리눅스 서버 재기동 전 바로 껐다 켜지 말고 확인해야 할 체크리스트

리눅스 서버 재기동 전 CPU, 메모리, 디스크, 프로세스, 포트, 로그, 자동 기동 설정을 확인하는 체크리스트를 설명하는 대표 이미지

 

리눅스 서버가 느려졌거나 서비스가 이상할 때, 가장 먼저 떠오르는 조치가 재기동일 때가 있습니다. 서버를 재기동하면 일단 문제가 해결되는 것처럼 보일 수 있습니다. 하지만 운영 서버에서는 재기동 전에 반드시 확인해야 할 항목들이 있습니다.

아무 확인 없이 바로 재기동하면 장애 원인을 놓칠 수 있고, 재기동 후 서비스가 자동으로 올라오지 않거나, 마운트된 디스크가 붙지 않거나, 연동 서비스에 영향이 생길 수도 있습니다.

특히 초보 운영자 입장에서는 “재기동하면 괜찮아지겠지”라고 생각하기 쉽습니다. 그런데 실제 운영에서는 재기동도 하나의 작업입니다. 그래서 최소한의 체크리스트를 보고 진행하는 것이 안전합니다.

이번 글에서는 리눅스 서버를 재기동하기 전에 어떤 항목을 먼저 확인하면 좋은지, 그리고 재기동 후에는 무엇을 다시 확인해야 하는지 정리해보겠습니다.

서버 재기동 전 확인이 필요한 이유

서버 재기동은 단순히 껐다 켜는 작업처럼 보일 수 있습니다.

하지만 운영 서버에서는 생각보다 확인할 것이 많습니다.

예를 들어 이런 상황이 생길 수 있습니다.

- 재기동 전 원인 프로세스를 확인하지 못함
- 서비스가 자동으로 올라오지 않음
- DB나 WAS 같은 주요 프로세스가 내려간 뒤 기동 실패
- 마운트된 디스크가 재기동 후 안 붙음
- 방화벽이나 라우팅 설정이 재기동 후 달라짐
- 작업 중이던 배치나 백업이 중단됨
- 모니터링 알림이 대량으로 발생함
- 장애 원인 분석에 필요한 로그가 사라지거나 끊김

 

물론 재기동이 필요한 상황도 있습니다.

다만 재기동을 하더라도, 최소한 “현재 상태”를 보고 진행해야 합니다.

기본은 항상 같습니다.

확인 → 판단 → 조치

가상의 운영 상황 예시

예를 들어 운영 중인 웹 서버에서 이런 상황이 발생했다고 가정해보겠습니다.

[상황]
- 사용자 접속 지연 제보 발생
- 모니터링에서 응답 시간 증가 알림 발생
- 담당자가 서버 재기동을 검토 중
- 원인은 CPU, 메모리, 디스크, 애플리케이션 로그 중 어디인지 아직 확인 전

 

이 상황에서 바로 재기동하면 일시적으로 좋아질 수 있습니다.

하지만 원인이 메모리 부족인지, 특정 프로세스 CPU 과다 사용인지, 로그 폭증인지, 포트 미기동인지 알 수 없게 됩니다.

재기동 전에는 최소한 현재 상태를 남겨야 합니다. 그래야 재기동 후에도 같은 문제가 반복될 때 비교할 수 있습니다.

1단계. 현재 접속 사용자 확인하기

서버를 재기동하기 전에 먼저 누가 접속해 있는지 확인하는 것이 좋습니다.

 

who

 

또는 아래 명령어를 사용할 수 있습니다.

 

w

 

예시입니다.

USER     TTY      FROM             LOGIN@   IDLE   JCPU   PCPU WHAT
appuser  pts/0    192.0.2.10       10:25    1:20   0.02s  0.02s -bash

 

운영 서버에서는 다른 작업자가 접속해 있을 수 있습니다.

예를 들어 누군가 로그를 확인 중이거나, 배포 작업을 하고 있거나, DB 작업을 진행 중일 수 있습니다.

