React Native 배포 가이드

React Native 배포 가이드

첫 배포의 여정, 그 중요성과 도전 과제

React Native를 이용해 멋진 모바일 애플리케이션을 개발하는 것은 흥미로운 여정입니다. 사용자 인터페이스를 구축하고, 데이터를 처리하며, 복잡한 로직을 구현하는 개발 과정은 분명 즐겁지만, 애플리케이션의 진정한 가치는 사용자의 손 안에서 비로소 실현됩니다. 개발된 앱이 세상 밖으로 나아가 사용자를 만나기 위해서는 반드시 '빌드'와 '배포'라는 과정을 거쳐야 합니다. 이 과정은 단순한 코드 작성을 넘어선, 애플리케이션 생명주기의 핵심 단계입니다.

많은 React Native 개발자들이 첫 번째 배포 과정에서 예상치 못한 어려움에 직면합니다. 개발 환경에서의 시뮬레이터/에뮬레이터 실행은 비교적 매끄럽지만, 실제 스토어에 올릴 실행 가능한 번들(bundle)을 만들고, 이를 승인받아 배포하는 과정은 전혀 다른 차원의 도전입니다. 서명(Signing) 문제, 빌드 환경 설정 오류, 네이티브 코드와의 연동 문제, 그리고 각 스토어의 복잡한 등록 절차까지, 개발자를 괴롭히는 수많은 장애물이 존재합니다.

이 글은 React Native 애플리케이션을 성공적으로 빌드하고 배포하는 과정을 심층적으로 다루고자 합니다. 특히, React Native 개발자들이 주로 사용하는 두 가지 접근 방식인 'Expo'와 'React Native CLI'를 이용한 빌드 및 배포 전략을 비교 분석하고, 실제 앱 스토어(Apple App Store)와 Google Play 스토어에 게시하는 구체적인 절차를 안내할 것입니다. 이 글을 통해 독자 여러분이 React Native 앱의 첫 배포를 성공적으로 완수하고, 나아가 안정적인 배포 파이프라인을 구축하는 데 필요한 실무 지식과 통찰을 얻으시기를 바랍니다.

---

React Native 앱 빌드 및 배포 심층 분석

React Native 애플리케이션의 빌드와 배포 과정은 개발 단계와는 근본적으로 다릅니다. 개발 단계에서는 주로 JavaScript 코드를 번들링하여 시뮬레이터나 에뮬레이터에서 빠르게 실행하며 디버깅합니다. 하지만 React Native 빌드와 배포 단계에서는 애플리케이션을 최종 사용자에게 제공할 수 있는 독립적인 실행 파일(iOS의 경우 .ipa, Android의 경우 .aab 또는 .apk) 형태로 패키징해야 합니다. 이 과정에는 단순한 JavaScript 번들링뿐만 아니라, 네이티브 코드 컴파일, 리소스 패키징, 그리고 가장 중요한 '서명(Signing)' 과정이 포함됩니다.

빌드와 배포, 왜 다른가? 개념 이해

개발 중에는 react-native run-ios 또는 react-native run-android 명령어를 사용합니다. 이 명령어는 개발 서버를 띄우고, JavaScript 코드를 번들링하여 시뮬레이터/에뮬레이터에 배포합니다. 이때 생성되는 빌드는 디버그(Debug) 빌드이며, 개발 도구와의 연동, 성능 측정 오버헤드 등이 포함되어 있습니다. 이는 실제 사용자가 사용하는 배포용 앱과는 다릅니다.

배포용 빌드 (Release Build)는 다음과 같은 특징을 가집니다.

1. JavaScript 번들링 최적화: 코드가 압축되고 난독화되어 크기가 줄어들고 성능이 향상됩니다. 디버깅 정보나 개발 도구 관련 코드가 제외됩니다.
2. 네이티브 코드 컴파일: iOS (Swift/Objective-C) 및 Android (Kotlin/Java) 네이티브 코드가 컴파일되어 바이너리 형태로 포함됩니다. 서드파티 네이티브 라이브러리도 함께 컴파일됩니다.
3. 리소스 패키징: 이미지, 폰트 등 앱에 필요한 모든 리소스가 패키지에 포함됩니다.
4. 서명 (Signing): 앱의 제작자가 누구인지, 앱이 변조되지 않았음을 보증하기 위해 디지털 서명이 추가됩니다. 이 서명 없이는 앱 스토어나 Google Play 스토어에 앱을 게시하거나 기기에 설치할 수 없습니다.
5. 최종 패키지 생성: iOS의 경우 .ipa 파일, Android의 경우 .aab (Android App Bundle) 또는 .apk 파일 형태로 최종 빌드 결과물이 생성됩니다.

