Android App Bundle에 대해

2026년 10월 3일

서론

예전에는 보통 APK 파일로 앱을 빌드 및 배포하곤 했지만 지금은 Android 앱 번들(AAB 파일)이 표준으로 통용되고 있다. 근데 맨날 빌드하고 Play Console에 아티팩트를 올리면서도 왜 앱 번들을 쓰는지에 대해 생각해본 적이 없다는 사실을 깨닫고, 간단하게나마 앱 번들의 특징에 대해 좀 알아보고자 한다.

소개

Android App Bundle은 앱의 모든 컴파일된 코드 및 리소스를 포함하며 APK 생성 및 서명을 Google Play에 맡기는 게시 형식입니다.

Google Play는 App Bundle을 사용하여 각 기기 설정에 맞게 최적화된 APK를 생성하고 제공합니다. 따라서 앱을 실행하기 위해서는 특정 기기에 필요한 코드와 리소스만 다운로드하면 됩니다. 개발자는 더 이상 다양한 기기에 대한 지원을 최적화하기 위해 여러 개의 APK를 빌드, 서명 및 관리할 필요가 없으며, 사용자는 더 작고 최적화된 앱을 다운로드하게 됩니다.

공식 문서에서 긁어온 정의다. 이걸 읽어보니까 대충 왜 사용하는지 알겠더라.

앱 번들은 쉽게 말해 배포 환경을 개선하고 앱 용량을 줄이기 위해 Google이 도입한 빌드 및 배포를 위한 수단이다. 이 번들에는 모든 디바이스에서 동작할 수 있는 전체 소스 코드와 리소스가 다 들어 있고, Google Play는 사용자가 앱을 다운로드할 때 기기 사양에 맞춰 필요한 소스 코드와 리소스만 선별적으로 택하여 APK를 내려준다.

그럼 앱 번들은 어떻게 기기별로 필요한 것만 집어 APK로 묶을 수 있는 것일까? 이 과정에 대해 알아보자.

구성에 따른 분할 APK를 통한 앱 용량 최적화

아래 내용은 C/C++ 바이너리가 NDK를 통해 앱에 포함되어 있음을 전제하고 있다는 점을 미리 알린다. NDK를 사용하지 않는 일반적인 Android 소스 코드(Java, Kotlin)는 DEX(Dalvik Executable) 바이트코드로 컴파일된다.

가장 먼저 ABI라는 단어에 대해 알아봐야 한다. ABI란 Application Binary Interface의 준말로, 컴파일된 바이너리(binary)가 특정 CPU 위에서 동작하기 위해 준수해야 하는 인터페이스를 말한다.

CPU마다 지원하는 명령어가 다르다. 그래서 모든 프로그램은 자신이 실행될 것으로 예상되는 CPU가 알아먹을 수 있는 이진 명령어로 컴파일되어야 한다. 이를 돕기 위해 CPU 제조사들은 자신들이 제작한 CPU가 어떤 연산을 지원하는지를 공개하고, 프로그래밍 언어를 개발하는 팀은 CPU 환경에 따라 소스 코드가 다른 ABI로 컴파일되도록 구성한다.

내가 알기로는 Android에서 지원하는 ABI는 4종으로 다음과 같다:

• armeabi-v7a
• arm64-v8a
• x86
• x86_64

AS-IS

문제는 Gradle에서는 특정 ABI를 명시하지 않으면, 위 4종의 ABI를 APK에 모두 포함해버린다는 점이다.

이 부분은 공식 문서에서도 언급하고 있는 부분이다. 따라서 기존에는 Gradle에서 ABI를 바꿔가면서 총 4번의 빌드를 해 주어야 했다. 여기에 기기별 DPI까지 고려하면 ABI 4종에 Android에서 지원하는 DPI 케이스 6종(ldpi, mdpi, hdpi, xhdpi, xxhdpi, xxxhdpi)까지 해서 4 × 6 = 24가지의 APK를 빌드해줘야 하는 것이다.

그럼 선택지는 2개다: 모든 ABI와 DPI 리소스를 포함한 Fat APK를 하나 배포하든지, 아니면 서로 다른 APK를 24개 배포하든지.

Fat APK

유일한 문제이면서 동시에 중대한 문제는 용량이 너무 크다는 것이다.

64 비트 기기 및 OS에서는 32 비트에서 동작하는 바이너리는 전혀 필요하지 않음에도 불구하고 그냥 가지고 있어야 한다. 어떤 이유도 없다. 그냥. 그 외에 DPI가 달라 기기 화면에는 맞지 않는 다른 리소스도 포함하고 있어야 한다. 그냥. 그러므로 다운로드를 할 때도 무거워서 문제고, 설치 후에도 불필요하게 공간을 차지하기에 문제가 된다.

환경에 따라 APK 따로 빌드 및 배포

이 방안에 관해서는 Android 공식 문서에서도 언급한 바가 있었다. 쉽게 말해, ABI와 DPI에 맞게 따로 빌드된 여러 개의 APK를 전부 배포해버리는 것이다.

