NVR 소프트웨어 벤치마크: Shinobi vs ZoneMinder 성능 비교

홈랩 CCTV를 오래 굴리다 보면 결국 한 번은 NVR 소프트웨어 벤치마크를 제대로 해야 할 때가 옵니다. 카메라 2대 정도일 땐 둘 다 무난해 보여도, 24시간 녹화가 붙고 실시간 보기 세션이 겹치고 보존 기간이 길어지면 병목이 갑자기 드러나거든요. 이때 가장 흔한 실수는 제품 이름만 보고 “이게 더 가볍다”고 결론 내리는 겁니다. 실제로는 NVR 자체보다 스트림을 어떻게 받는지, 다시 인코딩하는지, 이벤트를 어떤 경로에서 판정하는지, 파일을 어떤 단위로 저장하는지가 성능을 더 크게 좌우합니다.

이번 글은 Shinobi 성능과 ZoneMinder 비교를 숫자 몇 개로 포장하는 글은 아닙니다. 검증되지 않은 “채널당 CPU” 같은 수치는 일부러 뺐습니다. 대신 홈랩과 소형 자가 호스팅 환경에서 실제로 체크해야 하는 기준, 공정하게 비교하는 절차, 결과를 해석할 때 놓치기 쉬운 운영 포인트를 정리해보겠습니다. 결론부터 말하면 둘 중 하나가 절대적으로 우월하다기보다, 어떤 워크로드에서 어떤 비용을 치르는지를 읽는 쪽이 훨씬 중요하더라고요.

Shinobi와 ZoneMinder를 동일한 네트워크, 동일한 카메라 스트림 조건에서 비교하는 홈랩 CCTV 아키텍처 예시입니다.

1. 왜 Shinobi vs ZoneMinder를 따로 봐야 할까요?

둘 다 실사용 가능한 오픈소스 NVR이지만, 운영할 때 체감하는 무게중심은 꽤 다릅니다. 저는 이 차이를 스트림을 다루는 방식과 운영자가 개입해야 하는 지점으로 봅니다.

• Shinobi는 웹 UI에서 카메라별 설정을 빠르게 바꾸고 테스트를 반복하는 흐름에 강한 편입니다. 홈랩에서 “일단 붙이고 부하를 보면서 조정”하는 스타일이면 손에 잘 맞는 경우가 많습니다.
• ZoneMinder는 모니터 소스, 이벤트, 저장소, 로그를 더 명시적으로 관리하는 느낌이 강합니다. 처음엔 투박해 보여도 장기 운영에서 어디가 병목인지 추적하기는 편한 편입니다.

벤치마크 관점에서는 이 차이가 꽤 큽니다. 같은 RTSP 카메라를 붙여도 실제 부하는 다음 질문에서 갈립니다.

• 스트림을 그대로 저장(copy)하는가, 아니면 디코드 후 다시 가공하는가
• 실시간 보기와 녹화가 같은 스트림 경로를 공유하는가
• 모션 감지를 카메라 이벤트에 기대는가, 서버에서 계산하는가
• 이벤트가 쌓일 때 부담이 DB 쪽으로 가는가, 파일시스템 쪽으로 가는가

제가 이 둘을 비교할 때 제일 먼저 버리는 질문은 “누가 더 빠르냐”입니다. 대신 이렇게 묻습니다. 내 서버에서 제일 먼저 비명을 지를 자원이 CPU인지, 메모리인지, 디스크인지, 아니면 관리 시간인지. 이 기준으로 보면 둘의 인상이 꽤 달라집니다.

2. NVR 소프트웨어 벤치마크에서 봐야 할 핵심 지표

NVR 소프트웨어 벤치마크를 CPU 퍼센트 한 줄로 끝내면 거의 항상 해석이 틀어집니다. 제가 최소한 같이 보는 항목은 아래 8개입니다.

