APM 도구 비교: 추적 범위와 실제 운영 비용으로 고르기

느린 요청은 애플리케이션 코드에서 시간을 쓰거나, 하위 서비스를 기다리거나, 과부하가 걸린 호스트의 영향을 받을 수 있습니다. 서비스 맵은 요청이 어디를 지났는지 보여 주지만, 시간이 왜 걸렸는지까지 설명하지는 않습니다. 관련 로그, 컨테이너 지표, 사용자 세션을 찾아 같은 요청과 시간 범위로 맞추는 작업이 뒤따릅니다.

APM 도구를 고를 때는 이 조사 경로를 따라가 보겠습니다. 어떤 작업이 기록되고, 무엇이 샘플링으로 빠지며, 언제까지 보관되는지부터 봅니다. 기존 SkyWalking, Jaeger나 클라우드 서비스로 이미 답을 찾을 수 있다면 그 투자를 유지할 수 있습니다. 반복해서 부족한 맥락을 채우거나 팀이 더는 운영하고 싶지 않은 백엔드를 맡길 수 있을 때 변경할 이유가 생깁니다.

Guance 편집팀 · 2026년 10월 28일. 공식 문서에 근거해 기술적 작동 방식과 운영 책임을 비교합니다. 발행사인 Guance도 후보에 포함되며, 동일 부하 성능 시험이나 고객 비용 실측은 수행하지 않았습니다.

빠진 Span이 어디에서 사라졌는지 먼저 찾기

분산 추적은 계측된 작업을 Span으로 기록하고 전파된 컨텍스트로 연결합니다. APM은 이 기록과 다른 텔레메트리를 바탕으로 요청량, 오류, 지연 시간, 의존성을 분석합니다. 서비스가 맵에 표시된다고 모든 호출의 완전한 Trace를 나중에 조회할 수 있는 것은 아닙니다. 기본 개념은 APM의 의미에서 다루며, 여기서는 조사에 필요한 기록에 집중합니다.

동기 HTTP 호출도 호출 측의 컨텍스트 주입, 게이트웨이의 헤더 보존, 수신 측의 추출이 맞아야 이어집니다. 큐나 다른 스레드로 넘어가는 작업에는 해당 계측이나 명시적인 전달이 필요합니다. W3C Trace Context의 traceparent는 trace ID와 부모 Span 정보 등을 전달합니다. 양쪽에 같은 service.name을 붙이는 것만으로는 이런 인과관계가 생기지 않습니다. OpenTelemetry 컨텍스트 전파

자동 계측은 지원하는 라이브러리와 런타임의 수집 코드를 줄여 줍니다. 업무 고유의 단계에는 사용자 정의 Span이나 속성이 여전히 필요할 수 있습니다. eBPF의 관측 범위도 커널, 프로토콜, 구현에 달려 있습니다. 네트워크 연결을 봤다고 결제가 세 번 재시도된 이유까지 알 수는 없습니다. 코드 프로파일링은 실행 지점에 대한 또 다른 기록이므로 지원 언어, 수집 경로, 제품 범위를 따로 봐야 합니다.

전파나 계측의 빈틈부터 고치면 백엔드에 요구할 범위가 분명해집니다. 같은 불완전한 기록을 다른 곳으로 보내도 기록되지 않은 작업은 돌아오지 않습니다.

샘플링은 남는 증거와 비용이 줄어드는 위치를 바꾼다

헤드 샘플링은 요청 초기에 적은 상태로 결정하지만 요청이 나중에 실패할지는 알 수 없습니다. 테일 샘플링은 받은 Span의 오류, 소요 시간, 속성을 사용할 수 있는 대신 데이터 수신과 상태 유지가 필요합니다. OpenTelemetry Collector의 tail sampling processor는 같은 Trace의 Span이 같은 샘플링 인스턴스에 도착해야 합니다. 여러 복제본에 임의로 분산하면 각 결정에 필요한 근거가 나뉩니다. 샘플링 개념 · Collector 테일 샘플링

초당 요청이 항상 100건이고, 요청마다 정확히 20개 Span을 만들며, Trace 단위로 일관된 10% 확률 샘플링을 한다고 가정해 봅시다. 재시도, 유실, 지연 도착을 제외한 계산입니다.

샘플링 전: 100 × 20 × 86,400 = 172,800,000 Span/일
샘플링 후 기대값: 172,800,000 × 10% = 17,280,000 Span/일

