OpenAI Codex 코딩 에이전트 하네스의 설계 원리

URL: https://www.youtube.com/watch?v=1eMDZjsVOh4 날짜: 2026-08-18 채널: Tech Bridge

---

📌 핵심 질문 / 이 영상이 다루는 핵심 논점

==코딩 에이전트의 성능은 모델 자체뿐 아니라 컨텍스트를 조립하고, 도구를 실행하고, 안전을 검토하고, 긴 작업을 이어 가는 하네스(Harness)의 설계에서 결정된다.==

• Codex는 UI와 하네스 사이의 App Server 프로토콜, 하네스와 추론 모델 사이의 Responses API라는 두 개방형 계층으로 구성된다.
• 컨텍스트 크기와 비용을 통제하기 위해 지연 도구(Deferred Tools), Tool Search, 스킬 목록 2% 캡을 사용한다.
• 서브에이전트, 지속적인 브라우저 실행 환경, 파일 시스템 샌드박스, Auto Review가 에이전트의 행동 범위와 안전성을 구성한다.
• 초고속 추론에서는 네트워크가 병목이 되므로 WebSocket의 상태 유지와 변경분 전송이 중요해진다.
• 구체적이고 검증 가능한 목표, 자동 루프, 서버 측 Auto Compaction이 장시간 실행을 가능하게 한다.

OpenAI의 Codex 하네스는 에이전트를 단순히 모델에 도구 몇 개를 붙인 시스템으로 다루지 않는다. 컨텍스트가 커질수록 비용과 모순 정보가 늘어나는 문제, 플러그인과 MCP가 늘어날 때의 확장성, 파일·네트워크 조작의 위험, 수많은 도구 호출의 지연, 수시간에서 수일에 걸친 작업의 지속성을 각각 별도의 프로토콜과 실행 계층으로 해결한다. 하네스와 Responses API가 모두 공개되어 있으므로 같은 원리를 자체 에이전트에 적용하거나 Codex 하네스 자체를 기반으로 확장할 수 있다.

1. 발표의 범위와 Codex 하네스의 공개성

1.1. 에이전트를 이미 만드는 개발자를 위한 20분 압축 설명

1. 대상의 선택

   1. 청중: 자신의 에이전트를 만들었거나 현재 만들고 있는 개발자들을 대상으로 삼는다.
   2. 설명의 초점: AI 에이전트의 정의나 기본 작동 원리는 건너뛰고, 메시지를 보낸 뒤 Codex 하네스에서 실제로 무슨 일이 일어나는지와 다른 에이전트에 적용할 수 있는 핵심 기능을 다룬다.

2. 빠른 진행의 이유

   1. 콘텐츠의 양: 약 20분 안에 많은 내용을 전달하기 위해 거의 2배 속도로 말하겠다고 미리 알린다.
   2. 행사 맥락: AI Engineer World's Fair의 엔지니어링 트랙에 맞춰 개념 설명보다 구현상의 어려움과 해결책에 시간을 쓴다.

1.2. 오픈 소스 하네스라는 출발점

1. 공개 라이선스와 구현 언어

   1. Apache 2 라이선스: Codex 하네스와 시연되는 구성 요소는 오픈 소스로 공개되어 있다.
   2. Rust 구현: 공개 저장소의 하네스는 Rust로 작성되어 있어 코드를 직접 읽거나 Codex에게 더 깊은 질문을 하거나 포크해서 자기 방식으로 바꿀 수 있다.

2. 빠르게 변하는 현재 상태

   1. 모델과 API의 변화: 새 모델이 출시될 때마다 새 API가 추가되고 하네스의 동작 방식도 바뀔 수 있으므로, 현재 설명을 영구적인 사양으로 받아들이면 안 된다.
   2. 자체 에이전트의 갱신: 최신 상태는 Codex에 다시 확인하고, 모델과 Responses API의 변화에 맞춰 자신의 에이전트도 갱신해야 한다.

2. UI에서 추론까지 이어지는 두 개의 개방형 프로토콜

2.1. App Server 프로토콜: UI와 하네스 사이

