Play Console

Play Console 은 개발자가 만든 Android 앱을 Google Play 스토어에 내보내 줍니다. 앱 파일을 올리는 일부터 사용자에게 공개하는 일까지 웹 브라우저 한 화면에서 합니다. 출시한 뒤에는 앱이 얼마나 자주 죽는지와 사용자 평가도 여기서 봅니다.

쉽고 빠른 이해

무슨 일을 하나 — Android 앱을 Google Play 스토어에 올리는 Google 의 관리 화면입니다. 새로 빌드한 앱 파일을 올립니다. 누구에게 먼저 줄지 고른 뒤 공개합니다. Google Play 로 내는 앱에만 씁니다. 사내 기기에만 까는 앱이나 다른 스토어로 내는 앱에는 안 씁니다.

왜 이렇게 하나 — Android 앱을 Google Play 에 내려면 반드시 이 화면을 거칩니다. 스토어에 나가는 앱은 Google 이 먼저 살펴봅니다. 사용자 전부에게 한 번에 내보내면 버그도 모두에게 퍼집니다. 그래서 올리는 것과 공개하는 것 사이에 테스트와 심사와 조금씩 넓히기가 끼어 있습니다.

어떻게 도나

1. 앱 항목을 만들고 서명한 앱 파일을 올립니다
2. 소수의 테스터에게 먼저 나눠 줍니다
3. 심사를 통과하면 사용자 일부에게 열고 차츰 넓힙니다

대가 — 앱을 가리키는 고유 이름은 한 번 올린 뒤로 못 바꿉니다. 나간 버전을 옛 버전으로 되돌릴 수도 없습니다. 고친 새 버전을 다시 올려야 합니다.

상세

Play Console 이 맡는 범위는 Android 앱 하나를 스토어까지 내보내고 그 뒤를 지켜보는 일 전부입니다. 이 절은 앱 하나가 등록되어 사용자 기기에 깔리기까지를 따라갑니다.

먼저 이름이 비슷한 셋을 가릅니다. 그다음 앱을 가리키는 이름, 올리는 파일, 서명, 출시 단계, 스토어 등록 정보, 출시 뒤에 보는 화면을 차례로 봅니다. 마지막으로 Play Console 을 거치지 않는 배포를 봅니다.

이름이 비슷한 셋

Play Console 은 Google 이 운영하는 웹 서비스입니다. 받아서 설치하는 프로그램이 아니라 브라우저로 들어가 쓰는 관리 화면입니다. Android 앱을 Google Play 에 내려면 이 화면을 거쳐야 합니다.

비슷한 이름이 둘 더 있어서 헷갈리기 쉽습니다. 셋은 맡는 일이 다릅니다.

Play Console 에 들어가려면 개발자 계정부터 만듭니다. 계정을 만든 사람이 소유자가 됩니다. 다른 팀원은 초대를 받아 들어옵니다. 팀원마다 권한을 따로 줄 수 있습니다. 출시만 맡는 사람과 매출만 보는 사람을 가를 수 있다는 뜻입니다.

앱 하나를 가리키는 패키지 이름

Play Console 은 앱을 패키지 이름으로 가립니다. 패키지 이름은 com.example.shop 처럼 도메인을 거꾸로 적은 꼴의 고유 이름입니다. 기기 안에서도, 스토어 안에서도 이 이름 하나가 그 앱을 가리킵니다.

이 이름은 앱 파일을 처음 올리는 순간 그 앱에 묶입니다. 그 뒤로는 바꿀 수 없습니다. 이름을 바꾸고 싶으면 새 앱으로 다시 등록해야 합니다. 그러면 기존 사용자와 평가는 옛 앱에 남습니다.

Android App Bundle 을 올린다

개발자가 Play Console 에 올리는 파일은 Android App Bundle 입니다. 줄여서 AAB 라고 씁니다. AAB 는 앱의 코드와 리소스를 모두 담은 꾸러미입니다. 기기에 바로 설치하는 파일이 아니라 설치 파일을 만들 재료입니다.

기기에 실제로 설치되는 파일은 APK(Android Package, 안드로이드 패키지)입니다. Google Play 는 AAB 를 받아 기기마다 맞는 APK 를 만들어 내려보냅니다. 화면 해상도나 프로세서 종류가 다른 기기는 저마다 필요한 조각만 받습니다. 그래서 사용자가 내려받는 크기가 줄어듭니다.

