로그 로테이션(logrotate) 입문: 리눅스 디스크 관리 자동화의 원리와 실무 설정

서버를 운영하는 환경에서 로그는 시스템의 상태를 이해하고 문제를 추적하는 가장 기본적인 자료이지만, 동시에 방치하면 디스크를 조용히 잠식하는 부담 요소이기도 하다. 로그 로테이션(log rotation)은 이렇게 끊임없이 쌓이는 로그 파일을 일정한 규칙에 따라 분할, 보관, 삭제하여 저장 공간을 자동으로 관리하는 기법이며, 리눅스 계열 시스템에서는 logrotate라는 표준 도구가 이 역할을 담당한다. 이 글은 logrotate의 동작 원리와 설정 방식, 그리고 실무에서 흔히 마주치는 함정을 체계적으로 정리하여, 로그 관리 자동화를 처음 접하는 관리자가 신뢰할 수 있는 기준을 세울 수 있도록 돕는 데 목적이 있다.

 

 

 

 

 

 

 

 

▍ 로그 파일이 시스템에 남기는 부담

 

유닉스와 리눅스 시스템에서 대부분의 서비스는 자신의 동작 기록을 텍스트 형태의 로그 파일로 남긴다. 웹 서버의 접근 기록, 인증 데몬의 로그인 시도, 애플리케이션의 오류 메시지 등은 시간이 흐를수록 누적되며, 트래픽이 많은 환경에서는 하루 만에 수백 메가바이트에서 수 기가바이트 규모로 커지는 경우도 드물지 않다. 이러한 증가는 대체로 완만하게 진행되기 때문에 즉시 문제로 인식되지 않지만, 방치가 길어지면 결국 파일 시스템의 여유 공간을 소진하는 지점에 도달한다.

 

디스크가 가득 찬 서버는 단순히 로그를 더 쓰지 못하는 수준을 넘어, 새로운 파일 생성이나 임시 데이터 기록이 막히면서 서비스 자체가 정상적으로 동작하지 못하는 상황으로 이어질 수 있다. 데이터베이스가 쓰기에 실패하거나 세션 정보를 저장하지 못해 장애가 발생하는 사례가 대표적이다. 따라서 로그는 반드시 남겨야 하지만, 무한히 축적되도록 두어서는 안 된다는 상반된 요구를 동시에 만족시켜야 한다. 로그 로테이션은 바로 이 균형을 자동화된 방식으로 달성하기 위한 접근이다.

 

 

 

▍ 로그 로테이션이란 무엇인가

 

 

 

▍ 로테이션의 기본 개념

 

로테이션은 현재 기록 중인 로그 파일을 일정 시점에 밀어내고 새로운 빈 파일에 기록을 이어가는 과정을 뜻한다. 예컨대 access.log가 회전되면 그 내용은 access.log.1로 이름이 바뀌고, 이전의 access.log.1은 access.log.2로 밀려나는 식으로 세대(generation)가 이어진다. 관리자는 몇 세대까지 보관할지를 지정하며, 지정한 세대 수를 넘어선 가장 오래된 파일은 자동으로 삭제된다. 이 구조를 통해 로그의 총량이 일정한 상한 안에서 유지된다.

 

이러한 세대 관리 방식의 장점은 최근 기록은 세밀하게 남기면서도 오래된 기록은 점진적으로 정리한다는 점에 있다. 문제 분석에 필요한 정보는 대체로 최근 며칠에서 몇 주 사이에 집중되므로, 무한 보관 대신 합리적인 보관 기간을 설정하면 진단에 필요한 자료를 잃지 않으면서 저장 공간을 절약할 수 있다.

 

 

 

 

 

 

▍ logrotate의 위치와 실행 방식

 

logrotate는 상시 실행되는 데몬이 아니라, 주기적으로 한 번씩 호출되어 조건을 점검하고 필요한 회전을 수행한 뒤 종료되는 유틸리티다. 전통적으로는 cron이 매일 정해진 시각에 logrotate를 실행하는 방식이 널리 쓰였고, systemd를 채택한 현대 배포판에서는 logrotate.timer라는 타이머 유닛이 이 역할을 대신하는 경우가 많다. 두 방식 모두 결과적으로 하루 한 번 정도 logrotate를 구동한다는 점에서는 유사하다.

 