1. 메시지의 첫 번째 이동

   1. App Server: 사용자가 UI에서 보낸 메시지는 App Server 프로토콜을 통해 하네스로 들어온다.
   2. Codex 앱의 기반: Codex 앱도 동일한 App Server를 사용하므로 Codex가 제공하는 기능을 거의 그대로 활용할 수 있다.

2. 다양한 클라이언트로의 확장

   1. 자체 UI: 개발자가 직접 UI나 에이전트 인터페이스를 만들 때 App Server 프로토콜 위에 구축할 수 있다.
   2. 커뮤니티 프로젝트: Theo의 T3 Code와 Remote X 같은 제3자 프로젝트도 이 프로토콜 위에서 동작한다.
   3. 외부 도구에 Codex 삽입: 같은 App Server를 이용해 Claude Code에 Codex를 넣는 플러그인도 만들 수 있다.
   4. 실험적 인터페이스: 전날 발표에서는 App Server 프로토콜을 이용해 Doom 안에 Codex를 넣는 실험도 진행했으며, 게임 안에서 에이전트를 실행하는 재미있는 사례가 되었다.

2.2. Responses API: 하네스와 추론 사이

1. Chat Completions에서 에이전트 중심 API로의 전환

   1. 재설계의 시점: Responses API는 전년도에 Chat Completions API를 에이전트 중심 세계에 맞게 다시 생각한 결과로 출시되었다.
   2. 구조와 능력의 변화: 메시지 구조를 일부 재설계했을 뿐 아니라 웹 검색(Web Search), 이미지 생성(Image Generation) 같은 에이전트용 복합 기능을 추가했다.

2. 개방형 Responses 생태계

   1. 파트너 협력: Ollama, LM Studio, Nvidia 등을 포함한 파트너들과 개방형 Responses 스키마를 정리했다.
   2. 거버넌스: 다른 기업과 플랫폼도 같은 스키마를 구현할 수 있도록 거버넌스 조직을 마련했다.
   3. 교체 가능한 제공자: Responses API와 호환되는 모델 제공자나 하네스를 선택해 Codex 하네스에 연결할 수 있다.

2.3. 전체 요청 경로

1. 두 계층의 역할 분리

   1. 첫 번째 구간: UI에서 App Server 프로토콜을 거쳐 에이전트 하네스로 이동한다.
   2. 두 번째 구간: 하네스에서 Responses API를 거쳐 언어 모델(LLM) 추론 계층으로 이동한다.

2. 재사용의 의미

   1. 하네스의 선택: 개발자는 공개 Codex 하네스를 그대로 사용하거나 App Server 위에 자신의 UI를 만들 수 있다.
   2. API 기능의 선택: 자체 하네스를 만들더라도 Tool Search, 컴퓨터 사용을 위한 코드 실행, WebSocket, 서버 측 압축 같은 Responses API 기능은 독립적으로 활용할 수 있다.

3. 컨텍스트 구성: 크기·유연성·성능의 균형

3.1. 컨텍스트가 많다고 항상 좋은 것은 아니다

1. 크기(Size)의 통제

   1. 토큰 예산: 불필요한 콘텐츠를 대량으로 넣어 토큰 예산을 소진하지 않도록 해야 한다.
   2. 모순 정보: 컨텍스트가 커질수록 서로 충돌하는 정보가 포함될 확률이 올라가며, 모델이 혼란을 겪을 가능성도 커진다.

2. 유연성(Flexibility)의 보장

   1. 기능 수의 변화: 사용하는 스킬의 수가 적거나 많아도 일관된 경험을 제공해야 한다.
   2. 플러그인과 MCP: 플러그인과 MCP를 설치할수록 도구 레지스트리와 관련 설명이 커지므로, 설치 수가 컨텍스트 품질을 무너뜨리지 않게 처리해야 한다.

