OpenTelemetry
오픈텔레메트리
OpenTelemetry는 애플리케이션에서 나오는 추적·지표·로그를 하나의 규격으로 만들고 내보내는 오픈소스 관측 프레임워크입니다. 공식 문서는 원격 측정 데이터의 생성·내보내기·수집을 돕는 도구 모음이며 특정 벤더나 도구에 묶이지 않는다고 밝힙니다. 저장과 시각화는 담당하지 않아 예거·프로메테우스 같은 백엔드를 따로 골라야 합니다. 2019년 오픈트레이싱과 오픈센서스의 통합으로 출발해 2026년 5월 21일 CNCF 졸업 프로젝트가 됐습니다.
쉽게 말하면?
OpenTelemetry는 열린(open) 원격 측정(telemetry)이라는 뜻입니다. 서비스마다 다른 규격으로 로그를 남기면 나중에 합쳐 보기 어려운데, 계측 규격을 하나로 맞춰 두는 표준 콘센트 같은 역할이에요. 한 번만 계측해 두면 모니터링 도구를 바꿔도 코드를 다시 고치지 않아도 됩니다.
한 줄로 비유하면?
장비마다 다른 플러그를 하나의 표준 콘센트로 통일하는 일입니다.
어디에 쓰이나?
케이스 1이베이 — Sherlock.io 관측 플랫폼
이베이는 5년 넘게 쓰던 Elastic Beats 기반 수집 체계를 OpenTelemetry 수집기로 바꿨습니다. 노드마다 에이전트를 띄우는 방식 대신 클러스터 단위 수집 모델로 옮겼습니다. 상류 프로젝트에 10건 넘는 변경을 기여했습니다.
도입효과: 수집기 자원 사용량 약 1,700코어 → 29코어, 약 570GB → 57GB(쿠버네티스 노드 2,851대 기준, 2022-12-19)[4]
케이스 2스카이스캐너 — 중앙 라우팅과 분산 수집
스카이스캐너는 모든 원격 측정 데이터를 단일 DNS 엔드포인트로 받은 뒤 서비스 메시가 가까운 수집기로 보내는 구조를 씁니다. 대량 OTLP 트래픽은 게이트웨이 수집기가, 프로메테우스 엔드포인트 수집은 에이전트 수집기가 맡습니다. 서비스 메시 스팬을 플랫폼 지표로 바꿔 애플리케이션 코드는 건드리지 않았습니다.
도입효과: 마이크로서비스 1,000개 이상과 프로덕션 쿠버네티스 클러스터 24개를 애플리케이션 코드 변경 없이 계측(2026-04-21)[3]
케이스 3사람인 — 쿠버네티스 오퍼레이터 기반 도입
사람인은 쿠버네티스 전환으로 서비스 간 의존 관계 추적이 어려워지자 OpenTelemetry를 도입했습니다. 기존 Filebeat와 Metricbeat 조합은 데이터가 흩어져 고객 문의 분석이 오래 걸렸습니다. 오퍼레이터가 애너테이션으로 자동 계측을 주입하도록 구성하고 백엔드로 SigNoz를 붙였습니다.
도입효과: 계측 도구 2종(Filebeat·Metricbeat) → OpenTelemetry 단일 계측 체계로 통합(2026-03-20)[7]
케이스 4kt cloud — K8S 통합 수집기
kt cloud 서비스개발팀은 수집기가 너무 많다는 고객 의견을 받아 하나로 합치는 작업을 했습니다. 이전에는 로그와 지표를 Fluent-Bit이, 추적을 OpenTelemetry가 맡았습니다. OpenTelemetry Contrib 수집기 하나로 세 가지를 모두 처리하도록 파이프라인을 다시 짰습니다.
도입효과: 수집 도구 2종(Fluent-Bit·OpenTelemetry) → 1종으로 통합(2024-11-04)[8]
주의할 점은?
오늘 바로 해보기
1. 서비스 하나를 골라 현재 로그·지표·추적을 각각 어떤 도구로 보내는지 적습니다.
2. 해당 언어의 OpenTelemetry SDK 또는 코드 수정이 필요 없는 에이전트를 개발 환경에 붙입니다.
3. OTLP로 내보낸 추적이 백엔드에 들어오는지 요청 한 건으로 확인합니다.
4. 값 종류가 지나치게 많은 태그(사용자 ID 등)를 빼고 다시 측정합니다.
5. 계측 전후 응답 시간과 수집기 자원 사용량을 표로 남깁니다.
한계와 진화
오버헤드를 미리 숫자로 약속할 수 없습니다. 공식 자바 에이전트 문서는 현대 소프트웨어의 복잡성과 배포 환경의 다양성 때문에 단일 오버헤드 추정치를 내는 것이 불가능하다고 못 박고, 각자 부하 테스트를 하라고 안내합니다. 값 종류가 많은 태그와 디버그 로깅이 오버헤드를 키우는 요인으로 지목됩니다.
배포 구조가 비용을 좌우합니다. 이베이 사례에서 보듯 노드마다 수집기를 띄우는 기본 구성과 클러스터 단위 구성의 자원 사용량 차이는 수십 배에 이릅니다. 또 OpenTelemetry 자체는 저장소가 아니므로 예거·프로메테우스·SigNoz 같은 백엔드를 따로 고르고 운영해야 합니다. 계측 표준화의 이득은 도구를 갈아탈 때 비로소 체감됩니다.
참고 자료
- OpenTelemetry Docs, What is OpenTelemetry? https://opentelemetry.io/docs/what-is-opentelemetry/
- CNCF, OpenTelemetry Graduation 발표 (2026-05-21) https://www.cncf.io/announcements/2026/05/21/cloud-native-computing-foundation-announces-opentelemetrys-graduation-solidifying-status-as-the-de-facto-observability-standard/
- OpenTelemetry Blog, How Skyscanner scales OpenTelemetry (2026-04-21) https://opentelemetry.io/blog/2026/devex-skyscanner/
- OpenTelemetry Blog, Why and How eBay Pivoted to OpenTelemetry (2022-12-19) https://opentelemetry.io/blog/2022/why-and-how-ebay-pivoted-to-opentelemetry/
- OpenTelemetry Docs, Java agent performance https://opentelemetry.io/docs/zero-code/java/agent/performance/
- OpenTelemetry Blog, Performance testing (2023-11-27) https://opentelemetry.io/blog/2023/perf-testing/
- 사람인 기술 블로그, OpenTelemetry 도입기 (2026-03-20) https://saramin.github.io/2026-03-20-opentelemetry-in-action/
- kt cloud 기술 블로그, OpenTelemetry를 활용한 K8S Metric, Log, Trace 데이터 통합 수집기 (2024-11-04) https://tech.ktcloud.com/entry/OpenTelemetry%EB%A5%BC-%ED%99%9C%EC%9A%A9%ED%95%9C-K8S-Metric-Log-Trace-%EB%8D%B0%EC%9D%B4%ED%84%B0-%ED%86%B5%ED%95%A9-%EC%88%98%EC%A7%91%EA%B8%B0
대표 출처
OpenTelemetry Docs, What is OpenTelemetry?이 페이지에 대한 의견을 남겨주세요
여러분의 의견은 다음 갱신에 반영됩니다.