📘TIL - Selection 기반 커맨드 컨텍스트 정리와 Selection Panel 생산 UI 연동

문제

어제까지는 UI 표현 계층을 규격화하는 작업이 중심이었다.

HUDRoot = 위치
Panel = 구조
Widget = 표현

이 기준을 세우면서
TopBar, SelectionPanel, CommandPanel, MenuPanel 같은 각 패널의 역할과
표현 규칙을 정리하는 데 집중했다.

즉 어제의 핵심은
“동작하는 UI를 유지 가능한 UI로 바꾸는 것”이었다.

그런데 오늘 작업으로 넘어오면서 문제가 달라졌다.

이제는 표현 계층이 아니라
실제 선택 상태와 명령 구조, 그리고 건물 생산 상태를
UI에 연결하는 과정에서 구조적인 충돌이 드러났다.

특히 오늘은 다음 두 가지가 핵심 문제였다.

1. 선택 대상 기준 커맨드 컨텍스트 식별
2. Selection Panel에서 건물 생산 상태 표현

---

구조적 문제

구분	문제
커맨드 해석	PlayerController가 모든 명령을 직접 해석하면 하드코딩이 다시 늘어남
선택 대상 처리	유닛과 건물이 서로 다른 커맨드 집합을 가지는데 이를 어디서 판별할지 기준이 모호했음
컨텍스트 전환	선택된 대상에 따라 Build, Train, Move, Attack 같은 커맨드 묶음이 달라져야 했음
생산 UI	CommandPanel 숫자 배지만으로는 원하는 “생산 큐” 느낌을 만들기 어려웠음
Selection Panel	기존에는 이름/타입/HP까지만 표시하고 생산 상태를 표현할 구조가 없었음
데이터 흐름	QueueCount, 진행률, 큐 아이콘 데이터를 어디서 조립해 UI로 넘길지 기준이 불명확했음

---

기존 상태

처음에는 PlayerController 쪽에서 입력과 명령 해석을 많이 들고 가는 방향으로 정리되어 있었다.

대략 흐름은 이런 느낌이었다.

입력 수집
-> PlayerController
-> CommandId 결정
-> 실행

이 구조는 단순한 유닛 명령에는 괜찮았지만,
선택 대상이 바뀔 때마다 해석 기준이 달라지는 구조에는 잘 맞지 않았다.

예를 들어:

선택 대상이 유닛이면
-> Move / Attack / Hold

선택 대상이 건물이면
-> TrainFootman / TrainArcher / BuildSubMenu

이렇게 컨텍스트가 달라지는데도
PlayerController가 이를 직접 다 품고 있으면
결국 선택 대상별 분기와 예외 처리가 계속 늘어나게 된다.

즉 기존 구조는
“입력은 받지만, 선택 대상에 따라 바뀌는 명령 문맥을 자연스럽게 흡수하지 못하는 상태”였다.

---

분석

오늘 핵심은 이거였다.

입력 진입점과 커맨드 의미 해석은 분리해야 한다

중요했던 건
“어떤 키를 어떻게 받느냐”보다
“현재 선택된 대상이 어떤 커맨드 컨텍스트를 가지는가”였다.

즉 오늘 정리해야 했던 구조는
입력 기술 방식 자체가 아니라
선택 상태에 따라 커맨드 문맥을 식별하고
그 문맥 기준으로 바인딩과 표시를 맞추는 흐름이었다.

역할을 다시 정리하면 이렇게 된다.

PlayerController
-> 현재 선택 상태를 기준으로 명령 라우팅 진입점 담당

Selected Unit / Selected Building
-> 자신이 가진 커맨드 컨텍스트 제공

UIBridge / Provider / Coordinator
-> 현재 컨텍스트와 상태를 UI에 맞는 ViewModel로 조립

즉 오늘의 핵심 판단은 다음이었다.

명령 실행 진입은 PlayerController
커맨드 컨텍스트 식별은 선택 대상 기준
UI 반영은 Bridge / Provider / Coordinator

이렇게 나눠야
PlayerController가 다시 비대해지는 걸 막을 수 있고,
선택 대상별 커맨드 문맥도 자연스럽게 유지할 수 있다.

