Intel N100 홈서버 2주차 회고 : Proxmox·Docker 운영 안정화

 

 

※ 이 글은 운영자가 직접 홈서버를 운영하면서 실험한 경험과 여러 공개 자료를 참고해 작성한 것입니다. 글의 문장 정리와 구성에는 AI 보조 도구를 일부 사용했지만, 최종 내용은 운영자가 직접 꼼꼼하게 확인했습니다.

Intel N100 홈서버 2주차 회고: Proxmox·Docker 운영 안정화와 다음 주 방향 정리

도입

Intel N100 홈서버 2주차에는 Proxmox VE 설치와 Docker 서비스 구동을 넘어서, 서버를 오랫동안 안정적으로 운영할 수 있는 구조를 직접 점검해보는 데 집중했습니다.

이번 주에는 VM과 Docker의 역할을 분리하는 방법부터 VT-x와 KVM 가상화 옵션을 확인하는 과정, Docker의 자동 재시작 정책 설정, 로그 관리, 모니터링, 그리고 운영 데이터 기록까지 하나하나 살펴봤습니다. 처음에는 ‘서비스가 제대로 동작하는지’만 중요하다고 생각했는데, 며칠 직접 운영해보니 막상 문제가 생겼을 때 어디부터 점검해야 하는지 알 수 있는 게 더 중요하다는 걸 느꼈습니다.

이 글은 2주차 전체 과정을 돌아보며 정리한 회고입니다. 정해진 답을 제시하기보다는, 지금 구성에서 어떤 선택이 합리적이었는지, 그리고 다음 주에는 어떤 점을 개선하면 좋을지 생각해보고자 합니다.

Intel N100 홈서버 2주차 회고 - Proxmox·Docker 운영 안정화와 다음 주 방향 정리

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

본문

2주차의 핵심은 “설치”보다 “운영 안정화”였다

1주차가 Intel N100 홈서버를 직접 구축하고 기본적인 운영 과정을 살펴본 시간이었다면, 2주차에는 Proxmox와 Docker를 함께 사용하는 환경에서 어떻게 하면 더 안정적으로 운영할 수 있을지 고민해보았습니다.

VM을 만들고 Docker 컨테이너를 실행하는 일은 비교적 금방 끝낼 수 있습니다. 하지만 오랜 기간 서비스를 안정적으로 운영하려면, 컨테이너가 자동으로 재시작되는지, 로그가 지나치게 쌓이지 않는지, 디스크 사용량이 예상치에서 벗어나지 않는지, 그리고 가상화 옵션이 제대로 동작하는지 같은 부분을 더 신경 써야 했습니다. 이런 점들이 실무에서 훨씬 중요하게 느껴졌습니다.

• VM과 Docker 역할을 나눠 장애 추적 범위를 줄이는 것
• BIOS와 VT-x 설정을 확인해 KVM 가속 기반을 점검하는 것
• Docker restart 정책으로 기본 복구 흐름을 만드는 것
• 로그와 백업 파일 증가 추세를 기록하는 것
• 모니터링 지표를 같은 기준으로 반복 확인하는 것

이번 주에 내린 가장 큰 결론은 단순히 서버가 '켜져 있는지'보다, 필요할 때마다 다시 점검하거나 확인할 수 있는 서버가 훨씬 더 믿을 만하다는 것이었습니다.

월요일 : Proxmox 구조를 먼저 이해했다

월요일에는 Proxmox VE의 하이퍼바이저 구조와 VM, LXC, Docker가 어떻게 다른지 정리해봤습니다. 처음엔 '가상화'라는 단어가 좀 거창하게 느껴졌지만, 막상 운영 측면에서 보면 결국 ‘서비스를 어떻게 나누고 관리할지’에 관한 이야기라는 생각이 들었습니다.

Proxmox는 가상 머신과 컨테이너를 손쉽게 관리할 수 있는 환경을 제공합니다. 하지만 모든 설정을 지나치게 세분화하는 것이 늘 좋은 선택은 아니었습니다. 특히 Intel N100처럼 자원이 넉넉하지 않은 환경에서는 관리의 편리함과 리소스 소모 사이에서 적절한 균형을 잡는 게 중요했습니다.

