스토어 등록과 출시 준비

출시는 버튼 하나가 아니라 세 가지를 맞추는 일이다

출시는 게임 파일을 업로드하고 공개 버튼을 누르는 일이 아니다. 빌드, 상점 페이지, 커뮤니케이션이 같은 날짜에 맞물려야 하는 작은 프로젝트다.

빌드는 플레이어가 실제로 실행할 파일이다. 상점 페이지는 플레이어가 구매를 결정하는 장소다. 커뮤니케이션은 리뷰어, 스트리머, 커뮤니티, 기존 위시리스트 유저에게 "이 게임이 언제, 어디서, 어떤 상태로 나온다"는 사실을 알려주는 과정이다.

이 셋 중 하나만 늦어도 출시 효과는 약해진다. 게임은 완성됐지만 상점 페이지가 설득력이 없으면 구매가 줄어든다. 상점 페이지는 준비됐지만 출시 후보 빌드가 불안정하면 첫 리뷰가 무너진다. 빌드와 상점이 모두 준비됐어도 아무도 출시일을 모르면 첫날 유입이 작다.

따라서 출시 준비는 다음 질문으로 시작한다.

• 플레이어가 오늘 구매해도 끝까지 플레이할 수 있는가?

• 상점 페이지가 게임의 핵심 매력을 10초 안에 보여주는가?

• 출시 당일 문제가 생겼을 때 누가, 어디서, 어떻게 대응하는가?

AI 생성 이미지

플랫폼별로 막히는 지점이 다르다

PC 스토어: 페이지와 빌드 심사를 따로 준비한다

PC 출시에서 많은 인디 개발자가 먼저 고려하는 곳은 Steam이다. Steam은 파트너 등록, 세금·은행 정보 입력, 제품별 등록비 결제, 상점 페이지 구성, 빌드 업로드, 가격 입력 같은 절차를 거친다. Steam Direct 기준으로 제품마다 등록비가 있으며, 상점 페이지와 빌드는 공개 전 검토를 받는다. 공식 안내에서는 검토에 보통 1~5일이 걸린다고 설명한다. 또한 첫 몇 개 타이틀은 등록비 결제 후 출시까지 30일의 대기 기간이 있고, 공개된 '출시 예정' 페이지도 최소 2주 동안 열어두어야 한다¹.

여기서 중요한 점은 빌드 심사와 상점 페이지 심사가 모두 필요하다는 것이다. 게임 실행은 되지만 상점 설명이 부정확하거나, 스크린샷이 실제 플레이와 다르거나, 권리가 없는 음악·이미지를 사용하면 문제가 된다. 반대로 상점 페이지는 멀쩡해도 실행 파일이 백신에 걸리거나, 첫 실행에서 크래시가 나거나, 저장 폴더 권한 문제가 생기면 출시가 지연될 수 있다.

PC 출시 전에는 최소한 다음을 확인한다.

• 새 컴퓨터에 처음 설치해도 정상 실행되는가?

• 최소 사양 PC에서 목표 프레임에 근접하는가?

• 키보드, 마우스, 컨트롤러 입력이 설명과 일치하는가?

• 저장 파일 경로와 삭제, 새 게임 시작, 이어하기가 정상인가?

• 업적, 클라우드 저장, 오버레이 등 스토어 기능을 켰다면 실제로 작동하는가?

• 상점의 장르 태그와 실제 플레이가 크게 어긋나지 않는가?

Itch.io 같은 비교적 가벼운 플랫폼은 심사 부담이 낮은 편이지만, 그만큼 개발자가 직접 품질과 결제 안내, 다운로드 파일 구조, 업데이트 공지를 관리해야 한다. Epic Games Store, GOG 등은 입점 방식과 요구 조건이 다르므로, 목표 플랫폼을 정한 뒤 파트너 문서를 따로 확인해야 한다.

모바일: 심사보다 운영 조건을 먼저 생각한다

모바일은 설치 장벽이 낮지만 심사와 정책, 기기 대응 부담이 크다. iOS와 Android 모두 개발자 계정, 앱 식별자, 서명 인증서, 패키지 이름, 개인정보 처리방침, 연령 등급, 스크린샷, 설명문, 앱 내 결제 설정 등을 요구한다.

Google Play는 내부 테스트, 비공개 테스트, 공개 테스트, 사전 출시 보고서, 단계적 출시 같은 도구를 제공한다. 작은 팀이라도 이를 활용하면 모든 유저에게 한 번에 배포하기 전에 크래시, 성능, 기기 호환성 문제를 일부 확인할 수 있다². 앱 스토어 정책과 계정별 요구사항은 바뀔 수 있으므로, 출시 일정표를 만들 때는 항상 최신 콘솔 문서와 개발자 공지를 다시 확인해야 한다.

