Intel N100 홈서버 운영 데이터 로그 정리 : 전력·온도·Docker 상태 기록하기
도입
금요일에는 Intel N100 홈서버에서 Docker와 Proxmox의 상태를 어떤 방식으로 확인하는지 정리했어요. CPU와 메모리, 디스크 사용량, 그리고 Docker 컨테이너들의 상태를 일차적으로 점검하는 날이었죠. 토요일이 되면 이렇게 모아둔 관찰 결과를 한 주 동안의 운영 데이터로 정리하는 데 더 집중하게 됩니다.
홈서버는 한 번 설치해서 계속 켜두기만 하면 되는 장비처럼 느껴질 수 있지만, 막상 운영을 해보면 작은 변화들이 계속해서 쌓입니다. 예를 들어, 전력 사용량이 조금씩 변하고 CPU 온도가 특정 시간에 올라가기도 하죠. 또, Docker 로그나 백업 파일이 차곡차곡 늘어나면서 디스크 공간도 서서히 줄어듭니다.
이번 글에서는 Intel N100 홈서버를 직접 운용하면서 전력 사용량, 온도, Docker 상태, 디스크 용량, 그리고 백업 파일 상태를 어떤 기준으로 꾸준히 기록해 왔는지 정리해보았습니다. 그 과정에서 느낀 점은, 보기 좋은 대시보드를 만들기보다 같은 기준으로 계속해서 기록을 남기는 것이 훨씬 더 중요하다는 것이었습니다.

