OpenAI의 저지연 음성 AI 확장을 위한 WebRTC 스택 재설계 기술 분석

서론

음성을 통한 AI 상호작용은 텍스트 기반의 채팅과는 근본적으로 다른 제약을 가진다. 인간이 대화에서 느끼는 '자연스러움'은 응답 지연(Latency)이 300밀리초를 넘어서는 시점에서 급격히 손상된다고 알려져 있으며, 여기에 턴 테이킹(Turn-taking, 화자 교체) 타이밍의 정밀도와 음성 품질의 일관성까지 포함하면 엔지니어링 측면의 요구 수준은 매우 높아진다.

2026년 5월, OpenAI는 엔지니어링 블로그를 통해 Realtime API를 뒷받침하는 WebRTC 스택을 대규모로 재설계한 경위와 기술적 상세 내용을 공개했다[1]. 9억 명 규모의 사용자를 보유한 서비스에서 저지연 음성 AI를 안정적으로 가동하기 위해, 동사가 어떠한 아키텍처상의 판단을 내렸는지는 기업용 음성 AI 시스템 설계를 검토하는 데 있어서도 많은 시사점을 제공한다. 본고에서는 그 기술적 배경과 구현상의 포인트를 정리한다.

기존 WebRTC가 대규모 Kubernetes 환경에서 겪는 3가지 제약

OpenAI가 WebRTC 스택의 재설계를 단행한 근본적인 이유는 표준 WebRTC의 설계 사상이 동사의 Kubernetes 기반 인프라와 구조적으로 상성이 좋지 않았기 때문이다[1:1].

1. 세션별 전용 UDP 포트 문제

표준 WebRTC는 세션 단위로 퍼블릭 UDP 포트를 점유하는 'one-port-per-session' 모델을 전제로 한다. 수백만 세션이 동시에 가동되는 스케일에서는 포트 관리, 보안 확보, Kubernetes 클러스터 전체로의 공개가 현실적으로 불가능해진다. 컨테이너화된 인프라에게 상태(State)를 가진 UDP 포트의 대량 관리는 운영 비용을 현저히 증가시킨다.

2. 스테이트풀(Stateful)한 ICE/DTLS 프로토콜

WebRTC의 연결 확립에 사용되는 ICE (Interactive Connectivity Establishment)와 DTLS (Datagram Transport Layer Security)는 모두 세션 상태를 유지하는 스테이트풀 프로토콜이다. 이는 특정 세션의 패킷이 항상 동일한 프로세스에 도달해야 함을 의미한다. 이는 Kubernetes 상에서의 오토스케일링(Auto-scaling)이나 포드(Pod)의 재스케줄링과 상성이 좋지 않아, 가용성을 유지하면서 스케일 아웃(Scale-out)을 하는 것이 어려웠다.

3. 음성 품질을 보장하는 패킷 관리

음성 통신에서의 품질 유지에는 지터(Jitter) 제어, 패킷 손실 보간 처리, 혼잡 제어(Congestion Control) 등 실시간성과 신뢰성을 양립시킨 섬세한 패킷 관리가 필요하다. 표준 WebRTC 스택의 이러한 기능들을 클라우드 네이티브한 스케일링 요구사항과 양립시키는 설계는 기성 솔루션으로는 구현하기 어려운 상황이었다.

스플릿 릴레이(Split Relay) + 트랜시버(Transceiver) 아키텍처로의 전환

위의 세 가지 제약을 해소하기 위해 OpenAI가 채택한 것이 '스플릿 릴레이 + 트랜시버'라고 불리는 독자적인 아키텍처이다[1:2][2].

이 설계의 핵심은 '패킷 라우팅'과 'WebRTC 세션 상태 관리'를 두 종류의 서로 다른 컴포넌트로 분리하는 데 있다.

스테이트리스 릴레이 (Stateless Relay): 수신한 패킷을 ICE 사용자 이름 프래그먼트(username fragment)에 삽입된 라우팅 메타데이터를 바탕으로 전달만 하는 컴포넌트. 상태를 가지지 않기 때문에 Kubernetes를 통한 수평 확장(Horizontal Scaling)이 용이하며, 퍼블릭에 공개되는 UDP 풋프린트를 최소화할 수 있다.

