컴파일에 이어서 빌드에 대해서도 알아보겠습니다.
안드로이드에서 빌드 유형은 크게 두가지로 나뉩니다. APK와 AAB 빌드인데요.
이 두 유형의 빌드가 어떤 과정으로 이루어지는지, 어떤 차이점이 있는지 살펴보겠습니다.
APK는 안드로이드 운영체제에서 앱을 설치하기 위해 사용하는 최종 실행 파일 형식입니다.
컴파일된 소스 코드(.dex), 리소스 파일, 매니페스트 등을 하나의 압축 파일(ZIP 형식)로 묶은 것이며, 기기의 사양(CPU 아키텍처, 해상도 등)과 상관없이 설치에 필요한 모든 리소스를 포함하고 있습니다. 때문에 모든 리소스가 들어있기 때문에 사용자 기기에 최적화되지 않은 데이터까지 다운로드하게 되어 용량이 크다는 특징이 있죠.
구글 플레이 스토어를 통하지 않고도 웹사이트나 USB를 통해 기기에 바로 설치(Sideloading)가 가능합니다.
AAPT2(Android Asset Packaging Tool) 도구가 XML 레이아웃, 이미지 등 리소스 파일을 컴파일하여 이진 형태의 중간 결과물을 생성합니다. 이 과정에서 리소스에 접근할 수 있는 R.java 파일이 생성됩니다.
Java 소스 코드는 javac를 통해, Kotlin 소스 코드는 kotlinc를 통해 JVM 바이트코드인 .class 파일로 변환됩니다.
릴리즈 빌드인 경우, R8 도구가 실행되어 사용하지 않는 코드를 제거하고 난독화를 수행합니다. 이후 D8 도구가 여러 개의 .class 파일을 안드로이드 전용 바이트코드인 .dex 파일로 하나로 묶어 변환합니다.
컴파일된 리소스, .dex 파일, 그리고 라이브러리 파일들을 하나의 압축 파일 형태인 .apk로 병합합니다.
apksigner 도구를 사용하여 개발자의 개인 키로 APK에 디지털 서명을 진행합니다.
이 과정이 끝나야 기기에 설치 가능한 상태가 됩니다.
완성된 하나의 APK를 사용자에게 배포합니다.
해당 파일은 모든 기기 사양을 포함하고 있어 용량이 크며, 사용자는 이 전체 파일을 다운로드하여 설치하게 됩니다.
AAB는 2018년 구글이 도입한 새로운 게시 형식으로, 현재 구글 플레이 스토어의 표준입니다. 앱의 모든 컴파일된 코드와 리소스를 포함하지만, 설치 파일이 아닌 스토어 업로드용 파일입니다.
사용자가 앱을 다운로드할 때, 구글 플레이 서버가 해당 기기의 사양에 딱 맞는 APK만 생성해서 전달합니다. 때문에 평균적으로 APK 대비 용량이 약 15~20% 정도 줄어들어 설치 전환율이 높아집니다.
APK와 반대로 기기에 직접 설치할 수 없으며, 반드시 구글 플레이와 같은 배포 시스템을 거쳐 APK로 변환되어야 합니다.
소스 코드 컴파일과 .dex 변환 과정은 APK와 동일합니다.
하지만 최종 결과물을 만들 때 설치용 파일이 아닌, 앱의 모든 코드와 리소스를 모듈별로 구분한 .aab 파일을 생성합니다.
개발자가 서명된 AAB 파일을 구글 플레이 콘솔에 업로드합니다.
AAB 자체는 기기에 직접 설치할 수 없는 상태입니다.
구글 플레이 서버에 탑재된 bundletool이 업로드된 AAB를 분석하여 지원하는 모든 언어, 화면 밀도(DPI), CPU 아키텍처(ABI)별로 리소스를 쪼개어 관리합니다.
특정 사용자가 앱 다운로드를 요청하면, 구글 서버는 해당 사용자의 기기 정보를 확인합니다.
사용자의 기기에 꼭 필요한 리소스와 코드만 골라내어 최적화된 APK 세트를 실시간으로 조합합니다.
구글이 관리하는 앱 서명 키를 사용하여 조합된 최적화 APK에 서명한 뒤 사용자에게 전달합니다.
사용자의 기기에는 전체 앱의 공통 부분인 base.apk와 해당 기기 사양에 맞는 리소스만 담긴 config.apk들이 나누어져 설치됩니다.
두 유형의 차이점에 대해 간단하게 정리해보죠.
APK는 그 자체로 실행 가능한 최종 설치 파일이지만, AAB는 구글 플레이가 설치용 APK를 생성하기 위해 사용하는 재료 주머니와 같은 출판 포맷입니다.
APK는 모든 기기 대응 리소스를 품고 있어 무겁지만, AAB 기반 배포는 사용자의 기기 사양에 불필요한 데이터를 제외하므로 다운로드 용량이 훨씬 가볍습니다.
APK는 개발자가 로컬에서 서명을 완료하여 배포하는 방식이 주를 이루며, AAB는 보안과 최적화를 위해 구글 플레이 서버에서 앱 서명을 관리하는 방식을 권장합니다.
APK는 앱의 모든 기능을 한 번에 설치해야 하지만, AAB는 특정 기능을 사용자가 원할 때나 특정 조건에서만 추가로 다운로드하게 만드는 동적 기능 배포가 가능합니다.
최종적으로 APK는 완성된 단일 패키지, AAB는 조립 설계도라고 이해할 수 있습니다. 로컬 테스트나 직접 배포가 필요할 때는 APK를, 스토어에 정식 출시하여 사용자에게 최적화된 경험을 제공하고 싶을 때는 AAB를 선택하는 것이 안드로이드 개발의 표준이 되었음을 알려드리며 오늘은 여기서 마치도록 하겠습니다.