HLS, WebRTC, RTMP, SRT는 언제 써야 할까?

라이브 스트리밍 프로토콜 정리

2026년 7월 3일

12분 읽기조회 0댓글 0
개발#프로토콜

들어가며: 왜 이 주제를 공부하게 되었나

라이브 스트리밍 관련 자료를 보다 보면 비슷해 보이는 이름들이 계속 등장한다.

HLS, LL-HLS, MPEG-DASH, WebRTC, RTMP, SRT, WHIP, WHEP.

처음에는 전부 “영상을 보내는 프로토콜” 정도로만 이해했다. 그런데 조금만 더 들어가 보니 이들은 같은 문제를 해결하는 기술이 아니었다. 어떤 것은 시청자에게 영상을 배포하는 데 적합하고, 어떤 것은 OBS나 인코더에서 서버로 영상을 밀어 넣는 데 적합하며, 어떤 것은 화상회의처럼 거의 실시간에 가까운 상호작용을 위해 사용된다.

이 글은 내가 라이브 스트리밍 프로토콜을 공부하면서 헷갈렸던 부분을 정리한 글이다. 단순히 프로토콜 이름을 외우는 것이 아니라, 다음 질문에 답하는 방향으로 정리해보려고 한다.

  • 왜 이렇게 많은 스트리밍 프로토콜이 존재할까?
  • HLS, DASH, WebRTC, RTMP, SRT는 각각 무엇이 다를까?
  • 실제 프로젝트에서는 어떤 기준으로 프로토콜을 선택해야 할까?
  • 특히 SRT는 RTMP와 비교해서 왜 주목받는 걸까?

글 전체를 관통하는 핵심은 하나다.

스트리밍 프로토콜은 “좋고 나쁨”으로 고르는 것이 아니라, 송출인지, 배포인지, 실시간 상호작용인지에 따라 다르게 선택해야 한다.

이 글에서 다룰 질문들

이번 글에서는 다음 질문들을 중심으로 정리한다.

  • 스트리밍 시스템에서 “송출”, “배포”, “실시간 통신”은 어떻게 다른가?
  • HLS, LL-HLS, MPEG-DASH는 왜 대규모 시청자 배포에 많이 쓰일까?
  • WebRTC는 왜 초저지연에 강하지만 대규모 배포가 복잡할까?
  • RTMP와 SRT는 둘 다 송출용으로 쓰이는데, 어떤 차이가 있을까?
  • WHIP과 WHEP은 WebRTC에서 어떤 문제를 해결하려는 걸까?
  • 실제 프로젝트에서 프로토콜을 선택할 때 어떤 기준을 봐야 할까?

먼저 배경부터 이해하기

스트리밍을 택배에 비유해보자. 영상을 보내는 일은 단순히 “파일 하나를 전달하는 것”이 아니다. 라이브 방송에서는 영상이 계속 만들어지고, 그 데이터를 끊기지 않게, 가능한 한 빠르게, 여러 사람에게 전달해야 한다.

이때 필요한 역할을 크게 나누면 다음과 같다.

역할설명예시 프로토콜
송출 / 인제스트영상 생산자가 서버로 영상을 보내는 단계RTMP, SRT, WHIP
처리 / 변환서버에서 인코딩, 패키징, 트랜스코딩하는 단계FFmpeg, Media Server
배포 / 재생시청자가 영상을 받아 보는 단계HLS, LL-HLS, MPEG-DASH, WebRTC, WHEP

여기서 중요한 점은 프로토콜마다 담당하는 위치가 다르다는 것이다.

예를 들어 HLS는 많은 시청자에게 안정적으로 영상을 전달하는 데 강하지만, OBS에서 서버로 영상을 밀어 넣는 용도로는 일반적으로 사용하지 않는다. 반대로 SRT는 현장 카메라나 OBS에서 서버로 안정적으로 보내는 데 강하지만, 브라우저에서 바로 재생하는 시청자용 프로토콜로 보기는 어렵다.

전체 구조 한눈에 보기

라이브 스트리밍 시스템을 단순화하면 보통 다음과 같은 구조가 된다.

[카메라 / OBS / 인코더]
          |
          |  RTMP / SRT / WHIP
          v
[미디어 서버 / 인제스트 서버]
          |
          |  인코딩 / 패키징 / 트랜스코딩
          v
