UniFi Protect 비용 vs DIY NVR, 오래 굴리면 뭐가 남을까

집이나 소규모 사무실에 카메라를 붙이기 시작하면 결국 UniFi Protect 비용 이야기를 피하기 어렵습니다. 처음엔 본체와 카메라 가격만 보게 되는데, 막상 운영에 들어가면 저장소, PoE 스위치, UPS, 원격 접속, 디스크 교체, 장애 대응 시간까지 전부 비용으로 돌아오거든요. 저도 홈랩에서 DIY NVR을 오래 굴려봤고, 반대로 관리 포인트가 적은 어플라이언스형 구성도 써봤는데, 오래 남는 차이는 감가상각보다 운영 피로도였습니다.

이번 글은 특정 브랜드를 밀려는 글이 아닙니다. 보안 카메라 시스템 비용을 왜 자꾸 잘못 계산하게 되는지, 그리고 홈랩 기준으로 어떤 선택이 덜 후회되는지 실무 관점으로 정리해 보려는 글입니다. UniFi Protect는 지원되는 UniFi Console과 전용 앱 경험을 중심으로 운영 복잡도를 줄이는 방식에 가깝고, DIY NVR은 Frigate, ZoneMinder, Shinobi 같은 조합으로 하드웨어 자유도를 얻는 대신 운영 책임을 직접 져야 합니다. 여기서는 최근 문서와 실제 구축 예시가 풍부한 Frigate 기준 DIY NVR을 예로 들겠습니다.

UniFi Protect 전용 콘솔 구조와 DIY NVR의 서버, 스토리지, PoE 스위치, 카메라 연결 흐름을 한눈에 보여주는 비교 아키텍처입니다.

UniFi Protect 비용 계산이 자꾸 틀어지는 이유

NVR은 한 번 설치하고 끝나는 가전이 아니라, 계속 쓰기 부하를 받는 기록 시스템입니다. 그래서 구매 시점에는 안 보이던 비용이 운영 3개월차쯤부터 슬슬 드러납니다. 특히 아래 네 가지를 빠뜨리면 계산이 거의 항상 틀어지더라고요.

• 전력과 발열: 24시간 켜 두는 시스템이라 전기요금보다 발열, 팬 소음, 먼지 축적, 쓰로틀링이 먼저 문제를 만드는 경우가 많습니다.
• 디스크 수명: 영상 저장은 읽기보다 쓰기가 훨씬 많습니다. 운영체제 디스크와 녹화 디스크를 섞어 두면 성능 문제와 장애 복구가 같이 옵니다.
• 장애 대응 시간: 로그를 읽고 원인을 좁히는 데 드는 시간이 실제 비용입니다. 홈랩에서는 이 항목이 숫자로 안 보여서 더 과소평가됩니다.
• 가족 사용성: 나만 보는 시스템이면 DIY의 불편함을 버틸 수 있어도, 가족이나 동료가 같이 쓰면 앱 품질과 재생 일관성이 바로 비용으로 체감됩니다.

이 지점에서 Protect와 DIY의 성격 차이가 또렷해집니다. Protect는 비용이 앞단에 몰려 있고, DIY는 비용이 뒷단에 퍼집니다. 전자는 지갑이 먼저 아프고, 후자는 시간이 먼저 아픕니다.

UniFi Protect vs DIY NVR, 개념부터 다릅니다

Protect는 용도 고정형 장비에 가깝고, DIY는 조합형 플랫폼에 가깝습니다. 이 차이는 단순 취향 문제가 아니라 장애 범위와 책임 소재를 바꿉니다.

UniFi Protect 쪽

Protect를 쓰면 콘솔, 저장소, 앱, 카메라 동작 방식이 한 생태계 안에서 맞물립니다. 게다가 현재는 ONVIF 호환 서드파티 카메라도 일부 연동할 수 있어서, 예전보다 선택 폭이 넓어졌습니다. 다만 고급 AI 기능은 UniFi 카메라나 별도 AI 액세서리 쪽이 더 유리한 편이라, 가장 매끄러운 경험은 여전히 UniFi 중심 구성에서 나옵니다.

이 구조의 장점은 분명합니다. 문제가 생겨도 의심해야 할 층이 적습니다. 저장소 상태가 안 좋은지, 콘솔이 과부하인지, 카메라 링크가 흔들리는지 정도로 범위를 좁히기 쉬워요. 다시 말해 비용의 예측 가능성이 높습니다. 장기 운영에서는 이게 생각보다 크게 느껴집니다.

