How to incrementally adopt Expo

 

 

How to incrementally adopt Expo

https://expo.dev/blog/how-to-incrementally-adopt-expo

 

기존 React Native 프로젝트에 Expo를 점진적으로 도입하는 방법

 

Expo 도입은 모든 기능을 한꺼번에 적용해야 하는 방식이 아닙니다. 필요한 기능을 선택해서 사용할 수 있는 a la carte 메뉴와 같습니다. 프로젝트에서 가장 필요한 기능들만 골라서 사용할 수 있습니다.

 

제가 React Native 개발자들과 이야기할 때 자주 받는 질문 중 하나는 다음과 같습니다. "우리 앱은 5년 이상 되었고, 꽤 복잡합니다. 처음에는 Expo 없이 시작했는데, 이제 보니 Expo의 여러 훌륭한 기능을 놓치고 있는 것 같습니다. 하지만 이 시점에서 마이그레이션을 시도하는 것이 너무 벅차게 느껴집니다. Expo로의 마이그레이션을 어떻게 시작해야 할까요?"

 

저는 이 질문에 답하는 것을 즐깁니다. 단지 Expo 도구에 대해 이야기할 수 있어서가 아닙니다. 새로운 기능 개발, 버그 수정, 성능 개선 등 여러 작업을 동시에 처리하는 바쁜 개발자들에게 이 전환이 한 번에 모두 해야 하는 '빅뱅' 방식일 필요는 없다는 것을 안심시킬 수 있어서입니다. 데스몬드 투투의 말을 빌리자면, 코끼리를 한 입에 다 먹을 필요는 없다는 것이죠.

 

Expo 도구는 팀에 가장 중요한 기능들을 목표로 점진적으로 도입할 수 있습니다. 이를 통해 몇 개의 풀 리퀘스트만으로도 큰 변화 없이 프로젝트 방향을 조금씩 전환해 나갈 수 있습니다.

 

Taking inventory: 어떤 Expo 기능이 당신에게 가장 중요한가요?

첫 번째 단계는 "Expo 앱"에 대한 오해를 풀어주는 데서 시작됩니다. 많은 사람들은 npx create-expo-app을 통해 생성된 앱, 즉 개발 빌드, 지속적인 네이티브 생성, EAS Build, EAS Update와 같은 기능을 모두 포함하는 앱을 Expo 앱이라고 생각합니다. 하지만 실제로는 Expo 앱이란 Expo 도구를 사용하는 앱을 의미합니다.

 

당신의 앱은 오랫동안 운영되어 왔습니다. 그 과정에서 사용자와 개발자의 필요에 맞추어, 자연스럽게 도구와 프로세스(어쩌면, 자체 프레임워크)를 구축해 왔을 것입니다.

이제 도구 체인의 일부를 개선하거나 교체할 기회가 보이기 때문에 Expo 도구를 고려하고 있습니다. 그러나 현재 사용 중인 도구 체인의 일부는 다른 부분보다 더 많은 도움이 필요할 수 있습니다. Expo를 점진적으로 도입할 때는 가장 큰 문제점에 먼저 집중하는 것이 좋습니다.

• Expo CLI와 개발 빌드를 사용하여 로컬 개발 경험을 간소화하고 싶으신가요?
• Expo SDK 패키지인 expo-router나 expo-image와 같은 것을 사용하고 싶으신가요, 아니면 Expo Modules API를 사용해 Kotlin과 Swift로 직접 네이티브 모듈을 작성하고 싶으신가요?
• 업그레이드와 네이티브 코드 유지보수의 복잡성을 Continuous Native Generation을 통해 크게 줄이고 싶으신가요?
• EAS Update를 사용하여 더 자주 프로덕션 업데이트를 배포하고 싶으신가요?
• EAS Update를 사용하여 PR 리뷰 워크플로우를 통해 QA 테스트 속도를 높이고 싶으신가요?
• EAS Build로 전환하여 빌드 인프라를 유지하거나 수동 빌드 스크립트를 관리하는 데 드는 부담을 줄이고 싶으신가요?

당신의 최우선 사항을 염두에 두고, 사용 사례에 가장 중요한 Expo 기능을 구현하는 핵심 경로를 설정할 준비가 되었습니다. 이 경로는 빠르게 성과를 달성하는 데 도움이 되며, 나중에 추가적으로 도입할 수 있는 기능을 위한 기반도 마련해 줄 것입니다.

 

 

Mission: Expo의 점진적인 도입

 