모바일 심사에서 자주 막히는 항목은 다음과 같다.

• 앱을 켜자마자 크래시가 난다.

• 권한 요청 이유가 불명확하다.

• 개인정보 처리방침이 없거나 실제 수집 정보와 다르다.

• 광고, 추적, 앱 내 결제 표시가 정책과 맞지 않는다.

• 로그인 필수 게임인데 심사용 테스트 계정을 제공하지 않았다.

• 태블릿, 긴 화면, 노치 영역, 가로·세로 회전 대응이 부족하다.

• 연령 등급과 게임 내 폭력성, 도박성, 채팅 기능이 맞지 않는다.

첫 모바일 게임이라면 전 세계 동시 출시보다 제한된 국가, 제한된 비율, 제한된 기기 범위로 시작하는 방식을 검토할 수 있다. 작은 출시로 데이터를 보고, 치명적인 문제가 없을 때 넓히는 편이 안전하다.

콘솔: 게임 완성 후 시작하면 늦다

콘솔 출시는 별도의 파트너 등록, 개발 장비, 플랫폼별 기술 요구사항, 연령 등급, 심사 절차가 필요하다. PlayStation, Xbox, Nintendo는 각각 세부 용어와 문서 체계가 다르지만, 공통적으로 "게임이 플랫폼의 기본 동작 규칙을 지키는가"를 강하게 본다.

콘솔에서 자주 문제가 되는 것은 게임의 재미보다 플랫폼 상황 처리다. 예를 들어 절전 모드에 들어갔다가 돌아왔을 때 멈추지 않는가, 컨트롤러가 분리되면 안내가 뜨는가, 다른 사용자 프로필로 바뀌어도 저장 데이터가 섞이지 않는가, 네트워크가 끊겼을 때 게임이 종료되지 않는가, 버튼 아이콘이 해당 플랫폼 기준과 맞는가 같은 항목이다. 콘솔 인증은 한 번 실패하면 수정과 재제출로 일정이 크게 늘어날 수 있으므로, 출시 일정에는 재심사 가능성을 넣어야 한다³.

첫 인디게임이라면 PC나 모바일로 먼저 출시하고, 반응과 안정성을 확인한 뒤 콘솔 이식을 검토하는 전략도 현실적이다. 콘솔을 처음부터 목표로 한다면 개발 초기에 입력, 저장, 해상도, 성능, 현지화 구조를 콘솔 기준으로 설계해야 한다.

상점 페이지는 조용한 영업사원이다

상점 페이지는 게임 설명서가 아니라 구매 결정을 돕는 화면이다. 플레이어는 보통 긴 설명을 먼저 읽지 않는다. 캡슐 이미지, 첫 스크린샷, 짧은 트레일러, 태그, 가격, 리뷰 분위기를 보고 계속 볼지 결정한다.

설명문은 '무엇을 하는 게임인지'부터 말한다

좋은 설명문은 세계관을 길게 소개하기 전에 플레이어 행동을 먼저 말한다.

나쁜 예:

오래전 잊힌 왕국의 비밀을 찾아 떠나는 장대한 여정.

개선 예:

10분 안에 던전을 돌파하며, 매 방마다 무기 하나를 버리고 새 전략을 선택하는 짧은 로그라이트 액션 게임.

두 번째 문장은 장르, 플레이 시간, 핵심 선택, 반복 구조가 보인다. 상점 설명의 첫 문단은 이 정도로 구체적이어야 한다.

설명문 체크리스트는 간단하다.

• 플레이어가 어떤 역할을 맡는가?

• 가장 자주 하는 행동은 무엇인가?

• 실패와 재도전은 어떻게 일어나는가?

• 콘텐츠 규모는 어느 정도인가?

• 싱글플레이, 협동, 온라인, 컨트롤러 지원 여부가 명확한가?

• 지원 언어와 자막 여부가 실제 빌드와 일치하는가?

트레일러는 첫 5초가 핵심이다

출시 트레일러는 분위기 영상이 아니라 구매 판단 자료다. 첫 5초 안에 실제 플레이 화면이 나와야 한다. 로고, 검은 화면, 긴 문장, 느린 카메라 이동으로 시작하면 많은 플레이어가 이탈한다.

작은 게임의 트레일러 구성은 다음 정도면 충분하다.

1. 0~5초: 가장 강한 플레이 장면

