프로덕션 환경에서 고객별 LLM 비용을 추적하는 방법

고객별로 LLM 비용을 추적한다는 것은 멀티테넌트 (multi-tenant) 제품 내에서 모든 모델 제공업체(model-provider) 비용을 특정 사용자에게 할당하는 것을 의미합니다. 집계 대시보드(Aggregate dashboards)는 어떤 고객이 수익성이 없는지를 숨기지만, 고객별 할당 (per-customer attribution)은 이를 드러냅니다. 이 글에서는 계측 (instrumentation) 패턴, 확장 가능한 할당 방식, 그리고 해당 데이터를 어떻게 활용할지에 대해 다룹니다.

고객별 LLM 비용 추적이 중요한 이유

대부분의 팀은 이를 수행하지 못합니다. CloudZero의 2025년 AI 비용 현황 보고서(2025 State of AI Costs report)에 따르면, AI 비용을 고객에게 할당할 수 있는 조직은 43%에 불과하며, 트랜잭션 (transaction) 단위로 할당할 수 있는 조직은 22%뿐입니다 (CloudZero, 2025년 5월). FinOps Foundation의 2026년 FinOps 현황(State of FinOps 2026)에 따르면, AI를 FinOps 실무 범위에 포함하는 조직은 2024년 31%에서 98%로 증가하여 인식은 확산되었으나, 계측 (instrumentation) 기술은 아직 따라가지 못하고 있습니다.

비용은 구조적입니다. 스케일업 단계의 AI B2B 기업에서 모델 추론 (model inference) 비용은 매출의 약 23%를 차지하며 규모가 커져도 유의미하게 감소하지 않습니다 (ICONIQ AI B2B Operating Index, 2026년 1월). 팀이 고객별로 세분화할 수 없는 '매출의 23%'에 달하는 비용 센터는, 어떤 계정이 유료인지 모른 채 SaaS 비즈니스를 운영하는 것과 운영 측면에서 동일합니다.

평균을 망치는 것은 꼬리 부분(the tail)입니다. 중앙값(median)에서는 수익성이 있는 사용자라도, 쿼리 볼륨이 복리로 증가함에 따라 75백분위수(75th percentile)에서는 손익분기점으로, 90백분위수(90th percentile)에서는 월간 손실로 전환될 수 있습니다 (Todd Gagne, Wildfire Labs, 2026년 3월). Replit은 2026년 2월, 에이전트가 가격 책정 범위보다 더 많은 LLM을 소비하면서 매출 총이익률(gross margin)이 36%에서 -14%로 급락한 프로덕션 사례를 보고했습니다. 집계 대시보드는 이를 보여주지 않지만, 고객별 원장 (per-customer ledger)은 이를 보여줍니다.

할당 (attribution)을 통해 얻을 수 있는 것: 이사회 회의에서 제시할 수 있는 가격 결정 근과, 다음 서비스 중단(deprovisioning) 또는 가격 재조정(repricing) 결정을 이끌어낼 수 있는 마진 수치입니다.

멀티테넌트 AI 제품에서 "고객별"이 실제로 의미하는 것

멀티테넌트 (multi-tenant) AI 제품에서 고객별 LLM 비용 귀속 (attribution)은 조직 (organization), 최종 사용자 (end-user), 그리고 세션 (session) 또는 에이전트 작업 (agent task)이라는 세 가지 ID를 동시에 추적해야 합니다. 계측 (instrumentation) 단계에서 단 하나만 선택한다는 것은, 가격 모델이 처음 변경될 때 파이프라인을 다시 구축해야 함을 의미합니다.