[CDN / WebRTC 서버 / 스트리밍 서버]
          |
          |  HLS / LL-HLS / DASH / WebRTC / WHEP
          v
[시청자 브라우저 / 모바일 앱 / 플레이어]

이 구조를 보면 프로토콜을 다음처럼 나눌 수 있다.

RTMP / SRT / WHIP
= 서버로 영상을 밀어 넣는 입구

HLS / LL-HLS / DASH
= 많은 시청자에게 안정적으로 나눠주는 배포 방식

WebRTC / WHEP
= 매우 낮은 지연시간으로 시청하거나 통신하는 방식

이렇게 위치를 나눠서 보면 프로토콜이 훨씬 덜 헷갈린다.

핵심 개념 1: 배포용 프로토콜 — HLS, LL-HLS, MPEG-DASH

먼저 시청자에게 영상을 전달하는 프로토콜부터 보자.

HLS

HLS는 HTTP Live Streaming의 약자다. Apple이 만든 HTTP 기반 스트리밍 방식이며, 현재도 라이브와 VOD에서 매우 널리 사용된다.

HLS는 영상을 작은 조각으로 나눈 뒤, 플레이어가 .m3u8 플레이리스트를 보고 필요한 조각을 HTTP로 가져가는 방식이다.

영상 원본
  → 작은 세그먼트로 분할
  → .m3u8 플레이리스트 생성
  → CDN에 배포
  → 플레이어가 필요한 세그먼트 다운로드

HLS의 장점은 명확하다.

  • HTTP 기반이라 웹 인프라와 잘 맞는다.
  • CDN 캐싱에 유리하다.
  • iOS, Safari, 스마트TV 등에서 호환성이 좋다.
  • 네트워크 상황에 따라 화질을 바꾸는 ABR에 적합하다.

여기서 ABR은 Adaptive Bitrate Streaming의 약자다. 쉽게 말하면 네트워크가 좋을 때는 고화질을 받고, 느려지면 자동으로 저화질을 받는 방식이다.

다만 일반적인 HLS는 지연시간이 상대적으로 크다. 플레이어가 안정적인 재생을 위해 여러 세그먼트를 미리 버퍼링하기 때문이다. 그래서 실시간 채팅, 경매, 원격 제어처럼 반응성이 중요한 서비스에는 한계가 있다.

LL-HLS

LL-HLS는 Low-Latency HLS다. 이름 그대로 HLS의 저지연 버전이라고 볼 수 있다.

일반 HLS가 완성된 세그먼트를 받아 재생한다면, LL-HLS는 세그먼트를 더 작은 조각으로 나누어 더 빠르게 전달한다.

일반 HLS
[세그먼트 완성] → 다운로드 → 재생

LL-HLS
[부분 세그먼트 생성] → 빠르게 다운로드 → 재생

LL-HLS의 장점은 기존 HLS 생태계를 유지하면서 지연시간을 줄일 수 있다는 점이다. CDN과 HTTP 기반 구조를 그대로 활용할 수 있어 대규모 시청자 서비스에 유리하다.

하지만 실제 적용은 생각보다 단순하지 않다. 인코더, 패키저, CDN, 플레이어가 모두 LL-HLS에 맞게 동작해야 한다. 따라서 “HLS보다 빠르다”만 보고 선택하기보다는 전체 파이프라인이 이를 지원하는지 확인해야 한다.

MPEG-DASH

MPEG-DASH는 Dynamic Adaptive Streaming over HTTP의 약자다. HLS와 비슷하게 HTTP 기반으로 세그먼트를 내려받는 적응형 스트리밍 방식이다.

HLS가 .m3u8 플레이리스트를 사용한다면, DASH는 보통 .mpd manifest 파일을 사용한다.

HLS  → .m3u8
DASH → .mpd

DASH 역시 CDN 친화적이고, ABR에 강하다. Android, 웹 플레이어, DRM이 필요한 OTT 서비스에서 자주 등장한다.

다만 Apple 생태계에서는 HLS가 더 자연스럽게 지원되는 경우가 많다. 그래서 실무에서는 “HLS냐 DASH냐”를 기술적으로만 고르기보다, 타깃 디바이스, DRM 요구사항, 플레이어 지원 여부, CDN 구성까지 함께 본다.

핵심 개념 2: 초저지연 실시간 통신 — WebRTC

