한눈에 보기
- 발표 내용: OpenAI가 2026년 4월 22일 Responses API에 WebSocket mode를 도입했다고 밝혔다.
- 핵심 변화: 반복적인 HTTP 요청/응답과 매번 다시 처리되는 상태 관리 비용을 줄이기 위해 지속 연결과 세션 재사용 쪽으로 구조를 바꿨다.
- 성능 포인트: OpenAI는 agentic workflow가 end-to-end 기준 최대 40% 빨라졌고, GPT-5.3-Codex-Spark에서 sustained throughput 1,000 TPS 목표와 burst 4,000 TPS를 확인했다고 설명했다.
- 배경: 같은 날 OpenAI는 ChatGPT workspace agents도 발표했다. Google과 Anthropic도 long-running agents, agent platform, coding workflow 개선을 강조하고 있다.
- 내 결론: AI 에이전트 경쟁은 이제 "어떤 모델이 더 똑똑한가"만으로 설명하기 어렵다. 모델을 둘러싼 런타임, API, 상태, 도구 오케스트레이션이 실제 체감 속도를 크게 좌우하는 구간으로 들어왔다.
이번 발표, 뭐가 바뀐 건가
OpenAI가 Responses API에 WebSocket mode를 공개했다. 이름만 보면 통신 방식 하나 추가된 것처럼 보이지만, 이번 글에서 OpenAI가 직접 꺼낸 문제의식은 꽤 흥미롭다. Codex 같은 에이전트가 버그를 고칠 때를 예로 들면, 모델이 한 번 답하고 끝나는 게 아니다. 관련 파일을 찾고, 읽고, 수정하고, 테스트를 돌리고, 결과를 다시 모델에 넘긴다. 이 과정이 여러 번 반복된다.
기존 방식에서는 이런 단계마다 Responses API 요청이 오갔다. 모델의 다음 행동을 정하고, 로컬 도구를 실행하고, 도구 결과를 다시 API로 보내고, 또 다음 행동을 정하는 식이다. OpenAI는 이런 왕복이 복잡한 작업에서는 사용자가 기다리는 시간으로 쌓인다고 설명했다.
중요한 건 여기다. 예전에는 LLM inference, 그러니까 GPU에서 토큰을 생성하는 시간이 워낙 컸기 때문에 API 서비스 오버헤드가 상대적으로 덜 보였다. 그런데 모델 추론 속도가 빨라지자, 이제는 API 서비스에서 요청을 검증하고 처리하는 시간, 클라이언트에서 도구를 실행하고 컨텍스트를 다시 만드는 시간이 더 눈에 띄기 시작했다.
쉽게 말하면 예전 병목은 "모델이 생각하는 시간"에 가까웠고, 이제는 "모델에게 일을 계속 시키기 위해 주변 시스템이 움직이는 시간"이 병목으로 올라온 셈이다.
WebSocket mode가 겨냥한 병목
OpenAI가 이번에 택한 방향은 지속 연결이다. 매번 새 HTTP 요청을 만들고 전체 대화 상태를 다시 처리하는 대신, WebSocket 연결을 유지하면서 이전 response 상태를 연결 범위의 메모리 캐시에 보관한다. 이후 요청이 previous_response_id를 포함하면, 서버가 그 상태를 처음부터 다시 만들지 않고 캐시에서 가져오는 방식이다.
OpenAI가 설명한 캐시 대상에는 이전 response 객체, 과거 입력과 출력 아이템, tool 정의와 namespace, 이미 렌더링된 토큰 같은 재사용 가능한 sampling artifact가 들어간다. 이걸 통해 안전 분류기와 요청 validator가 매번 전체 history를 보지 않고 새 입력만 처리하게 하거나, tokenization 같은 반복 작업을 줄일 수 있었다고 한다.
여기서 개인적으로 눈에 들어온 건 "API 모양은 최대한 익숙하게 유지했다"는 부분이다. OpenAI는 초기 prototype에서 agentic rollout을 하나의 long-running Response처럼 다루는 방식도 실험했다. 하지만 최종 공개 버전에서는 기존 Responses API의 response.create 형태를 유지하고, WebSocket 연결 위에서 상태 재사용을 얹었다. 개발자 입장에서는 완전히 새로운 mental model을 받아들이기보다, 기존 API 형태를 유지하면서 transport와 상태 처리 쪽 이점을 얻는 쪽에 가깝다.
OpenAI는 이 방식으로 agent loop가 end-to-end 기준 40% 빨라졌다고 설명했다. GPT-5.3-Codex-Spark에서는 목표였던 sustained throughput 1,000 TPS를 달성했고, burst는 4,000 TPS까지 확인했다고 밝혔다. Vercel AI SDK 통합, Cline의 multi-file workflow, Cursor에서의 OpenAI 모델 속도 개선 사례도 함께 언급됐다.
왜 하필 지금 WebSocket인가
이번 발표를 모델 출시 뉴스처럼만 보면 조금 밋밋할 수 있다. 하지만 같은 주의 흐름을 같이 놓고 보면 메시지가 더 분명해진다.
OpenAI는 같은 2026년 4월 22일 ChatGPT workspace agents도 발표했다. 팀이 공유해서 쓰는 Codex-powered agents이고, ChatGPT와 Slack 안에서 쓸 수 있으며, long-running workflow를 처리하고, 승인과 권한, Compliance API 같은 기업용 통제 장치도 강조했다. OpenAI 설명에 따르면 이 agent들은 클라우드에서 계속 작업할 수 있고, 코드 실행, 연결 앱 사용, memory, 여러 단계 작업 지속 같은 기능을 갖는다.
이런 에이전트가 실제 업무 흐름으로 들어오면 단순 질의응답보다 실행 시간이 길어진다. Slack에서 요청을 받고, 문서를 찾고, 도구를 실행하고, 사람이 승인해야 하는 지점에서 멈췄다가 다시 이어가고, 결과를 다른 시스템에 반영하는 식이다. 이때는 모델 성능만 좋아서는 부족하다. 상태가 유지돼야 하고, 도구 호출이 안정적으로 이어져야 하며, 매 단계마다 쓸데없는 왕복 비용이 작아야 한다.
Google 발표도 같은 방향을 가리킨다. Google Cloud Next 26에서 Google은 Gemini Enterprise Agent Platform을 발표하면서 Agent Designer, Inbox, Skills, Projects, long-running agents를 강조했다. 특히 long-running agents는 복잡한 비즈니스 프로세스를 실행하고, secure cloud sandbox에서 자율적으로 작업하며, multi-step workflow를 처리하도록 설계됐다고 설명했다. Agent Gateway, Agent Observability, Agent Sessions, Memory Bank 같은 구성도 함께 나왔다.
Anthropic도 Claude Opus 4.7 발표에서 advanced software engineering, complex long-running tasks, coding workflow 개선을 강조했다. 초기 사용자 피드백에는 async workflows, CI/CD, long-running tasks, multi-step coding workflow 같은 표현이 반복된다. 결국 세 회사가 서로 다른 제품을 내고 있지만, 방향은 비슷하다. 에이전트가 길게 일하고, 도구를 쓰고, 상태를 들고 다니는 쪽으로 가고 있다.
모델 속도가 빨라질수록 API가 더 중요해지는 이유
아이러니하게도 모델이 빨라질수록 API와 런타임이 더 중요해진다. 모델이 느릴 때는 주변 시스템이 조금 비효율적이어도 전체 대기 시간에서 티가 덜 난다. 그런데 OpenAI가 GPT-5.3-Codex-Spark에서 1,000 TPS를 목표로 잡을 정도로 추론 속도를 밀어붙이면, API 서비스에서 반복적으로 상태를 재구성하는 비용이 더 크게 보인다.
OpenAI가 말한 구조적 문제도 이 지점이다. 각 Codex 요청을 독립적인 요청처럼 다루면, 후속 요청마다 conversation state와 재사용 가능한 context를 다시 처리하게 된다. 대부분의 대화가 바뀌지 않았는데도 전체 history에 묶인 비용을 계속 내는 셈이다. 에이전트 작업이 길어질수록 이 반복 비용은 더 커진다.
그래서 WebSocket mode의 핵심은 "통신을 WebSocket으로 바꿨다"라기보다 "에이전트 실행 중 재사용 가능한 상태를 어디에 두고, 얼마나 덜 반복할 것인가"에 가깝다. persistent connection, low-latency bidirectional communication, session reuse, async tool orchestration 같은 키워드가 나오는 이유도 여기에 있다.
이건 개발자에게도 꽤 현실적인 신호다. 앞으로 에이전트 제품을 만들 때는 모델 선택만큼이나 실행 루프를 봐야 한다. 도구 호출 결과를 어떻게 넘기는지, 이전 상태를 어떻게 이어가는지, 긴 작업 중 실패나 승인 대기를 어떻게 처리하는지, 사용자가 기다리는 시간을 어디서 줄일 수 있는지가 제품 품질이 된다.
좋은 점
- Codex류 에이전트처럼 도구 호출이 잦은 workflow에서 반복 HTTP 왕복과 상태 재처리 비용을 줄이는 방향이 명확하다.
- 기존 Responses API의 입력/출력 형태를 크게 흔들지 않고 WebSocket mode를 붙인 점은 개발자 전환 비용을 낮추는 선택으로 보인다.
- OpenAI가 모델 inference 외부의 API 서비스 오버헤드를 공개적으로 병목으로 지목했다는 점이 의미 있다.
- ChatGPT workspace agents, Google Gemini Enterprise Agent Platform, Claude Opus 4.7 발표까지 함께 보면, long-running agent를 위한 실행 인프라 경쟁이 본격화되는 분위기다.
주의할 점
- OpenAI가 제시한 최대 40% 개선은 agentic workflow 기준 설명이다. 모든 API 사용 패턴에서 같은 개선이 나온다고 볼 수는 없다.
- WebSocket mode의 체감 효과는 도구 호출 빈도, conversation length, 상태 재사용 방식, 클라이언트 구현에 따라 달라질 가능성이 크다.
- 지속 연결과 in-memory cache는 성능상 유리하지만, 운영 관점에서는 연결 관리, 장애 복구, 세션 만료, 재시도 설계 같은 문제가 따라온다.
- 이번 글은 OpenAI 발표와 관련 회사 발표를 정리한 것이며, 직접 벤치마크나 실제 사용 후기는 포함하지 않았다.
내 생각
이번 발표는 "OpenAI가 WebSocket을 지원합니다" 정도로 끝낼 뉴스는 아닌 것 같다. 더 큰 흐름은 AI 에이전트가 점점 일반 채팅에서 벗어나 실제 업무 실행 단위로 이동하고 있다는 점이다. 그렇게 되면 모델이 답을 잘하는 것만큼이나, 모델이 일을 끊기지 않고 이어가게 만드는 주변 시스템이 중요해진다.
특히 에이전트는 보통 한 번에 끝나지 않는다. 파일을 읽고, 검색하고, 테스트하고, 다시 판단하고, 필요하면 사람에게 묻는다. 여기서 매번 전체 상태를 다시 읽고, 같은 검증을 반복하고, 요청/응답을 동기적으로 기다리면 모델이 아무리 빨라도 체감은 느릴 수밖에 없다.
개인적으로는 앞으로 AI 제품 리뷰를 볼 때 "어떤 모델을 썼나"만 보는 습관을 조금 바꿔야겠다는 생각이 들었다. 어떤 runtime에서 돌아가는지, session을 어떻게 유지하는지, tool orchestration이 얼마나 자연스러운지, 긴 작업을 중간에 잃어버리지 않는지가 점점 더 큰 차이를 만들 것 같다.
여러분은 AI 에이전트에서 더 답답한 병목이 모델 품질이라고 느끼시나요, 아니면 도구 호출과 대기 시간 같은 실행 경험이라고 느끼시나요? 댓글로 실제로 불편했던 지점을 남겨주시면 다음 글에서 같이 이어서 정리해보겠습니다.
결론
OpenAI의 Responses API WebSocket mode 공개는 단순한 transport 옵션 추가라기보다, 에이전트 시대의 병목이 어디로 옮겨가고 있는지 보여주는 발표에 가깝다. 모델 inference가 빨라질수록 반복 API 처리, 상태 재구성, 도구 호출 왕복, 비동기 orchestration의 비용이 더 크게 드러난다.
같은 시점에 OpenAI는 workspace agents를, Google은 Gemini Enterprise Agent Platform을, Anthropic은 Claude Opus 4.7의 long-running coding workflow 개선을 강조했다. AI 에이전트 경쟁은 이제 모델 성능표만으로 설명하기 어렵다. 앞으로는 모델을 실제 업무 흐름 안에서 오래, 빠르게, 안전하게 굴리는 실행 인프라가 더 자주 뉴스의 중심에 설 것 같다.