※ 다이어그램은 운영 환경 설계를 바탕으로 AI 도구를 활용해 제작했으며, 최종 구성과 내용은 운영자가 직접 검수했습니다.
출처: 디지털 장난감
본문
운영 데이터는 문제를 늦게 발견하지 않기 위한 기준이었다
홈서버는 겉보기에는 조용하고 문제 없어 보여도, 내부에서는 로그가 차곡차곡 쌓이고 백업 파일이 계속 늘어나기도 합니다. 또 어떤 컨테이너는 이유 없이 반복해서 재시작되는 경우도 생길 수 있습니다. 겉으로 평온해 보여도, 속에서는 이런 변화들이 조금씩 일어나고 있는 셈입니다.
토요일에 정리한 운영 데이터는 단순히 "지금 문제가 있나?"를 확인하려는 목적보다는, 다음 주에 참고할 수 있는 기준을 만드는 데 더 가까웠습니다. 이렇게 기준이 마련되어야 평소와 비교해서 전력 사용이 늘었는지, 온도가 올랐는지, 디스크가 더 빨리 늘어나는지를 쉽게 확인할 수 있습니다.
- 전력 사용량이 평소보다 증가했는지 확인
- CPU 온도가 장시간 높게 유지되는지 확인
- Docker 컨테이너가 반복적으로 재시작되는지 확인
- 디스크 사용량이 일주일 사이 얼마나 늘었는지 확인
- 백업 파일이 정상적으로 생성되고 있는지 확인
전력 사용량은 같은 시간대 기준으로 비교했다
Intel N100은 주로 저전력 시스템에 많이 사용됩니다. 하지만 실제로 소모하는 전기는 어떤 작업을 하느냐에 따라 달라집니다. 예를 들어, 아무것도 하지 않고 대기하는 동안에는 전력 사용이 낮지만, Docker 업데이트나 미디어 스캔, 백업 압축처럼 다양한 작업을 하면 그만큼 전기 소모가 더 많아집니다. 이런 식으로 운영 상황에 따라 전력 흐름이 달라지는 점을 염두에 두어야 합니다.
그래서 전력 기록을 한 번의 수치만 보는 것보다, 같은 시간대의 데이터를 반복해서 살펴보는 게 더 의미 있게 느껴졌어요. 예를 들어 밤에는 자동화 작업이 별로 없어서 자원 사용이 줄고, 백업이 이뤄지는 시간대에는 디스크와 CPU 사용량이 같이 올라갈 때가 많았습니다.
| 상태 | 기록 목적 | 운영 메모 |
|---|---|---|
| Idle | 기준 전력 확인 | 서비스만 켜진 평상시 기준값 |
| 일반 운영 | Docker 서비스 동작 중 전력 확인 | n8n, Reverse Proxy, 관리 도구 가동 상태 |
| 부하 작업 | 전력 상승 구간 확인 | Jellyfin 스캔, 이미지 업데이트, 백업 압축 |
| 백업 시간 | CPU·디스크 동시 부하 확인 | 작업 시간이 겹치지 않도록 조정 필요 |
온도 기록은 순간 최고값보다 유지 흐름이 훨씬 더 중요했다
CPU 온도는 잠깐씩 오를 수 있습니다. 하지만 홈서버를 운영할 때는 이 온도가 오랜 시간 동안 계속 높게 유지되는지, 그리고 부하가 끝난 뒤에 다시 정상 범위로 잘 내려오는지가 더 중요합니다.
# 센서 정보 확인
sensors
sensors 명령어는 환경에 따라 별도 패키지 설치가 필요할 수 있습니다. Debian이나 Ubuntu 계열에서는 보통 lm-sensors 패키지를 통해 확인합니다.
# Debian/Ubuntu 계열 예시
sudo apt install lm-sensors
sensors
작은 미니 PC는 어디에 두는지, 주변 온도나 먼지, 통풍 상태에 따라 열이 퍼지는 방식이 달라집니다. 그래서 온도 기록을 볼 때 절대값 자체만 보는 것보다는, 평소와 비교해서 얼마나 달라졌는지 살펴보는 게 훨씬 도움이 됐습니다.
Docker 상태는 실행 여부보다 반복 패턴을 봤다
Docker 컨테이너가 Up 상태라고 해서 모든 것이 안정적인 것은 아닙니다. 실제 운영에서는 컨테이너가 살아 있어도 내부 서비스가 느리거나, 특정 컨테이너가 짧은 주기로 재시작되는 경우가 있습니다.
# Compose 기준 컨테이너 상태
docker compose ps
# 전체 컨테이너 상태
docker ps -a
# 컨테이너별 리소스 사용량
docker stats
토요일 데이터 정리에서는 특히 Restarting 상태가 반복되는지, Exited 상태로 멈춘 컨테이너가 있는지, 특정 컨테이너의 메모리 사용량이 계속 증가하는지 확인했습니다.
docker compose ps: 서비스 단위 상태 확인docker ps -a: 종료된 컨테이너 포함 전체 상태 확인docker stats: 컨테이너별 CPU·메모리 사용량 확인docker logs: 특정 컨테이너 로그 확인
디스크 사용량은 로그와 백업 때문에 계속 증가했다
홈서버를 며칠만 사용해도 디스크 용량이 조금씩 차오르는 걸 느낄 수 있습니다. 그 이유는 Docker 이미지나 컨테이너 로그, journal 로그, 백업 파일, 임시 파일 등이 하나둘씩 쌓이기 때문입니다.
# 전체 디스크 사용량
df -h
# Docker 이미지·컨테이너·볼륨 사용량
docker system df
# systemd journal 로그 사용량
journalctl --disk-usage
# 백업 파일 확인
ls -lh /backup
여기서 중요한 점은 곧바로 정리를 시작하지 않는 것이었습니다. 먼저 각 항목이 얼마나 늘어났는지 확인하고, 그 결과를 바탕으로 정리 기준을 세우는 편이 훨씬 안전했죠. 특히 Docker 볼륨 같은 경우, 실제 서비스 데이터가 포함되어 있을 수 있기 때문에 함부로 삭제해서는 안 됩니다.
백업 파일은 생성 여부와 크기를 함께 봐야 했다
백업은 단순히 “파일이 생겼다”로 끝나는 일이 아니었습니다. 백업 파일이 제대로 만들어졌는지, 파일 용량이 너무 작거나 크지는 않은지, 그리고 꼭 필요한 설정 파일과 데이터 디렉터리까지 잘 들어 있는지 하나하나 직접 확인해야 했습니다.
# 백업 파일 목록과 크기 확인
ls -lh /backup
# 백업 디렉터리 전체 크기 확인
du -sh /backup
예를 들어, Docker Compose로 홈서버를 구성했다면 compose 파일, 환경 변수 파일, 서비스별 데이터 디렉터리, Reverse Proxy 설정, 자동화 도구의 데이터 경로 등이 백업 대상에 들어가는지 꼭 확인해보는 게 좋습니다.
주간 기록은 표로 남기는 편이 가장 오래 갔다
처음에는 복잡한 대시보드를 만들어보고 싶었어요. 하지만 막상 꾸준히 기록하려다 보니, 결국 가장 편한 건 단순한 표였습니다. 같은 항목을 같은 순서로 써 놓으니, 다음 주에 비교하기도 쉬웠고, 언제부터 변화가 생겼는지도 한눈에 알 수 있었죠.
| 기록 항목 | 확인 방법 | 비교 기준 |
|---|---|---|
| 전력 사용량 | 와트미터 또는 스마트 플러그 | Idle / 일반 운영 / 백업 시간 비교 |
| CPU 온도 | sensors |
장시간 유지 온도와 부하 후 회복 흐름 |
| 메모리 상태 | free -h |
swap 사용 증가 여부 |
| Docker 상태 | docker compose ps |
Restart 반복 또는 Exited 상태 |
| Docker 리소스 | docker stats |
특정 컨테이너 CPU·RAM 급증 여부 |
| 디스크 사용량 | df -h |
일주일간 증가폭 |
| Docker 저장소 | docker system df |
이미지·볼륨 누적 상태 |
| 백업 파일 | ls -lh /backup |
파일 생성 여부와 크기 변화 |
운영 로그
아래 표는 토요일마다 점검하는 Intel N100 홈서버 운영 데이터 루틴을 정리한 것입니다. 실제 수치는 장비의 구성이나 실내 온도, 서비스 종류, SSD 용량 등에 따라 달라질 수 있으니 참고해 주세요.
| 점검 구간 | 확인 항목 | 운영 판단 |
|---|---|---|
| 평상시 | 전력, CPU 온도, 메모리 | 기준값 확보 |
| 서비스 운영 중 | Docker 상태, 컨테이너 리소스 | 특정 서비스 부하 확인 |
| 백업 이후 | 백업 파일, 디스크 증가량 | 백업 정상 생성 여부 확인 |
| 주간 정리 | Docker system df, journal 사용량 | 정리 필요성 판단 |
| 다음 주 계획 | 증가 추세, 반복 오류 | 최적화 대상 선정 |
에디터의 해석 노트 (Editor's Lab Note)
- 토요일 기록의 핵심은 “지금 정상인가”보다 “다음 주에 비교할 기준이 있는가”였습니다.
- N100 홈서버는 순간 성능보다 장시간 안정성과 변화 추세를 보는 편이 더 중요했습니다.
- Docker 로그와 백업 파일은 생각보다 빠르게 증가하므로, 정리보다 먼저 기록이 필요했습니다.
- 복잡한 모니터링 도구보다 같은 기준으로 반복 기록하는 습관이 운영 안정성에 더 도움이 됐습니다.
참고 링크 (References)
트러블슈팅
문제: 홈서버는 정상적으로 동작하지만 어떤 데이터를 기록해야 할지 불명확함
홈서버를 처음 관리할 때는 서비스가 정상적으로 접속되는지만 확인하고 그냥 지나치는 경우가 많습니다. 그런데 시간이 흘러 로그나 백업 파일, Docker 이미지, 그리고 컨테이너 볼륨 등이 점점 쌓이다 보면, 문제가 어디서부터 시작됐는지 찾아내기 더 어려워질 수 있습니다.
확인: 전력, 온도, Docker 상태, 디스크 사용량, 백업 파일을 같은 기준으로 기록
# CPU / 메모리 상태
htop
free -h
# 온도 확인
sensors
# Docker 상태
docker compose ps
docker stats
# 디스크와 Docker 사용량
df -h
docker system df
# 로그와 백업 확인
journalctl --disk-usage
ls -lh /backup
원인: 운영 상태는 확인하고 있지만, 비교할 기준값을 남기지 않음
해결: 토요일마다 같은 항목을 반복 기록하고, 다음 주와 비교할 수 있는 기준값을 만든다
기록은 굳이 복잡하게 남길 필요가 없습니다. 오히려 같은 명령어나 항목이라도 반복해서 꼼꼼하게 적어두는 것이 더 중요합니다. 이렇게 모아놓은 기록들은 나중에 문제가 생겼을 때 원인을 추적하는 데 큰 도움이 됩니다.
마무리
Intel N100 홈서버를 운영하다 보면 토요일은 ‘새로운 기능을 추가하는 날’이라기보다는, 차라리 한 주 동안 모아둔 데이터를 정리하는 날에 가깝게 느껴집니다. 평소 전력이나 온도, Docker 상태, 디스크 사용량, 백업 상태 같은 것들을 꼼꼼히 기록해두면, 홈서버가 평소와 다르게 반응하는 시점도 자연스럽게 발견할 수 있었습니다.
홈서버를 운영하면서 느낀 건, 결국 기록이 쌓이는 과정의 반복이라는 점이었습니다. 한 번의 수치보다는, 동일한 기준으로 데이터를 다시 들여다볼 수 있다는 게 훨씬 더 중요했죠. 일요일마다 이렇게 모아진 운영 데이터를 바탕으로 2주차의 전체 흐름을 돌아보고, 다음 주엔 어떤 방향으로 운영해 볼지 정리해두려 합니다.
'코어-테크 : 트러블 슈팅 노트' 카테고리의 다른 글
| Docker Compose 운영 구조 다시 정리하기 : Intel N100 홈서버 서비스 그룹화와 유지관리 흐름 (0) | 2026.05.25 |
|---|---|
| Intel N100 홈서버 2주차 회고 : Proxmox·Docker 운영 안정화 (0) | 2026.05.24 |
| Intel N100 홈서버 운영 모니터링 : Docker·Proxmox 상태 기록과 리소스 관찰하기 (0) | 2026.05.22 |
| Intel N100 홈서버 운영 최적화 : Proxmox + Docker 자동 재시작과 로그 관리 정리 (0) | 2026.05.21 |
| Intel N100 홈서버 트러블슈팅: VT-x와 가상화 옵션 문제 해결하기 (0) | 2026.05.20 |