Shopify, React Native에서 AI 기반 네이티브로 전환

이전에는 지속적인 기능 출시를 방해하지 않기 위해 기존 방식이 선호되었지만, 대규모 언어 모델(LLM) 및 AI 에이전트의 등장으로 완전히 새로운 전략이 가능해졌습니다. 이러한 새로운 접근 방식은 AI 지원을 통해 단 12주 만에 Shopify 앱을 성공적으로 재구축함으로써 입증되었습니다.

회사는 네이티브 코드로의 점진적인 마이그레이션과 즉각적인 완전 재구축 사이에서 고민해 왔습니다. 그러나 AI 기반 프로토타입, 특히 에이전트와의 유망한 결과가 완전히 새로운 전략을 추구하기로 결정하는 데 결정적인 역할을 했습니다.

AI 기반 코드 마이그레이션을 효과적으로 관리하기 위해 Shopify는 'Helix'라는 시스템을 개발했습니다. 이 시스템은 단일의 완벽한 결과에 의존하기보다는 AI 생성 코드의 품질을 보장하기 위해 점진적인 루프 기반 접근 방식을 사용합니다. Helix는 체크포인트, 시각적 검토, 사람의 승인을 중요한 단계로 통합합니다.

이 시스템은 LLM 결과물의 일반적인 문제인 유지 보수 불가능한 코드가 진행되지 않도록 미리 정의된 품질 표준을 충족할 때까지 불완전한 시도가 진행되지 않도록 보장하여 문제를 해결하도록 특별히 설계되었습니다.

이러한 분리는 모바일 시뮬레이터가 너무 느려 AI 에이전트의 피드백 루프 효율성을 저해하기 때문에 중요합니다.

비즈니스 로직을 CLI(명령줄 인터페이스)를 통해 에이전트에 액세스할 수 있도록 함으로써 Shopify는 에이전트가 기존 시뮬레이터와 관련된 지연을 우회하여 몇 분이 아닌 밀리초 단위로 코드를 반복할 수 있도록 합니다.

이러한 업데이트를 통해 개발자는 전체 앱을 앱 스토어에 재제출할 필요 없이 즉각적인 수정 사항과 사소한 변경 사항을 구현할 수 있으며, 이는 시간이 오래 걸릴 수 있는 과정입니다.

네이티브 개발은 종종 앱 스토어 지연 및 업데이트의 느린 사용자 채택으로 어려움을 겪어 신속한 버그 수정을 어렵게 만듭니다. OTA 업데이트는 이러한 문제를 우회하여 개발자가 중요한 패치를 즉시 배포할 수 있도록 합니다.

이 기능은 특히 사용자 기반에서 다양한 앱 버전을 관리하는 복잡성을 고려할 때 앱 안정성과 사용자 경험을 유지하는 데 중요합니다. OTA 업데이트가 없으면 버전 문제로 인해 React Native가 아닌 애플리케이션의 경우 상당한 지원 비용이 발생할 수 있습니다.

이러한 입장은 주로 모든 중요한 기능이 엄격한 검토 프로세스를 거쳐 플랫폼 일관성과 보안을 보장하기를 선호하기 때문입니다. 그럼에도 불구하고 특정 목적을 위한 OTA 사용은 잘 확립되어 있습니다.

개발자는 작은 버그 수정, 사소한 사용자 인터페이스 조정 및 임시 기능 플래깅을 위해 OTA 업데이트를 효과적으로 활용합니다. 이를 통해 앱 스토어 제출 및 검토 주기를 거칠 필요 없이 즉각적이고 영향이 적은 변경이 가능합니다.

이는 개발자 경험을 크게 향상시키는 필수 도구를 제공합니다.

Expo는 개발자 빌드 서명 간소화 및 복잡한 네이티브 구성 관리와 같이 React Native 개발의 중요한 문제점을 해결하며, 이는 그렇지 않으면 상당한 장애물이 될 수 있습니다. 포괄적인 도구 모음은 개발 워크플로우를 간소화하는 데 도움이 됩니다.

Shopify가 React Native에서 겪는 어려움은 부분적으로 Expo를 효과적으로 활용하지 못했기 때문입니다. 이는 플랫폼의 잠재력과 사용 편의성이 Expo와 같은 강력한 도구와 함께 사용될 때 가장 잘 실현된다는 것을 시사합니다.

React Native 앱이 네이티브 앱보다 상당히 크다는 일반적인 인식은 최근 연구 결과에 의해 도전받고 있습니다. Shopify는 네이티브로 마이그레이션한 후 예상과 달리 앱 크기가 단 1메가바이트만 절약되는 것을 관찰했습니다.

