호스트 디스크가 가득 찼다는 이유만으로 Docker 로그가 원인이라고 단정할 수는 없습니다. 이미지, 볼륨, 애플리케이션 파일도 공간을 사용합니다. 이 글은 Linux Docker Engine과 Compose V2에서 표준 출력·표준 오류로 내보낸 컨테이너 로그를 점검하는 상황을 다룹니다.
현재 컨테이너의 로그 설정부터 확인합니다
Docker는 이 출력을 로깅 드라이버로 처리합니다. 기본 json-file 드라이버는 별도 제한이 없으면 로그가 계속 커질 수 있습니다. 반면 애플리케이션이 /app/logs 같은 경로에 직접 쓰는 파일에는 이 설정이 적용되지 않으므로, 먼저 어떤 로그가 증가하는지 구분해야 합니다. [1]
아래 명령에서 app은 실제 컨테이너 이름이나 ID로 바꿉니다. Docker 명령을 실행할 권한이 필요합니다. 첫 줄은 데몬의 기본값, 둘째 줄은 해당 컨테이너가 실제로 가진 설정입니다.
docker info --format '{{.LoggingDriver}}'
docker inspect --format '{{json .HostConfig.LogConfig}}' app
docker inspect --format '{{.LogPath}}' app기본값이 바뀌었어도 기존 컨테이너는 이전 설정을 유지할 수 있습니다. inspect 결과의 Type과 Config를 함께 확인합니다. LogPath는 로컬 로그 위치를 파악하는 단서이며, 드라이버에 따라 비어 있을 수 있습니다. 경로가 나온다고 그 파일을 직접 편집해도 된다는 뜻은 아닙니다. [2]
호스트의 파일시스템 사용량과 로그 저장 영역의 증가 추세도 대조합니다. 디스크 전체가 증가하는데 해당 로그 영역은 일정하다면 다른 저장 대상을 확인해야 합니다. Docker Desktop은 Linux 가상머신 안에서 동작하므로 이 글의 호스트 경로를 그대로 대입하지 않습니다.
파일 크기와 개수를 한 쌍으로 정합니다
json-file을 유지한다면 max-size와 max-file을 함께 지정합니다. max-size는 파일을 교체하는 크기 기준이고, max-file은 유지할 로그 파일 수입니다. max-file만 지정해서는 크기 기준 순환이 작동하지 않습니다. 예를 들어 10m와 3은 하루치 보관이 아니라 크기·개수 제한입니다. [1]
Compose에서는 기존 서비스 정의의 logging 항목에 아래 내용을 병합합니다. app은 예시 서비스 이름이며, 이미지·환경변수·볼륨 등 기존 설정을 이 조각으로 대체하지 않습니다. 서비스별 설정 방법은 Compose 공식 문서에서 확인할 수 있습니다. [4]
services:
app:
logging:
driver: json-file
options:
max-size: "10m"
max-file: "3"이 값은 예시입니다. 오류가 반복되면 같은 용량에서도 남는 시간 범위는 짧아집니다. 필요한 조사 기간 동안 발생하는 로그량을 관찰하고, 컨테이너 수와 호스트 여유 공간까지 고려해 정합니다. 중요한 기록을 외부로 수집한다면 로컬 로그가 순환하기 전에 전달되는지도 확인해야 합니다.
외부 수집기가 JSON 파일 형식에 의존하지 않는다면 local 드라이버도 검토할 수 있습니다. local은 기본적으로 파일당 20m, 5개 순환과 압축을 사용합니다. 전환 전에는 기존 수집 방식과 운영 도구의 호환성을 확인합니다. 드라이버를 바꿔도 앱이 별도 파일에 쓰는 로그까지 제한되지는 않습니다. [3]
설정 저장과 기존 컨테이너 적용을 구분합니다
Compose 파일을 저장했다고 실행 중인 컨테이너의 로그 정책이 즉시 바뀌지는 않습니다. 기존 컨테이너에는 원하는 설정으로 재생성하는 절차가 필요합니다. docker restart로 같은 컨테이너를 다시 시작하는 작업과 구분해야 합니다. [2]
아래는 현재 프로젝트의 app 서비스만 재생성하는 예시입니다. 작업 전에 보존할 로그를 정상 조회·수집 경로로 확보하고, 영속 데이터 연결과 서비스 중단 영향을 확인합니다. 재생성으로 컨테이너 쓰기 계층의 데이터와 기존 로컬 로그를 잃을 수 있으므로 보존이 필요한 항목을 먼저 분리합니다.
docker compose config
docker compose up -d --no-deps --force-recreate app
docker compose ps -q appconfig 출력은 병합된 설정을 확인하는 용도이며 민감한 환경값이 포함될 수 있어 외부 공유에 주의합니다. up 명령은 실제로 서비스를 중지·재생성할 수 있습니다. --no-deps는 의존 서비스를 함께 시작하지 않는 옵션이므로 필요한 의존 서비스가 정상 동작하는지 확인한 뒤 사용합니다. [5]
마지막 명령이 반환한 새 컨테이너 ID로 첫 절의 inspect를 다시 실행합니다. 인스턴스가 여러 개라면 각각 확인합니다. 설정값이 맞는지 확인한 뒤, 정상 운영 트래픽에서 docker logs --since 10m --tail 100 명령에 새 ID를 붙여 로그가 계속 조회되는지 살펴봅니다. 시험 환경에서 순환까지 검증하고 운영에서는 저장 영역의 증가 추세를 관찰합니다.
서버 전체 기본값을 바꾸려면 daemon.json의 log-driver와 log-opts를 기존 설정에 병합하고 Docker 데몬 재시작 영향을 검토합니다. 이 변경도 새로 생성한 컨테이너부터 적용됩니다. 기본값 변경만으로 기존 컨테이너 조치가 끝났다고 기록해서는 안 됩니다. [2]
결론
Docker가 관리하는 로그 파일에 외부 logrotate를 중복 적용하거나 직접 삭제·잘라내는 작업은 기본 대응으로 삼지 않는 편이 좋습니다. 공식 문서는 외부 도구로 로그 파일을 조작하면 로깅 동작에 예상하지 못한 문제가 생길 수 있다고 안내합니다. 이미 공간이 고갈됐다면 서비스 영향과 보존할 기록을 확인한 뒤 복구 여유부터 확보합니다. [1]
이 문제의 완료 기준은 설정 파일 수정이 아닙니다. 대상 로그의 식별, 보관 기준 결정, 컨테이너 재생성, 실효 설정 확인, 증가 추세 관찰까지 이어져야 합니다. 특히 보관 개수는 보관 일수를 보장하지 않으므로 장애 조사에 필요한 기록이 남는지도 함께 판단해야 합니다.