LabHub

블로그

분산 추적 & OpenTelemetry 2026 — OTel / Jaeger / Tempo / Zipkin / Honeycomb / Lightstep / SigNoz / SkyWalking / Datadog APM 심층 비교

2026-05-16 · 36 분 읽기 · #observability#distributed-tracing#opentelemetry#otelcol#jaeger#tempo#zipkin#honeycomb#charity-majors#lightstep#servicenow#signoz#apache-skywalking#datadog-apm#new-relic-apm#elastic-apm#sentry-performance#dynatrace#appdynamics#splunk#pixie#beyla#w3c-trace-context#b3-propagation#baggage#head-based-sampling#tail-based-sampling#deep-dive

한국어English日本語

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

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 SaaSDatadog, New Relic, Dynatrace, Splunk, AppDynamics, Sentry, Elastic매니지드. 통합 UI + 알람 + AIOps
observability 2.0Honeycomb, 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이 제공하는 것:

핵심 데이터 모델: 트레이스 = 스팬의 트리. 각 스팬은 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는 앱 밖에 도는 별도 프로세스다. 별도로 떼낸 이유:

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

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 → 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

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는 비밀이 아니다. 다음 홉이 외부 시스템이면 누구나 헤더를 본다. PII는 절대 baggage에 넣지 않는다.

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

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

특징:

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

배포 모양:

장점: 가볍고, 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
}

장점:

한계:

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

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

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

특징:

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

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 이다.
  ← 이런 결합을 사람이 미리 정하지 않아도 자동으로 찾는다.

차별점:

장점: 디버깅 속도가 다르다. "왜 느린가"를 인덱스 없이 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와 묶인 곳)에서 살아남았다.

기술적 유산:

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

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

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

특징:

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

2024~2025 업데이트:

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

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

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

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

특징:

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

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

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

Datadog APM

New Relic APM

Elastic APM

Sentry Performance

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

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

Dynatrace

AppDynamics (now Splunk-acquired)

Splunk Observability Cloud

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

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

Pixie

Beyla — Grafana의 eBPF 자동 계측기

eBPF 트레이스의 위치

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

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

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

세 가지 전략:

Head-based sampling (헤드 샘플링)

Ratio sampling (확률 샘플링)

Tail-based sampling (테일 샘플링)

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 샘플링 프록시와 청구서

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

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

해법:

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

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

한국

일본

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

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

작은 팀 / 사이드 프로젝트

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

엔터프라이즈

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

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

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

19장 · 안티패턴 10가지

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

에필로그 — 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 심층 비교, 끝.

참고 / References

원문 보기: https://www.youngju.dev/blog/culture/2026-05-16-distributed-tracing-opentelemetry-2026-otel-jaeger-tempo-zipkin-honeycomb-lightstep-signoz-skywalking-datadog-apm-deep-dive

댓글

아직 댓글이 없습니다.

로그인하면 댓글을 쓸 수 있습니다