SRT RTMP 차이와 SRTLA 비교: IRL 스트리밍에 맞는 프로토콜은?

IRL 스트리밍에서는 대체로 RTMP보다 SRT가 잘 맞고, 여러 회선으로 동시에 보낼 수 있다면 SRTLA가 가장 좋아요. 스트리밍 플랫폼이 RTMP를 기대하기 때문에 RTMP도 여전히 필요해요. 다만 모바일 네트워크가 아니라, 서버에서 플랫폼까지 이어지는 안정적인 마지막 구간에 써야 해요.

이 가이드는 SRT RTMP 차이를 중심으로 세 프로토콜이 어떻게 동작하는지, 모바일 회선에서 어떻게 달라지는지, SRT 레이턴시를 어떻게 제대로 설정하는지 설명해요.

RTMP는 무엇인가요?

RTMP(Real-Time Messaging Protocol)는 Adobe가 설계했고, 2009년에 공개 사양으로 발표됐어요. TCP처럼 신뢰할 수 있는 전송 방식 위에서 동작하도록 만들어서, 모든 메시지가 순서대로 도착하는 것을 보장해요(RTMP 사양). SRT의 IETF 초안은 RTMP를 공용 인터넷으로 영상을 보내는 사실상의 표준이라고 불러요. 거의 모든 인코더와 앱, 플랫폼이 RTMP를 지원하는 이유예요.

약점도 같은 설계에서 나와요. RTMP는 TCP에 의존해서 왕복 시간이 짧은 연결에서만 쓸 만한 안정성을 내요. TCP 혼잡 제어 때문에 연결의 대역폭을 끝까지 쓰지도 못해요. 기지국 사이를 계속 옮겨 다니는 스마트폰에는 잘 맞지 않아요.

기존 RTMP는 코덱에도 제한이 있어요. 오디오는 2채널까지, 코덱도 일부만 지원하고 HEVC, VP9, AV1은 쓸 수 없어요. Enhanced RTMP 사양이 이 코덱들을 추가했고, YouTube도 이제 RTMP(S)용으로 H.264, H.265, AV1을 안내해요. 다만 사용하는 소프트웨어와 플랫폼이 둘 다 지원해야 해요. RTMPS는 암호화된 SSL 연결 안에서 RTMP를 쓰는 방식이고, YouTube도 바로 그 이유로 RTMPS를 권장해요.

SRT는 무엇인가요?

SRT(Secure Reliable Transport)는 오픈 소스 프로토콜이에요. Haivision의 공개 GitHub 저장소에서 개발되고 IETF Internet-Draft에 설명돼 있어요. UDP 위에서 동작하면서, UDP만으로는 부족한 신뢰성을 더해요. 핵심 방식은 ARQ(Automatic Repeat reQuest)예요. 수신 측이 빠진 패킷을 알아채면 송신 측에 그 패킷을 다시 보내 달라고 요청해요. Forward Error Correction과 자체 커넥션 본딩도 지원해요.

IRL 스트리밍에서는 세 가지 특성이 중요해요.

• 레이턴시 버퍼: 수신 측은 모든 패킷을 설정된 시간만큼 붙들고 있다가 다음으로 넘겨요. 이 시간 덕분에 유실된 패킷을 재전송할 여유가 생기고, 스트림 원래의 타이밍도 복원돼요. 너무 늦게 도착한 패킷은 버려질 수 있어서, 지연이 계속 커지지 않고 일정하게 유지돼요.
• 암호화: SRT는 128, 192, 256비트 키의 AES 암호화를 지원해요.
• 코덱 독립성: SRT는 페이로드를 가리지 않아요. HEVC를 포함해 어떤 코덱, 해상도, 프레임 레이트도 전송해요.

트레이드오프는 설계에 이미 들어 있어요. 버퍼는 일부러 지연을 더하기 때문에, 네트워크에 맞는 레이턴시 값을 골라야 해요(아래에서 더 설명해요).

SRTLA는 무엇인가요?

SRTLA는 링크 애그리게이션을 지원하는 SRT 전송 프록시예요. BELABOX 프로젝트에서 시작됐고, SRT 트래픽을 여러 네트워크 회선으로 보내서 대역폭과 이중화를 확보해요. 트래픽은 네트워크 상태에 따라 동적으로 분배되고, 라이브 스트리밍을 위해 모바일 모뎀을 본딩하는 용도를 염두에 두고 있어요.

SRTLA가 SRT를 대체하지는 않아요. SRT 송신 측과 수신 측 사이에 들어가요. 예를 들어 SIM 카드 두 장, 또는 SIM 한 장과 Wi-Fi로 기기가 SRT 스트림을 내보내면, SRTLA를 이해하는 수신 측이 패킷을 다시 맞춰서 일반 SRT 스트림으로 넘겨줘요. 실제로는 세 가지를 알아 둬야 해요.

