필사 모드: 리눅스 장애 대응 명령어 완전 가이드: 첫 60초부터 근본 원인까지

• 들어가며
• 1. 첫 60초 — 표준 점검 시퀀스
• 2. 부하 평균이 실제로 말해 주는 것
• 3. CPU를 누가 쓰고 있는가
• 4. 메모리 — free의 어느 숫자를 믿을 것인가
• 5. 디스크가 찼을 때 — 용량과 inode
• 6. I/O — 느린 디스크의 증거 찾기
• 7. 네트워크 — 포트, 큐, 그리고 재전송
• 8. 로그 — 시간 범위를 먼저 좁힌다
• 9. 멈춘 것처럼 보이는 프로세스 파헤치기
• 10. 재현되지 않는 장애를 잡는 상시 수집
• 퀴즈: 실력을 확인해 보세요
• 마치며
• 참고 자료
• 이어서 읽기

들어가며

장애 대응에서 가장 많이 낭비되는 시간은 명령어를 몰라서 생기지 않습니다. 어떤 명령을 어떤 순서로 쳐야 하는지 모르기 때문에 생깁니다. top을 띄우고 30초간 바라보다가, df를 치고, 다시 top으로 돌아오고, 그러는 동안 5분이 지나갑니다.

이 글은 "서버가 느리다", "응답이 없다", "배포 후 이상하다"는 연락을 받은 순간부터 실행할 명령을 순서대로 정리합니다. 이 블로그에는 이미 리눅스 성능 엔지니어링 가이드가 있지만 그 글은 프로파일링과 튜닝 방법론을 다룹니다. 이 글은 다릅니다. 아직 무엇이 문제인지 모르는 상태에서 후보를 하나씩 배제해 나가는 순서가 주제입니다.

전제는 하나입니다. 진단은 "범인 찾기"가 아니라 "용의자 제외하기" 입니다. CPU가 아니면 CPU를 지우고, 메모리가 아니면 메모리를 지웁니다. 남은 것이 답입니다.

배포판 표기는 다음과 같습니다. RHEL 계열은 RHEL/Rocky/AlmaLinux 8 이상, Debian 계열은 Debian 12 및 Ubuntu 22.04 이상을 기준으로 합니다.

1. 첫 60초 — 표준 점검 시퀀스

Netflix 성능 엔지니어링 팀이 공개한 "첫 60초" 체크리스트가 사실상 업계 표준이 되었습니다. 핵심은 한 번에 열 개를 던져 놓고 전체 그림을 먼저 본 다음 깊게 파는 것입니다.

uptime
dmesg --level=err,warn --ctime | tail -20
vmstat 1 5
mpstat -P ALL 1 3
pidstat 1 3
iostat -xz 1 3
free -m
sar -n DEV 1 3
ss -s

각 명령이 배제하는 용의자는 다음과 같습니다.

mpstat, pidstat, iostat, sar는 모두 sysstat 패키지에 들어 있습니다. 기본 설치가 아닌 경우가 많으므로 서버를 만들 때 미리 넣어 두세요.

# RHEL 계열
sudo dnf install -y sysstat
# Debian 계열
sudo apt install -y sysstat

sar로 과거 데이터를 보려면 수집 데몬이 켜져 있어야 합니다. Debian 계열은 /etc/default/sysstat에서 활성화 값을 켜야 수집이 시작됩니다.

sudo systemctl enable --now sysstat

2. 부하 평균이 실제로 말해 주는 것

uptime의 세 숫자는 1분, 5분, 15분 부하 평균입니다. 여기서 두 가지를 오해하기 쉽습니다.

첫째, 리눅스의 부하 평균은 CPU 대기만 세지 않습니다. 실행 가능(R) 상태뿐 아니라 중단 불가 대기(D 상태) 프로세스도 포함합니다. D 상태는 대부분 디스크 I/O 또는 NFS 응답 대기입니다. 그래서 CPU가 놀고 있는데도 부하가 40이 나오는 상황이 생깁니다. 이 경우 범인은 CPU가 아니라 스토리지입니다.

둘째, 절대값보다 기울기가 중요합니다. 1분 값이 15분 값보다 크면 지금 악화되는 중이고, 작으면 이미 회복 중입니다. 후자라면 급하게 재기동할 이유가 없습니다.

uptime

 14:22:31 up 41 days,  3:11,  2 users,  load average: 12.44, 6.80, 3.15

