| {{{#!wiki style="margin: -10px -10px" |
<tablealign=center><tablebordercolor=white,#1f2023> |
React Native | }}} | |
| 종류 | 라이브러리 | |||
| 라이선스 |
MIT 라이선스 크리에이티브 커먼즈 라이선스 |
|||
| 개발 | Meta | |||
| 언어 | JavaScript, TypeScript | |||
|
|
||||
[clearfix]
1. 개요
React의 문법으로 안드로이드, iOS 앱을 개발할 수 있는 프레임워크이다. React를 배웠던 개발자라면 몇시간만에 익숙해질 수 있을만큼 React와 거의 유사한 문법을 가지고 있으며, 실제로 차이나는 부분은 브라우저의 HTML Element를 사용하는 것이 아니라 View, Text 등의 자체 태그를 사용하는 점과 CSS를 사용하지 않고 오직
CreateStyleSheet를 이용한 스타일만 지원하고, 일부 속성이 가감되었다는 것 정도. 현재는 웹과 동일한
CSS 요소 사용을 위한 Styled Component 및 PostCSS를 지원하므로 웹개발자나 퍼블리셔도 무리없이 UI구성이 가능하다.React Native Render HTML이라고 해서 리액트 네이티브에서 HTML을 사용할 수 있게 해주는 라이브러리도 있다.
2. 지원 플랫폼
거의 모든(Windows Phone을 제외한) 플랫폼을 지원한다.
3. 다른 라이브러리와의 비교
사실상 크로스 플랫폼은 React Native와 Flutter가 양분하고 있다고 봐도 된다. 따라서 Flutter와 비교를 위주로 서술한다.App Store 심사 없이 UI와 function을 업데이트할 수 있는 Code Push 기능을 공식적으로 지원하는 플랫폼은 하이브리드와 크로스플랫폼 전체를 통틀어 React Native가 유일하기 때문에 큰 장점이라 볼 수 있다. Flutter도 존재는 하지만, 서드파티 라이브러리이며 버전이 낮기에 신뢰도가 낮다.[3]
Flutter 는 React Native와 비슷한 성격을 가지고 있으나[4] JavaScript가 아닌 구글의 Dart언어를 사용한다. 패키지의 수는 React Native가 더 많지만, 페이스북의 성향은 대부분의 기능들을 서드파티로 사용하라에 가깝고, 구글은 대부분은 공식에서 지원해준다는 것에 가까워서 직접적인 비교는 힘들다. JavaScript 기반이기에 기존 개발자가 접근하기에는 유리하다는 장점이 있지만[5] 동시에 장기적인 관점에서 보면 확장성 및 유지보수, WASM과의 연계에 있어 희망이 없어보일 정도다. 모든 면에서 두 기술이 서로 같아질 경우를 비교하면 개발의 생산성에 있어 리액트는 JavaScript 기반 언어의 태생적인 한계 때문에 Flutter를 따라잡기가 구조적으로 불가능하다.
플러터와 비교했을 때 프레임 드랍 문제가 존재한다. 이를 해결하기 위해 Flutter가 Skia로 렌더링하듯이 React Native Skia 가 개발되고 있다.
아이러니하게도 React Native 프로젝트를 관리하고 있는 Meta에서는 자사 앱 개발을 React Native가 아닌 안드로이드와 iOS 네이티브로 하고 있다.
이외에는 ASP.NET에서 파생된 Blazor.NET과 Xamarin에서 파생된 MAUI 또한 경쟁 상대다. 특히 Blazor는 윈도우 기반 플랫폼에서는 Flutter조차도 상대가 되지 않을 정도이며 C# 기반의 안정성과 개발 편의도 이전보다 상당히 증대되었다. Blazor.NET으로 코딩을 해보면 C#을 사용함에도 Svelte와 비견될 정도의 생산성을 느낄 수 있다.
4. 크로스 플랫폼
크로스 플랫폼은 맞다. 그러나 단순히 하나의 코드가 Android, iOS 등 다양한 플랫폼에 맞게 추가적인 노력을 들이지 않아도 알아서 척척 다 해주는 것이라고 착각하여 함부로 적용하는 것은 조심해야 한다. 개발자 자신들도 그렇지만 개발자를 고용하는 입장에서도 더욱 주의해야 한다.특히나 영세한 업체에서 Android, IOS 개발자를 각각 고용하기 힘들고 2명을 쓰는것이 큰 부담이라고 생각하여 React Native 개발자 한명만 뽑으면 되지 않겠느냐고 단순히 접근하는 경우가 많은데 일반적인 쇼핑몰 수준까지는 가능할 수 있다. 그러나 네이티브한 기능을 사용할때 큰 문제가 된다. React Native 개발자가 Android, IOS 네이티브 앱 개발을 하지 못할 경우 해당 기능은 그냥 못한다고 보면 된다.
예를 들어 카카오 로그인 기능을 넣는다고 하자. 카카오에서 React Native 모듈을 지원해주지 않는다면, Android와 IOS 네이티브 코드를 각각 작성해야만 한다. 거기에 모듈을 사용하다 네이티브한 코드를 변경할 일이 생기거나 업데이트를 한다면 어떻게 대응할 것인가?
필요한 모듈을 별로 고민해보지 않고 사용하는 개발자 혹은 PM들이라면 전혀 신경을 쓰지 못했을 수 있으나 이 위험성을 간과하지 말아야 한다. 네이버 지도 API의 경우도 React Native 지원 모듈을 공식이 아니라 오픈 소스 개발자들이 지원해주고 있다. 카카오의 경우도 마찬가지이며, 적지 않은 오픈소스 모듈들은 미구현된 기능들도 많고 업데이트되는 기능을 따라가지 못하기도 한다. UI를 구현할 때도 네이티브로 건들지 않고서는 구현하기 껄끄러운 것들을 지원하는 React Native 모듈이 없다면 그 UI는 만들지 못하는 것이다.
이 상황이 가장 와닿는 예시로, VAN사를 통한 카드 결제 기능을 사용하는 앱을 개발한다고 가정해 보자. VAN사에서는 아직도 C++, C#, C 모듈만 제공하는 곳이 많으며 조금 신경쓰는 곳마저 Java 정도를 지원할 뿐이고 JavaScript를 지원하는 곳은 더욱이 적다. 자, React Native만 다룰줄 아는 개발자에게 이러한 대체할 수 없는 외부 모듈을 반드시 사용하라고 한다면 bridge[6]를 구현해낼 수 있을까?
물론 Android, IOS 개발자가 준비되어 있고 유지보수가 잘 되는 탄탄한 기업은 오히려 네이티브 앱에서 React Native로 갈아타기도 한다. 왜냐하면 한번 정식 버전 출시 후에는 큰 변경이 없는 마이너한 업데이트가 대부분이며 이럴 경우에는 React Native로 갈아타며 얻는 생산성이 좋기 때문.
5. 헤르메스 엔진
[1]
어째서인지
메타도
애플도 아닌
마이크로소프트가 개발하고 있다.
[2]
지원 종료
#
[3]
이 부분은 trade-off라고 할 수 있다. Flutter는 네이티브 코드로 미리 컴파일 되기 때문에 속도가 빠른 대신 코드 푸시가 불가능한 것이고 리액트 네이티브는 속도가 희생되는 대신 자바스크립트 코드만 서버에서 따로 푸시해주면 앱 상에서는 자바스크립트 런타임에서 실시간으로 컴파일하며 돌아가는 것이기 때문이다. 그러나 Flutter 개발 시 사용하는 언어인 Dart는 JIT 컴파일와 AOT 컴파일 모두 지원하기 때문에 기술적으로 불가능하지는 않다. 다만 공식 지원 계획이 없고 있다 하더라도 속도가 희생될 뿐이다.
[4]
그럴 수밖에 없는 것이 플러터 자체가 리액트 네이티브를 참고하여 만들어진 것이기 때문이다.
[5]
신규 개발자가 배우기에는 오히려 Dart가 유리하다. JavaScript는 그동안 수많은 확장을 거치며 동시에 배워야 할 내용이 자바와 비견될 정도로 늘어났다. HTML, CSS와 각종 데브옵스 개념은 기본이고, 서드 파티 라이브러리 종류들은 세어보기도 힘들 정도다. 반면 Flutter는 10개 이내의 서드파티로도 안정적인 웹앱 서비스가 가능하다. 게다가 은근히 기존 백엔드와의 호환성도 뛰어나서 백엔드로 자바 등을 사용하고 프론트엔드만 Flutter로 작성하기도 하는데 이 경우에도 JS 기반 언어와는 생산성에서 비교가 안 된다. 결정적으로 Dart라는 언어 자체가 확장성이 크며 Flutter는 윈도우, 리눅스와 맥 등의 멀티플랫폼이 커버가 된다.
[6]
Turbo Native Modules로 개선하고 있다고는 해도 네이티브 구현이 간단하지 않은 것은 여전히 마찬가지이다.