13년차의 서버실

서버, 인프라, 홈랩 기술 블로그

[태그:] RTSP

  • [HomeLabs] Home Assistant IP 카메라 보안 체크리스트: 홈랩 연동 모범 사례

    [HomeLabs] Home Assistant IP 카메라 보안 체크리스트: 홈랩 연동 모범 사례

    목차

    Home Assistant IP 카메라 보안 체크리스트

    Home Assistant IP 카메라 조합은 생각보다 빨리 복잡해집니다. 화면만 뜨면 끝이라고 보기 쉬운데, 실제 운영에서 발목을 잡는 건 대개 영상 품질보다 권한, 네트워크 경계, 로그 품질이거든요. 저도 홈랩에서 몇 번 다시 깔아보니, ONVIF로 장치가 잡히고 스트림이 재생되는 순간보다 그다음 몇 주가 더 중요하더라고요.

    지금은 기준을 하나로 잡습니다. 카메라는 신뢰하는 장비가 아니라, 필요한 범위 안에서만 일하게 만드는 장비로 보는 겁니다. 이 관점으로 보면 설계가 훨씬 단순해집니다. 카메라는 영상을 보내고, Home Assistant는 상태와 자동화를 묶고, 외부 접근은 VPN이나 엄격한 리버스 프록시로만 받습니다. 이번 글은 그 기준으로 정리한 Home Assistant IP 카메라 보안 실전 체크리스트입니다.

    Home Assistant IP 카메라 분리 네트워크 아키텍처 이미지

    Home Assistant 서버, 카메라 전용 네트워크, 관리용 단말, VPN 경로를 한눈에 보여주는 개요 이미지입니다.

    1. 왜 Home Assistant IP 카메라 연동이 보안 이슈로 이어질까

    IP 카메라는 단순한 영상 소스가 아닙니다. 스트림 서버이자 웹 관리 장비이고, 경우에 따라 이벤트 발행자이기도 합니다. Home Assistant는 그 위에 자동화를 얹는 오케스트레이션 레이어에 가깝고요. 여기서 자주 놓치는 건, Home Assistant에 붙였다고 해서 카메라 자체의 공격면이 자동으로 줄어드는 건 아니라는 점입니다.

    제가 현장에서 제일 자주 본 실패는 세 가지였습니다.

    • 노출 실패: RTSP, 웹 관리 포트, ONVIF 포트가 의도치 않게 다른 VLAN이나 인터넷 쪽에서 보입니다.
    • 권한 실패: Home Assistant 연동 계정이 관리자 권한이라 PTZ, 사용자 관리, 설정 변경까지 다 열려 있습니다.
    • 가시성 실패: 프록시, 카메라, Home Assistant 시간이 어긋나거나 원본 접속 정보를 교차 확인할 로그가 부족해 사고 분석이 어려워집니다.

    이 셋이 겹치면 꽤 번거로워집니다. 예를 들어 현관 카메라가 외부에 노출돼 있고, 관리자 계정으로 ONVIF를 붙여놨고, 프록시 access log 없이 Home Assistant 로그만 본다고 해보겠습니다. 그러면 누가 어디서 접근했는지 추적이 흐려지고, 연동 편의 때문에 열어둔 기능이 오히려 리스크를 키웁니다. 제 경험상 홈랩 감시 시스템은 “잘 나오느냐”보다 잘 제한돼 있느냐를 먼저 봐야 나중이 편합니다.

    2. Home Assistant IP 카메라 연동의 핵심 개념: ONVIF, RTSP, 네트워크 분리

    처음엔 ONVIF와 RTSP를 한 묶음으로 보기 쉬운데, 운영 관점에서는 역할을 분리해서 봐야 판단이 빨라집니다. ONVIF는 장치 발견, 프로필 조회, 이벤트, PTZ 같은 제어 채널에 가깝고, RTSP는 영상 전달 채널입니다. 참고로 Home Assistant의 ONVIF 통합은 현재 기준으로 ONVIF Profile S 호환 장치를 대상으로 하며, 영상 처리를 위해 FFmpeg 통합이 필요합니다.

    구성 방식 언제 쓰는지 장점 주의점 제가 권하는 판단
    RTSP만 사용 라이브 뷰나 NVR 쪽 스트림만 필요할 때 공격면이 비교적 단순함 이벤트, PTZ, 장치 메타데이터 연동이 줄어듦 움직임 감지는 별도 센서나 NVR이 맡는 구조면 이쪽이 더 깔끔합니다.
    ONVIF 중심 사용 장치 검색과 이벤트 연동이 핵심일 때 초기 통합은 편함 권한 과다 부여가 흔하고, 영상 경로 검증은 별도로 필요함 화면보다 이벤트가 중요할 때만 제한적으로 권합니다.
    ONVIF + RTSP 병행 이벤트와 라이브 뷰를 둘 다 쓸 때 기능은 가장 풍부함 권한, 포트, 디버깅 포인트가 늘어남 대부분 여기로 가지만, 계정과 네트워크 분리를 같이 하지 않으면 금방 지저분해집니다.
    카메라 전용 VLAN/서브넷 카메라 수가 2대 이상이거나 장기 운영할 때 격리, 룰 관리, 문제 분리가 쉬움 초기 라우팅과 방화벽 정책 설계가 필요함 하나만 먼저 하라면 저는 이걸 고릅니다.

    네트워크 분리는 단순히 “분리했다”에서 끝나지 않습니다. 누가 누구에게 먼저 말을 걸 수 있는지를 줄이는 작업에 가깝습니다. 카메라는 Home Assistant에 필요한 포트만 열고, 관리용 PC는 관리 페이지에만 접근하고, 인터넷으로 직접 나가는 경로는 기본 차단하는 식이죠. 이 구조를 먼저 잡아두면 카메라가 늘어나도 판단 기준이 흔들리지 않습니다.

    3. 제가 쓰는 연동 전 체크리스트

    1. 펌웨어부터 확인: 최신 안정 버전으로 맞추고, 업데이트 직후 ONVIF 프로필과 RTSP 경로가 바뀌지 않았는지 같이 봅니다.
    2. 기본 계정 정리: 기본 admin 계정은 비활성화하거나 강한 비밀번호로 바꾸고, Home Assistant용 계정은 별도로 만듭니다.
    3. 권한 최소화: Home Assistant 계정에는 영상 조회와 필요한 이벤트 권한만 주고, 사용자 관리나 네트워크 설정 권한은 빼둡니다.
    4. 관리 평면 분리: 카메라 웹 UI는 관리 단말 또는 관리 VLAN에서만 열리게 하고, 일반 사용자 대역에서는 막습니다.
    5. 시간 동기화: 카메라, Home Assistant, 리버스 프록시, NVR이 있다면 그 장비까지 NTP 기준을 맞춥니다.
    6. 스트림 전략 결정: 대시보드에는 서브 스트림, 녹화나 분석은 메인 스트림처럼 역할을 나눕니다.
    7. 외부 접속 원칙 결정: 직접 포트포워딩은 피하고, VPN 또는 인증이 명확한 프록시 경로 중 하나만 표준으로 정합니다.
    8. 검증 경로 준비: nmap, ffprobe, 패킷 캡처, Home Assistant 로그 확인 순서를 미리 정해둡니다.

    여기서 특히 많이 놓치는 게 시간 동기화입니다. 연동은 되는데 이벤트 타임라인이 엇갈리고, 녹화 파일 시각과 자동화 시각이 다르면 원인 찾는 속도가 확 떨어집니다. “움직임 감지됐다는데 왜 같은 시각 로그가 없지?” 하고 헤매는 경우가 은근 많더라고요. 저는 카메라 세팅 끝내면 NTP부터 꼭 확인합니다.

    4. 실전 구현 1: 네트워크와 포트부터 줄입니다

    실전에서는 카메라가 노출한 서비스부터 확인합니다. 제 기준은 간단합니다. 예상한 포트만 열려 있어야 하고, 예상한 대상에게만 닿아야 합니다. 카메라가 Home Assistant에 스트림을 제공하는 건 괜찮지만, 외부 DNS나 제조사 클라우드 주소로 계속 통신하고 있으면 다시 봐야 합니다. P2P 기능이 숨어 있는 장비도 생각보다 많았습니다.

    제가 보통 먼저 돌리는 확인 명령은 아래 순서입니다.

    # 1) 카메라가 실제로 어떤 TCP 포트를 열고 있는지 확인
nmap -Pn -sT -sV -p- 192.168.30.10

# 2) RTSP 스트림이 정상인지 Home Assistant 바깥에서 먼저 검증
ffprobe -v error -rtsp_transport tcp \
  -show_entries stream=index,codec_name,codec_type,width,height \
  -show_entries format=format_name \
  -of default=noprint_wrappers=1 \
  "rtsp://ha_viewer:[email protected]:554/stream1"

# 3) 카메라가 예상 밖 목적지와 통신하는지 관찰
sudo tcpdump -ni any host 192.168.30.10

    이 세 개만 제대로 봐도 원인 분리가 꽤 빨라집니다. 코드 블록은 예시라서, 실제 환경에서는 IP와 계정명, RTSP 경로를 장비에 맞게 바꿔서 확인하시면 됩니다.

    • nmap에서 웹 관리 포트, ONVIF 포트, RTSP 외에 낯선 서비스가 보이면 먼저 정리합니다.
    • ffprobe가 여기서 실패하면 Home Assistant 문제가 아니라 스트림 URL, 계정 권한, 코덱, 네트워크 경로 문제일 확률이 높습니다.
    • tcpdump에서 카메라가 Home Assistant 말고 다른 내부 장비나 외부 공인 IP와 자주 대화하면, 의도한 경로인지부터 따져봐야 합니다.

    방화벽은 장비마다 문법이 다르니 원칙을 먼저 잡는 게 낫습니다. 저는 보통 이렇게 나눕니다.

    • 카메라 VLAN -> Home Assistant: RTSP와 필요한 이벤트 포트만 허용
    • 관리 VLAN -> 카메라: 웹 UI 등 관리 포트만 허용
    • 카메라 VLAN -> 인터넷: 기본 거부
    • 일반 사용자 VLAN -> 카메라: 기본 거부

    리눅스 기반 방화벽이라면 아래처럼 시작하는 편이 이해가 쉽습니다. 인터페이스명과 IP는 환경에 맞게 바꿔야 하지만, 논리는 그대로 가져가면 됩니다.

    # nftables 예시: 기본은 막고, 필요한 경로만 허용
sudo nft add table inet camfilter
sudo nft 'add chain inet camfilter forward { type filter hook forward priority 0; policy drop; }'
sudo nft add rule inet camfilter forward ct state established,related accept
sudo nft add rule inet camfilter forward iifname "vlan30_cam" ip daddr 192.168.10.20 tcp dport { 554 } accept
sudo nft add rule inet camfilter forward iifname "vlan10_mgmt" ip daddr 192.168.30.0/24 tcp dport { 80, 443 } accept

    제가 이 단계에서 중요하게 보는 건 “열어둘 포트 목록”보다 “닫아둘 기본 방향”입니다. 카메라는 업데이트할 때만 잠깐 인터넷이 필요할 수 있습니다. 그래서 상시 허용보다 일시 허용 후 다시 차단이 운영이 훨씬 편하더라고요.

    Home Assistant IP 카메라 방화벽 정책 흐름 이미지

    카메라 전용 대역에서 Home Assistant로만 제한적으로 접근하도록 설계한 예시입니다.

    5. 실전 구현 2: Home Assistant 쪽 설정도 같이 잠급니다

    카메라만 분리해도 절반은 정리되지만, Home Assistant가 느슨하면 사고 기록이 흐려집니다. 특히 리버스 프록시를 거치는 환경에서는 Trust X-Forwarded-For, Trusted proxies, 로그인 차단 정책을 같이 봐야 합니다. 다만 2026년 현재 Home Assistant의 HTTP 서버 설정은 보통 Settings > System > Network에서 관리하므로, 예전처럼 configuration.yaml의 http: 블록만 기준으로 보면 오히려 헷갈릴 수 있습니다.

    실전 점검 포인트는 이렇습니다.

    • Trusted proxies에는 실제 앞단 프록시 IP나 정확한 CIDR만 넣습니다. 대충 넓게 잡으면 나중에 해석이 꼬입니다.
    • Enable IP banning과 로그인 시도 제한은 켜두되, 먼저 프록시를 신뢰하는 방식이 맞는지 확인합니다.
    • CORS allowed origins는 필요한 도메인만 넣습니다. 편하다고 넓게 열어두면 괜히 문제만 늘어납니다.
    • SSL profile은 특별한 호환성 문제가 있을 때만 조정합니다. 기본값을 괜히 건드릴 필요는 거의 없었습니다.

    하나 더 짚고 갈 부분이 있습니다. 로그인 실패나 차단 로그는 환경에 따라 프록시 주소 위주로 보일 수 있어서, Home Assistant 로그만으로 원본 IP를 항상 정확히 복원할 수 있다고 기대하면 안 됩니다. 이럴 때는 프록시 access log와 같이 봐야 훨씬 정확합니다. 이거 한 번 이해해두면, 나중에 분석할 때 진짜 편합니다.

    카메라 통합 계정도 저는 분리합니다. 공식 ONVIF 문서도 Home Assistant 전용 사용자를 따로 만들고, 현재 기능 범위에서는 표준 사용자 권한이면 충분하다고 안내합니다. PTZ를 안 쓰면 PTZ 권한을 안 주고, 이벤트를 안 쓰면 ONVIF 자체를 줄이거나 끄는 편이 낫습니다. 연동 편의와 공격면은 거의 항상 같이 움직입니다.

    # automations.yaml
- id: camera_motion_notification
  alias: Front Door Motion Notification
  triggers:
    - trigger: state
      entity_id: binary_sensor.front_door_motion
      to: "on"
  conditions:
    - condition: state
      entity_id: input_boolean.alerts_enabled
      state: "on"
  actions:
    - action: notify.mobile_app_phone
      data:
        title: "Front Door Motion"
        message: "현관 카메라 이벤트가 감지됐습니다."
  mode: single

    이 자동화 예시는 현재 Home Assistant YAML 문법 기준에도 맞는 형태입니다. 자동화는 결국 이벤트를 만든 주체와, 알림을 보낸 주체를 분리해서 추적할 수 있게 짜두는 게 핵심입니다.

    외부 접속 방식은 이렇게 고릅니다

    방식 장점 주의점 추천 상황
    직접 포트포워딩 당장 붙이기는 쉬움 관리 포트와 인증 표면이 인터넷에 그대로 노출될 수 있음 사실상 비추천
    VPN 내부망 기준으로 통제하기 쉬움 초기 설정, 기기별 접속 경로 관리가 필요함 개인 홈랩, 소규모 운영, 보안 우선 환경
    리버스 프록시 + 접근 통제 서비스별 정책 분리, 인증 연동이 쉬움 프록시 신뢰 범위, 원본 IP 전달, 인증 체계 설계가 중요함 여러 내부 서비스를 함께 운영할 때

    제 추천은 분명합니다. 혼자 운영하는 홈랩이면 VPN이 먼저입니다. 반대로 Home Assistant 외에도 여러 웹 서비스를 묶어 외부에 내보내야 하고, 접근 제어를 한 곳에서 관리해야 한다면 리버스 프록시 + 엄격한 trusted proxy 설정이 더 맞습니다. 직접 포트포워딩은 임시 테스트에서도 습관이 되면 별로더라고요.

    Home Assistant IP 카메라 ONVIF 연동 설정 이미지

    Home Assistant에서 카메라 통합을 추가하고 이벤트 자동화를 연결하는 흐름을 설명하는 이미지입니다.

    6. 자주 겪는 문제와 해결법

    이 구간은 제가 실제로 가장 많이 손댄 부분입니다. “아예 안 됨”보다 “가끔 됨”이 더 어렵습니다. 그래서 증상보다 근본 원인으로 묶어보는 편이 훨씬 낫습니다.

    1) ONVIF는 잡히는데 영상이 안 나오는 경우

    이건 보통 제어 채널과 스트림 채널이 분리돼 있을 때 생깁니다. 장치 정보는 읽히는데, 실제 스트림 URL이나 코덱 지원이 표시 경로와 안 맞는 겁니다.

    • 근본 원인: ONVIF 프로필 조회는 성공했지만 RTSP 경로가 다르거나 인증 정보가 다릅니다.
    • 근본 원인: 카메라 기본 스트림이 H.265 위주인데, 표시 경로나 중간 구성요소가 기대대로 처리하지 못합니다.
    • 해결 순서: ffprobe로 스트림 자체 검증 -> VLC 등 별도 플레이어 검증 -> Home Assistant 통합 문제 확인 순으로 나눕니다.

    2) 로그인 실패 차단이 정상 사용자에게 걸리는 경우

    이건 거의 항상 프록시 신뢰 설정이나 앱 URL 설정 문제였습니다. Home Assistant가 실제 사용자 흐름을 충분히 구분하지 못하면, 여러 사용자의 실패 시도가 한 지점에 뭉쳐 보일 수 있습니다.

    # Home Assistant OS/SSH 애드온 환경에서 로그 보기
