CNCF를 졸업한 OpenTelemetry

2026년 5월 21일, 클라우드 네이티브 생태계를 구축하는 CNCF(Cloud Native Computing Foundation)에서 OpenTelemetry의 졸업(Graduation)을 발표했다.

CNCF는 클라우드 네이티브와 관련된 다양한 오픈소스 프로젝트를 관리하고 있지만, 모든 프로젝트가 같은 지위를 가지고 있는 것은 아니다.

프로젝트의 성숙도에 따라 Sandbox → Incubating → Graduated(졸업)으로 나눠서 관리되고 있으며, CNCF의 프로젝트가 졸업했다는 것은 아래와 같은 의미를 지닌다.

기술적 성숙도: 프로덕션 환경에서 대규모로 사용하기에 충분히 안정적임
거버넌스의 투명성: 특정 기업에 종속되지 않고 다양한 기여자들에 의해 건강하게 운영 중임
보안 검증: 정기적인 보안 점검 및 컴플라이언스 충족함

그렇다면 CNCF에서 졸업 단계로 인정된 OpenTelemetry는 어떤 프로젝트일까?

1. 오픈소스 옵저버빌리티 프레임워크 OpenTelemtry

OpenTelemetry 이전에 OpenTracing과 OpenCensus라는 프로젝트가 있었다.

OpenTracing은 트레이스를 위한 벤더 중립적인 인터페이스(API)를 제공하는 데에 집중한 프로젝트였으며, 실제 데이터 수집과 구현은 사용자가 알아서 했어야 했다는 한계점이 존재했다.

OpenCensus는 API뿐만 아니라 실제 데이터를 수집하는 SDK까지 제공하는 프로젝트였다. 풍부한 구현체를 제공했지만 OpenTracing과 호환되지 않고 두 프로젝트는 서로 경쟁하는 위치였다.

오픈소스 생태계에서 이러한 경쟁은 기여나 지원 측면에서 불리할 수 있었기에, 2019년 KubeCon에서 OpenTracing와 OpenCensus가 OpenTelemetry라는 이름으로 합쳐졌다. 이로서 옵저버빌리티를 위한 API와 SDK가 하나로 통합된 프로젝트가 등장한 것이다.

출범하고 7년이 지난 OpenTelemetry는 CNCF에서 2번째로 큰 프로젝트로 거듭났다. Kubernetes 다음으로 활발한 프로젝트로서, 오프소스 옵저버빌리티의 ‘사실상 표준’으로 자리잡은 것이다. CNCF에서 졸업할 만한 기록이다.

OpenTelemetry를 간단히 설명하자면 (1)벤더 중립 오픈소스 (2)통합 옵저버빌리티 프레임워크다. 두 가지 키워드가 각각 어떤 의미인지 살펴보겠다.

벤더 중립 오픈소스

과거 모니터링과 옵저버빌리티 시스템을 구현하려면 각 솔루션 업체(벤더)가 제공하는 전용 에이전트와 SDK에 의존해야 했다. 각각 사용하는 표준이 다르기 때문이다. 이는 사용자가 벤더에 종속(Lock-In)되는 문제로 이어졌다. 자유와 유연성을 잃게 되는 것이다.

OpenTelemetry는 벤더에 종속되지 않는 오픈소스다. 제공업체에 의존하지 않고 옵저버빌리티에 필요한 데이터의 흐름을 사용자가 결정할 수 있게 되는 것이다.

게다가 OpenTelemetry가 CNCF에서 졸업 단계로 인정되었다는 것은 전세계의 수많은 기여자가 안정적인 생태계를 만드는 데에 성공했다는 뜻이다. 그렇기 때문에 지속가능성도 보장이 된다.

통합 옵저버빌리티 프레임워크

옵저버빌리티의 3가지 구성요소인 로그(Log)와 메트릭(Metric), 트레이스(Trace)는 본래 서로 다른 도구와 포맷으로 관리되어 왔다. 그래서 정작 장애가 발생했을 때 각 데이터들을 연결해서 원인을 파악하기 어려웠다.

OpenTelemetry는 이러한 관측 데이터들을 하나의 표준 규격과 프레임워크 안에서 통합 관리할 수 있다. 이는 두 가지 장점이 있다.

