진짜로 유용한 일을 하는 MCP 서버를 하나 공개했다고 합시다. 예컨대 부품 카탈로그에 대한 구조화된 접근이나 문서 요약 도구 같은 것이요. 그러던 어느 아침, 한 번도 만난 적 없는 AI 에이전트들이 밤새 보내온 40,000건의 도구 호출을 마주하게 됩니다. 꿈같은 일이죠. 하지만 당신의 청구 미터, 장부, 세무 설정이 모두 인간의 속도로 버튼을 클릭하는 인간을 위해 설계되었다는 사실을 깨닫기 전까지만요. 에이전트는 인간 사용자처럼 행동하지 않습니다. 하나의 프롬프트가 몇 초 만에 수십 개의 도구 호출을 연쇄적으로 일으키고, 단 하나의 지시를 해결하기 위해 수천 건의 요청을 반복하며, 모든 단계에서 다운스트림 비용을 유발합니다. 접근 권한에 요금을 부과한다면, 에이전트가 소비하는 방식에 맞는 미터링, 가치가 전달되는 시점에 맞는 수익 기록, 그리고 마진을 가시적으로 유지해 주는 비용 추적이 모두 필요합니다. 이 가이드에서 그 세 가지를 모두 다룹니다.
MCP 수익이 실제로 들어오는 방식
Model Context Protocol은 당신의 서버를 AI 클라이언트가 JSON-RPC를 통해 호출하는 도구와 리소스의 집합으로 노출합니다. 모든 호출이 프로그래밍 방식이기 때문에, 전통적인 SaaS 좌석제보다 훨씬 다양한 가격 옵션이 생깁니다. 그리고 각 옵션은 장부에 다르게 기록됩니다.
도구 호출당 과금. 가장 단순한 모델로, 각 메서드 호출에 고정 금액을 부과합니다. 미터링하기 쉽고 설명하기 쉬우며, 도구들의 비용이 대체로 균일할 때 잘 작동합니다. 하지만 가벼운 메타데이터 조회는 거의 비용이 들지 않는 반면, 워크플로 도구는 수십 개의 다운스트림 API 호출로 확산되는 경우에는 무너집니다.
데이터 볼륨 기준. 메서드가 문서 내용, 임베딩, 쿼리 결과 같은 대용량 페이로드를 반환할 때, 반환된 메가바이트당 또는 천 토큰당 과금하면 모델 제공업체가 자체 API 가격을 책정하는 방식처럼 가격을 비용에 맞출 수 있습니다.
결과 기준. 시도당 과금 대신 완료된 작업당 과금합니다. 문서 하나가 성공적으로 요약된 건당, 실행된 기기 명령당, 유효한 결과를 반환한 쿼리당 등입니다. 고객은 실패하거나 빈 호출이 무료라서 좋아합니다. 다만 단위를 계산하기 전에 성공과 실패를 구분할 수 있는 미터링이 필요합니다.
세션 또는 메모리 기준. 호출 간에 대화 상태를 유지하는 서버는 생성된 세션당, 활성 세션 시간의 분당, 또는 보유한 컨텍스트 블록당 과금할 수 있습니다. 이는 당신의 메모리 계층에 의존하는 어시스턴트와 장시간 실행되는 에이전트에 적합합니다.
하이브리드 구독 + 초과 사용. 할당량이 포함된 기본 월 요금과 임계치 초과 시 종량제 요금이 결합된 형태입니다. 기본 요금이 고정 비용을 충당하고 초과 사용이 헤비 유저와 함께 확장되기 때문에, 프로덕션 API 비즈니스에서 가장 흔한 형태입니다.
선불 크레딧. 고객이 사용량 블록을 미리 구매하고 차감해 나가는 방식입니다. 현금 흐름에는 좋지만 회계는 더 까다롭습니다(아래에서 자세히 다룹니다). 수령한 현금은 크레딧이 소비되기 전까지는 벌어들인 수익이 아니기 때문입니다.
마켓플레이스 정산금. MCP 서버 관련 리스팅과 마켓플레이스는 수익 배분을 가져가고 나머지를 당신에게 지급합니다. 모든 앱 마켓플레이스를 통해 판매하는 것과 같은 형태이며, 총액 대 순액 회계라는 동일한 질문을 던집니다.
에이전트 네이티브 소액 결제. x402 같은 프로토콜은 에이전트가 HTTP를 통해 스테이블코인으로 요청당 결제할 수 있게 해 주며, 계정 가입도 인보이스도 필요 없습니다. 이 방식을 택하면 모든 도구 호출이 그 자체로 작은 판매가 될 수 있고, 이는 수익과 원가 기준을 기록하는 방식에 실질적인 영향을 미칩니다. (이러한 기계 결제가 어떻게 작동하는지에 대한 배경은 x402를 통한 AI 에이전트 간 결제 가이드를 참조하세요.)
고객이 가치로 인식하는 미터를 선택하세요. 그것은 제품 결정입니다. 다만 위의 각 선택이 서로 다른 회계 패턴을 만든다는 점을 알아두세요. 이 가이드의 나머지 부분은 각 방식에서 돈이 어떻게 흘러가는지 따라갑니다.
당신의 미터가 곧 회계 원본 문서
사용량 기반 비즈니스에서 사용 이벤트 스트림은 법률 사무소의 타임시트와 같습니다. 인보이스의 모든 달러를 정당화하는 원본 기록인 것입니다. 그렇게 취급하세요.
표준 구조는 이렇습니다. 서버가 청구 가능한 단위마다 사용 이벤트를 발생시킵니다. 메서드 이름, 고객 식별자, 수량, 타임스탬프, 성공 또는 실패 여부입니다. 이 이벤트들은 미터링 계층(Stripe Billing Meters, 사용량 기반 청구 플랫폼, 또는 자체 집계기)으로 흘러 들어가 고객별로 귀속되고 기말 인보이스로 집계됩니다. Stripe의 종량제 청구가 정확히 이 형태를 따릅니다. 청구 주기 동안 사용량을 보고하면, 기말에 기록을 집계하여 총액을 청구합니다.
이 파이프라인에서 세 가지 회계 원칙이 도출됩니다.
- 매 주기마다 미터와 인보이스를 대사하세요. 미터링 단위 곱하기 요율은 청구된 사용량 수익과 일치해야 합니다. 출하 단위 곱하기 가격이 매출과 일치해야 하는 것과 같습니다. 차이가 있다면, 그것은 의도한 무료 티어 사용량이거나, 결과 기반 가격이 용서한 실패한 호출이거나, 누수입니다. 즉 미터가 보지 못한 사용량입니다. 누수는 조용한 킬러입니다. 인증되지 않은 엔드포인트나 미터링되지 않은 도구는 당신이 벌었지만 결코 받지 못할 수익입니다.
- 원시 사용 로그를 감사 추적으로 보관하세요. 집계는 청구에 쓰이는 것이고, 이벤트 수준 로그는 고객이 급증에 이의를 제기하거나 회계사가 수익 숫자의 구성 요소를 물을 때 제시하는 것입니다. 최소한 인보이스 분쟁 기간만큼, 이상적으로는 세무 기록 기간만큼 보관하세요.
- 경계에서 신원을 귀속하세요. 청구 대상이 프롬프트 뒤의 최종 사용자인지, 당신의 서버를 통합한 API 키 보유자인지 결정하고, 그 결정을 이벤트에 기록하세요. 하나의 엔터프라이즈 키가 50명 직원의 에이전트로 확산될 때, "고객이 누구인가"는 단순한 청구 세부사항이 아니라 세무적 결과를 수반하는 회계 질문입니다.
사용량 수익을 올바르게 기록하기
여기서 MCP 운영자들이 가장 자주 실수합니다. 현금이 Stripe에 들어오면 그것을 수익으로 기록하고, 장부는 조용히 현실과 어긋나기 시작합니다. 수익 인식 기준인 ASC 606에 따르면, 소비 기반 가격 책정의 규칙은 명확합니다. 고객이 소비함에 따라 수익을 인식하세요. 소비된 각 단위가 바로 이행되는 수행 의무이기 때문입니다. 사용 요금은 변동 대가이며, 이는 계약이 가치 있다고 기대하는 것이 아니라 해당 기간에 실제로 사용된 것을 인식한다는 뜻입니다.
순수 종량제는 쉬운 경우입니다. 에이전트가 9월에 당신의 정가로 100,000건의 호출을 소비했다면, 인보이스가 10월에 지급되더라도 9월 수익은 100,000 곱하기 요율입니다. 인보이스 발행 시 매출채권을, 사용이 발생한 시점에 수익을 기록하세요. ASC 606에 따른 토큰 및 사용량 미터링의 전체 처리를 원한다면, 토큰 청구와 사용량 기반 SaaS 수익 인식 가이드에서 더 깊이 다룹니다.
하이브리드 기본 요금 + 초과 사용은 둘로 나뉩니다. 기본 구독은 서비스 기간에 걸쳐 정액으로 인식하고(월간 요금제에서 하루당 1/30), 초과 사용은 초과 사용이 발생함에 따라 인식합니다. 이 둘은 별도의 수익 계정에 유지하세요. 이들을 혼합하면 실제로 비즈니스를 운영하는 두 숫자가 가려집니다. 예측 가능한 구독 MRR과 변동이 큰 소비 수익입니다.
선불 크레딧은 수익이 아니라 부채를 만듭니다. 고객이 크레딧 블록을 구매하면 현금을 차변에, 이연 수익을 대변에 기록합니다. 사용량이 잔액을 차감할 때마다 소비된 가치를 이연 수익에서 벌어들인 수익으로 이동시킵니다. 고객이 결코 사용하지 않는 잔여분, 즉 소멸(breakage)에는 자체 규칙이 있습니다. 이력이 미사용 몫을 신뢰성 있게 추정할 수 있게 해 준다면, 그 예상 소멸분을 실제 사용량에 비례하여 점진적으로 인식합니다. 추정하기에는 너무 신생이라면, 크레딧이 만료되거나 환급 가능성이 희박해질 때까지 기다렸다가 나머지를 인식합니다. 신규 MCP 서버는 거의 항상 후자에 해당하므로, 한 달을 좋아 보이게 하려고 예상 소멸분을 미리 기록하지 마세요.
결과 기반 가격은 타이밍 문제를 하나 더합니다. 수익은 호출이 시작될 때가 아니라 결과가 달성되고 측정 가능해질 때 인식됩니다. 미터가 성공한 완료만 계산한다면, 수익 기록도 같은 카운터를 따라야 합니다. 미터와 원장은 "판매"가 무엇인지에 대해 합의해야 합니다.
이 모든 것을 견딜 수 있게 해 주는 두 가지 실천 습관이 있습니다. 첫째, 청구 미터별(호출당 도구, 데이터 볼륨, 세션, 초과 사용)로 별도의 수익 계정이나 태그를 운영하세요. 그래야 한 도구의 마진 문제가 혼합된 총액 안에 숨지 않습니다. 둘째, 월말 마감 기준을 강제하세요. 9월에 타임스탬프된 사용량은 인보이스가 10월 2일에 확정되더라도 9월에 속합니다. 배치 지연이 있는 미터링 파이프라인은 마감 오류를 사용량 비즈니스에서 가장 흔한 허위 기재로 만듭니다.
비용 측면: MCP 서버의 실제 비용
도구 호출당 수익은 도구 호출당 비용 없이는 아무 의미가 없습니다. 매출원가를 밑에서부터 쌓아 올리세요.
- 컴퓨팅 및 호스팅. 도구를 실행하는 서버, 컨테이너, 서버리스 호출, 그리고 페이로드가 많은 메서드의 송신 대역폭.
- 다운스트림 API 및 모델 비용. 고객을 대신해 도구가 수행하는 모든 LLM 호출, 임베딩 조회, 검색 쿼리, 서드파티 API 호출. 요약 도구가 문서당 모델 제공업체를 호출한다면, 그 패스스루가 가장 큰 변동 비용이며 월별 일괄이 아니라 도구별로 추적해야 합니다.
- 데이터 및 라이선스 비용. 서버가 노출하는 독점 데이터에 대한 로열티나 쿼리당 수수료.
- 마켓플레이스 수익 배분. 플랫폼이 가져가는 마켓플레이스 판매 몫은 판매 비용입니다(또는 순 정산금에서 차감 — 하나를 선택하고 일관되게 유지하세요). 결코 수익 안에 묻힌 상쇄로 처리해서는 안 됩니다.
- 결제 처리. 구독 청구의 카드 수수료, 인보이스의 게이트웨이 수수료, 스테이블코인 정산의 네트워크 수수료. 소액 결제 규모에서는 이것이 아픕니다. 고정 거래당 수수료가 1센트 미만 도구 호출의 마진을 초과할 수 있으며, 바로 이것이 에이전트 결제 프로토콜이 저수수료 레일로 정착한 이유입니다.
가격을 책정하기 전에 도구별로 단위 계산을 실행하세요. 카탈로그 조회 도구가 호출당 컴퓨팅과 다운스트림 쿼리에 0.004달러가 들고 0.01달러를 청구한다고 가정합시다. 60퍼센트 총마진처럼 보입니다. 하지만 지원, 미터링 인프라, 실패한 호출 용서가 이를 끌어내리기 전까지만요. 느낌이 아니라 측정된 비용에서 가격을 책정하고, 다운스트림 제공업체가 요율을 변경할 때마다 계산을 다시 실행하세요.
스테이블코인 수령은 별도의 단락이 필요합니다. 세무 목적상 스테이블코인은 통화가 아니라 재산입니다. 수령 시점의 공정 시장 가치가 당신의 수익이고, 그 가치가 원가 기준이 됩니다. 코인을 보유하다가 페그가 흔들리거나 나중에 다른 가치로 전환하면, 그 차이는 이익 또는 손실입니다. 소액 결제 규모에서는 거래별 추적이 필수입니다. 집계 추측은 세무 조사를 견디지 못하므로, 연말에 재구성하는 대신 정산 기록을 자동으로 장부에 흘려보내세요.
판매세: 당신의 API는 생각보다 많은 주에서 과세 대상
대부분의 MCP 운영자를 기다리는 규정 준수 surprise가 있습니다. API 접근 판매는 소프트웨어나 디지털 제품 판매이며, 주들이 그 정의를 빠르게 확장하고 있습니다.
- 캘리포니아는 2026년 6월 SB 122에 서명하여 원격 접근 소프트웨어와 SaaS를 포함한 디지털 제품에 판매세를 확대했고, 2027년 1월 1일 발효됩니다. 이는 미국 최대 주 시장에서 수십 년간의 면세를 끝내는 것입니다.
- 시카고는 일리노이주가 주 차원에서 SaaS에 과세하지 않음에도 불구하고, 개인 재산 임대 거래세(Personal Property Lease Transaction Tax)로 SaaS와 클라우드 소프트웨어에 9퍼센트를 과세합니다.
- 오클라호마는 반대로 전자적으로 전달되는 SaaS 구독이 면세라고 판결했습니다. 전국적으로 하나의 답을 가정할 수 없다는 증거입니다.
경제적 넥서스 임계치는 어디서 징수해야 하는지를 결정합니다. 판매세가 있는 대부분의 주는 원격 판매자에게 10만 달러 매출 임계치를 적용하며, 캘리포니아, 텍사스, 뉴욕은 50만 달러입니다. 전국적 범위의 종량제 API는 한 번도 발을 들인 적 없는 주에서 순전히 거래량만으로 임계치를 넘을 수 있습니다.
이에 대한 대응:
- 거주지가 아니라 고객이 있는 주별로 과세 여부를 결정하세요. 미터는 이미 귀속을 위해 고객 위치를 기록합니다. 그 데이터를 넥서스 추적에 재사용하세요.
- 마켓플레이스 판매는 커버될 수 있습니다. 마켓플레이스가 마켓플레이스 퍼실리테이터 자격을 갖추면, 그를 통한 판매의 세금을 징수하고 납부합니다. 자체 사이트나 자체 x402 엔드포인트를 통한 직접 판매는 전적으로 당신의 책임입니다.
- 징수를 일찍 자동화하세요. 결제에 연결된 세무 엔진(Stripe Tax 및 그 경쟁사)은 수십 개 주에 수동으로 등록, 신고, 납부하는 것보다 훨씬 저렴하며, 감사관이 요구하는 고객 위치 증거를 유지해 줍니다.
- 달력을 주시하세요. 캘리포니아의 2027년 발효일과 다른 의회에서 진행 중인 유사한 확대와 함께, "우리는 걱정하기엔 너무 작다"는 태도는 빠르게 만료됩니다.
마켓플레이스 정산금과 세무 양식
수익 중 일부가 마켓플레이스 정산금으로 들어온다면, 앱스토어 개발자들이 하는 방식으로 기록하세요. 총액 판매를 수익으로, 플랫폼의 몫을 비용으로 기록합니다. 당신의 1099-K(또는 플랫폼의 분류에 따라 1099-NEC)는 총액을 보고하며, IRS는 그 숫자를 당신의 신고서와 대조합니다. 순 입금액만 보고하는 것이 바로 과소 신고 통지가 시작되는 방식입니다. 총 정산 명세서를 순 은행 입금액과 매달 대사하고, 차이를 설명하는 수수료 일정을 보관하세요.
타이밍 격차도 유의하세요. 플랫폼의 정산일은 당신의 수익일이 아닙니다. 수익은 최종 고객의 에이전트가 당신의 도구를 소비한 기간에 속합니다. 마켓플레이스가 2주 후에 지급하더라도 마찬가지입니다. 직접 판매에도 같은 원칙이 적용됩니다. 사용 기간이 기준이며 정산일이 아닙니다.
MCP 운영자를 위한 월말 체크리스트
매달 같은 방식으로 장부를 마감하면 예외 상황이 복리로 쌓이는 것을 멈춥니다.
- 고객별, 미터별 미터링 사용량을 가져와 청구된 사용량 수익과 맞추세요. 무료 티어와 실패 용서 기준선을 초과하는 차이를 조사하세요.
- 하이브리드 인보이스를 기본(정액)과 초과 사용(소비 시점) 수익 계정으로 분리하세요.
- 선불 크레딧 차감분을 이연 수익에서 빼내세요. 소멸 처리를 위해 에이징된 크레딧 잔액을 검토하세요.
- 다운스트림 API, 호스팅, 데이터 비용을 도구별로 기록하세요. 미터별 총마진을 다시 계산하세요.
- 마켓플레이스 총 명세서를 순 입금액과 대사하세요. 명세서를 해당 월 기록과 함께 보관하세요.
- 스테이블코인 수령을 공정 시장 가치로 기록하고 전환을 통한 원가 기준을 추적하세요.
- 고객 위치 합계를 주 넥서스 임계치와 비교 검토하세요. 필요한 곳에서 세금 징수를 확인하세요.
- 원시 사용량 내보내기를 월 마감 패키지와 함께 저장하세요. 그것이 미래의 당신(또는 감사관)이 요구할 원본 문서입니다.
재무 관리를 간소화하세요
종량제 수익, 이연 크레딧 잔액, 패스스루 API 비용, 50개 주 과세 여부는 주말에 시작한 MCP 서버 사이드 프로젝트치고는 움직이는 부품이 너무 많습니다. Beancount.io는 재무 데이터에 대한 완전한 투명성과 통제를 갖춘 플레인 텍스트 회계를 제공합니다. 모든 사용량 인보이스, 크레딧 차감, 마켓플레이스 수수료가 버전 관리되고 AI에 적합한 트랜잭션으로 기록되어 실제로 감사할 수 있습니다. 무료로 시작하세요 그리고 당신의 에이전트 경제 장부를 서버만큼 프로그래밍 가능하게 유지하세요.
