오늘 크롬 웹 스토어 개발자 대시보드를 열어보면 뭔가 빠져 있다는 걸 알아챌 것이다. 바로 "결제" 탭이다. 구글은 2021년에 확장 프로그램용 자체 인앱 결제 시스템을 종료했고, 그 이후로 다시 돌아오지 않았다. 2026년에 크롬 확장 프로그램으로 요금을 받고 싶다면, 결제, 구독, 환불, 세금 징수를 스스로 해결해야 하며 — 거의 아무도 미리 계획하지 않는 부분인 — 실제로 은행 계좌에 입금된 금액을 판매 내역과 대조하는 일도 직접 해야 한다.
가격 책정보다 이 마지막 부분에서 발이 걸리는 1인 개발자가 더 많다. 스트라이프, 패들, 혹은 ExtensionPay 같은 래퍼를 통해 서너 개의 확장 프로그램을 운영하는 1인 개발사는 어느 제품과도 깔끔하게 매칭되지 않는 정산 입금, 크롬 웹 스토어 심사 지연 이후 느닷없이 발생하는 환불 급증, 그리고 판매 대시보드가 알려주는 수치와 결코 정확히 맞아떨어지지 않는 은행 잔액을 마주하게 된다. 이는 여러분의 사업에 문제가 있다는 뜻이 아니다. 구글이 예전에 대신 운영해주던 결제 스택을 스스로 이어 붙인 결과로 나타나는 당연한 현상일 뿐이다.
이를 견뎌내는 부기 체계를 구축하는 방법을 소개한다.
구글이 결제 사업에서 손을 뗀 이유
크롬 웹 스토어 결제는 2010년대 초, 1인 개발자가 브라우저 확장 프로그램으로 요금을 받을 만한 괜찮은 선택지가 많지 않던 시절에 출시되었다. 2021년이 되자 스트라이프, 브레인트리, 그리고 여러 "기록상 판매자(merchant of record)" 서비스들이 충분히 성숙해졌고, 구글은 더 이상 자체 결제, 라이선스 키, 정산 시스템을 운영할 필요가 없다고 판단했다. 구글은 크롬 웹 스토어 결제를 폐지하고, 유료 확장 프로그램마다 무료로 전환하거나 서드파티 처리업체로 갈아타도록 밀어붙였다.
개발자에게 미치는 실질적인 결과는 이렇다. 이제 확장 프로그램이 벌어들이는 모든 1달러는 자신이 직접 조립한 결제 스택을 거쳐 흐르며, 그 스택이 만들어내는 모든 대사(reconciliation) 문제는 온전히 자신의 몫이다. 더 이상 단일한 "크롬 웹 스토어 정산 보고서" 같은 건 없다. 있는 것이라곤 결제 처리업체가 주는 자료, 크롬 웹 스토어 자체 등록 정보 분석, 그리고 은행 명세서뿐이며, 이 셋은 처음 봤을 때 좀처럼 서로 맞아떨어지지 않는다.
결제 처리업체냐 기록상 판매자냐 — 확장 프로그램마다 하나를 선택하라
대사를 시작하기도 전에, 거래에서 법적으로 어느 편에 서 있는지 알아야 한다. 그것이 장부에 무엇이 기록되는지를 좌우하기 때문이다.
결제 처리업체(스트라이프를 직접 쓰거나, ExtensionPay 같은 그 위에 만들어진 래퍼)를 이용하면 여러분이 판매자가 된다. 여러분이 대금을 수취하고, 세무상 기록상 판매자(merchant of record)가 되며, 고객이 거주하는 모든 관할 지역의 판매세와 부가가치세(VAT) 의무를 직접 파악해야 한다. 수수료는 더 낮다 — 스트라이프의 기본 요율은 건당 2.9% + $0.30이며, ExtensionPay 같은 래퍼는 보통 그 위에 자체 수수료를 얹는다 — 하지만 규제 준수 부담은 온전히 여러분 몫이다.
기록상 판매자(Merchant of Record, MoR)(패들, 레몬 스퀴지, Fungies 등)는 여러분 대신 법적 판매자가 된다. 이들은 부가가치세나 소비세(GST)를 징수하고, 이제 디지털 상품에 대해 이를 요구하는 140여 개국에서 신고를 대행하며, 지급 거절(chargeback)을 처리하고, 순수익을 여러분에게 지급한다. 매출의 약 3% 대신 4~8%를 내주게 되지만, 부기 및 세무 신고 업무의 한 카테고리 전체가 사라진다. 이 트레이드오프에 대한 전체 분석과 전환이 언제 손익분기점을 넘는지 계산하는 방법은 저희의 기록상 판매자 가이드를 참고하라.
월 매출이 수천 달러 미만인 대부분의 1인 확장 프로그램 개발자에게는, MoR이 부과하는 추가 3~5%가 십여 개국에서 손수 VAT 등록을 해야 하는 상황에 대한 저렴한 보험이나 다름없다. 여러 확장 프로그램에 걸쳐 실질적인 반복 매출을 올리게 되면, 비교 계산을 다시 해보라 — 거래량이 커질수록 그 셈법도 달라진다.
어느 쪽을 선택하든 반드시 기록해 두라. 장부에는 "이 확장 프로그램의 법적 기록상 판매자가 누구인가"에 대한 명확한 답이 있어야 한다. 그것이 판매세 부채가 대차대조표에 아예 나타나는지 여부를 결정하기 때문이다.
대사 문제는 실수가 아니라 구조적인 문제다
개발자를 당황하게 만드는 부분은 이렇다. 처리업체가 올바르게 설정되어 있어도, 받는 정산금은 그 기간에 발생시킨 매출과 거의 절대 정확히 일치하지 않는다. 세 가지 요인이 1:1 매칭을 깨뜨린다.
- 일괄 정산. 스트라이프와 대부분의 MoR은 순환 일정(종종 결제 후 2~7일, 때로는 매주)에 따라 정산금을 지급하므로, 이번 달 5일에 들어온 정산금에는 지난달 마지막 며칠간의 판매분이 포함되어 있다. 정산금이 은행에 도착한 날짜를 기준으로 매출을 기록한다면, 매달 소득을 잘못된 회계 기간에 귀속시키게 된다.
- 여러 확장 프로그램, 하나의 처리업체 계정. 하나의 대표 상품보다는 여러 개의 소규모 도구를 출시하는 개발자에게 흔한 경우인데, 동일한 스트라이프나 패들 계정으로 여러 확장 프로그램을 운영한다면 정산금은 전체를 합친 단일 금액으로 온다. 확장 프로그램별 태깅(스트라이프의 메타데이터 필드, 또는 확장 프로그램별로 분리된 Product/Price)이 없으면 어느 확장 프로그램이 실제로 매출을 견인했는지 알 수 없고, 그러면 어느 것이 유지보수 시간을 들일 가치가 있는지도 알 수 없다.
- 수수료, 환불, 통화 환전이 이미 순계로 반영된 숫자. 정산 금액에는 이미 처리 수수료, 그 기간에 발생한 환불, 그리고 해외 판매 시 통화 환전분이 차감되어 있다. 정산금을 총매출로 기록하면 매출 총액이 과대 계상되고 실제 마진이 가려진다.
해결책은 최소 매월 한 번씩 수행하는 **3자 대사(three-way match)**다.
- 처리업체 판매 보고서 — 계정이 지원한다면 제품/확장 프로그램별로 항목화된, 수수료와 환불이 차감되기 전 총거래.
- 처리업체 정산 보고서 — 실제로 은행에 입금된 순액으로, 수수료와 환불이 별도 항목으로 분리되어 있다.
- 은행 명세서 — 실제로 정산 완료되어 입금된 금액.
세 가지를 모두 대조하라. 판매 보고서는 여러분이 무엇을 벌었는지(고객이 서비스 기간에 대해 결제한 시점에 인식되는 매출) 알려준다. 정산 보고서는 비용과 매출 차감 항목으로 기록해야 할 수수료 손실분과 환불 활동을 알려준다. 은행 명세서는 실제로 현금이 도착했는지 확인해 준다. 세 가지 중 어느 두 가지라도 맞아떨어지지 않는다면, 그것이 바로 뭔가 조사가 필요하다는 신호다 — 정산 실패, 지급 거절 분쟁, 혹은 예상하지 못한 처리업체 수수료일 수 있다.
크롬 고유의 위험: 심사 지연과 강제 삭제
모든 결제 스택에는 일반적인 환불 활동이 존재한다. 크롬 확장 프로그램에는 별도의 항목으로 추적할 가치가 있는 추가적인 실패 모드가 있다. 바로 크롬 웹 스토어 심사 지연과 정책 위반으로 인한 강제 삭제다.
구글의 심사팀이 게시된 확장 프로그램에 정책 위반 딱지를 붙이면, 즉각적인 강제 삭제(중대하거나 심각한 위반의 경우)를 당하거나 경미한 위반을 수정할 약 7일에서 30일의 경고 기간을 받는다. 어느 쪽이든, 사용자는 실제로 돈을 내고 있던 확장 프로그램에 대한 접근 권한을 잃게 되고, 이는 환불 요청, 지급 거절, 지원 티켓의 예측 가능한 급증을 일으킨다 — 개발자들은 바로 이런 패턴 때문에 한 달 구독 매출의 두 자릿수 비율을 잃었다고 보고했으며, 이는 직접적인 환불에 더해진 것이다.
두 가지 부기 습관을 들이면 이 문제가 놀라운 일이 아니라 관리 가능한 일이 된다.
- 환불과 지급 거절을 원인별로 태깅하라. 고객이 확장 프로그램을 마음에 들어 하지 않아 발생한 환불은 사업을 운영하는 데 따르는 정상적인 비용이다. 확장 프로그램이 일주일간 강제 삭제되어 발생한 환불은 별개의, 추적 가능한 사업 리스크다. 이 둘을 구분하면(메모 필드나 하위 계정만 있어도) 1년에 걸쳐 매출 변동성이 플랫폼 리스크에서 오는 것인지, 제품-시장 적합성 문제에서 오는 것인지 파악할 수 있다.
- 심사 대기 중이거나 정책 경고가 진행 중인 상태는 공시가 필요한 사건으로 취급하라. 핵심 고객 이탈 위험을 표시하는 것과 같은 방식이다. 가격을 인상하거나, 인력을 채용하거나, 대출을 받을지 결정하기 위해 숫자를 계산하고 있다면, 현재 30일 규정 준수 경고를 받고 있는 확장 프로그램은 "안정적인 반복 매출"이 아니다 — 심사를 통과할 때까지는 위험 자산으로 모델링하라.
정산금이 도착할 때가 아니라, 벌어들일 때 매출을 인식하라
구독형과 일회성 구매형 확장 프로그램은 다르게 처리해야 하며, 이를 혼동하는 것이 이 분야에서 가장 흔한 회계 실수다.
- 월간 또는 연간 구독: 요금이 청구된 순간 전액이 아니라, 고객이 결제한 기간 전체에 걸쳐 균등하게 매출을 인식하라. 선불로 결제된 연간 요금제는 **이연 수익 부채(deferred revenue liability)**를 만든다 — 이미 돈은 받았지만 열두 달 중 아직 열한 달의 서비스를 제공하지 않았으므로, 판매 월에는 1/12만 매출로 인식되고 나머지는 매달 대차대조표에서 점차 소멸된다.
- 평생 이용권(구독형에 대한 경계심 때문에 확장 프로그램에서 특히 인기 있는 가격 모델)은 여전히 업데이트와 지원을 무기한 제공해야 할 의무를 나타내므로, 첫날에 현금 전액을 매출로 인식하면 그달의 실제 벌어들인 소득이 과대 계상된다. 더 타당한 접근법은 평생 이용권 매출을 합리적으로 추정한 서비스 제공 기간(많은 기업이 12~36개월을 대용치로 사용한다)에 걸쳐 인식하는 것이지, 한 번에 전부 인식하는 것이 아니다.
- 추가 의무가 없는 일회성 구매: 제공된 시점에 전액 인식한다 — 이는 단순한 사례다.
MRR(월간 반복 매출)은 유용한 성장 지표이지만, 장부상 인식된 매출과 같은 숫자가 아니다. MRR은 활성 구독의 런레이트를 알려줄 뿐이며, 원장은 이연 처리 이후 이번 기간에 실제로 벌어들인 것을 반영해야 한다.
여러 확장 프로그램을 견뎌내는 원장 구조
평문 텍스트 복식부기 시스템으로 장부를 관리하고 있다면, "정산금 하나, 확장 프로그램 여러 개" 문제에 대한 해결책은 처음부터 제품별로 수익을 분리하는 계정 과목표에, 정산 보고서가 이미 차감해 놓은 항목들에 대한 명시적인 계정을 더하는 것이다.
2026-07-05 * "Stripe payout - batch #4471"
Assets:Bank:Checking 842.17 USD
Income:Extensions:FocusTimer -510.00 USD
Income:Extensions:TabArchiver -390.00 USD
Expenses:PaymentProcessing:StripeFees 41.83 USD
Expenses:Refunds:FocusTimer 16.00 USD모든 정산이 하나의 거래가 되어, 은행 입금을 확장 프로그램별 수익, 수수료, 환불이라는 별도의 분개로 대사한다 — 어느 제품이 실제로 수익성이 있는지 아무것도 알려주지 않는 불투명한 "스트라이프 입금" 한 줄 대신 말이다. 파일이 평문 텍스트이기 때문에, 확장 프로그램별, 월별, 또는 환불 원인별로 grep이나 쿼리를 실행할 수 있으며, 이는 일괄 정산 보고서가 결코 제공하지 않는 가시성이다.
월간 체크리스트
- 그달의 처리업체 판매 보고서를 가져온다(가능하다면 제품별로 항목화된 총액).
- 정산 보고서를 가져와서 수수료, 환불, 지급 거절을 별도 항목으로 분리한다.
- 정산 입금을 은행 명세서와 대조 확인한다.
- 구독 및 평생 이용권 매출을 수취 시점이 아니라 인식 일정에 따라 기록한다.
- 크롬 웹 스토어 심사 지연이나 강제 삭제와 관련된 환불은 일반적인 이탈과 별도로 태깅한다.
- (MoR이 아닌) 순수 결제 처리업체를 통해 해외 판매를 하고 있다면, 특정 국가에서 누적 매출이 VAT/GST 등록 기준을 넘었는지 확인한다.
코드만큼이나 확장 프로그램 사업의 장부도 깔끔하게 유지하라
버전 관리 없이 확장 프로그램을 배포하지는 않을 것이다. 여러분의 재무 상태도 같은 수준의 엄격함을 받을 자격이 있다 — 특히 정산금이 여러 제품과 처리업체로 분산될 때는 더욱 그렇다. Beancount.io는 확장 프로그램별로 수익을 태깅하고, 이연 수익을 추적하며, 코드에 쏟는 것과 같은 정밀함으로 정산금을 은행 명세서와 대사할 수 있는 평문 텍스트 버전 관리 회계를 제공한다. 무료로 시작하기를 통해 개발자들이 자신이 만드는 다른 모든 것과 동일한 방식으로 장부를 관리하는 이유를 확인해 보라.