RTMP vs HLS 라이브 스트리밍 방식 차이와 선택 기준

라이브 스트림 전송에 사용되는 프로토콜

유튜브와 같은 동영상 플랫폼에 라이브 스트림을 전송하는 방법은 여러 가지가 있다. 그중 가장 널리 사용되는 방식은 RTMP(Real-Time Messaging Protocol)이며, HLS(HTTP Live Streaming)나 SRT(Secure Reliable Transport)를 사용하는 경우도 있다.

RTMP는 오랜 기간 라이브 스트리밍에 사용되어 왔으며, 지원하는 인코더와 플랫폼이 많아 플랫폼 송출을 위한 사실상의 표준으로 사용된다. 전송 구간을 암호화한 RTMPS도 있지만, 스트림을 연속적으로 전송한다는 기본 동작은 RTMP와 같다. 따라서 별도의 요구 조건이 없다면 일반적으로 가장 먼저 선택하는 인제스트(ingest, 콘텐츠 입수) 방식이다.

RTMP 이외에도 선택지는 존재한다. 유튜브는 HLS 인제스트를 지원하며, 다른 일부 플랫폼과 방송 시스템에서는 낮은 지연 시간과 전송 안정성을 확보하기 위해 SRT를 지원하기도 한다. 그러나 라이브 스트림 인제스트에서는 아직 RTMP만큼 보편적으로 사용되지는 않는다.

프로토콜이 다르다는 것은 라이브 스트림 데이터를 전송하는 방법이 다르다는 의미이며, 이는 라이브 채널의 특성과 안전성의 차이로 이어진다. 본 글에서는 RTMP와 HLS의 전송 방식과 특성을 비교하고, 유튜브 라이브 스트리밍에 어떤 프로토콜이 적합한지 살펴본다.

RTMP와 HLS의 차이 – 연속 vs 단속

두 프로토콜 모두 동영상 스트림을 끊임없이 전송하고 재생하기 위한 방법이지만, 그 전송 방식에는 많은 차이가 있다. 가장 핵심적인 차이는 아래의 그림을 보면 쉽게 알 수 있다.

위의 그래프는 동일한 MPEG2-TS UDP 스트림을 와우자 스트리밍 엔진에서 RTMP와 HLS로 각각 변환한 뒤, 두 스트림을 전송할 때 발생하는 네트워크 트래픽 그래프이다. 왼쪽은 RTMP, 오른쪽은 HLS의 네트워크 전송률을 나타낸다.

그래프를 보면 한눈에 봐도 두 형태가 매우 다른 것을 알 수 있다. RTMP 그래프에서는 약 5Mbps의 네트워크 트래픽이 끊임없이 연속적으로 발생한다. 반면 HLS 그래프에서는 약 10초 간격으로 50Mbps 정도의 트래픽이 발생한 뒤 다시 멈추는 모습이 반복되고 있다.

RTMP는 인코딩된 데이터 스트림을 연속적으로 끊임없이 전송한다. 마치 수도꼭지를 약하게 틀어두고 일정한 양의 물을 계속 흐르게 하는 것과 같다. 실시간으로 상대방의 음성이 전달되는 전화 통화를 생각하면 이해하기 쉽다. 플레이어 입장에서는 이렇게 끊임없이 전달되는 데이터 스트림을 연속으로 재생한다.

HLS는 인코딩된 데이터 스트림을 일정 시간 동안 모아 동영상 파일로 만든 뒤 반복적으로 전송한다. 이렇게 일정한 길이로 나눈 동영상 조각을 세그먼트(Segment)라고 하며, 일반적으로는 청크(Chunk)라 부른다.

이는 양동이에 물을 모아 일정한 양이 차면 한 번씩 나르거나, 내용을 종이에 작성한 뒤 편지로 전달하는 것과 유사하다. 플레이어에서 현재 재생 중인 10초짜리 동영상 파일이 끝나기 전에 다음 10초짜리 동영상 파일을 다운받아 재생 목록에 추가하면, 영상은 멈추지 않고 다음 동영상을 이어서 재생할 수 있다. 이 과정을 반복하여 여러 개로 나뉜 청크를 하나의 연속된 라이브 영상처럼 재생하는 것이 HLS의 기본 개념이다.