이렇게 생성된 배포용 빌드를 사용자에게 제공하는 과정이 '배포'입니다. 대부분의 경우 앱 스토어와 Google Play 스토어를 통해 배포가 이루어지며, 이 과정에는 스토어 개발자 계정 등록, 앱 정보 입력, 빌드 파일 업로드, 심사 제출 및 통과 등의 절차가 포함됩니다.

가장 빠르게 배포하기: Expo 워크플로우

Expo는 React Native 개발을 위한 강력한 도구 세트이자 프레임워크입니다. Expo는 React Native 앱의 빌드 및 배포 과정을 크게 단순화하여 개발자가 네이티브 환경 설정에 신경 쓰지 않고 JavaScript 개발에 집중할 수 있도록 돕습니다. 특히 초기 단계나 네이티브 코드를 깊게 다룰 필요가 없는 앱의 경우 Expo를 이용한 간단한 배포는 매우 효율적인 방법입니다.

Expo 워크플로우의 장점:

• 단순함: 네이티브 빌드 환경(Xcode, Android Studio) 설정 및 관리가 필요 없습니다. Expo 서버에서 빌드 과정을 대행합니다.
• 빠른 시작: 개발 서버, 푸시 알림 설정, 자산 관리 등 다양한 기능이 미리 구성되어 있어 개발 초기 속도가 빠릅니다.
• OTA 업데이트: 앱 스토어 재심사 없이 JavaScript 코드 및 에셋 업데이트가 가능합니다 (Over-the-Air updates).
• 간편한 빌드: eas build 명령어를 통해 iOS와 Android 빌드 파일을 쉽게 생성할 수 있습니다.

Expo 워크플로우의 단점:

• 네이티브 모듈 제한: Expo SDK에 포함되지 않은 네이티브 라이브러리나 코드를 직접 사용할 수 없습니다. (최근 expo-dev-client나 expo prebuild 등을 통해 어느 정도 해결 가능하지만, 순수 Expo 관리형 워크플로우에서는 제한적입니다.)
• Expo SDK 의존성: 앱의 기능이 Expo SDK 버전에 의존적입니다.
• 빌드 시간: Expo 클라우드 빌드 서버의 상태에 따라 빌드 시간이 달라질 수 있습니다.

Expo를 이용한 배포 과정 (EAS Build 활용):

최신 Expo에서는 expo build 대신 EAS Build (Expo Application Services Build) 를 권장합니다. EAS Build는 더 유연하고 강력한 클라우드 빌드 서비스입니다.

• EAS CLI 설치 및 로그인:Expo 계정으로 로그인하여 빌드 서비스를 이용할 준비를 합니다.

npm install -g eas-cli
eas login

• 프로젝트 설정 (선택 사항):
  프로젝트 루트에 eas.json 파일을 생성하여 빌드 프로파일을 설정할 수 있습니다. 예를 들어, 프로덕션 빌드 설정을 정의합니다.

{
  "build": {
    "production": {
      "ios": {
        "resourceClass": "m1-medium", // 더 빠른 빌드를 위한 옵션
        "distribution": "app-store"
      },
      "android": {
        "resourceClass": "medium",
        "buildType": "apk" // 또는 "app-bundle" (권장)
      }
    }
  },
  "submit": {
    "production": {
      "ios": {
        "appleId": "your-apple-id@example.com",
        "ascAppId": "your-app-store-connect-app-id", // App Store Connect 앱 ID
        "teamId": "your-apple-developer-team-id"
      },
      "android": {
        "serviceAccountKeyPath": "./google-play-key.json", // Google Play 서비스 계정 키 경로
        "track": "production"
      }
    }
  }
}

• 빌드 실행:
  프로젝트 루트에서 다음 명령어를 실행합니다.--profile 옵션으로 eas.json에 정의된 빌드 프로파일을 선택할 수 있습니다 (기본값은 production). 빌드가 시작되면 Expo 클라우드 서버로 코드가 업로드되고 빌드가 진행됩니다. 빌드 진행 상황은 터미널 또는 Expo 웹사이트의 빌드 대시보드에서 확인할 수 있습니다.

 # iOS 빌드
eas build -p ios --profile production

# Android 빌드 (AAB 권장)
eas build -p android --profile production

• 서명 설정:
  EAS Build는 서명 과정도 관리해 줍니다. 처음 빌드하는 경우 서명 설정을 안내합니다. Expo에서 서명 정보를 관리하도록 할 수도 있고 (Managed Signing), 직접 생성한 인증서와 키스토어를 업로드하여 사용할 수도 있습니다 (Manual Signing). 프로덕션 앱의 경우 일반적으로 Manual Signing이 더 안전하거나 선호될 수 있습니다. 서명 설정이 완료되면 이후 빌드에서는 이 정보를 재사용합니다.
