서버를 오래 운영하다 보면 장애 자체보다 로그 관리 부실이 더 큰 문제를 만들 때가 많습니다. 

디스크가 갑자기 차거나, 필요한 시점의 로그가 이미 사라졌거나, 로그는 많은데 어디부터 봐야 할지 몰라

시간이 낭비되기도 합니다. 

이런 상황을 줄이려면 로그를 "많이 남기는 것"보다 예측 가능하게 보관하고, 필요할 때 빨리 확인하는 운영 루틴이 중요합니다.

이번 글은 리눅스 서버 운영 관점에서 logrotate와 journalctl을 함께 써서 로그를 정리하고 점검하는 기본 루틴을 소개합니다.

배포 직후 한 번만 세팅해도 이후 운영 피로도가 꽤 줄어듭니다.

 

1. 먼저 로그가 어디에 쌓이는지 구분하기

리눅스 서버에서는 로그가 보통 두 갈래로 쌓입니다.

  • 애플리케이션 또는 일부 데몬 로그: /var/log/ 아래 파일 형태
  • systemd 저널 로그: journalctl로 조회하는 바이너리 로그

이 둘을 섞어서 생각하면 관리가 꼬이기 쉽습니다. 

예를 들어 Nginx 접근 로그는 파일 기반일 가능성이 높고, 

서비스 시작 실패나 유닛 메시지는 journalctl에서 확인하는 편이 더 빠릅니다.

> 운영 초반에는 "이 서비스 로그는 파일인지, 저널인지"부터 정리해두면 장애 대응 속도가 확실히 빨라집니다.

2. logrotate로 파일 로그가 무한정 커지지 않게 만들기

logrotate는 오래된 로그를 압축하거나, 일정 개수만 남기고 정리하는 데 쓰입니다. 

대부분 배포판에 기본 포함되어 있지만 설정이 서비스별로 충분하지 않은 경우도 있습니다.

현재 어떤 설정이 있는지 먼저 확인합니다.

ls /etc/logrotate.d cat /etc/logrotate.conf

