MVP 개념에 대해
본격적으로 코드를 작성하기 전에 구조에 대한 컨셉트에 대해 이야기 할 필요가 있다.
MVP와 MVVM
정석적인 MVP에 대해
정석적인 MVP라고 한다면, Model, View, Presenter를 각각 만들고 서로에 대해 의존성을 떨어뜨리기 위해 서로 구체적인 구현을 고려하지 않고 Interface만을 통해서 통신하는 구조로 만들어야만한다.
이는 각각의 UI 요소에 대한 재활용성을 고려한 설계이며, 프로젝트 전체적으로 재사용될만한 UI 구조가 많은 경우에 매우 유효한 방식이다.
그러나 이렇게 설계를 하는데에는 상당한 시간/노력이 발생한다.
정석적인 MVVM에 대해
MVVM은 Presenter측에서 view측에 데이터를 일일히 수정하는 수고를 덜어내는데 큰 방점이 있는 방식이다.
View Model 측에서 View와 Model의 데이터를 서로 바인딩 함으로서, Model의 값 변화가 원하는 타이밍에 바로바로 View측의 UI에 바로 표시되도록 한다.
정통적인 방식의 문제에 대해
Unity 게임의 특성
게임이라는 프로그램의 특성상 일반적인 앱이나 웹과는 다르게 재사용되는 UI 구조가 거의 없다.
정확히 표현하자면 여러 화면에 걸쳐 재사용되는 UI컴포넌트, 즉, MVP를 뽑아내는데 어려움이 많다.
그리고 기획적으로 조금만 달라지더라도, 큰 범위의 수정이 필요한 경우가 많다.
이때 오히려 정통적인 방식의 엄격한 MVP, MVVM 구현이 오히려 프로젝트 진행의 발목을 잡는 경우가 많다.
MVVM과 UGUI
MVVM의 핵심인 데이터 바인딩은 UI 프레임워크 레벨에서 반드시 지원해주어야 구현이 가능하다.
UGUI는 이를 전혀 고려하지 않고 설계된 UI 프레임워크이다. (최근 유니티에서 푸시하고 있는UIToolKit은 이를Unity6 LTS에서 부터 지원하나, 아직UIToolKit은 실 제품에 사용하기에는 미완성인 프레임워크이다.)또한 UI에 데이터를 바인딩한다는 것은 퍼포먼스 이슈와도 깊게 관련되어있다. (일반 앱/웹 보다 이 퍼포먼스 이슈에 게임은 훨씬 큰 영향을 받는다)
나는 이렇게 하기로 정했다.
이렇게 하는게 반드시 옳다고 주장하는것이 아니다. 가장 중요한 것은 일관된 구조를 팀내에서 협의하고 이를 프로젝트 전체에 일관되게 적용하는것이라고 생각한다. 그런 부분에 있어서 나는 이 구조가 경험적으로 가장 효율성이 있었다고 제안하는 것이다. 만약, 당신의 프로젝트가 내가 경험해 온 게임 프로젝트와 다른 특성이 있고 이 때문에 다른 구조를 사용하는것이 더 효율적이라면 그렇게 팀내에서 협의해서 결정하면 된다.
MVP는 서로 한 세트
MVP를 구현할때 다른곳에서 사용될 수 있다는 가능성을 배제하고, MVP의 한 세트로 작성한다.
한 화면에 Model은 반드시 한개, View는 반드시 한개, Presenter는 반드시 한개.
즉, 인터페이스등을 사용하여 공용 로직부분을 추출하지 않는다.
기획이 바뀌면 그 한 세트만 수정하면 되고, 다른 화면의 UI에 영향을 주지 않는다.
이렇게 함으로서 오히려 빠른 개발 사이클을 진행할 수 있고, 빠른 수정이 가능하다는 것을 경험한 바 있다.
MVRP 사용
UniTask나 UniRx(R3) 등에서 지원하는 ReactiveProperty 등을 이용하여 UI에 데이터를 일종의 바인딩을 한다.
공용로직 추출은 나중에
프로젝트를 진행하다가 정말 공용되는 UI가 반복적으로 2-3회 이상 사용된다고 판단되면 그때 그 부분을 인터페이스로 추출해도 늦지 않다.
MVP & MVVM의 하이브리드
위 두 방식을 사용함으로서, 게임이라는 도메인 특성에 맞는 UI 코드 구조를 갖추었다고 생각한다.
Last updated