React Native in Production

Seokjun Kim -

최근 쏘카는 새로운 서비스 제로카를 발표하였고, 100명 모집에 10,000명이 몰리는 등 관심과 인기를 한몸에 받고 있다. 관련 블로그 글도 상당히 많이 올라오고 있으니 궁금하시면 한번쯤 찾아보시라.

제로카는 고객에게 판매 및 인도되는 차량인 동시에, 쏘카로서 서비스 내에서 운영되어야 하는 레거시 인듯 아닌듯 애매한 다소 복잡한 상황에서 개발 계획이 세워졌다. 그리고 개발기간은 3주가 주어졌다.

엄마 보고싶다

왜 React Native 를 고려하게 되었는가?

React Native 의 프로덕션 경험을 설명하기에 앞서 왜 React Native 를 선택하게 된 것인지에 대해 집고 넘어가야 할 것 같다. 쏘카는 Cordova 기반의 PHP 웹앱으로 일정 부분은 CodeIgniter 와 RainTpl, jQuery 로 일정 부분은 React 로 개발 되어있다.

오랜 기간 개발되어 오고, 많은 부분에서 수정과 개발을 반복하다보니 Legacy 문제도 있고, 테스트 코드 작성은 다소 미흡한 편이다. 처음에는 현재 쏘카 앱 내의 기능의 일부로 개발하는 계획 또한 가지고 있었다. 몇가지 이유로 결사 반대했는데, 정리해보면 이렇다.

  1. 새로운 서비스의 복잡도와 운영 리스크가 현재 쏘카 서비스에 병합된다.
  2. 기존 앱과 중복되는 부분이 많지 않아 대부분 새로 만들어야 하고, 사실상 재활용할 수 있는 코드도 상당히 적다.
  3. 초기 스펙은 비교적 단순하니 빠르게 개발해서 배포하고, 이후에는 빠른 업데이트로 대응하면 된다.

가장 큰 이유는 역시 개발 및 배포시 동반되는 쏘카 서비스의 리스크였고, 현 쏘카 서비스의 안정성을 해치지 않는 선에서 새로운 앱의 사용 경험을 높이고 싶었기 때문에 React Native 를 진지하게 고려하게 되었다.

React Native 의 장단점

React Native 를 고려하게 된 이유중 가장 큰 것은 개발 리소스 때문이었다. 프로젝트에 투입 가능한 클라이언트 개발자는 상대적으로 네이티브 앱 개발 경험이 적은 웹 프론트엔드 개발자 가 전부였고, 그러다보니 선택할 수 있는 폭이 많지는 않았다. 그래서 Javascript 로 개발할 수 있는 프레임워크를 찾을 수 밖에 없었는데 Native Script 도 그중 하나였다.

현재 프레임워크의 완성도만 봤을때는 Native Script 가 React Native 보다 프로덕션 레디에 근접했다. 많은 모듈이 이미 상당히 완성도 높은 형태로 구현되어 있었고, 듣보잡 비교적 유명하지 않은 회사에서 개발했지만, 커뮤니티에서의 평가도 나쁘지 않았다. 다만, React Native 가 가진 깡패같은 장점들 때문에 채택하지는 않았다.

