Codex App Server와 GPT-Realtime-2를 활용한 차세대 개발 스타일 구상

2026년 5월 7일, OpenAI가 GPT-Realtime-2를 포함한 Realtime API를 GA(General Availability)로 전환했습니다. 마찬가지로 이번 봄에는 Codex App Server도 독자적인 프로덕트에 통합할 수 있는 형태로 정식 문서화되었으며, openai/codex 하위에 오픈 소스로 구현체가 공개되었습니다.

이 두 가지를 나란히 사용해 보니, 지금까지 '텍스트 전제'였던 AI 코딩 에이전트를 **목소리로 대화하며 움직일 수 있는 페어 프로그래머(Pair Programmer)**로 탈바꿈시킬 수 있겠다는 느낌을 받았습니다. 검증을 위해 voice-pair-programmer라는 작은 프로토타입을 만들어 보았기에, 이를 소재로 양자의 특성과 '목소리로 코딩하는 시대'의 윤곽을 함께 짚어보고자 합니다.

참고로, 본 기사는 실제 프로덕트의 설계 지침이라기보다는 조작감을 확인하기 위한 검증 노트에 가까운 내용입니다.

백문이 불여일견

본 기사의 소재가 되는 검증용 리포지토리는 다음과 같습니다.

voice-pair-programmer는 간단히 말해, 브라우저 마이크를 향해 말로 부탁하면, 백그라운드에서 Codex가 코드를 작성하고 diff를 제안해 주는 로컬 Web 앱입니다. 음성은 GPT-Realtime-2가, 코딩은 Codex App Server가 담당하며, 승인 UI를 통해 파일 변경을 허용하는 방식입니다.

voice-pair-programmer의 UI 전체도. 왼쪽에 리포지토리 선택과 CONNECT 버튼, 오른쪽에 승인 큐가 나열됨

기존의 음성 입력과 큰 차이점은, AI가 말하는 도중에도 사용자가 말을 걸 수 있다는 점입니다. "아, 역시 그 테스트는 건너뛰어줘"라고 중간에 끼어들 수 있고, Codex가 긴 작업을 수행하는 중에 "하는 김에 README도 수정해 줘"라고 추가 지시를 내릴 수도 있습니다. 대화를 주고받으며 에이전트를 구동하는, 인간과의 페어 프로그래밍에 가까운 경험입니다.

실제로 말하는 모습을 보는 것이 빠를 것 같아 데모 영상도 함께 올려둡니다.

긴 설명을 읽기 전에 먼저 실행해 보는 것이 빠를 것입니다.

git clone https://github.com/s-hiraoku/voice-pair-programmer
cd voice-pair-programmer

여기서 Claude Code나 Codex CLI 등 즐겨 사용하는 AI 에이전트를 실행합니다.

이 앱을 실행해 봐

라고 부탁하면, README를 읽으면서 의존성을 설치하고, Codex CLI 설정을 안내해 줍니다. .env 템플릿을 안내하고, npm run dev까지 실행해 줄 것입니다.

그 후 OPENAI_API_KEY (gpt-realtime-2를 사용할 수 있는 OpenAI 프로젝트의 키)를 입력하고, 브라우저에서 http://localhost:8787을 엽니다. CONNECT를 누르면 마이크가 작동하기 시작합니다.

'인간이 README를 순서대로 밟아 나가는 시대'에서 '에이전트에게 README째로 넘겨주는 시대'로, 그 경계가 이 단 3줄의 명령어 사이에 나타나 있는 듯한 기분이 듭니다. 한 번 체감한 뒤에 다음 내용을 읽으시면 아마 이야기가 더 빠를 것입니다.

비용 문제에 대해 미리 언급

"일단 한번 시도해 봐"라는 말을 들었을 때, 과금이 걱정되는 분들도 있을 것입니다. 비용 문제를 미리 정리해 두겠습니다.

이 앱은 두 개의 독립된 계통으로 작동하며, 비용이 발생하는 계통과 발생하지 않는 계통이 명확히 나뉩니다.

계통	담당	비용
음성 계통	브라우저 ↔ OpenAI Realtime API (gpt-realtime-2)	OpenAI API 종량제 (.env의 OPENAI_API_KEY 사용)
코딩 계통	Express ↔ codex app-server (stdio JSON-RPC)	ChatGPT Plus 이상의 구독 범위 내 포함 (codex login의 로그인 정보 사용)

