opsnote - 초보 인프라 노트

리눅스 서버에서 OOM으로 서비스가 죽었는지 확인하는 실제 점검 흐름

opsnote — Mon, 28 Sep 2026 23:27:40 +0900

OOM CHECK 서비스가 갑자기 죽었다 재시작 전에 확인

운영 중인 리눅스 서버에서 서비스가 갑자기 내려갔다는 연락을 받으면 가장 먼저 떠오르는 대응 중 하나가 재시작입니다.

systemctl restart 서비스명

서비스를 빨리 살려야 하는 상황에서는 필요한 조치일 수 있습니다.

하지만 바로 재시작해 버리면 왜 서비스가 종료됐는지 확인할 수 있는 단서를 놓칠 수 있습니다.

특히 메모리 부족으로 Linux 커널의 OOM Killer가 프로세스를 종료한 상황이라면 단순히 서비스를 다시 올리는 것만으로는 원인이 해결되지 않습니다.

저라면 서비스가 갑자기 죽었을 때 다음 순서로 확인합니다.

서비스 종료 확인
→ OOM 로그 확인
→ 어떤 프로세스가 종료됐는지 확인
→ 현재 메모리와 Swap 확인
→ 메모리를 많이 사용하는 프로세스 확인
→ 서비스 상태와 로그 확인
→ 조치
→ 재확인

이번 글에서는 이 흐름대로 정리해보겠습니다.

1. 서비스가 죽었다고 바로 restart부터 하지 않는다

예를 들어 웹 애플리케이션 서비스가 갑자기 내려갔다고 가정해보겠습니다.

초보 운영자 입장에서는 일단 서비스를 다시 올리고 싶어집니다.

systemctl restart myapp

하지만 운영 서버에서는 먼저 생각할 것이 있습니다.

지금 재시작하면 장애 원인을 확인하는 데 필요한 상태가 바뀌지 않는가?

그리고 서비스 재시작이 사용자에게 어떤 영향을 주는지도 확인해야 합니다.

서비스를 즉시 복구해야 하는 긴급 상황이라면 재시작이 우선일 수도 있습니다. 반대로 원인을 확인할 시간이 있다면 먼저 로그와 현재 상태를 확보하는 편이 좋습니다.

우선 서비스 상태부터 확인합니다.

systemctl status myapp

여기서 서비스가 실제로 내려가 있는지, 종료 시점은 언제인지, 어떤 종료 상태가 남아 있는지 확인합니다.

서비스 상태 확인 방법은 아래 글에서도 따로 정리했습니다.

https://opsnote.tistory.com/73

리눅스 서버 서비스가 안 뜰 때 systemctl status와 journalctl로 원인 좁히는 과정

리눅스 서버를 운영하다 보면 서비스가 안 뜨는 상황을 만날 때가 있습니다.처음에는 단순하게 보입니다.서비스가 안 뜬다.프로세스가 죽은 것 같다.restart 하면 되지 않을까?저도 처음에는 이렇

opsnote.tistory.com

2. OOM 흔적부터 확인한다

서비스가 특별한 이유 없이 갑자기 종료됐고 메모리 문제가 의심된다면 커널 로그에서 OOM 관련 기록을 찾아봅니다.

먼저 다음과 같이 확인할 수 있습니다.

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

systemd 환경에서는 커널 로그를 다음처럼 확인할 수도 있습니다.

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

예를 들어 로그에서 다음과 비슷한 내용을 발견했다고 가정해보겠습니다.

Out of memory: Killed process 12345 (java) total-vm:...

여기서 중요한 것은 단순히 OOM이라는 문자열이 있다는 사실만 보는 것이 아닙니다.

실제로 어떤 프로세스가 종료됐는지 확인해야 합니다.

위 예시에서는 PID 12345의 java 프로세스가 종료됐다는 흔적을 확인할 수 있습니다.

이런 기록이 장애 발생 시각과 일치한다면 OOM과 서비스 종료의 연관성을 의심할 수 있는 중요한 근거가 됩니다.

다만 dmesg 출력은 시스템 설정이나 권한에 따라 제한될 수 있고, 로그 보존 상태에 따라 과거 기록이 남아 있지 않을 수도 있습니다.

그래서 한 가지 명령 결과만 보고 바로 결론을 내리기보다 서비스 로그와 당시 상황을 함께 확인하는 것이 좋습니다.

3. 종료된 프로세스가 실제 서비스 프로세스인지 확인한다

OOM 로그에서 Killed process를 찾았다면 다음 질문으로 넘어갑니다.

죽은 프로세스가 장애가 발생한 서비스와 관련된 프로세스인가?

예를 들어 다음과 같은 기록이 있다고 해보겠습니다.

Killed process 12345 (java)

java라는 이름만으로는 어떤 서비스인지 확실하지 않을 수 있습니다.

이미 프로세스가 종료됐다면 현재 ps에서 해당 PID를 찾을 수 없을 가능성이 높습니다.

따라서 장애 시각의 서비스 로그, systemd 기록 등을 같이 확인합니다.

systemctl status myapp

journalctl -u myapp

특정 시간대를 알고 있다면 범위를 좁혀 보는 것도 좋습니다.

journalctl -u myapp --since "2026-09-28 14:00:00" --until "2026-09-28 14:10:00"

예시의 날짜와 시간은 실제 장애 발생 시각에 맞게 바꿔서 사용하면 됩니다.

이렇게 보면 커널에서 프로세스가 종료된 시각과 서비스가 내려간 시각이 비슷한지 비교할 수 있습니다.

4. free -m으로 현재 메모리 상태를 확인한다

OOM 흔적을 확인했다면 현재 메모리 상태도 봅니다.

free -m

예를 들면 다음과 같은 항목이 표시됩니다.

               total        used        free      shared  buff/cache   available
Mem:           15900       14200         300         100        1400         800
Swap:           4096        3900         196

여기서 초보 운영자가 많이 보는 값이 free입니다.

하지만 free 값 하나만 보고 메모리가 부족하다고 판단하면 안 됩니다.

Linux는 사용하지 않는 메모리를 캐시 등에 활용하기 때문에 실제로 추가 프로세스가 사용할 수 있는 메모리를 판단할 때는 available도 같이 보는 것이 좋습니다.

free -m 결과를 볼 때 제가 같이 확인하는 것은 다음입니다.

전체 메모리
available 메모리
Swap 사용량
장애 이후에도 메모리 압박이 계속되고 있는지

free -m의 available에 대해서는 아래 글에 따로 정리했습니다.

https://opsnote.tistory.com/44

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

리눅스 서버에서 메모리 상태를 확인할 때 가장 많이 쓰는 명령어 중 하나가 free -m입니다.free -m그런데 초보 운영자 입장에서 가장 헷갈리는 부분이 있습니다.used 값이 높게 보이면 바로 “메모

opsnote.tistory.com

여기서 한 가지 주의할 점이 있습니다.

현재 free -m 결과가 정상이라고 해서 장애 당시에도 메모리가 정상이었다는 뜻은 아닙니다.

OOM Killer가 프로세스를 종료하면 해당 프로세스가 사용하던 메모리가 반환될 수 있습니다.

따라서 OOM 발생 여부는 현재 메모리 상태만으로 판단하지 않고 커널 로그와 장애 시각의 모니터링 데이터가 있다면 함께 확인하는 것이 좋습니다.

5. Swap도 같이 확인한다

다음으로 Swap 상태를 봅니다.

free -m

또는 다음 명령으로 현재 Swap 사용 상태를 확인할 수 있습니다.

swapon --show

Swap을 많이 사용하고 있다고 해서 무조건 장애라고 볼 수는 없습니다.

반대로 Swap이 없다고 해서 그것만으로 OOM의 원인이라고 단정할 수도 없습니다.

중요한 것은 장애 당시 물리 메모리와 Swap이 어떤 상태였는지 전체적으로 보는 것입니다.

특히 평소보다 Swap 사용량이 크게 증가했고 메모리 압박도 같이 발생했다면 추가 확인이 필요합니다.

Swap 확인에 대한 내용은 아래 글과 같이 보면 이해하기 쉽습니다.

https://opsnote.tistory.com/43

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

리눅스 서버를 확인하다 보면 free -m 결과에서 Swap 사용량이 높게 보일 때가 있습니다.초보 운영자 입장에서는 이 숫자를 보면 바로 불안해집니다.free -m예를 들어 이런 식입니다. total used free share

opsnote.tistory.com

6. 현재 메모리를 많이 사용하는 프로세스를 확인한다

OOM 로그와 현재 메모리 상태를 확인했다면 어떤 프로세스가 메모리를 많이 사용하고 있는지도 확인합니다.

먼저 top을 사용할 수 있습니다.

top

top 실행 후 메모리 사용량 기준으로 확인하거나, 명령으로 바로 정렬해서 볼 수도 있습니다.

ps -eo pid,ppid,user,%mem,%cpu,rss,cmd --sort=-rss | head -20

여기서는 특히 다음 항목을 봅니다.

PID
%MEM
RSS
CMD

RSS가 큰 프로세스가 무엇인지 확인하고 해당 프로세스가 장애가 발생한 서비스와 관련 있는지 봅니다.

하지만 여기서도 바로 프로세스를 종료하면 안 됩니다.

예를 들어 메모리를 많이 사용하는 프로세스를 발견했다고 해서 곧바로 다음과 같이 처리하는 것은 위험합니다.

kill -9 PID

메모리를 많이 사용한다는 사실과 비정상 프로세스라는 판단은 다른 문제입니다.

먼저 어떤 서비스의 프로세스인지, 정상적인 사용량인지, 종료했을 때 서비스 영향이 무엇인지 확인해야 합니다.

7. 서비스 상태와 로그를 다시 확인한다

커널과 메모리 쪽을 확인했다면 서비스 자체의 기록도 확인합니다.

systemctl status myapp

그리고 서비스 로그를 확인합니다.

journalctl -u myapp

최근 로그만 보고 싶다면 다음처럼 볼 수도 있습니다.

journalctl -u myapp -n 100 --no-pager

여기서는 단순히 에러 문자열 하나를 찾기보다 OOM이 발생한 시각 전후에 서비스에서 어떤 일이 있었는지 확인하는 것이 중요합니다.

예를 들어 다음과 같은 흐름을 맞춰볼 수 있습니다.

14:03 메모리 사용량 증가
14:05 커널 OOM 발생
14:05 java 프로세스 종료
14:05 myapp 서비스 중단

이런 식으로 시간 순서가 연결되면 장애 상황을 설명하기 훨씬 쉬워집니다.

8. 여기까지 확인한 결과를 조합한다

실제 장애 분석에서는 명령어 하나의 결과보다 여러 결과를 조합해서 판단하는 경우가 많았습니다.

예를 들어 다음과 같은 상황입니다.

systemctl
→ 서비스가 비정상 종료된 상태

커널 로그
→ 장애 시각에 OOM 기록 존재

Killed process
→ 서비스와 관련된 java 프로세스 확인

free -m
→ 현재 available 메모리는 회복된 상태

서비스 로그
→ 커널의 프로세스 종료 시점과 서비스 종료 시점이 유사

이 정도까지 확인했다면 단순히 "서비스가 죽었다"보다 훨씬 구체적으로 상황을 정리할 수 있습니다.

반대로 커널 로그에 OOM 흔적이 없다면 OOM으로 단정하지 않고 애플리케이션 오류, 수동 종료, systemd 동작 등 다른 가능성을 확인해야 합니다.

9. 조치하기 전에 영향도를 먼저 확인한다

OOM이 의심된다고 해서 바로 재부팅하거나 프로세스를 강제 종료하는 것은 피하는 편이 좋습니다.

조치 전에 최소한 다음 내용을 생각합니다.

서비스를 재시작하면 사용자 영향이 있는가?
이중화된 서비스인가?
재시작하면 원인 분석에 필요한 정보가 사라지는가?
메모리를 많이 사용하는 프로세스가 정상 업무 프로세스인가?
프로세스를 종료했을 때 자동으로 다시 올라오는가?
원복이 가능한 조치인가?

특히 운영 서버에서는 다음과 같은 명령을 실행하기 전에 영향도를 확인해야 합니다.

systemctl restart myapp
kill PID
kill -9 PID
reboot

서비스 복구가 최우선인 상황이라면 담당자와 영향도를 확인한 뒤 재시작이 필요할 수 있습니다.

중요한 것은 명령어를 실행할 수 있느냐가 아니라 지금 실행해도 되는 상황인지 판단하는 것이라고 생각합니다.

10. 조치 후에는 반드시 재확인한다

서비스를 재시작하기로 결정했다고 가정해보겠습니다.

systemctl restart myapp

명령어가 에러 없이 끝났다고 작업이 끝난 것은 아닙니다.

서비스 상태를 다시 확인합니다.

systemctl status myapp

프로세스가 필요한 포트에서 정상적으로 대기하고 있는지도 확인할 수 있습니다.

ss -lntp

HTTP 서비스라면 실제 응답도 확인합니다.

curl -I https://example.com

그리고 메모리가 다시 빠르게 증가하지 않는지도 확인합니다.

free -m

ps -eo pid,ppid,user,%mem,%cpu,rss,cmd --sort=-rss | head -20

즉 조치 후에는 최소한 다음 흐름까지 확인하는 것이 좋습니다.

서비스 정상 기동
→ 포트 정상
→ 실제 요청 정상
→ 메모리 상태 확인
→ 동일 증상 재발 여부 확인

재시작 후 확인해야 할 항목은 아래 글에서도 정리했습니다.

https://opsnote.tistory.com/29

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

리눅스 서버에서 서비스 장애가 발생했을 때 systemctl restart를 실행하는 경우가 많습니다.systemctl restart nginx 그런데 실제 운영에서는 재시작 명령어가 실행됐다고 해서 서비스가 정상 기동한 것은

opsnote.tistory.com

11. OOM 로그가 있다고 서비스 장애 원인으로 바로 확정할 수 있을까?

OOM 로그를 확인했다고 해서 해당 서비스가 메모리 부족으로 종료됐다고 바로 결론 내리기는 어렵습니다.

예를 들어 커널 로그에 다음과 같은 기록이 있다고 가정해 보겠습니다.

Out of memory: Killed process 12345 (java)

여기서 확인된 사실은 커널이 메모리 부족 상황에서 PID 12345인 Java 프로세스를 종료했다는 것입니다.

하지만 서버에 Java 애플리케이션이 여러 개 실행되고 있었다면 어느 서비스가 종료된 것인지 로그 한 줄만으로는 알기 어렵습니다.

그래서 저는 다음 세 가지를 함께 확인하는 편입니다.

OOM 발생 시각과 실제 서비스 중단 시각이 일치하는지
종료된 PID가 장애가 발생한 서비스의 프로세스인지
서비스 로그에도 같은 시각에 종료 또는 비정상 종료 기록이 남아 있는지

서비스 종료 상태도 함께 확인

systemd로 관리하는 서비스라면 다음 명령으로 종료 결과를 확인할 수 있습니다.

systemctl show myapp -p Result -p ExecMainCode -p ExecMainStatus

여기서 myapp은 실제 서비스명으로 변경해야 합니다.

예를 들어 ExecMainStatus=9가 표시되었다면 SIGKILL 신호로 종료됐을 가능성을 확인할 수 있습니다.

다만 이것만으로 OOM이 원인이라고 확정할 수는 없습니다. 관리자가 강제로 종료했거나 다른 이유로 SIGKILL이 발생했을 수도 있기 때문입니다.

OOM 로그가 없다면?

커널 로그에 OOM 기록이 없다고 해서 메모리 문제를 바로 제외하지는 않습니다.

로그가 이미 사라졌거나, 별도의 메모리 제한이 적용된 환경일 수도 있습니다.

Kubernetes에서 실행되는 서비스라면 다음 명령으로 컨테이너 종료 사유를 확인할 수 있습니다.

kubectl describe pod myapp-pod -n default

실제 운영에서는 myapp-pod와 default를 대상 Pod 및 네임스페이스로 변경합니다.

이때 종료 사유에 OOMKilled가 표시된다면 컨테이너가 메모리 부족으로 종료됐다는 중요한 근거가 됩니다.

다만 컨테이너가 OOM으로 종료됐다는 사실이 서버 전체 메모리가 부족했다는 의미는 아닙니다.

컨테이너에 설정된 메모리 제한을 초과했는지도 함께 확인해야 합니다.

확인한 결과를 어떻게 정리할까?

예를 들어 다음과 같이 구분할 수 있습니다.

확인된 사실

14:05경 커널 OOM 로그 발생
Java 프로세스가 종료된 기록 확인
같은 시각 서비스 응답 실패 발생

추가 확인이 필요한 부분

종료된 Java 프로세스가 실제 장애 서비스의 프로세스인지
메모리 사용량이 증가한 원인
동일한 문제가 반복될 가능성

이렇게 정리하면 확인되지 않은 내용을 원인으로 단정하지 않으면서도 현재까지 파악한 장애 상황을 설명할 수 있습니다.

결국 OOM 장애에서 중요한 것은 로그에 Out of memory가 있는지만 확인하는 것이 아닙니다.

OOM 발생 시각, 종료된 프로세스, 서비스 중단 시점을 연결해 실제 장애 원인인지 판단하는 과정이 중요합니다.

12. 장애 보고는 확인한 사실 중심으로 작성한다

OOM 장애를 확인한 뒤 보고할 때도 처음부터 원인을 확정해서 쓰기보다는 확인한 사실을 중심으로 정리하는 편이 안전합니다.

예를 들어 다음처럼 작성할 수 있습니다.

서비스 비정상 종료 확인 후 장애 발생 시각의 커널 로그를 점검했습니다.

동일 시간대에 OOM 발생 및 서비스 관련 프로세스 종료 기록을 확인했으며,
현재 메모리와 Swap 사용 상태 및 서비스 로그를 추가 확인했습니다.

영향도 확인 후 서비스를 재기동했으며,
현재 서비스 상태와 포트 및 요청 응답은 정상입니다.

메모리 사용량을 추가 모니터링하며 동일 증상 재발 여부를 확인할 예정입니다.

아직 OOM과 서비스 장애의 관계가 명확하지 않다면 표현도 달라져야 합니다.

서비스 비정상 종료 시점에 메모리 부족 관련 로그가 확인되어
OOM 연관 가능성을 확인 중입니다.

현재 서비스 상태와 메모리 사용량은 정상이며,
장애 시점의 서비스 로그와 메모리 사용 추이를 추가 확인하고 있습니다.

운영 보고에서는 확인된 사실과 추정하고 있는 원인을 구분해서 쓰는 것이 중요합니다.

서버 장애 상황을 전체적으로 어떤 순서로 확인할지는 아래 글에 정리했습니다.

https://opsnote.tistory.com/69

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

리눅스 서버를 운영하다 보면 어느 날 갑자기 이런 말을 듣게 됩니다.서버가 느립니다.접속이 안 됩니다.서비스가 안 뜹니다.디스크가 가득 찼습니다.로그가 계속 쌓입니다.재기동하면 될까요?

opsnote.tistory.com

마무리

서비스가 갑자기 죽으면 가장 먼저 서비스를 다시 올리고 싶은 마음이 듭니다.

하지만 OOM처럼 장애가 발생한 순간의 흔적이 중요한 경우에는 재시작 전에 로그를 확인하는 것이 원인을 좁히는 데 도움이 됩니다.

제가 기억하려고 하는 순서는 단순합니다.

서비스가 죽었다
→ 바로 restart하지 않는다
→ 커널 로그에서 OOM 흔적을 찾는다
→ 어떤 프로세스가 죽었는지 확인한다
→ 현재 메모리와 Swap을 확인한다
→ 메모리를 많이 사용하는 프로세스를 확인한다
→ 서비스 로그와 시간을 맞춰본다
→ 영향도를 확인하고 조치한다
→ 서비스와 메모리를 다시 확인한다

결국 중요한 것은 restart 명령어를 아는 것보다 왜 서비스가 죽었는지 확인할 수 있는 증거를 먼저 확보하는 것입니다.

운영 서버에서는 특히 restart, kill, reboot 같은 조치부터 시작하기보다 현재 상태와 로그를 먼저 남겨두는 습관이 장애 원인을 찾는 데 도움이 됩니다.

리눅스 서버가 느린데 CPU는 낮을 때 Load Average와 wa로 확인하는 실제 점검 흐름

opsnote — Sat, 26 Sep 2026 23:56:19 +0900

LOAD CHECK CPU 낮은데 서버가 느릴 때 Load Average → wa → 로그 확인

리눅스 서버를 운영하다 보면 이런 말을 들을 때가 있습니다.

서버가 느립니다.
화면이 늦게 뜹니다.
요청 응답이 평소보다 오래 걸립니다.

처음에는 CPU부터 보게 됩니다.

top을 열어봤는데 CPU 사용률이 생각보다 높지 않습니다.
그러면 초보 운영자 입장에서는 이런 생각이 들 수 있습니다.

CPU는 낮은데 왜 서버가 느리지?
서버 문제는 아닌가?
애플리케이션 문제인가?
그냥 일시적인 현상인가?

저도 처음에는 CPU 사용률만 보고 판단하려고 했습니다.
그런데 운영 서버에서는 CPU 사용률이 낮아 보여도 서버가 느릴 수 있습니다.

이럴 때 같이 봐야 하는 것이 Load Average와 wa입니다.

Load Average는 서버에 얼마나 많은 작업이 밀려 있는지 보는 데 도움이 됩니다.
wa는 CPU가 일을 못 해서 노는 것이 아니라, 디스크나 스토리지 응답을 기다리는 상황인지 확인할 때 도움이 됩니다.

이번 글에서는 리눅스 서버가 느린데 CPU 사용률은 낮아 보일 때, Load Average와 wa를 이용해서 원인을 좁혀가는 실제 점검 흐름을 정리해보겠습니다.

핵심은 단순합니다.

CPU가 낮다고 서버가 정상인 것은 아닙니다.

운영 서버에서는 항상 확인 → 판단 → 조치 → 재확인 순서가 먼저입니다.

1. 먼저 “서버가 느리다”를 나눠서 봅니다

“서버가 느리다”는 말은 생각보다 넓습니다.

느리다는 표현 안에는 여러 상황이 섞여 있을 수 있습니다.

웹 화면이 늦게 뜸
API 응답이 늦음
SSH 접속이 느림
명령어 실행이 느림
배치 작업이 오래 걸림
파일 읽기나 쓰기가 느림
특정 시간대에만 느림
특정 서비스만 느림
서버 전체가 느림

이 상황들은 모두 비슷하게 들리지만 확인 방향이 다를 수 있습니다.

그래서 처음에는 이렇게 나눠야 합니다.

서버가 느리다.
그러면 CPU 문제인지, 메모리 문제인지, 디스크 I/O 문제인지, 서비스 문제인지 나눠서 본다.

여기서 바로 재기동부터 하면 안 됩니다.

서버가 느린 원인은 CPU 사용률 하나로 결정되지 않습니다.
Load Average, wa, 메모리, Swap, 디스크 사용률, 로그, 프로세스 상태를 함께 봐야 합니다.

2. uptime으로 Load Average를 먼저 봅니다

서버가 느릴 때 가볍게 먼저 볼 수 있는 명령어는 uptime입니다.

uptime

결과에는 현재 시간, 서버 부팅 후 경과 시간, 로그인 사용자 수, Load Average가 나옵니다.

예를 들어 이런 식입니다.

load average: 4.20, 5.10, 4.80

Load Average는 보통 1분, 5분, 15분 평균으로 표시됩니다.

여기서 중요한 것은 숫자 하나만 보고 바로 장애라고 판단하지 않는 것입니다.

Load Average는 CPU 코어 수와 함께 봐야 합니다.

예를 들어 CPU가 1코어인 서버에서 Load Average가 4라면 꽤 높은 상태일 수 있습니다.
하지만 CPU가 8코어인 서버에서 Load Average가 4라면 상대적으로 여유가 있을 수도 있습니다.

CPU 코어 수는 아래처럼 확인할 수 있습니다.

nproc

또는 이렇게 볼 수도 있습니다.

lscpu

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

Load Average는 숫자만 보지 말고 CPU 코어 수와 함께 봐야 합니다.

Load Average를 보는 기본 방법은 아래 글에서 정리했습니다.

https://opsnote.tistory.com/41

리눅스 서버 CPU 낮다고 정상이라 하지 말고 Load Average까지 확인하는 법

리눅스 서버가 느려졌을 때 가장 먼저 보는 것 중 하나가 CPU 사용률입니다.top 그런데 막상 top을 열어보면 CPU 사용률은 생각보다 낮은데, 서버는 계속 느린 경우가 있습니다.처음에는 이 상황이

opsnote.tistory.com

3. CPU 사용률이 낮아도 Load Average가 높을 수 있습니다

처음에는 이 부분이 가장 헷갈립니다.

CPU 사용률이 낮아 보이는데 Load Average가 높을 수 있습니다.

그 이유는 Load Average가 단순히 CPU 사용률만 의미하지 않기 때문입니다.

리눅스에서 Load Average는 실행 중이거나 실행을 기다리는 작업, 그리고 일부 대기 상태의 작업까지 영향을 받을 수 있습니다.

즉, CPU가 바빠서 높은 경우도 있지만, 디스크나 스토리지 응답을 기다리는 작업이 많아도 높게 보일 수 있습니다.

예를 들어 이런 상황입니다.

CPU 사용률은 낮음
Load Average는 높음
서버는 느림
명령어 실행도 늦음

이 경우에는 CPU만 보고 “정상”이라고 판단하면 안 됩니다.

이제 다음으로 봐야 할 것은 top의 wa 값입니다.

4. top에서 wa 값을 확인합니다

서버가 느릴 때는 top을 자주 봅니다.

top

top 화면 상단에는 CPU 사용률이 항목별로 표시됩니다.

그중에서 wa를 봐야 합니다.

wa는 I/O wait을 의미합니다.
쉽게 말하면 CPU가 디스크나 스토리지 응답을 기다리는 시간입니다.

예를 들어 이런 식으로 보일 수 있습니다.

%Cpu(s):  3.0 us,  1.0 sy,  0.0 ni, 70.0 id, 25.0 wa

여기서 id는 idle, 즉 CPU가 쉬는 비율입니다.
wa는 I/O wait입니다.

CPU 사용률이 낮아 보이는데 wa가 높다면, CPU가 일을 못 해서 노는 것이 아니라 디스크나 스토리지 응답을 기다리고 있을 수 있습니다.

이때는 이렇게 생각해야 합니다.

CPU가 낮다.
그런데 wa가 높다.
그러면 디스크 I/O나 스토리지 지연을 의심한다.

top에서 wa 값을 보는 방법은 아래 글에서 이어서 볼 수 있습니다.

https://opsnote.tistory.com/42

리눅스 서버 CPU 낮다고 정상이라 하지 말고 top wa 값까지 확인하는 법

리눅스 서버가 느려졌을 때 top 명령어를 열어보면 보통 CPU 사용률부터 보게 됩니다.top 그런데 CPU 사용률은 높지 않은데 서버가 계속 느린 경우가 있습니다.처음에는 이렇게 생각하기 쉽습니다.C

opsnote.tistory.com

5. wa가 높다고 바로 디스크 장애로 단정하지 않습니다

여기서도 바로 결론을 내리면 안 됩니다.

wa가 높다고 해서 무조건 디스크 장애라는 뜻은 아닙니다.

아래 상황에서도 wa가 높게 보일 수 있습니다.

대용량 로그 쓰기
백업 작업
압축 또는 해제 작업
DB 디스크 I/O 증가
스토리지 지연
NFS나 NAS 응답 지연
과도한 파일 읽기/쓰기
특정 프로세스의 I/O 집중

그래서 wa가 높다면 먼저 어떤 작업이 디스크를 많이 쓰는지 확인해야 합니다.

가능하면 iostat을 사용해서 디스크 I/O 상태를 봅니다.

iostat -x 1 3

