[내일배움캠프 TIL] - 부하 테스트 지표와 p95가 국룰인 이유

배경

k6 부하 테스트 결과를 분석하다가 avg, p90, p95, max 등 여러 지표 중 어떤 걸 기준으로 봐야 하는지 정리하게 됐다.

---

avg가 믿을 수 없는 이유

요청 9개 → 10ms
요청 1개 → 10000ms (DB 락 걸린 불운한 유저)

avg = (9×10 + 10000) / 10 = 1009ms
→ "평균 1초"라고 하면 실제보다 훨씬 나빠 보임
→ 반대로 극단값 몇 개가 avg를 반대 방향으로 왜곡하기도 함

avg는 이상치(outlier)에 취약하다. 대부분의 유저가 빠른 응답을 받아도 일부 느린 요청이 avg를 끌어올린다.

---

퍼센타일(Percentile)이란?

전체 요청을 응답시간 순으로 줄 세웠을 때, 빠른 쪽에서 N번째 퍼센트에 해당하는 값이다.

p50  = 전체의 50%가 이 시간 이하로 응답 (중앙값)
p90  = 전체의 90%가 이 시간 이하로 응답
p95  = 전체의 95%가 이 시간 이하로 응답
p99  = 전체의 99%가 이 시간 이하로 응답

즉 p95 = 8068ms 라면, 전체 요청 중 5%는 8초 이상 걸렸다는 의미다.

---

p95가 국룰인 이유

지표 문제점

avg	이상치에 취약, 왜곡 가능
p50	절반의 유저 경험만 반영 → 너무 낙관적
p95	대부분의 유저(95%) 경험을 대표, 이상치에 덜 흔들림
p99	너무 엄격, 일반 서비스엔 과도할 수 있음

p95는 "대부분의 유저 경험"을 대표하면서 극단적인 이상치에 덜 흔들리는 균형점이다.

Google SRE 책, AWS, Netflix 모두 p95를 기본 SLA(Service Level Agreement) 지표로 사용한다.

---

업계 기준

지표 사용 상황

p50	중간값 참고용
p95	일반 서비스 SLA 기준 (국룰)
p99	금융, 결제 등 민감한 서비스
p99.9	대형 플랫폼 (구글, 아마존 수준)

일반적인 웹 API SLA 목표: p95 < 500ms

---

실제 테스트 결과 분석 예시

쿠폰 발급 부하 테스트 (VU: 100명, 쿠폰 수량: 100개)

지표 값 평가

avg	3098ms	❌ 3초 평균은 너무 느림
p90	6567ms	❌ 상위 10%는 6.5초 이상
p95	8068ms	❌ 목표(500ms) 대비 16배 초과
max	14669ms	❌ 최대 14.7초
에러율	0.00%	✅ 정합성은 완벽
DB 발급 건수	100건	✅ 동시성 제어 정상

정합성은 완벽하지만 응답속도가 문제. 100 VU가 동시에 몰리면서 DB 락 경합이 발생한 것으로 추정. Redis DECR을 critical path 앞단에 두는 구조로 개선하면 p95를 크게 낮출 수 있다.

---

정리

• avg는 이상치에 취약해서 단독으로 믿으면 안 된다
• p95가 SLA 지표의 국룰 — 대부분의 유저 경험을 대표
• 금융/결제는 p99, 일반 서비스는 p95 기준
• 일반 웹 API 목표: p95 < 500ms