Shopify, AI 코딩 에이전트와 함께 React Native에서 Swift·Kotlin 네이티브로 전환

핵심 요약

1. Shopify는 2020년 React Native로 전환해 코드 공유와 플랫폼 간 기능 동등성 유지의 이점을 얻었지만, AI 에이전트의 발전으로 네이티브 개발의 비용 구조가 달라졌다고 판단했다.
2. Shopify는 Swift와 Kotlin으로 주요 앱을 새로 구축하며, React Native 코드를 기준으로 기능 구현·플랫폼 간 변환·테스트·리뷰를 수행하는 Helix 시스템을 개발했다.
3. Shopify 앱과 Shop 앱을 시작으로 모든 모바일 앱을 네이티브로 전환하며, 성능·안정성·접근성·제품 품질을 현재 수준 이상으로 유지하는 것을 기준으로 삼는다.

도입

Shopify는 2020년 React Native를 전사 모바일 기술 스택으로 선택해 기능을 한 번만 구현하고 여러 플랫폼에서 공유하는 방식을 택했다. 그러나 2025년 말부터 coding model과 agent가 Swift·Kotlin 구현, 플랫폼 간 변환, 테스트와 리뷰를 수행할 수 있게 되면서 핵심 가정이 바뀌었다. Shopify는 여러 앱을 대상으로 프로토타입을 진행한 뒤 React Native에서 네이티브 개발로 돌아가기로 결정했다.

상세 요약

React Native에서 네이티브로 돌아가는 이유

Shopify는 2020년 React Native를 선택하며 세 가지 목표를 세웠다.

• 같은 기능을 두 번 구현하지 않는다.
• 모바일 경험이 없는 개발자도 앱 개발에 참여할 수 있게 한다.
• 플랫폼 간 기능 동등성을 맞추는 작업보다 제품 개발에 시간을 쓴다.

React Native는 이 목표를 실제로 달성했다. Shopify는 여러 기능을 한 번만 개발했고, 개발자의 참여 범위를 넓혔다. 대신 성능 최적화, React Native의 기반 영역 개선, 프레임워크와 외부 의존성 업데이트에 상당한 시간과 자원을 투입했다. 당시에는 이런 비용보다 공유 구현의 이점이 컸다.

하지만 2025년 말부터 LLM 기반 coding agent가 기능 구현을 넘어 플랫폼 간 개발을 지원할 수 있게 됐다. Shopify는 주요 앱의 일부를 Swift와 Kotlin으로 다시 만들며 다음 작업을 확인했다.

• 한 플랫폼의 구현을 참고해 다른 플랫폼의 기능을 만들 수 있다.
• 개발자는 주력 플랫폼이 아닌 환경에서도 더 빠르게 기여할 수 있다.
• 공유 사양, 테스트, 리뷰 체크포인트를 이용해 플랫폼 간 기능 동등성 유지 비용을 낮출 수 있다.

네이티브 개발은 여전히 iOS와 Android용 소프트웨어를 각각 만들고 유지해야 한다. 다만 구현, 변환, 테스트, 리뷰의 상당 부분을 agent가 수행하면서 이중 개발 비용이 더 이상 기술 스택을 결정하는 유일한 요소가 아니게 됐다. 네이티브 방식은 각 플랫폼의 기능과 first-party tooling에 더 가깝고, 프레임워크와 의존성 계층도 줄일 수 있다는 점이 선택의 근거가 됐다.

2026년 Expo 없는 React Native 확장이 레거시 리스크인 이유은 React Native 확장 과정에서 발생하는 구조적 부담을 다룬다. Shopify의 결정은 이와 달리 공유 구현 자체의 이점이 AI agent의 발전으로 상대적으로 줄었다는 판단에 기반한다.

오픈소스 라이브러리의 처리 계획

Shopify는 React Native 생태계에 기여해 온 라이브러리를 한꺼번에 중단하지 않는다.

• React Native Skia: 2026년 말까지 후원을 이어간다. William Candillon은 이후에도 개발을 계속하며, 몇 달 안에 저장소를 fork해 새 이름으로 배포할 예정이다. 기존 저장소는 전환이 끝나면 보관된다.
• FlashList: 주당 약 200만 회 다운로드되는 라이브러리다. Shopify는 호환성을 깨뜨리는 치명적 문제를 계속 수정하고, 장기 유지보수 주체를 찾고 있다.
• Restyle: 저장소를 보관한다. 2026년 말까지 동작을 유지한 뒤 유지보수를 중단하며, 다른 팀의 fork와 인계를 지원한다.

