Intel N100 홈서버 운영 최적화 : Proxmox + Docker 자동 재시작과 로그 관리 정리

 

 

※ 이 글은 운영자가 직접 홈서버를 운영하며 실험한 경험과 공개된 자료를 참고해 썼습니다. 문장 정리와 구성에는 AI 도구의 도움을 약간 받았지만, 마지막 검토와 내용 확인은 모두 운영자가 직접 했습니다.

Intel N100 홈서버 운영 최적화: Proxmox + Docker 자동 재시작과 로그 관리 정리

도입

월요일에는 Proxmox VE의 가상화 구조를 정리했고, 화요일에는 VM과 Docker의 역할을 어떻게 나눌지 설계해봤어요. 수요일에는 VT-x와 KVM 가속이 잘 동작하는지 점검했죠. 이제 목요일이 되면, 설치와 기본 구성을 마친 후 실제로 24시간 홈서버를 안정적으로 운영하기 위해 어떤 점을 최적화해야 하는지 살펴보게 됩니다.

홈서버를 설치했다고 해서 곧바로 안정적으로 운영되는 것은 아니었습니다. 재부팅을 하면 일부 컨테이너가 자동으로 실행되지 않거나, Docker 로그가 계속 쌓이는 문제가 있었고, Proxmox VM 안에서는 메모리 사용량이 조금씩 늘어나는 현상도 보였습니다. 그래서 이번 글에서는 Proxmox와 Docker를 함께 사용할 때 경험했던 자동 재시작 설정, 로그 관리, 리소스 점검 기준 등을 직접 운영하면서 확인한 내용 위주로 정리해보았습니다.

Intel N100 홈서버에서 Proxmox와 Docker를 장시간 안정적으로 운영하기 위한 자동 재시작 정책, 로그 관리, 리소스 점검 흐름입니다.

출처 : 디지털 장난감

※ 다이어그램은 운영 환경 설계를 바탕으로 AI 도구를 활용해 제작했으며, 최종 구성과 내용은 운영자가 직접 검수했습니다.

본문

설치보다 어려운 것은 계속 살아 있게 만드는 일이었다

Proxmox VE에 Ubuntu VM을 설치하고 그 안에서 Docker Compose 서비스를 올리는 과정은 생각보다 빠르게 마칠 수 있습니다. 하지만 실제로 운영할 때는 서비스가 한 번 잘 실행됐는지보다는, 예기치 못한 문제가 생겨도 제대로 다시 복구되는지가 더 중요하다는 걸 느꼈습니다.

특히 전원을 재부팅하거나 Docker 이미지를 업데이트하고, VM을 다시 시작하거나 네트워크 지연이 생기는 등 여러 상황이 겹치면 컨테이너가 모두 제대로 동작하지 않거나, 일부 서비스만 멈춰 있는 일이 생길 수 있습니다. 홈서버를 24시간 운영할 때는 이런 작은 복구 과정을 미리 정리해 두는 게 꼭 필요하다고 느꼈습니다.

• 재부팅 후 일부 컨테이너가 자동으로 올라오지 않는 문제
• 컨테이너는 실행 중이지만 Web UI 응답이 느려지는 문제
• Docker 로그와 journal 로그가 계속 누적되는 문제
• 사용하지 않는 이미지와 볼륨이 SSD 공간을 차지하는 문제
• 메모리 사용량이 천천히 증가해 swap 사용 가능성이 생기는 문제

Docker restart 정책은 서비스 성격에 따라 달라야 했다

Docker Compose에서 restart 정책이 겉으로는 단순한 선택지처럼 보일 수 있지만, 실제로 서비스를 운영하다 보면 복구 방식에 큰 영향을 주곤 합니다. 모든 서비스에 똑같은 정책을 적용하는 것보다는, 각각의 서비스 특성에 맞게 정책을 다르게 정하는 게 훨씬 현실적이었습니다.

정책	의미	운영 판단
no	자동 재시작 없음	테스트용 컨테이너에만 적합
always	중지되어도 계속 재시작	핵심 서비스에는 유용하지만 의도적 중지도 다시 올라올 수 있음
unless-stopped	운영자가 직접 중지하지 않은 경우 자동 재시작	홈서버 운영에서 가장 무난한 기본값
on-failure	오류 종료 시에만 재시작	실험용 작업이나 배치성 컨테이너에 적합

처음에는 restart 정책에 대해 별다른 고민 없이 컨테이너를 띄웠습니다. 그런데 Proxmox VM을 한번 재부팅하고 나니 몇몇 서비스가 자동으로 복구되지 않는 상황이 생겼습니다. 이 경험을 통해, 운영 환경에서는 최소한의 자동 복구 정책이 꼭 필요하다는 걸 깨달았습니다.

services:
  nginx-proxy-manager:
    image: jc21/nginx-proxy-manager:latest
    restart: unless-stopped

  n8n:
    image: n8nio/n8n:latest
    restart: unless-stopped

  jellyfin:
    image: jellyfin/jellyfin:latest
    restart: unless-stopped

