TL;DR
작성자는 OpenInference 형식의 JSONL 로그를 입력으로 받아 서브에이전트별로 llm.cost.total을 합산하고 비용 기준으로 정렬하는 CLI 스크립트를 공개했다. 스크립트는 접두사 매칭으로 반복되는 컨텍스트 블록을 찾아 불필요 토큰을 표시하고 토큰 카운팅은 추정법으로 계산하는 처리 흐름을 사용한다. 현재 한 건의 LangGraph 런에서만 테스트되었고 접두사 매칭, 추정 토큰 계산, 2개의 하드코드 비용 단가라는 한계가 있어 실제 운영에서 정확도 보완이 필요하다는 점이 확인됐다.
주요 논점
token-trace-viewer는 OpenInference JSONL을 직접 파싱해 서브에이전트별로 llm.cost.total을 합산하고 비용 순위를 매기는 처리 흐름을 구현했다. 이 구현은 agent.name 필드를 키로 사용해 각 서브에이전트의 토큰·비용 사용량을 집계하고 반복되는 컨텍스트를 접두사 매칭으로 탐지하는 방식으로 동작한다. 결과적으로 제품형 관찰성 도구들이 놓치는 서브에이전트 수준의 비용 가시성을 확보할 수 있음이 확인됐다.
스크립트는 유용한 프로토타입이지만 현재 토큰 카운팅을 실제 토크나이저가 아닌 추정법으로 수행하고 있다. 접두사 매칭과 2개의 하드코드된 비용 설정은 실제 환경에서 오차를 유발할 수 있으며 확장성을 제한한다. 따라서 본 구현은 개념 증명으로 가치를 가지지만 정확한 계측과 더 많은 실험 데이터가 필요함이 확인됐다.
일부 관찰성 플랫폼은 대시보드와 집계 기능으로 충분한 통찰을 제공하기 때문에 별도 스크립트가 항상 필요하지 않을 수 있다. 게시물에서는 LangSmith와 Langfuse가 다수 런 대시보드를 제공한다고 기술됐고 Helicone와 Phoenix도 각자 가능한 분석 경로가 있다고 명시됐다. 따라서 추가 도구의 가치는 사용자의 워크플로와 태깅 수준에 따라 제한될 수 있음이 확인됐다.
합의점 vs 논쟁점
합의점
- 로그 표준이 정비되면 서브에이전트별 비용 집계가 가능하다는 점에서 OpenInference 필드 구성이 유용하다는 점이 합의됐다.
- 제품형 관찰성 도구들은 대시보드나 질의 기반 접근을 통해 비슷한 정보를 제공할 수 있으나 단일 실행에서의 서브에이전트 수준 가시성은 자동으로 제공되지 않는 경우가 많음이 인정됐다.
논쟁점
- 어떤 플랫폼이 서브에이전트별 비용 분석을 가장 잘 지원하는지에 대한 평가는 도구의 태깅, 스팬 모델링, 사용자 요구에 따라 엇갈린다는 점이 논쟁의 핵심으로 남아있다. 일부는 LangSmith/Langfuse의 대시보드 집계만으로 충분하다고 보았고 다른 일부는 OpenInference처럼 표준화된 로그 필드 기반 접근이 더 정확하다고 주장했다. 이로 인해 사용자가 직접 로그를 파싱하는 자체 도구 개발이 유효한지에 대한 의견 차이가 존재함이 확인됐다.
실용적 조언
- OpenInference 형식의 JSONL을 표준 입력으로 삼아 agent.name과 llm.cost.total 필드를 키로 집계하면 서브에이전트 수준의 비용 산출이 가능하다는 방법론이 제시됐다. 파이프라인은 JSONL을 순차로 읽어 각 레코드를 매핑하고 에이전트별 합계를 누적하며 최종적으로 비용 기준으로 정렬하는 처리 흐름으로 구성되어야 한다는 점이 구체적으로 기술됐다. 정확도를 높이려면 본 스크립트의 추정 토큰 계산을 실제 토크나이저로 교체하고 비용값을 하드코딩 대신 메타데이터로부터 동적으로 읽어 처리해야 한다는 권고가 포함됐다.
- 반복되는 시스템 프롬프트 문제를 탐지하려면 입력 토큰의 접두사 일치를 찾는 전처리 단계가 필요하다는 구현 요령이 제공됐다. 접두사 매칭은 동일한 컨텍스트 블록이 여러 호출에서 중복 전달되는지를 식별하는 간단한 방법이며 이 정보를 토대로 불필요 토큰과 절감 기회를 보고할 수 있다. 다만 접두사 매칭은 완전 매칭에 한정되므로 부분 매칭이나 토크나이저 수준의 정규화가 없으면 오탐이 발생할 수 있음이 명시됐다.
- 실제 배포를 염두에 두면 테스트 데이터를 늘려 LangGraph 외 다른 런에서도 동작을 확인하고 비용 모델을 환경별로 조정해야 한다는 실무적 권고가 제시됐다. 또한 스크립트 결과를 기존 관찰성 플랫폼의 대시보드 또는 SQL 분석 워크플로에 연동하면 운영상 활용도가 확대될 것이라는 제안이 포함됐다. 마지막으로 토큰 카운팅과 비용 단가를 외부 구성으로 분리해 유지보수성과 재현성을 확보해야 함이 권고됐다.
섹션별 상세
이미지 분석
이 이미지는 저장소의 기본 메타데이터를 시각적으로 확인할 수 있게 한다. 저장소의 가시성 수준이 낮고 테스트가 제한적이라는 본문 설명과 일치하며 오픈 소스 프로토타입 성격을 뒷받침한다. 스크린샷은 구현된 코드와 사용 예시를 직접 보여주지 않으므로 상세 구현 증거로는 제한적이다.
GitHub 리포지토리 헤더 스크린샷으로 저장소명이 보이고 기여자 2명, 이슈 0개, 스타 3개, 포크 0개가 표시되어 있다.
용어 해설
- OpenInference 스펙(OpenInference)
- — OpenInference는 에이전트·LLM 실행 로그 표준을 규정하는 스펙이다. 로그에 agent.name, llm.cost.total 등 필드가 포함될 수 있게 구조를 정의한다. 이 스펙은 제품이 아니라 필드 명세로 구현 간 상호운용성을 목적으로 한다.
- 다중 서브에이전트 구조(multi-subagent agent)
- — 다중 서브에이전트 구조는 하나의 상위 에이전트가 여러 하위 에이전트를 호출해 작업을 분할하는 실행 패턴이다. 각 서브에이전트는 별도 context와 LLM 호출을 가질 수 있어 비용과 토큰 사용량을 분리해 측정해야 한다. 본 글은 서브에이전트별 비용 순위를 산출하는 문제를 다루고 있다.
- 토큰 계산(token counting)
- — 토큰 계산은 프롬프트·응답의 토큰 수를 산정해 비용을 추정하는 과정이다. 본 게시물에서 사용된 스크립트는 실제 토크나이저를 쓰지 않고 추정법으로 카운트한다는 한계가 명시됐다. 정확한 비용 비교와 최적화에는 정확한 토크나이저 기반 계측이 필요하다.
- Langfuse
- — Langfuse는 런 관찰성과 디버깅을 제공하는 플랫폼으로 여러 실행을 대시보드 형태로 집계한다. 포스트에서는 Langfuse가 대시보드 기반으로는 서브에이전트별 비용 순위를 직접 제공하지 않는다고 기술됐다. 개별 런 태깅과 SQL 질의를 통해 비슷한 분석이 가능하다고 적시됐다.
언급된 도구
다수 실행을 대시보드 형태로 집계해 런 관찰성을 제공하는 플랫폼이다. 게시물에서는 LangSmith가 서브에이전트별 비용을 개별 실행 수준에서 자동으로 분해해 보여주지 않는다고 기술됐다. 따라서 단일 실행의 서브에이전트 비용까지 보려면 추가적인 로그 태깅이나 후처리가 필요하다고 판단됐다.
대시보드 기반으로 여러 런을 집계하고 분석할 수 있는 관찰성 도구이다. 게시물은 Langfuse가 대시보드 수준에서는 가능하지만 서브에이전트 단위의 즉시 가시성 제공에는 제약이 있다고 기술했다. 개별 런 태깅과 SQL 질의를 통해 필요한 분석을 구현할 수 있다고 적시됐다.
API 호출 및 토큰 사용량을 추적하는 플랫폼으로 개별 태그 기반의 SQL 질의를 통해 비용 분석이 가능하다고 언급됐다. 게시물은 Helicone이 태깅을 통해 분석 가능하나 기본적으로 서브에이전트 반복 컨텍스트를 자동 인식하지 못한다고 판단했다. 따라서 추가 메타데이터 삽입이 필요하다는 점이 지적됐다.
스팬 단위와 프로젝트 단위로 비용을 제공하는 관찰성 솔루션으로 포스트에서는 중간 수준 집계가 없다고 기술됐다. 이 특성 때문에 세밀한 서브에이전트별 비용 분석을 직접 제공하지 않는 상황이 발생한다고 적시됐다. 결과적으로 Phoenix는 스팬 또는 전체 프로젝트 관점의 비용 분석에는 적합하지만 중간 집계가 필요한 케이스에는 한계가 있다고 판단됐다.
게시물에서는 해당 스크립트가 LangGraph 실행 로그 하나에 대해 테스트되었다고 명시됐다. LangGraph는 언급된 다른 플랫폼과 달리 게시물의 테스트 케이스 역할을 했고 스크립트의 동작 검증에 사용된 실세계 런으로 기술됐다. 따라서 현재 결과는 LangGraph 기반 한 건의 검증임이 명확히 표기됐다.
저자가 작성한 CLI 스크립트 저장소로 OpenInference JSONL 입력을 읽어 서브에이전트별 비용을 합산하고 비용 순위를 생성하며 반복 컨텍스트를 식별하는 처리 파이프라인을 구현했다. 구현은 접두사 매칭 기반 반복 탐지, 추정식 토큰 카운팅, 2개의 하드코드 비용 단가를 사용한다는 한계가 명시됐다. 저장소는 프로토타입 검증용으로 LangGraph 로그에서 테스트된 상태임이 확인됐다.
언급된 리소스
AI 요약 · 북마크 · 개인 피드 설정 — 무료
출처 · 인용 안내
인용 시 "요약 출처: AI Trends (aitrends.kr)"를 표기하고, 사실 확인은 원문 보기 기준으로 진행해 주세요. 자세한 기준은 운영 정책을 참고해 주세요.