Shopify 네이티브 모바일이 돌아왔다. 그리고 AI가 트레이드오프를 바꿨다

Shopify의 네이티브 모바일 개발이 React Native를 대체하고 있다. 코딩 에이전트가 두 개의 애플리케이션을 유지하는 비용을 바꾸면서, Shopify는 6년간의 전략을 뒤집었다. Shopify는 iOS 소프트웨어를 Swift로, Android 소프트웨어를 Kotlin으로 개발할 예정이다. 회사는 이제 에이전트가 충분한 작업을 번역, 테스트, 검토할 수 있어 별도 코드베이스 운영이 실용적이라고 말한다.

이 결정은 크로스플랫폼 개발의 가장 강력한 약속 중 하나에 도전한다. React Native는 팀이 iOS와 Android 전반에서 애플리케이션 구현의 상당 부분을 공유할 수 있게 한다. Shopify는 기능을 두 번 개발하지 않고, 웹 개발자도 기여할 수 있게 하며, 두 플랫폼을 일치시키기 위해 이 모델을 채택했다.

Shopify는 React Native가 느렸거나 성공하지 못했다고 선언하는 것이 아니다. 회사는 이 프레임워크가 2020년 모바일 결정에서 약속한 이점을 제공했다고 말한다. 이번 전환은 다른 논거에 기반한다. AI가 구현 공유로 절감되는 노동을 줄인 반면, 네이티브 소프트웨어는 여전히 각 플랫폼에 더 밀접하게 접근할 수 있다는 것이다.

이 구분은 Shopify를 넘어 중요하다. 코딩 에이전트가 병렬 구현을 감당 가능한 수준으로 만든다면, 엔지니어링 팀은 코드 재사용을 측정하는 방식을 재고해야 한다. 가치 있는 공유 계층은 소스 코드에서 명세, 테스트, 디자인 시스템, 검토 절차로 이동할 수 있다.

Shopify 네이티브 모바일, 성공적인 React Native 전략을 대체하다

Shopify는 그 아래의 경제적 전제가 바뀌었기 때문에 성공적인 아키텍처를 폐기하고 있다.

회사는 2026년 9월 10일 네이티브 개발로의 복귀를 발표했다. 주요 모바일 제품에는 Shop, Shopify, Point of Sale, Inbox가 포함된다. Shopify에 따르면 수백만 명의 판매자와 구매자가 이 애플리케이션에 의존하고 있다.

회사는 2020년에 React Native에 전면적으로 투자했다. React Native는 JavaScript와 네이티브 플랫폼 컴포넌트로 iOS 및 Android 인터페이스를 구축하는 Meta의 프레임워크다. Shopify는 두 운영체제 간 중복 개발을 줄일 공통 스택을 원했다.

초기 결과는 이 결정을 뒷받침했다. 회사는 Shop으로 발전한 Arrive에서 95%의 코드가 공유됐고, Compass에서는 99%가 공유됐다고 보고했다. 한 팀은 Arrive를 React Native로 재작성한 뒤 생산성이 두 배가 됐다고 느끼기도 했다.

Shopify는 이후 가장 큰 판매자용 애플리케이션을 이 프레임워크로 전환했다. 이 제품은 각 플랫폼에서 300개가 넘는 화면을 포함했다. 완전한 재작성을 위해 기능 개발을 중단하는 것보다 점진적 마이그레이션이 처음에는 더 안전해 보였다.

이 전략에는 상당한 조직적 투자가 필요했다. Shopify는 내부 React Native 프로그램을 통해 네이티브 개발자를 교육하고, 공유 기반을 만들며, 더 넓은 생태계에 라이브러리를 기여했다. 또한 플랫폼별 작업이 계속 필요한 경우 네이티브 코드와 React Native를 혼합하는 절차도 개발했다.

2025년 1월까지도 Shopify는 React Native의 미래가 밝다고 설명했다. 회사의 5년간의 리뷰는 Meta의 관리 역량을 높이 평가하고 공유 기반에 대한 추가 투자를 약속했다. 또한 이 프레임워크를 사용하는 기업들을 위한 부활한 워킹 그룹도 홍보했다.

따라서 새 발표는 실패한 실험을 뒤늦게 거부한 것이 아니라 진정한 전략 전환을 의미한다. Shopify는 React Native가 시간을 절약하고, 기여할 수 있는 사람을 늘리며, 기능 동등성을 맞추는 데 드는 노력을 줄였다고 말한다.

