[Linux] journald 로그 관리: systemd 실전 트러블슈팅 5가지

목차

• 1. journald가 중요한 이유: 파일 로그만 보던 습관에서 벗어나야 합니다
• 2. 기본 개념 먼저: journalctl은 어떻게 봐야 덜 헷갈릴까
• 3. 실전 트러블슈팅 1: 로그가 너무 많아서 원인을 못 찾을 때
• 3-1. 시간 범위로 자르기
• 3-2. 서비스 단위로 좁히기
• 3-3. 에러 우선순위만 보기
• 4. 실전 트러블슈팅 2: 재부팅 후 로그가 사라지는 문제
• 4-1. 현재 저장소 상태 확인
• 4-2. 영구 저장 활성화
• 5. 실전 트러블슈팅 3: 디스크가 차오르는 원인이 journald일 때
• 5-1. 현재 사용량 확인
• 5-2. 즉시 정리하기
• 5-3. 아예 정책으로 제한하기
• 6. 실전 트러블슈팅 4: 서비스는 죽었는데 원인이 안 보일 때
• 6-1. 특정 부팅 세션 기준으로 보기
• 6-2. 서비스 실시간 추적
• 6-3. 상세 상태 확인과 묶어서 보기
• 7. 실전 트러블슈팅 5: 로그 형식이 불편하거나 파이프라인 연동이 필요할 때
• 7-1. 출력 형식 바꾸기
• 7-2. 최근 로그 일부만 빠르게 확인
• 7-3. grep과 함께 써서 빠르게 패턴 찾기
• 8. 운영 중 자주 겪는 주의사항: 제가 삽질했던 포인트들
• FAQ: 많이 받는 질문
• 9. 검증과 마무리: 제대로 설정됐는지 이렇게 확인하면 됩니다

[Linux] journald 로그 관리: systemd 실전 트러블슈팅 5가지

서버 장애는 꼭 바쁜 시간에 터지더라고요. 특히 journald 로그 관리가 제대로 안 되어 있으면, 분명 에러는 났는데 로그가 어디 갔는지부터 찾게 됩니다. 저도 홈랩에서 Rocky Linux, Ubuntu 계열 서버를 굴리면서 처음엔 /var/log만 뒤지다가 시간을 꽤 날렸습니다. 근데 systemd 기반 배포판에서는 journalctl 하나만 제대로 익혀도 장애 대응 속도가 확 달라지거든요. 이번 글에서는 제가 실제로 자주 쓰는 Linux 트러블슈팅 방식 기준으로, 운영 중 바로 써먹을 수 있는 로그 분석 팁 5가지를 정리해보겠습니다.

systemd와 journald가 서비스 로그를 수집하고 조회하는 전체 흐름을 보여주는 개요 이미지입니다.

1. journald가 중요한 이유: 파일 로그만 보던 습관에서 벗어나야 합니다

쉽게 말해 journald는 systemd 환경에서 로그를 모아두는 중앙 저장소 역할을 합니다. 전통적인 텍스트 로그 파일처럼 보이는 방식과는 조금 다르죠. 서비스별 로그, 부팅 세션별 로그, 우선순위(priority), 커널 메시지까지 한 번에 엮어서 볼 수 있다는 게 핵심입니다.

처음엔 이게 뭔가 싶었는데, 실제로 써보니까 특정 서비스가 언제 죽었는지, 재시작되기 직전에 어떤 에러가 있었는지 추적하기가 훨씬 편했습니다. 특히 컨테이너 호스트나 작은 홈서버처럼 서비스 수가 늘어나는 환경에서는 로그가 여기저기 흩어져 있으면 진짜 피곤하거든요.

• journalctl: journald 로그 조회 도구
• persistent logging(영구 저장): 재부팅 후에도 로그 유지
• priority(우선순위): error, warning 같은 중요도 기준 필터링
• boot scope(부팅 범위): 특정 부팅 시점 로그만 추적

2. 기본 개념 먼저: journalctl은 어떻게 봐야 덜 헷갈릴까

저도 처음엔 journalctl 치고 로그가 너무 많이 나와서 바로 닫았습니다. 그래서 저는 아래 순서로 익히는 걸 추천합니다.

1. 전체 로그보다 서비스 단위로 보기
2. 시간 범위를 자르기
3. 우선순위를 걸어서 에러만 보기
4. 부팅 단위로 사고 시점을 좁히기

가장 먼저 익혀둘 명령은 이 정도입니다.