DIY NVR 쪽

DIY는 RTSP나 ONVIF 기반 카메라를 섞어 쓸 수 있고, 이미 가지고 있는 미니 PC나 NAS, 서버를 재활용할 수 있습니다. 문제는 자유도만큼 변수도 늘어난다는 점입니다. 같은 “영상이 끊긴다”는 증상도 실제 원인은 제각각입니다. 카메라 서브스트림 미설정일 수도 있고, ffmpeg 재연결 루프일 수도 있고, 디스크 await 증가일 수도 있고, 하드웨어 디코딩이 빠져 CPU가 포화된 것일 수도 있습니다.

제 경험상 DIY NVR의 진짜 난점은 기능 부족이 아닙니다. 문제가 생겼을 때 어디부터 의심해야 하는지 초기에 감이 잘 안 잡힌다는 점이 더 큽니다. 이게 쌓이면 비용보다 피로도가 먼저 올라갑니다.

UniFi Protect 비용은 이렇게 나눠 봐야 덜 속습니다

UniFi Protect 비용을 제대로 보려면 초기 구매비만이 아니라 운영 구조까지 같이 봐야 합니다. 아래 표는 실제 비교할 때 꽤 유용한 프레임입니다. 가격표보다 나은 이유는, 어떤 항목이 장기 TCO를 밀어 올리는지 바로 보이기 때문입니다.

제가 실제로 후회했던 판단은 “일단 싸게 시작해 보고, 문제 생기면 고치자”는 접근이었습니다. NVR은 그렇게 가면 거의 항상 저장소와 알림 신뢰도에서 발목이 잡힙니다. 반대로 처음부터 완성형 장비를 샀는데 내가 결국 손대는 걸 즐기는 타입이라면, 그때는 Protect가 꽤 폐쇄적으로 느껴질 수도 있습니다. 결국 비용은 숫자만의 문제가 아니라 내가 어떤 문제를 즐기고, 어떤 문제를 싫어하는가의 문제이기도 합니다.

실전 구현: DIY NVR을 Frigate로 올릴 때 최소 구성

DIY를 비용 효율적으로 굴리려면 “싼 부품”보다 “역할 분리”가 더 중요합니다. 제가 최소 기준으로 보는 건 세 가지입니다. 첫째, 감지 스트림과 녹화 스트림을 분리할 것. 둘째, 운영체제 디스크와 녹화 데이터를 분리할 것. 셋째, 가능하면 하드웨어 디코딩을 붙일 것. 이 세 가지를 빼면 초기 절감 효과가 운영 중 병목으로 다시 청구됩니다.

아래 Compose 예시는 Frigate를 올릴 때 기본 뼈대로 쓰기 괜찮습니다. 최근 공식 가이드 기준으로 웹 UI 기본 포트는 8971이고, 하드웨어 가속 장치는 호스트 환경에 따라 /dev/dri/renderD128처럼 더 구체적으로 잡는 편이 안전합니다. 핵심은 /config와 /media/frigate를 분리하고, 임시 캐시와 녹화 저장소를 구분하는 데 있습니다.

1. 카메라에서 메인스트림과 서브스트림이 각각 살아 있는지 먼저 확인합니다.
2. 감지는 저해상도 서브스트림, 녹화는 메인스트림으로 분리합니다.
3. 녹화 볼륨은 OS가 설치된 디스크와 분리합니다.
4. 컨테이너가 재부팅 후 자동 복구되는지 먼저 확인한 다음 세부 튜닝으로 들어갑니다.

services:
  frigate:
    container_name: frigate
    image: ghcr.io/blakeblackshear/frigate:stable
    restart: unless-stopped
    stop_grace_period: 30s
    shm_size: "512mb"
    ports:
      - "8971:8971"
      - "8554:8554"
      - "8555:8555/tcp"
      - "8555:8555/udp"
    volumes:
      - ./frigate/config:/config
      - ./frigate/media:/media/frigate
      - type: tmpfs
        target: /tmp/cache
        tmpfs:
          size: 1000000000
      - /etc/localtime:/etc/localtime:ro
    devices:
      - /dev/dri/renderD128:/dev/dri/renderD128

