안드로이드 앱 바이브 코딩 6단계: 비공개 테스트와 프로덕션 준비하기

Android 비공개 테스트 관점에서 보면, Google Play의 프로덕션 준비는 빈칸을 모두 채우는 행정 작업이 아닙니다. 앱이 실제로 하는 일, 스토어에서 약속하는 기능, 수집·공유하는 데이터, 개인정보처리방침과 콘텐츠 등급이 하나의 사실을 말하도록 맞추는 검증 과정입니다. 이번 글에서는 내부 테스트를 마친 Android 앱을 비공개 테스트로 확장하고, 서로 다른 Play Console 문서를 모순 없이 작성하는 방법을 정리합니다.

이 글은 시아메이커랩의 “안드로이드 앱 바이브 코딩” 시리즈 여섯 번째 글입니다. 앞 단계에서는 릴리즈 AAB를 내부 테스트 트랙에 배포하고 설치·업데이트·핵심 기능을 확인했습니다. 이번 단계의 입력은 검증된 앱 동작과 테스터 피드백이며, 출력은 비공개 테스트에 올릴 릴리즈, 일관된 스토어·정책 정보, 프로덕션 접근을 판단할 수 있는 증거입니다.

Android 비공개 테스트: 6단계의 목표는 네 문서를 따로 완성하는 일이 아니다

스토어 설명은 마케팅 담당자, 데이터 보안은 개발자, 개인정보처리방침은 문서 템플릿에 맡기면 표현이 쉽게 어긋납니다. 예를 들어 스토어에는 “완전한 오프라인 앱”이라고 쓰면서 분석 SDK가 기기 식별자를 서버로 전송하거나, 방침에는 계정 삭제 절차가 있지만 앱에서는 그 기능을 찾을 수 없는 식입니다. 먼저 코드와 실제 동작을 조사해 하나의 기준표를 만들고 모든 답변을 그 표에서 가져와야 합니다.

• 현재 출시할 빌드에 실제로 존재하는 기능
• 요청하는 Android 권한과 사용 시점
• 기기 밖으로 전송되는 데이터와 목적
• 직접 운영하는 서버와 포함된 제3자 SDK
• 보관 기간, 암호화, 삭제 및 계정 탈퇴 방법
• 광고, 사용자 생성 콘텐츠, 위치 공유처럼 등급에 영향을 주는 요소

앱 기능 사실표를 먼저 만든다

기능별로 입력 데이터, 저장 위치, 외부 전송, 사용 SDK, 사용자 제어와 문서 반영 위치를 기록합니다. “개인정보를 수집하지 않는다”처럼 큰 결론부터 적지 말고 각 데이터의 이동 경로를 먼저 적는 것이 중요합니다.

기능	데이터	저장·전송	목적과 제어	반영할 문서
로컬 작업 저장	사용자 입력 내용	기기 내부 DB	핵심 기능, 앱에서 삭제	스토어 설명·개인정보처리방침
오류 보고	충돌 로그·기기 정보	진단 SDK 서버	안정성 개선, SDK 설정 확인	데이터 보안·개인정보처리방침
광고 표시	광고 식별자·상호작용	광고 제공자	광고, 동의·설정 확인	스토어·데이터 보안·등급

AI 에이전트에는 선언이 아니라 조사 결과를 요청한다

현재 Android 릴리즈 후보의 데이터 흐름을 감사해 주세요.

1. AndroidManifest 권한, Gradle 의존성, SDK 초기화 코드와 네트워크 호출을 조사합니다.
2. 기능별 데이터 종류, 기기 내부 처리, 외부 전송 대상과 목적을 표로 정리합니다.
3. 광고·분석·충돌 보고·인증 SDK는 공급자 문서 확인이 필요한 항목으로 표시합니다.
4. 보관 기간, 암호화, 삭제와 사용자 선택 여부를 근거와 함께 기록합니다.
5. 알 수 없는 내용은 추측하지 말고 '확인 필요'로 남깁니다.
6. Play Console 답변을 제출하거나 정책 준수를 단정하지 않습니다.Code language: JavaScript (javascript)

데이터 보안은 코드와 SDK에서 시작한다

Google Play의 데이터 보안 양식에서 수집은 일반적으로 앱에서 사용자 데이터를 기기 밖으로 전송하는 행위를 뜻합니다. 기기 안에서만 처리하는 데이터는 같은 방식으로 신고하지 않지만, 서버 전송이나 포함된 SDK의 전송은 개발자가 직접 보지 못하더라도 검토 대상입니다. 분석·광고·충돌 보고·로그인 SDK의 공식 데이터 보안 안내와 실제 설정을 함께 확인해야 합니다.

