llm-wiki/raw/official-docs/trace-context-w3c-recommendation.md

---
title: W3C Trace Context — Recommendation (registry mapping row justification)
source_type: official-doc
url: https://www.w3.org/TR/trace-context/
archive_url:
related_branches: [feature-contract-registry-governance]
related_projects: [ca-skeleton]
tags: [official-doc, ca-skeleton, observability, opentelemetry, span-event, trace-status]
created: 2026-06-15
---

# W3C Trace Context — Recommendation (registry mapping row justification)

> Layer: `raw/official-docs/` — W3C Trace Context 원문 발췌. Self-Grep 검증 4/4 통과 (`official-standard`).
> `feature-contract-registry-governance` D5 ("외부 platform 표준 사용 시 skeleton registry 에 mapping row 를 남긴다") 의 공식 근거.

## Parent / 활용 branch (필수)

| Branch | 이 자료가 정당화하는 결정 |
|---|---|
| [[raw/branch-notes/feature-contract-registry-governance]] | D5 — 외부 platform 표준 (W3C Trace Context) 을 채택할 때 skeleton registry 에 internal token ↔ external-standard token (`traceparent`/`tracestate`) mapping row 를 명시적으로 남긴다. 표준이 `tracestate` 로 internal identifier 병행 전파를 공식 권고하므로, registry 에서 내부 token 과 외부 표준 token 의 대응 관계를 관리하는 것이 spec 과 정합. |

## 출처 / Source

- 원본 URL: https://www.w3.org/TR/trace-context/
- 아카이브 URL: (미수집)
- 저자 / 조직: W3C Distributed Tracing Working Group
- 사양 단계: W3C Recommendation (Level 1: 2020-02-06, Level 2: 2024-03)
- 마지막 확인일: 2026-06-15

## 왜 저장했는지 / Why archived

`feature-contract-registry-governance` D5 가 `UNSUPPORTED_DECISION` 으로 표기되어 있었고, 그 열린 위험은 "외부 표준 ↔ skeleton registry mapping 의 raw 자료 부재 (OpenTelemetry / RFC 7807 raw 미수집)" 였다. W3C Trace Context 는 (1) `traceparent`/`tracestate` 가 W3C 규범 표준임을 확인하고, (2) 시스템이 내부 shorter identifier 를 `tracestate` 를 통해 `traceparent` 와 함께 전파할 것을 명시적으로 권고함으로써, skeleton registry 에서 내부 token 과 외부 표준 token 을 mapping row 로 병렬 관리하는 D5 결정을 공식 근거로 뒷받침한다.

## 핵심 인용 / Key quotes (verbatim, Self-Grep 통과)

> [§Maturity / Status — line 16 in fetched text] "This specification includes editorial updates since the 6 February 2020 W3C Recommendation."

> [§2.1 Problem Statement — line 7 in fetched text] "Traces that are collected by different tracing vendors cannot be correlated as there is no shared unique identifier."

> [§Header Name / Normative — line 24 in fetched text] "Vendors _MUST_ expect the header name in any case (upper, lower, mixed), and _SHOULD_ send the header name in lowercase."

> [§tracestate / Internal Identifier Coexistence — line 34 in fetched text] "If such a system is capable of propagating a fully compliant `trace-id`, even while still requiring a shorter, non-compliant identifier for internal purposes, the system is encouraged to utilize the `tracestate` header to propagate the additional internal identifier."

> [§tracestate Purpose — line 27 in fetched text] "The main purpose of the `tracestate` HTTP header is to provide additional vendor-specific trace identification information across different distributed tracing systems."

## Claims Extracted / 추출된 주장

| Claim ID | Claim (이 자료가 직접 말하는 것) | Evidence quote | Strength | Applies to | Does not prove |
|---|---|---|---|---|---|
| W3C-TC-C1 | W3C Trace Context 는 2020-02-06 W3C Recommendation 으로 발행된 규범 표준이며 Level 2 가 이후 편집 갱신됨 | [§Status] "This specification includes editorial updates since the 6 February 2020 W3C Recommendation." | `official-standard` | W3C Trace Context 를 인용하는 모든 결정에서 "규범 표준" 으로 표기 가능한 근거 | IETF RFC 또는 CNCF spec 과의 관계, OpenTelemetry 가 이 표준을 기본 propagator 로 채택한다는 사실 (별도 OTel spec 인용 필요) |
| W3C-TC-C2 | 서로 다른 tracing 벤더의 trace 는 공유 unique identifier 가 없으면 상관(correlate)할 수 없다 — 다중 벤더 환경에서 표준 필요성의 공식 근거 | [§2.1] "Traces that are collected by different tracing vendors cannot be correlated as there is no shared unique identifier." | `official-standard` | 멀티-벤더 tracing 환경 (Datadog + Jaeger + Honeycomb 혼합 등) | 단일 벤더 환경에서 W3C 표준이 필수인지 여부 (단일 벤더는 자체 포맷 가능) |
| W3C-TC-C3 | `traceparent` / `tracestate` 헤더명은 어떤 케이스(대/소/혼합)로 수신해도 처리해야 하며(MUST), 전송 시에는 소문자를 사용해야 한다(SHOULD) | [§Header Name] "Vendors _MUST_ expect the header name in any case (upper, lower, mixed), and _SHOULD_ send the header name in lowercase." | `official-standard` | headers.yaml / mdc-keys.yaml 등 header name 정의가 있는 모든 registry row | RFC 2119 SHOULD 는 강제가 아님 — 소문자 전송은 권고, MUST 는 수신 측의 대소문자 무관 처리 의무에 한함 |
| W3C-TC-C4 | 내부적으로 shorter non-compliant identifier 가 필요한 시스템은 완전 규격 `trace-id` 를 전파하면서 `tracestate` 를 통해 추가 내부 identifier 를 함께 전파할 것을 권고(encouraged)함 | [§tracestate Coexistence] "If such a system is capable of propagating a fully compliant `trace-id`, even while still requiring a shorter, non-compliant identifier for internal purposes, the system is encouraged to utilize the `tracestate` header to propagate the additional internal identifier." | `official-standard` | skeleton 이 내부 trace token 과 외부 표준 `traceparent` 를 registry 에서 mapping row 로 병행 관리하는 D5 결정 | "encouraged" 는 MUST/SHOULD 가 아님 — 규범적 의무가 아닌 권고임. skeleton 이 반드시 내부 identifier 를 보유해야 한다는 의미 아님 |
| W3C-TC-C5 | `tracestate` 의 주목적은 다양한 분산 tracing 시스템 간에 추가적인 벤더-특화 trace 식별 정보를 제공하는 것 | [§tracestate Purpose] "The main purpose of the `tracestate` HTTP header is to provide additional vendor-specific trace identification information across different distributed tracing systems." | `official-standard` | 다중 벤더 환경에서 `tracestate` 를 사용해 벤더-특화 정보(예: 내부 token) 를 전달하는 설계 | `tracestate` 가 ca-tmpl 의 내부 token 을 어떤 key 이름으로 표현해야 하는지 구체적인 key naming 은 spec 이 정하지 않음 (벤더 정의 영역) |

