블로그 목록
Media18분 읽기

HLS vs DASH — 매니페스트·세그먼트·DRM·저지연, 그리고 CMAF가 둘을 합친 방법

iOS 앱과 웹, 스마트TV를 한 서비스에서 다 지원해야 할 때 HLS와 DASH 중 무엇을 골라야 할까요? 사실 양자택일 문제가 아닙니다. 둘은 영상을 짧은 조각으로 잘라 HTTP로 배달한다는 본질이 같고, 매니페스트 문법과 세그먼트 포맷, DRM 생태계만 다릅니다. 이 글은 .m3u8과 .mpd, MPEG-TS와 fMP4, FairPlay와 Widevine, 그리고 LL-HLS와 LL-DASH의 저지연 방식을 비교하고, 세그먼트 한 벌로 양쪽을 동시에 서비스하는 CMAF까지 정리합니다. 흔히 LL-HLS의 핵심으로 알려진 HTTP/2 Push가 사실 2020년 스펙에서 빠졌다는 점도 바로잡습니다.

HLSDASHCMAFfMP4MPEG-TSm3u8MPDLL-HLSLL-DASHDRMFairPlayWidevine
목차(20개 항목)
  1. 0. 핵심 명제 — 표준 전쟁이 아니라 분업, 그리고 CMAF로 수렴
  2. 1. 한눈 비교 매트릭스
  3. 2. 매니페스트 — .m3u8(텍스트) vs .mpd(XML)
    1. HLS — 마스터 + 미디어 2단 구조
    2. DASH — MPD 한 파일에 전체 구조
  4. 3. 세그먼트 — MPEG-TS(.ts) vs fMP4/CMAF(.m4s)
    1. 전통 HLS: MPEG-TS
    2. fMP4 / CMAF (.m4s)
  5. 4. ABR 동작 — 화질/오디오 전환 방식의 차이
  6. 5. DRM — FairPlay vs Widevine/PlayReady, 그리고 CENC
  7. 6. 저지연 — LL-HLS vs LL-DASH (HTTP/2 Push 정정 포함)
    1. LL-HLS (Apple, 2019 — RFC 8216bis에 통합)
    2. LL-DASH
  8. 7. CMAF — 하나의 fMP4로 HLS·DASH 둘 다
  9. 8. 플랫폼 지원 — 결국 Apple이 변수다
  10. 9. 실무 선택 가이드
  11. 10. 한 장 요약 — 암기 카드
  12. 11. 한 줄 결론
  13. 관련 글
  14. 참고 자료

"iOS 앱이랑 웹, 스마트TV까지 다 지원해야 하는데 HLS로 깔까요 DASH로 깔까요?" 라이브든 VOD든 스트리밍 아키텍처를 잡을 때 가장 먼저 막히는 질문입니다. 답부터 말하면 — 둘 중 하나를 고르는 문제가 아니라, 어느 쪽을 메인으로 두고 한 벌의 세그먼트로 둘 다 서비스하느냐의 문제입니다(그 답이 바로 CMAF).

