본문으로 건너뛰기

AI 에이전트를 GPT 스토어나 스킬 마켓플레이스에 등록하셨나요? 사용량 기반 매출에 대한 플랫폼 수수료를 어떻게 장부에 기록할까요

게시됨 약 10분Mike ThriftMike Thrift
AI 에이전트를 GPT 스토어나 스킬 마켓플레이스에 등록하셨나요? 사용량 기반 매출에 대한 플랫폼 수수료를 어떻게 장부에 기록할까요
이 페이지에서

마켓플레이스 대시보드는 지난달에 $1,000를 벌었다고 표시합니다. 은행 계좌에는 $850이 입금되었습니다. 그리고 플랫폼이 보내는 세금 신고 양식은 — 보낸다면 말이지만 — 실제로 챙긴 입금액이 아니라 더 큰 숫자를 보여줄 것입니다. 장부에 입금된 $850만 기록한다면, 플랫폼이 제출한 정보 신고서가 보고한 매출이 신고한 금액보다 15~30퍼센트 높다고 나오는 세무 시점에 원장에 불일치가 드러나게 됩니다.

이것이 마켓플레이스를 통해 AI 에이전트와 스킬을 판매할 때의 핵심적인 장부 문제입니다: 플랫폼은 당신이 돈을 보기도 전에 수수료를 가져가고, 받는 지급액은 이미 순액이며, 모든 후속 기록 — 매출, 세금 신고, 마진 계산 — 에는 당신이 직접 만진 적 없는 총액이 필요합니다. 다음은 AI 마켓플레이스가 실제로 지급하는 방식, 총액과 순액이 계속 맞도록 각 지급액을 기록하는 방법, 그리고 예상해야 할 세금 양식입니다.

2026년 말 AI 마켓플레이스가 실제로 지급하는 방식​

무엇이든 기록하기 전에, 어떤 지급 모델에 속하는지 명확히 하십시오. AI 마켓플레이스가 모두 앱 스토어처럼 작동하지는 않기 때문입니다.

GPT 스토어는 판매 가격의 비율이 아니라 참여도에 따라 지급합니다. OpenAI의 빌더 프로그램은 제3자 추정치에 따르면 평균 대화당 약 $0.03를 기준으로 — 판매 가격의 15퍼센트나 30퍼센트를 가져가는 대신 — 사용자의 GPT 참여도에 따라 창작자에게 보상합니다. 이 프로그램은 제한적이고 기준 기반의 단계적 출시로 유지되어 왔으며, 대부분의 개인 창작자는 사용량이 엄청나지 않는 한 한 달에 낮은 수백 달러 수준에 머뭅니다. 여기에는 기록할 수수료가 전혀 없습니다: 지급액은 단일 매출 항목이며, 당신의 임무는 대화 수 곱하기 실효 요율을 실제 도착한 금액과 대조하는 것입니다.

시간 제한도 있습니다. 개인 ChatGPT 계정은 더 이상 새로운 GPT를 생성하거나 게시할 수 없으며, OpenAI는 기존 커스텀 GPT를 2026년 12월 11일에 은퇴시키도록 예정했고, 승인된 유예를 받은 엔터프라이즈 워크스페이스는 2027년 2월 11일까지입니다. 대체 수단은 Apps SDK를 통해 구축된 플러그인이며, 사용량 기반 개발자 지급은 논의되었지만 광범위하게 배포되지는 않았습니다. GPT 스토어 지급액이 장부의 한 항목이라면, 그 항목이 끝나고 다른 보고 방식을 가진 무언가로 대체될 것을 대비하십시오.

Claude Skills에는 공식 마켓플레이스나 수익 배분이 없습니다. Anthropic은 Agent Skills 표준과 자사의 무료 스킬을 공개하지만, 올해 기준으로 내장 결제가 있는 자체 스토어는 없습니다. 빌더는 간접적으로 수익화합니다: 사용자를 유료 구독 등급으로 유도하는 브랜드 스킬, 빌더 자체의 사용량 기반 API 엔드포인트로 라우팅하는 스킬, 또는 직접 계약으로 엔터프라이즈 고객을 위해 구축한 스킬입니다. 이 각각은 마켓플레이스 매출이 아니라 장부상의 일반적인 제품 또는 서비스 매출입니다.

