Quick Comparison

MVP는 presenter가 model 변화·사용자 입력·화면 전환을 명시적으로 연결하는 구조이고, MVVM은 viewmodel이 view용 property·command를 노출하고 binding이 동기화를 돕는 구조입니다. Unity 6 UI Toolkit의 runtime binding은 MVVM을 쉽게 만들 수 있지만, uGUI 또는 짧은 popup 흐름에 억지로 바인딩 계층을 추가할 이유는 없습니다.

Model: 게임 상태와 규칙을 소유한다.
View: button, label, visual tree를 표현한다.
Presenter/ViewModel: view가 필요한 형태로 state를 연결한다.

입력은 View -> Presenter 또는 command로 전달하고,
저장·전투 규칙을 View가 직접 바꾸지 않게 한다.

동기화 방식 선택

MVP에서 Presenter는 InventoryChanged를 구독해 view.ShowItems(...)를 호출하고, button click은 presenter method로 전달합니다. 흐름과 side effect가 코드에 보이므로 modal, retry, navigation, asynchronous purchase처럼 단계가 중요한 UI에 유리합니다. View가 destroy될 때 presenter가 listener를 해제하거나 disposable scope가 정리하는 책임을 둡니다.

MVVM에서 ViewModel은 모델을 그대로 노출하지 않고 label text, enabled state, validation message처럼 View가 사용할 상태를 제공합니다. UI Toolkit runtime binding은 C# object·ScriptableObject·MonoBehaviour data source의 property를 UI property에 연결할 수 있으며 ToTarget, TwoWay 같은 BindingMode와 update trigger를 고릅니다. binding은 business rule을 실행하는 권한이 아니라 state를 동기화하는 연결입니다.

성능과 수명주기

runtime binding을 매 frame 갱신하면 작은 HUD에서는 편하지만 복잡한 list나 값 타입 boxing이 많은 UI에서는 비용이 생길 수 있습니다. 자주 변하는 health bar는 적절한 trigger로 갱신하고, 드문 settings는 change detection 또는 dirty mark로 갱신합니다. binding을 끄거나 View를 닫을 때 data source, event, async request가 남지 않게 lifecycle을 확인합니다.

MVP와 MVVM을 같은 화면에 섞을 수도 있습니다. ViewModel이 표시 state를 제공하고 Presenter가 navigation·purchase approval·scene change처럼 workflow를 조정하면 됩니다. 다만 같은 label을 binding과 presenter가 동시에 쓰면 최종 값의 owner가 불명확해지므로 한 update path만 둡니다.

선택을 검증하기

UI architecture를 고를 때는 패턴 이름보다 state change 하나를 끝까지 추적합니다. 예를 들어 item 구매가 성공·실패·취소됐을 때 어떤 model이 바뀌고, 누가 UI를 갱신하며, 창을 닫은 뒤 callback이 어디서 취소되는지 확인합니다. 단순 toggle 화면은 direct binding 또는 작은 presenter가 더 읽기 쉬울 수 있습니다.