느리다는 말을 숫자로 바꾸기

한 줄 요약

"느려요" 로는 아무것도 못 고칩니다. 무엇이 · 언제 · 얼마나 · 몇 %
느린지로 바꾸는 순간 조사 범위가 10분의 1이 됩니다.

왜 이게 필요했나

신고는 이렇게 옵니다. "요즘 시스템이 느려요."

여기서 바로 서버에 들어가 CPU 를 보는 것이 가장 흔한 실수입니다. CPU 가
30% 면 "정상인데요" 로 끝나고, 90% 면 "CPU 때문입니다" 로 잘못 끝납니다.
둘 다 답이 아닙니다.

먼저 물어야 할 것은 네 가지입니다.

| 질문 | 왜 | 답이 좁혀 주는 것 |
| --- | --- | --- |
| 어떤 화면/기능이? | 전부가 느린 경우는 드물다 | 코드 경로 |
| 언제부터? | 배포·설정 변경과 대조 | 원인 시점 |
| 얼마나? (전에는 2초, 지금 20초) | 10배인지 10% 인지 | 문제의 성격 |
| 항상? 가끔? | 평균 문제인지 꼬리 문제인지 | 조사 방법 |

특히 네 번째. 항상 느린 것과 가끔 느린 것은 원인이 다릅니다.
항상이면 구조(쿼리, N+1, 동기 호출)이고, 가끔이면 경합(락, 커넥션 풀, GC,
디스크)입니다. 이 둘을 섞어 놓고 보면 평균에 묻혀 아무것도 안 보입니다.

구간을 쪼갠다

요청 하나가 지나는 길을 나눠 각 구간의 시간을 잽니다.

클라이언트 → [네트워크] → 웹서버 → [앱] → [DB] → 앱 → 웹서버 → 클라이언트

측정 도구가 없어도 curl 하나로 구간을 나눌 수 있습니다.

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

• dns 가 크다 → 이름 해석. 리졸버 설정, 캐시 미스.
• conn 이 크다 → TCP 연결. 경로·방화벽·SYN 대기.
• tls 가 크다 → 핸드셰이크. 인증서 체인, OCSP 조회.
• ttfb 가 크고 total - ttfb 는 작다 → 서버가 생각하는 시간. 앱/DB.
• total - ttfb 가 크다 → 본문 전송. 응답이 크거나 대역폭 문제.

이 다섯 숫자만으로 "네트워크냐 서버냐" 가 갈립니다. 대부분의 논쟁이
여기서 끝납니다.

평균을 믿지 않는다

평균 응답 200ms 인 서비스에서 사용자가 "느리다"고 하는 건 흔한 일입니다.
1000건 중 950건이 50ms 이고 50건이 3초면 평균은 197ms 입니다. 평균은
정상인데 20명 중 1명은 3초를 기다립니다.

그래서 백분위수를 봅니다.

| 지표 | 뜻 | 쓰임 |
| --- | --- | --- |
| p50 (중앙값) | 절반이 이보다 빠름 | 전형적인 경험 |
| p95 | 20명 중 1명이 겪는 값 | 체감 불만의 시작점 |
| p99 | 100명 중 1명 | 꼬리. 경합·GC·재시도 |
| max | 최악 한 건 | 이상값 추적 |

p50 은 그대로인데 p99 만 올랐다면 용량이 아니라 경합입니다.
p50 부터 함께 올랐다면 구조나 용량입니다.

부하와 지연은 다른 축이다

CPU 사용률 60% 는 "여유 40%" 를 뜻하지 않습니다. 대기 행렬 이론에서
이용률이 올라가면 대기 시간은 선형이 아니라 급격히 늘어납니다.
70% 를 넘어서면 조금만 더 몰려도 지연이 몇 배가 됩니다. 그래서 "아직
CPU 여유 있는데요" 는 지연 문제의 반박이 되지 못합니다.

현장에서 만나는 모습

• "네트워크가 느린 것 같아요" → ttfb 를 재 보면 서버 처리 시간이 대부분.
• 오전 9시만 느리다 → 출근 시간 동시 접속 + 캐시가 비어 있는 시각.
• 특정 고객만 느리다 → 그 고객의 데이터 양이 다르다. 쿼리가 풀스캔.

이어지는 실습에서 할 것

340건짜리 실제 요청 로그를 받아 네 질문에 직접 답합니다. 답이 다 들어 있는
데이터라, 순서대로 자르기만 하면 "느려요" 한 줄이 버전 하나를 가리키는
보고서가 됩니다.