안드로이드 개발자를 위한 MVC, MVP, MVVM, MVI 아키텍쳐 끝장정리— 1

매번 헷갈리는 아키텍쳐, 확실하게 정리하기

Bonny

Published in

DelightRoom

9 min readJan 4, 2024

최근에 MVI 아키텍쳐가 안드로이드 커뮤니티에서 자주 언급되고 있습니다. MVI 아키텍쳐를 알아볼겸, 기존에 존재하던 아키텍쳐들도 다시 한 번 학습하였습니다.

MVI 에 대해서는 더 자세히 다룰 것이기 때문에 블로그 글을 2편으로 나누어, 1편에는 MVC, MVP, MVVM에 대해 알아보고 2편에서 MVI에 대해 자세히 알아보려 합니다.

이 글에서는 MVC, MVP, MVVM의 각 구성요소와 장, 단점에 대해서 알아봅니다.

1. MVC

MVC는 MVP, MVVM 등이 나오게 되는 배경이 되는 아키텍쳐입니다. MVP, MVVM이 각각 MVC 로 부터 발전해나갔습니다. MVC는 다른 아키텍쳐들에 비해 시간에 따라, 적용 플랫폼에 따라 다양하게 해석되고 변화해 왔습니다. 먼저 전통적인 MVC, 가장 처음 제안되었던 형태에 대해 알아보겠습니다.

M, V, C 가 각각 뜻하는 것은 아래와 같습니다.

1. Model

어플리케이션 구현에 쓰일 데이터, 비즈니스 로직들을 합쳐 부릅니다
(MVC, MVP, MVVM의 Model 정의는 모두 같습니다.)

2. View

모델을 화면에 표시하는 방법입니다. 즉 UI를 가리킵니다.
View는 Controller의 존재를 알지 못하며, Model만을 알고 있습니다.
Model이 전달되어지길 기대하며, model을 통해 View를 그릴 수 있습니다.

3. Controller

사용자의 Input을 입력받고 그에 따라 Model을 변경합니다.
View를 직접 조정하지 않습니다.

주의할 부분은 View는 본인에게 Model이 전달되어지길 기대하는데, 그 과정에서 Controller를 거치지 않는다는 것입니다. 때문에 View가 Model을 받을 수 있는 방법들은 생각해 내야 하는데, 아래와 같은 방법들이 있습니다.

1. Model 스스로 자신의 변화를 View에게 알립니다.
2. View가 주기적으로 Model을 가져와 업데이트합니다. (Polling)

저는 안드로이드에서 Controller를 거치지 않고, 위 2가지 방법을 구현하는 방법이 명확히 그려지지 않습니다. 그래서 MVC 개념 그대로를 안드로이드 개발에서 사용하기에는 어려움이 있었다고 생각합니다.

각 구성요소를 안드로이드 코드 구성요소로 표현해보자면 아래와 같습니다.

MVC 구조를 안드로이드에 적용해보면 Activity는 Controller를 맡게됩니다. OnClickListener와 같은 리스너를 통해 사용자의 Input을 받을 수 있고, 그 입력에 따라 모델을 변경시킬 수 있기 때문입니다.

그리고 xml 코드들이 View의 역할을 맡게 됩니다. 이 때, View가 Model을 알 수 있는 방법은 중간에서 Activity(=Controller) 가 중재하지 않는 이상 어렵습니다. 여기서 Activity가 View와 Model을 중재한다면, Activity는 Controller이면서 View와 Model의 어딘가가 됩니다.

MVC는 시간이 흐르면서 다양하게 해석하게 되었는데, 초기의 MVC는 view와 model이 연결되어 있지만 이후에는 직접 연결되지 않습니다.변화한 형태는 Controller가 View를 직접 다루게 됩니다. 이 변경된 방식에서는 안드로이드 코드로도 MVC를 구현해 볼 수 있습니다. 다만 이 변형된 형태가 MVC가 맞는지에 대한 논의도 많습니다.

MVC의 장, 단점에 대해 알아보자면

장점

코드들의 역할이 나눠지고 관심사의 분리가 시작되었습니다.
다른 아키텍쳐에 비해 학습이 가장 빠릅니다.

단점

