Frigate NVR 도입 사례: 홈랩 보안 카메라 설계 체크포인트

Frigate NVR를 검토하게 된 이유는 단순했습니다. 카메라를 몇 대만 붙여도 녹화는 되는데, 막상 필요한 장면을 찾는 시간이 너무 오래 걸리더라고요. 저도 처음엔 RTSP만 받아 저장하면 끝일 줄 알았는데, 실제 운영에선 이벤트 기준으로 좁혀보는 기능이 없으면 사람이 영상을 관리하는 시간이 훨씬 더 많이 들었습니다.

그래서 본격적으로 본 게 Frigate NVR였습니다. 오픈소스라는 점도 매력적이지만, 더 중요한 건 객체 감지 이벤트를 기준으로 녹화, 검색, 자동화를 한 흐름으로 묶기 쉽다는 점이었습니다. 다만 이건 설치형 앱보다는 운영형 시스템에 가깝습니다. 잘 맞는 환경에 넣으면 진짜 편한데, 안 맞는 환경에 억지로 올리면 전용 NVR보다 더 손이 갑니다.

이번 글은 기능 소개보다 도입 판단 기준에 초점을 맞췄습니다. 홈랩에서 제가 실제로 먼저 보는 항목, 어디서 병목이 생기는지, 어떤 구성은 오래 가고 어떤 구성은 금방 흔들리는지를 경험 중심으로 정리했습니다. Home Assistant 자동화나 홈랩 네트워크 설계를 함께 보고 계신다면, 이 글을 기준 글로 삼아 연결해서 읽어보셔도 좋습니다.

카메라, Frigate, MQTT, Home Assistant, 저장소가 어떻게 연결되는지 한눈에 보여주는 구성도입니다.

1. 왜 Frigate NVR를 보게 되었나

전용 NVR은 장점이 분명합니다. 설치가 빠르고 제조사 앱이 있고, 웬만하면 바로 녹화가 되니까요. 그런데 홈랩을 굴리다 보면 아쉬움이 생깁니다. 특정 브랜드에 종속되거나, 이벤트를 외부 시스템으로 자연스럽게 내보내기 어렵거나, 저장 정책이 내 운영 방식과 딱 안 맞는 경우가 생각보다 많습니다.

Frigate NVR를 보게 되는 분들은 보통 비슷한 지점에서 고민합니다. 영상 자체보다 영상에서 발생한 사건을 다루고 싶을 때죠. 사람이 지나갔는지, 차량이 들어왔는지, 특정 시간대에만 알림을 줄 건지, Home Assistant에서 조명이나 사이렌과 연결할 건지 같은 요구가 붙는 순간 전용 장비의 편의성보다 데이터 흐름의 유연성이 더 중요해집니다. 저도 딱 그 지점에서 Frigate가 훨씬 현실적으로 느껴졌습니다.

반대로 영상 보관만 안정적으로 되면 충분한 환경이라면 얘기가 달라집니다. 카메라 2~4대 정도에서 문제가 생기면 타임라인만 훑어보는 수준이라면 전용 NVR이 더 잘 맞을 수 있습니다. Frigate의 진짜 가치는 AI라는 단어 자체보다 운영 자동화와 검색 비용 절감에 있습니다. 이 축이 중요하지 않으면, 도입 난이도 대비 이익이 크지 않을 수 있습니다.

2. Frigate NVR 핵심 개념 쉽게 정리

처음 보면 기능이 많아 보여도, 실제로는 세 가지 흐름만 이해하면 됩니다. 입력 영상, 감지 파이프라인, 저장과 이벤트 소비 경로입니다. 이걸 한 번에 보면 복잡한데, 나눠 보면 의외로 단순합니다.

• 입력 영상: 카메라가 내보내는 메인 스트림과 서브 스트림입니다. 코덱, 해상도, 프레임레이트가 전체 시스템 성격을 거의 정합니다.
• 감지 파이프라인: Frigate가 FFmpeg로 스트림을 읽고, 감지용 프레임을 detector에 넘기고, 추적 결과를 이벤트로 묶는 흐름입니다.
• 이벤트 소비 경로: 녹화 저장, 스냅샷 생성, MQTT 발행, Home Assistant 자동화가 여기에 걸립니다.

