[Project: TEXTRPG] C++로 구현하는 TEXT RPG 프로젝트 4~5일차.

[26.01.01] 4일차. Develop 브랜치 병합 및 충돌 해결하기

3일차에 코드 리뷰를 마쳤고, 브랜치 간에 서로 없는 클래스·함수·변수가 많아 작업 효율을 높이기 위해 부팀장과 피드백 반영 전 develop 브랜치로 선 병합을 진행했다.

 

그 과정에서 WinMerge 사용법을 익혔고 다음과 같이 해결하기로 결정했다.

- 충돌이 발생한 경우에는 WinMerge를 사용해 시각적으로 비교하며 충돌을 해결한다.
- 충돌이 없는 경우에는 GitHub Desktop에서 바로 Merge를 진행한다.

 

이후 자잘한 버그 수정을 하고 Develop에 다시 Push하여 팀원 모두 같은 작업 환경에서 개발할 수 있도록 했다.

[winmerge 설정 방법]

.git config 파일 끝에 아래 내용 추가

[diff]
    tool = winmerge
[difftool "winmerge"]
    cmd = "'C:/Program Files/WinMerge/WinMergeU.exe'" -e "$LOCAL" "$REMOTE"
[merge]
    tool = winmerge
[mergetool "winmerge"]
    cmd = "'C:/Program Files/WinMerge/WinMergeU.exe'" "$LOCAL" "$REMOTE" "$MERGED"
    trustExitCode = false


GitHub Desktop에서 Branch 탭 → Merge into current Branch 선택 → 현재 브랜치가 develop인지 확인 → 병합할 브랜치 선택. 예) feature/~~ 
"내 파일"이 develop 브랜치에 있는 파일.
"그 파일"이 feature/~~ 브랜치에 있는 파일.

---

[26.01.02] 5일차. Item, Inventory 클래스 재설계 및 구현

5일차에는 기능 구현보다 팀원들의 각 파트(Item, Inventory 연관 클래스)에서 발생한 문제를 조율하고 합의점을 찾는 데 대부분의 시간을 썼다.

각자 필요한 데이터와 원하는 구조가 달랐고, 그 요구사항을 모두 반영하려다 보니 설계가 계속 흔들렸다.

 

이 과정에서 딜레마에 빠졌다.
내 개발을 우선해야 할지, 팀원들의 요구사항에 대한 결정을 먼저 내려야 할지 쉽게 판단할 수 없었다.
둘 중 어느 쪽도 가볍지 않았고, 결국 선택의 책임은 팀장에게 돌아왔다.

 

검수 없이 빠르게 작성한 기존 Item 설계로 인해 클래스 책임이 불분명해지는 문제가 발생했음을 확인했다.

 

이에 따라 Item 클래스는 아이템의 정보만 보유하도록 역할을 축소했고,
아이템 사용에 따른 실제 효과 적용 로직은 Player의 책임으로 변경했다.
또한 아이템 사용 흐름은 BattleSystem에서 Player가 아이템을 사용하도록 구조를 수정했다.

 

아이템 시스템의 확장성을 높이기 위해 아이템 종류는 enum class로 관리하고 아이템 구조는 struct로 정의하며 아이템 생성은 Factory Method Pattern으로 처리하도록 설계를 변경했다.

그 결과, 기존 로직을 수정하지 않고도 신규 Item을 추가하면 Player가 사용할 수 있는 아이템이 자연스럽게 확장되는 구조를 목표로 구현했다.

 

아이템 이름은 변경될 일이 없다고 판단해 std::string 대신 const char*를 사용했고,

이에 따라 수동 메모리 관리 방식을 선택했다.

 

파일 단위로는 다음과 같이 작업했다.

• Item.cpp에서 플레이어에게 효과를 적용하는 로직을 제거했다.
• Item.h에서 ItemType을 Types/ItemType.h로 분리하고, 객체 복사는 막고 이동만 허용하도록 수정했다.
• ItemDefs.cpp/h에서 아이템 원형을 정의하고 검색할 수 있는 기능을 구현했다.
• ItemFactory.cpp/h에서 팩토리 패턴을 적용해 아이템 이름 기반 생성 기능을 구현했다.
• Inventory.cpp/h에서는 인덱스 기반 처리 방식을 제거하고, 아이템 객체 기반으로 추가 및 사용 로직을 변경했다.

일단 1차 테스트는 마무리했고 develop 브랜치에 병합까지는 완료했지만,
실제 게임 흐름에서 제대로 굴러갈지에 대한 확신은 들지 않았다.

이 시점에서 "먼저 테스트 코드를 작성해 전체 흐름을 고정했어야 하지 않았을까?" 라는 아쉬움이 남았다.

 

나 역시 명확한 답을 알고 있는 상태가 아닌데,
그럼에도 불구하고 매번 결정을 내려야 하는 위치에 있다는 점에서 팀장의 책임이 얼마나 무거운지 실감했다.

 

그동안 설계와 해결을 AI에 의존해 빠르게 진행해 온 영향인지,
막상 팀원들에게 "왜 이렇게 가야 하는지"를 명확하게 설명하기가 쉽지 않았다.

---

느낀 점

팀장이 되면 정답을 아는 사람이 아니라 불완전한 정보 속에서도 결정을 내려야 하는 사람이 된다는 걸 느꼈다.
설계는 코드보다 먼저 합의의 기준가 필요하다는 걸 체감했다.
"돌아가게 만드는 것"과 "설명 가능한 구조"는 전혀 다른 문제였다.

앞으로 프로젝트를 진행하게 된다면 다음 원칙들을 무조건 지키기로 했다.

 

 

• 구현 전, 최소한의 흐름 테스트 코드부터 작성한다.
  → 클래스 책임과 데이터 흐름을 코드로 먼저 고정한다.
• 결정의 기준을 문서로 남긴다.
  → 왜 이 구조를 선택했는지, 왜 다른 선택지를 버렸는지를 명확히 기록한다.
• AI는 참고 도구로만 사용한다.
  → 설계의 최종 결정과 설명은 내가 할 수 있어야 한다.
• 팀원 요구사항은 '데이터'로 정리한 뒤 판단한다.
  → 감각이 아니라 근거 기반으로 구조를 선택한다.

 

이번 5일차는 기능 구현보다 리더로서 부족한 지점을 명확히 인식한 날이었다.
힘들었지만, 반드시 지나야 할 단계라고 생각한다.