App Thinning — 개념, 구성 요소 및 작동 방식

App Thinning이란

App Thinning — Apple이 iOS 9(2015년 9월)와 함께 도입한 iOS 앱 배포 최적화를 위한 포괄적인 기술입니다. App Thinning의 목표는 소스 코드와 기능을 변경하지 않고 사용자가 기기에 다운로드하는 앱의 크기를 최소화하는 것입니다. 이 기술은 빌드 단계(컴파일), App Store 측(배포), 기기(리소스 관리)의 세 가지 수준에서 작동합니다.

App Thinning 이전에는 개발자가 모든 가능한 기기에 대한 리소스(@2x 및 @3x 이미지, 32비트 및 64비트 코드, 다양한 GPU용 Metal 셰이더)를 바이너리 파일에 포함했습니다. 이로 인해 앱 크기가 비대해졌습니다. Retina HD 디스플레이를 탑재한 iPhone 6 Plus 사용자는 사용되지 않는 iPad Pro용 벡터 리소스를 받게 되었습니다. Apple은 빌드 작업의 일부를 App Store 서버로 이전하여 이 문제를 해결했습니다.

Apple의 연구(WWDC 2015, Session 412)에 따르면 여러 아키텍처와 해상도를 지원하는 일반적인 앱은 App Thinning 적용 후 30-50%까지 줄어들 수 있습니다. 고해상도 텍스처가 많은 게임의 경우 절감 효과가 70-80%에 달할 수 있습니다. Apple은 기술을 계속 개선하고 있습니다. iOS 17에서는 ARM64e 최적화와 Swift Package Manager를 사용하는 앱을 위한 On-Demand Resources 작업 개선이 추가되었습니다.

App Thinning이 해결하는 문제

모바일 앱의 크기는 계속 증가하고 있습니다. Sensor Tower(2025)에 따르면 지난 5년간 iOS 앱의 평균 크기가 45% 증가했습니다. 데이터 요금제가 제한적이거나 인터넷이 느린 사용자에게는 모든 메가바이트가 중요합니다. App Thinning은 개발자의 참여 없이 이 문제를 해결합니다. 프로젝트 설정에서 지원을 활성화하고 App Store Connect에 빌드를 업로드하기만 하면 됩니다.

App Thinning의 작동 방식

App Thinning 프로세스는 App Store Connect에 앱 아카이브를 업로드한 후 시작됩니다. App Store는 바이너리 파일을 분석하고 아키텍처(armv7, arm64, arm64e), 화면 해상도(iPhone, iPad) 및 iOS 버전별로 세그먼트로 나눕니다. 각 조합에 대해 별도의 변형이 생성됩니다. 사용자가 “다운로드”를 클릭하면 App Store는 기기 모델, iOS 버전 및 연결 유형(Wi-Fi/모바일 네트워크)을 확인하고 해당 변형만 전송합니다.

사용자에게 프로세스는 투명합니다. “경량 버전” 선택 옵션이나 설정 대화상자가 없습니다. App Store는 다운로드 요청 시 서버로 전송되는 기기 메타데이터를 기반으로 가장 적합한 변형을 자동으로 선택합니다. 기기가 Wi-Fi를 사용하는 경우 App Store는 더 높은 품질의 리소스(예: iPhone 16 Pro용 ProRes 비디오)가 포함된 변형을 보낼 수 있습니다. 모바일 네트워크를 통해 다운로드할 때는 최소한의 세트가 사용됩니다.

두 번째 최적화 수준은 Bitcode입니다. ENABLE_BITCODE 옵션이 활성화되면 Xcode는 앱을 머신 코드가 아닌 중간 LLVM 표현으로 컴파일합니다. App Store는 Bitcode를 사용자의 프로세서 아키텍처에 맞게 다시 컴파일하여 Apple이 개발자의 앱 업데이트 없이 새로운 칩 세대(A17, M4)에 대한 컴파일러 최적화를 적용할 수 있게 합니다. Bitcode는 watchOS 및 tvOS에서는 필수이지만 iOS에서는 선택 사항입니다.

App Thinning의 구성 요소: Slicing, Bitcode, ODR

App Thinning은 각각 최적화의 특정 측면을 담당하는 세 가지 독립적인 메커니즘으로 구성됩니다. Slicing은 바이너리 파일을 아키텍처와 화면 해상도에 따라 변형으로 나눕니다. 개발자는 Asset Catalogs를 통해 Slicing을 구성합니다. Xcode는 대상 기기와 일치하는 리소스만 슬라이스에 자동으로 포함합니다. 예를 들어 iPhone SE(3세대)는 @2x 이미지와 arm64 코드만 받고, iPad Pro M4는 @3x 이미지와 arm64e 코드를 받습니다.

