OpenTelemetry란? [알아야 할 모든 것]

발행: 3일 전 (2026년 2월 23일 오후 08:15 GMT+9)

17 분 소요

Source: Dev.to

번역하려는 전체 텍스트를 제공해 주시면, 원본 형식과 마크다운 구문을 유지하면서 한국어로 번역해 드리겠습니다.

관측성은 조각난 혼란이었습니다

로그용 에이전트 하나, 메트릭용 다른 라이브러리, 그리고 분산 추적용 독점 SDK가 있었습니다.
벤더를 교체하고 싶다면, 계측 코드를 처음부터 다시 작성해야 했습니다.

OpenTelemetry (OTel)가 이를 해결했습니다.

OpenTelemetry는 CNCF(클라우드 네이티브 컴퓨팅 재단)에서 Kubernetes 바로 뒤로 두 번째로 가장 활발한 프로젝트가 되었습니다. 애플리케이션이 텔레메트리 데이터를 생성하고 전송하는 방식을 표준화함으로써, OpenTelemetry는 데이터는 여러분의 것이고, 벤더가 아니라라는 것을 보장합니다.

이 가이드에서 다루는 내용

OpenTelemetry가 무엇인지
아키텍처가 어떻게 작동하는지
왜 현대 인프라에서 이제 기본 선택이 되었는지

Comic: OTel의 힘을 설명 (placeholder for illustration)

OpenTelemetry란?

OpenTelemetry는 오픈‑소스 관측 프레임워크로, 트레이스, 메트릭, 로그와 같은 텔레메트리 데이터를 생성, 수집, 내보낼 수 있게 해줍니다.

스토리지 백엔드나 시각화 도구가 아닙니다.
대신, 텔레메트리 데이터를 위한 범용 언어 및 전달 시스템 역할을 합니다.

OpenTelemetry를 배관에 비유해 보세요: 애플리케이션과 인프라에서 데이터를 수집하고, 처리한 뒤, 선택한 백엔드(SigNoz, Prometheus, Jaeger 등)로 전달합니다.

역사

2019년에 두 주요 프로젝트의 합병으로 탄생했습니다:
- 구글의 OpenCensus
- CNCF의 OpenTracing
목표: 계측을 위한 단일 표준으로 산업을 통합하는 것.

관측성의 세 가지 핵심 기둥

Pillar	What It Does	Example
Traces	분산 시스템에서 요청이 이동하는 과정을 추적합니다. 트레이스는 스팬(예: DB 쿼리 또는 HTTP 요청)으로 구성됩니다.	문제의 위치를 보여줍니다.
Metrics	시간에 따라 측정되는 수치 데이터 포인트(CPU 사용량, 메모리 소비, 요청 속도 등).	문제 발생 시점을 보여줍니다.
Logs	타임스탬프가 포함된 텍스트 기록으로, 종종 오류 메시지나 상태 업데이트를 포함합니다.	문제 발생 이유를 보여줍니다.

OTel을 세 가지 모두에 사용하면 자동으로 상관관계를 연결할 수 있습니다. 예를 들어, 특정 트레이스를 확인하면 정확히 같은 시간대에 생성된 로그를 즉시 볼 수 있으며, 모두 동일한 컨텍스트 태그를 공유합니다.

벤더 중립, 플러그‑앤‑플레이

With OTel you are not tied to a single vendor. → OTel을 사용하면 단일 벤더에 얽매이지 않습니다.
You can easily plug in any observability backend of your choice. → 원하는 관측성 백엔드를 쉽게 플러그인할 수 있습니다.
Supports many languages (Java, Python, Go, etc.) and platforms, making it versatile for different development environments. → 다양한 언어(Java, Python, Go 등)와 플랫폼을 지원하여 다양한 개발 환경에 유연하게 적용할 수 있습니다.

Source:

OpenTelemetry Framework

Specification

OTel의 핵심은 specification—텔레메트리 데이터가 어떻게 생성·처리·내보내져야 하는지를 정의한 공식 가이드라인 집합입니다.

언어, 도구, 벤더 간 interoperability를 보장합니다.
관측 데이터에 대한 일관된 모델을 제공합니다.

API vs. SDK

Component	Purpose	What Happens If Missing
API (Interface)	코드에 계측을 삽입할 때 사용하는 클래스·메서드(스팬 생성, 메트릭 기록)	API만 가져오면 구현이 no‑op이 됩니다—코드는 실행되지만 데이터가 생성되지 않습니다.
SDK (Implementation)	데이터 처리: 샘플링, 리소스 속성(`service.name`, `k8s.pod.name` 등), 배치, 내보내기	실제 텔레메트리 전송을 위해서는 반드시 필요합니다.