컨테이너만 띄운다고 끝나지 않습니다. 실제 안정성은 설정 파일에서 갈립니다. 처음 구성할 때는 아래 네 가지를 꼭 봅니다. mqtt.enabled를 안 쓸 거면 명시적으로 끌 것, record.enabled를 켤 것, ffmpeg.hwaccel_args를 하드웨어에 맞출 것, 카메라 입력에 roles를 분리할 것. 특히 마지막은 성능 차이가 바로 납니다.

Frigate 컨테이너, RTSP 입력, 감지용 서브스트림, 녹화용 메인스트림, 스토리지 볼륨이 어떻게 연결되는지 보여주는 구성도입니다.

mqtt:
  enabled: false

ffmpeg:
  hwaccel_args: preset-vaapi

record:
  enabled: true

snapshots:
  enabled: true

cameras:
  front_door:
    ffmpeg:
      inputs:
        - path: rtsp://viewer:{FRIGATE_RTSP_PASSWORD}@192.168.10.20:554/cam/realmonitor?channel=1&subtype=2
          roles:
            - detect
        - path: rtsp://viewer:{FRIGATE_RTSP_PASSWORD}@192.168.10.20:554/cam/realmonitor?channel=1&subtype=0
          roles:
            - record
    detect:
      width: 1280
      height: 720
      fps: 5

이 구성이 중요한 이유는 간단합니다. 객체 감지는 높은 해상도보다 안정적인 프레임 공급이 더 중요하고, 녹화는 반대로 디테일 보존이 중요합니다. 둘을 한 스트림에 몰아넣으면 CPU와 I/O가 함께 흔들립니다. 저도 예전에 메인스트림 하나에 감지와 녹화를 같이 태웠다가, 겉으론 녹화가 되는데 이벤트 감지가 듬성듬성 빠지는 문제를 겪었습니다. 이거 처음엔 소프트웨어 버그처럼 보여서 더 헷갈리더라고요.

스트림이 제대로 열리는지 먼저 확인하고 싶을 때는 웹 UI보다 ffprobe가 빠릅니다. 아래처럼 카메라가 내보내는 영상 특성을 먼저 확인해 두면, 나중에 detect 해상도와 fps를 조정할 때 헛손질이 줄어듭니다.

ffprobe -hide_banner "rtsp://viewer:[email protected]:554/cam/realmonitor?channel=1&subtype=2"
ffprobe -hide_banner "rtsp://viewer:[email protected]:554/cam/realmonitor?channel=1&subtype=0"

UniFi Protect 비용을 안정적으로 만드는 요소

UniFi Protect 대안을 찾는 분들이 많지만, Protect가 반복해서 선택되는 이유는 기능 수보다 운영 구조에 있습니다.

• 원인 범위가 좁습니다: 장애 시 네트워크, 저장소, 콘솔 상태 중심으로 문제를 좁히기 쉽습니다.
• 앱 경험이 일정합니다: 타임라인 탐색과 원격 재생에서 사용자 교육 비용이 적습니다.
• 용량 계획이 단순합니다: 콘솔과 저장소를 중심으로 증설 판단을 하게 되니 sizing이 단순합니다.
• 운영 시간을 아낍니다: 로그를 덜 읽어도 되는 시스템은 생각보다 값어치를 크게 합니다.

물론 단점도 분명합니다. 기존 RTSP/ONVIF 카메라를 최대한 살리고 싶은 분에게는 여전히 제약이 느껴질 수 있고, 하드웨어 자유도도 좁습니다. 그러니 Protect는 기능 확장 플랫폼이라기보다 실패 확률을 낮추는 비용 구조라고 보는 편이 더 정확합니다. 홈랩 장난감으로 접근하면 비싸게 느껴지고, 생활 인프라로 보면 오히려 합리적으로 느껴지는 이유가 여기 있습니다.

⚠️ 실제로 자주 부딪히는 문제와 해결법

여기서는 제가 실제로 여러 번 본 시나리오를 하나 적어보겠습니다. 미니 PC에 Frigate를 올리고, 감지와 녹화를 동시에 켠 상태에서 처음 며칠은 멀쩡합니다. 그런데 시간이 지나면 알림이 늦고, 이벤트 썸네일이 비거나, 특정 시간대 재생이 버벅입니다. 이때 많은 분이 “컨테이너가 불안정하다”고 생각하시는데, 실제로는 아래 세 가지가 원인인 경우가 많습니다.

