ABOUT ME

-

Today
-
Yesterday
-
Total
-
  • 리액트 네이티브 - 훅의 강력함, 그리고 성능
    앱개발이야기 2020. 7. 23. 18:46

    최근에 재미있게 만들고 있는 어플이 하나 있습니다. 이번에는 소셜기능이 포함되어 있는지라, 백엔드와 프런트엔드를 한가지 언어로 할 수 있는 리액트 네이티브로 만들기로 하고 시작을 했습니다. 백엔드는 서버리스 (Firebase사용)로 만들고 있는데, 워낙 파이어베이스가 다 해줘서 제가 할게 별로 없더군요. Functions 로 API 개발하는게 예전에 비하면 너무나 쉬워서 진입장벽도 매우 낮아졌겠다 싶습니다. 요즘 아마존에도 백엔드 개발하는 사람들이 TCP의 three-way-handshaking이나 소켓 바인딩 개념을 잘 모르는거 보면... 예전에는 아얘 불가능 했었는데 말이죠. 그동안의 변화를 비추어 보면 앞으로 더 얼마나 변할지 어느정도 가늠이 되죠.

    이야기가 초반부터 다른데로 샜네요. 사실 회사에서 리액트 네이티브를 3년째 쓰고 있지만, iOS와 Android용 어플이 아니라 TV나 셋탑박스 사용자들을 위한 아마존 프라임비디오 어플을 개발하고 있다 보니, 개발 환경, 빌드환경이 고도화 되어 있고 매우 복잡합니다. 게다가 리액트 네이티브를 가지고 내 마음대로 뭔가를 만들어 본 경험은 3년 전 이후로는 처음이었습니다. 그 당시 훅(Hook)이 없을 때라서 개발하는데 그다지 수월하다고 느껴지지가 않았었고, 회사에서도 아직 React 16.3에 발이 묶여 있는 지라, 훅을 사용하지 못하고 있었습니다.

    그래서 이번에는 내맘대로 만드는 즐거움을 위해서, 플러터를 잠시 미뤄두고 RN으로 개발을 시작했습니다. 3년전과는 너무나 다르게... 훅을 사용하니 개발 효율이 거짓말 조금 보태서 5배 정도는 되는것 같았습니다. 길게 말하자면 입아프지만 저는 무조건 타입스크립트를 추구하기 때문에, 비교적 속도가 더딜 수 밖에 없음에도 불구하고, 그 쾌적함은 이루 말로 표현 하기가 어렵네요.

    특히 Redux 를 쓰는데 보일러플레이트 코드가 너무 많이 들어가니 개인 프로젝트에서는 절대 쓰지 말아야지 하고 다짐을 했었거든요. 실제로 전에는 MobX를 사용 해 봤었는데, 개발 효율이 엄청나게 향상됨을 경험 했기 때문에 다시 Redux 를 쓸 생각을 해 본 적이 없었습니다. 그런데 척추처럼 어플 전체를 꽉 잡아주는 Redux의 장점을 포기할 수 가없고, 타입스크립트와 함께 사용하면 초반 매몰비용 이후에는 개발 가속도가 상당히 좋기 때문에 훅이랑 같이 한번 써보자 하고 시작을 해 보았습니다.

    리둑스 사용에 필요한 보일러플레이트 코드들 - 액션, 리듀서, Thunk, 셀렉터 - 등을 짜는 과정에서는 어느정도 손가락 아픈 노가다를 피하기는 어려웠습니다. 그나마도 Redux Toolkit 으로 훨씬 편해진건 사실이지만 타입스크립트를 함께 쓸 때 타입 인퍼런스가 자연스럽게 되도록 셀렉터를 짜두는것은 여전히 고생스러운 일이긴 합니다. 그런데 놀라운건, 그 이후에 벌어졌습니다. 리둑스 훅들 - useSelector, useDispatch 등 - 을 사용하니까 기존에 리둑스 훅 없이 개발하는 것 보다 거짓말 많이 보태서 10배 정도는 차이가 나는 것 같더군요. 게다가 타입 인퍼런스가 생각했던 것 보다 훨씬 더 잘 되어서 놀랐습니다.

    환경 설정에 대해서 느낀점은, Expo를 사용하지 않으면 발품을 조금 팔아야 하기는 하지만 여전히 초보자라도 커맨드만 순서대로 입력하면 개발/빌드 환경을 셋팅할 수 있을 정도로 쉽다는 점이 매우 고무적이었습니다. 3년전에도 쉽기는 했는데 종종 부드럽게 진행되지 않는 경우가 많고, 그 하나하나를 제대로 해결하기위해 붇들고 씨름하다보면 꽤나 만만치 않았던 것으로 기억하거든요. 그런데 지금은 뭔가 실패하는 과정이 생기면 반가울 정도로 모든것이 매우 부드럽게 돌아가더군요. 그렇게 리액트 네이티브로 어플 개발을 시작해서 2일 정도 하니까 디자인은 없지만 기본 기능을 하는 소셜앱을 만들 수 있었습니다.

    그런데 말입니다.. 매우 당연할것이라고 생각했던 것에 문제가 발생했습니다. 성능입니다. 저는 "당연히" 매우 간단한 어플에서 성능 차이를 느낄거라고는 전혀 생각하지 못했습니다. 텍스트만 있는 스크롤뷰를 스크롤하거나, BottomNavigation을 눌러 이동하는 등의 간단한 사용자 인터랙션을 하는데도 아주 미세하지만 딜레이가 느껴졌습니다. 플러터로 개발했던 어플과 확연히 다른 뭔가 조금 답답한 느낌이 있더군요. Debug 빌드라서 그런가보다 하고는 prod 빌드로 다시 올려 봤는데, 그 미묘한 답답함은 그대로더라구요. 구태여 비유하자면 얼굴이 보들보들할때 만지는것과 얼굴에 기름이 꼈을때 만지는것 같은 차이랄까요.

    제가 무언가를 잘못 했을 가능성도 있겠지만, 도무지 어떤 이유인지 가늠이 되지 않더군요. UI 프레임워크로 react-native-papar 를 사용했는데, 이게 주 원인인지는 모르겠습니다. 아니면 어쩌면 플러터가 그만큼 반응속도가 빠른것일지도 모르겠습니다. 제가 성능에 상당히 민감한 편인지는 모르겠으나, 폰에 네이티브 어플, 플러터 어플, 리액트 네이티브 어플을 깔아놓고 조금만 써보면 그 차이가 느껴집니다.

    그래서... 다시 플러터로 만들기로 결정 했습니다. 삽질이 되지 않기를 바라며.. ^^;

     

    플러터(Flutter)의 장점 (2) - 성능편

    지난 4개월 전에 "플러터의 장점"에 대해서 적은 글이 생각보다 많이 조회된 것을 보고 플러터의 인기가 올라가고 있음을 실감한다. 당시에 2달밖에 사용하지 않았기 때문에, 좀더 민감할 수 있��

    www.steeme.com

     

    댓글 0

Designed by Tistory.