AI가 React Native를 끝냈을까?

URL: https://www.youtube.com/watch?v=oPZLPUtmROo 날짜: 2026-09-15 채널: t3dotgg 원문 제목: Did AI Kill React Native?

---

📌 핵심 질문 / 이 영상이 다루는 핵심 논점

==AI 에이전트가 Swift·Kotlin 구현과 플랫폼 간 이식·테스트 비용을 낮추면서 React Native의 핵심 선택 이유를 약화했지만, OTA(Over-the-Air) 업데이트와 Meta가 축적한 네이티브 품질은 여전히 React Native를 강력하게 만든다.==

• Shopify는 2020년 React Native로 전환해 기능을 한 번만 만들고, 모바일 경험이 없던 개발자도 앱에 기여하게 하며, 플랫폼 간 기능 격차를 쫓는 시간을 줄였다.
• 2021년부터 사용한 LLM 에이전트가 2025년 말에는 Swift와 Kotlin의 구현·번역·테스트·리뷰 상당 부분을 맡을 만큼 좋아져, 두 플랫폼을 따로 만든다고 일이 두 배가 되지는 않게 됐다.
• React Native는 웹뷰가 아니라 JavaScript가 실제 네이티브 컴포넌트를 지시하는 명령 계층이며, OTA로 JavaScript 번들을 교체해 작은 수정과 긴급 버그 수정을 앱스토어 심사 없이 배포할 수 있다.
• Shopify의 판단은 React Native가 느리거나 나쁜 기술이라는 선언이 아니라, 에이전트 시대에 네이티브의 비용·플랫폼 접근성·일류 도구의 이점이 커졌다는 재평가다.
• 팀 규모, Expo 도입 정도, 새 아키텍처 전환 여부, 네이티브 전문성, 제품이 요구하는 업데이트 방식에 따라 최적의 선택이 달라진다.

1. Shopify 전환이 React Native 생태계에 던진 질문

React Native의 대표적 성공 사례였던 Shopify가 네이티브 코드로 돌아가면서, 프레임워크의 실패가 아니라 비용 구조의 변화가 핵심 쟁점이 됐다.

1.1. 과거의 React Native 방어와 Shopify의 성과

1. Airbnb 논쟁과 React Native 옹호

   1. Airbnb가 React Native에서 이탈한 이유를 정리한 오래된 글은 수년 동안 React Native 도입을 가로막는 강력한 근거로 사용됐다.
   2. 과거 글의 주장 가운데 일부는 5년 이상 지나면서 더 이상 유지되지 않았고, Airbnb는 글을 업데이트해 그 점을 인정했으며 상단에 t3dotgg의 반박 영상을 링크하기도 했다.
   3. Twitch에서 React Native를 실제로 이점이 있는 영역에 도입하려 했을 때 Airbnb 글 때문에 기술을 진지하게 받아들이게 만들기 매우 어려웠다.

2. Shopify가 보여준 반전

   1. Shopify는 React Native로 전환한 뒤 기대보다 좋은 성능을 얻었고, 일부 영역에서는 네이티브 버전보다도 빠른 결과를 냈다.
   2. 특히 Shopify의 판매시점관리(Point of Sale) 시스템 Android 앱은 기존 네이티브 버전을 자주 앞섰다.
   3. Shopify의 투자는 React Native 성장과 성공에 크게 기여했기 때문에, Shopify의 이탈 발표가 생태계에 큰 충격이 됐다.

3. 새로운 발표

   1. Shopify는 모바일의 미래를 네이티브로 규정하고 React Native에서 Swift와 Kotlin으로 이동하겠다고 발표했다.
   2. 발표 글과 후속 커뮤니케이션이 공개된 뒤 관련 논쟁이 폭발했고, T3 Code에서 React Native와 네이티브를 모두 만들고 있는 경험이 논점을 직접 검증할 재료가 됐다.
   3. Meta 내부에서 진행 중인 변화까지 겹치면서, Shopify의 선택은 단순한 회사별 마이그레이션이 아니라 React Native의 미래에 대한 질문이 됐다.

1.2. 2020년 선택이 합리적이었던 이유

1. React Native 전환의 목표

   1. 같은 기능을 iOS와 Android에 두 번 만들지 않는 것이 가장 직접적인 목표였다.
   2. 모바일 전문성이 없던 개발자도 앱에 기여할 수 있게 하고, 두 플랫폼 사이의 기능 격차를 맞추는 일보다 가치 있는 기능을 출시하는 데 시간을 쓰려 했다.
   3. React Native는 이 이점을 꾸준히 제공했고, 성능 최적화·기반 영역 개선·프레임워크 및 외부 의존성 업데이트에 드는 비용은 감수할 만한 절충이었다.

2. 2025년까지의 평가 변화

   1. 2025년 1월 Shopify의 Mustafa Ali는 Shopify에서 React Native를 5년 사용한 경험을 정리하며 React Native의 미래가 밝고 계속 투자할 계획이라고 썼다.
   2. 당시 React Native는 Shopify 앱에서 잘 작동했고 지금도 훌륭한 프레임워크라는 평가는 유지된다.
   3. 그러나 그 뒤 코딩 모델이 급격히 좋아져 Swift와 Kotlin으로 같은 기능을 만드는 비용이 과거만큼 크지 않게 됐다.
   4. Shopify는 과거 결정이 성공적이었다는 이유만으로 붙잡지 않고, 핵심 가정이 바뀌면 처음부터 모바일 스택을 다시 평가하는 방식을 택했다.

3. LLM 사용의 누적

   1. Shopify는 2021년부터 LLM을 사용했으며, ChatGPT가 나오기 1년 전부터 소프트웨어 제작에 활용했다.
   2. 초기에는 기능 구현, 버그 조사와 수정, 코드 리뷰에 썼고 모델이 좋아질수록 맡기는 작업의 복잡도를 높였다.
   3. 2025년 말에는 LLM이 코드를 더 빨리 쓰게 하는 도구를 넘어, 소프트웨어를 두 번 만든다는 말이 정말 두 배의 작업을 뜻하는지 의심하게 할 정도가 됐다.

1.3. Shopify의 실험과 결론

1. 네이티브 프로토타입

   1. Shopify는 모바일 기술 스택을 재평가하기 위해 가장 큰 앱의 핵심 부분을 Swift와 Kotlin으로 다시 만들었다.
   2. 에이전트는 iOS 구현을 참고해 Android 기능을 만들거나 Android 구현을 참고해 iOS 기능을 만드는 식으로 양방향 이식을 수행했다.
   3. 개발자는 주력 스택 밖에서도 에이전트의 도움으로 빠르게 적응하고 기여할 수 있었다.
   4. 공유 명세, 테스트, 리뷰 체크포인트를 통해 두 플랫폼의 동작 일치를 유지하는 비용도 크게 줄었다.

2. 줄어든 이점과 남은 이점

   1. 네이티브는 여전히 두 플랫폼용 소프트웨어를 만들고 유지해야 하므로 비용 자체가 사라진 것은 아니다.
   2. 달라진 점은 에이전트가 구현·플랫폼 간 번역·테스트·리뷰의 상당 부분을 담당해 두 번 만드는 비용이 2020년만큼 결정적인 요소가 아니라는 것이다.
   3. 에이전트는 공유 구현의 이점을 줄였지만, 각 플랫폼에 맞게 만드는 네이티브의 장점은 남겼다.
   4. 네이티브 코드는 플랫폼 기능과 자사 도구에 더 가깝고, 앱 코드와 플랫폼 사이에 프레임워크와 의존성 계층이 적다.

