지금

참고로, 메인 저장소(main repo)는 올해 평소와 같은 주기로 배포되었습니다 — v1.39.0 (1월 12일), v1.40.0 (2월 19일), v1.41.0 (4월 28일), v1.41.1 (5월 11일), v1.42.0 (6월 12일, GenAI 추출 기능 포함), v1.43.0 (7월 3일). 메인 저장소 내의 마지막 주요 GenAI 추가 사항은 v1.41.0에 반영되었습니다: 스트리밍 메트릭 (streaming metrics) (gen_ai.client.operation.time_to_first_chunk 및 .time_per_output_chunk), 연산(operation)으로서의 invoke_workflow, 그리고 invoke_agent를 클라이언트(client) 대 내부 스팬(internal spans)으로 분리한 것입니다.

따라서 솔직한 현재 상태는 다음과 같습니다: 자체 저장소와 자체 SIG(Special Interest Group) 모멘텀, 실제 벤더(vendor) 채택을 동반하며 빠르게 통합되고 있는 표준이지만, 속성 이름(attribute names)에 대한 안정성은 보장되지 않음.

오늘 당장 내보내야(emit) 하는 것

개발(Development) 상태임에도 불구하고, 핵심 시그널 세트(signal set)는 구축이 가능할 정도로 충분히 안정되었습니다. 중요한 짧은 목록은 다음과 같습니다:

이를 내보내기 위해 별도의 인스트루멘테이션 라이브러리(instrumentation library)가 필요하지는 않습니다. 표준 Python SDK를 사용한 일반적인 수동 스팬(manual span)만으로도 완전히 규격에 부합합니다:

from opentelemetry import trace

tracer = trace.get_tracer("my-agent")
...

누락된 것에 주목하십시오: 프롬프트 텍스트(prompt text)도, 완성 텍스트(completion text)도 없습니다. 현재의 컨벤션(conventions) 하에서 콘텐츠는 메타데이터 선택 사항(metadata-opt-in)입니다. 이는 GDPR을 준수하거나 고객 데이터를 다루는 경우 합리적인 기본 설정입니다.

이름 변경의 함정 (The rename traps)

이 지점이 오래된 블로그 포스트들이 실제로 여러분에게 해를 끼치는 부분입니다. 만약 여러분의 인스트루멘테이션(또는 벤더의 인스트루멘테이션)이 2024/2025년 상태의 컨벤션을 기준으로 작성되었다면, 다음 마이그레이션 체크리스트를 실행하십시오:

• gen_ai.system → gen_ai.provider.name. 기존 속성은 레지스트리에서 사용 중단(deprecated)되었습니다. 만약 대시보드가 gen_ai.system을 기준으로 그룹화되어 있다면, 라이브러리가 업데이트됨에 따라 데이터가 표시되지 않을 것입니다.
• gen_ai.usage.prompt_tokens → gen_ai.usage.input_tokens 및 gen_ai.usage.completion_tokens → gen_ai.usage.output_tokens. 기존 이름으로 구축된 비용 대시보드는 데이터 생성기(emitter)가 전환되면 조용히 수치를 과소 집계하게 됩니다.
• gen_ai.prompt 및 gen_ai.completion은 완전히 제거되었습니다 — 이름이 변경된 것이 아닙니다. 이제 콘텐츠 캡처는 선택 사항(opt-in)인 gen_ai.input.messages / gen_ai.output.messages (및 gen_ai.system_instructions)를 통해 이루어집니다.
• 코드뿐만 아니라 알람 규칙(alert rules)과 저장된 쿼리(saved queries)도 검색(grep)하십시오. 데이터를 생성하는 측과 쿼리하는 측은 독립적으로 변동될 수 있습니다.
• 이런 일이 더 자주 발생할 것을 예상하십시오. 개발 상태(Development status)라는 표현은 이름이 여전히 변경될 수 있음을 명시적으로 의미합니다. OTel의 일반적인 전환 메커니즘은 OTEL_SEMCONV_STABILITY_OPT_IN을 통한 이중 생성(dual-emission)입니다. 따라서 이전 이름과 새 이름을 모두 처리해야 하는 기간을 계획하십시오.

에이전트(Agents)와 MCP가 퍼스트 클래스 스팬(first-class spans)을 얻다

프로덕션 환경에서 에이전트를 실행하는 모든 이들에게 가장 관련성이 높은 부분은 다음과 같습니다: 이제 컨벤션은 단순한 단일 LLM 호출이 아니라, 에이전트 실행 전체를 스팬 트리(span tree)로 모델링합니다.

invoke_agent  (에이전트 실행)
├── chat      (각 모델 호출)
│   └── execute_tool   (각 도구 호출)
...

