---
title: Datadog APM vs OpenTelemetry — Vendor APM 비교
source_type: company-tech-blog
url: https://www.datadoghq.com/blog/opentelemetry-instrumentation/
archive_url:
related_branches: [feature-distributed-tracing-contract]
related_projects: [ca-skeleton-operational-contract]
tags: [ca-distributed-tracing, datadog, opentelemetry, apm, vendor-comparison]
status: raw
confidence: low
created: 2026-05-22
last_reviewed: 2026-05-27
---

# Datadog APM vs OpenTelemetry — Vendor APM 비교

> Layer: `raw/company-tech-blogs/` — Datadog 공식 블로그 "Send OpenTelemetry data to Datadog" (2019) + Datadog Java tracer docs verbatim.
> 주의: 본 파일의 이전 버전에는 verbatim 으로 확인되지 않는 marketing 문구 4개가 포함되어 있었음 (예: "Datadog supports OpenTelemetry instrumentation in two ways: OTLP ingest via the Datadog Agent...", "auto-instruments 100+ frameworks out of the box", "AWS X-Ray uses its own propagation header (`X-Amzn-Trace-Id`)..."). 2026-05-27 재검증 결과 본문에서 verbatim 확인 안 됨 — 모두 `needs-confirmation` 으로 격하.

## Parent / 활용 branch (필수)

| Branch | 이 자료가 정당화하는 결정 |
|---|---|
| [[raw/branch-notes/feature-distributed-tracing-contract]] | Micrometer Tracing + OpenTelemetry exporter 채택 결정의 vendor-neutrality 근거 (대안: Datadog dd-trace-java / AWS X-Ray) |
| [[raw/project-notes/ca-skeleton-operational-contract]] | Distributed Tracing Contract — OTel vs vendor-native APM 비교의 입력 자료 |

## 컨텍스트 / 왜 저장했는지

ca-tmpl이 채택한 "**Micrometer Tracing + OpenTelemetry exporter**"를 vendor APM (Datadog native tracer / AWS X-Ray)과 비교. vendor lock-in trade-off 명시.

## 출처 / Source

- 원본 URL: https://www.datadoghq.com/blog/opentelemetry-instrumentation/
- 보조 1: Datadog APM Java tracer docs — https://docs.datadoghq.com/tracing/trace_collection/dd_libraries/java/
- 보조 2: AWS X-Ray Java SDK docs (별도 확인 필요)
- 아카이브 URL: (미수집)
- 저자 / 조직: Datadog (2019-09 블로그)
- 발행일: 2019-09 (Datadog/OpenTelemetry 파트너십 발표 시점)
- 마지막 확인일: 2026-05-27

## 핵심 인용 / Key quotes (verbatim)

(Datadog 블로그 — `datadoghq.com/blog/opentelemetry-instrumentation/`, 2026-05-27 재검증 결과)

> [§OpenTelemetry vendor-neutrality] "Because OpenTelemetry is vendor-neutral, companies will be able to migrate their observability data between monitoring backends more easily, without vendor lock-in."

> [§Datadog 기여] "contributing our tracing libraries to the OpenTelemetry project"

(Datadog Java tracer docs — `docs.datadoghq.com/tracing/trace_collection/dd_libraries/java/`)

> [§dd-trace-java 자동 계측] "Automatic instrumentation for Java uses the `java-agent` instrumentation capabilities provided by the JVM."

## Claims Extracted / 추출된 주장

| Claim ID | Claim (이 자료가 직접 말하는 것) | Evidence quote | Strength | Applies to | Does not prove |
|---|---|---|---|---|---|
| DD-OTEL-C1 | OpenTelemetry 는 vendor-neutral 이며 이를 통해 모니터링 backend 간 observability 데이터 마이그레이션이 vendor lock-in 없이 더 쉬워짐 | [§OpenTelemetry vendor-neutrality] "Because OpenTelemetry is vendor-neutral, companies will be able to migrate their observability data between monitoring backends more easily, without vendor lock-in." | `company-case-study` | Datadog 외 backend 로의 portability 가 결정 요인일 때 | OTel 가 vendor-native 기능 (Datadog Watchdog, Continuous Profiler) 를 모두 대체한다는 뜻은 아님 |
| DD-OTEL-C2 | Datadog 은 자사 tracing 라이브러리를 OpenTelemetry 프로젝트에 기여 (2019 시점) | [§Datadog 기여] "contributing our tracing libraries to the OpenTelemetry project" | `company-case-study` | Datadog/OTel 호환성 history | 현재 2026 시점에서의 정확한 통합 상태 (OTLP ingest 경로 등) 는 본 인용으로 보장 안 됨 — 별도 docs 필요 |
| DD-OTEL-C3 | dd-trace-java 의 자동 계측은 JVM 의 `java-agent` 계측 기능을 사용 | [§dd-trace-java 자동 계측] "Automatic instrumentation for Java uses the `java-agent` instrumentation capabilities provided by the JVM." | `official-vendor-doc` | Java 애플리케이션에 dd-trace-java 통합 시 | dd-trace-java 가 자동 계측하는 framework 의 개수 / 목록은 본 인용 범위 밖 (예: "100+ frameworks") |
| DD-OTEL-C4 | (부재) "Datadog supports OpenTelemetry instrumentation in two ways: OTLP ingest via the Datadog Agent, and direct OTLP HTTP/gRPC ingestion." — 본 자료의 2026-05-27 재검증에서 verbatim 미확인 | (부재 자체가 claim) | `needs-confirmation` | Datadog 의 OTLP 수집 경로 (Agent vs direct) | 해당 사실이 거짓이라는 뜻은 아님. Datadog OTLP docs (별도) 에서 verbatim 재수집 필요 |
| DD-OTEL-C5 | (부재) "dd-trace-java auto-instruments 100+ frameworks out of the box" — verbatim 미확인 | (부재 자체가 claim) | `needs-confirmation` | dd-trace-java 의 자동 계측 framework 개수 비교 | Datadog Compatibility Requirements 페이지 (별도) 의 확인 필요 |
| DD-OTEL-C6 | (부재) "AWS X-Ray uses its own propagation header (`X-Amzn-Trace-Id`) by default; W3C trace context support added in 2021" — verbatim 미확인 (Datadog 블로그가 아닌 AWS X-Ray docs 가 출처여야 함) | (부재 자체가 claim) | `needs-confirmation` | AWS X-Ray propagation 헤더 / W3C 호환 | AWS X-Ray Developer Guide 의 verbatim 확인 필요. 본 raw 파일로는 미보장 |

