CCTV 영상을 웹브라우저에서 보려면? 카메라부터 중계 서버까지 연결 구조

카메라 제조사 앱에서는 CCTV가 잘 보이는데, 같은 영상을 회사 홈페이지나 별도의 관제 화면에 넣으려면 무엇이 더 필요할까요? 출발점은 카메라가 내보내는 영상과 브라우저가 받아 재생하는 영상을 나누어 보는 것입니다. 이 글은 IP 카메라의 영상을 웹으로 전달하는 기본 구조와 도입 전에 확인할 항목을 정리합니다.

기존 RTSP CCTV 관제·AI 분석 프로그램 소개를 읽으며 중계 서버의 역할이 궁금했던 분도 먼저 참고할 수 있습니다.

1. 카메라 주소와 웹 재생 주소는 역할이 다릅니다

많은 IP 카메라는 RTSP로 영상을 제공합니다. 다만 실제 지원 여부와 접속 경로는 카메라 모델 및 설정에 따라 확인해야 합니다. MediaMTX는 이러한 RTSP 카메라나 서버에 연결해 영상을 받아올 수 있습니다. MediaMTX의 RTSP 카메라 안내에서 이 입력 구조를 확인할 수 있습니다.

RTSP 주소를 알고 있다는 사실만으로 일반적인 웹페이지의 영상 재생 준비가 끝나지는 않습니다. 웹 서비스에서는 브라우저가 처리할 수 있는 재생 경로를 마련해야 합니다. 예를 들어 MediaMTX는 받은 스트림을 WebRTC나 HLS로 웹브라우저에 제공할 수 있습니다. 브라우저 재생 공식 안내는 두 방식의 재생 페이지와 웹페이지 삽입 방법을 구분합니다.

이때 카메라 접속 주소는 중계 서버가 사용하는 입력 정보이고, 사용자가 여는 주소는 서비스의 재생 화면입니다. 두 주소를 구별하면 장애가 발생한 구간도 찾기 쉬워집니다.

직접 구성한 개념도. 카메라 입력, 영상 중계, 브라우저 재생의 역할을 나눠 표시했습니다. 실제 제품 화면은 아닙니다.

2. 연결 구조를 세 구간으로 읽어보기

구간	맡는 일과 확인할 질문
카메라 → 중계 서버	원본 영상을 받습니다. 서버에서 카메라에 도달할 수 있는지, 해당 계정에 영상 읽기 권한이 있는지 확인합니다.
중계 서버 → 재생 경로	시청 환경에 맞는 전달 방식을 제공합니다. 사용할 프로토콜과 영상·음성 코덱을 함께 확인합니다.
재생 경로 → 브라우저	사용자가 영상을 보고 제어합니다. 실제 사용할 PC·휴대전화와 네트워크에서 재생되는지 확인합니다.

웹 화면의 로그인과 카메라 목록은 서비스 프로그램이 담당할 수 있습니다. 반면 영상을 받아 전달하는 일은 미디어 서버에 맡길 수 있습니다. 따라서 관리 화면이 정상적으로 열리는지와 영상이 실제로 움직이는지는 각각 확인할 필요가 있습니다.

3. 중계와 코덱 변환을 구분해야 하는 이유

프로토콜은 영상을 주고받는 방식이고, 코덱은 영상이나 음성을 압축하고 복원하는 방식입니다. 입력을 RTSP에서 WebRTC로 중계했다고 해서 모든 브라우저가 원본 코덱을 처리할 수 있게 되는 것은 아닙니다. H.264·H.265라는 이름 외에도 프로파일, 프레임 구성, 운영체제와 브라우저의 지원 조건을 확인해야 합니다. MDN의 영상 코덱 안내가 이 차이를 살펴보는 데 도움이 됩니다.

원본 형식이 수신 환경과 맞지 않으면 카메라 출력 설정을 조정하거나 재인코딩 단계를 검토합니다. MediaMTX의 재인코딩 문서는 FFmpeg 또는 GStreamer를 함께 사용하는 구성을 설명합니다. 이 단계가 추가되면 단순 중계와는 별도로 처리 자원을 산정해야 합니다.

예를 들어 카메라 자체에서 필요한 코덱의 보조 스트림을 제공한다면, 그 입력을 사용할 수 있는지 먼저 확인할 수 있습니다. 반대로 원본 설정을 바꿀 수 없다면 변환 구간을 어디에 둘지 검토합니다. 어느 쪽이 적합한지는 장비 지원 범위와 요구 화질을 놓고 판단해야 합니다.

4. 매장 카메라 4대를 보는 상황이라면

다음은 구조를 이해하기 위한 가상 사례입니다. 매장에 카메라 4대가 있고, 매장 PC 한 대와 외부 관리자 휴대전화에서 영상을 보려는 상황을 가정하겠습니다.

1. 카메라 한 대로 시작합니다. 네 대를 한 번에 연결하기 전에 입력 한 개가 중계 서버까지 들어오는지 확인합니다.
2. 내부망의 브라우저에서 재생합니다. 카메라 입력과 웹 재생이 연결되는지 확인한 뒤 카메라 수를 늘립니다.
3. 외부 휴대전화에서 다시 확인합니다. 내부 Wi-Fi에서 된다는 사실만으로 이동통신망의 연결까지 확인한 것은 아닙니다.
4. 한 화면과 분할 화면을 비교합니다. 전체 목록에 필요한 화질과 확대 화면에 필요한 화질을 구분해 요구사항을 정합니다.

이 순서는 특정 제품의 설치 절차가 아니라 확인 대상을 좁히는 방법입니다. 실패한 단계와 장비·브라우저·네트워크 조건을 함께 기록하면 다음 점검의 범위가 명확해집니다.

5. 도입 전에 적어두면 좋은 정보

항목	기록할 내용
카메라	모델명, RTSP 지원 여부, 주·보조 스트림, 영상·음성 코덱
시청 방식	동시에 보는 사람 수, 분할 화면 수, PC·모바일 비중
반응 속도	화면을 보고 즉시 대응해야 하는지, 일정한 지연을 허용하는지
접속 위치	내부망 전용인지, 외부 접속이 필요한지, 이용자별 접근 범위
저장 요구	실시간 보기만 필요한지, 영상 녹화나 이벤트 기록도 필요한지

라이브 재생, 녹화, AI 분석은 각각 요구사항을 적는 편이 좋습니다. 영상을 브라우저에서 볼 수 있게 했다고 녹화 보관이나 분석 기능까지 자동으로 갖춰지는 것은 아닙니다. 필요한 기능을 나누어야 저장 공간과 운영 범위를 설명할 수 있습니다.

6. 화면이 나오지 않을 때 남길 기록

“영상이 안 나옵니다”라는 기록에 다음 네 가지를 덧붙여 보세요. 카메라 입력을 서버에서 확인했는지, 웹페이지 자체가 열리는지, 어떤 브라우저에서 시험했는지, 내부망과 외부망 중 어디에서 실패했는지입니다. 오류 문구도 함께 남기되, 카메라 비밀번호가 포함된 주소는 공유 자료에서 지웁니다.

연결 구조를 읽을 때 핵심 질문은 세 가지입니다. 어디서 영상을 받고, 어떤 형태로 전달하며, 누가 어떤 환경에서 볼 것인가? 이 질문에 답할 수 있으면 필요한 구성요소와 다음 확인 작업을 구체적으로 정할 수 있습니다.

자료 확인일: 2026년 9월 6일. 공식 문서를 바탕으로 작성한 개념 설명이며, 가상 사례는 특정 현장의 구축 결과나 성능 측정값을 뜻하지 않습니다.