[Programming] MVC, MVP, MVVM 차이점

내가 여러 가지 강의도 찾아보고, 많은 글도 읽어본 결과 MVC, MVP, MVVM은 UI를 어떻게 표현할지에 대한 디자인 패턴에 가깝다고 느꼈다. 그 이유는 맨 마지막에 써보도록 하겠다. 많은 곳에서 MVC, MVP, MVVM에 대해 말하는 것이 조금씩 다른데, 공통적으로 말하는 큰 본질 부분을 정리해 보려고 한다. 

 

디자인 패턴은 추상적인 컨셉이나 아이디어에 가깝기 때문에 실제 구현은 일부사항이 달라질 수 있기 때문에 모두가 조금씩 다르게 설명하는 것 같다.

 

물론 코딩에 대한 경력이 너무너무 적기 때문에, 설명이 부족할수도 있고, 틀릴 수도 있지만 그래도 최대한 이런 글을 작성해보고 싶다는 생각이 들었다. 나중에 이 글을 보게 된다면 그때는 이런 생각을 했구나 알 수도 있고...

 

우선 시작은 이렇다. 어떠한 앱이나 웹이 있을 때, Model과 View의 역할이 있었다. 하지만 기능이 복잡해지고, 다양해지면서 Model과 View의 코드도 길어지고, 책임도 막중해지게 되었다. 따라서 이 역할과 책임을 나누게 된다. 그리고 이 역할과 책임에 따라 Controller, Presenter, ViewModel가 나뉘게 되는 것이다.

 

MVC

점점 웹이나 앱이 복잡해지면서 유지보수 및 테스트를 위한 관심사의 분리, 즉 역할분리가 필요하게 되었다.  MVC는 1979년 최초로 소개된 소프트웨어 디자인 패턴이다. Model은 데이터 담당, View는 UI담당을 맡게 된다. Controller는 뜻 그대로 이들을 통제한다. input을 받고, 어떠한 것을 실행해야 하는지, 어떠한 결과물을 View에 보여줄지도 담당한다. Controller를 통해서 Model은 데이터를 가공하게 되고 이것을 View에 보여주게 된다.

MVC의 단점

1. 각 요소간의 결합

Model을 직접 View에서 표시하기 때문에 View에서 Model을 알아야 하고, Controller는 View와 Model을 알아야 한다. 따라서 서로 얽혀있다. 그렇다는 것은 하나를 변경하면 다른 곳에 어떠한 영향이 갈지 모른다는 위험성이 존재하고, 이는 코드를 수정하기가 매우 어렵다는 뜻이기도 하다. 특히 Model과 View가 결합되어 있어 Model의 재사용이 어려워질 수 있다.

 

2. Controller의 역할이 과도하게 커짐

흔히 Massive View Controller라고 표현하기도 한다. 아래에도 나와있듯이 Controller가 통제하다보니 여러 View와 Model을 Controller가 가져와서 쓰게 되고, 결국 하나의 Controller에 Model과 View가 복잡하게 연결되어 버리는 상황이 발생할 수 있다.

Facebook: MVC Does Not Scale, Use Flux Instead [Updated]

출처: 상단 링크

 

MVP

이러한 Controller의 과도한 업무와... Model과 View의 결합에 관련된 문제를 해결하고자 나온 패턴중 하나가 MVP(Model-View-Presenter)이다.

Model과 View사이의 화살표가 사라졌다! View는 input을 받아 Presenter에게 알려주고, Presenter가 Model의 데이터를 View에 표시해준다. 여기서 View와 Presenter의 의존성이 강해지면서 View와 Presenter가 1:1 대응을 이루게 된다. 비슷한 로직을 여러 개의 Presenter가 하게 된다. 화면이 늘어나게 되면 Presenter도 늘어나게 된다.

 

MVVM

그래서 의존성을 좀 줄여보자! 해서 나온게 ViewModel이다. ViewModel은 데이터만 가지고 있다. View에서 ViewModel을 지켜보다가 데이터가 변경되면 그것을 View에 표시한다. 따라서 여러 화면이 있어도 똑같은 데이터를 필요로 한다면 ViewModel하나에 여러 가지 View가 연결되어 있다.

 

마치며

MVC, MVP, MVVM이 디자인 패턴에 가깝다고 생각한 이유는 Model에 대한 고려사항이 크게 없다. Model이 어디서 데이터를 가져오는지, 어떻게 로직을 처리해야 하는지... Clean Architecture를 보면 그것에 대한 고민이 엄청나게 보인다.

 

아래의 글은 unnnyong님이 "SwiftUI에서 MVVM 사용을 멈추자" 아티클을 번역해주신 글인데, 이번에 소프트웨어 디자인 패턴에 대한 공부를 해보면서 다시 읽어보니 느낌이 달랐다.

「SwiftUIでMVVMを採用するのは止めよう」と思い至った理由 - Qiita

swiftui_mvvm.md

 

SwiftUI에는 기본적으로 @State, @ObservableObject 등 데이터의 변경을 관찰하고 있는 모양을 띄고 있다. 따라서 이러한 프로퍼티 래퍼가 자연스럽게 MVVM의 성질(?)을 띄고 있다.

 

어떻게 하면 UI와 로직을 분리할 수 있을지 좀 더 깊은 고민을 해봐야겠다.