모바일 개발에서 Release: 앱의 기본, 빌드 및 게시

Release 빌드란?

Release는 모든 컴파일러 최적화가 적용되고, 디버그 정보가 제거되며, 리소스가 압축되고, 지적 재산권 보호를 위해 실행 코드가 난독화되는 빌드 구성입니다. Release의 목표는 공식 채널을 통해 배포할 수 있는 가장 빠르고 컴팩트한 바이너리 파일을 얻는 것입니다.

Debug와 달리 Release 빌드에는 디버거 진입점이 없고, 어설션이 비활성화되며, 로깅이 최소화됩니다. 이는 단순한 플래그 전환이 아니라 다른 인증서, 프로비저닝 프로파일 및 패키징 설정을 가진 별도의 빌드 파이프라인입니다. Release 빌드는 컴파일러가 추가 최적화 패스를 수행하기 때문에 더 오래 걸립니다.

iOS의 경우 Release 빌드는 Apple 배포 인증서로 서명되며 App Store Connect에서 검토를 거칩니다. Android의 경우 Release 빌드는 업로드 키로 서명되며 Google Play Console에 업로드할 수 있습니다. 두 플랫폼 모두 디지털 서명이 필요합니다. 서명 없이 빌드된 앱은 사용자 기기에 설치되지 않습니다.

Release와 Debug: 구성 비교

Debug와 Release의 차이점은 컴파일러 플래그부터 .apk 또는 .ipa의 최종 크기까지 모든 수준에서 나타납니다. 이러한 차이점을 이해하는 것은 CI/CD 파이프라인과 Release 빌드에서만 나타나는 회귀를 찾는 데 중요합니다.

컴파일러 플래그

Release에서 컴파일러는 크기 최적화(LLVM의 경우 -Os) 또는 속도 최적화(-O2)를 활성화합니다. 이는 인라인 함수 포함, 데드 코드 제거, 명령어 재정렬 및 적극적인 루프 최적화를 의미합니다. Debug에서는 이러한 모든 단계가 생략되어 코드는 느려지지만 소스 라인과 기계 명령어 간의 완전한 일치가 유지됩니다.

난독화 및 축소

ProGuard/R8(Android)는 클래스, 메서드 및 필드를 짧은 이름(a, b, c)으로 변경하여 리버스 엔지니어링을 어렵게 만들고 DEX 파일 크기를 줄입니다. iOS에서는 동등한 기능이 Strip Symbols 및 Swift Symbolication에서 제공됩니다. 리플렉션이나 XML 레이아웃을 통해 사용되는 클래스에는 keep 규칙을 구성하는 것이 중요합니다. 그렇지 않으면 앱이 시작 시 ClassNotFoundException으로 충돌합니다.

빌드 크기

Release 빌드는 Debug 빌드보다 훨씬 작습니다. 일반적인 비율: Debug 버전은 40~80MB, Release는 15~30MB입니다. 차이는 디버그 심볼(DWARF) 제거, 리소스 압축(aapt2) 및 DEX 난독화 때문입니다. 사용자에게 앱 크기는 설치 전환의 중요한 요소이므로 Release에서 크기 최적화는 필수 관행입니다.

Android의 Release 빌드 프로세스

Gradle은 Release 버전을 빌드하기 위한 내장 태스크(assembleRelease, bundleRelease(AAB용), signingReport)를 제공합니다. 모듈 수준에서 build.gradle의 올바른 구성은 안정적인 CI/CD 빌드의 기초입니다. 일반적인 프로젝트를 예로 들어 주요 단계를 살펴보겠습니다.

build.gradle 구성

buildTypes 블록에서 릴리스 구성을 지정합니다. minification을 활성화하고, shrinkResources를 켜고, proguard 규칙을 설정합니다. signingConfig 블록은 storeFile, storePassword, keyAlias 및 keyPassword를 참조해야 합니다. 이러한 매개변수는 VCS에 저장되어서는 안 됩니다. CI/CD의 경우 환경 변수 또는 Keystore Provisioning Plugin을 사용하세요.

android {
    buildTypes {
        release {
            minifyEnabled true
            shrinkResources true
            proguardFiles getDefaultProguardFile(
                "proguard-android-optimize.txt"
            ), "proguard-rules.pro"
            signingConfig signingConfigs.release
        }
    }
}

AAB 및 APK 빌드

Android App Bundle(AAB)은 Google Play에 게시하기 위한 권장 형식입니다. AAB에는 단일 APK가 아닌 모듈식 리소스 세트가 포함되어 있으며, Google Play가 특정 기기에 최적화된 APK를 동적으로 생성합니다. ./gradlew bundleRelease 명령은 AAB를 빌드하고, ./gradlew assembleRelease는 업로드 전 테스트용 범용 APK를 빌드합니다.

서명 및 검증

서명된 APK/AAB는 apksigner verify를 통해 검증됩니다. Google Play Console은 업로드 시 자동으로 서명을 확인합니다. Android 9(API 28)부터 Google은 v2 또는 v3 서명 체계를 요구합니다. Wear OS 및 Android TV의 경우 회전 키가 있는 v3.1이 추가로 필요합니다.

iOS의 Release 빌드 프로세스

