Chaos and Order

💡 왼쪽 원문을 읽으면서 오른쪽에 따라 써보세요. Tab 키로 힌트를 받을 수 있습니다.

프롤로그 — "왜 결제가 느린가요?"라는 질문에서 시작한다

2026년 어느 금요일 저녁, 결제팀 슬랙 채널에 알람이 울린다.

"p99 결제 지연 4.2초. 평소 600ms. 무엇이 느려졌나?"

이런 질문에 5분 안에 답하기 위해 인류는 지난 10년간 분산 추적(distributed tracing)을 만들어 왔다. 한 요청이 게이트웨이를 지나, 인증을 거쳐, 결제 코어로 들어가서, 외부 PG를 호출하고, 영수증 큐에 쌓이는 — 그 모든 홉(hop)을 한 줄의 트레이스로 본다.

2020년만 해도 이 분야는 OpenTracing, OpenCensus, Jaeger 클라이언트, Zipkin 라이브러리, 각 APM 벤더의 에이전트가 난립했다. 같은 회사 안에서도 자바는 Datadog 에이전트, Go는 Jaeger 클라이언트, Node는 New Relic을 쓰는 식이었다. 2026년에는 답이 단순해졌다 — OpenTelemetry.

이 글은 2026년 분산 추적의 지도를 그린다. OTel 사양과 Collector, 전파 표준, OSS 백엔드(Jaeger/Tempo/Zipkin), observability 2.0 진영(Honeycomb/SigNoz), 인수된 거물(Lightstep), APM 슈퍼리그(Datadog/New Relic/Dynatrace/Splunk), eBPF 자동 계측(Pixie/Beyla), 그리고 샘플링과 비용까지. 한국·일본 회사들이 실제로 어떻게 마이그레이션했는지도.

1장 · 2026년 분산 추적 지도 — 4분류

분산 추적 생태계는 거칠게 네 묶음으로 나뉜다.

묶음	대표	성격
표준/계측	OpenTelemetry	공통 사양·SDK·Collector. 거의 모두가 이걸 통한다
OSS 셀프호스팅 백엔드	Jaeger, Tempo, Zipkin, SigNoz, SkyWalking	직접 운영. 라이선스 비용 없음
APM SaaS	Datadog, New Relic, Dynatrace, Splunk, AppDynamics, Sentry, Elastic	매니지드. 통합 UI + 알람 + AIOps
observability 2.0	Honeycomb, Lightstep(ServiceNow)	와이드 이벤트·고카디널리티 분석
eBPF 자동 계측	Pixie, Beyla, Coroot	코드 변경 없이 커널/네트워크에서

세 축을 동시에 보면 좋다.

              OSS                              SaaS
        ┌──────────────┐              ┌─────────────────┐
계측    │ OTel SDK     │  ─── 호환 ──▶ │ OTel SDK         │
        │ (벤더-중립)   │              │ (벤더 어댑터)     │
        └──────┬───────┘              └────────┬────────┘
               │                                │
        ┌──────▼─────────────────────────────────▼─────────┐
        │            OpenTelemetry Collector               │
        │   receivers ──▶ processors ──▶ exporters         │
        └──────┬─────────────────────────────────┬─────────┘
               │                                  │
       ┌───────▼────────┐                ┌────────▼────────┐
       │ Jaeger / Tempo │                │  Datadog APM    │
       │ Zipkin / SigNoz│                │  New Relic APM  │
       │ SkyWalking     │                │  Honeycomb 등   │
       └────────────────┘                └─────────────────┘

핵심: 계측은 OTel에 통일하고, 백엔드는 갈아끼울 수 있게 한다. 이게 2026년의 표준 자세다.

2장 · OpenTelemetry — CNCF 졸업 (2024)

OpenTelemetry(OTel)는 OpenTracing(2016)과 OpenCensus(2018)의 합병으로 2019년에 출발했다. 2021년 CNCF 인큐베이팅, 2024년 11월 CNCF 졸업(graduated)으로 사실상 산업 표준이 됐다. Kubernetes 다음으로 CNCF 활동이 활발한 프로젝트다.

OTel이 제공하는 것:

사양(Specification): 무엇이 트레이스이고, 무엇이 스팬이고, 어떤 속성을 가지는가.
API: 언어별 계측 API (Java, Go, Python, .NET, Node.js, Ruby, PHP, Rust, C++, Swift…).
SDK: API의 참조 구현 — 샘플링, 배치, 익스포터 포함.
Collector: 별도 프로세스로 도는 텔레메트리 파이프라인.
Semantic Conventions: HTTP, DB, 메시징 등의 표준 속성 이름.
OTLP(OpenTelemetry Protocol): gRPC/HTTP 기반 와이어 포맷.

