TraceLLM

TraceLLM은 AI 워크플로를 중첩된 스팬을 가진 세션으로 구성한다. 세션은 사용자 턴을 담는다. 각 스팬은 공급자 호출, 검색 단계, 도구 실행 같은 하나의 작업 단위를 담는다. 이것이 LLM 트레이싱의 핵심이다. 세션을 시작하고, 그 안에서 스팬을 열고, 이벤트가 일어나는 대로 기록하고, 둘 다 상태로 닫는다. 이 구조가 어지러운 로그 줄 더미를 재생 가능한 하나의 실행으로 바꾼다.

모든 것을 저장해서는 안 된다. 프로젝트별로 정책을 정한다. 프롬프트와 출력 내용을 수집할지, 메타데이터와 사용량을 얼마나 보관할지, 마스킹이 API 키와 bearer 토큰을 데이터베이스에 닿기 전에 가릴지. 여기서 프롬프트 트레이싱이 안전장치를 얻는다. 샘플링은 세션의 0%에서 100%까지 수집할 수 있고, 특정 스팬 종류는 통째로 건너뛸 수 있다.

각 스팬은 속성과 나란히 토큰 수와 시간을 실을 수 있다. 비용과 속도가 호출 자체와 같은 뷰에 놓인다. 어느 단계가 느리고 어느 것이 비싼지 보인다. 두 대시보드를 합칠 필요가 없다. 이것이 청구서가 올랐다는 것과 어떤 프롬프트가 원인인지를 아는 것의 차이다.

TraceLLM은 자체 제품 타임라인을 유지하면서 선택한 트레이스를 고객 소유 OTLP HTTP 수집기로 전달할 수 있다. 엔드포인트를 붙여 넣고 전달할 신호를 고르면 데이터가 SigNoz, Honeycomb, Tempo, Datadog 또는 OTLP 호환 백엔드로 흐른다. 이미 APM을 운영하는 팀은 기존 스택을 유지하고 TraceLLM을 그 위의 AI 전용 계층으로 다룰 수 있다.

한 공급자에 묶지 않는 AI 디버깅 도구라고 보면 된다. 스팬은 어떤 모델을 호출하는지 신경 쓰지 않는다. TraceLLM은 OpenAI, Claude, Gemini, 자체 라우터, 내부 서비스, MCP 형태 워크플로와 동작한다. 공급자 전용 플러그인에 의존하지 않고 호출을 직접 감싸기 때문이다. 모델이나 게이트웨이를 바꿔도 트레이싱 설정은 깨지지 않는다.

각 API 키는 요청을 하나의 프로젝트에 대응시키고 그 프로젝트의 수집 정책을 SDK 런타임으로 가져간다. 여러 키를 만든다. 이름을 붙인다. 서비스가 쓰지 않게 되면 옛 키를 폐기한다. 이렇게 하면 공유 정책이 무관한 앱으로 새지 않고, 키 교체가 간단한 두 단계 작업이 된다.