온라인 동영상 스트리밍은 어떻게 작동하나요?

온라인 동영상 스트리밍은 플레이어가 먼저 다운로드하는 작은 텍스트 매니페스트의 안내에 따라, 일반 HTTPS 위에서 동영상을 짧고 순차적으로 번호가 매겨진 세그먼트의 연속으로 기기에 전송합니다. 매니페스트는 사용 가능한 모든 화질 변형과 각 세그먼트의 URL을 나열합니다. 플레이어는 변형을 선택하고, 가까운 CDN 엣지에서 한 번에 몇 개씩 세그먼트를 가져오며, 하드웨어 가속으로 디코딩하고, 프레임을 화면에 그립니다. 페치 → 디코드 → 그리기 전체 루프는 동영상 내내 끊임없이 반복됩니다.

스트리밍과 다운로드의 차이는 무엇인가요?

다운로드는 시청 전에 전체 파일을 기기에 저장합니다. 스트리밍은 짧은 세그먼트를 재생 직전에 다운로드하고 다음 세그먼트가 전송 중이 되면 이전 것을 폐기합니다. 전체 파일을 보유하는 일은 없습니다. 또한 스트리밍은 플레이어가 서로 다른 변형의 세그먼트를 선택해 재생 중에 화질을 전환할 수 있게 하며, 세션이 종료되면 서비스가 즉시 전송을 중단할 수 있게 합니다. 다운로드된 파일은 영구적으로 오프라인에서 작동합니다. 스트리밍 세션은 바이트가 계속 도착하는 동안에만 작동합니다.

빠른 인터넷에서도 동영상이 가끔 버퍼링되는 이유는 무엇인가요?

버퍼링은 플레이어의 버퍼가 세그먼트가 도착하는 것보다 빨리 비워질 때마다 발생합니다. 빠른 피크 대역폭이 안정적인 처리량을 보장하지는 않습니다 — 피어링 지점의 혼잡, Wi-Fi 간섭, CDN 엣지의 캐시 미스가 각각 단일 세그먼트의 다운로드 시간을 그 길이를 넘어서까지 끌어올릴 수 있습니다. 인코드 사다리도 중요합니다. 서비스가 8Mbps 1080p 변형만 제공하고 회선이 잠깐 그 아래로 떨어지면 플레이어는 720p로 내려가거나 기다려야 합니다. 버퍼링은 플레이어가 다시 채울 시간을 요청하는 것이지, 회선 속도에 대한 판결이 아닙니다.

스트리밍 동영상을 오른쪽 클릭으로 저장할 수 없는 이유는 무엇인가요?

저장할 단일 파일이 없기 때문입니다. 페이지는 플레이어에게 매니페스트 URL — 보통 .m3u8 또는 .mpd — 을 전달하며, 그 파일은 세그먼트 URL의 목록일 뿐입니다. 오른쪽 클릭은 동영상이 아니라 매니페스트를 저장합니다. 시청 가능한 파일을 재구성하려면 모든 세그먼트를 순서대로 가져오고, AES-128이나 DRM으로 래핑된 키로 암호화된 것을 복호화하며, 오디오와 동영상 스트림을 하나의 MP4나 MKV 컨테이너로 리먹스해야 합니다. 그것은 브라우저가 기본으로 제공하지 않는 다단계 파이프라인입니다.

스트리밍에는 특별한 서버가 필요한가요?

아닙니다. 최신 적응형 스트리밍은 완전히 HTTPS 위에서 동작합니다 — HTML 페이지와 JPEG을 제공하는 것과 동일한 프로토콜입니다. 세그먼트와 매니페스트는 다른 정적 자산처럼 엣지에서 캐시 가능한 CDN상의 파일일 뿐입니다. RTMP, RTSP, MMS 같은 구형 프로토콜은 전용 서버와 포트가 필요했지만, HLS와 DASH는 의도적으로 일반 HTTP를 사용해 방화벽을 통과하고, 기존 CDN 인프라에서 확장되며, HTTP/2와 HTTP/3의 개선을 프로토콜 변경 없이 누릴 수 있도록 설계되었습니다.

라이브 스트리밍과 주문형 비디오(VOD)의 차이는 무엇인가요?

둘 다 동일한 프로토콜과 세그먼트 형식을 사용합니다. 차이는 매니페스트에 있습니다. VOD 매니페스트는 처음부터 끝까지의 모든 세그먼트를 나열하고 스트림이 유한함을 선언합니다 — HLS는 이를 위해 EXT-X-ENDLIST 태그를 사용합니다. 라이브 매니페스트는 지금까지 게시된 세그먼트만 나열하고 종료 표시를 생략하며, 플레이어가 새 항목을 발견하기 위해 몇 초마다 다시 가져옵니다. 라이브 스트림의 지연은 전통적인 HLS의 30초부터 저지연 HLS나 저지연 DASH의 3초 미만까지 다양합니다.

동영상 화질은 어떻게 자동으로 전환되나요?

최신 스트림은 동일한 콘텐츠를 여러 비트레이트로 — 1080p, 720p, 480p 등 — 각각 별개의 세그먼트 집합으로 전송합니다. 매 세그먼트 다운로드 후, 플레이어는 다운로드에 걸린 시간과 그 사이에 소모된 실제 시간을 비교해 유효 대역폭을 계산합니다. 추세가 하락하면 다음 세그먼트는 더 낮은 변형에서 요청합니다. 상승하고 버퍼가 건강하면 다시 올라갑니다. 변형 간에 세그먼트 경계가 정렬되어 있으므로 전환은 세그먼트 사이에서 깔끔하게 일어납니다.

