Google Play 내부 테스트 설정 방법 (2026)

개발자가 소프트웨어에 대해 당연하게 기대하는 방식 그대로 움직여 주는 Play Console 트랙은 내부 테스트 하나뿐입니다. 빌드를 올리면 나타나고, 사람들이 설치합니다. 그러다 어느 순간 그렇게 되지 않습니다. 그때부터는 이 계정에서 앱을 사용할 수 없다는 Play Store 화면만 띄우는 링크를 들여다보게 됩니다. 오류 코드도 없고 진단 정보도 없으며, 도움말 문서는 수백 줄에 걸쳐 세 가지 테스트 트랙을 뒤섞어 설명합니다. 이 글은 내부 트랙을 나머지 둘과 분리하고, 실제로 필요한 순서대로 콘솔 경로와 테스터 목록 규칙을 정리한 다음, 지원 게시판을 가득 채우는 실패 유형에 충분한 분량을 씁니다. Google 문서끼리 서로 어긋나는 지점, 특히 소요 시간에서는 분명히 그런데, 편한 쪽만 고르지 않고 두 해석을 모두 보여 드립니다. 여기 실린 내용은 모두 2026년 8월 12일 기준입니다.

내부 테스트는 어떻게 설정하나요?

시작하기 전에

앱과 빌드, 테스터 계정, 그리고 본인의 Play Console 권한을 준비하세요. 필요하지 않은 것도 눈여겨보세요. 완성된 스토어 등록정보, 스크린샷, 콘텐츠 등급, 작성이 끝난 데이터 보안 양식은 필요 없습니다. Google은 앱 설정을 모두 마치기 전에도 내부 테스트를 진행할 수 있다고 명시합니다. 문서 확인

• 01
  Play Console에 만들어져 있는 앱 내용을 다 채울 필요는 없고 생성만 되어 있으면 됩니다. 처음 업로드하는 아티팩트가 그 앱의 패키지 이름을 확정하고 이후에는 바꿀 수 없으므로, applicationId가 계속 쓸 값이 맞는지 확인하세요.
• 02
  유효한 앱 번들 Google의 표현은 「유효한 앱 번들」입니다. 초기 내부 빌드를 테스터에게 전달하는 데 필요한 아티팩트 조건은 이것뿐입니다.
• 03
  테스터 이메일 주소 Google 계정이어야 합니다. 현재 도움말은 Gmail을 쓰는 Google 계정 또는 Google Workspace 계정을 명시합니다. 각자 로그인할 정확한 주소를 받아 두세요. 트랙 전체가 그 신원을 기준으로 돌아가기 때문입니다.
• 04
  이 작업을 할 Play Console 권한 소유자와 관리자는 이미 가지고 있습니다. 권한을 위임받은 사용자는 테스트 트랙에 앱을 출시할 권한이 필요하고, 트랙과 테스터 목록을 관리하려면 테스트 트랙 관리 및 테스터 목록 수정이라는 별도 권한이 필요할 수 있습니다. 출시 버튼이 없거나 비활성화되어 있다면 빌드 문제가 아니라 권한 문제입니다.
• 05
  첫 출시에만 나오는 Play 앱 서명 앱의 첫 출시에서는 Play Console이 Play 앱 서명 설정을 안내합니다. 미리 준비해 둘 일이라기보다 업로드 도중에 만나게 되는 일회성 단계지만, 시작하기 전에 이런 단계가 온다는 것은 알아 두시는 편이 좋습니다.

1단계: 내부 테스트 트랙 열기

앱을 선택한 다음 Test and release › Testing › Internal testing으로 이동합니다. Google은 이 경로를 두 가지로 문서화합니다. 테스트 설정을 다루는 Play Console 도움말 문서는 Testing › Internal testing으로 줄여 적고, 다른 현행 도움말 페이지는 상위 메뉴까지 전부 보여 줍니다. 둘 다 같은 곳을 가리키므로, 사용 중인 콘솔의 메뉴가 여기 적힌 것보다 짧더라도 잘못 찾아온 것이 아닙니다.

