OpenTelemetry 개요와 아키텍처

관측성 문제는 왜 생겼나

분산 시스템이 흔해지면서 "API 응답이 왜 느린가"라는 질문이 갑자기 어려워졌다. 하나의 요청이 프론트엔드 → API 게이트웨이 → 사용자 서비스 → DB → 캐시를 거친다면, 각 구간의 로그, 메트릭, 지연을 따로 수집해도 원인을 찾기 어렵다. 이 문제를 관측성(Observability)이라는 단어로 정리하면서 세 가지 신호(signal)가 산업 표준으로 자리 잡았다.

• 트레이스(Traces): 단일 요청이 여러 서비스를 거쳐 가는 경로와 각 구간의 지연을 기록한다.
• 메트릭(Metrics): 시스템의 상태를 숫자로 지속 측정한다. CPU, 요청 수, 에러율 같은 값이다.
• 로그(Logs): 시점 기반의 이벤트 텍스트 기록이다.

문제는 각 신호를 수집하는 도구가 제각각이었다는 점이다. 트레이스는 Jaeger, Zipkin, 메트릭은 Prometheus, 로그는 ELK. 각자의 SDK를 코드에 삽입해야 했고, 백엔드를 바꾸려면 코드도 다시 써야 했다.

OpenTracing과 OpenCensus의 분열, 그리고 통합

2010년대 중반, 이 파편화를 해결하려는 시도가 두 갈래로 나뉘었다.

• OpenTracing: 분산 트레이싱 표준을 만들기 위한 CNCF 프로젝트. API 명세에 집중했고 계측 라이브러리 중립성을 목표로 했다.
• OpenCensus: Google이 내부에서 쓰던 라이브러리를 오픈소스로 공개한 것. 트레이싱과 메트릭을 동시에 지원했고, 구현체까지 포함했다.

두 프로젝트는 같은 문제를 푸는 경쟁 표준이 됐다. 생태계가 분열되자 2019년 5월, 두 프로젝트는 합병을 선언하고 OpenTelemetry를 출범시켰다. 이후 CNCF 인큐베이팅 프로젝트를 거쳐, 2026년 5월 CNCF 졸업(Graduated) 상태를 획득하며 사실상의 업계 표준으로 자리 잡았다.

OpenTelemetry가 제공하는 것

OpenTelemetry(OTel)는 벤더 중립적인 관측성 프레임워크다. 코드를 한 번 계측하면 Jaeger, Prometheus, Datadog, Honeycomb 등 어느 백엔드로든 데이터를 보낼 수 있다. OTel이 제공하는 것은 세 계층으로 나뉜다.

1. 사양(Specification): 신호별 데이터 모델, API 계약, 시맨틱 컨벤션(속성 이름 규칙)을 정의한다.
2. SDK와 계측 라이브러리: Python, Java, Go, Node.js 등 20개 이상의 언어로 구현된 SDK와, Spring, Django, Express 같은 인기 프레임워크를 자동으로 계측하는 플러그인.
3. Collector: 데이터를 수집·처리·내보내는 독립 프로세스.

OTel 자체는 백엔드가 아니다. 데이터를 저장하거나 시각화하지 않는다. 그 역할은 Jaeger(트레이스), Prometheus(메트릭), Grafana Loki(로그) 같은 기존 도구에 맡긴다.

핵심 컴포넌트

API

OTel API는 계측 코드가 호출하는 인터페이스다. Tracer, Meter, Logger를 얻어 스팬을 시작하거나 메트릭 값을 기록하는 메서드를 정의한다. API는 구현을 포함하지 않는다. 라이브러리 작성자는 API에만 의존해서 계측 코드를 작성하고, 런타임에 SDK가 연결된다. SDK가 없으면 no-op(아무 동작 없음)으로 처리된다.

SDK

SDK는 API의 실제 구현이다. 애플리케이션 개발자가 직접 의존하는 부분이다. 스팬 데이터를 실제로 생성하고, 샘플링 규칙을 적용하고, 배치로 묶어서 Collector나 백엔드로 내보내는 책임을 진다.

Collector

Collector는 SDK로부터 텔레메트리를 받아 처리한 뒤 백엔드로 내보내는 독립 프록시 프로세스다. 크게 두 가지 배포 패턴이 있다.

Receiver → Processor → Exporter 파이프라인으로 구성된다. Processor에서 필요 없는 속성 제거, 민감 데이터 마스킹, 샘플링 비율 조정을 할 수 있다.

OTLP

OTLP(OpenTelemetry Protocol)는 OTel의 네이티브 와이어 프로토콜이다. gRPC와 HTTP(protobuf 또는 JSON) 위에서 동작한다. SDK → Collector, Collector → 백엔드 구간 모두에서 쓰인다. 기본 포트는 gRPC가 4317, HTTP가 4318이다.

자동 계측과 수동 계측

OTel의 가장 큰 실용적 장점 중 하나는 자동 계측(Auto-instrumentation)이다. Java Agent나 Python의 opentelemetry-instrument 래퍼를 붙이면 HTTP 클라이언트, DB 드라이버, 메시지큐 라이브러리에 대한 스팬이 코드 수정 없이 생성된다.

자동 계측이 커버하지 못하는 비즈니스 로직은 수동 계측(Manual instrumentation)으로 보완한다. tracer.start_span("order.process")처럼 원하는 구간을 직접 측정한다.

from opentelemetry import trace

tracer = trace.get_tracer("order-service")

def process_order(order_id: str):
    with tracer.start_as_current_span("order.process") as span:
        span.set_attribute("order.id", order_id)
        result = db.fetch_order(order_id)
        span.set_attribute("order.status", result.status)
        return result

시맨틱 컨벤션

OTel은 속성 이름까지 표준화한다. HTTP 요청의 메서드는 http.request.method, DB 시스템은 db.system, 오류 타입은 error.type처럼 정해진 이름을 쓴다. 이 덕분에 서로 다른 언어로 작성된 서비스의 데이터를 동일한 방식으로 쿼리하고 대시보드에 표시할 수 있다.

한 줄 정리

OpenTelemetry는 코드 계측(API/SDK)과 데이터 수집(Collector)을 표준화해서 어느 백엔드든 교체 가능하게 만든다. 트레이스·메트릭·로그 세 신호를 하나의 프레임워크로 통합한다는 점이 이전 OpenTracing/OpenCensus 시대와의 결정적인 차이다.

References

• https://opentelemetry.io/docs/what-is-opentelemetry/
• https://opentelemetry.io/docs/concepts/components/
• https://opentelemetry.io/docs/collector/architecture/
• https://opensource.microsoft.com/blog/2019/05/23/announcing-opentelemetry-cncf-merged-opencensus-opentracing/
• https://www.cncf.io/announcements/2026/05/21/cloud-native-computing-foundation-announces-opentelemetrys-graduation-solidifying-status-as-the-de-facto-observability-standard/
• https://opentelemetry.io/docs/concepts/signals/
• https://opentelemetry.io/docs/specs/otel/overview/