서론
부스트캠프 웹・모바일 마지막 프로젝트는 그룹 프로젝트로 진행하게 되었다.
나는 백엔드 분야를 담당했고 좋은 기회로 안드로이드 분야 캠퍼분들과 함께 협업을 진행하게 되었다. ( 안드로이드 3, 백엔드 2 )
주제
그룹 인원들이 모두 온라인으로 모여 진행한 첫 회의는 역시 아이스 브레이킹, 커뮤니티 수칙 및 주제 정하기 였다.
주제를 정하는 것에서는 나도 걱정이 되었는데, 그룹원 모두가 최소 1개의 아이디어를 제시하고 모두가 함께 아이디어의 검토를 통해서 결정하는 것으로 정했다.
기준
아이디어의 선택 기준은 창의성 보다는 '기술적 도전'에 집중했다. 그룹원 모두가 팀 프로젝트에 대한 경험이 많지 않은 만큼 이미 있는 주제일지라도 기본적인 부분들에 대해서 딥 다이브를 통해서 문서화를 해 나가며 다같이 성장하자는 것이 그룹원들의 생각이었고, 나 역시도 동의했다.
아이디어 설명
그렇게 선정된 아이디어를 선정했고 주제는 '음식점 공유 플랫폼 앱' 이었다.
간단하게 얘기하자면 아래 요소를 갖춘 정보 공유 플랫폼을 목적으로 설계한 앱이다.
- 지도 API를 활용
- 검색 기능
- 팔로잉 / 언팔로우 기능
- 로그인 / 회원가입
1주차 시작하기
아이디어를 선정하고 대략적인 방향을 정했으면 다음으로 할 일은 우선적으로 크게 세 가지였다.
- Feature List 및 Bakclog 작성하기
- 팀 그라운드 룰 확정하기
- 역할 분담하기
Feature List 및 Backlog 작성
우선 Feature List및 Backlog의 문서화는 선택이 아닌 필수라고 생각했기에 초기에 확실히 정해야 할 부분이었다.
Feature List와 BackLog를 분리한 이유는 Feature List를 초기에 앱 기능목록에서 빠진 부분이 없는지를 팀원이 다같이 작성 및 검토하여 1차로 큰 틀을 잡고, 이 Feature List를 바탕으로 제품 Backlog 및 스프린트 Backlog를 작성하여 세부적인 Task까지 정하기 위함이었다.
Feture List 일부분
결과는 만족스러웠다. Feature List에서 먼저 넣어야 할 기능들을 정리하고 Backlog 작성으로 넘어가니 Backlog에서 새롭게 추가해야할 사항들이 많지 않았고, 작성에 용이했다.
Backlog 일부분
flow 방식 그리고 Git Issue 관리
flow
flow 방식은 다소 고민이 되었다. git-flow, github-flow방식을 고려했는데 그 이유는
Trunk-Based Development 같은 하나의 브랜치로 개발을 하는 경우는 간단한 프로젝트에서 사용하기는 하지만, 이번 프로젝트가 처음인만큼 굉장한 실수를 자주 하지 않을까 싶어 고려하지 않았다.
선택한 flow 방식은 git-flow 방식이었는데 이유는 처음 프로젝트를 경험하는 만큼, 나중에 이보다는 더 편이하다고 느껴지는 github-flow 방식을 사용한다 하더라도 git-flow를 먼저 경험해보며 각 feature, develop, release, main의 단계를 직접 겪으며 알아보는 것이 좋다고 판단했다.
Issue
다음으로는 이렇게 만든 Backlog를 어떻게 Iusse및 Project화 하는가 였다.
Iusse의 단위를 user story로 할 지, story의 task로 할지 팀원들과 토론한 결과 Iusse를 스토리 단위로 하되, Iusse 내부에 각각의 task를 적는것이 확인 및 수정에 용이하다 판단되어 이를 적용했다.
문서화
개발만큼이란 중요하다고 생각하는 부분이었다. 개발을 하면서 겪는 트러블 슈팅이나, 방향의 변경, 데일리 스크럼 회의, 기술적 도전과 같은 부분들을 문서화 하지 않는다면 같은 상황을 마주했을 때 또 삽질을 할 것이라 생각했다.
우리팀의 경우에는 Notion 및 github Wiki를 활용하기로 했다. Notion에 우선적으로 1차 정리를 하면서 생각을 다듬고, 이를 2차로 Wiki에 더 정돈된 형식으로 공유하면서 모두가 잘 이해할 수 있도록 하기로 했다.
wiki 일부분
와이어프레임
와이어프레임은 백엔드, 프론트엔드 모든 분야 그룹원이 함께 참여하였다.
내가 와이어프레임 작업에 참여한 이유는 그룹원이 함께 시각적 요소를 작성하고 이를 확인하면서 프론트엔드와 백엔드 간의 상호작용에 필요한 기능적 요구사항을 더 잘 이해할 수 있다고 판단되었기 때문이었다.
또한, 와이어프레임을 통해 내가 필요한 데이터와 그 흐름을 파악하고, 이에 기반하여 API와 데이터베이스 설계를 더 효율적으로 할 수 있을거라 판단했다.
API 문서 작성
nest swagger를통한 API 문서화를 하기로 정해둔 상태였지만, 첫 문서화는 직접 글로 작성하며 부족한 api 엔드포인트가 없는지 프론트엔드 분야와 토론하며 정하기로 했다.
실제로 부족한 api 엔드포인트가 있었고, 보완하는 작업이 이루어졌다.
이 api 문서를 토대로 nest swagger 코드를 작성할 예정이다.
멘토링
정해진 내용을 토대로 멘토님들과 회의를 거쳤고, 결과는 참담했다.
팀 프로젝트 개발을 하면서 MVP버전을 고려하지 않고 너무 많은 기능을 넣은 것이 문제였다.
"실시간 소켓 통신, 대용량 이미지 처리, AI 적용" 등 6주라는 짧은 기간에서 이 모든 것을 학습하고 적용하기에는 완성하더라도 별로 남는 것이 없을 수도 있다는 것을 느꼈고, 팀원들과 회의를 통해서 MVP버전에서 먼저 구현할 기능과 FINAL 버전까지 구현할 기능 및 시간이 남는다면 추가적으로 구현할 기능들을 분류하였다.
정리
프로젝트를 시작하는 첫 주 였기에, 모든 것이 어색하고 어렵게 느껴지기도 했지만 본격적으로 팀 프로젝트를 하는구나 하는 기분이 들었다.
단순히 시간을 흘려 보내는 것이 아닌 이 기회를 통해 한사람의 개발자로서 성장하는 계기가 되기를 바란다.
2주차서는 1주차에서 정했던 규칙들을 토대로 cloud service와 nestjs를 이용한 서버 개발을 진행할 계획이다. 개발을 시작하는 첫 주는 같은 분야 인원과 페어 프로그래밍을 진행할 예정이기에 속도는 늦을 것 같지만, 그만큼 코드 스타일과 서버 구조에 대해 먼저 정해놓으면 개발에 더 속도가 붙을 것 같다.