• SRTLA를 지원하는 송신 측이 필요해요. 예를 들어 무료 iOS 앱 Moblin은 모바일 회선 하나, Wi-Fi 하나, 여러 이더넷 연결을 동시에 쓸 수 있어요. IRL Pro와 BELABOX 기기도 SRTLA 본딩을 제공해요.
• SRTLA 수신 측이 필요해요. 스트리밍 플랫폼이나 일반 SRT 리스너는 처리하지 못해서, SRTLA 입력을 받는 서버가 중간에 있어야 해요.
• 튜닝이 필요해요. 패킷이 회선마다 순서가 뒤섞여 도착해요. 그래서 README는 lossmaxttl 같은 수신 측 옵션과 알맞은 레이턴시를 요구해요.

RTMP, SRT, SRTLA 한눈에 비교

플랫폼이 RTMP를 원하는 이유와 중간에 서버를 두는 이유

대형 플랫폼의 인코더 문서는 지금도 RTMP 중심이에요. YouTube는 인코더 프로토콜로 RTMP/RTMPS를 안내하고(대안은 HLS), Twitch 개발자 문서도 RTMP로 스트림을 Twitch에 보내는 방법을 설명해요. 그래서 대부분은 SRT나 SRTLA를 플랫폼에 직접 연결할 수 없어요.

서버를 두면 이 문제가 풀리고, 장점이 하나 더 생겨요. 구성은 이렇게 돼요.

1. 휴대폰이나 인코더가 서버로 SRT 또는 SRTLA(또는 RTMP)를 보내요.
2. OBS Studio 같은 스트리밍 소프트웨어가 그 서버에서 스트림을 가져와요.
3. OBS가 완성된 스트림을 안정적인 연결로 RTMP(S)를 통해 플랫폼에 보내요.

불안정한 모바일 구간에는 더 너그러운 프로토콜을 쓰고, 플랫폼에는 움직이지 않는 연결로 기대하는 프로토콜을 전달해요. 모바일 신호가 잠깐 끊겨도 OBS가 플랫폼으로 계속 스트리밍하기 때문에, 시청자 입장에서는 방송이 끝나지 않아요. 인코더와 OBS 모두 서버를 향해 밖으로 연결하므로 라우터의 포트를 열 필요도 없어요.

내 PC의 OBS와 함께 이 역할을 해 주는 것이 저희 IRL 엔드포인트 서버예요. RTMP, SRT, SRTLA를 입력으로 받아요. 스트리밍용 PC가 없다면 IRL 브로드캐스팅 서버가 클라우드에서 OBS Studio를 실행하고, 같은 세 가지 입력을 받아요. IRL 환경 전체의 큰 그림은 IRL 스트리밍 가이드를 참고해 주세요.

SRT 레이턴시를 설정하는 방법

SRT 레이턴시는 카메라에서 시청자까지의 전체 지연이 아니에요. Haivision 문서에서는 네트워크로 보내면서 생기는 지연만을 뜻해요. 인코딩, 디코딩, OBS, 플랫폼의 지연은 여기에 더해져요. 이 설정이 실제로 정하는 것은 늦게 온 패킷과 재전송을 보정하려고 수신 측이 더 기다리는 시간이에요.

OBS 지식 베이스는 가장 중요한 옵션에 대한 경험칙을 알려 줘요.

• 기본값은 120 ms예요.
• 값은 인코더와 서버 사이 왕복 시간(밀리초)의 최소 2.5배여야 해요.
• OBS가 쓰는 FFmpeg 방식 URL에서는 단위가 마이크로초예요. 레이턴시 1초는 latency=1000000으로 써요.

예를 들어 서버로 ping을 보냈을 때 왕복 시간이 80 ms라면, 이 규칙에 따라 최솟값은 200 ms예요. 그래서 srt://SERVER:PORT?latency=200000을 입력해요. 주소와 포트는 고객 포털에 나온 그대로 쓰세요. OBS에서는 이런 옵션을 미디어 소스나 사용자 지정 스트림 대상의 SRT URL 뒤에 붙일 수 있어요.

저희 서버로 보내는 스트림에는 레이턴시 2초를 권장해요. 앱에 따라 2000(밀리초) 또는 2000000(마이크로초)로 입력해요. 대부분 전용 입력란이 있어요. 없다면 SRT URL 뒤에 붙이세요. 예: srt://<server>:<port>?streamid=publish:publish/<streamkey>&latency=2000. 더 낮은 값도 쓸 수 있지만, 안정성을 위해 일부러 2초를 권장해요.

몇 가지 더 기억해 두세요.

