software-design
뉴스 방송을 보면 아나운서(View)는 화면에 정보를 전달하지만, 실제로 어떤 내용을 말할지 정하는 건 방송국 PD(Presenter)입니다. PD는 기자(Model)로부터 기사를 수집하고, 이를 가공하여 아나운서에게 전달해 방송을 진행하게 하죠. 아나운서는 단순히 보여주고 전달만 하며, PD는 정보를 조율하고, 기자는 데이터를 제공합니다. 이처럼 각자의 역할이 명확히 분리되어 협업하는 구조가 바로 MVP 패턴입니다.
MVP(Model-View-Presenter) 패턴은 사용자 인터페이스(View)와 비즈니스 로직(Model) 사이를 Presenter가 중재하는 구조로, MVC의 변형 중 하나입니다. View는 단순히 화면 요소를 담당하며, 로직을 직접 처리하지 않습니다. 대신 모든 사용자 이벤트를 Presenter로 전달하고, Presenter는 Model과 상호작용해 필요한 데이터를 가져오거나 수정한 후 그 결과를 View에 반영합니다.
MVP의 중요한 특징은 View가 Presenter에게만 의존한다는 점입니다. View는 직접 Model을 알지 못하고, Presenter는 View와 Model 양쪽을 알고 조율합니다. 따라서 View는 단순해지고, Presenter를 독립적으로 테스트할 수 있어 단위 테스트와 유지보수에 큰 장점을 제공합니다. 특히 Android 개발에서는 액티비티(Activity)와 프래그먼트(Fragment)의 생명 주기를 분리하고 UI 로직을 가볍게 유지하기 위해 널리 사용됩니다.
MVP는 MVC보다 뷰와 로직의 경계가 명확해져 협업과 테스트가 쉬워지는 장점이 있습니다. 다만 Presenter가 지나치게 많은 책임을 떠맡으면 코드가 비대해지고 복잡도가 커질 수 있으며, View와 Presenter 간의 의존성이 과도해질 경우 유지보수 비용이 증가할 수 있습니다. 따라서 MVP를 설계할 때는 Presenter의 역할을 적절히 분리하고, 관심사 분리를 철저히 지켜야 효과를 극대화할 수 있습니다.
MVC, MVP, MVVM은 모두 UI와 비즈니스 로직을 분리해 유지보수성과 확장성을 높이는 아키텍처 패턴이지만, 각기 다른 방식으로 역할을 나눕니다. MVC는 가장 단순한 구조로, Controller가 View와 Model을 동시에 다루지만 규모가 커질수록 결합도가 높아집니다. MVP는 Presenter를 중심으로 View를 단순화하여 테스트 용이성을 확보했지만, Presenter가 지나치게 비대해지는 단점이 있습니다. MVVM은 ViewModel과 데이터 바인딩을 활용해 View와 Model을 느슨하게 연결하며, 테스트와 재사용성에서 가장 강력하지만 바인딩 로직이 복잡해질 수 있습니다.
따라서 작은 규모의 프로젝트나 빠른 개발에는 MVC가, UI 테스트가 중요한 모바일/데스크톱 앱에는 MVP가, 데이터 바인딩과 상태 관리가 중요한 현대적 프론트엔드와 모바일 개발에는 MVVM이 적합합니다. 패턴을 맹목적으로 적용하기보다 팀의 기술 스택, 프로젝트 규모, 유지보수 요구사항을 고려해 선택하는 것이 가장 중요합니다.
| 구분 | MVC (Model-View-Controller) | MVP (Model-View-Presenter) | MVVM (Model-View-ViewModel) |
|---|---|---|---|
| 구성 요소 | Model, View, Controller | Model, View, Presenter | Model, View, ViewModel |
| 역할 분리 | Controller가 사용자 입력 처리 및 Model 업데이트 | Presenter가 View 이벤트 처리 및 Model ↔ View 중재 | ViewModel이 상태와 로직 관리, Data Binding으로 View ↔ Model 자동 연결 |
| View의 의존성 | View가 Controller를 알고, Controller는 Model과 View 양쪽을 다룸 | View는 Presenter에만 의존, Model은 Presenter를 통해 접근 | View는 ViewModel과만 연결 (데이터 바인딩 활용) |
| 데이터 흐름 | 단방향(사용자 입력 → Controller → Model → View 갱신) | 단방향(View → Presenter → Model → Presenter → View) | 양방향(View ↔ ViewModel ↔ Model) |
| 테스트 용이성 | Controller와 View가 밀접해 단위 테스트 어려움 | Presenter는 View와 분리 가능 → 테스트 용이 | ViewModel은 UI와 독립적 → 테스트 매우 용이 |
| 복잡도 | 단순하지만 대규모 프로젝트에서 Controller 비대화 | Presenter 비대화 가능성 있음 | Data Binding 관리 복잡성 증가 |
| 대표 사례/프레임워크 | Spring MVC, ASP.NET MVC, Django, Rails | Android 초기 아키텍처(MVP 패턴 적용) | WPF, Xamarin, Android Jetpack (ViewModel), Vue.js, Angular |
| 장점 | 구조 단순, 빠른 개발 | 뷰와 로직 분리 명확, 테스트 용이 | UI와 로직 강력한 분리, 코드 재사용성 ↑ |
| 단점 | Controller와 View 결합도 ↑, 대규모 확장 어려움 | Presenter 비대화 문제, 코드 복잡도 ↑ | Data Binding 과도 사용 시 디버깅 어려움, 러닝 커브 |