로깅에서 APM, 관측 가능성으로 이어지는 모니터링의 진화를 살펴보고, OpenTelemetry가 탄생한 배경과 3대 신호, 벤더 중립의 가치를 이해합니다.
시스템 운영의 역사는 로그(Log)에서 시작됩니다. 유닉스 시스템의 syslog부터 애플리케이션이 남기는 텍스트 파일까지, 로그는 가장 오래되고 직관적인 디버깅 도구였습니다. 문제가 발생하면 서버에 접속하여 tail -f로 로그를 확인하는 것이 운영자의 일상이었습니다.
하지만 시스템이 복잡해지면서 로그만으로는 한계가 드러났습니다. 수십 대의 서버에 분산된 로그를 하나하나 확인하는 것은 비효율적이었고, "무엇이 일어났는가"는 알 수 있어도 "왜 일어났는가"를 파악하기는 어려웠습니다.
**APM(Application Performance Monitoring)**은 애플리케이션의 성능을 자동으로 측정하고 시각화하는 접근법입니다. New Relic, Datadog, AppDynamics 같은 상용 도구가 이 시장을 이끌었습니다. APM은 응답 시간, 처리량, 에러율 같은 핵심 지표를 자동으로 수집하고, 느린 트랜잭션을 추적하여 병목 지점을 찾아주었습니다.
그러나 APM에는 치명적인 문제가 있었습니다. **벤더 종속(Vendor Lock-in)**입니다. 한 번 특정 APM 도구를 도입하면, 해당 도구의 에이전트와 SDK가 코드 곳곳에 심어지고, 다른 도구로 전환하려면 막대한 비용이 발생합니다. 또한 각 도구마다 데이터 형식과 전송 프로토콜이 달라 상호 운용이 불가능했습니다.
**관측 가능성(Observability)**은 "시스템의 외부 출력만으로 내부 상태를 추론할 수 있는 능력"을 의미합니다. 제어 이론에서 차용된 이 개념은 단순한 모니터링을 넘어, 예측하지 못한 장애 상황에서도 원인을 파악할 수 있는 능력을 강조합니다.
모니터링이 "미리 정의한 질문에 대한 답"을 제공한다면, 관측 가능성은 "미리 예상하지 못한 질문에도 답할 수 있는 역량"을 제공합니다.
현대 관측 가능성은 세 가지 핵심 신호(Signal)로 구성됩니다. 이 세 신호를 통합적으로 수집하고 연관시키는 것이 관측 가능성의 핵심입니다.
**분산 추적(Distributed Tracing)**은 하나의 요청이 여러 서비스를 거치는 전체 경로를 기록합니다. 사용자가 API를 호출하면, 그 요청이 게이트웨이 → 인증 서비스 → 비즈니스 로직 → 데이터베이스를 거치는 과정을 하나의 트레이스로 연결하여 볼 수 있습니다.
각 서비스에서의 처리는 **스팬(Span)**이라는 단위로 기록되며, 스팬들이 부모-자식 관계로 연결되어 하나의 트레이스를 구성합니다. 이를 통해 "어느 서비스에서 지연이 발생했는가", "어떤 외부 호출이 실패했는가"를 정확히 파악할 수 있습니다.
**메트릭(Metrics)**은 시간에 따른 수치 데이터입니다. CPU 사용률, 메모리 사용량, 요청 처리량, 에러율 같은 지표를 일정 주기로 수집합니다. 메트릭은 저장 비용이 낮고 집계가 용이하여, 대시보드와 알림의 기반이 됩니다.
메트릭은 "현재 시스템이 정상인가?"라는 질문에 가장 빠르게 답할 수 있는 신호입니다. 하지만 메트릭만으로는 문제의 원인을 깊이 파고들기 어렵습니다.
**로그(Logs)**는 시스템에서 발생하는 이벤트의 텍스트 기록입니다. 구조화 로그(Structured Log)는 JSON 형태로 정형화된 데이터를 담아 검색과 분석을 용이하게 합니다. 로그는 가장 상세한 맥락 정보를 제공하지만, 저장량이 많아 비용 관리가 중요합니다.
진정한 관측 가능성은 이 세 신호를 **상관관계(Correlation)**로 연결할 때 완성됩니다. 메트릭 대시보드에서 에러율 급증을 감지하고, 해당 시점의 트레이스를 조회하여 실패한 요청의 경로를 확인하고, 관련 로그에서 상세 에러 메시지를 확인하는 것 -- 이것이 관측 가능성이 지향하는 워크플로우입니다.
OpenTelemetry는 두 개의 선행 프로젝트가 합쳐져 탄생했습니다.
OpenTracing은 2016년 CNCF에 합류한 분산 추적 API 표준입니다. 벤더 중립적인 추적 API를 정의하여, 애플리케이션 코드를 변경하지 않고도 백엔드를 교체할 수 있게 했습니다. Uber가 만든 Jaeger가 대표적인 구현체였습니다.
OpenCensus는 Google이 내부에서 사용하던 Census 라이브러리를 오픈소스로 공개한 것입니다. 추적뿐 아니라 메트릭까지 통합 수집하는 접근을 취했으며, Microsoft도 적극적으로 참여했습니다.
두 프로젝트는 비슷한 목표를 가지고 있었지만, 커뮤니티가 분산되는 문제가 있었습니다. 2019년, 두 프로젝트의 핵심 기여자들이 합의하여 **OpenTelemetry(OTel)**라는 이름으로 통합했습니다.
OpenTelemetry는 CNCF(Cloud Native Computing Foundation) 인큐베이팅 프로젝트를 거쳐, Kubernetes에 이어 CNCF에서 두 번째로 활발한 프로젝트가 되었습니다. 2024년에 CNCF 졸업(Graduated) 프로젝트로 승격되었으며, 이는 프로덕션 환경에서의 안정성과 성숙도를 인정받은 것입니다.
2026년 현재, OpenTelemetry의 현황은 다음과 같습니다.
주요 클라우드 벤더(AWS, GCP, Azure)와 관측 가능성 도구(Datadog, Splunk, Elastic, Grafana Labs)가 모두 OTLP(OpenTelemetry Protocol)를 네이티브로 지원하고 있습니다.
벤더 종속은 단순히 도구 교체 비용만의 문제가 아닙니다. 가격 협상력을 잃고, 기술 선택의 자유를 제한받으며, 벤더의 로드맵에 종속됩니다.
OpenTelemetry는 계측(Instrumentation)과 백엔드(Backend)를 완전히 분리합니다. 애플리케이션에는 OTel SDK만 통합하고, 데이터를 어디로 보낼지는 Collector의 설정만으로 변경할 수 있습니다.
exporters:
# 백엔드를 설정만으로 교체 가능
otlp/jaeger:
endpoint: "jaeger:4317"
otlp/tempo:
endpoint: "tempo:4317"
prometheus:
endpoint: "0.0.0.0:8889"
service:
pipelines:
traces:
receivers: [otlp]
processors: [batch]
exporters: [otlp/tempo] # Jaeger에서 Tempo로 전환? 이 줄만 변경벤더 중립 관측 가능성의 핵심은 "한 번 계측하면, 어디로든 보낼 수 있다(Instrument once, export anywhere)"는 원칙입니다. 애플리케이션 코드를 변경하지 않고 백엔드를 교체하거나 여러 백엔드에 동시 전송이 가능합니다.
벤더 중립 접근법은 다음과 같은 실무적 이점을 제공합니다.
OpenTelemetry는 하나의 라이브러리가 아니라, 관측 가능성 생태계를 구성하는 여러 구성 요소의 집합입니다.
| 구성 요소 | 역할 |
|---|---|
| Specification | API, SDK, 데이터 모델의 언어 독립적 명세 |
| API | 계측을 위한 인터페이스 정의 (구현 없음) |
| SDK | API의 실제 구현체 (샘플링, 배치 처리, 내보내기) |
| Collector | 텔레메트리 데이터 수집/처리/전송 독립 프로세스 |
| OTLP | OpenTelemetry Protocol — 표준 전송 프로토콜 |
| Semantic Conventions | 속성/이벤트 명명 규칙 표준 |
| Auto-instrumentation | 코드 변경 없이 자동 계측하는 라이브러리/에이전트 |
이 시리즈는 총 11장으로 구성되며, OpenTelemetry의 이론과 실무를 모두 다룹니다.
이 시리즈는 Python, Node.js, Go 예제를 포함하며, Docker Compose를 활용한 실습 환경을 제공합니다. 실습을 위해 Docker가 설치된 환경을 준비해 주세요.
이번 장에서는 모니터링의 진화 과정을 따라가며 관측 가능성이라는 패러다임이 왜 등장했는지 살펴보았습니다. OpenTelemetry는 OpenTracing과 OpenCensus의 통합으로 탄생하여, CNCF 졸업 프로젝트로서 관측 가능성의 사실상 표준이 되었습니다. 트레이스, 메트릭, 로그라는 3대 신호를 벤더 중립적으로 수집하고 연관시키는 것이 OpenTelemetry의 핵심 가치입니다.
다음 장에서는 OpenTelemetry의 내부 아키텍처를 심층적으로 분석합니다. API, SDK, Collector의 3계층 구조와 컨텍스트 전파 메커니즘, 시맨틱 컨벤션을 자세히 살펴보겠습니다.
이 글이 도움이 되셨나요?
관련 주제 더 보기
OpenTelemetry의 API/SDK/Collector 3계층 구조, W3C TraceContext 기반 컨텍스트 전파, 리소스와 시맨틱 컨벤션, 배포 패턴을 심층적으로 분석합니다.
스팬의 내부 구조와 종류, 부모-자식 관계, 샘플링 전략(Head/Tail/Rate)을 학습하고 Python으로 분산 추적을 직접 구현합니다.
OpenTelemetry 메트릭의 종류(Counter, Gauge, Histogram), 카디널리티 관리, Exemplars를 통한 메트릭-트레이스 연결, Prometheus 호환을 학습합니다.