ha core logs

# 컨테이너 배포라면
docker logs -f homeassistant

# 프록시가 있다면 access log에서도 실제 전달 흐름 확인
sudo tail -f /var/log/nginx/access.log
    • 같은 프록시 주소만 반복되면 프록시 로그와 Home Assistant 설정을 같이 확인합니다.
    • 짧은 시간에 여러 계정 실패가 보이면 외부 스캔인지, 비밀번호 관리자 자동 재시도인지 먼저 분리합니다.
    • 특정 모바일 앱만 반복 실패하면 저장된 이전 세션이나 잘못된 내부 URL을 물고 있는 경우가 많습니다.

    3) 홈랩 감시 시스템이 느려지는 경우

    이때 Home Assistant를 범인으로 단정하면 해결이 늦습니다. 병목은 대개 스트림 디코딩, 저장소 I/O, 데이터베이스 기록, 네트워크 재전송 중 하나에서 납니다.

    • 라이브 뷰가 느리다: 메인 스트림 대신 서브 스트림을 대시보드에 붙입니다.
    • 자동화는 되는데 화면이 버벅인다: 영상 처리와 상태 자동화를 같은 계층에서 무리하게 같이 하고 있지 않은지 봅니다.
    • DB가 커진다: recorder 범위를 줄여 카메라 관련 부수 이벤트까지 전부 기록하지 않게 합니다.
    • 가끔만 끊긴다: 무선 구간, 케이블, 스위치 상태를 보기 전에 tcpdump나 스위치 통계로 재전송 징후를 확인합니다.

    저는 보통 이렇게 결정합니다. 대시보드용 영상은 보기 편한 서브 스트림, 분석이나 녹화는 별도 구성요소, Home Assistant는 상태와 자동화 중심. 이렇게 역할을 나누면 성능 이슈가 생겨도 어디를 손봐야 할지 금방 좁혀집니다.

    7. 검증은 이렇게 합니다: 연결 성공보다 중요한 확인 포인트

    연동이 끝난 직후보다, 하루 지나고 일주일 지나도 같은 상태가 유지되는지가 더 중요합니다. 저는 아래 항목을 통과해야 “붙였다”고 봅니다.

    1. 외부 노출 검증: 외부 네트워크에서 카메라 RTSP와 웹 관리 포트가 직접 보이지 않는지 확인합니다.
    2. 권한 검증: Home Assistant용 계정으로 카메라 설정 변경, 사용자 추가, 네트워크 변경이 안 되는지 확인합니다.
    3. 이벤트 검증: 실제 움직임을 만들어 엔티티 상태 변화, 알림, 로그 타임스탬프가 이어지는지 봅니다.
    4. 재부팅 복구 검증: 카메라 재부팅 후 스트림 재연결과 자동화 복구가 되는지 확인합니다.
    5. 로그 품질 검증: 프록시 로그, Home Assistant 로그, 카메라 로그에서 시간과 출발지 정보가 어떻게 남는지 교차 확인합니다.

    판단 기준도 애매하게 두지 않는 게 좋습니다. 저는 이렇게 봅니다. 엔티티 상태가 안 바뀌면 이벤트 수집 문제, 상태는 바뀌는데 알림이 안 오면 자동화 문제, 알림은 오는데 영상만 안 보이면 스트림 문제입니다. 이 순서로 자르면 디버깅 시간이 꽤 줄어듭니다.

    Home Assistant IP 카메라 대시보드 검증 이미지

    연동 후 검증해야 할 대시보드 요소와 이벤트 이력을 보여주는 결과 예시입니다.

    8. 운영하면서 지키면 좋은 습관

    • 카메라별 정책 분리: 실내 카메라와 실외 카메라를 같은 권한, 같은 노출 정책으로 묶지 않습니다.
    • 문서화: 카메라 모델, IP, 스트림 URL, Home Assistant 계정, 관리 계정 위치를 남겨둡니다.
    • 변경 이력 관리: 펌웨어 업데이트 뒤 RTSP 경로, ONVIF 동작, 이벤트 엔티티 이름이 바뀌었는지 확인합니다.
    • 정기 점검: 포트 스캔, 계정 점검, 방화벽 정책, 외부 노출 여부를 주기적으로 다시 봅니다.
    • 백업 분리: Home Assistant 설정 백업과 카메라 설정 백업을 같은 위치에만 두지 않습니다.

    운영 습관에서 제일 체감이 컸던 건 문서화였습니다. 카메라가 1대일 때는 기억으로 버티지만, 3대만 넘어가도 “이 스트림이 메인인가 서브인가”, “이 계정이 관리자였나 읽기 전용이었나” 금방 헷갈립니다. 그때부터는 문제 해결보다 기억 복구에 시간을 더 쓰게 되더라고요.

    같이 읽으면 좋은 글도 내부 링크로 묶어두세요. 예를 들어 Home Assistant 관련 가이드나 네트워크 분리, 리버스 프록시 설정 글을 함께 연결해두면 검색 유입 후 체류 시간이 확실히 좋아집니다.

    9. FAQ와 마지막 권고

    Q. Home Assistant에서 카메라만 보이면 끝 아닌가요?

    아닙니다. 보이는 건 기능 확인일 뿐이고, 보안 확인은 따로 해야 합니다. 관리 포트 노출, 계정 권한, 외부 접근 경로, 로그 품질까지 같이 봐야 실제 운영 기준을 통과합니다.

    Q. ONVIF를 끄고 RTSP만 쓰는 게 더 안전한가요?

    PTZ나 카메라 이벤트가 필요 없으면 공격면을 줄이는 데 도움이 됩니다. 반대로 이벤트 연동이 필요하면 ONVIF를 쓰되, 관리자 계정 대신 최소 권한 계정으로 붙이는 편이 훨씬 현실적입니다.

    Q. 가장 먼저 하나만 하라면 뭘 하시겠어요?

    카메라 네트워크 분리입니다. 그다음이 Home Assistant 전용 읽기 계정, 마지막이 외부 접근 경로 정리입니다. 이 순서가 체감 효과가 제일 컸습니다.

    제 권고는 명확합니다. 집에서 소규모로 운영하고, 실사용 안정성이 더 중요하다면 VPN + 카메라 전용 네트워크 + Home Assistant 전용 읽기 계정으로 가세요. 반대로 여러 내부 서비스를 함께 공개해야 하고 인증과 접근 제어를 중앙에서 관리해야 한다면 리버스 프록시 + 좁게 잡은 trusted proxy + 로그 검증 체계가 맞습니다. 직접 포트포워딩은 편한 시작처럼 보여도 운영 부채가 큽니다. 저는 이제 카메라가 잘 뜨는지보다, 몇 달 뒤에도 조용히 제한된 상태로 잘 도는지를 더 중요하게 봅니다.

    Home Assistant IP 카메라 보안 체크리스트 요약 이미지

    네트워크 분리, 계정 최소 권한, 외부 접속 방식 선택을 한 장으로 정리한 요약 이미지입니다.

  • [HomeLabs] NVR 소프트웨어 벤치마크: Shinobi vs ZoneMinder 비교

    [HomeLabs] NVR 소프트웨어 벤치마크: Shinobi vs ZoneMinder 비교

    목차

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

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

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

    NVR 소프트웨어 벤치마크용 홈랩 CCTV 아키텍처 다이어그램

    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가 더 무겁다고 말하려면, 적어도 비교 조건은 통제해야 합니다. 저는 아래 표를 만족하지 못하면 벤치마크라고 부르지 않습니다.

    항목 비교 원칙 이유
    카메라 수 동일 수량 채널 수가 늘면 프로세스 수, 소켓 수, I/O 큐 길이가 같이 변합니다
    해상도 동일 해상도 1080p와 4MP 혼용은 감지 비용과 저장량을 동시에 왜곡합니다
    프레임레이트 동일 FPS FPS 차이는 CPU, 네트워크, 저장 용량에 직접 반영됩니다
    코덱 가능하면 동일 코덱 H.264와 H.265는 디코딩 부담이 다르고 브라우저 호환성도 다릅니다
    녹화 정책 상시/모션 동일 이벤트 방식이 다르면 파일 생성 패턴과 메타데이터 갱신량이 달라집니다
    저장소 같은 SSD/HDD 조건 같은 소프트웨어도 저장장치가 바뀌면 체감 성능이 완전히 달라집니다
    하드웨어 가속 같은 정책으로 켜거나 끄기 VAAPI, QSV, CUDA 계열 적용 여부가 결과를 뒤집을 수 있습니다

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

    • 브라우저 시나리오 통일: 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를 타는지까지 봐야 합니다. 컨테이너라면 디바이스 패스스루, 그룹 권한, 런타임 제약도 같이 확인하는 게 안전합니다.

    Shinobi 성능과 ZoneMinder 비교를 위한 테스트 구성 이미지

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

    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에서 보기 좋은 부분
    초기 UI 접근성 웹 화면에서 스트림 흐름과 카메라별 설정 반복이 비교적 빠릅니다 전통적인 관리 흐름에 익숙하면 구성 요소 역할을 구분해 보기가 쉽습니다
    스트림 관리 체감 메인/서브 스트림 분리 실험과 카메라별 조정이 잦을 때 유리한 편입니다 소스, 이벤트, 저장 구조를 나눠 보고 원인을 좁히는 흐름에 잘 맞습니다
    운영 난이도 빨리 붙여보고 병목을 눈으로 확인하기 좋습니다 초기 이해 비용은 있지만 장기 운영 원인을 추적하기 좋습니다
    디버깅 접근 스트림 단위 관찰과 FFmpeg 경로 확인이 핵심입니다 프로세스, DB, 저장 구조를 같이 보는 습관이 중요합니다
    홈랩 적합성 반복 테스트와 빠른 설정 변경 중심의 홈랩에 잘 맞습니다 운영 정책을 명확히 세우고 길게 굴리는 스타일에 잘 맞습니다

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

    • 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 소스를 같이 맞춰야 합니다.

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

    체크 항목 왜 중요한가 실패 시 보이는 증상
    카메라/NVR/호스트 시간 일치 로그 상관관계를 맞추기 위해 이벤트 재생 시점이 맞지 않음
    메인/서브 스트림 분리 여부 보기와 감지 비용을 분리하기 위해 Live View와 Motion 결과가 뒤엉킴
    가속 경로 실사용 확인 CPU 폴백을 걸러내기 위해 설정은 켰는데 CPU만 높음
    보존 정책 실행 시간 삭제 피크를 분리하기 위해 특정 시간대에만 끊김 발생
    파일 수 증가율 메타데이터 병목을 보기 위해 용량은 남는데 반응성 저하
    NVR 소프트웨어 벤치마크 결과를 보여주는 리소스 모니터링 대시보드

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

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

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

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

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

    운영 시나리오 우선 체크할 제품 판단 기준
    빠르게 홈랩 CCTV를 붙여보고 싶다 Shinobi UI 흐름, 카메라별 설정 반복 속도, 메인/서브 스트림 조정 편의성
    전통적인 Linux 운영 흐름이 익숙하다 ZoneMinder 프로세스 구조 파악, 로그 해석, 장기 운영 관리성
    카메라 수가 늘어날 예정 둘 다 테스트 필요 디스크 I/O 패턴, 삭제 부하, 감지 비용의 증가 방식
    낮은 전력과 저소음 홈서버가 중요하다 둘 다 동일 조건 필수 비교 Idle 사용량, 하드웨어 가속 실적용 여부, 서브 스트림 활용성

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

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

    실무 체크리스트 통과 기준 실패 시 조치 방향
    RTSP 입력 안정성 재연결 없이 일정 시간 유지 카메라 펌웨어, 스위치, PoE, TCP/UDP 전송 방식 점검
    Live View 다중 접속 브라우저 수 증가 시 급격한 끊김 없음 서브 스트림 보기 분리, 브라우저 레이아웃 축소
    상시 녹화 CPU보다 I/O 패턴이 안정적 저장 경로 분리, 재인코딩 여부 재검토
    모션 감지 이벤트 지연이 누적되지 않음 감지 해상도, FPS, 영역 축소 또는 카메라 이벤트 활용
    보존 정책 정리 삭제 시점에 서비스 품질 급락 없음 정리 시간 분산, SSD 캐시, 파일 수 감소 전략
    재시작 복구 카메라 세션이 자동 복구 서비스 의존성, 네트워크 타이밍, 타임아웃 설정 점검

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

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

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

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

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

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

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

    홈랩 CCTV용 Shinobi 성능과 ZoneMinder 비교 요약 인포그래픽

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

    자주 묻는 질문

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

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

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

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

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

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

  • [홈랩] IP 카메라 시스템 비용 분석: 클라우드 vs 온프레미스 TCO 비교

    [홈랩] IP 카메라 시스템 비용 분석: 클라우드 vs 온프레미스 TCO 비교

    목차

    [홈랩] IP 카메라 시스템 비용 분석: 클라우드 NVR vs 온프레미스 TCO

    집이나 사무실에 카메라 몇 대만 달면 끝일 줄 알았는데, 막상 계산해보면 IP 카메라 시스템 비용은 장비값보다 운영 방식에서 더 크게 갈리더라고요. 저도 처음엔 CCTV 자가 설치만 잘하면 예산이 끝나는 줄 알았습니다. 그런데 실제로 홈랩에서 굴려보니, 카메라 본체보다 클라우드 NVR(Cloud NVR, 클라우드 기반 녹화 저장 장치) 구독료, 온프레미스 NVR(On-premise NVR, 현장 설치형 녹화 장치)의 스토리지 증설, 장애 대응 시간 같은 숨은 비용이 꽤 컸습니다. 그래서 이번 글에서는 제품 홍보식 비교가 아니라, 13년차 인프라 엔지니어 관점에서 총 소유 비용, 즉 TCO(Total Cost of Ownership, 총 소유 비용)를 어떻게 봐야 하는지 정리해보겠습니다.

    특히 보안 카메라 예산을 처음 짜는 분들, 매달 나가는 비용이 부담스러운 분들, NAS나 미니 PC로 자가 구축을 고민하는 분들께 도움이 될 겁니다. 여기서 중요한 포인트는 단순히 초기 구매가가 아니라, 3년 정도 운영했을 때 누가 더 덜 피곤하고 덜 비싼가입니다.

    IP 카메라 시스템 비용 비교를 위한 클라우드 NVR와 온프레미스 NVR 아키텍처 이미지

    클라우드 녹화와 로컬 녹화의 데이터 흐름, 비용 발생 지점을 한눈에 보여주는 개요 이미지입니다.

    1. 왜 IP 카메라 시스템 비용은 생각보다 복잡할까요?

    쉽게 말해 카메라는 끝이 아니라 시작입니다. 카메라가 영상을 찍으면 그다음부터는 저장, 검색, 알림, 백업, 네트워크, 전원까지 다 돈이거든요. 제가 직접 해보니 같은 4대 구성이라도 어떤 집은 월 구독형이 편하고, 어떤 집은 온프레미스가 훨씬 이득이었습니다.

    • 초기 비용(CAPEX, Capital Expenditure): 카메라, PoE 스위치, 저장 장치, 케이블, UPS
    • 운영 비용(OPEX, Operating Expenditure): 구독료, 전기, 디스크 교체, 인터넷 업로드 부담
    • 관리 비용: 장애 대응 시간, 펌웨어 업데이트, 저장 정책 조정
    • 리스크 비용: 인터넷 장애, 디스크 장애, 계정 잠금, 벤더 종속성

    혹시 이런 경험 있으신가요? 처음엔 2대만 달았다가 사각지대 때문에 2대를 더 붙이고, 그다음엔 녹화 보관일이 부족해서 저장 공간을 늘리게 되는 패턴이요. 보통 여기서 예산이 깨집니다. 그래서 IP 카메라 시스템 비용은 반드시 확장 가능성까지 보고 잡아야 합니다.

    2. 클라우드 NVR vs 온프레미스 NVR, 개념부터 정리해보겠습니다

    클라우드 NVR이란?

    클라우드 NVR은 카메라 영상이나 이벤트 영상을 제조사 또는 서비스 사업자의 클라우드에 저장하는 방식입니다. 사용자는 앱에서 바로 보고, 저장 기간도 요금제에 따라 관리하죠. 설치는 편합니다. 정말 편해요. 대신 월 비용이 누적됩니다.

    온프레미스 NVR이란?

    온프레미스 NVR은 집이나 사무실 안에 NVR 장비, NAS, 또는 미니 PC를 두고 직접 녹화를 저장하는 방식입니다. RTSP(Real Time Streaming Protocol, 실시간 스트리밍 프로토콜)나 ONVIF(Open Network Video Interface Forum, 카메라 상호운용 표준)를 지원하는 장비를 많이 씁니다. 초기 구성은 조금 번거롭지만, 장기 운영에서는 비용 구조를 내가 통제할 수 있다는 장점이 있습니다.

    항목 클라우드 NVR 온프레미스 NVR
    초기 설치 난이도 낮음 중간~높음
    초기 장비 비용 상대적으로 낮을 수 있음 저장 장치 포함 시 높아질 수 있음
    월 고정비 발생 가능성이 큼 보통 낮음
    인터넷 의존성 높음 낮음
    확장성 요금제 의존 디스크/서버 증설로 대응
    운영 자유도 제한적 높음

    결론부터 아주 짧게 말하면 이렇습니다. 카메라 수가 적고 관리 시간을 아끼고 싶으면 클라우드 NVR, 카메라 수가 늘어나고 장기 운영비를 줄이고 싶으면 온프레미스 NVR 쪽으로 기웁니다.

    3. TCO 계산할 때 꼭 넣어야 하는 항목

    여기서 많이들 놓치는 게 있습니다. 장비값만 넣고 끝내면 안 됩니다. 저도 처음 견적 짤 때 저장용 디스크 교체 주기를 빼먹어서 다시 계산했었거든요. 삽질 좀 했습니다 ㅎㅎ

    1. 카메라 수량: 2대인지 8대인지에 따라 경제성이 완전히 달라집니다.
    2. 보관 기간: 7일, 14일, 30일 중 무엇이 필요한지부터 정해야 합니다.
    3. 녹화 방식: 상시 녹화(continuous recording)인지, 이벤트 기반 녹화(event recording)인지 확인합니다.
    4. 스토리지 중복성: RAID(Redundant Array of Independent Disks, 디스크 이중화) 여부를 넣어야 합니다.
    5. 전력 비용: 24시간 켜두는 장비는 생각보다 누적 전력비가 있습니다.
    6. 운영 인건비: 자가 구축은 내 시간이 공짜가 아닙니다.
    7. 장애 대응 리스크: 인터넷이 끊겼을 때도 녹화가 유지되는지 봐야 합니다.

    제가 실무에서 자주 쓰는 방식은 3년 기준으로 계산하는 겁니다. 이유는 간단합니다. 저장장치 수명, 카메라 추가, 요금제 누적 비용이 그쯤 되면 차이가 확 드러나거든요.

    3년 TCO = 초기 장비비 + (월 구독료 x 36) + 전력비 + 유지보수비 + 예비 부품/디스크 비용 + 운영 시간 비용

    이 공식이 엄청 정교한 건 아니지만, 실제 의사결정에는 꽤 유용합니다. 특히 총 소유 비용을 비교할 때 감으로 판단하는 걸 막아주더라고요.

    4. 실전 예시: 홈랩 기준 온프레미스 NVR 예산 잡는 방법

    제가 홈랩에서 자주 보는 구성은 이렇습니다. PoE 스위치로 전원과 네트워크를 같이 보내고, 미니 PC나 NAS에 컨테이너 기반 NVR 소프트웨어를 올리는 방식이죠. 여기서는 특정 가격을 찍기보다, 어떤 부품이 비용을 만드는지에 집중해보겠습니다.

    • IP 카메라 4대
    • PoE 스위치 1대
    • 미니 PC 또는 NAS 1대
    • 감시용 HDD 또는 SSD 캐시 + HDD 조합
    • UPS(무정전 전원 장치) 1대
    • Cat6 케이블, 커넥터, 브라켓

    여기서 중요한 포인트! 카메라 가격만 보고 들어가면 안 됩니다. 실제로는 저장장치와 전원 안정화 비용이 뒤늦게 붙습니다. 특히 정전이 잦거나 네트워크 품질이 불안정한 환경이면 UPS를 빼면 안 되겠더라고요.

    예시 구성 파일

    아래는 Docker Compose(Docker Compose, 컨테이너 묶음 실행 도구)와 YAML 예시입니다. 특정 제품 강매가 아니라, 온프레미스 NVR 흐름을 이해하기 위한 샘플로 보시면 됩니다.

    services:
  nvr:
    image: ghcr.io/blakeblackshear/frigate:stable
    container_name: frigate
    privileged: true
    restart: unless-stopped
    shm_size: "256mb"
    ports:
      - "5000:5000"
      - "8554:8554"
    volumes:
      - /etc/localtime:/etc/localtime:ro
      - ./config:/config
      - ./media:/media/frigate
    environment:
      FRIGATE_RTSP_PASSWORD: "change-me"
    mqtt:
  enabled: false

