RTSP는 언제 쓰면 좋을까? CCTV 영상 수집의 장점과 한계

CCTV를 연결할 때 rtsp://로 시작하는 주소를 자주 만나게 됩니다. 그런데 이 주소를 PC 플레이어에 넣으면 영상이 나오고, 웹페이지의 동영상 칸에 넣으면 재생되지 않는 경우가 있습니다. RTSP를 이해하려면 카메라에서 영상을 가져오는 구간과 사용자에게 보여 주는 구간을 나누어 보는 것이 좋습니다.

이번 글은 스트리밍 프로토콜 활용 연재의 첫 편입니다. 카메라 영상을 수집할 때 RTSP가 유용한 이유, TCP·UDP 전송 선택의 차이, 브라우저 서비스로 확장할 때 추가로 필요한 요소를 살펴봅니다.

1. RTSP와 RTP는 맡은 일이 다릅니다

RTSP는 Real-Time Streaming Protocol의 약자입니다. 스트리밍 세션을 설정하고 재생을 요청하는 제어 역할을 맡으며, 실제 미디어는 흔히 RTP로 운반합니다. “RTSP 영상”이라는 표현은 편리하지만 제어와 영상 데이터의 전달까지 하나의 동작으로 생각하면 연결 문제를 찾기 어렵습니다.

RTSP 2.0 규격인 IETF RFC 7826은 제어 메시지와 RTP 전송의 관계를 설명합니다. 이 문서가 모든 현장 카메라의 구현 버전을 뜻하는 것은 아닙니다. 실제 장비는 제조사 문서에서 RTSP 버전, 인증 방식, 지원 전송 방식과 스트림 경로를 확인해야 합니다.

IP 카메라는 자체 RTSP 서버를 제공하고, 녹화기나 미디어 서버가 그 주소로 접속해 영상을 읽는 구성이 흔합니다. MediaMTX의 RTSP 카메라 연결 문서도 이 수집 방식을 다룹니다. 같은 제조사라도 모델·채널·메인 스트림과 서브 스트림에 따라 주소 경로가 달라질 수 있습니다.

직접 제작한 RTSP 활용 개념도. 화살표는 주요 영상 흐름이며, RTSP의 제어 요청과 응답은 양방향으로 오갑니다. 녹화·분석과 브라우저 전달은 서버의 별도 기능입니다.

2. 어떤 상황에서 사용하면 좋을까?

첫 번째는 관리 가능한 내부망에서 CCTV와 녹화기를 연결하는 경우입니다. 이미 카메라가 제공하는 스트림을 활용할 수 있어 영상 입력 경로를 구성하기 좋습니다. 예를 들어 매장 카메라를 녹화 서버로 모으고, 관리 화면에는 서버가 다시 전달하도록 설계할 수 있습니다.

두 번째는 서버에서 영상을 분석하는 경우입니다. 카메라 입력을 받아 필요한 프레임을 디코딩한 뒤 객체 탐지나 상태 분석에 사용할 수 있습니다. RTSP가 분석 기능을 제공하는 것은 아니므로, 디코딩 부하와 분석 프로그램의 처리 속도는 별도로 계산합니다.

세 번째는 카메라 연결을 중계 서버로 모으는 경우입니다. 여러 시청자가 카메라에 각각 접속하면 장비의 동시 연결 한도에 도달할 수 있습니다. 중계 서버가 입력을 공유하도록 구성하면 카메라 측 연결을 줄일 수 있지만, 서버의 출력 대역폭과 동시 접속 부하는 여전히 남습니다.

사용 상황	RTSP의 장점	한계·확인 사항
내부망 CCTV 수집	기존 카메라 스트림 활용	장비별 주소·인증·연결 한도
녹화·AI 분석 입력	지속적인 영상 입력 구성	저장·디코딩·분석 기능은 별도
웹 관제 서비스	카메라 입력 구간에 활용	브라우저용 전달 경로 필요

3. TCP와 UDP는 무엇을 기준으로 고를까?

RTSP를 쓴다는 결정만으로 미디어 전송 방식이 끝나는 것은 아닙니다. 대표적으로 RTP를 UDP로 보내는 방식과, RTSP의 TCP 연결에 미디어를 함께 싣는 방식이 있습니다. 지원 범위와 선택 옵션은 MediaMTX의 RTSP 전송 방식 안내처럼 사용하는 서버·클라이언트의 문서에서 확인합니다.

