월말에 Anthropic 청구서를 받고 나서야 "어, 이게 왜 이렇게 많이 나왔지?"라고 뒤늦게 당황한 경험, 혹시 있으신가요? 저는 있습니다. 그것도 한 번이 아니라 여러 번. Claude API를 SaaS 서비스에 붙이기 시작했을 때, 비용 관리가 이렇게 복잡한 문제가 될 거라고는 생각도 못 했습니다.
기능별 cost attribution이 안 된다는 것, 처음엔 몰랐습니다
처음 Claude API를 붙였을 때는 Anthropic 콘솔 대시보드만 보면 충분할 거라고 생각했습니다. 직접 써봤는데, 그건 완전히 착각이었습니다. 대시보드는 조직 전체 토큰 소비량을 하나의 숫자로 보여줄 뿐이었습니다. 서비스에는 문서 요약 기능과 챗봇 기능이 함께 있었는데, 어느 쪽이 비용을 더 많이 쓰는지 전혀 알 수가 없었습니다.
여기서 cost attribution이란 전체 비용을 기능별, 사용자별로 분리해서 귀속시키는 것을 의미합니다. 일반 서비스라면 서버 비용을 기능별로 쪼개는 일이 그나마 예측 가능하지만, LLM은 입력 컨텍스트 길이와 출력 토큰 수에 따라 호출마다 비용이 천차만별이라 더욱 까다롭습니다.
해결책으로 선택한 건 API 호출 레이어에 미들웨어를 추가하는 방식이었습니다. 응답의 usage 필드, 즉 input_tokens와 output_tokens 값을 기능 이름, 사용자 ID, 타임스탬프와 함께 PostgreSQL 로그 테이블에 저장했습니다. 처음에는 단순 INSERT로 충분했지만, 트래픽이 늘면서 API 응답 지연이 생기기 시작했습니다. 그때 비동기 큐인 BullMQ를 도입해 로깅을 메인 흐름에서 분리했는데, 이후로는 응답 속도에 영향을 주지 않으면서도 100% 기록 보존이 가능해졌습니다.
솔직히 이건 예상 밖이었습니다. Anthropic의 공식 Admin API인 /v1/organizations/usage_report/messages 엔드포인트가 있고, 시간 버킷(1분, 1시간, 1일) 단위 집계와 모델별·워크스페이스별 분류를 지원한다는 건 알고 있었지만, 이 API는 Admin API 키, 즉 sk-ant-admin으로 시작하는 키가 필요하고 조직 내 admin 역할을 가진 멤버만 접근할 수 있습니다. 그리고 결정적으로, 워크스페이스 단위까지만 집계를 지원합니다. SaaS처럼 수천 명의 최종 사용자가 있는 서비스에서 per-user 비용 추적, 즉 사용자 한 명 한 명의 비용을 뽑아내려면 결국 애플리케이션 레이어에서 직접 구현하는 수밖에 없습니다.
Enterprise Analytics API라는 게 2025년 중반부터 별도로 제공되고 있긴 합니다. 9개의 엔드포인트로 모델별, 컨텍스트 창별, 추론 리전별 데이터를 제공하고 claude.ai 챗, Claude Code, Cowork 등 모든 서비스 표면에 걸친 per-user 수준 데이터를 프로그래밍 방식으로 접근할 수 있다고 합니다(출처: Anthropic 공식 문서). 그런데 제 경험상 이건 엔터프라이즈 플랜 가입자에게만 제공되는 유료 기능입니다. AI 비용 투명성은 모든 규모의 서비스에 필요한 기본 역량인데, 플랜에 따라 차등 제공된다는 점은 솔직히 아쉽습니다.
핵심 포인트를 정리하면 다음과 같습니다.
- Admin API는 조직·워크스페이스 단위 집계만 지원하므로 per-user 추적은 앱 레이어에서 직접 구현해야 합니다
- API 응답의 input_tokens, output_tokens를 기능명·사용자 ID와 함께 DB에 기록하는 미들웨어가 가장 현실적인 출발점입니다
- 트래픽 증가 후에는 BullMQ 같은 비동기 큐로 로깅을 분리해야 응답 지연을 막을 수 있습니다
- Enterprise Analytics API는 엔터프라이즈 플랜 전용으로, 중소 팀에서는 접근이 제한될 수 있습니다
중복 집계 버그와 실시간 대시보드, 그 사이에서 배운 것
미들웨어 로깅을 구축한 뒤 한동안은 잘 돌아가는 것처럼 보였습니다. 그런데 Agent SDK를 붙이고 나서 이상한 일이 생겼습니다. 토큰 집계 수치가 실제 청구액과 맞지 않았고, 어떤 날은 2배에서 3배 가까이 부풀려져 있었습니다.
원인은 병렬 툴 호출 시 발생하는 deduplication 문제였습니다. 여기서 deduplication이란 동일한 데이터가 중복으로 집계되지 않도록 ID 기준으로 한 번만 계산하는 처리를 의미합니다. Claude Agent SDK에서 병렬로 툴을 호출하면 동일한 message ID를 공유하는 응답이 스트리밍 방식으로 여러 번 수신될 수 있는데, ID 기반 중복 제거 없이 단순히 합산하면 실제보다 훨씬 높은 토큰 수가 기록됩니다. 제가 이 버그를 프로덕션에서 발견했을 때는 이미 한 달치 비용 데이터가 부정확하게 쌓인 상태였고, 소급 수정에만 꽤 많은 시간이 걸렸습니다. 돌이켜보면 초기 설계 단계에서 message ID 기준 deduplication 로직을 먼저 넣었어야 했습니다.
이 경험 이후 Grafana Cloud와 Admin Usage API를 연동해 실시간 대시보드를 구성했습니다. Grafana Cloud와의 공식 통합은 Prometheus 레이블링 방식으로 입출력 토큰, 모델, 워크스페이스 ID, 서비스 티어 등을 메트릭 시리즈로 수집합니다. 여기서 Prometheus 레이블링이란 각 메트릭 데이터에 key=value 형태의 식별자를 붙여서 다차원 필터링이 가능하게 만드는 방식을 말합니다. 외부 익스포터 없이 Grafana Cloud가 직접 HTTP 페치와 파싱을 처리하는 'collector-less' 구조라서 운영 부담이 낮다는 점도 실제로 써보고 나서 만족스러웠습니다(출처: Grafana Labs).
대시보드에서 핵심 지표로 설정한 건 일일 토큰 소비량, 기능별 비용 비율, 사용자당 평균 비용, 그리고 캐시 히트율입니다. 캐시 히트율은 동일한 프롬프트 컨텍스트가 재사용되는 비율을 뜻하는데, 이 수치가 낮으면 입력 토큰 비용이 불필요하게 반복 발생하고 있다는 신호입니다. 이 대시보드가 제 역할을 톡톡히 한 순간이 있었는데, 특정 날 비용이 갑자기 급등했을 때 원인을 30분 만에 찾아낸 적이 있습니다. 시스템 프롬프트 버그로 인해 매 요청마다 5,000토큰짜리 불필요한 컨텍스트가 붙고 있었습니다. 로깅 인프라가 없었다면 며칠이 지나도 눈치채지 못했을 것입니다.
비용 알림도 빠질 수 없었습니다. 시간당 토큰 소비량이 평균의 2배를 넘으면 Slack으로 알림이 오도록 설정했는데, 실제로 DDoS성 비정상 트래픽이나 프롬프트 인젝션 공격을 조기에 탐지하는 데 도움이 되었습니다. 여기서 프롬프트 인젝션이란 악의적인 사용자가 입력값을 통해 시스템 프롬프트를 우회하거나 모델의 동작을 조작하려는 공격을 의미합니다. 보안 이슈이기도 하지만, 비용 급등의 원인이 되기도 합니다.
Claude API 비용 추적은 처음에는 "그냥 콘솔 보면 되겠지"로 시작했다가, 결국 미들웨어, 비동기 큐, deduplication 로직, 실시간 대시보드까지 쌓아가는 여정이 됩니다. 제 경험상 이 인프라를 초기부터 설계해 두는 것과 나중에 뒤늦게 붙이는 것은 공수 면에서 두세 배 차이가 납니다. API를 막 붙이기 시작하는 단계라면, 최소한 usage 필드 로깅과 message ID 기반 deduplication만큼은 처음부터 넣어두길 권합니다.
참고:
- Anthropic Admin API - Usage & Cost Report: https://platform.claude.com/docs/en/build-with-claude/usage-cost-api
- Anthropic Enterprise Analytics API (Finout, 2025): https://www.finout.io/blog/anthropics-enterprise-analytics
- Grafana Cloud + Anthropic Integration: https://grafana.com/blog/how-to-monitor-claude-usage-and-costs
- Claude Agent SDK - Cost Tracking: https://platform.claude.com/docs/en/agent-sdk/cost-tracking