Closed 및 Open Beta — 앱 베타 테스트의 개념과 작동 방식

앱 베타 테스트란

베타 테스트는 공식 릴리스 전에 실제 사용자를 대상으로 애플리케이션을 테스트하는 단계입니다. 개발자와 QA 엔지니어가 테스트하는 내부 테스트와 달리, 베타 테스트는 자체 기기, 데이터 및 시나리오를 사용하여 실제 조건에서 애플리케이션을 사용하는 외부 사용자를 대상으로 수행됩니다.

베타 테스트는 Closed Beta(비공개)와 Open Beta(공개)의 두 가지 유형으로 나뉩니다. Google Play에서는 두 트랙 모두 개발자 콘솔을 통해 사용할 수 있으며, App Store에서는 TestFlight를 통해 사용할 수 있습니다. 주요 차이점은 액세스 방식에 있습니다. Closed Beta는 초대가 필요하고, Open Beta는 공개 링크 또는 스토어 검색을 통해 사용할 수 있습니다.

베타 테스트가 필요한 이유

Google Play Console의 연구에 따르면, 베타 테스트는 내부 테스트 중에 감지되지 않은 최대 40%의 심각한 버그를 발견합니다. 실제 사용자는 테스트 환경에서 재현할 수 없는 다양한 기기 모델, OS 버전 및 네트워크 조건을 사용합니다. 베타 테스트는 또한 UX/UI 및 새로운 기능에 대한 질적 피드백을 수집합니다.

파이프라인의 베타 테스트 단계

일반적인 파이프라인은 다음과 같습니다: 내부 테스트 → Closed Beta → Open Beta → Production. 내부 트랙에서 안정화된 후, 빌드는 제한된 외부 사용자를 위해 Closed Beta에 게시됩니다. 피드백을 수집하고 버그를 수정한 후 — 모든 사람을 위해 Open Beta에 게시됩니다. 최종 프로덕션 릴리스는 Open Beta에서 안정성이 확인된 후 수행됩니다.

Closed Beta: 특징 및 설정

Closed Beta는 초대 전용 액세스 권한이 있는 테스트 트랙입니다. 개발자가 이메일 주소 목록을 지정하거나 Google Group을 만들어 해당 구성원이 베타 버전에 액세스할 수 있도록 합니다. Google Play에서 Closed Beta는 최대 10,000명의 테스터를 지원하며, 이는 100명의 내부 테스트 제한을 크게 초과합니다.

Google Play에서 Closed Beta 설정

Closed Beta 트랙을 만들려면 Google Play Console → Release → Testing → Closed Beta로 이동합니다. 테스터 그룹을 만들고 추가 방법(이메일, Google Group 또는 초대 링크)을 지정합니다. 빌드를 업로드하고 Google Play에서 확인한 후, 시스템이 그룹 구성원에게 초대장을 보냅니다.

// Fastlane — Closed Beta 트랙에 게시
lane :closed_beta_release do
    gradle(task: ":app:assembleRelease")
    
    upload_to_play_store(
        track: "beta",
        release_status: "draft",
        rollout: 1.0
    )
    
    promote_to_play_store(
        track: "beta",
        release_status: "completed"
    )
end

Closed Beta에서 버전 관리

Closed Beta 트랙은 별도의 versionCode 번호를 사용합니다. 내부 테스트 및 프로덕션과 중복되지 않는 versionCode 범위를 할당하는 것이 좋습니다. 예를 들어, 버전 2.4.0의 경우: Internal → versionCode 24000, Closed Beta → 24001, Open Beta → 24002, Production → 24003. 이렇게 하면 트랙 간 빌드 승격 시 충돌을 방지할 수 있습니다.

Open Beta: 공개 테스트

Open Beta는 초대 없이 모든 사용자가 사용할 수 있는 트랙입니다. Google Play에서 Open Beta는 스토어에 Beta 레이블이 있는 별도의 앱 카드로 표시됩니다. 모든 사용자는 공개 링크를 통해 또는 Google Play에서 앱을 찾아 Become a Tester를 클릭하여 테스트에 참여할 수 있습니다.

Open Beta의 이점

Open Beta는 테스트를 위한 최대 사용자 범위를 제공합니다. 샘플을 개발자가 결정하는 Closed Beta와 달리, Open Beta는 다양한 기기, 습관 및 시나리오를 가진 사용자를 유치합니다. 이는 릴리스 전에 애플리케이션 안정성에 대한 가장 완전한 그림을 제공합니다. 피드백은 Google Play Rating 및 인앱 설문조사를 통해 수집됩니다.

Google Play에서 Open Beta의 제한 사항

Open Beta는 모든 개발자 계정에서 사용할 수 있지만, 게시 전에 검토 승인이 필요합니다. Google Play는 프로덕션 릴리스와 마찬가지로 기본 요구 사항 준수 여부를 확인합니다. 승인 후 트랙이 스토어에 게시되며, 모든 사용자가 구독할 수 있습니다. 현재 설치를 잃지 않고 언제든지 Open Beta를 취소할 수 있습니다.

