Slicing은 App Thinning의 메커니즘으로, App Store가 자동으로 바이너리 파일의 여러 변형을 생성하고 각각 특정 기기 모델에 대한 리소스만 포함하도록 합니다. Apple Developer Documentation, 2026에 따르면 Slicing은 지원되지 않는 구성의 리소스를 배포에서 제외하여 설치 크기를 줄입니다. 작동 원리, 슬라이싱 변형 및 결과 확인 방법을 살펴보겠습니다.
핵심 요점
Slicing은 App Thinning의 구성 요소로, App Store 측에서 애플리케이션 바이너리의 변형(슬라이스)을 생성하는 역할을 합니다. 개발자가 지원되는 모든 구성에 대한 코드와 리소스를 포함하는 유니버설 팻 바이너리를 업로드하면 App Store가 이를 분석하고 여러 슬라이스를 생성합니다: A17 프로세서가 탑재된 iPhone용, M4가 탑재된 iPad용, Apple Watch용 등으로 나뉩니다. 각 슬라이스에는 해당 아키텍처와 해상도의 특정 조합에 필요한 코드 조각과 리소스만 포함됩니다.
iOS 9 이전에는 개발자가 수동으로 여러 기기용으로 별도의 바이너리 파일을 만들거나 모든 것을 한 번에 포함하는 유니버설 팻 바이너리를 배포했습니다. Slicing은 이 프로세스를 완전히 자동화했습니다: 개발자는 Xcode에서 하나의 프로젝트를 준비하고 App Store Connect에 하나의 아카이브를 업로드하기만 하면 서버 측 Slicing이 최적의 수의 변형을 생성합니다. 사용자는 슬라이싱 프로세스를 전혀 볼 수 없으며 — 자신의 기기에 최적화된 준비된 .app을 받습니다.
Slicing은 코드와 이미지뿐만 아니라 Metal 셰이더에도 적용됩니다. Apple GPU는 자체 명령어 세트(Metal Shading Language)를 사용하며, 이는 PowerVR 또는 ARM Mali 명령어와 다릅니다. Slicing은 대상 기기의 GPU 제품군에 대한 셰이더만 슬라이스에 포함시킵니다. 이는 사용자 정의 셰이더가 있는 게임에서 특히 중요합니다 — 예를 들어 고품질 후처리 효과는 강력한 GPU(iPad Pro M4, iPhone 16 Pro Max)가 있는 기기에서만 컴파일됩니다.
Xcode 컴파일러는 여러 아키텍처(armv7, arm64, arm64e)가 있는 팻 바이너리를 생성하지만 리소스를 제거하지는 않습니다 — 모든 해상도의 모든 이미지가 .app 내에 남아 있습니다. Slicing은 더 나아갑니다: Asset Catalogs, Metal 셰이더 및 Swift 라이브러리를 분석하고 각 슬라이스에서 특정 대상에 필요하지 않은 것을 제거합니다. 예를 들어 @3x 그래픽은 iPhone SE 슬라이스에 포함되지 않으며, iPhone별 컨트롤러(별도 리소스로 추출된 경우)는 iPad Air 슬라이스에 포함되지 않습니다.
Slicing 프로세스는 App Store Connect에 빌드를 업로드한 후 시작되며 분석, 슬라이싱 및 패키징의 세 단계로 구성됩니다. 분석 단계에서 App Store 서버는 바이너리 파일을 파싱하고 지원되는 아키텍처, 기기, 화면 해상도 및 iOS 버전에 대한 정보를 추출합니다. App Store는 모든 상용 Apple 모델을 기술 사양에 매핑한 데이터베이스를 사용합니다 — 기기 데이터베이스는 각 iOS 릴리스와 함께 업데이트됩니다.
슬라이싱 단계에서 서버는 각 고유 조합에 대해 바이너리 파일의 개별 복사본을 만듭니다. 이를 위해 App Store는 Asset Catalogs에서 특정 태그(idiom, subtype, scale)가 있는 이미지를 추출하고 대상 기기와 일치하는 것만 선택하여 새 리소스 번들을 조합합니다. Swift 표준 라이브러리도 슬라이싱 대상이 되며, 사용되지 않는 심볼과 메서드가 제거됩니다(데드 코드 스트리핑).
패키징 단계에서 각 슬라이스는 별도의 배포 패키지에 배치되고 메타데이터(이 슬라이스가 대상으로 하는 기기 모델 목록)와 연결됩니다. 사용자가 애플리케이션을 다운로드하면 App Store는 기기 모델, iOS 버전 및 연결 유형에 따라 적절한 슬라이스를 선택합니다. 정확히 일치하는 것이 없으면 서버는 특성이 가장 가까운 슬라이스를 사용합니다. Apple은 모든 변형을 CloudKit CDN 네트워크에 저장하여 전 세계에 빠르게 전송합니다.
Slicing은 App Thinning의 세 가지 메커니즘 중 하나이지만 다운로드 크기 감소에 가장 크게 기여합니다. Bitcode는 기계 코드 최적화를 담당하고, On-Demand Resources는 기기에서 리소스 관리를 담당하며, Slicing은 배포 단계에서 중복 리소스를 제거합니다. Slicing이 없으면 처음 두 메커니즘은 여전히 작동하지만 사용자는 모든 기기용 리소스를 받게 되어 Asset Catalogs 수에 따라 크기가 20–40% 증가합니다.
Slicing과 Bitcode의 차이점은 적용 지점에 있습니다: Slicing은 리소스 수준(이미지, 셰이더, NIB 파일)에서 작동하고 Bitcode는 기계 코드 수준에서 작동합니다. Slicing은 코드를 아키텍처(arm64 vs arm64e)로 나누고 Bitcode는 Apple이 새로운 아키텍처용 코드를 다시 컴파일할 수 있게 합니다. Bitcode + Slicing을 함께 사용하면 최대 최적화를 제공합니다: Bitcode가 특정 아키텍처용 코드를 생성하고 Slicing이 해당 아키텍처에 불필요한 리소스를 제거합니다.
On-Demand Resources와의 관계 — Slicing과 ODR은 중복되지 않습니다. Slicing은 어떤 리소스가 기기 배포에 도달할지 결정하고 ODR은 이러한 리소스가 로드 및 언로드되는 시기를 관리합니다. 개발자는 리소스에 ODR 태그를 지정할 수 있으며 Slicing은 기기와 일치하는 경우 슬라이스에 포함시킵니다. Apple은 최소 설치 크기를 위해 세 가지 메커니즘을 모두 동시에 사용할 것을 권장합니다.
| 메커니즘 | 최적화 대상 | 적용 시점 | 크기 영향 |
|---|---|---|---|
| Slicing | 리소스(이미지, 셰이더) | App Store 측 | 중복 리소스의 ~30% 제거 |
| Bitcode | 기계 코드 | 사용자 다운로드 시 | 아키텍처에 맞게 코드 최적화 |
| ODR | 기기 내 리소스 | 설치 후 | 초기 크기를 40–60% 감소 |
Slicing은 여러 차원에 따라 개별 슬라이스를 만듭니다: 프로세서 아키텍처, 화면 크기(해상도), iOS 버전 및 GPU 제품군(Metal용). 아키텍처는 CPU 명령어 세트를 결정합니다: arm64 — 기본 64비트 세트(iPhone 5s — iPhone X), arm64e — Pointer Authentication 및 PAC 지원이 포함된 확장 세트(iPhone XS 이상, A12X+ 탑재 iPad Pro). arm64e용 슬라이스에는 arm64 기기에서 사용할 수 없는 메모리 보호 명령어가 포함된 코드가 포함됩니다.
화면 해상도 — Slicing의 두 번째 주요 차원입니다. Apple은 @1x(iPhone 3GS), @2x(iPhone 4 — iPhone SE 3), @3x(iPhone 6 Plus 이상) 스케일과 iPad 특정(추가 메트릭이 있는 2x 및 3x)을 사용합니다. Slicing은 대상 기기와 일치하는 스케일의 이미지만 슬라이스에 포함시킵니다. Xcode에서 Asset Catalogs를 적절히 구성하면 리소스 세트를 수동으로 관리할 필요가 없어집니다 — 카탈로그에 이미지를 추가하고 지원되는 기기 유형을 지정하기만 하면 됩니다.
GPU 제품군 — 세 번째 차원으로, Metal 애플리케이션에 매우 중요합니다. Apple은 GPU를 세대별로 분류합니다: Apple GPU family 1(A7), family 2(A8), ... family 8(M4). Metal 셰이더는 각 제품군별로 별도로 컴파일되는데, Metal Shading Language 명령어 세트가 GPU 세대마다 확장되기 때문입니다. Slicing은 대상 기기의 GPU 제품군에 대한 셰이더만 슬라이스에 포함시켜 렌더링에 Metal을 사용하는 게임 및 애플리케이션의 크기를 크게 줄입니다.
CPU 아키텍처는 슬라이스 크기에 직접적인 영향을 미칩니다: arm64e 코드에는 추가 Pointer Authentication(PAC) 및 Signed Return Address 명령어가 포함되어 arm64에 비해 바이너리 파일이 5–10% 증가합니다. 그러나 이 증가는 Slicing이 arm64e 코드를 A12+ 프로세서가 탑재된 기기의 슬라이스에만 포함시킨다는 사실로 상쇄됩니다. A15 Bionic이 탑재된 iPhone SE(3세대)의 경우 Slicing은 이 칩의 성능에 최적화된 별도의 슬라이스를 만듭니다.
Xcode에서 Slicing 구성은 최소한입니다 — 주요 구성은 Asset Catalogs와 Build Settings를 통해 이루어집니다. Asset Catalog에는 기기 유형(Any, iPhone, iPad, Apple Watch, Apple TV)별로 구성된 리소스가 포함되어야 하며 스케일과 표시 모드가 올바르게 지정되어야 합니다. Xcode는 Deployment Target 설정에서 지정된 대상 기기와 일치하는 리소스만 자동으로 빌드에 포함시킵니다.
Xcode의 주요 Slicing 설정은 Build Setting App Thinning입니다. 사용 가능한 값:
General → Deployment Info의 Targeted Device Families는 애플리케이션이 어떤 기기 유형용으로 빌드되는지 결정합니다(iPhone / iPad / Universal). Slicing은 슬라이싱 시 이 매개변수에 의존합니다 — 애플리케이션이 iPhone만 지원하는 경우 iPad용 슬라이스가 생성되지 않습니다. Deployment Target(최소 iOS 버전)도 Slicing에 영향을 줍니다: 오래된 iOS 버전은 iOS 13+에서 필요하지 않은 armv7 슬라이스가 필요할 수 있습니다. Apple은 Deployment Target을 최신 안정적인 iOS 버전으로 설정할 것을 권장합니다 — 이렇게 하면 슬라이스 수와 바이너리 크기가 줄어듭니다.
최대 Slicing 효율을 위해 Asset Catalogs는 각 리소스에 특정 태그를 사용해야 합니다. Xcode는 Attributes Inspector에서 이미지에 대해 Width Class(Any, Compact, Regular), Height Class(Any, Compact, Regular), Gamut(sRGB, Display P3), Memory(Any, Low, High), Graphics(Any, Low, High)를 제공합니다. 이러한 태그를 결합하여 개발자는 각 이미지가 어떤 슬라이스에 나타날지 제어합니다. 예를 들어 Regular Width + Regular Height 태그가 있는 iPad 이미지는 가로 방향의 iPad 슬라이스에만 나타납니다.
# 특정 기기용 슬라이스 내보내기
xcodebuild -exportArchive \
-archivePath "App.xcarchive" \
-exportPath "sliced/" \
-exportOptionsPlist "export.plist" \
-thinning "iPhone17,2" # iPhone 16 Pro Max
Xcodebuild는 -thinning 매개변수와 모델 식별자를 사용하여 해당 모델에 대해서만 슬라이스를 만듭니다. 식별자 목록은 Apple 기기 데이터베이스에서 찾을 수 있습니다(형식: iPhone17,2 — iPhone 16 Pro Max, iPad14,1 — iPad Pro 11 M4). 이 방법은 App Store Connect에 제출하기 전에 슬라이스 크기를 확인하는 데 유용합니다. CI/CD는 자동 확인을 위해 이 명령을 사용할 수 있습니다 — 슬라이스 크기가 제한(예: 모바일 다운로드의 경우 100MB)을 초과하면 파이프라인이 경고를 발행합니다.
App Store Connect에 아카이브를 업로드한 후 Apple은 슬라이스 크기에 대한 상세한 통계를 제공합니다. App Store Connect → Activity → 빌드 선택 → App Thinning — 기기 카테고리별 Estimated App Store Size를 표시합니다: iPhone, iPad, Apple Watch, tvOS. 크기는 iOS 버전과 프로세서 유형별로 분류됩니다. 슬라이스가 예상 크기를 초과하면 App Store Connect가 노란색 경고로 표시합니다.
Xcode Organizer를 통한 로컬 확인: 아카이브 후 Window → Organizer를 열고 아카이브를 선택한 다음 App Thinning Profiles를 클릭합니다. Xcode는 현재 프로젝트 구성을 기반으로 각 가능한 슬라이스의 크기를 표시합니다. 특정 Slicing 프로필로 IPA를 생성하기 위한 Export 옵션도 사용할 수 있습니다. Xcode는 각 슬라이스에 포함된 리소스에 대한 정보가 담긴 .app-thinning.plist 파일을 생성합니다.
CI/CD에서 Slicing 확인을 자동화하려면 -thinning과 함께 xcodebuild를 사용하고 생성된 .app 파일의 크기를 분석합니다. Apple은 명령줄 유틸리티 app-size(Xcode Command Line Tools를 통해 설치)를 제공하며, 이는 코드 크기, 카테고리별 리소스 크기(이미지, 셰이더, NIB), Swift 라이브러리 크기를 포함한 상세 보고서를 출력합니다. Asset Catalog 최적화 전후의 슬라이스 크기를 비교하면 잘못된 구성으로 인해 Slicing에 참여하지 않는 리소스를 식별하는 데 도움이 됩니다.
# 슬라이스 크기 분석
app-size -m "sliced/App.app" \
--format json
App-size는 리소스 카테고리별로 분류된 JSON 보고서를 출력합니다. Slicing이 올바르게 구성된 경우 “images” 섹션에는 하나의 스케일 세트(@2x 또는 @3x)만 포함되고 모든 변형이 포함되지는 않습니다. Asset Catalog 구성 오류는 모든 스케일(@1x, @2x, @3x)이 슬라이스에 존재할 때 나타납니다 — 이는 Xcode가 이러한 이미지의 대상 기기를 결정할 수 없어 Slicing이 작동하지 않았음을 의미합니다.
자주 묻는 질문
네, TestFlight도 Slicing을 지원합니다. 테스터가 TestFlight를 통해 애플리케이션을 다운로드하면 Apple 서버가 테스터의 기기에 최적화된 슬라이스를 제공합니다. App Store Connect는 Enterprise 및 Ad Hoc 빌드를 제외하고 TestFlight를 포함한 모든 배포에 대해 Slicing을 자동으로 처리합니다.
네, Asset Catalogs에서 각 이미지의 특정 기기 유형 플래그를 해제할 수 있습니다. Xcode는 Attributes Inspector에서 리소스가 포함되어야 하는 Idiom(iPhone, iPad, Apple Watch, Mac)과 스케일을 지정할 수 있습니다. 리소스가 모든 기기에 필요한 경우 모든 스케일로 Universal을 사용하십시오.
사용자 정의 프레임워크(.framework)도 XCFramework(여러 아키텍처 포함)로 빌드된 경우 Slicing에 참여합니다. App Store는 대상 기기와 일치하는 프레임워크 아키텍처만 슬라이스에 포함시킵니다. 정적 라이브러리(.a)는 Slicing 대상이 아니며 바이너리 파일에 완전히 임베드됩니다.
Xcode Organizer는 estimated size(예상 크기)를 표시합니다 — Apple 서버에서의 실제 슬라이싱을 고려하지 않은 예측 크기입니다. App Store Connect는 Slicing 후 실제 크기를 표시하며, 서버가 로컬에서 사용할 수 없는 추가 최적화(LZFSE 알고리즘, Zstandard 리소스 압축)를 적용하기 때문에 예상보다 10–15% 작을 수 있습니다.
네, Slicing은 SwiftUI와 완전히 호환됩니다. Asset Catalogs는 SwiftUI에서 Image, Color 및 SymbolImage 유형을 통해 사용됩니다. Slicing은 인터페이스 구축에 SwiftUI 또는 UIKit이 사용되는지 여부에 관계없이 벡터 및 래스터 이미지, SF Symbols 및 Metal 셰이더에 적용됩니다.
요약
턴키 방식의 모바일 애플리케이션을 개발해 드립니다
IT Sectr는 2017년부터 스타트업과 기업을 위한 iOS 및 Android 애플리케이션을 만듭니다. 저희가 상담해 드리고 최적의 솔루션을 제안하겠습니다.