---

어제 작업과의 연결

어제는 표현 규칙을 정리했다면,
오늘은 그 표현 구조 위에
실제 선택 상태와 명령 문맥, 생산 상태를 얹는 작업이었다.

흐름으로 보면 이렇게 이어진다.

어제
동작하는 UI
-> 규격화된 UI

오늘
규격화된 UI
-> 실제 선택 상태와 커맨드 문맥이 반영되는 UI

즉 어제의 작업이
패널, 위젯, 스타일의 뼈대를 세우는 단계였다면,
오늘은 그 뼈대 안에
선택 대상별 상태와 생산 큐 같은 실제 데이터를 흘려 넣는 단계였다.

---

해결

1. 선택 대상 기준 커맨드 컨텍스트 식별 구조 정리

가장 먼저 정리한 건
명령을 누가 해석할 것인가였다.

오늘 기준으로 유지해야 하는 흐름은 이거다.

현재 선택 대상 식별
-> 선택 대상이 가진 커맨드 컨텍스트 조회
-> 그 컨텍스트 기준으로 커맨드 바인딩/표시

즉 중요한 건
PlayerController가 TrainFootman, TrainArcher, BuildBarracks 같은 개별 명령을 직접 아는 것이 아니라,
현재 선택된 유닛 또는 건물이
어떤 커맨드 그룹을 가지는지를 기준으로
명령 집합을 얻어오는 구조다.

이렇게 하면:

선택된 대상이 바뀜
-> 컨텍스트가 바뀜
-> CommandPanel 표시가 바뀜
-> 실행 가능한 명령도 같이 바뀜

이 흐름이 자연스럽게 이어진다.

---

2. PlayerController는 해석자가 아니라 라우터에 가깝게 정리

오늘 구조에서 PlayerController는
모든 명령의 의미를 직접 들고 있는 주체가 아니라
현재 선택 상태를 보고 적절한 쪽으로 연결하는 진입점에 가깝다.

정리하면 이런 느낌이다.

PlayerController
-> 현재 선택 대상 확인
-> 대상의 커맨드 컨텍스트 확인
-> 해당 컨텍스트 기준으로 명령 요청 전달

이 구조가 좋은 이유는 두 가지다.

첫 번째는
선택 대상별 명령 분기가 PlayerController 내부 하드코딩으로 쌓이지 않는다는 점이다.

두 번째는
유닛, 건물, 하위 빌드 메뉴, 생산 가능한 구조물 같은 문맥 차이를
선택 대상이 가진 컨텍스트 정보로 흡수할 수 있다는 점이다.

즉 컨트롤러는
점점 더 “명령 전달자”에 가까워지고,
실제 의미 체계는 선택 대상 쪽에 남게 된다.

---

3. CommandPanel은 “현재 컨텍스트의 명령”, SelectionPanel은 “현재 대상의 상태”로 역할 재정리

처음에는 QueueCount를 CommandPanel 숫자 배지로만 보여주려 했는데
원하는 느낌과는 거리가 있었다.

원하는 화면은 오히려 이런 구조였다.

Selection Panel
├ Portrait / 이름 / 타입 / HP
└ Production Strip
   ├ 생산 중 타이틀
   ├ Progress Bar
   └ 큐 아이콘 목록

즉 CommandPanel은
현재 실행 가능한 명령 집합을 보여주는 곳이고,

SelectionPanel은
현재 선택한 대상의 상태를 보여주는 곳이어야 했다.

이 기준으로 다시 보면 역할은 이렇게 정리된다.

CommandPanel
-> 현재 컨텍스트에서 실행 가능한 명령 표시

SelectionPanel
-> 현재 선택 대상 상태 표시
-> 건물이라면 생산 상태까지 포함

이렇게 나누니
생산 큐 UI 위치도 훨씬 자연스러워졌다.

---

4. SelectionViewModel에 생산 상태 확장

기존 FSelectionViewModel은
이름, 타입, HP, Portrait, Multi Selection 요약 정도를 담고 있었다.

오늘은 여기에
건물 생산 상태를 얹을 수 있도록 구조를 확장하는 방향이 정리됐다.

