Shopify, 6년 만에 React Native 버리고 네이티브로 전환
Shopify moves back to Native from React Native
Shopify가 2020년부터 올인했던 React Native를 떠나 Swift와 Kotlin 기반 네이티브로 회귀한다. LLM이 코드 구현·번역·테스트를 대신하면서 '두 번 개발' 비용이 더 이상 결정적이지 않아졌기 때문이다. AI 지원으로 Shop 앱은 12주 만에 네이티브로 재출시됐고, 300개 이상 화면의 Shopify 앱도 올해 안에 전환된다. React Native Skia, FlashList 등 오픈소스 라이브러리의 거취도 함께 발표됐다.
우리는 당시 성공적이었다는 이유만으로 결정을 고수하지 않는다. 핵심 가정이 바뀌면, 그것이 여전히 옳은 선택인지 되돌아볼 의향이 있다.
HN 토론
412- Waterluvian
앱이 필요하거나 앱을 가진 모든 회사를 스펙트럼 위에 올려놓으면, 어딘가에 이들을 대략 두 그룹으로 나누는 선이 있습니다: Electron/React Native 등이 말이 되는 쪽과 그렇지 않은 쪽이죠. 이건 그냥 평범한 엔지니어링 결정입니다: 한정된 자원으로 문제를 해결하는 것. 회사마다 문제도 다르고 자원도 다릅니다.
저는 기술 커뮤니티 사람들이 이 도구들의 좋고 나쁨에 대해 절대적인 의견을 갖는 게 꽤 인기 있다는 것도 아마 눈치챘을 거라고 생각합니다. 무지에서 비롯된 마법 같은 사고방식이 있죠 — 모두가 그냥 네이티브로 가야 한다거나, React Native가 어디에나 쓰이는 최고의 것이라거나, AI가 이 선을 완전히 없애준다거나 하는 식의.
저는 이런 주장들이 별 가치가 없고, 흥미로운 점, 그리고 이 글의 부제가 말하는 것 — 즉 AI 때문에 이 선이 움직이고 있다는 점 — 에서 주의를 분산시킨다고 봅니다. 그리고 그건 아마 맞는 말인 것 같습니다.
- tonic_note
모델들이 네이티브 iOS 앱을 생성하는 능력이 훨씬 좋아졌습니다. RN의 주된 매력은 웹 개발자를 모바일 개발에 활용할 수 있다는 점이었죠. 제가 지난 회사에서 했던 것도 그겁니다. 그리고 스타트업에는 그걸로 충분하지만, 결국에는 전담 네이티브 엔지니어를 원하게 됩니다. 각 플랫폼은 정말로 그 플랫폼을 위해 최적화할 수 있는 자기만의 기술 전문가를 가질 자격이 있으니까요.
하지만 이제 모든 코드가 생성되는 시대에는 RN 앱을 유지할 이유가 거의 없습니다... 그냥 네이티브로 시작하세요. 어차피 개발자들이 코드를 직접 작성할 일은 거의 없을 테니까요.
- atonse
우리도 같은 걸 했습니다 - 하룻밤 사이에 90%를 해냈죠. 그 다음 며칠 동안은 백그라운드에서 다듬고 폴리싱하는 데 썼습니다.
우리 앱은 더 작고, 화면이 15~20개 정도 됩니다. 새벽 12시 30분쯤 codex에게 목표를 주고 시작했더니, React Native 코드를 기반으로 모든 화면을 목록화하고, android와 iOS 디렉터리를 만들고, maestro를 사용해서 (몇 주 전 개인 앱 빌드 때 이미 이 툴링을 설정해둔 상태였습니다), 아침에는 android와 iOS에서 전부 작동하게 만들었습니다. 제가 잠든 동안 약 6시간 걸렸죠.
앱은 훨씬 작고, 즉시 실행되며, android 앱은 (아마도) 네이티브처럼 보입니다. '아마도'라고 한 이유는 저는 android 폰을 쓰지 않기 때문입니다. 하지만 Jetpack Compose와 Kotlin을 사용하고 있습니다.
그리고 저는 Swift나 Kotlin을 모릅니다. 솔직히 이제 React Native의 존재 의의를 모르겠습니다. Expo가 아주 멋진 에이전트 관련 작업을 하고 있다는 건 알지만, 네이티브 앱을 작성할 수 있는데 그게 왜 필요한지 잘 모르겠습니다.
- pkaler
저는 Cordova Street이 내려다보이는 책상에 앉아 있습니다. Apache Cordova의 이름을 딴 그 거리죠. 이 논쟁을 거의 20년째 보고 있습니다.
팀들은 최신 크로스 플랫폼 프레임워크에 뛰어들면서, 각 플랫폼에서 최소 공통 분모 수준의 앱을 갖게 되는 대신 인건비를 줄일 수 있을 거라고 가정합니다.
후자는 사실이지만 전자는 거짓입니다.
결국 벌어지는 일은, 팀이 iOS 엔지니어 20명과 Android 엔지니어 20명으로 시작한다는 겁니다. 그들이 React Native 같은 걸 도입하죠. 그러면 결국 프로덕트 엔지니어 20명과 툴링 및 프레임워크 엔지니어 20명의 팀이 됩니다.
지난 20년 동안 그런 걸 수도 없이 봤습니다.
- fnthawar2
우리는 당시에 성공적이었다는 이유만으로 결정을 고수하지 않습니다. 핵심 가정이 바뀌면, 기꺼이 돌아가서 여전히 올바른 선택인지 물어봅니다. LLM이 2020년 결정의 핵심 가정 중 하나를 바꿔놓았기 때문에, 우리는 모바일 스택을 제1원리부터 재평가했습니다.
우리가 찾은 결과는 우리를 다시 네이티브로 이끌었습니다.
- netshade
저는 사람들에게 React Native에서 벗어나라고 권하는 데 동의합니다만, 'LLM이 아니었으면 고려하기엔 너무 비쌌을 마이그레이션을 가능하게 했다'는 이야기는 맞지 않다고 생각합니다.
제가 이렇게 말하는 이유는, 중간 규모의 React Native 앱을 Swift/Kotlin 네이티브 앱으로 재작성하는 마이그레이션에 참여했기 때문입니다. 기술 작업의 대부분을 제가 했습니다. 작업 대부분은 2026년 1월 이전에, LLM 코드 지원 없이 이루어졌습니다. 물론 이후 기능들에서는 일부 사용했습니다.
이걸 고려하는 분들에게 말하자면, LLM 지원을 고려하지 않고서도 이 마이그레이션은 충분히 고려할 가치가 있습니다. 불필요하게 어려운 업그레이드, 기반 핵심 프레임워크와의 임피던스 미스매치, 믿을 수 없을 정도로 들쭉날쭉한 라이브러리 품질이라는 React Native의 지속적인 세금 때문에, 비즈니스는 기술을 결승선까지 끌고 가는 데 정말 많은 시간을 써야 합니다. '빌드하고, 컴파일하고, 출시하고, 확신하라'는 세계로 돌아온 건 정말 멋집니다. Shopify 글이 '이해하고 있다'고 생각하는 근본 원칙 중 하나는 피드백 사이클의 중요성입니다 - 초기에 통합 테스트 체계에 시간을 투자한 것이 제 사이클 타임에도 도움이 되었고, 나중에는 LLM 지원을 위한 가드레일을 제공하는 데도 도움이 되었습니다.
요컨대, 이 결정은 LLM 지원을 고려하지 않고서도 충분히 고려할 가치가 있습니다.
- lmf4lol
어제 잠들기 직전에, 저는 Astra를 우리 Electron 데스크톱 앱에 겨누고, iOS용 네이티브 Swift 앱을 작성해달라고 요청했습니다.
그 Electron 앱에는 750개의 단위 테스트와 50개 정도의 통합 테스트가 있습니다. 또한 mcp를 통해 Electron 앱에 접근할 수 있었고, 이리저리 클릭하며 검사할 수 있었습니다. 백엔드 코드에는 Astra에게 읽기 전용 접근 권한도 줬습니다.
3시간 동안 작업하더니 거의 기능이 완전한 포팅을 내놓았습니다. 오늘 수동 테스트에서 버그 3개와 성능 문제 1개를 발견했는데, 모두 나중에 고쳤습니다. 성능 문제를 해결하기 위해 여러 가지 빌드를 만들고 Xcode로 프로파일링까지 했습니다.
12시 30분쯤에는 우리 제품의 완전한 네이티브 앱 포팅을 iPhone과 iPad에서 실행하고 팀에 보여줄 수 있었습니다. 심지어 세로/가로 모드도 정확히 처리했습니다!
말할 필요도 없이, 저는 어안이 벙벙했습니다. 한편으로는 좋습니다, 이제 그 모든 멋진 것들을 만들 수 있으니까요. 하지만 다른 한편으로는, 제 기술이 완전히 가치 절하된 것입니다. 저는 스스로에게 여전히 제가 적절한 환경을 설정한 사람이고 아무나 할 수 있는 건 아니라고 말하곤 합니다. 하지만 그건 자기합리화입니다. 빌어먹을 자기합리화... 그리고 그걸 압니다.
- underdeserver
그리고 저는 여기 앉아서 Codex 데스크톱 mac 앱을 보며, 목록 하나, 채팅 창 하나, 텍스트 상자 하나에 왜 579MB(압축) 다운로드와 4GB RAM이 필요한지 의아해하고 있습니다.
- jrochkind1
시뮬레이터에 관한 부분은 잘 따라가지 못하겠습니다. 아마 제가 실제로 모바일 개발을 해본 적이 없어서일 겁니다.
> 시뮬레이터 상호작용이 필요할 때, CLI는 원격 모드로 연결하여 레이아웃이나 접근성 트리를 검사할 필요 없이 명령으로 UI를 구동할 수 있습니다. 이를 통해 매우 빠른 성능과 E2E 테스트가 가능합니다.
이해가 안 되는 것 같습니다. 사용자가 실제로 상호작용할 레이어에서 접근성 트리와 레이아웃을 여전히 테스트해야 하지 않나요?
- asimovDev
다음엔 React를 버리고 순수 JavaScript로 돌아갈 건가요?
저는 아직도 React 이전의 GitHub를 애도하고 있습니다. 장밋빛 안경일지도 모르지만, 정말 쓰기 즐거웠거든요