첫 게임 출시 포스트모템: 번 돈과 잃은 것, 배운 것

첫 게임의 출시 결과를 정리할 때 가장 위험한 표현은 “생각보다 팔렸다”와 “완전히 망했다”다. 둘 다 감정은 설명하지만 다음 게임의 판단 근거가 되지는 못한다.

포스트모템의 목적은 성공과 실패에 점수를 매기는 일이 아니다. 출시 전에 세운 가설이 무엇이었고 실제로 어떤 비용과 반응이 나왔으며 다음 프로젝트에서 무엇을 유지하거나 버릴지를 결정하는 일이다. 특히 첫 게임은 수익뿐 아니라 개발 습관, 협업 방식, 플레이어와의 소통 방식까지 함께 평가해야 한다.

먼저 구분할 것: 매출, 정산액, 이익

스토어 대시보드의 총매출은 통장에 들어온 돈이 아니다. 플랫폼 수수료, 환불, 할인, 세금, 외주비, 광고비를 거친 뒤에야 프로젝트의 실제 현금흐름을 볼 수 있다.

다음은 특정 게임의 실적이 아닌, 계산 방식을 보여 주기 위한 가상 예시다.

항목	금액	확인할 점
총매출	10,000,000원	할인 전후 기준을 통일한다.
플랫폼 수수료	-3,000,000원	계약과 매출 구간에 따라 달라질 수 있다.
환불·차지백	-300,000원	출시 초기와 할인 기간을 따로 본다.
세금·정산 조정	-700,000원	거주 국가와 판매 지역별 규칙을 확인한다.
외주·에셋·번역	-1,500,000원	이미 지출한 비용도 포함한다.
광고·홍보	-800,000원	비용과 유입 결과를 함께 기록한다.
추정 프로젝트 이익	3,700,000원	인건비 포함 여부를 명시한다.

계산식은 단순하다. 다만 각 숫자의 기준일과 포함 범위를 문서 상단에 적어야 비교가 가능하다.

$$\text{프로젝트 이익}=\text{총매출}-\text{플랫폼 수수료}-\text{환불}-\text{세금}-\text{직접비}-\text{마케팅비}$$

개발자의 노동비를 비용으로 넣지 않으면 현금은 남았는데 사업으로는 손해인 상황을 놓치기 쉽다. 첫 작품이라 무급 개발을 선택했더라도 투입 시간을 기록해 두면 다음 게임의 목표 매출과 기간을 현실적으로 잡을 수 있다.

출시 성과는 판매량 하나로 판단하지 않는다

판매량은 결과 지표다. 왜 그 결과가 나왔는지 알려면 발견, 구매, 플레이, 평가의 흐름을 나누어 봐야 한다.

flowchart LR
    A[노출: 스토어·영상·커뮤니티] --> B[관심: 위시리스트·페이지 방문]
    B --> C[구매: 출시·할인 기간]
    C --> D[플레이: 실행·완주·이탈]
    D --> E[반응: 리뷰·환불·문의]
    E --> F[개선: 패치·다음 프로젝트]

예를 들어 위시리스트 수가 기대보다 적었다면 출시일의 가격이나 할인율보다 스토어 페이지와 사전 노출이 우선 과제일 가능성이 크다. 반대로 페이지 방문은 많은데 구매 전환이 낮다면 트레일러 첫 10초, 장르 전달력, 가격, 데모의 완성도를 점검해야 한다. 구매 뒤 환불이 많다면 성능, 조작감, 기대와 실제 콘텐츠의 차이를 확인해야 한다.

다음 표처럼 채널별로 같은 기준을 유지해 기록하면 “어디에 시간을 썼는가”와 “무엇이 실제 반응으로 이어졌는가”를 비교할 수 있다.