설정은 크게 두 위치에 나뉘어 존재한다. 전역 기본값을 담는 /etc/logrotate.conf 파일이 있고, 개별 서비스별 규칙은 /etc/logrotate.d/ 디렉터리 안에 별도의 파일로 두는 것이 관례다. 패키지가 설치될 때 해당 서비스의 로그 규칙 파일이 이 디렉터리에 자동으로 배치되는 구조이며, 관리자는 전역 설정을 건드리지 않고도 서비스 단위로 정책을 추가하거나 조정할 수 있다. 이러한 분리는 설정의 충돌을 줄이고 유지 관리를 단순하게 만든다.

 

 

 

▍ logrotate 동작 원리와 주요 설정 지시자

 

logrotate가 실행되면 각 설정 파일에 기술된 대상 로그를 하나씩 검토하면서, 지정된 조건이 충족되었는지 판단한다. 조건 충족 여부는 상태 파일에 기록된 마지막 회전 시각을 근거로 계산되며, 이 상태 파일은 일반적으로 /var/lib/logrotate/ 아래에 존재한다. 이 덕분에 logrotate는 실제로 여러 번 호출되더라도, 실제 회전은 조건이 만족될 때에만 수행한다.

 

logrotate의 동작을 결정하는 것은 설정 파일 안의 지시자(directive)들이다. 대표적인 지시자와 그 기능을 정리하면 다음과 같으며, 이 항목들의 조합이 로그 관리 정책의 뼈대를 이룬다.

 

 

 

 

이 가운데 rotate는 보관 세대 수를 결정하므로 저장 공간 총량과 직결되고, compress는 오래된 로그의 부피를 줄여 공간 효율을 크게 높인다. 텍스트 로그는 압축률이 높은 편이어서, 압축만으로도 상당한 절약 효과를 기대할 수 있다는 점이 실무에서 자주 활용된다.

 

 

 

▍ 로테이션 주기와 보관 정책 설계

 

회전 주기와 보관 세대 수는 로그의 성격과 서비스 규모에 따라 달라져야 한다. 매우 활발한 웹 서버라면 매일 회전이 적절하지만, 트래픽이 적은 내부 도구라면 주 단위나 월 단위가 오히려 관리에 유리할 수 있다. 반면 폭증 가능성이 있는 로그, 즉 특정 오류가 반복되면서 순식간에 커질 수 있는 로그에는 시간 기반보다 크기 기반 조건이 더 안전하다.

 

 

 

 

보관 기간을 정할 때는 저장 공간뿐 아니라 규정과 운영 정책도 함께 고려하는 편이 바람직하다. 보안 사고 분석이나 감사 목적으로 일정 기간 이상 로그를 남겨야 하는 경우가 있고, 반대로 개인정보가 포함된 로그는 필요 이상으로 오래 보관하지 않는 편이 안전하다. 이처럼 로그 보관 정책은 순수한 기술적 판단만이 아니라 조직의 요구를 반영하는 결정이므로, 획일적인 기본값을 그대로 두기보다 서비스별로 검토하는 것이 권장된다.

 

 

 

 

 

 

▍ 압축과 후처리, copytruncate 같은 세심한 고려사항

 

단순히 파일 이름을 바꾸는 것만으로 로테이션이 완결되지 않는 경우가 많다. 대표적인 예가 기록 중인 프로세스가 파일 핸들을 계속 붙잡고 있는 상황이다. 로그 파일의 이름이 바뀌더라도 프로세스는 여전히 열린 파일 기술자를 통해 예전 파일에 계속 기록할 수 있는데, 이 경우 새 파일에는 아무 내용도 쌓이지 않고 이미 회전된 파일만 커지는 문제가 생긴다.

 

이 문제를 해결하는 방식은 크게 두 가지로 나뉜다. 첫째는 create와 postrotate 조합으로, 회전 이후 새 빈 파일을 만들고 후처리 스크립트를 통해 해당 프로세스에 로그 파일을 다시 열도록 신호를 보내는 방식이다. 웹 서버나 데몬이 재열기 신호를 지원하는 경우 가장 깔끔하며 로그 유실 위험도 낮다. 둘째는 copytruncate 방식으로, 원본 파일의 내용을 복사한 뒤 원본을 비워 버리는 방법이다. 프로세스를 건드리지 않아도 되므로 재열기 신호를 지원하지 않는 소프트웨어에 유용하지만, 복사와 비우기 사이의 짧은 순간에 기록되는 로그가 유실될 가능성이 이론적으로 존재한다는 점은 감안해야 한다.

 