제3자 스킬 마켓플레이스는 실제로 비율 수수료를 가져가며 — 서로 다릅니다. 여기서 슬라이딩 스케일 문제가 실제로 영향을 미칩니다. Claude 스타일 스킬을 위한 독립 마켓플레이스는 자체 배분을 공개합니다: 하나는 8퍼센트를 가져가고 창작자가 92퍼센트를 유지하며, 다른 하나는 유료 스킬 가격의 70퍼센트를 창작자에게 지급하고 Stripe Connect를 통해 지급합니다. 같은 스킬을 두 마켓플레이스에 등록하면 서로 다른 두 개의 지급 일정에 대해 서로 다른 두 개의 수수료율을 기록하게 됩니다. 아래 메커니즘은 어떤 비율에도 적용됩니다; 계산 예시는 플랫폼 커머스 전반에서 가장 흔한 소규모 판매자 등급이기 때문에 15퍼센트를 사용합니다.

15~30퍼센트라는 형태는 앱 스토어에서 비롯됩니다. Apple의 표준 수수료는 각 판매의 30퍼센트이며, App Store Small Business Program의 개발자 — 연간 수익이 $100만 미만인 경우 — 에게는 15퍼센트로 인하됩니다. AI 마켓플레이스는 이 계층적 형태를 차용합니다: 표준 요율과 소규모 판매자 할인 등급, 때로는 최근 12개월 거래량이 임계값을 넘으면 요율이 인상되기도 합니다. 수수료율이 자신의 판매량에 따라 달라질 때는 모든 지급액에 금액 확인뿐 아니라 요율 확인이 필요합니다 — 바로 아래의 조정 루프가 그것입니다.

총액이냐 순액이냐: 장부를 좌우하는 단 하나의 결정​

마켓플레이스가 당신의 스킬을 $49에 팔고 $7.35를 가져간 뒤 $41.65를 보낼 때, 기록하는 방법은 두 가지입니다. 그중 하나만 옳습니다.

총매출을 매출로 기록하고 수수료를 비용으로 기록합니다. ASC 606의 본인 대 대리인(principal-versus-agent) 프레임워크에서 문제는 제품이 고객에게 도달하기 전에 누가 통제하는가입니다. 당신의 스킬이 당신의 제품입니다: 당신이 만들었고, 가격을 정했고, 구매자를 지원합니다. 마켓플레이스는 단지 판매를 주선하고 결제를 처리할 뿐이며, 이는 마켓플레이스가 대리인이고 당신이 본인임을 의미합니다. 본인은 총매출을 보고합니다. 플랫폼이 가져가는 몫은 판매 비용 — 다른 사람의 상점을 통해 유통하는 비용 — 입니다.

이것은 학문적 구분이 아닙니다. 관심 있는 세 가지 숫자를 바꿉니다:

세금 양식은 총액을 보고합니다. 마켓플레이스와 결제 처리업체의 정보 신고서는 수수료 차감 전 귀하에게 흘러가는 전체 판매 금액을 보여줍니다. 장부에 순액 입금만 매출로 표시하면, 제출하는 신고서가 IRS가 이미 받은 양식과 불일치하게 되고, 이 불일치는 자동 통지의 가장 흔한 촉발 요인 중 하나입니다. 총매출과 별도의 수수료 비용을 기록하면 장부가 구성상 서류와 일치하게 됩니다.

마진이 정직하게 유지됩니다. $7.35의 플랫폼 수수료로 $49에 팔리는 스킬은 총액으로든 순액으로든 $41.65를 벌어들입니다 — 매출총이익은 어느 쪽이든 동일합니다. 그러나 순액만 기록하면 수수료가 더 작은 매출 숫자 안에 숨어, 플랫폼이 요율을 올리거나 더 높은 등급으로 넘어갈 때 손해가 명확히 표시된 상승하는 비용이 아니라 신비롭게 줄어드는 매출로 나타납니다. 분리된 항목을 두면 수수료 항목이 움직이는 것을 볼 수 있습니다.

플랫폼별 비교가 가능하게 유지됩니다. 서로 다른 수수료율의 두 마켓플레이스에서 판매하는 경우, 플랫폼별 수수료 계정과 함께 총액 기록은 각 채널의 비용이 정확히 얼마인지 알려줍니다. 순액만 기록하면 채널 경제성이 분해할 수 없는 하나의 숫자로 뒤섞입니다.

수수료 항목이 속한 곳​

