[CS] MVVM 패턴 바로알기

들어가며

지난 포스팅에서는 MVC 패턴의 단점을 개선하고자 탄생한 MVP 패턴에 대해 알아보았습니다.

MVP 패턴에 관한 자세한 이야기는 아래 포스팅을 참고해주세요!

[CS] MVP 패턴 바로알기

 

이번 포스팅에서는 MVVM 패턴의 구조와 탄생 배경, 장단점을 알아보겠습니다.

분량 문제로 인해 본 포스팅에서는 안드로이드 개발에서 MVVM 패턴을 적용하는 방법은 다루지 않습니다!
안드로이드에서 MVVM을 적용하는 방법은 다음 포스팅에서 다룰 예정입니다.

 

 

MVP의 문제점

지난 포스팅에서 알아본 MVP 패턴은 Model-View-Presenter로 구성되어 있으며, UI 로직과 비즈니스 로직을 분리하여 View와 Model 간 결합도를 낮추어 MVC의 문제점을 해결해주었습니다. 하지만 아래의 문제점이 존재합니다.

• View와 Presenter 간 일대일 의존성 : View와 Model의 결합도를 낮추었지만, View와 Presenter가 서로 강하게 연결되어있습니다. Contract라는 Interface를 정의하여 서로가 추상화된 View와 Presenter를 참조하지만 결국 의존성이 남아있기에 Presenter의 재사용이 어렵고 Presenter에 대한 테스트가 귀찮아집니다.

MVP의 문제점을 해결하기 위해 우리는 MVVM 패턴을 활용할 수 있습니다.

 

MVVM 패턴

정의

Wikipedia: Model–view–viewmodel

Model–view–viewmodel (MVVM) is an architectural pattern in computer software that facilitates the separation of the development of a graphical user interface (GUI; the view)—be it via a markup language or GUI code—from the development of the business logic or back-end logic (the model) such that the view is not dependent upon any specific model platform.

Model–view–viewmodel - Wikipedia

 

MVVM 패턴은 Model, View, ViewModel로 구성된 컴퓨터 소프트웨어 아키텍처 패턴입니다.

GUI(그래픽 사용자 인터페이스, View) 개발과 비즈니스 혹은 백엔드 로직(Model) 개발을 분리하여, View가 특정 모델(구성 요소)에 종속되지 않도록 만드는 시스템 설계 방법입니다.

여기서 설명한 백엔드 로직이란, UI 로직과 구별되는 애플리케이션의 핵심 로직을 의미합니다.

 

View가 특정 구성 요소에 종속되지 않는다는 것은 View에 대한 참조를 가진 요소가 존재하지 않는다는 의미입니다. 즉, Model뿐 아니라 ViewModel 또한 View를 알지 못한다는 것이죠. 이것이 어떻게 가능할까요?

 

구조

MVVM 패턴을 좀 더 이해하기 위해 구조를 살펴보겠습니다. MVVM 역시 MVC에서 파생되었기 때문에 구조가 유사하지만, View와 ViewModel 사이의 연결 구조에 중요한 차이가 있습니다.

 

MVVM 패턴 구조(출처: Microsoft - MVVM)

Model

MVC, MVP의 Model과 동일한 역할을 합니다.

• 프로그램 상에서 도메인과 비즈니스 로직을 구현하는 객체이다.
• UI에 나타낼 정보를 담고 있다.
• ViewModel로부터 데이터와 이벤트를 전달받아 변경된다.

View

MVC, MVP에서 View와 같지만, 중요한 차이가 있습니다.

• UI 로직을 구현한다.
• 사용자와 상호작용을 담당하고, 해당 이벤트를 ViewModel에게 전달한다.
• ViewModel로부터 데이터(Model의 값, 속성 등)을 전달받아 사용자에게 보여준다.
• ViewModel과의 상호작용은 DataBinding(데이터 바인딩)을 통해 이루어진다.

ViewModel

View와 Model 사이에서 데이터를 주고받는 Controller 또는 Presenter와 비슷하지만, View를 추상화한 개념이며, View 사이를 이어주는 Binder가 존재합니다.

• Model과 View 사이 중간 관리자 역할을 한다.
• 속성과 동작을 외부에 노출시킨, View의 추상화다.
• View와 View에 바인딩된 ViewModel의 속성을 자동으로 연결해주는 Binder가 존재한다.
• 바인딩된 View로부터 이벤트를 전달받아 처리하며, Model을 가공한다.
• 가공된 Model의 데이터는 바인딩된 View에게 자동으로 전달된다.

