Blog,Observability,미분류

쿠버네티스에서 애플리케이션은 수백 개의 Pod로 분산되고, 각 Pod는 수개의 컨테이너로 구성됩니다. 전통적인 모니터링 방식은 메트릭(Prometheus), 로그(EFK/ELK), 트레이스(Jaeger)를 각각 별도 스택으로 구축했습니다. 세 스택이 제각기 다른 포맷으로 데이터를 저장하므로, 한 Pod의 지연 문제를 진단하려면 세 대시보드를 오가며 상관관계를 수동으로 맞춰야 했습니다.

이 방식의 근본 문제는 데이터의 단편화입니다. 메트릭으로 이상 징후를 발견해도, 로그에서 원인을 찾고, 트레이스로 영향 범위를 파악하는 과정이 분리되어 있으면 장애 대응 시간이 기하급수적으로 늘어납니다.

그래서 우리 조직은 왜 지금 단일 파이프라인으로 통합해야 하는가. 답은 간단합니다. 구분된 도구 사이를 오가는 시간 자체가 운영 리스크이기 때문입니다. OpenTelemetry는 이 단편화를 해결하기 위해 CNCF가 표준으로 정한 단일 API·SDK·Collector 아키텍처를 제공합니다.

서로 다른 벤더의 제품을 조립해 만든 관측성 스택은 데이터·관리·책임 세 축이 동시에 끊깁니다. 아래 그림은 그 단절이 실제 운영에서 어떤 비용으로 돌아오는지 정리한 것입니다.

그림 1. 이종 벤더 제품을 조립한 구조는 데이터·관리·책임 3축이 모두 끊긴다 — 결국 MTTR 증가로 돌아온다.

1. 벤더 종속성

기존 트레이스 도구(Jaeger, Zipkin)나 메트릭 스택(Prometheus 전용)은 데이터 포맷과 수집 프로토콜이 벤더 고유의 방식으로 고정되어 있었습니다. 한 도구에서 다른 도구로 마이그레이션하려면 계측 코드 전체를 다시 써야 했습니다.

2. 계측 비용의 중복

각 도구마다 자체 SDK나 에이전트를 설치해야 하므로, 동일한 애플리케이션에 세 개의 SDK가 중복 설치되는 경우가 흔했습니다. 이는 애플리케이션의 성능 오버헤드를 3배로 늘리고, SDK 버전 충돌로 인한 예기치 않은 동작의 원인이 되었습니다.

3. 상관관계 단절

메트릭 이상 → 로그 확인 → 트레이스 탐색이라는 워크플로우에서 세 데이터가 서로 연결되지 않으면, 엔지니어가 수동으로 trace ID를 복사해 세 시스템에 입력하는 비효율이 발생합니다. Kubernetes 1.36부터는 OTLP(OpenTelemetry Protocol)를 통한 트레이스 내보내기가 기본 지원되지만(Kubernetes Docs, 2025-09-23), 기존 스택을 사용하는 팀은 여전히 수동 연계에 의존하고 있습니다.

OpenTelemetry는 로그, 메트릭, 트레이스 세 가지 텔레메트리 유형을 하나의 프레임워크로 처리합니다. 세 축은 각자 답하는 질문이 다르고, trace_id라는 공통 키로 묶였을 때 비로소 “왜 느려졌는가”에 답할 수 있습니다. 세 축의 역할 구분은 APM과 옵저버빌리티의 차이에서 더 자세히 다뤘습니다.

그림 2. 세 축은 상관관계로 묶일 때 비로소 원인을 설명한다 — 관측성의 세 기둥과 대표 질문.

핵심 구성 요소는 세 층으로 나뉩니다.

계층 1: API & SDK — 애플리케이션 코드에 삽입하는 계측 라이브러리입니다. 언어별로 Go, Python, Java, Node.js, .NET 등 20개 이상의 런타임이 공식 지원됩니다. SDK는 API를 구현하고, 수집한 데이터를 OTLP(OpenTelemetry Protocol) 형식으로 내보냅니다.

