tail -f vs journalctl 차이 — 리눅스 로그 모니터링, 언제 뭘 쓸까

새벽에 서버가 죽었다는 알림을 받고 터미널을 열었을 때, 손가락이 먼저 치는 명령이 그 사람 짬밥을 말해준다. 누군가는 tail -f /var/log/... 를 때리고, 누군가는 journalctl -u ... -f 를 친다. 둘 다 "로그를 실시간으로 본다"는 같은 목적인데, 두 명령은 애초에 보고 있는 대상이 다르다. 이 차이를 모르고 섞어 쓰다 "로그가 텅 비었다"며 당황하는 경우를 실무에서 자주 본다.

둘은 "같은 로그"를 보는 게 아니다

먼저 깔고 가야 할 게 있다. tail 과 journalctl 은 경쟁 도구가 아니라, 리눅스 로깅의 서로 다른 두 세계에 각각 사는 도구다.

tail -f 는 그냥 텍스트 파일을 따라 읽는다. /var/log/nginx/access.log, 애플리케이션이 직접 떨구는 app.log 처럼 디스크에 쌓이는 평범한 파일이면 뭐든 대상이다. 로그가 파일로 존재하는 한 tail 은 거의 만능이다.

journalctl 은 systemd 저널을 읽는다. 요즘 배포판(Ubuntu 16.04+, CentOS 7+, Debian 8+)은 systemd 가 서비스를 관리하면서, 각 서비스가 stdout/stderr 로 내뱉는 로그를 바이너리 저널에 통째로 모은다. 이건 텍스트 파일이 아니라서 cat 이나 tail 로 못 읽는다. 전용 도구 journalctl 이 필요한 이유다.

핵심은 이거다. 당신 서비스가 로그를 "파일"로 쓰면 tail, "systemd 서비스의 표준출력"으로 흘리면 journalctl. 어느 쪽인지 모르겠으면 둘 다 때려보면 된다 — 데이터가 나오는 쪽이 정답이다.

뭐가 어떻게 다른가 — 한눈에

tail 의 강점은 단순함과 보편성이다. 파일만 있으면 어떤 유닉스 계열에서도 똑같이 동작하고, 파이프로 grep·awk 에 넘기기도 자연스럽다. 반대로 "어제 오후 3시에서 4시 사이, nginx 만, 에러 레벨만" 같은 교차 조건 검색은 tail 혼자선 버겁다. grep 을 몇 겹씩 쌓아야 한다.

journalctl 은 그 조건 검색을 옵션 하나로 끝낸다. 대신 systemd 없는 환경(일부 컨테이너, 오래된 유닉스)에선 아예 못 쓴다. 강함과 전제 조건이 맞바꿔지는 셈이다.

실전 — 자주 쓰는 명령만 추렸다

tail 쪽부터. 실시간 추적의 기본이다.

# 파일 끝을 실시간으로 따라감
tail -f /var/log/nginx/access.log

# 로그 로테이션에도 안 끊기게(파일이 새로 만들어져도 계속 추적)
tail -F /var/log/nginx/access.log

# 마지막 200줄부터 보여주고 이어서 실시간 추적
tail -n 200 -f /var/log/app.log

# 에러만 걸러서 실시간
tail -f /var/log/app.log | grep -i error

여기서 -f 와 -F 차이는 꼭 짚고 가자. 소문자 -f 는 열어둔 파일 그 자체(inode)를 붙든다. 로그 로테이션으로 파일이 교체되면 옛 파일을 계속 붙들고 있어 새 로그가 안 보인다. 대문자 -F 는 경로 기준으로 재추적해서 로테이션 후에도 이어 본다. 운영 서버라면 거의 항상 -F 가 맞다. 이거 하나 몰라서 밤새 멀쩡히 쌓이는 로그를 "안 나온다"며 삽질하는 사람이 의외로 많다.

journalctl 쪽. tail 과 1:1로 대응시켜 보면 감이 온다.

# 특정 서비스 실시간 추적 (tail -f 와 가장 닮은 사용법)
journalctl -u nginx -f

# 최근 100줄만 보여주고 이어서 실시간
journalctl -u nginx -n 100 -f

# 시간 범위로 조회
journalctl --since "2 hours ago"
journalctl --since "2026-10-24 14:00" --until "2026-10-24 15:00"