WebRTC는 브라우저나 앱 사이에서 오디오, 비디오, 데이터를 실시간으로 주고받기 위한 기술이다.

HLS나 DASH가 “방송을 안정적으로 나눠주는 방식”에 가깝다면, WebRTC는 “실시간 통화”에 가깝다.

HLS / DASH
서버 → CDN → 많은 시청자

WebRTC
브라우저 ↔ 브라우저
또는
브라우저 ↔ 미디어 서버 ↔ 브라우저

WebRTC의 장점은 지연시간이 매우 낮다는 점이다. 화상회의, 실시간 수업, 원격 진료, 실시간 경매, 인터랙티브 라이브처럼 사용자의 반응이 중요한 서비스에 적합하다.

하지만 WebRTC는 단순히 “영상 전송 프로토콜 하나”라고 보기 어렵다. 내부적으로 여러 기술이 함께 동작한다.

구성 요소역할
SDP어떤 미디어를 어떤 방식으로 주고받을지 설명
ICE연결 가능한 네트워크 경로 탐색
STUN내 공인 IP와 포트를 확인
TURN직접 연결이 안 될 때 중계 서버 역할
DTLS-SRTP미디어 암호화
RTP / RTCP실시간 미디어 패킷 전송과 품질 제어

처음에는 WebRTC가 “브라우저에서 실시간 영상을 보내는 기능” 정도로 보였지만, 실제로는 NAT, 방화벽, 암호화, 미디어 협상, 네트워크 품질 제어까지 포함하는 복합적인 기술 스택에 가깝다.

그래서 WebRTC는 초저지연에는 강하지만, HLS처럼 CDN에 세그먼트를 올려두고 수십만 명에게 쉽게 배포하는 구조와는 다르다. 대규모 서비스에서는 SFU, TURN 인프라, 미디어 서버 확장 구조를 별도로 설계해야 한다.

핵심 개념 3: 송출용 프로토콜 — RTMP와 SRT

이번에는 방송을 서버로 밀어 넣는 단계, 즉 인제스트 관점에서 보자.

RTMP

RTMP는 Real-Time Messaging Protocol의 약자다. 예전 Flash 시대부터 사용된 오래된 스트리밍 프로토콜이다.

현재는 브라우저 재생용이라기보다, OBS나 인코더에서 YouTube, Twitch, 미디어 서버로 송출할 때 여전히 많이 사용된다.

OBS → RTMP → 스트리밍 서버

RTMP의 장점은 다음과 같다.

  • OBS와 라이브 플랫폼 지원이 넓다.
  • 설정이 비교적 단순하다.
  • 레거시 시스템과 호환성이 좋다.

하지만 RTMP는 TCP 기반이다. TCP는 안정적인 전송에는 강하지만, 패킷 손실이 발생했을 때 뒤따르는 데이터까지 기다리는 문제가 생길 수 있다. 실시간 영상에서는 이 대기 시간이 지연으로 이어질 수 있다.

또한 최신 코덱, 초저지연, 불안정한 네트워크 대응 관점에서는 한계가 있다.

SRT

SRT는 Secure Reliable Transport의 약자다. 공용 인터넷처럼 품질이 일정하지 않은 네트워크에서도 라이브 영상을 안정적으로 보내기 위해 만들어진 UDP 기반 전송 프로토콜이다.

SRT를 한 문장으로 표현하면 이렇게 볼 수 있다.

SRT는 UDP의 빠른 전송 위에, 패킷 복구와 암호화, 지연 제어를 얹은 라이브 영상 전송 프로토콜이다.

SRT는 주로 다음과 같은 구조에서 사용된다.

현장 카메라 / OBS / 인코더
          |
          | SRT
          v
방송국 / 클라우드 서버 / 미디어 서버

RTMP와 비교하면 SRT는 불안정한 네트워크에 더 강하다. 패킷이 유실되면 수신자가 빠진 패킷을 감지하고 송신자에게 재전송을 요청할 수 있다. 이를 ARQ라고 한다.

ARQ는 Automatic Repeat reQuest의 약자로, 손실된 패킷을 다시 요청하는 방식이다.

1. 송신자가 패킷을 보낸다.
2. 수신자가 sequence number를 보고 누락된 패킷을 찾는다.
3. 수신자가 NAK를 보낸다.
4. 송신자가 빠진 패킷을 다시 보낸다.
5. 제시간에 도착하면 재생에 사용한다.
6. 너무 늦으면 버리고 다음 패킷을 진행한다.