장점

  1. React 와 Redux
    React Native 의 가장 큰 장점은 무엇보다도 React 라는 점이다. React 는 워낙 훌륭한 뷰 라이브러리인데다가 쏘카의 개발자 풀에 React 를 다뤄본 사람이 많은 것도 사실이었다. 개발만 봤을때는 Native Script 도 나쁘지 않지만 유지보수가 되면 이야기는 달라진다. Redux 또한 쏘카 개발 스택의 일부이기도 하고, 그 완성도는 전 세계적으로 인정받고 있으니 굳이 이 자리에서 따로 언급할 필요는 없을 것 같다.

  2. Flex Layout
    CSS the Good Part 중 하나라고 말할 정도인 Flex Layout 은 레이아웃을 정의하기에 매우 편리한 방법이라고 말하고 싶다. 단연컨데 현재 어떠한 레이아웃 정의 방법보다 사실 내가 아는것 중에서 편리하고 유연하다. 화면을 채우고 싶다고? { flex: 1 } 이면 끝. 이 Flex Layout 과 기본적인 CSS 의 형태를 빌려 UI 를 개발할 수 있도록 구성해두었다.

  3. Instant Reload, Hot Reloading ...
    React Native 는 내부적으로 Javascript Thread 가 Native Component 들을 제어하는 형태이다. 때문에 대부분의 경우 컴파일(!)이 필요없이 코드를 수정할 수 있다. 게다가 React 의 가장 큰 장점중 하나인 React Hot Loader 를 프레임워크 레벨에서 지원한다. 예를들어 쏘카 를 코드상에서 제로카 로 수정하면 손을 대지 않아도 바로 뷰가 업데이트 된다. 넘나 편한 것

  4. THE JAVASCRIPT
    게다가 자바스크립트다. Package 는 npm 으로 관리하고 DOM 이나 Node 엔진 API 를 호출하지 않는 대부분의 패키지는 그대로 사용할 수 있다. lodash, moment 같은 아름다운 분들을 아무 수정 없이 사용할 수 있다. 특히 이번에는 API 서버를 Node.js 로 개발하였는데, 이 과정에서 파서나 밸리데이션 라이브러리를 npm private registry 에 등록해놓고(!) 함께 사용해서 매우 편리했다. React 쓰세요. 두번 쓰세요. 계속 쓰세요!

  5. Code-push 로 리뷰없는 즉시 업데이트
    iOS 앱을 리뷰 없이 업데이트 할 수 있다. 더이상 무슨 설명이 필요하랴! 참고로 code-push 때문에 리젝은 당하지 않는다. 실제로 code-push 에 업데이트가 올라간 상태로 실수로 리뷰를 신청했는데 무난하게 통과했다. 자세한 이유는 링크를 참조! 이메일 정규식에 버그가 포함된 채로 배포를 한적이 있는데 수정하고 다시 배포하기까지 3분 정도 걸렸다. iOS 개발자가 춤을 추더라

  6. 테스트가 용이하다
    사실 아직 react-native 에서 TDD를 도입하거나 유닛테스트를 작성하지는 못했다. 다만 네이티브 앱 유닛 테스트보다는 Enzyme Shallow 렌더링 등을 이용해서 훨씬 유연하게 테스트를 작성할 수 있다. 참고자료

단점

당연히 단점도 있다. 사실 꽤 많다. 업데이트 좀 그만해라 이놈들아 개발자 다 죽겠다

  1. 난해한 Navigation, Navigator, Navigation Bar ...
    지옥같다. react-native-router-flux 같은 재밌는 녀석이 있는 것도 사실이지만 사실 React Native 쓰는 이유가 네이티브 탭바나, 안드로이드 드로어 레이아웃 때문에 쓰는건데 저 녀석을 쓰면 다 커스텀 해야된다. 대부분 이런건 티가 난다. 때문에 Navigator 를 주로 쓰게 되는데 이게 아주 골치아픈 물건이다. 문서화도 잘 되어 있지 않고 Navigation Bar 는 또 설명도 허접한 주제에 사용 방법도 난해하다. TabBar 나 Drawer Layout 과 섞이면 정말 혼란스럽다. 확실한 러닝커브가 있다.

  2. Native Modules 개발이 어렵다
    세상일이 내맘대로 안되더라. 네이티브 모듈과 개발 하는 것 자체는 어렵지 않은데 역시 문서화가 깔끔하게 안되어있다. 그러다보니 그냥 남코드 까서 따라 만드는 편이 더 빠르다. 된거 아니야? 결국 뭔가 특이한 걸 하고 싶으면 Native Module 개발이 필요하고, 네이티브 개발자가 필요하고 그나마도 손이 많이 간다. 브릿지 개념은 (다른 프레임워크들과 비교하면) 쉽고 단순한데, 막상 만들다보면 그렇게 간단하진 않다.

  3. 허접한 문서와 잦은 업데이트
    Facebook 은 정말 문서화를 못하는 집단인 것 같다. MS 정도까지는 안바래도 Google 만큼이라도 해주면 좋을텐데, "모르면 까보시던가" 인건지 개발 문서가 매우 빈약하다. 뭐라고 해야하나 있을 건 다 있긴 한데, 애매한 건 하나도 없다. 여기에 잦은 업데이트까지 섞이다 보니 또 지옥이 되는데, 2주에 한번씩 릴리즈를 하는데 가끔씩 Breaking Changes 개객기 가 눈에 들어온다. 개발 기간 늘어나는 소리가 들리는 것 같다.

  4. 무엇에 쓰는 아니 어떻게 되가는 물건인고?
    아쉽게도 코드를 직접 분해해 보지는 못했고, 게다가 또 Java 코드와 Objective-C 코드가 함께 섞여 있기 때문에 도대체 안에서 어떻게 돌아가고 있는지 알 수가 없다. 차차 나아지겠지만, 실제로 어떻게 돌아가는지 모르니 잘 되면 다 좋은데, 문제가 생기면 고치기가 상당히 힘들다. 거기에 iOS 와 Android 에서의 미묘한 차이까지 합쳐지면 이걸 어디까지 들어가서 고쳐야 할지 막막하다. 둘다 알면 좋겠지만 난 어디까지나 웹 개발자인데 라는 분은 웰 컴 투더 헬!

  5. 느리다
    고는 하는데 실제로 느껴보진 못했다. 특히 안드로이드에서 컴포넌트 중첩이 많지 않아지면 메모리 누수가 일어나서 매우 느려진다고 하는데, 아직까지는 그런적은 없었다. 버젼업이 되어서 그런건지, 일단 지금까지는 괜찮다.