# 에러 이상 우선순위만 (0 emerg ~ 7 debug)
journalctl -p err -u myapp

# 이번 부팅 이후 로그만 / 커널 메시지만
journalctl -b
journalctl -k

# 키워드 검색 (systemd 237 이상)
journalctl -u myapp -g "timeout"

# JSON 으로 뽑아 다른 도구에 넘기기
journalctl -u myapp -o json

팁 하나. journalctl 은 기본적으로 pager(less)를 띄워서 스크립트나 파이프에 쓸 땐 거슬린다. --no-pager 를 붙이거나, 맨 끝으로 바로 가려면 -e 를 쓴다. 저널이 디스크를 너무 먹으면 journalctl --vacuum-time=7d 로 최근 7일치만 남기고 정리할 수 있다.

그래서 언제 뭘 쓰나

상황으로 끊어서 정리하면 이렇다.

• 앱이 로그를 파일로 쓴다 (nginx access/error, 직접 지정한 app.log) → tail -F. 특히 웹서버 접근 로그 실시간 관찰은 tail 이 제일 편하다.
• systemd 로 띄운 서비스의 로그를 본다 (systemctl start 로 관리하는 데몬) → journalctl -u. 로그 파일 경로를 찾아 헤맬 필요가 없다.
• 과거 특정 시간대·레벨·서비스를 교차해서 파고든다 → journalctl 의 --since / -p / -u 조합. tail+grep 으로 억지로 하지 말자.
• systemd 가 없는 환경 (일부 Docker 컨테이너, 알파인, 구형 유닉스) → 선택지가 사실상 tail 뿐이다. 컨테이너라면 docker logs -f 가 tail 역할을 대신한다.

현실의 운영 서버는 둘을 섞어 쓴다

국내 실무로 좁혀 보면, 요즘 새로 세팅하는 우분투·로키리눅스 서버는 거의 다 systemd라 journalctl 로 통일하면 관리 포인트가 줄어든다. 그런데 현실의 운영 서버엔 레거시가 섞여 있다. nginx·톰캣·PHP-FPM처럼 자기 로그를 파일로 떨구도록 설정된 미들웨어가 여전히 많고, 이 로그들은 journalctl 에 안 잡힌다. "서비스는 systemd 로 띄웠는데 왜 journalctl -u nginx 에 접근 로그가 안 나오지?" 하는 혼란이 정확히 여기서 온다 — nginx 데몬의 기동·에러는 저널로 가지만, 접근 로그는 nginx 가 직접 파일에 쓰기 때문이다. 그래서 한 서버 안에서도 "기동·크래시는 journalctl, 트래픽·접근은 tail" 로 나눠 보는 조합이 가장 현실적이다.

하나 더. 저널이 기본 설정상 휘발성(/run 에 저장 → 재부팅 시 소멸)인 배포판이 아직 있다. 사고 원인을 찾으려고 과거 로그를 뒤져야 하는데 재부팅으로 날아가 있으면 낭패다. /etc/systemd/journald.conf 에서 Storage=persistent 로 바꿔 디스크에 영구 저장되도록 해두는 게 운영 서버의 기본값이어야 한다. 그리고 장기 보관·검색이 정말 중요한 규모라면, 그때는 tail 이냐 journalctl 이냐를 넘어 Loki·ELK 같은 중앙 로그 수집으로 가는 게 맞다. 둘 다 "단일 서버에서 눈으로 보는" 도구지, 수백 대를 가로지르는 분석 도구는 아니다.

한 줄로 외운다면

tail 과 journalctl 은 대결 구도가 아니다. 보는 대상이 파일이냐 저널이냐가 갈림길이고, 대부분의 운영자는 결국 둘 다 쓴다. 딱 세 개만 외우자. 로테이션 안전하게 보려면 tail -F, 서비스 추적은 journalctl -u ... -f, 과거 파고들기는 journalctl --since 에 -p 를 얹기.

여러분 서버에선 로그를 주로 어떻게 보시는지 궁금하다. journalctl 로 통일한 팀도 있을 테고, 여전히 tail -f | grep 한 줄이 제일 빠르다는 분도 있을 거다. 실시간 추적할 때 꼭 쓰는 자기만의 명령 조합이 있다면 댓글로 풀어 달라.