화요일 : VM과 Docker 역할 분리를 다시 설계했다

화요일에는 모든 Docker 서비스를 하나의 Ubuntu VM에 몰아넣는 방식과, 각각의 역할에 따라 VM이나 서비스 영역을 나누는 방식 이 두 가지 구조를 비교해 봤습니다.

단일 Docker VM 구조는 처음 도입할 때 간편하고, 관리해야 할 포인트도 적다는 점이 매력입니다. 하지만 Jellyfin의 미디어 스캔, n8n 자동화, 리버스 프록시, 테스트용 컨테이너 등이 한데 모이면 각 서비스가 어떻게 리소스를 쓰는지, 또 어느 부분에서 장애가 생겼는지 파악하기가 쉽지 않을 수 있습니다.

그래서 지금 환경에서는 모든 요소를 완전히 분리하기보다는, 운영 서비스와 테스트 서비스, 외부 연결 계층, 그리고 백업 영역을 나누어 구성하는 것이 더 현실적이라고 생각했습니다. 이 결정 역시 절대적인 정답이라기보다는, 현재 장비 상황과 운영 목표를 고려해 내린 선택에 가깝습니다.

수요일 : VT-x와 KVM 상태를 점검했다

수요일에는 Intel N100 홈서버에서 VT-x와 BIOS 가상화 설정, 그리고 KVM 모듈이 제대로 활성화되어 있는지 확인했습니다. N100 칩셋 자체는 가상화를 지원하지만, 장비에 따라 BIOS에서 이 옵션이 꺼져 있는 경우도 종종 있습니다. 그래서 실제로 가상화 기능이 사용할 수 있는지 꼼꼼히 점검할 필요가 있습니다.

# CPU 가상화 플래그 확인
egrep -c '(vmx|svm)' /proc/cpuinfo

# CPU 정보 확인
lscpu

# KVM 모듈 확인
lsmod | grep kvm

이 명령어들은 무조건 이상 없음을 보장해주는 도구라기보다는, 가상화 환경이 제대로 세팅됐는지 확인하기 위한 첫 단계로 보는 쪽이 더 적합했습니다. 특히 VM 속도가 유난히 느리거나 KVM 가속에 문제가 있는 것 같을 때는, 성능의 한계를 먼저 의심하기보다는 BIOS 설정이나 CPU 플래그부터 점검해보는 게 더 합리적인 방법이었습니다.

목요일 : 자동 재시작과 로그 관리 기준을 잡았다

목요일에는 Docker의 재시작 정책과 로그 관리 구조를 정리했어요. 홈서버에서는 서비스가 처음 실행될 때뿐만 아니라, 재부팅 이후에도 제대로 다시 동작하는 과정이 중요하다고 느꼈습니다.

운영용 컨테이너에는 restart: unless-stopped를 기본값으로 검토했습니다. 이 설정을 사용하면 서버가 재부팅된 뒤 컨테이너가 자동으로 올라와 편리합니다. 하지만 운영자가 일부러 중지해둔 서비스까지 모두 다시 실행되는 상황은 막을 수 있습니다.

하지만 모든 서비스에 똑같은 정책을 일괄적으로 적용하는 것이 늘 올바른 선택은 아닙니다. 예를 들어, 실험용이나 일회성, 배치 작업을 위한 컨테이너처럼 용도에 따라서는 각기 다른 기준이 더 잘 어울릴 수도 있습니다.

services:
  example-service:
    restart: unless-stopped

로그 관리는 한층 신중하게 진행했습니다. 로그가 문제를 해결할 때는 꼭 필요하지만, 장기간 쌓이면 디스크 공간을 쉽게 차지하게 되거든요. 그래서 로그를 바로 지우기보다는 먼저 사용량을 살펴보고, 필요하면 로그 회전 정책도 함께 검토하는 게 더 안전하겠다고 판단했습니다.

금요일 : 모니터링 기준을 만들었다

