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

"라이브 커머스에 HLS면 충분한가요?", "스포츠 중계는 LL-HLS와 WebRTC 중 무엇을 써야 하나요?" 허용 지연은 첫 질문이지만 시청자 규모, 기기, 비용, 양방향성까지 함께 봐야 합니다.

이 글은 HLS / LL-HLS / WebRTC 세 프로토콜을 지연 분해, 내부 메커니즘, 비용·호환성 트레이드오프, 한국 시장 현실까지 비교해 의사결정 프레임을 제공합니다.

0. 핵심 명제 — 지연 예산으로 후보를 좁히고 운영 조건으로 검증한다

허용 지연으로 후보를 좁힌 뒤, 시청자 규모·상호작용·네트워크·기기·전송 비용으로 HLS, LL-HLS, WebRTC를 선택한다. 지연 숫자 하나가 프로토콜을 자동 결정하지는 않는다.

흔한 오해와 정정:

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

같은 "라이브"라도 지연 예산이 다르면 우선 검토할 프로토콜 후보가 달라집니다.

아래 수치는 구성 요소의 상대적 크기를 설명하기 위한 가상 예시이며 보장값이 아닙니다. 실제 서비스에서는 동일한 timecode를 송출 화면과 재생 화면에 표시해 glass-to-glass 지연을 측정합니다.

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

시청자 버퍼는 큰 비중을 차지할 수 있지만, 인코더·패키저·네트워크 상태에 따라 지배 구간이 달라집니다. 각 구간을 따로 계측합니다.

2. HLS — 세그먼트 배포와 지연의 트레이드오프

Apple이 공개한 HTTP 기반 라이브 스트리밍 프로토콜로, 여러 플랫폼과 플레이어에서 폭넓게 사용됩니다.

작동 원리

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

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

전통적인 HLS 구성은 완성된 세그먼트를 게시한 뒤 플레이어가 이를 가져갑니다. 세그먼트 길이와 live-edge 정책이 지연에 영향을 주며, part를 먼저 게시하는 LL-HLS는 다른 동작을 사용합니다.

지연 공식

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

예: 6초 세그먼트와 3개 세그먼트의 live-edge 거리를 선택하면
세그먼트·버퍼 항목만 약 18초다. 실제 값은 playlist와 플레이어 정책으로 측정한다.

왜 버퍼 3개인가

1. 네트워크 출렁임 대비 — 한 세그먼트 다운로드 실패해도 다음 두 개로 버팀
2. 재생 안정성 — 1개만 갖고 있으면 잠깐 끊겨도 멈춤
3. live-edge 정책 — 플레이어 시작점과 서버의 hold-back 설정이 안정성과 지연을 교환

구조

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

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

장점

• 폭넓은 플레이어·기기 지원
• 일반 HTTP 캐시 인프라 활용
• 대규모 배포에 CDN 캐시 활용 가능
• 성숙한 운영 도구와 생태계

단점

