Intel N100 홈랩 운영 요약 : 서비스 상태·백업·외부 접속 점검 데이터 정리

 

 

※ 이 글은 운영자가 직접 홈서버를 운영하며 경험한 내용을 바탕으로, Docker 공식 문서와 다양한 공개 자료를 참고해 작성했습니다. 글을 정리하고 구성할 때 일부 AI 도구의 도움을 받았지만, 모든 내용은 운영자가 최종적으로 꼼꼼히 검토했습니다.

Intel N100 홈랩 운영 요약 : 서비스 상태·백업·외부 접속 점검 데이터 정리

도입

3주차에는 Intel N100 홈서버를 단순히 작동만 시키는 데 그치지 않고, 앞으로 오랫동안 안정적으로 운영하려면 어떤 부분들을 꾸준히 챙겨야 할지 하나씩 정리해보았습니다. 월요일에는 Docker Compose의 전체 운영 구조를 다시 한 번 살펴보았고, 화요일에는 Compose 파일, 볼륨 구성, 그리고 운영 데이터를 어떻게 백업할지 그 흐름을 점검했습니다.

수요일에는 Docker 로그가 어떻게 순환되는지와 디스크 사용량을 어떻게 관리할지 기준을 살펴봤습니다. 목요일에는 Reverse Proxy 설정과 외부에서 접속하는 경로를 다시 정리했고요. 금요일에는 만약 실제로 장애가 생겼을 때 어떤 순서로 점검해야 할지 확인하는 루틴을 만들어봤습니다.

오늘은 토요일이라 새로운 기능을 추가하기보다는, 이번 주 홈랩 운영 상황을 전체적으로 다시 점검하는 데 집중했습니다. 홈랩을 운영하면서 기능을 하나둘 늘려가는 것도 중요하지만, 무엇보다 지금 갖추고 있는 구조가 제대로 안정적으로 돌아가고 있는지 확인하는 과정도 꼭 필요하다는 생각이 들었습니다.

Intel N100 홈서버에서 한 주 동안 점검한 서비스 상태, 백업, 로그, 디스크, Reverse Proxy, Docker network 흐름을 주간 운영 로그 형태로 정리한 다이어그램입니다.

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

본문

이번 주 운영 목표는 기능 추가보다 유지관리였다

3주차를 시작하면서 세운 목표는 새로운 서비스를 무작정 많이 추가하는 것이 아니었어요. 이미 Docker Compose를 기반으로 한 서비스가 점점 늘어나고 있었고, 그 과정에서 백업이나 로그 관리, 외부 접속, 장애 대응처럼 운영에 필요한 일들이 자연스럽게 하나둘 쌓이고 있었습니다.

이번 주에는 ‘새로운 것을 더 설치할까’ 하는 고민보다는, ‘지금 갖추고 있는 구조를 얼마나 안정적으로 관리할 수 있을까’에 더 신경을 썼습니다. 실제로 홈서버를 운영해 보면, 기능이 많아질수록 챙겨야 할 부분도 자연스럽게 늘어납니다. 서비스가 추가되면 Compose 파일이 복잡해지고, 볼륨이나 로그도 점점 불어납니다. 여기에 외부 접속 경로나 SSL 인증서 상태까지 함께 살펴봐야 하죠.

• Docker Compose 서비스 구조 정리
• Compose, .env, volume 백업 대상 확인
• Docker 로그와 디스크 사용량 점검
• Reverse Proxy 외부 접속 경로 정리
• 장애 발생 시 확인 순서 작성

서비스 상태는 실행 여부보다 반복 패턴을 봤다

토요일 점검에서 가장 먼저 본 것은 Docker 서비스 상태였습니다. 단순히 컨테이너가 Up 상태인지 확인하는 것만으로는 충분하지 않았습니다. 반복해서 재시작되는 서비스가 있는지, 종료된 컨테이너가 그대로 남아 있지는 않은지, 또 어떤 서비스가 유독 로그를 많이 쌓고 있는지도 함께 살펴봐야 했습니다.

# Compose 기준 서비스 상태 확인
docker compose ps

