1. 충돌보다 조용한 성공이 나쁘다

OpenAI에서 핵심 데이터·AI 인프라를 다루는 발표자가 프로덕션 에이전트 실패를 주제로 발표했다. 이전에는 애플과 우버에서 분산 시스템을 만들었고 「The Agent Stack」이라는 블로그를 쓴다.

발표를 여는 사고는 이렇다. 사용자가 고객 환불 건을 다음 턴을 위해 기억해 달라고 했고 어시스턴트는 기록했다고 답했다. 화면은 정상이었다. 빨간 오류도 눈에 띄는 실패도 없었다. 그런데 다음 턴에서 그 사실을 다시 불러오지 못했다.

충돌은 성가시지만 적어도 경계를 준다. 무언가 멈췄다는 것을 알 수 있고 마지막 정상 지점에서 다시 시작할 수 있다. 조용한 성공은 그 경계를 안 준다. 전달은 성공했고 저장은 실패했는데 사용자에게도 운영자에게도 의심할 이유가 없다.

다음 턴에도 모델은 여전히 그럴듯하게 말한다. 일관돼 보이지만 끊긴 이력 위에서 일관된 것뿐이다.

발표는 *오픈클로를 예로 쓴다. 홍보가 아니라 이슈와 코드와 문서가 공개돼 있어 하니스 구조가 유난히 잘 들여다보이기 때문이라고 밝힌다.

2. 계약 한 줄

이 발표의 문장은 하나다. 모델은 제안하고 하니스는 확정하며 영수증이 그것을 증명한다.

모델은 메시지와 툴 호출과 수정과 명령을 제안할 수 있다. 그러나 그 자체로 프로덕션의 경계는 아니다. 상태 전환, 권한 검사, 순서 있는 커밋, 영수증은 *하니스의 몫이다.

대화 기록은 증거가 아니다. 기록은 에이전트가 무엇이라고 말했는지를 남기고, *영수증은 시스템이 실제로 무엇을 했는지를 남긴다.

발표자가 든 비유는 자동차다. 모델은 엔진이다. 강력하지만 아무도 마력만 보고 프로덕션용 차를 사지 않는다. 조향과 제동과 도로 규칙과 계기판과 블랙박스도 본다. 모델은 능력을 주고 하니스는 통제를 준다. 브레이크 없는 강력한 엔진은 자율이 아니라 가속도만 좋은 부채다.

3. 하니스는 무엇으로 이루어져 있나

에이전트를 깨우는 신호는 한 곳에서만 오지 않는다. 사람이 친 채팅도 있고, 다른 시스템이 보낸 알림도 있고, 시간이 되어 울린 타이머도 있고, 살아 있는지 확인하는 신호도 있다.

그래서 하니스가 맨 처음 하는 일이 정해진다. 들어온 신호가 어느 대화의 것인지 이름표를 붙이는 것이다. 발표에서 세션 키라고 부르는 것이 그 이름표다.

이름표 하나가 곧 울타리가 된다. 그 대화에 딸린 기록과 메모리와 정책이 그 울타리 안에 든다. 그리고 울타리 안의 것을 고치는 문은 하나로 둔다. 두 곳에서 동시에 고치는 일을 막으려는 것이고, 이 문을 하나로 안 두면 뒤에 나오는 「겹친 기록자」 사고가 난다.

그 뒤는 단순하다. 모델과 도구를 부르고, 도구는 승인과 정책을 지나서야 실행되고, 그 실행이 남긴 기록이 영수증이 된다. 개인 비서형이든 코딩 에이전트든 이 밑구조는 같다고 발표자는 말한다.

여기서 하나 더 짚을 것이 있다. 에이전트는 사람처럼 기억하지 않는다. 턴이 끝나면 잊으므로 하니스가 매 턴 필요한 것을 다시 모아 넘긴다. 대화 기록과 세션 상태와 메모리와 정책과 도구 목록이 그것이다. 모델은 넘겨받은 것만 보므로, 하나가 빠지거나 낡아도 답은 여전히 그럴듯하게 들린다.

타임아웃과 재시도와 *멱등성과 락과 순서는 새 문제가 아니다. 달라진 것은 환경이다. 모델이 매 턴 계획을 새로 세우고 넘길 것을 다시 모으는 데다, 깨우는 신호도 손댈 곳도 늘었다. 그래서 같은 실패가 더 쉽게 터지고 원인을 대기는 더 어려워졌다.

