안드로이드 앱 바이브 코딩 5단계: AAB 만들고 내부 테스트로 배포하기

Android 내부 테스트 관점에서 보면, 서명된 릴리즈 빌드가 만들어졌다고 해서 앱이 출시 준비를 마친 것은 아닙니다. 개발자 기기에서 잘 실행되던 앱을 실제 배포 경로에 올리고, 다른 계정과 기기에서 설치·업데이트·핵심 기능을 확인해야 비로소 “배포 가능한 앱”에 가까워집니다. 이번 글에서는 Android App Bundle(AAB)을 만들고 Google Play Console의 내부 테스트 트랙으로 배포한 뒤, 피드백을 다음 릴리즈로 연결하는 과정을 정리합니다.

이 글은 시아메이커랩의 “안드로이드 앱 바이브 코딩” 시리즈 다섯 번째 글입니다. 앞 단계에서 릴리즈·디버그 키스토어를 분리하고 Gradle 서명 설정과 백업을 준비했습니다. 이번 단계의 입력은 실제 기기에서 검증된 MVP와 안전하게 보관된 업로드 키이며, 출력은 테스터가 Play 스토어를 통해 설치할 수 있는 첫 내부 테스트 릴리즈와 재현 가능한 피드백 기록입니다.

Android 내부 테스트: 5단계의 목표는 출시가 아니라 배포 경로 검증이다

첫 내부 테스트의 성공 기준을 “프로덕션 공개”로 잡으면 확인할 일이 한꺼번에 너무 많아집니다. 지금 검증할 것은 릴리즈 산출물이 만들어지는지, Play Console이 번들을 받아들이는지, 허용된 테스터가 설치할 수 있는지, 그리고 실제 사용자 경로에서 핵심 기능이 유지되는지입니다.

• 릴리즈 AAB가 올바른 application ID와 versionCode로 생성된다.
• 업로드 키로 서명된 번들이 Play Console에 정상 등록된다.
• 테스터가 초대 링크로 참여하고 Play 스토어에서 앱을 설치한다.
• 새 버전을 올렸을 때 기존 설치 위에 업데이트된다.
• 치명적인 문제와 후속 개선을 구분해 기록한다.

APK와 AAB는 목적이 다르다

APK는 기기에 직접 설치해 빠르게 확인하기 편한 실행 패키지입니다. 반면 AAB는 기기에 그대로 설치하는 파일이 아니라 Google Play가 기기 구성에 맞는 APK를 생성하도록 코드와 리소스를 묶어 전달하는 게시 형식입니다. 새로운 앱을 Google Play에 게시할 때는 AAB를 기준으로 준비해야 합니다.

Gradle 프로젝트라면 일반적으로 bundleRelease 작업으로 릴리즈 번들을 만듭니다. 프로젝트의 실제 모듈 이름과 빌드 변형에 따라 명령은 달라질 수 있으므로 에이전트에게 명령만 실행시키지 말고 산출물 경로, 서명 인증서 지문, versionCode와 versionName을 함께 보고하게 해야 합니다.

./gradlew clean bundleRelease

# 일반적인 산출물 위치
app/build/outputs/bundle/release/app-release.aabCode language: PHP (php)

코딩 에이전트에 맡길 때 사용할 프롬프트

현재 Android 프로젝트의 첫 내부 테스트 릴리즈를 준비해 주세요.

1. 작업 전 applicationId, versionCode, versionName과 release 서명 설정을 확인합니다.
2. 비밀번호나 키 파일 내용을 출력하거나 Git에 추가하지 않습니다.
3. 테스트와 lint 결과를 확인한 뒤 release AAB를 생성합니다.
4. 생성된 파일 경로, 크기, 서명 여부와 인증서 지문을 보고합니다.
5. 실패하면 설정을 임의로 우회하지 말고 원인과 최소 수정안을 먼저 설명합니다.
6. Play Console 업로드는 하지 말고 로컬 산출물 검증에서 멈춥니다.

첫 업로드 전에 고정되는 값을 다시 확인한다

Play Console에 첫 산출물을 올리는 순간 패키지명은 그 앱의 정체성이 됩니다. 나중에 마음이 바뀌어도 기존 앱의 패키지명을 간단히 교체할 수 없으므로, 업로드 전에 개발자 계정, 앱 이름, application ID, 서명 키, 버전 정보를 한 화면에 모아 대조하는 편이 안전합니다.

• application ID: 임시 이름이나 예제 도메인이 남아 있지 않은가
• versionCode: 이전에 올린 값보다 반드시 커지는 구조인가
• 업로드 키: 앞 단계에서 백업한 키와 실제 서명에 사용한 키가 같은가
• 앱 이름과 아이콘: 디버그용 표시와 릴리즈 표시가 혼동되지 않는가
• 지원 SDK와 권한: 사용하지 않는 민감 권한이 남아 있지 않은가

내부 테스트에 필요한 준비물을 먼저 모은다

내부 테스트는 스토어 등록 정보가 완전히 끝나기 전에도 시작할 수 있지만, 번들 하나만 올리면 모든 검토가 끝나는 것은 아닙니다. 앱의 기능과 데이터 처리 방식에 따라 개인정보처리방침, 데이터 보안, 광고 포함 여부, 콘텐츠 등급, 앱 액세스 방법 같은 항목을 작성해야 합니다. 로그인 뒤에만 기능이 보인다면 검토자가 사용할 테스트 계정이나 접근 방법도 준비합니다.