2단계: 내부 테스터 목록 만들기

내부 테스트 트랙에서 테스터 탭을 열고 이메일 목록 만들기를 선택합니다. 목록 이름을 정하고 주소를 넣은 뒤 변경사항을 저장하고 목록을 생성합니다. 주소는 쉼표로 구분해 화면에 직접 입력해도 되고 CSV로 업로드해도 됩니다. 목록이 소리 없이 날아가는 곳이 바로 CSV 쪽인데, 한 번만 문서화되고 다시는 언급되지 않는 규칙 세 가지가 붙어 있기 때문입니다.

테스터 목록 검사기

3단계: 목록과 의견 채널 추가하기

다시 테스터 탭에서 이 트랙에 사용할 사용자 목록을 선택한 다음, 의견을 받을 URL이나 이메일 주소를 Google에 알려 줍니다. 이 주소는 테스트 참여 페이지에서 테스터에게 표시되므로, 무언가 잘못됐다고 알려 줄 수 있는 유일한 기본 경로가 됩니다.

4단계: 출시 버전 만들고 출시하기

새 버전 만들기를 선택해 앱 번들을 추가하고, 검토한 뒤 현재 콘솔 화면대로 출시합니다. Play Console은 버전에 따라 버튼 문구가 제법 달라서, 여기서 더 나아간 클릭 순서를 외우는 것은 도움이 아니라 부담이 됩니다. 그래서 이 안내도 Google의 현행 문서가 멈추는 지점에서 멈춥니다.

5단계: 테스트 참여 링크 복사해 공유하기

공유 가능한 테스터 링크를 복사해 보내세요. 적어도 2018년부터 개발자들을 헷갈리게 해 온 단계이고, 그 혼란은 충분히 이해할 만합니다. 인터넷의 다른 모든 초대 시스템은 이메일을 보내는데, Google이 문서화한 절차는 대신 배포할 링크를 손에 쥐여 주기 때문입니다. Play Console이 알아서 테스터를 초대해 주리라고 기대하지 마세요.

그 링크가 존재하는지 자체를 두 조건이 좌우합니다. 테스트 참여 링크는 앱 상태가 게시됨일 때만 표시됩니다. 앱이 Draft나 Pending publication에 머물러 있는 동안에는 복사할 것이 없고, 테스터 탭을 몇 번을 다시 읽어도 링크는 나타나지 않습니다. 문서 확인

6단계: 테스터가 참여하고 설치하기

마지막 단계는 테스터의 몫이고, 개발자가 대신해 줄 수 없는 유일한 단계입니다. 각자 추가된 바로 그 계정으로 로그인한 상태에서 링크를 열고, 그 페이지에서 참여를 마친 다음, Play Store 링크를 따라가 설치합니다. 그 전까지는 자격만 있고 등록은 되지 않은 상태이며, 자격만 있는 테스터는 아무것도 받지 못합니다. 링크를 보내실 때 초대한 계정 이름을 옆에 적어 주세요. 엉뚱한 신원으로 참여하는 것이 이 과정에서 가장 자주 보고되는 실패이고, 겉모습은 링크가 고장 난 것과 똑같기 때문입니다.

누가 무엇을 하나

전체 순서를 한 표로

표를 옆으로 밀어 모든 열을 확인하세요

테스터가 설치하기까지 얼마나 걸리나요?

내부 테스트 중에는 서로 다른 시계 다섯 개가 동시에 돌아가는데, 시간이 오래 걸린다는 불만은 대개 엉뚱한 둘을 비교한 데서 나옵니다. 빌드가 Google의 배포 시스템에 도달하는 것이 하나입니다. 테스터가 여는 테스트 참여 링크가 살아나는 것이 둘입니다. 게시한 변경사항이 이미 참여한 사람들에게 도달하는 것이 셋입니다. 설치된 앱이 자동 업데이트되는 것이 넷입니다. 그리고 임시 스토어 등록정보가 실제 앱 이름으로 바뀌는 것이 다섯인데, 멀쩡히 동작하는 내부 빌드가 며칠 동안 미완성처럼 보이는 이유가 바로 이것입니다.

