저번 팀 프로젝트를 진행하면서 했던 고민과 공부했던 이론 그리고 해당 이론을 적용하는데 사용한 툴들에 대해 전반적으로 정리해 보았다. 나를 포함해서 프로젝트에 참여하는 인원들 모두 취준생 아니면 학생 이였기 때문에 협업에 능숙한 사람은 없었고 그렇기 때문에 이번 기회가 공부하고 실제로 적용해 보기 좋은 기회라고 생각했다.
개발 협업에 대한 주워들은 지식과 추가적인 정보 탐색 이후 진행할 프로젝트에 적용할 방식과 툴을 어느정도 정했다. 결과적으로 Scrum 개발 방식과 Github 를 프로젝트 관리에 사용하기로 결정했다.
Scrum 개발론
스크럼 방식은 비즈니스 요구에 집중해서 작은 목표들을 짧은 주기로 점진적이고 지속적으로 개발하는 관리 기법이다.
스크럼 개발론의 특징
- 프로젝트에 포함할 기능/개선점에 대해 우선순위를 부여한다
- 개발주기는 1~4주로 하고 매 주기마다 실제 동작하는 결과를 제공하라
- 매일 15분 정도의 scrum meeting 을 가져라
- 항상 팀을 우선으로 생각하라. 자신의 업무보다 주변 이슈가 더 급하면 도와줘야 한다.
프로젝트의 개발론 적용
프로젝트의 기한을 한달 정도르 짧게 잡았기 때문에 sprint의 주기를 7일로 정했다.
매일마다 팀원들과 scrum meeting 을 진행했고 미팅 미닛을 작성해서 보관했다. 미팅은 모두 온라인으로 이루어졌고 Discord 의 화상 미팅을 통해 서로 화면을 공유하면서 진행했다.
그 후 스크럼 방식을 더 효과적으로 프로젝트에 적용하기 위해 Jira 와 Github 같은 툴을 사용했다.
JIRA
많은 회사에서 사용하고 있는 이슈관리 툴이라는 이야기를 듣고 프로젝트에 적용해서 사용해보기로 한다.
전체 프로젝트 기간동안의 각 스프린트 마다 달성할 목표를 정하고, 해당 스프린트 아래에 구현할 기능 목록인 백로그를 작성해서 정리했다. 그리고 스크럼 보드를 통해 팀원들이 서로의 진행 상황을 확인하고 공유했다.
하지만 이후 Github 이 제공하는 issue 와 project 탭 사용방법에 대해서 알게 되면서 사용빈도가 줄고 결국 사용하지 않게 되었다.
JIRA 설정 스크린샷
GitHub
협업의 용도로써 깃을 거의 사용해 본적이 없던 나는 말그대로 코드 저장소의 역할로써 깃을 사용해왔다.
하지만 팀원들과 여러 기능들에 대해 공부해보니 깃헙에서 제공하는 여러 유용한 툴들과 개발 방식에 대해 알게 되었고 프로젝트에 바로 적용했다.
깃 브랜치 전략
Git-Flow 라는 브랜치 구조를 참고했으면 해당 구조는 아래와 같다.
main: 배포할 라이브 서버에 연결될 브랜치.dev: 다음 출시 버전을 대비하여 개발하는 브랜치.topic: 추가 기능 개발 브랜치. dev 브랜치에서 작업할 이슈별로 topic 브랜치를 나눠서 개발한다. 이 각각의 브랜치는 기능을 완성할 때 까지 유지하고, 다 완성되면 dev 브랜치에 merge 하고 결과가 좋지 않다면 버리는 방식으로 개발한다.
프로젝트에는 간략화 된 git-flow 구조를 사용했다
브랜치 이름은 다음 형태로 정했다:
<종류>-<이슈넘버>-<내용요약> (e.g. `feat-13-loginpage`)토픽 종류는 간단하게 3가지로 정했다:
feat: 기능개발fix: 기능 수정refactor: 코드 리팩토링
이슈
이슈는 프로젝트의 작업, 개산 사항 및 버그를 추적하는 좋은 방법으로 사용되며 모든 활동 내역에 대해서 이슈를 등록하고 등록한 이슈를 기반으로 작업을 진행할 수 있다.
새로운 이슈를 추가하고 싶을 때는 이슈 탭 안에 New issue 버튼을 사용해서 간단히 만들 수 있다. 또한 미리 이슈 템플릿을 만들어 이슈 형태를 통일시킬 수 있다.
이슈 템플릿 추가 방법
프로젝트의 깃의 탭 중에서 설정 탭 아래에서 템플릿을 추가할 수 있다.
Settings→General→Features→Issues→Set up Templates
프로젝트가 복잡하고 크지 않기 때문에 아래와 같은 간단한 형태의 템플릿을 만들어서 사용했다 :
**설명**
무슨 기능에 대해서 작업하고 싶은지 명료하게 명시
**할일 목록**
- [ ] 할일1
- [ ] 할일1
**참고사항**
추가로 설명해야하는 상황이나 스크린샷등...이렇게 템플릿을 만들고 나면 자동으로 레포지토리 코드 /.github/ISSUE_TEMPLATE 폴더가 생성되고 그 안에 [템플릿 이름].md 파일이 생성되어 저장된다.
프로젝트의 이슈들
나는 앞서 만들었던 스크럼 백로그들을 이슈로 등록했다.
개발 백로그들을 따라 만들어진 이슈들 (개발중 추가적으로 필요한 기능들은 계속 이슈로 추가했다)
이슈넘버와 커밋
해당 이슈들을 기반으로 브랜치를 나누고 개발한 코드를 커밋했는데 이때 커밋 메세지에 #이슈넘버 를 포함하면 깃헙에서 해당 커밋을 이슈에서 자동으로 트랙킹 해준다.
“Feat: 풋터 개발” 커밋 안에 #21 이슈넘버를 입력함으로써 해당 이슈에서 트랙킹된다.
부가적으로 커밋 형태 역시 아래와 같은 규칙을 정하고 사용했다:
Feat: "회원 가입 기능 구현"
SMS, 이메일 중복확인 API 개발
Ref: #1브랜치 설정과 Pull Request
Pull Request
브런치에 commit 한 내역들 변경된 사항을 다른 사람들에게 알리는 기능으로 지정된 브랜치에 merge 하기 전에 변경사항들에 팀원들과 논의, 검토 할 수 있다.
배포에 앞서 팀원과 같이 검토하고 개발 진행 상황에 따라 코드 리뷰도 진행할 수 있는 좋은 도구라는 생각이 들어 프로젝트에 도입했다.
프로젝트에 PR 설정
Settings 탭 아래 Branches 설정 항목에서 각 브랜치 별로 설정을 해줄수가 있었는데 이 프로젝트에서는 main 과 dev 브랜치에 다음과 같이 pull request 설정을 해놨다:
팀원이 총 3명이였기 때문에 PR 을 머지하기 이전에 나머지 두명의 review 에서 approve 를 받아야만 머지가 완료되는 설정을 추가했다. 이 리뷰는 데일리 미팅 시간에 코드 리뷰 및 진행 상황 공유와 함께 이루어졌고 이 과정을 통해서 팀원 모두가 개발상황을 따라올 수 있게 하는 좋은 방법이라는 생각이 들었다.
Pull Request 진행 방식
- 깃 레포를 clone 해서 로컬에 코드를 가져온다.
git clone 레포주소- 로컬에서 따로 개발할 브랜치를 만든다.
git checkout -b 작업브랜치- 작업한 브랜치에 변경사항들을 커밋한 뒤 깃헙
origin레포에push한다.
git push origin 작업브랜치- 이후 깃헙에서 변경된 코드가 포함된 새로운 브랜치가 생성되고 해당 브랜치에서
pull request를 생성한다. - 깃헙에서 머지가 완료되면 로컬 브랜치에서도 똑같이 작업 브랜치를 머지하고 삭제한다.
git checkout dev
git merge 작업브랜치
git branch -d 작업브랜치
프론트 레포에서 생성하고 머지된 PR들의 모습
느낀점
오픈소스 컨트리뷰트 경험도 없고 제대로된 팀프로젝트를 깃헙에서 경험해보지 못했던 나로서는 이번 프로젝트에서 가장 많이 배운점이 깃헙을 활용한 협업이였다. 대부분의 개념들을 처음 접하고 프로젝트에 적용해보는 거라 실수 투성이에 어수룩한 점들이 많지만 이런 과정들을 통해서 배우는게 아닌가 싶다.
아쉬운 점이 있다면 프론트 개발은 나 혼자서 진행했기 때문에 코드 리뷰를 진행하더라도 팀원들이 전체적인 코드를 정확하게 이해하고 리뷰를 해주지는 못했고 진행상황을 가볍게 공유하는 정도에 그쳤다는 점이다.
Reference
[Agile] Scrum(스크럼) 이해하기
[GIT] 📈 깃 브랜치 전략 정리 - Github Flow / Git Flow
