사이드 프로젝트로 앱을 만들고, 마침내 스토어에 제출합니다. 그리고 며칠 뒤, 메일 한 통이 옵니다. "Your app has been rejected."
2024년 Apple은 7,771,599건의 앱 제출 중 1,931,400건을 거절했습니다. 거절률 약 25%. 네 번에 한 번은 떨어지는 셈이에요. Google Play도 같은 해에 236만 개의 앱을 차단했습니다. 첫 제출은 40%라고도 합니다.
그런데 흥미로운 점이 있어요. 거절 사유의 대부분은 코드 품질이 아닙니다. 서류 누락, 설정 실수, 메타데이터 오류 — 미리 확인만 했으면 피할 수 있는 것들이에요.
사이드 프로젝트는 특히 취약합니다. 회사 앱은 QA팀이 체크리스트를 돌리지만, 사이드 프로젝트는 개발자 혼자 코드도 짜고, 디자인도 하고, 제출도 합니다. "일단 올려보자"는 마인드가 거절의 시작이에요.
이 글에서는 제출 전에 확인해야 할 항목을 정리합니다. 이 체크리스트만 훑으면, 거절 없이 한 번에 통과할 수 있어요.
전체 거절률
25%
4건 중 1건 거절
첫 제출 거절률
~40%
10명 중 4명이 첫 번에 떨어짐
Apple 심사 거절 1위는 Performance (Guideline 2.1 App Completeness) 입니다. 2024년에만 1,235,471건이 이 카테고리에서 거절됐어요. 앱이 크래시하거나, 기능이 미완성이거나, 백엔드가 응답하지 않으면 여기에 걸립니다.
개발 중에는 DEBUG 모드로 돌립니다. 에러가 나면 친절하게 로그가 뜨고, 핫 리로드도 되죠. 그런데 RELEASE 빌드는 다른 세계입니다. 컴파일러 최적화가 달라지고, 일부 서드파티 라이브러리는 DEBUG에서만 동작하는 코드 경로가 있어요.
실제로 React Native 앱에서 DEBUG에서는 멀쩡하던 앱이 TestFlight에서 크래시하는 케이스가 반복적으로 보고됩니다. Xcode에서 Archive한 빌드를 실제 기기에 설치하고, 최소 2~3대의 디바이스에서 주요 플로우를 돌려보세요.
심사관은 제출 후 24시간~7일 사이 아무 때나 앱을 열어봅니다. 이때 백엔드가 죽어있으면 기능 미작동으로 거절이에요.
사이드 프로젝트에서 흔한 함정은 무료 호스팅의 sleep 모드입니다. Render, Railway 같은 서비스의 무료 티어는 트래픽이 없으면 인스턴스가 꺼져요. 심사관이 앱을 열었을 때 첫 요청에서 30초 이상 걸리거나, 아예 타임아웃이 나면 거절됩니다.
"Coming Soon", Lorem ipsum, 빈 화면, 작동하지 않는 버튼 — 이런 게 하나라도 있으면 2.1 App Completeness 위반입니다. 개발 중에 만들어둔 더미 화면이나 테스트 페이지가 빌드에 남아있지 않은지 확인하세요.
로그인이 필요한 앱인데 데모 계정이 없으면 즉시 거절됩니다. 심사관은 회원가입을 직접 하지 않아요.
App Store Connect의 "Notes for Review" 필드에 테스트 계정 정보를 입력하세요. 프리미엄 기능이 있다면, 프리미엄이 활성화된 계정을 제공해야 합니다. 역할이 여러 개면(관리자, 일반 사용자) 각 역할별 계정을 모두 준비하세요.
DEBUG 빌드
친절한 에러 로그
크래시 시 상세 스택 트레이스 출력
핫 리로드
저장 즉시 변경 내용 반영
느슨한 최적화
일부 SDK의 동작이 다를 수 있음
⚠ 개발자만 보는 빌드
RELEASE 빌드
컴파일러 최적화
코드 경로가 달라져 버그가 드러남
일부 SDK 동작 변경
DEBUG 전용 코드 경로 비활성화
심사관이 보는 빌드
TestFlight / 내부 트랙에서 배포
✓ Archive 후 실기기에서 반드시 테스트
Apple 심사 거절 2위는 Legal (Guideline 5.1.1) 입니다. 445,696건이 법적 요건 미충족으로 거절됐어요. 대부분은 개인정보 처리방침 관련입니다.
개인정보 처리방침은 세 곳에 모두 있어야 합니다.
"우리 앱은 데이터를 수집하지 않으니 필요 없다"고 생각하기 쉬운데, 그렇지 않습니다. Firebase Analytics, Crashlytics, AdMob 같은 SDK를 하나라도 쓰고 있다면 데이터가 수집되고 있어요.
여기가 사이드 프로젝트 개발자가 가장 많이 놓치는 부분입니다.
Firebase를 쓰면 디바이스 ID가 수집됩니다. Crashlytics를 쓰면 크래시 로그와 기기 정보가 수집됩니다. AdMob을 쓰면 광고 ID가 수집됩니다. 이 모든 걸 개인정보 처리방침에 명시하고, 스토어 양식에 신고해야 합니다.
Apple은 Privacy Nutrition Labels에서, Google은 Data Safety 섹션에서 이를 요구해요. 자동화된 시스템이 앱 바이너리를 분석해서 실제 SDK 동작과 신고 내용이 일치하는지 교차 검증합니다. 불일치가 발견되면 거절이에요.
2024년 5월부터 Apple은 PrivacyInfo.xcprivacy 파일을 요구합니다. 앱과 모든 서드파티 SDK에 Privacy Manifest가 포함되어야 해요. Xcode에서 빌드하면 자동으로 Privacy Report를 생성하는데, 여기서 누락된 SDK가 있으면 제출 자체가 차단됩니다.
계정 생성을 허용하는 앱은 계정 삭제 기능을 반드시 제공해야 합니다. Apple은 2022년부터 이를 강제하고 있는데, 여전히 많은 사이드 프로젝트 앱이 이걸 빠뜨려요.
설정 화면에서 "계정 삭제" 버튼을 누르면 실제로 서버에서 데이터가 삭제되는 플로우가 필요합니다. "이메일로 문의해주세요"는 안 됩니다.
개인정보 처리방침 — 3곳 모두 등록 필수
스토어 메타데이터
App Store Connect /
Play Console에 URL 입력
개인정보 처리방침
HTTPS · 로그인 없이
공개 접근 가능
앱 내 설정
설정 화면에서
한 탭으로 접근
셋 중 하나라도 빠지면 거절 — SDK 하나만 써도 수집 근거 필요
Apple 심사 거절 3위는 Design (Guideline 2.3 Accurate Metadata) 입니다. 스크린샷, 설명, 키워드에서 걸리는 경우가 많아요.
스크린샷 관련 거절 중 1위는 스플래시 화면만 캡처한 경우입니다. 앱이 실제로 사용되는 모습을 보여줘야 해요. 디바이스 프레임이나 마케팅 텍스트를 입히는 건 괜찮지만, 그 안의 UI는 실제 앱 캡처여야 합니다.
양쪽 스토어 모두 앱 이름에 "Best", "#1", "Free", "New" 같은 프로모션 용어를 금지합니다. Google Play는 추가로 전체 대문자(ALL CAPS)와 이모지도 금지해요.
설명에서 다른 플랫폼을 언급하는 것도 거절 사유입니다. iOS 앱 설명에 "Android보다 낫다"는 말은 물론, "Android 버전도 있습니다" 같은 중립적 문구도 피하세요.
소셜 기능이나 사용자 생성 콘텐츠(UGC)가 있는 앱은 4+ 등급을 받을 수 없습니다. UGC가 있으면 콘텐츠 필터링, 신고 기능, 차단 기능도 함께 구현되어 있어야 해요 (Guideline 1.2).
연령 등급을 낮게 설정해서 더 많은 사용자에게 노출하려는 시도는 발각되면 앱이 아예 제거됩니다.
소셜 로그인(Google, Facebook, Kakao 등)을 하나라도 제공하면, Sign in with Apple도 반드시 제공해야 합니다 (Guideline 4.8). 없으면 즉시 거절이에요. 이건 예외가 없습니다.
WebView로 웹사이트를 감싸기만 한 앱은 거절됩니다. Safari로 충분한 것을 굳이 앱으로 만들 이유가 없다는 게 Apple의 입장이에요.
통과하려면 네이티브 기능이 최소 하나 이상 있어야 합니다. 푸시 알림, 오프라인 지원, 생체 인증, 네이티브 공유 시트 등. Capacitor나 Ionic으로 만든 앱이라면 특히 주의하세요.
심사관은 첫 번째 화면만 보고 판단하는 경향이 있어요. Review Notes에 네이티브 기능의 위치와 접근 경로를 명시적으로 안내하세요.
앱 내에서 디지털 콘텐츠를 판매하거나, 프리미엄 기능을 잠금 해제하거나, 광고를 제거하는 경우 반드시 Apple IAP를 사용해야 합니다 (Guideline 3.1.1). Stripe 같은 외부 결제를 쓰면 거절이에요.
예외는 물리적 상품 배송(쇼핑몰), 실시간 1:1 서비스(과외, 의료 상담), 이미 다른 플랫폼에서 구매한 콘텐츠 열람(Netflix형 리더 앱) 정도입니다.
카메라, 위치, 마이크 등의 권한을 요청할 때 Info.plist의 Usage Description이 구체적이어야 합니다. "We need your location"처럼 모호한 문구는 거절됩니다.
"프로필 사진 촬영을 위해 카메라에 접근합니다", "주변 매장 검색을 위해 위치 정보를 사용합니다"처럼 왜 필요한지를 명확하게 써야 해요.
플랫폼별 핵심 요건 비교
App Store
로그인
Sign in with Apple 필수
소셜 로그인 1개라도 있으면 예외 없음
결제
Apple IAP 강제
디지털 콘텐츠·기능은 외부 결제 불가
개인정보
Privacy Manifest 필수
PrivacyInfo.xcprivacy — 2024년 5월~
심사 기간
24 ~ 48시간
주말·공휴일 포함, 최대 7일
Google Play
테스트
12명 × 14일 필수
2023.11 이후 신규 개인 계정 대상
API 레벨
API Level 35 이상
2025년 8월 31일부터 강제
빌드 포맷
AAB 필수 (APK 불가)
Play App Signing 등록 필요
자동 검사
Pre-launch Report
Firebase Test Lab 자동 크래시 탐지
2023년 11월 이후에 생성된 개인 계정은 프로덕션 출시 전에 12명의 테스터가 14일 연속으로 앱을 사용해야 합니다. 이 조건을 충족해야 프로덕션 접근 신청이 가능해요.
출시 예정일에서 최소 4~5주 전에 클로즈드 테스트를 시작해야 합니다. 이걸 모르고 출시 당일에 제출하면 아무것도 할 수 없어요.
조직(Organization) 계정이나 2023년 11월 이전에 생성된 개인 계정은 이 요건이 면제됩니다.
2025년 8월 31일부터 새 앱과 업데이트는 Android 15 (API Level 35) 이상을 타겟해야 합니다. 미충족 시 제출이 거부되고, 기존 앱도 API 34 이상이 아니면 최신 기기에서 검색이 안 돼요.
Google Play는 2021년부터 새 앱을 AAB (Android App Bundle) 포맷으로만 받습니다. APK는 안 됩니다. AAB를 사용하려면 Play App Signing에 등록해야 하고, 업로드 키와 앱 서명 키가 분리됩니다.
흔한 실수는 앱 서명 키로 AAB에 서명하는 것입니다. 업로드 키로 서명해야 해요.
AAB를 업로드하면 Google이 자동으로 Firebase Test Lab 기기에서 앱을 돌려봅니다. 여기서 발견된 크래시는 심사 전에 확인할 수 있어요. Play Console의 Pre-launch Report 탭에서 결과를 반드시 확인하세요.
심사를 한 번에 통과하는 사람들이 코드를 더 잘 짜는 건 아닙니다. 제출 버튼을 누르기 전에 한 번 더 확인하는 사람들이에요.
거절 사유의 대부분은 "몰라서" 빠뜨린 항목입니다. 개인정보 처리방침 URL을 안 넣었거나, 데모 계정을 안 만들었거나, RELEASE 빌드를 안 돌려봤거나. 한 번만 알면 다시는 놓치지 않을 것들이에요.
아래는 이 글의 모든 체크리스트를 한 페이지로 요약한 표입니다. 제출 전에 한 번 훑어보세요.
제출 전 최종 점검
앱 심사 원패스 체크리스트
앱 완성도
4RELEASE 빌드 실기기 2대 이상 테스트
프로덕션 서버 sleep 방지 조치 완료
placeholder · 미완성 화면 전체 제거
데모 계정 + 탐색 경로 Review Notes 기재
개인정보
4처리방침 3곳 등록 (스토어·앱·웹)
SDK 수집 데이터 전량 신고
Apple Privacy Manifest 추가
계정 삭제 기능 앱 내 구현
메타데이터
3스크린샷 — 실제 앱 화면 · 필수 사이즈 제출
앱 이름 30자 이내 · 프로모션 표현 없음
연령 등급 정직 작성 · UGC 필터링 구현
Apple 전용
4Sign in with Apple 구현 완료
WebView만이 아닌 네이티브 기능 1개 이상
디지털 판매 시 Apple IAP 사용
권한 Usage Description 구체적 용도 명시
Google Play 전용
412명 × 14일 클로즈드 테스트 완료
targetSdkVersion 35 이상
AAB 포맷 빌드 · Play App Signing
Pre-launch Report 크래시 0건
이 체크리스트를 제출 전에 한 번 훑으면, 거절 없이 한 번에 통과할 수 있습니다.
다음 글에서는 거절당했을 때 복구하는 방법 — Apple Resolution Center 활용법, Google Play에서 절대 하면 안 되는 실수, Expedited Review 요청 방법을 다룰게요.
