AAB — 개념, APK와의 차이점 및 작동 원리

AAB란

AAB(Android App Bundle)는 Google Play를 통한 배포를 위해 Google이 APK의 대체품으로 개발한 게시 형식입니다. AAB 내부에는 .aab 확장자를 가진 ZIP 아카이브가 있으며, 컴파일된 코드, 리소스 및 메타데이터가 포함되어 있습니다. 주요 차이점: AAB는 기기에 직접 설치되지 않습니다.

작동 방식

개발자가 AAB를 Google Play Console에 업로드합니다. 사용자가 애플리케이션을 설치하려고 하면 Google Play가 기기 구성을 분석합니다: 화면 밀도(DPI), CPU 아키텍처, 언어 및 Android 버전. 이 분석을 기반으로 필요한 구성 요소만 포함된 최소 APK가 생성됩니다.

도입 역사

Google은 2018년 I/O 컨퍼런스에서 AAB를 발표했습니다. 2021년 8월부터 Google Play의 모든 새 애플리케이션에 이 형식이 필수가 되었습니다. 기존 애플리케이션은 APK를 계속 사용할 수 있지만, 새 애플리케이션은 AAB로만 게시해야 합니다.

AAB와 APK의 차이점

AAB와 APK의 차이점은 근본적입니다. APK는 설치 준비가 완료된 완전한 설치 파일입니다. AAB는 처리가 필요한 소스 구성 요소가 포함된 컨테이너입니다.

APK는 Google Play 외부(웹사이트, 이메일 또는 기업 MDM 시스템) 배포에 적합합니다. AAB는 Google Play 인프라에 종속되어 있으며 직접 설치할 수 없습니다. AAB 테스트에는 bundletool 도구를 사용하여 로컬 머신에서 APK 생성을 에뮬레이션합니다.

AAB 파일 구조

AAB의 내부 구조는 APK와 유사하지만 모듈 및 해당 종속성을 설명하는 추가 디렉토리와 파일이 포함되어 있습니다.

기본 모듈(base)

base 모듈은 AAB의 필수 구성 요소입니다. 주요 코드, 리소스 및 애플리케이션 매니페스트가 포함되어 있습니다. 기본 모듈 없이는 애플리케이션을 빌드할 수 없습니다. 다른 모든 모듈은 선택 사항이며 Dynamic Delivery를 통해 연결됩니다.

Protobuf 형식

AAB 구성은 XML 대신 Protocol Buffers(protobuf)를 사용합니다. .pb 파일은 더 컴팩트하며 Google 서버 인프라에서 더 빠르게 구문 분석됩니다. bundletool 도구는 디버깅을 위해 protobuf를 읽을 수 있는 형식으로 변환합니다.

Dynamic Delivery 및 애플리케이션 모듈

Dynamic Delivery는 AAB의 기반이 되는 핵심 기술입니다. 사용자의 기기 및 언어와 일치하는 애플리케이션 부분만 전달하고 필요에 따라 추가 모듈을 로드할 수 있습니다.

모듈 유형

Install-time 모듈은 설치 중에 기본 APK와 함께 로드됩니다. Conditional 모듈은 조건이 충족될 때만 전달됩니다(예: 4K 화면용 자료가 포함된 모듈). On-demand 모듈은 애플리케이션 내에서 사용자 요청에 따라 로드됩니다.

Play Asset Delivery(PAD)

대용량 리소스(최대 2GB)의 경우 OBB 파일 대신 Play Asset Delivery가 사용됩니다. PAD는 동일한 세 가지 전달 모드를 지원합니다: install-time, fast-follow(설치 직후), on-demand.

// SplitInstallManager를 통한 온디맨드 모듈 로드
val manager = SplitInstallManagerFactory
    .create(context)

val request = SplitInstallRequest
    .newBuilder()
    .addModule("level_pack_3")
    .build()

manager.startInstall(request)
    .addOnSuccessListener {
        Log.d("AAB", "Module installed")
    }

Gradle의 모듈 구성

각 동적 모듈은 전달 유형을 지정하여 별도의 build.gradle 파일에 설명됩니다. 모듈은 기본 애플리케이션과 독립적인 자체 리소스, 코드 및 매니페스트를 가질 수 있습니다.

Gradle을 통한 AAB 빌드

AAB 빌드는 Android Gradle Plugin의 bundleRelease(또는 bundleDebug) 작업을 통해 수행됩니다. 결과는 build/outputs/bundle/ 디렉토리에 .aab 파일로 생성됩니다.

빌드 구성

AAB 빌드에 특별한 구성이 필요하지 않습니다. Android Gradle Plugin은 기본적으로 번들을 지원합니다. assemble 대신 bundle 작업을 지정하기만 하면 됩니다.

