장애 대응과 비용 관리

이 장에서 배울 것

이번 장에서는 AI 시스템에서 발생하는 장애를 운영 절차로 다루고, 학습·추론 비용을 통제하는 방법을 배웁니다.

이 장을 끝내면 다음을 할 수 있습니다.

• AI 시스템에서만 자주 나타나는 장애 유형을 구분합니다.

• 온콜 담당자가 즉시 실행할 수 있는 triage runbook을 작성합니다.

• 장애 대응 지표와 AI 품질 지표를 함께 해석합니다.

• 학습·추론·로그·외부 API 비용을 나누어 추적합니다.

• 비용 폭증을 운영 장애로 보고 예방 장치를 설계합니다.

왜 이 주제가 중요한가

일반적인 웹 서비스 장애는 비교적 눈에 잘 띕니다. 서버가 죽거나, 500 오류가 늘거나, 응답 시간이 급격히 늘어납니다. AI 시스템은 다릅니다. API는 계속 200 OK를 반환하지만 추천 품질이 떨어지고, 챗봇은 그럴듯한 오답을 내며, 분류 모델은 특정 집단에만 나쁜 결과를 낼 수 있습니다. 서비스는 살아 있지만 의사결정 품질은 무너질 수 있습니다.

운영의 실력은 장애가 없을 때가 아니라 장애가 발생했을 때 드러납니다. 더 정확히는 "얼마나 빨리 알아차리고, 얼마나 안전하게 완화하며, 같은 문제가 반복되지 않게 만드는가"에서 드러납니다. Google SRE의 포스트모템 문화도 장애를 비난이 아니라 학습과 재발 방지의 기회로 다루는 것을 강조합니다.¹

비용도 마찬가지입니다. GPU 사용량, 토큰 수, 벡터 검색량, 로그 저장량이 통제 없이 늘어나면 서비스 장애만큼 심각한 운영 문제가 됩니다. AI 시스템에서는 품질 저하와 비용 폭증이 서로 연결되는 경우도 많습니다. 예를 들어 LLM 응답 품질이 낮아져 재시도가 늘면 사용자 경험은 나빠지고 비용은 동시에 증가합니다.

핵심 개념 설명

AI 장애는 두 종류로 나누어 본다

첫째는 명확한 장애입니다. 엔드포인트가 응답하지 않거나, 오류율이 증가하거나, GPU 메모리 부족으로 추론 서버가 재시작되는 경우입니다. 이런 장애는 기존 SRE 방식으로도 어느 정도 탐지할 수 있습니다.

둘째는 정상처럼 보이는 장애입니다. 요청은 성공하지만 입력 스키마가 바뀌어 모든 특성이 기본값으로 들어가거나, 라벨 오류 때문에 새 모델이 잘못 학습되거나, 학습 데이터와 서빙 데이터의 전처리 방식이 달라 예측이 틀어지는 경우입니다. LLM 시스템에서는 검색 파이프라인 변경으로 근거 문서가 누락되고, 그 결과 환각이나 오답이 증가할 수 있습니다.

운영에서는 다음 장애 유형을 별도로 기록해야 합니다.

장애 유형을 나누는 이유는 책임을 미루기 위해서가 아닙니다. 원인 후보를 빠르게 좁히기 위해서입니다. 데이터 장애를 재학습으로 해결하려 하면 문제가 커질 수 있고, 비용 장애를 단순 트래픽 증가로만 보면 악성 재시도나 프롬프트 변경을 놓칠 수 있습니다.

심각도는 미리 정한다

장애 중에 심각도를 정하려고 하면 늦습니다. 기준은 사전에 합의해야 합니다.

• P0: 고객 영향이 크고 즉시 중단 또는 우회가 필요한 장애. 예: 결제 심사 모델이 대량 오판, 챗봇이 위험한 답변 생성.

• P1: 핵심 기능 품질이 크게 하락했지만 fallback으로 완화 가능한 장애.

• P2: 일부 사용자나 내부 기능에 영향이 있는 장애.

• P3: 즉시 영향은 작지만 추세상 악화될 가능성이 있는 장애.

심각도에는 기술 지표뿐 아니라 비즈니스 영향도 포함합니다. 같은 오류율 5%라도 내부 리포트 모델과 고객 결제 모델의 심각도는 다릅니다. 또한 AI 시스템에서는 "오류율"만으로 심각도를 판단하기 어렵습니다. 오류율이 0%여도 잘못된 대출 승인, 위험한 의료 정보, 개인정보 노출 가능성이 있다면 높은 심각도로 다뤄야 합니다.

Triage runbook은 15분 안에 실행 가능해야 한다

