팀프로젝트 회고
KPT와 팀원별 피드백을 바탕으로 팀프로젝트의 협업 과정과 개선점을 돌아봅니다.
이번 팀프로젝트에서는 C++로 텍스트 RPG를 제작했다. 여러 팀원이 캐릭터, 상점, 몬스터 등 각자 맡은 기능을 구현하고 하나의 게임으로 합치는 과정을 경험했다.
프로젝트를 마무리하며 팀 전체의 경험을 KPT(Keep, Problem, Try) 방식으로 정리했다. 잘 유지하고 싶은 부분과 실제로 겪은 문제, 다음 프로젝트에서 시도할 개선책을 돌아본 뒤 각 팀원의 개인 회고도 함께 기록했다.
프로젝트 플레이 영상
KPT 회고
| 항목 | 내용 |
|---|---|
| Keep | 역할에 맞는 브랜치 사용 각자 담당 기능에 따라 features/Characters, features/shop, features/monster_boos 등의 브랜치를 나누어 작업했다.PR(Pull Request) 통한 코드 병합 저장소 소유자만 main 브랜치에 직접 반영하고, 팀원들의 코드는 PR과 코드 리뷰를 거쳐 병합했다.코드 컨벤션 공유 프로젝트 문서 상단에 코드 컨벤션을 정리해 팀원들이 같은 기준을 참고할 수 있도록 했다. 공용 유틸리티 분리 Tools::GetIntRange(), Tools::WaitForKey()처럼 여러 곳에서 사용하는 기능을 별도의 유틸리티 파일로 분리했다.상속 구조 활용 모든 몬스터가 Monster를 상속하도록 구성하고, Character, Monster, Slime 등이 Battle의 전투 기능을 상속하도록 설계했다. |
| Problem | 충돌과 병합 이후의 컴파일 오류 PR에서 코드 컨벤션과 객체 지향적인 구조, 중복 코드 등을 검토했지만 병합 후 컴파일 오류가 발생하기도 했다. 이후 PR을 요청하기 전에 최신 main을 먼저 병합하고 오류를 수정하는 방식으로 바꾸었으나, 프로젝트 막바지에야 정착했다. 다음 프로젝트에서는 이 절차를 처음부터 적용할 필요가 있다.코드 컨벤션 미준수 초반에는 컨벤션이 잘 지켜지지 않았지만, PR 리뷰를 진행하면서 일정 시점 이후부터는 점차 정착되었다. 잦은 함수명 변경 함수명을 바꾼 뒤 모든 호출부가 함께 수정되지 않아 오류가 발생했다. Visual Studio의 이름 바꾸기 기능인 Ctrl + R, R을 활용하고, 자동 변경으로 해결되지 않는 부분은 직접 확인해야 했다.Git 사용 경험 부족 Git에 익숙하지 않아 어려움이 있었지만, 직접 시도한 뒤 해결되지 않는 부분을 질문하고 함께 처리하면서 경험을 쌓았다. 꾸준히 사용하면 자연스럽게 개선될 문제라고 생각한다. |
| Try | 초기 기획과 업무 정리 개발을 시작하기 전에 구현할 기능과 업무 범위를 구체적으로 정리한다. 균등한 업무 분배 기능과 클래스를 더 작은 단위로 나누어 특정 팀원에게 업무가 몰리지 않도록 한다. 정기적인 소통 주기적으로 아이디어 회의와 진행 상황 공유 미팅을 진행한다. 틈날 때마다 개별적으로 확인하는 것만으로는 전체 상황을 공유하기에 부족했다. |
팀원별 개인 회고
| 팀원 | 회고 |
|---|---|
| 나 | PR(Pull Request)을 Git에 익숙해진 뒤 적용하려다 보니 PR을 프로젝트 시작 시점이 아닌 3일차 쯤 도입했디, 의도와 다르게 이것이 팀원에게 혼란을 키운 점이 아쉽다. 병합으로 코드 구조가 크게 바뀌었을 때 팀원들에게 변경 사항과 main 브랜치를 다시 받아야 한다는 점을 충분히 공지하지 못했다.업무량도 균등하게 나누지 못했다. 일부 담당자에게는 일이 적고 다른 담당자에게는 일이 몰렸는데, 클래스와 작업 단위를 더 세분화해 분배했어야 했다. |
| 팀원 A | 기한 안에 어느 정도까지 구현할 수 있을지 확신이 없어 하루하루 기능을 기워 붙이는 느낌으로 진행했다. 다음 프로젝트에서는 전체 구조를 먼저 고민해 조금 더 효율적으로 기능을 구성하고 싶다. |
| 팀원 B | enum을 활용해 아이템 효과를 적용하는 방법을 처음 배웠다. 여러 기능에 더 쉽게 접근하고 활용할 수 있도록 구성하는 방법도 익힐 수 있었다. |
| 팀원 C | 서로 맡을 일을 조금 더 구체적으로 정한 뒤 개발했다면 더 많은 기능을 구현할 수 있었을 것 같다. 담당한 역할의 범위가 다소 작았던 점도 아쉬움으로 남는다. |
| 팀원 D | 몬스터 클래스 작업을 수현 님이 대부분 담당했는데, 다음에는 직접 큰 틀을 설계해 보고 싶다. 결정할 일이 생겼을 때는 미루지 않고 그때그때 바로 이야기를 나눌 필요가 있다고 느꼈다. GitHub Desktop이 익숙하지 않아 많은 도움을 받았다. 앞으로도 프로젝트에서 계속 사용하며 익숙해져야겠다. |
| 팀원 E | 게임 매니저를 만들기 전에 필요한 기능을 먼저 정리하고 팀원들과 공유했으면 더 좋았을 것 같다. 게임 매니저 안에 너무 많은 기능을 구현하려 했다. 게임 매니저는 전체 흐름을 통합하고, 실제 기능은 각 담당 클래스에 두는 방향이 더 적절했을 것이다. 이번에는 AI 사용을 최대한 줄이려 했지만, 다음 프로젝트에서는 개발 보조 도구로 적극 활용해 보고 싶다. |
정리하며
다시 한 번 소통의 중요성을 깨닫는 계기가 되었다.