cameras:
  front_door:
    ffmpeg:
      inputs:
        - path: rtsp://user:{FRIGATE_RTSP_PASSWORD}@192.168.10.21:554/stream1
          roles:
            - record
    record:
      enabled: true
      retain:
        days: 7
        mode: motion

    이런 식으로 구성하면 이벤트 위주 녹화로 저장 공간을 아낄 수 있습니다. 상시 녹화보다 검색은 조금 덜 촘촘할 수 있지만, 홈 환경에서는 꽤 현실적인 타협점입니다.

    미니 PC, PoE 스위치, 카메라, 스토리지 연결 구조를 보여주는 구성 이미지입니다.

    5. 실전 구현: 네트워크와 저장 정책은 이렇게 잡으면 덜 후회합니다

    처음엔 저도 카메라만 붙이면 되는 줄 알았는데, 실제로 써보니까 네트워크 분리와 저장 정책이 운영 난이도를 거의 결정하더라고요.

    1. 카메라 전용 VLAN을 분리합니다. VLAN(Virtual LAN, 가상 랜)으로 관리망과 분리하면 보안상 훨씬 낫습니다.
    2. 고정 IP를 할당합니다. DHCP 예약도 괜찮지만 장비가 늘면 표로 정리하는 게 편합니다.
    3. 녹화 정책을 먼저 정합니다. 현관은 이벤트 기반, 외곽은 상시 녹화처럼 나누면 저장 효율이 좋아집니다.
    4. 보관 기간을 현실적으로 잡습니다. 무조건 길게가 답은 아니더라고요.
    5. 원격 접근은 VPN(Virtual Private Network, 가상 사설망) 우선으로 잡습니다.
    # RTSP 스트림 확인 예시
ffprobe rtsp://user:[email protected]:554/stream1

# 녹화 저장 경로 용량 확인 예시
df -h /media/frigate

# 컨테이너 로그 확인 예시
docker logs -f frigate

    클라우드 NVR 쪽은 구현이 더 단순합니다. 대신 업로드 대역폭이 변수입니다. 여러 대가 동시에 이벤트를 밀기 시작하면 인터넷 환경에 따라 체감이 꽤 달라집니다. 특히 업로드가 좁은 회선에서는 라이브 뷰 지연이 생각보다 거슬릴 수 있어요.

    6. ⚠️ 트러블슈팅: 제가 실제로 부딪힌 문제들

    이 섹션은 꼭 넣고 싶었습니다. 이론대로만 하면 세상 모든 시스템이 잘 돌아가야 하는데, 현실은 그렇지 않더라고요.

    문제 1. 저장 공간이 예상보다 빨리 찼습니다

    원인은 보통 해상도, 프레임레이트, 이벤트 민감도 설정입니다. 처음엔 “좋은 화질이 최고지” 하고 높게 잡았다가 며칠 만에 디스크가 훅 줄어드는 걸 보고 정신이 번쩍 들었습니다.

    • 이벤트 기반 녹화로 전환
    • 필요 없는 서브스트림 저장 제외
    • 민감도 구역(zone) 재조정

    문제 2. 밤에 벌레랑 빗방울 때문에 이벤트가 폭증했습니다

    이거 진짜 자주 겪습니다. IR(적외선) 반사와 외부 조명 때문에 오탐(false positive)이 많아지거든요. 해결은 카메라 각도 조정, 조명 위치 변경, 탐지 영역 제한이었습니다. 소프트웨어만 만지다 보면 끝이 안 납니다. 물리 배치가 더 중요할 때가 많아요.

    문제 3. 원격 접속을 편하게 하려다 보안이 약해질 뻔했습니다

    포트 포워딩으로 바로 열어두면 편하긴 한데, 장기적으로는 권장하지 않습니다. 가능하면 VPN이나 리버스 프록시(reverse proxy, 역방향 프록시) + 인증을 쓰는 게 낫습니다. 보안 카메라 예산을 줄이려다 보안 자체를 약하게 만들면 안 되니까요.

    문제 4. 디스크 장애를 너무 늦게 알았습니다

    SMART 모니터링이나 알림 설정이 없으면 진짜 늦게 알게 됩니다. 그래서 저는 디스크 상태 알림과 저장 용량 임계치 알림은 무조건 켜두는 편입니다. 드디어 됐다 싶었는데 녹화가 비어 있으면 그 허탈함이 꽤 큽니다.

    IP 카메라 시스템 비용 운영 중 발생하는 트러블슈팅 대시보드 이미지

    실제 운영에서 자주 만나는 경고 상황과 점검 포인트를 시각화한 이미지입니다.

    7. 검증: 어떤 경우에 누가 더 유리했나

    제가 여러 번 계산해보고 운영해본 결론은 꽤 단순합니다. 카메라 수가 적고, 관리 시간을 비용으로 크게 보는 환경에서는 클라우드 NVR이 편합니다. 반대로 카메라가 늘어나고, 장기 보관과 로컬 통제가 중요하면 온프레미스 NVR이 유리해집니다. 특히 IP 카메라 시스템 비용을 3년 기준으로 보면 이 차이가 더 또렷해집니다.

    환경 추천 방식 이유
    원룸/소형 매장, 카메라 1~2대 클라우드 NVR 설치와 운영이 단순하고 초기 진입 장벽이 낮음
    단독주택/사무실, 카메라 4대 이상 온프레미스 NVR 구독 누적 비용보다 로컬 저장이 유리해질 가능성 큼
    인터넷 불안정 환경 온프레미스 NVR 망 장애 시에도 로컬 녹화 지속 가능
    관리 인력이 거의 없는 환경 클라우드 NVR 장애 대응과 앱 접근성이 상대적으로 쉬움

    검증할 때는 아래 항목을 체크해보시면 됩니다.

    1. 7일, 14일, 30일 보관 기준으로 저장 여유가 있는가
    2. 인터넷이 끊겨도 최소 녹화 요구사항을 만족하는가
    3. 카메라 2대를 추가해도 예산 구조가 유지되는가
    4. 앱 알림, 검색, 내보내기(export) 과정이 실제로 편한가

    이전 글에서 다룬 홈 네트워크 분리 이야기를 이미 보신 분이라면, 이번 구성에서 VLAN과 VPN이 왜 중요한지 더 빠르게 이해되실 겁니다. 다음 글에서는 CCTV 자가 설치 시 카메라 위치 선정과 PoE 배선 팁도 정리해보겠습니다.

    3년 기준 IP 카메라 시스템 비용과 총 소유 비용 비교 인포그래픽

    3년 운영 기준으로 무엇을 비교해야 하는지 보여주는 결과 요약 이미지입니다.

    8. 정리 + 자주 묻는 질문

    IP 카메라 시스템 비용은 카메라 가격표만 봐서는 절대 감이 안 옵니다. 저장 방식, 운영 기간, 인터넷 품질, 보관 정책, 내 시간까지 넣어야 진짜 숫자가 보입니다. 저도 처음엔 장비 스펙만 보고 골랐었는데, 결국 오래 남는 건 운영 편의성과 유지비였습니다. 사실 이게 인프라 일도 똑같거든요. 초기 구축보다 운영이 더 깁니다.

    FAQ 1. CCTV 자가 설치가 무조건 더 저렴한가요?

    무조건은 아닙니다. 소규모 구성에서는 클라우드 구독형이 시간 비용까지 포함하면 더 합리적일 수 있습니다.

    FAQ 2. 온프레미스 NVR은 NAS가 꼭 필요한가요?

    꼭 그렇진 않습니다. 미니 PC + 외장 또는 내부 저장장치 조합으로도 가능합니다. 다만 백업과 장애 대응은 더 신경 써야 합니다.

    FAQ 3. 보안 카메라 예산을 줄이려면 어디서 아껴야 하나요?

    카메라 대수와 보관 정책부터 조정하는 게 효과적입니다. 반대로 전원 안정화나 저장장치 신뢰성을 과하게 줄이면 나중에 더 비싸집니다.

    FAQ 4. 초보자는 어떤 방향이 무난한가요?

    처음이라면 2대 정도는 클라우드 NVR로 경험을 쌓고, 확장 시 온프레미스로 넘어가는 방식도 괜찮습니다. 저도 이런 식으로 단계적으로 접근하는 걸 추천합니다.

    마지막으로 한 줄 정리해보겠습니다. 편의성 우선이면 클라우드 NVR, 장기 TCO 우선이면 온프레미스 NVR입니다. 숫자보다 운영 습관과 장애 대응 성향이 더 중요할 때도 많으니, 꼭 본인 환경에 맞춰 계산해보세요.

    초기 비용, 운영 비용, 관리 난이도를 한 번에 정리한 마무리 요약 이미지입니다.

  • [HomeLabs] Frigate AI NVR로 홈랩 CCTV 오탐 줄인 객체 감지 최적화 사례

    [HomeLabs] Frigate AI NVR로 홈랩 CCTV 오탐 줄인 객체 감지 최적화 사례

    목차

    Frigate AI NVR로 홈랩 CCTV 오탐 줄인 객체 감지 최적화 사례

    홈랩 CCTV를 오래 굴리다 보면 제일 먼저 지치는 게 저장공간이 아니라 오탐(false positive, 잘못된 감지)입니다. 바람에 흔들리는 나뭇잎, 새벽 벌레, 비 오는 날 헤드라이트 반사까지 전부 이벤트로 찍히면, 정작 봐야 할 장면은 묻혀버리거든요. 저도 처음엔 알림이 많이 오면 좋은 줄 알았습니다. 근데 실제로 써보니까 너무 많이 울리는 시스템은 결국 안 보게 되더라고요. 그래서 이번 글에서는 Frigate AI NVR를 기준으로, 홈랩 CCTV 환경에서 객체 감지 정확도를 높이고 오탐 감소에 집중했던 과정을 사례 연구 형태로 정리해보겠습니다.

    특히 이 글은 “무조건 최신 장비를 사면 해결된다”가 아니라, 이미 가지고 있는 보안 카메라 최적화와 설정 조정만으로 어디까지 개선되는지에 초점을 맞췄습니다. 혹시 지금 홈랩 CCTV 알림 때문에 피곤하신 분이라면, 꽤 공감되실 겁니다.

    Frigate AI NVR가 카메라 스트림을 받아 객체를 감지하고 이벤트를 기록하는 전체 흐름을 보여주는 개요 이미지입니다.

    1. Frigate AI NVR가 왜 홈랩 CCTV에 잘 맞는가

    쉽게 말해 Frigate AI NVR는 카메라 영상을 받아서 사람이 직접 보기 전에, 먼저 객체를 구분해 주는 NVR(Network Video Recorder, 네트워크 비디오 레코더)입니다. 단순히 녹화만 하는 장비가 아니라, 사람이 지나갔는지 차량이 들어왔는지 같은 이벤트를 기준으로 영상을 정리해 주는 쪽에 가깝습니다.

    여기서 핵심은 모션 감지(motion detection)와 객체 감지(object detection)를 분리해서 생각하는 겁니다. 모션 감지는 픽셀 변화만 보고 움직임을 잡아내기 때문에 비, 그림자, 벌레에도 민감합니다. 반면 객체 감지는 “이게 사람인지, 차량인지”를 구분하려고 시도합니다. 물론 완벽하진 않지만, 방향이 다르죠.

    구분 모션 감지 객체 감지
    기준 화면 변화 사람, 차량 등 대상 식별
    장점 가볍고 빠름 의미 있는 이벤트 분류 가능
    단점 오탐이 많음 설정이 잘못되면 놓침 발생
    홈랩 활용 보조 지표 주 이벤트 기준

    제가 직접 해보니, 오탐 감소의 출발점은 모델이나 하드웨어보다도 카메라 구도, 감지 영역, 프레임 수, 객체 필터였습니다. 이 네 가지를 안 잡고 나머지만 만지면, 정말 삽질이 길어집니다.

    2. 오탐이 생기는 진짜 이유

    처음엔 저도 “감지 엔진이 별로인가?” 싶었는데, 실제 원인은 꽤 현실적이었습니다.

    • 야간 적외선(IR, 적외선 조명)에서 벌레가 렌즈 가까이 지나감
    • 차량 헤드라이트가 벽면에 반사되면서 큰 움직임처럼 보임
    • 현관 앞 화분이나 나뭇가지가 바람에 흔들림
    • 너무 넓은 화각으로 도로와 인도까지 같이 잡음
    • RTSP 스트림 해상도와 감지 해상도가 맞지 않아 형태가 흐려짐

    여기서 중요한 포인트가 있습니다. 오탐 감소는 AI 모델만의 문제가 아니라 입력 품질의 문제이기도 하다는 점입니다. 카메라가 쓸데없는 영역을 너무 많이 보고 있으면, Frigate AI NVR가 아무리 열심히 판단해도 헷갈릴 수밖에 없거든요.

    3. 제가 적용한 홈랩 CCTV 객체 감지 최적화 순서

    실제로는 이것저것 한 번에 건드리면 뭐가 효과 있었는지 모르게 됩니다. 그래서 저는 아래 순서로 정리했습니다.

    1. 카메라별 감시 목적 정의: 현관, 주차, 창고처럼 역할을 나눴습니다.
    2. 프레임 구도 조정: 필요 없는 도로, 하늘, 나무 영역을 최대한 빼냈습니다.
    3. 감지 해상도와 FPS(Frame Per Second, 초당 프레임 수) 조정
    4. 객체 종류 제한: 사람과 차량만 먼저 추적했습니다.
    5. 영역(Zone, 존) 기반 필터 적용
    6. 며칠 로그를 보고 다시 미세 조정

    이 순서가 중요한 이유는, 나중 단계로 갈수록 앞선 입력 품질에 의존하기 때문입니다. 예를 들어 존 설정을 정교하게 해도 카메라가 가로등 반사광을 계속 크게 잡으면 의미가 반감됩니다.

    4. 실전 구현: Docker와 Frigate 기본 구성

    제 홈랩에서는 Docker Compose로 올려서 운영하는 편이 관리가 편했습니다. 아래 예시는 구조를 이해하기 위한 기본 예시입니다. RTSP URL이나 저장 경로는 환경에 맞게 바꾸셔야 합니다.

    services:
  frigate:
    container_name: frigate
    image: ghcr.io/blakeblackshear/frigate:stable
    restart: unless-stopped
    privileged: true
    shm_size: "512mb"
    ports:
      - "5000:5000"
      - "8554:8554"
    volumes:
      - ./config:/config
      - ./media:/media/frigate
      - /etc/localtime:/etc/localtime:ro

    실행은 단순합니다.

    docker compose up -d
