Docs
전체 목차 cocode.im
문서 둘러보기
cocode.im 문서 허브

문서 검색

바로 가기

심사 거절 대응

심사나 인증에서 거절됐을 때 사유를 읽는 곳, 흔한 사유와 스토어별 공식 가이드라인 번호, 고쳐서 다시 제출하는 방법과 이의 제기를 한곳에 정리합니다. 정책 7.20 에서 바뀌는 연령 등급 · 사용자 생성 콘텐츠 요건도 담았습니다.

마지막 확인:
목차

심사나 인증에서 거절되면 먼저 사유를 읽고, 고치고, 다시 제출합니다. 이 페이지는 거절 안내를 읽는 곳, 흔한 사유와 스토어별 공식 가이드라인 번호, 다시 제출하고 이의를 제기하는 방법을 한곳에 모았습니다. 번호나 정책 이름을 알면 공식 문서에서 정확한 문구를 바로 찾을 수 있습니다.

주의

스토어 정책은 자주 바뀝니다. 이 페이지의 번호와 요건은 「마지막 확인」 날짜 기준이고, 다르면 각 스토어의 공식 문서가 우선합니다. 콘솔 화면은 로그인이 필요해 직접 확인하지 못했으므로, 메뉴와 버튼 이름 · 각 단계의 성공 판정(화면에 보이는 상태)은 공식 도움말의 설명을 따랐습니다. 이름은 한국어판 도움말에서 확인한 것을 「한글(영문)」으로 적었고, 확인하지 못한 이름은 영문으로 적었습니다. 한국어판 도움말은 번역이라 실제 화면과 다를 수 있습니다.

아래 번호는 Apple 의 App Review 지침(본문 표시 기준 2026-06-08 갱신), Google 의 개발자 프로그램 정책(2026-09-30 시행 표시), Microsoft Store 정책 7.20(2026-10-22 시행, 그 전까지는 7.19 적용)을 읽은 것입니다.

준비물

  • 거절 안내를 받은 곳에 들어갈 권한 — Apple 은 거절 메시지에 답하는 일을 Account Holder · Admin · App Manager 역할에 허용합니다. Microsoft 는 게시 상태 알림을 계정 소유자에게 이메일과 파트너 센터의 Action Center 로 보냅니다. Google 은 정책 상태를 Play Console 의 알림과 이메일로 알립니다.
  • 거절된 제출의 정보 — 올린 빌드 또는 패키지, 스토어 등록정보, 심사용 계정, 심사 메모입니다.
  • 문제를 다시 만들 기기 — 충돌이나 설치 실패가 사유라면 같은 환경에서 다시 재현해야 고쳤는지 알 수 있습니다.

거절 안내와 처리 방법 한눈에

(2026-10-09 확인)

항목 App Store · Mac App Store Google Play Microsoft Store
안내를 받는 곳 App Store Connect 앱 페이지 위쪽의 해결되지 않은 이슈 링크에서 「진행 중(In Progress)」 구역의 「해결(Resolve)」로 여는 App Review 화면입니다. 거절 메시지에 어긴 지침이 적힙니다 Play Console 의 「정책 상태(Policy status)」 페이지와 알림 · 이메일입니다. 조치 안내 이메일에 이의 제기 방법도 들어 있습니다 인증이 끝나면 받는 인증 보고서입니다. 어떤 시험이 실패했거나 어떤 정책을 지키지 못했는지 알려 줍니다
사유를 부르는 방식 지침 번호(2.1 · 4.3 · 5.1.1 …) 번호 대신 정책 이름(Metadata · Deceptive Behavior · Privacy Policy …). 일부 정책 안의 항목에만 1. 2. 번호가 있습니다 정책 번호(10.1.2 · 10.5.1 · 11.11 …)
고쳐서 다시 낼 때 빌드 문제는 고친 새 빌드를 올려 제출하고, 메타데이터나 서버 쪽 문제(심사용 계정 활성화 등)는 고친 뒤 재제출 없이 App Review 에 답합니다. 이의 제기 중에는 재제출하지 않습니다 고친 번들을 모든 트랙에 올리고 문제 있는 번들은 비활성화한 뒤 새 릴리스를 롤아웃합니다. 바꾼 내용은 「검토를 위해 전송」까지 눌러야 검토됩니다 문제를 고친 뒤 앱의 새 제출을 만들어 인증을 처음부터 다시 받습니다
해명 · 이의 제기 먼저 거절 메시지에 답해 해명하고, 해결되지 않으면 App Review Board 에 이의 제기를 합니다 조치 안내 이메일의 안내를 따릅니다. 조치 하나에 한 번이고, 답변은 중국어 · 영어 · 일본어 · 한국어로만 받을 수 있습니다 설명이나 도움이 필요하면 인증 보고서 메일에 회신하거나 앱 ID 와 함께 reportapp@microsoft.com 으로 문의합니다. 별도의 이의 제기 절차는 확인하지 못했습니다(정책 페이지의 「Certification Appeal Process」 절도 이 메일 주소로 문의하라고 안내할 뿐입니다). 연령 등급은 IARC 가 보내는 등급 증명 메일의 링크로 이의를 제기합니다

