필사 모드: WebRTC & 실시간 통신 2026 완벽 가이드 — LiveKit · Daily · Agora · Twilio · Pion · Mediasoup · Jitsi · Janus · AWS IVS · Cloudflare Calls 심층 분석
한국어프롤로그 — Programmable Video의 죽음과 새로운 질서
2024년 12월 5일, Twilio가 Programmable Video를 공식 종료했다. 한때 WebRTC PaaS의 대명사였던 제품이 신규 가입을 막은 게 2024-03이었고, 정확히 9개월 뒤 기존 워크로드도 모두 잘렸다. 이전을 망설이던 수천 개의 앱이 한 분기 동안 LiveKit · Daily · Agora · Vonage · Dolby.io · Zoom Video SDK 사이에서 새 둥지를 찾아 헤맸다.
그 빈자리에 누가 들어왔는가가 곧 2026년 실시간 통신의 지도다.
- **LiveKit**이 OpenAI Realtime API의 공식 transport로 채택되면서 AI 음성 에이전트의 사실상 표준이 되었다. 오픈소스 SFU와 LiveKit Cloud, Agents SDK가 한 묶음으로 움직인다.
- **Daily.co**는 Daily Bots와 함께 LLM·STT·TTS·SFU를 하나의 파이프라인으로 묶어 팔기 시작했고, Pipecat이 그 사이의 글루 코드를 표준화하고 있다.
- **Cloudflare Calls**가 0.05 USD/GB(아웃바운드 전송량 기준)라는 공격적 가격으로 들어와 SFU 시장에 가격 압력을 걸었다.
- **AWS IVS Real-Time**(2023-08 GA)는 Twitch의 인프라를 그대로 빌려와 100ms 미만의 글로벌 멀티-호스트 라이브 스트리밍을 만들어냈다.
- 그리고 표준 측에서는 **WebRTC NV**가 — RTCRtpScriptTransform · Encoded Audio/Video Frame · AV1 · L1T3 SVC — 오랜 실험을 워킹 드래프트로 끌어올렸다.
이 글은 그 지도를 처음부터 끝까지 그려본다. RTCPeerConnection의 한 줄짜리 코드부터, 9개 플랫폼의 비교 매트릭스, AI 음성 에이전트와의 통합, 그리고 한국·일본 시장의 사정까지.
1장 · WebRTC가 실제로 하는 일 — 세 개의 다리
WebRTC는 마법이 아니다. 세 개의 다리로 서 있는 표준이다.
[Browser A] [Browser B]
| |
| (1) Signaling — 어떻게 만날지 약속한다 |
| (WebRTC가 정하지 않는 부분 — WebSocket·SIP·임의) |
+----> Signaling Server (앱이 직접 운영) <----+
| |
| (2) ICE — 어디로 연결할지 후보를 모은다 |
+----> STUN (퍼블릭 IP·포트 알아내기) |
| TURN (NAT 뚫기 실패 시 릴레이) |
| |
| (3) Media — 실제 비디오/오디오/데이터를 흘린다 |
+-----------------DTLS-SRTP 암호화--------------- +
(P2P 또는 SFU/MCU 경유)
세 다리의 책임을 외워두면 도구 선택이 쉬워진다.
- **(1) Signaling은 WebRTC 표준의 범위가 아니다.** 어떤 채널이든 — WebSocket, Server-Sent Events, MQTT, SIP — 양쪽에 같은 SDP(Session Description Protocol)와 ICE candidate를 전달할 수 있으면 된다. LiveKit·Daily·Agora는 이 부분을 직접 만들어 SDK로 감춘다.
- **(2) ICE는 표준의 핵심이다.** STUN 서버로 자기 자신의 퍼블릭 IP·포트를 알아내고, 그래도 안 되면 TURN 서버로 미디어를 릴레이한다. 오픈소스 coturn이 사실상 표준이다.
- **(3) Media는 항상 DTLS-SRTP로 암호화된다.** 평문 미디어는 표준에 존재하지 않는다. 위에 얹는 코덱은 Opus(오디오 필수), VP8/VP9/H.264/AV1(비디오 — AV1과 H.265는 2024년부터 본격적으로 등장).
세 다리 중 한쪽만 빠져도 통신은 성립하지 않는다. PaaS가 파는 것은 이 세 다리를 "동작하는 묶음"으로 묶어주는 노력이다.
2장 · RTCPeerConnection — 한 페이지로 보는 코어 API
브라우저가 노출하는 표면은 의외로 작다. 핵심은 세 객체다.
- `RTCPeerConnection` — 피어 한쪽을 표현하는 객체. SDP offer/answer, ICE candidate, 트랙 송수신을 모두 여기서 한다.
- `MediaStream` / `MediaStreamTrack` — 카메라/마이크/화면 공유의 추상.
- `RTCDataChannel` — 미디어가 아닌 임의 데이터를 같은 PeerConnection 위로 보낸다.
가장 작은 양쪽 연결 예시(시그널링은 의사코드):
// 양쪽 공통 셋업
const pc = new RTCPeerConnection({
iceServers: [
{ urls: 'stun:stun.l.google.com:19302' },
{ urls: 'turn:turn.example.com:3478', username: 'u', credential: 'p' },
],
})
pc.onicecandidate = (e) => e.candidate && signaling.send('ice', e.candidate)
pc.ontrack = (e) => (remoteVideo.srcObject = e.streams[0])
const stream = await navigator.mediaDevices.getUserMedia({ video: true, audio: true })
stream.getTracks().forEach((t) => pc.addTrack(t, stream))
// caller
const offer = await pc.createOffer()
await pc.setLocalDescription(offer)
signaling.send('sdp', offer)
// callee
signaling.on('sdp', async (sdp) => {
await pc.setRemoteDescription(sdp)
const answer = await pc.createAnswer()
await pc.setLocalDescription(answer)
signaling.send('sdp', answer)
})
40줄 정도면 1:1 통화가 뜬다. 문제는 여기부터다. 3명, 30명, 300명으로 늘어나는 순간 P2P 망을 유지하는 비용이 폭발한다. 그래서 다음 장이 필요해진다.
3장 · 토폴로지 — Mesh · MCU · SFU의 차이
세 가지 위상이 있고, 2026년 현장에서 거의 모든 그룹 통화는 SFU다.
Mesh (N:N 완전 그래프)
A <----> B
^ \ / ^
| \/ |
| /\ |
v / \ v
D <----> C
업·다운링크: O(N) per peer, 총 O(N^2)
장점: 서버 비용 0, 종단간 암호화 자연스러움
단점: 4~5명 넘어가면 클라이언트 CPU·대역폭 폭발
MCU (Multipoint Conferencing Unit — 서버가 디코딩·믹싱·재인코딩)
A ─┐
B ─┼─► [MCU: 디코드 → 합성 → 재인코드] ─► 한 장의 비디오 ─► 모두에게
C ─┤
D ─┘
장점: 클라이언트 대역폭 1개 스트림만, 옛 디바이스 호환
단점: 서버 CPU 비용 매우 큼, 종단간 암호화 불가능
SFU (Selective Forwarding Unit — 서버는 라우팅만)
A ─► [SFU] ─► B, C, D
B ─► [SFU] ─► A, C, D
...
장점: 서버 CPU 가볍고 확장 쉬움, simulcast/SVC로 수신자별 품질 조절
단점: 클라이언트 다운링크 O(N), 종단간 암호화는 Insertable Streams로 별도 처리
2026년에 새로 짓는 그룹 통화 시스템에서 MCU는 거의 등장하지 않는다. SFU가 표준이고, 100명을 넘는 청중 모드는 SFU + HLS/LL-HLS·WHEP 분기가 일반적이다. LiveKit·Mediasoup·Janus·Jitsi Videobridge·Agora·Daily·Cloudflare Calls 모두 SFU다.
4장 · WebRTC NV — 표준은 어디까지 왔는가
WebRTC 1.0은 2021년 1월 W3C 권고가 되었고, 그 이후의 모든 신기능은 "WebRTC NV(Next Version)"라는 이름으로 묶여 W3C WebRTC 워킹 그룹과 IETF RTCWEB에서 진행되어왔다. 2026년 시점에 실무에서 의미가 큰 항목들.
- **Insertable Streams / RTCRtpScriptTransform** — 인코딩된 프레임에 JavaScript로 접근해 E2EE, 워터마킹, 적응형 트랜스코딩을 만들 수 있다. Chromium에서는 이미 안정. Safari·Firefox 26 이후 보편화.
- **Encoded Audio/Video Frame** — 위 transform에서 다루는 단위. `RTCEncodedAudioFrame`, `RTCEncodedVideoFrame`. 메타데이터 포함.
- **AV1** — 코덱. 동일 화질에서 VP9 대비 약 30% 비트레이트 절감. Chrome 90+, Safari 17+, Firefox 116+에서 디코드, 인코드는 디바이스 의존적. 하드웨어 인코더가 부족해 여전히 fallback이 필요.
- **L1T3 SVC(Scalable Video Coding)** — 한 인코드로 시간축 3개 레이어를 만들어 SFU가 수신자별로 골라 보낸다. simulcast(공간축)와 보완 관계.
- **Selectable Audio Output (setSinkId)** — 출력 장치 선택. Chrome·Edge·Safari·Firefox 모두 안정.
- **WebRTC-HTTP Ingest/Egress (WHIP/WHEP)** — IETF RFC. SDP 한 번 POST로 인코더가 미디어를 서버에 푸시(WHIP), 시청자가 풀(WHEP). OBS Studio 30+ · FFmpeg 7 · Cloudflare Stream Live · AWS IVS · LiveKit 모두 지원.
- **WebCodecs / WebTransport** — WebRTC와 인접한 표준. 인코딩/디코딩과 트랜스포트를 분리해 게임이나 클라우드 게이밍에서 더 낮은 지연을 만든다.
2024년까지 "실험"이던 것들이 2026년에 한꺼번에 보편 표준이 되었다는 점이 중요하다.
5장 · 코덱 — Opus는 신, 비디오는 정치다
오디오에는 사실상 선택지가 없다. WebRTC 표준 필수 코덱이 Opus다. 8kHz 음성부터 48kHz 음악까지, 가변 비트레이트, 낮은 지연. 음성 AI 에이전트에서도 Opus가 그대로 쓰인다.
비디오는 정치다.
- **VP8** — 가장 보편적이고 호환성이 높다. 라이선스 없음. 하드웨어 가속이 약하다.
- **VP9** — 동일 화질에서 VP8 대비 약 50% 절감. Chrome/Edge/Firefox/Safari 14+ 모두 디코드.
- **H.264 (Baseline / Constrained Baseline)** — 모바일 하드웨어 가속이 거의 보편적. 특허 비용이 있지만 PaaS가 처리한다.
- **H.265 / HEVC** — 라이선스 분쟁이 길어 WebRTC에서는 사실상 비주류. Apple 디바이스 중심.
- **AV1** — 미래. 30% 더 효율적. 인코딩 비용이 비싸 simulcast/SVC와 함께 단계적 도입.
- **Lyra** — Google의 신경망 기반 음성 코덱. 3kbps에서도 명료. WebRTC 표준에는 진입하지 못했지만 SDK 내부에서 사용 가능.
2026년 기본 권장: 오디오는 Opus 단일, 비디오는 simulcast로 VP9 + H.264, AV1은 옵션. 화면 공유는 VP9 또는 AV1이 텍스트에 강하다.
6장 · ICE · STUN · TURN — 가장 자주 망가지는 부분
WebRTC 운영에서 가장 자주 망가지는 곳이 ICE 후보 수집이다. 사내망·기업 방화벽·캐리어 그레이드 NAT·IPv6 절반 적용 환경에서 STUN만으로는 부족한 경우가 자주 생긴다.
- **STUN** — 공용 IP·포트만 알려준다. 매우 가볍다. Google의 `stun:stun.l.google.com:19302`가 사실상 공용 인프라.
- **TURN** — 미디어 자체를 릴레이한다. 실제 트래픽을 흘리는 서버이므로 대역폭 비용이 크다. 보통 글로벌 통화 트래픽의 10~25%가 TURN을 거친다.
- **TURN-TLS(443)** — 기업 방화벽이 UDP를 막을 때 TCP/443으로 우회. 지연이 더 크지만 연결률을 끌어올린다.
- **Trickle ICE** — 후보를 모은 즉시 전송. 첫 패킷 도착 시간을 단축. 표준화된 지 오래되었지만 실제 구현은 다양하다.
오픈소스 표준은 **coturn**. PaaS는 자체 글로벌 TURN을 운영하고 일정 GB까지 무료로 묶어 팔거나, 별도 청구한다. Cloudflare TURN(2023 출시)이 가격 파괴자 역할을 하면서 다른 PaaS의 TURN 단가도 내려갔다.
7장 · 9개 플랫폼 한 줄 요약
2026년 실무 후보군을 한 줄씩 정리하면 이렇다.
- **LiveKit** — 오픈소스 SFU + LiveKit Cloud + Agents SDK. OpenAI Realtime API 공식 transport. Apache 2.0.
- **Daily.co** — 매니지드 SFU + Daily Bots + Pipecat 글루. AI 음성 통합 사용성이 가장 부드럽다.
- **Agora** — 글로벌·중국 동시 커버가 강점. 4.x SDK, 100ms 미만 지연 글로벌 평균.
- **Twilio Video** — 2024-12-05 종료. 대체 권장: Zoom Video SDK, LiveKit, Daily, Vonage.
- **Pion** — Go로 짠 오픈소스 WebRTC 스택. 라이브러리. 인프라를 직접 짤 때.
- **Mediasoup 3** — Node.js + C++ SFU 라이브러리. 매우 강력한 라우터, 직접 짜는 팀용.
- **Jitsi Meet / JVB / Jicofo** — 오픈소스 회의실. 자체 호스팅 표준. 8x8가 운영.
- **Janus Gateway** — Meetecho의 모듈식 게이트웨이. 플러그인으로 회의·스트리밍·녹화·SIP 게이트 모두.
- **AWS IVS Real-Time** — Twitch 인프라 기반. 매니지드. 라이브 스트리밍과 다자 호스트.
- **Cloudflare Calls (Realtime SFU)** — 0.05 USD/GB 아웃바운드. 글로벌 엣지에 SFU.
다음 장부터 각 플랫폼을 자세히 본다.
8장 · LiveKit — OpenAI Realtime API의 표준 transport
LiveKit은 2021년 시작된 오픈소스 프로젝트로, 2024년 OpenAI Realtime API가 첫 공식 SDK로 LiveKit Agents를 채택하면서 사실상 표준 위치를 굳혔다.
세 개의 레이어가 한 묶음으로 움직인다.
- **LiveKit Server** — Go로 짠 SFU. Apache 2.0. 단일 노드로 수만 개 동시 세션, 클러스터로 수십만. ION/Mediasoup와 함께 오픈소스 SFU 3대장.
- **LiveKit Cloud** — 위 서버를 글로벌 엣지에 매니지드로 띄운다. 워크스페이스 단위 과금. Free 50GB/월, Build 100 USD/월부터.
- **LiveKit Agents** — 음성 에이전트 프레임워크. STT·LLM·TTS를 한 파이프라인에 묶어 LiveKit Room에 봇으로 참여시킨다. OpenAI Realtime · GPT-4o Realtime · Anthropic Claude · Google Gemini · Cartesia · ElevenLabs · Deepgram · Whisper 모두 어댑터.
핵심 API는 Room 중심이다.
const room = new Room({ adaptiveStream: true, dynacast: true })
room
.on(RoomEvent.TrackSubscribed, (track, pub, participant) => {
if (track.kind === 'video') document.body.appendChild(track.attach())
})
.on(RoomEvent.ParticipantConnected, (p) => console.log('joined', p.identity))
await room.connect('wss://your.livekit.cloud', token)
await room.localParticipant.enableCameraAndMicrophone()
`adaptiveStream`이 수신자 화면 크기에 따라 SFU에 다른 simulcast 레이어를 요청하고, `dynacast`는 보지 않는 트랙의 송출을 자동 정지한다. 두 기능이 클라우드 대역폭 비용에 직접적으로 작용한다.
9장 · Daily.co + Daily Bots + Pipecat — AI 음성에 가장 부드러운 스택
Daily는 2016년부터 매니지드 WebRTC를 팔아온 회사고, 2024년 들어 Daily Bots와 Pipecat 오픈소스 프레임워크를 묶어 "AI 통화를 가장 쉽게 만드는 곳" 포지셔닝을 굳혔다.
- **Daily SDK** — JS/iOS/Android/React Native. `daily-js`로 임베드형 통화 UI를 한 줄로 띄울 수 있다.
- **Daily Bots** — 매니지드 서버 사이드 봇. LLM·STT·TTS를 묶어 통화에 참여시킨다.
- **Pipecat** — 오픈소스. STT·LLM·TTS를 노드 그래프로 연결하는 파이프라인. Daily가 만들었지만 transport 독립적이라 LiveKit·Twilio Programmable Voice·전화망에서도 동작.
대표적인 한 줄 호출:
const call = DailyIframe.createFrame({ url: 'https://yourdomain.daily.co/room' })
call.join()
`createFrame`이 iframe을 만들고 Daily의 UI를 통째로 넣는 형태. UI 커스터마이즈가 필요하면 `createCallObject` 모드로 떨어뜨려 모든 트랙을 직접 컨트롤한다.
가격은 분당 과금 모델로, Free 10,000분/월, Scale plan 600 USD/월 + 사용량. 다른 PaaS와 달리 대역폭이 아닌 참여자·분 기준이라 예측이 쉽다.
10장 · Agora — 글로벌·중국 동시 커버의 사실상 유일한 선택지
Agora는 2014년 상하이/실리콘밸리에서 시작한 회사로, SoftBank 산하 SD-RTN(Software-Defined Real-Time Network)이라는 자체 글로벌 망을 운영한다. 4.x SDK 기준 세계 평균 first-frame-time 76ms, 5G 환경에서 글로벌 평균 e2e 지연 100ms 미만을 광고한다.
중국 내 워크로드를 갖는 모든 글로벌 서비스는 이 지점에서 Agora를 진지하게 검토하게 된다. 다른 PaaS는 중국 본토에서 안정적 운영이 어려운 경우가 많고, 정부 규제(ICP 등) 대응도 Agora가 가장 경험이 많다.
API는 Channel 모델이다.
const client = AgoraRTC.createClient({ mode: 'rtc', codec: 'vp9' })
await client.join(appId, channel, token, uid)
const [mic, cam] = await Promise.all([
AgoraRTC.createMicrophoneAudioTrack(),
AgoraRTC.createCameraVideoTrack({ encoderConfig: '1080p_1' }),
])
await client.publish([mic, cam])
가격은 분당 + 화질별. 1080p 비디오 분당 약 0.0099 USD, HD가 0.00399. 글로벌·중국 라우팅 비용은 별도. 다른 PaaS보다 가격 매트릭스가 복잡하지만 대량 디스카운트가 큰 편.
11장 · Twilio Video의 종료와 마이그레이션 경로
2024-03-04, Twilio는 Programmable Video 신규 가입을 막았다. 2024-12-05, EOL. 5년 동안 WebRTC PaaS의 사실상 표준이었던 제품이 — Twilio Voice/Messaging은 살아남았지만 — 비디오는 죽었다.
공식 마이그레이션 가이드가 가리킨 대체재는 Zoom Video SDK였다. Zoom이 마이그레이션 패키지를 만들고 코드 변환 도구를 공급했다. 실제로 시장은 더 분산되어 갔다.
- **Zoom Video SDK** — Twilio와 가장 가까운 SDK 모양. 분당 과금. 마이그레이션 도구가 가장 잘 갖춰져 있다.
- **LiveKit Cloud** — 오픈소스 친화 팀. Twilio Programmable Video에서 LiveKit Room으로 거의 1:1 매핑되는 마이그레이션 가이드 공식 제공.
- **Daily.co** — 빠르게 AI 음성으로 확장하고 싶은 팀.
- **Vonage Video API**(구 OpenTok) — 가장 오래된 PaaS. SDK API가 Twilio와 비슷한 추상도.
- **Dolby.io Communications** — 공간 오디오·고음질이 필요한 팀.
2025년 한 해는 마이그레이션의 해였고, 2026년에는 위 다섯 곳으로 트래픽이 분산되어 들어갔다는 게 시장 데이터에 드러난다.
12장 · Pion — Go로 짠 WebRTC 스택
Pion은 Sean DuBois가 2018년 시작한 Go 기반 WebRTC 라이브러리다. 매니지드 서비스가 아니라 "Go에서 WebRTC를 직접 짤 수 있게 해주는 도구"다. WebRTC를 직접 구현하기로 결정한 팀이 가장 먼저 보는 곳.
특징.
- **모듈식** — DTLS·SRTP·ICE·SCTP·RTP·RTCP가 별도 패키지. 필요한 만큼만 가져다 쓴다.
- **Go의 동시성 모델** — 수만 개의 PeerConnection을 한 노드에서 다루기 쉽다.
- **상용 도입** — Twitch Cloud Game · Hopin · WeWork · LiveKit 일부 컴포넌트.
대안으로 Rust 진영에는 **WebRTC-rs**가 있고(2023년 시작, Pion API와 유사한 구조로 의도적으로 짠 포트), C++ 진영에는 Google이 만든 libwebrtc 본가가 있다. 매니지드 SFU를 처음부터 짜겠다는 결정에는 Pion·WebRTC-rs·libwebrtc 중 선택이 자연스럽다.
13장 · Mediasoup 3 — Router · Worker 모델의 정수
Mediasoup은 José Luis Millán(이전 SIP.js)이 시작한 Node.js + C++ SFU 라이브러리다. 매니지드가 아니라 라이브러리. 직접 SFU를 짓겠다는 팀이 가장 자주 선택한다.
- **C++ Worker 프로세스** — 한 프로세스가 한 CPU 코어를 점유. 미디어 라우팅의 핫패스.
- **Node.js Router 객체** — Worker 위에 있는 JS 추상. 룸·peer·transport를 관리.
- **Pipe Transport** — Router 간 미디어 전달. 멀티 노드 확장 표준 패턴.
- **DataProducer / DataConsumer** — SCTP 위 DataChannel을 SFU가 라우팅.
대표적인 사용처로 Atlassian·Versatica·Whereby·LiveKit(일부) 등이 있다. 매니지드를 만들 자원이 없는 팀이 Mediasoup 위에 자체 SFU를 짓고, 그 위에 비즈니스 룸을 얹는 패턴.
14장 · Jitsi Meet — 자체 호스팅의 표준
Jitsi는 BlueJimp가 시작했고, 2015년 Atlassian이 인수, 2018년 8x8로 다시 이전된 오픈소스 회의 스택이다. 자체 호스팅 회의를 띄울 때 가장 자주 선택되는 묶음.
- **Jitsi Videobridge (JVB)** — 자바로 짠 SFU. 단일 노드 수백 명, 캐스케이드로 수천 명.
- **Jicofo (Jitsi Conference Focus)** — XMPP 기반 시그널링과 컨퍼런스 포커스.
- **Prosody** — XMPP 서버.
- **Jitsi Meet** — React 프런트엔드. meet.jit.si가 레퍼런스 인스턴스.
- **Jibri** — 녹화·라이브 스트리밍 봇. Chromium을 띄워 화면을 캡처한다.
자체 호스팅의 정석은 docker-jitsi-meet 묶음. 한 VM에 한 줄로 띄울 수 있다. 보안 요구가 높은 정부·의료·교육 분야에서 가장 많이 본다.
15장 · Janus Gateway — 모듈식 게이트웨이의 정수
Janus는 이탈리아 Meetecho가 만든 C 기반 WebRTC 게이트웨이다. SFU·MCU·SIP gateway·녹화·스트리밍·NoSIP을 플러그인으로 갈아끼우는 구조. Jitsi가 회의에 특화되어 있다면 Janus는 "WebRTC를 무언가에 붙이는 일반 게이트웨이"에 가깝다.
주요 플러그인.
- **videoroom** — SFU 모드 그룹 통화.
- **streaming** — RTSP/RTP를 받아 WebRTC로 분기. 카메라·OBS 라이브 분배.
- **sip** — SIP gateway. PSTN 통화를 WebRTC로 끌어온다.
- **recordplay** — 녹화·재생.
- **textroom** — DataChannel 기반 채팅룸.
Discord 음성 채널 시절(2017-2020), Slack Huddle 초기, Microsoft Teams 일부 분기 등이 Janus 또는 그 파생을 썼다는 게 공개된 적이 있다. 자유도가 가장 높은 대신 운영 난도가 높다.
16장 · AWS IVS Real-Time과 Cloudflare Calls
매니지드 SFU의 가장 새로운 두 축이 클라우드 제공자에서 나왔다.
**AWS IVS (Interactive Video Service)**는 Twitch의 인프라를 AWS 상품으로 빌려온 결과물이다. 2020년 라이브 스트리밍 모드로 출발했고, 2023-08 IVS Real-Time이 GA되면서 다자 호스트(stage) 기능을 얹었다.
- **Stage** — 최대 12명까지 호스트가 실시간 양방향. 라이브로 청중에게 송출.
- **Channel** — 단방향 라이브 스트리밍. LL-HLS 5초 미만 지연.
- **Composition** — 서버 사이드 합성으로 한 장의 비디오로 다운스트림 송출.
- **WHIP** 지원 — OBS·FFmpeg·자체 인코더에서 곧장 푸시.
가격은 Stage 0.0149 USD/분/참여자, Channel은 시청 시간 + 인코딩 시간으로 분리.
**Cloudflare Calls (Realtime SFU)**는 2023-11 베타 출시, 2024-09 GA. 한 줄 가격이 충격이었다.
- **0.05 USD/GB** 아웃바운드 — 다른 PaaS의 1/5~1/10 가격.
- 글로벌 엣지 — Cloudflare의 300여 PoP를 그대로 SFU로 사용.
- **TURN over 443** 무료 포함. Cloudflare TURN을 단독으로도 판매.
가격 압력이 곧 다른 PaaS의 가격표를 끌어내렸다. Cloudflare는 또 Calls 위에 WebRTC-WHIP/WHEP 게이트웨이도 함께 운영한다.
17장 · OpenAI Realtime API · Claude voice · Cartesia · ElevenLabs — AI 음성의 transport
2024년 10월, OpenAI가 Realtime API를 공개했다. 그 핵심 변화는 "GPT-4o가 처음으로 텍스트가 아닌 음성으로 직접 들고 직접 말한다"는 것이었다. 이전까지 음성 에이전트는 STT → LLM → TTS의 세 모델 직렬이었는데, Realtime은 그 세 단계를 GPT-4o 한 모델 안에 녹였다.
여기서 LiveKit이 결정적이었다. OpenAI가 공식 SDK를 만들 때 LiveKit Agents를 택했고, 그 결과 LiveKit이 사실상 표준 transport가 되었다. WebSocket 직결도 가능하지만, 운영용으로는 거의 모두 LiveKit Agents를 통해 SFU 위로 올린다.
비슷한 시점에 등장한 경쟁자들.
- **Anthropic Claude voice** — Claude 3.5/3.7 위의 음성 에이전트. Pipecat·LiveKit Agents 모두 어댑터 제공.
- **Google Gemini Live API** — 2024 I/O에서 공개. 멀티모달 양방향 스트림.
- **Cartesia Sonic** — TTS. 90ms 첫 토큰 지연. 음성 에이전트의 응답 지연을 깎는 데 가장 자주 동원된다.
- **ElevenLabs Conversational AI** — STT·LLM·TTS·turn-taking을 묶은 매니지드. 자체 transport 또는 Twilio·LiveKit 연결.
- **Deepgram Aura** — TTS. 200ms 지연.
- **Whisper / Whisper-Large-v3** — STT. 오픈소스 기반.
WebRTC의 P95 e2e 지연이 200ms 안쪽일 때, AI 음성의 전체 사용자 체감 지연(말 끝→다음 말 시작)을 500ms 안쪽으로 만드는 게 2026년의 표준 목표가 되었다. 그 목표를 가능하게 한 것이 곧 WebRTC 표준 + AI 모델의 결합이다.
18장 · WHIP · WHEP — 라이브 스트리밍이 WebRTC로 옮겨오다
오랫동안 라이브 스트리밍은 RTMP push와 HLS pull의 짝이었다. 인코더(OBS)가 RTMP로 미디어 서버에 푸시하고, 시청자가 HLS로 풀. 지연은 보통 6~30초.
2022년 IETF가 표준화를 시작한 WHIP(WebRTC-HTTP Ingest Protocol)와 WHEP(WebRTC-HTTP Egress Protocol)이 그 짝을 대체하기 시작했다. 핵심은 단순함이다.
- **WHIP** — 인코더가 SDP를 HTTP POST로 보낸다. 서버가 SDP answer를 응답. 그 뒤는 평범한 WebRTC.
- **WHEP** — 시청자가 SDP를 HTTP POST로 보낸다. 그 뒤는 WebRTC.
이 한 번의 POST 덕에 — RTMP/SDP 양쪽이 같은 WebRTC 위로 통합되었다. 지연도 1~3초 수준으로 떨어진다.
2026년 지원 현황.
- **OBS Studio 30+** — WHIP 출력 기본 지원.
- **FFmpeg 7+** — WHIP muxer.
- **Cloudflare Stream Live · AWS IVS · Mux · Daily · LiveKit · Wowza · Ant Media** — WHIP/WHEP 모두 지원.
- 브라우저는 WHEP를 별도 SDK 없이도 `RTCPeerConnection` + `fetch` 한 줄로 구현 가능.
RTMP는 죽지 않았지만, 2030년경에는 신규 시스템에서 거의 모두 WHIP/WHEP로 옮겨갈 거라는 게 표준 진영의 컨센서스다.
19장 · 한국과 일본의 실시간 통신 시장
한국·일본 시장은 글로벌 PaaS에 더해 로컬 사업자가 강한 영역이다.
**한국 — NHN TalkN, NCP Real-Time Comms, KakaoTalk 음성**
- **NHN TalkN** — NHN Cloud가 운영하는 매니지드 WebRTC. 게임·교육 분야에서 자주 채택. 국내 데이터 레지던시 요구 대응이 강점.
- **Naver Cloud Platform Real-Time Comms** — 네이버 클라우드의 매니지드 SFU. 국내 KISA·VOIP 인증 대응.
- **카카오톡 음성·영상통화** — 자체 스택. 외부 공개 SDK는 없지만 카카오 i 비즈콜·카카오워크에서 일부 API 노출.
- **줌·구글 미트·MS 팀즈** — 한국 기업 협업 표준. WebRTC 위에 동작.
**일본 — Skyway (NTT Communications), Yahoo!Japan, NTT-X**
- **Skyway** — NTT Communications가 운영. 2014년부터 가장 오래된 국내 PaaS. 2023년 v2 출시로 SDK가 완전히 갈렸다. 국내 데이터 센터·일본어 문서가 강점.
- **NTT Communications Smart Workspace** — Skyway 위에 얹은 협업 SaaS.
- **LINE 음성·영상통화** — 자체 스택. LINE WORKS에 통합.
- **Yahoo!Japan** — 자체 회의 시스템.
일본은 Skyway가 단단해 글로벌 PaaS의 점유율이 한국보다 낮은 편이다. 한국은 글로벌 PaaS(특히 줌·구글 미트·Agora·LiveKit)의 침투가 더 빠르다.
20장 · 의사 결정 매트릭스 — 어디서 무엇을 쓸까
2026년 5월 기준 시나리오별 권장.
- **1:1 화상 통화 — 디자인 자유도가 가장 중요한 SaaS** → LiveKit Cloud 또는 Daily.co. UI 100% 커스텀이 쉽다.
- **그룹 회의 — Zoom급 기능을 처음부터** → Zoom Video SDK가 가장 빠른 ramp-up. 디자인 자유도는 낮다.
- **글로벌·중국 동시 커버가 필수** → Agora 외에는 사실상 선택지가 없다.
- **자체 호스팅 · 정부·의료·교육** → Jitsi Meet 또는 Janus Gateway. 데이터가 외부로 나가지 않는다.
- **라이브 스트리밍 + 다자 호스트** → AWS IVS Real-Time. Twitch 친화 워크플로우.
- **가격이 가장 중요한 대규모 청중** → Cloudflare Calls + WHEP. 0.05 USD/GB.
- **AI 음성 에이전트** → LiveKit Agents + OpenAI Realtime / Claude voice + Cartesia/ElevenLabs. 사실상 표준.
- **SFU를 직접 짓겠다** → Mediasoup 3(Node.js) 또는 Pion(Go) 또는 ION.
- **국내 데이터 레지던시 — 한국** → NHN TalkN 또는 NCP Real-Time Comms.
- **국내 데이터 레지던시 — 일본** → Skyway v2.
이 매트릭스가 만능 답은 아니다. 가격, 팀의 언어 스택, 운영 인력, 데이터 거버넌스, 정부 인증이 모두 변수다. 다만 처음 후보를 좁히는 데는 충분히 쓸 수 있다.
21장 · 운영의 함정 — 실제로 망가지는 지점들
매니지드든 자체 호스팅이든, 운영에서 자주 망가지는 지점은 비슷하다.
- **첫 번째 연결 실패** — TURN 설정. 기업망에서 UDP가 막혀 TURN-TLS(443)이 필요한 경우가 많다.
- **품질 저하** — 적응형 시뮬캐스트가 비활성. 송신측 업링크가 좁을 때 자동 다운레이어가 동작하지 않으면 모두가 깨진다.
- **녹화 누락** — 서버 사이드 녹화 SDK 권한 누락, 또는 컨테이너 디스크 풀.
- **오디오 에코** — `echoCancellation: true`가 일부 디바이스에서 미동작. AEC3 강제 필요.
- **모바일 백그라운드 끊김** — iOS Safari의 백그라운드 제약. PWA에서 특히. 표준은 점점 완화되고 있다.
- **CPU 폭주** — VP9/AV1 소프트웨어 인코딩이 모바일에서 CPU를 100% 점유. H.264 simulcast fallback 필요.
- **시계 동기 어긋남** — NTP가 잘못 잡혀 RTCP가 깨진다. 컨테이너에서 자주.
- **TURN 비용 폭주** — TURN 사용률 25%를 넘기면 비용 모델을 다시 본다.
운영 매뉴얼의 표준은 — "P95 지연, 접속 실패율, TURN 사용률, 디바이스별 인코더 폴백 비율"의 네 그래프를 항상 띄워두는 것이다.
22장 · 보안 — DTLS-SRTP, E2EE, 워크플로우
WebRTC의 기본 보안은 강하다. 모든 미디어가 DTLS-SRTP로 암호화되고, SDP에 키가 노출되지 않는다. 표준 자체에는 "암호화 끄기" 옵션이 없다.
문제는 SFU다. SFU는 미디어를 라우팅하기 위해 DTLS-SRTP를 한 번 풀어야 한다. 즉 SFU 운영자는 평문 미디어를 볼 수 있는 위치에 있다. 진짜 종단간 암호화(E2EE)가 필요한 경우, **Insertable Streams / RTCRtpScriptTransform**으로 SFU 이전에 한 번 더 암호화한다.
- **Jitsi의 E2EE** — Insertable Streams 기반. 한 키를 모든 참여자가 공유.
- **Google Meet E2EE** — 1:1·소그룹 한정. 동일 메커니즘.
- **Zoom E2EE** — 별도 옵션. 일부 기능(녹화·전화 게이트) 제약.
- **LiveKit E2EE** — Insertable Streams + Web Crypto. 클라이언트 라이브러리 내장.
E2EE를 켜는 순간 — 서버 사이드 녹화·서버 사이드 자막·SFU 트랜스코딩이 모두 불가능해진다. 이 트레이드오프를 처음부터 설계해야 한다.
추가로 신경 쓸 것.
- **JWT 토큰 만료** — Room 입장 토큰의 TTL은 짧게.
- **TURN 자격증명 회전** — 정적 자격증명은 위험. ephemeral credential 표준 사용.
- **워터마크** — 화면 공유에 사용자 ID 워터마크. RTCRtpScriptTransform으로 가능.
23장 · 미래 — WebTransport · QUIC · 클라우드 게이밍 인접
WebRTC 옆에는 비슷한 문제를 다른 방식으로 푸는 표준들이 자라고 있다.
- **WebTransport** — QUIC 위의 양방향·신뢰성 선택 가능한 트랜스포트. WebSocket·WebRTC DataChannel의 후속. Chrome·Edge·Firefox 지원, Safari 26+.
- **WebCodecs** — 코덱을 브라우저가 노출. 트랜스포트와 분리. 게임에서 자체 라우팅을 만들 때 유리.
- **Media over QUIC (MoQ)** — IETF 작업 그룹. 라이브 미디어를 QUIC 위에서 표준화. 2027~2028년 표준화 목표.
- **HTTP/3 멀티플렉싱** — 시그널링까지 한 커넥션에 묶는다.
- **클라우드 게이밍 — NVIDIA GeForce NOW · Xbox Cloud Gaming** — WebRTC + WebCodecs + WebTransport 조합.
WebRTC가 사라지지는 않는다. 다만 "특정 워크로드에서는 WebRTC가 무겁다"는 문제 인식이 5년 사이 굳어졌고, 그 옆에서 WebTransport · MoQ가 자라고 있다. 2030년 즈음에는 통화는 여전히 WebRTC, 라이브·게임·메시지는 WebTransport·MoQ — 이런 구도가 자리 잡을 가능성이 크다.
24장 · 마무리 — 한 줄의 권고
2026년에 새로 실시간 통신을 시작하는 팀에게 한 줄로 권고한다면:
- **AI 음성 에이전트** — LiveKit Cloud + LiveKit Agents + OpenAI Realtime 또는 Claude voice.
- **사람 간 그룹 회의** — Daily.co 또는 LiveKit Cloud. UI 자유도와 가격이 가장 균형 잡혀 있다.
- **글로벌·중국 동시** — Agora.
- **자체 호스팅** — Jitsi Meet 또는 LiveKit Server.
- **라이브 스트리밍 + 다자 호스트** — AWS IVS Real-Time.
- **대량 청중 저비용** — Cloudflare Calls.
- **국내 데이터** — 한국 NHN TalkN, 일본 Skyway.
표준은 안정되었다. 도구는 충분히 다양하다. 이제 남은 일은 — 우리 워크로드에 맞는 묶음을 고르고, P95 지연과 운영 그래프를 항상 띄워두는 것이다.
References
- W3C WebRTC 1.0: https://www.w3.org/TR/webrtc/
- W3C WebRTC NV Use Cases: https://www.w3.org/TR/webrtc-nv-use-cases/
- IETF RTCWEB Working Group: https://datatracker.ietf.org/wg/rtcweb/about/
- WHIP RFC 9725: https://datatracker.ietf.org/doc/rfc9725/
- WHEP draft: https://datatracker.ietf.org/doc/draft-ietf-wish-whep/
- LiveKit: https://livekit.io/
- LiveKit Agents docs: https://docs.livekit.io/agents/
- Daily.co: https://www.daily.co/
- Pipecat: https://www.pipecat.ai/
- Agora: https://www.agora.io/
- Twilio Programmable Video EOL: https://www.twilio.com/en-us/changelog/programmable-video-eol
- Pion: https://github.com/pion/webrtc
- WebRTC-rs: https://github.com/webrtc-rs/webrtc
- Mediasoup: https://mediasoup.org/
- Jitsi Meet: https://jitsi.org/
- Janus Gateway: https://janus.conf.meetecho.com/
- AWS IVS Real-Time: https://aws.amazon.com/ivs/
- Cloudflare Calls: https://developers.cloudflare.com/calls/
- OpenAI Realtime API: https://platform.openai.com/docs/guides/realtime
- Anthropic Voice: https://www.anthropic.com/
- Cartesia Sonic: https://cartesia.ai/
- ElevenLabs Conversational AI: https://elevenlabs.io/conversational-ai
- coturn: https://github.com/coturn/coturn
- Skyway (NTT): https://skyway.ntt.com/
- NHN TalkN: https://www.toast.com/service/realtime/talkn
- Naver Cloud Real-Time Comms: https://www.ncloud.com/product/media/rtc
현재 단락 (1/306)
2024년 12월 5일, Twilio가 Programmable Video를 공식 종료했다. 한때 WebRTC PaaS의 대명사였던 제품이 신규 가입을 막은 게 2024-03이었고,...