여기서 ACK는 잘 받았다는 확인이고, NAK는 빠진 패킷이 있다는 알림이다.

SRT가 흥미로운 이유는 TCP처럼 완벽하게 모든 데이터를 기다리는 방식이 아니라는 점이다. 라이브 영상에서는 “완벽하지만 늦은 영상”보다 “조금 손상되더라도 제시간에 나오는 영상”이 더 나을 때가 많다.

그래서 SRT에는 Too-Late Packet Drop이라는 개념이 있다. 너무 늦게 도착해서 재생 시간에 맞출 수 없는 패킷은 버리고, 다음 패킷을 진행하는 방식이다.

SRT를 조금 더 깊게 이해하기

SRT에서 가장 중요한 설정값 중 하나는 latency다.

여기서 latency는 단순히 “전체 지연시간”을 의미하지 않는다. 정확히는 패킷 손실, 지터, 재전송을 흡수하기 위한 버퍼 시간에 가깝다.

네트워크 지연
+ 패킷 손실
+ 재전송 대기
+ 지터 흡수
= SRT latency 설정으로 어느 정도 대응

SRT에서는 TSBPD라는 개념도 등장한다. TSBPD는 Timestamp-Based Packet Delivery의 약자로, 패킷의 타임스탬프를 기준으로 수신 측에서 언제 애플리케이션에 전달할지 결정하는 방식이다.

흐름을 단순화하면 다음과 같다.

패킷 도착
  ↓
수신 버퍼에 보관
  ↓
누락 패킷 재전송 대기
  ↓
정해진 시간에 디코더로 전달

latency를 너무 낮게 잡으면 재전송할 시간이 부족해져 화면 깨짐이 발생할 수 있다. 반대로 너무 높게 잡으면 안정성은 좋아지지만 전체 지연시간이 늘어난다.

일반적으로는 RTT의 3~4배 정도를 latency 기준으로 생각할 수 있다. 여기서 RTT는 Round Trip Time, 즉 패킷이 왕복하는 데 걸리는 시간이다.

예를 들어 RTT가 50ms라면 다음과 같이 생각할 수 있다.

RTT = 50ms
권장 latency ≈ 50ms × 4 = 200ms

장거리 회선에서 RTT가 150ms라면:

RTT = 150ms
권장 latency ≈ 150ms × 4 = 600ms

물론 이 값은 절대적인 정답은 아니다. 실제로는 네트워크 품질, 패킷 손실률, burst loss, 비트레이트, 인코더 설정에 따라 달라진다.

실제 동작 흐름 뜯어보기

SRT를 FFmpeg로 송출하는 예시는 다음과 같이 작성할 수 있다.

ffmpeg -re -i input.mp4 \
  -c:v libx264 -preset veryfast -b:v 5000k \
  -c:a aac -b:a 128k \
  -f mpegts \
  "srt://example.com:9000?mode=caller&latency=500000"

각 옵션의 의미를 간단히 보면 다음과 같다.

옵션의미
-re입력 파일을 실제 재생 속도에 맞춰 읽음
-i input.mp4입력 파일 지정
-c:v libx264비디오를 H.264로 인코딩
-preset veryfast인코딩 속도와 압축 효율의 균형 설정
-b:v 5000k비디오 비트레이트를 약 5Mbps로 설정
-c:a aac오디오를 AAC로 인코딩
-b:a 128k오디오 비트레이트 설정
-f mpegtsMPEG-TS 컨테이너로 출력
srt://...SRT 주소로 송출

여기서 눈여겨볼 부분은 URL이다.

srt://example.com:9000?mode=caller&latency=500000
  • example.com:9000은 SRT를 받을 서버 주소와 포트다.
  • mode=caller는 송신자가 먼저 연결을 건다는 의미다.
  • latency=500000은 FFmpeg 기준으로 마이크로초 단위이며, 500000은 500ms를 의미한다.

SRT에는 연결 모드도 있다.

모드의미대표 상황
caller먼저 연결을 거는 쪽OBS나 인코더가 서버로 송출
listener포트를 열고 기다리는 쪽서버가 인제스트 대기
rendezvous양쪽이 동시에 연결 시도NAT 환경에서 양쪽이 직접 연결을 시도

