https://www.youtube.com/watch?v=3SyLjKieNsI
1. 🌧️ 여름 비와 프로그래밍 패턴 소개
-
알쓸유잡은 3개월째 프로그래밍 패턴에 대한 내용을 다루고 있으며, 오늘은 그 세 번째 회차로 진행된다.
-
지금까지 여섯 가지의 프로그래밍 패턴을 살펴보았고, 유니티에서의 활용 방법도 데모를 통해 보여주었다.
-
최근 여름철에 비가 많이 오는 현상에 대해 농담을 주고받는 대화를 나누며 분위기를 풀었다.
2. 🏗️ UI 디자인 패턴: MVC, MVP, MVVM
-
오늘 다룰 내용은 MVC와 MVP, 그리고 MVVM으로, 이들 모두 UI/UX 관련 패턴이다.
-
MVC, MVP, MVVM은 서로 연결된 세트처럼 다뤄지며, UI 기반으로 적용된 패턴이다.
-
UI 패턴들은 과거 텍스트 기반의 도스 시대와 달리 오늘날의 화려한 그래픽 디자인을 위해 개발되었으며, 각기 다른 역할 분담이 필요해졌다.
-
주목할 점은 이 패턴들이 로직과 UI를 분리하여 서로 독립적으로 작동할 수 있도록 돕는다는 것이다.
-
이러한 패턴은 단순한 클래스 기준이 아닌, 관심사 분리(Separation of Concerns) 원칙에 따라 구조적, 개념적으로 나눠진다.
3. 🖥️ MVP와 MVC 디자인 패턴 비교
-
MVP 패턴은 모델과 뷰의 의존성을 없애고, 프레젠터가 중재 역할을 수행하는 구조로 되어 있다. 프레젠터는 사용자의 입력을 처리하고, 모델의 상태 변화를 뷰에 반영한다.
-
MVC 패턴은 모델, 뷰, 컨트롤러로 구성되며, 각각의 구성 요소가 서로의 상태를 알고 있어 의존성이 존재한다. 그러나 특정 경우에는 이러한 의존성이 유지되기 어려울 수 있다.
-
MVP에서 뷰는 모든 사용자 입력을 직접 처리하며, 그 결과를 프레젠터에게 전달하고, 프레젠터는 모델의 상태를 변경하고 뷰를 업데이트한다.
-
MVC는 주요 구성 요소 간의 역할이 분명하고 각 구성 요소의 기능이 제한되어 있으며, 특히 데이터와 프레젠테이션의 분리를 강하게 주장한다.
-
두 패턴 모두 스파게티 코드를 방지하고, 코드의 모듈성과 유지 관리성을 높이기 위한 구조로 설계되어 있다. 그러나 MVP는 모델과 뷰의 완전한 분리로 더욱 확장성이 좋고, 디버깅이 용이하다는 장점이 있다.
-
아키텍처와 아키텍처 패턴은 서로 연관되어 있으며, 특히 버전 컨트롤 시스템에서 중요한 역할을 한다.
-
예전 버전의 에디터인 콜라보레이터는 MVP 패턴을 적용한 구조로 설계되어 있다.
-
콜라보레이터 프로그램은 클라이언트 코드에서 뷰와 프레젠터로 나뉘며, 모델은 서버에 존재한다.
-
버전 컨트롤 시스템은 클라이언트 측에서 뷰만을 보여주고, 모든 로직은 서버에서 처리된다.
-
현대의 디자인 패턴들은 아키텍처 패턴으로 구분되며, 특정 기능이 백엔드와 프론트엔드로 나뉘어 운영되곤 한다.
-
MVP와 같은 디자인 패턴은 스파게티 코드를 방지하기 위해 구조적으로 코드를 나누고 체계적으로 작성하는 것을 지향한다.
-
디자인 패턴을 적용하지 않고 코드를 작성하면 쉽게 스파게티 코드로 변질될 수 있다.
-
스파게티 코드란 구조가 복잡하고 비효율적인 코드를 의미하며, 이는 코드 유지보수를 어렵게 만든다.
-
최근 AI 기술이 발전함에 따라 프롬프트에 따라 생성된 코드도 스파게티 형태로 나올 수 있다.
-
AI의 발전으로 인해 코드 생성 과정에서 다양하고 신선한 결과물을 얻을 수 있게 되었다.
-
현재 방송을 보고 있는 사람들은 주로 신입 혹은 지망생으로, 이들은 디자인 패턴에 관심이 많고 MVP, MVC 패턴을 당장 사용할 필요가 있다.
-
게임 업계는 프로급 개발자가 아닌 이상 UI 작업을 꺼리는 경향이 있어서, UI는 신입에게 맡기는 경우가 많다.
-
앱이나 웹에서는 UI/UX의 중요성이 크지만, 게임 쪽은 인게임 로직이 메인이며 UI 작업 선호도가 낮다.
-
신입들이 회사에 입사하면 MVP, MVC 같은 패턴을 곧바로 사용하게 될 가능성이 높고, 이는 면접에서도 유용하게 작용할 수 있다.
-
UI와 UX 디자인은 프레임워크에 크게 의존하고 있으며, 사용하는 플랫폼에 따라 결과물이 다를 수 있다.
-
실제로 UI를 처음부터 끝까지 생으로 만드는 경우는 거의 없거나 아예 없다고 보는 것이 맞다.
-
예를 들어, 임베디드 업계에서는 주로 Qt를 사용하고, MFC는 과거의 기술로, 30년 전에 만들어진 클래스 기반 구조를 가지고 있다.
-
MFC의 구조는 MVC 패턴과 가깝도록 설계되어 있으며, WPF는 데이터 바인딩을 통해 MVVM을 적용할 수 있도록 되어 있다.
-
다른 예시로, 유니티의 UI는 기본적으로 제공되는 시스템을 활용해 개발되며, 이 안에서도 MVP와 같은 디자인 패턴을 적용할 수 있다.
-
MVC와 MVP는 프로그래밍 패턴의 예제로 존재하며, 이와 관련된 여러 데모를 보여준다.
-
제공되는 데모는 12개의 예제가 포함되어 있으며, 각각 패턴을 다룬다.
-
예제로는 싱글톤, 단일 책임 원칙, 스테이트 패턴, MVP 패턴 등이 있으며, 이들을 통해 샘플을 확인할 수 있다.
-
현재 함께 볼 데모는 MVP 패턴으로, 간단한 게임 형태로 구성되어 있다.
-
이 데모는 헬스 캐릭터를 모델로 하여 요청 예시를 보여주며, 실제로 응용 분야가 많다.
-
게임 오브젝트는 모델, 뷰, 프레젠터로 명확하게 나눠져 있다.
-
뷰는 UI 및 UX/UI 측면을 담당하고 있다.
-
프레젠터는 중재 역할을 하며, 뷰와 모델 간의 상호작용을 관리한다.
-
모델은 관련 데이터인 헬스를 포함하고 있다.
-
이러한 구조는 프로그래밍에서 명확한 역할 분담을 통해 알기 쉬운 코드를 가능하게 한다.
-
MVC는 모델(Model), 뷰(View), 컨트롤러(Controller)로 구성된 소프트웨어 설계 패턴이다.
-
모델은 애플리케이션의 데이터를 관리하고 보관하는 역할을 하며, 실제 계산을 수행하지 않는다.
-
뷰는 데이터를 사용자에게 표시하는 그래픽적인 UI 요소를 담당하며, 사용자에게 보여지는 화면 구성요소이다.
-
컨트롤러는 사용자 입력을 처리하고, 로직을 관리하여 모델에 전달하며, 이를 통해 뷰와의 상호작용을 조정한다.
-
MVC 패턴은 단일 책임 원칙을 지키려 하지만, 실제 개발에서는 서로의 의존 관계를 끊는 것이 어려운 한계가 있어, 이로 인해 MVP와 같은 발전된 형태로 넘어간다.
-
MVP 패턴에서는 모델과 뷰가 서로 직접적으로 상호작용하지 않으며, 중재자 역할을 수행하는 프레젠터가 그 사이를 연결한다.
-
뷰는 사용자 입력 이벤트를 처리하고 이를 프레젠터로 전달하여, 프레젠터가 모델을 업데이트하는 방식으로 작동한다.
-
MVP는 사용자 입력 처리를 뷰 단계에서 수행하는데 반해, MVC는 컨트롤러에서 처리가 이루어진다.
-
모델과 뷰의 분리는 코드 관리와 확장성을 높여 주며, 모듈성과 코드 디버깅이 수월하다.
-
이러한 구조는 스파게티 코드가 될 확률을 줄여주고, 재사용성과 유지 관리성을 향상시킨다.
-
데모는 코드가 간단하게 구성되어 있으며, MVP 패턴의 기본적인 구조를 보여주기 위해 심플한 프로젝트로 만들어졌다.
-
헬스 모델은 헬스 데이터만 보유하고 있으며, 게임 로직은 최소화되어 데이터 처리에만 중점을 두고 있다.
-
옵저버 패턴을 통해 모듈 간 이벤트로 통신하며, 패턴을 만들 때 여러 가지가 조합되어 사용할 수 있다.
-
각 요소들은 프레젠터를 통해 중재되며, 더 복잡한 로직을 구현할 수 있도록 동작한다.
-
MVP 패턴은 뷰와 모델을 서로 분리하여 유지보수성을 높이고, 사용자 입력을 뷰에서 처리하여 코드를 학습하기 쉽게 만든다.
4. 💻 MVVM 패턴의 이해와 특징
-
MVVM(모델-뷰-뷰모델)은 모델과 뷰의 변화를 잇는 중재자로서 뷰모델의 역할에 주목해야 한다.
-
MVVM은 MVP 및 MVC 패턴보다 모델과 뷰의 종속성을 최소화하여, 뷰와 뷰모델 사이의 강한 연결을 끊고자 한다.
-
MVVM에서는 데이터 바인딩을 통해 뷰와 뷰모델을 연결하며, 데이터 변경 시 UI가 자동으로 갱신된다.
-
MVVM 패턴은 테스트의 용이성을 고려해 뷰모델이 뷰에 대한 직접적인 참조를 가지지 않는 구조로 설계된다.
-
게임 개발보다는 웹 개발 프레임워크(예: Angular, Vue.js, React)에서 MVVM 패턴이 더 많이 활용되고 있다.
5. 🎮 스테이트 패턴의 이해와 적용
-
스테이트 패턴은 다양한 상태들 간의 전환을 관리하며 시스템의 행동을 수정할 수 있는 디자인 패턴이다.
-
이 패턴은 유연한 상태 전환과 코드 유지보수의 용이성을 제공하지만, 클래스 수가 증가하여 복잡성이 증가할 수 있다.
-
UI 프로젝트에서는 각각의 상태(예: 메뉴 화면, 플레이 화면) 간의 전환과 관계를 정의하는 것이 가능하다.
-
상태에 대한 전환 조건과 링크를 관리하여 화면 전환을 제어하며, 이는 코드로 구현되고 있으며 확장성을 높인다.
-
스테이트 패턴은 UI와 같은 다양한 분야에 적용할 수 있으며, 실수로 잘못된 상태로의 전환을 미연에 방지할 수 있다.
-
스테이트 패턴은 여러 가지 상태 간의 전환을 다루는 디자인 패턴이다.
-
스테이트 패턴은 상태 객체의 내부에 따라 시스템 행동을 변경하고 각 상태를 캡슐화하는 방법으로 동작한다.
-
예를 들어, 캐릭터 애니메이션과 AI에 적용되는 사례가 있다.
-
이 패턴의 장점은 상태 전환이 유연하고 관리 및 확장이 용이해진다는 점이다.
-
하지만 클래스 수가 증가하며 복잡성이 증가할 수 있는 단점도 존재한다.
-
UI 프로젝트는 여러 상태(예: 메뉴 화면, 플레이 화면 등)를 가지며, 이러한 상태들 간의 전환이 필요하다.
-
각 화면에 따른 상태 전환 조건이 있으며, 예를 들어 로딩 화면에서 대기 화면으로 넘어가는 구조가 있다.
-
Finite State Machine (FSM)이나 스테이트 패턴을 통해 UI의 상태 전환을 효율적으로 관리할 수 있다.
-
UI의 확장성이 용이해져 새로운 화면이나 기능이 추가될 때 효과적으로 적용할 수 있다.
-
상태 관리로 인해 실수로 잘못된 화면으로 넘어가는 것을 방지할 수 있는 장점이 있다.
-
스테이트 인터페이스는 기본 형태이며 기존의 몬스터 AI와 유사한 메커니즘을 활용한다. 그러나 이번 모듈에서 추가된 요소는 밸리데이터와 링크다.
-
화면 전환은 이전 구현과 달리 직접 생성해야 하며, 링크 조건과 관련된 여러 함수가 존재한다.
-
상태 간 전환 조건은 여러 개의 링크를 통해 이루어지며, 이를 리스트 형태로 관리하여 접근 가능하다.
-
로딩 화면과 이벤트 발생 시 관련된 링크를 통해 상태가 무조건적으로 전환된다.
-
마지막 상태에서는 단순히 뒤로 넘어가는 링크만 존재하며, 스테이트 머신은 계속해서 현재 상태의 전환 조건을 체크하여 다음 상태로 이동한다.
-
세팅 버튼과 메뉴 버튼을 통해 이벤트를 호출하고 등록하는 방식이 설명된다.
-
캐릭터의 상태를 나타내기 위해 클래스가 별도로 존재하는 대신, 상태를 관리하는 방식으로 단일 클래스를 사용한다.
-
화면 전환만 처리하므로 별도의 클래스가 필요하지 않으며, 상태를 스테이트로 관리하고 현재 상태를 저장한다.
-
스테이트는 스타트 스크린, 메인 메뉴, 레벨 셀렉션, 세팅, 게임 플레이 등으로 구성되며, 모든 화면이 동일한 클래스를 사용하여 스테이트 머신을 구현한다.
-
조건들을 코드로 등록하여 각 상태 간의 전환 로직이 완성되며, UI에도 스테이트 패턴을 적용할 수 있음을 보여준다.
-
참가자는 다운로드할 수 있는 프로젝트의 이북에 스테이트 패턴 및 MVP에 대한 자세한 설명이 포함되어 있다고 언급했다.
-
해당 이북은 UI 툴킷 사용 시 디자인 패턴에 대해 더 깊이 있게 알고 싶은 이들에게 많은 도움이 될 것으로 보인다.
-
8월부터는 스크립터블 오브젝트를 심층적으로 다룰 예정이며, 이 개념의 파급력이 크다고 평가된다.
-
스크립터블 오브젝트는 게임 개발자들에게 점점 더 많이 사용되고 있는 추세라고 설명되었다.
-
다음 방송에서도 유니티와 관련된 내용으로 계속 서비스를 제공할 것이라고 밝혔다.