실무적으로 중요한 건 Frigate가 얼마나 똑똑한가보다 어떤 입력을 어떤 비용으로 처리하게 만들었는가입니다. 저는 보통 카메라 설정 50, 저장소 30, Frigate 설정 20 정도 감각으로 봅니다. 숫자는 비유지만, 체감상 병목은 Frigate 바깥에서 먼저 시작되는 경우가 많았습니다. 특히 서브 스트림 없이 메인 스트림 하나로 detect와 record를 같이 처리하는 구성은 처음엔 쉬워 보여도 운영 피로도가 빨리 올라가더라고요.

어떤 환경에 특히 잘 맞나

3. Frigate NVR 설계에서 먼저 볼 것

처음 붙일 때 CPU와 메모리부터 보는 경우가 많은데, 제 경험상 우선순위는 조금 다릅니다. 먼저 봐야 할 건 스트림 분리 가능 여부, 카메라 코덱 설정, 저장소 분리, 네트워크 안정성입니다. 여기서 한 번 잘못 잡히면 Frigate 설정을 아무리 손봐도 운영이 쉽게 안정되지 않습니다.

1. 카메라가 메인 스트림과 서브 스트림을 따로 제공하는지 확인합니다.
2. 감지는 서브 스트림, 녹화는 메인 스트림으로 분리할 수 있는지 먼저 봅니다.
3. 카메라가 H.264처럼 브라우저와 환경에서 다루기 쉬운 코덱을 안정적으로 내보내는지 확인합니다.
4. 저장소를 OS 디스크와 분리할지, 최소한 미디어 경로를 분리할지 결정합니다.
5. Home Assistant 연동이 필요하면 MQTT 브로커 위치를 먼저 정합니다.
6. 원격 접근은 공개 포트 직결보다 VPN 또는 신뢰된 역방향 프록시 뒤에 둘지 결정합니다.

여기서 자주 나오는 실수가 두 가지 있습니다. 첫째, 감지에 고해상도 메인 스트림을 그대로 넣는 경우입니다. 이렇게 하면 detect 정확도가 무조건 좋아지는 게 아니라, 디코딩 비용과 지연만 커지는 경우가 더 많습니다. 둘째, 녹화까지 서브 스트림으로 처리하는 경우입니다. 이벤트는 잘 잡혀도 나중에 확인할 때 디테일이 부족해 아쉬움이 크게 남습니다.

결국 detect는 처리비용, record는 증거품질이라는 기준으로 따로 생각해야 합니다. 저도 예전에 현관 카메라 하나에 메인 스트림만 걸고 detect와 record를 동시에 맡겼다가 밤에 크게 돌아간 적이 있습니다. 낮에는 얼핏 괜찮았는데 밤이 되니까 UI 반응이 느려지고 감지 시점도 뒤로 밀리더라고요. 한참 Frigate 설정만 만졌는데, 실제 원인은 카메라 메인 스트림이 과했고 저장 디스크까지 같이 바빴던 거였습니다.

4. 실전 구현: Docker Compose로 Frigate 띄우기

홈랩에서는 컨테이너 기반 운영이 가장 다루기 편한 편입니다. 다만 compose 파일은 실행만 되는 예시보다, 왜 이렇게 두는지 설명되는 예시가 훨씬 중요합니다. 아래 예시는 현재 Frigate 공식 문서 흐름에 맞춘 최소 구성 기준으로 정리했습니다.

1) 디렉터리 준비

sudo mkdir -p /opt/frigate/config
sudo mkdir -p /srv/frigate/media
sudo mkdir -p /srv/frigate/db

# 권한 점검: 컨테이너가 읽고 쓸 수 있는지 먼저 확인
sudo chown -R $USER:$USER /opt/frigate /srv/frigate
ls -ld /opt/frigate/config /srv/frigate/media /srv/frigate/db

저는 설정 경로와 미디어 경로를 분리합니다. 백업 정책이 다르기 때문입니다. 설정과 DB는 보존 가치가 높고 용량은 작습니다. 반면 이벤트 클립과 녹화 파일은 금방 커집니다. 이 둘을 같은 디스크, 같은 백업 정책으로 묶어두면 나중에 운영이 꽤 지저분해집니다.

2) docker-compose.yml 예시

