Shopify는 2026년 9월 10일 모바일 앱의 중심 기술을 React Native에서 Swift와 Kotlin으로 다시 옮기겠다고 밝혔다. 2020년에는 iOS와 Android에 같은 기능을 따로 만들지 않는 이점 때문에 React Native를 선택했다. 이번에는 코딩 에이전트가 구현, 두 플랫폼 사이의 번역, 테스트, 코드 검토를 맡으면서 그 이점의 비용 절감 효과가 작아졌다고 판단했다.
이 소식은 네이티브가 항상 낫다는 결론이 아니다. Shopify가 다시 계산한 것은 언어의 우열이 아니라, 기능 하나를 두 번 만드는 비용과 플랫폼에 더 가까이 붙는 이점의 합계다. 모바일 팀이 AI 도구를 도입했다면 기존의 크로스플랫폼 선택 기준도 같은 방식으로 다시 계산할 수 있다.
두 번 만드는 일이 다시 결정적 비용이 된 이유
React Native는 한 코드베이스로 iOS와 Android의 기능 격차를 줄이고, 모바일 경험이 적은 개발자도 기여하기 쉽게 만들었다. Shopify는 이 구조를 유지하기 위해 성능 최적화, 프레임워크 업데이트, 외부 의존성 관리에 시간과 자원을 썼지만 당시에는 이익이 더 컸다고 적었다.
바뀐 전제는 에이전트의 역할이다. Shopify는 2021년부터 LLM을 기능 구현, 버그 조사와 수정, 코드 리뷰에 활용했고, 2025년 말에는 여러 핵심 앱의 일부를 Swift와 Kotlin으로 다시 만드는 실험을 했다. iOS 구현을 참고해 Android 기능을 만들고 그 반대도 수행했으며, 공통 명세, 테스트, 검토 체크포인트로 플랫폼 간 일치 비용을 낮췄다. 네이티브 앱이 두 개의 소프트웨어를 유지해야 한다는 사실은 그대로다. 구현과 검증의 반복 비용이 2020년과 달라졌다는 것이 전환의 근거다.
마이그레이션은 왜 점진 교체가 아니라 재구축인가
대형 앱을 옮길 때는 기존 코드에 네이티브 화면을 조금씩 섞는 브라운필드 방식이 흔하다. Shopify도 이전 React Native 전환 때는 수년이 걸릴 재작성 기간에 새 기능 배포가 멈추는 일을 피하려고 이 방법을 썼다. 이번에는 새로 만드는 그린필드 방식을 택했다. 기존 제약 없이 구조를 다시 잡을 수 있고, React Native 구현을 참조한 에이전트가 Swift와 Kotlin 기능을 만들 수 있으며, 내부 실험에서 재구축 속도가 충분히 나왔기 때문이다.
첫 대상인 Shop 앱은 개념 검증부터 앱스토어에 올린 완전한 네이티브 앱까지 12주가 걸렸다. 300개가 넘는 화면과 홈·잠금 화면 위젯, Apple Watch 앱, Siri Shortcuts 등을 가진 Shopify 앱도 이전 작업 중이며 연내 출시 계획이다. 이 기간은 Shop 앱 한 사례이며, 다른 앱과 조직에 그대로 대입할 수 있는 생산성 지표는 아니다. 대신 팀이 재구축과 점진 교체를 비교할 때, 기능 수뿐 아니라 기존 제약을 걷어내는 가치와 검증 능력을 함께 봐야 한다는 사례다.
에이전트가 만든 코드를 어떻게 통과시키나
Shopify는 React Native 코드를 한 번에 네이티브로 바꾸라는 지시가 배포할 수 없는 코드 더미를 만든다고 썼다. 그래서 Helix라는 내부 시스템에서 화면 하나를 짧은 체크포인트로 나눈다. 각 단계는 테스트로 동작을 증명하고, 실행 중인 앱과 시각적으로 대조하며, 두 명의 적대적 코드 검토를 거치고, 사람이 승인해야 다음 단계로 넘어간다. 검토 결과는 다음 반복에 남는다.
여기서 더 중요한 설계는 UI 밖에서 검증할 수 있는 구조다. Shopify는 비즈니스 로직을 UI와 완전히 분리해 데스크톱에서 헤드리스로 실행하고, 에이전트가 CLI로 상태를 읽고 기능을 반복하도록 만들고 있다. 화면을 접근성 트리나 스크린샷으로 읽고 조작하면 코드 수정은 몇 초여도 테스트는 몇 분 걸릴 수 있다. CLI에서 밀리초 단위로 검증할 수 있어야 에이전트가 사람의 지속적인 조작 없이 긴 작업을 수행할 수 있다는 설명이다.
기술 선택표에 무엇을 새로 넣어야 하나
크로스플랫폼 프레임워크를 쓰는 팀은 당장 네이티브 전환을 검토할 이유가 생긴 것은 아니다. 이미 안정적으로 운영되는 앱이라면 전환 자체가 큰 비용이다. 다만 다음 의사결정 때는 공유 코드 비율만 세지 말고, 에이전트가 두 구현 사이에서 실제로 줄이는 작업을 측정할 수 있다. 기능 하나의 구현, 플랫폼별 테스트, 리뷰, 버그 수정에 각각 얼마가 드는지와 OS 기능·공식 도구에 가까이 붙어 얻는 이익을 같은 표에 둔다.
그 표에서 빠지기 쉬운 항목은 피드백 시간이다. 에이전트가 시뮬레이터를 조작하며 몇 분씩 기다리는 구조라면 모델의 코딩 속도는 큰 효과를 내기 어렵다. UI와 독립적으로 실행할 수 있는 로직, 재현 가능한 CLI 명령, 단계별 통과 기준을 먼저 갖춘 팀이 기술 선택의 전제를 더 정확히 갱신할 수 있다.
출처: Shopify Engineering, Native is now the future of mobile at Shopify