docker compose logs -f frigate

    기본 설정 파일은 이런 식으로 시작했습니다.

    mqtt:
  enabled: false

cameras:
  front_door:
    ffmpeg:
      inputs:
        - path: rtsp://USER:[email protected]:554/stream1
          roles:
            - detect
    detect:
      width: 1280
      height: 720
      fps: 5
    objects:
      track:
        - person
        - car
    snapshots:
      enabled: true

  parking:
    ffmpeg:
      inputs:
        - path: rtsp://USER:[email protected]:554/stream1
          roles:
            - detect
    detect:
      width: 1280
      height: 720
      fps: 5
    objects:
      track:
        - person
        - car

    처음엔 이것만으로도 굴러갑니다. 그런데 여기서 만족하면 오탐 감소는 반쯤밖에 안 됩니다. 진짜 차이는 다음 단계에서 나더라고요.

    Frigate AI NVR 설정과 홈랩 CCTV 감지 영역 구성 화면

    카메라별 detect 해상도, FPS, 추적 객체, 영역 설정을 조정하는 실전 구성 이미지를 넣는 자리입니다.

    5. 오탐 감소 핵심: 영역 제한과 객체 필터

    제가 가장 큰 효과를 본 건 zone(존, 감지 영역)과 track(추적 객체) 정리였습니다. 예를 들어 현관 카메라에서 굳이 고양이나 새까지 추적할 필요가 없었거든요. 사람만 제대로 잡으면 되는 환경이라면, 범위를 좁히는 게 훨씬 낫습니다.

    cameras:
  front_door:
    ffmpeg:
      inputs:
        - path: rtsp://USER:[email protected]:554/stream1
          roles:
            - detect
    detect:
      width: 1280
      height: 720
      fps: 5
    objects:
      track:
        - person
    zones:
      porch:
        coordinates: 220,720,420,420,980,420,1180,720

    이렇게 하면 화면 전체가 아니라, 실제로 사람이 서거나 지나가는 구역에 더 집중하게 됩니다. 물론 좌표는 직접 화면 보고 잡아야 해서 약간 귀찮습니다. 저도 처음엔 점 몇 개 찍는 게 뭐가 어렵나 했는데, 은근히 감각이 필요합니다. 너무 빡빡하게 잡으면 사람이 프레임 가장자리로 들어올 때 이벤트를 놓칠 수 있거든요.

    또 하나는 FPS입니다. 많은 분이 높을수록 좋다고 생각하시는데, 홈랩 CCTV 객체 감지 목적이라면 무조건 그렇진 않습니다. 오히려 감지용 스트림은 적절한 수준으로 낮춰서 안정적으로 분석하게 하는 편이 나았습니다. 특히 CPU가 빠듯한 미니 PC나 홈서버에서는 더 체감됐습니다.

    실무 느낌으로 정리한 튜닝 우선순위

    • 1순위: 카메라 각도와 불필요한 배경 제거
    • 2순위: 사람/차량처럼 필요한 객체만 추적
    • 3순위: 현관, 주차 구역 등 존 설정
    • 4순위: detect 해상도와 FPS 조정
    • 5순위: 이벤트 로그 보고 재조정

    6. ⚠️ 실제로 겪은 트러블슈팅

    이 부분은 정말 중요합니다. 설정 예시만 복붙하면 끝날 것 같지만, 현실은 늘 다르거든요. 제가 삽질했던 지점들을 정리해보겠습니다.

    1) 밤에 벌레가 사람처럼 잡히는 문제

    적외선 조명이 강한 카메라는 렌즈 앞 벌레가 크게 부각됩니다. 이 경우 소프트웨어만으로 100% 해결은 어렵습니다. 저는 카메라 위치를 조금 옮기고, 조명이 벽을 과하게 비추지 않게 조정하니 확실히 줄었습니다. 보안 카메라 최적화는 설정 파일 안에서만 일어나지 않더라고요.

    2) 비 오는 날 반사광 이벤트 폭증

    주차장 바닥이 젖으면 차량 불빛이 넓게 퍼집니다. 이때 화면 하단 반사 구역을 존 밖으로 빼거나, 실제 진입 경로만 존으로 남겨두는 식으로 정리했습니다. 이건 예상보다 효과가 컸습니다.

    3) RTSP 스트림 품질이 들쭉날쭉한 문제

    와이파이 구간이 불안정하면 감지 자체가 흔들립니다. 처음엔 객체 감지 모델을 의심했는데, 결국 네트워크 품질 이슈였습니다. 가능하면 고정 배선이나 안정적인 AP 구성이 먼저입니다.

    4) 화면은 넓은데 정작 대상은 너무 작게 나오는 문제

    한 화면에 마당 전체, 담장, 도로까지 다 넣으면 보기엔 시원합니다. 그런데 감지 정확도는 떨어질 수 있습니다. 사람 객체가 너무 작게 잡히면 분류가 불리해지거든요. 저는 차라리 카메라 역할을 나눠서 넓게 보는 카메라와 좁게 보는 카메라를 분리했습니다.

    문제 증상 해결 방향
    벌레 오탐 야간에 작은 물체가 크게 감지됨 카메라 위치, IR 반사, 구도 조정
    반사광 비 오는 날 이벤트 급증 존 축소, 반사 영역 제외
    불안정한 스트림 감지 누락, 프레임 깨짐 네트워크 안정화
    너무 넓은 화각 대상이 작아져 분류 어려움 카메라 역할 분리

    7. 검증: 어떤 기준으로 결과를 확인했는가

    최적화는 느낌으로 하면 끝이 없습니다. 저는 최소 3일 이상 로그를 보고, 같은 시간대 기준으로 비교했습니다. 예를 들어 새벽 1시부터 5시까지 이벤트 수가 얼마나 줄었는지, 실제 사람 방문 이벤트는 놓치지 않았는지를 같이 봤습니다.

    1. 최적화 전 이벤트 수를 대략 기록합니다.
    2. 존과 객체 필터를 바꾼 뒤 2~3일 관찰합니다.
    3. 오탐과 실제 이벤트를 분리해서 확인합니다.
    4. 놓친 감지가 있으면 구도 또는 존을 다시 완화합니다.

    제가 직접 해보니 가장 좋은 결과는 “이벤트 수가 적은 상태”가 아니라 의미 없는 이벤트는 줄고, 확인해야 할 이벤트는 남는 상태였습니다. 이 균형이 정말 중요합니다. 오탐 감소만 너무 밀어붙이면 진짜 사람이 지나갔는데도 안 잡히는 상황이 생길 수 있습니다.

    Frigate AI NVR 최적화 전후 오탐 감소 결과 대시보드

    최적화 전후의 이벤트 분포, 시간대별 감지 빈도, 실제 유효 이벤트 비율을 비교하는 결과 시각화 이미지입니다.

    docker logs frigate --tail 100
curl http://localhost:5000/

    로그를 볼 때는 에러만 찾지 말고, 감지가 몰리는 시간대와 카메라를 함께 보는 게 좋습니다. 특정 카메라만 유독 시끄럽다면 소프트웨어보다 설치 위치 문제일 가능성이 큽니다.

    8. 정리와 다음 단계

    Frigate AI NVR를 홈랩 CCTV에 붙여서 오탐 감소를 시도해 보면, 결국 답은 거창한 데 있지 않았습니다. 카메라가 무엇을 보고 있는지, 어떤 객체만 추적할지, 어느 구역만 의미 있게 볼지. 이 세 가지를 정리하니 체감이 확 오더라고요. 드디어 됐다! 싶은 순간이 있었습니다.

    정리하면 이렇습니다.

    • Frigate AI NVR는 모션 감지보다 의미 있는 이벤트 정리에 강점이 있습니다.
    • 홈랩 CCTV에서는 카메라 각도와 존 설정이 오탐 감소에 가장 큰 영향을 줍니다.
    • 객체 감지는 많이 잡는 것보다, 필요한 것만 정확히 잡게 만드는 쪽이 중요합니다.
    • 보안 카메라 최적화는 소프트웨어와 설치 환경을 같이 봐야 효과가 납니다.

    혹시 지금 알림 피로가 심한 상태라면, 제일 먼저 카메라 한 대만 골라서 테스트해 보세요. 전체를 한 번에 손대면 금방 복잡해집니다. 다음 글에서는 Frigate AI NVR와 Home Assistant 연동, 그리고 이벤트 자동화 흐름도 다뤄볼 예정입니다. 이전 글에서 홈랩 네트워크 분리와 저장소 구성 얘기를 보셨다면, 이번 최적화와 연결해서 보시면 더 이해가 쉬우실 겁니다.

    Frigate AI NVR 오탐 감소 체크리스트와 최적화 요약 인포그래픽

    카메라 각도, 존 설정, 객체 필터, 네트워크 안정화 등 핵심 체크포인트를 한 장으로 정리한 요약 이미지입니다.

    자주 묻는 질문

    Frigate AI NVR를 쓰면 오탐이 완전히 없어지나요?

    아닙니다. 다만 의미 없는 이벤트를 줄이고, 확인할 가치가 있는 이벤트 비율을 높이는 데 큰 도움이 됩니다.

    객체 감지는 무조건 많은 클래스를 켜는 게 좋나요?

    아닙니다. 목적이 현관 감시라면 사람 중심으로, 주차 감시라면 차량 중심으로 좁히는 편이 관리가 쉽습니다.

    설정만 만지면 해결되나요?

    경험상 절반만 맞습니다. 카메라 위치, 조명, 반사, 네트워크 상태까지 같이 봐야 제대로 정리됩니다.

  • [HomeLabs] CheapSecurity vs Frigate: 홈랩 CCTV AI NVR 솔루션 실측 비교

    [HomeLabs] CheapSecurity vs Frigate: 홈랩 CCTV AI NVR 솔루션 실측 비교

    목차

    [홈랩] 홈랩 CCTV AI NVR 비교: CheapSecurity vs Frigate 실측 관점 정리

    홈랩 CCTV AI NVR 구성을 고민하시는 분들이 요즘 정말 많습니다. 저도 집에서 카메라 몇 대 붙여놓고 단순 녹화만 하다가, 사람이나 차량 같은 객체를 자동으로 잡아주는 AI NVR이 필요해졌거든요. 처음엔 ‘그냥 싼 장비 하나 사면 끝 아닌가?’ 싶었는데, 실제로 써보니까 저장 방식, RTSP(실시간 스트리밍 프로토콜), 하드웨어 가속(Hardware Acceleration), 객체 탐지(Object Detection) 안정성이 생각보다 크게 갈리더라고요. 그래서 이번 글은 CheapSecurity vs Frigate라는 비교 키워드로 많이 찾는 분들을 위해, 제가 홈랩에서 판단했던 기준과 실제 구축 흐름을 정리해보겠습니다.

    먼저 중요한 점 하나 짚고 갈게요. Frigate는 실존하는 대표적인 오픈소스 AI NVR로 널리 알려져 있지만, CheapSecurity는 제가 확인 가능한 범위에서 구체적인 실존 제품 정보가 명확하지 않았습니다. 그래서 이 글에서는 CheapSecurity를 특정 브랜드나 모델로 단정하지 않고, 저비용 홈랩 CCTV AI NVR 구성 전반을 뜻하는 비교축으로 풀어가겠습니다. 이게 할루시네이션을 피하는 가장 안전한 방식이더라고요.

    홈랩 CCTV AI NVR 전체 아키텍처를 보여주는 이미지

    홈랩 CCTV AI NVR 아키텍처 예시입니다. 카메라, RTSP 스트림, NVR, 저장소, 알림 흐름을 한눈에 보여주는 용도예요.

    왜 홈랩 CCTV AI NVR 비교가 중요한가

    쉽게 말해 CCTV는 이제 녹화만 되는 박스로 끝나지 않습니다. 홈랩에서 직접 운영하면 다음 세 가지가 바로 체감됩니다.

    • 탐지 정확도: 움직임 감지(Motion Detection)만으로는 나뭇잎, 그림자, 비 오는 날 오탐이 너무 많습니다.
    • 저장 효율: 24시간 연속 녹화는 편하지만 디스크를 꾸준히 잡아먹습니다.
    • 운영 편의성: 컨테이너(Docker Container) 기반인지, 설정 파일 중심인지에 따라 유지보수 난도가 확 달라집니다.

    제가 직접 해보니 홈랩 CCTV AI NVR에서 핵심은 단순히 ‘싼가 비싼가’가 아니었습니다. 오탐을 얼마나 줄이느냐, 스트림이 얼마나 안정적이냐, 그리고 장애가 났을 때 내가 직접 고칠 수 있느냐가 훨씬 중요했습니다. 특히 홈랩은 기업 환경처럼 전용 장비를 계속 바꿀 수 있는 구조가 아니잖아요. 이미 갖고 있는 미니 PC, NAS(Network Attached Storage), 중고 카메라를 최대한 활용해야 하니까요.

    CheapSecurity vs Frigate, 개념부터 쉽게 정리해보겠습니다

    저도 처음엔 헷갈렸는데, 여기서는 두 방향으로 이해하면 편합니다.

    1. CheapSecurity 쪽 접근: 저비용 우선입니다. 기존 카메라와 남는 서버를 최대한 재활용하고, 기능은 꼭 필요한 것부터 붙이는 방식이죠.
    2. Frigate 쪽 접근: 객체 탐지(Object Detection) 중심입니다. 단순 모션보다 사람, 차량 같은 이벤트를 기준으로 운영하기 좋습니다.
    3. 결정 포인트: 예산보다 운영 목표가 먼저입니다. ‘녹화 보관’이 목적이면 단순 구성도 충분하고, ‘이벤트 기반 알림’이 목적이면 Frigate류가 훨씬 잘 맞습니다.

    사실 보안 카메라 비교를 할 때 많은 분이 카메라 화질만 먼저 보시는데요, 실제 운영에서는 NVR이 더 중요할 때가 많습니다. 카메라가 RTSP를 안정적으로 뿌려줘도 NVR이 그걸 잘 받아먹지 못하면 녹화 구멍이 생깁니다. 반대로 카메라가 아주 고급형이 아니어도, NVR 구성이 안정적이면 실사용 만족도가 꽤 올라갑니다.

    한눈에 보는 비교 표

    항목 저비용 홈랩 구성(CheapSecurity 관점) Frigate
    주요 목적 최소 비용으로 녹화와 기본 감시 객체 탐지 중심 AI NVR 운영
    구성 난이도 케이스마다 편차 큼 초기 학습은 필요하지만 구조가 비교적 명확함
    탐지 방식 모션 감지 위주로 흐르기 쉬움 사람, 차량 등 객체 기준 운영에 유리
    확장성 개별 조합에 따라 다름 홈 어시스턴트(Home Assistant) 연동 사례가 많음
    트러블슈팅 조합형이라 원인 분리가 어려울 수 있음 설정 파일 중심이라 재현과 수정이 편한 편
    추천 대상 예산이 가장 중요한 입문자 안정적인 이벤트 감시를 원하는 사용자

    실전 구현: 제가 홈랩에서 Frigate 기준으로 잡은 기본 구조

    실제로 써보니까 가장 덜 삽질하는 시작점은 이렇습니다.

    1. 카메라는 RTSP 스트림을 안정적으로 제공하는 모델을 사용합니다.
    2. NVR은 Docker Compose로 올립니다.
    3. 녹화 저장소는 로컬 SSD나 NAS 마운트 경로로 분리합니다.
    4. 탐지용 스트림과 녹화용 스트림을 분리하면 운영이 조금 더 편해집니다.

    여기서 중요한 포인트! 홈랩 CCTV AI NVR은 CPU를 계속 갈아 넣는 구조로 가면 오래 못 버팁니다. 처음엔 ‘이 정도면 버티겠지’ 했는데, 여러 대 붙이니 팬 소음과 발열이 바로 올라오더라고요. 그래서 구성 자체를 단순하게 잡는 게 좋습니다.

    1. 디렉터리 준비

    mkdir -p ~/homelab/frigate/config