비용의 흐름을 말로 정리하면 다음과 같습니다.

• 음성으로 말한 만큼 Realtime API 비용이 청구됨
• 코딩 작업은 구독 범위 내에서 모두 흡수됨

**「코드를 대량으로 작성하게 하더라도, 코드를 작성하는 측의 비용은 ChatGPT 구독 범위 내에서 흡수할 수 있다」**는 점이 가장 큰 부분입니다. 음성으로 계속 말을 하고 있지 않는 한, 비용은 생각했던 것만큼 늘어나지 않았습니다.

음성 계열의 요금 체감

GPT-Realtime-2의 요금은 Audio input이 $32 / 1M tokens, Audio output이 $64 / 1M tokens입니다. OpenAI 자체의 개산(rough estimate)에 따르면 입력 $1.15/hour, 출력 $4.61/hour로 되어 있습니다.

대략적으로 시간 단위로 견적을 내보면 다음과 같습니다.

이용 시간	개산 비용 (입출력 혼재 시 최대)	엔화 환산 (기준)
5분	약 $0.5	약 75엔
...

실제로는 여기서 생각하는 침묵 시간은 output 토큰을 소비하지 않으므로, 이보다 저렴하게 끝나는 경우가 많습니다. 테스트용이라면 $5~10 정도의 크레딧(수백 엔~1,500엔 정도)을 넣어두면, 한 차례 충분히 놀고도 남습니다. 다 사용한 후에는 DISCONNECT를 누르는 습관만 들여 놓으면, "정신 차려보니 수천 엔이 나갔다"와 같은 사고도 일어나기 어렵습니다.

실행 전 준비

구독 범위 내에서 작동시키기 위해, 실행 전에 codex login을 완료하여, codex를 바로 입력했을 때 프롬프트가 반환되는 상태로 만들어 두어야 합니다.

npm install -g @openai/codex
codex login # 브라우저가 열림
codex # 프롬프트가 나오면 OK

여기까지 완료되어 있다면, npm run dev를 하는 것만으로 서버가 양쪽 계통을 한꺼번에 띄워줍니다.

1. 왜 지금 음성 지시인가?

AI의 똑똑함이 「지시의 정밀도」 요구사항을 바꾸었다

지금까지 AI 코딩의 인터페이스는 텍스트가 유일한 선택지였습니다. 이유는 간단합니다, 모델이 아직 그 정도로 똑똑하지 않았기 때문입니다. 모호하게 부탁하면 의도가 어긋나기 때문에, 이쪽에서 상세하게 조건을 써 내려가며 텍스트로 다듬어서 전달할 필요가 있었습니다. 프롬프트 엔지니어링 (Prompt Engineering)이라고 불리던 그것입니다.

하지만 GPT-5 / GPT-5.4 / GPT-5.5 정도에 이르면, 모델의 이해력이 한 단계 올라갔습니다. "테스트가 실패한 것 같아, 좀 봐줘"와 같은 모호한 부탁에도 에이전트 (Agent)는 문맥을 파악하며 움직여 줍니다. 상세하게 지시하지 않아도 통하게 되면, 이번에는 텍스트로 쓰는 수고가 오히려 번거롭게 느껴지기 시작합니다.

이 단계에 오면, 사람에게 말하듯이 지시하는 것이 더 적합하지 않을까 하는 것이 본 기사의 출발점입니다.

텍스트와 음성의 구분 사용이 인간 대상의 대화에 가까워진다

그렇다고 해서 "음성이 모든 것에 승리한다"고 생각하지는 않습니다. 사양을 엄격하게 전달하고 싶을 때, 중첩된 구조를 표현하고 싶을 때, 설계 논의에서 밀도를 높이고 싶을 때는 텍스트가 더 적합합니다.

반대로, 떠오른 순간에 던지고 싶은 지시, 진행 중인 작업에 대한 끼어들기, 추가적인 정정은 음성이 압도적으로 빠릅니다.

나란히 놓고 보면, 이것은 인간 사이의 상호작용과 같은 구조입니다. 평소의 대화는 음성으로 해결하고, 계약서나 설계도는 텍스트로 남깁니다. AI와의 상호작용도 이제 그 단계에 도달했다는 느낌을 받고 있습니다.

