RTMP와 SRT 차이: 실내 방송·야외 중계에 맞는 송출 방식 고르기

사무실에서 잘되던 라이브 방송이 야외 행사장에서는 끊긴다면, 같은 송출 설정을 그대로 유지해도 되는지 고민하게 됩니다. 이때 비교할 수 있는 선택지가 RTMP 계열과 SRT입니다. 다만 둘의 이름만 바꾸면 회선 문제가 모두 해결되는 것은 아닙니다.

이 글은 인코더에서 플랫폼이나 수신 서버로 영상을 보내는 구간을 다룹니다. 시청자의 브라우저에 전달하는 방식과 구분해서, 실내 방송과 야외 중계에서 어떤 조건을 먼저 확인해야 하는지 정리합니다.

1. RTMP는 플랫폼이 받는 방식을 먼저 확인합니다

RTMP는 Real-Time Messaging Protocol의 약자입니다. 방송 프로그램이나 하드웨어 인코더에서 수신 서버로 영상을 보내는 데 사용됩니다. 일반적인 RTMP 송출은 TCP 연결을 사용하며, 암호화가 필요한 구간에서는 TLS로 보호하는 RTMPS 지원 여부를 확인합니다. MediaMTX의 RTMP 안내는 두 방식의 서버 설정을 설명합니다.

실무에서 눈에 띄는 장점은 목적지 플랫폼의 안내에 맞춰 송출 경로를 구성하기 쉽다는 점입니다. 예를 들어 YouTube는 RTMPS 송출 안내를 제공합니다. 사용하는 인코더가 그 방식과 요구 코덱을 지원한다면, 플랫폼이 발급한 서버 주소와 스트림 키를 기준으로 설정할 수 있습니다.

따라서 안정적인 유선 회선에서 정해진 플랫폼으로 강의나 행사를 송출한다면 RTMPS를 먼저 검토할 수 있습니다. 이미 지원되는 입력 경로가 있는데 SRT를 추가하면 수신 서버나 변환 구간이 더 필요해질 수 있으므로, 목표에 비해 구성이 복잡해지지 않는지 판단합니다.

직접 제작한 송출 구간 비교도. RTMPS와 SRT는 현장 영상을 받는 구간의 선택지이며, 수신 이후 시청자 배포 방식은 따로 정합니다. 회선 상태만으로 선택이 확정되지는 않습니다.

2. SRT는 손실 복구와 지연 여유를 함께 봅니다

SRT는 Secure Reliable Transport의 약자입니다. UDP를 바탕으로 미디어를 운반하며, 수신 측이 누락을 감지하면 재전송을 요청하는 ARQ 같은 복구 기능을 제공합니다. 이 구조는 Haivision의 SRT 공식 프로젝트에서 설명합니다. 원격 현장에서 서버로 영상을 보내는 구간의 후보로 검토하기 좋습니다.

장점은 패킷 손실이나 도착 시간의 흔들림을 고려해 전송을 조정할 수 있다는 점입니다. 하지만 복구에는 시간과 추가 대역폭이 필요합니다. SRT의 지연 버퍼를 너무 작게 잡으면 재전송된 패킷이 재생 시한 안에 도착하지 못할 수 있습니다.

Haivision의 Latency 문서는 회선의 왕복 시간과 손실 상태를 바탕으로 버퍼를 정하도록 설명합니다. 이 설정값은 촬영부터 최종 화면까지의 전체 지연과 같지 않습니다. 카메라 처리, 인코딩, 수신 후 변환, 플레이어 버퍼가 추가되기 때문입니다.

SRT는 AES 암호화를 지원하지만, 이름에 Secure가 들어간다는 이유만으로 현재 연결이 암호화됐다고 가정하면 안 됩니다. SRT 암호화 설정 안내에 따라 송수신 양쪽의 지원과 실제 설정을 확인합니다.

3. 장점과 단점을 같은 기준으로 비교하기