1. 서브스트림 미사용: detect가 과한 해상도를 먹으면서 디코딩 부하가 누적됩니다.
2. 저장소 혼용: OS와 녹화가 같은 디스크를 두드리면서 await가 길어집니다.
3. 하드웨어 가속 누락: CPU가 ffmpeg를 오래 끌고 가다가 재연결 빈도가 올라갑니다.

이 문제는 갑자기 터지기보다 서서히 드러납니다. 그래서 더 위험합니다. 타임라인은 열리는데 탐색이 늦고, 감지는 되는데 누락이 섞이고, 로그에는 가끔씩만 재연결이 찍히는 식이죠. 이런 상태가 바로 DIY NVR의 전형적인 성능 저하 패턴입니다.

1. 카메라에서 저해상도 서브스트림을 활성화합니다.
2. Frigate에서 detect는 서브스트림, record는 메인스트림으로 분리합니다.
3. 운영체제 디스크와 녹화 디스크를 분리합니다.
4. 가능하면 하드웨어 디코딩 경로를 노출합니다.
5. 증상이 보이면 로그만 보지 말고 디스크 지표를 먼저 확인합니다. 영상 시스템은 CPU보다 I/O가 먼저 병목 나는 경우가 꽤 많습니다.

운영 중에는 아래 명령어를 자주 씁니다. 이 네 개만 익숙해져도 “문제가 소프트웨어인지, 저장소인지, 카메라인지”를 꽤 빠르게 가를 수 있습니다.

docker compose up -d
docker logs frigate --tail 100
iostat -x 1
smartctl -a /dev/sdb

해석 기준도 같이 봐야 합니다.

• docker logs frigate --tail 100에서 ffmpeg 재연결 메시지가 반복되면, 컨테이너 자체보다 RTSP 품질이나 카메라 측 스트림 안정성을 먼저 의심하는 편이 맞습니다.
• iostat -x 1에서 특정 디스크의 await가 길게 유지되거나 %util이 계속 높으면 녹화 쓰기가 저장소를 막고 있을 수 있습니다.
• CPU가 높아도 바로 CPU 업그레이드로 가기보다, 먼저 detect 해상도와 fps를 낮추고 서브스트림 분리를 확인하는 게 순서입니다.
• smartctl -a에서 디스크 건강 경고나 재할당 섹터가 보이면 설정 튜닝보다 저장장치 교체가 먼저입니다.

한 가지 더 말씀드리면, DIY에서는 “로그가 조용하니 괜찮다”가 잘 안 통합니다. 로그는 조용한데 타임라인 체감 성능이 나빠지는 경우가 꽤 있어요. 그래서 저는 홈랩 NVR을 볼 때 항상 로그와 함께 재생 UX를 같이 봅니다. 사용자가 느끼는 품질은 로그보다 UI에서 먼저 무너질 때가 많습니다.

검증: 잘 돌아가는지 확인하는 기준

설치가 끝났다고 바로 성공은 아닙니다. 실제 운영에서 보면 아래 네 가지가 꽤 중요합니다. 이 네 항목이 안정적이면, 대체로 그 시스템은 한동안 손이 덜 갑니다.

CPU, 디스크 I/O, 녹화 보존 기간, 카메라 이벤트 타임라인을 함께 확인하는 운영 대시보드 예시입니다.

1. 녹화 보존 기간: 의도한 일수만큼 파일이 실제로 유지되는지 확인합니다.
2. 이벤트 탐색 속도: 특정 시간대로 이동할 때 UI가 버벅이지 않는지 봅니다.
3. 알림 신뢰도: 사람이 지나갈 때 누락이 없는지, 반대로 오탐이 과한지 봅니다.
4. 재부팅 복구력: 호스트 재시작 뒤 스트림과 녹화가 자동 복구되는지 꼭 확인합니다.

df -h /media/frigate
du -sh ./frigate/media
journalctl --since "1 hour ago" | grep -Ei "docker|frigate|i/o error"

여기서 df -h는 사용 가능한 공간을 보는 명령이고, du -sh는 실제 영상 데이터가 얼마나 쌓였는지 보는 명령입니다. 둘이 예상과 다르면 보존 정책이나 녹화 조건이 생각과 다르게 잡혀 있을 수 있습니다. journalctl에서 I/O error가 보이면 설정을 건드리기 전에 디스크, 케이블, 외장 스토리지 연결 상태부터 확인하는 편이 맞습니다.

