Responses API의 WebSocket으로 에이전트 워크플로 속도 높이기

Codex의 에이전트 루프는 파일 탐색, 도구 실행, 결과 반영을 반복하는 동안 여러 번의 Responses API 왕복이 쌓이며 지연이 커졌다. 특히 GPT-5와 GPT-5.2가 약 65 TPS 수준이던 시절에는 모델 추론이 느려 API 오버헤드가 잘 드러나지 않았지만, GPT-5.3-Codex-Spark처럼 1,000 TPS 이상을 목표로 하는 초고속 모델에서는 CPU 쪽 API 처리 비용이 병목이 됐다.

이를 줄이기 위해 OpenAI는 먼저 캐싱, 네트워크 홉 축소, 안전성 분류기 개선으로 TTFT를 약 45% 개선했다. 그럼에도 긴 대화의 전체 히스토리를 매 요청마다 다시 처리하는 구조 때문에, 후속 요청마다 같은 검증과 상태 재구성이 반복되는 문제가 남아 있었다.

해결책은 persistent connection이었다. 초기에는 WebSockets와 gRPC bidirectional streaming을 검토했지만, 기존 Responses API의 입출력 형태를 거의 바꾸지 않고 붙일 수 있는 WebSockets를 택했다. 핵심 아이디어는 연결을 유지한 채, 새로 들어온 입력만 검증하고 재사용 가능한 상태는 메모리에 보관하는 것이다.

첫 프로토타입은 더 과감했다. 에이전트의 전체 rollout을 하나의 긴 Response로 보고, 툴 호출이 샘플링되면 API가 비동기로 멈춘 뒤 response.done 이벤트를 보내고, 클라이언트가 툴 결과를 response.append로 돌려주면 샘플링을 이어가는 방식이었다. 이 구조는 중복 작업을 거의 없앴지만, 개발자 입장에서는 새로운 상호작용 방식이 너무 낯설다는 문제가 있었다.

실제로 출시한 버전은 익숙한 형태를 유지했다. 기존처럼 response.create를 쓰되, previous_response_id로 이전 응답의 상태를 이어받는다. WebSocket 연결 안에서 서버는 이전 응답 상태를 연결 단위의 메모리 캐시에 보관하고, 후속 요청이 오면 전체 대화 기록을 재구성하지 않고 그 상태를 그대로 재사용한다.

이 캐시에는 다음이 포함된다.

• 이전 response 객체
• 과거 input/output items
• tool definitions와 namespaces
• 이미 렌더링된 tokens 같은 재사용 가능한 sampling artifacts

이 구조 덕분에 여러 최적화가 가능해졌다.

• 안전성 분류기와 요청 검증기가 전체 히스토리가 아니라 새 입력만 처리
• 렌더링된 tokens를 메모리에서 누적 관리해 불필요한 tokenization 제거
• 모델 resolution/routing 로직 재사용
• billing 같은 비차단 postinference 작업을 다음 요청과 겹쳐 실행

결과는 즉시 나타났다. 두 달간의 작업 끝에 alpha를 시작해 일부 코딩 에이전트 스타트업에 먼저 배포했고, 사용자들은 에이전트 워크플로에서 최대 40% 개선을 보고했다. 이후 Codex는 Responses API 트래픽의 대부분을 WebSocket mode로 옮겼고, GPT-5.3-Codex-Spark에서는 목표였던 1,000 TPS를 달성했으며 순간적으로 4,000 TPS까지 치솟았다.

생태계 반응도 비슷했다.

• Vercel은 AI SDK에 WebSocket mode를 통합해 최대 40% 지연을 줄였다.
• Cline의 멀티파일 워크플로는 39% 빨라졌다.
• Cursor의 OpenAI 모델은 최대 30% 빨라졌다.

WebSocket mode는 Responses API 출시 이후 가장 중요한 새 기능 중 하나가 됐고, 모델 추론이 빨라질수록 그 주변 서비스와 시스템도 함께 빨라져야 한다는 점을 분명히 보여줬다.