모바일 개발에서 App Size Optimization: 기본, 방법 및 실습

App Size Optimization이란

App Size Optimization은 애플리케이션 설치 패키지의 크기를 최소화하는 것을 목표로 하는 모바일 개발 분야입니다. 여기에는 데드 코드 및 리소스 제거, 이미지 압축, 라이브러리 최적화, 다양한 아키텍처를 위한 빌드 분할 및 온디맨드 전송 기술 사용이 포함됩니다.

애플리케이션 크기는 사용자 세그먼트에 따라 불균등하게 영향을 미칩니다. 모바일 인프라가 발달된 지역(미국, 유럽, 일본)에서는 50MB와 100MB의 차이가 눈에 띄지 않을 수 있습니다. 개발도상국(인도, 인도네시아, 브라질)에서는 데이터 요금제 한도와 모바일 인터넷 속도로 인해 추가 메가바이트마다 설치 전환율이 감소합니다. Google Play는 APK 크기를 200MB로 제한하지만 100MB 미만으로 유지할 것을 권장합니다.

iOS App Store의 경우 셀룰러 네트워크를 통한 최대 다운로드 크기는 200MB입니다(2023년 이전에는 150MB였습니다). IPA가 이 한도를 초과하면 사용자는 Wi-Fi를 통해서만 앱을 설치할 수 있습니다. Apple은 App Thinning도 지원하며, 여기에는 Slicing, Bitcode 및 On-Demand Resources — 개발자 개입 없이 특정 기기에서 설치 크기를 자동으로 줄이는 기술 — 가 포함됩니다.

앱 크기가 중요한 이유

앱 크기는 설치 전환율뿐만 아니라 리텐션, 업데이트 빈도 및 첫 실행 속도에도 영향을 미칩니다. 추가 메가바이트마다 사용자와 제품 사용 사이의 장벽이 됩니다.

설치 전환율에 미치는 영향

Google I/O 2024 데이터에 따르면 APK를 10MB 줄이면 설치 전환율이 평균 3.5% 증가합니다. 150MB 이상 앱의 경우 동일 클래스의 50MB 앱보다 전환율이 20–30% 낮을 수 있습니다. 이 효과는 사용자가 설치 전에 크기를 확인하는 Google Play에서 특히 두드러집니다. App Store에서는 크기가 앱 페이지에 표시되며, 데이터 요금제가 제한된 사용자는 설치를 Wi-Fi로 미루고 나중에 앱을 잊어버리는 경우가 많습니다.

업데이트 빈도 및 OTA 업데이트

대규모 앱은 OTA 업데이트 빈도가 낮습니다 — 사용자는 패치 다운로드를 Wi-Fi로 미루고 중요한 보안 수정을 놓칩니다. Google Play는 Incremental Updates(최대 10MB 패치)를 허용하지만 전체 재설치는 여전히 전체 APK 또는 AAB를 다운로드합니다. Apple App Store는 Delta Updates를 사용하여 변경된 파일만 전송하지만 리소스가 변경될 경우 델타도 상당할 수 있습니다.

첫 실행 및 압축 해제

크기는 첫 실행 시간에 직접적인 영향을 미칩니다. 앱은 리소스 압축을 풀고, 코드를 컴파일(Android)하거나 캐시에 서명(iOS)해야 합니다. 200MB 앱은 평균 기기에서 50MB 앱보다 10–15초 느리게 시작될 수 있습니다. 이로 인해 온보딩 경험이 저하되어 — 사용자가 로딩을 기다리지 않고 앱을 닫을 수 있습니다.

리소스 및 에셋 최적화

리소스 — 이미지, 글꼴, 사운드, 비디오 — 는 일반적인 모바일 앱 크기의 60–80%를 차지합니다. 리소스 최적화는 최소한의 노력으로 가장 큰 이득을 제공합니다. 주요 방향은 압축, 중복 및 사용하지 않는 에셋 제거, 올바른 형식 선택입니다.

이미지 최적화

WebP — Google의 이미지 형식으로, 동일한 시각적 품질에서 PNG보다 25–35%, JPEG보다 15–20% 더 나은 압축을 제공합니다. Android는 API 18부터 WebP를 기본 지원합니다. iOS의 경우 SDWebImage 또는 Kingfisher 라이브러리를 통해 WebP가 지원되며 iOS 17부터 기본 지원이 추가되었습니다. AVIF — WebP보다 추가로 10–15% 절감을 제공하지만 디코딩 속도가 더 느린 현대적인 형식입니다.

사용하지 않는 리소스 제거 — 크기를 줄이는 가장 간단한 방법입니다. Android에서는 Android Studio로 리팩토링을 사용합니다: Analyze → Run Inspection → Unused Resources. iOS에서는 — Build Settings → Remove Unused Resources. 프로젝트에는 이전 버전의 스프라이트, 오래된 아이콘, 사용하지 않는 시작 화면 이미지가 남아 있어 기능적 부하 없이 크기를 부풀리는 경우가 많습니다.

글꼴 및 사운드 최적화