# 전체 컨테이너 상태 확인
docker ps -a

# 최근 로그 확인
docker compose logs --tail=100

서비스 유형	주요 확인 항목	운영 판단
자동화 서비스	워크플로 실행 로그, 오류 반복 여부	최근 로그와 데이터 백업 상태 함께 확인
관리 도구	접속 가능 여부, 계정 보안	외부 노출 여부를 별도 기록
미디어 서비스	스캔 작업, 디스크 증가, CPU 사용	부하 발생 시간대를 따로 관찰
Reverse Proxy	도메인 연결, SSL, 내부 포트	외부 접속 경로를 문서화

백업은 파일 존재보다 복구 가능성을 기준으로 봤다

백업은 단순히 파일이 있는지 확인하는 작업이 아니었습니다. 실제로 복구하려면 Compose 파일, .env, volume 또는 bind mount 데이터, 백업 스크립트, 복구 순서가 함께 있어야 했습니다.

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

# 백업 디렉터리 크기 확인
du -sh /backup

# Compose 파일 위치 확인
find /opt/docker -name "compose.yml"

# 예약 백업 확인
crontab -l

• Compose 파일이 백업에 포함되어 있는가
• .env 파일이 누락되지 않았는가
• volume 또는 bind mount 데이터 위치가 기록되어 있는가
• 백업 로그가 남아 있는가
• 복구 순서가 문서로 정리되어 있는가

로그와 디스크 사용량은 함께 봐야 했다

Docker 로그는 장애 발생 시 중요한 운영 기록이 되지만, 무한정 쌓이면 SSD 저장 공간에 부담을 줄 수 있습니다. 그래서 로그만 따로 살피는 것보다는 이미지, 볼륨, 백업 파일, 그리고 journal 로그까지 전체적으로 점검하는 게 필요했습니다.

# 전체 파일시스템 사용량
df -h

# Docker 사용량 확인
docker system df

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

디스크 사용량이 늘었다고 해서 곧바로 docker system prune --volumes 같은 명령을 실행하는 것은 피했습니다. volume에는 실제 서비스 데이터가 들어 있을 수 있기 때문에, 먼저 어떤 항목이 늘어났는지 확인하는 것이 더 안전했습니다.

외부 접속 상태는 열려 있는 경로를 기록하는 것이 핵심이었다

외부에서 접속할 수 있는 서비스는 분명 편리하지만, 그만큼 관리해야 할 부분도 많아집니다. 예를 들어, 도메인이나 DNS 설정, SSL 인증서, 프록시 호스트, 내부 서비스 포트, 그리고 Docker 네트워크까지 서로 잘 맞아야 모든 기능이 제대로 작동합니다. 이 중 하나라도 엇갈리면 서비스에 문제가 생길 수 있으니 꼼꼼하게 확인하는 것이 중요합니다.

# Docker network 목록 확인
docker network ls

# 컨테이너 네트워크 상세 확인
docker inspect 컨테이너이름 --format='{{json .NetworkSettings.Networks}}'

외부 접속 항목	확인 기준	운영 판단
도메인	A 레코드 또는 CNAME	현재 홈서버 방향으로 연결되는지 확인
SSL 인증서	발급 및 갱신 상태	발급 성공보다 유지 상태를 중요하게 봄
Proxy Host	Forward Hostname/IP, Forward Port	내부 서비스와 실제 연결되는지 확인
Docker network	Proxy와 서비스의 네트워크 연결	서비스명 접근 가능 여부 확인

이번 주 장애 대응 기준은 순서 만들기였다

장애를 대응할 때는 처음부터 원인을 정확히 찾기보다는, 점점 원인 범위를 좁혀가는 과정에 더 가깝게 느껴졌습니다. 이번 주에는 아래와 같은 순서로 진행하는 것이 가장 관리하기 편했습니다.

1. docker compose ps
2. docker compose logs --tail=100
3. df -h / docker system df
4. docker network ls
5. Reverse Proxy 설정 확인
6. 백업 상태 확인
7. 최근 변경 이력 확인

운영 로그