흔한 사유와 공식 번호

Apple 은 App Review 페이지에서 흔한 문제를 지침 번호와 함께 안내하며, 해결되지 않은 이슈의 평균 40% 이상이 지침 2.1(앱 완성도)과 관련된다고 밝힙니다. Google 은 정책 본문의 「흔한 위반 예(common violations)」로, Microsoft 는 「흔한 인증 실패(common certification failures)」 목록으로 사유를 안내합니다. 아래 표는 그 안내를 모아 사유별로 맞춘 것이고, 스토어가 사유의 순위를 밝힌 것은 아닙니다.

사유 App Store · Mac App Store Google Play Microsoft Store
충돌 · 미완성 · 자리표시자 · 깨진 링크 2.1(a) App Completeness — 제출물은 필요한 메타데이터와 동작하는 URL 을 갖춘 최종본이어야 하고 자리표시자 텍스트 · 빈 웹사이트는 없애고 기기에서 시험해야 합니다 「Functionality, Content, and User Experience」의 2. Broken Functionality — 충돌 · 강제 종료 · 멈춤, 설치되지 않거나 로드되지 않거나 응답하지 않는 앱 10.1.2(완전히 동작해야 함) · 10.4.2(빨리 시작하고 사용자 입력에 응답하며 예외를 처리해야 함)
로그인이 필요한데 심사용 계정이 없음 2.1(a) — 데모 계정 정보를 넣고 백엔드 서비스를 켜 둡니다. 법적 · 보안상 계정을 줄 수 없을 때만 Apple 의 사전 승인을 받아 데모 모드로 대신할 수 있습니다 앱 콘텐츠의 「Sign-in details」 — 언제나 쓸 수 있고 재사용할 수 있는 정보를 영어로 줍니다. 비밀번호가 만료되면 심사하지 못해 거절될 수 있습니다 10.3.1(「인증 참고 사항」에 작동하는 데모 계정) · 10.3.2(서버가 동작해야 함)
스토어 설명 · 스크린샷이 실제 앱과 다름 2.3 Accurate Metadata — 2.3.1(숨은 기능 금지 · 오해를 부르는 홍보 금지) · 2.3.3(스크린샷은 앱을 쓰는 모습을 보여야 함) 「Metadata」(오해를 부르거나 형식이 틀린 설명 · 제목 · 아이콘 · 스크린샷 금지, 앱 제목 30자 이하) · 「Deceptive Behavior」의 1. Misleading Claims 10.1 · 10.1.1(메타데이터가 기능을 정확히 설명해야 하고 이름은 유일해야 하며 이름에 마케팅 문구를 넣을 수 없음)
개인정보 처리방침 · 데이터 선언 5.1.1(i) — 방침 링크를 App Store Connect 와 앱 안 두 곳에 두어야 합니다. 5.1.2(i) — 개인정보를 제3자(제3자 AI 포함)와 공유하려면 명시적 허락을 받아야 합니다 「Privacy Policy」 · 「Data safety section」(User Data 정책 아래) — 방침 링크를 Play Console 과 앱 안에 둡니다 10.5.1 — 개인정보에 접근 · 수집 · 전송하면 방침을 유지하고 파트너 센터에 URL 을 입력합니다. Desktop Bridge · Win32 제품은 항상 방침이 있어야 합니다
계정을 만들 수 있는데 삭제 수단이 없음 5.1.1(v) — 계정 생성을 지원하면 앱 안에서 계정 삭제도 제공해야 합니다 「Account Deletion Requirement」 — 앱 안과 앱 밖(웹 링크를 Play Console 에 입력)에서 삭제를 요청할 수 있어야 합니다 앱 안의 계정 삭제를 일반 요건으로 정한 조항은 정책 본문에서 확인하지 못했습니다
기능이 부족한 앱 · 웹사이트를 감싼 앱 · 템플릿 · 복제 4.2 Minimum Functionality · 4.2.6(상용 템플릿이나 앱 생성 서비스로 만든 앱은 콘텐츠 제공자가 직접 제출해야 함) · 4.3(a)(b) Spam · 4.1 Copycats 「Functionality, Content, and User Experience」의 1. Limited Functionality and Content · 「Spam」의 Webviews and Affiliate Spam(웹사이트 소유자 허락 없이 웹뷰를 제공하는 앱) · Repetitive Content 10.1.4(고유하고 유익한 메타데이터, 가치 있는 사용자 경험, 스토어에서의 활동) · 10.1.1(웹 앱으로 제출하는 제품은 도메인이나 웹사이트 소유자가 게시해야 함)
필요 이상의 권한 · 기능 선언 5.1.1(iii) Data Minimization — 앱의 핵심 기능에 관련된 데이터만 요청해야 합니다 「Permissions and APIs that Access Sensitive Information」 — 민감한 권한은 Play Console 선언과 승인이 필요할 수 있습니다 10.6(선언한 기능은 제품의 기능과 정당하게 관련돼야 함). runFullTrust 같은 제한된 기능은 제출 옵션에서 사유를 승인받아야 합니다
연령 · 콘텐츠 등급 2.3.6 — App Store Connect 의 연령 등급 질문에 정직하게 답해야 합니다 「Content Ratings」 — 등급이 없는 앱은 허용되지 않습니다 11.11.1(IARC 설문을 정확히) · 11.11.2(등급 정보를 계속 최신으로. 7.20, 2026-10-22 시행) · 11.11.3. 번호는 7.20 기준이고 7.19 에는 번호 없는 11.11 본문과 11.11.3 만 있습니다
사용자 생성 콘텐츠(UGC) 1.2 — 부적절한 자료를 거르는 방법 · 신고 수단과 신속한 대응 · 악성 사용자 차단 · 공개된 연락처가 있어야 합니다 「User Generated Content」 — 약관 동의 · 앱 안의 신고 · 차단 수단을 포함한 지속적인 중재가 필요합니다 11.12(약관 · 콘텐츠 지침 공개, 신고 수단, 제거는 7.19 에도 있었음. 7.20 의 시행일 2026-10-22 부터 행동 강령, 제품 안과 웹사이트 양쪽 공개, 보호자 설정 존중, 제3자 UGC 플랫폼 연동 규정이 더해짐)
결제 3.1.1 In-App Purchase — 기능 잠금 해제는 앱 내 구입을 써야 합니다 「Payments」 — 앱 안 기능 · 디지털 콘텐츠 결제는 Google Play 결제 시스템을 써야 합니다(예외 조항 있음) 10.8.1 — 게임은 Microsoft Store 앱 내 구입 API 를 써야 하고, 게임이 아닌 PC 제품은 안전한 제3자 결제 API 도 쓸 수 있습니다
실시간 생성형 AI 5.1.2(i) — 제3자 AI 와 개인정보를 공유하기 전에 명시적 허락이 필요합니다. 챗봇 같은 소프트웨어를 앱 안에 담는 경우는 4.7 도 봅니다 「AI-Generated Content」 — 생성형 AI 앱은 기존 정책을 지켜야 하고 앱 안에서 신고할 수 있어야 합니다 11.16 — 사용 사실을 메타데이터와 파트너 센터 제출에 밝히고, 사용자가 신고할 수단을 제공해야 합니다