고정 부하를 가정한 산술 예시이며 실제 트래픽이나 청구 시험 결과가 아닙니다. 속성과 이벤트에 따라 Span 크기가 달라져 개수를 GB로 바로 바꿀 수 없고, 최대 부하 용량도 따로 계산해야 합니다. 애플리케이션이 먼저 90%를 버리면 하위 테일 샘플러는 도착한 나머지 중에서만 선택할 수 있습니다. 모든 실패 요청을 남긴다고 보장할 수 없습니다. 전부 원격 샘플러에 보낸 뒤 걸러도 그 앞단의 전송과 수신 비용은 이미 발생합니다.

오류율의 분모도 함께 유지해야 합니다. 샘플링 전에 SDK나 Agent에서 만든 요청 지표와, 선택된 Span으로 만든 지표는 서로 다른 모집단을 나타낼 수 있습니다. 이전 후 오류 수가 줄었다면 먼저 지표 생성과 샘플링 위치를 봐야 합니다. Datadog도 OTel 구성별 Trace Metrics의 전제를 문서화합니다. 특정 Agent 경로의 전체 트래픽 집계를 모든 OTLP 경로에 적용할 수는 없습니다. Datadog OTel 호환 범위

기존 계측을 유지하면서 백엔드가 맡을 일 구분하기

OpenTelemetry는 계측과 전송의 이동성을 높입니다. 각 백엔드의 집계, 프로파일링, 서비스 검색, 권한 모델을 같게 만드는 기능은 아닙니다. 어떤 기반을 재사용하고 어떤 작업이 남는지 나누면 선택하기 쉬워집니다.

Guance의 DataKit OTel 문서에는 이런 차이가 실제 엔드포인트로 나타납니다. gRPC의 기본 리스너는 127.0.0.1:4317이고 HTTP/Protobuf Trace의 기본 경로는 :9529/otel/v1/traces입니다. 애플리케이션의 프로토콜과 주소를 실제 리스너 설정에 맞춰야 합니다. Java Agent 2.x는 기본으로 HTTP/Protobuf를 사용하므로 gRPC용 주소를 그대로 쓸 수는 없습니다. 기존 SkyWalking, Jaeger, Zipkin 계측도 해당 프로토콜과 버전에 맞춰 연결하고 쿼리, 알림, 샘플링 정책을 별도로 옮깁니다.

상용 제품도 수집 경로에 따라 봐야 합니다. Datadog은 공급자 SDK, OTel SDK, Collector, 직접 OTLP 구성의 기능 차이를 설명합니다. New Relic은 네이티브 OTLP 엔드포인트를 제공하며, Dynatrace는 Full-Stack과 독립 텔레메트리의 범위 및 계량을 구분합니다. 자체 추적기 데이터만 받는 제품으로 묶어서도 안 되고, 수집 성공을 모든 고급 기능의 동일한 지원으로 해석해서도 안 됩니다.

자체 운영 제품의 범위도 다릅니다. SkyWalking은 여러 관측·분석 기능을 포함합니다. Jaeger와 Tempo는 각자 지원하는 Trace 저장소를 사용하고 팀이 필요한 다른 신호와 연결해야 합니다. Thanos와 Cortex는 메트릭 시스템으로 범용 Trace 저장소를 대신하지 않습니다. 기존 소프트웨어 기능을 새로 개발할 필요는 없지만 운영 배포와 복구는 누군가가 맡아야 합니다.

클라우드 기본 서비스도 유지할 수 있습니다. Alibaba Cloud ARMS, AWS, Azure의 런타임과 제품 범위는 각각 다릅니다. Azure Application Insights에는 지원하는 OTel 경로가 있으며 클라우드 간 연결은 전파와 수집에 달려 있습니다. AWS는 X-Ray SDK와 daemon 계측을 OpenTelemetry로 옮기도록 권장합니다. 수집 구성 요소의 유지보수 변화이며 X-Ray 서비스 전체가 중단되었다는 뜻은 아닙니다. AWS 지원 일정

Trace에서 로그와 사용자 요청까지 같은 작업을 따라가기

느린 요청에서 관련 로그를 여는 편이 서비스명을 다시 검색하는 것보다 편합니다. Guance의 Trace 상세는 trace_id로 로그를 연결하고 service, env, version 등의 필드로 로그 인덱스 매핑을 선택합니다. 호스트, 컨테이너, Pod 정보에는 관련 식별자와 이미 수집된 데이터도 필요합니다. 업무 설정을 맞춘 뒤 관리형 플랫폼이 조회와 관련 화면을 제공하면 별도의 상관분석 백엔드를 먼저 구축하는 일을 줄일 수 있습니다. Trace 상세와 관련 분석

