AI 생성 이미지: 성인 개발자가 쌓인 로그 보관 폴더와 노트북을 함께 확인하는 장면

파이썬 로그 파일이 계속 커질 때: 크기 기준과 시간 기준 로테이션 선택법

by

Python 자동화 로그 파일이 계속 커진다면, 먼저 FileHandler 대신 크기 기준의 RotatingFileHandler 또는 시간 기준의 TimedRotatingFileHandler 중 보관 정책에 맞는 핸들러를 선택해야 합니다. 파일이 특정 용량을 넘을 때 나눌지, 정해진 시간 주기에 맞춰 나눌지가 핵심 기준입니다. 보관 기간보다 디스크 사용량을 우선하면 크기 기준을, 날짜별 확인과 운영 리포트를 우선하면 시간 기준을 먼저 검토하면 됩니다.

FileHandler를 그대로 두면 로그가 계속 커지는 이유

일반적인 FileHandler는 로그를 파일에 기록하는 역할은 하지만, 파일을 일정 크기나 시간마다 자동으로 나누는 정책을 제공하지 않습니다. 장시간 실행되는 자동화에서 같은 app.log에 계속 기록하면 과거 로그를 보존하는 동안 파일도 계속 커질 수 있습니다.

이때 중요한 것은 “로그를 남길 것인가”가 아니라 “언제 새 파일로 넘기고, 이전 파일을 어디까지 보관할 것인가”입니다. 이 두 결정을 표준 로깅 핸들러의 설정으로 분리하면 운영 기준을 코드에 남길 수 있습니다.

크기가 문제라면 RotatingFileHandler

하루 중 특정 시간대에 로그가 갑자기 몰리거나, 디스크 사용량을 일정 범위 안에서 관리해야 한다면 RotatingFileHandler가 더 자연스럽습니다. maxBytes에 가까워지면 현재 파일을 백업 파일로 돌리고 새 파일에 기록을 이어 갑니다. backupCount는 남겨 둘 백업 파일 수를 정합니다.

import logging
from logging.handlers import RotatingFileHandler

handler = RotatingFileHandler(
    "app.log",
    maxBytes=10 * 1024 * 1024,
    backupCount=5,
    encoding="utf-8",
)
logging.basicConfig(level=logging.INFO, handlers=[handler])

위 예제에서 maxBytes는 파일 하나의 상한을 정하는 값이고, backupCount는 과거 파일을 몇 개 남길지 정하는 값입니다. 따라서 두 값을 따로 보지 말고 “한 파일을 어느 정도 크기로 유지할지”와 “몇 번의 이전 상태가 필요한지”를 함께 정해야 합니다.

backupCount=5라면 현재 기록 파일 외에 .1부터 .5까지의 백업 파일을 유지하는 방식입니다. 실제 디스크 사용량은 로그 한 줄의 크기와 기록 패턴에 따라 달라지므로, 이 설정을 정확한 총 용량 보장으로 해석해서는 안 됩니다.

날짜와 시간 흐름이 중요하면 TimedRotatingFileHandler

날짜별 파일을 확인하거나 하루 단위로 운영 기록을 넘겨야 한다면 TimedRotatingFileHandler를 검토합니다. when과 interval의 조합으로 회전 주기를 정하고, backupCount로 시간 기준 백업의 보관 개수를 정합니다.

import logging
from logging.handlers import TimedRotatingFileHandler

handler = TimedRotatingFileHandler(
    "app.log",
    when="midnight",
    interval=1,
    backupCount=14,
    encoding="utf-8",
    utc=True,
)
logging.basicConfig(level=logging.INFO, handlers=[handler])

when="midnight"와 interval=1은 자정 주기의 설정입니다. utc=True를 사용하면 UTC를 기준으로 시간을 계산하고, 기본값에서는 로컬 시간을 기준으로 계산합니다. 서버의 지역 시간과 운영자가 보는 기준 시간이 다르면 이 선택을 명시하는 편이 안전합니다.