MVP와 구별되는 특징

데이터 바인딩

제공자와 소비자로부터 데이터 원본을 결합시켜 이들을 동기화하는 기법.

데이터 바인딩 프로세스에서 각 데이터 변화는 데이터에 묶인 요소에 의해 자동으로 반영된다. 데이터 바인딩이라는 용어는 또한 요소 내 데이터의 외부 표현이 변경되는 경우에도 사용되며 기반이 되는 데이터는 자동으로 이러한 변경을 반영하도록 업데이트된다.

데이터 바인딩 - 위키백과, 우리 모두의 백과사전

 

MVP, MVC와 가장 구별되는 MVVM의 특징을 이야기하자면, 바로 데이터 바인딩으로 구현되는 패턴이라는 것입니다.

위키 백과에서의 정의를 보면 알 수 있듯, 데이터 바인딩을 적용하면 제공자의 데이터의 변화가 소비자에게 자동으로 반영되고, 반대로 소비자의 데이터 변경이 제공자에게도 자동으로 반영됩니다.

 

아까 보았던 MVVM의 구조를 다시 살펴봅시다.

1. View로부터 전달된 이벤트를 받은 ViewModel이 (Data Binding and Commands)
2. Model을 이용해 보여줄 데이터를 가공하면, (ViewModel updates the model)
3. View의 데이터 또한 자동으로 동기화됩니다. (ViewModel → View: Send notifications)

즉, ViewModel은 데이터를 처리하고 변환하는 역할만 담당하며, 데이터가 변경되면 View에 자동으로 업데이트됩니다. 데이터 바인딩을 활용한 이러한 특성 때문에 ViewModel은 MVC의 Controller나 MVP의 Presenter와 달리 View에 대한 의존성이 없습니다.

 

MVVM의 탄생 배경

MVVM은 MVC와 MVP의 단점을 보완한다는 것만 알고 있었지, 정확히 누가, 어떤 과정으로 고안한 패턴인지는 몰랐습니다.

그래서 이번 기회에 가볍게 MVVM의 탄생 역사를 알아보았습니다.

위키백과와 아래의 글을 바탕으로 조사한 내용입니다!

 

Patterns - WPF Apps With The Model-View-ViewModel Design Pattern

Patterns - WPF Apps With The Model-View-ViewModel Design Pattern

Introduction to Model/View/ViewModel pattern for building WPF apps

Introduction to Model/View/ViewModel pattern for building WPF apps

 

개발 용도

최초의 MVVM 패턴은 마이크로소프트의 설계자였던 켄 쿠퍼(Ken Cooper)와 테드 피터스(Ted Peters)에 의해 발명되었으며, 이후 Window Presentation Foundation(WPF) 프로그램을 개발할 때 적용되었습니다.

WPF는 윈도우 기반 응용 프로그램에서 사용자 인터페이스를 표시할 수 있도록 지원해주는 UI 개발 프레임워크입니다. 윈도우 응용 프로그램 개발 프레임워크인 .NET(닷넷)의 일부이며, 한 때 자주 사용되었던 운영체제인 Window 7, Window 8의 시작 메뉴 창도 WPF를 이용해 제작되었다고 합니다.

고안된 이유

MVVM이 처음 고안된 이유는 UI/UX 중심의 개발을 이어나가기 위해서입니다.

MVVM이 처음 공개된 2000년대에 들어설 때에는 시스템의 View 개발 작업이 개발자에서 디자이너가 담당하는 것으로 바뀌는 추세였습니다. 웹과 응용 프로그램 등은 대부분 디자이너가 HTML이나 XAML 같은 언어를 활용해서 만들었습니다. 이렇듯 사용하는 언어와 개발 도구도 달랐기에 UI와 시스템 로직을 연결해주는 구조가 필요했습니다.

특히 HTML, XAML과 같은 언어만으로는 상태에 따라 View를 다르게 보여주는 등의 복잡한 UI를 구현하기 어려웠고(이는 HTML과 XAML의 선언적인 특성 때문이기도 합니다.), 기존에 사용하던 MVC 패턴으로는 이런 구현이 어려웠습니다.

그리하여 다른 언어로 개발된 UI와 시스템 로직을 연결해주면서도, UI/UX 디자인과 요구사항에 맞춰 시스템을 개발해야하는 필요성이 생겼고, 이를 위해 데이터 바인딩이 적용된 MVVM 패턴이 고안되었습니다.

