리눅스 서버 systemctl status만 보지 말고 journalctl로 서비스 로그 확인하는 법

리눅스 서버에서 systemctl status만으로 부족할 때 journalctl 명령어로 systemd 서비스 로그를 확인하고 status, ss, curl 흐름으로 장애 원인을 점검하는 방법을 설명하는 대표 이미지

 

리눅스 서버에서 서비스가 안 뜨거나, 재기동은 됐는데 정상 동작이 아닌 것 같을 때 초보 운영자가 자주 하는 실수가 있습니다.

바로 로그 파일 경로부터 먼저 헤매는 것입니다.

/var/log에 로그가 있나?
서비스 로그 파일명이 뭐였지?
nginx 로그는 어디였지?
애플리케이션 로그는 어디 있지?

 

물론 서비스별 로그 파일을 확인하는 것도 중요합니다. 하지만 systemd로 관리되는 서비스라면 먼저 journalctl로 systemd 로그를 확인하는 것이 더 빠를 때가 많습니다.

systemctl status는 서비스 상태를 보여주고, journalctl은 그 서비스가 왜 실패했는지, 어떤 로그를 남겼는지 더 자세히 보여줍니다.

이번 글에서는 리눅스 서버에서 systemctl status만으로 부족할 때 journalctl로 systemd 서비스 로그를 확인하는 방법을 정리합니다.

systemctl status만으로 부족한 이유

서비스 상태를 볼 때 가장 먼저 사용하는 명령어는 보통 아래입니다.

 

systemctl status nginx --no-pager

 

이 명령어는 서비스가 active인지, failed인지, inactive인지 확인할 때 유용합니다.

하지만 systemctl status에 보이는 로그는 보통 마지막 몇 줄 정도입니다.

예를 들어 이런 상황에서는 부족할 수 있습니다.

- 서비스가 시작되자마자 바로 죽음
- 재시작은 됐는데 에러가 반복됨
- 설정 파일 오류인지 포트 충돌인지 애매함
- 서비스 상태는 failed인데 원인이 한 줄로 안 보임
- 서버 재기동 후 자동 기동 실패 원인을 확인해야 함

 

이럴 때 흐름은 이렇게 가는 것이 좋습니다.

systemctl status 서비스명
→ journalctl -u 서비스명
→ 포트 확인
→ curl 응답 확인
→ 필요 시 조치

 

서비스 상태 확인 기본 흐름은 아래 글에서 먼저 정리했습니다.

https://opsnote.tistory.com/27

리눅스 서버 서비스가 안 뜰 때 재기동부터 하지 말고 systemctl status 먼저 확인하는 법

 

가상의 운영 상황 예시

예를 들어 nginx가 재시작 후 정상으로 올라오지 않았다고 가정해보겠습니다.

[상황]
- 사용자가 웹페이지 접속 불가 제보
- nginx 재시작 후에도 접속 안 됨
- systemctl status 기준 failed 상태
- status 하단 메시지만으로 원인 판단이 어려움

 

이때 바로 다시 restart를 반복하면 안 됩니다.

 

systemctl restart nginx

 

먼저 상태와 로그를 확인해야 합니다.

 

systemctl status nginx --no-pager
journalctl -u nginx -n 100 --no-pager

 

여기서 permission denied, address already in use, syntax error 같은 메시지가 보이면 원인 방향을 잡을 수 있습니다.

즉, journalctl은 서비스 장애 원인을 찾는 돋보기 같은 역할을 합니다. 상태판만 보고는 안 보이던 작은 균열을 로그에서 확인하는 식입니다.

1단계. 특정 서비스 로그는 journalctl -u로 봅니다

가장 먼저 알아둘 명령어는 아래입니다.

 

journalctl -u 서비스명

 

예를 들어 nginx 서비스 로그를 보려면 이렇게 입력합니다.

 

journalctl -u nginx

 

sshd 서비스라면 이렇게 볼 수 있습니다.

 

journalctl -u sshd

 

docker 서비스라면 이렇게 볼 수 있습니다.

 

journalctl -u docker

 

여기서 -u는 특정 systemd unit을 지정한다는 뜻입니다.

즉, 아래 명령은 nginx 서비스와 관련된 journal 로그를 보여줍니다.

 

journalctl -u nginx

 

서비스 이름은 서버 환경마다 다를 수 있습니다.

