13년차의 서버실

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

[카테고리:] homelab

  • [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] Frigate NVR 도입 사례: 홈랩 보안 카메라 설계 체크포인트

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

    목차

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

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

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

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

    Frigate NVR 기반 홈랩 보안 카메라 전체 아키텍처 이미지

    카메라, 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를 같이 처리하는 구성은 처음엔 쉬워 보여도 운영 피로도가 빨리 올라가더라고요.

    어떤 환경에 특히 잘 맞나

    시나리오 Frigate 적합도 실무 판단
    Home Assistant 자동화 중심 홈랩 높음 이벤트를 MQTT, 대시보드, 알림, 조명 자동화로 자연스럽게 연결하기 좋습니다.
    그냥 녹화만 필요한 단순 환경 중간 이하 검색성과 자동화가 핵심 요구가 아니라면 전용 NVR이 구축과 운영 모두 단순합니다.
    여러 제조사 카메라 혼합 운영 높음 RTSP 기준으로 묶기 쉬워 벤더 종속을 줄이기 좋습니다.
    저전력 장비 한 대에 감지, 녹화, 자동화 몰아넣기 주의 CPU보다 디코딩, 디스크 I/O, 네트워크 품질, 하드웨어 가속 지원에서 먼저 무너질 가능성이 큽니다.
    보안 장비처럼 손 덜 대고 오래 굴리고 싶은 환경 낮음 업데이트, 로그 확인, 저장 정책 조정이 계속 필요할 수 있어 운영형 시스템에 가깝습니다.

    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 쪽을 보는 게 더 안전합니다.

    Frigate NVR에서 메인 스트림과 서브 스트림을 분리한 설정 이미지

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

    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 쪽 객체 추적 대상이 기대와 다르게 잡혀서 메시지가 아예 안 올라오던 적이 있었습니다.

    Home Assistant 연동으로 Frigate NVR 이벤트를 확인하는 대시보드 이미지

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

    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 또는 혼합 구성
    자동화가 중요한가 Home Assistant, MQTT, 조건부 알림까지 엮고 싶을 때 앱에서 보기만 하면 충분할 때
    설정보다 간편함이 중요한가 설정 파일과 로그 확인을 감수할 수 있을 때 초기 구축 시간을 짧게 가져가야 할 때
    카메라 제조사가 섞여 있는가 표준 스트림 기준 통합 운영이 필요할 때 한 브랜드로 통일돼 제조사 앱 완성도가 충분할 때
    저장소와 네트워크를 직접 관리할 자신이 있는가 스토리지, 백업, 접근제어까지 직접 설계할 때 운영 책임을 줄이고 싶을 때
    문제 해결 방식 로그와 계층별 점검으로 원인을 추적하는 데 익숙할 때 장비 교체 또는 벤더 지원 중심으로 해결하고 싶을 때

    제가 실무적으로 추천하는 기준은 단순합니다. 이벤트를 다른 시스템과 연결해 써야 하면 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 도입 판단 기준을 정리한 홈 보안 카메라 비교 이미지

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

  • [HomeLabs] OPNsense 마이그레이션: 홈 네트워크 업그레이드 전략

    [HomeLabs] OPNsense 마이그레이션: 홈 네트워크 업그레이드 전략

    목차

    OPNsense 마이그레이션으로 홈 네트워크 업그레이드하는 법

    OPNsense 마이그레이션을 고민하게 되는 순간은 단순히 인터넷 속도가 아쉬울 때가 아니었습니다. NAS 붙이고, 홈서버 돌리고, 외부 접속 열고, IoT를 분리하고 싶어지면 속도보다 구조가 먼저 병목이 되더라고요. 저도 처음엔 소비자 공유기 설정 화면에서 포트포워딩 몇 개만 더 열면 끝날 줄 알았는데, 어느 순간부터는 규칙보다 예외가 더 많아졌습니다. 그때부터 장비 교체가 아니라 네트워크 역할을 다시 나누는 쪽으로 생각이 바뀌었습니다.

    막상 해보면 핵심은 의외로 분명합니다. 라우팅, DHCP, DNS, 방화벽 책임을 어디에 둘지 다시 설계하는 일입니다. 만족도는 높지만 접근 순서가 틀리면 가족 와이파이부터 바로 영향을 받습니다. 그래서 이 글은 설치 후기가 아니라, 언제 넘어가야 하고 어디서 망가지며 어떻게 다운타임을 줄일지에 집중해 정리했습니다.

    특히 아래 조건에 가깝다면 비싼 소비자 공유기 업그레이드보다 OPNsense 마이그레이션이 더 잘 맞습니다.

    • 내부망을 메인 PC, 서버, IoT, 게스트로 나누고 싶다
    • 포트포워딩과 VPN을 함께 운영해야 한다
    • 문제가 생겼을 때 로그와 상태로 원인을 추적하고 싶다
    • 기존 공유기를 버리기보다 AP로 재활용하고 싶다

    기존 공유기 단일 구조와 OPNsense 중심 분리 구조를 한눈에 보여주는 개요 이미지입니다.

    왜 OPNsense 마이그레이션이 필요한가

    소비자 공유기는 기본값이 강합니다. 인터넷 연결, NAT, DHCP, 무선, 간단한 방화벽이 한 장비 안에서 돌아가고, 대부분은 그게 장점이죠. 반대로 OPNsense는 기본값보다 의도가 중요합니다. 어떤 세그먼트가 어떤 DNS를 쓰는지, 어떤 VLAN이 어디까지 접근 가능한지, 어떤 포트포워딩이 상위 NAT와 충돌하는지까지 사용자가 구조를 정해야 합니다.

    제가 판단 기준으로 삼는 차이는 기능 수가 아니라 정책의 수입니다. 네트워크를 지나는 트래픽에 예외가 계속 늘어난다면, 고급형 소비자 공유기로 버티는 것보다 OPNsense 쪽이 장기적으로 덜 피곤합니다. 반대로 인터넷, 스트리밍, 무선만 안정적이면 되는 집이라면 마이그레이션이 오히려 관리 부담이 될 수 있습니다.

    • OPNsense가 유리한 경우: VLAN 분리, 내부 DNS 이름해결, VPN, 포트포워딩, 트래픽 추적, 정책 기반 제어가 필요한 경우
    • 기존 공유기가 나은 경우: 무선 커버리지가 핵심이고, 외부 공개 서비스가 없고, 네트워크를 손댈 일이 거의 없는 경우
    • 애매한 경우: 라우팅만 OPNsense로 넘기고 무선은 기존 장비를 AP 모드로 유지하는 하이브리드 구성이 현실적입니다

    중요한 건, OPNsense는 단순히 더 강한 공유기가 아니라 장애 원인을 분해해서 볼 수 있게 해주는 플랫폼이라는 점입니다. 이 차이를 알고 들어가면 꽤 편합니다. 모르고 들어가면 초반 피로도가 확 올라갑니다.

    OPNsense 마이그레이션 전에 먼저 정리할 것들

    1. 현재 네트워크를 도식화하지 않으면 장애 시간이 길어집니다

    OPNsense로 넘어갈 때 흔한 실수는 새 기능에 신나서 기존 상태를 정확히 안 남기는 겁니다. 이 단계에서 필요한 건 멋진 설계도가 아니라 현재 인터넷이 왜 되는지 설명 가능한 상태입니다. 아래 항목은 최소한 적어두는 편이 좋습니다.

    • 회선 연결 방식: DHCP, PPPoE, 고정 IP
    • 현재 LAN 대역과 게이트웨이 주소
    • 고정 IP 장비: NAS, 프린터, 홈서버, NVR, 카메라
    • 외부 공개 포트와 실제 목적지 장비
    • DNS를 누가 맡고 있는지: 공유기, Pi-hole, NAS, 외부 DNS
    • 무선 AP가 라우팅까지 하는지, 순수 AP인지
    • 상위 장비가 모뎀인지, 모뎀 겸 공유기인지

    이걸 안 적어두면 나중에 “인터넷은 되는데 NAS 이름이 안 풀린다” 같은 문제에서 시간을 크게 잃습니다. 그 증상이 DNS 문제인지, DHCP 정적 매핑 누락인지, AP 뒤에 남아 있는 옛 서브넷 때문인지 바로 구분이 안 되거든요.

    2. 전부 교체하지 말고 역할만 먼저 분리하세요

    마이그레이션에서 가장 생산적인 판단은 “무엇을 새로 살까”보다 “누가 어떤 역할을 맡을까”입니다. 특히 홈 네트워크는 무선 품질 때문에 기존 공유기를 완전히 버리는 게 꼭 답은 아닙니다. 저는 보통 아래처럼 나눠서 봅니다.

    역할 기존 소비자 공유기 유지 OPNsense로 전환 권하는 기준
    라우팅/NAT 설정은 쉽지만 예외 처리가 약함 정책 기반 제어와 상태 추적 가능 포트포워딩, VLAN, VPN 중 2개 이상 필요하면 OPNsense
    무선 즉시 사용 가능, 관리 쉬움 별도 AP 필요 가능 무선 품질이 괜찮으면 기존 장비를 AP로 재활용
    DHCP/DNS 단순 환경에 적합 정적 매핑, 내부 이름해결, 접근제어에 유리 NAS나 홈서버를 이름으로 접근해야 하면 OPNsense 쪽
    방화벽 기본 허용/차단 수준 규칙 순서, 로그, 상태 기반 추적 가능 IoT 격리나 외부 공개 서비스가 있으면 OPNsense
    장애 분석 원인 추적이 어려움 pf 상태, NAT 규칙, 라이브 로그 확인 가능 문제 원인을 직접 좁혀가고 싶다면 OPNsense
    운영 난이도 낮음 초기 설계와 검증 필요 네트워크를 거의 손대지 않을 집이면 굳이 안 옮겨도 됨

    핵심은 간단합니다. 무선은 유지해도 되고, 라우팅은 분리하는 게 맞습니다. 이 경계만 잘 그어도 전환 난이도가 확 내려갑니다.

    OPNsense 마이그레이션 전략: 한 번에 갈아엎지 마세요

    집 네트워크는 사무실보다 장애 허용도가 낮습니다. 서버가 잠깐 죽는 건 참아도 TV와 휴대폰 와이파이가 안 되면 바로 티가 납니다. 그래서 저는 병행 전환만 권합니다. 기존 공유기를 빼고 새 장비를 바로 올리는 방식은, 장애가 생겼을 때 비교 기준 자체가 사라집니다.

    1. OPNsense 장비 준비: 최소 2개 NIC가 있는 x86 장비를 준비합니다.
    2. 분리된 테스트 환경에서 먼저 부팅: WAN에는 회선 또는 상위 장비, LAN에는 테스트 PC 1대만 붙입니다.
    3. 기본 인터넷과 관리 UI 확인: WAN 주소, 기본 게이트웨이, LAN DHCP, 웹 UI 접근부터 검증합니다.
    4. 기존 공유기는 AP 모드로 전환: DHCP와 NAT는 끄고 무선만 맡깁니다.
    5. 고정 IP와 포트포워딩 이전: NAS, 홈서버처럼 영향 큰 장비부터 옮깁니다.
    6. VLAN과 세부 정책은 마지막: 기본 LAN이 멀쩡하다는 게 확인된 뒤에 분리 정책을 얹습니다.

    여기서 순서를 뒤집으면 대부분 꼬입니다. 특히 초반부터 VLAN, DNS 오버라이드, VPN, IDS/IPS까지 한 번에 켜는 건 추천하지 않습니다. 문제는 기능이 많아서가 아니라, 증상이 서로 비슷하게 보이기 때문입니다. DNS ACL 문제, VLAN 태깅 오류, AP의 잔존 DHCP는 전부 “어떤 기기만 인터넷이 안 됨”으로 보일 수 있습니다.

    실전 구현: 최소 다운타임으로 옮기는 순서

    1. 기존 공유기 설정 백업과 현재 상태 점검

    백업 파일만 믿지 말고, 클라이언트 기준 상태도 남겨두세요. 전환 후 비교할 때 훨씬 빠릅니다. 코드 블록은 설정을 바꾸는 용도가 아니라, 현재 상태를 기록하고 전환 전후를 비교하는 용도입니다.

    # Linux 클라이언트 기준: 전환 전 상태 저장
ip addr
ip route
cat /etc/resolv.conf
arp -an

# 전환 후 비교용
ping -c 4 1.1.1.1
ping -c 4 google.com
traceroute 1.1.1.1

    해석 포인트는 단순합니다. 숫자 IP는 되는데 도메인이 안 되면 DNS를 먼저 봅니다. 첫 홉이 새 OPNsense LAN 주소가 아니면 클라이언트가 아직 예전 게이트웨이를 보고 있는 겁니다. 이 단계에서 이미 문제를 절반은 줄일 수 있습니다.

    2. 전환 후 검증용 테스트 세트는 서비스별로 준비하세요

    제가 실제로 쓰는 검증 기준은 단순 인터넷 연결이 아닙니다. 외부 IP, 외부 DNS, 내부 DNS, 내부 서비스, 외부 진입을 구분해서 봅니다. 그래야 어디가 깨졌는지 바로 분류됩니다.

    # 외부 IP / 외부 DNS / 내부 이름해결을 한 번에 점검
for host in 1.1.1.1 google.com nas.home.arpa; do
  echo "== $host =="
  ping -c 2 "$host"
done