왜 분리했을까?

오픈소스 라이브러리에 무거운 의존성을 끌어들이지 않고 네이티브 계측을 삽입할 수 있습니다.
API는 가볍고 안전하게 유지하고, SDK는 복잡한 로직과 선택적 의존성을 포함할 수 있습니다.
사용자가 필요로 하지 않을 경우 런타임 비용을 발생시키지 않으면서, 내장된 관측성을 제공할 수 있습니다.

OTLP – OpenTelemetry Protocol

OpenTelemetry의 native language입니다.
SDK → Collector, 혹은 Collector → 백엔드 간 데이터를 전송하기 위한 매우 효율적인 프로토콜입니다.
gRPC와 HTTP 전송 방식을 지원합니다.
OTel이 Zipkin이나 Jaeger 포맷도 사용할 수 있지만, 효율적인 텔레메트리 전송을 위해 OTLP가 권장 기본값입니다.

OpenTelemetry Collector

애플리케이션과 백엔드 사이에 위치하는 vendor‑agnostic proxy입니다. 선택 사항이지만 프로덕션 환경에서는 강력히 권장됩니다.

Three Main Jobs

Receive – OTLP, Jaeger, Prometheus 등 다양한 포맷의 데이터를 수신합니다.
Process – 데이터를 정제·수정합니다(예: 헬스‑체크 트레이스 필터링, PII 제거, 인프라 태그 추가).
Export – 데이터를 하나 이상의 백엔드로 동시에 전송합니다.

Collector는 다음 형태로 배포할 수 있습니다.

Agent – 각 호스트에서 실행되는 데몬.
Gateway – 중앙 집중형 서비스.

Semantic Conventions

스펙은 공통 속성 이름(예: http.request.method, db.system)을 정의하여 구성 요소와 서비스 간의 일관성을 보장합니다. 따라서 데이터베이스 호출은 Python 애플리케이션이든 Java 애플리케이션이든 동일한 형태로 나타납니다.

OpenTelemetry가 미래인 이유

모듈식, 확장 가능, 미래 지향 – 한 번 계측하고 나중에 백엔드를 교체하세요 (SigNoz, Prometheus, Grafana, Datadog 등).
벤더 중립 – 텔레메트리 데이터를 직접 제어할 수 있습니다.
광범위한 생태계 – 강력한 커뮤니티 지원, 다양한 언어 라이브러리 및 통합.

TL;DR

OpenTelemetry는 트레이스, 메트릭, 로그를 하나의 데이터 스트림으로 표준화합니다.
Its API/SDK split, OTLP protocol, and Collector give you flexibility, performance, and vendor independence. → API/SDK 분리, OTLP 프로토콜, 그리고 Collector는 유연성, 성능, 벤더 독립성을 제공합니다.
Adopt OTel now to future‑proof your observability stack and avoid vendor lock‑in. → 지금 OTel을 도입해 관측 스택을 미래에 대비하고 벤더 종속을 피하세요.

OpenTelemetry 개요

OpenTelemetry (OTel)는 텔레메트리 데이터를 수집, 처리 및 내보내기 할 수 있게 해줍니다. 아래는 파이프라인을 단계별로 보여줍니다.

Instrumentation – OpenTelemetry API를 사용해 시스템에 무엇을 측정할지 알려줍니다(예: HTTP 지연 시간, DB 쿼리, 오류 이벤트).
SDK Collection – 애플리케이션에 포함된 SDK가 Instrumentation으로 생성된 데이터를 수집하고 처리용으로 전송합니다.
Collector Processing – OTel Collector는 처리 허브 역할을 합니다. 여기서 텔레메트리는 다음과 같이 처리될 수 있습니다:
- 샘플링됨
- 잡음을 줄이기 위해 필터링됨
- 다른 시스템의 메타데이터로 풍부해짐
  이 단계는 원시 신호에 유용한 컨텍스트를 추가합니다.
Exporters – 처리 후 데이터는 (필요한 경우) 관측 백엔드가 기대하는 형식으로 변환되고, Exporter에게 전달되어 목적지로 전송됩니다.
Backend Delivery – Collector를 떠나기 전에 데이터가 배치 처리될 수 있으며, 이후 하나 이상의 백엔드(예: SigNoz, 기타 클라우드 APM 서비스)로 라우팅됩니다.

Result: 애플리케이션 내부에서 시작해 관측 백엔드에 도달하는 텔레메트리 파이프라인.

왜 OpenTelemetry를 선택할까요?