2026년에 들어서며 기반이 갖춰졌다

실제로 2026년에 들어서 이후의 움직임을 나열해 보면, 업계 전체가 음성 인터페이스 (Voice Interface) 구현을 향해 움직이기 시작했음을 알 수 있습니다.

• Codex CLI 0.105에서 spacebar dictation 도입 (Wispr Flow 엔진, macOS/Windows, 2026년 2월)
• Claude Code에 /voice 기능 추가 (2026년 3월, /voice로 토글, Pro/Max/Team/Enterprise)
• Codex desktop app에 Ctrl+M 음성 프롬프트 추가
• OpenAI Realtime API GA (General Availability), GPT-Realtime-2가 GPT-5급의 추론을 음성에 도입

하나하나가 작은 기능 추가로 보일 수 있지만, 이것들이 모이면 의미가 달라집니다. "음성 입력으로 텍스트를 쓰는 것"이 아니라, 대화의 턴 (Turn)을 주고받으며 에이전트를 구동하는 것이 현실적이 되었다는 뉘앙스입니다.

이러한 차이를 뒷받침하는 것은 GPT-Realtime-2의 barge-in (끼어들기) 처리와 저지연성 (Low-latency)입니다. 그리고 Codex App Server와 같이 "에이전트를 외부에서 제어할 수 있는 접속점" 또한 중요한 요소가 되고 있다고 느낍니다.

지금 우리가 하고 있는 일은 조금 우스꽝스럽지 않나요?

잠시 멈춰서 생각해 보세요. 이제 인간은 코드를 거의 작성하지 않습니다. 하고 있는 일이라고는 AI를 향해 오로지 텍스트로 지시를 입력하는 것뿐입니다.

이것은 잘 생각해보면 우스꽝스럽지 않나요? 옆에 앉아 있는 동료에게 일을 부탁할 때, 굳이 키보드로 몸을 돌려 문장을 타이핑하는 사람은 없습니다. 보통은 말로 합니다. 그런데 AI가 상대가 되면, 왠지 모두가 묵묵히 키보드를 두드리고 있습니다.

아마 몇 년 후, 누구나 이렇게 생각할 것입니다. "왜 AI에게 지시할 때 굳이 텍스트로 쳤던 거지?"라고 말이죠. 지금 우리가 하고 있는 일은 나중에 되돌아보면 웃음거리가 될지도 모릅니다. 그 위화감을 이제 슬슬 깨달아도 될 시기라는 생각이 듭니다.

그래서 이 글을 계기로, 이제 슬슬 텍스트 일변도의 지시는 그만두지 않겠느냐고 제안하고 싶습니다. 모든 것을 음성으로 대체할 필요는 없습니다. 모호한 지시, 진행 중인 추가 요구사항, 갑자기 떠오른 끼어들기는 음성으로, 사양의 엄격한 정의나 설계 논의는 텍스트로. 전달하고 싶은 내용에 맞춰 인터페이스 (Interface)를 구분해서 사용하는 것, 단지 그뿐입니다.

"목소리로 코드를 작성한다"라고 들었을 때, 처음에는 회의적인 마음이 앞섰습니다. 하지만 **"코드를 눈으로 읽으면서, 목소리로 에이전트에게 지시한다"**는 체험은 의외로 합리적으로 보였습니다. 에이전트가 diff (차이점)를 제안하는 동안, 이쪽은 화면을 바라보고 있으면 되고, 생각이 나면 구두로 "역시 그 테스트는 건너뛰어줘"라고 끼어들 수 있습니다. 타이핑하며 반복하는 것보다 사고의 흐름이 끊기지 않아 기분이 좋았습니다.

이 프로토타입에서는 아직 구현하지 않았지만, 예를 들어 이런 것도 가능할 것 같습니다.

• "브라우저를 열어서, 지금 구현이 생각한 대로 작동하는지 확인해줘"라고 부탁하면, 알아서 검증해줌
• "방금 변경한 부분의 diff를 보여줘"라고 말하면, 옆의 디스플레이에 diff 표시 전용 스크린이 슥 나타나서, 추가된 행과 삭제된 행이 색깔과 함께 흘러감

