brunch

You can make anything
by writing

C.S.Lewis

by Bright Lee Dec 05. 2017

React Native,Xamarin은 한국에서 안팔려

우리가 아직까지도 엑티브X를 마주해야 하는 이유와 크게 다르지 않다

작년 '내 아기의 첫 번째 웨어러블' 올비의 킥스타터 캠페인이 성공한 후, 배송 전 짧은 기간 내에 앱을 완성하기 위해 네이티브 크로스 앱 개발 플랫폼 Xamarin.Forms를 시작했고 무사히 서비스를 하고 있다. Xamarin.Forms의 개발과정은 이전 글 [앱 개발, 이젠 다시 크로스 개발이다] 을 통해 자세히 다루었다. 요즘은 React Native를 시작해서 앱 개발을 하고 있다.

React Native나 Xamarin.Forms로 네이티브 앱 개발을 해보게 되면 기존의 앱 개발 방식이 허무해지며 다시는 그 방식으로 돌아갈 수 없다. 또한 너무나 매료되어 다른 사람들에게 이것을 알리지 않을 수 없다. 나도 그들 중 한 명으로서 글을 적었고 감사하게도 많은 분들이 읽어주셔서 적지 않은 보람을 느낄 수 있었다. 그런데 이상하다 우리 전도사들의 힘이 약했던 것일까 React Native와 Xamarin.Forms는 한국에서 유독 성장하지 않는다. 대세가 되기는커녕 소수의 회사나 프리랜서들 외에는 관심에서 멀어져 있다고 생각된다.

한국에서는 안 팔린다

Xamarin 네이버 카페 : 회원수 2600이지만 실제 활동 회원 10명 남짓

Xamarin Korea 페북 그룹 : 멤버 1000, 한 달에 글 한두개

React Native 네이버 카페 : 회원수 33

React Native Korea 페북 그룹 : 멤버 500, 일주일에 글 한개 꼴

React Native Seoul Meetup 그룹 : 멤버 100, 매주 작은 모임 진행 중

전혀 활성화되지 않았고 앞으로도 될 것 같아 보이질 않는다. OnOffmix나 meetup에도 모임을 상당히 찾기 어렵다.(마소 MVP분들이 가끔 수고해 주시고 있지만) 일단 React Native와 Xamarin.Forms가 뭔지 아주 간략하게 장단점을 이야기해 보자.

2018-07-30 추가:

*Xamarin.Forms 는 한때 주목받았지만 시간이 지난 현재시점에 비교하면 React Native 에 추월당해 그 격차가 상당히 많이 벌어졌음을 이야기 드립니다.

갓 React Native 갓 Xamarin.Forms

*React Native와 Xamarin.Forms는 하나의 코드로 iOS/Android 혹은 그 외 플랫폼까지 '네이티브 앱' 결과물을 만들어주는 개발도구이다. 둘 다 오픈소스!

서로 싸울 것 없다.. 둘다 짱이니까

React Native

장점 : Javascript, 미친듯한 개발 속도(Live reload), npm 월드의 무궁무진한 모듈들, 트렌디하고 젊은 개발자들이 대거 유입 중인 js진영(진행 중), 백엔드가 js라면 같은 계열이 유지된다, Redux 등 훌륭한 패턴, 향후 본인의 서비스가 웹으로 확장되어 간다면 좋은 선택(React)

단점 : JAVASCRIPT, React에 익숙하지 않다면 러닝커브 있다, Best Practice를 발견하기까지 시간이 걸림(바꿔 말해 Best Practice가 계속 바뀐다), 각 네이티브를 건드리려면 각각의 언어와 툴을 이용해야 한다.

Xamarin.Forms

장점 : C#, 빠르고 안정적이며 정석적인 개발, .Net 월드의 성숙한 라이브러리들, MS 진영의 수준 높은 개발자들 진영 및 서포트, 훌륭한 MvvM 패턴, 각 네이티브를 건드릴 때도 C#으로 작업, XCode나 Android Studio를 한 번도 켤 필요 없이 배포까지 완벽, 향후 본인의 서비스가 데스크톱 클라이언트 앱으로 확장되어 간다면 좋은 선택(Xamarin.Forms for UWP/Mac *Mac은 Preview)

단점 : 해당 진영이 모바일에 대한 이해도가 낮아 모바일 라이브러리들의 생성/개선이 뒤쳐짐

React Native, Xamarin.Forms 공통

장점 : 잘 작성된 매뉴얼, 현재는 매우 빠르고 안정적인 성능을 보여줌, 각 네이티브 플랫폼을 손쉽게 건드릴 수 있음, OS SDK 버전 업데이트에 발 빠르게 대처, 많은 개발자풀 진영/커뮤니티, 개발사와의 소통, 주체가 공룡들이다(Facebook, MS), 오픈소스, VS등 좋은 개발툴

