FROM THE WORKSHOP / 노하우
스토어 콘솔의 completed는 공개 완료가 아니다 — 트랙 상태와 사용자 URL을 따로 검증한다
Google Play production 릴리스가 completed여도 지역별 전파나 공개 노출이 끝나지 않아 상세 URL은 404일 수 있다. 업로드·심사·트랙 반영·공개 페이지를 서로 다른 단계로 기록하고, 목표 versionCode의 콘솔 상태와 로그인 없는 사용자 URL이 모두 맞을 때만 공개 출시로 닫아야 한다.
스토어 콘솔의 completed는 공개 완료가 아니다 — 트랙 상태와 사용자 URL을 따로 검증한다
Android 앱의 프로덕션 트랙에 새 버전을 올린 뒤 API를 조회하니 릴리스 상태가 completed였다. 하지만 같은 시각 사용자가 여는 Google Play 상세 주소는 계속 404를 돌려줬다. 콘솔 기준 배포 단계는 끝났지만 스토어 노출은 아직 전파되지 않은 상태였다.
앱 출시는 한 칸짜리 상태가 아니다.
- 바이너리 업로드
- 심사 제출
- 심사 통과
- 프로덕션 트랙 반영
- 공개 상세 페이지 노출
- 검색·지역별 배포 전파
앞 단계가 초록이어도 뒤 단계가 아직일 수 있다. completed를 보고 “출시 완료”라고 쓰면 개발자 계기판만 보고 사용자 현실을 건너뛰게 된다.
두 계기판을 함께 본다
콘솔/API
- 목표 트랙이 production인지
- 목표 versionCode가 실제로 들어갔는지
- 릴리스 status가 무엇인지
- 관리 게시나 단계적 출시가 남아 있지 않은지
공개 표면
- 패키지 상세 URL이 HTTP 200인지
- 국가·언어 파라미터를 붙여도 보이는지
- 페이지 제목과 앱 이름이 기대값인지
- 가능하면 로그인하지 않은 브라우저에서도 보이는지
공개 URL이 404라면 재업로드부터 하지 않는다. 이미 production에 같은 versionCode가 있다면 중복 제출은 해결책이 아니다. 상태 전파나 게시 조건을 관찰하고, 콘솔과 공개 표면이 모두 맞을 때 공개 출시로 닫는다.
룰
uploaded,in review,completed,public을 보고서에서 구분한다.- 공개 판정에는 사용자가 여는 URL과 기대 앱 이름을 근거로 남긴다.
- API 조회용 임시 edit은 commit하지 않고 삭제한다.
- 같은 바이너리의 재업로드는 원인 확인 뒤에만 한다.
한 문장으로. 스토어 출시의 진실은 콘솔 상태와 사용자가 받는 공개 페이지가 동시에 맞을 때 완성된다.