플러터(Flutter)와 리액트 네이티브(RN)를 두고 깊은 고민을 했습니다. 개인적으로 플러터로 앱을 개발해 출시를 준비하고 있지만, 회사의 상황은 또 다릅니다.
현재 회사의 앱은 WebView Shell 역할만 하고 있으며, 사실상 화면 없이 백엔드 로직만 수행하는 형태입니다.
도입 배경과 문제점
앞으로 네이티브 UI가 적용된 페이지들이 추가될 예정인데, 이렇게 되면 빈번한 배포가 필연적입니다. 따라서 앱 심사 과정을 최대한 줄이는 것이 핵심 과제가 되었습니다.
이런 문제를 가장 잘 해결할 수 있는 솔루션은 사실상 React Native 기반의 Expo 밖에 없다는 결론에 도달했습니다. 그래서 회사의 앱을 리액트 네이티브로 개발한다고 가정하고, 개발부터 배포, 운영까지의 과정을 미리 시뮬레이션해 보았습니다.
1. 개발 생산성: Shadcn UI의 경험을 그대로
개발 측면에서는 이미 우리 팀이 프론트엔드 개발에 도입하여 잘 사용 중인 Shadcn UI와 유사한 방식을 찾았습니다.
- React Native Reusables: Shadcn의 철학을 그대로 React Native로 옮겨놓은 라이브러리입니다.
이 라이브러리를 활용하면 웹 프론트엔드 개발 경험을 살려 화면을 빠르게 구축할 수 있을 것으로 판단했습니다.
2. 배포 및 운영 전략: EAS 비용 절감
Expo의 가장 강력한 무기인 OTA (Over-The-Air) 업데이트를 통해 마켓 심사 없이 신규 기능을 배포할 수 있는지 검토했습니다. 보통은 EAS (Expo Application Service) Cloud를 사용하지만, 비용이 만만치 않았습니다.
현재 상황: 회사는 비용 절감을 위해 AWS에서 운영 중인 서비스들을 모두 IDC(온프레미스) 로 이전하고 있습니다. 따라서 값비싼 EAS Cloud 비용은 부담이 될 수밖에 없습니다.
대안: 자체 구축 배포 파이프라인
결론적으로 EAS Cloud 없이도 충분히 운영 가능하다는 계산이 섰습니다.Run EAS Build locally with local flag
- 빌드 서버: 사무실에 Mac Mini 한 대를 두고 Jenkins를 세팅합니다.
- 배포 프로세스:
- Jenkins에서 빌드된 파일(JS 번들 등)을 IDC 서버 또는 S3로 전송합니다.
- 프론트 서버의 Nginx를 통해 정적 파일들을 서빙합니다.
- CloudFront와 연동하여 글로벌 배포 속도를 확보합니다.
이 방식은 현재 우리가 Next.js의 정적(static) 파일들을 S3에 업로드하고 CloudFront로 서빙하는 방식과 거의 동일합니다. 따라서 추가적인 인프라 비용 없이, 기존 운영 노하우를 그대로 적용하여 효율적인 운영이 가능할 것으로 보입니다.