핵심 데이터 모델: 트레이스 = 스팬의 트리. 각 스팬은 trace_id, span_id, parent_span_id, start/end, 속성, 이벤트, 링크를 가진다.

from opentelemetry import trace
from opentelemetry.sdk.trace import TracerProvider
from opentelemetry.sdk.trace.export import BatchSpanProcessor
from opentelemetry.exporter.otlp.proto.grpc.trace_exporter import OTLPSpanExporter

trace.set_tracer_provider(TracerProvider())
trace.get_tracer_provider().add_span_processor(
    BatchSpanProcessor(OTLPSpanExporter(endpoint="otel-collector:4317"))
)

tracer = trace.get_tracer("checkout")
with tracer.start_as_current_span("charge_card") as span:
    span.set_attribute("user.id", user_id)
    span.set_attribute("amount", amount)
    result = pg.charge(...)
    span.set_attribute("pg.response_code", result.code)

OTel의 진짜 가치는 메트릭·로그·트레이스를 같은 SDK로 다룬다는 점이다. 트레이스가 졸업 안정이고, 메트릭이 안정, 로그가 2024~2025년에 대부분 언어에서 안정으로 진행됐다. 이제 OTel은 단순한 트레이스 표준이 아니라 통합 텔레메트리 표준이다.

3장 · OTel Collector — Receivers · Processors · Exporters

OTel SDK가 앱 안에 들어간다면, Collector는 앱 밖에 도는 별도 프로세스다. 별도로 떼낸 이유:

앱이 백엔드 SDK를 직접 들이지 않아도 됨 — 의존성 관리가 쉬워짐.
샘플링·필터링·라우팅을 중앙에서 적용.
백엔드를 바꿔도 앱은 재시작 안 함.
트래픽 폭주 시 큐잉·재시도.

Collector의 핵심 3축:

컴포넌트	역할	예
Receivers	수신 — 외부에서 텔레메트리 받기	otlp, jaeger, zipkin, prometheus, kafka, filelog
Processors	가공 — 변환·필터링·샘플링	batch, memory_limiter, tail_sampling, attributes
Exporters	송신 — 백엔드로 내보내기	otlp, jaeger, prometheus, datadog, honeycomb, logging

이 3축이 파이프라인으로 연결된다.

receivers:
  otlp:
    protocols:
      grpc:
        endpoint: 0.0.0.0:4317
      http:
        endpoint: 0.0.0.0:4318

processors:
  batch:
    timeout: 5s
    send_batch_size: 1024
  memory_limiter:
    check_interval: 1s
    limit_mib: 1500
  tail_sampling:
    decision_wait: 30s
    policies:
      - name: errors
        type: status_code
        status_code: { status_codes: [ERROR] }
      - name: slow
        type: latency
        latency: { threshold_ms: 1000 }
      - name: sample_10
        type: probabilistic
        probabilistic: { sampling_percentage: 10 }

exporters:
  otlp/tempo:
    endpoint: tempo:4317
    tls: { insecure: true }
  datadog:
    api: { site: datadoghq.com, key: ENV_DD_API_KEY }

service:
  pipelines:
    traces:
      receivers: [otlp]
      processors: [memory_limiter, tail_sampling, batch]
      exporters: [otlp/tempo, datadog]

같은 트레이스를 OSS 백엔드(Tempo)와 SaaS(Datadog)로 동시에 보낼 수 있다. 이게 Collector가 마이그레이션 도구로 쓰이는 이유다 — 새 백엔드를 한 줄 추가로 병렬 비교, 검증 후 기존 것을 끈다.

Collector의 두 가지 모드:

Agent: 각 호스트/노드/Pod 사이드카에 1개. 트래픽이 작고 가까이서 수집.
Gateway: 클러스터/리전당 몇 개. 큐잉·테일 샘플링·중앙 정책에 적합.

대규모는 Agent → Gateway → 백엔드의 2단 구성을 많이 쓴다.

4장 · 전파 표준 — W3C Trace Context · B3 · Baggage

분산 추적이 "분산"인 이유는 같은 trace_id가 서비스 경계를 넘어 전파되기 때문이다. 전파는 보통 HTTP 헤더로 한다.