플랫폼 수수료는 매출원가(COGS)가 아니라 결제 처리 수수료와 함께 판매 또는 유통 비용으로 기록하십시오. 또한 매출에서 상계하지 마십시오. COGS는 제품 자체를 전달하는 비용 — API 추론 청구서, 호스팅, 사용량 기반 업스트림 서비스 — 을 위한 것입니다. 마켓플레이스 수수료는 그 채널을 통해 판매를 획득하는 비용입니다. 이를 매출총이익선 아래에 두면 매출총이익률은 제품 경제성(가격에서 전달 비용을 뺀 값)을 반영하고, 영업이익률은 채널 선택을 반영합니다. 마켓플레이스가 수취 요율을 올릴 때, 그것이 대응할 수 있는 — 재가격 책정, 재협상, 또는 이탈을 통해 — 판매비용 증가로 나타나길 원하며, 제품 운영 비용이 더 비싸진 것처럼 보이는 매출총이익률 하락으로 나타나길 원하지 않습니다.

월간 조정 루프​

모든 지급액은, 모든 마켓플레이스에서, 동일한 네 단계 루프를 거칩니다. 장부를 마감하기 전에 매월, 플랫폼별로 수행하십시오.

1. 입금액만이 아니라 지급 보고서를 가져오십시오​

은행 입금액은 하나의 숫자입니다. 그 뒤의 지급 보고서에는 최소 다섯 가지가 있습니다: 총매출, 플랫폼 수수료, 환불 및 지불 거절(chargeback), 원천징수나 보류된 준비금, 그리고 순 지급액. 플랫폼이 제공하는 가장 세분화된 단위로 — 가능하면 거래별로 — 보고서를 다운로드하십시오. 3단계에서 필요하기 때문입니다. 플랫폼이 판매당 달러가 아닌 다른 것으로 보고한다면(참여도 지급의 대화 수, 사용량 기반 스킬의 사용량 기반 API 단위), 사용량 보고서도 가져오십시오: 단위 곱하기 계약 요율이 조정 대상 총액입니다.

2. 금액보다 먼저 수수료율을 확인하십시오​

계층적 플랫폼에서는 요율이 변동 요소입니다. 각 판매가 어느 등급에 속했는지 확인하십시오: 기간 중 더 높은 구간으로 넘어간 후에 발생한 판매가 있었습니까? 프로모션 요율이 만료되었습니까? 이번 달 등급이 적용되어야 할 판매에 지난달의 15퍼센트를 적용한 지급액(또는 그 반대)은 판매별 데이터에서 직접 수수료를 재계산해야만 잡아낼 수 있는 플랫폼 오류입니다. 각 판매에 판매일 현재 유효한 등급 요율을 곱하고, 예상 수수료를 합산하여 보고서의 수수료 총액과 비교하십시오. 기록 후가 아니라 기록 전에 차이를 조사하십시오.

3. 총액, 수수료, 조정을 별도 항목으로 기록하십시오​

지급액당 하나의 분개로 총매출, 플랫폼 수수료, 그리고 환불이나 지불 거절을 구분된 전기로 기록하십시오. 환불은 매출을 차감합니다 — 비용이 아닙니다 — 그리고 플랫폼이 환불된 판매에 대한 수수료를 환수한다면, 그 환수는 수수료 비용을 감소시킵니다. 일반 텍스트 원장에서는 패턴이 이렇게 보입니다(이 형식이 처음이라면 원장 문법은 문서를 참조하십시오):

2026-01-01 open Assets:Bank:Checking USD
2026-01-01 open Income:Marketplace:Skill-Sales USD
2026-01-01 open Expenses:Marketplace:Platform-Fees USD
 
2026-11-01 * "Skills marketplace" "October payout, 15% tier"
  Assets:Bank:Checking  850.00 USD
  Expenses:Marketplace:Platform-Fees  150.00 USD
  Income:Marketplace:Skill-Sales  -1,000.00 USD
 
2026-11-15 * "Skills marketplace" "Refund, order 1042, fee clawed back"
  Income:Marketplace:Skill-Sales  49.00 USD
  Expenses:Marketplace:Platform-Fees  -7.35 USD
  Assets:Bank:Checking  -41.65 USD

지급 분개는 전체 $1,000의 판매를 매출로, $150의 수수료를 자체 비용으로, $850의 입금을 은행 이동으로 보여줍니다 — 대시보드, 수수료 일정, 은행 명세서를 함께 묶는 세 개의 전기입니다. 환불 분개는 세 다리를 모두 되돌립니다. 두 개 이상의 마켓플레이스에서 판매하는 경우 각각에 자체 수익 및 수수료 하위 계정을 부여하면 이전 섹션의 채널 비교가 원장에서 자연스럽게 도출됩니다.