사용자 정의 글꼴은 특히 전체 서체(모든 스타일: Regular, Bold, Italic, BoldItalic)가 포함된 경우 5–15MB를 차지할 수 있습니다. 서브셋팅 — 앱에서 지원하지 않는 언어의 글리프 제거 — 을 통해 필요한 스타일과 문자 하위 집합만 사용합니다. Google Fonts 및 Transfonter와 같은 서비스를 통해 최소 문자 세트를 만들 수 있습니다. 오디오의 경우 WAV 및 비압축 형식 대신 AAC/HE-AAC를 사용합니다 — 품질 손실 없이 최대 90% 절감.

코드 및 라이브러리 최적화

코드는 앱 크기의 20–40%를 차지하지만, 기능을 손상시킬 위험 없이 종속성 분석, 난독화 및 데드 코드 제거가 필요하기 때문에 리소스보다 최적화가 더 복잡합니다.

Android용 ProGuard 및 R8

ProGuard는 코드 난독화, 최소화 및 최적화를 수행하는 Android 도구입니다. R8 — 그 후속으로 Android Gradle Plugin에 내장되어 더 빠르고 효율적으로 작동합니다. R8은 사용하지 않는 클래스와 메서드를 제거하고, 변수 이름을 줄이며, 명령어 수를 줄이기 위해 코드를 다시 작성합니다. R8을 사용한 DEX 파일 크기의 일반적인 감소율은 30–50%입니다.

// build.gradle — 최소화를 위한 R8 구성
android {
    buildTypes {
        release {
            minifyEnabled true
            proguardFiles getDefaultProguardFile(
                'proguard-android-optimize.txt')
            shrinkResources true
        }
    }
}

라이브러리 및 종속성 최적화

라이브러리 — 크기 비대화의 일반적인 원인입니다. 하나의 라이브러리가 앱에 직접적인 이점 없이 크기를 5–20MB 증가시키는 전이적 종속성을 끌어올 수 있습니다. 명시적 종속성 선언과 함께 Android용 Gradle Version Catalog 및 iOS용 Swift Package Manager를 사용합니다. Android Studio의 Build Analyzer 또는 Xcode Build Timeline으로 크기를 분석합니다. 무거운 라이브러리를 더 가벼운 대안으로 교체합니다: 예를 들어 Apache HTTP(15MB) 대신 OkHttp(3MB).

iOS에서 사용하지 않는 코드 제거

Dead Code Stripping — Xcode의 링크 단계에서 사용하지 않는 메서드와 클래스를 자동으로 제거합니다. Build Settings → Dead Code Stripping = YES로 활성화합니다. Bitcode — Apple이 다양한 아키텍처로 재컴파일할 수 있는 중간 표현으로, 사용하지 않는 함수를 제거합니다. 그러나 Xcode 14부터 Bitcode는 선택 사항이 되었으며, 크기 감소에 대한 기여도는 Objective-C 프로젝트의 경우 5–15%, Swift의 경우 그보다 낮습니다.

App Thinning 및 온디맨드 전송

App Thinning — 특정 기기에 필요한 리소스만 전송하여 설치된 앱의 크기를 자동으로 줄이는 Apple의 기술입니다. Slicing, On-Demand Resources 및 Bitcode의 세 가지 구성 요소로 이루어져 있습니다. Android에서는 Dynamic Delivery가 포함된 Android App Bundle(AAB)이 이에 해당합니다.

Android App Bundle(AAB)

AAB — Google Play의 게시 형식으로, 스토어가 각 기기에 대해 개별적으로 APK를 생성하며 해당 아키텍처(armeabi-v7a, arm64-v8a), 화면 밀도(mdpi, hdpi, xhdpi, xxhdpi, xxxhdpi) 및 언어의 리소스만 포함합니다. 범용 APK에서 AAB로 전환 시 일반적인 설치 크기 감소율은 20–40%입니다. Play Feature Delivery는 온디맨드 모듈 로드를 허용하며 Install-time 모듈은 기본 설치에 포함됩니다.

// build.gradle — AAB 및 Dynamic Features 구성
android {
    bundle {
        language {
            enableSplit = true
        }
        density {
            enableSplit = true
        }
        abi {
            enableSplit = true
        }
    }
}

iOS의 On-Demand Resources

On-Demand Resources(ODR) — 리소스(게임 레벨, 고해상도 이미지, 비디오)가 사용자에게 실제로 필요할 때만 Apple 서버에서 다운로드되는 iOS 메커니즘입니다. 초기 설치 크기를 50–80%까지 줄일 수 있습니다. 리소스는 세 가지 범주로 나뉩니다: Initial Install Tags(설치 중 다운로드), Prefetched Tag Order(설치 후 백그라운드에서 다운로드), On-Demand(요청 시에만 다운로드). Apple은 첫 화면에서 필요하지 않은 콘텐츠(게임 레벨, 추가 콘텐츠, 비디오 튜토리얼)에 ODR을 사용할 것을 권장합니다.

SwiftUI는 Bundle.module 속성을 통해 ODR을 지원하고 UIKit은 NSBundleResourceRequest를 사용합니다. Unity 및 Unreal Engine의 게임 경우 ODR은 네이티브 래퍼 수준에서 통합됩니다. 주요 제한 사항은 저장 공간이 부족할 때 ODR 리소스가 시스템에 의해 삭제된다는 점이므로 중요한 데이터는 메인 빌드에 포함되어야 합니다.