금요일에는 CPU, 메모리, Docker 상태, 디스크 사용량, 그리고 Proxmox Web UI에서 지표를 함께 살펴보는 과정을 정리해 두었습니다. 여기서 핵심은 멋진 대시보드를 꾸미는 데 있는 게 아니라, 매번 같은 항목을 꼼꼼히 반복해서 점검하는 습관을 들이는 것이었습니다.

# CPU와 프로세스 흐름
htop

# 메모리 상태
free -h

# Docker 컨테이너 리소스
docker stats

# 디스크 사용량
df -h

# Docker 저장소 사용량
docker system df

Intel N100 환경에서는 CPU 사용량보다 오히려 메모리나 디스크 사용량, 그리고 Docker 볼륨이 쌓이는 현상이 더 먼저 체감되는 경우가 종종 있었습니다. 그래서 단순히 한 시점의 수치만 보는 것보다, 시간에 따라 어떻게 변화하는지 흐름을 살펴보는 게 훨씬 더 합리적이라고 느꼈습니다.

토요일 : 운영 데이터를 기준값으로 정리했다

토요일마다 전력, 온도, Docker 상태, 디스크 사용량, 백업 상태 등 한 주 동안의 운영 데이터를 정리해두었습니다. 이 기록은 그저 현재 상태를 자랑하려고 남긴 게 아니라, 다음 주와 비교할 수 있는 기준점에 더 가까웠죠.

실제 전력 사용량과 온도는 미니 PC 제조사나 SSD 구성, 실내 온도, 실행 중인 서비스 수 등에 따라 달라집니다. 그래서 특정 수치를 절대적인 기준으로 보기보다는, 같은 조건에서 여러 번 측정해 그 변화 추이를 살펴보는 것이 더 신뢰할 만했습니다.

기록 항목	확인 방법	운영 판단
전력 사용량	와트미터 또는 스마트 플러그	같은 시간대 기준 비교
CPU 온도	sensors	순간 최고값보다 장시간 유지 흐름 확인
Docker 상태	docker compose ps	Restart 반복 또는 Exited 상태 확인
디스크 사용량	df -h	주간 증가폭 확인
백업 파일	ls -lh /backup	파일 생성 여부와 크기 변화 확인

운영 로그

아래 표는 2주차 전체를 돌아보며 정리한 운영 회고입니다. 모든 환경에 똑같이 들어맞는 정답은 없지만, 현재 Intel N100 홈서버에서는 이 구성이 가장 합리적이라고 판단했습니다.

요일	핵심 주제	운영 판단
월요일	Proxmox 구조 이해	가상화 기반을 먼저 이해해야 이후 구성이 흔들리지 않음
화요일	VM·Docker 역할 분리	완전 분리보다 관리 가능한 수준의 역할 구분이 현실적
수요일	VT-x·KVM 점검	성능 문제로 보기 전에 BIOS와 CPU 플래그 확인이 필요
목요일	자동 재시작·로그 관리	서비스 복구와 로그 누적 기준을 함께 잡는 것이 안정적
금요일	운영 모니터링	단일 수치보다 변화 추세를 반복 관찰하는 것이 중요
토요일	운영 데이터 정리	다음 주 비교를 위한 기준값 확보가 핵심

다음 주 운영 방향

다음 주에는 기능을 무리하게 확장하기보다는, 이번 주에 만들어둔 운영 기준을 좀 더 안정적으로 다듬는 게 더 나을 것 같습니다. 특히 백업 자동화나 로그 회전, 리버스 프록시 정리, 모니터링 시각화 같은 부분들은 한 번에 다 하려고 하기보다 단계적으로 차근차근 진행하는 게 훨씬 효율적입니다.

• 백업 자동화 스크립트 점검과 복구 테스트
• Docker 로그 회전 설정 검토
• Reverse Proxy 설정 구조 정리
• Proxmox Web UI와 CLI 기준 모니터링 항목 통일
• NAS 또는 외장 저장소 백업 구조 테스트

