플러터 vs 리액트 네이티브 승자는 리액트인 이유

Flutter vs React Native

 

 

요즘 크로스 플랫폼이 유행이지요. 게임도 그렇고 앱개발도 그렇습니다. 회사에서 한창 크로스 플랫폼 기술들을 검토하라 하고 최근들어 정말 많은 프레임워크들을 찍먹해 보았습니다. 코르도바, 리액트, 리액트 네이티브, 플러터 등등.

 

공부를 하며 결국에는 리액트 네이티브 vs 플러터 둘중 선택해야 하는 경우가 다가왔습니다.

 

저는 리액트 네이티브가 승자라고 결론내렸습니다. 그 이유에 대해 적어보겠습니다.

 

 

 

 

1. 플러터 첫 인상은 좋으나 알면 알수록 별로

처음 저의 플러터 첫 인상은 좋았습니다. 리액트네이티브 처럼 자바스크립트 브릿지가 아닌 직접 os의 캔버스에 접근하여 네이티브급 성능을 낸다는 내용이였습니다. 개발자 입장에서 속도는 몹시 중요한 요소이고 네이티브급으로 속도가 나온다니 혹하지 않을 수 없습니다. 

 

허나 자료를 찾아보니 어느정도는 맞는 말이나 여러 벤치마크를 확인해본 결과 리액트 네이티브와 큰 속도의 차이가 없으며 리액트 네이티브의 헤르메스 엔진 적용 이후 둘은 성능에 큰 차이가 없다고 합니다.

 

또한 개발을 하다보며 단순 ui를 넘어 좀더 딥하게 들어갈 수록 리액트 네이티브와 플러터의 커다란 차이를 보였습니다.

카메라와 영상처리에 관한 라이브러리를 찾아보니 플러터는 쓸만한게 하나도 없고 리액트 네이티브는 정말 많았습니다.

 

무언가 기술을 딥하게 사용할 수록 플러터는 네이티브 코드가 필요한게 느껴지고 반면 리액트 네이티브는 네이티브에 대한 의존이 크게 필요하지 않았습니다.

 

 

 

2. 리액트 네이티브는 자바스크립트 진영의 라이브러리 사용이 가능하다

이게 정말 크게 다가왔습니다. 이미 프로그래밍 랭귀지 대장격인 자바스크립트 진영의 라이브러리를 사용할 수 있다는게 엄청난 장점으로 다가왔습니다. 반면 플러터는 생태계가 엄청 빈약하고 검증된 라이브러리가 몇개 없으며 기술적으로 딥하게 들어가는 부분들은 구현이 안된게 어마어마하게 많았습니다.

 

 

 

 

3. 플러터는 검증된 빅테크 앱이 없다

플러터로 구현된 앱중에 아직 빅테크라 불릴만한 앱들이 얼마 없습니다. 그나마 유명한건 누뱅크 정도.

반면 리액트 네이티브의 경우 페이스북, 트위터, 인스타그램, 윅스, 디스코드, 스카이프, 우버이츠등 이름만 들어도 아는 수많은 앱들이 있습니다.

기술적으로 딥하게 들어갈 때 리액트 네이티브는 항상 해결책이 있던 이유가 바로 이런 이유가 아닐까 싶네요.

 

 

 

 

4. 리액트 네이티브는 코드푸시가 있다

길게 설명하지 않겠습니다. 리액트 네이티브의 완승입니다

 

 

 

 

 

5. Killed by Google

플러터 알아보면서 알게 된 문장인데 홈페이지도 따로 있더군요. 제가 애용했던 구글듀오는 언제죽은건지 ㅠㅠ

구글은 자기가 만든거 많이 죽인다고 합니다. 플러터도 예외가 아닐 수 없습니다.

 

https://killedbygoogle.com

Killed by Google

 

 

 

6. 리액트 네이티브도 지원이 뜸해지고 있다?

이런 얘기도 중간에 보았습니다. 그래서 찾아봤는데 금시초문이라는 얘기도 있고 해외에서도 관련 내용 찾아봤는데 딱히 그런 논의가 있지는 않았습니다.

 