// build.gradle.kts — 서명으로 AAB 빌드
android {
    bundle {
        language {
            enableSplit = true
        }
        density {
            enableSplit = true
        }
        abi {
            enableSplit = true
        }
    }
}
// 작업: ./gradlew bundleRelease

bundletool을 통한 로컬 테스트

Google은 로컬 머신에서 AAB로부터 APK를 생성하기 위한 bundletool 도구를 제공합니다. `bundletool build-apks --bundle=app.aab --output=app.apks` 명령은 다양한 기기 구성에서 테스트할 APK 세트를 생성합니다.

bundletool은 AAB의 압축을 풀고, 구성을 표시하며, Google Play Console에 업로드하기 전에 서명 무결성을 확인할 수도 있습니다. 디버깅을 위해 `bundletool dump manifest --bundle=app.aab` 명령을 사용하여 기본 모듈의 매니페스트를 표시합니다.

AAB의 분할 구성

기본적으로 AAB는 리소스를 언어, 화면 밀도(density), CPU 아키텍처(abi)의 세 가지 차원으로 분할합니다. 개발자는 build.gradle에서 분할을 비활성화할 수 있습니다(예: 애플리케이션이 영어만 지원하는 경우). 분할을 비활성화하면 모든 변형의 리소스가 기본 APK에 포함됩니다.

리소스 최적화 — AAB는 자동으로 PNG를 품질 손실 없이 WebP로 변환하고, 사용하지 않는 리소스를 압축하며, 중복 문자열을 제거합니다. 이러한 최적화는 최종 APK 생성 시 Google Play 측에서 적용됩니다. 결과적으로 사용자는 전체 아카이브보다 15~25% 더 작은 APK를 받게 됩니다.

Google Play에 AAB 게시

Google Play Console에서 AAB를 게시하는 프로세스는 업로드하는 파일 형식만 APK와 다릅니다. 콘솔은 .aab를 수락하고 구조, 서명 및 모듈 구성을 확인한 후 각 기기 유형에 대한 APK를 생성합니다.

App Signing by Google Play

AAB를 업로드하면 Google Play가 서명 키 관리를 인수합니다. 개발자는 upload 키로 서명된 패키지를 업로드하고 Google은 생성된 APK를 자체 키로 다시 서명합니다. 이렇게 하면 키 순환과 키스토어 분실 시 액세스 복구가 간소화됩니다.

출시 전 테스트

Google Play Console은 내장된 AAB 테스트를 제공합니다: 특정 기기용으로 생성된 APK를 다운로드하거나 Internal Testing, Closed Alpha 및 Open Beta 트랙을 통해 내부 테스트를 실행할 수 있습니다.

일반적인 AAB 문제 및 해결 방법

AAB로의 마이그레이션은 특히 동적 모듈이 많거나 리소스 구성이 복잡한 프로젝트에서 문제를 일으킬 수 있습니다.

모듈 구성 오류

동적 모듈이 잘못된 이름으로 기본 모듈 리소스를 참조하는 경우 Google Play는 확인 단계에서 AAB를 거부합니다. 해결 방법 — 빌드 전에 lint 검사를 사용하고 bundletool을 통해 모든 모듈을 로컬에서 테스트합니다.

언어 분할 및 성능 영향

언어별 분할은 현재 로케일의 리소스가 동적으로 로드되는 경우 애플리케이션 시작 속도를 저하시킬 수 있습니다. Google의 권장 사항은 10개 미만의 언어인 경우 분할하지 않거나 가장 인기 있는 언어에 install-time을 사용하는 것입니다.

타사 SDK와의 호환성

일부 SDK(분석, 광고, 지도)는 전체 매니페스트 및 리소스에 대한 액세스가 필요합니다. 마이그레이션 전 AAB 호환성 확인은 필수 단계입니다. 대부분의 주요 SDK(Firebase, Google Ads, Crashlytics)는 2022년부터 AAB를 완벽하게 지원합니다. 호환성 확인을 위해 --validate 플래그와 함께 bundletool을 사용하여 서버 측 APK 생성을 에뮬레이션합니다.

AAB 버전 관리

AAB는 기본 모듈 매니페스트의 versionCode를 사용합니다. APK와 달리 AAB는 각 모듈에 대해 별도의 versionCode도 지원하므로 완전한 재설치 없이 애플리케이션의 개별 부분을 업데이트할 수 있습니다. Dynamic Delivery는 설치된 모듈을 추적하고 Google Play를 통한 업데이트 중 변경된 구성 요소만 전달합니다.

AAB 모니터링 및 분석

Google Play Console은 각 AAB에 대한 자세한 분석을 제공합니다: 생성된 APK 수, 수요가 있었던 분할, 기기당 평균 다운로드 크기 등. Android Vitals는 생성된 APK의 성능 메트릭을 표시합니다. 이 데이터는 분할 구성을 최적화하고 다양한 기기 카테고리의 다운로드 크기를 줄이는 데 도움이 됩니다.