내부 테스트 트랙에만 활성화된 앱은 데이터 보안 섹션의 적용 예외가 될 수 있지만, 비공개·공개·프로덕션 트랙으로 확장할 때는 양식을 완성해야 합니다. 데이터를 수집하지 않는 앱도 양식 제출과 개인정보처리방침 링크가 필요하다는 점을 놓치지 않습니다. 자세한 정의는 Google Play 데이터 보안 공식 안내를 기준으로 확인합니다.

개인정보처리방침은 데이터 보안 답변의 긴 버전이 아니다

데이터 보안은 Play 스토어에 정형화된 요약을 보여 주고, 개인정보처리방침은 앱과 개발 주체가 데이터를 어떻게 다루는지 문장으로 설명합니다. 둘의 범위와 표현 방식은 다르지만 사실은 일치해야 합니다. 방침에는 앱 또는 개발자 이름, 수집·이용·공유 항목, 보안 조치, 보관과 삭제, 사용자 권리, 문의 방법과 시행일을 실제 운영에 맞게 적습니다.

• 로그인 없이 공개되고 정상적인 HTTPS 주소에서 열리는가
• 스토어 등록 개발자 또는 앱 이름을 명확히 식별하는가
• 제3자 SDK와 제공받는 주체를 실제 구성에 맞게 설명하는가
• 계정 생성 기능이 있다면 앱 안과 웹에서 탈퇴·삭제 경로를 제공하는가
• 앱 안에서도 방침을 쉽게 찾을 수 있는가
• 기능이나 SDK 변경 시 문서와 데이터 보안 답변을 함께 갱신하는가

스토어 등록 정보는 현재 앱이 증명할 수 있는 만큼만 약속한다

앱 제목, 간단한 설명, 자세한 설명, 아이콘과 스크린샷은 검색 키워드보다 실제 기능을 정확하게 보여 주는 일이 우선입니다. 개발 예정 기능, 다른 서비스와 혼동할 표현, 근거 없는 최고·무료·안전 보장은 제외합니다. 스크린샷은 출시할 빌드에서 직접 만들고, 로그인이나 결제가 필요한 기능은 조건을 숨기지 않습니다.

• 제목: 앱을 식별할 수 있고 다른 제품을 사칭하지 않는다.
• 간단한 설명: 핵심 사용자와 해결하는 문제를 한 문장으로 말한다.
• 자세한 설명: 실제 핵심 기능, 사용 흐름과 제한을 구체적으로 적는다.
• 스크린샷: 현재 UI와 같은 언어·상태를 사용하며 존재하지 않는 기능을 합성하지 않는다.
• 광고·구매: 표시 여부와 유료 기능을 설명과 정책 답변에 일관되게 반영한다.

콘텐츠 등급과 대상 연령은 마케팅 선택이 아니다

콘텐츠 등급 설문은 앱에 실제로 포함되거나 사용자가 접할 수 있는 폭력성, 성적 콘텐츠, 언어, 약물, 도박, 사용자 생성 콘텐츠, 위치 공유와 구매 요소 등을 기준으로 답합니다. 광고가 있다면 앱 자체뿐 아니라 제공될 수 있는 광고의 적절성도 고려합니다. 국가별 등급은 같은 답변에서도 다르게 계산될 수 있습니다.

대상 연령에 어린이가 포함되면 추가 정책이 적용될 수 있으므로 “더 많은 사람에게 노출되기 위해” 연령대를 넓히지 않습니다. 앱 기능이 바뀌어 설문 답변에 영향을 준다면 새 버전 제출 때 등급도 다시 확인합니다. 절차와 질문 기준은 콘텐츠 등급 공식 안내를 따릅니다.

다섯 열의 모순 검사표를 만든다

기능별 행을 만들고 앱 동작, 스토어 설명, 데이터 보안, 개인정보처리방침, 콘텐츠 등급·대상 연령을 열로 둡니다. 한 열이라도 다른 사실을 말하면 제출 전에 원인을 해결합니다. 문서 표현만 고칠 수도 있지만, 불필요한 권한이나 SDK를 앱에서 제거하는 편이 더 올바른 해결일 수 있습니다.

자주 생기는 모순

