12조 Text RPG 팀 프로젝트 회고록
1. 프로젝트 기본 정보
TRPG: - 개발 기간: 2026.05.21 ~ 2026.05.28 (총 7일) (실 근무 45시간)
사용 기술 스택: C++ 14, JetBrains Rider
최배성 - 총괄 김명현 - 몬스터 김현승 - 전투 시스템 강명우 - 플레이어 송건호 - 아이템
2. 프로젝트 요구사항 달성도
플레이어 캐릭터 ✅
몬스터 ✅
전투 시스템 ✅
레벨업 ✅
아이템 ✅
게임 로그 확인 ✅
몬스터 보스전 ✅
상점 시스템 ✅
3. 개인 성과
최배성
프로젝트 관리 규칙 선언
깃을 활용한 브랜치 관리 및 Pull Request 선언 형태로 컨플릭트 방지
전반적인 설계 및 코드 흐름 관리
팀원들과 소통하며 코드 작성 및 설계에 필요한 팁을 공유함
멀티 콘솔 시스템 도입
여러개의 창을 띄워 가시적으로 보기좋기 구성함
메모리 누수 점검 & 스마트 포인터 사용
일반 포인터를 사용하던 부분을 스마트 포인트로 변경함으로써 메모리 누수 걱정이 없어짐
김명현
성과 1 - 객체지향적 기술
Singleton과 Interface 등의 객체지향적인 핵심 기술 패턴을 익힐 수 있었고좀 더 c++스러운 코딩을 할 수 있게 되었다.
성과 2 - git 협업
gitHub 등의 업무 공유 프로그램의 워크플로우를 익힐 수 있었고, 협업에 대한 적응을 하면서 데이터관리 시 어떤 점을 신경써서 주의해야하는지 등을 알 수 있었다.
성과 3 - 사전 계획의 중요성
프로젝트의 설계 및 기획 단계가 얼마나 중요한지 알게되었다. 왜냐하면 사전에 구현하고자하는 기능이나 세계관에 따라서 목적에 맞게 단위를 쪼개고 역할을 분배하여 분배 된 내용에 따라서 필요한 준비물들을 사전에 설정해놓으면 각자 맡은 역할에 맞게 기능을 구현하는 일에만 집중하다보면 어느새 완성이 되어있기 때문이었다. 이는 더 큰 프로젝트일수록 더욱 더 중요한 사안이라는 생각이 들었고, 계획이 세밀하고 완성도가 높을 수 록 로직의 유지보수나 확장성이 높아지기 때문이다. (당연히 중간중간에 방향이 바뀌거나 계획이 수정되거나 팀원간의 대화를 통해서 기능이 달라질 수 도 있긴하다.)
김현승
Git을 사용하는 방법과 개발 협업과정에 대해 이해함
새로운 C++문법 및 기술에 대해 학습함
협업과 소통의 중요성을 깨달음
강명우
깨달음
Source Tree를 활용한 Git 활용 : → 브랜치 생성, 관리, 병합 밑 pull request와 review
→ 팀 컨벤션 익숙해 지기 팩토리 패턴 : unordered map을 통한 생성 패턴 스마트 포인터 : 특히 unique_ptr의 활용법 숙지 밑 주의 사항 깨달음 협업 시 필요한 요청 사항 정리법
송건호
협업 프로그램을 사용 함으로 git에 대한 이해도
협업에서 팀원간 소통의 중요성과 전체적인 흐름을 느낌
C++ 기본 지식 필요성
작업 들어가기 전 전체적인 틀 작성 필요성
<aside> 
4. 스프린트 운영 회고
아쉬운점
최배성
과도한 브랜치 생성 요구
이슈 트래킹을 위해 브랜치를 남겼지만, 결과적으로 확인하기 힘들었다.
업무 분배 미스
도움을 줬다고 하지만 개인 역량 차이로 부담감을 느끼신것 같다.
독단적인 프로젝트 진행
개인적인 설계를 강요함 프로젝트 완성을 위해 다른 분들의 업무를 가져감
김명현
고급적인 테크닉 부족
좀 더 고급적인 테크닉이 부족해서 처음에 큰 흐름에서 주고받는 사고방식 흐름을 잘 따라가지 못했던것이 아쉽게 느껴졌다. 그로인해서 몬스터 매니져라는 부분은 후반에 생겨났기에 그러한 테크닉적인 부분을 좀 더 다듬고 기본 배경 지식을 쌓기위해서 서고 등을 많이 참고해야겠다고 생각했다. 워낙에 뛰어난 분들과 협업을 하게 되어서 그런 부분에 대한 개발 지식들을 얻을 수 있어서 좋았고 의사소통도 활발히 진행되었던 팀이라서 인상깊고 좋았고 다시 만나더라도 의사소통이나 호흡면에서 좋은 인연이 될것같았다 (물론 내가 더 큰 성장을 이룩했을 경우)
김현승
초반에 팀원과 소통을 하지 않고 너무 혼자 하려해 전투시스템을 엉망으로 만들었었다. -C++의 새로운 기능과 문법들에 대한 이해와 학습이 많이 부족했다.
강명우
GameManager 미활용
저는 보통 ManagerClass를 총괄하는 Manager들의 Manager 총괄 매니저를 두는 것을 선호합니다
만드는게 Game이다 보니 이름은 GameManager로 하곤 했죠
총괄 manager를 두는 이유는 3가지가 있습니다
초기화 순서의 꼬임
저희는 Manager를 GetInstance( )라는 함수를 통해 생성 했습니다
여기서 발생할 수 있는 문제는 보통 싱글턴 끼리 서로를 사용할 때 생깁니다
PlayerManager가 생성될 때Inventory싱글턴의 데이터를 참조해야 하고,Inventory가 생성될 때ItemManager를 참조해야 한다면 어떻게 될까요?바로 nullptr이 발생할 겁니다
하나의 총괄 매니저가 모든 Manager의 생성을 관리 하는 편이 좋습니다
전역 상태 관리 용이
혹시 작업 하시면서 어떤 클래스가 어떤 클래스에 의존 하는 지 혼동 되신 적이 있으셨습니까?
코드 여기저기에
PlayerManager::GetInstance(),MonsterManager::GetInstance(),ItemManager::GetInstance()등이 흩어져 있으면 어떤 클래스가 어떤 매니저에 의존하고 있는지 추적하기가 힘들어집니다.
지금은 프로젝트 규모가 매우 작다 보니 어렵지 않으셨을 수도 있겠지만
프로젝트가 커지면 문제가 생길 확율이 높습니다.
해제 순서의 제어 불가능
지금 프로젝트는 싱글톤이 중간에 해제 되지는 않기 때문에 문제가 될 일이 아니였지만,
목적에 따라 싱글턴이 게임 도중에 해제되는 일도 있습니다.
이때 static class는 동시에 해제 될 때 소멸자가 불러오는 순서가 랜덤이기 때문에…
의도한 소멸자 순서를 불러오기 어렵습니다.
총괄 매니저가 소멸의 순서를 정해주는 게 좋겠죠
송건호
아쉬운 점
C언어에 대한 전반적인 공부 필요
협업 프로그램에 대한 이해도
팀원 간 소통에 적극적으로 참여
주제에 대한 전체적인 정확한 흐름 파악
5. 최종 프로젝트 마무리 후기
최배성 - 다들 소통에 잘 참여해주셔서 프로젝트를 수월하게 마무리할 수 있었던것 같습니다.
김명현 - 좋은 인연이었고 다들 편안한 분위기로 대화에 임해주셔서 감사해여
김현승 - 솔직히 버스탄것 같습니다 죄송하고 고맙습니다
강명우 - 다음 프로젝트에서는 싱글턴을 쓰지 않겠습니다
송건호 -첫 프로젝트였는데 좋은 분들 덕분에 너무 좋은 경험이 되었습니다 저 또한 버스를 그냥 탔기 떄문에 죄송하고 감사합니다
이 노트는 보도·비평·교육·연구 목적으로 작성되었습니다. 저작권 문의가 있으시면 에서 알려주세요.