mkdir -p ~/homelab/frigate/media
cd ~/homelab/frigate

    설정 파일과 녹화 저장소를 분리해두면 백업이나 마이그레이션 할 때 편합니다. 저는 이걸 안 나눠놨다가 나중에 경로 정리하느라 삽질 좀 했습니다 ㅎㅎ

    2. Docker Compose 작성

    services:
  frigate:
    container_name: frigate
    restart: unless-stopped
    image: ghcr.io/blakeblackshear/frigate:stable
    privileged: true
    shm_size: "512mb"
    ports:
      - "5000:5000"
      - "8554:8554"
      - "8555:8555/tcp"
      - "8555:8555/udp"
    volumes:
      - ./config:/config
      - ./media:/media/frigate
      - /etc/localtime:/etc/localtime:ro

    버전 태그를 세세하게 고정하지 않은 이유도 있습니다. 이 글은 특정 시점의 미확인 버전을 단정하기보다, 구조와 운영 포인트에 집중하려고 했거든요.

    3. 기본 설정 파일 예시

    mqtt:
  enabled: false

cameras:
  front_door:
    ffmpeg:
      inputs:
        - path: rtsp://USER:PASS@CAMERA_IP:554/stream1
          roles:
            - detect
            - record
    detect:
      enabled: true
    record:
      enabled: true
    snapshots:
      enabled: true
      timestamp: true
      bounding_box: true

    여기서는 가장 단순한 형태로만 시작하시면 됩니다. 처음부터 카메라 여러 대, 역할 분리, 알림 자동화까지 한 번에 넣으면 어디서 꼬였는지 파악이 안 됩니다. 저도 처음엔 욕심냈다가 결국 한 대만 붙여서 다시 검증했었거든요.

    홈랩 CCTV AI NVR에서 Frigate 설정과 컨테이너 구성을 설명하는 이미지

    Frigate 설정 파일, Docker Compose, 카메라 입력 흐름을 설명하는 구성 이미지가 들어갈 자리입니다.

    4. 컨테이너 실행

    docker compose up -d
docker compose logs -f frigate

    로그를 바로 보는 습관이 중요합니다. 웹 화면만 보고 있으면 ‘왜 안 되지?’ 상태가 길어집니다. 반면 로그를 보면 RTSP 인증 실패인지, 스트림 경로 문제인지, 디렉터리 권한 문제인지 금방 감이 옵니다.

    CheapSecurity 관점에서 봤을 때의 장점과 한계

    그렇다면 저비용 중심의 구성은 무조건 별로냐? 그건 아닙니다. 오히려 홈랩 입문에서는 아주 현실적인 선택일 수 있습니다.

    • 장점: 이미 가진 장비를 재활용하기 좋습니다.
    • 장점: 작은 규모에서는 투자 부담이 적습니다.
    • 장점: 학습용으로는 충분히 재미있습니다.
    • 한계: 기능이 여기저기 흩어지면 운영 일관성이 떨어집니다.
    • 한계: 객체 탐지 품질을 안정적으로 맞추려면 결국 별도 설계가 필요합니다.

    제가 실제로 느낀 차이는 이거였습니다. 저비용 조합은 처음 시작은 빠른데, 시간이 갈수록 관리 복잡도가 올라갑니다. 반면 Frigate는 초반 설정이 조금 귀찮아도, 구조가 잡히고 나면 비교적 덜 흔들립니다. 특히 보안 카메라 비교를 많이 해보신 분일수록 공감하실 텐데요. 장비가 늘수록 ‘설정이 코드처럼 관리되느냐’가 진짜 중요해집니다.

    ⚠️ 트러블슈팅: 제가 실제로 부딪힌 문제들

    여기서부터가 진짜 실전입니다. 드디어 됐다 싶다가 다시 무너지는 구간이 꼭 오더라고요.

    1. RTSP 연결은 되는데 화면이 불안정한 경우

    대부분 카메라 스트림 프로파일이 원인인 경우가 많았습니다. 메인 스트림은 녹화용, 서브 스트림은 탐지용으로 나누는 방식이 보통 더 안정적이더라고요.

    ffprobe rtsp://USER:PASS@CAMERA_IP:554/stream1

    해결 포인트: 스트림 자체가 흔들리면 NVR을 아무리 만져도 답이 없습니다. 카메라 쪽 인코딩 설정부터 확인하세요.

    2. 저장은 되는데 이벤트 검색이 불편한 경우

    이건 모션 감지 중심 구성에서 자주 느낀 문제였습니다. 비슷한 시간대의 잡이벤트가 너무 많아져서, 막상 필요한 장면을 찾는 시간이 길어지더라고요. 그래서 객체 기반 태깅이 왜 중요한지 뒤늦게 체감했습니다.

    3. CPU 사용률이 계속 높은 경우

    처음엔 이게 뭔가 싶었는데, 탐지와 녹화를 같은 고해상도 스트림 하나로 다 처리하면 부담이 커질 수 있습니다. 특히 홈랩 미니 PC는 여유가 넉넉하지 않거든요.

    • 탐지 스트림 해상도를 낮춰봅니다.
    • 동시 카메라 수를 줄여서 먼저 검증합니다.
    • 디스크 I/O 병목도 함께 봐야 합니다.

    중요: 성능 문제를 무조건 CPU 탓으로만 보면 안 됩니다. 네트워크, 저장소, 스트림 품질이 같이 얽혀 있는 경우가 많습니다.

    4. 권한 문제로 녹화 파일이 안 쌓이는 경우

    이건 진짜 자주 겪습니다. 컨테이너는 떠 있는데 파일이 안 생기면, 경로 권한부터 보셔야 합니다.

    ls -al ~/homelab/frigate
ls -al ~/homelab/frigate/media

    저는 예전에 NFS(Network File System) 마운트 경로로 연결했다가 권한이 꼬여서 반나절을 날린 적도 있습니다. 이런 날은 정말 허무하죠.

    홈랩 CCTV AI NVR 트러블슈팅과 로그 분석을 표현한 이미지

    로그 분석, RTSP 오류, 저장소 권한 문제 같은 트러블슈팅 장면을 보여주는 이미지 자리입니다.

    검증과 결과: 어떤 기준으로 비교해야 덜 후회하나

    실제로 써보니까 결과를 볼 때는 화려한 기능보다 아래 기준이 훨씬 중요했습니다.

    1. 이벤트 재생이 빠른가
    2. 오탐이 줄었는가
    3. 카메라 추가 시 설정이 반복 가능(repeatable)한가
    4. 문제 발생 시 로그와 설정 파일만으로 복구 가능한가

    여기서 Frigate의 강점은 꽤 분명했습니다. 객체 중심 이벤트 관리를 하려는 순간, 단순 저비용 조합보다 운영 일관성이 좋아지더라고요. 반대로 CheapSecurity식 접근, 즉 기존 자원 재활용 중심 접근은 예산을 많이 아껴야 하는 상황에서 꽤 유효했습니다. 다만 규모가 조금만 커져도 관리 체계가 필요해집니다.

    제가 정리한 결론은 이렇습니다.

    질문 추천 방향
    일단 가장 적은 비용으로 시작하고 싶은가 저비용 홈랩 조합부터 시작
    사람/차량 감지와 이벤트 탐색이 중요한가 Frigate 우선 검토
    나중에 홈 어시스턴트 연동까지 볼 생각인가 Frigate가 더 자연스러움
    운영보다 실험 자체가 목적인가 저비용 조합도 재미있음
    홈랩 CCTV AI NVR 결과 검증과 이벤트 대시보드를 보여주는 이미지

    탐지 이벤트, 썸네일, 타임라인 기반 검증 결과를 보여주는 대시보드 이미지 자리입니다.

    정리: 홈랩 CCTV AI NVR은 목적이 먼저입니다

    이번 비교를 한 문장으로 줄이면 이겁니다. CheapSecurity vs Frigate의 승부는 가격이 아니라 운영 목표에서 갈립니다. 단순 녹화와 저비용이 우선이면 가볍게 시작해도 됩니다. 하지만 나중에 사람 감지, 알림 자동화, 이벤트 검색 효율까지 보게 되면 Frigate 쪽 장점이 점점 더 크게 느껴질 가능성이 높습니다.

    혹시 이런 경험 있으신가요? 처음엔 싸게 시작했는데, 나중에 설정이 쌓이면서 오히려 시간이 더 들어가는 경우요. 저도 딱 그랬습니다. 그래서 지금은 장비 스펙보다도 운영 구조가 단순하고 재현 가능한가를 먼저 봅니다. 홈랩은 재미있어야 오래 가거든요.

    홈랩 CCTV AI NVR에서 CheapSecurity식 구성과 Frigate를 비교 요약한 이미지

    두 접근 방식의 장단점과 추천 상황을 한 장으로 요약한 인포그래픽이 들어갈 자리입니다.

    다음 단계 제안

    • 1단계: 카메라 1대로 RTSP 안정성부터 검증해보세요.
    • 2단계: 그 다음 Frigate 같은 AI NVR로 이벤트 기반 운영을 붙여보세요.
    • 3단계: 마지막에 저장 정책과 알림 정책을 다듬는 게 효율적입니다.

    다음 글에서는 홈 어시스턴트(Home Assistant)와 Frigate 연동이나, 카메라 스트림 분리 전략을 더 자세히 다뤄볼 예정입니다. 이전 글에서 다룬 Docker Compose 운영 팁도 같이 보시면 훨씬 이해가 빨라지실 겁니다.

    자주 묻는 질문 FAQ

    Q1. 홈랩 CCTV AI NVR 입문은 어떤 방향이 좋을까요?

    예산이 빡빡하면 저비용 조합으로 시작하셔도 됩니다. 다만 이벤트 기반 운영을 원하면 초반부터 Frigate를 검토하는 편이 장기적으로 편할 수 있습니다.

    Q2. 보안 카메라 비교에서 가장 먼저 봐야 할 건 뭔가요?

    해상도보다 RTSP 안정성, 스트림 설정 유연성, 그리고 NVR과의 궁합을 먼저 보시는 걸 추천드립니다.

    Q3. Frigate는 누구에게 잘 맞나요?

    단순 녹화보다 사람/차량 감지, 이벤트 검색, 자동화 연동이 중요한 분들께 잘 맞습니다.

    Q4. CheapSecurity라는 이름의 특정 제품을 찾고 있었는데요?

    제가 확인 가능한 범위에서는 특정 실존 제품으로 단정하기 어려웠습니다. 그래서 이 글에서는 저비용 홈랩 CCTV AI NVR 접근 전반을 뜻하는 비교 개념으로 다뤘습니다.

  • [HomeLabs] 기존 CCTV 시스템, Frigate AI NVR로 마이그레이션: 성공적인 전환 가이드

    [HomeLabs] 기존 CCTV 시스템, Frigate AI NVR로 마이그레이션: 성공적인 전환 가이드

    목차

    [홈랩] Frigate 마이그레이션으로 기존 CCTV 시스템 전환하기

    기존 CCTV 시스템을 쓰다가 답답함을 느끼는 순간이 한 번쯤 오더라고요. 녹화는 되는데 검색이 불편하고, 알림은 많은데 정작 필요한 장면은 놓치고, 모바일 앱이나 웹 화면도 제약이 많고요. 저도 홈랩에서 자가 호스팅 CCTV를 오래 굴리다 보니 결국 Frigate 마이그레이션을 진지하게 검토하게 됐습니다. 특히 AI NVR(인공지능 네트워크 비디오 레코더) 방식으로 사람, 차량 같은 객체를 기준으로 이벤트를 다루고 싶었거든요. 이번 글에서는 기존 보안 카메라 환경을 Frigate로 옮길 때 어떤 순서로 접근하면 덜 헤매는지, 제가 직접 해보며 삽질했던 포인트까지 묶어서 정리해보겠습니다.

    핵심부터 말씀드리면, Frigate 설정은 단순히 컨테이너 하나 띄우는 작업이 아닙니다. 카메라 스트림, RTSP(실시간 스트리밍 프로토콜), 저장소, 하드웨어 가속, 객체 감지기(detector), 그리고 기존 CCTV 운영 습관까지 같이 바꿔야 하거든요. 그래서 처음부터 전체 구조를 보고 들어가는 게 훨씬 낫습니다.

    Frigate 마이그레이션을 위한 기존 CCTV와 AI NVR 아키텍처 이미지

    기존 NVR, PoE 스위치, IP 카메라, Frigate 서버, 저장소가 어떻게 연결되는지 한눈에 보여주는 개요 이미지입니다.

    1. 왜 기존 CCTV 시스템을 Frigate AI NVR로 바꾸게 되는가

    쉽게 말해 Frigate는 영상 파일 중심으로 보던 CCTV를, 이벤트 중심으로 다시 정리해주는 도구에 가깝습니다. 기존 장비형 NVR(Network Video Recorder, 네트워크 비디오 녹화기)은 안정적이긴 한데, 검색과 확장성에서 아쉬운 경우가 많습니다. 반면 Frigate는 자가 호스팅 CCTV 환경에서 유연성이 크고, Home Assistant 같은 도구와도 궁합이 좋기로 많이 알려져 있죠.

    제가 실제로 옮기려 했던 이유는 아래 네 가지였습니다.

    • 이벤트 검색성: 단순 시간대 탐색보다 객체 기준 탐색이 훨씬 편했습니다.
    • 운영 통합: 홈랩에 이미 있는 Docker, NAS, 리버스 프록시(reverse proxy, 역방향 프록시)와 붙이기 좋았습니다.
    • 알림 품질 개선: 움직임만 잡는 방식보다 실제 필요한 이벤트만 고르기 쉬웠습니다.
    • 벤더 종속 감소: 특정 카메라 제조사 앱에 덜 묶이게 되더라고요.

    물론 무조건 교체가 답은 아닙니다. 기존 NVR이 매우 안정적이고, 가족이 사용하는 환경이라 변경 리스크가 크다면 병행 운영 기간을 반드시 두셔야 합니다. 여기서 중요한 포인트! Frigate 마이그레이션은 기능 업그레이드이면서 동시에 운영 모델 변경입니다.

    2. Frigate 마이그레이션 전에 알아둘 핵심 개념

    저도 처음엔 이게 뭔가 싶었는데, 개념만 정리되면 훨씬 수월합니다.

    2-1. Frigate는 무엇을 담당하나

    Frigate는 오픈소스 기반의 NVR 소프트웨어로 많이 사용됩니다. 영상 스트림을 받아 녹화하고, 감지 결과를 이벤트 단위로 관리합니다. 여기서 중요한 건 Frigate가 카메라 자체를 제어한다기보다, 카메라가 보내는 스트림을 잘 받아서 분석하고 저장하는 쪽에 가깝다는 점입니다.

    2-2. RTSP, detect stream, record stream

    보안 카메라를 붙일 때 많이 헷갈리는 부분이 이겁니다. 하나의 카메라에서도 메인 스트림과 서브 스트림이 따로 나오는 경우가 많거든요.

    • record stream: 녹화 품질 위주 스트림입니다. 해상도가 높고 저장용에 적합합니다.
    • detect stream: 객체 감지용 스트림입니다. 보통 더 가볍고, 시스템 부담을 줄이는 데 유리합니다.
    • go2rtc: 카메라 스트림 중계나 재가공에 자주 쓰이는 구성 요소입니다. 환경에 따라 활용도가 높습니다.

    제가 직접 해보니 detect와 record를 같은 고해상도 스트림으로 밀어붙이면 CPU가 금방 올라가더라고요. 처음부터 역할을 분리하는 게 좋습니다.

    2-3. 객체 감지와 하드웨어 가속

    AI NVR의 핵심은 객체 감지입니다. 다만 모든 처리를 CPU로만 해결하려고 하면 금방 한계가 옵니다. 그래서 운영 환경에 따라 GPU 가속이나 전용 감지기(detector)를 붙이는 구성을 많이 검토합니다. 이 부분은 서버 사양과 운영 목적에 따라 차이가 커서, 무리해서 한 번에 완성형으로 가기보다 카메라 수와 해상도 기준으로 단계적으로 확장하는 게 안전했습니다.

    3. 마이그레이션 설계: 기존 CCTV를 바로 끄지 말아야 하는 이유

    여기서 많이들 실수합니다. 기존 CCTV 장비를 먼저 내리고 Frigate 설정부터 맞추려 하면, 문제 생겼을 때 되돌아갈 길이 없어집니다. 저도 예전에 비슷하게 접근했다가 야간 녹화 확인이 꼬여서 식은땀 흘린 적이 있거든요.

    제가 권장하는 순서는 이렇습니다.

    1. 기존 NVR은 그대로 유지합니다.
    2. 카메라 한두 대만 Frigate에 병행 연결합니다.
    3. 녹화, 감지, 저장 정책을 먼저 검증합니다.
    4. 문제가 없으면 카메라를 순차적으로 옮깁니다.
    5. 최종적으로 운영 화면과 알림 경로를 정리합니다.

    병행 운영 기간에는 특히 아래 항목을 꼭 체크하세요.

    점검 항목 기존 CCTV Frigate 전환 시 체크 포인트
    카메라 연결 방식 벤더 앱 또는 NVR 종속 RTSP 주소 확인, 인증 방식 점검
    녹화 보관 장비 내부 디스크 중심 저장 경로, 보존 기간, 디스크 사용량 확인
    이벤트 탐색 타임라인 중심 객체 기반 이벤트 흐름 검증
    성능 전용 장비 최적화 CPU, 메모리, 디코딩 부하 확인
    장애 대응 단일 장비 재부팅 위주 컨테이너 로그, 스트림 재연결, 저장소 상태 확인

    4. 실전 구현: Docker 기준 Frigate 설정 흐름

    이제 실전입니다. 아래 예시는 개념을 설명하기 위한 기본 형태입니다. 실제 환경에서는 장치 매핑, 저장소 경로, 하드웨어 가속 설정이 달라질 수 있습니다. 저는 처음엔 최소 구성으로 올리고, 그 다음 카메라를 하나씩 붙이는 방식으로 갔습니다. 이게 진짜 편하더라고요.

    4-1. 디렉터리 구조 준비

    mkdir -p ./frigate/config
