App Store 리젝 가이드라인 2.1 앱 완성도: 재제출 전 릴리스 빌드 테스트 계획 (2026)

가이드라인 2.1 앱 완성도로 App Store 리젝을 받았다는 것은 심사자가 고객처럼 앱을 사용할 수 없었다는 뜻입니다. 앱이 크래시했거나, 플레이스홀더 콘텐츠를 보여줬거나, 로그인 화면에서 막혔거나, 인앱 구매가 숨겨져 있었을 수 있습니다. 해결책이 코드 한 줄인 경우는 드뭅니다. 재제출하기 전에 릴리스 빌드로 짧은 테스트 계획을 실행하세요. 새로 설치한 앱과 App Review에 제공하는 것과 똑같은 계정 정보를 사용해야 합니다. 이 글에서는 그 계획을 단계별로 설명하고, 다른 개발자들이 같은 리젝을 어떻게 해결했는지 보여드립니다.

App Store 가이드라인 2.1 앱 완성도는 무엇을 확인하나요?

가이드라인 2.1은 제출한 빌드가 완성되어 제대로 작동하는 앱인지 확인합니다. 완전한 메타데이터, 작동하는 링크, 데모 로그인, 라이브 백엔드, 그리고 심사자가 찾아서 사용할 수 있는 인앱 구매가 필요합니다.

Apple의 App Review 가이드라인은 2.1을 두 부분으로 나눕니다. 2.1(a)는 제출물이 "필요한 모든 메타데이터와 완전히 작동하는 URL이 포함된 최종 버전이어야 한다"고 하며, 플레이스홀더 텍스트와 빈 웹사이트는 제거해야 한다고 말합니다. 또한 기기에서 버그와 안정성을 테스트하고, "앱에 로그인이 있다면 데모 계정 정보를 포함하라(그리고 백엔드 서비스를 켜 두라!)"고 안내합니다. Apple은 "불완전한 앱 번들과, 크래시하거나 명백한 기술적 문제를 보이는 바이너리는 거절"합니다. 2.1(b)는 인앱 구매가 "완전하고, 최신 상태이며, 심사자에게 보이고, 작동해야 한다"고 말합니다. 설정한 구매 항목을 앱에서 찾을 수 없다면 심사 메모에 그 이유를 설명하세요.

이 리젝은 흔합니다. Apple의 App Review 준비하기 페이지에는 이렇게 적혀 있습니다: "평균적으로 해결되지 않은 이슈의 40% 이상이 가이드라인 2.1: 앱 완성도와 관련되어 있으며, 여기에는 크래시, 플레이스홀더 콘텐츠, 불완전한 정보 등이 포함됩니다."

왜 디버그 빌드 테스트로는 2.1 문제를 잡지 못하나요?

디버그 빌드는 심사자가 받는 사본과 같은 방식으로 실행되지 않습니다. 심사자는 배포용으로 서명된 릴리스 빌드를 저장된 세션도, 디버그 단축 경로도 없는 깨끗한 기기에 설치합니다.

여러분의 시뮬레이터는 이미 로그인되어 있습니다. 로컬 API는 절대 다운되지 않는 스테이징 서버를 가리키고 있을 수 있습니다. 디버그 플래그는 페이월을 건너뛰고, 기능 플래그는 기본값이 켜짐입니다. 심사자에게는 그런 것이 전혀 없습니다. Apple의 심사 페이지는 "최신 소프트웨어를 실행하는 기기에서 철저히 테스트하라"고도 요구하므로, 심사자는 여러분의 테스트 폰보다 새로운 iOS를 쓰고 있을 수 있습니다.

TestFlight는 심사자의 환경에 가장 가깝게 재현할 수 있는 방법입니다. TestFlight 개요에 따르면 App Store Connect 팀에서 최대 100명의 내부 테스터와 최대 10,000명의 외부 테스터를 추가할 수 있습니다. 하나의 빌드는 최대 90일 동안 테스트할 수 있습니다. 제출하려는 바로 그 빌드를 업로드하고, 이 앱을 한 번도 실행한 적 없는 기기에 TestFlight로 설치해 그 사본을 테스트하세요.

재제출 전 릴리스 빌드 테스트 계획에는 무엇이 포함되어야 하나요?

릴리스 빌드 테스트 계획은 처음 앱을 접하는 심사자가 막힐 수 있는 모든 지점을 점검합니다. 실행, 권한, 로그인, 백엔드, 콘텐츠, 링크, 구매, 네트워크 장애, iPad입니다. TestFlight 빌드에서 순서대로 단계를 실행하고, 심사 메모에 인용할 수 있도록 각 결과를 기록하세요.