• 단위가 달라요. SRT 라이브러리와 SRTLA README는 밀리초를, FFmpeg 방식 URL은 마이크로초를 써요. 값을 입력하기 전에 앱이 어떤 단위를 기대하는지 확인하세요.
• 양쪽이 협상해요. SRT 초안에 따르면 연결의 레이턴시는 송신 측과 수신 측이 제안한 값 중 큰 쪽이에요. 한쪽에서 낮춰도 다른 쪽이 더 많이 요구하면 소용없어요.
• 모바일과 본딩 스트림에는 여유가 필요해요. 위 규칙은 권장값이 아니라 최솟값이에요. 구간이 크면 재전송과 재정렬에 쓸 시간이 늘지만, 지연도 커져요. 예를 들어 SRTLA README는 샘플 수신 설정에서 latency=2000(ms)을 lossmaxttl과 함께 써요.
• 한 번에 하나만 바꾸고, 책상 앞에서만이 아니라 이동하면서도 테스트하세요.

서버 위치와 레이턴시

SRT 최소 레이턴시는 왕복 시간에 비례하므로 거리가 중요해요. 서버가 가까울수록 왕복 시간이 짧아서, 더 작은 레이턴시 구간을 쓰거나 같은 안정성을 더 적은 지연으로 얻을 수 있어요. 마지막 구간에도 같은 논리가 적용돼요. 예를 들어 Twitch는 기기까지의 네트워크 경로를 기준으로 인제스트 엔드포인트를 추천해요.

서버 지역은 미국, 유럽, 아시아, 남미 중에서 고를 수 있어요. IRL 엔드포인트 서버는 스탠더드 요금제에서 지역을 고를 수 있고 고객 포털에서 언제든 바꿀 수 있어서, 여행할 때 도움이 돼요. Dedicated 요금제에서는 저희가 엔드포인트를 설정해 드려요. 기본값은 청구 주소와 가장 가까운 위치예요.

어떤 프로토콜을 써야 할까요?

• 연결 하나, 최신 앱: SRT를 쓰고, 왕복 시간을 기준으로 레이턴시를 설정하세요.
• 연결 둘 이상: 앱이 지원하고 서버가 받아 준다면 SRTLA를 쓰세요.
• RTMP만 되는 앱이나 카메라: RTMP를 쓰세요. 동작은 하지만 약한 네트워크에는 덜 너그러워요.
• HEVC: SRT는 코덱에 독립적이에요. 인코더에서 OBS, 플랫폼까지 전체 구간이 지원하는지 확인하세요. 인코더의 키프레임 간격은 2초로 설정하고, Apple 기기에서 HEVC를 쓸 때는 앱이 지원하면 B-프레임을 꺼 두세요.

FAQ

IRL 스트리밍에서 SRT가 RTMP보다 나은가요?

모바일 구간에서는 대체로 그래요. SRT는 UDP로 동작하고 설정 가능한 레이턴시 구간 안에서 유실된 패킷을 재전송하는 반면, RTMP는 TCP에 의존해서 왕복 시간이 짧은 연결에서만 안정적이에요. 서버나 OBS에서 플랫폼으로 가는 연결에는 지금도 RTMP가 흔한 선택이에요.

SRT와 SRTLA는 뭐가 다른가요?

SRT는 연결 하나를 위한 전송 프로토콜이에요. SRTLA는 SIM 카드 두 장처럼 여러 네트워크 회선으로 SRT 트래픽을 동시에 보내서 대역폭과 이중화를 더해요. SRTLA에는 SRTLA를 지원하는 앱과 이를 이해하는 수신 측이 필요해요.

SRT로 Twitch나 YouTube에 바로 스트리밍할 수 있나요?

두 플랫폼의 인코더 문서는 RTMP(S) 중심이고, YouTube는 대안으로 HLS를 안내해요. 모바일 구간에서 SRT나 SRTLA를 쓰고 싶다면 기기와 플랫폼 사이에 서버와 OBS를 두세요.

SRT 레이턴시는 얼마로 설정해야 하나요?

저희 서버로 보내는 스트림에는 2초를 권장해요. 앱에 따라 2000(밀리초) 또는 2000000(마이크로초)로 입력해요. 더 낮은 값도 쓸 수 있지만, 2초는 안정성을 위해 일부러 정한 권장값이에요. 일반적인 기준으로 OBS 지식 베이스는 서버까지 왕복 시간의 최소 2.5배, 기본값은 120 ms라고 해요. 모바일 네트워크와 본딩 연결은 보통 더 여유가 필요하고, 그만큼 지연이 늘어요.

IRL 엔드포인트 서버는 세 가지 프로토콜을 모두 지원하나요?

네. IRL 엔드포인트 서버와 IRL 브로드캐스팅 서버는 RTMP, SRT, SRTLA를 입력으로 받아요.