스토어 한 곳에만 있는 요건도 있습니다.

  • Mac App Store — 지침 2.4.5 가 샌드박스 · 패키징 · 자동 실행 금지 · 업데이트 경로 같은 추가 요건을 정합니다. 자세한 항목은 Mac App Store 편의 「자주 겪는 문제」에 있습니다.
  • Microsoft Store 의 EXE/MSI 설치 파일 — 10.2.9(서명 · 버전 주소 · 무인 설치 · 독립 실행형 설치 프로그램 · PC 전용), 10.4.4(다운로드 시간과 설치 성공률), 10.2.3(관련 없는 다른 소프트웨어 설치 금지), 10.2.7(깨끗이 제거되어야 함)을 봅니다. 요건은 Microsoft Store 편의 「MSIX 와 EXE/MSI 경로 비교」에 있습니다.

단계

  1. 거절 안내를 읽고 사유의 번호나 정책 이름을 적어 둡니다. Apple 은 App Store Connect 의 App Review 화면에서 거절 메시지를 읽고, Google 은 「정책 상태(Policy status)」와 알림 · 이메일에 적힌 정책을 읽고, Microsoft 는 인증 보고서에서 실패한 시험이나 정책 번호를 봅니다. Google 은 조치 안내가 계정이나 앱의 모든 위반을 빠짐없이 알려 주지 않을 수 있다고 밝히니, 적힌 사유만 고치지 말고 앱 전체를 다시 점검하세요.

    성공 판정 — 어긴 지침 번호(Apple) · 정책 이름(Google) · 실패한 시험이나 정책 번호(Microsoft)를 사유마다 하나씩 적어 두었습니다.

  2. 사유를 고치고 같은 문제가 다른 곳에도 없는지 봅니다. 위 「흔한 사유와 공식 번호」 표에서 사유의 행을 찾아 공식 문서의 정확한 문구를 열어 읽고 고칩니다. 심사용 계정 · 방침 URL · 스크린샷 같은 메타데이터 문제는 코드를 바꾸지 않아도 고쳐지고, 충돌이나 권한 문제는 빌드를 다시 만들어야 합니다.

    성공 판정 — 사유마다 무엇을 어떻게 고쳤는지 한 줄로 적을 수 있고, 같은 사유가 다른 화면 · 다른 언어 · 다른 스토어 등록정보에 남아 있지 않습니다.

  3. 무엇을 고쳤는지에 따라 다시 제출하거나 답글로 알립니다.

    • Apple — 빌드의 문제를 고쳤다면 새 빌드를 올려 제출하고, 이것은 새 빌드의 전체 심사를 시작합니다. 메타데이터나 서버 쪽 문제(심사용 계정 제공 · 활성화 등)는 고친 뒤 재제출하지 않고 App Store Connect 에서 App Review 의 메시지에 답하라고 Apple 이 안내합니다. 다시 제출하기 전에는 거절 메시지에 답하면서 스크린샷 같은 첨부를 보낼 수 있습니다. 사유를 모두 해결하기 전에는 재제출하지 않고, 이의 제기 중에 재제출하면 새 심사가 시작되며 이의가 닫힙니다. 거절된 버그 수정 업데이트의 메시지 맨 위에 「Bug Fix Submissions」 안내가 보이면 재제출하지 말고 답글로 현재 제출의 승인을 요청한 뒤 다음 업데이트에서 고칠 수 있습니다(이미 한 번 미룬 이슈는 다시 미룰 수 없습니다).
    • Google — 고친 번들을 내부 · 비공개 · 공개 테스트와 프로덕션 등 모든 트랙에 올리고 문제 있는 번들은 새 릴리스의 「포함되지 않음(Not included)」 구역에 둡니다. 비활성화하지 않으면 재제출이 실패하고 출시 중인 번들이 내려갈 수 있다고 Google 이 경고합니다. 릴리스 이름을 입력해 저장한 뒤 검토 화면(Review release)에서 100% 로 롤아웃합니다. 로그인 정보 때문이라면 새 번들 없이 「Sign-in details」를 고쳐 저장한 뒤 게시 개요에서 「검토를 위해 전송(Send for review)」을 눌러 다시 보냅니다.
    • Microsoft — 문제를 고친 뒤 앱의 새 제출을 만들어 인증을 다시 시작합니다. 패키지를 고쳤다면 Microsoft Store 편의 4단계대로 더 높은 버전(업데이트라면 현재 게시된 버전보다 높게)으로 다시 패키징합니다.

    성공 판정 — Apple 은 재제출했다면 상태가 「심사 대기 중(Waiting for Review)」으로 바뀌고 답글로 알렸다면 보낸 답글을 App Store Connect 에서 확인할 수 있으며, Google 은 변경이 「검토 중인 변경사항(Changes in review)」 구역으로, Microsoft 는 앱 상태가 「인증 중(In certification)」으로 바뀝니다.

  4. 필요하면 해명하고 이의 제기를 합니다. 고쳤는데도 결과에 동의할 수 없을 때만 합니다.

    • Apple — App Store Connect 에서 거절 메시지에 먼저 답해 해명하고, 그래도 해결되지 않으면 App Review Board 에 이의 제기를 합니다. 이의 제기는 한 번만 하세요. Apple 의 App Review 페이지는 심사를 통과하지 못한 제출당 한 번이라고, 이의 제기 안내는 거절되거나 내려진(removed) 앱당 한 번이라고 적습니다. 이의 제기와 신속 심사 요청은 심사 메시지 답글 창이 아니라 별도의 문의 양식(Contact Us)으로 보냅니다. 거절 메시지가 여러 지침 위반을 들었다면 한 번의 이의 제기에서 모두 다룹니다. 이미 고쳐서 다시 제출했다면 이의 제기를 하지 않습니다.
    • Google — 조치 안내 이메일의 안내를 따릅니다. 앱이 정지(suspended)됐다면 「정책 상태(Policy status)」 페이지의 「이의 제기(Appeal)」로도 시작할 수 있습니다. 조치 하나에 한 번이고, 이의 제기를 남용하면 이메일 지원을 받지 못할 수 있습니다.
    • Microsoft — 인증 보고서 메일에 회신하거나 reportapp@microsoft.com 에 앱 ID 를 적어 문의합니다. 별도의 이의 제기 절차는 확인하지 못했습니다(정책 페이지의 「Certification Appeal Process」 절도 같은 메일 주소로 심사 · 인증 상태를 문의하라고 안내할 뿐입니다). 연령 등급에 이의가 있으면 IARC 가 보내는 등급 증명 이메일의 링크로 이의를 제기합니다.

    성공 판정 — 해명이나 이의 제기를 보낸 날짜와 내용을 기록했고, 같은 내용을 다시 보내지 않았습니다.

  5. 결과를 확인하고 되풀이되면 접근을 바꿉니다. 같은 사유로 여러 번 거절되면 사유를 처음부터 다시 읽으세요. Google 은 거절이 반복되면 앱이 정지될 수 있다고 경고하고, Apple 은 심사 지침 2.3.1(b)에서 숨은 기능이나 오해를 부르는 홍보 같은 부정직한 행위가 심각하거나 반복되면 개발자 프로그램에서 제외될 수 있다고 정합니다.

    성공 판정 — 앱이 심사를 통과해 출시 방식대로 공개되었거나, 거절 사유가 바뀌어 새 사유를 다시 고치는 중입니다.