• 빌드 결과물 다운로드:
  빌드가 완료되면 터미널 또는 웹 대시보드에 생성된 .ipa (iOS) 파일 및 .aab (Android) 파일의 다운로드 링크가 제공됩니다. 이 파일들을 다운로드하여 각 앱 스토어에 제출할 수 있습니다.

OTA 업데이트 (EAS Update):

EAS Update를 사용하면 앱 스토어 심사 없이 JavaScript 및 에셋 변경 사항을 사용자에게 즉시 배포할 수 있습니다.

1. 업데이트 채널 설정: eas.json 등에 업데이트 채널을 설정합니다 (예: production, staging).
2. 업데이트 발행:

   eas update --branch production --message "JS code update for feature X"

   이 명령어는 현재 프로젝트의 JavaScript 번들을 Expo 서버에 업로드하고, 지정된 브랜치(채널)를 구독하는 앱에 업데이트를 푸시합니다. 앱은 다음에 실행되거나 백그라운드에서 업데이트를 감지하여 적용합니다. 이는 버그 수정이나 UI 변경 등 네이티브 코드를 건드리지 않는 업데이트에 매우 유용합니다.

Expo 워크플로우는 빠르고 간편하게 첫 React Native 빌드와 배포를 경험하고 싶은 개발자에게 훌륭한 선택입니다. 네이티브 환경 설정의 복잡성을 회피하고 핵심 기능 개발에 집중할 수 있게 해줍니다.

완전한 제어: React Native CLI 워크플로우

React Native CLI (Command Line Interface)를 사용하여 프로젝트를 생성하고 개발하는 방식은 네이티브 코드에 대한 완전한 제어권을 가질 수 있다는 장점이 있습니다. 이는 Expo SDK에 포함되지 않은 특정 네이티브 라이브러리나 디바이스 기능을 사용해야 하는 복잡한 앱에 적합합니다. 하지만 그만큼 빌드 및 배포 과정이 복잡해지며, 각 플랫폼의 네이티브 개발 환경(Xcode, Android Studio)에 대한 이해가 필요합니다. 이것이 바로 React Native CLI를 이용한 iOS 및 Android 앱 빌드 과정의 핵심입니다.

React Native CLI 워크플로우의 장점:

• 완전한 네이티브 제어: 모든 네이티브 기능과 라이브러리를 자유롭게 사용할 수 있습니다.
• 유연성: 프로젝트 구조나 빌드 설정을 세밀하게 커스터마이즈할 수 있습니다.
• 네이티브 에코시스템 접근: 각 플랫폼의 표준 빌드 도구와 CI/CD 파이프라인에 통합하기 용이합니다.

React Native CLI 워크플로우의 단점:

• 복잡성: 네이티브 빌드 환경 설정, 서명 관리, 종속성 문제 해결 등 신경 쓸 부분이 많습니다.
• 환경 종속적: iOS 빌드는 macOS 환경에서만 가능합니다. Android 빌드는 Java, Android SDK 등이 필요합니다.
• 수동적인 업데이트: Expo의 OTA 업데이트와 같은 기능을 기본적으로 제공하지 않습니다 (CodePush 등 별도 라이브러리 필요).
• 높은 학습 곡선: 네이티브 개발 환경과 도구에 대한 이해가 필요합니다.

React Native CLI를 이용한 Android 앱 빌드 (AAB 권장):

Google Play 스토어는 2021년 8월부터 신규 앱 제출 시 APK 대신 AAB(Android App Bundle) 사용을 의무화했습니다. AAB는 사용자 기기에 설치될 때 Google Play가 해당 기기에 최적화된 APK를 생성하여 제공하므로 앱 크기를 줄일 수 있습니다.

• 빌드 환경 설정:
  • JDK (Java Development Kit) 설치 및 환경 변수 설정
  • Android Studio 설치 및 Android SDK, SDK Tools 등 필요 구성 요소 설치
  • ANDROID_HOME 환경 변수 설정 및 PATH에 platform-tools 디렉토리 추가
• 서명 키 생성:
  앱을 Google Play에 업로드하려면 앱에 서명해야 합니다. 서명 키는 Java keytool 명령어를 사용하여 생성합니다.이 명령어를 실행하면 비밀번호, 이름, 조직 등 정보를 입력하라는 메시지가 나옵니다. 입력한 비밀번호와 alias를 기억해야 합니다. 생성된 my-upload-key.keystore 파일은 안전한 곳에 보관해야 합니다. 이 키가 유실되면 더 이상 같은 키로 앱 업데이트에 서명할 수 없어 치명적인 문제가 발생합니다 (Google Play App Signing 사용 시 복구 가능성은 있으나 복잡합니다).

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