그래서 재기동 전에는 최소한 접속자가 있는지 확인하고, 필요하면 작업자에게 공유하는 것이 좋습니다.

접속 사용자 있음 → 작업 여부 확인
접속 사용자 없음 → 다음 항목 확인

 

2단계. 현재 서버 부하 확인하기

재기동 전에 서버가 왜 느린지 최소한의 상태를 확인해야 합니다.

가장 먼저 볼 수 있는 명령어는 top입니다.

 

top

 

여기서 확인할 항목은 아래입니다.

- CPU 사용률
- Load Average
- 메모리 사용량
- CPU를 많이 쓰는 프로세스
- wa 값, 즉 I/O wait

 

CPU가 높다면 바로 재기동하기보다 어떤 프로세스가 CPU를 쓰고 있는지 확인합니다.

 

ps -fp PID

 

예를 들어 top에서 PID 2345가 CPU를 많이 쓰고 있다면 아래처럼 확인합니다.

 

ps -fp 2345

 

재기동을 하면 CPU를 많이 쓰던 프로세스 정보가 사라질 수 있습니다. 그래서 재기동 전에는 최소한 상위 프로세스 정도는 기록해두는 것이 좋습니다.

 

서버가 느릴 때는 CPU, 메모리, 디스크 상태를 따로따로 보는 것보다 보고 흐름까지 같이 잡아두면 좋습니다. 서버 느림 상황에서 확인한 내용을 어떻게 정리하면 좋은지는 아래 글에서 이어서 볼 수 있습니다.

https://opsnote.tistory.com/47

리눅스 서버 느림 보고할 때 CPU, 메모리, 디스크 상태 정리하는 방법

 

3단계. CPU 높은 PID가 어떤 서비스인지 확인하기

CPU 사용률이 높은 프로세스가 보이면 바로 kill 하거나 재기동하면 안 됩니다.

먼저 어떤 서비스인지 확인해야 합니다.

 

ps -fp 2345

 

실행 경로를 확인할 수도 있습니다.

 

pwdx 2345

 

프로세스 실행 파일을 확인합니다.

 

readlink -f /proc/2345/exe

 

포트와 연결된 프로세스인지 볼 수도 있습니다.

 

ss -lntp | grep 2345

 

CPU가 높은 프로세스가 정상 배치인지, 애플리케이션인지, 장애를 일으키는 비정상 프로세스인지에 따라 조치 방향이 달라집니다.

CPU가 높다고 바로 재기동하거나 프로세스를 죽이면 정상 작업을 중단할 수 있습니다.

 

CPU 100% 알림이 떴을 때는 먼저 범인 PID를 찾고, 그 PID가 어떤 서비스인지 확인하는 흐름이 중요합니다. 아래 글에서 CPU 높은 프로세스를 바로 죽이지 않고 확인하는 순서를 따로 정리했습니다.

https://opsnote.tistory.com/45

리눅스 서버 CPU 100% 알림 떴을 때, 재기동 전 범인(PID)부터 찾는 법

 

4단계. 메모리와 Swap 확인하기

서버가 느려졌을 때 메모리도 확인해야 합니다.

 

free -m

 

예시입니다.

              total        used        free      shared  buff/cache   available
Mem:          16000       12000         500         300        3500        3200
Swap:          4096        1800        2296

 

여기서 used만 보면 안 됩니다.

같이 볼 항목은 아래입니다.

- available
- buff/cache
- Swap used

 

리눅스는 캐시 때문에 used가 높게 보일 수 있습니다. 그래서 실제 판단에서는 available을 같이 봐야 합니다.

메모리 상태를 볼 때 used만 보고 “메모리 부족”으로 판단하면 틀릴 수 있습니다. available 기준으로 보는 방법은 아래 글에서 이어서 확인할 수 있습니다.

https://opsnote.tistory.com/44

