To-do 리스트 프로젝트 회고 - (1) 시작

4월 셋째주의 금요일인 오늘, 코드스쿼드에서 진행하는 프로젝트 과정의 첫번째 To-do 리스트 프로젝트가 끝났다. 이번 프로젝트에는 백엔드 2명, 프론트엔드 2명이 함께 참여했고, 웹 애플리케이션을 위해 협업하는 과정에서 많은 논의가 이루어질 수 있었다. 특히 협업을 위해 무엇을 논의해야 하는지, Git 과 Github 리포지토리는 어떻게 관리해야하는지, 그리고 애플리케이션 내에서 기능을 위해 어떤 점을 클라이언트와 고민해야하는지에 대해 생각할 수 있는 좋은 기회가 되었다. 이번 프로젝트를 진행한 방식과 함께 좋았던 점과 아쉬웠던 점, 개선할 점을 짚어가며 회고를 진행해보고자 한다.

 

프로젝트 내 소스 코드 등은 아래 Github 리포지토리에서 확인할 수 있다.

 

 

GitHub - rxdcxdrnine/todo-list: 그룹 프로젝트 #1

 

 

---

 

 

협업의 시작

---

프로젝트의 주제는 To-do 리스트 만들기로, 아래와 같은 Github 프로젝트와 같은 칸반 보드를 웹 애플리케이션으로 만드는 것이 목표로 주어졌다. 처음 피그마로 제공된 기획서를 보고서 생각보다 쉬운 기능을 가진 애플리케이션이겠구나라고 생각했지만, 프로젝트를 진행하면서 점점 생각할 부분이 많아진다는 것을 느낄 수 있었다. 예를 들면 드래그 앤 드롭으로 칸반 보드의 특정 열에서 다른 열로 카드를 옮기거나, 같은 열 안에서 카드의 순서를 바꾸는 경우에 카드 간의 순서를 어떻게 관리하고 데이터베이스에서 카드 테이블을 어떻게 업데이트할지에 대한 부분이 쉽지 않았다.

 

 

칸반 보드는 간단해 보이지만 비즈니스 로직은 예사롭지 않았다

 

 

하지만, 처음에는 간단할 것이라고 생각했던만큼 여유롭게 프로젝트를 시작했다. 그래서 코드스쿼드 내에서 클라이언트 팀과 처음으로 진행한 프로젝트인만큼 협업을 위한 논의를 충분히하고 넘어가야겠다고 생각했다. 그 결과로 2주차 프로젝트의 첫 날에는 Gitflow 와 Github 내 Issue, Pull Request, Project, Wiki 등을 어떻게 관리할지에 대해 논의하는데 하루를 다 쓰게 되었다. 논의한 내용은 Github 리포지토리의 Wiki 문서에 작성하며, 앞으로 프로젝트를 진행하면서 참고할 수 있도록 작성했다.

 

Github Wiki 협업 전략 링크

 

협업 전략 중에서도 특히 브랜치와 PR 전략에 대해 많은 이야기를 나누었다. 현재 프로젝트에서 사용하는 내 Github 리포지토리는 upstream 리포지토리인 코드스쿼드 마스터즈 코스의 리포지토리를 fork 해 온 downstream 리포지토리이고, 매주 2회 upstream 리포지토리로 PR을 보내고 리뷰를 받아야했다. 여기서 여러 팀원이 기능 추가 혹은 수정을 위해 브랜치를 만들고 다시 공동으로 사용하는 develop 브랜치에 커밋을 모두 합친 뒤에 upstream 리포지토리에 PR 을 올려야한다는 점이 쉽지 않았다. 게다가 프론트엔드 팀과 백엔드 팀은 각자 따로 PR 을 보내야했기 때문에, develop 브랜치도 팀별로 나눠야한다는 문제가 있었다.

 

여러 논의를 진행한 끝에, 아래와 같은 구조로 브랜치와 PR 전략을 정리할 수 있었다.

 

 

excalidraw 로 깔끔하게 순서도를 작성해보았다

 

 

그리고 Git Issue 와 Pull Request 의 템플릿에 대해서도 논의하고, 브랜치와 커밋 규칙에 대해서도 디테일하게 논의를 진행했다. 아래 구성을 바탕으로 Github 에서 제공하는 파일 방식의 템플릿 관리를 이용해, Issue 나 PR 을 추가할 때마다 팀원들이 편하게 작성할 수 있도록 리포지토리 내에 마크다운 형식의 파일을 추가하기도 했다.

 

 

 

 

이전에는 전혀 사용해보지 않았던 Github 내 마일스톤 기능까지 사용을 해보고자 했다. 마일스톤을 단지 마감 일자를 정하기 위해 사용하기보다 프로젝트 내의 지표로 삼을 수 있도록, 프로젝트 내에서 작업 순서를 지정하고 모든 작업의 이전에는 마일스톤이 존재할 수 있도록 논의하기도 했다.

 

 

 

 

결과적으로는 프로젝트를 진행하면서 Github Issue 와 PR 을 적극적으로 활용하면서, 2주간의 프로젝트 기간 동안 Issue/PR 넘버링이 #90 을 넘을 수 있었다. (물론 여기에는 작은 커밋 단위임에도 세부적으로 나눠서 PR 을 올린 내 탓이 있긴 하다.) 그리고 아래와 같이 각 기능의 추가와 수정을 세부적으로 확인할 수 있는 Issue/PR 내역을 남길 수 있었다.

 

 

 