첫 번째로 상관관계 분석이 편리해진다. 각 관측 데이터에 리소스 특성(Attribute)과 Trace ID 등이 공유되기 때문에 에러 로그에서 해당 에러가 발생한 시점의 트레이스로 바로 이동할 수 있는 컨텍스트가 부여되고, 당시 서버의 메트릭(CPU, 메모리 상태) 데이터도 확인이 가능한 것이다.

두 번째로 학습 곡선이 단일화된다. 메트릭 수집용 SDK, 트레이스 수집용 라이브러리를 따로 공부할 필요가 없어진 것이다. OpenTelemetry라는 하나의 표준 가이드라인만 익히면 모든 종류의 옵저버빌리티 데이터를 다룰 수 있으므로 개발 생산성도 향상된다.

2. 앞으로 OpenTelemery 프로젝트에서 주목받을 키워드

OpenTelemetry가 CNCF에서 Graduated로 인정되었다는 것은 클라우드 네이티브 생태계의 기본 사양으로 거듭날 준비가 끝났다는 의미이다. 앞으로 OpenTelemetry 프로젝트에서 어떤 키워드가 주목받을지 살펴보겠다.

지속적 프로파일링

프로파일링이란 애플리케이션 코드의 CPU 및 메모리 사용량을 측정하는 것을 의미한다. 그러니까 지속적 프로파일링이라고 하면 코드의 자원 사용량을 애플리케이션이 실행 중에 실시간으로 측정한다는 뜻이다.

(출처: CNCF)

옵저버빌리티가 발전하면서 지속적 프로파일링을 고려하는 움직임이 늘어나고 있다. OpenTelemetry도 아직 알파 단계이지만 프로파일링 데이터를 호환하고 있다. 특히 eBPF 기술과 결합되면서 1% CPU 및 250MB 메모리만으로 프로파일링이 가능한 수준이다.

OpenTelemetry를 활용한 지속적 프로파일링에 대한 관심은 점차 커질 것으로 보인다. 통합 옵저버빌리티 프레임워크로서 다른 관측 데이터와의 연동도 수월하기 때문이다.

eBPF를 통한 코드 수정 없는 관측

방금 전 언급한 eBPF 기술에 대해서도 살펴볼 점이 있다. eBPF(extended Berkeley Packet Filter)는 리눅스 커널 레벨에서 데이터를 수집하는 기술로, 애플리케이션 코드 수정이 필요 없다는 것이 가장 큰 특징이다.

현재 OpenTelemetry에서는 eBPF 기술을 활용한 측정을 지원하고 있다. 이를 OBI(OpenTelemetry eBPF Instrumentation)라고 하는데, eBPF 기술을 활용해서 애플리케이션과 네트워킹 레이어를 살펴보며 트레이스와 핵심 상태 지표(RED) 데이터를 추출할 수 있는 기능이다. (RED 지표는 이전 아티클에서 다룬 적이 있다.)

OBI eBPF architecture (OBI 동작 원리 / 출처: OpenTelemtery 공식 문서)

OBI는 애플리케이션이나 네트워크, DB 측정뿐만 아니라 생성형 AI 측정도 지원한다. OpenAI나 Claude, Gemini 등 다양한 생성형 AI의 트레이스와 메트릭 데이터도 수집 가능한 것이다.

애플리케이션 코드 수정 없이 적은 리소스로 애플리케이션의 트레이스와 메트릭 데이터를 수집할 수 있으므로, OpenTelemetry가 클라우드 네이티브 생태계의 옵저버빌리티 표준 규격으로 자리잡으면서 OBI도 주목받는 것은 시간 문제일 것이다.

마무리

이번 아티클에서는 OpenTelemetry의 CNCF 졸업이 의미하는 바와 OpenTelemetry의 소개, 앞으로 주목받을 키워드까지 알아봤다.

OpenTelemetry는 앞으로 더 널리 사용되는 오픈소스 옵저버빌리티 프레임워크로 자리잡을 것이 자명하므로 미리미리 알아두면 도움이 될 것이다.

프로파일링과 eBPF 기술은 옵저버빌리티 분야에서 점점 자주 보이는 키워드이기 때문에 이번 아티클에서 간략히 다뤄보았다. 기회가 된다면 각 키워드를 좀 더 깊이 다루는 시간도 가져보도록 하겠다.

🔭Aiden's Lab

최근 게시글