Runbook은 장애 대응 절차서입니다. 좋은 runbook은 "전문가가 읽으면 좋은 문서"가 아니라 "졸린 온콜 담당자가 새벽 3시에 그대로 따라 할 수 있는 문서"입니다. 특히 모델 내부를 깊이 몰라도 첫 판단을 할 수 있어야 합니다. Google의 인시던트 관리 가이드도 장애 대응에서 조율, 커뮤니케이션, 통제를 중요하게 다루며, 명확한 역할과 절차가 대응 품질을 좌우한다고 설명합니다.²

AI 시스템의 triage runbook은 첫 15분을 기준으로 설계하는 것이 좋습니다.

첫 5분: 서비스가 살아 있는지 확인합니다.

• 엔드포인트 오류율, p95/p99 지연 시간, QPS를 확인합니다.

• 최근 배포, 설정 변경, 모델 alias 전환이 있었는지 확인합니다.

• 영향 범위가 전체 사용자, 특정 지역, 특정 모델 버전, 특정 기능 중 어디인지 봅니다.

5~10분: 데이터와 모델 신호를 확인합니다.

• 입력 스키마 검증 실패가 늘었는지 확인합니다.

• 데이터 신선도와 피처 파이프라인 상태를 봅니다.

• 입력 분포와 예측 분포가 기준선에서 크게 벗어났는지 확인합니다.

• 샘플 요청 몇 건을 직접 재현해 모델 버전, 입력값, 응답값을 확인합니다.

10~15분: 완화 조치를 결정합니다.

• 이전 모델로 롤백할지 결정합니다.

• fallback 규칙을 켤지 결정합니다.

• 고비용 기능이나 위험 기능을 일시 제한할지 결정합니다.

• 데이터팀, ML팀, 플랫폼팀, 보안팀 중 누구에게 에스컬레이션할지 정합니다.

Runbook에는 최소한 다음 항목이 있어야 합니다.

1. 탐지 조건: 어떤 알림이 이 runbook을 여는가?

2. 심각도 분류: P0/P1/P2/P3 기준은 무엇인가?

3. 영향 범위 확인: 전체 사용자, 특정 지역, 특정 모델 버전 중 어디에 영향이 있는가?

4. 초기 완화 조치: 롤백, fallback, 기능 제한, 큐잉, rate limit 중 무엇을 할 것인가?

5. 에스컬레이션: 데이터팀, ML팀, 플랫폼팀, 보안팀 중 누구를 언제 호출할 것인가?

6. 복구 확인: 어떤 지표가 정상 범위로 돌아와야 종료할 수 있는가?

7. RCA와 postmortem: 원인과 재발 방지 액션을 어떻게 남길 것인가?

장애 지표는 SRE 지표와 AI 지표를 연결한다

기존 운영 지표는 여전히 중요합니다. 오류율, p95·p99 지연 시간, 요청 수, CPU/GPU 사용률, 재시도율은 반드시 봅니다. 여기에 AI 품질 지표를 더해야 합니다. 입력 분포, 예측 분포, 정답 라벨 도착 후 정확도, 데이터 신선도, drift 점수, 환각률, 안전성 위반률, 사용자 불만 비율을 함께 봅니다. MLOps에서 운영 모니터링은 모델 성능과 비즈니스 지표까지 연결되어야 합니다.³

장애 대응 성과는 다음 지표로 측정합니다.

• 탐지까지 걸린 시간: 문제가 시작된 뒤 알림이 울릴 때까지.

• 인지까지 걸린 시간: 담당자가 알림을 확인하고 대응을 시작할 때까지.

• 완화까지 걸린 시간: 고객 영향을 줄이는 임시 조치까지.

• 복구까지 걸린 시간: 정상 기준으로 돌아올 때까지.

• 재발 방지 완료율: postmortem 액션 아이템이 실제로 끝났는가.

여기서 "복구"는 서버가 다시 살아났다는 뜻만은 아닙니다. AI 시스템에서는 모델 품질 지표, 비즈니스 KPI, 비용 지표가 함께 정상 범위로 돌아왔는지도 확인해야 합니다.

비용 폭증도 장애다

AI 비용은 한 덩어리로 보면 통제할 수 없습니다. 최소한 다음 항목으로 나누어 추적합니다.

• 학습 비용: GPU/TPU, 하이퍼파라미터 탐색, 재학습 파이프라인.

• 추론 비용: 실시간 엔드포인트, 배치 예측, 오토스케일링 복제본.

• 데이터 비용: 스토리지, 데이터 웨어하우스 쿼리, 네트워크 전송.

• 관측성 비용: 로그, 트레이스, 메트릭 저장.

• LLM 비용: 입력 토큰, 출력 토큰, 모델 등급, 외부 API 호출.

• RAG 비용: 임베딩 생성, 벡터 DB 저장, 벡터 검색, 재색인.