gen_ai.operation.name은 create_agent, invoke_agent, invoke_workflow, execute_tool, retrieval, plan 및 메모리 작업을 포함하여 전체 에이전트 라이프사이클을 다룹니다. 특히 주목할 점은, MCP 컨벤션이 v1.42.0 추출과 함께 동일한 GenAI 리포지토리로 이동했다는 것입니다. 따라서 MCP 도구 호출은 이를 명령하는 에이전트와 동일한 트레이스 어휘(trace vocabulary)의 일부가 됩니다.

이는 더 이상 이론적인 이야기가 아닙니다: 공식 OTel 블로그의 2026년 GenAI 관측성(observability) 포스트에 따르면, VS Code Copilot, OpenAI Codex, Claude Code(후자는 베타 버전)와 같은 코딩 에이전트들은 이미 OTel GenAI 트레이스를 생성하고 있습니다. 동시에 해당 포스트는 컨벤션이 여전히 활발한 개발 단계에 있음을 강조하고 있습니다.

하지만 트레이스(traces)가 제공하지 못하는 한 가지는 에이전트의 출력(output)이 얼마나 좋았는가 하는 점입니다. 지연 시간(Latency)과 토큰 수(token counts)는 필수적이지만 충분하지는 않습니다. 품질 측면을 위해서는 동일한 파이프라인에 평가(evals)가 연결되어 있어야 합니다. 우리는 프로덕션 에이전트를 위해 이 문제에 어떻게 접근하는지 여기(독어)에 정리해 두었습니다.

오늘날 실제로 gen_ai.*를 사용하는 곳

도입은 실질적으로 이루어지고 있으나 불균형하며, 스키마 파편화(schema fragmentation) 문제는 여전히 해결되지 않았습니다:

• Datadog은 자사의 LLM/에이전트 관측성(Observability) 제품에서 OTel GenAI 시맨틱 컨벤션(semantic conventions)을 **네이티브(natively)**로 지원합니다 (관련 전용 포스트를 게시했습니다).
• Langfuse는 전체 **OTLP 엔드포인트(endpoint)**를 통해 트레이스를 수락하며, gen_ai.*를 자체 데이터 모델로 매핑합니다.
• Arize Phoenix의 네이티브 스키마는 OpenInference(llm.*라는 자체 네임스페이스)입니다. 이는 변환 레이어(예: OpenLLMetry 트레이스를 변환하기 위한 OpenInferenceSpanProcessor)를 통해 상호 운용하며, gen_ai.*와의 더 긴밀한 정렬을 위한 공개 RFC 논의가 진행 중입니다.
• OpenLLMetry/Traceloop는 OTel 기반입니다. 원래의 GenAI 컨벤션 일부는 실제로 OpenLLMetry의 기여(donation)로부터 왔지만, 여전히 일부 사용 중단된 속성(deprecated attributes)(gen_ai.prompt/gen_ai.completion)을 방출합니다. 현재 마이그레이션을 추적하는 오픈 이슈(open issue)가 있습니다.

이 세계들 사이에는 컨버터(Converters)가 존재하지만, 충실도(fidelity)는 제각각입니다. 이는 다음과 같은 실질적인 결론으로 이어집니다.

플레이북 (The playbook)

1. gen_ai.*를 대상으로 한 번의 계측 (Instrument once). 직접 작성한 스팬(span)이든 OTel 기반 라이브러리이든 관계없이, 컨벤션(convention)이 계약의 기준이지 벤더(vendor)가 기준이 아닙니다.
2. OTLP를 소켓(socket)으로 취급하세요. OTLP를 통해 데이터를 내보내면 Langfuse, Datadog 또는 Grafana 스택이 종속(lock-in) 결정이 아닌 교체 가능한 백엔드(backend)가 됩니다.
3. 비용 대시보드는 덤으로 따라옵니다. gen_ai.client.token.usage + gen_ai.request.model + gen_ai.provider.name 조합은 당신이 사용하는 모든 제공업체에 대해 표준화된 비용 스키마(schema)를 제공합니다.
4. 프롬프트 캡처(prompt capture)는 선택 사항(opt-in)으로 유지하세요. 기본값은 메타데이터(metadata) 전용입니다. 개인정보 보호 문제가 해결된 경우에만 gen_ai.input.messages/gen_ai.output.messages를 활성화하세요.
5. 이름 변경(rename)을 위한 예산을 확보하세요. 개발 단계(development status)는 작은 글씨의 주의 사항이 아니라 하나의 기능적 경고입니다. gen_ai.system의 이름 변경이 마지막이 아닐 것입니다.

저희는 azena.ai에서 독일 미텔슈탄트(Mittelstand) 고객들을 위한 에이전트 관측성(agent observability)을 운영하고 있습니다. 독일어를 읽으실 수 있다면, 정확히 이 스택을 위한 5가지 관측성 도구에 대한 저희의 더 심도 있는 비교 분석을 여기에서 확인하실 수 있습니다.