결정적으로 2023년이 되자마자 리액트 네이티브 0.71버전이 릴리즈 되었습니다. 여전히 개발중이라는 얘기지요.

 

https://reactnative.dev/versions

Versions · React Native

 

 

메타에서 리액트 네이티브로 먹고살고 있는데 이를 버린다면 다른 기술스택을 찾을텐데 딱히 그런 동향도 보이지 않습니다. 여전히 지원 할 것으로 보입니다.

 

 

 

 

 

7. 플러터의 심각한 가독성 문제

flutter의 지독한 네스팅 지옥

아주 심각한 문제입니다. 가독성이 진짜 토나옵니다. 특히 저 망할 네스팅은 아무리 해도 적응이 되지 않습니다. 플러터에서도 이를 인지하고 있는지 IDE에 편히 수정하는 기능을 넣어주긴 했지만 문제는 프로젝트 사이즈가 커질 때 입니다.

 

프로젝트 사이즈가 몹시 커져 원격서버에서 관리하는 경우 가끔가다 간단한 수정사항을 vim으로 작업을 하는경우가 있을 때 플러터는 그냥 작업이 불가능합니다.

 

무조건 안드로이드 스튜디오 같은 전용 IDE를 물려주어야만이 저 네스팅 지옥에서 그나마 적응할 수 있으며 다른 편집기는 꿈도 꾸지 못합니다.

 

 

또한 기본적으로 UI를 꾸미는 css같은 요소가 위젯과 강하게 묶여있습니다. 리액트의 jsx처럼 엘리먼트 따로, css 따로 코드 분리해서 관리하는것이 아닌, 두개가 한데 묶여서 코드 작업을 하는 경우가 많습니다. 

 

엘리먼트+css가 뭉텅이로 묶이면서 다니니 몹시 불편하였습니다.

 

 

 

8. 플러터는 지금도 자주 바뀐다

이게 좀 그지같습니다. 잠깐 맛보기 한건데도 그사이에 deprecated가 되는 위젯들이 있습니다. 자꾸 이러니 뭐 믿고 쓸수가 있어야지요..

of함수 느리니 쓰지말고 다른거 써라 이러더니 자기들은 of 쓰고있고... 어쩌라는건지 모르겠습니다.

 

가이드문서도 중구난방으로 자꾸 바뀌고... 반면 리액트 네이티브는 공식문서에 들어가면 느껴지는게 아주 구수한 50년 전통 맛집같아서 든든합니다.

 

 

 

9. 그래도 플러터가 주목할만한 점. Android와 Fucshia OS 그리고 Matter

플러터와 가장 언급이 많은 내용이 퓨시아os 입니다. 퓨시아는 구글이 준비하는 차세대 os로 플러터가 여기 안에 네이티브로 사용된다는 썰이 있습니다. 회사에서도 다른팀에서 퓨시아 플랫폼 검토하는지 안에 소스코드 잠깐 구경했는데 dart 관련 파일들이 있더군요...

 

이 퓨시아 os가 구글이 칼을 갈고 만들고 있다는데 이게 얼마나 먹힐지 모르겠습니다. 내부적으로 안드로이드 앱 실행을 지원한다는대 멀쩡히 있는 안드로이드를 버릴예정인지...

 

그리고 또하나 주목할만한게 matter입니다. 기본적으로 iot기기에 들어가는 플랫폼으로 추정됩니다.

퓨시아 + 매터 이 조합이 얼마나 시장에 잘먹힐지가 플러터의 운명을 결정지을거라 생각이 드네요.

 

그렇다고 메타도 가만히 놀고만 있지 않고 퓨시아에 맞춰서 플러터ui를 호출하겠지만. 플러터가 퓨시아에서 네이티브 된 시점에서 리액트 네이티브는 아무 장점을 가지지도 못할거 같군요.

 

그나저나 이걸보니 갑자기 크롬os가 생각나는군요 ㅋㅋ...

 

 

 

이상으로 리액트 네이티브와 플러터에 대해 비교해 보았습니다.

 

 

당분간 리액트 네이티브를 공부할거지만.. 퓨시아os가 어떻게 나오나에 따라 플러터로 전향할 마음에 준비도 해야겠습니다.