쇼피파이는 왜 React Native를 버리고 네이티브 앱 개발로 복귀했을까? (AI 에이전트가 바꾼 개발 비용의 법칙)
쇼피파이는 왜 React Native를 버리고 네이티브 앱 개발로 복귀했을까? (AI 에이전트가 바꾼 개발 비용의 법칙)
GeekNews · 2026-09-13 00:32
① 글로벌 커머스 플랫폼 쇼피파이가 주요 모바일 앱들을 React Native에서 Swift와 Kotlin 기반 네이티브 개발로 전면 전환하기로 결정했습니다.
② 이번 결정은 React Native의 성능 문제가 아니라, 코딩 에이전트의 발전으로 두 플랫폼을 각각 개발하는 비용이 극적으로 낮아졌기 때문입니다.
③ 첫 주자인 'Shop' 앱은 핵심 엔지니어 6명과 AI 에이전트의 협업으로 12주 만에 완전한 네이티브 앱으로 재구축되어 출시되었습니다.
④ 자체 구축한 단계별 검증 시스템 'Helix'와 비즈니스 로직을 시뮬레이터 없이 검증하는 CLI 도구 등을 통해 에이전트의 작업 생산성을 극대화했습니다.
왜 성공적이었던 크로스 플랫폼 결정을 6년 만에 뒤집었을까?
글로벌 커머스 플랫폼 쇼피파이(Shopify)가 자사의 모바일 앱들을 리액트 네이티브(React Native, 단일 코드베이스로 iOS와 안드로이드 앱을 동시에 개발하는 프레임워크)에서 각 플랫폼 고유의 언어인 스위프트(Swift)와 코틀린(Kotlin) 기반의 '네이티브(Native)' 개발 체제로 복귀시키겠다고 발표했습니다. 이는 지난 2020년 쇼피파이가 리액트 네이티브 전면 도입을 선언하며 얻었던 수많은 이점들을 뒤로하는 결정이기에 업계의 큰 주목을 받고 있습니다.
당시 쇼피파이가 리액트 네이티브를 선택한 이유는 명확했습니다. 중복 구현을 없애고, 모바일 개발 경험이 없는 웹 개발자도 모바일 앱 개발에 기여하게 만들며, 양대 플랫폼 사이의 기능 일치(feature parity)를 쉽게 달성하기 위함이었습니다. 실제로 이 결정은 수년간 매우 성공적이었고 성능 또한 훌륭하게 유지되었습니다. 심지어 2025년 1월까지만 해도 쇼피파이는 리액트 네이티브에 대한 투자를 이어갈 계획이었습니다.
하지만 불과 1년 만에 상황이 완전히 바뀌었습니다. 거대언어모델(LLM, Large Language Model)과 코딩 에이전트(coding agent, 스스로 코드를 작성하고 수정하는 AI 도구) 기술이 비약적으로 발전하면서, 기존의 대전제였던 "두 플랫폼을 각각 따로 개발하면 비용이 두 배로 든다"는 명제가 더는 유효하지 않게 되었기 때문입니다. 쇼피파이는 리액트 네이티브 프레임워크 자체의 한계나 성능 실패 때문이 아니라, 기술 환경의 변화로 개발의 비용 구조가 재편되어 네이티브로 복귀한다고 명확히 밝혔습니다.
AI 코딩 에이전트는 어떻게 양대 플랫폼 개발 비용을 낮추었는가?
전통적으로 iOS 앱과 안드로이드 앱을 따로 네이티브로 만드는 방식은 두 배의 시간과 인력이 들어가는 비효율을 감수해야 했습니다. 그러나 숙련된 코딩 에이전트는 이미 작성된 한쪽 플랫폼의 구현 코드(예: iOS 스위프트 코드)를 참고하여 다른 쪽 플랫폼(예: 안드로이드 코틀린)용 코드로 정밀하게 변환하고 마이그레이션(migration, 시스템 이전 작업)하는 작업을 훌륭히 수행해 냈습니다.
쇼피파이의 실험 결과, 에이전트는 기존 구현이라는 명확한 참조 대상이 있을 때 극도의 효율성을 보였습니다. 화면의 뼈대를 만들고, 데이터를 연결하며, 애니메이션을 구현하고 시각적인 레이아웃을 다듬는 까다로운 작업을 에이전트가 주도적으로 수행했습니다. 개발자가 자신의 주력 스택(개발 분야)이 아닌 플랫폼 코드를 다루어야 할 때도 에이전트의 도움을 받아 빠르게 적응하고 기여할 수 있었습니다.
결과적으로 공유 스펙, 자동화된 테스트, 에이전트 기반의 리뷰 프로세스를 통해 플랫폼 간 기능 싱크를 맞추는 비용이 극적으로 낮아졌습니다. 네이티브 개발이 보장하는 고유한 성능적 이점(운영체제 API 및 공식 개발 도구에 대한 직접 접근, 서드파티 의존성 레이어 감소 등)을 온전히 누리면서도, 이중 개발비용이라는 단점은 AI로 상쇄할 수 있게 된 것입니다.
6명의 엔지니어가 12주 만에 이뤄낸 'Shop' 앱의 기적
쇼피파이는 점진적인 마이그레이션 대신 전체 앱을 처음부터 완전히 새로 작성하는 전면 재구축(greenfield) 방식을 과감하게 선택했습니다. 수억 명의 고객과 수백만 판매자가 사용하는 대표 서비스인 'Shop' 앱이 첫 시험대였습니다. 프로젝트는 1명의 엔지니어가 코딩 에이전트와 함께 일주일간 리액트 네이티브 기반 앱을 스위프트 UI(SwiftUI) 기반 iOS 앱으로 변환해보는 개념 증명(PoC, Proof of Concept)으로 시작되었습니다. 단 1주일 만에 완벽하지는 않지만 기존 기능을 거의 동일하게 구현할 수 있음을 확인하고 전면 전환을 확정했습니다.
본격적인 전환 작업에는 단 6명의 핵심 엔지니어가 투입되었습니다. 이들은 에이전트의 보조를 받아 앱의 네이티브 기반을 다지고 핵심 사용자 시나리오를 구축했습니다. 각 기능별 담당 팀은 개발 중간 단계에 합류하여 예외 상황을 보완하고 완성도를 다듬었습니다. 결과적으로 개념 증명 시작 단계부터 완전한 네이티브 앱을 구축해 양대 앱스토어에 정식 출시하기까지 걸린 시간은 단 12주였습니다.
기존 사용자들이 업데이트 과정에서 로그인 상태가 풀리거나 푸시 알림 수신에 실패하지 않도록 사용자 경험(UX) 연속성을 완벽히 보존했습니다. 특히 비즈니스 마케팅과 추천 시스템의 핵심인 분석 데이터 수집 이벤트 구조도 조금의 누락 없이 정교하게 이관되었습니다.
개념 증명 단계부터 완성된 네이티브 앱의 양대 앱스토어 출시까지 소요된 총 기간
놀라운 성능 향상: 스타트업 시간 최대 50% 단축
네이티브 앱으로 완전히 전환한 후 측정된 기술 지표들은 놀라웠습니다. 최적화를 거의 진행하지 않은 첫 번째 릴리스 빌드 상태임에도 성능과 안정성 모두에서 상당한 개선을 보였습니다.
가장 먼저 눈에 띄는 부분은 앱 시작 속도(cold start, 앱을 처음 눌러 홈 화면 콘텐츠가 보일 때까지의 시간)입니다. iOS의 경우 리액트 네이티브 환경의 3,200ms에서 네이티브 전환 후 2,466ms로 약 23% 단축되었고, 안드로이드는 4,433ms에서 2,233ms로 무려 50% 단축되었습니다. 또한 안드로이드 기기(Pixel 기기 기준)에서 화면 피드를 스크롤할 때의 렌더링 프레임이 120FPS(초당 프레임 수)에 안정적으로 도달했습니다.
안정성 측면에서도 비약적인 성장을 거두었습니다. 기존 리액트 네이티브 버전에서 99.5% 이상으로 관리되던 세션 안정성(충돌 없이 유지되는 세션 비율)이 네이티브 앱 출시 이후 99.95% 이상으로 높아졌습니다. 이는 앱 작동 중 크래시(crash, 강제 종료)가 발생하는 세션의 비율이 기존 대비 10분의 1 수준으로 줄어들었음을 의미합니다. 또한 안드로이드 기준 빌드 크기는 293MB에서 184MB로 37.2% 감소하였고, 안드로이드 앱 빌드 시간 역시 약 75% 감소하여 개발 효율을 높였습니다. (iOS 앱 크기는 67MB에서 68MB로 1.5% 소폭 증가에 그쳤습니다.)
AI의 실수를 방지하는 시스템: 'Helix'와 'Tardis'
쇼피파이는 LLM에 단순히 코드를 던져주고 한 번에 전체 기능을 구현하라고 요구하면 반드시 실패한다고 경고합니다. 이 방식은 유지보수가 불가능한 불량 코드를 무더기로 양산하기 때문입니다. 쇼피파이는 이 문제를 극복하기 위해 단계별 검증 프레임워크인 'Helix'를 개발해 도입했습니다.
Helix는 첫 작업물이 정확하다고 가정하지 않는 상호 보완 루프입니다. 개발자가 타겟 화면을 지정하면 Helix가 소스 코드를 분석하고 수 분 안에 리뷰할 수 있는 작은 크기의 연속적인 작업 단위(체크포인트)를 제안합니다. 각 체크포인트가 다음 단계로 넘어가려면 4가지 까다로운 관문을 동시에 통과해야만 합니다.
Helix 검증 통과 조건:
1. 자동화 테스트를 통해 정상 동작을 입증할 것
2. 실행 중인 앱과의 시각적 일치도를 검사할 것
3. 두 명의 가상 적대적 코드 리뷰어(AI) 검토를 통과할 것
4. 최종적으로 사람(엔지니어)의 승인을 받을 것
또한 에이전트가 가상 디바이스(시뮬레이터)를 직접 조작하며 UI 검사를 진행할 때 발생하는 병목과 속도 저하를 막기 위해 자체 디버깅 도구인 'Tardis'를 개발했습니다. 아울러 비즈니스 로직을 UI와 완벽하게 분리하여 터미널(CLI, Command Line Interface) 환경에서 시뮬레이터 없이 밀리초 단위로 결과를 검증하도록 설계했습니다. 에이전트가 직접 터미널 상에서 앱 상태를 확인하고 화면 이동 명령을 수행하며 E2E(End-to-End, 종단 간) 테스트를 수 시간 동안 자율적으로 반복할 수 있게 만든 아키텍처의 혁신입니다.
그래서 우리에게 무슨 의미인가?
쇼피파이의 이번 시도는 기술 생태계에 강력한 질문을 던집니다. 과거 모바일 개발팀들은 생산성(크로스 플랫폼)과 품질(네이티브) 사이에서 어쩔 수 없는 기회비용 타협을 해야 했습니다. 그러나 생성형 AI 에이전트가 일상적인 구현, 번역, 테스트, 1차 리뷰 단계를 전담하게 되면서 플랫폼 개발의 물리적 장벽이 무너지기 시작한 것입니다.
그렇다고 인간 네이티브 개발자의 전문성이 쓸모없어진 것은 아닙니다. 쇼피파이는 에이전트가 생성한 코드가 기능은 구현하더라도 중복 코드, 아키텍처 설계 이탈, 성능 저하 등을 빈번하게 발생시키기 때문에 린팅(linting, 코드 스타일 및 오류 사전 검사), 정적 분석, 꼼꼼한 코드 리뷰와 사람이 결정하는 최종 아키텍처 판단은 여전히 필수적이라고 강조했습니다.
쇼피파이는 300개 이상의 화면과 복잡한 위젯을 포함하고 있는 자사의 가장 거대한 앱인 'Shopify' 앱 또한 네이티브 전환을 진행 중이며 2026년 내로 출시할 예정입니다. 한편, 기존에 쇼피파이가 기여해 왔던 리액트 네이티브 오픈소스 라이브러리인 'React Native Skia'는 2026년 말까지 후원을 유지한 뒤 새 이름으로 분가하며, 대규모 렌더링에 널리 쓰이는 'FlashList'는 다른 기업들로의 장기 유지보수 이관을 논의 중입니다. AI가 인간의 도구 수준을 넘어 개발의 구조와 비용 방정식 자체를 재정의하는 시대가 현실로 다가왔음을 보여주는 이정표적 사례입니다.
댓글
댓글 쓰기