Docker 로그 회전 설정하기: Intel N100 홈서버 디스크 사용량 관리 흐름

 

 

※ 이 글은 운영자가 직접 홈서버를 실험한 경험과 Docker 공식 문서를 참고하여 작성했습니다. 내용 정리와 구성에는 AI 도구도 조금 활용했지만, 마지막 검토는 운영자가 직접 했습니다.

Docker 로그 회전 설정하기 : Intel N100 홈서버 디스크 사용량 관리 흐름

도입

월요일에는 Docker Compose의 운영 구조를 다시 한 번 정리했습니다. 화요일에는 Compose 파일, 볼륨, 그리고 운영 데이터 디렉터리를 중심으로 백업 자동화 과정을 살펴봤죠. 수요일인 오늘은 오랜 기간 서비스를 운영할 때 점차 문제가 될 수 있는 Docker의 로그와 디스크 사용량을 점검해보려고 합니다.

홈서버를 처음 세팅할 땐 컨테이너가 제대로 돌아가는지만 확인하면 돼서 비교적 간단합니다. 그런데 며칠 지나고 꾸준히 운영하다 보면 컨테이너 로그나 Docker 이미지, 볼륨, 그리고 systemd journal 로그들이 하나둘씩 쌓이기 시작하죠. NVMe나 SSD처럼 저장 공간이 넉넉하지 않은 미니 PC를 쓸 때는 이런 로그와 데이터가 차지하는 용량도 운영 기준에 반드시 고려해야 했습니다.

이번 글의 핵심은 ‘로그를 무조건 삭제하자’는 뜻이 아닙니다. 로그는 장애 원인을 파악할 때 꼭 필요한 운영 기록이기 때문입니다. 그래서 얼마 동안 로그를 보관할지, 언제부터 순환 저장을 시작할지에 대한 기준을 세우는 것이 더 현실적이고 효과적인 방법이라고 생각합니다.

Docker 로그 회전 설정하기 - Intel N100 홈서버 디스크 사용량 관리 흐름

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

본문

로그는 불필요한 파일이 아니라 운영 기록이었다

Docker 로그는 서비스가 어떻게 동작했는지 살펴볼 수 있는 중요한 기록입니다. 예를 들어, 특정 컨테이너가 예고 없이 재시작되거나, Web UI가 갑자기 느려지거나, 백그라운드 작업이 실패했을 때 가장 먼저 살펴보는 것이 바로 이 로그입니다. 실제로 문제가 생겼을 때 원인을 빠르게 파악하려면, 로그를 꼼꼼히 확인하는 습관이 필요합니다.

Docker의 docker logs 명령은 컨테이너가 기록한 로그를 조회하는 데 사용됩니다. Docker 공식 문서에서도 docker logs는 실행 시점에 존재하는 컨테이너 로그를 가져오며, --follow 옵션을 사용하면 새로 출력되는 STDOUT과 STDERR 로그를 계속 볼 수 있다고 설명합니다.

# 최근 100줄 로그 확인
docker logs 컨테이너이름 --tail=100

# 새 로그를 계속 따라가기
docker logs -f 컨테이너이름

운영 입장에서는 이 로그를 무조건 삭제해야 한다고 생각하지 않는 게 중요했습니다. 하지만 만약 로그가 계속해서 커질 수 있는 구조라면, 오랜 기간 운영할 때 디스크 용량에 부담이 될 수도 있습니다.

Docker 로그는 서비스 출력 흐름과 연결되어 있었다

컨테이너 안에서 애플리케이션이 표준 출력이나 표준 오류로 남긴 내용은 Docker 로그에서 확인할 수 있습니다. 서비스마다 생성되는 로그의 양이 다르며, 예를 들어 n8n, 리버스 프록시, 미디어 서버, 테스트 컨테이너 등 각각의 로그 발생 패턴도 서로 다를 수 있습니다.

