나의 이번 프로젝트는 왜 망했는가

서론

제목에 적혀있듯이 이번 프로젝트는 두 달 넘는 시간을 들였지만 배포조차 못하고 망했다.

 

실패한걸 뭘 정리까지 해두나 하는 생각이 있었는데, 심심할 때 42 슬랙에서 저장해둔 글을 읽다가 실패도 정리해둬야겠다는 생각이 들었다.

크흐흑 존경합니다 멘토님

 

실패했다고 관심 끄고 버려두는 게 아니라 왜 실패했는지를 한 번 더 생각해보는 시간을 갖기 위해서 어제 몇몇 팀원들과 포스트 모템을 했고 그 내용을 간추렸다. 다음에 프로젝트를 또 할 텐데 그때 같은 이유로 망하면 안 되니까 경계의 의미로 기록을 남겨두려 한다.

 

상세한 내용은 노션에 적어뒀지만 문제가 될만한 부분은 빼고 다른 사람들을 위한 내용은 더해서 다시 글을 적는다.

 

 

프로젝트 소개

https://youtu.be/9Gv8oJ2OSV4

https://github.com/economicus

Economicus

 

처음 프로젝트에 참여할 때의 소개글과 최종본의 데모, 그리고 깃허브 링크를 가져왔다. 진행과정에 문제가 생겨서 실험실과 프로필 기능을 우선 완성해서 배포하려 하였는데, 영상에서 시연하지 않은 버그로 인해 배포에 의미가 없을만한 상황이라 배포하지 못했다.

 

나는 이 프로젝트의 프론트엔드 팀장을 맡아서 팀원 둘을 이끌고 TypeScript + React 로 필요한 기능들을 구현했다. 아예 웹을 모르는 상태에서 합류하다 보니 필요한 기술을 배우고 코딩하는 것으로도 벅찼는데, 성공적으로 완성할 수 있게 함께 노력한 프론트엔드 팀원분들께 감사했다.

 

 

진행과정

이 프로젝트는 1월 11일에 모집을 시작해서 15일에 팀 빌딩이 완성됐다. 처음에는 퀀트팀과 소셜팀으로 나눠서 12명 규모의 팀이었다. 

 

17일에 첫 회의(OT)를 했고 각자 공부할 것을 공부하면서 기획을 기다리기로 했는데 기획이 코드로 옮길 수 있을 만큼 구체화되어있지 않아서 내가 그 작업을 했다. 

 

https://docs.google.com/presentation/d/15Kw2XtshKFtLZM5W3m9VSIT7rqmDJEXThoRQthG6mkc/edit?usp=sharing 

이코노미쿠스 목업&기능명세서

 

추상적인 기획을 목업과 기능 명세서로 구체화한 게 1월 28일쯤이었고 이 기획을 바탕으로 바로 코딩을 시작했다.

 

2월 초에 사람들이 나가면서 기획을 축소하고 팀도 FE / BE로 다시 나눴다.

 

3월 중순까지 기능 개발을 완료하고 버그 픽스를 진행했는데, 처음에 배포하려던 3월 25일에는 배포 문제로 1주일이 늦춰졌고, BE 측에서 개인 사정으로 인해 두어 가지 이슈를 해결하지 못하면서 사용할 이유가 없는 웹페이지라고 생각되어 배포 취소로 프로젝트를 종결했다.

 

 

잘 진행된 부분들과 그 이유

1. FE팀에서 팀 프로젝트를 해본 사람이 드물어서 처음 1~2주 정도 한 사람 컴퓨터에서 VS Code Live Share 를 이용해서 개발했는데 이후에 개발 컨벤션을 특별히 지정하지 않았음에도 서로 자연스럽게 적응할 수 있었다.
2. 팀 리빌딩 당시에 인원이 줄어든 만큼 기능을 더 적극적으로 줄여서 기능 완성까지 진행할 수 있었다고 생각한다. 그러지 않았으면 기능 개발도 늦춰지고 버그도 더 많았을 것 같다.
3. 깃을 적극적으로 사용하기 위해 PR이나 이슈 등의 기능을 일부러 더 자주 사용하려고 했는데, 그 과정에서 이슈 트래킹 등이 자연스럽게 이루어진 것 같다.

세 명 다 골고루 이슈를 적은게 굉장히 좋았다고 생각합니다.

 

 

망한 이유로 추측되는 것

