이 문서를 통해 아래 질문들에 답할 수 있게 됩니다.
- AI 장애를 증상별로 어떻게 분류하는가?
- 답변 지연, 비용 폭증, JSON 깨짐, RAG 오답, tool 중복 실행은 어디부터 봐야 하는가?
- 즉시 완화와 근본 해결은 어떻게 구분하는가?
- 장애 후 재발 방지를 위해 어떤 지표와 테스트를 추가해야 하는가?
개요
AI 장애 대응의 핵심은 “모델이 이상하다”를 금지하는 것이다. AI 기능은 입력 검증, context 조립, retrieval, 모델 호출, 응답 검증, 후처리, 저장, tool 실행이 연결된 파이프라인이다.
장애가 나면 증상을 단계별로 분리해야 한다.
공통 진단 순서
- 영향을 받는 기능과 tenant를 좁힌다.
- 최근 변경을 확인한다. prompt, model, schema, retrieval, index, provider, SDK, infra 변경을 본다.
- trace에서 단계별 latency와 실패 유형을 본다.
- fallback이나 degrade mode로 즉시 완화한다.
- eval과 재현 케이스를 만들어 회귀 테스트에 추가한다.
답변이 느림
확인할 것:
- input token과 output token이 증가했는가?
- provider latency가 증가했는가?
- retry count가 증가했는가?
- vector DB query가 느려졌는가?
- queue depth가 증가했는가?
- streaming gateway timeout이 바뀌었는가?
즉시 완화:
- max output token을 줄인다.
- top-k를 줄이거나 reranker를 잠시 끈다.
- 긴 요청은 job으로 전환한다.
- fallback model이나 cached response를 사용한다.
재발 방지:
- feature별 latency budget을 둔다.
- token length와 latency 상관관계를 대시보드로 본다.
- queue depth와 job age 알림을 둔다.
비용이 갑자기 증가함
확인할 것:
- prompt version 변경 후 input token이 늘었는가?
- retry storm이 있는가?
- 특정 tenant나 user가 과도하게 호출하는가?
- eval/batch가 production key를 쓰는가?
- prompt cache hit rate가 떨어졌는가?
- RAG top-k나 chunk 크기가 바뀌었는가?
즉시 완화:
- tenant별 quota를 임시 제한한다.
- batch/eval을 중단한다.
- fallback을 더 저렴한 모델로 전환한다.
- output token limit을 낮춘다.
재발 방지:
- usage event를 feature, tenant, prompt version별로 저장한다.
- 비용 알림 threshold를 둔다.
- eval과 production key를 분리한다.
JSON 응답이 깨짐
확인할 것:
- structured output schema가 바뀌었는가?
- 모델이 refusal을 반환했는가?
- streaming 중 partial output을 파싱했는가?
- output token limit 때문에 잘렸는가?
- fallback model의 schema 준수율이 낮은가?
즉시 완화:
- 이전 prompt/schema로 rollback한다.
- validation failure 시 repair path를 사용한다.
- 사용자에게 재시도 가능한 실패로 응답한다.
재발 방지:
- schema validation 실패율을 metric으로 둔다.
- refusal 케이스를 eval에 추가한다.
- fallback model도 schema eval을 통과시킨다.
RAG가 엉뚱한 문서를 찾음
확인할 것:
- index가 최신인가?
- embedding 모델이 바뀌었는가?
- metadata filter가 권한 모델과 일치하는가?
- chunk 크기와 overlap이 바뀌었는가?
- 오래된 문서가 최신 문서보다 높은 점수를 받는가?
- query rewrite가 오히려 의도를 바꾸는가?
즉시 완화:
- source 표시를 강화해 사용자가 근거를 확인하게 한다.
- 문제 문서나 오래된 문서를 index에서 제외한다.
- top-k와 reranker 설정을 rollback한다.
재발 방지:
- retrieval eval set을 만든다.
- 문서 삭제와 재색인 파이프라인을 검증한다.
- source freshness score를 고려한다.
Tool Calling이 중복 실행됨
확인할 것:
- retry가 side effect tool에 적용되었는가?
- queue가 메시지를 중복 전달했는가?
- agent loop가 같은 tool을 반복 호출했는가?
- idempotency key가 없거나 매번 달라지는가?
- timeout 후 실제 실행은 성공했는데 host가 실패로 판단했는가?
즉시 완화:
- write tool을 일시적으로 read-only 또는 approval required로 전환한다.
- idempotency key 없는 retry를 끈다.
- tool call max step을 낮춘다.
재발 방지:
- write tool은 idempotency key를 필수로 받는다.
- audit log로 중복 실행을 탐지한다.
- tool별 retry policy를 문서화한다.
코드로 이해하기
장애 이벤트는 증상과 단계를 함께 남긴다.
{
"event": "ai.failure",
"feature": "document_qa",
"stage": "retrieval",
"symptom": "wrong_source",
"prompt_version": "doc-qa-v4",
"retrieval_profile": "top8-rerank-v2",
"tenant_id": "tenant-a",
"trace_id": "trace-123"
}symptom만 있으면 원인 분석이 어렵고, stage만 있으면 사용자가 겪은 문제가 보이지 않는다. 둘을 함께 남긴다.
인프라 협업 포인트
장애 런북에는 인프라팀이 볼 지표가 들어가야 한다.
- provider latency와 error rate
- queue depth와 job age
- vector DB latency
- worker CPU, memory, concurrency
- outbound error
- log volume
- trace sampling
AI 장애는 애플리케이션과 인프라가 같이 봐야 빨리 좁혀진다.
위험 신호!
- 장애 로그에 prompt version이 없다.
- retrieval 결과 source id가 trace에 없다.
- validation failure가 500으로만 보인다.
- provider 장애와 내부 validation 실패가 같은 에러 코드다.
- 장애 후 eval case를 추가하지 않는다.
확인 질문
확인 질문
- AI 장애를 분석할 때 “모델이 틀렸다”로 끝내면 안 되는 이유는 무엇인가?
- retrieval, context, 모델 호출, validation, 후처리 중 어느 단계 문제인지 알아야 재발 방지를 할 수 있기 때문이다.
- tool 중복 실행 장애의 핵심 완화책은 무엇인가?
- write tool retry를 제한하고 idempotency key와 audit log를 강제하는 것이다.