빠른 답변
Google 2025년 연간 투명성 보고서를 기준으로 하면 Google Play의 제출 거부 비율은 약 7.89%입니다. 거부된 제출 1,692,467건을 검토된 제출 21,461,250건으로 나눈 값입니다. 이는 Google이 공개한 건수로 계산한 값이며, 2026년 연간 거부율도 아니고 새 앱이 첫 제출에서 통과하지 못할 확률도 아닙니다. Google이 따로 공개하는 정책 시행 수치는 이와 다른 결과를 측정한 것입니다.
출처: Google Play 2025년 연간 투명성 보고서(PDF), 2026년 3월 31일 발표, 전 세계 기준. 2024년 보고서는 같은 방식으로 10.13%가 나옵니다.
이 글은 Google이 최근 공개한 제출 및 정책 시행 수치와 그 한계, 그리고 거부에 대응할 때 실제로 도움이 되는 점검 항목을 설명합니다. 연간 투명성 보고서 데이터와 연간 안전 결산, 본문에서 링크한 모든 정책 문서는 2026년 9월 12일에 확인했습니다.
이 글의 근거 표시를 읽는 방법
- Google 보고서Google 투명성 보고서나 연간 안전 결산에 실린 수치이며, 숫자 옆에 출처를 달았습니다.
- 계산Google이 공개한 건수를 이 글에서 직접 계산한 값입니다. Google은 그 결과를 공개하지 않습니다.
- Google 정책Play Console 고객센터나 개발자 프로그램 정책에 설명된 요구사항이나 절차입니다.
- 실무 점검저희가 지원하는 제출 과정에서 권장하게 된 점검입니다. Google 규칙이 아니며, 측정된 거부 빈도도 아닙니다.
- 예시기록을 어떤 형태로 남기면 되는지 보여 주려고 만든 예시입니다. 고객 사례도 아니고 플랫폼 통계도 아닙니다.
이 페이지에서
2026년 Google Play 앱 거부율은 얼마인가요?
Google은 “거부율”이라는 이름의 퍼센트를 공개하지 않습니다. 대신 그 값을 계산하는 데 필요한 두 건수, 즉 앱 제출을 몇 건 검토했고 몇 건을 거부했는지를 1년에 한 번 공개합니다. 자료가 완성된 가장 최근 연도는 2025년이고 2026년 3월 31일에 발표되었으므로, 2026년에 쓰는 글은 2025년 활동을 근거로 삼습니다.
가장 최근에 집계가 끝난 연간 제출 데이터
Google 보고서| 활동 연도 | 검토된 제출 | 거부된 제출 | 거부 ÷ 검토 | 보고서 발표 |
|---|---|---|---|---|
| 2024 | 19,292,647 | 1,955,305 | 10.13% | 2025년 3월 31일 · 보고서 |
| 2025 | 21,461,250 | 1,692,467 | 7.89% | 2026년 3월 31일 · 보고서 |
출처 위치: 2025년 보고서 인쇄본 3쪽, 2024년 보고서 인쇄본 3~4쪽. 퍼센트는 공개된 건수로 계산했으며(거부 ÷ 검토 × 100), 소수점 둘째 자리까지 반올림했습니다. 두 보고서 모두 집계 범위를 전 세계로 밝히고 있습니다. 데이터는 2026년 9월 12일에 확인했습니다.
연도별 계산 보기
검토된 전체 제출 중 거부된 비중
2025년에는 검토된 제출 100건 중 약 8건이 거부되었습니다.
이 비율을 계산하는 방법과 예측할 수 없는 것
이 비율은 Google이 보고한 전 세계 연간 앱 제출 검토 건수와 거부 건수를 비교한 값입니다. 보고서에는 첫 제출만 따로 묶은 모집단도, 제출 차수별 세부 내역도 없습니다. 따라서 이 전체 집계값으로 특정 신규 앱의 결과를 예측해서는 안 됩니다.
이 비율로는 알 수 없는 것
- 내 앱의 확률. 나머지 값(약 92%)은 새 앱이 첫 검토에서 승인될 확률이 아닙니다.
- 2026년 수치. 2026년 연간 데이터는 아직 공개되지 않았습니다. 이 숫자는 2026년에 확인할 수 있는 2025년 데이터로 표기하세요.
- 최종 승인률. 2025년 보고서에는 거부 이후 승인된 건수도 나오지만, 수정 후 승인률을 내는 데 필요한 모집단 집계는 없습니다. 그래서 이 글에서는 계산하지 않았습니다.
- 비공개 테스트나 프로덕션 액세스 승인률. 신규 개인 계정에 대한 액세스 결정은 별개의 절차이며, 이 표에는 집계되어 있지 않습니다.
- 정책이 엄격해졌는지 여부. 10.13%에서 7.89%로 낮아진 것은 비율의 변화일 뿐, 정책이 완화되었다거나 검토 기준이 달라졌다거나 개별 개발자의 위험이 줄었다는 근거는 아닙니다.
사이트마다 다른 수치를 인용하는 이유
어떤 글은 Google이 분모를 공개하지 않는다고 말합니다. 연간 안전 결산 계열에는 맞는 말이지만 투명성 보고서에는 해당하지 않습니다. 또 어떤 글은 연간 안전 결산의 “게시 차단 앱” 건수를 투명성 보고서의 분모로 나누는데, 이는 서로 다른 두 계열을 섞는 것입니다.
Google이 공개하는 거부 및 정책 시행 통계
Google은 플랫폼 안전 현황을 두 곳에서 발표하며, 이 둘은 혼동하기 쉽습니다. 하나는 제출과 정책 시행 건수를 표로 정리한 연간 투명성 보고서이고, 다른 하나는 반올림한 대표 수치를 글로 풀어 쓴 Google 블로그의 연간 안전 결산입니다.
검토된 제출과 거부된 제출
Google 보고서위 표의 검토 및 거부 건수 외에도 2025년 투명성 보고서에는 앱 삭제 2,012,981건과 해지된 개발자 계정 125,550개가 실려 있습니다. 삭제는 이미 제공 중이던 앱에 대한 조치이고, 거부는 앱이 공개되기 전 제출에 대한 결정입니다.
출처: 2025년 연간 투명성 보고서, 인쇄본 3쪽.
게시가 차단된 앱, 2023년~2025년
Google 보고서| 활동 연도 | 게시가 차단된 정책 위반 앱 | 차단된 악성 개발자 계정 | 출처 |
|---|---|---|---|
| 2023 | 228만 | 333,000 | 2023년 안전 결산(2024년 4월 29일) |
| 2024 | 236만 | 158,000 이상 | 2024년 안전 결산(2025년 1월 29일) |
| 2025 | 175만 이상 | 80,000 이상 | 2025년 안전 결산(2026년 2월 19일) |
같은 결산에는 거부 건수가 아닌 다른 성격의 수치도 함께 실립니다. 2023년에는 백그라운드 위치나 SMS 같은 민감한 권한과 관련해 약 200,000건의 제출이 거부되거나 시정되었습니다. 2024년에는 민감한 사용자 데이터에 불필요하거나 과도하게 접근하려던 앱 130만 개가 차단되었고, 2025년에는 그 수치가 255,000개 이상이었으며 스팸 평점과 리뷰 1억 6,000만 건도 함께 차단되었습니다. 이 수치들은 서로 더할 수 있는 값도, 위 표와 더할 수 있는 값도 아닙니다.
Google은 또한 앱 출시 전후로 10,000건이 넘는 안전 검사를 실행한다고 설명합니다. 이 숫자가 작은 결함 하나하나가 곧바로 거부로 이어진다는 뜻은 아니며, 그 검사가 모두 게시 전 관문이라는 뜻도 아닙니다.
거부, 삭제, 차단 건수가 서로 다른 이유
| 출처 | 지표 | 단위 | 기간 | 포함하지 않는 것 |
|---|---|---|---|---|
| 연간 투명성 보고서 | 거부된 제출 | 제출 건수이며, 고유 앱 기준 모집단이 아님 | 역년(1~12월) | 같은 앱이 이후에 승인되었는지 여부 |
| 연간 투명성 보고서 | 앱 삭제 | 게시 후 삭제된 앱 | 역년(1~12월) | 공개된 적 없는 제출 |
| 연간 안전 결산 | 게시가 차단된 앱 | 앱 수, 반올림 값 | 역년(1~12월) | 분모. 비율로 환산할 수 없음 |
| 연간 안전 결산 | 차단된 개발자 계정 | 계정 수 | 역년(1~12월) | 개별 앱 거부 |
Google의 연간 투명성 보고서와 연간 안전 결산은 지표 이름이 다르고 합계도 다릅니다. 각 숫자는 출처와 정의에 붙여 둔 채로 쓰세요. 확인한 보고서 어디에도 두 계열을 서로 환산하는 방법은 나와 있지 않으므로, 둘을 합쳐 하나의 거부율을 계산해서는 안 됩니다.
플랫폼 전체 집계값과 특정 업체가 측정한 결과는 동시에 사실일 수 있습니다. PrimeTestLab의 관리형 테스트 완료율은 저희가 직접 진행하고 종료일까지 인원을 채워 운영한 비공개 테스트를 설명하는 값이고, Google의 비율은 보고된 앱 제출 건수를 설명하는 값입니다. 어느 쪽도 다른 쪽을 예측해 주지 않습니다.
어떤 Google Play 결정을 받으셨나요?
무엇을 고치기 전에, 지금 보고 있는 결정이 어떤 종류인지부터 확인하세요. “거부”라는 말은 최소한 다섯 가지 상황에 두루 쓰이고, 상황마다 다음 단계가 다릅니다. Play Console의 상태 표시와 계정 소유자에게 발송된 메일에 그 이름이 적혀 있습니다.
Google 정책받으신 안내를 선택하세요
| 결정 또는 차단 사유 | 해당 상황 | 다음 단계 |
|---|---|---|
| 앱 또는 업데이트 거부 | 제출한 변경사항이 받아들여지지 않았습니다. 일반적인 업데이트 거부에서는 수정하는 동안 이전에 게시된 버전이 그대로 제공됩니다. | 안내를 읽고 해당 제출을 수정한 뒤 다시 제출하세요. 거부된 뒤에 할 일을 참고하세요. |
| 프로덕션 액세스 거부 또는 “추가 테스트 필요” | 신규 개인 계정의 앱을 프로덕션으로 옮기려는 신청에 보완이 필요하다는 뜻입니다. 앱에 대한 처분이 아니라 비공개 테스트의 준비 상태에 대한 결정입니다. | 테스트와 준비 상태 단계를 따른 다음, 프로덕션 액세스 테스트 거부 해결하기를 참고하세요. |
| 앱 삭제 | 스토어 등록정보가 더 이상 제공되지 않습니다. 이미 게시된 앱에 사후 정책 시행 조치가 내려진 경우입니다. | 정책 시행 안내를 따라, 안내에 적힌 경로로 정책을 충족하는 업데이트를 제출하세요. |
| 앱 정지 또는 계정 해지 | 앱 단위 또는 계정 단위의 더 강한 정책 시행 조치이며, 각각 별도의 안내와 결과가 따릅니다. | 안내에 적힌 이의신청 절차를 이용하세요. 다시 게시하려고 다른 계정을 새로 만들지 마세요. 그 자체가 위반으로 처리됩니다. |
| 업로드 또는 호환성 차단 | 준비한 상태로는 제출이 진행되지 않습니다. 예를 들어 타겟 API 수준이 현재 최소 기준보다 낮거나, Play Console이 받아들이지 않는 번들인 경우입니다. | 명시된 기술 요구사항을 해결한 뒤 다시 제출하세요. 아직 검토가 시작되지 않은 단계입니다. |
상태 표시의 의미: Play Console 고객센터, 앱 게시하기 및 정책 시행 절차.
상태 표시로는 알 수 없는 것
앱이 제공되지 않는다고 해서 반드시 정책 위반으로 거부된 것은 아닙니다. 직접 게시를 중단했거나 호환성 규칙에 걸려 있을 수도 있습니다. 또한 프로덕션 액세스 거부에는 원인이 여러 가지일 수 있으므로, 위 표의 각 행은 진단이 아니라 경로 안내로 보시면 됩니다. 비공개 트랙에 올린 출시 버전도 정책 검토를 받을 수 있고, 프로덕션 액세스 신청은 그와 별개인 테스트 준비 상태에 대한 결정입니다.
문서로 확인되는 거부 위험과 실무 수정 방법
Google은 거부 사유의 빈도 순위를 공개하지 않으며, 이 글도 순위를 지어내지 않습니다. 아래 여덟 가지 점검은 빌드에서 바깥쪽으로, 실제로 수행할 수 있는 순서대로 배열했고 항목마다 정책 출처를 달았습니다. 비공개 테스트 관련 항목은 테스트 섹션에 있습니다. 그것은 신규 개인 계정의 자격 조건이지 정책 위반에 따른 거부가 아닙니다.
안정성과 쓸모 있는 기능
비정상 종료, 멈춤, 설치 실패
- 문제
- Google의 기능 관련 정책은 비정상 종료되거나 강제 종료되거나 멈추는 등 정상적으로 작동하지 않는 앱을 금지합니다. 설치되지 않는 앱, 설치는 되지만 실행되지 않는 앱, 실행은 되지만 반응이 없는 앱도 여기에 포함됩니다.
- 확인 방법 한 가지
- 제출할 출시 후보 빌드를 그대로 실제 기기 두 대에 새로 설치해 보세요. 실행하고, 로그인하고, 핵심 흐름을 끝까지 진행하고, 백그라운드로 보냈다가 다시 불러옵니다. 그다음 사전 출시 보고서에서 비정상 종료와 ANR(앱 응답 없음)을 확인하세요.
- 수정
- 제출 전에 실행 시 비정상 종료와 ANR을 해결하고, 다시 빌드한 바이너리로 같은 흐름을 한 번 더 확인하세요.
앱 고유의 기능 없이 정적인 콘텐츠만 있는 경우
- 문제
- 같은 정책은 기능이나 콘텐츠가 부족한 경우도 다룹니다. 앱만의 쓸모가 없는 정적 콘텐츠, 콘텐츠가 거의 없는 앱, 아무 기능도 하지 않도록 만들어진 앱이 여기에 해당합니다. 형식 자체가 정책 충족 여부를 결정하지는 않으며, 앱에는 여전히 충분한 유용성과 콘텐츠가 필요합니다.
- 확인 방법 한 가지
- 앱의 핵심 기능을 직접 보여 주고, 그 기능이 사용자에게 어떤 쓸모를 주는지 설명해 보세요. 정적인 자료를 보여 주는 데 그치지 않고 충분한 콘텐츠와 의미 있는 기능을 갖췄는지 확인하세요.
- 수정
- 의도한 용도에 맞는 충분한 유용성을 갖추도록 기능이나 콘텐츠를 보강하세요.
검토자 액세스
검토자가 제한된 기능이나 핵심 기능에 접근하지 못하는 경우
- 문제
- Google은 로그인, 지역 제한, 일반적이지 않은 인증 뒤에 있는 기능에 대해 실제로 작동하는 로그인 정보와 이용 안내를 요구합니다. 이것이 없으면 검토자는 막힌 화면을 만나게 되고, 검토할 수 없는 앱은 승인되지 않습니다.
- 확인 방법 한 가지
- 제출할 출시 버전을 아무 기록도 없는 기기에 설치하고, 앱 콘텐츠 페이지에 적어 둔 로그인 정보와 안내만으로 들어가 보세요. 그 밖에 다른 것이 필요했다면 검토자에게도 똑같이 필요합니다.
- 수정
- 만료되지 않는 검토 전용 계정과, 접근이 제한된 모든 기능에 대한 단계별 안내를 제공하세요. 모든 앱에 로그인이 필요한 것은 아니며, 작동하는 계정은 검토의 전제 조건일 뿐 승인을 보장하지는 않습니다.
출처 검토를 위한 앱 준비
권한, 개인정보, 데이터 보안
권한 범위와 선언
- 문제
- 백그라운드 위치나 SMS 같은 민감한 권한에는 앱이 눈에 보이게 제공하는 사용 사례가 있어야 하고, 선언 양식이 있는 권한이라면 그 내용이 앱의 실제 동작과 일치해야 합니다. Google의 2023년 안전 결산은 바로 이 문제로 약 200,000건의 제출이 거부되거나 시정되었다고 밝혔습니다.
- 확인 방법 한 가지
- 매니페스트에 선언한 위험 권한을 모두 적어 보고, 각 권한마다 사용자가 그 권한이 필요한 이유를 확인하게 되는 화면이 어디인지 짚어 보세요.
- 수정
- 눈에 보이는 사용 사례가 없는 권한은 삭제하고, Play Console의 선언이 검토자가 실제로 보게 될 동작을 설명하도록 맞추세요. 기능과 관련이 있다는 이유만으로는 충분하지 않습니다. 해당 권한에 적용되는 제한과, 접근 전에 요구되는 눈에 띄는 공개 및 동의 절차를 확인하세요.
출처 사용자 데이터 정책 · 2023년 안전 결산
개인정보처리방침과 계정 삭제
- 문제
- Play Console에 개인정보처리방침 URL을 입력하고, 앱 안에도 링크나 방침 본문을 두세요. 해당 페이지는 공개되어 있어야 하고, 지역 차단이 없어야 하며, PDF가 아니어야 하고, 방문자가 편집할 수 없어야 하며, 앱이나 개발자를 밝히고 실제로 수집하는 데이터를 설명해야 합니다. 앱 안에서 계정을 만들 수 있다면 앱 안과 앱 밖 모두에서 찾기 쉬운 삭제 요청 경로를 제공하고, 보관이 필요한 데이터가 있다면 그 사실도 알려야 합니다.
- 확인 방법 한 가지
- 로그아웃 상태의 기기에서, 가능하다면 다른 국가에서도 그 URL을 열어 보고, 데이터 보안 양식과 대조해 읽어 보세요.
- 수정
- 직접 관리하는 방침 페이지를 게시해 Play Console과 앱 양쪽에 넣고, 앱에서 계정을 만들 수 있다면 삭제 요청 경로를 추가하세요.
출처 사용자 데이터 정책
데이터 보안 양식과 SDK의 일치 여부
- 문제
- 데이터 보안 선언은 앱과 그 안에 들어 있는 모든 서드파티 SDK가 무엇을 수집하고 공유하는지를 그대로 반영해야 합니다. 광고, 분석, 비정상 종료 보고 SDK는 런타임 권한 없이도 데이터를 수집하거나 공유할 수 있습니다. 그래서 “권한이 없는” 앱이 곧 “데이터를 다루지 않는” 앱이 되지는 않으며, 개인정보처리방침 페이지가 살아 있다고 해서 양식이 정확하다는 근거가 되지도 않습니다. 사용 중인 SDK의 버전과 설정, 실제 동작을 확인하세요.
- 확인 방법 한 가지
- 출시 버전의 종속성 목록을 뽑아 각 SDK가 공개한 데이터 처리 내용을 찾아보고, 양식의 모든 답변과 하나씩 대조하세요. 첫 실행 시 네트워크를 관찰해, 사용자가 아무것도 하기 전에 기기 밖으로 나가는 데이터가 있는지 확인하세요.
- 수정
- 관찰한 동작에 맞게 양식을 수정하거나 해당 SDK를 제거하세요. 직접 작성하지 않은 코드까지 포함해, 선언의 책임은 개발자에게 있습니다.
스토어 등록정보, 선언, 결제
스토어 등록정보, 광고, 타겟층, 콘텐츠 선언
- 문제
- 앱 콘텐츠 섹션에서는 앱에 광고가 있는지, 어떤 사용자층을 대상으로 하는지를 묻고, 콘텐츠 등급 설문과 그 밖에 해당하는 선언을 요구합니다. 빌드에 없는 기능을 보여 주는 스토어 등록정보나 앱과 어긋나는 선언은 그 자체로 거부 사유가 됩니다.
- 확인 방법 한 가지
- 출시 버전을 옆에 띄워 둔 채로 앱 콘텐츠의 답변을 하나씩 짚어 보고, 모든 스크린샷을 현재 화면과 대조하세요.
- 수정
- 선언과 등록정보 애셋을 그것이 설명하는 빌드에 맞게 업데이트하세요. 등록정보만 고치는 경우라면 새 바이너리가 필요하지 않을 수도 있습니다.
출처 검토를 위한 앱 준비
결제와 적용되는 프로그램 조건
- 문제
- 디지털 상품과 서비스의 일부 인앱 구매에는 Google Play 결제 시스템을 사용해야 합니다. 실물 상품과 오프라인 서비스, 그 밖의 일부 유형은 대상에서 제외되며, 대체 결제나 외부 안내 프로그램은 특정 지역에서 각자의 조건에 따라 적용됩니다.
- 확인 방법 한 가지
- 구매 흐름마다 앱 안에서 소비되는 디지털 콘텐츠를 판매하는지 판단하고, 그렇다면 Play Billing이나 실제로 가입되어 있는 프로그램을 통해 처리되는지 확인하세요.
- 수정
- 디지털 구매를 Play Billing으로 옮기거나 프로그램 가입 사실을 기록해 두세요. 특정 지역 프로그램을 전 세계에 적용되는 예외로 여기지 마세요.
출처 결제 정책
사전 검토 확인은 검토가 아닙니다
Play Console의 사전 검토 확인은 제출 전에 이 가운데 일부를 알려 줍니다. 로그인 정보 누락, 권한 선언, 깨진 개인정보처리방침 링크 같은 것들입니다. 사전 출시 보고서는 테스트 기기에서 앱을 실제로 실행해 봅니다. 둘 다 해 볼 가치가 있지만, 통과했다고 해서 정식 앱 검토에서 승인이 보장되지는 않습니다. 또 어느 쪽도 비공개 테스트 참여자가 앱을 어떻게 사용했는지는 측정하지 않습니다.
비공개 테스트가 프로덕션 액세스에 미치는 영향
테스트 요구사항은 누구에게 적용되나요?
Google 정책2023년 11월 13일 이후에 만든 개인 개발자 계정은 프로덕션 액세스를 신청하기 전에 최근 14일 동안 중단 없이 참여 상태를 유지한 테스터 12명 이상으로 비공개 테스트를 진행해야 합니다. 최소 요건을 충족하면 신청할 자격이 생기는 것이지 앱이 승인되는 것은 아닙니다. 조직 계정과 그 이전에 만든 개인 계정은 이 요구사항의 대상이 아닙니다.
내부 테스트는 아무리 오래 진행해도 비공개 테스트를 대신하지 못합니다. 테스터 12명은 비공개 트랙에서 참여 상태여야 합니다. 설정 방법은 Google Play 비공개 테스트 요구사항 글에서 자세히 다룹니다.
근거와 준비 상태, 그리고 다음 단계
요건을 충족한 테스트에서 프로덕션 출시까지
- 1요건을 충족하는 비공개 테스트를 마칩니다. 최근 14일 동안 중단 없이 참여 상태를 유지한 테스터가 12명 이상이어야 합니다.
- 2프로덕션 액세스를 신청합니다. 신청서는 테스터가 앱을 어떻게 사용했는지, 어떤 의견을 받았는지, 그 결과 무엇이 바뀌었는지를 묻습니다.
- 3Google이 신청서를 검토합니다. 보통 7일 이내이지만 더 오래 걸릴 때도 있으며, 액세스를 부여하거나 추가 테스트를 요청합니다. 이 기간은 이 검토에 해당하는 것이지 출시 전체 일정에 해당하는 것이 아닙니다.
- 4액세스를 받으면 프로덕션 출시를 준비합니다. 그 출시에 대한 검토와 단계적 배포는 이 결정과 별개의 단계입니다. 액세스는 게시할 수 있는 자격이지 게시 자체가 아닙니다.
테스터 한 명이 참여를 취소하면 그 테스터의 요건 기간이 끊기고 그 사람의 일수는 더 이상 집계되지 않습니다. 다른 테스터는 영향을 받지 않습니다. 신청 시점에 중요한 것은 요건을 충족하는 테스터가 12명 남아 있는지이지, 중간에 나간 사람이 있었는지가 아닙니다.
Google은 무엇을 배웠는지 묻지, 업데이트를 최소 몇 번 하라고 정해 두지는 않습니다. 솔직하게 말할 수 있어야 하는 준비 상태 진술은 이렇습니다. 테스터 의견을 검토했고, 필요한 부분은 조치했으며, 무엇을 배웠고 앱이 왜 준비되었는지 설명할 수 있습니다. 솔직한 답이 아무도 앱을 쓰지 않았다는 것이라면, 검토에서도 같은 결론에 이를 가능성이 큽니다.
테스터를 12명보다 몇 명 더 두면 이탈에 대비한 여유가 생기고 받는 의견의 폭도 넓어집니다. 다만 그것으로 승인 가능성이 높아진다는 측정 결과를 저희가 주장하는 것은 아닙니다. 대표적인 실제 기기를 함께 다루는 것은 QA 차원의 선택입니다. 공개된 기준은 에뮬레이터를 어떻게 집계하는지에 대해 아무것도 말하지 않으며, 이 글도 어느 쪽으로든 주장하지 않습니다. 함께 보기: 테스터 여유 인원 계획하기, 프로덕션 액세스 신청서 질문, 거부된 뒤 확인할 사항.
앱이나 업데이트가 거부된 뒤에 할 일
안내에는 어떤 결정인지, 어떤 제출이 대상인지, 어떤 정책이나 요구사항이 걸렸는지가 적혀 있습니다. 그 안내를 기준으로 다음 순서대로 진행하세요.
Google 정책- 1정확히 어떤 결정이고 어떤 제출이 대상인지 확인합니다. 어느 출시 버전인지, 어느 트랙인지, 어떤 정책이나 요구사항인지 봅니다.
- 2지적된 문제를 재현하거나 직접 확인합니다. 지금 작업 중인 빌드가 아니라 실제로 검토를 받은 빌드에서 확인하세요.
- 3문제를 수정하고 같은 영역의 관련 요구사항도 함께 점검합니다. 다음 검토에서 그 옆에 있던 문제가 걸리지 않도록 하기 위해서입니다.
- 4대상 빌드나 선언을 검증합니다. 위 점검 항목에 있는 확인 방법을 다시 실행해 보세요.
- 5알맞은 수정 사항을 제출합니다. 결정이 잘못되었다고 판단되면 이의신청 경로를 이용하세요. 필요한 경우 Play Console의 게시 개요를 열고 ‘검토를 위해 전송’을 선택해야 합니다. 수정 내용을 저장했다고 해서 항상 자동으로 제출되지는 않습니다.
- 6근거를 남기고 결과를 확인합니다. 안내 내용, 버전, 문제, 수정, 검증, 결정을 기록해 두세요.
수정 후 재제출할지, 이의신청할지
지적이 맞다면 수정한 뒤 다시 제출하세요. Google의 정책 시행 안내는 위반을 고치지 않은 채 다시 제출하는 것 자체가 문제라고 분명히 밝히고 있습니다. 지적된 위반이 해결되지 않은 상태에서는 재제출하지 마세요. 수정 중에는 바이너리를 그대로 두고 스토어 등록정보나 선언만 바꾸는 것도 있습니다. 결정이 잘못되었다고 판단되면 안내에 적힌 이의신청 방법을 따르고, 패키지 이름, 해당 버전, 지적된 정책, 결정이 잘못되었다고 보는 이유, 그리고 정책을 지키고 있음을 보여 주는 스크린샷이나 재현 절차를 함께 제출하세요. 다른 계정으로 다시 게시하려고 시도하지 마세요.
출처: 정책 시행 절차 · 앱 변경사항의 검토 및 게시 시점 관리.
바이너리를 고쳐야 할까요, 선언을 고쳐야 할까요?
스토어 등록정보나 선언만 고치는 경우에는 새 바이너리가 필요하지 않을 수 있습니다. 수정 내용이 패키지에 포함된 코드, 애셋, 권한, 설정을 바꾼다면 새 빌드가 필요합니다. 웹사이트나 서버 쪽 수정만으로 문제가 해결되는 경우도 있습니다. 안내를 따르고, 대상 제출을 검증하세요.
Google은 일반적인 앱 변경사항 처리 기간을 몇 시간에서 7일까지이며 때로는 더 오래 걸린다고 설명합니다. 이는 여러분이 받은 거부나 이의신청이 그 안에 해결된다는 보장이 아니며, 프로덕션 액세스 검토는 별개의 절차입니다. Google Play 검토 기간을 참고하세요. 거부가 몇 번까지 허용되는지, 이의신청 성공 확률이 얼마인지는 공개되어 있지 않고, 이 글도 그런 수치를 약속하지 않습니다.
쓸모 있는 거부 기록은 어떤 모습일까요?
예시남겨 둘 만한 근거가 어떤 형태인지 보여 주려고 만든 예시 기록 두 개입니다. 하나는 업데이트 거부, 다른 하나는 테스트 자격 미충족입니다. 고객 사례도 아니고 통계도 아닙니다. Play Console의 제출 활동에 있는 제출 ID를 안내 내용, 해당 버전과 함께 남겨 두면 고객지원팀이 정확한 제출 건을 확인할 수 있습니다.
| 안내 내용 | 업데이트 거부, 사용자 데이터 정책 |
|---|---|
| 해당 버전 | 2.4.1(빌드 241), 프로덕션 트랙 |
| 문제 | 스토어 등록정보의 개인정보처리방침 링크가 404를 반환함 |
| 수정 | Play Console과 앱에서 이미 쓰고 있던 기존 URL에 개인정보처리방침 페이지를 복구함. 앱에 들어 있는 URL은 바뀌지 않아 새 바이너리가 필요하지 않았음. |
| 검증 | 로그아웃 상태의 기기에서 두 개 국가에서 URL을 열어 확인, 데이터 보안 양식을 해당 페이지와 대조해 다시 읽음 |
| 결정 | 재제출 후 업데이트 승인됨 |
| 안내 내용 | 테스트 자격 미충족 |
|---|---|
| 해당 버전 | 1.0.3, 비공개 트랙 |
| 문제 | 테스터 12명을 추가했으나 14일 동안 참여 상태를 유지한 사람은 9명뿐이었음 |
| 수정 | 대체 테스터 3명을 모집했고, 각자 자신의 14일 기간을 새로 시작함 |
| 검증 | 대시보드에 최근 14일 동안 참여 상태인 테스터 12명이 표시됨 |
| 결정 | 대체 테스터들이 각자 필요한 기간을 채운 뒤 신청 자격을 갖춤 |
제출 전 체크리스트
지난주에 테스트한 빌드가 아니라 지금 제출하려는 바로 그 출시 버전으로 확인하세요. 해당하는 경우라고 표시한 항목은 앱이 무엇을 하는지에 따라 달라집니다.
빌드와 동작
검토자 액세스와 선언
개인정보와 데이터
결제
테스트 요건, 신규 개인 계정만 해당
질문과 답변
연간 비율로 내 앱의 첫 검토 결과를 예측할 수 있나요?
아니요. 7.89%라는 비율은 Google이 보고한 2025년 전 세계 앱 제출 검토 건수와 거부 건수를 비교한 값입니다. 보고서에는 첫 제출만 따로 묶은 모집단이 없으므로, 이 비율도 그 나머지 값도 특정 신규 앱에 대한 확률이 아닙니다.
안전 결산의 수치는 왜 투명성 보고서의 수치와 다른가요?
서로 다른 것을 측정하기 때문입니다. 연간 안전 결산은 게시가 차단된 정책 위반 앱의 건수를 반올림해 발표하고, 투명성 보고서는 거부된 제출과 앱 삭제 건수를 집계합니다. Google은 두 계열을 서로 맞춰 보는 기준을 공개하지 않으므로, 둘을 합쳐 하나의 비율로 만들 수 없습니다.
업데이트가 거부되면 이미 게시된 버전에도 영향이 있나요?
일반적인 업데이트 거부는 이미 게시된 버전을 내리지 않습니다. 업데이트를 수정하는 동안 이전 출시 버전은 그대로 제공됩니다. 앱 삭제, 앱 정지, 계정 해지는 각각 별도의 안내가 있는 정책 시행 상태이며, 이들은 제공 중인 앱에 영향을 미칩니다.
프로덕션 액세스 거부도 정책 위반에 따른 거부인가요?
아니요. 신규 개인 계정에 대한 프로덕션 액세스 결정은 진행한 비공개 테스트와 제출한 답변을 검토한 결과입니다. “추가 테스트 필요”는 신청서에 보완이 필요하다는 뜻이지 앱에 대한 정책 위반 처분이 아니며, 테스터를 늘린다고 해서 실제 정책 위반에 따른 거부가 해결되지도 않습니다.
이의신청을 해야 하나요, 수정 사항을 제출해야 하나요?
지적된 위반이 해결되지 않은 상태에서는 다시 제출하지 마세요. 수정 중에는 바이너리를 그대로 두고 스토어 등록정보나 선언만 바꾸는 것도 있습니다. 결정이 잘못되었다고 판단되면 안내에 적힌 이의신청 방법을 따르고 정책을 지키고 있다는 근거를 제출하세요. 다시 게시하려고 다른 계정을 만들지 마세요. 그 자체가 위반으로 처리됩니다.
출처와 데이터 참고
다음에 무엇을 볼지는 이 글을 찾은 이유에 따라 달라집니다. 이 비율을 인용하려면 7.89%를 연도(2025년 활동), 분모(검토된 제출)와 함께 인용하세요. 받은 안내에 대응하려면 결정 표에서 해당 행을 찾아 그 경로를 따르세요. 테스트 요건에서 막혀 있다면 비공개 테스트 요구사항 가이드가 설정 전 과정을 다룹니다.
핵심 정리
2025년 Google Play 제출 거부 비율은 약 7.89%입니다. Google 2025년 연간 투명성 보고서의 거부된 제출 1,692,467건과 검토된 제출 21,461,250건으로 계산한 값입니다. 이는 플랫폼 전체의 과거 수치이지 내 앱의 확률이 아닙니다. 거부 안내에는 구체적인 결정이 적혀 있습니다. 안내가 지적한 것을 수정해 다시 제출하거나 이의신청하고, 신규 개인 계정에 적용되는 테스트 요건은 그와 별개의 준비 단계로 다루세요.
연간 투명성 보고서
연간 안전 결산
업데이트 이력
2026년 2월 28일: 연간 안전 결산 계열만으로 게시했습니다. 2026년 9월 12일: 투명성 보고서 기반 계산과 그 한계를 추가하고, Google의 두 계열을 분리했으며, 결정 표와 검토자 액세스, 데이터 보안, 거부 이후 섹션을 추가하고, 사유를 순위로 제시하던 구성을 없앴습니다. 같은 날 진행한 2차 점검에서 재제출과 기능, 검토 기간에 관한 표현을 바로잡았습니다. 다음 연간 갱신은 Google이 2026년 보고서를 발표하는 시점이며, 2027년으로 예상합니다.