1. Idle 사용량: 아무도 안 보고 이벤트도 거의 없을 때 얼마나 조용한가
2. Live View 부하: 4분할, 8분할, 다중 브라우저 접속 시 부하가 얼마나 튀는가
3. Recording 경로: 상시 녹화가 재인코딩 없이 유지되는가, 중간 변환이 들어가는가
4. Motion Detection 비용: 감지 영역, FPS, 해상도 변화에 따라 CPU가 선형으로 느는지 급증하는지
5. Disk I/O 패턴: 평균 쓰기량보다 작은 파일 다량 생성, 메타데이터 갱신, 삭제 시 폭증이 있는지
6. Retention 정리 비용: 오래된 녹화 삭제가 평시 부하와 분리되는지, 같은 시간대에 몰리는지
7. Reconnect 안정성: 카메라 재부팅, 네트워크 지연 후 세션 복구가 깔끔한지
8. 관측 가능성: 로그, 프로세스, 저장량 변화를 보고 원인을 좁히기 쉬운지

여기서 실무적으로 중요한 건 평균값보다 피크와 패턴입니다. 예를 들어 CPU 평균이 낮아 보여도 5초마다 스파이크가 생기면 실시간 보기 체감은 바로 나빠집니다. 디스크도 마찬가지예요. 초당 평균 쓰기량이 낮아도 작은 파일을 계속 만들고 지우는 구조면 HDD에서 금방 티가 납니다.

또 하나, 홈랩에서는 카메라 스트림 품질이 벤치마크 자체를 오염시키는 경우가 생각보다 많습니다. 메인 스트림은 H.265, 서브 스트림은 H.264, 프레임 간격도 제각각이면 결과를 NVR 탓으로 돌리기 어렵습니다. 그래서 제품 비교 전에 먼저 입력 스트림이 예측 가능해야 합니다.

3. 비교 전에 조건을 맞춰야 공정합니다

Shinobi 성능이 더 좋다거나 ZoneMinder가 더 무겁다고 말하려면, 적어도 비교 조건은 통제해야 합니다. 저는 아래 표를 만족하지 못하면 벤치마크라고 부르지 않습니다.

여기에 저는 두 가지를 더 넣습니다.

• 브라우저 시나리오 통일: Live View 테스트에서 브라우저 탭 수, 레이아웃, 자동 재생 여부를 맞춥니다.
• 보존 정책 통일: 파일 수 제한인지, 일 수 기준인지, 용량 기준인지에 따라 정리 부하가 달라집니다.

실무에서 자주 깨지는 지점은 하드웨어 가속입니다. 한쪽은 실제로 VAAPI가 먹고 있고, 다른 쪽은 설정만 켜진 상태인데 CPU 디코드로 돌면 비교가 성립하지 않습니다. 그래서 저는 벤치마크 전에 항상 “가속을 켰는가”가 아니라 “가속 경로를 실제로 탔는가”를 확인합니다.

4. 실전 구현: 홈랩 CCTV 벤치마크 절차

설치 가이드는 환경마다 달라서, 여기서는 운영 중인 두 NVR 인스턴스를 같은 조건으로 측정하는 절차에 집중하겠습니다. bare metal, VM, LXC, Docker 중 무엇을 쓰든 핵심은 같습니다. 입력, 저장, 관측 방식을 통일하는 겁니다.

4-1. 카메라 스트림 상태 먼저 확인

NVR이 느린 것처럼 보여도 실제 원인은 입력 스트림 불안정인 경우가 많습니다. 먼저 각 RTSP 스트림의 해상도, 평균 FPS, 코덱, GOP 간격이 의도한 값과 맞는지 확인합니다.

ffprobe -hide_banner -rtsp_transport tcp rtsp://USER:PASS@CAMERA_IP:554/stream1
ffprobe -hide_banner -rtsp_transport tcp rtsp://USER:PASS@CAMERA_IP:554/stream2

가능하면 아래 항목을 따로 메모해 두세요.

• 메인/서브 스트림 해상도
• 실제 코덱(H.264/H.265)
• 명시 FPS와 실측 FPS 차이
• 키프레임 간격이 비정상적으로 긴지
• TCP/UDP 전송 방식 차이

