Android 앱 번들(AAB)(AAB): 개발자와 사용자를 위한 완벽한 가이드

A sealed parcel labeled AAB on a developer desk, illustrating the Android 앱 번들(AAB) format

2021년 8월, Google은 Android 앱 배포 방식을 근본적으로 바꾸는 결정을 내렸습니다. Google Play 스토어에 제출되는 모든 새 앱은 기존 APK 대신 Android 앱 번들(AAB) 형식을 사용해야 합니다. 이러한 변화는 개발자, 사용자 및 타사 앱 배포의 전체 생태계에 영향을 미쳤습니다. 하지만 앱 번들(AAB)이 정확히 무엇이고, 어떻게 작동하며, 왜 관심을 가져야 할까요?

이 가이드에서는 AAB 형식의 내부 기술부터 친구와 앱을 공유하거나 Play 스토어 액세스 없이 기기에 앱을 설치하려는 사용자를 위한 실제적인 의미까지 모든 것을 다룹니다.

Android 앱 번들이란 무엇입니까?

Android 앱 번들(AAB)은 앱의 컴파일된 코드와 리소스를 모두 포함하지만 최종 설치 가능한 APK 생성을 Google Play로 연기하는 게시 형식입니다. Google 서버가 즉시 최적화된 기기별 패키지를 생성하는 마스터 템플릿이라고 생각하세요.

즉시 설치 가능한 패키지인 APK와 달리 AAB 파일은 기기에 직접 설치할 수 없습니다. 이는 Play 스토어에 업로드되는 빌드 아티팩트이며, 여기에서 Google의 인프라가 이를 처리하고 각 기기 구성에 맞는 맞춤형 APK를 생성합니다.

파일 확장자는 .aab이며 내부적으로는 ZIP과 같은 구조가 결합된 프로토콜 버퍼 형식을 사용합니다. 여기에는 앱의 DEX 바이트코드, 리소스, 자산, 네이티브 라이브러리 및 Google Play에 콘텐츠 분할 방법을 알려주는 특수 번들 메타데이터 파일이 포함되어 있습니다.

Google에서 앱 번들(AAB)을 의무화하는 이유

앱 번들(AAB)의 주요 동기는 앱 다운로드 크기 줄이기입니다. 일반적인 Android 앱은 여러 화면 밀도(mdpi, hdpi, xhdpi, xxhdpi, xxxhdpi), 여러 CPU 아키텍처(armeabi-v7a, arm64-v8a, x86, x86_64) 및 여러 언어를 지원해야 합니다. 기존 APK 모델에서는 특정 기기에 그 중 극히 일부만 필요한 경우에도 이러한 모든 리소스가 단일 파일로 묶입니다.

4가지 CPU 아키텍처에 대한 기본 라이브러리와 5가지 화면 밀도에 대한 텍스처가 포함된 게임을 생각해 보세요. 범용 APK는 200MB일 수 있지만 관련 아키텍처와 밀도만 포함하는 기기별 버전은 80MB일 수 있습니다. 이는 다운로드 크기가 60% 감소한 것입니다.

Google은 앱 번들(AAB)을 사용하는 앱이 범용 APK에 상응하는 앱보다 평균 15% 더 작다고 보고합니다. 대규모 앱과 게임의 경우 비용 절감 효과가 훨씬 더 클 수 있습니다. 다운로드가 작을수록 설치 속도가 빨라지고 대역폭 소비가 줄어들며 크기 문제로 인해 설치가 중단되는 경우가 줄어듭니다.

앱 번들(AAB)이 내부적으로 작동하는 방식

번들 구조

AAB 파일은 모듈로 구성되며 각 모듈에는 자체 코드, 리소스 및 자산이 포함되어 있습니다. 가장 일반적인 구조는 다음과 같습니다.

  • 기본 모듈: 모든 장치에 필요한 핵심 앱 코드와 리소스가 포함되어 있습니다. 이는 항상 설치됩니다.
  • 구성 분할: 언어 리소스, 화면 밀도 리소스 및 ABI(CPU 아키텍처) 기본 라이브러리에 대한 별도의 섹션입니다.
  • 동적 기능 모듈: 초기 설치 후 요청 시 다운로드할 수 있는 옵션 모듈입니다.
  • 자산 팩: 설치 시, 요청 시 또는 백그라운드에서 제공될 수 있는 게임 레벨이나 미디어와 같은 대규모 자산입니다.

