관측가능성이 푸는 문제 - 터졌는데 어디가 문제인지 모른다

서비스가 여러 조각으로 나뉘면 “느려요” 신고 하나에 범인 후보가 수십이다. 어디부터 보나 - 그 물음이 이 시리즈다.

잘 돌던 게 갑자기 느려졌다

사용자가 “주문이 느려요”라고 한다. 그런데 주문 하나는 인증·재고·결제·배송 여러 서비스를 지난다(마이크로서비스). 로그를 열어도 서비스마다 따로 찍혀서, 이 요청이 어디서 막혔는지가 안 보인다. 스레드가 다 묶여 서비스가 통째로 죽는 일도(서킷 브레이커) 겉에서는 그냥 “느림”으로 보인다.

범인은 하나인데 후보가 수십이다. 이 막막함을 없애는 게 관측가능성이다.

모니터링은 아는 것만 본다

먼저 익숙한 것부터. 모니터링은 CPU·메모리·에러율처럼 미리 정한 지표를 대시보드로 지켜보는 것이다. 예상한 고장에는 훌륭하다 - “CPU 90% 넘으면 알림”은 무엇을 볼지 미리 알아서 판을 깔아둔 것이다.

문제는 처음 보는 고장이다. 대시보드에 없는 축으로 터지면, 그래프는 전부 초록인데 사용자만 아프다. 무엇을 볼지 미리 정해뒀기 때문에, 정해두지 않은 것은 영영 안 보인다.

관측가능성은 출력으로 내부를 설명하는 힘이다

관측가능성(observability)은 원래 제어이론 용어다 - 밖에서 보이는 출력만으로 시스템 내부 상태를 알아낼 수 있느냐를 뜻한다. 소프트웨어로 옮기면 이렇다. 코드를 새로 고쳐 심지 않고, 이미 나오는 신호만으로 “왜 이렇게 됐나”에 답할 수 있나.

모니터링이 “미리 정한 질문에 답하는 것”이라면, 관측가능성은 미처 못 했던 질문을 나중에 던질 수 있게 해두는 것이다. “어젯밤 그 느린 요청, 어느 사용자의 어떤 상품이었지?”를 사고가 난 뒤에 물어도 답이 나오게.

세 기둥이 각자 다른 질문에 답한다

그 힘은 세 가지 신호에서 나온다. 흔히 세 기둥이라 부른다.

이 시리즈는 이 셋을 차례로 판다 - 로그, 메트릭, 트레이스. 그다음 언제 사람을 부를지(헬스체크와 알림), 마지막에 셋을 하나로 잇는 실무를 본다.

하나로는 안 된다

왜 셋 다 필요할까. 각자 못 하는 게 있어서다.

• 로그만 있으면 - 사건 하나하나는 자세하지만, “지금 전체가 어떤가”를 못 센다. 초당 수천 줄을 눈으로 읽을 수 없다.
• 메트릭만 있으면 - “에러율이 5%“라는 건 알지만, 그 5%가 왜인지, 어떤 요청이었는지는 모른다.
• 트레이스만 있으면 - 요청 하나의 경로는 보이지만, 그게 흔한 일인지 드문 일인지(전체 분포)는 메트릭이 안다.

셋은 겹치는 게 아니라 서로의 빈칸을 메운다. 그래서 하나만 갖추면 늘 반쪽이다.

관측가능성은 공짜가 아니다

신호를 남기는 데는 값이 든다. 로그는 양이 폭발하고, 메트릭은 쪼개는 축이 늘면 비용이 뛰고(카디널리티 - 메트릭 편에서), 트레이스는 전부 담으면 감당이 안 돼 골라 담는다(샘플링 - 트레이싱 편에서).

그래서 관측의 실무는 “다 남기자”가 아니라 늘 **“무엇을 남길까”**다. 이 비용 감각을 편마다 함께 짚는다.

실무에서: 나중에 붙이기 어렵다

관측은 코드 곳곳에 **계측(instrumentation)**을 심어야 나온다. 사고가 난 뒤에 붙이면 늦다 - 그 순간의 상태는 이미 사라졌으니까. 그래서 처음부터 심는다.

요즘은 OpenTelemetry라는 표준으로 로그·메트릭·트레이스를 한 규격으로 심는다(마지막 편에서 정면으로). 핵심 규칙은 단순하다 - 수집·저장·시각화는 성숙한 도구에 맡기고, 우리는 무엇을 어디에 심을지만 잘 정한다.

정리

• 서비스가 나뉘면 “느리다” 신고 하나에 범인 후보가 수십이다. 모니터링은 미리 정한 것만 본다.
• 관측가능성은 이미 나오는 신호만으로 “왜 이렇게 됐나”에 답하는 힘 - 미처 못 한 질문을 나중에 던지게 한다.
• 세 기둥이 각자 다른 질문에 답한다 - 로그(무슨 일), 메트릭(지금 어떤가), 트레이스(어디서 느렸나). 하나로는 안 된다.
• 공짜가 아니라 무엇을 남길지가 늘 문제다 - 다음 글부터 하나씩 판다.

다음 글은 가장 오래되고 직관적인 신호, 로그부터 본다.