제가 경험상 제일 빨리 걸러내는 문제는 카메라가 표시하는 FPS와 실제 전송 FPS가 다른 경우입니다. 특히 저가형 카메라나 무선 구간이 끼는 환경에서는 설정값과 실제가 다를 수 있습니다. 이 상태로 벤치마크하면 NVR 비교가 아니라 입력 품질 비교가 됩니다.

4-2. 서버 자원 사용량 수집

관측 도구는 화려할 필요가 없습니다. 오히려 단순해야 반복하기 쉽습니다. 저는 최소한 pidstat, iostat, vmstat를 같이 봅니다.

pidstat -rud -h 1
iostat -xm 1
vmstat 1

프로세스 단위로 좁혀 볼 때는 관련 프로세스를 먼저 식별합니다.

pgrep -af 'shinobi|node|zm|zmc|zma|ffmpeg'
pidstat -rud -p ALL 1

여기서 중요한 건 “한 번 보고 느낌으로 판단”하지 않는 겁니다. 저는 보통 아래처럼 구간을 나눠 최소 10분 이상 유지합니다.

1. Idle 10분: 브라우저 접속 없음, 이벤트 최소화
2. Live View 10분: 4카메라, 8카메라, 2개 브라우저 세션 순서로 증가
3. Continuous Recording 10분: 상시 녹화만 켜고 보기 세션 제거
4. Motion Detection 10분: 동일 감지 영역, 동일 FPS로 서버 감지 활성화

여기서 특히 보는 건 usr/sys/iowait 분해입니다. CPU 총합만 보면 놓치는 게 많습니다. 예를 들어 iowait가 높으면 NVR이 무거운 게 아니라 저장소 응답이 밀리는 걸 수 있고, sys 비중이 높으면 작은 파일 처리나 네트워크/커널 경로가 병목일 수 있습니다.

하드웨어 가속 검증도 이 단계에서 같이 합니다. 리눅스라면 최소한 아래 항목은 확인해 두는 편이 좋습니다.

ffmpeg -hwaccels
ls -l /dev/dri
vainfo
intel_gpu_top
journalctl --since '10 minutes ago' | grep -Ei 'vaapi|qsv|cuda|nvdec|nvenc'

장치가 보인다고 끝은 아닙니다. 실제 디코드/인코드 경로가 GPU를 타는지까지 봐야 합니다. 컨테이너라면 디바이스 패스스루, 그룹 권한, 런타임 제약도 같이 확인하는 게 안전합니다.

동일한 카메라 수, 동일한 스트림 조건, 동일한 저장소 정책으로 테스트하는 구성 흐름 예시입니다.

4-3. 로그와 스토리지 증가량 기록

CPU만 보면 진짜 중요한 문제를 놓칩니다. 저는 저장 용량 증가, 파일 수 증가, 로그 에러를 반드시 같이 봅니다.

# ZoneMinder는 배포판과 스토리지 설정에 따라 경로가 달라질 수 있습니다.
du -sh /var/cache/zoneminder 2>/dev/null || du -sh /var/lib/zoneminder
find /var/cache/zoneminder -type f 2>/dev/null | wc -l
journalctl -u zoneminder --since '10 minutes ago'

# Shinobi는 systemd 서비스명 또는 PM2 사용 여부를 먼저 확인하세요.
journalctl -u shinobi --since '10 minutes ago' 2>/dev/null || pm2 logs --lines 100

가능하면 용량뿐 아니라 파일 개수를 같이 기록해 보세요. 홈랩에서 HDD 기반 저장소가 느려지는 대표적인 이유는 총 용량 부족보다도 작은 파일이 너무 많아져 메타데이터 작업이 밀리는 것입니다. 용량 그래프는 멀쩡한데 삭제 작업이 겹칠 때만 끊기는 패턴이 이때 자주 나옵니다.

그리고 로그는 “에러가 있냐 없냐”보다 에러가 어떤 구간에 몰리는지가 중요합니다. 저는 아래 네 가지 메시지가 보이면 바로 원인 축소에 들어갑니다.

• 재연결 반복: 카메라 응답 지연, RTSP keepalive, 스위치/PoE 불안정 가능성
• 디코드 실패: 코덱 불일치, 손상 프레임, 가속 경로 실패 가능성
• DB 관련 지연: 이벤트 인덱싱, 정리 작업, 메타데이터 병목 가능성
• 권한 오류: 저장 경로, GPU 장치, 컨테이너 볼륨 마운트 문제 가능성

