Expo로 시작하는 React Native의 맛

• 실시간 영상 처리 및 AI 처리를 위한 Edge Device를 관리하는 앱 개발이 요구사항으로 들어왔다. 일종의 산업용 IoT 앱이었다.
• Edge Device는 LTE 라우터가 내장된 모바일 서버이기 때문에 Rest API로 다룰 수 있었기에 기술적 난이도는 크지 않았다.
• 다만 추후에 Bluetooth 통신을 지원해야 할 수도 있고, 다른 스펙의 Edge Device를 지원한다던지 등 네이티브 수준의 기술이 요구되는 것을 고려해야 했다.

Native App vs Hybrid App

기존에 우리 회사는 다음의 이유로 하이브리드 앱을 선택했었다.

1. 사내에 네이티브 개발 인력이 없다. (대표님이 있지만 온전히 개발에 투입할 수 있는 인력이 아니다.)
2. 소수의 비싼 인력에게 의존해야 하는 네이티브 개발보단 누구나 쉽게 접근 가능한 웹 개발이 더 낫다고 판단했다.
3. 요구되는 기술의 수준이 네이티브 개발을 요구할 만큼 크지 않았다.
4. 빠르게 개발하고 배포하는 문화이기에 업데이트 때마다 심사를 거쳐야 하는 네이티브보다는 웹이 더 낫다고 판단했다.

그러나 이번에는 React Native(RN)를 선택했다. 내가 RN을 선택한 이유는 다음과 같다.

1. 이번 개발 스펙은 웹 브라우저 환경에서는 구현하기 애매한 부분이 있었고, 미래 확장성도 고려해야 했다.
2. RN의 개발 경험이 React Web과 크게 다르지 않아, 기존의 FE 인력을 투입하기에 적합했다.
3. 보다 정교한 앱을 개발 함에 있어서 하이브리드 앱보다 더 완성도 높은 앱을 개발하기 적합했다.
4. JS 번들만 배포하여 앱 심사를 받지 않고 업데이트할 수 있었다.

RN 외에 생각했던 것은 Capacitorjs, Flutter 등이 있었다.

Expo를 선택한 이유

• 기술 스택으로 React Native를 선택했다면 이제 순수 React Native로 개발할지, Expo와 같은 프레임워크를 사용할지 고려해야 한다.
• 필자가 기억하는 RN은 개발 세팅이 좀 복잡했고, 어쨌든 네이티브 API를 딥하게 다루다보면 네이티브 코드를 직접 수정해야 하는 경우가 왕왕있었다.
• 반대로 Expo의 개발 경험은 매우 편리하고 쉽고, 압도적으로 좋았지만 자유도의 문제가 있었다. 네이티브 코드에 접근해야 하는 경우 Expo를 eject해야 했는데 한 번 eject하면 다시는 Expo로 돌아갈 수 없었다.

그렇다면 현재의 Expo는 어떻고, 왜 선택했을까?

1. 현재의 Expo는 방향성을 바꾸어 eject가 사라졌고, expo 자체가 정적 Code Generator같은 형태가 되었다. app.json이라는 설정 파일을 중심으로 마치 vite처럼 네이티브 코드 자체를 빌드해주는 것이다. Expo는 이것을 plugin 방식으로 제공하고 있다.
2. 파일 기반 라우팅(expo-router)을 제공한다. 웹 개발 중에서도 Next.js와 유사한 라우팅 경험을 RN 생태계에도 제공하기 시작한 것이다.
3. EAS라는 빌드 시스템이 상당히 잘 만들어졌다. 자체적으로 클라우드 서비스를 운영하는데 Expo 기반 앱에 대한 배포 자동화를 SaaS 수준으로 제공한다.
4. ExpoGo는 여전히 GOAT다. 네이티브 앱을 개발하면서 HMR(Hot Module Replacement)을 사용할 수 있는 것은 정말 큰 차이다. 심지어 Deveopment Build라는 기술이 새로 생겼는데 빌드하는 앱에 ExpoGo의 미러링 기능을 삽입하여 내 앱이 실시간으로 업데이트되는 것을 보면서 시뮬레이션할 수 있다. (써보면 앎)
5. 자체 생태계가 상당히 잘 구축되어 있다. 이거 있을까? 싶으면 이미 expo 자체 플러그인으로 제공된다. 물론, 기존의 RN 라이브러리들도 당연히 사용할 수 있다. 심지어 expo를 적극 지원하는 라이브러리들의 경우 라이브러리 세팅 자체가 더 쉬운 경우가 많다.