# TCP 서비스 확인 예시
nc -vz nas.home.arpa 445
nc -vz opnsense.lan 443

    여기서는 내부 로컬 이름을 일부러 넣는 편이 좋습니다. OPNsense로 옮긴 뒤 가장 늦게 발견되는 문제가 바로 내부 DNS 등록 누락이기 때문입니다. 인터넷은 되는데 NAS 이름만 안 풀리면 사용자 입장에선 거의 망가진 것처럼 느껴집니다.

    3. OPNsense 초기 설정은 기본값을 존중하되 자동 마법에 기대진 마세요

    설치 직후엔 욕심내서 꾸미지 말고 아래 순서만 확인합니다.

    1. WAN 인터페이스에 회선 연결
    2. LAN 인터페이스에 테스트 PC 연결
    3. LAN 대역 지정
    4. DHCP 서버 활성화
    5. 웹 UI 접근 확인
    6. 외부 IP와 도메인 해석 확인

    이 시점에서 특히 중요한 건 DNS입니다. OPNsense는 기본 설치에서 Unbound DNS가 기본 리졸버로 활성화되는 구성이 일반적입니다. 내부 이름해결까지 생각하면 Services > Unbound DNS에서 아래 항목을 먼저 확인해 두는 편이 좋습니다.

    • Register ISC DHCP4 Leases: ISC DHCP를 쓰는 경우, DHCP 호스트명을 Unbound에 반영
    • Register DHCP Static Mappings: 정적 매핑 이름을 내부 DNS에 반영
    • Access Lists: 클라이언트 네트워크가 리졸버에 질의할 수 있는지 확인
    • Network Interfaces / Outgoing Interfaces: 특별한 이유가 없으면 수동 지정보다 기본값을 유지

    다만 여기에는 중요한 예외가 있습니다. Kea DHCP를 쓰는 경우에는 ISC DHCP처럼 동적 임대 호스트명이 바로 Unbound에 자동 등록되지 않습니다. 그래서 초반에는 정적 매핑과 내부 도메인 정책부터 먼저 맞추는 쪽이 더 안전합니다. 실제로 OPNsense 초반 장애는 방화벽보다 DNS에서 많이 나더라고요.

    OPNsense 마이그레이션 실전 구성과 VLAN 네트워크 구성 다이어그램

    인터넷 회선, OPNsense, 스위치, AP, 서버, IoT 네트워크가 어떻게 분리되는지 보여주는 구성 이미지입니다.

    4. AP 모드 전환은 체크박스가 아니라 이중 라우팅 제거 작업입니다

    기존 소비자 공유기를 AP로 재활용할 때는 아래 네 가지를 꼭 확인합니다.

    • DHCP 비활성화: 주소를 두 군데서 주면 클라이언트가 서브넷을 섞어 받습니다.
    • NAT 비활성화: 이중 NAT가 남으면 외부 진입과 VPN이 꼬입니다.
    • LAN 포트 uplink: 상위 연결은 보통 WAN이 아니라 LAN 포트로 넣습니다.
    • 관리 IP 고정: AP 관리 주소를 새 대역 안의 고정 IP로 잡아둡니다.

    여기서 자주 나오는 사고 시나리오가 있습니다. AP라고 해놨는데 라우터 기능이 일부 남아 있어서 휴대폰은 새 대역을 받고 TV는 옛 대역을 받는 식입니다. 겉으로 보면 무선 문제 같지만, 근본 원인은 DHCP 서버가 둘인 경우가 많습니다.

    5. VLAN은 기능이 아니라 운영 규칙입니다

    VLAN을 넣는 순간 네트워크는 깔끔해지지만 동시에 추적 포인트도 늘어납니다. 그래서 저는 기본 LAN이 완전히 안정된 다음에만 넣습니다. 그리고 VLAN ID보다 먼저 접근 정책 문장을 적어둡니다. 예를 들면 이런 식입니다.

    • 메인 LAN은 서버 VLAN과 관리 IP에 접근 가능
    • IoT VLAN은 인터넷만 가능, 메인 LAN과 서버 VLAN은 차단
    • 게스트 VLAN은 내부망 전체 차단, 인터넷만 허용
    • 관리용 네트워크는 OPNsense UI와 스위치/AP 관리 IP 접근 허용

    이 문장이 먼저 없으면 VLAN은 분리가 아니라 혼란이 됩니다. 태깅이 맞아도 방화벽 규칙이 애매하면 결국 운영자가 더 헷갈립니다. 홈랩에서 가장 위험한 상태는 “분리했다고 믿지만 실제로는 접근이 열려 있는 상태”입니다.

    OPNsense 마이그레이션 중 설정과 검증에 바로 쓰는 명령어

    웹 UI만으로도 운영은 되지만, 마이그레이션 시점에는 셸에서 현재 상태를 보는 편이 빠릅니다. 아래 명령은 설정을 바꾸는 게 아니라 관찰용이라 부담이 적고, 어디서 막히는지 가닥을 잡는 데 꽤 유용합니다.

    # OPNsense 셸에서 현재 상태 빠르게 확인
ifconfig
netstat -rn
sockstat -4 -6 -l | egrep ':(53|67|80|443)\b'
pfctl -sr
pfctl -s nat
pfctl -ss

    제가 보는 포인트는 이렇습니다.

    • <code>netstat -rn: 기본 경로가 WAN 쪽으로 제대로 잡혔는지
    • sockstat: DNS(53), DHCP(67), 웹 UI(80/443) 같은 핵심 서비스가 실제로 리슨 중인지
    • pfctl -sr: 필터 규칙이 생각한 순서대로 로드됐는지
    • pfctl -s nat: 포트포워딩과 아웃바운드 NAT가 실제로 반영됐는지
    • pfctl -ss: 연결 상태가 생기고 있는지 확인할 수 있는지

    포트포워딩이나 NAT reflection 관련해서는 pfctl -s nat가 특히 유용합니다. GUI에 규칙이 있어 보여도 적용 버튼을 놓친 경우, 셸에서 활성 NAT 규칙을 보면 바로 티가 납니다.

    # 외부 진입 문제를 볼 때 최소 확인 세트
pfctl -s nat
pfctl -ss | egrep '(:80|:443|:51820|:22)'
tcpdump -ni <wan_if> host <public_or_remote_ip>
tcpdump -ni <lan_if> host <internal_server_ip>

    이 블록은 트래픽 흐름을 좁혀보는 용도입니다. 패킷이 WAN에는 들어오는데 LAN으로 안 넘겨지면 NAT나 필터 규칙 문제를 먼저 의심합니다. WAN과 LAN 양쪽에 SYN이 보이는데 서버에서 SYN/ACK가 안 나오면, 그땐 서버 방화벽이나 서버 기본 게이트웨이를 먼저 보는 쪽이 맞습니다.

    트러블슈팅: OPNsense 마이그레이션에서 자주 막히는 지점들

    관리 UI는 열리는데 인터넷이 안 될 때

    이건 단순히 인터넷 불가라고 뭉뚱그리면 안 됩니다. OPNsense UI가 열리면 최소한 LAN, DHCP, 웹 UI는 살아 있다는 뜻입니다. 따라서 문제는 대개 WAN, 기본 경로, DNS 중 하나로 좁혀집니다.

    증상 가장 흔한 근본 원인 우선 확인할 항목 제가 보통 내리는 판단
    숫자 IP는 되는데 도메인이 안 됨 Unbound 설정, ACL, 상위 DNS 경로 문제 Unbound 활성화, Access Lists, 클라이언트 DNS 주소 방화벽보다 DNS 가능성이 높음
    어느 사이트도 안 열림 WAN 주소 미할당, 기본 게이트웨이 불량 WAN 상태, netstat -rn, 상위 장비 연결 방식 회선 인증 또는 상위 장비 문제부터 봄
    일부 기기만 안 됨 중복 DHCP, 예전 임대 정보, AP 오구성 클라이언트 IP 대역, 게이트웨이, DNS 서버 주소 라우팅보다 DHCP 서버 충돌을 먼저 의심
    내부 이름만 안 풀림 정적 매핑 미등록, DHCP 이름 등록 미반영 Register DHCP Static Mappings, Host Override, DHCP 백엔드 종류 인터넷은 정상, 내부 DNS 설계 문제

    제가 실제로 자주 본 케이스는 인터넷은 되는데 nas.home.arpa 같은 내부 이름만 안 풀리는 경우입니다. 이건 사용자 입장에선 반쯤 망가진 상태에 가깝습니다. 그런데 운영자가 이걸 가볍게 넘기면 이후 백업, 미디어 서버, 프린터 검색이 줄줄이 꼬입니다.

    포트포워딩이 안 먹을 때

    이쪽은 놀랄 만큼 자주 상위 NAT가 원인입니다. OPNsense WAN에 공인 IP가 아니라 사설 IP가 붙어 있다면, 그 위에 이미 모뎀 겸 공유기나 ISP 장비가 라우팅을 하고 있을 가능성이 큽니다. 이 상태에서 OPNsense에만 포워딩을 만들면 외부에서 안 들어옵니다.

    • 우선 확인: OPNsense WAN IP가 사설 대역인지 공인 IP인지
    • 다음 확인: 상위 장비가 브리지 모드인지, 아니면 별도 포워딩이 필요한지
    • 셸 확인: pfctl -s nat로 실제 로드된 NAT 규칙 확인
    • 로그 확인: 라이브 로그에서 생성한 규칙 라벨이 매치되는지 확인

    여기서 또 하나 많이 헷갈리는 게 헤어핀 NAT입니다. 집 안에서 공인 도메인으로 자기 서버에 접속하려는 경우죠. 외부에서는 되는데 내부에서는 안 되면, 서버가 죽은 게 아니라 NAT reflection이나 split DNS 설계 문제일 수 있습니다. 저는 reflection을 무조건 기본값처럼 기대하기보다, 내부에서는 내부 이름으로 접근하게 DNS를 정리하는 쪽이 더 편하더라고요.

    특정 기기만 이상하게 느릴 때

    이 부분은 네트워크 글에서 제일 뭉뚱그려 설명되지만 실제 원인은 몇 갈래로 나뉩니다.

    • 예전 DHCP 임대 정보: 새 게이트웨이 반영이 늦는 기기가 있습니다
    • MTU/MSS 문제: PPPoE나 특정 상위 장비 환경에서 일부 서비스만 유독 느릴 수 있습니다
    • DNS 재바인딩 보호나 로컬 DNS 충돌: 특정 내부 웹 UI 접속이 꼬일 수 있습니다
    • Wi-Fi 자체 문제: 라우팅이 아니라 무선 로밍이나 채널 혼잡일 수 있습니다

    여기서 중요한 건, 모든 느림을 OPNsense 탓으로 돌리면 안 된다는 점입니다. 실제로는 OPNsense로 옮긴 뒤 네트워크가 더 잘 보이기 때문에 원래 있던 무선 문제를 이제서야 발견하는 경우도 많습니다. 특정 기기만 느리면 저는 먼저 그 기기의 IP, 게이트웨이, DNS를 보고 그다음에 무선 연결 위치와 AP를 확인합니다.

    OPNsense 마이그레이션 트러블슈팅과 방화벽 구축 점검 장면

    관리 화면에서 규칙과 상태 정보를 확인하며 문제를 좁혀가는 과정의 이미지입니다.

    검증: OPNsense 마이그레이션이 끝났는지 판단하는 기준

    저는 웹 한 번 열렸다고 완료 판정하지 않습니다. 아래 체크리스트를 전부 통과해야 실제 전환 완료로 봅니다.

    1. 유선 클라이언트가 의도한 DHCP 범위에서 새 IP를 받는다
    2. 기본 게이트웨이가 OPNsense LAN 주소로 잡힌다
    3. 외부 IP 통신과 외부 DNS 조회가 모두 정상이다
    4. 내부 서비스(NAS, 프린터, 홈서버)가 IP와 이름 둘 다로 접근된다
    5. 포트포워딩 또는 VPN 진입이 의도한 서비스에만 열린다
    6. IoT와 게스트망이 메인 LAN이나 서버망에 임의 접근하지 못한다
    7. AP 관리 IP, 스위치 관리 IP 같은 운영 경로가 끊기지 않는다

    이 단계에서 저는 일부러 실패 테스트도 합니다. 예를 들어 IoT VLAN에서 NAS 관리 포트 접속을 시도해 보고, 막혀야 정상인지 확인하는 식입니다. 허용 테스트만 하면 분리 정책은 검증되지 않습니다.

    # 클라이언트 검증 예시
