이 글의 준비·심사 상태는 당시 개발 기록입니다. 이후 이용 경로는 앱 소개 페이지에서 확인할 수 있습니다.
같은 게임을 여러 플랫폼에 올리는 일은 파일 하나를 세 번 업로드하는 작업이 아니었습니다. 토스 미니앱, 원스토어, Google Play는 실행 방식부터 결제·광고·심사 자료까지 서로 달랐습니다. 나인투식스랩의 리듬게임 BEATWAVE 등록을 맡은 NtoSL 작업에서 실제로 확인한 차이를 초보자 눈높이로 정리합니다.
원스토어에는 비트웨이브 APK, 전체이용가 등급, 수집 정보, 인앱상품 정보를 저장했습니다. 당시에는 검수 요청과 판매 개시 전이었습니다. 이후 진행한 내용은 원스토어 출시 기록, Google Play 등록 경험, App Store 심사 제출 경험에서 이어집니다. 아래의 준비 과정은 당시 기록으로 읽어 주세요.
먼저 알게 된 것: ‘게임 완성’과 ‘출시 준비 완료’는 다르다
개발 화면에서 게임이 잘 실행돼도 스토어는 더 많은 것을 확인합니다. 어떤 정보를 수집하는지, 계정을 어떻게 삭제하는지, 유료 상품은 실제로 지급되는지, 환불하면 권한이 회수되는지, 광고 보상은 중복 지급되지 않는지까지 설명과 동작이 맞아야 합니다.
비트웨이브도 자동 검사와 Android 빌드는 통과했지만, 그 결과만으로 출시 완료라고 말하지 않았습니다. 테스트 코드 통과와 실제 휴대폰에서의 로그인·구매·복구·환불은 다른 검증이기 때문입니다.
플랫폼별로 무엇이 달랐나
| 구분 | 앱인토스 | 원스토어 | Google Play |
|---|---|---|---|
| 실행 형태 | 토스 안에서 실행되는 미니앱 번들 | 서명된 Android APK | 일반적으로 Android App Bundle(AAB) |
| 결제·광고 | 토스 전용 SDK와 광고 지면 | ONE store 결제 SDK와 상품 등록 | Google Play 결제·선택한 광고 SDK·데이터 공개 |
| 출시 전 핵심 | 샌드박스와 콘솔 검수 | 바이너리·IARC·상품·실결제 테스트 | 테스트 트랙·데이터 보안·계정 삭제 |
앱인토스: 웹게임이어도 토스 전용 준비가 필요했다
앱인토스는 웹 기술로 만든 게임을 토스 안에서 실행할 수 있다는 점이 장점입니다. 하지만 일반 웹사이트 주소를 넣는 방식은 아닙니다. 앱 이름과 실행 경로를 정하고, 전용 프레임워크로 번들을 만들고, 샌드박스에서 동작을 확인한 뒤 콘솔 검수를 거칩니다.
- 일반 브라우저와 토스 앱 안의 실행 환경을 따로 확인합니다.
- 보상형 광고는 토스에서 발급한 전용 광고 식별자와 SDK 흐름을 사용합니다.
- 광고를 끝까지 본 경우에만 보상을 지급하고, 닫기·오류·연속 클릭에는 지급하지 않도록 확인합니다.
- 이미 출시한 앱의 업데이트와 처음 출시하는 앱의 심사 흐름도 같다고 가정하면 안 됩니다.
비트웨이브의 공개 웹 테스트에서 사용한 모의 충전이나 일반 Android용 광고 설정은 토스 운영 빌드에 그대로 가져갈 수 없습니다. 플랫폼 전용 기능은 플랫폼별 코드와 검증이 필요했습니다.
원스토어: APK 업로드보다 상품과 서버 연결이 더 오래 걸렸다
원스토어에서는 서명된 APK를 준비하고 앱 정보, 배포 국가, 수집 정보, 이미지, 연령등급, 인앱상품을 입력합니다. 비트웨이브는 APK를 콘솔에 저장하고 IARC 설문을 통해 대한민국 전체이용가 등급을 받았습니다. 고정 가격 상품과 월정액 상품도 등록했습니다.
여기서 가장 중요한 점은 상품이 콘솔에 보인다고 결제가 완성된 것은 아니라는 사실입니다. 구매 요청, 영수증 서버 검증, 지급, 소비 또는 승인, 구매 복원, 취소·환불 알림까지 연결되어야 합니다. 당시에는 상품과 결제·광고 기능을 비활성 상태로 두고 실제 기기 검증을 먼저 진행했습니다.
- 기존 앱과 같은 개발자 서명을 유지했는지 확인합니다.
- 앱에 있는 상품 ID와 콘솔 상품 ID가 정확히 일치하는지 봅니다.
- 테스트 ID와 원스토어가 설치된 실제 Android 기기로 구매·취소·복원을 확인합니다.
- 환불 알림을 받았을 때 서버 권한도 함께 회수되는지 확인합니다.
- 확률형 상품이 없다면 설문과 상품 구조에도 그대로 표시합니다.
Google Play: 빌드 외에 ‘정책 화면’을 완성해야 했다
Google Play는 앱 정보와 스토어 이미지를 채운 뒤 테스트 트랙에서 먼저 검증하고 프로덕션 출시로 이동하는 흐름입니다. Google 공식 안내처럼 앱은 Android App Bundle을 기준으로 관리되고, 버전이 올라갈 때마다 versionCode도 증가해야 합니다.
로그인 계정이 있는 앱이라면 계정 삭제가 특히 중요합니다. 앱 안에서 삭제 요청 경로를 제공하는 것과 함께, 앱을 지운 사용자도 접근할 수 있는 웹 삭제 안내가 필요합니다. 개인정보처리방침의 문장, Data safety 답변, 앱의 실제 동작이 서로 다르면 심사에서 문제가 됩니다.
- 내부 테스트에서 설치·로그인·결제·광고를 확인합니다.
- 개인정보 수집과 제3자 SDK의 수집 항목을 Data safety에 맞게 공개합니다.
- 앱 안과 홈페이지 양쪽에 계정 삭제 경로를 둡니다.
- 스토어 설명과 스크린샷이 현재 앱 화면과 같은지 확인합니다.
실제로 가장 많이 막힌 다섯 가지
- 콘솔 입력과 앱 동작이 따로 놀았다. 상품을 등록해도 앱의 상품 식별자와 서버 검증이 맞지 않으면 구매할 수 없습니다.
- 에뮬레이터만으로 끝낼 수 없었다. 원스토어 앱 설치, OAuth 복귀, 실제 결제처럼 실기기가 필요한 구간이 있었습니다.
- 개인정보 문구가 너무 단순했다. 로그인, 구매 내역, 진단 정보, 광고 SDK를 실제 사용한다면 수집·이용·삭제 안내도 그에 맞춰야 합니다.
- 광고 보상은 클라이언트 신호만 믿을 수 없었다. 플랫폼이 제공하는 완료 신호와 서버 검증 방식을 확인하고, 같은 완료 건에 보상이 두 번 지급되지 않게 처리해야 했습니다. 서명 검증 지원 여부와 구현은 광고 플랫폼마다 다릅니다.
- ‘저장’과 ‘제출’을 구분해야 했다. APK를 올리고 정보를 저장하는 단계와 검수 요청 버튼을 누르는 단계, 승인 뒤 판매를 시작하는 단계는 서로 다릅니다.
초보자가 그대로 쓸 수 있는 출시 체크리스트
빌드
- 패키지명과 앱 이름 확정
- 릴리스 서명과 버전 번호 확인
- 테스트 기능·관리자 기능이 운영 빌드에서 꺼졌는지 확인
스토어 자료
- 아이콘, 대표 이미지, 실제 화면 스크린샷
- 짧은 설명과 상세 설명
- 고객 문의 이메일과 홈페이지
정책
- 개인정보처리방침
- 계정 삭제와 데이터 삭제 안내
- 청약철회·환불·구독 해지 경로
- 연령등급과 광고·인앱결제 표시
실기 검증
- 신규 설치, 업데이트, 로그인 복귀
- 구매, 지급, 소비, 복원, 취소, 환불
- 광고 완료·중도 종료·네트워크 오류
- 계정 삭제 후 데이터 처리
NtoSL 작업에서 정한 진행 순서
당시에는 원스토어 Android 등록을 먼저 마무리하고, 앱인토스 전용 기능을 확인한 뒤 Google Play와 Apple App Store로 넓히는 순서를 정했습니다. 순서를 정한 이유는 한 플랫폼에서 결제·환불·계정 삭제의 끝단까지 먼저 검증하면 다음 플랫폼에서 반복할 공통 문제를 줄일 수 있기 때문입니다.
다만 한 플랫폼에서 통과한 결과를 다른 플랫폼의 승인으로 보지는 않습니다. 원스토어 등급이 Google Play의 Data safety 답변을 대신하지 않고, 토스 광고 테스트가 AdMob 광고 검증을 대신하지도 않습니다.
공식 문서 바로가기
- 앱인토스 개발자 문서
- ONE store 개발자 센터
- ONE store 상품 검증 가이드라인
- Google Play 앱 만들기와 설정
- Google Play 계정 삭제 요구사항
- Apple App Review 제출 안내
마지막으로 얻은 교훈
스토어 등록의 핵심은 파일 업로드 속도가 아니었습니다. 앱이 약속한 내용, 콘솔에 적은 내용, 서버가 실제로 처리하는 내용이 서로 같은지 확인하는 일이 가장 오래 걸렸습니다.
처음 등록한다면 한 번에 모든 플랫폼을 열기보다 한 곳에서 설치부터 환불까지 끝까지 통과한 뒤 다음 플랫폼으로 넘어가는 편이 안전합니다. 나인투식스랩도 검수 버튼을 빨리 누르는 것보다, 실제 사용자가 결제하거나 계정을 삭제했을 때 문제가 남지 않는 상태를 먼저 만들고 있습니다.
이 글은 2026년 9월 24일 비트웨이브 등록 작업 기록과 각 플랫폼 공식 문서를 기준으로 작성했습니다. 콘솔 정책과 요구사항은 바뀔 수 있으므로 제출 직전 공식 문서를 다시 확인하세요.