이 출력은 "지난 15분 사이에 부하가 4배로 뛰었고 지금도 오르는 중"이라는 뜻입니다. 코어 수와 비교해야 의미가 생기므로 코어 수를 먼저 확인하세요.

nproc
lscpu | grep -E '^CPU\(s\)|Thread|Core|Socket|Model name'

3. CPU를 누가 쓰고 있는가

vmstat 1의 첫 줄은 부팅 이후 평균이므로 무시하고 둘째 줄부터 읽습니다. 이는 man 페이지에 명시된 동작입니다.

vmstat 1 5

procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu-----
 r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa st
 8  1      0 210488  91232 3120440    0    0    12    34  980 2210 71 14  9  6  0

읽는 순서는 이렇습니다.

• r: 실행 대기 중인 프로세스 수. 코어 수보다 지속적으로 크면 CPU 포화입니다.
• b: I/O 완료를 기다리며 블록된 프로세스 수. 여기가 크면 스토리지를 의심합니다.
• si/so: 스왑 인/아웃. 0이 아니면 메모리 부족이 이미 성능에 영향을 주고 있습니다.
• wa: I/O 대기 시간 비율. 높으면 디스크, 낮은데 느리면 디스크가 아닙니다.
• st: 하이퍼바이저에 빼앗긴 시간. 클라우드 VM에서 이 값이 계속 5를 넘으면 호스트가 과밀한 것이고, 내 서버 안에서는 해결할 수 없습니다.

전체가 바쁜지 코어 하나만 바쁜지는 mpstat으로 가릅니다.

mpstat -P ALL 1 3

코어 하나만 100퍼센트라면 단일 스레드 병목입니다. 스케일 업으로 해결되지 않고 코드나 설정을 봐야 합니다.

범인 프로세스는 pidstat으로 찾습니다. top과 달리 누적이 아니라 구간별 값을 계속 찍어 주기 때문에 로그로 남기기 좋습니다.

pidstat -u 1 5
pidstat -t -p 1234 1 5

-t 옵션은 스레드 단위로 분해합니다. 자바나 Go 프로세스처럼 스레드가 많은 경우 어느 스레드가 도는지 볼 수 있습니다. %wait는 실행 준비가 되었는데 CPU를 못 받아 기다린 비율이라, 여기가 높으면 프로세스가 느린 게 아니라 CPU 경합이 심한 것입니다.

전통적인 ps 조합도 여전히 유용합니다.

ps -eo pid,ppid,stat,pcpu,pmem,etime,rss,args --sort=-pcpu | head -15

stat 열에서 D가 보이면 중단 불가 대기, Z는 좀비, T는 정지 상태입니다.

4. 메모리 — free의 어느 숫자를 믿을 것인가

free -m에서 초보가 가장 자주 오독하는 곳이 free 열입니다. 리눅스는 남는 메모리를 페이지 캐시로 씁니다. free가 작은 것은 정상이며, 봐야 할 곳은 available 열입니다.

free -m

               total        used        free      shared  buff/cache   available
Mem:           15884       10233         412         188        5238        5102
Swap:           4095         120        3975

available은 "지금 새 프로세스가 요청하면 회수해서 줄 수 있는 양"의 커널 추정치입니다. 이 값이 총량 대비 충분히 남아 있으면 메모리 부족이 아닙니다.

메모리 부족이 의심되면 커널이 무엇을 죽였는지부터 확인합니다.

dmesg --ctime | grep -i -E 'out of memory|oom-kill|killed process'
journalctl -k --since '2 hours ago' | grep -i oom

dmesg --ctime(-T)은 사람이 읽는 시각으로 바꿔 주지만, man 페이지는 시스템 서스펜드/리줌 이후 타임스탬프가 부정확할 수 있다고 경고합니다. 정밀한 시각이 필요하면 journalctl -k를 쓰세요.

세부 분해는 /proc/meminfo를 봅니다.

grep -E 'MemAvailable|Dirty|Writeback|Slab|SReclaimable|Committed_AS' /proc/meminfo

Dirty가 크고 줄지 않으면 쓰기가 디스크로 못 내려가는 중입니다. Slab이 비정상적으로 크면 커널 객체 누수를 의심합니다. 프로세스별 실제 사용량은 RSS가 공유 페이지를 중복 계산하므로, 가능하면 PSS를 보세요.

sudo grep -H '^Pss:' /proc/1234/smaps_rollup

5. 디스크가 찼을 때 — 용량과 inode

