이번 SSAFY 2학기 공통프로젝트를 진행하면서 우리가 처음에 정했던 규칙들을 상기시켜보고, 어떤 점을 잘 이행했으며 어떤 점을 잘 못했었는지 회고를 해보자. 그리고 그 다음 심화 프로젝트에서는 어떻게 개선해야할까 생각해보자.
얼핏 언젠가 들었는데 백기선님이 개발자들은 논리적인것은 참 좋아하는데 정리를 했으면 좋겠다는,, 말을 들었던것 같다. 선장님이 하라면 해야쥐.. (feat. BDS)
우리는 이렇게 협업했다 🔙
처음 프로젝트를 시작할 때, 우리는 협업에 익숙치 않았다. git에 대한 경험도 부족했고, 특히 jira나 CICD 관련해서는 경험해본 사람이 없었다. 그렇다보니 구체적인 계획보다는 "한번 사용해보자, 그렇다면 어떻게 사용해볼까?"라는 의견으로 막연하게 시작했다.
결과는 어떻게 사용해야 더 옳은지 몰랐다. 때문에 검색을해서 일단 따라해보기로 했다.
git branch 전략
우리 팀원들이 git branch를 나눠서 프로젝트를 진행해본적이 있나 확인해봤다. 대부분의 일원들이 "사용해본적은 있으나 잘모른다"라는 답변을 했다. 나는 토이프로젝트나 재미로 깃 브랜치를 나눠서 사용해본적이 있었다. 그때는 브랜치를 master - develop - feature 로 나눠서 했었는데, develop branch 상위의 branch의 필요성을 느끼지 못했었다.
이번 프로젝트를 하면서 develop bracnh 상위의 branch 필요성을 느꼈다.
필요성을 느껴보지 못해서 그런지 그대로로 진행해도 무방할것같다는 판단을 내렸다. 그래서 우리는 크게 master - develop - feature 로 나누어서 프로젝트를 진행했다.
git commit message convention
먼저, "왜 커밋 메세지 컨벤션이 필요할까?"에 대해 생각해보았고 아래와 같은 결론이 나왔다.
- 서로가 어떤 내용을 작업했는지 한눈에 알 수 있다.
- 만약 롤백이 필요하다면, 롤백 시점을 보다 쉽게 찾을 수 있다.
- 코드리뷰를 할 때 도움이 되도록 설명하는 컨벤션도 있을 수 있다.
사실, 단기 프로젝트를 진행하면서 코드리뷰와 커밋들을 일일이 확인하기 어렵다고 생각한다. 그런 마음을 가지고 있어서인지 커밋 메세지 컨벤션을 어떻게 하자고 구체적으로 이야기하지 않았다. 그냥 feature : commit message 양식을 맞춰서 진행기로 했었다.
잘못된 양식이라기 보다는 우리가 컨벤션을 지키는 태도가 잘못됐었다고 생각한다.
JIRA를 통한 일정 & 이슈 관리
JIRA라는 키워드를 항상 들어왔었는데 막상 사용해본적도 없고, 어떻게 시작해야할지 막막했었다. 운이 좋게도 이번에는 싸피라는 인프라를 통해서 도움을 받아 프로젝트에 도입할 수 있었다. 다음과 같이 크게 3가지로 나누어서 일정 & 이슈관리를 진행했다.
- 에픽
- 스토리
- 스프린트
에픽으로 큰 기능을 잡고 스토리로 세부기능을 나누었다. 그리고 스프린트에 일주일 단위로 마감을 정해서 진행했고 어떤 이슈를 우선적으로 처리할지에 대해서는 스토리포인트를 활용했다. 스토리포인트는 피보나치 수열로 점수를 매겼다.
- 초반에 기능들을 세분화 시키는게 어려웠다. 때문에
기획이 굉장히 중요하다는 것을 깨달았다.- 지라를 사용해보자는 의미가 강해서,
스토리포인트에 신경을 못쓴것같다.우선순위를 정확히 지키지 않아서 프로젝트를 마감하는데 애를 먹었다.
Jenkins를 통한 CICD
Jenkins를 도입한건 프로젝트 진행 중반쯤이었다. 처음에는 내가 도맡아서 배포를 진행했다. 도입하게된 이유는 다음과 같았다.
- 배포를 담당하는 본인의 일 효율성이 떨어질뿐만아니라, 곧 팀의 효율성에 영향을 끼쳤다
- 배포하는 사람의 의존성이 높아진다.
- 가령 주말이나 근무시간외에 작업한 내용들을 배포할 때는 종종 호출(?)당하곤 했다.
하지만 Jenkins도 마찬가지로 키워드는 많이 들어왔었는데, 머릿속으로는 필요한것을 알았지만 "그렇게까지 필요한것인가?"라는 생각을 미약하게나마 했었다. 생각해보면 지난 프로젝트들은 branch를 나누어서 진행하지 않았던것이 한 몫을 한것같다. 그렇게 몸소 CICD의 필요성을 느끼고 도입을 했다.
Jenkins를 사용할때 추가적인 기능을 사용하면 좋겠다고 생각했다. [SSAFY 공통프로젝트 회고] 코드에 대한 고찰에서 언급하겠지만 TDD를 도입하게 된다면, jenkins에서 빌드하기전에 test하는 기능이 있었던것같은데, 적극 활용 할 수 있을듯하다.
카카오 오븐을 통한 와이어프레임
우리는 나름 와이어프레임을 세부적으로 잘 작성했다. Locker wiki에서 초기 카카오 오븐을 통해 만든 와이어프레임을 확인할 수 있다.
아쉬웠던 점은 너무
와이어프레임을 만든다는 것에 치중한 듯하다. 최초에 기획이 부실했던 점도있지만 와이어프레임을 만들고 나서flow-chart에 대한 고안이 필요하다고 느꼈다.
스웨거를 이용한 api 문서화
스웨거를 통해 API를 문서화한것에 대해서는 크게 언급할게 없다. 그럼에도 이 글을 적는 이유는 활용하는데 있어서 아쉬웠던 점이 있기때문이다.
- URI를 정하는 것에 대한 컨벤션도 필요할 듯하다.
다소(?) 일방적인 API 문서화는 오히려 일을 두번하게 만들었다. 프론트와 소통을 통해서 보다 정확한 데이터 셋을 보내줄 필요가 있고 느꼈다.
우리는 이렇게 협업할거다 🔜
추가적으로 우리가 아에 놓쳤던부분중 앞으로는 필요하다고 느꼈던것이 문서화 작업이다. 앞으로도 공통프로젝트에 대한 회고들이 남아있는데, 거의 프로젝트의 만족도를 높이기위한 토픽에서 나온 제안들이다. 문서화 작업도 그중 하나로 어떤 기술을 사용할때 막연하게 사용하지 않고 알고 사용하기 위함이다.
안다는 것은..
- 왜 이 기술을 도입하게 되었나
- 기술을 사용하다가 막힌부분을 어떻게 해결했는가
- 처음 의도한대로 기술을 사용하고 있는가
다음과 같은 내용들을 기록하는게 아닐까 싶다.
종합적으로 위에 회고를 통해 얻은 교훈과 문서화 작업을 다음 프로젝트에 적용시켜볼 예정이다. 다음 프로젝트를 끝내고 회고를 쓰는 그때에는 더 나은 우리가 되어있길... ㅎ_ㅎ
👍👍👍👍