MVVM에 대한 고찰

 

 

 

UIKit에서 흔히 Cocoa MVC 패턴을 쉽게 볼 수 있다.

그러나, UIViewController가 뷰 생성, 레이아웃, 이벤트 처리, 액션 등록, 비즈니스 로직 등등 많은 걸 담당하다 보면

눈 깜빡하는 사이에 Massive ViewController가 됐음을 알아챌 수 있다.

 

이는 테스트를 어디서부터 해야할지 어려움도 있고, 어떻게 유지보수를 해야 할지 막막하기도 하다.

 

이러한 한계를 극복하기 위해

MVVM을 비롯한 다양한 아키텍처가 등장했고,

 

주변에서 많이 채택하는 것을 볼 수 있고, 물론 나 또한

MVVM을 프로젝트에 채택하면서 장단점을 체감할 수 있었다.

 

 

---

 

 

 

MVVM를 도입하면서 느낀 점은

 

뷰는 UI 렌더링과 사용자 상호작용을 담당하고,

뷰모델은 화면에 표시할 데이터를 어떻게 가공할지 집중하며,

모델은 순수한 데이터 관리 및 비즈니스 로직을 담당하여서

 

명확한 책임이 분리가 되기 때문에 MVC보다 유지보수가 한결 수월했다.

 

그러나 뷰에 보여질 상태가 많거나 기능이 많아지면

필연적으로 뷰모델도 무거워지고, 

각종 에러처리, 리스트 업데이트, 토글 상태, 네비게이션 흐름 등등..

한 곳에서 관리하다 보니 유지보수의 어려움이 있었다.

 

---

 

정답이 없다보니 항상 고민이 되는 것 같다.

 

물론 MVVM는 개발속도가 빠르고, 

코드를 보기만 해도 화면 흐름이 머릿속에 바로 그려져 팀원들간의 의사소통이 잘 되는 것 또한

장점처럼 느껴진다.

 

그리고 단일책임원칙을 준수하면서 객체간에 의존성을 느슨하게 만들어

테스트 가능한 구조를 갖추기도 수월하다.

 

그러나 아무리 이렇게 한다해도 결국 화면이 복잡해지면,

뷰모델이 담아야 할 상태와 로직이 끝도 없이 필연적으로 늘어나게 된다.

 

그렇다고 기능별이나 컴포넌트 별로 뷰모델을 나눌까 싶기도 한데

이는 파일이 늘어나기 때문에

나 뿐만 아니라 팀원에게 탐색하는데 어려움이 예상이 되고,

파일 구조를 이해하는 데 더 많은 시간이 할애될 것 같기 때문에 망설임도 있다.

 

지금 현재는 화면 하나에 뷰모델 하나를 기본 원칙으로 삼고 있고,

정말 필요할 때만 1~2개의 추가 뷰모델을 만드는 방식으로 MVVM패턴을 적용하고 있다.

 

---

 

정리하면, 결국 정답이 없기 때문에

하나의 패턴만이 정답이라고 스스로 생각해서, 비슷한 고민에 갇히게 되는 것 같다.

모든 아키텍처 패턴의 장단점을 인정하고 유연한 생각을 지니어야 할 것 같다.

 

그래서 UI가 복잡해질수록 ViewModel이 무거워지는 문제를 해결하기 위해

상태와 액션을 분리한 단방향 데이터 흐름이 필요하다고 판단했고,

 

다음에는 이 흐름을 핵심으로 하는 MVI를 학습할 계획이다.