올리는 파일마다 버전 코드가 붙습니다. 버전 코드는 앱 파일에 적는 정수입니다. 새 파일을 올릴 때마다 앞의 것보다 커야 합니다. Play Console 은 이 숫자로 어느 파일이 더 새것인지 판단합니다. 사용자에게 보이는 「1.2.0」 같은 버전 이름과는 따로 놉니다.

서명 키를 Google 이 쥔다

Android 기기는 서명이 없는 앱을 설치하지 않습니다. 코드 서명은 이 파일을 누가 만들었고 중간에 바뀌지 않았는지를 보증하는 절차입니다. 같은 앱의 새 버전은 이전 버전과 같은 키로 서명되어 있어야 기기가 갱신으로 받아들입니다.

AAB 를 올리면 실제 APK 는 Google 이 만듭니다. 그래서 최종 서명도 Google 이 해야 합니다. 이 방식을 Play App Signing 이라고 부릅니다. 키가 둘로 갈립니다.

아래 그림은 AAB 하나가 기기에 닿기까지 서명이 어떻게 바뀌는지 보입니다.

flowchart TD
    A["개발자 컴퓨터 · 업로드 키로 AAB 서명"] --> B["Play Console · 업로드 서명 확인"]
    B --> C["Google Play · 기기별 APK 생성"]
    C --> D["앱 서명 키로 APK 서명"]
    D --> E["사용자 기기 · 앱 서명 확인 뒤 설치"]

키를 둘로 가르면 잃어버렸을 때 덜 아픕니다. 업로드 키를 잃으면 Google 에 요청해 새 업로드 키로 바꿀 수 있습니다. 기기가 보는 앱 서명 키는 Google 이 들고 있어서 그대로 남기 때문입니다. 그 대신 앱의 최종 서명은 개발자가 아니라 Google 이 쥡니다.

트랙과 출시

Play Console 에서 앱을 누구에게 줄지는 트랙으로 정합니다. 트랙은 같은 앱을 받는 사용자 집단입니다. 한 앱에 트랙이 여럿 있습니다. 트랙마다 다른 버전을 내보낼 수 있습니다.

앞의 세 트랙을 묶어 테스트 트랙이라 합니다. 마지막은 프로덕션 트랙입니다. 트랙에 내보내는 한 번의 묶음을 릴리스라고 부릅니다. 릴리스에는 AAB 와 이번 버전에서 바뀐 것을 적은 출시 노트가 담깁니다.

보통은 좁은 트랙에서 넓은 트랙으로 옮겨 갑니다. 내부 테스트에서 문제가 없던 릴리스를 비공개 테스트로 올립니다. 거기서도 괜찮으면 프로덕션으로 올립니다. 네 트랙을 모두 차례로 거쳐야 하는 것은 아닙니다. 이 예처럼 공개 테스트는 건너뛰어도 됩니다.

같은 AAB 를 다시 올리지 않고 릴리스를 다음 트랙으로 넘길 수 있습니다. 이 동작이 승격입니다.

심사와 단계적 출시

릴리스를 공개하기 전에 Google 이 심사를 합니다. 심사는 앱이 Google Play 의 정책을 지키는지 살피는 절차입니다. 정책을 어기면 릴리스가 거절됩니다. 이미 나간 앱도 내려갈 수 있습니다. 심사에 걸리는 시간은 그때그때 다릅니다.

프로덕션에 내보낼 때는 사용자 전부에게 한 번에 줄 필요가 없습니다. 그렇게 주면 새 버전의 버그도 모두에게 닿습니다. 단계적 출시는 새 버전을 사용자 가운데 일정 비율에게만 먼저 여는 방식입니다. 처음에는 사용자 가운데 적은 비율에게만 엽니다. 오류 보고를 지켜본 뒤 그 비율을 단계마다 올립니다. 문제가 보이면 출시를 멈춥니다.

단계적 출시는 이미 나간 앱의 갱신에만 씁니다. 앱을 처음 게시할 때는 쓸 수 없습니다.

멈추는 것과 되돌리는 것은 다릅니다. 이미 새 버전을 받은 사용자는 옛 버전으로 돌아가지 않습니다. 고치려면 버전 코드를 올린 새 버전을 만들어 다시 출시해야 합니다. 서버 배포에서 이전 버전으로 바로 돌리는 롤백과 크게 다른 대목입니다.

