왜 WebRTC는 Voice AI에 잘못된 선택인가

OpenAI가 대규모 저지연 Voice AI를 제공하는 방법에 관한 기술 블로그를 공개했을 때, 네트워킹 전문가들 사이에서 논쟁이 촉발되었습니다. WebRTC가 실시간 통신(RTC)의 업계 표준이긴 하지만, 시스템 엔지니어들 사이에서는 컨퍼런싱 프로토콜을 AI 에이전트에 적용하는 것이 제품 적합성과 인프라 확장성 측면에서 근본적인 불일치를 초래한다는 공감대가 형성되고 있습니다.

Voice AI를 구축하는 사람들에게 WebRTC는 대화용으로 설계되었기 때문에 유혹적인 선택입니다. 하지만 다음 분석에서 밝혀지듯이, WebRTC를 Zoom 통화에 적합하게 만드는 바로 그 기능들이 고정밀 AI 상호작용에는 문제를 일으킵니다.

제품 불일치: 지연 시간 vs 정확도

WebRTC는 인간 대 인간의 컨퍼런싱을 위해 설계되었으며, 주요 목표는 대화의 연속적이고 실시간적인 흐름을 유지하는 것입니다. 이를 달성하기 위해 WebRTC는 모든 비용을 치러서라도 지연 시간을 최소화하도록 공격적으로 최적화되어 있습니다. 네트워크 상태가 악화되면 WebRTC는 누락된 패킷을 기다리지 않고, 스트림을 최신 상태로 유지하기 위해 단순히 패킷을 드롭합니다.

인간의 대화에서 짧은 오디오 글리치는 뇌에 의해 무시되는 경우가 많습니다. 그러나 Voice AI에서는 이것이 치명적입니다. 만약 사용자가 "세차장에 가려면 걸어가야 할까요, 아니면 차를 운전해야 할까요?"라고 물었을 때 네트워크 문제로 인해 "운전"이라는 단어가 누락된다면, LLM은 손상된 프롬프트를 받게 됩니다. 한 전문가는 다음과 같이 언급합니다:

느리고 비싼 프롬프트가 정확하기 위해서라면 차라리 200ms를 더 기다리겠습니다. 결국 저는 엄청난 노력을 들여 결과를 얻으려 하는 것이고, 쓰레기 같은 프롬프트는 쓰레기 같은 응답을 의미하니까요.

게다가 WebRTC의 네이티브 버퍼링 부재는 오디오를 도착 시간에 따라 렌더링한다는 것을 의미합니다. 이로 인해 OpenAI와 같은 제공업체는 패킷이 렌더링되어야 할 정확한 시점에 도착하도록 하기 위해 패킷을 보내기 전에 인위적인 지연(sleeps)을 도입해야 합니다. 이는 역설적인 상황을 만듭니다: 시스템이 지연 시간을 낮게 유지하기 위해 인위적인 지연을 도입한 다음, 다시 공격적으로 패킷을 드롭하는 상황 말입니다.

인프라 악몽: 포트와 로드 밸런싱

WebRTC는 임시 포트(ephemeral ports)에 대한 의존성 때문에 확장하기가 매우 어려운 것으로 알려져 있습니다. 표준 TCP 설정에서 서버는 단일 포트(예: 443)에서 대기합니다. 그러나 WebRTC는 P2P(Peer-to-Peer) 연결을 위해 설계되었으며, NAT traversal을 처리하기 위해 각 연결마다 고유한 임시 포트를 할당해야 하는 경우가 많습니다.

대규모 환경에서는 다음과 같은 세 가지 주요 장애물이 발생합니다:

  1. 포트 고갈: 서버는 사용 가능한 포트 수가 제한되어 있습니다.
  2. 방화벽 제한: 많은 기업용 방화벽은 WebRTC가 요구하는 광범위한 임시 포트 범위를 차단합니다.
  3. 오케스트레이션 복잡성: Kubernetes 환경 내에서 이러한 포트를 관리하는 것은 상당한 운영 부담입니다.

이러한 문제를 우회하기 위해 많은 기업이 "해킹"을 구현합니다. 일부는 여러 연결을 단일 포트에 멀티플렉싱(mux)하거나 프로토콜에 대해 거짓말을 합니다(예: UDP:443에서 WebRTC 실행). OpenAI의 자체 솔루션은 STUN 헤더를 파싱하여 패킷을 라우팅하는 커스텀 로드 밸런서를 포함하는데, 이는 본질적으로 소스 IP/포트 변경을 원활하게 처리하는 프로토콜의 능력을 저해합니다.