다음으로, Expo 도구를 한 단계씩 추가하는 과정을 살펴보겠습니다. 이를 대략적인 시간과 복잡도에 따라 4단계로 나누었습니다. 중요한 점은, 필요한 사전 작업을 완료하면 앱에 가장 관련성이 높은 다음 단계로 바로 진행할 수 있다는 것입니다.

하지만, 아래 모든 기능을 추가하고자 한다면, 이 순서가 먼저는 작은 코드 변경을 통해 빠르게 이점을 얻을 수 있는 부분을 다루고, 나중에는 구현하는 데 시간이 더 오래 걸릴 수 있지만 가치 있는 변경 사항을 다룬다는 점을 알아두셔야 합니다.

 

Expo의 점진적인 도입은 네 단계로 이루어집니다:

• 사전 작업: 다른 Expo 기능을 사용하기 전에 먼저 해야 할 몇 가지 작업.
• 빠른 성과 (Quick Wins): 패키지 설치와 최소한의 설정만으로 얻을 수 있는 빠른 이점.
• 새로운 워크플로우: 빌드, 테스트, 배포 워크플로우를 크게 개선하는 작은 코드 변경.
• 새로운 사고방식 (New Mindsets): 코드 구조를 재편해 장기적인 유지보수성과 사용성을 개선하는 중요한 리팩터링.

이 단계의 진행 과정을 시각적으로 돕기 위해, 빈 React Native Community CLI(RNC CLI) 앱에서 시작하여 Expo 기능을 하나씩 추가하는 데모 코드 저장소를 제공합니다. 각 단계에 해당하는 풀 리퀘스트를 아래에서 강조하겠습니다.

 

* 사전 작업: Expo 모듈 지원 추가

 

Check out the pull request

 

모든 Expo 앱은 공통적으로 expo 패키지를 설치해야 합니다. 이 패키지는 Expo CLI를 포함하며, npx expo 명령을 사용할 수 있게 해줍니다. 또한 Expo 모듈 간에 공통으로 사용되는 라이브러리와 모듈 자동 연결을 지원하는 코드를 포함하고 있습니다. 이 첫 번째 단계를 완료하면, 개발 빌드, EAS Update, CNG 등 다양한 도구들을 사용할 수 있게 됩니다.

 

많은 앱은 단 한 줄의 명령어로 Expo 모듈 지원을 추가할 수 있습니다.

 

npx install-expo-modules@latest

 

이 명령어를 실행하면 expo 패키지가 설치되고 네이티브 프로젝트 파일에 약간의 변경이 가해집니다. Expo 패키지를 자동 연결하기 위한 변경 사항과, 앱의 생명 주기 이벤트에 Expo 패키지가 연결될 수 있도록 AppDelegate와 MainActivity 파일에도 수정이 이루어집니다. 이를 통해 더 이상 수동으로 해당 파일을 수정할 필요가 없어집니다.

일부 커스텀 네이티브 프로젝트의 경우, 스크립트가 자동으로 작동하지 않을 수 있습니다. 이 경우, 수동 설치 지침을 따를 수 있습니다.

 

어느 방식이든, 이제 당신은 Expo 앱을 가지게 되었고, Expo CLI를 사용해 앱을 개발 모드에서 시작할 수 있습니다.

 

npx expo run:android

 

또는

 

npx expo run:ios

 

 

이제 Expo 도구를 도입하려는 목적에 따라, 이후 단계 중 어느 것이든 바로 진행할 수 있습니다. 사전 요구 사항은 사실상 하나뿐입니다!

 

이후에 더 자세히 설명하겠지만, 간단한 요약을 먼저 드리자면, Expo 앱은 기본적으로 네이티브 코드 폴더가 없는 구조에서 시작하는데, 만약 네이티브 폴더를 가진 상태로 Expo 기능이 적용된 앱을 사용한다면, 이를 이상하게 생각할 수 있습니다. 빌드 직전에 네이티브 코드를 생성하는 프로세스를  Continuous Native Generation(CNG) 이라고 하며, 이는 필수가 아니므로 필요에 따라 나중에 전환할 수 있습니다.

 

* Quick Wins (빠른 성과)

 

다음의 **빠른 성과(Quick Wins)**는 일상적인 개발 경험을 향상시킬 수 있는 작은 코드 변경 사항들이며, 현재의 워크플로우에 최소한의 변경만 요구됩니다.

 

 

Development builds

 

Check out the pull request

 

다른 기능을 이 시점에 구현할 수도 있지만, 몇 가지 이유로 개발 빌드부터 바로 진행할 것을 제안하고 싶습니다.

