관측 가능성은 더 이상 사이트 신뢰성 팀만의 책임이 아니다. 개발자는 장애를 진단하고 애플리케이션이 프로덕션에 배포되기 전후의 동작을 이해할 수 있도록 자신이 작성하는 코드에 traces, logs, metrics를 점점 더 추가해야 한다. 2026년 8월 25일 CNCF 블로그에 게시된 글에서 OpenTelemetry 커뮤니티 매니저이자 CNCF 앰배서더인 Adriana Villela와 OpenTelemetry 문서화 기여자이자 CNCF 앰배서더인 Diana Todea는 OpenTelemetry를 사용해 이 작업의 부담을 줄이는 실용적인 경로를 제시한다.
두 저자는 개발자들이 흔히 제기하는 اعتراض에서 출발한다. Instrumentation을 추가하면 유지 관리해야 할 코드가 늘어나고, 복잡성이 증가하며, 오류나 기술 부채가 발생할 가능성이 있다는 것이다. 그러나 두 저자는 이러한 비용이 직접적인 실무적 이점과 연결된다고 설명한다. 주요 이점으로는 디버깅 시간 단축, 기능 완료 및 배포 가속화, 느린 경로와 드러나지 않는 재시도 및 엣지 케이스 발견, 분산 시스템에 대한 이해 개선이 있다. 또한 관측 가능성은 품질이 고르지 않을 수 있는 인공지능 지원 도구로 생성된 애플리케이션을 분해하는 데도 도움이 된다고 본다.
자동화로 시작한 뒤 부족한 부분을 추가하라
첫 번째 권고는 가능할 때 Zero-code instrumentation을 사용하는 것이다. 이 방식은 소스 코드를 수정하지 않고 런타임 또는 컴파일 시점에 일반적인 프레임워크와 라이브러리 호출을 가로채 애플리케이션에 Instrumentation을 추가한다. 글에 따르면 이러한 지원은 Java, .NET, Python, JavaScript, PHP, Go 언어에서 제공된다.
두 저자는 자동화가 완전한 해결책은 아니라고 말한다. 자동화는 애플리케이션 로직 자체에서 무엇이 중요한지 반드시 알 수 있는 것은 아니기 때문이다. 따라서 traces, metrics, logs, 컨텍스트 전파, 코드에 특화된 속성을 추가하려면 이를 Manual instrumentation으로 보완해야 한다. 또한 새 코드를 작성하는 동안 관측 가능성을 추가하는 Observability-driven development를 실천하라고 제안한다. 며칠이 지나 설계 세부 사항이 개발자의 기억에서 희미해진 뒤 다시 작업하는 것보다 낫다는 의미다.
무엇을 측정할 가치가 있는가?
- 중요한 작업 단위: HTTP 호출과 같은 수신 요청, 데이터베이스·캐시·API·Queues로의 발신 연결, 그리고 비즈니스상 민감한 작업에 spans를 추가하라. 글은 모든 작은 호출마다 span을 만들면 중요한 신호를 가리는 잡음이 발생할 수 있다고 경고한다.
- 영향을 미치는 이벤트: 특정 일이 발생한 이유를 설명하기 위해 로그를 사용하라. 오류, 검증 실패, 재시도 및 대체 경로, 인증 실패와 권한 거부 같은 보안 이벤트에 집중해야 한다.
- 응답 시간: 지연 시간 측정값은 특정 요청이 평소보다 오래 걸리는 이유를 파악하는 데 도움이 된다. 특히 장바구니에 상품을 추가한 뒤 결제하는 것처럼 여러 단계로 구성된 경로에서 유용하다.
- 내부 프레임워크와 라이브러리: 팀이 직접 개발한 프레임워크와 라이브러리에 Instrumentation을 적용하면 애플리케이션의 많은 부분이 이를 거치므로 광범위한 커버리지를 제공할 수 있다.
인공지능을 검토의 대체물이 아닌 보조자로 사용하라
두 저자는 인공지능 기반 프로그래밍 도구가 다양한 OpenTelemetry 인터페이스와 SDK를 탐색하는 시간을 줄이고 레거시 코드를 다루는 데도 도움을 줄 수 있다고 본다. 그러나 이를 활용하려면 정확한 지시가 필요하다. 보조자의 역할, 목표, 코드 위치와 사용 언어, 필요한 출력 결과를 명시하고 관련 문서 링크나 코드 예제를 함께 제공하라고 제안한다.
또한 에이전트에게 자신의 결정을 설명하도록 요청하고, 가능하다면 다른 에이전트를 심판으로 사용해 해당 결정을 검토하게 하며, 도구가 제안한 첫 번째 수정안을 그대로 받아들이기보다 반복해서 시도하고 결과를 개선하라고 권고한다. 이러한 권고는 두 저자의 견해와 경험을 반영한 것이며, 인공지능이 생성한 코드가 정확하거나 애플리케이션에 적합하다는 보장은 아니다.
측정 데이터를 이해하기 위한 로컬 경로
생성된 데이터를 읽을 방법이 없으면 Instrumentation은 완성되지 않는다. 글은 OpenTelemetry Collector가 벤더 중립적인 에이전트로 작동한다고 설명한다. 여러 소스에서 traces, logs, metrics를 수신하고 필요할 때 처리한 뒤 하나 이상의 대상으로 전송한다. Collector는 데이터를 수신하는 Receivers, 속성을 수정·숨김 처리하거나 샘플링하는 Processors, 데이터를 전송하는 Exporters, 각 신호 유형의 경로를 지정하는 Pipelines, 그리고 두 파이프라인을 연결하는 Connectors로 구성된다.
개발 목적을 위해 글은 OTLP를 통해 gRPC 또는 HTTP로 데이터를 수신하고 Debug 모듈로 내보내는 간단한 설정을 제안한다. 또한 SpanMetrics Connector를 사용해 span 지속 시간을 metrics 데이터로 변환하면 지연 문제를 모니터링하는 데 도움이 된다. 이어 Collector 및 Docker Compose와 함께 실행할 수 있는 세 가지 오픈 소스 도구를 소개한다. OTel Desktop Viewer는 traces를 표시하고, otel-tui는 터미널 인터페이스에서 traces, logs, metrics와 서비스 관계를 표시하며, OTel Front는 대시보드와 함께 동일한 세 가지 유형을 표시한다.
고려해야 할 제약
이 경험은 이러한 도구에 장애물이 없지 않다는 점을 보여준다. 두 저자는 OpenTelemetry Collector와 Docker를 이전에 사용한 경험 덕분에 설정이 더 쉬웠지만, 초보자는 더 큰 어려움을 겪을 수 있다. 또한 도구가 제3자 오픈 소스 프로젝트에 의존하므로 최신 OpenTelemetry API 및 SDK 버전을 항상 따라가지 못하거나 기능 면에서 완전한 동등성을 제공하지 못할 수 있다.
글은 생태계 전반의 더 광범위한 과제도 강조한다. 언어별 특별 관심 그룹의 활동 수준 차이, Rust와 Elixir 같은 일부 언어에서 자동화가 제공되지 않는 문제, SDK와 eBPF 및 컴파일 시점 Instrumentation 사이에서 선택해야 하는 수많은 옵션, API 안정성 문제, 의존성 업그레이드 문제, 일부 속성에서 Cardinality가 높아지는 문제가 이에 해당한다.
편집자 해설: 여기서 실용적인 가치는 새로운 도구를 추가하는 데 있지 않다. 관측 가능성을 미뤄 둔 작업에서 코드 개발 주기의 일부로 전환하는 데 있다. 이 가이드는 마찰이 적은 시작점을 제시한 뒤 자동화가 알 수 없는 부분에 명확한 한계를 설정한다. 그러나 원문은 도구 간 정량적인 성능 비교를 제공하지 않으며, 하나의 경로가 모든 언어나 환경에 적합하다는 사실도 입증하지 않는다. 따라서 권고를 시작을 위한 프레임워크로 받아들이고, 설정과 데이터 규모 및 비용, 실제 애플리케이션에 대한 적합성을 테스트하고 검토해야 한다.