앱 심사 거절 없이 한 번에 통과하는 체크리스트

사이드 프로젝트로 앱을 만들고, 마침내 스토어에 제출합니다. 그리고 며칠 뒤, 메일 한 통이 옵니다. "Your app has been rejected."

2024년 Apple은 7,771,599건의 앱 제출 중 1,931,400건을 거절했습니다. 거절률 약 25%. 네 번에 한 번은 떨어지는 셈이에요. Google Play도 같은 해에 236만 개의 앱을 차단했습니다. 첫 제출은 40%라고도 합니다.

그런데 흥미로운 점이 있어요. 거절 사유의 대부분은 코드 품질이 아닙니다. 서류 누락, 설정 실수, 메타데이터 오류 — 미리 확인만 했으면 피할 수 있는 것들이에요.

사이드 프로젝트는 특히 취약합니다. 회사 앱은 QA팀이 체크리스트를 돌리지만, 사이드 프로젝트는 개발자 혼자 코드도 짜고, 디자인도 하고, 제출도 합니다. "일단 올려보자"는 마인드가 거절의 시작이에요.

이 글에서는 제출 전에 확인해야 할 항목을 정리합니다. 이 체크리스트만 훑으면, 거절 없이 한 번에 통과할 수 있어요.

앱 완성도 체크리스트

Apple 심사 거절 1위는 Performance (Guideline 2.1 App Completeness) 입니다. 2024년에만 1,235,471건이 이 카테고리에서 거절됐어요. 앱이 크래시하거나, 기능이 미완성이거나, 백엔드가 응답하지 않으면 여기에 걸립니다.

RELEASE 빌드를 실기기에서 테스트했는가

개발 중에는 DEBUG 모드로 돌립니다. 에러가 나면 친절하게 로그가 뜨고, 핫 리로드도 되죠. 그런데 RELEASE 빌드는 다른 세계입니다. 컴파일러 최적화가 달라지고, 일부 서드파티 라이브러리는 DEBUG에서만 동작하는 코드 경로가 있어요.

실제로 React Native 앱에서 DEBUG에서는 멀쩡하던 앱이 TestFlight에서 크래시하는 케이스가 반복적으로 보고됩니다. Xcode에서 Archive한 빌드를 실제 기기에 설치하고, 최소 2~3대의 디바이스에서 주요 플로우를 돌려보세요.

• Xcode Archive / Android Release APK로 실기기 테스트 완료
• 최소 2개 기기에서 주요 플로우 동작 확인
• 권한 거부 상태, 비행기 모드, 저속 네트워크에서도 크래시 없음

백엔드가 살아있는가

심사관은 제출 후 24시간~7일 사이 아무 때나 앱을 열어봅니다. 이때 백엔드가 죽어있으면 기능 미작동으로 거절이에요.

사이드 프로젝트에서 흔한 함정은 무료 호스팅의 sleep 모드입니다. Render, Railway 같은 서비스의 무료 티어는 트래픽이 없으면 인스턴스가 꺼져요. 심사관이 앱을 열었을 때 첫 요청에서 30초 이상 걸리거나, 아예 타임아웃이 나면 거절됩니다.

• 프로덕션 API 엔드포인트가 정상 응답하는지 확인
• 스테이징이 아닌 프로덕션 서버를 가리키고 있는지 확인
• 무료 호스팅 사용 시, 심사 기간 동안 sleep 방지 조치 완료

placeholder와 미완성 화면을 제거했는가

"Coming Soon", Lorem ipsum, 빈 화면, 작동하지 않는 버튼 — 이런 게 하나라도 있으면 2.1 App Completeness 위반입니다. 개발 중에 만들어둔 더미 화면이나 테스트 페이지가 빌드에 남아있지 않은지 확인하세요.

• 모든 화면에서 placeholder 텍스트 제거
• 모든 버튼과 네비게이션이 실제로 동작
• 앱 이름이나 설명에 "beta", "test", "demo" 포함되지 않음

리뷰어용 데모 계정을 준비했는가