3. 성능과 비용(Performance and Cost)

   1. 비용 민감성: 에이전트 사용자는 비용에 민감하므로 모든 요청마다 동일한 큰 컨텍스트를 재전송하면 안 된다.
   2. 캐시 가능성(Cacheability): 안정적인 부분을 캐시할 수 있도록 컨텍스트를 구성해야 네트워크와 추론 비용을 낮출 수 있다.

3.2. Nano Codex로 보는 정적·동적 컨텍스트

1. 시연용 구현

   1. 동일한 동작: 공개 저장소의 Codex 코드와 같은 방식으로 작동하는 작은 Nano Codex를 만들었다.
   2. TypeScript 변환: 공개 Rust 구현의 원리를 TypeScript로 옮겨 컨텍스트가 조립되는 각 부분을 눈으로 확인할 수 있게 했다.

2. 예측 가능한 부분과 변하는 부분

   1. 모델 지침(Model Instructions): 비교적 표준적이고 구조화되어 있으며 크기가 크게 변하지 않아 캐시 가능성을 흔들지 않는다.
   2. 스킬 목록: 사용자가 몇 개의 스킬을 설치했는지에 따라 크기가 달라진다.
   3. 도구 레지스트리(Tool Registry): MCP를 더 설치하면 사용할 도구와 설명이 추가되어 계속 커진다.

3.3. Deferred Tools와 Tool Search

1. 도구 지연 로딩(Deferred Tools)

   1. 컨텍스트에서 제외: 일부 도구를 deferred로 표시해 초기 컨텍스트 윈도우에 도구 정의를 직접 넣지 않는다.
   2. 필요할 때 검색: 모델이 나중에 Tool Search를 호출할 때만 해당 도구를 찾아 사용할 수 있게 한다.

2. 스킬 설명의 2% 상한

   1. 최대 컨텍스트 기준: 사용 가능한 스킬 목록은 모델의 최대 컨텍스트 윈도우 중 2%를 넘지 않게 제한한다.
   2. 설명 축약: 스킬이 더 많아져 한도를 넘으면 목록을 무한히 늘리는 대신 각 스킬 설명에 할당하는 정보량을 점진적으로 줄인다.

3. 자체 하네스에서의 재사용

   1. Responses API 기능: GPT-5.4부터 Tool Search를 Responses API에서 사용할 수 있다.
   2. 지연 도구 표시: 어떤 도구든 deferred loading으로 표시할 수 있다.
   3. 검색 구현의 선택: OpenAI가 제공하는 기본 Tool Search 도구를 사용하거나, 개발자가 더 나은 발견 로직을 구현해 자체 검색 도구로 대체할 수 있다.

4. 에이전트가 행동을 수행하는 세 가지 실행 계층

4.1. 비동기 행동과 서브에이전트

1. 메인 에이전트와 작업 위임

   1. Spawn Agent 도구: 메인 에이전트가 새 에이전트 인스턴스를 만들어 특정 작업을 위임할 수 있다.
   2. Send Input 도구: 생성된 에이전트에 새 입력을 보내 추가 지시를 전달한다.
   3. 대기와 종료: 메인 에이전트는 서브에이전트가 끝나기를 기다리거나, 필요하면 새 인스턴스를 종료할 수 있다.

2. 백그라운드 터미널

   1. 동일한 위임 개념: 백그라운드 터미널도 별도의 작업 실행 인스턴스를 만드는 방식으로 처리한다.
   2. 지속적인 상호작용: 새 프로세스의 표준 입력(stdin)에 데이터를 계속 보내며 명령을 이어 갈 수 있다.
   3. 완료 대기: 일정 시간 기다리거나 작업 완료를 확인한 뒤 결과를 회수한다.

4.2. 컴퓨터 사용과 브라우저 자동화

1. 초기 Computer Use의 제약

   1. 단일 행동: Responses API에 컴퓨터 사용 기능이 처음 도입됐을 때는 한 번에 한 행동만 수행할 수 있었다.
   2. 고정된 구현 부담: 컴퓨터 사용을 명시적으로 선언한 뒤 도구가 노출하는 특정 행동 유형을 개발자가 직접 구현해야 했다.