# 전체 로그 최근 부분 보기
journalctl -e

# 특정 서비스 로그 보기
journalctl -u nginx.service

# 최근 부팅 기준 로그 보기
journalctl -b

# 에러 레벨만 보기
journalctl -p err

# 실시간 추적
journalctl -f

여기서 중요한 포인트! -u, -b, -p, --since만 익혀도 현장에서 체감이 큽니다. 쓸데없이 로그 바다에 빠지지 않게 해주거든요.

3. 실전 트러블슈팅 1: 로그가 너무 많아서 원인을 못 찾을 때

이건 정말 흔합니다. 로그는 있는데 너무 많아요. 특히 장시간 운영한 서버에서 전체 로그를 그냥 열면 필요한 줄 찾다가 집중력이 먼저 떨어집니다. 제가 직접 해보니 이럴 땐 시간 범위 + 서비스명 + 우선순위를 같이 거는 게 제일 효율적이었습니다.

3-1. 시간 범위로 자르기

journalctl --since "2026-07-15 09:00:00" --until "2026-07-15 10:00:00"

journalctl --since "30 min ago"

journalctl --since today

장애가 9시 20분쯤 났다는 제보가 있으면, 굳이 하루치 전체를 볼 필요가 없죠. 이 범위를 먼저 줄이는 것만으로도 노이즈가 꽤 사라집니다.

3-2. 서비스 단위로 좁히기

journalctl -u docker.service --since "30 min ago"
journalctl -u ssh.service -e
journalctl -u NetworkManager.service -b

예를 들어 SSH 접속 장애면 ssh.service, 컨테이너 이슈면 docker.service부터 보시면 됩니다. 서비스 이름이 헷갈릴 때는 아래처럼 확인해두면 편합니다.

systemctl list-units --type=service
systemctl status nginx.service

3-3. 에러 우선순위만 보기

journalctl -p warning
journalctl -p err
journalctl -p crit..alert

저는 급할 때 journalctl -p err -b부터 봅니다. 큰 줄기부터 잡고, 그다음 상세 로그로 내려가는 방식이 훨씬 빠르더라고요.

시간 범위, 서비스, 우선순위 필터를 조합해 로그를 줄여나가는 과정을 보여주는 이미지입니다.

4. 실전 트러블슈팅 2: 재부팅 후 로그가 사라지는 문제

처음 홈랩을 꾸렸을 때 이걸로 꽤 삽질했습니다. 분명 어젯밤에 장애가 있었는데, 아침에 다시 보니 로그가 안 남아 있는 거예요. 이유는 간단했습니다. persistent logging(영구 저장)이 꺼져 있었던 겁니다.

4-1. 현재 저장소 상태 확인

journalctl --disk-usage
ls -ld /var/log/journal

/var/log/journal 디렉터리가 없으면 메모리 기반 저장만 되는 경우가 있습니다. 배포판 설정에 따라 동작이 다를 수 있어서, 실제 상태를 먼저 확인하는 게 안전합니다.

4-2. 영구 저장 활성화

sudo mkdir -p /var/log/journal
sudo systemd-tmpfiles --create --prefix /var/log/journal
sudo systemctl restart systemd-journald

환경에 따라 /etc/systemd/journald.conf에서 저장 정책을 명시하는 게 더 깔끔할 때도 있습니다.

sudo editor /etc/systemd/journald.conf

[Journal]
Storage=persistent
SystemMaxUse=1G
RuntimeMaxUse=200M
MaxRetentionSec=1month

설정 후에는 데몬을 다시 읽혀줍니다.

sudo systemctl restart systemd-journald
journalctl -b -1

-b -1이 보이면 이전 부팅 로그까지 남고 있다는 뜻입니다. 드디어 됐다! 싶은 순간이 여기서 나오죠.

5. 실전 트러블슈팅 3: 디스크가 차오르는 원인이 journald일 때

로그는 남겨야 하지만, 무한정 쌓아두면 결국 디스크를 압박합니다. 특히 작은 SSD나 VM 디스크에서는 이게 꽤 치명적이거든요. journald 로그 관리에서 운영자가 가장 먼저 챙겨야 할 부분 중 하나가 용량 정책입니다.

5-1. 현재 사용량 확인

journalctl --disk-usage

5-2. 즉시 정리하기

# 7일보다 오래된 로그 삭제
sudo journalctl --vacuum-time=7d

# 총 사용량을 500M 이하로 줄이기
sudo journalctl --vacuum-size=500M