W3C Trace Context (2020 권고)

2020년 W3C가 표준화한 두 헤더가 2026년 사실상 디폴트다.

traceparent: 00-4bf92f3577b34da6a3ce929d0e0e4736-00f067aa0ba902b7-01
             │   │                                │                │
             │   trace-id (16 byte hex)            parent-span-id   trace-flags
             version

tracestate: vendor1=value1,vendor2=value2

traceparent: 모든 OTel SDK가 기본으로 송수신.
tracestate: 벤더별 부가 정보 (예: 샘플링 결정).

OTel SDK는 이 헤더를 HTTP·gRPC·메시징(Kafka, RabbitMQ 헤더)·심지어 일부 SQL 주석에까지 자동으로 주입한다.

B3 Propagation (Zipkin 출신)

Zipkin이 만든 멀티헤더 포맷.

X-B3-TraceId: 4bf92f3577b34da6a3ce929d0e0e4736
X-B3-SpanId: 00f067aa0ba902b7
X-B3-ParentSpanId: 05e3ac9a4f6e3b90
X-B3-Sampled: 1

OTel는 W3C와 B3를 동시 지원한다. 레거시 시스템과 섞일 때 양쪽을 다 받게 설정한다.

Baggage — "다음 서비스에 같이 가져가는 컨텍스트"

Baggage는 trace_id와는 별개의 키-값을 트레이스 전파와 함께 운반한다. 예: user.tier=gold, tenant=acme, experiment=ab_42.

baggage: user.tier=gold,tenant=acme

쓸 곳:

모든 다운스트림 스팬에 같은 라벨을 자동으로 붙이고 싶을 때.
샘플링 결정을 baggage 값에 따라 바꾸고 싶을 때 (예: "tenant=enterprise는 100% 샘플").
다운스트림에서 권한·로깅·라우팅에 참조.

주의: baggage는 비밀이 아니다. 다음 홉이 외부 시스템이면 누구나 헤더를 본다. PII는 절대 baggage에 넣지 않는다.

5장 · Jaeger — CNCF 졸업, Uber 출신 클래식

Jaeger는 Uber가 2015년에 만든 분산 추적 시스템이다. 2017년 CNCF 인큐베이팅, 2019년 CNCF 졸업. OTel 이전 시대의 사실상 표준이었다.

특징:

Go로 작성, 백엔드 모듈식.
저장소: Cassandra, Elasticsearch/OpenSearch, ClickHouse, Badger(임베디드).
UI: 트레이스 뷰, 의존성 그래프, 비교 뷰.
인입: 자체 SDK(deprecated)·Zipkin 프로토콜·OTLP(OpenTelemetry Protocol).

2024년 이후 Jaeger 프로젝트는 명시적으로 "OTel 우선"으로 방향을 틀었다. Jaeger 자체 SDK는 deprecated이고, 신규 사용자는 OTel SDK로 보내고 Jaeger를 "백엔드 + UI"로만 쓰는 게 권장 경로다. v2 백엔드는 내부적으로 OTel Collector를 빌드 베이스로 쓴다.

배포 모양:

AllInOne: 데모/개발용. agent + collector + query + UI + memory storage 한 컨테이너.
Production: collector + storage + query/UI 분리, agent는 호스트별.
Kubernetes Operator: jaegertracing/jaeger-operator로 CR 한 줄.

장점: 가볍고, OSS이고, 잘 깔린다. UI가 직관적이다.

한계: 메트릭/로그는 안 한다(트레이스 전용). 고카디널리티 분석은 약하다 — UI는 trace_id로 찾기·시간 범위 필터까지가 강점.

6장 · Grafana Tempo — Parquet 기반, "object storage가 hot path"

Grafana Tempo는 2020년에 Grafana Labs가 만든 트레이스 백엔드다. 컨셉이 명료하다 — "인덱스 없는 추적 저장소".

기존 Jaeger/Zipkin은 모든 스팬에 인덱스를 만든다(서비스·오퍼레이션·태그). 인덱스가 트레이스 본문보다 더 크고 더 비싸다. Tempo는 인덱스 없이 trace_id로만 검색한다 — 단, 메트릭(Prometheus)·로그(Loki)에서 trace_id를 뽑아서 연결한다는 전제다. "exemplar에서 클릭하면 트레이스가 나오는" UX.