압축과 관련해서도 세심한 판단이 필요하다. delaycompress는 가장 최근에 회전된 파일을 한 세대 동안 압축하지 않고 남겨 두는 지시자인데, 이는 프로세스가 아직 이전 파일에 기록을 마치지 못한 상황에서 압축이 겹쳐 데이터가 손상되는 것을 막기 위한 안전장치다. 따라서 copytruncate나 재열기 방식과의 조합을 고려하여 압축 시점을 조율하는 것이 안정적인 운영으로 이어진다.

 

 

 

▍ 실무에서 자주 마주치는 함정

 

logrotate 설정에서 흔히 발생하는 오류 중 하나는 새 로그 파일의 권한과 소유자가 잘못 지정되는 경우다. 회전 이후 create가 만든 파일의 소유자가 실제 기록 프로세스와 맞지 않으면, 서비스가 로그를 쓰지 못하고 조용히 실패할 수 있다. 이런 문제는 즉시 드러나지 않고 로그가 사라진 뒤에야 발견되는 경우가 많아 주의가 필요하다.

 

또한 여러 설정 파일에서 같은 로그 파일을 중복으로 지정하면 예기치 않은 충돌이 발생한다. logrotate는 하나의 대상이 둘 이상의 규칙에 걸릴 때 경고를 내며 정상적으로 처리하지 못할 수 있으므로, /etc/logrotate.d/ 안의 규칙들이 서로 겹치지 않도록 관리해야 한다. 설정을 변경한 뒤에는 실제 회전 없이 규칙을 점검하는 방식으로 미리 검증하여, 운영 중 예상치 못한 동작을 방지하는 습관이 권장된다.

 

 

 

▍ systemd 저널과의 관계 및 비교

 

현대 리눅스 배포판은 systemd의 저널(journald)이라는 별도의 로깅 체계를 함께 운용한다. 저널은 로그를 구조화된 바이너리 형태로 저장하고 자체적인 크기 제한과 보관 정책을 갖고 있어, 텍스트 파일을 대상으로 하는 logrotate와는 관리 대상과 방식이 다르다. 따라서 두 체계는 대체 관계라기보다 서로 다른 영역을 담당하는 보완 관계로 이해하는 편이 정확하다.

 

많은 환경에서는 저널이 시스템 서비스의 로그를 관리하는 동시에, 전통적인 텍스트 로그를 남기는 애플리케이션과 웹 서버에 대해서는 logrotate가 계속 관여한다. 어느 한쪽만으로 모든 로그를 통제하려 하기보다, 각 서비스가 어떤 방식으로 로그를 남기는지 파악한 뒤 그에 맞는 관리 도구를 적용하는 것이 현실적인 접근이다. 로그 관리의 목표는 특정 도구의 사용 자체가 아니라, 필요한 기록을 확보하면서 저장 공간을 안정적으로 유지하는 데 있기 때문이다.

 

 

 

 

 

 

▍ 결론

 

로그 로테이션은 화려한 기능이 아니라 시스템을 조용히 안정적으로 유지하는 기반 작업에 해당한다. logrotate는 회전 주기, 보관 세대 수, 압축, 후처리 같은 지시자의 조합을 통해 로그의 총량을 통제하며, 이를 자동화함으로써 관리자가 매번 수작업으로 개입할 필요를 없앤다. 핵심은 서비스의 성격에 맞는 주기와 보관 정책을 설계하고, 파일 재열기나 권한 설정 같은 세부 사항을 정확히 다루어 로그 유실이나 서비스 실패를 예방하는 데 있다.

 

처음 설정할 때는 실제 회전 전에 규칙을 점검하고, 회전 이후 로그가 정상적으로 새 파일에 기록되는지 확인하는 절차를 거치는 것이 안전하다. 로그 관리 자동화는 한 번 잘 구성해 두면 오랫동안 손이 가지 않는 영역인 만큼, 초기 설계에 충분한 주의를 기울일 가치가 있다. 자신이 운영하는 시스템의 로그 디렉터리를 한 번 살펴보고, 어떤 파일이 어떤 속도로 커지고 있는지 점검하는 것에서부터 견고한 디스크 관리 습관이 시작된다.