분할 APK 생성

사용자가 Play 스토어에서 앱을 다운로드하면 Google 서버는 기기의 구성을 검사하고 해당 특정 기기에 맞는 분할 APK 세트를 생성합니다. 일반적인 설치에는 다음이 포함될 수 있습니다.

  • base.apk, 핵심 애플리케이션 코드 및 필수 리소스
  • split_config.arm64_v8a.apk, 장치 CPU용 네이티브 라이브러리
  • split_config.xxhdpi.apk, 장치의 화면 밀도에 대한 리소스
  • split_config.en.apk, 사용자 로캘에 대한 언어 리소스

이러한 분할 APK는 단일 논리 앱으로 함께 설치됩니다. Android 패키지 관리자는 이를 하나의 애플리케이션으로 취급하지만 기기에서는 물리적으로 별도의 파일입니다. 이것이 크기 절감을 가능하게 하는 메커니즘입니다.

동적 전달

앱 번들(AAB)의 가장 강력한 기능 중 하나는 동적 전달입니다. 개발자는 특정 기능을 필요할 때 다운로드할 수 있도록 표시할 수 있습니다. 예를 들어 사진 편집 앱에는 고급 필터가 동적 기능 모듈로 포함될 수 있습니다. 해당 필터를 전혀 사용하지 않는 사용자는 해당 필터를 다운로드하지 않으므로 저장 공간이 절약됩니다.

동적 기능 모듈은 런타임 시 Play Core 라이브러리를 통해 다운로드되고 설치됩니다. 앱은 모듈이 설치되었는지 확인하고 필요할 때 다운로드를 요청할 수 있으므로 사용자는 전체 재설치가 아닌 작은 인앱 다운로드로 새로운 기능을 경험할 수 있습니다.

AAB와 APK: 주요 차이점

이러한 형식 간의 차이점을 이해하면 각 형식이 적절한 시기를 명확히 하는 데 도움이 됩니다.

  • 설치 가능성: APK 파일은 모든 Android 기기에 직접 설치할 수 있습니다. AAB 파일은 직접 설치할 수 없으며 먼저 처리되어야 합니다.
  • 크기: 범용 APK에는 모든 구성에 대한 리소스가 포함되어 있습니다. AAB를 사용하면 장치별 전송이 가능하므로 다운로드 횟수가 줄어듭니다.
  • 서명: 개발자는 APK를 사용하여 최종 설치 가능한 패키지에 서명합니다. AAB를 사용하면 개발자가 번들에 서명하고 Google은 Play 앱 서명을 사용하여 생성된 APK에 다시 서명합니다.
  • 배포: APK는 모든 채널을 통해 배포될 수 있습니다. AAB는 주로 Play 스토어용으로 설계되었지만, Bundletool과 같은 도구는 AAB에서 로컬로 APK를 생성할 수 있습니다.
  • 공유성: APK 파일을 다른 사람과 쉽게 공유할 수 있습니다. AAB에서 설치된 앱을 공유하려면 모든 분할 APK를 수집해야 하며 이는 더 복잡합니다.

서명 논쟁

AAB 명령의 가장 논쟁적인 측면 중 하나는 Play 앱 서명입니다. 개발자가 AAB를 업로드하면 Google은 사용자에게 전달되는 최종 APK에 서명하는 데 사용되는 서명 키를 보유합니다. 이는 Google이 APK 콘텐츠에 서명하고 전달하기 전에 기술적으로 APK 콘텐츠를 수정할 수 있음을 의미합니다.

Google은 생성한 분할 APK에 서명해야 하기 때문에 이것이 필요하다고 주장합니다. 개발자는 업로드를 인증하기 위해 업로드 키를 보관하지만 실제 앱 서명 키는 Google 인프라에서 관리됩니다.