단점 : 노하우가 생기기 전까지는 괴로운 폭탄들이 좀 있다. 한국 회사 네이티브 SDK 래퍼 라이브러리 없음

구글트렌드. 이들의 강세는 현재 진행중.

Why not?

React Native와 Xamarin.Forms는 해외에서 끝없이 성장하고 있고, 앞서 말했듯이 한번 해보고 나면 도저히 기존의 개발방식으로 돌아갈 수 없다. 그런데 왜 한국에서 여전히 널리 퍼지지 않고 있을까. 나도 모르겠다.

대체 그 이유가 무엇인지 몇 가지 가설을 세워서 의문을 제기해보고 싶다.

가설 1. 한국 개발자들의 신기술에 대해 도입 속도가 떨어지는 걸까?

간혹 제기되는 한국 엔지니어들의 영어실력에 대한 언급과 함께 최신 기술에 반응이 늦는 것에 대한 지적이 있기도 한 것 같다. 그런데 아무리 봐도 그렇지는 않은 것 같다. 웬만한 개발자들은 실제로 영어를 잘하진 못하더라도 기술문서를 읽고 적용하는 것은 어렵지 않게 해내고 있다. 또 Swift를 프로젝트에 적용하는 속도나, 과거 Angular / React가 다양한 프로젝트에 도입되는 속도 등을 봐도 신기술을 적용하는 속도가 늦다고 생각되지 않는다. 신기술을 이용하면서도 IE8 등을 지원해야만 하는 개발사들의 노력은 오히려 박수를 쳐줘야 하는 눈물겨운 상황까지.

가설 2. 교과서를 따라야 해... 그렇게 배워왔지...

웹 프론트는 오랜 시간 동안 혼돈의 카오스이며 끝없는 춘추전국시대이다. 도대체 이 구역의 보스가 누구인지 알 수가 없다. 좀 자리가 잡혀간다 싶으면 또 "내가 더 미친놈이야"라며 새로운 게 나온다. 그러면서 각자 생존력을 발휘해가며 '무엇이 좋은가'를 찾아가며 성장시켜 온 것이 아닐까 싶다. 이 흐름에 한국의 웹 프론트 개발자들은 직접 만들어내진 못해도 무엇이 좋은지 고민하고 찾아내는 노력을 게을리하지 않았다고 생각한다.

그런데 한국에서 모바일 네이티브 앱 개발은 정석의 틀에서 틀어질 기미가 보이질 않는다. iOS는 XCode/Swift, Android는 Android Studio/Java를 통한 개발 방법이 완전히 시멘트처럼 굳어졌다. 이미 교과서가 있는데 왜 굳이 다른 걸 해야 한다고 생각하는 사람들이 보다 많은 것일까? 보다 나은 것에 대한 갈망보다 안정적인 업무수행이 더 우선시되는 것은 아닌지 생각해볼 필요도 있을 것 같다.

가설 3. 사장이 뿔 내면 누가 책임질 건데?

실리콘밸리에서 스타트업을 하는데 공동창업자 CTO가 없으면 투자는 꿈도 꿀 수 없다는 이야기를 들은 적이 있다. 태생이 뼛속부터 엔지니어링 적인 미국인들에게는 엔지니어 공동창업자가 없이 테크 스타트업을 벌이는 것이 말이 안 되는 것이다.

그래서 전통적으로 엔지니어가 창업하여 성공한 회사가 많고, 그렇지 않더라도 엔지니어들과 기술에 대한 원활한 토의를 할 수 있는 능력이 있어야 한다는 것은 잡스가 잘 보여주었다. [1990년, 어느 젊은 창업가의 회상, 그리고 예언: stage5]

최근 세계 부자 1위에 등극한 아마존의 제프 베조스가 어떻게 아마존을 경영했는지 봐도, 테크놀로지에 이해가 깊은 대표는 어떤 일이 가능한지 보여주었다. 게다가 최근에는 이런 일까지. [미디어 테크놀로지 기업으로 재탄생한 워싱턴 포스트]

"우리는 결정해야만 했습니다. 우리가 가려는 근본적인 방향이 어느 쪽인지. 그리고 뭐가 이치에 맞고 뭐가 이치에 안 맞는지." - D8 컨퍼런스

한국에서는 이 반대의 일이 꽤 많이 일어난다. 빵집은 하고 싶은데 제빵기술은 없는 파리바게트 점주들처럼 엔지니어 공동창업자 없이 창업을 하거나, 큰 테크 회사의 높은 요직에 앉아있는 경우이다. 자고 일어나면 새로운 기술이 나오는 세계에서 기술적인 판단과 평가를 해낼 수가 없으니 무엇이 올바른 방향인지 알 길이 없고. 외주에 의존하는 경우가 잦다. 여기에 '맡은 일만' 하기 원하는 엔지니어들이 시너지를 내어 놀라운 작품들이 많이 탄생한다.