스테이트풀 트랜시버 (Stateful Transceiver): ICE, DTLS, SRTP와 같은 WebRTC 세션 상태 전체를 관리하는 컴포넌트. 세션의 소유권을 일원적으로 가지며, 음성 품질과 관련된 패킷 처리도 여기서 수행된다. 클라이언트 입장에서는 기존의 표준적인 WebRTC 동작과 동일하게 보인다.

이러한 분리를 통해 클라이언트 측의 구현 변경을 전혀 요구하지 않고도 인프라 측에서 Kubernetes 친화적인 스케일링을 실현하고 있다. 릴레이와 트랜시버 사이에 원홉(One-hop) 전송이 추가되지만, 이 추가 지연 시간(Latency)은 최소한으로 억제되어 있으며, 전체적인 엔드 투 엔드(End-to-End) 지연 시간 감소 효과가 이를 크게 상회한다고 평가된다[2:1].

TTFB 최소화와 턴 테이킹의 정밀도 향상

확장성 외에도 OpenAI는 Realtime API에서의 TTFB (Time to First Byte) 최소화와 턴 테이킹의 자연스러움 개선에도 주력하고 있다[3].

엔드투엔드 (End-to-End) Speech-to-Speech 모델

기존의 음성 AI 시스템은 음성 인식 (STT) → 텍스트 처리 (LLM) → 음성 합성 (TTS)라는 3단계 파이프라인 구성이 일반적이었다. 각 단계에서 레이턴시 (Latency)가 발생하며, 300밀리초를 크게 초과하는 일도 드물지 않았다. Realtime API는 이 3단계를 하나의 엔드투엔드 (End-to-End) speech-to-speech 모델로 통합함으로써, 중간 단계의 텍스트 변환 처리를 배제하고 응답 지연의 대폭적인 절감을 실현하고 있다[4].

내장 VAD 및 바지인 (Barge-in) 대응

대화에서의 자연스러운 턴 테이킹 (Turn-taking)에는 음성 활동 감지 (VAD, Voice Activity Detection)의 정밀도가 필수적이다. Realtime API는 VAD를 모델 레벨에서 내장함으로써, 화자가 발화를 시작하는 순간 AI가 응답 생성을 중단하는 '바지인 (Barge-in)' 기능을 실현하고 있다[3:1]. 이를 통해 사용자가 발화 도중에도 말을 끊고 들어올 수 있는, 인간 사이의 대화에 가까운 인터랙션 경험을 제공할 수 있게 되었다.

AWS의 유사 접근 방식과의 비교

OpenAI의 접근 방식과 비슷한 시기에 AWS도 독자적인 음성 AI 스케일링 기법을 공개했다. Amazon Nova Sonic을 이용한 구성에서는 WebRTC를 활용한 실시간 음성 스트리밍 기반 구축 방법이 상세히 설명되어 있으며[5][6], 멀티링구얼 (Multilingual) 대응 및 모바일·데스크톱의 크로스 플랫폼 호환성을 과제로 나열하고 있다.

두 방식의 접근법을 비교하면, 인프라상의 과제 설정 (WebRTC × Kubernetes × 저지연)은 공통적이지만, OpenAI는 자사 모델과 인프라를 수직 통합함으로써 엔드투엔드 (End-to-End) 최적화를 추구하는 반면, AWS는 기존의 매니지드 서비스(Managed Service)나 파트너의 오픈 소스 (OSS) 프레임워크 (Stream Vision Agents 등)를 조합함으로써 에코시스템으로서의 확장성을 중시하는 방향성을 취하고 있다고 볼 수 있다.

기업 구현 시 설계상의 시사점

OpenAI의 아키텍처 혁신이 보여주는 지견은 기업용 음성 AI 시스템 설계에 있어서도 몇 가지 중요한 시사점을 포함하고 있다.

스테이트풀 (Stateful) 관리의 중요성

음성 AI 스케일링에서의 최대 제약은 모델의 추론 비용이 아니라 네트워크 계층의 스테이트풀 (Stateful) 특성에 있다. WebRTC에 국한되지 않고 세션 상태를 가지는 프로토콜을 Kubernetes와 같은 컨테이너화 환경에서 운용할 경우, 스테이트 (State) 분리 설계를 초기 단계부터 검토에 포함해야 한다. 사후 리팩토링은 OpenAI가 경험했듯이 대규모 재설계를 요할 가능성이 있다.

