Unity 프로젝트에서 일반적인 게임 프로그래밍 디자인 패턴을 구현하면 깔끔하고 체계적이며 가독성 높은 코드베이스를 효율적으로 빌드하고 유지 관리할 수 있습니다. 디자인 패턴은 리팩터링과 테스트 시간을 줄여 개발 프로세스의 속도를 높이고 게임, 팀, 비즈니스의 성장을 위한 탄탄한 기반을 마련합니다.
디자인 패턴은 코드에 복사하여 붙여넣을 수 있는 완성된 솔루션이 아니라 더 크고 확장 가능한 애플리케이션을 구축하는 데 도움이 되는 추가 도구라고 생각하세요.
이 페이지에서는 MVC(모델 뷰 컨트롤러) 및 MVP(모델 뷰 프레젠터) 디자인 패턴에 대해 설명합니다.
이 콘텐츠는 무료 전자책을 기반으로 합니다, 게임 프로그래밍 패턴으로 코드 레벨 업하기.
Unity 게임 프로그래밍 디자인 패턴 시리즈에 대한 자세한 내용은 Unity 베스트 프랙티스 허브 또는 다음 링크를 통해 확인할 수 있습니다:
MVC(모델 뷰 컨트롤러) 및 MVP(모델 뷰 프레젠터) 디자인 패턴을 사용하여 애플리케이션의 데이터와 로직을 표시되는 방식과 분리할 수 있습니다. 이러한 패턴은 '관심사 분리' 원칙을 적용하여 코드베이스의 유연성과 유지보수성을 향상시킬 수 있습니다.
Unity 게임 개발에서는 이러한 패턴을 사용하여 게임의 로직을 데이터(모델), 시각적 표현(뷰), 둘 사이의 상호작용을 제어하는 로직(컨트롤러 또는 프레젠터)과 같은 별개의 컴포넌트로 분리할 수 있습니다.
MVC는 소프트웨어 애플리케이션에서 사용자 인터페이스를 개발할 때 일반적으로 사용되는 디자인 패턴 제품군입니다.
MVC의 일반적인 개념은 소프트웨어의 논리적 부분을 데이터와 프레젠테이션에서 분리하는 것입니다. 이렇게 하면 불필요한 종속성을 줄이고 잠재적으로 스파게티 코드를 줄일 수 있습니다.
이름에서 알 수 있듯이 MVC 패턴은 애플리케이션을 세 개의 레이어로 분할합니다:
모델에 데이터를 저장합니다: 모델은 엄밀히 말해 값을 저장하는 데이터 컨테이너입니다. 게임플레이 로직을 수행하거나 계산을 실행하지 않습니다.
보기는 인터페이스입니다: 보기는 화면에서 데이터의 형식을 지정하고 그래픽 프레젠테이션을 렌더링합니다.
컨트롤러는 로직을 처리합니다: 이것을 두뇌라고 생각하세요. 게임 데이터를 처리하고 런타임에 값이 어떻게 변하는지를 계산합니다.
이러한 관심사 분리는 이 세 부분이 서로 상호 작용하는 방식도 구체적으로 정의합니다. 모델은 애플리케이션 데이터를 관리하고, 보기는 해당 데이터를 사용자에게 표시합니다. 컨트롤러는 입력을 처리하고 게임 데이터에 대한 모든 결정이나 계산을 수행합니다. 그런 다음 결과를 모델로 다시 보냅니다.
컨트롤러는 그 자체로 게임 데이터를 포함하지 않습니다. 보기도 마찬가지입니다. MVC 설계는 각 계층이 수행하는 작업을 제한합니다. 한 부분은 데이터를 보관하고, 다른 부분은 데이터를 처리하며, 마지막 부분은 사용자에게 해당 데이터를 표시합니다.
표면적으로는 단일 책임 원칙의 연장선상에서 생각할 수 있습니다. 각 파트는 한 가지 일을 잘 수행하며, 이는 MVC 아키텍처의 주요 장점입니다.
MVC로 Unity 프로젝트를 개발할 때 기존 UI 프레임워크( UI 툴킷 또는 Unity UI)는 자연스럽게 뷰로 작동합니다. 엔진에서 완벽한 사용자 인터페이스 구현을 제공하므로 개별 UI 컴포넌트를 처음부터 개발할 필요가 없습니다.
그러나 기존 MVC 패턴을 따르려면 런타임에 모델 데이터의 변경 사항을 수신하기 위해 뷰별 코드가 필요합니다.
이 방식도 유효한 접근 방식이지만, 많은 Unity 개발자는 컨트롤러가 중개자 역할을 하는 MVC의 변형을 사용합니다. 여기서 뷰는 모델을 직접 관찰하지 않습니다. 대신 위 다이어그램과 같은 작업을 수행합니다.
이러한 MVC의 변형을 모델 뷰 프레젠터 디자인 또는 MVP라고 합니다. MVP는 여전히 세 가지 애플리케이션 계층으로 우려 사항을 분리하여 유지합니다. 하지만 각 파트의 책임이 조금씩 달라집니다.
MVP에서 프레젠터(MVC에서는 컨트롤러라고 함)는 다른 계층의 중개자 역할을 합니다. 모델에서 데이터를 검색한 다음 뷰에 표시할 수 있도록 서식을 지정합니다. MVP는 입력을 처리하는 레이어를 전환합니다. 컨트롤러가 아닌 뷰가 사용자 입력을 처리합니다.
이벤트와 관찰자 패턴이 이 디자인에 어떻게 적용되는지 주목하세요. 사용자는 Unity UI의 버튼, 토글, 슬라이더 컴포넌트와 상호작용할 수 있습니다. 보기 레이어는 UI 이벤트를 통해 이 입력을 다시 발표자에게 전송하고 발표자는 모델을 조작합니다. 모델의 상태 변경 이벤트는 발표자에게 데이터가 업데이트되었음을 알려줍니다. 발표자는 수정된 데이터를 뷰에 전달하고, 뷰는 UI를 새로 고칩니다.
MVP의 변형을 구현하는 방법의 예를 포함하여 다양한 프로그래밍 디자인 패턴을 보여주는 샘플 프로젝트는 Github에서 확인할 수 있습니다.
MVP 예시는 캐릭터나 아이템의 상태를 보여주는 간단한 시스템으로 구성되어 있습니다. 이 예시에서는 데이터와 UI가 혼합된 하나의 클래스에 모든 것이 포함되어 있지만 실제 프로덕션에서는 잘 확장되지 않습니다. 더 많은 기능을 추가하면 확장해야 하므로 더 복잡해집니다. 또한 테스트와 리팩토링은 많은 오버헤드를 초래할 수 있습니다.
대신 스크립트를 헬스 및 헬스 프레젠터로 나누는 것부터 시작하여 보다 MVP 중심적인 방식으로 헬스 컴포넌트를 다시 작성할 수 있습니다.
샘플 프로젝트에서 슈팅 디스크로 표시된 대상 오브젝트를 클릭하여 손상시키거나(ClickDamage.cs), 버튼으로 생명력을 초기화할 수 있습니다. 이러한 이벤트는 생명력을 직접 변경하는 것이 아니라 ( 데미지 또는 리셋을 호출하는) 생명력 발표자에게 알려줍니다. UI 텍스트와 UI 슬라이더는 체력이 이벤트를 발생시키고 그 값이 변경되었음을 헬스프레젠터에 알릴 때 업데이트됩니다.
건강 컴포넌트가 어떤 모습인지 자세히 살펴보겠습니다. 이 버전에서는 건강이 모델 역할을 합니다. 실제 건강 값을 저장하고 해당 값이 변경될 때마다 HealthChanged 이벤트를 호출합니다. 생명력에는 게임플레이 로직이 포함되지 않고 데이터를 증가 및 감소시키는 메서드만 있습니다.
이를 통해 데이터, 데이터 표시 방식, 데이터 제어 방식을 명확하게 구분할 수 있습니다.
MVP(및 MVC)는 규모가 크고 UI가 많은 소프트웨어 애플리케이션에서 그 진가를 발휘하지만 이러한 사용 사례에만 국한되는 것은 아닙니다. 게임을 개발하는 데 상당한 규모의 팀이 필요하고 출시 후에도 오랫동안 게임을 유지해야 하는 경우 다음과 같은 이점이 있을 수 있습니다:
원활한 업무 분담: 프레젠터에서 뷰를 분리했기 때문에 사용자 인터페이스 개발 및 업데이트가 나머지 코드베이스와 거의 독립적으로 이루어질 수 있으므로 전문 개발자 간에 업무를 분담할 수 있습니다. 팀에 전문 프런트엔드 개발자가 있나요? 뷰를 관리하게 하세요.
MVP 및 MVC로 간소화된 단위 테스트: 이러한 디자인 패턴은 게임플레이 로직과 사용자 인터페이스를 분리합니다. 따라서 실제로 에디터에서 플레이 모드로 전환하지 않고도 오브젝트를 시뮬레이션하여 코드와 함께 작동할 수 있습니다. 이렇게 하면 상당한 시간을 절약할 수 있습니다.
유지 관리가 가능한 가독성 있는 코드: 이 디자인 패턴으로 더 작은 클래스를 만들면 더 읽기 쉬운 클래스를 만들 수 있습니다. 종속성이 적다는 것은 일반적으로 소프트웨어가 고장날 수 있는 곳이 적고, 버그를 숨길 수 있는 곳이 적으며, 테스트가 더 쉬워진다는 것을 의미합니다.
MVC와 MVP는 웹 개발이나 엔터프라이즈 소프트웨어에서 널리 사용되고 있지만, 애플리케이션의 규모와 복잡성이 충분히 커질 때까지는 그 이점이 분명하게 드러나지 않는 경우가 많습니다. Unity 프로젝트에서 두 패턴을 구현하기 전에 다음 사항을 고려해야 합니다:
미리 계획을 세워야 합니다: MVC와 MVP는 더 큰 아키텍처 패턴입니다. 이 중 하나를 사용하려면 책임별로 클래스를 분할해야 하므로 어느 정도 정리가 필요하고 사전에 더 많은 작업이 필요합니다. 디자인 패턴은 일관성 있게 사용하는 것이 가장 좋으므로 UI를 구성하는 방법을 정립하고 팀원들이 이에 동참하도록 하는 것이 좋습니다.
Unity 프로젝트의 모든 항목이 이 패턴에 맞는 것은 아닙니다: "순수한" MVC 또는 MVP 구현에서는 화면에 렌더링되는 모든 것이 실제로 뷰의 일부입니다. 모든 Unity 컴포넌트가 데이터, 로직, 인터페이스(예: 메시렌더러)로 쉽게 분할되는 것은 아닙니다. 또한 단순한 스크립트에서는 MVC/MVP의 이점을 많이 얻지 못할 수도 있습니다.
패턴을 통해 가장 큰 이점을 얻을 수 있는 위치를 판단해야 합니다. 일반적으로 단위 테스트가 안내해 줍니다. MVC/MVP가 테스트를 용이하게 할 수 있다면 애플리케이션의 해당 측면에 대해 고려하세요. 그렇지 않으면 프로젝트에 패턴을 강제로 적용하지 마세요.
무료 전자책에서 SOLID 원칙뿐만 아니라 Unity 애플리케이션에서 디자인 패턴을 사용하는 방법에 대한 더 많은 팁을 확인할 수 있습니다. 게임 프로그래밍 패턴으로 코드 레벨 업.
Unity UI 및 UI 툴킷 사용에 대한 자세한 안내가 필요한 경우 광범위한 가이드를 참조하세요, Unity에서 사용자 인터페이스 디자인 및 구현 가이드를 참조하세요.
모든 고급 Unity 기술 전자책과 문서는 베스트 프랙티스 허브에서 확인할 수 있습니다. 이 전자책은 문서 내 고급 모범 사례 페이지에서도 확인할 수 있습니다.