리눅스 서버를 운영하다 보면 갑자기 웹사이트가 접속되지 않거나, Nginx가 중지되거나, 서버의 특정 서비스가 정상적으로 실행되지 않는 문제가 발생할 수 있습니다.
이런 장애가 발생했을 때 무작정 서버를 재부팅하거나 프로그램을 다시 설치하기보다는 로그를 먼저 확인하는 것이 중요합니다.
리눅스에서는 시스템과 서비스에서 발생하는 다양한 이벤트를 로그로 기록합니다. 특히 systemd 기반의 리눅스 서버에서는 journalctl 명령어를 사용하면 시스템과 서비스의 로그를 효율적으로 확인할 수 있습니다.
이번 글에서는 journalctl의 기본 사용법부터 Nginx 장애, SSH 접속 문제, 서비스 실행 오류 등을 확인하는 방법까지 단계별로 알아보겠습니다.
1. journalctl이란?
journalctl은 systemd의 저널(journal)에 저장된 로그를 조회하는 명령어입니다.
Ubuntu, Debian, Rocky Linux 등 systemd를 사용하는 대부분의 최신 리눅스 서버에서 활용할 수 있습니다.
서버에서 발생하는 다양한 이벤트를 확인할 수 있기 때문에 다음과 같은 장애 상황에서 유용합니다.
- Nginx 서비스가 실행되지 않는 경우
- MySQL 서비스가 중지된 경우
- SSH 접속 문제가 발생한 경우
- 서버 부팅 과정에서 오류가 발생한 경우
- 특정 서비스가 반복적으로 재시작되는 경우
- 애플리케이션 오류가 발생한 경우
기본적인 journalctl 명령어는 다음과 같습니다.
sudo journalctl
로그가 매우 많다면 화면이 길어질 수 있으므로 필요한 조건을 지정하여 검색하는 것이 좋습니다.
2. 최신 로그부터 확인하는 방법
서버에서 최근에 발생한 로그를 확인하고 싶다면 다음 명령어를 사용할 수 있습니다.
sudo journalctl -e
-e 옵션은 로그의 마지막 부분으로 이동하여 최근 로그를 확인하기 편리하게 해줍니다.
장애가 방금 발생했다면 최근 로그부터 확인하는 것이 효율적입니다.
특히 다음과 같은 메시지가 있는지 확인합니다.
- error
- failed
- warning
- permission denied
- connection refused
- timeout
- fatal
다만 로그에 warning이나 error가 표시되었다고 해서 반드시 해당 메시지가 장애의 직접적인 원인이라고 단정해서는 안 됩니다.
오류가 발생한 시간과 실제 장애가 시작된 시간을 함께 비교하는 것이 중요합니다.
3. 최근 로그만 확인하기
서버 로그가 너무 많다면 최근 로그만 확인하는 것이 좋습니다.
예를 들어 최근 50개의 로그를 확인하려면 다음과 같이 사용할 수 있습니다.
sudo journalctl -n 50
최근 100개의 로그를 확인하려면:
sudo journalctl -n 100
서버 장애 직후에는 최근 로그를 먼저 확인한 다음 필요한 경우 시간 범위를 넓혀가면서 분석하는 것이 효율적입니다.
4. 실시간 로그 확인하기
서비스를 재시작하면서 어떤 오류가 발생하는지 확인하고 싶을 때는 -f 옵션을 사용할 수 있습니다.
sudo journalctl -f
이 명령어를 실행하면 새로운 로그가 발생할 때마다 화면에 표시됩니다.
예를 들어 Nginx를 재시작하면서 로그를 확인하려면 다음과 같이 사용할 수 있습니다.
sudo journalctl -u nginx -f
이 상태에서 다른 터미널을 열어 Nginx를 재시작합니다.
sudo systemctl restart nginx
그러면 Nginx 재시작 과정에서 발생하는 오류를 실시간으로 확인할 수 있습니다.
5. 특정 서비스 로그 확인하기
journalctl의 가장 유용한 기능 중 하나는 특정 서비스의 로그만 조회할 수 있다는 것입니다.
-u 옵션을 사용하면 특정 systemd 서비스를 지정할 수 있습니다.
예를 들어 Nginx 로그를 확인하려면:
sudo journalctl -u nginx
최근 Nginx 로그만 확인하려면:
sudo journalctl -u nginx -n 50
실시간으로 확인하려면:
sudo journalctl -u nginx -f
Nginx 서비스가 정상적으로 실행되지 않는 상황이라면 다음과 같은 순서로 확인하는 것이 좋습니다.
sudo systemctl status nginx
그리고:
sudo journalctl -u nginx -n 100
마지막으로 Nginx 설정 파일의 문법도 확인합니다.
sudo nginx -t
이처럼 서비스 상태 → 로그 → 설정 파일 순서로 확인하면 문제를 찾는 데 도움이 됩니다.
6. 특정 날짜와 시간의 로그 확인하기
서버 장애가 특정 시간에 발생했다면 시간 범위를 지정하여 로그를 검색할 수 있습니다.
예를 들어 오늘 오전 10시 이후의 로그를 확인하려면 다음과 같이 사용할 수 있습니다.
sudo journalctl --since "10:00"
특정 시간부터 현재까지 확인하려면:
sudo journalctl --since "2026-08-17 10:00:00"
종료 시간을 지정할 수도 있습니다.
sudo journalctl --since "2026-08-17 10:00:00" --until "2026-08-17 11:00:00"
실제 장애가 발생한 시간을 알고 있다면 이 방법이 매우 유용합니다.
예를 들어 웹사이트가 오전 10시 20분부터 접속되지 않았다면 10시 10분부터 10시 30분 사이의 로그를 집중적으로 확인할 수 있습니다.
7. 오늘 발생한 로그만 확인하기
오늘 발생한 로그를 확인하려면 다음과 같이 사용할 수 있습니다.
sudo journalctl --since today
어제의 로그를 확인하려면:
sudo journalctl --since yesterday --until today
장애가 언제 발생했는지 정확하게 모르는 경우 날짜를 기준으로 범위를 좁혀가는 것도 좋은 방법입니다.
8. 부팅 과정의 로그 확인하기
서버가 재부팅된 후 문제가 발생했다면 부팅 과정에서 어떤 오류가 발생했는지 확인해야 합니다.
현재 부팅의 로그를 확인하려면 다음 명령어를 사용할 수 있습니다.
sudo journalctl -b
이전 부팅의 로그를 확인하려면:
sudo journalctl -b -1
여기서 -1은 이전 부팅을 의미합니다.
서버가 갑자기 재부팅되었거나 부팅 후 특정 서비스가 실행되지 않는다면 이전 부팅 로그를 확인하는 것이 문제의 원인을 찾는 데 도움이 될 수 있습니다.
9. 오류 메시지만 집중적으로 확인하기
journalctl에는 로그의 심각도 수준을 기준으로 조회하는 기능도 있습니다.
예를 들어 오류 수준 이상의 로그를 확인하려면 다음과 같이 사용할 수 있습니다.
sudo journalctl -p err
현재 부팅에서 오류 로그만 확인하려면:
sudo journalctl -b -p err
이 명령어는 장애 분석을 시작할 때 유용합니다.
다만 오류 메시지가 발견되었다고 해서 바로 해당 오류가 장애 원인이라고 판단하면 안 됩니다.
발생 시간, 관련 서비스, 오류 내용, 장애 증상을 함께 비교해야 정확한 원인을 찾을 수 있습니다.
10. SSH 관련 로그 확인하기
리눅스 서버에 SSH로 접속할 수 없거나 비정상적인 로그인 시도가 의심된다면 SSH 관련 로그를 확인할 필요가 있습니다.
systemd 환경에서는 다음과 같이 SSH 서비스 로그를 확인할 수 있습니다.
Ubuntu 계열에서는 서비스 이름이 환경에 따라 ssh 또는 sshd일 수 있으므로 실제 서비스 이름을 확인한 뒤 사용해야 합니다.
sudo systemctl status ssh
로그는 다음과 같이 확인할 수 있습니다.
sudo journalctl -u ssh
환경에 따라 다음과 같이 사용할 수도 있습니다.
sudo journalctl -u sshd
SSH 로그에서는 인증 실패나 서비스 실행 오류 등을 확인할 수 있습니다.
11. MySQL 장애 로그 확인하기
데이터베이스 서버에서 문제가 발생했다면 MySQL 서비스 로그도 확인해야 합니다.
먼저 서비스 상태를 확인합니다.
sudo systemctl status mysql
그다음 journalctl을 이용해 MySQL 로그를 확인할 수 있습니다.
sudo journalctl -u mysql
최근 로그만 확인하려면:
sudo journalctl -u mysql -n 100
MySQL이 실행되지 않는 경우에는 로그에 나타나는 오류 메시지와 함께 디스크 공간, 권한, 설정 파일, 데이터 디렉터리 상태 등을 함께 확인해야 합니다.
12. journalctl로 Nginx 장애 원인 찾기
실제 서버 운영에서 자주 발생하는 문제 중 하나가 Nginx 서비스 장애입니다.
예를 들어 웹사이트가 갑자기 접속되지 않는다면 먼저 Nginx 상태를 확인합니다.
sudo systemctl status nginx
failed 상태라면 로그를 확인합니다.
sudo journalctl -u nginx -n 100
그리고 설정 파일 문법을 확인합니다.
sudo nginx -t
만약 다음과 같이 설정 오류가 표시된다면 Nginx 설정 파일을 수정해야 합니다.
nginx: [emerg] ...
설정 파일을 수정한 후 다시 문법을 검사합니다.
sudo nginx -t
문법 검사가 정상적으로 완료된 것을 확인한 후 Nginx를 다시 시작합니다.
sudo systemctl restart nginx
이 과정을 습관화하면 설정 파일을 잘못 수정해서 발생하는 장애를 보다 빠르게 해결할 수 있습니다.
13. 서비스가 반복적으로 재시작될 때
특정 서비스가 계속 중지되었다가 다시 시작되는 경우에도 journalctl을 활용할 수 있습니다.
먼저 서비스 상태를 확인합니다.
sudo systemctl status 서비스이름
그다음 해당 서비스의 최근 로그를 확인합니다.
sudo journalctl -u 서비스이름 -n 100
실시간 로그를 확인하려면:
sudo journalctl -u 서비스이름 -f
반복적인 재시작의 원인은 설정 오류, 포트 충돌, 권한 문제, 환경변수 오류, 메모리 부족 등 다양할 수 있습니다.
따라서 로그에 나타난 오류 메시지를 기준으로 원인을 하나씩 확인해야 합니다.
14. 디스크 부족 문제와 로그 확인
서버 운영 중 디스크 공간이 부족하면 다양한 서비스가 정상적으로 작동하지 않을 수 있습니다.
먼저 디스크 사용량을 확인합니다.
df -h
특정 디렉터리의 용량을 확인하려면:
sudo du -sh /var/*
특히 로그가 지나치게 많이 쌓이면 /var 아래의 디스크 사용량이 증가할 수 있습니다.
journal 로그의 디스크 사용량은 다음 명령어로 확인할 수 있습니다.
journalctl --disk-usage
로그가 차지하는 공간이 지나치게 큰 경우에는 무작정 로그 파일을 삭제하기보다 systemd-journald의 보관 정책과 서버의 로그 관리 정책을 먼저 확인하는 것이 좋습니다.
15. journalctl 로그를 장애 분석에 활용하는 순서
서버 장애가 발생했을 때 다음 순서로 접근하면 좋습니다.
① 서비스 상태 확인
sudo systemctl status nginx
② 최근 서비스 로그 확인
sudo journalctl -u nginx -n 100
③ 오류 수준 로그 확인
sudo journalctl -p err
④ 장애 발생 시간의 로그 확인
sudo journalctl --since "10:00" --until "11:00"
⑤ 실시간 로그 확인
sudo journalctl -u nginx -f
⑥ 설정 파일 검사
sudo nginx -t
⑦ 서버 자원 확인
free -h
df -h
top
이 과정을 통해 서비스 문제인지, 설정 문제인지, 서버 자원 문제인지 범위를 좁혀갈 수 있습니다.
16. journalctl 로그를 확인할 때 주의할 점
로그를 확인할 때 가장 흔한 실수는 오류 메시지 하나만 보고 원인을 결정하는 것입니다.
서버 로그에는 정상적인 경고나 일시적인 오류도 기록될 수 있습니다.
따라서 다음 네 가지를 함께 확인하는 것이 좋습니다.
첫째, 발생 시간입니다.
장애가 발생한 시간과 로그가 기록된 시간이 일치하는지 확인합니다.
둘째, 서비스입니다.
오류가 발생한 서비스가 실제 장애와 관련되어 있는지 확인합니다.
셋째, 반복 여부입니다.
같은 오류가 계속 발생하는지 확인합니다.
넷째, 서버 상태입니다.
CPU, 메모리, 디스크 등의 자원 부족이 함께 발생했는지 확인합니다.
이러한 정보를 종합해야 실제 장애 원인을 정확하게 판단할 수 있습니다.
17. 리눅스 서버 장애 분석의 기본 원칙
서버 장애가 발생하면 다음과 같은 순서로 접근하는 것이 좋습니다.
증상 확인 → 서비스 상태 확인 → 로그 확인 → 시스템 자원 확인 → 설정 확인 → 수정 → 재검증
예를 들어 Nginx가 실행되지 않는다면 다음과 같이 진행할 수 있습니다.
sudo systemctl status nginx
↓
sudo journalctl -u nginx -n 100
↓
sudo nginx -t
↓
df -h
↓
free -h
문제를 수정한 후에는 반드시 서비스 상태와 로그를 다시 확인해야 합니다.
마무리
리눅스 서버를 안정적으로 운영하기 위해서는 명령어를 많이 아는 것보다 문제가 발생했을 때 원인을 체계적으로 찾는 능력이 중요합니다.
그중 journalctl은 systemd 기반 리눅스 서버에서 시스템과 서비스의 로그를 확인할 수 있는 매우 유용한 도구입니다.
특히 다음 명령어는 서버 관리에서 자주 활용할 수 있습니다.
sudo journalctl
sudo journalctl -e
sudo journalctl -n 50
sudo journalctl -u nginx
sudo journalctl -u nginx -f
sudo journalctl -b
sudo journalctl -b -1
sudo journalctl -p err
sudo journalctl --disk-usage
하지만 로그에 나타난 오류 하나만으로 장애 원인을 단정하지 말고 발생 시간, 서비스 상태, 시스템 자원, 설정 파일, 네트워크 상태를 함께 확인하는 것이 중요합니다.
리눅스 서버를 운영하면서 journalctl 사용법을 익혀두면 Nginx, MySQL, SSH 등 다양한 서비스에서 발생하는 문제를 보다 체계적으로 분석할 수 있습니다.
다음 글에서는 이와 연결해서 **「리눅스 서버 디스크 용량 부족 원인과 df·du 명령어로 문제 해결하는 방법」**을 다루면 서버 관리 시리즈를 자연스럽게 이어갈 수 있습니다.