글을 끝까지 다 읽진 않았지만, 글쓴이가 WebRTC의 목적을 근본적으로는 이해하고 있다고 봄. 본인이 전문가라고 하고 Go/Rust로 SFU를 여러 회사에서 만든 것도 맞겠지만, 기술 이력이 곧 결론의 정당성을 보장하진 않음
내가 잘못 이해했을 수도 있지만, STUN과 DTLS를 왕복 시간 문제에서 서로 연관된 누적 요인처럼 다루는 듯한데 실제로는 꽤 직교적인 요소임. 또 패킷 재전송이 안 된다는 얘기에 너무 많은 시간을 쓰고, Discord에서 엄청 노력했다는 식으로 반복하는 지점에서 논지를 잃었다고 느낌
WebRTC의 RTC는 실시간 통신이고, 사람은 가끔 패킷이 빠진 소리보다 밀린 오디오나 속도가 들쭉날쭉한 오디오를 더 싫어함. 여기서는 사람의 말소리를 말하는 것임
패킷 손실을 감수하기 싫다면 UDP 대신 TCP 기반 프로토콜을 쓰면 됨. 하지만 나쁜 네트워크에서 TCP로 음성을 보내면 수신 쪽은 다음 올바른 패킷을 기다리느라 멈춤이 생김. 몇 초 지연된 뒤 다시 패킷이 오면, 밀린 오디오를 정상 속도로 재생할지, 다른 채널을 따라잡으려고 빠르게 재생할지 결정해야 하는데 보통 사람들은 그런 경험을 선호하지 않음
WebRTC를 잠깐 잊고 음성에서 TCP와 UDP를 생각해보면, VoIP가 90년대부터 UDP 기반이었던 데는 이유가 있음
먼저 기술적인 부분에 답하자면, WebRTC가 아닌 미래는 있다고 봄. 다만 그 방향이 WebTransport+WebCodecs 등이 가는 방향과 맞는지는 모르겠음
사용자가 느린/비싼 프롬프트가 정확해지도록 200ms 더 기다리겠다는 말은 내가 받는 피드백과 정반대임. 사용자는 즉각적인 응답을 원함. 응답 생성이나 끼어들기 처리에 지연이 있으면 마법 같은 느낌이 사라짐. 또한 실시간보다 빠르게 보내는 것도 원치 않음. 사용자가 모델을 중간에 끊으면 10초만 재생된 3분짜리 오디오를 보내느라 대역폭을 낭비한 셈이 됨
TTS가 실시간보다 빠르다는 주장에 대해서는, 최신/지향점의 음성 AI는 글쓴이가 설명한 방식에서 벗어나고 있음: https://research.nvidia.com/labs/adlr/personaplex/ 20ms 단위로 조금씩 입출력하는 쪽임
사용자의 원본 IP/포트가 바뀌지 않기를 바란다는 부분은 지원됨. ufrag에 대해 새 IP가 들어오면 처리 가능함
최소 8회 왕복 시간이 걸린다는 말도 틀림: https://datatracker.ietf.org/doc/draft-hancke-webrtc-sped/
오디오를 WebSocket으로 스트리밍하겠다는 선택은 AEC 같은 기능을 잃고, 복잡성을 클라이언트로 밀어냄. WebRTC의 단순함, 즉 createOffer -> setRemoteDescription 흐름 덕분에 사람들이 쉽게 시작할 수 있음. Realtime API + WebSocket에서는 많은 개발자가 코드가 많고 직접 처리해야 하는 부분 때문에 고생했음
개인적으로 고르라면 Offer/Answer 모델은 유지하되 DTLS+SCTP 대신 QUIC을 쓰고 싶음. 어쩌면 QUIC 위에서 RTP를 할 수도 있음. 프로토콜 자체에는 강한 선호가 없지만, 훨씬 큰 코드 footprint로 여러 클라이언트와 고객 클라이언트에 코드를 배포하는 방법은 잘 모르겠음
물론 사용자는 낮은 지연 시간을 원하지만, LLM이 잘못 들은 경우도 줄이고 싶어함. 지연 시간과 품질의 절충을 A/B 실험으로 돌릴 수 있으면 좋겠지만, WebRTC는 그 조절 손잡이를 다루기 어렵게 만듦
TTS 전문가는 아니지만 결과를 조금씩 흘려보내는 이점이 뭔지 모르겠음. 실리콘은 시간 숫자가 얼마나 빨리 증가하는지 신경 쓰지 않음
클라이언트가 자기 IP 변경을 알고 ICE 재협상을 할 수 있는 경우도 있지만, 모르는 경우가 많고 보통은 서버가 변경을 감지하길 기대함. 그런데 현재 로드밸런서 구성에서는 그게 불가능함. 큰 문제는 아니지만 이미 넘어야 할 절차가 많은 상황에서는 아쉬움
그 초안이 8 RTT가 아니라 7 RTT라는 뜻이라면, 일부는 파이프라인화할 수 있으니 실제 수치는 더 낮을 수 있음. 하지만 진짜 문제는 P2P가 쓰일 수도 있다는 이유만으로 필수 시그널링 서버와 이중 TLS 핸드셰이크가 생긴다는 점임
WebRTC가 새 개발자에게 쉬운 이유는 블랙박스 회의 앱이기 때문임. 하지만 OpenAI 같은 큰 회사에서는 그 블랙박스가 더 낮은 수준의 원시 기능으로 고칠 수 있는 문제를 만들기 시작함
RTP over QUIC은 꼭 실험해보면 좋겠고 도와줄 의향도 있음. 코드 크기가 걱정이라면 브라우저, 언젠가는 OS가 QUIC 라이브러리를 제공함. MoQ에 가까운 쪽으로 바꾸면 QUIC이 단편화, 재전송, 혼잡 제어 등을 처리하므로 애플리케이션은 놀랄 정도로 작아짐
RoQ/MoQ의 큰 한계는 QUIC이 데이터그램까지 포함해 혼잡 제어를 하기 때문에 GCC를 구현할 수 없다는 점임. 브라우저에서 보낼 때는 당분간 cubic/BBR에 묶이게 됨
사용자가 즉각적인 오답을 200ms 늦은 정답보다 선호한다는 피드백을 정말 받고 있다는 말은 매우 의심스러움
3분이나 20ms 단위로 보낼 필요 없이 약 1초씩 보내면 됨. 20ms씩 보내는 것도, 10분씩 보내는 것도 둘 다 바보 같음
WebRTC는 브라우저에 내장된 라이브러리라 해도 복잡함. 클라이언트/서버 음성 상호작용이라면 굳이 쓸 이유를 모르겠음. 음성 샘플은 다른 방식으로 보내고, 재생에는 지터 버퍼 로직 일부만 빌리면 됨
지금 하는 일이 음성/화상 회의와 1:1 통화인데, WebRTC의 복잡성은 엄청남. 제품을 빨리 시작하게 해주긴 했지만, 이상한 일을 할 때 고치기가 어렵고, 클라이언트용으로 포크까지 해도 그렇다
TURN에 대해서는 긴 불평을 쓸 수도 있음. 사실 WebRTC 프로토콜 묶음 전체가 존재하지 않는 인터넷을 대상으로 설계된 것 같음
TURN은 클라이언트가 할당을 요청할 때 임시 포트가 아니라 rendezvous id를 할당해야 함. 그러면 피어는 서비스 포트로 TURN 서버에 접속해 그 rendezvous id에 대한 연결을 요청하면 되고, 클라이언트가 피어 주소를 알고 permission을 추가할 필요가 없음. 종단 간 릴레이 연결까지 필요한 통신이 줄어듦. 고급 클러스터는 id에 정보를 인코딩해 클라이언트와 피어가 각각 자기와 가까운 TURN 서버에 접속하고 서버끼리 연결하게 할 수 있음. 덜 고급인 클러스터는 id와 함께 TURN 서버 IP와 서비스 포트를 공유해야 함
첫 음소 전달과 중요한 정보 전달은 결합될 필요가 없음. TV 정치인들은 이 요령에 매우 능숙해서, 머리가 돌아가기 시작할 때까지 시간을 메우는 상투 문구 세트를 갖고 있음. 우리의 시스템 1이 상호작용에 대한 신뢰를 잃지 않도록 빈틈을 메우기만 하면 됨
실제 표시 타임스탬프와 그것이 실제 시간에 어떻게 대응하는지 알아야 할 필요가 왜 있겠냐는 대목이 뼈아프게 와닿음. WebRTC를 만든 사람 중 누구도 서로 다른 출처의 데이터 스트림을 밀리초 정확도로 동기화해본 적이 없는 듯함
브라우저에서 웹캠과 IMU 모듈을 이용한 영상 안정화 데모를 만들었는데, video->rtc->browser 경로와 sensor->websocket->browser 경로의 지연 시간이 크게 다르고 일정하지 않았음. 당연한 해법은 센서 데이터에 UTC 타임스탬프를 보내고 브라우저에서 동기화하는 것이지만, 비디오에는 UTC 타임스탬프 기준이 없어 불가능했음
WebRTC 파이프 양쪽을 모두 제어하면 스트림 시작 시점의 UTC 타임스탬프를 보내는 식의 재미있는 일을 할 수는 있지만, 브라우저 지터는 해결하지 못함. 개념 증명으로는 충분히 동작했지만 전체 해법은 다시 설계해야 했음
이 분야 경험이 많고 특허 출원도 몇 개 있음. Alexa에서는 기기가 서버로 연결을 맺고 계속 열어둔 뒤, wake word를 감지하면 그 연결 위로 사실상 HTTP2/SPDY 비슷한 것을 보냈음. 그래서 사용자가 말을 끝내기 전에 STT 처리를 시작할 수 있었고, 마지막 몇 조각 처리 지연만 남았음
답변도 같은 연결로 돌아왔음
OpenAI의 경우 Alexa처럼 지속 연결을 항상 열어두긴 어렵지만, 휴대폰에서 HTTP2를 쓰면 iOS와 Android가 그 연결을 거의 알아서 관리해줌
글쓴이가 맞음. 실시간 프로토콜은 꼭 필요하지 않고, 모든 데이터를 받는 게 더 중요함. 사용자는 지연이 500ms를 넘기 전까지는 거의 알아차리지 못함. 특히 모바일 시대에는 대부분 사람이 사람 간 실시간 통신에도 지연이 있는 것에 익숙함
OpenAI나 Anthropic에서 일한다면 연락해도 좋음. 더 자세히 이야기할 수 있음
전송 지연에 너무 집중하다 보니 LLM 파이프라인 자체가 즉시 끝나지 않는다는 점을 잊는 것 같음
전송 지연은 이미 큰 다른 모든 지연 위에 더해짐
그래서 전체 파이프라인의 종단 간 지연을 줄이기 위해 가능한 최저 지연 해법을 택한 것이라고 봄
사람 간 음성 지연과의 비유는 맞지 않음. 그 경우에는 사람을 지연이 없는 존재처럼 취급하기 때문임
하루 약 6,000건의 음성 대화를 WebRTC + 계단식 STT/LLM/TTS 구조로 처리해보면, 500ms가 사용자가 못 느낄 지연이라는 말은 내 경험과 다름
500ms는 요즘 최첨단 음성 구현에서 운이 좋고 돈을 아끼지 않으며 speculative decoding과 reasoning 같은 비싼 기법까지 쓸 때의 바닥값에 가까움. LLM 단계만 450ms가 걸림. 상용 음성 AI에서는 모든 ms가 중요하고, 200~300ms만 더해도 대화 품질이 크게 나빠짐
우리 사업은 주로 비기술 사용자 대상 음성을 많이 다룸. 작년에 턴 간 지연이 1200~1500ms였을 때는 사용자 혼란, 끼어들기, 대화 이탈, 전반적으로 불쾌한 경험이 많았음. 지금은 필요한 도구 사용에 따라 약 700ms 수준이고, 실제 사람과의 상호작용에 견줄 만한 괜찮은 경험에 가까워지고 있음. 여기서 100ms를 더 줄이려고 꽤 많은 비용을 쓰고 있음
speculative LLM pass, speculative tool execution처럼 비싸고 낭비적인 일도 함. 사용자가 말하는 동안 여러 LLM 추론을 돌리되, 그 pass가 쓸 수 있고 사용자가 문장 끝에 중요한 말을 하지 않았다는 걸 알기 전에는 비멱등 도구 호출을 실제 실행하지 않는 식으로 100~200ms를 줄임. 500ms가 무관하다는 말은 사람-대-AI 음성 상호작용이 아닌 다른 사례를 말하는 것이라고 봄
음성 AI에서 진짜 어려운 문제는 가끔 빠지는 WebRTC 패킷이 아니라 강한 배경 소음, 에코, 억양임. WebRTC의 잘 다듬어진 AEC 구현은 적어도 에코에는 꽤 도움이 됨. OpenAI 규모에서 구현하기 매우 골치 아픈 프로토콜이라는 건 알지만, 초대규모가 아닌 애플리케이션에는 Daily 같은 상용 제공자와 괜찮은 해법이 많음. 진짜 풀 문제는 다른 곳에 있음. 그래도 내 지연 예산에 500ms를 더하면 애플리케이션은 죽음
안타깝게도 WebRTC만큼 구현하기 싫은 프로토콜이 드묾. 단순 클라이언트 하나를 띄우려 해도 SDP, TURN/STUN, ICE candidates, offer, P2P 프로토콜, 매번 처음부터 구현하는 복잡한 핸드셰이크에 빠르게 적응해야 함
프로토콜과 의도치 않은 “모범 사례”가 겹겹이 들어간 그 트렌치코트를 전부 다시 쓴다는 건 상상하기도 어렵다
Microsoft Graph API로 이메일을 다뤄본 적이 있는지 궁금함
LLM이 등장하고 나서야 aiortc로 동작하는 WebRTC datachannel 구성을 처음 만들 수 있었음. 그전에는 사실상 완전히 불가능했음. 무엇을 어떻게 해야 하는지 아는 사람이 없고 예제도 없음. 정말 끔찍한 프로토콜이고 사라져야 함
이런 이유로 LiveKit을 좋아하고, CEO도 괜찮음
어떤 플랫폼을 대상으로 했길래 그렇게 고통스러웠는지 궁금함. 좌절스러웠다니 아쉽다
교육 자료와 라이브러리가 늘면서 나아지고 있기를 바람. Codex 같은 도구가 이제는 이런 부분을 꽤 잘 밀고 나가는 것도 놀라움
브라우저 API 안정성 전반에는 문서화되지 않은 가장자리 사례가 많고, WebRTC만의 문제는 아님
답답할 정도로 한쪽으로 치우친 글임. WebRTC에 한계가 있는 건 맞지만, 표준에 기대면 많은 정확성을 얻고 장기 엔지니어링 비용을 줄일 수 있음. WebRTC가 복잡하다는 사실은 틀렸다는 뜻이 아니라, 공개 인터넷에서 실시간 미디어가 복잡하다는 뜻임
네트워킹은 본질적으로 상태를 가짐. NAT traversal, 지터 버퍼, 혼잡 제어, 패킷 손실, 코덱 상태, 암호화, 세션 라우팅은 오디오를 TCP나 WebSocket에 올린다고 사라지지 않음. 그렇지 않은 척하는 건 아키텍처적 명료함이 아니라 복잡성을 덜 보이는 곳으로 옮기는 것일 뿐임
글쓴이는 글 시작부터 본인 배경을 설명했음. 6년 전 Twitch에서 WebRTC SFU를 만들었고, 처음에는 OpenAI처럼 Pion(Go)을 썼지만 벤치마크에서 너무 느려 포크했으며, 결국 모든 프로토콜을 다시 썼다고 함
1년 전에는 Discord에서 Rust로 WebRTC SFU를 다시 썼고, 반복되는 패턴이 보일 것임
WebRTC는 2000년대 초반부터 이어진 약 45개의 RFC와, TWCC나 REMB처럼 기술적으로는 초안인 사실상 표준들로 구성됨. 이걸 전부 구현해야 할 때는 전혀 즐겁지 않음
본인은 공인 WebRTC 전문가로 봐도 좋고, 그래서 다시는 WebRTC를 쓰고 싶지 않다고 함
보통 방식으로 충분히 시도해봤으니 반대 방향의 견해를 가질 자격은 충분하지 않나 싶음
한쪽으로 치우쳤다는 점이 오히려 요즘 널린 양쪽 다 맞다는 식의 글머리표 AI 문장보다 사람이 쓴 글처럼 신선했음
주제 자체에 대한 입장은 없지만, 글에 분명히 인간적인 결이 있어서 좋았음
만약 AI가 쓴 글이라면 정말 큰일임
“얼마나 어렵겠어?”라고 허수아비가 물었음
2026년인데도 원격회의는 여전히 엉망임. 수십억 달러가 걸려 있고 Zoom도 잘해야 평범한 수준이며, Microsoft의 뭐시기만큼 나쁠 때도 있음. 원격회의가 서툴고 거친 난장판이 아닌 걸 본 적이 없음
QUIC도 표준임
훌륭한 글임. 글쓴이가 해당 분야 전문가일 때 블로그 글에 상을 줄 수 있으면 좋겠음
“WebRTC는 나쁜 네트워크 상황에서 내 프롬프트를 열화시키고 떨어뜨리도록 설계됐다”는 말에 대해, 실시간을 원한다면 감수해야 할 일임. 실시간을 원하지 않고 모든 걸 STT -> Prompt -> TTS로 상상한다면 애초에 오디오를 네트워크로 보낼 필요가 없을 수도 있음
글쓴이임. 댓글 답변이 글만큼 재밌지 않은 점은 양해 바람
모든 저지연 애플리케이션은 품질과 지연 시간 사이의 사용자 경험 절충을 정해야 함. 혼잡은 큐잉, 즉 지연을 만들고, 이를 피하려면 무언가를 건너뛰어야 해서 품질이 낮아짐
WebRTC의 지연 시간 대 품질 조절 손잡이는 고정돼 있음. 지연 최소화에는 훌륭하지만 유연성이 부족함. 그래도 브라우저 지원 덕분에 사실상 몇 안 되는 선택지라서 여전히 WebRTC를 쓰려고 함
하지만 이제는 WebTransport가 있음. 범용 프로토콜로 WebRTC 비슷한 동작을 만들 수 있음. 스트림을 drop/reset하기 전에 얼마나 기다릴지 애플리케이션이 선택할 수 있고, 그 결정을 대신 당하지 않아도 됨
글의 요지는 사용자가 대개 스트리밍은 원하지만 드롭은 원하지 않는다는 것임. 오디오 입출력 스트리밍은 WebRTC 없이도 당연히 가능함. 오디오 패킷이 영원히 사라지는 시점을 애플리케이션이 정할 수 있어야 함. 50ms인지 500ms인지 5000ms인지 말임. 음성 AI가 50ms 옵션을 고르면 안 된다는 주장임
핵심은 OpenAI의 사용 사례가 실시간을 요구하지 않는다는 것 아닌가 싶음
OpenAI가 응답할 때는 사용자가 들어야 하는 시점보다 앞서 오디오 대부분을 갖고 있음. 실시간보다 빠르게 오디오를 생성하므로 실시간 프로토콜은 맞지 않는 선택임
지연을 줄이는 추가 설정을 내가 놓쳤을 수도 있지만, 클라이언트들은 STT -> Prompt -> TTS의 지연을 감수하고 싶어하지 않는 듯함. 대화가 “진짜”처럼 느껴진다면 가끔 품질 문제가 생기는 건 기꺼이 받아들임
Gemini Live API를 관리형 WebRTC 클라우드 메시 위에서 돌리고 있는데 아주 잘 동작하고, 2년째 운영 중임. WebSocket을 시도하고 임시 키 등을 직접 처리할 수도 있지만, 이 영역에서 대규모 음성 에이전트를 운영하는 사람들과 이야기해보면 WebRTC와 Pipecat, 그리고 이미 해결된 문제들에 투입된 많은 리소스로 상당수가 풀려 있음
분명 과하다는 느낌이 들고 실제로도 그럴 수 있지만, 연결이 맺어진 뒤에는 꽤 마법 같음. 시작 시간과 버퍼링도 더 빠른 음성 연결을 위해 해결돼 있음: https://github.com/pipecat-ai/pipecat-examples/tree/main/ins... 영상은 더 어려움
Hacker News 의견들
글을 끝까지 다 읽진 않았지만, 글쓴이가 WebRTC의 목적을 근본적으로는 이해하고 있다고 봄. 본인이 전문가라고 하고 Go/Rust로 SFU를 여러 회사에서 만든 것도 맞겠지만, 기술 이력이 곧 결론의 정당성을 보장하진 않음
내가 잘못 이해했을 수도 있지만, STUN과 DTLS를 왕복 시간 문제에서 서로 연관된 누적 요인처럼 다루는 듯한데 실제로는 꽤 직교적인 요소임. 또 패킷 재전송이 안 된다는 얘기에 너무 많은 시간을 쓰고, Discord에서 엄청 노력했다는 식으로 반복하는 지점에서 논지를 잃었다고 느낌
WebRTC의 RTC는 실시간 통신이고, 사람은 가끔 패킷이 빠진 소리보다 밀린 오디오나 속도가 들쭉날쭉한 오디오를 더 싫어함. 여기서는 사람의 말소리를 말하는 것임
패킷 손실을 감수하기 싫다면 UDP 대신 TCP 기반 프로토콜을 쓰면 됨. 하지만 나쁜 네트워크에서 TCP로 음성을 보내면 수신 쪽은 다음 올바른 패킷을 기다리느라 멈춤이 생김. 몇 초 지연된 뒤 다시 패킷이 오면, 밀린 오디오를 정상 속도로 재생할지, 다른 채널을 따라잡으려고 빠르게 재생할지 결정해야 하는데 보통 사람들은 그런 경험을 선호하지 않음
WebRTC를 잠깐 잊고 음성에서 TCP와 UDP를 생각해보면, VoIP가 90년대부터 UDP 기반이었던 데는 이유가 있음
먼저 기술적인 부분에 답하자면, WebRTC가 아닌 미래는 있다고 봄. 다만 그 방향이 WebTransport+WebCodecs 등이 가는 방향과 맞는지는 모르겠음
사용자가 느린/비싼 프롬프트가 정확해지도록 200ms 더 기다리겠다는 말은 내가 받는 피드백과 정반대임. 사용자는 즉각적인 응답을 원함. 응답 생성이나 끼어들기 처리에 지연이 있으면 마법 같은 느낌이 사라짐. 또한 실시간보다 빠르게 보내는 것도 원치 않음. 사용자가 모델을 중간에 끊으면 10초만 재생된 3분짜리 오디오를 보내느라 대역폭을 낭비한 셈이 됨
TTS가 실시간보다 빠르다는 주장에 대해서는, 최신/지향점의 음성 AI는 글쓴이가 설명한 방식에서 벗어나고 있음: https://research.nvidia.com/labs/adlr/personaplex/ 20ms 단위로 조금씩 입출력하는 쪽임
사용자의 원본 IP/포트가 바뀌지 않기를 바란다는 부분은 지원됨. ufrag에 대해 새 IP가 들어오면 처리 가능함
최소 8회 왕복 시간이 걸린다는 말도 틀림: https://datatracker.ietf.org/doc/draft-hancke-webrtc-sped/
오디오를 WebSocket으로 스트리밍하겠다는 선택은 AEC 같은 기능을 잃고, 복잡성을 클라이언트로 밀어냄. WebRTC의 단순함, 즉 createOffer -> setRemoteDescription 흐름 덕분에 사람들이 쉽게 시작할 수 있음. Realtime API + WebSocket에서는 많은 개발자가 코드가 많고 직접 처리해야 하는 부분 때문에 고생했음
개인적으로 고르라면 Offer/Answer 모델은 유지하되 DTLS+SCTP 대신 QUIC을 쓰고 싶음. 어쩌면 QUIC 위에서 RTP를 할 수도 있음. 프로토콜 자체에는 강한 선호가 없지만, 훨씬 큰 코드 footprint로 여러 클라이언트와 고객 클라이언트에 코드를 배포하는 방법은 잘 모르겠음
TTS 전문가는 아니지만 결과를 조금씩 흘려보내는 이점이 뭔지 모르겠음. 실리콘은 시간 숫자가 얼마나 빨리 증가하는지 신경 쓰지 않음
클라이언트가 자기 IP 변경을 알고 ICE 재협상을 할 수 있는 경우도 있지만, 모르는 경우가 많고 보통은 서버가 변경을 감지하길 기대함. 그런데 현재 로드밸런서 구성에서는 그게 불가능함. 큰 문제는 아니지만 이미 넘어야 할 절차가 많은 상황에서는 아쉬움
그 초안이 8 RTT가 아니라 7 RTT라는 뜻이라면, 일부는 파이프라인화할 수 있으니 실제 수치는 더 낮을 수 있음. 하지만 진짜 문제는 P2P가 쓰일 수도 있다는 이유만으로 필수 시그널링 서버와 이중 TLS 핸드셰이크가 생긴다는 점임
WebRTC가 새 개발자에게 쉬운 이유는 블랙박스 회의 앱이기 때문임. 하지만 OpenAI 같은 큰 회사에서는 그 블랙박스가 더 낮은 수준의 원시 기능으로 고칠 수 있는 문제를 만들기 시작함
RTP over QUIC은 꼭 실험해보면 좋겠고 도와줄 의향도 있음. 코드 크기가 걱정이라면 브라우저, 언젠가는 OS가 QUIC 라이브러리를 제공함. MoQ에 가까운 쪽으로 바꾸면 QUIC이 단편화, 재전송, 혼잡 제어 등을 처리하므로 애플리케이션은 놀랄 정도로 작아짐
RoQ/MoQ의 큰 한계는 QUIC이 데이터그램까지 포함해 혼잡 제어를 하기 때문에 GCC를 구현할 수 없다는 점임. 브라우저에서 보낼 때는 당분간 cubic/BBR에 묶이게 됨
지금 하는 일이 음성/화상 회의와 1:1 통화인데, WebRTC의 복잡성은 엄청남. 제품을 빨리 시작하게 해주긴 했지만, 이상한 일을 할 때 고치기가 어렵고, 클라이언트용으로 포크까지 해도 그렇다
TURN에 대해서는 긴 불평을 쓸 수도 있음. 사실 WebRTC 프로토콜 묶음 전체가 존재하지 않는 인터넷을 대상으로 설계된 것 같음
TURN은 클라이언트가 할당을 요청할 때 임시 포트가 아니라 rendezvous id를 할당해야 함. 그러면 피어는 서비스 포트로 TURN 서버에 접속해 그 rendezvous id에 대한 연결을 요청하면 되고, 클라이언트가 피어 주소를 알고 permission을 추가할 필요가 없음. 종단 간 릴레이 연결까지 필요한 통신이 줄어듦. 고급 클러스터는 id에 정보를 인코딩해 클라이언트와 피어가 각각 자기와 가까운 TURN 서버에 접속하고 서버끼리 연결하게 할 수 있음. 덜 고급인 클러스터는 id와 함께 TURN 서버 IP와 서비스 포트를 공유해야 함
실제 표시 타임스탬프와 그것이 실제 시간에 어떻게 대응하는지 알아야 할 필요가 왜 있겠냐는 대목이 뼈아프게 와닿음. WebRTC를 만든 사람 중 누구도 서로 다른 출처의 데이터 스트림을 밀리초 정확도로 동기화해본 적이 없는 듯함
브라우저에서 웹캠과 IMU 모듈을 이용한 영상 안정화 데모를 만들었는데, video->rtc->browser 경로와 sensor->websocket->browser 경로의 지연 시간이 크게 다르고 일정하지 않았음. 당연한 해법은 센서 데이터에 UTC 타임스탬프를 보내고 브라우저에서 동기화하는 것이지만, 비디오에는 UTC 타임스탬프 기준이 없어 불가능했음
WebRTC 파이프 양쪽을 모두 제어하면 스트림 시작 시점의 UTC 타임스탬프를 보내는 식의 재미있는 일을 할 수는 있지만, 브라우저 지터는 해결하지 못함. 개념 증명으로는 충분히 동작했지만 전체 해법은 다시 설계해야 했음
이 분야 경험이 많고 특허 출원도 몇 개 있음. Alexa에서는 기기가 서버로 연결을 맺고 계속 열어둔 뒤, wake word를 감지하면 그 연결 위로 사실상 HTTP2/SPDY 비슷한 것을 보냈음. 그래서 사용자가 말을 끝내기 전에 STT 처리를 시작할 수 있었고, 마지막 몇 조각 처리 지연만 남았음
답변도 같은 연결로 돌아왔음
OpenAI의 경우 Alexa처럼 지속 연결을 항상 열어두긴 어렵지만, 휴대폰에서 HTTP2를 쓰면 iOS와 Android가 그 연결을 거의 알아서 관리해줌
글쓴이가 맞음. 실시간 프로토콜은 꼭 필요하지 않고, 모든 데이터를 받는 게 더 중요함. 사용자는 지연이 500ms를 넘기 전까지는 거의 알아차리지 못함. 특히 모바일 시대에는 대부분 사람이 사람 간 실시간 통신에도 지연이 있는 것에 익숙함
OpenAI나 Anthropic에서 일한다면 연락해도 좋음. 더 자세히 이야기할 수 있음
전송 지연은 이미 큰 다른 모든 지연 위에 더해짐
그래서 전체 파이프라인의 종단 간 지연을 줄이기 위해 가능한 최저 지연 해법을 택한 것이라고 봄
사람 간 음성 지연과의 비유는 맞지 않음. 그 경우에는 사람을 지연이 없는 존재처럼 취급하기 때문임
500ms는 요즘 최첨단 음성 구현에서 운이 좋고 돈을 아끼지 않으며 speculative decoding과 reasoning 같은 비싼 기법까지 쓸 때의 바닥값에 가까움. LLM 단계만 450ms가 걸림. 상용 음성 AI에서는 모든 ms가 중요하고, 200~300ms만 더해도 대화 품질이 크게 나빠짐
우리 사업은 주로 비기술 사용자 대상 음성을 많이 다룸. 작년에 턴 간 지연이 1200~1500ms였을 때는 사용자 혼란, 끼어들기, 대화 이탈, 전반적으로 불쾌한 경험이 많았음. 지금은 필요한 도구 사용에 따라 약 700ms 수준이고, 실제 사람과의 상호작용에 견줄 만한 괜찮은 경험에 가까워지고 있음. 여기서 100ms를 더 줄이려고 꽤 많은 비용을 쓰고 있음
speculative LLM pass, speculative tool execution처럼 비싸고 낭비적인 일도 함. 사용자가 말하는 동안 여러 LLM 추론을 돌리되, 그 pass가 쓸 수 있고 사용자가 문장 끝에 중요한 말을 하지 않았다는 걸 알기 전에는 비멱등 도구 호출을 실제 실행하지 않는 식으로 100~200ms를 줄임. 500ms가 무관하다는 말은 사람-대-AI 음성 상호작용이 아닌 다른 사례를 말하는 것이라고 봄
음성 AI에서 진짜 어려운 문제는 가끔 빠지는 WebRTC 패킷이 아니라 강한 배경 소음, 에코, 억양임. WebRTC의 잘 다듬어진 AEC 구현은 적어도 에코에는 꽤 도움이 됨. OpenAI 규모에서 구현하기 매우 골치 아픈 프로토콜이라는 건 알지만, 초대규모가 아닌 애플리케이션에는 Daily 같은 상용 제공자와 괜찮은 해법이 많음. 진짜 풀 문제는 다른 곳에 있음. 그래도 내 지연 예산에 500ms를 더하면 애플리케이션은 죽음
안타깝게도 WebRTC만큼 구현하기 싫은 프로토콜이 드묾. 단순 클라이언트 하나를 띄우려 해도 SDP, TURN/STUN, ICE candidates, offer, P2P 프로토콜, 매번 처음부터 구현하는 복잡한 핸드셰이크에 빠르게 적응해야 함
프로토콜과 의도치 않은 “모범 사례”가 겹겹이 들어간 그 트렌치코트를 전부 다시 쓴다는 건 상상하기도 어렵다
교육 자료와 라이브러리가 늘면서 나아지고 있기를 바람. Codex 같은 도구가 이제는 이런 부분을 꽤 잘 밀고 나가는 것도 놀라움
브라우저 API 안정성 전반에는 문서화되지 않은 가장자리 사례가 많고, WebRTC만의 문제는 아님
답답할 정도로 한쪽으로 치우친 글임. WebRTC에 한계가 있는 건 맞지만, 표준에 기대면 많은 정확성을 얻고 장기 엔지니어링 비용을 줄일 수 있음. WebRTC가 복잡하다는 사실은 틀렸다는 뜻이 아니라, 공개 인터넷에서 실시간 미디어가 복잡하다는 뜻임
네트워킹은 본질적으로 상태를 가짐. NAT traversal, 지터 버퍼, 혼잡 제어, 패킷 손실, 코덱 상태, 암호화, 세션 라우팅은 오디오를 TCP나 WebSocket에 올린다고 사라지지 않음. 그렇지 않은 척하는 건 아키텍처적 명료함이 아니라 복잡성을 덜 보이는 곳으로 옮기는 것일 뿐임
1년 전에는 Discord에서 Rust로 WebRTC SFU를 다시 썼고, 반복되는 패턴이 보일 것임
WebRTC는 2000년대 초반부터 이어진 약 45개의 RFC와, TWCC나 REMB처럼 기술적으로는 초안인 사실상 표준들로 구성됨. 이걸 전부 구현해야 할 때는 전혀 즐겁지 않음
본인은 공인 WebRTC 전문가로 봐도 좋고, 그래서 다시는 WebRTC를 쓰고 싶지 않다고 함
보통 방식으로 충분히 시도해봤으니 반대 방향의 견해를 가질 자격은 충분하지 않나 싶음
주제 자체에 대한 입장은 없지만, 글에 분명히 인간적인 결이 있어서 좋았음
만약 AI가 쓴 글이라면 정말 큰일임
2026년인데도 원격회의는 여전히 엉망임. 수십억 달러가 걸려 있고 Zoom도 잘해야 평범한 수준이며, Microsoft의 뭐시기만큼 나쁠 때도 있음. 원격회의가 서툴고 거친 난장판이 아닌 걸 본 적이 없음
훌륭한 글임. 글쓴이가 해당 분야 전문가일 때 블로그 글에 상을 줄 수 있으면 좋겠음
“WebRTC는 나쁜 네트워크 상황에서 내 프롬프트를 열화시키고 떨어뜨리도록 설계됐다”는 말에 대해, 실시간을 원한다면 감수해야 할 일임. 실시간을 원하지 않고 모든 걸 STT -> Prompt -> TTS로 상상한다면 애초에 오디오를 네트워크로 보낼 필요가 없을 수도 있음
모든 저지연 애플리케이션은 품질과 지연 시간 사이의 사용자 경험 절충을 정해야 함. 혼잡은 큐잉, 즉 지연을 만들고, 이를 피하려면 무언가를 건너뛰어야 해서 품질이 낮아짐
WebRTC의 지연 시간 대 품질 조절 손잡이는 고정돼 있음. 지연 최소화에는 훌륭하지만 유연성이 부족함. 그래도 브라우저 지원 덕분에 사실상 몇 안 되는 선택지라서 여전히 WebRTC를 쓰려고 함
하지만 이제는 WebTransport가 있음. 범용 프로토콜로 WebRTC 비슷한 동작을 만들 수 있음. 스트림을 drop/reset하기 전에 얼마나 기다릴지 애플리케이션이 선택할 수 있고, 그 결정을 대신 당하지 않아도 됨
글의 요지는 사용자가 대개 스트리밍은 원하지만 드롭은 원하지 않는다는 것임. 오디오 입출력 스트리밍은 WebRTC 없이도 당연히 가능함. 오디오 패킷이 영원히 사라지는 시점을 애플리케이션이 정할 수 있어야 함. 50ms인지 500ms인지 5000ms인지 말임. 음성 AI가 50ms 옵션을 고르면 안 된다는 주장임
OpenAI가 응답할 때는 사용자가 들어야 하는 시점보다 앞서 오디오 대부분을 갖고 있음. 실시간보다 빠르게 오디오를 생성하므로 실시간 프로토콜은 맞지 않는 선택임
Gemini Live API를 관리형 WebRTC 클라우드 메시 위에서 돌리고 있는데 아주 잘 동작하고, 2년째 운영 중임. WebSocket을 시도하고 임시 키 등을 직접 처리할 수도 있지만, 이 영역에서 대규모 음성 에이전트를 운영하는 사람들과 이야기해보면 WebRTC와 Pipecat, 그리고 이미 해결된 문제들에 투입된 많은 리소스로 상당수가 풀려 있음
분명 과하다는 느낌이 들고 실제로도 그럴 수 있지만, 연결이 맺어진 뒤에는 꽤 마법 같음. 시작 시간과 버퍼링도 더 빠른 음성 연결을 위해 해결돼 있음: https://github.com/pipecat-ai/pipecat-examples/tree/main/ins... 영상은 더 어려움