게임을 출시했다. Steam에는 누적 매출 42,000달러가 찍혀 있다. 그런데 은행 계좌에는 27,400달러만 들어와 있다. 나머지 14,600달러가 정확히 어디로 갔는지 모른다면, 당신만 그런 것이 아니다 — 그리고 사실 당신이 보고 있는 것은 회사의 재무제표가 아니라, 애초에 그런 용도로 설계되지 않은 스토어프론트 대시보드일 뿐이다.
Steam의 매출 배분은 흔히 "밸브가 30%를 가져간다"로 요약되고, 압도적 다수의 인디 개발자에게는 방향성 면에서 맞는 말이다. 하지만 그 30%라는 항목은 플레이어가 지불한 가격과 사업용 당좌예금 계좌에 실제로 들어오는 금액 사이에 존재하는 다섯 가지 공제 항목 중 하나일 뿐이다: 플랫폼 수수료, 환불, 환전, 부가가치세/판매세, 그리고 — 미국 납세자가 아니라면 — 연방 원천징수. 각 항목은 세무상 다르게 처리되기 때문에 장부에 각각 별도의 항목으로 기록해야 하며, 이를 뭉뚱그려 처리하면 분기별 추정세를 과다 납부하거나 4월에 회계사로부터 달갑지 않은 통보를 받는 결과로 이어진다.
돈이 실제로 어떻게 흘러가는지, 그리고 Steamworks 대시보드가 아니라 현실과 일치하는 장부를 만들려면 어떻게 기록해야 하는지 살펴보자.
Steam의 계단식 매출 배분, 그리고 대다수 개발자에게 별 의미가 없는 이유
밸브의 현재 구조는 타이틀별 누적 매출 기준으로 계단식이다:
- 총매출 1,000만 달러까지 플랫폼 수수료 30% (개발자 몫 70%)
- 1,000만~5,000만 달러 구간은 플랫폼 수수료 25% (개발자 몫 75%)
- 5,000만 달러 초과분은 플랫폼 수수료 20% (개발자 몫 80%)
이 구간 제도는 대형 퍼블리셔들이 대작 타이틀을 경쟁 스토어로 옮기겠다고 압박한 결과로 도입된 것이지, 인디 친화적 제스처로 만들어진 것이 아니다. 수치도 이를 뒷받침한다: 인디 게임의 중위 누적 매출은 5,000~15,000달러 사이이며, 판매량 상위 5%에 드는 타이틀조차 100만 달러를 넘기는 경우가 드물다. 다음 대박 히트작을 만드는 것이 아니라면, 고정 30% 수수료를 기준으로 장부를 설계하라 — 8자리 매출을 넘어서지 못하는 게임에게 이 구간 제도는 반올림 오차 수준에 불과하다.
다만 1,000만 달러에 근접하는 타이틀이 있다면, 이는 정산 명세서를 세 달 뒤에 대사하다가 뒤늦게 발견할 일이 아니라 부기 시스템이 실시간으로 감시해야 할 정확히 그런 종류의 임계값이다. 타이틀별로 매출을 추적하는 계정과목 체계(하나의 뭉뚱그린 "Steam 매출" 계정이 아니라)를 갖추면 구간 진입이 다가오는 것을 미리 볼 수 있다.
순매출: Steam이 실제로 지급 기준으로 삼는 금액
더 단순한 소매업이나 구독형 사업에서 넘어온 개발자들이 흔히 걸려 넘어지는 부분이 바로 이것이다: Steam의 수수료는 정가를 기준으로 계산되지 않는다. 총매출에서 해당 조정 항목을 뺀 순매출을 기준으로 계산된다.
총매출에는 결제 시 징수된 부가가치세와 판매세가 포함된다. 해당 조정 항목에는 다음이 포함된다:
- 환불 및 지불거절(chargeback) — 환불된 사본의 전체 구매가가 차감된다
- 부가가치세/판매세 — 대부분 국가에서 Steam 가격은 세금 포함가이며, 밸브가 해당 세금을 관련 당국에 직접 납부한다. 이 금액은 매출 배분 계산에 전혀 영향을 주지 않는다
- 환전 — 해외 판매는 밸브의 환율로 USD로 정산되며, 이 환율은 판매일과 정산일 사이 외환 시장 변동에 따라 움직인다
이 모든 것을 차감한 뒤에야 70/75/80%의 매출 배분율이 적용된다. 실무적으로 말하면: 환불된 판매 건에 대해서는 Steam 수수료를 내지 않지만(다행), 애초에 정가를 매출로 계상할 수도 없다(중요한 점인데, 마케팅 대시보드에 나오는 "총판매액" 수치는 회계상 총매출보다 항상 더 크게 나타난다는 뜻이다).
부기 방식: 정산 주기마다 두 개의 별도 수치를 기록하라 — 부가가치세를 제외한, 환불 전의 플랫폼 총매출을 매출 계정으로, 그리고 환불을 손익계산서에서 이를 상계하는 매출차감(contra-revenue) 계정으로 기록한다. 최종 입금액만을 "Steam 매출"로 기록하지 마라 — 그러면 인디 스튜디오가 가진 가장 유용한 건강 지표 중 하나인 환불률 추이를 볼 수 없게 된다.
환불은 반올림 오차가 아니다 — 금액이 아니라 비율을 추적하라
Steam의 환불 정책은 플레이어가 구매 후 2주 이내이고 플레이 시간이 2시간 미만이라면 전액 환불을 요청할 수 있게 한다. 콘솔이나 모바일 스토어보다 훨씬 관대한 정책이며, 그럴 만한 이유가 있다("구매 후 DRM 없는 사본을 복제하고 환불받는" 남용을 상당 부분 차단하고 구매자와의 신뢰를 쌓는다). 플랫폼 전체로 보면 환불률은 평균적으로 구매의 약 5% 수준이지만, 짧은 내러티브 게임이나 2시간 이내에 "핵심 진행을 완료"할 수 있는 타이틀은 훨씬 높은 비율을 보이는 경우가 많다 — 2시간 제한이 끝나기 전에 한 자리에서 끝낼 수 있는 타이틀은 환불률이 두 자릿수까지 치솟았다고 보고한 개발자들도 있다.
장부 관점에서 이는 다음을 의미한다:
- 환불을 예외가 아니라 Steam에서 사업을 운영하는 데 따르는 반복적 비용으로 취급하라. 소매업체가 도난·손실(shrinkage)을 예산에 반영하듯 환불도 예산에 반영하라.
- 환불 금액 총액만이 아니라 환불률을 KPI로 감시하라. 패치나 마케팅 캠페인 이후 서서히 올라가는 비율은 신호다 — 버그일 수도, 스토어 페이지가 오해를 유발할 수도, 아니면 (2026년 들어 점점 흔해진) 짧은 게임을 노린 환불 창구 남용일 수도 있다.
- 정식 수익 인식(ASC 606)을 적용한다면, 환불 창구가 실질적으로 경과하기 전까지는 판매에 대한 수익을 인식하지 마라 — 대부분의 인디 스튜디오는 2주라는 짧은 기간과 통계적으로 예측 가능한 비율을 감안하면 이 창구에 대해 수익 인식을 이연할 필요는 없지만, 특정 타이틀의 환불이 규모가 크고 변동성이 크다면 총매출의 100%를 먼저 인식하고 나중에 손실을 반영하는 방식보다 월별 환불 충당금/준비금 방식이 더 정확하다.
지역별 가격 책정과 스스로 선택하지 않은 환전
Steam은 35개 통화로 가격을 책정할 수 있게 지원하며, 밸브의 2026년 가격 정책 개편은 단순한 환율 기반 환산을 넘어 지역별 구매력과 지역 엔터테인먼트 가격 관행까지 반영하게 되었다 — 즉 미국 내 19.99달러 가격이 브라질이나 동남아시아 등에서는 실질 가치 기준으로 상당히 다른 가격으로 환산될 수 있고, 자신의 가격 설정을 전혀 건드리지 않아도 그 환산값은 시간이 지나며 변할 수 있다.
부기 측면에서 두 가지 결과가 따른다:
- 모든 해외 판매는 고정된 숫자가 아니라 USD 환전 결과다. 적용되는 환율은 플레이어가 게임을 구매한 날의 환율이 아니라 보고 시점의 밸브 환율이다. 세무나 사업 계획 목적으로 지역별 매출을 추적한다면, 입금 총액을 역산하려 하지 말고 Steamworks 판매 보고서에서 지역별 세부 내역을 가져와라.
- 단위당 순매출에 미치는 파급 효과를 확인하지 않고 지역 가격을 수동으로 조정하지 마라. 부가가치세가 높은 국가에서 가격을 인하하면, 정가 변동폭이 시사하는 것보다 실제 수취액이 더 크게 줄어들 수 있다. 부가가치세는 매출 배분이 적용되기 전에 차감되기 때문이다.
정산 시점: 은행 입금액이 이번 달 매출과 일치하지 않는 이유
밸브는 판매월 마감 후 약 30일 뒤에 정산한다 — 예를 들어 2월 매출은 3월 말에 지급된다 — 그리고 Steam은 계좌 잔액이 최소 100달러 기준을 넘을 때까지 지급을 보류하는데, 이는 아직 초기 액세스 단계인 소규모 타이틀이나 여러 소규모 게임을 운영하는 스튜디오에서 개별 타이틀의 월 매출이 단독으로는 그 기준을 넘지 못하는 경우 중요하게 작용한다.
이 시차는 신규 Steam 개발자들이 "내 장부가 은행 계좌와 맞지 않는다"고 혼란스러워하는 가장 흔한 원인이다. 해법은 표준적인 발생주의 회계다: 현금이 은행에 들어오는 달이 아니라 (Steamworks 판매 보고서 기준으로) 실제로 판매가 일어난 달에 매출을 기록하라. 매달 순매출을 발생시키고 30일쯤 뒤 전신송금이나 ACH 입금이 들어올 때 청산되는 "Steam 미수금(Receivable)" 계정을 설정하라. 이렇게 하지 않으면 월별 손익계산서는 실제 매출 추세와는 무관하게, 그저 어느 달에 정산금이 우연히 입금되었는지만 반영하는 롤러코스터처럼 보일 것이다.
세금 원천징수: 미국 외 개발자가 건너뛰고 후회하는 단계
미국 납세자라면 밸브가 1099 양식을 발급하고, 다른 사업 소득과 동일하게 처리하면 된다. 미국 납세자가 아니라면, 다음 부분이 바로 사람들을 발목 잡는 지점이다:
Steam 매출은 미국 원천 로열티 소득(구체적으로는 게임과 DLC에 적용되는 저작권 로열티 세율)으로 분류된다. Steamworks 온보딩 과정에서 모든 파트너는 세무 인터뷰를 완료하고 Form W-9(미국 개발자) 또는 Form W-8BEN(미국 외 개발자) 중 하나를 생성한다. 거주 국가와 그 국가가 미국과 조세 조약을 맺고 있는지에 따라, 밸브는 매출 배분금이 은행 계좌에 도달하기 전에 0%에서 30% 사이를 원천징수하고, 이를 매년 3월 15일까지 Form 1042-S로 보고한다.
30%가 원천징수되고 있는데 거주 국가가 미국과 조세 조약을 맺고 있어 낮은 세율을 적용받을 자격이 있다면, 세무 인터뷰를 제대로 완료하지 않았을 가능성이 높다 — 흔히 조약 혜택에 필요한 외국 또는 미국 납세자 식별번호를 제공하지 않은 경우다. 이는 다시 돌아가 재작성할 수 있는 양식이지, 영구적인 세율이 아니다. 1인 개발자에게 조약 혜택을 청구하지 않은 경우(30% 원천징수)와 청구한 경우(국가에 따라 흔히 0~15%)의 차이는 연간 수천 달러에 달할 수 있다 — 인터뷰 내용을 30분 들여 다시 확인할 가치가 있다.
어느 쪽이든, 그 원천징수는 Steam의 플랫폼 수수료와는 별개의 항목이다. "Steam 몫"과 "세금 원천징수"를 장부에서 하나의 숫자로 뭉뚱그리지 마라 — 세무 처리가 완전히 다르기 때문이다. 원천징수된 금액은 자신의 세금 채무를 선납한 것이다(거주국의 세무 처리에 따라 외국납부세액공제로 청구하거나 환급받을 수 있다). 반면 플랫폼 수수료는 그야말로 밸브의 수수료일 뿐이며 어떤 것에도 공제받을 수 없다.
Steam 기반 스튜디오를 위한 간단한 계정과목표
소규모 스튜디오라면 다섯 개의 계정으로 위 내용 대부분을 포착할 수 있다:
- Steam 총매출 — 환불과 수수료를 반영하기 전, 부가가치세 제외 가격 기준의 판매액
- Steam 환불 (매출차감 계정) — 환불/지불거절된 판매의 금액
- Steam 플랫폼 수수료 — 30/25/20% 수수료, 아래 항목과 별도로 추적
- Steam 세금 원천징수 — 미국 외 개발자에게만 해당; 비용이 아니라 선급 세금 자산으로 처리
- Steam 미수금 — 당월과 전월의 발생했지만 아직 지급되지 않은 매출로, 정산금이 입금될 때 청산됨
여러 타이틀을 운영한다면, 계정과목 세트를 통째로 늘리기보다 게임별로 클래스나 태그를 추가하라 — 계정과목 체계를 다섯 배로 중복시키지 않고도 타이틀별 성과를 비교할 수 있어야 한다.
게임 스튜디오의 장부도 코드베이스만큼 깔끔하게 유지하라
Steamworks 판매 보고서를 편하게 읽을 수 있다면, 이미 플레인 텍스트에 익숙하다는 뜻이다 — 그리고 이는 정확히 Beancount.io가 지향하는 방향이다. 계단식 플랫폼 수수료, 환불 준비금, 해외 원천징수처럼 불규칙한 것들을 모델링하기 위해 GUI 기반 회계 도구와 씨름하는 대신, 버전 관리되는 원장으로 한 번만 작성하면 이후의 모든 계산을 공짜로 얻을 수 있다. 개발자들이 마켓플레이스 매출 원장을 어떻게 구조화하는지는 문서를 확인하고, 플레인 텍스트를 벗어나지 않으면서 타이틀별 매출·환불·수수료를 대시보드 형태로 보고 싶다면 Fava를 살펴보라.