# 파일 개수 기준 정리
sudo journalctl --vacuum-files=10

운영 중 급하게 용량을 비워야 할 때 정말 유용합니다. 다만 무작정 지우기 전에 꼭 필요한 장애 분석이 끝났는지는 확인하셔야 합니다.

5-3. 아예 정책으로 제한하기

[Journal]
SystemMaxUse=1G
SystemKeepFree=500M
SystemMaxFileSize=100M
MaxRetentionSec=1month

저는 홈랩에서는 과하게 크게 잡지 않습니다. 분석 가능한 기간은 유지하되, 디스크 여유 공간도 남겨야 하니까요. 여기서 중요한 건 숫자 자체보다 정책을 명시해두는 습관입니다.

옵션	의미	언제 유용한가
SystemMaxUse	journal 전체 최대 사용량	디스크 점유 상한을 명확히 두고 싶을 때
SystemKeepFree	남겨둘 최소 여유 공간	서비스 디스크 고갈을 예방할 때
MaxRetentionSec	로그 보관 기간	기간 기준으로 운영 정책을 맞출 때
--vacuum-size	즉시 용량 기준 정리	긴급 대응 시

journald 로그 용량을 확인하고 정리하기 전후 차이를 보여주는 시각 자료입니다.

6. 실전 트러블슈팅 4: 서비스는 죽었는데 원인이 안 보일 때

이럴 때는 서비스 상태만 보지 말고, 이전 부팅 기록과 실시간 추적을 같이 봐야 합니다. 특히 재시작이 반복되는 서비스는 순간적으로 죽었다 살아나서 놓치기 쉽습니다.

6-1. 특정 부팅 세션 기준으로 보기

journalctl --list-boots
journalctl -b -1
journalctl -b -2 -u nginx.service

배포 후 재부팅이 있었는지, 장애가 이전 부팅부터 이어진 건지 확인할 때 굉장히 유용합니다. 저도 커널 업데이트 이후 네트워크 서비스가 꼬인 적이 있었는데, 부팅별로 나눠보니 원인이 바로 보이더라고요.

6-2. 서비스 실시간 추적

journalctl -u myapp.service -f

애플리케이션 재시작 테스트를 하면서 한쪽 터미널에서는 이 명령을 띄워두면 편합니다. 장애 재현과 동시에 로그를 보게 되니까, 놓치는 줄이 확 줄어듭니다.

6-3. 상세 상태 확인과 묶어서 보기

systemctl status myapp.service
journalctl -u myapp.service -n 100 -o short-iso

systemctl status는 현재 상태 요약, journalctl은 상세 로그 본문이라고 생각하시면 이해가 쉽습니다.

7. 실전 트러블슈팅 5: 로그 형식이 불편하거나 파이프라인 연동이 필요할 때

운영하다 보면 사람 눈으로만 보는 로그보다, 다른 도구로 넘기기 좋은 형식이 필요할 때가 있습니다. 예를 들어 자동화 스크립트, 간단한 grep 처리, 또는 JSON 수집 파이프라인 같은 경우죠.

7-1. 출력 형식 바꾸기

journalctl -u nginx.service -o short-iso
journalctl -u nginx.service -o json
journalctl -u nginx.service -o cat

개인적으로 사람 눈으로 볼 땐 short-iso를 자주 씁니다. 타임스탬프가 읽기 편해서요. 반면 후처리나 수집 연계가 필요하면 json 출력이 꽤 쓸만합니다.

7-2. 최근 로그 일부만 빠르게 확인

journalctl -u nginx.service -n 50
journalctl -k -n 100

-k는 커널 로그를 보는 옵션입니다. 디스크 I/O나 네트워크 드라이버 문제처럼 시스템 하단 이슈를 의심할 때 먼저 보는 편입니다.

7-3. grep과 함께 써서 빠르게 패턴 찾기

journalctl -u docker.service --since "1 hour ago" | grep -i error
journalctl -b | grep -Ei "timeout|failed|denied"

엄밀히 말하면 structured log(구조화 로그)의 장점을 다 살리는 방식은 아니지만, 현장에선 이렇게 빠르게 감 잡는 경우도 많습니다. 급할 때는 일단 보이는 게 중요하거든요.

서비스 로그를 실시간으로 추적하고 다양한 출력 형식으로 확인하는 예시 이미지입니다.

8. 운영 중 자주 겪는 주의사항: 제가 삽질했던 포인트들

여기부터는 진짜 실무형 메모입니다. 문서만 보면 안 보이는데, 실제로는 아래 포인트에서 많이 막히더라고요.

