사용자가 버그 수정을 요청하면 Codex는 관련 파일을 찾기 위해 코드베이스를 살펴보고 파일을 읽어 전체 맥락을 파악한 뒤 수정 작업을 진행합니다. 작업을 완료한 후에는 실제로 문제가 해결됐는지 확인하기 위해 테스트를 실행합니다. 이 과정에서 Codex는 내부적으로 Responses API와 수십 차례 요청을 주고받게 됩니다. 모델의 다음 작업을 결정하여 컴퓨터에서 도구를 실행하고, 그 결과를 다시 API로 보내는 과정을 반복합니다.
이처럼 여러 요청이 쌓이면 Codex가 복잡한 작업을 완료할 때까지 사용자가 몇 분씩 기다려야 하는 상황이 발생할 수 있습니다. 지연 시간 관점에서 보면 Codex 에이전트 루프는 크게 세 단계에서 대부분의 시간을 사용합니다. 요청을 검증하고 처리하는 API 서비스 단계, 모델 추론 단계, 그리고 도구 실행과 모델 컨텍스트 구성을 담당하는 클라이언트 측 단계입니다. 추론은 모델이 GPU에서 새로운 토큰을 생성하는 단계로, 과거에는 GPU에서 LLM 추론을 실행하는 과정이 에이전트 루프에서 가장 느린 부분이었기 때문에 API 서비스 오버헤드는 상대적으로 눈에 띄지 않았습니다. 하지만 추론 속도가 빨라지면서 에이전트 실행 과정에서 누적되는 API 오버헤드도 훨씬 더 두드러지게 나타나고 있습니다.
이번 글에서는 API를 사용하는 에이전트 루프의 전체 처리 속도를 40% 개선해 사용자가 초당 65 토큰에서 거의 1,000 토큰으로 빨라진 추론 속도를 직접 체감할 수 있도록 만든 과정을 소개합니다. OpenAI 팀은 이러한 성능을 달성하기 위해 캐싱을 적용하고 불필요한 네트워크 홉을 제거했으며, 문제를 더 빠르게 감지할 수 있도록 안전성 스택도 개선했습니다. 여기에 일련의 동기식 API 호출을 반복하는 대신 Responses API와 지속적으로 연결을 유지할 수 있는 방식을 구현하면서 성능을 크게 향상할 수 있었습니다.
Responses API에서 GPT‑5와 GPT‑5.2 같은 기존 플래그십 모델은 초당 약 65 토큰(TPS) 속도로 동작했습니다. 고속 코딩 모델인 GPT‑5.3‑Codex‑Spark를 출시하면서 목표로 한 것은 이보다 한 자릿수 이상 빠른 속도였습니다. 팀은 LLM 추론에 최적화된 Cerebras의 전용 하드웨어를 통해 초당 1,000 토큰 이상을 구현하고자 했습니다. 하지만 사용자가 이 새로운 모델의 실제 속도를 온전히 체감할 수 있도록 하려면 API 오버헤드를 줄여야만 했습니다.
2025년 11월경 OpenAI는 Responses API의 성능 개선을 위한 집중 작업을 시작했고, 단일 요청의 핵심 경로 지연 시간을 줄이기 위해 여러 최적화 방식을 적용했습니다.
- 멀티턴 응답에서 비용이 큰 토큰화 작업과 네트워크 호출을 줄일 수 있도록 렌더링된 토큰과 모델 설정을 메모리에 캐싱했습니다.
- 중간 서비스 호출(예: 이미지 처리 해상도 조정)을 없애고 추론 서비스를 직접 호출해 네트워크 홉으로 인한 지연 시간을 줄였습니다.
- 분류기 실행으로 대화를 신속하게 감지할 수 있도록 안전 스택 개선
이러한 개선을 통해 API의 응답성을 보여주는 첫 토큰 생성 시간(TTFT)은 약 45% 단축되었습니다. 하지만 이 정도는 GPT‑5.3‑Codex‑Spark에 충분하지 않았습니다. 개선 이후에도 모델 속도에 비해 Responses API의 오버헤드는 여전히 컸습니다. 즉, 사용자는 모델을 처리하는 GPU를 활용하기 전에 먼저 API를 실행하는 CPU 작업이 끝나기를 기다려야 했습니다.
더 근본적인 문제는 구조에 있었습니다. 각 Codex 요청을 서로 독립적인 작업으로 처리하면서, 후속 요청이 들어올 때마다 대화 상태와 재사용할 수 있는 다른 컨텍스트를 매번 다시 처리하고 있었습니다. 대화 내용의 대부분이 바뀌지 않았더라도 전체 기록에 연결된 작업 비용은 계속 발생했습니다. 대화가 길어질수록 이런 반복 처리 비용은 더욱 커졌습니다.
OpenAI 팀은 설계를 더 효율적으로 만들기 위해 전송 프로토콜을 다시 검토했습니다. 후속 요청마다 HTTP로 새 연결을 만들고 전체 대화 기록을 보내는 대신, 지속적인 연결을 유지하면서 상태를 캐싱할 수 있을지 살펴봤습니다. 핵심 아이디어는 검증과 처리가 필요한 새 정보만 보내고, 재사용 가능한 상태는 연결이 유지되는 동안 메모리에 캐싱하는 것이었습니다. 이렇게 하면 중복 작업에서 발생하는 오버헤드가 줄어들 것으로 예상되었습니다.
팀은 웹소켓과 gRPC 양방향 스트리밍을 포함해 몇 가지 접근 방식을 검토했고 최종적으로는 웹소켓을 선택했습니다. 단순한 메시지 전송 프로토콜이기 때문에 사용자가 Responses API의 입력과 출력 구조를 바꿀 필요가 없었기 때문입니다. 개발자가 적용하기도 쉬웠고 기존 아키텍처에도 큰 변경 없이 자연스럽게 맞출 수 있었습니다.
첫 번째 웹소켓 프로토타입은 Responses API 지연 시간에 대한 기존의 한계를 다시 생각하게 만들었습니다. API 스택 전반에 깊은 전문성을 가진 Codex 팀의 한 엔지니어가 밤새 Codex 에이전트를 실행해 프로토타입을 완성했습니다.
이 프로토타입에서는 에이전트 실행 과정을 장시간 실행되는 하나의 Response로 모델링했습니다. asyncio 기능을 활용해 도구 호출이 샘플링되면 Responses API는 샘플링 루프에서 비동기적으로 대기 상태에 들어가고, 클라이언트에 response.done 이벤트를 보냈습니다. 클라이언트는 도구 호출을 실행한 뒤 그 결과를 담은 response.append 이벤트를 다시 보내고, 그러면 샘플링 루프의 대기가 해제되어 모델이 계속 작업을 이어갈 수 있었습니다.
이를 쉽게 설명하면 로컬 도구 호출을 호스팅된 도구 호출처럼 다루는 것입니다. 예를 들어 모델이 웹 검색을 호출하면 추론 루프는 일시적으로 멈추고 웹 검색 서비스를 호출한 뒤, 그 응답을 모델 컨텍스트에 넣습니다. 이번 설계도 같은 방식입니다. 다만 원격 서비스를 호출하는 대신 모델의 도구 호출을 웹소켓을 통해 클라이언트로 보내고, 클라이언트가 응답하면 그 결과를 다시 컨텍스트에 넣어 샘플링을 계속 진행했습니다.
이 설계는 에이전트 실행 전반에서 반복되던 API 작업을 없앴기 때문에 매우 효과적이었습니다. 추론 전 작업은 한 번만 수행하고 도구 실행 동안 일시적으로 멈춘 뒤, 추론 후 작업도 마지막에 한 번만 처리할 수 있었습니다.
하지만 그만큼 API 구조는 익숙하지 않고 더 복잡해졌습니다. 팀은 개발자가 새로운 상호작용 방식에 맞춰 API 연동을 다시 작성하지 않아도 웹소켓 지원을 바로 적용할 수 있기를 원했습니다.
실제로 출시한 버전에서는 다시 익숙한 구조로 돌아갔습니다. 같은 요청 본문으로 response.create를 계속 사용하고, previous_response_id를 통해 이전 응답의 상태를 이어받아 대화 컨텍스트를 유지하도록 했습니다.
웹소켓 연결에서는 서버가 연결 범위 내에서 이전 응답 상태를 메모리 캐시에 유지합니다. 후속 response.create 요청에 previous_response_id가 포함되면 전체 대화를 처음부터 다시 구성하는 대신, 해당 상태를 캐시에서 바로 가져옵니다.
캐시에 저장되는 상태는 다음과 같습니다.
- 이전
response객체 - 이전 입력 및 출력 항목
- 도구 정의와 네임스페이스
- 이전에 렌더링된 토큰처럼 재사용 가능한 샘플링 아티팩트
팀은 메모리에 저장된 이전 응답 상태를 재사용하면서 몇 가지 중요한 최적화를 적용할 수 있었습니다.
- 일부 안전성 분류기와 요청 검증기가 매번 전체 기록이 아니라 새로 들어온 입력만 처리하도록 개선했습니다.
- 렌더링된 토큰을 메모리에 캐시하고 계속 이어 붙여 불필요한 토큰화 작업을 건너뛸 수 있게 했습니다.
- 이미 검증된 모델 선택 및 라우팅 로직을 여러 요청에 걸쳐 재사용했습니다.
- 과금처럼 차단이 필요 없는 추론 후 작업은 다음 요청과 겹쳐서 처리할 수 있도록 했습니다.
목표는 오버헤드를 최소화한 프로토타입에 최대한 가깝도록 성능을 구현하되, 개발자가 이미 이해하고 사용해 온 API 구조를 그대로 유지하는 것이었습니다.
팀은 두 달간 집중적으로 웹소켓 모드를 개발한 뒤, 주요 코딩 에이전트 스타트업과 함께 알파 버전을 출시해 각자의 인프라에 통합하고 트래픽을 안정적으로 확대할 수 있도록 했습니다. 알파 사용자들은 이를 매우 긍정적으로 평가했으며 에이전트 기반 워크플로에서 최대 40%의 성능 개선(새 창에서 열기)을 경험했다고 전했습니다. 이러한 긍정적인 피드백을 바탕으로 팀은 정식 출시를 진행할 준비를 마쳤습니다.
출시 효과는 즉시 나타났습니다. Codex는 Responses API 트래픽의 대부분을 빠르게 웹소켓 모드로 전환했고, 지연 시간도 크게 개선되었습니다. GPT‑5.3‑Codex‑Spark에서는 목표였던 초당 1,000토큰(TPS)을 달성했고, 순간적으로는 최대 4,000TPS까지 달성하는 결과를 보였습니다. 이를 통해 실제 프로덕션 환경에서도 Responses API가 훨씬 빨라진 추론 속도를 충분히 따라갈 수 있다는 것을 확인할 수 있었습니다. 이 영향은 개발자 커뮤니티에서도 빠르게 나타났습니다.
- Codex는 트래픽의 대부분을 빠르게 웹소켓으로 전환했습니다. GPT‑5.3‑Codex(새 창에서 열기), GPT‑5.4(새 창에서 열기), 등 최신 모델을 사용하는 Codex 사용자들은 모두 웹소켓 모드의 속도 향상 효과를 누리고 있습니다.
- Vercel은 AI SDK에 웹소켓 모드를 통합한 뒤 지연 시간이 최대 40%(새 창에서 열기) 감소하는 효과를 보았습니다.
- Cline의 멀티 파일 워크플로는 39% 더 빨라졌습니다(새 창에서 열기).
- Cursor의 OpenAI 모델은 최대 30% 더 빨라졌습니다(새 창에서 열기).
웹소켓 모드는 2025년 3월 Responses API 출시 이후 가장 중요한 신규 기능 중 하나입니다. OpenAI의 API 팀과 Codex 팀이 긴밀하게 협력한 덕분에 아이디어 단계에서 실제 프로덕션 운영까지 단 몇 주밖에 걸리지 않았습니다. 이 기능은 에이전트 실행 지연 시간을 크게 줄였을 뿐만 아니라, 개발자들의 점점 커지는 요구에도 대응합니다. 모델 추론 속도가 빨라질수록 그 주변을 뒷받침하는 서비스와 시스템 역시 함께 빨라져야만 그 성능 향상을 실제 사용자 경험으로 전달할 수 있기 때문입니다.
