📘TIL-UI 데이터 흐름 구조 정리 및 DataTable 기반 UI 아키텍처 구축

문제

UI 스켈레톤을 기반으로 실제 동작까지 연결한 이후,
기능적으로는 UI가 정상적으로 동작하게 되었지만 구조적으로 다음과 같은 한계가 드러났다.

---

구조적 문제

구분	문제
CommandPanel	커맨드 정보가 코드에 하드코딩되어 있음
Selection	표시 정보(DisplayName, TypeLabel)가 Provider 내부에 포함됨
UI 구조	데이터와 표현이 분리되지 않음
확장성	실제 게임 시스템 연결 시 구조 변경이 필요
유지보수	UI 변경 시 코드 수정이 필수

---

기존 구조

Provider → Coordinator → ViewModel → UI

이 구조는 동작 자체는 가능했지만 다음과 같은 문제가 존재했다.

데이터 생성 + 표현 결정 + UI 출력 책임이 하나의 흐름에 섞여 있는 상태

---

분석

문제의 핵심은 UI의 동작 여부가 아니라
데이터와 표현, 그리고 UI의 역할이 분리되지 않았다는 점이었다.

---

문제 구조 상세

Provider
→ Selection 상태 + DisplayName + TypeLabel까지 직접 생성
→ Coordinator 전달
→ UI 출력

이 구조에서는 Provider가 단순 데이터 제공자가 아니라
UI 표현까지 책임지는 상태가 된다.

---

문제점 정리

1. Provider가 UI 표현까지 알고 있어야 한다
2. UI 변경 시 Provider 코드 수정이 필요하다
3. 실제 게임 데이터 구조 변경 시 UI까지 영향이 간다

즉,

데이터(무엇) + 표현(어떻게) + 출력(UI)이 강하게 결합된 구조

---

Command 구조 문제

CommandPanel
→ CommandId + DisplayName + Hotkey
→ 코드에서 직접 정의

이 구조에서는:

• 커맨드 추가 시 코드 수정 필요
• Hotkey 변경 시 코드 수정 필요
• 디자이너가 데이터만으로 UI 조정 불가능

---

UI 레이아웃 문제

CommandPanel에서 슬롯이 상황에 따라 줄어드는 문제가 발생했다.

SetVisibility(ESlateVisibility::Collapsed);

이로 인해:

슬롯 위젯 자체가 제거 → 그리드 구조 붕괴

---

해결

핵심 방향은 다음 두 가지로 정리했다.

1. 데이터와 표현을 완전히 분리한다
2. UI는 데이터를 생성하지 않고 소비만 한다

---

1. CommandPanel → DataTable 기반 전환

커맨드 정보를 코드에서 제거하고 DataTable로 이동했다.

---

변경 전

Command 정보 → 코드 내부에서 직접 정의

---

변경 후

CommandId
→ DT_CommandMeta 조회
→ ViewModel 생성
→ UI 출력

---

동작 흐름

SelectionSource
→ CommandId 목록 전달
→ Coordinator
→ DataTable에서 메타 조회
→ ViewModel 구성
→ CommandPanel 출력

---

역할 분리

영역	역할
Provider	CommandId 제공
DataTable	표시 정보 (이름, Hotkey, Icon 등)
Coordinator	데이터 + 메타를 조합하여 ViewModel 생성
UI	ViewModel 출력

---

2. Selection → ID 기반 구조로 변경

Selection도 동일한 방식으로 구조를 분리했다.

---

변경 전

Provider → DisplayName / TypeLabel 직접 생성

---

변경 후

SelectionSource → SelectionId 전달
→ Coordinator
→ DT_SelectionPresentation 조회
→ DisplayName / TypeLabel / Icon 보완

---

구조 의미

Provider → "무엇이 선택되었는가"
DataTable → "어떻게 보여줄 것인가"

---

장점

• UI 변경 시 DataTable만 수정하면 됨
• Provider는 순수 데이터 역할만 수행
• 실제 게임 데이터 구조 변경에도 UI 영향 최소화

---

3. UI를 데이터 소비 구조로 전환

UI는 더 이상 데이터를 생성하지 않도록 구조를 정리했다.

---

최종 데이터 흐름

SelectionSource / ResourceSource
→ Coordinator
→ ViewModel 생성
→ HUDRoot
→ Panel Widget

추가적으로:

Coordinator
↑
DataTable (CommandMeta / SelectionPresentation)

---

구조 특징

Provider = 상태 제공
DataTable = 표현 정의
Coordinator = 조합 및 변환
UI = 출력

---

4. CommandPanel 구조 안정화 (9칸 고정)

CommandPanel은 항상 동일한 레이아웃을 유지하도록 수정했다.

---

기존 문제

슬롯 Collapse → 그리드 축소

---

수정 후

항상 9칸 유지
→ 슬롯은 유지하고 내부 데이터만 변경

---

동작 방식

1. 모든 슬롯을 빈 상태로 초기화
2. CommandId의 SlotIndex 기준으로 해당 위치에 배치
3. 빈 슬롯은 텍스트/아이콘만 제거

---

UI 결과

[Move] [Stop] [Attack]
[    ] [    ] [     ]
[    ] [    ] [     ]

---

5. Provider 계약 확장

향후 기능 확장을 고려해 인터페이스를 확장했다.

---

추가된 기능

함수	역할
GetSelectionViewMode	Single / Multi 구분
GetPrimaryEntityId	대표 선택 대상
GetTotalSelectedCount	선택 개수
GetSelectionSummary	Multi 선택 정보

---

설계 의도

현재는 Mock 기반이지만
실제 게임 시스템과 연결해도 구조 변경 없이 확장 가능하도록 준비

---

결과

항목	결과
CommandPanel	DataTable 기반으로 동작
SelectionPanel	ID 기반 + 메타데이터 분리
UI 구조	데이터 / 표현 / 출력 완전 분리
레이아웃	항상 안정적인 9칸 구조 유지
확장성	실제 게임 시스템 연결 가능한 구조 확보
유지보수	UI 변경 시 코드 수정 없이 데이터만으로 대응 가능

---

오늘의 정리

• 이번 작업은 UI를 수정하는 것이 아니라
  UI가 데이터를 받아서 동작하는 구조 자체를 정리
• UI는 더 이상 상태를 직접 가지지 않고,
  Provider와 DataTable을 조합해 출력하는 구조로 전환