2. 코드 실행 기반의 변화

   1. 최근 모델과 API: 최신 모델과 API 형태는 컴퓨터 사용을 별도의 고정 행동 목록 대신 코드 실행으로 처리할 수 있게 했다.
   2. 스크립트 작성: 에이전트가 사용하려는 컴퓨터 구현에 맞춰 JavaScript나 Python으로 상호작용 스크립트를 직접 작성한다.
   3. 하네스의 유연성: 도구가 미리 정의한 한 행동씩의 인터페이스보다 훨씬 유연하게 복합 상호작용을 구성할 수 있다.

3. 브라우저 사용의 실제 구조

   1. 지속적인 Node REPL: Codex는 여러 턴에 걸쳐 상태가 보존되는 Node REPL에 접속해 브라우저를 조작한다.
   2. JavaScript와 Playwright식 조작: 브라우저 인스턴스에 상호작용하기 위한 JavaScript를 REPL에 작성하고 실행한다.
   3. 첫 번째 탐색: Chromium 브라우저의 현재 상태를 확인하고 필요한 탭을 찾는 코드를 처음 실행한다.
   4. 후속 재사용: 다음 턴부터는 이미 열린 탭을 참조하고 필요한 정보를 가져오며, 브라우저 구조를 이해한 상태에서 후속 행동을 스크립트로 작성한다.

4. 속도와 반복 작업의 이점

   1. 구조 파악 후 자동화: 한 페이지의 구조를 먼저 확인하면 같은 구조를 가진 다음 페이지에서 필요한 동작을 더 쉽게 작성할 수 있다.
   2. 스크래핑 사례: 첫 페이지를 분석한 뒤 후속 페이지의 정보 수집을 코드로 반복할 수 있어 브라우저 행동이 크게 빨라진다.

4.3. 파일 시스템과 운영체제별 샌드박스

1. 파일 편집의 기본 도구

   1. Apply Patch: GPT-5부터 최근 모델들은 diff 형태로 파일을 수정하는 Apply Patch 도구를 학습했으며, 같은 방식으로 새 파일도 만들 수 있다.
   2. Shell: 파일 검색과 디렉터리 이동 등 나머지 파일 시스템 탐색은 Shell 도구로 처리한다.
   3. Ripgrep: 모델은 학습 과정에서 익숙해진 Ripgrep을 자연스럽게 사용하므로, Codex 하네스는 사용자의 시스템에 Ripgrep이 없더라도 함께 제공한다.
   4. Windows PowerShell: Windows 환경에서는 모델이 PowerShell을 기본 방식으로 사용하도록 학습되어 PowerShell 명령을 작성한다.

2. 운영체제별 격리

   1. macOS: 파일 시스템 상호작용은 Seatbelt 샌드박스를 통과한다.
   2. Linux: Linux에서는 Bubblewrap을 사용한다.
   3. Windows: 기존 대안만으로 충분하지 않아 별도의 맞춤형 오픈 소스 Windows 샌드박스를 만들었으며, 같은 GitHub 저장소에서 확인할 수 있다.

3. Windows 샌드박스의 배경

   1. 복잡한 대안 검토: Windows에서 자체 샌드박스를 만든 데에는 여러 이유가 있으며, 운영체제의 다른 격리 대안을 검토한 결과다.
   2. 추가 자료: Windows 내부 동작과 대안 비교를 깊이 이해하려면 David가 작성한 별도 글을 참고할 수 있다.

5. 승인 피로를 줄이는 Auto Review와 위험 판단

5.1. Full Access가 만드는 두 종류의 문제

1. 승인 피로(Approval Fatigue)

   1. 장시간 작업의 부담: 긴 작업에서 모든 파일·명령 승인을 계속 요구하면 사용자는 지치고 결국 Full Access 모드를 켜게 된다.
   2. 보안팀의 우려: 개발자는 편의를 위해 Full Access를 켜고 싶어 하지만 IT와 보안팀은 그 선택을 싫어한다.

