소프트웨어 아키텍처 시리즈 4화 – MVC, MVP, MVVM의 차이와 선택 기준
MVC, MVP, MVVM은 UI 구조를 설계할 때 널리 사용되는 아키텍처 패턴입니다. 이 글에서는 세 패턴의 차이와 각각의 적용 맥락, 선택 기준을 실무 사례와 함께 깊이 있게 분석합니다.
왜 UI 패턴이 아키텍처에서 중요한가?
UI 패턴은 단지 화면 레이아웃을 나누는 것이 아닙니다. 사용자 인터랙션과 도메인 로직 간 경계를 어떻게 설정할 것인가라는 문제이자, 전체 애플리케이션 구조의 시발점이 됩니다.
특히 프론트엔드 아키텍처, MVVM 기반 앱 개발(예: Android), 데스크톱/웹 애플리케이션에서 설계 패턴을 어떻게 잡느냐에 따라 테스트 전략, 유지보수성, 팀의 생산성까지 달라집니다.
1. MVC (Model-View-Controller)
구조
- Model: 비즈니스 로직과 데이터 처리
- View: 사용자에게 보여지는 UI
- Controller: 사용자 입력 처리, Model과 View 연결
특징
- View가 Controller에 의존하고, Controller는 Model을 업데이트하거나 View를 갱신
- 초창기 **웹 프레임워크(Spring MVC, ASP.NET MVC 등)**에서 자주 채택됨
장점
- 구조가 단순하고, 개념적으로 이해하기 쉬움
- 많은 프레임워크가 기본 구조로 채택하고 있음
단점
- 규모가 커질수록 Controller가 비대해지고(View와 Model 간 로직이 섞임), 테스트가 어려워질 수 있음
- 실제 구현에서는 ‘Controller가 Model을 직접 조작하고 View를 호출’하는 식으로 결합도가 높아질 수 있음
2. MVP (Model-View-Presenter)
구조
- Model: 데이터 및 비즈니스 로직
- View: UI 요소(대개 인터페이스)
- Presenter: View와 Model 간의 중개자, 로직 중심
특징
- View는 수동 객체로, Presenter에게 모든 처리를 위임
- View는 Presenter 인터페이스만 알고 있음
- Presenter는 View 인터페이스를 통해 화면을 업데이트
장점
- 테스트 용이성 ↑ (Presenter 단독 테스트 가능)
- View와 로직이 완전히 분리되어 모듈화에 유리
단점
- UI가 복잡할 경우 Presenter도 커지기 쉬움 (거대 Presenter 문제)
- 코드 양이 많아짐 (인터페이스, 바인딩 등)
주요 활용 예
- 구형 Android 앱 개발 (안드로이드 SDK 초기에는 공식 구조가 없어 MVP가 대안으로 채택됨)
- 데스크톱 앱, .NET WinForms 등 이벤트 중심 UI에 적합
3. MVVM (Model-View-ViewModel)
구조
- Model: 데이터, 비즈니스 로직
- View: UI (XAML, HTML 등)
- ViewModel: 상태 관리 및 바인딩 중심 로직
특징
- **View와 ViewModel 간 양방향 바인딩(data-binding)**을 지원
- View는 ViewModel의 속성을 자동 감지하고 반영
장점
- 코드량 감소 (바인딩 기반 자동 UI 갱신)
- ViewModel 테스트가 쉬움 (View에 의존하지 않음)
- 반응형 UI/상태 관리에 매우 적합
단점
- 바인딩의 복잡성 (디버깅 어려움, 무한 루프 이슈)
- 메모리 누수 가능성 (이벤트 리스너 제거 누락 시)
주요 활용 예
- Android Jetpack, WPF(XAML), React + MobX/Redux
- 단방향 또는 양방향 상태 관리가 중요한 SPA
실제로는 혼합되는 경우가 많다
현대 애플리케이션은 다음과 같은 식으로 복합 구조를 갖는 경우가 많습니다.
- React의 경우 MVVM보다는 View + 상태 컨테이너 구조로 해석하는 게 더 맞습니다.
- iOS에서는 MVC 구조를 기본으로 하지만 실제로는 MVVM으로 확장하거나 VIPER 구조를 선택하기도 합니다.
- Android는 공식적으로 MVVM을 권장하지만, 일부는 여전히 MVP 스타일을 선호합니다.
즉, “정답은 없다”가 실무 현실이며, 플랫폼, 프레임워크, 팀의 역량과 유지 전략에 따라 적합한 패턴을 골라야 합니다.
선택 기준: 무엇을 기준으로 고를 것인가?
조건 추천 패턴
| 간단한 CRUD 중심 | MVC |
| 테스트 가능한 중간 계층 필요 | MVP |
| 바인딩 기반 상태 관리 강조 | MVVM |
| 팀의 바인딩 경험 부족 | MVP, MVC |
| 상태 공유가 복잡하고 반응성 강조 | MVVM (Redux, MobX 포함) |
모르면 모른다고 해야 할 부분
“MVC, MVP, MVVM 중 어떤 게 가장 좋은가요?”라는 질문은 정답이 없습니다.
실제로는 ‘패턴 자체보다 구현 방식’이 더 큰 영향을 끼치며, MVVM이라고 해서 항상 더 나은 것도 아닙니다. MVVM은 강력한 바인딩이 장점이지만, 실무에서는 이로 인한 디버깅 복잡도나 성능 이슈도 자주 발생합니다.
즉, 구조보다 구현과 운영 전략이 아키텍처 품질을 좌우합니다.
마무리하며
MVC, MVP, MVVM은 모두 UI의 책임 분리와 로직 관리를 위한 훌륭한 접근입니다. 다만, 이들 패턴을 맹목적으로 적용하기보다는, 어떤 문제가 있고 어떤 제약 조건이 있는지를 먼저 정의한 뒤, 가장 잘 맞는 구조를 선택하는 것이 진짜 아키텍처 설계입니다.
다음 화에서는 이제 클린 아키텍처와의 접점으로 확장해 나가기 위해, 계층형 구조와 책임 분리 원칙을 다시 한번 심화해서 다루는 회차로 이어가겠습니다.