🟣 왜 프로토콜이 여러 개인가
영상을 실시간으로 전달하는 방법이 하나뿐이었다면 이 책은 훨씬 짧았을 것이다. 그런데 라이브 스트리밍에는 RTMP, HLS, WebRTC, 여기에 LL-HLS까지 서로 다른 프로토콜이 공존한다. 처음에는 그냥 오래된 것과 새것의 차이인 줄 알았는데, 실제로는 목적이 다른 도구들이 각자의 자리를 지키고 있는 것이었다.
이 자리를 가르는 축은 단순하다. 영상이 촬영된 순간부터 시청자 화면에 뜨기까지 걸리는 지연과, 어떤 기기와 네트워크에서든 문제없이 재생되는 호환성이다. 이 둘은 대체로 반비례한다. 지연을 극단적으로 줄인 프로토콜은 특수한 연결과 서버를 요구해서 아무 데서나 돌지 않고, 어디서나 도는 프로토콜은 구조상 지연을 크게 감수한다.
그래서 실제 서비스는 프로토콜 하나를 고르는 대신, 구간마다 다른 프로토콜을 이어 붙인다. 이 장은 그 조합이 왜 그렇게 짜이는지를 지연과 호환이라는 두 축으로 정리한다.
🟣 방송 구간과 시청 구간은 요구가 다르다
라이브 스트리밍을 하나의 흐름으로 보면 놓치는 게 있다. 이 흐름은 성격이 다른 두 구간으로 나뉜다. 방송하는 사람의 기기에서 서버까지 올리는 업링크 구간과, 서버에서 수많은 시청자에게 내려보내는 다운링크 구간이다.
업링크는 보통 방송자 한 명이다. 안정적으로, 끊김 없이, 서버까지 한 줄기로 올리면 된다. 반면 다운링크는 시청자가 수천, 수만 명일 수 있다. 여기서는 한 명에게 잘 보내는 것보다 많은 사람에게 동시에 감당 가능한 비용으로 뿌리는 것이 관건이 된다. 이 두 구간의 요구가 다르기 때문에 쓰는 프로토콜도 갈린다.
업링크에서 오래 자리를 지켜 온 것이 RTMP이고, 다운링크의 사실상 표준이 HLS다. 왜 이 조합이 굳어졌는지 하나씩 본다.
🟣 RTMP: 올릴 때는 아직도 이걸 쓴다
RTMP는 원래 플래시 시절의 프로토콜이다. 브라우저에서 플래시가 사라지면서 시청용으로는 거의 죽었는데, 방송자가 영상을 서버로 올리는 업링크 쪽에서는 여전히 살아 있다. 방송 장비와 소프트웨어가 오랫동안 RTMP 송출을 기본으로 지원해 왔기 때문이다.
RTMP는 TCP 위에서 영상과 음성을 잘게 쪼갠 조각으로 끊임없이 밀어 넣는다. 연결을 한 번 맺어 놓고 그 위로 계속 흘려보내는 방식이라 지연이 낮다. 방송자에서 서버까지는 보통 1초에서 2초 안쪽이다. 방송자 한 명이 서버 하나에 안정적으로 붙어 올리는 용도로는 부족함이 없다.
문제는 시청 쪽이다. RTMP로 수만 명에게 직접 뿌리려면 그 연결을 전부 서버가 유지해야 하고, 일반적인 웹 인프라(CDN, HTTP 캐시)를 태우기도 어렵다. 그래서 올릴 때는 RTMP, 내려보낼 때는 HTTP 기반 프로토콜이라는 역할 분담이 자연스럽게 자리 잡았다.
🟣 HLS: 영상을 파일 조각으로 바꾸는 발상
HLS(HTTP Live Streaming)는 애플이 2009년에 내놓은 프로토콜이다. 발상이 단순해서 오히려 강력하다. 연속된 영상 스트림을 몇 초짜리 파일 조각으로 잘라, 그냥 HTTP로 하나씩 내려받게 한다. 스트리밍을 특수한 실시간 연결이 아니라 평범한 파일 다운로드의 연속으로 바꿔 버린 것이다.
이 발상의 값어치는 기존 웹 인프라를 그대로 쓸 수 있다는 데 있다. 영상 조각이 그냥 HTTP 파일이므로 CDN이 캐싱하고, 방화벽이 막지 않고, 어떤 기기의 브라우저든 HTTP만 되면 받는다. 시청자가 백만 명이어도 서버가 백만 개의 연결을 붙들 필요 없이, CDN이 같은 파일 조각을 복제해 뿌리면 된다. 다운링크의 확장성 문제를 인프라 재사용으로 푼 셈이다.
대신 지연을 감수한다. 몇 초짜리 조각으로 자른다는 것은, 시청자가 한 조각을 받으려면 서버가 그 몇 초 분량을 다 모아 파일로 만들 때까지 기다려야 한다는 뜻이다. 여기에 여러 조각을 미리 받아 두는 버퍼까지 더해지면, HLS의 실제 지연은 흔히 10초를 훌쩍 넘는다. 다음 장에서 자세히 보겠지만, 이 지연은 HLS 구조에서 거의 필연이다.
🟣 WebRTC: 지연을 못 견디는 쪽의 답
HLS의 10초 지연이 문제가 안 되는 서비스가 많다. 스포츠 중계나 콘서트 라이브는 몇 초 늦어도 아무도 모른다. 그런데 이 지연이 서비스 자체를 망가뜨리는 영역이 있다. 화상 회의, 라이브 커머스의 실시간 소통, 온라인 게임의 관전처럼 상대의 반응이 즉시 돌아와야 대화가 성립하는 경우다. 서로 말하는데 10초씩 밀리면 통화가 아니다.
이 영역을 위한 것이 WebRTC다. WebRTC는 지연을 1초 밑, 흔히 수백 밀리초까지 끌어내린다. 방법은 HLS와 정반대다. 파일로 자르지 않고, 기기와 기기 사이에 직접 연결을 뚫어 영상을 곧바로 흘려보낸다. 중간에 파일을 모으는 단계가 없으니 그만큼 지연이 사라진다.
대가는 복잡성과 확장성이다. 직접 연결을 뚫으려면 서로의 주소를 찾아 주는 시그널링, 공유기 뒤에 숨은 기기를 이어 주는 STUN과 TURN 같은 장치가 필요하다. 게다가 참여자가 늘수록 연결 수가 급격히 불어나서, 다수를 감당하려면 SFU라는 중계 서버를 따로 둔다. HLS가 인프라 재사용으로 쉽게 확장되던 것과 대비된다. 이 구조는 3장에서 통째로 다룬다.
🟣 LL-HLS: 두 세계 사이를 좁히려는 시도
여기까지 보면 선택이 극단적이다. 넓은 호환성에 큰 지연을 얹은 HLS이거나, 낮은 지연에 복잡한 구조를 얹은 WebRTC이거나. 그 사이를 메우려는 절충이 LL-HLS(Low-Latency HLS)다.
LL-HLS는 HLS의 골격을 유지한다. HTTP 위에서 조각을 받는 방식 그대로다. 대신 조각을 통째로 기다리지 않고, 조각을 다시 더 작은 부분 조각으로 쪼개 완성되는 대로 먼저 내보낸다. 덕분에 HTTP와 CDN 친화성을 지키면서 지연을 2초 안팎까지 줄인다. 호환성을 크게 버리지 않고 지연만 깎으려는 타협이다.
물론 완전한 실시간은 아니다. WebRTC의 수백 밀리초에는 못 미친다. 그래서 LL-HLS는 HLS를 대체한다기보다, HLS로는 조금 부족하지만 WebRTC까지는 필요 없는 중간 지대를 채운다. 프로토콜이 여러 개인 이유가 여기서도 반복된다. 하나가 나머지를 이기는 게 아니라, 지연-호환 축의 서로 다른 지점을 각자 점유하는 것이다.
🟣 정리
- 라이브 스트리밍의 거의 모든 결정은 지연과 호환성이 대체로 반비례한다는 하나의 긴장에서 나온다. 지연을 줄이면 특수한 구조가 필요하고, 호환을 넓히면 지연을 감수한다.
- 흐름은 방송자 한 명의 업링크와 다수 시청자의 다운링크로 나뉘고, 요구가 다르므로 프로토콜도 갈린다. 업링크는 RTMP, 다운링크는 HLS가 사실상 표준이다.
- HLS는 영상을 HTTP 파일 조각으로 바꿔 기존 웹 인프라(CDN, 캐시)를 그대로 재사용한다. 확장성을 얻는 대신 10초 이상의 지연을 감수한다.
- WebRTC는 기기 간 직접 연결로 지연을 수백 밀리초까지 줄인다. 실시간 소통이 필요한 곳의 답이지만 시그널링과 중계 서버라는 복잡성을 떠안는다.
- LL-HLS는 HLS 골격을 유지한 채 조각을 잘게 나눠 지연을 2초 안팎으로 줄인 절충안이다. 프로토콜은 서로를 이기는 게 아니라 지연-호환 축의 다른 지점을 점유한다.
면접에서 "라이브 스트리밍을 어떻게 설계하겠냐"는 질문은 결국 이 축 위에서 요구 지연을 먼저 묻는 것과 같다. 서비스가 감당할 수 있는 지연이 몇 초인지가 정해지면 프로토콜은 거의 따라 정해진다. 실무에서도 "RTMP로 받아 HLS로 뿌린다"는 한 문장이 대부분 라이브 서비스의 뼈대다.
다음 장은 그 다운링크의 주인공인 HLS를 안으로 열어 본다. .m3u8 플레이리스트가 무엇을 담고 있는지, 그리고 시청자마다 화질이 달라지는 적응형 비트레이트가 어떻게 동작하는지를 본다.