Google Play 앱 출시 준비부터 심사 제출까지

앱 기능을 완성하고 릴리스 빌드까지 만들었는데 Play Console을 열면 해야 할 일이 다시 쌓여 있습니다. 앱 이름과 설명, 스크린샷, 개인정보처리방침, 데이터 보안, 콘텐츠 등급, 테스트 트랙, 심사용 로그인 정보가 각각 다른 메뉴에 있기 때문입니다. 준비 없이 순서대로 입력하면 마지막 단계에서 정책 문서나 테스트 기간 때문에 출시 일정이 밀릴 수 있습니다.

이 글은 국내 1인 개발자가 일반적인 안드로이드 앱을 처음 등록하는 상황을 기준으로, 개발 단계에서 무엇을 고정하고 어떤 순서로 Play Console을 채워야 하는지 정리합니다. Google Play 요건은 계정 유형, 앱 기능, 대상 국가와 시점에 따라 달라지므로 2026년 8월 30일 확인한 Google 공식 문서를 기준으로 작성했습니다.

출시 준비는 빌드, 테스트, 스토어 정보, 정책 답변을 따로 끝내는 일이 아니라 네 가지가 같은 앱을 설명하도록 맞추는 작업입니다.

출시 준비의 핵심

1. 출시 일정을 네 갈래로 나누기

출시일만 정해두고 개발이 끝난 뒤 등록 작업을 시작하면 정책 페이지 제작과 테스터 모집이 병목이 됩니다. 처음부터 준비 항목을 네 갈래로 나누고 동시에 진행하는 편이 안전합니다. 빌드가 바뀌면 데이터 보안 답변이 바뀔 수 있고, 스토어 설명이 실제 기능보다 앞서가면 심사에서 문제가 될 수 있으므로 한 사람이 최종 일치 여부를 확인해야 합니다.

2. 계정과 앱 식별정보를 먼저 고정하기

Play Console에서 앱을 만들기 전에 개인 계정과 조직 계정 중 실제 운영 주체에 맞는 계정을 선택하고, 개발자 이름·주소·지원 이메일처럼 사용자에게 공개되거나 검증에 사용될 정보를 정리합니다. 사업자 명의로 운영한다면 홈페이지와 개인정보처리방침, 문의 메일의 운영자 정보도 같은 기준으로 맞추는 편이 좋습니다.

패키지명은 단순한 프로젝트 설정값이 아닙니다. Google Play에서 앱을 식별하고 업데이트를 이어가는 기준이므로 테스트용 이름이나 다른 회사 도메인을 넣은 채 첫 빌드를 만들지 않습니다. 앱 이름은 나중에 다듬을 수 있지만 패키지명과 서명 체계는 첫 출시 전에 충분히 검토해야 합니다.

• 실제 운영 주체와 일치하는 개발자 계정을 사용한다
• 장기간 유지할 패키지명을 확정했다
• 지원 이메일과 홈페이지 주소가 외부에서 정상 접속된다
• 앱 이름과 개발자 이름이 정책 문서의 운영자 정보와 일치한다
• 계정 소유자 외에 필요한 사용자의 권한 범위를 구분했다

3. 제출용 AAB와 서명을 릴리스 기준으로 점검하기

디버그 빌드가 잘 실행된다는 사실만으로 제출 준비가 끝나지는 않습니다. 난독화, 리소스 축소, 환경변수, API 주소, 결제 키와 서명 설정이 적용된 릴리스 빌드 자체를 테스트해야 합니다. Play Console에는 Android App Bundle(AAB)을 올리고, Play App Signing 설정과 업로드 키 보관 방식을 확인합니다. 업로드 키와 저장소 비밀번호를 개인 메모 한 곳에만 남겨두는 방식은 피합니다.

버전 관리는 사용자에게 보이는 버전 이름과 Play Console이 업데이트 순서를 판단하는 버전 코드를 구분합니다. 이미 사용한 버전 코드는 다시 올릴 수 없으므로 CI나 릴리스 문서에서 증가 규칙을 정해두는 것이 좋습니다. 테스트 트랙에 올린 빌드와 실제 프로덕션 후보가 같은 커밋에서 만들어졌는지도 기록합니다.

타깃 API 요구사항은 제출 직전에 다시 확인한다

Google의 타깃 API 요구사항에 따르면 2026년 8월 31일부터 일반 모바일 신규 앱과 업데이트는 Android 16(API 36) 이상을 타깃으로 해야 합니다. Wear OS·Android Automotive OS·Android TV·Android XR에는 별도 기준이 적용됩니다. 마감 직전에 targetSdk만 올리면 권한과 백그라운드 동작이 달라질 수 있으므로 Android 버전별 동작 변경을 먼저 확인하고 실제 기기에서 회귀 테스트합니다.

