모바일 개발에서의 빌드 및 배포: 정의, 형식 및 작동 방식

빌드 형식: APK, AAB, IPA

APK vs AAB

APK(Android Package Kit) — Android에서 모바일 애플리케이션을 빌드하고 게시하는 전통적인 형식입니다. APK에는 애플리케이션의 모든 코드, 리소스 및 매니페스트가 포함됩니다. AAB(Android App Bundle) — Google이 2018년에 도입하고 2021년 8월부터 새로운 애플리케이션에 필수가 된 형식입니다. AAB는 직접 설치되지 않으며, Google Play가 각 기기에 최적화된 APK를 AAB에서 동적으로 생성합니다.

AAB의 장점: 다운로드 크기가 평균 15% 작습니다(필요한 리소스만 제공: 올바른 화면 밀도, 언어, CPU 아키텍처). AAB는 모듈식 전송도 지원하므로 주문형(Play Feature Delivery) 또는 지연(Play On-Demand)으로 모듈을 로드할 수 있습니다. 개발자의 경우 AAB는 필수이며, Google Play 외부 배포(사이드로딩, 마켓플레이스)의 경우 APK만 사용됩니다.

IPA

IPA(iOS App Store Package) — iOS 설치 파일로, 서명된 애플리케이션이 포함된 ZIP 아카이브입니다. IPA에는 Payload/ 폴더의 .app 번들, Provisioning Profile 및 서명이 포함됩니다. IPA는 macOS에서만 Xcode를 통해 빌드되며, 아카이브(.xcarchive)를 생성하고 IPA를 내보냅니다. App Store를 통한 배포에는 Apple Distribution Certificate로 IPA에 서명하고, Ad Hoc 또는 Enterprise의 경우 해당 인증서로 서명합니다.

컴파일 및 최적화: JIT, AOT, ART, Bitcode

JIT vs AOT

JIT(Just-In-Time) — 애플리케이션 실행 중 코드 컴파일로, 빌드 및 게시 속도에 영향을 미칩니다. Android 5.0(Lollipop)까지는 JIT 컴파일과 함께 Dalvik VM이 사용되었습니다. 애플리케이션이 시작될 때마다 DEX 바이트코드가 "즉시" 머신 코드로 변환되었습니다. 단점: 첫 시작 시 속도 저하 및 추가 전력 소비. AOT(Ahead-Of-Time) — 애플리케이션 시작 전, 설치 중 코드 컴파일. Android 7.0(Nougat)부터 ART(Android Runtime)가 설치 중에 애플리케이션을 완전히 컴파일합니다.

ART(Android Runtime) — Android 5.0에서 Dalvik을 대체한 런타임 환경입니다. ART는 하이브리드 방식을 사용합니다: 설치 중 AOT 컴파일 + 자주 실행되는 메서드에 대한 JIT. 이는 AOT의 속도(빠른 시작)와 JIT의 유연성(적응형 최적화)을 결합합니다. 결과: Dalvik과 비교하여 Android 애플리케이션 성능이 20-30% 향상되었습니다. 개발자의 경우 ART로의 전환은 투명하며 코드 변경이 필요하지 않습니다.

Bitcode 및 App Thinning

Bitcode — Apple이 다양한 프로세서 아키텍처에 대해 IPA를 다시 컴파일하는 데 사용하는 중간 코드 표현(IR)입니다. Bitcode는 선택 사항입니다. iOS 애플리케이션의 경우 기본적으로 활성화되어 있으며, watchOS 및 tvOS의 경우 필수입니다. Apple은 새 프로세서가 출시될 때 개발자의 참여 없이 Bitcode를 다시 컴파일할 수 있습니다. App Thinning — Apple의 기술로, Slicing(기기에 필요한 리소스만 전송) 및 On-Demand Resources(필요에 따라 리소스 로드)를 포함합니다. App Thinning은 App Store의 다운로드 크기를 30-50% 줄입니다.

DEX — Android용 바이트코드 형식으로, ART/Dalvik에 의해 실행됩니다. Kotlin/Java 소스 코드는 class 파일로 컴파일된 다음 dx 또는 d8(최신 고속 도구)을 통해 DEX로 변환됩니다. Multidex — 단일 DEX 파일의 65,536개 메서드 제한을 초과하는 애플리케이션을 위한 메커니즘입니다. 최신 프로젝트에서는 targetSdkVersion >= 21인 경우 multidex가 자동으로 활성화됩니다.

코드 서명: Code Signing, Keystore, Provisioning Profile

Android: Keystore

