Google Play: 개요, 앱 게시 및 개발자 콘솔

Google Play란?

Google Play는 앱 스토어, 게임, 영화, 도서 및 음악을 결합한 Google의 디지털 배포 플랫폼입니다. 2008년 10월 22일에 Android Market이라는 이름으로 출시되었으며, 2012년 3월에 Google Play로 이름이 변경되었습니다. Apple의 App Store와 달리 Google Play는 Android 앱을 설치하는 유일한 채널이 아닙니다. 사용자는 타사 소스에서 APK를 설치(사이드로딩)하거나 대체 스토어(Samsung Galaxy Store, Amazon Appstore, F-Droid)를 사용할 수 있지만, 대부분의 사용자는 Google Play를 사용합니다.

Google I/O 2026에 따르면 Google Play의 월간 사용자는 190개 이상의 국가에서 28억 명의 활성 사용자를 초과합니다. 사용 가능한 앱 수는 320만 개 이상입니다. 평균 앱 가격은 App Store보다 낮으며, 많은 개발자가 광고 또는 인앱 구매와 함께 무료 모델을 사용합니다. Google Play에는 태블릿(Large Screen Apps), Wear OS, Android TV, Android Auto 및 Chromebook용 섹션도 포함되어 있습니다.

Google Play는 고유한 Android 도구를 제공합니다: Google Play Protect — 설치 전후에 모든 앱을 검사하는 내장 바이러스 백신; Android Vitals — 앱 성능 분석(ANR, 충돌율, 시작 시간); Google Play Integrity — 기기 및 앱의 진위성을 확인하는 API(SafetyNet Attestation 대체). 민감한 데이터와 결제를 처리하는 앱에는 Play Integrity가 필수입니다.

Google Play Console: 기능 및 설정

Google Play Console은 Google Play에서 앱을 관리하기 위한 중앙 개발자 도구입니다. play.google.com/console에서 사용할 수 있습니다. 시작하려면 개발자 계정(일회성 결제 $25)과 신원 확인이 필요합니다. Play Console은 첫 번째 AAB 업로드부터 판매 분석 및 충돌 보고서까지 완전한 앱 관리 수명 주기를 제공합니다.

Play Console의 주요 섹션: Dashboard — 모든 앱의 전체 통계(설치, 제거, 충돌, 평점, 수익); Release — 버전 및 트랙 관리(Production, Open Beta, Closed Beta, Internal Testing); Growth — 프로모션 도구(Google Ads, Promo Codes, Store Listing Experiments); Quality — Android Vitals(ANR 비율, 충돌 비율, 시작 시간, 렌더링 시간); Monetization — 제품 및 구독 설정, Google Play Pass; Users & Permissions — 팀 액세스 관리.

테스트 트랙 — App Store와의 주요 차이점입니다. Internal Testing — 최대 100명의 테스터, 검토 불필요, 업데이트 즉시 게시. Closed Testing(Alpha) — 최대 100명, 검토 필요. Open Testing(Beta) — 무제한 테스터, 테스트에 등록한 모든 사람이 Google Play에서 앱 사용 가능. 먼저 Internal Testing, 그다음 Closed/Open Beta, 마지막으로 Production에 게시하는 것을 권장합니다.

// Google Play Billing Library 6.x — 구독 확인
import com.android.billingclient.api.BillingClient
import com.android.billingclient.api.BillingClientStateListener
import com.android.billingclient.api.BillingFlowParams
import com.android.billingclient.api.PurchasesUpdatedListener
import com.android.billingclient.api.QueryProductDetailsParams
import kotlinx.coroutines.tasks.await

