AI 에이전트의 실수가 반복되지 않게 하려면: Incident Log, Root Cause, Checklist, Eval 루프

1. 개요: 반복되는 실수는 시스템 문제다

AI 에이전트는 이제 파일, 도구, 웹사이트, 메일함, CRM, 사내 지식과 연결됩니다. 그래서 더 유용해졌지만, 실수의 의미도 달라졌습니다. 채팅 안의 오답은 불편한 정도에서 끝날 수 있습니다. 업무 흐름 안의 오답은 고객, 발행, 비용, 데이터, 컴플라이언스 문제로 이어질 수 있습니다.

실무 질문은 "AI가 절대 실수하지 않게 할 수 있나"가 아닙니다. 실수 이후 조직이 더 똑똑해지는가입니다. "다음부터 조심하자"로 끝나면 같은 실수는 모양만 바꿔 다시 돌아옵니다.

블로그 발행 업무를 예로 들면 명확합니다. 로컬 파일이 생겼고, 로컬 미리보기가 되고, 커밋까지 했더라도 독자가 볼 수 없다면 발행은 끝난 것이 아닙니다. 완료 기준은 원격 저장소에 푸시되고, 실제 언어별 URL이 열리고, 이미지와 sitemap까지 확인되는 것입니다. 이 마지막 기준이 Checklist에 없으면 에이전트는 많은 일을 하고도 공개 표면을 바꾸지 못할 수 있습니다.

2. 쉬운 용어 정리: Incident Log, Root Cause, Checklist, Eval, Trace, SOP

Incident Log는 업무 사고 기록입니다. 서버 장애만 의미하지 않습니다. AI가 오래된 정책을 썼거나, 잘못된 초안을 만들었거나, 라이브 확인을 건너뛰었거나, 같은 가정을 반복했다면 모두 기록 대상입니다.

Root Cause, 또는 RCA는 근본 원인 분석입니다. 사람을 혼내기 위한 문서가 아닙니다. "누가 깜빡했다"보다 "완료 기준에 라이브 확인이 없었다"가 훨씬 좋은 원인입니다. 고칠 수 있기 때문입니다.

Checklist는 기억력 대신 누락을 막는 실행 표입니다. SOP는 Standard Operating Procedure의 줄임말로, 반복 업무를 처리하는 표준 절차입니다. Eval은 AI가 중요한 예시를 제대로 처리하는지 보는 테스트 세트입니다. Trace나 Log는 에이전트가 무엇을 읽고, 어떤 도구를 쓰고, 어떤 판단을 했는지 남긴 실행 흔적입니다.

• Incident Log: 무엇이 언제 어디서 잘못됐는지 남기는 업무 사고 기록.
• Root Cause: 같은 실수가 가능해진 시스템 조건.
• Checklist: 완료 전 반드시 확인해야 하는 최소 관문.
• Eval: 원하는 행동이 반복되는지 확인하는 테스트 세트.
• Trace 또는 Log: 에이전트 실행의 근거와 경로를 남긴 기록.
• SOP 또는 Runbook: 다음 번 같은 상황에서 따라야 할 절차.

3. 반복 실수를 막는 루프

루프는 여섯 단계면 충분합니다. 업무를 실행합니다. 사건을 기록합니다. Root Cause를 찾습니다. Checklist나 SOP를 고칩니다. Eval 케이스를 추가합니다. 다음 실제 실행에서 중요한 표면을 다시 확인합니다. 블로그라면 라이브 URL과 sitemap입니다. 고객지원이라면 티켓 상태와 고객에게 보낼 초안입니다. 재무라면 승인된 장부나 송장일 수 있습니다.

OpenAI와 Anthropic 문서가 Eval을 강조하는 이유도 여기에 있습니다. 안정적인 AI 업무는 테스트 가능한 행동이 필요합니다. Google SRE와 Atlassian의 포스트모템 문화는 여기에 운영의 교훈을 더합니다. 실패를 개인의 주의력 문제가 아니라 재발 방지 작업으로 바꿔야 합니다.