저장은 S3/GCS/Azure Blob 같은 오브젝트 스토리지에 직접 한다. 인덱스 없으니 저장이 싸다. 2023년 이후 Parquet 포맷으로 통일됐다. 컬럼 저장 + 압축이 잘 되고, 외부 도구(Athena, DuckDB)로도 읽힌다.

쿼리 언어 TraceQL도 있다 — 트레이스 본문에서 패턴을 찾는다.

{ resource.service.name = "checkout"
  && span.http.status_code = 500
  && duration > 1s
}

장점:

저장 비용이 가장 싸다 — 오브젝트 스토리지 직저장.
Loki·Mimir·Grafana와 자연스럽게 연동.
Parquet이라 외부 분석 도구로도 끌고 갈 수 있다.

한계:

"메트릭/로그와 트레이스를 잇는 exemplar 워크플로"가 안 갖춰져 있으면 효용이 줄어든다.
일반 검색(서비스명·태그)은 Jaeger보다 약하다(대신 TraceQL).

대규모/장기 저장이 우선이면 Tempo가 답이다.

7장 · Zipkin — Twitter 원조, 살아있는 클래식

Zipkin은 Twitter가 2012년 오픈소스한 분산 추적 시스템이다. Google Dapper 논문의 가장 영향력 있는 OSS 구현체로, 이후 모든 트레이스 시스템의 출발점이 됐다.

특징:

Java 기반(브레이브 인스트루멘테이션).
저장소: 메모리(개발용), Cassandra, Elasticsearch, MySQL.
단순함 — 단일 jar로 떨어진다.
B3 전파의 원조.

2026년에는 신규 도입이 많지 않지만, 다음 경우에 여전히 쓴다.

이미 깔린 B3/Brave 자바 코드베이스의 백엔드.
"Jaeger도 너무 크다" 싶은 작은 시스템.
OTel Collector의 zipkin receiver/exporter로 변환 허브 역할.

Jaeger와 비교하면 — UI가 더 소박하지만, 셋업이 더 간단하다.

8장 · Honeycomb — Charity Majors의 "observability 2.0"

Honeycomb는 2016년 Charity Majors와 Christine Yen이 설립한 SaaS 옵저버빌리티 회사다. 이들이 만든 표현 "observability 2.0"이 업계 어휘를 바꿨다.

핵심 주장: 기존 모니터링(메트릭·로그·트레이스 분리)은 미리 정한 차원만 본다. 진짜 디버깅에 필요한 건 고카디널리티(user_id, request_id, k8s_pod 등) 차원을 자유롭게 슬라이스/다이스할 수 있는 와이드 이벤트(wide event)다.

Honeycomb의 데이터 모델: 모든 스팬은 사실상 "이벤트". 자유롭게 속성을 붙이고, 쿼리는 BubbleUp(이상치 자동 분해)·heatmap·trace 뷰를 자유롭게 오간다.

BubbleUp 결과 예:
  느린 요청(p95)의 73%가 user.tier=enterprise 이면서
  db.host=replica-3 이고
  client_country=JP 이다.
  ← 이런 결합을 사람이 미리 정하지 않아도 자동으로 찾는다.

차별점:

모든 차원을 인덱싱하지 않는다 — 자체 컬럼 스토리지(Retriever).
샘플링 SDK(Refinery) — 테일 샘플링의 사실상 표준.
OTel 100% 호환 인입.
가격: 이벤트 수(스팬 수)·보존 기간.

장점: 디버깅 속도가 다르다. "왜 느린가"를 인덱스 없이 1~2분 안에 좁힌다.

한계: SaaS-only(셀프호스팅 없음). 고카디널리티 풀세트가 필요 없는 단순한 모니터링에는 과하다.

9장 · Lightstep → ServiceNow Cloud Observability

Lightstep은 Google Dapper 원저자 중 한 명인 Ben Sigelman이 2014년에 창업한 회사다. "통계 기반 분석"·"메트릭과 트레이스 결합"을 일찍부터 강조했다.

2021년 ServiceNow가 인수. 현재는 ServiceNow Cloud Observability로 리브랜딩됐다. 단독 제품으로는 자취를 감추고 있지만, ServiceNow의 ITSM/AIOps와 묶여 엔터프라이즈 시장(특히 ITIL·CMDB와 묶인 곳)에서 살아남았다.

기술적 유산:

OTel 초기 표준화에 핵심 역할(Sigelman은 OTel 거버넌스 위원회 멤버였다).
트레이스에 통계적 노이즈 감소를 처음 강조.