services:
  frigate:
    container_name: frigate
    image: ghcr.io/blakeblackshear/frigate:stable
    restart: unless-stopped
    stop_grace_period: 30s
    privileged: true
    shm_size: "512mb"
    ports:
      - "8971:8971"
      - "8554:8554"
      - "8555:8555/tcp"
      - "8555:8555/udp"
    environment:
      FRIGATE_RTSP_PASSWORD: "change-me"
    volumes:
      - /etc/localtime:/etc/localtime:ro
      - /opt/frigate/config:/config
      - /srv/frigate/media:/media/frigate
      - type: tmpfs
        target: /tmp/cache
        tmpfs:
          size: 1000000000

shm_size를 대충 두면 디코딩과 버퍼 처리에서 애매한 문제가 납니다. UI만 보면 감지 문제처럼 보일 수 있는데, 실제로는 프레임 버퍼가 부족한 경우도 많습니다. tmpfs를 쓰는 이유도 비슷합니다. 공식 문서 기준으로도 녹화 세그먼트 캐시는 메모리 기반 /tmp/cache를 권장합니다. 물론 메모리 여유가 없는 장비라면 여기 숫자를 무리해서 크게 잡을 필요는 없습니다.

하나 더 짚고 갈 부분이 있습니다. 최근 Frigate는 인증 UI와 API 접근에 8971 포트를 쓰는 구성을 기본으로 안내합니다. 5000 포트는 내부 네트워크용 비인증 접근으로 쓰는 흐름이라, 외부 노출 기준으로는 8971 쪽을 보는 게 더 안전합니다.

메인 스트림은 녹화, 서브 스트림은 객체 감지에 쓰는 구성을 시각화한 이미지입니다.

3) frigate 설정 파일 예시

mqtt:
  enabled: true
  host: 192.168.0.10
  port: 1883
  topic_prefix: frigate
  client_id: frigate

record:
  enabled: true
  motion:
    days: 3
  alerts:
    retain:
      days: 14
      mode: motion
  detections:
    retain:
      days: 14
      mode: active_objects

snapshots:
  enabled: true
  retain:
    default: 7

cameras:
  front_door:
    ffmpeg:
      inputs:
        - path: rtsp://user:{FRIGATE_RTSP_PASSWORD}@192.168.0.20:554/stream1
          roles:
            - record
        - path: rtsp://user:{FRIGATE_RTSP_PASSWORD}@192.168.0.20:554/stream2
          roles:
            - detect
    detect:
      enabled: true
      width: 1280
      height: 720
      fps: 5
    objects:
      track:
        - person
        - car
    snapshots:
      enabled: true
      bounding_box: true
      retain:
        default: 7

여기서 봐야 할 건 문법보다 의미입니다. roles가 잘못 연결되면 기록은 남는데 감지가 안 되거나, 감지는 되는데 녹화 품질이 이상해질 수 있습니다. 그리고 예전 글에서 자주 보이던 record.events 형태보다, 현재 문서 기준으로는 record.alerts와 record.detections 구조를 기준으로 보는 편이 맞습니다.

보존 기간도 처음부터 길게 잡지 않는 쪽을 권합니다. 파일 증가 속도를 먼저 확인하고 늘리는 게 훨씬 덜 피곤합니다. 특히 H.265는 저장 효율은 좋지만, 브라우저 호환성과 재생 환경을 같이 따져야 해서 홈랩이라면 초반엔 H.264 쪽이 더 다루기 편할 때가 많습니다.

4) 컨테이너 실행과 상태 확인

docker compose up -d
docker compose ps
docker logs --tail=200 frigate
docker logs -f frigate

설치 직후에는 에러 유무만 보지 말고, 어느 계층에서 끊기는지를 구분해서 봐야 합니다.

• 연결 실패: 인증 오류, RTSP 경로 오타, 카메라 동시 접속 제한을 먼저 봅니다.
• 디코딩 오류: 코덱 설정, 스트림 안정성, 공유 메모리 부족을 의심합니다.
• 반복 재시작: 설정 문법, 볼륨 권한, 경로 쓰기 실패를 우선 확인합니다.
• UI만 느림: 감지 엔진보다 디스크 I/O 또는 썸네일, 클립 생성 부하일 가능성이 큽니다.

RTSP 스트림 자체가 안정적인지는 Frigate 바깥에서 꼭 따로 확인하는 게 좋습니다. 이걸 생략하면 원인이 뭉개져 보일 때가 많더라고요.

ffprobe -hide_banner rtsp://user:[email protected]:554/stream1
ffprobe -hide_banner rtsp://user:[email protected]:554/stream2

