구글 플레이 심사에 일주일을 비워 두는 출시 일정표

공개일에서 거꾸로 세면 비는 칸

공개일을 먼저 잡고 거꾸로 세는 일정표에는 개발 기간만 들어가기 쉽다. 만드는 쪽에 물으면 바로 나오는 숫자이기 때문이다. 하지만 앱은 다 만들었다고 바로 열리지 않는다. 구글 플레이 콘솔 도움말은 앱 변경 사항이 게시되기까지 몇 시간에서 최대 7일이 걸리며, 드물게는 그보다 더 걸린다고 적어 두었다. 같은 문서에서는 제출과 공개 사이에 최소 일주일을 두라고 권한다.

2026년 8월과 9월에는 그 드문 경우에 해당하는 대기 사례가 개발자들 사이에서 잇따라 나왔다. 출시일이 정해진 앱을 외주로 맡긴다면 이 대기는 개발 기간과 따로 계산해 칸을 하나 더 만들어야 한다. 개발사를 재촉해도 줄어들지 않는 칸이다.

최대 7일에는 조건이 붙어 있다

구글은 심사 기간을 보장하지 않는다. 앱 게시 도움말에는 사용자 보호를 위해 일부 개발자 계정의 앱을 더 꼼꼼히 검토한다고 적혀 있다. 이때 심사에는 최대 7일이 걸리고, 드물게는 더 길어진다. 이미 출시된 앱의 업데이트도 마찬가지다. 기본값인 표준 게시에서는 업데이트를 가능한 한 빨리 처리하지만, 일부 앱은 확장 검토로 넘어가 같은 기간이 걸린다.

도움말은 새 개발자 계정으로 제출한 앱을 확장 검토 대상이 될 수 있는 예로 든다. 처음 앱을 내는 발주사라면 이 숫자를 상한이 아니라 기본값으로 잡는 편이 안전하다.

8월 17일과 9월 16일에 남은 기록

2026년 8월 17일 구글 플레이 비즈니스 커뮤니티 공식 X 계정은 한 앱 개발자의 문의에 답하면서 지금은 평소보다 심사가 오래 걸리며, 드물게는 7일을 넘길 수도 있다고 밝혔다. 그 답변에 심사가 왜 밀렸는지, 언제 평소대로 돌아오는지는 적혀 있지 않았다.

한 달 뒤인 9월 16일에는 XMPP 메신저 앱 Conversations를 만드는 다니엘 굴치가 콘솔 화면을 올렸다. 9월 9일에 올린 업데이트가 일주일이 지나도록 심사 대기 줄에 그대로 있었다. 굴치는 그 앱이 플레이에 올라온 지 12년이 넘었고 업데이트는 한 달에 한 번뿐이라고 적었다. 심사 대기열이 AI로 찍어낸 저품질 앱으로 막혀 있는 사정은 이해한다고도 썼다. 다만 구글이 원인으로 밝힌 내용은 아니다. 같은 날 해커뉴스에도 이 게시물을 다룬 글타래가 올라왔다.

오래 운영한 앱도 줄을 피하지 못했다. 업데이트 한 번에 일주일이 걸리면 출시 직후 발견한 오류를 고친 버전도 일주일이 지나야 사용자에게 닿는다.

새 개인 계정이면 테스트 14일이 먼저 붙는다

2023년 11월 13일 이후에 만든 개인 개발자 계정은 앱을 공개하기 전에 비공개 테스트를 거쳐야 한다. 프로덕션 액세스를 신청하려면 직전 14일 동안 테스터 12명 이상이 계속 테스트에 참여해야 한다. 신청한 뒤에는 구글이 보통 7일 안에 검토를 끝내지만, 더 걸릴 때도 있다. 테스터가 12명에 못 미치는 등의 사유가 있으면 테스트를 더 이어 가라는 답이 돌아오기도 한다.

날짜로 계산하면 이렇다. 테스트 14일에 액세스 검토 7일을 더하면 3주다. 그다음에 올리는 출시 버전도 앞에서 본 심사를 다시 거친다. 발주사 이름으로 개인 계정을 새로 만들어 앱을 올린다면 이 조건이 그대로 적용된다. 계정을 누가 만들고 누가 갖고 있을지는 개발을 시작하기 전에 정해 둘 항목이다.

승인과 공개를 떼어 놓는 관리형 게시

관리형 게시를 켜면 업데이트는 평소처럼 심사를 받되, 승인된 뒤 언제 공개할지는 개발자가 정한다. 도움말은 광고 캠페인이나 출시 행사 날짜에 맞춰 특정 시각에 업데이트를 내보낼 때 이 기능이 유용하다고 설명한다. 확장 검토 대상인 앱에도 유용하다고 했다. 공개일이 정해져 있으면 심사를 미리 통과한 뒤 그날 버튼만 누르면 된다.

애플은 하루, 구글은 일주일

애플 개발자 사이트는 제출한 앱의 90%가 평균 24시간 안에 심사를 마친다고 적어 두었다. 두 스토어에서 같은 날 앱을 공개하려면 제출일은 심사에 더 오래 걸리는 구글 쪽 일정에 맞춰야 한다. 구글이 8월 17일에 인정한 지연은 9월 16일에도 일주일 대기로 다시 나타났다.

제출일을 언제로 잡을지부터 정합니다

위플의 앱 개발은 첫 대화에서 화면 수보다 날짜를 먼저 묻습니다. 개발자 계정을 누구 이름으로 낼지, 비공개 테스트에 참여할 사람을 어디서 모을지, 관리형 게시를 켜 둘지는 만들기 시작한 뒤 되돌리기 번거로운 결정이기 때문입니다. 범위 문서를 쓰기 전에 심사 칸과 계정 칸부터 달력에 올려 두고, 그 위에서 화면 목록을 짭니다. 작업을 어떤 단위로 세는지는 가격 안내에 적어 두었습니다. 심사가 반려로 돌아왔을 때의 순서는 앱 심사 반려 메일에는 다음에 할 일이 적혀 있다에 따로 적어 두었습니다. 이미 콘솔에 올라가 있는 앱이라면 계정 종류와 마지막 업데이트 날짜, 두 줄만 알려 주셔도 남은 대기를 먼저 셈해 드립니다.