[UE5] ProjectTF#5 데이터 관리 구조 설계

데이터 관리 구조를 고민하게 된 이유

프로젝트를 진행하면서 아이템, 레시피, 퀘스트, 창고 데이터처럼 다양한 데이터를 다루게 되었다.

처음에는 Actor나 Widget에서 직접 데이터를 관리했지만, 데이터의 종류가 늘어나면서 "어떤 데이터는 변하지 않고, 어떤 데이터는 계속 변한다." 는 점을 알게 되었다.

이를 계기로 게임 데이터와 런타임 데이터를 분리하는 구조를 설계하게 되었다.

---

GameDataAsset의 역할

GameDataAsset은 게임의 기본 데이터를 저장하는 역할을 담당한다.

대표적인 예시는 다음과 같다.

• 아이템 정보
• 레시피 정보
• 상점 기본 정보
• 게임 설정 값

이러한 데이터는 게임이 실행되는 동안 거의 변경되지 않기 때문에 DataAsset으로 관리하는 것이 적합하다.

GameDataAsset

├─ Item Data
├─ Recipe Data
├─ Shop Data
└─ Game Config

즉, "게임의 기본 설계도" 역할을 한다.

---

DataTable와 Subsystem의 관계

DataTable에는 게임의 원본 데이터가 저장된다.

하지만 게임 플레이 중에는 DataTable을 직접 수정하지 않는다.

대신 Subsystem이 DataTable을 읽어 필요한 데이터를 가져와 게임 로직에 활용한다.

DataTable
      │
      ▼
Subsystem
      │
      ▼
ViewModel
      │
      ▼
UI

이 구조를 사용하면

• 데이터는 DataTable에서 관리하고
• 로직은 Subsystem에서 처리하며
• UI는 결과만 표시하는 역할로 분리할 수 있다.

---

게임 데이터와 런타임 상태 분리

프로젝트를 진행하면서 가장 중요하게 느낀 부분은 정적인 데이터와 동적인 데이터를 분리하는 것이었다.

게임 데이터(Static Data)

게임 시작 전에 이미 정해져 있는 정보이다.

예시

• 아이템 이름
• 아이템 가격
• 아이템 설명
• 레시피 재료
• 퀘스트 내용

이러한 데이터는 DataAsset이나 DataTable에 저장한다.

---

런타임 상태(Runtime Data)

게임 플레이 중 계속 변경되는 정보이다.

예시

• 현재 보유 골드
• 인벤토리 수량
• 창고 아이템
• 현재 퀘스트 진행도

이 데이터는 Subsystem이나 SaveGame에서 관리한다.

정적인 데이터와 동적인 데이터를 분리하면 데이터를 수정하거나 기능을 확장하기가 훨씬 쉬워진다.

---

창고(Storage) 데이터 관리 구조

창고 시스템도 같은 방식으로 설계하였다.

아이템의 기본 정보는 DataTable에 저장하고,

실제로 플레이어가 보유한 수량은 Storage에서 관리한다.

Item DataTable
        │
        ├── 이름
        ├── 아이콘
        ├── 가격
        └── 설명

StorageSubsystem
        │
        ├── ItemID
        └── Count

예를 들어

ItemID : Apple
Count : 10

이라는 데이터만 저장하고,

아이템 이름이나 아이콘은 DataTable에서 조회하여 사용한다.

이렇게 하면 같은 정보를 여러 곳에 저장하지 않아도 되고, 데이터 중복도 줄일 수 있다.

---

느낀 점

이번 구조를 설계하면서 "데이터를 어디에 저장할 것인가" 만큼 "누가 데이터를 관리할 것인가" 도 중요하다는 것을 배웠다.

DataAsset과 DataTable은 변하지 않는 게임 데이터를 관리하고,

Subsystem은 게임이 실행되는 동안 변경되는 상태를 관리하며,

UI는 필요한 정보만 받아 화면에 표시하는 구조가 가장 유지보수하기 쉽다는 것을 이해하게 되었다.

앞으로도 새로운 시스템을 구현할 때는 정적인 데이터와 동적인 데이터를 먼저 구분한 뒤, 각 데이터에 맞는 관리 주체를 결정하는 것을 우선적으로 고려해야겠다.