적응형 스트리밍은 어떻게 끊김을 줄이나
위키백과의 설명에 따르면 적응형 비트레이트 스트리밍(ABR)은 같은 원본 영상을 여러 비트레이트로 인코딩해 수 초 길이의 조각(세그먼트)으로 나눠 둡니다. 재생기는 먼저 각 조각의 목록과 비트레이트가 적힌 매니페스트 파일을 받고, 보통 가장 낮은 비트레이트로 시작합니다. 이후 다운로드 속도가 현재 조각의 비트레이트보다 높으면 더 높은 화질로, 낮아지면 낮은 화질로 옮겨 갑니다. 어떤 기준으로 옮길지는 처리량 기반, 버퍼 기반, 둘을 섞은 방식으로 나뉩니다. 이 때문에 영상을 보다가 화질이 갑자기 흐려졌다가 선명해지는 일이 생깁니다. 끊김(버퍼링)을 피하는 대신 화질을 일시적으로 양보하는 것입니다. 이 방식은 HTTP 위에서 동작하므로 방화벽과 NAT를 통과하기 쉽고, 서버가 시청자별 상태를 따로 기억하지 않아도 되며, 기존 웹 캐시와 CDN을 그대로 쓸 수 있다는 장점이 있습니다.
한계도 있습니다. 같은 영상을 여러 벌 만들어야 해서 저장과 인코딩 비용이 늘고, 전 세계에서 품질을 일정하게 유지하기가 어렵습니다. 또 ABR 로직이 TCP 흐름 제어와 어긋날 수 있으며, 모든 기기에 쓸 수 있는 단일 저작권 보호(DRM) 표준이 없습니다. 조각 단위로 영상을 받는 구조는 라이브 방송의 지연 시간에도 영향을 줄 수 있으나, 구체적인 지연 길이는 서비스 설정에 따라 다르므로 이 글에서는 수치를 쓰지 않습니다.
실제 사례 세 가지
사례 1. 서로 다른 방식이 하나의 표준으로 모이기까지 (적응형 스트리밍의 역사)
위키백과 기준으로, 현대적인 HTTP 기반 ABR은 2004~2006년 무브 네트웍스(Move Networks)가 개발했고 미국 특허는 2010년 10월에 부여되었습니다. 마이크로소프트는 2008년 하계 올림픽에서 ABR을 시연했고, 2009년 2월 스무스 스트리밍(Smooth Streaming)을 IIS7용 베타로 내놓은 뒤 4월 정식 출시했습니다. 애플은 2009년 6월 iOS 3.0과 함께 HTTP 라이브 스트리밍(HLS)을 공개했고, 어도비는 2010년 6월 HDS를 내놓았습니다. 이후 MPEG-DASH가 2011년 11월 국제 표준이 되어 2012년 4월 ISO/IEC 23009-1:2012로 발간되었고, 2016년 애플과 마이크로소프트가 제안한 CMAF가 2018년 발행되었습니다. 배울 점은 비슷한 아이디어가 여러 회사에서 경쟁하듯 나왔다가 표준과 호환 포맷으로 정리되어 갔다는 것입니다. 위키백과는 2026년 현재 HLS와 MPEG-DASH만 활발히 개발·사용된다고 서술합니다.
사례 2. 압축 효율을 높인 AV1 코덱과 그 대가 (코덱의 사례)
AV1은 2015년 설립된 오픈 미디어 연합(AOMedia)이 VP9의 후속으로 개발했고, 2018년 3월 28일 비트스트림 규격이 발표되었으며 같은 해 6월 25일 검증판 1.0.0이 나왔습니다. H.264나 H.265와 달리 로열티가 없다는 점이 특징입니다. 압축 효율은 시험마다 값이 다르게 보고됩니다. 위키백과는 2020년 워털루 대학의 4K 시험에서 HEVC보다 9.5%, VP9보다 16.4% 비트레이트를 줄였다는 결과를 소개하고, 2018년 페이스북의 시험에서는 VP9 대비 약 34%, x264 대비 약 50% 높은 압축률을 보였다고 적습니다. 반면 워털루 대학의 같은 2020년 연구에서 4K 인코딩 시간은 AVC 대비 평균 590배로 길었고(HEVC 4.2배, VP9 5.2배), 기기 쪽에서는 하드웨어 디코딩이 비교적 최신 기기부터 지원됩니다. 넷플릭스는 2025년 12월 시청의 30%가 AV1이라고 보고했다고 서술됩니다. 배울 점은 코덱 선택이 '더 작게 압축하는가'만이 아니라 인코딩 비용, 기기 지원, 라이선스를 함께 따지는 문제라는 것입니다. 시험 조건에 따라 수치가 크게 달라지므로 한 숫자만 인용하기보다 범위로 이해하는 것이 정확합니다.
사례 3. 영화는 왜 24프레임인가, TV는 왜 50과 60인가 (프레임레이트의 사례)
위키백과 기준으로 무성영화는 대략 16~24fps로 촬영되었고, 1926년 유성영화가 도입될 때 극장들이 무성영화를 22~26fps로 상영하던 점을 절충해 24fps가 정해졌습니다. 이는 1927~1930년 사이 35mm 유성영화의 표준이 되었습니다. 아날로그 TV는 세계 대부분이 초당 50필드, 캐나다·미국·멕시코·일본·한국·필리핀은 60필드를 썼는데, 이는 전원 주파수와 연관됩니다. 컬러 TV가 도입되며 60은 0.1% 낮춘 약 59.94로 바뀌었습니다. 24fps 영화를 60fps 화면에서 틀려면 프레임을 번갈아 2번·3번 반복하는 풀다운이 필요해 움직임이 고르지 않은 저더(judder)가 생깁니다. 배울 점은 프레임레이트의 숫자가 기술적 우열이 아니라 역사적 타협과 표준, 변환 방식의 결과라는 것입니다.
화질 문제를 겪을 때 확인하는 순서
- 설정부터 낮춰 보기: 화질을 낮추면 필요한 비트레이트가 줄어 끊김이 줄어드는 경우가 많습니다.
- 회선 점검: 인터넷 속도 측정으로 현재 속도를 확인하고, 무선이라면 느린 와이파이 점검도 해 봅니다.
- 유선 연결 시도: 유선은 무선보다 속도 변동 요인이 적어 시험해 볼 만한 방법입니다.
- 데이터 한도 확인: 모바일에서는 위 표의 계산처럼 화질이 올라갈수록 시간당 데이터가 크게 늘어납니다.
- 라이브에서는 지연을 감안: 실시간 방송은 인코딩·전송 과정 때문에 실제보다 늦게 보이는 것이 정상일 수 있습니다.
흔한 오해와 정정
- 오해: 해상도가 같으면 화질도 같다. 실제: 1080p만 해도 위키백과 예시 범위가 3~8 Mbit/s로 넓고, 코덱에 따라 같은 화질에 필요한 비트레이트가 달라집니다.
- 오해: 비트레이트와 대역폭은 같은 말이다. 실제: 비트레이트는 초당 비트 수, 처리량은 실제 달성한 유효 속도, 헤르츠 단위의 대역폭은 또 다른 양입니다.
- 오해: 프레임레이트가 높을수록 항상 좋다. 실제: 영화의 24fps는 역사적 표준이고, 다른 프레임레이트로의 변환은 저더 같은 부작용을 낳을 수 있습니다.
- 오해: 새 코덱은 모든 기기에서 바로 쓸 수 있다. 실제: AV1은 하드웨어 디코딩이 비교적 최신 기기(예: 아이폰 15 프로 이후, 픽셀 6 이후)부터 지원된다고 서술됩니다.
한계와 더 알아볼 점
이 글의 연혁과 수치는 위키백과 영문판 서술을 기준으로 했으며, 서비스별 실제 비트레이트 사다리와 지연 시간은 확인하지 못했습니다. 코덱의 효율 비교는 시험 방법과 인코더 설정에 따라 크게 달라지는데, 위키백과도 2016년 말 초기 시험에서는 AV1이 HEVC보다 효율이 낮게 나온 사례가 있음을 적습니다. 어느 서비스가 어떤 코덱을 어떤 조건에서 쓰는지는 서비스 공지를 확인해야 합니다.
영상 파일 형식도 궁금하다면
동영상 파일 자체의 형식이 궁금하다면 영상 파일 형식 완전정복도 확인해보세요.
자주 묻는 질문
버퍼링이 자주 생기면 어떻게 해결하나요?
인터넷 속도를 확인하고, 영상 화질 설정을 낮추거나 유선 인터넷 연결을 사용하면 버퍼링을 줄이는 데 도움이 됩니다.
라이브 스트리밍은 왜 실제보다 몇 초 늦게 보이나요?
영상을 인코딩하고 전송하는 과정에서 발생하는 지연 시간(레이턴시) 때문이며, 최신 기술로 이 지연을 최소화하려는 노력이 계속되고 있습니다.
재생 시작 직후 화질이 흐린 이유는 무엇인가요?
적응형 스트리밍은 보통 가장 낮은 비트레이트로 시작해, 속도가 충분하다고 판단되면 화질을 올립니다. 그래서 시작 직후 잠깐 흐렸다가 선명해지는 것이 일반적인 동작입니다(위키백과 기준).
HLS와 MPEG-DASH는 무엇이 다른가요?
둘 다 영상을 조각으로 나눠 HTTP로 보내는 적응형 방식입니다. HLS는 애플이 2009년 공개했고 목록 파일로 M3U8 형식을 쓰며 RFC 8216으로 발간되었습니다. MPEG-DASH는 국제 표준으로 정해진 방식입니다.
AV1은 왜 아직 모든 기기에서 쓰이지 않나요?
하드웨어 디코딩 지원이 비교적 최신 기기부터 시작되었고, 초기 인코더는 매우 느렸기 때문입니다. 이후 최적화로 격차가 줄었다고 서술되며, 지원 범위는 계속 넓어지고 있습니다.
이어서 읽어 보세요
- 유튜브 화질 가이드: 해상도 선택과 자동 화질의 의미
- 화면 해상도 가이드: 해상도 이름과 화면 크기의 관계
- 라이브 스트리밍 플랫폼 가이드: 실시간 방송 환경 비교
- 핑과 지연 시간 가이드: 지연이 생기는 위치 이해하기