쇼피파이의 React Native 이탈설, 코드 재사용은 언제 손해가 될까
핵심 요약
- 9월 10일 공개된 유튜브 영상은 제목에서 쇼피파이의 React Native 이탈을 주장했습니다.
- 이 제목만으로 쇼피파이의 공식 결정이나 전체 앱의 전환을 확정할 수는 없습니다.
- React Native로 비용을 얼마나 아낄 수 있는지는 코드 재사용으로 줄인 작업과 플랫폼별 대응에 드는 작업에 달려 있습니다.
- 네이티브로 전환할지 판단할 때는 재개발 비용과 이후 두 플랫폼을 유지할 비용까지 계산해야 합니다.
모바일 앱을 만드는 팀이라면 코드를 공유해 아이폰과 안드로이드 앱을 함께 개발할 수 있다는 말이 반가울 겁니다. 같은 작업을 되풀이할 필요가 줄어드니까요. 쇼피파이의 React Native 이탈설을 접하면 이 대목을 다시 생각하게 됩니다. 공유하는 코드가 많으면 개발비도 그만큼 줄어들까요?
쇼피파이의 복귀설, 어디까지 받아들여야 할까요
2026년 9월 10일, GENZ TECH 채널에 Shopify Ditches React Native, Rebuilds Apps in Swift and Kotlin이라는 영상이 올라왔습니다. 제목은 쇼피파이가 React Native를 버리고 Swift와 Kotlin으로 앱을 다시 만든다고 주장합니다.
다만 영상 제목의 주장만으로 회사가 공식 결정을 내렸다고 보기는 어렵습니다. 전체 앱에 관한 이야기인지, 특정 앱이나 기능에 한정된 선택인지도 제목만 봐서는 알 수 없습니다. 성능 문제나 개발 비용 때문에 그런 결정을 내렸다고 단정할 근거도 되지 않습니다.
코드를 공유할 때 늘 이득을 보는 건 아닙니다. 앱 개발에서 어떤 작업을 줄일 수 있고, 어떤 작업이 더 생기는지 따져봐야 합니다.
코드를 한 번 쓰면 비용도 절반일까요
React Native는 React 방식으로 iOS와 안드로이드 앱을 개발하는 프레임워크입니다. 두 운영체제에서 화면과 로직의 상당 부분을 공유할 수 있습니다. 필요하면 각 운영체제에 맞춘 네이티브 코드도 함께 씁니다.
예를 들어 판매자가 주문 목록을 확인하는 앱을 만든다고 해보겠습니다. 주문을 불러와 상태별로 분류하고 상세 화면을 보여줘야 합니다. 두 운영체제에서 이 흐름이 비슷하다면 함께 쓸 코드가 많습니다. 공통 코드의 오류를 한 번 고쳐 양쪽 앱에 반영할 수도 있습니다.
하지만 구현을 공유해도 검증할 플랫폼은 2개입니다. 아이폰에서 잘 작동하는 화면이 안드로이드에서는 키보드나 뒤로 가기 동작 때문에 어색할 수 있습니다. 운영체제별로 테스트하고 수정하는 일까지 없어지지는 않습니다.
저는 재사용률보다 변경 한 건을 끝내는 비용을 더 중요하게 봅니다. 코드를 얼마나 공유했는지만으로는 충분하지 않습니다. 기능 하나를 만들어 두 앱에 안정적으로 배포하기까지 얼마나 걸렸는지를 봐야 비용을 아꼈는지 알 수 있습니다.
네이티브가 유리해지는 순간
네이티브 개발은 각 운영체제가 제공하는 개발 도구와 API를 직접 쓰는 방식입니다. Swift와 Kotlin은 각각 iOS와 안드로이드 개발에 널리 쓰이는 언어입니다. React Native에서도 네이티브 기능을 연결할 수 있지만, 이를 연결하고 유지하는 데 별도의 작업이 필요할 수 있습니다.
가령 바코드를 스캔하거나 외부 장치를 연동하는 앱이라면 플랫폼 기능에 깊이 의존할 수 있습니다. 복잡한 화면 전환이 필요한 앱도 마찬가지입니다. 이런 기능의 비중이 커지면 공통 코드 외에 운영체제별 구현을 다룰 일이 늘어날 수 있습니다. 쇼피파이의 실제 전환 이유가 그렇다는 뜻은 아닙니다. 기술을 선택할 때 따져볼 수 있는 일반적인 사례입니다.
문제를 해결하는 데도 비용이 듭니다. 오류가 나면 공통 앱 코드에서 비롯됐는지부터 살펴봐야 합니다. 사용 중인 라이브러리나 운영체제별 구현에 원인이 있을 수도 있습니다. 이렇게 여러 곳을 오가며 원인을 찾는 일이 반복되면 코드를 공유해서 아낀 시간이 줄어들 수 있습니다.
다만 네이티브 개발이 얼마나 도움이 될지는 실제로 어디서 문제가 생기는지에 달려 있습니다. 서버 응답이 느린 앱이라면 화면을 구현하는 언어만 바꿔서는 해결하기 어렵습니다. 먼저 앱이 느려지는 지점과 수정에 시간이 많이 드는 지점을 구분해야 합니다.
돌아가는 데도 비용이 듭니다
네이티브로 전환할지 검토할 때는 바꾼 뒤에 얻을 장점만큼 전환 자체의 비용도 따져봐야 합니다. 화면을 다시 만드는 동안에도 기존 앱의 오류를 고쳐야 할 수 있습니다. 로그인과 알림이 제대로 작동하는지 확인하고 접근성도 다시 검증해야 합니다. 눈에 잘 띄지 않는 동작까지 챙겨야 하는 겁니다.
전환한 뒤에는 두 플랫폼의 구현을 각각 유지해야 합니다. 같은 기능을 비슷한 시점에 출시하려면 일정도 맞춰야 합니다. 플랫폼별 경험을 세밀하게 다듬을 여지는 커지지만, 그만큼 인력이 필요하고 일하는 방식도 뒷받침돼야 합니다.
따라서 손익을 계산할 때는 적어도 다음 항목을 넣어야 합니다.
- 공통 기능을 공유해서 줄인 구현·수정 시간
- 플랫폼별 예외 처리와 연동에 추가로 쓴 시간
- 실제 기기에서 측정한 성능과 오류 발생 수준
- 재개발에 드는 비용과 전환 이후의 유지 비용
앱 전체를 다시 작성하기 전에 문제가 집중된 기능을 네이티브로 구현하는 방법도 검토할 수 있습니다. 어느 쪽이 유리할지는 앱에 어떤 기능이 있는지, 팀이 어떤 경험을 쌓았는지에 따라 달라집니다.
쇼피파이의 이탈설을 기술 선택의 근거로 삼으려면 실제 전환 범위와 이유를 확인해야 합니다. 우리 팀의 손익계산서는 지금도 점검할 수 있습니다. 공통 코드를 고치는 데 드는 시간과 운영체제별 차이를 해결하는 데 드는 시간을 비교해보면, 현재 방식에서 어느 쪽에 비용이 더 드는지 알 수 있습니다.
댓글
댓글을 불러오는 중...