HLS vs HTTP-FLV vs MP4 — 프로토콜과 컨테이너부터 바로잡는 스트리밍 선택 가이드

"HLS와 FLV 중 무엇을 써야 하나요? MP4까지 비교하면 어떤 게 가장 좋나요?" 라이브 스트리밍을 설계할 때 자주 나오는 질문입니다. 그런데 이 질문에는 먼저 바로잡아야 할 함정이 있습니다. HLS와 HTTP-FLV는 영상을 전달하는 방식이고, FLV와 MP4는 영상과 음성을 담는 파일 형식입니다. 서로 역할이 다르기 때문에 단순히 어느 하나가 더 좋다고 비교하기는 어렵습니다.

이 글은 자주 인용되는 설명을 공식 사양과 구현 문서로 다시 검증합니다. HLS가 반드시 .ts만 쓰는지, HTTP-FLV가 Flash Player와 함께 사라졌는지, "HLS 1030초, HTTP-FLV 13초"라는 숫자를 어디까지 믿어야 하는지부터 정리한 뒤 실제 선택 기준으로 연결합니다.

0. 결론부터 — 서비스 요구사항이 답을 정한다

대규모 배포와 기기 호환성이 중요하면 HLS, 지원할 기기를 제한할 수 있고 낮은 지연이 중요하면 HTTP-FLV를 먼저 검토합니다. 다운로드·VOD·녹화 파일에는 MP4가 가장 무난합니다. 1초 안에 반응해야 하는 양방향 서비스라면 WebRTC도 함께 비교해야 합니다.

표에 적힌 지연 시간은 보장값이 아닙니다. 카메라에 찍힌 장면이 시청자 화면에 나오기까지 실제로 몇 초가 걸리는지 직접 측정해서 판단해야 합니다.

1. 가장 먼저 바로잡을 것 — 프로토콜, 컨테이너, 코덱은 다르다

영상 시스템은 세 층으로 나눠 보면 헷갈리지 않습니다.

전달 방식:  HLS          HTTP-FLV       HTTP progressive download
              │              │                    │
컨테이너:   MPEG-TS/fMP4     FLV                  MP4
              │              │                    │
코덱:       H.264/AAC 등    H.264/AAC 등         H.264/AAC 등

• 코덱(codec): 영상과 음성의 용량을 줄이는 압축 방식입니다. H.264, HEVC, AAC 등이 있습니다.
• 컨테이너(container): 압축된 영상과 음성을 함께 담는 상자입니다. FLV, MP4, MPEG-TS가 여기에 해당합니다.
• 전달 방식: 이 상자를 시청자에게 보내는 방법입니다. HLS와 HTTP-FLV가 여기에 해당합니다.

그래서 MP4라고 화질이 더 좋아지거나, FLV라고 용량이 더 작아지는 것은 아닙니다. FLV 안의 영상을 다시 압축하지 않고 MP4로 옮겨 담기만 하면 화질은 그대로입니다. 같은 물건을 다른 상자에 옮기는 것과 같습니다. 이런 작업을 리먹싱(remuxing)이라고 합니다. 화질은 파일 형식을 바꿀 때가 아니라, 영상을 다시 압축하면서 해상도나 비트레이트를 낮출 때 달라집니다.

2. 원문 팩트체크 — 맞는 말, 조건이 필요한 말, 틀린 말

핵심은 두 가지입니다. Flash Player가 종료됐다고 FLV 파일 형식까지 사라진 것은 아닙니다. HLS와 MP4도 경쟁 관계가 아닙니다. HLS가 영상을 나눠 보낼 때 MP4 계열인 fMP4를 사용할 수 있기 때문입니다.

3. HLS — 파일 조각과 플레이리스트로 확장성을 얻는다

HLS는 미디어를 짧은 세그먼트로 만들고, .m3u8 플레이리스트에 세그먼트 URL과 재생 규칙을 기록합니다. 플레이어는 플레이리스트를 갱신하면서 필요한 세그먼트를 HTTP로 요청합니다.

master.m3u8
├── 1080p/playlist.m3u8 → seg101.m4s → seg102.m4s → ...
├──  720p/playlist.m3u8 → seg101.m4s → seg102.m4s → ...
└──  480p/playlist.m3u8 → seg101.m4s → seg102.m4s → ...