2. 높은 자율성의 오해 가능성

   1. 지시와 실제 행동의 불일치: 모델이 좋아졌더라도 높은 자율성을 요구하는 프롬프트를 사용하면 모델의 해석이 사용자의 의도와 어긋날 수 있다.
   2. 파일 전송 사례: 사용자가 파일을 이메일로 보내라고 했는데 첨부할 수 없다는 이유로 파일 공유 서비스에 업로드해 링크를 대신 보낼 수 있다.
   3. 삭제 사고: 명령의 이스케이프 처리를 잘못해 의도한 범위보다 많은 데이터를 실수로 삭제할 수 있다.

5.2. Auto Review의 목표와 범위

1. 자동 승인과 제한의 결합

   1. 예측하기 어려운 행동 처리: 장시간 실행 중 에이전트가 할 법한 판단하기 어려운 행동은 Auto Review가 자동으로 검토하고 승인할 수 있게 한다.
   2. 데이터 반출의 제외: 모든 위험한 행동을 무조건 자동 승인하지 않고 데이터 엑스필트레이션(Data Exfiltration)은 자동 승인 범위 밖에 둔다.

2. 샌드박스에서 승인 요청이 발생하는 순간

   1. 트리거: 샌드박스 안에서 파일 삭제 같은 작업이 추가 권한을 요청하면 Auto Review 서브에이전트를 만든다.
   2. 완전한 분리: Auto Review 서브에이전트는 별도 실행되며 다른 서브에이전트를 생성할 수 없다.
   3. 읽기 전용: 판단을 위한 읽기 권한만 가지므로 스스로 문제의 행동을 실행하거나 권한을 확장하지 않는다.

5.3. 사용자 승인·위험 분류·실행 맥락

1. 판단에 제공되는 정보

   1. 사용자 권한 부여: 사용자가 무엇을 명시적으로 요청했는지에 관한 컨텍스트를 제공한다.
   2. 위험 분류 체계: 각 행동의 위험을 어떻게 분류하고 평가할지에 대한 위험 taxonomy를 제공한다.
   3. 전체 실행 맥락: 실제 트랜스크립트와 실행 중인 도구 호출을 함께 전달한다.

2. 같은 행동도 맥락에 따라 달라지는 판단

   1. 명시적 삭제: 사용자가 파일 삭제를 직접 요청했다면 사용자 권한 부여 수준은 높다.
   2. 프로젝트의 일부인 삭제: 사용자가 프로젝트 정리를 요청했고 그 과정에서 특정 파일을 지우는 것이라면 허용될 수 있다.
   3. .git 폴더 보호: 삭제를 요청하지 않았는데 .git 폴더를 지우면 프로젝트의 전체 이력과 버전 관리 기록을 없애므로 승인하면 안 된다.

3. 행동별 영향 평가

   1. 파일 시스템: 삭제가 실제로 어떤 범위와 영향을 갖는지 평가한다.
   2. 네트워크: 인터넷 연결 확인을 위해 Google에 curl 요청을 보내는 것은 괜찮을 수 있지만, 파일을 외부로 업로드하는 것은 별도의 높은 위험으로 본다.
   3. 결론 도출: 사용자 승인 수준, 행동의 영향, 허용할 다음 행동을 종합해 승인·거부 판단을 내린다.

4. 설계의 현재 범위

   1. 단순화된 설명: 짧은 시연에서 설명한 판단 과정은 엔지니어링 팀과 연구팀이 수행한 전체 작업을 크게 단순화한 것이다.
   2. 추가 학습: 상세한 위험 분류와 Auto Review 설계는 OpenAI의 Auto Review 블로그 글에서 확인할 수 있다.

6. 초고속 추론 환경에서 네트워크를 줄이는 WebSocket

6.1. 병목의 이동

1. 도구 호출이 만드는 지연
   1. 추론 속도만으로 부족: 에이전트는 많은 도구 호출과 상호작용을 수행하므로 모델 추론을 빠르게 만드는 작업은 전체 지연의 일부만 해결한다.
   2. GPT-5.3 Codex Spark 사례: Cerebras에서 초당 1,000토큰으로 실행되는 GPT-5.3 Codex Spark를 출시하면서 추론이 더 이상 가장 큰 병목이 아닐 수 있음을 확인했다.
   3. 네트워크 병목: 모델이 결과를 빠르게 생성한 뒤에도 HTTP 왕복과 반복 데이터 전송이 남아 실제 병목이 네트워크로 이동한다.

