MVI vs Android App Architecture

Compose를 사용하면서 MVI가 Compose와 아주 찰떡이라는 이야기를 듣고 MVI를 학습하면서 사용해봤다. 그렇다면 구글 권장 아키텍쳐와 MVI의 차이가 무엇일까? 비교해보자

 

MVI 란?

MVI (Model - View - Intent) 는 UI 상태를 단일 상태(SSOT, Single Source of Truth) 로 관리하고,

UI 이벤트를 “Intent → Reducer(copy) → State” 흐름으로 처리하는 아키텍처 패턴입니다.

 

Intent	사용자가 UI에서 수행하는 액션 (ex. 버튼 클릭, 텍스트 입력 등)
Reducer	이전 상태(State)를 기반으로 copy() 를 사용해 새로운 상태를 만드는 순수 함수
State	UI를 구성하는 불변 데이터 모델

 

 MVI가 강조하는 철학

1. Immutable State즉, 기존 객체를 절대 직접 수정하지 않습니다.
2. 상태는 항상 data class 로 정의하고, 변경할 때는 copy() 로 새 객체를 만듭니다.
3. 단방향 데이터 흐름 (Unidirectional Flow)입니다

 

왜 Compose와 잘 맞는가?

Compose는 상태 기반으로 UI를 재구성하는 선언형 UI 입니다.

MVI도 상태 중심이고, 변경이 일어나면 UI를 다시 그립니다.

그래서 방향성은 동일합니다.

상태가 바뀌면 → UI가 자동으로 다시 그려진다.

 

이게 Compose와 MVI가 찰떡이라는 말의 이유입니다.

 

그렇다면, 왜 구글은 MVI를 공식 채택하지 않았을까?

제가 생각하는 결론은 이렇습니다.

구글은 MVI라는 이름을 정식으로 채택하지 않았을 뿐,

실제로 제공하고 있는 아키텍처 가이드와 샘플 코드를 보면

• 단방향 데이터 흐름(UDF)
• 단일 상태(State) 기반 구성
• 상태에 의해 UI가 그려지는 선언형 모델

이라는 MVI의 핵심 개념을 그대로 사용하고 있습니다.

하지만 구글이 MVI/MVVM이라는 이름을 강조하지 않는 이유는

안드로이드만의 특성에 맞게끔 재정의 했기 때문이라고 생각합니다.

실제로 구글은 문서에서 MVVM이라는 용어조차 사용하지 않습니다.

그 대신 아래와 같은 개념만 명확히 제시합니다.

• ViewModel이 UI 상태를 소유하고,
• UI는 그 상태를 구독하며,
• 이벤트는 ViewModel로 전달된다.

결론

패턴 이름(MVI, MVVM)에 얽매이지 않고, “UI State → ViewModel → Data” 로 흐르는 명확한 데이터 방향성과

단일 상태 관리 가 가장 중요해 보입니다.