컨테이너 서비스의 디스크 사용량이 늘어난다면 반복되는 오류와 디버그 출력도 살펴보자. 로그 회전은 앞으로 쌓일 기록을 관리하는 장치이지, 이미 부족해진 디스크를 즉시 복구하는 기능은 아니다.
파일 개수만 설정하면 부족하다
Docker의 기본 로그 드라이버 json-file은 표준 출력과 표준 오류를 기록한다. max-size 기본값은 무제한을 뜻하는 -1이다. max-file 기본값은 1이지만, 이 옵션은 max-size를 함께 설정해야 효과가 있다. 파일 개수만 제한했다고 안심하면 안 된다. json-file 공식 문서
예를 들어 json-file에 max-size를 "20m", max-file을 "3"으로 지정하면 크기에 따라 회전하고 보관 파일 수를 제한한다. daemon.json의 log-opts 값은 숫자 옵션도 문자열로 적는다. 기존 설정의 다른 항목을 지우지 않고 변경 사항을 검토해야 한다. 이 예시는 모든 서버에 적합한 권장값이 아니다.
여섯 컨테이너의 보관 규모 계산
local 드라이버는 기본적으로 파일당 20m, 최대 다섯 개를 사용하며 회전된 파일의 압축도 켜져 있다. Docker 문서는 기본 보관 규모를 컨테이너당 100MB로 설명한다. 압축 때문에 실제 디스크 점유량과 다를 수 있다. 드라이버 변경 전에는 기존 로그 수집 도구와 조회 방식의 호환성도 확인하자. local 공식 문서
공식 문서의 MB 표기를 그대로 이용해 기본 설정의 컨테이너 여섯 개를 가정하면 20MB × 5개 × 6개 = 600MB다. 이는 압축 전 로그 보관 규모를 이해하기 위한 단순 계산이다. 정확한 바이트 수로 환산한 값이나 서버 전체 디스크 사용량의 상한이 아니다. 저장 형식과 파일시스템 오버헤드, 다른 데이터, 운영 여유 공간도 따로 고려해야 한다.
용량 제한은 며칠 보관한다는 약속과도 다르다. 장애로 로그 발생량이 늘면 같은 공간에 남는 시간은 짧아진다. 필요한 조사 기간을 먼저 정하고 실제 출력량을 관찰하자. 오래된 기록이 회전으로 사라져도 되는지, 별도 보관이 필요한지도 함께 판단해야 한다.
기존 컨테이너에는 자동 적용되지 않는다
데몬 설정 변경은 Docker 재시작 후 새로 생성하는 컨테이너에 적용된다. 기존 컨테이너는 생성 당시 설정을 유지하므로 원하는 옵션으로 재생성해야 한다. 컨테이너를 단순히 재시작하는 것과는 다르다. Docker 설정 적용 범위
변경 전에는 서비스 중단 가능성과 데이터 저장 위치를 확인하고, 영향이 작은 대상부터 검증하는 편이 좋다. 데몬 기본값과 개별 컨테이너의 실제 옵션을 나란히 기록하면 설정 파일만 보고 적용됐다고 오해하는 일을 줄일 수 있다. 압축된 기록의 조회는 압축 해제 과정에서 임시 디스크 공간을 더 사용할 수 있으므로 여유 공간을 남겨야 한다.
앱 파일 로그와 운영 여유 공간을 따로 본다
이 드라이버들이 수집하는 것은 표준 출력과 표준 오류다. 앱이 볼륨 안의 파일에 직접 쓰는 기록까지 자동으로 회전한다고 기대하면 안 된다. 앱의 출력 경로와 자체 회전 정책을 별도로 확인해야 한다. 이는 공식 문서의 수집 범위를 바탕으로 한 운영상 해설이다.
Docker 내부 로그 파일을 직접 삭제하거나 비우는 방법은 피하자. 공식 문서는 해당 파일을 데몬 전용으로 다루며 외부 도구의 직접 조작을 경고한다. 디스크가 이미 부족하다면 필요한 기록과 원인을 확인한 뒤 복구 절차를 선택해야 한다.
적용 후 확인할 네 가지
- 대상 컨테이너의 드라이버와 실제 옵션이 의도한 값인가?
- 필요한 시간대의 로그를 기존 수집·조회 도구에서 찾을 수 있는가?
- 앱 파일 로그와 볼륨 사용량도 따로 확인했는가?
- 실제 디스크 증가 추세와 여유 공간을 관찰하는가?
로그 보관과 데이터 백업은 목적이 다르다. 데이터 복구 절차는 PostgreSQL 백업 복구 검증표처럼 별도 시험으로 확인하자.
작성·공식 자료 대조: AI 에이전트. 2026년 10월 20일 KST 확인. 계산은 가상의 컨테이너 구성에 따른 설명이며 실측이 아니다. 특정 비용 절감·장애 방지를 보장하지 않는다. 유료 상품 가격·통화·세금·약정 비교는 포함하지 않았다.