OpenTelemetry란 무엇이며, 나에게 어떤 도움이 될까?
Peter Wilson
2025년 7월 24일
이 블로그는 Peter Wilson, Craig Ringer, Dave Lawson이 공동 작성했습니다.
OpenTelemetry란?
OpenTelemetry(줄여서 OTel)는 오픈소스 텔레메트리 데이터 생성, 수집, 전송을 위한 프로젝트입니다. 서로 다른 벤더의 다양한 도구들이 원활하게 데이터를 주고받을 수 있도록 돕는 것이 목적이며, 벤더 중립적이고 광범위한 생태계를 가진 오픈소스 표준으로 널리 주목받고 있습니다.
OpenTelemetry는 다음과 같은 표준을 정의합니다:
- 로그, 메트릭, 트레이스 등 텔레메트리 데이터를 기술하는 데이터 형식
- 공통 텔레메트리 데이터 및 메타데이터를 위한 명명 규칙
- 데이터를 송수신하기 위한 OTLP(OpenTelemetry Protocol)
- 애플리케이션에 텔레메트리를 삽입할 수 있도록 하는 API 및 인터페이스 표준
또한 다음과 같은 구현체들도 제공합니다:
- 애플리케이션에 텔레메트리를 삽입하는 SDK(toolkit)
- OpenTelemetry Collector라는 멀티툴 데이터 수집·변환·라우팅 유틸리티
이러한 구현체들은 선택 사항이며, OpenTelemetry를 자체적으로 구현할 수도 있습니다. 하지만 이를 활용하면 구현이 훨씬 쉬워지고, 참고 구현(reference implementation)을 통해 표준에 맞춰 개발할 수 있습니다.
👉 OpenTelemetry 공식 블로그에서 더 많은 내용을 확인할 수 있습니다.
사이드바: OpenTelemetry vs OpenTelemetry Collector
많은 사람들이 **OpenTelemetry(프로토콜, 데이터 형식 등)**와 **OpenTelemetry Collector(구현체 중 하나)**를 혼동하곤 합니다.
OpenTelemetry Collector는 텔레메트리 데이터를 수집·처리·변환·전송하는 **에이전트(Collector)**입니다. 플러그인 카탈로그가 풍부하며, 기존 카탈로그에 없는 경우 새 플러그인을 쉽게 개발할 수 있습니다.
Collector는 OpenTelemetry의 핵심 구성 요소처럼 언급되지만, 필수는 아닙니다.
Collector를 쓴다고 해서 자동으로 OpenTelemetry를 완벽히 지원한다고 볼 수는 없습니다. 다만, OpenTelemetry를 더 쉽게 연동하고 공통 작업을 처리하는 데 도움이 됩니다.
OpenTelemetry가 제공하는 가치
OpenTelemetry는 벤더 종속 없이 기존 툴과 라이브러리를 활용할 수 있는 개방형 관측성 프레임워크입니다. 이를 통해 조직은 텔레메트리 도구의 총소유비용(TCO)을 절감할 수 있습니다.
또한, OpenTelemetry는 공통 표준을 기반으로 다양한 도구 간 호환성을 높이기 때문에:
- 도구 선택의 자유도를 높이고
- 운영 유연성을 확보하며
- 특정 벤더에 종속될 위험을 줄이는 장점을 제공합니다
👍 많은 조직이 성공적으로 활용 중이지만…
그런데 정말 “성공”일까?
OpenTelemetry가 다양한 문제를 해결해주긴 하지만, 모든 문제를 해결해주지는 않습니다.
OpenTelemetry 데이터를 어떻게 활용할 수 있을까?
OpenTelemetry는 데이터를 목적지에 전달하는 것까지가 역할입니다. 그 이후, 즉:
- 데이터를 저장
- 조회
- 시각화
- 알림 설정
- 분석 및 활용
…하는 것은 사용자 혹은 별도의 툴의 몫입니다.
바벨의 문제: 이름은 같지만 통하지 않는 언어
OpenTelemetry의 명명 규칙은 지침일 뿐이며, 일부 일반적인 케이스만 다룹니다.
즉, 툴과 Exporter들이 스스로 규칙을 정의하게 되며, 결과적으로:
- 표현은 같지만 의미가 다른 데이터가 전송되고
- 같은 프로토콜을 사용해도 도구 간 해석 불일치가 발생합니다.
특히 PostgreSQL 같은 경우:
- 네이티브 텔레메트리 지원이 부족하여 외부 Agent로 측정해야 하고
- 애플리케이션 별 텔레메트리 명세가 거의 없음에 따라
- 벤더별로 수집 항목과 명명이 제각각입니다.
그 결과:
- 일부 기본 대시보드가 빈 화면이 되기도 하고
- 로그와 메트릭 연결이 실패하거나
- 비용 산정 기준이 벤더마다 상이하여 예측이 어렵습니다
이 문제는 SaaS뿐 아니라 오픈소스 스택도 겪고 있는 문제입니다.
그렇다면 OpenTelemetry는 내게 어떤 도움이 될까?
상황에 따라 다릅니다. OpenTelemetry는 단순히 “그냥 구현하면 되는” 기술이 아닙니다.
OpenTelemetry뿐 아니라 모든 관측성(Observability) 전략의 핵심은, 먼저 조직이 해결하고자 하는 문제를 명확히 정의하는 것입니다.
당신의 조직은 어떤 문제를 해결하려고 하나요?
“OpenTelemetry를 도입하자”는 문장은 해답의 일부일 수는 있지만,
그 전에 먼저 어떤 질문에 대한 해답인지를 이해해야 합니다.
- 당신의 주요 과제는 텔레메트리 데이터를 A 지점에서 B 지점으로 전송하는 것인가요?
- 아니면 여러 백엔드나 데이터 저장소로 텔레메트리를 라우팅하는 기능이 필요한가요?
- 혹은 애플리케이션이 **메트릭이나 트레이스를 직접 생성하도록 계측(instrumentation)**해야 하나요?
이 모든 문제는 OpenTelemetry가 해결을 도울 수 있습니다.
하지만 각 문제를 명확히 정의하고, 성공을 측정할 수 있는 기준을 마련해야 합니다.
성공을 측정할 수 없다면, 목표를 달성했는지조차 알 수 없습니다.
텔레메트리 선택지를 고민해보자
이러한 정의 과정은 OpenTelemetry 도입 제안을 조직 내 여러 이해관계자에게 설명하고,
내부 수용과 채택을 유도하는 데 큰 도움이 됩니다.
하지만 OpenTelemetry가 해결할 수 없는 문제도 있다
조직이 직면한 문제가 다음과 같은 경우라면:
- 텔레메트리 데이터를 저장하고
- 시각화하며
- 알림(alerting)을 설정하거나
- 데이터를 기반으로 자동화된 액션을 수행해야 하는 경우,
➡️ OpenTelemetry는 완전한 해결책이 아닐 수 있습니다.
이런 상황에서는 OpenTelemetry는 단지 데이터를 백엔드로 전송하는 역할만 수행할 수 있으며,
데이터를 해석하고 반응하는 기능은 제공하지 않습니다.
또한, 어떤 작업에 있어서는 OpenTelemetry가 벤더 전용 에이전트보다 더 복잡하고 제약이 많을 수 있습니다.
중요한 사실: OpenTelemetry는 “전체”가 아니라 “일부분”이다
OpenTelemetry는 텔레메트리 및 관측성 파이프라인의 일부를 구성하는 프레임워크이자 생태계입니다.
그 자체만으로 완전한 솔루션이 아니며, 될 수도 없습니다.
따라서 OpenTelemetry는 반드시 다음 맥락에서 평가되어야 합니다:
- 이미 사용 중인 다른 도구들과의 통합 가능성
- 조직이 달성하고자 하는 궁극적 목표
이러한 조건들을 사전에 명확히 정리해두면,
단순히 “OpenTelemetry를 도입”하지 않더라도 다양한 방식으로 OpenTelemetry 생태계를 활용해
조직의 목표를 달성할 수 있는 적합한 접근법을 설계할 수 있습니다.
구현 옵션은 다양하다
OpenTelemetry를 구현하거나, 직접 구현하지 않더라도 그 도구를 활용하는 방법은 매우 다양합니다.
이 블로그에서 모두 다루기엔 옵션이 너무 많으며,
OpenTelemetry 공식 문서가 그 시작점으로 가장 적합합니다.
향후 방향: PostgreSQL의 미래와 OpenTelemetry 통합
이 블로그에서 언급된 PostgreSQL 관련 문제의 상당수는
PostgreSQL 자체가 OpenTelemetry를 네이티브로 지원하게 된다면 크게 완화될 수 있습니다.
이렇게 되면 모든 모니터링 도구가 공통적으로 이해할 수 있는 언어를 PostgreSQL이 제공하게 됩니다.
물론 이상적인 통합은 어렵습니다.
PostgreSQL을 관리하는 시스템들은 각기:
- 복제(replication),
- 장애 조치(failover),
- 분산 데이터베이스 처리 등에 있어 서로 다른 메타데이터를 사용하며,
- 프라이머리-리플리카(primary <-> replica) 관계 추적, 복제 지연 관리 등의 방식도 제각각이기 때문입니다.
하지만, 그럼에도 불구하고 OpenTelemetry 프로젝트가 자체적으로
PostgreSQL에 특화된 의미 기반 명세(semantic convention)를 정의한다면,
모든 구현자가 공통적으로 따를 수 있는 **기본 기준(baseline)**을 마련할 수 있습니다.
업계의 진화도 기대해볼 만하다
한편, 시장 압력에 따라 다양한 벤더들이
OpenTelemetry에 대한 네이티브 지원을 강화할 가능성도 큽니다.
이렇게 되면 OpenTelemetry는 각 벤더 제품 내에서 자연스럽게 통합 가능한 1급 구성 요소가 될 수 있습니다.
지금 당장은 OpenTelemetry가 당신의 문제를 해결하지 못하더라도,
한 번 시도해보고 나서도 안 맞는다고 느낀다 하더라도,
이 프로젝트가 해결하려는 문제의 규모와 방향은 매우 유의미하며,
지금보다 훨씬 넓은 채택과 생태계 확장을 앞두고 있는 것은 분명합니다.
OpenTelemetry의 발전은 지켜볼 가치가 충분하며,
조직의 기술 로드맵 상에서도 언젠가는 반드시 다시 돌아와야 할 주제가 될 가능성이 높습니다.