채널	기록할 수치	해석할 질문
스토어 페이지	방문 수, 위시리스트 증가, 구매 전환	핵심 재미와 장르가 첫 화면에서 전달되는가?
데모	다운로드, 완주 구간, 피드백	데모가 구매 이유를 만들었는가?
영상·스트리머	조회 수, 링크 클릭, 유입 시점	조회가 스토어 행동으로 이어졌는가?
커뮤니티	질문, 버그 제보, 반복 불만	설명 부족인가, 실제 문제가 있는가?
고객 지원	문의 수, 해결 시간, 환불 사유	출시 후 운영 부담은 감당 가능한 수준인가?

잃은 것은 돈만이 아니다

첫 출시에서 흔히 빠지는 손실은 기회비용이다. 완성도를 높이겠다는 이유로 한 달을 더 쓰는 선택은 타당할 수 있다. 하지만 그 한 달이 출시일을 놓치게 했는지 다른 기능을 검증할 기회를 없앴는지 팀의 피로를 얼마나 키웠는지까지 함께 적어야 한다.

다음 질문은 후회 목록이 아니라 의사결정 기록으로 쓰기 좋다.

일정

• 가장 많이 밀린 작업은 무엇이었나?
• 늦어진 이유는 추정 오류였나, 요구사항 변경이었나, 승인·협업의 병목이었나?
• 다음에는 출시 필수 기능과 출시 후 업데이트 기능을 어떻게 나눌 것인가?

품질

• 출시 직후 가장 많은 버그 제보는 어떤 영역에서 나왔나?
• 자동화 테스트나 실제 기기 테스트가 있었다면 막을 수 있었나?
• 플레이어가 “버그”라고 부른 문제 중 설명과 UX의 문제는 무엇이었나?

마케팅

• 개발 중 가장 일찍 공개한 자료는 무엇이었고 반응은 어땠나?
• 트레일러, 스크린샷, 데모 중 구매 판단에 가장 영향을 준 자료는 무엇이었나?
• 출시일에만 홍보가 몰렸다면 사전 노출을 만들 기회는 어디에 있었나?

숫자를 다시 볼 수 있게 남기는 최소 데이터

스프레드시트 한 장이면 시작할 수 있다. 중요한 점은 출시 첫 주, 첫 달, 할인 기간처럼 비교 단위를 고정하는 것이다. 통화를 섞어 쓰지 말고 환율을 적용했다면 기준일도 함께 저장한다.

A열: 날짜
B열: 판매 수량
C열: 총매출
D열: 환불 금액
E열: 플랫폼 수수료
F열: 광고비
G열: 순현금흐름

H열: 세금·정산 조정
I열: 외주·에셋·번역 등 직접비
G2 = C2-D2-E2-F2-H2-I2

이 표에서 G열은 세금과 직접비까지 반영한 프로젝트 현금흐름으로 계산합니다.

여기에 날짜별 메모 열을 추가해 대형 패치, 영상 공개, 할인 시작, 스트리머 방송처럼 결과에 영향을 준 사건을 적는다. 숫자가 급변한 이유를 나중에 추측하지 않아도 된다.

다음 게임에 남길 결론은 세 가지면 충분하다

포스트모템 끝에는 실행 가능한 문장만 남겨야 한다. “마케팅을 더 잘하자”는 결론이 아니라 누가 언제 무엇을 할지 알 수 있는 문장이 필요하다.

예시는 다음과 같다.

1. 다음 프로젝트에서는 핵심 루프가 들어간 10분짜리 데모를 아트 확장 전에 만든다.
2. 출시 8주 전부터 스토어 페이지의 방문 수와 위시리스트 증가를 매주 같은 시간에 기록한다.
3. 출시 후 첫 72시간은 버그 수정과 문의 대응만 맡을 담당 시간을 미리 비워 둔다.

첫 게임이 큰 수익을 내지 못했더라도 비용 구조와 플레이어 반응을 정확히 남겼다면 다음 게임의 출발점은 훨씬 단단해진다. 반대로 매출 숫자만 기억하면 같은 실수를 더 비싼 프로젝트에서 반복할 가능성이 높다. 좋은 포스트모템은 과거를 미화하지 않고 다음 선택의 비용을 낮춘다.