journalctl 치트시트: Linux 로그 확인, 필터링, 실시간 추적

journalctl을 한 줄로 요약하면: journalctl -u <service> -f는 서비스 로그를 실시간으로 따라가고, journalctl -u <service> -n 100은 마지막 100줄을 보여주고, journalctl --since "1 hour ago"는 최근 기록을 전부 보여줍니다. “서비스가 왜 죽었지” 순간의 90%가 이 세 가지로 끝납니다. 이 치트시트의 나머지는 새벽 2시에 man page를 다시 펼치지 않게 해 주는 복붙용 패턴들입니다 — 유닛·시간·우선순위·부팅 단위 필터링에 더해, 저널이 디스크를 잠식하지 못하게 막는 정리 명령까지. 아래의 모든 명령은 systemd를 쓰는 배포판(Ubuntu, Debian, Fedora, Arch)이라면 그대로 동작합니다.

journalctl이란 무엇이고, 왜 /var/log/syslog를 직접 읽으면 안 될까?

옛날 방식의 리눅스 로깅은 /var/log 아래에 텍스트 파일을 썼습니다 — syslog, auth.log, messages. systemd는 이 모두를 저널(journal)로 대체했습니다: systemd-journald가 관리하는 바이너리 인덱스형 로그입니다. 평범한 grep으로는 읽을 수 없고, journalctl이 유일한 출입구입니다. 대신 정규식 곡예 없이 서비스·시간·부팅·심각도 기준 필터링이 가능해집니다.

멘탈 모델은 단순합니다: 저널에는 모든 것이 저장되고, journalctl은 그 조회 도구입니다. 서비스는 자체 로그 파일이 필요 없습니다 — systemd 아래에서 실행되는 동안 stdout/stderr에 쓰는 것은 전부 자동으로 저널에 떨어집니다. nginx가 에러 로그를 어디에 설정했는지 몰라도 journalctl -u nginx가 동작하는 이유입니다.

한 가지 주의점: 일부 미니멀 설치에서는 /var/log/journal이 없어서 저널이 휘발성입니다(/run에 저장, 재부팅 시 삭제). 한 번만 고쳐두면 됩니다:

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

로그의 마지막 100줄을 보려면?

-n은 출력을 가장 최근 N줄로 제한합니다(기본값은 10):

journalctl -n 100                      # 전체의 마지막 100줄
journalctl -u nginx -n 100             # 한 유닛의 마지막 100줄
journalctl -n 100 --no-pager           # 출력하고 종료 — 파이프용으로 딱

--no-pager는 보기보다 중요합니다: 이 옵션이 없으면 journalctl이 less를 열고, 스크립트·파이프·ssh 한 줄 명령은 키 입력을 기다리며 멈춥니다. 출력을 파이프로 넘기는 명령에는 항상 붙이세요.

tail -f처럼 로그를 실시간으로 따라가려면?

-f 플래그가 journalctl의 tail -f입니다 — 새 항목이 생기는 대로 스트리밍합니다:

journalctl -f                    # 전체, 실시간
journalctl -u sshd -f            # SSH 데몬만, 실시간
journalctl -u ollama -f -n 50    # 실시간, 마지막 50줄부터 시작

첫 번째 터미널에서 서비스를 재시작하는 동안 두 번째 터미널에 띄워두는 명령입니다: 한 패널에서 systemctl restart nginx, 다른 패널에서 journalctl -u nginx -f, 그러면 크래시 원인은 보통 몇 초 안에 스스로 드러납니다. 컨테이너나 서비스가 말썽일 때마다 homelab에서 정확히 이 루프를 돌립니다.

특정 서비스의 로그만 보려면?

-u는 systemd 유닛 기준으로 필터링합니다:

journalctl -u nginx                    # 유닛 하나, 전체 히스토리
journalctl -u nginx -u redis           # 여러 유닛 한 번에
journalctl _SYSTEMD_UNIT=nginx.service # 정확히 일치하는 대안

유닛은 흥미로운 출력을 가져가는 보조 유닛을 만들기도 합니다 — 죽어가는 웹 앱이 진짜 에러를 다른 유닛 아래에 기록하는 경우가 있죠. -u <service>가 아무것도 보여주지 않는데 서비스는 분명히 돌고 있다면, 실제 유닛 이름부터 찾으세요:

systemctl list-units --type=service | grep -i <guess>