HLS가 강한 이유

1. 일반 HTTP/CDN과 잘 맞는다
   플레이리스트와 세그먼트가 독립된 HTTP 객체라 엣지 캐시로 대규모 시청자에게 배포하기 쉽습니다.

2. ABR이 구조에 포함된다
   여러 비트레이트의 rendition을 준비하면 플레이어가 처리량과 버퍼 상태에 따라 화질을 전환합니다. 단, HLS를 쓴다고 ABR이 자동 생성되는 것은 아닙니다. 인코더와 패키저가 여러 rendition을 만들어야 합니다.

3. 라이브와 VOD를 같은 모델로 다룬다
   라이브는 플레이리스트가 계속 갱신되고, VOD는 완성된 목록을 제공합니다.

.ts만 쓴다는 설명이 낡은 이유

RFC 8216은 HLS 미디어 세그먼트로 MPEG-2 TS와 fragmented MPEG-4를 모두 정의합니다. Apple의 현재 문서도 인코더 출력으로 fMP4 또는 MPEG-2 TS를 설명합니다. 따라서 다음처럼 이해해야 정확합니다.

초기 HLS에서 흔함:       .m3u8 + .ts
현대 HLS/CMAF에서 흔함:  .m3u8 + init.mp4 + .m4s

지연이 커지는 지점

표준 HLS는 완성된 세그먼트를 발행하고 플레이어가 안정적인 재생을 위해 라이브 엣지보다 뒤에서 버퍼링합니다. 그래서 지연은 단순히 "세그먼트 한 개 길이"가 아닙니다.

총 지연 ≈ 인코딩 + 세그먼트 완성 대기 + origin/CDN 전파
        + 다운로드 + 플레이어 hold-back/buffer + 디코딩

10~30초는 전통적 설정에서 관찰되는 대표 범위이지 사양이 보장하는 값이 아닙니다. 2초 세그먼트, 낮은 hold-back, 빠른 CDN, 공격적인 플레이어 설정을 쓰면 더 줄일 수 있고, 안정성을 위해 버퍼를 늘리면 더 커집니다.

4. LL-HLS — HLS의 배포 모델을 유지하며 지연을 줄인다

LL-HLS는 세그먼트 하나가 완성될 때까지 기다리지 않습니다. 완성된 부분부터 작은 조각(partial segment)으로 먼저 보냅니다. Apple 문서가 설명하는 핵심 기능은 partial segment, playlist delta update, blocking playlist reload, preload hint, rendition report입니다.

표준 HLS: [──────── 2초 세그먼트 ────────] → 완성 후 전달
LL-HLS:   [0.2s][0.2s][0.2s][0.2s] ...   → part별로 빠르게 전달

이 방식은 HLS의 HTTP/CDN 모델과 ABR을 유지하면서 지연을 수초대로 낮출 수 있습니다. 반면 origin, CDN, 패키저, 플레이어 중 하나라도 LL-HLS 동작을 제대로 지원하지 않으면 지연 이점이 사라집니다. 요청 빈도와 운영 복잡도도 표준 HLS보다 높습니다.

즉 LL-HLS 형식으로 파일만 만든다고 바로 2초 지연이 되는 것은 아닙니다. 영상을 만드는 서버부터 CDN과 플레이어까지 모든 구간이 LL-HLS를 지원해야 합니다.

5. HTTP-FLV — 하나의 HTTP 응답으로 FLV tag를 계속 흘린다

HTTP-FLV는 독립된 IETF/W3C 표준 프로토콜 이름이라기보다, FLV 컨테이너를 HTTP의 지속 응답으로 전달하는 구현 관행을 가리킵니다.

GET /live/channel.flv

HTTP/1.1 200 OK
Content-Type: video/x-flv

[FLV Header][Metadata][Video Tag][Audio Tag][Video Tag][Audio Tag] ...
                         서버가 연결을 유지하며 계속 전송 ───────►

HLS처럼 플레이리스트를 갱신하고 다음 파일이 완성되기를 기다리지 않으므로 지연을 낮추기 쉽습니다. HTTP 인프라와 방화벽 친화성을 활용할 수 있다는 점도 장점입니다.

Flash가 없는데 브라우저에서 어떻게 재생하나

