Skip to content
Published on

WebRTC & 실시간 통신 2026 완벽 가이드 — LiveKit · Daily · Agora · Twilio · Pion · Mediasoup · Jitsi · Janus · AWS IVS · Cloudflare Calls 심층 분석

🇰🇷KO🇺🇸EN🇯🇵JA
Split View필사 모드
Authors

프롤로그 — 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 중심이다.

import { Room, RoomEvent } from 'livekit-client'

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·전화망에서도 동작.

대표적인 한 줄 호출:

import DailyIframe from '@daily-co/daily-js'
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 모델이다.

import AgoraRTC from 'agora-rtc-sdk-ng'

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

Discuss on Twitter • View on GitHub