지금 기다리는 시간이 정상인가요?

그 질문이 쓸모 있으려면 무엇을 기다리는지가 함께 들어가야 합니다. 단계에 따라 답이 수백 배 차이 나기 때문입니다. 아래 도구는 두 가지를 함께 묻고, 그 단계에 대해 Google이 실제로 밝힌 내용을 인용하며, 자체 수치 기준선은 Google의 것이 아니라 이 글의 해석이라고 분명히 표시합니다.

반영 시간 계산기

모든 시계를 나란히

표를 옆으로 밀어 모든 열을 확인하세요

여기서 챙겨 가실 요점은 이렇습니다. 몇 초, 몇 분, 몇 시간, 최대 48시간은 같은 파이프라인의 서로 다른 조각을 설명하기 때문에 동시에 모두 참입니다. 이것들을 숫자 하나로 뭉뚱그리는 글은 하필 정확성이 가장 필요한 순간에 누군가를 잘못 이끌게 됩니다. 문서 확인

내부 출시도 Google 검토를 기다리나요?

여기서는 표현을 조심해야 합니다. Google의 두 출처가 같은 방식으로 적고 있지 않기 때문입니다. 내부 테스트를 소개하는 Google 제품 페이지는 앱 검토를 기다릴 필요 없이 빌드를 배포하는 방법이라고 홍보합니다. Play Console 도움말은 더 부드러워서, 내부 테스트가 일반적인 Play 정책 및 보안 검토의 대상이 아닐 수 있다고 적습니다.

그러니 정확한 설명은 내부 테스트가 보통 일반 앱 검토 절차를 기다리지 않고 배포하게 해 준다는 것이고, 부정확한 설명은 내부 출시가 절대 검토되지 않는다는 것입니다. Google은 모든 검토에서 예외라고 약속한 적이 없으며, 그렇게 썼다가는 누군가의 내부 출시가 보류되는 순간 그 글이 틀린 글이 됩니다. 문서 확인, 표현에 단서 있음

내부 테스트가 테스터 12명 요건에 포함되나요?

이 주제 전체에서 결과가 가장 무거운 오해이고, 지금도 활발히 퍼지고 있습니다. 널리 도는 2026년 글 가운데 최소 한 편은 이 필수 요구사항을 내부 테스트 트랙에서 채울 수 있는 것처럼 설명합니다. Google의 요구사항 페이지는 해석의 여지가 없는 표현으로 그 반대를 말합니다.

한 줄로 정리한 판단 기준

믿을 만한 사람들과 빠르게 비공개 QA를 하고 싶으면 내부 테스트를, 프로덕션 전 필수 테스트가 필요하면 비공개 테스트를 쓰세요. 규칙은 이것이 전부이고, 이 글이 두 트랙 비교에 관해 하는 말도 여기까지가 전부입니다. 세 트랙의 전체 비교는 그 질문을 위해 따로 쓴 내부 vs 비공개 vs 공개 테스트에 있습니다.

표를 옆으로 밀어 모든 열을 확인하세요

이 요구사항이 실제로 적용되는 대상

요구사항에는 적용 범위가 있고, 혼란의 대부분이 바로 그 범위에서 생깁니다. Google 문서는 2023년 11월 13일 이후에 만들어진 대상 개인 개발자 계정을 기준으로 이를 설명합니다. Google이 정책을 발표한 날은 2023년 11월 9일이라, 두 날짜가 모두 시작일로 인용되는 것을 보시게 됩니다.

조직 계정에 관해서는 표현을 조심하셔야 합니다. Google의 요구사항 페이지는 이 규칙의 범위를 개인 계정으로 한정할 뿐, 조직 계정이 면제된다고 밝힌 문장은 담고 있지 않습니다. 방어 가능한 표현은, 이 요구사항이 대상 개인 개발자 계정에 대해 문서화되어 있으며 인용한 페이지가 조직 계정에 그것을 부과하지는 않는다는 것입니다. 적용 범위 추론