Github Issue 목록

Github PR 목록

 

 

---

 

 

설계의 시작

---

팀원 전체와 함께 협업 전략과 데일리 스크럼/리뷰에 관한 그라운드 룰을 정한 다음으로 서버와 데이터베이스를 구성하기 위한 설계 밑작업을 시작했다. 도메인 객체와 데이터베이스 테이블 구조에 대한 논의없이 구현으로 넘어가게 되면 나중에 구조가 바뀌게 되었을 때 후회하는 순간이 오기 때문에, 기초적인 설계를 반드시 짚고 넘어가고자 했다. (물론 그렇다고 뒷단계가 전부 매끄럽게 진행되었다는 것은 아니다. 설계한지 1주일 뒤에, 설계를 전부 뒤짚는 순간이 오고야 말았기 때문이다.)

 

설계를 위해 가장 먼저 주어진 기획서를 바탕으로 ER 다이어그램을 그리고, 이를 바탕으로 데이터베이스 스키마 구조를 작성했다. 아무래도 To-do 리스트 애플리케이션 내에 많은 데이터가 필요하지는 않았기 때문에, 테이블 수는 비교적 적게 구성할 수 있었다.

 

 

기획서를 바탕으로 작성한 ER 다이어그램

 

ER 다이어그램을 바탕으로 작성한 데이터베이스 스키마

 

 

ER 다이어그램과 데이터베이스 스키마를 작성하기 위해 짧게나마 가장 적절한 툴을 고르는 시간을 두기도 했는데, 가장 대중적으로 많이 사용하면서 여러 다이어그램 작성에 활용되는 draw.io 를 사용하기로 결정했다. draw.io 는 Github 과 연동해 리포지토리 내에 .drawio 파일 형태로 다이어그램을 관리할 수 있고 이를 외부에서 열람할 수도 있는데, 백엔드 팀 내에서 프로젝트를 진행하면서 다이어그램의 변경 내역 또한 함께 추적하면 좋을 것 같아 도입하게 되었다.

 

하지만 이후에 프로젝트를 진행하면서 프로젝트 내 팀원들이 각자 다른 브랜치에서 다이어그램을 수정하게 되면 커밋을 합치게될 때 .drawio 파일이 깨질 수 있다는 큰 단점을 느끼게 되었다. 아마 다음에 진행하는 프로젝트에서는 Github 리포지토리 내에서 관리하기보다 팀원 간에 파일을 수정하고 서로 주고 받거나, 아니면 아예 클라우드를 활용해 동시에 편집할 수 있는 툴을 찾게 될 듯하다.

 

데이터베이스 설계를 진행한 후에는 API 설계를 구성했다. 아무래도 프론트엔드 팀과 함께 협업하다보니, 프론트엔드 팀에서 활용할 목 서버에서 요청과 응답의 명세를 만드는 것이 우선이 되어야한다고 생각해 작업을 서두르게 되었다. API 설계에서는 현재 데이터베이스 구조를 바탕으로 서버 내 도메인 객체의 CRUD 시에 어떤 데이터가 필요하고, 클라이언트에서 화면을 띄울 때 어떤 데이터가 필요할지를 바탕으로 요청과 응답에 필요한 JSON 명세를 작성했다. 이 때 더 원활한 협업을 위해 실제로 많이 활용되는 API 명세를 찾아서 프로젝트 내에 도입하고자 했고, 아래의 링크를 주로 참고할 수 있었다.

 

Github WIki REST API 명세 링크

 

Documenting your REST API

OpenAPI Specification - Version 3.0.3 | Swagger

 

API 명세를 작성하면서, 기능을 구현하면서 많이 바뀔 수 있기 때문에 너무 구체적으로 작성해 많은 시간을 허비하지 말아야한다는 점을 느낄 수 있었다. 클라이언트에서 필요한 데이터가 바뀔 수 있고, 서버에서 기능을 구현하면서 필요한 데이터 또한 바뀔 수 있기 때문에, 초반에 API 명세에 많은 힘을 쏟기보다 가이드라인을 어느 정도 제시하는 수준으로 작성하고 기능을 구현해가면서 더 구체화하는 방식이 합리적일 것이라고 생각하게 되었다.

 

API 명세와 함께 클라이언트와 협업 시에 편한 도구인 Swagger UI 를 프로젝트 초기에 도입하게 되었다. Swagger UI 를 활용하면 서버에서 제공하는 REST API 에 대한 설명과 함께 HTTP 요청을 편하게 테스트할 수 있는 환경을 제공할 수 있기 때문에, 클라이언트와의 협업에서 필수적이라고 생각했다. 따라서 springfox-boot-starter 라이브러리에서 제공하는 어노테이션 기반 설정을 통해 아래와 같이 Swagger UI 를 제공할 수 있었다.

 

 

 

 

회고를 쓰다보니 생각보다 길어져서, 다음 포스트에서는 프로젝트를 진행하면서 구현 과정에서 어떤 고민을 주로 하게 되었고, 어떤 점이 좋았는지에 대해 작성해보고자 한다.