조직 (Organization). 각 계정이 비용 부담 주체인 B2B 제품의 경우입니다. CFO가 던지는 질문은 "고객 X가 이번 달에 4,200달러를 사용했습니다"와 같은 것입니다.
최종 사용자 (End-user). B2C 제품 및 좌석(seat) 단위의 가시성이 필요한 B2B 제품의 경우입니다. 좌석당 비용을 파악하면 계정 공유 및 무료 티어(free-tier) 남용을 드러낼 수 있습니다.
세션 또는 에이전트 작업 (Session or agent task). 한 명의 고객이 여러 개의 동시 실행 에이전트를 생성할 수 있는 제품의 경우입니다. 단일 고객의 월간 비용은 어떤 워크플로 (workflow)가 실행되었느냐에 따라 100배까지 차이 날 수 있기 때문에, 때로는 "작업당 (per task)"이 적절한 단위가 됩니다.

실무에서는 데이터 모델이 모든 모델 제공자 (model-provider) 호출을 통해 이 세 가지 ID를 모두 전파합니다. 집계 (aggregation)는 나중에 이루어집니다. 팀이 사용량 기반 과금을 시작하는 즉시, 이 동일한 세 가지 ID가 멀티테넌트 LLM 과금 결정의 근거가 됩니다.

Cursor의 가격 책정 사건은 제품 계층에서 귀속 (attribution) 기능이 누락되었을 때 어떤 일이 발생하는지 잘 보여줍니다. 2025년 6월, Cursor는 요청 제한 (request caps)을 프런티어 모델 (frontier-model) API 요율로 책정된 크레딧 풀 (credit pool)로 교체했습니다. 사용자들은 실시간 가시성 없이 며칠 만에 크레딧을 소진했고, 환불 사태가 뒤따랐습니다. TechCrunch는 그 근본 원인이 기존의 정액제 (flat plan) 하에서 장기 실행 에이전트 작업 (longer-horizon agent tasks)으로 인해 발생한 비용 흡수 문제였다고 분석했습니다.

귀속 (attribution)은 단순히 백오피스 (back-office)의 관심사가 아닙니다. 이것 없이는 제품이 사용자에게 경고를 보낼 수 없으며, 팀은 다음 버전의 가격을 책정할 수 없습니다.

네 가지 귀속 패턴

모델 제공자의 비용을 고객에게 연결하는 데에는 네 가지 일반적인 패턴이 있습니다. 이 중 어떤 것도 보편적으로 정답인 것은 없습니다.

제공자 측 메타데이터 (Provider-side metadata). 주요 제공업체들은 모두 사용자별 태깅 (per-user tagging) 기능을 제공합니다. OpenAI는 Chat Completions 및 Responses API에서 user 파라미터를 허용하며, (2024년 12월 출시된) OpenAI Usage API는 프로그래밍 방식으로 사용자별 비용 내역을 분류할 수 있도록 group_by=user_id를 지원합니다. Costs 엔드포인트는 관리자 키 (admin key)가 필요합니다. Anthropic은 모든 API 요청에서 metadata.user_id를 허용하지만, 최대 256자로 제한되며 개인 식별 정보 (PII) 용도로는 명시적으로 사용할 수 없습니다. 트레이드오프(Trade-off)는 다음과 같습니다: 제공자 메타데이터는 마찰(friction)이 가장 적지만, 특정 제공업체에 종속되며 애플리케이션 내부에서 실시간 고객별 누적 합계를 보여주지는 않습니다. (참고: OpenAI의 user 파라미터와 Usage API 간의 연결 관계는 확정적인 것으로 간주하기 전에 실제 API 레퍼런스를 통해 다시 확인해야 합니다.)

클라이언트 측 계측 (Client-side instrumentation). 제공자 SDK를 래핑(Wrap)하여 customer_id, 모델, 입력/출력/캐시된 토큰 수, 그리고 로컬 가격표를 기반으로 계산된 호출당 비용이 포함된 타입화된 비용 이벤트 (typed cost event)를 방출합니다. 제공업체에 관계없이 이식성이 높습니다. 어떤 패턴을 선택하더라도 반드시 해결해야 하는 과제인 customer_id 전파 (propagation) 문제를 정면으로 다룹니다.