그러나 이 이점에는 지속적인 비용이 따랐다. 팀은 성능을 최적화하고, 기반 컴포넌트를 유지하며, 프레임워크 변화를 따라가고, 외부 의존성을 관리했다. Shopify는 공유 구현이 상당한 중복 작업을 없애는 동안 이러한 비용을 감당할 만하다고 판단했다.

코딩 에이전트가 이 계산을 바꿨다. Shopify는 2021년부터 소프트웨어 개발에 대규모 언어 모델을 활용해 왔다고 말한다. 초기 활용 사례에는 기능 구현, 버그 조사, 문제 수정, 코드 검토가 포함됐다.

2025년 말까지 회사는 더 복잡한 작업을 에이전트에 맡길 수 있게 됐다. 팀은 iOS 구현이 Android 구현을 이끌 수 있는지, 그리고 그 반대 과정도 똑같이 잘 작동하는지를 시험하기 시작했다. 이러한 프로토타입은 Shopify가 별도의 Swift 및 Kotlin 애플리케이션으로 향하게 했다.

회사의 새로운 네이티브 전략은 여전히 핵심적인 단점을 인정한다. 네이티브 개발은 팀이 소프트웨어를 두 번 구축하고 유지해야 한다. Shopify에 따르면 AI는 이 부담을 줄였지만 없애지는 못했다.

이 전환은 Shopify가 한때 대규모 React Native 사용에 대해 유난히 강력한 증거를 제시했던 기업이기 때문에 중요하다. 단지 작은 기능 주변에서 프레임워크를 사용한 것이 아니다. 대형 애플리케이션을 마이그레이션하고, 팀을 교육하며, 인프라를 구축하고, 유지관리자를 후원하고, 재사용 가능한 라이브러리를 공개했다.

이제 같은 회사가 구현 재사용은 더 이상 같은 비중을 둘 가치가 없다고 주장하고 있다. 이것이 이 글의 핵심 긴장이다. Shopify의 React Native 마이그레이션 역사는 프레임워크가 작동했음을 보여주지만, Shopify의 에이전트는 이를 유지해야 할 사업적 근거를 약화시켰다.

코딩 에이전트가 크로스플랫폼 팀을 압박하다

즉각적인 압박은 공유 코드를 모바일 효율성의 주요 척도로 여기는 조직에 가해진다.

크로스플랫폼 프레임워크는 두 종류의 레버리지를 결합한다. 개발자가 행동을 한 번만 표현하게 하고, 기업이 더 적은 언어와 도구 중심으로 모바일 작업을 조직하게 한다. 두 이점 모두 코딩 시간뿐 아니라 조정 비용도 줄인다.

Shopify의 주장은 첫 번째 이점을 직접 약화시킨다. 에이전트는 기존 iOS 기능을 분석하고 그에 대응하는 Android 구현을 생성하며 행동 동등성 검증을 도울 수 있다. 소스 코드는 다르지만, 상당수의 인적 노력은 더 이상 수작업으로 반복할 필요가 없다.

그러면 관심은 두 번째 이점으로 옮겨간다. 별도 플랫폼에는 여전히 다른 빌드 시스템, 의존성, 릴리스 절차, 테스트 환경, 전문적 판단이 필요하다. 에이전트는 이러한 작업을 지원할 수 있지만, 팀은 출시되는 모든 결과물에 여전히 책임을 진다.

프레임워크 유지관리자는 이제 더 복잡한 가치 제안에 직면한다. 소프트웨어 번역 비용이 낮아지면 “한 번 작성”은 설득력이 떨어진다. 크로스플랫폼 도구는 신뢰성, 반복 속도, 팀 이동성, 생태계 품질, 조정 오버헤드 감소를 통해 가치를 입증해야 한다.

모바일 엔지니어링 리더들은 반대 방향의 압력에도 직면한다. 경영진은 Shopify의 Swift Kotlin 개발을 모든 기업이 공유 코드베이스를 포기할 수 있다는 증거로 해석할 수 있다. 그러한 결론은 Shopify가 에이전트 주변에 구축한 시스템을 무시하는 것이다.

Shopify는 모델에게 한 번에 애플리케이션을 재생성하라고 요청하지 않았다. 구조화된 워크플로, 검토 체크포인트, 테스트 도구, 아키텍처 제약을 만들었다. 숙련된 엔지니어는 요구사항, 플랫폼 결정, 프로덕션 품질을 계속 책임졌다.

