앱을 만들려면 원래 iOS와 안드로이드를 따로 만들어야 합니다. 언어도 다르고 도구도 다릅니다. 그런데 React Native를 쓰면 하나의 코드로 둘 다 낼 수 있습니다. 저희가 만든 숏캐시, 툴툴이, 펜슬팜이 모두 이 방식입니다.
실제로 얼마나 줄어드나
“절반”이라고들 하는데, 저희 경험으로는 60~70% 정도가 현실적입니다. 화면과 기능 로직은 대부분 그대로 공유됩니다. 대신 나머지에서 손이 갑니다.
- 푸시 알림 설정은 양쪽이 다릅니다.
- 로그인 연동은 각 플랫폼 설정이 따로 필요합니다.
- 화면 아래 여백, 상단 노치 처리 같은 게 다릅니다.
- 스토어 등록과 심사는 당연히 각각입니다.
그래서 “한 번 만들면 끝”은 아닙니다. 그래도 두 번 만드는 것보다는 확실히 적게 듭니다.
더 큰 이점은 유지보수입니다
만드는 비용보다 고치는 비용에서 차이가 큽니다.
기능 하나를 바꿀 때 코드를 한 번만 고치면 양쪽에 반영됩니다. 앱을 몇 년 굴리다 보면 이 차이가 누적됩니다. 따로 만들었다면 같은 수정을 두 번 하고, 두 곳 다 테스트해야 합니다.
앱은 만드는 기간보다 굴리는 기간이 훨씬 깁니다. 그래서 유지보수 비용이 진짜 비용입니다.
안 맞는 경우도 있습니다
솔직하게 말씀드리면 React Native가 답이 아닌 경우가 있습니다.
- 카메라나 센서를 아주 깊게 다루는 앱
- 그래픽 성능이 서비스의 핵심인 앱 (게임 등)
- 애플이나 구글이 방금 낸 신기능을 바로 써야 하는 앱
이런 경우는 각 플랫폼 언어로 만드는 게 낫습니다. 저희는 상담에서 이런 성격이 보이면 그렇게 말씀드립니다.
화면을 코드로 다시 만들 필요가 없는 경우
웹 서비스가 이미 있다면 다른 선택지도 있습니다. 밥알은 웹으로 만든 서비스를 Capacitor로 감싸서 앱으로 냈습니다. 화면을 앱용으로 새로 만들지 않고, 웹을 그대로 앱 안에 넣는 방식입니다.
이 방법은 훨씬 빠르고 쌉니다. 대신 앱다운 부드러운 움직임은 덜합니다. 서비스 성격에 따라 고르시면 됩니다.
모노레포로 묶기
숏캐시는 앱만 있는 게 아니라 미션 웹, 관리자 페이지, 백엔드, 크롤링 서버까지 함께 굴러갑니다. 이걸 저장소를 나눠서 관리하면 버전이 어긋납니다.
그래서 하나의 저장소에 묶어서 관리합니다. 공통으로 쓰는 타입과 유틸을 한 곳에 두면, API 규격이 바뀌었을 때 어디를 같이 고쳐야 하는지 바로 보입니다.
정리
- 하나의 코드로 두 플랫폼을 냅니다. 60~70% 정도 아낍니다.
- 진짜 이점은 만들 때가 아니라 고칠 때 나옵니다.
- 센서·그래픽이 핵심이면 다른 방식을 권합니다.
- 웹이 이미 있다면 감싸는 방식도 검토할 만합니다.
기술을 고르는 기준은 “요즘 뜨는 것”이 아니라 “이 서비스를 몇 년 굴릴 때 뭐가 싼가”입니다.