(Toss SLASH 22) 미친 생산성을 위한 React Native

아래 내용은 토스ㅣSLASH 22 - 미친 생산성을 위한 React Native
을 보고 정리한 내용입니다.

TL:DR; RN의 코드푸시 기능이 MVP 개발 철학과 아름답게 잘 어울린다!

기존 구조의 문제점

동남아시아에서 서비스 중인 토스 글로벌 팀은 프론트엔드, 안드로이드, IOS 개발자 각각 1명, 서버 개발자 2명으로 구성된 팀으로써, 개발을 진행할 수록 느린 배포 속도, 개발 리소스 부족의 문제가 발생하게 되었다.

느린 배포 속도

1. Xcode를 사용하는 IOS 개발자는 고질적으로 "빌드 속도"에서 문제가 발생했다
2. 앱스토어의 특성상 심사 기간이 최대 4주까지도 걸렸다.
3. 동남아시아의 지역적인 특성상 업데이트를 자주하지 않아, 실험적인 기능은 앱을 새로 설치하는 유저를 대상으로 테스트할 수 밖에 없다.

개발 리소스 부족

1. 플랫폼간의 차이때문에, 같은 기능인데도 다른 구현 방식이 일관성을 헤쳤다.
2. 플랫폼에 대해 개발자 의존적인 문제가 발생했다 (Ex: IOS 개발자가 휴가를 가면 아무도 IOS를 못건드리는 문제)

문제 해결을 위한 옵션

1. 앱의 모든 Flow를 웹으로 만드는 것

   1-1. 앱을 켤때마다 매번 최신 리소스를 다운로드하기에 유저들에게 일괄적으로 최신 기능을 제공할 수 있다는 장점이 있으나 네트워크 환경에 의존적이다.

   1-2. 성능적인 한계를 극복할 수 없다.

   -> 종합해볼때, 동남아시아라는 지역적 특수성때문에 단점이 크게 부각되어 선택할 수 없다.

2. 크로스 플랫폼 프레임워크를 사용하는 것
   Flutter: 공식 라이브러리가 잘 되어있다. RN보다 많이 사용된다. 높은 학습비용
   React Native: 채용 풀이 넓다. 공식 라이브러리 생태계가 빈약하다. + CodePush를 사용할 수 있다

💡 CodePush란, MS에서 만든 오픈소스로서 앱을 심사없이 실시간 업데이트를 가능하게 해주는 모듈이다. RN에서는 JS단의 코드와 assets(이미지, 폰트, ...)의 요소를 앱 심사 없이 바로 업데이트 할 수 있다.
(단, 네이티브 영역의 코드가 변경되어야 한다면, CodePush를 사용할 수 없다. JS수정시만 가능!)

RN 도입

빠른 실험과 배포, 낮은 학습비용을 이유로 RN으로 선택했다. RN을 기존 코드에 부분적으로 도입할 것인지, 처음부터 다시 만들 것인지를 선택해야하는 상황에서 병렬적으로 두 트랙 모두 진행.

부분적으로 도입하기

RN을 기존 네이티브 앱에 점진적으로 적용이 가능하고, 기존 코드와 모듈 활용 할 수 있다. 그리고 마이그레이션 이슈로 부터 자유롭다.

But, 다음과 같은 문제가 생겼다.

• React Native와 기존 Native 앱간의 통신 고도화 이슈
• 기존 프로젝트에 RN을 위한 추가 작업
• 여전히 각각의 플랫폼 네이티브 앱에 작업을 해야하는 상황은 여전하다.

결론적으로, 처음부터 다시 개발하는 것을 선택

크로스 플랫폼을 이점을 최대한 살리고 싶었다. (하나의 개발, 두개의 플랫폼)

• 기존에 사용하던 TDS(Toss Design System)은 웹 용이라 React Native용을 따로 만드는 추가 비용이 발생했다.

• 구현 과정에서 Native 코드를 사용해야하만 하는 일과 JS로만 할 수 있는 일 2가지로 분류해, 최대한 기존 팀의 리소스가 효율적으로 사용될 수 있도록 진행

RN을 적용 후 느낀 장점

역시, CodePush!

• 유저들이 앱을 업데이트할 필요가 없어졌다.
• 플랫폼 간의 UI 일관성이 적용되었다.
• 개발 속도가 빨라졌다. (핫 리로딩)
• 프론트엔드 개발자로서 저렴한 학습 비용, 역할의 확장의 장점이 있었다.
• 빠르게 실패와 개선 과정을 반복할 수 있다.