• 릴리스 AAB가 프로덕션 API와 설정을 사용한다
• versionCode가 이전 업로드보다 크다
• Play App Signing과 업로드 키 복구 방법을 확인했다
• 현재 제출일에 적용되는 target API 기준을 충족한다
• 릴리스 빌드를 Play 배포 경로에서 설치해 실행했다

4. 테스트 트랙을 출시 절차로 사용하기

로컬에서 APK를 설치하는 것과 Google Play를 통해 배포된 앱을 설치하는 것은 다릅니다. 서명, 앱 번들 분할, 인앱 업데이트, 결제 테스트, 설치 가능한 기기 조건을 확인하려면 Play Console의 테스트 트랙을 사용해야 합니다. 내부 테스트에서 빠르게 빌드를 확인하고, 비공개 테스트에서 실제 사용자 흐름과 피드백을 검증한 뒤 프로덕션으로 이동하는 순서가 기본입니다.

2023년 11월 13일 이후 생성된 개인 개발자 계정은 최소 12명의 테스터가 14일 동안 연속으로 참여한 비공개 테스트를 완료해야 프로덕션 접근을 신청할 수 있습니다.

신규 개인 계정 테스트 요건

이 요건은 Google의 신규 개인 계정 테스트 안내에서 확인할 수 있습니다. 테스터가 중간에 참여를 취소하면 연속 기간 계산에 영향을 줄 수 있고, 프로덕션 접근 신청 시 앱과 테스트 과정, 받은 피드백, 출시 준비 상태에 관한 질문에 답해야 합니다. 출시일을 정한 다음 테스터를 구하면 최소 기간 때문에 일정을 맞추기 어렵습니다.

실제 사용자 흐름을 기준으로 테스트한다

• 신규 설치 후 첫 실행과 온보딩
• 회원가입·로그인·로그아웃과 계정 복구
• 권한을 허용했을 때와 거부했을 때의 흐름
• 결제·구독·복원·취소 상태의 화면
• 오프라인, 느린 네트워크와 서버 오류
• 백그라운드 복귀, 화면 회전과 프로세스 재시작
• 이전 버전에서 새 버전으로 업데이트
• 계정과 사용자 데이터 삭제 경로

5. 스토어 등록정보를 제품 설명서처럼 만들기

스토어 등록정보는 검색 결과와 상세 페이지에서 사용자가 앱 설치 여부를 판단하는 자료입니다. 앱 생성과 등록정보 공식 안내 기준으로 앱 이름은 30자, 간단한 설명은 80자, 자세한 설명은 4,000자 제한입니다. 글자 수를 채우는 것보다 첫 문장에서 누구의 어떤 문제를 해결하는지 밝히고, 이후에 실제 기능과 사용 조건을 설명하는 편이 낫습니다.

아이콘, 그래픽 이미지와 스크린샷은 디자인 장식이 아니라 기능 증거입니다. 로그인 화면만 여러 장 올리거나 앱에서 볼 수 없는 합성 화면을 사용하지 않습니다. 미리보기 애셋 요구사항을 확인하고, 각 기기 유형에 맞는 크기와 수량을 준비합니다. 공식 안내는 스토어 등록정보 게시를 위해 서로 다른 기기 유형을 합쳐 최소 두 장의 스크린샷을 요구합니다.

1. 대표 기능이 실제로 동작하는 화면을 먼저 고릅니다.
2. 스크린샷 한 장에는 하나의 핵심 메시지만 전달합니다.
3. 작은 글자를 늘어놓기보다 화면 자체가 읽히도록 촬영합니다.
4. 무료·유료 기능, 계정 필요 여부처럼 설치 전 알아야 할 조건을 설명합니다.
5. 앱 업데이트로 UI가 바뀌면 스토어 이미지도 함께 교체합니다.

6. 데이터 보안과 개인정보처리방침을 코드 기준으로 맞추기

데이터 보안 양식은 앱 소개 문구가 아니라 실제 코드와 SDK가 어떤 데이터를 처리하는지 공개하는 문서입니다. Google은 모든 Play 게시 앱의 개발자가 데이터 수집·공유·보호 방식을 신고하도록 안내하며, 앱에 포함된 제3자 라이브러리와 SDK의 처리도 개발자 답변에 포함해야 한다고 명시합니다.

데이터를 직접 서버에 저장하지 않는다는 이유만으로 ‘수집 안 함’을 선택하면 안 됩니다. 광고, 분석, 오류 보고, 로그인, 결제 SDK가 기기 식별자나 진단 정보 등을 전송할 수 있습니다. 선언 전에 AndroidManifest 권한, 네트워크 요청, SDK 목록과 각 공급자의 데이터 보안 안내를 함께 검토합니다.

Google 안내상 비공개·공개·프로덕션 트랙에 게시된 앱은 데이터 보안 양식을 작성해야 하며, 데이터를 수집하지 않는 앱도 양식과 개인정보처리방침 링크가 필요합니다. 개인정보처리방침은 외부에서 열리는 공개 URL이어야 하고, 앱 이름과 운영자, 처리 목적, 보관·삭제, 문의 방법이 실제 앱과 일치해야 합니다.

