[Android] 안드로이드 아키텍처 패턴(MVC, MVP, MVVM, MVI) 알아보기
2025년 1월 15일에 작성되었던 글입니다.
이 글에서는 안드로이드 앱 개발 시 사용되는 네 가지 아키텍처 패턴(MVC, MVP, MVVM, MVI)을 살펴보고, 각 패턴의 동작 원리와 장단점을 알아봤습니다.
0. 안드로이드 아키텍처 패턴
아키텍처 패턴
특정 Context에서 반복적으로 발생하는 설계 이슈에 대해 검증된 해결책(재사용 가능한 솔루션)을 제공합니다.
안드로이드 개발에서는 크게 MVC, MVP, MVVM, MVI 네 가지 패턴이 활용되며, 모두 Model(M)과 View(V)를 공통으로 가집니다.
- Model : 앱의 데이터를 보관하며, 데이터 관련된 실질적인 Business Logic를 수행합니다.
- View : 사용자에게 UI를 보여주는 Presentation Logic를 수행합니다.
아키텍처의 목적
Presentation Logic과 Business Logic을 구현함에 있어서 데이터와 UI는 필수적이기 때문에, M과 V 사이에는 의존성이 생길 수밖에 없습니다. 이러한 로직들이 커지고 복잡해짐에 따라 의존성이 더 강해져, 앱의 유지보수성에 문제가 발생하게 됩니다.
이처럼 M-V 사이의 관계를 효과적으로 처리하기 위해서 다양한 아키텍처 패턴이 생겨나게 되었습니다.
1. MVC 패턴
Model–View–Controller의 세 영역으로 역할을 분리합니다.
동작 흐름은 다음과 같습니다.
- 리스너를 통해 모든 입력이 Controller로 전달됩니다.
- Controller가 해당 입력에 맞춰 Model을 업데이트합니다.
- 업데이트 결과에 따라 Controller가 표시할 View를 선택합니다. (Controller와 View는 1:N 관계)
- 선택된 View는 Model을 참조하여 화면을 다시 그립니다.
안드로이드의 MVC 구조는 조금 다른 형태를 보입니다.
안드로이드는 Activity (or Fragment)에서 View와 Controller의 기능을 모두 담고 있어, 분리가 어렵습니다.
또한 레이아웃(XML)의 경우, 기본 레이아웃만을 제공하기 때문에 리스트 구현과 같은 UI 로직이 들어갈 여지가 없습니다.
따라서 사실상 MV 구조의 형태를 띄게 됩니다.
다음 서준수님의 글에서 더 자세한 내용을 확인해볼 수 있습니다.
안드로이드에는 MVC 아키텍처 패턴이 없다
안드로이드에서 대표적인 아키텍처 패턴으로 MVC, MVP, MVVM이 거론된다. 사실상 MVC 패턴은 거의 사용되지 않는다. 더 좋은 아키텍처 패턴이 등장해서 사장된 것일 수도 있지만 여전히 다른 분야에
brunch.co.kr
MVC 아키텍처는 여러 단점을 가지고 있습니다.
- Massive ViewController : Activity/Fragment의 코드 양이 비대해지고, 잘못하면 스파게티 코드가 되기 쉽습니다.
- Controller가 안드로이드 API에 밀접하게 종속되어 단위 테스트가 어렵습니다.
- Model과 View 사이에 직접 의존이 발생하면, 비즈니스 로직에서 UI 코드를 참조하게 되어 클린 아키텍처 원칙을 위배합니다.
2. MVP 패턴
Model–View–Presenter의 세 영역으로 역할을 분리합니다.
동작 흐름은 다음과 같습니다.
- 모든 입력 이벤트를 View가 수신한 후, Presenter에게 이벤트를 위임합니다.
- Presenter는 View에서 전달받은 input에 해당하는 Model을 업데이트·조회합니다.
- Presenter는 Model 업데이트 결과에 따라 View를 업데이트합니다. (Presenter와 View는 1:1 관계)
MVP 아키텍처는 MVC에 비해 다음과 같은 개선점을 가지고 있습니다.
- Presenter를 통해서 데이터를 전달받아 Model과 View 간 직접 의존을 해제하여 테스트가 용이합니다.
- SOLID의 개방-폐쇄 원칙(OCP)을 따르는 구조로, View보다 더 높은 수준의 요소인 Presenter를 View의 변경으로부터 보호합니다.
그러나, 다음과 같은 단점이 존재했습니다.
- View와 Presenter가 1:1 관계이기 때문에 서로 간 의존성이 커집니다.
- 각각의 View에 해당하는 Presenter 클래스가 생겨, 코드량이 많아지며 유지보수가 어려워집니다.
3. MVVM 패턴
Model–View–ViewModel의 세 영역으로 역할을 분리합니다.
동작 흐름은 다음과 같습니다.
- 모든 입력 이벤트를 View가 수신한 후, ViewModel에게 사용자 입력을 전달합니다.
- ViewModel은 전달받은 input에 해당하는 Model을 업데이트합니다.
- Model이 변경되면 ViewModel에서 업데이트된 데이터를 LiveData(or State) 형태로 저장합니다.
- View는 ViewModel의 데이터를 관찰하고 자동으로 UI를 업데이트합니다. (ViewModel와 View는 1:N 관계)
MVVM 아키텍처는 MVP에 비해 다음과 같은 개선점을 가지고 있습니다.
- 1대1 관계의 Presenter와 달리, ViewModel이 View를 전혀 모르는 구조로 완전한 의존성 분리가 가능합니다.
- SOLID의 단일 책임 원칙(SRP)에 가깝게, UI 상태 관리와 비즈니스 로직 호출이 분리되어 테스트·재사용성이 높습니다.
여기서, MVVM에서의 ViewModel과, 안드로이드의 ViewModel은 다른 개념을 일컫습니다.
- MVVM 개념의 ViewModel에 “생명주기 안전성” 기능이 추가된 AAC 컴포넌트가 AndroidX ViewModel입니다.
- 화면 회전 시 Activity가 파괴·재생성되어도 ViewModel은 그대로 유지되어, 뷰가 데이터만 관찰하면 되도록 합니다.
4. MVI 패턴
Model–View–Intent의 세 영역으로 역할을 분리합니다.
다음 요소들을 활용해서 구조화를 진행합니다.
- Intent: 사용자의 액션을 나타내는 이벤트입니다.
- Model(State): Intent를 처리해 생성한 불변(Immutable) 상태 객체입니다.
- View: Model을 기반으로 UI를 렌더링하는 요소입니다.
- SideEffect: 상태를 변경할 필요가 없는 일회성 이벤트를 처리하는 요소입니다. (ex. 네비게이션, 토스트 노출)
다음 요소들을 단방향 순환 구조를 통해 진행됩니다.
- 사용자의 action이 새로운 Intent로 생성되어 전달됩니다.
- Intent의 의도가 적용된 새로운 Model을 생성합니다.
- 만들어진 Model를 통해 View를 갱신합니다.
MVI 구조는 다음과 같은 장점을 가지고 있습니다.
- 불변의 데이터 구조 사용으로, 상태를 변경할 때마다 새로운 객체를 생성하여 안정성이 보장됩니다.
- 상태 기반 UI 관리 : UI의 전체 상태(State)를 단일 소스로 관리하여, UI 변경을 예측 가능하도록 설정합니다.
- 상태 변경 시 전체 View가 아닌, 변경된 부분만 업데이트하여 퍼포먼스를 개선합니다.
참고 자료 :
MVC, MVP, MVVM, MVI 아키텍쳐 안드로이드에서 이해하기 — 1
Android 프로젝트에 MVI 도입하기 | 찰스의 안드로이드
안드로이드 [Kotlin] - 아키텍처 패턴 with MVC, MVP, MVVM (feat 코드 예제)
Android Architecture Pattern : MVC, MVP