스크립트
00:00:00쇼피파이는 지난 5년 동안 리액트 네이티브를 강력하게 지지해 온 후원자였지만 이번 주에 발표를 통해
00:00:05다시 네이티브 개발로 돌아간다고 밝혔습니다. 여러분도 왜 전환을 고려해야 하는지 이해하신다면 가장 큰
00:00:10리액트 네이티브 같은 플랫폼의 장점은 앱을 한 번만 빌드해서 안드로이드와
00:00:15iOS 양쪽에 모두 출시할 수 있다는 점입니다. 하나의 코드베이스, 하나의 언어로 유지보수 부담이 훨씬 적죠. 쇼피파이도 이 아이디어에
00:00:21전적으로 동참하여 주간 다운로드 수가 200만이 넘는 리액트 네이티브 패키지들을 직접 유지보수해 왔습니다.
00:00:26불과 2025년까지만 해도 이 기술에 대한 지지를 재확인하는 글을 발행했었는데요. 하지만 불과
00:00:321년 만에 태도가 완전히 돌변했습니다. 오픈소스 저장소들은 전부
00:00:37폐기되고 있으며, 회사는 완전히 네이티브로 복귀했습니다. 주된 이유는 AI의 발전 때문입니다.
00:00:44최신 모델들과 사내의 스마트한 기술들 덕분에 두 개의 독립된 앱을 각각 구축해야 하는 부담이
00:00:49더 이상 존재하지 않게 되었습니다. iOS 앱을 보여주며 안드로이드용으로도 만들어달라고 요청하면 그대로 뚝딱 만들어지니까요.
00:00:55그래서 오늘은 쇼피파이가 어떻게 네이티브로 전환하고 있는지 정확히 살펴보려고 합니다. 저 역시 지난 10년 중 상당 기간
00:01:00리액트 네이티브로 개발해 왔음에도 불구하고, 그들의 이러한 결정에 전적으로 공감하며 저 역시
00:01:06다시 네이티브로 돌아왔고 꽤 만족하고 있습니다. 이번 영상을 통해 여러분도 똑같이 마음을 먹게 되시기를 바랍니다.
00:01:12쇼피파이는 지난주 쇼피파이 모바일의 미래는 이제 네이티브라는 글을 발행했으며, 그 내용은 정말 보석 같은 정보들로 가득합니다.
00:01:23그들은 헬릭스(Helix)라는 시스템을 구축하여 에이전트의 작업을 더 작은 단위로 쪼개어 AI의 허접한 결과물(AI slop)을 방지하는 방법과,
00:01:29에이전트가 빌드 후 빠르게 테스트할 수 있도록 빠른 피드백 루프를 처리하는 방법에 대해 이야기합니다. 저도 지난 몇 달 동안 네이티브로 개발을 해보면서
00:01:36제 작업 방식 자체가 근본적으로 바뀌었는데요. 그럼 모든 내용을 하나씩 살펴봅시다.
00:01:42먼저, 왜 이런 전환을 했을까요? 그들 스스로가 말했듯이, 불과
00:01:482025년만 해도 리액트 네이티브의 미래는 밝으며 쇼피파이가 계속 투자를 이어갈 계획이라고 썼었기 때문입니다.
00:01:54하지만 그 사이에 코딩 모델들이 엄청나게 발전했고, 우리 팀이 앱의 동일한 기능을
00:01:59스위프트(Swift)와 코틀린(Kotlin)으로 각각 구축하는 것이 과거처럼 큰 비용을 유발하지 않게 되었습니다.
00:02:05따라서 양 플랫폼을 위해 한 번만 빌드하면 된다는 리액트 네이티브의 이점은 이제 AI 덕분에 더 이상 유효하지 않게 된 것입니다.
00:02:11그래서 그들은 현재 모델들의 한계를 극복하기 위해 헬릭스라는 시스템을 구축했습니다. 그들의 말에 따르면, LLM에 리액트 네이티브 코드베이스를 지정해주고
00:02:17네이티브로 한 번에 기능을 구현하려고 시도하는 것은 유혹적이겠지만, 그렇게 해서는 제대로 작동하지 않습니다.
00:02:23가능한 한 많은 정보를 수집하고, 그것을 명세서와 작업 파일로 정리한 뒤 구현하라고 요청하더라도,
00:02:29결국 출시할 수 없는 엄청난 양의 유지보수 불가능한 코드가 만들어질 뿐입니다. 대신 헬릭스는
00:02:34첫 시도가 완벽하지 않을 것이라는 점을 예상하고, 불완전한 시도가 좋은 결과물이 될 때까지
00:02:41다음 단계로 넘어가지 못하도록 막아주는 루프를 구축합니다. 개발자가 먼저 헬릭스에 화면을 지정하면, 화면은
00:02:46리액트 네이티브 코드를 읽고 몇 분 만에 검토할 수 있는 작고 정돈된 작업 조각들인 체크포인트 시퀀스를 제안합니다.
00:02:52그런 다음 체크포인트마다 빌드를 진행하며, 각 체크포인트는 테스트를 통해 동작을 증명하고, 시각적 검토에서 실행 중인 앱과 일치해야 하며,
00:03:00두 번의 적대적 코드 리뷰에서 살아남아야 하고, 커밋되어 다음 단계가 시작되기 전에 인간의 승인을 받아야 합니다.
00:03:05이러한 각 리뷰에서의 피드백은 기억되므로 마이그레이션이 진행될수록 루프는 더욱 자율적으로 변합니다.
00:03:11이러한 접근 방식은 찌꺼기 같은 코드(slop)를 효과적으로 제거합니다.
00:03:18하지만 이 모든 것이 마련되어 있어도 여전히 거대한 문제가 남습니다. 네이티브 환경을 컴파일하고 테스트하는 것은
00:03:23느리기 때문입니다. 에이전트는 몇 초 만에 변경을 마칠 수 있지만, 그 결과물을 테스트하는 데는 수 분이 걸립니다.
00:03:29이로 인해 반복 작업이 극도로 느리고 수동적으로 변합니다. 모델이 아무리 뛰어나도
00:03:34자신의 작업을 빠르게 테스트할 수 없다면 소용이 없으며, 이는 모바일에서 특히 더 어렵습니다. 쇼피파이는 이를 두 가지
00:03:40구체적인 방식으로 해결했습니다. 첫째, 비즈니스 로직은 UI와 완전히 분리되어야 합니다. 즉, 로직이 데스크톱에서
00:03:46헤드리스(headless) 방식으로 실행될 수 있으며, CLI를 통해 에이전트가 실행할 수 있도록 제공되어
00:03:52시뮬레이터를 거치지 않고 몇 분이 아닌 수밀리초 만에 반복 작업을 할 수 있게 됩니다. 웹 개발의 관점에서 보면 이것은
00:03:58앱의 모든 상태를 JSON에 유지한 다음 액션을 발생시켜 해당 JSON 저장소를 업데이트하는 것과 같습니다.
00:04:04UI는 단지 그 상태를 표현한 것에 불과하므로, 접근성 트리를 처리하거나 화면을 검사하거나
00:04:10요소를 찾아 클릭할 필요가 전혀 없습니다. 모든 것이 UI 없이도 구동될 수 있습니다. 그리고 진정으로
00:04:16UI를 렌더링해야 하는 경우에도 여전히 CLI를 통해 모든 상호작용을 구동할 수 있으므로
00:04:22모든 것이 빠르게 유지됩니다. 이것이 에이전트가 실시간으로 앱을 테스트하는 모습이며 전혀 배속되지 않은 화면입니다.
00:04:28저는 동일한 작업을 수행하는 간단한 데모를 만들어 보았는데, CLI를 통해 유튜브를 띄우고
00:04:32베터 스택(Better Stack)을 구독할 수 있습니다. 하지만 꼭 에이전트가 아니더라도 이 영상 아래의
00:04:36버튼을 눌러 직접 구독하실 수도 있습니다. 이와 같은 설정이 없다면 애플의
00:04:41XCUITest를 사용해야 하지만, 이는 프로세스 외부에서 실행되며 접근성 계층을 탐색해 요소를 찾고,
00:04:46탭을 합성한 뒤 트리를 다시 조회하여 확인하는 방식을 거치므로 대조적으로 매우 느리고 불안정합니다. 따라서
00:04:53이러한 기술들을 따라 쇼핑 앱은 이미 완전한 네이티브로 전환을 마쳤습니다. 월간 다운로드 수가 3백만 회에 달하는 앱 말이죠.
00:04:59여기서 주의할 점은 쇼피파이는 물론 거대 기업이라는 것입니다. 여러분이 직접 두 개의 앱을 유지보수해야 하는 것은 여전하겠지만,
00:05:06이것이 오늘날 모델들로 가능한 수준이며, 향후 몇 달 및 몇 년 동안
00:05:11이 과정은 훨씬 더 쉬워질 것입니다. 그리고 이것이 리액트 네이티브의 가치를 더욱 갉아먹기 시작할 것이라고 생각합니다.
00:05:17쇼피파이는 주간 다운로드 수 200만의 플래시리스트(FlashList)를 포함하여 몇 가지 주요 오픈소스 패키지를 유지보수해 왔으며,
00:05:23리액트 네이티브 스키어(Skia)와 리스타일(Restyle) 등도 있습니다. 이 모든 패키지들이 이제 서드파티 유지보수자들에게 인계되고 있습니다.
00:05:30따라서 쇼피파이는 리액트 네이티브와 완전히 손을 떼는 것으로 보입니다.
00:05:36에어비앤비(Airbnb) 역시 아주 오래전에 iOS, 안드로이드, 그리고 브리지를 유지보수하는 것이
00:05:43하나가 아니라 세 개의 플랫폼을 관리하는 것과 같았기 때문에 리액트 네이티브를 떠났습니다. 저 역시 수년 동안 리액트 네이티브로 개발하는 것을 사랑했고 제 커리어의 대부분을
00:05:50그 분야에서 보냈지만, 이것이 크로스플랫폼 기술의 종말의 시작이라고 생각합니다. 에이전트가 발전함에 따라
00:05:56어째서 성능과 클라우드 키트(CloudKit) 및 스위프트UI(SwiftUI) 같은 더 나은 플랫폼 네이티브 기능을 최적화하고 싶지 않겠습니까?
00:06:02물론 리액트 네이티브를 통해 이러한 시스템과 상호작용할 수도 있지만 성능은
00:06:08결코 그만큼 좋아질 수 없습니다. 여러분의 생각을 댓글로 알려주시고, 아직 구독하지 않으셨다면 구독해 주세요.
00:06:13우리는 끊임없이 기술 및 AI 콘텐츠를 발행하고 있으며, 다음 영상에서 뵙겠습니다.
커뮤니티 글
아직 글이 없습니다. 이 영상에 대한 첫 번째 글을 작성해 보세요!
이 영상에 대해 글쓰기