여기서 정말 중요한 건 모든 걸 한 번에 다 준비하는 게 아니라, 실제로 운영하다가 문제가 생기면 언제든지 되돌릴 수 있도록 작업을 작은 단위로 나눠서 진행하는 것입니다. 홈서버는 실험실처럼 이것저것 시도해볼 수 있는 공간이면서도, 동시에 항상 켜져 있어야 하는 작은 운영 환경이기도 하거든요.

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

• 2주차의 핵심은 설치 성공이 아니라 운영 안정화 기준을 만드는 것이었습니다.
• Intel N100 환경에서는 성능을 밀어붙이는 것보다 역할 분리와 기록 기준을 정리하는 편이 더 현실적이었습니다.
• 위험한 정리 명령어는 바로 실행하기보다 백업 여부와 데이터 위치를 먼저 확인하는 편이 안전했습니다.
• 다음 주에는 확장보다 복구 가능성과 기록 반복성을 높이는 방향이 더 합리적이라고 판단했습니다.

참고 링크 (References)

1. Proxmox VE Documentation
2. Docker Compose Documentation
3. Docker logging configuration
4. Docker stats reference
5. Docker system df reference

트러블슈팅

문제: 2주차 운영을 마쳤지만 다음 주에 무엇부터 개선해야 할지 우선순위가 불명확함

홈서버를 운영하다 보면 점점 해보고 싶은 일들이 많아집니다. 예를 들어, 모니터링 대시보드나 NAS 설정, 자동화, 백업, 리버스 프록시 정리 등 다양한 기능을 추가하고 싶다는 생각이 들죠. 하지만 한꺼번에 여러 가지를 바꾸다 보면, 혹시 문제라도 생겼을 때 어디에서 오류가 발생했는지 찾기가 쉽지 않습니다. 한 단계씩 차근차근 진행하는 게 훨씬 안전합니다.

확인: 이번 주에 가장 자주 확인한 항목과 실제로 불편했던 지점을 기준으로 우선순위 정리

# 현재 서비스 상태
docker compose ps

# Docker 사용량
docker system df

# 디스크 사용량
df -h

# 메모리 상태
free -h

# 백업 파일 확인
ls -lh /backup

원인: 운영 데이터는 쌓였지만 개선 우선순위를 정하지 않으면 작업 범위가 너무 넓어짐

해결: 다음 주에는 백업 검증, 로그 회전, 모니터링 기준 정리처럼 복구 가능성과 안정성에 직접 연결되는 항목부터 진행

지금은 새로운 서비스를 계속 추가하는 것보다, 이미 운영 중인 서비스가 안정적으로 복구되고 잘 기록될 수 있도록 구조를 먼저 정비하는 게 더 합리적이라고 생각했습니다.

마무리

Intel N100 홈서버 2주차는 '무엇을 설치했는가'에 집중하기보다는 '이걸 앞으로 어떻게 안정적으로 사용할까' 고민하게 된 시간이었습니다. Proxmox와 Docker를 함께 다루면서 가상머신 역할을 구분하고, VT-x가 제대로 활성화되어 있는지 확인하는 과정부터 시작했죠. 이외에도 자동 재시작 정책, 로그 정리, 모니터링, 운영 기록 등 하나씩 기준을 세워가며 환경을 조금씩 다듬어갔습니다.

이번 주를 정리하자면, 결론은 꽤 간단합니다. 홈서버는 설치만으로 끝나는 게 아니라, 직접 사용하면서 기록도 남기고, 여러 설정을 비교해보고, 때로는 조금씩 조정해야 비로소 안정적으로 운영할 수 있게 됩니다. 이렇게 시간이 쌓이다 보면 점점 더 자신만의 환경에 가까워지죠.

다음 주에는 이번 주에 마련한 기준을 토대로 백업 자동화, 로그 회전, 리버스 프록시 정리, 모니터링 시각화 같은 부분을 하나씩 살펴볼 생각입니다. 무리하게 확장하기보다는 언제든 되돌릴 수 있는 단위로 천천히 개선해 나가는 게 지금 환경에는 더 잘 어울릴 것 같습니다.