4-4. 반복 가능한 기록 시트 만들기

엑셀도 좋고 노션도 좋지만, 핵심은 나중에 같은 기준으로 다시 재현할 수 있느냐입니다. 저는 아래 같은 단순 시트를 씁니다.

Scenario,CPU usr/sys/iowait,Memory RSS,Disk Write MB/s,File Count Growth,Event Delay,Reconnect Stability,Notes
Idle, , , , , , ,
Live View 4 cams, , , , , , ,
Live View 8 cams, , , , , , ,
Continuous Recording, , , , , , ,
Motion Detection Enabled, , , , , , ,
Retention Cleanup Window, , , , , , ,

여기서 포인트는 메트릭보다 해석 단서를 남기는 것입니다. 예를 들어 Notes 칸에 아래처럼 적어두면 다음 테스트 품질이 확 올라갑니다.

• “서브 스트림 보기에서는 안정, 메인 스트림 다중 보기에서 브라우저가 먼저 버벅임”
• “Motion 켜는 순간 CPU보다 iowait가 먼저 튐”
• “카메라 6번만 주기적으로 reconnect 발생”
• “보존 정책 정리 시점에 삭제 지연과 DB 정리 동시 발생”

이런 메모가 있어야 나중에 제품 차이와 환경 문제를 분리하기 훨씬 쉽습니다.

5. Shinobi 성능과 ZoneMinder 비교 포인트

이제 구조적인 차이를 성능 관점으로 읽어보겠습니다. 특정 수치를 찍기보다, 어떤 조건에서 어떤 비용이 커지는지를 보는 게 맞습니다.

제 판단 기준을 조금 더 솔직하게 말하면 이렇습니다.

• Shinobi는 “구성을 자주 바꾸며 최적점을 찾는 사람”에게 잘 맞습니다. 카메라별 차이를 빨리 체감하기 좋고, 동적 서브스트림 같은 기능을 실험하기도 편한 편입니다.
• ZoneMinder는 “정책을 먼저 정하고, 그 정책이 장기적으로 버티는지 검증하는 사람”에게 더 잘 맞습니다. 다만 저해상도 보조 스트림 활용은 버전과 설정에 따라 성숙도가 달라서, 실제 테스트를 꼭 해보는 게 좋습니다.

다만 여기서 중요한 반전이 하나 있습니다. 실제 홈랩에서는 제품 차이보다도 아래 결정이 결과를 더 크게 바꿉니다.

• 실시간 보기를 메인 스트림으로 할지, 서브 스트림으로 분리할지
• 모션 감지를 카메라 이벤트에 맡길지, 서버 소프트웨어로 할지
• 상시 녹화 원본을 재인코딩 없이 저장할지
• 저장소를 SSD 캐시와 HDD 보관 계층으로 나눌지
• 보존 정책을 하루 단위 정리로 둘지, 용량 임계치 기준으로 둘지

즉, ZoneMinder 비교나 Shinobi 성능을 말할 때 제품명 자체보다 운영 설계가 더 큰 변수입니다. 저는 그래서 “무엇이 더 빠르냐”보다 “어떤 아키텍처를 강요하느냐”를 더 중요하게 봅니다.

6. 주의사항과 트러블슈팅

벤치마크를 망치는 실패 모드는 생각보다 정형화돼 있습니다. 중요한 건 증상보다 근본 원인을 읽는 겁니다.

6-1. 하드웨어 가속이 적용된 줄 알았는데 사실은 CPU가 다 먹는 경우

Hardware Acceleration은 설정값만으로 판단하면 한 번쯤은 꼭 헷갈립니다. 실제로는 아래 셋 중 하나가 많습니다.

• 가속 장치는 보이지만 애플리케이션 프로세스 권한이 없음
• 컨테이너에 /dev/dri 또는 GPU 장치가 전달되지 않음
• 입력 코덱이나 픽셀 포맷이 가속 경로와 맞지 않아 소프트웨어 폴백 발생