예를 들어 Apache는 배포판에 따라 httpd 또는 apache2일 수 있습니다.

 

journalctl -u httpd
journalctl -u apache2

 

서비스 이름이 헷갈리면 먼저 상태를 확인합니다.

 

systemctl status nginx --no-pager

 

2단계. --no-pager로 바로 출력하기

그냥 journalctl을 실행하면 화면이 less처럼 열릴 수 있습니다.

 

journalctl -u nginx

 

이 화면에서는 q를 눌러 빠져나올 수 있습니다.

하지만 초보 운영자 입장에서는 바로 출력되는 형태가 더 편할 때가 많습니다.

이럴 때 --no-pager 옵션을 붙입니다.

 

journalctl -u nginx --no-pager

 

--no-pager는 페이지 화면으로 들어가지 않고 터미널에 바로 출력하게 해줍니다.

운영 중 빠르게 확인하거나 결과 일부를 복사해야 할 때 편합니다.

다만 로그가 너무 많으면 화면이 길어질 수 있으니 보통은 -n 옵션과 함께 씁니다.

 

journalctl -u nginx -n 100 --no-pager

 

3단계. 최근 로그만 보려면 -n 옵션을 사용합니다

로그가 오래 쌓여 있으면 처음부터 전부 볼 필요는 없습니다.

장애 상황에서는 보통 최근 50줄 또는 100줄만 봐도 흐름이 보이는 경우가 많습니다.

최근 50줄을 보려면 아래처럼 입력합니다.

 

journalctl -u nginx -n 50 --no-pager

 

최근 100줄을 보려면 아래처럼 입력합니다.

 

journalctl -u nginx -n 100 --no-pager

 

여기서 -n은 마지막 N줄을 보여준다는 뜻입니다.

예를 들어 재시작 직후라면 아래 명령부터 보는 것이 무난합니다.

 

journalctl -u nginx -n 100 --no-pager

 

확인할 것은 아래입니다.

- 재시작 시각에 어떤 로그가 찍혔는지
- failed 메시지가 있는지
- permission denied가 있는지
- address already in use가 있는지
- timeout이나 connection refused가 있는지
- 같은 에러가 반복되는지

 

처음부터 전체 로그를 다 뒤지기보다 최근 로그부터 보는 습관이 좋습니다.

4단계. 서비스가 failed일 때 확인할 키워드

서비스가 failed 상태라면 journalctl에서 아래 키워드를 먼저 봅니다.

failed
denied
permission
timeout
address already in use
syntax error
invalid configuration
not found
connection refused
cannot open
missing

 

예를 들어 아래 메시지가 보이면 포트 충돌 가능성이 있습니다.

address already in use

 

이 경우에는 포트를 누가 잡고 있는지 확인합니다.

 

ss -lntp | grep ':80'

 

아래 메시지가 보이면 권한 문제일 수 있습니다.

permission denied

 

아래 메시지가 보이면 설정 파일 문제를 의심할 수 있습니다.

syntax error
invalid configuration

 

아래 메시지가 보이면 외부 연동이나 의존 서비스 문제일 수 있습니다.

connection refused
timeout

 

로그 키워드를 찾을 때는 grep도 함께 사용할 수 있습니다.

 

journalctl -u nginx -n 300 --no-pager | grep -i -E "failed|denied|timeout|permission|syntax|refused"

 

에러 키워드를 grep으로 찾는 기본 방법은 아래 글에서 이어서 볼 수 있습니다.

https://opsnote.tistory.com/24

리눅스 서버 로그에서 에러 찾을 때 grep만 믿지 말고 앞뒤 흐름까지 확인하는 법

 

5단계. 로그 한 줄만 보고 원인을 단정하면 안 됩니다

journalctl에서 에러 한 줄을 찾으면 원인을 찾은 것처럼 느껴질 수 있습니다.

예를 들어 아래 로그가 보였다고 가정해보겠습니다.

Failed to start nginx.service

 

이 줄만 보면 nginx 시작에 실패했다는 것만 알 수 있습니다.

하지만 왜 실패했는지는 아직 모릅니다.

바로 앞뒤 로그를 함께 봐야 합니다.

nginx: [emerg] bind() to 0.0.0.0:80 failed
address already in use
Failed to start nginx.service

 

이렇게 보면 단순히 nginx가 실패한 것이 아니라, 80 포트를 이미 다른 프로세스가 사용 중이라는 방향으로 볼 수 있습니다.