class PlayBillingManager(
    private val context: Context
) {
    private val billingClient = BillingClient.newBuilder(context)
        .setListener(purchasesUpdatedListener)
        .enablePendingPurchases()
        .build()

    private val purchasesUpdatedListener = PurchasesUpdatedListener { billingResult, purchases ->
        if (billingResult.responseCode == BillingClient.BillingResponseCode.OK && purchases != null) {
            // 구매 성공 — 구매 처리
            purchases.forEach { purchase ->
                handlePurchase(purchase)
            }
        }
    }

    suspend fun startConnection() {
        billingClient.startConnection(object : BillingClientStateListener {
            override fun onBillingSetupFinished(result: BillingResult) {
                if (result.responseCode == BillingClient.BillingResponseCode.OK) {
                    // 클라이언트 작동 준비 완료
                }
            }
            override fun onBillingServiceDisconnected() {
                // 재연결
            }
        })
    }

    suspend fun querySubscription(productId: String): ProductDetails? {
        val params = QueryProductDetailsParams.newBuilder()
            .setProductList(
                listOf(
                    QueryProductDetailsParams.Product.newBuilder()
                        .setProductId(productId)
                        .setProductType(BillingClient.ProductType.SUBS)
                        .build()
                )
            )
            .build()

        val result = billingClient.queryProductDetails(params)
        return result.productDetailsList?.firstOrNull()
    }

    private fun handlePurchase(purchase: Purchase) {
        // 서버 측 구매 확인
        // 1. 서버에 purchaseToken 보내기
        // 2. 서버가 Google Play Developer API를 통해 확인
        // 3. 성공 시 — 기능 잠금 해제
        val purchaseToken = purchase.purchaseToken
        val productId = purchase.products.firstOrNull()
        println("Purchase: $productId, Token: $purchaseToken")
    }
}

PlayBillingManager 클래스는 Google Play Billing Library 6.x 작업을 보여줍니다: BillingClient와의 연결 설정, 제품 세부 정보(구독 또는 일회성 구매) 요청, PurchasesUpdatedListener를 통한 구매 결과 처리. 검증은 purchaseToken을 사용하여 Google Play Developer API를 통해 서버에서 수행해야 합니다. 구매가 위조될 수 있으므로 로컬 검증만 절대 신뢰하지 마십시오.

Google Play에 앱 게시 프로세스

Google Play 게시는 계정 등록, 앱 준비, Play Console 설정, AAB 업로드, 검토 통과 및 게시를 포함하는 다단계 프로세스입니다. App Store와 비교하여 프로세스는 덜 형식적입니다. Google은 각 앱의 수동 검토보다는 자동화된 검사(Play Integrity, Google Play Protect를 통한 맬웨어 스캔)에 의존합니다.

단계 1: 개발자 계정 등록

게시하려면 Google 계정과 $25(일회성 결제)에 Google Play Console에 등록해야 합니다. 결제 후 신원 확인이 필요합니다: 신분증(여권 또는 운전면허증) 업로드 및 주소 확인. 확인 프로세스는 24시간에서 2주까지 소요됩니다. 확인이 없으면 앱이 Production 트랙에 게시되지 않습니다.

단계 2: AAB 빌드 및 Store Listing 작성

Google은 2021년 8월부터 AAB(Android App Bundle) 형식을 권장합니다. 새 앱의 경우 APK가 더 이상 허용되지 않습니다. AAB를 통해 Google Play는 각 기기 유형(다른 ABI, 화면, 언어)에 최적화된 APK를 생성하여 다운로드 크기를 15-35% 줄일 수 있습니다. 빌드는 Android Studio를 통해 수행됩니다: Build → Build Bundle(s) / APK(s) → Build Bundle(s). AAB는 Play App Signing을 통해 서명되며 Google이 서명 키를 보관합니다.

