Google Play에서 Broken Functionality로 앱이 거부되었나요? 의미와 해결 방법 (2026)

2026년 10월 16일 기준 최신 정보입니다. 이 페이지의 모든 규칙은 해당 날짜에 Google Play 정책 페이지와 Play Console 고객센터에서 확인했으며, 각 규칙이 쓰인 곳에 출처를 링크했습니다. 아래에 인용한 개발자 사례는 2026년에 개발자들이 실제로 본 내용을 보여 주는 증거일 뿐 Google이 그 앱들을 진단한 결과가 아니며, 이를 뒷받침하는 공개 데이터가 없으므로 원인의 순위는 제시하지 않습니다.

이 글은 Broken Functionality 정책에 따른 버전 거부를 다룹니다. 비공개 테스트 후 Google이 프로덕션 액세스를 거절했거나 추가 테스트가 필요하다고 안내했다면, 그것은 해결 방법이 다른 별개의 결정입니다. 이 경우에는 Google Play에서 추가 테스트가 필요하다고 할 때 해야 할 일과 비공개 테스트 신청이 거부되는 이유를 읽어 보세요.

Google Play에서 Broken Functionality는 무엇을 의미합니까?

Google은 이 문장 아래에 흔한 위반 사례 세 가지를 듭니다. 설치되지 않는 앱, 설치되지만 로드되지 않는 앱, 로드되지만 응답하지 않는 앱입니다. 이를 살펴볼 세 지점으로 읽으세요. 검토자가 빌드를 설치하지 못했든, 빈 화면이나 끝나지 않는 로딩 화면을 봤든, 컨트롤을 탭했는데 아무 일도 일어나지 않았든, 모두 같은 알림으로 이어질 수 있습니다.

예전 고객센터 링크나 포럼 글에서는 아직 최소 기능(Minimum Functionality)이라는 이름을 볼 수 있습니다. 현재 정책 섹션의 이름은 제한된 기능 및 콘텐츠(Limited Functionality and Content)이며, 정적인 텍스트나 PDF 앱, 콘텐츠가 매우 적은 앱, 아무 기능도 하지 않도록 설계된 앱을 다룹니다. 알림은 두 섹션 중 어느 것이든 사유로 들 수 있고 해결 방법이 다르므로, 무엇이든 바꾸기 전에 알림이 어느 섹션을 지목하는지 먼저 읽으세요.

서로 혼동되는 네 가지 결정

Google은 무엇이 고장 났는지 어디에서 보여 줍니까?

Play Console을 열고 앱을 선택한 뒤 정책 상태 페이지를 여세요. 코드를 건드리기 전에 네 가지를 적어 두세요. 지목된 정책 섹션, 검토된 버전 코드와 트랙, 날짜, 첨부된 증거입니다. 이메일과 Play Console 알림도 함께 확인하세요. 버전이 어떤 정책을 위반했는지 Google이 밝히는 곳이 바로 그곳입니다.

2026년 알림의 실제 모습

모든 사람이 받는 단일한 Broken Functionality 이메일은 없으며, 특정 문구를 정확한 템플릿처럼 싣는 페이지는 추측하고 있는 것입니다. 2026년에 알림을 공개적으로 올린 개발자들은 서로 매우 다른 수준의 상세 정보를 설명합니다.

• "Broken Functionality: Unresponsive UI elements"(응답하지 않는 UI 요소)라는 알림 라벨. 첫 데이터 동기화 중 앱에 오프라인 재시도 화면이 표시되던 개발자가 2026년 9월 2일에 올린 사례입니다(Play Console 고객센터 커뮤니티).
• "For example, your app does not open or load."(예를 들어 앱이 열리거나 로드되지 않습니다)라는 검토자 예시. 타이틀 화면은 정상적으로 로드되던 게임 개발자가 2026년 6월에 인용한 사례입니다. 작성자는 이후 Android 뒤로 버튼으로 게임을 종료하는 방식을 바꾼 뒤 게임이 게시되었다고 전했습니다.
• 한 개발자가 2026년 8월에 다른 내용 없이 "Broken functionality"라는 두 단어뿐이었다고 설명한 알림.

