MVP와 MVVM
들어가는 말
MVC의 아종인 MVP와 MVVM에 대해 간단하게 정리한 글입니다. 원래는 간단한 것 중에서 자세했었는데 쓰다가 한번 날려먹어서 다시쓰느라 좀 더 간단해졌어요 흑흑
MVP
목적
- presentation logic과 ui 구현체의 관심사 분리
- 단위 테스트 자동화
모델
- 비즈니스 로직, 백엔드 로직, 도메인 로직, ...
뷰
- 수동적인 인터페이스
- 이벤트 발생 시 프리젠터의 특정 콜백을 호출하는 방식
- 아니면 이벤트 발생 시 이벤트 객체처럼 약속된 형태를 프리젠터에게 넘겨주는 방식
프리젠터
- 모든 프리젠테이션 로직을 담당
- 모델과 뷰를 연결해줌
- 모델에게서 데이터를 받아 뷰를 위해 포매팅
- 데이터를 받아온 후 뷰를 업데이트하는 함수를 호출
- 어떻게든 뷰에게 알려야 하기 때문에 뷰와 프리젠터 사이에는 불가피한 의존성이 생김
장단점과 개인 의견
저는 MVP 패턴을 '럭키 MVC'이자 '언럭키 MVVM'이라고 생각합니다.
기존의 MVC에서는 뷰가 어디서 데이터를 받아올 것인지에 대한 제약이 딱히 없었습니다. 그렇기 떄문에 모델에게서 직접 받아올 수도 있었고, 컨트롤러를 이용해서 받아올 수도 있었죠. 하지만 MVP에서 뷰는 프리젠터랑만 소통하도록 구조가 짜여 있기 때문에 데이터를 받아오기 위해서 누구와 연락해야 하는지에 대한 모호함이 없습니다. 따라서 조금 더 통일성 있는 구조가 되었다는 점에서 '럭키'라고 표현했어요.
프리젠테이션 로직을 뷰로부터 분리했기 때문에 단위 테스트 역시 뷰를 제외하고 할 수 있어서 조금 더 용이해졌다고 볼 수도 있겠군요. 뷰는 이제 진짜로 그리는 역할만을 수행할 수 있어서 조금 더 관심사의 분리가 잘 이루어진 모습을 보입니다.
하지만 프리젠터의 입장은 조금 다를 수 있는데요. 데이터를 받아온 후 뷰에게 직접 그리라고 알려줘야 하기 때문에 뷰와 프리젠터는 서로에 대한 상호 의존성이 생길 수밖에 없습니다. 프리젠터는 누가 그려야 하는지를 알아야 하니까요. 그런 의미에서 '언럭키'입니다. MVVM은 알려주는 과정을 프리젠터가 아니라 다른 누군가가 대신 해주거든요.
MVVM
목적
- 뷰 자체를 개발하는 것과 뷰에 필요한 값을 계산하는 로직의 분리
- 비즈니스 로직, 프리젠테이션 로직, ui 세 가지의 분리
모델
- 비즈니스 로직, 백엔드 로직, 도메인 로직, ...
- 뷰 모델을 '구독'하지 않음
뷰
- 뷰모델의 결과물(객체)을 시각적으로 표현하는 데 사용할 uI를 나타내는 템플릿
- 뷰모델을 '구독'함
뷰모델
- 모델의 데이터 객체를 뷰가 쉽게 관리하고 표현할 수 있도록 바꿔주는 변환기
- 뷰를 위한 모델
- binder를 통해 뷰의 변화를 자동으로 유발
- 모델을 '구독'하지만 뷰는 '구독'하지 않음
장단점과 개인 의견
앞서 MVP 패턴의 단점은 값이 바뀌었을 때 바뀌었으니 새로 그리라는 요청을 프리젠터가 손수 한다는 점이라고 했었는데요. MVVM에서는 데이터 바인딩이라는 기법을 사용해서 이를 자동화합니다. 유튜브를 생각해 봅시다. 우리가 누군가를 구독하고 알림 설정까지 해 놓으면 그 사람이 동영상을 올릴 때마다 유튜브가 우리에게 알아서 알림을 보내겠죠? 정작 동영상을 올린 사람은 구독자한테 연락해야 해!! 라는 생각을 딱히 하지 않고요. 비슷하게 뷰는 뷰모델을 구독하고 있다가 뷰모델이 내놓는 값이 바뀌면 '누군가가' 뷰에게 알림을 주고, 뷰는 화면을 다시 그립니다. 그 누군가는 리액트와 같은 프레임워크나 외부 라이브러리일 수도 있고, 순수 자바스크립트를 사용한다면 Proxy 같은 친구들일 수도 있겠죠. 아무튼 그게 모델, 뷰, 뷰모델과는 아무런 관련이 없다는 뜻입니다. 따라서 뷰나 뷰모델은 본인이 값을 받아와야 하는 쪽만 알 뿐이지, 본인의 결과물은 그래서 누가 어떻게 쓰는 건지는 알 필요가 없기 때문에 개발에 상당히 용이해집니다. 마치 컨베이어 벨트처럼 앞사람이 어떻게 주면 나는 이렇게 바꾸면 된다는 것만 알면 되니까요. 만약 정말 큰 규모의 프로젝트라서 ui 개발과 프리젠테이션 로직 개발자가 분리된다면 MVVM 패턴이 상당히 유효할 거라고 생각해요.
하지만 데이터 바인딩을 해 줄 누군가가 필요하다는 사실 자체가 단점이 됩니다. 그 '누군가'를 결정하고 도입하는 비용이 발생하구요. 만약 라이브러리나 프레임워크 없이 자체적으로 데이터 바인딩 기법을 만들어야 한다면 그 공수는 더 커진다고 볼 수도 있겠죠. 따라서 규모가 작은 어플리케이션에서 성급히 MVVM을 사용한다면 오히려 그 보일러플레이트로 인해서 더 큰 귀찮음이 발생할 수 있습니다. 규모가 큰 어플리케이션에서는 이런 보일러플레이트가 여러 사람들 사이에서 코드의 통일성을 지켜주는 수호대의 역할을 할 수 있으니 무조건 단점은 아니긴 합니다. 물론 규모가 큰 어플리케이션에서는 대규모 데이터에 통째로 데이터 바인딩을 걸면 성능 저하가 있을 수 있으니 이쪽으로 고민이 필요하겠지만요.
아무튼 요는 MVVM은 강력한 도구이지만, 데이터 바인딩을 누가 어떻게 할 것인지에 대한 고민이 충분히 이루어져야 한다는 것입니다.
참고 자료
Model–view–viewmodel - Wikipedia
Model-View-ViewModel - .NET | Microsoft Learn
데이터 바인딩 및 MVVM - UMP applications | Microsoft Learn
한 번의 글로 이해하는 소프트웨어 아키텍처 패턴 ( MVC, MVP, MVVM )