디스크 부족은 두 종류입니다. 블록 부족과 inode 부족입니다. df -h만 보고 "여유 있는데요"라고 답했다가 실제로는 inode가 고갈된 경우가 드물지 않습니다.

df -h
df -i

df -i에서 IUse%가 100퍼센트면 용량이 남아 있어도 새 파일을 만들 수 없습니다. 세션 파일이나 메일 큐처럼 작은 파일이 수백만 개 쌓이는 디렉터리가 원인인 경우가 대부분입니다.

큰 디렉터리를 찾을 때는 한 파일시스템 안에서만 재귀하도록 제한하는 것이 안전합니다.

sudo du -x -h --max-depth=1 /var | sort -h | tail -20

-x는 다른 파일시스템으로 넘어가지 않게 합니다. 이것이 없으면 /proc이나 네트워크 마운트까지 훑다가 한참 걸립니다.

df와 du의 값이 크게 다르다면 삭제되었지만 아직 열려 있는 파일 때문입니다. 파일을 지워도 그 파일을 연 프로세스가 살아 있으면 공간이 반환되지 않습니다.

sudo lsof +L1
sudo lsof -nP +L1 | awk '{print $1, $2, $7, $9}' | sort -k3 -n -r | head

+L1은 링크 수가 1보다 작은, 즉 이미 unlink된 열린 파일을 나열합니다. 해결책은 해당 프로세스에 로그 재오픈 시그널을 보내거나 재기동하는 것입니다. 자세한 원리는 이 시리즈의 파일 디스크립터와 inode 가이드에서 다룹니다.

6. I/O — 느린 디스크의 증거 찾기

iostat -xz 1 3

-x는 확장 통계, -z는 활동 없는 장치를 생략합니다. 첫 리포트는 부팅 이후 통계이므로 -y로 생략하거나 둘째 리포트부터 읽습니다.

봐야 할 열은 다음과 같습니다.

• r_await / w_await: 요청이 큐에서 기다린 시간까지 포함한 평균 응답 시간(밀리초). NVMe에서 한 자리 밀리초를 넘으면 이상하고, 회전 디스크는 10에서 20까지는 정상 범위입니다.
• aqu-sz: 평균 큐 길이. 1을 크게 넘으면 장치가 요청을 소화하지 못하는 중입니다.
• rareq-sz / wareq-sz: 요청 평균 크기(KiB). 작은 랜덤 I/O인지 큰 순차 I/O인지 구분해 줍니다.
• %util: 이 장치에 I/O가 발행되어 있던 시간 비율.

%util은 반드시 조심해야 합니다. man 페이지가 명시적으로 경고합니다. 요청을 직렬로 처리하는 장치에서는 100퍼센트가 포화를 뜻하지만, RAID 배열이나 최신 SSD처럼 병렬 처리하는 장치에서는 100퍼센트여도 성능 한계가 아닙니다. 이 경우 판단 기준은 %util이 아니라 await입니다.

어떤 프로세스가 I/O를 만드는지는 pidstat -d로 봅니다.

pidstat -d 1 5

kB_rd/s, kB_wr/s가 프로세스별 읽기·쓰기, iodelay는 블록 I/O 지연을 클럭 틱 단위로 보여 줍니다. iotop이 설치되어 있다면 대화형으로 보기 더 편합니다.

sudo iotop -oPa

7. 네트워크 — 포트, 큐, 그리고 재전송

netstat은 net-tools 패키지의 유물이고, 최신 배포판의 표준은 ss입니다.

ss -tulpn
ss -tan state established | head
ss -s

• -t TCP, -u UDP, -l 리스닝만, -a 전부, -n 이름 해석 안 함, -p 소켓을 쓰는 프로세스 표시.
• -p로 프로세스명을 보려면 보통 root 권한이 필요합니다.

Recv-Q와 Send-Q는 소켓 상태에 따라 뜻이 달라집니다. 리스닝 소켓에서 Recv-Q는 accept 대기 중인 완료 큐의 길이이고, Send-Q는 백로그 최대치입니다. 리스닝 소켓의 Recv-Q가 계속 차 있으면 애플리케이션이 accept를 못 따라가는 중입니다. 확립된 연결에서는 각각 아직 읽히지 않은 수신 데이터와 아직 확인되지 않은 송신 데이터입니다. 다만 이 두 열의 의미는 man7.org에 공개된 ss 매뉴얼 본문에 명시되어 있지 않고 iproute2 구현 동작에 근거합니다. 판단의 근거로 삼기 전에 설치된 iproute2 버전의 man 페이지에서 한 번 확인하는 편이 안전합니다.