mkdir -p ./frigate/media
mkdir -p ./frigate/db

    구성을 분리해두면 나중에 백업이나 롤백이 훨씬 편합니다. 특히 설정 파일과 미디어 저장 경로는 처음부터 분리해두세요.

    4-2. 기본 Compose 예시

    services:
  frigate:
    container_name: frigate
    image: ghcr.io/blakeblackshear/frigate:stable
    restart: unless-stopped
    privileged: true
    shm_size: "512mb"
    ports:
      - "5000:5000"
      - "8554:8554"
    volumes:
      - ./frigate/config:/config
      - ./frigate/media:/media/frigate
      - ./frigate/db:/db
      - /etc/localtime:/etc/localtime:ro
    environment:
      FRIGATE_RTSP_PASSWORD: "strong-password"

    여기서 shm_size는 영상 처리 시 꽤 중요할 수 있습니다. 너무 작으면 예상 못 한 문제가 생기기도 합니다. 그리고 운영 환경에 따라 privileged 사용 여부는 보안 정책에 맞춰 검토하셔야 합니다.

    4-3. 기본 설정 파일 예시

    mqtt:
  enabled: false

ffmpeg:
  inputs: []

cameras:
  front_door:
    enabled: true
    ffmpeg:
      inputs:
        - path: rtsp://user:{FRIGATE_RTSP_PASSWORD}@192.168.10.20:554/stream1
          roles:
            - record
        - path: rtsp://user:{FRIGATE_RTSP_PASSWORD}@192.168.10.20:554/stream2
          roles:
            - detect
    detect:
      enabled: true
    record:
      enabled: true
    snapshots:
      enabled: true

    처음엔 카메라 이름을 물리적 위치 기준으로 짓는 걸 추천합니다. 예를 들면 front_door, parking, hallway 같은 식이죠. 나중에 알림 규칙 짤 때 훨씬 안 헷갈립니다.

    Frigate 설정에서 detect와 record 스트림 분리를 설명하는 보안 카메라 구성 이미지

    record 스트림과 detect 스트림을 분리해 설정하는 예시를 시각적으로 이해할 수 있는 이미지입니다.

    4-4. 단계별 적용 절차

    1. 카메라 한 대의 RTSP 주소를 먼저 확인합니다.
    2. 서브 스트림이 있다면 detect용으로 우선 연결합니다.
    3. Frigate 웹 UI에서 스트림이 정상 수신되는지 확인합니다.
    4. 그 다음 record 스트림을 붙여 녹화가 잘 되는지 봅니다.
    5. 이벤트가 과하게 잡히면 감지 영역(zone)이나 마스크(mask)를 조정합니다.
    6. 카메라별로 설정이 안정되면 다음 카메라로 넘어갑니다.

    이 순서를 지키면 문제 발생 지점을 좁히기 쉽습니다. 반대로 카메라 여러 대를 한 번에 붙이면 어느 부분이 병목인지 파악하기가 어렵습니다.

    5. Frigate 설정에서 자주 막히는 부분과 트러블슈팅

    이 섹션은 진짜 경험담입니다. 보기엔 단순한데 실제로는 여기서 시간을 많이 씁니다. 삽질 좀 했습니다 ㅎㅎ

    5-1. ⚠️ RTSP는 열리는데 화면이 불안정한 경우

    증상은 다양합니다. 영상이 잠깐 나오다가 멈추거나, 특정 카메라만 끊기거나, 감지 이벤트는 있는데 녹화가 비는 경우도 있죠.

    • 원인 후보 1: 카메라가 내보내는 코덱(codec, 영상 압축 방식)과 디코딩 경로가 맞지 않는 경우
    • 원인 후보 2: 메인 스트림만 사용해서 서버 부하가 과한 경우
    • 원인 후보 3: 네트워크 품질이나 PoE 스위치 상태 문제

    제가 직접 해보니 이럴 땐 무조건 Frigate 문제라고 보면 안 되더라고요. 카메라 웹 관리 화면에서 스트림 프로파일을 먼저 점검하고, 해상도와 프레임레이트(frame rate, 초당 프레임 수)를 보수적으로 잡는 게 효과적이었습니다.

    5-2. ⚠️ 감지가 너무 많이 뜨는 경우

    바람에 흔들리는 나뭇잎, 차량 라이트, 비 오는 날 반사 때문에 이벤트가 쏟아질 수 있습니다. 이건 AI NVR이라고 해서 자동으로 완벽해지진 않더라고요.

    • 카메라 각도 조정: 생각보다 중요합니다.
    • 감지 영역 분리: 현관, 주차 구역처럼 의미 있는 구역을 나눕니다.
    • 불필요 영역 마스킹: 도로, 나무, 하늘을 제외하면 훨씬 깔끔해집니다.

    혹시 이런 경험 있으신가요? 분명 사람 알림만 받고 싶은데 새벽마다 그림자 알림이 울리는 상황이요. 이건 설정만이 아니라 설치 위치와 화각 문제인 경우도 많습니다.

    5-3. ⚠️ 저장소가 빨리 차는 경우

    Frigate 마이그레이션 후 가장 체감되는 운영 이슈 중 하나가 저장소입니다. 기존 CCTV 장비는 내부 정책이 숨겨져 있어서 덜 의식하게 되는데, 자가 호스팅 CCTV는 내가 직접 책임져야 하거든요.

    record:
  enabled: true
  retain:
    days: 7
  events:
    retain:
      default: 14

    예시처럼 보존 기간을 분리해두면 운영이 편합니다. 연속 녹화는 짧게, 이벤트는 조금 더 길게 가져가는 식이 현실적이더라고요. 단, 정확한 값은 카메라 수와 해상도에 따라 달라서 무조건 정답은 없습니다.

    5-4. ⚠️ 기존 CCTV와 사용자 경험이 달라서 혼란스러운 경우

    이건 기술 이슈 같지 않지만 실제론 굉장히 큽니다. 가족이나 동료가 기존 앱 사용에 익숙하면, Frigate 웹 UI나 새 알림 흐름이 오히려 불편하게 느껴질 수 있거든요. 그래서 저는 완전 전환 전에 누가 어떤 화면으로 어떤 작업을 하는지부터 다시 정리했습니다. 이걸 안 하면 기술적으로는 성공인데 운영은 실패합니다.

    6. 검증 방법: 성공적인 Frigate 마이그레이션인지 어떻게 판단할까

    전환이 끝났다고 바로 기존 시스템을 철거하면 안 됩니다. 최소 며칠은 병행하면서 아래 기준으로 검증해보세요.

    1. 실시간 보기: 주요 카메라가 지연 없이 보이는가
    2. 이벤트 품질: 필요한 사람/차량 이벤트를 놓치지 않는가
    3. 녹화 신뢰성: 특정 시간대 영상 누락이 없는가
    4. 저장소 안정성: 디스크 사용량이 예상 범위 내인가
    5. 운영 편의성: 검색, 다운로드, 확인 흐름이 이전보다 나아졌는가

    저는 특히 야간, 우천 시, 역광 시간대를 따로 봤습니다. 낮에는 잘 되는데 밤에만 오탐이 늘거나 영상이 지저분해지는 경우가 있거든요. 실제로 써보니까 낮 테스트만으로는 절대 안심하면 안 되겠더라고요.

    Frigate 마이그레이션 결과를 확인하는 AI NVR 대시보드 이미지

    객체 이벤트 목록, 타임라인, 카메라 미리보기를 통해 전환 결과를 검증하는 모습을 보여주는 이미지입니다.

    검증 항목 확인 질문 통과 기준 예시
    이벤트 정확도 중요 이벤트가 빠지지 않았는가 현관/주차 구역 이벤트 확인 가능
    오탐 비율 의미 없는 알림이 과도하지 않은가 조정 후 체감상 감소
    리소스 사용량 서버가 과부하 없이 유지되는가 재생/감지 중에도 시스템 안정
    복구 용이성 스트림 장애 시 원인 파악이 쉬운가 로그와 설정 기준으로 추적 가능

    드디어 됐다! 싶은 시점은 단순히 화면이 뜰 때가 아니라, 필요한 순간에 원하는 장면을 안정적으로 찾을 수 있을 때입니다.

    7. 기존 CCTV 대비 Frigate 전환의 장단점 정리

    아무리 좋아 보여도 단점은 분명히 있습니다. 멘토처럼 솔직하게 말씀드리면, Frigate는 편한 만큼 책임도 따라옵니다.

    • 장점: 유연한 구성, 이벤트 중심 탐색, 자가 호스팅 CCTV와의 높은 궁합
    • 장점: 홈랩 자동화와 연계하기 좋음
    • 단점: 초기 설정 난이도 존재
    • 단점: 저장소와 성능 튜닝을 직접 관리해야 함
    • 단점: 카메라별 RTSP 품질 차이로 삽질 가능성 높음

    결국 선택 기준은 명확합니다. 내가 운영을 직접 챙길 의지가 있는가입니다. 벤더 일체형이 주는 편의성 대신, Frigate는 더 세밀한 제어권을 줍니다.

    8. 마무리: Frigate 설정은 설치보다 운영이 더 중요합니다

    이번 글에서는 기존 CCTV 시스템을 Frigate 마이그레이션하는 흐름을 큰 그림부터 실전 구성, 검증 포인트까지 정리해봤습니다. 제가 직접 해보니 제일 중요한 건 화려한 기능보다도 안정적인 스트림 확보, 보존 정책, 그리고 단계적 전환이었습니다. 사실 처음엔 컨테이너만 띄우면 끝날 줄 알았는데, 막상 해보면 카메라별 특성이 다르고 네트워크 상태도 달라서 생각보다 손이 많이 갑니다. 근데 그 과정을 한번 넘기면 운영 만족도가 꽤 올라가더라고요.

    특히 AI NVR, 보안 카메라, 자가 호스팅 CCTV 조합에 관심 있으신 분이라면, 무작정 전체 교체부터 하지 마시고 작은 파일럿부터 돌려보세요. 그게 시간을 가장 아끼는 길입니다.

    기존 CCTV와 Frigate 마이그레이션 전후 비교를 보여주는 자가 호스팅 CCTV 이미지

    전환 전후의 검색 방식, 운영 편의성, 확장성 차이를 직관적으로 비교해 보여주는 요약 이미지입니다.

    9. 정리 FAQ

    Frigate 마이그레이션은 어떤 환경에 특히 잘 맞나요?

    직접 서버를 운영하고, Docker나 NAS 기반 환경에 익숙한 분들께 잘 맞습니다. 홈랩 사용자라면 만족도가 높을 가능성이 큽니다.

    기존 NVR을 완전히 버려도 되나요?

    처음부터는 권하지 않습니다. 일정 기간 병행 운영하면서 녹화 누락, 이벤트 품질, 사용자 경험을 꼭 비교해보세요.

    Frigate 설정에서 가장 먼저 볼 것은 뭔가요?

    카메라 RTSP 스트림 품질, detect/record 역할 분리, 저장소 보존 정책 이 세 가지입니다.

    다음 글에서는 Frigate 설정을 조금 더 깊게 들어가서, 감지 영역(zone) 설계와 홈 자동화 연동 포인트를 따로 다뤄볼 예정입니다. 이전 글에서 다뤘던 홈랩 네트워크 분리나 리버스 프록시 구성과도 연결해서 보시면 훨씬 이해가 잘 되실 겁니다.

  • [홈랩] Frigate NVR 녹화 끊김·성능 저하 해결 디버깅 팁

    [홈랩] Frigate NVR 녹화 끊김·성능 저하 해결 디버깅 팁

    목차

    [홈랩] Frigate NVR 녹화 끊김·성능 저하 해결 디버깅 팁

    홈랩에서 카메라 몇 대만 붙여도 처음엔 잘 돌아가다가, 어느 순간 녹화가 뚝뚝 끊기고 CPU가 치솟는 경험 한 번쯤 있으실 겁니다. 저도 Frigate NVR 녹화 끊김 문제 때문에 꽤 오래 삽질했었는데요. 처음엔 카메라 문제인가 싶었고, 그다음엔 디스크가 느린가 싶었고, 나중엔 네트워크까지 의심하게 되더라고요. 근데 실제로 써보니까 이런 증상은 한 군데만 보는 식으로는 잘 안 잡힙니다. 입력 스트림, 디코딩, 감지 파이프라인, 저장소, 컨테이너 자원을 같이 봐야 하거든요.

    이번 글에서는 제가 홈랩에서 자주 만났던 Frigate NVR 성능 문제를 기준으로, 어디부터 확인해야 하는지 순서대로 정리해보겠습니다. 막연하게 “서버가 느린가?” 수준에서 끝내지 않고, 실제 로그와 명령어로 좁혀가는 방식입니다. 지금도 녹화 파일이 띄엄띄엄 생기거나, 타임라인이 비거나, 감지가 몰릴 때 프레임이 급격히 떨어지는 상황이라면 꽤 바로 도움이 되실 겁니다.

    Frigate NVR 녹화 끊김 점검을 위한 홈랩 아키텍처 개요

    Frigate NVR, IP 카메라, 스토리지, GPU 또는 iGPU 가속 경로를 한눈에 보여주는 홈랩 구성 예시입니다.

    Frigate NVR 녹화 끊김이 생기는 구조부터 이해해봅시다

    쉽게 말해 Frigate는 카메라에서 들어오는 영상 스트림을 받아서, 필요한 경우 decode(디코드, 압축 해제)하고, detect(객체 감지)에 쓰고, record(녹화)용으로 저장합니다. 여기서 중요한 포인트가 있습니다. 우리가 보기엔 그냥 “영상 하나”지만, 내부적으로는 역할이 나뉘어 있는 경우가 많습니다.

    • record(녹화): 원본에 가깝게 저장하는 흐름입니다.
    • detect(감지): 객체 인식용으로 해상도나 프레임을 낮춰 쓰는 경우가 많습니다.
    • ffmpeg: 스트림을 받아서 변환하고 전달하는 핵심 도구입니다.
    • hwaccel(하드웨어 가속): CPU 대신 GPU나 iGPU를 활용해 디코딩 부담을 줄입니다.

    이 구조를 모르고 접근하면 보통 녹화 끊김이 생겼을 때 CPU만 봅니다. 저도 처음엔 그랬거든요. 근데 실제 원인은 CPU가 아니라 RTSP 스트림 불안정, 디스크 I/O 병목, 컨테이너 볼륨 권한 문제, detect와 record를 같은 고해상도 스트림으로 태운 설정 같은 쪽에서 더 자주 나왔습니다.

    Frigate 디버깅 순서: 제가 먼저 확인하는 체크리스트

    Frigate 디버깅은 순서가 중요합니다. 여기서 한 번에 다 건드리면 더 헷갈립니다. 저는 아래 순서로 봅니다.

    1. 컨테이너와 Frigate 로그에 에러가 있는지 확인합니다.
    2. CPU, 메모리, 디스크 I/O 사용량을 동시에 봅니다.
    3. 카메라 RTSP 스트림이 독립적으로 안정적인지 테스트합니다.
    4. detect용 스트림과 record용 스트림을 분리했는지 확인합니다.
    5. 하드웨어 가속이 실제로 적용됐는지 확인합니다.
    6. 저장소가 로컬 디스크인지, 느린 네트워크 스토리지인지 확인합니다.

    여기서 중요한 건 증상과 원인을 분리하는 겁니다. 예를 들어 CPU 90%는 원인이 아니라 결과일 수 있습니다. RTSP 재연결이 반복되면 ffmpeg 프로세스가 늘어나고, 그게 다시 전체 성능 저하로 보일 수 있거든요.

    실전 구현 1: 로그와 자원부터 확인합니다

    가장 먼저 아래 명령어부터 보시면 됩니다. Docker(도커) 환경 기준으로 적어볼게요.

    docker ps