확인

  • 사유 목록: 거절 안내에 적힌 번호 · 정책 이름마다 고친 내용이 하나씩 있습니다.
  • 재제출: Apple 은 「심사 대기 중」(답글로 알렸다면 보낸 답글), Google 은 「검토 중인 변경사항(Changes in review)」, Microsoft 는 「인증 중(In certification)」으로 보입니다.
  • 선언: 개인정보 · 연령 등급 선언이 고친 앱과 같습니다. Microsoft 는 정책 7.20 의 11.11.2 가 2026-10-22 부터 등급 정보를 계속 최신으로 유지하라고 정합니다.
  • 이의 제기: 보냈다면 날짜와 내용이 기록돼 있고 같은 이의를 다시 보내지 않았습니다.

자주 겪는 문제

거절 사유가 모호합니다

Apple 은 거절 메시지에 답해 질문할 수 있고, 제출을 다시 하기 전까지 스크린샷 같은 첨부를 보낼 수 있습니다. 또 App Review 와 30분 화상 약속을 잡아 거절의 흔한 이유나 심사 과정을 물을 수 있다고 안내합니다. Microsoft 는 인증 보고서 메일에 회신하거나 reportapp@microsoft.com 으로 문의하라고 안내합니다. Google 은 조치 안내 이메일과 「정책 상태(Policy status)」의 설명을 읽고, 적힌 정책 본문을 열어 보라고 안내합니다.

