Flutter 상태관리 방식에 대한 생각

아까 1시간 정도 Flutter 관련 문서를 읽었다. 문서에서 무슨 이야기를 하고 있는지 확실히 잘 읽힌다는 느낌이 들더라.

 

https://api.flutter.dev/flutter/widgets/State/setState.html

https://themobilecoder.com/flutter-setstate-the-simplest-state-management-in-flutter/

https://api.flutter.dev/flutter/widgets/ValueListenableBuilder-class.html

 

• When setState() is called on a State object, all descendent widgets rebuild. Therefore, localize the setState() call to the part of the subtree whose UI actually needs to change. Avoid calling setState() high up in the tree if the change is contained to a small part of the tree.

공식문서에 따르면 setState를 사용한다고 모든 위젯을 re-render하는 것은 아니지만, 그럴 가능성이 있으니 조심해서 쓰라고 조언한다. 상태관리의 측면에서 기본적인 방식이 나쁘지는 않지만 뎁스가 많은 상황에서 부모의 상태를 자식에서 처리하기에는 복잡하다. 리액트처럼 ContextAPI가 뎁스의 영향을 받지 않는 구조라면 상관없지만... 하나하나 하위 위젯의 인자로 넣어주기도 애매하다.

 

ViewModel 같은 개념을 사용해서 관리하면 되는 게 아니냐 따진다면, 충분히 가능하긴 한데 새로운 문제가 발생한다. 변수 처리의 이상적인 개념은 사용하는 범위를 명확하게 지정하는 것이다. 예를 들어 ViewModel 내부에 특정 위젯을 레퍼런스라도 해서 참조했다고 해보자. 근데 해당 위젯이 dispose가 된 상황이다. C++로 따지면 댕글링 포인터가 된 상황이다. 나중에 해당 변수를 잘못써서 문제가 생길 가능성이 높다. 특정 값을 바꿨다고 옵저버마냥 스스로 데이터를 반영하지도 않을 것이다(아마 명시적으로 데이터를 바꾸고 setState를 호출하지 않을까 싶다.)

 

이 정도 수준의 고민이 들 정도라면 솔직히 상태관리 라이브러리를 도입하는 것이 맞다.

 

디자인 패턴 같은 것도 마찬가지인게, 마냥 MVVM같은 게 좋다고 무조건적으로 도입하면 안 된다. 상황에 따라서 도입해서 이득을 취할 수 있고 아닐 수도 있다. 화면 2개짜리 Todo앱 만드는데 MVVM까지 도입해서 개발을 해야 한다고 말할 수 있을까? 오히려 복잡한 UI에 상태 관리 로직이 필요한 상황에서 MVVM은 좋은 선택일 것이다.

 

개인적으로 MVVM을 선택하는 이유에는 2가지가 있다. 첫번째로 프레임워크의 기본 상태관리 방식이 해결하지 못하는 문제를 해결하기 때문이다. 두번째로 비즈니스 로직과 UI로직의 분리라는 관점이다. ViewModel은 데이터를 가지고 있으면서 해당 데이터로 처리하는 비즈니스 로직을 처리하고, 나머지는 UI로직(View)로 분리하여 상대적으로 깔끔하게 코드를 관리할 수 있다. 

 

나는 MVVM을 도입한다고 무조건 코드가 깔끔해진다고 믿지는 않는다. 프로젝트의 규모에 따라서 새로운 기술의 도입은 문제 상황을 더욱 복잡하게 만들 가능성도 있다. 따라서 MVVM 패턴을 도입하여 개발을 하더라도 모든 부분에 적용하진 않는 편이다. 

 

개인적으로 Provider라이브러리가 MVVM패턴을 기반으로 하고 있다고 생각한다. 그 이유는 ViewModel 역할을 하는 ChangeNotifier가 존재하고 View에서 Selector, Consumer같은 위젯을 사용해서 Observer 역할을 수행하기 떄문이다. 특정한 값이 바뀔 때, 특정한 뷰의 위치만 선별하여 다시 그리는 것이 가능하다. 이는 Flutter의 기본 상태관리 방식 중에 하나인 ValueListenableBuilder와 유사하다(사실상 뭐... ViewModel 개념만 없지 사용방식은 똑같다) 

 

새로운 기술/패턴을 도입하는 과정에는 '왜 A라는 기술을 선택하는지'에 대한 명확한 이유가 있어야 한다. 예를 들어 내가 리액트 개발에서 차크라UI를 선호하는 이유에는 몇 가지가 있다. 타 UI컴포넌트 라이브러리와 비교했을 때 파일 사이즈가 적은 편이라 가벼운 것이 마음에 든다. 또한 러닝커브가 매우 낮은 편이라 쉽게 배울 수 있다. 내 입장에서는 이전에 사용해본 경험이 있어 프로젝트 진행에 능숙한 점도 특징이다. 따라서 나는 차크라UI를 사용하는 것을 선호한다. 

 

만약에 회사에서 사용한다면, 나와 같이 개발하는 인력이 어떤 기술 스택을 사용해본 경험이 있는지 생각할 것이다. 새로운 기술을 도입할 때 들어가는 러닝커브가 높은지, 낮은지 생각해보고 원하는 처리를 해당 기술의 도입으로 해결할 수 있는지 판단하겠지. 사실 어지간한 부분에서 따봉을 많이 받은 라이브러리들은 원하는 처리를 다 해줄 수 있다고 생각한다. 그러나 적어도 그 기술을 선택한 이유를 2~3가지 정도는 이야기할 수 있어야 한다고 믿는다(모든 기술말고 주요 기술에 대해서)

 

=> 근데 보통 잘하는 개발자는 이런 토론? 같은 것을 하는데, 실력이 부족한 사람들은 이런 걸 잘 안 하는 편이다. 나도 예전에는 이런 관점에 대한 이해가 없었는데, 어느 순간부터 디테일을 따지기 시작하더라... 아마 계속 공부하다보면 더욱 깊숙한 부분까지 생각하게 되지 않을까 싶다.