TIL 71일차 - 얽힌 실타래를 푸는 법: 상점 시스템 리팩토링 기록

오늘은 기존 상점 시스템을 뼛속부터 갈아엎는 리팩토링을 했다.
사실 기능은 돌아가고 있었지만, 무언가 점점 억지로 짜 맞추는 듯한 느낌이 들고 있었다.
불안정한 구조 위에 새로운 기능을 얹는 건 이제 그만두기로 했다.

---

문제 상황 (Trouble)

처음 상점 시스템을 만들 땐 ShopItemData 하나로 모든 걸 다 처리했었다.
하지만 JSON 저장/불러오기, 상세 정보 출력, 가격 계산, 골드 UI 연동까지 얽히기 시작하자,
점점 데이터 흐름이 꼬이고 있었다.
특히 UI 쪽에서 ItemData까지 접근해야 할 때마다
“이거 진짜 이렇게 가도 괜찮은가?” 싶은 생각이 들었다.

---

시도했던 것 (Attempt)

그래서 ShopItem을 중심으로 구조를 완전히 다시 짰다.
기존 단일 데이터 구조를 ShopItem + ItemData의 조합으로 나누고,
추가적으로 JSON 직렬화를 위한 ShopItemDTO도 새로 만들었다.
ScriptableObject도 전면 교체하고, ShopInventorySO에서 ShopItem 리스트로 재정의했다.

UI 쪽은 ShopUI.Show()에서 ItemDataDictionary를 참조해
각 슬롯에 상세 설명을 직접 넣어주는 방식으로 바꿨다.
이제 더 이상 우회로를 돌지 않아도 되고, 확장성도 훨씬 좋아졌다.

---

해결 방법 (Solution)

GoldData를 중심으로 모든 상점 관련 UI/로직 흐름을 통합했다.
ShopManager에서 SetGoldData()를 통해 외부 주입받게 하고,
TownGameStart에서 초기화 시 GoldData를 직접 연결했다.

또한 Buy 버튼 → 가격 계산 → 골드 차감 → 장비 장착 → StatDisplay 반영
이 일련의 흐름도 단일 책임 원칙에 따라 메서드를 분리했다.
이제 StatDisplay.EquipItem()이나 GoldData.TryConsumeGold() 같은
역할이 명확한 메서드로 깔끔하게 정리된다.

에러 처리도 강화했다.
골드 데이터가 null일 경우는 Logger.LogError()로 로깅하고,
상점 진입 전 IsReady()로 상태 체크까지 추가했다.

---

오늘 알게 된 것 (Learning)

‘되긴 하지만, 이대로 가도 될까?’라는 고민은
결국 구조를 바꾸라는 신호였다.
이번 리팩토링을 하면서 특히 느낀 건,
데이터 구조는 UI를 억지로 맞추는 대상이 아니라, 자연스럽게 흘러야 할 기반이라는 점이다.

그리고 ScriptableObject나 DTO, GoldData 같은 클래스들이
서로 느슨하게 연결될 수 있도록 조립하는 감각도 조금씩 익숙해지고 있다.

오늘은 구조를 바꾸는 게 ‘기능 추가’보다 훨씬 깊은 의미가 있다는 걸 다시 한번 배운 날이다.
“유지보수는 결국 내가 나중에 다시 읽을 수 있느냐의 문제다.”
그걸 실감하면서, 내일은 NPC 텍스트랑 마을 배치도 슬슬 손대볼 생각이다.