딥리서치로 찾아본, 대규모 기업의 OpenTelemetry 도입 사례

오늘날 OpenTelemetry(OTel)는 마이크로서비스 환경에서 Observability(관측 가능성)를 구현하기 위한 사실상의 표준으로 자리잡았습니다. 다음에서는 eBay, Shopify, GitHub을 비롯한 대규모 트래픽을 처리하는 대표 기업들이 OpenTelemetry를 도입한 배경과 구현 방식, 활용 중인 백엔드, 전체 아키텍처 규모, 운영상의 이점과 해결한 문제점 등을 사례별로 정리합니다.

eBay의 OpenTelemetry 도입

도입 배경: eBay는 수년간 자체 Observability 플랫폼인 Sherlock을 통해 애플리케이션을 모니터링해왔으며, Elastic사의 Beats 에이전트(Filebeat, Metricbeat)를 사용해 로그와 메트릭을 수집해 왔습니다 (Why and How eBay Pivoted to OpenTelemetry). eBay의 플랫폼은 매 분 150만 개 이상의 Prometheus 엔드포인트를 스크레이핑하여 초당 4천만 개에 달하는 메트릭 샘플을 처리하고, 30억 개가 넘는 활성 시계열 데이터를 저장할 정도로 대규모로 운영되고 있었습니다 (Why and How eBay Pivoted to OpenTelemetry). 이러한 거대한 규모 속에서 서로 다른 에이전트와 포맷을 사용하다 보니 표준화의 필요성이 대두되었고, 마침 OpenTracing과 OpenCensus의 통합으로 등장한 OpenTelemetry의 성숙도가 높아지자 eBay는 관측 기술을 업계 표준으로 재편하기 위해 OpenTelemetry 도입을 결정했습니다 (Why and How eBay Pivoted to OpenTelemetry). 다시 말해, Beats 기반의 기존 솔루션을 장기적으로 대체하여 벤더 중립적이고 통합된 계측 표준으로 전환하려는 전략적 선택이었습니다.