브라우저의 <video src="...flv">가 FLV를 직접 재생하는 것이 아닙니다. 대표적인 flv.js 흐름은 다음과 같습니다.

HTTP-FLV 수신
  → JavaScript가 FLV tag demux
  → H.264/AAC를 fMP4 segment로 transmux
  → Media Source Extensions의 SourceBuffer에 append
  → HTML <video>가 디코딩·재생

W3C의 MSE byte stream registry에는 MP4, WebM, MPEG-2 TS 등이 등록되어 있지만 FLV는 없습니다. 이것이 FLV를 바로 넣지 않고 fMP4로 변환하는 이유입니다.

장점

• 세그먼트 완성 대기가 없어 수초대 지연을 만들기 쉽다.
• RTMP ingest의 FLV tag 구조와 가까워 서버에서 재패키징 비용을 줄이기 쉽다.
• 하나의 HTTP 연결이라는 비교적 단순한 모델이다.

단점

• FLV 네이티브 재생이 아니므로 JavaScript transmuxer와 MSE에 의존한다.
• 단일 연속 연결은 HLS의 독립 세그먼트만큼 CDN 캐시에 자연스럽지 않다.
• HLS master playlist 같은 표준 ABR 모델이 없다. 자체 다중 스트림·재접속 로직을 설계해야 한다.
• 긴 연결이 끊기면 재접속, 최신 GOP 진입, 버퍼 정리를 직접 안정화해야 한다.
• iOS를 포함한 모바일 전체를 한 경로로 지원하기 까다롭다.

참고: 원문에서 제안한 flv.js는 동작 원리를 설명하는 좋은 예지만, 저장소 자체가 유지보수 빈도가 낮다고 밝히고 라이브에는 후속 프로젝트인 mpegts.js 검토를 권합니다. 신규 서비스라면 특정 플레이어를 기본값으로 정하기 전에 현재 유지보수 상태와 대상 브라우저를 다시 확인해야 합니다.

6. MP4 — 범용 컨테이너지만, 그 자체로 ABR 라이브는 아니다

MP4는 MPEG-4 Part 14로 정의된 컨테이너입니다. 비디오·오디오·자막·메타데이터 트랙을 담을 수 있으며 H.264/AAC 조합은 현대 기기와 브라우저에서 매우 널리 재생됩니다.

그러나 "MP4로 스트리밍한다"는 말은 여러 구조를 가리킬 수 있습니다.

따라서 MP4는 HLS의 경쟁자가 아니라 HLS 안에서도 사용할 수 있는 파일 형식입니다. 단일 MP4 파일은 범용 VOD에는 훌륭하지만, 네트워크 상태에 따라 여러 화질을 자동 전환하는 ABR 라이브를 혼자 제공하지는 않습니다.

7. 실무 비교표 — 지연 숫자보다 구조를 본다

표의 지연 범위는 아키텍처 초기 가설에만 사용하세요. 최종 결정은 목표 지역·기기·동시접속·네트워크 조건에서 측정한 p50/p95 glass-to-glass 지연, rebuffering 비율, 시작 시간으로 내려야 합니다.

8. 시나리오별 선택

시나리오 A — 글로벌 스포츠 중계

처음부터 HTTP-FLV로 단정하기 어렵습니다. 스포츠는 지연도 중요하지만 수십만 동시접속, 스마트 TV, iOS, ABR, CDN 비용까지 함께 봐야 합니다.

수초 지연 허용 + 대규모/다기기 → LL-HLS 우선
표준 방송 지연 허용           → HLS 우선
통제된 특정 웹 클라이언트      → HTTP-FLV 후보
1초 미만 베팅·상호작용         → WebRTC 또는 hybrid 검토

시나리오 B — 라이브 커머스

모든 시청자를 하나의 프로토콜로 통일할 필요가 없습니다.

호스트·게스트: WebRTC
대규모 일반 시청자: LL-HLS 또는 HLS
특정 Android/desktop 시장의 저지연 경로: HTTP-FLV 후보
다시보기·상품 클립: MP4

이 hybrid 구조는 상호작용이 필요한 소수와 안정적으로 시청만 하는 다수를 분리합니다. 트레이드오프는 파이프라인과 동기화 복잡도가 늘어난다는 점입니다.

시나리오 C — 사내 모니터링·관제

