2장. 왜 동영상을 잘게 나누는가

2.1 동영상을 “쪼개서” 전달한다는 것

HLS는 동영상을 하나의 파일로 다루지 않는다.

대신 이렇게 처리한다.

동영상을 짧은 시간 단위의 조각으로 나누고 이를 순차적으로 전달한다

이 개념을 쉽게 이해하려면 이렇게 생각하면 된다.

HLS는 영상을 한 편의 긴 영화 파일이 아니라 짧은 영상 클립들의 집합으로 다룬다.

예를 들어 10초짜리 영상이라면:

0~2초   → seg1
2~4초   → seg2
4~6초   → seg3
6~8초   → seg4
8~10초  → seg5

플레이어는 이 조각들을 순서대로 다운로드하면서 동시에 재생한다.

즉 전체 영상을 한 번에 받는 것이 아니라 조각 단위로 이어 붙이면서 재생하는 구조다.

2.2 잘게 나누는 이유: 전체 실패에서 부분 실패로

이 구조는 단순한 구현 방식이 아니라 스트리밍의 문제를 해결하기 위한 핵심 설계다.

네트워크는 항상 불안정하다

인터넷 환경은 항상 안정적이지 않다.

• 속도가 순간적으로 떨어질 수 있다
• 패킷 손실이 발생할 수 있다
• 연결이 일시적으로 끊길 수 있다

큰 파일 vs 조각 단위

만약 하나의 큰 파일을 전송하는 구조라면:

• 다운로드 중단 시 전체 흐름이 끊긴다
• 재시작 비용이 매우 크다

반면 조각 단위로 나누면:

• 일부 조각만 실패한다
• 다음 조각부터 다시 요청할 수 있다

즉 HLS는 문제의 단위를 바꾼다.

“전체 실패“에서 “부분 실패“로 축소한다

이것이 HLS가 안정적인 이유다.

2.3 HTTP 요청 구조와의 결합

HLS는 HTTP 요청 기반 구조다.

이 구조의 흐름은 이렇다.

요청 → 응답 → 종료
다시 요청 → 응답 → 종료
...

동영상을 조각으로 나누면 이 흐름에 딱 맞는다.

• 조각 하나 = 요청 하나
• 요청 단위로 독립 처리 가능

즉 이렇게 표현할 수 있다.

조각 단위 구조는 HTTP의 특성과 정확히 맞물린다

이 매칭은 우연이 아니다. HLS는 처음부터 HTTP에 맞도록 영상을 재해석한 기술이다.

2.4 적응형 비트레이트(ABR)의 필요성

네트워크는 항상 일정하지 않다.

• 어떤 순간에는 10 Mbps
• 어떤 순간에는 2 Mbps

이 상황에서 항상 고화질 영상을 보내면:

• 버퍼링 발생
• 재생 끊김

반대로 항상 저화질이면:

• 화질 낭비
• 사용자 경험 저하

이 문제를 해결하기 위해 등장한 개념이 적응형 비트레이트 (Adaptive Bitrate, ABR)이다.

2.5 ABR이 가능한 이유

ABR은 HLS의 조각 구조 덕분에 가능하다.

핵심은 이것이다.

각 조각이 독립적인 영상 단위로 존재한다

같은 시간 구간이라도 여러 화질 버전이 존재할 수 있다.

플레이어는 다음과 같은 선택이 가능하다.

• seg1은 1080p로 재생
• seg2는 720p로 전환
• seg3은 다시 1080p로 복귀

즉 이렇게 정리된다.

다음 조각부터 화질을 바꿀 수 있다

이것이 ABR의 핵심이다.

Keyframe Alignment

ABR이 자연스럽게 동작하려면 한 가지 조건이 필요하다.

모든 화질의 segment 경계가 같은 위치(시간)에 있어야 한다

이 정렬을 keyframe alignment라고 부른다.

자세한 내용은 4.4절에서 다룬다.

지금은 이것만 기억하면 된다.

같은 시점에서 화질을 바꿀 수 있는 이유는 모든 화질이 같은 위치에서 잘려 있기 때문이다.

2.6 ABR 알고리즘의 종류

플레이어는 단순히 랜덤으로 화질을 바꾸지 않는다. 정해진 알고리즘으로 판단한다.

대표적인 방식은 세 가지다.

① Throughput-based (대역폭 기반)

가장 단순한 방식.

플레이어가 segment를 다운로드하면서 다운로드 속도를 측정한다.

seg1: 2 MB / 0.5초 → 32 Mbps
seg2: 2 MB / 1.0초 → 16 Mbps
seg3: 2 MB / 2.0초 → 8 Mbps  ← 떨어짐

측정한 속도보다 낮은 비트레이트를 가진 화질을 다음 segment로 선택한다.

장점

• 직관적이고 구현이 쉽다
• 빠른 네트워크에서 잘 동작한다

단점

• 네트워크가 출렁이면 화질도 출렁인다
• 버퍼 상태를 고려하지 않는다

② Buffer-based (버퍼 기반)

다른 접근.

플레이어 내부 버퍼의 양을 기준으로 판단한다.

버퍼 < 5초   → 화질 낮춤 (안전 우선)
버퍼 10~20초 → 현재 화질 유지
버퍼 > 20초  → 화질 높임 (여유 있음)

장점

• 네트워크 출렁임에 둔감하다
• 화질 변화가 부드럽다

단점

• 초기 재생(버퍼가 비어있을 때) 판단이 어렵다
• 네트워크가 갑자기 좋아져도 반응이 느리다

③ Hybrid (혼합 방식)

throughput + buffer를 함께 본다.

• 초기에는 throughput 기반으로 빠르게 결정
• 안정화되면 buffer 기반으로 부드럽게 유지
• 네트워크 급변 시 throughput 재반영

실무에서 쓰이는 대부분의 플레이어 (hls.js, Shaka Player, ExoPlayer 등)는 hybrid 방식을 사용한다.

대표적인 학술 알고리즘으로 BOLA, MPC, Pensieve 등이 있다.

2.7 ABR의 실제 동작 흐름

플레이어 내부에서는 다음 흐름이 반복된다.

1. 현재 화질로 segment 요청
2. 다운로드 시간 측정
3. 버퍼 잔량 확인
4. 알고리즘으로 다음 화질 결정
5. 결정된 화질의 segment 요청

이 과정을 통해 플레이어는 다음 목표를 추구한다.

끊김 없이 가능한 최고 화질을 유지한다

이 두 가지는 충돌하는 목표지만, ABR이 그 사이에서 균형을 잡는다.

2장 한 줄 정리

동영상을 쪼개는 것은 저장 방식이 아니라 안정성과 화질 적응을 동시에 얻기 위한 설계다.