Google Play 출시 트랙 정리: 내부·비공개·공개·프로덕션과 App Store 비교

오늘 성경 지도라는 앱을 App Store와 Google Play 양쪽에 올렸습니다. iOS를 먼저 끝내고 Play Console로 넘어왔는데, 출시 개요 페이지에서 카드 네 장을 보고 잠깐 멈췄습니다.

• 개발자가 관리하는 더 큰 테스터 그룹을 대상으로 앱 테스트 (2/5 완료)
• Google Play에서 누구나 앱 테스트에 등록할 수 있도록 설정 (1/4 완료)
• 사전 등록을 통해 앱에 대한 기대감 높이기
• 버전 생성 및 게시 (3/5 완료)

넷 다 진행률 막대가 붙어 있어서 배포 경로가 네 갈래로 갈라지는 줄 알았습니다. 이 중 하나를 골라야 하나 싶었고, 이미 진행률이 차 있는 게 셋이라 뭘 잘못 건드렸나 싶기도 했습니다.

결론부터 쓰면 제 생각이 틀렸습니다. 넷은 경로가 아니라 관객입니다. 그리고 넷 중 하나는 아예 트랙이 아닙니다.

API에 물어보니 명단이 달랐습니다

콘솔 화면만 보고는 확신이 안 서서 Android Publisher API로 트랙 목록을 직접 조회했습니다.

production   3 (1.0.0) [completed] vc=3
beta         (비어 있음)
alpha        (비어 있음)
internal     1.0.0    [completed] vc=3

네 줄인데 콘솔 카드 넷과 구성이 다릅니다. 세 가지가 눈에 띕니다.

사전 등록이 없습니다. 트랙이 아니기 때문입니다. 출시 전에 스토어 등록정보를 미리 띄워두고 관심 있는 사람의 알림 신청을 받는 홍보 기능이라, 앱 파일이 어디로 가는지와는 상관이 없습니다. 콘솔이 같은 목록에 나란히 놓아서 헷갈렸던 겁니다.

내부 테스트는 카드에 없는데 API에는 있습니다. internal 트랙에 이미 vc=3이 올라가 있습니다. 아까 eas submit으로 보낸 게 여기입니다. 콘솔은 이미 끝난 단계를 출시 개요에서 빼버립니다. 그래서 화면에는 넷만 남았고, 저는 그게 전부인 줄 알았습니다.

이름도 다릅니다. 콘솔의 비공개 테스트가 API에서는 alpha, 공개 테스트가 beta입니다. 초창기 이름이 API에 그대로 굳었습니다. 스크립트를 쓸 때는 콘솔의 한글 이름이 아니라 이쪽을 써야 합니다.

진행률 막대에 대해서도 하나 알게 됐습니다. 카드마다 세부 단계를 세는데 그 단계들이 서로 겹칩니다. 국가 및 지역 선택이나 스토어 등록정보 같은 건 어느 트랙으로 가든 필요한 항목이라, 프로덕션 쪽 작업을 하면 테스트 카드의 숫자도 같이 올라갑니다. 제가 손대지도 않은 비공개 테스트가 2/5였던 이유입니다.

트랙은 넷이고, 순서대로 넓어집니다

트랙	API 이름	받는 사람	심사
내부 테스트	internal	지정한 이메일 최대 100명	사실상 없음
비공개 테스트	alpha	이메일이나 Google 그룹으로 지정	받음
공개 테스트	beta	Play에서 아무나 신청	받음
프로덕션	production	전체 사용자	받음

아래로 갈수록 대상이 넓어집니다. 위에서부터 차례로 밟아야 하는 건 아니고, 내부 테스트만 하고 바로 프로덕션으로 가도 됩니다. 오늘 제가 한 게 그겁니다.

다만 개인 개발자 계정으로 첫 앱을 내는 경우에는 비공개 테스트가 강제되는 정책이 있습니다. 일정 인원을 모아 2주간 연속으로 테스트를 돌려야 프로덕션 신청이 열립니다. 요구 인원은 그동안 몇 차례 조정됐으니 숫자는 콘솔에 표시되는 값을 믿으시는 게 좋습니다. 사업자 계정에는 없는 조건입니다.

파일은 하나입니다

여기가 제일 오해하기 쉬웠습니다. 트랙이 넷이라고 해서 빌드를 네 번 하는 게 아닙니다.

