📘 TIL-Selection/Resource UI 데이터 연동과 표시 구조 정리

문제 상황

어제까지는

커서 UI / 드래그 선택 / 입력 좌표계 / 화면 표현 기준

을 정리하면서

입력 → 화면 반응

까지는 안정화된 상태였다.

---

오늘은 그 위에

선택된 유닛 / 건물의 실제 데이터
TopBar 자원 / 인구 표시
SelectionPanel 상세 정보

를 붙이면서

반응하는 UI → 실제 게임 데이터와 연결된 UI

단계로 넘어가는 작업을 진행했다.

---

구현 목표는 다음과 같았다.

TopBar → PlayerState 기준 자원 / 인구 / 유지비 표시
SelectionPanel → 선택 대상의 HP / 타입 / 상세 스탯 표시
Selection 구조 → NetID 기반 선택 데이터와 UI 연결

---

하지만 구현 과정에서 다음과 같은 문제가 발생했다.

---

발생 증상

• SelectionPanel은 뜨는데 실제 선택 대상 정보가 불완전함
• 단일 선택 / 다중 선택 전환 시 UI 상태가 어긋남
• 건물과 유닛이 같은 패널을 쓰는데 표시 기준이 섞임
• TopBar는 보이지만 실제 데이터와 연동이 불안정함
• PlayerState 값이 바뀌어도 UI가 즉시 반영되지 않는 구간이 존재함
• 스탯 표시 포맷이 하드코딩되어 반복 코드가 많아짐

---

공통점은

데이터는 있는데
→ UI에 전달되는 방식이 정리되지 않았거나
→ 같은 패널에 여러 타입의 데이터를 얹으면서 기준이 섞인 상태

즉

UI가 보이기 시작한 시점부터는 “무엇을 어떻게 보여줄지”에 대한 구조 정리가 필요해진 상태였다.

---

분석

---

1. SelectionPanel이 표현 대상별로 성격이 달랐다

SelectionPanel 하나로

단일 유닛
단일 건물
다중 선택

을 모두 처리하고 있었는데,
각 상태가 요구하는 정보가 달랐다.

예를 들면

단일 유닛 → HP + 상세 스탯
단일 건물 → HP + 생산 상태
다중 선택 → 요약 목록

즉 같은 패널이지만 사실상

보여줘야 하는 데이터 구조가 서로 다름

이라는 문제가 있었다.

---

2. Selection 데이터와 TopBar 데이터의 출처가 달랐다

현재 구조에서

TopBar → PlayerState 기반
SelectionPanel → UnitSubsystem / 선택 상태 기반

으로 들어오고 있었기 때문에,
겉보기에는 둘 다 HUD지만 실제로는 완전히 다른 소스를 사용하고 있었다.

그 자체는 틀린 구조는 아니었지만,
중간에서 ViewModel을 통일해주지 않으면

UI 갱신 타이밍
표시 기준
데이터 해석 방식

이 쉽게 어긋날 수 있는 상태였다.

---

3. UI 갱신은 “데이터 변경”과 “표시 갱신”이 동시에 맞아야 했다

PlayerState 값이 바뀌더라도

값 변경
→ Notify
→ PlayerController
→ UIBridge
→ Refresh

흐름이 끝까지 타지 않으면
결국 화면은 이전 값을 계속 보여주게 된다.

즉 문제는 단순히 값이 바뀌느냐가 아니라

값 변경이 UI 갱신까지 연결되느냐

였다.

---

4. SelectionPanel 스탯 포맷은 점점 하드코딩이 늘어나는 구조였다

처음에는 간단하게

"ATK: %.0f"
"DEF: %.0f"
"AS: %.2f"

형태로 바로 넣고 있었는데,
이 방식은 빠르게 붙일 수는 있어도

포맷 중복
표현 규칙 분산
유지보수 어려움

문제를 만들기 쉬웠다.

특히 스탯 종류가 늘어나거나,
표기 방식을 한 번에 바꾸고 싶을 때 불리한 구조였다.

---

5. NetID 기반 선택 구조는 맞지만, UI에 바로 쓰기에는 해석 단계가 필요했다

선택 자체는 NetID 기반으로 잡혀 있었지만
UI는 NetID를 직접 보여주는 게 아니라

이름
타입
HP
스탯
Portrait

같은 “표시용 정보”가 필요했다.

즉 선택 시스템과 UI 사이에는 반드시

선택 데이터 → ViewModel 변환

단계가 필요했고,
오늘 작업의 핵심은 결국 이 변환 레이어를 안정화하는 쪽에 가까웠다.

---

해결

---

1. SelectionPanel의 표시 모드를 명확히 분리했다

하나의 패널을 유지하되, 내부적으로는

None
Single
Multi

상태를 분기해서 처리하고,
단일 선택 안에서도

Unit
Building

을 구분하는 방향으로 정리했다.

즉 패널은 하나지만 내부 표현은

단일 유닛용
단일 건물용
다중 선택용

관점으로 나눠서 보게 됐다.

---

2. TopBar는 PlayerState 기준, SelectionPanel은 선택 데이터 기준으로 역할을 고정했다