1. 다들 의욕이 넘치는 프로젝트 초반에 더 많은 작업을 진행해서 나온 산출물을 가지고 성취감을 느끼며 계속 작업을 진행해야 하는데, 처음에 기획이 늦어지고 언어 공부에 시간을 너무 길게(2주 이상) 쓰다 보니 각자의 의욕을 많이 깎아먹은 상태에서 작업을 하다가... 팀이 하나 터진 게 이후 일정과 의욕에 큰 문제로 작용했다.
2. 각자 개발 일정을 미리 알리지 않고 진행한 것이 아쉽다. 몇 명은 다른 일 없이 계속 프로젝트에 열중하고 다른 일부는 3월부터 다른 일정이 생겨서 프로젝트 진행에 문제가 생겼는데, 이걸 미리 알았으면 중요한 기능을 더 빨리 개발하고 버그를 잡았어야 하지 않을까
3. 일부를 마이너한 언어로 선택한 것이 문제였던 것 같다. 해당 부분을 개발하거나 픽스할 수 있는 사람이 한 명밖에 없다 보니 한 사람에게 과중한 업무가 쏠리게 되었고, 이후에 해당 버그 수정을 못해서 프로젝트를 접게 된 원인이었다고 생각한다.
4. 에러를 발견했을 때 담당자에게 바로 물어보지 말고 상세한 내역을 적어서 슬랙 공개 채널에 문의를 남기고 해당 팀 전체 인원이 확인하고 고칠 수 있었으면 조금 자연스럽게 분업이 됐을 것 같은데, 다들 버그를 발견하면 바로 DM으로 제보하다 보니 분업이 잘 이루어지지 않았다.
5. 미리 기능마다 무엇을 테스트할지 정해두고 작업을 하지 않아서 화면을 다 만들어두고 나중에 시간이 남을 때 테스트하다가 뒤늦게 버그를 발견해서 버그 픽스가 기능 개발에 비해 굉장히 늦게 이뤄진 것 같다.

좋다고 한 이유가 뭔가 있었던 것 같은데 결국 그런게 중요한게 아니라는걸 배웠습니다.

 

 

개선해야 할 부분

1. 모두의 의욕이 남아있을 때 더 많은 작업을 진행하기 위해 노력해야 할 것 같다. 기획이 완성된 상태에서 모집하거나, 기획이 없다면 와이어 프레임을 가지고 해당 언어와 플랫폼에 익숙한 사람들을 뽑아서 첫 산출물이 빠르게 나오도록 진행해야겠다. 그리고 비대면 환경에서는 짧게라도 자주 만나야 프로젝트에 대한 참여도가 줄어들지 않는 것 같다.
2. 프로젝트의 일정을 정할 때 팀원들의 향후 일정을 미리 물어보고 모두 공지된 상태에서 진행을 한다면 모두의 시간이 남을 때 더 빠르게 작업할 수 있어서 이후에 개인 일정으로 프로젝트 일정이 밀리는 일이 줄어들 것 같다.
3. 괜히 회사에서 메이저한 언어를 사용하려고 하는 게 아니었다는 걸 절실히 깨달았다. 사실 회사에서는 사람 뽑기가 힘들어서 그런거 겠지만, 프로젝트에서도 중간에 마이너 한 언어에서 문제가 생겼을 때 해결할 인력을 구하는 것이 불가능했다.
4. 비대면 환경에서는 비동기적인 작업을 더 활발히 진행할 수 있는 방법들을 미리 정해놓고 실행해야 할 것 같다. 서로 물어보는 것이 껄끄러워서 회의시간까지 작업을 미루는 경우가 많았는데, 일정이 늦어진 이유였다고 생각한다.
5. 기획을 한 이후에 바로 개발에 들어가지 말고 화면별/기능별로 어떻게 테스트를 해서 통과가 되면 완성인지를 미리 생각해서 적어두고 작업을 해야 할 것 같다. 그래야 버그 수정이 바로바로 이루어질 수 있을 것 같다.

다음 프로젝트를 TDD로 짜면 5번은 바로 해결할수있을것같습니다.

 

 

결론

배포를 못한 게 아쉽긴 아쉽다. 앞으로 개발할 것도 많이 남아있고 더 기여할 수 있는 프로젝트였다고 생각하는데, 결국 이렇게 뭔가 섭섭하게 종결이 났다. 사실 아쉬운 건 모든 프로젝트가 그렇겠지만, 이건 배포 이후에만 배울 수 있는 내용들을 접하지 못해서 더 그런 것 같다.

 

프로젝트에서는 누구 하나가 문제가 있으면 다 멈춰야 한다는 걸 머리로는 알면서도 내가 뭔가 더 잘했으면 좀 더 낫지 않았을까 하는 아쉬움이 남는다.

 

다음 프로젝트는 끝낼 때 끝내더라도 좀 깔끔한 기분으로 끝낼 수 있도록 의식하고 노력해야겠다.