• 프로젝트 설정: android/gradle.properties 파일에 서명 정보를 추가합니다. 보안을 위해 환경 변수를 사용하거나 별도 파일에 저장하는 것이 좋습니다.

MYAPP_UPLOAD_STORE_FILE=my-upload-key.keystore
MYAPP_UPLOAD_KEY_ALIAS=my-key-alias
# 비밀번호는 환경 변수로 관리하는 것이 안전합니다.
# MYAPP_UPLOAD_STORE_PASSWORD=저장소비밀번호
# MYAPP_UPLOAD_KEY_PASSWORD=키비밀번호

• android/app/build.gradle 파일을 수정하여 릴리즈 빌드 시 서명 정보를 사용하도록 설정합니다. android 블록 안에 signingConfigs와 buildTypes 블록을 추가/수정합니다.

android {
  ...
  signingConfigs {
      release {
          if (project.hasProperty('MYAPP_UPLOAD_STORE_FILE')) {
              storeFile file(MYAPP_UPLOAD_STORE_FILE)
              storePassword System.getenv("MYAPP_UPLOAD_STORE_PASSWORD") // 환경 변수 사용
              keyAlias MYAPP_UPLOAD_KEY_ALIAS
              keyPassword System.getenv("MYAPP_UPLOAD_KEY_PASSWORD")   // 환경 변수 사용
          }
      }
  }
  buildTypes {
      release {
          ...
          signingConfig signingConfigs.release
          minifyEnabled true // 코드 축소 활성화 (선택 사항이지만 권장)
          proguardFiles getDefaultProguardFile('proguard-android.txt'), 'proguard-rules.pro'
      }
  }
}

• AAB 빌드 실행:
  프로젝트 루트 디렉토리에서 다음 명령어를 실행합니다.

cd android
# 환경 변수로 비밀번호 설정 (예시: macOS/Linux)
# export MYAPP_UPLOAD_STORE_PASSWORD=저장소비밀번호
# export MYAPP_UPLOAD_KEY_PASSWORD=키비밀번호
./gradlew bundleRelease

• 명령어 실행이 성공하면 android/app/build/outputs/bundle/release/app-release.aab 경로에 AAB 파일이 생성됩니다.

React Native CLI를 이용한 iOS 앱 빌드 (Requires macOS & Xcode):

iOS 앱 빌드는 Android보다 복잡하며, Apple 개발자 계정(유료)과 macOS 환경이 필수적입니다. Xcode를 통해 빌드 및 아카이브 생성을 진행합니다.

1. 빌드 환경 설정:
   • macOS 최신 버전 및 Xcode 설치
   • Xcode Command Line Tools 설치
   • Cocoapods 설치 (sudo gem install cocoapods)
   • Apple 개발자 프로그램 등록 (Annual Fee 필요)
2. 인증서, 식별자, 프로파일 설정 (Apple Developer Website):
   앱을 빌드하고 배포하기 위해 Apple Developer 웹사이트에서 다음 항목을 설정해야 합니다.
   • Certificates (인증서): 앱 스토어 배포를 위한 'App Store and Ad Hoc' 타입의 Production 인증서 (.p12 파일 포함)
   • Identifiers (식별자): 앱의 고유 식별자 (Bundle ID) 등록 (예: com.yourcompany.yourapp)
   • Profiles (프로파일): 특정 앱 ID, 인증서, 테스트 기기를 연결하는 Provisioning Profile 생성. 배포용으로는 'App Store' 타입의 Distribution Provisioning Profile이 필요합니다. 이 프로파일을 다운로드하여 Xcode에 설치합니다.
3. Xcode 프로젝트 설정:
   • ios/yourAppName.xcworkspace 파일을 Xcode로 엽니다. (Cocoapods 사용 시 .xcworkspace를 열어야 합니다)
   • 프로젝트 네비게이터에서 최상위 프로젝트를 선택하고 'Signing & Capabilities' 탭으로 이동합니다.
   • 'Team'을 자신의 Apple 개발자 팀으로 설정합니다.
   • 'Bundle Identifier'가 Apple Developer 웹사이트에 등록한 식별자와 일치하는지 확인합니다.
   • 자동 서명 관리(Automatically manage signing)를 사용하거나, 수동으로 다운로드한 Provisioning Profile을 선택합니다. 자동 서명 관리가 첫 배포 시에는 더 편리할 수 있습니다.
