Your Agent Didn’t Fail. Your Harness Did. — Vinoth Govindarajan, OpenAI
📺 원본 영상: Your Agent Didn’t Fail. Your Harness Did. — Vinoth Govindarajan, OpenAI
🎙️ 채널: AI Engineer
📅 정리 일자: 2026-07-30
⚠️ Note: 본 리포트는 영상의 음성을 텍스트로 변환(STT)하여 정리한 것입니다. 화면에 표시된 자료, 코드, 슬라이드, 표는 포함되지 않을 수 있습니다.
개요
Vinoth Govindarajan은 이 강연에서 AI 에이전트의 운영 장애를 바라보는 관점을 모델 품질 중심에서 시스템 하네스(Harness) 중심으로 전환해야 한다고 주장한다. 여기서 하네스란 모델을 감싸고 있는 실행 환경, 즉 상태를 조립하고, 도구 호출을 통제하며, 권한을 확인하고, 감사 가능한 증거를 남기는 생산 시스템의 경계다.
강연의 핵심 문장은 “모델은 제안하고, 하네스는 커밋하며, 영수증은 그것을 증명한다”로 요약된다. 모델이 답변을 생성하거나 도구 사용을 제안할 수는 있지만, 실제 운영 환경에서 무엇이 실행되었고 무엇이 지속 상태로 남았는지를 결정하는 주체는 모델이 아니라 하네스라는 뜻이다.
실패는 답변이 아니라 기록에서 시작된다
강연자는 사용자가 보기에는 정상적으로 처리된 것처럼 보였지만, 시스템의 영속 기록에는 해당 사실이 남지 않은 사건으로 이야기를 시작한다. 사용자는 에이전트에게 고객 환불 사실을 기억해 달라고 요청했고, 어시스턴트는 다음 턴을 위해 이를 기록했다고 응답했다. 인터페이스에는 오류가 없었고, 사용자는 성공을 경험했지만, 다음 턴에서 시스템은 그 사실을 다시 고려할 수 없었다.
이 사례가 중요한 이유는 장애가 겉으로 드러나지 않았기 때문이다. 크래시는 불편하지만 적어도 경계를 제공한다. 어디서 멈췄는지 알 수 있고, 오류 로그를 볼 수 있으며, 대개 마지막 정상 지점에서 복구를 시작할 수 있다. 반면 조용한 성공은 더 위험하다. 전달은 성공했지만 지속 상태 저장은 실패할 수 있고, 사용자는 응답을 의심할 이유가 없으며, 운영자에게도 명확한 알람이 발생하지 않는다.
이때 모델은 여전히 유창하게 답할 수 있다. 문제는 그 유창함이 완전한 이력 위에 서 있는 것이 아니라 깨진 히스토리 위에서 만들어진다는 점이다. 강연자가 말하는 에이전트 신뢰성은 바로 이 지점에서 모델 품질만으로는 충분하지 않다. 에이전트가 생산 시스템이 되려면 답변의 자연스러움뿐 아니라, 상태가 어디에 저장되고 누가 그것을 다시 재생할 수 있는지까지 설계되어야 한다.
하네스의 생산 계약: 제안, 커밋, 증명
강연자는 생산 환경의 계약을 “A model proposes, the harness commits, and the receipt proves it”이라고 정리한다. 모델은 메시지, 도구 호출, 편집, 명령을 제안할 수 있지만, 모델 자체가 생산 경계가 되어서는 안 된다. 상태 전이, 권한 검사, 감사 커밋, 그리고 다음 턴 이후에도 살아남는 증거는 하네스가 책임져야 한다.
이 관점은 AI 에이전트를 자동차에 비유할 때 더 선명해진다. 모델은 엔진과 같아서 성능과 능력을 제공하지만, 자동차를 생산품으로 만들기 위해서는 조향, 브레이크, 도로 규칙, 대시보드, 블랙박스가 함께 필요하다. 강력한 엔진만으로는 자율성이 만들어지지 않으며, 통제 장치가 없다면 그것은 빠르게 움직이는 책임 소재 불명의 위험 요소가 된다.
강연자가 제시한 하네스의 청사진은 이벤트, 세션 키, 런타임, 도구, 승인, 감사 기록으로 구성된다. 이벤트는 채팅, 웹훅, 타이머, 하트비트, 외부 시스템 등 여러 표면에서 들어오고, 컨트롤 플레인은 이를 세션 키에 매핑한다. 세션 키는 상태의 경계를 결정하며, 세션 레인은 변경 가능한 상태에 대해 하나의 활성 작성자를 제공한다. 런타임은 모델과 도구를 호출하고, 도구는 승인과 정책을 통해 실행되며, 감사 추적은 실행 영수증이 된다.
04:50 - 에이전트 하네스 청사진에서 이벤트, 세션 키, 런타임, 도구, 승인, 감사 기록의 관계를 설명하는 구간
에이전트는 기억하지 않는다, 하네스가 문맥을 재구성한다
강연에서 중요한 전제는 에이전트 런타임이 인간처럼 기억하지 않는다는 점이다. 대부분의 경우 모델은 상태를 내부적으로 지속하지 않으며, 매 턴마다 하네스가 작업 상태를 다시 조립한다. 이 작업 집합에는 대화 기록, 세션 상태, 메모리, 정책, 도구 정의 등이 포함될 수 있고, 모델은 하네스가 제공한 것만 볼 수 있다.
따라서 입력 중 하나가 빠져 있거나 오래된 상태라면, 모델의 답변은 여전히 그럴듯해 보일 수 있다. 그러나 답변의 일관성은 작업 집합이 완전했다는 증거가 아니다. 이 점은 생산 AI 시스템의 디버깅을 어렵게 만든다. 겉으로 보이는 답변이 자연스럽기 때문에 사람은 모델을 의심하기 쉽지만, 실제로는 모델에게 전달된 상태 자체가 결함을 품고 있었을 수 있다.
강연자는 타임아웃, 재시도, Idempotency(멱등성), 로그, 순서 보장, 상태 소유권 같은 문제들이 새로운 것이 아니라고 말한다. 다만 에이전트 환경에서는 이 오래된 분산 시스템 문제가 확률적 플래너와 결합하면서 더 자주 발생하고 설명하기 어려워진다. 에이전트는 매 턴마다 문맥을 다시 만들고, 더 많은 이벤트 소스에서 깨어나며, 더 많은 실행 표면을 통해 외부 세계에 영향을 미칠 수 있기 때문이다.
첫 번째 실패 모드: 상태 구멍과 소유권의 부재
첫 번째 실패 모드는 사용자가 성공을 보았지만 진실의 원천이 이를 재생할 수 없는 상태다. 강연자는 이를 “Delivered is not remembered”라는 형태로 설명한다. 예컨대 텔레그램 응답 전송은 성공했지만, 라우터 턴이 활성 문맥이나 대화 기록으로 되돌아오지 않았다면 사용자는 응답을 보았고 로그도 건강해 보일 수 있다. 그러나 다음 턴에는 해당 교환의 영속 기록이 존재하지 않는다.
06:52 - 응답 전송은 성공했지만 다음 턴의 지속 문맥에는 기록되지 않는 상태 구멍 사례를 설명하는 구간
이 문제의 핵심은 지능이 아니라 상태 소유권이다. 강연자가 말하는 소유자는 사람이 아니라, 영속 상태가 진실로 인정되는 시스템 오브 레코드(System of Record)를 뜻한다. 캘린더 이벤트는 캘린더 시스템에 속하고, 지원 티켓의 상태는 티켓팅 시스템에 속하며, 코드 변경은 워크스페이스나 저장소에 속한다. 대화 턴은 트랜스크립트에 속하고, 사용자 선호는 메모리 저장소에 속한다.
저장소가 바이트가 어디에 있는지를 말해준다면, 소유권은 누가 현실을 다시 판단할 수 있는지를 말해준다. 응답은 이름 붙은 소유자가 그것을 재생할 수 있을 때에만 신뢰할 수 있는 기억이 된다. 따라서 에이전트가 나중에 사용할 수 있는 모든 사실에 대해 “누가 이 사실을 소유하며, 어떻게 재생할 수 있는가”라는 질문을 던져야 한다. 이 질문에 답할 수 없다면 시스템은 그 사실을 안정적으로 기억한 것이 아니다.
두 번째 실패 모드: 겹치는 작성자와 잘못된 순서
상태의 소유자가 정해졌다면 다음 질문은 누가 어떤 순서로 그 상태를 바꿀 수 있는가다. 강연자는 두 개의 올바른 쓰기가 하나의 잘못된 결과를 만들 수 있다고 지적한다. 특히 Last Writer Wins(마지막 작성자 우선)는 일관성 모델이 아니며, 단지 충돌을 조용히 덮어버리는 방식에 가깝다.
강연자가 든 사례는 Load-Modify-Save 경쟁 조건이다. 두 호출자가 같은 오래된 상태를 읽고, 각각 다른 레코드를 수정한 뒤 저장한다. 두 작업은 각각 지역적으로는 올바르지만, 두 번째 저장이 첫 번째 변경을 조용히 지워버릴 수 있다. 사용자는 이미 해소된 약속이 다시 나타나거나, 심각한 중복 후속 조치가 발생하는 것처럼 경험할 수 있다.
08:52 - 두 작성자가 같은 상태를 수정하면서 하나의 변경이 다른 변경을 덮어쓰는 겹치는 작성자 문제를 설명하는 구간
여기서 필요한 불변식은 전체 시스템에서 동시성을 금지하는 것이 아니다. 병렬 읽기, 독립적인 검색, 여러 세션의 동시 실행, 하위 에이전트의 팬아웃은 여전히 가능하고 유용하다. 다만 하나의 변경 가능한 상태 경계에 대해서는 하나의 감사 커밋 경로가 있어야 한다. 구현은 큐, Mutex(뮤텍스), 트랜잭션, 락 등 무엇이든 될 수 있지만, 커밋 시점의 순서와 증거는 보존되어야 한다.
사용자는 큐나 락을 직접 보지 않는다. 대신 사용자는 마지막 수정이 사라지는 것을 건망증처럼 느끼고, 멈춘 세션을 죽은 것처럼 느끼며, 전달 전에 완료 처리된 작업을 혼란으로 경험한다. 그래서 순서 보장은 단순한 백엔드 구현 세부사항이 아니라 제품 경험의 일부다. 에이전트의 성격처럼 보이는 많은 문제가 사실은 순서 제어의 실패일 수 있다.
세 번째 실패 모드: 끝나지 않는 작업과 생명주기 관리
생산 환경에서 침묵은 중립 상태가 될 수 없다. 강연자는 실행이 결코 도착하지 않을 이벤트를 기다리는 상황을 생명주기 실패로 설명한다. 세션 안에 도구 호출은 존재하지만 그에 대응하는 도구 결과가 없다면, 프로세스가 죽었거나 연결이 끊겼거나 결과 기록 전에 타임아웃이 발생했을 수 있다. 원인은 디버깅에 중요하지만, 생산 장애의 본질은 더 단순하다. 런이 영원히 오지 않을 이벤트를 기다리고 있다는 것이다.
10:52 - 도구 호출 결과가 돌아오지 않아 세션이 멈추는 생명주기 실패와 타임아웃, Watchdog, 복구 명령의 필요성을 설명하는 구간
이 경우 새 메시지는 그 침묵 뒤에 줄을 서고, 사용자의 눈에는 에이전트가 그냥 멈춘 것처럼 보인다. 따라서 실행에는 Deadline(마감 시간)과 Cancellation(취소)이 필요하다. 마감 시간은 대기 시간을 제한하고, Watchdog(감시 프로세스)은 멈춘 작업을 보이게 만들며, 도구에는 타임아웃과 오류 결과가 있어야 한다. 또한 복구 명령은 자신이 해결하려는 멈춘 작업 뒤에서 기다리지 않아야 한다.
강연자는 모든 외부 경계에 반드시 끝이 있어야 한다고 말한다. 그 끝은 성공, 실패, 타임아웃, 취소, 최대 시도 횟수 도달 중 하나일 수 있다. 중요한 것은 영수증이 이 터미널 결과를 기록해야 한다는 점이다. 그래야 다음 단계가 앞선 작업이 성공했는지, 실패했는지, 아직 기다려야 하는지를 추측하지 않아도 된다.
네 번째 실패 모드: 권한은 기억이 아니라 실행 상태다
채팅이 실제 행동으로 바뀌는 순간, 기능 보유와 실행 권한은 분리되어야 한다. 모델은 액션을 요청할 수 있지만, 요청 가능성이 곧 권한을 의미하지는 않는다. 강연자는 승인 흐름에서 흔히 발생하는 오류를 “Approval Drift(승인 드리프트)”로 설명한다. 만료된 승인 콜백이 여전히 검색 가능한 상태처럼 남아 있고, 나중의 채널 작업을 막거나 잘못된 실행으로 이어지는 경우가 여기에 해당한다.
이 실수는 승인을 “사용자가 근처에 있었고 예를 눌렀다”는 모호한 기억처럼 다룰 때 발생한다. 강연자에 따르면 승인은 범위가 지정된 실행 상태다. 승인 객체는 누가, 어떤 세션과 런에서, 어떤 도구와 인자에 대해, 얼마나 오랫동안 승인했으며, 어떤 결과로 끝났는지를 답할 수 있어야 한다. 또한 해당 승인과 연결된 영수증을 가리켜야 한다.
12:20 - 승인 객체가 포함해야 할 실행 범위, 인자, 수명, 결과, 영수증 연결을 설명하는 구간
재시도, 재생, 채널 콜백 과정에서 이 필드들이 떨어져 나가면 하네스는 실행된 액션이 승인된 바로 그 액션이었다는 점을 더 이상 증명할 수 없다. 그래서 최소 권한은 도구 표면을 좁히고, 범위 지정 자격 증명은 올바른 신원이 사용되도록 하며, 승인과 감사는 실행 전후에 무엇이 일어났는지를 결정한다. 모델은 이 경계를 추론할 수는 있지만, 경계 그 자체가 되어서는 안 된다.
다섯 번째 실패 모드: 내부 성공은 사용자 가시 증거가 아니다
도구가 성공을 반환하더라도 사용자가 보는 표면에서는 결과가 나타나지 않을 수 있다. 강연자는 이를 “Missing Edge Proof(엣지 증거 누락)”로 설명한다. 메시지 도구가 웹 채팅이나 TUI(Text User Interface)에 대해 성공을 보고했지만 실제 메시지가 렌더링되지 않는다면, 내부 경로가 요청을 수락했다는 사실만 증명될 뿐 사용자가 결과를 봤다는 사실은 증명되지 않는다.
이 차이는 대화의 의미를 바꾼다. 에이전트는 나중에 “이미 보냈다”고 말할 수 있지만, 사용자는 진실하게 “나는 본 적이 없다”고 말할 수 있다. 내부 성공은 외부 증거가 아니다. 강연자가 강조하는 증명은 하나의 주장이나 단일 로그가 아니라 체인이다. 모델이 무엇을 제안했고, 정책이 무엇을 허용하거나 거부했으며, 에이전트가 무엇을 시도했고, 사용자 가시 경계가 어떤 결과를 확인했는지가 이어져야 한다.
13:54 - 내부 도구 성공과 사용자 가시 경계의 증거가 다르며 증명은 체인으로 남아야 한다는 설명 구간
트랜스크립트는 에이전트가 무엇을 말했는지를 기록한다. 도구 결과는 한 내부 컴포넌트가 무엇을 주장했는지를 기록한다. 그러나 진짜 영수증은 사용자가 실제로 중요하게 여기는 경계에서 무엇을 검증할 수 있는지를 보존해야 한다. 이 관점에서는 “성공 응답을 받았다”가 아니라 “사용자에게 보이는 결과가 확인되었다”가 생산 시스템의 완료 조건이 된다.
팀으로 돌아가 실행해야 할 감사 질문
강연자는 모든 에이전트 시스템을 한꺼번에 점검하려 하지 말고, 하나의 실제 생산 경로를 골라 영수증을 추적하라고 제안한다. 그 경로에서 무엇이 에이전트를 깨웠고, 어떤 상태를 물려받았으며, 어떤 권한을 사용했고, 무엇이 실행되었으며, 어떤 증거가 살아남았는지를 확인해야 한다. 이 질문들은 유창한 대화를 검사 가능한 생산 런으로 바꾸는 역할을 한다.
15:54 - 팀에서 실행할 감사 질문 중 무엇이 실행되었고 어떤 증거가 살아남았는지를 점검하는 구간
무엇이 에이전트를 깨웠는지를 알지 못하면 중복 제거, 순서, 권한 부여를 제대로 판단할 수 없다. 사용자의 메시지인지, 웹훅인지, 타이머인지, 도구 결과인지, 하위 에이전트인지, 재생 이벤트인지에 따라 해석해야 할 경계가 달라진다. 또한 모델이 물려받은 상태도 명확해야 한다. 트랜스크립트, 세션 상태, 메모리 스냅샷, 정책 버전, 도구 표면이 어떤 조합으로 제공되었는지가 모델의 사고 범위를 결정하기 때문이다.
권한에 대해서는 행위자, 세션, 도구, 런, 인자, 범위, 수명을 기록해야 한다. 모델의 요청은 권한이 아니며, 권한은 하나의 대기 중인 액션에 묶여야 한다. 실행에 대해서는 도구나 API 호출, 인자, 시도 횟수, Idempotency Key(멱등성 키), 외부 결과를 기록해야 한다. 마지막으로 살아남은 증거는 사용자가 실제로 신경 쓰는 경계에서 끝나야 한다. 티켓이 업데이트되었는지, 메시지가 렌더링되었는지, 파일이 변경되었는지, 캘린더 이벤트가 존재하는지가 그 예다.
더 나은 모델보다 먼저 필요한 더 나은 하네스
강연자는 마지막에 첫 사례를 다시 적용한다. 무엇이 에이전트를 깨웠는가라는 질문에는 사용자 메시지가 답이 되고, 무엇이 실행되었는가라는 질문에는 채널 전송이 답이 된다. 전달의 증거는 살아남았지만, 지속 가능한 턴의 기록은 살아남지 않았다. 바로 그 간극이 하네스 실패다.
이 사건에서 에이전트에게 더 나은 모델이 필요했던 것은 아니다. 모델에게 더 좋은 프롬프트가 필요했던 것도 아니다. 시스템에는 완전한 영수증을 남기는 더 나은 하네스가 필요했다. 더 나은 모델은 한 턴 안에서 도움을 줄 수 있지만, 턴을 넘어 시스템을 정상적으로 유지하는 것은 소유권, 순서, 생명주기, 권한, 증거다.
결국 텍스트가 행동이 되는 순간 질문은 바뀐다. 모델이 추론할 수 있는지만 물어서는 부족하다. 시스템이 상태를 소유하고, 변경을 순서화하고, 작업을 제한하고, 권한을 좁히고, 증거를 보존할 수 있는지를 물어야 한다. 하나의 루프는 한 턴에 답할 수 있지만, 생산 시스템을 운영하는 것은 하네스다.
마무리 / 핵심 정리
이 강연의 핵심은 에이전트 실패를 모델의 환각이나 추론 실패로만 해석하는 습관을 버려야 한다는 데 있다. 많은 생산 장애는 모델이 틀린 답을 해서가 아니라, 시스템이 상태를 잃어버리고, 쓰기 순서를 보장하지 못하고, 끝나지 않는 작업을 방치하며, 승인 범위를 흐리게 만들고, 사용자 가시 증거를 남기지 못해서 발생한다.
따라서 에이전트 신뢰성의 중심에는 하네스 설계가 있어야 한다. 상태는 소유자가 있어야 하고, 변경은 하나의 감사 가능한 커밋 경로를 지나야 하며, 모든 외부 작업은 끝을 가져야 한다. 권한은 실행 대상과 범위에 묶여야 하고, 성공은 내부 컴포넌트의 주장에 머물지 않고 사용자 경계에서 증명되어야 한다. 강연자가 반복한 “Own the state, order the mutation, and prove the action”은 에이전트 운영 시스템을 점검하는 가장 압축적인 기준이다.
📚 출처 및 참고
| 구분 | 내용 |
|---|---|
| 원본 영상 | Your Agent Didn’t Fail. Your Harness Did. — Vinoth Govindarajan, OpenAI |
| 채널 | AI Engineer |
| 리포트 작성 | 2026-07-30 |
| 작성 방식 | YouTube 영상 STT 변환 후 에디팅 |
💬 본 리포트는 영상 내용을 바탕으로 재구성되었습니다. 정확한 내용은 원본 영상을 참조해 주세요.