대부분의 개발자에게 이는 합리적인 절충안입니다. Google은 키 백업 및 복구 서비스를 제공하며 키 분실 위험(앱 업데이트를 영구적으로 방해함)이 제거됩니다. 그러나 개인 정보 보호에 초점을 맞춘 개발자와 오픈 소스 옹호자들은 이러한 신뢰의 중앙 집중화에 대한 우려를 제기했습니다.

앱을 공유하는 사용자에게 이것이 의미하는 바

앱 번들(AAB)로의 전환은 Play 스토어 외부에서 앱을 공유하려는 사용자에게 중요한 의미를 갖습니다.

설치된 앱 추출

AAB에서 설치된 앱을 추출하면 단일 APK 파일을 얻지 못합니다. 대신 분할 APK 컬렉션을 얻게 됩니다. 이러한 분할은 기기별로 다르며, 이는 ARM64 프로세서 및 xxhdpi 화면이 있는 휴대폰에서 추출된 앱이 다른 구성의 기기에서는 작동하지 않음을 의미합니다.

XAPK 및 APKS 형식

분할 APK 공유 문제를 해결하기 위해 XAPK 및 APKS와 같은 컨테이너 형식이 만들어졌습니다. 이러한 형식은 모든 분할 APK를 다운로드 가능한 단일 파일로 묶습니다. XAPK 파일이 발견되면 원래 앱 번들(AAB)로 배포된 앱이 포함되어 있을 가능성이 높습니다.

XAPK-APK 변환기는 이러한 컨테이너 형식에서 기본 APK를 추출하는 데 도움을 줄 수 있습니다. 그러나 밀도 및 ABI 관련 리소스가 분할 APK에 있을 수 있으므로 기본 APK만으로는 앱이 모든 기기에서 올바르게 작동하는 데 필요한 모든 리소스를 포함할 수 없다는 점을 명심하세요.

번들 도구 사용

Google은 AAB 파일에서 로컬로 APK를 생성할 수 있는 bundletool라는 오픈 소스 도구를 제공합니다. 개발자는 이를 사용하여 테스트 또는 대체 배포를 위한 범용 APK를 만들 수 있습니다. 명령은 다음과 같습니다:

bundletool build-apks --bundle=app.aab --output=app.apks --mode=universal

그러면 모든 구성에 대한 모든 리소스가 포함된 범용 APK가 생성됩니다. 장치별 빌드보다 크지만 모든 장치에서 작동합니다. 이것이 AAB에서 APK로 변환기에서 사용하는 접근 방식입니다.

대체 앱 스토어에 미치는 영향

AAB 의무사항은 주로 Google Play 스토어에 영향을 미칩니다. 대체 앱 스토어와 직접 배포 채널에서는 여전히 APK 파일을 허용할 수 있습니다. Play 외부에 배포하려는 개발자는 AAB 업로드와 함께 범용 APK를 계속 구축할 수 있습니다.

그러나 일부 개발자는 AAB만 구축하고 배포를 Play에 전적으로 의존합니다. 이는 이러한 개발자의 앱을 Play 스토어 생태계 외부에서 얻기가 더 어렵다는 것을 의미합니다. 타사 앱 저장소는 분할 APK 컬렉션(XAPK 또는 APKS 파일)을 호스팅하거나 Bundletool을 사용하여 범용 APK를 생성하는 방식으로 조정되었습니다.

실제 동적 기능 모듈

동적 기능 모듈은 앱 번들(AAB) 형식의 가장 흥미로운 기능 중 하나를 나타냅니다. 실제 사용 사례는 다음과 같습니다.

  • 카메라 기능: 앱에는 사용자가 카메라 기능에 처음 액세스할 때만 다운로드되는 AR 필터가 동적 모듈로 포함될 수 있습니다.
  • 언어 팩: 일반적이지 않은 언어에 대한 번역 데이터는 설치할 때마다 번들로 제공되지 않고 요청 시 제공될 수 있습니다.
  • 게임 레벨: 게임은 플레이어가 진행함에 따라 추가 콘텐츠를 제공하여 초기 다운로드를 작게 유지할 수 있습니다.
  • 전문 도구: 생산성 앱의 고급 기능은 해당 기능이 필요한 사용자에게만 제공될 수 있습니다.