docker logs --tail=200 frigate

docker stats frigate

df -h

iostat -xz 1

free -m

top

    제가 직접 해보니 여기서 이미 방향이 잡히는 경우가 많았습니다. 예를 들어 docker stats에서 CPU가 높게 치솟는데 디스크는 한가하다면 디코딩이나 감지 쪽을 먼저 의심하게 되고요. 반대로 CPU는 괜찮은데 iostat에서 await가 길게 나오면 저장소 병목일 가능성이 큽니다.

    로그에서 특히 자주 보는 단서는 이런 것들입니다.

    • Connection timed out: 카메라 또는 네트워크 구간 문제일 수 있습니다.
    • No frames received: 스트림이 끊기거나 인증이 꼬였을 수 있습니다.
    • error while decoding: 코덱, 하드웨어 가속, 손상된 스트림을 의심합니다.
    • Unable to write: 저장소 권한 또는 디스크 공간 문제일 수 있습니다.

    자원 병목을 빠르게 비교하는 기준

    증상 먼저 볼 곳 의심 원인 우선 조치
    녹화가 띄엄띄엄 저장됨 디스크 I/O, 볼륨 경로 저장소 병목, 권한 문제 로컬 SSD 확인, 마운트 경로 재검토
    CPU가 계속 높음 ffmpeg 프로세스, hwaccel 소프트웨어 디코딩, 고해상도 detect 하드웨어 가속 적용, detect 스트림 분리
    특정 카메라만 자주 끊김 카메라 RTSP 테스트 카메라 펌웨어, 네트워크 불안정 개별 스트림 재생 테스트
    감지 몰릴 때 전체가 느려짐 객체 감지 설정, 해상도 detect 과부하 해상도/프레임 조정

    실전 구현 2: 카메라 스트림과 설정을 분리해서 봅니다

    Frigate NVR 성능 문제를 줄이는 데서 가장 체감이 큰 건, 보통 녹화용 스트림과 감지용 스트림을 분리하는 겁니다. 처음엔 “어차피 같은 카메라 영상인데 왜 나누지?” 싶었는데, 이게 효과가 꽤 큽니다. 감지는 낮은 해상도와 적당한 프레임으로도 충분한 경우가 많거든요.

    cameras:
  front_door:
    ffmpeg:
      inputs:
        - path: rtsp://USER:[email protected]:554/stream1
          roles:
            - record
        - path: rtsp://USER:[email protected]:554/stream2
          roles:
            - detect
    detect:
      width: 1280
      height: 720
      fps: 5
    record:
      enabled: true

    위 예시는 원리를 보여주기 위한 단순한 형태입니다. 핵심은 이겁니다.

    1. record는 화질 보존이 우선입니다.
    2. detect는 낮은 부담으로 안정성이 우선입니다.
    3. 모든 역할을 같은 고해상도 스트림 하나로 몰아주면 CPU가 쉽게 올라갑니다.
    Frigate NVR 성능 문제를 줄이기 위한 record와 detect 스트림 분리 구성

    녹화용 원본 스트림과 감지용 저해상도 스트림을 나눠 CPU 부담을 줄이는 구성 예시입니다.

    그리고 RTSP 스트림 자체가 안정적인지도 꼭 따로 확인해보셔야 합니다. 저는 이걸 나중에 봤다가 시간을 많이 썼습니다 ㅎㅎ

    ffprobe rtsp://USER:[email protected]:554/stream1

ffplay rtsp://USER:[email protected]:554/stream1

    Frigate 밖에서 재생이 불안정하면, Frigate 안에서 아무리 튜닝해도 해결이 안 됩니다. 여기서 끊기면 카메라 자체 설정, 스위치 포트, PoE 상태, 무선 구간 사용 여부까지 봐야 합니다.

    실전 구현 3: 하드웨어 가속과 저장소를 점검합니다

    저도 처음엔 “서버 CPU가 꽤 괜찮은데 왜 이러지?” 했었는데, 실제로 써보니까 하드웨어 가속이 빠졌거나 제대로 붙지 않은 상태가 정말 흔합니다. 특히 여러 대 카메라를 붙이면 소프트웨어 디코딩만으로는 금방 버거워집니다.

    리눅스에서 장치가 보이는지부터 확인합니다.

    ls /dev/dri

vainfo

docker exec -it frigate ls /dev/dri

    여기서 장치가 보이지 않으면 컨테이너에 디바이스 전달이 안 된 경우가 많습니다. 반대로 장치는 보이는데 여전히 CPU가 높다면, ffmpeg 쪽 옵션이나 실제 사용 코덱과 가속 경로가 맞지 않는 경우가 있습니다. 이런 부분은 하드웨어마다 조금씩 다르기 때문에, 무리해서 확정적으로 단정하기보다 로그와 실제 CPU 변화를 같이 보시는 게 안전합니다.

    저장소도 중요합니다. 특히 NVR 오류 해결을 하다 보면 네트워크 스토리지에 바로 녹화하는 구성이 종종 보이는데요. 편하긴 한데, 지연(latency, 지연 시간)이 조금만 늘어나도 타임라인이 비거나 녹화가 밀리는 증상이 생길 수 있습니다. 저는 가능하면 로컬 SSD에 먼저 기록하고, 이후 보관 정책으로 넘기는 방식을 선호합니다.

    ⚠️ 실제로 자주 만난 Frigate 녹화 끊김 문제와 해결법

    여기부터는 제가 직접 해보니 재현 빈도가 높았던 케이스들입니다. Frigate 디버깅할 때 꽤 자주 만납니다.

    1. 특정 시간대에만 녹화 끊김이 생기는 경우

    이건 네트워크 트래픽 몰림이나 디스크 백그라운드 작업이 원인인 경우가 많았습니다. 백업, 썸네일 작업, 다른 컨테이너 업데이트가 겹치면 체감상 “Frigate만 문제”처럼 보이거든요.

    • 해결 팁: 같은 시간대에 돌아가는 작업 스케줄을 확인합니다.
    • 확인 명령어: <code>docker stats, iostat -xz 1, dmesg

    2. 녹화는 되는데 감지 순간만 프레임이 떨어지는 경우

    detect 해상도나 fps가 과한 경우가 많았습니다. 특히 카메라 수가 늘어날수록 누적 부담이 커집니다.

    • 해결 팁: detect 해상도와 fps를 낮춰봅니다.
    • 확인 포인트: 객체 감지 정확도와 CPU 사용량을 같이 봅니다.

    3. 컨테이너 재시작 후부터 녹화 경로 오류가 나는 경우

    볼륨 마운트 경로가 달라졌거나 권한이 꼬인 경우가 있었습니다. 로그에는 단순한 write error처럼 보이는데, 알고 보면 호스트 경로 소유권 문제더라고요.

    ls -al /path/to/frigate/media

id

