오픈텔레메트리(OpenTelemetry, OTel)가 클라우드 환경에서 분산 시스템의 관측 가능성(observability)을 위한 표준으로 자리매김하고 있지만, 벤더 중립성이라는 큰 목표를 달성하는 과정에서 기능 개발 속도가 현저히 느려지고 있다는 지적이 제기되었습니다. 엄격한 안정성 보장, 광범위한 언어 및 프레임워크 지원, 그리고 부족한 유지관리자 수가 복합적으로 작용하여 새로운 기능이 사용자에게 도달하는 데 오랜 시간이 걸리고 있다는 분석입니다.
OTel 프로젝트는 핵심(Core)과 기여(Contrib) 두 영역으로 나뉘어 운영되며, 새로운 기능은 OTEP(OpenTelemetry Enhancement Proposal) 제출부터 명세, 시맨틱 규약, 언어별 SDK 구현, 계측 패키지, Collector, OTLP 전송에 이르기까지 여러 단계를 거칩니다. 이 과정마다 안정성 검토와 구현 부담이 누적되는데, 특히 최근 24개월간의 PR 병합 분석 결과 C++(86.1%), Kotlin(79.7%), Ruby(78.7%), Python(61.4%) 등 여러 OTel SDK에서 최상위 1인 유지관리자의 병합 비중이 매우 높게 나타났습니다. 이는 Prometheus(14.4%)나 Envoy(35.8%)와 같은 다른 CNCF 프로젝트에 비해 특정 개인에게 작업이 과도하게 집중되어 있음을 보여줍니다. 시맨틱 규약 논의가 지연의 주원인일 것이라는 예상과 달리, 실제 병목은 공개 API 승인과 같은 추가 검토와 인력 부족에서 발생하는 것으로 확인되었습니다.
이러한 상황은 벤더별 SDK와 OTel의 격차를 더욱 벌리고 있습니다. 벤더 SDK는 설치 즉시 대시보드에 데이터가 표시되고 구성 요소 연결이 자동으로 처리되는 반면, OTel은 많은 기능에 '실험적(Experimental)' 표시가 붙어 있고, 같은 작업을 수행하는 방법도 여러 가지여서 사용 난이도가 높습니다. 프로젝트는 최소 12개월을 보장하는 베타(Beta) 단계를 도입하여 실험적 기능에 대한 실사용자 피드백을 확보하고, 언어별 유지관리 수준을 솔직하게 공개하여 사용자가 정보에 기반한 선택을 할 수 있도록 해야 한다고 제안됩니다. 현재의 안정성 계약과 지원 범위를 현실적으로 조정하지 않으면 진정한 벤더 중립 시스템으로서의 가치를 충분히 발휘하기 어려울 것이라는 경고입니다. 이는 결국 프로젝트의 지속 가능성과 채택률에 부정적인 영향을 미칠 수 있습니다.