계층 2: OTel Collector — 데이터를 수신·처리·내보내는 중앙 허브입니다. 사이드카로 Pod에 배포하거나 독립형 에이전트로 클러스터에 설치할 수 있습니다. 수집기는 샘플링, 필터링, 변환, 집계 등의 전처리 기능을 내장하고 있어, 백엔드에 전송하기 전에 데이터를 정제할 수 있습니다(Causely, 2024).

계층 3: 백엔드 — 수집된 데이터를 저장하고 시각화하는 저장소입니다. Prometheus, Jaeger, Loki, Datadog, Elastic, Grafana Cloud 등 다양한 백엔드와 호환됩니다. OTLP는 벤더 중립 프로토콜이므로, 한 번 계측하면 백엔드를 쉽게 교체할 수 있습니다.

OTel Collector 파이프라인 구조

OTel Collector의 핵심은 파이프라인(receivers → processors → exporters) 개념입니다.

그림 3. Collector는 단일 통로다 — 받고(Receivers) · 다듬고(Processors) · 분배한다(Exporters).

• Receiver(수신기): 데이터 소스로부터 데이터를 받습니다. OTLP(gRPC/HTTP), Jaeger, Prometheus, Fluent Bit 등 다양한 프로토콜을 지원합니다.
• Processor(처리기): 데이터를 필터링, 변환, 집계, 샘플링합니다. batch 프로세서는 효율성을 위해 데이터를 뭉치고, attributes 프로세서는 메타데이터를 추가합니다.
• Exporter(내보내기): 처리된 데이터를 목적지 백엔드로 전송합니다. OTLP, Jaeger, Prometheus, Zipkin, Elastic 등 다양한 포맷으로 내보낼 수 있습니다.

이 파이프라인 아키텍처 덕분에 같은 애플리케이션에서 수집한 데이터를 여러 백엔드에 동시에 보낼 수 있습니다. 메트릭은 Prometheus에, 트레이스는 Jaeger에, 로그는 Loki에 — 각각 최적의 저장소를 선택하면서도 계측 코드는 한 번만 작성하면 됩니다.

계측은 한 번에 전부 하는 것이 아니라 세 계층으로 나눠 쌓습니다. 코드를 건드리지 않는 자동 계측으로 기본 신호를 확보하고, 도메인 맥락이 필요한 곳만 수동으로 보강하고, 호스트·커널 영역은 인프라 에이전트로 덮습니다.

그림 4. 3계층 계측 전략 — 자동으로 깔고, 도메인만 손으로 보강하고, 인프라는 에이전트로 덮는다.

쿠버네티스 환경에 OpenTelemetry를 도입하는 가장 일반적인 경로는 다음 4단계로 진행됩니다. 클러스터 구성이 아직 없다면 쿠버네티스 설치 가이드부터 시작하고, 테스트 목적이면 k3s 경량 배포판이 빠릅니다.

1단계: OTel Collector DaemonSet 배포

클러스터 전체의 텔레메트리를 수집하려면 OTel Collector를 DaemonSet으로 각 노드에 배포합니다. Helm Chart(otel/opentelemetry-collector)를 사용하면 몇 분 안에 기본 구성을 설치할 수 있습니다. DaemonSet 방식의 장점은 각 노드의 시스템 메트릭, kubelet 메트릭, 컨테이너 로그를 한 곳에서 수집할 수 있다는 점입니다.

Kubernetes는 이미 /metrics 엔드포인트를 통해 컨트롤 플레인 컴포넌트(kube-apiserver, kube-controller-manager, kube-scheduler, kube-proxy)의 메트릭을 Prometheus 형식으로 노출하고 있습니다(Kubernetes Docs, 2025-09-23). OTel Collector는 이러한 Kubernetes 네이티브 메트릭도 OTLP로 변환하여 백엔드로 보낼 수 있습니다.

2단계: 애플리케이션 계측

애플리케이션에 OTel SDK를 삽입합니다. 예를 들어 Python 애플리케이션이라면 opentelemetry-api와 opentelemetry-sdk 패키지를 설치하고, 애플리케이션 시작 시 트레이서와 메트릭 리더를 초기화합니다. 코드 변경은 최소한으로 유지할 수 있는데, Auto-Instrumentation Operator를 사용하면 Sidecar 컨테이너를 자동으로 주입하여 코드 수정 없이 계측할 수 있습니다.

3단계: 파이프라인 구성