docker inspect frigate
    • 해결 팁: 컨테이너 사용자와 호스트 디렉터리 권한을 같이 확인합니다.

    4. 카메라 한 대만 유독 불안정한 경우

    이건 Frigate가 아니라 카메라 쪽 문제였던 적이 많았습니다. 펌웨어, RTSP 세션 제한, 비트레이트 과다, 스위치 포트 상태 같은 게 숨어 있더라고요.

    • 해결 팁: 카메라를 직접 재생해보고, 동일 모델 다른 장비와 비교합니다.
    • 추가 확인: 고정 비트레이트(CBR)와 키프레임 간격도 확인해보면 좋습니다.

    CPU 사용량, 디스크 지연, 로그 메시지를 함께 보면서 병목 지점을 찾아가는 실제 디버깅 흐름 예시입니다.

    검증: Frigate 성능 개선 후 무엇을 보면 될까요?

    설정을 바꿨으면 바로 체감으로만 판단하지 마시고, 최소 몇 시간은 지표를 보시는 걸 권장드립니다. 저도 처음엔 “드디어 됐다!” 싶었는데, 밤에 다시 끊겨서 허탈했던 적이 있거든요.

    1. Frigate 타임라인에 빈 구간이 줄었는지 확인합니다.
    2. 컨테이너 CPU 사용률이 이전보다 안정적인지 봅니다.
    3. 디스크 await와 utilization이 과하게 치솟지 않는지 봅니다.
    4. 특정 카메라의 재연결 로그가 줄었는지 확인합니다.
    5. 감지 정확도가 너무 희생되지 않았는지 같이 봅니다.

    여기서 중요한 포인트! 성능 최적화와 감지 품질은 항상 트레이드오프가 있습니다. detect 해상도와 fps를 너무 낮추면 CPU는 편해지지만, 작은 객체를 놓칠 수 있거든요. 그래서 저는 한 번에 크게 바꾸지 않고, 한 항목씩 줄여가면서 로그와 결과를 비교합니다.

    조치 항목 기대 효과 주의점
    detect fps 낮춤 CPU 감소 빠른 움직임 감지 저하 가능
    detect 해상도 낮춤 디코딩/감지 부담 감소 작은 객체 인식률 저하 가능
    하드웨어 가속 적용 CPU 대폭 완화 가능 장치 전달, 코덱 호환 확인 필요
    로컬 SSD 저장 녹화 안정성 향상 보관 공간 관리 필요
    Frigate NVR 녹화 끊김 해결 후 안정화된 타임라인과 모니터링 결과

    타임라인 빈 구간이 줄고 CPU와 디스크 지표가 안정화된 결과를 보여주는 대시보드 예시입니다.

    정리: Frigate NVR 녹화 끊김은 한 군데만 보면 잘 안 잡힙니다

    이번 글을 한 줄로 요약하면 이겁니다. Frigate NVR 녹화 끊김 문제는 카메라, ffmpeg, 감지 설정, 저장소, 하드웨어 가속을 같이 봐야 풀립니다. 저도 처음엔 이게 뭔가 싶었는데, 결국 가장 효과적이었던 건 복잡한 튜닝보다도 원인 후보를 하나씩 지워가는 디버깅 순서였습니다.

    특히 아래 네 가지는 거의 항상 점검하시는 걸 추천드립니다.

    • detect와 record 스트림을 분리했는지
    • 하드웨어 가속이 실제로 적용됐는지
    • RTSP 스트림 자체가 안정적인지
    • 녹화 저장소가 병목이 아닌지

    이 방식으로 보면 Frigate NVR 성능 문제가 생각보다 빨리 좁혀집니다. 다음 글에서는 홈랩 기준으로 저장소 분리 전략이나, 카메라 수가 늘어났을 때 운영 포인트도 따로 정리해보겠습니다. 이전에 다뤘던 컨테이너 자원 분리 방식과 같이 보시면 더 이해가 잘 되실 거예요.

    최적화 전후의 CPU 사용량, 녹화 안정성, 디버깅 포인트를 한 장으로 정리한 요약 인포그래픽입니다.

    자주 묻는 질문

    Q1. CPU만 낮추면 Frigate 디버깅이 끝난 걸까요?

    아닙니다. CPU가 낮아도 디스크 쓰기 지연이나 RTSP 재연결이 있으면 녹화는 계속 끊길 수 있습니다. 그래서 로그와 저장소 지표를 같이 봐야 합니다.

    Q2. Frigate NVR 녹화 끊김이 있을 때 가장 먼저 볼 항목은 뭔가요?

    저는 컨테이너 로그, 카메라 스트림 단독 재생, 디스크 I/O 이 세 가지부터 봅니다. 이 세 군데에서 방향이 잡히는 경우가 많았습니다.

    Q3. 무조건 detect 해상도를 낮추면 되나요?

    그건 아닙니다. 작은 객체를 중요하게 보시는 환경이면 감지 품질이 너무 떨어질 수 있습니다. 한 번에 크게 바꾸지 말고 단계적으로 조정해보시는 게 좋습니다.

  • [홈랩] Frigate NVR 하드웨어 체크리스트: 최적 성능을 위한 선택

    [홈랩] Frigate NVR 하드웨어 체크리스트: 최적 성능을 위한 선택

    목차

    [홈랩] Frigate NVR 하드웨어 체크리스트: 최적 성능을 위한 선택

    Frigate NVR 하드웨어를 어떻게 골라야 하는지 막막하셨다면, 딱 그 지점에서 이 글을 보시면 됩니다. 저도 처음 Frigate를 붙일 때는 “카메라 몇 대 안 되는데 아무 미니 PC나 쓰면 되겠지” 하고 시작했었거든요. 근데 실제로 써보니까 NVR(Network Video Recorder, 네트워크 영상 녹화 장치)은 단순 저장 장비가 아니라 영상 디코딩, 객체 감지, 저장, 네트워크 처리가 한 번에 몰리는 워크로드였습니다. 여기서 하드웨어 선택을 대충 하면 CPU는 100%로 치솟고, 녹화는 끊기고, 홈랩 보안은 오히려 불안해지더라고요.

    이번 글은 광고성 추천이 아니라, 제가 홈랩에서 Frigate, 보안 카메라, Coral AI(코랄 AI 가속기) 조합을 만지면서 정리한 실전 체크리스트입니다. 제품명만 나열하기보다 어떤 부품이 왜 중요한지, 어디서 병목이 생기는지, 그리고 최소한 무엇부터 챙겨야 하는지 멘토처럼 짚어보겠습니다.

    Frigate NVR 하드웨어 전체 아키텍처를 보여주는 홈랩 보안 구성 이미지

    Frigate, 보안 카메라, 스토리지, Coral AI, 스위치가 어떻게 연결되는지 한눈에 보여주는 전체 구성도입니다.

    1. 왜 Frigate NVR 하드웨어가 먼저 정리되어야 할까요?

    쉽게 말해 Frigate는 “녹화기”이면서 동시에 “영상 분석기”입니다. 카메라에서 RTSP(Real Time Streaming Protocol, 실시간 스트리밍 프로토콜)로 영상을 받아오고, ffmpeg로 스트림을 처리하고, 객체 감지를 돌리고, 이벤트 클립과 스냅샷을 저장하죠. 이 중에서 특히 무거운 건 영상 디코딩과 객체 감지입니다.

    제가 직접 해보니 같은 카메라 4대라도 설정에 따라 부하 차이가 꽤 컸어요. 해상도가 높아질수록, 프레임 수가 늘어날수록, 감지 구역이 많아질수록 하드웨어 부담이 훅 올라갑니다. 그래서 Frigate NVR 하드웨어를 고를 때는 “서버가 켜지느냐”보다 지속적으로 안정 동작하느냐를 봐야 합니다. 여기서 중요한 포인트! 처음부터 과하게 비싼 장비를 살 필요는 없지만, 병목이 생기는 영역은 정확히 알아야 삽질을 줄일 수 있습니다.

    2. Frigate와 NVR의 핵심 개념, 쉽게 말해 이겁니다

    Frigate는 오픈소스 NVR로 많이 알려져 있고, 홈 어시스턴트(Home Assistant)와 함께 쓰는 분도 꽤 많아요. 구조를 아주 단순하게 풀면 아래 흐름입니다.

    1. 보안 카메라가 영상을 계속 보냅니다.
    2. Frigate가 그 영상을 받아 녹화합니다.
    3. 필요하면 객체 감지(Object Detection, 사람/차량/동물 등 인식)를 수행합니다.
    4. 이벤트만 따로 저장하거나 알림을 보냅니다.

    이때 CPU는 전체 제어와 일부 디코딩을 맡고, GPU(Graphics Processing Unit, 그래픽 처리 장치)나 iGPU(내장 GPU)는 영상 가속을 도와주고, Coral AI 같은 TPU(Tensor Processing Unit, 추론 가속기)는 객체 감지를 덜어줍니다. 스토리지는 녹화 영상을 버티는 저장소 역할을 하고요. 즉, 한 부품만 좋아서는 안 되고 전체 밸런스가 맞아야 해요.

    3. Frigate NVR 하드웨어 체크리스트: 꼭 보는 항목 6가지

    3-1. CPU: 무조건 고클럭보다 “지속 부하”가 중요합니다

    처음엔 코어 수만 보면 되는 줄 알았는데, 실제로 써보니까 Frigate는 장시간 켜두는 서비스라서 발열과 스로틀링(throttling, 발열로 인한 성능 제한)도 같이 봐야 하더라고요. 소형 장비는 순간 성능은 괜찮아도 여름철에 성능이 출렁이는 경우가 있습니다.

    • 카메라 수: 2대와 8대는 완전히 다른 이야기입니다.
    • 해상도/프레임: 1080p와 4MP 이상급은 부하 차이가 큽니다.
    • 하드웨어 가속 유무: 지원되는 환경에서는 CPU 부담을 크게 줄어들어요.

    3-2. Coral AI: 객체 감지용 가속기는 체감 차이가 큽니다

    Frigate 이야기에서 Coral AI를 빼기 어렵습니다. 저도 처음엔 “CPU로도 되지 않나?” 싶었는데, 객체 감지를 CPU로 오래 돌리면 다른 작업까지 같이 무거워지더라고요. Coral USB Accelerator나 M.2 기반 Edge TPU 같은 실존하는 Coral 장치는 Frigate 구성에서 많이 쓰이는 편입니다.

    특히 사람, 차량 같은 이벤트 감지를 꾸준히 돌릴 계획이라면 Coral AI 같은 추론 가속기를 고려할 만한 가치가 충분해요. 다만 여기서 중요한 건, Coral이 모든 문제를 해결해주진 않는다는 점입니다. 영상 디코딩 병목은 여전히 별개라서 CPU/iGPU/스토리지도 같이 맞춰야 합니다.

    3-3. 저장장치: SSD와 HDD를 역할 분리하면 편합니다

    이거 진짜 편하더라고요. 운영체제, 컨테이너, 데이터베이스 성격의 파일은 SSD에 두고, 연속 녹화는 HDD에 두는 방식입니다. 제가 한동안 전부 한 디스크에 몰아넣고 썼었는데, 로그와 녹화가 같이 쌓이니 관리가 번거로웠어요.

    • SSD: OS, Docker, Frigate 메타데이터, 캐시
    • HDD: 장시간 녹화 보관
    • 여유 용량: 이벤트 중심 저장인지, 24시간 연속 녹화인지에 따라 크게 달라집니다

    3-4. 네트워크: 카메라보다 스위치가 먼저 흔들릴 수 있습니다

    보안 카메라는 한 대씩 보면 대역폭이 커 보이지 않는데, 여러 대가 동시에 붙으면 스위치와 업링크가 생각보다 바빠집니다. PoE(Power over Ethernet, 랜선 전원 공급) 스위치를 쓰면 배선은 깔끔해지지만, 전력 예산도 함께 봐야 해요. 홈랩 보안에서 의외로 자주 놓치는 부분입니다.

    3-5. 카메라 스트림 호환성: RTSP와 코덱 확인은 필수입니다

    Frigate 자체보다 카메라 설정에서 더 오래 헤매는 경우도 많더라고요. 메인 스트림은 녹화용, 서브 스트림은 감지용으로 나누는 구성이 흔한데요, 실제로 써보니까 카메라가 RTSP를 안정적으로 제공하는지, H.264/H.265 코덱을 어떻게 내보내는지부터 확인해야 했습니다.

    3-6. 전원과 냉각: 조용한 서버가 꼭 좋은 서버는 아니더라고요

    24시간 켜둘 장비라면 어댑터 품질, 케이스 통풍, 팬 소음보다 먼저 안정성을 보셔야 합니다. 미니 PC나 소형 보드 장비는 공간은 적게 먹지만, 먼지와 여름철 온도에 꽤 민감하더라고요. 저도 처음엔 무소음이 좋아 보였는데, 결국 약한 강제 냉각을 넣고 훨씬 안정화됐습니다.

    항목 중요 이유 체크 포인트
    CPU 전체 처리와 디코딩 부담 카메라 수, 발열, 지속 성능
    Coral AI 객체 감지 오프로딩 USB 또는 M.2 연결 가능 여부
    스토리지 녹화 데이터 누적 SSD/HDD 분리, 보관 기간
    네트워크 다중 카메라 스트림 수집 PoE, 스위치 용량, 케이블 상태
    카메라 스트림 품질과 호환성 RTSP, 서브 스트림, 코덱
    냉각/전원 24시간 안정성 온도, 어댑터, 팬 구성

    4. 실전 구현: 제가 주로 확인하는 구축 순서

    여기서는 제품 추천보다, 어떤 순서로 확인하면 덜 꼬이는지 말씀드리겠습니다. 저도 처음엔 Docker부터 올렸다가 카메라 스트림 문제를 뒤늦게 발견해서 삽질 좀 했습니다 ㅎㅎ 순서는 아래처럼 가는 게 훨씬 낫습니다.

    1. 카메라 RTSP 접속 확인
    2. 서버에서 저장소 마운트 구성
    3. Docker와 Frigate 컨테이너 실행
    4. 감지용 서브 스트림 연결
    5. Coral AI 인식 여부 확인
    6. 녹화/이벤트 저장 경로 검증
    7. 온도와 CPU 사용률 모니터링
    docker run --rm hello-world
ls /dev/bus/usb
lsblk
df -h

    위 명령은 아주 기본이지만 꼭 해보시는 걸 권합니다. 특히 Coral USB를 쓴다면 장치가 보이는지부터 확인해야 하고, 저장소는 남은 공간보다 어디에 마운트됐는지가 더 중요합니다.

    mqtt:
  enabled: false

cameras:
  front_door:
    ffmpeg:
      inputs:
        - path: rtsp://USER:PASS@CAMERA_IP:554/stream1
          roles:
            - record
        - path: rtsp://USER:PASS@CAMERA_IP:554/stream2
          roles:
            - detect
    detect:
      enabled: true
    record:
      enabled: true

detectors:
  coral:
    type: edgetpu
    device: usb

    설정의 핵심은 녹화용 스트림과 감지용 스트림을 분리하는 겁니다. 메인 스트림은 선명하지만 무겁고, 서브 스트림은 가볍지만 감지에는 충분한 경우가 많거든요. Frigate NVR 하드웨어 부담을 줄이는 가장 현실적인 방법 중 하나입니다.

    Frigate NVR 하드웨어에서 메인 스트림과 서브 스트림 분리 구성을 설명하는 이미지

    메인 스트림은 녹화, 서브 스트림은 감지에 사용하는 Frigate 설정 흐름을 보여주는 구성 이미지입니다.

    docker compose up -d
docker logs frigate
docker stats

    docker stats를 보면 대략적인 CPU와 메모리 사용량을 볼 수 있습니다. 드디어 됐다! 싶어도 바로 끝내지 말고, 카메라 여러 대를 동시에 붙였을 때도 안정적인지 꼭 보세요.

    5. ⚠️ 실제로 많이 겪는 문제와 해결 포인트

    이 섹션은 이론보다 실전입니다. 저도 처음엔 설정 파일 문법보다 하드웨어 병목에서 더 많이 막혔습니다.

    • CPU 사용률이 너무 높다: 감지 해상도를 낮추고, 서브 스트림을 감지용으로 분리해보세요. 하드웨어 가속 지원 여부도 다시 확인해야 합니다.
    • Coral AI가 안 잡힌다: USB 패스스루나 장치 권한 문제일 수 있습니다. 컨테이너에서 장치가 노출되는지 먼저 확인하세요.
    • 녹화가 중간중간 끊긴다: 네트워크 품질, 카메라 RTSP 안정성, 디스크 쓰기 지연을 순서대로 의심하는 게 좋습니다.
    • 저장 공간이 너무 빨리 찬다: 연속 녹화와 이벤트 녹화를 분리해서 생각해야 합니다. 보관 기간(retention)을 현실적으로 잡아야 합니다.
    • 장비가 뜨거워진다: 특히 소형 장비는 케이스 내부 공기 흐름만 바꿔도 안정성이 확 달라져요.

    혹시 이런 경험 있으신가요? 저는 한동안 카메라 문제인 줄 알았는데, 알고 보니 USB Coral이 허브를 타면서 인식이 불안정했던 적이 있었습니다. 결국 포트를 바꾸고 전원 환경을 정리하니 해결됐습니다. 사소해 보여도 이런 물리 계층 이슈가 꽤 많습니다.

    6. 검증 방법: 구축 후 무엇을 확인해야 할까요?

    구축이 끝났다고 바로 안심하긴 이릅니다. 홈랩 보안은 “켜졌다”보다 “며칠 지나도 멀쩡하다”가 훨씬 중요하거든요. 제가 보통 보는 검증 포인트는 아래와 같습니다.

    1. Frigate 대시보드에서 카메라별 라이브 뷰가 안정적으로 보이는지
    2. 사람이나 차량 같은 객체 이벤트가 정상 기록되는지
    3. 녹화 디렉터리에 파일이 꾸준히 생성되는지
    4. CPU, 메모리, 온도가 과하게 치솟지 않는지
    5. 재부팅 후에도 자동으로 서비스가 복구되는지
    docker ps
docker logs --tail 100 frigate
df -h
uptime

    실제로 써보니까 하루 정도는 멀쩡해도, 3일째부터 문제가 드러나는 경우가 있었습니다. 그래서 저는 최소 며칠은 돌려보면서 로그를 확인합니다. 🎉 이 과정을 통과하면 그때부터는 꽤 마음이 편해집니다.

    Frigate NVR 하드웨어 검증을 위한 대시보드와 시스템 리소스 모니터링 이미지

    카메라 상태, 이벤트 감지, CPU 사용률을 함께 확인하는 검증 단계의 대시보드 이미지입니다.

    7. 옵션별 판단 기준: 어떤 환경에 무엇이 맞을까요?

    정답은 한 가지가 아닙니다. 다만 사용 목적에 따라 우선순위는 분명히 갈립니다.

    환경 우선순위 추천 판단 기준
    카메라 1~2대 소형 홈랩 저전력, 저소음 서브 스트림 활용, SSD 중심 구성
    카메라 여러 대 상시 녹화 스토리지, 냉각 HDD 분리, 안정 전원, 네트워크 점검
    객체 감지 비중이 큰 환경 Coral AI Edge TPU 연결성과 컨테이너 인식 확인
    확장 예정이 있는 홈랩 여유 포트와 슬롯 저장장치 추가 가능성, USB/M.2 여유

    여기서 중요한 포인트! 지금 당장 카메라가 2대라고 해서 2대 기준으로만 짜면 나중에 꼭 후회하더라고요. 보안 카메라는 한 번 맛보면 주차장, 현관, 복도까지 늘어나기 쉽습니다. 저도 그랬습니다.

    8. 자주 묻는 질문과 마무리 체크

    • Q. Frigate는 무조건 Coral AI가 있어야 하나요?
      A. 꼭 그렇진 않습니다. 다만 객체 감지를 오래 안정적으로 돌릴 계획이면 Coral AI 같은 가속기가 체감상 도움이 큽니다.
    • Q. SSD만으로도 가능한가요?
      A. 가능합니다. 다만 장시간 녹화 보관이 목적이라면 저장 전략을 따로 설계하는 게 낫습니다.
    • Q. 보안 카메라는 어떤 점을 먼저 봐야 하나요?
      A. RTSP 지원, 스트림 분리 가능 여부, 코덱 호환성을 먼저 보시는 게 좋습니다.

    CPU, Coral AI, 스토리지, 네트워크, 냉각 요소를 한 장으로 정리한 요약 이미지입니다.

    정리해보면 Frigate NVR 하드웨어 선택의 핵심은 비싼 장비를 사는 게 아니라 병목이 생기는 지점을 먼저 이해하는 것입니다. CPU만 보지 마시고, Coral AI 같은 감지 가속기, 저장장치 역할 분리, 카메라 스트림 설계, 그리고 전원과 냉각까지 같이 보셔야 합니다. 제가 직접 해보니 이 순서로 접근하면 시행착오가 훨씬 줄었습니다.

    다음 글에서는 Frigate 설정 파일을 더 깊게 들어가서, 감지 구역(zone), 마스크(mask), 녹화 보관 정책을 어떻게 잡으면 좋은지 다뤄볼 예정입니다. 이전 글에서 홈랩 네트워크와 역방향 프록시(Reverse Proxy, 리버스 프록시) 구성 이야기를 보셨다면, 그 위에 얹는 방식으로 생각하시면 이해가 훨씬 쉬우실 겁니다. 홈랩 보안, 천천히 하나씩 쌓아가면 됩니다. 급하게 가면 꼭 다시 뜯게 되더라고요.