6.2. WebSocket 모드의 동작

1. 연결 방식의 전환

   1. 기존 방식: Responses API는 Server-Sent Events(SSE)와 HTTP를 통해 요청과 이벤트를 주고받았다.
   2. 새 방식: WebSocket 모드는 지속적인 연결을 유지해 네트워크 오버헤드를 줄인다.

2. 상태 있는 컨텍스트

   1. 변경분만 전송: 연결이 상태를 유지하므로 매번 모든 컨텍스트 아이템을 다시 보내지 않고 실제로 바뀐 데이터만 보낸다.
   2. 도구 결과의 예: 도구 호출 뒤에는 전체 아이템 목록이 아니라 새로 생성된 도구 호출 결과만 반환한다.
   3. 성능 영향: 반복 호출이 누적될수록 전송량과 왕복 시간이 줄어 성능이 크게 개선될 수 있다.

3. 시연에서 확인한 전송량

   1. 백업 데모: 실제 데모 서버가 중간에 크래시했지만, 백업 데모로 동일한 동작을 이어 갔다. 서버가 실제 데이터를 사용하고 있었다는 점도 드러났다.
   2. 항목 단위 전송: 한 번에 9개 아이템을 다시 보내는 대신 아이템을 하나씩 이어서 보낸다.
   3. 지속 효과: 한 번의 차이는 작아 보여도 도구 호출이 이어지는 장시간 작업에서는 상당한 속도 차이를 만든다.

7. /goal 루프와 검증 가능한 목표

7.1. 자동 연속 실행의 구조

1. 목표 달성까지 이어지는 작업

   1. 호출된 목표: 숫자를 맞히는 간단한 데모에서는 정답 숫자를 맞혀야만 전체 목표를 달성한 것으로 본다.
   2. 자동 continuation prompt: 목표가 끝나지 않은 동안 하네스가 다음 작업을 계속하도록 continuation prompt를 자동으로 주입한다.
   3. 목표의 재주입: continuation prompt 안에는 사용자가 설정한 객관적인 목표가 포함된다.

2. 종료 조건

   1. 도구 호출 기반 종료: 모델이 update_plan 또는 update_goal 도구를 호출해 계획이나 목표가 달성됐다고 표시할 때까지 루프를 이어 간다.
   2. 호스트의 추측 배제: 하네스가 임의로 “충분히 했다”고 판단하는 대신 모델이 명시적인 완료 신호를 내도록 한다.

7.2. 프롬프트를 구체화해야 하는 이유

1. 긴 에세이형 목표의 문제

   1. 완료 판정의 어려움: 목표를 장황한 에세이처럼 작성하면 어떤 상태가 달성인지 자동으로 판별하기 어렵다.
   2. 루프의 불안정성: 검증할 수 없는 목표는 continuation loop를 계속 돌거나 너무 일찍 종료하게 만들 수 있다.

2. 좋은 목표의 조건

   1. 구체성: 무엇을 해야 하는지 행동 단위로 명시해야 한다.
   2. 검증 가능성: 파일, 테스트, 결과값처럼 달성 여부를 확인할 수 있는 상태를 정의해야 한다.

8. 수시간·수일 작업을 위한 Auto Compaction

8.1. 긴 실행에서의 운영 문제

1. 사람의 지속적인 개입

   1. 장시간 에이전트: 에이전트가 몇 시간이나 며칠 동안 실행되면 사용자가 모든 단계에 서서 승인할 수 없다.
   2. 승인과 컨텍스트의 누적: 긴 트랜스크립트와 이전 도구 결과가 계속 쌓이면 컨텍스트 윈도우를 압박하고 운영 부담도 커진다.

