AI가 무너뜨린 ‘두 번 개발’의 비용 - 네이티브앱 개발 트랜드
중년개발자
@loxo
약 4시간 전
AI가 무너뜨린 ‘두 번 개발’의 비용
Shopify가 React Native를 떠나 네이티브로 돌아간 이유
Shopify가 자사의 쇼핑 앱인 Shop 앱을 React Native에서 Swift와 Kotlin 기반의 네이티브 앱으로 전환했다. 핵심 엔지니어 6명이 AI 코딩 에이전트를 활용해 개념 검증부터 앱스토어 출시까지 완료하는 데 걸린 시간은 불과 12주였다.
이 사건의 핵심은 단순히 “네이티브 앱의 성능이 더 좋다”는 데 있지 않다. 더 중요한 변화는 AI가 iOS와 Android를 따로 개발하는 비용을 낮추면서 모바일 기술을 선택하는 경제적 기준 자체가 달라졌다는 것이다.
한 번 개발하기 위해 선택했던 React Native
Shopify는 2020년부터 React Native에 적극적으로 투자했다. Swift로 iOS 앱을 만들고 Kotlin으로 Android 앱을 만들면 같은 기능을 사실상 두 번 개발해야 한다. 반면 React Native는 하나의 코드베이스를 공유할 수 있기 때문에 개발 속도를 높이고 두 플랫폼의 기능 차이를 줄일 수 있었다.
Shopify도 React Native를 통해 상당한 시간과 비용을 절약했다고 인정한다. 모바일 경험이 없는 웹 개발자도 앱 개발에 참여할 수 있었고, iOS와 Android의 기능을 동일하게 유지하기도 쉬웠다.
물론 대가도 있었다. 성능 최적화, 네이티브 모듈 연결, 외부 라이브러리 의존성 관리, 프레임워크 업데이트 대응에 지속적인 투자가 필요했다. 그러나 당시에는 이러한 부담보다 한 번 개발해 두 플랫폼에서 사용하는 이점이 훨씬 컸다.
그런데 AI 코딩 에이전트가 이 계산식을 바꾸기 시작했다.
AI는 코드를 한 번만 쓰게 한 것이 아니라, 두 번 쓰는 비용을 낮췄다
네이티브 개발은 여전히 iOS와 Android 코드를 각각 만들어야 한다. 이 비용이 사라진 것은 아니다. 달라진 점은 AI 에이전트가 한쪽 플랫폼의 구현을 참고해 다른 플랫폼의 코드를 만들고, 테스트하고, 차이를 찾아내는 상당 부분을 맡을 수 있게 됐다는 것이다.
예를 들어 엔지니어가 iOS의 SwiftUI 버전을 완성하면 에이전트는 그 구현과 기존 React Native 코드를 분석해 Android용 Jetpack Compose 버전을 만들 수 있다. 화면 구성뿐 아니라 상태 관리, 내비게이션, 애니메이션, 접근성, 분석 이벤트까지 비교하며 기능을 옮긴다.
과거에는 네이티브 전환이 곧 개발인력과 기간의 증가를 의미했다. 이제는 사람이 두 플랫폼의 모든 코드를 직접 작성하기보다, 사람이 구조와 기준을 정하고 AI가 구현·변환·검증 작업을 병렬로 수행하는 방식이 가능해졌다.
따라서 “AI 때문에 네이티브가 저렴해졌다”는 해석은 대체로 맞다. 다만 더 정확히 말하면, AI가 네이티브 개발의 가장 큰 약점이었던 중복 구현과 기능 동기화 비용을 크게 낮췄다고 해야 한다. Shopify는 구체적인 금액이나 전체 인건비 절감률을 공개하지 않았지만, 코딩 에이전트의 발전이 기술 선택을 다시 검토하게 만든 직접적인 이유라고 밝혔다.
12주 만에 가능했던 이유
Shopify는 처음부터 전체 앱을 무작정 다시 만들지 않았다. 먼저 엔지니어 한 명이 일주일 동안 AI 에이전트와 함께 기존 React Native 앱을 SwiftUI로 얼마나 옮길 수 있는지 시험했다. 결과는 출시 가능한 수준은 아니었지만, 화면과 상호작용, 주요 사용자 흐름을 비슷하게 재현할 수 있다는 가능성을 확인하기에는 충분했다.
이후 핵심 엔지니어 6명이 네이티브 기반 구조와 주요 사용자 여정을 구축했다. 프로젝트 중반부터는 각 기능팀이 참여해 담당 기능과 예외 상황을 검증했다. 따라서 “6명만으로 전체 작업을 끝냈다”기보다는 6명이 전환의 중심을 맡고 기존 기능팀이 검증에 합류한 구조로 이해하는 것이 정확하다.
에이전트에게는 단순히 “React Native 코드를 네이티브로 바꿔 달라”고 지시하지 않았다. Shopify는 기존 앱과 새 앱의 화면, 로그, 상태, 분석 이벤트를 같은 지점에서 비교할 수 있는 도구를 만들었다. 에이전트가 코드를 생성한 뒤 실제 실행 결과를 확인하고, 차이가 발견되면 다시 수정하는 반복 구조를 구축한 것이다.
이 점이 중요하다. 이번 사례는 막연한 ‘바이브 코딩’의 성공이 아니라, 명확한 명세와 작은 작업 단위, 자동화된 테스트, 실행 결과 비교, 전문가의 코드 리뷰가 결합된 AI 개발 시스템의 성공에 가깝다.
성능과 안정성도 개선됐다
Shopify가 공개한 결과에 따르면 앱을 실행해 초기 홈 피드가 나타날 때까지 걸리는 시간은 iOS에서 3,200ms에서 2,466ms로 약 23% 단축됐다. Android는 4,433ms에서 2,233ms로 약 50% 빨라졌다.
충돌 없이 유지되는 세션 비율도 기존 99.5% 이상에서 99.95% 이상으로 높아졌다. 수치상 차이는 0.45%포인트에 불과해 보이지만, 충돌 세션의 관점에서는 약 10분의 1 수준으로 감소한 셈이다.
Android 앱의 배포 크기는 293MB에서 184MB로 109MB 줄었고, Android 릴리스 빌드 시간도 약 75% 단축됐다. 반면 iOS 앱 크기는 67MB에서 68MB로 소폭 증가했고 빌드 시간에도 큰 차이가 없었다. 즉, 모든 지표에서 네이티브가 무조건 우월했다기보다 특히 Android에서 개선 효과가 크게 나타났다. Shopify의 Shop 앱 전환 사례
앞으로의 흐름은 ‘공유 코드’에서 ‘공유 기준’으로
이번 변화가 React Native나 Flutter의 종말을 의미하지는 않는다. 소규모 팀이나 초기 서비스처럼 하나의 코드베이스로 빠르게 제품을 출시해야 하는 환경에서는 여전히 크로스플랫폼 기술이 강력하다. Shopify 역시 React Native가 실패한 선택이 아니었으며, 2020년 당시에는 올바른 결정이었다고 설명한다.
그러나 AI 에이전트가 발전할수록 공유 코드가 제공하던 경제적 우위는 이전보다 작아질 가능성이 크다. 앞으로는 코드를 하나로 합치는 것보다 기능 명세, 디자인 시스템, 테스트, 분석 이벤트, 품질 기준을 공유하고 플랫폼별 구현은 AI가 지원하는 방식이 늘어날 수 있다.
Shopify도 두 플랫폼의 기능 일치를 더 이상 하나의 코드베이스로 강제하지 않는다. 대신 동일한 명세와 테스트, 검토 지점, 릴리스 절차를 통해 일치시킨다. 쉽게 말해 과거에는 “같은 코드를 사용해야 같은 앱이 된다”고 생각했다면, 이제는 “같은 기준으로 검증하면 서로 다른 코드로도 같은 제품을 만들 수 있다”는 접근이다.
AI가 바꾼 것은 개발 속도가 아니라 기술 선택의 자유다
이번 Shopify 사례가 보여주는 가장 큰 변화는 AI가 개발자를 없앴다는 것이 아니다. 생성된 코드에는 여전히 중복, 구조적 이탈, 성능 문제와 유지보수하기 어려운 설계가 생길 수 있다. 이를 발견하려면 Swift와 Kotlin, 모바일 아키텍처를 이해하는 전문가가 필요하다.
AI가 실제로 줄여준 것은 반복 구현과 플랫폼 간 번역에 들어가는 노동이다. 덕분에 개발자는 “두 번 만들어야 하니 어쩔 수 없이 공유 프레임워크를 사용한다”는 제약에서 조금씩 벗어날 수 있게 됐다.
결국 Shopify의 네이티브 복귀는 과거로의 회귀가 아니다. AI가 네이티브 개발의 비용 구조를 바꾸면서 가능해진 새로운 전진이다. 앞으로 기술 스택을 결정하는 기준도 “코드를 몇 번 작성하는가”보다 “AI와 사람이 얼마나 빠르고 정확하게 구현을 검증할 수 있는가”로 이동할 것이다.
Shopify가 보여준 것은 네이티브의 승리라기보다, AI 시대에는 어제의 합리적인 기술 선택도 오늘 다시 계산해야 한다는 사실이다. Shopify의 네이티브 전환 배경