벤더에 구애받지 않는 계측 – 표준 API 하나로 계측하고, 벤더를 바꾸려면 Collector 또는 Exporter 설정만 바꾸면 됩니다. 애플리케이션 코드는 그대로 유지됩니다.
표준화된 컨텍스트 전파 – OTel은 헤더(예: W3C Trace Context)를 삽입해 트레이스가 언어 경계를 넘어 끊기지 않도록 합니다(Go → Python 등).
개발자 중심 관측 – 라이브러리가 이제 OTel 훅을 기본 제공하므로, 라이브러리를 사용할 때 별도 비용 없이 텔레메트리를 얻을 수 있습니다.

트레이드오프

관심사	세부 내용
구성 복잡성	Collector는 매우 유연하지만, 올바른 구성을 찾기가 어려울 수 있습니다. 샘플링 비율과 메모리 제한을 관리하려면 신중함이 필요합니다.
버전 성숙도	Tracing은 대부분의 언어에서 안정적입니다. Metrics는 주요 언어에서는 안정적이지만 다른 곳에서는 아직 진화 중입니다. Logging은 가장 최신 신호이며 SDK마다 성숙도가 다릅니다.

OTel vs. 기존 도구

Feature	OpenTelemetry	Prometheus	Jaeger
Primary Role	텔레메트리 생성 및 수집	스토리지 및 쿼리(메트릭)	스토리지 및 시각화(트레이스)
Signals	트레이스, 메트릭, 로그	주로 메트릭만	트레이스만
Backend?	아니오 (파이프라인만)	예	예

OTel vs. Prometheus – 보완 관계. OTel은 메트릭을 스크래핑하여 Prometheus에 내보내거나, 스크래핑을 완전히 건너뛰고 PromQL을 지원하는 백엔드(예: SigNoz)로 직접 메트릭을 전송할 수 있습니다.
OTel vs. Jaeger – Jaeger는 트레이스를 저장·조회하는 백엔드입니다. OTel은 데이터를 Jaeger에 전송하는 파이프라인이며, Jaeger 클라이언트 라이브러리는 OpenTelemetry SDK로 대체되어 더 이상 사용되지 않습니다.

OpenTelemetry 구현

1. 애플리케이션 계측

방법	설명
자동 계측 (Zero‑code)	실행 중인 애플리케이션에 에이전트를 부착합니다 (예: Java JAR 에이전트, Python 배포판). HTTP 요청, DB 쿼리 및 표준 메트릭을 자동으로 수집합니다.
수동 계측	API를 임포트하고 직접 스팬을 생성하여 맞춤 비즈니스 로직을 계측합니다 (예: `process_payment()`, `calculate_inventory()`).

2. OTel Collector 구성

A minimal config.yaml:

receivers:
  otlp:
    protocols:
      grpc:
      http:

processors:
  batch:

exporters:
  otlp:
    endpoint: "ingest.us.signoz.cloud:443"   # use your region
    headers:
      signoz-ingestion-key: "${SIGNOZ_INGESTION_KEY}"

service:
  pipelines:
    traces:
      receivers: [otlp]
      processors: [batch]
      exporters: [otlp]

3. Exporter를 백엔드에 연결

처리된 데이터를 SigNoz와 같은 백엔드로 전송하여 분석합니다.

SigNoz – OpenTelemetry‑네이티브 관측 플랫폼

SigNoz는 OTel‑네이티브가 되도록 처음부터 설계되었습니다. 텔레메트리 데이터를 위한 백엔드 및 시각화 레이어 역할을 하며 OTel의 시맨틱 컨벤션을 완전히 활용합니다.

배포 옵션

옵션	설명
SigNoz Cloud	완전 관리형, 확장 가능한 솔루션 — 운영 오버헤드를 피하고자 하는 팀에 이상적입니다.
SigNoz Enterprise	자체 호스팅(클라우드 직접 구축 또는 온프레미스)으로, 전용 지원 및 엄격한 데이터 거주지·프라이버시 요구사항을 가진 조직을 위한 고급 보안을 제공합니다.

What’s Next?

이제 OpenTelemetry에 대한 기본적인 이해를 갖추었으니, 다음 단계들을 시도해 보세요:

OpenTelemetry로 애플리케이션을 계측
OpenTelemetry 데모 애플리케이션 설정
OpenTelemetry로 인프라를 계측

이 단계들을 수행하면 관찰, 디버깅 및 개선이 쉬운 시스템을 구축하는 길에 들어서게 됩니다.

도움이 더 필요하신가요?

If you have further questions about What is OpenTelemetry, you can:

Use the SigNoz AI chatbot
Join our Slack community

You can also subscribe to our newsletter for insights from observability nerds at SigNoz, and get open‑source, OpenTelemetry, and dev‑tool building stories straight to your inbox.