서버가 갑자기 다운됐을 때 원인 찾는 방법 정리

목차

1. 서버 다운, 당황하지 말자
2. 1단계 – 서버가 살아있는지 확인
3. 2단계 – 서비스 상태 확인
4. 3단계 – 시스템 자원 확인 (CPU, 메모리, 디스크)
5. 4단계 – 로그로 원인 추적하기
6. 5단계 – 서버가 완전히 응답하지 않을 때
7. 원인별 해결 방법 요약
8. 재발 방지를 위한 체크리스트
9. 정리

1. 서버 다운, 당황하지 말자

서버를 운영하다 보면 언젠가 반드시 다운 상황을 맞닥뜨립니다. 사이트에 갑자기 접속이 안 된다는 연락을 받거나, 모니터링 알림이 울리는 순간 머릿속이 하얘지는 경험은 서버를 다뤄본 사람이라면 누구나 겪어봤을 것입니다.

이런 상황에서 가장 중요한 것은 침착하게 순서대로 원인을 추적하는 것입니다. 원인도 모른 채 서버를 무작정 재부팅하면 일시적으로 복구될 수 있지만, 근본 원인을 해결하지 못해 같은 문제가 반복됩니다.

이 글에서는 서버가 다운됐을 때 단계별로 원인을 찾는 체계적인 방법을 알려드립니다.

2. 1단계 – 서버가 살아있는지 확인

가장 먼저 서버 자체가 살아있는지 확인합니다. 서비스 다운과 서버 자체 다운은 원인과 해결 방법이 완전히 다릅니다.

ping 테스트 내 컴퓨터에서 서버로 ping을 보내 네트워크 연결 여부를 확인합니다.

ping 서버IP주소

응답이 오면 서버는 살아있지만 특정 서비스가 죽은 것입니다. 응답이 없다면 서버 자체가 다운되었거나 네트워크 문제가 있는 것입니다.

SSH 접속 시도 ping이 돼도 SSH로 접속해 봅니다. SSH 접속이 되면 서버는 정상 동작 중이고, 특정 서비스에 문제가 생긴 것입니다. SSH도 안 된다면 서버 자체의 심각한 문제이므로 클라우드 서비스의 콘솔(웹 기반 원격 접속)을 사용해야 합니다.

3. 2단계 – 서비스 상태 확인

SSH 접속이 됐다면 서비스 상태를 확인합니다. 웹 서버가 응답하지 않는다면 Nginx 상태부터 확인합니다.

sudo systemctl status nginx

active (running) 상태가 아니라면 서비스가 죽은 것입니다. 로그를 확인해 왜 종료됐는지 파악해야 합니다.

sudo journalctl -u nginx -n 100

데이터베이스 서버도 함께 확인합니다.

sudo systemctl status mysql

4. 3단계 – 시스템 자원 확인 (CPU, 메모리, 디스크)

서비스 자체는 실행 중인데 응답이 느리거나 없다면 자원 부족이 원인일 수 있습니다.

CPU 사용량 확인 top 명령어를 실행해 CPU가 100%에 달해있는지 확인합니다. 특정 프로세스가 CPU를 독점하고 있다면 그것이 원인입니다.

top

메모리 확인 메모리가 부족하면 서버가 스왑 영역을 사용하게 되고, 이 경우 성능이 급격히 저하됩니다.

free -h

available 값이 거의 0에 가깝다면 메모리 부족이 원인입니다.

디스크 확인 디스크가 가득 차면 로그 기록, 파일 생성 등 모든 쓰기 작업이 실패합니다. 서버가 다운되는 가장 흔한 원인 중 하나입니다.

df -h

Use% 항목이 100%에 가깝다면 디스크 부족이 원인입니다. 로그 파일이나 임시 파일을 정리해야 합니다.

5. 4단계 – 로그로 원인 추적하기

자원이 정상인데도 서비스가 죽었다면 로그를 상세히 살펴봐야 합니다.

시스템 로그 확인 서버 전체에서 발생한 오류를 확인합니다.

sudo tail -n 100 /var/log/syslog

서비스별 오류 로그 확인

sudo tail -n 100 /var/log/nginx/error.log

OOM Killer 동작 여부 확인 메모리가 완전히 부족하면 리눅스 커널이 특정 프로세스를 강제 종료하는 **OOM Killer(Out of Memory Killer)**가 동작합니다. 이 경우 아래 명령어로 확인할 수 있습니다.

sudo dmesg | grep -i "killed process"

OOM Killer가 Nginx나 MySQL을 종료했다면 메모리 증설 또는 메모리 누수 해결이 필요합니다.

6. 5단계 – 서버가 완전히 응답하지 않을 때

SSH도 접속이 안 되고 ping도 안 된다면 서버 자체가 완전히 다운된 것입니다. 이 경우 클라우드 서비스의 관리 콘솔을 통해 대응합니다.

AWS EC2의 경우 AWS 콘솔에서 EC2 인스턴스 상태를 확인합니다. 인스턴스가 stopped 상태라면 Start 버튼으로 재시작합니다. 실행 중인데 응답이 없다면 인스턴스 재부팅(Reboot) 또는 강제 중지 후 시작(Stop → Start)을 시도합니다.

재시작 후에는 반드시 로그를 확인해 원인을 파악하고, 재발 방지 조치를 취해야 합니다.

7. 원인별 해결 방법 요약

원인증상해결 방법

서비스 비정상 종료	특정 서비스만 응답 없음	systemctl restart로 재시작
CPU 과부하	top에서 CPU 100%	원인 프로세스 확인 후 처리
메모리 부족	free에서 available 거의 0	불필요한 프로세스 종료, 메모리 증설
디스크 풀	df에서 Use% 100%	로그·임시파일 정리, 디스크 증설
OOM Killer 동작	dmesg에서 killed process	메모리 누수 해결, 메모리 증설
서버 자체 다운	ping, SSH 모두 불가	클라우드 콘솔에서 재시작

8. 재발 방지를 위한 체크리스트

서버를 복구한 후에는 반드시 재발 방지 조치를 취해야 합니다.

원인이 된 로그를 저장해두고 나중에 분석합니다. 디스크가 문제였다면 logrotate 설정을 점검하고 불필요한 파일을 정기적으로 정리하는 cron 작업을 설정합니다. 메모리가 문제였다면 애플리케이션의 메모리 설정을 점검합니다. CPU 과부하가 문제였다면 어떤 요청이 원인이었는지 access 로그를 분석합니다. 그리고 모니터링 도구를 설정해 자원 사용량이 임계치를 넘으면 알림을 받도록 합니다.

9. 정리

서버 다운 시 대응 순서를 정리합니다.

1단계로 ping과 SSH로 서버 생존 여부를 확인합니다. 2단계로 systemctl status로 서비스 상태를 확인합니다. 3단계로 top, free, df로 자원 사용량을 확인합니다. 4단계로 로그 파일에서 오류 메시지를 분석합니다. 5단계로 서버 자체가 다운됐다면 클라우드 콘솔에서 재시작합니다.

복구 후에는 원인을 분석하고 재발 방지 조치를 반드시 취해야 합니다.