ip route
ping -c 2 1.1.1.1
ping -c 2 google.com
ping -c 2 nas.home.arpa
nc -vz nas.home.arpa 445
nc -vz opnsense.lan 443

    그리고 OPNsense 쪽에서는 규칙이 실제로 상태를 만들고 있는지 봅니다. 규칙 설명을 사람이 읽을 수 있게 써두면 라이브 로그와 상태 추적에서 시간이 꽤 절약됩니다. 이거 진짜 편하더라고요.

    OPNsense 마이그레이션 완료 후 홈 네트워크 업그레이드 결과 이미지

    게이트웨이 정상, DHCP 분배 정상, 세그먼트 분리가 완료된 상태를 시각적으로 보여주는 결과 이미지입니다.

    운영 팁: OPNsense 마이그레이션 직후 바로 해두면 편한 것

    • 구성 백업: 포트포워딩, VLAN, DHCP 정적 매핑을 바꿀 때마다 설정 백업을 남기세요.
    • 관리 문서 분리: VLAN ID, 서브넷, 게이트웨이, DHCP 범위, 고정 IP, AP 관리 주소를 표로 남기세요.
    • 규칙 이름 정리: “allow any” 같은 이름보다 목적이 드러나는 설명을 쓰세요.
    • 변경 단위 축소: DHCP를 바꾼 날에는 DNS까지 같이 손대지 않는 편이 좋습니다.
    • 내부 DNS 우선: 포트포워딩보다 먼저 내부 이름해결을 안정화하세요.

    추가로 홈랩에서는 성능보다도 되돌리기 쉬운 구조가 중요합니다. VLAN을 멋지게 쪼개는 것보다, 문제가 생겼을 때 10분 안에 원인을 좁힐 수 있는 구성이 더 낫습니다. 저는 그래서 초기에 자동 생성 규칙에 과하게 기대기보다, 나중에 봐도 이해되는 명시적 규칙을 선호합니다.

    이전 글에서 스위치 포트 태깅과 AP SSID 분리까지 정리해두셨다면 그 글도 함께 보세요. OPNsense만 제대로 세팅해도 네트워크가 자동으로 정리되진 않거든요. 병목은 늘 경계면에서 생깁니다. 방화벽과 AP 사이, DHCP와 DNS 사이, 상위 모뎀과 WAN 사이에서요.

    FAQ와 최종 권고

    소비자 공유기를 완전히 버려야 하나요?

    그럴 필요 없습니다. 무선 품질이 괜찮다면 AP로 계속 쓰는 게 가장 현실적입니다. 다만 라우팅, NAT, DHCP는 한 곳으로 모아야 합니다. 저는 보통 그 역할을 OPNsense에 몰아주는 쪽을 권합니다.

    작은 집 네트워크에도 필요할까요?

    기기 수가 적고 외부 공개 서비스도 없고 분리할 네트워크도 없다면 굳이 필요 없습니다. OPNsense는 만능 업그레이드라기보다 정책이 늘어난 환경을 위한 도구에 가깝습니다.

    어떤 경우에 특히 추천하나요?

    NAS, 홈서버, 원격 접속, IoT 분리, 포트포워딩 운영이 동시에 들어간다면 추천합니다. 반대로 와이파이만 안정적이면 된다면 기존 공유기를 유지하거나 좋은 AP를 추가하는 쪽이 더 낫습니다.

    제가 실제 운영 기준으로 내리는 결론은 명확합니다. 외부 공개 서비스가 있거나, 내부망을 둘 이상으로 나눠야 하거나, 장애 원인을 직접 추적해야 한다면 OPNsense로 가는 편이 맞습니다. 이 경우 소비자 공유기 업그레이드는 대개 임시 연장선에 그칩니다. 반대로 네트워크를 설계할 생각이 없고 관리 포인트를 늘리고 싶지 않다면 기존 공유기를 유지하세요. 그 편이 운영 품질이 더 높습니다.

    즉, 선택 기준은 장비 성능이 아니라 내가 감당해야 할 정책의 복잡도입니다. 그 복잡도가 이미 공유기 UI를 넘었다면, OPNsense 마이그레이션은 꽤 만족도 높은 홈 네트워크 업그레이드가 됩니다. 아직 그 단계가 아니라면 AP 재배치나 무선 분리만으로도 충분할 수 있습니다.

    소비자 공유기 대체와 OPNsense 선택 기준 요약 인포그래픽

    어떤 환경에서 기존 공유기를 유지하고, 어떤 경우 OPNsense로 넘어가면 좋은지 정리한 요약 이미지입니다.

  • [HomeLabs] Tailscale 가격 분석: 홈랩·소규모 비즈니스 비용 전략

    [HomeLabs] Tailscale 가격 분석: 홈랩·소규모 비즈니스 비용 전략

    목차

    Tailscale 가격 분석: 홈랩·소규모 비즈니스 비용 전략

    Tailscale 가격을 볼 때 가장 많이 헷갈리는 지점은 하나더라고요. 핵심은 “기기 수가 많으면 비싸지는가”가 아니라, “누가 seat를 점유하고 어떤 인프라를 tagged resource로 운영하느냐”입니다. 홈랩에선 거의 무료처럼 느껴지지만, 팀 계정·서브넷 라우터·exit node·CI 러너가 붙는 순간 계산 기준이 확 달라집니다. 이 글은 2026년 8월 28일 기준 Tailscale 공식 가격 페이지와 공식 문서를 바탕으로, 실제 설계할 때 먼저 보는 비용 포인트만 골라 다시 정리한 내용입니다.

    제 기준은 단순합니다. 사람 비용은 seat, 인프라 비용은 tagged resource, 변동성 비용은 ephemeral minutes로 나눠서 보는 거예요. 이렇게 분리하면 플랜 선택이 꽤 선명해집니다. 반대로 한데 섞어 보면 “무료로 되겠지” 하고 시작했다가 월말에 권한 설계와 청구 기준이 같이 꼬이기 쉽습니다. 특히 소규모 비즈니스 VPN은 구독료보다 권한 설계 실수와 seat 정리 실패가 더 비싸게 돌아오는 경우가 많습니다.

    홈랩 장비, 사용자 좌석(seat), tagged resources, exit node 구성을 한 장으로 요약한 개요 이미지입니다.

    Tailscale 가격 구조, 실제 청구 기준으로 보면 이렇게 읽힙니다

    현재 공식 요금제 기준으로 신규 가입 tailnet은 seat-based pricing을 따릅니다. 사용자 노트북이나 폰이 여러 대여도, 그 사람은 보통 seat 하나를 점유합니다. 반대로 서버, 서브넷 라우터, app connector, exit node처럼 사람이 아니라 tag가 소유하는 장비는 tagged resource로 계산합니다. 다만 여기서 한 가지는 꼭 짚고 가야 합니다. 일부 기존 legacy tailnet은 예전 월간 활성 사용자 방식이 남아 있을 수 있어서, 이미 오래 운영 중인 계정이라면 현재 플랜 체계를 먼저 확인하는 편이 안전합니다.

    실무에서 특히 중요한 건 seat가 실제로 tailnet에 참여한 사용자 기준으로 소비된다는 점입니다. 초대만 해둔 사용자는 seat를 점유하지 않고, 처음 로그인하거나 처음 장비를 붙일 때 seat를 차지합니다. 공식 FAQ 기준으로 seat는 재사용 가능하지만, 월중에 seat를 줄여도 그달 비용이 바로 내려가지는 않습니다. 반대로 seat를 추가하면 일할 계산이 붙습니다. 이 부분, 월말 정산 때 꽤 체감되더라고요.

    • User device: 사람 계정에 귀속된 노트북, 폰, 워크스테이션 같은 일반 단말입니다. 수량 자체는 과금 기준이 아닙니다.
    • Seat: tailnet에 참여한 사용자가 차지하는 청구 단위입니다. 비용 최적화의 첫 번째 축입니다.
    • Tagged resource: tag가 소유하는 서버, subnet router, exit node, app connector 같은 공유 인프라입니다. 기본 50개가 포함되고, 추가분은 개당 월 1달러입니다.
    • Ephemeral resource: 짧게 뜨고 사라지는 CI/CD 러너, 쿠버네티스 워크로드 같은 장비입니다. 분 단위 풀을 쓰고, tailnet에 4시간 이상 남아 있으면 일반 tagged resource로 계산됩니다.

    Tailscale 가격 비교: 플랜표만 보면 놓치기 쉬운 판단 포인트

    플랜 공식 가격 사용자 ACL Groups Ephemeral resources 제가 보는 적합한 상황
    Personal $0 최대 6명 최대 3개 월 1,000분 비상업용 홈랩, 개인 장비 연결, 가족 단위 원격 접속
    Standard 사용자당 월 $8 무제한 최대 10개 월 1,000분 작은 팀, 업무용 계정 운영, SCIM/MDM, 역할 분리 시작점
    Premium 사용자당 월 $18 무제한 최대 300개 월 10,000분 감사 로그, log streaming, advanced Tailscale SSH, JIT access가 필요한 조직
    Enterprise Custom 맞춤 맞춤 맞춤 대규모 조직, 맞춤 계약, 다중 tailnet이나 확장 기능 협의가 필요한 경우

    플랜표에서 진짜 중요한 건 가격표 숫자보다 무료 한계가 어디서 실무 한계로 바뀌느냐입니다. Personal은 최대 6명까지 무료이고 tagged resource 50개도 포함이라 홈랩 기준으로 꽤 넉넉합니다. 그런데 작은 회사 프로젝트에 그대로 가져가면 얘기가 달라집니다. 공식 문서 기준으로 Personal은 commercial use를 전제로 한 플랜이 아니기 때문입니다. 성능보다 소유권과 운영 정책에서 먼저 막히는 셈이죠.

    또 하나, tagged resource 50개 포함은 넉넉해 보여도 소규모 비즈니스에선 금방 닿을 수 있습니다. 사무실 subnet router, 재택 근무용 exit node, NAS, 백업 서버, staging VM, 모니터링 박스, app connector, 고정 러너 노드를 분리해 두면 생각보다 빨리 늘어납니다. 사람 수보다 인프라 역할 수가 더 빨리 커지는 팀이라면 seat보다 tag 구조를 먼저 계산하는 편이 맞습니다. 이 차이를 놓치면 Tailscale 비용이 예상보다 빨리 불어나더라고요.

    홈랩 VPN에서 Tailscale 비용 줄이는 방법

    홈랩은 대체로 Personal 플랜에서 오래 버틸 수 있습니다. 그렇다고 아무렇게나 써도 된다는 뜻은 아니에요. 오히려 무료를 오래 유지하려면 사람 계정은 최소화하고, 공유 인프라는 역할이 겹치지 않게 묶고, 태그는 접근 제어 때문에 꼭 필요할 때만 늘리는 편이 좋습니다. 이거 생각보다 차이가 큽니다.

    홈랩에서 먼저 줄여야 할 건 tagged resource의 과도한 분해입니다. NAS, Proxmox 호스트, 리버스 프록시, 미디어 서버, 백업 서버를 전부 다른 태그와 정책으로 잘게 나누면 처음엔 있어 보입니다. 그런데 운영이 길어질수록 관리 포인트만 늘어나더라고요. 홈랩에선 복잡한 보안 모델보다, 나중에 내가 이해할 수 있는 구조가 더 중요할 때가 많습니다.

    • 개인 사용자 1~3명 중심이면 Personal 유지가 보통 맞습니다.
    • 공유 인프라는 tag 하나로 시작하고, ACL 분리가 실제로 필요할 때만 세분화하는 편이 낫습니다.
    • 서브넷 라우터는 대역 전체를 무심코 광고하지 말고, 필요한 세그먼트만 내보내는 편이 안전합니다.
    • exit node는 1대 대표 노드로 먼저 검증하고, 가용성이나 지역 분산 요구가 생길 때 늘리는 편이 비용과 운영 모두 안정적입니다.

    예를 들어 사용자 2명, 노트북 3대, 모바일 2대, NAS 1대, 미니 PC 1대, subnet router 1대, exit node 1대 정도라면 Personal 안에서 충분히 정리되는 경우가 많습니다. 여기서 비용이 새기 시작하는 건 디바이스 수 자체가 아닙니다. 가족이나 지인을 정식 사용자로 계속 추가하거나, 서버 역할마다 태그를 쪼개서 공유 인프라 수를 불리는 순간부터 계산이 달라집니다.

    Tailscale 가격 최적화를 위한 홈랩 VPN 단일 exit node 구성 이미지

    무료 또는 저비용으로 유지하기 좋은 홈랩 구성 예시입니다. 사용자 수는 적게, 공유 인프라는 단순하게 가져가는 그림입니다.

    소규모 비즈니스 VPN에서 Tailscale 가격, 언제 Standard가 맞을까요?

    팀 운영은 기준이 다릅니다. 여기서는 무료냐 유료냐보다 누가 계정을 만들고, 누가 회수하고, 누가 승인하는가가 먼저예요. 구성원 수가 6명을 넘기기 시작하거나, 업무용 계정과 개인 계정을 섞어 쓰기 싫거나, 입사·퇴사 흐름을 IdP나 SCIM으로 묶고 싶다면 Personal을 오래 붙잡을 이유가 거의 없습니다. 이때부터 Standard는 단순한 비용 증가라기보다 운영 통제 비용을 선제적으로 지불하는 선택에 가깝습니다.

    특히 Standard의 가치는 seat 가격 8달러 자체보다, 권한 구조를 사람 손으로 덜 만지게 해주는 점에 있습니다. 홈랩에서는 seat 하나가 사용자 1명으로 끝나지만, 팀 환경에서는 seat 하나가 곧 라이프사이클 관리 단위가 됩니다. 이게 정리되지 않으면 퇴사자 계정, 외주 계정, 테스트 계정이 tailnet 안에 남습니다. 청구서보다 보안 쪽이 먼저 문제 되기 쉽습니다.

    상황 추천 플랜 이유 굳이 올리지 말아도 되는 경우
    개인 홈랩, 비상업용, 사용자 6명 이하 Personal 무료 범위가 넓고 user device 수가 과금 기준이 아님 태그·그룹 설계를 과도하게 복잡하게 만들지 않는다면 충분합니다
    작은 팀, 업무용 계정 운영, SCIM/MDM 필요 Standard seat 기반 관리와 역할 분리, 상업적 사용 맥락에 더 잘 맞음 감사 로그·흐름 로그·JIT 접근이 아직 필요 없다면 Premium까지는 과한 경우가 많습니다
    접속 기록 보존, 외부 SIEM 연동, 세밀한 SSH 통제 필요 Premium network flow logs, log streaming, advanced Tailscale SSH, JIT access가 포함됨 원격 접속과 내부 웹 접근이 주된 목적이라면 비용 대비 체감이 낮을 수 있습니다

    실무에서 자주 던지는 질문은 딱 두 개입니다. “퇴사자 seat를 그날 바로 비울 수 있는가?”, “사고가 나면 누가 언제 어디에 붙었는지 남겨야 하는가?” 첫 번째에 예라고 답해야 하면 Standard, 두 번째에 예라고 답해야 하면 Premium 검토가 빨라집니다.

    Tailscale 비용 최적화 구현: 최소 구성부터 확인해보겠습니다

    비용 최적화는 대개 노드를 덜 사는 것보다 역할을 덜 쪼개는 것에서 시작합니다. 홈랩이든 작은 팀이든 먼저 대표 노드 1대로 subnet router와 exit node를 함께 맡길 수 있는지 확인해보세요. 되면 tagged resource 수, 승인 포인트, 장애 추적 포인트가 같이 줄어듭니다. 단순한 구성이 진짜 오래 갑니다.

    여기서 중요한 건 정책 파일과 CLI를 같이 설계하는 겁니다. 태그를 붙이려면 tagOwners가 있어야 하고, subnet route나 exit node를 수동 승인 없이 운영하려면 autoApprovers가 필요합니다. 이걸 안 잡아두면 노드는 살아 있는데 승인 대기 상태로 남는 경우가 생깁니다. 처음엔 멀쩡해 보여도 나중에 꼭 한 번 발목을 잡더라고요.

    {
  "tagOwners": {
    "tag:infra": ["group:netops"]
  },
  "groups": {
    "group:netops": ["[email protected]", "[email protected]"]
  },
  "autoApprovers": {
    "routes": {
      "192.168.10.0/24": ["tag:infra"]
    },
    "exitNode": ["tag:infra"]
  }
}

    이 구성의 장점은 분명합니다. 사람 계정이 바뀌어도 tag가 승인 주체로 남기 때문에, 담당자 교체나 사용자 비활성화 때문에 route 광고가 갑자기 끊길 가능성을 줄일 수 있습니다. 공식 정책 문서도 이 시나리오에선 tag 기반 auto-approver를 고려하라고 안내합니다. 소규모 팀에서 특히 편하더라고요.

    sudo tailscale up \
  --advertise-tags=tag:infra \
  --advertise-routes=192.168.10.0/24 \
  --advertise-exit-node \
  --accept-dns=false

    명령 자체는 간단하지만, 해석 포인트는 세 가지입니다.

    1. 태그를 먼저 설계하고 노드에 붙이세요. 태그는 단순 라벨이 아니라 그 노드의 정체성입니다.
    2. 광고할 대역을 최소화하세요. 192.168.10.0/24처럼 필요한 CIDR만 지정하는 편이 낫습니다.
    3. tailscale up은 이전 플래그를 기억하지 않는다고 보고 항상 전체 플래그를 다시 적는 습관이 안전합니다. 공식 CLI 문서도 실행할 때마다 필요한 플래그를 모두 지정하라고 안내합니다.

    현장에서 많이 보는 실패 모드는 이겁니다. 처음엔 --advertise-tags만 넣고, 며칠 뒤엔 --advertise-routes만 넣는 식이죠. 운영자는 설정을 추가했다고 생각하지만, 실제로는 이전 의도를 빠뜨린 상태로 다시 올린 셈이 됩니다. 요즘 CLI가 경고를 주긴 하지만, 자동화 스크립트에선 여전히 전체 플래그를 명시하는 편이 더 안전합니다.

    서브넷 라우터 설정이나 Tailscale SSH 운영이 궁금하시면 관련 글도 같이 보시면 흐름이 더 잘 잡힙니다.

    Tailscale 가격과 tagged resource 관리 흐름을 보여주는 설정 화면 이미지

    tagged resource, advertised routes, exit node 승인 흐름을 이해하기 쉽게 보여주는 구성 이미지입니다.

    검증과 결과 해석: Tailscale 비용 오판을 막는 체크 포인트

    비용 최적화에서 검증이 중요한 이유는 단순합니다. 느리다고 해서 플랜 업그레이드가 답은 아니고, 노드를 더 만든다고 해서 경로가 좋아지는 것도 아니기 때문입니다. 먼저 direct 연결이 되는지, DERP relay에 오래 머무는지, NAT가 까다로운지부터 읽어야 합니다. 그래야 불필요한 exit node 추가나 tagged resource 증설을 막을 수 있습니다.

    tailscale status