처리량(Throughput)과 레이턴시(Latency)는 트레이드오프가 아니다

스플릿 릴레이 (Split Relay) 설계는 처리량 (병렬 세션 수)과 레이턴시 (응답 지연)를 동시에 개선하는 데 성공했다. 이 설계 사상은 '스케일과 품질은 트레이드오프 관계'라는 선입견에 대한 반증이라 할 수 있다. 적절한 아키텍처 분리가 이루어진다면 양립이 가능하다는 것을 보여준다.

파이프라인 구성의 선택

STT/LLM/TTS의 3단계 파이프라인과 speech-to-speech 모델 중 무엇을 선택할지는 단순한 레이턴시 비교만으로는 판단할 수 없다. HIPAA 등의 컴플라이언스 (Compliance) 요건이나 기존 시스템과의 통합 제약이 있는 경우에는 파이프라인 구성이 더 유연성을 확보하기 쉬운 경우도 있다[3:2]. speech-to-speech 모델로의 이행은 저지연의 혜택이 큰 반면, 모델의 해석 가능성이나 디버깅 난이도가 높아지는 트레이드오프도 존재한다.

글로벌 스케일에서의 PoC와 운영 환경의 격차

PoC (Proof of Concept) 환경에서는 세션 수가 제한적이기 때문에 WebRTC의 표준 구현만으로도 충분히 동작하는 경우가 많다. 하지만 동시 접속 세션이 수천 개를 넘어서는 단계에서 포트 관리나 프로세스 간의 세션 일관성에 관한 문제가 드러나기 시작한다. 스케일을 고려한 아키텍처 리뷰를 조기에 실시하는 것이 후속 공정에서의 재작업을 최소화하는 데 중요하다.

요약

OpenAI가 공개한 WebRTC 스택의 재설계는 음성 AI를 프로덕션에서 대규모로 운용할 때 직면하는 현실적인 엔지니어링 과제를 체계적으로 정리한 사례라고 할 수 있다. 스플릿 릴레이 + 트랜시버 (Transceiver) 아키텍처를 통한 스테이트풀 (Stateful) 특성의 분리, speech-to-speech 모델을 통한 파이프라인 통합, VAD 내장을 통한 턴 테이킹 (Turn-taking) 개선이라는 세 가지 노력이 결합됨으로써, 대규모이면서도 저지연인 음성 AI 경험이 실현되고 있다.

음성 AI (Voice AI) 설계에 있어서는 모델 성능의 개선과 병행하여, 네트워크 계층 (Network Layer), 세션 관리 계층 (Session Management Layer), 추론 파이프라인 (Inference Pipeline)의 각 레이어에 걸친 통합적인 최적화가 요구된다고 할 수 있다. OpenAI의 이번 사례는 그 설계 판단의 일면을 공개했다는 점에서, 산업적 구현을 위한 참조 사례로서 가치를 지닌다고 생각된다.

참고 문헌

OpenAI Engineering Blog, "How OpenAI delivers low-latency voice AI at scale" (2026-05-04) https://openai.com/index/delivering-low-latency-voice-ai-at-scale/ ↩︎ ↩︎ ↩︎

Quantum Zeitgeist, "OpenAI's 4 Steps To Low-Latency Voice AI At Global Scale" (2026-05) https://quantumzeitgeist.com/low-latency-voice-ai-openais-steps/ ↩︎ ↩︎

forasoft, "OpenAI Realtime API: Production Voice Agents (2026)" https://www.forasoft.com/blog/article/openai-realtime-api-voice-agent-production-guide-2026 ↩︎ ↩︎ ↩︎

dasha.ai, "OpenAI Realtime API Alternatives in 2026: Escaping the 'Black Box'" https://dasha.ai/tips/openai-realtime-api-alternatives ↩︎

AWS Machine Learning Blog, "Build real-time voice streaming applications with Amazon Nova Sonic and WebRTC" (2026-05-13) https://aws.amazon.com/blogs/machine-learning/build-real-time-voice-streaming-applications-with-amazon-nova-sonic-and-webrtc/ ↩︎

AWS Machine Learning Blog, "Real-time voice agents with Stream Vision Agents and Amazon Nova 2 Sonic" (2026-05-14) https://aws.amazon.com/blogs/machine-learning/real-time-voice-agents-with-stream-vision-agents-and-amazon-nova-2-sonic/ ↩︎