이때 증상은 비슷합니다. 평소엔 버틸 만한데 Live View나 Motion Detection에서 CPU가 갑자기 치솟고, 로그에는 가속 관련 문구만 애매하게 남습니다. 해결의 핵심은 “가속 활성화”가 아니라 실제 디코드/인코드 경로를 관측 가능한 상태로 만드는 것입니다. 장치 파일, 그룹 권한, 컨테이너 런타임 옵션, 로그를 같이 봐야 합니다.

6-2. 모션 감지 때문에 디스크보다 CPU가 먼저 터지는 경우

모션 감지는 생각보다 계산량이 큽니다. 특히 아래 조합이 위험합니다.

• 메인 스트림 해상도로 감지
• FPS를 높게 유지
• 감지 영역을 화면 전체로 설정
• 야간 노이즈가 많은 카메라

근본 원인은 단순합니다. 감지 알고리즘은 프레임 차이를 계속 계산하니, 해상도와 프레임 수가 올라가면 비용도 빠르게 증가합니다. 야간 IR 노이즈가 심하면 실제 사람보다 센서 노이즈를 더 열심히 잡기도 하고요. 이럴 때는 감지는 서브 스트림, 보관은 메인 스트림으로 역할을 나누는 편이 현실적입니다. 이거 분리하고 나면 체감이 꽤 달라지더라고요.

6-3. 저장 공간은 충분한데 I/O wait가 치솟는 경우

이건 용량 문제가 아니라 저장 패턴 문제인 경우가 많습니다. 흔한 원인은 아래 셋입니다.

• 작은 파일이 지나치게 많이 생성됨
• 보존 정책 정리와 녹화 쓰기가 같은 시간대에 겹침
• HDD에서 메타데이터 작업과 순차 쓰기가 동시에 경쟁함

그래서 저는 항상 이렇게 판단합니다. “몇 TB 남았는가”보다 “삭제와 생성이 어떤 리듬으로 일어나는가”. 특히 HDD 단일 볼륨에서는 삭제 작업이 길어질수록 체감이 급격히 나빠질 수 있습니다. SSD 캐시 구간을 두거나, 적어도 정리 작업이 피크 시간과 겹치지 않게 분리하는 편이 안전합니다.

6-4. 시간 동기화가 어긋나서 이벤트 시간이 이상한 경우

NTP가 어긋나면 벤치마크 기록도 오염됩니다. 이건 단순히 이벤트 시간이 헷갈리는 수준에서 끝나지 않습니다. 카메라, NVR 서버, 브라우저, VM 호스트 시간이 어긋나면 이벤트 순서 해석, 재연결 시점 분석, 로그 상관관계가 전부 꼬입니다. 특히 여러 VM과 여러 카메라를 쓰는 환경이라면 타임존과 NTP 소스를 같이 맞춰야 합니다.

제가 벤치마크 전에 체크하는 최소 항목은 아래와 같습니다.

Idle, Live View, Motion Detection 구간별로 CPU와 디스크 I/O가 어떻게 달라지는지 시각적으로 보여주는 예시입니다.

7. NVR 소프트웨어 벤치마크 결과는 시나리오로 읽어야 합니다

제가 NVR 소프트웨어 벤치마크 결과를 해석할 때 마지막으로 보는 건 단일 최대 채널 수가 아닙니다. 그 숫자는 눈길은 끌지만, 실제 운영 의사결정에는 의외로 도움이 적습니다. 대신 아래 질문이 훨씬 유용합니다.

1. 아무도 안 볼 때 조용하게 잘 도는가
2. 여러 명이 동시에 실시간 보기를 열면 어느 자원이 먼저 포화되는가
3. 모션 이벤트가 몰릴 때 지연이 CPU 때문인지, 저장소 때문인지 구분되는가
4. 서비스 재시작 후 스트림이 자동으로 안정적으로 복구되는가
5. 일주일 이상 돌렸을 때 로그, 이벤트 DB, 저장소 정리 흐름이 예측 가능한가

정리하면 판단은 이런 식으로 하시면 됩니다.

