앱스토어 커넥트에 지난달 3,108이라고 표시됩니다. 합산해보니 6,580, 구글에서 $2,210이 들어왔습니다. 누군가 당신 돈을 훔친 게 아닙니다. 사라진 모든 달러에는 이름이 있습니다: 부가가치세, 수수료, 환불, 원천징수, 환전, 그리고 결국 소득세입니다. 문제는 그 격차 자체가 아니라, 대부분의 인디 개발자가 이를 설명할 수 있는 장부가 없어서 실제로 중요한 세 가지 질문에 답할 수 없다는 점입니다: 내 가격 책정이 올바른가? 수수료율을 제대로 적용받고 있는가? 현금흐름 예측이 현실적인가?
이 가이드는 정가에서 실수령액까지의 전체 과정을 설명하고, 지급액이 리포트와 일치하지 않는 이유를 짚어주며, 한 번 설정하면 매달 약 30분이면 끝나는 월간 대사 루틴을 제시합니다.
세 가지 숫자, 세 가지 다른 답
모든 앱 비즈니스에는 세 가지 매출 숫자가 있으며, 이들을 혼동하는 것이 혼란의 시작입니다:
- 총매출 — 고객이 지불한 금액으로, 분석 대시보드에 표시됩니다. 이는 허영 숫자입니다. 스토어가 징수하는 세금이 포함되어 있고, 보통 추정치이며 나중에 조정됩니다.
- 개발자 수익 — 스토어가 당신이 벌었다고 표시하는 금액으로, 월간 재무 보고서(애플) 및 수익 보고서(구글)를 기준으로 합니다. 이는 수수료, 스토어가 징수·납부하는 세금, 환불, 차지백을 차감한 순액입니다. 회계는 이 숫자를 기준으로 해야 합니다.
- 지급액 — 은행 입금액입니다. 수익에서 원천징수세를 차감하고, 환전을 반영하며, 최소 지급 기준액과 스토어의 지급 달력에 따라 결정됩니다.
장부에 은행 입금액만 기록하면 매출이 조용히 과소계상되고 한 달 이상 지연됩니다. 총매출을 기록하면 매출이 30–50% 과대계상되고 실제 받는 돈과 절대 일치하지 않습니다. 앱스토어 장부의 모든 기술은 이 세 숫자를 연결하여 매달 보고된 수익과 수령한 현금 사이의 차이가 0이 되도록 하는 것입니다.
정가에서 실수령액까지의 과정
VAT 20% 국가에서 판매된 €9.99 구독상품을 표준 30% 수수료율로 가정해보겠습니다. 실제로 일어나는 일의 정직한 버전입니다:
| 단계 | 계산 | 잔액 | 정가 대비 비율 |
|---|---|---|---|
| 정가 | — | €9.99 | 100% |
| 스토어가 징수·납부한 VAT | €9.99 ÷ 6 | €8.33 | 83% |
| 스토어 수수료(표준 요율) | 30% × €8.33 | €5.83 | 58% |
| 환불·차지백(3% 가정) | 3% × €5.83 | €5.65 | 57% |
| 실효 30% 소득세 | 30% × €5.65 | €3.96 | 40% |
정가의 약 60%는 결코 당신 주머니에 들어오지 않습니다. 디지털 상품에 과세하지 않는 미국 주에서의 판매는 더 높은 기준에서 시작하고, 할인된 수수료율을 적용받는 개발자는 훨씬 더 많은 금액을 가져갑니다(같은 VAT 지역 판매의 15% 수수료는 환불 전 €7.08 — 정가의 약 71%). 정확한 비율은 판매 구성에 따라 다르지만, 구조적 교훈은 모든 곳에서 동일합니다: 총매출은 당신의 돈이 아닙니다. 그것은 당신의 대시보드를 통과하는 스토어의 돈입니다.
이 중 어느 것도 숨겨져 있지 않습니다. 애플과 구글의 프로그램 약관에는 모든 공제 항목이 명시되어 있습니다. 대부분의 인디 비즈니스에서 빠진 것은 추적 시스템입니다 — 과정의 각 층이 월간 놀라움이 아니라 기록되고 감사 가능한 사실로 존재하는 곳 말입니다.
실제로 지불하고 있는 수수료율
이 분야에서 회계와 관련된 가장 비용이 많이 드는 실수 중 하나는 잘못된 수수료율을 적용받는 것입니다. 두 스토어 모두 소규모 개발자에게 수수료를 절반으로 줄여주지만, 모든 곳에서 자동으로 가입되지는 않습니다:
애플 앱스토어 소규모 사업자 프로그램은 유료 앱, 인앱 구매, 구독에 대해 수수료를 30%에서 15%로 인하합니다. 자격은 수익 기준으로 측정됩니다 — 총매출이 아닌 애플 수수료와 일부 세금·조정을 차감한 판매액입니다 — 그리고 이전 연도에 귀하의 계정 및 모든 연결 개발자 계정(소유, 통제, 또는 소유·통제받는 모든 계정)에서 1백만을 초과하지 않아야 합니다. 개발자들을 혼란스럽게 하는 두 가지 세부 사항:
- 연중 $1백만을 초과하면 표준 30% 요율이 향후 판매에 적용됩니다 — 이미 15%로 이루어진 판매는 추징되지 않으며, 수익이 기준 미만으로 떨어지면 다음 해에 다시 자격을 얻을 수 있습니다.
- 요율 변경은 가입 승인 후 회계 월 말로부터 15일 후에 적용되므로, 가입이 지연되면 할 일 목록에 있는 매주마다 실제 돈이 손실됩니다.
구글플레이 할인 등급은 매년 처음 $1백만 수익에 15%를 적용하고, 초과분부터 30%를 적용합니다 — 플레이 콘솔에서 연결 계정을 그룹화하고 약관에 동의하면 가입됩니다. 알아두면 좋은 구조적 차이 하나: 구글에서는 모든 자동 갱신 구독이 프로그램 가입과 관계없이 첫날부터 15% 서비스 수수료가 적용됩니다. 애플의 표준 요율에서는 구독자가 처음 12개월 동안 30%를 내고 2년차부터 15%를 냅니다 — 할인 프로그램을 졸업한 후에만 중요한 조용한 유지율 논리입니다.
$1백만 미만이면서 애플 프로그램에 가입하지 않았다면, 이를 해결하는 것이 올해 가장 ROI가 높은 10분일 수 있습니다: 가입 절차는 앱스토어 커넥트의 계약, 세금, 은행 메뉴에 있습니다.
입금액이 리포트와 일치하지 않는 이유
올바른 요율을 적용받고 있어도 수익과 지급액은 모두 기계적인 이유로 차이가 발생합니다 — 그리고 각각은 장부에 별도 항목으로 기록되어야 합니다:
지급 달력은 월 단위가 아닙니다. 애플은 각 회계 월 종료 후 45일 이내에 지급하며, 회계 월은 달력 월과 일치하지 않습니다 — 회계 월이 12월 27일에 끝나면 지급은 1월 29일에 이루어질 수 있습니다. 실제로 격차는 약 33일입니다. 구글은 다음 달 15일에 지급합니다(15일이 주말이면 다음 영업일로 연기). 발생주의 회계를 사용한다면 12월의 매출은 1월 또는 2월 중순의 현금이며, 장부에는 두 시점을 연결하는 지급 대기 계정이 필요합니다.
최소 지급 기준액으로 소액 지급이 지연됩니다. 애플은 은행 국가와 통화에 따라 달라지는 최소 지급 기준액을 초과할 때만 지급합니다. 판매가 저조한 달에는 입금이 전혀 없을 수 있고, 잔액이 다음 달로 이월됩니다 — 추적하지 않으면 $30이 사라진 것처럼 보입니다.
환불과 차지백은 수익에서 먼저 차감됩니다. 스토어는 전체 거래를 환수하며, 환불률은 제품과 지역에 따라 조용히 변동합니다. 올바르게 기록하면 이는 환불이 리포트에 반영된 달의 매출 차감 항목이지, 입금에서 발생한 미스터리 공제가 아닙니다.
세금은 두 개의 다른 문으로 흐릅니다. VAT와 많은 판매세의 경우 스토어가 세금 목적상 판매자(merchant of record) 역할을 합니다 — 예를 들어 EU에서 구글은 VAT를 부과하고 징수하며 납부하므로, 수익은 세금 제외 기준으로 계산되며 일반적으로 해당 국가에서 VAT 신고를 하지 않습니다. 별도로, 비미국 개발자는 미국 소득에 대해 원천징수를 받게 되며, 앱스토어 커넥트(또는 플레이 콘솔의 해당 메뉴)에서 W-8BEN 또는 W-8BEN-E를 제출하지 않았다면 30% 고정 요율이 적용될 수 있습니다. 조세조약 요율 — 또는 지급이 스토어의 해외 법인에서 이루어지는 사실 — 이 이를 0으로 줄일 수 있습니다. 어느 쪽이든 원천징수는 보고된 수익과 입금 사이의 차이로 나타나며, 보통 세액공제로 회수할 수 있습니다 — 기록한다면 말입니다.
환전은 실제 비용입니다. 스토어는 은행 계좌의 통화로 지급하며, 지역별 수익을 환전합니다. 외환(FX) 스프레드는 인보이스가 없는 비용이므로, 이를 확인하는 유일한 방법은 통화별 보고 수익과 입금액을 비교하는 것입니다.
대부분의 인디 개발자가 틀리는 회계 문제
매출 항목에 총매출을 표시해야 할까요, 순수익을 표시해야 할까요? 압도적 다수의 인디 개발자에게 정답은 순수익입니다. US GAAP(ASC 606)와 IFRS 15에 적용되는 수익 인식 기준에 따르면, 시험 기준은 당신이 판매의 본인(principal)인지, 즉 고객에게 이전되기 전에 재화나 용역을 통제하는지, 아니면 스토어가 판매할 때 성과 의무가 완수되는 **대리인(agent)**인지입니다. 스토어가 판매자로서 세금을 징수하고, 결제 시스템을 구성하며, 환불 절차를 부담하고, 거래당 순액을 지급한다면, 스토어가 본인이고 당신의 매출은 수익(proceeds)입니다. 총매출을 기록하고 수수료를 비용으로 표시하면 매출이 부풀려지고, 계산하는 모든 마진 비율이 왜곡되며, 누군가 확인했을 때 세금이 잘못 표시됩니다.
두 번째 오류는 시점입니다: 은행 입금액을 그 달의 매출로 기록하는 것입니다. 입금은 지난 달(또는 지난 회계 월)의 수익을 정산하는 것입니다. 올바른 패턴은:
- 매출 발생 시 수익을 발생시키고, 실제 수치가 아직 나오지 않았다면 스토어의 추정치를 사용합니다.
- 월간 재무 보고서가 나오면 실제 수치로 조정하고, 추정치와 실제치의 차이를 반영합니다(거의 항상 존재합니다 — 환전, 환불, 후기 조정 때문입니다).
- 입금이 도착하면 수취채권과 대사하고, 잔여 차이는 원천징수, 외환, 기준 미달 이월로 각각 별도 계정에 기록합니다.
마지막 조항이 핵심입니다: 모든 잔여 차이에 이름이 붙은 계정이 있다면, 0이 아닌 차이는 놓칠 수 없고 설명하는 데 몇 분밖에 걸리지 않습니다.
월 30분 월간 대사 워크플로우
- 실제 수치를 다운로드합니다. 앱스토어 커넥트에서 월간 재무 보고서(모든 지역을 포함하고 정산 날짜가 있는 상세 보고서)를 가져옵니다. 플레이 콘솔에서 수익 보고서를 가져옵니다. 이들 — 분석 대시보드가 아닌 — 이 원본 문서입니다.
- 지역 및 통화별로 수익을 기록합니다. 스토어별 매출 항목 하나에, 지역과 통화를 하위로 추적합니다. 여기에 감사 추적이 존재합니다: "왜 3월 EU 수익이 12% 하락했지?"라는 질문에 답해야 하는 날, VAT, 수수료, 환불이 통합된 숫자 하나가 아니라 분리되어 있어야 합니다.
- 추정치와 실제치의 조정을 반영합니다. 대시보드 예상과 보고서의 차이입니다: 보통 환불, 환전, 일괄 지급 조정입니다.
- 환불과 차지백을 보고 월의 매출 차감으로 기록하고, 시간에 따른 비율을 관찰합니다 — 환불률 상승은 회계 복장을 입은 제품 신호입니다.
- 입금을 수취채권과 대사합니다. 입금이 도착하면 보고서와 대조합니다. 원천징수는 세금 수취채권 계정으로(보통 공제 가능); 외환 차이는 환전 비용으로; 기준 미달로 인한 부족 입금은 다음 달까지 대기 계정에 남깁니다.
- 분기마다 수수료율을 확인합니다. 앱스토어 커넥트에서 소규모 사업자 프로그램 가입 상태와 플레이 콘솔에서 등급을 확인합니다 — 특히 수익이 $1백만에 근접할 때, 두 스토어 모두 향후 판매에 요율을 변경하기 때문입니다. 발생 전에 졸업을 모델링하세요: 기준선을 넘으면 연중 마진 구조 전체가 재평가될 수 있습니다.
여섯 단계, 한 달에 한 번의 세션. 이점은 깨끗한 장부뿐만 아니라, 가격 결정, 요율 가입, 현금 예측이 모두 허영 숫자 대신 수익을 기준으로 작동하게 된다는 점입니다.
전체 과정을 일반 텍스트로 추적하기
이것이야말로 다층 대사가 일반 텍스트 회계의 가치를 증명하는 분야입니다. beancount 장부는 과정의 각 층에 고유 계정을 부여합니다 — income:appstore:ios, income:playstore:android, expenses:refunds, assets:receivable:payouts:apple, assets:tax-withheld — 따라서 월간 입력 자체가 설명이 되고, 모든 수치가 수년 후에도 다시 유도할 수 있는 다운로드된 보고서에 연결됩니다. 장부가 텍스트이므로 스토어 보고서를 버전 관리에 나란히 넣을 수 있고, 대사는 스프레드시트 고고학 프로젝트가 아닌 diff가 됩니다. 은행 명세서와 스토어 데이터를 가져오는 도구가 필요하다면, 문서에서 가져오기 파이프라인을 자세히 다룹니다.
재무 관리를 단순화하세요
앱스토어 수익은 대부분의 개발자가 경험하게 될 가장 대사가 까다로운 소득입니다: 수수료, 세금, 환불, 지급 달력 모두가 돈이 도달하기 전에 각자의 몫을 가져갑니다. 이 과정을 반영하는 장부를 유지하는 것 — 단일 "앱 수입" 항목 대신 — 이 혼란스러운 지급액을 투명하고 감사 가능한 시스템으로 바꾸는 것입니다. Beancount.io는 투명하고 버전 관리되며 AI에 대비된 일반 텍스트 회계를 제공하여, 모든 스토어 보고서, 조정, 입금이 추적 가능하게 유지됩니다. 무료로 시작하기를 통해 실수령액을 코드만큼 명확하게 만드세요.