4. 사고 다섯, 빠진 경계 다섯

발표는 오픈클로에서 실제로 열렸던 이슈 다섯 건을 든다. 다섯 다 사용자 화면에는 문제가 없었다.

사고 다섯 건과 그때 빠져 있던 경계

여기서 소유자는 사람이 아니라 그 사실이 진실이 되는 시스템을 뜻한다. 달력 일정은 달력 시스템이, 상담 상태는 티켓 시스템이, 코드 변경은 저장소가, 대화 턴은 세션 기록이, 사용자 선호는 메모리 저장소가 소유한다. 저장은 바이트가 어디 있는지를 말하고 소유권은 누가 그 실재를 재구성할 수 있는지를 말한다.

순서 규칙은 좁고 단순하다. 가변 상태 경계 하나에 순서가 정해진 커밋 경로 하나. 동시성 자체를 없애자는 말이 아니다. 병렬 읽기도 독립적인 검색도 여러 세션 동시 실행도 서브 에이전트로 나누는 것도 괜찮다. 보수적으로 지킬 것은 커밋 시점이지 시스템 전체가 아니다.

승인은 막연한 기억이 아니라 범위가 한정된 실행 상태여야 한다. 쓸모 있는 승인 객체는 누가, 어떤 세션과 실행에서, 어떤 툴과 인자에 대해, 얼마 동안, 어떤 결과로 승인했는지에 답하고 영수증을 가리킨다. 그 필드가 재시도나 재생 도중 떨어져 나가면 하니스는 그 행동이 승인된 것임을 더 이상 증명할 수 없다.

5. 증명은 주장이 아니라 사슬이다

내부 성공은 외부 증명이 아니다. 툴 결과는 내부 경로가 요청을 받아들였다는 것만 증명한다. 사용자가 그것을 봤다는 것은 증명하지 못한다.

그 차이가 대화를 바꾼다. 에이전트는 나중에 이미 보냈다고 말할 수 있고 사용자는 정말로 본 적 없다고 말할 수 있다. 영수증은 사용자가 신경 쓰는 그 경계에서 끝나야 한다.

6. 프로덕션 자취 하나에 물을 다섯 가지

발표자는 팀에 돌아가 모든 에이전트가 아니라 하나만 골라 실제 프로덕션 경로 하나의 자취를 놓고 영수증을 요구해 보라고 제안한다.

감사에 쓸 다섯 질문

이 다섯을 맨 처음 사고에 대 보면 이렇게 된다. 깨운 것은 사용자 메시지, 물려받은 상태가 곧 깨진 경계, 실행된 것은 채널 전송이었다. 살아남은 증거는 전달뿐이고 지속된 턴은 아니었다. 그 에이전트에 필요했던 것은 더 나은 모델도 더 나은 프롬프트도 아니고 완전한 영수증을 갖춘 더 나은 하니스였다.

발표는 루프가 한 턴에 답할 수 있지만 하니스라야 프로덕션을 지탱한다는 문장으로 끝난다.

7. 발표가 밝히지 않은 것

발표자는 OpenAI 에이전트 *SDK에 이런 하니스 요소가 이미 들어 있다고 소개한다. 자기 회사 제품을 파는 대목이라 그대로 받지 않는 편이 좋다.

숫자가 없다. 사고는 다섯 건 다 공개 이슈를 가리키지만 얼마나 자주 났고 얼마나 많은 사용자가 겪었는지는 나오지 않는다.

영수증을 어디에 얼마나 오래 남기는지, 그 저장과 조회에 얼마가 드는지도 다루지 않는다. 모든 실행 경계에 영수증을 남기라는 요구는 기록량이 실행량을 따라 늘어난다는 뜻인데, 그 비용이 이 설계의 실제 문턱이다.

일반화의 근거가 얇다. 개인 비서형(오픈클로·Hermes)과 코딩 에이전트(코덱스·커서·오픈코드·클로드 코드)가 같은 밑구조를 쓴다고 발표자는 말하지만, 사고 사례로 든 이슈는 오픈클로 것뿐이다. 같은 다섯 경계가 다른 시스템에서도 같은 순서로 무너지는지는 이 발표만으로 알 수 없다.