게이트웨이 또는 프록시 귀속 (Gateway or proxy attribution). 모델 제공자 API 앞단에 리버스 프록시 (reverse proxy)를 두어 요청을 기록하고, 비용을 계산하며, 고객별 내역을 노출합니다. 오픈 소스 옵션으로는 Helicone, LiteLLM, Langfuse, OpenLLMetry 등이 있습니다. 호스팅형 서비스들은 중앙 집중식 가시성을 원하는 팀을 위한 AI 비용 관측성 (observability) 레이어 역할을 합니다: LangSmith, Datadog LLM Observability, Arize Phoenix. 네트워크 홉 (network hop)이 추가되지만, 다수의 서비스 플릿 (fleet) 전반에 걸쳐 계측을 중앙 집중화할 수 있습니다.

원시 로그(raw logs)를 통한 계산된 할당 (Computed attribution). 전체 요청(request)과 응답(response)을 캡처한 뒤, 야간 작업(nightly job)을 통해 사후에 할당량을 계산합니다. "나중에 해결하기" 방식입니다. 흔히 사용되지만, 캐시된 입력(cached input)이나 스트리밍(streaming) 데이터에 대해 손실이 발생할 수 있으며, 기간 중간에 가격이 변경될 경우 조정하기 어렵습니다.

방어 가능한 프로덕션 설정은 보통 다음 중 두 가지를 결합합니다: 저렴한 보험으로서의 제공업체 메타데이터(provider metadata), 그리고 신뢰할 수 있는 원천(source of truth)으로서의 능동적 패턴(클라이언트 측 또는 게이트웨이 방식) 중 하나입니다.

실제로 할당하고 있는 것: 비용 항목 (cost-line items)

완성(completion)당 청구 금액은 단일 숫자가 아닙니다. 이를 하나의 숫자로 취급하는 것이 할당 드리프트(attribution drift)가 시작되는 원인입니다.

모델이 처리해야 하는 비용 항목은 다음과 같습니다:

입력 토큰(Input tokens) × 입력 요율(input rate). Claude Opus 4.x: 입력 토큰 100만 개당 $5, 출력 토큰 100만 개당 $25 (Anthropic 가격 정책, 2026년 5월). Sonnet 4.5/4.6: 입력 $3, 출력 $15 (Anthropic 가격 정책, 2026년 5월).
출력 토큰(Output tokens) × 출력 요율(output rate). 동일한 개념이지만 별도의 요율이 적용되며, 종종 입력 요율의 5배에 달합니다.
캐시된 입력 토큰(Cached input tokens) 및 해당 요율. OpenAI는 최소 1,024개 이상의 토큰을 가진 프롬프트에 대해 캐시된 입력에 50% 할인을 코드 변경 없이 자동으로 적용합니다. 캐시 TTL(Time To Live)은 유휴 상태 시 5~10분이며, 최대 1시간까지 유지됩니다 (OpenAI 프롬프트 캐싱 발표, 2024년 10월). Anthropic은 캐시 읽기(cache reads) 시 기본 입력 비용의 0.1배(90% 할인)를 부과하며, 5분 캐시 쓰기(cache write) 시에는 기본 입력 비용의 1.25배, 또는 1시간 캐시 쓰기 시에는 기본 입력 비용의 2배를 부과합니다 (Anthropic 가격 정책, 2026년 5월). 할당 시 주의할 점(gotcha): 조직(organization) 수준에서 캐시되어 여러 고객에게 재사용되는 시스템 프롬프트는 쓰기 비용(write cost)을 하나의 비용 센터(cost center)에 집중시키는 반면, 읽기 절감액(read savings)은 여러 곳으로 분산시킵니다. 균일한 할당 모델은 이를 잘못 배분하게 됩니다.
도구(Tool) 또는 함수 호출(function call) 토큰. Anthropic의 도구 사용은 tool_choice 설정에 따라 **497~675개의 시스템 토큰(system tokens)**을 추가합니다 (Anthropic 가격 정책, 2026년 5월). 도구는 무료가 아니며, 해당 비용은 호출을 트리거한 고객에게 귀속됩니다.
임베딩(Embeddings). 별도의 엔드포인트(endpoint)와 별도의 가격 정책이 적용됩니다.

