Swift·Kotlin 한 줄 없이 만드는 Expo 전용 OTA 업데이트 시스템

1. OTA 업데이트의 동작 원리

React Native/Expo 앱의 로직은 JS 번들 파일입니다. 앱 시작 시 서버에서 새 번들 버전을 확인하고 다운로드해 교체하면 네이티브 코드(Swift/Kotlin) 변경 없이 앱을 업데이트할 수 있습니다. 네이티브 코드 변경이 없는 한 App Store 심사 없이 즉시 반영됩니다. 단, 네이티브 모듈 추가·변경 시에는 앱 스토어 배포가 필요합니다.

핵심 용어

2. Expo 업데이트 프로토콜

Expo 앱은 시작 시 `expo-updates` 모듈이 설정된 업데이트 URL로 HTTP 요청을 보냅니다. 서버는 현재 runtimeVersion과 platform에 맞는 매니페스트(JSON)를 반환합니다. 매니페스트에는 JS 번들 URL, 에셋 URL, 체크섬 등이 포함됩니다. 앱은 번들을 다운로드해 다음 실행 시 적용합니다.

핵심 용어

3. 롤백과 강제 업데이트 전략

업데이트 후 크래시 발생 시 자동 롤백: 연속 크래시 횟수를 카운트해 임계값 초과 시 이전 번들로 복원. 강제 업데이트: 서버에서 `minimumRequiredVersion`을 반환해 오래된 앱 버전을 강제 업데이트 화면으로 이동시킵니다. A/B 테스트: 특정 사용자 그룹에 다른 번들 버전을 제공해 기능을 점진적으로 롤아웃합니다.

핵심 용어

Q1. OTA 업데이트가 앱 스토어 심사를 우회할 수 있는 이유와 한계는 무엇인가요?

힌트

[감점 답변] 정의만 반복하거나 "OTA 업데이트가 앱 스토어 심사를 우회할 수 있는 이유와 한계는 무엇인가요?"에 대해 장단점 없이 단편적으로 답하면 감점 포인트입니다. 면접관은 실무 적용 경험이 부족하다고 판단합니다. [좋은 답변] 앱 스토어 가이드라인은 '네이티브 코드'의 변경을 심사합니다. JS 번들은 앱의 '해석되는 코드'로 기능 변경이 가능합니다. 단, 앱의 핵심 목적을 크게 바꾸거나 새 네이티브 모듈을 추가하는 것은 가이드라인 위반입니다. Apple은 특히 엄격해 OTA로 앱 성격 자체를 바꾸면 계정이 제재될 수 있습니다.

Q2. Expo의 runtimeVersion이 중요한 이유는 무엇인가요?

힌트

[감점 답변] 정의만 반복하거나 "Expo의 runtimeVersion이 중요한 이유는 무엇인가요?"에 대해 장단점 없이 단편적으로 답하면 감점 포인트입니다. 면접관은 실무 적용 경험이 부족하다고 판단합니다. [좋은 답변] runtimeVersion은 JS 번들과 네이티브 바이너리의 호환성을 나타냅니다. 네이티브 모듈을 추가하면 runtimeVersion을 올려야 하는데, 이렇게 하면 이전 버전 앱은 새 번들을 받을 수 없습니다. 네이티브 API가 없는 번들을 구 버전 앱에 배포하면 크래시가 발생하기 때문에 이 버전 관리가 OTA 시스템의 핵심입니다.

Q3. OTA 업데이트 중 앱이 크래시할 경우 어떻게 처리하시겠습니까?

힌트

[감점 답변] 정의만 반복하거나 "OTA 업데이트 중 앱이 크래시할 경우 어떻게 처리하시겠습니까?"에 대해 장단점 없이 단편적으로 답하면 감점 포인트입니다. 면접관은 실무 적용 경험이 부족하다고 판단합니다. [좋은 답변] 방어 전략: (1) 번들 다운로드 완료 후 체크섬 검증, (2) 첫 번째 실행 전 백업 번들 보존, (3) 연속 크래시 횟수 추적(AsyncStorage)으로 임계값 초과 시 이전 번들로 자동 복원, (4) 크래시 리포팅 서비스(Sentry)와 연동해 특정 업데이트 후 크래시율 급등 시 서버에서 강제 롤백.