1장. HLS의 정의와 등장 배경

1.1 스트리밍의 본질과 초기 방식

스트리밍이란
데이터를 모두 다운로드하지 않고, 전달받으면서 동시에 재생하는 방식이다.

초기 스트리밍 기술은 이 개념을 구현하기 위해
“지속적인 연결”을 기반으로 설계되었다.

대표적으로 다음과 같은 프로토콜이 사용되었다.

• RTMP
• RTSP

이 방식의 핵심 구조는 다음과 같다.

클라이언트와 서버가 연결을 유지한 상태에서
데이터를 끊임없이 전달한다

이 구조는 실시간성 측면에서는 효과적이었지만,
인터넷 환경 전체를 고려했을 때는 여러 한계를 가지고 있었다.

1.2 기존 스트리밍 구조의 한계

연결 기반 스트리밍은 다음과 같은 구조적 문제를 가진다.

1) 연결 상태에 대한 강한 의존성

스트리밍이 진행되는 동안 연결이 유지되어야 하므로
네트워크 상태 변화에 매우 민감하다.

• 네트워크 전환 (Wi-Fi → LTE)
• 일시적인 패킷 손실
• 연결 지연

이러한 상황이 발생하면 스트리밍 품질이 즉시 영향을 받는다.

2) 재연결 비용과 복구 문제

연결이 끊어지면 단순히 이어서 재생하는 것이 아니라
다음과 같은 과정이 필요하다.

• 재연결 (handshake)
• 스트림 위치 동기화
• 버퍼 재구성

이 과정은 사용자 입장에서
“영상이 멈추고 한참 뒤에 다시 시작되는 경험”으로 이어진다.

3) 모바일 환경에서의 비효율

연결을 계속 유지하는 구조는 다음과 같은 비용을 발생시킨다.

• 네트워크 인터페이스 지속 활성화
• CPU 사용 증가
• 배터리 소모 증가

특히 모바일 환경에서는 이 문제가 치명적이다.

4) 웹 인프라와의 비호환성

기존 스트리밍은 HTTP 기반이 아니기 때문에:

• CDN 캐싱 활용이 어렵고
• 웹 트래픽과 분리된 별도의 인프라가 필요하다

이는 대규모 서비스 확장에 큰 제약이 된다.

1.3 Apple의 문제 정의

이러한 한계를 해결하기 위해
Apple은 근본적인 질문을 던졌다.

“스트리밍은 반드시 연결을 유지해야 하는가?”

이 질문은 단순한 개선이 아니라
스트리밍의 전제를 뒤집는 접근이었다.

1.4 HLS의 핵심 아이디어

Apple이 제시한 해법은 다음과 같다.

스트리밍을 ‘연결 기반’이 아니라 ‘요청 기반’으로 바꾸자

즉 기존 방식이

• 하나의 연결 위에서 데이터를 흘려보냈다면

HLS는

• 데이터를 여러 단위로 나누고
• 필요할 때마다 요청하여 가져오는 방식으로 바뀌었다

이 변화는 단순한 구현 차이가 아니라
시스템의 성격 자체를 바꾼다.

연결 기반 vs 요청 기반

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

HLS는 스트리밍을 “데이터 흐름”이 아니라 “리소스 요청”으로 재정의한 기술이다

1.5 HTTP 기반 설계의 의미

HLS는 HTTP/HTTPS 위에서 동작한다.
이 선택은 단순한 구현 편의가 아니라 전략적 결정이다.

1) 웹 인프라와의 완전한 통합

• 기존 웹 서버 사용 가능
• CDN 캐싱 활용 가능
• 별도 프로토콜 필요 없음

즉, 스트리밍이 웹 트래픽의 일부가 된다

2) Stateless 구조

각 요청은 독립적으로 처리된다.

• 연결 유지 불필요
• 실패 시 다음 요청으로 복구 가능

이는 네트워크 환경 변화에 강한 구조를 만든다.

3) 네트워크 및 방화벽 친화성

HLS는 일반 웹 요청과 동일하게 동작한다.

• 포트 80 / 443 사용
• HTTP GET 요청 기반

따라서 대부분의 네트워크 환경에서 자연스럽게 허용된다.

여기서 중요한 표현은 다음과 같다.

HLS는 방화벽을 “우회하는 기술”이 아니라
애초에 차단되지 않는 방식으로 설계된 기술이다

1.6 시장과 기술의 교차점

HLS는 기술적 해결책이면서 동시에
플랫폼 전략의 일부였다.

당시 스트리밍 시장은
Adobe의 Flash 기반 기술이 지배하고 있었다.

Flash 기반 구조는:

• RTMP 중심
• 플러그인 의존
• 데스크탑 환경 중심

이에 대해
Apple은 다음과 같은 방향을 선택했다.

Apple의 전략

• iPhone에서 Flash 미지원 선언
• HTML5 기반 웹 생태계 선택
• HTTP 기반 스트리밍 도입

이 선택은 단순한 기술 교체가 아니라
스트리밍의 권력 구조를 바꾸는 결정이었다.

결과적으로:

스트리밍은 플러그인 기술에서 웹 표준 기술로 전환되었다

1.7 스트리밍 패러다임의 전환

HLS의 등장 이후 스트리밍은 다음과 같이 변화했다.

Before

• 연결 중심
• 특수 프로토콜
• 환경 의존적

After

• 요청 중심
• HTTP 기반
• 웹과 완전히 통합

이 변화의 핵심은 다음 한 문장으로 요약된다.

스트리밍은 더 이상 특수한 기술이 아니라, 웹 기술의 일부가 되었다

1.8 HLS의 설계 목표와 구조적 한계

HLS는 특정 목표를 기반으로 설계되었다.

✔ 설계 목표

• 안정성
• 확장성
• 네트워크 호환성

❗ 그 결과 발생하는 한계

이 구조는 자연스럽게 다음과 같은 특성을 만든다.

• 데이터가 준비된 이후 전달됨
• 요청 단위로 처리됨

👉 결과:

구조적으로 지연(Latency)이 발생한다

이 부분은 매우 중요하다.

HLS는 초저지연을 위해 만들어진 기술이 아니다
→ 안정성과 확장성을 우선한 기술이다