1. 최신 iOS에서 깨끗하게 설치하기. 이전 사본을 모두 삭제하고, TestFlight에서 설치한 뒤 저장된 상태 없이 실행하세요. 콜드 런치를 세 번 하고 온보딩에서 크래시가 나지 않는지 확인하세요.
2. 모든 권한 요청을 한 번씩 거부하기. 알림, 위치, 카메라, 추적을 모두 거부하세요. 그래도 앱은 사용 가능한 화면에 도달해야 합니다. 또한 앱이나 SDK가 사용하는 모든 보호 리소스에 대해 Info.plist에 사용 목적 설명이 있는지 확인하세요.
3. 정확히 같은 데모 계정 정보로 로그인하기. 비밀번호 관리자가 아니라 App Store Connect에서 복사하세요. 계정에는 실제와 비슷한 데이터가 있어야 하고, 이메일 인증이 필요 없어야 하며, 여러분의 폰에 연결된 2단계 인증을 사용해서는 안 됩니다.
4. 백엔드가 프로덕션이고 라이브 상태인지 확인하기. 빌드는 프로덕션 엔드포인트를 가리켜야 합니다. 요청 제한(rate limit), IP 허용 목록, 지역 차단 때문에 심사자가 막혀서는 안 됩니다. 가이드라인 2.1(a)는 백엔드 서비스를 켜 두라고 안내합니다.
5. 모든 탭과 화면 둘러보기. lorem ipsum, "준비 중" 화면, 설명 없는 빈 상태, 테스트 이미지, 아무 동작도 하지 않는 버튼을 찾으세요.
6. 모든 링크 눌러보기. 개인정보 처리방침, 고객 지원, 이용약관, 모든 웹뷰가 포함됩니다. Apple은 "최신 연락처 정보가 있는 사용자 지원 링크와 개인정보 처리방침 링크는 모든 앱에 필수"라고 말합니다.
7. 모든 인앱 구매 열어보기. 새 계정으로 로그인하세요. 해당 버전과 함께 제출한 모든 상품이 가격과 함께 표시되는지, 샌드박스에서 구매할 수 있는지, 구매 복원(Restore Purchases)이 작동하는지 확인하세요.
8. 느리거나 끊긴 네트워크에서 테스트하기. 흐름 중간에 비행기 모드를 켜세요. 명확한 오류 메시지는 괜찮습니다. 끝없이 도는 스피너나 크래시는 안 됩니다.
9. 지원한다면 iPad 확인하기. 앱이 iPad에서 실행된다면 iPad에서 실행해 보고, 레이아웃 때문에 사용자가 갇히지 않는지 확인하세요.

3단계의 데모 계정은 다른 어떤 단계보다 반복 리젝을 많이 일으킵니다. 오래 유지되는 계정을 만드는 방법은 App Store 심사용 데모 계정 설정 가이드에서 다룹니다.

2.1 리젝 메시지를 어떻게 해결책과 연결하나요?

2.1 리젝을 해결책과 연결하려면 가이드라인 번호 다음에 나오는 문장을 읽으세요. 그 문장이 증상을 알려주고, 각 증상은 테스트 계획의 한 단계로 이어집니다.

습관 추적 앱이 "앱이 실행 시 크래시하여 심사할 수 없었습니다(We were unable to review the app because it crashed on launch)"라는 메시지와 함께 리젝되었다고 가정해 봅시다. 두 번째 메모에는 심사자가 인앱 구매를 찾을 수 없었다고 적혀 있습니다. 아래 표는 흔한 증상을 원인, 테스트, 해결책과 연결합니다.

어떤 리젝 메시지든 읽어내는 더 넓은 방법은 App Store 리젝: 가이드라인별 해결 방법을 참고하세요.

다른 개발자들의 2.1 리젝은 어떤 모습이었나요?

공개된 2.1 사례들은 같은 패턴을 따릅니다. 앱은 개발자의 환경에서는 작동하지만, 새로 설치하거나 다른 사람이 로그인해야만 드러나는 문제 때문에 심사자에게서는 실패합니다.

• 사용 목적 설명 누락으로 인한 크래시. Solar2D 포럼에서 한 개발자는 앱이 TestFlight에서는 실행되었는데도 iOS 18.3.2를 실행하는 iPhone 13 mini에서 "앱이 실행 시 크래시하여 심사할 수 없었습니다"라는 답변을 받았습니다. 다른 회원이 첨부된 크래시 로그에서 다음 내용을 찾아냈습니다: "이 앱은 사용 목적 설명 없이 개인정보 관련 데이터에 접근하려 했기 때문에 크래시했습니다." 개발자는 "NSUserTrackingUsageDescription을 추가한 후 통과했다"고 전했습니다.
• 심사자가 사용할 수 없었던 소셜 로그인. Apple Developer 포럼의 한 개발자는 심사자가 "소셜 로그인을 사용할 수 없었다"는 이유로 2.1 리젝을 반복해서 받았다고 밝혔습니다. Apple과 Google 데모 계정을 제공했지만, Apple ID 로그인에는 개발자의 폰으로 전송되는 인증 코드가 필요했습니다. Apple 직원은 App Review가 직접 연락할 것이라고 답했습니다. 공개된 해결책은 올라오지 않았습니다.
• 인앱 구매를 "제출된 바이너리에서 찾을 수 없음". RevenueCat 커뮤니티 스레드에서 한 개발자는 샌드박스 구매는 작동했는데도 월간 플랜을 바이너리에서 찾을 수 없다는 이유로 리젝되었습니다. 도움을 준 한 사용자는 페이월로 가는 모든 경로를 자세히 설명하고 스크린샷을 첨부해 답장하는 방식으로 비슷한 리젝이 해결되었다고 말했습니다. RevenueCat 직원은 제출한 모든 상품을 기본 페이월에 표시하고, StoreKit 테스트 파일을 Archive 스킴에서 제외하라고 조언했습니다.