3. 갈색지대와 그린필드의 선택

   1. Shopify는 과거 React Native로 옮길 때 대형 앱을 점진적으로 섞어가는 brownfield 방식으로 전환했다.
   2. 앱을 처음부터 다시 쓰면 수년이 걸리고 그동안 새 기능 출시를 멈춰야 했기 때문이다.
   3. 이번에는 LLM, 깨끗한 상태에서 시작하는 이점, 에이전트 프로토타입의 성공을 합쳐 greenfield 재구축이 가능하다고 판단했다.
   4. Shopify는 점진적 전환보다 처음부터 다시 만드는 방식이 실제 승자라고 결론 내렸다.

4. Shop 앱과 Shopify 앱의 규모

   1. 쇼핑 카테고리 상위권에 자주 오르는 Shop 앱은 AI 지원으로 개념증명(Proof of Concept)에서 앱스토어에 게시된 완성 앱까지 12주 만에 도달했다.
   2. Shopify 앱 자체의 마이그레이션도 진행 중이며 300개 화면, 홈·잠금화면 위젯, Apple Watch 앱, 컴플리케이션(Complication), Siri Shortcuts 등을 포함한다.
   3. Shopify 앱의 네이티브 버전은 그해 말 출시될 예정으로 제시됐다.

2. AI 시대의 네이티브 재구축 방식

대형 코드베이스를 한 번에 번역하는 프롬프트보다, 검증 가능한 작은 체크포인트와 빠른 피드백 루프가 에이전트 기반 마이그레이션의 핵심이 됐다.

2.1. Helix의 단계적 검증 루프

1. 원샷 변환의 실패

   1. React Native 코드베이스를 LLM에 주고 같은 기능을 네이티브로 한 번에 만들라고 하면 제대로 작동하지 않는다.
   2. 사전에 정보를 모두 모아 명세와 작업 파일로 얼려도, 유지보수할 수 없고 출시할 수 없는 거대한 코드가 나오기 쉽다.
   3. 문제는 첫 번째 출력이 정답일 것이라는 기대에 있다.

2. Helix가 만든 체크포인트

   1. Shopify는 화면 하나를 Helix에 지정하고, Helix가 React Native 코드를 읽어 검토 가능한 변환 순서를 제안하게 했다.
   2. 각 체크포인트는 몇 분 안에 검토할 수 있을 정도로 작게 나뉜다.
   3. 단계별 결과는 실제 실행 앱과 일치하는 테스트로 동작을 증명하고, 시각적 리뷰를 거친다.
   4. 두 차례의 적대적 코드 리뷰(Adversarial Code Review)를 통과하고 사람이 승인해야 다음 단계로 넘어가며 커밋된다.

3. Helix에 대한 비판적 평가

   1. 기존 구현을 필요 이상으로 독창적인 전함처럼 숭배해, 기존 개발자들이 변환을 받아들이도록 기존 코드의 중요성을 과장하는 방식처럼 보일 수 있다.
   2. 실제로는 기존 앱을 점진적으로 보존하는 것보다 제품의 의도를 새 구조로 옮기는 편이 더 단순할 수 있다.
   3. Helix는 품질을 보장하는 통제 장치이지만, 기존 코드베이스를 지나치게 신성시하는 조직 문화를 드러내는 장치이기도 하다.

2.2. 에이전트가 겪는 모바일 시뮬레이터의 병목

1. 느리고 불안정한 자동화

   1. Shopify는 에이전트가 버그를 재현하고 고치고 수정 결과를 자율적으로 검증하도록 자체 도구를 만들었지만, 속도가 느리고 취약했다.
   2. React Native의 Hot Module Reloading은 상황을 개선했지만, 시뮬레이터 제어가 느려 근본 문제를 해결하지 못했다.
   3. 에이전트는 접근성 트리나 스크린샷으로 앱 상태를 파악하고, 동작을 실행하고, 결과를 다시 확인해야 했다.
   4. 모델이 아무리 좋아도 작업을 빠르게 테스트할 수 없으면 생산성이 나오지 않으며, 모바일은 특히 이 문제가 심하다.

2. 헤드리스 아키텍처

   1. Shopify는 사람과 에이전트 모두가 작업하기 쉽도록 앱 아키텍처를 다시 설계했다.
   2. 비즈니스 로직을 UI와 완전히 분리하고 데스크톱에서 헤드리스로 실행할 수 있게 했다.
   3. 에이전트가 CLI를 통해 UI 없이 상태를 검사하고 동작을 실행하게 해, 반복 주기를 분 단위에서 밀리초 단위로 줄이려 했다.
   4. 실제로 주로 CRUD 앱의 API와 데이터 계층을 헤드리스로 만들려는 접근이며, 이를 위해 상당한 엔지니어링을 추가했다.

3. CLI와 원격 시뮬레이터

   1. CLI는 에이전트가 UI를 직접 만지지 않고도 앱 상태를 조회하고 섹션 사이를 이동하며 동작을 수행하게 한다.
   2. 시뮬레이터 상호작용이 필요한 경우 원격 모드로 연결해 레이아웃이나 접근성 트리를 검사하지 않고 명령으로 UI를 구동한다.
   3. 이 설계는 검증 속도를 높이지만, Expo가 제공하는 기능을 충분히 사용했다면 필요성이 상당히 줄었을 복잡한 자체 구축으로 평가된다.

3. React Native가 여전히 제공하는 실제 이점

React Native의 본질적 강점은 단순한 “한 번 작성해 어디서나 실행”이 아니라, 네이티브 UI를 유지하면서 JavaScript로 변경 가능한 동작을 배포하는 데 있다.

3.1. OTA 업데이트와 앱 버전 파편화

1. OTA의 의미

   1. OTA는 Over-the-Air Update의 약자로, 앱스토어 새 바이너리 없이 JavaScript 번들을 내려받아 앱 동작을 바꾸는 방식이다.
   2. Apple과 Google은 모든 새 기능을 공식 심사로 보내길 원하므로 OTA로 새 기능을 몰래 배포하는 것은 정책상 민감하지만, 버그 수정과 기능 on/off에는 널리 자리 잡았다.

2. 작은 팀의 iPhone mini 사례

   1. 두세 명으로 구성된 팀이 메뉴에 새 버튼을 추가하고 자신의 휴대폰과 TestFlight에서 문제없이 확인한 뒤 출시할 수 있다.
   2. 그러나 중요한 고객이 iPhone mini 사용자라면 작은 화면에서 버튼이 잘려 보이지 않을 수 있다.
   3. 순수 네이티브 앱이라면 변경을 되돌려 출시를 취소하거나, 이미 깨진 버전을 받은 사용자의 지원 비용을 감수하거나, Apple 심사를 기다려 수정 버전을 내야 한다.
   4. React Native라면 JavaScript 번들을 고쳐 OTA로 바로 배포해 버튼을 고치고, 필요하면 같은 방식으로 기능을 끌 수 있다.