Xcode는 Archive 구성에서 Release 버전을 빌드합니다. 이는 단순한 빌드가 아니라 최적화된 컴파일, .xcarchive로 패키징, 배포 인증서 서명, .ipa로 내보내기의 완전한 파이프라인입니다. 프로세스는 Product → Archive 또는 xcodebuild 명령을 통해 시작됩니다.

빌드 스킴 구성

Edit Scheme → Run → Build Configuration에서 최종 테스트를 위해 Release를 선택합니다. App Store Connect에 제출하려면 Product 메뉴에서 Archive를 사용합니다. Xcode는 바이너리 파일, dSYM 및 리소스 번들이 포함된 .xcarchive를 생성합니다. 아카이브에서 Ad Hoc, Development 또는 App Store 배포용 .ipa가 내보내집니다.

App Store Connect 및 TestFlight

TestFlight는 App Store 배포 인증서로 서명된 Release 빌드를 수락합니다. App Store에 제출하기 전에 빌드는 Xcode에서 자동 검증을 거칩니다. 인증서 적합성, 모든 크기의 아이콘, Info.plist의 정확성, 바이너리 파일의 시뮬레이터 아키텍처 부재 여부가 확인됩니다.

# xcodebuild를 통한 Release 빌드
xcodebuild archive \
  -project MyApp.xcodeproj \
  -scheme "MyApp" \
  -configuration "Release" \
  -archivePath "build/MyApp.xcarchive"

# App Store용 .ipa 내보내기
xcodebuild -exportArchive \
  -archivePath "build/MyApp.xcarchive" \
  -exportPath "build/" \
  -exportOptionsPlist "export.plist"

Bitcode 및 App Thinning

App Thinning은 다운로드되는 앱의 크기를 줄이는 Apple의 기술입니다. App Store에 업로드할 때 Apple은 사용자의 특정 기기에 맞게 바이너리 파일을 다시 컴파일하고 사용되지 않는 아키텍처를 제거합니다. Bitcode(LLVM 중간 표현)는 프로젝트가 iOS 14+ 및 Xcode 12+를 사용하는 경우 Release 빌드에 포함됩니다.

Release 준비 시 일반적인 오류

Release 빌드 구성 오류는 세 가지 범주로 나뉩니다. 컴파일 문제, 서명 문제 및 최적화 후에만 나타나는 논리적 오류입니다. Debug에서 Release로 전환할 때 개발자가 직면하는 가장 일반적인 시나리오를 살펴보겠습니다.

난독화 후 ClassNotFoundException

Android에서 가장 일반적인 오류는 minifyEnabled를 활성화한 후 시작 시 충돌입니다. 원인: R8이 리플렉션을 통해 사용되는 클래스(예: Gson 직렬화, data class가 있는 Retrofit @Body)의 이름을 변경했습니다. 해결책은 직렬화에 관련된 모든 클래스에 -keep 규칙을 추가하고 빌드 전에 proguard 규칙을 확인하는 것입니다.

심볼리케이션을 위한 dSYM 부족

iOS에서 개발자는 Archive 후 dSYM 파일을 저장하는 것을 자주 잊습니다. dSYM이 없으면 App Store Connect의 크래시 로그가 읽을 수 있는 함수 이름 대신 16진수 주소로 전달됩니다. 해결책은 .ipa와 함께 dSYM을 보관하고 App Store Connect에 업로드하도록 CI/CD를 구성하는 것입니다.

프로비저닝 프로파일 문제

만료된 배포 인증서 또는 프로비저닝 프로파일의 잘못된 App ID는 App Store Connect가 빌드를 거부하는 이유입니다. 인증서는 1년(Apple) 또는 3년(Google) 동안 유효하며, 갱신을 릴리스 일정에 포함시켜야 합니다. 각 Release 빌드 전에 인증서 상태를 확인하는 것은 CI/CD 파이프라인의 필수 단계입니다.

SDK 버전 및 배포 대상 비호환성

Debug에서 Release로 전환할 때 일반적인 문제는 대상 OS 버전에서 사용할 수 없는 API 사용입니다. Debug에서는 최신 버전의 시뮬레이터에서 빌드가 테스트되므로 모든 새로운 API를 사용할 수 있습니다. Release에서는 앱이 다양한 OS 버전의 사용자 기기에 설치되며, 사용할 수 없는 API를 호출하면 시작 시 충돌이 발생합니다. @available(Swift) 또는 compileSdkVersion + minSdkVersion(Android)을 사용하여 최소 버전을 명시적으로 지정하세요.

누락된 지역화 및 다양한 구성을 위한 리소스

Debug 빌드에서는 리소스가 구성 확인 없이 소스 디렉토리에서 로드되는 경우가 많습니다. Release에서는 Gradle과 Xcode가 리소스 필터링을 적용합니다. 대상 로케일에서 문자열이나 drawable을 찾을 수 없으면 앱이 충돌하거나 플레이스홀더를 표시합니다. 이는 Android에서 특히 중요합니다. values-XX에 번역이 없으면 XML 파싱 시 ClassCastException이 발생합니다. Release 빌드 전에 lint 및 xcodebuild -showBuildSettings로 모든 로케일을 확인하세요. 이러한 문제를 감지하려면 공개 릴리스 전에 TestFlight 및 Internal Testing 트랙을 사용하세요. 실제 기기에서 다양한 언어 설정으로 실행됩니다.