기준	RTMP·RTMPS	SRT
잘 맞는 출발점	플랫폼이 제공하는 인코더 송출	원격 현장과 수신 서버 연결
주요 장점	지원 플랫폼의 기존 절차 활용	손실 복구·지연 버퍼 조정
주요 한계	TCP 재전송 대기로 지연 가능	복구용 시간·대역폭과 수신 지원 필요
전송 보호	RTMPS의 TLS 지원 확인	AES 암호화 설정 확인
브라우저 시청	일반적으로 별도 배포 경로 사용	일반적으로 별도 배포 경로 사용

RTMP 계열의 TCP 재전송은 데이터 전달을 돕지만, 손실된 구간을 기다리면서 지연이 늘 수 있습니다. 반면 SRT도 회선이 장시간 끊기거나 전송량이 지속적으로 회선 용량을 넘으면 원본을 온전히 전달할 수 없습니다. “SRT는 어떤 인터넷에서도 무손실”이라는 식의 표현은 도입 판단에 도움이 되지 않습니다.

또한 프로토콜 지원과 코덱 지원은 별개입니다. RTMP 계열도 서버와 인코더가 지원하는 확장 기능에 따라 가능한 코덱이 달라질 수 있고, SRT 역시 내부에 담는 미디어 형식과 수신기의 디코딩 능력이 맞아야 합니다. 양쪽에 같은 프로토콜 이름이 적혀 있다는 사실만으로 호환성이 끝나지는 않습니다.

4. 세 가지 송출 상황에 적용해 보기

사내 교육 방송을 특정 플랫폼에 올리는 경우에는 플랫폼이 안내하는 RTMPS 경로를 먼저 시험합니다. 유선망에서 인코더 부하, 목표 비트레이트, 장시간 송출과 재연결을 확인하면 됩니다. 플랫폼에서 영상을 다시 처리하는 시간까지 포함해 최종 시청 화면을 확인합니다.

야외 행사장에서 공용 인터넷이나 이동통신망으로 자체 서버에 보내는 경우에는 SRT를 비교 후보에 넣습니다. 행사장 회선의 손실과 왕복 시간, 업로드 여유를 관찰하면서 허용 지연 안에서 버퍼를 조정합니다. 동일한 입력과 비트레이트로 비교해야 프로토콜 차이와 인코딩 설정 차이를 구분하기 쉽습니다.

현장에서는 SRT를 쓰고 최종 플랫폼은 RTMPS만 받는 경우에는 중간 수신 서버가 SRT를 받아 RTMPS로 다시 내보내는 구성을 검토할 수 있습니다. 이때 두 전송 구간과 서버 처리 시간이 쌓입니다. 중간 서버 장애의 영향, 비용, 영상·음성 호환성까지 포함해서 이 구성이 필요한지 판단합니다.

5. 연결 성공 후에도 남는 확인 항목

먼저 누가 연결을 시작하고 어느 서버가 기다리는지 적습니다. SRT에서는 연결 모드와 UDP 경로가 맞아야 하고, RTMPS에서는 목적지 주소와 TLS 연결, 스트림 키가 맞아야 합니다. 네트워크가 막힌 문제와 비트레이트가 과도한 문제를 같은 “끊김”으로 묶지 않는 편이 좋습니다.

그다음 송신 비트레이트, 사용 가능한 업로드 대역폭, 재전송·손실 기록, 인코더의 처리 지연을 함께 봅니다. 회선에 여유가 없으면 복구 패킷을 보낼 공간도 부족해집니다. 초기 판단에서 최고 화질만 정하기보다, 혼잡할 때 낮출 화질과 송출 실패 시의 대체 경로도 정해 두세요.

마지막으로 수신 서버의 영상과 실제 시청 화면을 각각 확인합니다. 송출이 안정적이어도 시청자 배포 서버나 플레이어에서 문제가 생길 수 있습니다. 송출 키와 암호화 비밀값은 글이나 화면 캡처에 넣지 않고, 시험 기록에는 방식과 조건만 남기면 됩니다.

카메라 입력부터 전체 경로를 이해하려면 CCTV 영상의 서버 연결 구조를, 수신 이후 웹 전달을 고를 때는 WebRTC와 HLS 비교 글을 이어서 읽어 보세요.

자료 확인일: 2026년 9월 9일. 공식 문서에 근거한 송출 방식 선택 가이드입니다. 사례는 가상 구성이며, 특정 회선의 손실률이나 지연을 측정한 결과가 아닙니다.