세 사례 모두 개발자 자신의 테스트는 통과했습니다. 실패는 심사자의 출발점, 즉 2FA를 받을 폰도, 이전 세션도, 페이월 위치에 대한 지식도 없는 상태에서만 드러났습니다. 위의 테스트 계획이 재현하는 것이 바로 그 출발점입니다.

2.1 리젝 후 App Review 메모에는 무엇을 적어야 하나요?

2.1 리젝 후 심사 메모에는 작동하는 데모 계정 정보, 리젝된 빌드 이후 변경된 사항, 그리고 인앱 구매와 눈에 잘 띄지 않는 기능을 정확히 어디서 찾을 수 있는지를 적어야 합니다.

Apple의 심사 페이지는 계정 정보와 특수 설정을 App Review 정보 섹션에 넣으라고 안내합니다. 기능에 준비하기 어려운 하드웨어나 환경이 필요하다면 "데모 영상이나 하드웨어를 제공할 준비를 하라"고 합니다. 가이드라인 2.3.1(a)는 여기에 더해 새 기능은 심사 메모(Notes for Review)에 "구체적으로" 설명해야 하며 "일반적인 설명은 거절된다"고 말합니다. 짧고 구조화된 메모가 효과적입니다:

Demo account: review@example.com / (password)
Account is pre-verified, has no 2FA and has 30 days of sample data.

Fixes since last submission (2.1):
- Launch crash on fresh install fixed (tested build 42 on latest iOS, clean device).
- In-app purchases: Settings > Upgrade shows Monthly and Yearly.
- Backend is production and will stay live during review.

Non-obvious features:
- Widgets: long-press Home Screen > add "Streaks" widget.

법적 또는 보안상의 의무 때문에 데모 계정을 제공할 수 없다면, 가이드라인 2.1(a)는 앱 내장 데모 모드를 허용하지만 Apple의 사전 승인이 있을 때만 가능하며, 그 모드는 앱의 모든 기능을 보여줘야 합니다. 승인 없이 데모 모드로 전환하지 마세요.

2.1 리젝은 어떻게 재제출하거나 이의 제기하나요?

2.1 리젝 후 재제출하려면 테스트한 빌드를 업로드하거나 선택하고, App Store Connect에서 변경 사항을 App Review에 답장으로 알리고, 심사 메모를 업데이트한 뒤 다시 제출하세요. 이의 제기는 심사자가 앱을 오해했다고 판단될 때만 하세요.

1. App Store Connect에서 해당 버전에 연결된 빌드 번호가 테스트한 TestFlight 빌드와 일치하는지 확인하세요.
2. 리젝 메시지에 각 수정 사항을 짧게 요약해 답장하세요. 구매나 탐색 관련 문제라면 단계별 안내와 스크린샷을 추가하세요.
3. App Review 정보 섹션을 최신 계정 정보와 메모로 업데이트하세요.
4. 심사를 제출하세요. 2026년 10월 기준으로 Apple은 일반적으로 "제출 건의 최소 50%를 24시간 이내에, 90%를 48시간 이내에" 심사한다고 밝힙니다.

Apple이 잘못 판단했다고 생각한다면 App Review 페이지에서 App Review Board에 이의를 제기할 수 있습니다. 앱이 가이드라인을 준수하는 구체적인 이유를 제시하고, "심사를 통과하지 못한 제출 건당 이의 제기는 한 번만 하세요." 다만 2.1 리젝이라면 반박하는 것보다 깨끗한 기기에서 문제를 재현하는 편이 대개 더 빠릅니다. 재제출을 맡기고 싶다면 저희 App Store 제출 서비스가 두 스토어 모두의 심사 준비와 리젝 피드백 대응을 $599에 제공합니다(개발자 계정 비용은 별도).

2.1 문제는 이후 업데이트에서 자주 재발합니다. 새 기능 플래그, 교체된 API 키, 만료된 데모 계정 같은 것들입니다. 이 테스트 계획을 App Store 제출 체크리스트와 함께 릴리스 루틴에 추가하세요. 업데이트에서는 단계적 출시를 사용하면 놓친 버그가 영향을 미치는 사용자 수를 제한할 수 있습니다. 리젝된 빌드에 대해 다른 시각의 의견이 필요하다면 리젝 메시지와 함께 yagyeshsrbobde@gmail.com으로 이메일을 보내 주세요.