• 개발자 경험에 빠른 성과를 제공
• 프로덕션 앱에는 영향을 주지 않음

개발 빌드는 Expo Go 스타일의 앱 런처 인터페이스를 디버그 변형에 통합하여, 로컬 개발 환경이나 EAS Update에서 제공하는 모든 JS 번들 URL을 실행할 수 있게 해줍니다.

 

다음 지침을 따라 기존의 React Native 앱에 개발 빌드 지원을 추가하세요. expo-dev-client를 설치하고 디버그 버전을 다시 빌드하세요(예: npx expo run:android 또는 npx expo run:ios). 앞으로는 다음 번에 npx expo start를 실행하는 대신, 같은 빌드를 계속 사용할 수 있습니다. npx expo start는 Metro 번들러만 시작하며, 개발 빌드는 해당 번들러에 연결됩니다.

Android 및 iOS 시뮬레이터에서 이 빌드를 팀원들과 공유할 수 있어, 그들이 앱을 계속해서 빌드할 필요가 없습니다. iOS 기기의 경우, 애드혹 배포를 위해 앱 서명 작업이 필요하며(곧 EAS Build를 통해 이를 어떻게 처리할 수 있는지 설명할 예정입니다). 팀은 네이티브 코드나 구성 파일이 변경될 때만 다시 빌드하고, 대부분의 기능 개발 동안 네이티브 도구와 상호작용하지 않아도 됩니다.

 

Expo SDK 패키지 사용하기

Expo 모듈을 설치한 후에는 모든 Expo SDK 패키지를 사용할 수 있습니다. 예를 들어, expo-image나 expo-video와 같은 자주 사용되는 디바이스 API를 노출하는 패키지를 다른 React Native 패키지처럼 설치하고 사용할 수 있습니다. 또한, Expo Modules API를 사용해 Swift와 Kotlin으로 직접 모듈을 작성하여 JavaScript 기능을 확장할 수도 있습니다. Expo를 사용하여 네이티브 모듈을 만드는 방법을 보여주는 튜토리얼이 제공됩니다.

How to create a native module with the Expo modules API
https://youtu.be/CdaQSlyGik8

 

 

* 새로운 워크플로우

 

앱이 Expo 모듈을 지원하게 되면, EAS Build, EAS Update 또는 둘 다 도입할 수 있습니다. 이러한 변경은 코드 상에서 작은 수정이지만, 빌드, 테스트, 배포 워크플로우에서 큰 변화를 가져오고, 팀의 작업 효율성을 크게 향상시킬 수 있습니다.

 

EAS Build

 

Check out the pull request

 

빌드 파이프라인 유지보수의 부담을 줄이고 빠른 EAS 빌드 워커의 장점을 활용하고 싶다면, Expo 모듈 지원을 추가한 후 언제든지 EAS Build로 전환할 수 있습니다. eas-cli를 설치하고(npm install -g eas-cli), eas build:configure 명령어를 실행하여 시작합니다. 이 명령은 앱에 Expo 프로젝트 ID를 할당하고, eas.json 파일에 기본 빌드 프로필을 설정해줍니다. 이후 필요에 따라 해당 파일을 맞춤 설정할 수 있습니다.

 

비록 이 시점에서 앱이 CNG(Continuous Native Generation) 를 사용하지 않더라도, EAS Build에서 정상적으로 작동합니다. EAS Build가 프로젝트 내의 android 및 ios 폴더를 발견하면, prebuild 단계를 생략하고 현재의 네이티브 코드와 구성을 그대로 유지합니다.

 

EAS 빌드 작업을 로컬 머신이나 CI 하드웨어에서 eas build --local 명령어로 실행할 수 있습니다. EAS Build 작업을 로컬에서 실행하든 클라우드 워커에서 실행하든, EAS 자격 증명 관리를 활용할 수 있습니다. EAS 자격 증명 관리 도구는 Android 키스토어와 iOS 인증서, 프로비저닝 프로필을 자동으로 생성, 저장 및 재사용할 수 있게 도와줍니다.

 

EAS 자격 증명 관리 도구는 iOS 개발 빌드의 애드혹/내부 배포에도 도움을 줄 수 있으며, 팀원 누구나 자신의 기기를 애드혹 배포 프로비저닝 프로필에 추가할 수 있는 링크를 생성해 줍니다. 시작할 때는 EAS Build를 사용하여 개발 빌드만 배포하는 방식을 선택할 수 있으며, 이를 통해 팀원들이 어떻게 앱을 테스트하든 상관없이 효율적인 개발 빌드 환경을 누릴 수 있습니다.

 