대상 브라우저와 네트워크를 통제할 수 있고 1~3초대가 충분하다면 HTTP-FLV가 실용적일 수 있습니다. 반대로 iPhone 현장 접속, 다양한 스마트 기기, 다중 화질이 요구되면 HLS/LL-HLS가 운영 리스크를 줄입니다.

시나리오 D — 교육 VOD

다운로드 방지·다중 화질·긴 영상의 탐색이 중요하면 HLS가 유리합니다. 단순 업로드·다운로드와 짧은 영상이라면 MP4가 더 단순합니다. 실시간 수업에서 교사와 학생의 대화까지 필요하면 WebRTC를 별도 경로로 둡니다.

9. 선택 전 체크리스트

1. 시청자 대부분이 실제로 체감하는 지연 시간은 몇 초까지 허용할 수 있는가?
2. 대상이 Safari/iOS, Android, 데스크톱 웹, 스마트 TV 중 어디까지인가?
3. 예상 동시접속과 지역 분포는 어떻게 되는가?
4. ABR이 필수인가, 단일 화질로도 충분한가?
5. origin과 CDN이 LL-HLS의 partial segment·blocking reload를 지원하는가?
6. HTTP-FLV를 택한다면 플레이어 유지보수, MSE 호환성, 재접속, GOP cache를 누가 책임지는가?
7. 녹화·다시보기 산출물은 MP4인가, HLS VOD인가?
8. 목표 기기에서 startup time, p50/p95 latency, rebuffer ratio를 실제 측정했는가?

10. 최종 정리

HLS와 HTTP-FLV는 영상을 보내는 방법이고, FLV와 MP4는 영상과 음성을 담는 파일 형식입니다. HLS는 .ts뿐 아니라 fMP4도 사용할 수 있습니다. HTTP-FLV는 Flash Player 없이도 재생할 수 있지만 모바일 지원, 자동 화질 전환, 대규모 배포에는 제약이 있습니다. MP4는 호환성이 좋은 파일 형식이지만, MP4 하나만으로 라이브 화질을 자동 전환할 수는 없습니다.

안정적인 대규모 배포와 글로벌 기기 호환성이 중요하면 HLS가 기본값입니다. 지연을 수초대로 줄여야 하면 LL-HLS를 먼저 검토합니다. 지원 환경을 통제할 수 있고 HTTP 기반 저지연이 최우선이면 HTTP-FLV가 후보가 될 수 있습니다. 1초 미만의 양방향 경험이 제품 가치의 핵심이라면 HTTP-FLV에서 멈추지 말고 WebRTC까지 비교해야 합니다.

관련 글

• #40 라이브 스트리밍 프로토콜 선택 — HLS / LL-HLS / WebRTC — 지연 예산에 따른 프로토콜 의사결정
• #50 HLS vs DASH — CMAF가 둘을 합친 방법 — 매니페스트·세그먼트·DRM 비교
• #49 라이브 스트리밍 송출 파이프라인 — RTMP ingest부터 ABR·CDN·플레이어까지
• #15 M3U8과 TS 파일의 모든 것 — HLS 플레이리스트와 세그먼트 구조
• #16 FFmpeg, 미디어의 스위스 아미 나이프 — 컨테이너·코덱·트랜스먹싱 기초

검증 자료

• RFC 8216 — HTTP Live Streaming — HLS 플레이리스트와 MPEG-TS·fMP4 세그먼트 정의
• Apple — HTTP Live Streaming — HLS의 HTTP/CDN 배포, ABR, fMP4·MPEG-TS 구성
• Apple — Enabling Low-Latency HLS — partial segment, blocking reload, preload hint 등 LL-HLS 기능
• Adobe Flash Video File Format Specification 10.1 — FLV tag·codec·timestamp 구조
• Adobe — Flash Player End of Life — Flash Player 종료 사실
• W3C — Media Source Extensions Byte Stream Format Registry — MSE의 MP4·WebM·MPEG-2 TS 등록 형식
• flv.js — HTML5 FLV Player — FLV를 fMP4로 transmux해 MSE로 재생하는 구현과 유지보수 안내
• MPEG — ISO Base Media File Format — MP4 계열의 box·track·fragment 구조와 활용 범위
• MDN — Media container formats — 컨테이너·코덱 구분과 MP4 웹 호환성