← 노하우 목록

FROM THE WORKSHOP / 노하우

스토어 콘솔의 completed는 공개 완료가 아니다 — 트랙 상태와 사용자 URL을 따로 검증한다

Google Play production 릴리스가 completed여도 지역별 전파나 공개 노출이 끝나지 않아 상세 URL은 404일 수 있다. 업로드·심사·트랙 반영·공개 페이지를 서로 다른 단계로 기록하고, 목표 versionCode의 콘솔 상태와 로그인 없는 사용자 URL이 모두 맞을 때만 공개 출시로 닫아야 한다.

강대종 · 마이너스베타스튜디오

스토어 콘솔의 completed는 공개 완료가 아니다 — 트랙 상태와 사용자 URL을 따로 검증한다

Android 앱의 프로덕션 트랙에 새 버전을 올린 뒤 API를 조회하니 릴리스 상태가 completed였다. 하지만 같은 시각 사용자가 여는 Google Play 상세 주소는 계속 404를 돌려줬다. 콘솔 기준 배포 단계는 끝났지만 스토어 노출은 아직 전파되지 않은 상태였다.

앱 출시는 한 칸짜리 상태가 아니다.

  1. 바이너리 업로드
  2. 심사 제출
  3. 심사 통과
  4. 프로덕션 트랙 반영
  5. 공개 상세 페이지 노출
  6. 검색·지역별 배포 전파

앞 단계가 초록이어도 뒤 단계가 아직일 수 있다. completed를 보고 “출시 완료”라고 쓰면 개발자 계기판만 보고 사용자 현실을 건너뛰게 된다.

두 계기판을 함께 본다

콘솔/API

  • 목표 트랙이 production인지
  • 목표 versionCode가 실제로 들어갔는지
  • 릴리스 status가 무엇인지
  • 관리 게시나 단계적 출시가 남아 있지 않은지

공개 표면

  • 패키지 상세 URL이 HTTP 200인지
  • 국가·언어 파라미터를 붙여도 보이는지
  • 페이지 제목과 앱 이름이 기대값인지
  • 가능하면 로그인하지 않은 브라우저에서도 보이는지

공개 URL이 404라면 재업로드부터 하지 않는다. 이미 production에 같은 versionCode가 있다면 중복 제출은 해결책이 아니다. 상태 전파나 게시 조건을 관찰하고, 콘솔과 공개 표면이 모두 맞을 때 공개 출시로 닫는다.

룰

  • uploaded, in review, completed, public을 보고서에서 구분한다.
  • 공개 판정에는 사용자가 여는 URL과 기대 앱 이름을 근거로 남긴다.
  • API 조회용 임시 edit은 commit하지 않고 삭제한다.
  • 같은 바이너리의 재업로드는 원인 확인 뒤에만 한다.

한 문장으로. 스토어 출시의 진실은 콘솔 상태와 사용자가 받는 공개 페이지가 동시에 맞을 때 완성된다.

기록은 다음 시작이 됩니다.노하우 더 읽기 ↗이 작업장의 제품 ↗
작업장 전체 페이지 목적에 맞는 페이지 찾기