• 지연 큼 (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 핵심 메커니즘

현재 LL-HLS는 partial segment, blocking playlist reload, preload hint, delta update, rendition report와 server-control 속성을 조합합니다. 초기 제안에 있던 HTTP/2 Push 의존성은 현재 사양에 없습니다.

① Partial Segments (Parts)

세그먼트를 더 짧은 part로 나누고 EXT-X-PART로 표현합니다. part duration은 패키저 설정이며 Apple 문서는 200ms 예시를 제공합니다.

#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"

클라이언트는 다음 리소스 URI를 미리 알고 요청을 준비할 수 있습니다. preload hint만으로 리소스 전달이나 지연 목표가 보장되지는 않습니다.

④ 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"

byte range 사용 여부는 패키저·origin·CDN 캐시 동작을 함께 시험해 결정합니다.

LL-HLS 비용

표준 HLS 대비:

• playlist·part 요청과 origin 상태 관리 증가
• CDN 요금과 캐시 효율은 provider·요청 패턴에 따라 달라짐
• blocking reload, delta update, cache key를 이해하는 origin/CDN 구성이 필요

4. WebRTC — sub-second 목표와 다른 트레이드오프

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

작동 원리 차이

지연은 실측한다

WebRTC 지연은 capture timestamp가 시청자 화면에 나타나는 시각까지 측정합니다. 지역, SFU hop, TURN relay, packet loss, 재전송, jitter buffer, transcoding 여부를 결과와 함께 기록합니다. 특정 벤치마크 숫자를 제품 목표로 그대로 옮기지 않습니다.

WebRTC의 트레이드오프

• sub-second 지연 목표를 설계할 수 있음
• 시청자별 실시간 전송과 SFU egress 비용이 증가
• 일반 HLS 객체 캐시와 같은 방식으로 배포하지 않음
• 대상 브라우저·네트워크에서 selected candidate pair, relay 사용률, join 성공률을 측정
• TURN 서버, NAT 우회, ICE 상태를 운영해야 함

화상 회의·통화·상호작용이 중요한 방송에 잘 맞습니다. 대규모 one-to-many에서도 사용할 수 있지만, HLS 계열과 다른 capacity·비용 설계가 필요합니다.

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

6. CDN LL-HLS 지원 현황

LL-HLS는 단순히 .m3u8과 .m4s를 캐시하는 것보다 더 많은 동작이 필요합니다. CDN을 고를 때 현재 공식 문서와 실제 PoC로 다음을 확인합니다.

• blocking playlist reload 쿼리와 timeout 처리
• delta update·rendition report·preload hint 보존
• part와 byte-range의 cache key·TTL·origin shielding
• signed URL, 광고 삽입, multi-CDN 기능과의 호환성

제품 상태와 요금은 바뀌므로 특정 CDN의 GA/Beta 표를 고정하지 않습니다. 예를 들어 AWS는 MediaPackage의 LL-HLS 구성 문서를, Cloudflare는 Stream live input 문서를 각각 제공합니다.

7. YouTube 라이브 모드 비교

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

YouTube 공개 문서는 Low latency가 대다수 시청자에게 10초 미만, Ultra-low latency가 5초 미만이라고 설명합니다. 내부 전달 프로토콜은 이 수치만으로 추정하지 않습니다.

Ultra-low latency 모드 제약:

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

8. 시각적 타이밍 비교

아래는 구성 요소를 보여 주는 예시일 뿐, 보장 지연이 아닙니다. 실제 서비스에서는 화면에 timecode를 넣고 glass-to-glass로 측정합니다.

[발화 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. 유스케이스 → 프로토콜 의사결정

결정 트리

다음 분기는 지연 요구로 1차 후보를 좁히는 예시입니다. 최종 선택은 바로 아래 운영 조건과 PoC 결과까지 포함해 결정합니다.

[허용 지연이 얼마인가?]
        │
        ├── 수초~수십 초 허용, 대규모 캐시 배포 우선
        │       └─► 표준 HLS
        │           (강의 녹화, 일반 방송, VOD형)
        │
        ├── 수초대 목표, HTTP/CDN 배포 유지
        │       └─► LL-HLS
        │           (라이브 커머스, Q&A, 인터랙티브 방송)
        │
        └── sub-second 또는 양방향 상호작용
                └─► WebRTC
                    (화상 회의, 통화, 실시간 협업)

시나리오별 검토 후보

10. 한국 시장 현실

공개 근거 없이 국내 서비스의 내부 프로토콜을 추정하지 않습니다. 고객 미팅에서는 HAR·manifest·player 통계를 수집할 권한이 있는지 확인하고, 없으면 제품 요구사항만으로 새 파이프라인을 설계합니다. 지역 CDN PoP, 통신사별 RTT·손실, 한국에서 실제 쓰는 TV·모바일 기기 비중을 PoC 조건에 포함합니다.

11. SA 의사결정 프레임 — 7가지 인터뷰 질문

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

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

이 7가지 답으로 후보를 좁힌 뒤, 실제 사용자 지역·기기·동시 접속 조건의 PoC 결과로 결정합니다.

12. SA 체크리스트

프로토콜 선택 후 검증:

□ 1. 지연 측정 — 실제 E2E latency 측정해서 목표 충족 확인
□ 2. CDN 호환성 — 선택한 CDN이 LL-HLS 지원하는지 (GA vs Beta)
□ 3. 시청자 디바이스·플레이어별 LL-HLS/WebRTC 기능 확인
□ 4. ABR variant의 세그먼트·IDR·discontinuity 정렬 (#37, #38)
□ 5. 대상 ingest가 요구하는 rate-control·bitrate 설정 확인
□ 6. Closed GOP/CFR/scene-cut 정책과 실제 출력 검증 (#37)
□ 7. 시그널링 채널 별도 구축 (필요 시) — RTM/WebSocket
□ 8. SEI 메타데이터 활용 가능성 (#39)
□ 9. WebRTC 사용 시: TURN 서버, ICE 상태, NAT 우회 검증
□ 10. 부하 테스트 — 실 시청자 수 시뮬레이션

13. 한 줄 결론

허용 지연과 상호작용 요구로 후보를 좁히고, 시청자 규모·기기·네트워크·운영 비용을 PoC로 검증한다. LL-HLS는 part와 playlist 제어로 HTTP 배포의 live edge를 줄이고, WebRTC는 실시간 전송 대신 SFU·TURN capacity를 요구한다.

한 장 요약

┌─────────────────────────────────────────────────────────┐
│   허용 지연                                              │
│      │                                                   │
│      ├─ 수초~수십 초  →  표준 HLS                         │
│      │                  ├─ HTTP CDN 캐시 활용             │
│      │                  ├─ 폭넓은 플레이어 생태계          │
│      │                  └─ live-edge 정책 검증             │
│      │                                                   │
│      ├─ 수초대        →  LL-HLS                          │
│      │                  ├─ origin/CDN 기능 확인           │
│      │                  ├─ 플레이어 기능 확인              │
│      │                  ├─ Parts + Blocking + Preload    │
│      │                  └─ HTTP/2 Push 제거됨            │
│      │                                                   │
│      └─ sub-second/양방향 → WebRTC                       │
│                         ├─ P2P·SFU 토폴로지 선택        │
│                         ├─ 시청자 확장 제한              │
│                         └─ 네트워크·TURN 경로 검증       │
└─────────────────────────────────────────────────────────┘

관련 글

• 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) 옵션 공식 문서
• YouTube Help — Choose live stream latency — Normal/Low/Ultra-low latency의 공식 목표와 4K 제약