만약 iostat이 없다면 프로세스 상태와 로그, 디스크 사용률부터 확인합니다.

ps -eo pid,stat,cmd | grep ' D '

D 상태는 보통 uninterruptible sleep 상태로, I/O 대기와 관련된 힌트가 될 수 있습니다.

단, 이 결과도 단독으로 판단하면 안 됩니다.
어떤 프로세스가 어떤 파일이나 장치에서 대기 중인지 추가 확인이 필요합니다.

6. 디스크 용량과 inode도 같이 봅니다

서버가 느릴 때 디스크 I/O만 볼 것이 아니라 디스크 사용률도 함께 봐야 합니다.

디스크가 꽉 찼거나, inode가 부족하면 서비스가 느려지거나 파일 생성에 실패할 수 있습니다.

먼저 전체 사용률을 봅니다.

df -h

그리고 inode도 봅니다.

df -i

디스크가 90% 이상 찼다면 로그 증가, 임시 파일 증가, 백업 파일 증가, 업로드 파일 증가를 확인해야 합니다.

용량이 남아 있어도 inode가 부족하면 새 파일을 만들지 못할 수 있습니다.

디스크 용량 문제를 전체 순서로 보고 싶다면 아래 글을 함께 보면 좋습니다.

https://opsnote.tistory.com/70

리눅스 서버 디스크 용량 문제 확인 순서 총정리

리눅스 서버를 운영하다 보면 디스크 용량 문제는 생각보다 자주 만납니다.처음에는 단순해 보입니다.디스크가 찼다.공간이 부족하다.큰 파일을 지우면 된다. 하지만 운영 서버에서는 이렇게

opsnote.tistory.com

디스크 용량 90% 알림을 받았을 때 실제 점검 흐름은 아래 글에서 정리했습니다.

https://opsnote.tistory.com/72

리눅스 서버 디스크 용량 90% 알림을 받았을 때 실제 점검 흐름 정리

리눅스 서버를 운영하다 보면 디스크 용량 알림을 받을 때가 있습니다.처음에는 단순하게 보입니다.디스크가 90%를 넘었다.공간이 부족하다.큰 파일 몇 개만 지우면 되지 않을까?저도 처음에는

opsnote.tistory.com

7. 메모리와 Swap도 함께 확인합니다

서버가 느릴 때 CPU와 디스크만 보면 부족합니다.

메모리 상태도 함께 봐야 합니다.

free -m

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

available, buff/cache, Swap을 같이 봐야 합니다.

메모리가 부족해서 Swap 사용량이 늘어나면 서버 응답이 느려질 수 있습니다.
특히 디스크 I/O가 느린 환경에서 Swap까지 많이 쓰면 체감 성능이 크게 떨어질 수 있습니다.

Swap 사용량도 확인합니다.

free -m

또는 top에서도 Swap 사용량을 볼 수 있습니다.

메모리 확인 방법은 아래 글에서 정리했습니다.

https://opsnote.tistory.com/44

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

opsnote.tistory.com

Swap 사용량이 올라갔을 때 바로 재기동하지 말고 확인하는 순서는 아래 글에서 볼 수 있습니다.

https://opsnote.tistory.com/43

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

opsnote.tistory.com

8. 어떤 프로세스가 영향을 주는지 봅니다

Load Average가 높거나 wa가 높다면 어떤 프로세스가 영향을 주는지 봐야 합니다.

CPU를 많이 쓰는 프로세스는 top에서 바로 보일 수 있습니다.

메모리를 많이 쓰는 프로세스는 아래처럼 볼 수 있습니다.

ps aux --sort=-%mem | head

CPU 사용률 기준으로 보고 싶다면 아래처럼 볼 수 있습니다.

ps aux --sort=-%cpu | head

특정 PID가 의심된다면 그 PID가 어떤 서비스와 연결되어 있는지도 봐야 합니다.

ps -fp PID

ls -l /proc/PID/exe

cat /proc/PID/cmdline

CPU 사용률이 높은 PID를 찾고 서비스 영향도를 확인하는 방법은 아래 글에서 이어서 볼 수 있습니다.

https://opsnote.tistory.com/45

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

리눅스 서버가 갑자기 느려졌을 때 가장 먼저 의심하는 것 중 하나가 CPU 사용률입니다.서버가 버벅이거나, 접속이 느려지거나, 서비스 응답이 늦어질 때 top을 열어보면 특정 프로세스가 CPU를 많

opsnote.tistory.com

특정 PID가 어떤 서비스인지 확인하는 방법은 아래 글에서 정리했습니다.

https://opsnote.tistory.com/46

리눅스 서버 특정 PID가 어떤 서비스인지 확인하는 법

리눅스 서버에서 CPU나 메모리 사용률이 높은 프로세스를 확인하다 보면 특정 PID가 눈에 들어올 때가 있습니다.top또는:ps -eo pid,ppid,user,cmd,%cpu,%mem --sort=-%cpu | head예를 들어 이런 식입니다.PID PPID US

opsnote.tistory.com

9. 로그에서 같은 시간대의 오류를 확인합니다

서버가 느릴 때는 리소스 수치만 보는 것으로 끝내면 안 됩니다.

같은 시간대에 로그가 어떻게 찍혔는지도 봐야 합니다.

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

journalctl -u 서비스명 -n 100 --no-pager

애플리케이션 로그가 있다면 최근 로그를 봅니다.

tail -n 100 /var/log/example-app/app.log

에러만 좁혀서 볼 수도 있습니다.

grep -i -E "error|exception|timeout|fail" /var/log/example-app/app.log

서버가 느려지는 시간대에 timeout, DB connection error, disk error, permission error 같은 로그가 반복된다면 리소스 수치와 함께 봐야 합니다.

로그 확인은 결국 장애 원인을 좁히는 과정입니다.

로그를 안전하게 보는 방법은 아래 글에서 정리했습니다.

https://opsnote.tistory.com/20

리눅스 서버 로그 확인할 때 cat부터 치지 말고 tail과 less로 안전하게 보는 법

리눅스 서버에서 장애가 나거나 서비스가 이상할 때 가장 많이 확인하는 것 중 하나가 로그입니다. 그런데 초보 운영자일 때는 로그 파일을 확인하려고 바로 cat 명령어를 실행하는 경우가 있습

opsnote.tistory.com

실시간 로그 확인이 필요하다면 아래 글도 함께 보면 좋습니다.

https://opsnote.tistory.com/21

리눅스 서버 장애 났을 때 tail -f로 실시간 로그 확인하는 법

리눅스 서버에서 서비스가 이상하거나 장애가 발생했을 때, 로그를 한 번만 보고 끝내기 어려운 경우가 있습니다. 서비스를 재기동했는데 정상적으로 올라오는지, 테스트 요청을 보냈을 때 로

opsnote.tistory.com

10. 조치 전에 영향도를 먼저 정리합니다

서버가 느리다고 해서 바로 재기동하거나 프로세스를 종료하면 안 됩니다.

특히 운영 서버에서는 아래 조치가 모두 영향이 있을 수 있습니다.

서비스 restart
서버 reboot
프로세스 kill
로그 삭제
디스크 정리
DB 재기동
스토리지 마운트 변경
백업 작업 중단

조치 전에는 최소한 아래 내용을 정리하는 것이 좋습니다.

확인된 사실:
Load Average, CPU, wa, 메모리, Swap, 디스크, 로그 상태

추정 원인:
CPU 사용 증가, I/O wait 증가, 메모리 부족, Swap 사용, 로그 폭증, 특정 프로세스 문제

조치 계획:
서비스 재기동, 프로세스 확인, 로그 정리, 백업 작업 조정, 담당자 확인

영향 범위:
접속 사용자, 배치 작업, 데이터 처리, 서비스 중단 가능성

원복 방법:
변경 전 상태, 설정 백업, 조치 전 수치, 서비스 재기동 전 로그

운영 서버에서는 빠른 조치보다 안전한 조치가 중요합니다.

11. 조치 후에는 다시 같은 지표를 확인합니다

조치가 끝났다면 다시 확인해야 합니다.

처음 봤던 지표를 다시 봅니다.

uptime

top

df -h

free -m

journalctl -u 서비스명 -n 100 --no-pager

조치 후에는 아래를 봅니다.

Load Average가 내려가는가?
wa 값이 줄어드는가?
메모리 available이 충분한가?
Swap 사용량이 계속 증가하지 않는가?
디스크 사용률이 안정적인가?
같은 오류 로그가 반복되지 않는가?
사용자가 체감하는 응답이 회복됐는가?

서버 느림 문제는 조치보다 재확인이 더 중요할 때가 많습니다.

12. 보고는 숫자와 해석을 함께 남깁니다

서버가 느렸다는 보고는 단순히 “느렸습니다”라고 쓰면 부족합니다.

숫자와 해석을 함께 남기는 것이 좋습니다.

예시는 이렇게 정리할 수 있습니다.

[현상]
웹 서비스 응답 지연 신고 접수

[확인]
uptime 확인 결과 Load Average 8 이상 확인
top 확인 결과 CPU 사용률은 높지 않았으나 wa 값 25% 이상 확인
df -h 확인 결과 디스크 사용률 특이사항 없음
free -m 확인 결과 available 메모리 부족은 확인되지 않음
journalctl 확인 결과 같은 시간대 timeout 로그 반복 확인

[추정]
CPU 과부하보다는 디스크 I/O 대기 또는 외부 스토리지 응답 지연 가능성 확인

[조치]
해당 시간대 백업 작업 및 로그 증가 여부 확인
서비스 로그 추가 확인 후 담당자 공유

[결과]
조치 후 Load Average와 wa 감소 확인
서비스 응답 지연 완화 확인

[추가 확인]
동일 시간대 반복 여부 모니터링 예정

이렇게 쓰면 단순한 느낌이 아니라, 어떤 근거로 판단했는지가 남습니다.

“서버가 느려서 재기동했습니다”보다 훨씬 낫습니다.

13. 정리하면

리눅스 서버가 느릴 때 CPU 사용률만 보고 판단하면 놓치는 부분이 많습니다.

CPU가 낮아 보여도 서버가 느릴 수 있습니다.

운영 서버에서는 아래 순서로 보는 것이 좋습니다.

uptime으로 Load Average를 확인합니다.
CPU 코어 수와 Load Average를 함께 봅니다.
top에서 CPU 사용률과 wa 값을 확인합니다.
wa가 높다면 디스크 I/O 대기를 의심합니다.
df -h, df -i로 디스크와 inode를 확인합니다.
free -m으로 메모리와 Swap을 확인합니다.
프로세스 상태와 로그를 함께 봅니다.
조치 후 같은 지표를 다시 확인합니다.

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

CPU가 낮다고 서버가 정상인 것은 아닙니다. Load Average와 wa를 함께 확인하세요.

서버 느림 대응도 결국 같습니다.

확인 → 판단 → 조치 → 재확인

서버가 느릴 때 CPU, 메모리, 디스크 상태를 함께 정리하는 방법은 아래 글에서 볼 수 있습니다.

https://opsnote.tistory.com/47

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

리눅스 서버가 느려졌다는 이야기를 들으면 초보 운영자는 먼저 명령어부터 떠올리게 됩니다.topfree -mdf -huptime그런데 실제 운영에서는 명령어를 실행하는 것만큼 중요한 게 하나 더 있습니다.확

opsnote.tistory.com

Load Average와 wa를 명령어별로 따로 보고 싶다면 아래 글들도 함께 보면 좋습니다.

https://opsnote.tistory.com/41

리눅스 서버 CPU 낮다고 정상이라 하지 말고 Load Average까지 확인하는 법

opsnote.tistory.com

https://opsnote.tistory.com/42

리눅스 서버 CPU 낮다고 정상이라 하지 말고 top wa 값까지 확인하는 법

opsnote.tistory.com

메모리와 Swap 확인은 아래 글들도 이어서 볼 수 있습니다.

https://opsnote.tistory.com/44

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

opsnote.tistory.com

https://opsnote.tistory.com/43

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

opsnote.tistory.com

CPU가 높은 PID와 서비스 영향도 확인은 아래 글에서 정리했습니다.

https://opsnote.tistory.com/45

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

opsnote.tistory.com

https://opsnote.tistory.com/46

리눅스 서버 특정 PID가 어떤 서비스인지 확인하는 법

opsnote.tistory.com

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

https://opsnote.tistory.com/69

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

opsnote.tistory.com

ping은 되는데 사이트가 안 열릴 때 nc와 curl로 확인하는 실제 점검 흐름

opsnote — Fri, 25 Sep 2026 21:37:04 +0900

PING CHECK ping은 되는데 사이트가 안 열릴 때 nc → curl → DNS → 로그 확인

리눅스 서버나 웹 서비스를 운영하다 보면 이런 말을 들을 때가 있습니다.

서버는 살아 있는 것 같은데 사이트가 안 열립니다.
ping은 됩니다.
그런데 브라우저에서는 접속이 안 됩니다.

처음에는 헷갈립니다.

ping이 되면 서버가 살아 있는 것처럼 보입니다.
그래서 초보 운영자 입장에서는 “네트워크는 정상인데 왜 사이트가 안 열리지?”라는 생각이 들 수 있습니다.

저도 처음에는 ping 결과를 보고 꽤 안심했던 적이 있습니다.
하지만 운영 서버에서는 ping이 된다는 것과 웹 서비스가 정상이라는 것은 전혀 다른 이야기입니다.

ping은 주로 ICMP 응답을 확인합니다.
반면 웹사이트 접속은 TCP 포트, 웹서버, 애플리케이션, 인증서, 라우팅, DNS, HTTP 응답까지 함께 봐야 합니다.

이번 글에서는 ping은 되는데 사이트가 안 열릴 때, nc와 curl을 이용해서 어디까지 정상인지 실제 운영 흐름처럼 좁혀보겠습니다.

핵심은 단순합니다.

ping이 된다고 서비스가 되는 것은 아닙니다.

운영 서버에서는 항상 확인 → 판단 → 조치 → 재확인 순서가 먼저입니다.

1. 먼저 “사이트가 안 열린다”를 나눠서 봅니다

“사이트가 안 열린다”는 말은 생각보다 넓습니다.

브라우저에서 보이는 증상도 여러 가지입니다.

페이지가 계속 로딩됨
연결 시간이 초과됨
연결이 거부됨
403, 404, 500 같은 HTTP 오류가 뜸
인증서 경고가 뜸
특정 사용자만 접속이 안 됨
내부에서는 되는데 외부에서는 안 됨
도메인은 안 되는데 IP로는 됨

이 증상들은 비슷해 보이지만 원인이 다를 수 있습니다.

그래서 처음에는 이렇게 나눠야 합니다.

사이트가 안 열린다.
그러면 DNS 문제인지, 포트 문제인지, HTTP 응답 문제인지 나눠서 본다.

여기서 바로 서버 재기동부터 하면 안 됩니다.

웹 접속 장애는 서버 프로세스 문제가 아닐 수도 있습니다.
DNS, 방화벽, 로드밸런서, WAF, 포트, 인증서, 애플리케이션 라우팅 문제일 수도 있습니다.

2. ping은 참고용으로만 봅니다

웹사이트 접속이 안 될 때 ping으로 ICMP 응답을 확인할 수 있습니다.

ping -c 4 example.com

하지만 ping이 성공했다고 해서 웹 서비스가 정상이라는 뜻은 아닙니다.

이번 글에서는 ping 결과를 출발점으로 삼고, 실제 접속 장애가 발생한 구간을 TCP 연결과 HTTP 응답으로 좁혀보겠습니다.

ping의 의미와 한계가 궁금하다면 아래 기초 글을 먼저 참고해 주세요.

34번 — ping 성공과 서비스 정상의 차이

리눅스 서버 ping 된다고 정상이라 하지 말고 포트와 curl까지 확인하는 법

리눅스 서버에 접속이 안 되거나 웹사이트가 열리지 않을 때 가장 먼저 실행하는 명령어 중 하나가 ping입니다.ping -c 4 203.0.113.10응답이 정상적으로 돌아오면 서버가 정상이라고 생각하기 쉽습니

opsnote.tistory.com

3. nc로 포트 연결 여부를 확인합니다

ping이 된다면 다음은 실제 서비스 포트가 열려 있는지 확인해야 합니다.

웹 서비스라면 보통 80 또는 443 포트를 봅니다.

nc -vz example.com 80

nc -vz example.com 443

여기서 중요한 것은 ping이 아니라 TCP 포트 연결 여부입니다.

nc 결과가 성공하면, 클라이언트 입장에서 해당 포트까지 TCP 연결은 가능한 상태로 볼 수 있습니다.

예를 들어 이런 결과가 나올 수 있습니다.

Connection to example.com 443 port [tcp/https] succeeded!

이 경우에는 최소한 443 포트까지는 연결이 되는 것입니다.

반대로 아래처럼 나오면 포트 연결 자체가 안 되는 상황일 수 있습니다.

Connection timed out

또는 이렇게 나올 수도 있습니다.

Connection refused

이 두 결과는 느낌이 다릅니다.

timed out은 중간에서 막히거나 응답이 없는 상황일 수 있습니다.
refused는 대상까지는 갔지만 해당 포트에서 받아주는 서비스가 없을 때 볼 수 있습니다.

정리하면 이렇게 볼 수 있습니다.

ping 성공
nc 실패
→ 서버는 응답하지만 서비스 포트는 안 열렸거나 중간에서 막혔을 수 있음

포트가 열렸는지 nc로 확인하는 방법은 아래 글에서 이어서 볼 수 있습니다.

https://opsnote.tistory.com/36

리눅스 서버 포트 열렸는지 nc로 확인할 때 ping만 보지 말고 TCP 접속까지 확인하는 법

리눅스 서버에서 특정 서비스 접속이 안 되는 상황을 만나면 초보 운영자는 방화벽부터 의심하기 쉽습니다.서버는 살아 있는데 웹 접속이 안 돼요.DB 서버 포트가 막힌 것 같아요.방화벽 문제 아

opsnote.tistory.com

4. nc 성공이 서비스 정상이라는 뜻은 아닙니다

여기서 한 번 더 조심해야 합니다.

nc가 성공했다고 해서 웹 서비스가 정상이라는 뜻은 아닙니다.

nc는 TCP 포트 연결 여부를 보는 데 가깝습니다.
하지만 웹 서비스는 TCP 연결만으로 끝나지 않습니다.

예를 들어 443 포트 연결은 되지만 이런 문제가 있을 수 있습니다.

웹서버는 떠 있지만 애플리케이션 오류가 있음
인증서 문제가 있음
리버스 프록시 뒤쪽 upstream이 죽어 있음
HTTP 500 응답이 발생함
특정 경로만 404가 발생함
로그인 페이지나 API 경로만 실패함

그래서 nc 다음에는 curl로 HTTP 응답을 확인해야 합니다.

흐름은 이렇게 잡습니다.

ping으로 기본 응답 확인
→ nc로 포트 연결 확인
→ curl로 HTTP 응답 확인

5. curl로 HTTP 응답을 확인합니다

웹 서비스 상태를 확인할 때는 curl이 유용합니다.

먼저 헤더만 간단히 확인할 수 있습니다.

curl -I https://example.com

HTTP 상태 코드와 응답 헤더를 볼 수 있습니다.

예를 들어 정상이라면 이런 식의 응답을 기대할 수 있습니다.

HTTP/2 200

또는 리다이렉트가 있는 경우 아래처럼 볼 수 있습니다.

HTTP/1.1 301 Moved Permanently

오류가 있다면 이런 코드가 보일 수 있습니다.

HTTP/1.1 403 Forbidden
HTTP/1.1 404 Not Found
HTTP/1.1 500 Internal Server Error
HTTP/1.1 502 Bad Gateway
HTTP/1.1 504 Gateway Timeout

여기서 중요한 것은 상태 코드입니다.

nc가 성공했는데 curl에서 502가 나온다면, 포트는 열려 있지만 뒤쪽 애플리케이션이나 upstream 문제가 있을 수 있습니다.

curl에서 404가 나온다면, 서버는 응답하지만 경로나 라우팅 문제가 있을 수 있습니다.

curl에서 timeout이 난다면, 포트 연결 이후 응답이 지연되거나 중간 구간 문제가 있을 수 있습니다.

curl과 nc 차이는 아래 글에서 따로 정리했습니다.

https://opsnote.tistory.com/38

리눅스 서버 접속 확인할 때 curl과 nc 차이, 포트와 HTTP 응답을 구분하는 법

리눅스 서버에서 접속 문제가 생기면 curl과 nc 명령어를 자주 사용합니다. curl -I http://example.comnc -vz -w 3 example.com 80 처음 보면 둘 다 “접속 확인 명령어”처럼 보입니다.하지만 실제 운영에서는

opsnote.tistory.com

6. DNS가 의도한 IP를 바라보는지도 확인합니다

도메인으로 접속이 안 될 때는 DNS도 함께 확인해야 합니다.

특히 이런 상황에서는 DNS를 봐야 합니다.

IP로는 접속되는데 도메인으로는 안 됨
일부 사용자만 접속이 안 됨
최근 DNS 변경 작업이 있었음
로드밸런서 IP 변경이 있었음
내부 DNS와 외부 DNS 결과가 다름

가볍게 확인할 때는 nslookup을 사용할 수 있습니다.

nslookup example.com

조금 더 자세히 보고 싶다면 dig를 사용할 수 있습니다.

dig example.com

DNS 확인에서 볼 것은 단순히 응답이 있느냐가 아닙니다.

의도한 IP를 바라보고 있는지 봐야 합니다.

예를 들어 서비스가 원래 203.0.113.10을 바라봐야 하는데, DNS 결과가 다른 IP를 반환한다면 접속 장애 원인이 DNS일 수 있습니다.

도메인 확인은 아래 글들도 함께 보면 좋습니다.

https://opsnote.tistory.com/39

리눅스 서버 도메인 안 된다고 서버부터 보지 말고 nslookup으로 DNS부터 확인하는 법

리눅스 서버에서 어떤 사이트나 API 도메인에 접속이 안 될 때 초보 운영자는 보통 서버 장애나 방화벽 문제부터 떠올리기 쉽습니다.서비스가 죽었나?포트가 막혔나?방화벽 문제인가?서버를 재

opsnote.tistory.com

https://opsnote.tistory.com/40

리눅스 서버 nslookup만 보지 말고 dig로 DNS 응답까지 확인하는 법

리눅스 서버에서 도메인 접속이 안 될 때는 먼저 nslookup으로 DNS가 IP로 풀리는지 확인할 수 있습니다.nslookup api.example.com 그런데 nslookup 결과만으로는 조금 아쉬울 때가 있습니다.예를 들면 이런

opsnote.tistory.com

7. 서버 내부에서도 포트와 서비스 상태를 봅니다

외부에서 nc나 curl로 확인했다면, 서버 내부에서도 상태를 확인해야 합니다.

웹서버가 실제로 포트를 열고 있는지 봅니다.

ss -lntp | grep ':80'

ss -lntp | grep ':443'

서비스 상태도 봅니다.

systemctl status nginx --no-pager

Apache라면 이렇게 볼 수 있습니다.

systemctl status httpd --no-pager

최근 로그도 확인합니다.

journalctl -u nginx -n 100 --no-pager

서비스가 떠 있는데 외부에서 접속이 안 된다면 방화벽, 보안그룹, 로드밸런서, WAF 구간을 봐야 할 수 있습니다.

반대로 서버 내부에서도 포트가 안 열려 있다면 웹서버 설정, 서비스 실패, 포트 충돌, 애플리케이션 기동 문제를 먼저 봐야 합니다.

서비스 상태 확인은 아래 글에서 이어서 볼 수 있습니다.

https://opsnote.tistory.com/27

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

리눅스 서버를 운영하다 보면 “서비스가 안 떠요”, “접속이 안 됩니다”, “프로세스가 죽은 것 같습니다” 같은 상황을 만날 수 있습니다.이럴 때 초보 운영자 입장에서 가장 먼저 떠오르는

opsnote.tistory.com

서비스 로그 확인은 아래 글에서 정리했습니다.

https://opsnote.tistory.com/33

리눅스 서버 systemctl status만 보지 말고 journalctl로 서비스 로그 확인하는 법

리눅스 서버에서 서비스가 안 뜨거나, 재기동은 됐는데 정상 동작이 아닌 것 같을 때 초보 운영자가 자주 하는 실수가 있습니다.바로 로그 파일 경로부터 먼저 헤매는 것입니다./var/log에 로그가

opsnote.tistory.com

8. traceroute는 경로 참고용으로 봅니다

접속이 안 될 때 경로를 보고 싶다면 traceroute를 사용할 수 있습니다.

traceroute example.com

하지만 traceroute 결과에 별표가 보인다고 바로 장애로 단정하면 안 됩니다.

중간 장비가 ICMP 응답을 제한할 수도 있고, 경로상 장비가 응답하지 않도록 설정되어 있을 수도 있습니다.

그래서 traceroute는 참고 자료로 보는 것이 좋습니다.

경로 확인은 도움이 되지만, 실제 서비스 판단은 nc, curl, DNS, 서비스 상태, 로그를 함께 봐야 합니다.

traceroute를 볼 때 주의할 점은 아래 글에서 정리했습니다.

https://opsnote.tistory.com/37

리눅스 서버 접속 안 될 때 traceroute로 어느 구간에서 막히는지 확인하는 법

리눅스 서버에 접속이 안 되는 문제가 생기면 초보 운영자는 방화벽부터 의심하기 쉽습니다.서버 접속이 안 됩니다.API 호출이 안 됩니다.방화벽 문제 아닌가요?보안그룹 열어야 하는 거 아닌가

opsnote.tistory.com

9. 결과를 조합해서 원인을 좁힙니다

이제 결과를 조합해야 합니다.

각 명령어는 보는 영역이 다릅니다.

ping
→ ICMP 응답 확인

nc
→ TCP 포트 연결 확인

curl
→ HTTP 응답 확인

nslookup, dig
→ DNS 응답 확인

ss
→ 서버 내부 포트 listen 확인

systemctl, journalctl
→ 서비스 상태와 로그 확인

예를 들어 이런 식으로 판단할 수 있습니다.

ping 성공, nc 실패
→ 서버는 응답하지만 포트 연결이 안 되는 상태일 수 있음

nc 성공, curl 502
→ 포트는 열렸지만 뒤쪽 애플리케이션이나 upstream 문제일 수 있음

DNS 결과가 다른 IP
→ 도메인이 의도한 서버를 바라보지 않을 수 있음

서버 내부 ss에서 포트 없음
→ 웹서버가 포트를 열지 않았을 수 있음

systemctl failed
→ 서비스 기동 실패 원인부터 확인해야 함

이렇게 조합해서 봐야 합니다.

명령어 하나만 보고 결론을 내리면 위험합니다.

실전 점검 예시: ping 성공, 외부 443 포트 연결 실패

다음은 장애 분석 방법을 설명하기 위한 가상 점검 사례입니다. 실제 운영 장애 기록은 아닙니다.

상황

사용자가 https://example.com에 접속할 수 없다고 신고했습니다.

대상 IP의 ping 응답은 정상
브라우저에서는 연결 시간 초과
외부 클라이언트에서 TCP 443 연결 실패

1단계. 외부 클라이언트에서 확인

ping -c 4 203.0.113.10
nc -vz -w 3 example.com 443

예시 결과:

ping: 4 received, 0% packet loss
nc: Connection timed out

이 결과로 확인한 사실은 ICMP 응답은 수신됐지만 TCP 연결은 완료되지 않았다는 것입니다.

아직 방화벽 문제인지, LB 문제인지, 서버 문제인지는 확정할 수 없습니다.

2단계. 서버 내부 포트 확인

서버 접근 권한이 있다면 다음 명령어를 실행합니다.

sudo ss -lntp '( sport = :443 )'

예시 결과:

LISTEN 0 511 0.0.0.0:443 0.0.0.0:* users:(("nginx",pid=1234,fd=7))

