06 — Streaming

이 챕터가 답하는 질문: 비디오를 끊김 없이 보내려면 무엇이 필요한가? 레이어: ⑤ 변환 (Transformation) — 03-media-video가 만든 인코딩 결과를 어떻게 전달할지의 문제 작성: 2026-05-10

한 문장 답 (Pyramid Top)

스트리밍은 **“하나의 비디오를 N개의 작은 조각(segment)으로 자르고, 그 조각들의 목록(manifest)을 플레이어가 매 순간 골라 받게 만드는 일”**이다. 이 한 문장 안에 ABR·HLS·DASH·CMAF·LL·DRM이 모두 들어 있다 — 무엇을 자르고, 어떻게 목록을 표현하고, 누가 키를 쥐는가.

Why — 왜 별도 챕터인가

03-media-video까지의 결정(코덱·해상도·HDR)이 끝나도, 비디오 한 편을 인터넷으로 매끄럽게 전달하는 문제는 따로 풀어야 한다. 이유는 셋이다:

1. 네트워크는 변동한다 — Wi-Fi 80Mbps에서 LTE 2Mbps로 떨어지는 순간 1080p는 멈춘다. 그래서 ABR(Adaptive Bitrate).
2. 디바이스는 다양하다 — iOS Safari는 HLS만 native 재생, Chrome은 MSE(DASH도 가능). 그래서 HLS·DASH·CMAF의 3중 표준.
3. 콘텐츠는 보호받아야 한다 — 4K HDR 원본을 그대로 흘릴 수는 없다. 그래서 DRM.

이 세 가지가 한 챕터로 묶이는 이유: 하나라도 빠지면 나머지가 무의미하다. ABR 없는 HLS는 모바일에서 끊기고, DRM 없는 CMAF는 콘텐츠가 새고, 매니페스트 없는 ABR은 그냥 이론이다.

How — 9개 파일로 어떻게 분해했나

What — 한 장 비교 (HLS vs DASH vs CMAF vs WebRTC)

이 표 한 줄씩이 다음 8개 파일의 한 단원으로 풀린다.

What-if — 잘못 잡으면 어떻게 깨지는가

Insight — 흥미로운 한 줄

**“HLS는 Apple이 2009년에 단지 iPhone 3GS의 Wi-Fi/3G 전환 끊김을 풀려고 만든 것”**이고, 그게 지금 전 세계 OTT의 기본 표준이 되었다. **“DASH는 그것이 너무 Apple-specific 해 보여서 MPEG가 ISO 표준으로 다시 만든 것”**이다. **“CMAF는 그 둘이 사실은 같은 fMP4를 쓸 수 있다는 것”**을 확인한 합의다. 표준의 역사는 항상 (a) 한 회사가 먼저 만들고 → (b) 표준화 기구가 따라잡고 → (c) 둘이 합쳐지는 패턴이다.

한 단락 요약

**스트리밍은 “비디오를 잘라 목록으로 만든 뒤 플레이어가 그 목록에서 매 순간 적절한 조각을 고르게 하는 시스템”**이다. ABR은 어떻게 고르는가, HLS/DASH/CMAF는 목록을 어떻게 표현하는가, DRM은 누가 풀어주는가, 플레이어 엔진은 그 목록을 어떻게 해석하는가를 다룬다. 이 챕터의 9개 파일은 같은 문제를 8개 단면으로 본다.