개발/프론트엔드

📱 Shopify가 React Native 버리고 네이티브로 돌아간 이유

개발만빼고다잘함 2026. 9. 11. 11:48
반응형

 

2020년에 모바일 앱을 전부 React Native로 가기로 했던 Shopify가 2026년 9월 10일 블로그에 이제 네이티브가 자기들 모바일의 미래라고 썼다. 불과 20개월 전인 2025년 1월엔 같은 저자가 RN 앱은 빠르다며 화면 로드 500ms(P75) 아래를 자랑했던 회사다. RN으로 앱 굴리는 팀이라면 "그래서 우리도 접어야 하나"부터 떠오를 것이다.

먼저 결론을 잘못 읽지 말자. 이 글은 RN이 느리다고 말하지 않는다. Shopify 스스로 2020년엔 RN이 맞는 선택이었고 지금도 훌륭한 프레임워크라고 썼다. 바뀐 건 프레임워크가 아니라 계산식이다.

특히 유의해야 할 점은 이게 네이티브 전문가가 이미 있는 큰 회사 이야기라는 것이다. 이관 글 본문도 에이전트가 만든 코드가 중복과 아키텍처 드리프트, 성능 문제를 일으켜서 네이티브 전문성이 필수였다고 적었다.

2020년의 계산과 2026년의 계산

2020년에 RN을 고른 이유는 셋이었다. 한 번만 쓰기(Write it once), 인력이 플랫폼을 넘나들기(Talent portability), 더 많은 가치를 내놓기(Ship more value).

2026년 글의 한 문장이 이걸 뒤집는다. "LLMs changed one of the core assumptions behind our 2020 decision." 코딩 에이전트가 Swift와 Kotlin으로 각각 구현하는 비용을 확 낮추자 한 번만 쓰기의 값어치가 그만큼 깎였다는 논리다. 통역사를 두 명 고용하던 회사가 번역기가 좋아지자 각 나라 지사에 현지인을 뽑기로 한 것과 같다. 통역사가 무능해진 게 아니라 통역 비용이 사라진 것이다.

Shop 앱을 12주 만에 다시 만든 과정

Shop 앱이 첫 번째였다. 이관 글에 적힌 순서다.

  • 1주차 : 엔지니어 한 명이 코딩 에이전트와 기존 RN 앱을 SwiftUI 네이티브 앱으로 최대한 옮기는 실험
  • 이후 : 핵심 6명이 기반과 주요 사용자 흐름 구축, 중반부터 기능 팀 합류
  • 12주 : 개념 증명에서 앱스토어 게시까지

에이전트가 잘한 건 기능 포팅, 화면 뼈대, 데이터 연결, 애니메이션, 레이아웃 다듬기였다고 이관 글이 적었다. 어려웠던 건 기존 사용자 세션과 푸시 알림, 분석 이벤트를 깨지 않는 일이었다. 새로 짜는 것보다 옛것과 이어 붙이는 게 늘 더 힘들다.

결과 수치는 이관 글 기준이다.

항목 iOS Android
앱 시작 시간 3.2초 → 2.5초 (23% 개선) 4.4초 → 2.2초 (50% 개선)
앱 크기 1MB 증가 109MB 감소 (37.2%)
릴리즈 빌드 시간 변화 없음 75% 단축

세션 크래시율은 10배 줄어 crash-free 99.95% 이상이다. 2025년 글에서 RN 앱의 crash-free가 99.9% 이상이었으니, 원래 나쁘지 않던 걸 더 좋게 만든 셈이다.

내 프로젝트가 영향받는지 확인하기

Shopify가 만든 RN 라이브러리 세 개의 거취가 글에 나온다. FlashList는 주 약 200만 다운로드라 커뮤니티 이관을 논의 중이고, React Native Skia는 2026년 말까지만 후원하며, Restyle은 아카이브한다.

프로젝트 루트에서 셋 중 뭐를 쓰는지부터 보자.

# 세 라이브러리 중 설치된 것만 출력한다
npm ls @shopify/flash-list @shopify/react-native-skia @shopify/restyle 2>/dev/null | grep shopify

쓰고 있다면 package.json에서 버전을 고정해 두는 게 먼저다. 이관이나 아카이브 뒤에 캐럿(^) 범위로 예상 못 한 버전이 들어오는 걸 막는다.

{
  "dependencies": {
    "@shopify/flash-list": "2.3.2",
    "@shopify/react-native-skia": "2.11.2",
    "@shopify/restyle": "2.4.5"
  }
}

위 버전은 글 쓰는 시점의 최신값이고, 캐럿을 뺀 게 요점이다.

내 맥에서 최신 배포 시각을 찍어보면 이렇다. Skia는 9월 1일에도 배포됐고, Restyle은 4월이 마지막이다.

# 최신 버전과 마지막 배포 시각만 본다
$ npm view @shopify/flash-list version time.modified
version = '2.3.2'
time.modified = '2026-06-10T06:06:04.941Z'

$ npm view @shopify/react-native-skia version time.modified
version = '2.11.2'
time.modified = '2026-09-01T18:52:52.308Z'

$ npm view @shopify/restyle version time.modified
version = '2.4.5'
time.modified = '2026-04-16T14:50:12.899Z'

Restyle을 테마 시스템으로 깔고 앉은 프로젝트라면 지금부터 대체를 찾는 게 맞다. FlashList는 규모상 누군가 이어받을 가능성이 높으니 급하지 않다.

우리 팀에 적용할 때

HN 스레드에서 눈에 띄는 반응은 "팀 상황에 따라 다르다"였다. 두 코드베이스의 기능 동등성을 맞추는 건 엔지니어링보다 조직 문제라는 지적, 대규모 재작성이 망한 사례를 든 경고도 있었다.

판단하자면 iOS·Android 전문가가 각각 있고 에이전트 코드를 리뷰할 사람이 있는 팀은 Shopify 계산이 그대로 적용된다. 웹 개발자 서넛이 RN 하나로 버티는 팀은 전제가 다르다. 그 팀에서 두 번 만드는 비용을 깎아주는 건 에이전트가 아니라 여전히 RN이다.

당장 할 일은 위 명령 한 줄로 의존성을 확인하는 것 정도다. 뭐를 쓰는지 알고만 있어도 후원이 끝날 때 당황하지 않는다.

참고

반응형

'개발 > 프론트엔드' 카테고리의 다른 글

🧯 Sentry 에러 로그 자세히 남기기 · v11은 기본 수집이 늘었다  (0) 2026.10.23
⚡ Next.js prefetch false 언제 쓰나 · 기본값과 서버 부하  (0) 2026.10.23
⚛️ React 19.3 출시, ViewTransition canary 없이 쓴다  (0) 2026.09.16

'개발/프론트엔드'의 다른글

  • 현재글📱 Shopify가 React Native 버리고 네이티브로 돌아간 이유

관련글

티스토리툴바