OpenAI Codex 하네스 설계에서 먼저 봐야 할 것들: App Server, Responses API, 그리고 병목 | DAKER 커뮤니티
코딩 에이전트를 이야기할 때 흔히 모델 성능부터 떠올리게 됩니다. 하지만 이번 영상은 시선을 조금 다르게 돌립니다. 메시지를 보낸 뒤 실제로 무엇이 조립되고, 어떤 도구가 실행되며, 어디서 승인이 일어나고, 긴 대화가 어떻게 압축되는지가 더 큰 병목이 될 수 있다는 점을 설계 관점에서 짚습니다.
채널 Tech Bridge가 OpenAI 엔지니어 Dominik Kundel의 Codex 하네스 강연을 한글 자막으로 옮긴 약 20분 영상으로, 에이전트를 직접 만들거나 기존 도구를 고를 때 무엇을 먼저 봐야 하는지 정리해 볼 만한 내용입니다. 하네스는 Apache 2 오픈소스(Rust)이며, 발표자도 현재 상태라 모델 출시마다 바뀔 수 있다고 전제합니다.
영상 보기: https://www.youtube.com/watch?v=1eMDZjsVOh4
왜 프로토콜을 둘로 나눴을까
발표에서 먼저 눈에 띄는 부분은 프로토콜을 두 층으로 나눠 본다는 점입니다. 하나는 UI나 외부 클라이언트와 하네스 사이를 잇는 App Server이고, 다른 하나는 하네스와 추론 계층 사이를 잇는 Responses API입니다.
App Server는 Codex 앱도 같은 프로토콜을 쓰며, 커뮤니티 UI나 플러그인도 이 위에 올라갈 수 있다고 설명합니다. 반면 Responses API는 Chat Completions를 에이전트 환경에 맞게 다시 짠 형태로, 웹 검색이나 이미지 생성처럼 에이전트용 능력을 붙이는 역할을 맡습니다. 발표에서는 Ollama·LM Studio 등과도 스키마를 맞추려 했다고 말합니다.
직접 에이전트를 만들 때도 Codex를 통째로 쓰기보다, App Server와 Responses API라는 두 층을 블루프린트로 보는 것이 핵심입니다.
즉, 특정 제품 전체를 가져다 쓰는 문제라기보다, 어떤 경계에서 무엇을 맡길지 나누는 설계가 중요하다는 이야기입니다.
컨텍스트는 크기보다 조립 방식이 중요합니다
발표는 모델이 충분히 크더라도 컨텍스트가 어수선하면 쉽게 흔들릴 수 있다고 봅니다. 불필요한 토큰이 많거나 서로 충돌하는 정보가 함께 들어가면 모델이 헷갈리기 때문에, 무엇을 얼마나 넣을지 조립하는 과정이 핵심이라는 설명입니다.
이 맥락에서 Deferred tools가 등장합니다. 일부 도구는 처음부터 컨텍스트에 전부 넣지 않고, 필요할 때 tool search로 나중에 찾게 하는 방식입니다. 발표에 따르면 Responses API도 deferred loading을 지원합니다.
또 하나 흥미로운 대목은 스킬 목록 2% 캡입니다. 사용 가능한 스킬 설명이 최대 컨텍스트의 약 2%를 넘지 않게 줄여, MCP를 많이 설치해도 캐시 효율과 비용이 무너지지 않도록 한다고 설명합니다.
컨텍스트의 한계는 단순한 길이 문제가 아니라, 무엇을 미리 넣고 무엇을 나중에 찾게 할지의 문제입니다.
액션 실행은 하네스가 어떻게 다루는가
에이전트가 실제로 행동하는 단계에서는 하네스의 역할이 더 분명해집니다. 발표에서는 서브에이전트 생성과 입력, 백그라운드 터미널, 파일 수정 방식 등을 함께 설명합니다.
파일 작업은 apply_patch와 shell을 함께 쓰는 구조이며, 학습 과정에서 ripgrep을 선호했기 때문에 하네스가 ripgrep을 포함한다고 말합니다. Windows에서는 PowerShell을 쓰도록 학습됐다고도 설명합니다.
브라우저 사용 방식도 바뀌었습니다. 예전에는 한 번에 한 액션을 보내는 식이었다면, 이제는 코드 실행으로 Playwright식 스크립트를 지속적인 Node REPL에 쓰는 방향으로 진화했다고 합니다. 이 변화는 브라우저 자동화도 결국 더 긴 작업 흐름 안에서 다뤄야 한다는 점을 보여 줍니다.
샌드박스와 승인 피로
실행 권한이 커질수록 안전장치도 중요해집니다. 발표에서는 macOS는 Seatbelt, Linux는 Bubblewrap, Windows는 같은 GitHub 저장소에 있는 자체 오픈소스 샌드박스를 사용한다고 설명합니다.
여기에 Auto Review도 더해집니다. full access 환경에서 승인 요청이 너무 자주 뜨면 사용성이 떨어지기 때문에, 읽기 전용 서브에이전트가 위험 분류와 맥락을 보고 일부 승격을 자동 승인해 승인 피로를 줄인다는 설명입니다. 다만 데이터 유출 같은 문제는 막아야 하므로, 편의성과 통제 사이의 균형을 맞추려는 설계로 이해할 수 있습니다. 발표자는 세부 설계는 별도 블로그를 보라고 안내합니다.
에이전트의 실행력은 단순히 더 많은 권한을 주는 데서 나오지 않고, 샌드박스와 승인 흐름을 어떻게 설계하느냐에 달려 있습니다.
속도 병목은 추론이 아닐 수도 있습니다
이 영상에서 특히 인상적인 부분은 속도 병목에 대한 설명입니다. 발표에 따르면 GPT-5.3 Codex Spark가 Cerebras에서 초당 약 1000토큰일 때, 병목은 추론이 아니라 네트워크였습니다.
그래서 Responses API에 WebSocket 모드를 넣었다고 설명합니다. SSE/HTTP 대신 연결 상태를 유지하고, 전체를 반복해서 보내는 대신 바뀐 항목만 전송해 오버헤드를 줄이는 방식입니다. 예를 들어 툴 결과처럼 일부 상태만 달라질 때 이 차이가 커질 수 있습니다.
장시간 실행을 위한 장치로는 /goal 연속 루프와 서버 사이드 auto compaction도 언급됩니다. 목표가 달성될 때까지 continuation을 이어 가는 구조이며, goal은 검증 가능한 짧은 문장으로 쓰라고 강조합니다.
모델이 빨라질수록 오히려 네트워크와 상태 전송 방식이 더 먼저 병목이 될 수 있습니다.
오늘 가져갈 한 가지
이 발표의 요지는 분명합니다. 코딩 에이전트를 만들거나 고를 때 더 큰 모델만 볼 일이 아니라는 점입니다. 실제 병목은 컨텍스트 상한, 지연 로딩, 샌드박스, 승인 흐름, 전송 프로토콜에서 먼저 드러날 수 있습니다.
발표 마무리도 같은 방향을 가리킵니다. 하네스와 App Server는 오픈소스 블루프린트로 보고, tool search·apply patch·WebSocket·서버 compaction 같은 Responses API 기능은 하네스와 무관하게 활용할 수 있다는 점을 함께 보라는 이야기입니다. 모델이 바뀔 때마다 API와 Codex의 진화를 따라가는 시각이 필요하다는 뜻이기도 합니다.
참고 자료
제목: [한글자막] OpenAI는 왜 코딩 에이전트 하네스를 이렇게 설계했을까요?
채널: Tech Bridge (@TechBridge-KR)
유튜브: https://www.youtube.com/watch?v=1eMDZjsVOh4
여러분은 코딩 에이전트를 볼 때 모델 성능보다 먼저 확인하는 병목이 무엇인지 궁금합니다.