아래 표는 3주차 토요일을 기준으로 정리한 Intel N100 홈랩 운영 요약입니다. 실제 수치나 상태는 장비 구성, 사용하는 서비스 종류, 저장장치 용량, 그리고 네트워크 환경에 따라 조금씩 달라질 수 있습니다.

점검 영역	이번 주 확인 내용	다음 운영 판단
Docker Compose	서비스 그룹화와 디렉터리 구조 정리	서비스 성격별 관리 단위 유지
백업	Compose, .env, volume, 데이터 경로 확인	백업 파일보다 복구 가능성 기준 유지
로그	Docker 로그 회전과 디스크 사용량 점검	삭제보다 순환 보관 기준 검토
외부 접속	Reverse Proxy, DNS, SSL, Docker network 확인	필요한 서비스만 외부 노출
장애 대응	상태 → 로그 → 디스크 → 네트워크 순서 정리	반복 가능한 점검 루틴 유지

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

• 3주차는 새로운 기능을 추가하는 주간이라기보다, 기존 홈서버 구조를 운영 가능한 형태로 정리하는 주간이었습니다.
• Intel N100 홈랩에서는 성능을 밀어붙이는 것보다 관리 가능한 서비스 단위를 유지하는 것이 더 현실적이었습니다.
• 백업, 로그, 외부 접속, 장애 대응은 서로 분리된 주제가 아니라 장기 운영에서 함께 움직이는 항목이었습니다.
• 이번 주 운영 판단은 “더 많이 열기”보다 “현재 구조를 더 오래 유지하기”에 가까웠습니다.

참고 링크 (References)

1. Docker Compose Documentation
2. Docker volumes documentation
3. Docker logging configuration
4. Docker networking overview
5. docker system df reference

트러블슈팅

문제: 한 주 동안 점검한 항목이 많아졌지만, 실제 운영에서 무엇을 우선순위로 봐야 할지 흐려짐

Docker Compose 구조나 백업, 로그, 리버스 프록시, 장애 대응 같은 항목들을 따로따로 정리하다 보면 문서상에서는 할 일이 많아 보여도, 실제 운영에서는 오히려 판단이 더 복잡해질 수 있습니다. 이런 경우엔 새로운 기능을 성급하게 추가하기보다는, 지금 시스템 구조가 문제 발생 시 복구가 가능한지, 또 문제가 어떻게 진행됐는지 추적이 되는지부터 먼저 점검하는 것이 현실적으로 도움이 됐습니다.

확인: 서비스 상태, 백업 가능성, 로그 증가, 외부 노출 경로, 장애 점검 순서를 주간 단위로 확인

# 서비스 상태
docker compose ps

# 최근 로그
docker compose logs --tail=100

# 디스크 사용량
df -h
docker system df

# 네트워크
docker network ls

# 백업 확인
ls -lh /backup
crontab -l

원인: 기능별 점검은 했지만, 주간 운영 기준으로 다시 묶어보지 않음

해결: 토요일마다 서비스 상태, 백업, 로그, 외부 접속, 장애 대응 루틴을 한 번에 요약하고 다음 주 유지 기준을 정리

마무리

Intel N100 홈랩의 3주차 토요일에는 새로운 설정을 추가하기보다는, 한 주 동안 정리해둔 운영 항목들을 다시 한 번 정리하고 묶는 시간을 가졌습니다. Docker Compose 구조, 백업, 로그, 리버스 프록시, 그리고 장애 대응 같은 주제들은 따로 떨어져 있는 것처럼 보이지만, 실제로 운영을 하다 보면 이 모든 것들이 자연스럽게 연결되어 있다는 걸 느끼게 됩니다.

이번 주를 돌아보면서 가장 크게 느낀 점은, 홈랩을 운영하는 일이 계속해서 새로운 걸 추가하는 것보다는 지금의 구조를 얼마나 오래, 그리고 안정적으로 유지할 수 있을지 지켜보는 데 더 가깝다는 점이었습니다.

일요일에는 3주차 전체 과정을 돌아보고, 다음 주에 더 개선할 운영 항목이 무엇인지 정리해볼 예정입니다.