Android 플레이스토어에 앱을 출시하며

들어가며

1주일의 준비와 2주의 대기 끝에 앱을 플레이스토어에 출시했다.

앱스토어는 심사가 까다롭다고들 하는데, 플레이스토어는 그에 비하면 심사 기준이 덜 엄격한 편이다. 대신 2주간 20명의 닫힌 테스팅을 의무적으로 진행해야 하는 절차가 있어서, 이 부분을 미리 준비하지 않으면 출시 일정이 꼬일 수 있다.

이번 글에는 삽질했던 부분들을 정리해둔다. Expo를 쓴다면 특히 볼 만할 것이다.

배포 방법

플레이스토어에 앱을 올리려면 먼저 AAB(Android App Bundle) 파일을 생성해야 한다. 방법은 두 가지인데, 상황 봐서 고르면 된다.

로컬에서 직접 빌드

가장 기본적인 방법이다. 내 컴퓨터에서 직접 빌드하는 방식이라 과정을 하나하나 눈으로 확인할 수 있어서 처음 배포할 때는 이 방법을 추천한다.

1. npx expo prebuild : 네이티브 프로젝트 생성
2. cd android : android 폴더로 이동
3. ./gradlew bundleRelease : Gradle로 release AAB 생성

명령어를 실행하면 android/app/build/outputs/bundle/release/app-release.aab 경로에 AAB 파일이 생성된다. 이 파일을 플레이 콘솔에 업로드하면 된다.

로컬 빌드의 장점은 빌드 과정을 직접 제어할 수 있다는 점이다. 에러가 발생하면 로그를 바로 확인할 수 있고, 필요하면 Gradle 설정도 직접 수정할 수 있다. 다만 처음에는 환경 설정이 조금 까다로울 수 있는데, JDK 버전이나 Android SDK 경로 같은 걸 제대로 맞춰줘야 한다.

EAS를 활용한 빌드

실무에서 일하다 보면 로컬 빌드는 한계가 있다. 팀원마다 개발 환경이 다르고, CI/CD를 구축하려면 어차피 클라우드 빌드가 필요하다. 그래서 나는 로컬 빌드에서 익숙해진 후에는 EAS(Expo Application Services)로 넘어갔다.

1. eas build --platform android --profile production
2. eas submit --platform android

EAS는 Android Studio가 없어도 된다. 클라우드에서 알아서 빌드해주니 내 컴퓨터 성능이나 환경에 구애받지 않는다. 빌드 로그도 웹에서 깔끔하게 볼 수 있고, 팀원들과 결과물을 공유하기도 편하다. 대신 무료 플랜은 빌드 횟수가 제한되고, 대기열이 길면 시작까지 한참 걸린다. 그래도 처음 몇 번은 무료 플랜으로 충분하다.

EAS의 설정 파일(eas.json)은 마음에 드는데 빌드 횟수 제한이나 대기열이 부담스럽다면, --local 옵션을 쓰는 방법도 있다.

이렇게 하면 EAS의 빌드 설정은 그대로 쓰면서 내 컴퓨터에서 빌드할 수 있다. 클라우드 기능(자동 버전 관리, 빌드 아티팩트 저장 등)은 못 쓰지만, 급하게 빌드해야 할 때 유용하다.

심사 제출

안드로이드에는 아이폰의 TestFlight 같은 별도의 테스트 앱이 없다. 대신 Google Play Console 자체에서 제공하는 테스팅 트랙을 활용하면 된다. 플레이 콘솔에서는 세 가지 테스팅 트랙을 제공한다. 개발 단계에 맞게 활용하면 효율적으로 앱을 검증할 수 있다.

1. 내부 테스트 : 개발 초기 단계나 급하게 확인해야 할 때 쓰는 트랙이다. 심사 없이 몇 분 내로 바로 테스트할 수 있어서 제일 자주 사용한다. 최대 100명까지 이메일로 초대할 수 있고, 버그 수정 후 빠르게 검증하기 좋다.
2. 닫힌 테스트 : 프로덕션 출시 전에 2주간 20명 이상의 닫힌 테스팅이 필수다. 내부 테스트보다 실제 유저 환경에 가까운 조건에서 테스트할 수 있다. 인원 제한은 없고, 여러 트랙(알파, 베타 등)을 만들어 관리할 수도 있다.
3. 열린 테스트 : 누구나 참여할 수 있는 공개 테스트다. 플레이스토어에서 "테스터 되기"로 참여할 수 있어서, 출시 전에 얼리어답터를 모으는 용도로도 활용할 수 있다.