이 단계에서 해상도, 코덱, 프레임 정보가 일관되지 않거나 접속이 들쑥날쑥하면, Frigate 이전 계층에서 이미 문제가 시작된 겁니다.

5. Frigate NVR와 Home Assistant 연동 포인트

Home Assistant 연동은 Frigate를 단순 NVR에서 운영 시스템으로 바꿔줍니다. 다만 실제로 중요한 건 연동 자체보다 어떤 이벤트를 어떤 문맥에서 쓸 것인가입니다. 기준 없이 다 알림으로 보내면 며칠 안 가서 사람이 알림을 무시하게 됩니다. 이거 진짜 금방 소음이 되더라고요.

제가 권하는 방식은 이벤트를 세 단계로 나누는 겁니다. 기록용, 대시보드용, 즉시 알림용입니다. 예를 들어 사람 감지는 전부 기록하되, 심야 시간대 person 이벤트만 알림으로 보내고, 차량은 대시보드 위주로 소비하는 식입니다. Frigate가 잘 잡는다고 해서 모든 이벤트 가치가 같은 건 아니니까요.

현재 기준으로는 Home Assistant의 공식 Frigate 통합을 우선 쓰는 편이 가장 깔끔합니다. 다만 MQTT 메시지 구조를 직접 확인하고 싶다면 아래처럼 먼저 브로커에서 실제 토픽을 보는 게 안전합니다.

mqtt:
  sensor:
    - name: "Front Door Person Active Count"
      state_topic: "frigate/front_door/person/active"
      icon: mdi:account-alert

수동 MQTT 센서를 쓸 수도 있지만, 먼저 실제 메시지가 올라오는지 눈으로 확인하는 게 더 중요합니다. 특히 frigate/front_door/person과 frigate/front_door/person/active는 의미가 다르기 때문에, 무턱대고 binary sensor로 고정하면 해석이 꼬일 수 있습니다.

mosquitto_sub -h 192.168.0.10 -t 'frigate/#' -v

# 특정 카메라 관련 이벤트만 좁혀보기
mosquitto_sub -h 192.168.0.10 -t 'frigate/front_door/#' -v

이 과정을 생략하면 Home Assistant 설정이 틀린 건지, MQTT가 안 오는 건지, Frigate가 이벤트를 못 만드는 건지 구분이 잘 안 됩니다. 저도 초반엔 HA 자동화가 문제인 줄 알고 붙잡고 있었는데, 실제론 Frigate 쪽 객체 추적 대상이 기대와 다르게 잡혀서 메시지가 아예 안 올라오던 적이 있었습니다.

객체 감지 이벤트가 센서와 알림으로 연결된 결과 예시를 보여주는 대시보드 이미지입니다.

6. 운영 중 자주 만나는 문제와 해결법

설치보다 운영이 더 어렵습니다. Frigate는 시작은 빠를 수 있어도, 오래 굴릴수록 문제의 성격이 달라집니다. 초반엔 설정 문법과 접속 오류가 많고, 조금 지나면 저장소, 네트워크, 카메라 품질 문제가 본격적으로 드러납니다. 아래는 제가 자주 본 실패 모드와 근본 원인입니다.

사례 1: 녹화는 되는데 감지가 들쑥날쑥한 경우

이 상황은 대개 Frigate 설정보다 입력 영상 품질 문제에서 시작합니다. 메인 스트림 하나에 detect와 record를 같이 물려두면 낮에는 버티다가 밤에 흔들리는 경우가 많습니다. 헤드라이트, IR 전환, 노이즈 억제, WDR 같은 카메라 내부 처리 영향이 생각보다 큽니다.

1. detect용 스트림을 서브 스트림으로 분리합니다.
2. 카메라의 WDR, 노이즈 억제, 야간 모드 전환 시점을 다시 봅니다.
3. 객체 종류를 너무 넓게 잡지 말고 필요한 클래스만 추적합니다.
4. 로그와 이벤트 시간을 비교해 지연이 감지 문제인지 디코딩 지연인지 구분합니다.

핵심은 Frigate를 더 만지기 전에 카메라를 먼저 의심하는 것입니다. 영상이 흔들리는데 감지만 더 똑똑해지길 기대하면 답이 잘 안 나옵니다.

사례 2: 디스크가 버벅이면서 UI까지 느려지는 경우