로그는 보통 한 줄보다 앞뒤 흐름이 중요합니다.

journalctl 결과를 grep -C와 함께 보면 앞뒤 문맥을 같이 볼 수 있습니다.

 

journalctl -u nginx -n 300 --no-pager | grep -i -C 3 "failed"

 

grep -C로 에러 앞뒤 흐름을 확인하는 방법은 아래 글에서 자세히 정리했습니다.

https://opsnote.tistory.com/25

리눅스 서버 로그에서 에러 한 줄만 보지 말고 grep -C로 앞뒤 흐름 확인하는 법

 

6단계. 실시간 로그는 journalctl -f로 확인합니다

서비스를 재시작하거나 테스트 요청을 보내면서 로그가 새로 찍히는지 보고 싶을 때가 있습니다.

이럴 때는 -f 옵션을 사용할 수 있습니다.

 

journalctl -u nginx -f

 

이 명령은 해당 서비스의 로그를 실시간으로 따라갑니다.

예를 들어 한쪽 터미널에서는 로그를 봅니다.

 

journalctl -u nginx -f

 

다른 터미널에서는 테스트 요청을 보냅니다.

 

curl -I http://127.0.0.1

 

요청 시점에 어떤 로그가 찍히는지 확인할 수 있습니다.

종료하려면 아래 키를 누르면 됩니다.

Ctrl + C

 

실시간 로그는 장애 재현, 서비스 재시작 후 확인, 테스트 요청 확인에 유용합니다.

7단계. journalctl -f와 tail -f 차이

journalctl -f와 tail -f는 둘 다 실시간 로그 확인에 사용됩니다.

하지만 보는 대상이 다릅니다.

journalctl -f
→ systemd journal 로그를 실시간 확인

tail -f
→ 특정 로그 파일을 실시간 확인

 

예를 들어 systemd 서비스 로그를 보고 싶다면 아래처럼 봅니다.

 

journalctl -u nginx -f

 

반대로 애플리케이션이 별도 로그 파일을 남긴다면 아래처럼 봅니다.

 

tail -n 100 -f /app/logs/service.log

 

정리하면 이렇게 볼 수 있습니다.

서비스 기동 실패, systemd 관리 로그 확인
→ journalctl -u 서비스명

애플리케이션 파일 로그 확인
→ tail -f 로그파일

 

둘 중 하나만 정답인 것은 아닙니다.

서비스 기동 실패는 journalctl, 애플리케이션 내부 에러는 서비스 로그 파일에서 더 잘 보일 수 있습니다.

tail -f 실시간 로그 확인 방법은 아래 글에서 정리했습니다.

https://opsnote.tistory.com/21

리눅스 서버 장애 났을 때 tail -f로 실시간 로그 확인하는 법

 

8단계. 특정 시간대 로그 확인하기

장애 발생 시간이 어느 정도 알려져 있다면 시간 조건을 걸어 확인할 수 있습니다.

오늘 로그만 보고 싶다면 아래처럼 입력합니다.

 

journalctl -u nginx --since today --no-pager

 

특정 시간 이후 로그만 보고 싶다면 이렇게 볼 수 있습니다.

 

journalctl -u nginx --since "2026-06-10 09:00:00" --no-pager

 

특정 시간 구간만 보고 싶다면 --until을 같이 사용합니다.

 

journalctl -u nginx --since "2026-06-10 09:00:00" --until "2026-06-10 10:00:00" --no-pager

 

이런 상황에서 유용합니다.

- 오전 9시쯤 장애가 났다는 제보를 받았을 때
- 배포 이후부터 에러가 늘었는지 보고 싶을 때
- 서버 재기동 직후 로그만 보고 싶을 때
- 특정 작업 시간대의 서비스 로그를 확인하고 싶을 때

 

장애 시각을 알고 있다면 전체 로그를 뒤지는 것보다 시간 범위를 좁히는 것이 훨씬 편합니다.

9단계. journalctl -xeu는 언제 볼까?

가끔 아래 명령어를 볼 수 있습니다.

 

journalctl -xeu nginx

 

이 명령은 특정 서비스의 최근 로그를 에러 중심으로 확인할 때 도움이 될 수 있습니다.

다만 초보 운영자 입장에서는 출력이 조금 복잡하게 느껴질 수 있습니다.