마이그레이션은 또한 유난히 유리한 입력값에서 시작됐다. 바로 작동 중인 React Native 제품이었다. 이 애플리케이션은 화면, 상호작용, 내비게이션, 분석, 데이터 동작을 위한 실행 가능한 명세 역할을 했다. 에이전트는 제품 전체를 발명하는 대신 정의된 동작을 번역했다.

이 차이는 문서화가 부실한 애플리케이션을 가진 기업에 추가적인 압박을 가한다. AI가 생성한 포팅은 명확한 기준 동작과 관찰 가능한 결과에 의존한다. 모호한 레거시 시스템은 에이전트가 버그를 재현하거나, 엣지 케이스를 누락하거나, 호환되지 않는 패턴을 만들어낼 기회를 더 많이 제공한다.

개발자도 영향을 받는다. React Native는 웹 경험이 있는 사람들이 모바일 기능 작업을 할 수 있게 하면서 한때 Shopify의 기여자 풀을 넓혔다. 네이티브 코드는 전통적으로 전문 Swift, Kotlin, iOS, Android 지식에 더 큰 가치를 부여했다.

Shopify는 이제 에이전트가 엔지니어가 자신의 주력 스택 밖에서도 기여하도록 돕는다고 말한다. 익숙한 선언형 인터페이스 패턴 역시 React Native 개발자가 SwiftUI와 Jetpack Compose를 더 쉽게 배울 수 있게 했다. SwiftUI와 Jetpack Compose는 애플리케이션 상태를 통해 인터페이스를 정의하는 Apple과 Google의 현대적 프레임워크다.

그렇다고 플랫폼 전문성이 선택 사항이 되는 것은 아니다. 네이티브 엔지니어는 여전히 라이프사이클 동작, 접근성, 메모리, 백그라운드 처리, 플랫폼 관례, 릴리스 제약을 이해한다. 생성된 코드는 올바르게 보이면서도 아키텍처 드리프트나 미묘한 성능 문제를 일으킬 수 있다.

필수 대응이 반드시 프레임워크 마이그레이션인 것은 아니다. 이제 팀은 공유 코드가 실제 절감 효과를 내는 지점을 다시 계산해야 한다. 또한 에이전트가 자체 환경에서 두 구현 전반의 품질을 보존할 수 있는지 보여주는 증거도 필요하다.

React Native 팀에게 가장 강력한 대응은 이념적 대응이 아니라 운영적 대응이 될 것이다. 업데이트 노력, 의존성 유지보수, 크래시율, 시작 속도, 빌드 시간, 플랫폼별 예외를 측정할 수 있다. 이 수치는 공유 구현이 여전히 추상화 계층에 대한 비용을 상쇄하는지 보여준다.

네이티브 팀에게 Shopify의 결과는 AI 생산성을 입증하는 기준을 높인다. 코드 완성만으로는 충분하지 않다. 신뢰할 수 있는 에이전트 워크플로는 분석, 접근성, 내비게이션, 테스트, 릴리스 안전성, 일관된 제품 동작을 보존해야 한다.

따라서 장기적 압력은 양 진영 모두를 겨냥한다. 크로스플랫폼 옹호자는 코드 재사용을 넘어선 이점을 정량화해야 한다. 네이티브 옹호자는 에이전트 지원 중복 구현이 마이그레이션의 흥분이 지나간 뒤에도 유지 가능함을 입증해야 한다.

이번 전환은 React Native 성능이 아니라 재사용에 관한 것이다

Shopify의 결정은 코드 재사용과 제품 일관성을 분리하며, 이를 서로 다른 엔지니어링 문제로 다룬다.

React Native는 역사적으로 이 목표들을 연결했다. 공유 컴포넌트나 기능은 일반적으로 두 애플리케이션이 같은 구현의 상당 부분을 실행했기 때문에 플랫폼 간 유사하게 동작했다. 이 관계는 플랫폼 버전이 달라질 수 있는 범위를 줄였다.

Shopify의 새 모델은 공유 인터페이스 코드를 버리면서도 일관성은 유지한다. 팀은 공통 명세, 테스트, 디자인 규칙, 분석 계약, 검토 체크포인트를 사용한다. 이후 에이전트가 각 플랫폼의 네이티브 프레임워크로 동일하게 의도된 동작을 구현한다.

