웹 페이지나 API가 느립니다 — 원인을 어떻게 찾나요?

Question

Accepted Answer

**추측하지 말고 — 먼저 측정하세요.** 느림은 client, network, server, 또는 database에서 올 수 있습니다. 체계적인 접근은 *시간이 어디로 가는지*를 찾아낸 뒤, 무작위로 최적화하는 대신 **가장 큰 기여 요인**을 고칩니다.

## 체계적인 순서

```text
1. 측정 → 시간이 어디서 소비되는가? client render, network, server, DB?
2. 재현 → 안정적으로 확인 (같은 endpoint, payload, user)
3. TRACE → APM/distributed traces로 느린 span 찾기
4. 최근 변경 확인 → deploy, config, traffic, 데이터 증가
5. 격리 → 계층별로, 하나의 component로 좁히기
6. 가장 큰 기여 요인 수정 → 재측정으로 확인
```

## 먼저 측정: 시간이 어디에?

브라우저 **Network/Performance** 탭과 서버 **timing**으로 전체를 분리합니다. 유용한 분해:

```text
총 1200ms =
  DNS/connect      20ms
  server TTFB     900ms   ← 병목은 서버 쪽
  download         80ms
  client render   200ms
```

**평균이 아니라 percentile**을 보세요: **p50**(전형적인 사용자) vs **p99**(최악의 경우). 빠른 p50에 느린 p99는 균일한 문제가 아니라 간헐적 문제 — lock contention, 차가운 cache, 느린 DB replica, 또는 GC pause — 를 가리킵니다.

## 느린 span 추적

APM 도구(traces)는 요청 내부에서 시간이 어디로 가는지 정확히 보여줍니다:

```text
GET /orders                       950ms
  ├─ auth check                    10ms
  ├─ SELECT orders                 30ms
  └─ loop: SELECT user per order  900ms   ← N+1 query, 진짜 원인
```

trace는 문제의 호출을 곧장 가리킵니다. 그다음 **최근 변경**을 확인하세요 — deploy, 누락된 index, 또는 10배의 데이터 증가가 갑작스러운 regression을 설명하는 경우가 많습니다.

## 왜 중요한가

추측은 잘못된 계층을 최적화하느라 몇 시간을 낭비합니다. 먼저 측정하고, 느린 span을 추적하고, **p50 vs p99**를 보는 것은 모호한 "느려요"를 구체적이고 고칠 수 있는 원인으로 바꿉니다 — 그리고 재측정은 수정이 실제로 효과가 있었음을 증명합니다.