tailscale status --json

tailscale netcheck

tailscale ping nas

tailscale ping --tsmp nas

    읽는 기준은 보통 이렇게 잡습니다.

    • tailscale status: 공유 노드가 계속 비슷한 상태로만 남는다면, 실제로 쓰지 않는 tagged resource인지 먼저 확인합니다.
    • status –json: 월말 점검은 사람 눈보다 자동화가 낫습니다. 온라인 여부나 피어 상태를 정리해 보면 안 쓰는 인프라가 드러납니다.
    • netcheck: UDP: false면 direct 연결 기대치를 낮추고, 방화벽이나 사내망 정책부터 의심하는 편이 맞습니다.
    • MappingVariesByDestIP: true면 hard NAT 가능성이 높습니다. 이 경우 플랜 문제가 아니라 네트워크 환경 문제일 가능성이 큽니다.
    • PortMapping이 비어 있거나 false면 라우터가 포트 매핑을 못 도와주는 상태일 수 있습니다. 홈랩에선 이게 은근한 병목입니다.
    • tailscale ping: 처음엔 DERP를 타다가 direct로 붙는 건 자연스러운 흐름입니다. 계속 DERP만 유지되면 NAT나 UDP 경로를 다시 봐야 합니다.
    • tailscale ping –tsmp: OS의 ICMP 제약을 우회해서 Tailscale 경로 자체를 보기 좋습니다. 원인 분리에 꽤 유용합니다.

    비용 관점에서 꼭 덧붙이고 싶은 해석이 하나 있습니다. DERP relay를 쓴다고 바로 Premium이 필요한 건 아닙니다. Premium은 로그와 통제 요구에 대한 답이지, NAT 문제를 요금제로 해결하는 플랜은 아닙니다. 연결이 느린데 곧장 플랜을 올리는 판단은 의외로 헛돈이 되기 쉽습니다.

    Tailscale 가격 분석과 함께 보는 direct 연결 및 DERP relay 검증 이미지

    direct 연결과 DERP relay 상태 차이를 한눈에 볼 수 있는 검증 결과 시각화입니다.

    자주 겪는 함정과 트러블슈팅

    여러 번 본 패턴을 압축하면, 문제는 기능 부족보다 정체성 관리가 섞일 때 생깁니다. 사람 장비에 태그를 붙여 사용자처럼 쓰려 하거나, 오래 살아 있는 서버를 ephemeral처럼 취급하거나, 상업용 tailnet을 무료 플랜 감각으로 운영하면 나중에 정리가 정말 어려워집니다. 초반엔 편해 보여도 뒤로 갈수록 비용과 운영이 같이 무거워집니다.

    • 함정 1: 무료 플랜으로 업무용 운영을 길게 끌기. 근본 원인은 비용 절감이 아니라 계정 소유권과 상업적 사용 정책 정리를 미루는 데 있습니다.
    • 함정 2: tagged resource를 서버 수만큼 잘게 쪼개기. 근본 원인은 보안 모델 과설계입니다. 태그 수가 늘면 ACL, autoApprovers, 운영 인수인계가 같이 복잡해집니다.
    • 함정 3: ephemeral resource를 일반 서버처럼 오래 띄우기. 공식 문서 기준으로 4시간 이상 존재하면 일반 tagged resource로 계산됩니다.
    • 함정 4: seat를 비우지 않고 사람만 교체하기. 근본 원인은 IdP deprovision 미흡입니다. seat 재사용은 가능하지만 계정 비활성화가 실제로 돌아가야 의미가 있습니다.
    • 함정 5: route auto-approval 없이 subnet router를 여러 대 늘리기. 승인 절차를 콘솔 수작업에 의존하면 운영자 부재 시 라우팅 장애가 납니다.
    • 함정 6: 사람 장비에 태그를 붙여 권한을 흉내 내기. 공식 문서 기준으로 태그를 적용하면 사용자 기반 인증이 제거됩니다. 태그는 사람용 메타데이터가 아니라 머신 정체성입니다.

    월말 점검은 저는 꽤 기계적으로 합니다.

    1. seat: 실제 로그인한 사용자 수와 현재 구매 seat 수가 맞는지 확인합니다.
    2. tagged resource: 더 이상 쓰지 않는 subnet router, exit node, app connector, 고정 서버가 남아 있지 않은지 봅니다.
    3. ephemeral usage: CI/CD나 쿠버네티스 워크로드가 4시간 이상 tailnet에 잔류하지 않는지 확인합니다.
    4. relay 상태: direct로 바꿀 수 있는 연결인데 DERP에만 머무는 장비가 없는지 봅니다. 이건 비용보다 체감 품질 문제를 줄이는 데 효과적입니다.

    FAQ: Tailscale 가격에서 많이 헷갈리는 포인트

    Tailscale 비용은 기기 수가 많으면 바로 올라가나요?

    보통은 아닙니다. 현재 공식 요금제 기준으로 핵심은 seat 수입니다. 다만 서버·subnet router·exit node처럼 tag가 붙은 공유 인프라는 tagged resource로 따로 관리해야 합니다.

    홈랩 VPN 용도라면 무료 플랜으로 충분한가요?

    대부분은 충분합니다. 사용자 6명 이내, 비상업용, tagged resource 50개 안쪽이면 Personal이 꽤 넉넉합니다. 다만 태그와 라우팅을 과하게 쪼개면 무료라도 운영 난도는 확 올라갑니다.

    소규모 비즈니스 VPN은 언제 Premium까지 가야 하나요?

    보안 감사, 접속 흐름 추적, 외부 로그 적재, 고급 SSH 통제, JIT access가 필요할 때입니다. 단순 원격 접속과 내부 웹 접근 위주라면 Standard에서 끝나는 팀도 많습니다.

    ephemeral minutes가 부족하면 무조건 Premium으로 올려야 하나요?

    그 전에 먼저 워크로드 수명을 보셔야 합니다. 짧게 떠야 할 러너가 오래 남아 있다면 플랜 문제보다 설계 문제일 가능성이 큽니다. 4시간 이상 존재한 장비는 일반 tagged resource로 계산된다는 점도 같이 보셔야 합니다.

    마무리: 저는 이렇게 고르라고 말씀드립니다

    개인 홈랩이라면 Personal부터 시작하시면 됩니다. 사용자 6명 이내, 비상업용, 공유 인프라 수가 많지 않다면 구조를 단순하게 유지하는 쪽이 이득입니다. 새 노드를 추가하기 전에 대표 subnet router 1대와 exit node 1대로 충분한지 먼저 검증해보세요. 무료 유지의 핵심은 기기 수보다 역할 수를 늘리지 않는 것입니다.

    작은 팀이라면 Standard를 출발점으로 보는 게 맞습니다. 업무용 계정 수명주기, 역할 분리, SCIM/MDM이 필요하면 여기서부터가 운영적으로 안정적입니다. 그리고 누가 언제 어디에 접근했는지 남겨야 하는 조직이면 Premium 검토를 미루지 않는 편이 낫습니다. 그 구간에선 요금보다 사고 대응 비용이 더 크게 돌아오거든요.

    한 줄로 정리하면 이렇습니다. 사람이 적고 구조가 단순하면 Personal, 계정 운영이 시작되면 Standard, 감사와 추적이 필수면 Premium. Tailscale 가격은 복잡해 보여도 seat·tagged resource·ephemeral minutes를 따로 보면 의외로 답이 선명합니다.

    Tailscale 가격 기준으로 홈랩과 소규모 비즈니스 플랜 선택을 요약한 이미지

    Personal, Standard, Premium 중 어떤 상황에서 무엇을 고르면 되는지 빠르게 판단할 수 있는 요약 이미지입니다.

  • 홈랩에서 주식 봇 2대를 4개월 굴려보고 — 솔직한 운영 회고 (Proxmox LXC)

    개인 투자용 보조 도구를 남의 클라우드에 올리기가 영 내키지 않았습니다. API 키, 알림, 관심 종목… 사소해 보여도 결국 내 판단 흔적이 남는 데이터라, 그냥 집에 있는 홈랩에 올리자 싶었죠. 그렇게 시그널 봇 1대 + 포트폴리오 봇 1대를 Proxmox LXC로 올려 4개월을 굴렸습니다. 성공담이 아니라 — 솔직히 잘된 것도, 벽에 부딪힌 것도 다 적어봅니다.

    1. 왜 클라우드가 아니라 홈랩이었나

    • 프라이버시: 보유 현황·관심 종목은 개인 투자 성향 그 자체입니다. 남의 서버에 두기 싫었어요.
    • 비용 0: 이미 돌아가는 홈랩(Intel i5-8500 · 6코어 · 31GB RAM · Proxmox VE 8.4)에 LXC 하나 더 얹는 건 공짜에 가깝습니다.
    • 완전한 통제: 언제든 콘솔 열고 뜯어볼 수 있습니다.

    2. 두 봇은 역할이 완전히 다릅니다

    코드가 아니라 ‘용도’ 기준으로 나눠보면 이렇습니다.

    • 시그널 봇 — 관심 종목의 리스크 뉴스 키워드(리콜·결함 등)를 감지하면 텔레그램으로 “검토 알림”을 보냅니다. 핵심 원칙은 “자동 매매가 아니라, 조건 충족 사실만 전달 — 매매 결정은 본인 판단” 입니다.

    ▲ 시그널 봇의 텔레그램 리스크 알림 예시

    • 포트폴리오 봇 — Core-Satellite 방식으로 보유 현황을 웹 대시보드에 보여주고, 트레일링스톱·트렌드브레이크·리스크뉴스 같은 신호를 표시합니다. “매주 적립, 매도는 목표 수익 도달 또는 펀더멘털 훼손 시에만” 같은 규칙 기반이고요.

    ▲ 포트폴리오 봇 대시보드 (실제 보유 수치는 가림)

    3. 굳이 LXC 2대로 나눈 이유 — 완전 격리

    둘을 한 서버에 몰지 않고 LXC 2대로 물리적으로 분리했습니다. 각각 별도 텔레그램 토큰, 별도 DB, 별도 코드 저장소로요.

    이유는 단순합니다. 한쪽이 죽거나 꼬여도 다른 쪽은 멀쩡해야 하니까요. 토큰이 섞이면 알림이 엉키고, DB가 섞이면 디버깅이 지옥이 됩니다. 봇 하나당 스펙도 소박합니다 — 2코어 / 1GB RAM / 8GB 디스크면 충분했습니다.

    # LXC 114 (stock-signal-bot)
