에이전트 트레이스 샘플링: 100% 캡처가 더 이상 가치가 없을 때

도서: LLM Observability Pocket Guide: Picking the Right Tracing & Evals Tools for Your Team (저자 본인) 또한 저서: Thinking in Go (2부작 시리즈) — Complete Guide to Go Programming + Hexagonal Architecture in Go 제 프로젝트: Hermes IDE | GitHub — Claude Code 및 기타 AI 코딩 도구로 배포하는 개발자를 위한 IDE 저: xgabriel.com | GitHub

에이전트를 배포합니다. 트래픽이 증가합니다. 첫 주 동안 Honeycomb에서 트레이스가 멋지게 보입니다. 매 턴(turn), 모든 도구 호출(tool call), 모든 토큰이 무언가 문제가 생겼을 때 검토할 수 있도록 남아 있습니다. 그러다가 청구서가 도착하고 트레이스 저장 공간 라인이 추론(inference) 라인보다 더 커집니다. 뒤따르는 질문은 금요일에 아무도 대답하고 싶어 하지 않는 질문입니다: 무엇을 버릴 것이며, 실제로 필요한 트레이스를 잃지 않으면서 어떻게 버릴까요? 솔직한 대답은 에이전트 플릿(agent fleet)의 100% 캡처가 놀라울 정도로 일찍 가치가 없어진다는 것입니다. 트레이스는 여전히 도구 호출 루프를 디버깅할 수 있게 해주는 유일한 방법입니다. 문제는 트레이스의 가치가 매우 불균형하다는 것입니다. 올바른 답변을 반환하는 깨끗한 3초짜리 턴은 통계적 채움(statistical filler)에 불과합니다. 11개의 도구 호출을 실행하고 MAX_TOKENS로 끝난 47초짜리 턴은 금광입니다. 둘 다에 전액을 지불하면, 필요한 흥미로운 트레이스에 필요한 예산을 지루한 트레이스로 보조하는 셈이 됩니다. 이 게시물은 그 비율을 맞추기 위한 수학적 계산과 OTel(OpenTelemetry) 구성 방법을 다룹니다.

왜 에이전트 트레이스가 HTTP 트레이스보다 저장 비용을 더 빠르게 증가시키는지

일반적인 HTTP 요청 트레이스는 아마도 10개의 스팬(span) 정도입니다. 요청이 들어와 핸들러에 도달하고, 데이터베이스와 통신하며, 하나의 다운스트림 서비스를 호출한 다음, 반환됩니다. Honeycomb, Datadog 등 나머지 회사들은 그 모양을 기준으로 가격 책정을 했습니다. 에이전트 턴은 그런 모양이 아닙니다. 단일 사용자 메시지 하나만으로도 다음과 같은 것을 생성할 수 있습니다:

• agent.turn 부모 스팬(parent span) 4~8개
• model.input / model.output 스팬 (루프 반복마다 하나씩) 5~30개
• tool.execute 자식 스팬(child span), 때로는 도구가 다른 도구를 호출할 때 두 단계 깊이로 중첩되기도 합니다.
• 모든 모델 스팬에 gen_ai.usage.input_tokens 속성, 종종 재생을 위해 전체 프롬프트가 스팬 이벤트로 추가됩니다.
• 모델 컨텍스트 프로토콜(Model Context Protocol, MCP) 도구 경계를 추가하면 카운트가 두 배로 늘어나는데, 모든 MCP 호출이 자체 클라이언트 + 서버 스팬 쌍이기 때문입니다.

세 개의 리포지토리에서 코드 검색을 수행하는 수다스러운 에이전트는 턴당 60~120개의 스팬 범위에 도달합니다. 이를 하루 5만 번의 턴으로 곱하면 3백만 개에서 6백만 개의 스팬이 됩니다. 아래 링크된 공개 APM 가격 페이지에서 백만개 인덱스 스팬당 낮은 한 자릿수 달러를 고려할 때, 이는 아무것도 라우팅하지 않았을 때 발생하는 실제 돈입니다.

(Datadog의 공개 APM 가격 페이지 기준 (2026-05 관찰)) 인덱스된 스팬은 대략 다음과 같습니다.