• 자동화 서비스 : 워크플로 실행 결과와 오류가 누적될 수 있음
• Reverse Proxy : 접속 로그와 오류 로그가 늘어날 수 있음
• 미디어 서버 : 스캔 작업이나 변환 작업 중 로그가 증가할 수 있음
• 테스트 컨테이너 : 반복 오류가 발생하면 짧은 시간에 로그가 빠르게 커질 수 있음

그래서 로그 관리는 단순히 특정 명령어 하나만 실행해서 끝나는 일이 아니었어요. 오히려 어떤 서비스가 얼마나 자주, 어떤 속도로 로그를 쌓는지 계속 지켜보는 과정에 더 가까웠습니다.

먼저 디스크 사용량부터 확인했다

로그 회전을 설정하기 전에 먼저 현재 디스크 사용량부터 살펴봤습니다. 디스크를 차지하는 주 원인이 로그파일인지, Docker 이미지나 volume 때문인지, 아니면 백업 파일 때문인지 구분해야 했기 때문입니다.

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

# Docker 데몬이 사용하는 디스크 사용량 확인
docker system df

# Docker 서비스 상태 확인
docker compose ps

docker system df는 Docker 데몬이 사용하는 디스크 공간 정보를 보여주는 명령입니다. 이미지, 컨테이너, 로컬 volume, 빌드 캐시가 어느 정도의 공간을 차지하는지 확인할 수 있어, 로그 관리와 별개로 Docker 전체 사용량을 보는 기준으로 유용했습니다.

다만 docker system df만으로 모든 로그의 세부 원인을 알 수 있는 것은 아닙니다. 운영 기록상 먼저 전체 사용량을 보고, 이후 컨테이너 로그와 서비스별 상태를 나눠 확인하는 방식이 더 현실적이었습니다.

json-file 로그 드라이버와 회전 설정을 확인했다

Docker는 다양한 로그 드라이버를 지원합니다. 공식 문서에 따르면, Docker는 컨테이너와 서비스의 정보를 수집할 때 여러 종류의 로그 드라이버를 사용할 수 있습니다. 그리고 각 Docker 데몬에는 기본으로 지정된 로그 드라이버가 있습니다. 

일반적인 Docker 환경에서는 json-file 로그 드라이버를 사용하는 경우가 많습니다. 장기 운영을 고려한다면 이 로그가 무제한으로 커지지 않도록 max-size와 max-file 같은 옵션을 검토할 수 있습니다.

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

위 설정은 예시입니다. max-size는 로그 파일 하나의 최대 크기 기준을 정하고, max-file은 보관할 로그 파일 개수를 제한하는 용도로 이해할 수 있습니다. 실제 값은 서비스 중요도, 디스크 용량, 장애 추적 필요성에 따라 다르게 잡는 편이 안전합니다.

daemon.json 변경은 신중하게 접근했다

Docker 로그 드라이버의 기본 설정은 보통 Docker daemon 설정 파일인 daemon.json에서 관리할 수 있습니다. Linux 환경에서는 일반적으로 /etc/docker/daemon.json 경로를 사용합니다.

# Docker daemon 설정 파일 편집 예시
sudo nano /etc/docker/daemon.json

설정을 바꾼 후에는 Docker 서비스를 다시 시작해야 변경 사항이 적용됩니다. 하지만 Docker를 재시작하면 현재 실행 중인 컨테이너에 영향을 줄 수 있기 때문에, 특히 원격으로 접속한 환경에서는 더욱 신중하게 진행해야 합니다.

# 설정 파일 문법 확인 후 Docker 재시작
sudo systemctl restart docker

# Docker 서비스 상태 확인
sudo systemctl status docker --no-pager

지금 구성에서는 바로 운영 서버에 적용하기보다는, 먼저 백업이 제대로 되어 있는지와 컨테이너 상태를 점검한 뒤에 적용하는 것이 더 나았습니다. 특히 외부 접속을 위한 리버스 프록시나 자동화 서비스가 돌아가고 있다면, 별도로 작업 시간을 정해서 진행하는 것이 훨씬 안전합니다.

