| <colbgcolor=#ffffff,#1f2023><colcolor=#61DAFB> 리액트 네이티브 React Native | |
| | |
| 종류 | 라이브러리 |
| 라이선스 | MIT 라이선스 크리에이티브 커먼즈 라이선스 |
| 개발 | |
| 언어 | JavaScript, TypeScript |
| | |
[clearfix]
1. 개요
React의 문법으로 안드로이드, iOS 앱을 개발할 수 있는 프레임워크이다. React를 배웠던 개발자라면 몇시간만에 익숙해질 수 있을만큼 React와 거의 유사한 문법을 가지고 있으며, 실제로 차이나는 부분은 브라우저의 HTML Element를 사용하는 것이 아니라 View, Text 등의 자체 태그를 사용하는 점과 CSS를 사용하지 않고 오직CreateStyleSheet를 이용한 스타일만 지원하고, 일부 속성이 가감되었다는 것 정도. 현재는 웹과 동일한 CSS 요소 사용을 위한 Styled Component 및 PostCSS를 지원하므로 웹개발자나 퍼블리셔도 무리없이 UI구성이 가능하다.2. 지원 플랫폼
거의 모든(Windows Phone을 제외한) 플랫폼을 지원한다.
3. 다른 라이브러리와의 비교
사실상 크로스 플랫폼은 React Native와 Flutter가 양분하고 있다고 봐도 된다. 따라서 Flutter와 비교를 위주로 서술한다.앱스토어 심사없이 UI와 function을 업데이트할 수 있는 Code Push 기능을 공식적으로 지원하는 플랫폼은 하이브리드와 크로스플랫폼 전체를 통틀어 React Native가 유일하기 때문에 큰 장점이라 볼 수 있다. Flutter도 존재는 하지만, 서드파티 라이브러리이며 버전이 낮기에 신뢰도가 낮다.[3]
Flutter 는 React Native와 비슷한 성격을 가지고 있으나[4] JavaScript가 아닌 구글의 Dart언어를 사용한다. 패키지의 수는 React Native가 더 많지만, 페이스북의 성향은 대부분의 기능들을 서드파티로 사용하라에 가깝고, 구글은 대부분은 공식에서 지원해준다는 것에 가까워서 직접적인 비교는 힘들다.
플러터와 비교했을 때 프레임 드랍 문제가 존재한다. 이를 해결하기 위해 Flutter가 Skia로 렌더링하듯이 React Native Skia 가 개발되고 있다.
아이러니하게도 React Native 프로젝트를 관리하고 있는 Meta에서는 자사 앱 개발을 React Native가 아닌 안드로이드와 iOS 네이티브로 하고 있다.
ionic이 버전5 부터 React를 지원하기 시작했다. 기존 ionic 생태계의 플러그인인 cordova와 capacitor를 적절히 조합하여, 네이티브 기능을 선택적으로 제공할 수 있게 되었다.
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[5]를 구현해낼 수 있을까?
물론 Android, IOS 개발자가 준비되어 있고 유지보수가 잘 되는 탄탄한 기업은 오히려 네이티브 앱에서 React Native로 갈아타기도 한다. 왜냐하면 한번 정식 버전 출시 후에는 큰 변경이 없는 마이너한 업데이트가 대부분이며 이럴 경우에는 React Native로 갈아타며 얻는 생산성이 좋기 때문.
5. 헤르메스 엔진
[1] 어째서인지 메타도 애플도 아닌 마이크로소프트가 개발하고 있다.[2] 지원 종료 #[3] 이 부분은 trade-off라고 할 수 있다. Flutter는 네이티브 코드로 미리 컴파일 되기 때문에 속도가 빠른 대신 코드 푸시가 불가능한 것이고 리액트 네이티브는 속도가 희생되는 대신 자바스크립트 코드만 서버에서 따로 푸시해주면 앱 상에서는 자바스크립트 런타임에서 실시간으로 컴파일하며 돌아가는 것이기 때문이다. 그러나 Flutter 개발 시 사용하는 언어인 Dart는 JIT 컴파일와 AOT 컴파일 모두 지원하기 때문에 기술적으로 불가능하지는 않다. 다만 공식 지원 계획이 없고 있다 하더라도 속도가 희생될 뿐이다.[4] 그럴 수밖에 없는 것이 플루터 자체가 리액트 네이티브를 참고하여 만들어진 것이기 때문이다.[5] Turbo Native Modules로 개선하고 있다고는 해도 네이티브 구현이 간단하지 않은 것은 여전히 마찬가지이다.