로그 파일 로테이션 실패 시 디스크 공간 포화와 서비스 중단

증상 확인: 디스크가 100% 찼다는 경고가 뜨나요?

서버 관리자 콘솔이나 모니터링 도구에서 디스크 사용량이 100%에 근접했다는 경고를 받았습니다. 애플리케이션 로그가 기록되지 않거나, 특정 서비스가 갑자기 응답을 멈추기 시작합니다, df -h (linux) 또는 디스크 관리(windows) 명령을 실행하면 로그가 저장되는 파티션(예: /var/log 또는 c:\program files\application\logs)의 사용 가능 공간이 0바이트 또는 극도로 낮게 표시됩니다. 이는 로그 파일 로테이션 메커니즘이 제대로 작동하지 않아 단일 로그 파일이 무한정 커지거나, 오래된 로그 파일이 삭제되지 않아 발생하는 전형적인 증상입니다.

원인 분석: 왜 로테이션이 실패하는가

로그 로테이션은 설정된 조건(파일 크기, 기간)에 도달하면 현재 로그 파일의 이름을 변경(예: app.log -> app.log.1)하고 새로운 빈 로그 파일을 시작하며, 오래된 파일은 삭제하는 프로세스입니다. 이 과정이 실패하는 주된 원인은 세 가지입니다. 첫째, 로테이션 도구(예: Linux의 logrotate, 애플리케이션 내장 로거)의 설정 파일에 오류가 있습니다. 둘째, 로그 파일이나 대상 디렉토리에 대한 쓰기 권한이 부족합니다. 셋째, 가장 교활한 원인으로, 로그를 기록하는 프로세스가 파일 핸들을 계속 점유하고 있어 로테이션 도구가 파일 이름 변경이나 삭제를 수행할 수 없는 경우입니다. 이는 애플리케이션을 재시작하지 않고 로그 로테이션만 수행할 때 흔히 발생합니다.

긴급 대응: 디스크 공간 확보 (Method 1)

서비스가 중단된 상태에서는 원인 분석보다 선행되어야 할 긴급 조치가 있습니다. 디스크 공간을 즉시 확보하여 시스템이 기본 기능을 되찾을 수 있게 하는 것입니다. 가장 큰 파일을 찾아 임시로 처리하십시오.

1. 가장 큰 파일 찾기: Linux에서는 sudo du -ah /var/log | sort -rh | head -20 명령어를 실행합니다. Windows에서는 WinDirStat, TreeSize와 같은 도구를 사용하거나, PowerShell에서 Get-ChildItem -Path C:\Path\To\Logs -Recurse | Sort-Object Length -Descending | Select-Object -First 10 Name, @{Name="Size(GB)";Expression={[math]::Round($_.Length / 1GB, 2)}}를 실행합니다.
2. 로그 파일 내용 비우기: 완전 삭제(rm)보다는 내용만 비우는 것이 더 안전합니다. 서비스가 해당 파일을 여전히 사용 중일 수 있기 때문입니다. Linux: sudo truncate -s 0 /var/log/application/huge.log. Windows: PowerShell에서 Clear-Content C:\Logs\huge.log.
3. 임시 파일/오래된 로그 삭제: *.tmp, *.log.7z (7일 전 로그) 등 명확히 불필요한 파일을 삭제합니다. find /var/log -name "*.log.*" -mtime +30 -delete (30일 지난 로그 삭제).

주의: rm -rf 명령어는 신중하게 사용해야 합니다. 일례로 루트(/) 디렉토리에서 실수로 실행하면 시스템이 파괴됩니다. 항상 삭제 전 ls 명령으로 대상 파일을 다시 확인하는 습관이 필수입니다. 중요한 점은 windows에서도 휴지통을 거치지 않는 영구 삭제 명령은 동일한 위험성을 가집니다.

근본적 해결: 로테이션 설정 진단 및 수정 (Method 2)

공간을 확보했다면, 로테이션이 실패한 근본 원인을 찾아 수정해야 합니다. 대부분의 문제는 설정 파일에 있습니다.

Linux (logrotate)의 경우

주 설정 파일은 /etc/logrotate.conf이며, 애플리케이션별 설정은 /etc/logrotate.d/ 디렉토리에 있습니다. 다음 항목을 점검하십시오.

• rotate 카운트: rotate 4는 최신 파일 포함 5개만 유지한다는 의미입니다. 디스크 크기에 맞게 조정 필요.
• size/일자 조건: size 100M 또는 daily 지시어가 올바르게 설정되었는지 확인.
• postrotate 스크립트 (가장 중요): 로그를 쓰는 프로세스에게 새 파일을 사용하도록 알려주는 신호를 보내야 합니다. Apache의 경우 postrotate /bin/systemctl reload apache2.service > /dev/null 2>&1 || true, 다른 프로세스는 kill -HUP $(cat /var/run/application.pid) 형식이 일반적입니다. 이 스크립트가 없거나 잘못되면 로테이션 후에도 프로세스는 이전 파일 핸들을 고수합니다.
• 테스트 실행: 설정 파일을 수정한 후, sudo logrotate -d /etc/logrotate.d/yourapp 명령으로 디버그 모드로 실행하여 문제점을 확인합니다. 강제 실행은 sudo logrotate -vf /etc/logrotate.d/yourapp 입니다.

Windows 서비스/애플리케이션의 경우

내장 로거를 사용하는 경우(예: log4net, NLog, Serilog) 해당 애플리케이션의 구성 파일(.config, .json, .xml)을 확인합니다.