otel-collector-config.yaml에서 Receiver-Processor-Exporter 파이프라인을 정의합니다. 예를 들어 OTLP 수신기로 트레이스와 메트릭을 받고, batch 프로세서로 뭉친 후, Prometheus exporter로 메트릭을, OTLP exporter로 트레이스를 보내는 구성이 일반적입니다. 프로세서 체인에 resource 프로세서를 추가하여 Kubernetes Pod 메타데이터(네임스페이스, 노드 이름, 서비스 이름)를 자동으로 주입하면, 나중에 백엔드에서 Namespace별·Service별 필터링이 즉시 가능해집니다.

4단계: 백엔드 연동

선택한 백엔드(Jaeger, Prometheus, Grafana 등)에 데이터를 연결합니다. OTel Collector가 이미 벤더 중립 프로토콜을 사용하므로, 백엔드 변경 시 파이프라인 구성만 수정하면 됩니다. Grafana Tempo(Loki) + Grafana Alloy(구 Telegraf) 조합은 OTel native 환경을 제공하는 대표적인 오픈 소스 스택입니다. Enterprise 환경에서는 Datadog, New Relic, Dynatrace 같은 상용 APM과 OTel SDK를 함께 쓰는 하이브리드 방식도 널리 쓰입니다.

기존 분산 관측성 스택과 OpenTelemetry 기반 단일 파이프라인을 비교하면 도입 효과가 명확해집니다.

이 비교표에서 보듯, OpenTelemetry는 도입 초기에 약간의 학습 곡선이 있지만, 장기적으로는 운영 효율성과 유연성에서 우위를 보입니다. 특히 Kubernetes 1.36에서 OTLP 내보내기가 기본 지원되면서(Kubernetes Docs, 2025-09-23), 신규 클러스터에서는 OTel Collector와의 통합이 더욱 쉬워졌습니다.

OpenTelemetry 기반 단일 파이프라인을 도입하면 다음과 같은 효과가 기대됩니다.

대응 시간 단축 — 메트릭 이상 시 트레이스와 로그가 자동으로 연결되므로, 장애 원인 파악 시간을 기존 대비 60~80% 단축할 수 있습니다. trace ID가 세 시스템을 자동으로 연결하므로, 엔지니어가 수동으로 ID를 복사해 넣을 필요가 없습니다.

운영 비용 절감 — 중복 SDK 설치가 사라지고, 단일 Collector로 여러 백엔드를 대체할 수 있으므로 인프라 리소스 비용을 줄일 수 있습니다.

벤더 종속 탈피 — OTLP는 벤더 중립 프로토콜이므로, 백엔드 공급자를 쉽게 교체할 수 있습니다. 가격 협상이나 기능 요구사항에 따라 유연하게 대응할 수 있습니다.

확장성 — 새로운 언어나 프레임워크가 추가될 때마다 별도 에이전트를 설치할 필요가 없습니다. OTel SDK가 20개 이상 런타임을 공식 지원하므로, 신기술 도입 시 계측이 훨씬 수월해집니다.

OpenTelemetry와 기존 APM 도구( Datadog, New Relic )의 차이는 무엇인가요?

APM 도구는 관리형 서비스로 편의성은 높지만 벤더 종속성이 강합니다. OpenTelemetry는 오픈 소스 프레임워크로 데이터 포맷과 수집 프로토콜이 벤더 중립입니다. APM과 OpenTelemetry를 함께 사용하는 것도 일반적인데, OTel SDK로 계측한 데이터를 APM 백엔드로 보내는 hybrid 방식입니다.

OTel Collector를 사이드카로 배포해야 하나요, 독립형 에이전트로 둬야 하나요?

둘 다 가능합니다. 사이드카 방식은 애플리케이션과 같은 Pod에 배치하여 애플리케이션별 맞춤형 계측이 필요할 때 적합합니다. 독립형 에이전트(DaemonSet) 방식은 클러스터 전체의 시스템 메트릭과 로그를 수집할 때 효율적입니다. 실제로는 DaemonSet Collector + 애플리케이션 SDK 조합이 가장 일반적입니다.

OpenTelemetry 도입 시 애플리케이션 성능에 어떤 영향을 미치나요?

