Coinbase의 React Native 도입기
(blog.coinbase.com)최근 Coinbase 개발자가 새로운 Coinbase 앱이 RN 으로 작성되었음을 트위터에서 공유해서 소소한 화제가 되었는데(https://twitter.com/htormey/status/1392161714250993667), 그에 대한 자세한 내용이 Medium 글로 공유되었네요. 관련 트윗 타래에 의하면 일부 네이티브 모듈이 있긴 하지만, 앱 코드베이스의 97% 정도가 TypeScript 라고 합니다.
이하 원문 내용 요약 번역:
- iOS, Android 네이티브 앱이 이미 있는 상황에서 RN 으로 마이그레이션. 마이그레이션 과정에서 200개 이상의 화면 규모의 거대한 네이티브 앱을 다시 구현해야 했고, 30명 이상의 기존 네이티브 엔지니어들에겐 전환을 위한 사내 RN 강의도 제공.
- 많은 노력 끝에 네이티브 시절에 비해 퍼포먼스 지표, 비즈니스 지표, 앱 평점, 7 day crash free 유저 퍼센트, Cold Start 에 걸리는 시간, 탭 전환 시간 등 주요 지표가 모두 유지 혹은 개선되었음.
- 2013년에 첫 앱이 출시되고, 2017년쯤 되었을 때 Android/iOS 각각 작은 규모의 팀이 있었는데 채용이 웹 개발자에 비해 너무 어려웠고, 웹 플랫폼 기술의 발전 속도로 인한 생산성을 네이티브 플랫폼 기술이 못 따라온다고 느낌. 몇 번의 시도 실패 이후 2018년에는 모바일 플랫폼의 이터레이션 속도 및 성장율의 개선이 필요함이 명백해짐.
- Coinbase 가 제품을 어떻게 만드는지 바닥부터 다시 생각해보기로 함. 주요 피쳐는 기능 조직으로 백엔드 2명 + 각 플랫폼 (Web, Android, iOS) 마다 클라이언트 2명이 존재해, 하나의 버티컬을 위해 너무 많은 인력이 필요했음. 한 기능 팀의 최소 개발자 수를 8명을 5명 정도로 줄이고, 클라 개발자가 여러 플랫폼을 다 커버할 수는 없을까 라고 생각하게 됨.
- 이로 인해 팀 구성 최소 요건이 완화되고, 더 효율적인 개발이 가능해지고, 클라이언트 개발자끼리의 접점이 늘어날 것을 기대함. 물론 효율만으로는 충분하지 않고, 그 과정에서 고객이 느끼는 성능과 퀄리티 또한 개선이 되어야만 그 투자가 정당화 가능하다고 생각.
- 당시 이미 React 기반의 꽤 성숙한 웹 플랫폼 팀이 존재했음. 여러 크로스 플랫폼 검토 후에, 기존에 사용 중인 익숙한 기술에 기반하고, 웹과 모바일의 통합을 위한 경로가 클리어해 보이는 RN을 선택함. 이미 돌아가고 있는 네이티브 앱도 마이그레이션 해야 했기 때문에, 점진적이고 충격 없는 마이그레이션을 위해 몇 달의 사전 기술 검토 및 전략 수립 기간을 거침
- 일단 RN과 네이티브가 연동될 필요가 없는 greenfield 부터 시작하는게 좋겠다고 생각함. Coinbase 내에서도 복잡하고 실시간 가격 차트나 depth chart 등의 성능이 중요한 기능이 많은, 당시 모바일 제공하지 않던 Pro 라는 웹 제품을 앱으로 먼저 만들어 보기로 결정함. Pro 를 RN 으로 잘 만들 수 있다면 나머지 (덜 복잡하고 성능 요구사항도 덜 빡센) 기능도 무난하고 옮겨올 수 있을거라고 가정.
- 그 다음으로는 Pro와 기존 앱이 공유하는 온보딩 플로우를 RN으로 구현한 걸 기존 네이티브 앱에 붙여봄. 서비스 지역이 다양하다보니 온보딩 파트가 앱에서 가장 복잡한 부분 중 하나여서, 기존에 손대기가 너무 어려운 부분이었음. Pro 에서 새로 만들면서 기존 앱의 리팩토링도 겸할 것을 기대.
- 마지막으로 앞의 두 과정에서 얻은 경험과 지식을 바탕으로 기존 네이티브 앱을 RN으로 재작성. 일단 계획을 세울 때는 full rewrite 가 될지 네이티브 앱에 점진적으로 RN 비중을 늘리는 형태가 될지는 물음표였고, 앞선 두 단계의 결과에 따라 결정하기로 함.
- 전략을 세우고, 2019년 10월에 Pro 모바일 앱 출시했고, 결과는 기대 이상이었음. 비즈니스 성과도 좋고, 성능 문제가 되는 지점과 해결책에 대해 배웠으며, RN이 제공하는 생산성에 매우 만족했고, 짧은 시간 내에 웹 엔지니어가 RN 에서 생산성 낼 수 있다는 것도 확인함.
- 고무된 채로 온보딩 플로우 재작성도 시작, 마찬가지로 비즈니스, 앱 퀄리티 모두 목표 달성
온보딩 플로우 재작성 자체의 결과는 좋았지만, 기존 앱에 RN을 붙이는 게 어렵다는 걸 깨달음.
웹만 하거나 네이티브만 하는 것에 비해 생산성도 안 좋아서 양 쪽 모두에서 ‘이럴거면 RN 왜 쓰냐’ 싶은 엔지니어들이 나옴. (Airbnb 의 사례와 매우 비슷하고, 실제로 Airbnb 엔지니어들이랑 얘기하면서 많이 배움)
- 결과적으로 위의 교훈들을 통해 네이티브와 RN을 함께 가져가는 brownfield 접근이 모든 문제의 근원이라 판단하고, 기존 앱 전체를 RN으로 재작성하기로 결정.
- 두 플랫폼 중 안드로이드 앱 마이그레이션이 성능, 퍼포먼스, 생산성 등에서 더 어려울 것 같아서 안드로이드를 먼저 재작성 타겟으로 잡음. 앞선 경험으로 full rewrite는 6개월 정도 걸릴 거라고 예상했지만, 결과가 가져다 주는 이득이 비용을 상회할 거라고 예상.
- 2020년 3월에 안드로이드 앱 재작성을 시작해 실제로 6개월 정도 걸림. 이후 이어진 iOS 재작성도 2021년 1월에 끝남. 양 플랫폼 모두에서 핵심 지표가 좋은 성과를 보임.
- 2020년 중순에 코인베이스에는 18명의 iOS 엔지니어, 7명의 안드로이드 엔지니어가 있었음. 2021년 5월 현재 코인베이스 RN 저장소에는 113명의 컨트리뷰터가 있고, 그 중 그 전까지는 모바일에 기여할 수 없던 웹 엔지니어도 다수.
- 네이티브 엔지니어의 RN 엔지니어로의 전환을 위한 트레이닝은 큰 마찰 없이 진행되었고, 기존 네이티브 백그라운드 엔지니어들은 현재 RN 앱에서 높은 성과를 내는 중. 아직 완벽하진 않지만, 처음 기대했던 대로 각 기능 조직에서는 하나의 ‘클라이언트 팀’ 이 모든 클라이언트 플랫폼을 커버하는 형태가 되어가고 있음.
- 세 개 (React, iOS, Android) 이던 플랫폼이 두 개 (React, RN) 가 되었지만 다음 스텝으론 그걸 1.5개로 줄여보려고 함. 웹과 RN 에서 공유하는 디자인 시스템, GraphQL 기반의 공용 데이터 레이어, 인프라적인 툴링 등의 공유를 계획 중. 한 엔지니어가 최소한의 컨텍스트 스위칭만으로 웹과 모바일 모든 플랫폼에서 기능을 배포할 수 있는 그림을 그리고 있음.
- 앞으로 기술적인 난관과 그 과정에서 얻은 경험 등 RN 관련 더 많은 아티클 공유할 예정.
라프텔의 RN 도입기가 생각나네요.
https://ridicorp.com/story/react-native-1year-review/