업데이트가 거절되면 이미 출시된 버전은 어떻게 되나요?

Google 은 기존 앱의 업데이트가 거절돼도 업데이트 전에 게시된 버전은 Google Play 에 그대로 있다고 안내합니다. 같은 사항을 Apple 과 Microsoft 의 공식 문서에서는 확인하지 못했습니다.

바꾼 내용이 검토로 넘어가지 않습니다

Google 은 거절된 뒤에 바꾼 내용을 자동으로 검토에 보내지 않습니다. 저장한 뒤 게시 개요(Publishing overview)에서 「검토를 위해 전송」을 눌러야 합니다. 로그인 정보를 고쳤을 때도 같습니다.

Google Play 의 「앱 거부됨(App rejected)」과 「업데이트 거부됨(Update rejected)」은 무엇이 다른가요?

둘 다 정책이나 개발자 배포 계약을 지키지 못한 변경이 있다는 뜻입니다. 「앱 거부됨」은 처음 게시하려는 초안(Draft) 앱에만 쓰이고, 이미 게시된 앱의 업데이트는 「업데이트 거부됨」으로 표시됩니다. 두 경우 모두 고쳐서 다시 제출하거나 이의를 제기할 수 있다고 Google 이 안내합니다.

같은 사유로 계속 거절됩니다

