데브코스 중간 팀 프로젝트 회고록

지금까지 프로젝트를 할 때는 대부분 정해진 틀 없이 주먹구구 식으로 진행을 했었습니다. 하지만, 데브코스에서 프로젝트를 할 좋은 기회가 있어 이번 프로젝트는 처음으로 프로젝트다운 프로젝트, 협업다운 협업을 할 수 있었습니다. 그래서 이번에 어떤 식으로 프로젝트를 진행했는지 짧게 정리하고 회고를 남겨보도록 하겠습니다.

 

프로젝트 진행 과정

우리는 3명의 팀원으로 프로젝트 팀이 구성되었습니다. 저 포함 팀원들은 아직 프로젝트의 진행 순서나 팀적인 규칙 등을 어떻게 정하고 진행해야 하는지 모르는 부분이 많았습니다. 그래서 여러 블로그를 참조하고 멘토에게 조언을 얻어 프로젝트를 어떻게 진행해야 하는지 힌트를 얻을 수 있었습니다.

 

총 2주의 기간을 고려해서 일정을 정했습니다. 1주차는 도메인 분석, 요구사항 정의, 유즈케이스 작성, ERD 설계, API 설계 및 우선순위 상에 속한 요구사항을 개발을 시작하였습니다. 2주 차에는 나머지 코드 개발 및 리팩토링, 테스트 코드 작성과 클라우드 배포 관련 작업을 하기로 결정하였습니다.

 

프로젝트를 하면서 처음으로 팀 적인 규칙도 정해보았습니다. Git-Flow를 브랜치 전략으로 정했고, commit과 PR의 형식도 협의하여 정하고 일정은 Github project를 이용하기로 하였습니다. 코드 컨벤션은 sonarlint를 적용하기로 정했습니다.

 

회고

처음으로 나름 체계적인 팀 프로젝트를 진행해보니 새롭게 배운 것도 많았지만 예상치 못한 장애물도 많았습니다. 프로젝트를 진행하면서 어떤 어려움이 있었고 어떻게 해결했으며 무엇을 느꼈는지 정리해보겠습니다.

 

프로젝트의 체계

이번 프로젝트를 진행하면서 제일 만족했던 부분입니다. 이전에는 대학교에서 진행했던 프로젝트가 전부인데 그 과정은 체계는 없이 주먹구구 방식으로 진행됐었습니다. 이번 프로젝트에서는 2주 간의 일정을 3등분을 한 뒤, 각 일정별로 할 일을 계획하고 진행했습니다. 일정별로 3,4일이라는 짧은 시간이었지만 끝나면 간단히 회고도 한 뒤 나머지 일정에 대한 조율을 해보았습니다. 

 

처음으로 팀 규칙도 정해봤습니다. 이전의 프로젝트들은 각자의 코딩 스타일대로 작성하고 커밋도 각자의 방식을 하고 서로가 서로에 대해 터치가 별로 없었습니다. 하지만, 데브코스라는 곳에 참여한 사람들은 역시 달랐습니다 ㅎㅎ. 협업의 과정을 최대한 느껴보기 위해서 코드 컨벤션과 커밋, PR 형식도 맞추고 변수와 메소드 네이밍도 맞춰서 진행해보았습니다. 

 

개인 프로젝트를 할 때는 경험해보지 못 했던 체계가 잡힌 프로젝트를 경험해본 것이 이번 프로젝트의 가장 큰 수확인 것 같습니다.

 

애자일에 대한 잘못된 이해

애자일 방법론에 대한 잘못된 이해 때문에 프로젝트 중간에 도메인 분석을 크게 수정할 일이 있었습니다. 폭포수 방법론은 처음 기획 단계에서 최종 개발 단계까지 진행될 때 각 단계 별로 거의 100퍼센트에 가깝게 완료한 뒤 다음 단계로 넘겨줘야 합니다. 반면에 애자일은 스프린트 단위로 반복하면서 전체적인 과정을 동시에 진행한다고 이해했었습니다. 바로 이 부분에서 문제가 발생했습니다. 

 