가장 흔한 구조는 다음과 같다.

OBS / Encoder = caller
Media Server  = listener

암호화를 사용한다면 passphrase와 key length를 추가할 수 있다.

ffmpeg -re -i input.mp4 \
  -c:v libx264 -b:v 5000k \
  -c:a aac -b:a 128k \
  -f mpegts \
  "srt://example.com:9000?mode=caller&latency=500000&passphrase=mysecret1234&pbkeylen=16"

여기서:

  • passphrase는 송신자와 수신자가 공유하는 비밀 문자열이다.
  • pbkeylen=16은 AES-128 수준의 암호화를 의미한다.
  • 더 강한 키 길이가 필요하면 환경에 따라 24, 32 등을 검토할 수 있다.

주의할 점도 있다. SRT 암호화는 SRT 구간을 보호하는 것이다.

OBS → SRT → 미디어 서버

이 구간은 보호할 수 있지만, 서버가 다시 HLS나 DASH로 배포하는 구간까지 자동으로 보호되는 것은 아니다. 시청자 배포 보안은 HTTPS, 토큰 인증, signed URL, DRM 등을 별도로 설계해야 한다.

내가 헷갈렸던 부분 정리

Q1. HLS, DASH, WebRTC는 전부 영상 스트리밍인데 왜 따로 봐야 할까?

처음에는 세 가지 모두 “영상을 보는 방식”으로만 보였다. 하지만 실제로는 목표가 다르다.

HLS와 DASH는 대규모 시청자에게 안정적으로 영상을 배포하는 데 강하다. HTTP와 CDN을 활용할 수 있고, 네트워크 상황에 따라 화질을 조절하기 쉽다.

반면 WebRTC는 초저지연 실시간 통신에 강하다. 시청자가 방송을 보기만 하는 구조가 아니라, 서로 말하거나 반응해야 하는 서비스에 더 적합하다.

정리하면 다음과 같다.

많은 사람이 안정적으로 봐야 한다 → HLS / DASH
지연시간을 줄인 HTTP 배포가 필요하다 → LL-HLS
상호작용이 중요하다 → WebRTC

Q2. RTMP와 SRT는 둘 다 송출용인데, 왜 SRT를 따로 공부해야 할까?

RTMP는 여전히 많이 쓰인다. OBS, YouTube Live, Twitch 같은 서비스와 호환성이 좋고 설정도 익숙하다.

하지만 RTMP는 TCP 기반이고, 오래된 구조를 갖고 있다. 네트워크 품질이 나쁘거나 장거리 송출을 할 때 지연이나 끊김 문제가 커질 수 있다.

SRT는 UDP 기반이면서도 손실 복구, 지터 대응, 암호화, latency 제어를 제공한다. 그래서 공용 인터넷, 원격지 송출, LTE/5G, 해외 회선처럼 네트워크가 예측하기 어려운 환경에서 더 유리할 수 있다.

간단하고 호환성이 중요하다 → RTMP
불안정한 네트워크에서 안정성이 중요하다 → SRT

Q3. SRT latency는 낮을수록 좋은 걸까?

처음에는 latency 값을 무조건 낮추면 좋은 줄 알았다. 하지만 SRT에서 latency는 재전송과 지터를 흡수하기 위한 버퍼 시간이다.

너무 낮으면 손실 패킷이 재전송되어도 제시간에 도착하지 못한다. 이 경우 화면 깨짐이나 오디오 끊김이 생길 수 있다.

반대로 너무 높으면 안정성은 좋아지지만 전체 지연시간이 증가한다.

따라서 SRT latency는 “낮을수록 좋은 값”이 아니라, 네트워크 품질에 맞춰 조정해야 하는 값이다.

Q4. SRT는 시청자에게 직접 배포하는 프로토콜일까?

일반적으로는 그렇지 않다. SRT는 브라우저에서 바로 재생하는 시청자용 배포 프로토콜이라기보다, 송출자와 서버 사이의 안정적인 전송에 더 많이 사용된다.

실제 서비스에서는 다음과 같은 구성이 더 자연스럽다.

OBS / 카메라
  → SRT
  → 미디어 서버
  → HLS / DASH / WebRTC
  → 시청자