3. 버전 파편화의 실제 비용

   1. Twitch에서 관찰한 수치로는 어느 시점이든 사용자의 절반 이상이 최소 두 버전 이상 오래된 앱을 사용했다.
   2. 개인 휴대폰에서 업데이트가 없다고 표시된 뒤 새로고침하자 실제로 54개 앱 업데이트가 나타났으며, 설치된 앱 54개가 오래된 상태였다.
   3. 개발팀은 순방향·역방향 호환성, 서버와 지원팀의 여러 버전 대응을 동시에 관리해야 한다.
   4. 버그를 한 시간 만에 고쳐도 사용자가 업데이트하지 않으면 수개월 또는 수년 동안 같은 버그 신고가 들어올 수 있다.
   5. Apple은 승인 직후 모든 사용자에게 새 버전을 밀지 않고 때로 수주에 걸쳐 천천히 배포한다.
   6. 따라서 iOS와 Android에는 하나의 앱이 아니라 사용자가 설치한 모든 버전이 공존하며, 강제 폐기 체계가 없으면 개발자가 앱 안에 “앱스토어에서 최신 버전을 설치하라”는 팝업을 넣어야 한다.

3.2. React Native의 주방과 셰프 비유

1. 네이티브와의 관계

   1. React Native는 웹뷰나 네이티브의 대체물이 아니며, 실제로 네이티브 요소를 렌더링하도록 지시하는 명령 계층이다.
   2. 숙련된 셰프가 있는 주방에 무엇을 요리할지 전달하면 셰프가 빠르게 요리하는 상황이 네이티브 컴포넌트와 JavaScript의 관계에 해당한다.
   3. 주방과 셰프를 없애는 것이 아니라, 다른 셰프가 조사·계획하고 요리하는 셰프에게 조리법을 전달하는 구조다.

2. 코드 번들의 교체

   1. iPhone과 네이티브 레이어는 같은 주방으로 남고, 실제 플랫폼 동작은 Swift 등 네이티브 코드가 수행한다.
   2. JavaScript 레이어는 요소를 어디에 놓고 어떻게 행동할지 지시하는 상대적으로 쉬운 부분을 맡는다.
   3. 두 시간이 지나 메뉴가 완전히 바뀌어도 Apple이 주방의 셰프를 밖으로 내보내지 않는다면, 명령을 전달하는 셰프만 바꾸면 된다.
   4. 새 JavaScript 번들을 내려받는 OTA는 주방을 바꾸지 않고 조리법 공급원만 바꾸는 일이며, 그래서 작은 수정과 계절성 UI를 빠르게 적용할 수 있다.

3. 계절성 UI 사례

   1. 특정 휴일 하루 동안 홈 화면에 특별한 배경을 켰다가 밤에 끄는 기능을 네이티브로 만들려면 수개월 전부터 기능을 넣고 사용자가 최신 버전을 설치할 때까지 기다려야 한다.
   2. 정해진 날에 기능을 켜고 끄는 코드가 미리 들어 있어야 하며 문제가 생기면 이미 늦는다.
   3. React Native에서는 아침에 OTA를 올려 기능을 켜고 저녁에 다른 OTA를 올려 제거할 수 있으며, 중간에 문제가 생기면 또 다른 번들로 수정할 수 있다.

3.3. Expo가 제공하는 생산성

1. React Native 생태계의 운영 계층

   1. Expo는 React Native 세계의 Next.js와 Vercel에 가까운 도구 계층으로, 빌드·OTA·업데이트 배포·개발 클라이언트 등 운영에 필요한 기능을 묶는다.
   2. 자체 서버에서 빌드를 처리하고 OTA를 배포하며, 개발용 클라이언트를 쉽게 만들 수 있다.
   3. Jamon은 Shopify가 Expo를 완전히 도입하지 않았다고 지적했고, React Native를 Expo 없이 쓰면 결국 필요한 도구를 직접 다시 만드는 셈이라고 말했다.

2. 개발 루프의 차이

   1. 네이티브 앱은 Apple 계정, 권한, 서명, 공유 화면 같은 기능 때문에 한 컴퓨터에서 다른 컴퓨터로 빌드하기가 쉽게 실패한다.
   2. T3 Code 네이티브 포크를 Mac에서 휴대폰으로 빌드하면 공유 화면 권한과 서명 절차 때문에 실패할 수 있고, 작은 UI 변경만을 위한 쉬운 개발 빌드와 전체 기능 빌드를 따로 유지해야 한다.
   3. 실제 개발용 빌드에는 Apple의 별도 체크박스와 승인 절차 때문에 기능 서너 개가 빠질 수 있으며, 자신이 소유한 컴퓨터와 휴대폰 사이에 자신의 앱을 설치하는 데도 복잡한 절차가 필요하다.
   4. Expo에서는 한 명이 복잡한 설정을 통과해 개발 버전을 만들면 다른 개발자가 QR 코드를 스캔해 JavaScript를 교체하며 앱을 작업할 수 있다.
   5. 공유 화면처럼 깊은 네이티브 기능 자체를 바꿀 수는 없지만, 공유 기능과 연동된 새 기능을 시험하는 개발 루프는 크게 쉬워진다.

3. 시뮬레이터·웹 지원

   1. Expo의 시뮬레이터 지원과 웹 지원은 네이티브 빌드 없이도 에이전트가 많은 로직을 반복 실행하게 한다.
   2. CLI로 앱을 흉내 내는 것보다 전체 앱을 웹으로 컴파일해 테스트하는 편이 로직 검증에는 더 나을 수 있다.
   3. Expo에도 거친 모서리는 있지만, 네이티브 앱 개발의 계정·심사·서명 절차보다 전반적으로 훨씬 나은 모바일 개발 경험을 제공한다.
   4. Shopify가 Expo를 충분히 사용하지 않았다는 사실은 React Native의 장점을 덜 누린 채 네이티브와 비교하게 만들었고, 이 때문에 전환 비용도 상대적으로 낮췄다.

4. React Native의 실제 단점과 네이티브 비교

React Native의 약점은 “앱 용량이 크고 느리다”보다 네이티브 의존성 관리, 잘못된 사용 패턴, 변화가 큰 내부 구조, 플랫폼 소유자 의존성에 가깝다.

4.1. 라이브러리와 패키징 복잡성

1. Xcode 계층의 고통

   1. React Native 라이브러리 문제의 상당 부분은 JavaScript 자체보다 Xcode 안에서 Objective-C·CocoaPods 또는 Swift·CocoaPods 패키지를 관리하는 과정에서 발생한다.
   2. 라이브러리를 빌드하고 링크하는 방식이 서로 깨지는 이유를 이해하기 어려워 개발 경험이 나빠진다.
   3. 이 문제는 React Native의 추상화가 나빠서라기보다 Apple 패키징 시스템과 네이티브 연결 계층의 불쾌한 상호작용에 가깝다.

2. 앱 용량에 대한 반박

   1. React Native가 앱을 엄청나게 크고 느리게 만든다는 주장은 Shopify의 실제 이동 결과와 맞지 않는다.
   2. Shopify가 Shop 앱을 네이티브로 옮겨 줄인 용량은 고작 1MB였다.
   3. 기본 Expo React Native 앱의 크기는 대략 20~30MB 범위이며, 런타임 자체는 특별히 크지 않다.
   4. 큰 앱은 현지화·번역 데이터와 과도한 이미지·미디어 자산 때문에 커지는 경우가 많고, 작은 이미지 몇 개만으로도 앱 크기가 네 배가 될 수 있다.
   5. 네이티브 재작성 뒤의 크기 차이는 새 시스템을 만들며 얻은 학습과 정리 효과인 경우가 많으며, React Native 런타임의 본질적 문제라고 보기 어렵다.

4.2. Footgun과 개발자 구성

