[한영자막] OpenAI가 직접 밝힌 Codex 하네스 위에 나만의 에이전트를 구축하는 법

🖼️ 인포그래픽

🖼️ 4컷 인포그래픽

💡 한 줄 결론

Codex 하네스를 감싼 App Server를 활용하면 기존 에이전트 기능 위에 나만의 인터페이스·지침·도구를 얹어 맞춤형 에이전트를 구축할 수 있다.

📌 핵심 요점

1. App Server는 Codex 하네스와 깊게 통합할 수 있게 하는 프로토콜이다. 하네스와 App Server는 오픈소스이며, 발표자는 Apache 2 라이선스와 Responses API 호환 모델 제공자 연결을 설명한다.
2. JSON-RPC 방식의 메시지와 이벤트로 클라이언트와 서버가 통신한다. Codex 앱과 IDE 확장뿐 아니라 외부 클라이언트도 같은 하네스와 App Server를 활용한다.
3. 맞춤화의 중심은 developer instructions와 dynamic tools다. 기본 지침에 필요한 내용을 추가하고, 도구는 지연 로딩으로 노출하며, 스레드별 모델·네트워크·파일 접근 설정을 조정할 수 있다.
4. App Server는 Codex CLI와 같은 바이너리에 포함된다. 발표자는 프로토콜의 버전별 변화에 대응하도록 앱에 사용할 바이너리를 함께 배포하고, 해당 버전의 TypeScript 바인딩이나 JSON 스키마를 생성하라고 권한다.
5. 단순 스크립트와 CI/CD 작업에는 codex exec가 적합하고, 풍부한 인터페이스나 여러 스레드를 제어하는 제품에는 App Server가 유용하다. Doom 시연은 게임 안에서도 대화와 도구 호출, 로컬 작업을 연결할 수 있음을 보여준다.

🧩 배경과 문제 정의

에이전트 하네스를 직접 만드는 일은 부담스럽게 느껴질 수 있다. OpenAI에서 Codex 개발자 경험을 담당하는 Dom은 이 문제에 대해, Codex 하네스 위에 자신만의 인터페이스를 구축하는 방법을 소개한다. 중심 도구는 하네스를 감싼 App Server이며, 발표는 통신 구조와 맞춤화 방법, 배포 방식, 실제 시연, 도입 시 주의점으로 이어진다.

🕒 시간순 섹션별 상세정리

1. 하네스를 직접 만드는 부담과 재사용의 출발점

• 발표자는 하네스 구축 경험과 부담을 묻고, Codex 하네스 위에 자신만의 인터페이스를 만드는 방법을 설명하겠다고 보여준다. [00:37]
• App Server는 하네스를 감싸는 프로토콜로, 클라이언트가 하네스 기능과 깊게 통합할 수 있게 한다. 하네스와 App Server 모두 오픈소스라고 보여준다. [01:30]
• Apache 2 라이선스로 포크와 수정을 허용하며, Responses API와 호환되는 다른 모델 제공자도 연결할 수 있다고 안내한다. [02:01]

2. 여러 클라이언트가 공유하는 통신 계층

• App Server는 JSON-RPC 방식의 프로토콜이며, Codex 앱과 VS Code 확장 등 자사 인터페이스에 사용된다. [02:17]
• Xcode·JetBrains IDE와 외부 프로젝트도 같은 하네스와 App Server를 사용한다고 설명하며, 플러그인을 통한 다른 개발 환경과의 연결 사례도 보여준다. [02:55]
• 개발자가 만드는 클라이언트는 서버에 메시지를 보내 작업을 요청하고 이벤트를 받는다. 발표자는 실제 앱과 서버 사이의 통신을 가로채는 검사 도구를 준비한다. [03:30]

3. 실제 이벤트로 살펴보는 앱 내부 동작

• Codex 앱에서 메시지를 보내면 여러 이벤트가 발생하는 모습을 보여주고, 남아 있던 버퍼를 정리한 뒤 새 요청으로 시연을 이어간다. [04:16]
• 스레드 시작과 프로젝트 설정, 구성 읽기, 응답 데이터를 스트리밍하는 델타 메시지 등을 확인한다. [04:44]
• 스트리밍과 파일 검색 등 앱의 핵심 기능에 필요한 정보가 서버와 앱 사이에서 오가므로, 별도 클라이언트도 같은 기능을 활용할 수 있다고 보여준다. [05:14]

4. 메시지 범위와 ChatGPT 로그인