14일 참여와 14일 사용은 다릅니다

수치 기준은 테스터가 지속적으로 참여한 상태인지로 적혀 있지, 매일 얼마나 썼는지로 적혀 있지 않습니다. 측정 가능한 부분은 그쪽입니다. 그와 별개로 Google은 프로덕션 액세스를 신청할 때 개발자가 테스트에 대해 보고한 내용을 평가하고, 테스터 수나 참여도가 부족하면 테스트를 더 요구할 수 있습니다. 경쟁 페이지들은 이 두 가지를 하루 사용 시간에 관한 지어낸 규칙 하나로 뭉개곤 합니다.

정리하면, 기준선은 참여의 지속성이고 참여도는 그것을 대신하는 것이 아니라 그 위에 얹혀 평가됩니다. 진행 중인 테스트에서 이것이 실제로 어떤 의미인지는 14일 연속의 기준과 테스터 12명 요구사항 완전 정리에서 다룹니다. 문서 확인

내부 테스트 링크가 왜 열리지 않나요?

내부 테스트에서 커뮤니티 게시판을 가장 많이 채우는 실패이자, 문서가 가장 부실한 실패입니다. 개발자들은 Play Console이 요구한 것을 다 하고 나서 이 문제를 만나기 때문에 더 당황스럽습니다. 오류 코드도 진단 정보도 없고, 페이지는 계정이 문제인 것처럼 이 계정으로는 앱을 사용할 수 없다고 태연히 알려 줍니다. 보고는 2018년 Stack Overflow 질문부터 2026년 7월 Google 개발자 커뮤니티 글까지, 영어와 포르투갈어로 이어지며 같은 몇 가지 원인을 되풀이합니다.

유용한 접근은 이것을 고장 난 링크가 아니라 회로로 보는 것입니다. Google의 전달 규칙은 조건이 직렬로 이어진 형태라서, 접점 하나만 열려 있어도 그 뒤가 전부 멈춥니다. 그 보고들에서 반복되는 원인은 네 가지 상태로 정리됩니다. 테스터 목록에 없음, 목록에는 있지만 참여하지 않음, 참여했지만 다른 Google 계정 사용, 그리고 설정은 맞고 아직 반영 중입니다. 마지막 것은 애초에 결함이 아니며, 그래서 여기에 가장 많은 시간이 낭비됩니다.

열려 있는 관문 찾기

각 스위치를 짐작이 아니라 실제로 확인한 대로 설정하세요. 관문은 확인하는 데 드는 품이 적은 순서로 배열되어 있으므로, 아직 열려 있는 첫 번째 관문이 다음에 손볼 가치가 있는 것입니다.

액세스 관문 시뮬레이터

“이 계정으로는 앱을 사용할 수 없습니다”

테스터 액세스는 기기나 링크가 아니라 신원에 묶여 있습니다. Google의 요구사항은 그 계정이 관리 중인 테스터 설정에 포함되어 있으면서 동시에 그 테스트 프로그램에 참여한 상태여야 한다는 것입니다. 둘 중 하나라도 빠지면, Play Store는 그 사람을 URL을 우연히 찾아낸 낯선 사람과 구분할 방법이 없습니다.

이 문제가 유난히 자주 나타나는 이유는 시시합니다. 휴대전화와 브라우저에는 Google 계정이 여러 개 로그인되어 있는 것이 보통이고, 링크를 여는 계정이 초대한 계정이 아닐 때가 많습니다. 2026년 3월 Google 개발자 커뮤니티 글에는 계정 선택 화면이 예상과 다르게 동작해 원하는 신원으로 아예 전환하지 못하는 테스터 사례가 올라와 있고, 2025년 중반 포르투갈어 게시글도 같은 패턴을 보고하면서 Google Play에서 선택된 계정을 맞추라는 답을 그대로 가리킵니다. 커뮤니티 보고

복사할 테스트 참여 링크가 없습니다

