[TIL: 2026.06.17] CH3 팀프로젝트 ProjectFT의 아키텍처 분석

개요

프로젝트 개발에 본격적으로 들어가기에 앞서, 전체적인 구조와 사용된 기술 스택을 분석했다. ProjectFT는 대규모 프로젝트에서도 유지보수와 확장이 용이하도록 Gameplay Tags, Message Router, MVVM(ViewModel) 패턴을 활용하고 있다.

---

핵심 개념 정리

① Gameplay Tags

단순한 문자열(String)이나 열거형(Enum) 대신 사용하는 언리얼 엔진의 태그 시스템이다.
 

* 특징: State.Action.Attack과 같이 계층 구조를 가진다.
 * 장점: 오타로 인한 버그를 방지할 수 있고, State만 체크해도 그 하위 태그인 Attack, Move 등을 포함해 검사할 수 있어 매우 유연하다.

 

② Gameplay Message Router

객체와 객체가 직접 통신하지 않고 '방송국'을 거치는 방식이다.

 

* 작동 원리: 특정 이벤트(예: 아이템 획득)가 발생하면 방송국에 메시지를 쏜다(Publish). 이 정보가 필요한 객체들은 해당 채널을 구독(Subscribe)하여 듣고 있다가 행동한다.
 * 장점: 결합도(Coupling)를 낮춘다. 정보를 보내는 쪽은 받는 쪽이 누구인지 알 필요가 없다. 기능 추가 시 기존 코드를 건드리지 않아도 된다.

③ MVVM & ViewModel

데이터(Model)와 화면(View) 사이의 의존성을 끊기 위해 중간에 ViewModel을 두는 패턴이다.

* Model: 순수한 데이터 (예: 캐릭터 체력 수치)
* ViewModel: 데이터를 UI가 표현하기 좋은 형태로 가공 (예: "체력: 80%")
* View: 플레이어에게 보이는 실제 UI 위젯
* 장점: 디자이너가 UI 구조를 바꿔도 로직 코드에는 영향이 없고, 반대로 로직이 바뀌어도 UI를 새로 만들 필요가 없다.

 

④ Subsystems

특정 기능을 담당하는 객체가 게임이 시작될 때 자동으로 생성되어 상주하는 시스템이다.

* FTUIManagerSubsystem: UI 생성 및 관리 전담
* FTObjectiveSubsystem: 퀘스트 및 목표 달성 여부 감시
* FTSettlementSubsystem: 정착지 관련 데이터 및 로직 관리

---

게임 플레이 데이터 흐름 (Data Flow)

아이템을 획득하거나 퀘스트를 완료했을 때, 데이터는 왼쪽에서 오른쪽으로 다음과 같이 흐른다.

 

1. 트리거: 플레이어의 조작이나 게임 내 사건 발생.
2. 로직 처리: 서브시스템에서 실제 수치를 계산하고 상태를 변경.
3. 상태 정의: Gameplay Tags를 통해 현재 어떤 상태인지 명확히 정의.
4. 방송: Message Router를 통해 "이런 일이 발생했다!"고 전역으로 알림.
5. 가공: UI 뒤에 있는 ViewModel이 방송을 듣고 UI가 그리기 좋게 데이터를 정리.
6. 표시: 최종적으로 플레이어 화면의 UI가 자동으로 갱신됨.

 

---

 

오늘의 회고

처음 구조를 접했을 때는 단순히 기능을 구현하는 것보다 훨씬 복잡해 보였다. 하지만 프로젝트가 커질수록 "누가 이 함수를 호출했지?"를 찾아 헤매는 시간을 획기적으로 줄여줄 설계라는 확신이 든다.

직접적인 연결을 끊고 '방송과 구독'이라는 개념을 도입함으로써, 각 기능을 모듈화하고 안전하게 관리할 수 있다는 점이 가장 인상 깊었다. 앞으로 코드를 짤 때도 이 흐름을 깨지 않도록 주의하며 개발해야겠다.

 

 

 

참고 키워드

* Unreal Engine Gameplay Tags
* Gameplay Message Router Plugin
* MVVM (Model-View-ViewModel)
* GameInstance Subsystem