[UE5] ProjectFT#1 UI 리팩터링 - WidgetSwitcher 적용

리팩터링 배경

기존 UI는 하나의 MainWidget 안에서 여러 패널의 Visibility를 변경하며 화면을 전환하는 방식이었다.

패널이 늘어날수록 MainWidget의 책임이 커지고, 어떤 패널이 활성화되어 있는지 관리하기 어려워지는 문제가 있었다.

이를 개선하기 위해 WidgetSwitcher를 사용하는 구조로 변경했다.

---

변경 내용

1. WidgetSwitcher 구조로 변경

기존에는 각 패널의 Visibility를 직접 변경했다.

MainWidget
├─ Inventory (Visible)
├─ Craft (Hidden)
├─ Quest (Hidden)

리팩터링 후에는 WidgetSwitcher가 현재 보여줄 위젯만 관리하도록 변경하였다.

MainWidget
└─ WidgetSwitcher
    ├─ Inventory
    ├─ Craft
    └─ Quest

패널 전환은 WidgetSwitcher의 Active Index만 변경하면 된다.

---

2. MainWidget 역할 축소

기존 MainWidget은

• 패널 생성
• Visibility 변경
• 화면 전환
• UI 상태 관리

등 여러 역할을 담당하고 있었다.

리팩터링 이후에는

• WidgetSwitcher 보유
• 화면 전환 요청 전달

정도의 역할만 수행하도록 변경하여 책임을 줄였다.

---

3. Visibility 방식(Fallback) 제거

기존에는

Inventory->SetVisibility(...);
Craft->SetVisibility(...);
Quest->SetVisibility(...);

처럼 모든 패널의 Visibility를 직접 관리했다.

이 방식은

• 코드가 길어지고
• 패널이 추가될 때마다 수정해야 하며
• Hidden/Collapsed 상태 관리가 복잡해지는 문제가 있었다.

WidgetSwitcher를 적용하면서 이러한 Visibility 제어 코드를 제거하였다.

---

4. 기존 패널 구조 개선

기존에는 여러 패널이 동시에 존재하면서 Visibility만 변경되는 구조였다.

현재는 WidgetSwitcher가 하나의 화면만 활성화하도록 변경되어

• 화면 전환 로직이 단순해졌고
• 새로운 패널 추가가 쉬워졌으며
• UI 관리가 더욱 명확해졌다.

---

느낀 점

WidgetSwitcher를 적용하면서 단순히 화면 전환 방식만 바뀐 것이 아니라, MainWidget의 책임을 줄이고 UI 구조를 더욱 확장하기 쉬운 형태로 개선할 수 있었다.

패널이 계속 추가되는 프로젝트에서는 Visibility를 직접 관리하는 방식보다 WidgetSwitcher를 사용하는 구조가 유지보수 측면에서 훨씬 유리하다는 것을 알게 되었다.