애자일을 방법론을 적용하면 개발을 하면서 어차피 도메인이나 요구사항 단계로 다시 돌아가서 수정할 수 있는 것이라 생각해서 도메인 분석 등을 대충 잡아놓고 개발을 시작했습니다. 하지만, 이 상태로 이미 CRUD 등을 개발한 상태에서 도메인을 수정하고 ERD도 다시 설계하다 보니까 이 도메인을 담당한 팀원이 너무 힘들어하였습니다. 코드에서 수정할 부분이 너무 많아서 차라리 처음부터 개발하는 것이 나을 정도로 수정할 포인트가 많았습니다.

 

스프린트 단위로 반복한다 하더라도 전체 과정을 같이 진행하는 것은 아닌 것 같다는 결론을 내렸습니다. 도메인 분석 단계나 ERD 설계 단계 등 각 단계 별로도 스프린트 주기를 적용하여 어느 정도는 구체화를 하고 넘어가야 다음 단계에서도 수월하게 작업을 할 수 있고 설령 수정할 일이 있더라도 그 양이 최소화 될 것입니다. 특히 도메인 분석이나 프로젝트에서 구현할 요구사항은 모든 팀원들이 머릿속에서 일치할 정도로 꼼꼼히 정해야 한다고 느꼈습니다.

 

좌충우돌 Git-Flow

Git-Flow를 개인 프로젝트를 할 때 브랜치 전략으로 적용해보긴 했지만 팀 프로젝트를 한 것은 이번이 처음입니다. 팀 프로젝트에 적용하다보니 몇 가지 실수들이 있었습니다. 문제는 특정 이슈를 해결해서 PR을 날리고 다음 작업을 해야 하는 상황에서 발생했습니다.

 

이번에 한 작업이 다음 이슈에서도 필요한 내용이지만 remote에서는 리뷰를 받지도 않고 merge되지 않은 상태였습니다. 그래서 저는 아무 생각 없이 local에서 develop 브랜치에 merge 하고 다음 이슈 branch를 만들고 작업을 이어 나갔습니다. (어차피 내용이 같으면 충돌이 나지 않을 거라고 생각했었습니다;; )

 

하지만, PR은 저만 보내는 것도 아니었기 때문에 다른 사람들의 PR이 merge되면 제 local의 develop과 당연히 충돌이 날 수밖에 없었습니다. 설령, PR이 제 것만 있어서 파일의 내용이 모두 똑같다 하더라도 local의 hash값과 remote의 hash값이 달라서 충돌이 발생할 수밖에 없었습니다..

 

이 문제를 해결하기 위해 두 번째 시도한 방법도 잘못된 방법이었습니다. 이전 작업의 결과가 필요한데 local에서 merge를 하면 안 되니까 방금 전 작업한 branch에서 새로운 브랜치를 만들고 작업을 했습니다. 이렇게 이슈를 해결하고 pr을 보내고 반복을 하다보니 commit history에는 이슈와 관계없는 이전 내용까지 모두 담겨 있었습니다. 혼자 어설프게 해결하려다 보니 이상한 방법을 해왔던 것입니다.

 

결국엔 멘토에게 조언을 구하고 rebase에 대해서 배우고, 이슈를 나눌 때부터 최대한 영역이 안 겹치도록 하였습니다.  항상 add commit push pull 만 사용하다가 rebase를 사용해보니 신세계가 따로 없었습니다. 이번 팀 프로젝트에서 깃과 관련된 문제를 제일 많이 겪어서 최종 팀 프로젝트를 하기 전에 꼭 깃에 대한 공부를 할 예정입니다.

 

의사소통

운이 좋게도 이번 팀원들과 팀 프로젝트를 하면서 의사소통이 적극적으로 이루어졌습니다. 특정 주제에 대해서 각자의 관점이 다르면 그걸 적극적으로 어필해주었습니다. 단순히 다른 사람의 의견을 수용하기만 했다면 놓치고 지나치는 부분이 많았을 겁니다. 의사소통 부분에서는 좋은 점이 대부분이었지만 팀원과의 회고에서 한 가지 느낀 점이 있습니다.

 

의견을 제시할 때는 무조건 근거가 있어야 한다! 

팀원들과 회의를 할 때 다양한 의견을 제시하는 것은 당연히 좋은 일이다. 하지만, 그 의견에 대한 근거가 부족하고 단순히 추측을 기반으로 한 의견이 강하면 감정싸움으로 이어질 수도 있다고 생각했습니다. 자신이 제시한 의견을 상대방에게 납득시키고 이해를 시켜야하는데 근거가 부족할 때는 생산적인 회의 시간이 아니었던 것 같습니다. 앞으로는 의견과 근거를 항상 세트로 묶어서 생각해야겠습니다. ㅎㅎ

 