HUD 전체를 한 덩어리로 보지 않고

TopBar = PlayerState 기반 수치 HUD
SelectionPanel = 현재 선택 대상 표시 HUD

로 역할을 나눴다.

이렇게 하니까 데이터 출처가 다르더라도
각 패널이 “무슨 정보를 책임지는지”가 명확해졌다.

---

3. PlayerState → UI 갱신 흐름을 명확하게 연결했다

자원 / 인구 / 유지비 관련 값이 바뀌면

PlayerState
→ NotifyUIResourceStateChanged()
→ PlayerController
→ UIBridge::RefreshResources()
→ TopBar 갱신

으로 이어지도록 정리했다.

즉 UI는 데이터를 직접 계산하지 않고,
항상 PlayerState를 통해 전달받는 구조로 유지했다.

---

4. SelectionPanel 스탯 표시는 공통 포맷 함수로 정리했다

기존처럼 각 줄마다 직접 Printf 를 반복하지 않고,

정수형 스탯
실수형 스탯

을 나눠 공통 함수로 빼는 방향으로 정리했다.

예를 들면

FormatStatInt("ATK", Value)
FormatStatFloat("AS", Value)

처럼 정리해서

포맷 중복 제거
표기 방식 통일
확장성 확보

를 같이 해결했다.

---

5. ViewModel 중심으로 “UI가 알아야 할 값만” 넘기도록 정리했다

UI가 게임 오브젝트를 직접 해석하지 않게 하고,

DisplayName
TypeLabel
HP
Damage
Armor
AttackSpeed
MoveSpeed
Range

같은 값만 ViewModel에 담아 전달하는 방향으로 맞췄다.

즉 UI는 이제

무엇을 보여줄지

만 알고,

그 값이 어디서 왔는지

는 UIBridge / Provider 레벨에서 처리하는 방향이 되었다.

---

구조 정리

---

데이터 흐름

게임 데이터
→ PlayerState / UnitSubsystem / Building

→ PlayerController

→ UIBridge

→ ViewModel

→ Widget

---

TopBar 흐름

PlayerState 값 변경
→ NotifyUIResourceStateChanged
→ PlayerController
→ RefreshResources
→ TopBarWidget

---

SelectionPanel 흐름

선택 상태 변경
→ PlayerController
→ UIBridge::RefreshSelection
→ SelectionViewModel 생성
→ SelectionPanelWidget 반영

---

SelectionPanel 내부 모드

None
Single(Unit)
Single(Building)
Multi

---

발생 원인 정리

---

1. 하나의 패널에 여러 성격의 데이터를 동시에 얹고 있었다

유닛 / 건물 / 다중 선택

은 같은 선택 패널을 쓰지만
필요한 정보는 서로 달랐다.

---

2. HUD 전체를 하나의 데이터 흐름으로 보기 어려웠다

TopBar
SelectionPanel

이 서로 다른 원본 데이터를 쓰는데도
겉으로는 한 HUD처럼 붙어 있었기 때문에
구조를 명확히 나누는 작업이 필요했다.

---

3. UI는 데이터가 아니라 “해석된 표시값”을 받아야 했다

NetID, Fragment, PlayerState 내부값은
게임 쪽 데이터이고,

UI는 그것을 바로 쓸 수 없었다.

즉 중간 해석 레이어가 필수였다.

---

4. 포맷/문자열 처리도 구조의 일부였다

숫자를 보여주는 문제처럼 보였지만 실제로는

표현 규칙의 일관성

문제였다.

---

배운 점

---

1. UI 연결 단계부터는 “무엇을 보여줄지”를 먼저 정해야 한다

데이터가 있다고 바로 UI에 연결하면 안 되고,

이 패널은 무엇을 책임지는가

부터 정해야 한다.

---

2. 같은 HUD라도 데이터 출처가 다를 수 있다

TopBar ≠ SelectionPanel

둘 다 HUD이지만 원본은 다를 수 있고,
그래서 연결 계층도 분리되어야 한다.

---

3. UI는 원본 데이터를 직접 알면 안 된다

UI는

표시값
상태
가시성

만 알면 되고,
실제 게임 데이터 해석은 중간 레이어가 맡아야 한다.

---

4. ViewModel은 단순 전달 객체가 아니라 “표시 규칙의 기준점”이다

어떤 값을 넣고 어떤 값을 넣지 않을지 정리하는 순간,
UI 구조도 같이 정리된다.

---

5. 반복되는 포맷은 초반에라도 정리해두는 게 좋다

작은 반복처럼 보여도
스탯 UI처럼 줄이 늘어나는 구조에서는 금방 유지보수 비용이 커진다.

---

6. UI 문제처럼 보여도 실제로는 구조 문제인 경우가 많다

오늘 작업도 겉으로는

TopBar 값 표시
SelectionPanel 값 표시

였지만 실제로는

데이터 출처
갱신 타이밍
표현 모드 분리

를 정리하는 작업에 더 가까웠다.

---

오늘의 정리

오늘 작업은 단순히 UI에 숫자를 띄우는 작업이 아니라
PlayerState, Selection, ViewModel, Widget 사이의 역할을 정리하는 과정이었다.