목차
세 기둥을 각각 배웠다. 마지막 물음은 이것이다 - 이 셋을 어떻게 하나처럼 쓰나. 따로 있으면 아직 반쪽이다.
세 기둥을 다시 모으면
시리즈가 지나온 셋을 한자리에 놓는다.
각자 강한 곳과 못 하는 곳이 정확히 엇갈린다. 하나의 약점이 다른 하나의 강점이다. 그래서 셋은 따로가 아니라 함께 있어야 제 몫을 한다.
따로 있으면 반쪽이다
셋이 연결 없이 따로 있으면 어떻게 될까. 조사가 매번 벽에 막힌다.
- 메트릭이 “결제 p99 폭등”을 보여준다. → 그런데 어느 요청이 느렸지? 메트릭엔 없다.
- 느린 트레이스를 찾았다. → 그 순간 무슨 에러 로그가 있었지? 트레이스에서 로그로 넘어갈 길이 없다.
신호는 다 있는데 서로를 못 가리켜서, 사람이 세 화면을 번갈아 눈으로 맞춰야 한다. 사고 한복판에서 이건 치명적으로 느리다.
상관관계: trace ID가 셋을 잇는다
해법은 이미 로그와 트레이싱에서 깔아뒀다 - 모든 신호에 같은 trace ID를 박는 것.
메트릭에서 이상을 보고 → 그 시간대의 느린 트레이스로 내려가고 → 그 trace ID로 정확한 로그를 집는다. 세 신호를 하나의 실로 꿰는 이 흐름이 관측가능성의 완성형이다. “이상하다(메트릭) → 어디서(트레이스) → 왜(로그)“가 클릭 몇 번으로 이어진다.
OpenTelemetry: 한 규격으로 심는다
이 그림이 되려면 세 신호가 같은 규격으로 심겨야 한다. 예전엔 로그 라이브러리 따로, 메트릭 SDK 따로, 트레이싱 도구 따로여서 trace ID가 서로 안 맞았다.
OpenTelemetry(OTel)가 이걸 표준으로 묶었다. 계측을 OTel 규격으로 한 번 심으면,
- 로그·메트릭·트레이스가 **같은 컨텍스트(trace ID)**를 공유하고,
- 수집한 신호를 어느 백엔드로도 보낼 수 있다(특정 벤더에 안 묶인다).
계측(우리 코드)과 저장·시각화(도구)를 갈라놓은 것이다. 우리는 표준대로 심기만 하고, 도구는 나중에 갈아끼운다.
무엇을 남길지가 여전히 문제다
기둥을 다 세워도 첫 글에서 예고한 비용은 사라지지 않는다. 오히려 여기서 다 만난다.
그래서 관측의 실무는 처음부터 끝까지 **“무엇을 남기고 무엇은 버릴까”**의 저울질이다. 정답은 고정값이 아니라, 이 서비스에서 사고를 풀 때 실제로 답이 되는 신호가 무엇이냐로 정한다.
관측가능성은 문화이기도 하다
도구만 깔면 되는 게 아니다. 관측이 사는 팀은 습관이 다르다.
- 기능을 만들 때 계측을 함께 심는다(나중에 붙이면 늦으니까).
- 알림마다 다음 행동을 붙인다(런북).
- 사고 뒤엔 **“왜 늦게 알았나”**를 돌아봐 신호와 알림을 고친다.
기술은 신호를 만들 뿐이고, 그걸 실제로 보고 고치는 건 사람의 습관이다.
실무에서: 직접 만들지 않는다
- 계측만 표준(OTel)으로 잘 심는다. 수집·저장·대시보드·알림은 성숙한 도구 스택에 맡긴다.
- 세 신호에 trace ID를 반드시 공유시킨다 - 이게 없으면 아무리 많이 남겨도 서로 못 잇는다.
- 비용을 처음부터 설계한다 - 카디널리티 상한, 샘플링 비율, 보관 기간을 정해두고 시작한다.
정리
- 세 기둥은 강점과 약점이 엇갈려서, 따로 있으면 반쪽이고 함께여야 제 몫을 한다.
- trace ID가 셋을 잇는다 - “이상하다(메트릭) → 어디서(트레이스) → 왜(로그)“를 하나의 실로 꿴다.
- OpenTelemetry로 한 규격으로 심어 컨텍스트를 공유하고 벤더 종속을 푼다.
- 끝까지 남는 문제는 무엇을 남길지의 비용 - 그리고 신호를 보고 고치는 건 결국 팀의 습관이다.
여기까지가 이 시리즈다. “터졌는데 어디가 문제인지 모른다”에서 시작해, 무슨 일이 있었는지(로그)·지금 어떤지(메트릭)·어디서 느렸는지(트레이스)를 세우고, 언제 사람을 부를지(알림)를 정한 뒤, 마지막에 셋을 하나의 실로 꿰었다. 관측가능성은 신호를 많이 남기는 게 아니라, 급할 때 답이 되는 신호를 골라 잇는 일이다.