MVVM 아키텍쳐를 적용하고 프로젝트를 하다보면, ViewModel에서 State 관리에 대해 고민을 많이 한다. 물론 MutableStateFlow나 MutableLiveData의 value를 바꿔주는 함수로 도배를 해도 돌아가기만 하면 문제는 없다. 하지만 화면안에 많은 기능들이 존재하고 각 기능에 대한 상태 값이 많아지면, 단순히 이런 방식은 코드의 가독성을 떨어뜨릴 뿐더러 예상치 못한 오류를 범할 수도 있다.

최근에는 Compose를 주로 사용하는데, 상태 관리가 제대로 되지 않으면 UI가 업데이트 되어야 하는데 업데이트가 되지 않거나 혹은 Recomposition이 빈번이 일어나는 경우도 생긴다.

상태관리의 중요성을 느끼고 코드의 가독성 또한 챙기고자 하던 찰나, MVI 아키텍쳐라는 것을 알게되고 이를 적용해보고자 한다.

MVI 아키텍쳐란?

MVI는 Hannes Dorfmann이 고안해서 만든 **Android UDA(Uni-Direction-Architecture)**로, Model, View, Intent로 구성되어 있다. 여기서 주의할 것은 Model은 MVP나 MVVM에서의 Model과 다르며 Intent는 우리가 아는 컴포넌트 간 통신을 위한 정보가 아니다.

• Model : UI에 반영 될 상태를 의미한다. MVI 아키텍쳐에서는 다른 레이어와의 단방향 데이터 흐름을 보장하기 위해 변경 불가한 데이터이다.
• View : Model에서 상태 값을 가져와 보여지는 UI 그 자체를 말한다. View, Activity, Fragment, Compose가 이에 해당한다.
• Intent : 사용자로부터 받은 입력(ex. 클릭 이벤트)이나 앱내 발생하는 Action을 나타낸다. 모든 Action에 대해 View는 Intent를 수신한다.

데이터는 단방향 흐름을 가져야 하며, View-Intent-Model 순으로 순환한다. 사용자의 액션이 새로운 Intent로 변경되며, 이로부터 새로운 Model을 만들어 View를 갱신한다.

특징 및 장단점

단방향 아키텍쳐의 특징은 다음과 같다.

• View에 영향을 주는 State는 한 방향으로만 수정이 가능하다. - 단방향
• Model은 State를 변화시키고, View는 State를 참조만 한다. - View와 State 분리
• 상태는 불변적인 특징을 가진다.

이런 MVI 아키텍쳐에도 장단점이 있다.

장점

• 여러 이벤트에 대해 한 곳에서 모아서 관리할 수 있다.
• State가 명확하여 버그나 디버깅이 수월하다.

단점