이 글은 HLS와 DASH를 매니페스트·세그먼트·ABR·DRM·저지연 다섯 축으로 비교하고, 둘을 하나로 합친 CMAF, 그리고 실무 선택 기준까지 정리합니다. (라이브 송출 파이프라인 자체는 #49에서 다뤘으니, 여기선 "패키징 산출물" 관점에 집중합니다.)

0. 핵심 명제 — 표준 전쟁이 아니라 분업, 그리고 CMAF로 수렴

HLS(Apple)와 DASH(MPEG/ISO 국제표준)는 "영상을 짧은 조각으로 잘라 HTTP로 배달한다"는 본질이 같다. 차이는 매니페스트 문법(.m3u8 텍스트 vs .mpd XML), 전통적 세그먼트 포맷(MPEG-TS vs fMP4), DRM 생태계(FairPlay vs Widevine/PlayReady)다. 그런데 둘 다 fMP4 세그먼트를 쓸 수 있게 되면서, CMAF로 "세그먼트는 한 벌, 매니페스트만 둘"이 가능해졌다. 그래서 현대 OTT의 정답은 "HLS냐 DASH냐"가 아니라 "CMAF 세그먼트 + 양쪽 매니페스트"다.

먼저 흔한 오해와 정정:

흔한 오해정확한 이해
HLS는 .ts, DASH는 .m4s로 포맷이 다르다⚠️ HLS도 fMP4(.m4s)를 지원(2016, HLS v7~). 그래서 CMAF로 공유 가능
DASH가 더 최신이라 더 좋다❌ 우열이 아니라 생태계 문제. Apple 기기는 HLS만 네이티브
HLS는 A/V를 항상 묶어 보낸다⚠️ 전통 TS는 muxed지만, fMP4·EXT-X-MEDIA로 오디오/자막 분리 가능
LL-HLS는 HTTP/2 Push로 저지연을 낸다❌ 정정: Push는 초기 초안에만 있었고 2020년 스펙에서 제거. 지금은 Preload Hint + Blocking Reload
CMAF만 쓰면 DRM도 한 번에 통일된다⚠️ 세그먼트는 한 벌이지만, 암호화 모드(cbcs) 통일이 전제. 과거 cenc(ctr) vs cbcs 분기가 걸림돌이었음

1. 한눈 비교 매트릭스

항목HLSDASH
개발/표준Apple(사실상 표준, RFC 8216)MPEG / ISO·IEC 23009-1(국제 공식 표준)
매니페스트.m3u8 (텍스트).mpd (XML)
전통 세그먼트MPEG-TS .tsfMP4 .m4s
현대 세그먼트fMP4/CMAF .m4s(v7+)fMP4/CMAF .m4s
A/V 구성전통은 muxed, fMP4는 분리 가능AdaptationSet으로 비디오/오디오/자막 분리
Apple 기기✅ 네이티브❌ 별도 플레이어(MSE) 필요
DRMFairPlay(+ SAMPLE-AES/AES-128)CENC → Widevine·PlayReady·ClearKey
코덱H.264/H.265 중심(AV1도 가능)코덱 자유(AV1·VP9 등)
대표 사용처Apple 생태계, 범용 OTTYouTube·Netflix류

핵심 패턴: 본질(조각+HTTP 배달)은 같고, 문법·포맷·DRM 생태계가 다르다. 그 차이를 하나씩 봅니다.

2. 매니페스트 — .m3u8(텍스트) vs .mpd(XML)

가장 눈에 띄는 차이입니다. HLS는 한 줄씩 읽는 텍스트, DASH는 트리 구조의 XML입니다.

HLS — 마스터 + 미디어 2단 구조

# master.m3u8 (마스터 플레이리스트)
#EXTM3U
#EXT-X-VERSION:6
#EXT-X-MEDIA:TYPE=AUDIO,GROUP-ID="aud",NAME="Korean",URI="audio/ko.m3u8"
#EXT-X-STREAM-INF:BANDWIDTH=6000000,RESOLUTION=1920x1080,CODECS="avc1.640028,mp4a.40.2",AUDIO="aud"
1080p/index.m3u8
#EXT-X-STREAM-INF:BANDWIDTH=3000000,RESOLUTION=1280x720,CODECS="avc1.4d401f,mp4a.40.2",AUDIO="aud"
720p/index.m3u8

마스터는 "어떤 화질이 있는지"의 목록(EXT-X-STREAM-INF에 BANDWIDTH/RESOLUTION/CODECS). 각 화질의 실제 세그먼트 목록은 별도 미디어 플레이리스트에 있습니다. 즉 화질을 바꾸려면 다른 미디어 플레이리스트를 추가로 받아야 합니다.

DASH — MPD 한 파일에 전체 구조

<MPD type="dynamic" minimumUpdatePeriod="PT2S">
  <Period>
    <AdaptationSet mimeType="video/mp4" codecs="avc1.640028">
      <Representation id="1080p" bandwidth="6000000" width="1920" height="1080">
        <SegmentTemplate initialization="1080p/init.mp4"
          media="1080p/seg_$Number$.m4s" startNumber="1" duration="2" timescale="1"/>
      </Representation>
      <Representation id="720p" bandwidth="3000000" width="1280" height="720">...</Representation>
    </AdaptationSet>
    <!-- 오디오는 비디오와 완전히 분리된 AdaptationSet -->
    <AdaptationSet mimeType="audio/mp4" codecs="mp4a.40.2" lang="ko">
      <Representation id="aud" bandwidth="128000">...</Representation>
    </AdaptationSet>
  </Period>
</MPD>

구조적 핵심 차이: DASH의 AdaptationSet은 비디오/오디오/자막을 완전히 분리해 자유 조합합니다. HLS도 fMP4 + EXT-X-MEDIA로 오디오/자막을 분리할 수 있지만, DASH는 처음부터 "분리가 기본"이라 다국어 오디오·다중 자막 조합이 구조적으로 더 깔끔합니다.

3. 세그먼트 — MPEG-TS(.ts) vs fMP4/CMAF(.m4s)

전통 HLS: MPEG-TS

seg_001.ts = 188바이트 고정 패킷의 연속
   PAT(PID 0x0) → PMT → Video PES(예: PID 0x100) + Audio PES(0x101)
   → 비디오·오디오가 한 파일에 섞여(muxed) 들어감
   → 4바이트 헤더 × 수많은 188B 패킷 = 오버헤드가 상대적으로 큼

fMP4 / CMAF (.m4s)

ISO BMFF(MP4) 기반의 "조각난 MP4"입니다. 초기화 세그먼트와 미디어 조각이 분리됩니다.

init.mp4 (최초 1회)          seg_001.m4s (반복)
┌──────────────┐            ┌──────────────────┐
│ ftyp         │            │ (styp)           │
│ moov         │            │ moof             │  ← 조각 메타
│  = 코덱/트랙  │            │  ├ mfhd(시퀀스)   │
│   전역 정보   │            │  └ traf          │
└──────────────┘            │     ├ tfhd(기본)  │
   재생 전 1번 로드           │     ├ tfdt(DTS)   │
                            │     └ trun(샘플)   │
                            │ mdat             │  ← 실제 NAL 데이터
                            └──────────────────┘
  • moov(init): 코덱·해상도 등 전역 정보. 재생 시작 전 한 번만 받습니다.
  • moof + mdat(각 조각): moof는 이 조각의 타임스탬프/샘플 정보, mdat는 실제 H.264/H.265 NAL.
  • 비디오·오디오를 별도 트랙/별도 파일로 두기 좋아, 분리·다국어에 유리하고 오버헤드도 작습니다.

HLS는 v7(2016, WWDC)부터 fMP4를 정식 지원합니다. 이게 다음에 볼 CMAF 통합의 출발점입니다.

4. ABR 동작 — 화질/오디오 전환 방식의 차이

ABR(적응형 비트레이트)의 "여러 화질을 미리 만들어 두고 플레이어가 고른다"는 원리는 같지만(자세한 건 #49), 전환 절차가 다릅니다.

HLS:
  master.m3u8 → 화질별 '미디어 플레이리스트' 따로 존재
  720p→1080p 전환 = 1080p의 미디어 플레이리스트를 새로 받아야 함
  (오디오는 보통 비디오에 묶이거나 EXT-X-MEDIA 그룹으로)

DASH:
  MPD 한 방에 모든 Representation이 들어 있음
  720p→1080p 전환 = 같은 AdaptationSet 안에서 Representation만 바꿈
  비디오만 바꾸고 오디오는 그대로 유지 가능 (독립 선택)

DASH가 "비디오만 다운시프트, 오디오는 한국어 그대로" 같은 독립 전환이 구조적으로 자연스럽습니다. HLS도 가능하지만 그룹 구성이 더 필요합니다.

5. DRM — FairPlay vs Widevine/PlayReady, 그리고 CENC

콘텐츠 보호가 둘을 가르는 가장 현실적인 벽입니다.

항목HLSDASH
대표 DRMFairPlay(Apple)Widevine(Google) · PlayReady(MS) · ClearKey
암호화AES-128, SAMPLE-AES(fMP4는 cbcs)CENC(Common Encryption): cenc(ctr) / cbcs
키 전달#EXT-X-KEY 태그(URI)MPD의 ContentProtection + pssh
멀티DRMFairPlay 위주Widevine+PlayReady 동시 기술 용이
<!-- DASH CENC: 한 콘텐츠에 여러 DRM 시스템을 동시에 선언 -->
<ContentProtection schemeIdUri="urn:uuid:EDEF8BA9-79D6-4ACE-A3C8-27DCD51D21ED" value="Widevine">
  <cenc:pssh>AAAA...</cenc:pssh>
</ContentProtection>
<ContentProtection schemeIdUri="urn:uuid:9A04F079-9840-4286-AB92-E65BE0885F95" value="PlayReady">...</ContentProtection>

실무에서 가장 중요한 정정: "CMAF 세그먼트 한 벌이면 DRM도 자동 통일"은 절반만 맞습니다. 진짜 걸림돌은 암호화 모드였습니다 — FairPlay는 cbcs(AES-CBC, 패턴 암호화), 초기 Widevine/PlayReady는 cenc(AES-CTR)를 써서, 같은 fMP4라도 암호화가 달라 한 벌로 못 묶였습니다. 이후 Widevine·PlayReady가 cbcs를 지원하면서 cbcs로 통일하면 CMAF 한 벌 + 멀티DRM이 실제로 가능해졌습니다. "세그먼트 통일 = cbcs 통일"이 핵심입니다.

6. 저지연 — LL-HLS vs LL-DASH (HTTP/2 Push 정정 포함)

둘 다 "세그먼트를 더 잘게 쪼개 빨리 흘린다"는 방향은 같습니다.

LL-HLS (Apple, 2019 — RFC 8216bis에 통합)

  • Partial Segment(EXT-X-PART): 6초 세그먼트가 닫히기 전에 200~500ms짜리 파트를 먼저 공개.
  • Blocking Playlist Reload: 플레이어가 ?_HLS_msn=&_HLS_part=로 "다음 파트 나오면 응답해"라고 요청하면, 서버가 응답을 붙들었다가(hold) 새 파트 생기는 즉시 돌려줌 → 폴링 대기 제거.
  • Preload Hint(EXT-X-PRELOAD-HINT): 곧 나올 파트 URL을 미리 알려 선요청.
  • Rendition Report(EXT-X-RENDITION-REPORT): 다른 화질의 최신 위치를 매니페스트에 같이 실어, 화질 전환 시 추가 왕복 제거.

⚠️ 정정 — HTTP/2 Push는 빠졌습니다: 2019년 초기 LL-HLS 초안은 HTTP/2 Push로 매니페스트와 다음 파트를 함께 밀어주는 방식이었으나, 2020년 개정에서 제거됐습니다(서버/CDN 호환성·복잡도 문제). 현재 LL-HLS의 선제 전송은 Push가 아니라 Preload Hint(선요청) + Blocking Reload(서버 hold) 조합으로 같은 효과를 냅니다. 인터넷에 도는 "LL-HLS = HTTP/2 Push" 설명은 옛 초안 기준입니다.

LL-DASH

<SegmentTemplate duration="2000" timescale="1000"
  availabilityTimeOffset="1.8"          <!-- 세그먼트 완성 전에 가용 표시 -->
  availabilityTimeComplete="false"/>

LL-DASH는 CMAF Chunked + HTTP Chunked Transfer Encoding으로 세그먼트가 다 만들어지기 전에 청크 단위로 흘려보냅니다. availabilityTimeOffset으로 "완성 0.2초 전부터 가용"을 알립니다.

둘 다 글래스-투-글래스를 약 2~4초대로 끌어내립니다. 단, CDN이 Blocking Reload/Chunked 전송을 지원해야 효과가 납니다(Cloudflare·Fastly·Akamai 등 설정 필요). 미지원 CDN에선 저지연 효과가 사라집니다. 프로토콜 선택의 큰 그림은 #40.

7. CMAF — 하나의 fMP4로 HLS·DASH 둘 다

과거: HLS(.ts) ─┐
                ├─ 같은 콘텐츠를 두 포맷으로 인코딩·저장 (2배 비용)
      DASH(.m4s)┘

CMAF(ISO·IEC 23000-19, 1판 2018 — 작업 2017~):
      HLS  ─┐
            ├─▶ 동일한 CMAF fMP4(.m4s) 세그먼트 한 벌 공유
      DASH ─┘   매니페스트만 .m3u8 / .mpd 둘로

CMAF는 "표준 fMP4 세그먼트 포맷"을 정해, 세그먼트는 한 벌만 만들고 매니페스트만 둘(m3u8 + mpd)로 제공하게 합니다.

  • 🟢 인코딩 1회: 같은 세그먼트를 양쪽이 참조.
  • 🟢 저장·CDN 캐시 효율: 파일이 한 벌이라 캐시 적중률↑, 스토리지↓.
  • ⚠️ 전제: 위 §5의 암호화 cbcs 통일과 코덱/세그먼트 길이 정렬이 맞아야 진짜 "한 벌"이 됩니다. 그렇지 않으면 결국 두 벌로 갈라집니다.

이게 현대 범용 OTT의 사실상 표준 구성입니다 — CMAF 세그먼트 + HLS·DASH 매니페스트 동시 제공.

8. 플랫폼 지원 — 결국 Apple이 변수다

플랫폼HLSDASH
iOS / macOS Safari✅ 네이티브❌ (MSE 기반 라이브러리 필요, iOS Safari는 MSE 제약도)
Android Chrome✅ (hls.js/MSE)✅ (네이티브/ExoPlayer·MSE)
데스크톱 Chrome/Firefox✅ (hls.js)✅ (dash.js·Shaka)
스마트TV·셋톱✅ 대체로✅ 대체로
YouTube—✅ DASH
Netflix—✅ DASH + Widevine

핵심은 한 줄로 정리됩니다: Apple 기기에서 네이티브로 도는 건 HLS뿐입니다. iOS 앱·Safari를 포기할 수 없다면 HLS는 사실상 필수고, 그래서 "DASH만" 가는 선택지는 범용 서비스에선 드뭅니다. (Apple 기기에서 DASH를 쓰려면 MSE 기반 플레이어가 필요한데, iOS Safari의 MSE 지원은 환경에 따라 제약이 있어 까다롭습니다.)

9. 실무 선택 가이드

┌─────────────────────────────────────────────────────────┐
│ Q1. iOS 앱 / Safari 지원이 필수인가?                     │
│   YES → HLS는 사실상 필수 (Q3로)                          │
│   NO  → Q2                                               │
├─────────────────────────────────────────────────────────┤
│ Q2. 멀티DRM + 다국어 오디오/자막 조합이 복잡한가?         │
│   YES → DASH가 구조적으로 유리                            │
│   NO  → HLS 단독으로도 충분                               │
├─────────────────────────────────────────────────────────┤
│ Q3. 웹·안드로이드까지 다 커버하는 범용 OTT인가?           │
│   YES → CMAF 세그먼트 1벌 + HLS·DASH 매니페스트 동시 제공 │
│         (cbcs 암호화 통일 전제)                           │
│   NO  → HLS 단독                                          │
├─────────────────────────────────────────────────────────┤
│ Q4. 저지연 라이브(스포츠·게임, 목표 <4초)인가?            │
│   YES → LL-HLS / LL-DASH (CDN 지원 필수)                  │
│   더 낮게(<1초) → WebRTC 검토 (#40)                       │
└─────────────────────────────────────────────────────────┘
상황권장
Apple 기기 필수(iOS 앱·Safari)HLS(필수)
멀티DRM·다국어·복잡 구성DASH
YouTube/Netflix류 VODDASH
범용 OTT(모든 기기)CMAF + HLS·DASH 동시
저지연 라이브LL-HLS / LL-DASH
초저지연(<1초)WebRTC

10. 한 장 요약 — 암기 카드

개념한 줄
HLSApple 표준, .m3u8, Apple 기기 네이티브
DASHISO 국제표준, .mpd(XML), 코덱·DRM 자유
세그먼트전통 TS(.ts) vs fMP4(.m4s) — HLS도 fMP4 지원
ABRHLS=미디어 플레이리스트 교체 / DASH=Representation 교체(A/V 독립)
DRMHLS=FairPlay(cbcs) / DASH=CENC(Widevine·PlayReady)
저지연LL-HLS(EXT-X-PART+Blocking+Preload, Push는 제거됨) / LL-DASH(CMAF chunked)
CMAFfMP4 한 벌로 양쪽 — 단 cbcs 암호화 통일 전제
결론"HLS냐 DASH냐"가 아니라 "CMAF + 양쪽 매니페스트"

11. 한 줄 결론

HLS와 DASH는 본질(조각+HTTP 배달)이 같고, 매니페스트 문법·전통 세그먼트 포맷·DRM 생태계가 다르다. 둘 다 fMP4를 쓰게 되면서 CMAF가 "세그먼트 한 벌 + 매니페스트 둘"을 가능케 했고(암호화 cbcs 통일이 전제), 그래서 범용 OTT의 정답은 양자택일이 아니라 통합이다. 단 Apple 기기 네이티브는 HLS뿐이라는 제약, 그리고 LL-HLS의 저지연은 HTTP/2 Push가 아니라 Preload Hint+Blocking Reload로 낸다는 점은 꼭 기억해야 한다.

관련 글

참고 자료

© 2026 Frank Kim. All rights reserved.