구현 방식: eBay는 2021년부터 분산 트레이싱에 OpenTelemetry를 실험적으로 적용한 후, 긍정적인 효과를 확인하고 본격적으로 OTel로의 전환을 추진했습니다 (Why and How eBay Pivoted to OpenTelemetry). 구체적으로, 서비스 코드에는 언어별 OpenTelemetry SDK로 계측(주로 Java, Go, JavaScript 애플리케이션에 적용)하고, 데이터 수집 파이프라인에는 OpenTelemetry Collector를 도입했습니다 (Why and How eBay Pivoted to OpenTelemetry) (Adopters | OpenTelemetry). Collector는 Kubernetes 환경에서 데몬셋 형태로 배포하거나, 혹은 한 클러스터당 수십 대의 Collector 인스턴스를 띄워 게이트웨이(집중 수집기) 방식으로 운영했습니다. (예를 들어 eBay는 3000노드 규모의 쿠버네티스 클러스터에서 약 30대의 Collector 인스턴스가 각기 다수의 엔드포인트를 할당받아 스크레이핑하는 방식으로 확장성을 확보했습니다 (Why and How eBay Pivoted to OpenTelemetry).) Metricbeat가 담당하던 Prometheus 엔드포인트 수집 기능을 Collector로 이관하면서 가장 큰 과제는 동적인 설정 변경 문제였는데, 기본 OTel Collector는 런타임 중 구성 갱신이 어렵기 때문입니다 (Why and How eBay Pivoted to OpenTelemetry). eBay 팀은 이를 해결하기 위해 Collector 내에 파일 재로딩 리시버(filereloadreceiver)라는 커스텀 컴포넌트를 개발하여, 신규 서비스 파드가 뜰 때 해당 파드의 수집 파이프라인 설정을 파일로 생성해 Collector가 동적으로 불러들이도록 했습니다 (Why and How eBay Pivoted to OpenTelemetry). 또한 Beats에서 사용하던 각종 기능(예: 메트릭 레이블 정규화, 특정 필드 처리 등)에 대응되는 설정을 OpenTelemetry에서 구현하기 위해 매핑 테이블을 만들고 Collector의 프로세서를 활용하는 등 기능 호환성을 확보했습니다 (Why and How eBay Pivoted to OpenTelemetry). 이러한 준비 작업을 거쳐 Metricbeat 에이전트를 무중단으로 OTel Collector로 교체하는 데 성공했고, 현재는 동일한 방식으로 Filebeat 기반의 로그 수집도 OpenTelemetry로 옮기는 작업을 진행하고 있습니다 (A Look at eBay's Implementation of OpenTelemetry - Resources - Telemetryhub).

데이터 백엔드 연계: eBay Observability 플랫폼의 메트릭 저장소는 내부 개발한 분산 Prometheus 기반 스토리지(metricstore)로, Collector에서 수집된 메트릭 데이터를 이 스토리지에 적재합니다 (Why and How eBay Pivoted to OpenTelemetry). 애플리케이션들은 Prometheus 포맷으로 메트릭을 노출하거나 OpenTelemetry SDK로 계측되어 OTLP 형식으로 Collector에 데이터를 보내며, Collector는 이를 Prometheus Remote Write 등을 통해 metricstore에 보냅니다. 트레이싱의 경우 eBay는 OpenTelemetry 도입 초기에 OTLP 프로토콜로 수집된 스팬 데이터를 자사 플랫폼 Sherlock에 통합했습니다. Sherlock은 Jaeger와 유사한 분산 추적 백엔드를 구성하여 서비스 간 호출 관계와 지연 시간을 시각화하고 분석할 수 있게 했습니다. (eBay는具 추적 데이터를 저장하기 위해 Jaeger 등을 활용했다고 알려져 있으며, OTel Collector를 통해 수집한 스팬을 Jaeger API로 전송하거나, OTLP를 지원하는 백엔드로 내보내고 있습니다.) 로그의 경우에도 최종적으로는 ElasticSearch 기반 저장소로 연계하거나, OpenTelemetry Collector로 수집한 후 필요한 곳으로 보내는 구성을 검토 중입니다 (A Look at eBay's Implementation of OpenTelemetry - Resources - Telemetryhub). 요약하면 메트릭은 Prometheus 호환 스토리지, 트레이스는 Jaeger 호환 분산 트레이싱 시스템, 로그는 Elastic 스택으로 연결하는 형태로, OpenTelemetry Collector가 중앙 허브 역할을 수행하고 있습니다.

아키텍처와 규모: eBay의 Observability 아키텍처는 수천 개의 마이크로서비스와 수만 개의 컨테이너로부터 멀티 시그널(메트릭/로그/트레이스) 데이터를 수집하도록 설계되어 있습니다. 앞서 언급했듯 메트릭 부문에서는 매 분당 150만 엔드포인트, 초당 4천만 메트릭 샘플이라는 거의 행성급(planet-scale) 규모로 운영 중이며 (Why and How eBay Pivoted to OpenTelemetry), 트레이스의 경우 구체적인 수치를 공개하지는 않았지만 수백만 QPS에 달하는 사용자 트래픽을 처리하는 서비스들의 분산 호출 경로 전수 추적을 목표로 하고 있습니다. Kubernetes 기반 마이크로서비스 환경에서 수집 에이전트(Collector)는 각 노드별 혹은 클러스터별로 수평 확장되며, 앞서 설명한 동적 구성 로딩 기법으로 신규 서비스 인스턴스의 메트릭 엔드포인트를 실시간으로 수집에 포함시킵니다 (Why and How eBay Pivoted to OpenTelemetry). 이러한 체계 덕분에 eBay는 약 3억 개의 메트릭 시계열이 저장된 거대한 모니터링 환경에서도 OpenTelemetry Collector의 파이프라인 구성만 변경하여 새로운 서비스나 지표를 쉽게 추가/관리할 수 있게 되었습니다. 또한 eBay는 OpenTelemetry 도입 과정에서 발견된 문제들에 대해 적극적으로 커뮤니티에 패치 기여를 했는데, 예를 들어 레이블 명 처리 등 Beats 대비 OTel의 미비점들을 수정하여 upstream에 반영함으로써 eBay만 아니라 모든 OTel 사용자들이 혜택을 볼 수 있도록 하였습니다 (Why and How eBay Pivoted to OpenTelemetry).

운영 성과와 문제 해결: eBay는 OpenTelemetry 도입으로 분산 시스템 문제에 대한 가시성 향상이라는 큰 이점을 얻었습니다. 과거에는 서비스별로 흩어진 로그, 메트릭, 추적 정보를 정신없이 뒤져야 했던 반면, OTel 기반 통합 트레이스를 통해 사용자 요청이 거치는 모든 서비스를 한눈에 따라가며 성능 병목이나 오류 지점을 즉각 파악할 수 있게 되었습니다 (A Look at eBay's Implementation of OpenTelemetry - Resources - Telemetryhub). 이는 곧 장애로 인한 매출 손실을 줄이고 문제해결 시간을 단축하는 효과로 이어졌습니다 (A Look at eBay's Implementation of OpenTelemetry - Resources - Telemetryhub). 또한 OTel의 표준화된 SDK 덕분에 개발자들이 각자 서비스에 모니터링 코드를 일일이 작성할 필요 없이 공통 라이브러리를 활용하여 손쉽게 계측을 적용할 수 있었고, 만약 향후 Observability 백엔드를 변경하더라도 애플리케이션 코드를 수정하지 않고 Collector 설정만 변경하여 유연하게 대처할 수 있는 기반을 마련했습니다 (Why (and how) GitHub is adopting OpenTelemetry - The GitHub Blog). 물론 전환 과정에서 어려움도 있었습니다. Collector가 Beats의 모든 기능을 바로 대체하지는 못했기 때문에 앞서 언급한 동적 설정 로딩 문제나 지표명/레이블 체계 차이로 인한 데이터 불일치 등의 이슈가 발생했고, 첫 시도에서는 신규 Collector로 교체 후 일부 메트릭 누락 문제가 발견되어 롤백하는 해프닝도 있었습니다 (Why and How eBay Pivoted to OpenTelemetry). eBay는 이를 해결하기 위해 Metricbeat와 OTel Collector의 수집 결과를 비교 검증하는 도구를 만들어 데이터를 검증하고, 부족한 기능은 Collector에 직접 기여하면서 개선함으로써 결국 프로덕션 환경에 안정적으로 정착시킬 수 있었습니다 (Why and How eBay Pivoted to OpenTelemetry). eBay 사례에서 볼 수 있듯이, OpenTelemetry 도입은 대규모 모니터링의 표준화와 효율화를 가져왔으며, eBay는 얻어진 통찰을 바탕으로 향후에도 새로운 Observability 요구사항이 생길 때마다 유연하게 대응해나갈 계획입니다 (A Look at eBay's Implementation of OpenTelemetry - Resources - Telemetryhub).

Shopify의 OpenTelemetry 도입

도입 배경: Shopify는 전 세계 수백만 상점을 지원하는 커머스 플랫폼으로서, 폭증하는 트래픽과 데이터 규모를 감당할 수 있는 Observability 시스템이 필수적이었습니다. 한때 사용하던 상용 모니터링 솔루션은 트래픽 증가에 따라 연 수천만 달러에 달하는 비용이 예상되었고, SaaS 제품의 한계로 인해 성능과 운영상의 제약도 발생하고 있었습니다 (Shopify’s Journey to Planet-Scale Observability | by Dotan Horovits (@horovits) | Feb, 2025 | Medium) (Shopify’s Journey to Planet-Scale Observability | by Dotan Horovits (@horovits) | Feb, 2025 | Medium). Elijah McPherson 등 Shopify 엔지니어링 리더십은 “우리 규모에 기성 제품으로는 신뢰성, 성능, 비용 요구사항을 충족시킬 수 없었고 데이터에 대한 완전한 통제도 어려웠다”라고 밝히며 (Shopify’s Journey to Planet-Scale Observability | by Dotan Horovits (@horovits) | Feb, 2025 | Medium), 직접 Observability 스택을 구축하기로 결정했습니다. 즉, 비용 절감(자체 구축으로 저장소 비용 80% 이상 절약 (Shopify’s Journey to Planet-Scale Observability | by Dotan Horovits (@horovits) | Feb, 2025 | Medium))과 성능 향상, 데이터 주권 확보(베ンダ 종속 탈피)를 OpenTelemetry 등 오픈소스 표준 도입으로 이루고자 한 것입니다. 또한 기존 상용 APM 에이전트가 고트래픽 서비스에서 CPU 사용량의 15~20%에 달하는 부하를 초래한다는 분석도 나와, 경량화된 OpenTelemetry로 교체하여 이러한 오버헤드 제거를 노렸습니다 (Shopify’s Journey to Planet-Scale Observability | by Dotan Horovits (@horovits) | Feb, 2025 | Medium).

구현 방식: Shopify는 코드명 Observe라는 내부 Observability 플랫폼을 구축하며 OpenTelemetry를 핵심 구성요소로 활용했습니다 (Shopify’s Journey to Planet-Scale Observability | by Dotan Horovits (@horovits) | Feb, 2025 | Medium). 전체 스택은 100% 오픈소스 도구들로 조합되었는데, 메트릭 수집에는 기존에 개발자들에게 친숙한 StatsD 프로토콜과 Prometheus(OpenMetrics) 표준을 따르고, 로그 수집에는 Loki와 자체 개발한 Logging API/파이프라인(Vector + ClickHouse 기반)을 사용했으며, 분산 트레이싱에는 Grafana Tempo를 도입했습니다 (Shopify’s Journey to Planet-Scale Observability | by Dotan Horovits (@horovits) | Feb, 2025 | Medium) (Shopify’s Journey to Planet-Scale Observability | by Dotan Horovits (@horovits) | Feb, 2025 | Medium). OpenTelemetry는 이 중 트레이싱 파이프라인의 계측 표준으로서 핵심 역할을 합니다. Shopify는 다양한 서비스(대부분 Ruby on Rails 기반 모놀리식 앱과 다수의 Go 기반 마이크로서비스)에서 OpenTelemetry SDK로 자동/수동 계측을 적용했고, 기존 상용 APM 에이전트를 제거하여 OTel SDK + Collector 조합으로 교체했습니다 (Shopify’s Journey to Planet-Scale Observability | by Dotan Horovits (@horovits) | Feb, 2025 | Medium) (Shopify’s Journey to Planet-Scale Observability | by Dotan Horovits (@horovits) | Feb, 2025 | Medium). 예를 들어 Rails 애플리케이션에는 ruby용 OpenTelemetry 자동계측 라이브러리를 활용해 데이터베이스 쿼리, HTTP 요청 등의 스팬을 자동으로 생성하도록 했습니다. 메트릭은 애플리케이션이 StatsD나 Prometheus 형식으로 지표를 노출하면, OTel Collector가 StatsD/Prometheus 수신 기능을 통해 수집하여 Prometheus 및 장기 저장소로 넘기는 방식을 취했습니다. Shopify는 특히 오픈 표준(OpenMetrics 등)에 철저히 맞춰 개발함으로써 서비스 간 데이터 호환성을 확보하고, Prometheus나 Grafana 등에 플러그앤플레이로 연결되도록 설계했습니다 (Shopify’s Journey to Planet-Scale Observability | by Dotan Horovits (@horovits) | Feb, 2025 | Medium) (Shopify’s Journey to Planet-Scale Observability | by Dotan Horovits (@horovits) | Feb, 2025 | Medium).

Collector의 배포는 SaaS 벤더 에이전트 대신 호스트 에이전트 또는 사이드카/데몬셋 형태로 이루어졌고, 수집한 텔레메트리 데이터를 적절한 백엔드로 내보내도록 구성되었습니다. 이러한 듀얼 라이팅(dual-write) 전략 – 초기에는 기존 벤더 시스템과 새로운 OTel 기반 시스템을 병렬로 운영하여 데이터 차이를 모니터링 – 을 통해 점진적으로 안전한 전환을 진행하였습니다 (Shopify’s Journey to Planet-Scale Observability | by Dotan Horovits (@horovits) | Feb, 2025 | Medium). 한편, Shopify 플랫폼 팀은 단순히 기술 도구만 제공한 것이 아니라, 내부 개발자 경험을 제품화한다는 기조 하에 엔지니어들을 위한 편의 기능을 다수 개발했습니다. 예를 들어, 자연어 기반의 쿼리 도우미를 만들어 Grafana에서 PromQL이나 LogQL을 작성할 때 common pattern을 자동 추천함으로써 엔지니어들의 쿼리 작성 시간을 30~40% 단축시켰습니다 (Shopify’s Journey to Planet-Scale Observability | by Dotan Horovits (@horovits) | Feb, 2025 | Medium). 또한 OTel로 수집된 트레이스와 메트릭을 결합해 자동 종속성 맵을 생성, 어떤 서비스 장애가 어떤 하위 서비스의 문제로 이어졌는지 즉각 파악할 수 있게 함으로써 평균 장애 대응 시간을 크게 줄였습니다 (Shopify’s Journey to Planet-Scale Observability | by Dotan Horovits (@horovits) | Feb, 2025 | Medium). 이러한 기능들은 모두 OpenTelemetry로부터 얻은 풍부한 데이터 덕분에 가능해진 것입니다.

데이터 백엔드 연계: Shopify Observability 스택의 백엔드 구성은 메트릭과 트레이스를 장기 저장하고 조회할 수 있는 분산 저장소 계층과 시각화/알림 계층으로 나뉩니다. 메트릭은 우선 Prometheus로 수집되어 실시간 모니터링에 사용되고, 장기간의 메트릭 보존과 대규모 쿼리를 위해 Thanos + Parquet + GCS(Google Cloud Storage) 기반의 저장소로 내려보내집니다 (Shopify’s Journey to Planet-Scale Observability | by Dotan Horovits (@horovits) | Feb, 2025 | Medium). 트레이싱 데이터는 Grafana Tempo에 OTLP로 저장되며, Tempo는 대규모 추적 데이터를 저비용으로 보관하기 위해 객체 저장소와 Cassandra 등을 활용합니다. OpenTelemetry Collector는 애플리케이션으로부터 받은 OTLP 트레이스 데이터를 Tempo로 내보내거나, 일시적으로 Kafka 버퍼링을 거친 뒤 Tempo에 적재하는 방식으로 구축되었습니다. 로그의 경우 Grafana Loki를 기본 로그 검색 엔진으로 사용하되, 40TB/일에 달하는 방대한 로그를 효율적으로 보관하기 위해 Vector(로그 수집기)로 받아 ClickHouse에 적재하고 자체 API로 검색하는 하이브리드 방식을 채택했습니다 (Shopify’s Journey to Planet-Scale Observability | by Dotan Horovits (@horovits) | Feb, 2025 | Medium) (Shopify’s Journey to Planet-Scale Observability | by Dotan Horovits (@horovits) | Feb, 2025 | Medium). 모든 데이터는 Grafana 대시보드를 통해 일원화된 UI로 노출되어, 개발자가 한 화면에서 서비스의 메트릭, 로그, 트레이스를 연계 분석할 수 있습니다 (Shopify’s Journey to Planet-Scale Observability | by Dotan Horovits (@horovits) | Feb, 2025 | Medium). 요약하면 메트릭은 Prometheus/Thanos, 로그는 Loki/ClickHouse, 트레이스는 Tempo로 구성되며, OpenTelemetry Collector가 애플리케이션 계층과 이러한 백엔드들을 연결하는 허브로 기능합니다.

아키텍처와 규모: Shopify의 마이크로서비스 아키텍처와 인프라는 행성 규모(planet-scale)로 비유될 만큼 방대합니다. 수천 개에 달하는 서비스와 수백만 개의 앱 인스턴스/컨테이너에서 매 초 수백만 건의 이벤트가 발생하며 (Shopify’s Journey to Planet-Scale Observability | by Dotan Horovits (@horovits) | Feb, 2025 | Medium), 한꺼번에 쏟아지는 피크 트래픽을 처리해야 합니다. Observe 플랫폼 도입 이전에는 이러한 데이터를 외부 APM 서비스에 의존했지만, OTel 기반 신규 플랫폼에서는 완전한 수직 통합을 이뤘습니다. 모든 서비스에 OTel SDK로 계측을 심고, 수집된 데이터는 중앙의 Collector들을 거쳐 앞서 언급한 저장소로 흘러갑니다. Shopify는 특히 모놀리식 구조로 거대한 Rails 코어 애플리케이션을 가지고 있는데, 이 부분에도 OpenTelemetry를 적용하여 단일 애플리케이션 내부의 분산 추적도 가능하게 했습니다. Observability 플랫폼의 규모를 나타내는 지표로, Shopify는 이전 벤더 솔루션을 대체하면서 스토리지 비용을 80% 이상 절감하고 조회 성능을 개선했다고 밝히고 있으며 (Shopify’s Journey to Planet-Scale Observability | by Dotan Horovits (@horovits) | Feb, 2025 | Medium), OTel 도입으로 고부하 서비스의 CPU 오버헤드 15~20% 감소 등의 성능 향상도 이루었습니다 (Shopify’s Journey to Planet-Scale Observability | by Dotan Horovits (@horovits) | Feb, 2025 | Medium). 또한 네트워크 레벨에서는 eBPF 기반 모니터링으로 초당 수백만 건의 이벤트를 수집하고 이를 OTel 파이프라인으로 처리하는 등 (Shopify’s Journey to Planet-Scale Observability | by Dotan Horovits (@horovits) | Feb, 2025 | Medium), 인프라 영역까지 Observability 범위를 넓혔습니다.

운영상의 이점 및 문제 해결: Shopify는 OpenTelemetry 중심의 자체 Observability 플랫폼을 구축한 이후 다방면에서 큰 개선 효과를 얻었습니다. 첫째, 비용 절감 측면에서 앞서 언급한 것처럼 상용 서비스 이용 대비 연간 수천만 달러에 달하는 지출을 아끼게 되었고, 데이터 저장도 자체 최적화를 통해 효율화하였습니다 (Shopify’s Journey to Planet-Scale Observability | by Dotan Horovits (@horovits) | Feb, 2025 | Medium). 둘째, 성능 및 안정성 측면에서, 가벼운 OTel 에이전트로 교체한 덕분에 애플리케이션의 모니터링 부하가 줄어들었고 (1520%의 CPU 여유 확보 ([Shopify’s Journey to Planet-Scale Observability | by Dotan Horovits (@horovits) | Feb, 2025 | Medium](https://horovits.medium.com/shopifys-journey-to-planet-scale-observability-9c0b299a04dd#::text=By%20moving%20to%20OpenTelemetry%2C%20Shopify,throughput%20services))), Observability 인프라 자체도 Shopify의 요구에 맞춰 최적화되었기 때문에 대용량 쿼리도 빠르게 처리하는 등 엔드투엔드 성능 개선이 있었습니다. 셋째, 데이터 통합과 활용성 측면에서, 이제 개발자들은 한 가지 표준(OpenTelemetry)으로 계측된 메트릭, 로그, 트레이스, 프로파일링 데이터를 한 곳에서 조회하며 상호 연관짓게 되었습니다 (Shopify’s Journey to Planet-Scale Observability | by Dotan Horovits (@horovits) | Feb, 2025 | Medium). 이를 통해 예전에는 별개 도구로 보던 정보들을 단일 컨텍스트에서 분석함으로써, 예컨대 “어떤 서비스 응답 지연이 발생할 때 동시에 비즈니스 지표(구매 전환율 등)는 어떻게 변하는가”를 즉시 파악할 수 있게 되었습니다 (Shopify’s Journey to Planet-Scale Observability | by Dotan Horovits (@horovits) | Feb, 2025 | Medium). 실제로 Shopify는 트레이스와 비즈니스 지표(예: 체크아웃 포기율)를 대시보드에서 겹쳐 보여주는 기능을 도입하여, 성능 문제로 인한 매출 영향도를 실시간 평가하고 우선순위로 해결함으로써 잠재적으로 수백만 달러의 수익 손실을 예방할 수 있었다고 합니다 (Shopify’s Journey to Planet-Scale Observability | by Dotan Horovits (@horovits) | Feb, 2025 | Medium). 넷째, 운영 프로세스 적합성 측면에서, Observe 플랫폼은 Shopify 내부의 incident response 워크플로우와 긴밀히 통합되어 경보→대응→해결에 이르는 과정이 최적화되었습니다 (Shopify’s Journey to Planet-Scale Observability | by Dotan Horovits (@horovits) | Feb, 2025 | Medium). 자동화된 서비스 종속성 지도는 장애 시 원인 서비스를 신속히 지목해주어 평균 복구 시간(MTTR)을 단축시켰고 (Shopify’s Journey to Planet-Scale Observability | by Dotan Horovits (@horovits) | Feb, 2025 | Medium), 또 개발자 친화적인 UI/도구(앞서 언급한 자연어 쿼리 보조 등)를 통해 플랫폼에 대한 내부 엔지니어들의 만족도와 활용률을 크게 높였습니다 (Shopify’s Journey to Planet-Scale Observability | by Dotan Horovits (@horovits) | Feb, 2025 | Medium).

Shopify도 시행착오는 있었습니다. 라이브 프로덕션 환경을 새로운 Observability 시스템으로 갈아엎는 위험을 줄이기 위해, 한동안 구 시스템과 신 시스템을 함께 운영하며 데이터 검증(duAL-write)을 했고 그 과정에서 몇 가지 지표 불일치 문제가 발견되어 조정하였습니다 (Shopify’s Journey to Planet-Scale Observability | by Dotan Horovits (@horovits) | Feb, 2025 | Medium). 또한 플랫폼을 구축하는 막대한 노력(“모든 회사가 우리처럼 할 필요는 없다. Shopify 규모이기에 직접 구축이 의미가 있었다”는 언급 (Shopify’s Journey to Planet-Scale Observability | by Dotan Horovits (@horovits) | Feb, 2025 | Medium))과 내부 사용자들의 학습曲선도 존재했습니다. 이를 위해 플랫폼팀은 내부 교육 세션과 문서화를 추진하고, 각 팀으로부터 지속적인 피드백을 받아 기능을 개선하는 제품 관리 접근을 취했습니다 (Shopify’s Journey to Planet-Scale Observability | by Dotan Horovits (@horovits) | Feb, 2025 | Medium). 그 결과 현재 Shopify 엔지니어들은 Observability 플랫폼을 신뢰하고 적극 활용하게 되었으며, “이 플랫폼 덕분에 문제를 알 수 없었던 영역까지 탐색하게 되었다”는 평가를 받고 있습니다. 결론적으로, Shopify는 OpenTelemetry와 오픈소스 도구들로 자사에 최적화된 Observability 생태계를 구축함으로써 비용, 성능, 데이터 활용 면에서 큰 성공을 거두었고, 이러한 경험을 커뮤니티에도 공유하며 지속적으로 개선을 이어가고 있습니다.

GitHub의 OpenTelemetry 도입

도입 배경: GitHub는 전 세계 개발자들이 사용하는 거대한 플랫폼으로, 서비스 안정성과 성능을 위해 다양한 관측 기법을 발전시켜 왔습니다. 과거 GitHub 엔지니어들은 StatsD(메트릭), Syslog(텍스트 로그), OpenTracing(분산 트레이싱) 등 여러 도구와 포맷을 병용하여 시스템 상태를 모니터링해 왔습니다 (Why (and how) GitHub is adopting OpenTelemetry - The GitHub Blog). 그러나 서비스가 늘어날수록(모놀리식 레일즈 애플리케이션부터 수많은 보조 마이크로서비스까지) 각 시스템마다 조금씩 다른 방식으로 계측되어 있었고, 예를 들어 서비스별로 StatsD 구현체 방언이 달라 코드마다 계측 로직을 특별 처리해야 하는 등 비효율이 발생했습니다 (Why (and how) GitHub is adopting OpenTelemetry - The GitHub Blog). 또한 메트릭, 로그, 트레이스 등이 서로 연계가 잘 되지 않아 하나의 사용자 요청을 따라가며 문제를 진단하기가 어려웠습니다 (Why (and how) GitHub is adopting OpenTelemetry - The GitHub Blog). GitHub 내부에서도 “텔레메트리 데이터를 많이 수집하지만 실제 문제 해결에 활용하기엔 어렵다”는 인식이 있었고 (Why (and how) GitHub is adopting OpenTelemetry - The GitHub Blog), 이를 해결하기 위해 조직 전반에 걸친 계측 표준화와 개발자가 손쉽게 사용할 수 있는 도구가 필요하다는 결론에 이르렀습니다 (Why (and how) GitHub is adopting OpenTelemetry - The GitHub Blog). 마침 CNCF에서 주도하던 OpenTelemetry 프로젝트가 이러한 요구에 부합했고, GitHub는 2021년경 OTel 도입을 결정하여 표준화 작업을 시작했습니다 (Why (and how) GitHub is adopting OpenTelemetry - The GitHub Blog).

구현 방식: GitHub는 OpenTelemetry 도입에 있어 점진적 접근을 취했습니다. 우선 당장 효과를 볼 수 있는 분야로 분산 트레이싱을 선택하여, 새로운 표준 하에 트레이스를 수집·활용하는 데 집중했습니다 (Why (and how) GitHub is adopting OpenTelemetry - The GitHub Blog). GitHub의 주요 애플리케이션은 Ruby on Rails 기반으로, GitHub 팀은 Ruby용 OpenTelemetry SDK를 통해 자동 계측과 수동 계측을 조합하여 애플리케이션에 트레이싱을 넣었습니다. 내부적으로 개발된 OTel 헬퍼 라이브러리를 사용하여 개발자들이 최소한의 설정만으로도 서비스에 트레이싱을 추가할 수 있게 했는데, 예를 들어 해당 라이브러리는 테스트 환경에서는 트레이싱을 비활성화하여 불필요한 부하를 막고, 운영 환경에서는 적절한 Batch Span Processor 설정을 자동 적용하는 등의 편의를 제공합니다 (Why (and how) GitHub is adopting OpenTelemetry - The GitHub Blog). 또한 Rails, PostgreSQL, Redis, HTTP 클라이언트 등 일반적으로 사용되는 라이브러리에 대해 OpenTelemetry 계측 어댑터(Instrumentation)를 활용하여, 코드 수정 없이도 자동으로 스팬이 생성되도록 구성했습니다 (Why (and how) GitHub is adopting OpenTelemetry - The GitHub Blog) (Why (and how) GitHub is adopting OpenTelemetry - The GitHub Blog). 예컨대 Rails 애플리케이션에서는 OpenTelemetry::Instrumentation::Rails, PG, ActiveJob, Net::HTTP 등의 자동계측 패키지를 use함으로써, 웹 요청부터 DB 쿼리, 외부 API 호출까지 투명하게 추적할 수 있었고 이는 곧바로 성능 병목 구간을 찾아내는 데 기여했습니다 (Why (and how) GitHub is adopting OpenTelemetry - The GitHub Blog). 이런 초기 트레이싱 도입을 통해 GitHub는 서비스 호출 흐름을 시각화하고 문제를 진단하는 새로운 능력을 얻었고, 개발자들이 Observability의 가치를 체감하도록 만들었습니다. 이후 GitHub는 OpenTelemetry의 다른 신호들(로그, 메트릭)로도 범위를 넓혀 모든 텔레메트리 신호에 통합 표준을 적용하는 장기 로드맵을 그리고 있습니다 (Why (and how) GitHub is adopting OpenTelemetry - The GitHub Blog). 이를 위해 로그 라인에 트레이스ID를 자동으로 삽입하여 로그-트레이스 연결을 가능케 하고, 트레이스로부터 자동으로 중요 메트릭을 집계하는 기능 등을 개발 중입니다 (Why (and how) GitHub is adopting OpenTelemetry - The GitHub Blog).

데이터 백엔드 연계: GitHub는 OpenTelemetry 도입 시 벤더 중립성을 중요한 목표로 삼았습니다. OTel이 정의한 OTLP(OpenTelemetry Protocol)을 통해 수집된 데이터는 어떤 백엔드든 보낼 수 있으므로 (Why (and how) GitHub is adopting OpenTelemetry - The GitHub Blog), GitHub는 특정 상용 솔루션에 종속되지 않고 필요에 따라 내부 구축 또는 외부 서비스를 선택할 수 있는 유연성을 확보했습니다. 현재 GitHub의 모니터링 인프라는 상당 부분 자체 호스팅되어 있는데, 메트릭은 StatsD로 수집된 데이터를 Graphite/InfluxDB 등으로 저장하고 Grafana로 시각화해왔으며, 로그는 내부 로그 집계 시스템(예: ELK 스택)과 오류 추적 시스템(Sentry 등)에 보내는 구조가 혼재되어 있습니다. OpenTelemetry 도입 후에는 이 분산된 데이터 흐름을 점차 단일 OTLP 파이프라인으로 합쳐나가고 있습니다. OpenTelemetry Collector를 도입하여 애플리케이션에서 방출된 OTLP 데이터를 수집하고, 이를 기존 시스템(예: Prometheus, Elasticsearch)으로 변환 출력하거나 향후 도입할 새로운 Observability SaaS에 OTLP로 전송하는 등 허브로 활용하고 있습니다. 예를 들어 GitHub는 과거 OpenTracing으로 수집한 트레이스를 Lightstep에 전송한 바 있고, 메트릭은 Datadog을 사용한 팀도 있었지만, OTel 도입 이후로는 Collector 설정만 바꾸면 이러한 백엔드들을 쉽게 교체하거나 병렬로 사용할 수 있게 되었습니다 (Why (and how) GitHub is adopting OpenTelemetry - The GitHub Blog). 요약하면 GitHub의 데이터 파이프라인은 점차 OTel로 단일화되고 있으며, OTLP를 지원하는 어떤 백엔드와도 연계될 수 있는 개방형 구조로 재편되고 있습니다 (Why (and how) GitHub is adopting OpenTelemetry - The GitHub Blog).

아키텍처와 규모: GitHub의 서비스 아키텍처는 대형 Rails 기반 모놀리식 애플리케이션(웹 요청 처리 등 핵심 기능 담당)과, 이를 보조하는 다수의 마이크로서비스(검색, 데이터 처리, 액션 실행 등)들로 구성되어 있습니다. 전체 시스템이 방대하고 복잡하다 보니, 이전에는 각 컴포넌트가 서로 다른 방식으로 모니터링되어 운영 도구의 파편화가 심했습니다 (Why (and how) GitHub is adopting OpenTelemetry - The GitHub Blog). OpenTelemetry 도입으로 GitHub는 이러한 환경을 표준화된 계층구조로 바꾸고 있습니다. 언어별(OpenTelemetry Ruby 등) 단일 계측 SDK를 통해 다양한 서비스에서 일관된 텔레메트리 데이터를 생성하고, 이를 중앙 Collector 클러스터가 수집한 후 필요시 데이터 전처리(샘플링, 필터링 등)를 거쳐 저장소로 전달합니다. 현재 GitHub는 수백 대 이상의 애플리케이션 서버에 OTel을 적용했으며, GitHub Actions와 같은 고부하 서비스에도 트레이싱을 확산시키고 있습니다. 수집되는 데이터 규모에 대해 공개된 수치는 없지만, GitHub처럼 전 세계 수천만 사용자가 이용하는 플랫폼에서는 일일 수십억 건 이상의 이벤트(예: 푸시/풀 요청, 웹hook, API 호출 등)가 발생하며, OTel 기반 모니터링 시스템은 이러한 방대한 데이터를 실시간 처리할 수 있도록 수평 확장되고 분산 처리되는 형태로 구축되었습니다. GitHub의 Observability 팀은 OTel Collector를 쿠버네티스 상에 배포하고, 필요한 구성(예: Span Processor나 Exporter 설정)을 인프라 코드로 관리하여 서비스 추가/변경 시 신속히 반영하고 있습니다. 또한 OTel SDK 적용에 따른 애플리케이션 성능 영향을 최소화하기 위해 배치 스팬 처리, 적절한 샘플링 전략을 채택하고, 중요 서비스에 대해서는 trace sampling 비율을 조정하여 데이터량과 가시성 사이의 균형을 맞추고 있습니다.

운영상의 이점 및 극복한 문제: GitHub는 OpenTelemetry를 도입한 주된 효과로 관측 신호들의 표준화와 상호 연관성 향상을 들고 있습니다. 먼저, 조직 공통의 텔레메트리 언어가 생겼습니다. 이제 개발자들은 서비스 코드를 작성할 때 OTel SDK를 사용해 일관된 방식으로 메트릭과 트레이스를 계측하며, 이로써 팀마다 다른 계측 패턴을 쓰던 과거를 청산하고 베스트 프랙티스를 공유할 수 있게 되었습니다 (Why (and how) GitHub is adopting OpenTelemetry - The GitHub Blog). 둘째, 벤더 종속성 감소입니다. OTel로 계측한 데이터는 OTLP라는 개방형 포맷으로 중앙 수집되므로, 향후에 내부 저장소를 쓰든, 새로운 SaaS 모니터링 툴을 쓰든 애플리케이션 코드를 수정할 필요 없이 Collector의 Exporter만 교체하면 됩니다 (Why (and how) GitHub is adopting OpenTelemetry - The GitHub Blog). 이는 GitHub같이 빠르게 진화하는 조직에서 기술 스택 선택의 유연성을 크게 높여주었습니다. 셋째, 분산 시스템 디버깅 능력 향상입니다. OTel 기반 분산 추적(trace)은 마이크로서비스로 구성된 GitHub 인프라에 거의 마법과 같은 투명성을 제공하여, 하나의 사용자 요청이 거치는 서비스를 모두 시간순으로 보여줌으로써 성능 병목이나 오류를 즉각 밝혀냅니다 (Why (and how) GitHub is adopting OpenTelemetry - The GitHub Blog). GitHub는 이를 토대로 자동으로 서비스별 지연 메트릭을 산출하거나 예외 발생시 트레이스와 오류 추적 연계를 하는 등 2차 활용도 모색 중입니다 (Why (and how) GitHub is adopting OpenTelemetry - The GitHub Blog). 넷째, 운영 편의성입니다. 내부 OTel 헬퍼 라이브러리와 자동계측의 도입으로 개발자들은 몇 줄의 설정만으로 자신의 서비스에 관측 기능을 심을 수 있게 되었고, 테스트 환경에서는 계측이 자동으로 꺼지므로 테스트 오염 없이 안전하게 적용할 수 있습니다. 실제 한 개발자는 “몇 가지 c.use 설정을 추가하는 것만으로도 레일즈 앱의 DB 쿼리와 외부 호출에 대한 유용한 트레이스 정보를 바로 얻었다”고 말할 정도로, 낮은 진입장벽으로 높은 가치를 얻고 있습니다 (Why (and how) GitHub is adopting OpenTelemetry - The GitHub Blog). 다섯째, 종합 관찰 능력입니다. GitHub는 현재 트레이스를 관찰의 출발점으로 삼고 여기에 로그와 메트릭을 연결하는 노력을 기울이고 있습니다 (Why (and how) GitHub is adopting OpenTelemetry - The GitHub Blog) (Why (and how) GitHub is adopting OpenTelemetry - The GitHub Blog). 이미 애플리케이션 로그에 트레이스 ID를 자동 첨부함으로써 “특정 요청에서 발생한 로그를 한 번에 모아보기”가 가능해졌고 (Why (and how) GitHub is adopting OpenTelemetry - The GitHub Blog), 경고 알림이나 대시보드에서도 트레이스-메트릭-로그를 연계 링크로 손쉽게 넘나들며 문제를 분석할 수 있게 되었습니다.

물론 GitHub의 여정에도 과제가 있었습니다. 전사적 표준을 수립하는 일은 기술적인 측면보다 문화적인 측면에서 도전이 컸는데, 이를 위해 팀은 OTel의 이점을 사내에 적극 홍보하고, 각 프로젝트에 자동계측 기본셋을 제공하여 개발자들이 쉽게 따라오도록 장려했습니다 (Why (and how) GitHub is adopting OpenTelemetry - The GitHub Blog) (Why (and how) GitHub is adopting OpenTelemetry - The GitHub Blog). 또한 몇몇 레거시 시스템(특히 Git 데이터 전송 등의 낮은 레벨 서비스)은 기존 방식으로 계속 운영하면서, 새로운 서비스부터 OTel을 적용하는 점진적 도입 전략을 택해 무리한 한방 전환을 피했습니다. GitHub 엔지니어들은 OpenTelemetry 프로젝트 자체에도 다수의 개선사항을 기여하며 필요한 기능과 성능 개선을 함께 이루고 있는데 (Why (and how) GitHub is adopting OpenTelemetry - The GitHub Blog), 이러한 커뮤니티 참여는 문제 발생 시 직접 해결책을 만들어낼 수 있다는 점에서도 긍정적입니다. 전반적으로 GitHub는 OpenTelemetry 도입을 통해 개발자 경험의 일관성 증진, 관측 데이터 활용도 향상, 문제 해결 시간 단축이라는 성과를 거두고 있습니다. 아직 진행 중인 여정이지만, GitHub 사례는 대규모 플랫폼에서 텔레메트리 표준화가 왜 중요한지 잘 보여주며, 향후 점차 모든 신호(logs, metrics)로 OpenTelemetry를 확대 적용할 예정입니다.

Skyscanner의 OpenTelemetry 도입

도입 배경: Skyscanner는 전 세계 다양한 항공사, 호텔 등의 데이터를 수집해 사용자에게 제공하는 여행 메타검색 플랫폼입니다. 수백 개에 이르는 외부 파트너 API와 내부 서비스가 복잡하게 얽혀 있는 분산 시스템 특성상, 한 부분에 장애나 지연이 생기면 그 파급 효과를 파악하기 어려웠고, 전통적인 런북(runbook) 기반 대응만으로는 충분하지 않았습니다 (Skyscanner observability game days). 스카이스캐너 팀은 “모든 장애 상황을 사전에 정의할 수 없다”는 문제의식을 갖고, 각종 알 수 없는(unknown) 오류를 탐지하고 원인을 추적하기 위해서는 보다 일반적인 접근법, 즉 관찰가능성(Observability) 확보가 필요하다고 판단했습니다 (Skyscanner observability game days) (Making observability fun: How we increased engineers' confidence in incident management using a game | OpenTelemetry). 과거에는 문제 발생 시 한정된 패턴의 수동 대응에 의존했지만, 이제는 시스템 내부에서 실제 무슨 일이 일어나는지 탐색할 수 있어야 했습니다 (Skyscanner observability game days). 이를 위해 Skyscanner는 OpenTelemetry 도입을 핵심 전략으로 삼았습니다 (Skyscanner observability game days). OTel은 메트릭, 로그, 트레이스 등 다양한 신호를 하나의 표준으로 취급할 수 있게 해주며, Skyscanner처럼 마이크로서비스가 수백 개(정보에 따르면 수백 개 서비스에 OTel을 적용하는 대규모 이니셔티브를 진행)인 조직에서 통합된 계측 체계를 구축하기에 적합했습니다 (Effective and Efficient Observability with OpenTelemetry - InfoQ). 또한 OpenTelemetry를 통해 벤더 중립적인 데이터 포맷을 얻게 됨으로써, 내부적으로 데이터를 가공하거나 타사 Observability 플랫폼에 보내는 등 유연한 선택지를 확보하고자 했습니다 (Skyscanner observability game days).

구현 방식: Skyscanner는 수년간 축적된 자체 모니터링 솔루션들을 OpenTelemetry로 재구성하는 전환 작업을 추진했습니다. 여러 언어(Python, Java, JavaScript, Go 등)로 작성된 마이크로서비스에 일괄적으로 OpenTelemetry SDK를 적용하여 분산 추적과 메트릭 계측을 표준화했습니다 (Adopters | OpenTelemetry) (Adopters | OpenTelemetry). 예컨대 Python 서비스들은 OTel Python SDK와 Django/Flask용 자동계측을 붙였고, Java 서비스들은 OpenTelemetry Java Agent를 통해 별도 코드 수정 없이 트레이스를 내보내도록 설정했습니다. 데이터를 받아들이는 측면에서는 OpenTelemetry Collector를 에이전트 + 게이트웨이 하이브리드 방식으로 활용했는데, 각 애플리케이션 인스턴스나 노드에 경량 Collector를 배치하여 애플리케이션으로부터 OTLP 데이터를 수집하고, 중앙에 위치한 고성능 Collector 게이트웨이가 이를 취합하여 백엔드로 전송하도록 구성했습니다. Skyscanner가 선택한 Observability 백엔드는 New Relic이었는데, New Relic이 OTLP 프로토콜을 네이티브 지원하기 때문에 Collector의 OTLP Exporter를 New Relic 인게스트 엔드포인트로 향하게 하는 것만으로 손쉽게 연동할 수 있었습니다 (Skyscanner observability game days) (Making observability fun: How we increased engineers' confidence in incident management using a game | OpenTelemetry). 다시 말해 Collector → New Relic으로 이어지는 데이터 파이프라인을 구축한 것입니다. OTel Collector를 사용함으로써 얻은 부가이점은 유연한 데이터 처리인데, Skyscanner는 Collector 단계에서 고급 샘플링을 적용하여 중요하지 않은 트레이스를 버리거나 메트릭 해상도를 낮추는 등의 작업으로 데이터 볼륨을 조절했습니다 (Skyscanner observability game days). 이는 대규모 트래픽 환경에서 비용을 최적화하고, 중요한 신호에 집중할 수 있도록 한 운영상의 선택입니다.

데이터 백엔드 연계: 앞서 언급했듯 Skyscanner는 New Relic One 플랫폼을 Observability 백엔드로 사용합니다. 모든 서비스에서 수집된 메트릭, 트레이스, 로그 데이터는 최종적으로 New Relic에 모이게 되며, 개발자들은 New Relic의 UI를 통해 대시보드, 차트, 트레이스 뷰 등을 활용합니다. OpenTelemetry 도입 전에는 Skyscanner 내부에 12개에 달하는 서로 다른 모니터링 도구(팀별로 Prometheus, CloudWatch, ELK, Jaeger 등 다양한 툴을 병용)들이 존재했으나, OTel 표준으로 계측을 통합한 후 New Relic으로 일원화하여 운영 부담을 크게 줄였습니다 (한 사례로, 12개의 도구를 New Relic 하나로 대체하여 엔지니어들이 중요한 작업에 더 집중할 수 있게 되었다는 보고가 있습니다). Collector는 New Relic 외에도 상황에 따라 Prometheus 등의 오픈소스 백엔드와도 연계 가능하므로, 일부 특정 팀은 PromQL 친화성을 위해 OTel Collector에서 수집한 메트릭을 Prometheus 서버로도 넘겨보는 등 이중 활용을 하기도 합니다. 하지만 전체적으로 Skyscanner 조직 차원에서는 New Relic을 단일 관찰 플랫폼으로 정착시켰습니다 (Making observability fun: How we increased engineers' confidence in incident management using a game | OpenTelemetry). OTel 도입 덕분에 New Relic 같은 상용 툴을 사용하면서도 표준 데이터 포맷을 유지하게 되어, 만약 향후 다른 솔루션으로 갈아타거나 자체 저장소를 도입하더라도 애플리케이션 계측을 다시 할 필요 없이 Collector의 출력만 바꾸면 되는 유연성을 확보한 상태입니다 (Skyscanner observability game days).

아키텍처와 규모: Skyscanner의 백엔드에는 수백 개의 마이크로서비스가 존재하며, 이는 수천 대 이상의 컨테이너/인스턴스에서 실행되고 있습니다 (Effective and Efficient Observability with OpenTelemetry - InfoQ). 예측 불가능한 외부 API 지연이나 실패까지 합쳐져 복잡도가 높기 때문에, Observability 시스템은 모든 구성요소의 상태를 실시간 수집하고 상호 연관지어 보여줄 수 있어야 합니다. OTel 기반 새 아키텍처에서는 각 서비스에서 생성된 트레이스 스팬과 메트릭 데이터가 태그(속성)를 통해 공통 컨텍스트(예: Trace ID)로 연결되고, Collector가 이를 모아 New Relic으로 전달합니다 (Making observability fun: How we increased engineers' confidence in incident management using a game | OpenTelemetry). 매일 수십억 건 이상의 텔레메트리 이벤트가 생성되지만, 앞서 언급한 샘플링과 필터링으로 데이터량을 조절하고 New Relic 측에서도 대용량 처리를 감당하여 전체 시스템이 안정적으로 운영되고 있습니다 (Skyscanner observability game days). Skyscanner는 OTel 도입 이후 Observability 게임데이라는 것을 정기적으로 열고 있는데, 이는 사전에 준비된 OpenTelemetry Demo 분산 애플리케이션(Astronomy Shop)을 활용하여 가상의 장애 시나리오를 팀원들이 연습하는 훈련입니다 (Skyscanner observability game days). 이 환경에서 개발자들은 New Relic에 모인 OTel 데이터를 보며 문제를 진단/해결하는 실습을 거치는데, 이러한 교육 프로그램을 통해 전체 엔지니어 조직이 새로운 Observability 도구에 익숙해지고 실전 대응 능력을 향상시키고 있습니다 (Skyscanner observability game days) (Skyscanner observability game days). 즉, 기술적 아키텍처뿐 아니라 조직적 준비(인력 교육)까지 병행함으로써 OpenTelemetry 기반 관찰 문화를 정착시킨 것입니다.

운영 성과와 교훈: Skyscanner는 OpenTelemetry 도입을 통해 관측 가능성의 패러다임 전환을 이루었습니다. 우선, 이전에는 각각 별개로 보던 로그, 메트릭, 추적 정보를 이제는 한 곳에서 종합적으로 분석하게 되어 문제의 근본 원인에 도달하는 시간이 단축되었습니다. Skyscanner 팀은 “텔레메트리 데이터를 OpenTelemetry 표준으로 이관한 이후 더 풍부한 계측 정보를 얻었고, 이제는 관측 결과만으로 직접 문제를 파악할 수 있게 되었다”라고 밝혔습니다 (Making observability fun: How we increased engineers' confidence in incident management using a game | OpenTelemetry). 이는 곧 엔지니어들의 새로운 사고방식(observability mindset)을 가능케 했는데, 불확실한 장애 상황에서도 데이터에 기반해 탐색하고 대응할 수 있는 문화적 자신감을 심어주었습니다 (Making observability fun: How we increased engineers' confidence in incident management using a game | OpenTelemetry). 두 번째로, 운영 효율 향상입니다. 여러 도구를 하나로 통합하면서 관리 오버헤드가 크게 줄었고, New Relic 대시보드 상에서 서비스 지도, 추적, 경고 등을 한 번에 다루게 되어 협업 효율이 높아졌습니다. 예를 들어 과거에는 한 사고를 조사하려면 각각의 팀이 자기 도구(Sentry, Grafana, Splunk 등)를 보며 따로 논의해야 했지만, 이제는 공통 화면을 보면서 원인 서비스를 찾고 대응방안을 즉석에서 모색할 수 있습니다. 세 번째로, 데이터 품질과 비용 통제입니다. OTel 도입 후 Skyscanner는 모든 팀에 텔레메트리 데이터의 가치 평가를 요청하여, 불필요한 데이터는 버리고 중요한 데이터를 남기는 데이터 선별 작업을 거쳤습니다. 이를 바탕으로 데이터 수집 정책(어떤 경우에 어떤 신호를 얼마만큼 수집/저장할지)을 정했고, Collector 레벨에서 샘플링/쿼타를 구현하여 데이터 폭증이 시스템에 영향을 주지 않도록 했습니다 (Building a large-scale Observability Ecosystem | by Juan Pi | Mercado Libre Tech | Medium). 이처럼 수집 데이터에 우선순위를 두고 다룬 결과, 제한된 리소스로도 핵심 인사이트를 얻을 수 있게 되었고 New Relic 사용 비용도 합리적으로 유지하고 있습니다. 네 번째, 문제 대응력 향상입니다. 앞서 언급한 Observability 게임데이를 비롯해, Skyscanner는 OpenTelemetry 도입을 엔지니어링 역량 강화의 기회로 삼았습니다. 게임데이 훈련 결과 개발자들은 새로운 모니터링 도구에 익숙해졌고, 실제 사고 때 런북에 없는 미지의 문제도 끝까지 추적하는 능력이 향상되었습니다. 이는 결국 사용자들에게 더 나은 서비스 가용성과 신뢰성을 제공하게 되었고, 복잡한 분산 시스템에서도 체계적으로 운영할 수 있다는 자신감을 조직에 심어주었습니다.

Skyscanner 사례의 교훈은, 표준화된 계측 + 올인원 플랫폼 + 조직 학습의 조합이 대규모 시스템 Observability에 매우 효과적이었다는 점입니다. 다만 모든 조직이 Skyscanner와 동일한 선택(New Relic 도입 등)을 할 필요는 없겠지만, OpenTelemetry라는 개방형 표준을 중심에 둠으로써 얻는 유연성은 어떤 경우에도 유용합니다. Skyscanner는 현재도 OpenTelemetry 커뮤니티에서 활동하며 새로운 기능(예: 트레이스 기반 테스트, 확장 가능한 메트릭 수집 등)을 시도하고 있고, 얻은 경험을 블로그나 발표 (Effective and Efficient Observability with OpenTelemetry - InfoQ)를 통해 공유함으로써 업계 전체의 Observability 수준 향상에 기여하고 있습니다.

MercadoLibre의 OpenTelemetry 도입

도입 배경: MercadoLibre는 라틴아메리카 최대의 전자상거래 및 핀테크 기업으로, 마켓플레이스와 온라인결제(Mercado Pago) 등을 운영합니다. 규모가 매우 큰 만큼, 수많은 마이크로서비스가 상호작용하는 복잡한 시스템을 갖추고 있습니다. 예를 들어 결제 처리 서비스만 해도 100여 개의 마이크로서비스가 참여하고 그 사이에 1000개 이상의 서로 다른 오퍼레이션(연동 호출)이 일어납니다 (Building a large-scale Observability Ecosystem | by Juan Pi | Mercado Libre Tech | Medium). 이렇게 복잡도가 높은 분산 환경에서는 어느 한 서비스의 이상이 전체 거래 흐름에 영향을 줄 수 있기 때문에, 엔지니어들은 항상 “무엇이, 왜 실패하고 있는가?”를 빠르게 답해야 합니다 (Building a large-scale Observability Ecosystem | by Juan Pi | Mercado Libre Tech | Medium). MercadoLibre는 이러한 도전 과제에 대응하기 위해 Observability 역량을 강화하는 전략을 세웠고, 그 핵심에 OpenTelemetry 표준 도입을 두었습니다 (Building a large-scale Observability Ecosystem | by Juan Pi | Mercado Libre Tech | Medium). OpenTelemetry를 선택한 주된 이유는 (1) 벤더 종속성 탈피 및 데이터 소유권 확보 – 상용 APM에 의존하지 않고 스스로 데이터 포맷을 관리함으로써 향후 필요시 어떤 도구로도 전환이 가능하고 데이터 활용의 유연성이 높아짐 (Building a large-scale Observability Ecosystem | by Juan Pi | Mercado Libre Tech | Medium), (2) 통합된 계측과 데이터 모델 – 여러 팀과 서비스가 공통된 API와 명명 규칙으로 계측하면 서로 이해하기 쉬운 지표와 추적 정보를 생산하게 되어 협업이 원활해짐 (Building a large-scale Observability Ecosystem | by Juan Pi | Mercado Libre Tech | Medium), (3) 확장성과 커스터마이징 – OTel은 오픈소스로 필요한 기능을 추가 개발하거나 데이터 처리 파이프라인을 원하는 대로 조작하기 용이함 등이었습니다. 즉 MercadoLibre는 OpenTelemetry를 도입함으로써 데이터에 대한 주도권을 갖고, 사후분석이 아닌 탐색적 모니터링(Exploratory Observability)을 구현하려고 한 것입니다 (Building a large-scale Observability Ecosystem | by Juan Pi | Mercado Libre Tech | Medium).

구현 방식: MercadoLibre의 Observability 플랫폼 팀은 사내 플랫폼 (Fury라고 불리는 PaaS)의 일부로 대규모 Observability 에코시스템을 구축하기 시작했습니다. 이들은 우선 기존에 사용중이던 다양한 모니터링 도구들의 데이터를 수렴하기 위해 텔레메트리 데이터 표준화 작업에 착수했고, 그 일환으로 OpenTelemetry를 조직 전반에 채택하기로 했습니다 (Building a large-scale Observability Ecosystem | by Juan Pi | Mercado Libre Tech | Medium) (Building a large-scale Observability Ecosystem | by Juan Pi | Mercado Libre Tech | Medium). 각 서비스들은 언어별(OpenTelemetry Java, Go, Python, Node 등) SDK를 통해 로그, 메트릭, 트레이스를 수집하도록 계측되었습니다. 특히 이전까지 공백 영역이었던 분산 트레이싱과 프로파일링 기능을 새로 플랫폼에 추가하여, OTel을 통해 서비스 호출 추적과 CPU/메모리 프로파일 데이터 수집이 가능해졌습니다 (Building a large-scale Observability Ecosystem | by Juan Pi | Mercado Libre Tech | Medium) (Building a large-scale Observability Ecosystem | by Juan Pi | Mercado Libre Tech | Medium). 플랫폼 팀은 이를 위해 Jaeger, Pyroscope 등의 오픈소스 툴킷을 활용하거나 자체 Collector 모듈을 개발하여, Fury 플랫폼 내에서 애플리케이션 성능 프로파일링과 엔드투엔드 트랜잭션 추적을 제공했습니다. 또한 이러한 새로운 신호를 포함해 모든 Observability 데이터를 볼 수 있는 “Single Pane of Glass” UI를 구축했습니다 (Building a large-scale Observability Ecosystem | by Juan Pi | Mercado Libre Tech | Medium). 이 포털은 각 서비스의 메트릭 대시보드, 로그, 분산트레이스, 프로파일 등을 한 화면에서 연동해서 볼 수 있게 함으로써, 엔지니어들이 필요한 컨텍스트를 쉽게 얻고 문제 해결을 신속히 시작할 수 있도록 도와줍니다 (Building a large-scale Observability Ecosystem | by Juan Pi | Mercado Libre Tech | Medium). 한편, OpenTelemetry Collector도 데이터 수집 파이프라인에 도입되어 애플리케이션 측 SDK와 백엔드 저장소 사이에서 데이터 중계 및 처리 레이어를 형성했습니다. Collector를 통해 엔드포인트 지표(Prometheus etc.) 수집, Trace Sampling/Filtering, 메타데이터 추가 등을 수행하고, 결과 데이터를 사전에 결정한 경로로 전송했습니다. MercadoLibre는 메트릭, 로그, 트레이스 각각에 대해 다층적인 스토리지를 구현했는데, 예를 들어 메트릭은 실시간 모니터링을 위해 in-memory 시계열 DB에 먼저 적재하고, 중장기 분석을 위해 NoSQL 기반 데이터 레이크(예: Apache Druid나 ClickHouse 등)에도 저장합니다. 로그는 일별 수십 TB에 이르므로 Elasticsearch로는 감당하기 어렵고, 대신 분산 파일시스템 + Parquet 조합으로 장기보관하며, 최근 1일치 정도만 Elasticsearch 클러스터에 유지해 빠른 검색을 가능케 했습니다. 트레이스 역시 자체 분산 추적 저장소(Jaeger의 스토리지 엔진 개선 버전)를 구축하고, 핵심 트랜잭션에 대해서만 100% 수집하며 나머지는 샘플링 비율을 조정해 저장했습니다. 이러한 백엔드 구조는 서비스 특성에 따라 다양한 Retention 정책과 샘플링 전략을 적용할 수 있게 설계되었으며, OpenTelemetry Collector와 연동하여 구현되었습니다 (Building a large-scale Observability Ecosystem | by Juan Pi | Mercado Libre Tech | Medium) (Building a large-scale Observability Ecosystem | by Juan Pi | Mercado Libre Tech | Medium).

데이터 백엔드 연계: MercadoLibre Observability의 백엔드 시스템은 철저히 자체 호스팅 방식으로 구성되었습니다. 이는 워낙 데이터량이 많아 상용 솔루션으로는 감당이 어렵기도 하고, 민감한 비즈니스 데이터의 주권을 지키기 위함이기도 합니다 (Building a large-scale Observability Ecosystem | by Juan Pi | Mercado Libre Tech | Medium). 앞서 언급한 것처럼 메트릭은 내부 TSDB와 데이터 레이크, 로그는 ClickHouse/Parquet 기반 저장, 트레이스는 Jaeger 호환 저장소 등을 사용하고 있으며, 모두 OpenTelemetry로부터 출력된 표준화된 텔레메트리 데이터를 받아들이도록 만들어졌습니다 (Building a large-scale Observability Ecosystem | by Juan Pi | Mercado Libre Tech | Medium). OTel의 툴-불가지성(tool-agnostic) 특성 덕분에, MercadoLibre는 필요에 따라 Prometheus, Jaeger, Loki, Tempo 등 다양한 오픈소스 백엔드 컴포넌트를 조합해 사용할 수 있었고, 현재는 가장 효율적인 조합을 찾아 맞춤형 observability 스토리지 계층을 운영 중입니다. 또한 이 데이터들을 분석해 운영 인사이트를 뽑아내기 위해 별도의 빅데이터 분석 플랫폼(Spark 기반 데이터 웨어하우스 등)과도 연계하고 있습니다. 즉, OpenTelemetry로 모인 원천 텔레메트리 데이터를 OLAP 시스템으로 보내 비즈니스 KPI와 연관 분석을 수행하는 등 Observability 데이터를 비즈니스 의사결정에도 활용하고 있습니다. 이러한 통합 데이터 전략은 모두 OpenTelemetry의 개방형 표준 덕분에 가능했는데, OTel 이전이었다면 각 모니터링 도구에서 내보내는 서로 다른 포맷의 데이터를 일일이 ETL해야 했겠지만, 이제는 OTLP라는 단일 프로토콜로 통일되어 후처리가 용이해졌습니다 (Building a large-scale Observability Ecosystem | by Juan Pi | Mercado Libre Tech | Medium).

아키텍처와 규모: MercadoLibre의 Observability 생태계는 그야말로 초대규모입니다. 최근 공개된 바에 따르면, 하루에 로그 40TB 이상이 생성되고, 1분당 2억 개 이상의 트레이스 스팬과 2억5천만 건 이상의 메트릭 포인트가 수집됩니다 (Building a large-scale Observability Ecosystem | by Juan Pi | Mercado Libre Tech | Medium). 이는 초당 환산하면 약 330만 개 스팬, 416만 개 메트릭이 들어오는 셈으로, 세계에서도 손꼽힐 만한 수준입니다. 이러한 부하를 처리하기 위해 플랫폼 팀은 각 구성요소(로그, 메트릭, 트레이스 수집기 및 저장소)에 대한 성능 목표치와 성장률을 설정하고, 시스템이 한계에 가까워지면 확장하거나 아키텍처를 개선하는 식으로 탄력적 확장을 계획했습니다 (Building a large-scale Observability Ecosystem | by Juan Pi | Mercado Libre Tech | Medium) (Building a large-scale Observability Ecosystem | by Juan Pi | Mercado Libre Tech | Medium). 또한 앞서 설명한 샘플링 및 할당(quota) 정책을 도입하여, 중요도가 낮은 서비스나 데이터의 수집 빈도를 낮추고 중요 서비스에 리소스를 우선 분배함으로써 리소스 편중 현상(noisy neighbor)을 완화했습니다 (Building a large-scale Observability Ecosystem | by Juan Pi | Mercado Libre Tech | Medium) (Building a large-scale Observability Ecosystem | by Juan Pi | Mercado Libre Tech | Medium). 이런 거버넌스 덕분에 한 서비스의 폭주로 전체 Observability 시스템이 영향을 받지 않도록 격리하고 안정성을 높였습니다. 아키텍처적으로는, Fury 플랫폼 내에 Observability 전용 플랫폼 팀이 있어 중앙에서 수집기, 저장소, 대시보드 등을 관리하며 각 애플리케이션 팀과 협업합니다 (Building a large-scale Observability Ecosystem | by Juan Pi | Mercado Libre Tech | Medium) (Building a large-scale Observability Ecosystem | by Juan Pi | Mercado Libre Tech | Medium). 애플리케이션 팀은 자신들의 서비스에 OpenTelemetry SDK를 적용하고 적절한 span/metric 이름을 붙이는 역할을 하고, 플랫폼 팀은 수집된 데이터가 저장되고 시각화되는 파이프라인을 책임집니다. 수천 개에 달하는 마이크로서비스가 공존하는 MercadoLibre 환경에서, 이러한 중앙 통제와 표준화된 분산 계측은 필수적이며 OpenTelemetry 도입으로 그것이 가능해졌습니다.

운영상의 이점 및 해결한 문제: MercadoLibre는 OpenTelemetry 기반 Observability 생태계를 구축한 이후 여러 이점을 실현했습니다. 첫째, 데이터 일관성 및 컨텍스트 보존입니다. OTel 도입으로 서비스 간에 공통된 계측 규약이 생기고, 특히 Trace Context를 활용해 로그, 오류, 메트릭까지도 단일 트랜잭션 기준으로 묶을 수 있게 되었습니다. 이는 문제 발생 시 “해당 요청의 전체 행적”을 추적하는 것을 가능케 해주었고, 과거라면 여러 팀에 흩어진 로그를 시간순으로 맞춰봐야 했을 작업을 이제는 한 곳에서 수행할 수 있게 되었습니다. 둘째, 벤더 락인 해소와 비용 최적화입니다. MercadoLibre는 이전에는 일부 상용 APM을 사용하기도 했으나, OpenTelemetry로 계측을 표준화한 덕분에 내부에서 필요한 데이터를 모두 확보하게 되었고, 외부 솔루션 의존도를 줄여 비용을 대폭 절감했습니다 (Building a large-scale Observability Ecosystem | by Juan Pi | Mercado Libre Tech | Medium). 또한 데이터가 자신들 손에 있으므로 저장 기간이나 형태를 자유롭게 조절할 수 있어(예: 오래된 데이터는 콜드 스토리지로 옮기는 등) 경제적으로 운영하고 있습니다. 셋째, 기능 확장성입니다. Observability 팀은 OTel을 도입하면서 새로운 신호(Profile 등)도 플랫폼에 추가했는데 (Building a large-scale Observability Ecosystem | by Juan Pi | Mercado Libre Tech | Medium), 이는 개발자들에게 성능 최적화의 강력한 무기를 쥐여준 셈입니다. 예컨대 한 서비스에서 CPU 핫스팟이 의심되면, 해당 서비스에 OTel Profiling을 활성화하여 실시간으로 프로파일 데이터를 수집/분석함으로써 코드 레벨의 병목까지 찾아내는 식입니다. 이렇게 APM 이상의 깊이로 관찰할 수 있게 되어 시스템 전체의 성능을 한층 끌어올릴 기회가 생겼습니다. 넷째, 향상된 문제해결 과정입니다. OTel 도입 이후 MercadoLibre 엔지니어들은 문제를 탐색하는 접근법이 바뀌었는데, 예전처럼 미리 만들어둔 대시보드 몇 개를 훑는 것이 아니라, 그때그때 질문에 따라 데이터를 다각도로 파고드는 탐색적 분석을 하게 되었습니다 (Building a large-scale Observability Ecosystem | by Juan Pi | Mercado Libre Tech | Medium). Observability 플랫폼은 이를 뒷받침하기 위해 풍부한 메타데이터와 자유로운 질의를 지원하고, 덕분에 “예상치 못한 상태라도 관찰을 통해 이해하고 대처하는” 진정한 의미의 Observability를 추구하게 되었습니다 (Building a large-scale Observability Ecosystem | by Juan Pi | Mercado Libre Tech | Medium). 다섯째, 조직 차원의 인사이트 공유입니다. Single Pane of Glass 포털 도입으로 모든 팀이 공통된 툴을 사용하게 되자, 잘 만든 대시보드나 유용한 탐지 기법을 조직 전체에 전파하기 쉬워졌습니다. 한 팀에서 발견한 패턴을 다른 팀도 손쉽게 적용하면서 운영 최적화의 베스트 프랙티스가 빠르게 공유되고 있습니다. 또한 경영진이나 비기술 부서에서도 관찰 지표(서비스 가용성, 성능 지표 등)를 쉽게 확인하게 되어, 기술과 비즈니스 간의 연결 고리가 강화된 면도 있습니다 (Shopify’s Journey to Planet-Scale Observability | by Dotan Horovits (@horovits) | Feb, 2025 | Medium) (예: 어떤 캠페인의 효과를 시스템의 R.E.D. 메트릭과 연계해 살펴봄으로써 마케팅 의사결정에 참고하는 등).

물론 이런 성과들 뒤에는 많은 노력과 도전이 있었습니다. 운영 데이터의 폭발적 증가는 그중 가장 큰 도전이었는데, MercadoLibre Observability 팀은 이를 해결하기 위해 앞서 설명한 샘플링, 할당제, 계층화 저장소 등 모든 수단을 동원했습니다 (Building a large-scale Observability Ecosystem | by Juan Pi | Mercado Libre Tech | Medium). 또한 모든 서비스 팀의 협업이 필요하다는 점도 어려운 부분이었지만, 플랫폼 팀이 주도적으로 표준과 도구를 제공하고 서비스 팀이 피드백을 주는 크로스팀 협력 체계를 구축하여 비교적 순조롭게 전사 도입을 이끌어냈습니다 (Building a large-scale Observability Ecosystem | by Juan Pi | Mercado Libre Tech | Medium) (Building a large-scale Observability Ecosystem | by Juan Pi | Mercado Libre Tech | Medium). 아직도 데이터 증가율이 높고 새로운 서비스가 계속 생겨나기 때문에, MercadoLibre의 Observability 플랫폼은 진화 중인 시스템입니다. 플랫폼 팀은 정기적으로 시스템의 상태를 검토하고 병목 지점을 개선하고자 후속 블로그 시리즈를 예고하고 있습니다 (Building a large-scale Observability Ecosystem | by Juan Pi | Mercado Libre Tech | Medium). 이를 통해 얻은 교훈을 다시금 공유하며, OpenTelemetry를 중심으로 한 대규모 Observability 구현에 대한 모범 사례를 만들어가고 있습니다.

---

以上の 사례들을 통해 살펴보았듯이, OpenTelemetry는 eBay, Shopify, GitHub, Skyscanner, MercadoLibre와 같은 초대형 트래픽 기업들의 Observability 전략에 핵심 요소로 채택되고 있습니다. 각 기업은 저마다의 배경과 요구사항 속에서 OpenTelemetry를 도입하여 계측 표준화, 데이터 파이프라인 유연화, 문제 해결력 강화, 비용 절감 등의 효과를 얻었습니다. 물론 도입 과정에서 기술적 난관과 조직적 변화 관리가 필요했지만, 대부분 자체적인 도구 개발이나 커뮤니티 기여, 단계적 이행 등의 방법으로 극복해냈습니다. Observability 아키텍처의 규모는 회사마다 다르지만 (数千万 QPS 메트릭 처리부터 수백만 스팬/초 트레이싱까지), OpenTelemetry의 스케일 아웃 설계와 벤더 중립성이 이러한 요구에 잘 부응하고 있음을 알 수 있습니다. 결론적으로, OpenTelemetry 도입은 대규모 분산 시스템에서의 운영 가시성을 획기적으로 향상시키며, 업계 리더들은 이를 적극 활용함으로써 안정성과 개발 생산성, 나아가 비즈니스 성공을 뒷받침하고 있습니다.

참고 자료: 해당 사례에 대한 세부 내용은 각 사의 기술 블로그와 발표 자료에서 확인할 수 있습니다. eBay의 사례는 자사 기술 블로그 글인 *"Why and How eBay Pivoted to OpenTelemetry"에서 상세히 다뤄졌고 (Why and How eBay Pivoted to OpenTelemetry) (Why and How eBay Pivoted to OpenTelemetry), Shopify 사례는 *OpenObservability Talks 인터뷰 및 관련 미디엄 글에서 기술되었습니다 (Shopify’s Journey to Planet-Scale Observability | by Dotan Horovits (@horovits) | Feb, 2025 | Medium) (Shopify’s Journey to Planet-Scale Observability | by Dotan Horovits (@horovits) | Feb, 2025 | Medium). GitHub는 공식 엔지니어링 블로그 *"Why (and how) GitHub is adopting OpenTelemetry"*를 통해 배경과 초기 도입 경험을 공유했습니다 (Why (and how) GitHub is adopting OpenTelemetry - The GitHub Blog) (Why (and how) GitHub is adopting OpenTelemetry - The GitHub Blog). Skyscanner와 MercadoLibre는 CNCF 발표와 Medium 블로그를 통해 OpenTelemetry 도입 경험과 성과 지표를 공개하고 있어, 더욱 깊은 인사이트를 얻길 원한다면 해당 원문들을 참고하시기 바랍니다 (Skyscanner observability game days) (Building a large-scale Observability Ecosystem | by Juan Pi | Mercado Libre Tech | Medium).