android 아키텍처 패턴

과거 Velog 에서 정리한 아키텍처패턴 글과 MVI글을 수정한 뒤 합쳐서 재작성

---

아키텍처 패턴이란?

• 소프트웨어의 구조를 패턴화한 것

안드로이드 아키텍처 패턴의 종류

MVC (Model - View - Controller)

• MVC는 Model, View, Controller로 나뉘는 패턴

Model

• 어플리케이션의 데이터를 저장하고 처리

View

• 사용자가 보게 될 화면(UI)을 담당

Controller

• View와 Model을 연결하고 제어
• 사용자의 입력을 처리
• Android에서는 View와 Controller가 Activity와 Fragment에 포함

흐름

• 사용자 → Controller → Model → Controller → View → 사용자

장점

• 구현이 단순하고 이해가 쉽다

단점

• View와 Model 간의 의존성이 커서 유지보수가 어렵다
• 각 클래스의 코드양이 증가

MVP (Model - View - Presenter)

• MVC의 문제를 개선한 패턴으로, View와 Presenter를 명확히 분리

Model

• MVC와 동일

View

• MVC와 동일

Presenter

• 비즈니스 로직을 처리하고 Model에 데이터를 요청한 후, 결과를 View에 전달
• Interface로 구성되어 UnitTest에 용이

흐름

• 사용자 → View → Presenter → Model → Presenter → View → 사용자

장점

• Model과 View의 의존성이 없다
• UI와 Data가 명확히 구분된다

단점

• View와 Presenter 간의 의존성이 커진다
• 기능이 커질수록 Presenter가 복잡해진다

MVVM (Model - View - ViewModel)

• View와 Model 간의 상호작용을 더 분리하기 위해 만들어진 패턴

Model

• MVC, MVP와 동일하지만, 데이터 변경 시 ViewModel을 거쳐 View로 전달

View

• Model을 직접 알지 못하고 ViewModel을 옵저빙하여 상태 변화가 발생하면 화면을 갱신

ViewModel

• View에 필요한 데이터와 명령을 관리하며, 상태 변화를 View에 전달
• ViewModel은 Model과 상호작용하지만 View와는 독립적이다
• Model과 View 간의 의존성을 없애며 View의 재사용성을 높인다

흐름

• 사용자 → View → ViewModel → Model → ViewModel → View → 사용자

장점

• Model과 View, View와 ViewModel의 의존성이 없다
• AAC ViewModel을 활용하면 View와 ViewModel 간의 데이터 연결이 간편하고, 생명주기 관리가 용이하다
• UI 컨트롤러의 책임을 분담하여 유지보수와 테스트가 용이하다

단점

• ViewModel의 설계가 복잡해질 수 있다
• DataBinding 등 추가 학습이 필요

AAC ViewModel velog 정리글

MVI란?

• 상태 관리에 중점을 둔 패턴으로, 모든 상태를 단일 상태 객체로 관리하는 패턴

MVVM의 문제점

상태 문제

• 상태 제어가 제대로 이뤄지지 않는 경우 발생

부수 효과 (Side Effect)

• 원래 의도와 다른 효과 또는 부작용이 발생하는 경우

특징

• Intent와 State라는 두 가지 새로운 개념을 도입
• 단방향(Unidirectional) 및 순환(Circular Data Flow)의 원칙에 기반
• MVC, MVP, MVVM과 다르게 MVI의 Intent는 컴포넌트가 아닌 동작을 의미

구조

Model

• 상태(State)를 의미하며, Intent로 전달받은 객체에 맞춰 새로운 불변 객체로 생성
• 단방향 데이터 흐름을 보장하기 위해 변경이 불가능하다

View

• Model의 상태를 구독하고 상태 변화 시 UI를 갱신

Intent

• 사용자의 행동을 표현하며, 이를 통해 앱의 상태(State)가 변경
• Android의 Intent와 다르게 사용자 행동을 기반으로 상태를 변경하는 역할
  • Android의 Intent: 컴포넌트 간 메시지 전달을 위한 객체
  • MVI의 Intent: 사용자 행동을 나타내고 상태 변화를 유도

흐름

• 사용자 → Intent → (SideEffect) → Model → View → 사용자

SideEffect

• 앱 외부 시스템과의 상호작용을 처리하는 작업 (예: 네트워크 호출, 데이터베이스 저장)
• 장점: 상태 관리와 외부 작업을 분리 가능
• 단점: 비동기 로직이 복잡해질 수 있음

장점

• 단일 상태로 앱 상태를 관리해 예측 가능한 상태 전이를 보장
• 스레드 안전성, 디버깅, 테스트에 용이하다
• 의존성이 없다

단점

• 러닝 커브가 높다
• 보일러플레이트 코드가 많이 발생
• Intent, State, SideEffect 객체 관리에 신경 써야 한다
• RxJava, Orbit-MVI 등의 라이브러리를 옵션으로 활용할 수 있다

---

MVC, MVP, MVVM, MVI 비교 표

패턴	장점	단점	사용 상황
MVC	구조가 간단함 이해하기 쉬움	View와 Model 간 의존성 큼	작은 앱, 단순한 UI
MVP	View와 로직이 분리되어 테스트 용이	Presenter 복잡해질 수 있음	중소규모 앱, 테스트가 중요한 경우
MVVM	ViewModel이 UI 데이터를 관리 상태 관리에 적합	ViewModel 복잡해질 수 있음	UI 상태 관리가 중요한 앱
MVI	단일 상태 관리로 예측 가능 SideEffect 분리 가능	Intent와 State 관리 복잡 러닝 커브 높음	상태 관리가 중요한 대규모 앱

---

참고

• https://jionchu.tistory.com/entry/Android-Architectural-Pattern-MVC-MVP-MVVM
• https://velog.io/@changhee09/%EC%95%88%EB%93%9C%EB%A1%9C%EC%9D%B4%EB%93%9C-%EC%95%84%ED%82%A4%ED%85%8D%EC%B2%98-%ED%8C%A8%ED%84%B4MVC-MVP-MVVM
• https://adjh54.tistory.com/60
• https://meetup.nhncloud.com/posts/342
• https://meetup.nhncloud.com/posts/342
• https://brunch.co.kr/@oemilk/113
• https://yoon-dailylife.tistory.com/117
• https://jaehochoe.medium.com/%EB%B2%88%EC%97%AD-%EC%95%88%EB%93%9C%EB%A1%9C%EC%9D%B4%EB%93%9C%EB%A5%BC-%EC%9C%84%ED%95%9C-mvi-model-view-intent-%EC%95%84%ED%82%A4%ED%85%8D%EC%B3%90-%ED%8A%9C%ED%86%A0%EB%A6%AC%EC%96%BC-%EC%8B%9C%EC%9E%91%ED%95%98%EA%B8%B0-165bda9dfbe7
• https://www.charlezz.com/?p=46365
• https://sungbin.land/%EC%95%84%EC%A7%81%EB%8F%84-mvvm-%EC%9D%B4%EC%A0%A0-mvi-%EC%8B%9C%EB%8C%80-319990c7d60
• https://velog.io/@jshme/MVI-Architecture-for-Android
• https://heegs.tistory.com/112