Store Listing — Google Play의 앱 페이지: 제목(50자), 간단 설명(80자), 전체 설명(4000자), 스크린샷(최소 2개, 최대 8개; 휴대폰 5", 6.5", 태블릿 7"+), 아이콘(512x512), 피처 그래픽(1024x500), 프로모션 동영상(YouTube). 간단 설명은 Google Play 검색에서 가장 중요하며 인덱싱되어 결과에 표시됩니다. 전체 설명도 인덱싱되지만 검색에서 덜 중요합니다.

단계 3: 트랙 선택 및 게시

AAB 업로드 후 개발자는 트랙을 선택합니다: Internal Testing(최대 100명의 테스터, 검토 불필요), Closed Testing(Alpha, 최대 100명, 검토 필요), Open Testing(Beta, 무제한, 검토 필요) 또는 Production. 먼저 Internal Testing으로 실제 기기에서 테스트한 다음 Closed Testing으로 광범위한 검증을 수행하고 마지막으로 Production에 게시하는 것이 좋습니다. Open Testing 및 Production의 경우 새 계정은 지난 14일 동안 Closed Testing에서 최소 12시간 및 20명의 테스터가 필요합니다(Google Play 2024 정책).

게시 후 앱은 1-24시간 이내에 Google Play에 나타납니다. 첫 번째 업데이트는 포괄적으로 검토될 수 있습니다. Google Play는 Google Play Protect를 통해 모든 앱을 자동으로 악성 코드 검사합니다. 위협이 발견되면 앱이 게시 중단되고 개발자 계정이 정지될 수 있습니다.

Google Play의 targetSdkVersion 요구사항

Google Play는 앱 게시 및 업데이트를 위한 targetSdkVersion의 필수 요구사항을 설정합니다. Google은 매년 앱이 최신 보안 동작 변경 사항을 사용하도록 최소 targetSdk를 높이고 있습니다. 2024년 8월부터 최소 targetSdk는 API 33, 2025년 8월부터 API 34, 2026년 8월부터 API 35(Android 15)입니다.

요구사항을 충족하지 않는 앱은 차단되어 게시하거나 업데이트할 수 없습니다. targetSdk가 낮은 이미 게시된 앱은 스토어에서 계속 작동하지만 업데이트하려면 targetSdk를 높여야 합니다. Google Play Console은 기준 인상 90일 전에 경고합니다. 많은 개발자가 마지막 순간까지 업데이트를 미루며, 긴급 버그 수정이 필요할 때 앱이 차단될 위험을 초래합니다.

targetSdkVersion을 높이려면 이전 및 새 targetSdk 사이에 도입된 모든 동작 변경 사항을 확인해야 합니다. 예를 들어 API 33(Android 13)에서 API 35(Android 15)로 마이그레이션할 때 확인해야 할 사항: Foreground Service Types(API 34) — 매니페스트에서 서비스 유형 필수 선언; Privacy Sandbox(API 35) — 광고 식별자 제한; PhotoPicker(API 34+) — 직접 갤러리 액세스를 시스템 선택기로 대체; 새로운 백그라운드 서비스 제한. 각 동작 변경은 코드 변경이 필요할 수 있습니다.

준수 자동화를 위한 Play Console API

Google Play Developer API(REST)를 사용하면 계정의 모든 앱에 대한 targetSdk 준수 확인을 자동화할 수 있습니다. applications.get 메서드는 targetSdkVersion 정보를 반환합니다. 마감일 120일 전에 API를 통한 모니터링을 설정하여 업데이트가 필요한 앱 목록을 얻는 것이 좋습니다. 코드베이스가 큰 앱의 경우 동작 변경에 필요한 예상 작업량은 2일에서 2주입니다.

// 앱 코드에서 targetSdk 준수 확인
import android.os.Build

class TargetSdkCompliance {

    // 2026년 Google Play에서 요구하는 최소 targetSdk
    companion object {
        const val REQUIRED_TARGET_SDK = 35
    }

    // 확인: API 34의 동작 변경을 처리해야 합니까?
    fun checkForegroundServiceTypes(targetSdk: Int): Boolean {
        // targetSdk >= 34의 경우 Foreground Service Types 필수
        return targetSdk >= 34
    }

    // 확인: Privacy Sandbox(API 35)를 처리해야 합니까?
    fun checkPrivacySandbox(targetSdk: Int): Boolean {
        return targetSdk >= 35
    }

    // 빌드 전 준수 확인
    fun validateCompliance(targetSdk: Int): List<String> {
        val warnings = mutableListOf<String>()

        if (targetSdk < REQUIRED_TARGET_SDK) {
            warnings.add("targetSdk $targetSdk가 필요한 $REQUIRED_TARGET_SDK보다 낮습니다")
        }

        if (targetSdk >= 34) {
            // 모든 포그라운드 서비스가 매니페스트에서 유형을 선언했는지 확인
            warnings.add("확인: 모든 포그라운드 서비스가 AndroidManifest.xml에서 유형을 선언하는지 확인")
        }

        if (targetSdk >= 35) {
            warnings.add("확인: Privacy Sandbox, Advertising ID 제한")
        }

        return warnings
    }
}

TargetSdkCompliance 클래스는 빌드 전에 targetSdk 준수 여부를 확인합니다. validateCompliance 메서드는 지정된 targetSdk에 필요한 동작 변경에 대한 경고 목록을 반환합니다. Google Play Console에 빌드를 보내기 전에 준수 여부를 자동으로 확인하려면 CI/CD에서 이러한 코드를 사용하십시오. IT Sectr에서는 targetSdk 누락으로 인해 프로젝트 중 하나가 차단된 후 CI에 이 확인을 구현했습니다.

Google Play 수익화: 인앱 결제, 구독 및 AdMob

Google Play 수익화는 여러 모델을 포함합니다: 유료 다운로드, 인앱 제품(일회성 구매: 소모성 — 게임 통화; 비소모성 — 광고 제거), 구독(Google Play Billing을 통한 자동 갱신 구독), 광고(AdMob, Google Ad Manager, 타사 네트워크) 및 Google Play Pass(앱 번들 구독, 사용 시간에 따라 개발자 간 수익 분배).

Google Play Billing Library(현재 버전 — 2026년 기준 7.x)는 앱 내에서 디지털 상품을 판매하기 위한 필수 도구입니다. 디지털 상품에는 대체 결제 시스템이 금지됩니다(예외 — 한국, 인도, EU 디지털 시장법). Billing Library 7.x는 SKU 기반 구매에서 제품 기반 모델(SkuDetails 대신 ProductDetails)로 마이그레이션이 필요하며 비동기 작업을 위해 Kotlin Coroutines 및 Flow를 지원합니다.

Google Play 수수료: 표준 30%, 연간 처음 100만 달러 수익의 15%(Apple Small Business Program과 유사). 100만 달러 기준에 도달하면 나머지 기간 동안 수수료가 30%로 돌아갑니다. 구독: 첫 해 30%, 두 번째 해부터 15%(App Store와 유사). Google Play Pass 프로그램의 경우 수익은 고정 수수료가 아닌 참여도(Pass 구독자로서 사용자가 앱에서 보내는 시간)에 따라 분배됩니다.

Google의 AdMob은 주요 광고 수익화 도구입니다. 배너, 전면, 네이티브 및 보상형 광고를 지원합니다. Firebase용 Google Analytics는 AdMob과 통합되어 광고의 목표 액션 전환을 추적합니다. Android 14+(API 34)부터 Privacy Sandbox 준수를 위해 Google Play Services for Ads 22.0+ 및 Handling Ad Responses API가 필요합니다. 광고 수익화(수수료 0%)는 대규모 사용자를 보유한 무료 앱에 인기 있는 선택입니다.

Google Play 검토: 확인 및 정책

Google Play 검토(Google Play Policy Review)는 App Store와 다릅니다. Google은 각 앱의 100% 수동 검토보다는 자동화된 검사와 선택적 수동 검토에 의존합니다. 자동화 시스템은 AAB/APK를 스캔하여 악성 코드, 정책 위반(스파이웨어, 기만 행위, SDK 위반) 및 targetSdk 요구사항 미준수를 찾습니다. 위반이 발견되면 앱이 거부되거나 게시 중단될 수 있습니다.

Google Play는 Developer Program Policies를 게시합니다 — 콘텐츠, 앱 동작, 수익화 및 개인정보 보호를涵盖하는 규칙 세트. 주요 섹션: Restricted Content(폭력, 혐오, 불법 활동), Deceptive Behavior(허위 주장, 다른 앱 모방), Monetization and Ads(정직한 광고, 인앱 구매 정책 준수), Privacy and Security(데이터 수집, 암호화), Store Listing and Promotion(정확한 설명, 적절한 분류).

Google은 스파이웨어 및 기만적인 SDK에 적극적으로 대처하고 있습니다. 2024-2025년에 Google은 개인정보 보호 정책을 위반하는 150만 개 이상의 앱을 제거했습니다. 특히 사용자 모르게 데이터를 수집하는 SDK(동의 없는 위치 추적, 연락처 및 SMS 읽기)가 주목받고 있습니다. 게시 전에 사용하는 SDK가 Google Play 정책을 준수하는지 확인하십시오. 많은 인기 SDK(예: 일부 광고 네트워크)가 정책 위반으로 차단되었습니다.

이의 제기 프로세스: 앱이 거부되면 개발자는 Play Console에서 이유와 권장 사항과 함께 알림을 받습니다. Play Console → Policy → Appeals를 통해 이의를 제기할 수 있습니다. 검토 기간은 최대 7일입니다. 동일한 정책을 반복 위반하면 경고(strike)가 발생하고, 세 번째 위반 시 개발자 계정이 정지됩니다. 정지된 계정 복구는 매우 어려운 프로세스로, 서면 이의 제기와 위반 사항 수정 증명이 필요합니다.

위험 최소화를 위해: 요청 진위성 확인을 위해 Google Play Integrity API 사용, 데이터 안전 섹션 구현(2023년부터 필수 — 수집하는 모든 데이터와 수집 목적 명시), 모든 SDK가 Developer Program Policies를 준수하는지 확인, 게시 전 잠재적 위반을 추적하기 위해 Play Console Policy Insights 사용. IT Sectr에서 개발할 때 Production 출시 전에 실제 기기에서 내부 테스트를 통해 모든 앱을 테스트합니다.