앱스토어 심사 거절은 App Review가 보내는 메시지로, 가이드라인을 인용하고 심사자가 확인한 내용을 설명하며, 여러분이 문제를 수정하거나 해명하거나 이의를 제기할 때까지 출시를 보류합니다. 먼저 이 메시지를 테스트 가능한 문제로 바꾸는 것부터 시작하세요. 다음 단계는 심사자가 앱을 사용하지 못했는지, 정책 불일치를 발견했는지, 아니면 추가 정보가 필요한지에 따라 달라집니다. 2026년 10월 기준 App Review 가이드라인의 최종 업데이트일은 2026년 10월 16일이므로, 특정 조항을 인용하기 전에 현재 번호 체계를 확인하세요.
앱스토어 거절 메시지는 실제로 무엇을 알려 주나요?
앱스토어 거절 메시지에는 심사자가 적용한 가이드라인, 심사자가 확인한 구체적인 동작, 그리고 다음 단계가 담겨 있습니다. 기기, iOS 버전, 스크린샷이 포함되는 경우도 많습니다.
메시지 전문, 스크린샷, 빌드 번호, 기기 정보를 모두 저장하세요. 가이드라인 웹페이지에서 인용된 조항을 읽어 보세요. 그런 다음 "심사자는 Y 때문에 X를 완료할 수 없었다"라는 한 문장으로 정리하세요. 메시지가 결함을 지적하는 것이 아니라 누락된 정보를 요청하는 것이라면, 정확히 무엇이 빠졌는지 적어 두세요. Apple의 2.1 표준 문구는 문제를 재현하는 방법도 알려 줍니다. "신규 앱의 경우, 기기에서 앱의 이전 버전을 모두 삭제한 다음 앱을 설치하고 단계에 따라 문제를 재현하세요."
- 메시지가 크래시, 접근할 수 없는 화면, 미완성 기능을 언급하나요? 제출한 릴리스 빌드에서, Apple이 명시한 기기 유형으로 해당 흐름을 재현하세요.
- 스크린샷, 앱 설명, 심사 메모를 언급하나요? 메타데이터 수정만으로 해결할 수 있는지 확인하세요.
- 결제, 로그인, 개인정보 보호, 최소 기능을 언급하나요? 제품 동작을 인용된 가이드라인과 비교하세요.
앱스토어 거절에서 자주 인용되는 가이드라인과 요구 사항은 무엇인가요?
각 가이드라인은 구체적인 요구 사항을 정하고 있으므로, 인용된 번호를 해당 문구와 대조하고 그 문구를 기준으로 테스트하세요. 아래 표는 거절 메시지에서 자주 인용되는 가이드라인의 현재 문구를 정리한 것입니다.
| 가이드라인 | Apple 문구의 요구 사항 | 재제출 전 확인할 사항 |
|---|---|---|
| 2.1(a) 앱 완성도 | "완전히 작동하는 URL"을 갖춘 최종 버전, 데모 계정 정보 "(그리고 백엔드 서비스를 켜 두세요!)" | 크래시, 플레이스홀더 콘텐츠, iPhone과 iPad에서의 로그인, 작동 중인 백엔드 |
| 2.1(b) 앱 내 구입 | 구입 항목은 "완전하고 최신 상태이며 심사자에게 보이고 작동해야" 함 | 상품이 제출되어 있고 접근 가능한지, 찾을 수 없는 항목이 있다면 그 이유를 심사 메모에 설명했는지 |
| 2.3 정확한 메타데이터 | 메타데이터는 "앱의 핵심 경험을 정확하게 반영"해야 함 | 스크린샷이 실제 사용 중인 앱을 보여 주는지, 앱 설명이 이번 빌드와 일치하는지 |
| 4.2 최소 기능 | "재포장된 웹사이트 이상의 가치를 제공하는 기능, 콘텐츠, UI" | 네이티브 워크플로가 있는지, 주로 웹 클리핑이나 링크로만 구성된 앱이 아닌지(4.2.2) |
| 3.1.1 앱 내 구입 | 기능을 잠금 해제하려면 "반드시 앱 내 구입을 사용해야" 함 | 라이선스 키, QR 코드 등 다른 잠금 해제 수단이 없는지, 스토어프런트별 자격(entitlement)이 갖춰져 있는지 |
| 5.1.1(v) 계정 로그인 | "앱에서 계정 생성을 지원한다면 앱 내에서 계정 삭제도 제공해야 합니다." | 앱 안에서 접근할 수 있는 계정 삭제 흐름 |
2026년 10월 16일 업데이트에서는 숨겨진 기능, 휴면 기능, 문서화되지 않은 기능을 다루는 2.5.19가 추가되었습니다. 이 내용은 이전에 2.3.1에서 다뤘습니다. 또한 크리에이티브 에셋에 관한 2.3.14가 추가되었고, Music Streaming Services 자격은 3.1.1(a)의 StoreKit External Purchase Link 자격으로 통합되었습니다. 이 표는 출발점으로 활용하되 확실한 해결책으로 여기지는 마세요. 하나의 가이드라인이 여러 문제를 포괄할 수 있으며, 여러분이 해결해야 하는 구체적인 사례는 심사자가 제시한 예시입니다.
4.2 최소 기능 거절은 어떻게 해결하나요?
4.2 거절은 앱 설명 문구를 바꾸는 것이 아니라 실질적인 앱 가치를 더해서 해결해야 합니다. 가이드라인 4.2는 이렇게 말합니다. "앱이 특별히 유용하거나, 독창적이거나, '앱다운' 앱이 아니라면 App Store에 적합하지 않습니다."
사용자가 여러분의 앱에서 무엇을 할 수 있기에 앱으로서 유용한지 스스로 물어보세요. 워크플로를 완료하거나, 의미 있는 상태를 저장하거나, 앱에 맞는 방식으로 기기 기능을 활용하거나, 기기에 맞게 만들어진 모바일 경험을 누릴 수 있어야 합니다. 승인을 보장하는 공개된 기능 목록은 없습니다. 이런 워크플로가 이미 있다면 정확한 단계와 스크린샷을 곁들여 심사 메모에 적으세요. 앱이 대부분 웹 페이지를 보여 주는 수준이라면 제품 자체를 개선해야 합니다. 네이티브처럼 보이게 하려고 알림이나 빈 설정 화면을 추가하는 것은 사용자에게 주는 실질적인 가치를 대신하지 못합니다.
App Store Connect에서 App Review에 어떻게 회신하나요?
App Store Connect에서 회신하세요. 앱의 미해결 문제 링크에서 제출 항목을 열고 Resolve를 클릭한 다음 Reply to App Review를 클릭하면 됩니다. Apple 도움말 페이지에 따르면 이 작업에는 Account Holder, Admin 또는 App Manager 역할이 필요합니다.
- Apps에서 앱을 선택합니다.
- 페이지 상단에서 미해결 문제가 있음을 알리는 링크를 클릭합니다.
- In Progress 섹션에서 해당 제출 항목 옆의 Resolve를 클릭합니다.
- Reply to App Review를 클릭하고 내용을 입력합니다.
- 스크린샷이나 문서를 첨부하려면 Attach File을 클릭한 다음 Reply를 클릭합니다.
Apple은 "App Review에 다시 제출하기 전까지" 메시지를 주고받고 파일을 첨부할 수 있다고 안내하므로, 재제출하기 전에 근거 자료를 보내세요. 회신은 짧고 사실 위주로 작성하세요. 무엇이 바뀌었는지, 어디에 있는지, 어떻게 확인할 수 있는지를 밝히면 됩니다. 비슷한 기능을 하는 것처럼 보이는 다른 앱을 근거로 논쟁하지 마세요.
메타데이터를 수정할까요, 새 빌드를 올릴까요, 이의를 제기할까요?
등록 정보만 잘못된 경우에는 메타데이터를 수정하고 같은 빌드를 다시 제출하세요. 앱 동작을 바꿔야 한다면 새 빌드를 업로드하세요. 앱이 이미 가이드라인을 준수한다고 판단될 때만 이의를 제기하세요.
| 선택지 | 적합한 상황 | Apple의 안내 |
|---|---|---|
| 메타데이터 수정 | 스크린샷, 앱 설명, 개인정보 정보 또는 심사 메모가 잘못된 경우 | "메타데이터 문제로 앱이 거절된 경우, 문제를 해결한 후 같은 빌드를 다시 제출할 수 있습니다." |
| 새 빌드 | 크래시, 로그인, 권한, 결제 흐름에 코드 변경이 필요한 경우 | 빌드 번호를 올리고, 수정한 흐름을 그대로 먼저 테스트 |
| 이의 제기 | 결정이 가이드라인을 잘못 적용했다고 판단되는 경우 | 먼저 회신한 뒤, 지적된 모든 위반 사항을 다루는 "거절 또는 삭제된 앱 하나당 이의 제기 한 건"을 제출 |
Apple의 이의 제기 안내는 앱이 가이드라인을 "어떻게 충족하는지 항목별로 설명"하라고 요청합니다. 또한 이미 문제를 수정해 재제출했다면 이의를 제기하지 말라고 안내합니다. 이의 제기를 빠짐없이 작성하더라도 결정이 번복된다는 "보장은 없습니다". 이미 스토어에 출시된 앱의 경우, 가이드라인의 버그 수정 제출(Bug Fix Submissions) 정책에 따라 "법률 또는 안전 문제와 관련된 경우를 제외하고" 가이드라인 위반을 이유로 버그 수정이 지연되지 않습니다.
다른 개발자들은 실제 앱스토어 거절을 어떻게 해결했나요?
공개 포럼 스레드를 보면 2.1 거절의 상당수는 심사자 환경과 개발자 환경의 차이, 즉 네트워크, 기기, 권한 상태의 차이에서 비롯되었습니다. 4.2 거절은 제품 자체의 문제라서 작은 수정으로는 좀처럼 통과하지 못합니다.
2.1 로그인 오류. Apple Developer Forums의 한 개발자는 라이브 버전과 TestFlight 버전 모두 같은 자격 증명으로 로그인되는데도 "구체적으로, 오류로 인해 로그인할 수 없었습니다"라는 메시지를 받았다고 전했습니다. 같은 스레드의 다른 개발자들은 각기 다른 해결 방법을 공유했습니다. 한 개발자는 "웹 서버의 http를 https로 변경"해서 해결했습니다. 다른 개발자는 세 번 거절당한 뒤 끝없이 돌아가는 로딩 표시 대신 "Check your connection"(연결 상태를 확인하세요) 상태를 추가했습니다. 세 번째 개발자는 다섯 번 거절당한 뒤 배포 대상에서 iPad를 제외했는데, 이는 iPad 지원을 포기하는 방식으로 문제를 우회한 것입니다.
실행 시 크래시. Solar2D 포럼의 한 개발자는 iOS 18.3.2를 실행하는 iPhone 13 mini에서 "앱이 실행 시 크래시되어 심사할 수 없었습니다"라는 통보를 받았습니다. 첨부된 크래시 로그를 보니 NSUserTrackingUsageDescription 키가 누락되어 있었습니다. 이 개발자는 "NSUserTrackingUsageDescription을 추가한 후 통과했습니다"라고 확인했습니다.
4.2 WebView 앱. Apple Developer Forums의 한 개발자는 WebView 기반 앱이 10번째로 거절되었다고 밝혔습니다. 심사자는 왼쪽 메뉴의 스크린샷을 보내며 콘텐츠가 부족하다고 지적했습니다. 주요 화면은 이미 네이티브로 바뀌었지만 두세 개 화면은 여전히 WebView를 열었습니다. 답변으로 채택된 회신은 App Review가 작성한 것으로, 일대일 App Review 상담을 권했습니다. 스레드에서 승인 여부는 확인되지 않습니다.
비교해 보면, 2.1 사례는 심사자의 조건을 재현하고 크래시 로그를 읽어서 해결되었습니다. 반면 4.2 사례는 재제출할 때마다 여전히 대부분 웹사이트인 앱의 일부만 바꿨기 때문에 진전이 없었습니다.
같은 거절이 반복되지 않게 하려면 어떻게 해야 하나요?
해결한 문제를 하나씩 릴리스 체크리스트 항목으로 만들고, 제출할 때마다 릴리스 빌드에서 다시 테스트하세요. Apple 가이드라인은 같은 가이드라인 위반으로 앱이 반복해서 거절되면 심사가 "더 오래 걸릴 것"이라고 경고합니다.
- 앱을 삭제한 다음 실제 iPhone과 iPad에 릴리스 빌드를 새로 설치하세요.
- 개발 서버나 HTTP 예외가 없는 네트워크에서 심사용 계정으로 로그인해 보세요.
- 모든 권한 요청 창을 열어 보고, Info.plist에 각 사용 목적 설명(usage description)이 있는지 확인하세요.
- 모든 앱 내 구입 항목이 제출되어 있고, 보이며, 심사 메모에 설명되어 있는지 확인하세요.
- 흐름이 바뀔 때마다 심사 메모를 업데이트하세요. 여섯 번 전 릴리스의 메모를 그대로 붙여 넣지 마세요.
2.1 문제라면 2.1 거절 대응용 릴리스 빌드 테스트 계획을 따르고 심사자용 데모 계정을 준비하세요. 그다음 제출 체크리스트로 다음 빌드를 점검하세요. 심사 메시지를 보고도 여전히 막막하다면 자세한 내용을 보내 주세요. 부족한 부분이 접근 권한인지, 메타데이터인지, 코드인지 함께 파악해 드립니다.
자주 묻는 질문
앱스토어 심사에서 거절된 후 같은 빌드를 다시 제출할 수 있나요?
네, 메타데이터만 문제였다면 가능합니다. Apple의 App Store Connect 도움말은 "메타데이터 문제로 앱이 거절된 경우, 문제를 해결한 후 같은 빌드를 다시 제출할 수 있습니다"라고 안내합니다. 스크린샷, 앱 설명, 개인정보 세부 정보 또는 심사 메모를 수정한 뒤 다시 제출하세요. 심사자가 크래시, 로그인 오류, 결제 문제를 발견했다면 코드를 변경해야 하므로 빌드 번호를 올린 새 빌드를 업로드하세요.
앱이 거절된 후 몇 번까지 다시 제출할 수 있나요?
App Review 가이드라인에는 재제출 횟수 제한이 없습니다. 다만 앱이 "같은 가이드라인 위반으로 반복해서 거절되면" 심사가 더 오래 걸린다고 경고합니다. 또한 가이드라인 4.3은 스팸성 제출을 반복하면 Apple Developer Program에서 제명될 수 있다고 명시합니다. 문제를 재현하고 수정 사항을 테스트한 후에만 다시 제출하세요.
앱스토어 심사 거절이 개발자 계정에 불이익을 주나요?
공개된 가이드라인에 따르면, 한 번 거절된 뒤 문제를 해결했다면 계정이 위험해지지 않습니다. 위험은 반복되는 패턴에서 생깁니다. 가이드라인 2.3.1(b)는 심각하거나 반복적인 오해의 소지가 있는 행위를 "Apple Developer Program에서 제명될 수 있는 사유"로 규정하며, 4.3(b)는 모방 앱의 반복 제출에 대해 경고합니다. 계정이 해지될 상황에서 가이드라인을 준수하고 있다고 판단되면, Apple의 절차에 따라 App Review Board에 이의를 제기할 수 있습니다.
App Review의 버그 수정 제출(Bug Fix Submission) 제안이란 무엇인가요?
이미 App Store에 출시되었거나 대체 배포로 제공되는 앱의 경우, Apple은 법률 또는 안전 문제와 관련된 경우가 아니라면 가이드라인 위반을 이유로 버그 수정을 지연하지 않습니다. 버그 수정 업데이트가 거절되었고 이 절차의 대상이라면, App Store Connect에서 App Review에 회신해 이 절차를 이용하고 싶으며 다음 제출에서 문제를 수정하겠다고 밝히세요. 이 경우에도 다음 제출 때는 반드시 문제를 수정해야 합니다.
이의를 제기해야 하나요, 아니면 앱을 수정해야 하나요?
심사자가 실제 결함이나 정책상 미비점을 발견했다면 앱을 수정하세요. 이의 제기는 앱이 이미 가이드라인을 준수한다고 판단될 때만 적합합니다. Apple은 먼저 거절 메시지에 회신하라고 요청합니다. 그다음 거절된 앱 하나당 이의 제기를 한 건 제출하고, 앱이 인용된 가이드라인을 어떻게 충족하는지 항목별로 설명하세요. 이미 문제를 수정해 재제출했다면 이의를 제기하지 마세요.
출처 & 더 읽을거리
정책은 바뀝니다. 제출 전에 공식 문서를 확인하세요.
- Apple: App Review 가이드라인 ↗2026년 10월 18일 확인
- Apple: App Review 메시지에 회신하기 ↗2026년 10월 18일 확인
- Apple: App Review Board에 이의 제기하기 ↗2026년 10월 18일 확인
- Apple Developer Forums: 앱 거절 - 가이드라인 2.1 - 성능(로그인 오류) ↗2026년 10월 18일 확인
- Solar2D 포럼: App Store Connect 거절, 가이드라인 2.1 실행 시 크래시 ↗2026년 10월 18일 확인
- Apple Developer Forums: 가이드라인 4.2 - 디자인 - 최소 기능 ↗2026년 10월 18일 확인