cores: 2
memory: 1024
swap: 512
rootfs: local-zfs:subvol-114-disk-0, size=8G

# LXC 115 (stock-portfolio-bot) — 동일 스펙

    이 “작게 쪼개서 격리하는” 패턴은 나중에 다른 자동화(예: 블로그 발행 봇)에도 그대로 재사용했습니다. 한 번 몸에 익히니 새 프로젝트를 올릴 때 고민이 줄더라고요.

    4. 배포·운영

    각 LXC 안에서 Docker로 돌리고, onboot=1로 호스트 재부팅 시 자동 기동, 상태는 텔레그램 알림으로 확인합니다. 24/7 가동이지만 리소스가 작아 호스트에 부담이 거의 없습니다.

    5. 솔직히 — 가장 큰 벽은 ‘내 계좌 데이터’였습니다

    여기가 이 글의 핵심입니다. 인프라(LXC·Docker·알림)는 오히려 쉬웠고, 진짜 벽은 데이터였어요. 그런데 그 데이터가 시세가 아니라 ‘내 실제 보유 현황’ 이었다는 게 포인트입니다.

    • 시세(현재가·추이)는 어떻게든 흘러들어옵니다. 문제는 내가 어떤 종목을 몇 주, 평단 얼마에 갖고 있는지를 자동으로 못 가져온다는 거였습니다.
    • 증권사 계좌 연동이 벽이었습니다. 개인이 증권사 API를 붙이는 건 문턱이 높거나 제약이 많더라고요.
    • 그래서 주식을 사고팔 때마다 보유 수량·평단을 손으로 반영해야 합니다. 자동화 도구를 만들어놓고, 정작 제일 자주 바뀌는 데이터(내 포지션)를 수동으로 넣고 있는 거죠. 이게 제일 귀찮고, 자동화의 핵심을 못 채운 부분입니다.
    • 결국 “매매하면 손으로 업데이트”라는 수동 루프가 남았습니다. 대시보드는 멀쩡히 도는데 그 앞단에 사람 손이 계속 들어가니, “완전 자동”과는 거리가 멀어졌어요.

    6. 그래도 남은 것

    • LXC 격리·Docker·헬스체크·텔레그램 알림 같은 홈랩 운영 패턴을 제대로 체득했습니다.
    • “소규모 봇은 2코어/1GB면 충분하다”는 감이 생겨서, 이후 프로젝트의 리소스 산정이 훨씬 쉬워졌습니다.
    • 무엇보다 “뭐가 자동화의 진짜 병목인지”를 몸으로 배웠습니다. 서버가 아니라 데이터 소스라는 걸요.

    7. 홈랩에서 이런 봇 굴리려는 분께

    클라우드 홈랩(자가 호스팅)
    비용 월 과금 지속 전기세 수준(사실상 0)
    프라이버시 제3자 서버에 데이터 내 손 안
    유지보수 관리형(편함) 본인 몫
    데이터 접근 동일하게 API 필요 동일하게 API 필요

    핵심 조언 두 가지입니다.

    • 포트폴리오 자동화의 진짜 관문은 시세가 아니라 ‘내 계좌(보유 현황) 연동’입니다. 증권사 API가 붙는지부터 확인하세요. 안 되면 결국 수동 입력이 남고, 그게 자동화의 발목을 잡습니다.
    • 개인 금융 도구라면 클라우드보다 홈랩이 프라이버시·비용에서 유리합니다. 대신 유지보수는 온전히 본인 몫이라는 걸 감안하세요.

    ⚠️ 이 글은 홈랩 운영 기록이며 투자 조언이 아닙니다. 언급된 종목·수치는 예시일 뿐이며, 어떤 매매도 권유하지 않습니다.

  • [HomeLabs] UniFi Protect 비용 vs DIY NVR, 장기 운영비까지 비교

    [HomeLabs] UniFi Protect 비용 vs DIY NVR, 장기 운영비까지 비교

    목차

    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 비용 비교를 위한 전체 아키텍처 다이어그램

    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를 밀어 올리는지 바로 보이기 때문입니다.

    항목 UniFi Protect DIY NVR 실무 판단 기준
    초기 장비 콘솔과 카메라 조합이 사실상 세트에 가깝습니다 기존 서버, NAS, 미니 PC 재활용이 가능합니다 남는 장비가 없으면 체감 격차가 줄고, 남는 장비가 많으면 DIY가 훨씬 유리해집니다
    설치 난이도 초기 설정이 짧고 시행착오가 적습니다 스트림, 저장소, 권한, 가속 설정을 직접 맞춰야 합니다 첫 주말 안에 끝내고 싶다면 Protect 쪽이 더 안전합니다
    카메라 선택권 UniFi 중심일 때 가장 매끄럽고, 일부 ONVIF 카메라도 연동 가능합니다 RTSP/ONVIF 카메라를 폭넓게 섞을 수 있습니다 기존 카메라를 최대한 살려야 하면 DIY가 더 현실적입니다
    저장소 설계 구조가 단순하고 예상이 쉽습니다 OS 디스크, 녹화 디스크, 보존 정책을 직접 설계합니다 영상 보존 일수와 I/O 패턴을 이해하지 않으면 DIY에서 먼저 문제 납니다
    장애 범위 원인 추적 범위가 좁습니다 네트워크, 컨테이너, ffmpeg, 디코딩, 파일시스템까지 넓습니다 운영 경험이 적을수록 Protect의 시간 절약 효과가 커집니다
    확장 시 비용 예측은 쉽지만 생태계 안에서 확장해야 합니다 부품 단위로 늘릴 수 있지만 병목도 함께 늘어납니다 카메라 수가 늘수록 DIY는 설계 품질 차이가 크게 납니다
    가족/동료 사용성 앱 경험이 균일하고 인계가 쉽습니다 UI와 알림 품질이 조합에 따라 편차가 큽니다 공용 인프라라면 사용성 저하가 곧 숨은 비용입니다
    장기 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는 시간을 아끼는 방식입니다. 둘 중 어느 쪽이 더 비싼지는 가격표보다 사용자의 성향이 더 크게 좌우합니다.

    UniFi Protect 비용과 DIY NVR 비용 요소 비교 인포그래픽

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

    짧은 FAQ

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

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

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

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

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

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

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

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

    참고 자료

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

  • [HomeLabs] MikroTik RouterOS 트러블슈팅: 홈 네트워크 5가지 해결책

    [HomeLabs] MikroTik RouterOS 트러블슈팅: 홈 네트워크 5가지 해결책

    목차

    MikroTik RouterOS 트러블슈팅: 홈 네트워크 안정성 확보를 위한 5가지 해결책

    집에서 MikroTik RouterOS 트러블슈팅을 해보면, 문제 자체보다 더 피곤한 건 증상이 애매하다는 점입니다. 와이파이는 붙는데 웹만 안 열리거나, 낮에는 멀쩡한데 밤에만 지연이 튀고, 게임 핑이 흔들리는데 가족들 OTT는 또 되는 식이죠. 저도 홈랩과 가정용 회선을 RouterOS로 오래 만져보면서 느낀 건 하나였습니다. 설정을 많이 아는 사람보다, 어디부터 의심할지 아는 사람이 더 빨리 고칩니다.

    특히 MikroTik 홈 네트워크에서는 증상 하나를 여러 계층이 동시에 만들어냅니다. WAN 재협상, DHCP 임대 꼬임, DNS 캐시 실패, 브리지 포트 오배치, FastTrack 때문에 가려진 흐름, MTU 불일치, connection tracking 과부하가 비슷한 얼굴로 나타나거든요. 그래서 이 글은 기능 설명보다 집에서 실제로 장애를 좁혀가는 순서에 맞춰 정리했습니다. 무엇을 먼저 보고, 어떤 출력이면 어디를 의심하고, 언제 설정을 건드리지 말아야 하는지까지 담았습니다.

    광고성 요약 글처럼 메뉴 이름만 나열하지 않겠습니다. 대신 제가 RouterOS를 만질 때 실제로 효과가 좋았던 기준만 추렸습니다. 핵심은 다섯 가지입니다. 백업과 증거 확보, DHCP/DNS 분리 진단, MTU/MSS 확인, 브리지 루프 차단, 방화벽·세션 병목 판별. 이 다섯 축만 제대로 보면, 홈 네트워크 안정성 문제는 꽤 높은 확률로 방향이 잡힙니다.

    홈 인터넷 회선, MikroTik 라우터, 스위치, 무선 AP, NAS, IoT 기기가 어떻게 연결되는지 한눈에 보여주는 개요 이미지입니다.

    MikroTik RouterOS 트러블슈팅, 왜 순서가 중요할까

    RouterOS에서 흔히 하는 실수가 있습니다. 증상을 보자마자 NAT, DNS, 방화벽 규칙부터 고치는 겁니다. 이게 왜 위험하냐면, RouterOS는 기능 간 결합이 강해서 하나를 건드리는 순간 진짜 원인의 흔적이 사라질 수 있기 때문입니다. 예를 들어 DNS가 느린 것처럼 보여도 실제 원인은 WAN flap일 수 있고, 방화벽 병목처럼 보여도 브리지 루프가 CPU를 끌어올린 것일 수 있습니다.

    제가 권하는 순서는 늘 같습니다.

    1. 문제 범위를 먼저 자릅니다. 모든 단말이 문제인지, 특정 VLAN/AP/기기만 문제인지부터 확인합니다.
    2. IP 자체가 죽는지, 이름 해석만 죽는지 분리합니다. /ping 1.1.1.1과 /ping google.com은 항상 따로 봅니다.
    3. 현재 상태를 저장합니다. 로그, 인터페이스 링크 상태, 라우트, DHCP lease, 브리지 포트 구성을 남깁니다.
    4. 수정은 한 번에 하나만 합니다. DNS와 MTU와 방화벽을 한 번에 건드리면, 나중에 살아난 이유도 모릅니다.
    5. 수정 후에는 원래 깨지던 조건으로 다시 검증합니다. 한 번 핑이 됐다고 끝내면 재발하더라고요.

    이 순서가 중요한 이유는 단순합니다. RouterOS 문제 해결은 최적화보다 감별진단에 가깝기 때문입니다. 기능이 많다는 건 옵션이 많다는 뜻이지만, 동시에 오진 가능성도 많다는 뜻입니다.

    증상별로 어떤 도구를 먼저 볼지

    증상 가장 먼저 볼 것 권장 명령 이 출력이면 이렇게 판단
    인터넷이 간헐적으로 끊김 WAN 링크 상태, 기본 경로 활성 여부 /interface print detail, /ip route print detail where dst-address=0.0.0.0/0 포트 running 상태가 반복적으로 바뀌거나 기본 경로가 inactive면 회선, PPPoE, DHCP client 쪽부터 봅니다.
    와이파이는 연결되는데 웹이 안 열림 DHCP lease, DNS 응답 경로 /ip dhcp-server lease print detail, /ip dns print, /ping 1.1.1.1, /ping google.com IP 핑 성공 + 도메인 실패면 DNS 문제, lease 자체가 없으면 무선 문제가 아니라 DHCP 또는 브리지 문제일 가능성이 큽니다.
    특정 앱 로그인·업로드만 실패 MTU, MSS, PMTUD 차단 여부 /ping 1.1.1.1 size=1472 do-not-fragment=yes, /ip firewall mangle print detail 작은 패킷만 통과하면 MTU 경로 문제 가능성이 높고, 무조건 MTU를 낮추기보다 MSS 보정이 필요한지 먼저 봅니다.
    시간이 지나면 전체가 버벅임 CPU 사용률, connection tracking, 규칙 hit 수 /tool profile, /ip firewall connection print count-only, /ip firewall filter print stats firewall 또는 networking 비중이 튀고 세션 수가 급증하면 규칙 순서나 과도한 세션 생성 장비를 의심합니다.
    갑자기 네트워크 전체가 폭주 브리지 포트, MAC 이동, 브로드캐스트 급증 /tool torch interface=bridge, /interface bridge host print, /log print where message~"bridge" 동일 MAC이 포트를 옮겨 다니거나 의미 없는 트래픽이 계속 보이면 루프 가능성이 큽니다.

    여기서 포인트는 사용자가 말하는 “느리다”를 그대로 믿지 않는 겁니다. 사용자 입장에서는 DNS 지연도 느리고, MTU 문제도 느리고, 브리지 루프도 느립니다. 하지만 장비 입장에서는 완전히 다른 장애입니다. 그래서 진단 명령도 달라져야 합니다.

    해결책 1: 백업과 로그부터 남기기

    RouterOS에서 첫 번째 조치는 늘 같습니다. 설정을 고치는 게 아니라, 증거를 확보하는 것입니다. 실제로 여러 번 느낀 건, 문제 해결 속도는 CLI 실력보다 문제 직전 상태를 얼마나 잘 남겨뒀는가에 더 크게 좌우된다는 점이었습니다. 특히 집에서는 장애가 간헐적이라 멀쩡할 때만 장비를 들여다보게 되니까요.

    최소한 아래 정도는 바로 떠두는 편이 낫습니다.

    /export hide-sensitive file=before-troubleshoot
