숏컷 코드
MVP
View는 표시
Presenter가 흐름 제어
MVVM
ViewModel이 상태/명령 노출
View는 바인딩 중심문법과 예시
게임 UI는 "그리기"보다 "상태 동기화"가 더 어렵다
HUD, 퀘스트 패널, 상점, 설정 화면은 버튼을 그리는 것보다 게임 상태와 UI 상태를 맞추는 일이 더 어렵습니다. MVP와 MVVM은 이 동기화 책임을 어디에 둘지 정하는 패턴입니다.
MVP는 Presenter가 흐름을 명시적으로 잡아 주는 구조다
uGUI처럼 코드에서 버튼 이벤트를 많이 연결하고 화면 전환 규칙이 명확할 때는 MVP가 읽기 쉽습니다. Presenter가 View와 Model 사이에서 입력을 받아 상태를 계산하고, View에 어떤 텍스트와 표시를 넣을지 결정합니다.
PlayerInventoryModel
-> InventoryPresenter
-> InventoryView.SetItems(...)MVVM은 바인딩이 강할수록 이점이 커진다
UI Toolkit이나 바인딩 레이어가 있는 환경에서는 ViewModel이 더 자연스럽습니다. ViewModel은 표시용 상태와 명령을 노출하고, View는 그 값을 구독하거나 바인딩합니다. 반대로 바인딩 도구가 약한데 MVVM만 흉내 내면 Presenter보다 더 우회적인 구조가 될 수 있습니다.
게임 UI는 순수한 MVVM보다 MVP 혼합형이 자주 나온다
설정 화면처럼 데이터 중심 UI는 MVVM에 가깝고, 인게임 HUD나 복잡한 팝업 흐름은 MVP가 더 읽기 쉬울 때가 많습니다. 그래서 Unity에서는 한 프로젝트 안에서도 화면별로 MVP/MVVM을 다르게 고르는 편이 자연스럽습니다.
핵심 질문은 "화면 흐름 제어"가 중심인지 "표시 상태 바인딩"이 중심인지다
확인 팝업, 상점 구매, 인게임 HUD처럼 사용자 입력과 화면 전환 흐름이 중요하면 Presenter가 더 분명합니다. 반대로 설정 화면, 리스트 표시, 상세 패널처럼 상태 동기화가 핵심이면 ViewModel 쪽이 더 자연스럽습니다.
UI 패턴을 고를 때 핵심
| 상황 | 적합한 선택 |
|---|---|
| 버튼 이벤트와 화면 흐름 제어가 핵심일 때 | MVP |
| 데이터 바인딩과 표시 상태 동기화가 핵심일 때 | MVVM |
| uGUI 기반으로 코드 연결이 많은 화면 | MVP 우선 |
| UI Toolkit + 바인딩 흐름이 강한 화면 | MVVM 검토 |
| 프로젝트 전체에서 한 패턴만 강제하기 어렵고 화면 성격이 다를 때 | 화면별 혼합 적용 |
특이 케이스와 주의할 점
흔한 실패는 바인딩 도구가 약한데도 MVVM 이름만 붙여서 ViewModel과 View를 억지로 우회 연결하는 것입니다. 반대로 모든 화면을 Presenter 하나로 제어하면 데이터 표시용 화면까지 과하게 절차적으로 흐를 수 있습니다.
실패 예시
- 단순 옵션 토글 화면인데
- ViewModel, Binder, Adapter, Mapper를 모두 따로 둠
결과
- 화면은 단순한데 구조 설명 비용만 커짐참고 링크
1 sources