에이전트가 성공적으로 종료됐다는 오케스트레이터 보고를 믿었는데, 정작 커밋도 브랜치도 PR도 없었다. dev.to에 연재 중인 'The Factory Must Grow' 시리즈 저자가 2주 동안 수십 개의 PRD 이슈가 '완료' 처리됐지만 실제로 아무것도 배포되지 않았다는 사실을 뒤늦게 발견한 사례다. 에이전트가 조용히 실패했고, 오케스트레이터는 그걸 성공으로 기록했다. 이게 AI 에이전트 운영에서 가장 위험한 유형의 버그다.
크래시보다 무서운 건 침묵이다. 스택 트레이스를 던지는 장애는 오히려 낫다. 어디서 무엇이 잘못됐는지 바로 보이기 때문이다. 하지만 '성공'을 반환하면서 아무것도 하지 않은 에이전트는 시스템 전체에 거짓 신뢰를 심는다. 한두 번이면 수동으로 잡을 수 있지만, 에이전트 플릿이 병렬로 돌아가는 환경에서는 문제가 누적되는 속도가 탐지 속도를 앞선다.
저자가 꺼내든 해법의 틀은 의외로 Toyota Production System(TPS)이었다. Jidoka, Poka Yoke, Andon, Muda—자동차 공장 라인의 품질 철학을 AI 에이전트 오케스트레이션에 직접 매핑한 것이다. 언뜻 억지스러워 보이지만, 실제로 이 네 가지 원칙은 에이전트 실패의 패턴과 놀랍도록 정확하게 대응한다.
Jidoka: 자가 보고를 믿지 마라. Sakichi Toyoda의 Jidoka는 '이상 감지 즉시 자동 정지'다. 공장 라인에서는 불량이 감지되는 순간 기계가 멈추고, 품질팀이 라인 끝에 도달하기 전에 이미 개입이 이뤄진다. 에이전트에 대입하면 이렇다. 에이전트의 실행 상태 코드를 믿지 말고, 에이전트가 실제로 만들어낸 결과물을 검증하라. 저자는 모든 워커가 실행 종료 시 고정된 경로에 'verdict 파일'을 작성하도록 설계했고, 오케스트레이터는 이 파일의 존재와 내용만을 판단 기준으로 삼는다. 커밋, diff, 고정 경로의 파일—이것들은 에이전트가 거짓말할 수 없는 물리적 증거다.
Poka Yoke: 잘못된 상태 전이를 컴파일 타임에 막아라. Shigeo Shingo의 Poka Yoke는 '틀린 조작 자체를 불가능하게 만드는 설계'다. 프롬프트에 'XYZ를 잊지 마세요'라고 쓰는 건 Poka Yoke가 아니다. 저자의 시스템에서는 오케스트레이터의 인터페이스 경계에 가능한 dispatch 결과와 상태 전이를 명시적으로 정의하고, 이를 컴파일 타임에 강제한다. 'waiting for human answers' 레이블이 붙은 이슈는 절대 자동으로 closed 처리되지 않도록 상태 전이 레이어에 하드 가드를 걸었다. 재시도 루프가 무한히 돌았던 이유도 switch문에서 일부 케이스가 처리되지 않아 기본 경로로 떨어졌기 때문이었다. 모든 가능한 결과를 명시적으로 다루는 것이 진짜 방어선이다.
Andon: 에이전트 스스로 라인을 세울 수 있어야 한다. Toyota 라인에서 Andon 코드는 누구든 문제를 발견하면 당겨서 전체 생산을 멈출 수 있는 줄이다. 에이전트 버전으로는 이렇다. 워커가 시스템적 위험 신호를 감지하면 halt verdict를 파일에 쓰고 종료하며, 오케스트레이터는 이 신호를 받아 워크플로우 전체를 잠금 처리하고 인간이 개입하기 전까지 새 태스크를 디스패치하지 않는다. 저자는 Andon 도입 첫 주에 에이전트가 여러 번 코드를 당겼고, 그때마다 근본 원인을 파악해 시스템을 개선할 수 있었다고 밝혔다. 비결정론적인 에이전트 환경에서는 false positive 정지가 훨씬 싸다. 5분짜리 재디스패치가, 상태가 오염된 보드를 로그 더미에서 역추적하는 것보다 압도적으로 낫다.
여기까지가 운영 중 실패를 잡는 이야기라면, 두 번째 문제는 실패를 '잡았다고 착각하는' 것이다. dev.to의 또 다른 글—'Your AI Agent Evaluation Is Lying to You'—은 평가 단계에서 팀이 빠지는 통계적 함정을 정면으로 다룬다. 저자는 두 에이전트를 10번 대결시켜 5-5가 나오자 "유의미한 차이 없음"으로 결론 냈는데, 그 결론 자체가 틀렸다고 자가 진단한다.
10번의 테스트는 아무것도 증명하지 않는다. Wilson score interval로 계산하면, 10번 중 5번 이긴 에이전트의 95% 신뢰구간은 [24%, 76%]다. 이 범위 안에는 '압도적 우위', '무승부', '압도적 열세'가 모두 들어간다. 실제로 60% 승률의 에이전트를 50%와 구별하려면 최소 93번의 대결이 필요하고, 55% 우위라면 381번이 필요하다. 에이전트 간 실질적인 성능 격차는 대부분 52~58% 범위에 존재한다. 즉, 수백 번의 실행 없이는 개선인지 회귀인지조차 판단할 수 없다.
TrueSkill이나 Elo를 쓴다고 해도 함정은 같다. mu 값(추정 실력)이 그럴싸해 보여도, 게임 수가 적을 때의 sigma(불확실도)는 너무 커서 두 에이전트의 신뢰구간이 완전히 겹친다. 저자가 제시하는 실용적인 3가지 규칙은 단순하다. 첫째, 레이팅을 세션 간에 영속화하라(매번 sigma=200에서 시작하면 정보가 리셋된다). 둘째, sigma가 충분히 수렴하기 전까지 비교 결론을 내리지 마라. 셋째, 점수 하나가 아니라 신뢰구간 전체를 리포트하라. "v3의 mu=560"이 아니라 "v3: 560 ± 72 (95% CI)"가 진짜 답이다.
두 기사를 나란히 놓으면 하나의 메시지가 보인다. 에이전트가 '잘 동작하는 것처럼 보이는 것'과 '실제로 잘 동작하는 것'은 전혀 다른 명제다. 오케스트레이터가 성공을 보고해도, 에이전트 평가 지표가 개선을 보여줘도, 그 신호 자체가 신뢰 가능한지를 먼저 물어야 한다. TPS에서 이 질문에 대한 답은 명확하다. 라인을 세울 수 있는 구조를 먼저 설계하고, 세우는 비용이 흘려보내는 비용보다 항상 싸도록 만들어라.
팀 리드 관점에서 내일 당장 적용 가능한 체크리스트로 정리하면 이렇다. 에이전트의 자가 보고 대신 외부 검증 가능한 아티팩트(커밋, diff, 고정 경로 파일)를 성공 판단 기준으로 삼아라. 모든 상태 전이 엣지 케이스를 코드 레벨에서 명시적으로 처리하라. 에이전트가 스스로 전체 워크플로우를 정지시킬 수 있는 메커니즘을 처음부터 설계하라. 그리고 에이전트 성능 비교 결론을 내리기 전에 신뢰구간이 수렴했는지 반드시 확인하라.
에이전트 운영의 성숙도는 얼마나 빠르게 달리느냐가 아니라, 얼마나 신뢰 가능하게 멈출 수 있느냐로 측정된다. 자동화가 깊어질수록 침묵하는 실패의 비용은 기하급수로 커진다. Andon 코드를 설계하는 데 하루를 쓰는 것이, 2주치 토큰을 태우며 오염된 상태를 디버깅하는 것보다 훨씬 싸다. 이것은 Toyota가 수십 년 전에 이미 증명한 진리고, AI 에이전트 시대에도 변하지 않는다.