1. Hotwire Native: Rails 개발자의 강력한 무기
모바일 앱 개발 프레임워크를 선택할 때 Rails 개발자에게 가장 효율적인 선택지는 Hotwire Native입니다. 저자는 25개 이상의 앱을 출시하며 얻은 교훈으로, 앱 기능의 80-90%가 표준적인 CRUD(생성, 조회, 수정, 삭제) 작업임을 강조합니다. 이러한 기능들은 네이티브 내비게이션 래퍼 내부에서 서버 렌더링된 HTML로도 충분히 훌륭하게 작동합니다. 네이티브 코드가 반드시 필요한 영역은 푸시 알림, 카메라 접근, 생체 인식, 햅틱 피드백, 인앱 결제와 같이 웹 기술만으로는 구현이 불가능한 기능들로 한정됩니다. 이러한 기능들조차 브릿지 컴포넌트를 통해 몇 줄의 HTML로 제어할 수 있습니다.
2. 네이티브 화면의 함정과 유지보수의 현실
많은 팀이 사용자 경험을 이유로 초기부터 수많은 네이티브 화면을 구축하려 시도하지만, 이는 관리의 악몽으로 이어지기 쉽습니다. 네이티브 화면 하나를 추가할 때마다 Rails의 데이터 모델, API 엔드포인트, 그리고 Swift(iOS)와 Kotlin(Android) 각각의 UI 코드를 모두 유지보수해야 합니다. 즉, 하나의 화면을 위해 세 곳 이상의 코드를 수정해야 하는 상황이 발생합니다. 반면, Hotwire Native를 활용해 네이티브 계층을 얇게 유지하면 소규모 팀으로도 충분히 관리가 가능한 수준의 업무량을 유지할 수 있습니다. 이미 구축된 웹 로직을 재사용하는 것이 생산성의 핵심입니다.
3. React Native 선택 시 고려해야 할 트레이드오프
React Native는 성숙한 생태계와 좋은 개발자 경험을 제공하지만, Rails 기반 팀에게는 예상치 못한 비용을 발생시킵니다. 이미 React 웹 프론트엔드와 견고한 JSON API를 보유한 팀에게는 좋은 선택일 수 있으나, ERB와 Hotwire를 사용하는 일반적인 Rails 팀에게는 완전히 새로운 프론트엔드 스택을 처음부터 구축해야 함을 의미합니다. 특히 React 웹과 React Native는 코드 공유가 거의 불가능하므로, 단순히 언어가 같다는 이유로 선택하기에는 리스크가 큽니다. Rails 팀 입장에서는 차라리 완전 네이티브를 배우는 것이 한 가지 기술만 추가로 익히면 된다는 점에서 더 효율적일 수 있습니다.
4. Apple의 앱 스토어 거절 사유에 대한 오해와 진실
개발자들이 가장 걱정하는 부분 중 하나는 Apple이 웹 뷰 중심의 앱을 거절할 것이라는 우려입니다. 하지만 실제 거절 사유는 기술적 구현 방식보다는 비즈니스 규칙 준수 여부에서 기인합니다. Apple 로그인 제공, 인앱 결제 정책 준수, 계정 삭제 기능 포함, 그리고 앱 스토어에 존재해야 할 명확한 가치 제공 등이 핵심입니다. 단순히 HTML 콘텐츠를 사용한다는 이유로 거절되는 경우는 거의 없으며, 오히려 온보딩 흐름의 혼선이나 스크린샷 불일치, 개인정보 처리방침 링크 오류 등이 더 빈번한 거절 사유가 됩니다. 프레임워크는 Apple에게 중요하지 않습니다.
5. 빠른 출시를 위한 제약 조건과 팀의 역량 강화
가장 빠르게 출시된 프로젝트는 단 7주 만에 앱 스토어에 등록되었습니다. 이 팀은 Xcode를 한 번도 열어보지 않은 두 명의 Rails 개발자로 구성되었으며, 커스텀 네이티브 화면 없이 기존 Rails 뷰와 최소한의 브릿지 컴포넌트만으로 앱을 완성했습니다. 반대로 앱의 모든 화면을 네이티브로 구현하려 했던 팀은 6~8개월이 소요되었습니다. 속도는 제약에서 나옵니다. 최소한의 네이티브 계층으로 시작하여 출시한 뒤, 사용자의 피드백에 따라 점진적으로 네이티브 기능을 강화하는 것이 최선의 전략입니다. Rails 개발자들은 전문적인 모바일 개발자 없이도 충분히 모바일 앱을 출시할 역량을 갖추고 있습니다.