14장. 사고는 트레이스로 재생하고 평가로 봉합한다

사고 대응의 목표는 범인 찾기가 아니다

에이전트 사고에서 “모델이 이상했다”는 결론은 재발을 막지 못한다. 입력, 정책, 프롬프트, 모델, 도구, 런타임 중 어떤 조합이 결과를 만들었는지 좁히고, 영향을 제한하고, 같은 실패를 자동으로 잡는 사례를 남겨야 한다.

npm run lab:incident

실습은 결함 버전으로 CLM-1002를 처리해 잘못된 approve를 만든 뒤 기준 버전으로 재생한다. build/incident-report.json에는 관찰 결과, 기대 결과, 재생 결과, 원인, 완화와 trace ID가 남는다.

첫 30분 절차

1. 쓰기 도구와 후보 라우팅을 중단한다.
2. 사고 시간, 릴리스, 정책 버전과 영향 세그먼트를 고정한다.
3. 원본 로그를 마구 복사하지 말고 보존 승인된 증거 참조를 잠근다.
4. 알려진 위험 지표로 영향 건수를 계산한다.
5. 기준 버전 또는 사람 처리 경로로 우회한다.
6. 외부 고지 여부를 사고 책임자와 개인정보·법무 담당자가 판단한다.

원인 분석은 봉쇄 뒤에 한다. 장애 중 프롬프트를 즉흥적으로 고치면 증거가 바뀌고 다른 실패를 만들 수 있다.

재생의 세 모드

• 결정적 재생: 당시 fixture와 정책 엔진으로 같은 결과를 만든다.
• 공급자 재호출: 같은 모델과 설정을 다시 호출한다. 모델 변동과 공급자 변경으로 정확히 같지 않을 수 있다.
• 기록 재평가: 당시 출력을 현재 평가기로 다시 채점한다. 새로운 안전 규칙의 영향을 확인한다.

재현되지 않는 것도 정보다. 당시 모델 스냅샷이 사라졌거나 검색 인덱스가 덮어써졌다면 릴리스 보존 설계가 부족했다는 뜻이다.

사고를 회귀 사례로 바꾸기

원인이 배송 파손 예외 규칙이라면 개인정보를 제거한 최소 입력을 만든다. 기대 결과와 위험 등급, 발견한 릴리스, 수정 커밋을 연결한다. 그 사례가 다음 모든 후보에서 실행될 때 사고 대응이 운영 학습으로 바뀐다.

완료 기준

• 사고 재생 보고서에서 trace ID와 원인을 확인했다.
• 봉쇄, 영향 분석, 원인 분석의 순서를 설명할 수 있다.
• 사고 사례를 회귀 세트에 넣는 승인 절차를 정했다.