같은 -u 패턴이 타이머(이름은 systemctl list-timers로 확인)와 사용자 서비스에도 통합니다 — systemd --user 아래에서 도는 것은 --user를 붙이세요:

journalctl --user -u pipewire -n 50

로그를 시간으로 필터링하려면?

--since와 --until은 타임스탬프를 받지만, 관대한 상대 표현도 받습니다:

journalctl --since "1 hour ago"
journalctl --since "2026-09-01 09:00" --until "2026-09-01 12:00"
journalctl --since today
journalctl --since yesterday --until now -u cron

시간 창과 유닛을 조합하면 한 줄짜리 장애 분석이 됩니다: “09:00부터 API가 쓰러진 시점까지 뭘 기록했지?” 한 대짜리 머신에서는 그 어떤 로그 수집기보다 빠릅니다.

에러(또는 경고)만 보려면?

-p는 syslog 심각도 이름 기준으로 우선순위를 필터링합니다:

journalctl -p err -b              # 에러만, 이번 부팅 기준
journalctl -p warning..alert -u nginx   # 심각도 범위 지정

우선순위는 내림차순으로 emerg, alert, crit, err, warning, notice, info, debug입니다. 머신이 “평소와 다르게 굴 때” journalctl -p err -b --since today가 가장 빠른 이상 유무 확인입니다 — 일상적인 info 라인 소음 없이 “실제로 뭔가 실패하고 있는가?”에 답합니다.

이전 부팅의 로그를 보려면?

시작 시점에 크래시하는 서비스는 현재 부팅 이전에 로그를 남기는데, journalctl은 기본적으로 현재 부팅만 보여줍니다. -b가 부팅을 선택합니다:

journalctl -b                 # 현재 부팅만
journalctl -b -1              # 이전 부팅
journalctl -b -1 -u sshd      # 지난번에 SSH가 왜 죽었는지
journalctl --list-boots       # 저장된 부팅의 인덱스

“고장 났고, 재부팅했고, 이제 에러가 안 보인다” 상황에서 가장 유용한 플래그입니다 — 에러는 그대로 있습니다, 한 부팅 뒤에.

빠른 참고: 외워둘 만한 플래그

목표	명령
서비스 하나 실시간 추적	journalctl -u <svc> -f
마지막 100줄	journalctl -n 100
1시간 전 이후	journalctl --since "1 hour ago"
이번 부팅의 에러	journalctl -p err -b
이전 부팅	journalctl -b -1
저널의 디스크 사용량	journalctl --disk-usage
기계 판독 가능한 출력	journalctl -o json-pretty
커널 메시지만	journalctl -k

저널이 디스크를 채우지 못하게 하려면?

비용을 확인한 뒤 상한을 겁니다:

journalctl --disk-usage
sudo journalctl --vacuum-size=500M     # 최근 500 MB만 유지
sudo journalctl --vacuum-time=30d      # 최근 30일만 유지

상한을 영구적으로 만들려면 /etc/systemd/journald.conf의 [Journal] 섹션에 SystemMaxUse=500M을 넣고 sudo systemctl restart systemd-journald를 실행합니다. 크기 상한과 위의 부팅 필터가 있으면 저널은 도구로 머물지, 느린 디스크 누수로 변하지 않습니다.

journalctl vs dmesg vs /var/log — 어디를 먼저 봐야 할까?

• journalctl — 애플리케이션과 서비스의 동작. systemd가 관리하는 것은 전부 여기에, 인덱스와 필터와 함께. 기본 첫 번째 출발점.
• journalctl -k / dmesg — 커널과 하드웨어: OOM 킬, USB 리셋, 디스크 에러. 프로세스가 이유 없이 죽었다면 앱 탓하기 전에 여기서 OOM 킬러를 찾으세요.
• /var/log/<app>/ — 자체 파일 로깅을 하는 앱만(nginx access log, PostgreSQL). 그 경우에도 시작 시점 에러는 대개 저널에 떨어집니다.

같은 워크플로는 로컬 AI 서비스에도 통합니다 — ollama serve 유닛이 멈추면 journalctl -u ollama -n 100이 모델 로드 실패를 바로 보여줍니다. 자세한 내용은 Ollama vs LM Studio 비교에 있습니다.

이것으로 치트시트의 전부입니다: 유닛은 -u, 추적은 -f, 줄 수는 -n, 시간은 --since, 심각도는 -p, 부팅은 -b. 플래그 여섯 개면 리눅스 머신이 던지는 거의 모든 로그 질문에 답할 수 있습니다.