[TIL: 2026.05.22] C++ TRPG 인벤토리 구조 리팩토링 및 렌더러 기반 상점 UI 구축 트러블슈팅

📋 학습 개요

TRPG 프로젝트의 핵심인 인벤토리 및 상점 시스템을 객체지향 원칙에 따라 설계하고, 기존의 콘솔 출력(std::cout) 방식에서 벗어나 커스텀 렌더러(Renderer::DisplayUI) 시스템으로 전환했다. 이 과정에서 중첩된 조건문을 제거하는 리팩토링과 메모리 안전성을 위한 복사 생성자 활용법을 학습했다.

 

💻 상세 내용 및 트러블슈팅

1. 인벤토리 검색 로직 리팩토링

문제 발생: 아이템 사용(UseItem) 및 추가(AddItem) 로직에서 for문과 if문이 여러 번 중첩되어 코드의 가독성이 급격히 떨어지는 장풍 코드(Arrow Code) 현상이 발생했다.

• 해결 방안:
  1. 중앙 집중화: 이름으로 아이템 슬롯을 찾는 GetItemSlot 함수를 별도로 구현하여 검색 로직을 단일화했다.
  2. 조기 반환(Early Return): 조건이 맞지 않을 경우 즉시 return하는 방식을 도입하여 들여쓰기 깊이를 최소화했다.
• 인사이트: 인벤토리는 데이터 보관에만 집중하고, 아이템 효과 적용은 Item 클래스에게 위임함으로써 단일 책임 원칙(SRP)을 강화할 수 있었다.

 

2. 상점 거래 시스템 및 메모리 안전성 확보

• 상황: 상점에서 아이템을 구매/판매할 때, 상점과 플레이어 간의 아이템 이동 로직이 필요했다.
• 트러블슈팅 (Dangling Pointer 예방):
  • 문제: 처음에는 상점의 아이템 포인터를 플레이어 인벤토리에 그대로 넘겨주었으나, 이는 한쪽에서 아이템을 삭제할 경우 다른 쪽에서 유효하지 않은 메모리를 참조하게 되는 위험이 있었다.
  • 해결: new Item(*shopItem)과 같이 복사 생성자를 활용한 깊은 복사 방식을 적용하여, 상점과 플레이어가 서로 독립된 아이템 객체를 소유하도록 설계했다.
• 인사이트: 포인터를 다루는 C++ 프로젝트에서는 객체의 소유권을 누가 갖는지 명확히 하고, 필요 시 복사본을 생성하여 독립성을 유지하는 것이 치명적인 런타임 오류를 방지하는 길이다.

 

3. 콘솔 출력 방식에서 렌더러 기반 UI로 전환

• 문제 발생: std::cout을 무분별하게 사용할 경우 콘솔 화면이 위로 밀리면서 공들여 만든 프레임워크 UI가 깨지는 문제가 발생했다.
• 해결 방안:
  1. 모든 std::cout 호출을 제거하고 Renderer::DisplayUI 및 Renderer::DisplayUITimed로 교체했다.
  2. Inventory::PrintAllItems 함수가 출력 형식을 스스로 정하지 않고, 외부(상점, 플레이어 등)에서 전달한 람다(Lambda) 함수를 통해 정보를 출력하도록 구조를 추상화했다.
• 인사이트: 출력 로직과 데이터 로직을 분리함으로써, 동일한 인벤토리 데이터를 상황에 따라(상점용, 인벤토리용) 다르게 보여줄 수 있는 유연성을 확보했다.

 

🛠️ 오늘의 깨달음

[객체지향 설계 측면]

부모 클래스에 이미 있는 변수를 자식 클래스에서 또 선언하는 멤버 변수 섀도잉(Shadowing)이 얼마나 위험한지 체감했다. 아이템을 사용해도 체력이 오르지 않던 버그를 통해, 부모의 자원을 올바르게 상속받고 추상 함수를 정확히 구현하는 것의 중요성을 다시 한번 배웠다.

[코드 가독성 측면]

코드는 작성하는 시간보다 읽히는 시간이 훨씬 길다. 중첩된 if문을 펴고, 기능을 작은 단위의 함수(GetItemSlot)로 쪼개는 행위가 전체 프로젝트의 유지보수 비용을 획기적으로 낮출 수 있음을 확인했다.

✨ 오늘의 총평

오늘은 단순히 기능을 만드는 것을 넘어, "어떻게 하면 더 안전하고 깔끔한 코드를 짤 수 있을까?"를 깊게 고민한 하루였다. 특히 렌더러 시스템에 맞춰 인벤토리 출력 방식을 리팩토링했을 때, 화면 밀림 없이 텍스트가 지정된 자리에 싹 꽂히던 게 기억에 남는다.

 

🔗 프로젝트 관리 (GitHub)

• 새로운 조직 레포지토리: NBC-TRPG6/TRPG6