4. 아카이브 빌드:
   • Xcode 상단 툴바에서 빌드 대상을 실제 기기(Any iOS Device)로 선택합니다. (시뮬레이터는 배포용 아카이브를 만들 수 없습니다)
   • 메뉴 바에서 Product > Scheme > Edit Scheme... 선택.
   • 왼쪽 목록에서 Archive 선택.
   • 'Build Configuration'이 'Release'로 설정되어 있는지 확인합니다.
   • 메뉴 바에서 Product > Archive를 선택하여 아카이브 빌드를 시작합니다.
   • 빌드 성공 시 Organizer 창에 아카이브가 나타납니다.
5. 아카이브 내보내기 (.ipa):
   • Organizer 창에서 생성된 아카이브를 선택합니다.
   • Distribute App 버튼을 클릭합니다.
   • 배포 방식으로 App Store Connect를 선택합니다 (앱 스토어 업로드).
   • 'Upload' 또는 'Export'를 선택합니다. 앱 스토어에 바로 업로드하려면 'Upload'를, .ipa 파일로 로컬에 저장하려면 'Export'를 선택합니다. 첫 배포 시에는 로컬에 .ipa로 내보내서 Transporter 앱 등으로 업로드하는 것이 문제를 디버깅하기 편리할 수 있습니다.
   • 이후 Xcode의 안내에 따라 서명 설정 등을 확인하고 .ipa 파일을 생성합니다.

React Native CLI 워크플로우는 설정할 부분이 많고 각 플랫폼의 네이티브 생태계에 대한 이해가 필요하지만, 앱의 모든 측면을 완벽하게 제어할 수 있다는 강력한 장점이 있습니다. 복잡한 네이티브 기능을 사용하는 앱을 개발하거나, 커스텀 빌드 설정을 해야 하는 경우 필수적인 선택입니다.

앱 스토어 및 Google Play 스토어 게시 절차

빌드된 .ipa 또는 .aab 파일을 가지고 있다면 이제 이 파일들을 각 스토어에 업로드하고 게시하는 절차를 거쳐야 합니다. 이 과정은 기술적인 빌드만큼이나 중요하며, 스토어 정책과 사용자 경험에 대한 이해가 필요합니다.

Google Play 스토어 게시 절차:

1. Google Play 개발자 계정 등록:
   Google Play Console 웹사이트에서 개발자 계정을 등록하고($25 일회성 등록비 발생), 본인 확인 절차를 완료합니다.
2. 앱 만들기 및 스토어 등록 정보 입력:
   • Google Play Console에 로그인하여 '모든 앱' > '앱 만들기'를 클릭합니다.
   • 앱 이름, 기본 언어 등을 입력합니다.
   • 대시보드에서 앱 등록 정보를 단계별로 입력합니다. 여기에는 개인 정보처리방침, 앱 접근성, 광고 포함 여부, 콘텐츠 등급, 타겟 고객층, 뉴스 앱 여부, 방역/추적 앱 여부, 금융 기능 여부 등이 포함됩니다. 모든 필수 항목을 완료해야 합니다.
3. 앱 정보 입력 (스토어 등록정보):
   • 스토어 등록정보 메뉴에서 앱 이름, 짧은 설명, 자세한 설명, 그래픽 요소(앱 아이콘, 스크린샷, 기능 그래픽, 프로모션 동영상 등), 언어 및 번역 등을 입력합니다. 고품질의 스크린샷과 매력적인 설명은 사용자의 다운로드 결정에 큰 영향을 미칩니다.
4. AAB 파일 업로드 및 출시:
   • '출시' > '프로덕션' (또는 테스트 트랙)으로 이동하여 '새 버전 만들기'를 클릭합니다.
   • 앱 무결성 설정 (앱 서명) 화면에서 'Google Play 앱 서명 사용'을 선택합니다. 이는 보안을 강화하고 향후 서명 키 분실 시 복구를 용이하게 합니다. 업로드 키를 등록하고, Google Play가 배포에 사용할 배포 키를 관리하도록 합니다.
   • 준비된 app-release.aab 파일을 업로드합니다.
   • 업로드가 완료되면 버전 코드, 크기 등 정보가 표시됩니다. Release Notes (새로운 기능, 변경 사항)를 작성합니다.
   • 테스트 트랙(내부 테스트, 비공개 테스트, 공개 테스트)에서 먼저 앱을 테스트한 후 프로덕션 트랙으로 출시하는 것을 권장합니다.
5. 출시 검토 및 배포:
   • 모든 설정이 완료되면 '버전 검토'를 클릭합니다.
   • Google Play에서 정책 위반 여부 등을 검토합니다. 검토 시간은 앱의 복잡성이나 제출량에 따라 달라질 수 있습니다 (보통 몇 시간~며칠 소요).
   • 검토가 완료되면 상태가 '출시 준비 완료' 등으로 변경되며, 이때 '프로덕션에 출시' 버튼을 클릭하여 실제 사용자에게 앱을 배포할 수 있습니다. 점진적인 출시(Gradual rollout) 기능을 사용하여 특정 비율의 사용자에게만 먼저 배포하고 문제가 없는지 확인하는 것도 좋은 전략입니다.