• 스토어는 오프라인 전용이라고 하지만 분석 SDK가 데이터를 전송한다.
• 데이터를 수집하지 않는다고 답했지만 충돌 보고에 기기 정보가 포함된다.
• 방침에는 계정 삭제가 있지만 앱과 웹 어디에도 삭제 경로가 없다.
• 광고 없음을 강조하지만 광고 SDK나 테스트 광고 설정이 릴리즈에 남아 있다.
• 스크린샷에는 클라우드 동기화가 보이지만 출시 빌드에는 기능이 없다.
• 사용자 게시물이 있는데 콘텐츠 등급과 신고·차단 절차에 반영하지 않았다.

내부 테스트에서 비공개 테스트로 확장한다

내부 테스트가 설치 경로와 핵심 기능을 빠르게 확인하는 단계였다면 비공개 테스트는 목표 사용자에 가까운 더 넓은 그룹으로 정책 정보와 실제 사용 경험까지 검증하는 단계입니다. 프로덕션 접근 요건이 적용되는 신규 개인 계정은 Play Console에 표시되는 테스터 수와 연속 참여 기간을 충족하고, 실제 피드백과 수정 내용을 남겨야 합니다.

1. 내부 테스터와 비공개 테스터의 계정·트랙 중복을 정리한다.
2. 목표 사용자와 기기 다양성을 반영해 테스터를 모집한다.
3. 핵심 시나리오와 피드백 양식을 전달한다.
4. 치명적 문제와 정책 문서의 불일치를 먼저 수정한다.
5. 새 AAB와 변경사항을 올리고 업데이트 경로를 다시 확인한다.
6. 프로덕션 접근 신청에는 실제 테스트 과정과 개선 내용을 사실대로 설명한다.

프로덕션 제출 전에 마지막으로 확인한다

• 스토어의 모든 이미지와 설명이 현재 릴리즈 빌드와 일치한다.
• 권한, SDK, 네트워크 호출과 데이터 보안 답변을 대조했다.
• 개인정보처리방침 URL이 공개되어 있고 앱 안에서도 접근 가능하다.
• 계정 생성 앱은 실제 작동하는 계정·데이터 삭제 방법을 제공한다.
• 콘텐츠 등급, 대상 연령, 광고와 사용자 생성 콘텐츠 답변이 정확하다.
• 로그인이 필요한 앱은 검토용 계정과 접근 방법을 제공한다.
• 사전 출시 보고서와 비공개 테스트의 출시 차단 문제를 해결했다.
• 국가, 가격, 지원 이메일과 배포 기기 범위를 확인했다.
• 첫 공개는 가능한 경우 단계적으로 확대하고 중단 기준을 정했다.

마무리: 여기서 시리즈를 마치고 필요한 부분을 계속 보충한다

Play Console 질문에 그럴듯한 답을 만드는 것보다 중요한 일은 앱과 SDK가 실제로 어떤 데이터를 다루고 사용자에게 무엇을 보여 주는지 증명하는 것입니다. 하나의 기능 사실표에서 네 문서를 작성하면 정책 변경이나 새 SDK 추가 때 수정할 위치도 명확해집니다. 프로덕션 준비는 심사를 통과하기 위한 포장이 아니라 사용자에게 한 약속을 코드와 운영으로 지키는 과정입니다.

아이디어 검증과 MVP 설계에서 시작해 프로젝트 준비, AI 에이전트를 이용한 구현, 앱 서명, 내부·비공개 테스트와 프로덕션 준비까지 이어진 대략적인 순서의 글은 이번 편으로 마무리합니다. 실제 Android 앱 개발은 한 방향으로만 진행되지 않고, 앱의 기능과 상황에 따라 다시 앞 단계로 돌아가거나 여러 문제를 동시에 해결해야 하기 때문입니다.

앞으로는 단계 번호나 정해진 순서 없이 Android 앱 개발에 바로 활용할 수 있는 프롬프트, 바이브 코딩 팁, 빌드·배포 과정에서 만난 문제와 해결 방법을 개별 주제로 다룰 계획입니다. 또한 이번 시리즈에서 자세히 설명하지 못했거나 실제 개발 과정에서 새롭게 확인한 내용은 보충 글로 계속 연결하겠습니다. 필요한 글부터 골라 읽고 자신의 프로젝트에 맞게 적용할 수 있는 실전 기록을 쌓아가겠습니다.

관련 글: 키스토어 생성과 앱 서명 안전하게 구성하기 · AAB 만들고 내부 테스트로 배포하기