OpenTelemetry 는 애플리케이션 및 인프라에서 텔레메트리를 생성, 수집 및 내보내기 위한 오픈 소스 가시성 프레임워크입니다. 트레이스, 메트릭, 로그를 포함한 중요한 가시성 신호를 지원합니다.
최근 애플리케이션은 종종 여러 서비스, 컨테이너, 클라우드 플랫폼, 데이터베이스 및 외부 API에 걸쳐 있습니다. 문제가 발생했을 때 단일 서버 로그만으로는 무슨 일이 일어났는지 설명하기 어려울 수 있습니다. OpenTelemetry는 엔지니어들이 이러한 구성 요소 전반에서 시스템 동작을 이해하는 데 도움이 되는 공통 계측 및 텔레메트리 관행을 제공합니다.
OpenTelemetry란 무엇인가요?
일반적으로 OTel로 줄여 부르는 OpenTelemetry는 Cloud Native Computing Foundation 산하의 특정 공급업체에 종속되지 않는 가시성 프로젝트입니다. 텔레메트리 워크플로우를 위해 API, SDK, 계측, 시맨틱 컨벤션, 프로토콜 및 OpenTelemetry Collector를 제공합니다.
OpenTelemetry 자체는 완전한 모니터링 백엔드가 아닙니다. 대신 애플리케이션과 인프라가 해당 데이터를 저장, 분석, 시각화 및 경고할 수 있는 시스템으로 텔레메트리를 생성하고 전송할 수 있도록 돕습니다.
OpenTelemetry는 어떤 텔레메트리를 지원하나요?
추적 (Traces)
트레이스는 분산 시스템을 통과하는 요청의 경로를 나타냅니다. 요청이 API 게이트웨이에서 애플리케이션 서비스, 데이터베이스, 캐시 및 외부 서비스를 거쳐 이동하는 방식을 보여줄 수 있습니다.
메트릭 (Metrics)
메트릭은 시간에 따라 수집되는 수치 측정값입니다. 예시로는 요청 수, 지연 시간, 오류율, CPU 사용률 및 기타 애플리케이션 또는 인프라 측정값이 포함됩니다.
로그 (Logs)
로그는 애플리케이션과 시스템에서 생성된 이벤트의 타임스탬프 기록입니다. 트레이스 및 메트릭과 적절히 연관되면, 로그는 문제 해결 시 추가적인 컨텍스트를 제공할 수 있습니다.
OpenTelemetry가 중요한 이유
공통 계측 표준이 없으면 조직은 특정 가시성 공급업체에 강하게 결합되거나 애플리케이션마다 다른 통합 방식을 유지 관리하게 될 수 있습니다.
OpenTelemetry는 계측을 단순화하고 호환되는 백엔드로 텔레메트리를 내보낼 수 있는 공통 프레임워크를 제공합니다. 이를 통해 엔지니어링 팀은 가시성 아키텍처를 설계할 때 더 많은 유연성을 얻을 수 있습니다.
OpenTelemetry 작동 방식
- 애플리케이션 또는 인프라 구성 요소가 텔레메트리를 생성합니다.
- OpenTelemetry API 및 SDK는 계측 및 텔레메트리 처리 기능을 제공합니다.
- 텔레메트리는 OpenTelemetry Collector 또는 기타 지원되는 구성 요소에 의해 처리될 수 있습니다.
- 텔레메트리는 지원되는 프로토콜과 내보내기 도구를 사용하여 내보내집니다.
- 가시성 백엔드는 생성된 데이터를 저장하고 분석합니다.
이 아키텍처는 애플리케이션 계측 및 텔레메트리 수집을 최종적으로 데이터를 저장하고 분석하는 시스템과 분리합니다.
OpenTelemetry 아키텍처
API
OpenTelemetry API는 애플리케이션과 라이브러리가 텔레메트리를 생성하고 상호 작용하는 데 사용할 수 있는 인터페이스를 정의합니다.
SDK
SDK는 텔레메트리 생성, 처리, 내보내기를 위한 언어별 구현 및 구성을 제공합니다.
계측 (Instrumentation)
계측은 애플리케이션에 텔레메트리를 추가합니다. 개발자가 직접 계측을 추가하는 수동 방식이거나, 지원되는 라이브러리 및 프레임워크가 애플리케이션 코드 수정 없이 텔레메트리를 생성하는 자동 방식일 수 있습니다.
OpenTelemetry Collector
OpenTelemetry Collector는 텔레메트리를 수신, 처리, 내보낼 수 있는 특정 벤더에 종속되지 않는 컴포넌트입니다. 워크로드 근처에서 작동하거나 여러 애플리케이션에 서비스를 제공하는 게이트웨이로 작동할 수 있습니다.
OpenTelemetry Collector란 무엇인가요?
Collector는 애플리케이션과 관찰 가능성 백엔드 간의 텔레메트리 처리를 중앙 집중화할 수 있습니다. 파이프라인은 텔레메트리를 수신하고, 일괄 처리(배칭)나 필터링 같은 처리를 적용하며, 선택한 대상으로 데이터를 내보낼 수 있습니다.
예를 들어 조직은 Collector를 사용하여 속성을 추가하고, 원치 않는 데이터를 필터링하며, 일괄 처리를 제어하거나, 다양한 텔레메트리 신호를 다른 대상으로 라우팅할 수 있습니다. 이를 통해 애플리케이션 서비스 내부의 백엔드 종속 로직을 줄일 수 있습니다.
OpenTelemetry 대 전통적인 가시성 계측
| 영역 | OpenTelemetry | 포인트 통합 |
|---|---|---|
| 계측 (Instrumentation) | 공통 API, SDK 및 규칙 | 대개 벤더별 라이브러리 또는 에이전트 |
| 텔레메트리 라우팅 | Collector 파이프라인 및 표준화된 프로토콜 사용 가능 | 특정 백엔드로 직접 데이터 전송 가능 |
| 백엔드 유연성 | 상호 운용성을 위해 설계됨 | 더 강한 벤더 종속성 유발 가능 |
| 분산 추적 | 표준화된 추적 개념 | 구현은 플랫폼에 따라 다름 |
OpenTelemetry를 활용한 분산 추적
분산 추적은 마이크로서비스에 특히 유용합니다. 단일 요청이 여러 컴포넌트를 거칠 수 있으므로 지연 시간이나 오류가 발생하는 위치를 파악하기 어려울 수 있습니다.
OpenTelemetry는 스팬을 사용하여 추적 내의 개별 작업을 나타냅니다. 관련된 스팬은 서비스 간 작업의 순서와 지속 시간을 보여줄 수 있습니다.
추적 컨텍스트가 올바르게 전파되면 엔지니어는 프로세스 및 네트워크 경계를 넘어 요청을 추적할 수 있습니다.
OpenTelemetry와 마이크로서비스
마이크로서비스는 API, 메시징 시스템, 데이터베이스 및 기타 프로토콜을 통해 통신합니다. 이 아키텍처는 배포 유연성을 제공할 수 있지만 문제 해결을 더 어렵게 만들 수도 있습니다.
OpenTelemetry는 서비스 전반에 걸쳐 일관된 텔레메트리를 제공할 수 있습니다. 공통 속성과 추적 컨텍스트는 서비스 경계를 넘어 요청, 작업, 실패를 연결하는 데 도움이 될 수 있습니다.
OpenTelemetry 시맨틱 컨벤션
의의적 규칙은 일반적으로 기록되는 텔레메트리 속성에 대해 표준화된 이름과 의미를 정의합니다. 일관된 규칙을 사용하면 애플리케이션과 서비스 간에 텔레메트리를 더 쉽게 쿼리하고 비교할 수 있습니다.
이러한 규칙은 HTTP, 데이터베이스, 메시징 시스템, 서비스 리소스와 같은 일반적인 기술 및 작업을 다룰 수 있습니다.
자동 계측 대 수동 계측
자동 계측 은 애플리케이션 코드를 비교적 적게 수정하면서 지원되는 라이브러리 및 프레임워크에 대한 텔레메트리를 생성할 수 있습니다. 넓은 커버리지를 빠르게 확보하는 데 유용합니다.
수동 계측 을 통해 개발자는 자동 계측이 이해하지 못할 수 있는 애플리케이션 특정 스팬, 메트릭, 속성을 추가할 수 있습니다.
많은 성숙한 가시성(Observability) 구현체는 두 가지 접근 방식을 모두 사용합니다. 즉, 일반적인 프레임워크에는 자동 계측을 사용하고 중요한 애플리케이션 작업에는 수동 계측을 사용합니다.
OpenTelemetry의 이점
- 벤더 중립성: 텔레메트리는 호환되는 가시성 시스템으로 내보낼 수 있습니다.
- 표준화: 공통 API와 규칙은 단편화된 계측을 줄여줍니다.
- 분산 추적: 팀이 여러 서비스에 걸쳐 요청을 추적할 수 있습니다.
- 유연한 수집: Collector를 사용하여 텔레메트리를 처리하고 라우팅할 수 있습니다.
- 개방형 생태계: 이 프로젝트는 광범위한 커뮤니티와 업계의 참여를 받고 있습니다.
- 신호 상관관계: 메트릭, 로그, 트레이스를 통해 시스템 동작에 대한 더 연결된 뷰를 제공할 수 있습니다.
OpenTelemetry와 가시성 백엔드
OpenTelemetry는 반드시 텔레메트리를 분석하는 데 사용되는 데이터베이스나 대시보드일 필요는 없습니다. 대신 텔레메트리는 호환되는 백엔드로 내보낼 수 있습니다.
백엔드를 선택할 때 팀은 스토리지, 쿼리 기능, 알림, 보존 기간, 비용, 보안, 시각화를 평가해야 합니다. OpenTelemetry는 애플리케이션 계측 결정과 백엔드 선택을 분리하는 데 도움을 줄 수 있습니다.
성능 및 비용 고려 사항
가시성 데이터는 CPU, 메모리, 네트워크 대역폭, 스토리지를 소비합니다. 가능한 모든 이벤트를 최대 세부 정보로 수집하면 비용이 많이 들 수 있으며 중요한 신호를 식별하기 어려워질 수 있습니다.
팀은 적절한 샘플링, 필터링, 보존, 속성 정책을 수립해야 합니다. 또한 보안 및 개인정보 보호 요구 사항에 따라 민감한 정보는 제외되거나 보호되어야 합니다.
OpenTelemetry 보안 및 개인정보 보호
텔레메트리에는 민감한 정보가 포함될 수 있습니다. 계측이 잘못 설계된 경우 요청 속성, URL, 사용자 식별자, 데이터베이스 문, 로그 메시지에 기밀 정보가 노출될 수 있습니다.
- 수집되는 속성을 검토하세요.
- 자격 증명이나 보안 비밀을 텔레메트리에 절대 넣지 마세요.
- 가시성 시스템에 접근 제어를 적용하세요.
- 적절한 경우 전송 중인 텔레메트리를 보호하세요.
- 텔레메트리 데이터에 대한 보관 정책을 정의하세요.
- 민감한 값을 필터링하거나 마스킹하세요.
- 타사 Exporter 및 백엔드 연동을 검토하세요.
OpenTelemetry 시작하는 방법
- 더 나은 가시성이 필요한 애플리케이션과 서비스를 식별하세요.
- 적절한 OpenTelemetry 언어 SDK 또는 계측 방식을 선택하세요.
- 가치가 높은 서비스와 신호부터 시작하세요.
- 일관된 리소스 속성과 시맨틱 컨벤션을 사용하세요.
- 중앙 집중식 처리가 유용한 경우 OpenTelemetry Collector를 배포하세요.
- 호환되는 백엔드로 텔레메트리를 내보내세요.
- 서비스 간 추적 컨텍스트 전파를 검증하세요.
- 텔레메트리 품질, 볼륨, 비용, 유용성을 측정하세요.
전문가의 팁
- 모든 것을 한 번에 계측하는 대신 중요한 몇 개의 서비스부터 시작하세요.
- 일관된 서비스 이름과 리소스 속성을 사용하세요.
- 자동 계측과 대상 지정 수동 계측을 결합하세요.
- 대용량 시스템의 경우 신중하게 트레이스 샘플링을 사용하세요.
- 텔레메트리에 민감한 정보가 포함되지 않도록 하세요.
- 데이터 누락 및 리소스 사용량에 대해 텔레메트리 파이프라인 자체를 모니터링하세요.
- Define retention and cost controls before telemetry volume grows significantly.
흔히 하는 OpenTelemetry 실수
- Assuming OpenTelemetry is a complete observability backend.
- Collecting excessive telemetry without cost or retention controls.
- Using inconsistent service names and attributes.
- Ignoring trace-context propagation between services.
- Exposing sensitive information through logs or span attributes.
- Relying entirely on automatic instrumentation for application-specific behavior.
- Failing to monitor the Collector and telemetry pipeline.
자주 묻는 질문
OpenTelemetry란 무엇인가요?
OpenTelemetry is an open-source framework for generating, collecting, and exporting telemetry such as traces, metrics, and logs.
OpenTelemetry는 모니터링 도구인가요?
OpenTelemetry is primarily an observability framework and telemetry ecosystem. It typically sends telemetry to another backend for storage, querying, visualization, and alerting.
OpenTelemetry의 주요 신호는 무엇인가요?
The commonly used signals are traces, metrics, and logs. The project also has ecosystem support for related observability data as its capabilities evolve.
OpenTelemetry Collector란 무엇인가요?
The Collector is a vendor-neutral component that can receive, process, and export telemetry between applications and observability backends.
OpenTelemetry가 Prometheus를 대체하나요?
Not necessarily. OpenTelemetry and Prometheus have different architectures and roles, although their metrics capabilities can overlap. OpenTelemetry can collect and export metrics to compatible systems.
OpenTelemetry는 쿠버네티스와 함께 작동하나요?
Yes. OpenTelemetry can be deployed in Kubernetes environments to collect application and infrastructure telemetry, including through the OpenTelemetry Collector.
OpenTelemetry는 특정 공급업체에 종속되지 않나요?
Yes. Vendor neutrality and interoperability are central goals of the project, although the final backend and exporter choices still affect an organization’s architecture.
초보자가 OpenTelemetry를 배워야 할까요?
It is useful for engineers working with distributed applications, cloud infrastructure, microservices, or modern observability. Beginners should first understand basic monitoring and telemetry concepts.
결론
OpenTelemetry provides a common foundation for instrumenting applications and collecting telemetry across modern distributed systems. Its APIs, SDKs, semantic conventions, and Collector can help teams build more consistent and portable observability pipelines.
The best results come from purposeful instrumentation. Teams should collect signals that answer operational questions, protect sensitive information, control telemetry costs, and connect metrics, logs, and traces into a coherent view of application behavior.
Continue the technology series: next is Application Observability, which focuses on understanding application health and behavior through telemetry and actionable operational insights.