데이터 바인딩을 활용하여 다른 언어로 개발된 UI와 시스템 로직과 데이터를 연결하였고, UI/UX에 맞춰 시스템 로직을 개발할 수 있도록 ViewModel이라는 요소가 고안되었습니다.

MVVM의 근원: MVC와 PM 패턴

MVVM은 MVC와 PM 두 개의 패턴에서 기반했습니다.

기본적으로 MVVM은 MVC 패턴에서 변형된 패턴이며, MVVM 역시 MVC처럼 시스템을 관심사에 따라 3개의 구성 요소로 나누어져 있습니다.

이 글을 쓰기 전까지는 MVVM이 MVP의 문제점을 해결하는 패턴으로 많이 거론되었기에 MVP에서 변형된 패턴인 줄 알았지만, 놀랍게도 MVP로부터 파생되었다는 내용은 찾아볼 수 없었습니다.

 

PM 패턴은 마틴 파울러(Martin Fowler) 의 Presentation Model(PM) 디자인 패턴을 말합니다.

마틴 파울러의 PM 패턴 예시 다이어그램

2004년에 발표된 PM 패턴은 View를 동작 및 상태로부터 분리한다는 점에서는 MVP와 유사합니다. 그러나 PM 패턴은 Presentation Model이라고 불리는 View의 추상화를 생성합니다. 즉, View는 Presentation Model을 렌더링한 요소인 셈이죠. 이러한 PM 패턴의 Presentation Model의 개념에서 착안하여, View에 보여줄 데이터를 처리하는 ViewModel을 만든 것이라고 합니다.

MVVM의 ViewModel은 View의 상태와 동작을 포함하는 View의 추상화라는 점에서 파울러의 Presentation Model과 동일합니다. 그러나 파울러는 UI 플랫폼에 독립적인 뷰 추상화를 만들기 위한 수단으로 Presentatioin Model을 도입한 반면, 고스만은 UI 생성을 간소화하기 위해서 WPF의 핵심 기능을 활용하는 표준화된 방법으로 MVVM을 도입했습니다.

MVVM 패턴에 대한 글을 쓴 마이크로소프트의 Josh Smith는 MVVM에 대해서 아래와 같이 이야기했습니다.

In that sense, I consider MVVM to be a specialization of the more general PM pattern, tailor-made for the WPF and Silverlight platforms.

"그런 의미에서 저는 MVVM이, 보다 일반적인 PM 패턴을 WPF와 Silverlight 플랫폼에 맞게 특수화한 것이라고 생각합니다."

세상에 널리 알려지다

2005년, 마이크로소프트의 WPF 및 Silverlight 설계자 중 한 명인 존 고스만(John Gossman)은 자신의 블로그에 MVVM 패턴을 공개하면서 세상에 알려졌습니다.(지금은 Microsoft의 옛 문서를 보관한 카테고리에서 찾을 수 있습니다.)

마이크로소프트의 WPF 프로그램에서 시작된 MVVM 패턴은 점차 유명세를 얻었고, 웹, 응용 프로그램 뿐 아니라 모바일 프로그래밍 환경에서도 사용되면서 MVC 패턴과 MVP 패턴의 대안책으로 자리잡았습니다. 이제는 MVVM의 근간이었던 WPF보다도 훨씬 유명해졌습니다.

 

MVVM의 장단점

Advantages and disadvantages of M-V-VM

Advantages and disadvantages of M-V-VM

장점

MVVM 패턴은 관심사의 분리와 데이터 바인딩을 이용한 자동 UI 갱신 등으로 여러 장점을 가지고 있습니다.

관심사의 분리

MVC, MVP 패턴과 마찬가지로 관심사에 따라 3개의 구성 요소로 분리되어있습니다.

Model은 비즈니스 로직과 데이터의 저장, View는 UI 로직, ViewModel은 UI에 필요한 데이터 관리와 이벤트 처리 등을 담당합니다. 관심사에 따라 코드가 분리되었기에 유지 보수성이 향상합니다.

더 유리한 테스트

View를 알고있는 Controller, Presenter와 구별되는 가장 큰 차이점으로, ViewModel은 View를 참조하지 않습니다. View에 대한 의존성이 없기 때문에 ViewModel의 단위 테스트가 더욱 쉬워집니다.

