블로그 목록
Media25분 읽기

라이브 스트리밍 프로토콜 선택 — HLS / LL-HLS / WebRTC 의사결정

"라이브 커머스에 HLS면 충분할까, 스포츠 중계는 LL-HLS와 WebRTC 중 뭘 써야 할까?" 답은 늘 같습니다. 시청자에게 허용되는 지연 예산이 프로토콜을 자동으로 결정하기 때문입니다. 이 글은 HLS, LL-HLS, WebRTC 세 가지를 지연 분해와 내부 동작, 비용과 호환성, 한국 시장 현실까지 비교해 30초면 표준 HLS, 5초 이내면 LL-HLS, 1초 미만이면 WebRTC라는 의사결정 프레임을 정리합니다.

HLSLL-HLSWebRTC프로토콜 선택라이브 스트리밍지연CDNAkamaiCloudflareAWS CloudFrontFastly

"라이브 커머스 만드는데 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-HLSYouTube 내부 프로토콜은 비공개. "LL-HLS와 유사한 방식"으로만 묘사

1. 라이브 스트리밍 지연 분해

같은 "라이브"라도 지연 예산이 다르면 다른 프로토콜이 답.

[발화자 t=0]                                          [시청자 t=?]
   │                                                       │
   ├─ ① 캡처/인코딩 ──────────► 50~500ms                    │
   ├─ ② 네트워크 (인코더→서버) ─► 50~200ms                   │
   ├─ ③ 서버 처리 (트랜스코딩/패키징) ► 100ms~수초            │
   ├─ ④ CDN 전파 ──────────────► 100ms~수초                 │
   ├─ ⑤ 시청자 다운로드 ─────────► 수백ms                    │
   ├─ ⑥ 시청자 버퍼 ─────────────► 1~10초+                  │
   └─ ⑦ 디코딩/재생 ──────────────► 50~100ms                │
                                                            │
                              총 합산 = E2E 지연

지배적 변수: 보통 ⑥ 시청자 버퍼가 가장 큼. 프로토콜 차이의 핵심도 이 버퍼 크기.

프로토콜지배 변수일반 E2E
표준 HLS⑥ 시청자 버퍼 (3 세그먼트) + ③ 패키징 대기10~30초
LL-HLS⑥를 part 단위로 잘게 + ③ 즉시 전달2~5초
WebRTC⑥ 버퍼 거의 없음 + ③ 패키징 없음0.2~1초

2. HLS — 표준이지만 큰 지연

Apple이 2009년에 만든 라이브 스트리밍 프로토콜. 사실상 업계 표준.

작동 원리

인코더 측:
  seg1.ts (인코딩 끝남, 2초)
  seg2.ts (인코딩 끝남, 2초)
  seg3.ts (인코딩 중...)

시청자 측:
  플레이리스트 다운로드 → seg1.ts → 재생 시작
                       → seg2.ts → 이어서 재생
                       → seg3.ts → ...

전체 세그먼트가 인코딩 끝나야 시청자에게 배포 → 그게 곧 지연.

지연 공식

이론적 지연 ≈ 세그먼트 길이 × 시청자 버퍼 개수 + 네트워크 지연

YouTube 일반 라이브:
- 세그먼트 길이: 2초
- 시청자 버퍼: 3개 (HLS 표준 권장)
- → 최소 6초 지연
- 추가로 인코딩 + CDN 전파 + 디코딩
- → 총 10~20초 (실제)

왜 버퍼 3개인가

  1. 네트워크 출렁임 대비 — 한 세그먼트 다운로드 실패해도 다음 두 개로 버팀
  2. 재생 안정성 — 1개만 갖고 있으면 잠깐 끊겨도 멈춤
  3. HLS RFC 8216bis HOLD-BACK 권장 — Target Duration의 최소 3배

구조

master.m3u8
├── 1080p.m3u8 (child playlist)
│   ├── seg1_1080.ts
│   ├── seg2_1080.ts
│   └── ...
├── 720p.m3u8
└── 480p.m3u8

