5장. HLS의 한계를 줄이기 위한 변화

5.1 문제를 다시 바라보기

4장에서 확인했듯이 HLS의 지연은 단순한 성능 문제가 아니라
구조에서 자연스럽게 발생하는 결과다.

영상이 만들어지고 시청자에게 전달되기까지
여러 단계에서 기다림이 발생한다.

서버는 segment를 만들기 위해 기다리고,
플레이어는 새로운 데이터를 알기 위해 다시 요청해야 하며,
재생을 시작하기 위해 buffer를 쌓는다.

이 흐름을 이해하면 자연스럽게 하나의 방향이 나온다.

이 기다림을 줄이면 더 빠르게 만들 수 있다

5.2 가장 단순한 변화: segment를 더 작게 나누기

가장 먼저 시도된 방법은 segment를 더 짧게 만드는 것이다.

기존 HLS에서는 보통 2초 이상의 단위로 영상을 나눴다.
이 구조에서는 segment 하나가 완성되기까지 최소 그 시간만큼 기다려야 한다.

그래서 다음과 같은 변화가 등장한다.

• 2초 → 1초
• 또는 그보다 더 짧게

이렇게 하면 segment 생성까지의 대기 시간은 줄어든다.

하지만 중요한 점은 그대로다.

여전히 “완성된 뒤에 전송한다”는 구조는 유지된다

즉, 지연은 줄어들지만 근본적인 구조는 바뀌지 않는다.

5.3 다음 단계: 만드는 중간부터 전달하기

여기서 HLS 구조를 크게 바꾸는 아이디어가 등장한다.

segment가 완성될 때까지 기다리지 말고, 만드는 중간부터 전달하자

기존 방식에서는
2초짜리 segment가 모두 완성된 뒤에야 전송이 시작된다.

개선된 방식에서는 이렇게 바뀐다.

• segment를 만들면서
• 그 안을 더 작은 단위로 나누고
• 만들어지는 즉시 전달한다

예를 들어 2초짜리 segment가 있다면

• 0~0.5초 생성 → 바로 전달
• 0.5~1초 생성 → 바로 전달
• 1~1.5초 생성 → 바로 전달

이 방식은 기존과 비교하면 명확하게 다르다.

“완성 후 전송”에서 “생성 중 전송”으로 바뀐다

이 개념을 chunk 기반 전송이라고 한다.

5.4 segment와 chunk의 역할 구분

여기서 헷갈리기 쉬운 부분을 정리한다.

segment와 chunk는 같은 것이 아니다.

segment는 플레이어가 재생을 위해 사용하는 기준 단위이고,
chunk는 데이터를 전송하기 위해 더 잘게 나눈 단위다.

하나의 segment는 여러 개의 chunk로 나뉠 수 있다.

이렇게 이해하면 된다.

• segment → 재생 단위
• chunk → 전송 단위

이 구분이 이해되면 “만들면서 전달한다”는 개념도 자연스럽게 이어진다.

5.5 요청 방식의 변화: polling에서 대기형으로

기존 HLS는 polling 방식으로 동작한다.

플레이어는 일정 주기로 서버에 요청한다.

“새로운 데이터 있어?”

이 요청은 반복되고,
데이터가 없으면 응답은 끝나며 다시 요청해야 한다.

이 구조에서는 문제가 하나 발생한다.

데이터가 이미 준비됐어도
플레이어가 아직 요청하지 않았다면 전달되지 않는다

즉, 요청 타이밍에 따라 지연이 추가로 발생한다.

개선된 방식에서는 이 구조가 바뀐다.

플레이어는 요청을 한 번 보내고 연결을 유지한다.
서버는 즉시 응답하지 않고 기다린다.
그리고 데이터가 준비되는 순간 바로 전달한다.

흐름은 이렇게 바뀐다.

• 기존: 요청 → 응답 → 종료 → 다시 요청
• 개선: 요청 → 대기 → 데이터 생성 → 즉시 전달

이 차이를 한 문장으로 정리하면 다음과 같다.

계속 확인하는 구조에서, 기다렸다가 바로 받는 구조로 바뀐다

이 변화는 polling으로 인해 발생하던 지연을 줄이는 데 중요한 역할을 한다.

5.6 변화의 핵심과 한계

지금까지의 변화를 하나로 정리해보면 다음과 같다.

HLS는 다음 세 가지 방향으로 개선된다.

• segment를 더 작게 만들어 생성 대기 시간을 줄이고
• 데이터를 chunk 단위로 나누어 생성 중에 전달하며
• 요청 방식을 polling에서 대기형으로 바꿔 전달 지연을 줄인다

이 세 가지는 모두 같은 목표를 가진다.

기다리는 시간을 최대한 줄인다

하지만 중요한 사실이 하나 남아 있다.

구조 자체는 여전히 HLS다

즉 다음 요소는 그대로 유지된다.

• HTTP 요청 기반 구조
• playlist 중심 동작
• player buffer 필요

이 때문에 레이턴시는 줄어들지만 완전히 사라지지는 않는다.

일반적으로는 다음과 같은 수준이 된다.

• 기존 HLS: 약 6~10초
• LL-HLS: 약 2~3초

즉, 개선은 되었지만 완전히 실시간은 아니다.

이걸 한 문장으로 정리하면 이렇게 말할 수 있다.

LL-HLS는 HLS 구조를 유지하면서 지연을 최소화하기 위한 현실적인 개선 방식이다