/system backup save name=before-troubleshoot password=CHANGE_ME
/log print without-paging
/system resource print
/interface print detail
/interface monitor-traffic [find] once
/ip address print detail
/ip route print detail
/ip dhcp-client print detail
/ip dns print
/interface bridge port print detail

    여기서 /export hide-sensitive를 권하는 이유가 있습니다. 백업 파일은 같은 장비에 되돌릴 때 강하지만, 사람이 diff를 읽기엔 export 쪽이 훨씬 편합니다. 반대로 바이너리 백업은 원복에는 강하죠. 둘 중 하나만 고르기보다 분석용 export, 원복용 backup을 같이 가져가는 편이 실무적입니다. 다만 공식 문서 기준으로 바이너리 백업은 같은 장비, 가급적 같은 RouterOS 버전에서 복원하는 쪽이 안전합니다.

    출력을 읽을 때는 이런 기준이 꽤 유용합니다.

    • /interface print detail에서 WAN 인터페이스가 running 상태를 잃었다 되찾는 흔적이 있으면, DNS나 방화벽 전에 물리 링크와 상위 회선 재협상을 의심합니다.
    • /ip route print detail에서 기본 경로가 여러 개이거나 distance와 활성 상태가 예상과 다르면 장애 시점에 우선순위 전환이 있었는지 봅니다.
    • /log print에 link down, dhcp, pppoe, disconnect 메시지가 반복되면 라우터 내부 최적화보다 상위 연결 안정성이 우선입니다.
    • /system resource print에서 메모리보다 CPU 급등이 문제라면, 다음 단계에서 /tool profile로 어떤 기능이 CPU를 먹는지 좁혀야 합니다.

    반대로 이런 경우에는 설정 변경을 미루는 게 맞습니다. 문제가 지금 재현 중인데 로그가 계속 쌓이고 있는 상황입니다. 이때 NAT, FastTrack, DNS 서버 주소를 동시에 바꾸면 진짜 원인은 사라지고 운 좋게 증상만 가려질 수 있습니다. 집에서는 일단 되게 만들고 싶은 유혹이 큰데, 재발하는 장애는 대부분 여기서 시작되더라고요.

    해결책 2: DHCP와 DNS부터 분리해서 확인하기

    홈 네트워크에서 “인터넷이 안 된다”는 말은 진단 용어가 아닙니다. RouterOS에서는 최소한 두 개로 쪼개야 합니다. 단말이 정상 IP를 받지 못하는 문제와 IP는 되지만 이름 해석이 깨지는 문제입니다. 이 둘을 섞어서 보면 시간만 낭비합니다.

    저는 이 단계에서 항상 단말 하나를 기준점으로 잡습니다. 문제를 겪는 폰이든 노트북이든 하나를 정하고, 그 기기의 IP, 게이트웨이, DNS 서버, lease 상태를 먼저 맞춰봅니다. 여러 장비를 동시에 보면 이상하게 더 헷갈릴 때가 많았습니다.

    /ip dhcp-server lease print detail
/ip dhcp-server network print detail
/ip dhcp-server print detail
/ip dns print
/ip dns cache print where name~"google|cloudflare"
/ping 1.1.1.1 count=5
/ping google.com count=5
/tool traceroute 1.1.1.1

    판단은 다음처럼 자르면 됩니다.

    1. 1.1.1.1은 안정적으로 응답하는데 google.com이 실패한다면, 회선보다 DNS 경로가 문제일 가능성이 큽니다.
    2. 문제 단말의 lease가 안 보이거나 계속 새로 생기면, DHCP pool 부족보다 먼저 브리지 소속과 AP uplink 포트 배치를 봅니다.
    3. 여러 단말이 랜덤하게 DNS 실패를 겪는데 IP 통신은 된다면, allow-remote-requests, 상위 DNS 응답 품질, 또는 DNS 패킷이 특정 규칙에 막히는지 확인합니다.
    4. 특정 SSID에서만 실패하면 무선 문제로 단정하기보다, 그 SSID가 매핑된 bridge 또는 VLAN과 DHCP server 바인딩을 의심하는 편이 빠릅니다.

    DNS는 특히 오진이 많습니다. 예를 들어 사용자는 웹이 느리다고 하지만, 실제로는 첫 번째 도메인 조회만 실패하고 새로고침 몇 번 후 열리는 경우가 있습니다. 이럴 때 회선 속도 테스트를 돌리는 건 거의 무의미합니다. 먼저 RouterOS가 재귀 DNS를 직접 중계하는지, 단말이 외부 DNS를 직접 쓰는지, 캐시 실패가 반복되는지부터 봐야 합니다.

    RouterOS에서 DNS를 라우터가 직접 받아줄 때는 보통 이렇게 확인합니다.

    /ip dns print
/ip dns set allow-remote-requests=yes servers=1.1.1.1,8.8.8.8
/ip firewall filter print stats where chain=input
/log print where message~"dns"

    다만 여기에는 분명한 트레이드오프가 있습니다. 라우터가 DNS를 직접 중계하면 단말 관리가 단순해지고 캐시 이점도 생기지만, 장애 지점이 하나 더 늘어납니다. 반대로 단말이 외부 DNS를 직접 보게 하면 문제 분리는 쉬워지지만, 정책 통일과 로컬 이름 해석은 불편해집니다. 가정용에서 장비 수가 적고 관리가 간단해야 하면 라우터 DNS 중계가 편하고, 홈랩처럼 실험이 잦고 원인 분리가 중요하면 외부 DNS 직결이 오히려 더 편할 때도 있습니다.

    제가 자주 본 실패 모드는 이겁니다. AP를 추가하면서 포트를 브리지에 넣긴 했는데, DHCP 서버가 붙은 인터페이스와 실제 무선 트래픽이 지나가는 인터페이스가 달라진 경우입니다. 이때 단말은 와이파이에 붙지만 lease가 불안정하거나, DNS만 이상하게 새는 현상이 납니다. 겉보기엔 DNS 장애처럼 보여도, 근본 원인은 L2 경로 설계 실수인 경우가 꽤 많습니다.

    MikroTik RouterOS 트러블슈팅에서 DHCP와 DNS 점검 흐름 이미지

    DHCP 임대 목록, DNS 설정, 핑 테스트를 어떤 순서로 보는지 흐름 중심으로 보여주는 이미지입니다.

    해결책 3: MTU와 MSS 문제를 의심해야 할 때

    이 단계는 초보자뿐 아니라 경험자도 자주 놓칩니다. 전체 인터넷은 되는 것처럼 보이는데, 특정 로그인 페이지가 멈추거나, 대용량 업로드가 중간에 끊기거나, VPN만 유난히 불안정한 경우가 그렇습니다. 제 경험상 이런 문제는 서버 탓으로 오해되기 쉽지만, 실제로는 경로 MTU와 TCP MSS가 더 자주 원인입니다.

    특히 PPPoE, 터널, VPN, 이중 NAT, 일부 ISP 장비가 섞이면 PMTUD가 기대대로 동작하지 않는 경우가 있습니다. 여기서 흔한 실수는 아무 근거 없이 MTU를 확 낮춰버리는 겁니다. 일시적으로 증상이 숨을 수는 있지만, 왜 그런지 이해하지 못한 채 덮어두는 셈이라 나중에 다른 터널이나 서비스에서 다시 터질 수 있습니다.

    /ping 1.1.1.1 size=1472 do-not-fragment=yes count=5
/ping 1.1.1.1 size=1464 do-not-fragment=yes count=5
/ping 1.1.1.1 size=1400 do-not-fragment=yes count=5
/interface pppoe-client print detail
/ip firewall mangle print detail
/log print where message~"fragment|mtu|icmp"

    해석 기준은 간단하지만, 순서는 중요합니다.

    • 작은 패킷은 되는데 큰 패킷만 실패하면 MTU 관련 문제일 가능성이 큽니다.
    • 웹 브라우징은 되는데 파일 업로드, HTTPS handshake, 특정 앱 로그인만 불안정하면 MSS 보정 필요성을 봅니다.
    • PPPoE나 터널 인터페이스가 있다면 실제 오버헤드 때문에 usable MTU가 줄어들 수 있으니, 단순히 물리 포트 MTU만 봐서는 안 됩니다.
    • ICMP가 경로에서 비정상적으로 막히면 PMTUD가 제대로 동작하지 않아 증상이 더 애매해질 수 있습니다.

    RouterOS에서 실무적으로 많이 쓰는 방식은 TCP SYN 패킷에 대해 MSS를 PMTU에 맞게 clamp 하는 겁니다.

    /ip firewall mangle add chain=forward action=change-mss new-mss=clamp-to-pmtu protocol=tcp tcp-flags=syn comment="Clamp TCP MSS to PMTU"
/ip firewall mangle print stats
/tool sniffer quick ip-protocol=tcp

    이 설정이 유용한 상황과 피해야 할 상황도 분명합니다.

    상황 권장 접근 이유
    PPPoE, VPN, 터널링이 있고 특정 서비스만 실패 MSS clamp 우선 검토 패킷 경로의 실제 MTU 차이를 TCP 세션에서 완화하기 쉽습니다.
    회선 전체가 불안정하고 링크 자체가 자주 끊김 MTU보다 링크/WAN부터 점검 MTU 문제는 대개 선택적 실패를 만들지, 물리 링크 flap 자체를 만들지는 않습니다.
    원인 확인 없이 전 인터페이스 MTU를 임의로 하향 권장하지 않음 증상을 가릴 수는 있어도 이후 VPN, VLAN, 다른 경로에서 부작용이 재발하기 쉽습니다.
    ICMP 제어 패킷이 정책상 과도하게 차단됨 필터 정책 재검토 PMTUD 실패로 인해 웹과 앱 일부만 깨지는 모호한 장애가 생길 수 있습니다.

    제가 겪었던 패턴 중 하나도 비슷했습니다. 외부 백업 서비스 업로드가 매번 중간에 멈추는데 웹서핑은 멀쩡했거든요. 처음엔 원격 서버 장애인 줄 알았는데, RouterOS 쪽에서 경로 MTU가 어긋난 상태였고 SYN 이후 세그먼트 크기 조정이 제대로 안 된 케이스였습니다. 이때 무작정 MTU를 줄이는 대신, 어느 크기부터 깨지는지 확인한 뒤 MSS 규칙을 넣고 재현 테스트를 하니 원인과 해결이 같이 정리됐습니다. 이거 진짜 편하더라고요.

    해결책 4: 브리지 루프와 브로드캐스트 폭주 잡기

    홈랩 환경에서 가장 아프게 터지는 장애는 의외로 고급 기능이 아니라 브리지 루프입니다. 스위치를 하나 더 붙이고, AP를 메쉬로 묶고, NAS를 임시로 이중 연결하고, 테스트용 케이블을 잠깐 꽂았다가 전체 네트워크가 멈춰버리는 식이죠. 이건 사용자 체감상 인터넷이 갑자기 다 죽었다로 보이지만, 실제론 회선이 아니라 L2가 폭주한 경우가 많습니다.

    RouterOS에서 이 문제를 볼 때는 CPU 수치만 보면 안 됩니다. CPU가 높다는 건 결과일 뿐이고, 원인은 대개 브로드캐스트 스톰이나 MAC flapping입니다. 제가 이 유형을 볼 때는 다음 순서로 갑니다.

    /tool torch interface=bridge
/interface bridge port print detail
/interface bridge monitor [find] once
/interface bridge host print
/log print where message~"bridge|topology|loop|stp|rstp"

    이때 출력에서 눈여겨볼 건 세 가지입니다.

    1. 특정 포트에서 비정상적으로 많은 브로드캐스트·멀티캐스트가 보이는지
    2. 동일 MAC 주소가 여러 포트에서 번갈아 관측되는지
    3. 포트 상태 변경이나 토폴로지 변화 로그가 반복되는지

    루프는 특히 잠깐 연결했다가 괜찮아 보이는 상황이 더 위험합니다. 완전히 즉시 다운되지 않고, 트래픽이 많아지는 시간대에만 장애가 재현되기도 하거든요. 그래서 평소엔 멀쩡한데 백업 시간, 카메라 업로드 시간, 스마트홈 장비 재접속 시간에만 갑자기 망가지는 패턴이 나옵니다.

    이럴 때 제 권고는 명확합니다. 브리지 설계를 사람 기억에 맡기지 말고, 포트 역할을 문서화하고 RSTP 같은 루프 방지 보호를 켜는 쪽이 낫습니다. 장비마다 세부 구성은 다르지만, 원칙은 같습니다. 실수해도 전체가 안 죽게 해야 합니다. 홈 네트워크는 가용성을 지키는 게 최고급 최적화보다 훨씬 가치가 큽니다.

    자주 놓치는 실패 모드도 있습니다.

    • AP uplink를 access처럼 써야 하는데 trunk처럼 연결해 VLAN이 예상 밖으로 섞이는 경우
    • 브리지 포트에 임시 테스트 스위치를 연결했다가 원형 경로가 생기는 경우
    • 메시 Wi-Fi와 유선 uplink가 동시에 살아 있는데, 설계 의도와 다르게 중복 경로가 열린 경우
    • NAS나 스위치 이중 연결을 했지만 LACP나 스패닝트리 정합 없이 물리적으로만 두 줄 꽂은 경우

    이 유형은 방화벽 규칙을 아무리 다듬어도 해결되지 않습니다. 근본 원인이 L2 토폴로지이기 때문입니다. CPU가 높다고 해서 곧바로 성능 튜닝으로 들어가면 안 되는 이유가 바로 여기 있습니다.

    MikroTik 홈 네트워크의 브리지 루프와 브로드캐스트 폭주 설명 이미지

    잘못 연결된 스위치 또는 AP uplink 때문에 루프가 생기고 트래픽이 폭주하는 상황을 시각적으로 설명하는 이미지입니다.

    해결책 5: Firewall과 Connection Tracking 상태를 봐야 할 때

    홈 네트워크가 느려졌다고 해서 항상 회선이 포화된 건 아닙니다. 요즘은 NAS 동기화, 카메라 스트림, 토렌트, 게임 런처, IoT 장비 재접속이 겹치면서 세션 수 자체가 병목이 되는 경우가 많습니다. RouterOS에서는 특히 connection tracking과 방화벽 규칙 순서가 얽히면 랜덤하게 느림처럼 체감되기 쉽습니다.

    제가 이 구간을 볼 때는 단순히 규칙 개수보다 어떤 규칙이 실제로 많이 맞는지를 먼저 봅니다. 규칙은 적어도 순서가 나쁘면 손해를 보고, 규칙이 많아도 상단이 정리돼 있으면 생각보다 안정적입니다.

    /ip firewall connection print count-only