1. 모바일에서 증폭되는 실수

   1. 웹 React에서 덜 숙련된 팀을 괴롭히는 문제는 모바일에서 더 크게 나타나며, 잘못된 useEffect 하나가 모바일 경험 전체를 망칠 수 있다.
   2. React Native는 접근성이 높아 초보 개발자도 쉽게 시작할 수 있지만, 잘못 사용했을 때의 함정도 더 많은 사람에게 노출된다.

2. 평균 개발자 수준과 기술의 품질

   1. 평균적인 React Native 개발자가 평균적인 네이티브 개발자보다 실력이 낮다는 평가는 기술 우열이 아니라 진입장벽 차이에서 나온다.
   2. 네이티브가 더 어렵기 때문에 네이티브 개발자는 자기 선택을 위해 더 많은 준비를 거치는 반면, React Native는 네이티브가 너무 어려워서 선택하는 개발자도 많다.
   3. 좋은 기술이 기본값이 되면 실력이 낮은 개발자도 몰려 평균 수준이 내려가지만, 이는 기술 자체가 나쁘다는 증거가 아니다.
   4. 웹에서 React가 널리 쓰이며 비슷한 현상이 생겼듯이, React Native의 footgun은 기술의 성공 때문에 더 눈에 띈다.

4.3. 변화하는 표적과 Meta 의존성

1. 대규모 재설계의 비용

   1. React Native는 내부 동작을 근본적으로 바꾸는 대규모 아키텍처 재설계를 거쳤다.
   2. 앱 팀이 직접 작성한 네이티브 코드와 React Native의 연결 방식도 달라지고, 버전 업그레이드가 어려워진다.
   3. 큰 React Native·Expo 버전을 올릴 때 package.json과 lock 파일을 지우고 다시 설치한 뒤 결과를 기대하는 식의 경험이 반복된다.
   4. 설치가 깨지면 수동 수정하기보다 삭제하고 다시 쓰는 편이 빠를 때가 많으며, 웹의 다른 의존성 업데이트처럼 “그냥 작동”한 적이 거의 없다는 평가가 나왔다.

2. 플랫폼 기능을 기다리는 문제

   1. Meta가 악하거나 믿을 수 없어서 React Native를 쓰지 말아야 한다는 주장은 아니다.
   2. Apple이 새 기능을 내놓았을 때 네이티브 개발자는 곧바로 쓸 수 있지만, React Native 개발자는 Meta가 지원할 때까지 기다리거나 불완전한 shim을 직접 만들어야 할 수 있다.
   3. 네이티브는 새 기능을 즉시 사용할 수 있고 출시까지 한 달을 기다릴 수 있지만, 결국 기능 자체는 사용할 수 있다.

3. 빠진 항목

   1. 성능, 유동성, 데이터 로딩은 대표적인 반(反)React Native 논거처럼 보이지만 핵심 단점 목록에는 포함되지 않는다.
   2. iOS에서 앱이 잠들면 JavaScript 엔진이 완전히 종료되므로 백그라운드 연결 유지나 데이터 처리는 네이티브 코드가 필요하다.
   3. Swift 레이어도 종료될 수 있어 한계가 완전히 사라지지는 않지만, React Native는 필요할 때 네이티브 코드를 함께 작성할 수 있다.
   4. “React Native”에서 native라는 단어를 잊으면 안 되며, JavaScript만 고집할 때의 제약을 React Native 전체의 제약으로 오해하면 안 된다.

5. Shopify 사례를 둘러싼 두 가지 특수성

Shopify의 결론은 네이티브 전환의 기술적 근거를 제공하지만, 새 아키텍처·Expo 도입 여부·창업자 의사결정 방식 때문에 다른 회사가 그대로 일반화하기 어렵다.

5.1. New Architecture를 반영하지 않은 비교

1. React Native New Architecture

   1. React Native는 네이티브 코드와 JavaScript 사이의 브리지를 더 빠르게 만드는 대규모 핵심 아키텍처 개편을 진행했다.
   2. 이 구조는 React Native 0.68에서 실험적 opt-in으로 소개됐고, 현재는 기본값이라는 채팅 확인이 나왔다.
   3. 브리지 통신뿐 아니라 레이아웃 동기화, effects, ref를 네이티브에 가깝게 다루는 기능이 개선됐다.
   4. 이전에는 여러 계층을 거쳐야 했던 콜백과 target 업데이트가 더 빨라졌다.

2. Shopify 비교의 한계

   1. Shopify는 기존 React Native 작업을 New Architecture로 포팅할지, 네이티브로 다시 쓸지 결정해야 했다.
   2. 기존 네이티브 코드가 많아 New Architecture 포팅이 쉬운 일은 아니었지만, 에이전트가 있다면 감당하지 못할 정도는 아니었을 수 있다.
   3. Shopify의 시작 시간 등 비교 수치는 New Architecture가 충분히 적용된 React Native와 비교한 값이 아니므로 해석에 한계가 있다.
   4. New Architecture는 여러 성능 문제를 크게 개선하므로 구형 아키텍처·신형 아키텍처·네이티브를 나란히 비교했어야 격차를 더 정확히 볼 수 있다.
   5. T3 Code의 React Native 앱과 Swift 앱은 모두 Shopify Shop 앱보다 훨씬 빠르게 로드된다는 실제 관찰도 제시됐다.

5.2. Toby의 창업자 모드

1. 논쟁이 된 의사결정 방식

   1. Shopify의 창업자 겸 CEO Toby는 주말 사이에 결정을 내리고 실제 앱을 만드는 팀의 의견 없이 회사 전체에 적용한다는 비판을 받아왔다.
   2. 과거 React가 느리다고 판단해 새 프로젝트를 Ruby on Rails로 만들고 기존 프로젝트 일부도 마이그레이션하자는 회사 결정을 내렸다.
   3. 서버 컴포넌트를 알게 된 지 2주 뒤에는 React를 비판하던 내부 글을 지우고 마이그레이션 결정을 취소했다.
   4. 이런 일이 자주 일어나 Slack 채널에 즉시 바꾸라는 요구를 남기는 상황을 표현하는 회사 내부 이모지까지 있었다.

2. Toby의 반박

   1. 문제의 사례는 중요한 외부 제품이 아니라 약 50명이 쓰는 내부 도구였고, 팀이 스스로 만든 아키텍처 악몽에 갇힌 상황이었다.
   2. Rails 백엔드가 headless GraphQL API와 SPA React 프런트엔드를 붙인 구조라 작은 사용자 수에도 프런트엔드 엔지니어가 계속 필요했다.
   3. 이 정도 규모의 내부 도구에 GraphQL·Rails·SPA를 사용하는 것은 “엔터프라이즈 프로덕션 앱을 코스프레하는 일”이며, 단순한 Rails로 즉시 다시 쓰는 편이 맞다는 평가가 나왔다.
   4. Twitch에서도 비슷한 내부 Rails 앱을 Go 백엔드·GraphQL 계층·React 프런트엔드로 바꿔 공용 플랫폼과 내부 플랫폼 사이의 이동을 쉽게 만든 경험이 있었고, 내부 도구를 공개 서비스에 가져갈 기능을 실험하는 그린필드 공간으로 활용했다.