그래서 처음에는 아래 순서를 추천합니다.

1차 확인
→ systemctl status nginx --no-pager

2차 확인
→ journalctl -u nginx -n 100 --no-pager

3차 확인
→ journalctl -xeu nginx

 

journalctl -xeu를 무조건 먼저 보기보다, 상태와 최근 로그를 먼저 보고 필요할 때 사용하는 것이 좋습니다.

10단계. 서버 재기동 후 서비스가 안 뜰 때 확인 순서

서버 재기동 후 서비스가 자동으로 안 뜬다면 journalctl을 함께 확인해야 합니다.

먼저 현재 상태를 봅니다.

 

systemctl status nginx --no-pager

 

자동 기동 설정도 확인합니다.

 

systemctl is-enabled nginx

 

최근 로그를 봅니다.

 

journalctl -u nginx -n 100 --no-pager

 

포트도 확인합니다.

 

ss -lntp | grep ':80'

 

정상 응답도 확인합니다.

 

curl -I http://localhost

 

흐름으로 정리하면 아래와 같습니다.

1. systemctl status로 현재 상태 확인
2. is-enabled로 자동 기동 설정 확인
3. journalctl -u로 실패 원인 확인
4. ss로 포트 LISTEN 확인
5. curl로 로컬 응답 확인
6. 필요 시 조치 판단

 

서버 재기동 후 자동 기동 설정 문제는 아래 글에서 정리했습니다.

https://opsnote.tistory.com/30

리눅스 서버 재기동 후 서비스 안 뜨는 이유와 systemctl enable disable 차이

 

11단계. 실패한 서비스 목록부터 볼 수도 있습니다

어떤 서비스가 문제인지 정확히 모를 때는 systemctl --failed를 먼저 볼 수도 있습니다.

 

systemctl --failed

 

실패한 서비스가 보이면 해당 서비스의 로그를 이어서 확인합니다.

 

systemctl status nginx --no-pager
journalctl -u nginx -n 100 --no-pager

 

즉, 흐름은 이렇게 볼 수 있습니다.

systemctl --failed
→ systemctl status 서비스명
→ journalctl -u 서비스명
→ ss, curl 확인

 

실패한 서비스를 한 번에 확인하는 방법은 아래 글에서 정리했습니다.

https://opsnote.tistory.com/32

리눅스 서버에서 실패한 서비스 한 번에 확인하는 systemctl --failed 사용법

 

12단계. restart 후에도 journalctl을 다시 봐야 합니다

서비스를 재시작했다면 끝이 아닙니다.

재시작 후에도 로그를 다시 확인해야 합니다.

 

systemctl restart nginx
systemctl status nginx --no-pager
journalctl -u nginx -n 50 --no-pager

 

포트와 응답도 확인합니다.

 

ss -lntp | grep ':80'
curl -I http://localhost

 

재시작 후에도 아래 메시지가 남는지 봐야 합니다.

failed
timeout
permission denied
address already in use
connection refused

 

재시작 후 정상 기동 확인은 아래 글에서 따로 정리했습니다.

https://opsnote.tistory.com/29

리눅스 서버 restart 했으면 끝이 아닙니다? systemctl 재시작 후 정상 기동 확인하는 법

 

13단계. 운영 서버에서 journalctl 사용할 때 주의할 점

journalctl은 조회 명령이라 비교적 부담이 적습니다.

하지만 운영 서버에서는 로그 확인 후 판단이 중요합니다.

주의할 점은 아래와 같습니다.

- 로그 한 줄만 보고 원인 단정하지 않기
- 장애 발생 시각과 로그 시각을 맞춰보기
- restart 전에 최근 로그를 먼저 확인하기
- 로그에 실제 IP, 도메인, 토큰, 계정명이 있으면 외부 공유 전 마스킹하기
- 너무 많은 로그를 한 번에 긁어오지 않기
- systemd 로그와 애플리케이션 로그를 구분하기

 

특히 운영 로그에는 민감한 정보가 포함될 수 있습니다.

외부에 공유할 때는 실제 IP, 내부 도메인, 토큰, 계정명 등을 가려야 합니다.

IP: 203.0.113.10
도메인: example.com
토큰: [MASKED]
계정명: user01

 

14단계. 초보 운영자 기준 확인 흐름

서비스가 안 뜨거나 재시작 후 이상할 때는 아래 흐름이 무난합니다.