무엇보다 먼저 앱 상태를 확인하세요. Google은 테스트 참여 링크를 앱 상태가 게시됨일 때만 표시합니다. Draft나 Pending publication 상태에서는 링크가 숨겨지거나 지연되는 것이 아니라 아직 존재하지 않습니다. 조건이 이분법적이고 자신의 콘솔에서 눈으로 확인되기 때문에, 전체 문제 해결 항목 가운데 가장 깔끔하게 풀리는 경우입니다. 문서 확인

게시는 됐는데 Play 검색에서 아무도 못 찾습니다

결함이 아니라 정상 동작입니다. Google은 공개 테스트나 프로덕션보다 앞서 진행되는 내부 또는 비공개 테스트는 Play Store 검색으로 찾을 수 없다고 밝힙니다. 「Play에서 앱을 검색해 보라」는 말을 들은 테스터는 설정이 아무리 정확해도 매번 실패하고, 앱이 존재하지 않는다고 보고하는 것도 당연합니다.

직접 링크를 보내세요. 그리고 검색으로는 안 된다고 메시지에 분명히 적어 주세요. 누구나 가장 먼저 검색부터 해 보기 때문입니다. 문서 확인

일부 테스터가 아직 예전 버전을 보고 있습니다

원인 세 가지를 순서대로 확인하세요. 첫째, 반영 시간입니다. 추가로 게시한 변경사항은 테스터에게 도달하기까지 여러 시간이 걸릴 수 있으므로, 최근 업데이트라면 아직 도착하지 않았을 뿐일 수 있습니다. 둘째, 버전 코드입니다. 사용자는 자신이 자격을 가진 모든 트랙 가운데 호환되는 가장 높은 버전 코드를 받습니다. 모든 사용자가 프로덕션 대상이므로, 더 낮은 테스트 버전 대신 더 높은 프로덕션 버전 코드가 전달될 수 있고, 그러면 가장 최신 내부 빌드가 분명히 존재하고 멀쩡한데도 정작 테스터에게는 도달하지 않는 헷갈리는 상황이 벌어집니다. 셋째, 트랙 자격입니다. 내부 테스트에 참여 중인 계정은 비공개나 공개 빌드를 받을 자격이 없으므로, 작업을 다른 트랙으로 옮기셨다면 그 계정은 엉뚱한 트랙을 보고 있는 것입니다. 문서 확인

다 확인했는데도 안 됩니다

이제, 오직 이제야 커뮤니티에서 도는 처방을 시도해 볼 만합니다. 기기 재시작, Play Store 재시작, Play Store 캐시나 데이터 삭제, 또는 깨끗한 브라우저 프로필에서 링크 열기입니다. 이것들은 Google 정책이 아니라 Google 개발자 커뮤니티 글에서 나온 것이고, 문서화된 동작이 아니라 누군가에게 효과가 있었던 일로 보고된 것입니다. 이것부터 하다가 며칠씩 날리는데, 설정 문제를 고쳐 주지도 못하면서 반영 지연을 성공처럼 위장하기 때문입니다. 커뮤니티 보고

진짜 경계 사례도 있습니다. 2026년 2월 커뮤니티 글은 처음부터 한 번도 열리지 않은 내부 테스트 링크를 설명하고, 2026년 5월 글은 테스트 참여 페이지에서 HTTP 500이 났다고 보고합니다. 둘 다 일반적인 근본 원인이 확인되지 않았고, 여기서 기술적 설명을 지어내는 것은 모른다고 인정하는 것보다 나쁩니다. 설정이 검증 가능하게 올바르고, 반영 시간도 지났고, 실패가 계속되거나 서버 오류가 돌아온다면, 설정을 계속 바꾸기보다 Play Console 지원팀에 문의하는 것이 합리적인 시점입니다. 원인 미확인

증상별 해결법과 근거 등급

표를 옆으로 밀어 모든 열을 확인하세요

자주 틀리는 한도와 규칙

표를 옆으로 밀어 모든 열을 확인하세요