종종 한 번 미리 계산(pre-computed)되어 여러 고객에게 재사용되므로, 고객별 모델이 달라집니다.

Batch API. Anthropic의 Batch API는 입력 및 출력 토큰 모두에 대해 50% 할인을 제공하며, 결과는 24시간 이내에 반환됩니다 (Anthropic 가격 정책, 2026년 5월 기준). OpenAI에도 이와 유사한 기능이 있습니다. 할인율은 매우 큽니다. 문제는 타이밍입니다. 비용이 발생하는 날짜가 고객의 상호작용이 발생한 날짜와 다릅니다.
스트리밍 응답 (Streaming responses). 토큰이 점진적으로 방출됩니다. 연결이 종료될 때가 아니라 응답 id에 바인딩해야 하며, 그렇지 않으면 연결이 끊어질 때 카운트가 유실됩니다.

아무도 언급하지 않는 예외 케이스들

모든 프로덕션 AI 제품은 동일한 다섯 가지 귀속(attribution) 예외 케이스에 직면합니다: 비동기 배치 API (async batch APIs), 백그라운드 워크플로우 (background workflows), 재시도 (retries), 다단계 에이전트 체인 (multi-step agent chains), 그리고 제공업체 장애 (provider failures)입니다. 단순한 귀속 모델은 이 각각의 상황에서 실패합니다.

비동기 및 배치 API (Async and batch APIs). 비용이 이를 트리거한 고객의 상호작용과 다른 날짜에 나타납니다. 이벤트 시간(event time)을 기준으로 하는 일일 장부는 잘못된 날짜를 기록할 것이며, 요청 생성 시간(request creation time)을 기준으로 하는 장부는 올바른 날짜를 기록할 것입니다.
명확한 고객이 없는 백그라운드 워크플로우 (Background workflows with no clear customer). 주기적인 재인덱싱 (re-indexing), 내부 평가 (internal evals), 캐시된 시스템 프롬프트 (cached system prompts) 등이 이에 해당합니다. 고객별 수치를 오염시키지 않도록 이들을 내부 customer_id로 라우팅하십시오.
재시도 (Retries). 제공업체는 두 번 청구하지만 고객의 상호작용은 한 번입니다. 경계(boundary)에서 한 번만 귀속시키되, 제공업체의 인보이스(invoice)와 대조할 때 일치하도록 재시도를 별도로 로그에 기록하십시오.
다단계 에이전트 체인 (Multi-step agent chains). 고객 A에게 서비스를 제공하는 에이전트가 고객 B와 공유되는 컨텍스트 객체(context object)를 로드합니다. 이것은 누구의 비용입니까? 하나의 규칙을 정하고 문서화하십시오: 요청 경계에서 귀속시키되, 고객 간 의존성에 대한 별도의 로그를 남기는 방식입니다.
제공업체 장애 (Provider failures). 고객의 요청은 실패했지만, 제공업체는 여전히 비용을 청구했습니다. 비용을 귀속시키거나, 비용 처리(write it off)하거나, 혹은 공통 비용으로 처리(socialize it)하십시오. 규칙을 정하십시오. 하위 마진(margin) 수치는 어떤 규칙을 선택하느냐에 따라 달라집니다.

참조 구현 (A reference implementation)