이는 프로그래밍 언어를 바꾸는 것보다 더 깊은 전환이다. 회사는 단일 소스 오브 트루스를 더 상위 계층으로 옮기고 있다. 공유 코드를 주된 제품 계약으로 보는 대신, 검토된 의도와 관찰 가능한 동작을 계약으로 취급한다.

이 접근 방식은 여러 네이티브 이점을 보존한다. 개발자는 Apple과 Google이 출시하는 퍼스트파티 API를 사용할 수 있다. 공유 추상화를 조율하지 않고 플랫폼 관례를 따를 수 있다. 또한 애플리케이션과 운영체제 사이의 프레임워크 및 의존성 계층도 제거한다.

이 변화는 Shop이 또 다른 대규모 React Native 투자를 앞둔 시점에 나왔다. 애플리케이션은 렌더링, 네이티브 모듈 통합, 공유 코드와 플랫폼별 코드 간 경계를 바꾸는 프레임워크의 New Architecture를 채택해야 했다.

Shopify는 이 투자를 결정하기 전 SwiftUI와 Jetpack Compose에서 직접 개발을 시험했다. 한 엔지니어는 코딩 에이전트를 사용해 Shop의 최대한 많은 부분을 네이티브 iOS 프로토타입으로 마이그레이션하는 데 일주일을 보냈다.

이 프로토타입은 프로덕션 준비 상태가 아니었다. 그러나 충분한 화면, 상호작용, 애플리케이션 흐름을 재현해 완전한 마이그레이션이 가능해 보이게 했다. 에이전트는 정의된 기능과 눈에 보이는 동작을 기반으로 작업할 수 있을 때 가장 좋은 성과를 냈다.

그 후 핵심 엔지니어 6명으로 구성된 그룹이 네이티브 기반과 주요 Shop 여정을 구축했다. 기능 팀들은 중간에 합류해 담당 영역을 검증하고 예외 사례를 해결했다. Shopify는 12주 안에 개념 검증 단계에서 매장에 배포되는 네이티브 애플리케이션 단계로 전환했다.

이 수치는 이러한 전환이 신뢰를 얻은 이유를 설명한다. 기존 아키텍처를 이어받지 않고 새로 구현하는 일반적인 그린필드 재작성은 수년이 걸릴 수 있다. 또한 제품 개발을 멈추게 하고, 장기간의 기능 동등성 문제를 초래할 수 있다.

Shopify는 반대 방향에서 이 문제를 경험한 바 있다. 이전의 점진적인 React Native 전환 과정에서는 iOS, Android, React Native라는 세 가지 아키텍처가 공존하는 기간이 생겼다. 2022년의 한 설명에 따르면, 당시 속도라면 완료까지 4~5년이 걸렸을 것이다.

Shopify는 네이티브 복귀를 위해 그린필드 방식을 선택했다. 코딩 에이전트가 기존 React Native 애플리케이션을 참고할 수 있었고, 새 코드베이스는 기존 아키텍처의 제약을 제거했다고 회사는 설명한다. 프로토타입은 애플리케이션을 이전보다 훨씬 빠르게 재구축할 수 있음을 시사했다.

Shop 결과는 성능 근거도 제공했다. Shopify에 따르면 네이티브 iOS 애플리케이션은 홈 화면의 가시적 콘텐츠를 2,466밀리초 만에 표시했으며, 이전에는 3,200밀리초가 걸렸다. 이는 시작 시간이 23% 줄어든 수치다.

Android에서는 시작 시간이 4,433밀리초에서 2,233밀리초로 감소해 50% 단축됐다. Android 릴리스 빌드 크기는 293MB에서 184MB로 줄었고, iOS 빌드 크기는 67MB에서 68MB로 늘었다.

Android 릴리스 빌드 시간은 약 75% 감소했다. Shopify는 또한 Pixel 기기에서 피드 스크롤과 탐색 중 네이티브 Android 애플리케이션이 초당 120프레임에 도달하는 모습을 제시했다.

세션 안정성은 과거 최소 99.5%에서 네이티브 출시 후 최소 99.95%로 상승했다. Shopify는 이를 크래시가 발생하는 세션이 10분의 1로 줄어든 변화라고 설명했다.

이는 독립 벤치마크가 아니라 회사가 보고한 비교 수치다. 마이그레이션에는 제품 단순화도 포함됐으며, 일부 화면은 제거되고 다른 화면은 간소화됐다. 따라서 모든 개선을 네이티브 기술만의 결과로 돌리기는 어렵다.

