OpenAI가 대규모 저지연 Voice AI를 제공하는 방법

TL;DR Highlight

OpenAI가 9억 명 이상의 사용자에게 실시간 음성 AI를 제공하기 위해 WebRTC 스택을 어떻게 재설계했는지 설명하는 글로, relay + transceiver 분리 아키텍처의 설계 결정과 trade-off를 상세히 다룬다.

Who Should Read

실시간 음성/오디오 기능을 앱에 붙이려는 백엔드/인프라 개발자, 또는 WebRTC를 Kubernetes 환경에서 운영하면서 포트 관리나 라우팅 문제로 고생하고 있는 개발자.

Core Mechanics

WebRTC는 브라우저·모바일·서버에 이미 구현된 표준 프로토콜이기 때문에 OpenAI가 선택했다. ICE(NAT 통과), DTLS/SRTP(암호화 전송), 코덱 협상, RTCP(품질 제어), 에코 캔슬링·지터 버퍼링 같은 저수준 처리를 직접 구현하지 않아도 된다는 게 핵심 이유다.
음성 AI에서 가장 중요한 특성은 오디오가 연속 스트림으로 도착한다는 점이다. 덕분에 사용자가 말하는 도중에도 모델이 동시에 전사·추론·도구 호출·음성 생성을 시작할 수 있고, 이게 '대화 느낌'과 '푸시투토크 느낌'의 차이를 만든다.
기존 WebRTC 서버 방식인 SFU(Selective Forwarding Unit)는 세션마다 별도 포트를 열어야 하는데, 이 '1포트 1세션' 모델이 OpenAI 인프라 규모에서 Kubernetes와 충돌하는 핵심 문제였다. 스테이트풀한 ICE/DTLS 세션이 특정 노드에 고정되어야 해서 수평 확장이 어렵다.
이를 해결하기 위해 relay + transceiver 분리 아키텍처를 설계했다. relay는 글로벌 엣지에 배치해 클라이언트와의 첫 번째 홉 지연을 최소화하고, transceiver는 내부 인프라에서 실제 미디어 처리와 모델 연결을 담당하는 방식으로 역할을 나눴다.
클라이언트 입장에서는 표준 WebRTC 동작을 그대로 경험하면서, 내부적으로는 패킷 라우팅 방식이 완전히 바뀐 구조다. ICE credential(연결 수립 시 교환하는 인증 토큰)을 기반으로 라우팅 결정을 내려 stateful 세션을 올바른 transceiver로 연결한다.
글로벌 relay와 지오스티어링(사용자 위치 기반 자동 라우팅) 시그널링을 조합해서, 전 세계 어디에서든 첫 번째 네트워크 홉이 가까운 relay로 연결되도록 설계했다. 이게 900만이 아닌 9억 명 규모에서 지연을 낮게 유지하는 핵심이다.
이 아키텍처를 구현하는 데 오픈소스 Go WebRTC 라이브러리인 Pion(https://github.com/pion/webrtc)을 활용했고, Pion 창시자인 Sean DuBois가 현재 OpenAI에 합류해 있다고 언급했다.
현재 Realtime API의 음성 모델은 GPT-4o 계열에 머물러 있어, 아키텍처 개선과 달리 모델 자체의 능력은 최신 frontier 모델 수준이 아닌 상황이다.

Evidence

Pion 라이브러리 개발자가 직접 댓글을 달아 OpenAI가 사용 사실을 공개한 것에 감사를 표하며, WebRTC 입문 자료로 'WebRTC for the Curious(webrtcforthecurious.com)'를 추천했다.
WebRTC + Kubernetes 게임 스트리밍 제품을 만든 경험자가 강한 반론을 제기했다. 'OpenAI가 설명한 문제들은 대부분 WebRTC 자체가 아니라 libwebrtc 구현의 문제'이며, 'libwebrtc의 feature flag를 올바르게 설정하면 Twilio 같은 유료 네트워크 우회 없이도 지연을 무료로 줄일 수 있다'는 주장이다. 또한 '99%의 일반 사용자 환경에서는 relay나 transceiver 없이도 Kubernetes에서 완전히 동작한다'고 했다.
저지연 자체가 UX 문제를 만든다는 사용자 경험이 공유됐다. 사람은 대화 중 자연스럽게 쉬는데, 시스템이 이 멈춤을 '발화 종료'로 인식해 끼어드는 문제가 있고, 단어를 찾느라 잠깐 멈추는 사람에게는 오히려 더 불편하다는 의견이다.
OpenAI가 Realtime API용 오픈소스 Voice AI 파이프라인 프레임워크인 pipecat(https://github.com/pipecat-ai/pipecat)을 언급하지 않았지만, 댓글에서 '이 영역에 입문하려면 pipecat이 좋은 출발점'이라는 추천이 있었다.
OpenAI가 이전에 사용하던 LiveKit 대신 직접 WebRTC 스택을 구축한 것이냐는 질문이 나왔고, 이에 대한 공식 답변은 없었지만 아키텍처 설명 자체가 자체 구축임을 시사한다는 맥락이 있었다.

How to Apply

Kubernetes 환경에서 WebRTC 서버를 운영 중인데 1포트 1세션 문제로 스케일 아웃이 막힌다면, relay(엣지, stateless)와 transceiver(내부, stateful) 역할을 분리하고 ICE credential 기반으로 라우팅하는 패턴을 참고해 아키텍처를 재설계할 수 있다.
실시간 음성 AI 서비스를 빠르게 프로토타이핑하려면 직접 WebRTC 스택을 구현하기 전에 pipecat(https://github.com/pipecat-ai/pipecat)이나 Pion(https://github.com/pion/webrtc)을 먼저 검토하면 OpenAI 수준의 저수준 구현 없이 빠르게 시작할 수 있다.
Voice AI의 '발화 종료 감지(end-of-turn detection)' 로직을 구현할 때, 단순 무음 타이머만 쓰면 사용자가 단어를 찾느라 잠깐 멈추는 경우에도 끊어버리는 문제가 생긴다. 이 글과 댓글을 참고해 silence threshold를 사용자 조정 가능하게 만들거나, 발화 중간 멈춤과 발화 종료를 구분하는 로직을 별도로 설계하는 것이 좋다.
libwebrtc 기반으로 WebRTC를 운영 중이라면, 댓글에서 언급된 것처럼 feature flag 설정만으로 해결 가능한 지연 문제가 있을 수 있다. 유료 네트워크 우회 솔루션이나 복잡한 인프라 변경 전에 libwebrtc의 ICE candidate 관련 플래그 설정을 먼저 점검해볼 것.

Terminology

WebRTC브라우저와 모바일 앱에서 플러그인 없이 실시간 오디오·비디오를 전송하기 위한 오픈 표준. NAT 방화벽 통과, 암호화, 코덱 협상 등 까다로운 부분이 이미 구현되어 있다.

ICEInteractive Connectivity Establishment의 약자. 방화벽이나 NAT 뒤에 있는 두 기기가 서로를 찾아 연결을 맺을 수 있도록 경로를 탐색하는 프로토콜이다.

SFUSelective Forwarding Unit. 각 참가자의 스트림을 받아서 다른 참가자들에게 선택적으로 포워딩하는 미디어 서버. Zoom이나 Discord처럼 여러 사람이 참여하는 통화에 자주 쓰인다.

DTLSDatagram Transport Layer Security. UDP 위에서 TLS와 같은 암호화를 제공하는 프로토콜. WebRTC 미디어 전송 암호화에 사용된다.

SRTPSecure Real-time Transport Protocol. 음성·영상 스트림 자체를 암호화하는 프로토콜. DTLS로 키를 교환한 후 실제 미디어 페이로드를 이걸로 보호한다.

지오스티어링사용자의 위치를 기반으로 DNS나 로드밸런서가 자동으로 가장 가까운 서버로 연결해주는 기법. 글로벌 서비스에서 첫 번째 홉 지연을 줄이는 데 핵심적이다.