본문으로 건너뛰기
IFAI

AI 도구

오픈AI, Responses API에 웹소켓 지원: 에이전트 지연 시간 최대 40% 단축

게시 확산 지수 42

오픈AI가 Responses API에 웹소켓 모드를 도입했다. 매번 전체 대화 기록을 재검증하던 HTTP 방식 대신 지속적인 연결과 인메모리 캐시를 적용해 에이전트 워크플로 지연 시간을 최대 40% 줄이고 첫 토큰 응답 속도를 45% 앞당겼다. Cursor와 클라인 등 코딩 도구에 즉시 적용되었다.

오픈AI, Responses API에 웹소켓 지원: 에이전트 지연 시간 최대 40% 단축
이미지: openai.com

지금까지 AI 코딩 에이전트가 느렸던 이유는 모델이 글을 생성하는 시간 때문이었습니다. 그런데 하드웨어 발전으로 모델 추론이 극단적으로 빨라지자, 역설적으로 기존의 HTTP 통신 프로토콜이 전체 속도를 깎아먹는 병목으로 떠올랐습니다.

OpenAI가 Responses API에 WebSocket 지원을 추가했다고 밝혔습니다. 이로 인해 에이전트 기반 워크플로의 전체 지연 시간이 최대 40% 단축되었고, 첫 번째 토큰 생성 시간(TTFT)도 약 45% 빨라졌습니다.

모델은 빠른데 통신이 발목 잡던 구조

Codex 같은 코딩 에이전트는 한 번 질문하고 끝나는 구조가 아닙니다. 코드베이스를 훑고, 파일을 수정하고, 테스트를 돌리는 과정을 거치며 수십 번의 API 호출을 주고받습니다.

기존 HTTP 방식에서는 요청을 보낼 때마다 매번 새 연결을 맺고, 대화 기록 전체와 도구 정의를 다시 전송해 검증받아야 했습니다. GPT-5나 GPT-5.2가 초당 65토큰 수준으로 생성되던 시절에는 GPU 추론 시간이 길어 이 오버헤드가 크게 부각되지 않았습니다.

하지만 Cerebras 전용 칩셋을 활용하는 GPT-5.3-Codex-Spark가 등장하면서 상황이 바뀌었습니다. 초당 1,000토큰에서 최대 4,000토큰까지 쏟아내다 보니, 모델이 일하기도 전에 API 서버가 요청을 검증하느라 사용자를 대기시키는 병목이 발생한 것입니다.

상태를 메모리에 올려두는 WebSocket 방식

OpenAI는 개발자 친화성을 고려해 양방향 gRPC 대신 WebSocket을 선택했습니다. 지속적인 연결을 유지하면서 이전 응답 상태, 렌더링된 토큰, 도구 정의를 서버 메모리에 캐싱해 두는 방식입니다.

에이전트는 다음 작업을 요청할 때 previous_response_id만 넘겨주면 됩니다. 서버는 대화 기록을 처음부터 다시 파싱하지 않고 메모리에서 꺼내 쓰며, 안전성 검사 역시 새로 들어온 입력값에 대해서만 수행합니다. 중간 서비스 호출 단계를 줄이고 과금 처리 같은 비동기 작업을 뒤로 뺀 최적화도 함께 적용되었습니다.

효과는 즉각적이었습니다. Vercel의 AI SDK에서는 지연 시간이 최대 40% 줄었고, Cline의 다중 파일 워크플로는 39% 빨라졌으며, Cursor 환경에서도 OpenAI 모델 구동 속도가 최대 30% 향상되었습니다.

왜 중요한가

AI 인프라의 병목 지점이 모델 자체의 연산에서 주변 네트워크와 전송 파이프라인으로 이동하고 있음을 보여주는 사례입니다.

Cursor나 Cline 같은 에이전트 도구를 매일 다루는 개발자에게 이번 업데이트는 체감이 매우 큰 변화입니다. 여러 파일을 넘나들며 테스트를 반복하는 복잡한 작업에서 30~40%의 대기 시간이 사라지면, 작업 흐름이 끊기지 않고 거의 실시간 협업에 가까운 경험을 얻을 수 있습니다.

OpenAI가 파격적인 전용 프로토콜을 강제하는 대신 기존 response.create 구조를 그대로 유지해 진입 장벽을 낮춘 점도 영리합니다. 초고속 추론 칩이 보편화되는 환경에서, 이제 Anthropic이나 Google 같은 경쟁사들도 모델 속도 자랑을 넘어 API 전송 계층을 손보지 않을 수 없게 되었습니다.

출처 (1)

  1. [1]
    openai.com(새 탭에서 열림)원문openai.com

매일 AI 콘텐츠 픽