Medium - Should you use React Native to build your startup’s mobile app?
in Trend
Trend 파악을 Medium 기고문 요약 포스팅 - 스타트업 앱을 만드는데 리액트 네이티브를 써야할까요?
2007년에 출시된 첫 아이폰은 기존의 모바일 산업을 붕괴시킨 것이 서부의 골드러시를 연상시킵니다. 그리고 10년이 지난 지금도 여러 산업 분야에 영향을 미치고 있습니다.
만약 여러분이 세계적으로 인정받는 앱을 만들고 싶다면 당신은 AOS와 iOS 양쪽에서 모두 사용가능 하길 바랄 것입니다. 한 플랫폼에서만 출시할 수도 있지만 만약 유저들이 관심을 갖게 된다면 여러분은 사용자들이 자신들의 플랫폼에서 사용가능하게 해달라는 요청을 받게 될겁니다. 이 요청은 당신이 30%-70%의 잠재적인 스마트폰 유저를 놓쳐버렸다는 것을 의미하죠.
1년 전쯤 우리는 리액트 네이티브를 크로스플랫폼 모바일 앱을 만들기 위해 평가를 했었습니다. 모바일용 Snipe 개발은 2018년 2분기에 시작하여 지금까지 리액트 네이티브를 기반으로 하고 있습니다. 이것은 제품의 비전을 알아채는 것, MVP를 구성하는 것, 앱스토어와 플레이스토어에 배포하는 것, 그리고 정규적은 소프트웨어 업데이트를 포함하고 있습니다.
Background
최초의 Snipe 앱 아이디어는 게이머들에게 좋은 동료들을 찾아주는 것을 돕는 것이었습니다. - 경쟁 게임과 이스포츠에 널리 퍼져있는 문제 - 혁신적인 방법을 통해서 말이죠. 사용자들은 더 이상 팀메이트 매칭에 행운이 따르길 바라며 인게임 매칭(두 그룹이 공평한 매치가 되도록 하는데 초점을 맞춤)을 하거나, 디스코드 서버에서 홍보를 하거나, 포럼 웹사이트를 가지 않아도 됩니다. 우리가 제공하는 팀메이트 매칭은 서버의 AI(머신모델과 추천 시스템을 사용한 기술)를 통해 동작하며 사용자들은 모바일 앱을 이용하여 그들이 나중에 같이 플레이할 사람들을 찾을 수 있습니다.
우리는 다양한 경험을 가진 기술 팀을 구성했습니다. 그렇다고는 해도 단지 모바일 앱 개발 분야의 경험들의 조합이었으며 그 때 당시에는 안드로이드 앱에 “hello world” 같은 기능을 더 추가한 것이었습니다. 여기에 iOS와 AOS 동시에 출시하려는 욕구 때문에 우리에게는 리액트 네이티브가 매우 유망해 보였습니다.
리액트 네이티브는 페이스북이 관리하는 오픈 소스 툴셋이며 자바스크립트로 크로스플랫폼 모바일 앱을 만들 수 있습니다. 리액트 네이티브는 웹 스타일의 리액트와 CSS, HTML과 같은 마크업 신택스를 기반으로 합니다. 2015년에 출시되었으며 Airbnb, Wix, Discord 같은 곳에서 사용되었으며 크로스 플랫폼 개발 솔루션으로 많이 사용되고 있습니다.(비슷한 다른 솔루션들은 네이티브 스크립트, 아파치 코도바, 마이크로소프트 Xamrin, 구글의 플러터가 있습니다.)
우리가 초기에 발견했기 때문에 초기버전에서 리액트 네이티브를 사용해서 크로스플랫폼 앱을 만드는 것에 많은 장애물이 있었습니다만 일반적인 모바일 개발자들은 거의 마주치지 않을 것들입니다.
이 포스트의 나머지는 리액트 네이티브로 개발한 우리의 경험에 관한 것입니다. - 우리가 좋아한 것과 싫어한 것 그리고 사용하면서 추천할 점들입니다. 우리가 사용한 리액트 네이티브는 v55라는 걸 기억해 두세요.
“세상에는 두 부류의 개발자가 있지, 건방진 쪽과 테스트하는 쪽이지, 넌 테스트하는 쪽이냐?”
The Good
리액트 네이티브는 빠르고 꽤 보증되어 있습니다. 스타트업 환경에서 빠른 반복이 키 입니다. 자바 스크립트와 같은 언타입 언어를 사용하여 양 플랫폼의 코드를 동시에 작성하는 것이 반복을 빠르게 할 수 있도록합니다.(반면에 안전성 측면에서는 버그들이 좀 있습니다. - 이것을 염두해 두세요)
양 플랫폼에 공유할 수 있는 프로그래밍 언어를 사용하는 것은 우리가 존재하는 iOS앱을 안드로이드 플레이 스토어에 일주일 내로 배포할 수 있다는 것을 말합니다(!). 이것은 앱이 스위프트나 오브젝트 씨로 작성된 경우에는 일어날 수 없는 일이죠.
리액트 네이티브는 웹 기술을 기반으로 영감을 받았으며 웹에 대한 배경지식이 있는 개발자들은 집에 온듯한 느낌을 받을 겁니다. 네이티브 SDK를 사용하는 새로운 앱 개발자들은 그렇지 않겠네요. 이것은 특별히 윅스와 같이 웹 기술에 깊이 뿌리를 두고 있는 사람이나 조직과 연관되어 있습니다.
자바스크립트를 사용하는 것의 장점은 코드를 웹과 데스크톱에서 재사용 할 수 있다는 것입니다. 코드 전체를 공유하지 못하더라도 최소한 모델 레이어는 공유할 수 있습니다.
커뮤니티가 크고 계속 성장 중입니다. 이말은 새로운 라이브러리들이 꾸준히 튀어나오는 것이며 오래된 것들은 사라지죠. 추가적으로 여러분이 마주치는 많은 문제들은 구글 검색으로 쉽게 해결할 수 있습니다. 솔루션들이 항상 간단한 것은 아니지만 정보는 확실히 거기에 있습니다.
“커널 단에서 분리된 많은 레이어를 갖고 있는 프로그램은 항상 멈추는 것은 아닙니다. 심지어 당신의 더러운 안드로이드 조차도 강력한 CPU를 가지고 있습니다.”
The Bad
리액트 네이티브는 완벽한 크로스 플랫폼이 아닙니다. iOS와 AOS환경에서 리액트 네이티브가 일관적이지 않은 경우가 많습니다. 예를 들면 이런 것이죠.
- 스타일링이 다르게 동작합니다. 레이아웃에 대한 많은 변화가 한 플랫폼에서 수행되었다면 동일한 해상도임에도 다른 플랫폼에서는 깨질 수 있습니다.
- 리액트 네이티브에서 제공하는 많은 기능과 사용할 준비가 된 컴포넌트들은 한 플랫폼에서만 사용가능합니다. 예를 들어 우리가 최근에 텍스트 입력시 초기화 버튼을 추가하길 원했습니다. 문서는 iOS에는 솔루션이 빌트인 되어 있다고 했지만 해당 기능이 안드로이드에서는 사용불가 했습니다.
- 에러가 종종 비일관적입니다. 이것은 다음 포인트에서 설명하겠습니다.
에러 처리와 디버깅은 정말 고통스럽습니다. 자바스크립트 에러 자체가 수수께끼같은 것을 차치하고라도 패키징/배출 과정에서 source map이 생성하는 JS 에러들은 잘못된 행의 번호를 가리키고 당신 스스로 어디서 에러가 발생했는지 추측해야 합니다.
리액트 네이티브 내부와 연관된 에러들은 더욱 무섭습니다. 리액트 네이티브와 일을한 사람이 아니면 누구라도 이해하기 힘들 겁니다.
“어쨌거나 이 에러는 고아가 된 yoga어린이들을 사무실에 유행으로 만들었습니다.”
위의 에러는 안드로이드에서 발생한 에러인데 JSX 프로젝트에서 Yoga(리액트 네이티브에서 사용하는 레이아웃 엔진)를 파싱하지 못했을 때 발생하는 에러입니다. iOS 시뮬레이터에서 작업하고 테스트할 때는 잘되던게 안드로이드에서만 에러가 발생한 것이죠.
Installing libraries is a nightmare - 리액트 네이티브에서 구현되지 않은 어떤 네이티브 인터랙션을 사용하기 위해서는 라이브러리를 다운받고 네이티브 프로젝트에 링크하기 위해서는 네이티브 코드의 해당 파트를 수정해야 하고 빌드 설정을 수동으로 해야 합니다. 링크 과정은 에러가 발생하기 쉽고 많은 라이브러리를 쓸 수록 더욱 추가하기가 힘들어 질 것입니다. 이 과정은 근본적으로 안드로이드 앱과 iOS앱 에서 차이가 있는데 이 말은 당신은 그것을 두번씩 해야 한다는 것이죠.
많은 라이브러리들이 구현한 기능들은 우리에게 가지고 있을 만한 가치가 있었지만 리액트 네이티브 자체에는 없는 것이었죠, 예를 들면 푸시 알림, 비디오 플레이백, 네이티브 네비게이션, 맵 지원 같은 것입니다.
마지막으로 안드로이드에 대한 리액트 네이티브의 지원은 부실합니다 리액트 네이티브에서 안드로이드는 확실히 iOS 환경보다 힘듭니다. 오래된 자바 스크립트 코어로 이동하는데 iOS에는 없는 버그들이 많이 존재하고 deprecated된 메소들을 빌드하는데 사용하고 매우 느리게 수행됩니다. 이것에 대한 이유는 두가지가 있습니다. 공식적이진 않지만 페이스북이 iOS더 선호한다는 것입니다. 안드로이드는 설정을 통해 더욱 최적화를 할 수 있는 하드웨어 임에도 말이죠.
중요한 점은 이 모든 버거들이 리액트 네이티브의 문제가 아니라 각 플랫폼 OS와 관련된 의존성 때문입니다. 그리고 많은 것들은 고쳐질 수 있죠. 말할 필요도 없이 앞서 말한 문제들은 생산성 저하와 우리에게 많은 좌절감과 일이 지연되게 했죠.
“코딩을 해야한다면 코딩을 해라, 말을 하지 말고”
The Ugly
네이티브 코드로 작성해야하는 하이브리드 앱 형태나 라이브러리를 연결하는 부분은 코드를 난잡하게 만들고 빌드 설정파일들은 유지보수를 어렵게 합니다. 이것은 특히나 개발자가 한 쪽, 혹은 양 플랫폼에 능숙하지 않을 때 더 심합니다.
UI 디자인 또한 추가적인 작업이 필요합니다. 안드로이드 앱과 iOS 앱은 다른 디자인 패턴과 원리를 따릅니다.(Material Design과 HIG). 서로 차용하는 과정에서 그들은 다른 기초와 권장사항을 가지게 되었죠. 예를 들어 하단 네비게이션 바는 iOS앱에서는 매우 유명하지만 안드로이드에서는 지양을 하고 있습니다. 구글은 최근에 그것들을 Material Design에 포함시켰지만 여전히 다른 스키마를 권장합니다. 가이드라인을 충족하지 못하는 것은 형편없는 UX를 낳게 됩니다.
두 플랫폼을 위한 한가지 코드베이스는 한쪽의 디자인 가이드라인에 맞춰서 다른쪽을 포용하는 것을 말하는데 이는 다른 플랫폼의 사용자에게는 매우 낯설게 느껴질 것입니다. 아니면 두 가이드라인 모두를 채택하는 것인데 그러면 프랑켄슈타인처럼 괴상해 보이는 앱이 될 것입니다.
리액트 네이티브는 플랫폼에 기반하여 다른 버전의 컴포넌트를 렌더링 할 수 있도록 허용합니다. 그러나 거의 모든 것을 두번씩 하는 것이 위에서 언급한 문제점들을 해결하는데 답이 될까요? 우리의 견해는 아닙니다.
The Final Shootout
리액트 네이티브로 개발하는 것은 서부영화를 보는 것 같습니다. 액션씬은 빠르고 짜릿하지만 그것들을 만드는 것은 느리고 지루하죠. 2019년 초반, 리액트 네이티브는 아직 덜 성숙합니다. 그리고 크로스 플랫폼 모바일 개발을 완벽하게 충족하지 않습니다.
우리는 리액트 네이티브로 간단한 앱이나 폐기할 수 있는 MPV 혹은 프로토 타입에 사용하길 권장합니다. 아니면 iOS만 출시할 것이라면 더욱 안정적일 것입니다. 그러나 복잡한 앱이고 긴 시간이고 양 플랫폼에 출시할 것이라면 리액트 네이티브는 당신에게 적합한 플랫폼이 아닐 것입니다.
Airbnb는 최근에 리액트 네이티브로 작업하는 것을 중지했습니다. 우리로서는 양 플랫폼에 대한 풀 네이티브를 찾고 있습니다. 이 시점에서 우리는 리액트 네이티브로 코어 개발하는 것은 우리를 뒤에 묶어든다는 느낌을 받습니다.
Summary
- 리액트 네이티브는 자바스크립트를 사용하는 웹기술 기반의 크로스 플랫폼 모바일 앱 개발 환경이다.
- 양 플랫폼에 출시할 수 있는 한가지 프로그래밍 언어는 생산성과 재사용(웹, 데스크톱 가능)에 있어서 매우 큰 장점을 지닌다.
- 그러나 외부 라이브러리 추가 시 네이티브 코드와 빌드 설정이 수동으로 필요하고 양 플랫폼에 디자인 가이드라인이 다르다는 것이 가장 큰 문제다.
- 리액트 네이티브는 진정한 크로스 플랫폼을 충족할 수 없으며 OS에 대한 리액트의 의존성 때문에 버그가 발생하기도 한다.(source map 등)
- 복잡한 앱이나 장기적인 유지보수 관점에서 보면 리액트 네이티브로 지속적인 코어 개발을 하는 것은 올바른 선택이 아닐 수도 있다.(OS에 의존적인 버그, 서로 상이한 디자인 가이드 라인, 외부 라이브러리 추가 시 복잡도 증가 등)