로그는 30일, Trace는 7일 보관하는 예를 생각해 봅시다. 8일째 로그에서 trace ID를 읽을 수 있어도 원래 Trace는 사라졌을 수 있습니다. 제품 기본값이 아니라 보관 기간 차이를 보여 주는 예입니다. 함께 조사하는 신호는 필요한 기간을 맞추고 권한과 인덱스 선택도 일치시켜야 합니다.

브라우저에는 전파 단계가 하나 더 있습니다. Guance Web SDK는 allowedTracingUrls로 Trace Header를 넣을 요청을, traceType으로 전파 형식을 선택합니다. 백엔드가 컨텍스트를 이어받아야 하고 교차 출처 API는 CORS로 해당 헤더를 허용해야 합니다. RUM 세션과 백엔드 Trace의 샘플링은 각각 기록의 존재 여부를 바꿉니다. allowTraceHeaderWithoutSession으로 일반 세션이 샘플링되지 않았을 때도 헤더를 보낼 수 있지만, 빠진 RUM 세션 기록을 만드는 것은 아닙니다. Web SDK 추적 설정

서비스명, 컨텍스트 전파, 업무 속성은 애플리케이션 팀의 일로 남습니다. 관리형 서비스는 백엔드 운영과 문서화된 분석 기능을 맡습니다. AI가 기존 근거를 읽는 데 도움을 줄 수는 있어도 없거나 만료된 Span을 복원하지는 못합니다.

남겨 둔 데이터와 운영 책임을 같은 범위로 계산하기

APM 도구마다 하나의 애플리케이션을 청구서로 바꾸는 방식이 다릅니다. Datadog의 호스트 기반 APM은 수집 GB, 인덱싱 Span, 관련 기능, 초과 사용을 구분합니다. Dynatrace Full-Stack의 공개 단위는 메모리 GiB-hour이며 로그, RUM, 추가 텔레메트리는 해당 기능 기준으로 계산합니다. New Relic에는 데이터와 사용자 기반 방식, 해당 계약의 Full Consumption이 있고 추가 컴퓨팅 기능도 총액에 영향을 줍니다. Datadog 가격 · Dynatrace 가격 · New Relic 가격

Grafana Cloud의 Trace 서비스와 Application Observability도 구분해야 합니다. 후자는 host-hours와 해당 데이터 조건이 있어 Tempo 데이터량만으로 전체 견적을 낼 수 없습니다. Elastic은 Serverless, Hosted, 자체 운영을 나누고 수신·처리 경로가 필요한 APM 화면을 지원하는지도 봅니다. Grafana 애플리케이션 관측 계량 · Elastic OTel 아키텍처

Guance Enterprise는 압축 후 쓰기 바이트, 처리 대상 원래 데이터량, 저장, 작업, 선택한 컴퓨팅을 구분합니다. Span 수는 수집 규모를 설명하지만 청구서의 유일한 단위는 아닙니다. Commercial, Enterprise, 프라이빗 배포도 각각 같은 범위의 견적이 필요합니다. Enterprise 계량

요청량, Span 분포, 샘플링 위치, 보관 기간, 필요한 로그와 RUM을 먼저 맞춘 다음 서비스 비용, 고객 측 수집 리소스, 지속적인 엔지니어링 작업을 나눕니다. 일회성 이전과 병행 운영은 별도로 계산하며 이미 지출한 구축 비용을 미래 지출에 다시 더하지 않습니다. exporter 목적지 하나를 바꾸는 것은 보통 경로 전환입니다. 두 곳에 동시에 보내려면 수집 경로가 지원하는 복제 방식과 추가 부하·요금을 고려해야 합니다.

데이터 위치도 실제 배포 기준으로 판단합니다. SaaS 사이트, 프라이빗 배포, 원격 접근, 외부 처리가 실제 데이터 흐름을 만듭니다. 공급자의 국적만으로 설정과 계약의 적합성이 정해지지는 않습니다.

기존 추적으로 일상적인 조사를 할 수 있다면 유지하면서 전파와 상관관계의 빈틈부터 고칩니다. 신호 간 조사나 백엔드 유지보수의 반복 작업을 줄이고 싶을 때 Guance 같은 관리형 플랫폼이 맡을 수 있는 범위를 비교합니다. 성숙한 플랫폼 팀이 기반 리소스를 직접 제어해야 한다면 자체 운영을 이어 갈 수 있습니다. 남길 수 있는 조사 기능, 종료할 수 있는 기존 구성 요소, 계속 발생할 비용이 구매 범위를 결정해야 합니다.