WebRTC는 회의 통화처럼 낮은 지연을 우선해 네트워크가 나쁠 때 오디오 패킷을 적극적으로 버리지만, Voice AI에서는 느린 응답보다 음성 프롬프트 손상이 응답 품질을 더 크게 해칠 수 있음
TTS는 실시간보다 빠르게 오디오를 만들 수 있어 클라이언트 버퍼링으로 짧은 네트워크 장애를 숨길 수 있지만, WebRTC는 도착 시간 기준 렌더링과 작은 지터 버퍼 때문에 패킷을 제때 보내도록 인위적으로 대기해야 함
WebRTC는 임시 포트, ICE, DTLS, SCTP 등으로 연결 설정과 운영이 복잡하며, 단일 포트 다중화에서는 STUN, SRTP/SRTCP, DTLS, TURN 패킷을 각 연결로 라우팅하기 어려움
OpenAI가 빠른 연결 설정을 요구해도 WebRTC는 시그널링과 미디어 서버 절차를 합쳐 최소 8 RTT가 들 수 있으며, P2P 지원 구조 때문에 서버가 고정 IP를 가져도 같은 절차를 거쳐야 함
대안으로 WebSockets와 QUIC/WebTransport가 제시되며, QUIC은 CONNECTION_ID, QUIC-LB, preferred_address를 통해 단일 포트, 주소 변경, 상태 없는 로드밸런싱, anycast와 unicast 조합을 더 단순하게 지원함
WebRTC가 Voice AI에 맞지 않는 이유
WebRTC는 회의 통화처럼 빠른 왕복 대화에 맞춰 설계되어, 네트워크 상태가 나쁠 때 지연을 낮게 유지하려고 오디오 패킷을 적극적으로 버림
Voice AI에서는 사용자가 느린 응답을 조금 더 기다리더라도 프롬프트가 정확히 전달되는 편이 더 중요함
예를 들어 “세차장에 걸어갈지 운전해 갈지” 같은 음성 프롬프트가 손상되면, 이후 응답 품질도 나빠질 수 있음
브라우저의 WebRTC 오디오 구현은 실시간 지연을 강하게 전제하며, Discord에서 시도했을 때 WebRTC 오디오 패킷 재전송은 불가능했다고 함
업데이트로 일부 WebRTC 관계자들은 오디오 NACK 활성화가 가능할 수 있다고 봤지만, Discord에서는 올바른 SDP 조작 방법을 찾지 못했고 WebRTC 지터 버퍼가 매우 작다는 한계도 남음
Voice AI 에이전트가 언젠가 대화 수준의 지연 시간에 도달하더라도, 지연을 줄이는 데는 트레이드오프가 있으며 음성 프롬프트를 일부러 열화시키는 선택이 가치 있는지는 불확실함
TTS와 WebRTC의 버퍼링 문제
텍스트 음성 변환(TTS)은 실시간보다 빠르게 오디오를 생성할 수 있음
예를 들어 GPU가 2초 동안 8초 분량의 오디오를 생성한다면, 이상적으로는 생성 중인 2초 동안 오디오를 스트리밍하고 클라이언트가 8초 동안 재생하면서 로컬 버퍼를 확보할 수 있음
이렇게 하면 짧은 네트워크 장애가 있어도 사용자가 알아차리지 못할 가능성이 있음
WebRTC는 이런 방식과 맞지 않음
WebRTC는 버퍼링이 없고 도착 시간 기준으로 렌더링하며, 타임스탬프는 강한 재생 기준이 되지 않는다고 봄
비디오까지 포함되면 문제가 더 까다로워짐
OpenAI 같은 서비스는 패킷이 재생되어야 할 정확한 시점에 도착하도록, 각 오디오 패킷 전송 전에 인위적으로 대기해야 함
네트워크 혼잡이 생기면 해당 오디오 패킷은 손실되고 재전송되지 않음
결과적으로 인위적 지연을 넣은 뒤 “낮은 지연”을 위해 패킷을 적극적으로 버리는 구조가 되며, 이는 YouTube 영상을 버퍼링하지 않고 화면 공유로 보여주는 것과 비슷함
WebRTC는 오디오에 대해 20ms에서 200ms까지 동적으로 조정되는 지터 버퍼를 두며, 이는 네트워크 지터를 완화하기 위한 것이지만 실시간보다 빠르게 전송할 수 있다면 필요하지 않다고 봄
포트와 연결 식별의 한계
TCP 서버는 보통 443 같은 포트를 열고 연결을 받으며, 연결은 소스·목적지 IP와 포트 조합으로 식별됨
예: 123.45.67.89:54321 -> 192.168.1.2:443
휴대폰이 WiFi에서 셀룰러로 전환되거나 NAT가 소스 IP·포트를 바꾸면 TCP 연결은 끊기고 새 연결을 맺어야 함
TCP와 TLS 핸드셰이크에는 최소 2~3 RTT가 들며, 라이브 스트리밍에서는 사용자가 네트워크 끊김을 느낄 수 있음
WebRTC는 이 문제를 풀기 위해 각 연결마다 임시 목적지 포트를 할당하는 방식을 전제함
세션을 목적지 IP·포트만으로 식별하면, 소스 IP·포트가 바뀌어도 같은 사용자로 인식할 수 있음
하지만 OpenAI의 구조와 맞물리면 이 방식은 대규모 운영에서 문제가 됨
서버가 사용할 수 있는 포트 수에는 한계가 있음
방화벽은 임시 포트를 자주 차단함
Kubernetes 환경과도 잘 맞지 않음
WebRTC 서비스가 단일 포트 다중화로 가는 이유
많은 서비스는 WebRTC 사양을 그대로 따르지 않고, 여러 연결을 단일 포트에 다중화함
Twitch에서는 WebRTC 서버를 UDP:443에서 운영했음
원래 443은 HTTPS/QUIC 포트지만, 이렇게 하면 더 많은 방화벽을 통과할 수 있었음
Amazon 사내 네트워크는 약 30개 포트만 허용했다고 함
Discord는 CPU 코어마다 하나씩 50000-50032 포트를 사용함
이 방식은 더 많은 사내 네트워크에서 차단될 수 있음
단일 포트 다중화의 큰 문제는 WebRTC가 여러 표준을 묶은 구조라는 데 있음
UDP 위로 직접 올라가는 프로토콜이 5개 있으며, 패킷이 어떤 프로토콜인지 구분하는 일 자체는 어렵지 않지만 각 패킷을 어떤 연결로 라우팅할지가 어려움
3 hours ago
2
!["아아 팔아 갖고는"…치킨·볶음밥까지 내놓은 커피전문점 '속사정' [트렌드+]](https://img.hankyung.com/photo/202604/01.43949627.1.jpg)
English (US) · 