그래서 AI 기억력만으로는 부족합니다. 기억은 에이전트에게 상기시킵니다. Checklist는 완료를 막습니다. Eval은 재발을 잡습니다. Trace는 왜 틀어졌는지 보여줍니다. 각각 역할이 다르기 때문에 실제 운영에는 여러 층이 필요합니다.

• Run: 입력과 출력이 보이는 상태로 업무를 실행합니다.
• Record: 실수를 구조화된 Incident Log에 남깁니다.
• Analyze: 사람 탓이 아니라 Root Cause를 적습니다.
• Change: Checklist, SOP, 프롬프트, 권한, 출처 규칙을 고칩니다.
• Test: 같은 실패를 잡는 Eval 또는 회귀 테스트를 추가합니다.
• Verify: 실제 외부 결과를 확인하고 닫습니다.

4. Incident Log에는 무엇을 적어야 하나

기록은 화려할 필요가 없습니다. 오히려 지루하고 정확해야 합니다. Notion, Google Sheets, GitHub, Obsidian의 표 하나로도 충분합니다. 중요한 것은 매번 같은 필드를 쓰는 것입니다.

미래의 리뷰어가 긴 대화를 다시 뒤지지 않아도 이해할 수 있어야 합니다. 기대 결과는 무엇이었고, 실제 결과는 무엇이었는지, 어떤 도구나 URL이나 출처가 관련됐는지, 어떤 완료 신호가 빠졌는지, 어떤 예방 조치가 생겼는지를 적어야 합니다.

• 날짜와 업무: 언제, 어떤 업무에서 생겼는지.
• 기대 결과와 실제 결과: 가장 짧은 전후 설명.
• 발견 신호: 무엇을 보고 문제를 알게 됐는지.
• 영향: 고객 노출, 내부 문제, 비용, 데이터, 브랜드, 법적 위험.
• 근거: URL, 로그, 스크린샷, 도구 출력, 커밋, 티켓.
• Root Cause: 실수가 가능해진 운영 조건.
• 예방 조치: Checklist, SOP, Eval, Guardrail, 담당자, 권한 변경.
• 닫힘 증거: 라이브 URL, 테스트 결과, 배포, 승인 등 실제 완료 증거.

5. Root Cause는 비난이 아니라 설계다

Blameless, 즉 비난 없는 분석은 책임을 흐리자는 뜻이 아닙니다. 반복 가능한 조건을 찾자는 뜻입니다. "에이전트가 푸시를 잊었다"는 약한 원인입니다. "완료 정의가 로컬 확인에서 멈췄고, 원격 푸시와 라이브 확인을 요구하지 않았다"는 좋은 원인입니다. 바로 Checklist로 바꿀 수 있기 때문입니다.

좋은 Root Cause는 보통 몇 가지 범주로 모입니다. Source of Truth가 불명확했거나, 담당자가 없었거나, 지식이 오래됐거나, 권한 경계가 약했거나, 외부 검증이 없었거나, 승인 규칙이 애매했거나, Eval 케이스가 없었거나, Trace가 남지 않았던 경우입니다.

이 지점에서 사람도 AI와 함께 발전해야 합니다. 사람은 단순 승인자가 아니라 워크플로우 설계자가 됩니다. 어떤 신호가 더 일찍 잡았을지, 어떤 관문이 빠졌는지, 다음에는 에이전트가 무엇을 완료라고 부르지 못하게 해야 하는지 묻는 능력이 중요해집니다.

6. Checklist는 의도가 아니라 완료 기준을 정의해야 한다

Checklist에 "블로그 발행"이라고만 쓰면 너무 약합니다. 언어별 포스트 데이터 추가, 이미지 추가, 타입 체크, 린트, 빌드, 언어별 상세 페이지 확인, 목록 페이지 확인, sitemap 확인, 커밋, 푸시, 라이브 URL 확인까지 쪼개야 합니다. 마지막 10퍼센트를 보이게 만드는 것이 핵심입니다.