/tool profile
/ip firewall filter print stats
/ip firewall nat print stats
/ip firewall raw print stats
/log print where message~"drop|invalid|fasttrack"

    판단 기준은 이렇습니다.

    • /tool profile에서 firewall, networking, bridge가 문제 시점에 튄다면 해당 경로를 의심합니다.
    • /ip firewall filter print stats에서 오래된 테스트 규칙이 상단에서 계속 hit 된다면, 규칙 순서 정리가 성능과 가독성을 동시에 개선합니다.
    • 세션 수가 급격히 늘어나는데 특정 장비나 특정 시간대와 겹치면, 회선 자체보다 내부 트래픽 성격이 원인일 수 있습니다.
    • invalid 패킷 drop 로그가 과도하게 쌓이면 비정상 트래픽, 비대칭 경로, 또는 추적이 꼬이는 상황인지 구분해야 합니다.

    여기서 실무적으로 중요한 게 FastTrack입니다. FastTrack은 분명 성능에 도움이 될 수 있지만, 트러블슈팅 중에는 관측성을 떨어뜨릴 수 있습니다. QoS나 일부 카운터, 특정 규칙 흐름이 기대만큼 보이지 않는 상황이 생길 수 있기 때문입니다. 그래서 증상 분석 단계에서는 왜 느린지를 먼저 보고, 안정화 이후에 어디를 빨리 할지를 정하는 편이 훨씬 낫습니다.

    즉, 이럴 땐 이렇게 가면 됩니다.

    상황 추천 이유
    가끔 느리지만 원인이 불명확함 FastTrack 효과부터 보지 말고 규칙 통계와 profile부터 확인 병목 위치를 모른 채 최적화하면 증상만 숨길 수 있습니다.
    대량 세션이 생기는 NAS, 토렌트, 카메라가 있음 세션 수와 hit 많은 규칙을 먼저 정리 회선 대역폭보다 연결 추적과 규칙 처리 비용이 먼저 문제일 수 있습니다.
    정책 기반 라우팅, QoS, 세밀한 추적이 중요함 FastTrack 적용 범위를 보수적으로 검토 관측성과 정책 일관성이 성능 향상보다 중요할 때가 많습니다.
    장애 분석이 끝나고 단순 인터넷 공유가 주 목적 그때 최적화 검토 안정화 이후에야 성능 조정의 효과와 부작용을 판단하기 쉽습니다.

    제가 실제로 겪은 패턴도 비슷했습니다. 밤마다 NAS 백업과 외부 동기화가 겹치면 웹이 버벅이고 스트리밍이 불안정해졌는데, 속도 테스트만 보면 회선이 완전히 죽은 건 아니었습니다. 확인해보니 특정 시간대에 세션 수가 급증했고, 오래전에 넣어둔 테스트용 필터 규칙이 위쪽에서 계속 맞고 있었습니다. 이럴 때 회선 사업자를 탓하는 건 정확한 접근이 아닙니다. 규칙 흐름과 내부 트래픽 성격을 봐야 맞습니다.

    재현 가능한 시나리오 하나: 밤마다 끊기던 홈랩 라우터

    추상적인 얘기만 하면 현장감이 떨어져서, 제가 실제로 많이 보는 유형으로 재구성해보겠습니다. 집에서 밤마다 NAS 백업, 클라우드 동기화, 카메라 업로드가 겹치는 시간대만 인터넷이 흔들립니다. 증상은 이렇습니다. 휴대폰 와이파이는 붙어 있고, 메신저는 가끔 되는데 웹페이지 첫 로딩이 느리고, TV 스트리밍은 버퍼링이 생깁니다. 낮에는 멀쩡합니다.

    이럴 때 저는 순서를 이렇게 잡습니다.

    1. /ping 1.1.1.1 count=20와 /ping google.com count=20으로 IP와 DNS를 먼저 분리합니다.
    2. /tool profile로 문제 시간대에 CPU가 어디서 쓰이는지 봅니다.
    3. /ip firewall connection print count-only로 세션 수가 급증하는지 확인합니다.
    4. /ip firewall filter print stats, /ip firewall nat print stats로 어떤 규칙이 실제 hit 되는지 봅니다.
    5. 그래도 애매하면 /tool torch interface=bridge로 내부 브로드캐스트 폭주가 없는지 확인합니다.

    이 시나리오에서 중요한 건 한 번에 모든 가설을 세우지 않는 겁니다. 밤마다 느려진다고 해서 곧바로 회선 품질, DNS 사업자, 장비 성능, 무선 간섭을 다 의심하면 진도가 안 나갑니다. 시간대 의존성이 보이면 먼저 내부 트래픽 이벤트를 겹쳐보는 게 맞습니다. 백업, 동기화, 카메라 업로드, 펌웨어 자동 업데이트처럼 일정성 있는 작업이 생각보다 자주 원인입니다.

    이 유형에서 제가 내리는 추천은 분명합니다. 밤에만 느리면 회선보다 내부 이벤트를 먼저 보세요. IP 핑은 되는데 웹만 느리면 DNS와 세션 처리, 전체가 같이 흔들리면 브리지와 방화벽 쪽을 먼저 보시는 게 효율적입니다.

    검증: 수정 후에는 이렇게 확인하면 됩니다

    RouterOS에서 수정의 절반은 적용이고, 나머지 절반은 검증입니다. 장애가 한 번 안 보였다고 끝내면 안 됩니다. 특히 간헐 장애는 수정 직후보다, 원래 깨지던 조건에서 다시 확인해야 의미가 있습니다.

    /ping 1.1.1.1 count=20
/ping google.com count=20
/log print follow
/ip firewall filter print stats
/ip firewall nat print stats
/interface print detail

    수정 후 검증은 아래 기준이면 충분히 실무적입니다.

    1. IP 핑과 도메인 핑이 둘 다 안정적인지 확인합니다.
    2. WAN 인터페이스나 DHCP, PPPoE 상태가 다시 flap 하지 않는지 봅니다.
    3. 문제 시점에 반복되던 로그가 사라졌는지 확인합니다.
    4. 원래 깨지던 시간대나 트래픽 조건에서 재현 테스트를 다시 합니다.
    5. 규칙 hit 수와 CPU profile이 수정 전과 어떻게 달라졌는지 비교합니다.

    여기서 중요한 건 한 번 성공보다 실패하던 조건에서 다시 안 깨지는지입니다. 예를 들어 업로드 중단 문제가 원인이었다면, 웹 열림만 확인할 게 아니라 실제 업로드를 다시 만들어봐야 합니다. 브리지 루프가 문제였다면 한가한 시간대가 아니라 트래픽이 몰리는 시간대까지 봐야 하고요.

    RouterOS 문제 해결 후 네트워크 안정성 검증 대시보드 이미지

    수정 전후를 비교하면서 핑 안정성, 로그 변화, 트래픽 상태를 한눈에 확인하는 검증용 이미지입니다.

    MikroTik RouterOS 트러블슈팅에서 자주 놓치는 체크포인트

    • 케이블과 포트 협상: 설정만 보다가 물리 링크 재협상을 놓치는 경우가 많습니다. WAN flap은 DNS 장애처럼 보일 수 있습니다.
    • 브리지 포트 오배치: AP나 스위치 uplink가 기대한 브리지 또는 VLAN에 안 붙어 있으면 증상이 랜덤하게 보입니다.
    • DNS와 인터넷 연결 혼동: IP 핑과 도메인 핑을 분리하지 않으면 진단이 처음부터 틀어집니다.
    • 오래된 테스트 규칙 방치: 방화벽 규칙은 개수보다 순서와 실사용 hit가 더 중요합니다.
    • FastTrack을 너무 일찍 켬: 최적화는 유용하지만, 분석 단계에서는 흐름을 가릴 수 있습니다.
    • 문제 시점 기록 부재: 언제 느려졌는지 모르는데 로그를 읽는 건 거의 점치기에 가깝습니다.
    • MTU를 감으로 낮춤: 원인 확인 없이 전체 MTU를 줄이면 다른 서비스에서 더 애매한 문제가 생길 수 있습니다.

    마지막으로, 이런 경우엔 이렇게 가시면 됩니다

    MikroTik RouterOS 트러블슈팅은 기능 백과사전을 외우는 작업이 아닙니다. 집이나 홈랩에서는 판단 기준을 최대한 단순하게 가져가는 편이 좋습니다.

    인터넷 전체가 같이 흔들리면 WAN 링크와 기본 경로부터 보시면 됩니다. 이 경우 DNS나 애플리케이션별 미세 조정보다 상위 연결 안정성이 먼저입니다. 와이파이는 붙는데 웹만 이상하면 DHCP와 DNS를 먼저 분리하세요. IP 핑이 되면 회선이 완전히 죽은 건 아닙니다. 특정 업로드, 로그인, VPN만 깨지면 MTU/MSS를 의심하는 편이 맞고, 갑자기 전체가 먹통이 되거나 CPU가 튀면 브리지 루프와 브로드캐스트 폭주를 먼저 배제해야 합니다. 밤마다 버벅이거나 내부 장비가 많다면 방화벽 규칙 통계와 connection tracking을 보는 게 가장 실용적입니다.

    최종적으로 드리고 싶은 추천은 이겁니다. 가정용 RouterOS 안정화의 우선순위는 백업과 로그 확보, DHCP/DNS 분리 진단, MTU/MSS 확인, 브리지 설계 점검, 방화벽·세션 정리 순서로 가져가세요. 기능 추가는 그다음입니다. 반대로 장비를 자주 붙였다 뗐다 하는 홈랩이라면 RSTP 계열 보호와 포트 문서화가 생각보다 훨씬 큰 가치를 줍니다. 회선이 멀쩡한데 특정 서비스만 실패한다면, 그때는 회선 속도보다 패킷 크기와 세션 흐름을 보는 쪽이 더 정확합니다.

    다음 글에서는 RouterOS에서 VLAN 분리와 Guest Wi-Fi 구성할 때 실제로 많이 틀리는 포인트를 이어서 다뤄보겠습니다. RouterOS VLAN 분리 가이드도 함께 보면 흐름을 잡는 데 도움이 됩니다.

    백업, DHCP/DNS, MTU/MSS, 브리지 루프, 방화벽/세션 점검까지 핵심 흐름을 한 장으로 요약한 이미지입니다.

  • [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] OpenWRT 미니PC 벤치마크: N100 vs J4125 성능 비교

    [HomeLabs] OpenWRT 미니PC 벤치마크: N100 vs J4125 성능 비교

    목차

    OpenWRT 미니PC 벤치마크: N100 vs J4125 성능 비교

    OpenWRT 미니PC 벤치마크를 찾는 분들은 대체로 비슷한 고민을 하더라고요. 인터넷 회선은 빨라졌는데, 막상 x86 라우터에 VPN이나 SQM을 얹으면 체감 속도가 뚝 떨어지는 경험 말이에요. 저도 홈랩에서 이것저것 붙여보다가 “분명 회선은 충분한데 왜 업로드할 때 게임 핑이 튀지?” 싶었던 적이 많았습니다. 그래서 이번 글에서는 Intel N100과 J4125 기반 미니PC를 OpenWRT 라우터로 실제로 써봤을 때, 특히 VPN 성능과 SQM 관점에서 어떤 차이가 나는지 정리해봤습니다.

    결론부터 짧게 말하면, 둘 다 라우터로 충분히 쓸 수 있어요. 다만 WireGuard(와이어가드) 같은 가벼운 VPN, CAKE(케이크) 기반 SQM, 그리고 기가급 회선 근처까지 욕심내는 순간에는 N100 쪽이 훨씬 여유가 있더라고요. 반대로 J4125는 이미 검증된 저전력 홈서버 플랫폼이라, 회선 속도와 요구사항이 명확하면 여전히 괜찮습니다.

    OpenWRT 미니PC 벤치마크용 x86 라우터 전체 아키텍처 이미지

    WAN, LAN, VPN 클라이언트, SQM 큐잉 흐름이 한눈에 보이는 홈랩 네트워크 개요 이미지입니다.

    왜 OpenWRT 미니PC 벤치마크가 중요한가

    공유기 스펙표만 보면 다 비슷해 보여도, 실제 병목은 전혀 다른 데서 생깁니다. 쉽게 말해 라우터는 단순히 패킷만 전달하는 박스가 아니라, NAT(네트워크 주소 변환), Firewall(방화벽), QoS(서비스 품질 제어), VPN 암복호화를 동시에 처리하는 작은 서버거든요. 여기서 CPU 여유가 부족하면 다운로드 속도보다 먼저 지연시간(latency)과 버퍼블로트(bufferbloat, 대기열 지연)가 띄게 됩니다.

    특히 홈랩 네트워크에서는 이런 경우가 많아요.

    • 재택근무 때문에 VPN을 항상 켜둔다
    • 게임이나 화상회의 때문에 핑 안정성이 중요하다
    • NAS 백업, Docker 이미지 풀, 클라우드 동기화가 동시에 돈다
    • 기본 공유기 대신 x86 라우터로 기능을 통합하고 싶다

    여기서 중요한 포인트! 회선 속도 자체보다 부하가 걸렸을 때 얼마나 덜 무너지느냐가 실제 만족도를 좌우합니다. 저도 처음엔 최고 속도만 봤는데, 실제로 써보니까 SQM 한 번 켜는 순간 CPU 체급 차이가 너무 솔직하게 드러나더라고요.

    N100과 J4125, 뭐가 다를까

    두 CPU 모두 팬리스(fanless) 미니PC에 정말 자주 들어가는 계열이에요. 다만 세대 차이가 분명합니다.

    항목 Intel N100 Intel J4125
    포지션 비교적 최신 저전력 x86 플랫폼 검증된 구세대 저전력 플랫폼
    코어 구성 4코어 4코어
    체감 특성 단일·다중 작업 모두 여유가 큼 기본 라우팅은 무난하지만 고부하 기능 동시 사용 시 한계가 빨리 옴
    추천 용도 기가급 회선, WireGuard, SQM, 여러 서비스 동시 운영 중속 회선, 기본 방화벽/NAT, 가벼운 VPN

    사실 OpenWRT에서는 코어 수보다도 패킷 처리 중 인터럽트(interrupt), 암호화, 큐잉이 얼마나 매끄럽게 도는지가 중요해요. 제가 직접 해보니 J4125는 평소엔 조용한데, 업로드가 길게 차오르거나 VPN을 겹치면 CPU 사용률이 훅 올라가는 구간이 있었습니다. 반면 N100은 같은 설정에서도 숨이 좀 더 길더라고요.

    벤치마크 전에 알아야 할 핵심 개념

    1. VPN 성능은 프로토콜 차이가 큽니다

    WireGuard(와이어가드)는 구조가 단순하고 가벼워서 x86 미니PC와 궁합이 좋아요. OpenVPN(오픈VPN)은 호환성이 넓지만 CPU 부담이 더 크게 느껴질 때가 많습니다. 그래서 같은 장비라도 “VPN이 느리다”가 아니라 “어떤 VPN을 쓰느냐”를 먼저 봐야 합니다.

    2. SQM은 속도를 깎는 기능이 아니라 지연을 다듬는 기능입니다

    SQM(Smart Queue Management, 스마트 큐 관리)은 회선 최대 속도를 살짝 양보하는 대신, 업로드/다운로드 혼잡 시 핑을 안정화하는 데 목적이 있어요. OpenWRT에서는 보통 CAKE나 fq_codel을 많이 쓰죠. 쉽게 말해, 한 사람이 업로드를 꽉 채워도 나머지 사람이 웹서핑이나 게임을 덜 불편하게 만드는 장치입니다.

    3. 벤치마크는 최고 속도보다 재현성이 중요합니다

    벤치마크를 할 때는 숫자 하나보다 조건 통제가 훨씬 중요합니다. 같은 N100이라도 NIC(네트워크 인터페이스 카드), 드라이버, MTU, IRQ 분배, Flow Offloading 여부에 따라 결과가 꽤 달라질 수 있거든요. 그래서 이 글도 “절대 수치”보다 비교 방식과 판단 기준에 초점을 맞추겠습니다.

    OpenWRT x86 라우터 테스트 구성

    제가 홈랩에서 이런 류의 비교를 할 때는 환경을 최대한 단순하게 맞춘답니다. 그래야 CPU 차이가 더 잘 보이거든요.

    1. OpenWRT x86 장비에 기본 라우팅과 방화벽만 먼저 올립니다.
    2. WAN과 LAN 링크 속도를 확인합니다.
    3. 기본 NAT 상태에서 내부 구간 iperf3로 병목이 없는지 봅니다.
    4. 그 다음 WireGuard를 올려 VPN 성능을 비교합니다.
    5. 마지막으로 SQM을 켜고 다운로드/업로드 혼잡 시 핑 변화를 봅니다.

    테스트 항목은 보통 아래 4개면 충분합니다.

    • 기본 라우팅 처리 여유
    • WireGuard 활성화 시 CPU 상승 폭
    • SQM 활성화 시 체감 지연 변화
    • VPN과 SQM을 동시에 켰을 때의 안정성

    기본 패키지 설치

    opkg update