말로 부탁하면 AI가 PC를 조작해 주는, 옛날 SF 영화에서 보았던 것 같은 미래가 서서히 현실이 되어가고 있다는 느낌이 듭니다.

2. Codex App Server의 정체

Codex 내부의 "중앙 버스 (Central Bus)"

Codex App Server는 Codex 계열의 클라이언트들이 공유하는 **동일한 에이전트 엔진 (Agent Engine)**을 자신의 프로덕트에서 호출할 수 있도록 만든 인터페이스입니다. Codex 데스크톱 앱, Codex CLI, VS Code 확장, IDE Extension이 모두 동일한 엔진 위에서 구동되는 이미지입니다. 구현은 Rust로 작성되어 있으며, openai/codex/codex-rs/app-server에 오픈 소스로 공개되어 있습니다.

공식 문서(App Server – Codex)의 표현을 빌리면 다음과 같습니다.

Codex app-server is the interface Codex uses to power rich clients (for example, the Codex VS Code extension). Use it when you want a deep integration inside your own product: authentication, conversation history, approvals, and streamed agent events.

요컨대, 다음 사항들을 통째로 오프로드 (Offload)할 수 있다는 점이 큰 포인트입니다.

• 인증 (Authentication) (API 키 또는 ChatGPT OAuth)
• 대화 이력의 영속화 (Persistence of conversation history) (thread / turn / item)
• 승인 플로우 (Approval flow) (도구 실행 · 파일 변경)
• 에이전트 이벤트의 스트리밍 (Streaming of agent events)

Codex SDK가 "비대화형 · CI용" 레이어라면, App Server는 "대화형 UI를 직접 만들 때 사용하는" 레이어라고 이해하면 역할 분담이 명확해집니다.

JSON-RPC 2.0 + MCP 스타일의 트랜스포트 (Transport)

통신은 JSON-RPC 2.0입니다. MCP(Model Context Protocol)와 동일한 방식으로, 두 가지 종류의 트랜스포트(Transport)를 지원합니다.

트랜스포트	실행 명령	용도
stdio(기본값)	codex app-server	동일 프로세스 내에 통합하는 데스크톱형 클라이언트
WebSocket(실험적)	codex app-server --listen ws://127.0.0.1:4500	로컬 HTTP / 별도 프로세스의 클라이언트

WebSocket 측은 아직 실험적인 단계입니다. 루프백(loopback) 이외의 환경에 노출하려면 --ws-auth capability-token 또는 --ws-auth signed-bearer-token을 사용하라고 명시되어 있습니다.

반면 stdio는 자식 프로세스(child process)로 spawn하면 즉시 사용할 수 있습니다. Electron이나 VS Code 확장, Express 서버와 같이 "자신의 프로세스 안에 가두고 싶은" 용도라면 stdio가 전제 조건이 됩니다.

voice-pair-programmer 또한 stdio를 통해 실행됩니다. 코드는 나중에 보여드리겠습니다.

앱 프리미티브(App Primitive): Thread / Turn / Item

App Server의 세계관은 단순하며, 세 가지 개념만 기억하면 대부분의 동작을 이해할 수 있습니다.

• Thread— 사용자와 에이전트 간의 대화. 영속화(persistence)됩니다.
• Turn— 하나의 "사용자 입력 + 그에 이어지는 에이전트 작업"의 묶음.
• Item— Turn 내부의 최소 단위(사용자 메시지, 에이전트 발화, 명령 실행, 파일 변경, 도구 호출(tool call), 추론(reasoning) 블록 등).

라이프사이클은 다음과 같이 반복됩니다.