Shopify 역시 그런 주장을 하지 않는다. 회사는 React Native 애플리케이션도 빨랐으며 React Native는 여전히 훌륭한 프레임워크라고 명시한다. 핵심 주장은 에이전트가 중복 작업을 줄인 뒤 공유 구현이 제공하는 상대적 가치에 관한 것이다.

이 구분은 React Native와 네이티브 간의 오해를 낳기 쉬운 판결을 피하게 한다. Shopify는 모든 애플리케이션에 적용되는 보편적 벤치마크를 제시하는 것이 아니다. 대신 자사의 팀, 도구, 아키텍처, 제품 규모가 이제 다른 균형을 더 선호하게 됐다고 보고한다.

Helix는 이 마이그레이션이 단순한 코드 생성 이상이었던 이유를 보여준다

Shopify는 마이그레이션을 통제된 검증 루프로 전환해 네이티브 중복 구현을 관리 가능한 수준으로 만들었다.

회사는 일회성 변환이 유지보수하기 어려운 코드를 지나치게 많이 만든다는 사실을 발견했다. 사전에 상세한 사양을 마련해도 전체 자동 재작성을 신뢰할 수 있게 만들지는 못했다. 결과물은 완성된 것처럼 보이면서도 일관되지 않은 패턴과 누락된 동작을 숨길 수 있었다.

Shopify는 마이그레이션 작업을 작은 검증 지점으로 나누기 위해 Helix를 만들었다. 개발자가 시스템에 화면을 지정하면 Helix는 React Native 구현을 읽는다. 이어 사람이 빠르게 검토할 수 있는 순서화된 작업 단계를 제안한다.

각 검증 지점은 테스트를 통해 동작을 입증해야 한다. 또한 다음 검증 지점이 시작되기 전에 시각 비교, 적대적 관점의 코드 리뷰 두 차례, 사람의 승인을 거친다. 피드백은 축적돼 시간이 지날수록 워크플로가 더 자율적으로 작동하게 된다.

이 메커니즘은 순수한 생성 속도보다 더 중요하다. 소프트웨어 마이그레이션은 오류가 리뷰어가 이해할 수 있는 속도보다 빠르게 누적될 때 실패한다. 작고 승인된 단위는 검증되지 않은 동작이 새 애플리케이션으로 유입되는 양을 제한한다.

Shopify는 별도 워크트리에서 여러 에이전트 세션도 운영했다. 전문화된 하위 에이전트는 기존 코드를 조사하고, 동작을 문서화하며, 플랫폼 계획을 준비하고, 기능을 구현하고, 기능 동등성을 검토했다. 엔지니어들은 개발이 진행되기 전에 요구사항과 구현 계획을 승인했다.

계획 승인은 검토된 콘텐츠의 해시에 연결됐다. 계획이 변경되면 이전 승인은 무효가 됐다. 이 설계는 에이전트가 승인을 받은 뒤 조용히 다른 계획을 구현할 가능성을 줄였다.

워크플로는 보이는 인터페이스 요소보다 더 많은 것을 검토했다. Shopify에 따르면 소스 리뷰는 상태, 내비게이션, 분석, 접근성, 데이터 동작을 포괄했다. 스크린샷만으로는 드러나지 않기 때문에, 이 영역들은 흔히 가장 어려운 마이그레이션 실패가 발생하는 지점이다.

분석 데이터 보존은 특히 중요했다. 추천 시스템과 기타 다운스트림 시스템은 예상된 이벤트와 맥락적 필드에 의존했다. 이벤트 이름, 횟수, 페이로드 간 관계가 바뀌면 시각적으로 올바른 애플리케이션도 의사결정 시스템을 훼손할 수 있었다.

Shopify는 라이브 애플리케이션 이벤트, 로그, 상태를 구조화된 형태로 노출하는 또 다른 도구인 Tardis를 개발했다. 에이전트는 애플리케이션에 명령을 보내고, 문제를 조사하며, 내비게이션을 점검하고, 더 적은 수작업 상호작용으로 수정 사항을 검증할 수 있었다.

기능 동등성 리뷰를 위해 Tardis는 명명된 검증 지점에서 React Native 및 네이티브 애플리케이션의 스크린샷과 이벤트 구간을 캡처했다. 에이전트는 타임스탬프와 고유 페이지 식별자 등 정당한 차이를 고려하면서 이벤트 필드를 비교했다.