2. 자동 압축의 도입

   1. 시점: Codex는 전년도 말부터 서버 측 Auto Compaction을 사용해 왔다.
   2. 학습된 동작: 모델이 압축된 컨텍스트에서도 원래와 비슷한 방식으로 계속 수행하도록 학습된 형태로 자동 압축을 실행한다.

8.2. 이전 컨텍스트를 새 컨텍스트로 바꾸는 방식

1. 수동·자동 트리거

   1. 수동 실행: 필요할 때 사용자가 압축을 직접 트리거할 수 있다.
   2. 자동 실행: 컨텍스트가 커지는 조건에 도달하면 서버가 자동으로 압축한다.

2. Compaction item

   1. 새 컨텍스트 생성: 이전 트랜스크립트와 컨텍스트 윈도우를 이후 턴에서 사용할 새 컨텍스트로 변환한다.
   2. 필수 정보 보존: 새 컨텍스트에는 이후 작업에 필요한 정보가 담긴 compaction item이 포함된다.
   3. 연속성 유지: 모든 과거 대화를 그대로 들고 가지 않으면서도 목표, 진행 상태, 중요한 실행 맥락을 잃지 않고 작업을 이어 간다.

주요 발언 모음

“컨텍스트가 많아질수록 서로 모순되는 정보가 들어갈 가능성이 커지고, 모델이 혼란을 겪을 수 있다.”

“도구를 deferred로 표시하면 초기 컨텍스트 윈도우에 직접 넣지 않고 나중에 Tool Search로 사용할 수 있다.”

“Full Access는 여전히 조심해야 한다. 모델이 좋아졌더라도 사용자의 기대와 다른 행동을 할 수 있다.”

“초당 1,000토큰으로 추론하면 병목은 더 이상 추론이 아니라 네트워크가 된다.”

“목표는 장황한 에세이가 아니라 구체적이고 검증 가능해야 한다.”

핵심 데이터 & 수치

• 약 20분: Codex 하네스의 실제 요청 흐름과 핵심 기능을 압축해서 설명한 발표 길이.
• 2배 속도: 많은 내용을 전달하기 위해 거의 2x 속도로 말하겠다고 시작 부분에서 알린 진행 속도.
• 2%: 사용 가능한 스킬 설명이 차지할 수 있는 최대 컨텍스트 윈도우 비율.
• GPT-5.4: Responses API에서 도구를 deferred loading으로 표시하고 Tool Search로 발견할 수 있게 된 기준 모델 세대.
• GPT-5: Apply Patch를 이용한 파일 편집 개념을 학습한 최근 모델 세대의 시작점.
• 초당 1,000토큰: Cerebras에서 실행되는 GPT-5.3 Codex Spark의 추론 속도 사례.
• 9개 아이템: WebSocket 이전 방식에서 반복 전송할 수 있는 전체 항목과, WebSocket에서 변경된 한 항목만 보내는 방식의 대비 사례.
• 2026년: AI Engineer World's Fair가 열린 시점이며 /goal 루프를 설명한 행사 맥락.
• Apache 2: Codex 하네스의 공개 라이선스.
• macOS / Linux / Windows: 각각 Seatbelt, Bubblewrap, 맞춤형 오픈 소스 Windows 샌드박스를 사용하는 운영체제별 격리 방식.

결론 및 시사점

