OpenAI’s WebRTC problem

개요

OpenAI가 WebRTC를 음성 AI 서비스에 적용한 것에 대한 기술적인 문제점을 지적하며, WebRTC의 한계와 QUIC 프로토콜의 이점을 제시합니다.

주요 내용

• WebRTC의 음성 AI 부적합성: WebRTC는 낮은 지연 시간을 위해 네트워크 상태가 좋지 않을 때 오디오 패킷을 공격적으로 삭제하는 경향이 있어, 음성 AI 사용자에게는 프롬프트의 정확성을 위해 지연 시간을 더 감수하더라도 패킷 손실을 방지하는 것이 유리합니다. 또한, 브라우저 환경에서 WebRTC 오디오 패킷의 재전송이 어렵습니다.
• WebRTC의 텍스트-음성 변환(TTS) 처리의 문제점: TTS 오디오가 생성되는 시간(예: 2초)보다 실제로 재생되는 시간(예: 8초)이 더 길더라도, WebRTC는 패킷 도착 시간에 맞춰 렌더링하여 로컬 버퍼링 없이 오디오가 생성되는 동안 스트리밍하는 방식에 제약이 있습니다. 이는 패킷 손실 시 오디오를 잃게 만들고, OpenAI가 인위적인 지연을 추가하고 패킷을 삭제하는 역효과를 낳습니다.
• WebRTC의 포트 및 주소 변경 문제: WebRTC는 연결당 별도의 포트를 할당하도록 되어 있어 서버 포트 제한 및 방화벽 차단 문제를 야기하며, 클라이언트 IP/포트 변경 시 TCP + TLS 핸드셰이크를 다시 수행해야 하는 오버헤드가 발생합니다. OpenAI의 경우, 이를 해결하기 위해 STUN 헤더만 파싱하고 나머지 패킷을 불투명하게 처리하는 등의 비표준적인 방식을 사용합니다.
• WebRTC의 연결 설정 지연: P2P 지원을 위해 WebRTC는 최소 8 RTT(Round Trip Time) 이상의 연결 설정 과정이 필요하며, 이는 시그널링 및 미디어 서버가 동일한 호스트에 있더라도 중복적인 핸드셰이크를 발생시켜 불필요한 지연을 초래합니다.
• WebRTC 포크의 필요성: WebRTC의 여러 제약 사항으로 인해 많은 서비스들이 네이티브 앱을 통해 WebRTC 구현을 회피하거나 프로토콜을 수정(포크)하는 방식을 취하며, Discord 또한 이를 통해 네이티브 클라이언트에서는 WebRTC의 상당 부분을 구현하지 않습니다.
• 대안으로 QUIC 프로토콜 제안: QUIC은 1 RTT의 연결 설정으로 더 빠른 초기 연결을 제공하며, CONNECTION_ID를 통해 IP/포트 변경에 유연하게 대처하고 Stateless Load Balancing을 지원하여 서버 재부팅과 같은 상황에서도 상태 관리가 용이합니다. 또한, QUIC-LB는 서버 ID를 CONNECTION_ID에 인코딩하여 로드 밸런서의 부담을 줄여줍니다.
• QUIC의 Anycast + Unicast 기반 로드 밸런싱: QUIC의 preferred_address 기능을 활용하면 Anycast 주소를 통해 초기 핸드셰이크를 진행하고, 이후 Unicast 주소를 통해 상태를 유지하며 트래픽을 분산시킬 수 있어 로드 밸런서의 필요성을 최소화할 수 있습니다.

시사점

WebRTC는 낮은 지연 시간을 요구하는 기존 컨퍼런스 콜에는 적합할 수 있으나, 음성 AI 서비스의 정확성과 안정성을 위해서는 QUIC과 같은 더 효율적이고 유연한 프로토콜을 고려해야 합니다.