관측이란 무엇을 보는 기술이 아니라 언제 행동할지를 정하는 기술

이 글은 관측(observability) 카테고리의 마지막 글,
지금까지 쌓은 모든 개념을 운영 판단 기준 하나로 압축하는 글이다.
톤은 정리이되, 실무 선언처럼 간다.

---

관측이란 무엇을 보는 기술이 아니라 언제 행동할지를 정하는 기술이다

— 운영에서 살아남는 관측의 기준

관측을 도입한 팀이
가장 먼저 착각하는 게 있다.

• “지표를 다 보고 있다”
• “대시보드가 잘 되어 있다”
• “로그도 충분하다”

그런데 장애는 그대로 난다.

이유는 단순하다.

봤지만,
언제 움직여야 하는지
결정하지 않았기 때문이다.

관측의 목적은
이해가 아니라 결정이다.

---

1. 관측의 실패는 “정보 부족”이 아니다

지금까지 본 패턴을 떠올려보자.

• CPU는 낮았다
• 평균은 정상처럼 보였다
• 타임아웃은 늦게 왔다
• 재시도는 이미 폭발 중이었다

이건 지표가 없어서가 아니다.

지표에
‘의미’를 붙이지 않았기 때문이다.

---

2. 관측의 핵심 질문은 하나로 수렴한다

지금부터 관측은
이 질문 하나로 요약된다.

“지금 이 시스템은
정상 범위를 벗어났는가?”

이 질문에 답할 수 없다면
아무리 많은 지표도 소용없다.

---

3. 정상 범위는 숫자가 아니라 ‘패턴’이다

많은 팀이 여기서 실패한다.

• “p95 500ms면 위험?”
• “CPU 70%면 경고?”

이건 잘못된 접근이다.

정상 범위는:

• 하루 중 시간대별로 다르고
• 요일별로 다르고
• 트래픽 패턴별로 다르다

그래서 필요한 건 이거다.

“평소에는 어땠는가?”

관측은 기억이 있어야 작동한다.

---

4. 행동 기준이 없는 지표는 소음이다

이 지표를 보자.

• p95 = 800ms

이 숫자는
아무 의미도 없다.

하지만 이렇게 바뀌면 달라진다.

“p95가
평소 대비 2배 이상으로
10분 이상 유지됐다”

이 순간,
지표는 행동을 요구한다.

---

5. 관측이 완성되는 순간의 대화 변화

관측이 자리 잡은 팀은
이렇게 말하지 않는다.

• “좀 느린 것 같아요”
• “CPU는 괜찮은데요”

대신 이렇게 말한다.

• “p95가 기준선을 넘었고”
• “대기 시간이 누적되고 있으며”
• “지금 개입 안 하면 p99가 터집니다”

이건 기술의 차이가 아니라
언어의 차이다.

---

6. 관측의 최종 산출물은 ‘플레이북’이다

관측이 잘 된 팀의 특징은 하나다.

느림이 보이면
무엇을 할지
이미 정해져 있다.

예를 들면:

• p95 상승 → 요청 제한
• p99 스파이크 → 기능 축소
• 타임아웃 증가 → 재시도 차단

이건 즉흥 대응이 아니다.

관측은
행동을 자동화하기 위한 전제다.

---

7. 관측은 장애를 없애지 않는다

중요한 사실 하나.

관측은
장애를 막아주지 않는다.

하지만 이건 가능하게 만든다.

• 장애를 예측하고
• 피해를 제한하고
• 회복을 빠르게 한다

운영에서 이 차이는
압도적이다.

---

8. 지금까지의 흐름을 한 줄로 요약하면

• 큐는 쌓인다
• 재시도는 증폭된다
• 타임아웃은 늦을수록 위험하다
• CPU는 우리를 속인다
• 퍼센타일은 신호를 보낸다
• 관측은 행동 시점을 정한다

이 모든 게
하나의 이야기였다.

---

9. 관측이 실패하는 마지막 이유

마지막으로 가장 흔한 실패 원인.

“이 정도는
아직 괜찮겠지.”

이 말은
관측을 의견으로 되돌린다.

관측은 의견이 아니다.

관측은
‘지금 움직여야 한다’는
합의된 기준이다.

---

10. 한 문장 정리

관측이란
시스템을 보는 기술이 아니라,
시스템을 언제 바꿀지
결정하는 기술이다.

---

다음 단계 예고

이제 남은 질문은 하나다.

“이 모든 기준을
실제 코드와 시스템에
어떻게 녹일 것인가?”

다음 카테고리에서는
이 개념들을 설계와 구현으로 옮긴다.

• 백프레셔를 코드로 표현하는 법
• 큐를 제한하는 실제 패턴
• 느림을 구조로 흡수하는 설계

이제부터는
개념이 아니라 구조의 문제다.