• 발표 당시 120개 이상의 클라이언트 메시지가 있으며, 초기화·스레드 수정·턴 처리·목표 설정·플러그인 목록·파일 검색과 파일 시스템 수정 등을 지원한다고 보여준다. [05:58]
• 범용 프로토콜인 ACP와 비교해, App Server는 Codex 하네스의 개별 구성 요소를 더 세밀하게 제어하도록 설계됐다고 보여준다. [06:15]
• ChatGPT 로그인을 통합하면 사용자가 자신의 구독을 가져와 Codex 사용 한도 안에서 앱을 이용할 수 있으며, T3 Code를 사례로 든다. [06:35]

5. 지침·도구·스레드 설정으로 에이전트 맞춤화

• developer instructions를 기본 시스템 프롬프트에 추가하면 모델별로 조정된 기존 지침을 활용하면서 업무에 맞게 동작을 확장할 수 있다고 권한다. [07:29]
• dynamic tools나 MCP로 기능을 노출할 수 있다. 도구를 지연 로딩으로 표시하면 도구 검색을 통해 찾게 하여 전체 컨텍스트에 설명을 미리 넣는 부담을 줄일 수 있다. [08:04]
• 스레드별로 모델 제공자와 모델을 바꾸거나, 샌드박스의 네트워크 연결과 수정 가능한 파일 범위를 조정할 수 있다. [08:25]

6. 바이너리 배포와 버전별 통합 기준

• App Server는 Codex CLI와 같은 바이너리에 포함된다. Codex 앱도 바이너리를 번들로 제공하며, Windows에서는 WSL과 네이티브 실행에 대응하는 바이너리를 포함한다고 보여준다. [09:19]
• 사용할 버전에 맞는 TypeScript 바인딩이나 JSON 스키마를 생성할 수 있다. 프로토콜이 버전 사이에서 변하므로 앱에 바이너리를 함께 배포해 기대하는 기능을 통제하라고 권한다. [09:54]
• 통신 방식으로 표준 입출력과 WebSocket을 지원하며, 사용 사례에 맞는 방식을 선택하라고 안내한다. [10:09]

7. Python SDK와 Codex를 활용한 구현

• Python SDK는 수명 주기 관리를 처리하고 ChatGPT 로그인 등의 통합을 쉽게 하는 익숙한 인터페이스를 제공한다고 보여준다. [10:33]
• 또 다른 방법은 문서를 바탕으로 Codex에 프로토콜 구현을 맡기는 것이다. 앱 제작 관련 플러그인과 결합하는 활용도 언급한다. [11:01]
• 발표자는 Visual Basic으로 Windows 네이티브 클라이언트를 만든 사례를 들며, 하네스의 세부 구현을 모두 익히지 않고도 인터페이스를 만들 수 있다고 보여준다. [11:21]

8. Doom 안에서 보여준 비채팅 인터페이스의 가능성

• 기존 앱 화면, 백그라운드 실행, 별도 하드웨어와 게임 등으로 인터페이스를 확장할 수 있다고 말하며 Doom 안에서 Codex를 실행하는 시연을 시작한다. [12:04]
• Electron 앱과 Doom의 Wasm 렌더러를 사용하고, 게임 안에 표시한 입력을 Electron IPC를 거쳐 App Server로 전달해 응답을 받는 구조를 보여준다. [13:26]
• dynamic tools로 체력·방어구·무기·탄약을 조작하고, 로컬 셸로 작업 디렉터리도 확인한다. 게임 인터페이스에서도 실제 로컬 하네스의 기능을 사용할 수 있음을 보여준다. [14:28]

9. codex exec와 App Server의 선택 기준

• codex exec는 비대화형으로 작업을 시작하는 명령으로, 스크립팅이나 CI/CD에서 PR 자동 수정 같은 작업에 적합하다고 보여준다. [15:04]
• 에이전트 동작을 보여주는 클라이언트, 여러 Codex 스레드의 동시 실행, 평가 하네스와 목표 기능처럼 더 넓은 제어가 필요할 때는 App Server가 유용하다고 드러낸다. [15:28]
• 여러 exec 호출의 병렬화를 별도로 구성하는 대신, 새 스레드 이벤트와 작업 요청으로 실행을 관리할 수 있다는 차이를 강조한다. [15:40]

10. 운영 팁: 자체 버전 배포와 도구 지연 로딩

