Docker Compose 운영 체크리스트 만들기 : Intel N100 홈서버 주간 점검 항목 정리

 

 

※ 이 글은 운영자가 직접 홈서버를 운영하며 실험한 경험과 Docker 공식 문서를 참고해 작성했습니다. 글의 문장 정리와 구성에는 AI 도구를 일부 도움 받았지만, 최종 내용은 운영자가 직접 꼼꼼히 확인하고 검토했습니다.

Docker Compose 운영 체크리스트 만들기 : Intel N100 홈서버 주간 점검 항목 정리

도입

4주차에는 Intel N100 홈서버에서 Docker를 좀 더 체계적으로 이해하는 데 초점을 맞춰 내용을 정리하고 있습니다. 월요일에는 Docker 네트워크를 활용해서 서비스들이 어떻게 연결되는지 살펴봤고, 화요일에는 볼륨과 바인드 마운트로 데이터가 어떻게 저장되는지 직접 확인해봤습니다. 수요일에는 .env 파일을 중심으로 설정값 관리 기준을 정리했고, 목요일에는 Docker 이미지 업데이트 정책을 살펴봤습니다. 금요일에는 Docker 로그를 살펴보면서 장애가 발생한 원인을 어떻게 찾아가는지 정리해봤습니다.

토요일에는 이 흐름을 참고해서 Docker Compose 운영 체크리스트를 만들어볼까 합니다. 금요일 글이 문제가 생긴 뒤에 로그를 살펴보고 원인을 파악하는 내용이었다면, 토요일 글은 문제를 미리 예방하기 위한 주간 점검 습관에 더 가깝다고 볼 수 있습니다.

홈서버를 운영할 때 단순히 새로운 서비스를 계속 추가하는 것만이 중요한 건 아니었습니다. 오히려 서비스 상태나 로그, 백업, 디스크 사용량, 그리고 업데이트 여부를 꾸준히 확인하는 일이 더 중요했습니다. 이렇게 반복적으로 점검하면 작은 문제도 미리 발견해 큰 장애로 번지는 걸 막을 수 있었거든요.

Intel N100 홈서버에서 Docker Compose 서비스 상태, 로그, 백업, 디스크 사용량, 이미지 업데이트, 네트워크 상태를 주기적으로 점검하기 위한 운영 체크리스트입니다.

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

본문

왜 체크리스트를 만들게 되었을까

홈서버를 처음 만들 때는 서비스가 정상적으로 작동하는지만 확인해도 충분하다고 생각했습니다. 컨테이너가 실행되고, 웹 화면이 뜨고, 외부에서도 접속이 되면 그걸로 일단 성공했다는 느낌이 들었죠.

하지만 시간이 흐르면서 챙겨야 할 것들이 점점 많아졌습니다. 예를 들어, 어떤 서비스가 계속 재시작되는지, 로그에 같은 오류가 반복되는지, 백업이 제대로 남아 있는지, SSD 공간이 부족하지는 않은지, 또는 업데이트할 이미지가 있는지 직접 하나하나 확인하지 않으면 쉽게 놓칠 수 있었습니다.

그래서 지금 Intel N100 홈랩에서는, 단순히 생각날 때마다 확인하는 것보다는 주간 체크리스트를 만들어 주기적으로 점검하는 방법이 더 현실적이라고 느꼈습니다. 특별한 자동화보다 먼저, 기본적인 점검 항목을 빼먹지 않고 챙기는 습관이 중요하다는 걸 알게 됐어요.

1단계 : 서비스 상태 확인

가장 먼저 살펴봐야 할 것은 Docker Compose 서비스의 상태입니다. 컨테이너가 정상적으로 실행 중인지, 아니면 중간에 종료됐거나 계속해서 재시작하고 있는지부터 확인해보세요. 이런 기본적인 점검이 문제 해결의 첫걸음입니다.

# 현재 Compose 프로젝트의 서비스 상태 확인
docker compose ps

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

Up 상태라고 해서 모든 기능이 정상이라는 뜻은 아니지만, Exited나 Restarting 상태가 보이면 바로 로그 확인으로 넘어가야 합니다.

상태	의미	다음 확인
Up	컨테이너 실행 중	로그와 실제 접속 상태 확인
Exited	컨테이너 종료됨	종료 원인 로그 확인
Restarting	반복 재시작 중	설정값, volume, 권한, network 확인

2단계 : 최근 로그 확인

서비스 상태를 확인한 다음에는 꼭 로그도 살펴봐야 합니다. 로그는 문제가 발생했을 때만 보는 것이 아니라, 주간 점검처럼 평소에도 잠깐씩 확인해두면 도움이 됩니다. 겉보기에는 서비스가 정상처럼 보여도, 실제로는 오류가 계속 반복되는 경우가 있기 때문입니다.

