<네이티브 앱 → 리액트 네이티브 앱 전환 그리고 1년 후> 라프텔(애니메이션 스트리밍 서비스) 서비스에서, 기존 네이티브 앱을 리액트 네이티브로 전환한 이야기를 하고 있습니다. 리액트 네이티브는 사실, 적은 리소스로 모바일 서비스를 제공하는 스타트업에서 종종 써먹고 싶어하는 기술일텐데요. 라프텔 팀 역시도 비슷한 고민을 해서 시작했던 것 같습니다. "라프텔은 구독형 서비스 플랫폼입니다. 사용자가 멤버십을 구독하면 라프텔에서 제공하는 애니메이션 중 멤버십 포함 작품들을 무제한으로 감상할 수 있지요. 저희 팀에게 주어진 가장 중요한 미션 중 하나는 사용자가 서비스에 유입된 이후 멤버십 구독을 할때까지의 흐름을 개선하는 것입니다. 멤버십 구독 이후 재결제율 또한 매우 중요한 지표지요. 이 지표들을 개선하기 위해서 저희가 할 수 있는 것은 무엇이 있을까요? 사용자가 좋아할 만한 새로운 기능들을 추가하는 것도 중요하고요, 단순히 상품의 설명이나 UI의 재배치도 이 지표에 영향을 끼치기도 한답니다. 최적의 성과에 도달하기 위해서는 다양한 테스트를 거쳐야 하는데요, 저희는 리액트 네이티브를 사용했을 때 이러한 테스트를 진행할 때 매우 효율적일 것이라 생각했습니다. 예를 들어서 A/B 테스트를 진행한다면, 만약 Android 와 iOS 개발이 따로따로 이뤄져 있는 경우 테스트를 위한 코드를 두 번씩 작성해야 하고, 관련 QA도 두 번씩 해야 하고, 테스트를 마친 후 관련 코드를 제거하는 작업도 두 번씩 해야 합니다. 반면 리액트 네이티브를 사용하는 경우엔 해당 작업들을 한 번씩만 하면 되지요." 이런 이유로 조직 구조를 변경하고, 그 변경 속에서 리액트 네이티브로의 전환을 시작한 것이죠. 글의 아래 부분에는 리액트 네이티브를 도입하면서 느낀 장점과 단점이 나옵니다. 하지만 이 부분이 하이라이트라고 생각해서.. 본문 내용을 적어서 마무리를 짓고자 합니다. "리액트 네이티브 앱의 개발과 릴리즈는 성공적으로 되었었지만, 릴리즈 직후에는 이렇게 전환을 한 것이 과연 가장 좋은 선택이였을까? 라는 의문을 가지고 있었습니다. 만약 리액트 네이티브로 통합하지 않고 개발자 채용을 잘 진행해서 Android 개발자, iOS 개발자, Web 개발자 각 플랫폼에 한명씩 더 인력 충원을 하고 서비스 기능 개발에 힘을 더 줬더라면 다른 좋은 결과가 있지 않았을까? 라는 생각을 하기도 했습니다. 2020년 7월까지는 그렇게 생각을 했었는데, 리액트 네이티브 프로젝트가 안정화 되면서 그러한 의문은 모두 사라졌습니다. 저희 개발 조직의 업무 처리가 이전보다 훨씬 가속화 된 것을 느꼈고, 또 코드를 웹, 모바일 앱, TV 앱 간에 공유 하는 것을 실행으로 옮기게 되면서 개발 효율이 높아져서 이 방향으로 틀길 확실히 잘했다는 것을 느꼈습니다. 가장 좋았던 것은 프런트엔드 개발자들의 협업과 소통의 발전이였습니다. 이전에 Android, iOS, Web 개발이 따로 따로 이뤄질 때에는 서로 소통하는 것이 꽤나 적은 편이였습니다. 왜냐하면 서로의 개발 환경도 달랐고 만약 소통을 한다면 특정 로직 구현에 관한 노하우 공유 정도가 전부였는데, 이제는 프런트엔드 개발팀의 그룹원들이 모두 웹 개발자이자, 앱 개발자이기 때문에 더욱 많은 것을 함께 설계해나갈 수 있게 됐습니다. 같은 고민을 함께 하는 사람들이 늘어나니까 확실히 이전보다 더 좋은 솔루션에 도달하는 것이 느껴집니다. 앞으로 팀이 더 커질 것을 생각하면 너무 기대가 됩니다."