본문 바로가기
system_fundamentals/observability

우리는 무엇을, 어디서, 어떻게 봐야 하는가

by 죄니안죄니 2026. 1. 5.
반응형

지금까지 “왜 망가지는가”를 봤다면, 이제는 **“그걸 어떻게 알아채는가”**로 넘어간다.


우리는 무엇을, 어디서, 어떻게 봐야 하는가

— 성능 문제를 감(感)에서 숫자로 바꾸는 첫 단계

성능 장애를 몇 번 겪고 나면
이런 말이 자연스럽게 나온다.

  • “그때 뭔가 이상했는데…”
  • “지표를 봤으면 알았을 것 같은데…”
  • “로그는 있었는데 연결이 안 됐어요”

이 말들의 공통점은 하나다.

봤지만, 이해하지 못했다.

관측(observability)은
로그를 많이 쌓는 일이 아니다.
지표를 많이 그리는 일도 아니다.

관측이란
‘시스템의 내부 상태를
질문할 수 있는 능력’이다.


1. 모니터링과 관측은 다르다

먼저 이 차이를 명확히 하자.

  • 모니터링
    → “이 값이 임계치를 넘었나?”
  • 관측(Observability)
    → “왜 이 값이 이렇게 되었나?”

CPU 그래프를 보고
“30%네”라고 말하는 건 모니터링이다.
그 상태에서 왜 응답이 안 오는지 설명할 수 있으면
그게 관측이다.


2. 우리가 앞에서 계속 실패한 이유

performance_failure_basics에서
계속 같은 패턴을 봤다.

  • CPU는 낮다
  • 메모리는 남는다
  • 서버는 살아 있다
  • 그런데 사용자는 실패한다

이때 우리가 놓친 건 이거다.

대기(wait)와 점유(block)를
거의 보지 않았다.

CPU는 실행 시간만 보여준다.
하지만 장애의 원인은 대부분:

  • 큐에서 기다리는 시간
  • 락을 기다리는 시간
  • I/O를 기다리는 시간
  • 이벤트 루프를 기다리는 시간

이었다.


3. 그래서 관측의 출발점은 항상 같다

관측을 시작할 때
가장 먼저 던져야 할 질문은 이거다.

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

이 질문에 답하지 못하면:

  • 로그가 있어도 소용없고
  • 메트릭이 많아도 소용없다

4. 관측해야 할 것은 생각보다 단순하다

처음부터 분산 트레이싱, APM, 대시보드
다 필요 없다.

딱 이 세 가지면 시작할 수 있다.

  1. 처리 시간 (Service Time)
  2. 대기 시간 (Wait Time)
  3. 거절/실패 (Reject / Fail)

이 세 가지를 합치면
우리가 앞에서 다룬 모든 문제가 설명된다.

우리는 무엇을, 어디서, 어떻게 봐야 하는가우리는 무엇을, 어디서, 어떻게 봐야 하는가
 

5. CPU·메모리는 왜 항상 우리를 속였나

이제 이유가 보인다.

  • CPU: 실행 중이냐 아니냐만 본다
  • 메모리: 쌓였는지 아닌지만 본다

하지만 성능 장애의 핵심은:

“실행되지 못한 시간”

이다.

이 시간은:

  • 큐에 있고
  • 락에 있고
  • 타임아웃을 기다리고 있고

CPU 그래프에는 안 나온다.


6. 관측은 “지표의 개수”가 아니라 “질문의 방향”이다

지표를 100개 그려도
이 질문에 답 못 하면 무의미하다.

  • 지금 느린 요청은 어디서 막혔나?
  • 전체 중 몇 %가 대기 중인가?
  • 실패는 빠르게 드러나는가?
  • 재시도는 언제 발생했나?

관측은
사후 분석을 위한 기록이 아니라
실시간 질문을 위한 구조
다.


7. Node.js · Java 관측의 공통 기준

런타임은 달라도
관측 기준은 같다.

  • Node.js
    → 이벤트 루프 지연, 큐 길이, 처리 시간 분해
  • Java
    → 스레드 대기 시간, 풀 사용률, 대기 큐

하지만 질문은 동일하다.

“일을 못 하는 시간은
어디에 숨어 있는가?”


8. 로그부터 볼까, 메트릭부터 볼까?

정답은 이거다.

“메트릭으로 의심하고,
로그로 확인한다.”

  • 메트릭: 전체 상태 파악
  • 로그: 개별 요청 맥락

순서를 바꾸면
항상 길을 잃는다.


9. 관측이 되기 시작했다는 신호

이 순간이 오면
관측이 자리 잡기 시작한 거다.

  • “CPU는 낮은데요”라는 말이 사라진다
  • 대신 이렇게 말한다
    → “요청의 80%가 큐에서 2초 대기합니다”

이건 차원이 다른 대화다.


10. 한 문장 정리

관측이란
시스템이 왜 느려졌는지를
‘설명할 수 있는 상태’다.


다음 글 예고

이제 질문은 더 구체해진다.

“그럼
큐와 대기는
어떤 지표로 드러나는가?”

다음 글에서는
큐·대기·점유를
숫자로 보는 방법
을 다룬다.

이제 진짜로
감이 아니라 데이터로
시스템을 보기 시작한다.

반응형

댓글