3. Founder Mode as a Service

   1. Toby는 팀이 옳은 결정을 알고도 나쁜 사람이 되기 싫어할 때 대신 결정해 달라고 요청하는 경우가 많다고 답했다.
   2. 그 요청에 동의하면 창업자가 결정을 내려 회의와 변경 관리 비용을 크게 줄이는 방식이며, 이를 “서비스로서의 창업자 모드(Founder Mode as a Service)”라고 부른다.
   3. 결정의 모든 변수를 설명하고 당시 정보에 비춰 왜 그 선택을 했는지 가르치기 위해 10년 동안 내부 팟캐스트 context를 운영했다.
   4. 과거 선택을 지금의 지식으로 비난하는 매몰비용 오류를 피하고, 창업자 없이도 이런 판단을 내릴 수 있게 하는 교육이 목적이다.
   5. 해당 전환을 Toby의 실수로만 보는 이야기는 실제로 기술 부채가 적고 좋은 아키텍처로 회사를 움직인 성공 사례를 무시한다는 반박도 나왔다.

6. T3 Code의 실제 네이티브 포팅 실험

에이전트에게 실행 가능한 기존 구현, 시뮬레이터, 명확한 피드백을 주면 React Native 앱을 Swift로 옮기는 작업은 Shopify의 경험보다 훨씬 매끄럽게 진행될 수 있다.

6.1. Soul·Astra를 활용한 재구축

1. 첫 번째 실험

   1. 새로운 모델 접근권과 토큰을 잃을 가능성이 있던 시기에 T3 Code의 React Native 버전이 이미 깊이 개발된 상태였지만, 남은 토큰으로 Swift와 UIKit 앱을 만들어 보자는 실험이 진행됐다.
   2. Mac Mini에 Xcode를 설치하는 데 예상보다 오래 걸렸고, Mac App Store 대신 CDN에서 직접 내려받아야 한다는 조언이 덧붙었다.
   3. Soul에게 Swift와 UIKit으로 만들라고 지시하자 약 2시간 만에 작업이 끝났으며, 멈췄다고 생각했지만 앱을 열어 보니 실제로 작동했다.
   4. 당시 Rust 포팅 세 건도 동시에 진행 중이어서 첫 결과를 깊이 탐색하지는 못했다.

2. 두 번째 실험

   1. 이후 T3 Code 사용이 늘고 다시 코딩을 시작하면서 React Native 버전의 맞춤형 내비게이션 문제와 여러 미세한 문제가 드러났다.
   2. 스크롤 뷰는 T3 Code 서비스 중 React Native 버전이 여전히 가장 좋다고 평가됐다.
   3. Ultra와 Soul, Mac Mini의 computer-use 기능을 사용해 React Native 앱을 Swift로 포팅하려 했고, 에이전트가 AppKit을 UIKit으로 이해한 뒤 두 번째에는 둘 다 아닌 SwiftUI를 선택했다.
   4. 그 결과 기존 React Native 앱과 같은 기능의 UIKit 버전과 SwiftUI 버전이 각각 만들어졌다.
   5. 각 빌드는 컴퓨터 사용 루프를 에이전트가 자동으로 돌리며 3시간 이내에 완료했다.

3. SwiftUI의 장점과 한계

   1. 네이티브 버전은 일부 내비게이션과 백그라운드 데이터 로딩이 더 나았고, 앱이 잠들어도 네이티브 코드가 데이터를 더 잘 유지했다.
   2. 전체가 더 빠르게 느껴질 정도의 성능 혁명은 아니었으며, 오히려 SwiftUI 리스트 스크롤은 매우 나빴다.
   3. Arc 브라우저도 SwiftUI 네이티브 UI에서 다운로드 폴더에 수백 개 파일이 있으면 파일을 모두 인덱싱하다 다운로드 버튼이 충돌하고 브라우저가 느려지는 문제가 있었다.
   4. 반면 SwiftUI에서 스레드로 들어갔다가 돌아올 때 스와이프가 손가락을 더 정확히 따라오는 듯한 미묘한 감각은 좋았다.

6.2. 스와이프 내비게이션 버그와 Apple의 역설

1. 사용자 습관의 차이

   1. 한 화면에서 다음 화면으로 들어간 뒤 왼쪽 가장자리에서 오른쪽으로 끌면 내비게이션 스택을 한 단계 되돌아가는 동작이 자연스럽다.
   2. 한쪽은 화면 왼쪽 3분의 1 또는 4분의 1에서 시작하고, 다른 사람들은 손가락을 멀리 뻗기 싫어 화면 중앙에서 시작한다.
   3. Android의 오래된 메뉴 바보다 제스처가 화면 공간을 덜 차지하고 더 낫다는 개인적 선호도 제시됐다.

2. React Native에서 발견된 8픽셀 버그

   1. T3 Code React Native 앱에 과거 스와이프 드로어가 추가되면서 화면 왼쪽 약 8픽셀 영역을 여전히 감지하는 문제가 남았다.
   2. 실제 드로어가 사라진 뒤에도 그 영역을 터치하면 드로어가 활성화돼 가장자리 스와이프가 작동하지 않았다.
   3. 중앙에서 스와이프하는 Julius는 버그를 한 번도 겪지 않았고, 왼쪽에서 스와이프하는 사용자는 매일 겪었기 때문에 원인을 찾기까지 큰 논쟁이 있었다.
   4. 결국 팀은 문제를 파고들어 남은 감지 영역을 제거했다.

3. SwiftUI의 공식 내비게이션 한계

   1. SwiftUI의 네이티브 내비게이션 스택은 Apple 공식 방식이라 안정적일 것처럼 보이지만, 뒤로 가기 제스처를 허용하는 영역이 왼쪽 4분의 1로 고정된다.
   2. 그 gutter 크기를 바꿀 수 없어 중앙에서 시작하는 스와이프를 지원하려면 네이티브 내비게이션 제스처를 포기해야 한다.
   3. iPhone 설정 앱에서 배터리처럼 다른 화면으로 들어간 뒤 중앙에서 스와이프해도 돌아갈 수 있지만, Apple 자체 앱이 이 네이티브 스택을 그대로 쓰지 않고 다양한 뒤로 가기 방식을 지원하기 위한 자체 레이어를 사용하기 때문이다.
   4. iMessage, 설정, Twitter, 새 SwiftUI 앱이 서로 다른 뒤로 가기 감각을 제공하면 사용자는 Apple이 아니라 앱을 탓한다.
   5. 결국 자연스러운 손가락 위치를 모두 지원하려면 내비게이션 레이어를 직접 다시 만들어야 하며, “Apple의 개발자 경험이 더 좋은 감각의 앱을 보장한다”는 주장도 흔들린다.

6.3. 에이전트가 만든 앱을 신뢰하게 된 순간

1. 프롬프트와 반복 작업

   1. 기존 React Native 구현이 명확하고 에이전트가 시뮬레이터를 사용할 수 있으며 무엇이 틀렸는지 알려주면, 거의 완벽하게 포팅하고 실패하더라도 첫 수정으로 고치는 경우가 많았다.
   2. Soul은 기존 React Native 코드베이스를 탐색해 실제 네이티브 앱의 정신으로 옮기는 능력이 매우 매끄러웠고, 실패 원인은 모델 선택·컴퓨터 사용·도구 운용 차이일 수 있다는 추정이 나왔다.