# 전체 서비스 최근 로그 확인
docker compose logs --tail=100

# 특정 서비스 최근 로그 확인
docker compose logs 서비스이름 --tail=100

# 실시간 로그 확인
docker compose logs -f

주간 점검을 할 때는 긴 로그 전체를 다 읽기보다는, 반복적으로 나타나는 오류나 권한 문제, 경로 또는 네트워크 관련 오류가 있는지만 살펴봐도 충분했습니다. 무엇보다 중요한 건 ‘로그를 꾸준히 확인하는 습관’을 유지하는 것이었습니다.

3단계 : 백업 상태 확인

백업은 문제가 생긴 뒤에 확인하면 늦을 수 있습니다. Compose 파일, .env 파일, volume, bind mount 경로가 백업 기준에 포함되어 있는지 주기적으로 확인해야 했습니다.

# 백업 디렉터리 확인 예시
ls -lh /backup

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

# 예약 백업 작업 확인
crontab -l

백업 파일이 존재하는 것만으로 충분하지 않았습니다. 최근 백업이 언제 만들어졌는지, 크기가 비정상적으로 작지는 않은지, 실제 복구에 필요한 compose.yml과 .env가 포함되어 있는지를 확인해야 했습니다.

• compose.yml : 서비스 구조 복구 기준
• .env : 포트, 경로, 시간대, 토큰 등 설정값
• Volume : Docker가 관리하는 서비스 데이터
• Bind Mount : 호스트 경로에 저장된 설정과 데이터
• 백업 로그 : 최근 백업 성공 여부 확인

4단계 : 디스크 사용량 확인

Intel N100 미니 PC를 사용할 때는 SSD나 NVMe 저장 공간이 한정적이라서, Docker 이미지와 볼륨, 로그, 백업 파일이 함께 쌓이다 보면 어느새 저장 공간이 부족해질 수 있습니다. 필요한 파일만 남기고 주기적으로 정리해 주는 것이 중요합니다.

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

# Docker 사용량 확인
docker system df

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

docker system df는 Docker가 사용하는 이미지, 컨테이너, volume, 빌드 캐시 규모를 확인하는 데 도움이 됩니다. 하지만 용량이 늘었다고 해서 곧바로 정리 명령을 내리는 건 주의해야 했습니다. 특히 볼륨에는 실제 서비스 데이터가 들어 있을 수도 있어서 더 신중할 필요가 있었죠.

5단계 : 업데이트 여부 확인

목요일에 정리했던 업데이트 정책을 생각해보면, 주간 점검에서는 지금 쓰고 있는 이미지가 무엇인지, 그리고 업데이트가 필요한지 간단하게 확인하는 정도면 충분했습니다. 모든 서비스를 매주 최신 상태로 만드는 게 목표는 아니었어요.

# 이미지 목록 확인
docker images

# 서비스 상태 확인
docker compose ps

중요한 서비스는 업데이트 전에 릴리즈 노트, 백업 상태, .env 변경 가능성, volume 구조를 함께 확인해야 했습니다. 그래서 체크리스트에서는 “업데이트 실행”보다 “업데이트 검토”를 우선했습니다.

6단계 : network와 외부 접속 점검

Reverse Proxy나 외부 접속 서비스를 운영할 때는 Docker 네트워크도 정기적으로 점검해 두는 것이 좋습니다. 외부 접속이 안 될 때만 확인하지 말고, 평소에도 어떤 서비스가 어떤 네트워크에 연결되어 있는지 구조를 파악해 두면 장애가 발생했을 때 훨씬 빠르게 대응할 수 있습니다.

# Docker network 목록 확인
docker network ls

# 특정 network 상세 확인
docker network inspect 네트워크이름

# 컨테이너 network 확인
docker inspect 컨테이너이름 --format='{{json .NetworkSettings.Networks}}'

주간 점검을 할 때마다 모든 네트워크 세부 정보를 꼼꼼하게 확인할 필요는 없습니다. 하지만 리버스 프록시와 외부에서 접속해야 하는 서비스가 같은 네트워크에 속해 있는지, 그리고 테스트용으로 잠깐 만들었던 네트워크가 혹시 남아 있지는 않은지 정도는 살펴보는 것이 좋습니다.

점검 결과는 짧게라도 기록했다.

체크리스트에서 가장 중요한 점은 확인 그 자체보다는 기록을 남기는 일이었습니다. 매번 길게 보고서를 작성할 필요는 없었죠. 그저 날짜와 상태, 그리고 특이사항 정도만 메모해도, 나중에 문제가 발생했을 때 흐름을 쉽게 되짚을 수 있었습니다.

2026-06-01 주간 점검

