1. 사이트가 갑자기 안 열린다 – 침착하게 대응하는 법
“사이트가 안 들어가요”라는 연락을 받거나 스스로 접속이 안 된다는 것을 발견했을 때, 처음에는 당황스럽습니다. 무작정 서버를 재부팅하고 싶은 충동이 생기지만 참는 것이 좋습니다.
원인도 파악하지 않고 재부팅하면 증거가 사라집니다. 임시로 복구될 수 있지만 같은 문제가 반복될 가능성이 높습니다. 단계별로 원인을 추적하는 것이 장기적으로 훨씬 유리합니다.
2. 1단계 – 서버가 살아있는지 먼저 확인
먼저 서버 자체가 살아있는지, 아니면 특정 서비스만 문제인지를 구분해야 합니다.
ping 테스트 내 컴퓨터에서 서버 IP로 ping을 보내 네트워크 연결을 확인합니다.
ping 서버IP주소
응답이 온다면 서버 자체는 살아있고 특정 서비스에 문제가 생긴 것입니다. 응답이 없다면 서버 자체가 다운됐거나 네트워크 단절일 가능성이 높습니다.
SSH 접속 시도 ping이 되더라도 SSH로 직접 접속을 시도합니다. SSH 접속이 된다면 서버는 정상이므로 서비스 문제를 점검합니다. SSH도 안 된다면 서버 자체의 심각한 문제입니다.
3. 2단계 – 서비스 상태 점검
SSH 접속이 된다면 문제가 생긴 서비스의 상태를 바로 확인합니다.
Nginx 상태 확인입니다.
sudo systemctl status nginx
MySQL 상태 확인입니다.
sudo systemctl status mysql
Active: failed나 Active: inactive (dead) 상태라면 서비스가 죽어 있는 것입니다. 로그를 확인하기 전에 일단 재시작을 시도해볼 수 있습니다.
sudo systemctl restart nginx
재시작 후 상태를 다시 확인하고 여전히 실패한다면 로그 분석으로 넘어갑니다.
4. 3단계 – 자원 사용량 확인
서비스는 실행 중인데 응답이 느리거나 없다면 자원 부족이 원인일 수 있습니다.
CPU 확인 top 명령을 실행해 CPU 사용률을 확인합니다. 특정 프로세스가 CPU를 거의 100% 독점하고 있다면 해당 프로세스를 조사합니다.
메모리 확인 free -h 명령으로 available 메모리를 확인합니다. 거의 0에 가깝다면 메모리 부족이 원인입니다. 이 경우 불필요한 프로세스를 종료하거나 서버를 재시작하는 것이 방법입니다.
디스크 확인 df -h 명령으로 디스크 사용량을 확인합니다. Use% 항목이 100%라면 디스크가 가득 찬 것입니다. 로그 파일이나 임시 파일을 정리해야 합니다.
디스크가 꽉 차는 것은 서버 장애의 흔한 원인 중 하나입니다. 특히 로그 파일이 제한 없이 쌓이면 며칠 만에 디스크를 가득 채울 수 있습니다.
5. 4단계 – 로그 파일 분석
서비스가 재시작이 안 된다면 로그를 통해 원인을 찾아야 합니다.
서비스 상세 로그를 확인합니다.
sudo journalctl -u nginx -n 100
Nginx 오류 로그를 확인합니다.
sudo tail -n 100 /var/log/nginx/error.log
시스템 로그에서 재시작 직전 기록을 확인합니다.
sudo tail -n 200 /var/log/syslog
OOM Killer(메모리 부족으로 인한 강제 프로세스 종료)가 동작했는지 확인합니다.
sudo dmesg | grep -i “killed process”
OOM Killer가 Nginx나 애플리케이션을 강제 종료했다면, 메모리 부족이 원인입니다.
6. 5단계 – 서버 자체가 죽었을 때
ping과 SSH 모두 안 된다면 서버 자체가 다운된 것입니다.
클라우드 콘솔 접근 AWS, GCP, 기타 클라우드 서비스의 관리 콘솔에 접속합니다. 인스턴스 상태가 stopped라면 시작 버튼으로 재시작합니다. 실행 중인데 응답이 없다면 인스턴스 재부팅(Reboot) 또는 강제 중지 후 재시작을 시도합니다.
재시작 후 반드시 로그 확인 재시작 후 시스템이 올라오면 즉시 로그를 확인해 원인을 파악합니다. 원인을 모른 채 재시작만 반복하면 같은 문제가 재발합니다.
7. 원인별 빠른 해결 방법
| 원인 | 증상 | 해결 방법 |
|---|---|---|
| 서비스 비정상 종료 | systemctl status에서 failed | systemctl restart로 재시작 |
| 디스크 가득 참 | df -h에서 100% | 로그 파일 및 임시 파일 삭제 |
| 메모리 부족 | free -h에서 available 0 | 불필요 프로세스 종료, 메모리 증설 |
| CPU 과부하 | top에서 100% | 원인 프로세스 확인 및 처리 |
| 설정 파일 오류 | 재시작 시 계속 failed | 로그에서 오류 위치 확인, 문법 수정 |
| 서버 전체 다운 | ping과 SSH 불가 | 클라우드 콘솔에서 재시작 |
8. 재발 방지를 위한 예방 조치
복구 후에는 반드시 재발 방지 조치를 취해야 합니다.
모니터링 알림 설정: CPU, 메모리, 디스크 사용량이 임계치를 넘으면 알림을 받도록 설정합니다.
로그 정리 자동화: logrotate와 cron을 활용해 오래된 로그를 주기적으로 삭제합니다.
디스크 여유 공간 확보: 로그 파티션을 분리하거나 정기적으로 용량을 점검합니다.
장애 기록 남기기: 언제, 어떤 원인으로, 어떻게 해결했는지 기록해 두면 나중에 비슷한 상황에서 빠르게 대응할 수 있습니다.
9. 정리 및 다음 단계
서버 장애 대응 단계를 정리합니다.
1단계로 ping과 SSH로 서버 생존 여부를 확인합니다. 2단계로 systemctl status로 서비스 상태를 점검합니다. 3단계로 top, free, df로 자원 사용량을 확인합니다. 4단계로 journalctl과 로그 파일로 원인을 분석합니다. 5단계로 서버 자체가 다운됐다면 클라우드 콘솔에서 재시작합니다.
다음 글에서는 SSL 인증서를 무료로 발급받고 HTTPS를 적용하는 방법을 상세히 알아보겠습니다.