Keyboard shortcuts

Press ← or → to navigate between chapters

Press S or / to search in the book

Press ? to show this help

Press Esc to hide this help

7장. 브라우저 재생 구조의 진화와 MSE

7.1 스트리밍 재생은 어떻게 발전해왔는가

지금까지 우리는 서버와 전송 구조를 중심으로 살펴봤다.
이제는 시점을 바꿔서, 브라우저가 이 데이터를 어떻게 재생하는지를 이해해야 한다.

여기서 중요한 관점은 하나다.

스트리밍 기술은 단순히 포맷이 바뀐 것이 아니라
“재생을 누가 통제하느냐”가 계속 바뀌어 온 과정이다

이 흐름은 Flash → HTML5 video → MSE로 이어진다.

7.2 Flash 시대: 플러그인이 모든 것을 담당

초기 웹 스트리밍은 Flash가 중심이었다.

브라우저는 단순히 Flash Player를 실행해주는 역할만 하고,
실제 영상 재생과 스트리밍 처리는 Flash 내부에서 이루어졌다.

즉 구조는 이렇게 된다.

  • 브라우저 → Flash 실행
  • Flash → 서버와 통신 (RTMP 등)
  • Flash → 직접 재생

이 구조에서는 재생 제어권이 어디에 있는지가 명확하다.

모든 제어권은 어도비(Flash)에 있었다

Flash의 장점은 강력했다.
실시간 스트리밍도 가능했고, 플레이어를 자유롭게 만들 수 있었다.

하지만 단점도 명확했다.

  • 플러그인 설치 필요
  • 보안 취약
  • CPU / 배터리 소모 큼
  • 모바일 환경, 특히 iOS에서 지원되지 않음

특히 애플은 Flash를 아예 배제하면서 큰 변화를 만든다.

7.3 전환점: 애플의 선택과 HLS

애플은 iPhone에서 Flash를 지원하지 않기로 결정했다.
이건 단순한 기술 문제가 아니라 플랫폼의 주도권과 보안, 효율성을 고려한 전략적인 선택이었다.

Flash 대신 애플이 밀어붙인 것이 HLS다.

이 선택으로 스트리밍 방식이 바뀐다.

  • RTMP → HTTP 기반
  • 플러그인 → 브라우저 기본 기능

그리고 재생 구조도 바뀐다.

Flash 내부가 아니라, 브라우저가 직접 재생을 담당하게 된다

7.4 HTML5 video 시대: URL만 넘기면 재생

Flash 이후 등장한 것이 HTML5 video 태그다.

<video src="stream.m3u8"></video>

이 방식은 매우 단순하다.
개발자는 영상의 위치(URL)만 넘겨주면 된다.

그러면 브라우저가 내부적으로 다음을 처리한다.

  • m3u8 다운로드
  • Segment 목록 확인 및 순차적 다운로드
  • 내부 버퍼(Buffer) 관리 및 디코딩
  • 화면 렌더링

즉

브라우저가 다운로드부터 재생까지 모든 것을 처리한다

이 구조에서는 재생 제어권이 이렇게 바뀐다.

어도비 → 브라우저

이 방식은 표준 기반이고 모바일에서도 잘 동작했다.
하지만 새로운 한계가 생긴다.

  • 언제 데이터를 가져올지 제어 불가
  • buffer 크기 제어 불가
  • 지연 시간 제어 불가
  • Low Latency 구현 어려움

즉 개발자는 단순히

“이 영상 틀어줘”

라고 요청만 할 수 있고,
재생 알고리즘에는 개입할 수 없다.

7.5 Low Latency에서 발생한 문제

LL-HLS 구조에서는 상황이 달라진다.

데이터가 더 이상 “완성된 파일”로 오지 않는다.
작은 조각(chunk) 단위로 계속 도착한다.

이걸 제대로 재생하려면 필요하다.

  • 조각이 오면 바로 재생에 반영하고
  • buffer를 최소화하고
  • 지연을 계속 조절하는 것

하지만 HTML5 video 구조에서는 이게 불가능하다.

왜냐하면

브라우저가 “파일 단위”로 처리하기 때문이다

그래서 새로운 방식이 필요해진다.

7.6 MSE: 데이터를 직접 넣는 방식

