새 구독 상품의 테스트 결제는 성공했지만 단독 심사 항목으로 추가되지 않습니다.
가장 빠른 해결법은 상품 유형별 첫 상품인지 먼저 확인하는 것입니다. 2026년에는 App Store Connect의 인앱 결제 또는 구독 세부 화면에서 Add for Review로 심사 제출을 만들며, 해당 유형의 첫 상품은 새 앱 버전과 함께 제출해야 합니다. 같은 유형의 상품이 이미 승인되었고 승인된 앱 버전도 있다면 후속 상품은 조건에 따라 앱 버전 없이 제출할 수 있습니다. Apple의 인앱 결제 제출 안내에서 이 구분을 확인할 수 있습니다.
이 글은 처음으로 소모성 상품, 비소모성 상품 또는 구독을 등록하는 독립 개발자를 위한 안내입니다.
이미 유료 상품을 운영하면서 새 요금제나 새 구독을 추가하는 개발자, 원격 맥에서 빌드를 만들고 심사 과정을 안정화하려는 작은 팀에도 적합합니다.
마지막 업데이트: 2026년 8월 29일. Add for Review, 첫 상품 조건과 빌드 지원 범위는 App Store Connect 공식 출시 안내 및 앱 제출 요구 사항을 기준으로 확인했습니다.
제출 자격부터 판정하기
App Store Connect 인앱 결제 제출에서 가장 먼저 볼 항목은 상품의 테스트 성공 여부가 아닙니다. 다음 조건을 순서대로 확인해야 합니다.
- 상품이 소모성, 비소모성, 자동 갱신 구독 또는 비갱신 구독 중 어디에 속하는지 확인합니다.
- 같은 상품 유형에서 이미 승인된 상품이 있는지 확인합니다.
- 앱에 승인된 버전이 존재하는지 확인합니다.
세 조건은 서로 대체되지 않습니다. 예를 들어 자동 갱신 구독이 이미 승인되었더라도 비소모성 상품의 첫 상품 조건을 충족하는 것은 아닙니다. 상품 유형별 첫 상품은 새 앱 버전에 연결해야 하며, 이후 상품은 같은 유형의 승인 이력과 승인된 앱 버전이 있을 때 독립 제출 가능성이 생깁니다. 내부 결제 제출 조건에 대한 공식 설명을 기준으로 상품별 승인 이력을 따로 기록해야 합니다.
따라서 “새 구독이 왜 단독 심사되지 않는가”라는 문제는 대개 구독 그룹에 상품을 연결했는지와 별개로, 그 구독 유형의 첫 승인 상품인지 확인하지 않았기 때문에 발생합니다. 샌드박스에서 구매가 완료되었다는 사실은 결제 동작을 확인했다는 뜻일 뿐, 심사 제출에 필요한 상품 정보가 완성되었다는 뜻은 아닙니다.
심사 자료를 먼저 완성하기
상품을 제출하기 전에 상태와 메타데이터를 점검해야 합니다. 상품이 준비 중인지, 판매 가능 상태인지, 심사 중인지에 따라 화면에서 선택할 수 있는 제출 방식이 달라질 수 있습니다.
다음 항목은 상품마다 별도로 확인합니다.
- 표시 이름과 설명의 현지화 정보가 준비되어 있는지 확인합니다.
- 가격과 판매 가능 지역을 의도한 설정으로 저장했는지 확인합니다.
- 심사용 스크린샷을 등록했는지 확인합니다.
- 검토 메모에 구매 진입 경로와 테스트에 필요한 설명을 적었는지 확인합니다.
- 앱 안에서 상품을 실제로 찾을 수 있는 화면과 조건을 설명했는지 확인합니다.
인앱 결제 정보와 심사 자료 편집 안내에 표시되는 항목을 기준으로 확인하는 편이 안전합니다. 개발 기기에서 구매가 성공했더라도 현지화, 심사 스크린샷 또는 검토 메모가 빠지면 심사 자료 부족으로 처리될 수 있습니다.
자동 갱신 구독이라면 Subscription Group에 상품이 연결되어 있어야 합니다. 첫 구독 제출에서는 앱 버전, 구독 그룹, 구독 상품이 같은 심사 초안에 들어가는지 확인해야 합니다. 후속 구독은 승인 이력과 앱 버전 조건을 충족할 때만 별도 제출을 검토할 수 있습니다.
Add for Review 초안 만들기
App Store Connect의 인앱 결제 또는 구독 관리 영역에서 상품을 선택한 뒤 Add for Review를 사용합니다. 이때 기존 심사 초안에 상품을 추가할 수도 있고, 새 제출 초안을 만들 수도 있습니다. 중요한 것은 버튼을 찾는 것보다 이번 제출에 어떤 객체가 묶였는지 확인하는 일입니다.
첫 상품이라면 제출 내용에 다음 항목이 함께 보여야 합니다.
- 심사할 앱 버전
- 해당 상품 유형의 첫 인앱 결제 상품 또는 첫 구독 상품
- 자동 갱신 구독일 경우 Subscription Group
- 심사 자료가 완성된 상품 정보
후속 상품이라면 앱 버전이 반드시 포함되는지부터 단정하지 말고, 상품의 승인 이력과 앱의 승인 버전을 다시 대조합니다. 심사 제출 전체 흐름에 따라 제출 초안의 객체 목록과 각 객체의 상태를 함께 확인해야 합니다.
제출 내용 확인 목록
- [ ] 상품 유형을 기존 승인 상품의 유형과 비교했습니다.
- [ ] 해당 유형의 첫 승인 상품인지 후속 상품인지 기록했습니다.
- [ ] 첫 상품이면 새 앱 버전과 함께 초안에 넣었습니다.
- [ ] 첫 구독이면 구독 그룹과 구독 상품을 같은 초안에 넣었습니다.
- [ ] 현지화, 가격, 판매 범위, 스크린샷, 검토 메모를 확인했습니다.
- [ ] 앱에서 구매 화면으로 이동하는 경로를 실제 빌드에서 확인했습니다.
- [ ] Submit for Review 전에 제출 초안에 포함된 객체를 캡처했습니다.
빌드와 상품 연결 확인
새 앱 버전이 필요한 경우에는 심사 가능한 빌드를 먼저 업로드해야 합니다. Xcode 26 정식 배포 흐름에서는 Archive 이후 올바른 앱 버전을 선택하고, 처리 완료된 빌드를 해당 버전에 연결합니다. 업로드 직후 화면에 보이는 상태만으로 완료를 판단하지 말고 빌드 업로드 상태 정의에서 처리, 검증, 실패 상태를 구분해야 합니다.
상품 연결도 별도로 확인합니다. 빌드가 처리되었더라도 앱 안에 구매 진입점이 없거나, 로그인 조건 때문에 심사자가 상품을 찾지 못하면 심사 재현성이 떨어집니다. Product ID, Bundle ID, Team ID, 계정 이름, 스크린샷과 로그는 외부 문서에 올리기 전에 반드시 가립니다.
Xcode 27 Beta 6 빌드는 2026년 8월 29일 기준으로 TestFlight 내부 및 외부 테스트에 사용할 수 있지만, 이를 정식 App Store 고객 배포가 가능한 빌드라고 설명해서는 안 됩니다. 베타 지원 범위는 App Store Connect 출시 안내에서 다시 확인해야 합니다. 정식 심사가 목적이면 Xcode 26의 정식 배포 경로를 기준으로 빌드를 검증해야 합니다.
원격 맥을 사용하는 팀은 다음 복구 지점도 확인합니다.
- 서명 인증서와 프로비저닝 프로파일이 올바른 키체인에 있는지 확인합니다.
- 업로드 인증 정보가 개발용 계정과 분리되어 있는지 확인합니다.
- 연결이 끊긴 뒤 Archive 결과와 업로드 로그가 남아 있는지 확인합니다.
- 빌드 처리 상태를 원격 세션이 아니라 App Store Connect에서 다시 확인합니다.
서명과 업로드를 반복해야 한다면 RUVCLOUD의 원격 맥 이용 경로를 검토할 수 있습니다. 다만 물리 기기 연결이나 장기간 고정 부하가 핵심이면 자체 장비가 더 적합할 수 있습니다.
상태별 재제출 처리
Submit for Review를 누른 뒤에는 앱 버전, 인앱 결제 상품, 구독 그룹, 심사 제출의 상태를 따로 추적합니다. 빌드가 처리 완료라는 사실은 업로드 파이프라인이 끝났다는 의미이지, 상품 심사가 승인되었다는 의미가 아닙니다. 앱과 제출 상태 정의를 기준으로 객체별 상태를 기록해야 합니다.
상품이 거절되었다면 먼저 Messages에서 거절 사유가 연결된 객체를 찾습니다. 가격이나 설명 문제면 상품 정보를 수정하고, 앱에서 상품을 찾지 못하는 문제면 빌드와 검토 메모를 점검합니다. 수정 대상이 상품 정보라면 변경하지 않은 바이너리를 습관적으로 다시 업로드할 필요는 없습니다.
수정 후에는 Update Review와 Resubmit 흐름을 사용합니다. 앱 버전과 상품이 함께 제출된 경우에는 어느 객체가 심사를 막고 있는지 확인한 뒤 해당 객체의 메시지에 맞춰 대응합니다. 하나의 제출에 여러 상품을 묶었다면 모든 상품이 같은 이유로 거절되었다고 가정하지 않는 것이 안전합니다.
계정 역할도 확인해야 합니다. 제출 권한은 팀의 역할과 계약 상태에 영향을 받을 수 있으므로 계정 역할별 권한 안내를 기준으로 운영 계정과 개발 계정을 나눕니다.
반복 가능한 출시 절차로 고정하기
한 번의 성공보다 다음 상품을 같은 방식으로 제출할 수 있는지가 중요합니다. 상품 유형 등록표에는 다음 정보를 남깁니다.
- 상품 유형과 Product ID
- 첫 승인 상품인지 후속 상품인지
- 연결된 앱 버전
- Subscription Group 연결 여부
- 심사 스크린샷과 검토 메모의 저장 위치
- 거절 메시지와 수정 내역
- 빌드 번호와 업로드 로그 위치
처음부터 자동화를 크게 만들 필요는 없습니다. 먼저 실제 후속 상품 하나를 독립 제출하면서 자격 판정, 상품 자료 확인, Add for Review 초안 생성, 상태 추적, 거절 후 재제출을 기록합니다. 이 과정에서 빌드 업로드와 심사 제출을 서로 다른 담당 절차로 나누면 개발 계정이 배포용 비밀 정보에 불필요하게 접근하는 문제도 줄일 수 있습니다.
현재 방식이 개인 맥 한 대에 의존한다면 전원 종료, 저장 공간 부족, 인증서 만료, 원격 접속 단절이 동시에 출시를 막을 수 있습니다. 반대로 원격 맥은 상시 실행 환경과 복구 가능한 세션을 확보하기 쉽지만, 네트워크 지연과 계정 보안 설정을 별도로 관리해야 합니다. 다음 인앱 결제 출시에서 빌드, 서명, 업로드, 심사 초안까지 실제로 재현할 환경이 필요하다면 RUVCLOUD의 맥 이용 요금과 기간 선택을 비교해 보는 편이 합리적입니다.
App Store Connect 인앱 결제 제출의 핵심은 테스트 구매 성공이 아니라 첫 상품인지 후속 상품인지에 맞춰 심사 객체를 구성하는 것입니다. 현재 방식은 단일 개인 맥에 종속되고, 빌드 처리 확인과 심사 상태 추적이 분리되며, 연결이 끊기면 업로드 기록을 다시 찾기 어렵다는 단점이 있습니다. 안정적으로 Xcode를 실행할 상시 맥이 없고 다음 출시에서 원격 복구까지 검증하려는 경우라면, 구매 전에 필요한 기간과 접근 방식을 비교한 뒤 RUVCLOUD의 원격 맥 환경을 시험하는 선택이 더 현실적일 수 있습니다.