오늘은 기다리고 기다리던(?) 미니 프로젝트 발표의 장이었습니다.
짧은 기간이었지만 결과물은 문제 없이 나올 수 있어서 다행이었다는 생각이 들면서 다른 무엇보다 최종적이 회고가 필요하다는 생각이 들었습니다.
개발했던 노션에도 작성하였지만, 추가적으로 TIL 를 작성하면서 좀 더 깊게 개인적으로 회고 해보고자 합니다.
( 어찌보면 정든 24조 노션... )
본격 적인 회고 전에 어떻게 회고를 진행하는게 좋을까 라는 생각이 먼저 들었습니다. 그래서 "팀 프로젝트 회고" 에 대한 자료를 찾아보던중 오늘 TIL 강의 시간에 들었던 **"문시해알"** 과 어찌보면 동일한 메커니즘인 **KPT 회고** 방식에 대해 알게되어서 먼저 간단하게 정리하고 회고를 진행해보고자 합니다
< 개인회고를 위한 Keep / Problem / Try >
KPT는 Keep / Problem / Try 의 약자로 이 세단계로 나누어서 해당 프로젝트에 대해 회고하는 것을 말합니다.
일반적으로는 4인 이상의 팀원으로 진행중인 프로젝트에서 프로젝트 마지막날 혹은 중간에 회고를 통해 협업 과정을 이끌어 내는 것이지만
이 또한 개인 회고 방식에도 적절하다고 생각합니다. (문제점/시도해본것/해결방법/느낀점 과 유사해서.. )
각 구간에 대한 간단한 설명은 아래와 같습니다
- Keep : 프로젝트 완료 후에도 간직하고 싶은 잘한 내용
- Problem : 프로젝트 중 겪었던 기술/소통/협업 등에서 겪을 수 있는 모든 종류의 문제점, 프로젝트 완료 후에도 아쉬움으로 남는 것
- Try : Problem 중 해결 된 사항에 대한 해결 방법과 해결되지 못한 사항에 대한 피드백
그럼 이제 이를 바탕으로 실제적으로 이번 미니프로젝트에 대한 회고를 작성해야 겠죠?
< 미니 프로젝트 : 이삿짐 센터 르탄이 개인 회고 >
[ 프로젝트 설명 ]
- 유니티 10기 미니 프로젝트로 진행한 카드 뒤집기 게임의 개선버전을 만들어 보면서 기본적인 git 사용과 협업, 컨벤션에 대한 것을 익히고. 필수 기능과 추가적인 기능을 구현 → 최종적으로 빌드까지 만들어 발표 해 보는 일련의 개발 전체 과정에 대한 체험판 이었습니다.
- 저희는 필수에 더해 추가적인 게임 로직, 연출, 사운드, UI 관리에 신경 썼으며. 단순히 기능 개발에서 멈추지 않고 최종적인 PC, APK 빌드를 만드는 것 까지 성공해냈습니다. 이러한 프로젝트 전반에 대한 경험은 앞으로 있을 긴 개인 / 팀 프로젝트 과정에 있어서 주줏돌이 될 수 있을 것이라 생각합니다.
[ K P T ]
- Keep :
! UI 자동화 !
( 그렇게 많이 프로젝트를 했는데도 처음 쓰는 것 같은 enum... 그래도 UI 자동화는 잘 구현되어서 기분이 좋습니다 )
- UI 자동화 기술에 대해서 관심이 있었고, 이를 처음으로 직접 구현해 보았는데 생각보다 결과물이 잘 나와서 기존에 작업하던 다른 프로젝트에도 패키지 형태로 적용 할 수 있겠다는 생각이 들었습니다. 또한 개인 프로젝트만 1년 넘게 진행하다보니 협업에 대한 감각이 녹슬었다고 생각했는데, 그래도 문제 없이 원활하게 프로젝트를 진행 할 수 있어서 만족스럽습니다.
! 프로퍼티 사용 !
( 쉽지만 잘 사용지 않았던 프로퍼티 )
- 또, 개인적인 버전으로 SoundManager를 구성해 보면서 그 동안 잘 사용해보지 않았던 프로퍼티를 상황에 맞게 적용시켜 보았습니다. 접근 제한자처럼 외부에서 특정 함수나, 프로퍼티를 통해서만 Set / Get 을 받아 올 수 있게 함으로써 OOP의 특징인 캡슐화가 잘 적용되도록 개발했다고 생각합니다.
Problem :
( Git Flow를 자만하지 않고 미리 좀 알아보고 갔더라면...)
-
역시나 예상했던대로 git 병합 과정에서 문제가 발생했습니다. 좋은 소식은 그래도 별도의 merge 브랜치를 만들었기 때문에 씬이 아예 파괴되는 최악의 상황은 빗겨나갈 수 있었다는 것이고, 안좋은 소식은 그 병합 브랜치 (Dev 브랜치) 의 부모 자식 설정이 잘못되어서 병합 충돌이 발생했다는 점이 있었습니다.
-
또 다른 문제라고 생각 할 수 있는 것은 그동안의 경험 때문인지 너무나 독단적으로 팀내 결정을 진행한게 있지 않을까 걱정입니다. 이런 프로젝트를 진행하게 되면 몸이 앞으로 쏠리는 경향이 있는데 처음으로 프로젝트를 진행해 보는 분이 많은 미니 프로젝트에서 과도하게 발언한 것은 없는지 불안으로 남습니다.
-
다른 부분으로는 병합에 대한 문제를 혼자 해결해 버린 것이 혹여 다른 분들의 경험을 방해한 것은 아닌지 걱정으로 남았습니다. 어떻게 보면 처음 프로젝트를 진행해보면서 GIT으로 프로젝트를 터쳐보기도 해야 경각심도 생가고 주의하게 된다고 저 개인적으로는 생각하는데, GIT 담당자라는 이유로 그냥 혼자서 해치워버린것 아닌가 하는 아쉬움도 남습니다.
- Try :
( 그동안 개인프로젝트만 한다고 무뎌졌던 협업 감을 다시 잡아야한다! )
- 먼저 git 병합 과정에서의 문제 해결은 앞서 말했듯 별도의 병합 브랜치 merge branch 를 만듦으로써 해결했다고 생각했습니다. 시도는 좋아서 씬 파괴까지는 막을 수 있었으나 병합 과정에서의 충돌이 발생했고, 이에 대한 해결책이 이미 나와있다는 사실도 알게 되었습니다. 지금처럼 main 에서 개발과 병합의 브랜치를 형제관계로 설정하는 것이 아니라 main → dev → 기능 구현 이러한 과정으로 브랜치를 생성하면 병합 문제를 현저하게 줄일 수 있다는 것입니다. 또한 꼭 머지 기능을 통해서 병합 할 필요 없이 패키지나 프리팹 단위로 구성해서 병합을 진행해도 큰 문제가 없다는 튜터님의 말씀이 기억에 남습니다.
- 협업 중 몸이 쏠리는 문제에 대해서는 깊게 인식하고 있어서 최대한 자제하려고 하고 의견도 많이 물었는데, 아무래도 상황이 상황인지라 직접적으로 의견을 내는게 어려울 수도 있었다고 생각합니다. 그래도 적극적으로 의견 제시해주시는 분이 있어 다행이라고 생각은 들었습니다만, 특히 최종 빌드 완성에 집착하여 추가 기능등에 대해서 반영 기한을 빡빡하게 정한게 아닌가 하는 아쉬움은 남았습니다.
- 느낀점 :
누구에게나 첫 프로젝트가 있듯, 저의 첫 프로젝트를 돌아보게 되는 미니 프로젝트였습니다. 처음으로 개발할 당시 일을 안하는 기획자 팀장과 저를 포함한 처음으로 C#을 손대보는 개발자 2명을 이루어진 프로젝트… 4개월간 열심히 하여 최종적인 결과물은 잘 나오긴 했지만 전혀 협업했다는 느낌이 들지 않는 프로젝트였습니다. 하지만 이번 프로젝트는 많은 분들이 처음으로 협업 프로젝트를, 그것도 GIT 을 이용해서 진행하는데 큰 충돌이나 브랜치 삭제, 마감 기한 미달성 등의 문제가 생기지 않은 것을 보면 정말 기분좋게 마무리 되었다고 생각했습니다.