2. 5~20초: 핵심 조작과 목표

3. 20~40초: 변형 요소, 적, 퍼즐, 성장, 선택

4. 40~55초: 콘텐츠 폭과 분위기

5. 마지막: 출시일, 플랫폼, 게임명

트레일러에는 실제 게임에 없는 장면을 넣지 않는다. 연출용 화면을 쓰더라도 실제 플레이 기대를 속이면 첫 리뷰에서 바로 드러난다.

캡슐 이미지와 태그는 발견 가능성을 바꾼다

캡슐 이미지는 작은 썸네일 상태에서도 읽혀야 한다. 게임명, 장르 분위기, 주인공 또는 핵심 오브젝트가 구분되어야 한다. 너무 많은 캐릭터와 문구를 넣으면 작게 보였을 때 아무것도 남지 않는다.

태그는 알고리즘을 속이는 단어가 아니라 정확한 분류다. 인기 태그를 억지로 붙이면 잘못된 기대를 가진 유저가 들어오고, 구매 전환과 리뷰가 나빠질 수 있다. "로그라이크", "소울라이크", "오픈월드", "멀티플레이어"처럼 기대치가 강한 태그는 실제 구조가 그에 맞을 때만 사용한다.

지원 언어도 구매 결정에 영향을 준다. 영어만 지원하는지, 한국어 UI만 있는지, 자막까지 번역했는지, 음성은 어느 언어인지 분명히 적어야 한다. 지원 언어를 넓게 표시해 놓고 일부 메뉴만 번역되어 있으면 신뢰를 잃는다.

릴리즈 후보 빌드를 고정한다

출시 직전 가장 위험한 말은 "이 기능 하나만 더 넣자"다. 작은 기능도 입력, 저장, UI, 번역, 밸런스, 버그를 함께 건드린다. 출시 후보 빌드가 정해진 뒤에는 새 기능을 넣지 않는 릴리즈 프리즈가 필요하다.

릴리즈 프리즈는 개발을 멈춘다는 뜻이 아니다. 게임을 안정화하는 기간이다.

• 기능 프리즈: 새 시스템, 새 모드, 새 콘텐츠 추가 금지

• 콘텐츠 프리즈: 스테이지, 대사, 아이템 수량 고정

• 문자열 프리즈: 번역이 필요한 문장 추가 금지

• 빌드 프리즈: 출시 후보 빌드 번호 고정

• 예외 규칙: 진행 불가, 크래시, 저장 손상, 심각한 결제 오류만 수정

수정 여부는 감정이 아니라 등급으로 판단한다.

출시 후보 빌드를 고정한 뒤에는 같은 테스트를 반복한다. 새로 고친 버그만 보지 말고, 이전에 고친 핵심 버그가 다시 생기지 않았는지 확인한다. 이것을 회귀 테스트라고 한다. 특히 저장, 로딩, 재시작, 엔딩, 옵션, 해상도 변경, 언어 변경, 컨트롤러 연결 해제는 마지막까지 확인해야 한다.

프레스킷과 코드 배포를 준비한다

리뷰어와 스트리머에게 "게임 해주세요"라고만 보내면 반응이 낮다. 상대가 바로 이해하고 사용할 수 있는 자료가 필요하다. 이것이 프레스킷이다.

프레스킷에는 보통 다음을 넣는다.

• 게임 한 줄 소개

• 짧은 설명문과 긴 설명문

• 핵심 특징 3~5개

• 출시일, 플랫폼, 가격, 지원 언어

• 개발자 또는 스튜디오 소개

• 연락 가능한 이메일

• 상점 페이지 링크

• 트레일러 다운로드 링크

• 고해상도 스크린샷 6~10장

• 로고, 키아트, 캡슐 이미지

• GIF나 짧은 클립

• 리뷰용 빌드 또는 키 요청 방법

프레스킷 자료는 웹페이지 하나와 압축 파일 하나로 준비하면 좋다. 기자는 이미지를 바로 내려받을 수 있어야 하고, 스트리머는 방송 화면에 쓸 로고와 게임 설명을 빠르게 찾을 수 있어야 한다. 실제 프레스킷 가이드에서도 설명문, 영상, 스크린샷, 로고, 키아트, 연락처, 다운로드 묶음을 기본 구성으로 권장한다⁴.

코드 배포, 즉 리뷰용 스토어 키 배포는 더 조심해야 한다. 출시 전 키를 무작정 많이 뿌리면 리셀러나 사기 요청에 노출될 수 있다.

코드 배포 절차는 이렇게 정한다.

1. 요청 메일과 신청 폼을 만든다.