시간 기준 회전은 지정된 시각에 프로세스가 실제로 로그를 기록할 때 관찰될 수 있습니다. 로그가 전혀 발생하지 않는 동안에도 파일이 즉시 분리된다고 가정하지 말고, 유휴 시간이 긴 작업이라면 이 동작을 운영 점검 항목에 포함하는 것이 좋습니다.

두 핸들러 중 무엇을 선택할까

판단 순서는 다음처럼 단순하게 잡을 수 있습니다.

운영 상황 우선 검토할 핸들러 설정의 중심
로그 폭주 때 파일 크기를 제한해야 함 RotatingFileHandler maxBytes, backupCount
날짜별·시간별로 파일을 구분해야 함 TimedRotatingFileHandler when, interval, backupCount
두 조건을 동시에 엄격하게 적용해야 함 별도 운영 설계 검토 단일 핸들러의 한계와 보관 정책

크기 기준은 로그량이 일정하지 않은 자동화에 대응하기 쉽습니다. 반면 파일이 언제 바뀌었는지 날짜로 바로 파악해야 하는 운영이라면 시간 기준이 읽기 편합니다. 하루 로그량이 매우 큰데도 날짜 기준만 고르면 한 파일이 지나치게 커질 수 있고, 반대로 작은 로그를 짧은 주기로 나누면 파일 관리 부담이 커질 수 있습니다.

backupCount를 정하는 실무 순서

backupCount를 먼저 임의로 정하기보다 다음 질문에 답해 보시기 바랍니다.

  1. 장애가 발생했을 때 과거 로그를 어느 기간까지 확인해야 하는가?
  2. 한 파일의 크기 또는 한 주기의 로그량이 디스크 여유 공간에 맞는가?
  3. 로그 보관이 끝난 뒤 별도 저장소로 옮기는 절차가 있는가?

크기 기준에서는 maxBytes와 보관 개수를 곱해 대략적인 보관 규모를 가늠할 수 있지만, 기록량과 파일시스템 상황에 따라 실제 사용량은 달라집니다. 시간 기준에서는 interval을 바꾸면 기존 시간 접미사 파일의 삭제 대상 판정이 기대와 달라질 수 있으므로, 운영 중 설정을 바꿀 때 기존 파일을 별도로 확인해야 합니다.

적용 전 확인할 것

  • 파일 경로와 실행 계정이 해당 디렉터리에 기록할 수 있는지 확인합니다.
  • encoding="utf-8"처럼 읽는 환경을 고려한 인코딩을 명시합니다.
  • 서버가 여러 시간대를 사용한다면 utc 기준과 운영자의 확인 시간을 합의합니다.
  • 멀티프로세스가 하나의 파일에 직접 기록하는 구조라면 이 글의 단일 핸들러 선택만으로 안전성을 보장한다고 보지 않습니다. 이 경우에는 QueueHandler와 QueueListener를 이용해 파일 핸들러를 한 곳에서 처리하는 별도 설계가 필요합니다.

로그 자체가 생성되지 않는 문제라면 먼저 파이썬 로그 파일이 안 생기는 이유와 logging 설정 점검법에서 로거와 경로를 확인한 뒤, 파일이 정상적으로 기록될 때 이 글의 회전 정책을 적용하는 순서가 좋습니다.

정리

파일 크기 제한이 우선이면 RotatingFileHandler에 maxBytes와 backupCount를 설정하고, 날짜나 시간 단위의 구분이 우선이면 TimedRotatingFileHandler에 when, interval, backupCount를 설정합니다. backupCount는 현재 파일까지 포함한 총 용량을 고정하는 값이 아니므로 로그량과 디스크 여유를 함께 점검해야 합니다. 마지막으로 시간대, 유휴 시간의 회전 동작, 멀티프로세스 기록 여부까지 확인하면 단순히 파일을 나누는 데서 그치지 않고 실제 운영에 맞는 로그 보관 정책을 세울 수 있습니다.

출처: Python logging.handlers 공식 문서, Python Logging Cookbook, Python Logging HOWTO

Leave a Comment