2026년 평가: ServiceNow 생태계 안에 있는 회사면 검토. 그렇지 않으면 Honeycomb·Datadog·OSS 진영이 더 활발하다.

10장 · SigNoz — OSS 풀스택 옵저버빌리티

SigNoz는 2020년 인도에서 출발한 OSS APM이다. ClickHouse 위에 트레이스·메트릭·로그를 다 얹는다. "Datadog의 OSS 대안"을 표방한다.

특징:

100% OTel 네이티브 — OTel Collector를 SDK처럼 쓴다.
단일 UI에서 트레이스/메트릭/로그/예외 모두.
ClickHouse 기반 — 쿼리가 빠르고 저장이 압축된다.
2024년 Series B 펀딩 — LogStream·Anomaly Detection·메트릭 V2 출시.

docker-compose up 한 줄로 풀스택이 뜨고, OTel 호환이라 마이그레이션이 비교적 무탈하다.

2024~2025 업데이트:

LogStream: 로그도 같은 UI에서 검색/필터.
Anomaly Detection: ML 기반 이상치 탐지(베이스라인 자동).
Trace Funnels: 결제 같은 다단계 흐름의 단계별 성공률.

장점: OSS인데도 UI가 단정하고 풀스택이다. 클라우드 SaaS도 있어 셀프호스팅이 부담스러우면 그쪽으로.

한계: ClickHouse 의존이 강해 대규모 운영 노하우가 필요하다. 엔터프라이즈 기능(SSO·SOC2 보고 등)은 클라우드 플랜에 몰린다.

11장 · Apache SkyWalking — APM + 트레이스, 중국 주도

Apache SkyWalking은 2017년 Apache 인큐베이팅, 2019년 졸업한 OSS APM이다. 중국 화웨이/알리바바/텐센트 출신 컨트리뷰터가 많고, 동아시아에서 사용자가 두텁다.

특징:

자체 에이전트(자바·.NET·Node) + OTel 호환.
트레이스만이 아니라 서비스 토폴로지·메트릭·로그·이벤트 전부.
백엔드: 자체 OAP 서버 + Elasticsearch/BanyanDB(자체 시계열 DB).
UI: 토폴로지 시각화가 강하다.
서비스 메시(Istio) 가시화·이벤트 기반 자가복구(SkyWalking-Rover, eBPF) 등 확장.

2026년의 자리: 중국·인도·동남아 OSS 진영의 메인 선택지. 한국·일본에서는 상대적으로 적지만, 중국법인을 운영하는 회사면 자연스레 만난다.

12장 · Datadog APM · New Relic APM · Elastic APM · Sentry Performance

상업 APM 슈퍼리그의 트레이스 라인업.

Datadog APM

가장 큰 시장 점유. UI 완성도가 압도적.
OTel 네이티브 입출력 — dd-trace도 있지만 OTel SDK 직접도 지원.
트레이스 + APM 메트릭(throughput·error·latency) + 프로파일링 연결.
가격: 호스트당 + 인입 스팬당 분리 과금. 트래픽 큰 곳은 청구서가 무서워질 수 있다.
Watchdog(AIOps), Continuous Profiler, Database Monitoring으로 연결.

New Relic APM

1세대 APM(2008)의 원조. 2020년대 들어 "Telemetry Data Platform"으로 리포지셔닝.
2020년 가격 정책 대수술 — 사용자당 + 인입 GB 과금으로 단순화.
OTel 호환, OTel-only 운영도 가능.
AI 분석(New Relic AI), 로그-트레이스 자동 결합.

Elastic APM

Elasticsearch 위에 얹은 APM. 이미 ELK 스택을 쓰는 곳이면 자연스럽다.
셀프호스팅·Elastic Cloud 둘 다 가능.
가격이 OTel + OSS 백엔드보다 비싸지 않으면서, 검색·대시보드·머신러닝이 통합된다.

Sentry Performance

Sentry는 본래 에러 모니터링 회사. 2020년경 Performance(분산 추적)를 추가했다.
강점: 프론트엔드와의 결합. React/Vue 등 클라이언트 SDK 트레이스가 그대로 백엔드까지 이어진다.
백엔드 전용 APM으로는 약하지만, 풀스택(특히 SPA 프런트엔드)은 강하다.

13장 · Dynatrace · AppDynamics(Splunk) · Splunk Observability Cloud

엔터프라이즈 무거운 진영.