2. 실제 사용 앱

   1. 매일 휴대폰에서 코딩하는 앱은 React Native 앱을 SwiftUI로 옮긴 포트이며, 약 95%를 Soul이 만들고 나머지 5~10%를 Astra가 보완했다.
   2. 거의 전체 앱을 단일 스레드에서 만들었고, 기존 브랜치는 여전히 PR로 열려 있었다.
   3. 해당 PR은 번호가 5,000번일 때 열렸지만, 몇 달 동안 너무 많은 기능이 출시돼 현재 작업 번호가 약 12,000번까지 올라갔다.
   4. React Native 앱이 리스트 같은 일부 기능에서 여전히 더 빠르지만, SwiftUI 포트도 매일 사용할 만큼 충분히 안정적이다.

3. 자율 루프의 범위

   1. 에이전트는 한 시간 동안 목표를 새로 받지 않고 스스로 메인 브랜치의 최신 변경을 가져오고, wire protocol을 유지하며 SwiftUI 포트를 갱신했다.
   2. 배치 inbox 업데이트, 스레드 행의 provider 계정 배지, 새 작업의 기존 브랜치 선택, 비동기 질문 닫기, 질문 첨부, 저장된 첨부 초안, answer history, hub reset, 크레딧과 사용량 라벨의 개인정보 보호를 처리했다.
   3. 작업 중 최소 두 번 컨텍스트를 압축했고, 시뮬레이터를 직접 테스트하다 종료했지만 테스트를 통과시킨 뒤 결과를 제출했다.
   4. 과거에는 앱을 휴대폰에 설치해 직접 확인하고 점검 목록을 달라고 했지만, 이 시점에는 에이전트를 믿고 공개 TestFlight에 올리라고 할 정도로 신뢰가 올라갔다.
   5. 공개 TestFlight에는 약 1,000명이 참여하고 있으며, 제작자는 앱 코드 한 줄도 읽지 않았지만 매일 코딩에 사용하고 있다.
   6. 한 명이 재미로 파트타임으로 만든 앱이므로, 전담 엔지니어를 둔 회사라면 더 복잡한 Shop 앱도 충분히 이식할 수 있다는 판단이 제시됐다.

7. 성능과 Meta의 React Native 팀

React Native의 강력함은 JavaScript의 편리함만이 아니라, Meta가 수백 명의 고급 네이티브 엔지니어를 투입해 만든 바인딩과 런타임을 모두가 물려받는 데서 나온다.

7.1. Legend List와 성능의 재평가

1. Legend State와 Legend List

   1. Jay가 만든 Legend State와 Legend List는 React 생태계의 성능 중심 라이브러리이며 최근 웹에도 진출했다.
   2. Legend List는 모바일 렌더링 문제를 해결해 T3 Code 팀이 웹 버전도 매우 일찍 도입하게 만들었다.
   3. T3 Code의 Electron 앱과 웹 앱 스크롤 영역이 훌륭하고 Codex나 Cloud Code에서 보이는 이상한 버그가 적은 이유 중 하나가 이 라이브러리다.

2. JS만으로 만드는 가상화

   1. 다른 React Native 리스트 라이브러리는 약간의 JavaScript와 많은 네이티브 코드로 긴 목록을 처리한다.
   2. Legend List는 전체가 JavaScript이고, JavaScript 계층에서 가상화기(virtualizer)를 충분히 빠르게 구현해 리스트가 날아가듯 작동한다.
   3. 네이티브 코드를 포함하지 않아 웹 포팅도 어렵지 않았다.

3. 네이티브보다 빠를 수 있는 이유

   1. Jay가 벤치마크 비교에서 React Native가 네이티브보다 빠른 경우를 봤다고 말하는 데는 성능 최적화에 대한 구체적 근거가 있다.
   2. React Native가 항상 네이티브보다 빠르다는 뜻이 아니라, 좋은 JavaScript 구조와 고성능 라이브러리가 네이티브 구현을 앞설 수 있다는 뜻이다.

7.2. Meta가 만든 네이티브 전문성

1. 팀 규모의 비대칭

   1. React 코어·웹·기타 영역의 Meta 엔지니어는 전성기에 30명 미만이었다는 추정이 제시됐다.
   2. React Native 팀은 한때 300명 이상이었으며, 두 영역의 비율은 10 대 1 정도로 React Native 쪽이 컸다.
   3. React는 DOM에 접근하고 더 나은 방식으로 업데이트하면 되지만, React Native는 iOS·Android와 Quest 계열의 복잡한 네이티브 기능을 하나의 JavaScript 접근 계층으로 노출해야 하므로 훨씬 만들기 어렵다.

2. 웹과의 비유

   1. React에서 window와 DOM에 직접 접근할 수 없고 Chromium의 모든 기능을 React가 다시 노출해야 한다면 엄청난 일이 되는 것처럼, React Native는 네이티브 세계 전체를 다시 연결하는 작업을 해냈다.
   2. 그래서 React Native는 단순한 JavaScript 래퍼가 아니며 Meta가 수억 또는 수십억 달러를 들여 축적한 결과를 활용하는 플랫폼이다.

3. 팀에 대한 오해

   1. React Native 팀은 JavaScript 개발자만 모인 팀이 아니며, Apple·Google에서 직접 일한 개발자와 Xcode를 방어할 정도로 네이티브를 사랑하는 엔지니어가 포함됐다.
   2. 최고의 네이티브 개발자들은 광고 팀에서 갓 졸업한 경험 부족 개발자가 React 코드를 잘못 작성해도 아름다운 네이티브 플랫폼을 망치지 않게 만드는 데 집중했다.
   3. 좋은 네이티브 바인딩을 만들어 덜 숙련된 개발자도 자신이 직접 작성하는 것보다 나은 네이티브 코드를 사용하게 하는 것이 목표였다.
   4. 앱 팀이 Meta보다 더 뛰어난 네이티브 엔지니어를 보유했는지 묻는다면, 대부분의 팀은 Meta의 전문성을 등에 업는 편이 유리하다.

7.3. 코딩 에이전트가 줄인 실력 격차

1. 기존의 선택 압력

   1. WWDC에 가는 유형의 네이티브 전문가가 팀에 없으면 앱 품질이 낮아질 수 있었기 때문에 과거에는 React Native를 선택해야 할 이유가 컸다.
   2. 네이티브 개발이 어려워도 Meta의 전문가가 만든 바인딩을 이용하면 팀의 부족한 네이티브 역량을 보완할 수 있었다.

2. 현재의 변화

   1. Codex 같은 코딩 에이전트도 네이티브 코드를 매우 잘 다루므로, 에이전트가 Meta의 엔지니어와 유사한 실력 격차 완화 역할을 한다.
   2. Soul과 Astra가 충분히 가까운 수준까지 격차를 줄여, React Native를 반드시 써야 한다는 과거의 압력이 약해졌다.
   3. OTA와 잘 작동하는 리스트를 포기하면 아쉽고 Apple의 개발자 경험과 계속 충돌하겠지만, 네이티브 전문성 부족 때문에 React Native를 택해야 하는 이유는 줄었다.

7.4. Meta의 팀 축소와 생태계 리스크

1. React·React Native 팀의 해체

   1. Meta는 React와 React Native 팀을 축소하거나 해체하는 방향으로 움직였고, React 컴파일러의 주요 엔지니어였던 Lauren이 Cursor로 옮겼다.
   2. Meta에서 충분한 투자를 받지 못해 떠난 뒤 약 3개월 만에 업계와 소셜 미디어에서 세계적 엔지니어로 주목받은 속도는 과거 팀의 인재 밀도를 보여준다.
   3. Meta의 다른 인재들도 업무가 데이터 라벨링으로 변하는 것을 원하지 않아 업계를 떠나고 있다.

