플러터(Flutter)를 공부하며 앱을 만들어 봤습니다.

플러터(Flutter)는 구글에서 만든 Dart 언어 기반의 멀티 플랫폼 개발도구 입니다. 개인적으로 발표 시점부터 꾸준히 지켜보고 있었는데 조만간 뭔가 하나 만들어야지.. 하다가 한해가 넘어가 버렸습니다.

이전글(http://practical.kr/?p=53)에서도 이야기 한적이 있지만 멀티 플랫폼에 대한 환상(?)을 가지고 있어서 페이스북에서 나온 ReactNative(이하 RN)로 프로젝트를 진행한적이 있고(http://practical.kr/?p=19) 네이티브(주로 iOS) 개발을 하고 있기 때문에 네이티브 개발과 멀티플랫폼 개발툴간의 장단점을 조금은 안다고 생각하고 개발 과정을 한번 정리해 봤습니다.

UI 디자인

좋아하던 Xcode를 싫어하기 시작한게 아마도 Auto Layout이 나오기 시작한 시점이이 아닌가 싶은데요. 맞춰놓으면 작은 변경에도 Layout 전체를 조정해야 하는 Auto 스럽지(?) 않은 Xcode가 최근에 SwiftUI라는 Flex 스러운 UI 디자이너를 만들어서 모바일 개발에서 UI를 만드는 일이 사실 전체적으로 비슷한 기조로 가고 있는듯 싶습니다

Flutter 의 UI 디자인은 코드로 해야 합니다. 그래픽 디자인 도구가 없어요. 하지만 Flex 디자인의 구조를 차용한 Cascade 구조를 사용해서 모듈화를 할 수 있습니다. 컴포넌트를 좀 더 잘게 구성하고 모듈화 시키면 디자인 화면에 cascade된 UI Design Tree의 복잡성을 줄일 수는 있습니다만 코드와 통합된 UI 코드는 꽤 복잡하게 보일 수도 있지만 어렵지 않게 화면을 구성할 수 있습니다. 그리고 개인적으로는 RN의 CSS 구조보다는 좋다고 생각합니다. 그건 아마도 제가 CSS를 좀 싫어(?)해서 그런건지도 모르겠습니다. CSS를 잘 쓰시는 분들은 CSS 재사용 구조가 더 좋을 수도 있습니다. 절대적으로 개취(?)입니다.

컴포넌트 혹은 패키지

재사용 가능한 라이브러리를 플러터에서는 패키지라고 부릅니다. Node가 먼저인지 CocoaPod이 먼저인지 아니면 그전에도 패키지 매니저가 있었는지 잘모르겠습니다만 플러터에도 패키지 매니저가 내장되어 있습니다. pubspec.yaml 파일에 https://pub.dev 에서 검색한 패키지를 추가하고

> flutter get pub

위와 같이 실행하면 패키지를 설치해 줍니다. 다 찾아본건 아닙니다만 이젠 필요한건 거의 있는것 같습니다. 이번 앱 개발하면서도 여러개 테스트 해봤는데 보는 눈만 좋다면 코드를 상당히 줄일 수 있습니다. pub.dev 페이지에서 인기도를 참조하면 신뢰성 있는 패키지를 고룰 수 있습니다. 저는 15개나 사용했네요. 제가 페북에 패키지 설치를 의존성주입이라는 말을 썻더니 그게 아니라고 하시더라구요. 사실.. 아닐수도 있고 맞을 수도 있는 말입니다만 패키지는 그냥 설치라고 해두죠 ^^;

디버깅

Flutter는 개발도구를 Android Studio를 씁니다. 아마 구글 입장에서도 새 도구를 만드는것보다 이렇게 하는게 쉬웠을것 같네요. 익숙하기도 하구요. 그래서는 아니지만 디버깅 도구가 RN에 비해서 월등히 좋습니다. 물론 Xcode에 비할바는 아니지만 브레이크 포인트를 걸어서 스택데이터를 볼 수 있다는것만 해도 정말 좋습니다. 당연한거지만 RN으로 개발해 보면 이게 왜 좋은지 알게 됩니다.

문서화

이것도 RN과 비교할 수밖에 없는데 너무 빈약한 문서로 고생했던 기억이 있는데요. 그에 반해 구글답게 개발문서가 아주 잘 정리되어 있습니다. 게다가 이제 버전이 꽤 올라와 있는 상황이라 StackOverFlow에도 Flutter 관련 Q/A가 필요한만큼(?) 있습니다.

그래서

평소에 앱 혹은 프로그램을 하나 만드는게 가장 빠른 언어 공부 방법이라고 생각하고 있었습니다. 그래서 앱을 하나 만들었습니다. 대략 3주 정도 걸린것 같습니다. 딱히 별 아이디어가 없어서 만들기 쉬운걸로 만들었습니다. QRCode를 생성하고 읽어서 저장하고 조회하는 기본적인 기능을 가진 앱을 하나 만들었습니다.

앱을 만드는데 가장 기본적으로 필요한 라이브러리들을 선정하고 사용법을 읽히는 일은 기존에 네이티브앱을 만들때 하던 방식과 동일 할 수 밖에 없습니다. 기본 라이브러리를 쓸것인지 아니면 외부 패키지를 사용할 것인지를 선택하고 기능에 적절하게 구현하는 행위를 반복하다보면 앱이 하나 완성되어 있는거죠 ^^;

UI와 관련해서는 기본적으로 필요한 거의 대부분의 컴포넌트가 이미 만들어져 있습니다. 아래와 같은 화면을 구성하려면 화면 하단의 TabBar, 화면 상단의 TitleBar, 리스크 구조의 스크롤 그리드, 이미지를 보여기기 위한 Image 컴포넌트등 다양한 기본 컴포넌트와 그 구조를 정의 하기위한 Layout 컴포넌트들 준비되어 있습니다.

그외에 기본으로 지원되지 않거나 기본으로 지원되는 것들이 예쁘지(?) 않다면 외부 패키지를 설치해서 사용할 수 있습니다. 제경우 Store, QRCode Reader, 다국어 지원 등을 위하여 외부 패키지를 사용 했습니다.

제가 사용한 기본적인 몇가지 패캐지 리스트는 아래와 같습니다. 이외에도 몇가지가 더 있습니다만 대략 입맛에 맞게 고르시면 됩니다.

Data Store  - https://pub.dev/packages/provider
http 통신 - https://pub.dev/packages/http
다국어지원 - https://pub.dev/packages/easy_localization
QRCode - https://pub.dev/packages/qrcode
컬러피커 - https://pub.dev/packages/flutter_colorpicker

아이폰용앱은 아래 링크에서 다운 받으실 수 있습니다. 안드로이드용은 스토어 승인단계에 있는데 요즘은 안드로이드가 애플스토어보다 승인이 느리군요. 승인되면 링크 올릴께요. (5일만에 승인이 났습니다. 요즘은 아이폰이 더 빠릅니다)

아이폰앱 다운로드 - https://apps.apple.com/app/id1523448616
안드로이드 다운로드 - https://play.google.com/store/apps/details?id=com.rtlink.qscanner

결론

2020년에 앱개발은 굉장히 다양한 선택지가 있습니다. 업무의 특성에 따라 혹은 개발팀의 리소스, 혹은 취향에 맞게 다양한 개발도구를 선택 할 수 있습니다. 개인적으로 소프트웨어 개발의 가장 중요한 요소는 생산성이라고 생각하는 편이라 이런 도구가 많이 나오는건 환영하고 대부분 확인해 보는 편입니다만 그중에서도 Flutter는 굉장히 매력적인 도구라고 해야 할것 같습니다. 그리고 아마도 상당기간 사용하게 될것 같다는 생각을 했습니다.

아참! 앱은 무료! 공짜! 입니다. 그리고 개발의뢰 환영합니다. ^_^

Dart Cheat Sheet는 뽀너스!

2020년 7월 21일 박병일

React Native 다시 공부하기

React Native는 이미 2017년에 버즈아트에서 나름 빠르게 도입해서 프로젝트에 성공적으로 적용했던 적이 있었다. 링크참조(http://practical.kr/?cat=6) 그때 버전이 v0.45 수준이었는데 3년이 지난 지금도 React Native는 v0.61에 머물러 있다. 대체 언제쯤 v1.0을 내놓으려나…

2020년 현재 여전히 크로스(멀티)플랫폼(iOS, Android)을 지원하는것은 매력적이고 그동안 꽤 많은 기술적 진보가 있었을 것이라는 생각을 염두에 두고 다시 한번 공부를 시작해 볼까? 하는 생각에 연습용 프로젝트를 하나 만들기 시작했다. 이글을 쓰는 이유는 프로젝트를 만들고 보니 기억 나는게 하나도 없어서 뭘 했는지 정리하기 위함이다.

모바일 멀티플랫폼

잠시 멀티 플랫폼 이야기를 하고 넘어가보자. 최근 2~3년 사이에 모바일 플랫폼 개발과 관련한 프레임워크는 전통적인 Swift기반의 Xcode, Java & Kotlin 기반의 Android Studio와 더불어 Dart 기반의 Flutter, C# 기반의 Xamarin 등이 쏟아지며 개발툴 전성시대가 열린것 같다. 성능도 많은 향상을 보여서 거의 네이티브 성능을 따라오는 수준까지 도달한 것으로 보인다. 어떤것을 선택해도 크게 문제가 없을것으로 생각된다. 하지만 역시 가장 좋은것은 손에 익은것이 아닐까 싶다.

나 개인적으로는 오래도록 사용해온 Obj-C 기반의 Xcode가 가장 좋지만 이건 멀티 플랫폼이 아닌지라(iOS만지원) 제외하고 최근 2~3년간 JavaScript 특별히 Vue.js / Node.js를 사용해 오고 있었기 때문에 JS 기술을 그래도 활용할 수 있는 React Native에 끌리는건 당연한 선택일 수 밖에 없다. 하지만 처음 접하는 모바일 멀티 플랫폼 개발이라면 Dart/Flutter이 좀더 낫지 않을까 하는 생각인데 이유는 구글의 개발자 문서 지원이 매우 좋고 React Native에 비하여 좀 더 좋은 실행 성능을 내고 있다고 알려져 있기 때문이다.

Getting-Started

프로젝트 시작은 여기서 한다. Expo를 이용하는 방법과 Cli 툴을 이용하는 방법이 있는데 나는 Cli 툴을 이용하여 프로젝트를 생성 했다. Expo를 쓰면 폰에 직접 앱을 올려서 바로 결과를 볼 수 있고 Cli툴을 쓰면 Xcode 및 각종 도구를 깔아서 시뮬레이터에서 테스트를 할 수 있다. 나중에 스토어용으로 빌드를 하기 위해서 후자의 방법으로 설치하는 것이 좋다. 하지만 간단한 테스트는 Expo가 훨씬 편하다.

https://reactnative.dev/docs/getting-started

Navigation

앱을 만들려면 기본적으로 메뉴 시스템이 있어야 한다. 모바일 시스템에서 메뉴 시스템은 보통 Tabbar – Navigation, Drawer – Navigation 두가지 중에서 선택하는 것이 일반적인 선택이다. 한동안 Drawer 메뉴가 유행을 하다가 최근 다시 Tabbar 시스템이 유행인것 같아서 나는 Tabbar 시스템 기반으로 했다.

네비게이션 라이브러리는 ReactNavigation을 사용했다. 아마 개발자들이 가장 많이 사용하는 메뉴 시스템이고 Tabbar와 Drawer를 모두 지원한다.

https://reactnavigation.org/docs/getting-started

import React from 'react';
import {NavigationContainer} from '@react-navigation/native';
import { createBottomTabNavigator } from '@react-navigation/bottom-tabs';

import Home from './src/Home';
import Profile from './src/Profile';
import Settings from './src/Settings';

const Tab = createBottomTabNavigator();

export default function App() {

  return (
    <NavigationContainer>
      <Tab.Navigator>
        <Tab.Screen name="Home" component={Home}/>
        <Tab.Screen name="Profile" component={Profile}/>
        <Tab.Screen name="Settings" component={Settings}/>
      </Tab.Navigator>
    </NavigationContainer>
  );
}

코드의 결과로 아래와 같은 메뉴 시스템이 나왔다. 메뉴에 아이콘을 넣거나 좀더 예쁘게 꾸미려면 https://reactnavigation.org/docs/tab-based-navigation 를 참조하자.

Rest API Communication

Rest API 서버에서 데이터를 가지고 와서 목록 형태로 보여주는 것은 axios를 이용한다. https://github.com/axios/axios 를 참조한다. 컴포넌트가 마운트 될때 API 서버에서 데이터를 가져와서 state에 저장했다.

import axios from "axios";

...

componentDidMount() {
 axios.get("https://jsonplaceholder.typicode.com/users")
  .then(res =>{
   this.setState({ persons:res.data });
  });
}

FlatList – 목록보여주기

모바일 화면의 대부분은 목록(List)이다. 상하스크롤을 통하여 데이터 리스트를 조회 하고 화면을 선택하면 상세화면으로 진입하는 구성이 대부분이다. 이 리스트는 스크롤이 계속되는 특성상 화면에 보이는 만큼만 메모리 관리를 하지 않으면 너무 많은 메모리를 사용해서 앱을 다은 시키는 원인이 된다. React Native의 FlatList는 자동으로 메모리 관리를 해주기 때문에 필수적으로 쓰는 컴포넌트이다.

대략 아래와 같이 연결한다.

function Item({item, navigation}) {
 return (
   <View>
    <Text>{item.name}</Text>
   </View>
 )
}
....

render() {
 return (
  <View>
   <FlatList
    data={this.state.persons}
    renderItem={({item})=><Item item={item}/>}
    keyExtractor={item=>item.id}
   />
  </View>
 )
}
FlatList 결과화면

상태관리(Store)

React Native의 상태 관리는 Redux로 하는것이 기본이다. 하지만 Redux의 구조와 사용법이 직관적이지 않아서 좀더 직관적으로 쓸 수 있는 MobX를 사용했다. Redux와 MobX의 비교와 관련해서 우아한 형제의 기술블로그에 좋은 자료가 있어서 링크에서 자세한 정보를 얻을 수 있다.

https://woowabros.github.io/experience/2019/01/02/kimcj-react-mobx.html

MobX는 매우 직관적으로 Store를 사용할 수 있는데 이것은 마치 Vue.js의 Store 처럼 단순하게 사용할 수 있다. 사실 그에 비하면 Redux는 너무 복잡한 구조를 가진것이 사실이다. 대략 아래와 같은 코드를 이용하여 두개의 페이지에서 동일한 값의 증가를 확인 할 수 있다.

import {observable} from 'mobx';

class CounterStore {
 @observable counter = 0;
 
 increment() {
  this.counter++;
 }

 decrement() {
  this.counter--;
 }
}
export default new CounterStore();
import React, {Component} from 'react';
import { observer } from 'mobx-react';
import { StyleSheet, Text, View, Button } from 'react-native';

import CounterStore from '../../mobx/store'

@observer
export default class HomeScreen extends Component {
 render() {
  return (
   <View >
    <Text style={{fontSize: 60}}>
     {CounterStore.counter}
    </Text>
    <Button
     title="Increase"
     onPress={() => CounterStore.increment()}
    />
   </View>
  )
 }
}

Source Code – GitHub

아래 링크에서 위의 셈플 프로젝트의 소스코드는 아래 링크에서 다운로드 할 수 있다.

https://github.com/bipark/react_native_study

관련 링크

React 스터디 – https://ko.reactjs.org/docs/hello-world.html

Components – https://reactnative.dev/docs/activityindicator

Navigation – https://reactnavigation.org/docs/getting-started

Axios – https://github.com/axios/axios

Awesome React Native – https://github.com/jondot/awesome-react-native

리액트 프로젝트에서 MobX 사용하기 – https://velog.io/@velopert/MobX-2-%EB%A6%AC%EC%95%A1%ED%8A%B8-%ED%94%84%EB%A1%9C%EC%A0%9D%ED%8A%B8%EC%97%90%EC%84%9C-MobX-%EC%82%AC%EC%9A%A9%ED%95%98%EA%B8%B0-oejltas52z

React에서 Mobx 경험기 (Redux와 비교기) – https://woowabros.github.io/experience/2019/01/02/kimcj-react-mobx.html

카카오 로그인 모듈 – https://github.com/react-native-seoul/react-native-kakao-login

Practical / 대표개발자 박병일

리액트 네이티브(React Native) 프로젝트에서 생각해야할 것들

리액트 네이티브(React Native) 프로젝트에서 생각해야할 것들

  • 최근 프로젝트에서 프론트앤드 기술 스택을 페이스북의 React 와 React Native(이하 RN)로 통일(?) 했습니다. 기존의 기술스택(Angular & Native)을 버리고 완전 새로운 기술 스택(React Native & React)을 도입해서 앱과 웹 프론트 개발을 완료 했습니다. 아래 몇가지 이야기로 왜 기술을 바꿨는지 어떤점이 좋은점이고 위험한지 정리해봤습니다.

기술 스택 변경의 이유

  • 스타트업들은 작은 회사 입니다. 많은 기술 인력을 채용할 여력이 없고 운영할 능력도 부족합니다. 하지만 한 팀이 되어야 하고 동일한 어조로 서로 소통 할 수 있어야 한다고 생각 했습니다. React와 RN은 동일한 자바스크립트 기술 기반위에 있어서 적은 개발팀 내부에서 여러가지 언어와 기술 스택이 분리되어 있어서 언어들이 달라서 발생할 수 있는 분리 장벽이 없습니다. 그리고 누군가 어려운 일이 생기면 서로 도움을 주고 받을 수 있는 팀 구조를 만들 수 있다고 생각 했습니다. 이게 작은팀에서는 꽤 중요한 요소 입니다.

크로스플랫폼에 대한 개인적인 환상

  • 제 개인적으로 크로스플랫폼이라는 말에 아주 오~래 된 환상이 있었습니다. 한번 만들면 여기 저기서 돌릴 수 있어 라는 말은 석기시대 때부터 있었던 사기(?) 같은 이야기 였고 자바가 어느정도 그문제를 해결하는가 싶더니 최근엔 LLVM을 통해서 많은 언어들이 이젠 진짜 가능한것 처럼 이야기 하고 있습니다. 리액트와 RN 역시 그 대열에 서 있긴 하지만 역간 다른 스텐스를 취합니다.
  • 페이스북 개발팀은 니가 잘하면 한 70% 정도의 코드는 공유 할 수 있을거야~ 라고 말하더군요. 이정도면 대박 아닌가 하는 생각도 선택의 이유였습니다. 결국은 개인적인 환상을 성취하기 위해 회사를 위험에 빠트리게 됩니다.

선택의 불안감

  • 하지만 불안감이 존재 했습니다. 개인적으로는 꽤 오랫동안 아이폰으로 네이티브 개발을 해왔기 때문에 RN이 네이티브의 성능을 따라갈 수 있을지 의문스러웠습니다. 그리고 RN은 글을 쓰고 있는 현재도 버전 0.45에 머물고 있고 국내에서 성공 사례로 알려진 케이스도 별로 없었습니다.
  • 게다가 RN으로 시작 했다가 네이티브로 돌아간 이야기(https://brunch.co.kr/@jamess/5) 와 같은 블로그가 불안감을 더 높이기도 했습니다.

파일럿 프로젝트

  • 그래서 파일럿 프로젝트를 먼저 하기로 했습니다. 성능을 한번 보면 되겠지 싶었습니다. 그리고 새로 만난 팀원들의 합도 한번 맞춰 보구요.
  • 일주일 정도의 작업끝에 메인 피드 하나를 만들어서 각종폰에서 테스트 했습니다. 아이폰은 매우 훌륭한 성능이 나왔고 안드로이드는 뭔가 찜짐하긴 했지만 커스터마이즈를 좀 하고 캐싱을 좀 하면 나아 지겠지 하는 생각으로 이정도면 시작 할만하다고 평가 했습니다.
  • 하지만 그게 아니었다는게 나중에 밝혀 집니다.

RN 개발의 기술적인 포인트들

  • 결론적으로 파일럿 프로젝트를 포함해서 아이폰, 안드로이드, 웹프론트를 4명의 인원으로 약 3개월(100일)만에 개발완료하고 성공적(?)으로 서비스를 오픈 했습니다.
  • 그 과정에서 겪은 몇가지 기술적 혹은 개발 운영 측면에서 본 문제점 및 해결 방안을 아래와 같이 정리 해보겠습니다.

CSS

  • RN의 개발과정은 웹프론의 개발 과정과 동일한 순서와 방법으로 진행 하는 것이 좋습니다. 웹프론트를 개발해 보신분은 아시겠지만 UI 디자인이 나오면 CSS를 이용해 화면을 먼저 만들게 됩니다. 그리고 HTML이 나오면 거기에 데이터를 입히는 과정을 진행 하죠.
  • 기존 네이티브앱 개발은 한명의 개발자가 화면구성과 데이터 연결을 동시에 작업하는 것이 일반적이었지만 RN의 특성상 CSS를 이용한 화면 구성이 이루어 지므로 CSS를 잘 다루는 웹 퍼블리셔가 필수적인 요소입니다.
  • 다행히 저희팀에는 CSS를 아주 잘 다루는 개발자가 있었습니다. 이것이 중요한 또 한가지 이유는 일반적으로 Hot-Loading을 이용한 시뮬레이터 기반에서 개발을 하게 되는데 이게 주로 아이폰 시뮬레이터 기반에서 개발을 시작하기 때문에 나중에 안드로이드에 올려보면 화면이 깨지거나 오동작을 하는 경우가 꽤 빈번하게 발생합니다. 이유는 아직 RN이 베타라서 그럴 수도 있고 CSS를 깔끔하게 정리 하지 못한 탓일 수도 있습니다만 제 생각으로는 RN으로 만든앱들에서 UI관련된 오류 문제는 거의 CSS를 잘못 만든 탓이 아닌가 싶습니다.

리스트 컨트롤

  • 앱개발에서 가장 많이 쓰는 컨트롤은 리스트 컨트롤입니다. 아이폰과 안드로이드 각각 다른 이름의 리스트 컨트롤이 있지만 앱화면의 거의 대부분은 이 리스트 컨트롤 기반으로이루어진다고 해도 과언이 아닙니다. RN에도 ListView라는 리스트 컨트롤이 있습니다.
  • 저희팀이 앱을 거의 다만들고 여러가지 폰에서 테스트를 시작하면서 고난에 빠지게 된 이유가 이 ListView 때문이었습니다. 아이폰은 매우 깔끔하게 잘 돌아갔습니다. 물론 아이폰도 리스트를 계속해서 로딩 하다보면 메모리 부족 현상이 나타나면서 앱이 크래시 되는 문제가 더러 있었습니다만 가장 심하게 나타난 것은 역시 안드로이드 구중에서도 하위 기종에서 문제가 많았습니다.
  • 10페이지를 넘기지 못하고 앱이 죽어 버리는 경우가 다반사 였습니다. 꽤 심각 했습니다. 문제의 해결방법을 찾던중 RN의 3월 이후 버전에 FlatList 라는 컨트롤이 있다는걸 발견 했습니다. 몇일이 걸리긴 했지만 ListView를 FlatList로 변경 했습니다.
  • 링크(https://facebook.github.io/react-native/blog/2017/03/13/better-list-views.html)를 살펴 보시면 알 수 있겠지만 FlatList는 메모리 사용과 성능 문제에서 기존 ListView가 가지고 있던 문제들을 대부분 해결 했고 저희팀도 결과로 확인 할수 있었습니다.
  • 안드로이드 하위 기종에서도 크래시없이 거의 모든 페이지를 보여주는 결과를 보여 줬습니다.

브리지 라이브러리

  • RN은 기본적으로 웹뷰가 아닌 네이티브 방식으로 실행됩니다. JS를 통해 만든 코드를 앱 내부에 임포트된 네이티브 코드를 실행 시키면서 기존의 웹뷰 빙식의 하이브리드 앱보다 더 빠르게 실행 시킬 수 있도록 만든 플랫폼입니다. 이것은 기존에 만든 네이티브 스테틱 라이브러리를 사용할 수도 있다는 이야기 이기도 합니다. RN에서 지원해 주지 않는 기능들은 네이티브로 만들어서 연결 할 수도 있다는 이야기 입니다. 그것을 위해 존재하는 연결방법이 브리지 라이브러리 입니다.
  • https://js.coach/react-native 에는 이미 만들어서 사용가능하게 구성된 상당이 많은 라이브러리들이 있고 그 라이브러리들은 아이폰과 안드로이드를 동시에 지원 하도록 구성된 것들이 많습니다.
  • 하드웨어 연결 혹은 카메라, 비디오, 기타 다양한 기능을 가진 브리지 라이브러리들이 있고 만약 없다면 스스로 만들 수도 있습니다.

자바스크립트

  • 웹프론트팀을 운영하고 있는 회사라면 JS 기술 혹은 환경에 대해 익숙 할 수도 있지만 네이티브앱만 만들어 왔다면 JS로 앱을 만드는 일에는 꽤 많은 허들이 존재 할것 같습니다.
  • ES6, Webpack 기타등등.. 너무 많은 디펜던시에 얽혀 있어서 요즘은 JS헬이라는 말도 있을 정도입니다만 Create-React-Native-App과 같은 cli도구를 이용하면 기본적인 환경 구성은 쉽게 할 수도 있습니다. (https://github.com/react-community/create-react-native-app)
  • 그렇지만 JS를 이용한 개발은 어쩔 수 없는 공부시간이 필요한것 같습니다. 최근에는 TypeScript를 많이들 사용해서 JS의 Type 오류들을 해결해 나가면서 구조화 시키는 기술들을 많이 사용하고 있는것으로 확인하고 있습니다. 저희도 다음 업그레이드에서는 TypeScript를 도입해 보려고 준비하고 있습니다.

결론

  • RN은 매우 매력적입니다.
  • 개인적으로 가장 매력적인것은 더이상 아이폰앱을 만드는 AutoLayout을 사용하지 않아도 된다는 부분이었습니다. 사실 애플이 AutoLayout을 도입한건 매우 큰 실책이라고 여전히 생각하고 있습니다. Flex Layout얼마나 좋은데요.
  • 아이폰과 안드로이드를 한개의 코드 베이스로 개발하고 동일한 기술스택으로 웹까지 개발 할 수 있다는 것은 예산이 적은 스타트업에겐 매우 좋은 소식이 아닐 수 없습니다. 하지만 기존의 개발 습성과 기술 전환에 들어가는 리스크와 비용을 생각하면 쉽게 올라 탈 수 있는 말은 아닌것 같습니다.