기존 컨테이너 적용 범위도 확인해야 했다

Docker 데몬의 기본 로그 설정을 변경했다고 해도 기존에 실행 중인 모든 컨테이너의 로그 설정이 바로 동일하게 적용되는 것은 아닙니다. 실제 운영 환경에서는 각 컨테이너를 재생성하거나, 서비스별로 별도의 로그 설정이 적용되어 있는지 직접 확인해보는 과정이 필요할 수 있습니다.

# 컨테이너 로그 설정 확인 예시
docker inspect 컨테이너이름 --format='{{.HostConfig.LogConfig.Type}}'
docker inspect 컨테이너이름 --format='{{json .HostConfig.LogConfig.Config}}'

이 단계는 다소 번거로울 수 있지만, 장기적으로 시스템을 안정적으로 운영하려면 꼭 필요한 확인이었습니다. 로그 회전 설정을 모두 동일하게 적용했다고 생각할 수 있지만, 실제로는 일부 컨테이너에서 다른 설정을 사용하는 경우도 있습니다. 이런 차이 때문에 디스크 사용량이 예상과 다르게 늘어나거나 관리에 어려움이 생길 수 있으니, 꼼꼼하게 점검하는 게 중요합니다.

로그 삭제보다 로그 유지 기준이 더 중요했다

디스크 사용량이 늘어나면 대부분 먼저 "이걸 지워야 할까?"라는 고민을 하게 됩니다. 하지만 로그는 장애 원인을 추적할 때 꼭 필요한 자료입니다. 특히 컨테이너가 다시 시작되거나 어떤 작업이 실패했을 때 로그가 없으면, 어디서 문제가 생겼는지 파악하기가 훨씬 어렵습니다.

• 핵심 서비스는 최근 오류를 추적할 수 있을 만큼 로그를 남긴다.
• 테스트 컨테이너는 로그 보관 기간을 짧게 잡아도 된다.
• 접속 로그가 많은 서비스는 디스크 증가 속도를 따로 관찰한다.
• 무조건 삭제보다 회전 기준을 먼저 잡는다.

Intel N100으로 홈서버를 운영할 때는 로그를 오래 보관하는 것보다는, 최근 발생한 장애를 파악할 수 있을 만큼만 로그를 남기고 주기적으로 순환하는 방식이 훨씬 실용적이었습니다.

prune 계열 명령은 로그 관리와 구분했다

Docker 디스크 사용량을 볼 때 docker system prune 같은 명령이 떠오를 수 있습니다. 하지만 이 명령은 로그 회전 설정과는 성격이 다릅니다. Docker 공식 문서 기준으로 docker system prune은 사용하지 않는 컨테이너, 네트워크, 이미지, 그리고 옵션에 따라 volume까지 제거할 수 있습니다.

# 사용하지 않는 Docker 데이터 정리
docker system prune

# volume까지 포함하는 정리는 더 주의
docker system prune --volumes

운영 환경에서는 이 명령을 로그 관리의 대체 수단처럼 사용하지 않는 편이 안전했습니다. 특히 --volumes 옵션은 실제 서비스 데이터와 연결될 수 있으므로, 어떤 volume이 어떤 서비스와 관련되어 있는지 확인한 뒤 접근해야 합니다.

운영 로그

아래 표는 3주차 수요일을 기준으로 정리한 Docker 로그 회전과 디스크 사용량 점검 항목입니다. 실제 설정 값은 서비스 수나 로그 발생량, SSD 용량, 그리고 장애 추적의 필요성에 따라 달라질 수 있습니다.

