리눅스 오류 로그 확인하는 방법: journalctl부터 /var/log까지

리눅스 서버를 운영하다 보면 “뭔가 안 된다”는 순간을 자주 만난다. 웹사이트가 안 열리거나, 서비스가 시작되지 않거나, 갑자기 접속이 느려지거나, 재부팅 후 프로그램이 올라오지 않을 때가 있다. 이때 초보자가 가장 먼저 해야 할 일은 추측이 아니라 로그를 보는 것이다. 로그는 서버가 남겨둔 일기장이다. 어디서, 언제, 어떤 문제가 생겼는지 단서가 들어 있다.

이 글에서는 리눅스에서 오류 로그를 확인하는 기본 방법을 정리한다. 특히 요즘 리눅스 서버에서 가장 자주 쓰는 journalctl을 중심으로 설명하고, /var/log 아래의 전통적인 로그 파일 확인 방법도 함께 다룬다. 처음 보는 명령어가 많아 보여도 걱정할 필요 없다. 목적별로 나눠서 보면 어렵지 않다.

먼저 어떤 서비스가 문제인지 확인한다

로그를 보기 전에 먼저 어떤 서비스가 문제인지 알아야 한다. 예를 들어 웹서버라면 nginx나 apache2, 데이터베이스라면 mysql 또는 mariadb, 애플리케이션이라면 직접 만든 서비스 이름일 수 있다. systemd 기반 리눅스에서는 systemctl status로 서비스 상태를 먼저 확인한다.

systemctl status nginx
systemctl status apache2
systemctl status mysql
systemctl status ssh

여기서 active (running)이면 실행 중이고, failed나 inactive가 보이면 문제가 있을 가능성이 크다. 상태 화면 아래쪽에는 최근 로그 몇 줄도 함께 보인다. 하지만 더 자세히 보려면 journalctl을 사용해야 한다.

journalctl이란 무엇인가

journalctl은 systemd의 로그 저장소인 journal을 조회하는 명령어다. 쉽게 말하면 리눅스 시스템과 서비스가 남긴 로그를 시간순으로 꺼내 보는 도구다. 예전에는 주로 /var/log/syslog, /var/log/messages 같은 파일을 직접 봤지만, systemd를 쓰는 배포판에서는 journalctl이 매우 중요하다.

아무 옵션 없이 실행하면 전체 로그가 오래된 것부터 출력된다.

journalctl

하지만 전체 로그는 너무 많다. 그래서 실제로는 서비스, 시간, 우선순위, 부팅 시점 등을 기준으로 좁혀서 본다.

특정 서비스 로그 보기: -u

가장 많이 쓰는 옵션은 -u다. unit, 즉 systemd 서비스 단위의 로그를 보는 옵션이다. 예를 들어 nginx 로그만 보고 싶으면 이렇게 입력한다.

journalctl -u nginx
journalctl -u nginx.service

서비스 이름 뒤에 .service를 붙여도 되고 생략해도 되는 경우가 많다. 서비스가 실패했을 때는 먼저 systemctl status nginx를 보고, 이어서 journalctl -u nginx로 자세한 로그를 확인하는 흐름이 좋다.

최근 로그만 보기: -n

로그가 너무 많으면 최근 몇 줄만 보는 것이 편하다. 이때 -n을 사용한다.

journalctl -n 50
journalctl -u nginx -n 100

첫 번째 명령은 전체 로그 중 최근 50줄을 보여준다. 두 번째 명령은 nginx 서비스 로그 중 최근 100줄을 보여준다. 장애가 막 발생했을 때는 오래된 로그보다 최근 로그가 중요하므로 -n은 자주 쓰인다.

실시간으로 로그 따라가기: -f

서비스를 재시작하거나 오류를 재현하면서 로그를 바로 보고 싶을 때는 -f를 쓴다. follow의 의미로, 새 로그가 생기면 화면에 계속 추가된다.

journalctl -u nginx -f
journalctl -f

예를 들어 웹서버 설정을 바꾼 뒤 다른 터미널에서 systemctl restart nginx를 실행하고, 한쪽에서는 journalctl -u nginx -f를 켜두면 오류가 즉시 보인다. 종료하려면 Ctrl + C를 누른다.

이번 부팅 이후 로그 보기: -b

서버를 재부팅한 뒤 문제가 생겼다면 이번 부팅 이후의 로그만 보는 것이 좋다. 이때 -b를 사용한다.

journalctl -b
journalctl -u nginx -b

첫 번째 명령은 현재 부팅 이후 전체 로그를 보여준다. 두 번째 명령은 현재 부팅 이후 nginx 로그만 보여준다. 부팅 과정에서 서비스가 올라오지 않은 경우에는 -b가 매우 유용하다.

이전 부팅 로그를 보고 싶으면 숫자를 붙인다.

journalctl -b -1
journalctl -b -2

-b -1은 바로 이전 부팅, -b -2는 그보다 한 번 더 이전 부팅 로그를 의미한다. 단, 시스템이 이전 부팅 로그를 보관하도록 설정되어 있어야 한다.

시간 범위로 로그 보기: –since, –until

“오늘 아침부터 문제가 생겼다”, “어제 밤 10시쯤 오류가 났다”처럼 시간이 대략 기억난다면 시간 범위를 지정하면 된다.

journalctl --since "today"
journalctl --since "yesterday"
journalctl --since "2026-06-27 09:00"
journalctl --since "2026-06-27 09:00" --until "2026-06-27 10:00"

서비스와 함께 쓰면 더 실용적이다.

journalctl -u nginx --since "1 hour ago"
journalctl -u mysql --since "today" -n 200

--since는 시작 시각, --until은 끝 시각이다. 장애가 발생한 시간대를 알고 있을 때 로그 범위를 좁히는 데 좋다.

