AI 에이전트 장애의 원인은 모델이 아니라 하네스 — OpenAI 엔지니어의 프로덕션 설계 강연 정리

핵심 메시지

• 프로덕션 에이전트 장애의 대부분은 모델의 환각이나 오답이 아니라, 모델을 둘러싼 실행 계층(하네스)의 설계 결함에서 발생한다.
• 가장 위험한 실패는 '조용한 성공'이다. 사용자에게는 정상으로 보이지만 시스템의 영구 기록에는 구멍이 남아, 다음 턴에서 잘못된 전제 위에 유창한 답이 쌓인다.
• 발표자가 제시한 계약은 간명하다. 모델은 제안하고, 하네스가 커밋하며, 영수증(receipt)이 그것을 증명한다.
• 기억할 세 가지는 상태를 소유하고, 변경을 순서대로 처리하고, 실행을 증명하는 것이다.
• 팀에 돌아가서 실제 운영 경로 하나를 골라 다섯 가지 질문으로 감사해 보면 하네스의 빈틈이 곧바로 드러난다.

쉽게 이해하기

AI Engineer 콘퍼런스 무대에 오른 OpenAI의 핵심 데이터·AI 인프라 담당 엔지니어는 도발적인 주장으로 강연을 시작했다. 프로덕션에서 벌어지는 에이전트 장애의 대부분은 에이전트나 모델의 실패가 아니라 '하네스(harness)'의 실패라는 것이다. 여기서 하네스란 모델을 둘러싸고 상태 전환, 권한 확인, 명령 실행, 기록 보존을 담당하는 결정론적 소프트웨어 계층을 가리킨다.

그가 제시한 첫 사례는 이렇다. 사용자가 상담원 에이전트에게 고객의 환불 요청을 기억해 달라고 했고, 에이전트는 다음 턴을 위해 기록했다고 답했다. 화면에는 오류도 경고도 없었다. 그러나 다음 턴에서 그 사실은 복원되지 않았다. 사용자는 성공을 경험했지만 시스템은 불완전한 현실을 물려받은 것이다. 발표자는 이런 '조용한 성공'이 차라리 크래시보다 위험하다고 말한다. 크래시는 최소한 경계를 알려주고 마지막 정상 지점부터 복구할 수 있지만, 조용한 성공은 거짓을 남기기 때문이다.

발표의 뼈대는 하나의 계약으로 요약된다. 모델은 메시지나 도구 호출, 편집, 명령을 제안할 수 있지만 모델은 프로덕션의 경계가 아니다. 상태 전환과 권한 확인, 순서가 지정된 커밋은 하네스가 담당하고, 영수증은 그 턴이 끝난 뒤에도 남는 증거다. 그는 모델을 자동차 엔진에 비유했다. 마력만 보고 양산차를 사는 사람은 없다. 핸들, 브레이크, 계기판, 블랙박스가 있어야 제어가 가능하다. 모델은 능력을 주고 하네스는 통제력을 준다.

강연은 실제 운영에서 반복되는 다섯 가지 실패 유형을 차례로 해부한다. 상태 소유권이 없어 전달은 됐지만 기억되지 않는 경우, 두 작성자가 같은 상태를 읽고 각자 수정해 나중 저장이 앞선 저장을 조용히 덮는 경우, 도구 호출은 있는데 그에 대응하는 결과가 없어 실행이 영원히 오지 않을 이벤트를 기다리는 경우, 만료된 승인이 여전히 유효한 것처럼 취급되는 경우, 그리고 내부 구성 요소는 성공을 보고했지만 사용자 화면에는 아무것도 뜨지 않은 경우다.

마지막으로 그는 청중에게 숙제를 남겼다. 모든 에이전트 시스템을 손대지 말고 실제 운영 경로 하나만 골라, 무엇이 이 실행을 깨웠는지, 어떤 상태를 물려받았는지, 어떤 권한을 근거로 삼았는지, 실제로 무엇이 실행됐는지, 그리고 어떤 증거가 남았는지를 물어보라는 것이다. 이 다섯 질문이 유창한 대화를 검토 가능한 프로덕션 시스템으로 바꿔 놓는다.

주요 인사이트

• 발표자는 이런 실패들이 새로운 종류가 아니라고 강조한다. 타임아웃, 재시도, 멱등성, 잠금, 순서 보장, 상태 소유권은 분산 시스템에서 이미 알려진 문제다. 달라진 점은 이 문제들이 매 턴 맥락을 새로 조립하는 확률적 계획기 주변에 쌓인다는 것이다.
• 에이전트는 사람처럼 기억하지 않는다. 하네스가 매 턴 작동 상태를 재구성해 넘겨줄 뿐이며, 모델은 하네스가 준 것만 볼 수 있다. 입력 하나가 누락되거나 낡았어도 답변은 여전히 논리적으로 들린다. 일관성은 작업 세트가 완전했다는 증거가 되지 못한다.
• 동시성을 없애라는 얘기가 아니다. 병렬 읽기와 독립 검색, 여러 세션 동시 실행은 모두 괜찮다. 규칙은 더 좁다. 하나의 가변 상태 경계에는 순서가 지정된 커밋 경로가 하나만 있어야 한다. 보수적으로 지킬 대상은 시스템 전체가 아니라 커밋 시점이다.
• 권한과 실행은 다르다. 모델은 작업을 요청할 수 있지만 요청 가능성이 곧 권한은 아니다. 승인은 '사용자가 예를 눌렀던 것 같다'는 막연한 기억이 아니라, 누가 어떤 세션에서 어떤 도구와 인수를 대상으로 얼마나 오래 승인했는지가 명시된 범위 있는 실행 권한이어야 하고 만료도 명확해야 한다.
• 내부의 성공은 외부의 증명이 아니다. 도구가 성공을 반환해도 사용자가 결과를 봤다는 뜻은 아니다. 증명은 주장이 아니라 연쇄다. 모델이 제안했고, 정책이 허용했고, 실행이 시도됐고, 사용자에게 보이는 경계에서 결과가 확인됐다는 사슬이 남아야 한다.

자주 묻는 질문

관련 AI 소식