2026년 7월 1일, Envato는 CodeCanyon과 ThemeForest에서의 판매 경제학을 조용히 다시 썼다. 10년에 걸쳐 "독점" 지위를 쌓아 올리고 그 대가로 판매당 최대 87.5%에 달하는 넉넉한 수수료율을 받아온 저작자들이, 단계도 충성 보너스도 독점 요건도 없이 하나의 고정 50% 수익 배분으로 일괄 전환된 것이다. 이곳에서 판매하는 워드프레스 플러그인이나 테마 개발자라면 판매당 실수령액이 방금 절반으로 줄었을 수 있으며, 만약 장부가 플랫폼별·수수료 구조별·라이선스 유형별로 수익을 이미 추적하고 있지 않았다면 정산금이 예상보다 적게 들어올 때까지 이 사실을 눈치채지 못했을 가능성이 높다.
이 특정 변경 아래에 숨어 있는 진짜 문제는 이것이다. 대부분의 1인 및 소규모 팀 워드프레스 제품 비즈니스는 실제로 자신이 얼마를 버는지 모른다. 이들이 아는 것은 은행 계좌에 얼마가 들어왔는가뿐이다. 이 둘은 같은 숫자가 아니며, 그 사이의 간극 — 마켓플레이스 수수료, 결제 처리 수수료, 환전, 원천 징수된 부가가치세, 일회성 수익으로 잘못 처리된 갱신 수익 — 이야말로 부기 실수가 몇 년에 걸쳐 조용히 누적되는 지점이다.
다채널 정산의 문제
대부분의 워드프레스 제품 비즈니스는 하나의 채널로만 판매하지 않는다. 전형적인 구성은 다음과 같은 조합이다.
- 자체 호스팅 스토어 — Freemius나 Paddle 같은 기록상 판매자(merchant-of-record) 플랫폼을 사용하며, 라이선스 발급, 구독, 세금 징수를 처리
- Envato Market(플러그인용 CodeCanyon, 테마용 ThemeForest) — 입금이 이루어지기 전에 이미 몫을 떼어가는 마켓플레이스
- 직접 결제 — Easy Digital Downloads나 WooCommerce에 연결된 Stripe나 결제 게이트웨이를 통해, 본인이 직접 기록상 판매자가 되는 방식
이들 채널은 각각 다른 주기로, 다른 통화 조합으로, 서로 다른 수수료 조합을 공제한 뒤 정산한다. Freemius는 자사 수익 배분과 판매세 처리분을 제외한 금액을 매월 송금할 수 있다. Envato는 수수료를 제한 뒤 PayPal이나 계좌이체로 지급하는데, 정확한 비율은 이제 과거의 독점 등급이 아니라 2026년 7월의 고정 요율 변경에 따라 결정된다. 직접 Stripe 결제는 카드 총수익을 입금하고, 처리 수수료는 며칠 뒤 별도의 비용 항목으로 나타난다.
만약 여러분의 부기가 은행 계좌에 들어온 숫자를 그대로 "매출"로 기록하는 방식이라면, 총수익·마켓플레이스 수수료·처리 수수료·세금 송금이라는 네 가지 서로 다른 회계 이벤트를 하나의 숫자로 뭉뚱그리는 셈이며, 그 숫자는 어느 채널이 판매 단위당 실제로 수익성이 있는지에 대해 거의 아무것도 말해주지 않는다.
해법은 복잡하지 않지만 규율이 필요하다. 각 채널의 하위 원장에서 판매 시점에 총수익을 기록하고, 마켓플레이스 수수료·처리 수수료·원천 징수된 세금은 별도의 비용 또는 수익 차감 항목으로 기록해야 한다. 그래야만 "2026년 7월 요율 변경 이후에도 CodeCanyon 등록이 여전히 가치가 있는가?"와 같은 질문에 감이 아니라 실제 숫자로 답할 수 있다.
Envato의 변경이 계정과목에 중요한 이유
2026년 7월 이전, Envato의 독점 저작자 프로그램은 누적 수익을 기준으로 수수료를 단계화했다 — 플랫폼에서 오래, 많은 물량을 판매할수록 최상위 저작자의 요율은 최저 12.5%까지 떨어졌고, 이는 곧 판매당 최대 87.5%를 가져갈 수 있었다는 뜻이다. 다른 곳에서도 상품을 판매할 수 있는 비독점 판매자는 훨씬 불리한 조건을 받았다. 2026년 7월 1일부터 이 단계별 구조 전체가 사라졌다. 판매 이력이나 독점 여부와 무관하게 모든 저작자는 이제 고정 50% 수익 배분을 받는다.
부기 관점에서 이는 각주로 넘길 사안이 아니다. 만약 "Envato 매출" 계정이 85% 이상의 취득률을 암묵적으로 전제한 채 과거의 마진 계산에 녹아 있었다면, 그 전제는 이제부터의 모든 거래에서 틀리게 된다. 즉시 해야 할 일이 두 가지 있다.
- 채널별 수익 보고를 2026년 7월 1일을 기준으로 분리하라. 마켓플레이스가 여전히 가치가 있는지 평가할 때 변경 전후 달을 평균 내지 말라 — 단위 경제학이 그 날짜를 기점으로 실제로 바뀌었다.
- 채널 비교를 다시 실행하라. Envato의 고정 50% 수수료는 Freemius의 누진형 수익 배분 모델(보통 더 높게 시작해 물량이 늘수록 낮아진다)이나, 유일한 "수수료"가 약 2.9%의 처리 수수료와 고객 확보 비용뿐인 자체 관리형 Stripe 결제와는 매우 다른 숫자다. 예전 단계 요율 아래에서는 Envato 독점 유지가 합리적이었던 제품이 이제는 더 이상 수지가 맞지 않을 수 있다.
기록상 판매자 vs. 자체 관리형 결제: 세금은 누가 책임지는가
이 부분은 워드프레스 제품 부기에서 가장 많은 사람을 당황하게 만드는 지점이다. 두 모델이 장부상 완전히 다른 의무를 만들어내기 때문이다.
Freemius나 Paddle 같은 기록상 판매자(MoR) 플랫폼을 통해 판매하는 경우, 세금 목적상 법적 판매자는 그 플랫폼이다. 플랫폼이 EU·영국의 부가가치세, 해당 지역의 GST, 그리고 경제적 넥서스가 있는 미국 각 주의 판매세를 계산·징수·송금한다. 이런 판매에 대해서는 장부에 판매세 부채 계정이 필요하지 않다 — MoR이 이미 그 책임을 떠맡았기 때문이다. 여러분이 기록할 것은 실제로 수령한 순 정산금이며, 세무 당국이 특정 판매가 어떻게 과세되었는지 물을 경우를 대비해 MoR 자체의 거래 보고서를 감사 증적으로 보관해 두어야 한다.
직접 판매하는 경우 — 즉 자체 결제에 연결된 Stripe나 구형 Paddle 통합처럼 본인이 기록상 판매자인 경우 — 그 책임은 여러분의 것이다. 주별로 경제적 넥서스 기준(대부분의 미국 주는 연 매출 10만 달러 또는 거래 200건 부근에서 판매세 의무를 발생시키지만, 기준은 주마다 다르다)을 추적하고, 필요한 곳에 등록하고, 징수한 세금을 송금할 책임이 있다. 즉 장부에는 단순한 수익 항목이 아니라 실제 판매세 부채 계정이 필요하며, 각 신고 기간마다 징수한 금액과 송금한 금액을 대사하는 절차도 필요하다.
이 두 모델을 장부에서 구분하지 않고 섞어 쓰는 것은 흔하면서도 비용이 큰 실수다. 어떤 사업자는 MoR 플랫폼이 이미 처리한 세금 부채를 이중으로 계상하고, 또 어떤 사업자는 — 더 나쁘게도 — 실제로는 본인이 책임져야 할 채널에서 MoR이 세금 의무를 처리해 주고 있다고 착각한다.
라이선스 갱신은 일회성 판매가 아니다
플러그인과 테마 라이선스는 대개 연간(또는 평생) 키로 판매되며, 갱신 결제가 계좌에 들어오는 순간 전액을 수익으로 계상하고 싶은 유혹이 있다. 표준 수익 인식 원칙(미국의 ASC 606)에 따르면, 라이선스가 1년치 업데이트와 지원을 제공하는 것이라면 이는 옳지 않다. 갱신에서 나오는 수익은 갱신 기간이 시작되기 전에는 인식할 수 없으며, 고객이 실제로 서비스를 받을 자격이 있는 기간에 걸쳐 분산 인식해야 한다.
구체적으로 말하면 이렇다. 고객이 연 120달러짜리 라이선스를 갱신할 때, 결제된 날 120달러 전액을 수익으로 계상해서는 안 된다. 120달러를 이연수익(1년치 업데이트/지원을 제공할 의무가 있는 부채)으로 기록한 뒤, 실제로 그 의무를 이행하는 매달 10달러씩 수익으로 인식해야 한다. 만약 대부분 연간 라이선스를 판매하면서 입금된 현금만 수익으로 계상한다면, 월별 손익계산서는 오해를 불러일으킬 것이다 — 갱신이 몰리는 달에는 급등하고 나머지 기간에는 과소평가되는 식으로 — 그리고 대출 신청이나 인수 협상, 혹은 단순히 사업이 실제로 성장하고 있는지 솔직하게 파악해야 할 때, 그 들쭉날쭉함이 실제 추세를 가려버린다.
Freemius, Envato, 직접 결제를 동시에 운영할 때 이 문제는 더욱 커진다. 각 채널의 갱신 방식이 조금씩 다르기 때문이다(예를 들어 Envato의 라이선스는 전통적으로 구독형 갱신보다는 일회성 구매에 더 가깝게 설계된 반면, Freemius는 반복 라이선스를 중심으로 만들어져 있다). 이연수익 추적은 이런 채널별 차이를 반영해야 하며, 모든 판매에 하나의 일괄적인 가정을 적용해서는 안 된다.
정신줄을 놓지 않고 정산 대사하기
이 모든 것을 하나로 묶는 실무적인 주간 또는 월간 작업은 정산 대사다 — 각 플랫폼의 대시보드가 말하는 수익과 실제로 은행 계좌에 들어온 금액을 맞춰보고, 그 사이의 모든 항목을 이해하는 일이다. 실용적인 절차는 대략 다음과 같다.
- 요약 정산 총액에 의존하지 말고 각 채널(Freemius, Envato, Stripe)의 거래 단위 보고서를 받아라 — 총 판매액, 수수료/처리비, 원천 징수 세금을 하나의 순액이 아니라 별도의 항목으로 확보해야 한다.
- 총수익과 각 공제 항목을 원장에 채널별로 태그해 별도로 기록하라. 그래야 채널별 실제 마진 보고서를 뽑을 수 있다.
- 순 입금액을 해당 정산 기간의 총수익에서 수수료와 원천 징수 세금을 뺀 값과 대조하라. 불일치가 있다면 대개 아직 기록하지 않은 환불, 지불 거절, 또는 환율 차이 때문이다.
- 단일 채널 내에서도 갱신 수익과 신규 판매 수익을 별도로 추적하라. 그래야 실제 갱신율을 파악할 수 있는데, 이는 라이선스 소프트웨어 비즈니스에서 아마도 가장 좋은 건강 지표이며, 갱신과 신규 판매를 하나의 "Envato 매출" 계정에 뭉뚱그리면 완전히 가려지고 만다.
이를 스프레드시트로 수작업 처리하는 것은 월 거래 건수가 얼마 안 될 때는 가능하다. 하지만 서로 다른 통화, 수수료 체계, 세금 처리를 가진 세 채널을 매 정산 주기마다 서로 대조해야 하는 순간부터는 더 이상 확장되지 않는다.
다채널 장부를 감사 가능하게 유지하라
Freemius, Envato, 직접 Stripe 결제에서 들어오는 정산금을 동시에 관리하고 있다면, 평문 회계(plain-text accounting)는 자연스러운 해법이다. 각 채널의 거래는 순 입금액만 보여주는 블랙박스 대시보드 안에 묻히는 대신, 태그를 달고 스크립트를 돌리고 diff를 뜰 수 있는 버전 관리된 항목으로 존재한다. Beancount.io는 그 투명성을 제공한다 — 총수익, 마켓플레이스 수수료, 이연 갱신 수익을 어떻게 분류할지에 대한 완전한 통제권과, 모든 판매에 대한 완전한 감사 증적을 함께. 무료로 시작하기 — 이미 버전 관리로 사고하는 개발자들이 왜 장부도 평문으로 옮기고 있는지 직접 확인해 보라.