코드 리뷰

남의 코드를 이해하는 것도 어렵고, 내 코드를 남에게 이해시키는 것도 어렵다!

팀 프로젝트에서 코드리뷰를 하는 것도 이번이 처음이었습니다. 이전에 팀원들의 과제를 코드 리뷰하는 것과도 천지차이였습니다. 과제는 똑같은 요구사항을 구현하는 것이었기 때문에 코드를 보기 전부터 제가 작성했던 코드를 기반으로 쉽게 이해를 할 수 있었습니다. 

 

하지만, 팀 프로젝트에서 팀원들의 코드를 이해하는 것은 과제처럼 쉽지 않았습니다. 가장 큰 차이점은 도메인이 달랐다는 점입니다. 개발을 할 때는 팀원들 각자 도메인을 맡아서 진행하였습니다. 이렇게 다른 도메인을 개발하다 보니 특정 요구사항에 대해서 어떤 로직이 수행되는지 파악하는 게 어려웠습니다. 더군다나 사람마다 변수나 메소드 네이밍도 묘하게 달랐던 점도 코드를 이해하는데 걸림돌이었습니다. 

 

서로의 코드에 대한 이해를 돕기 위한 임시방편으로 라이브 코드 리뷰를 하기도 했습니다. Github에서 하는 코드리뷰는 리뷰어가 먼저 코멘트를 달면서 시작하는 방식이었다면 라이브 코드 리뷰는 코드를 작성한 당사자의 발표로 시작하였습니다. 특정 요구사항을 만족시키기 위해 어떻게 로직의 흐름이 진행되는지 그리고 왜 그렇게 작성했는지 발표하는 시간이었습니다. 덕분에 다른 팀원들도 코드를 훨씬 쉽게 이해할 수 있었습니다. 

 

하지만, 이 방식은 이해를 돕기 위한 보조 수단일 뿐, 근본적인 해결방법은 아니라고 생각했습니다. 실제 현업에서 일을 한다고 생각했을 때, 코드를 작성할 때마다 모두 모여서 발표를 할 수는 없기 때문입니다. 근본적으로 코드를 왜 그렇게 작성했는지 설명하지 않아도 쉽게 이해할 수 있는 코드를 작성해야 할 것입니다. 

 

점점 해이해지는 모습들

프로젝트를 시작할 때 팀원들과 정했던 각종 규칙들이 있었습니다. commit 메시지는 어떻게 작성하고 PR은 어떻게 작성하고 등등 원활한 팀 프로젝트를 진행하기 위한 약속이었습니다. 이 약속들이 초반에는 잘 지켜었습니다. 하지만, 시간이 흐를수록 제 자신이 점점 규칙들을 잘 지키지 않고 있었습니다. 리팩토링을 할 때도 새로운 이슈를 생성하고 작업을 했어야 하지만 실제로는 다른 이슈에 대한 PR을 보낼 때 얹어서 보내곤 했습니다. 심지어 메시지를 작성할 때도 구체적으로 안 적고 점점 추상적으로 적고 있었습니다. 

 

팀이라면 팀원들에게 내가 어떤 작업을 했는지를 명확히 알려야 합니다. 또한, Git을 사용한다면 언제든지 특정 commit 상황으로 되돌아갈 수 있어야 합니다. 이 두가지를 만족시키기 위해서는 이슈를 정확히 나누고 커밋 메시지도 구체적으로 작성했어야 하는데 그러지 못했던 점에 대해 반성하였습니다. 팀원들과 정한 약속이므로 팀에 피해갈 일 없도록 정말 꼼꼼히 신경써야겠다는 것을 배울 수 있었습니다.

 

마무리

2주라는 짧은 시간이었지만 프로젝트다운 프로젝트를 처음으로 해볼 수 있었던 좋은 기회였습니다. 덕분에 부딪힌 장애물도 많았고 그 안에서 배운 점도 정말 많았습니다. 이번 프로젝트에서 배우고 익힌 것들은 최종 프로젝트에 잘 녹여내고 실수한 잘못들은 최대한 안 할 수 있도록 노력해야겠습니다. 마지막으로 2주 동안 같이 고생한 팀원들, 매일 저녁마다 질문도 받아주고 조언 해주신 멘토 레이 감사합니다!