React Native 런타임 자체는 특별히 크지 않은 것으로 밝혀졌습니다. 대신 앱 부풀림의 주요 원인은 일반적으로 미디어 자산 및 현지화 파일이며, 이는 기본 프레임워크와 무관합니다. 네이티브 코드로 앱을 다시 작성함으로써 상당한 크기 또는 성능 향상을 얻을 수 있다는 믿음은 종종 '제2의 시스템 효과'이며, 기술의 근본적인 결함이라기보다는 인지된 이점이 실제 개선 사항보다 클 때 발생합니다.

개발 환경에서 중요한 관찰은 일반 React Native 개발자와 일반 네이티브 개발자 사이의 주장되는 기술 격차입니다. React Native에 대한 진입 장벽이 낮으면 경험이 적은 팀을 유인하는 경향이 있어 이러한 인지된 격차에 기여합니다.

이것은 React Native 자체가 열등한 기술이라는 것을 의미하지 않습니다. 오히려 그 인기와 접근성은 더 넓은 범위의 기술 수준에서 채택된다는 것을 의미합니다. 이 기술은 숙련된 팀의 손에 들어가면 강력할 수 있지만, '풋 건'(오용하기 쉬운 기능)은 능력이 떨어지는 개발자가 사용할 때 문제를 일으킬 수 있습니다.

발표자는 일반 React Native 개발자가 일반 네이티브 개발자보다 기술이 떨어진다고 주장하며, 이를 논쟁의 여지 없이 사실로 내세웁니다. 이 관점은 React Native에 자주 귀속되는 문제가 사실은 프레임워크의 본질적인 결함보다는 개발 팀의 기술 수준 때문이라는 것을 시사합니다.

Shopify의 기술 결정은 창립자 Toby Lütke의 갑작스러운 개입에 의해 자주 형성됩니다. '창립자 모드'라고 불리는 이 현상은 팀 구성원들이 변화의 필요성을 인지하지만 스스로 시작하기를 주저할 때 발생하며, Lütke가 전제에 동의하면 개입하여 결정적인 결정을 내립니다.

Lütke는 과거에 회사 전체를 Ruby on Rails로 전환하도록 강요하는 등 이러한 영향력 있는 결정을 내린 역사가 있습니다. 최근에는 React 서버 컴포넌트의 등장으로 이러한 입장을 뒤집었는데, 이는 기술 발전에 따라 기꺼이 적응하려는 의지를 보여줍니다.

이러한 창립자가 주도하는 아키텍처 전환은 Shopify의 개발 문화의 특징이며, 팀이 아키텍처 정체에 직면했을 때 특히 중요한 전략적 방향이 종종 최고 수준의 개입으로 해결됩니다.

이 결과는 이러한 마이그레이션이 본질적으로 복잡하고 시간이 많이 걸린다는 통념에 크게 도전합니다.

AI 에이전트는 컴퓨터 비전과 상호 작용을 사용하여 마이그레이션 프로세스를 관리하는 루프에서 작동했습니다. AI가 가끔 UIKit 대신 SwiftUI를 선택했지만, 결과로 나온 네이티브 애플리케이션은 내비게이션 및 데이터 로딩 성능에서 현저한 개선을 보였습니다.

이 빠르고 대부분 자동화된 포팅 프로세스는 이전에는 사소하지 않고 리소스 집약적이라고 여겨졌던 개발 작업을 간소화하는 AI의 혁신적인 잠재력을 강조합니다. 달성된 효율성은 초기 예상을 훨씬 뛰어넘어 크로스 플랫폼 마이그레이션을 위한 새로운 패러다임을 제시합니다.

SwiftUI 목록에서 스크롤하는 경험은 예상보다 훨씬 나빴으며, 이전에는 앱 충돌로 이어졌던 성능 문제가 있었습니다.

이러한 속도 저하의 한 가지 원인은 로컬 폴더 내 파일의 자동 인덱싱이며, 이는 사용자 인터페이스의 응답성에 영향을 미칩니다. 이 문제는 SwiftUI의 약속과 특정 핵심 UI 구성 요소에서의 실제 성능 사이의 격차를 강조합니다.

주목할 만한 제한은 뒤로 제스처가 화면 왼쪽 1/4로 제한되며 개발자가 이 '여백'의 크기를 사용자 정의할 수 없다는 것입니다. 이러한 유연성 부족은 보다 유동적이고 직관적인 사용자 경험을 만들기 위한 노력을 방해할 수 있습니다.

