개요

좀 더 직관적이고 Testable한 코드를 작성하기 위해 MVVM과 상태 패턴을 같이 사용하면서 상태를 관리하는 코드를 작성하다보니 관리하거나 작성하기가 어렵다는 생각이 들었다 그래서 단방향 Flow를 가지고 여러사람이 작성하더라도 일관성 있게 유지 할 수 있는 아키텍쳐가 존재할까 라는 생각에 검색해보다가 상태를 관리하는 아키텍쳐인 MVI에 대해 알게 되어서 정리 차원해서 글을 작성하게 되었다.

MVI를 왜 사용 해야할까?

Android 앱을 개발하면서 발생하는 Side Effect들은 대부분 앱의 상태가 의도한 대로 동작하지 않았기 때문에 발생한다. 이러한 문제는 엄청 간단한 앱이면 쉽게 찾아내서 고칠 수 있지만 엄청 거대한 앱같은경우에는 트래킹 하기 어렵다. 또한 다른사람이 작성한 코드는 사람마다 스타일이 다르기 때문에 이해하기도 어렵고 그 코드를 내가 고쳤을 때 발생하는 시간과 그 코드를 완벽하게 이해하지 못해 사이드이팩트가 발생 할 수 있다. 이러한 복잡한 흐름과 충돌을 막기 위해서 고안한 아키텍쳐가 MVI 아키텍쳐이다. 단방향 Flow로 구현되어있고 상태에 대한 불변성을 가지고 있기 때문에 이를 통해 앱의 상태를 트래킹하기가 쉽다. 또한 불변성으로 인해 상태의 충돌을 막을 수 있다.

MVI는 어떻게 구성되어 있을까?

일단 일반적인 사람 두명에서 대화하는 방식을 보자 아래와 같이 각자 듣고 들은것에 대해 반응한다.

만약 두사람중에 한사람을 컴퓨터로 바꾸려면 어떻게 바꿔야 할까? 사람과 컴퓨터가 상호작용 하기 위해서는 마우스, 마이크, 키보드, 스피커 , 모니터와 같은 Interface가 필요하다. 말하는 것 대신 마이크로 말하거나 키보드로 입력하거나 마우스로 클릭을 해야한다. 이때 컴퓨터는 이런 입력을 받아드리고 어떤 작업을 하고 Output으로 내보낼지 입력을 분석하고 모니터에 출력을 한다. 그리고 모니터에 출력된 정보를 보고 사람은 다시 어떤 순환작업을 할지 결정한다.

이 그림을 프로그래밍 관점에서 보려면 함수가 필요하다. 그래서 우리는 Input Output을 함수로 바꿔볼 수 있다.

각각의 함수의 결과가 다음 함수의 입력이 되는 형태가 되는데 이러한 형태는 단방향으로 이동된다. 그렇기 때문에 다른방향으로 갈 수 없다.

User의 결과는 Intent의 입력으로 전달 된다. 원안에 있는 모든 함수가 동일한 규칙을 가지고 있다.

그리고 Model의 유일한 결과인 State가 View의 입력으로 전달된다. 그리고 그 View의 출력은 User를 호출하는데 사용되며 이 순환은 아래와 같이 계속된다.

intent(user(view(model(intent(user())))))

하지만 User는 코딩의 대상이 아니기 때문에 최종적으로는 이렇게 구성이 된다.

view(model(intent()))

결과적으로 3가지 함수가 MVI의 구성요소를 만들게 된다.

• Model
• View
• Intent

Intent

여기서 이야기하는 Intent는 Android Framework에 있는 Intent가 아니다. 네이밍 적으로 햇갈릴 수 있겠지만 확실히 정의하고 가겠다.

여기서 이야기하는 Intent는 사용자의 Action 예를들어 어떠한 글을 Posting하는 행위 혹은 화면에 출력을 하고 싶은 데이터를 가져오는 행위 등등을 뜻한다.

그래서 우리는 Intent 파일을 통해 여러가지 작업에 대한 사이클을 알 수 있다. 그렇기 때문에 앱이 어떤식으로 동작하는지 쉽게 파악 할 수 있다.

Side Effects

MVI에서 말하는 Side Effects는 어떠한 Api 호출, DB 작업(Intent)을 하거나 했을때 보통 Model에 입력값으로 처리가 되는데 이때 Model에 입력값으로 처리가 되면서 동시에 Intent는 다른 구성요소에 사이드 이펙트를 실행하도록 한다. 이 사이드 이펙트의 결과는 아무것도 없을 수도 있고 새로운 Intent가 될 수도 있다. 이는 또 다른 사이드 이펙트를 일으키거나 Model의 입력값이 될 수 있다. 이러한 부분을 Side Effects라고 한다.