ViewModel은 View보다는 Model에 조금 더 가깝기 때문에 테스트에서 UI 로직을 고려하지 않아도 됩니다.

UI 변경에 유리

서비스에서 UI는 자주 변경될 수 있는 부분이기 때문에, 변경사항에 유연하게 대처하는 것이 중요합니다. ViewModel은 View의 참조가 없어 View의 변경에 큰 영향을 받지 않습니다. 많은 기업에서 MVVM 패턴을 사용하고 있는 이유 중 하나입니다.

ViewModel의 재사용 가능

View와 Presenter가 1:1로 연결되었던 MVP와 달리, MVVM의 ViewModel은 다른 View에서 재사용이 가능합니다. View에 대한 참조가 없고, View에 필요한 데이터를 외부에 노출하고만 있기 때문입니다.

복잡한 프로젝트에서 어느 정도의 재사용성을 제공해주어 코드 중복을 줄여줄 수 있습니다.

 

단점

하지만 몇 가지 치명적인 단점 역시 존재합니다.

과도한 설계

단순한 UI를 가졌거나 소규모의 프로젝트인 경우 MVVM 패턴의 적용은 너무 과도할 수 있습니다.

MVVM은 ViewModel을 별도로 분리하고 데이터 바인딩을 위한 구문이 추가되면서, 오히려 단순한 프로젝트에서는 코드 구조가 과도하게 복잡해질 수 있습니다. 소규모의 프로젝트인 경우에는 MVP나 MVC 패턴이 더 적합할 수 있습니다.

빌드 속도 저하

데이터 바인딩은 생각보다 무거운 작업입니다. 프로젝트를 빌드하는데 더 많은 시간이 소요되고 더 많은 메모리를 차지하기 때문에 성능에 영향이 갈 수 있습니다. 규모가 큰 프로젝트인 경우 빌드 시간이 더욱 많이 소요됩니다.

어려운 디버깅

데이터 바인딩 오류는 컴파일 타임이 아닌 런타임에 감지되는 경우가 많기 때문에 오류가 발생했을 때 문제 원인을 찾기 어렵습니다.

메모리 누수 문제

모바일 개발 환경에서는 앱과 화면의 생명 주기를 잘 관리해야합니다. 생명 주기에 따라 적절히 바인딩을 해제하지 않거나, ViewModel이 View를 잘못 참조하게 된다면 메모리 누수 문제가 발생할 수 있습니다.

 

 

마치며

정리하자면, MVVM 패턴은 MVC 패턴과 PM 패턴의 변형으로, View 중심의 시스템 개발을 할 수 있도록 고안된 설계 패턴입니다. 디자이너와 협업하여 UI를 개발하고, 복잡한 UI가 필요해지면서 데이터 바인딩을 활용한 MVVM 패턴이 탄생했습니다.

데이터 바인딩으로 인해 Controller, Presenter의 역할을 하는 ViewModel에서는 View에 대한 참조가 사라졌고, 덕분에 테스트가 유리해지고 유지보수가 편리해지는 등 여러 장점이 나타났습니다.

하지만 소규모 프로젝트인 경우 과도한 엔지니어링이 될 수 있으며, 실제 구현에서는 디버깅이 어렵고 빌드 속도 저하, 메모리 누수 문제 등의 어려움이 존재한다는 것을 알 수 있었습니다.

 

다음 포스팅에서는 이번 글에서 소개하지 못했던 안드로이드에서 MVVM 패턴을 적용하는 방법을 자세히 이야기해보고자 합니다!

 

참고 자료

• Model–view–viewmodel

Model–view–viewmodel - Wikipedia

• 모델-뷰-뷰모델

모델-뷰-뷰모델 - 위키백과, 우리 모두의 백과사전

• Model-View-ViewModel - .NET

Model-View-ViewModel - .NET

• Patterns - WPF Apps With The Model-View-ViewModel Design Pattern

Patterns - WPF Apps With The Model-View-ViewModel Design Pattern

• Introduction to Model/View/ViewModel pattern for building WPF apps

Introduction to Model/View/ViewModel pattern for building WPF apps

• Presentation Model

Presentation Model

• The birth of MVVM and the Untold Story of Windows Presentation Foundation (WPF)

The birth of MVVM and the Untold Story of Windows Presentation Foundation (WPF)

• Advantages and disadvantages of M-V-VM 

Advantages and disadvantages of M-V-VM