위 조회 결과를 다시 보면 internal과 production 양쪽에 똑같이 vc=3이 들어 있습니다. 그런데 번들 라이브러리에는 파일이 하나뿐입니다.

== 번들 라이브러리 ==
  versionCode 3   sha1 b92ba685

AAB를 한 번 올려두면 트랙은 그 파일을 가리키기만 합니다. 그래서 프로덕션 버전을 만들 때 화면 가운데 크게 그려진 업로드 영역이 아니라, 그 아래 작게 붙어 있는 라이브러리에서 추가를 눌러야 합니다. 같은 파일을 다시 업로드하면 versionCode가 겹쳐서 거부당합니다. 업로드 영역이 워낙 크게 그려져 있어서 저는 그쪽이 정답인 줄 알았습니다.

iOS와 나란히 놓으면

	Google Play	App Store
테스트 배포	트랙 3개 (내부·비공개·공개)	TestFlight (내부·외부)
정식 배포	프로덕션 트랙	App Store
동시 운영	트랙마다 다른 버전 가능	라이브 버전은 하나
단계적 출시	프로덕션에서 비율 지정	7일에 걸친 자동 단계 출시
테스트 빌드 심사	비공개부터 받음	외부 TestFlight만 받음
개인 계정 제약	비공개 테스트 기간 요건	없음

가장 큰 차이는 동시 운영입니다. Play는 프로덕션에 1.0을 서비스하면서 공개 테스트에 1.1을 돌릴 수 있습니다. 서로 다른 사용자 집단이 서로 다른 버전을 쓰고 있는 상태가 정상입니다. App Store에는 그런 개념이 없습니다. 라이브 버전은 항상 하나고, TestFlight 빌드는 스토어에 노출되지 않는 별개 통로입니다.

이게 왜 중요한가 하면, Play에서는 되돌리기가 트랙 단위로 끝납니다. 공개 테스트에서 문제가 터져도 프로덕션은 건드릴 필요가 없습니다. iOS는 새 버전이 나가면 그게 곧 전체 사용자의 버전이라, 문제가 생기면 다음 심사를 기다리거나 이전 버전으로 되돌려 달라고 요청해야 합니다.

두 번째 차이는 테스트 빌드에 심사가 붙는 시점입니다. iOS는 내부 TestFlight에 심사가 없고 외부 테스터를 부를 때부터 심사를 받습니다. Play는 내부 테스트가 그 자리를 대신하고 비공개 테스트부터 심사 대상입니다. 이름만 다를 뿐 경계선이 거의 같은 자리에 있습니다.

completed는 끝났다는 뜻이 아니었습니다

프로덕션 트랙에 vc=3이 completed로 들어갔길래 다 됐구나 싶어 스토어를 열어봤는데 아무것도 없었습니다.

트랙의 completed는 "출시 절차가 끝났다"가 아니라 "이 트랙의 단계적 출시 비율이 100%다"라는 뜻입니다. 10%만 열어두면 inProgress가 되고, 전부 열면 completed가 됩니다. 심사를 통과했는지, 스토어에 게시됐는지와는 별개의 값입니다.

실제로는 앱 콘텐츠 설문이 남아 있었습니다. 개인정보처리방침 URL, 콘텐츠 등급 설문, 데이터 보안 양식, 타겟층, 광고 여부, 앱 액세스 권한. 전부 콘솔에서 사람이 답해야 하고 API로는 넣을 수 없는 항목들입니다. 이걸 끝내야 검토 요청이 나갑니다.

설문을 채우고 나니 그제서야 제출이 묶여서 올라갔습니다. 변경사항 13개가 하나의 제출로 들어갔는데, 프로덕션 버전과 176개 국가 지정, 스토어 등록정보, 콘텐츠 등급, 개인정보처리방침 URL이 전부 한 덩어리입니다. Play는 이렇게 여러 변경을 모아 한 번에 검토합니다. iOS가 앱 버전 하나를 심사 단위로 삼는 것과 다른 지점입니다.

제출 화면에서 웃긴 것도 하나 봤습니다. 타겟 연령대가 만 6~2147483647세로 적혀 있었습니다. 32비트 정수 최댓값을 상한 없음 대신 그대로 찍어놓은 콘솔 표시 버그입니다.

iOS도 같은 시각에 심사 대기 상태입니다. 양쪽 다 남의 손으로 넘어갔으니, 실제 심사가 얼마나 걸렸는지는 결과가 나오면 쓰겠습니다.