서버 내부에서는 nginx가 443 포트를 LISTEN하고 있습니다.

하지만 이것만으로 외부 접속이 정상이라는 의미는 아닙니다.

3단계. 결과를 구간별로 분리

점검 항목결과판단

ICMP 응답	성공	ICMP 응답 확인
외부 TCP 443	타임아웃	외부 연결 실패
서버 내부 LISTEN	확인	서버 포트 대기 확인
HTTP 응답	미확인	추가 점검 필요

이제 DNS, LB, 방화벽, 보안그룹, 라우팅 경로를 확인해야 합니다.

특히 도메인이 실제 서비스 VIP를 바라보는지, 외부 클라이언트의 출발지 IP가 허용되어 있는지 구분해서 확인합니다.

4단계. 조치 여부 판단

현재까지 확인된 결과만으로 nginx를 재기동할 근거는 부족합니다.

먼저 외부 연결이 실패하는 구간을 확인하고, 정책이나 설정 변경이 필요하다면 담당자 승인과 원복 계획을 준비해야 합니다.

5단계. 조치 후 재확인

원인을 확인하고 승인된 조치를 완료했다면 동일한 클라이언트에서 다시 확인합니다.

nc -vz -w 3 example.com 443
curl -I --connect-timeout 3 --max-time 10 https://example.com

TCP 연결 성공 여부와 HTTP 응답을 각각 확인합니다.

HTTP 200 응답이 나오더라도 실제 로그인이나 주요 API 기능까지 정상인지 별도 검증이 필요합니다.

핵심은 ping 성공 여부가 아니라, 어느 구간까지 확인됐고 어디서 실패했는지를 증거로 구분하는 것입니다.

10. 조치 전에 영향도를 확인합니다

원인을 어느 정도 좁혔다면 조치를 고민해야 합니다.

하지만 운영 서버에서는 조치 전에 영향도를 먼저 봐야 합니다.

예를 들어 아래 작업은 모두 영향이 있을 수 있습니다.

웹서버 restart
설정 파일 수정
방화벽 정책 변경
로드밸런서 대상 변경
DNS 레코드 변경
WAF 정책 수정
애플리케이션 재기동

조치 전에는 최소한 아래를 정리하는 것이 좋습니다.

확인된 사실:
ping, nc, curl, DNS, 서비스 상태 결과

추정 원인:
포트 차단, DNS 오류, 웹서버 오류, upstream 장애, 설정 문제

조치 계획:
서비스 재기동, 설정 수정, 방화벽 확인, DNS 확인, 담당자 협의

영향 범위:
접속 중인 사용자, 외부 서비스 영향, 장애 지속 시간

원복 방법:
변경 전 설정, 기존 DNS 값, 기존 방화벽 정책, 서비스 상태

운영 서버에서는 빠른 조치보다 안전한 조치가 중요합니다.

11. 조치 후에는 다시 확인합니다

조치가 끝났다면 반드시 다시 확인해야 합니다.

다시 확인할 명령어는 처음 확인했던 것과 비슷합니다.

ping -c 4 example.com

nc -vz example.com 443

curl -I https://example.com

nslookup example.com

서버 내부에서는 서비스 상태와 로그도 다시 봅니다.

systemctl status nginx --no-pager

journalctl -u nginx -n 100 --no-pager

조치 후 확인할 것은 아래와 같습니다.

DNS가 의도한 IP를 바라보는가?
포트 연결이 되는가?
HTTP 응답 코드가 정상인가?
서비스가 active 상태인가?
최근 로그에 같은 오류가 반복되지 않는가?
외부와 내부에서 결과가 같은가?

접속 장애는 조치보다 재확인이 더 중요할 때가 많습니다.

12. 보고는 구간별로 정리합니다

아래는 앞서 설명한 외부 TCP 연결 실패 사례와는 별개의 가상 장애 보고 예시입니다. 이번에는 웹서버 설정 오류로 서비스가 기동되지 않은 상황을 가정했습니다.

[현상]
도메인 접속 불가 신고 접수

[확인]
ping 응답 정상
nc 확인 결과 443 포트 연결 실패
nslookup 결과 도메인은 정상 IP 반환
서버 내부 ss 확인 결과 443 포트 listen 없음
systemctl status 확인 결과 nginx failed 상태 확인
journalctl 확인 결과 설정 파일 오류 메시지 확인

[조치]
설정 파일 오류 수정 후 nginx 재기동
서비스 active 상태 확인
443 포트 listen 확인
curl -I 결과 HTTP 200 응답 확인

[결과]
도메인 접속 정상 확인
동일 오류 로그 재발 없음

[추가 확인]
설정 변경 이력 및 재발 방지 체크 예정

이렇게 쓰면 “접속 안 됨”이라는 넓은 문제를 어디까지 확인했는지 쉽게 보여줄 수 있습니다.

13. 정리하면

ping이 된다고 웹 서비스가 정상인 것은 아닙니다.

운영 서버에서는 접속 장애를 아래 순서로 나눠서 보는 것이 좋습니다.

ping으로 기본 응답을 확인합니다.
nc로 TCP 포트 연결 여부를 확인합니다.
curl로 HTTP 응답 코드를 확인합니다.
nslookup 또는 dig로 DNS 응답을 확인합니다.
서버 내부에서 ss로 포트 listen 상태를 확인합니다.
systemctl status로 서비스 상태를 확인합니다.
journalctl로 최근 로그를 확인합니다.
조치 후 같은 순서로 다시 확인합니다.

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

ping은 참고용이고, 실제 서비스 확인은 nc와 curl까지 봐야 합니다.

접속 장애 대응도 결국 같습니다.

확인 → 판단 → 조치 → 재확인

접속 장애를 전체 순서로 보고 싶다면 아래 글을 함께 보면 좋습니다.

https://opsnote.tistory.com/71

리눅스 서버 접속 장애 확인 순서 총정리

리눅스 서버를 운영하다 보면 가장 자주 듣는 말 중 하나가 있습니다.접속이 안 됩니다.사이트가 안 열립니다.서버가 죽은 것 같습니다.도메인이 안 됩니다.포트가 막힌 것 같습니다. 처음 들으

opsnote.tistory.com

리눅스 서버 서비스가 안 뜰 때 systemctl status와 journalctl로 원인 좁히는 과정

opsnote — Thu, 24 Sep 2026 23:48:28 +0900

서비스가 안 뜰 때 바로 재기동하지 않고, systemctl status와 journalctl로 원인을 먼저 확인하는 리눅스 서버 장애 대응 흐름

리눅스 서버를 운영하다 보면 서비스가 안 뜨는 상황을 만날 때가 있습니다.

처음에는 단순하게 보입니다.

서비스가 안 뜬다.
프로세스가 죽은 것 같다.
restart 하면 되지 않을까?

저도 처음에는 이렇게 생각했습니다.
그런데 운영 서버에서는 서비스가 안 뜬다고 바로 restart부터 하는 것이 항상 좋은 선택은 아닙니다.

서비스가 실패한 이유를 확인하지 않고 재기동하면, 잠깐 살아나는 것처럼 보여도 같은 문제가 다시 반복될 수 있습니다.
또는 실패 원인이 로그에 남아 있었는데 재기동 과정에서 중요한 단서를 놓칠 수도 있습니다.

이번 글에서는 리눅스 서버에서 서비스가 안 뜰 때, systemctl status와 journalctl을 이용해서 원인을 좁혀가는 실제 점검 흐름을 정리해보겠습니다.

핵심은 단순합니다.

서비스가 안 뜰 때는 바로 restart 하지 말고, 먼저 상태와 로그를 확인해야 합니다.

운영 서버에서는 항상 확인 → 판단 → 조치 → 재확인 순서가 먼저입니다.

1. 먼저 “서비스가 안 뜬다”는 말을 나눠서 봅니다

운영 중에 “서비스가 안 떠요”라는 말을 들으면, 바로 명령어부터 치기 전에 상황을 나눠서 봐야 합니다.

서비스가 안 뜬다는 말 안에는 여러 경우가 섞여 있을 수 있습니다.

프로세스가 아예 없음
systemd 서비스가 failed 상태임
프로세스는 있는데 포트가 안 열림
포트는 열렸는데 응답이 없음
재기동 직후 바로 죽음
서버 재부팅 후 자동으로 안 올라옴

이 상황들은 모두 비슷해 보이지만 확인 순서가 조금씩 다릅니다.

그래서 먼저 이렇게 생각합니다.

서비스가 안 뜬다.
그러면 먼저 현재 서비스 상태부터 확인한다.

이때 가장 먼저 볼 명령어가 systemctl status입니다.

2. systemctl status로 현재 상태를 확인합니다

서비스가 안 뜰 때 가장 먼저 확인할 명령어는 보통 아래와 같습니다.

systemctl status 서비스명 --no-pager

예를 들어 nginx라면 이렇게 볼 수 있습니다.

systemctl status nginx --no-pager

여기서 중요한 것은 단순히 active인지 failed인지만 보는 것이 아닙니다.

아래 항목을 같이 봐야 합니다.

Loaded 상태
Active 상태
Main PID 존재 여부
최근 종료 코드
최근 로그 일부
서비스가 언제부터 실패했는지
어떤 설정 파일을 바라보는지

예를 들어 Active: failed가 보이면 서비스가 시작에 실패한 것입니다.
Active: inactive라면 현재 실행 중이 아닌 상태일 수 있습니다.
Active: activating 상태가 오래 지속된다면 시작 중 멈춰 있는 상황일 수도 있습니다.

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

서비스가 안 뜰 때는 restart보다 status가 먼저입니다.

systemctl status로 서비스 상태를 먼저 확인하는 방법은 아래 글에서 정리했습니다.

https://opsnote.tistory.com/27

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

opsnote.tistory.com

3. status 결과만 보고 단정하지 않습니다

systemctl status를 보면 어느 정도 힌트가 나옵니다.

하지만 status 결과만으로 원인을 모두 알 수는 없습니다.

예를 들어 이런 식입니다.

Active: failed
Main PID: exited
code=exited
status=1/FAILURE

이 결과만 보고는 정확한 원인을 알기 어렵습니다.

설정 파일 오류인지, 포트 충돌인지, 권한 문제인지, 디렉터리가 없는지, 환경 변수가 빠졌는지까지는 추가 로그를 봐야 알 수 있습니다.

그래서 status는 시작점이고, 다음은 로그 확인입니다.

흐름은 이렇게 잡습니다.

systemctl status로 현재 상태 확인
→ failed 또는 exited 확인
→ journalctl로 자세한 로그 확인

4. journalctl로 실패 원인을 확인합니다

systemd 서비스의 최근 로그를 확인할 때는 journalctl을 사용합니다.

기본 형태는 아래와 같습니다.

journalctl -u 서비스명 -n 100 --no-pager

nginx라면 이렇게 확인할 수 있습니다.

journalctl -u nginx -n 100 --no-pager

여기서 -u는 특정 서비스 로그를 보는 옵션이고, -n 100은 최근 100줄을 보겠다는 뜻입니다.

서비스가 안 뜨는 상황에서는 최근 로그가 중요합니다.

특히 아래 메시지를 찾습니다.

permission denied
address already in use
no such file or directory
failed to start
configuration error
cannot bind
timeout
dependency failed

예를 들어 address already in use가 보이면 포트 충돌을 의심할 수 있습니다.
permission denied가 보이면 권한 문제를 의심할 수 있습니다.
no such file or directory가 보이면 경로나 파일 누락을 확인해야 합니다.

서비스 실패 원인을 journalctl로 확인하는 방법은 아래 글에서 이어서 볼 수 있습니다.

https://opsnote.tistory.com/33

리눅스 서버 systemctl status만 보지 말고 journalctl로 서비스 로그 확인하는 법

opsnote.tistory.com

5. 실패한 서비스가 여러 개인지도 확인합니다

서비스 하나만 실패한 것처럼 보여도, 실제로는 여러 서비스가 함께 실패했을 수 있습니다.

이럴 때는 systemctl --failed를 사용합니다.

systemctl --failed

이 명령어는 현재 실패 상태인 systemd unit을 한 번에 보여줍니다.

운영 서버에서는 서비스 하나만 보고 판단하면 놓치는 경우가 있습니다.

예를 들어 애플리케이션 서비스가 failed 상태인데, 실제 원인은 그 앞단의 데이터베이스, 마운트, 네트워크 관련 서비스일 수도 있습니다.

그래서 서비스가 이상할 때는 이렇게 봅니다.

문제가 된 서비스 하나만 보지 않는다.
실패한 서비스 목록도 함께 확인한다.

실패한 서비스 목록을 확인하는 방법은 아래 글에서 정리했습니다.

https://opsnote.tistory.com/32

리눅스 서버에서 실패한 서비스 한 번에 확인하는 systemctl --failed 사용법

리눅스 서버에서 서비스가 안 뜨거나, 서버 재기동 후 뭔가 이상할 때 보통 특정 서비스 하나를 찍어서 systemctl status로 확인합니다.systemctl status nginx 그런데 실제 운영 상황에서는 어떤 서비스가

opsnote.tistory.com

6. 포트가 열렸는지도 같이 봅니다

서비스가 active로 보인다고 해서 실제로 접속 가능한 상태라고 단정하면 안 됩니다.

프로세스는 떠 있는데 포트가 열리지 않았을 수도 있습니다.
또는 포트는 열렸지만 다른 프로세스가 잡고 있을 수도 있습니다.

포트 확인은 이렇게 할 수 있습니다.

ss -lntp

특정 포트만 보고 싶다면 이렇게 확인합니다.

ss -lntp | grep ':80'

웹 서비스라면 HTTP 응답도 같이 확인합니다.

curl -I http://localhost

이렇게 보면 상태를 나눌 수 있습니다.

systemctl status는 active
→ 포트도 열림
→ HTTP 응답 확인

systemctl status는 active
→ 포트가 안 열림
→ 설정 또는 서비스 내부 문제 의심

systemctl status는 failed
→ journalctl로 실패 원인 확인

서비스 확인은 하나의 명령어로 끝내기보다, 상태와 포트와 로그를 함께 보는 것이 좋습니다.

7. 바로 restart 하지 않는 이유

서비스가 안 뜰 때 가장 쉽게 떠오르는 명령어는 restart입니다.

systemctl restart 서비스명

하지만 운영 서버에서는 이 명령어를 먼저 치기보다, 먼저 확인해야 합니다.

왜냐하면 restart는 원인 확인이 아니라 조치에 가깝기 때문입니다.

원인을 모른 채 restart를 하면 아래 문제가 생길 수 있습니다.

실패 원인을 놓칠 수 있음
같은 장애가 다시 반복될 수 있음
로그 단서가 뒤섞일 수 있음
순간적으로 서비스 영향이 생길 수 있음
의존 서비스 문제를 감출 수 있음

그래서 restart는 이렇게 생각하는 것이 좋습니다.

restart는 첫 번째 확인 명령어가 아니라,
상태와 로그를 본 뒤 선택하는 조치입니다.

start, stop, restart 차이는 아래 글에서 정리했습니다.

https://opsnote.tistory.com/28

리눅스 서버 systemctl start stop restart 차이와 restart 바로 누르면 안 되는 이유

리눅스 서버에서 서비스를 다루다 보면 systemctl start, systemctl stop, systemctl restart 명령어를 자주 보게 됩니다.초보 운영자 입장에서는 서비스가 안 되면 일단 restart를 누르고 싶은 마음이 먼저 들

opsnote.tistory.com

8. restart를 했다면 반드시 재확인합니다

상태와 로그를 확인한 뒤 재기동이 필요하다고 판단했다면, 그때 restart를 실행할 수 있습니다.

systemctl restart 서비스명

하지만 여기서 끝내면 안 됩니다.

restart가 성공적으로 끝났다는 것과 서비스가 정상이라는 것은 다릅니다.

재기동 후에는 다시 확인해야 합니다.

systemctl status 서비스명 --no-pager

포트도 봅니다.

ss -lntp | grep ':포트'

최근 로그도 확인합니다.

journalctl -u 서비스명 -n 100 --no-pager

웹 서비스라면 응답도 확인합니다.

curl -I http://localhost

재기동 후 확인할 것은 아래와 같습니다.

서비스가 active 상태인지
Main PID가 정상적으로 존재하는지
포트가 열렸는지
HTTP 응답이 정상인지
최근 로그에 에러가 새로 찍히지 않는지
일정 시간이 지나도 다시 죽지 않는지

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

https://opsnote.tistory.com/29

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

opsnote.tistory.com

9. 서버 재부팅 후 자동으로 안 뜬다면 enable도 확인합니다

서비스가 수동으로는 뜨는데, 서버 재부팅 후 자동으로 안 뜨는 경우도 있습니다.

이때는 enable 설정을 확인해야 합니다.

현재 서비스가 실행 중인지 보는 명령어와, 재부팅 후 자동 기동 설정을 보는 명령어는 다릅니다.

현재 실행 상태는 이렇게 봅니다.

systemctl is-active 서비스명

자동 기동 설정은 이렇게 봅니다.

systemctl is-enabled 서비스명

서비스를 지금 켜는 것은 start이고, 서버 재부팅 후 자동으로 켜지게 설정하는 것은 enable입니다.

이 둘을 헷갈리면 이런 일이 생길 수 있습니다.

지금은 서비스가 정상으로 보인다.
그런데 서버 재부팅 후 다시 안 뜬다.

이런 경우에는 is-enabled를 함께 확인해야 합니다.

서비스 자동 기동 설정 확인은 아래 글에서 정리했습니다.

https://opsnote.tistory.com/30

리눅스 서버 재기동 후 서비스가 자동으로 안 뜰 때 systemctl enable disable 차이 확인하는 법

리눅스 서버에서 서비스를 직접 올릴 때는 보통 systemctl start를 사용합니다.systemctl start nginx 그런데 분명 서비스를 켜둔 것 같은데, 서버를 재기동한 뒤 다시 확인해보면 서비스가 안 떠 있는 경

opsnote.tistory.com

10. 조치 전에는 영향도를 정리합니다

서비스가 안 뜬 원인을 어느 정도 찾았다면 조치를 고민해야 합니다.

하지만 운영 서버에서는 조치 전에 영향도를 먼저 봐야 합니다.

예를 들어 아래 작업은 모두 영향이 있을 수 있습니다.

restart
stop
설정 파일 수정
권한 변경
포트 변경
프로세스 kill
서버 재부팅

그래서 조치 전에는 최소한 아래 내용을 정리하는 것이 좋습니다.

확인된 사실:
서비스 상태, 실패 시간, 로그 메시지

추정 원인:
포트 충돌, 설정 오류, 권한 문제, 파일 누락, 의존 서비스 문제

조치 계획:
설정 수정, 서비스 재기동, 권한 조정, 담당자 확인

영향 범위:
서비스 중단 가능성, 사용자 영향, 재발 가능성

원복 방법:
변경 전 설정 백업, 이전 값 기록, 재기동 전 상태 확인

운영 서버에서는 빨리 조치하는 것보다, 안전하게 확인하고 조치하는 것이 더 중요합니다.

11. 보고는 상태와 로그 중심으로 남깁니다

서비스 장애를 확인한 뒤에는 보고도 남겨야 합니다.

보고는 길게 쓰기보다, 확인한 사실과 조치 내용을 나눠서 적는 것이 좋습니다.

예시는 이렇게 정리할 수 있습니다.

[현상]
서비스 접속 불가 및 프로세스 미기동 상태 확인

[확인]
systemctl status 확인 결과 서비스 failed 상태 확인
journalctl 확인 결과 설정 파일 경로 오류 메시지 확인
systemctl --failed 확인 결과 동일 서비스만 failed 상태 확인
포트 listen 상태 없음 확인

[조치]
설정 파일 경로 수정 후 서비스 재기동
재기동 후 systemctl status active 상태 확인
포트 listen 및 HTTP 응답 정상 확인

[결과]
서비스 정상 기동 확인
최근 로그에서 동일 오류 재발 없음

[추가 확인]
재부팅 후 자동 기동 설정 확인 예정

이렇게 정리하면 보는 사람도 상황을 빠르게 이해할 수 있습니다.

“서비스가 안 떠서 재기동했습니다”보다 훨씬 낫습니다.

12. 정리하면

리눅스 서버에서 서비스가 안 뜰 때 가장 먼저 할 일은 restart가 아닙니다.

먼저 현재 상태와 로그를 확인해야 합니다.

systemctl status로 서비스 상태를 확인합니다.
journalctl로 최근 실패 로그를 확인합니다.
systemctl --failed로 실패한 서비스 목록을 봅니다.
포트 listen 여부를 확인합니다.
HTTP 응답이 필요한 서비스라면 curl로 응답을 봅니다.
restart가 필요하면 조치 후 반드시 다시 확인합니다.
재부팅 후 자동으로 안 뜬다면 is-enabled를 확인합니다.
조치 전 영향도와 원복 방법을 정리합니다.

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

서비스가 안 뜰 때는 restart 전에 systemctl status와 journalctl부터 확인하세요.

서비스 장애 대응도 결국 같습니다.

확인 → 판단 → 조치 → 재확인

서비스 상태 확인을 명령어별로 더 자세히 보고 싶다면 아래 글들을 함께 보면 좋습니다.

https://opsnote.tistory.com/27

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

opsnote.tistory.com

https://opsnote.tistory.com/33

리눅스 서버 systemctl status만 보지 말고 journalctl로 서비스 로그 확인하는 법

opsnote.tistory.com

https://opsnote.tistory.com/32

리눅스 서버에서 실패한 서비스 한 번에 확인하는 systemctl --failed 사용법

opsnote.tistory.com

https://opsnote.tistory.com/28

리눅스 서버 systemctl start stop restart 차이와 restart 바로 누르면 안 되는 이유

opsnote.tistory.com

https://opsnote.tistory.com/29

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

opsnote.tistory.com

https://opsnote.tistory.com/30

리눅스 서버 재기동 후 서비스가 자동으로 안 뜰 때 systemctl enable disable 차이 확인하는 법

opsnote.tistory.com

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

https://opsnote.tistory.com/69

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

opsnote.tistory.com

리눅스 서버 디스크 용량 90% 알림을 받았을 때 실제 점검 흐름 정리

opsnote — Tue, 22 Sep 2026 21:11:01 +0900

리눅스 서버 디스크 용량 90% 알림을 받았을 때 df -h, du, find, df -i, deleted 파일 확인 순서와 조치 전 영향도 확인 흐름을 설명하는 이미지

리눅스 서버를 운영하다 보면 디스크 용량 알림을 받을 때가 있습니다.

처음에는 단순하게 보입니다.

디스크가 90%를 넘었다.
공간이 부족하다.
큰 파일 몇 개만 지우면 되지 않을까?

저도 처음에는 이렇게 생각했습니다.
그런데 운영 서버에서는 디스크 용량 알림을 단순한 청소 문제로 보면 위험할 수 있습니다.

디스크가 찼다고 바로 파일을 삭제하면 장애 원인을 확인할 로그를 지워버릴 수 있고, 서비스가 아직 사용 중인 파일을 건드릴 수도 있습니다.

특히 /var, /tmp, /data, 애플리케이션 로그 경로, 백업 경로는 각각 성격이 다르기 때문에 같은 방식으로 판단하면 안 됩니다.

이번 글에서는 리눅스 서버에서 디스크 용량 90% 알림을 받았을 때, 실제 운영 상황에서 어떤 순서로 확인하면 좋은지 정리해보겠습니다.

핵심은 단순합니다.

디스크가 찼다면, 지우기 전에 먼저 어디가 왜 찼는지 확인해야 합니다.

운영 서버에서는 항상 확인 → 판단 → 조치 → 재확인 순서가 먼저입니다.

1. 먼저 알림 내용을 확인합니다

디스크 용량 알림을 받으면 가장 먼저 알림 내용을 다시 봅니다.

이때 중요한 것은 사용률 숫자만 보는 것이 아닙니다.
90%라는 숫자보다 더 중요한 것은 어느 파일시스템이 찼는지입니다.

보통 알림에는 아래 정보가 들어 있습니다.

서버명
파일시스템
사용률
마운트 경로
알림 발생 시간

여기서 가장 먼저 볼 항목은 마운트 경로입니다.

같은 90%라도 /가 찬 것과 /var가 찬 것, /tmp가 찬 것, /data가 찬 것은 전혀 다른 문제일 수 있습니다.

/ : OS 전체 영향 가능성
/var : 로그, 캐시, 패키지, 서비스 데이터 영향 가능성
/tmp : 업로드, 압축 해제, 배치 작업, 임시 파일 영향 가능성
/data : 애플리케이션 데이터나 사용자 업로드 파일 영향 가능성

그래서 처음 판단은 이렇게 잡는 것이 좋습니다.

디스크가 찼다.
그러면 어느 마운트가 찼는지 먼저 확인한다.

2. df -h로 전체 파일시스템을 봅니다

가장 먼저 확인할 명령어는 df -h입니다.

df -h

이 명령어로 전체 파일시스템의 사용률을 확인합니다.

여기서 Use%만 보면 안 됩니다.
Size, Used, Avail, Mounted on을 같이 봐야 합니다.

특히 Mounted on이 중요합니다.
같은 90%라도 어느 경로가 찼는지에 따라 판단이 완전히 달라집니다.

예를 들어 /var가 92%라면 로그나 캐시를 먼저 의심할 수 있습니다.
/tmp가 100%라면 임시 파일이나 배치 작업을 볼 수 있습니다.
/data가 찼다면 업로드 파일, 백업 파일, 애플리케이션 데이터 증가를 확인해야 할 수 있습니다.

df -h를 볼 때는 아래처럼 생각하면 좋습니다.

어느 경로가 찼는가?
남은 용량은 어느 정도인가?
증가 속도가 빠른가?
서비스 영향이 있는 경로인가?

df -h 결과를 볼 때 Use%만 보면 안 되는 이유는 아래 글에서 따로 정리했습니다.

https://opsnote.tistory.com/2

리눅스 서버 df -h 결과, Use%만 보면 안 되는 이유와 확인 순서

리눅스 서버에서 디스크 용량을 확인할 때 가장 많이 쓰는 명령어는 df -h입니다. 그런데 초보 운영자는 Use% 숫자만 보고 “90%니까 바로 파일을 지워야 하나?”라고 판단하기 쉽습니다. 하지만 서

opsnote.tistory.com

디스크 용량 90% 알림을 받았을 때 기본 확인 순서는 아래 글도 함께 보면 좋습니다.

https://opsnote.tistory.com/1

리눅스 서버 디스크 용량 90% 넘었을 때 바로 삭제하지 말고 확인하는 법

리눅스 서버를 운영하다 보면 디스크 용량 90% 이상 사용 중 같은 알림을 받을 때가 있습니다. 이때 바로 파일을 삭제하면 로그 분석에 필요한 파일을 지우거나, 서비스가 사용 중인 파일을 잘못

opsnote.tistory.com

3. 바로 삭제하지 말고 큰 폴더부터 찾습니다

어느 마운트가 찼는지 확인했다면, 다음은 그 안에서 어떤 폴더가 큰지 확인합니다.

예를 들어 /var가 찼다고 해서 바로 /var/log 파일을 지우면 안 됩니다.
먼저 /var 아래에서 어떤 폴더가 큰지 봐야 합니다.