로그인이 필요한 앱인데 데모 계정이 없으면 즉시 거절됩니다. 심사관은 회원가입을 직접 하지 않아요.

App Store Connect의 "Notes for Review" 필드에 테스트 계정 정보를 입력하세요. 프리미엄 기능이 있다면, 프리미엄이 활성화된 계정을 제공해야 합니다. 역할이 여러 개면(관리자, 일반 사용자) 각 역할별 계정을 모두 준비하세요.

• 데모 계정 정보를 Review Notes에 입력
• 프리미엄 기능이 활성화된 계정 제공
• "홈 탭 → 설정 → 구독 관리" 같은 기능별 탐색 경로 안내 포함

개인정보 & 법적 요건 체크리스트

Apple 심사 거절 2위는 Legal (Guideline 5.1.1) 입니다. 445,696건이 법적 요건 미충족으로 거절됐어요. 대부분은 개인정보 처리방침 관련입니다.

개인정보 처리방침이 3곳에 등록되어 있는가

개인정보 처리방침은 세 곳에 모두 있어야 합니다.

1. 스토어 메타데이터 — App Store Connect / Google Play Console에 URL 입력
2. 앱 내부 — 설정 화면에서 한 탭으로 접근 가능한 링크
3. 웹 — HTTPS로 접근 가능한 공개 URL (로그인 없이 열려야 함)

"우리 앱은 데이터를 수집하지 않으니 필요 없다"고 생각하기 쉬운데, 그렇지 않습니다. Firebase Analytics, Crashlytics, AdMob 같은 SDK를 하나라도 쓰고 있다면 데이터가 수집되고 있어요.

• HTTPS URL로 호스팅된 개인정보 처리방침 존재
• 스토어 메타데이터에 URL 입력 완료
• 앱 내 설정에서 한 탭으로 접근 가능

SDK가 수집하는 데이터까지 신고했는가

여기가 사이드 프로젝트 개발자가 가장 많이 놓치는 부분입니다.

Firebase를 쓰면 디바이스 ID가 수집됩니다. Crashlytics를 쓰면 크래시 로그와 기기 정보가 수집됩니다. AdMob을 쓰면 광고 ID가 수집됩니다. 이 모든 걸 개인정보 처리방침에 명시하고, 스토어 양식에 신고해야 합니다.

Apple은 Privacy Nutrition Labels에서, Google은 Data Safety 섹션에서 이를 요구해요. 자동화된 시스템이 앱 바이너리를 분석해서 실제 SDK 동작과 신고 내용이 일치하는지 교차 검증합니다. 불일치가 발견되면 거절이에요.

• 사용 중인 모든 SDK의 데이터 수집 항목 파악
• Apple Privacy Nutrition Labels 정확히 작성
• Google Data Safety 섹션 정확히 작성
• 개인정보 처리방침 본문에 SDK별 수집 데이터 명시

Apple Privacy Manifest를 추가했는가

2024년 5월부터 Apple은 PrivacyInfo.xcprivacy 파일을 요구합니다. 앱과 모든 서드파티 SDK에 Privacy Manifest가 포함되어야 해요. Xcode에서 빌드하면 자동으로 Privacy Report를 생성하는데, 여기서 누락된 SDK가 있으면 제출 자체가 차단됩니다.

• PrivacyInfo.xcprivacy 파일 추가
• Xcode Privacy Report에서 누락된 SDK 없음 확인

계정 삭제 기능이 있는가

계정 생성을 허용하는 앱은 계정 삭제 기능을 반드시 제공해야 합니다. Apple은 2022년부터 이를 강제하고 있는데, 여전히 많은 사이드 프로젝트 앱이 이걸 빠뜨려요.

설정 화면에서 "계정 삭제" 버튼을 누르면 실제로 서버에서 데이터가 삭제되는 플로우가 필요합니다. "이메일로 문의해주세요"는 안 됩니다.

• 앱 내에서 계정 삭제 가능 (웹이 아닌 앱 내)
• 삭제 시 서버 데이터 실제 삭제 처리

