MCP 사용량 측정: 과금 관련 예기치 못한 상황 없이 에이전트 도구 호출 추적하기

AI 에이전트는 단 하나의 사용자 요청을 모델 호출, MCP 도구 호출, 재시도(retries), 부분적 실패, 그리고 백그라운드 작업의 작은 폭풍으로 변환할 수 있습니다. 만약 최종 응답만을 측정한다면, 당신은 추측을 하고 있는 것입니다. 맥락(context) 없이 모든 저수준(low-level) 이벤트를 측정한다면, 고객이 신뢰하지 않을 노이즈를 생성하게 됩니다.

이것이 바로 많은 AI 제품 빌더들이 빠지는 과금의 함정입니다. 제품은 단순해 보이지만, 그 이면의 사용량은 다단계이며, 비결정론적(non-deterministic)이고, 논쟁의 여지가 생기기 쉽습니다.

MCP는 이를 더욱 시급하게 만듭니다. Model Context Protocol (MCP)은 에이전트에게 도구를 호출하는 표준화된 방식을 제공하지만, 표준화된 도구 호출이 공정한 사용량 측정(usage meter)과 동일한 것은 아닙니다. 프로덕션 환경의 측정 시스템은 더 어려운 질문에 답할 수 있어야 합니다:

어떤 고객, 워크스페이스, 사용자, 그리고 에이전트 실행이 호출을 발생시켰는가?
읽기 전용(read-only)이었는가, 아니면 쓰기 가능(write-capable)이었는가?
호출이 재시도되었는가, 중복되었는가, 캐시되었는가, 거부되었는가, 아니면 실제로 실행되었는가?
유료 업스트림 API(paid upstream API)를 호출했는가?
할당량(quota), 인보이스(invoice), 남용 제한(abuse limits)에 포함되어야 하는가, 아니면 관찰 가능성(observability) 용도로만 사용되어야 하는가?
개인적인 프롬프트나 고객 데이터를 노출하지 않고 비용을 설명할 수 있는가?

이 가이드는 사용자에게 예기치 못한 비용을 발생시키지 않으면서 비용 제어가 필요한 1인 개발자, 마이크로 제품 팀, 그리고 AI 플랫폼 빌더를 위한 실질적인 MCP 사용량 측정 아키텍처를 보여줍니다.

MCP 사용량 측정이 토큰 추적과 다른 이유

토큰 추적(Token tracking)은 대부분 선형적입니다. 프롬프트를 보내고, 응답을 받고, 입력 토큰, 출력 토큰, 모델, 지연 시간(latency), 그리고 비용을 기록합니다.

에이전트의 도구 사용은 훨씬 더 복잡합니다.

"이 계정들을 조사하고 CRM을 업데이트해줘"와 같은 단일 요청은 다음과 같은 작업을 트리거할 수 있습니다:

고객 규칙을 가져오기 위한 검색(retrieval) 호출
각 계정에 대한 검색(search) 도구 호출
누락된 필드를 위한 브라우저 또는 인리치먼트(enrichment) 호출
CRM 읽기(read)
CRM 쓰기 제안(write proposal)
인간의 승인을 위한 일시 중지
최종 쓰기(write) 호출
요약 응답

어떤 호출은 내부적(internal)입니다. 어떤 호출은 고객에게 노출됩니다. 어떤 호출은 비용이 많이 들고, 어떤 호출은 위험합니다. 어떤 호출은 무료이지만 속도 제한(rate limit)을 걸어야 합니다. 어떤 호출은 실제 작업을 수행한 후 실패하기도 합니다. 어떤 호출은 에이전트(agent), SDK, 큐(queue), 또는 네트워크 계층(network layer)에 의해 재시도(retry)됩니다.

만약 MCP 호출당 무분별하게 과금한다면, 사용자들은 자신들이 제어할 수 없는 모델의 동작에 대해 처벌받는다고 느낄 것입니다. 반대로 모든 비용을 회사가 부담한다면 마진(margin)이 사라질 것입니다. 중간 경로는 명확한 이벤트 유형, 멱등성(idempotency), 할당량(quota), 가격 책정 규칙(pricing rules) 및 영수증(receipt)을 갖춘 사용량 원장(usage ledger)을 구축하는 것입니다.