리눅스 서버 메모리 used만 보면 판단이 틀리는 이유와 available 확인법

 

Swap 사용량도 함께 봐야 합니다.

Swap이 많이 올라가 있다고 해서 바로 재기동해야 하는 것은 아닙니다. 중요한 것은 현재도 Swap 입출력이 계속 발생하는지입니다.

 

vmstat 1 5

 

여기서 si, so 값을 봅니다.

si → swap in
so → swap out

 

si, so가 계속 발생한다면 메모리 압박이 현재 진행 중일 가능성이 있습니다.

Swap이 올라갔다고 바로 재기동하기보다, 현재 Swap 입출력이 지속되는지 확인하는 것이 중요합니다. 아래 글에서 Swap을 어떻게 해석하면 좋은지 따로 정리했습니다.

https://opsnote.tistory.com/43

리눅스 서버 Swap 올라갔다고 바로 재기동하지 말고 확인하는 순서

 

5단계. OOM 로그 확인하기

서비스가 갑자기 죽었거나 서버가 느려진 뒤 프로세스가 사라졌다면 OOM도 확인해야 합니다.

 

dmesg -T | grep -i -E "out of memory|oom|killed process"

 

또는 systemd 환경에서는 아래처럼 볼 수 있습니다.

 

journalctl -k | grep -i -E "out of memory|oom|killed process"

 

OOM은 커널이 메모리 부족 상황에서 특정 프로세스를 강제로 종료한 경우입니다.

이 경우 단순히 서비스를 다시 올리거나 서버를 재기동해도 같은 문제가 반복될 수 있습니다.

확인할 것은 아래입니다.

- 어떤 프로세스가 종료됐는지
- 종료 시각이 장애 발생 시각과 맞는지
- 메모리 사용량이 계속 증가했는지
- 최근 배포나 설정 변경이 있었는지

 

OOM 흔적이 있다면 재기동보다 메모리 사용 원인 확인이 먼저입니다.

6단계. 디스크 사용률 확인하기

재기동 전에 디스크 사용률도 봐야 합니다.

 

df -h

 

여기서 중요한 것은 Use%만 보는 것이 아니라 Mounted on을 같이 보는 것입니다.

예시입니다.

Filesystem      Size  Used Avail Use% Mounted on
/dev/vda1        50G   47G  3.0G  94% /
/dev/vdb1       200G  100G  100G  50% /data

 

/ 영역이 90% 이상이면 주의가 필요합니다.

OS 영역이 꽉 차면 서비스 기동, 로그 기록, 임시파일 생성 등에 문제가 생길 수 있습니다.

디스크가 높다면 바로 삭제하지 말고 어떤 경로가 큰지 확인합니다.

 

du -xhd1 / 2>/dev/null | sort -h

 

로그가 큰 경우에는 /var/log도 확인합니다.

 

du -xhd1 /var/log 2>/dev/null | sort -h

 

삭제 전에는 반드시 서비스 영향도와 로그 보관 필요 여부를 확인해야 합니다.

이제 디스크 시리즈는 별도로 정리했으니, 이 글에서는 “재기동 전 디스크 상태도 빠뜨리지 않는다” 정도로만 잡으면 됩니다.

7단계. 주요 서비스 프로세스 확인하기

서버 재기동 후 가장 문제가 되는 것 중 하나가 서비스 자동 기동입니다.

재기동 전에는 현재 어떤 서비스가 떠 있는지 확인해두는 것이 좋습니다.

 

ps -ef | grep 서비스명

 

예를 들어 Java 서비스라면 아래처럼 볼 수 있습니다.

 

ps -ef | grep java

 

프로세스 확인 시에는 아래를 봅니다.

- 실행 계정
- PID
- 실행 명령어
- 서비스명
- 프로세스 개수

 

예시입니다.

app  2345  1  2 10:25 ?  00:03:12 java -jar service-api.jar

 

이 정보를 남겨두면 재기동 후 정상적으로 다시 올라왔는지 비교할 수 있습니다.