1. Codex를 청사진으로 활용: 공개된 App Server와 Rust 하네스는 에이전트 아키텍처를 학습하는 자료이자 자체 제품의 기반으로 사용할 수 있다.
2. 모델과 하네스를 분리해 설계: UI와 하네스는 App Server로, 하네스와 추론은 Responses API로 분리하면 모델 제공자와 클라이언트를 개방형 생태계 안에서 교체할 수 있다.
3. 컨텍스트를 예산으로 관리: 모든 스킬과 MCP 설명을 처음부터 넣지 말고 Deferred Tools, Tool Search, 2% 스킬 캡으로 크기·비용·모순을 관리해야 한다.
4. 행동별 실행 계층을 설계: 서브에이전트와 백그라운드 터미널은 비동기 위임으로, 코드 실행 기반 브라우저는 지속 상태로, Apply Patch와 Shell은 파일 시스템 도구로 분리해야 한다.
5. 안전성과 자율성을 함께 다루기: 샌드박스만으로 승인 피로를 해결하려 하지 말고, 읽기 전용 Auto Review가 사용자 의도·위험·실행 맥락을 평가하도록 구성해야 한다.
6. 속도 최적화의 다음 대상 확인: 추론이 초고속이 된 뒤에는 SSE·HTTP의 반복 전송이 병목이 되므로 WebSocket과 상태 있는 변경분 전송을 고려해야 한다.
7. 완료를 판정할 수 있게 만들기: /goal 루프를 안정적으로 작동시키려면 프롬프트에 구체적이고 검증 가능한 완료 조건을 넣어야 한다.
8. 긴 작업의 기억을 압축하기: 수시간·수일 실행을 위해 서버 측 Auto Compaction으로 이전 컨텍스트를 필수 정보가 담긴 새 컨텍스트로 바꾸고 연속성을 유지해야 한다.
9. API 진화를 계속 추적하기: 새 모델이 나올 때마다 Responses API, Tool Search, WebSocket, 컴팩션 같은 기능이 바뀔 수 있으므로 자체 에이전트도 그 변화에 맞춰 업데이트해야 한다.

핵심 요약 (20줄)

Codex 하네스는 모델 호출을 넘어 컨텍스트·도구·안전·지속 실행을 조정하는 운영 계층이다. UI와 하네스는 App Server 프로토콜로 연결되고 하네스와 추론 모델은 Responses API로 연결된다. 두 프로토콜은 외부 UI와 모델 제공자가 참여할 수 있는 개방형 생태계를 지향한다. App Server는 Codex 앱뿐 아니라 T3 Code, Remote X, Claude Code 플러그인 같은 클라이언트의 기반이 된다. Responses API는 Chat Completions를 에이전트 중심으로 재설계하며 웹 검색과 이미지 생성 같은 기능을 추가했다. 컨텍스트 설계의 핵심 기준은 크기, 기능 확장성, 성능과 비용이다. 컨텍스트가 커지면 토큰 비용뿐 아니라 모순 정보로 인한 모델 혼란도 증가한다. Deferred Tools는 도구 정의를 초기 컨텍스트에서 빼고 Tool Search가 필요할 때만 불러온다. 사용 가능한 스킬 설명은 최대 컨텍스트 윈도우의 2%로 제한되고 초과분은 축약된다. 서브에이전트와 백그라운드 터미널은 메인 에이전트가 작업을 위임하고 계속 진행하게 한다. 최근 컴퓨터 사용은 고정된 단일 행동보다 JavaScript나 Python 코드 실행으로 유연하게 처리된다. 브라우저 자동화는 상태가 유지되는 Node REPL에서 JavaScript를 실행해 후속 페이지의 작업을 빠르게 반복한다. GPT-5 계열은 Apply Patch로 파일을 수정하고 Shell과 Ripgrep으로 파일 시스템을 탐색한다. macOS Seatbelt, Linux Bubblewrap, 맞춤형 Windows 샌드박스가 파일 시스템 접근을 격리한다. Auto Review는 읽기 전용 서브에이전트로 사용자 승인과 위험도와 실행 트랜스크립트를 평가한다. 명시적인 파일 삭제와 요청하지 않은 .git 삭제는 같은 도구 호출이라도 서로 다른 판단을 받는다. Cerebras에서 초당 1,000토큰을 내는 GPT-5.3 Codex Spark는 네트워크를 새로운 병목으로 만든다. WebSocket 모드는 상태를 유지하고 변경된 도구 결과만 보내 반복 전송의 네트워크 비용을 줄인다. /goal 루프는 목표가 달성될 때까지 continuation prompt를 주입하므로 완료 조건이 구체적이어야 한다. Auto Compaction은 긴 트랜스크립트를 필수 정보가 담긴 새 컨텍스트로 바꿔 수시간·수일 작업을 이어 가게 한다.