initialize → thread/start → turn/start → (item/* 이벤트 스트림) → turn/completed

도중에 turn/steer를 던지면 사용자가 추가 입력을 흘려보낼 수 있고, turn/interrupt로 진행 중인 턴을 취소할 수 있습니다. 이 "도중에 개입할 수 있는" 설계가 나중에 GPT-Realtime-2와 맞물리는 복선이 됩니다.

인증 모드

사소해 보이지만 중요한 점은, 인증 모드에 chatgpt가 있다는 것입니다. 서두에서 언급한 "구독 범위 내에서 커버"의 정체가 바로 이것입니다.

chatgpt 모드를 선택하면, 해당 App Server 세션은 ChatGPT Plus 이상의 구독 범위를 소비할 뿐, API 과금은 발생하지 않습니다.

모드	내용
apikey	일반적인 OpenAI API 키를 사용 (종량제 과금)
chatgpt	Codex 측이 ChatGPT OAuth를 관리하며, 토큰 갱신까지 처리함
chatgptDeviceCode	디바이스 코드 플로우 (Device Code Flow)

voice-pair-programmer는 Express에서 codex app-server를 자식 프로세스로 실행합니다. 이때 Codex CLI의 글로벌 로그인 정보를 그대로 상속하므로, 평소 ChatGPT 구독으로 Codex를 사용하고 있다면 추가 설정 없이 구독 범위가 적용됩니다.

3. GPT-Realtime-2로 무엇이 바뀌었는가

2026년 5월 7일, OpenAI가 새로운 음성 모델군을 Realtime API에 투입했습니다. 구체적으로는 GPT-Realtime-2 / GPT-Realtime-Translate / GPT-Realtime-Whisper 세 가지입니다. Realtime API 자체도 베타를 벗어나 GA(General Availability)가 되었습니다. 본 기사의 주인공은 그중에서도 GPT-Realtime-2이며, OpenAI 스스로가 "first voice model with GPT-5-class reasoning"이라고 부르는 모델입니다.

GPT-5급 추론을 음성에 도입

지금까지의 Realtime 모델(gpt-realtime-1.5까지)은 speech-to-speech(음성 대 음성)가 성립될 뿐, 추론(reasoning)은 다소 얕은 수준이었습니다. 복잡한 로직을 말하게 하면 도중에 논리가 파괴되거나, 도구 호출(tool calling) 순서를 틀리는 경우가 있었습니다.

GPT-Realtime-2는 이러한 구조를 바꾸어 놓았습니다.

• 128K 컨텍스트 (Context) (기존에는 32K). 4시간급의 대화가 컨텍스트에 담깁니다.
• 추론 노력(reasoning effort)을 5단계로 조정 가능 (minimal / low / medium / high / xhigh)
• 기본값은 low로 설정되어 있으며, 이는 레이턴시(latency)를 우선시합니다.

벤치마크 수치는 다음과 같습니다.

• Big Bench Audio (음성 추론): 96.6% (gpt-realtime-1.5는 81.4%)
• Audio MultiChallenge (음성 멀티턴 지시 따르기): 48.5% (gpt-realtime-1.5는 34.7%)

참고로 이 수치는 xhigh effort로 측정된 값이며, 기본값인 low에서는 수치가 조금 더 낮아집니다. 그럼에도 불구하고 후자의 +13.8 포인트 차이는 「지시 사항을 기억한 채 대화를 지속할 수 있는 시간」이 체감상 2배 가까이 늘어나는 정도의 효과로 나타났습니다.

Preambles와 병렬 도구 호출

은근히 효과적인 부분은 preambles(서문/도입 문구)와 병렬 도구 호출(parallel tool calling)이 정식으로 지원되었다는 점입니다.

여기서부터 제10장까지는 voice-pair-programmer의 아키텍처(Architecture)와 구현에 관한 이야기입니다. 관심 있는 장만 펼쳐서 읽어주세요.

세부적인 동작이 궁금하다면, 리포지토리(Repository)를 Claude Code나 Codex CLI에 읽히는 것이 가장 빠릅니다. 궁금한 부분만 콕 집어서 답변해 줍니다.

구현 상세 내용을 건너뛰고 싶다면, 제11장까지 바로 진행하셔도 문제없습니다.

4. voice-pair-programmer의 아키텍처

이제부터 본 기사의 검증 리포지토리인 voice-pair-programmer의 내부를 살펴보겠습니다.

전체 구조도

요점만 뽑아내면 다음과 같습니다.

• 브라우저는 SDP 오퍼(Offer)만 서버로 전송 - 서버가 OpenAI Realtime API에 대해 세션을 생성하고, SDP 앤서(Answer)를 중계
• 이후의 음성 및 이벤트는 WebRTC를 통해 브라우저 ↔ OpenAI 직결
• GPT-Realtime-2가 코딩 작업이 필요하다고 판단하면, codex_task라는 단 하나의 도구(Tool)를 호출
• 이 도구가 호출되면, Express가 codex app-server(자식 프로세스)에 turn/start로 작업을 위임
• API 키는 서버 측에만 존재

WebRTC를 사용하는 가장 큰 이점은 3번입니다. 음성 스트림은 P2P 연결이므로 서버에 부하가 걸리지 않으며, 서버는 인증만 중개하는 형태가 됩니다. 클라이언트는 서버를 거친 토큰만을 가지므로, API 키 유출 리스크도 사라집니다.

codex_task 도구

단 하나뿐인 codex_task 도구가 바로 voice-pair-programmer의 핵심이며, Realtime API에 공개한 도구는 codex_task 단 하나로 제한했습니다.

// src/server/realtime.ts (발췌)
export const REALTIME_TOOLS = [
{
...

처음에는 세밀한 단위의 도구(Fine-grained tools)를 Realtime에 개별적으로 등록하는 설계도 시도했습니다. workspace_status, read_file, git_diff, run_tests, propose_patch와 같은 단위로 분할하는 이미지입니다. 하지만 결과적으로는 전부 Codex에게 맡기는 것이 더 심플했습니다. Codex는 이미 내부적으로 모든 코딩 작업을 실행할 수 있습니다. Realtime 측에서 세세하게 지시를 내리는 것보다, "태스크 내용을 한 문장으로 전달하고 끝내는 것"이 더 직관적이라는 것이 직접 사용해 본 느낌입니다.

시스템 인스트럭션(System Instruction)으로 "Codex에게 맡겨라"라고 명시

Realtime 세션 설정에서는 시스템 프롬프트(System Prompt)로 다음과 같이 지시하고 있습니다.

// src/server/realtime.ts (발췌)
instructions: [
"You are the voice layer of Voice Pair Programmer.",
...

이 "codex_task가 반환될 때까지 완료되었다고 말하지 마라"라는 지시가 은근히 효과적입니다. preambles(서문/도입 문구)를 통해 "지금 Codex가 확인하고 있습니다"라고 발화하게 하면서, 실제 완료는 Codex 측의 turn/completed를 기다리는 흐름이 안정적으로 동작하게 됩니다.

역할 분담 요약

컴포넌트	역할	프로세스 경계
브라우저 UI	마이크 입력, 음성 재생, 승인 UI, 프로젝트 관리	Chrome / Edge / Safari
GPT-Realtime-2	음성 대화, codex_task 호출 판단, preambles 발화	OpenAI 측
Express	SDP 중계, codex app-server 자식 프로세스 관리, 승인 큐	Node.js
codex app-server	리포지토리 조사, 코드 구현, 파일 변경, 명령 실행	Codex CLI의 자식 프로세스

"목소리를 담당하는 계층"과 "손을 움직이는 계층"이 깔끔하게 분리되어 있다는 점이 이 구성의 포인트입니다.

5. Realtime API(WebRTC) 샘플 코드

여기서부터 코드입니다. OpenAI 공식 문서(Realtime API with WebRTC)의 형식을 기반으로, voice-pair-programmer의 구현부에서 발췌하여 게시합니다.

서버 측: SDP 중계

// src/server/routes/realtime.ts(발췌·간략화)
import express from "express";
app.use("/api/realtime/call", express.text({ type: ["application/sdp", "text/plain"] }));
...

포인트는 두 가지입니다.

세션 설정에 도구를 포함— 앞서 언급한 codex_task

1개만 -
API 키는 여기서만 사용— 브라우저는 /api/realtime/call을 호출할 뿐입니다.

세션 설정으로 「끼어들기 가능」하게 만들기

세션 설정 내용 중 중요한 것은 turn_detection 지정입니다.

// src/server/realtime.ts(발췌)
audio: {
input: {
...

interrupt_response: true를 넣어두면, 사용자가 말을 시작하는 순간 서버 측에서 현재 응답 음성을 자동으로 truncate(잘라내기) 해줍니다. 이것이 「인간의 대화와 같은 자연스러운 끼어들기」 경험의 실체입니다.

클라이언트 측: WebRTC 피어 연결 (Peer Connection)

// src/client/hooks/useRealtimeSession.ts(발췌·간략화)
export async function connectRealtime(audioElement: HTMLAudioElement) {
// 1. 피어 연결을 생성
...

pc.ontrack