내부 테스트 vs 내부 앱 공유

이 둘은 이름이 헷갈릴 만큼 비슷한 서로 다른 기능이고, 잘못 고르면 반나절이 날아갑니다. 내부 테스트는 이 글 전체가 설명하는 정식 트랙입니다. 출시 버전이 있고, 최대 100명까지 관리되는 테스터 목록이 있고, 테스트 참여가 있으며, 업데이트가 Google Play를 통해 전달됩니다. 내부 앱 공유는 업로드한 APK나 앱 번들을 받아 돌려 볼 수 있는 다운로드 링크를 만들어 주는 빠른 공유 도구입니다. 여기에도 자체 액세스 제어가 있는데, 종류가 다를 뿐입니다. Google의 해당 문서를 보면 다운로드를 이메일 목록으로 제한하거나 링크를 받은 사람 누구에게나 열어 둘 수 있고, 어느 쪽이든 테스터가 먼저 자신의 Play Store 앱에서 내부 앱 공유를 켜야 합니다.

현실적인 기준은 이렇습니다. 지금 당장 10분 안에 동료에게 빌드를 던져 줘야 하면 내부 앱 공유를, 버전 기록과 테스터 목록이 필요하고 나중에 승격할 빌드를 원하면 내부 테스트 트랙을 쓰세요. 사람들이 걸려 넘어지는 세부 사항은 60일 만료입니다. 두 달 전 버그 리포트에 붙어 있던 링크가 설정 오류가 아니라 그냥 죽은 링크이기 때문입니다. 두 기능 모두 테스터 12명 비공개 테스트에는 집계되지 않습니다. 문서 확인

인앱 구매의 함정

내부 테스트 중에는 전부 무료라는 흔한 주장을 그대로 옮기지 마세요. Google의 규칙은 앱과 앱 안에서 파는 것을 구분합니다. 유료 앱 자체는 내부 테스터가 무료로 설치합니다. 인앱 구매는 그 테스터의 계정이 라이선스 테스터로도 설정되어 있지 않으면 그대로 결제됩니다.

구독이 들어간 테스트라면 이 구분은 실제 돈 문제입니다. 게다가 지금 상위에 노출되는 비교 글 가운데 최소 한 편은 정반대로 적고 있습니다. 테스터가 곧 결제 흐름을 밟을 예정이라면 라이선스 테스트를 먼저 설정하시거나, 실제 결제를 각오하세요. 문서 확인

당신 잘못이 아닌 두 가지

인터넷에 떠도는 일반적인 내부 테스트 조언의 상당수는 원인일 수 없는 것을 고치라고 시킵니다. 시간이 낭비되고, 때로는 멀쩡히 돌아가던 설정이 망가집니다.

검증한 주장과 판정

아래 각 행은 내부 테스트에 관해 실제로 돌아다니는 주장입니다. 판정 열은 그럴듯하게 들리는 쪽이 아니라 1차 출처가 뒷받침하는 내용을 적었습니다.

• 사실 아님
  “내부 테스트가 테스터 12명 테스트로 인정된다.” Google의 요구사항 페이지는 비공개 테스트를 명시적으로 요구합니다. 14일이라는 기간 전체를 통째로 잃게 만들기 때문에, 이 주제에서 가장 손해가 큰 오류입니다.
• 지난 정보
  “아직 테스터 20명이 필요하다.” 2024년 12월 11일부터 옛 기준입니다. 현재 최소 인원은 12명입니다.
• 사실 아님
  “내부 테스터는 모든 구매가 무료다.” 무료인 것은 유료 앱 자체뿐입니다. 인앱 구매는 라이선스 테스트를 설정하지 않으면 결제됩니다.
• 사실 아님
  “테스터가 해외에 있으면 그 국가를 추가해야 한다.” Google은 내부 테스트를 그 배포 제한에서 명시적으로 제외합니다.
• 오해의 소지
  “바로 안 되면 링크가 고장 난 것이다.” Google 스스로 첫 링크에는 몇 시간, 이후 변경에는 여러 시간을 잡아 둡니다.