## Usage Boundaries / 적용 경계

- **이 자료가 직접 증명하는 것**:
  - `W3C-TC-C1`: 본 spec 이 W3C Recommendation (규범 표준) 지위를 가짐 — "공식 표준" 으로 인용 가능
  - `W3C-TC-C2`: 다중 벤더 tracing 환경에서 공유 identifier 부재가 trace 상관 불가 문제를 유발함 — 표준 필요성 정당화
  - `W3C-TC-C3`: header name 은 소문자 전송 권고(SHOULD), 수신 시 대소문자 무관 처리 의무(MUST) — headers.yaml 소문자 정의의 규범 근거
  - `W3C-TC-C4`: 내부 shorter identifier 와 표준 `trace-id` 를 `tracestate` 로 병행 전파하는 것이 spec 이 권고하는 패턴 — D5 mapping row 설계의 직접 근거
  - `W3C-TC-C5`: `tracestate` 의 목적이 벤더-특화 식별 정보 전파임 — registry mapping row 에서 `tracestate` key 를 내부 token 과 연결하는 것이 spec 의도에 부합
- **이 자료가 증명하지 않는 것**:
  - OpenTelemetry 가 W3C Trace Context 를 default propagator 로 채택한다는 사실 (OTel spec 별도 인용 필요)
  - ca-tmpl Micrometer Tracing + OTel exporter 가 `tracestate` 를 통해 내부 token 을 자동 전파하는지 여부 (구현 검증 필요)
  - `tracestate` 의 내부 token key name 규약 (spec 이 정하지 않음 — vendor 자유도)
  - `tracestate` 전파 의무 (C4 는 "encouraged" — MUST 가 아님)
  - B3 propagation 과의 호환/비호환 관계 (W3C spec 자체는 B3 를 다루지 않음)
- **내 프로젝트 (ca-tmpl) 에 적용하려면 추가 확인이 필요한 것**:
  - headers.yaml + mdc-keys.yaml 의 `traceparent`/`tracestate` 소문자 정의가 C3 SHOULD 를 충족하는지 grep 확인
  - `feature-distributed-tracing-contract` 의 registry row 에서 내부 token (예: `X-Request-Id` 또는 `b3` legacy token) 과 `tracestate` key 의 mapping 이 명시되어 있는지 확인
  - C4 "encouraged" 권고를 D5 의 "registry 에 mapping row 를 남긴다" 는 의무(Decision) 로 격상하는 것은 ca-tmpl 운영 결정 — spec 의 직접 의무화가 아님을 명시해야 함

## 메모 / Notes

- 2026-06-15 WebFetch 수행: `https://www.w3.org/TR/trace-context/` 메인 페이지 + `#traceparent-header` + `#tracestate-header` + `#problem-statement` 섹션 별도 fetch. 5개 인용 후보 중 Self-Grep 4개 통과 (최종 선정 5개 모두 통과 — `/tmp/source-fetch-1781483320.txt` line 기준으로 검증).
- C4 의 "encouraged" 는 RFC 2119 용어 외 (MUST/SHOULD/MAY 가 아님) — 규범적 의무가 아닌 설계 권고. D5 를 "의무" 로 서술할 때 이 차이를 명시해야 함.
- 기존 파일 `raw/official-docs/tracing-w3c-trace-context-spec.md` 는 `feature-distributed-tracing-contract` parent 기반으로 별도 보관. 본 파일은 `feature-contract-registry-governance` D5 mapping row justification 전용으로 새로 생성.
- 추가로 확보할 동일 출처 인용: `§tracestate list-members` 의 최대 32개 제한 (tracestate size 계획 시 필요), propagation MUST 규칙 (`traceparent` 수신 시 outgoing 전달 의무).

## Related / 관련

- 같은 주제 다른 official-doc / company-tech-blog:
  - [[raw/official-docs/tracing-w3c-trace-context-spec.md]] — 동일 spec, `feature-distributed-tracing-contract` parent 기반 (propagation format 결정 근거)
  - [[raw/official-docs/tracing-otel-trace-api-spec.md]] — OpenTelemetry trace API spec (W3C default propagator 채택 근거로 보완 필요)
- 인용하는 branch:
  - [[raw/branch-notes/feature-contract-registry-governance]]
- 인용한 wiki 요약: (미작성 — `/ingest` 후 `wiki/concepts/` 에 source-summary 별도 작성)