
OpenAI 공식 엔지니어링 글에 따르면 회사는 3일(현지시간) 전체 이중 통신 기반 음성 모델 GPT-Live를 운영하기 위해 구축한 실시간 시스템 구조를 공개했다. 기존처럼 사용자의 발화 종료를 별도 탐지한 뒤 응답을 시작하는 대신, 모델이 음성을 계속 들으면서 동시에 말할 수 있도록 추론과 전송 경로를 다시 설계했다.
핵심은 음성 흐름과 나머지 애플리케이션 작업을 분리한 구조다. 이용자와 음성 모델 사이의 오디오는 전용 고속 경로로 이동하고, 프런티어 모델 위임과 도구 호출, 대화 저장은 비동기 RPC 경계 뒤에서 처리된다. 외부 도구나 백엔드 응답이 늦어져도 실시간 미디어 흐름은 멈추지 않도록 한 것이다.
OpenAI는 기존 Python asyncio 기반 구현을 Go로 교체해 미디어 프런트엔드와 추론 로직을 작성했다고 밝혔다. 회사 자체 비교에서 새 시스템의 프레임 전달 지연 p95는 이전 시스템의 p50 수준과 같았다. 이는 평균적인 상황뿐 아니라 지연이 큰 구간의 흔들림을 줄이는 데 초점을 맞춘 변화지만, 세부 측정 환경과 절대 지연 수치는 공개하지 않았다.
긴 대화를 유지하기 위한 상태형 추론 방식도 적용됐다. 모델 인스턴스를 교체해야 할 때 기존 인스턴스를 계속 실행하면서 새 인스턴스를 미리 준비하고, 현재 대화 문맥을 채운 뒤 두 인스턴스를 병렬로 돌려 준비가 끝나는 시점에 전환한다. 문맥 길이가 한계에 가까워져 압축이 필요할 때도 같은 방식으로 새 인스턴스를 준비해 음성 중단을 피한다.
복잡한 추론과 도구 사용은 GPT-Live가 프런티어 모델에 맡긴다. 음성 세션을 시작할 때부터 프런티어 모델 세션과 도구를 미리 준비하고, 같은 세션과 작업자 연결을 유지해 첫 결과가 돌아오는 시간을 줄인다. 지속적인 음성 스트림을 기존 대화 기록과 안전 시스템이 다룰 수 있는 메시지 단위로 바꾸기 위해 화면용 추정 기록과 분석용 확정 기록도 별도로 관리한다.
연결 시작 지연을 줄이기 위해 WebRTC 프로토콜 계층도 손봤다. OpenAI는 DTLS와 ICE, SCTP 협상 일부를 겹치거나 미리 처리하는 WARP와 SDP 매개변수를 사전 협상하는 Instant Connect를 결합했다. 회사 설명대로라면 사전 협상이 유효할 때 클라이언트는 하나의 UDP 패킷으로 세션을 시작할 수 있고, 실패하면 기존 신호 흐름으로 되돌아간다.
WARP는 아직 완성된 표준이 아니다. 7월 22일 공개된 IETF 인터넷 초안은 OpenAI와 Meta 연구자가 공동 작성한 작업 문서로, 현재 WebRTC의 데이터 채널 연결에 최대 6회의 네트워크 왕복이 필요하며 제안된 최적화를 함께 적용하면 이를 2회로 줄일 수 있다고 설명한다. OpenAI가 밝힌 단일 패킷 시작은 WARP만의 효과가 아니라 Instant Connect까지 포함한 전체 시스템 경로로 구분해 볼 필요가 있다.
이번 공개는 실시간 음성 AI의 경쟁이 모델 품질만으로 결정되지 않는다는 점을 보여준다. 대화 중 끼어들기와 맞장구를 자연스럽게 처리하려면 추론 서버, 문맥 관리, 도구 호출, 미디어 전송, 연결 협상이 하나의 지연 예산 안에서 움직여야 한다. OpenAI가 제시한 수치는 자체 운영 결과인 만큼 독립 비교는 더 필요하지만, 음성 에이전트 개발자에게는 저지연 경로와 업무 로직을 분리하는 구체적인 설계 사례가 됐다.
출처: OpenAI https://openai.com/index/continuous-voice-interaction-with-gpt-live/
출처: IETF Datatracker https://datatracker.ietf.org/doc/draft-uberti-tsvwg-warp/