사용자의 경우 이는 동적 모듈이 다운로드됨에 따라 시간이 지남에 따라 앱의 설치 크기가 커질 수 있음을 의미합니다. 또한 이러한 앱을 공유하려면 다운로드한 모든 모듈을 포함해야 하므로 추출 프로세스가 더욱 복잡해집니다.

개발자를 위한 모범 사례

Android 앱을 개발하는 경우 앱 번들(AAB)을 효과적으로 사용하기 위한 권장 사항은 다음과 같습니다.

  1. Play에 업로드하기 전 항상 로컬에서 Bundletool을 사용하여 테스트하세요.. 기기별 APK를 생성하고 올바르게 작동하는지 확인하세요.
  2. Play Console의 내부 테스트 트랙 사용는 분할 APK가 실제 기기에 올바르게 설치되고 작동하는지 확인합니다.
  3. 사용자 기반이 Play 스토어 이상으로 확장되는 경우 대체 배포 채널을 위한 범용 APK 제공을 고려하세요.입니다.
  4. 동적 기능 모듈 경계에 유의하세요. 자주 사용되는 기능은 동적 모듈이 아닌 기본 모듈에 있어야 합니다.
  5. 다양한 구성의 기기에서 테스트는 구성 분할이 올바르게 생성되고 누락된 리소스가 없는지 확인합니다.
  6. 업로드 키를 안전하게 보관하세요. Google에서 앱 서명 키를 관리하는 동안 업로드 키는 귀하의 개발자 신원을 인증합니다.

앱 배포의 미래

앱 번들(AAB) 형식은 계속 발전하고 있습니다. Google은 대규모 게임 자산을 위한 Play Asset Delivery, 광고 SDK를 위한 SDK 런타임, Wear OS 및 Android TV 구성에 대한 향상된 지원과 같은 기능을 도입했습니다. 추세는 앱 구성요소를 보다 세부적으로 주문형으로 제공하는 것입니다.

사용자의 입장에서 이는 Play 스토어 앱에서 단일의 자체 포함 앱 파일 개념이 덜 일반적이라는 것을 의미합니다. 표준 Play 스토어 흐름 외부에서 앱을 관리하는 모든 사람에게는 XAPK, APKS 및 이에 사용할 수 있는 도구와 같은 형식을 이해하는 것이 점점 더 중요해지고 있습니다.

AAB를 유지해야 하는 시기와 범용 APK를 구축해야 하는 시기

Android 앱 번들(AAB)은 앱을 패키징하고 제공하는 방식의 근본적인 변화를 나타냅니다. 다운로드 크기와 전송 효율성 측면에서 실질적인 이점을 제공하는 동시에 앱을 공유하거나 대체 소스에서 앱을 설치하는 사용자에게는 복잡성을 초래하기도 합니다. AAB 작동 방식, 분할 APK 생성 방법, 형식 간 변환에 사용할 수 있는 도구를 이해하면 올바른 형식을 선택하고 자신있게 형식 간에 변환하는 데 필요한 정보를 얻을 수 있습니다.

개발자는 앱 제공 방식을 최적화하기 위해 AAB에 접근합니다. 대부분의 일반 사용자는 Play 스토어에 액세스할 수 없는 기기에 무언가를 설치하려고 할 때만 이 문제를 접합니다. 어느 쪽이든 기억할 가치가 있는 점은 간단합니다. AAB는 설치 형식이 아닌 게시 ​​형식이며 둘 사이의 격차를 해소하는 도구가 있습니다.

Mst Shaefale가 설계하고 문서화함 수석 개발자 및 Android 패키지 설계자 • Android 12~15에서 검증됨

Mst Shaefale은 xapktoapk.com에서 클라이언트측 XAPK/APKS 합병, 바이너리 매니페스트 파서 및 APK v1+v2 서명 도구를 유지 관리합니다. 오래된 명령이나 OS 변경 사항을 발견하셨나요? 편집 메모를 보내세요.