SRT 스트리밍이란? SRT와 RTMP 차이 쉽게 정리

SRT는 불안정한 네트워크에서도 버틸 수 있도록 만든 영상 전송 프로토콜입니다. 손실된 패킷을 어떻게 복구하는지, 지연 시간(latency) 설정이 무슨 역할을 하는지, RTMP와 어떻게 다른지, 그리고 왜 대부분의 플랫폼이 여전히 RTMP를 요구하는지 알려 드립니다.

StreamHouse Team게시일 2026년 10월 30일 · 읽는 데 약 6분

이 페이지의 내용

SRT(Secure Reliable Transport)는 공용 인터넷처럼 예측하기 어려운 네트워크에서 라이브 영상을 보내기 위한 오픈 소스 프로토콜입니다. UDP 위에서 작동하며, 손실된 패킷을 다시 요청하고, 안정성을 위해 지연을 얼마나 감수할지 직접 정할 수 있으며, 방송 신호를 암호화할 수도 있습니다. 방송사들은 SRT로 여러 장소 사이에서 고품질 신호를 주고받습니다.

모든 곳에서 RTMP를 대체하는 것은 아니지만, 특정 문제는 아주 잘 해결합니다. 작동 방식과 언제 쓸 만한지 살펴보겠습니다.

핵심 요약
SRT는 UDP를 사용하며, 직접 설정한 지연 시간 범위 안에서 손실된 패킷을 복구합니다.
원격 행사장이나 컨트리뷰션(송출 원본) 신호처럼 장거리이거나 손실이 많은 연결에 적합합니다.
대부분의 크리에이터 플랫폼은 여전히 RTMP 또는 RTMPS 인제스트를 안내합니다.
공유 암호 문구를 사용하는 AES 암호화가 전송 중인 SRT 신호를 보호합니다.

SRT의 탄생 배경과 해결하려는 문제

SRT는 영상 기술 기업 Haivision이 개발해 2017년에 오픈 소스로 공개했습니다. 지금은 OBS와 FFmpeg를 비롯해 다양한 인코더, 디코더, 미디어 서버, 소프트웨어에서 지원합니다.

SRT가 겨냥하는 문제는 간단히 설명할 수 있습니다. 공용 인터넷은 특히 장거리, 혼잡한 Wi-Fi, 모바일 회선에서 패킷을 잃어버리거나 순서를 뒤섞습니다. 기존 방송 회선은 전용 회선이나 위성 대역으로 이 문제를 피했습니다. SRT는 그 대신 평범한 인터넷 연결에서 방송 수준의 안정성을 제공하는 것을 목표로 합니다.

그러면서도 방송 신호 안에 무엇이 들어 있는지는 크게 신경 쓰지 않습니다. SRT는 영상 형식이 아니라 전송 방식이며, 가장 흔하게는 H.264 또는 HEVC 영상과 AAC 오디오를 담은 MPEG 전송 스트림을 실어 나릅니다. 이런 유연성 덕분에 전문 제작 현장에서 빠르게 채택되었습니다.

패킷 복구와 지연 버퍼의 작동 방식

RTMP는 TCP 위에서 작동합니다. TCP는 손실된 데이터를 재전송하지만, 손실이 감지될 때마다 연결 전체의 속도를 늦춥니다. 손실이 많은 장거리 연결에서는 이것이 멈춤과 버퍼링으로 나타납니다.

SRT는 UDP를 사용하고 복구를 스스로 처리합니다. 수신 측은 패킷을 짧은 버퍼에 보관합니다. 순서에 빈틈이 보이면 송신 측에 빠진 패킷만 다시 보내 달라고 요청합니다. 해당 구간의 영상이 버퍼를 떠나기 전에 대체 패킷이 도착하면, 그 뒤의 누구도 문제를 알아채지 못합니다.

이 버퍼의 크기가 바로 지연 시간(latency) 설정입니다. 값을 크게 하면 더 나쁜 네트워크도 견딜 수 있지만 지연이 늘어나고, 값을 작게 하면 지연은 낮게 유지되지만 너무 늦게 도착한 패킷은 버려집니다. 일반적인 출발점은 송신 측과 수신 측 사이 왕복 시간의 몇 배 정도이며, 불안정한 연결이라면 더 높입니다. 도구마다 지연 시간을 표시하는 단위가 다르니 문서를 확인하세요.

암호화, 스트림 ID, 연결 모드

SRT에는 RTMP 자체로는 제공하지 않는 기능이 있습니다.

암호화. 양쪽이 공유하는 암호 문구로 AES 암호화를 하며, 128, 192, 256비트 키를 사용합니다. RTMP는 암호화하려면 별도 변형인 RTMPS가 필요합니다.
스트림 ID. 수신 포트 하나로 여러 신호를 받아 각각 올바르게 분배할 수 있게 해 주는 선택적 식별자로, 스트림 키와 조금 비슷합니다.
연결 모드. 한쪽이 포트에서 대기(listener)하고 다른 쪽이 호출(caller)합니다. 세 번째 모드인 랑데부(rendezvous)는 양쪽이 동시에 연결하는 방식으로, 둘 다 방화벽 뒤에 있을 때 도움이 될 수 있습니다.

SRT는 UDP를 사용하므로, 외부로 나가는 TCP 연결을 쓰는 RTMP와 달리 경로상의 모든 방화벽에서 대기 측 UDP 포트가 열려 있어야 합니다. RTMP 쪽은 RTMP의 작동 방식과 RTMP와 RTMPS 비교를 참고하세요.