아키텍처는 시뮬레이터 지연 문제도 다뤘다. 모바일 에이전트는 인터페이스 상태를 이해하기 위해 흔히 접근성 트리나 스크린샷에 의존한다. 몇 초 안에 코드를 수정할 수 있지만, 이후 시뮬레이터를 통해 빌드하고 테스트하는 데 몇 분이 걸릴 수 있다.

Shopify는 이 느린 루프가 잦은 사람의 개입을 요구한다는 점을 발견했다. React Native의 핫 모듈 리로딩은 반복 작업을 개선했지만 시뮬레이터 병목을 없애지는 못했다. 피드백이 느리고 취약하게 남아 있는 상황에서는 모델 역량의 가치가 제한적이었다.

회사는 비즈니스 로직을 인터페이스에서 분리하는 방식으로 대응했다. 헤드리스 비즈니스 로직은 애플리케이션을 표시하지 않고 실행할 수 있다. Shopify는 이 로직을 명령줄 인터페이스로 노출해 에이전트가 데스크톱에서 밀리초 단위로 실행할 수 있게 했다.

이것이 Shopify의 네이티브 모바일 개발을 뒷받침하는 메커니즘이다. 에이전트가 단순히 생성된 코드로 엔지니어 6명을 대체한 것은 아니다. Shopify는 기계의 참여를 중심으로 애플리케이션 아키텍처, 피드백 시스템, 리뷰 게이트, 테스트 접근 방식을 재설계했다.

이 작업은 표면적인 경제성을 바꾼다. 두 구현을 유지하는 비용이 줄어드는 이유 중 하나는 조직이 공유 검증 시스템에 투자하기 때문이다. 공통 자산은 더 이상 인터페이스 코드가 아니라, 기대되는 동작을 기술하고 검증하는 장치가 된다.

이 모델은 팀이 기술적 결정에 관한 검색 가능한 기록을 구축하는 방식과도 닮아 있다. 사양, 계획, 리뷰 결과, 테스트 성과는 재사용 가능한 맥락이 된다. 엔지니어링 지식 베이스는 사람이 문서 전반에서 이러한 결정을 추적하는 데 도움이 될 수 있지만, 리포지터리 수준의 테스트를 대체하지는 않는다.

이 접근 방식은 성숙한 인프라를 갖춘 대규모 조직에 유리하다. Shopify는 맞춤형 도구를 만들고, 광범위한 자동화 검사를 유지하며, 경험 많은 엔지니어를 아키텍처와 리뷰에 배정할 수 있었다. 더 작은 팀은 공유 코드로 조율을 제공하는 프레임워크에서 더 큰 이점을 얻을 수 있다.

따라서 진정한 경쟁 구도는 공유 구현과 공유 의도 사이에 있다. React Native는 재사용 가능한 소스에 일관성을 직접 인코딩한다. Shopify의 새 프로세스는 사양, 계측, 테스트, 통제된 변환을 통해 일관성을 인코딩한다.

Shopify의 결과가 React Native와 네이티브의 논쟁을 결론짓지는 않는다

성공적인 12주 재작성은 두 네이티브 코드베이스가 전체 수명 기간 동안 더 저렴하게 유지될 것임을 증명하지 않는다.

마이그레이션 속도는 시작 단계의 측정치일 뿐이다. 더 어려운 검증은 두 애플리케이션이 독립적으로 발전한 뒤에 찾아온다. 새 기능, 운영체제 변화, 긴급 수정, 인력 교체는 에이전트가 구현을 계속 정렬된 상태로 유지할 수 있는지를 드러낼 것이다.

기능 동등성은 여전히 명시된 요구사항이다. Shopify는 Android와 iOS가 항상 정렬된 상태를 유지해야 한다고 말한다. 이전에는 공유 React Native 코드가 그 조건의 상당 부분을 구조적으로 강제했다. 새 프로세스는 개발 및 릴리스 통제를 통해 이를 강제해야 한다.

이는 여러 실패 가능성을 도입한다. 에이전트는 동등한 동작을 구현하면서도 호환되지 않는 아키텍처 패턴을 만들 수 있다. iOS의 가정을 Android에 복사하거나, 참조 애플리케이션에 존재한다는 이유로 기존 버그를 보존할 수도 있다.

