앱 개발

쇼피파이가 React Native를 떠났어요 | 우리 앱 기술 선택에 볼 5가지

쇼피파이가 2020년부터 쓰던 React Native를 접고 Swift·Kotlin 네이티브로 앱을 다시 만들었어요. AI 에이전트로 12주 만에 재구축했고 안드로이드 실행 속도는 50% 빨라졌어요. 발주자가 앱 기술을 고를 때 이 소식에서 챙길 5가지를 정리했어요.

크리에이티브소프트
크리에이티브소프트
2026년 9월 16일 ·

핵심 요약

  • 쇼피파이가 2020년부터 주력으로 쓰던 React Native를 접고 Swift(iOS)·Kotlin(안드로이드) 네이티브로 앱을 다시 만들고 있어요.
  • 결정적 이유는 AI 코딩 에이전트였어요. 쇼핑 앱 Shop은 시제품부터 스토어 출시까지 12주 만에 새로 만들어졌고, 실행 속도는 iOS 23%·안드로이드 50% 빨라졌어요.
  • 그렇다고 “크로스플랫폼은 끝”이라는 뜻은 아니에요. 쇼피파이 스스로 두 플랫폼을 따로 유지하는 비용은 사라지지 않았다고 적었어요.
  • 앱 개발을 앞둔 발주자가 이 소식에서 챙길 판단 기준 5가지를, 앱을 직접 만들고 운영해온 개발사 관점으로 정리했어요.

📰 2026년 9월 17일 기준 최신 소식 | 이 글은 특정 시점의 뉴스를 다루고 있어요.

“쇼피파이도 네이티브로 갔다는데, 저희도 처음부터 네이티브로 해야 하나요?”

이번 주 앱 개발 상담에서 나올 법한 질문이에요. 큰 회사가 기술을 바꾸면 그 결정이 정답처럼 들리거든요. 그런데 쇼피파이의 발표를 끝까지 읽어 보면 결론보다 조건이 더 많이 적혀 있어요. 그 조건을 우리 프로젝트에 대입해 보는 게 이 소식을 제대로 쓰는 방법이에요.


1. 쇼피파이는 무엇을 바꿨나요

서울 스타트업 사무실에서 아이폰과 안드로이드 폰에 같은 쇼핑 앱을 띄워 비교하는 개발자

쇼피파이는 2020년 “모바일의 미래는 React Native”라고 선언했고, 2025년 1월에도 그 방향을 다시 확인했던 회사예요. 그런 회사가 2026년 9월 네이티브로 돌아간다고 발표했어요.

공식 엔지니어링 블로그와 InfoQ 기사(2026년 9월 16일)에 나온 숫자는 이래요.

항목발표 내용
재구축 기간Shop 앱, 시제품 → 스토어 출시 12주
투입시제품 엔지니어 1명(1주) → 본개발 6명 (InfoQ 보도)
실행 속도iOS 23%, 안드로이드 50% 단축
안정성비정상 종료 없는 세션 비율 99.5% → 99.95%
안드로이드 용량109MB 감소
남은 일정화면 300개가 넘는 Shopify 앱은 2026년 안에 전환 예정

공식 외부 기준 — 쇼피파이 엔지니어링 블로그 “Native is now the future of mobile at Shopify”와 InfoQ 보도를 기준으로 했어요. 성능 수치는 쇼피파이 자체 측정값이에요.

2. 왜 지금 바꿨을까요 — AI가 “두 번 만드는 비용”을 줄였어요

회의실 모니터에 AI 코딩 에이전트가 화면 코드를 옮기는 과정을 띄워 놓고 논의하는 모바일 개발팀

크로스플랫폼을 쓰는 가장 큰 이유는 한 번 만들어 두 플랫폼에 내보내는 것이었어요. 네이티브는 iOS와 안드로이드를 따로 만들어야 하니 인력과 시간이 거의 두 배로 들었고요.

쇼피파이 모바일 총괄 무스타파 알리는 이 계산이 뒤집혔다고 봤어요. AI 모델이 iOS 코드를 보고 안드로이드 버전을 만들고, 반대 방향도 해내면서 두 벌을 만드는 부담이 크게 줄었다는 거예요. 쇼피파이는 발표에서 이렇게 적었어요.

“에이전트가 구현을 공유하는 이점은 줄였고, 플랫폼별로 만드는 이점은 그대로 남았다.”

여기서 발주자가 기억할 건 한 줄이에요. 기술 선택의 기준이 되던 비용 구조가 AI 때문에 움직이고 있어요. 2~3년 전 견적 논리를 그대로 믿으면 안 되는 이유예요.

12주는 AI 혼자 만든 숫자가 아니에요

화이트보드에 화면별 체크포인트와 테스트 통과 여부를 표시하며 검수하는 QA 담당자

“12주 만에 재구축”이라는 숫자만 떼어 보면 AI에게 맡기면 끝나는 것처럼 들려요. 쇼피파이가 만든 작업 흐름 Helix를 보면 그렇지 않아요.

  1. 개발자가 옮길 화면을 지정해요.
  2. 에이전트가 기존 React Native 코드를 읽고 단계별 체크포인트를 제안해요.
  3. 체크포인트마다 테스트로 동작을 증명하고, 실행 중인 앱과 화면을 대조하고, 적대적 코드 리뷰를 두 번 통과해야 해요.
  4. 마지막으로 사람이 승인해야 다음 단계로 넘어가요.

