App Store Connect이나 Google Play Console을 열면 마치 내 수익처럼 보이는 숫자가 보일 것입니다. 지난달에 7,000가 입금되었습니다. 두 숫자 모두 틀린 것은 아닙니다. 하지만 그중 하나만이 손익계산서의 "수익" 항목에 속하며, 이 결정을 잘못 내리면 조용히 총 마진을 왜곡하고, 성장률을 잘못 표시하며, 대출 기관이나 투자자에게 실제와 다른 비즈니스 모습을 보여줄 수 있습니다.
이것이 바로 주체 대 대리인 문제이며, 미국 회계기준(US GAAP)의 ASC 606 수익 인식 기준에 따르면 이는 선택적인 서류 작업이 아닌 필수 규칙입니다. 이 규칙은 3,000의 매출 원가를 보고할지, 아니면 그냥 $7,000의 수익만 보고하고 끝낼지를 결정합니다. Apple 앱스토어나 Google Play 스토어를 통해 판매하는 인디 개발자에게 정답은 대개 사람들을 놀라게 합니다.
모든 앱 개발자가 결국 묻게 되는 질문
발단은 거의 항상 동일합니다. 창업자가 투자 피치덱을 준비하거나, 소기업 대출을 신청하거나, "이번 분기에 실제로 얼마를 벌었는지"를 알아내려고 하다가 자신이 은행 계좌에 입금된 금액을 "매출"로 기록해왔다는 사실을 깨닫게 됩니다. 그 숫자는 Apple이나 Google의 수수료가 차감된 순액, 즉 플랫폼 수수료가 이미 제외된 금액입니다.
문제는 수익에서 플랫폼 수수료를 차감하여 순액으로 기록하는 것이 단순한 스타일 선택이 아니라는 점입니다. ASC 606은 정확히 이 상황에 대한 특정 테스트를 가지고 있으며, 이는 한 가지 질문에 달려 있습니다. 고객에게 양도되기 전에 판매되는 상품에 대한 통제권을 누가 가지고 있는가?
알기 쉬운 ASC 606 통제 테스트
ASC 606의 5단계 수익 모델은 계약상의 수행 의무를 식별하고 누가 이를 이행하고 있는지 결정하도록 요구합니다. 시장이나 플랫폼(Apple, Google, Etsy, DoorDash, Uber)이 개발자와 최종 고객 사이에 있을 때, 회계 기준에서는 이를 주체 대 대리인 평가라고 부르며, PwC의 수익 가이드는 앱스토어 판매가 이러한 주의 깊은 검토가 필요한 전형적인 예라고 언급합니다.
- 주체(본인): 상품이나 서비스가 고객에게 양도되기 전에 통제권을 가집니다. 고객이 지불한 전체 총액을 수익으로 인식하고, 플랫폼 수수료는 수익 차감 항목이 아닌 매출 원가(비용) 가 됩니다.
- 대리인: 플랫폼이 상품 제공을 통제하고 개발자는 단순히 타인을 대신하여 판매를 주선할 뿐입니다. 자신이 보유하는 순액만을 수수료로 인식합니다.
Deloitte 및 PwC 프레임워크에 따르면 세 가지 지표가 어느 쪽에 해당하는지 결정합니다:
- 이행 책임 — 앱이 작동하지 않거나, 구독이 제공되지 않거나, 고객이 불만을 제기할 때 책임을 지는 사람은 누구인가? 보통은 Apple이 아닌 개발자 본인입니다.
- 양도 전 위험 — "재고"(앱, 콘텐츠, 구독 등급)가 판매되지 않거나 고객을 만족시키지 못할 위험을 누가 부담하는가? 역시 일반적으로 개발자 본인입니다.
- 가격 결정 재량권 — 고객이 실제로 지불할 금액을 누가 결정하는가? 개발자가 앱의 가격 등급을 선택하며, 플랫폼이 개별 거래마다 가격을 협상하지 않습니다.
대부분의 인디 개발자는 제품 경험을 통제하고, 고객 지원 및 업데이트에 대한 고객 관계를 소유하며, 자체 가격을 설정하기 때문에 테스트 결과 주체 측에 해당합니다. 즉, 올바른 회계 처리는 고객이 지불한 총액을 수익으로 기록하고, Apple이나 Google의 수수료를 보이지 않는 공제액이 아닌 매출 원가 항목으로 처리하는 것입니다.
공제액 뒤에 숨은 숫자
자신이 주체라는 것을 아는 것은 실제로 무엇이 공제되는지 알아야만 의미가 있습니다. 플랫폼 수수료 구조는 지난 몇 년 동안 크게 변화했으며, 대부분의 개발자는 여전히 구식 가정에 기반하여 예산을 책정하고 있습니다:
| 플랫폼 | 표준 요율 | 할인 요율 | 자격 요건 |
|---|---|---|---|
| Apple App Store | 30% | 15% (App Store 소규모 사업 프로그램) | 연간 앱스토어 수익이 $100만 이하인 개발자 |
| Apple 구독 | 30% (1년차) | 15% (2년차부터) | 최초 12개월이 지난 모든 구독 |
| Google Play | 30% | 연간 첫 $100만 수익에 대해 15% | 모든 개발자, 자동 등급 적용 |
| Google Play 구독 | 15% 고정 | — | 모든 구독 수익 |
| Apple EU (디지털 시장법 조건) | ~17% + 핵심 기술 수수료 | 최대 ~20%까지 합산 | EU의 대체 비즈니스 조건을 선택한 개발자 |
또한, 대부분의 사람들이 어디에도 할당하는 것을 잊는 연간 고정 비용이 있습니다: Apple의 연간 25 등록 수수료입니다. 소액이지만 차트 오브 어카운트(계정과목) 어딘가에 포함되어야 하며, 일반적으로 매출 원가가 아닌 일반 운영 비용에 속합니다.
올바르게 기록하기: 실제 예시
고객이 Apple을 통해 9.99를 징수하고 6.99를 개발자 은행 계좌에 입금합니다. $6.99를 "수익"으로 기록하면 상위 매출(총 수익)이 30% 과소 계상됩니다. 이는 직접 판매하는 경쟁사와 성장률을 비교하거나, 대출 기관에 마진을 설명해야 할 때 매우 중요합니다.
올바른 분개는 전체 판매를 인식한 후 수수료를 별도로 비용으로 계상합니다:
2026-07-18 * "Apple" "iOS 구독 — 총액 판매"
자산:미수금:AppStore 9.99 USD
수익:앱판매 -9.99 USD
2026-07-18 * "Apple" "30% App Store 수수료"
비용:매출원가:플랫폼수수료 3.00 USD
자산:미수금:AppStore -3.00 USD
2026-07-20 * "Apple" "지급금 수령"
자산:당좌예금 6.99 USD
자산:미수금:AppStore -6.99 USD지급금이 정산되면 미수금 계정 잔액은 0이 되지만, 손익계산서에는 여전히 3.00의 매출 원가가 표시되어 해당 판매의 총 마진이 70%임을 보여줍니다(신비롭게 사라진 30%가 아닌). 이것이 바로 일반 텍스트, 버전 관리 원장이 잘 처리하는 거래 유형입니다. 총액 판매, 플랫폼 수수료, 지급금이 하나의 모호한 은행 입금이 아닌 세 가지 별개의 감사 가능한 이벤트로 기록됩니다.
대시보드 숫자만으로 충분하지 않은 이유
규칙을 알더라도 수동으로 적용하는 것은 생각보다 어렵습니다. 일반적인 App Store Connect 및 Play Console 보고서는 합계만 보여주며, ASC 606이 요구하는 구독자 수준, 거래 수준의 세부 정보(수익, 환불, 통화 변환)는 실제 판매가 발생한 지 며칠 또는 몇 주 후에 단일 총액으로 도착하는 경우가 많습니다. 이러한 격차가 바로 점점 더 많은 구독 기반 앱 비즈니스가 월별 요약 PDF에서 역으로 추정하려고 시도하는 대신 플랫폼 API 또는 RevenueCat과 같은 도구를 사용하여 거래별 세부 정보를 재구성하는 이유입니다.
이 단계를 건너뛰면 실제 비용이 발생합니다. 널리 인용되는 한 예로, 한 개발자가 해당 월의 대시보드에 1,294에 불과했습니다. 이는 그들이 생각했던 "수익"과 비즈니스가 실제로 보유한 금액 사이에 60% 이상의 차이가 있음을 의미합니다. 대시보드 숫자(조정된 수치 대신)를 기반으로 채용이나 지출 결정을 내리는 개발자는 현실에 존재하지 않았던 숫자에 대해 예산을 책정하는 것입니다.
장부를 왜곡하는 흔한 실수들
- 순 입금액만 수익으로 기록하는 것. 이것은 가장 흔한 오류이며 이 글이 다루는 내용입니다. 수익과 매출 원가를 모두 과소 계상하여 총 마진 그림을 무의미하게 평탄화합니다.
- 환불 및 차지백을 무시하는 것. Apple과 Google은 모두 고객 환불을 대신 처리하며, 때로는 원래 판매 후 몇 주 후에 처리되기도 합니다. 거래별로 조정하지 않으면 환불된 수익이 장부에 무기한 남아 있을 수 있습니다.
- 25 Google 등록 수수료를 매출 원가에 포함시키는 것. 이는 고정 운영 비용이며 거래 수준의 수수료가 아닙니다. 별도의 비용 항목에 속합니다.
- EU의 별도 수수료 체계를 잊는 것. 사용자 기반의 일부가 EU에 있고 Apple의 대체 조건을 선택한 경우, 해당 수익은 나머지 비즈니스와 다른 수수료 구조를 가지므로 별도의 계정이 필요합니다.
비즈니스가 성장함에 따라 재정을 체계적으로 유지하세요
스토어에 하나의 앱만 있는 솔로 개발자이든, 소수의 구독 제품을 운영하는 소규모 스튜디오이든, 총액 대 순액 결정은 매달 잘못될 때마다 그 영향이 누적됩니다. 투자 유치나 자금 조달을 신청할 때쯤이면 과소 계상된 수익 라인은 설명하기 어려운 문제가 됩니다. Beancount.io는 개발자에게 이러한 다단계 거래(총액 판매, 플랫폼 수수료, 지급금)를 하나의 모호한 은행 입금 대신 세 개의 별개이고 감사 가능한 항목으로 처리하도록 설계된 일반 텍스트, 버전 관리 원장을 제공합니다. 지금 무료로 시작하여 이미 코드로 생각하는 개발자들이 동일한 방식으로 작동하는 회계를 선호하는 이유를 확인해보세요.