SRT vs RTMP: 각각이 이기는 영역

어느 프로토콜이 무조건 더 좋은 것은 아닙니다. 잘하는 일이 서로 다를 뿐입니다.

컨트리뷰션에서는 SRT가 이깁니다. 원격 행사장, 현장 제작팀, 모바일 회선에서 제작 거점으로 신호를 보낼 때 패킷 복구가 진가를 발휘하며, 송출 시스템, 디코더, 미디어 서버로 이어지는 방송 체인에서도 마찬가지입니다.
거리에는 SRT가 더 강합니다. 손실과 지터가 있는 대륙 간 연결에서는 잘 조정한 지연 버퍼가 TCP 기반 RTMP보다 대개 더 안정적인 결과를 냅니다.
호환성에서는 RTMP가 이깁니다. 거의 모든 인코더, 서비스, 플랫폼이 지원하며, 설정도 URL과 키만 있으면 됩니다.
배포는 RTMP가 더 간단합니다. UDP 포트, 지연 시간 조정, 암호 문구를 맞출 필요가 없습니다.

실용적인 원칙은 이렇습니다. 본인이나 파트너가 관리하는 시스템 사이에서는 SRT를, 공개 플랫폼으로 들어가는 마지막 구간에서는 RTMP나 RTMPS를 사용하세요.

YouTube, Twitch 등 대부분의 플랫폼이 아직 RTMP를 요구하는 이유

SRT가 그렇게 튼튼하다면, 왜 주요 크리에이터 플랫폼은 여전히 RTMP와 RTMPS 인제스트를 안내할까요?

첫째는 호환성입니다. 플랫폼은 휴대폰 앱부터 오래된 하드웨어 인코더까지 모든 스트리머가 연결할 수 있기를 원하고, RTMP는 그 모두가 쓰는 프로토콜입니다. 둘째, 대부분의 크리에이터는 집에서 가까운 인제스트 서버로 송출하므로 TCP로도 충분히 잘 작동합니다. 셋째, 플랫폼들은 수년에 걸쳐 RTMP를 중심으로 인증, 키 관리, 모니터링 체계를 구축해 왔습니다.

이 구도는 바뀌고 있습니다. 일부 플랫폼과 많은 전문 영상 서비스는 SRT나 다른 최신 인제스트 프로토콜을 받습니다. 하지만 이 글을 쓰는 시점 기준으로 주류 소셜 또는 게임 플랫폼은 대개 RTMP나 RTMPS URL을 제공합니다. 이런 송출 대상의 작동 방식은 커스텀 RTMP 스트리밍 가이드에서 설명합니다.

하나의 클라우드 방송에서 RTMP와 SRT 동시에 송출하기

많은 환경에서 두 프로토콜이 동시에 필요합니다. 공개 플랫폼에는 RTMP를, 스튜디오나 송출 서버, 파트너의 수신 장비에는 SRT를 보내야 하는 경우입니다. 집에 있는 인코더라면 출력 두 개와 두 배의 업로드가 필요합니다.

StreamHouse는 이를 클라우드에서 처리합니다. 같은 방송에 RTMP나 RTMPS로 YouTube, Twitch, Kick을 추가하고, 수신 장비를 가리키는 커스텀 SRT 출력도 추가하세요. 방송 하나가 모든 곳에 닿으며, 송출 대상을 추가해도 방송 슬롯이 더 들지 않습니다.

사전 녹화 프로그램이라면 영상을 업로드하세요. 영상은 하나의 일관된 인코딩 프로필로 미리 준비됩니다. 그다음 재생목록을 만들고 시작하거나 예약하면 됩니다. 방송은 24시간 반복 재생되고, 네트워크에 문제가 생기면 자동으로 다시 연결되며, 컴퓨터를 꺼 두어도 계속 돌아갑니다.

자주 묻는 질문

스트리밍에는 SRT가 RTMP보다 더 좋은가요?

길거나 불안정한 네트워크 경로라면 대개 그렇습니다. SRT는 연결 전체를 멈추지 않고 손실된 패킷을 복구하기 때문입니다. 다만 주류 플랫폼은 RTMP나 RTMPS만 제공하는 경우가 많으므로, 올바른 선택은 신호를 어디로 보내느냐에 달려 있습니다.

SRT는 RTMP보다 지연 시간이 짧은가요?

그럴 수 있습니다. SRT의 전송 지연은 대략 설정한 지연 버퍼만큼이며, 좋은 네트워크에서는 작게 설정할 수 있습니다. 하지만 시청자가 체감하는 전체 지연은 플랫폼의 처리와 재생에도 좌우되므로, 프로토콜을 바꾼다고 항상 더 빠르게 느껴지지는 않습니다.

OBS로 SRT 방송을 할 수 있나요?

네. OBS에서 사용자 지정 서버로 srt:// 주소를 입력하고, 모드, 지연 시간, 암호 문구 같은 매개변수를 URL에 포함하세요. 받는 쪽 서버나 서비스가 SRT를 지원하고 연결을 받도록 설정되어 있어야 합니다.

SRT는 기본적으로 암호화되나요?

암호 문구를 설정했을 때만 암호화됩니다. 양쪽에 같은 암호 문구를 설정하면 SRT는 128, 192, 256비트 키의 AES로 신호를 암호화합니다. 암호 문구가 없으면 암호화되지 않은 채 전송되므로, 공용 인터넷을 거치는 신호에는 꼭 설정하세요.