로그와 시스템 진단 기초, Linux 로그 분석으로 장애 원인을 추적하는 실무 방법
서버를 운영하다 보면 “웹사이트가 갑자기 접속되지 않습니다.”, “서비스가 자주 종료됩니다.”, “데이터베이스 연결이 실패합니다.“와 같은 장애를 경험하게 됩니다. 이러한 문제가 발생했을 때 가장 먼저 확인해야 하는 것이 바로 **로그(Log)**입니다. 로그는 운영체제와 애플리케이션이 실행되는 동안 발생한 다양한 이벤트와 오류를 기록하는 데이터로, 장애 원인을 분석하는 가장 중요한 단서가 됩니다.
실무에서 시스템 엔지니어(System Engineer)는 서버를 재부팅하기 전에 반드시 로그를 확인합니다. 로그에는 서비스 시작과 종료, 사용자 접속 기록, 시스템 오류, 네트워크 문제, 디스크 장애, 인증 실패 등 다양한 정보가 남아 있기 때문입니다. 장애 원인을 정확하게 파악하려면 로그를 읽는 방법뿐만 아니라 여러 로그를 서로 연관 지어 분석하는 능력이 필요합니다.
이번 글에서는 Linux의 journalctl과 syslog를 비롯해 웹 서버와 애플리케이션 로그를 확인하는 방법, 그리고 실제 장애 상황에서 로그를 활용하여 원인을 추적하는 실무 기법까지 자세히 알아보겠습니다.
로그(Log)는 운영체제나 프로그램이 실행되는 동안 발생하는 모든 이벤트를 기록한 데이터입니다.
로그에는 다음과 같은 정보가 저장됩니다.
로그를 분석하면 장애가 언제 발생했는지, 어떤 서비스에서 문제가 시작되었는지, 그리고 어떤 원인으로 서비스가 중단되었는지 확인할 수 있습니다.
Linux는 다양한 로그를 파일 또는 시스템 로그 서비스에 저장합니다.
대표적인 로그 저장 위치는 다음과 같습니다.
|
로그 |
위치 |
|---|---|
|
시스템 로그 |
|
|
커널 로그 |
|
|
인증 로그 |
|
|
부팅 로그 |
|
|
Apache 로그 |
|
|
Nginx 로그 |
|
최근 배포판에서는 대부분 systemd를 사용하기 때문에 journalctl을 통한 로그 조회가 기본이 되었습니다.
현재 Rocky Linux, Ubuntu, Debian 등 대부분의 Linux 배포판은 systemd를 사용하여 시스템을 관리합니다.
systemd는 서비스 관리뿐 아니라 로그까지 함께 관리하며, 이 로그를 확인하는 명령어가 journalctl입니다.
전체 로그 확인
journalctl
최신 로그만 확인
journalctl -n 100
실시간 로그 확인
journalctl -f
부팅 이후 로그만 확인
journalctl -b
이전 부팅 로그 확인
journalctl -b -1
서비스별 로그 확인
journalctl -u nginx
예를 들어 Nginx가 실행되지 않는다면 해당 서비스의 로그만 확인하여 원인을 빠르게 분석할 수 있습니다.
syslog는 Linux에서 오래전부터 사용되어 온 표준 로그 시스템입니다.
운영체제와 여러 서비스가 공통된 형식으로 로그를 기록하며, 대부분 다음 위치에 저장됩니다.
Ubuntu
/var/log/syslog
Rocky Linux
/var/log/messages
로그 확인
tail -100 /var/log/messages
또는
tail -100 /var/log/syslog
실시간 확인
tail -f /var/log/messages
journalctl이 등장한 이후에도 많은 프로그램이 syslog 형식을 함께 사용하기 때문에 여전히 중요한 로그입니다.
웹 서버 장애는 가장 자주 발생하는 문제 중 하나입니다.
대표적으로 Nginx와 Apache는 두 종류의 로그를 제공합니다.
사용자의 요청을 기록합니다.
예시
192.168.0.10 - - [15/Jul/2026:10:30:25] "GET /index.html HTTP/1.1" 200
확인할 수 있는 내용
실시간 확인
tail -f /var/log/nginx/access.log
오류만 기록합니다.
예시
connect() failed
permission denied
file not found
확인
tail -f /var/log/nginx/error.log
웹사이트가 접속되지 않는다면 Access Log보다 Error Log를 먼저 확인하는 것이 좋습니다.
Apache도 동일하게 Access Log와 Error Log를 제공합니다.
tail -f /var/log/httpd/access_log
tail -f /var/log/httpd/error_log
Apache 모듈 오류나 권한 문제는 대부분 Error Log에 기록됩니다.
웹 서버가 정상이어도 실제 프로그램에서 오류가 발생할 수 있습니다.
예를 들어 FastAPI에서는 다음과 같은 로그를 볼 수 있습니다.
Database Connection Error
500 Internal Server Error
SQLAlchemy Exception
Spring Boot라면
NullPointerException
Bean Creation Failed
Node.js라면
Unhandled Promise Rejection
애플리케이션 로그는 프로그램 내부의 예외(Exception)를 확인하는 가장 중요한 자료입니다.
증상
브라우저에서 접속되지 않는다.
확인 순서
systemctl status nginx
journalctl -u nginx
tail -f /var/log/nginx/error.log
원인
SSL 인증서 오류
또는
설정 파일 문법 오류
확인
top
vmstat
iostat
로그 확인
journalctl
원인
디스크 Full
또는
OOM 발생
로그 확인
journalctl -u postgresql
또는
PostgreSQL 로그
원인
장애가 발생하면 모든 로그를 읽기보다 다음 순서로 확인하는 것이 효율적입니다.
① 최근 시간의 로그
journalctl -n 100
② Error
grep ERROR
③ Warning
grep WARN
④ 서비스 종료
systemctl status
⑤ 최근 변경 사항
업데이트
설정 변경
배포 여부
실무에서는 “언제부터 문제가 발생했는가?“를 기준으로 로그를 분석하는 것이 매우 중요합니다.
로그 파일은 수백 MB에서 수 GB까지 커질 수 있습니다.
필요한 내용만 검색하려면 grep을 활용합니다.
예를 들어 Error 검색
grep ERROR /var/log/messages
IP 검색
grep 192.168.0.100 access.log
특정 사용자 검색
grep admin secure
날짜 검색
grep "Jul 15"
grep은 로그 분석에서 가장 많이 사용하는 명령어 중 하나입니다.
전체 로그 보기
less /var/log/messages
마지막 로그 확인
tail -100
실시간 로그 확인
tail -f
특히 tail -f는 서비스 실행과 동시에 로그를 확인할 수 있어 실시간 장애 분석에 매우 유용합니다.
로그는 중요도에 따라 구분됩니다.
|
레벨 |
의미 |
|---|---|
|
DEBUG |
개발 및 디버깅 정보 |
|
INFO |
일반적인 실행 정보 |
|
NOTICE |
중요한 이벤트 |
|
WARNING |
잠재적인 문제 |
|
ERROR |
오류 발생 |
|
CRITICAL |
심각한 장애 |
|
ALERT |
즉시 대응 필요 |
|
EMERGENCY |
시스템 사용 불가 |
실무에서는 INFO보다 WARNING과 ERROR를 우선적으로 확인하는 경우가 많습니다.
로그 분석은 단순히 오류 메시지를 찾는 것만으로 끝나지 않습니다. 동일한 시간대의 운영체제 로그, 웹 서버 로그, 애플리케이션 로그를 함께 비교해야 실제 원인을 찾을 수 있습니다. 예를 들어 웹 서버에서는 500 Internal Server Error가 발생했더라도, 원인은 데이터베이스 연결 실패나 디스크 용량 부족일 수 있습니다.
또한 서버의 시간이 정확하게 동기화되어 있지 않으면 여러 로그의 시간 순서가 맞지 않아 분석이 어려워질 수 있으므로 NTP(Network Time Protocol)를 이용한 시간 동기화도 중요합니다. 운영 환경에서는 로그를 중앙 서버로 수집하여 통합 분석하는 방식도 많이 사용됩니다.
로그는 장애 분석뿐 아니라 보안과 감사(Audit) 측면에서도 중요한 역할을 합니다.
효율적인 로그 관리를 위해서는 다음 사항을 고려해야 합니다.
기업에서는 ELK Stack(Elasticsearch, Logstash, Kibana), Grafana Loki, Graylog와 같은 중앙 로그 관리 시스템을 활용하여 여러 서버의 로그를 한곳에서 분석하는 경우가 많습니다.
로그는 시스템에서 발생하는 모든 이벤트와 오류를 기록하는 가장 중요한 정보입니다. Linux에서는 journalctl과 syslog를 통해 운영체제와 서비스의 상태를 확인할 수 있으며, Nginx와 Apache의 Access Log와 Error Log는 웹 서비스 장애를 분석하는 핵심 자료가 됩니다. 또한 애플리케이션 로그를 함께 확인하면 데이터베이스 연결 오류, 프로그램 예외, 인증 실패 등 실제 서비스의 문제를 보다 정확하게 파악할 수 있습니다.
실무에서는 단일 로그만 확인하기보다 운영체제, 웹 서버, 데이터베이스, 애플리케이션 로그를 시간 순서대로 비교하며 원인을 추적하는 것이 중요합니다. 여기에 grep, tail, less, journalctl과 같은 명령어를 활용하면 수많은 로그 속에서도 필요한 정보를 빠르게 찾아낼 수 있습니다. 이러한 로그 분석 능력은 시스템 엔지니어가 장애를 신속하게 해결하고 안정적인 서비스를 운영하기 위해 반드시 갖추어야 할 핵심 역량입니다.