제가 권하는 검증 루틴도 있습니다. 카메라 한 대만 붙인 상태에서 먼저 하루를 봅니다. 그다음 카메라 수를 늘리고, 마지막에 알림과 녹화를 같이 켭니다. 처음부터 모든 기능을 한 번에 켜면 병목 원인을 분리하기 어렵습니다. 이 절차는 Protect보다 DIY NVR에서 훨씬 중요합니다.

누구에게 어떤 선택이 맞을까

UniFi Protect 비용이 아깝지 않은 경우는 생각보다 분명합니다. 카메라 수가 늘어날 가능성이 있고, 가족이나 동료가 같이 쓰며, 장애가 났을 때 제가 직접 ffmpeg 로그를 들여다보고 싶지 않다면 Protect 쪽이 맞습니다. 특히 보안 카메라를 취미가 아니라 생활 인프라로 보는 분이라면, 예측 가능한 비용과 낮은 운영 스트레스가 장기적으로 이깁니다.

반대로 이미 괜찮은 서버가 있고, RTSP 카메라를 꼭 살리고 싶고, 로그 분석과 튜닝을 번거로움보다 재미로 느끼신다면 DIY NVR이 더 낫습니다. 다만 조건은 있습니다. 저장소 분리, 전원 안정성, 보존 정책, 하드웨어 디코딩까지 같이 설계할 준비가 되어 있어야 합니다. 오픈소스라서 공짜인 거지, 운영이 자동으로 쉬워지는 건 아니더라고요.

실제로 추천 기준은 아래처럼 단순합니다.

• 생활 인프라로 쓸 거면: Protect를 권합니다. 돈을 더 쓰더라도 시간을 덜 씁니다.
• 홈랩 실험이 목적이면: DIY가 맞습니다. 남는 장비를 잘 활용할 수 있고 배울 것도 많습니다.
• 기존 카메라를 반드시 살려야 하면: DIY가 더 현실적입니다.
• 가족 사용성과 앱 완성도가 중요하면: Protect가 덜 피곤합니다.
• 문제 해결 과정을 즐긴다면: DIY의 운영 공수 자체가 취미가 될 수 있습니다.
• 문제가 생기면 바로 복구돼야 한다면: Protect처럼 관리 포인트가 적은 구조가 낫습니다.

제 개인적인 판단을 한 줄로 줄이면 이렇습니다. DIY는 장비를 아끼는 방식이고, Protect는 시간을 아끼는 방식입니다. 둘 중 어느 쪽이 더 비싼지는 가격표보다 사용자의 성향이 더 크게 좌우합니다.

초기 장비, 운영 공수, 저장소, 확장성, 장애 대응 시간을 기준으로 두 방식을 요약 비교한 인포그래픽입니다.

짧은 FAQ

UniFi Protect 비용은 왜 체감상 높게 느껴질까요?

카메라만이 아니라 콘솔, 저장소, PoE, 운영 단순성까지 함께 사는 구조라서 그렇습니다. 대신 그 안에는 시행착오를 줄이는 값도 들어 있습니다.

DIY NVR이 무조건 싸진 않나요?

남는 장비가 있으면 시작은 저렴해 보일 수 있습니다. 하지만 디스크 교체, 장애 대응 시간, 전력, 저장소 병목 대응까지 넣으면 얘기가 꽤 달라집니다.

홈랩 NVR로 처음 시작할 때 가장 먼저 챙길 것은 뭔가요?

카메라를 많이 사기 전에 스트림 분리부터 하시는 게 좋습니다. 감지용 서브스트림과 녹화용 메인스트림을 나누는 것만으로도 안정성이 크게 달라집니다.

Protect와 DIY 중 하나를 고르기 애매하면 어떤 질문을 던져야 하나요?

“장애가 났을 때 제가 직접 만질 건가요, 아니면 바로 복구되길 원하나요?” 이 질문 하나로 방향이 꽤 명확해집니다. 전자면 DIY, 후자면 Protect가 더 잘 맞습니다.

참고 자료

• UniFi Protect 시작 가이드
• UniFi 저장소 요구사항
• UniFi Protect 카메라 수용 가이드
• UniFi Protect 서드파티 카메라 연동
• Frigate Getting Started
• Frigate Configuration

관련해서 다음 글에서는 홈랩 NVR의 저장소 보존 기간을 실제로 어떻게 계산하는지, 그리고 PoE 스위치와 VLAN 분리를 어디까지 해야 운영이 편해지는지 이어서 다뤄보겠습니다. 이 글과 함께 읽으면 비용 계산이 훨씬 또렷해집니다.