Dynatrace

1993년부터 시작한 오스트리아 회사. 엔터프라이즈 APM의 거인.
자체 에이전트 OneAgent가 깐 즉시 자동 토폴로지·메트릭·트레이스를 만든다 — 사람이 손댈 일이 거의 없다.
AI 엔진 Davis가 원인 후보를 자동 제시.
OTel 입력도 지원.
가격: 엔터프라이즈. ROI가 큰 환경(글로벌 대형 운영)에 적합.

AppDynamics (now Splunk-acquired)

시스코가 2017년 인수, 2024년 시스코가 Splunk를 인수하면서 Splunk 우산 아래로 다시 묶였다.
자바·.NET 강세. 비즈니스 트랜잭션 중심 뷰.
2025~2026년 로드맵상으로는 Splunk Observability Cloud로 점진 통합 방향.

Splunk Observability Cloud

2019년 SignalFx 인수로 만든 라인. 메트릭·트레이스·로그 + RUM(real-user monitoring).
시스코의 Splunk 인수(2024) 이후 SignalFx 유산 + AppDynamics 유산을 같은 SKU로 합치는 작업이 진행 중.
시스코+Splunk를 이미 쓰는 곳에는 강한 후보.

14장 · eBPF 트레이스 — Pixie와 Beyla, 코드 변경 없는 자동 계측

eBPF는 리눅스 커널 안에서 안전하게 코드를 실행하는 기술이다. 네트워크 패킷·시스템 콜·HTTP 요청을 커널 레벨에서 잡을 수 있다 — 앱 코드를 한 줄도 바꾸지 않고.

Pixie

2019년 시작, 2021년 New Relic이 인수. 그 후 OSS로 CNCF 샌드박스(2021), 2023년 인큐베이팅.
쿠버네티스에 데몬셋으로 깔면 HTTP/HTTPS/gRPC/DNS/MySQL/Postgres/Redis 등의 요청을 자동 캡처.
데이터는 노드 안의 인메모리에 머무르고(기본 24h), 필요할 때만 외부로 보낸다 — 프라이버시·비용에 유리.
데이터 쿼리는 PxL(Python-like).

Beyla — Grafana의 eBPF 자동 계측기

Grafana Labs가 2023년 발표. 2024년 GA.
단일 바이너리·사이드카로 깔리고, eBPF로 HTTP/gRPC 통신을 잡아 OTel 스팬으로 내보낸다.
셀프호스팅 OTel + Tempo 스택에 가장 매끄럽게 끼워진다.

eBPF 트레이스의 위치

코드 변경 없는 빠른 가시화가 필요한 곳 — 폴리글랏 환경, 레거시 코드, "지금 당장 어디가 느린지" 추정.
단점: 비즈니스 컨텍스트(user_id 등)는 못 잡는다. eBPF는 네트워크 페이로드를 본다 — 앱이 그 안에 ID를 안 넣으면 보이지 않는다.

결론: eBPF + OTel SDK 둘 다 쓰는 게 정석이다. eBPF로 인프라/네트워크 레벨 자동 가시화, OTel SDK로 비즈니스 스팬·고카디널리티 속성.

15장 · 샘플링 — head vs tail vs ratio

트레이스 비용 = 만든 스팬 수 × 단가. 비용 곡선의 80% 이상은 샘플링 전략에 달렸다.

세 가지 전략:

Head-based sampling (헤드 샘플링)

트레이스의 시작 지점에서 결정. 시작 시 결정한 결과를 traceparent의 trace-flags로 전파.
결정에 쓸 정보가 적다(아직 무슨 일이 일어날지 모름).
장점: 단순, 비용 예측 쉬움, SDK만으로 가능.
보통 1~10% 고정 비율로 흘려보낸다.

Ratio sampling (확률 샘플링)

Head 샘플링의 하위 분류. 예: sample_ratio=0.1 (10%).
OTel SDK 디폴트 (TraceIdRatioBased).
일관성 보장: trace_id 해시로 결정 → 같은 trace는 모든 서비스에서 같은 결정.

Tail-based sampling (테일 샘플링)

트레이스가 다 끝난 후(또는 일정 시간 대기 후) 결정.
모든 스팬을 일단 Collector로 모아서 본다 — 결정에 풍부한 정보(에러 여부, 총 지연, 특정 속성) 활용.
장점: 에러·느린 트레이스만 100% 보관, 정상은 1%만. 비용 대 가치가 최고.
단점: 결정까지 큐잉 필요(보통 30초~수 분), 메모리·CPU 소모, 같은 trace의 모든 스팬이 같은 Collector 인스턴스로 가야 함(load balancer exporter로 trace_id 해싱 라우팅).

