미공개 모바일 2D 게임 (개인)

개발 진행중

VContainer + R3 기반 MVrP 구조로 개발 중인 모바일 2D 게임입니다. Firebase 서버리스 백엔드. 공개 전 사이드 프로젝트입니다.

역할: 1인 개발 (진행중)
기간: 2026.07 ~ 진행중
플랫폼: Android · iOS

UnityC#VContainerR3MVrPFirebase

30초 요약

실무에서 UniRX·Zenject 기반 MVrP를 다룬 경험을 바탕으로, 차세대 스택인 R3 + VContainer로 같은 패턴을 재구축하며 개발 중인 모바일 2D 게임입니다. 백엔드는 Firebase 서버리스로 구성했습니다. 공개 전 프로젝트라 상세 내용과 영상은 준비 중입니다.

기술적 도전

UniRX·Zenject에서 R3·VContainer로 — 스택 세대 교체 선행 검증

증상: 라이브러리에도 세대가 있습니다. 실무에서 UniRX·Zenject로 MVrP 구조를 다뤘지만, UniRX는 이미 deprecated되었고 Cysharp의 후속 스택은 R3로 이동했습니다. 팀 프로젝트에 검증되지 않은 스택을 바로 도입할 수는 없으니, 개인 프로젝트에서 먼저 써보기로 했습니다.
조치: R3를 UniRX의 후속으로, VContainer를 Zenject의 경량 대안으로 채택해 같은 MVrP 패턴을 처음부터 다시 구성했습니다. 실무에서 익힌 구조를 그대로 옮기면서 라이브러리만 교체해, 스택 자체의 차이를 분리해서 관찰할 수 있게 했습니다.

결과

R3·VContainer 조합 위에서 동일한 MVrP 구조가 동작함을 확인했습니다. 두 스택의 세부 비교는 개발을 진행하며 이 카드에 축적합니다.

왜 MVrP인가 — Unity UI 아키텍처 선택의 이유

증상: Unity의 UI는 코드가 아니라 프리팹과 컴포넌트로 구성됩니다. View를 코드로 완전히 추상화하기 어렵고, MVVM의 데이터 바인딩을 가져오려면 별도 바인딩 프레임워크가 필요하며, 아무 패턴 없이 두면 View에 로직이 섞여 테스트하기 어려워집니다.
조치: Presenter가 View를 직접 참조하고 Reactive Property 스트림으로 값을 밀어넣는 MVrP(Model-View-(Reactive)Presenter)를 채택했습니다. 상태 변경이 곧 스트림이 되므로 Update() 폴링이나 수동 Refresh() 호출 없이 갱신 타이밍이 선언적으로 결정되고, Unity의 프리팹 구조와도 마찰이 없습니다.
버린 대안: MVVM — 바인딩 프레임워크 의존이 추가되는 비용 대비, 2D 모바일 게임 규모에서 얻는 이점이 크지 않다고 판단했습니다.

결과

View에 로직이 남지 않아 Presenter를 테스트 대상으로 분리할 수 있는 구조를 확보했습니다.