재기동 전:

 

ps -ef | grep java

 

재기동 후:

 

ps -ef | grep java

 

이렇게 비교하면 됩니다.

8단계. 포트 LISTEN 상태 확인하기

프로세스가 떠 있어도 포트가 안 열려 있으면 접속이 안 될 수 있습니다.

재기동 전에는 주요 포트가 열려 있는지 확인합니다.

 

ss -lntp

 

특정 포트만 확인할 때는 아래처럼 봅니다.

 

ss -lntp | grep ':8080'

 

예시입니다.

LISTEN 0 128 0.0.0.0:8080 0.0.0.0:* users:(("java",pid=2345))

 

여기서 봐야 할 것은 아래입니다.

- LISTEN 상태
- 포트 번호
- 프로세스명
- PID
- Listen IP

 

재기동 후에도 같은 포트가 다시 LISTEN 상태인지 확인해야 합니다.

포트가 안 올라오면 서비스 기동 실패나 설정 문제일 수 있습니다.

 

접속 장애 상황에서는 netstat보다 ss -lntp로 포트와 프로세스를 확인하는 흐름을 익혀두면 좋습니다. 아래 글에서 ss로 포트 상태를 확인하는 방법을 따로 정리했습니다.

https://opsnote.tistory.com/18

리눅스 서버 접속이 안 될 때 netstat보다 ss로 포트 확인하는 이유

 

9단계. 마운트 상태 확인하기

서버에 별도 디스크나 NAS, NFS가 붙어 있다면 마운트 상태도 확인해야 합니다.

 

df -h

 

또는 아래처럼 볼 수 있습니다.

 

mount | grep -E "nfs|data|backup|logs"

 

운영 환경에 따라 /data, /backup, /logs, /app 같은 경로가 별도 디스크일 수 있습니다.

재기동 후 마운트가 안 붙으면 서비스가 정상 기동되지 않거나 로그 저장에 실패할 수 있습니다.

확인할 것은 아래입니다.

- 재기동 전 마운트된 경로
- 재기동 후 동일하게 마운트되는지
- /etc/fstab 설정이 있는지
- NFS나 NAS 연결 장애 가능성이 있는지

 

재기동 전에는 현재 마운트 상태를 확인하고, 재기동 후에도 동일하게 붙었는지 확인하는 것이 좋습니다.

10단계. 최근 로그 확인하기

서버 재기동 전에는 최근 로그도 확인합니다.

OS 로그는 환경에 따라 다르지만 아래를 볼 수 있습니다.

 

tail -n 100 /var/log/messages

 

Ubuntu 계열에서는 아래처럼 볼 수 있습니다.

 

tail -n 100 /var/log/syslog

 

systemd 환경에서는 아래 명령어를 사용할 수 있습니다.

 

journalctl -xe

 

서비스 로그도 확인합니다.

 

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

 

재기동 전 로그를 확인하는 이유는 간단합니다.

- 재기동 전 에러가 있었는지
- OOM이나 디스크 오류가 있었는지
- 서비스가 이미 죽어 있었는지
- 반복 에러가 있었는지
- 재기동 후에도 같은 에러가 반복되는지 비교하기 위해

 

로그가 계속 커지거나 반복 오류가 보인다면 재기동보다 로그 증가 원인을 먼저 확인해야 합니다. 로그 파일이 계속 커질 때 확인하는 흐름은 아래 글에서 이어서 볼 수 있습니다.

https://opsnote.tistory.com/7

리눅스 서버 로그 파일이 계속 커질 때 바로 비우지 말고 확인하는 법

 

11단계. 자동 기동 설정 확인하기

서버를 재기동하면 서비스가 자동으로 올라와야 하는 경우가 있습니다.

systemd 서비스라면 아래처럼 확인할 수 있습니다.

 

systemctl status example-app

 

자동 기동 여부는 아래처럼 확인합니다.

 

systemctl is-enabled example-app

 

예시입니다.