OTel Collector tail_sampling processor 예:

processors:
  tail_sampling:
    decision_wait: 30s
    num_traces: 100000
    policies:
      - name: keep_errors
        type: status_code
        status_code: { status_codes: [ERROR] }
      - name: keep_slow
        type: latency
        latency: { threshold_ms: 1500 }
      - name: keep_pii_tenant
        type: string_attribute
        string_attribute: { key: tenant.tier, values: [enterprise] }
      - name: random_2pct
        type: probabilistic
        probabilistic: { sampling_percentage: 2 }

이 정책은: 에러 100% + 1.5초 초과 100% + enterprise 테넌트 100% + 나머지의 2%만 유지.

어떤 걸 골라야 하나

상황	추천
트래픽 작음(~수백 rps)	Head 100% 또는 ratio 50%
일반적 SaaS(~수천 rps)	Head 10% + 에러 100% (SDK에서 분기)
대규모(~수만~수십만 rps)	Tail-based + 에러/느림/특정 테넌트 100%
비용 폭주 중	Tail-based 즉시 도입 — 대개 5~10배 절감

16장 · 비용 — tail-based 샘플링 프록시와 청구서

분산 추적의 청구서가 무서워지는 두 패턴.

트래픽 증가에 비례한 청구서 — 100% 샘플 + 대형 트래픽.
고카디널리티 속성 폭발 — 모든 스팬에 user_id, request_id, k8s_pod, container_id를 다 박음.

해법:

테일 샘플링을 게이트웨이 Collector에 둔다. SaaS에 인입되기 전에 자른다. 같은 트레이스의 모든 스팬을 같은 Collector로 라우팅하기 위해 loadbalancing exporter를 앞단에 둔다.
저장은 OSS, "Hot" 트레이스만 SaaS. 모든 트레이스를 Tempo에 보내고, 에러·느림만 Honeycomb/Datadog에 추가 보냄.
속성 화이트리스트. attributes processor로 안 쓰는 속성을 제거한다.
로그 트레이스 연결로 트레이스 본문을 슬림화. 길고 큰 속성은 로그에 두고, 스팬에는 log_id 참조만.

실전 경험치(저자의 보수적 추정):

무리한 100% → 1% head 샘플 = 청구서 90% 감소, 디버깅 품질 30% 감소.
1% head → 테일 샘플(에러 100% + 정상 1%) = 청구서 같지만 디버깅 품질 200% 증가.
게이트웨이 Collector + 화이트리스트 추가 = 청구서 추가 30% 감소.

17장 · 한국 / 일본 — 실전 사례

한국

토스(Toss) — 자체 트레이스 인프라(KafkaConsumer + Spring Sleuth 기반)에서 2023~2024년 사이 OTel + Tempo + Grafana 스택으로 점진 마이그레이션. 결제·송금 트래픽의 테일 샘플링으로 비용을 잡았다. 토스 SLASH 컨퍼런스에서 관련 발표가 나온다.
카카오(Kakao) — 사내 APM에서 OTel 표준화로 이전. 카카오톡 백엔드는 자바 스택이라 OTel Java agent 자동 계측 + 일부 핵심 서비스만 수동 계측의 조합. if(kakao) 컨퍼런스에 트레이싱 사례가 종종 등장.
NAVER — 사내 모니터링 플랫폼 nLog, Pinpoint 같은 자체 도구에서 OTel 호환 인터페이스를 추가하는 방향. Pinpoint는 NAVER가 만든 OSS APM(자바 바이트코드 계측 강점)이라 그 자체로 OTel exporter를 추가하며 표준에 합류.

일본

メルカリ(Mercari) — Datadog에서 OTel + 자체 백엔드 조합으로 이행한 사례를 Mercari Engineering 블로그가 공개. 트래픽 비용이 핵심 동인이었고, OTel Collector + tail sampling으로 청구서를 잡았다.
NTT Communications — 사내 멀티 클라우드 모니터링 플랫폼에 OTel 채택. Datadog/New Relic/SkyWalking 혼재 환경을 OTel로 일원화. 한국으로 치면 SK텔레콤·KT 같은 통신사 모니터링 부서의 무거운 사례.
CyberAgent / DeNA / LINE — 게임·미디어·메신저 트래픽 특성상 테일 샘플링·고카디널리티 분석 요구가 높아, Honeycomb/Datadog + OSS 셀프호스팅(Tempo·Jaeger) 혼합.