InfoQ도 구조 설계와 작업 계획, 완료 검증, 오류 수정에 개발자가 깊게 관여했다고 전했어요. 줄어든 건 코드를 옮겨 적는 시간이고, 무엇이 맞는지 판정하는 일은 사람에게 남았어요.

운영사 Tip — 저희도 자체 서비스를 운영하며 자동화 결과를 “돌았다”가 아니라 “기록으로 확인했다”로 판정해요. AI가 만든 앱 코드도 같아요. 견적서에 테스트 코드와 리뷰 기록이 산출물로 들어가 있는지 보세요. 이 둘이 없는 “AI로 빠르게”는 속도만 사고 검수는 발주자에게 넘기는 셈이에요.

3. 첫째, 우리 앱이 쇼피파이와 같은 조건인지 봐요

노트북에 앱 화면 목록과 위젯·워치 기능 표를 띄워 규모를 세어 보는 기획자

쇼피파이가 네이티브로 가서 얻은 것들은 앱이 크고 오래 운영될 때 커지는 이득이에요. 우리 앱을 이 표에 대 보세요.

확인할 것네이티브 쪽이 유리크로스플랫폼도 충분
화면 수수십~수백 개20~30개 안팎
기기 기능위젯·워치·블루투스·카메라 깊은 연동일반 화면·결제·푸시
성능 민감도긴 피드 스크롤, 실행 속도가 매출과 직결조회·신청 위주
운영 기간5년 이상 핵심 채널검증용·기간 한정
사내 역량두 플랫폼 코드를 검수할 사람이 있음외부에 유지보수를 맡김

왼쪽이 많을수록 native app을 진지하게 검토할 만해요. 오른쪽이 많다면 쇼피파이 소식은 참고만 하면 돼요. 두 방식의 비용 차이는 크로스플랫폼 vs 네이티브, 비용과 유지보수 비교에 따로 정리했어요.

4. 둘째, 업데이트를 얼마나 자주 할지 정해요

스마트폰 앱스토어 심사 대기 화면을 확인하며 출시 일정을 조정하는 마케팅 담당자

InfoQ 기사에 달린 개발자 의견 중 가장 많이 짚은 게 이 부분이었어요. React Native 계열은 스토어 심사 없이 일부 화면을 바꾸는 무선 업데이트를 쓰는 경우가 있는데, 완전 네이티브로 가면 그 길이 좁아져요.

  • 이벤트·공지 화면을 주 단위로 바꾸는 서비스라면 심사 대기가 운영 부담이 돼요.
  • 이런 경우 자주 바뀌는 화면만 웹 화면으로 앱 안에 넣는 설계도 방법이에요.
  • 반대로 기능 변경이 분기 단위라면 심사는 큰 문제가 아니에요.

웹 vs 앱을 어디서 나눌지는 앱 vs 웹 vs PWA, 첫 출시엔 무엇이 맞을까요에 기준을 적어뒀어요.

5. 셋째, “옛 구조와 비교한 숫자”라는 점을 기억해요

모니터에 이전 버전과 새 버전 앱의 실행 속도 그래프를 나란히 띄운 성능 분석 화면

실행 속도 50%, 비정상 종료 10분의 1은 인상적인 숫자예요. 다만 커뮤니티에서는 React Native 옛 구조와 비교한 결과라는 지적이 나왔어요. React Native의 새 구조로 옮겼다면 격차가 얼마였을지는 공개되지 않았어요.

그래서 우리 프로젝트에 가져올 건 숫자 자체보다 측정 항목이에요.

  • 앱을 처음 켤 때까지 걸리는 시간
  • 비정상 종료 없는 세션 비율
  • 설치 용량

리뉴얼이나 기술 전환을 발주할 때 이 세 가지를 전후로 재서 보고받는 조건을 넣어 두면, “빨라졌어요”라는 말 대신 숫자로 검수할 수 있어요.

6. 넷째, AI 에이전트 도입과 앱 발주는 따로 판단해요

사무실 책상에서 사내 업무 자동화 계획서와 앱 개발 제안서를 따로 펼쳐 검토하는 IT 기획 담당자

쇼피파이는 앱을 만드는 회사가 자기 개발 방식에 AI 에이전트를 도입한 사례예요. 발주사 입장에서 AI 에이전트 도입을 떠올리면 보통은 사내 업무(문서·고객 응대·데이터 조회) 쪽이죠. 둘은 필요한 준비가 달라요.

구분앱 개발에 AI 활용사내 AI 에이전트 도입
누가 쓰나개발사·개발팀현업 부서
핵심 준비물테스트·리뷰 기준업무 절차서·데이터 권한
발주자가 볼 것산출물에 검증 기록이 있나에이전트가 어디까지 손대나