Apple App Store 게시 절차:

iOS 앱을 앱 스토어에 게시하려면 Apple 개발자 프로그램에 등록해야 하며, 연간 $99의 비용이 발생합니다.

1. Apple 개발자 프로그램 등록:
   Apple Developer 웹사이트에서 개인 또는 조직으로 등록합니다.
2. App Store Connect 설정:
   App Store Connect는 iOS 앱의 관리, 배포, 판매 및 분석을 위한 웹 기반 도구입니다.
   • App Store Connect에 로그인하여 '나의 앱' > '+' 버튼 > '새 앱'을 클릭합니다.
   • 플랫폼(iOS), 앱 이름, 기본 언어, 번들 ID(Apple Developer 웹사이트에 등록한 것과 일치해야 함), SKU(내부 관리용 고유 식별자) 등을 입력합니다. 번들 ID는 한 번 생성하면 변경할 수 없습니다.
3. 앱 정보 입력:
   • 앱 페이지에서 '앱 정보' 섹션으로 이동하여 앱 스토어 표시 이름, 개인 정보처리방침 URL, 카테고리 등을 설정합니다.
   • '가격 및 판매 지역' 섹션에서 앱 가격과 판매할 국가/지역을 설정합니다.
4. 빌드 업로드:
   Xcode의 Organizer 창에서 아카이브를 생성하고 'Distribute App' 시 'App Store Connect' > 'Upload'를 선택하여 직접 업로드하거나, Xcode 없이 Transporter 앱을 사용하여 미리 내보내기한 .ipa 파일을 업로드할 수 있습니다.
5. TestFlight 설정 (선택 사항이지만 권장):
   TestFlight는 앱 스토어 심사 전에 내부 테스터나 외부 테스터에게 앱을 배포하여 피드백을 받을 수 있는 서비스입니다. App Store Connect에서 업로드된 빌드를 선택하고 TestFlight 탭에서 내부 또는 외부 테스터 그룹을 생성하여 빌드를 배포할 수 있습니다. 외부 테스터에게 배포하려면 첫 빌드 제출 시 제한된 심사(Beta App Review)를 거쳐야 합니다.
6. 앱 스토어 버전 정보 입력:
   • App Store Connect의 앱 페이지에서 'App Store' 탭으로 이동합니다.
   • 새로운 버전 (+)를 클릭하여 새 버전을 생성합니다 (예: 1.0.0).
   • 새 버전 페이지에서 빌드를 선택합니다. 업로드된 빌드가 처리가 완료되면 목록에 나타납니다.
   • 버전 정보, 스크린샷, 앱 미리보기, 설명, 키워드(검색 최적화 중요), 지원 URL, 마케팅 URL 등을 입력합니다.
   • 앱 심사 정보 (데모 계정 정보 등) 및 연락처 정보를 제공합니다.
   • 자동 출시 여부(심사 통과 즉시 출시 vs. 수동 출시)를 선택합니다.
7. 심사 제출:
   모든 정보 입력과 빌드 선택이 완료되면 '심사를 위해 제출' 버튼이 활성화됩니다. 버튼을 클릭하여 앱을 Apple의 앱 심사팀에 제출합니다. 심사 시간은 앱의 복잡성이나 시점에 따라 달라지며, 보통 24시간~7일 정도 소요됩니다. 심사 중 거절당할 경우 사유와 함께 피드백이 제공되며, 해당 부분을 수정한 후 다시 제출해야 합니다.
8. 출시:
   심사를 통과하면 상태가 변경됩니다. 자동 출시를 선택했다면 즉시 앱 스토어에 게시되며, 수동 출시를 선택했다면 원하는 시점에 직접 '출시' 버튼을 눌러 게시할 수 있습니다.

앱 스토어 및 Google Play 게시 시 공통 고려 사항:

• 메타데이터 품질: 앱 이름, 설명, 키워드, 스크린샷 등은 사용자의 첫인상과 앱 검색 노출에 매우 중요합니다. 각 스토어의 가이드라인을 참고하여 매력적으로 작성해야 합니다.
• 개인 정보처리방침: 대부분의 앱은 사용자 데이터를 수집하므로 개인 정보처리방침 URL을 제공해야 합니다.
• 앱 미리보기 및 스크린샷: 앱의 주요 기능을 잘 보여주는 고품질의 스크린샷과 짧은 비디오는 전환율을 높이는 데 도움이 됩니다.
• 테스트: 배포용 빌드는 개발 빌드와 다를 수 있으므로, 실제 기기에서 배포용 빌드를 충분히 테스트해야 합니다. TestFlight나 Google Play의 테스트 트랙을 적극 활용하세요.
• 콘텐츠 등급: 앱의 콘텐츠에 맞는 정확한 등급을 지정해야 합니다.