Bitcode — LLVM IR(Intermediate Representation) — 프로그램의 머신 독립적 표현입니다. Bitcode가 활성화되면 Xcode는 최종 머신 코드를 생성하지 않고 중간 표현을 저장합니다. App Store Connect는 빌드 업로드 시 Bitcode를 받아 지원되는 모든 기기의 아키텍처로 다시 컴파일합니다. Bitcode를 통해 Apple은 개발자의 컴파일 단계에서 사용할 수 없는 최적화(예: M4 칩의 새로운 프로세서 명령어 SME, SVE 사용)를 적용할 수 있습니다.

On-Demand Resources(ODR) — 세 번째 메커니즘으로, 사용 후 앱 리소스를 언로드할 수 있습니다. 개발자는 리소스(게임 레벨, 온보딩 이미지, 비디오)에 ODR 태그를 지정합니다. iOS는 태그된 리소스를 필요에 따라 백그라운드에서 다운로드하고 메모리 부족 시 또는 사용 후 언로드합니다. ODR은 특히 대량의 콘텐츠가 있는 게임에 효과적입니다. 첫 번째 레벨은 앱과 함께 제공되고 나머지는 진행에 따라 다운로드될 수 있습니다.

각 구성 요소를 선택해야 하는 경우

App Thinning 메커니즘의 선택은 앱 유형과 대상 사용자에 따라 달라집니다. Slicing은 항상 활성화하는 것이 좋습니다. Asset Catalogs의 올바른 구성 외에 개발자의 추가 작업이 필요하지 않으며 크기를 20-30% 안정적으로 줄여줍니다. Bitcode는 사용자 정의 Metal 셰이더를 사용하거나 재컴파일 없이 새로운 Apple 아키텍처를 지원하려는 앱에 적합합니다. ODR은 대량의 콘텐츠가 있는 앱(게임, 사진 편집 앱, 스트리밍 앱)에 적합합니다.

일반적인 비즈니스 앱(데이터 피드, 양식, REST API)의 경우 Slicing과 온보딩 이미지용 최소 ODR 구성으로 충분합니다. 게임은 3D 그래픽으로 세 가지 메커니즘 모두의 이점을 얻습니다. Slicing은 불필요한 셰이더를 제거하고, Bitcode는 GPU에 맞게 렌더링을 최적화하며, ODR은 완료된 레벨을 언로드합니다. Apple(WWDC 2024)에 따르면 세 가지 메커니즘의 조합은 유니버설 바이너리와 비교하여 초기 설치 크기를 평균 45-55% 줄입니다.

Xcode에서 App Thinning 설정

Xcode 프로젝트에서 App Thinning을 활성화하려면 여러 단계를 따라야 합니다. Slicing은 빌드 설정의 App Thinning을 통해 구성됩니다: Build Settings → App Thinning. None(최적화 없음), Automatic(기본 자동 설정), Manual(테스트용 특정 변형 선택)의 세 가지 값이 있습니다. Apple은 대부분의 프로젝트에 Automatic을 권장합니다.

Asset Catalogs의 경우 리소스를 올바르게 구성하는 것이 중요합니다. 이미지는 너비/높이를 지정하여 범용 카탈로그에 배치되고 Xcode는 자동으로 @1x, @2x 및 @3x 변형을 만듭니다. Xcode는 빌드 시 프로젝트에서 사용된 해상도만 포함합니다. Metal 셰이더는 각 GPU 제품군(Apple GPU, PowerVR, Mali)에 대해 별도로 컴파일되며, 이 또한 Asset Catalogs를 통해 관리됩니다.

Bitcode는 Build Settings에서 ENABLE_BITCODE = YES 플래그로 활성화됩니다. iOS의 경우 이 플래그는 선택 사항이지만(Xcode 14부터 기본적으로 꺼짐), watchOS 및 tvOS의 경우 필수입니다. 서드파티 라이브러리를 사용하는 프로젝트에서 Bitcode를 활성화하는 경우 해당 라이브러리도 모두 Bitcode로 컴파일되어야 합니다. 그렇지 않으면 빌드가 실패합니다. Bitcode는 컴파일 시간을 20-30% 증가시키지만 향후 아키텍처와의 완전한 호환성을 제공합니다.

App Thinning 결과 확인