아래 그림은 릴리스 하나가 심사부터 단계적 출시까지 지나는 길입니다. 문제가 보였을 때 가는 길은 새 버전 하나뿐입니다.

flowchart TD
    A["릴리스"] --> B["심사"]
    B -->|정책 위반| X["거절"]
    B -->|통과| C["사용자 일부에게 공개"]
    C --> D["오류 보고를 지켜봄"]
    D --> E{"문제가 보이나"}
    E -->|아니다| F["비율을 올림"]
    F --> D
    E -->|보인다| G["출시 멈춤"]
    G --> H["버전 코드를 올린 새 버전"]
    H --> B

그림에 옛 버전으로 돌아가는 화살표가 없다는 점이 요점입니다. 이미 받은 사용자를 고치는 길은 앞으로 나가는 새 버전뿐입니다.

스토어 등록 정보와 정책 신고

앱을 공개하려면 스토어 페이지에 보일 정보를 채웁니다. 이 정보가 스토어 등록 정보입니다. 앱 이름, 짧은 설명과 긴 설명, 아이콘, 스크린샷이 여기 들어갑니다.

앱의 성격을 Google 에 알리는 신고도 함께 합니다. 신고한 내용은 심사의 기준이 됩니다. 일부는 스토어 페이지에도 보입니다.

백엔드 개발자에게는 데이터 보안 항목이 특히 걸립니다. 앱이 서버로 보내는 데이터가 바뀌면 이 신고도 같이 고쳐야 하기 때문입니다.

출시 뒤에 보는 화면

앱이 나간 뒤에도 Play Console 은 사용자 기기에서 앱이 어떻게 도는지 모아 보여 줍니다. 그중 앱 품질을 재는 화면이 Android vitals 입니다.

Android vitals 가 보는 대표 값은 둘입니다. 하나는 앱이 갑자기 꺼지는 크래시의 비율입니다. 다른 하나는 ANR(Application Not Responding, 앱 응답 없음)의 비율입니다. ANR 은 앱이 화면 입력에 한동안 답하지 못해 시스템이 경고를 띄우는 상태입니다.

이 값이 나쁘면 스토어에서 앱이 덜 노출될 수 있습니다. 그래서 출시 뒤에도 이 화면을 계속 봅니다. 사용자가 남긴 평점과 리뷰도 여기서 보고 답글을 답니다.

Play Console 을 거치지 않는 배포

Android 는 스토어를 거치지 않아도 앱을 설치할 수 있습니다. APK 파일을 직접 받아 까는 일이 사이드로딩입니다. 다른 회사가 운영하는 앱 스토어로 내는 앱도 Play Console 과 무관합니다.

Play Console 은 Google Play 로 나가는 앱만 다룹니다. 사내 기기에만 까는 앱이나 다른 스토어 전용 앱이라면 Play Console 을 쓸 이유가 없습니다.

맞물림

Play Console 은 혼자서 앱을 만들지도, 기기에 깔지도 않습니다. 앞뒤에 Google 의 다른 도구와 서비스가 붙어야 앱이 사용자에게 닿습니다. 이 절은 그중 다섯을 봅니다. 올릴 파일을 만드는 쪽, 파일을 기기로 나르는 쪽, 출시를 자동으로 돌리는 쪽, 결제를 확인하는 쪽, 출시 전에 앱을 돌려 보는 쪽입니다.

아래 그림은 이 다섯이 Play Console 의 앞뒤 어디에 붙는지만 보입니다. 화살표 하나하나는 뒤의 소절이 풉니다.

flowchart TD
    S["Android Studio · Gradle"] -->|AAB| PC["Play Console"]
    PC -->|출시| GP["Google Play"]
    GP -->|기기별 APK| U["사용자 기기"]
    CI["CI 서버"] -->|출시 자동화| API["Google Play Developer API"]
    BE["백엔드 서버"] -->|결제 확인| API
    API --> PC
    PC -->|테스트 트랙의 AAB| TL["Firebase Test Lab"]
    TL -->|출시 전 보고서| PC

Android Studio 와 Gradle 이 올릴 AAB 를 만든다

Play Console 에 올리는 AAB 는 개발자 쪽에서 만듭니다. Android Studio 는 Android 앱을 짜는 Google 의 개발 도구입니다. 그 안에서 빌드를 실제로 도는 것은 Gradle 이라는 빌드 도구입니다.