생성된 코드는 테스트를 통과하면서도 중복이나 기술 부채를 늘릴 수 있다. Shopify는 아키텍처 드리프트, 반복 로직, 성능 문제 등을 위험 요소로 인정한다. 리포지터리 가이드라인, 린팅, 정적 분석, 성능 검사, 사람의 리뷰는 여전히 필요하다.

따라서 네이티브 전문성은 줄어들기보다 더 중요해진다. 엔지니어는 생성된 Swift가 Apple의 관례를 따르는지, 생성된 Kotlin이 Android 아키텍처에 맞는지를 판단해야 한다. 또한 모델이 충실하게 재현했지만 유지해서는 안 되는 동작도 알아차려야 한다.

Shop 마이그레이션은 안정적인 참조 구현의 이점을 얻었다. 새 제품 개발은 다른 문제를 만든다. 어느 플랫폼에도 승인된 버전이 없을 때 에이전트는 알려진 소스에서 동작을 번역할 수 없다. 팀은 먼저 두 구현 모두를 위해 의도를 충분히 명확하게 정의해야 한다.

제품 발견 과정은 이를 어렵게 만들 수 있다. 디자이너와 엔지니어는 초기 버전을 사용하면서 동작을 자주 다듬는다. 공유 React Native 컴포넌트는 이러한 개선을 즉시 플랫폼 전반에 적용하는 반면, 네이티브 팀은 이를 두 번 전파하고 검증해야 한다.

성능 비교에도 주의가 필요하다. Shopify는 깨끗한 기반 위에서 Shop을 재구축하고 제품의 일부를 단순화했다. 네이티브 프레임워크, 줄어든 의존성, 제거된 화면, 아키텍처 정리가 모두 보고된 성능 향상에 기여했을 수 있다.

측정치는 독립적인 테스트 기관이 아니라 Shopify에서 나왔다. 프로덕션 배포를 설명한다는 점에서 여전히 가치가 있지만, 보편적 비율로 받아들여서는 안 된다. 애플리케이션마다 시작 경로, 네이티브 통합, 팀 구조가 다를 것이다.

React Native는 코딩 에이전트가 없애지 못하는 장점을 계속 제공한다. 공유 구현은 비즈니스 로직이 달라질 수 있는 위치의 수를 줄인다. 생태계는 라이브러리, 디버깅 관행, 배포 도구, 그리고 대규모 React 개발자 인력 풀도 제공한다.

Shopify 역시 이러한 강점을 강조해 왔다. 이전 마이그레이션은 공유 기반을 만들고 개발자가 애플리케이션 간에 이동하는 데 도움을 줬다. 회사는 또한 React Native가 팀이 플랫폼 차이를 끊임없이 조정하지 않고도 가치를 배포할 수 있게 했다고 말했다.

오픈 소스 전환은 또 다른 불확실성을 더한다. Shopify는 2026년 말까지 React Native Skia를 후원할 계획이며, 그 이후에는 메인테이너 William Candillon이 새 이름으로 프로젝트를 계속 운영할 예정이다. 원래 리포지터리는 결국 아카이브될 것이다.

FlashList는 다른 경로를 제시한다. Shopify에 따르면 이 고성능 리스트 라이브러리는 매주 약 200만 건의 다운로드를 기록한다. 회사는 다른 조직과 장기적인 관리 방안을 논의하는 한편, 치명적인 호환성 문제를 수정할 계획이다.

Restyle은 사용자 기반이 더 작아 아카이브될 예정이다. Shopify는 잠재적인 다른 메인테이너 인수 지원과 함께, 2026년 말까지는 계속 작동할 것이라고 말한다. 이러한 전환은 Shopify 라이브러리에 의존하는 개발자에게 실질적인 계획 수립 작업을 요구한다.

이들은 또한 주요 사용자의 이탈이 그 기술의 신뢰를 훼손하지 않더라도 생태계에 영향을 미치는 이유를 보여준다. React Native는 저명한 도입 기업으로부터 엔지니어링 투자, 현장 테스트, 조직적 지지를 잃는다. 커뮤니티의 관리 체계가 그 기여를 대체할 수는 있지만, 그 이관은 성공해야 한다.

회사의 더 광범위한 마이그레이션은 아직 완료되지 않았다. Shop은 이전되는 첫 번째 애플리케이션이다. 주요 Shopify 애플리케이션에는 300개가 넘는 화면, 위젯, Apple Watch 애플리케이션, 컴플리케이션, Siri Shortcuts가 포함되어 있다.

