OTel은 잘되고 있지 않다 — 스프레드시트로 분석한 병목

OpenTelemetry는 벤더 중립성을 달성했지만, 엄격한 안정성 약속과 광범위한 언어·프레임워크 지원, 부족한 유지관리자가 맞물려 기능 전달이 느려짐 작업은 Core와 Contrib로 나뉘며, 새 기능은 OTEP·명세·시맨틱 규약·언어별 SDK·계측 패키지·Collector·OTLP를 거쳐야 해 단계마다 안정성 검토와 구현 부담이 누적됨 최근 24개월간 PR 병합의 최상위 1인 비중은 C++ 86.1%, Kotlin 79.7%, Ruby 78.7%, Python 61.4%였지만 Prometheus는 14.4%로, 여러 OTel SDK가 소수 유지관리자에게 과도하게 의존함 시맨틱 규약의 긴 논의가 SDK 전체를 직접 늦춘다는 예상과 달리, Python의 장기 미병합 PR은 공개 API 승인 같은 추가 검토와 인력 부족에서 병목이 나타남 Experimental과 Stable 사이에 최소 12개월을 보장하는 Beta 단계를 두고 언어별 유지관리 수준을 공개해야 하며, 안정성 계약과 지원 범위를 현실화하지 않으면 벤더별 SDK를 대체하기 어려움 벤더 SDK와 OpenTelemetry의 격차 벤더별 관측 가능성 SDK는 설치하면 대시보드에 데이터가 표시되고 구성 요소 연결도 공급자가 처리하지만, OpenTelemetry는 많은 기능에 Experimental 표시가 붙고 같은 작업을 수행하는 방법도 여러 가지임 특정 공급자나 데이터 사용처를 선호하지 않는 진정한 벤더 중립 시스템을 지향하며, 관측 가능성 업체에 고용된 유지관리자가 많은 상황에서도 특정 벤더가 우대된다는 인상을 주지 않음 시간이 지나면서 시맨틱 규약 저장소의 논의가 길어지고 언어별 지원 격차도 커짐 Go와 .NET은 일급 지원에 가까웠지만 일부 언어는 수년 뒤처짐 자동 계측은 효과적이지만 수동 계측이 필요한 순간부터 난도가 급격히 높아져, 시간·예산·여력이 적은 소규모 팀에는 사전 경고가 필요함 문제는 단순한 오픈소스 인력 부족이 아니라 바이너리 안정성 장벽, 작은 유지관리자 풀, 방대한 지원 범위가 충돌한다는 점임 기능을 Stable로 고정하면 바꾸기 어려워 잠재적 문제를 장기간 논의할 유인이 생김 Core, Contrib와 Collector 구조 OpenTelemetry는 수십 개 언어, 수백 개 라이브러리와 여러 백엔드를 포괄하며 작업을 두 영역으로 나눔 Core: OTel 프로젝트가 직접 유지관리하며 작고 안정적인 벤더 중립 명세를 정의함 Con...