[SPOT] 협업 과정 회고

김민석·2024년 8월 19일

Spring 프로젝트 협업

SPOT

목록 보기

3/11

여러 프로젝트를 진행 했지만, 한 파트의 리드 개발자 역할로 프로젝트에 참여해 본 경험이 없어 막상 어떻게 해야할 지에 대해 고민이 많았다.

0. 많은 고민들

어떻게 프로젝트를 이끌어 나가야 할 지 리스트 업 해봤다. 사실 안적어도 되는데, 이렇게 정리 안해두면 내가 긴장해서 아무 말도 못할 것 같아서 미리 정리했다.

우선 프로젝트 초기 세팅을 진행하기 위해 ERD 설계와 API 리스트 업을 첫 대면 개발 전 과제로 진행 했다. 대략적으로 구성된 화면을 봤을 때, 구현 해야할 API의 갯수가 상당히 많아 보였다. PM님은 데모 데이 이전까지 꽤나 많은 양의 기능을 구현 하기를 요구 하셨고, API 연동 및 연동 과정에서 발생하는 이슈들을 적절히 처리하기 위해서는 빠르게 프로젝트 환경을 구축하고, 개발에 들어가야 한다고 판단 했다. 실질적으로 API 개발을 진행할 수 있는 기간은 3주 정도 였다.

1. 일정 관리

이러한 타이트 한 일정 속, 합리적인 업무 배분과 원활한 업무 관리를 할 수 있는 방식에 대해 고민했다.

과거 프로젝트

과거 학교 수업에서 스크럼과 칸반을 활용한 Agile 방식의 프로젝트를 진행한 경험이 있다. 우선, 플래닝 포커를 통해 각 업무의 난이도와 소요 시간을 평가하고, 이를 바탕으로 개발자의 역량과 가용 시간을 고려하여 업무를 배분했다. 이렇게 분배된 업무와 발생하는 이슈들은 Jira 플랫폼을 통해 관리했다. 또한, 이틀에 한 번씩 스크럼 회의를 열어 업무 진행 상황을 점검하고, 발생한 이슈나 다른 팀의 요구 사항을 논의했다.

적용

이 경험을 똑같이 이번 프로젝트에도 적용해보면 좋을 것 같다고 생각했다.

업무 배분

우선, 각자 과제를 진행 하면서, 각 화면 별로 구현 해야할 API에 대해 난이도를 생각해보자고 제안 했다. 그래서 대면 개발 시간을 통해 정리 해온 내용을 통합해서 적절하게 업무 배분을 진행했다.

위와 같이 업무 배분이 진행 됐다. 이후 상황에 따라서 유동적으로 담당 파트를 수정 하기로 했다.

칸반 보드 도입

이후 원활한 프로세스 관리를 위해 Jira의 도입을 제안 했다.

하지만, 팀원 모두 Jira를 사용한 경험이 없었다. 또한 팀 Notion 페이지에 팀 전체를 위한 칸반 보드를 PM님께서 제공 해주셨다.

Jira라는 새로운 플랫폼의 도입 대신 비교적 익숙한 Notion을 통해 프로세스 관리를 진행 하기로 결정 했다. 또한, 팀 Slack에 칸반 보드를 연동 하여 변경 사항이 생길 때 마다 알림을 받을 수 있도록 설정 했다.

팀 전체가 동시에 사용하는 칸반 보드라, Spring 팀의 업무 진행 상황을 한 눈에 알아보기 힘들다는 한계점이 있었다. 이 문제를 해결하기 위해 데일리 스크럼을 추가적으로 도입 했다.

데일리 스크럼

팀원들의 업무를 지속적으로 트래킹 하기 위해 데일리 스크럼을 제안 했다.

칸반 보드 만으로는 디테일하게 팀원 들의 업무를 트래킹 하기엔 어렵다고 판단 했다. 그래서 데일리 스크럼을 통해 자신의 개발 진행 상황을 공유 하고, 혼자 해결하기 어려운 문제는 바로 공유 해서 같이 해결 하도록 했다.

가능하면 Zoom을 통해서 서로의 코드를 공유 하며 진행 했고, 이후 개발 일정이 어느 정도 마무리 된 상황에서는 Slack을 통해 채팅으로만 간단하게 진행 했다.

결과

위 칸반 보드와 데일리 스크럼을 통해 95% 이상의 업무를 완료했다. 우선 순위 2순위까지 화면 구성에 필요한 API는 모두 구현을 성공적으로 마무리 했다.

