라이브 스트리밍 프로토콜 선택 — HLS / LL-HLS / WebRTC 의사결정
"라이브 커머스에 HLS면 충분할까, 스포츠 중계는 LL-HLS와 WebRTC 중 뭘 써야 할까?" 답은 늘 같습니다. 시청자에게 허용되는 지연 예산이 프로토콜을 자동으로 결정하기 때문입니다. 이 글은 HLS, LL-HLS, WebRTC 세 가지를 지연 분해와 내부 동작, 비용과 호환성, 한국 시장 현실까지 비교해 30초면 표준 HLS, 5초 이내면 LL-HLS, 1초 미만이면 WebRTC라는 의사결정 프레임을 정리합니다.
목차(31개 항목)
- 0. 핵심 명제 — 지연 예산이 프로토콜을 결정한다
- 1. 라이브 스트리밍 지연 분해
3. LL-HLS — 저지연 HLS
4. WebRTC — 1초 미만 (다른 트레이드오프)
- 5. 프로토콜 비교 매트릭스
- 6. CDN LL-HLS 지원 현황
- 7. YouTube 라이브 모드 비교
- 8. 시각적 타이밍 비교
- 10. 한국 시장 현실
- 11. SA 의사결정 프레임 — 7가지 인터뷰 질문
- 12. SA 체크리스트
13. 한 줄 결론
- 관련 글
- 참고 자료
"라이브 커머스 만드는데 HLS면 충분한가요?", "스포츠 중계는 LL-HLS를 써야 하나요, WebRTC를 써야 하나요?". 답은 항상 같습니다 — 시청자에게 허용 가능한 지연 예산이 얼마인가. 그 예산이 프로토콜을 자동으로 결정.
이 글은 HLS / LL-HLS / WebRTC 세 프로토콜을 지연 분해, 내부 메커니즘, 비용·호환성 트레이드오프, 한국 시장 현실까지 비교해 의사결정 프레임을 제공합니다.
0. 핵심 명제 — 지연 예산이 프로토콜을 결정한다
프로토콜 선택은 기술 취향이 아니라 비즈니스 요구사항(지연)이 자동 결정한다. 30초 OK면 표준 HLS, 5초 이내 필요하면 LL-HLS, 1초 미만 필요하면 WebRTC. 그 외 항목(비용/호환성/CDN 지원)은 모두 보조 변수.
흔한 오해와 정정:
| 오해 | 정확한 이해 |
|---|---|
| HLS는 옛날 거, LL-HLS가 좋음 | 둘은 다른 트레이드오프. HLS는 안정성/비용/호환성, LL-HLS는 지연 |
| LL-HLS = HTTP/2 Push | ❌ 2020년 스펙에서 제거됨. 현재는 Preload Hints가 대체 |
| WebRTC가 무조건 빠름 | 좋은 네트워크 조건 한정. 3G/고손실 환경에서는 300ms~1초+ |
| YouTube Ultra-low latency = LL-HLS | YouTube 내부 프로토콜은 비공개. "LL-HLS와 유사한 방식"으로만 묘사 |
1. 라이브 스트리밍 지연 분해
같은 "라이브"라도 지연 예산이 다르면 다른 프로토콜이 답.
지배적 변수: 보통 ⑥ 시청자 버퍼가 가장 큼. 프로토콜 차이의 핵심도 이 버퍼 크기.
| 프로토콜 | 지배 변수 | 일반 E2E |
|---|---|---|
| 표준 HLS | ⑥ 시청자 버퍼 (3 세그먼트) + ③ 패키징 대기 | 10~30초 |
| LL-HLS | ⑥를 part 단위로 잘게 + ③ 즉시 전달 | 2~5초 |
| WebRTC | ⑥ 버퍼 거의 없음 + ③ 패키징 없음 | 0.2~1초 |
2. HLS — 표준이지만 큰 지연
Apple이 2009년에 만든 라이브 스트리밍 프로토콜. 사실상 업계 표준.
작동 원리
전체 세그먼트가 인코딩 끝나야 시청자에게 배포 → 그게 곧 지연.
지연 공식
왜 버퍼 3개인가
- 네트워크 출렁임 대비 — 한 세그먼트 다운로드 실패해도 다음 두 개로 버팀
- 재생 안정성 — 1개만 갖고 있으면 잠깐 끊겨도 멈춤
- HLS RFC 8216bis HOLD-BACK 권장 — Target Duration의 최소 3배
구조
ABR ladder의 child playlist들이 master 아래에 묶임 → 시청자가 자기 네트워크 상태에 맞춰 화질 자동 전환 (#38).
장점
- 모든 디바이스 호환 (iOS/Android/Web/TV)
- 모든 CDN 지원 (단순 HTTP)
- 비용 가장 낮음
- 운영 안정성 검증됨
단점
- 지연 큼 (10~30초)
- 인터랙티브 라이브에 부적합
3. LL-HLS — 저지연 HLS
Apple이 2019년 WWDC에서 발표. 표준 HLS의 지연 문제를 해결하기 위한 확장.
핵심 아이디어
세그먼트가 완성되기 전에 더 작은 단위(part)로 쪼개서 즉시 전달.
LL-HLS 3+1 핵심 메커니즘
⚠️ 일부 자료에서 "HTTP/2 Push"를 LL-HLS의 4번째 메커니즘으로 소개하는데, 2020년 Apple이 LL-HLS 스펙에서 HTTP/2 Push 요구사항을 제거했습니다. CDN들이 HTTP/2 Push를 지원하지 않아 채택 장벽이었던 게 이유. Chrome도 2022년 HTTP/2 Push 지원 제거. 현재 핵심 메커니즘은 3가지 + Preload Hints.
① Partial Segments (Parts)
세그먼트를 200~500ms 단위로 쪼갬. EXT-X-PART 태그로 표현.
② Blocking Playlist Reload
시청자가 "다음 part 나오면 즉시 알려줘"라고 요청. HTTP long polling 방식.
_HLS_msn (media sequence number) + _HLS_part 쿼리 파라미터로 정확한 시점 지정.
③ Preload Hints
다음 올 part를 미리 알려줘서 시청자가 미리 요청 준비.
HTTP/2 Push의 대체 메커니즘. 시청자가 part4가 곧 올 거라는 걸 알고 있으니 connection을 미리 열어놓고 대기.
④ Byte Range Addressing (옵션)
작은 part 여러 개를 한 파일에 담고 byte range로 가리킴 → 파일 개수 폭증 방지.
CDN 캐시 효율성과 origin 부하 측면에서 권장. Akamai 등이 적극 사용.
LL-HLS 비용
표준 HLS 대비:
- 요청 빈도 ↑ (part 단위 = 약 6배)
- CDN 비용 ↑
- 서버 운영 복잡도 ↑ (HTTP/2 권장, 일부 CDN만 지원)
4. WebRTC — 1초 미만 (다른 트레이드오프)
브라우저/모바일에서 직접 P2P 또는 SFU 통해 미디어를 주고받는 프로토콜.
작동 원리 차이
| 항목 | HLS 계열 | WebRTC |
|---|---|---|
| 전송 단위 | 파일(세그먼트/part) | 패킷(RTP) |
| 프로토콜 | HTTP over TCP | RTP over UDP (SRTP 암호화) |
| 패키징 단계 | 필요 (HLS 컨테이너) | 없음 (raw RTP) |
| 시청자 버퍼 | 1초~수초 | 50~100ms (jitter buffer) |
| 신뢰성 | TCP 재전송 | NACK/PLI/RPSI 선택적 |
| 적응 | ABR ladder | RTP 자체 비트레이트 적응 |
실측 지연 (현실적인 범위)
| 시나리오 | 지연 | 출처 |
|---|---|---|
| 같은 도시 SFU passthrough | 100~200ms | 일반적 |
| 1628km 거리 passthrough | 178~240ms | Ceeblue 벤치마크 |
| 트랜스코딩 포함 | 284~300ms | Ceeblue 벤치마크 |
| 좋은 네트워크 SFU | 200~500ms | 프로덕션 평균 |
| 고손실 네트워크/3G | 300~1000ms+ | 변동 큼 |
뉘앙스: WebRTC가 "0.2초"라고 단정하지 말 것. 좋은 네트워크 + SFU 기반 + 짧은 거리 한정. 글로벌 분산 시청자나 모바일 셀룰러는 더 큼.
WebRTC의 트레이드오프
- ✅ 압도적인 저지연
- ❌ 시청자 수 확장 어려움 (SFU 비용 ↑)
- ❌ CDN 캐시 불가능 — 매 시청자마다 별도 stream
- ❌ 일부 모바일/구형 브라우저 호환성 이슈
- ❌ 운영 복잡도 ↑ (TURN 서버, NAT 우회, ICE)
대규모 라이브 방송에는 부적합. 화상 회의/통화/소규모 인터랙티브 라이브에 적합.
5. 프로토콜 비교 매트릭스
| 항목 | 표준 HLS | LL-HLS | WebRTC |
|---|---|---|---|
| 지연 | 10~30초 | 2~5초 | 0.2~1초 (조건부) |
| 세그먼트 길이 | 2~6초 | 1 | N/A (RTP 패킷) |
| 시청자 버퍼 | 3 세그먼트 | Part 단위 | 50~100ms |
| 키프레임 정렬 | 세그먼트와 정렬 | Part와 정렬 (더 짧음) | I-frame 강제 |
| 서버 요구사항 | 일반 HTTP | HTTP/2 권장 | SFU + TURN + STUN |
| 시청자 확장성 | 무한 (CDN 캐시) | 무한 (CDN 캐시) | 제한적 (SFU 비용) |
| 비용 | 낮음 | 중간 (요청 빈도 ↑) | 높음 (SFU per-viewer) |
| 호환성 | 모든 디바이스 | iOS 14+, Android 신버전 | 모든 모던 브라우저 |
| ABR | ✅ Master playlist | ✅ Master playlist | △ 자체 비트레이트 적응 |
| 운영 복잡도 | 낮음 | 중간 | 높음 |
6. CDN LL-HLS 지원 현황
LL-HLS는 모든 CDN이 지원하지 않습니다. 도입 시 CDN 선택 자체가 제약 조건.
| CDN | 상태 | 비고 |
|---|---|---|
| Akamai | ✅ GA | Adaptive Media Delivery, byte range addressing 권장, 3초 이하 목표 |
| AWS CloudFront | ✅ GA | MediaLive → MediaPackage(LL-HLS 패키징) → CloudFront, 2023년 5월부터 |
| Fastly | ✅ GA | Wowza + THEOplayer 공동 솔루션, HTTP/3·QUIC 지원 |
| Cloudflare | ⚠️ Open Beta | Cloudflare Stream 한정, ?protocol=llhls 플래그, 2025년 현재 GA 미확인 |
| 그 외 (자체 CDN, 일부 KR CDN) | ❌ 미지원 다수 | 도입 전 사전 확인 필수 |
실무 팁: Cloudflare Stream에 의존하는 경우 GA 전까지 프로덕션 배포 신중. 다른 옵션으로 AWS CloudFront 또는 Akamai 권장.
7. YouTube 라이브 모드 비교
YouTube는 라이브 송출 시 3가지 모드를 제공합니다.
| 모드 | 공식 지연 목표 | 일반 측정 |
|---|---|---|
| Normal | 명시 없음 | 20~30초 |
| Low Latency | 10초 미만 | 5~10초 |
| Ultra-low Latency | 5초 미만 | 2~5초 |
주의: YouTube는 Ultra-low latency의 내부 프로토콜을 공개하지 않습니다. "LL-HLS와 유사한 방식"이라고 묘사하는 자료가 있으나 YouTube 공식 문서로 확인되지 않음. YouTube 자체 DASH 변형 또는 커스텀 프로토콜일 가능성 [NEEDS VERIFICATION].
Ultra-low latency 모드 제약:
- 4K 미지원
- 버퍼링 가능성 증가
- 일부 인코더/플레이어 호환성 이슈
8. 시각적 타이밍 비교
발화자가 "안녕하세요"라고 말한 시점부터 시청자가 듣는 시점까지:
9. 유스케이스 → 프로토콜 의사결정
결정 트리
시나리오별 권장
| 시나리오 | 프로토콜 | 이유 |
|---|---|---|
| 일반 방송 / 강의 / VOD형 라이브 | 표준 HLS | 비용 낮음, 안정성, 호환성 |
| 라이브 커머스 (채팅 동기 중요) | LL-HLS | 시청자 채팅과 발화 간격이 짧아야 |
| 스포츠 / 게임 / 경매 | LL-HLS 또는 LL-DASH | "베팅 마감 직전 골" 시나리오 |
| 화상 회의 / 통화 | WebRTC (Agora RTC) | 1초도 길음 |
| 1:N 인터랙티브 라이브 | LL-HLS + WebRTC 보조 채널 | 시청자는 LL-HLS, 호스트는 WebRTC |
10. 한국 시장 현실
[NEEDS VERIFICATION] 아래 한국 플랫폼의 프로토콜 사용 현황은 공개적으로 확인하기 어렵습니다. 일반적인 업계 인식을 바탕으로 정리.
| 플랫폼 | 일반적 인식 |
|---|---|
| 쿠팡 라이브 | 표준 HLS 기반으로 추정 (지연 10~20초 관찰) |
| 네이버 쇼핑라이브 | 표준 HLS 기반으로 추정 |
| 카카오TV | 표준 HLS |
| 글로벌 OTT (YouTube, Twitch) | 표준 HLS + 저지연 옵션 |
| 스포츠 중계 (TV → IPTV) | 표준 HLS, 일부 LL-HLS 도입 시도 |
한국 시장 트렌드:
- LL-HLS 도입은 글로벌 대비 보수적
- 라이브 커머스 분야가 가장 적극적인 LL-HLS 후보 (시청자 결제 직결 → 지연 손실 명확)
- WebRTC는 화상 회의(라인웍스, 줌, 구루미 등) 외에는 라이브 송출 도입 사례 적음
11. SA 의사결정 프레임 — 7가지 인터뷰 질문
라이브 프로젝트 미팅에서 던지는 질문 순서:
이 7가지 답을 채우면 자연스럽게 프로토콜이 결정됩니다.
12. SA 체크리스트
13. 한 줄 결론
프로토콜 선택은 "허용 지연 → CDN 호환성 → 비용"의 3단계 의사결정. HLS는 30초+ 일반 방송, LL-HLS는 2~5초 인터랙티브, WebRTC는 1초 미만 통화. HTTP/2 Push는 LL-HLS 스펙에서 2020년 제거됐으며 현재는 Preload Hints가 대체.
한 장 요약
관련 글
- GOP-세그먼트 정렬의 산수 — Layer A 시간축 정렬
- ABR Ladder의 Layer B 정렬 — 화질 전환 시 키프레임 동기화
- Agora SEI 메타데이터 — 비디오 동기 메타데이터
- WebRTC란? ICE? STUN? NAT? TURN? — WebRTC 기초
- 왜 P2P가 막히는가? — NAT, STUN, TURN
- Agora의 기업 방화벽 우회 전략 — Cloud Proxy — UDP/TCP 정책
- M3U8과 TS 파일의 모든 것 — HLS Deep Dive — HLS 컨테이너 구조
- TTFB 분해 — 다른 종류의 지연 합산값
- 라이브 스트리밍 송출 파이프라인 — 송출 측에서 본 인코딩/세그먼팅 파이프라인
참고 자료
- RFC 8216bis — HTTP Live Streaming 2nd Edition (draft) —
EXT-X-PART,EXT-X-PRELOAD-HINT,EXT-X-SERVER-CONTROL(HOLD-BACK/PART-HOLD-BACK), Blocking Playlist Reload 등 LL-HLS 태그의 1차 규격 - RFC 8216 — HTTP Live Streaming — 표준 HLS 플레이리스트/세그먼트 구조의 원본 RFC
- Apple — Enabling Low-Latency HLS — Parts/Preload Hints/Blocking Reload 등 LL-HLS 구현 가이드(2020년 HTTP/2 Push 제거 반영)
- WebRTC W3C Recommendation — RTCPeerConnection, SRTP 전송, jitter buffer 등 WebRTC 브라우저 API 표준
- AWS — Low-latency HLS on AWS Elemental MediaPackage — MediaLive→MediaPackage→CloudFront LL-HLS 패키징/배포 공식 문서
- Cloudflare Stream — Live latency / LL-HLS — Stream 라이브 저지연(LL-HLS) 옵션 공식 문서