이것은 개발자가 옮겨 적은 발췌문이지 진위가 확인된 Google 이메일이 아니며, 각각 하나의 사례일 뿐입니다. 받을 수 있는 상세 정보의 범위를 보여 줄 뿐, 여러분의 알림에 무엇이 적힐지나 앱이 왜 실패했는지를 알려 주지는 않습니다.

Broken Functionality 거부 후 무엇을 먼저 확인해야 합니까?

순서대로 확인할 5가지

Google 검토자에게 로그인 정보를 어떻게 제공합니까?

안내 추가 또는 업데이트하기

1. Play Console을 열고 앱 콘텐츠 페이지(정책 및 프로그램 > 앱 콘텐츠)로 이동합니다.
2. Sign-in details에서 시작(Start)을 선택하거나, 이전에 안내를 추가했다면 관리(Manage)를 선택합니다.
3. + Add new instructions(새 안내 추가)를 선택하고 액세스 정보를 입력합니다. 일회성 비밀번호, 다단계 인증, 입력란이 세 개 이상인 로그인처럼 특이한 내용은 Any other instructions(기타 안내) 입력란을 사용하세요.
4. 변경사항을 저장합니다. 안내는 최대 다섯 세트까지 추가할 수 있습니다.
5. 게시 개요(Publishing overview)로 이동해 Changes ready to send for review(검토를 위해 전송할 준비가 된 변경사항)에서 해당 변경사항을 찾은 뒤 Send for review(검토를 위해 전송)를 선택합니다. 저장만으로는 아무것도 제출되지 않습니다.

유효한 액세스로 인정되는 것

Google의 Play Console 요구사항은 "Google Play에서 앱을 검토하는 데 필요한 활성 데모 계정, 로그인 정보 및 기타 모든 리소스를 제공"하도록 요구합니다. Google의 로그인 세부정보 요구사항은 그것이 무엇을 의미하는지 구체적으로 설명합니다.

• 일회용 초대나 검토 도중 만료되는 체험판이 아니라, 활성 상태이며 반복해서 쓸 수 있는 계정.
• 일회성 코드와 2단계 인증을 통과할 수 있는 자격 증명. 검토자는 여러분이 휴대전화나 받은편지함으로 보내는 코드를 받을 수 없기 때문입니다.
• 앱이 지역별로 제한한다면 어느 위치에서든 작동하는 액세스, 그리고 검토자가 확인해야 하는 유료 또는 제한된 기능에 요금 청구 없이 접근할 수 있는 전체 액세스.
• 영어로 작성되고 최신 상태로 유지되는 정보. 비밀번호를 바꾸거나 테스트 계정을 삭제했다면 같은 날 Sign-in details를 업데이트하세요.
• QR 코드나 바코드처럼 텍스트가 아닌 것이 로그인에 필요하다면, 이를 위한 고정 URL을 생성해 Sign-in details에 추가하세요. 앱이 사용자에게 직접 PIN을 설정하게 하거나 소셜 로그인을 쓴다면, 검토자가 어떻게 통과하는지 안내에 설명하세요.

앱이 내 휴대전화에서는 작동하고 Google이 스크린샷을 보내지 않았다면?

사전 출시 보고서

테스트 및 출시 > 테스트 > 사전 출시 보고서에서 찾을 수 있습니다. Google은 앱 번들이나 APK를 업로드하면 처리 용량이 허락하는 한도 내에서 테스트 기기로 앱을 실행해 이 보고서를 자동으로 생성합니다. 크롤링이 실제로 어느 화면까지 도달했는지 확인하세요. 로그인 화면에서 멈췄다면 앱의 나머지 부분은 전혀 보지 못한 것입니다. Google은 알아 둘 만한 한계를 덧붙입니다. "사용자 인증 정보는 표준 Android 위젯을 사용하는 Android 앱에만 자동으로 입력할 수 있습니다."(사전 출시 보고서를 사용하여 문제 파악하기). 문제없는 보고서는 증거일 뿐 통과가 아닙니다. Google은 사전 검토 확인에 대해서도 같은 말을 합니다. "모든 사전 검토 확인을 통과하더라도 정식 앱 검토 절차를 통과한다는 보장은 없습니다".

