관측성 3대 신호 로그·메트릭·트레이스 차이와 추적 ID 연결법 정리

핵심 메시지

• 로그·메트릭·트레이스는 같은 것의 다른 이름이 아니라 각각 '무엇이(메트릭)·어디서(트레이스)·왜(로그)'라는 다른 질문에 답하는 신호다.
• 메트릭은 값을 시간순으로 집계해 싸고 빠르지만 세부 정보가 없고, 로그는 가장 자세하지만 비싸고 한 서비스 안만 본다.
• 트레이스는 하나의 요청을 모든 서비스에 걸쳐 추적 ID와 스팬 트리로 따라가 '어디서 시간이 걸렸는지'를 보여 준다.
• 세 신호를 잇는 것은 같은 추적 ID이며, OpenTelemetry로 로깅과 추적을 한 번 연결하면 모든 로그 줄에 추적 ID가 자동으로 남는다.
• 메트릭→트레이스→로그(증상→위치→원인)로 이동하면 3시간 걸릴 디버깅이 3분으로 줄어든다.

쉽게 이해하기

한밤중 결제 실패 알림이 울려 로그를 열면 초당 수천 줄이 쏟아지지만 정작 '왜' 깨졌는지는 어디에도 없다. 영상은 로그·메트릭·트레이스를 흔히 같은 것의 다른 이름처럼 다루지만, 사실 각각이 다른 질문에 답하는 별개의 신호이며 이를 혼동하면 10분짜리 문제가 몇 시간으로 늘어난다고 지적한다. 관측성이란 시스템이 표면에 드러내는 신호로 내부에서 무슨 일이 벌어지는지 알아내는 일이다.

로그는 특정 시각에 일어난 하나의 사건을 기록한 '프로그램의 일기'다. 사람만 읽을 수 있는 평문 대신 이름 붙은 필드를 가진 구조화 로그(JSON)로 남기면 '최근 10분간 결제 서비스의 모든 오류'처럼 빠른 검색이 가능해진다. 로그는 가장 자세하지만 두 가지 비용이 있다. 규모가 커지면 저장·검색이 느리고 비싸며, 한 줄만으로는 무엇이 그 서비스를 호출했는지·직전에 무슨 일이 있었는지를 알 수 없어 맥락이 끊긴다.

메트릭은 로그의 반대편으로, 시간에 따라 추적되는 하나의 숫자다. 초당 요청 수·오류율·메모리·지연시간처럼 시스템 전체를 집계한다. 값만 올라가는 카운터, 오르내리는 게이지, 분포를 담는 히스토그램(P95·P99 같은 느린 사용자 지연 확인)으로 나뉜다. 숫자라서 싸고 빨라 대시보드와 알림에 적합하지만, 집계 과정에서 세부 정보를 버리므로 '오류율이 5%로 뛰었다'는 알려도 '어떤 요청이' 실패했는지는 말해 주지 못한다. 사용자 ID 같은 고카디널리티 데이터를 메트릭 라벨에 넣으면 시계열이 폭증하니 그런 정보는 로그·트레이스에 두어야 한다.

현대 시스템은 하나의 결제 요청이 게이트웨이·인증·장바구니·재고·결제·DB로 여러 홉을 거치는데, 로그와 메트릭은 요청이 다음 서비스로 넘어가는 순간 맥락을 잃는다. 트레이스는 이 빈틈을 메운다. 요청이 게이트웨이에 도착하면 소포의 송장번호 같은 고유 추적 ID가 부여되고, 각 작업 단위는 이름·시작시각·소요시간·태그를 가진 '스팬'이 된다. 스팬은 부모 스팬을 가리키며 트리를 이루고, 추적 ID와 스팬 ID는 보통 W3C trace context의 traceparent 헤더에 실려 서비스 경계마다 전달된다. 스팬을 타임라인에 펼친 워터폴을 보면 결제 스팬 2초 중 1.9초가 부정거래 점검 호출에서 쓰였다는 사실이 드러난다.

세 신호는 '완전한 세부정보·낮은 비용·전체 커버리지'를 동시에 가질 수 없어 각자 하나씩 포기한 한 가지 트레이드오프의 세 모서리다. 그래서 셋 다 필요하며, 이들을 하나로 묶는 것이 같은 추적 ID다. 메트릭 알림에서 exemplar로 연결된 트레이스로 한 번에 점프하고, 그 스팬에서 추적 ID로 필터링한 로그로 들어가면 증상→위치→원인으로 이어진다. 필요한 변경은 작다. 구조화 로그에 추적 ID·스팬 ID 두 필드를 더하고 OpenTelemetry에서 로거와 추적 라이브러리를 한 번 연결하면 된다.

주요 인사이트

• 신호 선택의 기준은 '무엇(메트릭)·어디서(트레이스)·왜(로그)'라는 세 단어로 요약된다. 어느 질문에 답해야 하는지를 먼저 정하면 어떤 신호를 봐야 할지가 정해진다.
• 대규모에서는 모든 요청을 추적하면 비싸므로 샘플링한다. 요청 시작 시점에 정하는 헤드 기반과, 트레이스 완료 후 결정해 원하는 트레이스를 확실히 남기는 테일 기반 두 방식이 있다.
• Prometheus(메트릭), Jaeger·Tempo·Zipkin(트레이스), Loki·ELK(로그)처럼 도구는 바뀌어도 역할은 그대로다. OpenTelemetry는 특정 벤더에 묶이지 않고 세 신호를 모두 내보내며 맥락을 함께 전달한다.
• 구조화 로그는 평문 로그와 달리 검색이 가능해, grep으로 몇 시간 걸릴 조회를 한 번의 빠른 검색으로 바꾼다. 자세함이 필요할 때 로그만 한 신호가 없다.

자주 묻는 질문

관련 AI 소식