이전에 “클러스터노이드"라는 게임을 만드는 데 참여한 적이 있습니다. 개발에서 프로그래머로 참가하며 느낀 점을 적어 봅니다. 원 문서는 2018년 8월 23일 동아리 회의에서 발표할 때 사용했습니다. 최소한의 포맷 변경 및 익명화만 진행했습니다.

발표에 사용한 발표자료는 마찬가지로 최소한의 수정만 하여 여기에 올려두었습니다.

클러스터노이드 개발 리뷰

잘 된 점

• 개발을 일찍부터 시작했다. 다행히도 내가 휴학이고 (메인 기획자 겸 디자이너 겸 프로그래머, 지금도 직장인) 도 직장인이라 방학에 맞춰서 시작할 필요가 없었다. 최초 커밋 일자: 12월 3일.
• 초반부터 기획을 확정하고 들어갔다. 명확하게 어떤 게임을 만들지 생각을 했기 때문에 실제 코딩을 할 때에도 “어떻게 만들어야 한다”라는 것도 쉽게 구상을 할 수 있었다.
• 포스트 프로세싱 에셋을 통해, 빠르게 예쁜 그래픽을 구현할 수 있었다. 동아리의 다른 프로젝트에서도 포스트 프로세싱 에셋을 활용한다면 예쁜 그래픽을 만들 수 있을 것이다.
• AI의 서로 다른 기능을 잘게 분할해 컴포넌트로 뺴 놓는 식으로 구현했는데, 재사용성이 높아졌다는 점에서 긍정적으로 생각한다.
• 3D 모델링을 할 수 있는 동아리원이 참여해, 높은 수준의 애니메이션과 3D 모델링을 동아리에서 활용할 수 있었다.
• 발표 자료의 퀄리티도 매우 높게 만들어졌다고 생각한다.
• 시네머신 애셋을 이용해 카메라워크를 만들었는데, 이와 같이 사용성도 좋고 확장성도 좋은 (무료) 애셋을 활용하면 원하지 않는 개발 부담을 줄일 수 있을 것 같다. not developed in here 신드롬을 극복하자. 바퀴를 재발명할 필요는 없다.
• 사운드 매니저 시스템은 (다른 동아리원이) 만든 것을 가져와 사용했는데 좋았다. 다른 동아리 프로젝트에서 좋은 부분이 있다면, 먼저 허락을 받고, 적절하게 고친 다음 가져와 사용하면 좋을 것 같다. 바퀴를 재발명할 필요는 없다(2).
• 인싸 계산 등, 알고리즘을 다루어야 할 일들이 있었다. 척수반사코딩이 불가능하다 보니 어쩔 수 없이 계획을 하고 코딩을 하게 되었는데, 덕분에 나중에 버그를 고쳐야 할 일이 적어진 것 같다. 생각을 하고 계획을 하고 코딩을 하는 습관을 들이자.
• 그러면서도, 처음부터 너무 최적화를 생각할 필요는 없는 것 같다. 일단 구현을 해 놓고, 최적화/기능 추가는 그 다음에 생각해야 프로그램을 짤 수 있는 것 같다.

잘 못된 점

• 기획/프로그래밍/모델링 사이에 지연이 발생했다. 소통 사이클이 며칠 단위였기 때문에, 구현이 어렵거나 피드백이 필요할 경우 그 결과가 반영되는 데 긴 시간이 걸렸다. 기획을 하고, 모델링을 가져와 프로그래밍을 하는 데 긴 시간이 걸렸다.
• 회의 진행이 온라인으로만 이루어지다보니 의견 개진이 원활하지 못했고 참여가 소극적이 되는 문제가 있었다. 전반적으로 소통이 부족했다. 결론적으로, 카카오톡이나, 구글 드라이브 채팅으로 회의를 하는 것은 적절하지 않다고 생각한다. 슬랙이 좋은 것 같다(다만 모든 회원들이 참여하도록 해야 한다)
• 맵을 제작하고 플레이테스트를 실시할 시간이 부족했다. 실제 맵을 조금 더 빨리 만들어서 테스트를 했다면 더 재미있게 만들 수 있었을 것이다.
• 프로그래밍 인원이 부족했다. 많은 기능을 한 사람(으흠)이 만들었기 때문에 효율성이 높다고도 할 수 있었겠지만, 다른 한 편으로는 한 사람의 노력에 의존하기 때문에 이런 것은 지속되기 어렵다고 생각한다. 일을 잘 분배하는 작업도 필요하다고 생각한다.
• (주로 내가) 다른 사람이 구현한 기능을 이해하지 못해, 간단한 버그라도 ticket을 넘겨서 처리해야 하는 경우가 있었다. 상호 코드 리뷰를 실시하거나, 주석을 달아놓는 것이 좋을 것이다.
• 트렐로나 구글 드라이브 등의 작업 트래킹 도구를 사용하지 않아, 각자 어떤 일을 하고 있고 어떤 일을 해야 하는지, 어떤 일들이 남아있는지 파악하기 어려웠다. 또한 마일스톤을 팀 단위에서 작성하고 관리하는 노력이 부족했던 것 같다.
• 여전히 제출 1주일 전에 대부분의 일이 몰려 있는 문제를 발견했다. 가능할지는 모르겠지만, 일의 배분을 조금 더 고르게 하면 부담이 줄 것이라고 생각한다.
• 일을 하고 사라진 사람들이 왜 사라졌는지, 어떻게 하면 남아서 개발을 하게 할 수 있을지도 생각해야 한다.
• 파일이 버전관리가 되지 않았고, 폴더 정리에 대해서도 방식을 합의해야 할 것 같다. 예를 들어 작업중인 파일과 작업 완료된 파일을 구분한다거나. 그 외 네이밍 컨벤션에 대해서도 공부해야 할 것 같다.
• 필드 추상화/캡슐화. 컴포넌트의 응집도를 낮추자.