경로 문제인지 애플리케이션 문제인지는 계층을 나눠 확인합니다.

ip -brief addr
ip route get 10.0.3.14
ping -c 4 10.0.3.14
mtr -rwc 20 10.0.3.14
curl -sS -o /dev/null -w 'dns:%{time_namelookup} conn:%{time_connect} tls:%{time_appconnect} ttfb:%{time_starttransfer} total:%{time_total}\n' https://example.com

curl의 타이밍 변수는 어느 단계가 느린지 한 줄로 보여 줍니다. DNS 단계가 느리면 이름 해석 문제이고, time_connect가 느리면 경로나 방화벽, time_starttransfer만 느리면 서버 애플리케이션입니다.

TCP 재전송이 많은지 확인합니다.

nstat -az | grep -i -E 'retrans|drop|overflow'
ss -ti state established | grep -E 'retrans|rtt' | head

ListenOverflows 또는 ListenDrops가 증가하고 있다면 백로그가 넘치는 중입니다.

8. 로그 — 시간 범위를 먼저 좁힌다

로그를 처음부터 읽지 마세요. 장애 시각의 앞뒤 5분만 봅니다.

journalctl --since '2026-08-15 14:10' --until '2026-08-15 14:30' -p err
journalctl -u nginx.service -n 200 --no-pager
journalctl -u nginx.service -f
journalctl -k -b -1 -p warning
journalctl -g 'timeout|refused|denied' --since today

• -p err는 err 이상 우선순위만 봅니다. 우선순위 이름은 emerg, alert, crit, err, warning, notice, info, debug 순입니다.
• -b -1은 직전 부팅의 로그입니다. 서버가 갑자기 재부팅된 경우 여기에 원인이 남아 있습니다.
• -g는 MESSAGE 필드에 정규식을 적용합니다.

부팅 목록과 재부팅 원인 확인은 이렇게 합니다.

journalctl --list-boots
last -x reboot shutdown | head

last -x에 정상 종료 기록 없이 재부팅만 있으면 커널 패닉이나 전원 문제, 하이퍼바이저 강제 재시작을 의심합니다. 로그 파이프라인 자체를 설계하는 방법은 리눅스 로그 운영 가이드에서 다룹니다.

9. 멈춘 것처럼 보이는 프로세스 파헤치기

응답이 없는 프로세스는 세 가지 중 하나입니다. CPU를 태우는 중, 무언가를 기다리는 중, 락에 걸린 중입니다.

먼저 커널이 보고하는 대기 지점을 봅니다. 이것은 부작용이 없는 읽기 연산입니다.

cat /proc/1234/status | grep -E 'State|Threads|voluntary'
sudo cat /proc/1234/stack
sudo cat /proc/1234/wchan; echo
ls -l /proc/1234/fd | head

State가 D (disk sleep)이면 중단 불가 대기입니다. 이 상태의 프로세스는 SIGKILL로도 죽지 않습니다. 기다리는 자원(대부분 스토리지나 NFS)이 응답해야 풀립니다.

시스템 콜 수준을 봐야 한다면 strace를 붙이되, 운영 환경에서 프로세스를 크게 느리게 만든다는 점을 반드시 인지하고 짧게 사용하세요.

sudo strace -f -p 1234 -tt -T -e trace=network,file 2>&1 | head -50
sudo strace -c -f -p 1234

-c는 요약만 내므로 부하가 상대적으로 적습니다. 어느 시스템 콜에서 시간을 쓰는지 한눈에 보여 줍니다. strace가 붙지 않는다면 커널의 ptrace 제한 설정 때문일 수 있습니다.

cat /proc/sys/kernel/yama/ptrace_scope

값이 1 이상이면 같은 사용자라도 임의 프로세스에 붙을 수 없고 root가 필요합니다.

파일 잠금 때문에 멈춘 경우도 흔합니다.

cat /proc/locks | head
sudo lsof /var/lib/myapp/data.db

10. 재현되지 않는 장애를 잡는 상시 수집

가장 흔한 실패는 "그때 로그를 안 남겼다"입니다. 순간 부하는 사람이 로그인하기 전에 끝나므로, 평상시에 수집이 돌고 있어야 합니다.

sar는 이 용도로 만들어졌습니다. 기본 수집 주기는 배포판 설정에 따라 다르며 보통 10분 간격입니다.

