이 글은 페이스북 [구글 Flutter 한국 사용자 그룹 - https://www.facebook.com/groups/flutterkorea] 에 올라온 글에 제 생각을 추가하기 위해서 작성되었습니다.
책의 모든 내용을 저자 직강으로 진행한 강의는 ssamz.com 에서 들으실 수 있습니다.
안녕하세요.
저는 플러터 강의(https://www.ssamz.com) 를 하고 집필(Do it! 깡샘의 플러터&다트 프로그래밍) 및 개발을 하는 강성윤입니다. 평소 관심있어 하는 주제의 좋은 글(https://engineering.linecorp.com/ko/blog/flutter-architecture-getx-bloc-provider?fbclid=IwAR1PbF9GHnum6WruP9SEYd2gdCNScjxzo-hTTp3Nlqv0o4K341NVbL8S4nU - 윤기영) 이 올라와 제 생각을 첨언하기 위해서 글을 씁니다.
먼저 윤기영님의 글에서 각 프레임워크에 대한 비교를 그림 및 코드까지 추가해서 잘 설명하고 있음으로 관심있으신 분들은 위의 글을 먼저 읽어보시면 좋을 것 같습니다.
저는 윤기영님이 설명하신 내용은 제외하고(사실 너무 잘 설명되어 있어서 그보다 더 잘 비교할 자신이 없어서 ㅠ) 제가 가진 생각만 몇 자 적어봅니다.
상태관리 프레임워크 어떤 것을 써야 하는가?
강의를 하면서 가장 많이 받는 질문중에 하나이기도 하고, 반대로 제가 학습자분들께 회사에서 어떤 것을 쓰시는지? 이유는 무엇인지를 가장 많이 물어보는 것 중에 하나이기도 합니다.
또한 책을 집필하면서 3개의 프레임워크를 모두 소개는 했지만 논란의 소지가 있어서 어떤 것이 더 좋아 보이는지 평할 수 없었던 주제이기도 합니다.
Provider 와 GetX 가 경쟁을 하고 있고 Bloc 이 약간 뒤처지는 느낌.
pub.dev 의 인기도에도 그렇고, 만나본 개발자들의 답도 그렇고 Provider 와 GetX를 많이 사용하고 있는 것 같습니다. 특히 GetX 가 가장 늦게 알려졌음에도 불구하고 치고 올라오는 속도가 좋은 것 같습니다. Bloc 은 GetX, Provider 에 비해서는 덜 사용되는 것 같고요.
Bloc 은 왜 인기가 없는가?
Bloc은 확실히 호불호가 있는 프레임워크입니다. 3개의 프레임워크중 가장 런닝커브가 길죠. 그러다 보니 수업을 통해 처음 접하시는 분들은 GetX, Provider 에 비해 난해해 합니다. 이 점이 Bloc 을 배제하게 되는 이유 중 큰 부분을 차지합니다.
그런데 다른 분야의 프로그래밍(웹 프런트)을 통해 상태 관리개념을 이미 접한 개발자들은 Bloc 을 상당히 쉽게 생각하며 Bloc 에 대한 호감도가 좋습니다. 사실 Bloc 은 자바스크립트의 Redux, Vuex 등과 뿌리가 동일하다 보니 이를 통해 이미 상태관리 아키텍처를 아는 개발자에게는 학습할 것도 없는 것이 되지요.
라이브러리로 볼 것인가? 프레임워크로 볼 것인가?
뭐라 불러도 상관 없겠지만 분명 라이브러리를 바라보는 개발자의 기대치와 프레임워크를 바라보는 개발자의 기대치에는 차이가 있을 것 같습니다.
우리가 자바스크립트에서 jQuery 를 라이브러리로 봤지, 프레임워크라고 하지는 않았습니다. 또한 React.js, Vue.js 등은 아무리 많은 기법의 API 를 제공한다고 하더라도 그 근간은 프레임워크입니다.
라이브러리에서 우리가 기대하는 중요한 것은 라이브러리에서 제공하는 유용한 API 를 이용해 개발 생산성을 높이는 것 아닐까 싶습니다. 반대로 프레임워크에서 우리가 기대하는 중요한 것은 프레임워크에서 제공하는 구조대로 우리 앱이 구성되어 유지보수성을 높이는 것 아닐까 싶습니다.
상태관리란 프레임워크이다.
앱, 특히 프런트(웹, 모바일)에서 상태관리를 체계적으로 해야 한다는 사상은 이미 논란의 여지가 없는 모두 받아들이는 사상인듯 합니다. 앱의 상태를 체계적 관리하기 위해서 여러가지 사상 및 구조가 고민되어 왔으며 그로인해 reduce, unidirectional data flow, pure function 등의 개념이 접목된 지금의 구조가 완성되지 않았나 싶습니다.
결국 앱을 개발하면서 상태관리를 적용하겠다는 의미는 앱의 상태를 관리하기 위한 검증된 구조를 적용하겠다는 것이 핵심이지, 상태관리를 위한 API 의 도움을 받겠다는 것이 핵심은 아닌 듯 합니다.
Bloc? Provider? GetX?
개인적인 생각입니다. 개인적인 호불호이기도 하고요.
Bloc 의 아키텍처는 모바일 개발자들에게는 낯설어 보일지 모르겠지만 이미 많은 곳에서 사용하는 검증된 아키텍처이지요. Bloc 을 이용하는 것이 Provider, GetX 로 작성하는 것보다 코드 양이 더 많이 나오고 구성요소도 더 많아지지만 우리가 프레임워크를 사용하는 것이 코드 줄이자고 사용하는 것이 아님으로 이런 측면에서 Bloc 을 배제하는 것은 모순이 아닐까 싶습니다. 그리고 앱이 복잡하면 복잡할수록 Bloc 처럼 상태를 아예 분리해서 개발하는 방법이 더 유지보수성이 좋아보이기도 하고요.
Provider 는 앱 전역에 분리되어 관리되어야 하는 상태가 없거나 작은 경우 유용하다고 생각합니다. 단순히 상태관리를 일종의 라이브러리 개념으로 접근해서 위젯 트리구조내에서 상태 데이터를 하위 위젯에서 쉽게 이용하기는 것이 목적이라면 좋은 프레임워크라고 생각합니다.
음. GetX. 개발 생산성은 최고죠. 그런데 느낌이 Vue.js 와 React.js 의 느낌이랄까.. 프레임워크로 인정하기는 싫고(개인 생각입니다.) 상태관리를 위한 쉬운 라이브러리가 있었으면 좋겠다면 최선의 선택일 수 있습니다.
논란의 여지가 있는 글을 쓴 것 같습니다. 물론 아키텍처에는 정답이 없다는 것으로 글을 봐주시지 않을까 싶습니다. 감사합니다.
글쓴이의 책/인강
https://www.ssamz.com/lecture_view.php?LectureStep1=51&LectureSeq=34
http://www.yes24.com/Product/Goods/117206541
책의 모든 내용을 저자 직강으로 진행한 강의는 ssamz.com 에서 들으실 수 있습니다.
'flutter' 카테고리의 다른 글
플러터 - FCM (0) | 2023.03.13 |
---|---|
플러터 - image_picker (0) | 2023.03.13 |
플러터 - BasicMessageChannel (0) | 2023.03.13 |
플러터 - GetX로 상태 관리하기 (0) | 2023.03.13 |
플러터 - Bloc Cubit (0) | 2023.03.13 |