## Usage Boundaries / 적용 경계

- **이 자료가 직접 증명하는 것**:
  - `DD-OTEL-C1`: OpenTelemetry 의 vendor-neutrality 주장 (Datadog 블로그의 marketing 문구)
  - `DD-OTEL-C2`: Datadog 의 OTel 프로젝트 기여 (2019 시점)
  - `DD-OTEL-C3`: dd-trace-java 가 java-agent 기반이라는 vendor docs 사실
- **이 자료가 증명하지 않는 것**:
  - `DD-OTEL-C4`, `C5`, `C6`: 이전 raw 파일에 기록된 marketing/spec 문구의 정확한 verbatim
  - Datadog APM 의 모든 기능 (Watchdog, Continuous Profiler, Live Search) 의 정확한 동작
  - AWS X-Ray 의 정확한 propagation 헤더 / W3C 호환 시점
  - OTel SDK + Datadog 조합의 실제 production 운영 사례
- **내 프로젝트에 적용하려면 추가 확인이 필요한 것**:
  - Datadog OTLP ingest 경로 (Agent vs direct) 의 최신 docs 확인 → 별도 raw 파일 생성 권고
  - AWS X-Ray Developer Guide 에서 propagation 헤더 verbatim 수집 → 별도 raw 파일 생성 권고
  - Micrometer Tracing 1.x + OTel exporter + Datadog Agent 의 실측 latency / 호환성 검증

## 메모 / Notes (내 프로젝트 해석)

> 본 섹션은 자료 직접 인용 아님. ca-tmpl 결정 컨텍스트 해석.
> 주의: 아래 메모는 verbatim 출처가 없는 사실을 포함할 수 있음 → wiki 로 옮길 때 verbatim 재수집 필요.

- **3가지 선택지 비교 (사실 자체는 별도 출처 확인 필요)**:

  | 옵션 | propagation | exporter | vendor lock-in |
  |---|---|---|---|
  | OTel SDK (ca-tmpl 채택) | W3C traceparent | OTLP → any backend | 없음 |
  | Datadog dd-trace-java | W3C 또는 Datadog header | dd agent → Datadog only | 있음 |
  | AWS X-Ray | `X-Amzn-Trace-Id` (W3C 옵션) | X-Ray daemon → AWS only | 있음 |

- **장점 (ca-tmpl OTel SDK 채택)**:
  - vendor-neutral → backend swap 가능 (`DD-OTEL-C1` 으로 지지됨).
  - Spring Boot 3 + Micrometer Tracing 통합 자연스러움.
  - W3C trace context default 와 정합.
- **단점 (vendor-native 대비)**:
  - vendor-specific feature (Datadog Watchdog, X-Ray service map auto-discovery) 사용 어려움.
  - vendor auto-instrumentation 이 더 광범위한 경우 있음.
- **ca-tmpl 과의 차이**: 명시적으로 "특정 APM vendor 종속 설정" 을 out-of-scope 로 둠 → OTel 선택은 결정과 정합.
- **운영 복잡도**: OTel + collector 추가 deploy 필요. vendor native 는 agent 설치만으로 시작 가능 → 초기 적용 비용은 vendor native 가 낮으나 장기 portability 는 OTel 우위.

## Related / 관련

- 같은 주제 다른 raw:
  - (예정) `raw/official-docs/aws-x-ray-propagation` — X-Ray 헤더 verbatim 확인
  - (예정) `raw/company-tech-blogs/datadog-otlp-ingest-options` — Datadog OTLP 경로 verbatim 확인
- 인용하는 branch:
  - [[raw/branch-notes/feature-distributed-tracing-contract]]
- 인용하는 project:
  - [[raw/project-notes/ca-skeleton-operational-contract]] (Distributed Tracing Contract)
- 인용한 wiki 요약: (미작성)