비용 관리는 사후 정산이 아니라 운영 설계입니다. 프로젝트·팀·환경·모델 이름으로 라벨을 붙이고, 예산과 알림을 설정하며, 비용 대시보드에서 이상 증가를 탐지해야 합니다. Google Cloud의 AI/ML 비용 최적화 가이드도 비용을 측정 가능한 단위로 나누고, 리소스 사용률·모델 선택·데이터 처리 방식을 함께 최적화할 것을 권장합니다.⁴

LLM 시스템에서는 호출마다 다음 정보를 남겨야 원인을 찾을 수 있습니다.

• 요청 ID

• 사용자 또는 테넌트 ID(개인정보 정책에 맞게 비식별화)

• 기능 이름

• 모델 이름

• 프롬프트 버전

• 입력 토큰 수

• 출력 토큰 수

• 캐시 적중 여부

• 재시도 횟수

• 예상 또는 실제 비용

이 정보를 남기지 않으면 "이번 달 LLM 비용이 왜 두 배가 되었는가?"라는 질문에 답할 수 없습니다. 비용 증가는 단순 사용량 증가 때문일 수도 있지만, 프롬프트가 길어졌거나, 캐시가 꺼졌거나, 재시도 루프가 생겼거나, 비싼 모델로 라우팅되는 비율이 늘었기 때문일 수도 있습니다.⁵

비용 절감은 안정성을 해치지 않는 범위에서 한다

비용을 줄이겠다고 무조건 작은 모델로 바꾸면 품질 장애가 생깁니다. 비용 최적화는 품질 기준을 통과하는 가장 싼 경로를 찾는 일입니다.

실무에서 자주 쓰는 방법은 다음과 같습니다.

• 오토스케일링의 최소·최대 복제본을 명확히 둡니다.

• 실시간이 필요 없는 요청은 배치로 돌립니다.

• 동일 요청이나 동일 임베딩은 캐싱합니다.

• 모델 양자화와 경량화를 적용하되 품질 회귀 테스트를 통과시킵니다.

• 고가 LLM은 어려운 요청에만 라우팅하고 쉬운 요청은 저비용 모델로 처리합니다.

• 로그와 트레이스는 전량 저장 대신 샘플링과 보존 기간을 설정합니다.

• spot/serverless 자원은 중단 가능 작업에만 사용합니다.

• 콜드스타트가 치명적인 기능은 warm pool이나 fallback을 준비합니다.

비용 절감 조치는 반드시 품질 지표와 함께 봐야 합니다. 비용이 30% 줄었지만 환각률이 두 배가 되거나, 지연 시간이 SLO를 넘거나, 특정 고객군의 성능이 크게 나빠졌다면 성공한 최적화가 아닙니다.

쉬운 비유 또는 사례

AI 운영은 병원 응급실과 비슷합니다. 모든 환자에게 최고 전문의를 바로 붙일 수는 없습니다. 먼저 생명이 위험한지, 어디가 문제인지, 지금 당장 해야 할 처치가 무엇인지 빠르게 가릅니다. 이것이 triage입니다.

비용 관리도 같습니다. 모든 요청에 가장 큰 모델을 쓰는 것은 모든 감기 환자에게 최고급 MRI를 찍는 것과 비슷합니다. 정확할 수는 있지만 지속 가능하지 않습니다. 운영자는 품질을 유지하면서도 필요한 만큼만 자원을 쓰도록 경로를 설계해야 합니다.

직접 해보는 실습

다음 가상 사건을 바탕으로 문서를 작성해 봅시다.

사건: 추천 API는 정상 응답하지만 오전 9시 이후 클릭률이 30% 하락했습니다. p95 지연 시간은 2배 증가했고, LLM 기반 설명 생성 비용은 평소보다 280% 증가했습니다. 전날 밤 feature pipeline과 프롬프트 템플릿이 함께 배포되었습니다.

1단계: Triage runbook 작성

아래 항목을 채웁니다.

• 알림 이름:

• 심각도:

• 영향 범위:

• 첫 5분 확인:

  • 엔드포인트 상태:

  • 최근 배포:

  • 데이터 파이프라인 상태:

  • 비용 급증 여부:

• 5~10분 확인:

  • 현재 모델 버전:

  • 입력 분포 변화:

  • 예측 분포 변화:

  • 샘플 요청 10건:

• 즉시 조치:

  • 롤백:

  • fallback:

  • rate limit:

  • 고비용 기능 제한:

• 에스컬레이션 대상:

• 복구 확인 기준:

2단계: RCA 초안 작성

RCA는 Root Cause Analysis, 즉 근본 원인 분석입니다. 비난을 위한 문서가 아니라 시스템을 고치기 위한 문서입니다. 좋은 postmortem은 원인, 영향, 복구 과정, 재발 방지 액션을 구체적으로 남깁니다. 액션 아이템에는 담당자와 완료 기한이 있어야 합니다.¹