1. systemctl status로 현재 상태 확인
2. journalctl -u로 최근 로그 확인
3. 에러 키워드 확인
4. 필요하면 grep -C로 앞뒤 흐름 확인
5. ss로 포트 LISTEN 확인
6. curl로 로컬 응답 확인
7. 필요 시 조치
8. 조치 후 다시 status, journalctl 확인

 

명령어로 정리하면 아래처럼 볼 수 있습니다.

 

systemctl status nginx --no-pager
journalctl -u nginx -n 100 --no-pager
journalctl -u nginx -n 300 --no-pager | grep -i -E "failed|denied|timeout|permission|syntax|refused"
ss -lntp | grep ':80'
curl -I http://localhost

 

실시간 확인이 필요하면 아래처럼 봅니다.

 

journalctl -u nginx -f

 

서비스 파일 로그가 따로 있다면 아래처럼 확인합니다.

 

tail -n 100 -f /app/logs/service.log

 

15단계. 실무 보고 예시

서비스가 failed 상태이고 journalctl 로그를 확인했다면 이렇게 정리할 수 있습니다.

서비스 상태 확인 결과 nginx가 failed 상태로 확인되었습니다.
journalctl 로그 기준 address already in use 메시지가 확인되어,
대상 포트를 사용 중인 프로세스를 추가 확인하겠습니다.

 

권한 문제가 의심된다면 이렇게 쓸 수 있습니다.

journalctl 로그에서 permission denied 메시지가 확인되었습니다.
서비스 실행 계정과 대상 파일 권한을 우선 확인하겠습니다.

 

설정 파일 오류가 확인되었다면 이렇게 정리할 수 있습니다.

journalctl 로그 기준 syntax error 메시지가 확인되어 설정 파일 오류 가능성이 있습니다.
설정 검증 후 재기동 여부를 판단하겠습니다.

 

재시작 후에도 에러가 반복된다면 이렇게 쓸 수 있습니다.

서비스 재시작 후 journalctl 로그를 재확인했습니다.
동일 timeout 로그가 반복적으로 확인되어 외부 연동 응답 지연 여부를 추가 확인하겠습니다.

 

로그에서 특이사항이 없을 때는 이렇게 정리할 수 있습니다.

journalctl 기준 최근 서비스 오류 로그는 확인되지 않았습니다.
다만 접속 불가 현상이 지속되어 포트 LISTEN 상태와 애플리케이션 로그를 추가 확인하겠습니다.

 

이렇게 쓰면 단순히 “로그 봤습니다”보다 훨씬 명확합니다.

정리하면

리눅스 서버에서 systemd로 관리되는 서비스는 문제가 생겼을 때 journalctl로 서비스 로그를 확인할 수 있습니다.

특정 서비스 로그는 아래처럼 봅니다.

 

journalctl -u 서비스명

 

최근 100줄만 보려면 아래처럼 확인합니다.

 

journalctl -u 서비스명 -n 100 --no-pager

 

실시간 로그를 보려면 아래처럼 확인합니다.

 

journalctl -u 서비스명 -f

 

서비스 상태부터 보고 싶다면 아래처럼 시작합니다.

 

systemctl status 서비스명 --no-pager

 

서비스 로그를 볼 때는 journalctl 결과만 따로 보지 말고, 서비스 상태와 함께 확인하는 것이 좋습니다.

systemctl status에서는 서비스가 현재 active인지, failed인지, 언제부터 문제가 있었는지 볼 수 있고, journalctl에서는 그 원인에 가까운 로그를 더 자세히 확인할 수 있습니다.

서비스가 안 뜰 때 먼저 systemctl status로 상태를 확인하는 방법은 아래 글에서 이어서 볼 수 있습니다.

https://opsnote.tistory.com/27

리눅스 서버 서비스가 안 뜰 때 재기동부터 하지 말고 systemctl status 먼저 확인하는 법

실패한 서비스가 여러 개 있는지 한 번에 확인하고 싶다면 systemctl --failed도 함께 보면 좋습니다.

https://opsnote.tistory.com/32

리눅스 서버에서 실패한 서비스 한 번에 확인하는 systemctl --failed 사용법

 

리눅스 서버 장애 대응 전체 흐름은 아래 글에서 정리했습니다.

https://opsnote.tistory.com/69

초보 운영자를 위한 리눅스 서버 장애 대응 순서 총정리