출시 포스트모템: 개발비와 매출을 공개한 ARPG에서 배운 것

먼저 구분해야 할 것: 매출은 손에 남는 돈이 아니다

개발비와 매출을 함께 공개한 출시 회고는 보기 드문 자료다. 다만 숫자를 읽을 때 가장 흔한 실수는 상점 페이지에 표시되는 판매액을 스튜디오의 수입으로 받아들이는 일이다. 플랫폼 수수료, 환불, 세금, 할인, 퍼블리셔 정산 조건이 빠지면 손익 판단은 쉽게 달라진다.

이 글의 예시는 특정 게임사의 실적이 아니라 계산 방법을 설명하기 위한 가정이다. 실제 계약과 세무 처리는 국가, 플랫폼, 퍼블리싱 계약에 따라 달라지므로 회계·세무 전문가의 검토가 필요하다.

손익을 계산하는 가장 작은 단위

출시 후 의사결정에는 누적 판매량보다 월별 순현금 유입이 더 유용하다. 아래처럼 항목을 분리하면 ‘매출은 나왔는데 왜 다음 달 인건비가 부족한가’라는 질문에 답할 수 있다.

$$순매출 = 총판매액 - 환불액 - 판매세 - 플랫폼수수료 - 퍼블리셔배분$$ $$영업현금흐름 = 순매출 - 출시후운영비 - 마케팅비 - 미지급개발비$$

예를 들어 정가 2만 5천 원인 게임을 1만 장 판매했다고 해서 2억 5천만 원이 그대로 남지는 않는다. 할인 판매 비중과 지역별 가격, 환불률, 수수료가 섞이기 때문이다. 따라서 회고에는 다음 수치를 함께 적는 편이 낫다.

• 판매 수량과 총판매액
• 평균 실판매 단가
• 환불·차지백 비율
• 플랫폼 및 퍼블리셔 공제 후 순매출
• 개발비와 출시 후 운영비
• 손익분기점 도달 시점 또는 미도달 사유

계산을 재현할 수 있게 만들기

스프레드시트에서도 충분하지만 계산 규칙을 코드로 남기면 업데이트 때 기준이 흔들리지 않는다.

type LaunchMetrics = {
  grossSales: number;
  refunds: number;
  taxes: number;
  platformFeeRate: number;
  publisherShareRate: number;
  postLaunchCost: number;
};

export function calculateCashFlow(m: LaunchMetrics) {
  const afterRefundsAndTax = m.grossSales - m.refunds - m.taxes;
  const platformFee = afterRefundsAndTax * m.platformFeeRate;
  const publisherShare = (afterRefundsAndTax - platformFee) * m.publisherShareRate;
  const netRevenue = afterRefundsAndTax - platformFee - publisherShare;

  return {
    netRevenue,
    operatingCashFlow: netRevenue - m.postLaunchCost,
  };
}

이 함수에서 중요한 점은 수수료율 자체가 아니라 적용 기준이다. 계약서상 퍼블리셔 배분이 플랫폼 수수료 전 금액을 기준으로 하는지 후 금액을 기준으로 하는지에 따라 결과가 달라진다. 숫자 공개 시에는 비율만 적지 말고 계산 기준도 명시해야 한다.

ARPG에서 비용이 커지는 지점

ARPG는 전투만 재미있으면 끝나는 장르가 아니다. 플레이어는 반복 플레이를 견딜 빌드 선택지, 전리품의 읽기 쉬운 규칙, 적 조합, 보상 곡선을 함께 기대한다. 이 때문에 콘텐츠 하나를 추가할 때 전투·UI·밸런스·QA 비용이 함께 늘어난다.

flowchart TD
    A[새 스킬 또는 아이템] --> B[전투 구현]
    A --> C[툴팁·인벤토리 UI]
    A --> D[드롭·제작 규칙]
    B --> E[빌드 상호작용 테스트]
    C --> E
    D --> E
    E --> F[밸런스 조정과 회귀 QA]

이 구조가 주는 교훈은 콘텐츠 수를 처음부터 약속하지 않는 것이다. ‘무기 100종’ 같은 목표보다 핵심 빌드 몇 개가 처음부터 끝까지 재미있게 작동하는지를 먼저 검증해야 한다. 아이템 수를 줄여도 조합의 의미가 명확하면 플레이어는 선택지를 느낀다. 반대로 수치만 다른 장비를 늘리면 제작비와 테스트 범위만 커진다.

개발비는 역할별로 기록한다

총 개발비 하나만 남기면 다음 프로젝트의 견적에 쓰기 어렵다. 최소한 아래처럼 분류하면 범위 조정의 근거가 생긴다.

항목	기록할 내용	다음 프로젝트에서의 활용
인건비	역할별 투입 월수와 외주비	팀 규모와 개발 기간 추정
콘텐츠	맵, 몬스터, 보스, 아이템 제작량	콘텐츠 1개당 실제 비용 비교
기술	엔진, 서버, 빌드, 도구	재사용 가능한 기반과 일회성 비용 분리
QA·현지화	언어 수, 테스트 기간, 수정 건수	출시 직전 병목 예측
마케팅	영상, 체험판, 행사, 광고	채널별 전환 효율 검토

출시일은 끝이 아니라 지원 비용의 시작이다

출시 직후에는 크래시, 저장 데이터, 밸런스, 컨트롤러 호환성처럼 구매 결정에 직접 영향을 주는 문제가 몰린다. 이 시기에 새 콘텐츠를 서둘러 넣기보다 신뢰를 회복하는 패치 순서를 정해 두는 편이 낫다.

1. 진행 불가와 데이터 손실 문제를 최우선으로 해결한다.
2. 성능과 입력 반응처럼 전투 감각을 해치는 문제를 고친다.
3. 빌드를 무너뜨리는 명백한 밸런스 오류를 조정한다.
4. 그 뒤에 품질 개선과 신규 콘텐츠의 일정을 공개한다.

패치 공지에는 수정 내용뿐 아니라 알려진 문제와 재현 조건을 적는 것이 좋다. 커뮤니티의 제보는 QA를 대체하지 않지만 실제 플레이 환경에서 놓친 우선순위를 찾는 데 도움이 된다.

다음 ARPG를 위한 회고 질문

좋은 포스트모템은 성공을 자랑하거나 실패를 변명하는 문서가 아니라 다음 결정을 바꾸는 기록이다. 출시 후 아래 질문에 답할 수 있다면 숫자 공개의 가치가 생긴다.

• 가장 많은 비용이 든 기능은 출시 후에도 핵심 가치로 남았는가?
• 체험판, 스트리머, 할인 중 어떤 경로가 실제 구매와 연결됐는가?
• 플레이 시간이 긴 이용자는 어떤 빌드와 구간에서 이탈했는가?
• 출시 후 8주 운영비를 개발비와 별도로 확보했는가?
• 다음 작품에서 재사용할 도구와 버릴 시스템은 무엇인가?

개발비와 매출을 투명하게 다루는 일은 숫자를 멋있게 보이게 만드는 작업이 아니다. 판매액, 정산액, 현금흐름을 분리하고 제작 범위가 만든 비용을 기록하는 일이다. 이 기준이 남아 있어야 다음 ARPG에서 더 작은 범위로도 더 강한 전투와 더 안정적인 출시를 설계할 수 있다.