스트리밍은 합법인가요?

시청 권한이 있는 스트림 — 구독한 서비스, 자유 라이선스 동영상, 본인의 방송 — 을 시청하는 것은 명백히 합법입니다. 스트림 다운로드는 더 미묘합니다. 본인 소유 콘텐츠나 자유 라이선스 자료를 저장하는 것은 일반적으로 문제가 없습니다. DRM 보호 상용 스트림을 다운로드하는 것은 일반적으로 플랫폼 이용 약관에 위배되며 미국의 DMCA §1201 같은 반(反)우회 법률을 발동시킬 수 있습니다. 항상 해당 관할권의 법률과 가입 시 동의한 약관을 확인하십시오.

온라인 동영상은 실제로 어떻게 재생되는가: 클릭에서 프레임까지

YouTube 동영상에서 재생 버튼을 누르면 1초 안에 무언가가 화면에 나타납니다. 그 1초 동안 무슨 일이 일어났을까요? 정말 놀라울 정도로 많은 일이 있었습니다. 동영상은 기기에 없고, 시청 중인 파일은 어디에도 단일 파일로 존재하지 않으며, 화면을 채우는 바이트는 심지어 YouTube의 서버에서 오지도 않았습니다. 사용자의 집과 같은 대도시권 어딘가의 캐시에서 온 것입니다 — 사용자나 다른 천 명의 시청자가 바로 그 영화의 바로 그 슬라이스를 요청할 경우를 대비해 만들어 둔 사본입니다.

순서는 다음과 같습니다. 브라우저가 동영상을 설명하는 작은 텍스트 파일을 건네주는 서버와 통신합니다. 플레이어는 그 파일을 읽고 여러 화질 옵션 중 하나를 선택한 뒤, CDN에 짧은 오디오 및 동영상 청크 — 일반적으로 각 2~6초 — 를 요청하기 시작합니다. 청크는 일반 웹 페이지를 제공하는 동일한 HTTPS 연결을 통해 도착합니다. 플레이어는 사용자의 스마트폰이나 노트북에 이미 있는 하드웨어로 이를 디코딩하고 프레임을 화면에 그립니다. 첫 청크를 시청하는 동안 플레이어는 이미 다음 세 개를 가져오고 있습니다. Wi-Fi가 흔들리면 다음 청크의 더 낮은 화질 버전으로 조용히 떨어뜨려 재생이 멈추지 않게 합니다. 매니페스트 페치, 세그먼트 페치, 디코드, 그리기, 측정, 적응 — 이 전체 루프가 웹의 모든 Netflix, YouTube, Twitch, Disney+, TikTok 동영상 뒤에서 보이지 않게 돌아가고 있습니다.

이 글은 스트리밍 시리즈의 기둥 글입니다. 한쪽 끝의 카메라부터 다른 쪽 끝의 화면 위 프레임까지, 전체 파이프라인을 군더더기 없이 짚어보겠습니다. 기술 계층을 정확하게 다룰 만큼 깊이 있지만 전문 용어에 빠지지는 않게 다루고, 어떤 서비스가 이 계층들의 어떤 조합을 사용하는지 살펴본 뒤, 많은 독자가 처음 이 글을 찾은 실질적인 질문 — 동영상을 다 봤을 때 그 사본을 보관할 수 있는가 — 으로 마무리합니다.

동영상 스트리밍은 HTTPS 위에서 가져온, 짧고 순차적으로 번호가 매겨진 파일 세그먼트의 연속으로 동영상을 기기에 전달하는 것입니다. 작은 매니페스트 파일의 안내에 따라 즉석에서 디코딩되고, 다음 세그먼트가 전송 중이 되는 순간 폐기됩니다.