opkg install iperf3 htop luci-app-sqm sqm-scripts wireguard-tools luci-proto-wireguard

    여기서 htop은 CPU 코어별 사용률을 보기 좋고, iperf3는 구간별 처리량 확인에 편하더라고요. 처음엔 이게 뭔가 싶었는데, 실제로 써보니까 속도 숫자보다 코어가 어느 순간 100%로 붙는지 보는 게 훨씬 유용했습니다.

    OpenWRT LuCI에서 WAN, WireGuard, SQM이 연결되는 흐름을 보여주는 설정 이미지입니다.

    실전 구현: OpenWRT에서 VPN과 SQM 구성하기

    1. WireGuard 인터페이스 생성

    LuCI에서 해도 되지만, CLI가 재현성은 더 좋습니다.

    uci set network.wg0=interface
uci set network.wg0.proto='wireguard'
uci set network.wg0.private_key='YOUR_PRIVATE_KEY'
uci add_list network.wg0.addresses='10.0.10.2/24'
uci commit network
/etc/init.d/network restart

    피어(peer) 설정은 환경마다 달라서 여기선 기본 골격만 적었어요. 중요한 건 터널이 올라온 뒤 실제 트래픽이 wg0를 타는지 확인하는 겁니다.

    wg show
ip route
logread | grep wireguard

    2. SQM 적용

    SQM은 인터페이스를 잘못 잡으면 효과가 없거나 오히려 꼬입니다. PPPoE인지 DHCP인지, 실제 WAN 디바이스가 뭔지부터 확인하세요.

    uci set sqm.eth1=queue
uci set sqm.eth1.interface='eth1'
uci set sqm.eth1.download='800000'
uci set sqm.eth1.upload='800000'
uci set sqm.eth1.qdisc='cake'
uci set sqm.eth1.script='piece_of_cake.qos'
uci set sqm.eth1.enabled='1'
uci commit sqm
/etc/init.d/sqm enable
/etc/init.d/sqm restart

    위 예시는 형식 예시입니다. 실제 속도 값은 본인 회선 실측보다 조금 낮게 잡는 게 일반적이에요. 여기서 중요한 포인트! 속도를 너무 높게 넣으면 SQM이 제 역할을 못 하고, 너무 낮게 넣으면 괜히 손해를 보게 됩니다.

    3. 테스트 실행

    iperf3 -s

    iperf3 -c SERVER_IP -P 4 -t 30
ping 1.1.1.1
top

    저는 보통 iperf3로 부하를 주면서 동시에 ping을 띄워봅니다. 이 조합이 단순하지만 꽤 정직합니다. SQM이 잘 먹으면 최고 속도는 약간 덜 나와도 핑이 덜 튀고, CPU 한계에 걸리면 라우터가 바로 표정을 바꾸거든요.

    체감 기준 벤치마크: N100 vs J4125

    숫자를 지어내는 건 의미가 없으니, 제가 실제로 장비를 고를 때 보는 체감 지표로 정리해봤습니다.

    비교 항목 N100 J4125 실사용 해석
    기본 NAT/방화벽 여유 있음 무난함 둘 다 일반 가정용 라우터로는 충분
    WireGuard VPN 확실히 유리 가능하지만 여유 차이 존재 VPN 상시 사용이면 N100 쪽이 편함
    OpenVPN 상대적으로 낫지만 부담은 큼 CPU 압박이 빨리 옴 OpenVPN 위주면 체급 차이가 더 잘 보임
    SQM + 고부하 업로드 안정적 한계 구간이 빨리 보임 핑 안정성이 중요하면 N100 선호
    멀티롤 운영 유리 보수적으로 접근 필요 AdGuard Home, 모니터링 등 같이 돌리면 차이 남

    제가 직접 해보니 N100은 “아직 좀 더 올려도 되겠는데?”라는 느낌이 있었고, J4125는 “여기까진 괜찮은데 둘을 같이 하면 아슬아슬하네”라는 구간이 빨리 왔습니다. 특히 VPN 성능과 SQM을 동시에 요구하는 홈랩 네트워크에서는 그 차이가 더 또렷했어요.

    반대로 냉정하게 말하면, 회선 속도가 아주 높지 않고 VPN도 가끔만 쓴다면 J4125가 완전히 뒤처진다고 보긴 어렵습니다. 중고 시장 접근성이나 검증된 플랫폼이라는 장점도 있으니까요. 다만 지금 새로 산다면 저는 N100 쪽으로 갑니다. 이유는 단순합니다. 여유는 결국 안정성으로 돌아오거든요.

    OpenWRT 미니PC 벤치마크에서 N100과 J4125 성능 비교 대시보드 이미지

    부하 테스트 중 CPU 사용률과 핑 변화를 비교한 성능 검증 대시보드 이미지입니다.

    ⚠️ 실제로 많이 겪는 문제와 해결법

    1. SQM 켰는데 체감이 없다

    가장 흔한 원인은 인터페이스 지정 오류입니다. 예를 들어 실제 WAN이 pppoe-wan인데 eth1에 걸어두면 기대한 효과가 안 나와요.

    ifstatus wan
ubus call system board
logread | grep sqm

    해결: 실제 트래픽이 지나가는 인터페이스를 정확히 확인하고 다시 적용합니다.

    2. VPN은 붙는데 속도가 이상하게 안 나온다

    MTU(최대 전송 단위) 문제나 라우팅 누락일 가능성이 커요. 특히 WireGuard는 터널이 올라와도 경로가 꼬이면 성능이 이상하게 나옵니다.

    해결: wg show, ip route, tcpdump 순으로 확인하세요. 저도 처음엔 키만 맞으면 다 되는 줄 알았는데, 실제 병목은 라우팅에서 나오는 경우가 꽤 많았더라고요.

    3. 속도는 잘 나오는데 게임 핑이 튄다

    이건 대개 업로드 혼잡입니다. 다운로드보다 업로드 포화가 지연시간에 더 치명적일 때가 많거든요.

    해결: SQM 업로드 값을 현실적으로 다시 잡고, 테스트할 때는 다운로드와 업로드를 각각 따로 꽉 채워보세요. 둘 중 어디서 무너지는지 먼저 알아야 합니다.

    4. 팬리스 미니PC인데 발열이 걱정된다

    이건 CPU보다 케이스 설계와 설치 위치 영향이 커요. 같은 N100이어도 밀폐된 장 안에 넣어두면 장시간 VPN 부하에서 쓰로틀링(열로 인한 성능 저하)이 생길 수 있습니다.

    해결: 통풍 공간을 확보하고, 가능하면 장시간 부하 테스트를 해보세요. 짧은 벤치만 보고 끝내면 실제 운영 때 다르게 보일 수 있습니다.

    검증 포인트: 무엇을 보면 성공인가

    OpenWRT 미니PC 벤치마크에서 제가 보는 성공 기준은 아래와 같습니다.

    1. 기본 NAT 상태에서 CPU가 과도하게 치솟지 않는다.
    2. WireGuard 활성화 후에도 체감 웹서핑과 화상회의가 안정적이다.
    3. SQM을 켠 뒤 부하 상황에서 핑이 눈에 띄게 덜 튄다.
    4. VPN과 SQM을 동시에 써도 재부팅이나 세션 끊김 없이 버틴다.

    여기서 중요한 건 최고 속도 스크린샷 한 장이 아니에요. 30분, 1시간 운영했을 때도 안정적인가가 더 중요하죠. 홈랩 네트워크는 벤치보다 운영 시간이 길기 때문에, 잠깐 빠른 것보다 오래 조용한 구성이 훨씬 값집니다.

    정리: 어떤 사람에게 N100, 어떤 사람에게 J4125가 맞나

    • N100 추천: 기가급 회선, WireGuard 상시 사용, SQM 적극 활용, 여러 네트워크 서비스를 함께 돌릴 분
    • J4125 추천: 기본 라우팅 중심, 중간급 회선, 가벼운 VPN, 비용 효율과 검증된 플랫폼이 중요한 분

    제 결론은 이렇습니다. x86 라우터를 처음 만들고 앞으로 2~3년 이상 쓸 생각이라면 N100이 훨씬 편해요. 성능 그 자체보다 설정 실수나 트래픽 변동을 버텨주는 여유가 있어서죠. 반면 이미 J4125 장비를 갖고 계시다면 무조건 교체부터 할 필요는 없습니다. 다만 VPN 성능과 SQM을 둘 다 진하게 쓰는 순간 업그레이드 이유가 분명해질 가능성이 커요.

    OpenWRT 미니PC 벤치마크 기반 N100과 J4125 선택 가이드 이미지

    회선 속도, VPN 사용량, SQM 필요 여부에 따라 장비를 고르는 요약 인포그래픽입니다.

    FAQ: 많이 받는 질문

    Q1. OpenWRT 미니PC 벤치마크에서 제일 먼저 볼 건 뭔가요?

    CPU 자체도 중요하지만, 실제로는 NIC 안정성, 드라이버, SQM 사용 여부, VPN 프로토콜을 같이 봐야 해요. 같은 CPU라도 체감이 달라집니다.

    Q2. WireGuard와 OpenVPN 중 뭐가 더 낫나요?

    대부분의 홈랩 환경에서는 WireGuard 쪽이 더 가볍고 다루기 편한 편입니다. 다만 회사 정책이나 특정 서비스 호환성 때문에 OpenVPN이 필요한 경우도 있어요.

    Q3. SQM은 꼭 켜야 하나요?

    혼자 쓰는 회선보다 여러 기기가 동시에 붙는 집에서 효과를 더 체감합니다. 특히 업로드가 자주 차는 환경이라면 거의 필수에 가까우니까요.

    마무리

    이번 글은 OpenWRT 미니PC 벤치마크를 숫자 놀음보다 실제 선택 기준에 맞춰 정리해봤어요. 저도 처음엔 CPU 이름만 보고 골랐다가, 막상 홈랩 네트워크에 VPN과 SQM을 얹어보니 “아, 라우터는 여유가 중요하구나”를 제대로 느꼈습니다. 드디어 됐다! 싶은 순간은 대개 최고 속도보다, 누가 업로드를 꽉 채워도 집안 전체가 조용할 때 오더라고요.

    다음 글에서는 OpenWRT x86에서 IRQ 튜닝, Flow Offloading, CAKE 세부 파라미터를 좀 더 깊게 다뤄볼 예정입니다. 이전에 정리한 홈랩 라우터 구성 글과 함께 보시면 장비 선택부터 튜닝까지 흐름이 더 잘 잡히실 거예요.