연속 녹화, 스냅샷, 이벤트 클립이 쌓이면 저장소 쓰기 패턴이 꽤 거칠어집니다. 특히 OS, 컨테이너 데이터, 미디어 파일을 같은 디스크에 몰아두면 녹화는 되는데 보는 순간 느린 상태가 나옵니다. 이건 CPU 부족처럼 보여도 실제론 I/O 대기인 경우가 많습니다.

iostat -x 1
df -h
du -sh /srv/frigate/media
find /srv/frigate/media -type f | wc -l

저는 여기서 %util, await, 파일 개수 증가 속도를 같이 봅니다. 이벤트가 몰릴 때만 순간적으로 튀는 건 자연스러울 수 있지만, 평시에도 디스크가 숨이 차 있으면 저장 정책을 먼저 줄여야 합니다. retain을 공격적으로 길게 잡는 것보다 실제 이벤트 밀도에 맞춰 보수적으로 시작하는 편이 훨씬 낫습니다.

사례 3: ffmpeg 관련 오류가 반복되는 경우

로그에 스트림 재연결이나 디코딩 오류가 반복될 때는 순서를 지켜서 봐야 합니다. Frigate 컨테이너만 재시작하는 건 보통 해결책이라기보다 증상 가리기에 가깝습니다.

1. 카메라 RTSP URL이 정확한지 다시 확인합니다.
2. 같은 스트림을 ffprobe로 직접 열어봅니다.
3. 카메라 코덱과 해상도 설정이 과하지 않은지 봅니다.
4. PoE 스위치, 케이블, 링크 상태를 포함한 네트워크 층을 확인합니다.

ffprobe rtsp://user:[email protected]:554/stream1
ping -c 20 192.168.0.20
docker logs --tail=200 frigate | grep -iE 'error|fail|ffmpeg|restart'

Frigate 문제처럼 보여도 원인이 카메라 펌웨어, 링크 품질, 전원 불안정인 경우가 꽤 많습니다. 저도 예전에 PoE 스위치 포트 상태가 애매해서 RTSP가 간헐적으로 끊기는 걸 한참 뒤에 찾았습니다. 이런 문제는 설정 파일만 만진다고 해결되지 않습니다.

사례 4: 알림은 오는데 정작 볼 만한 이벤트가 너무 많은 경우

이건 성능 이슈가 아니라 설계 이슈입니다. 시스템은 정상인데 사람이 못 쓰는 상태죠. 이벤트를 많이 잡는 것과 유용하게 잡는 건 다릅니다. 낮 시간 현관, 도로 변 카메라, 반사면이 많은 창가 카메라에서 특히 자주 생깁니다.

1. 알림용 이벤트와 기록용 이벤트를 분리합니다.
2. 밤 시간대, 특정 구역, 특정 객체만 알림 대상으로 좁힙니다.
3. Home Assistant에서 조건부 자동화를 먼저 걸고 Frigate는 과도하게 만지지 않습니다.

여기서 중요한 건 Frigate를 오탐 0% 도구로 기대하지 않는 겁니다. 운영자는 탐지 정확도보다 알림 가치 밀도를 높이는 쪽으로 설계하는 게 훨씬 현실적입니다.

7. 검증: 무엇을 보고 정상 동작으로 판단할까

정상 동작을 웹 UI가 뜬다로만 판단하면 결국 다시 손보게 됩니다. 최소한 이벤트 생성, MQTT 전달, 저장 정책, 재시작 복구, 조회 응답성까지 봐야 합니다. 저는 배포 직후와 카메라 추가 직후에 같은 체크리스트를 반복합니다.

• 이벤트 생성 흐름: 사람이 지나갈 때 이벤트, 스냅샷, 클립이 일관되게 남는지 봅니다.
• MQTT 전파: 이벤트가 브로커까지 실제로 전달되는지 확인합니다.
• 스토리지 적재: /media/frigate 아래 파일이 예상한 보존 정책대로 누적, 정리되는지 확인합니다.
• 재부팅 복구: 호스트 또는 컨테이너 재시작 후 자동으로 회복되는지 봅니다.
• UI 응답성: 이벤트 목록 조회와 최근 영상 접근이 과도하게 느리지 않은지 확인합니다.

검증할 때는 단순 모니터링보다 문제 분리용 명령이 필요합니다. 저는 아래 정도는 바로 돌려봅니다.