정리하자면, RTMP와 HLS의 전송 방식 차이는 다음과 같이 정의할 수 있겠다.

RTMP

동영상 데이터를 끊김 없이 연속적으로 전송한다.

실시간 전화 통화나 수도꼭지에서 계속 흐르는 물과 유사한 개념이다.

HLS

동영상 데이터를 일정한 시간 간격으로 모아 동영상 파일로 만들어 전송한다.

전달받은 청크를 재생 목록에 따라 계속 이어서 재생한다.

RTMP와 HLS의 차이가 만드는 특성 – 지연 vs 안정성

위에서 보았듯이, RTMP 전송과 HLS 전송의 가장 큰 차이점은 연속 전송이냐 단속 전송이냐의 차이이다. 그리고 이러한 전송 방식의 차이는 라이브 스트리밍의 지연 시간과 네트워크 변화에 대응하는 능력의 차이를 만든다.

HLS의 동작은 일정 시간 동안 스트림 데이터를 모아서 청크를 생성한 후 전송하는 방법이라 말했다. 즉, 스트림 데이터를 모으는 시간이 필요하게 된다. 만약 청크의 길이를 10초로 설정했다면, 최소한 10초가 지난 다음 전송이 이루어진다는 의미이며, 이는 최소한 10초 이상의 지연시간이 발생한다는 의미가 된다. 하지만 청크를 전송하는 중간에 네트워크에 지연이 발생한다 하더라도 10초 안에만 전송이 완료되면 스트림은 계속 유지될 수 있다.

RTMP의 동작은 인코더의 데이터를 실시간으로 끊임없이 전송하는 방법이라 말했다. 끊임없이 실시간으로 전송한다는 의미는, ①정확한 시간에 ②정확한 순서대로 ③온전한 데이터가 전달되어야 한다는 의미이다. 만약 어떠한 이유로 데이터 전송에 문제가 생겨 셋 중 하나에라도 문제가 발생한다면, 영상 재생에 문제가 발생한다. 하지만 별도의 청크를 생성하지 않기 때문에 HLS보다 지연 시간을 줄일 수 있다.

정리하자면, RTMP와 HLS 전송에는 다음과 같은 특성 차이가 있다.

RTMP

청크 생성 과정이 없어 전송 지연 시간이 상대적으로 짧다.

데이터가 재생 시간에 맞춰 계속 도착해야 하므로 순간적인 회선 품질 저하에 민감하다.

HLS

청크 생성과 버퍼링으로 인해 추가적인 지연 시간이 발생한다.

다음 재생 시점까지 청크 전송을 완료할 수 있어 순간적인 회선 품질 저하를 상대적으로 잘 흡수한다.

RTMP vs HLS – 내게 적합한 유튜브 라이브 스트리밍 방식은?

RTMP와 HLS는 전송 방식이 다르기 때문에 각각 적합한 라이브 스트리밍 환경도 다르다. 시청자와 즉각적으로 소통하거나 지연 시간을 줄여야 한다면 RTMP가 유리하고, 지연 시간보다 장시간 안정적인 송출이 중요하거나 순간적인 네트워크 품질 저하가 반복된다면 HLS가 유리하다.

시청자와 소통하며 즉각적으로 반응해야 하는가? – RTMP

게임 방송과 같이 시청자와 실시간 소통하며 진행하는 콘텐츠라면, 지연 시간이 적은 RTMP를 사용하는 것이 더 유리하다. HLS를 이용할 경우, 유튜브에서 권장하는 최소 청크 값인 2초를 적용한다 하더라도, 시청자에게 반응하기까지 시간은 기본 4초 이상이 필요하다. 여기에 유튜브 내부의 트랜스코딩 시간과 전송 시간을 감안하면 이 시간은 더 늘어나게 된다. 과도한 지연은 실시간 소통 경험에 좋지 않은 영향을 미치게 된다.