핵심 요약 {#key-takeaways}

스트리밍은 특별한 프로토콜이 아닙니다 — 일반 HTTP 위에 영리하게 얹은 패턴입니다. 매니페스트와 세그먼트는 CDN상의 파일일 뿐입니다.
“시청”하는 동영상은 단일 파일로 존재하지 않습니다. 매니페스트와 몇백 개의 작은 세그먼트로부터 플레이어 안에서 재구성됩니다.
인코딩은 동일 콘텐츠의 여러 비트레이트 변형을 만듭니다. 플레이어가 실시간 대역폭 측정을 바탕으로 그중에서 선택합니다.
대부분의 세그먼트는 원본 서버가 아니라 가까운 CDN 엣지에서 옵니다. 엣지 캐시가 스트리밍을 즉각적으로 느껴지게 만드는 이유입니다.
적응형 비트레이트 스트리밍이 재생 중간에 화질이 조용히 바뀌는 이유입니다 — 플레이어는 버퍼를 건강하게 유지하기 위해 세그먼트 사이에서 변형을 전환합니다.
세 가지 암호화 계층이 독립적으로 쌓일 수 있습니다: 전송용 HTTPS, 세그먼트 콘텐츠용 AES-128, 라이선스 게이팅 상용 스트림용 DRM.
HLS와 DASH가 지배합니다. HLS는 Apple의 사양(RFC 8216, .m3u8), DASH는 ISO/IEC 표준(23009-1, .mpd XML)입니다. 대부분의 주요 서비스는 둘 다 제공합니다.
스트림을 저장한다는 것은 매니페스트를 파싱하고, 모든 세그먼트를 가져오고, 암호화를 처리하고, 리먹스하는 것을 의미합니다 — 단순한 오른쪽 클릭과 다른 이름으로 저장이 아닙니다.

간단한 설명

전 세계 1억 명의 시청자에게 장편 영화를 배송한다고 상상해보십시오. 영화는 거대합니다 — 2시간짜리 1080p H.264 영화 한 편이 약 4~8 기가바이트입니다 — 그리고 시청자들은 기가비트 광케이블부터 흔들리는 4G가 깔린 달리는 기차 안까지 모든 종류의 연결을 씁니다. 동일한 거대한 파일을 모두에게 보낼 수는 없습니다. 올바른 파일조차 보낼 수 없습니다. 기차 시청자는 낮은 비트레이트 사본이 필요하고, 광케이블 시청자는 높은 비트레이트를 원하며, 기차 시청자가 영화 중간에 Wi-Fi로 전환하면 다시 시작하지 않고 등급을 올려야 합니다.

업계가 정착한 패턴은 너무 단순해서 김이 빠질 정도입니다. 영화를 수백 개의 짧은 클립으로 자르고, 각 클립을 여러 화질 수준으로 인코딩하고, 모든 클립을 전 세계 서버에 저장하고, 시청자의 플레이어가 다음 어떤 클립을 재생할지 결정하게 하는 것입니다. 그게 전부입니다. “스트리밍”이라 부르는 것은 본질적으로 폴더 안의 파일을 특정한 순서로 웹에서 가져오는 것입니다.

엔드 투 엔드 라이프사이클은 다음과 같습니다.

카메라나 렌더링 엔진이 원시 프레임을 캡처합니다. 라이브의 경우 실제 카메라입니다. VOD의 경우 스튜디오가 넘기는 완성된 마스터 파일입니다.
인코더가 원시 프레임을 코덱으로 압축합니다 — 동영상은 H.264, H.265, AV1, 오디오는 AAC 또는 Opus. 인코더는 보통 하나의 입력에서 서로 다른 비트레이트의 여러 출력을 만듭니다.
패키저가 인코딩된 스트림을 짧은 세그먼트로 자르고 매니페스트를 작성합니다. 각 변형은 자체 세그먼트 폴더와 변형별 매니페스트가 되며, 최상위 마스터 매니페스트에 변형들이 나열됩니다.
세그먼트와 매니페스트가 원본에 업로드되어 CDN으로 복제됩니다. Cloudflare, Akamai, Fastly, AWS CloudFront — 어떤 CDN을 사용하든 — 가 전 세계 엣지 노드에 파일을 캐시합니다.
재생 버튼을 누릅니다. 플레이어가 매니페스트를 다운로드하고, 변형을 고르고, 가까운 CDN 엣지에서 첫 세그먼트들을 가져와 디코딩을 시작합니다.
플레이어가 각 세그먼트를 디코딩하고 프레임을 화면에 그립니다. 시청 중인 지점보다 몇 초 앞선 버퍼를 유지하면서.
플레이어가 세그먼트가 도착하는 동안 대역폭을 측정하고 세그먼트 사이에서 변형을 조정해 실시간 연결 상태에 화질을 맞춥니다.

이것이 전체 파이프라인입니다. 다른 일은 일어나지 않습니다 — 특수 서버도, 회선의 독점 프로토콜도, 마법도 없습니다. 모든 단계는 충분히 끈기가 있다면 스크립트를 작성할 수 있는 도구와 형식을 씁니다. 영리함은 설계에 있습니다. 각 세그먼트는 그 사이에서 변형을 전환할 수 있을 만큼 짧고, 매니페스트는 왕복이 빠르도록 작으며, 세그먼트는 다른 정적 파일처럼 캐시되고, 플레이어는 이미 Blu-ray와 FaceTime 통화를 디코딩하는 같은 하드웨어 위에서 동작합니다. 스트리밍 웹 전체가 HTTPS, 파일, 타이밍으로 만들어져 있습니다. 다음에 다룰 프로토콜과 코덱은 이 조각들이 대규모로 상호 운용되게 하는 규약일 뿐입니다.

스트리밍 동영상은 실제로 어떻게 작동하나요

여기가 기둥 글의 기술적 핵심입니다. 파이프라인 전체를 엔드 투 엔드로 짚어보겠습니다. 다 읽고 나면 어떤 스트리밍 사이트의 네트워크 탭을 봐도 각 요청이 어느 단계에 속하는지 식별할 수 있을 것입니다.

Camera → Encoder → Packager → Origin → CDN edge → Player → Decoder → Screen

그 다이어그램이 전체 경로입니다. 아래에서 다룰 모든 개념 — 비트레이트 사다리, 매니페스트, 세그먼트, ABR, 암호화 — 은 그 화살표 위 어딘가에 들어맞습니다.

원본과 인코딩

모든 것은 원시 동영상에서 시작합니다. 라이브 방송에서는 카메라(게임 스트리밍의 경우 화면 캡처)가 예를 들어 1920×1080, 초당 60 프레임으로 비압축 프레임을 생성합니다. 비압축으로는 대략 초당 3 기가비트입니다. 누구도 원시 동영상을 공용 인터넷에 보내지 않습니다. 첫 번째 작업은 압축입니다.

동영상 인코더는 시간적 중복성(대부분의 픽셀이 지난 프레임의 픽셀과 닮음)과 공간적 중복성(이미지 대부분의 영역이 이웃과 닮음)을 활용해 원시 프레임을 압축된 비트스트림으로 변환합니다. 2026년 현재 지배적인 코덱은 다음과 같습니다.

H.264 (AVC) — 2003년 표준화. 오래되었지만 인터넷에서 가장 폭넓게 지원되는 코덱입니다. 지난 15년간 만들어진 모든 기기가 하드웨어 디코딩할 수 있습니다.
H.265 (HEVC) — 동일 화질에서 H.264보다 약 50% 더 효율적입니다. 로열티 부담이 있어 웹 채택이 느렸지만, 스마트폰, 스마트 TV, Apple 플랫폼에서는 보편적입니다.
AV1 — 로열티 무료, 개방형, HEVC보다 약간 더 효율적입니다. YouTube, Netflix, Vimeo가 주요 AV1 게시자입니다. 2025~2026년 기준 하드웨어 디코드 지원이 마침내 거의 모든 곳에 도달했습니다.
AAC 및 Opus — 오디오 코덱입니다. HLS에서 AAC는 필수입니다. Opus는 WebRTC를 지배하고 DASH에서도 점점 흔해지고 있습니다.

동일한 콘텐츠는 거의 항상 여러 비트레이트 변형으로 인코딩됩니다. 일반적인 인코드 사다리는 다음과 같이 생겼습니다.

변형	해상도	비트레이트	코덱
1080p	1920×1080	5.0 Mbps	H.264 high
720p	1280×720	3.0 Mbps	H.264 main
480p	854×480	1.5 Mbps	H.264 main
360p	640×360	0.8 Mbps	H.264 baseline
오디오	—	128 kbps	AAC-LC

그 표의 각 행은 동일한 소스의 별개 인코드입니다. 시간적으로 정렬되어 있어서 플레이어가 디코더를 재시작하지 않고 동일 벽시계 순간에 그들 사이에서 전환할 수 있습니다. 각 변형 안에 실제로 무엇이 들어 있는지 — 코덱 대 컨테이너 — 에 관한 자세한 내용은 MP4 같은 컨테이너와 H.264 같은 코덱 글을 참조하십시오.

패키징 — 세그먼트와 매니페스트

인코딩 다음은 패키징입니다. 각 변형의 비트스트림을 세그먼트라 부르는 짧은 청크로 자르고, 그 목록을 담은 매니페스트를 작성합니다.

세그먼트는 일반적으로 동영상과 오디오 각각 2~10초 분량입니다. 키프레임 경계(비트스트림의 I-프레임)에서 잘려서 플레이어가 어떤 세그먼트의 시작에서도 디코딩을 시작할 수 있게 합니다. 매니페스트가 EXT-X-INDEPENDENT-SEGMENTS(HLS) 또는 DASH의 그에 상응하는 항목을 선언하면 모든 세그먼트는 단독으로 재생 가능함이 보장됩니다. 그 선언이 없으면 일부 세그먼트는 이전 세그먼트가 운반하는 데이터에 의존합니다.

세그먼트 컨테이너 형식은 다양합니다.

MPEG-TS (.ts) — 레거시 HLS. 원래 1990년대 위성/케이블 방송 형식으로 비트 오류에 강건합니다. 여전히 사용되지만 단계적으로 폐기되는 중입니다.
Fragmented MP4 (.m4s, 때로 .mp4) — 최신 HLS와 모든 DASH. 일반 파일과 동일한 MP4 컨테이너이지만, 자체 헤더를 가진 프래그먼트로 잘려서 각각이 독립적으로 재생 가능합니다.
CMAF — Common Media Application Format(ISO/IEC 23000-19)은 .ts와 fMP4의 병합이 아니라, fragmented-MP4 프로파일이자 패키징 제약입니다. 동일한 fMP4 파일 집합이 HLS .m3u8과 DASH .mpd 모두에서 참조될 수 있도록 fMP4 세그먼트가 어떻게 구성되어야 하는지를 정확히 정의합니다. 최신 서비스는 프로토콜별로 바이트를 중복하지 않고 CMAF를 제공합니다. 레거시 .ts 세그먼트는 fMP4를 받아들이지 못하는 구형 HLS 클라이언트를 위해 여전히 함께 존재합니다.

매니페스트 자체에는 두 가지 형식이 있습니다.

HLS 매니페스트는 .m3u8 텍스트 파일입니다. 마스터 플레이리스트는 변형과 그 대역폭을 나열하고, 각 변형은 세그먼트 URL과 길이를 나열하는 미디어 플레이리스트를 가집니다. 전체 구조에 대해서는 m3u8 파일이 실제로 무엇을 담고 있는가를 참조하십시오.
DASH 매니페스트는 .mpd XML 파일입니다. 하나의 파일이 전체 프레젠테이션을 — adaptation set, representation, segment timeline, BaseURL을 — 트리 구조로 기술합니다. HLS와의 비교는 DASH와 그 .mpd 매니페스트를 참조하십시오.

두 설계 모두 같은 일을 합니다. 매니페스트는 어떤 변형이 존재하는지, 각 세그먼트가 어디 있는지, 각 세그먼트가 얼마나 긴지 플레이어에게 알립니다. 나머지는 모두 플레이어의 몫입니다.

CDN 배포

세그먼트와 매니페스트가 파일로 존재하게 되면, 스트리밍 서비스는 이를 원본 서버 — 보통 S3나 R2 같은 객체 저장소 — 에 업로드하고 콘텐츠 전송 네트워크가 전 세계 엣지 노드에 복제하게 합니다. 네트워크 요청에서 볼 수 있는 CDN으로는 Akamai, Cloudflare, Fastly, AWS CloudFront, Google의 엣지 네트워크, 그리고 Netflix(Open Connect)와 YouTube가 ISP 내부에서 운영하는 사설 CDN이 있습니다.

CDN이 스트리밍에 그토록 중요한 이유는 캐시 가능성입니다. 세그먼트는 URL이 바뀌지 않는 정적 파일입니다. 한 지역의 첫 시청자가 원본에서 세그먼트를 가져오면 엣지가 이를 캐시하고, 그 지역의 모든 시청자는 그 후 한두 시간 동안 수십 밀리초 거리의 서버에서 받아갑니다. 인기 있는 YouTube 동영상의 경우 세그먼트 요청의 대다수는 YouTube의 원본을 절대 건드리지 않습니다 — 사용자의 ISP 안에 물리적으로 자리한 캐시 박스에서 제공됩니다.

이것이 또한 스트리밍이 그렇게 잘 확장되는 이유입니다. 도쿄에서 동시 시청자 100만 명을 추가해도 캘리포니아에 100만 번의 왕복이 추가되지 않습니다 — 이미 그 파일을 가지고 있는 도쿄 엣지 노드에 부하가 추가될 뿐입니다. 2010년 이전의 어떤 스트리밍 프로토콜도 허용하지 않았던 방식으로 수학이 관대합니다.

플레이어 워크플로우

이제 다시 사용자의 기기로 돌아옵니다. 브라우저가 페이지를 로드하고, 페이지가 JavaScript 플레이어(보통 shaka-player, hls.js, video.js, 또는 그 위에 얹은 벤더의 커스텀 빌드)를 부팅하고, 플레이어가 페이지의 <video> 요소에 재생 시작을 요청합니다. 거기부터 플레이어는 빡빡한 루프를 돕니다.

매니페스트를 가져옵니다. HTTPS GET 한 번. 응답은 수 킬로바이트의 텍스트입니다.
매니페스트를 파싱하고 초기 변형을 선택합니다. 플레이어는 대역폭 추정치(최근 이력이나 기기의 네트워크 정보로 초기화), 기기 화면 해상도, 그리고 첫 세그먼트가 멈추지 않도록 안전 마진을 기반으로 선택합니다.
첫 몇 세그먼트를 가져옵니다. 최신 플레이어는 단일 HTTP/2 또는 HTTP/3 연결 위에서 이를 병렬화합니다. 세그먼트가 동시에 도착합니다.
세그먼트 바이트를 브라우저의 Media Source Extensions 버퍼로 푸시합니다. MSE는 JavaScript가 <video> 요소에 동영상 데이터를 프로그래밍 방식으로 공급할 수 있게 해주는 W3C API입니다. 브라우저의 내장 디코더가 거기서부터 처리합니다.
디코딩하고 그립니다. 디코더 — 지난 10년간 만들어진 거의 모든 기기에서 하드웨어 가속 — 가 압축된 프레임을 원시 픽셀로 변환하고, GPU가 그것을 동영상의 프레임 레이트로 그립니다.
버퍼를 가득 유지합니다. 사용자가 세그먼트 N을 보는 동안 플레이어는 세그먼트 N+1, N+2, N+3을 가져오고 있습니다.
매 세그먼트마다 재평가합니다. 매 다운로드 후 플레이어는 연결이 얼마나 빠른지에 대한 신선한 데이터를 갖습니다. 그것으로 다음 세그먼트의 변형을 전환할지 결정합니다.

대부분의 플레이어 코드는 부기(bookkeeping)입니다. 버퍼 건강 추적, 실패한 세그먼트 페치 재시도, 탐색과 일시 정지 처리, 광고 세그먼트 스플라이싱, 오디오 트랙 전환, 자막 렌더링. 스트리밍 부분은 개념적으로 작습니다 — 페치, 디코드, 반복 — 그리고 엔지니어링의 복잡성은 그 주변의 모든 엣지 케이스에 있습니다.

적응형 비트레이트 (ABR)

적응형 비트레이트는 이 전체 구성을 쓸 만하게 만드는 기능입니다. ABR이 없다면 플레이어는 화질을 하나 골라 고수하다가 연결이 그것을 지탱하지 못하는 순간 다시 버퍼링했을 것입니다. ABR이 있으면 플레이어는 매 세그먼트마다 대역폭을 측정하고 진행 중에 변형을 전환합니다.

기본 루프는 다음과 같이 생겼습니다. 매 세그먼트 다운로드 후 플레이어는 유효 대역폭을 계산합니다. 세그먼트 크기를 다운로드 시간으로 나눈 값입니다. 이를 최근 측정치의 이동 평균과 비교합니다. 대역폭이 하락 추세이면 다음 세그먼트 요청은 더 낮은 비트레이트 변형으로 갑니다. 대역폭이 상승 추세이고 버퍼가 건강하면 플레이어는 다시 올라갑니다. 결정은 세그먼트 사이에서 이루어지고, 세그먼트 중간에는 절대 이루어지지 않아 전환이 매끄럽습니다.

실제 ABR 구현은 더 미묘합니다. 버퍼 점유율을 추적하고(건강한 버퍼는 더 높은 변형을 시도할 수 있고, 비워지는 버퍼는 빠르게 내려가야 함), 화면 해상도를 고려하며(720p 노트북에 4K를 스트리밍할 이유가 없음), 변형 사이의 진동을 피하기 위해 예측 모델 — 이동 평균, 저역 통과 필터, 때로는 머신러닝 추정기 — 을 사용합니다. 2026년 현재 지배적인 ABR 알고리즘 두 가지는 BOLA(버퍼 기반)와 MPC(모델 예측 제어)이며, 둘 다 오픈소스 플레이어에 등장합니다. 전체 분석은 모든 최신 플레이어 안의 ABR 로직을 참조하십시오.

사용자가 체감하는 결론은 이렇습니다. 화질을 직접 선택할 필요가 없습니다. 플레이어가 매초 그것을 합니다. 그리고 전환은 보통 보이지 않습니다. 보일 때 — Netflix 화면에서 갑작스러운 부드러움을 알아챌 때 — 그것은 ABR이 재생을 지속하기 위해 더 낮은 변형을 고른 것입니다.

암호화: 자주 혼동되는 세 가지 계층

스트리밍의 암호화는 사람들이 생각하는 것보다 더 많고, 세 가지 독립적인 계층이 일상적으로 뭉뚱그려집니다. 같은 것이 아닙니다.

HTTPS = 전송 보안. 모든 현대 스트림은 TLS 위에서 제공됩니다. 이는 네트워크상의 도청자로부터 바이트를 보호합니다. ISP, Wi-Fi 공격자, 기업 프록시는 그들 옆을 흘러가는 것을 읽을 수 없습니다. HTTPS는 수신 브라우저가 바이트를 읽는 것을 막지는 않습니다 — 엄격히 회선에 관한 것입니다.

AES-128 세그먼트 암호화 = 콘텐츠 계층. HLS와 DASH 모두 CBC 또는 CTR 모드의 AES-128로 세그먼트 자체를 암호화하는 것을 지원합니다. 매니페스트는 키 URL을 운반하고, 플레이어는 HTTPS로 키를 가져와 디코딩 전에 각 세그먼트를 복호화합니다. 이는 콘텐츠 계층 보호입니다. 누군가 바이트를 획득하더라도 무의미하게 만들지만, 키 URL 자체가 문입니다. 키 URL에 도달할 수 있는 자라면 세그먼트를 복호화할 수 있습니다. 많은 라이브 및 크리에이터 플랫폼이 기본 보호 계층으로 AES-128 세그먼트 암호화를 사용합니다.

DRM = 라이선스 서버 게이팅, 하드웨어 기반 복호화. Widevine(Google), FairPlay(Apple), PlayReady(Microsoft)는 세그먼트 암호화 위에 정책 계층을 얹습니다. 세그먼트는 여전히 AES 암호화되어 있지만(MPEG Common Encryption, ISO/IEC 23001-7 아래에서), 콘텐츠 키는 기기의 신뢰 실행 환경만이 풀 수 있도록 래핑됩니다. 라이선스 서버는 구독, 기기 신뢰, 지역을 확인한 후 라이선스를 발급합니다. 복호화는 하드웨어 기반 보안 모듈에서 이루어집니다 — GPU가 복호화된 프레임을 애플리케이션 메모리를 거치지 않고 직접 받습니다. 이것이 Netflix, Disney+, Apple TV+, 대부분의 유료 스트리밍을 보호하는 것입니다. 자세한 내용은 Widevine과 FairPlay가 프리미엄 스트림을 어떻게 게이팅하는지를 참조하십시오.

이 계층들은 쌓입니다. 프리미엄 Netflix 스트림은 전송용 HTTPS, CENC 아래 암호화된 CMAF 세그먼트, 라이선스 게이팅 키 전달용 Widevine 또는 FairPlay를 사용합니다. Twitch 라이브 스트림은 HTTPS만 사용합니다. 유료 강의 플랫폼은 HTTPS와 AES-128 세그먼트 암호화를 함께 사용하지만 DRM은 쓰지 않을 수 있습니다. 어떤 계층이 작동 중인지 아는 것은 바이트에 접근하기 위한 실제 기술적 장벽이 무엇인지, 그리고 합법적 사용의 경계가 어디 있는지 알려줍니다.

암호화되지 않은 스트림조차 저장하려면 그 모든 프로토콜을 올바른 순서로, 플레이어가 조용히 처리하는 엣지 케이스까지 다루며 말할 수 있어야 합니다. VidMost는 그 작업을 백그라운드에서 — 매니페스트 파싱, 세그먼트 페치, AES 처리, 내장 Widevine L3를 통한 DRM, 컨테이너 리먹스 — 수행하도록 만들어졌습니다. 그래서 사용자가 보는 단계는 URL을 붙여넣고 MP4를 받는 것입니다.

실제 세계에서 어디서 볼 수 있나요

위의 파이프라인은 본질적으로 2026년의 모든 상용 스트리밍 서비스를 설명합니다. 차이는 각 서비스가 어떤 프로토콜, 코덱, DRM을 선택하는지와 사용자의 기기와 어떻게 협상하는지에 있습니다.

YouTube. 웹과 Android의 주 프로토콜은 MPEG-DASH이며, Safari, iOS, AirPlay, 대부분의 스마트 TV에는 HLS가 제공됩니다. 거의 모든 콘텐츠는 CMAF입니다 — 하나의 fMP4 세그먼트 집합이 두 매니페스트 모두에 사용됩니다. 코덱은 호환성을 위한 H.264, 대부분의 재생을 위한 VP9, 지원 기기의 고해상도 스트림용 AV1입니다. 영화/TV 대여에는 Widevine과 FairPlay DRM이 사용되며, 사용자 업로드 동영상은 비암호화입니다.
Netflix, Disney+, Apple TV+, HBO Max, Prime Video. 모두 클라이언트에 따라 HLS와 DASH를 혼합 사용하며, 공통 세그먼트 형식으로 CMAF를 씁니다. DRM은 필수입니다 — 기기가 선택한 Widevine, FairPlay, 또는 PlayReady. 코덱은 H.264, H.265, AV1, 그리고 Dolby Vision/Atmos 오버레이를 포함합니다. 라이선스 서버는 매 재생마다 지역, 구독, 기기 신뢰를 강제합니다. Netflix는 많은 ISP 안에 자체 CDN(Open Connect)을 운영합니다.
Twitch. HLS만 사용하며, .ts 세그먼트가 CMAF와 나란히 여전히 흔합니다. 라이브 스트림은 저지연 변형에서 2~~5초 지연, 표준에서 15~~30초 지연을 보입니다. 세그먼트는 비암호화입니다 — Twitch의 보호 모델은 콘텐츠 암호화가 아니라 신원 및 계정 수준입니다.
Bigo Live, OnlyFans 라이브, Chaturbate, Fansly. HLS 기반 라이브 스트리밍, 일반적으로 비암호화 세그먼트와 저지연을 위한 짧은(2초) 청크. 브라우저 측 재생은 hls.js나 Safari의 네이티브 HLS 지원을 사용합니다.
Vimeo, Mux, Cloudflare Stream, JW Player. 호스팅 동영상 플랫폼들. 업로드를 HLS와 DASH 둘 다로 자동 패키징하고 자체 CDN으로 전달합니다. Cloudflare Stream은 CMAF를 제공합니다. Mux는 기본값이 HLS입니다. DRM은 유료 플랜에서 선택 사항입니다.
스포츠와 뉴스 — ESPN, DAZN, BBC iPlayer, Sling TV. DRM이 적용된 HLS 또는 DASH, 종종 Widevine + FairPlay + PlayReady가 함께 패키징되어 동일한 인코딩된 세그먼트가 모든 기기에 제공됩니다. 저지연 HLS(LL-HLS)가 이쪽의 추세입니다 — 한때 방송보다 30초 늦었던 라이브 이벤트의 3초 미만 지연.
TikTok, Instagram Reels, YouTube Shorts. 짧은 형식 동영상은 가장 작은 클립에 MP4 프로그레시브 다운로드를, 1분 이상에는 HLS나 DASH를 사용합니다. 장편 서비스와 동일한 CDN 및 코덱 선택.

표면은 다르지만 같은 기계 장치입니다. 이야기는 변형 있는 반복입니다. 모든 서비스가 매니페스트 형식, 코덱 사다리, DRM 조합을 고른 다음, 수십억 시청자에게 동일한 페치-디코드-그리기 루프를 돌립니다.

동영상을 저장하고 싶다면 이것이 의미하는 바

파이프라인을 알면 한 가지 실용적 사실이 명백해집니다. 저장할 단일 파일이 없다는 것입니다. “시청”하는 동영상은 매니페스트와 몇백 개의 작은 세그먼트로부터 플레이어가 실시간으로 재구성한 것이며, 진행 중에 디코딩되고, 다음 것이 도착하면 폐기됩니다. 브라우저의 “다른 이름으로 저장”은 매니페스트를 가져옵니다 — 동영상 바이트가 전혀 들어있지 않은 작은 텍스트 파일입니다.

시청 가능한 파일까지의 수동 경로는 길습니다. 매니페스트(HLS .m3u8 또는 DASH .mpd)를 가져와 파싱합니다. 올바른 변형을 고릅니다 — 보통 저장 공간이 흡수할 수 있는 가장 높은 대역폭. 모든 세그먼트 URL을 열거합니다. 서명된 URL이 만료되기 전에 모두 가져옵니다(6초 세그먼트의 30분 동영상이면 300개 이상의 요청). EXT-X-KEY가 있으면 AES-128 키를 가져와 각 세그먼트를 복호화합니다. 스트림이 DRM 보호이면, 라이선스를 발급할 수 있는 CDM 없이는 이것 중 어느 것도 작동하지 않습니다 — 그것이 있다 해도 복호화된 바이트는 보안 모듈을 결코 떠나지 않습니다. 일반 세그먼트를 확보하면 오디오와 동영상을 하나의 MP4 또는 MKV 컨테이너로 리먹스합니다. 변형 선택이 옳기를 바랍니다. 그렇지 않으면 다른 것으로 다시 시작합니다.

올바른 도구는 그 파이프라인을 사용자의 단일 행동으로 압축합니다. VidMost는 HLS와 DASH 매니페스트를 파싱하고, 사용 가능한 최고 화질 변형을 선택하며, 브라우저가 이미 통신 중이던 동일한 CDN에서 세그먼트를 병렬로 다운로드하고, AES-128 세그먼트 암호화를 자동으로 처리하며, L3 재생이 가능한 곳에서 DRM 보호 스트림을 위한 Widevine L3를 지원합니다(화질은 서비스와 DRM 수준에 의해 제한될 수 있으며, 프리미엄 플랫폼은 일반적으로 L3를 480p~720p로 제한합니다). 그리고 모든 것을 어떤 미디어 플레이어에서도 재생할 수 있는 깔끔한 MP4로 리먹스합니다. 프로토콜 계층이 사라집니다. URL을 붙여넣고, 파일을 받습니다.

시청할 적법한 권리가 있는 콘텐츠 — 비용을 지불한 강의, 보관하고 싶은 라이브스트림, 본인의 방송, 자유 라이선스 동영상 — 의 경우, 그것이 전체 워크플로우입니다. 이 글이 설명하는 파이프라인은 그 도구가 사용자를 대신해 헤쳐 나가도록 만들어진 것입니다.

흔한 함정과 오해

스트리밍에 관한 한 줌의 믿음이 반복해서 등장합니다. 바로잡을 가치가 있습니다.

“스트리밍은 특수 프로토콜을 사용한다.” 그렇지 않습니다. 최신 적응형 스트리밍은 일반 HTTPS 위에서 동작합니다 — HTML과 JPEG을 제공하는 동일한 프로토콜입니다. 매니페스트와 세그먼트는 CDN상의 정적 파일입니다. HLS나 DASH의 “프로토콜”은 그 파일이 무엇을 담는지에 관한 규약일 뿐입니다.
“내가 보는 동안 파일이 다운로드되고 있다.” 정확히는 아닙니다. 세그먼트는 재생 직전에 다운로드되고 다음 것이 전송 중이 되면 폐기됩니다. 기기는 동영상 전체를 보유하지 않습니다. 이것이 “세션 중단”이 효과적이고 바이트가 멈추는 순간 스트리밍 세션이 깨지는 이유입니다.
“높은 대역폭은 더 좋은 화질이다.” 대역폭이 안정적인 경우에만요. 10초 동안 2Mbps로 떨어지는 100Mbps 회선은 꾸준한 8Mbps 연결보다 나쁜 경험을 줍니다. 인코드 사다리도 한계를 정합니다 — 최고 변형이 5Mbps이면 그 이상의 어떤 대역폭도 더 나은 화질을 사주지 않습니다.
“버퍼링은 인터넷이 느리다는 뜻이다.” 때로는 그렇습니다. 그만큼 자주, 인코드 사다리가 너무 듬성하거나(현재 대역폭에 맞는 변형이 없음), CDN 엣지가 캐시 미스를 냈거나, 피어링 혼잡이거나, 플레이어의 ABR 알고리즘이 반응이 느린 것입니다. 버퍼링은 플레이어가 시간을 요청하는 것 — 회선 속도에 대한 결정적 판결이 아닙니다.
“DRM은 암호화와 같다.” 아닙니다. 암호화는 수학적 연산입니다 — 키가 필요한 뒤죽박죽 바이트. DRM은 그 암호화를 둘러싼 정책 시스템입니다. 키를 누가 받는지 통제하는 라이선스 서버, 키를 사용하는 신뢰 실행 환경, 어떤 기기가 어떤 콘텐츠를 재생할 수 있는지 결정하는 계약 이행 계층이 결합된 것입니다. 암호화는 잠금 장치이고, DRM은 경보 시스템, 키 배포, 폐기 정책이 합쳐진 것입니다.
“MP4는 스트리밍 형식이다.” 아닙니다. MP4는 컨테이너입니다 — 오디오, 동영상, 메타데이터를 감싸는 파일 형식. HLS와 DASH는 스트리밍 프로토콜이고, fragmented MP4 세그먼트를 운반할 수 있습니다. 일반 .mp4 파일은 스트리밍되지 않고 점진적으로 다운로드됩니다. HLS와 DASH에서 보는 CMAF 세그먼트는 MP4에서 파생되었지만 매우 다르게 구조화되어 있습니다.

대부분의 혼란은 파이프라인을 내재화하면 사라집니다. 스트리밍은 파일과 타이밍입니다 — 나머지는 모두 세부 사항입니다.

마무리하며

인터넷은 다른 모든 것을 보내는 방식 그대로 동영상을 보내기 시작했습니다. HTTP 위의 파일로요. 그러고 나서 어떤 파일을, 어떤 순서로, 어떤 화질로, 어떤 엣지 캐시에서, 어떤 하드웨어로 디코딩하는지에 관해 영리해졌습니다. 그 영리한 패턴 — 매니페스트 + 세그먼트 + 적응형 비트레이트 + CDN 캐싱 — 이 스트리밍이 즉각적으로 느껴지고, 수십억 시청자로 확장되며, 실제 네트워크의 지저분한 현실을 견디는 전체 이유입니다. 비밀 프로토콜도, 독점 서버도, 특별한 마법도 없습니다. 그저 파일, 타이밍, 그리고 스택 전체에 걸친 매우 훌륭한 엔지니어링입니다.

프로토콜 계층을 완전히 건너뛰고 그저 동영상을 저장하고 싶다면, VidMost가 HLS, DASH, fMP4, AES-128, Widevine L3를 백그라운드에서 처리합니다 — 매니페스트가 파싱되고, 세그먼트가 페치되며, 암호화가 처리되고, MP4가 작성됩니다.

관련 글

HLS와 M3U8이란 무엇인가? — 스트리밍 대부분이 돌아가는 플레이리스트와 세그먼트 설계.
MPEG-DASH 대 HLS — 각 프로토콜이 이기는 경우와 대부분의 스트리밍 서비스가 둘 다 제공하는 이유.
적응형 비트레이트 스트리밍 설명 — 모든 현대 플레이어 안의 ABR 로직.
동영상 컨테이너 대 코덱 — 세그먼트 안에 실제로 무엇이 들어 있는가.
DRM 보호 콘텐츠란 무엇인가? — Widevine, FairPlay, PlayReady가 프리미엄 스트림을 어떻게 게이팅하는가.