핵심: 고객은 사용량 기반 과금을 싫어하는 것이 아니라, 불투명한 과금을 싫어하는 것입니다.

사용량 기반 가격 책정(Usage-based pricing)은 가치와 매칭될 때 공정할 수 있습니다. 개발자들은 이미 API 호출, 컴퓨팅 시간(compute minutes), 스토리지(storage), 시트(seats), 메시지(messages) 개념을 이해하고 있습니다.

문제는 '예상치 못한 상황'입니다.

사용자가 한 가지 작업을 요청했습니다. 에이전트는 47번의 호출을 수행합니다. 청구서에는 "47회의 도구 호출(tool invocations)"이라고 적혀 있습니다. 사용자는 합리적으로 질문합니다. "왜 이렇게 많이 나왔죠?"

여러분의 계측기(meter)는 답변을 쉽게 만들어 주어야 합니다:

"이 워크플로(workflow)는 과금 대상인 데이터 보강(enrichment) 호출 12회, CRM 쓰기 시도 3회, 승인된 내보내기(export) 1회를 사용했습니다. 내부 계획(internal planning), 캐시된 읽기(cached reads), 실패한 유효성 검사 호출, 그리고 안전 점검(safety checks)은 과금되지 않았습니다. 여기 실행 영수증이 있습니다."

이러한 문장은 단순히 낮은 가격보다 더 큰 신뢰를 구축합니다.

MCP 사용량 계측을 위한 간단한 아키텍처

MCP 사용량 계측을 다섯 가지 계층으로 생각하십시오:

캡처(Capture): MCP 경계(boundary)에서 모든 도구 호출을 포착합니다.
분류(Classify): 테넌트(tenant), 도구, 작업 유형, 위험도 및 과금 정책에 따라 각 이벤트를 분류합니다.
중복 제거(Deduplicate): 멱등성 키(idempotency keys)를 사용하여 재시도 및 반복된 전달을 제거합니다.
집계(Aggregate): 이벤트를 가격 책정 모델에 맞는 사용 기록으로 집계합니다.
노출(Expose): 영수증, 할당량 상태 및 감사 로그(audit logs)를 사용자에게 제공합니다.

기본적인 흐름은 다음과 같습니다:

에이전트 실행 (Agent run)
  -> MCP 게이트웨이 또는 래퍼 (MCP gateway or wrapper)
    -> 도구 호출 이벤트 (tool invocation event)
...

첫날부터 복잡한 과금 시스템이 필요하지는 않습니다. 하지만 처음부터 반드시 지켜야 할 불변의 원칙(invariant)이 하나 있습니다:

모든 과금 대상 도구 이벤트는 고객에게 노출되는 작업으로 추적 가능해야 하며, 나중에 설명하기에 안전해야 합니다.

경계에서 도구 호출 캡처하기

MCP 사용량을 측정하기에 가장 깔끔한 위치는 에이전트가 도구를 호출하는 경계(boundary)입니다. 그 위치는 다음과 같을 수 있습니다:

MCP 서버 앞단의 HTTP 프록시 (HTTP proxy)
로컬 MCP 서버를 감싸는 stdio 래퍼 (stdio wrapper)
애플리케이션 내부의 도구 게이트웨이 (tool gateway)
도구 실행을 감싸는 프레임워크 미들웨어 (framework middleware)

목표는 단순히 호출 횟수를 세는 것이 아닙니다. 나중에 과금 (billing), 할당량 (quotas), 지원 (support) 및 디버깅 (debugging)을 지원할 수 있는 최소한의 이벤트를 캡처하는 것입니다.

유용한 이벤트 형태는 다음과 같습니다:

type ToolUsageEvent = {
  event_id: string;
  idempotency_key: string;
...

저장되지 않는 항목들에 주목하세요: 원문 프롬프트 (raw prompts), 원문 자격 증명 (raw credentials), 전체 도구 인자 (full tool arguments), 또는 개인적인 결과 본문 (private result bodies)입니다. 명확한 보유 정책 (retention policy)과 더 많은 정보를 유지해야 할 사용자 대상의 이유가 없다면, 해시 (hashes), 참조 (references), 그리고 안전한 요약 (safe summaries)을 저장하세요.

무엇을 과금 대상으로 할지 결정하기

모든 도구 호출이 비용 청구로 이어져서는 안 됩니다. 만약 모델이 불확실성 때문에 검증 도구 (validation tool)를 세 번 호출했다면, 고객이 자동으로 세 번의 비용을 지불해서는 안 됩니다.

네 가지 범주로 시작해 보세요.

이벤트 유형 (Event type)	예시 (Example)	일반적으로 과금 대상인가?
내부 추론 지원 (Internal reasoning support)	정책 조회 (policy lookup), 스키마 가져오기 (schema fetch), 캐시된 컨텍스트 읽기 (cached context read)	아니오
...

A 좋은 규칙은 에이전트의 혼란 (agent confusion)이 아니라, 전달된 가치 (value delivered) 또는 발생한 비용 (cost incurred)에 대해 과금하는 것입니다.

이는 모든 호출을 내부적으로 추적하면서도, 더 작은 하위 집합에 대해서만 과금할 수 있음을 의미합니다. 이를 통해 모든 에이전트의 행동을 송장 항목 (invoice line)으로 만들지 않고도 가시성 (visibility)을 확보할 수 있습니다.

가격 책정을 적용하기 전에 멱등성(Idempotency)을 사용하세요

과금 버그는 종종 재시도 (retry) 버그에서 시작됩니다.

상위 시스템 (upstream system)이 작업을 완료한 후 도구 호출이 타임아웃 (timeout)되는 상황을 가정해 봅시다. 에이전트는 재시도합니다. 귀하의 측정기 (meter)는 두 번의 성공적인 호출을 기록합니다. 고객은 이중 청구를 보게 됩니다. 고객 지원 팀은 깔끔한 답변을 내놓을 수 없습니다.

가격 책정 로직을 구축하기 전에 사용량 계층 (usage layer)에서 멱등성 (idempotency)을 추가하세요.

실용적인 키 (key)에는 다음이 포함될 수 있습니다:

tenant_id + agent_run_id + step_id + tool_name + normalized_argument_hash + billing_intent

그런 다음 이 규칙을 강제하세요:

async function recordUsage(event: ToolUsageEvent) {
  const existing = await db.usage_events.findUnique({
    where: { idempotency_key: event.idempotency_key }
...```

멱등성 (Idempotency)은 중복 실행을 잡아낼 수 있을 만큼 충분히 안정적이어야 하지만, 정당한 반복 작업을 숨길 정도로 광범위해서는 안 됩니다. 위험도가 높은 쓰기 도구 (write tools)의 경우, 과금 측 (billing-side) 키뿐만 아니라 도구 측 (tool-side) 멱등성 키와도 함께 쌍을 이루어야 합니다.

## 가격 책정 규칙을 프롬프트 텍스트가 아닌 설정으로 추가하기

모델에게 무엇이 과금 대상인지 결정하도록 요청하지 마세요. 에이전트는 의도 (intent)를 설명할 수 있지만, 과금 정책 (billing policy)은 코드와 설정의 영역입니다.

시작 단계에서는 작은 가격 책정 규칙 테이블만으로도 충분합니다:

```json
[
  {
    "server": "crm",
...

가장 구체적인 것부터 가장 덜 구체적인 순서로 매칭하세요:

정확한 서버 및 도구 (exact server and tool)
정확한 서버 와일드카드 도구 (exact server wildcard tool)
액션 유형 (action type)
전체 적용 기본값 (catch-all default)

기본값은 보수적으로 유지하세요. 알 수 없는 도구는 검토될 때까지 과금되지 않거나, 명확하게 라벨링된 내부 비용 예산 (internal cost budget)에 대해서만 과금되어야 합니다. 새로 추가된 도구로 인해 발생하는 예기치 못한 과금은 신뢰를 빠르게 잃는 지름길입니다.

비용이 많이 드는 호출 앞에 할당량 (Quotas) 배치하기

사후에만 보고하는 미터 (meter)는 회계에는 유용하지만, 제품 안전성 측면에서는 취약합니다. 에이전트는 비용이 많이 들거나 위험한 호출을 하기 전에 사전 비행 할당량 체크 (pre-flight quota checks)가 필요합니다.

과금 대상인 MCP 도구를 실행하기 전에 다음을 확인하세요:

남은 워크스페이스 크레딧 (remaining workspace credits)
실행당 예산 (per-run budget)
사용자당 일일 한도 (per-user daily cap)
도구당 속도 제한 (per-tool rate limit)
위험 등급 승인 상태 (risk-tier approval state)
월간 하드 리밋 (monthly hard limit)

간단한 할당량 체크는 다음과 같은 실행 결정 (execution decision)을 반환할 수 있습니다:

type QuotaDecision =
  | { allow: true; reservation_id: string }
  | { allow: false; reason: "budget_exceeded" | "approval_required" | "rate_limited" };
...

에이전트 워크플로우는 병렬로 진행되기 때문에 예약 (Reservations)이 중요합니다. 예약이 없다면, 10개의 병렬 도구 호출이 모두 동일한 잔액을 확인하고 이를 초과하여 지출할 수 있습니다.

사용 영수증을 제품 UX의 일부로 만들기

청구서 발행일까지 사용량을 숨기지 마세요. 사용자에게 실행 단위의 영수증 (run-level receipt)을 제공하세요.

유용한 영수증에는 다음이 포함됩니다:

작업 이름 또는 에이전트 실행 라벨 (agent run label)
시작 및 종료 시간
총 과금 단위 (total billable units)
비과금 내부 호출 (non-billable internal calls)
안전한 설명이 포함된 고비용 도구 호출 (expensive tool calls)
거부되었거나 승인이 필요한 호출
비용을 절감한 캐시된 호출 (cached calls)
추정 비용 또는 사용된 크레딧
관리자를 위한 트레이스 (trace) 또는 감사 로그 (audit log) 링크

예시:

실행 (Run): 25개 체험 계정 정보 보강 (Enrich 25 trial accounts)
과금 대상 사용량 (Billable usage):
- 25개 기업 정보 보강 레코드 (company enrichment records)
...

이를 통해 미터링 (metering)은 단순한 재무 기능에서 신뢰 기능 (trust feature)으로 전환됩니다. 또한 사용자가 "무슨 일이 일어났나요?"라는 질문에 스스로 답할 수 있게 되어 고객 지원 부하를 줄여줍니다.

실패, 캐시 및 부분적 호출을 주의 깊게 처리하기

이 지점이 많은 미터링 시스템이 허술해지는 구간입니다.

명시적인 규칙을 사용하세요:

실행 전 실패: 과금 대상 아님
상위 비용 지불 후 실패: 통과 비용 (pass-through)으로서 과금될 수 있으나, 명확하게 라벨을 붙일 것
검증 거부 (Validation rejected): 과금 대상 아님
캐시된 결과 (Cached result): 일반적으로 과금 대상이 아니거나, 더 낮은 단위 비용으로 과금됨
부분적 성공 (Partial success): 성공한 단위만 과금
사람에 의한 거부 (Human rejected): 쓰기 (write) 작업은 과금하지 않되, 이를 준비하는 데 사용된 고비용 읽기 (read) 작업은 계산할 수 있음
상태를 알 수 없는 제공자 타임아웃 (Provider timeout): 즉시 청구하지 말고 대기 중인 조정 (pending reconciliation) 상태로 유지

실행 상태와 분리된 billing_state를 추가하세요:

execution_status: succeeded | failed | timeout | rejected
billing_state: pending | billable | non_billable | disputed | reversed

이렇게 하면 원장 (ledger)을 손상시키지 않고 불확실한 이벤트를 조정할 수 있는 여유를 가질 수 있습니다.

청구 전 사용량 조정 (Reconcile)

소규모 팀의 경우 매일 조정하는 것으로 충분합니다. 사용량이 청구 가능한 상태가 되기 전에 다음과 같은 체크를 실행하세요:

중복된 멱등성 키 (idempotency keys)
도구 트레이스 (tool traces)는 실패했으나 과금 이벤트는 성공한 경우
과금 대상인 알 수 없는 도구
음수 또는 불가능한 단위 수
테넌트 (tenant) 또는 실행 ID (run ID)가 누락된 이벤트
커밋되거나 해제되지 않은 예약 (reservations)
정상 범위를 벗어난 사용량 급증
고객에게 보이는 영수증 항목이 없는 고비용 호출

간단한 야간 작업(nightly job)을 통해 이벤트를 청구 준비 상태로 표시할 수 있습니다:

UPDATE usage_events
SET billing_state = 'billable', invoice_ready_at = now()
WHERE status = 'succeeded'
...

이러한 지연은 의도된 것입니다. 이를 통해 청구가 확정되기 전에 지연된 실패(late failures), 중복 전달(duplicate delivery), 큐 재시도(queue retries), 그리고 도구 콜백(tool callbacks)이 안정화될 시간을 확보할 수 있습니다.

상위 콘텐츠들이 흔히 놓치는 것들

MCP 과금 및 AI 에이전트 미터링(metering)과 관련된 현재의 검색 결과들은 대개 다음 세 가지 관점 중 하나에 집중하는 경향이 있습니다:

호출당 과금(per-call), 구독형(subscription), 프리미엄(freemium), 또는 결과 기반 과금(outcome-based billing)과 같은 가격 모델
MCP 도구의 지연 시간(latency) 및 오류에 대한 관측성(observability)
특정 제품 전용 미터링 도구 또는 게이트웨이 문서

이러한 정보들도 유용하지만, 빌더(builders)들에게 가장 필요한 운영 계층(operational layer)은 종종 생략되곤 합니다: 멱등성(idempotent) 사용 이벤트, 할당량 예약(quota reservations), 고객 가시적 영수증(customer-visible receipts), 과금 상태 전환(billing-state transitions), 대조(reconciliation), 그리고 분쟁 방지용 감사 추적(dispute-safe audit trails) 등이 바로 그것입니다.

이 아키텍처는 바로 그 간극을 메웁니다. 단순히 도구 호출에 대해 비용을 청구하는 것만으로는 충분하지 않습니다. 어떤 호출이 집계되었는지, 왜 집계되었는지, 그리고 반복되거나 실패한 호출이 왜 청구서의 노이즈가 되지 않았는지를 증명할 수 있어야 합니다.

구현 체크리스트

MCP 이벤트를 과금 시스템에 연결하기 전에 다음 체크리스트를 사용하십시오:

FAQ

MCP 사용량 미터링(usage metering)이란 무엇인가요?

MCP 사용량 미터링 (usage metering)은 할당량 (quotas), 비용 제어 (cost control), 과금 (billing), 관측성 (observability), 그리고 고객에게 공개되는 사용 영수증 (usage receipts)을 지원할 수 있을 만큼 충분한 문맥과 함께 Model Context Protocol 도구 호출을 추적하는 프로세스입니다. 단순히 호출 횟수 이상을 추적해야 하며, 테넌트 (tenant), 실행 (run), 도구 (tool), 상태 (status), 멱등성 (idempotency), 그리고 과금 상태 (billing state)를 포함해야 합니다.

모든 MCP 도구 호출이 과금 대상이어야 하나요?

아니요. 많은 도구 호출은 내부 지원 작업, 캐시된 읽기 (cached reads), 유효성 검사 (validation checks), 또는 재시도 (retries)입니다. 공정한 시스템은 모든 호출을 추적하되, 명확한 가격 정책 (pricing policy), 전달된 가치 (delivered value), 또는 실제 업스트림 비용 (upstream cost)과 일치하는 이벤트에 대해서만 과금합니다.

에이전트의 재시도로 인한 중복 과금을 어떻게 방지하나요?

사용량 이벤트에 대해 멱등성 키 (idempotency keys)를 사용하고, 가능한 경우 도구 동작 (tool action) 자체에도 사용하십시오. 키에는 테넌트 (tenant), 실행 (run), 단계 (step), 도구 (tool), 정규화된 인자 (normalized arguments), 그리고 과금 의도 (billing intent)가 포함되어야 합니다. 중복된 전달이 발생할 경우, 새로운 과금을 생성하는 대신 기존의 사용 기록을 반환해야 합니다.

Insights