느림을 봤을 때 절대 하지 말아야 할 것들, 가장 먼저 해야 할 것들

이 글은 관측(observability) 카테고리의 네 번째 글이자,
지표를 실제 행동으로 바꾸는 운영 가이드다.
톤은 단호하게, “하지 말 것”부터 끊고 간다.

---

느림을 봤을 때 절대 하지 말아야 할 것들, 가장 먼저 해야 할 것들

— 성능 장애 대응의 우선순위

느림을 감지했을 때
대응은 거의 두 갈래로 갈린다.

• 즉각적인 조치 → 대개 실패
• 질문부터 하는 조치 → 회복

이 글은
성능이 흔들리는 순간에 무엇을 ‘하지 말아야’ 하고,
무엇을 ‘먼저 해야’ 하는지를 고정한다.

---

1. 절대 하지 말아야 할 첫 번째 행동: 서버 증설

가장 흔하고, 가장 비싼 실수다.

“일단 서버를 늘려볼까요?”

이 판단은 대부분 증상을 가린다.

• 큐가 있는 상태 → 더 큰 큐가 생김
• 재시도 폭풍 → 더 많은 재시도 수용
• 타임아웃 지연 → 장애 시점만 뒤로 이동

증설은
원인이 ‘계산량 부족’일 때만 의미가 있다.

지금 보고 있는 느림이 대기라면, 증설은 해답이 아니다.

---

2. 두 번째로 하지 말아야 할 것: 타임아웃 늘리기

이미 봤다.

타임아웃을 늘리는 건
실패를 늦추는 게 아니라
피해를 키운다.

느림이 보일 때 타임아웃을 늘리면:

• 큐는 더 길어지고
• 리소스는 더 오래 묶이며
• 재시도는 더 크게 동기화된다

이건 치료가 아니라 진통제다.

---

3. 세 번째 금기: 평균값만 보고 판단하기

“평균 응답 시간은 괜찮은데요?”

이 말이 나오면
이미 관측이 빗나갔다.

• 평균은 대기를 숨긴다
• 꼬리(p95/p99)가 문제를 드러낸다

느림을 봤다면
평균을 보지 말고
꼬리를 봐라.

---

4. 가장 먼저 해야 할 것 #1: 대기부터 확인하라

느림이 보이면
첫 질문은 이것이다.

“이 요청은
어디에서 얼마나 기다렸는가?”

확인 순서는 단순하다.

1. p95 / p99 변화
2. 처리 시간(Service Time) vs 전체 시간
3. 타임아웃/재시도 증가 여부

이 셋이 맞물리면
큐가 이미 생겼다는 뜻이다.

 

---

5. 가장 먼저 해야 할 것 #2: 빠른 거절 지점을 만든다

느림을 봤다면
다음 질문은 이거다.

“어디에서 멈출 수 있는가?”

즉시 가능한 선택들:

• 앞단에서 요청 제한
• 특정 기능 임시 차단
• 무거운 요청 분리
• 캐시 강제 사용

성능 대응의 1순위는
‘더 잘 처리하기’가 아니라
‘덜 받기’다.

---

6. 그 다음에 해야 할 것: 재시도 통제

느림 + 재시도는
가장 위험한 조합이다.

즉시 점검해야 할 것:

• 클라이언트 재시도 횟수
• 재시도 간격
• 서버 내부 재시도 존재 여부

재시도는
느림을 회복시키지 않는다.
느림을 증폭시킨다.

필요하면 일시적으로 재시도를 끈다.

---

7. 마지막에 해야 할 것: 원인 제거

여기까지 왔으면
이제서야 “원인”을 건드릴 차례다.

• 특정 API 분리
• 워커/비동기 전환
• 큐 길이 제한
• 타임아웃 재설계

중요한 순서:

시스템을 살린 다음에,
구조를 고친다.

---

8. Node.js / Java 공통 대응 원칙

런타임이 달라도
대응 원칙은 같다.

• Node.js
  → 이벤트 루프 보호, 큐 단축
• Java
  → 스레드 풀 보호, 대기열 제한

하지만 첫 행동은 동일하다.

거절 지점 확보 → 대기 제거 → 재시도 통제

---

9. 성능 대응을 망치는 한 문장

이 문장이 나오면
거의 항상 늦었다.

“조금만 더 지켜볼까요?”

느림은 지켜보는 대상이 아니라
즉시 형태를 바꿔야 하는 신호다.

---

10. 한 문장 정리

성능 장애 대응의 핵심은
‘더 잘 고치는 것’이 아니라
‘먼저 덜 망가뜨리는 것’이다.

---

다음 글 예고

관측 파트의 마지막 질문은 이것이다.

“그럼
장애가 오기 전에
어디까지 예측할 수 있는가?”

다음 글에서는
사전 신호를 읽는 법을 다룬다.

장애는 언제나
미리 신호를 보낸다
— 느림이 ‘사고’가 되기 전의 패턴

이제 관측은
사후 분석을 넘어 예측으로 간다.