13장 관측·오류·복구를 제품으로 만든다

운영자는 “에러가 났다”보다 어느 요청이 어느 단계에서 왜 멈췄는지 알아야 한다. 요청마다 상관관계 ID를 만들고 received → validated → analyzed → approved → queued 단계를 구조화 로그로 기록한다. 연락처 대신 브리프 ID를 쓴다.

핵심 지표는 요청 수가 아니라 결과 품질과 실패 복구다. 검증 실패율, AI 계약 실패율, 승인 대기 시간, 중복 방지 횟수, 큐 재시도와 최종 실패를 본다. 알림은 행동 가능해야 한다. 계약 실패율이 임계치를 넘으면 실제 AI 경로를 mock 또는 수동 검토로 전환한다.

복구 설계에는 세 가지가 필요하다. 재시도 가능한 오류인지 분류하고, 같은 행동을 반복해도 안전하게 만들고, 끝내 실패한 작업을 사람이 다시 볼 보류함에 둔다.