뭐야 쓰라는거야 말라는거야?

결론적으로 말하자면 아래와 같은 특정 케이스에서 뛰어난 가성비와 퍼포먼스를 자랑한다.

  1. 개발자가 부족한데 앱을 만들어야 하고 상대적으로 웹 개발자에 여유 있는 경우
  2. 코르도바, 타이타늄 등 하이브리드 앱을 고려하고 있는 경우
  3. 다양한 애니메이션이나 효과 보다 컨텐츠 자체가 중요한 앱을 개발할 경우
  4. 개발 기간이 부족하고 빠르게 프로토타입을 개발해야 하는 경우
  5. 비지니스 로직이 빠르게 변경되고 이를 앱에 반영해야 하는 상황

특히 코르도바나 폰갭 같은 경우보다는 React Native 는 네이티브 앱의 퍼포먼스와 큰 차이가 나지 않을 정도로 비교 자체를 거부할만 하고, 타이타늄 보다는 개발이 훨씬 편하며, 관련된 오픈소스 모듈도 훨씬 많다. 유료로 팔지 말란 말이야 이자식들아 React 와 Redux 가 가진 장점이 워낙에 많다보니 뷰를 그리고 데이터를 핸들링하는 코스트가 매우 낮다. 게임이나 리소스를 많이 써야하는 앱이라면 당연히 네이티브로 가는 쪽이 낫겠지만, 그렇지 않거나 빠르게 개발하는 것이 중요한 상황이라면 개발 퍼포먼스나 투입 시간 대비 결과물의 퀄리티가 상당히 높다.

React Native 개발 후기

대체로 좋은 경험었다. 개발 결과물도 빠르게 나왔고 대부분의 문제는 완벽하진 않지만 해결할 수 있었고, npm 은 역시 만족스러웠다.

  1. 개발은 쉽고, 배포는 할만하고, 업데이트는 힘들다.
  2. react-native 전용 패키지들은 항상 문제를 만들었다.
  3. 네이티브 퍼포먼스는 나쁘지 않다.
  4. 앱의 사이즈가 크지 않다면, 프로덕션에서도 써볼만 하다.

이정도로 크게 정리할 수 있을 것 같다.

Javascript 로 네이티브 앱을 개발한다는 컨셉이 많이들 나오고 많이들 스러져 나갔으나, 가장 성공에 근접할 수 있는 프레임워크라고 생각한다. 안드로이드폰 답게, 아이폰 답게 만들 수 있고 개발 퍼포먼스는 압도적이다. 업데이트도 편리하고, ES6 덕분에 가독성도 괜찮다. 네이티브 모듈은 다소 까다로우나, 못할 정도는 아니다. 안드로이드에서 메모리 누수 현상이 있다고 들었으나, 아직 느껴보지 못했다.


아직 갈길은 멀다.

제로카는 현재 0.2.0 버젼을 개발하고 있고, 대부분의 중요 네이티브 패키지는 잘 작동한다. 알수없는 이유로 알수없는 곳에서 문제가 생기긴 하지만 솔직히 이게 비단 React Native 만의 문제는 아니라고 본다. 현재 쏘카에서는 몇개의 프로젝트에서 더 React Native 를 시험하고 있다. 고백하자면 Native Script 를 고려하지 않았던 이유 중 가장 큰 것이 듣보잡(?) 회사라는 점이었다. 반면에 React Native 는 페이스북이 이미 f8 이나 facebook ad, group 등에서 쓰는 만큼 이후를 기대해볼만 하다고 생각한다. 위에 열거한 상황과 조건이 맞아떨어진다면 자신있게 프로덕션에 올려보라고 추천하고 싶다.