Android vitals

모니터링 및 개선 > Android vitals > 비정상 종료 및 ANR에서 찾을 수 있습니다. Google은 사용 현황 및 진단 데이터 공유에 동의한 사용자에게서만 이 데이터를 수집하므로(Android vitals로 기술 품질 모니터링하기), 소규모 테스트 중인 새 앱에는 아무것도 표시되지 않을 수 있습니다. vitals 페이지가 비어 있다고 해서 앱이 한 번도 비정상 종료되지 않았다는 증거가 되지는 않습니다.

실기기를 쓰는 실제 사람들

비공개 테스트는 공개 출시 전에 바로 이런 문제를 찾기 위해 존재합니다. 다양한 휴대전화, Android 버전, 네트워크를 쓰는 테스터는 검토자가 도달하는 화면에 도달하며, 그들의 의견은 어디에서 문제가 생기는지 알려 줍니다. 이는 결함을 찾고 고치는 데 도움이 될 뿐, Google이 앱을 검토하는 방식을 바꾸지는 않습니다. 트랙 자체의 기본 사항이 필요하다면 Google Play 비공개 테스트의 작동 방식을 참고하세요.

수정 후 재제출해야 합니까, 이의를 제기해야 합니까?

수정된 버전 다시 제출하기

Google의 재제출 단계는 새 버전 코드를 업로드하는 것 이상입니다.

1. 이메일과 알림에 적힌 정책을 읽고, 다른 정책에 대해서도 앱을 점검하세요. Google은 추가 위반이 추가 조치로 이어질 수 있다고 경고합니다.
2. 프로덕션뿐 아니라 영향을 받은 버전이 포함된 모든 출시 유형을 업데이트하세요. 공개, 비공개, 내부 테스트 트랙도 포함됩니다.
3. 수정된 앱 번들을 업로드하고 정책을 위반하는 번들을 비활성화하세요. Google은 이를 비활성화하지 않으면 재제출이 실패하고 게시된 버전이 삭제될 수 있다고 경고합니다.
4. 영향을 받은 각 트랙에서 트랙 관리(Manage track)와 새 버전 만들기(Create new release)를 선택하고, 수정된 번들을 추가한 뒤(또는 위반 번들이 들어 있는 초안을 삭제한 뒤), 정책을 위반하는 버전이 포함되지 않음(Not included) 아래에 표시되는지 확인하세요.
5. 저장하고 버전 검토(Review release)를 선택한 뒤 출시하세요.

그 후 변경사항은 처리를 기다립니다. Google은 이렇게 말합니다. "처리에는 몇 시간에서 최대 7일이 걸릴 수 있습니다(예외적인 경우 더 오래 걸릴 수 있음)"(앱 변경사항의 검토 및 게시 시기 관리하기).

수정했는데 경고가 여전히 남아 있을 때

수정된 버전이 게시되었는데도 정책 상태에 여전히 문제가 표시된다면, 경고가 지목한 버전 코드와 트랙을 현재 활성 상태인 것과 비교하세요. 테스트 트랙에 남아 있는 정책 위반 번들이 가장 먼저 배제해야 할 원인입니다. 새 버전이 모든 조치 항목을 자동으로 해제하지는 않습니다. 모든 것이 일치한다면 버전 코드, 영향을 받은 트랙, 이전 사례 참조 번호가 있다면 그것까지 갖춰 Play Console 지원팀에 문의하세요.

결정에 이의 제기하기

Google은 자체 오류가 있었고 앱이 정책을 위반하지 않는다고 판단되면 앱을 복원합니다. 이의를 제기하려면 조치 안내 이메일의 안내를 따르거나 Google의 이의 제기 양식을 사용하세요. 이의 제기는 조치 1건당 한 번 제출할 수 있으며(정책 위반 및 이의 제기 관리하기), Google은 중국어, 영어, 일본어, 한국어로 이의 제기에 답변합니다. Google은 이의 제기 응답 기간을 공개하지 않으며, 개발자 사례에서도 이의 제기 답변과 이후의 버전 검토가 뒤섞여 있으므로 날짜를 정하지 말고 계획하세요.