• 오해의 소지
  “테스터는 참여 링크를 이메일로 자동 수신한다.” Google이 문서화한 절차는 개발자가 공유 가능한 링크를 복사해 배포하는 것입니다. Play Console이 대신 테스터를 초대해 준다는 전제로 계획을 세우지 마세요.
• 부분적으로 사실
  “내부 테스트에도 Google 그룹스를 쓸 수 있다.” 현재 콘솔 도움말은 내부 테스트에는 이메일 목록을, 비공개 테스트에는 Google 그룹스를 문서화하고 있습니다. 게시 API의 testers 리소스는 그룹을 더 넓게 지원하지만, 그것이 이 트랙의 2026년 콘솔 동작을 증명해 주지는 않습니다. 문서화된 이메일 목록 방식을 쓰시고 그룹을 전제로 계획하지 마세요.
• 부분적으로 사실
  “Google은 내부 트랙을 정확히 하나만 허용한다.” 게시 API는 표준 내부 트랙을 잘 알려진 단일 트랙으로 노출하고, 도움말은 이름을 붙인 추가 비공개 트랙을 문서화하면서 내부 트랙 개수는 밝히지 않습니다. 단정적인 한도를 말하기보다 「표준 내부 테스트 트랙」이라고 부르세요.
• 사실
  “스토어 등록정보를 마치기 전에도 내부 테스트를 돌릴 수 있다.” Google은 앱 설정을 모두 마치기 전이라도 유효한 앱 번들만 있으면 내부 배포가 가능하다고 밝힙니다.
• 사실
  “테스트에서 받은 의견은 공개 평점에 해가 되지 않는다.” Google은 테스트 사용자의 의견이 앱의 공개 평점에 영향을 주지 않는다고 밝힙니다.

내부 테스트 종료하기

트랙을 일시중지하세요. 테스터는 이미 설치한 앱을 그대로 가지고 있지만, 이 트랙을 통한 테스트 업데이트는 더 이상 받지 않습니다. 트랙을 일시중지하면 누군가의 휴대전화에서 앱이 사라진다고 생각하기 쉬운데 그렇지 않으니, 알아 두시면 좋습니다. 문서 확인

빌드를 비공개 테스트로 어떻게 옮기나요?

내부 테스트를 잘 마친 뒤 대부분 이 단계에 도착하며, 프로덕션 액세스 시계가 실제로 돌기 시작하는 지점도 여기입니다. 아래 안내는 버튼 하나하나를 짚는 대본을 일부러 피했습니다. Play Console은 버전마다 화면이 다르고, 외워 둔 클릭 경로가 가장 먼저 깨지기 때문입니다.

1. 01
   목적지 트랙 열기 Test and release › Testing › Closed testing으로 이동해 사용할 비공개 트랙을 관리합니다.
2. 02
   그 트랙에서 출시 버전 만들기 이미 테스트를 마친 아티팩트를 담더라도, 비공개 출시는 그 자체로 별개의 출시 버전입니다.
3. 03
   라이브러리에서 추가로 테스트한 아티팩트 재사용 번들을 다시 올리지 마시고 내부 테스트 때 업로드한 버전을 고르세요. 이 부분은 Google의 현재 출시 도움말(answer 9859348)에 문서화되어 있습니다. 문서 확인
4. 04
   비공개 테스터 설정 비공개 트랙의 자체 테스터 설정을 사용합니다. 비공개 테스트에서는 현재 도움말이 이메일 목록 또는 Google 그룹스를 지원하며, 이 점이 내부 트랙과 실제로 다릅니다.
5. 05
   검토하고 출시 그다음 내부 테스트 때와 같은 방식으로 비공개 테스트 참여 링크를 공유하세요. 두 조건은 그대로입니다. 목록에 있을 것, 그리고 참여할 것.

같은 테스터를 그대로 쓸 수 있나요?