always도 강력하긴 하지만, 홈서버를 운영할 때는 일부러 중단시킨 서비스까지 자동으로 다시 실행되는 게 오히려 불편하게 느껴질 때가 있습니다. 그래서 기본 설정은 unless-stopped로 두고, 꼭 필수로 유지해야 하는 핵심 서비스만 따로 골라 판단하는 방식이 훨씬 더 수월하게 느껴졌습니다.

컨테이너 상태는 Up만 보면 부족했다

docker compose ps에서 컨테이너가 Up 상태라고 해서 무조건 정상적으로 운영되고 있다고 말하기는 어렵습니다. 컨테이너 자체는 살아 있을 수 있지만, 그 안의 애플리케이션이 응답하지 않거나 재시작이 계속 늘어나는 경우도 있습니다.

# Compose 기준 컨테이너 상태 확인
docker compose ps

# 전체 컨테이너와 종료된 컨테이너 확인
docker ps -a

# 컨테이너별 실시간 리소스 확인
docker stats

특히 N100 홈서버에서는 CPU 성능보다 메모리와 디스크 I/O 흐름이 먼저 체감되는 경우가 있었습니다. docker stats로 특정 컨테이너의 CPU, 메모리 사용량이 갑자기 올라가는지 확인하고, Proxmox Web UI에서 VM 전체 리소스도 함께 보는 방식이 안정적이었습니다.

로그는 문제 해결 도구이면서 동시에 저장소 압박 요인이다

로그는 장애 원인을 파악할 때 꼭 필요합니다. 하지만 홈서버처럼 NVMe나 SSD처럼 저장 공간이 한정된 경우, 로그 파일들이 오히려 저장소를 압박하는 원인이 될 수 있습니다. 처음 며칠 동안은 별로 티가 나지 않지만, Docker 로그나 systemd journal, 그리고 각종 서비스 로그가 한꺼번에 쌓이다 보면 예상보다 빠르게 공간을 잡아먹게 됩니다.

# Docker 이미지, 컨테이너, 볼륨 사용량 확인
docker system df

# systemd journal 로그 사용량 확인
journalctl --disk-usage

# 특정 컨테이너 로그 확인
docker logs 컨테이너이름 --tail=100

여기서 중요한 것은 “로그를 무조건 지우는 것”이 아닙니다. 로그를 너무 빨리 지우면 문제 원인을 찾기 어렵고, 너무 오래 쌓아두면 저장소가 부족해집니다. 그래서 운영 기준을 정해두는 것이 필요했습니다.

Docker 로그 회전 설정을 검토했다

Docker는 기본 로그 드라이버로 json-file을 사용하는 경우가 많습니다. 별도 설정 없이 오래 운영하면 컨테이너 로그 파일이 계속 커질 수 있습니다. 그래서 장기 운영을 생각한다면 로그 회전 설정을 검토하는 편이 좋습니다.

{
  "log-driver": "json-file",
  "log-opts": {
    "max-size": "10m",
    "max-file": "3"
  }
}

위 설정은 예시입니다. 실제 적용은 /etc/docker/daemon.json에 반영한 뒤 Docker 서비스를 재시작해야 합니다. 다만 운영 중인 서비스가 있다면 곧바로 적용하기보다, 먼저 백업과 현재 컨테이너 상태를 확인한 뒤 진행하는 편이 안전합니다.

# Docker 설정 변경 후 재시작 예시
sudo systemctl restart docker

이 명령을 실행하면 컨테이너에 영향을 줄 수 있기 때문에, 특히 원격으로 작업할 때는 각별히 신경 써야 합니다. 홈서버를 운영하고 있다면, 설정을 바꾸기 전에 먼저 어떤 서비스에 영향이 갈지부터 확인하는 것이 중요합니다.

사용하지 않는 Docker 이미지와 볼륨은 조심해서 정리해야 했다

Docker를 운영하다 보면 사용하지 않는 이미지, 중지된 컨테이너, dangling image, 오래된 볼륨이 쌓입니다. 이때 docker system prune 명령어가 떠오르지만, 홈서버에서는 조심해서 사용해야 합니다.

# 사용량 먼저 확인
docker system df

# 사용하지 않는 이미지, 컨테이너, 네트워크 정리
docker system prune

# 볼륨까지 포함한 정리는 더 주의
docker system prune --volumes

특히 --volumes 옵션은 실제 서비스 데이터가 들어 있는 볼륨까지 영향을 줄 수 있으므로, 운영 환경에서는 매우 신중하게 사용해야 합니다. 디지털 장난감 운영 기준에서는 “정리 명령어를 먼저 실행”하기보다, docker system df로 증가 추세를 보고 필요한 항목만 정리하는 방향이 더 안전했습니다.

메모리와 swap은 조용히 확인해야 하는 지표였다

Intel N100 홈서버는 저전력 장비이기 때문에 서비스 수를 조금씩 늘리다 보면 메모리 여유가 먼저 줄어들 수 있습니다. 컨테이너는 가볍게 느껴지지만, 여러 개가 동시에 실행되면 VM 내부 메모리를 꾸준히 사용합니다.

