옵저버빌리티 벤더를 교체해 본 모든 엔지니어링 팀은 진짜 비용이 계약이 아니라는 것을 압니다 — 진짜 비용은 모든 서비스를 다시 계측하고, 모든 익스포터를 다시 작성하고, 온콜 로테이션에 새 에이전트 사용법을 재교육하는 데서 발생합니다. 이것이 바로 OpenTelemetry가 해결하기 위해 만들어진 문제이며, 그 공식 Vendors 목록이 조용히 옵저버빌리티 업계에서 가장 주목받는 페이지 중 하나가 된 이유입니다. 이는 "실제로 OTel 데이터를 맡길 수 있는 플랫폼은 어디인가?"라는 질문에 대해 시장이 가질 수 있는 가장 중립적인 답에 가장 가깝습니다.
TrueWatch가 이제 그 목록에 이름을 올렸습니다 — AWS, Microsoft Azure, Google Cloud, Datadog, Dynatrace, Elastic, Grafana Labs, New Relic, Splunk와 나란히 등재되었으며, 저희 이름 옆에는 두 가지 속성이 표시되어 있습니다: Commercial: Yes와 Native OTLP: Yes.
벤더 중립적 텔레메트리가 이제 기본 요건이 된 이유
OpenTelemetry(OTel)는 CNCF가 호스팅하는 오픈소스 표준으로, 트레이스, 메트릭, 로그를 벤더 중립적인 형식으로 생성, 수집, 전송하기 위해 만들어졌습니다. 이는 옵저버빌리티가 대부분의 엔지니어링 조직에게 수년에 걸친 다중 벤더 의사결정이 되는 순간, '한 번 계측하면 영원히 고착된다'는 기존 모델이 더 이상 의미가 없어졌기 때문에 존재합니다.
"기업들은 더 이상 벤더를 먼저 고른 뒤 툴링이 나중에 따라오기를 바라지 않습니다. OpenTelemetry에서는 표준이 먼저이고, 벤더는 그 표준을 충족하거나 논의에서 배제됩니다. 목록에 등재되었다는 것은 TrueWatch가 이제 OTel을 표준으로 채택하는 모든 팀에게 기본적으로 고려되는 선택지가 되었다는 의미입니다." — Mike Loong, TrueWatch CEO
이러한 변화는 미국, 싱가포르, 인도네시아처럼 빠르게 성장하는 시장의 팀들에게 특히 중요합니다. 이러한 시장에서는 인프라가 처음부터 클라우드 우선, 다중 리전으로 구축되는 경우가 많기 때문입니다. OpenTelemetry를 표준으로 채택한다는 것은 백엔드, 리전, 벤더가 바뀌더라도 계측 계층은 그대로 유지된다는 의미입니다.
TrueWatch의 등재가 OpenTelemetry 벤더 지형도에 더하는 의미
OpenTelemetry Vendors 페이지는 마케팅용 디렉터리가 아닙니다 — 이는 OTLP를 통해 OTel 데이터를 네이티브로 수신하고, 이를 단순한 패스스루 파이프가 아니라 최종 사용자가 실제로 사용할 수 있는 옵저버빌리티 솔루션으로 전환할 수 있는 플랫폼들의 등록부입니다. 목록에 등재된다는 것은 데이터시트에 OTel "지원"을 명시하는 것이 아니라, 이 기준을 실제로 통과했다는 의미입니다. 현재 플랫폼을 비교 중인 팀들에게 이는 TrueWatch가 지형도에서 차지하는 위치를 바꿉니다: 어쩌다 OTel 데이터를 받아들이는 대안이 아니라, 이미 목록에 있는 벤더들과 동등한 위치에 서게 된 것입니다.
"저희를 Datadog, Grafana, New Relic과 함께 검토하는 팀들에게, 이번 등재는 질문 자체를 '어떤 독점 에이전트에 락인될 것인가'에서 '어떤 OTel 네이티브 백엔드가 우리 스택에 맞는가'로 바꿔줍니다. 이는 훨씬 쉽게 '예'라고 답할 수 있는 결정이며, 잘 맞지 않을 경우 되돌리기도 훨씬 쉬운 결정입니다." — Brandon Foo, TrueWatch Head of Growth & GTM
TrueWatch의 Native OTLP 지원 살펴보기
Native OTLP 지원은 말로는 간단해 보입니다 — 데이터를 받고, 저장하면 됩니다. 하지만 실제로는 단순히 OTLP 페이로드를 수신하는 플랫폼과, 실제 프로덕션 부하 상황에서도 그 데이터를 유용하게 만들 수 있는 플랫폼 사이에는 큰 차이가 있습니다.
TrueWatch는 DataKit의 OpenTelemetry 입력을 통해 OpenTelemetry Traces, Metrics, Logs를 네이티브로 수집하여, 어떤 언어나 프레임워크에서 오는 텔레메트리든 하나의 옵저버빌리티 컨텍스트로 통합합니다. 프로토콜 수준에서 TrueWatch는 다음을 지원합니다:
- gRPC를 통한 OTLP
- HTTP/Protobuf를 통한 OTLP
- Traces, Metrics, Logs를 위한 독립적인 엔드포인트
- HTTP 및 gRPC 전송 모두에 대한 gzip 압축
- OpenTelemetry Java Agent (V1, V2 모두 지원)
"OTLP를 지원한다는 것은 단순히 gRPC나 HTTP 엔드포인트를 여는 것이 아닙니다. 진짜 작업은 수집 이후에 이루어집니다 — 샘플링 결정, 카디널리티 제어, 프로덕션 규모에서 트레이스-로그 연관성을 온전히 유지하는 일입니다. 저희가 이번 등재를 얻어낸 것은 단순한 설정 플래그가 아니라 바로 이러한 부분 때문입니다." — Jimmy Soh, TrueWatch Head of Product & Solutions Engineers
프로덕션을 위한 설계: 대규모 환경에서의 샘플링, 거버넌스, 비용
OTLP 트래픽을 수신하는 것과, 이를 프로덕션 규모에서 유용하고 비용 효율적으로 유지하는 것은 별개의 문제입니다. TrueWatch의 OpenTelemetry 통합은 엔지니어링 팀들이 꾸준히 요구해 온 세 가지 프로덕션 요건을 중심으로 설계되었습니다:
- 유연한 거버넌스 — 트레이스 샘플링, 희소 리소스 보존, 오류 필터링, 태그 허용/차단 목록, 로컬 캐싱을 통해 모든 데이터를 저장하는 비용 없이도 중요한 신호를 유지
- 호환 가능한 분석 — 요청량, 오류율, 지연 시간, Apdex 점수를 트레이스 데이터에서 직접 추출하며, 레거시 DDTrace 계측과의 호환성을 지원하여 전면 교체 없이 마이그레이션 가능
- 통합된 컨텍스트 — 트레이스, 메트릭, 로그가 서로 단절된 세 개의 사일로가 아니라 동일한 옵저버빌리티 모델 안에 통합됨
바로 여기서 OpenTelemetry 자체의 한계도 분명해집니다: OTel은 텔레메트리가 어떻게 생성, 수집, 전송되는지를 해결하지만, 팀이 어떻게 이상 징후를 발견하고, 여러 신호에 걸쳐 상관관계를 분석하고, 인시던트를 종결하는지는 해결하지 않습니다. 이를 위해서는 여전히 그 아래를 받쳐주는 완전한 옵저버빌리티 플랫폼이 필요합니다. TrueWatch는 OTel에서 수집된 데이터를 APM, 인프라 및 컨테이너 모니터링, 로그 관리, 사용자 경험 모니터링(RUM), 알림, 인시던트 관리와 결합하여, 트레이스가 단순히 도착하는 데 그치지 않고 발견-분석-위치파악-해결 워크플로우의 일부가 되도록 합니다.
하나의 플랫폼, 650개 이상의 통합 — OpenTelemetry는 시작일 뿐
OpenTelemetry는 TrueWatch로 들어오는 여러 경로 중 하나일 뿐, 유일한 경로가 아닙니다. 이 플랫폼은 현재 호스트, 컨테이너, Kubernetes, 클라우드 플랫폼, 데이터베이스, 미들웨어, 네트워크 장비, 로그, 애플리케이션, RUM 전반에서 650개 이상의 통합을 지원하며, OpenTelemetry, Prometheus, Telegraf를 수집 방식으로 나란히 함께 사용할 수 있습니다.
그 폭넓은 지원은 실제 현장에서 중요한 의미를 갖습니다: 대부분의 엔지니어링 조직은 순수하게 OTel만 사용하는 단일 스택을 운영하지 않습니다 — Prometheus 익스포터, 레거시 에이전트, 그리고 OTel 마이그레이션 이전부터 있던 클라우드 네이티브 통합들과 OTel을 함께 운영하는 경우가 대부분입니다. DataKit의 통합 수집 계층 덕분에 팀은 하나의 수집 방식을 선택하고 나머지를 모두 걷어낼 필요가 없습니다. 다른 모든 것이 동일한 옵저버빌리티 컨텍스트로 계속 보고되는 동안, 자신들의 속도에 맞춰 OpenTelemetry를 도입할 수 있습니다.
더 알아보기:
- OpenTelemetry 공식 Vendors 페이지: https://opentelemetry.io/ecosystem/vendors/
- TrueWatch OpenTelemetry 통합 문서: https://docs.truewatch.com/integrations/opentelemetry/