요약

  • 2023년 11월 13일 이후 만든 개인 개발자 계정은 프로덕션 액세스 신청 시점에 최소 12명의 테스터가 직전 14일 동안 계속 비공개 테스트에 참여했어야 한다.
  • 신청 자격을 얻는 일과 출시 승인을 받는 일 사이에는 실제 참여와 개선 내용을 평가하는 심사가 있다. 이 간격을 무시한 출시 약속은 개발자의 현금으로 갚게 된다.

앱보다 먼저 사람을 운영해야 한다

작은 개발팀은 서버 장애에 대비해 여유를 둔다. 그런데 출시를 좌우하는 테스트 명단은 딱 필요한 인원으로 채우기도 한다. 서버에는 예비 자원이 있고, 사람에게는 휴가와 변심과 다른 일이 있다. 최소 인원만 맞춘 일정은 기술적으로 정교한 제품에 붙은 의외로 소박한 약점이다.

Google Play의 공식 규칙은 2023년 11월 13일 이후 생성한 개인 계정을 대상으로 한다. 프로덕션 액세스를 신청하려면 최소 12명의 테스터가 직전 14일 동안 비공개 테스트에 연속 참여해야 한다. 모든 개발자에게 적용되는 보편적 대기 기간은 아니다. 하지만 해당 계정에는 제품을 시장에 내놓기 위한 실제 조건이다.

가령 12명을 정확히 모았는데 13일째에 한 명이 빠졌다고 하자. 이미 기간 조건을 채운 다른 사람이 없다면 신청할 때 자격을 갖춘 참여자가 11명으로 줄 수 있다. 남은 11명의 기록까지 사라지지는 않는다. 나갔다가 다시 들어온 사람은 자신의 연속 14일을 새로 충족해야 한다. 문제는 집단 전체의 시계가 초기화되는 데 있지 않다. 여유 없는 명단에서 한 사람의 선택이 일정의 빈칸이 되는 데 있다.

연속 참여 조건을 매일 앱을 몇 번 실행해야 한다는 규칙으로 바꿔 읽어서도 안 된다. 공식 기준은 참여 상태의 연속 기간이다. 다만 실제로 앱을 써 봤는지는 별도로 심사한다. Google은 어떤 기능을 사용했는지, 사용 방식이 예상 고객과 비슷했는지, 피드백을 어떻게 모았고 무엇을 고쳤는지 묻는다. 참여가 부족하면 테스트를 더 해야 할 수 있다. 이름을 올려 놓은 달력과 제품을 검증한 기록은 다른 서류다.

인원을 줄여도 모집 담당자는 그대로다

처음부터 12명이었던 것은 아니다. 공식 개발자 블로그의 2024년 12월 11일 업데이트는 요구 인원을 20명에서 12명으로 낮췄다. 소규모 이용자층을 겨냥하는 개발자가 20명을 모집하는 데 어려움을 겪었다는 설명도 담았다. 숫자를 낮춘 것은 실질적인 완화다. 그렇다고 플랫폼이 남은 사람을 대신 섭외하는 것은 아니다.

모집에는 두 가지 목표가 섞여 있다. 필요한 수를 채우는 일과 제품을 제대로 평가할 사람을 찾는 일이다. 친구에게 부탁하면 답은 빨리 올 수 있다. 그러나 좁은 직업군을 위한 도구라면 그 친구가 실제 사용 환경을 재현하기는 어렵다. 반대로 적합한 사용자는 바쁘고, 참여를 설득하는 데 더 많은 설명이 필요할 수 있다. 개발자는 기능을 만드는 동시에 작은 사용자 집단을 운영해야 한다.

이 작업은 낭비로 치부할 수 없다. 이해하기 어려운 첫 화면이나 쓸모없는 기능을 광고비 집행 전에 발견하는 것은 제품에 이익이다. 다만 이익이 있다는 사실이 노동 시간을 지워 주지는 않는다. 연락하고, 사용을 독려하고, 질문에 답하고, 의견을 정리하는 일은 프로젝트가 부담한다. 일정표에 '테스트 14일'만 적으면 그 안에 들어가는 사람의 일이 사라져 보인다.

테스터 열두 명이 별점 열두 개는 아니다

테스트 채널 안내에 따르면, 아직 공개 테스트나 프로덕션에 들어가기 전에는 내부·비공개 테스트를 Google Play 검색으로 찾을 수 없다. 개발자가 자격 있는 참여자에게 링크를 전달해야 한다. 거대한 앱 마켓에 들어왔다고 해서 모집에 필요한 유입까지 자동 배달되는 구조는 아니다.

테스트 피드백은 공개 평점에 영향을 주지 않으며, 테스터는 테스트 버전에 공개 리뷰를 남길 수 없다. 모집에 쓴 노력이 제품 개선과 신청 근거로 돌아올 수는 있어도, 그 인원만큼 매장에 공개 추천 글이 쌓이지는 않는다. 모집 비용을 초기 고객 획득비로 기록하면서 같은 수의 공개 후기를 기대하면 마케팅 성과를 너무 일찍 계상하게 된다.

유료 앱에서는 더 섬세한 구분이 필요하다. 공개·비공개 테스트 참여자는 앱을 구매해야 하고, 내부 테스터는 유료 앱을 무료로 설치할 수 있다. 테스트 중 구매도 실제 거래다. 그렇지만 부탁받아 구매한 사람과 스스로 제품을 발견한 고객의 동기와 재사용 가능성은 따로 살펴야 한다. 내부 테스트가 편리하다는 이유로 개인 계정의 필수 비공개 테스트를 대체할 수도 없다. 각 단계의 역할을 섞으면 절약한 것처럼 보이는 시간이 뒤에서 청구된다.

가장 낙관적인 날짜를 팔지 말 것

12명과 14일을 채우면 신청할 수 있다. 자동 출시는 아니다. Google은 프로덕션 액세스 심사가 보통 7일 이내에 끝나지만 더 걸릴 수 있다고 설명한다. 14와 7을 더해 21일 후 출시를 보장하는 것은 계산기의 권한을 과대평가하는 일이다. 계산기는 심사 담당자가 아니다.

제출한 변경 사항의 처리에도 별도의 시간이 필요하다. 게시 관리 문서는 제출부터 실제 공개까지 최소 일주일의 여유를 권하며, 심사 중 새 변경 사항을 제출하면 대기열 뒤로 밀릴 수 있다고 안내한다. 이 심사 시계는 테스터의 연속 참여 기간과 다르다. 코드를 수정할 때마다 모든 사람의 14일이 다시 시작된다는 뜻으로 읽을 근거는 없다.

사용 조건을 충족하면 관리형 게시로 승인된 변경을 보류해 공개 시점을 고를 수 있다. 승인 속도까지 선택할 수는 없고, 최초 게시에는 기능 사용 제한도 있다. 승인 이후의 조정 수단을 승인 이전의 일정 보증서로 팔 수는 없다.

이 차이는 광고와 계약에서 돈이 된다. 되돌리기 어려운 홍보비를 먼저 집행하거나 고객에게 고정 날짜를 약속하면, 개발자는 자신이 통제하지 못하는 참여와 심사를 자기 책임으로 인수한다. 플랫폼은 그 날짜를 약속한 적이 없고, 테스터도 사업 일정을 보증하지 않았다. 코드를 완성한 사람이 결국 달력의 채무자가 되는 순간이다.