• 원인:

• 직접 영향:

• 간접 영향:

• 타임라인:

• 탐지가 늦어진 이유:

• 즉시 조치:

• 재발 방지 액션:

• 담당자:

• 완료 기한:

3단계: 비용 리포트 작성

• 총 증가 비용:

• 증가한 비용 항목:

• 모델별 비용:

• 기능별 비용:

• 사용자 또는 테넌트별 비용:

• 입력/출력 토큰 변화:

• 캐시 적중률:

• 다음 달 예상 비용:

• 제한 정책 또는 예산 알림 변경:

이 실습에서 중요한 것은 "정답"이 아닙니다. 장애를 감으로 처리하지 않고, 관찰한 신호와 조치를 문서로 연결하는 연습입니다.

흔한 실수와 오류 분석

• 업타임만 본다: 200 OK가 계속된다고 AI 기능이 정상이라는 뜻은 아닙니다.

• 롤백은 있는데 검증이 없다: 롤백 후 어떤 지표가 회복되어야 하는지 없으면 복구를 선언할 수 없습니다.

• 모든 문제를 재학습으로 해결하려 한다: 원인이 데이터 지연이나 스키마 변경이면 재학습은 오히려 문제를 키웁니다.

• 오토스케일링 상한이 없다: 트래픽 폭주나 무한 재시도 때 비용이 장애처럼 터집니다.

• 로그를 전부 영구 저장한다: 관측성 비용이 추론 비용보다 커질 수 있습니다.

• 외부 API 실패를 고려하지 않는다: LLM, 임베딩, 벡터 DB는 모두 장애 전파 지점입니다.

• postmortem을 쓰고 끝낸다: 액션 아이템이 완료되지 않으면 같은 장애가 반복됩니다.

• 비용 알림을 월말 청구서로만 확인한다: 비용 장애는 실시간 또는 일 단위로 감지해야 합니다. 월말에 발견하면 이미 늦습니다.

요약

AI 장애는 서버가 죽는 문제만이 아닙니다. 데이터가 늦고, 스키마가 바뀌고, 모델 품질이 하락하고, LLM이 그럴듯한 오답을 내는 것도 장애입니다. 따라서 runbook은 인프라, 데이터, 모델, 비용을 함께 확인하도록 작성해야 합니다.

비용 폭증 역시 운영 장애로 다루어야 합니다. 예산·쿼터·대시보드·알림·캐싱·라우팅 정책으로 통제해야 하며, 비용 절감 조치는 품질과 안정성 기준을 통과해야 합니다.

좋은 장애 대응은 영웅적인 야근이 아닙니다. 누가 봐도 따라 할 수 있는 runbook, 빠른 완화, 명확한 롤백 기준, 비난 없는 postmortem, 완료되는 액션 아이템에서 나옵니다.

퀴즈

1. API가 200 OK를 반환해도 AI 장애일 수 있는 이유는 무엇인가?

2. P0 장애와 P2 장애를 나누는 기준에는 어떤 요소가 들어가야 하는가?

3. 비용 폭증을 탐지하려면 LLM 호출마다 어떤 정보를 남겨야 하는가?

4. 오토스케일링이 비용 장애를 만들 수 있는 상황을 설명해 보라.

5. RCA 문서에 반드시 포함해야 할 항목 세 가지를 적어 보라.

체크리스트

• 모델 장애 유형을 인프라·데이터·모델·LLM·비용으로 나누어 정의했다.

• P0/P1/P2/P3 심각도 기준이 문서화되어 있다.

• 알림마다 연결된 runbook이 있다.

• 롤백, fallback, 기능 제한 절차가 테스트되어 있다.

• 탐지·인지·완화·복구 시간을 측정한다.

• 학습, 추론, 로그, 외부 API, 임베딩, 벡터 검색 비용을 분리해 본다.

• 예산 한도와 비용 급증 알림이 설정되어 있다.

• LLM 호출의 토큰 수, 모델명, 프롬프트 버전, 캐시 적중률을 기록한다.

• postmortem 액션 아이템에 담당자와 완료 기한이 있다.

다음 장 연결

다음 장에서는 지금까지 배운 내용을 하나의 재현 가능한 MLOps 프로젝트로 묶습니다. 데이터 버전, 실험 추적, 파이프라인, CI/CD/CT, 서빙, 모니터링, 장애 대응 문서를 모두 연결해 "다시 실행해도 같은 결과가 나오는 운영 가능한 AI 시스템"을 만듭니다.

참고

¹Google SRE Workbook, Postmortem Culture: Learning from Failure

²Google SRE, Incident Management Guide

³MLOps Principles

⁴Google Cloud Well-Architected Framework: AI 및 ML 비용 최적화

⁵AWS Well-Architected Framework, Cost Optimization Pillar