UDP 방식은 TCP의 순서 보장과 재전송 대기를 거치지 않지만, 기본 RTP/UDP 구성에서는 잃어버린 영상 패킷이 자동으로 모두 복구되지 않습니다. 손실이 발생하면 화면 깨짐이나 프레임 누락으로 나타날 수 있고, 별도 UDP 포트가 NAT나 방화벽에 막힐 수도 있습니다.

TCP 방식은 미디어를 같은 연결에 실을 수 있어 포트 경로를 단순화하는 데 도움이 됩니다. 다만 손실된 데이터를 재전송하는 동안 뒤의 데이터도 기다릴 수 있습니다. 따라서 “TCP이므로 지연이 없다”거나 “UDP이면 언제나 빠르고 안정적이다”라고 단정하기 어렵습니다.

가상 점검 사례로, 같은 카메라가 내부망에서는 재생되고 외부망에서는 검은 화면만 보인다고 해 보겠습니다. 인증 성공 여부를 먼저 확인하고, 그다음 미디어 전송 방식과 도달 가능한 포트를 비교합니다. RTSP 제어 연결의 성공이 실제 영상 패킷의 도착까지 보장하지는 않습니다.

4. 브라우저 배포와 보안에서 드러나는 한계

일반적인 웹브라우저의 기본 video 요소에 RTSP 주소를 넣는 것만으로 직접 재생되지는 않습니다. 웹 관제에서는 미디어 서버가 입력을 받아 WebRTC나 HLS 등 브라우저에서 처리할 경로로 제공하는 구성을 검토합니다. MediaMTX의 브라우저 재생 안내에서 이러한 출력 경로를 확인할 수 있습니다.

이때 프로토콜을 바꾼다고 영상 코덱까지 자동으로 바뀌는 것은 아닙니다. 예를 들어 카메라의 영상·음성 형식이 목표 브라우저에서 지원되지 않으면 별도 재인코딩이 필요할 수 있습니다. 카메라 입력 성공, 서버 출력 성공, 사용자 단말 재생 성공을 각각 확인해야 합니다.

또한 일반 rtsp:// 연결에 계정과 비밀번호를 설정했다고 영상 전송까지 암호화되는 것은 아닙니다. 외부 연결이 필요하면 VPN 같은 보호 경로나 장비가 지원하는 암호화 전송 구성을 검토합니다. RTSPS를 쓰는 경우에도 제어뿐 아니라 미디어가 어떤 방식으로 보호되는지 장비 문서에서 확인합니다. 공개 웹페이지에는 카메라 원본 주소와 비밀번호를 노출하지 않습니다.

5. 도입 전에 다섯 항목을 기록해 두세요

• 입력 정보: 장비 모델, 스트림 경로, 영상·음성 코덱과 해상도
• 연결 조건: 내부망·외부망, TCP·UDP 선택, 필요한 포트
• 시간 특성: 첫 화면까지의 시간, 현재 장면과 재생 화면의 시간 차
• 복구 동작: 네트워크가 끊긴 뒤 재접속과 영상 복구 여부
• 부하 조건: 카메라 연결 수, 서버 출력 수, 디코딩과 녹화 자원

예를 들어 녹화에는 고화질 메인 스트림을 쓰고 작은 관제 타일에는 저화질 서브 스트림을 쓰는 방안을 비교할 수 있습니다. 다만 서브 스트림의 해상도가 분석 대상 식별에 충분한지는 실제 화면으로 판단해야 합니다. 전송이 가볍다는 이유만으로 분석 입력까지 낮추지는 않는 편이 좋습니다.

RTSP는 기존 CCTV를 서버에 연결하는 입력 경로에 잘 맞습니다. 서비스 전체를 설계할 때는 카메라에서 수집한 이후의 녹화, 분석, 시청자 배포를 이어서 정해야 합니다. 전체 흐름은 CCTV에서 웹브라우저까지의 연결 구조, 웹 전달 방식은 WebRTC와 HLS 선택 가이드를 함께 참고하세요.

자료 확인일: 2026년 9월 9일. 공식 규격과 구현 문서를 참고한 활용 가이드입니다. 사례는 설명을 위해 구성했으며, 특정 장비의 성능 측정 결과가 아닙니다.