지연 시간이 중요한 요소인가? : RTMP

스포츠 이벤트 생중계나 중대 발표와 같이, 결과가 중요해서 스포일러 문제(축구 경기를 지상파로 시청하던 옆집의 함성 소리가 우리 집 TV의 골 장면보다 먼저 터져 나오는)가 발생할 수 있는 콘텐츠로 라이브 스트리밍을 진행한다면, 지연 시간이 적은 RTMP를 사용하는 것이 더 유리하다.

장시간(3시간 이상) 방송인가? : HLS

3시간 정도면 라이브 스트리밍을 시작할 때에 비해 네트워크 환경이 달라지기에 충분한 시간이다. 사실 네트워크 품질은 3시간은커녕 분 단위로 바뀌기도 한다. RTMP로 방송을 진행할 경우, 처음에는 원활했던 방송이 네트워크의 상황에 따라 불안정하게 바뀔 수 있다. 때문에 안정적인 스트리밍을 유지하기 위해서 네트워크 환경에 영향을 덜 받는 HLS를 사용하는 것이 더 유리하다.

무선 네트워크를 사용하거나, 네트워크 품질이 불안정한가? : HLS

RTMP는 전송 과정에서 단 하나의 오류가 발생하더라도 재생에 문제가 생긴다. 반면, HLS는 순간적인 전송 오류가 발생하더라도, 시간 안에 데이터가 전달되기만 한다면 끊임없는 재생이 가능하다. 때문에 와이파이 무선 네트워크를 사용하거나, 유선 인터넷이라 하더라도 네트워크 품질이 좋지 않다면 HLS를 사용하는 것이 유리하다.

필자의 추천 : HLS

인터넷 환경이란 것은 생각보다 불안정하다. 국내 플랫폼이라면 그나마 나으나, 유튜브와 같은 글로벌 플랫폼은 통신사와 사업자 간 연동을 포함해 더 복잡한 네트워크 경로를 거칠 수 있다.

전송 경로가 복잡해진다는 것은 거쳐야 할 지점이 많아진다는 의미이다. 이는 문제가 발생할 수 있는 지점이 많아지는 동시에, 신호가 물리적으로 이동해야 하는 전체 거리도 길어진다는 의미이다. 해저 광케이블이나 중계 설비, 옥외 통신 설비 중 어느 한 구간에 장애가 발생하면 전체 전송 품질에 영향이 미친다. 아니, 당장 밖에 비가 오는 것만으로도 옥외 통신 설비나 무선 구간, 구내 네트워크의 상태가 달라져 인터넷 품질이 달라질 수 있다.

위의 영상은 동일한 라이브 스트림 소스를 하나의 와우자 스트리밍 엔진에서 RTMP 방식과 HLS 방식으로 유튜브에 송출한 모습이다. 왼쪽의 RTMP의 경우 끊김이 계속 발생하고 있지만, 오른쪽의 HLS의 경우 안정적으로 재생되고 있음을 확인할 수 있다.

두 영상 사이에는 약 30초의 지연 시간 차이가 있었으나, 전송 안정성을 같은 장면에서 비교할 수 있도록 재생 위치를 동일한 시점으로 맞췄다. 따라서 이 영상은 두 방식의 지연 시간 차이를 보여 주기 위한 것이 아니라, 동일한 소스와 송출 환경에서 나타난 재생 안정성의 차이를 비교하기 위한 것이다.

본 필자는 안정성을 우선하여 시스템을 구성한다. 때문에 기본적으로 HLS를 사용할 것을 추천한다. 하지만 환경과 콘텐츠 특성에 따라 독자 제위께 적합한 선택은 다를 수 있다. 본 글을 참고하여 적합한 프로토콜을 선택하고 소기의 목적을 이루시기를 바라는 바이다.

FAQ

HLS와 RTMP의 차이는 무엇인가?

