CCTV 화면이 지금 잘 나온다고 해서 어제 같은 시간의 영상도 볼 수 있는 것은 아닙니다. 실시간 보기는 현재 들어오는 영상을 전달하는 기능이고, 녹화는 그 영상을 저장하는 기능입니다. 다시보기에는 저장된 영상에서 원하는 시간을 찾아 재생하는 과정이 더 필요합니다.
앞서 살펴본 CCTV 웹브라우저 연결 구조에 저장소와 다시보기 경로를 더해 보겠습니다. 이 글에서는 세 기능의 차이, 비트레이트로 저장 용량을 계산하는 방법, 녹화가 실제로 남는지 확인할 항목을 설명합니다.
1. 실시간 보기·녹화·다시보기의 역할
| 기능 | 처리하는 대상 | 성공 여부를 확인하는 방법 |
| 실시간 보기 | 현재 들어오는 영상 | 화면이 계속 갱신되는지 확인 |
| 녹화 | 시간에 따라 쌓이는 파일 | 파일 생성과 크기 증가 확인 |
| 다시보기 | 선택한 시간의 저장 영상 | 시간 검색과 실제 재생 확인 |
예를 들어 중계 서버의 실시간 전달은 정상인데 녹화 디스크가 꽉 차면, 현재 화면은 보여도 새 녹화가 남지 않을 수 있습니다. 반대로 카메라 연결이 끊겨도 이미 저장된 파일과 재생 서비스가 정상이라면 과거 영상은 볼 수 있습니다. 따라서 세 기능을 같은 상태 표시 하나로 판단하지 않는 편이 좋습니다.

2. 녹화가 추가되면 어떤 설정이 필요할까?
MediaMTX의 녹화 기능은 스트림을 디스크에 저장하며, 설정에서 저장 경로, 파일 형식, 구간 길이, 삭제 시점을 정할 수 있습니다. 지원 코덱에 따라 fMP4 또는 MPEG-TS 형식을 사용합니다. 각 설정의 의미는 MediaMTX 녹화 공식 문서에서 확인할 수 있습니다.
설계할 때는 먼저 “어디에 저장할 것인가”를 정합니다. Docker로 실행한다면 프로그램이 기록하는 컨테이너 내부 경로와 실제 데이터가 남는 볼륨·호스트 경로를 연결해서 확인해야 합니다. 저장 공간을 연결하는 기본 개념은 Docker 데이터 영속성 글에서 이어서 볼 수 있습니다.
다음으로 카메라별 파일을 구별할 이름과 시간 기준을 정합니다. 카메라 A의 오후 2시 영상과 카메라 B의 오후 2시 영상을 혼동하지 않아야 합니다. 화면에 표시하는 시간대와 저장 파일의 시간대를 함께 기록해 두면, 검색한 시간과 영상 속 시계가 다른 문제를 추적하기 쉬워집니다.
3. 카메라 4대의 저장 용량 계산하기
다음은 평균 영상 비트레이트가 카메라 한 대당 4 Mbps이고, 4대를 하루 24시간 연속 녹화한다고 가정한 계산 예시입니다. 특정 장비에서 측정한 값이 아닙니다. 여기서는 1 GB를 10억 바이트, 1 TB를 1,000 GB로 계산합니다.
하루 용량(GB) = 평균 비트레이트(Mbps) × 86,400초 ÷ 8 ÷ 1,000
따라서 한 대는 하루 약 43.2 GB이고, 네 대는 172.8 GB입니다. 같은 조건으로 7일이면 약 1.21 TB, 30일이면 약 5.18 TB가 됩니다. 여기서 7일과 30일은 계산을 비교하기 위한 기간이며, 특정 시설의 보관 기간을 제안하는 수치가 아닙니다.
| 대당 평균 비트레이트 | 1대·1일 | 4대·7일 |
| 2 Mbps | 21.6 GB | 604.8 GB |
| 4 Mbps | 43.2 GB | 1,209.6 GB |
| 8 Mbps | 86.4 GB | 2,419.2 GB |
이 값은 영상 데이터만 단순 계산한 것입니다. 음성, 파일 구조, 별도 색인, 파일시스템과 운영 여유 공간을 포함한 실제 디스크 요구량은 달라집니다. 가변 비트레이트라면 설정 화면의 최대값과 장시간 평균값도 구분해야 합니다. 먼저 대표적인 하루의 녹화 증가량을 확인한 뒤 계산을 보정하는 것이 좋습니다.
움직임이 있을 때만 저장한다면 녹화 시간 비율을 곱해 대략적인 값을 구할 수 있습니다. 다만 예상보다 움직임이 많은 날이나 이벤트 전후를 함께 저장하는 조건을 고려해야 합니다. “평소에 20%만 녹화된다”는 가정 하나로 디스크를 꽉 맞춰 정하면 여유가 부족해질 수 있습니다.
4. 파일이 있어도 다시보기 화면은 따로 필요합니다
저장 폴더에 파일이 생성되는 것과 사용자가 달력에서 시간을 골라 재생하는 것은 다른 단계입니다. MediaMTX는 별도의 HTTP 재생 서버에서 녹화된 시간 구간 목록과 영상 제공 기능을 지원합니다. 다시보기 공식 문서에서 경로와 시작 시간 등을 사용하는 요청 구조를 확인할 수 있습니다.
이를 바탕으로 서비스 화면에서는 카메라 선택, 날짜·시간 선택, 녹화가 있는 구간 표시, 재생 실패 안내를 구성할 수 있습니다. 녹화가 없는 구간을 선택했을 때는 무한 로딩보다 “해당 시간의 녹화 없음”처럼 상태를 구분하는 편이 이용자에게 명확합니다. 파일 형식뿐 아니라 영상 코덱과 실제 사용할 브라우저에서 재생되는지도 확인해야 합니다.
5. 도입 후 확인할 다섯 가지
- 짧게 녹화한 뒤 실시간 화면을 닫고, 방금 저장한 시간을 다시 재생합니다.
- 카메라 두 대의 같은 시간을 열어 경로와 영상이 서로 맞는지 확인합니다.
- 녹화가 끊긴 구간을 찾았을 때 화면이 어떤 상태를 보여주는지 확인합니다.
- 별도 시험 환경에서 프로그램을 재시작한 뒤 이전 녹화가 유지되는지 확인합니다.
- 디스크 사용량과 가장 오래된 녹화 시간을 함께 기록해 보관 설정이 의도대로 작동하는지 확인합니다.
이 점검을 기록할 때 “녹화 정상”만 남기기보다 카메라 이름, 저장 시간 범위, 재생한 단말기, 남은 디스크 공간을 적어 보세요. 나중에 특정 시간의 영상이 없다는 문의가 들어왔을 때 입력 문제인지, 저장 문제인지, 검색 문제인지 구분할 근거가 됩니다.
자료 확인일: 2026년 9월 7일. 공식 문서를 참고한 구조 설명과 가상 계산 예시이며, 특정 현장의 구축 결과나 장비 성능 측정값이 아닙니다.
'소프트웨어개발' 카테고리의 다른 글
| CCTV 관제 화면에 로그인하면 영상도 보호될까? 접근 권한의 구조 (0) | 2026.09.07 |
|---|---|
| Docker 컨테이너를 삭제해도 데이터를 보관하려면? 볼륨과 바인드 마운트 (0) | 2026.09.06 |
| WebRTC와 HLS 차이: CCTV·라이브 서비스에 맞는 영상 전송 방식 고르기 (0) | 2026.09.06 |