sar -u -f /var/log/sa/sa15
sar -r -s 14:00:00 -e 15:00:00
sar -n DEV -s 14:00:00 -e 15:00:00
sar -q

-f로 특정 날짜 파일을 지정합니다. 파일 경로는 RHEL 계열이 /var/log/sa/, Debian 계열이 /var/log/sysstat/으로 다릅니다.

임계치를 넘을 때만 스냅샷을 남기는 간단한 방식도 유효합니다. 다음은 부하가 임계치를 넘으면 프로세스 목록을 파일로 남기는 예입니다.

#!/usr/bin/env bash
set -euo pipefail
THRESHOLD=20
LOAD=$(awk '{print int($1)}' /proc/loadavg)
if [ "$LOAD" -ge "$THRESHOLD" ]; then
  TS=$(date +%Y%m%d-%H%M%S)
  OUT="/var/log/spike-$TS.txt"
  {
    uptime
    ps -eo pid,stat,pcpu,pmem,etime,args --sort=-pcpu | head -30
    ss -s
    vmstat 1 3
  } > "$OUT"
fi

이 스크립트를 1분 주기 cron이나 systemd 타이머에 걸어 두면, 다음번 순간 부하 때 사람이 없어도 증거가 남습니다. 타이머 작성법은 systemd 타이머 완전 정복을 참고하세요.

마지막으로, 진단 중 실행하는 명령이 장애를 키우지 않도록 주의합니다. 루트에서 du -x를 빼먹고 돌리거나, 이미 I/O가 포화된 디스크에 find / 전체 스캔을 거는 것은 상황을 악화시킵니다. 디스크가 이미 100퍼센트 사용 중일 때는 읽기 작업도 줄을 서야 한다는 점을 기억하세요.

퀴즈: 실력을 확인해 보세요

ps -eo pid,stat,wchan:20,args --sort=-pcpu | awk '$2 ~ /D/'
iostat -xz 1 3
vmstat 1 5

df -i
df -h /var/lib/myapp
mount | grep myapp

sudo lsof -nP +L1 | head
sudo systemctl reload rsyslog

ps -o pid,ppid,stat,wchan:24,args -p 1234
sudo cat /proc/1234/stack

curl -sS -o /dev/null -w 'dns:%{time_namelookup} conn:%{time_connect} tls:%{time_appconnect} ttfb:%{time_starttransfer} total:%{time_total}\n' https://api.example.com/health

마치며

장애 대응을 잘하는 사람과 못하는 사람의 차이는 아는 명령어 개수가 아닙니다. "이 명령의 결과로 무엇을 배제할 수 있는가" 를 매번 의식하는지의 차이입니다.

vmstat을 치기 전에 "여기서 wa가 낮으면 디스크를 지운다"고 미리 정해 두면, 출력이 나온 순간 다음 행동이 결정됩니다. 그렇게 하지 않으면 같은 화면을 세 번 보고도 아무것도 좁히지 못합니다.

이 글의 명령 목록을 사내 위키에 그대로 옮기지 말고, 첫 60초 블록을 스크립트 하나로 만들어 모든 서버에 배포하세요. 장애가 났을 때 그 스크립트 하나를 실행하는 것이 아홉 개의 명령을 기억해 내는 것보다 훨씬 빠릅니다.

참고 자료

• vmstat(8) — man7.org (2026-08-15 확인)
• iostat(1) — man7.org (2026-08-15 확인)
• pidstat(1) — man7.org (2026-08-15 확인)
• ss(8) — man7.org (2026-08-15 확인)
• lsof(8) — man7.org (2026-08-15 확인)
• dmesg(1) — man7.org (2026-08-15 확인)
• journalctl(1) — man7.org (2026-08-15 확인)

이어서 읽기

• 다음 글: 리눅스 성능 도구 완전 가이드 — 출력의 숫자를 해석하는 법
• 리눅스 성능 엔지니어링 완전 가이드 — 프로파일링과 eBPF까지 들어가는 이론 편
• systemd 서비스 관리 완벽 가이드 — 서비스가 안 뜰 때의 진단
• DNS 해석 순서 디버깅 — 이름만 안 풀릴 때
• Linux 터미널 — 명령을 브라우저에서 바로 연습
• 리눅스 명령어 퀴즈 — 옵션 암기 상태 점검
• curl 빌더 — 타이밍 옵션이 붙은 curl 명령 만들기