대표가 엔지니어가 아니고, 기술에 대한 권한과 책임을 엔지니어에게 완전히 위임할 것도 아니라면, 동급의 위치에서 싸워가며 방향을 결정할 공동창업자 엔지니어가 필수적이다. 나는 꼭 '개발자 찬양론'을 전개하려는 것은 절대 아니지만, 중요한 기술적 방향을 결정할 때 엔지니어가 스스로 목소리를 내지 않거나 혹은 중하지 않은 것으로 여겨지는 현실이 안타깝다. 개발 역사적으로 한국은 응용프로그램이 주가 되었고 소프트웨어 원천기술 쪽으론 부족한 상황도 한 몫한다. 우리들 스스로 그만한 중한 위치를 만들지 못한 것도 있다.

기괴하다. 달리 표현할 길이 없는 따릉이 iOS앱

어쨌든 이런 상황의 대표적인 예가 천만 서울시민이 애용하는 따릉이 iOS 앱이 아닐까 싶다. 이 웹앱은 정말이지 시작부터 경악스러운데 뒤로 갈 페이지가 없는데 존재하는 뒤로가기 버튼부터 '오른쪽' 위 햄버거 메뉴를 누르면 '왼쪽'에서 경악스러운 쉐도우와 함께 등장하는 Drawer Menu 라던지. 나는 자전거는 사랑하지만 이 앱을 만지기가 싫어서 따릉이를 못쓰겠다. 몇 명 쓰는 앱도 아니고 수백만의 사람들이 써야 하는 앱이 도대체 왜 이모양인 걸까. 이 앱을 보면 그 전설적인.. 1억짜리 개발 건이었는데 외주에 외주를 거쳐 결과물은 500만 원 받고 어떤 개인개발자가 만들었던 사례가 떠오른다. 서울시청에는 이것에 대해 평가할 수 있는, 혹은 개선할 수 있는 사람이 한 명도 없는 것인가? 아니면 그냥 자기 입에 지퍼를 닫아버린 건가. 몇 년째 같은 모양인 이 앱 대체 언제까지 봐야 하나?

하이브리드 앱이 문제라는 말이 아니다. 웹앱은 한마디로 알맹이 웹을 잘 만든다면 사용이 원활한 훌륭한 결과물이 나올 수 있다. 실제로 그런 회사들이 한국에도 꽤 많이 있다. React Native와 Xamarin.Forms의 경쟁상대는 하이브리드가 아니고 각 네이티브다. 하이브리드는 지금까지 그랬고 앞으로도 모바일 앱의 한 축을 계속 담당할 것이다. (뒤에 다시 언급하겠다)

어쨌든 React Native나 Xamarin.Forms로 개발을 하게 되면 노하우가 쌓이기 전까지는 앞으로 해야 할 이 부분이 크로스 플랫폼으로 가능할지 불가능할지 가늠을 하지 못해 시간을 박아 넣어야 하는 순간이 분명 있다. 내가 엔지니어면서 동시에 내가 중요 결정권자면 그럼에도 불구하고 그것을 감수해보자 라는 선택을 할 수도 있지만, 그렇지 않은 경우 회사에서 나는 곤란한 처지에 빠지게 될 것이 분명하다. 좀처럼 쉽게 선택할 수 없다. 뭔가에 막혀 끙끙대며 시간을 보내고 있게 된다면 개발을 잘 알지 못하는 사장에게 '내가 무능한 개발자가 아니다'라는 변호를 훌륭하게 해낼 자신이 없다. 해낸다 해도 사장의 머릿속에 의문은 사라지지 않겠지. 물론 훌륭한 개발자라면 회사와 관계없이 다른 개인 시간에 공부하고 테스트해보지 않을까 싶기도 하다.

가설 4. 마켓 리더 개발사들의 미적거림

이게 가능한지 불가능한지 가늠이 안 되는 이유는 그만큼 선례가 많지 않기 때문이다. 한마디로 먼저 총대 맸던 사람이 많지 않으니 아무도 움직이지 않는 현상이 오래도록 지속되고 있다. 가장 기본적으로는 한국형 앱 개발에 필수적인 네이버/카카오/지도 SDK 나 PG사 결제모듈 SDK 의 React Native 용 공식 래퍼모듈이 없다는 것이 큰 문제다. (Xamarin 쪽은 훨씬 상황이 심각하다)

