모든 가정용 NVR 서버가 처리할 수 있는 카메라 스트림 수를 신뢰할 만한 고정 숫자로 정할 수는 없습니다. 압축 스트림 8개를 녹화하는 서버가 고해상도 영상 4개를 디코딩하고 분석하는 서버보다 가벼운 작업을 수행할 수도 있습니다. 구매 시에는 녹화 대역폭, 비디오 디코딩, 객체 감지라는 세 가지 부하를 따로 산정한 다음, 저장 보존 기간과 동시에 활성화될 가능성이 있는 카메라 수를 기준으로 다시 확인해야 합니다.
모든 카메라를 녹화, 시청, 감지 부하로 나누기
카메라는 물리적으로 하나의 장치여도 여러 작업을 생성할 수 있습니다. NVR은 고화질 메인 스트림을 저장하고, 감지를 위해 저해상도 서브스트림을 디코딩하며, 실시간 시청을 위해 또 다른 스트림을 재전송할 수 있습니다. 이 세 가지를 하나의 “카메라 채널”로 취급하면 서버가 실제로 수행하는 작업을 파악하기 어렵습니다.
Axis는 감시 코덱 효율이 대역폭과 저장 요구량을 어떻게 바꾸는지 설명합니다. H.264, H.265 및 최신 코덱은 비슷한 시각적 품질을 서로 다른 비트레이트로 제공할 수 있으므로, 코덱과 비트레이트를 제외한 단순한 스트림 수만으로는 용량을 산정하기에 부족합니다.
ZimaSpace의 로컬 NVR 서버 구축 가이드는 카메라 스트림, 네트워크 경로, 애플리케이션 런타임, 녹화 스토리지, 원격 액세스가 시스템에서 서로 분리된 구성 요소라는 점을 보여줍니다.
카메라별로 한 행을 만들고 녹화 해상도, 녹화 비트레이트, 감지 해상도, 감지 FPS, 실시간 보기 요구량, 하드웨어 디코딩 지원 여부를 열로 구성한 작업표를 작성하세요. 이 작업표는 특정 프로세서가 보편적으로 처리할 수 있는 카메라 수를 주장하는 것보다 훨씬 유용합니다.
녹화 전용 스트림은 대개 스토리지와 네트워크 문제입니다
NVR이 디코딩이나 재인코딩 없이 이미 인코딩된 카메라 스트림을 그대로 기록한다면 CPU 부하는 비교적 낮게 유지될 수 있습니다. 주요 제한 요소는 총 네트워크 처리량, 지속적인 디스크 쓰기 성능, 파일 시스템 오버헤드, 재생이나 내보내기 작업이 유입되는 녹화 데이터와 경쟁하는지 여부입니다.
Reolink의 최신 해상도 가이드는 해상도와 압축 방식이 카메라 스토리지 요구량을 어떻게 바꾸는지 보여줍니다. 고해상도 스트림에도 고정된 단일 비트레이트가 있는 것은 아니며, 장면의 복잡도와 인코딩 설정도 여전히 영향을 줍니다.
카메라 수에 일반적인 숫자를 곱하지 말고 총 비트레이트를 측정하세요. 지속적으로 녹화되는 모든 스트림의 최대 예상 비트레이트를 더한 뒤, 재생, 내보내기, 썸네일, 데이터베이스 작업 및 일시적인 피크를 위한 여유를 남겨야 합니다. 이러한 작업이 동시에 수행될 때도 네트워크와 스토리지가 포화 상태에 가까워지지 않도록 해야 합니다.
따라서 서버가 주로 압축된 비디오를 수신해 기록하기만 한다면 비교적 낮은 사양의 프로세서로도 많은 스트림을 녹화할 수 있습니다. 하지만 NVR이 모든 피드를 디코딩하고, 프레임 크기를 조정하고, 미리보기를 생성하고, 클라이언트용 트랜스코딩을 수행하거나, 컴퓨터 비전을 지속적으로 실행해야 한다면 상황이 달라집니다.
하드웨어 디코딩은 AI 감지보다 먼저 카메라 한계를 바꿉니다
여러 고해상도 스트림을 소프트웨어 방식으로 처리하면 비디오 디코딩에 상당한 범용 CPU 자원이 소모될 수 있습니다. 내장 그래픽이나 다른 하드웨어 비디오 엔진을 사용하면 디코딩 작업의 상당 부분을 줄일 수 있으므로, CPU 코어 수가 비슷한 두 서버라도 지원할 수 있는 NVR 작업량은 크게 다를 수 있습니다.
Tom's Hardware의 내장 그래픽을 갖춘 Intel N100 플랫폼 리뷰는 저전력 홈 서버에 흔히 사용되는 하드웨어 등급을 보여줍니다. 4개의 CPU 코어와 iGPU, 빠른 로컬 스토리지를 갖춘 구성입니다. 여기서 중요한 것은 게임 성능이 아니라 미디어 엔진입니다.
객체 감지는 디코딩과 별개의 경로입니다. 가속기는 추론을 효율적으로 처리할 수 있지만, 서버는 프레임이 감지기에 전달되기 전에 여전히 프레임을 수신하고 디코딩해야 할 수 있습니다. Coral, GPU 또는 다른 AI 장치를 추가한다고 해서 모든 CPU 및 비디오 처리 병목이 사라진다고 가정해서는 안 됩니다.
구매 전 테스트에서는 먼저 감지를 끄고 녹화와 디코딩만 측정하세요. 그런 다음 목표 FPS로 감지를 활성화하고 CPU, GPU, 가속기 사용률, 프레임 드롭 및 감지 지연 시간을 확인하세요. 이렇게 하면 실제로 업그레이드가 필요한 하드웨어 한계를 분리할 수 있습니다.
컴퓨팅 성능보다 저장 보존 기간 때문에 더 큰 서버가 필요할 수 있습니다
가정용 NVR이 처리 성능에 여유가 있더라도 원하는 보존 기간을 충족할 저장 공간이 없다면 적절한 구매가 아닐 수 있습니다. 연속 비디오는 지속적인 쓰기 작업이며, 필요한 용량은 총 비트레이트와 녹화 시간에 따라 직접 증가합니다.
Backblaze의 감시 스토리지 분석은 카메라 수, 비트레이트 및 보존 기간이 스토리지 요구량을 어떻게 결정하는지 설명합니다. 드라이브 베이를 선택하거나 소형 녹화 디스크로 충분하다고 판단하기 전에 이러한 변수를 계산해야 합니다.
ZimaSpace의 카메라 녹화 격리 구매 가이드는 안정성 측면의 우려도 제기합니다. 스토리지가 가득 차거나 분석 작업이 급증했을 때 NVR 작업이 중요한 홈 오토메이션 서비스를 고갈시키지 않도록 해야 합니다.
2드라이브 구성이 보존 기간 한도에 너무 빨리 도달한다면 CPU 사용률이 낮더라도 더 많은 베이가 필요할 수 있습니다. 이는 스토리지 구성의 업그레이드가 필요하다는 의미이지, 카메라 처리 플랫폼 자체에 더 많은 컴퓨팅 성능이 필요하다는 증거는 아닙니다.
빈 화면이 아니라 동시 작업 상태를 테스트하세요
카메라 분석은 모든 화면에 동시에 움직임이나 객체가 나타나는 것이 아니기 때문에 순간적으로 부하가 급증할 수 있습니다. 조용한 밤에 진행한 테스트만으로는 가족이 귀가하고, 차량이 진입로를 지나가며, 반려동물이 여러 구역을 통과하고, 실시간 보기 화면이 동시에 열릴 때 발생하는 부하를 파악하기 어렵습니다.
StorageReview의 NVR 테스트는 여러 카메라의 동시 녹화가 충분한 지속 처리량을 갖춘 녹화 경로에서 안정적으로 처리될 수 있으며, 재생과 네트워크 액세스를 위한 여유도 남길 수 있음을 보여줍니다. 핵심은 유휴 상태가 아니라 모든 작업이 결합된 상태를 테스트하는 것입니다.
실시간 대시보드를 열고, 여러 구역에서 움직임을 발생시키고, 객체 감지를 실행하며, 모든 카메라가 계속 녹화하는 동안 최근 영상을 내보내거나 재생하는 최악의 상황을 만들어 보세요. 디코딩 지연 시간, 추론 지연 시간, 프레임 드롭, 디스크 큐 깊이 및 네트워크 사용률을 확인해야 합니다.
시스템이 안정적으로 유지된다면 카메라 한 대를 추가하는 것은 측정 가능한 용량 결정이 됩니다. 공유 리소스 하나가 이미 포화 상태에 가깝다면 카메라 수만 보고 NVR 전체를 교체하기보다 해당 리소스를 먼저 업그레이드하세요.
녹화 규모와 분석 부하에 따라 NVR을 Zima 하드웨어에 맞추기
소수의 카메라를 로컬에 녹화하고 분석 작업이 제한적인 중간 규모의 가정용 NVR이라면 ZimaBoard 2 1664가 더 적합한 ZimaBoard 2 등급입니다. 추가 메모리 덕분에 카메라 소프트웨어, 데이터베이스 및 지원 컨테이너를 위한 여유 공간이 더 많기 때문입니다. 로컬 감지를 계획하고 있다면 PCIe 슬롯을 가속기용으로 사용할 수도 있습니다.
실제 스트림을 테스트하지 않고 보드에 고정된 카메라 수를 배정하지 마세요. 해상도, 코덱, 비트레이트, 디코딩 경로 및 감지 FPS에 따라 부하가 크게 달라질 수 있으므로 보편적인 채널 등급을 정하기 어렵습니다. 앞서 제시한 작업표와 통합 부하 테스트를 최종 선정 기준으로 사용하세요.
더 긴 보존 기간, 더 많은 드라이브 베이, 더 무거운 동시 녹화 또는 가정 내 대용량 스토리지가 필요해 멀티베이 NAS를 선택할 별도의 이유가 생긴다면 ZimaCube 2로 업그레이드하세요. Creator Pack은 전용 GPU 컴퓨팅이 실제 분석 요구 사항일 때만 선택해야 하며, NVR 소프트웨어에 “AI”라는 단어가 표시된다는 이유만으로 선택해서는 안 됩니다.
가장 적합한 NVR은 현실적인 최대 카메라 부하 테스트를 통과하면서도 스토리지, 네트워크 및 컴퓨팅 성능에 여유를 남기는 가장 작은 시스템입니다. 카메라 수는 단지 표시일 뿐이며, 실제 작업량은 스트림 파이프라인이 결정합니다.
FAQ
4K 카메라 한 대를 1080p 카메라 네 대처럼 계산해야 하나요?
아니요. 픽셀 수만으로 서버 부하가 결정되지는 않습니다. 비트레이트, 코덱, 프레임 레이트, 서브스트림 구성, 하드웨어 디코딩 및 분석 해상도가 모두 영향을 줍니다. 해상도를 고정된 카메라 환산 수치로 바꾸기보다 각 카메라의 실제 녹화 스트림과 감지 스트림을 기준으로 계산하세요.
AI 가속기를 사용하면 녹화할 수 있는 카메라 수가 늘어나나요?
자동으로 늘어나는 것은 아닙니다. 가속기는 객체 감지 처리 용량을 높일 수 있지만, 녹화에는 여전히 네트워크와 스토리지 처리량이 필요하며 비디오 디코딩은 CPU나 내장 그래픽에 의존할 수 있습니다. 추론 단계가 병목일 때만 가속기가 전체 처리 한계를 높여 줍니다.
구매 가이드
더 읽어보기

CPU, RAM, IOPS 사양을 Plex 성능으로 해석하는 방법
Plex 작업량 측정값을 바탕으로 CPU, RAM, 스토리지 및 네트워크 최소 요구 사항을 산정하여 과도한 구매를 피하는 구매 가이드.

가중 기준을 사용해 Plex용 홈 서버 후보를 추리는 방법
구매 전에 필수 조건과 선호 사항을 구분하고 불확실성을 드러내는, 재현 가능한 Plex 구매 매트릭스.

Plex 서버는 어떤 지원 및 업그레이드 수명 주기를 제공해야 할까요?
Plex 서버 지원, 업데이트 이력, 호환성, 수리 용이성, 비용, 마이그레이션 준비도를 통과 또는 실패로 판정하는 구매 프레임워크.