서비스 상태: 정상
반복 오류 로그: 없음
디스크 사용량: 42%
Docker 사용량: 이미지 증가 확인
백업 상태: 완료
업데이트 대상: 2개, 다음 점검 때 검토
특이사항: Reverse Proxy 테스트 host 정리 필요

이런 기록은 꼭 완벽하게 정리된 문서일 필요는 없었습니다. 운영자가 다음 주에 다시 볼 때, 지난주에 무슨 내용을 확인했는지만 알 수 있으면 충분했죠.

운영 로그

아래 표는 Intel N100 홈서버를 기준으로 정리한 Docker Compose 주간 운영 체크리스트입니다. 실제 점검 항목과 주기는 서비스의 종류나 개수, 저장장치의 용량, 외부 접속 여부, 그리고 백업 방식 등에 따라 달라질 수 있습니다. 운영 환경에 맞게 유동적으로 조정해 사용하시면 좋겠습니다.

점검 항목	명령어 또는 확인 기준	운영 판단
서비스 상태	docker compose ps	종료 또는 반복 재시작 여부 확인
최근 로그	docker compose logs --tail=100	반복 오류와 경고 확인
백업 상태	ls -lh /backup, crontab -l	최근 백업 존재 여부와 크기 확인
디스크 사용량	df -h	전체 저장 공간 여유 확인
Docker 사용량	docker system df	이미지, volume, cache 증가 확인
이미지 업데이트	docker images	업데이트 실행보다 검토 우선
network 상태	docker network ls	불필요한 network와 Proxy 연결 확인

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

• Docker 서비스를 운영하면서 가장 도움이 된 것은 새로운 기능보다 반복 가능한 점검 습관이었습니다.
• 서비스 상태, 로그, 백업, 디스크 사용량은 특별한 기술보다 먼저 확인해야 할 기본 항목이었습니다.
• 업데이트는 바로 실행하기보다 백업과 로그 상태를 확인한 뒤 검토하는 편이 안전했습니다.
• 체크리스트는 문제를 완전히 막아주지는 않지만, 문제를 늦게 발견하는 상황을 줄이는 데 도움이 됐습니다.

참고 링크 (References)

1. docker compose ps reference
2. docker compose logs reference
3. docker system df reference
4. docker image ls reference
5. docker network ls reference

트러블슈팅

문제: 오랫동안 점검하지 않은 뒤 갑자기 Docker 서비스가 정상 동작하지 않음

주간 점검을 건너뛰면 서비스 재시작 오류나 로그 반복, 디스크 용량 부족, 백업 실패나 네트워크 연결 문제를 제때 알아차리지 못할 수 있습니다. 이렇게 문제가 터진 뒤에야 여러 항목을 한꺼번에 점검하면, 어떤 문제가 원인인지 파악하는 데 더 많은 시간이 소요될 수 있습니다.

확인: 서비스 상태, 로그, 디스크, Docker 사용량, 백업 상태를 순서대로 점검

# 서비스 상태
docker compose ps

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

# 디스크 사용량
df -h

# Docker 사용량
docker system df

# 백업 상태
ls -lh /backup
crontab -l

원인: 상태 점검이 누락되면서 작은 경고나 용량 증가, 백업 실패를 제때 확인하지 못함

해결: 주간 체크리스트를 기준으로 서비스 상태, 로그, 백업, 용량, 업데이트 여부를 반복 점검하고 간단한 기록을 남김

현재 구성에서는 자동화보다 먼저 반복 가능한 점검 루틴을 만드는 것이 더 현실적인 운영 방식이었습니다.

마무리

Docker Compose 운영 체크리스트를 만들면서 새삼 느꼈던 건, 홈서버에서 꼭 대단한 기술만이 중요한 건 아니라는 점이었습니다. 서비스 상태를 수시로 살피고, 로그를 꼼꼼히 확인하고, 백업이 제대로 되어 있는지 점검하고, 디스크 공간도 주기적으로 체크하는 이런 기본적인 습관이 오히려 서버를 오래, 안정적으로 운영하는 데 큰 힘이 된다는 걸 알게 됐습니다.

Network는 연결 구조였고, Volume은 데이터 구조였으며, .env는 설정 구조였습니다. 로그는 문제를 찾는 지도였고, 체크리스트는 문제를 예방하기 위한 운영 습관에 가까웠습니다.

토요일을 마무리하면서 느낀 점은 아주 간단했습니다. 일이 벌어진 뒤에 문제를 해결하는 것도 물론 필요하지만, 그보다 더 중요한 건 애초에 문제가 생기지 않도록 미리 점검하는 습관이었습니다. 일요일에는 이 흐름을 이어가려고 합니다. ‘내 홈서버는 지금 제대로 돌아가고 있을까?’라는 질문을 던지며, 4주차 전체 점검 루틴에 대해 다시 한번 돌아볼 계획입니다.