연결 비용: 8-RTT 문제

Voice AI의 주요 목표 중 하나는 "빠른 연결 설정"입니다. 하지만 WebRTC는 초기화하는 데 가장 비용이 많이 드는 프로토콜 중 하나입니다. 연결을 설정하는 데는 일반적으로 다양한 레이어에 걸쳐 최소 8번의 왕복(RTT)이 필요합니다:

  • Signaling: TCP, TLS 1.3, 및 HTTP 핸드셰이크.
  • Media: ICE, DTLS 1.2, 및 SCTP 핸드셰이크.

에지 노드(edge nodes)를 사용하더라도 이러한 왕복 과정은 누적되어 사용자가 말을 시작하기 전에 인지할 수 있는 지연을 생성합니다. 이러한 복잡성이 존재하는 이유는 WebRTC가 실제 아키텍처가 클라이언트-서버 방식일지라도 P2P 시나리오를 지원해야 하기 때문입니다.

대안: 왜 QUIC이 "Chad" 프로토콜인가

WebRTC가 다른 시대에 설계된 "프로토콜의 코트"라면, QUIC(HTTP/3의 기반)은 현대적인 후계자입니다. QUIC은 WebRTC의 가장 눈에 띄는 문제들을 해결합니다:

1. 연결 이동성 (Connection Migration)

TCP나 WebRTC와 달리, QUIC은 수신자가 선택한 CONNECTION_ID를 사용합니다. 사용자가 WiFi에서 셀룰러 데이터로 전환하여 IP 주소가 변경되더라도 CONNECTION_ID는 동일하게 유지됩니다. 서버는 클라이언트를 즉시 인식하며, 연결은 비용이 큰 재핸드셰이크 없이 계속됩니다.

2. 상태 없는 로드 밸런싱 (QUIC-LB)

QUIC-LB를 사용하면 백엔드 서버가 자신의 ID를 CONNECTION_ID에 인코딩할 수 있습니다. 이를 통해 로드 밸런서는 (Redis와 같은) 공유 상태 데이터베이스 없이 패킷을 올바른 백엔드 서버로 전달할 수 있습니다. 이는 제로-스테이트(zero-state), 글로벌 애니캐스트(anycast) 라우팅을 가능하게 하여 인프라 복잡성을 크게 줄여줍니다.

3. 신속한 설정

QUIC은 전송 레이어와 암호화 핸드셰이크를 결합하여 연결 설정을 단일 RTT(또는 일부 경우 0-RTT)로 줄여, WebRTC가 요구하는 "8-RTT 댄스"를 제거합니다.

반론: WebRTC 없이 무엇을 잃게 되는가?

비판에도 불구하고, 일부 엔지니어들은 WebRTC를 버리는 것이 단순한 교체 작업이 아니라고 주장합니다. WebRTC는 다음과 같은 완전한 오디오 DSP(Digital Signal Processing) 파이프라인을 제공합니다:

  • Acoustic Echo Cancellation (AEC)
  • Noise Suppression
  • Automatic Gain Control
  • NAT Traversal Maturity

WebSockets나 원시 QUIC을 사용한다는 것은 개발자가 클라이언트 측에서 이러한 기능들을 직접 구현하거나 원시 오디오 처리를 처리할 대체 라이브러리를 찾아야 함을 의미합니다. 많은 이들에게 WebRTC의 createOffer와 setRemoteDescription 워크플로우의 "마법"은 전송 레이어의 고통을 위해 감수할 수 있는 수준입니다.

최종 결론

단순한 1:1 Voice AI를 위해서는 WebSockets나 WebTransport를 통해 오디오를 스트리밍하는 것이 가장 실용적인 경로일 수 있습니다. WebRTC는 인간 대 인간의 컨퍼런싱을 위한 강력한 도구이지만, 그 공격적인 패킷 손실과 인프라 오버헤드는 AI 에이전트의 고정밀 요구 사항을 충족하기에 부적합합니다. 업계가 Speech-to-Speech (S2S) 모델로 이동함에 따라, 진정한 글로벌 규모와 신뢰성을 추구하는 이들에게 QUIC 기반 전송 방식은 필수적인 선택이 될 것입니다.

Sources