"구글 플레이 심사가 일주일을 넘는다" — 개발자 불만이 다시 불붙은 이유 | 뉴스

구글 플레이의 앱 심사 대기 시간이 상시로 일주일을 넘긴다는 개발자들의 문제 제기가 2026년 9월 중순 개발자 커뮤니티에서 다시 확산됐다. 구글은 공식적인 심사 소요 시간을 공지하지 않으며, 업계에서 정리한 2026년 기준 수치는 기존 개발자 1~7일, 첫 앱 제출 7~14일 수준이다.

민감 카테고리(건강·금융·도박·아동·정부 관련) 첫 제출은 14~21일까지 늘어나고, 신규 개발자 계정이거나 과거 삭제 이력이 있으면 더 길어진다는 설명이 일반적이다. 요점은 평균이 아니라 예측 불가능성이다.

심사가 며칠 걸리는지보다 중요한 건, 그게 얼마나 흔들리는지다. 항상 7일이면 계획을 세울 수 있다. 어떤 빌드는 3시간에 통과하고 어떤 빌드는 12일이 걸린다면 계획이 무너진다. 마케팅 일정, 서버 배포, 제휴사 오픈 일정이 전부 심사 큐에 묶인다.

현재 알려진 소요 시간

제출 유형	일반적으로 언급되는 범위
기존 개발자, 일반 업데이트	1~7일
첫 앱 제출	7~14일
민감 카테고리 첫 제출	14~21일
신규 계정·삭제 이력 보유	더 길어질 수 있음

주의 구글은 공식 심사 기간 수치를 발표하지 않는다. 위 수치는 커뮤니티와 업계 정리 자료에서 반복적으로 언급되는 범위이며, 제출 물량과 정책 변화에 따라 달라진다. 어떤 수치도 보장으로 받아들이면 안 된다.

근본 해법 — 출시일을 심사에서 분리한다

심사를 빠르게 만드는 방법은 우리 손에 없다. 통제할 수 있는 건 심사 결과에 대한 의존도다. 원칙은 하나다. 기능이 사용자에게 보이는 시점을 앱 배포가 아니라 서버가 정하게 하라.

피처 플래그를 기본 습관으로

새 기능은 항상 꺼진 상태로 스토어에 올린다. 심사는 미리 통과시켜 두고, 켜는 건 서버 설정으로 한다.

릴리스 트레인 운영

"기능이 준비되면 배포"가 아니라 "2주마다 정해진 날에 배포". 기능이 못 타면 다음 열차를 기다린다.

단계적 출시(staged rollout) 활용

1%→5%→20%→100%로 늘리며 크래시율을 본다. 문제가 생기면 롤아웃을 멈춘다.

긴급 경로 분리

킬스위치와 원격 설정은 앱 배포 없이 동작해야 한다. 이것이 심사 지연에 대한 유일한 실질적 보험이다.

사전 제출 검증 자동화

정책 위반으로 반려되면 대기 시간이 처음부터 다시 시작된다. 권한 선언·개인정보 정책·타깃 API 레벨 체크를 CI에 넣어 둔다.

// 원격 플래그로 기능 노출을 제어하는 최소 형태
data class Flags(val newCheckout: Boolean = false)

// 앱 시작 시 원격 설정을 가져오고, 실패하면 안전한 기본값 유지
val flags = remoteConfig.fetch().getOrDefault(Flags())

if (flags.newCheckout) {
    showNewCheckout()
} else {
    showLegacyCheckout()   // 심사 통과 시점의 안전한 경로
}

// 핵심: 새 코드는 "배포됐지만 꺼져 있다".
// 문제가 생기면 스토어를 거치지 않고 즉시 끌 수 있다.

반려를 줄이는 실무 체크

제출 전 자가 점검

✓타깃 API 레벨이 현재 요구 수준을 충족하는가

✓데이터 안전 섹션이 실제 SDK 동작과 일치하는가 (서드파티 SDK가 수집하는 항목 포함)

✓민감 권한을 선언했다면 그 권한이 핵심 기능에 필요한 이유가 설명돼 있는가

✓심사용 테스트 계정과 재현 절차를 제공했는가 (로그인 벽 뒤 기능은 반드시)

✓스크린샷·설명이 실제 기능과 일치하는가

✓정책이 바뀐 카테고리(결제·구독·아동·AI 생성 콘텐츠 등)에 해당하는지 최신 정책 문서로 확인

네 번째 항목에서 반려되는 사례가 의외로 많다. 심사자가 기능에 도달하지 못하면 심사가 진행되지 않고, 그 왕복에 며칠이 사라진다.

맥락 — 심사 부담은 양쪽에서 커지고 있다

앱 제출 물량은 계속 늘고, 정책은 매년 복잡해진다. 애플 쪽에서도 2026년 9월부터 신규 제출·업데이트와 공증 제출에 추가 응답이 요구되기 시작했다. 플랫폼 입장에서는 품질과 안전 관리를 강화하는 조치지만, 개발팀에게는 배포 리드타임이 길어지는 변화다.

이 흐름은 되돌아가지 않을 가능성이 높다. 그러면 답은 하나뿐이다. 배포 주기를 늘리는 대신, 배포 없이 바꿀 수 있는 것의 범위를 늘리는 것.

출처

Google Play Developer Community, 앱 심사 시간 관련 논의 스레드 — https://support.google.com/googleplay/android-developer/community-guide/244499850/app-review-time?hl=en
Aerious, "Google Play Review Time in 2026: Real Timelines and How to Avoid Delays" — https://aerious.uk/blog/google-play-review-time-in-2026-real-timelines-and-how-to-avoid-delays
inTesters, "Why Your Google Play Store App Review Is Taking So Long" — https://intesters.com/blog/why-your-google-play-store-app-review-is-taking-so-long-and-how-to-fix-it

자주 묻는 질문

구글 플레이 심사는 보통 얼마나 걸리나요?

구글은 공식 수치를 공지하지 않습니다. 업계 정리 자료 기준으로 기존 개발자의 일반 업데이트는 1~7일, 첫 앱 제출은 7~14일, 민감 카테고리 첫 제출은 14~21일 범위가 자주 언급됩니다. 제출 물량과 정책 상황에 따라 달라집니다.

심사가 오래 걸리는 이유는 무엇인가요?

신규 개발자 계정, 민감 카테고리, 과거 정책 위반 이력, 데이터 안전 섹션과 실제 동작의 불일치 등이 대표적입니다. 심사자가 기능에 접근하지 못하는 경우(테스트 계정 미제공)도 흔한 지연 원인입니다.

출시일을 지키려면 어떻게 해야 하나요?

기능 노출을 앱 배포가 아니라 서버 설정으로 제어하세요. 기능을 꺼진 상태로 미리 제출해 심사를 통과시켜 두고, 출시일에 원격으로 켜면 심사 일정과 마케팅 일정을 분리할 수 있습니다.

단계적 출시는 어떻게 활용하나요?

1~5%로 시작해 크래시프리율과 주요 지표를 확인한 뒤 비율을 올리는 방식입니다. 문제가 발견되면 롤아웃을 중단하고 이전 버전 비중을 유지할 수 있어, 전면 배포보다 회복 비용이 훨씬 낮습니다.

반려를 줄이는 가장 효과적인 방법은 무엇인가요?

데이터 안전 선언을 실제 SDK 동작과 일치시키고, 심사용 테스트 계정과 재현 절차를 명확히 제공하는 것입니다. 이 두 가지만 챙겨도 왕복 반려로 날리는 시간이 크게 줄어듭니다.