물론 APK 용량이 줄어든다는 건 장점이긴 하지만, 그만큼 많은 APK를 따로 빌드하고 Play Console에서 유지/관리하는 건 쉬운 일이 아니며 이는 분명한 이 방안의 단점일 것이다. 가장 큰 문제는 Google Play가 하나의 versionCode에 하나의 APK만 허용했었다는 것이다. 하나의 커밋에서 파생된 APK라고 하더라도, 같은 버전 코드를 가질 수 없다.

예를 들어 태그 v1.0.2를 가지는 커밋에서 빌드된 x86 + hdpi 타겟 APK 하나의 versionCode가 10이라고 가정해보자. 만약 이 앱이 arm64-v8a도 지원하도록 빌드하려면 versionCode를 10이 아닌 다른 숫자로 설정해야 한다. 위에서 언급한 대로 24개 조합 전부를 Fit하게 지원하는 APK 24개를 만들 경우, 하나의 커밋에서 빌드된 앱이지만 버전 코드가 24개나 필요하다는 말이다. 굉장한 낭비다.

추가적인 문제도 몇 가지 있었는데 다음과 같다:

• 조건에 부합하는 APK가 여러 개일 경우 versionCode가 높은 APK가 우선한다. 만약 64 비트 CPU에서 32 비트 타겟으로 빌드된 APK가 우선순위가 높다면? 64 비트 APK가 아니라 32 비트 APK가 설치된다.
• versionCode상 다운그레이드가 불가하다. 32 비트 OS가 64 비트 OS로 업데이트됐다고 가정하자. 만약 기존에 깔려 있었던 32 비트 APK versionCode가 43이고 새로 설치해야 할 64 비트 APK versionCode가 42라면, 64 비트 APK를 설치할 수 없다. 다운그레이드니까.

TO-BE

앱 번들을 사용하는 개발자는 APK마다 versionCode를 설정할 필요가 없다. 앱 번들 하나에만 versionCode를 지정해줘도 충분하기 때문이다.

Play 스토어는 개발자가 앱 번들을 올리면 가능한 모든 구성 설정에 맞는 APK를 모두 준비하고 서명까지 다 끝내둔다. 이때 모든 APK에 앱 번들에 지정된 versionCode를 동일하게 설정해준다. 기존처럼 APK 24개 다 빌드하고 올릴 필요도 없고, 환경 및 APK 파일별로 versionCode를 별도로 지정해줄 필요도 없다. 하나의 태그에 하나의 versionCode. 얼마나 편리한가.

실제 분할 과정

분할 과정을 조금 더 상세히 알아보자. 분할의 단위가 되는 기준은 다음과 같다:

• 언어
• ABI
• DPI (화면 밀도)

사용자는 앱 다운로드 시 이 3가지 값에 따라 최소한으로 조립된 APK를 수신한다. 정확히는 다음과 같은 APK들을 다운받게 된다:

• 기본 APK, 모든 기기에서 공유하는 기본 바이트코드로 매니페스트 등이 포함된다.
• 구성 APK, 특정 화면 밀도, ABI, 언어에 관한 네이티브 라이브러리 및 리소스가 포함된다. 이 부분이 기기나 사용자 상황에 따라 달라지는 부분이다.
• 동적 기능 모듈 APK, 이 부분은 필요에 따라 추가하든 안 하든 상관이 없는 기능 모듈이다. 초기 설치에 무조건 포함될 수도 있고, 하드웨어나 국가 등 조건에 따라 설치될 수도 있으며, 실행 중 사용자가 요청 시 다운로드될 수도 있다.

출처는 Android App Bundle 형식 문서다.

서명 관리 경험 개선

APK를 쓰던 시절에는 개발자가 릴리즈 버전 APK에 릴리즈 서명 키로 서명해야 했다. 만약 이 서명 키를 분실하면, 다시는 같은 패키지명으로 앱을 업데이트할 수 없었다. 반면, 앱 번들을 사용하게 되면서 키 관리에 대한 부담이 조금 줄었다.

앱 번들은 APK가 아니다. APK를 조립할 때 필요한 모든 데이터가 모여 있는 번들이기 때문에, 사용자가 앱 다운로드를 요청하여 실제 APK 조립이 이루어지는 시점에서 Play Console이 릴리즈 키로 서명을 대신 해준다. 기존에 개발자가 릴리즈 키로 쓰던 그 키는 용도가 업로드 키로 바뀌었고, 예전과는 다르게 분실했다고 하더라도 고객 지원을 통해 업로드 키 변경을 요청하면 이제는 바꿔준다.

요약

앱 번들은 다음 3가지 측면에서 개발자의 앱 빌드 및 배포 경험을 크게 개선한다:

• 버전 관리 개선. 다중 APK 분기 빌드와 복잡한 versionCode 관리 체계가 단일 앱 번들 업로드로 통일됐다.
• 키 관리 경험 개선. 업로드 키와 서명 키를 분리했고, 서명 키는 Google이 대신 관리해주며, 업로드 키는 이제 교체할 수 있다.
• APK 용량 최적화. ABI 바이너리뿐만 아니라 화면 밀도와 언어 리소스까지 기기 단위로 분할 서빙할 수 있어, 이제는 불필요한 데이터로 인한 낭비를 하지 않아도 된다.

참고 자료

• Android App Bundle 정보 | Other Play guides | Android Developers에 딸린 모든 하위 문서