MSE는 이 문제를 해결하기 위해 등장했다.

기존 방식과 가장 큰 차이는 이것이다.

URL을 넘기는 방식에서
바이너리 데이터를 직접 넘기는 방식으로 바뀐다

기존 HTML5 video 방식은 이렇게 동작한다.

  • 개발자 → URL 전달
  • 브라우저 → 알아서 다운로드 + 버퍼링 + 재생

MSE 방식은 이렇게 바뀐다.

  • JavaScript가 직접 데이터를 다운로드
  • 그 데이터를 buffer에 추가
  • 브라우저는 재생만 수행

즉 구조는 이렇게 바뀐다.

개발자가 데이터를 가져오고
브라우저는 그걸 재생만 한다

이걸 비유하면 이해가 쉽다.

기존 방식은

“이 주소에 있는 영상 틀어줘”

MSE 방식은

“영상 데이터를 내가 가져왔으니까
이걸 그대로 틀어줘”

이 변화가 의미하는 바는 크다.

재생 제어권이 개발자에게 넘어간다

7.7 MSE로 가능해진 것

이 구조 덕분에 가능해진 것들이다.

  • chunk 단위 데이터 즉시 반영
  • buffer 크기 직접 제어
  • 지연 시간 조절
  • 네트워크 상태 기반 화질 변경

즉

플레이어를 직접 만드는 수준의 제어가 가능해진다

7.8 재생 제어권의 변화 정리

지금까지 흐름을 정리하면 다음과 같다.

Flash 시대
→ 어도비가 재생을 통제

HTML5 video 시대
→ 브라우저가 재생을 통제

MSE 시대
→ 개발자가 재생을 통제

7.9 Safari는 왜 다른 구조를 가지는가

여기서 Safari가 자연스럽게 등장한다.

지금까지 흐름은 “개발자가 점점 더 많은 제어권을 가진다”는 방향이었다.
그런데 Safari는 이 흐름을 매우 늦게 수용했다.

이유는 애플의 철학에 있다.

애플은 HLS의 종주국으로서,
시스템 전체(AVFoundation)가 HLS 재생에 최적화되어 있다.
이들은 배터리 효율과 시스템 안정성을 위해
개발자가 하드웨어를 직접 제어하는 MSE 방식을 오랫동안 제한했다.

즉 구조가 이렇게 된다.

  • video 태그 → m3u8
  • Safari 내부 플레이어가 처리

이 구조에서는

재생 제어권이 여전히 브라우저 내부에 있다

다른 브라우저는

  • 네이티브 스트리밍 기능이 부족했고
  • 그래서 MSE 기반으로 발전했다

하지만 Safari는 이미 완성된 HLS 플레이어를 가지고 있었기 때문에
그 구조를 유지하게 된다.

7.10 실무에서 발생하는 차이

이 구조 차이는 실제 서비스에서 차이를 만든다.

Chrome / Edge는

  • MSE 기반
  • 개발자가 buffer / 지연 / 화질을 직접 제어

개발자가 버퍼를 2초로 강제하고 지연을 조절할 수 있다

Safari는

  • Native HLS 기반
  • 내부 로직에 따라 재생

개발자가 아무리 요청해도
iOS 시스템 플레이어가
“안정성을 위해 버퍼를 5초 이상 쌓겠다“라고 판단하면
개발자가 개입할 수 없다.

따라서

Safari는 “성능이 부족한 것”이 아니라,
“시스템이 제어권을 꽉 쥐고 놓아주지 않는 것”이다.
(참고: 최근 iOS 17부터는 Managed Media Source를 통해 이 제약이 점차 풀리고 있다.)

7.11 핵심 정리

이 장의 핵심은 다음과 같다.

  • 스트리밍은 URL 전달 방식에서 데이터 전달 방식으로 발전했다
  • MSE는 개발자가 재생을 직접 제어하는 구조다
  • Safari는 네이티브 HLS 구조를 고수해왔으며, 이로 인해 타 브라우저보다 레이턴시 제어가 까다롭다

한 문장으로 정리하면 이렇게 된다.

Low Latency는 “데이터를 어떻게 보내느냐”와
“누가 재생을 제어하느냐”가 함께 만들어낸 결과다