du -sh /var/* 2>/dev/null | sort -rh | head

문제가 되는 경로로 이동해서 볼 수도 있습니다.

cd /var
du -sh * 2>/dev/null | sort -rh | head

이 과정의 목적은 삭제할 파일을 바로 찾는 것이 아닙니다.

용량을 차지하는 위치를 좁히는 것입니다.

흐름은 이렇게 잡습니다.

df -h로 찬 마운트를 확인합니다.
du로 큰 폴더를 확인합니다.
큰 폴더 안으로 들어가서 다시 du로 확인합니다.
마지막에 실제 파일을 확인합니다.

큰 폴더를 찾는 방법은 아래 글에서 이어서 볼 수 있습니다.

https://opsnote.tistory.com/3

리눅스 서버 디스크 용량이 찼을 때 du -sh로 큰 폴더 찾는 법

서버를 운영하다 보면 df -h로 전체 용량을 먼저 확인하게 됩니다.그런데 어느 영역이 찼는지 확인했다면, 그다음에는 “정확히 어떤 폴더가 용량을 많이 차지하는지” 찾아야 합니다.이때 실무

opsnote.tistory.com

4. 큰 파일인지, 작은 파일이 많이 쌓인 것인지 나눕니다

큰 폴더를 찾았다면 그다음은 원인을 조금 더 나눠야 합니다.

디스크가 찬 이유는 크게 두 가지일 때가 많습니다.

큰 파일 몇 개가 용량을 차지하는 경우
작은 파일이 너무 많이 쌓인 경우

큰 파일을 찾을 때는 find 명령어를 사용할 수 있습니다.

find /var/log -type f -size +100M -exec ls -lh {} \; 2>/dev/null

로그 파일 하나가 몇 GB까지 커졌다면 애플리케이션 오류가 반복되고 있을 수 있습니다.

반대로 작은 파일이 수십만 개 쌓였다면 용량보다 inode 문제가 먼저 나타날 수도 있습니다.

큰 파일을 찾는 방법은 아래 글에서 정리했습니다.

https://opsnote.tistory.com/4

리눅스 서버 디스크 용량을 잡아먹는 큰 파일 find 명령어로 찾는 법

리눅스 서버에서 디스크 용량이 부족할 때는 먼저 df -h로 어느 영역이 찼는지 확인합니다.그다음 du -sh * | sort -rh 명령어로 어떤 폴더가 큰지 확인할 수 있습니다.그런데 폴더 단위로 확인한 뒤에

opsnote.tistory.com

5. df와 du 결과가 다르면 deleted 파일을 의심합니다

운영 중에는 df -h와 du 결과가 맞지 않는 경우가 있습니다.

df -h에서는 용량이 많이 찼다고 나오는데, du로 찾아보면 그만큼 큰 파일이 보이지 않을 때가 있습니다.

이럴 때는 deleted 파일을 의심해야 합니다.

파일은 삭제됐지만, 어떤 프로세스가 아직 그 파일을 잡고 있으면 디스크 공간이 바로 반환되지 않을 수 있습니다.

확인은 이렇게 합니다.

lsof | grep deleted

특정 경로만 보고 싶다면 이렇게 좁힐 수 있습니다.

lsof | grep deleted | grep /var

이 상황에서 무작정 다른 파일을 지우면 원인을 더 놓칠 수 있습니다.

실제로 공간을 잡고 있는 것은 이미 삭제된 로그 파일일 수도 있기 때문입니다.

df와 du 결과가 다르게 보일 때 확인하는 방법은 아래 글에서 이어서 볼 수 있습니다.

https://opsnote.tistory.com/65

6. 용량은 남았는데 파일 생성이 안 되면 inode를 확인합니다

디스크 문제는 용량만의 문제가 아닐 수 있습니다.

df -h에서는 용량이 남아 있는데, 파일 생성이 안 되거나 No space left on device 오류가 나는 경우가 있습니다.

이때는 inode를 확인해야 합니다.

df -i

inode는 파일을 만들 수 있는 자리표에 가깝습니다.

용량이 남아 있어도 inode가 다 차면 새 파일을 만들 수 없습니다.

이 문제는 작은 파일이 많이 쌓이는 경로에서 자주 발생합니다.

세션 파일
캐시 파일
임시 파일
작은 로그 파일
업로드 임시 파일

용량은 남았는데 파일 생성이 안 될 때 inode를 확인하는 방법은 아래 글에서 정리했습니다.

https://opsnote.tistory.com/66

리눅스 서버 용량은 남았는데 파일 생성이 안 될 때 df -i로 inode 확인하는 법

리눅스 서버에서 df -h로 보면 디스크 용량은 아직 남아 있는데, 파일 생성이나 로그 기록이 안 되고 No space left on device 오류가 뜨는 경우가 있습니다. 이때 초보 운영자는 “용량이 남았는데 왜

opsnote.tistory.com

7. /tmp는 이름만 보고 가볍게 보면 안 됩니다

디스크 용량 문제에서 /tmp는 자주 등장합니다.

이름이 임시 폴더라서 쉽게 지워도 될 것처럼 보입니다.
하지만 운영 서버에서는 현재 프로세스가 /tmp 안의 파일을 사용 중일 수 있습니다.

예를 들어 이런 경우가 있습니다.

파일 업로드 중 임시 저장
압축 해제 중 임시 파일 생성
배치 작업 중 임시 결과 저장
애플리케이션이 임시 파일 사용

그래서 /tmp가 찼을 때도 바로 삭제하지 말고 먼저 확인해야 합니다.

du -sh /tmp/* 2>/dev/null | sort -rh | head
find /tmp -xdev -type f -mmin -60 | head
lsof | grep /tmp

중요한 것은 오래된 파일인지, 지금 사용 중인 파일인지, 정리 정책이 있는지 나누는 것입니다.

/tmp 용량이 찼을 때 확인하는 순서는 아래 글에서 이어서 볼 수 있습니다.

https://opsnote.tistory.com/67

리눅스 서버 /tmp 용량이 찼을 때 바로 삭제하지 말고 확인하는 법

리눅스 서버에서 /tmp 용량이 가득 차면 파일 업로드 실패, 압축 해제 실패, 배치 오류, 애플리케이션 임시파일 생성 실패 같은 문제가 생길 수 있습니다. 이때 초보 운영자는 “임시파일이니까

opsnote.tistory.com

8. /var는 더 조심해서 봅니다

/var는 운영 서버에서 특히 조심해야 하는 경로입니다.

/var 아래에는 여러 성격의 데이터가 섞여 있습니다.

/var/log
/var/cache
/var/spool
/var/lib

/var/log는 로그가 쌓이는 경로입니다.
/var/cache는 캐시 데이터가 있을 수 있습니다.
/var/lib는 서비스 데이터가 들어가는 경우가 많아서 함부로 지우면 위험합니다.

그래서 /var가 찼을 때는 이렇게 나눠서 봐야 합니다.

로그가 커진 것인지
캐시가 쌓인 것인지
서비스 데이터가 증가한 것인지
패키지 관련 파일인지
현재 서비스가 사용하는 파일인지

/var 용량 문제를 안전하게 보는 방법은 아래 글에서 정리했습니다.

https://opsnote.tistory.com/68

리눅스 서버 /var 용량이 찼을 때 위험한 이유와 안전한 확인 순서

리눅스 서버에서 /var 용량이 가득 차면 단순히 디스크 공간이 부족한 문제로 끝나지 않을 수 있습니다. /var에는 로그, 캐시, 스풀, 패키지 데이터, 애플리케이션 상태 파일이 쌓이는 경우가 많아

opsnote.tistory.com

9. 조치 전에 영향도를 먼저 봅니다

어느 정도 원인을 찾았다면 다음은 조치입니다.

하지만 운영 서버에서는 조치도 바로 들어가면 안 됩니다.

삭제, 비우기, 이동, 압축, 재기동은 모두 영향이 있을 수 있습니다.

조치 전에는 최소한 아래를 확인해야 합니다.

이 파일을 삭제해도 되는가?
현재 서비스가 사용 중인가?
로그 분석에 필요한 파일인가?
백업 대상인가?
보관 정책이 있는가?
삭제보다 압축이나 이동이 나은가?
서비스 재기동이 필요한가?
원복 방법은 있는가?

특히 아래 작업은 운영 영향이 생길 수 있습니다.

rm
truncate
logrotate 강제 실행
서비스 restart
프로세스 kill

그래서 조치 전에는 이렇게 정리해두면 좋습니다.

확인된 사실:
어떤 파일시스템이 몇 %까지 찼는지

추정 원인:
어떤 경로나 파일이 증가했는지

조치 계획:
삭제, 이동, 압축, 로그 정리, 서비스 재기동 여부

영향 범위:
서비스 중단 가능성, 로그 유실 가능성, 재발 가능성

원복 방법:
백업 위치, 이동 경로, 변경 전 상태

10. 조치 후에는 다시 확인합니다

디스크 조치가 끝났다고 바로 완료라고 보면 안 됩니다.

반드시 다시 확인해야 합니다.

df -h
df -i

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

journalctl -u 서비스명 -n 100 --no-pager

웹 서비스라면 간단한 응답도 확인합니다.

curl -I http://localhost

조치 후에는 아래를 봅니다.

사용률이 실제로 내려갔는가?
inode 사용률도 정상인가?
서비스 에러가 새로 발생하지 않는가?
로그가 다시 빠르게 증가하지 않는가?
같은 알림이 반복되지 않는가?

디스크 문제는 지웠다는 사실보다 다시 쌓이지 않는지 확인하는 것이 더 중요합니다.

11. 같은 디스크 90% 알림이어도 원인은 다를 수 있다

운영 중인 리눅스 서버에서 디스크 사용률이 90%를 넘었다는 알림을 받았다고 가정해 보겠습니다.

처음에는 공간이 부족하다는 사실만 확인할 수 있습니다. 실제로 어떤 파일이 증가했는지, 왜 사용률이 높아졌는지는 아직 알 수 없습니다.

그래서 먼저 파일시스템 사용률부터 확인합니다.

df -h

예를 들어 /var 파일시스템의 사용률이 92%라고 해보겠습니다.

이때 바로 로그 파일을 삭제하기보다는 어떤 경로에서 공간을 사용하고 있는지 확인합니다.

du -xhd1 /var 2>/dev/null

-x 옵션은 다른 파일시스템으로 넘어가지 않고 현재 파일시스템 안에서 사용량을 확인할 때 유용합니다.

다만 디렉터리의 파일을 읽으며 사용량을 계산하므로 파일이 매우 많은 운영 서버에서는 디스크 I/O 부하가 발생할 수 있습니다.

이후에는 확인 결과에 따라 점검 방향이 달라집니다.

1. 로그 파일이 계속 증가하는 경우

/var/log의 사용량이 크고 특정 로그 파일이 계속 증가하고 있다면, 로그 발생량과 보관 정책을 확인합니다.

이때 중요한 것은 해당 파일이 현재 서비스에서 사용 중인지 확인하는 것입니다.

로그 파일이 크다고 해서 무조건 삭제하면 안 됩니다. 장애 원인을 확인하는 데 필요한 기록일 수도 있기 때문입니다.

저는 이런 경우 로그가 갑자기 증가한 시각과 애플리케이션에서 오류가 발생한 시각이 비슷한지 먼저 비교합니다.

2. df와 du의 사용량이 크게 다른 경우

df -h에서는 디스크 사용률이 높은데, du로 확인한 파일 사용량의 합계는 생각보다 적을 수 있습니다.

이때는 삭제된 파일을 프로세스가 계속 열고 있는 상황인지 확인해 볼 수 있습니다.

lsof +L1

파일을 삭제했더라도 프로세스가 해당 파일을 계속 열고 있으면 디스크 공간이 즉시 반환되지 않을 수 있습니다.

다만 df와 du의 차이가 항상 삭제된 파일 때문인 것은 아닙니다. 파일시스템의 예약 공간이나 메타데이터 등 다른 원인도 있을 수 있습니다.

또한 lsof +L1은 서버 전체 프로세스를 확인하므로 규모가 큰 환경에서는 실행 비용을 고려해야 합니다.

주의할 점은 여기서 바로 프로세스를 종료하거나 서비스를 재시작하지 않는 것입니다.

해당 프로세스가 어떤 서비스를 담당하는지, 재시작하면 영향이 있는지 확인한 후 조치 여부를 결정해야 합니다.

3. 디스크 용량은 남았는데 파일 생성이 안 되는 경우

디스크 공간뿐 아니라 inode가 부족한 상황일 수도 있습니다.

이럴 때는 다음 명령으로 확인합니다.

df -i

inode 사용률이 100%라면 디스크 공간이 남아 있어도 새 파일을 만들지 못할 수 있습니다.

특히 작은 파일이 매우 많이 생성되는 환경에서는 사용 용량보다 inode가 먼저 부족해질 수 있습니다.

이 경우에도 파일을 무작정 삭제하기보다 어떤 경로에서 파일 수가 증가했는지 확인해야 합니다.

점검 결과에 따라 다음 행동을 결정한다

세 가지 상황을 정리하면 다음과 같습니다.

확인 결과의심할 수 있는 원인다음 확인

/var/log 사용량 증가	로그 급증 또는 보관 정책	로그 증가 시각과 서비스 오류
df와 du 사용량 차이	삭제 후 열린 파일 등	lsof +L1 결과
inode 사용률 100%	작은 파일 대량 생성	파일 생성 경로와 개수

같은 디스크 90% 알림이라도 확인 결과에 따라 원인과 조치 방법은 달라질 수 있습니다.

제가 운영하면서 중요하게 생각하는 순서는 다음과 같습니다.

디스크 알림 확인
→ 사용률이 높은 파일시스템 확인
→ 실제 사용 경로 확인
→ 점검 결과에 따라 원인 분기
→ 서비스 영향도 확인
→ 조치 후 재확인

결국 중요한 것은 디스크 사용률을 일시적으로 낮추는 것보다 왜 사용률이 올라갔는지 확인하고, 같은 문제가 반복되지 않도록 하는 것입니다.

12. 보고는 짧고 정확하게 남깁니다

디스크 용량 문제를 확인한 뒤에는 보고도 남겨야 합니다.

보고는 길게 쓰기보다, 확인한 사실과 조치 내용을 나눠서 쓰는 것이 좋습니다.

예시는 이렇게 정리할 수 있습니다.

[현상]
서버 디스크 사용률 90% 이상 알림 발생

[확인]
df -h 확인 결과 /var 파일시스템 사용률 92% 확인
du 확인 결과 /var/log/example-app 경로의 로그 파일 증가 확인
lsof deleted 확인 결과 삭제 상태로 점유 중인 파일은 확인되지 않음

[조치]
담당 서비스 로그 보관 정책 확인 후 오래된 로그 압축 및 정리
서비스 영향 없음

[결과]
df -h 재확인 결과 사용률 92%에서 76%로 감소
서비스 상태 및 최근 로그 정상 확인

[추가 확인]
로그 증가 원인 분석 및 logrotate 설정 점검 예정

이렇게 쓰면 보는 사람도 상황을 빠르게 이해할 수 있습니다.

단순히 “디스크 찼습니다. 정리했습니다.”라고 쓰는 것보다 훨씬 낫습니다.

13. 정리하면

리눅스 서버에서 디스크 용량 90% 알림을 받았을 때 가장 위험한 대응은 바로 삭제하는 것입니다.

운영 서버에서는 먼저 확인해야 합니다.

df -h로 어느 마운트가 찼는지 확인합니다.
du로 큰 폴더를 확인합니다.
find로 큰 파일을 확인합니다.
df와 du가 다르면 deleted 파일을 확인합니다.
용량은 남았는데 파일 생성이 안 되면 df -i를 확인합니다.
/tmp와 /var는 경로 성격을 나눠서 확인합니다.
조치 전 영향도를 확인합니다.
조치 후 df -h, df -i, 서비스 상태를 다시 확인합니다.

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

디스크가 찼다면, 지우기 전에 먼저 어디가 왜 찼는지 확인하세요.

디스크 문제도 결국 같습니다.

확인 → 판단 → 조치 → 재확인

디스크 용량 문제를 명령어별로 더 자세히 보고 싶다면 아래 글을 함께 보면 좋습니다.

https://opsnote.tistory.com/70

리눅스 서버 디스크 용량 문제 확인 순서 총정리

opsnote.tistory.com

df -h, du, find, df -i, deleted 파일 확인 흐름을 따로 보고 싶다면 아래 글들도 이어서 볼 수 있습니다.

https://opsnote.tistory.com/2

리눅스 서버 df -h 결과, Use%만 보면 안 되는 이유와 확인 순서

opsnote.tistory.com

https://opsnote.tistory.com/3

리눅스 서버 디스크 용량이 찼을 때 du -sh로 큰 폴더 찾는 법

opsnote.tistory.com

https://opsnote.tistory.com/4

리눅스 서버 디스크 용량을 잡아먹는 큰 파일 find 명령어로 찾는 법

opsnote.tistory.com

https://opsnote.tistory.com/65

리눅스 서버 df와 du 결과가 다르게 보일 때 deleted 파일부터 확인하는 법

리눅스 서버에서 디스크 용량을 확인하다 보면 df -h에서는 사용량이 높은데, du로 디렉터리를 확인하면 큰 파일이 잘 보이지 않는 경우가 있습니다. 이럴 때 초보 운영자는 “파일을 더 지워야

opsnote.tistory.com

https://opsnote.tistory.com/66

리눅스 서버 용량은 남았는데 파일 생성이 안 될 때 df -i로 inode 확인하는 법

opsnote.tistory.com

https://opsnote.tistory.com/67

리눅스 서버 /tmp 용량이 찼을 때 바로 삭제하지 말고 확인하는 법

opsnote.tistory.com

https://opsnote.tistory.com/68

리눅스 서버 /var 용량이 찼을 때 위험한 이유와 안전한 확인 순서

opsnote.tistory.com

리눅스 서버 접속 장애 확인 순서 총정리

opsnote — Tue, 11 Aug 2026 20:59:19 +0900

리눅스 서버 접속 장애가 발생했을 때 ping, nc, curl, traceroute, nslookup, dig, systemctl, journalctl을 순서대로 확인하는 방법을 설명하는 대표 이미지

리눅스 서버를 운영하다 보면 가장 자주 듣는 말 중 하나가 있습니다.

접속이 안 됩니다.
사이트가 안 열립니다.
서버가 죽은 것 같습니다.
도메인이 안 됩니다.
포트가 막힌 것 같습니다.

처음 들으면 마음이 급해집니다.

서버에 바로 접속해보고, ping을 날려보고, 방화벽부터 떠올리게 됩니다.
하지만 접속 장애는 생각보다 원인이 다양합니다.

서버 자체가 죽은 것일 수도 있고, 서비스 프로세스가 내려간 것일 수도 있습니다.
포트는 열려 있는데 HTTP 응답이 이상할 수도 있고, DNS가 다른 IP를 바라보고 있을 수도 있습니다.
중간 네트워크 구간에서 막힌 것처럼 보여도 실제로는 특정 장비가 응답을 제한하는 경우도 있습니다.

그래서 접속 장애는 한 가지 명령어만 보고 판단하면 위험합니다.

이 글에서는 리눅스 서버에서 접속 장애가 발생했을 때 ping, nc, curl, traceroute, nslookup, dig, systemctl, journalctl을 어떤 순서로 확인하면 좋은지 정리해보겠습니다.

접속 장애에서 가장 먼저 해야 할 일

접속이 안 된다고 바로 방화벽이나 서버 장애로 단정하면 안 됩니다.

먼저 “접속이 안 된다”는 말을 더 작게 나눠야 합니다.

서버 IP로 접근이 안 되는지
도메인으로만 접근이 안 되는지
SSH 접속이 안 되는지
웹 서비스만 안 되는지
특정 포트만 안 되는지
특정 URL만 안 되는지
내부망에서는 되고 외부망에서는 안 되는지
일부 사용자만 안 되는지
전체 사용자가 안 되는지

이걸 나누지 않으면 확인 순서가 꼬입니다.

예를 들어 도메인 문제인데 서버만 계속 보고 있을 수 있습니다.
반대로 서비스 프로세스 문제인데 방화벽만 계속 볼 수도 있습니다.

초보 운영자라면 먼저 이렇게 정리하는 것이 좋습니다.

현상:
웹 페이지 접속 불가

접속 대상:
https://example.com

확인 범위:
도메인 응답, 서버 접근, 포트 오픈 여부, HTTP 응답, 서비스 상태, 로그

주의할 점:
ping 결과만으로 서비스 정상 여부를 판단하지 않음

이렇게 적어두면 접속 장애 대응이 훨씬 차분해집니다.

접속 장애 확인 순서

접속 장애가 발생했을 때는 아래 순서로 보는 것이 좋습니다.

접속 대상 구분
ping으로 기본 네트워크 응답 확인
nc로 포트 오픈 여부 확인
curl로 HTTP 응답 확인
systemctl로 서비스 상태 확인
journalctl로 서비스 로그 확인
traceroute로 경로 확인
nslookup으로 도메인 IP 확인
dig로 DNS 응답 상세 확인
최근 변경 사항 확인
조치 전 영향도 판단
조치 후 재확인

여기서 중요한 건 순서입니다.

ping이 안 된다고 바로 방화벽 문제로 결론 내리면 안 되고, ping이 된다고 서비스가 정상이라고 봐도 안 됩니다.

접속 장애도 결국 아래 흐름으로 움직이는 게 안전합니다.

확인 → 판단 → 조치 → 재확인

1. 먼저 IP 접속 문제인지 도메인 문제인지 나눕니다

접속 장애를 볼 때 가장 먼저 나눌 것은 이것입니다.

IP로도 안 되는가?
도메인으로만 안 되는가?

예를 들어 아래처럼 확인할 수 있습니다.

curl -I http://192.0.2.10
curl -I https://example.com

IP로는 접속되는데 도메인으로 안 된다면 DNS, 인증서, 가상호스트, 리버스 프록시 설정 쪽을 봐야 할 수 있습니다.

반대로 IP로도 접속이 안 된다면 서버 접근, 포트, 방화벽, 라우팅, 서비스 상태를 먼저 확인하는 쪽이 자연스럽습니다.

초반에 이걸 나누지 않으면 괜히 먼 길을 돌게 됩니다.

도메인 문제인데 서버 재기동 고민
서비스 문제인데 DNS만 계속 확인
포트 문제인데 ping만 반복 확인

접속 장애에서는 “어디까지 되는지”를 먼저 그려야 합니다.

2. ping은 기본 연결 확인용입니다

많이 사용하는 첫 번째 명령어는 ping입니다.

ping 192.0.2.10

도메인으로도 확인할 수 있습니다.

ping example.com

ping은 대상까지 ICMP 응답이 오는지 확인하는 도구입니다.

다만 여기서 바로 결론을 내리면 안 됩니다.

ping이 된다고 웹 서비스가 정상이라는 뜻은 아닙니다.
반대로 ping이 안 된다고 서버가 반드시 죽었다는 뜻도 아닙니다.

일부 서버나 보안 장비는 ICMP 응답을 막아둘 수 있습니다.

초보 운영자 기준으로는 이렇게 기억하면 좋습니다.

ping 성공
→ 서버 또는 경로가 ICMP에는 응답함
→ 서비스 포트 정상 여부는 별도 확인 필요

ping 실패
→ 서버 장애일 수도 있지만 ICMP 차단일 수도 있음
→ 포트, 경로, DNS를 함께 확인 필요

ping은 되는데 서비스 접속이 안 되는 경우는 아래 글에서 따로 정리했습니다.

https://opsnote.tistory.com/34

리눅스 서버 ping 된다고 정상이라 하지 말고 포트와 curl까지 확인하는 법

리눅스 서버 접속 문제가 생겼을 때 가장 먼저 떠올리는 명령어 중 하나가 ping입니다.서버가 살아 있는지, 네트워크가 닿는지 간단히 확인할 수 있어서 자주 사용합니다. ping -c 4 203.0.113.10 그런

opsnote.tistory.com

ping이 안 될 때도 바로 방화벽 문제로 단정하지 않는 흐름은 아래 글과 이어서 보면 좋습니다.

https://opsnote.tistory.com/35

리눅스 서버 ping 안 된다고 방화벽 문제라 하지 말고 포트와 curl까지 확인하는 법

리눅스 서버에 접속이 안 되는 상황에서 ping을 실행했는데 응답이 없으면, 초보 운영자는 바로 이렇게 생각하기 쉽습니다.ping -c 4 203.0.113.10 Request timeout 또는 이런 결과가 보일 수도 있습니다.4 pa

opsnote.tistory.com

3. 포트가 열려 있는지는 nc로 확인합니다

웹 서비스나 애플리케이션은 결국 특정 포트로 접속합니다.

예를 들어 웹 서비스라면 보통 80, 443 포트를 봅니다.

nc -vz 192.0.2.10 80
nc -vz 192.0.2.10 443

결과가 성공하면 해당 IP와 포트로 TCP 연결이 가능하다는 뜻입니다.

Connection to 192.0.2.10 443 port [tcp/https] succeeded!

실패하면 포트가 닫혀 있거나, 중간에서 차단되었거나, 서비스가 해당 포트를 listen하지 않을 수 있습니다.

Connection refused
Connection timed out
No route to host

여기서도 메시지를 나눠서 봐야 합니다.

Connection refused
→ 대상까지는 갔지만 해당 포트에서 받는 서비스가 없을 가능성

Connection timed out
→ 중간 방화벽, 네트워크 차단, 응답 지연 가능성

No route to host
→ 라우팅 또는 네트워크 경로 문제 가능성

포트 확인은 ping보다 서비스 접근에 한 걸음 더 가깝습니다.

nc로 포트가 열려 있는지 확인하는 방법은 아래 글에서 정리했습니다.

https://opsnote.tistory.com/36

리눅스 서버 포트 열렸는지 nc로 확인할 때 ping만 보지 말고 TCP 접속까지 확인하는 법

opsnote.tistory.com

4. HTTP 응답은 curl로 확인합니다

포트가 열려 있어도 웹 서비스가 정상이라는 뜻은 아닙니다.

포트는 열려 있는데 404, 500, 502, 503 같은 응답이 나올 수 있습니다.
이때는 curl로 HTTP 응답을 확인합니다.

curl -I https://example.com

예를 들어 이런 결과를 볼 수 있습니다.

HTTP/1.1 200 OK

또는 이런 결과가 나올 수도 있습니다.

HTTP/1.1 502 Bad Gateway
HTTP/1.1 503 Service Unavailable
HTTP/1.1 504 Gateway Timeout

curl은 단순히 포트가 열렸는지가 아니라, 웹 서버나 애플리케이션이 어떤 HTTP 응답을 주는지 확인하는 데 좋습니다.

그래서 nc와 curl은 역할이 다릅니다.

nc
→ 포트 연결 가능 여부 확인

curl
→ HTTP 응답 상태 확인

둘을 구분하지 않으면 “포트는 열려 있는데 왜 안 되지?”에서 멈추기 쉽습니다.

curl과 nc 차이는 아래 글에서 자세히 정리했습니다.

https://opsnote.tistory.com/38

리눅스 서버 접속 확인할 때 curl과 nc 차이, 포트와 HTTP 응답을 구분하는 법

opsnote.tistory.com

5. 서비스가 떠 있는지 systemctl로 확인합니다

포트가 닫혀 있거나 HTTP 응답이 이상하다면 서버 안에서 서비스 상태를 봐야 합니다.

예를 들어 nginx 상태를 확인합니다.

systemctl status nginx --no-pager

Apache라면 아래처럼 볼 수 있습니다.

systemctl status httpd --no-pager

Tomcat이나 애플리케이션 서비스라면 환경에 맞는 서비스명을 확인해야 합니다.

systemctl status tomcat --no-pager

여기서 볼 것은 단순히 active인지 아닌지만이 아닙니다.

Active 상태
Main PID
최근 에러 메시지
실패 코드
서비스 시작 시각
마지막 로그 일부

예를 들어 서비스가 내려가 있다면 포트가 닫혀 있을 수 있습니다.

반대로 서비스는 떠 있는데 HTTP 502가 난다면, 웹 서버 뒤쪽 upstream이나 애플리케이션 연결 문제일 수 있습니다.

서비스가 안 뜰 때 systemctl status부터 확인하는 흐름은 아래 글에서 정리했습니다.

https://opsnote.tistory.com/27

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

opsnote.tistory.com

실패한 서비스가 여러 개 있는지 보고 싶다면 아래 명령어도 도움이 됩니다.

systemctl --failed

관련 내용은 아래 글과 연결됩니다.

https://opsnote.tistory.com/32

리눅스 서버에서 실패한 서비스 한 번에 확인하는 systemctl --failed 사용법

opsnote.tistory.com

6. journalctl로 서비스 로그를 확인합니다

서비스 상태를 봤다면 로그를 같이 확인해야 합니다.

journalctl -u nginx -n 100 --no-pager

커널 메시지가 의심될 때는 아래처럼 볼 수도 있습니다.

journalctl -k -n 100 --no-pager

로그에서는 이런 키워드를 봅니다.

error
failed
timeout
permission denied
connection refused
address already in use
no space left on device
upstream
bind

접속 장애는 네트워크 문제처럼 보여도 실제로는 서비스 내부 문제일 수 있습니다.

예를 들어 이런 경우입니다.

설정 파일 오류로 서비스 기동 실패
포트 충돌로 bind 실패
인증서 경로 오류
로그 디렉터리 권한 문제
디스크 용량 부족으로 서비스 오류
upstream 애플리케이션 장애

그래서 ping, nc, curl만 보고 끝내지 말고 서비스 로그까지 봐야 합니다.

journalctl로 서비스 로그를 확인하는 방법은 아래 글에서 정리했습니다.

https://opsnote.tistory.com/33

리눅스 서버 systemctl status만 보지 말고 journalctl로 서비스 로그 확인하는 법

opsnote.tistory.com

7. 경로 문제는 traceroute로 봅니다

접속이 안 될 때 서버 자체 문제인지, 중간 네트워크 구간 문제인지 헷갈릴 수 있습니다.

이때는 traceroute를 사용합니다.

traceroute example.com

환경에 따라 tracepath를 사용할 수도 있습니다.

tracepath example.com

다만 traceroute 결과도 조심해서 봐야 합니다.

중간에서 별표가 보인다고 해서 그 장비가 무조건 장애라는 뜻은 아닙니다.

* * *

일부 네트워크 장비는 traceroute나 ICMP 응답을 제한할 수 있습니다.
그래서 traceroute는 단독 판단용이 아니라 경로를 추정하는 참고 자료로 보는 것이 좋습니다.

예를 들어 아래 결과를 같이 봐야 합니다.

ping 결과
nc 포트 확인 결과
curl HTTP 응답 결과
DNS 응답 결과
traceroute 경로

traceroute로 어느 구간에서 막히는지 확인하는 흐름은 아래 글에서 정리했습니다.

https://opsnote.tistory.com/37

리눅스 서버 접속 안 될 때 traceroute로 어느 구간에서 막히는지 확인하는 법

opsnote.tistory.com

8. 도메인 문제는 nslookup으로 먼저 확인합니다

도메인으로 접속이 안 될 때는 서버만 보면 안 됩니다.

먼저 도메인이 어떤 IP를 바라보는지 확인합니다.

nslookup example.com

예를 들어 도메인이 예상한 IP를 바라보지 않는다면, 서버가 정상이어도 접속 장애처럼 보일 수 있습니다.

확인할 것은 아래입니다.

도메인이 IP를 정상적으로 응답하는지
예상한 IP와 일치하는지
내부 DNS와 외부 DNS 응답이 다른지
CNAME이 다른 곳을 바라보는지
DNS 변경 직후 TTL 영향은 없는지

운영 환경에서는 내부망과 외부망의 DNS 응답이 다를 수 있습니다.

예를 들어 내부에서는 사설 IP를 바라보고, 외부에서는 공인 IP나 로드밸런서 주소를 바라볼 수 있습니다.

그래서 가능하면 확인 위치도 같이 적는 것이 좋습니다.

내부 서버에서 조회한 결과인지
사용자 PC에서 조회한 결과인지
외부망에서 조회한 결과인지
특정 DNS 서버로 조회한 결과인지

도메인 접속 장애에서 nslookup을 먼저 보는 흐름은 아래 글과 이어집니다.

https://opsnote.tistory.com/39

리눅스 서버 도메인 안 된다고 서버부터 보지 말고 nslookup으로 DNS부터 확인하는 법

opsnote.tistory.com

9. DNS 응답을 더 자세히 보려면 dig를 사용합니다

nslookup으로 기본 확인을 했다면, 더 자세한 DNS 응답은 dig로 볼 수 있습니다.

dig example.com

A 레코드를 직접 확인할 수도 있습니다.

dig A example.com

CNAME을 확인할 수도 있습니다.

dig CNAME example.com

특정 DNS 서버를 지정해서 조회할 수도 있습니다.

dig @8.8.8.8 example.com

dig에서는 이런 부분을 봅니다.

ANSWER SECTION
응답 IP
CNAME 흐름
TTL
조회한 DNS 서버
응답 시간

DNS 변경 직후라면 TTL 때문에 어떤 곳에서는 새 IP가 보이고, 어떤 곳에서는 예전 IP가 보일 수 있습니다.

이런 경우 서버가 문제가 아니라 DNS 반영 시점 차이일 수 있습니다.

dig로 DNS 응답을 자세히 확인하는 방법은 아래 글에서 정리했습니다.

https://opsnote.tistory.com/40

리눅스 서버 nslookup만 보지 말고 dig로 DNS 응답까지 확인하는 법

opsnote.tistory.com

10. 접속 장애와 서버 리소스도 같이 봅니다

접속 장애라고 해서 항상 네트워크만 보는 것은 아닙니다.

서버가 너무 느리거나, 디스크가 꽉 찼거나, 애플리케이션이 응답하지 못하는 상태라면 접속 장애처럼 보일 수 있습니다.

기본 리소스도 같이 확인합니다.

uptime
top
free -m
df -h

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

Load Average가 높아서 응답 지연
wa 값이 높아서 디스크 I/O 대기
메모리 부족으로 서비스 응답 지연
디스크 용량 부족으로 로그 기록 실패
서비스가 떠 있지만 요청 처리가 밀림

서버가 느린데 CPU만 보고 정상이라고 판단하면 안 됩니다.

Load Average 확인 흐름은 아래 글에서 정리했습니다.

https://opsnote.tistory.com/41

리눅스 서버 CPU 낮다고 정상이라 하지 말고 Load Average까지 확인하는 법

opsnote.tistory.com

top에서 wa 값을 보는 흐름은 아래 글과 이어서 보면 좋습니다.

https://opsnote.tistory.com/42

리눅스 서버 CPU 낮다고 정상이라 하지 말고 top wa 값까지 확인하는 법

opsnote.tistory.com

디스크 용량 문제가 접속 장애로 이어질 수도 있기 때문에, 디스크 확인도 같이 봐야 합니다.

https://opsnote.tistory.com/70

리눅스 서버 디스크 용량 문제 확인 순서 총정리

opsnote.tistory.com

11. 최근 변경 사항을 확인합니다

접속 장애는 변경 작업 뒤에 나타나는 경우가 많습니다.

아래 항목을 꼭 확인합니다.

방화벽 정책 변경
보안그룹 변경
DNS 변경
인증서 교체
웹 서버 설정 변경
로드밸런서 설정 변경
Ingress 설정 변경
애플리케이션 배포
서비스 재기동
포트 변경
서버 IP 변경

특히 이런 상황은 흔합니다.

DNS는 바꿨는데 일부 사용자만 이전 IP를 바라봄
방화벽 정책 변경 후 특정 포트만 차단됨
서비스 포트가 변경됐는데 LB 설정은 예전 포트를 바라봄
인증서 교체 후 HTTPS 접속 오류 발생
배포 후 애플리케이션 포트가 열리지 않음

명령어 결과가 애매할수록 최근 변경 사항을 같이 봐야 합니다.

운영에서는 “지금 안 된다”만 보는 것보다 “언제부터, 무엇이 바뀐 뒤부터 안 되는지”가 훨씬 중요합니다.

12. 바로 재기동하기 전에 확인할 것

접속이 안 되면 재기동을 떠올리기 쉽습니다.

하지만 재기동은 마지막에 가까운 카드입니다.

서비스 재기동 전에는 최소한 아래를 봐야 합니다.

서비스 상태를 확인했는지
최근 로그를 확보했는지
포트가 실제로 닫혀 있는지
설정 파일 오류는 없는지
디스크나 메모리 문제는 없는지
재기동 영향 범위는 확인했는지
재기동 후 자동 기동 여부는 확인했는지

서비스 재기동은 아래처럼 할 수 있습니다.

systemctl restart nginx

하지만 운영 서버에서는 명령어를 아는 것보다, 지금 이 조치를 해도 되는지 판단하는 것이 더 중요합니다.

서버 전체 재기동은 더 조심해야 합니다.

reboot

재기동 전 체크리스트는 아래 글과 함께 보면 좋습니다.

https://opsnote.tistory.com/19

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

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

opsnote.tistory.com

13. 조치 후에는 같은 경로로 다시 확인합니다

조치를 했다면 끝이 아닙니다.

반드시 다시 확인해야 합니다.

systemctl status nginx --no-pager
journalctl -u nginx -n 100 --no-pager
nc -vz 192.0.2.10 443
curl -I https://example.com

DNS 문제였다면 다시 조회합니다.

nslookup example.com
dig example.com

네트워크 경로 문제였다면 다시 확인합니다.

traceroute example.com

운영에서는 “조치했습니다”보다 “조치 후 정상 확인했습니다”가 더 중요합니다.

예를 들어 이렇게 정리할 수 있습니다.

조치 후 확인 결과:
서비스 상태 active 확인
443 포트 연결 성공
curl 기준 HTTP 200 응답 확인
최근 에러 로그 추가 발생 없음

이 정도까지 확인해야 대응이 마무리됩니다.

14. 실무에서 쓸 수 있는 보고 예시

접속 장애 상황에서는 보고도 중요합니다.

처음에는 짧게 정리하는 것이 좋습니다.

현상:
확인 내용:
원인 추정:
조치 내용:
현재 상태:
추가 확인 필요:

예를 들어 웹 접속 장애라면 이렇게 쓸 수 있습니다.

현상:
웹 서비스 접속 불가 문의가 접수되었습니다.

확인 내용:
서버 ping 응답은 확인되었으나, 443 포트 연결이 실패하는 상태입니다.
서비스 상태 및 방화벽 정책 변경 여부를 추가 확인 중입니다.

원인 추정:
현재까지는 웹 서비스 포트 미응답 또는 중간 방화벽 차단 가능성이 있습니다.

조치 내용:
서비스 상태와 최근 변경 사항을 확인하고 있습니다.

현재 상태:
서버 자체 접근은 가능하나 웹 서비스 접속은 정상 확인되지 않았습니다.

추가 확인 필요:
서비스 포트 listen 여부, 방화벽 정책, 로드밸런서 설정 확인이 필요합니다.

DNS가 의심된다면 이렇게 정리할 수 있습니다.

현상:
도메인 접속 시 일부 환경에서 접속 불가 현상이 확인되었습니다.

확인 내용:
nslookup 및 dig 조회 결과, 조회 위치에 따라 응답 IP가 다르게 확인됩니다.

원인 추정:
DNS 변경 후 TTL 또는 내부/외부 DNS 응답 차이 가능성이 있습니다.

조치 내용:
DNS 응답 경로와 실제 서비스 IP 일치 여부를 확인 중입니다.

현재 상태:
IP 직접 접속과 도메인 접속 결과를 분리하여 확인하고 있습니다.

서비스 장애가 의심된다면 이렇게 쓸 수 있습니다.

현상:
웹 서비스 접속 시 502 응답이 발생합니다.

확인 내용:
443 포트는 열려 있으나 curl 기준 502 응답이 확인되었습니다.
nginx 상태는 active이나 upstream 애플리케이션 연결 여부 확인이 필요합니다.

원인 추정:
웹 서버 자체보다는 뒷단 애플리케이션 또는 upstream 연결 문제 가능성이 있습니다.

조치 내용:
서비스 로그와 애플리케이션 프로세스 상태를 확인 중입니다.

이렇게 적으면 “접속 안 됩니다”보다 훨씬 실무적으로 보입니다.

접속 장애 빠른 확인 명령어 정리

상황별로 자주 쓰는 명령어를 정리하면 아래와 같습니다.

기본 네트워크 응답 확인

ping 192.0.2.10
ping example.com

포트 오픈 여부 확인

nc -vz 192.0.2.10 80
nc -vz 192.0.2.10 443

HTTP 응답 확인

curl -I http://example.com
curl -I https://example.com

서비스 상태 확인

systemctl status nginx --no-pager
systemctl --failed

서비스 로그 확인

journalctl -u nginx -n 100 --no-pager
journalctl -k -n 100 --no-pager

네트워크 경로 확인

traceroute example.com
tracepath example.com

DNS 기본 확인

nslookup example.com

DNS 상세 확인

dig example.com
dig A example.com
dig CNAME example.com
dig @8.8.8.8 example.com

명령어를 한 번에 다 치는 것이 중요한 건 아닙니다.

순서가 중요합니다.

ping으로 기본 응답 확인
nc로 포트 확인
curl로 HTTP 응답 확인
systemctl과 journalctl로 서버 내부 확인
traceroute로 경로 확인
nslookup과 dig로 DNS 확인
최근 변경 사항과 영향도 확인

정리하면

리눅스 서버 접속 장애는 한 가지 원인으로만 생기지 않습니다.

서버가 내려간 것처럼 보여도 DNS 문제일 수 있고, 방화벽 문제처럼 보여도 서비스 프로세스 문제일 수 있습니다.
포트는 열려 있어도 HTTP 응답이 502일 수 있고, 도메인은 정상이어도 뒷단 애플리케이션이 응답하지 않을 수 있습니다.

초보 운영자라면 아래 순서를 기억하면 좋습니다.

접속 대상 구분
ping 확인
nc 포트 확인
curl HTTP 응답 확인
systemctl 서비스 상태 확인
journalctl 로그 확인
traceroute 경로 확인
nslookup, dig DNS 확인
최근 변경 사항 확인
조치 후 재확인

그리고 가장 중요한 문장은 이것입니다.

접속이 안 된다고 바로 방화벽이나 서버 장애로 단정하지 말고, 어디까지 되고 어디서부터 안 되는지 나눠서 확인해야 합니다.

운영 서버에서는 빠른 조치보다 정확한 구분이 먼저입니다.

접속 장애는 네트워크 문제처럼 보이지만, 실제로는 서비스 상태, DNS, 포트, HTTP 응답이 함께 얽혀 있는 경우가 많습니다.

전체적인 리눅스 서버 장애 대응 흐름을 먼저 보고 싶다면 아래 글을 함께 보면 좋습니다.
https://opsnote.tistory.com/69

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

opsnote.tistory.com

디스크 용량 문제처럼 서버 내부 리소스 문제까지 함께 확인해야 하는 경우는 아래 글에서 따로 정리했습니다. https://opsnote.tistory.com/70

리눅스 서버 디스크 용량 문제 확인 순서 총정리

opsnote.tistory.com

웹 장애 상황에서 400, 401, 403, 404, 500, 502, 503, 504 같은 HTTP 상태 코드를 구분해서 보고하는 방법은 아래 글을 참고하면 됩니다.
https://opsnote.tistory.com/64

리눅스 서버 웹 장애 보고할 때 HTTP 코드 정리하는 법, 한눈에 보이는 오류 보고 가이드

리눅스 서버 운영을 하다 보면 웹 장애가 났을 때 “사이트 안 됩니다”, “접속이 안 돼요”, “nginx 에러 같아요”처럼 너무 크게 뭉뚱그려서 보고하게 될 때가 있습니다. 그런데 실제 장애 대

opsnote.tistory.com

리눅스 서버 디스크 용량 문제 확인 순서 총정리

opsnote — Tue, 11 Aug 2026 20:49:18 +0900

리눅스 서버 디스크 용량 문제가 발생했을 때 df -h, df -i, du, find, lsof deleted, 로그 파일, var와 tmp 경로를 순서대로 확인하는 방법을 설명하는 대표 이미지

리눅스 서버를 운영하다 보면 디스크 용량 문제는 생각보다 자주 만납니다.

처음에는 단순해 보입니다.

디스크가 찼다.
공간이 부족하다.
큰 파일을 지우면 된다.

하지만 운영 서버에서는 이렇게 바로 생각하면 위험합니다.

디스크가 찼다는 말 안에는 여러 상황이 섞여 있습니다.
/가 찬 것인지, /var가 찬 것인지, /tmp가 찬 것인지, 로그가 커진 것인지, inode가 부족한 것인지, 삭제한 파일을 프로세스가 계속 잡고 있는 것인지에 따라 확인 순서가 달라집니다.

초보 운영자가 가장 하기 쉬운 실수는 df -h에서 Use%만 보고 바로 삭제할 파일을 찾는 것입니다.

Use% 90%?
큰 파일 하나 지우면 되겠지?

하지만 디스크 문제에서 중요한 건 “무엇을 지울까”가 아니라 어디가 왜 찼는지 먼저 확인하는 것입니다.

이 글에서는 리눅스 서버에서 디스크 용량 문제가 생겼을 때 어떤 순서로 확인하면 좋은지 정리해보겠습니다.

디스크 문제에서 가장 먼저 멈춰야 하는 순간

디스크 용량 알림을 받으면 마음이 급해집니다.

예를 들어 이런 상황입니다.

/ 사용률 90%
/var 사용률 95%
/tmp 용량 부족
No space left on device
파일 업로드 실패
로그 기록 실패
서비스 응답 지연

이때 바로 파일을 삭제하고 싶어질 수 있습니다.

하지만 운영 서버라면 여기서 한 번 멈추는 게 좋습니다.

큰 파일이라고 해서 모두 불필요한 파일은 아닙니다.
서비스 데이터일 수도 있고, 장애 분석에 필요한 로그일 수도 있고, 현재 프로세스가 사용 중인 파일일 수도 있습니다.

더 헷갈리는 경우도 있습니다.

파일을 삭제했는데도 디스크 용량이 줄지 않을 수 있습니다. 이때는 삭제된 파일을 프로세스가 계속 잡고 있는 상태일 수 있습니다.

그래서 디스크 문제는 항상 아래 흐름으로 봐야 합니다.

확인 → 판단 → 조치 → 재확인

삭제는 확인의 시작이 아니라, 확인이 끝난 뒤 선택할 수 있는 조치 중 하나입니다.

디스크 용량 문제 확인 순서

디스크 용량 문제가 생겼을 때는 아래 순서로 보는 것이 좋습니다.

df -h로 어느 파일시스템이 찼는지 확인
df -i로 inode 부족 여부 확인
du로 큰 디렉터리 확인
find로 큰 파일 확인
/var, /tmp 같은 주요 경로 확인
로그 파일 증가 여부 확인
df와 du 결과가 다르면 deleted 파일 확인
현재 사용 중인 파일인지 확인
삭제, 압축, 이동, 재기동 여부 판단
조치 후 df -h로 다시 확인

처음부터 모든 명령어를 외울 필요는 없습니다.

다만 이 문장은 기억해두면 좋습니다.

디스크가 찼다고 바로 삭제하지 말고, 어디가 왜 찼는지 먼저 확인합니다.

1. df -h로 어느 파일시스템이 찼는지 확인합니다

디스크 용량 문제에서 가장 먼저 확인할 명령어는 df -h입니다.

df -h

예를 들어 이런 결과가 나올 수 있습니다.

Filesystem      Size  Used Avail Use% Mounted on
/dev/sda2        50G   45G  5.0G  90% /
/dev/sdb1       200G  180G   20G  90% /data
tmpfs           2.0G     0  2.0G   0% /run

여기서 Use%만 보면 안 됩니다.

같이 봐야 할 항목은 아래입니다.

Filesystem
→ 어떤 디스크나 볼륨인지

Size
→ 전체 크기

Used
→ 사용 중인 용량

Avail
→ 남은 용량

Use%
→ 사용률

Mounted on
→ 실제로 어느 경로에 붙어 있는지

특히 중요한 것은 Mounted on입니다.

/가 찬 것인지, /var가 찬 것인지, /tmp가 찬 것인지, /data가 찬 것인지에 따라 확인 순서가 달라집니다.

디스크 사용률 90% 알림을 처음 받았다면, 먼저 아래 글처럼 df -h로 위치부터 잡는 것이 좋습니다.

https://opsnote.tistory.com/1

리눅스 서버 디스크 용량 90% 넘었을 때 바로 삭제하지 말고 확인하는 법

opsnote.tistory.com

df -h 결과에서 Use%만 보면 안 되는 이유는 아래 글과 함께 보면 좋습니다.

https://opsnote.tistory.com/2

리눅스 서버 df -h 결과, Use%만 보면 안 되는 이유와 확인 순서

opsnote.tistory.com

2. “서버 용량이 찼다”를 더 작게 나눕니다

디스크 용량 문제를 “서버 용량이 찼다”라고만 말하면 너무 넓습니다.

운영에서는 아래처럼 나눠서 봐야 합니다.

/ 가 찼는지
/var 가 찼는지
/tmp 가 찼는지
/home 이 찼는지
/data 가 찼는지
애플리케이션 업로드 경로가 찼는지
백업 경로가 찼는지

예를 들어 /var가 찼다면 로그, 캐시, spool, 패키지 파일, 서비스 데이터 쪽을 봐야 할 수 있습니다.

반대로 /tmp가 찼다면 임시 파일, 업로드 임시 파일, 압축 해제 파일, 배치 작업 흔적을 확인해야 할 수 있습니다.

/data가 찼다면 애플리케이션 데이터, 업로드 파일, 백업 파일, DB dump, 배치 결과 파일 등을 확인해야 할 수 있습니다.

그래서 처음에는 이렇게 질문하는 것이 좋습니다.

어느 파일시스템이 찼는가?
그 경로는 어떤 용도로 쓰이는가?
서비스가 현재 사용 중인 파일이 있는가?
삭제해도 되는 기준이나 보관 정책이 있는가?

운영 서버에서는 “큰 파일이니까 삭제”가 아니라 “무슨 파일인지 확인 후 조치”가 기본입니다.

3. 용량은 남았는데 파일 생성이 안 되면 inode를 확인합니다

가끔 이상한 상황이 있습니다.

df -h로 보면 용량은 남아 있음
그런데 파일 생성이 안 됨
No space left on device 오류가 발생함
로그 파일이 새로 생성되지 않음

이럴 때는 디스크 용량이 아니라 inode 문제일 수 있습니다.

확인 명령어는 아래입니다.

df -i

inode는 파일을 만들 때 필요한 관리 정보라고 보면 됩니다.

아주 작은 파일이 너무 많이 쌓이면 실제 용량은 남아 있어도 inode가 먼저 부족해질 수 있습니다.

예를 들어 이런 경우입니다.

세션 파일이 많이 쌓임
임시 파일이 대량 생성됨
캐시 파일이 너무 많음
메일 큐나 spool 파일이 쌓임
작은 로그 조각 파일이 많음
컨테이너 관련 파일이 많이 생성됨

이때 df -h만 보면 원인을 놓칠 수 있습니다.

용량은 남았는데 파일 생성이 안 될 때는 아래 글처럼 inode를 같이 확인해야 합니다.

https://opsnote.tistory.com/66

리눅스 서버 용량은 남았는데 파일 생성이 안 될 때 df -i로 inode 확인하는 법

opsnote.tistory.com

4. du로 큰 디렉터리부터 좁혀갑니다

df -h로 어느 파일시스템이 찼는지 확인했다면, 다음은 그 안에서 어떤 디렉터리가 큰지 봐야 합니다.

예를 들어 /var가 문제라면 아래처럼 확인합니다.

du -sh /var/*

루트 파일시스템 전체를 볼 때는 아래처럼 사용할 수 있습니다.

du -sh /*

다만 운영 서버에서는 루트 전체를 확인할 때 권한 오류가 나오거나 시간이 오래 걸릴 수 있습니다.

그래서 가능하면 문제가 되는 경로를 좁혀서 확인하는 것이 좋습니다.

du -sh /var/log/*
du -sh /data/*
du -sh /home/*

여기서 df와 du의 역할을 구분해야 합니다.

df
→ 파일시스템 전체 사용량 확인

du
→ 디렉터리나 파일 단위 사용량 확인

둘을 헷갈리면 이런 상황에서 막히기 쉽습니다.

df -h에서는 사용량이 높음
du -sh로 보면 큰 파일이 안 보임

이 경우에는 삭제된 파일을 프로세스가 계속 잡고 있을 가능성도 봐야 합니다.

df와 du 결과가 다르게 보일 때의 확인 흐름은 아래 글에서 자세히 볼 수 있습니다.

https://opsnote.tistory.com/65

리눅스 서버 df와 du 결과가 다르게 보일 때 deleted 파일부터 확인하는 법

opsnote.tistory.com

5. 큰 파일은 find로 찾습니다

어느 디렉터리가 큰지 대략 확인했다면, 그 안에서 큰 파일을 찾아볼 수 있습니다.

예를 들어 /var/log 아래에서 100MB 이상 파일을 찾는다면 아래처럼 확인합니다.

find /var/log -type f -size +100M -exec ls -lh {} \;

/data 아래에서 1GB 이상 파일을 찾을 수도 있습니다.

find /data -type f -size +1G -exec ls -lh {} \;

여기서도 바로 삭제하면 안 됩니다.

큰 파일이라고 해서 모두 불필요한 파일은 아닙니다.

애플리케이션 로그
DB 백업 파일
업로드 파일
장애 분석용 dump
배치 결과 파일
압축 파일
서비스가 현재 쓰고 있는 파일

운영 서버에서는 파일명이 낯설다고 바로 지우면 안 됩니다.

먼저 파일의 성격을 확인합니다.

ls -lh /path/to/file
file /path/to/file
stat /path/to/file

필요하다면 해당 파일을 어떤 프로세스가 사용 중인지도 확인합니다.

lsof /path/to/file

큰 파일을 찾는 목적은 삭제가 아니라 판단입니다.

삭제는 마지막에 가까운 조치입니다.

6. /var가 찼다면 더 조심해서 봅니다

/var는 리눅스 서버에서 자주 커지는 경로입니다.

df -h /var
du -sh /var/*

/var 아래에는 여러 종류의 데이터가 섞여 있습니다.

/var/log
→ 로그 파일

/var/cache
→ 캐시 파일

/var/spool
→ 메일, 작업 큐 등

/var/lib
→ 서비스 데이터

/var/tmp
→ 임시 파일

특히 조심해야 할 곳은 /var/lib입니다.

/var/lib 아래에는 DB, 컨테이너, 패키지, 서비스 데이터가 들어갈 수 있습니다.
파일이 크다고 해서 바로 삭제하면 서비스 장애로 이어질 수 있습니다.

/var/log도 가볍게 보면 안 됩니다.

로그는 장애 원인을 확인하는 단서입니다.
먼지를 쓸기 전에 발자국 방향을 먼저 봐야 하는 것처럼, 로그도 비우기 전에 왜 커졌는지 확인해야 합니다.

/var 용량이 찼을 때 위험한 이유와 확인 순서는 아래 글에서 따로 정리했습니다.

https://opsnote.tistory.com/68

리눅스 서버 /var 용량이 찼을 때 위험한 이유와 안전한 확인 순서

opsnote.tistory.com

7. /tmp가 찼을 때도 바로 삭제하지 않습니다

/tmp는 이름 때문에 가볍게 보기 쉽습니다.

df -h /tmp
du -sh /tmp/*

하지만 /tmp가 찼다고 전체를 바로 삭제하면 안 됩니다.

/tmp에는 임시 파일이 많지만, 현재 서비스나 배치 작업이 사용 중인 파일도 있을 수 있습니다.

예를 들어 이런 상황입니다.

파일 업로드 임시 파일
압축 해제 중인 파일
배치 작업 임시 파일
설치 작업 중 생성된 파일
소켓 또는 잠금 파일
애플리케이션 임시 데이터

무작정 삭제하면 실행 중인 작업에 영향을 줄 수 있습니다.

먼저 파일의 생성 시간과 사용 여부를 확인합니다.

ls -al /tmp
find /tmp -type f -mtime +7 -exec ls -lh {} \;

/tmp 용량이 찼을 때는 아래 글처럼 바로 삭제보다 확인 순서를 먼저 잡는 것이 좋습니다.

https://opsnote.tistory.com/67

리눅스 서버 /tmp 용량이 찼을 때 바로 삭제하지 말고 확인하는 법

opsnote.tistory.com

8. 로그 파일이 계속 커지는지 확인합니다

디스크 용량 문제의 흔한 원인 중 하나는 로그 증가입니다.

du -sh /var/log/*

큰 로그 파일을 찾을 수도 있습니다.

find /var/log -type f -size +100M -exec ls -lh {} \;

하지만 로그 파일이 크다고 바로 비우면 안 됩니다.

먼저 아래를 확인해야 합니다.

어떤 서비스 로그인지
현재도 계속 증가 중인지
에러가 반복되고 있는지
logrotate 대상인지
보관 정책이 있는지
장애 분석에 필요한 로그인지

로그가 계속 커진다는 것은 단순 용량 문제가 아닐 수 있습니다.

애플리케이션 오류가 반복되고 있거나, 외부 요청이 비정상적으로 많거나, 특정 배치가 계속 실패하면서 로그를 쌓고 있을 수 있습니다.

최근 로그는 아래처럼 확인합니다.

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

에러 키워드를 찾을 수도 있습니다.

grep -i "error" /var/log/nginx/error.log
grep -i "timeout" /var/log/nginx/error.log

로그 파일이 계속 커질 때는 아래 글처럼 “비우기 전에 원인 확인”이 먼저입니다.

https://opsnote.tistory.com/7

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

리눅스 서버에서 디스크 용량 부족 알림이 발생했을 때, 원인이 로그 파일인 경우가 많습니다. 특히 /var/log 아래 시스템 로그나 애플리케이션 로그가 계속 커지면 시간이 지날수록 디스크 사용

opsnote.tistory.com

9. 삭제했는데 용량이 안 줄면 deleted 파일을 봅니다

운영 중에 이런 일이 생길 수 있습니다.

큰 로그 파일을 삭제함
그런데 df -h 사용량이 줄지 않음
du로 보면 큰 파일이 안 보임
서비스 재기동 후에야 용량이 줄어듦

이 경우 삭제된 파일을 프로세스가 계속 잡고 있을 수 있습니다.

확인 명령어는 아래입니다.

lsof | grep deleted

환경에 따라 아래 명령어를 사용할 수도 있습니다.

lsof +L1

파일명은 사라졌지만, 해당 파일을 열고 있는 프로세스가 있으면 디스크 공간이 바로 반환되지 않을 수 있습니다.

이때는 어떤 프로세스가 잡고 있는지 확인해야 합니다.

웹 서버 프로세스인지
애플리케이션 프로세스인지
DB 프로세스인지
로그 수집 에이전트인지
백업 또는 배치 프로세스인지

프로세스를 바로 kill 하거나 서버를 바로 재기동하기보다, 서비스 영향도를 먼저 봐야 합니다.

df와 du 결과가 다를 때 deleted 파일을 확인하는 방법은 아래 글과 연결해서 보면 좋습니다.

https://opsnote.tistory.com/65

리눅스 서버 df와 du 결과가 다르게 보일 때 deleted 파일부터 확인하는 법

opsnote.tistory.com

10. 현재 사용 중인 파일인지 확인합니다

삭제 후보 파일을 찾았다고 바로 지우면 안 됩니다.

현재 프로세스가 사용 중인지 확인해야 합니다.

lsof /path/to/file

특정 디렉터리를 사용하는 프로세스를 볼 수도 있습니다.

lsof +D /path/to/directory

다만 lsof +D는 디렉터리 크기가 크면 시간이 걸릴 수 있습니다.
운영 서버에서는 범위를 좁혀서 사용하는 것이 좋습니다.

파일을 삭제하기 전에는 최소한 아래를 확인합니다.

서비스가 현재 쓰고 있는 파일인가?
장애 분석에 필요한 로그인가?
백업 대상인가?
보관 정책이 있는가?
삭제 대신 압축이나 이동이 가능한가?
파일 삭제 후 서비스 영향이 있는가?

삭제보다 안전한 선택지가 있을 수도 있습니다.

압축
백업 경로 이동
logrotate 적용
오래된 파일만 정리
서비스 담당자 확인 후 삭제
디스크 증설

운영에서는 “지웠다”보다 “확인하고 안전하게 정리했다”가 더 중요합니다.

11. 디스크 용량 문제와 서비스 상태를 같이 봅니다

디스크가 꽉 차면 서비스에도 영향을 줄 수 있습니다.

예를 들어 아래 문제가 생길 수 있습니다.

로그 기록 실패
파일 업로드 실패
임시 파일 생성 실패
세션 생성 실패
DB 쓰기 실패
캐시 파일 생성 실패
배치 작업 실패
서비스 기동 실패

그래서 디스크 문제를 확인할 때 서비스 상태도 같이 봐야 합니다.

systemctl status nginx --no-pager
journalctl -u nginx -n 100 --no-pager

서비스 이름은 환경마다 다릅니다.

systemctl status httpd --no-pager
systemctl status tomcat --no-pager
systemctl status mariadb --no-pager

디스크 문제를 해결한 뒤에도 서비스가 정상인지 반드시 다시 확인해야 합니다.

서버 재기동 전에는 아래 체크리스트도 같이 보면 좋습니다.

https://opsnote.tistory.com/19

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

opsnote.tistory.com

12. 디스크가 찼을 때 바로 재기동하면 안 되는 이유

디스크가 찼을 때 서버를 재기동하면 일시적으로 좋아질 수도 있습니다.

예를 들어 임시 파일이 정리되거나, deleted 상태로 잡혀 있던 파일 공간이 반환될 수 있습니다.

하지만 재기동만으로 넘어가면 원인을 놓칠 수 있습니다.

어떤 파일이 커졌는지
왜 로그가 증가했는지
어떤 프로세스가 파일을 잡고 있었는지
어느 시간대에 용량이 급증했는지
다시 같은 문제가 생길 가능성이 있는지

이런 단서를 확인하지 못한 채 넘어가게 됩니다.

운영에서는 재기동이 필요할 수 있습니다.
다만 그 전에 확인할 것은 확인하고, 재기동 후에는 정상 상태를 다시 봐야 합니다.

df -h
systemctl status nginx --no-pager
journalctl -u nginx -n 100 --no-pager

재기동은 문제 해결 버튼이 아니라, 영향도가 있는 조치입니다.

13. 실무에서 쓸 수 있는 보고 예시

디스크 용량 문제가 생겼을 때는 이렇게 보고할 수 있습니다.

현상:
서버 디스크 사용률 증가 알림이 발생했습니다.

확인 내용:
df -h 확인 결과 /var 파일시스템 사용률이 95%로 확인되었습니다.
du -sh /var/* 결과 /var/log 경로 사용량이 가장 크게 확인되었습니다.

원인 추정:
애플리케이션 오류 로그가 반복적으로 기록되며 로그 파일이 증가한 것으로 보입니다.

조치 예정:
현재 로그 증가 원인을 확인 중이며, 서비스 영향 여부 확인 후 로그 보관 정책에 따라 정리 여부를 판단하겠습니다.

현재 상태:
서비스는 기동 중이나 디스크 여유 공간이 부족하여 추가 확인이 필요합니다.

deleted 파일이 의심된다면 이렇게 쓸 수 있습니다.

현상:
파일 삭제 후에도 df -h 기준 디스크 사용량이 감소하지 않는 상태입니다.

확인 내용:
du 결과에서는 큰 파일이 확인되지 않아 deleted 파일 점유 가능성을 확인 중입니다.

조치 예정:
lsof 결과로 파일을 점유 중인 프로세스를 확인한 뒤, 서비스 영향도를 검토하여 재기동 여부를 판단하겠습니다.

inode 문제라면 이렇게 정리할 수 있습니다.

현상:
디스크 용량은 남아 있으나 파일 생성 실패가 발생했습니다.

확인 내용:
df -h 기준 여유 공간은 있으나, df -i 기준 inode 사용률이 높게 확인되었습니다.

원인 추정:
작은 임시 파일 또는 캐시 파일이 대량으로 생성된 가능성이 있습니다.

조치 예정:
파일 생성 위치와 보관 정책을 확인한 뒤 오래된 파일 정리 여부를 검토하겠습니다.

이렇게 정리하면 “디스크 찼습니다”보다 훨씬 실무적으로 보입니다.

디스크 문제 빠른 확인 명령어 정리

상황별로 자주 쓰는 명령어를 정리하면 아래와 같습니다.

전체 디스크 사용량 확인

df -h

inode 사용량 확인

df -i

큰 디렉터리 확인

du -sh /*
du -sh /var/*
du -sh /var/log/*
du -sh /data/*

큰 파일 확인

find /var/log -type f -size +100M -exec ls -lh {} \;
find /data -type f -size +1G -exec ls -lh {} \;

deleted 파일 확인

lsof | grep deleted
lsof +L1

특정 파일 사용 프로세스 확인

lsof /path/to/file

서비스 상태 확인

systemctl status nginx --no-pager
journalctl -u nginx -n 100 --no-pager

명령어를 많이 아는 것보다 중요한 것은 순서입니다.

df로 위치 확인
du로 범위 좁히기
find로 파일 확인
lsof로 사용 여부 확인
로그와 서비스 영향 확인
조치 후 다시 df 확인

정리하면

리눅스 서버에서 디스크 용량 문제가 생겼을 때 가장 먼저 할 일은 삭제가 아닙니다.

먼저 확인해야 합니다.

어느 파일시스템이 찼는지
inode 문제는 아닌지
어떤 디렉터리가 큰지
어떤 파일이 커졌는지
현재 사용 중인 파일인지
로그가 왜 증가했는지
삭제 후 용량이 안 줄어드는 상황인지
서비스에 영향이 있는지

초보 운영자라면 아래 순서를 기억하면 좋습니다.

df -h
df -i
du -sh
find
lsof
journalctl
systemctl status

그리고 가장 중요한 문장은 이것입니다.

디스크가 찼다고 바로 삭제하지 말고, 어디가 왜 찼는지 확인한 뒤 조치해야 합니다.

운영 서버에서는 파일 하나를 지우는 것도 조치입니다.
삭제, 압축, 이동, 서비스 재기동, 디스크 증설 중 어떤 선택이 맞는지는 확인 결과를 보고 판단해야 합니다.

디스크 용량 문제는 단독으로 끝나는 경우도 있지만, 실제 운영에서는 서비스 장애나 접속 장애와 함께 나타나는 경우도 있습니다.
전체적인 리눅스 서버 장애 대응 흐름을 먼저 보고 싶다면 아래 글을 함께 보면 좋습니다.

https://opsnote.tistory.com/69

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

opsnote.tistory.com

서버 접속이 안 될 때 ping, nc, curl, traceroute, nslookup, dig를 어떤 순서로 확인하면 좋은지 보고 싶다면 아래 글을 참고하면 됩니다.
https://opsnote.tistory.com/71

리눅스 서버 접속 장애 확인 순서 총정리

opsnote.tistory.com

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

opsnote — Mon, 10 Aug 2026 00:06:50 +0900

초보 운영자를 위한 리눅스 서버 장애 대응 순서 총정리로 현상 확인, 최근 변경 사항 확인, 리소스 확인, 서비스 상태 확인, 로그 확인, 네트워크 확인, 조치 판단과 재확인 흐름을 설명하는 대표 이미지

리눅스 서버를 운영하다 보면 어느 날 갑자기 이런 말을 듣게 됩니다.

서버가 느립니다.
접속이 안 됩니다.
서비스가 안 뜹니다.
디스크가 가득 찼습니다.
로그가 계속 쌓입니다.
재기동하면 될까요?

처음에는 마음이 급해집니다.

서버 화면을 열고, top을 보고, df -h를 보고, 로그를 열어보다가 어느 순간 이런 생각이 듭니다.

뭘 먼저 봐야 하지?
이거 바로 재기동해도 되나?
파일 하나 지워도 괜찮은 건가?

초보 운영자에게 가장 어려운 부분은 명령어 자체보다 순서입니다.

명령어를 하나씩 아는 것도 중요하지만, 운영 서버에서는 어떤 순서로 확인하고 어느 시점에서 조치할지 판단하는 것이 더 중요합니다.

순서를 잘못 잡으면 장애를 해결하기보다 원인 단서를 먼저 지워버릴 수 있습니다.
로그를 지우거나, 프로세스를 종료하거나, 서버를 재기동한 뒤에는 처음 상태를 다시 확인하기 어려워지는 경우도 있습니다.

이 글은 리눅스 서버에서 문제가 생겼을 때 초보 운영자가 어떤 흐름으로 확인하면 좋은지 정리한 글입니다.
세부 명령어 하나하나를 깊게 설명하기보다는, 장애 상황에서 길을 잃지 않기 위한 전체 점검 순서에 가깝습니다.

서버 장애 대응의 기본 흐름

리눅스 서버 문제가 생겼을 때는 아래 순서로 보는 것이 좋습니다.

현상 확인
영향 범위 확인
최근 변경 사항 확인
서버 리소스 확인
서비스 상태 확인
로그 확인
네트워크 확인
원인 범위 좁히기
조치 전 영향도 확인
조치 후 재확인
보고 정리

처음부터 완벽하게 할 필요는 없습니다.

다만 이 흐름 하나는 기억해두면 좋습니다.

확인 → 판단 → 조치 → 재확인

운영 서버에서 가장 위험한 흐름은 반대입니다.

조치 → 확인 → 당황 → 추가 조치

예를 들어 서버가 느리다고 바로 재기동하고, 디스크가 찼다고 바로 삭제하고, 프로세스가 높다고 바로 kill 하는 식입니다.

이렇게 하면 당장은 뭔가 한 것처럼 보이지만, 실제 원인을 놓칠 수 있습니다.

1. 먼저 “안 된다”를 구체적으로 나눕니다

장애 대응의 시작은 명령어가 아니라 현상 정리입니다.

“서버가 안 됩니다”라는 말은 너무 넓습니다.

아래처럼 나눠서 봐야 합니다.

서버 SSH 접속이 안 되는지
웹 서비스만 안 되는지
특정 URL만 안 되는지
전체 사용자가 느린지
일부 사용자만 느린지
내부망에서만 안 되는지
외부망에서도 안 되는지
특정 시간대에만 발생하는지

예를 들어 “접속이 안 된다”는 말도 여러 가지입니다.

ping 자체가 안 됨
포트가 닫혀 있음
포트는 열려 있는데 HTTP 응답이 이상함
도메인이 잘못된 IP를 바라봄
서비스 프로세스가 내려가 있음
중간 네트워크 구간에서 막힘

처음부터 원인을 단정하면 위험합니다.

ping 안 됨 = 방화벽 문제
CPU 낮음 = 서버 정상
디스크 90% = 파일 삭제
서비스 안 뜸 = 재기동

이런 식으로 바로 결론을 내리면 실제 원인을 놓치기 쉽습니다.

먼저 아래 정도만 정리해도 좋습니다.

현상:
웹 서비스 접속 시 응답 지연 발생

영향 범위:
일부 사용자에게서만 지연 문의 발생

발생 시점:
오전 10시 이후 문의 접수

우선 확인:
서버 리소스, 서비스 상태, 로그, 네트워크, 최근 변경 사항

이렇게 적어두면 이후 확인 과정이 훨씬 덜 흔들립니다.

2. 최근 변경 사항을 먼저 확인합니다

초보 운영자는 서버 상태부터 보는 경우가 많습니다.

물론 top, df -h, systemctl status 같은 명령어도 중요합니다.
하지만 그 전에 꼭 확인해야 할 것이 있습니다.

바로 최근 변경 사항입니다.

배포가 있었는지
설정 파일 변경이 있었는지
인증서 교체가 있었는지
방화벽 정책 변경이 있었는지
DNS 변경이 있었는지
LB나 Ingress 설정 변경이 있었는지
크론, 백업, 배치 시간이 겹치는지
패키지 업데이트가 있었는지

장애는 갑자기 생긴 것처럼 보이지만, 실제로는 변경 작업 이후에 드러나는 경우가 많습니다.

이럴 때는 아래 질문이 도움이 됩니다.

언제부터 발생했는가?
그 직전에 무엇이 바뀌었는가?
전체 서비스가 안 되는가, 일부만 안 되는가?
다른 서버도 같은 증상인가?
재기동, 배포, 설정 변경 이력이 있는가?

명령어 결과만 보면 서버 내부만 보게 됩니다.
하지만 운영 장애는 서버 밖에서 시작되는 경우도 많습니다.

DNS, 방화벽, 로드밸런서, 인증서, 배포 작업, 스토리지, 네트워크까지 같이 봐야 할 때가 있습니다.

3. 서버가 느릴 때는 CPU만 보지 않습니다

서버가 느리면 가장 먼저 CPU를 보게 됩니다.

top

CPU 사용률이 높다면 어떤 프로세스가 CPU를 많이 쓰는지 확인해야 합니다.

ps -eo pid,ppid,cmd,%mem,%cpu --sort=-%cpu | head

하지만 CPU가 낮다고 해서 서버가 정상이라고 바로 판단하면 안 됩니다.

서버가 느린데 CPU 사용률은 낮은 경우도 있습니다.

이럴 때는 Load Average를 같이 봐야 합니다.

uptime

예를 들어 이런 상태라면 다시 봐야 합니다.

CPU 사용률은 낮음
Load Average는 높음
서버 응답은 느림

Load Average는 단순 CPU 사용률이 아니라, 실행 중이거나 대기 중인 작업의 흐름을 보는 데 도움이 됩니다.

CPU가 낮은데 서버가 느릴 때 Load Average를 어떻게 봐야 하는지는 아래 글에서 정리했습니다.

https://opsnote.tistory.com/41

리눅스 서버 CPU 낮다고 정상이라 하지 말고 Load Average까지 확인하는 법

opsnote.tistory.com

또 하나 봐야 할 값이 있습니다.

top에서 보이는 wa입니다.

%Cpu(s):  3.0 us,  2.0 sy, 70.0 id, 25.0 wa

wa는 I/O wait입니다.

쉽게 말하면 CPU가 디스크나 스토리지 응답을 기다리는 시간입니다.

CPU가 낮아 보여도 wa가 높다면 디스크 I/O 대기 때문에 서버가 느릴 수 있습니다.

top에서 wa 값을 확인하는 흐름은 아래 글과 이어집니다.

https://opsnote.tistory.com/42

리눅스 서버 CPU 낮다고 정상이라 하지 말고 top wa 값까지 확인하는 법

opsnote.tistory.com

서버 느림 상황을 보고할 때 CPU, 메모리, 디스크 상태를 어떻게 정리하면 좋은지도 따로 정리했습니다.

https://opsnote.tistory.com/47

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

opsnote.tistory.com

4. 메모리는 used만 보고 판단하지 않습니다

메모리 사용률이 높다고 바로 장애라고 보면 안 됩니다.

리눅스는 사용하지 않는 메모리를 캐시로 활용합니다.
그래서 used가 높아 보여도 실제로는 여유가 있을 수 있습니다.

기본 확인 명령어는 아래입니다.

free -m

여기서 초보 운영자가 꼭 봐야 할 값은 available입니다.

used
free
buff/cache
available

used만 보고 “메모리가 부족하다”고 판단하면 잘못 볼 수 있습니다.

메모리 상태는 아래처럼 보는 것이 좋습니다.

available이 충분한지
Swap이 계속 증가하는지
OOM 관련 로그가 있는지
특정 프로세스가 메모리를 과도하게 쓰는지
서비스 영향이 실제로 있는지

메모리 used와 available을 구분하는 방법은 아래 글에서 정리했습니다.

https://opsnote.tistory.com/44

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

opsnote.tistory.com

Swap도 마찬가지입니다.

Swap 사용량이 올라갔다고 바로 재기동할 필요는 없습니다.

free -m
swapon --show

Swap이 언제부터 올라갔는지, 계속 증가하는지, 서비스 응답에 영향이 있는지를 같이 봐야 합니다.

https://opsnote.tistory.com/43

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

opsnote.tistory.com

5. 디스크가 찼을 때는 바로 삭제하지 않습니다

디스크 용량 알림은 초보 운영자를 가장 긴장하게 만드는 알림 중 하나입니다.

/ 사용률 90%
/var 사용률 95%
No space left on device
파일 생성 실패
로그 기록 실패

이때 바로 큰 파일을 찾아서 삭제하고 싶어질 수 있습니다.

하지만 운영 서버에서는 바로 삭제하면 안 됩니다.

먼저 어느 파일시스템이 찼는지 확인해야 합니다.

df -h

df -h에서는 Use%만 보면 안 됩니다.

아래 항목을 같이 봐야 합니다.

Filesystem
Size
Used
Avail
Use%
Mounted on

특히 Mounted on이 중요합니다.

/가 찼는지, /var가 찼는지, /tmp가 찼는지, /data가 찼는지에 따라 확인 순서가 달라집니다.

디스크 사용률 90%를 넘겼을 때 처음 확인하는 흐름은 아래 글에서 정리했습니다.

https://opsnote.tistory.com/1

리눅스 서버 디스크 용량 90% 넘었을 때 바로 삭제하지 말고 확인하는 법

opsnote.tistory.com

df -h 결과에서 Use%만 보면 안 되는 이유는 아래 글과 함께 보면 좋습니다.

https://opsnote.tistory.com/2

리눅스 서버 df -h 결과, Use%만 보면 안 되는 이유와 확인 순서

opsnote.tistory.com

용량은 남아 있는데 파일 생성이 안 되는 경우도 있습니다.
이때는 inode 문제일 수 있습니다.

df -i

inode 문제는 초보 운영자가 놓치기 쉬운 부분입니다.

https://opsnote.tistory.com/66

리눅스 서버 용량은 남았는데 파일 생성이 안 될 때 df -i로 inode 확인하는 법

opsnote.tistory.com

/tmp가 찼을 때도 바로 삭제하면 안 됩니다.
임시 파일처럼 보여도 현재 서비스나 배치 작업이 사용 중일 수 있습니다.

https://opsnote.tistory.com/67

리눅스 서버 /tmp 용량이 찼을 때 바로 삭제하지 말고 확인하는 법

opsnote.tistory.com

/var가 찼을 때는 더 조심해야 합니다.
로그, 캐시, spool, 서비스 데이터가 섞여 있을 수 있습니다.

https://opsnote.tistory.com/68

리눅스 서버 /var 용량이 찼을 때 위험한 이유와 안전한 확인 순서

opsnote.tistory.com

6. df와 du 결과가 다르면 deleted 파일을 의심합니다

디스크 문제를 확인하다 보면 이런 상황이 있습니다.

df -h에서는 사용량이 높음
du -sh로 보면 큰 파일이 안 보임
파일을 삭제했는데 용량이 줄지 않음

이럴 때는 삭제된 파일을 프로세스가 계속 잡고 있을 수 있습니다.

확인 명령어는 아래입니다.

lsof | grep deleted

환경에 따라 아래 명령어도 사용할 수 있습니다.

lsof +L1

이 상황에서 서버를 재기동하면 용량이 줄어들 수는 있습니다.

하지만 어떤 프로세스가 어떤 파일을 잡고 있었는지 확인하지 못하고 넘어가게 됩니다.

운영에서는 “재기동하면 해결된다”보다 “왜 용량이 안 줄었는지 확인했다”가 더 중요합니다.

df와 du 결과가 다르게 보일 때 확인하는 흐름은 아래 글과 이어집니다.

https://opsnote.tistory.com/65

리눅스 서버 df와 du 결과가 다르게 보일 때 deleted 파일부터 확인하는 법

opsnote.tistory.com

7. 로그가 커질 때는 비우기 전에 원인을 봅니다

로그 파일이 계속 커지면 디스크 문제가 생길 수 있습니다.

du -sh /var/log/*

큰 로그 파일은 아래처럼 찾을 수 있습니다.

find /var/log -type f -size +100M -exec ls -lh {} \;

하지만 로그가 크다고 바로 비우면 안 됩니다.

로그는 단순한 파일이 아니라 장애 원인을 알려주는 흔적입니다.
비유하자면, 바닥에 찍힌 발자국을 지우기 전에 어디서 왔는지 먼저 봐야 합니다.

먼저 아래를 확인합니다.

어떤 서비스 로그인지
현재도 계속 쓰고 있는지
오류가 반복되고 있는지
logrotate 대상인지
장애 분석에 필요한 로그인지
보관 정책이 있는지

로그 파일이 계속 커질 때 확인하는 순서는 아래 글에 정리했습니다.

https://opsnote.tistory.com/7

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

opsnote.tistory.com

8. 서비스가 안 뜰 때는 status부터 봅니다

서비스가 안 뜨거나 접속이 안 될 때 바로 restart부터 누르면 안 됩니다.

먼저 상태를 봐야 합니다.

systemctl status nginx --no-pager

서비스 이름은 환경마다 다릅니다.

systemctl status httpd --no-pager
systemctl status mariadb --no-pager
systemctl status docker --no-pager

systemctl status에서는 아래를 봅니다.

Active 상태
Main PID
최근 에러 메시지
실패 코드
마지막 실행 로그

서비스가 안 뜰 때 systemctl status를 먼저 봐야 하는 이유는 아래 글에서 정리했습니다.

https://opsnote.tistory.com/27

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

opsnote.tistory.com

실패한 서비스를 한 번에 확인하려면 아래 명령어도 사용할 수 있습니다.

systemctl --failed

https://opsnote.tistory.com/32

리눅스 서버에서 실패한 서비스 한 번에 확인하는 systemctl --failed 사용법

opsnote.tistory.com

서비스를 재기동해야 한다면 start, stop, restart 차이를 알고 있어야 합니다.

https://opsnote.tistory.com/28

리눅스 서버 systemctl start stop restart 차이와 restart 바로 누르면 안 되는 이유

opsnote.tistory.com

재기동 후에는 정상 기동 여부도 반드시 확인해야 합니다.

https://opsnote.tistory.com/29

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

opsnote.tistory.com

서버 재기동 후 서비스가 자동으로 안 뜨는 문제는 enable 설정과 관련될 수 있습니다.

https://opsnote.tistory.com/30

리눅스 서버 재기동 후 서비스가 자동으로 안 뜰 때 systemctl enable disable 차이 확인하는 법

opsnote.tistory.com

9. 로그 확인은 tail, less, journalctl을 나눠서 봅니다

서비스 상태를 봤다면 로그를 확인합니다.

최근 로그만 빠르게 볼 때는 tail을 사용합니다.

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

큰 로그 파일을 열 때는 less가 더 안전합니다.

less /var/log/nginx/error.log

실시간으로 로그를 따라갈 때는 tail -f를 사용할 수 있습니다.

tail -f /var/log/nginx/error.log

다만 처음부터 tail -f만 보고 있으면 전체 흐름을 놓칠 수 있습니다.

먼저 최근 에러를 보고, 필요한 경우 실시간으로 따라가는 것이 좋습니다.

tail과 less 사용 흐름은 아래 글에서 정리했습니다.

https://opsnote.tistory.com/20

리눅스 서버 로그 확인할 때 cat부터 치지 말고 tail과 less로 안전하게 보는 법

opsnote.tistory.com

실시간 로그 확인은 아래 글과 이어서 보면 좋습니다.

https://opsnote.tistory.com/21

리눅스 서버 장애 났을 때 tail -f로 실시간 로그 확인하는 법

opsnote.tistory.com

systemd 서비스 로그는 journalctl로 확인합니다.

journalctl -u nginx -n 100 --no-pager

커널 메시지는 아래처럼 볼 수 있습니다.

journalctl -k -n 100 --no-pager

journalctl 확인 흐름은 아래 글에 정리했습니다.

https://opsnote.tistory.com/33

리눅스 서버 systemctl status만 보지 말고 journalctl로 서비스 로그 확인하는 법

opsnote.tistory.com

10. 로그가 많을 때는 grep으로 좁혀봅니다

로그가 많을 때는 필요한 키워드부터 찾습니다.

grep -i "error" /var/log/nginx/error.log

타임아웃 관련 로그를 찾을 수도 있습니다.

grep -i "timeout" /var/log/nginx/error.log

에러 앞뒤 흐름을 같이 보려면 -C 옵션이 유용합니다.

grep -C 5 -i "error" /var/log/nginx/error.log

불필요한 로그를 제외하고 보고 싶을 때는 grep -v를 사용할 수 있습니다.

grep -v "healthcheck" /var/log/nginx/access.log

로그에서 에러를 찾는 기본 흐름은 아래 글에서 정리했습니다.

https://opsnote.tistory.com/24

리눅스 서버 로그에서 에러 찾을 때 grep만 믿지 말고 앞뒤 흐름까지 확인하는 법

리눅스 서버에서 장애가 발생했을 때 로그 파일을 열어보면 생각보다 내용이 많습니다. 처음에는 tail이나 less로 로그를 확인하지만, 로그가 길면 눈으로 ERROR, Exception, timeout 같은 키워드를 찾는

opsnote.tistory.com

에러 앞뒤 로그를 같이 보는 방법은 아래 글과 이어집니다.

https://opsnote.tistory.com/25

리눅스 서버 로그에서 에러 한 줄만 보지 말고 grep -C로 앞뒤 흐름 확인하는 법

리눅스 서버에서 장애가 발생했을 때 로그에서 ERROR 한 줄을 찾으면 뭔가 원인을 찾은 것처럼 느껴질 때가 있습니다.하지만 실제 운영 환경에서는 에러 한 줄만 보고 바로 판단하면 놓치는 부분

opsnote.tistory.com

불필요한 로그를 제외하는 방법은 아래 글에 정리했습니다.

https://opsnote.tistory.com/26

리눅스 서버 로그에서 정상 로그가 너무 많을 때 grep -v로 제외하고 확인하는 법

리눅스 서버에서 장애 로그를 확인하다 보면 로그가 너무 많이 찍혀서 오히려 보기 어려울 때가 있습니다.에러를 찾으려고 로그를 열었는데 INFO 로그, health check 로그, access log, 정상 요청 로그가

opsnote.tistory.com

11. 접속 장애는 ping 하나로 판단하지 않습니다

서버 접속이 안 될 때 ping부터 확인하는 경우가 많습니다.

ping 192.0.2.10

하지만 ping은 ICMP 응답을 보는 도구입니다.
웹 서비스나 애플리케이션 포트가 정상인지까지 알려주지는 않습니다.

예를 들어 ping은 되는데 웹 서비스가 안 될 수 있습니다.

이때는 포트를 확인해야 합니다.

nc -vz 192.0.2.10 443

HTTP 응답을 확인하려면 curl을 사용합니다.

curl -I https://example.com

ping은 되는데 서비스 접속이 안 될 때 확인하는 흐름은 아래 글에서 정리했습니다.

https://opsnote.tistory.com/34

리눅스 서버 ping 된다고 정상이라 하지 말고 포트와 curl까지 확인하는 법

opsnote.tistory.com

ping이 안 될 때도 바로 방화벽 문제로 단정하면 안 됩니다.

https://opsnote.tistory.com/35

리눅스 서버 ping 안 된다고 방화벽 문제라 하지 말고 포트와 curl까지 확인하는 법

opsnote.tistory.com

포트가 열려 있는지 확인하는 nc 명령어는 아래 글에서 정리했습니다.

https://opsnote.tistory.com/36

리눅스 서버 포트 열렸는지 nc로 확인할 때 ping만 보지 말고 TCP 접속까지 확인하는 법

opsnote.tistory.com

curl과 nc는 역할이 다릅니다.
포트 확인과 HTTP 응답 확인을 구분해야 합니다.

https://opsnote.tistory.com/38

리눅스 서버 접속 확인할 때 curl과 nc 차이, 포트와 HTTP 응답을 구분하는 법

opsnote.tistory.com

12. 네트워크 경로와 DNS도 확인합니다

서비스 접속 장애는 서버 내부 문제가 아닐 수도 있습니다.

중간 네트워크 구간에서 막히는지 확인하려면 traceroute 또는 tracepath를 사용할 수 있습니다.

traceroute example.com

환경에 따라 아래 명령어를 사용할 수도 있습니다.

tracepath example.com

traceroute 결과는 단독으로 판단하면 안 됩니다.
중간 장비가 ICMP 응답을 제한할 수 있기 때문입니다.

그래서 ping, nc, curl 결과와 함께 봐야 합니다.

https://opsnote.tistory.com/37

리눅스 서버 접속 안 될 때 traceroute로 어느 구간에서 막히는지 확인하는 법

opsnote.tistory.com

도메인 문제도 자주 헷갈리는 부분입니다.

도메인이 어떤 IP를 바라보는지 확인하려면 nslookup을 사용할 수 있습니다.

nslookup example.com

DNS 응답을 더 자세히 보고 싶다면 dig를 사용합니다.

dig example.com
dig A example.com
dig CNAME example.com

DNS 문제는 서버 애플리케이션이 정상이어도 장애처럼 보일 수 있습니다.

아래처럼 나눠서 봐야 합니다.

도메인이 IP를 못 찾는지
잘못된 IP를 바라보는지
내부 DNS와 외부 DNS 응답이 다른지
TTL 때문에 변경 반영이 늦는지
LB나 Ingress 앞단 주소가 맞는지

nslookup 확인 흐름은 아래 글에서 정리했습니다.

https://opsnote.tistory.com/39

리눅스 서버 도메인 안 된다고 서버부터 보지 말고 nslookup으로 DNS부터 확인하는 법

opsnote.tistory.com

dig로 DNS 응답을 자세히 확인하는 방법은 아래 글과 이어집니다.

https://opsnote.tistory.com/40

리눅스 서버 nslookup만 보지 말고 dig로 DNS 응답까지 확인하는 법

opsnote.tistory.com

13. 재기동은 마지막에 가까운 카드입니다

운영 서버에서 재기동은 쉬운 버튼처럼 보입니다.

하지만 실제로는 꽤 큰 조치입니다.

재기동 전에 최소한 아래는 확인해야 합니다.

현재 접속자 영향
서비스 이중화 여부
서비스 재기동인지 서버 전체 재기동인지
최근 로그 확보 여부
디스크, 메모리, CPU 상태
재기동 후 자동 기동 여부
담당자 또는 고객 공지 필요 여부
롤백 가능 여부

서비스만 재기동할지, 서버 전체를 재기동할지도 구분해야 합니다.

systemctl restart nginx

서버 전체 재기동은 더 신중해야 합니다.

reboot

서버 재기동 전 확인해야 할 체크리스트는 아래 글에 정리했습니다.

https://opsnote.tistory.com/19

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

opsnote.tistory.com

운영에서는 “재기동했습니다”보다 “재기동 전 원인 단서를 확인했고, 재기동 후 정상 확인했습니다”가 더 중요합니다.

14. 조치 전에는 영향도를 먼저 생각합니다

원인이 어느 정도 보이더라도 바로 조치하면 안 됩니다.

아래 작업들은 모두 운영 영향이 있을 수 있습니다.

서비스 재기동
서버 재기동
프로세스 kill
로그 삭제
권한 변경
설정 파일 수정
방화벽 정책 변경
DNS 변경
패키지 설치

조치 전에는 최소한 아래를 생각해야 합니다.

이 조치가 서비스에 영향을 주는가?
되돌릴 수 있는가?
작업 전 백업이 필요한가?
공지나 승인 절차가 필요한가?
장애 원인 로그를 먼저 확보했는가?

설정 파일을 수정해야 한다면 원본을 먼저 백업하는 습관이 필요합니다.

cp nginx.conf nginx.conf.bak_$(date +%Y%m%d_%H%M%S)

작은 습관 하나가 큰 사고를 막아줍니다.

15. 조치 후에는 반드시 재확인합니다

조치를 했다고 끝난 것이 아닙니다.

반드시 다시 확인해야 합니다.

systemctl status nginx --no-pager
journalctl -u nginx -n 100 --no-pager
curl -I https://example.com
df -h
free -m
uptime

확인할 내용은 아래와 같습니다.

서비스가 정상 기동됐는지
에러 로그가 계속 발생하는지
접속이 정상인지
디스크 사용률이 내려갔는지
CPU, 메모리, Load Average가 안정됐는지
사용자 영향이 해소됐는지

운영에서는 “조치했습니다”보다 “조치 후 정상 확인했습니다”가 더 중요합니다.

16. 보고는 짧고 정확하게 정리합니다

장애 상황에서는 보고도 중요합니다.

처음부터 길게 쓰려고 하면 오히려 헷갈립니다.

아래 흐름으로 정리하면 좋습니다.

현상:
확인 내용:
원인 추정:
조치 내용:
현재 상태:
추가 확인 필요:

예를 들어 서버가 느린 상황이라면 이렇게 쓸 수 있습니다.

현상:
웹 서비스 응답 지연 문의가 접수되었습니다.

확인 내용:
서버 접속은 가능하며, CPU 사용률은 높지 않으나 Load Average와 wa 값이 함께 높게 확인되었습니다.
디스크 I/O 대기 가능성이 있어 관련 프로세스와 로그를 확인했습니다.

원인 추정:
백업 작업 시간대와 증상 발생 시간이 일부 겹치는 것으로 확인됩니다.

조치 내용:
현재 백업 작업 종료 여부 및 서비스 로그를 추가 확인 중입니다.

현재 상태:
서비스는 응답 중이나 일부 요청에서 지연이 확인됩니다.

추가 확인 필요:
스토리지 응답 지연 여부와 백업 작업 영향도를 추가 확인하겠습니다.

이렇게 정리하면 “서버 느립니다”보다 훨씬 실무적으로 보입니다.

장애 상황별 빠른 확인 순서

마지막으로 상황별 확인 순서를 짧게 정리해보겠습니다.

서버가 느릴 때

uptime
top
free -m
df -h
ps -eo pid,stat,cmd | head
journalctl -xe --no-pager

확인할 것:

Load Average
CPU 사용률
wa 값
메모리 available
Swap
디스크 사용률
D 상태 프로세스
서비스 로그

디스크가 찼을 때

df -h
df -i
du -sh /*
du -sh /var/log/*
lsof | grep deleted

확인할 것:

어느 파일시스템이 찼는지
inode가 부족한지
큰 파일이 어디에 있는지
삭제된 파일을 프로세스가 잡고 있는지
로그가 비정상적으로 증가하는지

서비스가 안 뜰 때

systemctl status nginx --no-pager
journalctl -u nginx -n 100 --no-pager
systemctl --failed

확인할 것:

Active 상태
실패 코드
최근 에러 로그
설정 변경 여부
포트 충돌 여부
권한 문제 여부

접속이 안 될 때

ping 192.0.2.10
nc -vz 192.0.2.10 443
curl -I https://example.com
traceroute example.com
nslookup example.com
dig example.com

확인할 것:

서버 접근 가능 여부
포트 오픈 여부
HTTP 응답 여부
네트워크 경로
DNS 응답
도메인이 바라보는 IP

장애 상황별 실제 점검 사례

기본적인 장애 대응 순서를 익혔다면 실제 상황에서는 어떻게 적용하는지도 살펴볼 필요가 있습니다.

서버 장애는 비슷한 증상으로 시작하더라도 원인은 다를 수 있습니다. 그래서 상황별로 어떤 부분부터 확인하면 좋은지 따로 정리했습니다.

디스크 용량이 90%를 넘었을 때

사용률이 높은 파일시스템을 확인하고, 로그 증가나 삭제된 파일, inode 문제 등을 구분해 점검하는 과정입니다.

https://opsnote.tistory.com/72

리눅스 서버 디스크 용량 90% 알림을 받았을 때 실제 점검 흐름 정리

opsnote.tistory.com

서비스가 갑자기 실행되지 않을 때

systemctl status와 journalctl로 서비스 상태와 오류 기록을 확인하고 원인을 좁혀가는 과정입니다.

https://opsnote.tistory.com/73

리눅스 서버 서비스가 안 뜰 때 systemctl status와 journalctl로 원인 좁히는 과정

opsnote.tistory.com

ping은 되는데 사이트가 열리지 않을 때

ping 응답만으로 정상이라고 판단하지 않고 포트 연결과 HTTP 응답을 확인하는 방법입니다.

https://opsnote.tistory.com/74

ping은 되는데 사이트가 안 열릴 때 nc와 curl로 확인하는 실제 점검 흐름

리눅스 서버나 웹 서비스를 운영하다 보면 이런 말을 들을 때가 있습니다.서버는 살아 있는 것 같은데 사이트가 안 열립니다.ping은 됩니다.그런데 브라우저에서는 접속이 안 됩니다.처음에는 헷

opsnote.tistory.com

서버가 느린데 CPU 사용률은 낮을 때

CPU 사용률 외에도 Load Average와 I/O wait를 함께 확인해야 하는 이유를 정리했습니다.

https://opsnote.tistory.com/75

리눅스 서버가 느린데 CPU는 낮을 때 Load Average와 wa로 확인하는 실제 점검 흐름

리눅스 서버를 운영하다 보면 이런 말을 들을 때가 있습니다.서버가 느립니다.화면이 늦게 뜹니다.요청 응답이 평소보다 오래 걸립니다.처음에는 CPU부터 보게 됩니다.top을 열어봤는데 CPU 사용

opsnote.tistory.com

OOM으로 서비스가 종료됐는지 확인할 때

커널 OOM 로그와 종료된 프로세스, 서비스 중단 시각을 비교해 원인을 판단하는 과정입니다.

https://opsnote.tistory.com/76

리눅스 서버에서 OOM으로 서비스가 죽었는지 확인하는 실제 점검 흐름

운영 중인 리눅스 서버에서 서비스가 갑자기 내려갔다는 연락을 받으면 가장 먼저 떠오르는 대응 중 하나가 재시작입니다.systemctl restart 서비스명 서비스를 빨리 살려야 하는 상황에서는 필요한

opsnote.tistory.com

장애 대응에서는 모든 명령어를 외우는 것보다 현재 상황에서 어떤 정보를 먼저 확인해야 하는지 판단하는 것이 중요합니다.

저도 운영 중 문제가 발생하면 확인 → 판단 → 조치 → 재확인 순서로 접근하려고 합니다.

무엇보다 서비스에 영향을 줄 수 있는 조치부터 실행하지 않고, 현재 상태와 로그를 먼저 확보하는 습관이 중요합니다.

정리하면

리눅스 서버 장애 대응에서 중요한 것은 명령어를 많이 외우는 것이 아닙니다.

문제가 생겼을 때 어떤 순서로 확인하고, 어디서 멈춰서 판단할지 아는 것이 더 중요합니다.

초보 운영자라면 아래 순서를 먼저 기억해도 충분합니다.

현상 확인
최근 변경 사항 확인
리소스 확인
서비스 상태 확인
로그 확인
네트워크 확인
조치 전 영향도 확인
조치 후 재확인
보고 정리

그리고 가장 중요한 문장은 이것입니다.

운영 서버에서는 바로 조치하지 말고, 확인 → 판단 → 조치 → 재확인 순서로 움직여야 합니다.

이 블로그에서는 리눅스 서버 운영 중 자주 만나는 상황을 하나씩 나눠서 정리하고 있습니다.

리눅스 서버 장애 대응은 한 번에 외우기보다, 상황별로 확인 순서를 나눠서 보는 것이 좋습니다.
전체 흐름은 이 글에서 잡고, 디스크 용량 문제와 접속 장애처럼 자주 만나는 상황은 아래 글에서 따로 확인하면 됩니다.

디스크 용량 문제가 생겼을 때 df -h, du, df -i, lsof deleted 확인 순서를 보고 싶다면 아래 글을 함께 보면 좋습니다.
https://opsnote.tistory.com/70

리눅스 서버 디스크 용량 문제 확인 순서 총정리

opsnote.tistory.com

접속 장애 상황에서 ping, nc, curl, DNS 확인 순서를 보고 싶다면 아래 글을 참고하면 됩니다.
https://opsnote.tistory.com/71

리눅스 서버 접속 장애 확인 순서 총정리

opsnote.tistory.com

리눅스 서버 /var 용량이 찼을 때 위험한 이유와 안전한 확인 순서

opsnote — Sun, 12 Jul 2026 13:02:30 +0900

리눅스 서버에서 /var 용량이 찼을 때 로그, 캐시, 스풀, 서비스 데이터를 구분하고 바로 삭제하지 않고 안전하게 확인하는 방법을 설명하는 대표 이미지

리눅스 서버에서 /var 용량이 가득 차면 단순히 디스크 공간이 부족한 문제로 끝나지 않을 수 있습니다. /var에는 로그, 캐시, 스풀, 패키지 데이터, 애플리케이션 상태 파일이 쌓이는 경우가 많아서 서버 운영 중 /var가 차면 로그 기록 실패, 서비스 기동 실패, 배치 오류, 패키지 설치 실패 같은 장애로 이어질 수 있습니다.

이번 글에서는 /var 용량 부족 알림이 떴을 때 바로 삭제하지 않고, 어떤 경로가 커졌는지 구분한 뒤 안전하게 확인하는 순서를 정리해보겠습니다.

/var에는 뭐가 쌓일까?

/var는 이름 그대로 변하는 데이터가 많이 쌓이는 경로입니다.

대표적으로 이런 것들이 있습니다.

/var/log      → 시스템 로그, 서비스 로그
/var/cache    → 패키지 캐시, 애플리케이션 캐시
/var/spool    → 메일, 프린트, 작업 큐
/var/tmp      → 재부팅 후에도 남을 수 있는 임시파일
/var/lib      → 서비스 상태 데이터, DB성 데이터, 컨테이너 데이터

그래서 /var가 꽉 차면 “로그 하나 지우면 되겠지”로 보기 어렵습니다.

어떤 서비스가 어떤 용도로 쓰는 공간인지 먼저 확인해야 합니다.

특히 /var/lib는 더 조심해야 합니다.
이 경로 아래에는 DB 데이터, 컨테이너 데이터, 패키지 관리 데이터, kubelet 데이터처럼 서비스 운영에 직접 영향을 주는 파일이 있을 수 있습니다.

가상의 운영 상황 예시

예를 들어 운영 서버에서 이런 알림이 발생했다고 가정해보겠습니다.

[상황]
- 디스크 사용률 알림 발생
- df -h /var 결과 Use% 92% 확인
- 애플리케이션 로그 기록 지연 발생
- 패키지 설치 작업 실패
- /var/log 또는 /var/lib 증가 의심

이 상황에서 초보 운영자는 이렇게 생각할 수 있습니다.

/var가 찼으니까 /var/log만 지우면 되지 않을까?

하지만 /var는 로그만 있는 공간이 아닙니다.

/var/log, /var/cache, /var/spool, /var/lib는 각각 성격이 다릅니다.
따라서 먼저 어떤 하위 경로가 커졌는지 확인해야 합니다.

초보 운영자가 하기 쉬운 실수

/var가 90% 이상 찼다고 보면 바로 이런 명령어를 떠올리기 쉽습니다.

rm -rf /var/log/*
rm -rf /var/cache/*

하지만 운영 서버에서는 매우 조심해야 합니다.

로그는 장애 원인 분석에 필요할 수 있고, /var/lib 아래에는 서비스 데이터가 있을 수 있습니다.

특히 Docker, containerd, DB, 패키지 관리 도구, Kubernetes kubelet이 /var 아래 데이터를 쓰는 경우도 있습니다.

그래서 /var는 바로 삭제가 아니라, 무엇이 커졌는지 먼저 확인하는 공간으로 봐야 합니다.

1단계. df -h로 /var가 별도 파일시스템인지 확인하기

먼저 /var가 실제로 어느 파일시스템에 있는지 확인합니다.

df -h /var

예시입니다.

Filesystem      Size  Used Avail Use% Mounted on
/dev/sda3        30G   27G  3.0G  90% /var

여기서 /var가 별도 마운트라면 /var 내부를 확인하면 됩니다.

반대로 /var가 /에 포함되어 있다면 루트 파일시스템 전체 용량 문제로 이어질 수 있습니다.

전체 파일시스템도 함께 봅니다.

df -h

Use%만 보지 말고 Mounted on을 같이 봐야 합니다.

같은 90%라도 /var가 찬 것인지, /가 찬 것인지, /data가 찬 것인지에 따라 대응 방향이 달라집니다.

df -h 결과를 볼 때는 Use%만 보면 놓치는 경우가 있습니다. 어느 파일시스템이 찼는지에 따라 대응 순서가 달라지기 때문에 Mounted on을 함께 확인하는 습관이 중요합니다.

2026.05.02 - [리눅스] - 리눅스 서버 df -h 결과, Use%만 보면 안 되는 이유와 확인 순서

리눅스 서버 df -h 결과, Use%만 보면 안 되는 이유와 확인 순서

opsnote.tistory.com

2단계. /var 안에서 큰 디렉터리 찾기

이제 /var 안에서 어디가 큰지 봅니다.

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

예시입니다.

500M    /var/cache
1.2G    /var/spool
8.0G    /var/log
15G     /var/lib
25G     /var

여기서 /var/log가 큰지, /var/lib가 큰지에 따라 확인 방향이 완전히 달라집니다.

/var/log   → 로그 증가 확인
/var/cache → 패키지 캐시, 애플리케이션 캐시 확인
/var/spool → 큐 적체 확인
/var/tmp   → 오래된 임시파일 확인
/var/lib   → 서비스 데이터, 컨테이너, DB 데이터 확인

/var/log가 크면 로그를 봐야 하고, /var/lib가 크면 서비스 데이터, 컨테이너, DB 관련 데이터를 의심해야 합니다.

이 단계에서 중요한 건 삭제가 아니라 분류입니다.

/var 문제는 /tmp처럼 임시파일만 보는 방식으로 접근하면 위험합니다. /tmp 용량이 찼을 때 안전하게 확인하는 흐름은 아래 글에서 따로 정리했습니다.

https://opsnote.tistory.com/67

리눅스 서버 /tmp 용량 찼을 때 당황해서 바로 삭제하지 마세요 - 안전한 임시 파일 확인 및 조치

리눅스 서버에서 /tmp 용량이 가득 차면 파일 업로드 실패, 압축 해제 실패, 배치 오류, 애플리케이션 임시파일 생성 실패 같은 문제가 생길 수 있습니다. 하지만 /tmp가 꽉 찼다고 해서 바로 rm -rf /

opsnote.tistory.com

3단계. /var/log가 크면 로그부터 확인하기

로그가 큰 경우에는 어떤 로그가 커졌는지 확인합니다.

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

큰 파일을 직접 찾을 수도 있습니다.

find /var/log -xdev -type f -size +500M -ls 2>/dev/null

예시입니다.

/var/log/nginx/access.log
/var/log/messages
/var/log/example-app/app.log

여기서 바로 삭제하지 말고, 왜 커졌는지 먼저 봐야 합니다.

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

로그가 갑자기 커졌다면 같은 오류가 반복 출력되고 있을 수 있습니다.

예를 들면 이런 상황입니다.

- 애플리케이션 오류가 초당 반복 출력됨
- 외부 연동 실패 로그가 계속 쌓임
- 접근 로그가 비정상적으로 증가함
- 배치 실패 로그가 반복됨
- 디버그 로그가 운영 환경에서 켜져 있음

이런 경우 단순히 로그 파일만 비워도, 원인이 남아 있으면 다시 빠르게 커질 수 있습니다.

4단계. 로그 파일은 삭제보다 로테이션 상태 확인하기

로그가 크다고 바로 삭제하면 안 됩니다.

먼저 logrotate 설정을 확인합니다.

ls -l /etc/logrotate.d/

특정 로그가 로테이션 대상인지 확인합니다.

grep -R "/var/log/example-app" /etc/logrotate.d/

로테이션이 안 되어 있으면 로그가 계속 커질 수 있습니다.

운영 서버에서는 직접 삭제보다 이런 방향으로 봐야 합니다.

- 로그가 왜 커졌는지 확인
- logrotate 설정이 있는지 확인
- 보관 정책 확인
- 필요하면 로그 백업 후 정리
- 서비스가 잡고 있는 deleted 파일 여부 확인

deleted 파일도 같이 확인합니다.

lsof | grep deleted | grep /var/log

로그를 삭제했는데 용량이 줄지 않는다면 프로세스가 파일을 아직 잡고 있을 수 있습니다.

이때 바로 kill -9 하거나 reboot 하기보다, 어떤 프로세스가 어떤 파일을 잡고 있는지 먼저 확인해야 합니다.

/var 용량 문제는 로그 파일 증가와 자주 연결됩니다. 로그를 삭제했는데도 용량이 줄지 않거나 df와 du 결과가 다르게 보인다면 deleted 파일을 함께 확인해야 합니다.

https://opsnote.tistory.com/65

리눅스 서버 df와 du 결과가 다르게 보일 때 deleted 파일부터 확인하는 법

opsnote.tistory.com

5단계. /var/cache가 크면 패키지 캐시 확인하기

/var/cache가 크다면 패키지 캐시나 애플리케이션 캐시가 쌓였을 수 있습니다.

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

RHEL, Rocky, CentOS 계열이라면 패키지 캐시가 있을 수 있습니다.

du -sh /var/cache/dnf 2>/dev/null
du -sh /var/cache/yum 2>/dev/null

캐시 정리는 비교적 안전한 편인 경우도 있지만, 운영 기준이 있을 수 있으니 확인 후 진행해야 합니다.

예를 들어 dnf 캐시 정리는 아래처럼 할 수 있습니다.

dnf clean all

다만 이것도 운영 서버에서는 패키지 관리 정책과 영향 여부를 확인한 뒤 실행하는 것이 좋습니다.

특정 애플리케이션 캐시라면 더 조심해야 합니다.
서비스가 캐시 파일을 계속 참조 중일 수 있고, 캐시를 삭제한 뒤 재생성 과정에서 순간적으로 부하가 생길 수 있습니다.

6단계. /var/spool이 크면 큐 적체를 의심하기

/var/spool은 작업 대기열 성격의 파일이 쌓일 수 있는 곳입니다.

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

메일 큐, 프린트 큐, cron 관련 파일 등이 있을 수 있습니다.

메일 큐가 많다면 단순 삭제보다 왜 발송이 안 되고 쌓였는지 봐야 합니다.

- 메일 발송 실패
- DNS 문제
- 외부 SMTP 연결 실패
- 작업 큐 처리 지연
- 배치 실패

스풀은 “쌓인 결과”일 뿐이고, 진짜 원인은 처리 실패일 수 있습니다.

따라서 /var/spool이 크다면 파일을 지우기보다 큐가 왜 처리되지 않는지 확인해야 합니다.

7단계. /var/lib가 크면 더 조심하기

/var/lib가 크다면 특히 조심해야 합니다.

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

여기에는 서비스 데이터가 들어가는 경우가 많습니다.

예를 들면 이런 경로입니다.

/var/lib/docker
/var/lib/containerd
/var/lib/mysql
/var/lib/pgsql
/var/lib/rpm
/var/lib/kubelet

이 경로들은 함부로 삭제하면 서비스 장애로 바로 이어질 수 있습니다.

특히 /var/lib/docker, /var/lib/containerd, /var/lib/mysql 같은 경로는 운영 데이터일 수 있습니다.

아래 명령어는 절대 가볍게 실행하면 안 됩니다.

rm -rf /var/lib/*

/var/lib는 “용량 많이 쓰니까 지워도 되는 곳”이 아니라, 서비스가 상태를 저장하는 공간으로 보는 게 안전합니다.

/var/lib가 큰 경우에는 해당 서비스의 정리 방식으로 접근해야 합니다.

Docker 이미지 정리 → docker 명령어 기준으로 검토
containerd 데이터 정리 → 컨테이너 런타임 기준으로 검토
DB 데이터 증가 → DB 내부 용량과 테이블 확인
kubelet 데이터 증가 → Pod, 이미지, 로그 정책 확인
패키지 DB → 패키지 관리 도구 상태 확인

8단계. 최근에 커진 파일 확인하기

최근에 갑자기 /var가 찼다면 최근 수정된 큰 파일을 확인합니다.

find /var -xdev -type f -mtime -1 -size +100M -ls 2>/dev/null

최근 1시간 안에 생성 또는 수정된 파일을 볼 수도 있습니다.

find /var -xdev -type f -mmin -60 -ls 2>/dev/null | head

이렇게 보면 갑자기 커지는 로그나 임시 파일을 찾는 데 도움이 됩니다.

최근 파일이 계속 늘어난다면 단순 정리보다 원인 확인이 먼저입니다.

- 어떤 프로세스가 만들고 있는지
- 특정 오류가 반복되는지
- 배치가 실패하고 있는지
- 로그 레벨이 과도하게 설정됐는지
- 외부 연동 실패로 큐가 쌓이는지

9단계. inode도 같이 확인하기

/var는 작은 파일이 많이 쌓이는 경우도 많습니다.

용량은 남아 있는데 파일 생성이 안 된다면 inode를 확인합니다.

df -i /var

예시입니다.

Filesystem      Inodes  IUsed  IFree IUse% Mounted on
/dev/sda3      2000000 1999000  1000  100% /var

이 경우 용량보다 inode 부족이 문제일 수 있습니다.

작은 파일이 많은 경로를 확인합니다.

for d in /var/*; do echo "$d"; find "$d" -xdev -type f 2>/dev/null | wc -l; done

작은 파일이 많이 쌓이면 df -h에서는 용량이 남아 보여도 파일 생성이 실패할 수 있습니다.

용량은 남았는데 파일 생성이 안 되는 상황은 inode 부족일 수 있습니다. df -h가 정상인데 No space left on device가 뜬다면 아래 글에서 df -i 확인 방법을 함께 보면 좋습니다.

https://opsnote.tistory.com/66

리눅스 서버 용량은 남았는데 파일 생성이 안 될 때 df -i로 inode 확인하는 법

opsnote.tistory.com

10단계. 운영자 보고 문장 예시

/var 용량 부족을 발견했다면 이렇게 보고하면 좋습니다.

[/var 용량 부족 확인]

- 발생 시각: 2026-07-08 15:20
- 대상 서버: web-01
- 증상: /var 파일시스템 Use% 92% 확인
- 확인 내용:
  1) df -h /var 결과 /var 92% 사용 중
  2) du -xhd1 /var 결과 /var/log 약 12G 확인
  3) /var/log/example-app/app.log 파일이 8G로 확인
  4) logrotate 설정 확인 중
  5) lsof deleted 여부 확인 중
- 추정 원인:
  애플리케이션 로그 반복 증가 가능성
- 조치 방향:
  로그 증가 원인 확인 후 로테이션 및 정리 검토

이렇게 적으면 “용량 찼습니다”보다 훨씬 명확합니다.

운영 보고에서는 아래 내용을 함께 적으면 좋습니다.

- 어느 파일시스템이 찼는지
- /var 아래 어떤 경로가 큰지
- 로그, 캐시, 스풀, 서비스 데이터 중 무엇인지
- 최근 증가인지 오래 누적된 것인지
- 삭제 가능한 파일인지 확인이 필요한 데이터인지

운영 서버에서 조심할 점

/var가 찼을 때 아래 명령어는 특히 조심해야 합니다.

rm -rf /var/log/*
rm -rf /var/cache/*
rm -rf /var/lib/*
kill -9 <PID>
reboot

/var는 단순 임시공간이 아니라 서비스 운영 데이터가 많이 들어가는 경로입니다.

특히 /var/lib는 함부로 지우면 서비스 데이터가 사라질 수 있습니다.
로그 파일도 장애 원인 분석에 필요할 수 있으므로, 삭제보다 원인 확인과 로테이션 상태 확인이 먼저입니다.

안전한 흐름은 이렇게 잡는 것이 좋습니다.

df -h /var 확인
Mounted on 확인
du -xhd1 /var 로 큰 경로 확인
/var/log, /var/cache, /var/spool, /var/lib 구분
로그 증가 원인 확인
deleted 파일 확인
inode 확인
정리 가능 여부 확인 후 조치

디스크 용량 문제를 처음부터 순서대로 보고 싶다면 전체 점검 흐름도 함께 확인해두면 좋습니다. 아래 글에서는 디스크 사용률이 90%를 넘었을 때 바로 삭제하지 않고 확인하는 순서를 정리했습니다.

https://opsnote.tistory.com/1

리눅스 서버 디스크 용량 90% 넘었을 때 바로 삭제하지 말고 확인하는 법

opsnote.tistory.com

정리하면

/var 용량이 차면 서비스도 위험해질 수 있습니다.

이유는 /var 아래에 로그, 캐시, 스풀, 서비스 데이터가 함께 쌓이기 때문입니다.

확인 명령어는 이렇게 시작하면 됩니다.

df -h /var
du -xhd1 /var 2>/dev/null | sort -h
find /var -xdev -type f -size +500M -ls 2>/dev/null
lsof | grep deleted | grep /var
df -i /var

/var 용량 문제는 로그 파일 증가와 함께 나타나는 경우가 많습니다.

로그가 계속 커질 때는 바로 비우기보다, 어떤 오류가 반복되는지, logrotate가 정상 동작하는지, deleted 파일이 남아 있는지 먼저 확인하는 것이 좋습니다.

로그 파일이 계속 커질 때 확인하는 순서는 아래 글에서 이어서 볼 수 있습니다.

https://opsnote.tistory.com/7

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

opsnote.tistory.com

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

https://opsnote.tistory.com/69

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

opsnote.tistory.com

디스크 용량 문제를 전체 순서로 보고 싶다면 아래 글을 함께 보면 좋습니다.
https://opsnote.tistory.com/70

리눅스 서버 디스크 용량 문제 확인 순서 총정리

opsnote.tistory.com

리눅스 서버 /tmp 용량이 찼을 때 바로 삭제하지 말고 확인하는 법

opsnote — Sat, 11 Jul 2026 15:35:29 +0900

리눅스 서버에서 /tmp 용량이 찼을 때 바로 삭제하지 않고 오래된 임시파일, 사용 중인 파일, 정리 정책을 확인하는 방법을 설명하는 대표 이미지

리눅스 서버에서 /tmp 용량이 가득 차면 파일 업로드 실패, 압축 해제 실패, 배치 오류, 애플리케이션 임시파일 생성 실패 같은 문제가 생길 수 있습니다. 이때 초보 운영자는 “임시파일이니까 지워도 되겠지”라고 생각하고 rm -rf /tmp/*를 실행하기 쉽지만, 운영 서버에서는 현재 프로세스가 사용 중인 임시파일, 소켓 파일, lock 파일까지 지워서 장애를 키울 수 있습니다.

이번 글에서는 서버 운영 중 /tmp 용량이 찼을 때 df -h, du, find, lsof로 무엇이 쌓였는지 확인하고, 오래된 파일과 사용 중인 파일을 구분해 안전하게 점검하는 순서를 정리합니다.

/tmp는 어떤 곳일까?

/tmp는 이름 그대로 임시파일이 저장되는 경로입니다.

애플리케이션, 배치 작업, 압축 해제, 업로드 처리, 패키지 설치, 스크립트 실행 중에 잠깐 필요한 파일이 /tmp에 만들어질 수 있습니다.

예를 들면 이런 파일들이 쌓일 수 있습니다.

- 업로드 임시파일
- 압축 해제 파일
- 세션 임시파일
- 배치 작업 중간 파일
- 설치 작업 임시파일
- 애플리케이션 작업 파일
- 소켓 파일
- lock 파일

문제는 이 임시파일이 자동으로 정리되지 않거나, 특정 작업이 비정상 종료되면서 계속 쌓일 때입니다.

임시파일이라는 이름만 보면 가볍게 느껴지지만, 운영 서버에서는 /tmp가 꽉 차는 것만으로도 서비스 오류가 날 수 있습니다.

가상의 운영 상황 예시

예를 들어 웹 애플리케이션 서버에서 이런 상황이 발생했다고 가정해보겠습니다.

[상황]
- 사용자가 파일 업로드를 시도했지만 실패함
- 애플리케이션 로그에 No space left on device 메시지 확인
- df -h /tmp 결과 Use% 95% 확인
- /tmp 아래 batch-work 디렉터리에 임시파일이 많이 쌓인 것으로 보임

이 상황에서 초보 운영자는 이렇게 생각하기 쉽습니다.

/tmp는 임시파일이니까 그냥 지우면 되지 않을까?

하지만 바로 삭제하면 안 됩니다.

현재 업로드 중인 파일, 실행 중인 배치의 작업 파일, 프로세스가 사용하는 소켓 파일이 같이 지워질 수 있기 때문입니다.

초보 운영자가 하기 쉬운 실수

/tmp가 꽉 찬 걸 보면 급하게 이런 명령어를 떠올리기 쉽습니다.

rm -rf /tmp/*

하지만 운영 서버에서는 조심해야 합니다.

/tmp 안에는 지금 실행 중인 프로세스가 사용하는 파일이 있을 수 있습니다.

특히 아래 파일들은 무작정 지우면 서비스 영향이 생길 수 있습니다.

- 소켓 파일
- lock 파일
- 업로드 중인 임시파일
- 배치 작업 파일
- 설치 중 생성된 파일
- 애플리케이션이 참조 중인 캐시 파일

그래서 /tmp는 “임시니까 다 지워도 된다”가 아니라, “오래됐고 사용 중이 아닌 파일부터 확인 후 정리한다”가 더 안전합니다.

1단계. df -h로 /tmp가 별도 파일시스템인지 확인하기

먼저 /tmp가 실제로 얼마나 찼는지 확인합니다.

df -h /tmp

예시입니다.

Filesystem      Size  Used Avail Use% Mounted on
/dev/sdb1        10G  9.5G  500M  95% /tmp

여기서 중요한 건 Use%와 Mounted on입니다.

Mounted on이 /tmp라면 /tmp가 별도 파일시스템으로 잡혀 있는 상태입니다.

이 경우에는 /tmp 안에서 무엇이 쌓였는지 확인해야 합니다.

반대로 /tmp가 별도 마운트가 아니고 /에 포함되어 있다면 루트 파일시스템 전체 용량 문제와 연결될 수 있습니다.

예를 들어 이렇게 보일 수 있습니다.

Filesystem      Size  Used Avail Use% Mounted on
/dev/sda2        50G   48G    2G  96% /

이 경우 /tmp만의 문제가 아니라 / 전체 용량 문제일 수 있습니다.

따라서 /tmp 문제를 볼 때도 df -h 결과에서 Mounted on을 같이 확인해야 합니다.

df -h 결과를 볼 때는 Use%만 보는 것보다 Mounted on을 함께 확인하는 것이 중요합니다. 같은 90%라도 어느 파일시스템이 찼는지에 따라 대응 방향이 달라질 수 있습니다.

2026.05.02 - [리눅스] - 리눅스 서버 df -h 결과, Use%만 보면 안 되는 이유와 확인 순서

2단계. /tmp 안에서 어떤 경로가 큰지 보기

전체 용량부터 봅니다.

du -sh /tmp

그리고 1단계 깊이로 확인합니다.

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

예시입니다.

100M    /tmp/systemd-private-example
5G    /tmp/upload-cache
0G    /tmp/batch-work
8G    /tmp

이 경우 /tmp/batch-work 쪽에 파일이 많이 쌓였을 가능성이 있습니다.

여기서 바로 삭제로 가지 말고, 먼저 이 디렉터리가 어떤 용도로 쓰이는지 확인해야 합니다.

- 배치 작업 중간 파일인지
- 업로드 임시파일인지
- 압축 해제 파일인지
- 특정 애플리케이션이 사용하는 작업 디렉터리인지
- 최근에도 계속 파일이 생성되는지

운영 서버에서는 처음부터 깊게 뒤지기보다, 이렇게 한 단계씩 좁혀가는 게 안전합니다.

3단계. 오래된 파일부터 확인하기

삭제 후보는 보통 오래된 파일부터 봅니다.

먼저 7일 이상 된 파일을 확인합니다.

find /tmp -xdev -type f -mtime +7 | head

개수도 확인합니다.

find /tmp -xdev -type f -mtime +7 | wc -l

예시입니다.

7일 이상 된 파일이 15만 개 이상이라면 정리 후보가 될 수 있습니다.

하지만 바로 삭제하지 말고 먼저 목록을 더 확인합니다.

find /tmp -xdev -type f -mtime +7 -ls | head -n 20

파일명, 경로, 수정 시간을 보고 어떤 애플리케이션이 만든 파일인지 추정해야 합니다.

오래된 파일이라고 해서 모두 안전한 것은 아닙니다.

특정 서비스가 장기간 유지하는 임시파일일 수도 있고, 이름은 임시파일처럼 보여도 애플리케이션이 참조 중일 수 있습니다.

4단계. 최근 생성된 파일이 계속 늘어나는지 보기

/tmp가 계속 차고 있다면 현재도 파일이 생성 중일 수 있습니다.

최근 1시간 내 생성된 파일을 봅니다.

find /tmp -xdev -type f -mmin -60 | head

개수도 확인합니다.

find /tmp -xdev -type f -mmin -60 | wc -l

최근 1시간 안에 파일이 매우 많이 만들어지고 있다면, 단순 정리보다 원인 확인이 먼저입니다.

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

- 업로드 실패가 반복되면서 임시파일 누적
- 배치가 실패하면서 중간 파일 누적
- 애플리케이션이 캐시 파일을 계속 생성
- 압축 해제 작업이 반복 실패
- 외부 연동 실패로 재처리 파일 누적

이런 경우에는 파일을 지워도 금방 다시 찰 수 있습니다.

따라서 “무엇을 지울까”보다 먼저 “왜 계속 생기고 있나”를 확인해야 합니다.

5단계. 사용 중인 파일인지 확인하기

삭제 전에는 사용 중인 파일인지 확인하는 게 좋습니다.

특정 경로가 의심된다면 lsof로 확인할 수 있습니다.

lsof +D /tmp/batch-work 2>/dev/null | head

다만 lsof +D는 해당 디렉터리를 훑기 때문에 파일이 아주 많으면 무거울 수 있습니다.

운영 서버에서는 /tmp 전체보다 의심 경로로 범위를 좁혀서 쓰는 게 좋습니다.

예를 들어 /tmp 전체를 바로 훑기보다 이렇게 좁혀서 봅니다.

lsof +D /tmp/upload-cache 2>/dev/null | head

결과에 프로세스가 잡힌다면, 해당 파일은 현재 사용 중일 수 있습니다.

이 경우 삭제 전 서비스 영향 여부를 먼저 확인해야 합니다.

deleted 파일도 같이 확인할 수 있습니다.

lsof | grep deleted | grep /tmp

이미 삭제됐지만 프로세스가 잡고 있는 /tmp 파일이 있다면 df 용량이 바로 줄지 않을 수 있습니다.

이때도 바로 kill 하거나 reboot 하기보다, 어떤 프로세스가 파일을 잡고 있는지 먼저 확인해야 합니다.

/tmp 용량이 꽉 찼는데 파일을 삭제해도 df 용량이 바로 줄지 않는다면 deleted 파일도 함께 의심해볼 수 있습니다. df와 du 결과가 다르게 보이는 상황은 아래 글에서 이어서 확인할 수 있습니다.

2026.07.09 - [리눅스] - 리눅스 서버 df와 du 결과가 다르게 보일 때 deleted 파일부터 확인하는 법

6단계. 바로 삭제 대신 조건을 좁히기

정리가 필요하다면 조건을 좁혀서 진행해야 합니다.

먼저 삭제 대상만 출력합니다.

find /tmp -xdev -type f -mtime +30 -print | head

개수를 확인합니다.

find /tmp -xdev -type f -mtime +30 | wc -l

정말 삭제해도 되는 파일이라고 판단되면 그때 삭제를 검토합니다.

find /tmp -xdev -type f -mtime +30 -delete

이 명령어도 운영 서버에서는 신중해야 합니다.

삭제 조건을 잘못 잡으면 필요한 파일까지 지울 수 있습니다.

처음에는 -delete를 붙이지 말고 반드시 -print로 대상부터 보는 습관이 안전합니다.

find /tmp -xdev -type f -mtime +30 -print | head

대상이 맞는지 확인한 뒤, 영향 범위를 판단하고 조치해야 합니다.

7단계. 디렉터리 자체를 지우는 건 더 조심하기

아래 명령어는 특히 조심해야 합니다.

rm -rf /tmp/*

그리고 이런 명령어도 조심해야 합니다.

find /tmp -xdev -type d -mtime +7 -delete

디렉터리 안에 사용 중인 파일이나 소켓 파일이 있을 수 있습니다.

또 어떤 애플리케이션은 특정 임시 디렉터리가 있어야 정상 동작할 수도 있습니다.

파일 정리와 디렉터리 정리는 위험도가 다릅니다.

파일은 오래된 파일만 조건을 좁혀 정리할 수 있지만, 디렉터리를 지우면 그 안의 구조나 권한, 애플리케이션이 기대하는 경로까지 사라질 수 있습니다.

디렉터리를 지울 때는 더 신중하게 확인해야 합니다.

8단계. /tmp 정리 정책 확인하기

일부 리눅스 환경에서는 systemd-tmpfiles가 /tmp 정리 정책을 관리합니다.

설정을 확인할 수 있습니다.

systemd-tmpfiles --cat-config | grep -A3 "/tmp"

또는 설정 파일을 확인합니다.

ls -l /usr/lib/tmpfiles.d/
ls -l /etc/tmpfiles.d/

환경에 따라 정리 주기나 정책이 다를 수 있습니다.

운영 서버에서는 임의로 삭제 스크립트를 만들기보다 기존 정리 정책이 있는지 먼저 확인하는 게 좋습니다.

만약 정리 정책이 없거나 애플리케이션 임시파일이 계속 쌓이는 구조라면, 단발성 삭제만으로는 다시 같은 문제가 반복될 수 있습니다.

9단계. 애플리케이션 임시 경로 설정 확인하기

애플리케이션이 /tmp를 과도하게 사용한다면 설정을 봐야 할 수 있습니다.

예를 들어 Java 애플리케이션은 임시 디렉터리를 따로 지정할 수 있습니다.

-Djava.io.tmpdir=/app/tmp

Node.js, Python, WAS, 배치 프로그램도 환경변수나 설정값에 따라 임시 경로를 사용할 수 있습니다.

확인할 만한 환경변수는 다음과 같습니다.

env | grep -i tmp

서비스 단위로는 systemd 환경 설정을 확인해야 할 수 있습니다.

systemctl cat example-app

/tmp가 자주 찬다면 단순 삭제보다 애플리케이션이 어떤 임시 경로를 쓰는지 확인하는 게 더 중요할 수 있습니다.

필요하다면 애플리케이션 임시 경로를 별도 디스크로 분리하거나, 정리 정책을 명확히 잡는 방향도 검토할 수 있습니다.

10단계. 운영자 보고 문장 예시

/tmp 용량 부족을 발견했다면 이렇게 정리하면 좋습니다.

[/tmp 용량 부족 확인]

- 발생 시각: 2026-07-08 14:30
- 대상 서버: web-01
- 증상: 파일 업로드 실패 및 No space left on device 오류 발생
- 확인 내용:
  1) df -h /tmp 결과 Use% 95% 확인
  2) du -xhd1 /tmp 결과 /tmp/batch-work 약 6G 확인
  3) /tmp/batch-work 내 30일 이상 파일 다수 확인
  4) 최근 1시간 내 생성 파일 증가 여부 확인 중
  5) lsof 기준 현재 사용 중인 파일 여부 확인 중
- 추정 원인:
  배치 작업 임시파일 누적 가능성
- 조치 방향:
  사용 중 여부와 정리 정책 확인 후 오래된 파일부터 정리 검토

이렇게 쓰면 단순히 “/tmp 찼습니다”보다 훨씬 좋습니다.

운영 보고에서는 아래 내용을 함께 적으면 좋습니다.

- 어느 파일시스템이 찼는지
- 어떤 경로가 많이 차지하는지
- 오래된 파일인지 최근 생성 파일인지
- 현재 사용 중인 파일인지
- 바로 삭제 가능한지, 확인이 더 필요한지

운영 서버에서 조심할 점

/tmp 용량이 찼을 때 아래 작업은 특히 조심해야 합니다.

rm -rf /tmp/*
find /tmp -type f -delete
reboot
kill -9 <PID>

이런 조치는 빠른 해결처럼 보일 수 있지만, 현재 실행 중인 서비스에 영향을 줄 수 있습니다.

안전한 흐름은 이렇게 잡는 게 좋습니다.

df -h /tmp 확인
Mounted on 확인
du -xhd1 /tmp 로 큰 경로 확인
오래된 파일 목록 확인
최근 생성 파일 확인
사용 중인 파일 확인
정리 정책 확인
삭제 대상 확정 후 조치

/tmp에 작은 임시파일이 너무 많이 쌓이면 용량뿐 아니라 inode 부족 문제가 함께 생길 수 있습니다. 용량은 남았는데 파일 생성이 안 되는 상황은 아래 글에서 df -i 기준으로 따로 정리했습니다.

2026.07.11 - [리눅스] - 리눅스 서버 용량은 남았는데 파일 생성이 안 될 때 df -i로 inode 확인하는 법

정리하면

/tmp는 임시파일 경로지만, 운영 서버에서는 함부로 비우면 안 됩니다.

먼저 확인할 명령어는 아래와 같습니다.

df -h /tmp
du -xhd1 /tmp 2>/dev/null | sort -h
find /tmp -xdev -type f -mtime +7 | head
find /tmp -xdev -type f -mmin -60 | head
lsof | grep deleted | grep /tmp

이번 상황의 핵심은 단순합니다.

`/tmp`가 찼다면, 지우기 전에 먼저 쓰는 주체를 확인해야 합니다.

`/tmp`는 이름 때문에 가볍게 보기 쉽지만, 운영 서버에서는 현재 서비스나 배치 작업이 임시 파일을 사용 중일 수 있습니다.

그래서 바로 삭제하기보다 어떤 파일이 쌓였는지, 최근에 생성된 파일인지, 현재 프로세스가 잡고 있는 파일은 아닌지 확인하는 순서가 먼저입니다.

디스크 용량 문제를 전체 순서로 보고 싶다면 아래 글을 함께 보면 좋습니다.

https://opsnote.tistory.com/70

리눅스 서버 디스크 용량 문제 확인 순서 총정리

opsnote.tistory.com

`/tmp`와 함께 자주 확인해야 하는 경로가 `/var`입니다.
`/var`에는 로그, 캐시, 서비스 데이터가 함께 들어갈 수 있어서 더 조심해서 봐야 합니다.

https://opsnote.tistory.com/68

리눅스 서버 /var 용량이 찼을 때 위험한 이유와 안전한 확인 순서

opsnote.tistory.com

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

https://opsnote.tistory.com/69

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

opsnote.tistory.com

opsnote - 초보 인프라 노트

리눅스 서버에서 OOM으로 서비스가 죽었는지 확인하는 실제 점검 흐름

1. 서비스가 죽었다고 바로 restart부터 하지 않는다

2. OOM 흔적부터 확인한다

3. 종료된 프로세스가 실제 서비스 프로세스인지 확인한다

4. free -m으로 현재 메모리 상태를 확인한다

5. Swap도 같이 확인한다

6. 현재 메모리를 많이 사용하는 프로세스를 확인한다

7. 서비스 상태와 로그를 다시 확인한다

8. 여기까지 확인한 결과를 조합한다

9. 조치하기 전에 영향도를 먼저 확인한다

10. 조치 후에는 반드시 재확인한다

11. OOM 로그가 있다고 서비스 장애 원인으로 바로 확정할 수 있을까?

서비스 종료 상태도 함께 확인

OOM 로그가 없다면?

확인한 결과를 어떻게 정리할까?

12. 장애 보고는 확인한 사실 중심으로 작성한다

마무리

리눅스 서버가 느린데 CPU는 낮을 때 Load Average와 wa로 확인하는 실제 점검 흐름

1. 먼저 “서버가 느리다”를 나눠서 봅니다

2. uptime으로 Load Average를 먼저 봅니다

3. CPU 사용률이 낮아도 Load Average가 높을 수 있습니다

4. top에서 wa 값을 확인합니다

5. wa가 높다고 바로 디스크 장애로 단정하지 않습니다

6. 디스크 용량과 inode도 같이 봅니다

7. 메모리와 Swap도 함께 확인합니다

8. 어떤 프로세스가 영향을 주는지 봅니다

9. 로그에서 같은 시간대의 오류를 확인합니다

10. 조치 전에 영향도를 먼저 정리합니다

11. 조치 후에는 다시 같은 지표를 확인합니다

12. 보고는 숫자와 해석을 함께 남깁니다

13. 정리하면

ping은 되는데 사이트가 안 열릴 때 nc와 curl로 확인하는 실제 점검 흐름

1. 먼저 “사이트가 안 열린다”를 나눠서 봅니다

2. ping은 참고용으로만 봅니다

3. nc로 포트 연결 여부를 확인합니다

4. nc 성공이 서비스 정상이라는 뜻은 아닙니다

5. curl로 HTTP 응답을 확인합니다

6. DNS가 의도한 IP를 바라보는지도 확인합니다

7. 서버 내부에서도 포트와 서비스 상태를 봅니다

8. traceroute는 경로 참고용으로 봅니다

9. 결과를 조합해서 원인을 좁힙니다

실전 점검 예시: ping 성공, 외부 443 포트 연결 실패

상황

1단계. 외부 클라이언트에서 확인

2단계. 서버 내부 포트 확인

3단계. 결과를 구간별로 분리

4단계. 조치 여부 판단

5단계. 조치 후 재확인

10. 조치 전에 영향도를 확인합니다

11. 조치 후에는 다시 확인합니다

12. 보고는 구간별로 정리합니다

13. 정리하면

함께 읽으면 좋은 글

리눅스 서버 서비스가 안 뜰 때 systemctl status와 journalctl로 원인 좁히는 과정

1. 먼저 “서비스가 안 뜬다”는 말을 나눠서 봅니다

2. systemctl status로 현재 상태를 확인합니다

3. status 결과만 보고 단정하지 않습니다

4. journalctl로 실패 원인을 확인합니다

5. 실패한 서비스가 여러 개인지도 확인합니다

6. 포트가 열렸는지도 같이 봅니다

7. 바로 restart 하지 않는 이유

8. restart를 했다면 반드시 재확인합니다

9. 서버 재부팅 후 자동으로 안 뜬다면 enable도 확인합니다

10. 조치 전에는 영향도를 정리합니다

11. 보고는 상태와 로그 중심으로 남깁니다

12. 정리하면

리눅스 서버 디스크 용량 90% 알림을 받았을 때 실제 점검 흐름 정리

1. 먼저 알림 내용을 확인합니다

2. df -h로 전체 파일시스템을 봅니다

3. 바로 삭제하지 말고 큰 폴더부터 찾습니다

4. 큰 파일인지, 작은 파일이 많이 쌓인 것인지 나눕니다

5. df와 du 결과가 다르면 deleted 파일을 의심합니다

6. 용량은 남았는데 파일 생성이 안 되면 inode를 확인합니다

7. /tmp는 이름만 보고 가볍게 보면 안 됩니다

8. /var는 더 조심해서 봅니다

9. 조치 전에 영향도를 먼저 봅니다

10. 조치 후에는 다시 확인합니다

11. 같은 디스크 90% 알림이어도 원인은 다를 수 있다

1. 로그 파일이 계속 증가하는 경우