공통 패턴: 벤더 락인을 피하려면 SDK는 OTel, 백엔드는 갈아끼울 수 있게. SaaS 단가 협상도 OTel 호환이 무기다.

18장 · 누가 무엇을 골라야 하나

작은 팀 / 사이드 프로젝트

OTel SDK + Jaeger(AllInOne) 또는 SigNoz (셀프호스팅) 또는 Honeycomb Free / Sentry Performance.
깔리는 데 30분, 비용 0~수만 원.

중간 규모 (수십 명, 수만~수십만 rps)

OTel SDK + Collector + Tempo + Grafana (OSS 풀스택). 비용은 인프라 비용만.
또는 Datadog/New Relic APM(SaaS, 빠른 적용·통합 알람).
둘을 OTel Collector로 병행 운영하다가 한쪽으로 정리하는 게 안전한 마이그레이션 패턴.

엔터프라이즈

Dynatrace / Splunk Observability Cloud / Datadog — 자동 토폴로지·AIOps·전사 알람·감사 로깅.
OTel 호환이 필수 조건. 벤더가 OTel만 입력 받아도 되도록 협상.

디버깅 우선 (고카디널리티·온디맨드 분석)

Honeycomb — observability 2.0 자세. 비용은 이벤트 수·보존.
SigNoz도 비슷한 방향을 OSS로 따라가는 중.

셀프호스팅 강제 (규제·보안)

OTel + Tempo/Jaeger/SigNoz/SkyWalking. SigNoz는 풀스택(트레이스+메트릭+로그+이벤트), Tempo+Loki+Mimir는 Grafana 진영의 분리형.

Kubernetes 폴리글랏 + 코드 변경 어려움

Pixie 또는 Beyla — eBPF로 자동 가시화. 비즈니스 스팬은 OTel SDK로 추가.

19장 · 안티패턴 10가지

OTel 안 쓰고 벤더 SDK 직결 — 벤더 바꿀 때 코드를 다 고친다.
계측은 했는데 샘플링은 100% 그대로 — 청구서가 폭발한다.
테일 샘플링 없이 "에러는 다 보고 싶다" — head 1% 샘플로는 에러 99%가 사라진다.
모든 스팬에 user_id·request_id 무차별 박기 — 고카디널리티 청구로 직결.
W3C와 B3 동시 운영을 안 챙김 — 레거시 서비스 경계에서 trace가 끊긴다.
Baggage에 PII 박기 — 다음 홉에서 헤더로 누출.
메트릭·로그·트레이스 백엔드가 따로 놀고 trace_id 연결 안 됨 — exemplar 워크플로 깨짐.
Collector를 안 두고 SDK에서 직접 SaaS로 — 백엔드 바꾸면 앱 전체 재배포.
Tail sampling의 trace_id 라우팅을 무시 — 같은 트레이스가 여러 Collector로 흩어져 결정이 잘못된다.
트레이스만 보고 메트릭/로그를 안 챙김 — 트레이스는 "특정 요청의 이야기", 메트릭은 "전체의 추세"다. 둘 다 필요.

에필로그 — OTel 위에 자유를 짓는다

2026년의 가르침은 한 문장이다.

계측은 OTel로 통일하고, 백엔드는 갈아끼울 수 있게 한다.

OTel은 단순한 트레이스 표준이 아니라, 벤더 락인을 끊는 인터페이스다. 그 위에 — Jaeger·Tempo의 OSS 자유든, Honeycomb의 디버깅 깊이든, Datadog의 통합 UX든, Dynatrace의 AIOps든 — 각자에게 맞는 백엔드를 얹는다. 갈아끼우는 비용이 코드 한 줄이 아니라 Collector 설정 한 줄이 되는 순간, 협상력도, 비용 관리도, 디버깅 품질도 다 손에 들어온다.

다음 글 후보: OpenTelemetry 메트릭 심층 — exemplar과 trace-metric 연결, 로그를 트레이스로 연결하기 — Loki·OpenSearch·OpenTelemetry Logs, 테일 샘플링 실전 — load-balancing exporter 토폴로지와 비용 곡선.

— 분산 추적 & OpenTelemetry 2026 심층 비교, 끝.