“AI 자체 도입과 외주 개발 중 어떤 선택이 맞나요?”라는 질문도 이 표로 나눠 보면 답이 쉬워져요. 개발사가 AI를 쓰는 건 개발사의 효율 문제이고, 사내 AI 에이전트는 우리 조직의 운영 문제예요. AI가 만든 코드의 책임 범위는 AI가 보낸 코드, 누가 확인하나요에서 다뤘어요.

7. 다섯째, 견적에서 달라진 부분을 물어봐요

개발사 담당자와 발주사 실무자가 태블릿에 띄운 견적서 항목을 함께 짚어 보는 모습

AI 코딩이 개발 방식을 바꾸고 있으니 견적서도 예전과 같은지 물어볼 때가 됐어요. 저희가 권하는 질문은 세 가지예요.

  1. “AI 도구를 쓰면 어느 단계가 줄어드나요?” — 옮겨 적기·반복 화면은 줄 수 있어요. 기획·설계·검수 기간까지 같이 줄었다면 근거를 물어보세요.
  2. “테스트 코드와 리뷰 기록도 넘겨주시나요?” — 쇼피파이가 12주를 지킨 장치가 바로 이거예요.
  3. “두 플랫폼을 따로 만든다면 유지보수는 어떻게 나누나요?” — 네이티브는 출시 뒤에도 두 벌을 고쳐요. 운영비가 어떻게 잡히는지 확인하세요.

앱 개발 비용 전체 범위는 앱 개발 비용, 2026 유형별 견적 기준에 정리해 뒀어요.

기술 선택이 아직 흐릿해도 괜찮아요. 우리 앱의 화면 수와 운영 계획부터 같이 적어 보면 방향이 잡혀요. 앱 기술 선택부터 함께 따져볼게요 →

저희는 10년 넘게 50개 이상의 프로젝트를 만들고 자체 SaaS 4종을 지금도 직접 운영하는 개발사예요. 코닥 인스턴트 프린터 연동 앱처럼 기기와 붙는 앱도 만들어 봤고, 롯데·캐논 같은 곳과도 함께해 왔어요. 출시 뒤 고치는 쪽까지 겪어 봤기에 “처음에 무엇으로 만들까”를 운영 기준으로 말씀드릴 수 있어요.

8. 자주 묻는 질문

쇼피파이가 옮겼으니 React Native나 크로스플랫폼은 이제 피해야 하나요?

그렇게 읽을 소식은 아니에요. 쇼피파이 엔지니어링 블로그도 React Native 앱이 빠를 수 있다고 적었고, 네이티브는 여전히 두 플랫폼을 따로 만들고 유지하는 비용이 든다고 밝혔어요. 쇼피파이는 수백 개 화면과 위젯·워치 앱까지 가진 큰 앱이고, AI 에이전트 작업 흐름을 직접 만들 수 있는 팀이 있었어요. 화면 수가 적고 출시가 급한 앱이라면 크로스플랫폼이 여전히 합리적인 경우가 많아요.

AI 에이전트로 앱을 다시 만들면 외주 비용도 크게 줄어드나요?

일부 작업은 줄어요. 다만 쇼피파이 사례에서도 사람이 화면마다 작업을 지정하고, 테스트·화면 비교·코드 리뷰를 통과한 결과를 승인했어요. 줄어드는 건 옮겨 적는 시간이고, 기준을 세우고 검수하는 시간은 그대로 남아요. 견적에서 테스트와 검수 항목이 빠져 있다면 오히려 확인해야 해요.

AI 자체 도입과 외주 개발 중 어떤 선택이 맞나요?

사내에 앱 코드 기준(테스트·리뷰 규칙)을 세울 사람이 있다면 AI 코딩 도구를 내부에 들여 속도를 올릴 수 있어요. 그런 사람이 없다면 AI를 쓰는 개발사에 맡기되, 산출물에 테스트 코드와 리뷰 기록을 포함해 달라고 계약에 적는 편이 안전해요. 사내 AI 에이전트를 붙이는 일과 앱을 새로 만드는 일은 필요한 역량이 달라서 따로 판단하는 게 좋아요.

네이티브로 가면 앱 업데이트가 느려지나요?

그럴 수 있어요. React Native 같은 방식은 스토어 심사 없이 일부 화면을 고치는 무선 업데이트를 쓰기도 하는데, 완전 네이티브는 대부분의 변경이 앱 심사를 거쳐요. InfoQ 기사에 달린 개발자 의견에서도 이 점이 단점으로 꼽혔어요. 공지·이벤트 화면을 자주 바꾸는 서비스라면 그 부분을 웹 화면으로 두는 설계를 함께 검토해 보세요.

9. 마무리

쇼피파이 소식의 핵심은 “네이티브가 이겼다”가 아니에요. AI가 개발 비용 구조를 바꾸자, 큰 회사가 5년 된 기술 결정을 다시 계산했다는 거예요.

앱을 준비 중이라면 한 가지만 해 보세요. 우리 앱의 화면 수, 꼭 필요한 기기 기능, 업데이트 주기를 한 줄씩 적어 보는 것. 그 세 줄이 기술 선택 회의의 출발점이 돼요.

함께 보면 좋은 글