2. 품질 정체의 원인

   1. 남은 사람이 갑자기 무능해진 것이 아니라 팀 규모와 투자, 인재 밀도가 과거와 달라졌다.
   2. 에이전트로 외부 팀의 역량은 높아졌지만 React Native 팀이 제공하는 품질과 유지보수 속도는 정체될 수 있다.
   3. New Architecture를 출시한 시점이 팀 변화와 겹쳤다는 점에서 기존 React Native 팀의 마지막 큰 유산처럼 보일 수 있다.

3. 앞으로의 상태

   1. React Native가 사라지지는 않으며 이를 기반으로 한 제품과 생태계가 계속 존재한다.
   2. Meta가 사람 대신 에이전트로 유지보수를 수행한다면 이전보다 느리고 덜 꼼꼼하며 덜 애정을 받는 프로젝트가 될 수 있다.
   3. 수년간 함께 일한 동료들이 하나씩 사라지는 상황에서 남은 엔지니어가 의욕을 잃으면 좋은 소프트웨어를 만들기 어렵다.
   4. 현재 팀의 품질이 끔찍하다는 뜻이 아니라, 역사적으로 혁신적이었던 수준의 결과를 앞으로도 꾸준히 기대하기 어렵다는 뜻이다.

8. 결론: React Native의 사망이 아니라 선택 기준의 이동

Shopify의 실험은 React Native가 실패했다는 증명이 아니라, AI 에이전트가 플랫폼 간 중복 구현의 경제학과 네이티브 전문성의 희소성을 동시에 바꿨다는 사례다.

8.1. 두 가지 큰 베팅

1. React Native 자체의 역사

   1. React Native는 웹의 React가 예상보다 훨씬 잘 작동한 뒤, “웹용 JavaScript 기술이 모바일 플랫폼 작동 방식까지 다시 만들 수 있지 않을까”라는 대담한 베팅에서 출발했다.
   2. 화면이 바뀔 때 UI를 통째로 다시 만든다는 발상은 어리석어 보였지만 단순했기 때문에 작동했고, Meta는 뛰어난 엔지니어를 대규모로 투입해 성공시켰다.
   3. 광고 웹 팀의 개발자도 Instagram 모바일 앱의 광고 플랫폼에 기여할 수 있을 정도로 단순한 인터페이스를 만들려는 목표를 달성했다.

2. Shopify의 새 베팅

   1. Shopify는 에이전트가 기존 소프트웨어를 네이티브로 포팅하는 능력이 충분히 좋아졌다는 가정에 베팅했다.
   2. 이 베팅은 멀티플랫폼이라는 구호에 기대지 않고, 플랫폼별 코드를 직접 만들면서도 에이전트가 구현·번역·검증 비용을 떠안는 구조를 시험한다.
   3. React Native가 게으른 개발자를 위한 기술이고 네이티브가 언제나 우월하다는 결론은 나오지 않는다.

8.2. “한 번 작성, 어디서나 실행”이 아닌 “한 번 배우고, 어디서나 이해”

1. React Native의 실제 약속

   1. React Native는 write once, run everywhere가 아니라 learn once, understand everywhere에 가까웠다.
   2. React를 배운 뒤 플랫폼의 동작과 모바일 사용감을 이해하면 새로운 언어를 처음부터 배우지 않고도 좋은 앱을 만들 수 있다는 뜻이다.
   3. React를 알면서도 모바일이 어떻게 느껴져야 하는지 모르면 React Native 앱의 품질을 보장할 수 없다.

2. 에이전트 시대의 팀 책임

   1. React Native를 쓰든 Swift·Kotlin 같은 네이티브 플랫폼을 쓰든 iOS와 Android 양쪽에서 실제 앱을 테스트해야 한다.
   2. 팀에는 Android 휴대폰을 매일 쓰며 Android의 감각을 아는 사람이 필요하고, Android 담당자도 iPhone을 매일 써 본 뒤 Android로 돌아가야 두 플랫폼의 문제를 발견할 수 있다.
   3. React Native·Kotlin·Jetpack Compose 중 어떤 라이브러리도 사용자의 실제 습관을 모르는 팀을 대신해 주지 않는다.

8.3. 제품별 선택 기준

1. React Native가 여전히 유리한 경우

   1. OTA로 작은 변경과 긴급 수정을 빠르게 배포해야 하는 제품은 JavaScript 번들 교체의 가치가 크다.
   2. Expo의 개발 클라이언트·빌드·시뮬레이터·웹 지원과 Legend List 같은 생태계를 활용하면 개발 속도와 런타임 품질을 함께 얻을 수 있다.
   3. 팀이 Meta의 네이티브 전문성을 활용하고, 공통 UI·로직과 빠른 기능 출시를 중시한다면 React Native는 여전히 강력하다.

2. 네이티브가 유리해지는 경우

   1. AI 에이전트가 충분히 강하고, Swift·Kotlin의 구현·테스트·리뷰를 신뢰성 있게 자동화할 수 있는 팀은 플랫폼별 코드의 장점을 직접 얻을 수 있다.
   2. 최신 Apple·Google 기능을 즉시 사용하고 프레임워크·의존성 계층을 줄이며 백그라운드 동작을 네이티브로 제어해야 한다면 네이티브가 매력적이다.
   3. 기존 앱을 깨끗한 상태에서 다시 만들 수 있고 에이전트가 제품 명세·시각적 테스트·적대적 리뷰를 통과하는 구조를 갖추면 greenfield 전환의 비용이 낮아진다.

3. 공통적으로 필요한 조건

   1. 앱을 실제 기기에서 반복 테스트하고, 사용자 손가락이 닿는 위치와 앱이 잠든 뒤의 동작까지 검증해야 한다.
   2. 구현 속도보다 플랫폼 감각·제품 품질·업데이트 전략·팀 역량을 함께 판단해야 한다.
   3. Shopify의 선택을 그대로 복제하기보다 자신의 Expo 사용 정도, New Architecture 상태, 에이전트 품질, 네이티브 인력, OTA 필요성을 먼저 측정해야 한다.

주요 발언 모음

“React Native 앱은 빠를 수 있고, Shopify의 앱들은 실제로 빠르다.”

“React Native는 네이티브의 대안이 아니라 네이티브 요소를 제어하는 명령 계층이다.”

“React Native는 레시피를 배포하는 시스템이다.”

“좋은 네이티브 개발자가 더 많은 팀은 어디인가? 당신의 팀인가, Meta인가?”

“에이전트가 그 격차를 훨씬 작게 만든다.”

“React Native는 한 번 작성해 어디서나 실행하는 것이 아니라, 한 번 배우고 어디서나 이해하는 방식이었다.”

“AI 에이전트가 구현을 쉽게 만들었지만, 모바일 개발의 고통스러운 문제까지 사라지게 하지는 않았다.”

핵심 데이터 & 수치

