안녕하세요. 일본서버 호스팅 전문 비전 IDC 기술팀입니다.
오늘은 Ubuntu 24.04에서 journalctl을 사용해 부팅 오류 로그를 확인하는 방법을 알아보겠습니다. 서버가 재부팅된 뒤 특정 서비스가 실행되지 않거나 네트워크, 디스크, 파일시스템, 드라이버 등의 문제로 부팅 과정에서 오류가 발생했다면 systemd journal에서 현재 부팅과 이전 부팅의 기록을 구분해 확인하는 것이 중요합니다.
이 문서에서는 전체 부팅 오류 확인, 실패한 systemd 서비스 추적, 커널 로그 확인, 이전 부팅 로그 조회와 이전 로그가 보이지 않을 때의 점검 방법까지 단계별로 설명합니다.
적용 환경
이 문서는 Ubuntu 24.04 LTS(Noble Numbat)와 systemd-journald 환경을 기준으로 작성합니다. Ubuntu 24.04 LTS는 Canonical의 표준 보안 유지보수가 2029년 5월까지 제공되는 지원 버전입니다.
운영체제 버전은 다음 명령으로 확인할 수 있습니다.
cat /etc/os-release1. 실패한 서비스 먼저 확인
부팅 후 특정 기능이 동작하지 않는다면 먼저 systemd에서 실패 상태로 남아 있는 유닛이 있는지 확인합니다. 이 단계에서 문제가 발생한 서비스 이름을 찾으면 전체 로그를 모두 읽지 않고 해당 서비스의 로그로 바로 범위를 좁힐 수 있습니다.
systemctl --failed --no-pager출력에 failed 상태의 유닛이 있다면 유닛 이름을 기록해 두고 뒤의 특정 서비스 로그 확인 단계에서 사용합니다. 실패한 유닛이 없다고 해서 부팅 과정에 경고나 일시적인 오류가 없었다는 뜻은 아니므로, 다음 단계에서 journal 로그도 함께 확인해야 합니다.
2. 현재 부팅 오류 로그 확인
journalctl -b는 현재 부팅 세션의 로그만 표시합니다. 먼저 현재 부팅에서 기록된 전체 로그를 확인할 수 있습니다.
sudo journalctl -b --no-pager로그가 너무 많다면 오류 수준 이상의 메시지만 필터링합니다. -p err는 syslog 우선순위에서 err와 그보다 더 심각한 수준의 메시지를 표시합니다.
sudo journalctl -b -p err --no-pager경고까지 포함해 범위를 넓히려면 다음과 같이 확인할 수 있습니다.
sudo journalctl -b -p warning --no-pager3. 이전 부팅 오류 로그 확인
서버가 비정상 종료되었거나 재부팅 후 문제가 사라진 경우에는 현재 부팅 로그보다 직전 부팅 로그가 더 중요할 수 있습니다. 먼저 journal에 저장된 부팅 목록을 확인합니다.
sudo journalctl --list-boots현재 부팅은 일반적으로 0, 직전 부팅은 -1, 그 이전 부팅은 -2와 같이 표시됩니다. 직전 부팅의 전체 로그는 다음과 같이 확인합니다.
sudo journalctl -b -1 --no-pager직전 부팅에서 오류 수준 이상의 메시지만 확인하려면 다음 명령을 사용합니다.
sudo journalctl -b -1 -p err --no-pager4. 특정 서비스의 부팅 로그 확인
systemctl --failed에서 실패한 서비스가 확인되었다면 해당 유닛만 필터링하는 것이 가장 빠른 진단 방법입니다. 아래에서는 nginx.service를 예시로 사용하며 실제 문제가 발생한 서비스명으로 변경하십시오.
먼저 현재 서비스 상태와 최근 오류 메시지를 확인합니다.
systemctl status nginx.service --no-pager현재 부팅에서 해당 서비스가 기록한 로그만 확인합니다.
sudo journalctl -b -u nginx.service --no-pager직전 부팅에서 같은 서비스의 로그를 확인하려면 다음과 같이 실행합니다.
sudo journalctl -b -1 -u nginx.service --no-pager로그에서 설정 파일 문법 오류, 파일 또는 디렉터리 부재, 권한 문제, 포트 충돌, 의존 서비스 실패, 실행 파일 오류와 같은 구체적인 원인을 확인합니다.
5. 커널 부팅 오류 확인
디스크, 파일시스템, 네트워크 장치, 드라이버 또는 하드웨어 관련 문제는 서비스 로그가 아니라 커널 메시지에서 단서를 찾는 경우가 많습니다. 현재 부팅의 커널 로그만 확인하려면 -k 옵션을 사용합니다.
sudo journalctl -k -b --no-pager커널 로그에서도 오류 수준으로 범위를 줄일 수 있습니다.
sudo journalctl -k -b -p err --no-pagerI/O 오류, 파일시스템 오류, 장치 인식 실패, 드라이버 초기화 실패 등이 보인다면 해당 장치와 파일시스템 상태를 별도로 점검해야 합니다.
6. 시간 범위를 지정하여 로그 확인
장애가 발생한 시간을 알고 있다면 시간 범위를 지정해 불필요한 로그를 줄일 수 있습니다. 최근 30분 동안 기록된 로그는 다음과 같이 확인합니다.
sudo journalctl --since "30 minutes ago" --no-pager특정 날짜와 시간 범위를 지정할 수도 있습니다. 아래 시간은 예시이므로 실제 장애 발생 시간으로 변경하십시오.
sudo journalctl --since "2026-10-04 02:00:00" --until "2026-10-04 03:00:00" --no-pager시간 범위와 -u, -p 등의 필터를 조합하면 특정 서비스가 특정 시간에 기록한 오류만 빠르게 추적할 수 있습니다.
7. 이전 부팅 로그가 보이지 않을 때
systemd-journald는 journal을 영구 저장소인 /var/log/journal 또는 휘발성 저장소인 /run/log/journal에 저장할 수 있습니다. 휘발성 저장만 사용 중이면 재부팅 후 이전 부팅 로그를 조회할 수 없습니다.
먼저 현재 저장 경로를 확인합니다.
sudo ls -ld /var/log/journal /run/log/journal 2>/dev/null
sudo journalctl --list-boots이전 부팅 로그를 계속 보관해야 하고 /var/log/journal이 없다면 다음과 같이 영구 journal 디렉터리를 만들 수 있습니다.
sudo mkdir -p /var/log/journal
sudo systemd-tmpfiles --create --prefix /var/log/journal
sudo journalctl --flush설정 후에는 이후 부팅부터 이전 부팅 기록을 보존할 수 있는지 확인합니다. 저장 정책은 /etc/systemd/journald.conf 및 journald.conf.d의 Storage= 설정에 의해 별도로 지정되어 있을 수 있으므로 기존 설정이 있다면 함께 확인하십시오.
8. 자주 발생하는 문제와 확인 방법
| 증상 | 가능한 원인 | 확인 방법 | 조치 방향 |
|---|---|---|---|
journalctl -b -1에서 기록이 없음 |
이전 journal이 보존되지 않음 | journalctl --list-boots와 /var/log/journal 존재 여부 확인 |
필요하면 영구 journal 저장을 구성 |
| 오류 로그가 너무 많음 | 전체 부팅 로그를 필터 없이 조회 | -p err, -u, --since 옵션 사용 |
문제가 발생한 서비스와 시간 범위로 좁혀 확인 |
| 서비스가 부팅 후 실행되지 않음 | 서비스 시작 실패 또는 의존성 문제 | systemctl --failed, journalctl -b -u 서비스명 |
실제 오류 메시지를 기준으로 설정·권한·의존 서비스 점검 |
| 디스크나 장치 오류가 의심됨 | 커널 또는 드라이버 단계 문제 | journalctl -k -b 확인 |
장치·파일시스템·드라이버 상태를 별도로 진단 |
journal 파일 자체 오류 확인
journal 파일 손상이 의심되는 경우 읽을 수 있는 journal 파일의 내부 일관성을 검사할 수 있습니다.
sudo journalctl --verify검사 결과와 함께 파일시스템 오류나 비정상 종료가 있었는지도 커널 로그에서 확인하는 것이 좋습니다.
9. 부팅 오류를 빠르게 확인하는 권장 순서
systemctl --failed로 실패한 유닛을 확인합니다.journalctl -b -p err로 현재 부팅의 주요 오류를 확인합니다.- 문제가 재부팅 전에 발생했다면
journalctl --list-boots와journalctl -b -1로 직전 부팅을 확인합니다. - 특정 서비스가 의심되면
journalctl -b -u 서비스명으로 범위를 좁힙니다. - 디스크·장치·드라이버 문제라면
journalctl -k -b를 확인합니다. - 오류가 발생한 시간 전후의 로그를 비교해 최초 실패 메시지와 연쇄 오류를 구분합니다.
공식 참고자료
- Ubuntu Manpages — journalctl - Print log entries from the systemd journal — 부팅 필터, 우선순위 필터, 커널 및 유닛 로그 조회 옵션 확인. 조회일: 2026-10-04.
- Ubuntu Manpages — systemctl - Control the systemd system and service manager — 실패한 systemd 유닛 확인 방법 확인. 조회일: 2026-10-04.
- Ubuntu Manpages — systemd-journald — journal 영구·휘발성 저장 위치와 동작 확인. 조회일: 2026-10-04.
- Canonical Ubuntu — Ubuntu 24.04 LTS release notes — Ubuntu 24.04 LTS 지원 상태 확인. 조회일: 2026-10-04.
자주 묻는 질문
현재 부팅 로그만 확인하려면 어떤 명령을 사용하나요?
sudo journalctl -b를 사용합니다. 오류 수준 이상의 메시지만 보고 싶다면 sudo journalctl -b -p err로 범위를 줄일 수 있습니다.
재부팅하기 전의 오류를 확인할 수 있나요?
이전 journal이 보존되어 있다면 가능합니다. journalctl --list-boots에서 부팅 목록을 확인하고 journalctl -b -1로 직전 부팅 로그를 조회합니다.
특정 서비스의 부팅 실패 원인만 볼 수 있나요?
가능합니다. 먼저 systemctl --failed로 실패한 유닛을 확인한 다음 journalctl -b -u 서비스명을 사용하면 해당 서비스의 현재 부팅 로그만 확인할 수 있습니다.
이전 부팅 로그가 전혀 보이지 않는 이유는 무엇인가요?
journal이 /run/log/journal에 휘발성으로만 저장되었거나 이전 로그가 보존되지 않았을 가능성이 있습니다. /var/log/journal과 journald의 Storage= 설정을 확인하십시오.
마무리
Ubuntu 24.04에서 부팅 오류를 확인할 때는 systemctl --failed로 실패한 유닛을 찾고, journalctl -b와 journalctl -b -1을 이용해 현재 부팅과 이전 부팅의 로그를 구분해서 확인하는 것이 핵심입니다. 특정 서비스는 -u, 커널 문제는 -k, 심각도는 -p 옵션을 이용하면 원인을 빠르게 좁힐 수 있습니다.
비전 IDC는 일본서버 호스팅 환경을 포함한 다양한 서버 운영 환경에서 장애 원인을 정확히 진단하고 안정적으로 서버를 관리하는 데 도움이 되는 기술정보를 지속적으로 제공하겠습니다.