사람은 그대로 쓸 수 있지만 두 테스트에 동시에 참여할 수는 없습니다. 이 단계에서 비공개 테스트를 가장 많이 망가뜨리는 것이 바로 이 구분입니다.

내부 테스트에 참여 중인 계정은 공개나 비공개 테스트 빌드를 받을 자격이 없습니다. Google의 안내는 테스터가 먼저 내부 테스트 참여를 해제한 다음 비공개 테스트에 참여하라는 것입니다. 그러니 공들여 모은 내부 QA 인원을 비공개 테스트 그룹으로 그대로 쓸 수는 있지만, 한 사람도 빠짐없이 직접 내부 트랙에서 빠져나와야 비공개 트랙의 빌드가 보입니다.

표를 옆으로 밀어 모든 열을 확인하세요

여기서부터는 성격이 다른 주제로 넘어갑니다. 14일 연속으로 참여를 유지할 사람을 모으고, 그 인원이 제대로 집계되게 하고, 프로덕션 액세스 질문지를 넘기는 일입니다. 그 내용은 비공개 테스트 테스터 초대 방법, Play Console에 참여 테스터가 0명으로 보이는 이유, 프로덕션 액세스 질문지에서 다룹니다.

PrimeTestLab이 맡는 부분

인수인계 지점을 정확히 짚어 둘 필요가 있습니다. 두 트랙은 실패하는 이유가 전혀 다르기 때문입니다. 내부 테스트는 설정에서 실패합니다. 아직 존재하지도 않던 링크, 끝내 참여하지 않은 계정, 아무도 기다려 주지 않은 반영 시간 같은 것들이죠. 이런 문제는 꼼꼼히 읽으면 풀리고, 이 글의 앞 3분의 2가 바로 그 역할을 합니다.

비공개 테스트는 사람에서 실패합니다. Google이 공개한 수치 조건은 최근 14일 동안 지속적으로 비공개 테스트에 참여한 테스터 12명 이상인데, 현실로 옮기면 참여해 준 사람 열둘이 둘째 주에도 그대로 남아 있어야 한다는 뜻입니다. 그 인원과는 별개로, 테스터들이 빌드를 설치해 의미 있게 써 주기를 바라게 됩니다. Google이 프로덕션 액세스 신청을 검토할 때 참여도와 기능 사용, 받은 의견을 묻기 때문입니다. 어느 쪽도 문서를 몰라서 생기는 문제가 아니고, 콘솔 지식을 아무리 쌓아도 풀리지 않습니다. 대부분의 개발자는 내부 테스트를 끝내고 요구사항이 조금도 줄지 않았다는 사실을 깨닫는 순간 이것을 알게 됩니다.

비공개 테스트를 직접 할 것인가, 맡길 것인가

표를 옆으로 밀어 모든 열을 확인하세요

네, 지금은 테스터 25명이 20명보다 저렴합니다. 오타가 아니라 프로모션입니다. 현재 Enterprise에 세 요금제 중 가장 큰 할인이 걸려 있어서 테스터 1명당 단가도 가장 낮고, Professional의 $1.50에 비해 대략 $1.12 수준입니다. 두 요금제 모두 같은 비공개 테스트를 진행하며, 순서가 뒤집힌 이유는 프로모션 하나뿐입니다. 이 글을 쓴 뒤 금액이 바뀌었다면 요금제 페이지의 값이 실제 값입니다.

120+개국 7,400+개 앱에서 비공개 테스트 요구사항 기준 테스트 완료율 99.9%를 유지하고 있습니다. 다만 승인이 보장된다는 말씀은 드리지 않습니다. Google은 프로덕션 액세스 신청을 자체 기준으로 검토하며 테스트를 더 요구할 수도 있고, 특정 결과를 약속하는 사람은 자기가 통제하지 못하는 것을 이야기하고 있는 것입니다. 저희가 약속드리는 것은 통제할 수 있는 부분입니다. 테스트가 요건을 채우지 못하면 무료 재테스트 또는 전액 환불을 받으실 수 있습니다.

내부 테스트 FAQ

핵심 정리