• ⚠️ 권한 문제: 일반 사용자로는 일부 시스템 로그가 제한될 수 있습니다. 안 보이면 sudo로 다시 확인해보세요.
• ⚠️ 로그가 없다고 장애가 없는 건 아닙니다: 애플리케이션이 stdout/stderr로 안 남기면 journald에도 부족하게 남을 수 있습니다.
• ⚠️ 영구 저장 설정 후 재시작 필요: 설정 파일만 바꾸고 journald 재시작을 안 해서 헷갈리는 경우가 많습니다.
• ⚠️ 너무 aggressive한 vacuum: 로그를 급하게 지웠다가, 나중에 RCA(Root Cause Analysis, 근본 원인 분석) 못 하는 상황이 생깁니다.
• ⚠️ 시간 동기화 확인: NTP가 어긋나면 로그 해석이 꼬입니다. 사건 순서가 뒤집혀 보이기도 하거든요.

여기서 중요한 포인트! journald 로그 관리는 단순히 용량 정리만 의미하지 않습니다. 남겨야 할 로그를 남기고, 필요한 순간에 바로 찾을 수 있게 만드는 운영 습관에 가깝습니다.

FAQ: 많이 받는 질문

Q. rsyslog가 있으면 journald는 안 써도 되나요?
아닙니다. 둘은 배타적이라기보다 함께 쓰는 경우가 많습니다. journald로 빠르게 조회하고, 필요하면 다른 로그 시스템으로 전달하는 식이죠.

Q. journalctl이 너무 느릴 때는요?
시간 범위, 서비스명, 부팅 범위를 먼저 줄여보세요. 전체 검색부터 하면 당연히 체감이 무겁습니다.

Q. Linux 트러블슈팅에서 가장 먼저 볼 명령 하나만 고르라면?
저는 journalctl -p err -b를 자주 씁니다. 현재 부팅의 에러를 먼저 보고 큰 줄기를 잡기 좋거든요.

9. 검증과 마무리: 제대로 설정됐는지 이렇게 확인하면 됩니다

설정은 했는데 정말 잘 적용됐는지 확인하는 단계가 중요합니다. 아래 순서대로 보면 웬만한 건 검증됩니다.

1. journalctl --disk-usage로 저장량 확인
2. journalctl --list-boots로 이전 부팅 로그 유지 여부 확인
3. journalctl -u 서비스명 -f로 실시간 수집 확인
4. journalctl -p err -b로 에러 필터 확인
5. systemctl restart systemd-journald 이후 동작 재확인

journalctl --disk-usage
journalctl --list-boots
journalctl -b -1
journalctl -u ssh.service -n 20 -o short-iso
journalctl -p err -b

이 다섯 줄만 점검해도 현재 서버의 journald 상태를 꽤 명확하게 파악할 수 있습니다. 저도 처음엔 파일 로그만 찾다가 돌아왔는데, 이제는 장애가 나면 거의 반사적으로 journalctl부터 엽니다. 이거 진짜 편하더라고요.

정리하자면, 이번 글의 핵심은 이겁니다. journald 로그 관리는 로그를 보는 기술이 아니라, 장애 순간에 증거를 잃지 않는 운영 방식입니다. persistent 설정으로 로그를 남기고, 시간/서비스/우선순위 필터로 빨리 좁히고, vacuum 정책으로 디스크를 보호하면 기본기는 꽤 단단해집니다.

다음 글에서는 systemd 서비스 유닛 파일 튜닝이나, rsyslog와의 연계, 중앙 로그 수집 구조도 이어서 다뤄볼 예정입니다. 이전 글에서 다뤘던 리눅스 서비스 장애 대응 흐름과 연결해서 보시면 더 이해가 잘 되실 거예요. 혹시 지금 운영 중인 서버에서 로그가 자꾸 증발하거나, 디스크가 로그 때문에 차는 경험 있으신가요? 그럴 때 오늘 소개한 5가지를 하나씩 적용해보시면 방향이 꽤 빨리 잡히실 겁니다.

journald 설정과 검증 포인트를 한눈에 정리한 요약 인포그래픽 이미지입니다.

📚 함께 읽으면 좋은 글

• Arch Linux 마이그레이션: Debian에서 Arch로 전환한 이유와 과정
• Fedora Ubuntu 비교: 1년 써본 홈 서버 분석
• systemd 서비스 오류 진단 및 해결: journalctl 활용법