react native가 구조 개선을 상당히 했네요.

개인적으로 RN과 Flutter 둘 다 사용한 입장에서 Flutter를 선호하게된 이유는 대충짜도 적당히 빠른 앱을 만든다는 점이였습니다.

사실 그것을 제외하고는 Flutter는 어떤 장점도 없다고 생각합니다. 인력수급,배포,기술성숙도,코드퀄리티,유지보수,구글이만든 기술

이라는 점, 러닝커브 어떤것을 다 따져도요. 외주 회사들 입장에서는 결국 레퍼런스가 중요하기 때문에 Flutter를 최근에 많이 선택합

니다. 외주 회사들은 애초에 우수한 인력으로 고 퀄리티 유지 보수 가능한 앱을 만드는 목적이 아니기 때문이죠.

0-1년차들이 만들어도 느리지 않는 것처럼 만들 수 있고 결국 단가를 낮춰서 시장에서 생존가능한 기술인거죠.

그래서 최근 많은 업체들이 flutter로 앱이 만들었고 인력수급이 어렵다 보니 채용공고도 많습니다.

저 같은 경우는 admin + web service + mobile service + nodejs 전부 monorepo로 묶어서 js 하나로만 개발하기 때문에 외

주업체들이 저랑 단가 경쟁을 붙어서는 저를 이길수가 없습니다.

그럼에도 저도 Flutter를 사용합니다. 젊은 대표들은 곧 죽어도 Flutter 외치는 분들도 있고 혹은 Flutter로 만들어진 부드러운 앱들을

보고와서 똑같이 해달라고 많이합니다. 토스 쿠팡도 RN으로 만들어졌다고 하면 수긍하는 분들도 있는데, 아닌분들은 그냥 Flutter

로 만들어드립니다. 근데 코드퀄리티 보장이 안 됩니다. 업체들은 유지보수 해달라고 하는데, 저 입장에서는 엄청 피곤한거죠. 저도 모

바일 개발 10년을 했는데, Flutter는 만들긴 쉬워도 유지보수는 쉽지 않거든요. 유지보수를 해도 dart라. 어디 재활용 가능한 로직이

없습니다. 스프링이 정착되기전 질풍노도의 java백엔드 시절을 보는 느낌이라고 할까요.-_- 어쩔수 없이 만들어주다보니 저 입장에

서 새로운 외주를 받는 것 대비 돈도 안되고 피곤하거든요.

그러다 이번년도에 RN 문서를 한 번 읽었는데, 드디어 bridge 형태의 통신구조를 개선했더군요.-_- 어휴..

내용만봐서는 장단은 있겠으나 그 방식이 나이스하다는 생각이 들더군요.

js를 native code로 변환시키는 기술(codegen) 그 native code의 interface를 하는 object를 c++로 만들었다는 점(JSI)

결국 interface가 c++로 만들어 졌기 때문에 앞으로 electron영역이나 다른 플랫폼으로 확장가능하고요.

그외에 static hermes? 그건 대놓고 flutter 저격이긴 하더군요. 물론 언제 상용화까지 갈지는 모르겠지만 결국 되겠죠.

확실히 meta는 2023년도에 스레드를 RN으로 출시하면서 이미 RN에 대한 애착을 들어내긴했죠.

메타스토어 인스타그램 스레드 모두 RN 기반이니 메타 입장에서는 해당 기술을 버리는건 코어를 도려내는 작업이니깐요.

2024년도에 default로 적용된다고 하는데 기대가 됩니다.