4. 순액은 은행에, 총액은 사용량에 연결하십시오​

두 개의 독립적인 연결이 루프를 닫습니다. 첫째, 지급액의 순액은 센트 단위까지 은행 입금과 일치해야 합니다 — 그렇지 않다면 차액은 자체 설명이 필요한 미결 항목(보류된 준비금, 지연된 이체, 환전)이며 반올림 조정이 아닙니다. 둘째, 총액은 기초 활동에 다시 연결되어야 합니다: 단위 판매의 경우 판매별 보고서 합계; 참여도나 사용량 기반 지급의 경우 자체 사용량 기반 단위 수 곱하기 계약 요율입니다. 두 번째 연결을 건너뛰는 빌더들이 6개월 후에 요율 변경이 한 달 일찍 적용되었다는 것을 발견하는 사람들입니다. 자체 사용량 로그가 플랫폼 계량기에 대한 유일한 검증입니다 — 보관하십시오.

세금 양식: 무엇이 오고 무엇이 오지 않는가​

마켓플레이스 소득은 일반 사업 소득이며, 다른 자영업 매출과 함께 Schedule C에 보고됩니다. 플랫폼별로 다른 것은 어떤 정보 신고서 — 있다면 — 가 이를 문서화하는가입니다.

제3자 마켓플레이스 지급액은 Form 1099-K로 도착할 수 있습니다. 2026년의 경우, One Big Beautiful Bill Act는 고전적 임계값을 복원했습니다: 결제 처리업체와 마켓플레이스는 수취인이 역년 동안 총 지급액 $20,000와 200건의 거래를 초과할 때만 1099-K를 발행합니다. 그 이하에서는 양식이 오지 않지만 — 소득은 여전히 완전히 과세 대상이며, 이전 섹션의 총액 기록 습관이 복사할 양식이 없을 때 신고서를 올바르게 만드는 것입니다. 임계값은 총 지급액과 거래 건수를 계산하므로, 고빈도·저가격 스킬 카탈로그는 거래 건수에 걸릴 수 있지만 몇 건의 대형 엔터프라이즈 스킬 계약은 결코 근처에도 가지 않습니다.

직접 참여도 지급액은 계약자 소득에 더 가깝게 보입니다. 제3자 구매자의 결제금을 정산하는 대신 자체 주머니에서 참여도 기반 수익 배분을 지급하는 플랫폼은 지급자-계약자 관계에 더 가까우며, 임계값이 충족되면 1099-NEC 또는 1099-MISC 계열로 문서화됩니다. 이 계열의 보고 임계값은 2026년에 $2,000로 인상되었습니다. 어느 쪽이든, 도착하는 양식이 무엇이든 그 플랫폼에 대한 원장의 총매출과 조정하십시오; 양식과 장부는 신고서 제출 전에 일치해야 합니다.

주 임계값은 연방보다 낮을 수 있습니다. 여러 주는 연방의 $20,000 및 200건 거래보다 훨씬 낮은 자체 1099-K 제출 임계값을 부과하며, 이는 연방 양식이 오지 않는 해에도 주 사본 1099-K를 받고 — 주가 일치하는 소득을 기대하게 됨 — 을 의미합니다. 받으면 같은 방식으로 조정하십시오: 양식의 총액 대 원장의 총액.

양식이 없다는 것이 소득이 없다는 것과 같지 않습니다. 이것이 소규모 판매자에게 실제 돈을 손실하게 하는 실수입니다. 한 달에 몇백 달러의 참여도 지급, 보고 임계값을 결코 넘지 않는 마켓플레이스에서 판매된 스킬, 스킬이 사용자를 자체 사용량 기반 API로 유도하는 간접 소득 — 누군가 양식을 보내든 안 보내든 모두 과세 대상입니다. 세무 시즌을 순조롭게 넘기는 판매자는 원장에 이미 모든 달러가 총액으로 기록되어 있어, 신고서가 플랫폼 이메일 상자가 아니라 장부에서 저절로 작성되는 사람들입니다.

조용히 누적되는 네 가지 실수​

입금액을 매출로 기록하기. 위에서 다룬 순액만 기록하는 습관입니다. 매출을 과소계상하고, 수수료 추세를 숨기며, 1099-K와의 불일치를 보장합니다. 해당 연도의 지급액을 총액으로 다시 기록하여 한 번 고치면, 월간 루프가 그것을 계속 고쳐진 상태로 유지합니다.

