다사다난했던 2학기 첫 프로젝트가 끝났습니다.
잘했던 점도 있고 부족한 점도 있었지만 이번에는 부족한 점을 위주로 회고해보도록 하겠습니다.
많이 부족했던 점과 사소한 아쉬운점까지 모두 다 허심탄회하게 돌아보는 시간이 될 것입니다.
1. git
미숙한 git 사용이 프로젝트 시간관리에 가장 큰 적이었습니다.
기능별로 나누지 않은 브랜치로 인해 일어나는 충돌, 서로 다른 브랜치에서 버전이 달라 일어나는 충돌 등 갖가지 충돌을 해결하는데 너무나 많은 시간을 쏟아부었습니다.
실제 프로젝트를 발전시키는 시간이 아니라 문제해결(제대로된 문제가 아닌)에만 집중하다보니 개발 진행이 루즈해지고 서로가 지쳐가는 원인이 되었습니다.
또한 commit message를 제대로 작성하지 않는 습관이 들어버려 어떤 기능이 업데이트되었는지, 어떤 수정이 있었는지를 알 수가 없었던 점이 어려웠습니다. 이는 후술할 소통의 부재에도 큰 영향을 미쳤다 생각합니다.
- git 컨벤션, git 플로우를 명확하게 작성하고 전략을 세워 모두가 알고 있어야 합니다.
2. api 명세서
저희는 api명세서를 swagger를 통해서 사용하고자 했습니다. swagger가 있으면 api 명세서를 쉽게 확인할 수 있고 테스트또한 가능하기 때문이죠.
하지만 문서화된 api명세서가 없다는 점은 소통에 있어 어려움을 야기시켰습니다.
이 api가 어떤 기능을 가지는지, input은 무엇인지, output은 무엇인지, url은 어떻게 되는 것인지 swagger로도 알 수 있지만 여기에는 큰 단점이 존재했습니다.
바로 swagger는 개발하면서 계속해서 수정된다는 점이었습니다.
해당 api를 개발하는 사람이 api를 수정해버리면 client 파트에서도 수정된 사항에 맞춰서 변경해야하는데, 후술할 소통의 부재가 근본 원인이긴 하지만, 서로 공통적으로 맞춰나갈 최종 목표가 없이 계속 변경되는 api 명세서를 보며 개발하다보니 서버 개발이 마무리 될 때 까지 클라이언트 개발이 마무리되지 않는 단점이 생겨버렸습니다.
- 문서화된 api 명세서가 꼭!!! 필요합니다.
3. 중구난방인 문서들
문서들이 한 곳에 모여있지 않아서 겪은 어려움이 있습니다.
ERD를 보다가, 아키텍처를 보다가, 기능 명세서를 보다가....
각각의 문서들이 어디에 있는지 찾기도 어려웠을 뿐더러 한곳에 모여있지 않아서 각자 수정도 어려웠습니다. 또한 맞춰가기도 어려웠죠,,,
- 모든 문서는 한 곳에 뭉쳐놓고 상시 확인할 수 있어야 합니다.
4. Jira
지라를 사용하여 팀원들이 각자 어떤 업무를 수행하고 있는지, 현재 업무의 진척도가 어느정도인지 확인하며 개발을 하자고 다짐했었습니다.
하지만 개발을 해나가며 Jira를 통한 소통과 확인은 물건너갔고 결국에는 구두로 개발 진행 상황과 수정사항을 말하게 되었습니다.
역시나 소통의 부재가 근본 원인이었지만,,,, Jira를 통해 물어보지 않아도 확인할 수 있는 부분을 확인하지 못한 것이 아쉬웠습니다.
- Jira를 적극적으로 활용하자!!
5. 스프린트
매주 새로운 스프린트를 시작하였는데, 스프린트 기간동안 우리가 목표로하는 바를 제대로 정하지 않아서 개발이 늘어지는 결과로 이어졌습니다.
각자 대충 견적만 내고 세부적인 계획이 없어서 두루뭉실하게 개발을 하게 되었습니다.
마무리되지 않은 업무는 어떤 부분이 마무리되지 않았는지 명확하게 짚고 넘어가지 않고 대충 마무리 되지 않았다만 넘기다보니 같은일을 반복하게 되었습니다.
- 스프린트의 목표와 세부계획을 확실하게 짜자!
6. 코드리뷰
저희 팀은 개발이 바빠서(루즈했지만 바빴습니다) 코드리뷰를 전혀 진행하지 못했습니다.
핑계일수도 있으나 누가 어떤 개발을 하고있는지도 제대로 파악하지 못했는데 코드리뷰까지 할 여유가 없었죠...
안타까운점은 프로젝트에서 자기가 맡은 파트 이외에 다른 사람이 무엇을 했는지 전혀 알지 못한다는 것이었습니다.
또한 더 좋은 코드, 더 좋은 성능을 만들 수 있었겠지만 코드리뷰가 이루어지지 않아서 부족한 점을 보완하지 못했습니다.
- 코드리뷰는 시간이 없다고 넘어가지말고 꼭 진행하자!!
7. 배포
우리는 CI/CD 구축을 하지 않고 수동배포를 진행했습니다.
배포에 대한 지식이 있던 사람도 전무하였고, 수동배포로 배포의 과정을 익혀보자는 생각에 수동배포를 선택했습니다.
결과적으로 배포에서는 큰 실패는 없었지만 사소한 아쉬움이 남는 점은 배포과정에서 배포 인력이 빠져서 1명이 부족한 상태로 막판 스퍼트를 달렸다는 점입니다.
수동배포를 하게되면 버전이 바뀔때마다 빌드 - 배포의 과정을 사람이 해야하는데, 막판에는 계속된 수정과 수정된 버전을 이용해야하는 각 서버의 사정 때문에 계속해서 빌드-배포의 반복이었습니다.
- CI/CD를 미리 구축해서 편하고 빠른 배포를 하자..
8. 소통의 부재
만악의 근원
소통이 부족해서 git 관리, api 명세서, 코드리뷰, Jira 등의 모든 문제가 발생했습니다.
각자 개발에 바빴기 때문일 것입니다.
하지만 그로인해 서로 개발한 것이 맞지 않아 연결하는 데 너무많은 시간을 쏟아부었고, 소통의 부재는 곧 프로젝트의 멸망으로 이어졌습니다.
- 모든 파트에 대해서 소통하고, 내가 뭘하는지, 다른 팀원이 뭘 하는지 모든것이 모든 팀원의 머리속에 있어야합니다.
마무리
이렇게 부족한 점만 적어보다보니 어떻게 프로젝트를 완성했는지 의문이 들긴 하지만 결국에는 마무리되었습니다.
아쉬웠던 점들을 해결하면 더 나은 프로젝트를 완성할 수 있을거라 생각합니다.