고객별 LLM 비용을 추적하기 위한 견고한 프로덕션 설정은 저렴한 보험 역할을 하는 제공업체 메타데이터(provider metadata), 신뢰할 수 있는 단일 원천(source of truth)으로서의 클라이언트 측 래퍼(client-side wrapper), 그리고 제공업체 인보이스(invoice)와 대조하는 야간 정산(nightly reconciliation)을 결합하는 것입니다. 아래 표는 네 가지 할당 패턴(attribution patterns)을 설정 비용, 정확도, 다중 제공업체(multi-provider) 환경에서의 정확성을 기준으로 비교합니다. 점수는 벤치마크 연구가 아닌, 저자가 실제 배포된 패턴들을 종합하여 작성한 것입니다.

패턴	설정 비용	할당 정확도	다중 제공업체	멀티 테넌트(Multi-tenant) 정확성	요청당 오버헤드
제공업체 메타데이터 (Provider metadata)	가장 낮음	제공업체에 따라 다름	아니오 (제공업체당 하나)	제한적 (앱 내부에서 실시간 아님)	없음
...

OpenAI SDK를 감싸는 최소한의 TypeScript 래퍼는 단일 함수로 구성됩니다. 이 함수는 customerId를 입력받고, user 파라미터가 설정된 상태로 제공업체를 호출하며, response.usage를 파싱하여 prompt_tokens, completion_tokens, 그리고 prompt_tokens_details.cached_tokens를 추출합니다. 그런 다음 각 수치에 로컬 가격 상수(pricing constant)를 곱하여 고객 ID, 모델, 세부 항목(line items), 총액이 포함된 타입화된 LLMCostEvent를 방출(emit)합니다. 가격 상수는 모델 및 세부 항목별로 하나의 항목이 들어있는 별도의 파일입니다. 제공업체가 가격을 인상하거나 캐시된 입력(cached-input) 요율을 추가하는 경우, 해당 파일만 수정하면 됩니다.

야간 정산(Nightly reconciliation)은 오차가 발생하는 비용 세부 항목을 잡아냅니다. 재시도(retries), 캐시 쓰기(cache writes), 그리고 모델링되지 않은 도구 토큰(tool tokens)이 일반적인 원인입니다. 제공업체 인보이스와 비교했을 때 몇 퍼센트 이상의 차이가 발생한다면, 이는 제공업체가 틀린 것이 아니라 가격표나 계측(instrumentation) 과정에서 세부 항목을 놓쳤다는 신호입니다.

할당 스택(attribution stack)을 직접 관리하고 싶지 않은 팀은 실시간 지갑 할당(wallet attribution)을 기본적으로 처리하는 사용량 기반 과금 플랫폼(usage-based billing platform)에 이를 위임할 수 있습니다. aibilling.dev의 더 광범위한 사용량 기반 과금 플랫폼 디렉토리에서 옵션들을 나란히 비교해 볼 수 있습니다.

고객별 LLM 비용을 추적할 수 있게 된 후 해야 할 일

고객별 비용 데이터는 그것이 의사결정을 변화시킬 때에만 유용합니다. 이 데이터가 이끌어내야 할 세 가지 의사결정이 있습니다.

고객별 마진(Margin) 수치를 산출하십시오. 고객당 매출에서 고객당 추론 비용(Inference cost) 및 기타 모든 비용을 차감하여 매월 계산합니다. 마진 수치는 "이 고객을 Sonnet으로 전환해야 합니다"라는 막연한 직감을 실제적인 논의로 바꿔주는 지표가 됩니다.

비용 기준 상위 5%에 대해 알림을 설정하십시오. 사용량(Usage) 기준이 아니라, 절대적인 모델 지출액(Model spend) 기준입니다. Ridgeway의 CFO 자문 프레임워크는 명확합니다: "상위 90백분위수(90th percentile) 관점은 매우 중요합니다. 대부분의 마진 급감은 헤비 유저(Heavy users)로부터 발생합니다." 상위 5%는 이미 다음 가격 책정 실패(Pricing failure)가 일어나고 있는 지점입니다.