7. 앱 콘텐츠 메뉴를 심사 전에 끝내기

Play Console의 앱 콘텐츠 영역에는 개인정보처리방침 외에도 광고 포함 여부, 앱 액세스, 타깃층과 콘텐츠, 콘텐츠 등급, 뉴스 앱 여부 등 앱에 따라 필요한 선언이 표시됩니다. 대시보드의 할 일 목록을 하나씩 없애되, 답변은 스토어 설명과 코드 동작을 기준으로 작성합니다.

로그인이 필요한 앱은 심사 계정을 따로 준비한다

앱의 주요 기능이 로그인 뒤에 있다면 심사자가 접근할 수 있는 계정과 사용 절차를 앱 액세스 항목에 제공합니다. 일회용 비밀번호, 특정 국가 전화번호, 사내 VPN, 초대 코드처럼 심사자가 통과하기 어려운 조건은 별도 안내가 필요합니다. 테스트 계정은 심사 기간에 만료되거나 비밀번호가 바뀌지 않도록 관리하고 실제 개인정보를 넣지 않습니다.

• 개인정보처리방침 URL이 로그인 없이 열린다
• 데이터 보안 답변이 현재 SDK와 권한을 반영한다
• 광고, 콘텐츠 등급과 타깃층 답변이 실제 앱과 일치한다
• 심사용 계정과 로그인 절차가 준비되어 있다
• 계정 생성 앱이라면 사용자 데이터 삭제 경로를 확인했다

8. 심사 제출은 이 순서로 마무리하기

1. 앱 식별정보와 개발자 계정 검증 상태를 확인합니다.
2. 릴리스 AAB를 내부 테스트에 올리고 Play 경로로 설치합니다.
3. 주요 기능과 권한, 로그인, 결제, 데이터 삭제를 테스트합니다.
4. 스토어 설명과 이미지 자료를 현재 빌드에 맞춰 등록합니다.
5. 개인정보처리방침과 데이터 보안 등 앱 콘텐츠 항목을 완료합니다.
6. 계정에 적용되는 비공개 테스트와 프로덕션 접근 요건을 충족합니다.
7. 프로덕션 릴리스를 만들고 국가·배포 비율·출시 시점을 검토합니다.
8. 오류와 경고, 정책 상태를 다시 확인한 뒤 심사에 제출합니다.

심사 기간은 고정된 배포 시간이 아닙니다. 출시일에 맞춰 당일 제출하기보다 보완과 재심사 시간을 포함한 여유를 둡니다. 첫 출시라면 자동 게시 여부와 관리형 게시 기능도 확인해 승인되는 즉시 공개할지, 승인 후 직접 공개할지 결정합니다.

9. 제출 직전에 자주 발견되는 불일치

가장 흔한 문제는 각각의 입력을 완료했지만 서로 맞지 않는 경우입니다. 앱은 위치 권한을 요청하는데 데이터 보안에는 위치 처리가 없거나, 스토어 설명에는 회원가입 없이 쓸 수 있다고 적었는데 실제 첫 화면은 로그인을 요구할 수 있습니다. 스크린샷에 있는 기능이 출시 빌드에서 비활성화되어 있거나 심사용 계정이 만료되는 경우도 같은 유형입니다.

제출 전에는 개발자 관점이 아니라 처음 설치한 사용자 관점으로 한 번 더 확인합니다. 새 Google 계정과 초기화한 테스트 기기를 사용하고, 별도 설명 없이 설치부터 주요 기능 완료와 계정 삭제까지 진행해봅니다. 이 과정에서 막히는 부분은 심사자와 실제 사용자도 막힐 가능성이 높습니다.

최종 출시 체크리스트

• 패키지명, 서명, 버전 코드와 target API를 확인했다
• 릴리스 AAB를 Play 테스트 트랙에서 설치했다
• 계정에 적용되는 테스터 수와 테스트 기간을 충족했다
• 앱 이름, 설명, 아이콘과 스크린샷이 실제 기능과 일치한다
• 모든 SDK와 권한을 포함해 데이터 보안 답변을 검토했다
• 개인정보처리방침과 계정 삭제 경로가 외부에서 열린다
• 심사용 계정으로 주요 기능에 접근할 수 있다
• 공개 국가, 배포 방식과 게시 시점을 확인했다

Google Play 출시는 개발의 마지막 버튼이 아니라 운영의 첫 배포입니다. 빌드와 정책 문서를 따로 준비하지 말고, 릴리스 AAB에서 실제로 동작하는 내용이 테스트 결과·스토어 설명·데이터 보안 답변에 동일하게 나타나는지를 마지막 기준으로 삼으면 심사 대응과 이후 업데이트가 훨씬 단순해집니다.