docker stats
ls -lah /srv/frigate/media
du -sh /srv/frigate/media
docker inspect frigate --format '{{.State.Status}}'
docker restart frigate
docker logs --since=2m frigate

여기서 중요한 건 숫자 자체보다 변화 시점입니다. 사람이 지나갈 때만 CPU가 오르는 건 자연스러울 수 있습니다. 하지만 평소에도 높게 유지되면 감지 대상이 과하거나 스트림 구성이 비효율적일 가능성이 큽니다. 디스크도 마찬가지입니다. 총 용량보다 하루에 얼마나 늘어나는지, 이벤트 밀도가 높은 날에 정리 정책이 제대로 작동하는지가 더 중요합니다.

이벤트 리스트, 클립 저장, 리소스 사용 상태를 함께 확인하는 운영 점검 이미지입니다.

8. Frigate NVR 도입 전에 꼭 따져볼 선택 기준

Frigate를 쓸지, 전용 NVR을 쓸지, 혼합 구성을 쓸지는 좋다 나쁘다로 고를 문제가 아닙니다. 운영 목표가 무엇인지에 따라 답이 달라집니다. 아래 표는 실제로 많이 받는 질문을 기준으로 정리한 것입니다.

제가 실무적으로 추천하는 기준은 단순합니다. 이벤트를 다른 시스템과 연결해 써야 하면 Frigate NVR, 영상 보관 자체가 목적이면 전용 NVR입니다. 그리고 이 둘을 혼합하는 것도 충분히 현실적인 선택입니다. 예를 들어 안정적인 연속 녹화는 전용 장비에 맡기고, 특정 카메라의 이벤트 자동화만 Frigate로 가져가는 구성도 꽤 괜찮습니다.

즉, Frigate는 제품 하나 설치해서 끝나는 장비라기보다 카메라 품질, 네트워크 안정성, 스토리지, 자동화 요구사항을 묶어 운영하는 플랫폼에 가깝습니다. 홈랩을 즐기는 분께는 이 유연성이 큰 장점이지만, 손이 덜 가는 보안 장비를 원한다면 장점이 곧 관리 포인트가 되기도 합니다.

9. 마무리: 이런 분께는 Frigate, 이런 분께는 다른 선택

제가 직접 굴려보며 얻은 판단은 꽤 선명합니다. 카메라 2~4대 규모에서 Home Assistant 연동, 객체 감지 기반 알림, 이벤트 검색이 핵심이라면 Frigate NVR 쪽이 잘 맞습니다. 이 경우에는 처음부터 detect와 record를 분리하고, 미디어 저장 경로를 OS와 분리하고, MQTT 이벤트를 먼저 검증하는 순서로 들어가면 시행착오를 많이 줄일 수 있습니다.

반대로 목표가 무조건 안정적으로 녹화하고 필요할 때 영상만 찾겠다는 쪽에 가깝다면 전용 NVR이나 제조사 클라우드 조합이 더 현실적입니다. 설정 파일 만지는 시간이 부담스럽고, 장애가 났을 때 로그를 따라가며 원인을 찾고 싶지 않다면 더더욱 그렇습니다. Frigate는 강력하지만, 공짜로 단순해지지는 않더라고요.

한 줄로 정리하면 이렇습니다. 이벤트를 시스템으로 쓰고 싶으면 Frigate, 영상을 장비로 보관하고 싶으면 전용 NVR이 더 낫습니다. 저는 홈랩이라면 전자를 권하지만, 전제는 분명합니다. 스트림 분리, 저장소 분리, 이벤트 설계까지 같이 볼 생각이 있을 때 이야기입니다.

바로 다음 단계로 넘어가실 분이라면, Frigate를 띄운 뒤 가장 먼저 할 일은 설정을 더 늘리는 게 아닙니다. 현관 카메라 하나만 붙여서 이벤트 생성, MQTT 전달, 디스크 증가 패턴, 재시작 복구까지 확인해보는 겁니다. 이 작은 파일럿을 통과하면 확장하면 되고, 여기서부터 흔들리면 카메라나 저장소 설계를 먼저 고치는 편이 훨씬 덜 돌아갑니다.

어떤 환경에서 Frigate가 맞고, 어떤 경우 전용 NVR이 더 나은지 한 장으로 정리한 요약 이미지입니다.