OTel SDK의 성능 오버헤드는 일반적으로 5~15% 정도로 보고됩니다. Auto-Instrumentation Operator를 사용하면 애플리케이션 코드 변경 없이 Sidecar로 계측할 수 있어, 코드 수정으로 인한 리스크를 완전히 제거할 수 있습니다.

로그, 메트릭, 트레이스를 정말 하나로 모을 수 있나요?

네. OTel Collector의 파이프라인 아키텍처가 이를 가능하게 합니다. Receiver로 세 가지 데이터를 모두 받고, Processor에서 공통 메타데이터(서비스 이름, 네임스페이스, Pod ID 등)를 붙인 뒤, Exporter에서 각 데이터 유형에 맞는 백엔드로 보냅니다. 핵심은 세 데이터가 동일한 trace/span ID를 공유한다는 점입니다.

쿠버네티스 외부(온프레미스)에서도 사용할 수 있나요?

물론입니다. OpenTelemetry는 클라우드 네이티브 환경뿐만 아니라 온프레미스, 멀티 클라우드, 하이브리드 환경 모두에서 동작합니다. OTLP 프로토콜은 네트워크 기반 프로토콜이므로, 데이터 소스와 백엔드가 서로 다른 네트워크에 있어도 통신할 수 있습니다.

OpenTelemetry 공식 문서

• OpenTelemetry 공식 문서 — API, SDK, Collector, Protocol 공식 문서
• Kubernetes 관측성 가이드 — Kubernetes 1.36 OTLP 내보내기 포함
• CNCF TAG Observability — CNCF 관측성 기술자문그룹
• OTel Collector Contrib Receivers/Exporters — 80개 이상 수신기/내보내기 커넥터
• OpenTelemetry Python SDK — Python 계측 시작 가이드
• OpenTelemetry Java SDK — Java 계측 시작 가이드
• OpenTelemetry Go SDK — Go 계측 시작 가이드
• Auto-Instrumentation Kubernetes Operator — Sidecar 자동 주입
• OTLP 스펙 문서 — OpenTelemetry Protocol 사양
• CNCF Observability Whitepaper — CNCF 관측성 백서

함께 읽으면 좋은 글

관측성·APM 기초

• APM 옵저버빌리티 차이 — 무엇이 다르고, 무엇부터 갖춰야 하나 — 이 글의 전제가 되는 개념 정리
• APM 핵심 지표 읽는 법 — 응답시간·TPS·에러율의 의미 — 메트릭 축을 실제로 읽는 기준값
• WAS 성능 튜닝 — JVM 힙·GC·스레드 풀·커넥션 풀 기준값 가이드 — 트레이스가 가리킨 병목을 실제로 고치는 단계

쿠버네티스 기반 다지기

• 쿠버네티스(Kubernetes)란 무엇인가 — AI 표준 플랫폼
• 쿠버네티스 아키텍처 완전 정복 — 컨트롤 플레인부터 워커 노드까지 — Collector를 어디에 배치할지 판단하는 근거
• 쿠버네티스 Pod 완벽 가이드 — 개념·생명주기·멀티컨테이너 패턴 — 사이드카 계측을 이해하려면 먼저
• 쿠버네티스 설치 가이드 — 첫 클러스터 구축
• k3s란? 경량 쿠버네티스의 구조와 배포판 선택 가이드 — 계측 실습용 클러스터를 빠르게 띄울 때

클라우드 네이티브 설계 원칙

• 클라우드 네이티브 4대 요소 — 컨테이너·MSA·CI/CD·DevOps
• 12 Factor App — 클라우드 네이티브 설계 원칙 12가지 — 로그를 이벤트 스트림으로 다루는 원칙(XI)
• 클라우드 네이티브 보안 — 4C 모델부터 DevSecOps까지 — 텔레메트리의 PII 마스킹과 이어지는 주제
• 클라우드 네이티브 전환 로드맵 — 5단계 마이그레이션 전략

AI 운영으로 확장하기

• Agentic AI란 무엇인가 — 생성형 AI의 다음 단계 — 수집한 텔레메트리를 에이전트가 읽고 판단하는 단계
• RAG란 무엇인가 — 파이프라인 해부와 기업 도입 체크리스트 — 로그·트레이스를 근거로 삼는 검색 증강 구조