빌드 및 배포 파이프라인 자동화 (CI/CD 맛보기)

수동으로 앱을 빌드하고 스토어에 업로드하는 과정은 시간이 많이 소요되고 오류 발생 가능성이 높습니다. 특히 팀 단위 개발 환경에서는 이러한 과정을 자동화하는 것이 효율성과 안정성 측면에서 필수적입니다. 빌드 및 배포 파이프라인 자동화는 CI/CD (Continuous Integration/Continuous Deployment) 개념을 활용하는 것입니다.

자동화의 이점:

• 일관성: 항상 동일한 환경과 절차로 빌드가 수행되어 '내 로컬에서는 되는데...' 문제를 줄입니다.
• 시간 절약: 수동 빌드 및 업로드에 소요되는 시간을 단축하여 개발 생산성을 높입니다.
• 오류 조기 발견: 자동화된 테스트(유닛 테스트, 통합 테스트 등)를 빌드 파이프라인에 포함하여 문제를 더 빨리 발견할 수 있습니다.
• 빈번한 배포: 자동화를 통해 잦은 업데이트 및 배포가 용이해집니다.

React Native 빌드/배포 자동화 도구:

• EAS Build: Expo 관리형 프로젝트나 네이티브 코드(Bare workflow)를 사용하는 프로젝트 모두 EAS Build를 CI/CD의 일부로 사용할 수 있습니다. eas build 명령어는 클라우드에서 실행되며, 웹훅(Webhook) 등을 통해 다른 CI 서비스와 연동할 수도 있습니다. EAS Submit 기능을 통해 스토어 업로드까지 자동화할 수 있습니다.
• GitHub Actions, GitLab CI, Jenkins, CircleCI, Bitrise 등: 다양한 CI/CD 플랫폼을 사용하여 React Native 빌드 파이프라인을 구축할 수 있습니다.

기본적인 CI/CD 워크플로우 예시:

1. 코드 푸시 (Code Push): 개발자가 코드 변경 사항을 Git 저장소(예: GitHub, GitLab)에 푸시합니다.
2. CI 트리거: 푸시 이벤트가 발생하면 CI/CD 서버가 자동으로 트리거됩니다.
3. 환경 설정: CI 서버에 React Native 빌드 환경(Node.js, Yarn/npm, JDK, Android SDK, Xcode 등)을 설정하거나 미리 구성된 환경을 사용합니다.
4. 의존성 설치: 프로젝트 종속성(npm/yarn packages, Pods)을 설치합니다.
5. 코드 검사 및 테스트: 린트(Lint), 정적 분석, 유닛 테스트, 통합 테스트 등을 실행합니다.
6. 빌드: 테스트가 통과하면 배포용 빌드(AAB, IPA)를 생성합니다. 이 단계에서 서명 과정이 포함됩니다. 서명에 필요한 키 파일이나 비밀번호는 CI/CD 환경의 Secure Variables 기능을 이용하여 안전하게 관리해야 합니다.
7. 아티팩트 저장: 생성된 AAB/IPA 파일을 CI/CD 시스템의 아티팩트 저장소에 저장합니다.
8. (선택 사항) 배포: 아티팩트가 성공적으로 생성되면 설정에 따라 TestFlight, 내부 테스트 트랙 또는 프로덕션 스토어로 자동 배포를 진행할 수 있습니다. EAS Submit, Fastlane 등 도구를 활용하여 스토어 자동 업로드를 구현합니다.

CI/CD 파이프라인 구축은 초기 설정에 시간과 노력이 필요하지만, 장기적으로는 개발 생산성과 배포 안정성을 크게 향상시키는 투자입니다. 특히 잦은 업데이트가 필요한 서비스나 대규모 팀 프로젝트에서는 필수적인 고려 사항입니다.

---

성공적인 React Native 배포를 위한 제언

React Native 애플리케이션의 첫 배포는 개발 과정의 중요한 이정표입니다. 이 과정을 성공적으로 완수하는 것은 앱이 사용자에게 도달하고 실제 가치를 창출하는 첫걸음입니다. 우리는 이 글을 통해 React Native 빌드 및 배포의 기본 개념부터 시작하여, Expo와 React Native CLI라는 두 가지 주요 워크플로우의 특징과 구체적인 빌드 절차, 그리고 앱 스토어와 Google Play 스토어에 게시하는 상세한 과정을 살펴보았습니다.