Gradle 이 코드를 AAB 로 묶고 업로드 키로 서명합니다. 개발자는 그 파일을 Play Console 에 올립니다. 버전 코드와 패키지 이름도 이 빌드 설정에 적습니다. 새 파일의 버전 코드는 앞 것보다 커야 하므로, 빌드 설정에서 버전 코드를 안 올리면 Play Console 이 업로드를 거절합니다.

Google Play 스토어가 기기로 앱을 나른다

Play Console 에서 출시를 누르면 그 뒤 일은 Google Play 가 맡습니다. 사용자 기기에 깔린 Play 스토어 앱이 새 버전이 있는지 물어보고 받아 갑니다. 이때 앞에서 말한 기기별 APK 가 내려갑니다.

그래서 Play Console 에서 출시를 눌러도 모든 기기에 바로 깔리지는 않습니다. 기기마다 갱신을 확인하는 때가 달라서, 새 버전이 퍼지는 데 시간이 걸립니다. 기기가 새 버전을 물으면 Google Play 가 그 기기를 이번 비율 안에 넣을지 골라 답합니다. 단계적 출시의 비율은 이렇게 적용됩니다.

Google Cloud 서비스 계정으로 API 를 부른다

출시를 사람이 화면에서 누르지 않고 자동으로 하고 싶을 때가 있습니다. 이때 Google Play Developer API 를 부릅니다. 이 API(Application Programming Interface, 프로그램이 부르는 인터페이스)는 Play Console 화면에서 하는 일 대부분을 프로그램으로 하게 해 줍니다.

API 를 부르는 프로그램은 사람 계정 대신 Google Cloud 의 서비스 계정으로 로그인합니다. 서비스 계정은 사람이 아니라 프로그램에게 주는 계정입니다. 그 서비스 계정을 Play Console 에 사용자로 초대하고 권한을 줘야 API 가 통합니다.

서비스 계정은 비밀번호 대신 키 파일로 로그인합니다. 프로그램은 이 파일을 들고 있다가 API 를 부를 때 내밉니다. 이 키 파일은 앞에서 본 업로드 키나 앱 서명 키와 다른 것입니다. 앱에 서명하는 데는 쓰지 않습니다.

CI/CD(Continuous Integration/Continuous Delivery, 지속적 통합과 지속적 배포)는 코드가 바뀔 때마다 빌드부터 배포까지 사람 손 없이 돌리는 방식입니다. CI/CD 파이프라인은 마지막 단계에서 이 API 로 출시합니다.

API 로 출시할 때는 바꿀 것을 편집 묶음 하나에 모읍니다. 편집 묶음을 연 뒤 그 안에서 AAB 를 올리고 트랙을 고릅니다. 마지막에 편집 묶음을 커밋합니다. 커밋해야 묶음 안에서 바꾼 것이 한꺼번에 적용됩니다.

sequenceDiagram
    participant CI as CI 서버
    participant API as Developer API
    CI->>API: 편집 묶음을 연다
    CI->>API: AAB 를 올린다
    CI->>API: 내부 테스트 트랙에 릴리스를 지정한다
    CI->>API: 편집 묶음을 커밋한다
    Note over API: 커밋하기 전에는 아무것도 바뀌지 않는다

fastlane 이나 Gradle 플러그인처럼 이 순서를 대신 짜 주는 도구도 있습니다. 그 대신 서비스 계정의 키 파일을 가진 쪽이 곧 출시 권한을 쥡니다. 이 파일이 새면 누구든 앱을 내보낼 수 있습니다.

백엔드 서버가 같은 API 로 결제를 확인한다

같은 Developer API 를 백엔드 서버도 부릅니다. 앱 안에서 돈을 내는 인앱 결제가 진짜인지 확인할 때입니다. 앱은 사용자 기기에서 돌기 때문에 조작될 수 있습니다. 그래서 결제를 받아들일지는 앱 말고 서버가 정합니다.

결제가 끝나면 Google Play 가 앱에 구매 토큰을 줍니다. 구매 토큰은 결제 한 건을 가리키는 문자열입니다. 앱은 이 토큰을 서버로 넘깁니다. 서버는 그 토큰으로 API 에 물어 진짜 결제인지 확인합니다.

sequenceDiagram
    participant GP as Google Play
    participant App as 앱
    participant BE as 백엔드 서버
    participant API as Developer API
    GP->>App: 구매 토큰을 준다
    App->>BE: 구매 토큰을 넘긴다
    BE->>API: 이 토큰이 진짜 결제인지 묻는다
    API-->>BE: 결제 상태