ABR ladder의 child playlist들이 master 아래에 묶임 → 시청자가 자기 네트워크 상태에 맞춰 화질 자동 전환 (#38).

장점

  • 모든 디바이스 호환 (iOS/Android/Web/TV)
  • 모든 CDN 지원 (단순 HTTP)
  • 비용 가장 낮음
  • 운영 안정성 검증됨

단점

  • 지연 큼 (10~30초)
  • 인터랙티브 라이브에 부적합

3. LL-HLS — 저지연 HLS

Apple이 2019년 WWDC에서 발표. 표준 HLS의 지연 문제를 해결하기 위한 확장.

핵심 아이디어

세그먼트가 완성되기 전에 더 작은 단위(part)로 쪼개서 즉시 전달.

표준 HLS 세그먼트:
[━━━━━━━━━━━━━ seg1.ts (2초) ━━━━━━━━━━━━━]
↑ 인코딩 완료까지 시청자에게 안 보냄

LL-HLS 세그먼트:
[part1][part2][part3][part4][part5][part6][part7][part8][part9][part10]
 0.2s   0.4s   0.6s   0.8s   1.0s   1.2s   1.4s   1.6s   1.8s   2.0s
↑ 각 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 태그로 표현.

#EXT-X-PART-INF:PART-TARGET=0.33334
...
#EXT-X-PART:DURATION=0.33334,URI="part1.mp4"
#EXT-X-PART:DURATION=0.33334,URI="part2.mp4"
#EXT-X-PART:DURATION=0.33334,URI="part3.mp4"
#EXTINF:1.0,
seg1.m4s   ← 위 3개 part가 합쳐진 것

② Blocking Playlist Reload

시청자가 "다음 part 나오면 즉시 알려줘"라고 요청. HTTP long polling 방식.

GET playlist.m3u8?_HLS_msn=42&_HLS_part=3
                              ↑          ↑
                        시청자가 이 시점의 part 기다림

서버: 그 part가 준비될 때까지 응답 보류 (long polling)
서버: part 준비됨 → 즉시 응답

_HLS_msn (media sequence number) + _HLS_part 쿼리 파라미터로 정확한 시점 지정.

③ Preload Hints

다음 올 part를 미리 알려줘서 시청자가 미리 요청 준비.

#EXT-X-PRELOAD-HINT:TYPE=PART,URI="part4.mp4"
#EXT-X-PRELOAD-HINT:TYPE=MAP,URI="init.mp4"

HTTP/2 Push의 대체 메커니즘. 시청자가 part4가 곧 올 거라는 걸 알고 있으니 connection을 미리 열어놓고 대기.

④ Byte Range Addressing (옵션)

작은 part 여러 개를 한 파일에 담고 byte range로 가리킴 → 파일 개수 폭증 방지.

#EXT-X-PART:DURATION=0.33334,URI="seg1.m4s",BYTERANGE="50000@0"
#EXT-X-PART:DURATION=0.33334,URI="seg1.m4s",BYTERANGE="50000@50000"
#EXT-X-PART:DURATION=0.33334,URI="seg1.m4s",BYTERANGE="50000@100000"

CDN 캐시 효율성과 origin 부하 측면에서 권장. Akamai 등이 적극 사용.

LL-HLS 비용

표준 HLS 대비:

  • 요청 빈도 ↑ (part 단위 = 약 6배)
  • CDN 비용 ↑
  • 서버 운영 복잡도 ↑ (HTTP/2 권장, 일부 CDN만 지원)

4. WebRTC — 1초 미만 (다른 트레이드오프)

브라우저/모바일에서 직접 P2P 또는 SFU 통해 미디어를 주고받는 프로토콜.

작동 원리 차이

항목HLS 계열WebRTC
전송 단위파일(세그먼트/part)패킷(RTP)
프로토콜HTTP over TCPRTP over UDP (SRTP 암호화)
패키징 단계필요 (HLS 컨테이너)없음 (raw RTP)
시청자 버퍼1초~수초50~100ms (jitter buffer)
신뢰성TCP 재전송NACK/PLI/RPSI 선택적
적응ABR ladderRTP 자체 비트레이트 적응

실측 지연 (현실적인 범위)

시나리오지연출처
같은 도시 SFU passthrough100~200ms일반적
1628km 거리 passthrough178~240msCeeblue 벤치마크
트랜스코딩 포함284~300msCeeblue 벤치마크
좋은 네트워크 SFU200~500ms프로덕션 평균
고손실 네트워크/3G300~1000ms+변동 큼

뉘앙스: WebRTC가 "0.2초"라고 단정하지 말 것. 좋은 네트워크 + SFU 기반 + 짧은 거리 한정. 글로벌 분산 시청자나 모바일 셀룰러는 더 큼.

WebRTC의 트레이드오프

  • ✅ 압도적인 저지연
  • ❌ 시청자 수 확장 어려움 (SFU 비용 ↑)
  • ❌ CDN 캐시 불가능 — 매 시청자마다 별도 stream
  • ❌ 일부 모바일/구형 브라우저 호환성 이슈
  • ❌ 운영 복잡도 ↑ (TURN 서버, NAT 우회, ICE)

대규모 라이브 방송에는 부적합. 화상 회의/통화/소규모 인터랙티브 라이브에 적합.


5. 프로토콜 비교 매트릭스

항목표준 HLSLL-HLSWebRTC
지연10~30초2~5초0.2~1초 (조건부)
세그먼트 길이2~6초12초 (+ part 200500ms)N/A (RTP 패킷)
시청자 버퍼3 세그먼트Part 단위50~100ms
키프레임 정렬세그먼트와 정렬Part와 정렬 (더 짧음)I-frame 강제
서버 요구사항일반 HTTPHTTP/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✅ GAAdaptive Media Delivery, byte range addressing 권장, 3초 이하 목표
AWS CloudFront✅ GAMediaLive → MediaPackage(LL-HLS 패키징) → CloudFront, 2023년 5월부터
Fastly✅ GAWowza + THEOplayer 공동 솔루션, HTTP/3·QUIC 지원
Cloudflare⚠️ Open BetaCloudflare Stream 한정, ?protocol=llhls 플래그, 2025년 현재 GA 미확인
그 외 (자체 CDN, 일부 KR CDN)❌ 미지원 다수도입 전 사전 확인 필수

실무 팁: Cloudflare Stream에 의존하는 경우 GA 전까지 프로덕션 배포 신중. 다른 옵션으로 AWS CloudFront 또는 Akamai 권장.


7. YouTube 라이브 모드 비교

YouTube는 라이브 송출 시 3가지 모드를 제공합니다.

모드공식 지연 목표일반 측정
Normal명시 없음20~30초
Low Latency10초 미만5~10초
Ultra-low Latency5초 미만2~5초

주의: YouTube는 Ultra-low latency의 내부 프로토콜을 공개하지 않습니다. "LL-HLS와 유사한 방식"이라고 묘사하는 자료가 있으나 YouTube 공식 문서로 확인되지 않음. YouTube 자체 DASH 변형 또는 커스텀 프로토콜일 가능성 [NEEDS VERIFICATION].

Ultra-low latency 모드 제약:

  • 4K 미지원
  • 버퍼링 가능성 증가
  • 일부 인코더/플레이어 호환성 이슈

8. 시각적 타이밍 비교

발화자가 "안녕하세요"라고 말한 시점부터 시청자가 듣는 시점까지:

[발화 t=0]
   │
   ▼ 시간 ────────────────────────────────────────────►

표준 HLS (2초 세그먼트):
   [인코딩 0.5s][세그먼트 빌드 2s][CDN 전파 1s][시청자 버퍼 4s]
   ↓
   시청자가 듣는 시점: 약 7~8초 후

LL-HLS:
   [인코딩 0.5s][Part 빌드 0.3s][즉시 전달 0.5s][최소 버퍼 1s]
   ↓
   시청자가 듣는 시점: 약 2~3초 후

WebRTC (좋은 네트워크):
   [인코딩 50ms][전송 100ms][디코딩 50ms]
   ↓
   시청자가 듣는 시점: 약 200~500ms 후

9. 유스케이스 → 프로토콜 의사결정

결정 트리

[허용 지연이 얼마인가?]
        │
        ├── 30초 이상 OK
        │       └─► 표준 HLS
        │           (강의 녹화, 일반 방송, VOD형)
        │
        ├── 5~10초
        │       └─► LL-HLS
        │           (라이브 커머스, Q&A, 인터랙티브 방송)
        │
        ├── 2~5초
        │       ├── 시청자 ~수만 명
        │       │       └─► LL-HLS (Akamai/AWS/Fastly)
        │       │           (스포츠, 게임, 경매)
        │       │
        │       └── 시청자 ~수백 명
        │               └─► WebRTC SFU
        │
        └── 1초 미만
                └─► WebRTC
                    (화상 회의, 통화, 실시간 협업)

시나리오별 권장

시나리오프로토콜이유
일반 방송 / 강의 / 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가지 인터뷰 질문

라이브 프로젝트 미팅에서 던지는 질문 순서:

1. "허용 지연은 얼마예요?"             → 프로토콜 1차 분기
2. "동시 시청자 규모는?"                → CDN/SFU 선택
3. "송출 대상 디바이스는?"              → 호환성 제약
4. "예산 규모는?"                       → 비용 트레이드오프
5. "이미 사용 중인 CDN이 있나요?"       → LL-HLS 지원 여부
6. "ABR ladder가 필요한가요?"          → HLS 계열 vs WebRTC
7. "인터랙티브 요소(채팅/투표 등) 있나요?" → 시그널링 채널 필요성

이 7가지 답을 채우면 자연스럽게 프로토콜이 결정됩니다.


12. SA 체크리스트

프로토콜 선택 후 검증:

□ 1. 지연 측정 — 실제 E2E latency 측정해서 목표 충족 확인
□ 2. CDN 호환성 — 선택한 CDN이 LL-HLS 지원하는지 (GA vs Beta)
□ 3. 시청자 디바이스 호환성 — iOS 13/14 분기 확인
□ 4. ABR ladder 정렬 — Layer A + Layer B (#37, #38)
□ 5. CBR 모드 — 라이브는 CBR (#37 Rate Control)
□ 6. Closed GOP + Scene-cut OFF + CFR (#37)
□ 7. 시그널링 채널 별도 구축 (필요 시) — RTM/WebSocket
□ 8. SEI 메타데이터 활용 가능성 (#39)
□ 9. WebRTC 사용 시: TURN 서버, ICE 상태, NAT 우회 검증
□ 10. 부하 테스트 — 실 시청자 수 시뮬레이션

13. 한 줄 결론

프로토콜 선택은 "허용 지연 → CDN 호환성 → 비용"의 3단계 의사결정. HLS는 30초+ 일반 방송, LL-HLS는 2~5초 인터랙티브, WebRTC는 1초 미만 통화. HTTP/2 Push는 LL-HLS 스펙에서 2020년 제거됐으며 현재는 Preload Hints가 대체.

한 장 요약

┌─────────────────────────────────────────────────────────┐
│   허용 지연                                              │
│      │                                                   │
│      ├─ 30초+        →  표준 HLS                         │
│      │                  ├─ 모든 CDN                      │
│      │                  ├─ 모든 디바이스                  │
│      │                  └─ 비용 ↓                        │
│      │                                                   │
│      ├─ 2~10초       →  LL-HLS                          │
│      │                  ├─ Akamai/AWS/Fastly GA          │
│      │                  ├─ Cloudflare Beta              │
│      │                  ├─ Parts + Blocking + Preload    │
│      │                  └─ HTTP/2 Push 제거됨            │
│      │                                                   │
│      └─ 1초 미만     →  WebRTC                          │
│                         ├─ SFU 기반                      │
│                         ├─ 시청자 확장 제한              │
│                         └─ 좋은 네트워크 한정            │
└─────────────────────────────────────────────────────────┘

관련 글

참고 자료

© 2026 Frank Kim. All rights reserved.