RTMP는 하나의 연결을 유지하면서 인코딩된 데이터 스트림을 연속적으로 전송하고, HLS는 데이터를 일정한 길이의 세그먼트로 나누어 재생 목록과 함께 전송한다. 이 차이로 인해 RTMP는 지연 시간이 상대적으로 짧고, HLS는 순간적인 네트워크 품질 변화를 흡수할 시간적 여유가 상대적으로 크다.

유튜브 라이브 스트리밍에서 HLS를 선택해야 하는 경우는?

시청자와의 즉각적인 소통보다 장시간 안정적인 송출이 중요하거나, 순간적인 속도 저하와 지연 증가로 RTMP 송출이 반복적으로 끊긴다면 HLS를 고려할 수 있다.

유튜브 라이브 스트리밍에서 RTMP를 선택해야 하는 경우는?

게임 방송이나 실시간 질의응답처럼 시청자와 즉각적으로 소통해야 하거나, 스포츠 중계와 같이 지연 시간이 중요한 콘텐츠라면 RTMP 또는 RTMPS가 유리하다. 특히 유튜브의 낮은 지연 시간이나 매우 짧은 지연 시간 설정을 사용하려면 HLS보다 RTMP 계열을 우선적으로 고려하는 것이 좋다.

RTMP와 RTMPS의 차이는 무엇인가?

RTMPS는 RTMP 통신을 암호화한 방식이다. 사용자에게 체감되는 차이는 없지만 영상·음성·제어 정보를 암호화하여 보안성을 향상시킨다. RTMPS를 지원하는 인코더와 플랫폼을 사용한다면 RTMPS를 선택하는 것이 좋으며, 유튜브도 RTMPS 사용을 권장한다.

OBS에서 HLS 방식으로 유튜브 송출이 가능한가?

가능하다. 최근 버전의 OBS Studio는 HLS 출력을 지원하며, 유튜브 HLS 서비스를 선택하여 송출할 수 있다.

네트워크가 불안정하다면 RTMP와 HLS 모두 영향을 받는 것 아닌가?

그렇다. 하지만 HLS는 현재 청크를 재생하는 동안 다음 청크를 전송할 수 있으므로, 다음 재생 시점 전까지 전송을 마치면 연속 재생을 유지할 수 있다. 예를 들어 10초짜리 청크 파일 하나의 크기가 6MByte라고 하면, 1Gbps급 회선을 사용할 경우, 이론상 최대 200회 가까운 재전송의 기회가 있다.

HLS와 RTMP 중 안정성이 높은 전송 방식은 무엇인가?

순간적인 속도 저하나 지연 증가가 반복되는 네트워크에서는 HLS가 상대적으로 안정적이다. 세그먼트와 버퍼가 순간적인 네트워크 변화를 흡수할 시간적 여유를 제공하기 때문이다.

10Gbps 광랜을 사용하면 회선도 안정적인가?

최대 대역폭과 전송 안정성은 서로 다른 문제이다. 10Gbps 인터넷 회선이라도 문제가 발생할 수 있다. 라이브 스트리밍에서는 표시된 최대 속도보다 송출 비트레이트를 지속적으로 유지할 수 있는지, 지연과 패킷 손실이 안정적으로 관리되는지가 더 중요하다.

HLS의 지연 시간을 줄일 수 있는가?

LL-HLS(Low-Latency HLS)라는 1초 미만의 저지연 규격도 존재한다. 하지만 플랫폼과 인코더가 모두 지원해야 한다.

전송 지연은 시청 영상에만 영향을 미치는가?

아니다. 전송 지연이 계속 누적되면 송출 버퍼가 증가하고 시청자에게 전달되는 영상이 실제 시간보다 점점 늦어질 수 있다. 버퍼의 한계를 넘으면 프레임 드롭, 전송 시간 초과, 연결 종료와 재송출이 발생할 수 있으며, 버퍼 제한이 적절하지 않은 시스템에서는 메모리 사용량 증가로 서버 전체가 불안정해질 수도 있다.