대체적으로 만족스럽지만, 스프린트를 설정하지 않고 프로젝트를 진행 했다는 점이 아쉬움이 남는다. 개발 마감 일정이 체계적으로 관리되지 않았기 때문에, 업무를 좀 더 세분화하여 스프린트를 설정했더라면 더 효율적인 개발이 가능했을 것 같다. 특히, 기능 구현에 소요되는 시간이 개발자마다 달랐고, 이를 관리하는 것이 쉽지 않았다. 이로 인해 일부 일정이 너무 여유로웠던 반면, 처음 시도해보는 기능은 2주 이상 소요되는 경우도 있었다.

추후 출시까지 개발을 하게 된다면, 이 부분을 보완해서 진행하고 싶다.

2. Github 및 브랜치 전략

다음으로는 Github 및 브랜치 전략에 대해 이야기를 나눴다.

Github 관리

PR Rule

제일 먼저 Pull Request 규칙을 정의했다.

프로젝트 시작 당시에는 Server 파트가 4명이라 총 2명의 Approve가 있어야 PR을 merge 할 수 있도록 했다.

코드 리뷰를 통해서 자신이 미처 파악하지 못한 부분에 대해서 함께 확인을 하고, 새로 도입한 기술에 대해서는 어떤 특징이 있는지, 다른 더 나은 방법이 있지는 않은지 함께 이야기 나누기로 했다.

Slack과 연동

PR이나 Issue 생성 시, 다른 팀원들의 빠른 확인을 위해 팀 Slack과 Github 연동을 진행 했다.

커밋 컨벤션

이후 네이밍이나 커밋 및 PR 컨벤션에 대해서도 이야기를 나눴는데, 이 부분에 대해서는 스터디에서 사용했던 방식을 그대로 사용 하기로 했다.

Git-Flow

팀 Repo를 PM님께서 제작을 해주셔서 팀 Repo에서 작업 하기로 결정 했다. 이후 Github 전략에 대해 이야기를 나눴다.

결론적으로는 Git-flow가 결정이 됐다.

Git-flow를 선택한 이유는 먼저 학기 중 진행했던 스터디 워크북에서 Git-flow와 비슷한 방식으로 설명이 되어있다. 그래서 프로젝트를 경험해보지 못한 팀원도 비교적 친숙하게 접근할 수 있었다. 그리고 나를 포함한 팀원 한 분이 Git-flow를 사용해서 프로젝트를 진행 한 경험이 있었고, 브랜치 관리 측면에서도 만족스러웠다는 의견이 나와 Git-flow로 결정 했다.

우려

Git-flow에서 우려되었던 점은 브랜치가 복잡하게 많이 생겨 유지보수에 어려움이 있다는 것이었다. 이러한 문제는 이전 프로젝트에서 경험한 바가 있다. 팀원 대부분이 작업이 완료된 브랜치를 merge 후에도 삭제하지 않아서 브랜치 구분이 어려웠다.

이 문제를 해결하기 위해, 작업이 완료된 브랜치는 삭제하기로 했다. 또한, 업무를 시작할 때는 issue를 생성하고, 생성된 issue 번호에 맞게 브랜치를 생성하여 브랜치 명 뒤에 번호를 추가했다. 이렇게 함으로써 각 브랜치가 어떤 작업을 하고 있는지 쉽게 파악할 수 있도록 했다.

결과

코드 리뷰를 통해서 개발 과정에서 미쳐 발견하지 못한 문제점들을 종종 발견할 수 있었다.

또한, 내가 도입한 기술에 대해서도 왜 사용 했는지 다시 한 번 생각해볼 수 있는 기회가 여럿 있었다.

하지만, 브랜치가 깔끔하게 관리 되지 않은 점에 대해서는 아쉬움이 남는다. 우려했던 문제가 발생했던 부분이었다. 데모 데이 이후에는 팀원들과 논의를 통해 다른 브랜치 전략을 적용하거나, Git-flow를 사용 하되 더 나은 방법을 찾기 위해 이야기 해 볼 예정이다!

3. 좋은 협업 파트너가 되어 보자

Swagger

마지막으로 API 명세서를 작성할 플랫폼을 결정 했다.

이전 프로젝트에서는 Notion과 Swagger를 사용해 명세서를 두 번 작성한 경험이 있었다. 그러나 두 명세서 간 중복되는 내용이 많아, API 스펙이 변경될 경우 두 곳에서 모두 업데이트해야 하는 번거로움이 있었다. 이를 제대로 관리하지 않으면, 두 명세서의 내용이 달라져 프론트엔드 개발자들이 혼란을 겪는 경우가 빈번했다.

반면 Swagger를 통해 명세서를 작성하면 코드 변경 시 이를 코드와 동기화하기가 상대적으로 수월했다. 또한 문서화된 API를 직접 테스트할 수 있어, 명세서를 더 직관적으로 확인할 수 있다는 장점도 있었다.

따라서 이번에는 서버 배포 이후, Swagger를 통해 API 명세서를 작성하기로 결정했다.