기존 앱을 새로 구축하는 전략

Shopify는 Shopify, Shop, Point of Sale, Inbox 등 대형 앱을 운영한다. 기존에는 React Native로 옮길 때 일부 앱에 점진적 전환인 brownfield 방식을 적용했다. 전체 재작성에는 수년이 걸리고, 전환 중 새 기능 출시를 멈춰야 했기 때문이다.

이번에는 greenfield가 선택됐다. React Native 버전을 참고해 Swift와 Kotlin으로 기능을 구현하는 작업이 agent에 적합했고, 이전 제약 없이 앱을 다시 설계할 수 있었다. 프로토타입에서도 과거보다 훨씬 빠른 재구축이 확인됐다.

Shop 앱은 첫 번째 전환 대상이다. 팀은 AI의 지원을 받아 proof of concept에서 앱스토어에 게시된 완전한 네이티브 앱까지 12주 만에 도달했다. 300개가 넘는 화면과 홈·잠금화면 위젯, Apple Watch 앱, complications, Siri Shortcuts를 포함한 Shopify 앱도 전환 중이며, 나머지 앱도 뒤따를 예정이다.

Helix로 생성 결과를 단계적으로 검증

React Native 코드를 agent에 입력하고 네이티브 앱을 한 번에 생성하는 방식은 유지보수할 수 없는 코드로 이어졌다. Shopify는 이를 막기 위해 Helix를 구축했다.

개발자가 화면을 지정하면 Helix는 React Native 코드를 읽고 작업을 작은 순서형 체크포인트로 나눈다. 각 체크포인트는 다음 조건을 통과해야 한다.

• 테스트로 동작을 증명한다.
• 실행 중인 앱과 시각적으로 일치하는지 검토한다.
• 두 명의 적대적 코드 리뷰어 검토를 통과한다.
• 사람이 승인해야 커밋하고 다음 단계로 넘어간다.

각 리뷰의 피드백은 이후 단계에 반영된다. 따라서 전환이 진행될수록 반복 작업의 자율성이 높아진다. AI 생성 React Native 코드의 숨겨진 비용과 안정화 가이드에서 다룬 생성 코드의 유지보수 문제와도 연결되는 접근이다.

시뮬레이터 대신 CLI 중심의 피드백 루프

모바일 agent 개발의 병목은 시뮬레이터 제어였다. 접근성 트리나 스크린샷으로 앱 상태를 확인하고 조작하는 방식은 느리고 불안정했다. 코드 변경은 몇 초 만에 끝나도 결과를 테스트하는 데 수분이 걸렸다.

Shopify는 비즈니스 로직을 UI에서 완전히 분리하고 데스크톱에서 headless로 실행할 수 있도록 앱 아키텍처를 설계한다. agent는 CLI를 통해 앱 상태를 확인하고, 섹션을 이동하며, 동작을 실행할 수 있다. 이 작업은 시뮬레이터 없이 밀리초 단위로 수행된다.

시뮬레이터가 필요할 때는 CLI가 remote mode로 연결돼 레이아웃이나 접근성 트리를 검사하지 않고 명령으로 UI를 구동한다. Shopify는 이를 통해 E2E 테스트와 자동 수정·검증을 빠르게 수행하려 한다.

전환의 평가 기준

Shopify는 모든 모바일 앱을 Swift와 Kotlin으로 옮긴다. 전환 속도를 높이더라도 기존의 성능, 안정성, 접근성, 제품 품질 기준을 낮추지 않는다. 목표는 같은 앱을 다른 언어로 다시 쓰는 데 그치지 않는다. 사람과 agent가 앱을 빠르게 이해하고 테스트하고 변경할 수 있는 구조로 재구축하는 것이다.

성과는 제품 개발 속도, 앱 품질, agent가 자율적으로 완료하는 작업량으로 측정한다.

결론

이번 전환의 핵심은 단순히 프로그래밍 언어를 바꾸는 데 있지 않다. Shopify는 비즈니스 로직을 UI와 분리하고 데스크톱에서 headless로 실행할 수 있게 만들어 에이전트의 피드백 속도를 높인다. Helix는 작은 체크포인트마다 테스트, 시각 검토, 적대적 코드 리뷰와 사람의 승인을 요구한다. Shopify는 제품 출시 속도, 앱 품질, 에이전트의 자율 수행 범위를 전환 성과로 측정한다.