enabled

 

enabled면 부팅 시 자동 기동 설정이 되어 있는 상태입니다.

만약 disabled라면 재기동 후 서비스가 자동으로 올라오지 않을 수 있습니다.

재기동 전에 이 부분을 확인하지 않으면, 서버는 올라왔는데 서비스는 안 떠 있는 상황이 생길 수 있습니다.

확인 흐름은 이렇게 잡으면 좋습니다.

1. systemctl status 로 현재 상태 확인
2. systemctl is-enabled 로 자동 기동 여부 확인
3. 재기동 후 systemctl status 재확인
4. 포트 LISTEN 상태 확인
5. curl로 서비스 응답 확인

 

12단계. 작업 중인 배치나 백업 확인하기

운영 서버에서는 배치, 백업, 압축, 로그 정리 작업이 돌고 있을 수 있습니다.

프로세스에서 확인할 수 있습니다.

 

ps -ef | grep -E "backup|rsync|tar|gzip|java|python|sh"

 

cron 설정도 확인할 수 있습니다.

 

crontab -l

 

시스템 cron은 아래 경로에 있을 수 있습니다.

 

ls -l /etc/cron*

 

재기동 시점에 배치나 백업이 실행 중이면 작업이 중단될 수 있습니다.

특히 DB 백업, 파일 백업, 대용량 압축 작업은 재기동 전에 반드시 확인하는 것이 좋습니다.

바로 재기동하기 전에 아래를 확인합니다.

- 백업 작업 실행 중인지
- 배치 작업 실행 중인지
- 로그 압축 작업이 있는지
- 데이터 이관이나 대용량 파일 처리 중인지
- 작업 중단 시 재실행 가능한지

 

13단계. 재기동 전 기록해두면 좋은 정보

재기동 전에 모든 것을 길게 문서화할 필요는 없습니다.

다만 최소한 아래 정도는 기록해두면 좋습니다.

- 현재 시간
- CPU/Load 상태
- free -m 결과
- df -h 결과
- 주요 프로세스 상태
- 주요 포트 LISTEN 상태
- 최근 에러 로그
- 재기동 사유

 

간단히 명령어 결과를 저장하려면 이런 식으로 할 수 있습니다.

 

date
top -b -n 1 | head -20
free -m
df -h
ss -lntp

 

필요하면 파일로 남깁니다.

 

{
  date
  free -m
  df -h
  ss -lntp
} > /tmp/pre-reboot-check.txt

 

다만 운영 서버에서는 파일 저장 위치도 조심해야 합니다.

민감한 정보가 포함될 수 있으니 외부 공유 전에는 반드시 확인해야 합니다.

14단계. 재기동 후 확인할 것

재기동은 실행보다 사후 확인이 더 중요할 때가 많습니다.

재기동 후에는 아래를 확인합니다.

- 서버 접속 가능 여부
- 마운트 상태
- 서비스 프로세스 기동 여부
- 포트 LISTEN 상태
- 애플리케이션 응답 여부
- 로그 에러 여부
- 모니터링 알림 해소 여부

 

자주 쓰는 명령어는 아래입니다.

 

uptime
df -h
ps -ef | grep 서비스명
ss -lntp | grep ':8080'
curl -o /dev/null -s -w "%{http_code}\n" http://localhost:8080

 

재기동 후 서비스가 정상인지 확인하지 않으면, 서버만 살아 있고 서비스는 죽어 있는 상태를 놓칠 수 있습니다.

특히 포트가 열렸다고 끝이 아닙니다. 내부에서 curl로 실제 응답까지 확인하는 것이 좋습니다.

서버 재기동 전 체크리스트 정리

초보 운영자 기준으로는 아래 순서만 기억해도 좋습니다.