즉 SRT는 최종 시청자에게 보여주는 방식이라기보다, 좋은 품질의 원본 스트림을 서버까지 안정적으로 가져오는 역할에 가깝다.

Q5. WHIP과 WHEP은 왜 등장했을까?

WebRTC는 실시간 미디어 전송에는 강하지만, signaling 방식은 서비스마다 다르게 구현되는 경우가 많다. 여기서 signaling은 연결을 시작하기 위해 SDP offer/answer나 ICE candidate 같은 정보를 주고받는 과정을 말한다.

WHIP은 WebRTC 기반 송출을 HTTP 방식으로 단순화하려는 프로토콜이다. 쉽게 말해 “WebRTC로 서버에 송출할 때 표준화된 입구”를 만드는 시도라고 볼 수 있다.

WHEP은 반대로 WebRTC 기반 시청을 HTTP 방식으로 단순화하려는 프로토콜이다. “WebRTC로 서버에서 시청자에게 내보내는 출구”에 가깝다.

WHIP = WebRTC 인제스트
WHEP = WebRTC 이그레스

다만 WHEP은 표준화 상태가 변동될 수 있으므로, 실제 도입 전에는 IETF Datatracker나 사용하는 미디어 서버의 지원 상태를 확인하는 것이 좋다.

설계 관점에서 다시 보기

실제 프로젝트에서 프로토콜을 선택한다면, 먼저 “내가 해결하려는 문제가 무엇인가?”를 정해야 한다.

선택 기준

질문중요하게 볼 기준
시청자가 많은가?CDN 친화성, 캐싱, 플레이어 호환성
지연시간이 중요한가?end-to-end latency, 버퍼링 구조
양방향 상호작용이 필요한가?WebRTC, SFU, TURN 구성
송출 네트워크가 불안정한가?SRT, 재전송, latency 튜닝
브라우저에서 바로 재생해야 하는가?HLS, DASH, WebRTC 지원 여부
DRM이나 유료 콘텐츠 보호가 필요한가?DASH/HLS 패키징, DRM, 토큰 인증
인코더/OBS 호환성이 중요한가?RTMP, SRT, WHIP 지원 여부

프로토콜 비교

선택지장점단점적합한 상황
HLS호환성 좋음, CDN 친화적, 안정적일반적으로 지연시간이 큼대규모 라이브, VOD, OTT
LL-HLSHLS 생태계를 유지하면서 지연 감소구성 복잡, 지원 여부 확인 필요스포츠, 라이브 커머스, 저지연 방송
MPEG-DASH표준 기반, DRM/OTT에 유리Apple 생태계에서는 HLS 고려 필요Android/Web 중심 OTT
WebRTC초저지연, 양방향 통신 가능대규모 확장과 운영이 복잡화상회의, 실시간 경매, 인터랙티브 방송
RTMP지원 범위 넓음, 설정 쉬움오래된 구조, 불안정망 대응 한계OBS 송출, 기존 플랫폼 인제스트
SRT불안정한 네트워크에 강함, 암호화 가능브라우저 직접 재생용은 아님원격 송출, 방송국/클라우드 인제스트
WHIPWebRTC 송출을 단순화지원 생태계 확인 필요WebRTC 기반 인제스트
WHEPWebRTC 재생을 단순화하려는 방식표준화/지원 상태 확인 필요WebRTC 기반 저지연 시청

프로젝트 상황별 판단 예시

1. 일반적인 라이브 방송 플랫폼

요구사항이 “많은 시청자가 안정적으로 보는 것”이라면 HLS 또는 DASH가 자연스럽다.

OBS → RTMP/SRT → 미디어 서버 → HLS/DASH → CDN → 시청자

이 구조에서는 송출 프로토콜과 배포 프로토콜을 분리해서 생각하는 것이 중요하다.

  • 송출: RTMP 또는 SRT
  • 배포: HLS 또는 DASH

2. 네트워크가 불안정한 야외 현장 송출

야외 행사, 이동 중계, 해외 회선, LTE/5G 환경에서는 SRT가 좋은 선택지가 될 수 있다.

현장 카메라 → SRT → 클라우드 서버 → HLS/LL-HLS → 시청자

이때는 다음 값을 특히 신경 써야 한다.

  • SRT latency
  • 업로드 대역폭
  • 비디오 bitrate
  • packet loss
  • burst loss
  • 암호화 설정
  • streamid 라우팅