• 사용자에게 설치된 CLI에 의존하면 버전 차이, 실험 기능의 변경, 업데이트 여부 때문에 문제가 생길 수 있으므로 사용할 하네스 버전을 직접 함께 배포하라고 권한다. [16:24]
• 앱 고유 기능을 도구로 노출하되 지연 로딩으로 표시하면, 기능을 사용할 수 있게 유지하면서 불필요한 도구 설명이 컨텍스트를 차지하는 일을 줄일 수 있다고 보여준다. [16:51]

11. 기본 지침을 보존하는 맞춤화와 마무리

• 지침을 바꿀 때는 기본 지침 교체에 앞서 developer instructions 추가부터 시작하라고 다시 강조한다. [17:01]
• 모델에 맞는 프롬프트와 에이전트 성능을 유지하기 위해 조정한 내용이 있으므로, 시스템 프롬프트를 직접 다시 쓰면 그 이점을 잃을 수 있다고 경고한다. [17:24]
• 슬라이드를 받을 수 있는 QR 코드와 OpenAI 부스에서의 추가 질의응답을 안내하며 발표를 마친다. [17:37]

🧾 결론

• 하네스를 처음부터 구현하는 부담을 줄이고, 기존 기능을 활용하면서 제품에 필요한 사용자 경험을 설계하는 것이 발표의 핵심이다.
• 안정적인 통합을 위해서는 사용할 하네스 버전을 앱과 함께 배포하고, 그 버전의 기능과 프로토콜을 기준으로 구현해야 한다.
• 맞춤화는 기본 시스템 프롬프트를 교체하기보다 developer instructions 추가와 필요한 도구 연결부터 시작하는 접근이 권장된다.

📈 투자·시사 포인트

• 같은 하네스를 여러 제품이 활용할 수 있으므로, 개발자가 차별화할 지점은 인터페이스·업무 흐름·앱 고유 도구로 넓어진다.
• 프로토콜이 계속 바뀌는 환경에서는 기능 개발뿐 아니라 바이너리 배포와 버전 호환성 관리도 제품 운영의 중요한 과제가 된다.
• 채팅 외에도 기존 앱 내부 실행, 백그라운드 처리, 게임과 같은 인터페이스로 활용 범위를 확장할 수 있다. 다만 발표에는 이러한 활용의 수익성이나 투자 성과를 판단할 자료는 제시되지 않는다.

⚠️ 불확실하거나 확인이 필요한 부분

• 발표에서 언급한 120개 이상의 클라이언트 메시지, Python SDK, 실험 기능의 제공 범위는 발표 당시 설명이다. 실제 구현에 사용할 버전에서도 같은 기능과 인터페이스를 제공하는지 확인해야 한다.
• ChatGPT 로그인으로 사용자의 구독과 Codex 사용 한도를 활용할 수 있다고 설명하지만, 구체적인 이용 조건·지원 범위·한도 수치는 제시하지 않는다.
• Responses API 호환 모델 제공자를 연결할 수 있다는 설명은 있으나, 제공자별 기능 호환성이나 성능 차이를 비교한 결과는 없다.
• 자막 기반 정리: 타임스탬프가 있는 자막을 기준으로 정리했으며, 고유명사·수치·인용은 원문 확인 필요 시 별도 검증한다.
• 영상 속 주장: 발표자의 해석·전망·비교는 확인된 외부 사실이 아니라 영상 속 주장으로 분리해 읽는다.
• 검증 필요: 수치, 기업 실적, 정책·시장 전망은 발행 전 최신 자료로 별도 검증이 필요하다.

✅ 액션 아이템

• 만들려는 기능이 단순 작업 실행인지, 지속적인 상호작용과 여러 스레드 제어가 필요한 클라이언트인지 구분해 codex exec와 App Server 중 출발점을 정한다.
• 앱과 함께 배포할 Codex 바이너리 버전을 정하고, 해당 버전의 TypeScript 바인딩 또는 JSON 스키마를 생성해 통합 기준을 맞춘다.
• 기본 시스템 지침을 유지한 상태에서 업무에 필요한 developer instructions를 추가한다.
• 앱 고유 기능을 dynamic tools로 연결하고, 지연 로딩을 적용해 불필요한 도구 설명이 컨텍스트를 차지하지 않도록 한다.

❓ 열린 질문

• 만들려는 제품에서 사용자 경험을 가장 크게 바꾸는 것은 대화창, 기존 화면 안의 실행 기능, 백그라운드 작업 중 무엇인가?
• 앱에 포함한 하네스의 업데이트 주기와 실험 기능 도입 기준을 어떻게 정할 것인가?
• 기본 지침에 추가하는 방식으로 충분한 요구사항과, 더 깊은 하네스 수정이 필요한 요구사항을 어떻게 구분할 것인가?