[Architecture] MVVM 패턴

MVVM?

MVVM 아키텍쳐/패턴은 MVC의 한계점을 극복하기 위해서 제시된 구조이다. iOS UIKit을 사용해 개발하는 관점에서 MVC는 View와 Controller가 깊게 연관되어 있어 코드를 분리하거나, 테스트 하는데에 용이하지 못하는 문제점과 Controller가 너무나 많은 역할을 담당하는 등의 문제가 있었다. MVVM은 ViewModel이라는 새로운 계층을 도입하여 이를 해결하는 방법을 제시한다.

MVVM에 대해서 알아보기전에, MVP 패턴에 대해서 먼저 살펴보자.

MVP 패턴

MVVM

전에 알아본 것과 같이, Apple MVC 패턴은 View와 Controller 계층이 너무나 밀접하게 연관되어 있어 사실상 같은 계층으로 취급(ViewController)되었던 것과 다르게 Prsenter라는 계층을 새로 두고 ViewController를 View계층으로 취급한다. 따라서 Presenter는 UIKit등의 view 프레임워크에 종속되지 않아 Testable하게 된다는 장점이 생긴다. 또한 Presenter가 기존 ViewController 역할에서 view 관련 요소들을(라이프 사이클 등) 배제한 역할을 담당하므로, 부하도 감소하게 된다.
(전통적인 MVC와 비교했을때는, view와 model이 분리되었다는 의의도 갖게 된다.)

MVP 패턴에서는 presenter가 view의 정보를 직접 업데이트하고 view와 presenter가 1:1 대응관계라는 점이 특징이다. presenter가 view를 업데이트 1:1 대응 관계라서 view에 의존하여 설계될 수 밖에 없고 서로 양방향 소통을 전제로 구현된다는 한계를 극복하기 위해 MVVM 패턴이 등장하게 되었다.

MVVM 패턴

먼저 각 구성요소들을 살펴보자

View

• 사용자 Action을 받아들이고, 보여지는 부분을 담당하는 것은 MVC와 동일하다.
• MVC와 비교해, MVVM에서의 View는 ViewController를 포함하는 것이라는 중요한 차이가 있다.
• View는 ViewModel을 알고있다
• ViewModel과 Binding을 통해 연결되어 있어 ViewModel이 변경되면 View가 업데이트 되게 된다.
• MVC와는 다르게 View Controller를 이 계층에 두므로, 뷰 관련 설정에 대한 코드가 이곳에 들어가게 된다.

View Model

• View Model은 Model의 데이터를 통해 어떻게 화면이 그려질지를 결정하는 Presentation Logic을 담당한다.
• View Model은 View를 알지 못한다. "바인딩" 이라는 방식을 통해서 뷰의 특정 이벤트가 발생했을 때 자동으로 그 로직을 실행하게끔 구현될 뿐이다.
• 하나의 ViewModel이 n개의 View를 담당할 수 있다.
• ViewModel은 View를 알지못한다.

Model

MVC에서의 Model의 역할과 다르지 않다. 앱의 비즈니스 로직과 데이터 및 관련된 Entity들이다.

MVVM 패턴의 장점과 단점

장점

• ViewModel의 책임이 한정되므로, 부하가 줄어들게 된다.
• View는 ViewModel을 알고, ViewModel은 View를 모른다. 이러한 관계에서 데이터 바인딩을 통해 viewModel의 변경사항을 View에 적용하게 된다. 이러한 단방향(unidirectional) 소통을 통해 ViewModel의 View에 대한 의존성을 완전히 낮추게 된다. ViewModel의 재사용성이 향상되고, Testable해진다.
  • 데이터 바인딩은 어떻게 할까? 일반적으로 아래의 방법이 사용된다.
    • RxSwift, Combine등과 같은 반응형 Framework를 사용한다.
    • 컴플리션 핸들러, 딜리게이트 패턴, 노티피케이션, 프로퍼티 감시자 등 다양한 방법을 사용할 수 있다.
• 데이터를 변경하는 단방향의 이벤트 흐름과, 그 흐름과 반대로 존재하는 변경된 데이터의 흐름를 통해 단방향 데이터 플로우 방식을 구현하므로써, 앱이 동작하는 방식을 직관적으로 파악할 수 있게 된다.
  • View(userAction) -> ViewModel(model에 이벤트에 해당하는 비즈니스 로직 수행 요청) -> Model(비즈니스 로직 수행 및 데이터 변경)-> ViewModel(model의 변경을 인지하고 presentation logic 수행) -> View(viewModel의 변경사항을 반영하여 업데이트)

단점

• 복잡한 화면을 구현할 때 ViewModel역시 과한 부하가 생길 수 있다.
• MVC보다 보일러 플레이트코드가 많이 생긴다.

결론

MVC, MVP 및 MVVM 패턴에 대해 알아봤는데, 이러한 패턴들은 정해진 템플릿이 없기 때문에 기본원칙만 지킨다면 개발자가 원하는 다양한 바리에이션이 나올 수 있고 반대로 말하면 정형화된 형식이 없기 때문에 표준화 규칙을 정확히 만들지 않는다면 중구난방인 코드가 될수도 있다는 단점이 있는 것 같다.

특정한 아키텍쳐를 사용하는 목적은 역할과 책임에 따른 계층분리를 수월하게 하고 그에 따른 코드의 분리를 통해서 초기 개발과정과 이후의 확장과 변경에 있어서 개발편의성을 증대시키는 것이라고 생각한다. 따라서 "정답"인 아키텍쳐는 없고, 특정 아키텍쳐에 매몰되지 않고 각 아키텍쳐들의 본질과 특징이 무엇인지를 파악하고 주어진 상황에 맞는 구조를 사용하는 것이 중요할 것 같다.

템플릿이 있는 아키텍쳐 중 ReactorKit과 RIBs가 유명한데, ReactorKit같은 경우는 최근 채용과제를 진행하면서 한번 경험해보았고 RIBs를 개인적으로 프로젝트에 적용해보고, 후속 포스팅을 하려한다.