리액트 네이티브로 13년 된 네이티브 앱 전환하기

리디북스가 네이티브 앱에서 리액트 네이티브로 전환하는 과정에서 겪었던 경험에 대한 이야기

1. 리액트 네이티브를 선택한 이유

- 기존에는 웹에서 콘텐츠 탐색 및 결제를 하고 앱을 뷰어로 사용해왔었는데, 앱에서도 탐색 및 결제 기능을 도입하기로 결정. 빠른 변화에 대응 및 주어진 기간 내에 목표를 달성하기 위해 크로스 플랫폼 개발이 가능한 기술 도입 결정
- 플러터 / 리액트 네이티브를 고민하던 중에 리액트 네이티브가 커뮤니티가 조금 더 안정화, 활성화되어 있어서 리액트 네이티브 결정

2. 네이티브 기반 vs 리액트 네이티브 기반

- 네이티브 앱에 리액트 네이티브를 올릴지, 아니면 반대로 리액트 네이티브 위에 네이티브를 올릴지에 대해서 고민
- 네이티브 위에 리액트 네이티브를 올리면 화면별로 endpoint 달라지고, 앱 라이프사이클 관리가 복잡해짐
- 리액트 네이티브 위에 네이티브를 올릴 경우 기존의 네이티브 코드가 리액트 네이티브와 호환되도록 한번 수정을 해야함. 미래에는 리액트 네이티브로 아예 새로 작성을 해야 함
- 어짜피 대부분의 기능을 모두 리액트 네이티브로 옮겨갈 예정이여서 리액트 네이티브 위에 네이티브를 올리는 방향으로 가기로 결정

3. 네이티브 화면 재활용

- 주어진 기간 내에 변화게 빠르게 대응하기 위하여 새로운 화면은 리액트 네이티브로 작성하고 기존 화면은 네이티브 화면을 유지하도록 결정 (네이티브 화면은 점진적으로 리액트 네이티브로 전환)

4. 네이티브 코드 재활용

- 리디북스에서 13년간 유지보수하며 쌓아 올린 네이티브의 정수를 리액트 네이티브에 녹여낼 수 있을까? 기존의 네이티브 앱에서 Swift, Kotlin을 사용하고 있었는데 이걸 그대로 리액트 네이티브에서 쓸 수 있을지에 대한 검증
- 브릿지를 만들어서 기존 방식대로 사용 가능

5. 적용 과정의 애로사항

- 번들 크기와 메모리 사용량이 증가함
- 번들 크기는 예상한 수준이였으나 메모리는 처참했음. 최적화에 대해서 많이 신경을 써야했다.
- 써드파티 라이브러리를 신뢰하기 어려움
- 네이티브와 프론트 모두 간과할 수 없음. 네이티브 개발자가 프론트 개발을, 프론트 개발자가 네이티브 개발을 알아가야함. 서로 간 교류가 성공의 핵심임.

6. 리액트 네이티브 이래서 좋다

- 높은 생산성
- 협업하기 좋은 플랫폼

리액트 네이티브 덕분에 주어진 기간 내에 제품 로드맵을 달성했으며 변화에 빠르게 대응하는 환경과 생산성을 갖춤. 앞으로 본격적으로 네이티브 영역을 리액트 네이티브로 바꿔나갈 예정. 하지만, 뷰어는 13년간 쌓아 올린 노하우가 있기 때문에 이는 계속 유지하며 최상의 사용자 경험을 제공할 것.