오류 수준만 보기: -p

로그에는 정보성 메시지, 경고, 오류가 모두 섞여 있다. 오류만 보고 싶을 때는 priority를 의미하는 -p 옵션을 쓴다.

journalctl -p err
journalctl -u nginx -p warning
journalctl -u nginx -p err -b

자주 쓰는 우선순위는 다음과 같다.

• emerg: 시스템 전체가 사용 불가능한 수준
• alert: 즉시 조치가 필요한 심각한 문제
• crit: 치명적인 오류
• err: 일반적인 오류
• warning: 경고
• notice: 주의할 만한 정상 이벤트
• info: 정보 메시지
• debug: 디버깅용 상세 메시지

초보자는 우선 -p err와 -p warning만 기억해도 충분하다. “진짜 문제만 빨리 보고 싶다”면 journalctl -p err -b부터 시작하면 된다.

출력 형식 다루기: -e, –no-pager, -o

journalctl은 기본적으로 less 같은 페이지 화면으로 열린다. 방향키로 움직이고 q로 종료한다. 마지막 부분부터 보고 싶으면 -e를 붙인다.

journalctl -u nginx -e

스크립트에서 쓰거나 화면에 바로 출력하고 싶으면 --no-pager를 쓴다.

journalctl -u nginx --no-pager

출력 형식을 바꾸고 싶으면 -o를 사용한다.

journalctl -u nginx -o short-iso
journalctl -u nginx -o cat
journalctl -u nginx -o json-pretty

short-iso는 날짜와 시간이 읽기 좋게 나오고, cat은 메시지만 간단히 보여준다. json-pretty는 구조화된 형태로 보고 싶을 때 쓴다. 보통은 short-iso 정도만 알아도 충분하다.

전통적인 로그 파일도 확인하자: /var/log

journalctl만 보면 끝나는 것은 아니다. 많은 프로그램은 여전히 /var/log 아래에 별도 로그 파일을 남긴다. 특히 웹서버, 데이터베이스, 인증 로그는 파일로 보는 경우가 많다.

ls -lah /var/log
sudo less /var/log/syslog
sudo less /var/log/auth.log
sudo less /var/log/nginx/error.log
sudo less /var/log/apache2/error.log

배포판에 따라 파일 이름이 다를 수 있다. Ubuntu/Debian 계열은 /var/log/syslog, /var/log/auth.log를 자주 쓰고, RHEL/CentOS 계열은 /var/log/messages, /var/log/secure를 자주 쓴다.

파일 로그를 볼 때 자주 쓰는 명령어

파일 로그는 less, tail, grep을 함께 쓰면 편하다.

sudo less /var/log/syslog
sudo tail -n 100 /var/log/syslog
sudo tail -f /var/log/nginx/error.log
sudo grep -i "error" /var/log/syslog
sudo grep -i "failed" /var/log/auth.log

less는 긴 로그를 천천히 볼 때 좋다. tail -n 100은 마지막 100줄만 본다. tail -f는 실시간으로 추가되는 로그를 따라간다. grep -i는 대소문자를 구분하지 않고 특정 단어를 찾는다.

초보자를 위한 장애 확인 순서

실제로 문제가 생겼을 때는 아래 순서로 보면 된다.

• 서비스 상태 확인: systemctl status 서비스명
• 해당 서비스 journal 확인: journalctl -u 서비스명 -n 100
• 이번 부팅 오류 확인: journalctl -p err -b
• 실시간 확인: journalctl -u 서비스명 -f
• 전용 파일 로그 확인: /var/log/서비스명/ 또는 /var/log/syslog

예를 들어 nginx가 안 올라온다면 이렇게 보면 된다.

systemctl status nginx
journalctl -u nginx -n 100
journalctl -u nginx -p err -b
sudo tail -n 100 /var/log/nginx/error.log

대부분의 초보자 문제는 여기까지 보면 단서가 나온다. 포트가 이미 사용 중인지, 설정 파일 문법이 틀렸는지, 권한이 없는지, 파일 경로가 잘못됐는지 같은 내용이 로그에 남아 있다.

권한 문제: sudo가 필요할 수 있다

일부 로그는 일반 사용자 권한으로 볼 수 없다. 이럴 때는 sudo를 붙인다.

sudo journalctl -u nginx
sudo less /var/log/auth.log

특정 사용자에게 journal 로그 조회 권한을 주는 방법도 있지만, 초보자는 우선 sudo로 확인하는 편이 안전하다. 운영 서버에서는 회사나 팀의 권한 정책을 따라야 한다.

journal 로그가 재부팅 후 사라진다면

일부 시스템은 journal 로그를 메모리에만 저장해서 재부팅하면 이전 로그가 사라질 수 있다. 이전 부팅 로그를 계속 보관하려면 persistent journal 설정이 필요하다.

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

이후부터는 journalctl -b -1처럼 이전 부팅 로그를 확인할 수 있는 환경이 된다. 다만 로그가 디스크를 차지하므로 서버 용량도 함께 확인해야 한다.

마무리

리눅스 오류 로그 확인은 어렵게 생각할 필요가 없다. 처음에는 세 가지만 기억하면 된다. 서비스 상태는 systemctl status, systemd 로그는 journalctl, 파일 로그는 /var/log다. 여기에 -u, -n, -f, -b, --since, -p 옵션을 익히면 대부분의 초보자 단계 장애는 충분히 추적할 수 있다.

서버 문제를 해결하는 사람은 감으로 맞히는 사람이 아니라, 로그를 차분히 읽는 사람이다. 오류 메시지를 무서워하지 말고 한 줄씩 따라가면 된다. 로그는 늘 조금 불친절하지만, 대체로 답에 가까운 힌트를 남겨둔다.