ARPG 출시 회고 설계: 개발비·예상 정산액·현금 수지 구분하기

가상의 ARPG 출시를 예로 판매액, 예상 정산액, 실제 현금 수지를 구분한다. 제작 범위별 비용 기록과 출시 후 지원 예산을 검토하는 방법을 제안한다.

✓ 복사 완료!
챕터퍼블리싱 계약 & 지원 사업
난이도중급
상태● 검토 완료
대상 엔진
Engine Agnostic
최종 업데이트
ARPG 출시 회고 설계: 개발비·예상 정산액·현금 수지 구분하기

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

출시 회고의 판매액을 스튜디오가 실제로 받은 돈과 구분해서 읽어야 한다. 예를 들어 Steamworks 정산 안내는 판매 보고서의 수익 표시와 공제 항목을 반영한 월별 정산 보고서를 구분한다. 플랫폼 수수료, 환불·차지백, 세금과 퍼블리셔 정산 조건을 함께 확인한다.

이 글의 숫자와 제작 일정은 특정 게임사의 공개 실적이나 실제 포스트모템을 재현한 자료가 아니라 계산과 회고 방법을 설명하기 위한 가정이다. 아래 정산 모델을 실제 보고서에 적용하려면 해당 계약의 공제 항목·순서와 지급 내역을 확인해야 한다.

ARPG 출시 비용과 정산 항목을 나눈 재무 대시보드 예시

이미지의 금액과 그래프는 설명용 값이다. 특히 그림의 Net Revenue, Unpaid Development Costs 표기를 아래 현금 수지의 정의로 사용하지 않는다. 아직 지급하지 않은 개발비는 지급 예정액이며 지급 전에는 현금 지출이 아니다.

예상 정산액과 기간 현금 수지를 나누기

다음 달 인건비를 지급할 수 있는지 검토하려면 누적 판매량과 함께 월별 입금·지출 일정과 기초 현금 잔액을 확인한다. 아래 첫 식은 공제 순서를 가정한 간이 정산 모델이다. 정가에 할인율을 이미 반영한 실제 총판매액을 사용하며 할인액을 다시 빼지 않는다.

예상정산액=총판매액−환불⋅차지백액−판매세−플랫폼수수료−퍼블리셔배분예상정산액 = 총판매액 - 환불·차지백액 - 판매세 - 플랫폼수수료 - 퍼블리셔배분 기간현금수지=기간실제현금유입−기간실제현금지출기간현금수지 = 기간실제현금유입 - 기간실제현금지출

예상 정산액은 입금 전의 추정치이며 회계상 매출이나 영업현금흐름으로 단정하지 않는다. IAS 7 개요는 현금흐름을 영업·투자·재무 활동으로 구분하고 비현금 거래와 발생·이연 항목을 별도로 다룬다. 이 글의 기간 현금 수지는 해당 분류를 생략한 자금 계획용 합계다. 운영비, 마케팅비, 이전 개발비는 해당 기간에 실제 지급한 금액만 현금 지출에 넣고 항목 간 중복 합산을 피한다.

정가 2만 5천 원에 1만 장을 모두 팔았다는 가정의 판매액은 2억 5천만 원이다. 할인과 지역별 가격이 다르면 실제 총판매액부터 달라지며 공제와 지급 시점도 확인해야 한다. 회고에는 다음 수치를 함께 기록한다.

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

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

계산 규칙을 스프레드시트나 코드로 남기고 계약 버전과 기준값을 기록한다. 코드로 만들었다는 이유만으로 계산 기준이 유지되는 것은 아니므로 변경 시 예시 입력·결과를 대조한다.

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

export function estimateSettlement(m: LaunchMetrics) {
  const amounts = [m.grossSales, m.refundsAndChargebacks, m.taxes];
  const rates = [m.platformFeeRate, m.publisherShareRate];
  if (amounts.some(v => !Number.isFinite(v) || v < 0)
      || rates.some(v => !Number.isFinite(v) || v < 0 || v > 1)
      || m.refundsAndChargebacks + m.taxes > m.grossSales) {
    throw new RangeError("Invalid values for this simplified settlement model");
  }
  const afterRefundsAndTax = m.grossSales - m.refundsAndChargebacks - m.taxes;
  const platformFee = afterRefundsAndTax * m.platformFeeRate;
  const publisherShare = (afterRefundsAndTax - platformFee) * m.publisherShareRate;
  const estimatedSettlement = afterRefundsAndTax - platformFee - publisherShare;

  return {
    platformFee,
    publisherShare,
    estimatedSettlement,
  };
}

이 예제는 동일 통화의 금액을 사용하고 환불·차지백과 판매세를 뺀 뒤 플랫폼 수수료, 그 다음 퍼블리셔 배분을 차감한다고 가정한다. 이 순서가 모든 계약에 적용되는 것은 아니다. 원천징수, 송금 수수료, 환전, 선급금 회수와 지급 시차는 구현하지 않았다. 이전 기간 판매분의 환불이 현재 판매액보다 큰 경우도 이 단순 모델 밖이다. 실제 정산에는 계약상 공제 기준과 통화별 반올림 규칙을 구현하고 확정 보고서와 대조해야 한다. 이 함수는 현금흐름을 계산하지 않는다.

ARPG에서 비용이 커지는 지점

이 제작 계획에서는 전투, 빌드 선택지, 전리품 규칙, 적 조합, 보상 곡선을 함께 검토 대상으로 삼는다. 새 콘텐츠가 어떤 시스템을 변경하는지 확인하고 전투·UI·밸런스·QA 작업을 견적에 반영한다. 모든 ARPG 이용자의 기대나 콘텐츠당 비용 증가를 측정한 결과는 아니다.

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

콘텐츠 수를 약속하기 전에 핵심 빌드가 목표 플레이 경험을 만드는지 테스트하는 순서를 제안한다. ‘무기 100종’ 같은 목표와 함께 조합별 선택 이유를 플레이테스트로 확인한다. 아이템 수를 줄이거나 수치만 다른 장비를 추가했을 때의 선택 체감과 제작·테스트 비용은 실제 결과로 비교한다.

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

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

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

전투 콘텐츠, UI, QA가 연결된 ARPG 제작 일정 보드 예시

이 일정 보드도 설명용 이미지이며 실제 스튜디오의 진행 상태나 버그 건수를 보여 주는 자료는 아니다.

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

출시 후 크래시, 저장 데이터 손실, 밸런스, 컨트롤러 호환성 문제가 보고될 때의 대응 순서를 미리 정한다. 다음은 진행 불가와 데이터 손실의 심각도를 우선하는 정책 예시다. 실제 우선순위는 영향 인원, 재현성, 회피 방법과 보안 문제 등을 함께 보고 조정한다.

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

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

다음 ARPG를 위한 회고 질문

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

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

회고에는 판매액, 예상·확정 정산액, 실제 현금 유입·지출을 구분하고 제작 범위별 비용을 기록한다. 다음 프로젝트에서 범위를 바꿀 때 이 기록을 견적과 플레이테스트 계획의 근거로 사용한다. 작은 범위만으로 전투 품질이나 안정적인 출시가 보장되는 것은 아니다.