1. 롤링 파일 어펜더 설정 찾기: 구성 파일 내에서 rollingFile, maxArchiveFiles, maximumFileSize, archiveAboveSize와 같은 키워드를 검색합니다.
2. 올바른 경로와 권한 확인: 로그 파일이 기록되는 디렉토리에 애플리케이션을 실행하는 사용자 계정(예: NETWORK SERVICE, 특정 서비스 계정)에 쓰기 및 수정 권한이 있는지 확인합니다.
3. 파일 점유 문제 해결: Windows에서는 프로세스가 파일을 독점적으로 잠그는 경우가 많습니다. 로테이션을 ‘날짜별’로 설정하여 매일 새 파일을 생성하도록 하거나, 애플리케이션에서 파일 점유 모드를 공유 읽기/쓰기로 설정할 수 있는지 확인합니다.

고급 문제 해결: 파일 핸들 점유와 모니터링 (Method 3)

설정이 완벽함에도 로그 로테이션이 빈번히 실패한다면, 이는 프로세스의 파일 핸들 관리 문제일 확률이 매우 높습니다. 시스템 수준의 진단을 위해 sudo lsof /var/log/yourapp/app.log 명령을 실행하면 해당 파일을 점유 중인 프로세스 ID(PID)를 즉시 파악할 수 있습니다. 실제로 운영 환경의 현장 관측 사례를 분석해 보면, 로테이션 이후 프로세스가 새 파일로 핸들을 전환하지 못해 기존 삭제된 파일에 계속 쓰기를 시도하는 패턴이 반복됩니다. 이를 해결하기 위해 postrotate 스크립트로 HUP 신호를 보내거나 copytruncate 옵션을 활용할 수 있습니다. 다만, copytruncate는 파일 내용을 비우는 짧은 찰나에 로그 누락이 발생할 수 있는 구조적 트레이드오프가 존재하므로 시스템의 데이터 정밀도에 따라 신중한 선택이 필요합니다.

Windows – 리소스 모니터 활용: ‘리소스 모니터(resmon.exe)’를 실행한 후 ‘CPU’ 탭의 ‘연결된 핸들’ 검색창에 로그 파일명(예: ‘.log’)을 입력합니다. 파일을 점유하고 있는 프로세스를 찾을 수 있습니다. 해당 프로세스를 안전하게 재시작하는 것이 가장 확실한 해결책입니다.

모니터링 체계 구축: 문제가 발생한 후 대응하는 것보다 예방하는 것이 중요합니다. 다음 지표를 모니터링 도구에 추가하십시오.

• 로그 디렉토리의 디스크 사용률 (임계값: 80%)
• 가장 큰 로그 파일의 크기와 증가 추이
• logrotate 크론 작업의 최근 실행 성공/실패 여부
• 로그 파일 수 (임의의 증가는 로테이션 실패 징후)

주의사항 및 예방 조치

로그 로테이션은 단순한 유지보수 작업이 아니라 시스템 안정성의 핵심입니다. 다음 사항을 명심하십시오.

• 설정 파일 변경 전 백업: /etc/logrotate.d/yourapp 파일을 수정하기 전에 반드시 sudo cp yourapp yourapp.backup_$(date +%Y%m%d) 와 같이 백업을 생성합니다.
• 테스트 환경 검증: 새로운 로그 설정은 반드시 스테이징(테스트) 환경에서 충분히 테스트한 후 프로덕션(운영) 환경에 적용합니다. 로테이션 주기, 권한, 디스크 공간 소모를 확인합니다.
• 중앙 집중식 로깅 고려: 서버가 많거나 로그의 중요도가 높다면, 로그를 로컬 디스크에만 의존하지 말고 Rsyslog, Fluentd, Logstash 등을 통해 중앙 로그 저장소(예: Elasticsearch, 클라우드 로그 서비스)로 전송하는 아키텍처를 도입하십시오. 이는 로컬 디스크 포화 문제에서 벗어나게 해주며, 로그 분석과 보안 감사에도 유리합니다.
• 로그 레벨 관리는 운영 안정성을 위해 필수적인 요소입니다. 개발 중이나 문제 추적 과정에서 사용하던 DEBUG 레벨 로깅을 프로덕션 환경에 그대로 유지하면 로그 파일 크기가 기하급수적으로 증가할 수 있습니다. 이는 데이터 압축 해제 시 메모리 사용량 급증으로 OOM(Out of Memory)이 발생하는 상황과 유사하게, 자원 사용이 통제되지 않을 때 서비스 전반에 부담을 주는 원인이 됩니다. 따라서 운영 환경에서는 로그 레벨을 INFO 또는 WARN 수준으로 조정하는 것이 바람직합니다.

전문가 팁: 프로세스 재시작 없이 안전한 로그 전환
Linux에서 copytruncate는 편리하지만 순간적인 로그 손실 위험이 있습니다. 더 안전한 방법은 애플리케이션에 표준 시그널을 지원하도록 요구하는 것입니다. 그러나 지원하지 않는다면, 네임드 파이프(named pipe)를 활용한 우회책을 고려할 수 있습니다. 애플리케이션이 특정 파일에 로그를 쓰도록 설정하는 대신, mkfifo로 생성한 네임드 파이프에 쓰도록 합니다. 그리고 별도의 데몬(예: cat > actual.log)이 이 파이프에서 데이터를 읽어 실제 로그 파일에 기록하게 합니다. 로테이션 시점에는 이 데몬 프로세스만 재시작하면 되므로 애플리케이션에는 영향을 주지 않습니다. 이는 고가용성이 요구되는 핵심 서비스에서 유용한 패턴입니다. 구현 복잡도가 증가하므로, 충분한 테스트 후 도입해야 함을 명심하십시오.