2025년 1월, Shopify의 Mustafa Ali는 회사 엔지니어링 블로그에 React Native의 앞날이 밝고 Shopify는 계속 투자하겠다고 썼어요. 1년 8개월 뒤인 2026년 9월 10일, 그는 같은 블로그에 Shopify의 모바일 앱을 전부 React Native에서 Swift와 Kotlin으로 옮기겠다는 글을 올렸어요.
Shopify는 온라인 쇼핑몰을 열고 운영하는 플랫폼 회사예요. React Native는 Meta가 만든 개발 도구로, 앱 코드를 한 번 쓰면 iOS와 안드로이드 양쪽에서 돌아가게 해 줘요. Swift는 iOS 앱을, Kotlin은 안드로이드 앱을 만드는 전용 언어이고요. 앞으로는 같은 기능을 iOS용과 안드로이드용으로 한 번씩, 모두 두 번 짜겠다는 뜻이에요.
Shopify가 든 이유는 하나였어요. 코딩 모델이 크게 좋아지면서, 같은 기능을 Swift와 Kotlin으로 두 번 만드는 일이 예전만큼 비싸지 않게 됐어요. Shopify는 이 변화를 두고 "LLM이 2020년 결정의 핵심 전제 하나를 바꿨다"고 썼어요.
2020년에 Shopify는 iOS 앱과 안드로이드 앱을 한 코드로 만들기로 했어요
Shopify가 2020년에 React Native를 전면 도입한 이유는 셋이었어요. 같은 기능을 두 번 만들지 않는 것, 모바일 경험이 없는 개발자도 앱 개발에 참여하게 하는 것, 두 앱의 기능을 똑같이 맞추는 데 드는 시간을 줄이는 것이었어요.
Shopify는 세 가지를 모두 얻었다고 적었어요. 기능을 한 번만 만들어 시간을 크게 아꼈고, 모바일 경험이 없는 개발자도 앱에 기여했고, 두 앱의 기능을 맞추는 데 시간을 덜 쓰게 됐다고요. 성능을 다듬고 프레임워크 업데이트를 따라가는 데 적지 않은 품이 들었지만, 얻은 것이 더 컸다고 했어요. Shopify가 뒤집은 것은 실패한 결정이 아니라 성공한 결정이었어요.
성능 때문에 네이티브로 옮기는 것도 아니었어요. Shopify는 "React Native 앱도 빠를 수 있고, 우리 앱도 빠르다"고 분명히 했어요. 네이티브로 옮기는 이유는 에이전트 때문에 한 코드를 두 플랫폼이 나눠 쓰는 이점은 줄었는데, 플랫폼마다 따로 만드는 이점은 그대로 남았기 때문이라고 했어요. 따로 만들면 애플과 구글이 제공하는 플랫폼 기능과 공식 개발 도구를 더 직접 쓸 수 있고, 코드와 플랫폼 사이에 끼는 프레임워크와 의존 라이브러리도 줄어들어요.
엔지니어 한 명이 일주일 동안 에이전트와 함께 Shop 앱을 iOS 코드로 옮겨 봤어요
처음 네이티브로 옮긴 앱은 Shop이에요. 쇼핑하는 사람이 주문을 추적하고 결제하는 Shopify의 소비자용 앱이고, 앱 스토어 쇼핑 분야 상위권에 자주 올라요. 이 앱은 마침 React Native의 새 구조로 넘어가는 큰 작업을 앞두고 있었어요. 그 작업에 비용을 쓰기 전에, Shopify는 코딩 에이전트와 함께 iOS와 안드로이드 전용 코드로 바로 다시 만들 수 있는지부터 시험했어요.
엔지니어 한 명이 일주일 동안 에이전트와 함께, 기존 React Native 앱을 참고해 옮길 수 있는 만큼의 기능을 iOS 앱으로 옮겼어요. 일주일 만에 출시할 수준이 되지는 않았지만, 기능 하나하나를 iOS 앱으로 그대로 옮기는 일이 가능하다는 건 확인했어요. 에이전트가 특히 잘한 건 참고할 기존 구현이 있을 때였어요. 이미 있는 기능을 새 코드로 옮기고, 화면의 기본 구조를 만들고, 데이터를 연결하고, 애니메이션을 넣고, 화면을 보며 배치를 다듬었어요.
본 작업은 핵심 인원 여섯 명이 맡았어요. 이들이 앱의 기반과 주요 사용 흐름을 만들었고, 기능별 팀이 중간에 합류해 자기 영역을 검증하고 빠진 예외 상황을 채웠어요. 기존 사용자에게는 평범한 업데이트처럼 느껴져야 했어요. 로그인이 풀리면 안 되고 푸시 알림도 그대로 와야 했죠. 추천 시스템처럼 앱이 보내는 이벤트를 받아 쓰는 다른 시스템이 있어서, 분석 이벤트도 예전과 같은 내용으로 나가야 했고요. 그러면서 일부 화면은 일부러 없애고 일부는 단순하게 정리했어요. Shopify는 개념 검증에서 앱 스토어 출시까지 12주가 걸렸다고 밝혔어요.
2020년에 한 코드 방식을 고른 두 번째 이유는, 모바일 경험이 없는 개발자도 앱 개발에 참여하게 하려는 것이었어요. 이번에는 한 코드가 없어도 개발자들이 두 플랫폼 개발에 참여할 수 있었어요. React Native 개발자들이 iOS와 안드로이드의 화면 도구인 SwiftUI와 Jetpack Compose에 예상보다 쉽게 적응했다고 해요. 화면을 선언하는 방식이 React와 닮았고, 에이전트가 자기 주력 분야가 아닌 플랫폼에서도 개발자가 빨리 익숙해져 기여하도록 도왔다고요. 그래도 네이티브 전문가는 계속 필요했어요. 생성된 코드는 기능 요구는 채우면서도 중복이나 설계에서 벗어난 구조, 성능 문제를 들여올 수 있었다고 Shopify는 적었어요.
앱 전체를 네이티브 코드로 한 번에 옮기라고 시키면, 출시할 수 없는 코드가 잔뜩 나왔어요
Shopify는 가장 쉬워 보이는 방법부터 경계했어요. 에이전트에게 React Native 코드를 통째로 주고 네이티브로 한 번에 다시 짜게 하는 방법이에요. 처음에 정보를 최대한 모아 명세와 작업 파일로 정리한 다음 구현하게 해도, 유지보수할 수 없는 코드가 대량으로 나와 출시할 수가 없었다고 해요.
그래서 가장 큰 앱인 Shopify 앱을 네이티브로 옮기려고 Helix라는 사내 도구를 만들었어요. Helix는 첫 결과물이 맞을 거라고 기대하지 않아요. 엔지니어가 화면 하나를 고르면 Helix가 그 화면을 작은 단계 여러 개로 나눠 순서를 제안하고, 엔지니어는 그 순서를 몇 분 안에 검토해 승인해요. 첫 단계는 보통 화면의 기본 구조이고, 뒤로 갈수록 범위가 넓어져요. 단계마다 설명을 몇 단어로 짧게 두는 것도 일부러 고른 방식이에요. Helix 글은 "생성된 긴 글을 제대로 검토할 수 있는 사람은 없다"고 적었어요.
각 단계는 네 관문을 차례로 통과해야 커밋되고, 그래야 다음 단계가 시작돼요.
- 동작 테스트
옛 React Native 코드를 읽어 단계마다 만든 테스트 중 해당하는 것을 전부 통과해야 해요. - 화면 비교
새 앱과 옛 앱을 같은 상태에서 캡처해 Gemini에게 꼼꼼한 디자인 검수자 역할을 맡기고, 차이를 화면 위치와 심각도까지 전부 적게 해요. 코드로 고칠 수 있는 차이가 있으면 기본적으로 다음 단계로 넘어가지 못해요. - 흠을 찾는 코드 리뷰 둘
맥락을 서로 공유하지 않는 리뷰 에이전트 두 개가, Shopify가 문서로 정해 둔 앱 구조 기준에 맞는지 봐요. 지적은 전부 고쳐야 하고, 둘 다 승인할 때까지 반복해요. - 엔지니어 승인
엔지니어가 코드와 실행 중인 앱을 보고 판단해요. 이 피드백은 기록돼 다음 단계에 반영되고, 승인된 결과가 쌓일수록 사람 손을 덜 거치고 진행할 수 있어요.
관문은 조언이 아니라 통과 조건이에요. 떨어지면 에이전트가 피드백을 보고 고친 뒤 다시 시험을 받아요. 몇 번이든 다시 할 수 있지만, 결과가 충분히 좋다고 스스로 판단해 넘어갈 수는 없어요. Helix 글은 이 방식을 "시도는 틀려도 된다. 틀리지 않게 될 때까지 출시되지 않을 뿐이다"라고 요약했어요.
코드를 두 벌로 늘린 것은 복잡도를 두 배로 늘린 것이라는 반론도 커요
이 발표는 Hacker News에서 1,200점 넘게 받았고 댓글이 900개 넘게 달렸어요. 반론도 많았어요. AI가 있으니 복잡도가 공짜라고 착각한 함정이라는 댓글이 있었고, 그 댓글은 AI도 사람처럼 복잡한 코드 앞에서 헤맨다고 덧붙였어요. 쇼핑 앱에 기술적인 이유도 없이 같은 것을 두 번 만든다는 비판도 있었고요. React Native처럼 한 코드로 여러 플랫폼 앱을 만드는 도구를 직접 만드는 한 개발자는, 비용이 더 들어서 몇 년 안에 다시 공통 도구 쪽으로 돌아올 거라고 내다봤어요. 그가 경쟁 도구를 만드는 사람이라는 점도 함께 봐야 해요.
엔지니어가 많은 큰 회사라서 할 수 있는 선택이라는 반론도 있었어요. Shop 앱은 여섯 명이 중심이 돼 네이티브로 옮겼지만, 그 뒤에는 기능별 팀과 에이전트용 사내 도구를 따로 만든 사람들이 있었어요. Shopify가 AI를 유난히 앞세워 온 회사라는 점도 있어요. CEO Tobi Lütke는 2025년 4월 "AI를 반사적으로 쓰는 것이 Shopify의 기본 기대치"라는 사내 메모를 직접 공개했고, 이번 글에도 챗GPT가 나오기 한 해 전인 2021년부터 LLM으로 소프트웨어를 만들어 왔다고 적었어요. 발표 글과 Helix 글은 모바일·AI 엔지니어 채용 안내로 끝나요.
가장 큰 앱은 아직 네이티브로 옮기는 중이에요. 화면이 300개가 넘고 홈 화면 위젯과 애플워치 앱까지 딸린 Shopify 앱이고, Shopify는 올해 안에 내놓겠다고 했어요.
두 앱의 기능을 똑같이 맞추는 일은, 에이전트가 줄여 주지 않았어요
한 코드로 만들던 시절에는 두 앱의 기능이 저절로 같았어요. 같은 코드가 양쪽에서 돌았으니까요. Shopify는 Shop 앱을 네이티브로 옮긴 뒤에도 "iOS와 안드로이드는 언제나 기능이 같아야 한다"는 원칙을 그대로 뒀어요. 그리고 예전에는 공유 코드가 지켜 주던 이 원칙을, 이제는 개발과 출시 절차로 지키겠다고 적었어요.
그 절차의 중심에는 확인이 있어요. 에이전트가 고친 앱이 제대로 도는지 보려면, 시뮬레이터 안에서 앱의 상태를 화면 구조 정보나 스크린샷으로 읽어 내야 해요. Shopify는 "모델이 아무리 좋아도 자기 작업을 빨리 확인하지 못하면 소용없다"고 썼어요. 그래서 앱의 동작을 화면과 떼어 내 명령줄에서 바로 부를 수 있도록 앱 구조를 바꾸고 있어요.
Shopify에 따르면 에이전트는 코드를 고치는 데 몇 초, 그 결과를 확인하는 데는 몇 분이 걸려요.
2020년에 Shopify는 코드를 하나로 합쳐, 짜고 관리할 코드의 양을 줄이는 데 집중했어요. 코드를 짜고 고치는 일을 에이전트에게 맡길 수 있게 된 지금, Shopify가 집중하는 건 코드의 양이 아니라 AI가 만든 결과를 확인하는 시간이에요.
더 깊이 파고 싶다면
