장애가 났을 때 ‘서버가 느립니다’는 알지만 ‘왜 느린지’는 모르는 상황, 익숙하실 겁니다. 전통적 모니터링은 알고 있는 문제만 잡지만, 옵저버빌리티는 예상치 못한 문제도 사후에 파고들 수 있게 해줍니다. 그 토대가 로그, 메트릭, 트레이스라는 세 기둥입니다.
운영 문제: 데이터는 많은데 답이 없다
세 신호를 각각 따로 수집하면, 메트릭에서 지연 급증을 봐도 어느 요청 때문인지 추적할 수 없습니다. 옵저버빌리티의 진짜 가치는 세 신호를 상관(correlation)시켜 하나의 사건을 입체적으로 재구성하는 데 있습니다.
세 기둥의 역할
- 메트릭: 무슨 일이 일어나는가 (수치·추세, 저비용·고압축)
- 로그: 정확히 무엇이 일어났는가 (이벤트의 맥락)
- 트레이스: 어디서 시간이 걸렸는가 (요청의 전체 경로)
메트릭으로 이상을 감지하고, 트레이스로 병목 구간을 좁힌 뒤, 로그로 근본 원인을 확인하는 흐름이 이상적인 디버깅 동선입니다.
구현: 상관관계의 열쇠는 trace_id
세 신호를 엮는 결정적 장치는 모든 신호에 공통 trace_id를 심는 것입니다. 로그 한 줄에서 trace_id를 클릭하면 해당 요청의 전체 트레이스로 점프할 수 있어야 합니다.
{
"ts": "2026-06-25T09:14:02Z",
"level": "error",
"trace_id": "a1b2c3d4",
"service": "checkout",
"msg": "payment timeout",
"latency_ms": 5021
}OpenTelemetry 같은 표준을 쓰면 언어·프레임워크가 달라도 동일한 trace_id 전파 규약을 공유할 수 있어, 마이크로서비스 전체를 하나의 추적 망으로 연결할 수 있습니다.
비용: 다 저장하면 파산한다
옵저버빌리티의 함정은 비용입니다. 모든 로그와 트레이스를 100% 보관하면 데이터 비용이 인프라 비용을 넘어서기도 합니다. 정상 트래픽은 1~5%만 샘플링하고 에러·고지연 요청은 100% 보관하는 테일 샘플링이 비용과 가시성의 균형점입니다.
정리
옵저버빌리티는 도구를 사는 게 아니라 신호를 엮는 설계입니다. 공통 trace_id로 세 기둥을 연결하고, 똑똑한 샘플링으로 비용을 통제하면, 처음 보는 장애 앞에서도 자신 있게 질문을 던지고 답을 찾을 수 있습니다.