핵심 요약:

• 빌드와 배포의 차이점: 개발 중의 디버그 빌드와 달리 배포용 빌드는 네이티브 컴파일, 자바스크립트 최적화, 리소스 패키징, 그리고 가장 중요한 서명 과정을 포함합니다.
• Expo의 강점: 네이티브 환경 설정 없이 빠르게 빌드하고 OTA 업데이트를 활용할 수 있어 초기 개발 및 단순 앱 배포에 용이합니다. EAS Build/Update를 통해 간편한 클라우드 기반 빌드 및 업데이트가 가능합니다.
• React Native CLI의 강점: 네이티브 코드에 대한 완전한 제어권을 제공하여 복잡한 기능 구현에 유리하지만, 빌드 환경 설정 및 서명 관리가 복잡하며 각 플랫폼의 네이티브 도구에 대한 이해가 필요합니다.
• 스토어 게시: 각 스토어(App Store, Google Play)는 고유의 개발자 계정, 앱 정보 입력, 빌드 파일 업로드, 심사 절차를 요구합니다. 매력적인 스토어 등록 정보와 철저한 테스트가 성공적인 출시에 중요합니다.
• 자동화의 중요성: CI/CD 파이프라인 구축은 빌드 및 배포 과정을 자동화하여 효율성, 일관성, 안정성을 확보하는 데 필수적입니다.

실무 적용 팁 및 개인적인 조언:

1. 첫 배포는 간단하게: 처음 React Native 앱을 배포한다면, 기능적으로 최소화된 상태에서 배포 과정을 한 번 끝까지 경험해보는 것을 강력히 추천합니다. 복잡한 기능 추가 전에 배포 파이프라인이 제대로 작동하는지 확인하는 것이 중요합니다.
2. 서명 키 관리의 중요성: Android의 키스토어 파일과 비밀번호, iOS의 인증서와 개인 키는 앱 업데이트의 핵심입니다. 이 정보가 유실되면 앱 업데이트가 불가능해지는 치명적인 상황이 발생할 수 있습니다. 안전한 곳에 백업하고, 팀 내에서 안전하게 공유/관리하는 시스템을 구축하세요. Google Play App Signing이나 Apple의 자동 서명 관리를 활용하는 것도 좋은 방법입니다.
3. 릴리즈 빌드 테스트 필수: 개발 환경(Debug 빌드)에서 잘 작동하더라도 릴리즈 빌드에서는 예상치 못한 문제가 발생할 수 있습니다 (예: 코드 축소로 인한 오류, 환경 설정 차이). 실제 기기에 릴리즈 빌드를 설치하여 주요 기능을 철저히 테스트해야 합니다. TestFlight나 Google Play의 내부/공개 테스트 트랙을 적극 활용하세요.
4. 스토어 심사 가이드라인 숙지: 각 스토어는 엄격한 심사 가이드라인을 가지고 있습니다. 앱이 심사에서 거절당하는 주요 원인을 미리 파악하고 대비하는 것이 재작업 시간을 줄이는 길입니다. 개인 정보처리방침 명시, 기능 설명 명확화, 광고 정책 준수 등이 대표적입니다.
5. 점진적인 출시 고려: Google Play의 점진적인 출시나 Apple의 TestFlight 외부 테스트를 통해 소수의 사용자에게 먼저 배포하여 잠재적인 문제를 미리 발견하고 수정하는 것이 전체 사용자에게 미치는 영향을 최소화하는 방법입니다.
6. 자동화는 필수: 첫 배포 이후에는 CI/CD 파이프라인 구축을 계획하세요. 반복적인 수작업은 결국 휴먼 에러와 시간 낭비로 이어집니다. EAS Build/Submit, GitHub Actions, Fastlane 등 다양한 도구를 검토하여 팀에 맞는 자동화 전략을 수립하세요.
7. 업데이트 전략 수립: 앱 배포 후에는 필연적으로 업데이트가 발생합니다. Expo의 OTA 업데이트를 사용할지, 스토어 업데이트만 사용할지, 혹은 CodePush와 같은 서드파티 라이브러리를 사용할지에 대한 전략을 미리 세워두면 효율적인 유지보수가 가능합니다.

향후 전망:

React Native 생태계는 빠르게 발전하고 있으며, 빌드 및 배포 과정 역시 점차 개선되고 자동화되는 추세입니다. EAS와 같은 서비스는 네이티브 환경 설정의 복잡성을 더욱 줄여줄 것이며, CI/CD 도구와의 통합은 더욱 긴밀해질 것입니다. 개발자들은 점차 네이티브 빌드 자체보다는 애플리케이션의 핵심 기능과 사용자 경험 개선에 더 집중할 수 있게 될 것입니다.