EAS Update

 

Check out the pull request

 

EAS Update는 앱의 JavaScript 번들만 업데이트하여 스토어 출시 없이도 작은 버그 수정과 업데이트를 즉시 사용자에게 전달할 수 있게 해줍니다. 일반적으로 비즈니스 로직은 JavaScript나 TypeScript로 작성되고, 네이티브 코드 변경은 장치 API와 OS 수준 기능에 사용됩니다. 비즈니스 로직은 자주 변경되지만 네이티브 코드는 덜 빈번하게 변경되므로, 이 점을 활용해 네이티브 코드를 빌드 및 배포하는 횟수를 줄이고, JS 번들만 자주 업데이트할 수 있습니다.

 

What kind of changes can be pushed with EAS Update

 

EAS Update는 이미 설치된 Expo 모듈 지원을 통해 쉽게 추가할 수 있습니다. 이는 expo-updates 라이브러리를 초기화하여, 다음에 앱을 시작할 때 (또는 useUpdates 훅을 사용하여 더 빠르게) 새로운 JavaScript 버전으로 업데이트할 수 있도록 도와줍니다. eas update:configure 명령어를 실행하면 자동으로 설정이 완료됩니다.

 

프로덕션 업데이트를 위한 EAS Update

 

프로덕션 앱에서 EAS Update를 사용할지 여부는 사용자와 앱의 상호작용 방식, 코드 배포 방식에 따라 달라집니다. 해석된 코드의 업데이트는 앱 스토어에서 허용되지만, 가이드라인을 준수해야 합니다. 모든 상황에 딱 맞는 해결책은 없으므로, 배포 패턴에 대한 권장 사항이 제공됩니다. 프로덕션 배포 모델이 EAS Update에 적합하지 않더라도, 테스트 용도로 사용해보는 것을 고려할 수 있습니다.

 

PR 프리뷰를 사용하여 EAS Update 를 테스트하는 방법

 

프로덕션 앱은 단일 프로덕션 업데이트 채널을 통해 호환되는 업데이트를 다운로드하지만, 개발 빌드는 QR 코드를 스캔해 네이티브 런타임과 호환되는 모든 업데이트를 실행할 수 있습니다. 이를 통해 강력한 QA 시나리오를 구현할 수 있는데, 테스터가 개발 빌드를 사용해 각 변경 사항이나 풀 리퀘스트를 QR 코드로 다운로드해 개별적으로 테스트할 수 있습니다. 이렇게 하면 테스터는 동일한 앱을 사용하여 여러 PR을 독립적으로 테스트할 수 있습니다.

 

PR 프리뷰는 풀 리퀘스트가 생성되거나 업데이트될 때 Github Action을 통해 자동으로 EAS Update를 실행하는 방식으로 작동합니다. 그 후, QR 코드가 PR 스레드에 게시되어 해당 업데이트로 연결됩니다. 이와 유사한 워크플로우는 다른 지속적 통합 시스템에서도 구현할 수 있습니다.

 

* 새로운 사고방식 (New Mindsets)

 

다음 변경 사항들은 이전과 마찬가지로 앱이 Expo 모듈을 지원한 후에 진행할 수 있습니다. 이러한 변경은 코드의 구조화, 유지보수, 업그레이드 및 확장 방식에서 장기적인 이점을 가져다주는 사고방식의 전환을 의미합니다. 상당한 리팩토링이 필요할 수 있으며, 다른 기능을 먼저 도입한 후에 이러한 변경을 고려하거나, 빠른 성과와 병행하여 시작하는 것이 좋습니다.

 

Continuous Native Generation (CNG) 도입

 

Check out the pull request

 

우리는 Continuous Native Generation(CNG) 을 마지막에 다루지만, 이것이 우선순위가 낮아서가 아닙니다. 사실, 많은 사람들이 Expo를 도입할 때 가장 먼저 생각하는 것이 CNG입니다. 다만, 전환 과정에서 조금 더 나중에 도입하는 것이 좋을 수 있는 몇 가지 이유가 있기 때문입니다.

 

CNG(Continuous Native Generation) 을 도입한다는 것은 네이티브 코드 폴더를 소스 관리에서 제거하고, prebuild 명령어를 통해 템플릿, package.json, app.json / app.config.js 및 설정 플러그인에 따라 네이티브 프로젝트 파일을 자동으로 생성하는 것을 의미합니다. 이를 통해 네이티브 프로젝트 전체를 업그레이드할 필요가 없어 유지보수성이 크게 향상됩니다. 네이티브 코드와 구성에서 고유한 부분만 관리하면 됩니다. CNG에 대한 자세한 내용은 여기에서 확인할 수 있습니다.

 