View와 Model이 서로를 의존하고 있습니다. 특히 Model이 View를 직접 참조하게 된다면, 로직단에서 UI단을 의존하게 되어 클린 아키텍쳐에 위배됩니다.
Controller에서 다양한 역할을 수행하게 되면서 비대해집니다.
안드로이드에서 Controller를 명확히 구분짓기 어렵습니다.

2️. MVP

MVC에서 변형된 MVP에 대해서도 알아보겠습니다.

M, V, P 가 각각 뜻하는 바는 아래와 같습니다.

1. Model

MVC의 Model과 같습니다.
어플리케이션 구현에 쓰일 데이터, 비즈니스 로직들을 합쳐 부릅니다

2. View

모델을 화면에 표시하는 방법입니다. 즉 UI를 가리킵니다.
MVC의 View와 다르게, 사용자의 Input을 입력받습니다.
presenter를 참조하고 있습니다.

3. Presenter

View로부터 사용자의 Input을 전달받아 Model을 처리 후, 다시 View를 업데이트 합니다.
View와 Model의 연결다리라고 생각할 수 있습니다.
View와 1:1 관계를 가집니다.
view를 참조하고 있습니다.

다시 MVP를 안드로이드 코드요소로 표현해보자면 아래와 같습니다.

MVP는 MVC와 다르게 유저의 Input을 View가 받습니다.

때문에 Activity를 View로 취급할 수 있게됩니다.

MVP의 장, 단점에 대해 알아보자면

장점

MVC에서 경계가 모호한던 것이 정리되었습니다. (Activity가 view단으로 이동)
View와 Model(=비즈니스 로직)이 서로를 의존하지 않습니다.

단점

View와 Presenter가 1:1로 결합하고 서로를 알고 있습니다. 서로를 서로에게서 떼어내기 어려워집니다. (이 때문에 서로를 interface로 나마 느슨하게 연결합니다.)
View와 Presenter의 1:1 관계를 지키기 위해 큰 의미가 없어도 view마다 presenter를 추가하게 되고, presenter 갯수가 늘어나게 됩니다.

3️. MVVM

안드로이드에서 가장 보편적으로 많이 쓰이고 있는 아키텍쳐라고 생각합니다. MVP의 단점을 해결한 아키텍쳐 입니다.

바로 M, V, VM 에 대해서 알아보겠습니다.

1. Model

MVC의 Model과 같습니다.
어플리케이션 구현에 쓰일 데이터, 비즈니스 로직들을 합쳐 부릅니다

2. View

모델을 화면에 표시하는 방법입니다. 즉 UI를 가리킵니다.
사용자의 Input을 입력받습니다.
ViewModel을 알고 있습니다. (다른 말로, 코드에서 viewModel을 의존하고 있습니다)

3. ViewModel

View를 모릅니다.
View로부터 사용자의 Input을 전달받고, Model을 처리 합니다.
다만 view가 정확히 어떤 객체인지는 알지 못합니다. view를 import하고 있지 않습니다.
model을 적절히 업데이트 한 후, 외부에 노출할 상태를 정의하면, view가 그 상태를 스스로 가져갑니다.
View와 1:1 관계가 아닙니다.

MVVM을 안드로이드 코드요소로 표현해보자면 아래와 같습니다.

observable 패턴, 데이터 바인딩 등을 통해 viewModel이 view를 참조하지 않아도, view가 viewModel의 상태값을 받아올 수 있습니다. MVP 때의 그림과 회색 화살표 하나가 달라졌습니다. 즉, LiveData, Flow 등으로 viewModel은 Model을 업데이트하고, view가 이 데이터를 구독하고 있습니다.

MVVM의 장, 단점에 대해 알아보자면

장점

View가 Model(= 비즈니스 로직)에 의존하지 않습니다.
ViewModel이 View를 의존하지 않습니다.
MVP와 달리 view와 viewModel이 강하게 결합하지 않습니다.
viewModel이 view를 모르기 때문에, 의존성 분리가 되고, view 교체가 쉬워집니다.
때문에, 위 패턴 중 가장 테스트를 작성하기 수월합니다.
ViewModel과 View가 1:1 관계가 아니기 때문에, ViewModel을 잘 나누면 여러 뷰에서 재활용 가능합니다. 다만, 최근 안드로이드 가이드에서는 뷰단위의 ViewModel 재활용을 비추천하고 있으니 주의가 필요합니다.