Flutter State Management 라이브러리 꼭 필요한가?
들어가며
오늘은 Flutter의 State Management(이하 상태관리)에 대한 내용을 적어보고자 한다. 일반적으로 Flutter 개발을 시작하는 분들은 개발에 적합한 상태관리 라이브러리를 생각하면서 검색을 시작할 것으로 예상된다 (ScopeModel, Bloc, GetX, Provider etc.. ). 다소 자극적인 제목으로 시작하게 되었지만 상태관리에 대한 몇 가지 의견을 정리해 보았다.
상태관리에 대한 정해진 답 즉, 정답은 없다.
상태관리에 대한 내용은 다소 민감한 주제가 될 수 도있다. 그래서 많은 개발자 분들은 아래에 대한 내용에 다소 답변을 주저할 수 도 있을 것이라고 본다.
“Flutter를 배우는 초심자 입니다. 상태관리 패키지 추천해주세요”
“어떤 상태관리 라이브러리를 써야하나요? ”
“왜 GetX는 사용안 하나요?” 혹은 “GetX가 좋은거 같은데 왜 다른 상태관리 라이브러리를 사용하나요? 등등
“Provider 꼭 써야하나요?”
소제목에도 적어 놓았지만 상태관리 라이브러리에 대한 정답은 정해져 있지않다. 우리는 개발하는 결과물 또는 프로젝트에 대한 적합한 상태관리를 처리하고, 필요에 의해 wrapping된 사용하기 편리한 라이브러리를 사용할 뿐이다. 따라서, 우리는 현존하는 상태관리 라이브러리에 대한 각 특징을 알아가며 분석하고 적절하게 선택해야 한다.
- 프로젝트의 규모 & 개발기간
- 협업하는 개발자의 수
- 의존성 충돌 여부
- 유지보수성
4가지를 적절히 고려해 가면서 선정해보는건 어떨까? 만약, ‘어떤 패키지를 적용했는데 결과물이 좋지않다’ 라면 Extra work로서 다른 상태관리 패키지로 migration 작업을 진행 해보는것도 개인적으로 좋은 개선 방법이라 생각한다.
상태관리
들어가기 앞서, Flutter에서의 상태가 무엇이고 상태관리는 무엇인지에 대한 내용은 생략하였다.
React 의 Context 가 곧 Flutter의 InheritedWidget과 동일하며 Flutter의 InheritedWidget이 React의 Context보다 다소 복잡하고 어려운 측면이 있다. ScopeModel, Provider 등 대부분의 상태관리 패키지들은 InheritedWidget를 wrapping하고 있으며, 우리가 원하는 결과물을 도출하기 까지의 개발을 좀 더 쉽게 돕는다. (개발 시간을 단축시켜 준다는 것도 어느정도 맞는거 같다. )
Flutter에서 우리가 가장 쉽게 접근할 수 있는 low-level의 상태관리인 setState를 호출하게 되면 전체 위젯을 다시 build하기에 cost가 다소 높아질 수 있다. 이를 개선 시키기 위해 InheritedWidget을 사용하면 State를 공유하는 위젯만 build될 수 있기에 Cost 절감이 가능하다.
하지만, InheritedWidget 또한 러닝커브가 다소 높다. 규모가 커지면 스파케티 코드 처럼 꼬여버린다. 따라서 이런 불편함을 해소하고자 ScopeModel, BLoC, Provider 등등의 패키지들이 개발되어 사용자가보다 쉽게 상태관리를 사용할 수 있게 되었다.
BLoC은 State를 잘 쪼개고 명세하기 좋은 패턴임은 분명하다. 하지만 중요한건 러닝 커브가 높다. 개발자가 개발 중간에 투입되었을 때의 F/U 시간 또한 증가할 가능성이 있다.
GetX에 대해 의견을 조금 정리해보 자면, GetX의 경우 상태관리에 대해 편리하게 만들어져있다고 생각한다. 인기도 많고 국내, 해외 모두 실무에 많이 사용하는 것 같다. 하지만 개인적으로 다소 사용에는 부정적이다. 이게 라우터 라이브러리 인지, 국제화(i18n) 라이브러리인지, 상태관리 라이브러리인지 경계가 모호하다. 너무 범위(규모)가 크고 의존성 충돌이 생각보다 많았다.
9천개 이상의 like를 받고 7천개 이상의 star를 받은 패키지가 왜 아직 Flutter Favorite에는 선정되지 못했을까?
Because The flutter and dart team know that GetX has serious problems, bugs, bad code, without unit and widget testing. Also almost the all users who loves GetX don’t understand the concept of Inherited widgets and state management. If you domain the inherited widgets and the state management with Provider or Bloc and you know the importance of the context in the widget tree you will never use Getx
여전히 GetX와 Provider 간 논쟁을 펼치는 곳이 많은 것 같다. 하지만 무엇을 선택할지 결정하는 것은 언제나 개인의 몫이자 자유이다.
단순하게 “상태관리는 이거 사용하세요~저거 사용하세요” 딱 짚어서 확정시키는 행위는 위험하다고 본다. 그 외 Flutter 상태관리 라이브러리에 대해서는 아래의 링크를 참고하면 좋다.
State Management 라이브러리 꼭 필요한가?
소규모의 앱을 개발한다면 low-level부터 시작하는 것도 좋다고 본다. 여기서 low-level은 setState와 InheritedWidget을 포함한다. 소규모의 범위를 특정 지을 수 없는 것은 개인마다 가지는 규모의 척도에 차이가 있을 수 있다. 가끔 규모에 비에 굳이 싶을 정도로 과하게 적용된 상태관리 코드들이 많이 보인다.
- 불편함을 해결하기 위해 자신만의 상태관리 패키지를 만들어 보는 것은 어떠한가?
- setState → InheritedWidget → Other State Management Packages 한 단계식 migrate 과정도 중요하지 않을까? 물론 시간이 많이 투자되는 작업임으로 이는 시간이 날 때 진행해 보는 것도 좋다고 본다. (이런 작업을 거치다 보면 쉽게 사용할 수 있는 현존 상태관리 패키지에 대해 다소 감사함을 느끼게 된다. )
결론적으로, To-Do 앱을 만든다거나 단순 카운트 앱을 만들어보는 작업을 한다면 처음부터 상태관리 라이브러리를 굳이 적용할 필요는 없다고 본다.
마치며
다소 자극적인 제목을 시작하여 Flutter 상태관리에 대한 생각을 정리해보았다. 글을 마치며 언제가 될지 확정지을 수는 없지만 조만간 Provider는 Deprecated 될 수도 있을 거 같다.