점검 항목	확인 방법	운영 판단
컨테이너 로그	docker logs --tail=100	최근 오류 흐름 확인
전체 디스크	df -h	파일시스템 여유 공간 확인
Docker 사용량	docker system df	이미지·컨테이너·volume 사용량 파악
로그 드라이버	docker inspect	컨테이너별 로그 설정 확인
daemon 설정	/etc/docker/daemon.json	기본 로그 회전 정책 검토
Docker 상태	systemctl status docker	설정 변경 후 서비스 상태 확인

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

• Docker 로그는 단순히 지워야 할 파일이 아니라 장애 추적을 위한 운영 기록이었습니다.
• Intel N100 환경에서는 SSD 용량과 로그 발생량을 함께 보면서 회전 기준을 정하는 편이 현실적이었습니다.
• daemon.json 변경은 Docker 서비스 재시작을 동반할 수 있으므로, 운영 중인 컨테이너 상태를 먼저 확인하는 것이 안전했습니다.
• docker system prune은 로그 회전의 대체 수단이 아니며, 특히 volume 관련 옵션은 신중하게 다뤄야 했습니다.

참고 링크 (References)

1. Docker logging drivers configuration
2. docker logs reference
3. docker system df reference
4. docker system prune reference
5. Docker daemon logs

트러블슈팅

문제: Docker 서비스는 정상적으로 동작하지만 로그와 Docker 데이터가 계속 쌓이면서 디스크 사용량이 증가함

홈서버를 오랫동안 운영하다 보면 컨테이너의 로그, 이미지, 볼륨, 백업 파일 등도 자연스럽게 쌓이기 마련입니다. 이럴 때 로그를 바로 삭제하거나, prune 명령부터 무작정 실행하면 나중에 문제가 생겼을 때 원인을 찾기 어려워질 수 있습니다. 자칫하면 중요한 데이터까지 지워질 위험도 있으니 주의해야 합니다.

확인: 로그, 디스크 사용량, Docker 사용량, 컨테이너별 로그 설정을 순서대로 점검

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

# 전체 디스크 사용량 확인
df -h

# Docker 사용량 확인
docker system df

# 로그 드라이버 확인
docker inspect 컨테이너이름 --format='{{.HostConfig.LogConfig.Type}}'

# Docker 서비스 상태 확인
sudo systemctl status docker --no-pager

원인: 로그 회전 기준 없이 장기 운영하면서 컨테이너 로그와 Docker 데이터가 누적됨

해결: 서비스별 로그 필요성을 구분하고, max-size, max-file 기준을 검토한 뒤 Docker 로그 회전 정책을 적용

현재 구성에서는 로그를 완전히 삭제하는 것보다는, 최근 발생한 장애를 추적할 수 있을 정도로 로그를 남기고 순환시키는 방식이 훨씬 더 안정적으로 운영되었습니다.

마무리

Intel N100으로 홈서버를 오랫동안 돌리다 보면 Docker 서비스의 로그와 디스크 사용량을 신경 써야 할 때가 종종 찾아옵니다. 서비스 자체는 아무 문제 없이 돌아가더라도, 로그 파일이 계속 쌓이면 SSD 용량이 넉넉하지 않은 환경에서는 금방 디스크가 부족해질 수 있거든요. 그래서 주기적으로 로그를 점검하고, 필요하면 정리해 주는 습관이 중요합니다.

하지만 로그는 그저 쓸모없는 파일이 아니라, 시스템의 운영 과정을 기록한 자료입니다. 장애가 발생했을 때 원인을 파악하는 데 중요한 단서가 되기 때문에, 무턱대고 삭제하기보다는 적절한 기준을 정해 주기적으로 관리하는 것이 훨씬 현실적이었습니다.

수요일에는 결론이 분명했습니다. 홈서버를 운영할 때 단순히 서비스를 실행하는 것뿐만 아니라, 서비스에서 남기는 기록을 어떻게 보존하고 관리할지도 중요하다는 점을 알게 됐죠. 목요일에는 이 흐름을 계속 이어가면서 Reverse Proxy 구조와 외부에서 접속하는 방법을 좀 더 정리해보려고 합니다.