흥미롭게도 Apple의 자체 내부 애플리케이션은 항상 네이티브 내비게이션 스택을 준수하지 않습니다. 이는 Apple조차도 최적의 사용자 경험을 유지하기 위해 더 큰 유연성의 필요성을 인식하고 있으며, 때로는 표준 네이티브 구성 요소 대신 사용자 지정 솔루션을 선택한다는 것을 시사합니다.

이러한 제한으로 인해 개발자는 미리 정의된 경계 내에서 작업해야 하므로 고도로 사용자 지정되거나 고유한 사용자 인터페이스를 목표로 할 때 어려울 수 있습니다. 내비게이션 제스처 여백과 같은 기본 상호 작용 영역을 조정할 수 없다는 것은 이러한 엄격한 제약을 보여줍니다.

이러한 성공은 AI 모델이 메인 React Native 브랜치에서 네이티브 빌드로 로직 동기화를 거의 완벽하게 처리할 수 있음을 보여줍니다.

발표자는 Shopify와 같은 대기업의 전문 팀이 유사한 작업에 어려움을 겪는 이유를 의문을 제기하며, AI 모델 선택이 요인이 될 수 있다고 제안합니다. 특히 Claude와 같은 모델에 과도하게 의존하고 OpenAI 모델을 충분히 사용하지 않는 것이 효과적인 포팅을 방해할 수 있음을 시사합니다.

이러한 강력한 포팅 기능은 AI 에이전트가 복잡한 크로스 플랫폼 코드베이스를 원래 의도와 기능을 보존하면서 네이티브 동등물로 번역할 수 있는 패러다임 전환을 나타냅니다. 이 기능은 이러한 마이그레이션이 광범위한 수동 노력을 필요로 하거나 실패하기 쉽다는 전통적인 가정을 약화시킵니다.

Legend List는 JS 계층 내에서 매우 효율적으로 설계된 JavaScript 기반 가상화 기능을 통해 우수한 성능을 보여줍니다. 이 디자인은 기본 플랫폼과 관계없이 원활하고 빠르게 작동할 수 있도록 합니다.

대조적으로, 대부분의 경쟁 목록 라이브러리는 목록 관리를 위해 네이티브 코드에 크게 의존하며, 이는 성능 병목 현상을 유발하고 크로스 플랫폼 유연성을 감소시킬 수 있습니다. Legend List의 순수한 JavaScript 핵심 로직은 React Native와 웹 환경 간의 이식성도 크게 향상시킵니다.

이 접근 방식은 중요한 기술적 이점을 강조합니다. 즉, UI 구성 요소를 JavaScript로만 가상화함으로써 개발자는 광범위한 호환성과 다양한 플랫폼 간의 쉬운 포팅을 유지하면서 높은 성능을 달성할 수 있습니다.

역사적으로 이 격차를 해소하는 것은 종종 Meta와 같은 회사의 고급 네이티브 엔지니어링 전문 지식에 의존했습니다.

그러나 AI 에이전트는 한때 깊은 네이티브 지식이 필요했던 코딩 작업을 처리할 수 있게 되었으며, 이러한 전문 지식의 중요성을 줄였습니다. 이러한 변화는 네이티브 코드의 내재된 이점이 자동화된 도구를 통해 더 넓은 범위의 개발자에게 더 쉽게 접근할 수 있게 된다는 것을 의미합니다.

AI 비서가 더욱 정교해짐에 따라 네이티브와 JavaScript 성능 또는 개발 복잡성 간의 구별이 줄어들어 경쟁의 장이 평준화됩니다. 이러한 변화는 성능을 최적화하기 위해 엘리트 네이티브 개발자에게 전통적으로 의존하는 것을 줄이며, 이제 많은 작업을 AI에 위임할 수 있습니다.

대신 '한 번 배우면 어디에서나 이해'로 틀이 잡혔습니다. 이 철학은 기존 React 지식을 적용하여 다양한 모바일 플랫폼의 미묘한 차이를 이해하는 것을 강조했습니다. 목표는 모든 플랫폼에서 동일한 코드베이스를 만드는 것이 아니라 익숙한 기술 세트를 활용하여 다른 환경을 위한 빌드를 만드는 것이었습니다.

이러한 맥락에서 AI 기반 개발은 프로세스를 더욱 간소화합니다. 이는 개발자가 기본 플랫폼에 관계없이 '한 번 배우면 어디에서나 이해' 패러다임 내에서 더 쉽게 작업할 수 있도록 합니다. AI 도구는 React 개념을 특정 네이티브 구현에 적용하는 데 도움을 줄 수 있으므로 크로스 플랫폼 개발을 위한 프레임워크를 더욱 접근하기 쉽고 강력하게 만듭니다.