블로그 내 검색

2013. 6. 6.

MVC, MVP, MVVM 의 이해

과연…?

만일 열명의 소프트웨어 개발자를 한 방에 두고 Model – View – Controller 패턴에 대해 토론하라고 한다면, 아마 토론이 끝났을 때 서로 다른 열두개의 의견이 나올 것이다.
MVC 패턴은 프로그래밍을 배우는 사람들, 특히 웹 프로그래머에게는 아주 친숙한 패턴이다. 한때 SI 업계를 휩쓸었던 Struts가 MVC를 표방했었고 그 뒤로 대부분의 웹 프레임워크들은 MVC가 아니면 도태되는 듯이 당연하다는 듯 수식어를 붙이고 등장했다.

하지만 어떤가? 다들 MVC를 완벽히 이해하고 쓰고 있는 것일까.

이 패턴에 대해 정확하게 이해하고 쓰기란 참 쉽지 않은 것 같다. 이 글을 읽는 당신이 당장 MVC 패턴에  대해 자신있게 5분간 말할 수 있다면 이 글을 그만 읽어도 된다.
41224_97606099
사실 이 글을 쓰는 필자 조차도 누군가 갑자기 MVC에 대해 묻는다면 버벅댈 것이다. 글을 쓰려고 수많은 조사를 한 이 순간에도 말이다.

위의 죠쉬 스미스의 말처럼, MVC 패턴에 대해서는 명확한 정의를 내리기 어려운 것 같다.
이번에 다룰 개념들은 MVC, MVP, MVVM 에 대해서이다.

다시 말하지만 여기 쓰여진 것들이 정답은 아니다. 구현과 상황, 이해도에 따라 다른 개념으로 해석하거나 적용될 수 있다.

이 글은 필자가 이해하고 있는 수준에서 이야기할 것이다. 만일 잘못되었거나 다른 의견이 있다면 댓글로 달아주면 아주 기쁘게 토론할 수 있겠다.

Model 과 View 그리고 서로간의 관계

오늘 설명할 프레임워크들에서 변하지 않는 공통적인 용어 두개의 일반적 의미부터 짚고 넘어가 보자.

Model

모델은 도메인 개체 그 자체이다.

도메인은 프로그램 내에서 동일한 의미를 갖는 대상이다. 보통 Data 그 자체와 동일시 되지만, 이 외의 데이터를 조작할 수 있는 기능이 추가되기도 한다. 구현과 상황에 따라서는 단순히 데이터소스에 접근하는 DAO 역할을 하거나,  파일 시스템 자체가 되거나, 라이브러리 세트가 된다.

View

디스플레이.

사용자(Client. 사람이 아닌 기계 혹은 동물일수도 있다. 어플리케이션이 이용되는 타겟이라고 생각하자) 에게 제공되는 UI Layer를 말한다. 더욱 큰 의미를 포함하면 눈으로 이미지가 곁들여지거나 글자로 이루어지지 않은 바이트 코드의 나열이나 음악 파일등이라도, Client 가 이해할 수 있다면 View가 될 수 있다.

보통 Web Application 등에서는 View는 HTML/CSS 로 렌더링된 화면을 가르킨다.

둘의 관계..

MVC를 비롯한 여러 프레임워크들이 나온 이유는 명확하다.

각 계층의 분리로 재활용성을 높이고 중복을 막자는 것이다. 각 계층의 강한 결합이 발생한다면 애초에 프레임워크를 적용하는 의미가 없다.

이 둘의 의존성을 어떻게 제어하느냐에 따라 MVC, MVP, MVVM … etc 등으로 나뉘게 된다.

Controller, Presenter, ViewModel…?

이들은 모델과 뷰의 통신을 담당한다. 이들의 차이점을 한번 훓어보자.

Controller

모든 입력은 Controller에서 처리된다.
특정 입력이 들어오면 Controller는 그 입력에 해당하는 Model을 선택하여 처리하게 한다.
Controller는 입력에 따라 Model을 업데이트하고, 결과에 따라 다른 View를 선택한다. Controller는 View를 선택할 수 있기에 View를 여러개 관리할 수 있다.

일반적으로 View는 Model을 사용하여 업데이트를 하지만, Model을 관리하는 것은 Controller이므로 사실상 View는 Model을 직접적으로 생성하거나 관리하는 것은 아니다. Model을 이용하거나 이용될 뿐이다.

