이 글의 준비·심사 상태는 당시 개발 기록입니다. 이후 이용 경로는 비트웨이브 소개 페이지에서 확인할 수 있습니다.
상점에 상품 15개를 준비했는데 테스트 기기에서는 10개만 보였습니다. 비트웨이브를 아이폰에 올리는 과정에서 만난 문제입니다. 등록 화면을 채웠다는 것과 앱이 상품을 실제로 받아 온다는 것을 따로 확인하게 됐습니다.
App Store 준비에는 계정과 서명, 빌드, 테스트, 심사 자료가 이어졌습니다. 이 글에서는 그중 실제 작업이 멈췄던 지점들을 남깁니다. 상품 수가 달랐던 원인을 하나로 확정하지 못한 부분은 그대로 구분했습니다.
저희 작업 기록에는 2026년 9월 26일 버전 1.0·빌드 27 심사 제출과 제출 직후 ‘심사 대기’ 확인이 남아 있습니다. 아래는 그때까지의 경험입니다. 심사 통과나 현재 App Store 출시를 선언하는 글은 아닙니다.
Apple 개발자 가입: D-U-N-S가 있다고 끝은 아니었습니다
Apple Developer Program 가입 안내에서 먼저 개인과 조직의 요건을 확인합니다. Apple은 개인·개인사업자의 가입과 법적 실체를 갖춘 조직의 가입을 구분합니다. D-U-N-S를 받았다는 사실만으로 조직 가입 자격이 완성되는 것은 아닙니다.
일반 멤버십은 공식 안내상 연 99달러이며, 지역별 현지 통화 가격은 결제 화면에서 확인합니다. D-U-N-S 번호 무료 발급과 개발자 연회비는 다른 항목입니다.
초보자라면 처음부터 ‘사업자니까 무조건 조직’이라고 생각하기보다 법적 사업 형태와 Apple의 가입 조건을 먼저 대조하세요. 출시 직전에 서류를 맞추면 게임 개발과 관계없는 곳에서 일정이 멈출 수 있습니다.
Windows로 개발했는데, 왜 Mac이 필요하죠?
웹게임 화면과 로직은 Windows에서 만들 수 있습니다. 하지만 iOS 앱을 묶고 서명해 올리는 단계는 Mac의 Xcode 또는 Mac 기반 빌드 환경이 필요합니다.
어렵게 보이는 말을 세 개로 나누면 편합니다.
- Bundle ID: Apple 안에서 우리 앱을 구분하는 고유 이름
- 서명·프로비저닝: 어떤 개발자가 어느 앱을 배포할지 맞추는 정보
- 빌드: 코드와 그림을 실제 설치 가능한 앱으로 묶은 결과
저희도 웹 화면만 옮기는 것으로 끝내지 않았습니다. 아이폰에서 소리·터치·화면 복귀가 되는지, 로그인과 결제가 iOS 흐름에 맞게 이어지는지 따로 확인했습니다. 제출 시점에는 Apple이 요구하는 최신 Xcode·SDK 조건도 점검해야 합니다.
TestFlight: 설치됐다고 심사가 끝난 게 아니었습니다
App Store Connect에서 앱 정보를 만들고 빌드를 올립니다. 업로드한 파일의 처리가 끝나야 테스트나 심사에 사용할 빌드를 고를 수 있습니다.
TestFlight는 공개 출시 전에 iPhone에 앱을 설치해 시험하는 도구입니다. 실제 플레이, 로그인, 테스트 구매, 앱을 껐다 켠 뒤 상태를 확인하는 데 사용했습니다. TestFlight 설치 성공은 App Store 심사 통과와 다릅니다.
저희 기록에서는 테스트 환경의 구독 활성 상태와 이용권 지급을 확인했습니다. 다만 이것을 실제 고객의 유료 구매나 운영 광고 수익이 검증된 것으로 적지 않았습니다. TestFlight 공식 소개에서 테스트 범위를 확인할 수 있습니다.
가장 헷갈린 일: 상품 15개를 준비했는데 왜 10개만 보일까?
미국 판매 설정을 준비한 상품은 15개였습니다. 그런데 당시 실제 빌드 27에서는 10개만 조회됐고, 노트 3개와 배경 2개가 빠졌습니다. 숫자가 다르다는 것을 보고, 설정 화면과 기기 화면을 따로 대조했습니다.
이때 구분한 것은 네 가지였습니다.
- 앱 판매 국가: 앱 자체를 어느 지역에 내놓는가
- 상품 판매 국가: 각 인앱상품을 어느 지역에 판매하는가
- Apple Storefront: 테스트에 쓰는 Apple 계정의 스토어 지역
- 게임 로그인 계정: 게임 안에서 저장·보상을 받을 계정
게임에서 Google 계정을 바꿨다고 Apple 스토어 지역이 자동으로 바뀌는 것은 아닙니다. 앱 판매 국가만 맞춰도 모든 상품 설정이 자동으로 같아지는 것도 아닙니다.
저희가 원인을 전부 확정한 것은 아닙니다. 상품 정보 반영 지연도 점검 후보였지만, 그것만이 원인이라고 단정하지 않았습니다. 당시 일부 상품 미조회라는 한계를 기록하고 심사 메모에도 전달했습니다. 이 상태로 제출하면 누구나 승인된다는 요령으로 받아들이면 안 됩니다.
같은 문제가 있다면 상품 ID, 판매 가능 국가, 계약 상태, 기기의 계정·지역을 먼저 확인하세요. 그다음 다시 조회한 시각과 결과를 남기면 ‘방금 바꿨는데 왜 안 되지?’를 반복하는 일을 줄일 수 있습니다. Apple의 테스트 환경 상품 조회 문제 안내도 함께 보세요.
심사 자료: 설명만 예쁘게 쓰면 끝이 아니었습니다
게임 설명·스크린샷·연령 등급 외에도 개인정보, 지원 URL, 로그인 방법, 계정 삭제, 결제 안내를 준비했습니다. 심사자가 실제 기능까지 들어갈 수 있게 접근 방법을 설명하는 것도 중요했습니다.
저희가 확인한 순서는 이렇습니다.
- 스크린샷이 제출하는 버전과 같은가?
- 지원·개인정보 링크가 로그인 없이 열리는가?
- 로그인과 계정 삭제가 실제로 동작하는가?
- 테스트 구매와 복원 뒤 중복 지급이 없는가?
- 미확인 항목이 있다면 무엇인지 정확히 기록했는가?
- 심사할 빌드와 공개 방식이 의도한 설정인가?
저희는 9월 26일 빌드 27을 제출한 뒤 심사 대기 상태를 확인했습니다. 자동 공개를 선택한 경우 승인 후 공개가 이어질 수 있어, 제출 전 공개 설정도 함께 확인했습니다.
등록 칸을 채운 뒤에도 남았던 확인
상품을 등록하고 빌드를 올린 뒤에도 기기에서 무엇이 보이는지 다시 확인해야 했습니다. 특히 상품 15개와 조회된 10개의 차이는 등록 화면만 보고 넘어갈 수 없었던 부분입니다.
다음 등록에서는 빌드 번호, 상품 ID, 테스트 환경, 확인 시각을 한 기록에 묶어 두려 합니다. 원인을 확정하지 못한 것은 해결했다고 적지 않습니다. 빌드 환경이 필요한 분을 위해 Windows에서 클라우드 Mac으로 iOS 빌드를 진행한 후속 기록도 남겼습니다.