
OpenTelemetry 공식 블로그에 따르면 프로젝트는 16일 Go 애플리케이션을 빌드 단계에서 계측하는 ‘OpenTelemetry Go Compile-Time Instrumentation’의 첫 안정판을 공개했다. 다만 GitHub 릴리스 기록상 최초 v1.0.0은 모듈 경로를 잘못 기록하는 오류로 철회됐으며, 현재 권장 버전은 수정판 v1.0.1이다.
Go는 코드를 단일 정적 바이너리로 컴파일하기 때문에 Java나 Python, Node.js처럼 프로그램 시작 시 에이전트를 붙이는 자동 계측 방식에 제약이 있었다. 새 도구는 Go 표준 툴체인의 `-toolexec` 기능을 이용해 애플리케이션 코드와 의존성, 표준 라이브러리가 컴파일될 때 OpenTelemetry 계측 코드를 주입한다. 실행 시 별도 에이전트를 붙이지 않는 구조다.
프로젝트가 제공하는 명령줄 도구 `otelc`는 기존 `go build` 명령을 감싼다. 개발자는 빌드 명령을 `otelc go build`로 바꿔 계측을 적용할 수 있다. 기본적으로 모듈에서 지원 라이브러리를 찾아 자동으로 처리하며, 컨테이너 빌드나 CI·CD 파이프라인에도 같은 방식을 적용할 수 있다는 설명이다.
안정판은 `net/http`, `database/sql`, gRPC, Redis와 Go 런타임 메트릭을 지원한다. v1 릴리스에는 MongoDB와 Gin, OpenAI Go SDK, Kafka, Kubernetes client-go informer, `slog`·Logrus용 계측도 포함됐다. 자체 규칙을 추가해 지원 범위를 넓힐 수 있고, 수집되는 텔레메트리는 OpenTelemetry 의미 규칙을 따른다.
컴파일타임 계측은 소스코드를 직접 수정하지 않으면서 애플리케이션을 다시 빌드할 수 있는 환경에 맞는다. 이미 배포된 바이너리를 다시 만들기 어렵다면 프로세스 밖에서 동작하는 eBPF 계측이 대안이 될 수 있고, 업무 의미가 담긴 사용자 정의 스팬이 필요하면 Go API를 이용한 수동 계측을 함께 적용할 수 있다. OpenTelemetry는 세 방식을 서로 보완하는 선택지로 제시했다.
배포 과정에서는 버전 확인이 필요하다. GitHub 릴리스 노트에 따르면 v1.0.0의 `otelc pin` 명령은 사용자의 `go.mod` 파일에 잘못된 모듈 경로를 기록했다. v1.0.1은 이를 `go.opentelemetry.io/otelc` 경로로 바로잡고 v1.0.0을 모듈에서 철회 처리했다. 프로젝트는 v1.0.0 사용자에게 v1.0.1로 올리라고 안내한다.
첫 안정판이라는 점이 모든 Go 라이브러리에 대한 계측 완성을 뜻하지는 않는다. OpenTelemetry는 현재 지원 범위를 핵심 라이브러리 중심이라고 설명하고, 향후 지원 대상 확대와 레지스트리 기반 배포, 빌드·실행 비용 개선을 과제로 제시했다. 실제 도입 조직은 사용하는 라이브러리의 지원 여부와 빌드 시간, 텔레메트리 수집 비용을 자체 환경에서 확인할 필요가 있다.
이 프로젝트는 2025년 Alibaba와 Datadog이 각각 추진하던 접근을 하나의 벤더 중립 프로젝트로 모으면서 출발했다. 안정판 공개로 Go 서비스도 수동 계측과 eBPF 외에 빌드 단계 자동 계측을 정식 선택지로 검토할 수 있게 됐다.
출처: OpenTelemetry 공식 블로그 https://opentelemetry.io/blog/2026/go-compile-time-instrumentation-v1/
출처: OpenTelemetry Go Compile-Time Instrumentation v1.0.1 릴리스 https://github.com/open-telemetry/opentelemetry-go-compile-instrumentation/releases/tag/v1.0.1
출처: OpenTelemetry Go Compile-Time Instrumentation v1.0.0 릴리스 https://github.com/open-telemetry/opentelemetry-go-compile-instrumentation/releases/tag/v1.0.0