CCTV 저장장치를 고를 때 카메라 해상도만 보고 4TB나 8TB를 선택하면 원하는 보관 기간을 채우지 못할 수 있습니다. 녹화 용량을 직접 결정하는 값은 평균 비트레이트, 카메라 수, 하루 녹화 시간과 보관일입니다.
연속 녹화를 단순 계산할 때는 다음 공식을 사용할 수 있습니다. 용량(GB) = 비트레이트(Mbps) × 10.8 × 카메라 수 × 보관일입니다. 여기서 GB와 TB는 저장장치 제조사가 쓰는 십진 단위 기준입니다.
1. 왜 1Mbps가 하루 10.8GB일까?
비트레이트 1Mbps는 초당 1,000,000비트입니다. 바이트로 바꾸기 위해 8로 나누고, 하루 86,400초를 곱하면 10,800,000,000바이트가 됩니다. 십진 단위로 약 10.8GB입니다.
따라서 4Mbps 카메라 한 대를 24시간 연속 녹화하면 하루 약 43.2GB가 필요합니다. 8대를 14일 보관하는 단순 계산은 4 × 10.8 × 8 × 14 = 4,838.4GB, 약 4.84TB입니다.
이 값은 영상 데이터만 단순 환산한 결과입니다. 오디오, 컨테이너와 인덱스, 파일시스템, 장애 대비 여유 공간이 추가될 수 있습니다. RAID를 사용하면 미러링·패리티 방식에 따라 실제 사용 가능한 용량도 줄어듭니다.

