Coroot가 7개 언어의 OpenTelemetry SDK 오버헤드를 같은 조건에서 측정했다

이 글의 가장 큰 한계는 비교를 위한 실험 설계는 자세하지만, 정작 비교 결과가 빠져 있다는 점입니다. Go부터 Ruby까지 일곱 언어를 같은 부하와 서비스 조건에서 측정했다고 설명하지만, CPU·메모리·지연 시간·네트워크 사용량의 언어별 수치가 제시되지 않았습니다. 따라서 독자는 어떤 SDK가 가벼운지, 추적을 켰을 때 어느 런타임에서 비용이 커지는지 판단할 수 없습니다. 지금 주어진 정보만으로는 이 기사를 언어 성능 비교의 근거로 인용하기 어렵습니다.

그렇다고 측정 설계가 무의미한 것은 아닙니다. 요청마다 Valkey의 INCR 한 번만 수행하고 초당 1,000건을 고정한 구성은 애플리케이션 작업에 비해 계측 비용이 눈에 띄게 드러나도록 만든 조건입니다. 또 SDK를 끈 경우와 추적 비율 0%를 나눠 둔 점은 유용합니다. 둘의 차이는 스팬을 전송하지 않아도 SDK와 계측 코드가 활성화된 상태에서 발생하는 비용을 가늠하는 데 도움이 될 수 있습니다.

다만 이 결과가 공개되더라도 이를 곧바로 언어 자체의 성능 순위로 읽으면 곤란합니다. Java·Python·Node.js는 제로 코드 에이전트를 쓰고 다른 언어는 SDK와 계측 라이브러리를 썼다고 되어 있어, 비교 대상에는 런타임뿐 아니라 구현 방식과 계측 스택의 차이도 함께 들어갑니다. 이는 실제 현장에서 흔히 선택하는 구성을 비교한다는 장점이 있지만, 특정 언어가 느린 이유를 런타임과 SDK 중 무엇에서 찾아야 하는지는 분리해 주지 못할 가능성이 큽니다.

또한 단일 엔드포인트와 한 가지 요청률은 오버헤드가 큰 상황을 드러내는 데 적합할 수 있지만, 실제 서비스의 대표값이라고 보기는 어렵습니다. 요청마다 더 많은 계산이나 외부 호출이 있는 서비스에서는 트레이싱 비용의 상대적 비중이 작아질 수 있고, 반대로 고처리량·저지연 서비스에서는 작은 절대 비용도 중요한 제약이 될 수 있습니다. 그러므로 이 실험은 보편적인 답이라기보다 특정한 경계 조건을 보여주는 자료로 해석하는 편이 타당합니다.

재현성을 위해 두 차례 측정하고 평균을 냈다는 점은 확인되지만, 반복 횟수와 평균만으로 변동 폭까지 알 수는 없습니다. 편차나 신뢰구간, 언어별 런타임 설정과 버전, 실제 지연 시간 변화가 함께 공개되어야 차이가 안정적인지 판단할 수 있습니다. 특히 차트가 두 번째 측정만 보여준다고 설명하면서 표의 평균과 시각 자료가 어떻게 대응하는지도 결과와 함께 확인할 필요가 있습니다.

결국 지금 이 글이 뒷받침하는 결론은 ‘OpenTelemetry 비용은 언어마다 이렇다’가 아니라, 그런 비교를 위해 어떤 조건을 통제했는가에 한정됩니다. 결과 수치가 빠진 상태에서 특정 언어나 SDK를 선택하라고 권하는 것은 근거를 넘어선 주장일 겁니다. 다음에 필요한 것은 순위표보다도 추적 비율별 자원 증가량, 지연 시간 분포, 반복 측정의 편차를 포함한 결과 공개입니다. 그때야 팀은 관측 가능성의 비용을 실제 서비스 특성과 맞춰 판단할 수 있습니다.