고쳤다고 생각한 부분이 실제 앱이나 스토어 등록정보에 반영되지 않았을 수 있습니다. 빌드 번호를 올렸는지, 올바른 트랙(Google)이나 올바른 빌드(Apple)를 골랐는지, 패키지 버전을 올렸는지(Microsoft)부터 확인하세요. 같은 사유가 계속되면 위 「흔한 사유와 공식 번호」 표의 지침 문구를 처음부터 다시 읽고, 거절 메시지에 질문하세요. 거절이 쌓이면 Google 은 앱 정지를, Apple 은 심각하거나 반복되는 부정직한 행위에 대한 개발자 프로그램 제외를 경고합니다.

Microsoft 정책이 바뀐다는데 어느 버전을 보면 되나요?

정책 7.20 이 2026-09-15 에 게시되어 2026-10-22 부터 시행됩니다. 그 전까지는 7.19(2025-10-14 시행)가 적용됩니다. 7.20 은 연령 등급(11.11)에 제품 수명 주기 내내 최신으로 유지하라는 11.11.2 를 더했고, 사용자 생성 콘텐츠(11.12)를 고쳐 약관 · 행동 강령 · 콘텐츠 지침을 제품 안과 웹사이트 양쪽에서 볼 수 있게 하고 보호자 설정을 존중하라는 항목, 제3자 게임 모드 · UGC 플랫폼과 연동할 때의 신고 · 중재 규정을 더했습니다. 제출 직전에 정책 페이지의 문서 버전과 시행일을 다시 확인하세요.

EXE/MSI 설치 파일이 인증에서 거절됐습니다

Microsoft 의 EXE/MSI 인증은 패키지 URL 이 HTTPS 인지, 악성코드가 없는지, 무인 설치가 되는지, 표준 사용자 계정으로 설치되는지, 시작 메뉴와 프로그램 목록에 항목이 생기는지, 독립 실행형 오프라인 설치 프로그램인지, 다른 앱을 끼워 넣지 않는지를 봅니다. 서명은 정책 10.2.9 가 필수로 정하니 설치 파일과 그 안의 모든 PE 파일을 서명했는지 확인하세요. 같은 주소의 파일을 바꾸지 말고 새 설치 파일은 새 버전 주소로 제출합니다.

다음 단계

고친 앱을 다시 낼 때는 업데이트와 단계적 출시의 순서를 따르세요. 제출 전에는 제출 전 체크리스트를 다시 훑고, 스토어별 절차는 스토어별 안내에서 고릅니다.

출처