그러나 CNG의 혜택은 매우 크지만, 일반적으로 오랜 시간에 걸쳐 실현됩니다. 다음에 React Native 버전을 업그레이드할 때까지는 CNG의 이점이 크게 느껴지지 않을 수 있으며, 그 시점은 몇 개월 후일 수도 있습니다. 또한, CNG로 전환하는 과정의 복잡성은 현재 네이티브 프로젝트가 기본 설정에서 얼마나 커스터마이징되었는지에 따라 크게 달라집니다.

 

따라서, 몇 가지 변경 사항에 우선순위를 두어야 한다면, CNG를 도입하기 전에 팀에 가장 관련 있는 Expo의 다른 기능들부터 먼저 구현하는 것을 권장합니다. 개발 빌드, Expo Router, EAS Build, EAS Update 등 다른 Expo 도구의 많은 이점을 비교적 짧은 시간 내에 얻을 수 있으며, 이후에 시간을 두고 CNG 전환을 진행할 수 있습니다.

 

CNG로 전환하려면 앱이 기본 네이티브 프로젝트 템플릿에서 어떻게 달라지는지 파악한 후, 그에 맞는 설정을 app.json 또는 app.config.js에 업데이트하여 자동화할 수 있도록 해야 합니다. 때로는 서드파티 패키지의 설정 플러그인을 추가하거나, 직접 설정 플러그인 또는 Expo 모듈을 작성해야 할 수 있습니다. CNG 도입에 대한 사고 과정을 설명한 자료와, 설정 플러그인을 사용해 간단한 커스터마이징을 추가한 예제 프로젝트의 차이점을 확인할 수 있습니다. 여기에는 기본 app.json 필드에 없는 간단한 커스터마이징을 추가하기 위해 설정 플러그인을 사용하는 예제가 포함되어 있습니다.

 

Expo Router

 

Check out the pull request

 

Expo Router는 앱이 Expo 모듈을 지원하게 되면 도입할 수 있습니다. Metro 설정과 진입점을 올바르게 구성하는 몇 가지 지침을 따르면 됩니다. 파일 기반 라우팅은 탐색 계층 구조를 체계적으로 정리하는 데 유용하며, 각 화면은 고유한 URL을 가지게 되어 앱 내의 모든 화면에 대해 자동으로 딥 링크 지원을 활성화할 수 있습니다.

 

앱에 많은 화면이 있는 경우, Expo Router를 도입하면 각 화면을 코드베이스의 새로운 위치로 이동시켜야 하기 때문에 상당한 리팩토링이 필요할 수 있습니다. 따라서, 이 단계를 Expo 도입 여정의 후반에 고려하는 것이 좋습니다. 그러나 Expo Router는 React Navigation을 기반으로 구축되었으므로, 이전에 사용한 내비게이터 기능들은 Expo Router에서 동일하게 구현되어 있습니다.

 

도입 절차를 시작하세요

 

오랫동안 프로덕션에서 사용된 대규모 코드베이스와 앱은 고유한 도전 과제가 있습니다. 지속성과 안정성이 무엇보다 중요하며, 큰 변화는 이러한 안정성을 위협할 수 있고 개발자들에게 부담을 줄 수 있습니다. 우리도 앱 개발자로서, 안정된 개발 환경과 충분한 수면의 중요성을 잘 이해하고 있습니다!

 

그렇기 때문에 Expo 도입을 점진적으로 진행할 수 있도록 설계하였으며, 현재 팀에 가장 도움이 될 기능에 초점을 맞추도록 했습니다. Expo의 워크플로우와 도구는 새로 시작하는 앱에도 유용하지만, 특히 대규모 프로덕션 앱에서 큰 잠재력을 발휘합니다. 이러한 앱들도 자신의 방식에 맞게 Expo의 장점을 활용할 수 있으며, 점진적으로 도입할 수 있습니다!

따라서, Expo로의 마이그레이션은 반드시 모두 적용해야 하는 방식이 아니라, 필요한 기능만 선택해서 도입할 수 있는 a la carte 메뉴와 같습니다. 팀이 기능을 계속 제공하는 동안, 지금 당장 도움이 될 기능을 선택해 도입할 수 있습니다. 더 자세한 정보는 우리의 문서를 확인해 보세요. React Native 앱이 Expo를 점진적으로 도입하는 방법에 대해 자세히 설명되어 있습니다.