React Native 안내서 · 6/6

배포

React Native 앱을 사용자에게 전달하려면 릴리스 빌드를 만들고, 플랫폼 규칙에 맞게 서명한 뒤, Google Play와 App Store에 제출해야 합니다. 이 장에서는 Expo의 EAS로 하는 방법과 네이티브 도구로 직접 하는 방법, 그리고 OTA 업데이트를 살펴봅니다.

배포 전에 준비할 것

개발자 계정: App Store는 Apple Developer Program(연회비), Google Play는 Play Console 개발자 계정(1회 등록비)이 필요합니다.
앱 식별자: iOS 번들 ID와 Android 패키지 이름은 스토어에 올린 뒤 바꿀 수 없으므로 신중히 정합니다.
버전: 사용자에게 보이는 버전(version)과 빌드마다 올라가는 번호(iOS buildNumber, Android versionCode)를 구분해 관리합니다.

{
  "expo": {
    "version": "1.2.0",
    "ios": { "bundleIdentifier": "com.example.myapp", "buildNumber": "12" },
    "android": { "package": "com.example.myapp", "versionCode": 12 }
  }
}

릴리스 빌드에서는 JavaScript가 미리 번들되어 앱에 들어가고(Hermes 바이트코드), 개발 서버 없이 동작합니다. 스토어에 올리기 전에 반드시 릴리스 빌드를 실기기에서 확인합니다.

EAS Build로 빌드하기

EAS Build는 Expo의 클라우드 빌드 서비스로, Expo 프로젝트와 일반 React Native 프로젝트 모두에서 쓸 수 있습니다. macOS가 없어도 iOS 앱을 빌드할 수 있고, 서명용 키스토어·인증서·프로비저닝 프로필을 만들어 보관해 줍니다.

npm install -g eas-cli
eas login
eas build:configure
eas build --platform android --profile production
eas build --platform ios --profile production

eas build:configure는 빌드 프로필을 담은 eas.json을 만듭니다.

{
  "cli": { "appVersionSource": "remote" },
  "build": {
    "development": { "developmentClient": true, "distribution": "internal" },
    "preview": { "distribution": "internal" },
    "production": { "autoIncrement": true }
  },
  "submit": { "production": {} }
}

development는 개발 빌드, preview는 팀 내부 테스트용, production은 스토어 제출용입니다. autoIncrement는 빌드 번호를 자동으로 올립니다. 인증 정보는 eas credentials로 확인·관리하며, 자신의 컴퓨터에서 빌드하려면 eas build --local을 씁니다.

EAS Submit으로 제출하기

eas submit --platform ios
eas submit --platform android
eas build --platform all --auto-submit

iOS 빌드는 App Store Connect에 올라가 TestFlight 베타 테스트를 거쳐 심사에 제출할 수 있습니다. Android는 Google 서비스 계정 키가 필요하며, Google Play 정책상 첫 업로드는 Play Console에서 직접 해야 합니다. Google Play에는 APK가 아닌 AAB(Android App Bundle)를 올립니다.

네이티브 도구로 직접 빌드하기

EAS 없이 Community CLI 프로젝트를 배포할 때는 플랫폼 도구를 직접 씁니다. Android는 업로드 키를 만들고 Gradle에 서명 설정을 넣습니다.

keytool -genkeypair -v -storetype PKCS12 -keystore my-upload-key.keystore -alias my-key-alias -keyalg RSA -keysize 2048 -validity 10000

// android/app/build.gradle
android {
    signingConfigs {
        release {
            storeFile file(MYAPP_UPLOAD_STORE_FILE)
            storePassword MYAPP_UPLOAD_STORE_PASSWORD
            keyAlias MYAPP_UPLOAD_KEY_ALIAS
            keyPassword MYAPP_UPLOAD_KEY_PASSWORD
        }
    }
    buildTypes {
        release {
            signingConfig signingConfigs.release
        }
    }
}

MYAPP_UPLOAD_... 값은 저장소에 커밋하지 않는 ~/.gradle/gradle.properties에 두고, 키스토어 파일은 안전하게 백업합니다. 그다음 android 폴더에서 ./gradlew bundleRelease를 실행하면 android/app/build/outputs/bundle/release/app-release.aab가 만들어집니다. Play App Signing을 쓰면 Google이 최종 배포 키를 관리합니다.

iOS는 Xcode에서 Release 구성으로 Product > Archive를 실행하고, Organizer에서 App Store Connect로 업로드합니다. 서명에는 Apple Developer 계정의 배포 인증서와 프로비저닝 프로필이 필요합니다.

OTA 업데이트

JavaScript와 이미지 같은 에셋만 바뀌었다면 스토어 심사 없이 앱에 업데이트를 내려보낼 수 있습니다. Expo에서는 expo-updates와 EAS Update를 씁니다.

npx expo install expo-updates
eas update:configure
eas update --channel production --message "로그인 화면 문구 수정"

앱은 다음 실행 때 같은 채널의 새 업데이트를 받아 적용합니다. 네이티브 코드나 네이티브 설정이 바뀌면 새 빌드를 스토어에 올려야 하며, 런타임 버전(runtimeVersion)이 맞는 빌드에만 업데이트가 전달됩니다. 업데이트도 앱 스토어 정책을 따라야 하므로 앱의 주요 목적을 바꾸는 변경은 심사를 거칩니다.

정리

배포 전에 개발자 계정, 번들 ID·패키지 이름, 버전과 빌드 번호를 준비합니다.
EAS Build·Submit을 쓰면 서명 관리와 스토어 제출을 명령 몇 개로 처리할 수 있습니다.
직접 배포한다면 Android는 업로드 키와 bundleRelease, iOS는 Xcode Archive를 씁니다.
JavaScript만 바뀐 수정은 EAS Update로 빠르게 내보낼 수 있습니다.

공식 문서:

이 장에 대해 질문이 있나요?