Keystore — 빌드 중 Android 애플리케이션에 서명하기 위한 개인 키와 인증서가 포함된 파일입니다. Keystore는 keytool(-genkey 명령) 또는 Android Studio를 통해 생성됩니다. 중요: Keystore를 분실하면 Google Play에서 애플리케이션을 업데이트할 수 없습니다. 서명 매개변수: keyAlias, keyPassword, storePassword 및 storeFile. 형식: JKS(Java KeyStore) 또는 AAB의 경우 PEPK(Play Encrypted Private Key).

App Bundle ID(Android) — 패키지 표기법(com.example.app)의 고유 애플리케이션 식별자. Version Code — 내부 버전 번호 매기기를 위한 정수(새 빌드마다 증가). Version Name — 사용자에게 표시되는 문자열(1.2.3). 이러한 매개변수는 앱 수준 build.gradle에서 설정됩니다.

iOS: Apple Certificate 및 Provisioning Profile

Apple Certificate — 개발자 신원을 확인하는 디지털 인증서입니다. 유형: Development(디버깅용), Distribution(App Store용), Ad Hoc(제한된 배포용). 인증서는 Apple Developer Account에서 생성되어 Keychain에 다운로드됩니다. Provisioning Profile — 인증서, App ID(Bundle Identifier) 및 허용된 기기 목록을 연결하는 파일입니다. Provisioning Profile이 없으면 애플리케이션이 기기에서 실행되지 않습니다.

Bundle ID(iOS) — 고유 애플리케이션 식별자(com.example.app). Build Number — 빌드 번호로, 빌드할 때마다 증가합니다. Marketing Version — 사용자에게 표시되는 버전입니다. 버전 관리: iOS의 경우 매개변수는 Info.plist 및 Project Settings에서 설정됩니다. Android의 경우 build.gradle에서 설정됩니다. IT Sectr에서는 Fastlane을 통해 버전 업데이트를 자동화하여 릴리스 시 인적 오류를 제거합니다.

스토어 게시 프로세스

Google Play Console

Google Play Console — Android 애플리케이션을 게시하기 위한 도구입니다. 프로세스: 개발자 계정 등록($25 일회성), 애플리케이션 생성, 메타데이터 입력(이름, 설명, 스크린샷, 카테고리), AAB 업로드, 가격 및 배포 구성, 검토. Google은 애플리케이션을 자동(바이러스, 정책 준수)으로 그리고 일부 카테고리는 수동으로 확인합니다. 검토는 몇 시간에서 2-3일이 소요됩니다.

App Store Connect

App Store Connect — iOS 애플리케이션을 게시하기 위한 Apple의 플랫폼입니다. 프로세스: Apple 개발자 계정($99/년), App Store Connect에서 애플리케이션 생성, Xcode에서 IPA 준비(Archive → Distribute App → App Store Connect), Transporter 또는 Xcode를 통해 업로드, 메타데이터 입력, 검토 제출. App Review — Apple의 수동 검토는 24시간에서 7일까지 소요될 수 있습니다. 거부의 일반적인 이유: 작동하지 않는 버튼, 불완전한 콘텐츠, 설명 없는 권한 요청.

베타 테스트: TestFlight, Closed/Open Beta

TestFlight (iOS)

TestFlight — iOS 애플리케이션의 베타 테스트를 위한 Apple의 공식 도구입니다. TestFlight는 Internal Testing(이메일로 최대 100명의 테스터, 검토 불필요)과 External Testing(최대 10,000명의 테스터, Apple 검토 필요)을 지원합니다. 빌드는 90일 동안 사용 가능하며, 이후 새 빌드를 업로드해야 합니다. TestFlight는 새 빌드가 업로드되면 테스터의 앱을 자동으로 업데이트합니다.

Internal / Closed / Open Beta (Android)

Internal Testing(Android) — 최대 100명의 테스터, Google 검토 불필요, 빌드 즉시 사용 가능. Closed Beta — 이메일 또는 Google Groups를 통해 최대 1000명의 테스터, 검토 불필요. Open Beta — 공개 링크를 통한 무제한 테스터, Google 검토 필요. Staged Rollout — 업데이트를 받는 사용자 비율을 단계적으로 증가(5% → 20% → 50% → 100%). 가장 안전한 릴리스 방법입니다.

App Thinning(iOS) — 다운로드되는 IPA 크기의 자동 감소: Slicing(기기에 필요한 리소스만), Bitcode(프로세서 최적화), On-Demand Resources(필요 시 다운로드). IT Sectr에서는 iOS 베타 테스트에 TestFlight를, Android에는 Internal Testing을 사용합니다. 이를 통해 대규모 릴리스 전에 문제를 발견할 수 있습니다.