플랫폼 수수료를 COGS로 기록하기. 수수료를 매출원가에 묶으면 매출총이익률이 판매비용에 속하는 채널 비용을 흡수합니다. 제품이 실제보다 덜 수익성 있어 보이고, 수수료 인상이 채널 문제가 아니라 제품 문제로 읽힙니다. 전달 비용(추론, 호스팅, 업스트림 API)은 COGS에, 유통 비용(마켓플레이스 수수료, 결제 처리)은 판매비용에 두십시오.

등급 전환을 잊기. 슬라이딩 스케일 플랫폼에서 최근 거래량이 더 높은 구간으로 밀어 올린 달에는 실효 요율이 혼합됩니다 — 월초 판매는 이전 요율, 월말 판매는 새 요율입니다. 전체 지급액을 하나의 요율로 기록하는 판매자는 수수료를 덜 유용하게 호의적인 방향으로든 그렇지 않은 방향으로든 잘못 표시하며, 경계 근처에 머무는 매달 오류가 반복됩니다. 2단계의 판매별 요율 확인이 바로 이 경우를 위해 존재합니다.

모든 플랫폼을 하나의 계정으로 처리하기. 모든 마켓플레이스에 하나의 수익 계정과 하나의 수수료 계정을 쓰는 것이 더 단순하게 느껴지지만, 어느 채널이 제 몫을 하는지 답해야 할 때, 또는 한 플랫폼의 1099-K를 혼합 잔액과 조정해야 할 때까지 그럴 뿐입니다. 플랫폼별 하위 계정은 기록 시점에 비용이 들지 않고 세무 시점에 몇 시간을 절약합니다.

이번 달 지급액 체크리스트​

판매하는 각 마켓플레이스의 가장 최근 지급 보고서를 가져와 처음부터 끝까지 처리하십시오: 각 판매일 현재 유효한 수수료 등급을 확인하고, 판매별 데이터에서 수수료 총액을 재계산하고, 총매출을 수수료 및 환불과 별도 항목으로 기록하고, 순액을 은행 입금과 연결하고, 총액을 자체 사용량 또는 판매 로그와 연결하십시오. 그런 다음 최근 12개월 거래량이 등급 경계에 접근하고 있는지 확인하십시오 — 그렇다면 플랫폼이 알려주기 전에 실효 요율이 곧 움직일 것임을 이제 알게 됩니다. 이것이 전체 원칙입니다: 모든 달러가 총액으로 기록되고, 모든 수수료가 자체 항목에 보이며, 모든 플랫폼이 자체 기준으로 조정됩니다.

출처: https://beancount.io/ko/blog/2026/11/09/ai-agent-marketplace-platform-commission-revenue-share-bookkeeping-guide

게시됨: 2026년 11월 9일

약 9분

AWS Marketplace 판매자 장부 관리: 총매출, 등록 수수료, 세금, 환불, 지연 지급을 오퍼별로 조정하기

AWS Marketplace 판매자가 예금을 매출로 오인하지 않도록 하는 방법 — 거래 수준에서 총 청구액을 기록하고, 등록 수수료를 별도로…

bookkeeping
reconciliation
약 9분

Metronome, Orb, 아니면 그냥 Stripe Billing? 왜 연중에 사용량 기반 과금 플랫폼을 전환하면 종량제 매출 조정에 골칫거리가 생기는가

연중에 과금 플랫폼을 전환하면 종량제 사용량, 인보이스, 매출 간의 대사가 깨집니다 — 한 기간을 재생하고, 병행 운영하고, 나머지는 정산…

saas
revenue-recognition
약 6분

인디 앱 개발자를 위한 ASC 606: 앱스토어 수익을 총액으로 기록해야 할까요, 순액으로 기록해야 할까요?

대부분의 인디 개발자는 ASC 606의 주체 대 대리인 테스트에서 주체(본인)에 해당하므로, $9.99 앱스토어 판매는 $6.99의 순…

revenue-recognition
apple
약 9분

MCP 서버 접근 권한 판매: 사용량 기반 및 구독 수익 회계 처리

에이전트가 MCP를 소비하는 시점에 사용량 수익을 인식하고, 선불 크레딧을 이연 수익으로 계상하며, 도구별 API 패스스루 비용을 추적하세요.

ai
saas
약 6분

토큰 청구: AI 사용량 기반 SaaS를 위한 수익 인식 가이드

ASC 606은 여전히 AI 토큰 기반 가격 책정을 규정하지만, 변동 대가 추정, 청구권 실용적 편의, 선불 크레딧 팩의 잔액 소멸은 사용량…

revenue-recognition
saas