App Store Connect에 업로드한 후 Activity → Build Metric 섹션에서 슬라이스 크기를 확인할 수 있습니다. App Store Connect는 다양한 기기에 대한 Estimated App Store Size를 표시합니다. 로컬 확인을 위해 Xcode는 로컬 머신에서 슬라이스를 생성하는 -exportArchive 플래그와 thinning 옵션이 있는 xcodebuild 명령을 제공합니다. Slicing의 결과는 아카이브 후 Organizer(Window → Organizer)에서 확인할 수 있습니다. App Thinning Profiles 탭에 다양한 기기의 크기가 표시됩니다.

# Slicing 로컬 확인
xcodebuild -exportArchive \
  -archivePath "App.xcarchive" \
  -exportPath "export/" \
  -exportOptionsPlist "export.plist" \
  -thinning "<thin-for-all-variants>"

Xcodebuild는 -thinning 플래그와 함께 아키텍처, 비트 수 및 GPU의 각 조합에 대한 .app 파일을 만듭니다. <thin-for-all-variants> 매개변수는 가능한 모든 변형을 생성하여 확인에 유용합니다. CI 파이프라인의 경우 iPhone14,4(iPhone SE 3)와 같은 특정 조합을 지정합니다. 결과 .app 파일은 app-size 유틸리티로 분석할 수 있습니다.

App Thinning의 이점 및 영향

App Thinning의 주요 이점은 최종 사용자를 위한 다운로드 크기 감소입니다. Apple(WWDC 2024)에 따르면 세 가지 App Thinning 메커니즘을 모두 사용하는 일반적인 앱은 모바일 네트워크에서 평균 40% 더 빠르게 다운로드되고 디스크 공간을 35% 적게 차지합니다. 이는 설치 전환율에 직접적인 영향을 미칩니다. Sensor Tower에 따르면 앱 크기가 10MB 증가할 때마다 전환율이 1% 감소합니다.

두 번째 이점 — Bitcode를 통한 향후 기기 최적화입니다. Apple은 개발자의 참여 없이 Bitcode 앱을 새로운 아키텍처로 다시 컴파일할 수 있습니다. 예를 들어 Intel에서 Apple Silicon(M1)으로 전환하는 동안 Bitcode 앱은 추가 빌드 없이 Rosetta 2를 통해 macOS에서 작동했습니다. Bitcode를 활성화하지 않은 개발자는 arm64용으로 앱을 다시 컴파일해야 했습니다.

세 번째 이점 — ODR(On-Demand Resources)은 기기 저장 공간의 부담을 줄입니다. Asphalt 8: Airborne과 같은 수십 개의 레벨이 있는 게임은 ODR을 사용하여 진행에 따라 새로운 트랙을 다운로드합니다. 개발자는 앱과 함께 다운로드되는 리소스에 Initial Install Tags를 설정하고 설치 후 백그라운드에서 다운로드되는 콘텐츠에 Prefetch Tags를 설정할 수 있습니다. Apple은 ODR 제한을 관리합니다: 요청당 최대 512MB, 기기의 총 캐시 최대 20GB입니다.

App Thinning의 제한 사항

App Thinning에는 앱 설계 시 고려해야 할 몇 가지 중요한 제한 사항이 있습니다. 첫째, Slicing은 Enterprise(in-house) 또는 Ad Hoc을 통해 배포되는 앱에는 적용되지 않습니다. 이러한 빌드에는 모든 변형이 포함되어 있으며 App Store를 통과하지 않습니다. Slicing 테스트를 위해 개발자는 TestFlight를 사용할 수 있습니다. TestFlight도 Apple 서버에서 Slicing을 처리합니다.

둘째, Bitcode는 빌드 시간과 .xcarchive 아카이브 크기를 약 30-50% 증가시킵니다. 모든 서드파티 라이브러리가 Bitcode를 지원하는 것은 아닙니다. 하나 이상의 종속성이 Bitcode 없이 컴파일된 경우 ENABLE_BITCODE로 프로젝트 빌드가 실패합니다. Apple은 Bitcode를 활성화하기 전에 라이브러리 호환성을 확인할 것을 권장합니다. 또한 Bitcode는 Swift Package Manager를 완전히 지원하지 않습니다. 일부 Swift 패키지는 Bitcode 빌드를 손상시킬 수 있습니다.

셋째, On-Demand Resources는 콘텐츠의 즉시 사용을 보장하지 않습니다. ODR 다운로드는 백그라운드에서 이루어지며 기기가 저전력 모드이거나 신호가 약한 경우 지연될 수 있습니다. 개발자는 NSBundleResourceRequest를 통해 ODR 다운로드 상태를 처리하고 사용자에게 진행 표시기를 표시해야 합니다. ODR 다운로드 실패는 앱 기능을 차단해서는 안 됩니다. Graceful Fallback이 필요합니다.