# 메모리 상태 확인
free -h

# 프로세스별 사용량 확인
htop

# 컨테이너별 메모리 사용량 확인
docker stats

swap이 조금 사용된다고 해서 반드시 문제는 아니지만, 평소보다 swap 사용량이 계속 증가한다면 메모리 압박이 시작된 신호일 수 있습니다. 특히 n8n, Jellyfin, 데이터베이스류 컨테이너는 장시간 운영하면서 메모리 사용량을 주기적으로 확인하는 것이 좋았습니다.

운영 로그

아래 표는 Proxmox와 Docker를 함께 운영하면서 목요일 기준으로 정리한 최적화 점검 항목입니다. 실제 기준값은 장비 사양, RAM 용량, SSD 구성, 운영 서비스 수에 따라 달라질 수 있습니다.

점검 항목	확인 방법	운영 기준
자동 재시작 정책	docker inspect, compose 파일 확인	운영 서비스는 unless-stopped 중심
컨테이너 상태	docker compose ps	Restart 반복 여부 확인
컨테이너 리소스	docker stats	CPU/RAM 급증 컨테이너 확인
Docker 용량	docker system df	이미지·볼륨 증가 추세 확인
journal 로그	journalctl --disk-usage	시스템 로그 누적량 확인
메모리 상태	free -h, htop	swap 사용 증가 여부 확인
VM 전체 리소스	Proxmox Web UI	VM별 CPU/RAM/디스크 사용량 비교

에디터의 해석 노트 (Editor's Lab Note)

• 이번 목요일의 핵심은 “서비스를 실행하는 것”보다 “서비스가 다시 살아나는 구조를 만드는 것”이었습니다.
• restart 정책은 단순 편의 기능이 아니라 홈서버 복구 흐름의 일부로 봐야 했습니다.
• 로그는 문제 해결에 꼭 필요하지만, 장기 운영에서는 SSD 공간을 압박할 수 있는 요소였습니다.
• N100 환경에서는 CPU보다 메모리, 로그, Docker 볼륨 증가 추세를 꾸준히 보는 것이 더 실용적이었습니다.

참고 링크 (References)

1. Docker Compose restart policy reference
2. Docker logging configuration
3. Docker system df reference
4. journalctl manual
5. Proxmox VE Documentation

트러블슈팅

문제: 재부팅 후 일부 Docker 서비스가 자동으로 복구되지 않거나 로그가 과도하게 누적됨

Proxmox VM은 정상적으로 올라왔지만, VM 내부 Docker 서비스 중 일부가 자동으로 시작되지 않거나 특정 컨테이너 로그가 계속 쌓여 디스크 사용량이 증가하는 상황이 생길 수 있습니다.

확인: restart 정책, 컨테이너 상태, 로그 사용량, Docker 용량을 함께 점검

# 컨테이너 상태
docker compose ps

# 컨테이너별 리소스 사용량
docker stats

# Docker 용량 확인
docker system df

# journal 로그 사용량 확인
journalctl --disk-usage

# 메모리 상태 확인
free -h

원인: restart 정책 미설정, 로그 회전 미설정, 사용하지 않는 Docker 이미지와 볼륨 누적

해결: 운영용 컨테이너에 적절한 restart 정책을 적용하고, Docker 로그 회전 설정과 주기적 사용량 점검 루틴을 추가

홈서버를 운영하다 보면 문제가 생겼을 때 한 번만 복구하는 데 그치지 않고, 같은 문제가 반복되지 않게 기준을 세우는 것이 정말 중요하다는 걸 알게 됩니다. 자동 재시작이나 로그 관리, 그리고 리소스 점검 같은 것들은 겉보기에는 단순한 설정일 수 있지만, 오랜 기간 서버를 안정적으로 운영하는 데 꼭 필요한 기본이라고 할 수 있습니다.

마무리

Intel N100 홈서버에서 Proxmox와 Docker를 같이 쓰다 보면, 설치하는 것보다 오히려 꾸준히 관리하는 일이 훨씬 더 중요하다는 걸 새삼 느끼게 됩니다. 컨테이너가 제대로 돌아간다고 해서 끝이 아니거든요. 서버를 재부팅한 뒤에도 자동으로 서비스가 복구되는지, 로그 파일이 쌓여서 저장 공간을 잡아먹지는 않는지, 또 메모리 사용량이나 Docker 볼륨이 서서히 늘어나고 있지 않은지 틈틈이 점검해야 마음이 놓입니다.

목요일에 내린 결론은 사실 간단합니다. 홈서버는 단순히 ‘켜지는 구조’보다는 ‘다시 살아나는 구조’를 갖추는 게 더 중요하거든요. 금요일에는 이렇게 안정화된 구조를 바탕으로, 실제로 서버가 어떻게 돌아가는지 모니터링하고, 그 기록을 어떻게 남길지 정리해보려고 합니다.