🏗️ MVC, MVP, MVVM 패턴 - 같은 듯 다른 이들?
UI 관련 아키텍처 패턴인 MVC, MVP, MVVM 패턴을 정리해보려고 한다.
공부하면서 궁금한 점도 하나씩 짚어보자.
🎭 MVC 패턴 - Model, View, Controller
MVC 패턴은 가장 익숙한 디자인 패턴 중 하나다.
Spring 웹 MVC를 공부하면서 접한 적이 있는데, 다시 한번 개념을 정리해 보자.
🛠️ 각 요소의 역할
Model (모델):
데이터를 담당하는 부분이다. 데이터베이스, 변수, 상수 등 애플리케이션의 핵심 정보가 들어간다.
예를 들어, 사용자가 네모 박스(input box)에 글자를 입력한다고 하면,
모델은 네모 박스의 크기, 입력한 글자 내용, 글자의 위치, 포맷 정보 등을 저장한다.View (뷰):
사용자에게 보여지는 화면이다. 버튼, 텍스트 박스, 체크박스 등 UI 요소를 포함하며,
모델을 기반으로 화면을 표시하지만 모델의 데이터를 직접 저장하지 않는다.
즉, 변화가 생기면 컨트롤러에게 알려줘야 한다.Controller (컨트롤러):
모델과 뷰를 이어주는 다리 역할을 한다.
사용자의 입력을 받아서 모델을 변경하고, 그에 따라 뷰를 업데이트한다.
또한, 모델과 뷰의 생명주기 관리 역할도 한다.
✅ MVC의 장점
- 역할이 나뉘어 있어 유지보수와 확장이 쉽다.
- 각 구성 요소에 집중할 수 있어 개발이 체계적으로 이루어진다.
❌ MVC의 단점
- 애플리케이션이 커질수록 모델과 뷰의 관계가 복잡해질 수 있다.
- 컨트롤러가 비대해질 위험이 있다.
🤔 그런데 MVC 패턴에서 뷰는 왜 컨트롤러를 참조하면 안 되는 걸까?
뷰가 컨트롤러를 직접 참조하면 MVC 구조가 깨질 위험이 있다.
컨트롤러가 모든 요청을 처리하는 게 아니라면, 뷰가 다른 요소를 직접 조작하지 않도록 해야 한다.
🎤 MVP 패턴 - Model, View, Presenter
MVP는 MVC의 컨트롤러(C)가 프레젠터(P)로 바뀐 구조이다.
가장 큰 차이점은 View와 Presenter가 1:1 관계를 맺는다는 것!
🛠️ 역할 정리
- Model (모델): 데이터를 관리하는 것은 동일하다.
- View (뷰): UI를 표시하지만, 모델을 직접 조작하지 않는다.
- Presenter (프레젠터): 뷰와 모델 사이에서 중간 역할을 하며,
뷰의 모든 로직을 담당한다.
→ 즉, 뷰는 단순히 보여주는 역할만 하고, 프레젠터가 모든 처리를 맡는다.
✅ MVP의 장점
- 뷰가 정말 UI만 담당하기 때문에, UI 코드와 로직 코드가 분리된다.
- 테스트하기 쉽다. (프레젠터 단위 테스트 가능!)
❌ MVP의 단점
- 뷰와 프레젠터가 1:1 관계이기 때문에, 뷰가 많아질수록 프레젠터도 많아져야 한다.
- 프레젠터의 코드가 커질 위험이 있다.
🤔 그럼 MVP가 항상 MVC보다 좋은 걸까?
꼭 그렇지는 않다. MVC에서는 뷰와 컨트롤러가 1:N 관계일 수 있지만,
MVP는 무조건 1:1 관계라서 앱의 크기에 따라 불필요한 코드가 많아질 수도 있다.
🖼️ MVVM 패턴 - Model, View, ViewModel
MVVM은 MVC의 컨트롤러(C)가 뷰모델(ViewModel)로 바뀐 패턴이다.
Vue.js 같은 프레임워크에서 많이 사용된다.
그럼 MVC, MVP와 비교했을 때 어떤 점이 다를까?
🛠️ 역할 정리
- Model (모델): 데이터를 관리하는 것은 동일하다.
- View (뷰): 사용자에게 보여지는 화면이다.
- ViewModel (뷰모델):
- 뷰를 추상화한 계층으로, 뷰와 직접 연결되지 않는다.
- 뷰와 1:N 관계를 가질 수 있다.
- 커맨드(Command)와 데이터 바인딩(Data Binding)을 사용해 뷰와 데이터를 연결한다.
🎯 MVVM의 핵심 개념
- 커맨드(Command): 여러 UI 요소의 동작을 하나의 액션으로 처리할 수 있는 기법
- 데이터 바인딩(Data Binding):
→ 화면의 데이터와 실제 데이터의 값을 자동으로 동기화하는 방식
✅ MVVM의 장점
- 뷰와 로직이 완전히 분리되어 있어, 뷰를 쉽게 변경할 수 있다.
- 데이터 바인딩 덕분에 UI 코드를 최소화할 수 있다.
❌ MVVM의 단점
- 데이터 바인딩이 많아지면 디버깅이 어려울 수 있다.
- 프로젝트가 크면 ViewModel이 너무 비대해질 가능성이 있다.
🤔 그렇다면 MVVM이 MVP보다 더 좋은 걸까?
MVVM은 자동화된 데이터 바인딩을 제공하지만, 모든 프로젝트에서 필요하지는 않다.
특히 데이터 바인딩이 많아지면 성능 문제가 발생할 수도 있다.
🔥 세 가지 패턴 비교 정리
| 패턴 | 관계 | 참조 |
|---|---|---|
| MVC | 컨트롤러 ↔ 뷰 = 1:N | 뷰는 컨트롤러를 참조 ❌ |
| MVP | 프레젠터 ↔ 뷰 = 1:1 | 뷰는 프레젠터를 참조 ⭕ |
| MVVM | 뷰모델 ↔ 뷰 = 1:N | 뷰는 뷰모델을 참조 ⭕ |
각 패턴의 차이를 정리하니 조금 더 명확해졌다.
MVC, MVP, MVVM 모두 장단점이 있기 때문에, 프로젝트의 성격에 맞춰 선택하는 것이 중요하다.
🤔 그렇다면 Spring Boot 웹 애플리케이션에서는 어떤 패턴을 사용해야 할까?
Spring Web MVC를 보면 알 수 있듯이 기본적으로 MVC 패턴이 가장 적합하다.
하지만 클라이언트 UI가 복잡해지면, MVP나 MVVM이 더 적합할 수도 있다.
🏁 마무리하며...
이번 정리를 하면서 MVC, MVP, MVVM 패턴의 차이를 좀 더 명확히 이해할 수 있었다.