1. 접속 사용자 확인
2. CPU/Load 확인
3. CPU 높은 PID 확인
4. 메모리/Swap 확인
5. OOM 로그 확인
6. 디스크 사용률 확인
7. 주요 프로세스 확인
8. 포트 LISTEN 확인
9. 마운트 상태 확인
10. 최근 로그 확인
11. 자동 기동 설정 확인
12. 배치/백업 작업 여부 확인
13. 재기동 전 상태 기록
14. 재기동 후 서비스 확인

 

명령어로 정리하면 아래입니다.

 

who
top
uptime
free -m
vmstat 1 5
df -h
ps -ef | grep 서비스명
ss -lntp
journalctl -xe
systemctl status 서비스명
systemctl is-enabled 서비스명
curl -o /dev/null -s -w "%{http_code}\n" http://localhost:포트

 

실무 보고 예시

서버 재기동 전 보고는 이렇게 정리할 수 있습니다.

서버 재기동 전 기본 상태를 확인했습니다.
현재 CPU/메모리/디스크 사용률은 즉시 장애 수준은 아닌 것으로 확인되며,
주요 서비스 프로세스와 LISTEN 포트 상태를 확인했습니다.
재기동 후 동일 프로세스 및 포트 상태, 서비스 응답 여부를 재확인하겠습니다.

 

장애 대응 중 재기동이 필요한 경우는 이렇게 쓸 수 있습니다.

현재 서비스 응답 지연이 지속되어 기본 상태 확인 후 서버 재기동을 검토 중입니다.
재기동 전 CPU, 메모리, 디스크, 프로세스, 포트 상태를 확인했으며,
재기동 후 서비스 기동 여부와 로그 이상 여부를 확인하겠습니다.

 

자동 기동이 우려될 때는 이렇게 쓸 수 있습니다.

재기동 후 서비스 자동 기동 여부 확인이 필요합니다.
systemctl is-enabled 기준 자동 기동 설정을 확인하고,
재기동 후 프로세스 및 포트 LISTEN 상태를 재확인하겠습니다.

 

재기동을 보류하고 원인 확인을 먼저 해야 할 때는 이렇게 쓸 수 있습니다.

현재 서버 재기동 전 기본 상태를 확인 중입니다.
CPU 사용률이 높은 PID와 최근 로그에서 반복 오류가 확인되어,
재기동 전 원인 범위를 먼저 확인한 뒤 조치 여부를 판단하겠습니다.

 

정리하면

리눅스 서버 재기동은 단순한 조치처럼 보이지만, 운영 서버에서는 반드시 확인이 필요한 작업입니다.

재기동 전에는 최소한 아래 항목을 봐야 합니다.

- 접속 사용자
- CPU와 Load
- 메모리와 Swap
- OOM 로그
- 디스크 사용률
- 프로세스
- 포트
- 로그
- 마운트
- 자동 기동 설정
- 배치와 백업 작업

 

초보 운영자라면 아래 문장만 기억해도 좋습니다.

서버 재기동은 마지막 조치가 아니라, 확인 후 진행해야 하는 작업입니다.

바로 재기동하기보다 먼저 현재 상태를 확인하고, 재기동 후 정상 여부까지 확인해야 합니다.

서버 운영에서는 항상 같습니다.

확인 → 판단 → 조치

 

서버 재기동은 마지막 조치에 가깝습니다.

재기동 전에는 현재 사용자, CPU와 메모리 상태, 디스크 사용률, 프로세스, 포트, 로그, 자동 기동 설정을 먼저 확인해야 합니다.  
그리고 재기동 후에는 서비스가 정상적으로 올라왔는지 다시 확인해야 합니다.

서비스를 재기동한 뒤 정상 여부를 확인하는 순서는 아래 글에서 이어서 볼 수 있습니다.

https://opsnote.tistory.com/29

리눅스 서버 systemctl restart 후 정상 기동 확인하는 법, 명령어만 치고 끝내지 마세요

 

서비스 상태와 로그를 먼저 확인하는 방법은 아래 글도 함께 보면 좋습니다.

https://opsnote.tistory.com/27

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

 

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

https://opsnote.tistory.com/69

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