Your Agent Didn't Fail. Your Harness Did. — Vinoth Govindarajan, OpenAI

한 줄 핵심

에이전트의 생산 실패는 대부분 모델 성능보다 상태 소유권, 커밋 순서, 실행 권한, 종료 증명 같은 하네스 설계에서 발생하므로, 실전에서는 "모델이 무엇을 했는가"보다 "시스템이 무엇을 보존하고 증명했는가"를 봐야 한다.

시간별 요약

1. 0:01
   겉으로는 성공처럼 보였지만 다음 턴에서 기억되지 않는 사례를 통해, 사용자에게 보이는 응답과 영구 기록이 어긋날 때 문제가 생긴다는 점을 강조한다. 실패가 드러나는 크래시보다, 조용한 성공이 더 위험하며 에이전트 신뢰성은 모델 품질만으로 설명되지 않는다.
2. 2:01
   모델은 제안만 하고 하네스가 상태 전이, 권한 검사, 순서 있는 커밋, 실행 증거를 책임지는 생산 계약이 핵심이다. 이벤트, 세션 키, 단일 writer, 툴 실행, 감사 기록으로 이루어진 기본 구조가 에이전트 운영의 골격이며, 맥락은 하네스가 매 턴 다시 조립한다.
3. 7:01
   상태 소유권이 없으면 사실을 안정적으로 기억했다고 볼 수 없고, 재생 가능한 단일 시스템 오브 레코드가 있어야 한다. 또한 동시 writer가 있으면 last writer wins로 조용한 데이터 손실이 생기므로, 병렬 읽기는 허용하되 mutable state에는 하나의 순서 있는 커밋 경로가 필요하다.
4. 10:01
   툴 호출이 중간에 끊기면 세션이 끝나지 못한 채 멈추며, silence는 정상 상태가 아니라 종료되지 않은 작업 상태가 된다. 따라서 deadline, cancellation, watchdog, timeout, error result, recovery command를 갖추고 모든 외부 경계에 success, failure, timeout, cancel, max attempts 같은 종결 상태를 기록해야 한다.
5. 12:02
   권한은 단순한 승인 기억이 아니라 세션, 도구, 인자, 기간, 결과에 묶인 실행 상태여야 하며, 재시도나 복구 과정에서 그 증거가 사라지면 안 된다. 내부 컴포넌트의 success는 사용자에게 보였다는 증명이 아니므로, 실행·정책·렌더링이 이어지는 증거 사슬을 receipt로 남겨야 한다.
6. 14:00
   실무 점검은 트리거, 상속된 상태, 사용한 권한, 실제 실행, 남은 증거라는 다섯 질문으로 요약된다. 이 질문들은 대화 로그를 생산 실행으로 바꾸고, opening incident처럼 전달은 성공했지만 영구 상태는 깨진 하네스 실패를 빠르게 드러낸다.

실무 인사이트

• 에이전트 장애를 디버깅할 때는 모델 응답을 먼저 의심하기보다, 상태 소유권·권한 범위·커밋 순서·종료 기록이 제대로 남는지부터 확인하는 것이 훨씬 빠르다.
• 운영 로그는 대화 내용보다 receipt 중심으로 설계해야 하며, 사용자에게 보였는지까지 포함한 증거를 남겨야 재현과 책임 추적이 가능하다.
• 병렬 처리 자체보다 mutable state에 대한 단일 커밋 경로를 강제하는 것이 중요하므로, 읽기 확장과 쓰기 직렬화를 분리해 설계하는 것이 좋다.