관측성(observability) 도구를 벤더 종속 SDK에서 오픈텔레메트리(OpenTelemetry, OTel)로 옮기려 할 때 실무자들이 가장 자주 내놓는 반응은 "왜 아직 다 안 만들어진 것처럼 보이느냐"는 것이다. 벤더 SDK는 설치만 하면 대시보드에 데이터가 뜨고, 부품들이 어떻게 맞물리는지는 다른 누군가가 고민한다. 반면 OTel은 문 앞에서부터 '실험적(experimental)' 딱지와, 하나의 작업을 처리하는 여섯 가지쯤 되는 방법으로 사용자를 맞이한다. 한 엔지니어가 이 오래된 '뭔가 잘못됐다'는 인상을 감이 아닌 데이터로 확인해보기로 하고, 공개 저장소 활동을 긁어 스프레드시트로 정리했다.
먼저 짚을 것은, 이것이 애초에 OTel이 지향한 바가 아니라는 점이다. OTel은 데이터를 어디에 어떻게 쓰든 상관하지 않는, 진정으로 벤더 중립적인 시스템을 목표로 삼았다. 유지보수자 상당수가 관측성 벤더에 고용되어 있음에도 특정 벤더가 노골적으로 우대받는 느낌이 없다는 점은 이 치열하고 돈이 걸린 생태계에서 꽤 대단한 성취다. 문제는 이 원칙주의가 다른 제약과 충돌하면서 프로젝트를 사실상 얼려버렸다는 데 있다.
세 가지가 동시에 충돌한다
필자가 진단한 핵심은 '3중 충돌'이다. 첫째, 한번 안정(stable)으로 표시하면 되돌릴 수 없다는 이진적 안정성 관문이 있다. 둘째, 실제로 움직이는 유지보수자 인력이 매우 얇다. 셋째, 지원하려는 언어와 프레임워크의 범위가 어마어마하게 넓다. 이 셋이 겹치면 '한번 확정되면 영영 못 고친다'는 두려움 때문에, 기능이 만들어낼 잠재적 문제를 놓고 끝없이 논쟁할 유인이 생긴다. 안정성을 진지하게 지키려는 태도가 역설적으로 진행을 막는 것이다.
구조적으로 OTel은 작업을 core와 contrib로 나눈다. 깨지지 않는 것은 core, 깨질 수 있는 것은 contrib로 간다. 언어 SDK 쪽에서는 이 방식이 큰 문제가 아니다. 필요한 Flask 계측이 있으면 해당 패키지만 설치하면 된다. 그러나 컬렉터(collector) 쪽에서는 300개짜리 익스포터를 다 끌어안을 수 없으니, 필요한 것만 골라 자기만의 컬렉터를 빌드해야 하는 부담이 생긴다. 도구가 있다는 건 좋지만, 작은 팀이 감당하기엔 과한 범위다.
문제는 논쟁이 아니라 사람 수였다
필자는 같은 CNCF 프로젝트인 Envoy, Prometheus와 비교했다. Envoy는 작성자·병합자·이슈 처리자가 고르게 분포된 건강한 프로젝트로 나타났다. 특정 인물이 중요하긴 해도 대체 인력이 있다. 반면 PHP와 Ruby SDK는 활동이 사실상 두 사람에게 집중되어 있었다. 이는 OTel이 감당하려는 범위를 커버하기엔 명백히 부족한 구조다. 상대적으로 Go와 닷넷, 그리고 파이썬은 훨씬 건강해 보였다. 즉 언어별 성숙도 격차는 인상이 아니라 실제였다.
흥미로운 건 '느린 이유'에 대한 필자의 최초 가설이 빗나갔다는 점이다. 그는 시맨틱 컨벤션(semantic-conventions) 저장소에서 벤더 간 논쟁이 병목을 일으키고 그것이 하류로 번질 것이라 예상했다. 그러나 데이터를 보니 semconv의 느린 PR들은 대체로 복잡한 주제 자체 때문이었고, 그 지연이 SDK/API 영역으로 전파되지도 않았다. OTel이 이 논의를 잘 격리해둔 셈이다. 파이썬에서 가장 느린 PR들의 원인은 별도 유지보수자의 승인을 요구하는 공개 API 검토 절차였는데, 이는 적절하지만 결국 다시 '사람이 부족하다'는 출발점으로 되돌아온다.
결국은 '누가 유지보수자에게 돈을 주느냐'
필자는 유지보수자들이 논의를 공개적으로 잘 운영해왔고, 참여를 막으려는 태도도 아니라고 본다. 프로젝트를 얼린 것은 게이트키핑이 아니라 안정성에 대한 과도한 기대다. 이 정도 복잡도의 프로젝트를 취미로 유지할 수는 없다. 장기 안정성 약속을 내건 프로젝트라면 무보수 자원봉사 커뮤니티에 의존할 수 없고, 그렇다고 유급 유지보수자에게는 소속 조직의 기대라는 또 다른 압력이 얹힌다.
대안으로 제시된 것은 실험적 단계와 안정 단계 사이의 '기간 한정 베타' 계층이다. 실험적 기능은 접근 절차가 번거로워 대다수 사용자에겐 없는 것이나 마찬가지다. 만약 어떤 기능이 최소 12개월간 제거되지 않고 더 쉽게 쓸 수 있다면, 실제 피드백을 모으는 데 도움이 될 것이다. 다만 현재 베타 개념은 SDK에는 적용되지만 컴포넌트에는 적용되지 않는 등 라벨 체계 자체가 혼란스럽다는 한계가 있다. 필자는 또한 Go와 Ruby가 같은 수준으로 관리된다고 말하는 것은 오해를 부르며, 유지보수 등급을 솔직히 드러내야 사용자가 선택할 수 있고 다른 계층에 도움도 끌어올 수 있다고 지적한다. 한국의 실무자 입장에서 시사점은 분명하다. OTel 도입 여부는 이념이 아니라 자신이 쓰는 언어 SDK의 성숙도와 자동 계측 이후 수동 계측의 절벽을 감당할 수 있는지로 판단해야 하며, 프로젝트 진짜 병목이 '논쟁'이 아니라 '독립적인 유지보수자 부족'이라는 점을 기억할 필요가 있다.