테스트를 마쳤다면, 이제 Production을 눌러 제출하면 된다.

팁

2주의 닫힌 테스팅 기간

앞서 말했듯이 플레이스토어는 2주간 20명 이상의 닫힌 테스팅을 의무적으로 진행해야 한다. 처음에는 "2주나 기다려야 해?"라고 생각했는데, 실제로 해보니 이 기간이 꽤 유용했다. 내부 테스트와 다르게 닫힌 테스트는 실제 유저들과 비슷한 환경에서 앱을 검증할 수 있다. 테스터들은 플레이스토어를 통해 앱을 받기 때문에, 설치부터 업데이트까지 전체 플로우를 확인할 수 있다.

실제로 닫힌 테스팅을 진행하면서 로그인이 잘 안 되는 이슈라든가, http프로토콜의 웹사이트로 이동하면 에러가 발생하는 등의 이슈를 미리 발견해서 해결할 수 있었다.

주의 사항

실제로 배포하면서 몇 가지 삽질했던 부분들을 공유한다. 미리 알았다면 시간을 많이 절약했을 텐데 싶은 것들이다.

eas submit으로 플레이스토어에 직접 제출하려고 할 때, 초기 설정이 필요하다.

eas submit으로 플레이스토어에 직접 제출하려면 처음에 설정이 필요하다. Expo 공식 문서(creating-google-service-account.md)를 따라 하면 되는데, 여기서 하나 놓치기 쉬운 부분이 있다.

Google Cloud Console에서 서비스 계정을 만들고 account.json 파일을 다운로드받으면, 자동으로 이메일 주소가 생성된다. 대충 이런 형식이다.

여기서 중요한 건, 이 이메일 주소를 Play Console에 꼭 초대해줘야 한다는 점이다. 나는 이걸 빼먹어서 한참 헤맸는데, Play Console → 사용자 및 권한에서 해당 이메일을 추가하고 적절한 권한을 줘야 EAS에서 자동 제출이 가능하다.

AAB 파일은 바로 테스트가 안 된다

AAB(Android App Bundle) 파일은 플레이스토어에 업로드하기 위한 포맷이지, 실제 기기에서 바로 실행할 수 있는 파일이 아니다.

빌드는 됐는데 폰에 설치가 안 된다면 AAB를 APK로 변환해야 한다. 방법은 몇 가지가 있다.

1. bundletool 사용하기

# bundletool로 APK set 생성
bundletool build-apks --bundle=app-release.aab --output=app.apks

# 특정 기기에 맞는 APK 추출 및 설치
bundletool install-apks --apks=app.apks

2. 웹 서비스 활용하기

3. 내부 테스트 트랙 활용하기

맺으며

플레이스토어 배포를 처음 준비하면서 가장 당황스러웠던 건 2주간의 닫힌 테스팅 의무 기간이었다. 앱스토어는 심사가 까다롭다는 얘기를 많이 들어서 각오하고 있었는데, 정작 플레이스토어는 심사 기준은 비교적 느슨한 대신 이 대기 기간이 있었다. 앱스토어가 최대 48시간 안에 심사 결과를 주는 것과 비교하면, 오히려 플레이스토어 쪽이 출시까지 더 오래 걸릴 수도 있겠다는 생각이 들었다. 물론 이 48시간은 어디까지나 ‘한 번 심사에 걸리는 시간’이다. 리젝을 받고 고쳐서 다시 넣는 과정을 반복하다 보면 앱스토어도 출시까지 총 며칠, 길게는 몇 주가 걸리기도 한다. (실제로 내 iOS 앱은 리젝만 7번 받아서 3주가 걸렸다.) 앱스토어는 리젝을 받을수록 늘어나고, 플레이스토어는 2주가 고정으로 깔린다. 성격이 다르다.

하지만 막상 2주를 겪어보니 이 기간이 마냥 손해는 아니었다. 실제 사용자 환경과 거의 동일한 조건에서 테스트할 수 있어서, 개발 환경에서는 발견하지 못했던 문제들을 미리 잡아낼 수 있었다. 특히 네트워크 설정이나 권한 관련 이슈는 닫힌 테스팅을 하지 않았다면 출시 후에야 발견했을 것들이다.

앱스토어는 심사로, 플레이스토어는 테스트 기간으로 품질을 거른다. 각각의 특성을 이해하고 일정을 짜야 한다는 걸 배웠다.

첫 배포는 언제나 배울 게 많다. 특히 2주 테스팅 기간을 미리 감안해서 출시 일정을 잡으시길. 그리고 막히는 부분이 있어도 너무 조급해하지 마시길.