TestFlight를 통한 App Store 베타 테스트

Apple 생태계에서 외부 베타 테스트는 TestFlight External Testing을 통해 수행됩니다. 외부 테스터의 최대 수는 10,000명입니다. Google Play와 달리 TestFlight는 스토어 표시가 있는 완전한 Open Beta를 지원하지 않습니다. 액세스는 초대 링크 또는 Apple의 공개 페이지를 통해서만 배포됩니다.

TestFlight External Testing: 프로세스

TestFlight External Testing에 빌드를 게시하려면 개발자가 Xcode 또는 Transporter를 통해 IPA를 업로드하고, 그 후 Beta App Review가 시작됩니다. Apple은 전체 App Review와 달리 기본 요구 사항을 확인합니다. 검토에는 1~2일이 소요됩니다. 승인 후 빌드는 최대 90일 동안 링크를 통해 배포할 수 있습니다. 기간을 연장하려면 새 빌드를 업로드해야 합니다.

TestFlight를 통한 피드백 수집

TestFlight에는 스크린샷 및 기기 로그 수집을 위한 기본 지원이 있습니다. 테스터가 기기를 흔들면 App Store Connect를 통해 개발자에게 보고서가 전송됩니다. 각 보고서에는 스택 추적, 스크린샷, 빌드 버전 및 기기 정보가 포함됩니다. 이를 통해 테스터와의 긴 연락 없이도 버그를 재현하고 수정할 수 있습니다.

Google Play Console에서 베타 트랙 설정

Google Play Console에서 Closed 및 Open Beta 설정은 Release → Testing 섹션에서 수행됩니다. 프로세스는 15~30분이 소요되며, 첫 사용 전에 한 번 트랙을 구성해야 합니다. 두 유형의 베타 테스트에 대한 단계별 지침을 살펴보겠습니다.

Closed Beta에 게시

Google Play Console에서 테스터 그룹을 만들고 빌드를 Closed Beta 트랙에 업로드합니다. 시스템이 기본 요구 사항을 확인하고 5~15분 내에 빌드를 그룹 구성원이 사용할 수 있게 됩니다. 구성원은 Google Play를 통해 초대장 및 설치 지침이 포함된 이메일을 받습니다.

Open Beta에 게시

Open Beta 트랙을 선택하고 빌드를 업로드합니다. Closed Beta와 달리 Open Beta는 검토(프로덕션 릴리스와 유사)를 거쳐야 하며, 24~48시간이 소요됩니다. 승인 후 앱 카드가 Google Play에 Beta 레이블과 함께 표시됩니다. 사용자는 Become a Tester 버튼을 통해 테스트에 참여할 수 있습니다.

베타 테스트 모범 사례

베타 테스트의 효과는 프로세스 구성의 품질에 직접적으로 달려 있습니다. 다음은 주요 개발자의 경험과 Google Play Console 권장 사항을 기반으로 한 검증된 방법입니다. 이러한 규칙을 따르면 버그 발견률이 40~60% 증가합니다.

• 100~500명의 신뢰할 수 있는 사용자로 Closed Beta를 시작하세요
• 안정성 메트릭(ANR, 충돌, 정지 빈도)을 수집하세요
• 내장 피드백 도구(Firebase, Crashlytics, TestFlight)를 사용하세요
• Open Beta 전에 Closed Beta에서 새 기능의 A/B 테스트를 수행하세요
• 베타 테스트 기간을 설정하세요: Closed 7~14일, Open 14~30일

피드백 및 메트릭 분석

베타 테스트 완료 후 모든 보고서를 수집하고, 버그를 우선순위에 따라 분류하여 개발 팀에 전달합니다. Open Beta에서 발견된 버그는 프로덕션 릴리스 전에 수정되어야 합니다. 베타 테스트에 참여한 사용자는 공식 출시 후 첫 번째 활성 사용자가 되는 경우가 많습니다.

베타 테스터와의 커뮤니케이션

테스터에게 업데이트 정보를 지속적으로 제공하세요. 새 빌드를 알리려면 Google Play 및 TestFlight의 내장 알림을 사용하세요. 수정 사항 및 새 기능에 대한 설명이 포함된 변경 로그를 유지 관리하세요. Resolution Center(TestFlight) 또는 앱 페이지(Google Play)에서 피드백에 응답하세요. 이는 테스터 참여도를 높입니다.

베타 테스트 성능 메트릭

베타 테스트 평가를 위한 주요 메트릭: 활성 테스터 수, 버그를 보고한 비율, 첫 번째 보고까지의 평균 시간, 커버리지 비율(테스트가 적용된 기기 및 OS 버전의 비율). 커버리지 비율이 40% 미만인 경우, 대상 초대 이메일을 통해 누락된 구성의 테스터를 추가하세요.