예를 들어 /var/log/myapp/*.log를 운영 중이라면 아래처럼 서비스별 설정 파일을 둘 수 있습니다.

/var/log/myapp/*.log {    daily    rotate 14    compress    missingok    notifempty    copytruncate }

각 옵션 의미는 아래 정도만 기억해도 실무에 충분합니다.

  • daily: 하루마다 회전
  • rotate 14: 최근 14개 보관
  • compress: 오래된 로그 gzip 압축
  • missingok: 로그 파일이 없어도 에러 없이 진행
  • notifempty: 빈 로그는 회전하지 않음
  • copytruncate: 프로세스를 재시작하지 않고 현재 파일을 잘라서 계속 쓰게 함

> copytruncate는 편하지만, 쓰기 타이밍에 따라 일부 로그가 어긋날 수 있습니다. 

서비스가 로그 재오픈 신호를 지원하면 그 방식이 더 안정적입니다.

설정을 추가한 뒤에는 실제 적용 전 테스트를 해보는 습관이 좋습니다.

sudo logrotate -d /etc/logrotate.conf

강제로 한 번 돌려 확인하려면 다음 명령을 씁니다.

sudo logrotate -f /etc/logrotate.conf

3. journalctl은 "지금 무슨 일이 일어나는지" 볼 때 가장 강력하다

시스템 서비스 운영에서는 파일 로그보다 journalctl이 더 빠를 때가 많습니다.

특히 systemd 서비스, 부팅 이력, 최근 에러 확인에 강합니다.

자주 쓰는 기본 명령은 아래 몇 개면 충분합니다.

journalctl -u nginx -n 100 --no-pager journalctl -u ssh --since "today" journalctl -p err -b --no-pager journalctl -xeu myapp.service

이 명령들을 상황별로 보면 이렇습니다.

  1. 특정 서비스 최근 로그 보기
  2. 오늘 기준 서비스 로그만 보기
  3. 현재 부팅 세션에서 에러 우선순위 로그만 보기
  4. 서비스 실패 원인을 자세히 보기

실시간 추적이 필요하면 -f 옵션을 붙입니다.

journalctl -u myapp.service -f

운영자 입장에서는 장애가 났을 때 여러 파일을 헤매기보다, 

먼저 journalctl -u 서비스명 -n 100으로 최근 흐름을 보는 습관이 훨씬 효율적입니다.

4. systemd 저널도 보관 한도를 정해두는 편이 안전하다

저널 로그 역시 방치하면 디스크를 예상보다 많이 사용할 수 있습니다. 

특히 메모리 적은 VPS나 소형 디스크 환경에서는 한도를 정해두는 편이 안전합니다.

현재 디스크 사용량은 이렇게 확인할 수 있습니다.

journalctl --disk-usage

보관 정책은 /etc/systemd/journald.conf에서 관리합니다. 

예시는 아래처럼 둘 수 있습니다.

[Journal]

SystemMaxUse=500M

SystemKeepFree=1G

MaxRetentionSec=14day

운영 의미는 다음과 같습니다.

  • SystemMaxUse=500M: 저널이 최대 500MB까지만 사용
  • SystemKeepFree=1G: 디스크 여유 공간 1GB는 남기도록 시도
  • MaxRetentionSec=14day: 최대 14일까지만 보관

설정 변경 뒤에는 재시작이 필요합니다.

sudo systemctl restart systemd-journald

이미 쌓인 로그를 즉시 정리하려면 아래처럼 vacuum 기능을 쓸 수 있습니다.

sudo journalctl --vacuum-time=14d sudo journalctl --vacuum-size=500M

5. 서버 운영 루틴으로 묶으면 더 효과적이다

로그 관리가 잘되는 서버는 특별한 비밀이 있는 게 아니라, 짧은 점검 루틴이 반복되는 서버인 경우가 많습니다. 

아래 정도만 주간 루틴에 넣어도 운영 안정성이 올라갑니다.

> 매주 한 번은 로그 저장 용량, 최근 에러, 오래된 압축 로그 개수 정도를 같이 확인하는 것이 좋습니다.

추천 점검 순서:

  1. df -h로 디스크 여유 공간 확인
  2. journalctl --disk-usage로 저널 사용량 확인
  3. /var/log에서 큰 파일 상위 몇 개 확인
  4. journalctl -p err -b로 최근 부팅 에러 확인
  5. logrotate -d 또는 서비스별 설정 검토

큰 로그 파일을 찾는 예시는 아래처럼 간단합니다.

sudo find /var/log -type f -size +100M -ls

6. 운영 팁: 로그는 "보관"보다 "찾기 쉽게"가 더 중요하다

로그를 무작정 오래 보관한다고 운영이 쉬워지지는 않습니다. 오히려 적절한 기간만 보관하고, 

서비스별 위치와 확인 명령을 팀 안에서 통일하는 편이 더 낫습니다.

실무적으로는 아래 원칙이 효과적입니다.

  • 서비스별 주요 로그 확인 명령을 문서화하기
  • 파일 로그와 저널 로그를 혼동하지 않기
  • 디스크 작은 서버는 저널 한도를 꼭 두기
  • logrotate 테스트 없이 운영 반영하지 않기
  • 장애 대응 때는 최근 50~100줄부터 보기

마무리

리눅스 서버 운영에서 로그는 남기는 것 자체보다 잘 돌리고, 적절히 줄이고, 빨리 읽는 체계가 중요합니다.

logrotate는 파일 로그를 정리하고, journalctl은 서비스 상태와 장애 흐름을 빠르게 보여줍니다.

이 둘을 함께 관리하면 디스크 폭주도 줄이고, 문제 분석 속도도 훨씬 나아집니다.

서버를 여러 대 운영 중이라면 오늘 한 번 각 서버에서 journalctl --disk-usage와 logrotate 설정만 확인해도

꽤 쓸모 있는 점검이 될 겁니다.