2. 채널 링크, 이메일 도메인, 과거 콘텐츠를 확인한다.

3. 승인한 사람에게만 키를 보낸다.

4. 키 번호, 발송일, 대상, 플랫폼을 기록한다.

5. 엠바고가 있다면 날짜와 시간을 명확히 쓴다.

6. 긍정 리뷰를 요구하지 않는다.

7. 사용하지 않은 키는 출시 후 회수하거나 비활성화 가능 여부를 확인한다.

리뷰어에게는 긴 기획 의도보다 실용 정보가 필요하다. 플레이 시간, 저장 방식, 알려진 버그, 콘텐츠 제한, 스포일러 구간, 연락처를 짧게 제공한다. 스트리머에게는 음악 저작권 문제 여부도 알려야 한다. 방송 중 저작권 경고가 뜰 가능성이 있다면 별도 스트리머 모드나 음악 끄기 옵션을 제공하는 것이 좋다.

출시 주간 체크리스트

출시 준비는 날짜별로 쪼개야 한다. 다음은 작은 PC 인디게임 기준 예시다. 모바일이나 콘솔은 심사 기간을 더 길게 잡는다.

출시 4주 전

• 상점 페이지 공개 상태 확인

• 가격, 지원 언어, 시스템 요구 사양 입력

• 트레일러 최종 편집 시작

• 프레스킷 초안 작성

• 외부 테스트 마지막 라운드 진행

• 출시 후보 빌드 기준 정하기

출시 2주 전

• 릴리즈 프리즈 시작

• 출시 후보 빌드 업로드

• 상점 설명문, 스크린샷, 태그 재검토

• 리뷰어·스트리머 1차 연락

• 커뮤니티 공지 초안 작성

• 치명적 버그 목록만 남기기

출시 1주 전

• 최종 빌드 실행 테스트

• 새 설치, 저장, 엔딩, 옵션, 언어 변경 확인

• 출시 트레일러 예약 업로드

• 출시 당일 게시물 예약

• 코드 발송 목록 정리

• 핫픽스 담당자와 대응 시간 정하기

출시 전날

• 공개 시간과 시간대 확인

• 상점 페이지 링크 확인

• 가격과 할인율 확인

• 프레스킷 링크 확인

• 커뮤니티 공지, 메일, 소셜 문구 최종 확인

• 긴급 연락 채널 열어두기

출시 당일

• 상점 공개 상태 확인

• 구매, 설치, 실행 테스트

• 트레일러와 공지 게시

• 리뷰어·스트리머에게 출시 알림 발송

• 커뮤니티, 버그 제보, 리뷰 모니터링

• 치명적 문제만 핫픽스 대상으로 분류

출시 당일에는 모든 피드백에 즉시 반응하고 싶어진다. 하지만 첫날의 목표는 방향 수정이 아니라 안정화다. "재미없다"는 의견 하나로 게임을 바꾸지 말고, "게임이 실행되지 않는다", "저장이 날아간다", "결제가 지급되지 않는다" 같은 치명적 문제부터 처리한다.

마지막 점검표

출시 버튼을 누르기 전, 다음 질문에 모두 답할 수 있어야 한다.

• 출시 후보 빌드 번호가 무엇인가?

• 이 빌드로 처음부터 끝까지 클리어했는가?

• 새 기능 추가가 중단되었는가?

• 상점 페이지의 스크린샷과 실제 게임이 일치하는가?

• 트레일러 첫 5초에 실제 핵심 플레이가 보이는가?

• 가격, 할인율, 지원 언어, 시스템 요구 사양이 맞는가?

• 개인정보, 연령 등급, 저작권, 라이선스 문제가 없는가?

• 리뷰어와 스트리머에게 보낼 프레스킷이 준비되었는가?

• 키 발송 기록을 남길 표가 있는가?

• 출시 당일 누가 커뮤니티와 버그를 확인하는가?

• 핫픽스가 필요할 때 빌드하고 배포할 수 있는가?

출시는 개발의 끝이 아니라 플레이어와 만나는 시작점이다. 하지만 첫 만남에서 실행 불가, 잘못된 설명, 준비되지 않은 대응이 나오면 회복이 어렵다. 좋은 출시는 운이 아니라 체크리스트에서 나온다. 게임을 작게 만들었듯, 출시도 작은 항목으로 나누어 하나씩 닫아야 한다.

참고

¹Steamworks Partner Program

²Release | Google Play Console

³Console Certification Complete Guide – TRC, TCR & LOT Checks

⁴Press Kit Guide for Indie Games