핵심은 다음 세 층이다.

FProductionQueueItemViewModel
-> 큐 슬롯 하나

FBuildingProductionViewModel
-> 생산 패널 전체

FSelectionViewModel
-> bShowProductionPanel
-> Production

이 구조가 중요한 이유는
Selection Panel 위젯이 생산 로직을 직접 계산하지 않아도 되기 때문이다.

위젯은 받은 데이터만 그리고,
실제 생산 상태 조립은 브리지 쪽에서 담당한다.

즉 표현 계층과 상태 조립 계층이 다시 분리됐다.

---

5. Production Queue Item 위젯 분리

생산 큐는 개수가 고정이 아니라
상황에 따라 0개일 수도 있고 여러 개일 수도 있다.

그래서 Queue UI는
정적인 BindWidget 하나로 해결하는 구조보다
런타임 생성형 구조가 더 자연스러웠다.

형태는 이렇다.

SelectionPanel
-> ProductionQueueBox

QueueItemWidget
-> 큐 아이콘 한 칸

즉 SelectionPanel은
큐 아이템 자체를 고정으로 들고 있는 것이 아니라,
필요한 개수만큼 생성해서 HorizontalBox에 붙이는 컨테이너 역할을 맡는다.

이렇게 하면
생산 큐 수가 바뀌어도 UI 구조를 억지로 고정하지 않아도 된다.

---

6. 생산 상태 조립은 UIBridge에서 담당

Selection Panel이 직접 생산 정보를 계산하면
표현 계층이 다시 비대해진다.

그래서 오늘 방향은
생산 상태 조립을 TWPlayerUIBridge에서 처리하는 쪽으로 정리됐다.

예를 들어 현재 선택 대상이 병영이면
브리지에서 이런 식의 데이터를 만든다.

- SelectionType = Building
- ViewMode = Single
- ProductionPanel = Visible
- QueueCount 읽기
- Queue 아이콘 목록 생성
- ProgressBar 값 채우기

그리고 이 결과를
SelectionProvider를 통해 HUDCoordinator로 넘기게 된다.

이 구조가 좋은 이유는
나중에 병영 외의 생산 건물, 연구 건물, 특수 구조물로 확장하더라도
위젯을 뜯지 않고 조립 로직만 확장하면 되기 때문이다.

---

7. CommandPanel의 QueueCount는 보조 정보로 유지

Selection Panel 쪽 생산 UI가 메인이 되더라도
기존 CommandPanel의 QueueCount 정보는 완전히 버릴 필요는 없었다.

대신 이건 메인 표현이 아니라
보조 지표 정도로 두는 게 맞았다.

흐름은 이렇게 정리된다.

Bridge
-> RuntimeCommandQueueCount 설정

SelectionProvider
-> RuntimeCommandQueueCountMap 저장

HUDCoordinator
-> CommandSlotViewModel 생성 시 QueueCount 주입

즉 메인 생산 상태는 Selection Panel이 담당하고,
CommandPanel은 현재 명령 슬롯에 대한 보조 상태만 가볍게 반영하는 구조다.

---

8. 오늘 작업에서 드러난 핵심 포인트

오늘은 단순히 위젯을 추가한 날이 아니었다.

실제로는 아래 세 가지를 맞추는 작업에 가까웠다.

1) 선택 상태와 명령 문맥 연결

무엇이 선택되었는가
-> 어떤 컨텍스트를 가지는가
-> 어떤 명령을 보여줄 것인가

2) 선택 대상 상태와 UI 연결

건물이 선택되었는가
-> 생산 상태가 있는가
-> Selection Panel에 어떻게 보일 것인가

3) ViewModel 조립 경로 정리

선택 대상 상태
-> Bridge
-> Provider
-> Coordinator
-> Widget

즉 오늘의 핵심은
입력 기술 자체보다도
“선택 상태 기반으로 커맨드와 UI를 어떻게 연결할 것인가”를 구조화한 데 있었다.

---

결과

