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

목차

• Frigate NVR 녹화 끊김이 생기는 구조부터 이해해봅시다
• Frigate 디버깅 순서: 제가 먼저 확인하는 체크리스트
• 실전 구현 1: 로그와 자원부터 확인합니다
• 자원 병목을 빠르게 비교하는 기준
• 실전 구현 2: 카메라 스트림과 설정을 분리해서 봅니다
• 실전 구현 3: 하드웨어 가속과 저장소를 점검합니다
• ⚠️ 실제로 자주 만난 Frigate 녹화 끊김 문제와 해결법
• 1. 특정 시간대에만 녹화 끊김이 생기는 경우
• 2. 녹화는 되는데 감지 순간만 프레임이 떨어지는 경우
• 3. 컨테이너 재시작 후부터 녹화 경로 오류가 나는 경우
• 4. 카메라 한 대만 유독 불안정한 경우
• 검증: Frigate 성능 개선 후 무엇을 보면 될까요?
• 정리: Frigate NVR 녹화 끊김은 한 군데만 보면 잘 안 잡힙니다
• 자주 묻는 질문
• Q1. CPU만 낮추면 Frigate 디버깅이 끝난 걸까요?
• Q2. Frigate NVR 녹화 끊김이 있을 때 가장 먼저 볼 항목은 뭔가요?
• Q3. 무조건 detect 해상도를 낮추면 되나요?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

docker ps

docker logs --tail=200 frigate

docker stats frigate

df -h

iostat -xz 1

free -m

top

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

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

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

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

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

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

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

cameras:
  front_door:
    ffmpeg:
      inputs:
        - path: rtsp://USER:PASS@192.168.1.10:554/stream1
          roles:
            - record
        - path: rtsp://USER:PASS@192.168.1.10:554/stream2
          roles:
            - detect
    detect:
      width: 1280
      height: 720
      fps: 5
    record:
      enabled: true

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

1. record는 화질 보존이 우선입니다.
2. detect는 낮은 부담으로 안정성이 우선입니다.
3. 모든 역할을 같은 고해상도 스트림 하나로 몰아주면 CPU가 쉽게 올라갑니다.

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

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

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

ffplay rtsp://USER:PASS@192.168.1.10:554/stream1

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

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

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

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

ls /dev/dri

vainfo

docker exec -it frigate ls /dev/dri

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

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

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

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

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

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

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

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

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

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

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

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

ls -al /path/to/frigate/media

id

docker inspect frigate

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

자주 묻는 질문

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

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

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

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

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

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

📚 함께 읽으면 좋은 글

• 소규모 홈랩 랙 구성 베스트 프랙티스: 공간 효율과 소음 관리 체크리스트
• Proxmox UPS 연동: NUT 설정으로 홈랩 자동 종료 구성하기
• Frigate NVR 하드웨어 체크리스트: 최적 성능을 위한 선택