OpenAI가 Responses API에 WebSocket 모드를 추가했다. 핵심은 새 엔드포인트가 아니라, 도구 호출이 많은 에이전트형 워크플로에서 연결을 계속 유지하며 턴을 이어갈 수 있게 했다는 점이다. OpenAI는 20회 이상 연속 도구 호출이 있는 흐름에서 종단 간 실행 시간이 약 40% 빨라질 수 있다고 설명한다.1
그래서 지금 중요한 질문은 "Chat Completions를 Responses API로 어떻게 바꾸지?"가 아니다. 더 실무적인 질문은 이것이다. 모델이 대화와 도구 흐름을 더 많이 오케스트레이션하게 둘 때, 우리 스택에서 무엇이 단순해지고, 무엇이 더 까다로워지는가.
엔드포인트 교체가 아니라, 오케스트레이션 책임의 재배치다
Responses API는 채팅 응답 생성 API라기보다 상태와 도구 사용을 다루는 실행 단위에 가깝다. previous_response_id로 이전 응답을 이어 붙일 수 있고, 응답을 저장·조회·삭제하거나, 긴 컨텍스트를 compact로 압축하는 식의 상태 관리 수단도 함께 제공한다.2
이 변화가 주는 첫 번째 이점은 글루 코드 감소다. Chat Completions 중심 구조에서는 이전 메시지, 도구 호출 결과, 요약된 상태를 애플리케이션이 직접 관리해야 했다. Responses API는 이 중 일부를 서버 측 상태와 응답 체인으로 흡수한다. 특히 도구 호출이 여러 번 오가는 흐름에서는 "전체 히스토리 재전송 + 상태 재구성" 비용을 줄이기 쉽다.3
하지만 그 단순화에는 대가가 있다. 상태를 API가 더 많이 맡을수록, 디버깅 포인트는 애플리케이션 바깥으로 이동한다. 어떤 턴에서 왜 그 도구를 골랐는지, 압축 이후 무엇이 남았는지, 재연결 시 어떤 상태가 유효한지 같은 문제는 오히려 더 중요해진다. 즉, Responses API는 "항상 더 낫다"기보다 "오케스트레이션 부담을 어디에 둘지"를 다시 정하게 만든다.
WebSocket이 빛나는 앱과, 굳이 안 써도 되는 앱
WebSocket 모드가 특히 잘 맞는 건 도구를 많이 부르는 에이전트형 앱이다. 예를 들어 코딩 에이전트가 파일을 읽고, 테스트를 돌리고, 결과를 다시 해석하며 여러 번 왕복하는 경우다. 이때 HTTP 기반 반복 호출은 모델 추론보다 연결 수립과 컨텍스트 재전송 오버헤드가 커질 수 있다. WebSocket은 연결을 유지하고, 직전 응답 상태를 연결 단위 메모리에 두며, 다음 턴에 변경분만 보내게 해 이 비용을 줄인다.14
반대로 단일 질의응답, 짧은 멀티턴 챗봇, 도구 호출이 1~3회 수준인 제품이라면 이야기가 다르다. 이런 경우 HTTP 스트리밍만으로도 충분하고, WebSocket의 운영 복잡성은 체감 이득보다 클 수 있다.4 "에이전트스럽다"는 이유만으로 전부 WebSocket으로 옮길 필요는 없다.
중간 지점도 있다. 검색과 파일 조회가 자주 붙는 코파일럿류 앱이다. 이 경우 Responses API 자체는 꽤 유효하다. 내장 도구, 상태 연결, 멀티모달 입력 같은 통합 이점이 있기 때문이다.5 다만 WebSocket까지 갈지는 "세션당 몇 번이나 모델-도구-모델 왕복이 생기나"로 판단하는 편이 정확하다.
숨은 비용은 속도가 아니라 운영이다
문제는 성능 수치가 아니라 실패 경로다. 확인된 제약만 봐도 운영 관점의 판단 포인트가 뚜렷하다. WebSocket 연결 하나는 동시에 하나의 응답만 처리하며, 병렬 실행에는 여러 연결이 필요하다.4 연결은 장시간 유지되지 않고, 끊기면 재연결 로직이 필요하다. store=false나 ZDR처럼 저장을 최소화한 구성을 쓰면, 연결 메모리에만 있던 상태가 사라졌을 때 전체 컨텍스트 재전송이나 compaction 기반 재시작 전략이 필요하다.24
여기서 제품 UX도 바뀐다. 사용자는 더 "대화형"이라기보다 "작업이 진행되는" 인터페이스를 기대하게 된다. 그래서 단순 타이핑 애니메이션보다, 현재 어떤 도구를 호출 중인지, 실패 시 어디서 복구되는지, 장기 작업은 백그라운드로 넘길지 같은 설계가 중요해진다. Responses API는 앱을 더 똑똑하게 만들 수 있지만, 그만큼 사용자에게 설명해야 할 상태도 늘린다.
지금 옮길지 판단하는 기준
지금 Responses API를 적극 검토할 팀은 세 부류다. 첫째, 도구 호출이 잦은 코딩 에이전트나 업무 자동화 제품. 둘째, 대화 상태와 도구 실행 흐름을 직접 관리하느라 백엔드 복잡도가 커진 팀. 셋째, 장기적으로 Assistants 계열 기능을 통합된 런타임으로 재정리하려는 팀이다.25
반대로 아직 단순 패턴에 머무는 제품은 서두를 이유가 크지 않다. 짧은 FAQ 봇, 단순 요약기, 단발성 생성 기능이라면 Chat Completions 혹은 HTTP 기반 Responses API만으로도 충분할 가능성이 높다. 이 경우 더 중요한 일은 WebSocket 도입이 아니라 프롬프트 캐싱, 출력 길이 제한, 관측성 설계 같은 기본기다.
결국 Responses API의 가치는 "최신 API"라서가 아니라, 앱의 실행 책임을 모델 쪽으로 얼마나 넘길지 선택하게 만든다는 데 있다. 그리고 WebSocket 모드는 그 선택이 진짜 성능 이득으로 이어지는 좁지만 중요한 구간--도구 호출이 길게 이어지는 에이전트 루프--에서 특히 강하다. 지금 신경 써야 할 사람은 챗봇을 하나 더 만드는 팀이 아니라, 이미 모델이 도구를 부리기 시작해 백엔드 구조가 흔들리는 팀이다.
참고
1Speeding up agentic workflows with WebSockets in the Responses API
4OpenAI's WebSocket mode: persistent connections for agentic workloads
이 노트는 보도·비평·교육·연구 목적으로 작성되었습니다. 저작권 문의가 있으시면 에서 알려주세요.