다른 업무도 마찬가지입니다. 영업 요약은 CRM 기록에 붙어야 끝납니다. 고객지원 초안은 사람이 승인하기 전에는 끝난 것이 아닙니다. 데이터 정리는 하위 리포트가 기대대로 바뀌어야 끝납니다.

강한 Checklist에는 외부 증거가 들어갑니다. "파일 수정 완료"보다 "라이브 페이지가 200을 반환하고 새 slug를 포함한다"가 강합니다. "초안 생성 완료"보다 "리뷰어가 승인했고 고객 자동 발송은 여전히 막혀 있다"가 강합니다.

7. Eval은 사건을 반복 테스트로 바꾼다

Eval은 기술 용어처럼 들리지만 뜻은 단순합니다. 에이전트가 꼭 잘해야 하는 예시 묶음을 만드는 것입니다. 오래된 지식을 믿어서 실패했다면 오래된 출처와 최신 출처가 함께 있는 예시를 넣습니다. 라이브 확인을 건너뛰었다면 로컬 성공만으로는 통과할 수 없는 예시를 넣습니다.

처음부터 거대한 벤치마크를 만들 필요는 없습니다. 회사가 실제로 아파한 실패 10개면 충분합니다. 기대 답변, 금지 행동, 필요한 출처, 필요한 승인, 완료 증거를 함께 적습니다. 그리고 프롬프트, 모델, 도구, 출처, Checklist가 바뀔 때마다 돌립니다.

커뮤니티에서도 같은 신호가 반복됩니다. 일반적인 LLM 판정자는 회사가 실제로 중요하게 보는 도메인 실패를 놓칠 수 있습니다. 그래서 좋은 Eval 케이스는 실제 사건, 고객 수정, 리뷰어 수정, 아슬아슬했던 near miss에서 나옵니다.

8. Guildex식 Incident Learning Table

작은 팀에게 가장 유용한 산출물은 사건과 예방 장치를 연결한 한 장의 표입니다. 목적은 관료제가 아닙니다. 조직이 배운 것을 시스템이 기억하게 만드는 것입니다.

예를 들면 이런 행입니다. Incident는 "포스트는 로컬에 있지만 라이브에는 없음", Signal은 "라이브 블로그의 최신 글이 이전 날짜에서 멈춤", Root Cause는 "완료 기준에 push와 live sitemap 확인이 없음", Prevention은 "Checklist에 commit, push, live URL, image, sitemap 확인 추가", Closeout Proof는 "라이브 URL 200 확인"입니다.

• Incident: 무슨 일이 잘못됐는지 한 문장으로 적습니다.
• Signal: 어떻게 발견했는지 적습니다.
• Root Cause: 빠져 있던 시스템 조건을 적습니다.
• Prevention: 어떤 Checklist, SOP, Eval, 권한, 출처 규칙이 바뀌었는지 적습니다.
• Owner: 그 예방 장치를 누가 유지할지 적습니다.
• Verification URL 또는 Output: 실제로 닫혔다는 외부 증거를 적습니다.

9. 결론: AI 도입은 실수를 지식으로 바꿀 때 복리로 좋아진다

AI를 잘 쓰는 회사는 실수가 전혀 없는 회사가 아닙니다. 실수를 더 좋은 운영 지식으로 바꾸는 회사입니다. 모든 사건은 시스템을 더 속이기 어렵게 만들고, 리뷰하기 쉽게 만들고, "완료"의 의미를 더 선명하게 만들어야 합니다.

AI가 발전할수록 사람도 함께 발전해야 합니다. 사람의 역할은 "이 출력 괜찮나 빨리 봐주기"에서 "다음 출력이 더 안전해지는 루프 설계하기"로 바뀝니다. 더 좋은 Incident Log, 더 좋은 Root Cause 사고, 더 좋은 Checklist, 더 좋은 Eval, 더 좋은 라이브 검증을 만드는 능력이 필요합니다. AI의 속도는 인간의 운영 시스템도 함께 학습할 때 비로소 가치가 됩니다.