이의 제기는 불만이 아니라 증거로 작성하세요. 검토된 버전 코드, 테스트한 기기와 Android 버전, 정확한 재현 단계, 알림이 지목한 흐름의 화면 녹화, 그리고 변경한 내용이 있다면 그 내용을 담으세요.

Broken Functionality 거부가 계정이나 비공개 테스트에 불이익을 줍니까?

Google의 정책 시행 절차 페이지는 그 차이를 다음과 같이 설명합니다.

• "거부는 Google Play 개발자 계정의 상태에 영향을 주지 않습니다."
• "기존 앱의 업데이트가 거부된 경우, 업데이트 이전에 게시된 앱 버전은 Google Play에서 계속 제공됩니다."
• "정지는 심각하거나 여러 건의 정책 위반뿐 아니라 반복적인 앱 거부 또는 삭제로 인해서도 발생할 수 있습니다."

Google은 안전한 거부 횟수를 공개하지 않습니다. 같은 실패를 다시 제출하는 것이 바로 세 번째 문장이 설명하는 패턴입니다.

그렇다면 14일 비공개 테스트는?

Google의 테스트 요구사항은 2023년 11월 13일 이후 생성된 개인 개발자 계정에 대해, 프로덕션 액세스를 신청하기 전에 최근 14일 이상 지속적으로 테스트에 참여하겠다고 선택한 12명 이상의 테스터를 요구합니다. 비공개 트랙 버전이 정책 거부를 받았을 때 이 기간이 초기화되는지, 일시 중지되는지, 유지되는지는 밝히지 않으며, 어느 쪽이든 포럼의 주장은 추측입니다. 확인할 수 있는 것은 테스터에게 아직 해당 트랙의 승인된 버전이 있는지, 그리고 대시보드가 프로덕션 액세스에 대해 무엇을 보여 주는지입니다. 수정하는 동안 테스터의 테스트 참여를 유지하고, 대시보드가 바뀌면 Play Console 지원팀에 본인 사례를 문의하세요. 규칙 자체는 14일 연속의 의미에서 설명합니다.

Google은 WebView나 TWA 앱을 고장 난 앱으로 거부합니까?

웹 기반 앱의 Broken Functionality 확인 항목은 다른 앱과 같습니다. 새로 설치한 상태에서 앱 안에 사이트가 로드되어야 하고, 오프라인 상태와 오류 상태는 스스로 상황을 설명해야 하며, 모든 링크는 어딘가로 이어져야 합니다. 앱이 대부분 웹사이트를 얇게 보여 주는 화면이라면 제한된 기능 및 콘텐츠 섹션이 더 큰 위험입니다. TWA에서 WebView로, 또는 그 반대로 바꾸는 것만으로 거부가 해결된다는 사실은 확인된 바 없습니다.

PrimeTestLab은 다음 검토 전에 어떻게 도움이 됩니까?

PrimeTestLab은 Android 7부터 17까지를 아우르는 실기기를 쓰는 실제 테스터 12명 이상을 제공하며, 테스터는 14일 내내 테스트 참여를 유지하고 테스트는 4~6시간 안에 시작됩니다. 저희는 12,100+개 앱의 관리형 테스트를 진행했으며, 테스터는 120+개국에 있습니다.

직접 하는 테스트와 관리형 테스트

PrimeTestLab 테스트를 끝까지 마친 뒤에도 Google이 프로덕션 액세스를 허용하지 않으면, 무료 재테스트 또는 전액 환불 중에서 선택할 수 있습니다. 환불 및 무료 재테스트 정책을 참고하세요. 이는 테스트 요구사항에 대한 것이며, 코드에 대한 정책 거부는 해당되지 않습니다. 요금제는 $19.99부터 시작하며 결제 시 서비스 수수료 5%가 추가되고(최소 $1.50), Google의 일회성 등록 수수료(미화 25달러)는 별도입니다. 요금제는 가격 페이지에서 비교하세요.

자주 묻는 질문

핵심 정리

다음 검토자보다 먼저 실기기를 쓰는 실제 사람들이 고장 난 화면을 찾아 주길 원한다면, 여러분이 앱을 수정하는 동안 PrimeTestLab이 비공개 테스트 쪽을 맡습니다.