내부 테스트와 내부 앱 공유는 이름이 비슷하지만 목적이 다릅니다. 내부 테스트 트랙은 Play 스토어의 테스트 참여 흐름과 향후 릴리즈 승격을 점검하기 좋습니다. 내부 앱 공유는 링크로 빌드를 아주 빠르게 전달하는 별도 도구이며, 그 산출물은 테스트나 프로덕션 트랙의 릴리즈로 그대로 승격되지 않습니다. 이번 단계에서는 실제 출시 경로에 가까운 내부 테스트 트랙을 사용합니다.

Play Console에서 내부 테스트 릴리즈를 만든다

1. Play Console에서 앱을 만들고 기본 언어, 앱 또는 게임, 무료 또는 유료 여부를 확인합니다.
2. 테스트 및 출시 메뉴의 내부 테스트에서 새 릴리즈를 만듭니다.
3. Play 앱 서명 안내를 읽고 계정에 맞는 키 구성을 확인합니다.
4. 검증한 릴리즈 AAB를 업로드하고 오류와 경고를 읽습니다.
5. 릴리즈 이름과 변경사항을 테스터가 이해할 수 있게 적습니다.
6. 이메일 목록 또는 Google 그룹으로 테스터를 지정합니다.
7. 릴리즈를 시작한 뒤 참여 링크를 테스터에게 전달합니다.

테스터에게 설치 링크만 보내지 않는다

“써 보고 알려 주세요”라는 요청은 좋은 피드백을 만들기 어렵습니다. 테스트 계정, 반드시 확인할 핵심 경로, 기대 결과, 오류를 제보할 장소와 필요한 정보까지 함께 전달해야 합니다. 특히 내부 테스트 앱은 일반 검색으로 찾는 것이 아니라 참여 링크를 통해 접근하므로, 테스터가 초대에 사용된 Google 계정으로 Play 스토어에 로그인했는지도 확인합니다.

테스트할 버전: 0.1.0 (versionCode 1)
설치 방법: 전달한 참여 링크에서 테스터 등록 후 Play 스토어로 설치
반드시 확인할 흐름: 첫 실행 → 핵심 작업 생성 → 저장 → 앱 재실행 → 수정·삭제
제보할 내용: 기기 모델, Android 버전, 재현 단계, 기대 결과, 실제 결과, 화면 캡처
주의: 실제 개인정보나 결제 정보를 입력하지 말고 제공된 테스트 데이터 사용Code language: CSS (css)

피드백은 출시 차단 문제와 개선 아이디어로 나눈다

첫 테스트에서 받은 모든 의견을 즉시 구현하면 MVP 범위가 다시 커집니다. 설치 실패, 시작 직후 충돌, 로그인 불가, 저장 데이터 손실, 핵심 작업 완료 불가처럼 사용 자체를 막는 문제는 다음 릴리즈 전에 해결합니다. 문구 다듬기, 추가 정렬, 새로운 테마처럼 핵심 사용을 막지 않는 요청은 후속 백로그로 보냅니다.

다음 번들을 올리기 전 확인할 것

• 재현 절차가 있는 문제만 수정 대상으로 확정한다.
• versionCode를 증가시키고 versionName 정책을 유지한다.
• 수정한 경로뿐 아니라 기존 핵심 경로도 다시 확인한다.
• 같은 업로드 키로 서명하고 인증서 지문 변화를 확인한다.
• 릴리즈 노트에 테스터가 다시 볼 항목을 구체적으로 적는다.
• 설치뿐 아니라 이전 내부 테스트 버전에서 업데이트되는지 확인한다.

자동 검사 결과도 실제 앱과 함께 본다

Play Console은 업로드한 번들을 여러 실제·가상 기기에서 실행해 안정성, 호환성, 성능, 접근성 문제를 찾는 사전 출시 보고서를 제공할 수 있습니다. 보고서가 깨끗하다고 품질이 자동 보장되는 것은 아니지만, 개발자가 가진 기기에서 드러나지 않은 충돌이나 화면 문제를 찾는 보조 증거로 유용합니다. 로그인이 필요한 앱이라면 공식 계정 대신 제한된 테스트 자격 증명과 안전한 테스트 데이터를 사용합니다.

완료 체크리스트

• application ID와 앱 이름을 마지막으로 확인했다.
• 릴리즈 AAB의 버전과 서명 인증서를 확인했다.
• Play Console에 내부 테스트 릴리즈가 활성화됐다.
• 개발자 본인이 아닌 테스트 계정으로 참여·설치했다.
• 첫 실행, 핵심 작업, 저장, 재실행과 업데이트를 확인했다.
• 사전 출시 보고서의 오류와 경고를 검토했다.
• 피드백을 출시 차단 문제와 후속 개선으로 분리했다.
• 다음 릴리즈의 versionCode와 변경 범위를 기록했다.

마무리: 첫 배포는 사용자를 모으는 일이 아니라 증거를 모으는 일이다

내 기기에서 실행되는 앱과 다른 사용자가 Play 스토어에서 설치할 수 있는 앱 사이에는 서명, 번들, 계정, 정책, 배포 트랙과 업데이트라는 새로운 경계가 있습니다. 내부 테스트는 그 경계를 작은 범위에서 처음 통과해 보는 단계입니다. 설치 링크 하나를 만들었다는 사실보다, 누가 어떤 버전을 어떤 기기에서 사용했고 무엇이 막혔는지를 남기는 일이 더 중요합니다.

다음 글에서는 내부 테스트에서 확인한 앱을 비공개 테스트와 프로덕션 준비로 확장하면서, 스토어 등록 정보·데이터 보안·개인정보처리방침·콘텐츠 등급을 서로 모순 없이 작성하는 방법을 다루겠습니다.

관련 글: AI 에이전트로 로드맵 실제 구현하기 · 키스토어 생성과 앱 서명 안전하게 구성하기