제가 현장에서 가장 많이 하는 조언은 이겁니다. 제품을 고르기 전에 먼저 운영 시나리오를 고르세요. 상시 녹화 중심인지, 실시간 보기 중심인지, 감지를 카메라에서 올릴지 서버에서 계산할지부터 정해야 합니다. 그다음에야 Shinobi가 더 편한지, ZoneMinder가 더 맞는지가 보입니다. 관련해서 홈랩 CCTV 저장소 설계나 GPU 패스스루 글도 같이 보면 판단이 훨씬 빨라집니다.

실무 체크리스트도 하나 남겨보겠습니다. 새 환경에서 둘을 비교할 때 저는 아래 항목을 모두 통과해야 “쓸 만한 구성”이라고 봅니다.

8. 정리: 어떤 분에게 어떤 선택이 맞을까요?

이번 ZoneMinder 비교를 마무리하면서 제 결론을 짧게 정리하면 이렇습니다.

• Shinobi는 빠르게 붙여보고 자주 만지면서 최적점을 찾는 홈랩 스타일에 잘 맞습니다.
• ZoneMinder는 구조를 이해하고 운영 규칙을 세운 뒤 길게 가져가는 스타일에 잘 맞습니다.
• 둘 중 무엇이 더 빠른지는 절대값보다 입력 스트림, 감지 방식, 저장소 구조, 가속 경로가 더 크게 좌우합니다.

저는 NVR을 평가할 때 제품 자체보다 워크로드 분리 능력을 더 중요하게 봅니다. 실시간 보기와 녹화를 분리할 수 있는지, 감지와 보관을 분리할 수 있는지, 문제가 났을 때 그 원인을 CPU인지 디스크인지 네트워크인지 빠르게 좁힐 수 있는지가 핵심입니다. 이 기준으로 보면 벤치마크는 숫자 놀이보다 운영 리스크를 줄이는 설계 검증에 더 가깝습니다.

혹시 바로 테스트에 들어가실 거라면 저는 아래 순서를 권합니다.

1. 동일 모델 카메라 2~4대로 메인/서브 스트림 특성부터 기록
2. 상시 녹화와 모션 감지를 분리해 각각 부하 측정
3. Live View 다중 접속과 보존 정책 정리 시점을 별도 테스트
4. SSD와 HDD에서 파일 수 증가, 삭제 부하, 재시작 복구까지 확인

이 과정을 거치면 다음에 카메라를 늘릴 때도 덜 흔들립니다. 결국 오픈소스 NVR 선택은 제품명보다 운영 기준이 먼저입니다. 그 기준만 잘 세워두면 Shinobi든 ZoneMinder든 훨씬 덜 억울하게 굴릴 수 있습니다.

Shinobi 성능과 ZoneMinder 비교 포인트를 한눈에 정리한 요약 인포그래픽 자리입니다.

자주 묻는 질문

Q1. 홈랩 초보자는 어떤 쪽이 더 쉬운가요?

설정 변경을 자주 하면서 체감을 빨리 얻고 싶다면 Shinobi 쪽이 더 편하게 느껴질 수 있습니다. 반대로 Linux 서비스 구조와 장기 운영 습관이 익숙하다면 ZoneMinder도 충분히 괜찮은 선택입니다. 중요한 건 초보 여부보다 운영 방식을 얼마나 자주 바꿀지입니다.

Q2. 벤치마크는 몇 대 카메라부터 의미가 있나요?

최소 2대 이상은 있어야 동시 보기, 저장 부하, 재연결 안정성 차이가 드러납니다. 다만 진짜 의미 있는 비교를 하려면 수량보다도 같은 모델, 같은 코덱, 같은 FPS로 맞추는 게 더 중요합니다.

Q3. CPU보다 디스크가 더 중요할 때도 있나요?

네, 꽤 자주 그렇습니다. 특히 상시 녹화와 이벤트 파일이 같이 쌓이고 오래된 파일 정리까지 겹치면 저장 장치 응답성이 전체 체감 성능을 좌우합니다. 용량 여유가 많아도 파일 수와 삭제 패턴 때문에 느려질 수 있습니다.