npm에서 검색해보면 몇몇 개인이 배포한 래퍼모듈이 있기는 한데 (감사합니다) 다운로드 수가 매우 적고 해당 프로젝트를 진행하면서 필요해서 배포한 임시적인 모듈들이라 향후 관리가 되지 않을 가능성이 크다. Facebook SDK 등과 같은 유명한 SDK들의 경우 React Native는 지네가 만든 것이니 당연히 자기들이 배포해놓았고, Xamarin의 경우 활성화를 위해서 Xamarin 팀이 직접 FB SDK 등 주요SDK는 바인딩해서 배포/업데이트 관리하고 있다. 그럼 네이버, 카카오 SDK 이거 누가 React Native용으로 래핑 해서 배포해야 하는 것일까? 네이버, 카카오에서 해야 한다고 생각한다. 이 정도로 지속적으로 (해외에서) 대세급으로 성장하고 있는 플랫폼이면, 조금 손해 보는 것 같아도 기여하는 측면으로 해주는 선택을 했으면 좋겠다. 쓰는 사람들이 많아지면 해줄 계획일까? 사람들은 반대로 네이버, 카카오가 해주면 쓸려고 할지 모르겠다. 닭이 먼저냐 달걀이 먼저냐..

Google 같은 경우 FireBase의 최신 기술인 FireStore도 이미 빠방한 문서와 함께 React Native용 래퍼모듈을 제공하고 있고. [React Native Firebase Documentation]

아마존의 최신 기술인 AWS AppSync도 React Native용 문서를 제공한다. [React Native(Preview) AWS Appsync Documentation]

Progressive Web App

그리고 아주 쌘 놈이 오고 있다. 위에서 열심히 한말을 전부 쓰레기통에 집어넣어야 할 수도 있다는 위기감에 아찔하다. Progressive Web App(이하 PWA)는 한마디로 말해 (잘 만들어진) 하이브리드 앱의 끝판왕이다. 지금까지의 하이브리드 앱은 웹이지만 앱의 껍데기가(앱스토어 등록 등) 갖고 싶어서, 웹뷰 하나에 url 박고 Push Notification 좀 추가해서 스토어에 등록한 앱이다. 방금 말했듯이 이들이 필요했던 건 단지 바탕화면에 깔리는 앱 아이콘과 푸시뿐이다. 이것을 Android OS적으로 지원하고 추가로 오프라인 가동까지 가능하게 된 것이 PWA다. [Progressive Web App is a perfect solution for your Lite version] 이 글에 사례들과 함께 아주 잘 나와있다.

올라간다~~ 내가 짱 한번 먹어볼려고!

웹앱은 알맹이가 잘 만들어졌기만 하면 요즘은 정말 네이티브 앱과 비교해도 아무 문제가 없다. Angular나 React로 만든 웹앱도 약간의 작업을 추가하면 어렵지 않게 PWA로 바꿀 수 있다. 웹앱의 유일한 문제라 한다면 중구난방한 UX. 그들의 앱 생태계에 '디자인 가이드라인'을 철저히 세우고 이를 철저하게 수호해왔던 애플의 경우 내 생각에 이 UX 때문에 가장 고민을 하고 있지 않을까 생각된다. 최근 iOS의 PWA 지원 계획을 가늠하게 할 수 있는 정보가 하나 나오긴 했지만, 아직은 확실치가 않다. 그리고 PWA앱과 네이티브 앱이 공존했을 때의 혼동을 줄 수 있는 문제. 앱스토어를 통해 내오던 수익을 나눠먹을 것이라는 위기의식. 대세가 될 것은 분명하나 교통정리가 어떤 식으로 흘러갈지 모르겠다. iOS는 PWA용 포켓 바탕화면을 따로 만들어주려나? 뭐 예측이야 자유니 한번 해본다.

PWA가 대세가 된다고 하여도 앱의 모든 부분을 대체 가능한 것은 아니기 때문에 (스마트폰 디바이스의 센서를 사용해야 한다던지), React Native와 Xamarin.Forms가 없어질 것이라고 생각되지는 않지만, 이들 크로스 플랫폼이 가장 효력을 발휘하는 파트가 PWA의 그것과 겹치는 부분도 있어. 쉽게 가늠하기는 어렵겠다.

글을 마치며.

아직도 한국에서는 Active X를 몇년도에 없애니 하는 이야기를 마주해야 하는 현실이 참 원통하다. 아직도 모바일 결제가 여러 규제에 묶여 활성화되지 않는 현실이 고통스럽다.

그리고 그동안 여러 방법으로 새로운 기술들을 알리는 세션 스피커 분들, 커뮤니티를 만들어온 여러 분들, 네이티브 SDK 래퍼모듈을 배포하는 분들, 이를 지원하고 후원하는 공개SW개발자Lab 등의 기관 분들께 감사드린다.