스토어 메타데이터 체크리스트

Apple 심사 거절 3위는 Design (Guideline 2.3 Accurate Metadata) 입니다. 스크린샷, 설명, 키워드에서 걸리는 경우가 많아요.

스크린샷이 실제 앱 화면인가

스크린샷 관련 거절 중 1위는 스플래시 화면만 캡처한 경우입니다. 앱이 실제로 사용되는 모습을 보여줘야 해요. 디바이스 프레임이나 마케팅 텍스트를 입히는 건 괜찮지만, 그 안의 UI는 실제 앱 캡처여야 합니다.

• 모든 스크린샷이 실제 앱 사용 화면
• 스크린샷에 표시된 기능이 현재 버전에 존재
• 필수 스크린샷 사이즈 모두 제출 (iPhone 6.9", 6.7", 5.5" 등)

앱 이름과 설명에 금지 표현이 없는가

양쪽 스토어 모두 앱 이름에 "Best", "#1", "Free", "New" 같은 프로모션 용어를 금지합니다. Google Play는 추가로 전체 대문자(ALL CAPS)와 이모지도 금지해요.

설명에서 다른 플랫폼을 언급하는 것도 거절 사유입니다. iOS 앱 설명에 "Android보다 낫다"는 말은 물론, "Android 버전도 있습니다" 같은 중립적 문구도 피하세요.

• 앱 이름 30자 이내, 프로모션 용어 없음
• 설명에 경쟁 플랫폼 언급 없음
• 키워드에 경쟁사 앱 이름이나 상표 미포함

연령 등급이 실제 콘텐츠와 맞는가

소셜 기능이나 사용자 생성 콘텐츠(UGC)가 있는 앱은 4+ 등급을 받을 수 없습니다. UGC가 있으면 콘텐츠 필터링, 신고 기능, 차단 기능도 함께 구현되어 있어야 해요 (Guideline 1.2).

연령 등급을 낮게 설정해서 더 많은 사용자에게 노출하려는 시도는 발각되면 앱이 아예 제거됩니다.

• 연령 등급 질문서를 정직하게 작성
• UGC 있는 경우: 신고, 차단, 필터링 기능 구현 확인

Apple 전용 체크리스트

Sign in with Apple

소셜 로그인(Google, Facebook, Kakao 등)을 하나라도 제공하면, Sign in with Apple도 반드시 제공해야 합니다 (Guideline 4.8). 없으면 즉시 거절이에요. 이건 예외가 없습니다.

• 소셜 로그인 사용 시 Sign in with Apple 구현 완료
• Sign in with Apple이 다른 로그인 옵션과 동등한 위치에 배치

Guideline 4.2 — 최소 기능 요건

WebView로 웹사이트를 감싸기만 한 앱은 거절됩니다. Safari로 충분한 것을 굳이 앱으로 만들 이유가 없다는 게 Apple의 입장이에요.

통과하려면 네이티브 기능이 최소 하나 이상 있어야 합니다. 푸시 알림, 오프라인 지원, 생체 인증, 네이티브 공유 시트 등. Capacitor나 Ionic으로 만든 앱이라면 특히 주의하세요.

심사관은 첫 번째 화면만 보고 판단하는 경향이 있어요. Review Notes에 네이티브 기능의 위치와 접근 경로를 명시적으로 안내하세요.

• WebView 래핑만으로 구성되지 않음
• 네이티브 기능 1개 이상 구현 (푸시, 오프라인, 생체 인증 등)
• Review Notes에 네이티브 기능 위치 안내

인앱 결제 (IAP)

앱 내에서 디지털 콘텐츠를 판매하거나, 프리미엄 기능을 잠금 해제하거나, 광고를 제거하는 경우 반드시 Apple IAP를 사용해야 합니다 (Guideline 3.1.1). Stripe 같은 외부 결제를 쓰면 거절이에요.

예외는 물리적 상품 배송(쇼핑몰), 실시간 1:1 서비스(과외, 의료 상담), 이미 다른 플랫폼에서 구매한 콘텐츠 열람(Netflix형 리더 앱) 정도입니다.

• 디지털 콘텐츠/기능 판매 시 Apple IAP 사용
• 구독 시 가격, 결제 주기, 해지 방법 명확히 표시

권한 요청 문구

카메라, 위치, 마이크 등의 권한을 요청할 때 Info.plist의 Usage Description이 구체적이어야 합니다. "We need your location"처럼 모호한 문구는 거절됩니다.

"프로필 사진 촬영을 위해 카메라에 접근합니다", "주변 매장 검색을 위해 위치 정보를 사용합니다"처럼 왜 필요한지를 명확하게 써야 해요.

• 모든 권한 요청의 Usage Description이 구체적 용도를 설명
• 핵심 기능과 무관한 불필요한 권한 요청 제거

Google Play 전용 체크리스트

클로즈드 테스트 요건

2023년 11월 이후에 생성된 개인 계정은 프로덕션 출시 전에 12명의 테스터가 14일 연속으로 앱을 사용해야 합니다. 이 조건을 충족해야 프로덕션 접근 신청이 가능해요.

출시 예정일에서 최소 4~5주 전에 클로즈드 테스트를 시작해야 합니다. 이걸 모르고 출시 당일에 제출하면 아무것도 할 수 없어요.

조직(Organization) 계정이나 2023년 11월 이전에 생성된 개인 계정은 이 요건이 면제됩니다.

• 계정 생성 시점 확인 (2023.11 이후면 테스트 필수)
• 12명 테스터 모집 + 14일 연속 사용 완료
• 출시 4~5주 전부터 테스트 시작

Target API Level

2025년 8월 31일부터 새 앱과 업데이트는 Android 15 (API Level 35) 이상을 타겟해야 합니다. 미충족 시 제출이 거부되고, 기존 앱도 API 34 이상이 아니면 최신 기기에서 검색이 안 돼요.

• targetSdkVersion이 35 이상
• Android 15에서 동작 테스트 완료

AAB 포맷 + Play App Signing

Google Play는 2021년부터 새 앱을 AAB (Android App Bundle) 포맷으로만 받습니다. APK는 안 됩니다. AAB를 사용하려면 Play App Signing에 등록해야 하고, 업로드 키와 앱 서명 키가 분리됩니다.

흔한 실수는 앱 서명 키로 AAB에 서명하는 것입니다. 업로드 키로 서명해야 해요.

• AAB 포맷으로 빌드
• Play App Signing 등록 완료
• 업로드 키로 서명 (앱 서명 키 아님)

Pre-launch Report

AAB를 업로드하면 Google이 자동으로 Firebase Test Lab 기기에서 앱을 돌려봅니다. 여기서 발견된 크래시는 심사 전에 확인할 수 있어요. Play Console의 Pre-launch Report 탭에서 결과를 반드시 확인하세요.

• Pre-launch Report에서 크래시 0건 확인
• ANR(Application Not Responding) 이슈 없음 확인

한 번에 통과하는 사람들의 공통점

심사를 한 번에 통과하는 사람들이 코드를 더 잘 짜는 건 아닙니다. 제출 버튼을 누르기 전에 한 번 더 확인하는 사람들이에요.

거절 사유의 대부분은 "몰라서" 빠뜨린 항목입니다. 개인정보 처리방침 URL을 안 넣었거나, 데모 계정을 안 만들었거나, RELEASE 빌드를 안 돌려봤거나. 한 번만 알면 다시는 놓치지 않을 것들이에요.

아래는 이 글의 모든 체크리스트를 한 페이지로 요약한 표입니다. 제출 전에 한 번 훑어보세요.

이 체크리스트를 제출 전에 한 번 훑으면, 거절 없이 한 번에 통과할 수 있습니다.

다음 글에서는 거절당했을 때 복구하는 방법 — Apple Resolution Center 활용법, Google Play에서 절대 하면 안 되는 실수, Expedited Review 요청 방법을 다룰게요.