구독은 정해진 기간마다 돈을 다시 내는 상품입니다. 구독은 사용자가 앱을 켜지 않아도 갱신되거나 취소됩니다. 그래서 서버는 앱을 거치지 않고 그 소식을 받아야 합니다.

Google Play 는 이 소식을 Cloud Pub/Sub 로 보냅니다. Cloud Pub/Sub 은 Google Cloud 의 메시지 전달 서비스입니다. 보내는 쪽과 받는 쪽이 서로를 몰라도 메시지를 주고받게 해 줍니다.

메시지가 오가는 통로를 토픽이라 합니다. 어느 토픽으로 보낼지는 Play Console 에서 정합니다. 서버는 그 토픽의 메시지를 받겠다고 미리 등록해 둡니다. Pub/Sub 에서는 이 등록도 구독이라고 부르지만, 앱이 파는 상품인 구독과는 다른 뜻입니다.

서버는 소식을 받으면 API 에 그 구독의 최신 상태를 다시 묻습니다. 메시지는 무엇이 바뀌었다는 알림일 뿐입니다.

sequenceDiagram
    participant GP as Google Play
    participant T as Pub/Sub 토픽
    participant BE as 백엔드 서버
    participant API as Developer API
    Note over T: 보낼 토픽은 Play Console 에서 정한다
    GP->>T: 구독의 갱신·취소 소식
    T->>BE: 메시지를 전달한다
    BE->>API: 최신 상태를 다시 묻는다
    API-->>BE: 구독의 최신 상태

Firebase Test Lab 이 출시 전에 앱을 돌려 본다

테스트 트랙에 AAB 를 올리면 Google 이 그 앱을 여러 실제 기기에서 자동으로 켜 봅니다. 그 결과를 모은 것이 출시 전 보고서입니다. 기기를 돌리는 쪽은 Firebase Test Lab 입니다. Firebase Test Lab 은 Google 의 데이터센터에 놓인 기기들에서 앱을 돌려 주는 서비스입니다.

보고서에는 앱이 죽은 기록과 화면 캡처, 접근성 문제가 담깁니다. 개발자가 따로 테스트 코드를 쓰지 않아도 기본 점검이 한 번 돕니다. 다만 로그인이 필요한 화면처럼 자동으로 못 들어가는 곳에는 점검이 닿지 않습니다. 그런 화면까지 보려면 테스트용 계정 정보를 따로 넣어 줘야 합니다.

관련 항목

Play Console 이 속하는 상위 분류

배포 · 앱 스토어 · 모바일 개발 · Android · Google Play

Play Console 이 앱을 가리는 식별자와 파일

패키지 이름 · 애플리케이션 ID · 버전 코드 · Android App Bundle · APK · Dynamic Delivery

Play Console 에 올리기 전에 거치는 서명 단계

코드 서명 · Play App Signing · 업로드 키 · 앱 서명 키 · 키스토어 · 전자 서명

Play Console 이 관리하는 출시 단계

트랙 · 테스트 트랙 · 프로덕션 트랙 · 릴리스 · 단계적 출시 · 롤아웃 · 앱 심사 · 롤백

Play Console 에서 신고하는 스토어 정보와 정책

스토어 등록 정보 · 콘텐츠 등급 · 데이터 보안 섹션 · 개인정보처리방침 · Play Policies

Play Console 이 보여 주는 품질 지표

Android vitals · 크래시 · ANR · 출시 전 보고서 · 평점과 리뷰

Play Console 과 맞물려 도는 Google 도구와 서비스

Android Studio · Gradle · Android Developers · Firebase Test Lab · Google Cloud · Cloud Pub/Sub · Play Integrity

Play Console 을 자동화하는 인터페이스와 도구

Google Play Developer API · 서비스 계정 · fastlane · Gradle Play Publisher · CI/CD · GitHub Actions

Play Console 에서 다루는 결제 요소

Google Play Billing · 인앱 결제 · 구독 · 구매 토큰 · 실시간 개발자 알림

Play Console 을 거치지 않는 배포 수단

사이드로딩 · Firebase App Distribution · MDM · 서드파티 앱 스토어

Play Console 과 같은 역할을 다른 생태계에서 맡는 배포 서비스

App Store Connect · TestFlight · Microsoft Partner Center · Steamworks