AI 에이전트 비용 추적은 모델 API 청구액을 보는 것으로 끝나지 않는다. 사용자 목표 하나를 완료한 실행(run)을 기준으로 LLM 토큰, 캐시, 도구 API, 재시도, 관측 저장비를 합산하고 팀·프로젝트·기능별로 배부해야 한다. 월별 총액만 보면 어떤 에이전트가 비용을 만들었는지, 실패한 실행에 얼마를 썼는지, 캐시가 실제로 절감됐는지 알 수 없다.
핵심 요약: 최상위 trace는 사용자 작업 1건으로 잡고, 그 아래 LLM 호출과 도구 호출을 span으로 기록한다. 모든 trace에 팀·사용자·프로젝트·환경 태그를 붙인다. 비용은 입력·출력·cache read·cache write·reasoning 토큰을 분리해 계산하고, 외부 API와 재시도 비용까지 더한다. 대시보드는 총비용보다 실행당 비용, 성공 실행당 비용, 실패 비용, 캐시 적중률을 먼저 보여줘야 한다.
출처: 월 44,000회 가정 자체 계산
요청당 비용이 아니라 실행당 총원가를 봐야 한다
일반 챗봇은 사용자 메시지 한 번과 모델 호출 한 번이 비교적 가깝다. AI 에이전트는 한 작업 안에서 계획을 만들고, 여러 모델을 호출하고, 검색·브라우저·데이터베이스·코드 실행 도구를 사용하고, 실패하면 다시 시도한다. 한 번의 사용자 요청이 10개의 LLM 호출과 20개의 도구 호출로 늘어날 수 있다.
따라서 비용의 기본 단위를 HTTP 요청이나 모델 호출로 잡으면 업무 원가를 계산하기 어렵다. 가장 실용적인 단위는 다음 세 단계다.
| 단위 | 의미 | 답할 수 있는 질문 |
|---|---|---|
| Span | LLM 호출, 도구 호출, 검색, 평가 같은 개별 작업 | 어느 단계에서 비용과 지연이 발생했나 |
| Trace / Run | 사용자 목표 하나를 처리한 전체 실행 | 이 작업을 완료하는 데 총 얼마가 들었나 |
| Session / Project | 여러 실행을 묶은 사용자 세션·팀·프로젝트 | 누가 어떤 기능에서 예산을 사용했나 |
기존 AI 에이전트 관측성 가이드가 trace 설계와 운영 안전성을 설명했다면, 이 글은 trace에 비용 데이터를 붙여 원가와 예산을 통제하는 방법에 집중한다.
AI 에이전트 총비용 계산식
에이전트 실행 1건의 총비용은 다음 네 항목을 합쳐 계산한다.
실행 총비용 = LLM 비용 + 도구·검색 비용 + 재시도·낭비 비용 + 인프라·관측 비용
1. LLM 비용
LLM 비용도 단순히 전체 입력 토큰에 입력 단가를 곱하면 안 된다.
- 일반 입력 토큰
- cache read 입력 토큰
- cache write 또는 cache creation 토큰
- 출력 토큰
- reasoning 출력 토큰
- 이미지·오디오·영상 입력
- Batch·Priority·Long context 같은 별도 요율
제공자마다 캐시 분류와 과금 방식이 다르므로 input_tokens 하나로 합쳐 저장하면 나중에 정확한 재계산이 어렵다. 모델별 최신 단가와 캐시 차이는 2026년 하반기 LLM 비교에서 확인할 수 있다.
2. 도구·검색 비용
에이전트가 호출하는 외부 도구도 원가에 포함한다.
- 웹 검색 API와 크롤링 서비스
- 지도·번역·OCR·음성 API
- 벡터 데이터베이스 검색·저장
- 브라우저 실행과 샌드박스 컴퓨팅
- 코드 인터프리터·GPU 작업
- 문자·메일·결제·업무 SaaS API
도구가 무료 티어에 들어가더라도 호출 횟수와 사용량은 기록해야 한다. 무료 한도를 넘는 순간 비용 구조가 바뀌고, 공급자가 요금제를 변경했을 때 과거 사용량으로 영향을 계산해야 하기 때문이다.
3. 재시도와 낭비 비용
실패 후 같은 프롬프트를 다시 호출한 비용, 잘못된 도구 인자로 반복 실행한 비용, 종료 조건 없이 루프를 돈 비용은 모델 청구서에는 정상 사용량으로 표시된다. 운영 관점에서는 별도 낭비 비용이다.
다음 값을 구분한다.
- 최초 시도 비용
- 자동 재시도 비용
- 오류 복구 비용
- 사용자 취소 이후 발생한 비용
- 실패로 끝난 실행의 전체 비용
- 평가·검증 모델의 추가 비용
4. 인프라와 관측 비용
자체 호스팅 모델의 GPU 비용뿐 아니라 trace 저장소, 로그, 객체 스토리지, 데이터 웨어하우스와 대시보드 비용도 포함한다. SaaS 관측성 도구가 이벤트 수나 보존 기간에 따라 과금된다면 에이전트 실행 원가에 배부해야 한다.
월 44,000회 실행 비용 계산 예시
다음은 특정 모델 추천이 아니라 계산 구조를 설명하기 위한 가상 단가 예시다.
| 조건 | 가정 |
|---|---|
| 사용자 | 100명 |
| 사용자당 일일 실행 | 20회 |
| 월 근무일 | 22일 |
| 월 실행 수 | 44,000회 |
| 실행당 입력 | 20K 토큰 |
| 실행당 출력 | 2K 토큰 |
| Cache hit | 입력의 50% |
| 1M 토큰 단가 | 일반 입력 $2, cache read $0.20, 출력 $10 |
| 추가 재시도 | 기본 LLM 비용의 8% |
| 외부 도구 API | 실행당 $0.003 |
| 관측·저장 | 월 $250 |
캐시가 없으면 실행당 LLM 비용은 $0.06, 월 $2,640이다. 입력의 절반이 cache hit라면 실행당 $0.042, 월 $1,848로 내려가 $792, 30%를 절감한다.
하지만 최종 원가는 여기서 끝나지 않는다.
| 비용 항목 | 월 비용 |
|---|---|
| 캐시 반영 LLM 호출 | $1,848.00 |
| 재시도·복구 | $147.84 |
| 외부 도구 API | $132.00 |
| 관측·저장 | $250.00 |
| 합계 | $2,377.84 |
완료 실행 1건당 총원가는 약 $0.054다. 모델 호출비 외 항목은 $529.84로 전체의 약 22.3%다. 모델 공급자 대시보드만 봤다면 이 비용을 제품 원가에서 놓치게 된다.
반드시 기록해야 할 비용 필드
OpenTelemetry의 GenAI semantic conventions는 2026년 7월 기준 별도 semantic-conventions-genai 저장소로 이동했으며 상태가 Development다. 속성명은 바뀔 수 있으므로 버전을 고정하고 변경 이력을 확인해야 한다.
| 영역 | 필드 예시 | 용도 |
|---|---|---|
| 추적 식별자 | trace_id, span_id, run_id, conversation_id | 개별 호출을 사용자 작업과 연결 |
| 조직 배부 | tenant_id, team_id, user_id, project_id, environment | 팀·고객·환경별 비용 집계 |
| 에이전트 | gen_ai.agent.name, gen_ai.workflow.name, agent version | 어느 에이전트·버전이 비용을 만들었는지 확인 |
| 모델 | gen_ai.provider.name, gen_ai.request.model, gen_ai.response.model | 요청 모델과 실제 응답 모델·fallback 구분 |
| 토큰 | gen_ai.usage.input_tokens, gen_ai.usage.output_tokens | 기본 토큰 사용량 |
| 캐시 | gen_ai.usage.cache_read.input_tokens, gen_ai.usage.cache_creation.input_tokens | 캐시 절감·생성 비용 계산 |
| 추론 | gen_ai.usage.reasoning.output_tokens | reasoning 토큰을 일반 출력과 분리 |
| 도구 | gen_ai.tool.name, tool type, 호출 상태, 외부 비용 | 검색·DB·브라우저·코드 실행 원가 |
| 실행 상태 | iteration, retry count, error type, termination reason | 재시도와 무한 루프 비용 분리 |
| 가격 기준 | price version, currency, estimated/actual, billing tier | 단가 변경과 청구서 대조 |
| 품질 | success, user acceptance, evaluator score | 싸지만 실패하는 실행 구분 |
tenant_id, team_id, 가격과 비용 필드는 조직별 custom attribute로 설계할 수 있다. OpenTelemetry 표준 속성과 자체 속성을 구분하고 접두어 규칙을 정해야 한다.
프롬프트·응답 전문을 저장하지 않아도 비용 추적은 가능하다. 개인정보와 소스코드 유출이 우려되면 본문은 마스킹하거나 저장하지 않고 토큰 수, 모델, 도구명, 상태와 비용만 남긴다.
가격표는 호출 시점에 버전으로 저장한다
비용을 조회할 때 현재 가격표를 과거 토큰에 곱하면 안 된다. 모델 가격, 캐시 할인, Long context 기준과 공급자 티어는 바뀐다. 호출 시점에 다음 정보를 함께 저장하는 편이 안전하다.
- 적용한 모델 가격표 버전과 유효일
- 요청 모델과 공급자가 반환한 실제 모델
- Standard·Batch·Priority 같은 요금 티어
- Short·Long context 구간
- cache read·cache write 단가
- 통화와 환율 기준일
- 추정 비용인지 공급자 확정 비용인지
실시간 대시보드는 추정 비용으로 빠르게 보여주고, 하루 한 번 공급자 usage·청구 데이터와 대조해 확정 비용을 보정할 수 있다. 둘 사이 차이는 반올림, 지연 집계, 공유 캐시, 무료 크레딧, 약정 할인과 공급자별 토큰 분류에서 발생한다.
팀·사용자·프로젝트별 비용 배부
배부 태그는 Gateway나 에이전트 진입점에서 강제로 붙여야 한다. 개발자가 각 모델 호출마다 직접 넣게 하면 누락이 생긴다.
권장 배부 계층
- Tenant 또는 고객사: B2B 서비스의 고객별 원가와 마진
- Team: 부서·개발팀별 예산
- Project 또는 기능: 코드 리뷰, 문서 생성, 고객지원 같은 기능별 원가
- User: 과도한 사용과 교육 필요 사용자 식별
- Agent·Workflow·Version: 버전 변경 전후 비용 비교
- Environment: production, staging, eval 비용 분리
예를 들어 같은 고객지원 에이전트라도 refund-agent:v3가 v2보다 성공률은 2% 높지만 실행당 비용이 40% 늘었다면 품질 개선과 원가 상승을 함께 판단할 수 있다. 총 토큰만 보면 이 의사결정이 불가능하다.
AI Gateway를 통과하도록 구성하면 모델 키, 라우팅, 공통 태그와 비용 제한을 한 지점에서 적용하기 쉽다.
도구별 역할: 하나로 모두 해결하려 하지 않는다
| 도구 | 주 역할 | 공식 비용 기능 | 예산 차단 | 배포 형태 | 주의점 |
|---|---|---|---|---|---|
| Langfuse | LLM·에이전트 trace, 평가, 대시보드 | input·output·cached·audio·image usage와 모델 가격 기반 비용 | Gateway와 별도 설계 | Cloud·Self-host | 신규 모델·커스텀 단가 최신화 필요 |
| LangSmith | LangChain·LangGraph 중심 tracing·평가 | LLM 비용과 tool·retrieval custom run 비용을 Other로 집계 | evaluator 비용 제한 제공, 일반 실행 hard cap은 별도 | Cloud·엔터프라이즈 Self-host | 프레임워크 결합도와 데이터 보관 정책 확인 |
| Phoenix | OpenTelemetry·OpenInference 기반 오픈소스 관측성 | token count와 모델 가격으로 span·trace·session·project 롤업 | 별도 Gateway 필요 | Self-host·Arize 서비스 | Phoenix와 Arize AX 제품 구분 필요 |
| LiteLLM | 멀티 모델 Gateway와 spend control | 100개 이상 모델의 key·user·team별 spend 추적 | 개인·팀·에이전트 budget·rate limit | Self-host 중심·Enterprise | 정확한 모델 매핑과 DB 운영 필요 |
| Cloudflare AI Gateway | 관리형 Gateway·분석·정책 | 요청·토큰·캐시·오류·provider 비용 분석 | Spend limits 기능 제공 | Cloudflare 관리형 | 세부 업무 trace는 별도 관측성 도구와 연결 |
| OpenTelemetry | 공급자 중립 trace·metric 표준 | 토큰·모델·도구 속성 표준화 | 없음 | Collector와 원하는 backend | 완성 제품이 아니며 GenAI 규약이 Development 상태 |
선택은 “가장 많은 기능”보다 통제 위치에 따라 달라진다.
- 모델 호출 전에 예산을 막아야 한다면 LiteLLM·Cloudflare 같은 Gateway 계층이 필요하다.
- 실행 원인과 품질을 분석하려면 Langfuse·LangSmith·Phoenix 같은 trace backend가 필요하다.
- 제품 종속을 줄이고 여러 backend로 보내려면 OpenTelemetry Collector를 중간에 둔다.
- 작은 팀은 Gateway 1개와 관측성 backend 1개로 시작하는 편이 운영 부담이 낮다.
비용 대시보드에 넣을 10개 패널
월간 총비용만 크게 표시한 대시보드는 원인을 알려주지 않는다. 최소한 다음 패널이 필요하다.
- 총비용과 전일·전주 대비 증감
- 성공 실행당 평균·P50·P95 비용
- 실패 실행과 취소 실행의 비용
- 팀·고객·프로젝트별 비용
- 모델·공급자·요금 티어별 비용
- 일반 입력·cache read·cache write·출력 토큰 비중
- Cache hit 비율과 절감 추정액
- 도구별 호출 수·성공률·외부 API 비용
- 에이전트 iteration·retry 분포
- 품질 점수 대비 비용
평균만 보면 소수의 폭주 실행을 놓칠 수 있다. P95 실행 비용, 하루 최대 실행 비용과 상위 20개 비싼 trace를 바로 열 수 있어야 한다.
예산 알림과 무한 루프 차단 기준
비용 통제는 월말 보고서보다 실행 중 제한이 중요하다.
| 통제 지점 | 권장 규칙 예시 |
|---|---|
| 팀 월 예산 | 70% 정보 알림, 90% 경고, 100% 신규 저우선순위 작업 제한 |
| 실행당 예산 | 예상 비용이 상한을 넘으면 저가 모델 전환 또는 사용자 승인 |
| 반복 횟수 | agent iteration·tool retry 최대값 설정 |
| P95 비용 | 최근 7일 기준의 2배를 넘으면 이상 징후 알림 |
| Cache hit | 기준선 아래로 떨어지면 프롬프트 prefix 변경 검사 |
| 실패 비용 | 실패 실행 비용 비중이 임계값을 넘으면 배포 중단 검토 |
| 도구 비용 | 유료 검색·브라우저·GPU 호출 전에 남은 예산 검사 |
숫자는 서비스 위험도와 마진에 맞춰 정해야 한다. 결제·배포·데이터 삭제 같은 중요한 작업을 예산 때문에 중간에 강제 종료하면 더 큰 장애가 날 수 있다. hard cap은 안전하게 재개할 수 있는 작업에 적용하고, 중요한 작업은 승인·fallback·grace budget을 둔다.
최소 비용 추적 도입 순서
1단계: 공통 식별자와 토큰 기록
사용자 작업 하나에 trace_id와 run_id를 만들고 모든 LLM·도구 호출에 전파한다. provider, request model, response model, 입력·출력·캐시 토큰을 기록한다.
2단계: 가격 계산기와 버전 추가
모델별 가격표를 코드에 흩어놓지 않고 중앙 cost map으로 관리한다. 가격 버전, 통화, 요금 티어와 estimated cost를 span에 붙인다.
3단계: 조직 배부 태그 강제
Gateway나 공통 SDK에서 tenant, team, user, project, environment, agent version을 필수화한다. 태그가 없으면 production 호출을 거부하거나 unallocated 비용으로 따로 집계한다.
4단계: 도구·재시도 비용 연결
외부 API 호출 span에 단가와 사용량을 붙인다. retry count, iteration, error type과 termination reason을 기록해 실패 비용을 분리한다.
5단계: 대시보드와 알림
총비용, 성공 실행당 비용, 실패 비용, cache hit, P95 비용과 상위 고비용 trace를 먼저 만든다. 이후 팀 예산과 실행당 상한을 적용한다.
6단계: 공급자 청구서와 대조
매일 provider usage와 내부 추정 비용을 비교한다. 차이가 일정 수준을 넘으면 가격표·모델 매핑·캐시 분류·시간대 기준을 점검한다.
운영 체크리스트
- 사용자 목표 1건을 하나의 trace로 묶었는가
- 모든 모델·도구 호출에 같은 run ID가 전파되는가
- request model과 response model을 분리했는가
- 일반 입력·cache read·cache creation·출력을 구분했는가
- reasoning·이미지·오디오 사용량을 별도로 기록하는가
- 외부 검색·브라우저·DB·GPU 비용을 포함했는가
- retry·iteration·실패 비용을 분리했는가
- 팀·사용자·프로젝트·환경 태그가 필수인가
- 가격표 버전과 요금 티어를 저장하는가
- 실시간 추정액을 공급자 청구 데이터와 대조하는가
- 프롬프트 전문 없이도 비용 분석이 가능한가
- 실행당 budget과 무한 루프 제한이 있는가
FAQ
AI 에이전트 비용 추적과 일반 LLM 비용 추적은 무엇이 다른가?
일반 LLM 비용 추적은 모델 호출별 토큰과 금액을 본다. AI 에이전트 비용 추적은 하나의 사용자 목표 아래 여러 LLM 호출, 도구 실행, 재시도, 평가와 인프라 비용을 합쳐 실행 총원가를 계산한다.
OpenTelemetry만 도입하면 비용 계산이 끝나나?
아니다. OpenTelemetry는 trace와 GenAI 속성을 표준화하지만 제품별 가격표, 조직 배부, 외부 도구 단가와 예산 차단은 별도로 구현하거나 관측성·Gateway 제품을 연결해야 한다. GenAI semantic conventions도 2026년 7월 기준 Development 상태다.
Langfuse와 LiteLLM 중 무엇을 써야 하나?
역할이 다르다. Langfuse는 trace·평가·비용 분석 backend에 가깝고 LiteLLM은 모델 Gateway와 key·user·team 예산 통제에 강하다. 비용 차단과 원인 분석이 모두 필요하면 함께 사용할 수 있다.
프롬프트와 응답을 저장해야 비용을 계산할 수 있나?
필수는 아니다. 모델, 토큰 유형별 사용량, 도구명, 상태, 재시도와 가격 버전만으로 비용을 계산할 수 있다. 민감한 프롬프트는 마스킹하거나 저장하지 않는 편이 안전하다.
캐시 적중률이 높으면 비용도 같은 비율로 줄어드나?
아니다. 캐시 할인은 캐시된 입력 부분에만 적용된다. 출력, reasoning, cache write, 도구 API와 관측 비용은 그대로 남는다. 전체 절감률은 입력 비중과 cache read 단가에 따라 달라진다.
공급자 대시보드 금액과 내부 계산이 다른 이유는 무엇인가?
시간대, 집계 지연, 반올림, 무료 크레딧, 약정 할인, 실제 응답 모델, 캐시 분류와 가격표 버전 차이 때문이다. 내부 값은 실시간 통제를 위한 추정액으로 사용하고 공급자 usage·청구 데이터로 정기 보정해야 한다.
참고 자료
- OpenTelemetry GenAI Semantic Conventions Repository — GenAI span·agent·tool·token 속성 표준
- Langfuse Token & Cost Tracking — usage 유형과 모델 가격 기반 비용 계산
- LangSmith Cost Tracking — LLM·tool·retrieval custom cost와 대시보드
- Arize Phoenix Cost Tracking — span·trace·session·project 비용 롤업
- LiteLLM Spend Tracking — key·user·team별 spend 추적
- LiteLLM Budgets and Rate Limits — 개인·팀·에이전트 예산과 실행 제한
- Cloudflare AI Gateway Analytics — 요청·토큰·캐시·오류·비용 분석
*제품 기능과 문서 상태는 2026년 7월 29일 확인 기준이며 이후 변경될 수 있다.*