Shopify는 해당 애플리케이션을 2026년 후반에 네이티브로 출시하고, 나머지 애플리케이션도 뒤따르게 할 것이라고 밝혔다. 이 프로젝트들은 더 폭넓은 플랫폼 통합과 판매자 핵심 워크플로를 포함하고 있어 Shop보다 더 강도 높은 시험대가 된다.

그때까지 책임 있는 결론은 제한적이다. Shopify는 에이전트 지원 네이티브 마이그레이션이 하나의 주요 애플리케이션에서 빠르게 작동할 수 있음을 입증했다. 하지만 전체 모바일 포트폴리오에 걸친 장기 유지보수 비용은 아직 확립하지 못했다.

Shopify의 선택이 유지되는지 보여줄 세 가지 신호

다음 증거는 반복 가능성, 지속적인 동등성, 안정적인 오픈소스 이관을 보여줘야 한다.

첫 번째 신호는 주요 Shopify 애플리케이션의 네이티브 출시다. 300개가 넘는 화면과 광범위한 Apple 통합 기능은 이를 Shop보다 더 어려운 마이그레이션으로 만든다. 기능을 보존한 채 예정대로 출시된다면 Shopify의 방식이 확장 가능하다는 주장을 강화할 것이다.

이 출시의 품질은 날짜 자체보다 더 중요하다. 시작 성능, 세션 안정성, 빌드 시간, 접근성, 분석 연속성, 판매자 워크플로가 React Native 버전과 동등하거나 그보다 개선되어야 한다. 출시가 지연되거나 품질이 고르지 않다면 신속한 그린필드 마이그레이션의 근거는 약화될 것이다.

두 번째 신호는 독립적인 기능 개발이 시작된 이후에도 동등성이 유지되는지다. Shopify는 iOS와 Android가 검토 지연을 늘리지 않으면서 동등한 기능을 계속 출시한다는 점을 보여줘야 한다. 여러 릴리스 주기에 걸친 증거가 마이그레이션 처리량보다 더 중요하다.

이 시험은 Shopify Swift Kotlin 개발의 핵심을 건드린다. 에이전트는 완료된 기능을 번역할 수 있지만, 제품팀은 구현 과정에서 요구사항도 변경한다. 일관된 분석과 동작은 시간이 지나며 공유 사양이 공유 소스를 대체할 수 있는지를 보여줄 것이다.

세 번째 신호는 Shopify의 React Native 라이브러리의 미래다. 원활한 React Native Skia 포크, 지속 가능한 FlashList 관리, 명확한 Restyle 가이드는 Shopify가 책임감 있게 이탈을 관리하고 있다는 주장을 뒷받침할 것이다.

유지보수가 중단된다면 전혀 다른 이야기가 된다. 이는 아키텍처 변경이 한 회사의 저장소를 넘어 비용을 부과한다는 점을 보여줄 것이다. 그 비용은 Shopify의 이전 약속을 기반으로 계획을 세운 개발자들에게 돌아갈 것이다.

엔지니어링 리더들은 이 결정을 따라 하기 전에 이러한 신호를 지켜봐야 한다. 또한 충돌, 시작 시간, 애플리케이션 크기, 빌드 기간, 프레임워크 유지보수, 동등성 작업에 대한 자체 기준선을 수립해야 한다.

그런 다음 실제 기능을 사용해 범위가 제한된 프로토타입을 실행할 수 있다. 테스트에는 분석, 접근성, 내비게이션, 오류 상태, 플랫폼 관례가 포함되어야 한다. 단순히 생성된 코드 줄 수가 아니라 검토 시간과 결함 발견도 측정해야 한다.

Shopify 네이티브 모바일 개발은 에이전트 시대에 재사용의 개념을 재구성한다는 점에서 중요하다. 이는 React Native와 네이티브 중 어느 쪽이 더 낫다는 보편적 답을 제시하지 않는다. 대신 구현 비용이 낮아진다면 엔지니어링 조직은 소스 오브 트루스를 어디에 두어야 하는가라는 까다로운 질문을 던진다.

팀은 프로덕션 증거를 바탕으로 이 질문에 답해야 한다. 에이전트가 여러 릴리스에 걸쳐 전체 검토 및 유지보수 노력을 줄이는지 추적해야 한다. 그렇다면 분리된 네이티브 애플리케이션은 더 매력적이 된다. 조정 비용이 코드 생성 개선 속도보다 빠르게 증가한다면, 공유 구현은 여전히 그 가치를 인정받는다.