Controller는 Model을 조작하고 View를 선택하지만 View를 직접 업데이트하진 않는다.
이 경우에는 View와 Model의 관계가 어느정도 있으며

  • View가 Model을 직접 사용하여 업데이트가 되거나,
  • 아니면 Model은 자신과 관련돤 View 들에게 Notify 해줘서 View가 업데이트 되는 방식도 있고,
  • View가 polling 을 통해 Model의 변화를 알아채고 스스로 업데이트하는 방식도 있다.
어느것이 되었든 View와 Model의 어느정도의 의존성은 피할 수 없다. 이것이 Controller를 사용하는 MVC의 문제점이라면 문제점이다.
MVC 패턴의 좋은 구성은 최대한 이 둘의 의존성을 낮추는게 관건이다.

조금 억지스러운 예를 들어보자.
View와 Model이 클럽에 온 소극적인 남녀라면 Controller는 이 둘을 부킹해주는 실력좋은 웨이터이다. 여기서 소극적인 이라는게 중요하다. 물론 웨이터는 수 많은 요청에 의해 오늘도 매번 부킹에 성공할 것이다.

Presenter

View와 Model 사이의 상호작용을 담당한다.
또한, 이 경우 사용자의 입력 처리는 Controller 가 아닌 View가 담당한다.

View가 이벤트를 Presenter에 전달하면 이벤트에 맞춰 Presenter는 Model을 조작하고 그 결과를 다시 View에 바인딩하여 View의 요소들이 업데이트된다.

Controller는 단순히 View를 선택하고 Model을 조작한 뒤 실제 회면 갱신은 View와 Model의 상호작용으로 이루어지지만 Presenter 를 사용한 MVP에서는 Presenter가 Model을 조작하고 관리하며 변경이 있으면 Model에 따라 View를 업데이트하게 된다.

실제 구현체로 생각해본다면 Presenter는 Model과 View의 인스턴스를 모두 가지고 있어야 할 것이다. View가 섬이고 Model이 육지라면 그 사이를 이어주는 다리와 같다고 보면 될 듯 싶다.

View와 Presenter는 1:1 관계로 맺어지며 Presenter는 보통 Model보다는 View에 더 닮은 구조로 디자인된다. MVC와는 다르게 View와 Model의 관계가 전혀 없으며 단지 View는 Presenter라는 것을 하나씩 가지고 있게 된다. 그리고 입력 처리를 View에서 처리한다는 점도 큰 차이점이 된다.

이 녀석을 사용하면 View와 Model의 의존관계가 완전히 없어진다.

ViewModel

View의 표현을 담당한다고 보면 되겠다.

MVP와 매우 비슷하지만 큰 차이점이라면 비중이 View에 좀더 치우쳐 있다는 점이며, Presenter는 View에 상당한 의존성이 있었지만, Controller, Presenter의 위치인 ViewModel은 View와 아무런 관련이 없다.

여러 View들은 하나의 ViewModel을 선택하여 바인딩하고 업데이트를 받는다.

ViewModel의 디자인은 View보다는Model에 비슷하게 구성된다. 보통 ViewModel이 변경되면 자동으로 View에 업데이트되는 방식으로 구현된다.
Model이 순수한 Model이라면 ViewModel은 View를 위한 모든 커스터마이징을 제공하는 Model이다.
좀 억지를 부려보면, ViewModel이 회사라면 View는 근무하는 사원에 가깝다. 회사는 사원의 여러 근무에 대한 환경을 제공한다. 이윤을 위해서라면 회사는 그 무엇과도 거래하고 연결한다.

결론

정리하고보니 더욱 애매한 것 같다. 더욱이 패턴의 개념은 구현에 따라 조금씩 변하고 달라지기에 이 셋을 완전히 구분해서 완벽히 이해한다는것도 쉽지 않은 일이다.

더구나 글의 서두에서 밝혔듯이 Model, View의 개념만으로도 개발자들은 제각각의 생각과 구현을 갖고 있을 수 있다. 게다가 만일 이 셋보다 더 획기적인 것이 등장한다면 새로운 용어와 함께 새로운 개념을 이해하려고 시간을 보내고 무슨차이가 있는지 고민이 늘어날 것이다.

이 셋의 차이점을 줄줄 외우는 것보다 이러한 개념의 구분이 어떠한 장점이 있으며, 뭐가 현재 상황에 더 적합한지를 파악하고 사용하는 것이 더 좋을 것 같다.

참고자료

댓글 없음:

댓글 쓰기