2. 카메라 수와 보관일을 넣어 계산해 보기
| 조건 | 계산 | 영상 단순 용량 |
| 2Mbps · 4대 · 7일 | 2 × 10.8 × 4 × 7 | 604.8GB |
| 4Mbps · 8대 · 14일 | 4 × 10.8 × 8 × 14 | 4,838.4GB |
| 6Mbps · 16대 · 30일 | 6 × 10.8 × 16 × 30 | 31,104GB |
계산 순서는 간단합니다. 카메라 설정이나 NVR 통계에서 실제 평균 비트레이트를 확인하고, 같은 설정의 카메라 수와 보관일을 곱합니다. 설정이 다른 카메라는 그룹별로 계산한 뒤 합치는 편이 정확합니다.
예를 들어 출입구 4대는 4Mbps, 창고 4대는 2Mbps라면 8대를 모두 4Mbps로 보거나 평균을 임의로 정하지 마세요. 두 그룹을 각각 계산하면 14일 기준 2,419.2GB와 1,209.6GB, 합계 3,628.8GB가 됩니다.
3. 해상도만으로 용량을 계산하면 안 되는 이유
같은 1080p라도 움직임이 많은 도로, 정적인 복도, 야간 노이즈가 많은 주차장의 비트레이트는 달라질 수 있습니다. 프레임률, H.264·H.265 코덱, 압축 강도, GOP와 카메라의 장면 최적화 기능도 영향을 줍니다.
AXIS Site Designer 설명서는 카메라 모델, 장면과 조명, 움직임, 녹화 방식, 프레임률, 해상도, 코덱과 압축 설정이 대역폭·저장공간 추정에 영향을 준다고 설명합니다. 계산기는 출발점이며 설치 환경의 실제 사용량과 차이가 날 수 있습니다.
가장 좋은 입력값은 운영하려는 설정으로 대표 장면을 일정 기간 녹화해 얻은 평균과 최대 비트레이트입니다. 평일과 주말, 낮과 밤, 조명 전환과 비가 오는 날처럼 장면이 달라지는 시간도 포함하면 예상 오차를 줄일 수 있습니다.
4. VBR·CBR·MBR에서는 무엇을 넣어야 할까?
VBR은 장면 복잡도에 따라 비트레이트가 변합니다. 평균 화질을 유지하기 좋지만 저장량이 일정하지 않으므로 대표 기간의 평균값과 변동 범위를 확인해야 합니다.
CBR이나 최대 비트레이트 제한은 전송량 상한을 관리하는 데 도움이 될 수 있지만, 장면이 복잡해질 때 화질을 희생할 수 있습니다. Axis 비트레이트 제어 자료도 저장 용량과 목표 비트레이트의 관계, VBR·MBR·평균 비트레이트 방식을 구분합니다.
용량 계획에는 평균 비트레이트를 쓰고, 네트워크와 NVR의 쓰기 처리량에는 여러 카메라가 동시에 높아질 때의 최대값도 확인하세요. 평균만으로 디스크를 정하고 최대값만으로 전체 저장량을 계산하면 각각 다른 방향으로 오차가 커질 수 있습니다.
5. 움직임 감지 녹화는 몇 퍼센트로 잡아야 할까?
움직임 감지 녹화는 실제 녹화 시간이 줄어 저장공간을 절약할 수 있습니다. 하지만 ‘하루의 20%만 움직인다’는 추정값을 모든 카메라에 똑같이 적용하면 위험합니다. 나뭇잎, 비와 눈, 차량 불빛, 영상 노이즈가 녹화를 자주 시작할 수 있습니다.
사전 녹화와 사후 녹화 시간도 포함해야 합니다. 이벤트 전후 10초를 보관하도록 설정하면 짧은 움직임이 반복될 때 실제 녹화 비율이 예상보다 높아집니다. 사람·차량 분류 분석을 사용하더라도 누락과 오탐을 실제 현장에서 확인하세요.
연속 녹화가 필요한 중요 구역은 100% 기준으로 계산하고, 이벤트 녹화 구역은 최소 1~2주의 실제 통계로 녹화 비율을 추정하는 편이 안전합니다. 예상 절감률만으로 가장 작은 디스크를 선택하지 마세요.
6. 디스크를 고를 때 추가해야 할 여유
- 표시 단위 차이: 제조사 TB는 십진 단위이고 운영체제는 TiB에 가까운 값을 표시할 수 있습니다.
- RAID 용량: 미러링과 패리티에 사용하는 공간을 제외한 가용 용량을 봅니다.
- 시스템 데이터: 오디오, 인덱스, 데이터베이스와 파일시스템 사용량을 반영합니다.
- 운영 여유: 비트레이트 증가, 카메라 추가와 장애 복구를 위한 공간을 남깁니다.
- 쓰기 성능: 총 평균·최대 비트레이트와 NVR의 채널·쓰기 한도를 함께 확인합니다.
Axis의 저장장치 안내도 제조사 표기 TB와 운영체제의 TiB 차이, RAID에 따른 가용 용량 감소를 설명합니다. 예를 들어 계산 결과가 4.84TB라고 해서 5TB 디스크 하나가 실제 운영에서 충분하다고 단정할 수 없습니다.
7. 자주 묻는 질문
1TB에 4Mbps 카메라 한 대를 며칠 저장할 수 있나요?
영상만 십진 단위로 단순 계산하면 1,000 ÷ 43.2 = 약 23.1일입니다. 실제 보관 기간은 포맷·인덱스·오디오·여유 공간과 비트레이트 변동 때문에 짧아질 수 있습니다.
H.265로 바꾸면 계산식도 달라지나요?
공식은 같습니다. H.265 설정에서 측정한 평균 Mbps를 넣습니다. H.264 비트레이트에 임의의 절감률을 곱하는 것보다 실제 값을 사용하는 편이 정확합니다.
NVR에 표시된 남은 날짜가 계속 바뀌는 이유는 무엇인가요?
VBR 영상의 평균 비트레이트, 움직임 녹화 비율과 장면이 계속 달라지기 때문일 수 있습니다. 현재 추정치가 어떤 기간의 사용량을 기준으로 하는지 확인하세요.
코덱별 저장량 차이는 H.264와 H.265 비교 글, 녹화와 실시간 보기의 역할은 CCTV 실시간 보기와 녹화 구조에서 이어서 설명합니다.
자료 확인일: 2026년 9월 12일. 계산은 십진 단위의 이론값이며 특정 장비의 보관 기간을 보장하지 않습니다. 최종 설계는 실제 평균·최대 비트레이트와 NVR 제조사 사양으로 검증하세요.
'소프트웨어개발' 카테고리의 다른 글
| H.264와 H.265 차이: CCTV 녹화 용량·화질·브라우저 호환성 비교 (0) | 2026.09.12 |
|---|---|
| ONVIF와 RTSP 차이: CCTV 자동 검색·제어·영상 주소를 구분하는 법 (0) | 2026.09.12 |
| HLS와 MPEG-DASH 차이: 많은 시청자에게 영상을 배포할 때의 선택 기준 (0) | 2026.09.09 |