• 2020년: Shopify가 React Native에 전면 투자하기 시작한 해다.
• 2021년: Shopify가 LLM을 소프트웨어 제작에 사용하기 시작한 해다.
• 2025년 1월: Mustafa Ali가 Shopify의 React Native 5년 사용 경험과 지속 투자 계획을 정리했다.
• 2025년 말: LLM이 단순한 코드 작성 보조를 넘어 두 플랫폼 구현의 비용 가정을 다시 묻게 했다.
• 12주: AI 지원을 받은 Shop 앱이 개념증명에서 앱스토어 출시까지 걸린 기간이다.
• 300개 화면: 마이그레이션 중인 Shopify 앱의 화면 수다.
• 약 2~3명: OTA의 iPhone mini 버튼 오류 사례에 등장한 소규모 팀 규모다.
• 절반 이상: Twitch에서 어느 시점이든 최소 두 버전 오래된 앱을 사용하던 사용자 비율이다.
• 54개 앱: 휴대폰에서 업데이트가 실제로 가능했던 앱 수다.
• 약 20~30MB: 기본 Expo React Native 앱의 대략적인 용량 범위다.
• 1MB: Shopify가 React Native에서 네이티브로 옮겨 Shop 앱에서 줄인 용량이다.
• React Native 0.68: New Architecture가 실험적 opt-in으로 등장한 버전으로 언급됐다.
• 300명 이상 대 30명 미만: Meta에서 전성기 React Native 팀과 React 코어·웹·기타 팀의 추정 인원 규모다.
• 약 10 대 1: 두 팀 규모의 추정 비율이다.
• 약 2시간: Soul이 첫 Swift·UIKit 앱을 만든 시간이다.
• 3시간 미만: UIKit·SwiftUI 포트 각각이 자동화 루프에서 완성된 시간이다.
• 약 95%: SwiftUI 포트에서 Soul이 만든 비율이다.
• 약 5~10%: SwiftUI 포트에서 Astra가 보완한 비율이다.
• 약 1,000명: T3 Code 네이티브 포트 공개 TestFlight 참여자 수다.
• 약 8픽셀: React Native 앱에서 사라진 스와이프 드로어가 남긴 감지 영역이다.
• 10년: Toby가 내부 의사결정 팟캐스트 context를 운영한 기간이다.
• 약 50명: 논쟁이 된 Shopify 내부 도구의 사용자 수다.
• 약 3개월: Meta를 떠난 Lauren이 업계에서 빠르게 주목받기까지 걸린 기간이다.
• 1,000명 구독자: 영상 반응이 충분하면 Electron 영상을 만들겠다는 조건으로 제시된 수치다.

결론 및 시사점

1. AI 에이전트는 React Native를 죽이지 않았지만, “두 플랫폼의 구현을 한 번만 작성한다”는 경제적 우위를 약화했다.
2. Shopify의 전환은 React Native의 성능 실패보다 Swift·Kotlin 구현을 에이전트가 충분히 빠르게 처리하게 된 상황에 대한 재평가다.
3. OTA는 앱스토어 버전 파편화와 긴 심사·배포 주기를 완화하는 React Native의 독보적인 장점으로 남는다.
4. React Native는 웹뷰가 아니라 네이티브 컴포넌트를 JavaScript 명령으로 조정하는 구조이므로 필요할 때 네이티브 코드를 직접 추가할 수 있다.
5. Expo를 적극적으로 쓰지 않은 Shopify의 경험은 일반적인 React Native 팀의 경험보다 프레임워크 생태계 이점을 덜 반영했을 가능성이 있다.
6. Shop 앱의 12주 그린필드 재구축은 대형 기업도 에이전트와 깨끗한 상태를 결합해 앱을 다시 만들 수 있음을 보여준다.
7. Helix의 체크포인트·테스트·시각적 검토·두 번의 적대적 리뷰·인간 승인은 에이전트 슬롭을 줄이지만 기존 코드베이스 숭배를 강화할 위험도 있다.
8. 네이티브 전환의 실제 장벽은 앱 크기보다 Xcode 패키징, CocoaPods, 권한, 서명, 플랫폼별 도구와 백그라운드 동작이다.
9. Meta의 React Native 팀이 축소되는 상황에서 외부 개발자는 생태계 유지 속도와 핵심 라이브러리의 stewardship을 확인해야 한다.
10. React Native와 네이티브 중 선택할 때는 멀티플랫폼 슬로건보다 OTA 필요성, Expo 활용도, New Architecture 상태, 에이전트 품질, 네이티브 전문성, 실제 사용자 테스트를 기준으로 판단해야 한다.
11. 어떤 스택을 선택해도 iOS와 Android를 매일 직접 사용하는 팀원이 있어야 제스처·화면 크기·업데이트 지연에서 생기는 실제 문제를 발견할 수 있다.
12. 소프트웨어의 다음 베팅은 기존 기술의 승패 선언이 아니라, 에이전트가 구현 비용을 바꾼 뒤 어떤 추상화가 여전히 가장 큰 사용자 가치를 주는지 다시 묻는 일이다.

핵심 요약 (20줄)

1. Shopify는 2020년 React Native로 전환해 기능 중복 구현과 플랫폼 간 기능 격차를 줄였다.
2. Shopify의 React Native 전환은 성능과 개발자 참여 측면에서 기대 이상으로 성공했다.
3. Shopify는 2025년 말 LLM 에이전트가 Swift와 Kotlin 구현 비용을 낮추자 모바일 스택을 다시 평가했다.
4. 네이티브 앱을 두 플랫폼에 따로 만드는 비용은 에이전트의 구현·번역·테스트·리뷰 자동화로 줄었다.
5. Shopify는 Shop 앱을 AI 지원으로 12주 만에 재구축해 앱스토어에 출시했다.
6. Shopify 앱 재구축은 300개 화면과 위젯·Apple Watch·Siri Shortcuts까지 포함하는 대규모 작업이다.
7. Helix는 화면 변환을 작은 체크포인트로 나누고 테스트·시각 리뷰·적대적 리뷰·사람 승인을 요구한다.
8. Shopify는 느린 모바일 시뮬레이터를 피하려고 비즈니스 로직을 헤드리스 CLI에서 밀리초 단위로 실행하려 했다.
9. React Native의 가장 강력한 기능은 네이티브 UI를 유지하면서 JavaScript 번들을 OTA로 교체하는 능력이다.
10. OTA는 iPhone mini 같은 특정 기기 버그를 앱스토어 심사와 사용자 업데이트 지연 없이 수정하게 한다.
11. React Native는 웹뷰가 아니라 JavaScript가 실제 네이티브 요소를 지시하는 명령 계층이다.
12. Expo는 빌드·OTA·개발 클라이언트·시뮬레이터·웹 지원을 제공해 React Native 개발 루프를 크게 단순화한다.
13. React Native의 주요 약점은 앱 용량보다 Xcode 패키징과 CocoaPods 의존성, 버전 업그레이드의 불안정성이다.
14. 기본 Expo React Native 앱은 대략 20~30MB이며 Shopify의 네이티브 전환 용량 절감은 1MB에 불과했다.
15. T3 Code 포트 실험은 에이전트가 기존 React Native 구현을 UIKit과 SwiftUI로 3시간 안에 옮길 수 있음을 보였다.
16. SwiftUI는 일부 데이터 로딩과 내비게이션 감각이 좋았지만 리스트 성능과 뒤로 가기 제스처에 큰 한계를 보였다.
17. Legend List는 JavaScript만으로 고성능 가상화를 구현해 React Native와 웹에서 긴 목록 문제를 해결했다.
18. Meta의 React Native 팀은 전성기에 300명 이상으로 추정되며 네이티브 전문성을 생태계에 공급했다.
19. Meta의 팀 축소와 인재 이탈은 React Native 유지보수 속도와 품질의 정체를 초래할 수 있다.
20. React Native와 네이티브의 선택은 기술 우열이 아니라 OTA·Expo·에이전트·팀 역량·플랫폼 요구의 조합으로 결정된다.