Shopify가 2020년부터 밀어온 React Native 전략을 접고 모바일 앱을 Swift와 Kotlin으로 다시 짓는다. 프레임워크의 성능 실패가 직접적인 이유는 아니다. 같은 기능을 iOS와 Android에서 두 번 구현해야 한다는 비용을 코딩 에이전트가 크게 낮췄고, 그 결과 코드 공유보다 각 플랫폼에 가까이 붙는 편이 유리해졌다는 계산이다. HN 토론도 ‘AI가 cross-platform과 native 사이의 손익분기점을 어디까지 옮겼는가’를 집중적으로 파고들었다.

Shopify Engineering이 공개한 설명에 따르면 React Native 도입은 성공적이었다. 기능을 한 번 개발하고, 웹 개발자가 모바일 작업에 참여하며, 두 플랫폼의 기능 격차를 줄이는 효과를 얻었다. 다만 프레임워크 업데이트, 외부 의존성, 성능 최적화에 계속 자원이 필요했다. 2025년 말부터 모델이 한 플랫폼의 구현을 참고해 다른 플랫폼 코드를 만들고 테스트와 검토까지 맡을 수준에 이르자, 기존 선택의 전제가 달라졌다.

첫 결과물은 Shop 앱이다. 팀은 개념 검증에서 앱스토어 배포까지 12주 만에 native 재구축을 마쳤다. 300개가 넘는 화면과 위젯, Apple Watch 앱, Siri Shortcuts를 품은 Shopify 앱도 2026년 안에 새 버전을 내놓을 계획이다. 회사는 점진적으로 일부 화면만 옮기는 brownfield 방식 대신, 기존 React Native 앱을 참조해 처음부터 만드는 greenfield 방식을 택했다.

속도만 믿고 모델에 전체 변환을 맡기지는 않았다. Shopify가 만든 Helix는 화면 하나를 작은 checkpoint로 나눈 뒤 각 단계에서 동작 테스트, 실행 화면의 시각 검토, 두 차례의 적대적 코드 리뷰, 사람의 승인을 요구한다. 검사를 통과하지 못하면 다음 단계로 갈 수 없다. 비즈니스 로직은 UI와 분리해 데스크톱에서 headless로 실행하고, 에이전트가 CLI로 상태 확인과 조작을 빠르게 반복하도록 앱 구조도 바꾼다.

오픈소스 후속 조치도 구체적이다. React Native Skia는 2026년 말까지 후원한 뒤 개발자가 새 이름으로 fork하고 기존 저장소를 보관 처리한다. 주당 약 200만 회 내려받는 FlashList는 당분간 호환성 문제를 고치면서 장기 관리 주체를 찾는다. Restyle은 2026년 말까지 작동 상태를 유지한 뒤 관리가 끝난다. React Native 자체가 사라진다는 뜻은 아니지만, Shopify 내부의 기본 선택에서는 native에 자리를 내주는 셈이다.

커뮤니티 반응은 이 결정을 모든 팀의 정답으로 일반화하는 데 신중했다. 작은 조직에는 여전히 하나의 코드베이스가 유효하고, 두 native 코드베이스는 토큰과 검토 비용을 함께 늘린다는 지적이 나왔다. 결국 달라진 것은 프레임워크의 절대 평가가 아니라 인력, 제품 규모, 에이전트 검증 체계를 포함한 비용 함수다. Shopify의 사례는 코딩 모델이 단순 생산성 도구를 넘어 기술 스택 선택의 전제까지 바꾸기 시작했다는 실증 사례에 가깝다.

#react-native

Shopify, React Native에서 Swift·Kotlin으로 회귀…코딩 에이전트가 뒤집은 비용 계산