3. 실시간 상호작용이 필요한 서비스

시청자가 단순히 보는 것이 아니라 실시간으로 대화하거나 반응해야 한다면 WebRTC를 고려해야 한다.

브라우저 → WebRTC → SFU → WebRTC → 브라우저

예를 들면 다음과 같은 서비스다.

  • 화상회의
  • 원격 수업
  • 실시간 경매
  • 라이브 퀴즈
  • 원격 제어
  • 인터랙티브 방송

다만 WebRTC는 TURN 서버, SFU 확장, signaling 서버, 네트워크 정책까지 함께 설계해야 한다.

내가 내린 결론

처음에는 프로토콜 이름들이 단순히 나열된 것처럼 느껴졌다. HLS도 스트리밍이고, WebRTC도 스트리밍이고, SRT도 스트리밍이면 “뭘 써야 하지?”라는 생각이 들었다.

정리해보니 핵심은 프로토콜을 기능별로 나누는 것이었다.

시청자에게 나눠주는가?
→ HLS / LL-HLS / DASH

실시간으로 상호작용해야 하는가?
→ WebRTC

서버로 안정적으로 밀어 넣어야 하는가?
→ RTMP / SRT / WHIP

WebRTC 송출과 재생을 표준 HTTP 방식으로 단순화하고 싶은가?
→ WHIP / WHEP

특히 SRT를 공부하면서 인상적이었던 부분은, “UDP 기반이라 빠르다”에서 끝나지 않는다는 점이었다. SRT는 UDP 위에 ACK/NAK, ARQ, latency buffer, TSBPD, Too-Late Packet Drop, 암호화 같은 기능을 얹어서 라이브 영상 전송에 필요한 균형을 맞춘다.

완벽한 전송보다 중요한 것은 “라이브에 맞는 전송”이다. SRT는 이 지점을 잘 보여주는 프로토콜이라고 느꼈다.

더 공부해볼 내용

이번 글에서는 스트리밍 프로토콜을 큰 흐름 중심으로 정리했다. 다음으로는 아래 주제를 더 깊게 공부해볼 수 있다.

1. SRT 튜닝 딥다이브

  • latency 설정
  • RTT 측정
  • packet loss와 burst loss
  • oheadbw
  • streamid 라우팅
  • OBS/FFmpeg/SRS 설정 예시

2. WebRTC 내부 구조

  • SDP offer/answer
  • ICE candidate
  • STUN/TURN
  • DTLS-SRTP
  • SFU 구조
  • WHIP/WHEP 흐름

3. HLS/LL-HLS/DASH 패키징

  • MPEG-TS
  • fMP4
  • CMAF
  • playlist/manifest 구조
  • ABR ladder
  • CDN 캐싱 전략

4. 실제 라이브 스트리밍 아키텍처

  • OBS 송출
  • 미디어 서버 인제스트
  • 트랜스코딩
  • 패키징
  • CDN 배포
  • 모니터링
  • 장애 대응

마무리

이번 글을 통해 내가 이해한 핵심은 다음과 같다.

  • 스트리밍 프로토콜은 모두 같은 역할을 하지 않는다.
  • HLS와 DASH는 대규모 배포에 강하고, WebRTC는 초저지연 상호작용에 강하다.
  • RTMP와 SRT는 주로 서버로 영상을 보내는 인제스트 단계에서 많이 쓰인다.
  • SRT는 UDP 기반이지만 손실 복구, 지연 제어, 암호화를 제공해 불안정한 네트워크에서 유리하다.
  • 실제 프로젝트에서는 프로토콜 자체보다 “송출, 배포, 실시간성, 확장성, 네트워크 품질”을 기준으로 선택해야 한다.

기술을 공부하다 보면 이름을 외우는 데 집중하게 될 때가 있다. 하지만 이번에 정리하면서 느낀 것은, 프로토콜의 이름보다 중요한 것은 어떤 문제를 해결하기 위해 만들어졌는지를 이해하는 것이라는 점이다.

이 글을 한 문장으로 요약하면

라이브 스트리밍 프로토콜은 하나의 정답을 고르는 문제가 아니라, 송출·배포·실시간성·네트워크 품질이라는 조건에 맞춰 적절한 도구를 선택하는 설계 문제다.

댓글 0

이름과 비밀번호를 입력하면 바로 댓글을 남길 수 있습니다.