오늘 작업으로 가장 크게 달라진 점은
UI가 단순히 “표시되는 구조”에서
실제 선택 상태와 생산 상태를 반영할 수 있는 구조로 한 단계 더 가까워졌다는 점이다.

정리하면:

선택 대상 식별
-> 커맨드 컨텍스트 결정

커맨드 컨텍스트
-> CommandPanel 명령 구성

건물 상태
-> Production 정보 생성

UIBridge
-> SelectionViewModel에 생산 상태 조립

SelectionPanel
-> ProgressBar + Queue 아이콘 표시

즉 지금은 적어도
“무엇을 선택했는가에 따라 어떤 명령이 보이고,
건물이라면 현재 생산 상태가 어떻게 보일 것인가”를
같은 구조 안에서 테스트할 수 있는 수준까지는 왔다.

---

Before

명령 해석 기준이 PlayerController 쪽으로 많이 쏠려 있었음
Selection Panel은 기본 정보만 표시
생산 큐는 CommandPanel 숫자 배지 수준
선택 대상과 UI 명령 문맥 연결이 약했음

---

After

선택 대상 기준 커맨드 컨텍스트 식별 구조 정리
PlayerController는 라우터에 가깝게 역할 정리
Selection Panel 내부 생산 UI 추가
Queue / 진행도 / 큐 아이콘 표시 구조 확보
Bridge / Provider / Coordinator 데이터 흐름 보강

---

비교

항목	이전	이후
명령 해석 기준	PlayerController 중심	선택 대상 컨텍스트 중심
CommandPanel 역할	명령 + 상태 일부 혼재	현재 컨텍스트의 명령 표시
SelectionPanel 역할	기본 정보 표시	대상 상태 + 생산 상태 표시
큐 표현	QueueCount 숫자	진행바 + 큐 아이콘
구조 안정성	컨텍스트 연결 기준이 약함	선택 상태 기준 흐름 정리

---

1. 핵심은 입력 방식보다 선택 대상의 커맨드 문맥이었다

오늘 다시 정리해 보니
중요했던 건 특정 입력 기술을 확정하는 게 아니라
현재 선택된 대상이 어떤 명령 문맥을 가지는지를 먼저 구조화하는 일이었다.

즉 기준은 이거다.

선택 대상이 무엇인가
-> 어떤 커맨드 집합을 가지는가
-> UI와 실행 경로를 어떻게 맞출 것인가

이 기준이 먼저 서야
나중에 입력 진입점을 어떻게 가져가든
전체 구조가 흔들리지 않는다.

---

2. 생산 큐는 Selection Panel 안으로 들어가는 게 맞았다

CommandPanel = 명령
SelectionPanel = 현재 대상 상태

이 기준으로 보니까
생산 큐는 CommandPanel 숫자 배지로 버티는 것보다
Selection Panel 안에서 현재 건물 상태로 보여주는 게 훨씬 자연스러웠다.

---

3. UI는 결국 데이터 구조가 먼저 정리돼야 했다

오늘도 다시 느낀 건
위젯만 손본다고 되는 문제가 아니라는 점이었다.

결국 같이 맞춰야 했던 건:

SelectionViewModel
ProductionViewModel
Provider runtime data
Coordinator 조립 구조

즉 오늘 작업의 핵심은
위젯 추가보다도
데이터가 어디서 만들어지고 어디로 흘러가는지를 정리하는 데 더 가까웠다.

---

전체 흐름

선택 대상 변경
-> 커맨드 컨텍스트 식별
-> CommandPanel 명령 갱신

건물 선택 상태
-> 생산 상태 조회
-> UIBridge
-> SelectionProvider
-> HUDCoordinator
-> SelectionPanel 갱신

---

오늘의 정리

• 어제는 UI를 규격화하고 표현 계층을 정리하는 단계였다.
• 오늘은 그 구조 위에 선택 상태, 커맨드 문맥, 생산 큐를 연결하는 단계였다.
• 특히 선택된 유닛/건물 기준으로 커맨드 컨텍스트를 식별하고, Selection Panel에 생산 UI를 붙이면서, “현재 선택 대상에 따라 명령과 상태가 함께 바뀌는 구조”를 좀 더 명확하게 만들었다.