🗣 <LUVOOK> 팀 프로젝트 회고

러북 팀 프로젝트에 대해 회고한 내용입니다. 오타나 오류가 있으면 댓글로 알려주세용!

📚 당신에게 필요한 책, <러북>

📑 러북 프로젝트에 대해 더 알 수 있는 링크 모음집
러북 노션페이지
러북 깃허브

러북에 대한 소개는 깃허브 또는 노션 페이지를 참고해주시고 이 회고에는 어떻게 문서화를 했고 어떻게 프로젝트를 진행했는지에 대해 담았습니다. 이번 프로젝트에서 처음으로 팀장을 맡았고 진행 시에 문서화 하는 것에 노력을 많이 쏟았습니다.

📑 프로젝트 문서화

프로젝트에서 팀장을 맡으면서 가장 신경썼던 부분은 일정관리입니다. 실제로 예전에 팀 프로젝트를 하면서 기획 시기에 구현하고자 했던 부분들을 프로젝트가 끝나는 시기에 반도 구현하지 못했었기 때문에 이번에 더욱 일정관리에 신경을 썼습니다.

📆 일정 전체 캘린더

위의 달력에서 볼 수 있듯이 매일 프로젝트의 진행과정을 기록하였습니다. 모든 문서는 노션에서 확인할 수 있습니다.

1. 회의/스크럼

매일 회의와 스크럼을 진행하여 프로젝트 기획과 어떻게 프로젝트가 진행되고 있고 어떤 이슈가 발생했으며 해결은 하였는지를 기록하였습니다.

기획 회의에서는 진행할 내용, 회의록, 다음 일정 TODO을 정해서 따로 작성하였고 스크럼 회의 때에는 시작/종료 스크럼을 진행하였습니다. 시작 스크럼 때에는 그날의 안건확인, PR확인을 진행하고 종료 스크럼에는 오늘의 이슈, 질문, 진행시 어려움 등을 공유하는 시간을 가졌습니다.

처음에는 이런 구조가 잡히지 않아서 문서를 작성하는데도 1~2시간정도의 큰 시간이 소요되었습니다. 다른 팀원들이 어느정도 진행했는지, PR이 올라왔는지, 오늘의 안건은 어떤게 추가되었는지를 먼저 확인해서 정리해 놓아야 하는 점. 그리고 지금 우리팀은 어느정도 진행이 되었는지, 어떤 구현사항을 더 해야하는지를 파악해야했습니다.

2. 2~3일의 스프린트

저희는 스프린트 기간을 2~3일로 잡았습니다. 그 이유는 총 개발 기간이 3주가 안되기 때문에 짧게 기간을 잡아서 목표치의 구현 요구사항을 설정하고 그 안에 모두 해결할 수 있도록 진행하였습니다.

그 전 스프린트 때의 목표치에서 어느정도 진행했는지 확인하고 새로운 목표를 설정했고 앞으로 어떤 기능들을 더 구현해야 하는지 3가지로 나누어 작성하였습니다. 그랬기 때문에 진행사항을 한번에 확인할 수 있었고 그랬기 때문에 보너스 요구사항, 즉 우선순위가 낮은 것은 깔끔하게 포기할 수 있었습니다.

구현 순서로는 공통 컴포넌트를 개발, 그 후에는 그 공통 컴포넌트를 사용해서 컴포넌트 개발, 그 후에는 컴포넌트에 더미 데이터를 연결해서 먼저 구현, 그리고 API 연결, 마지막으로 디자인 순으로 진행하였습니다.

3. 안건 페이지

이번 프로젝트에서 잘 만들었다고 생각했던 부분입니다. 아무래도 기획 때 모든 부분을 정할 수 없었기 때문에 대화가 많이 필요했습니다. 그리고 중요하지 않은 부분들도 동기식으로 대화하게 되는 상황, 팀원들과 같이 상의해 보고 싶은 부분들에 대해서 어떻게 해결할까 하다가 안건 페이지를 만들었습니다.

안건이 생기면 적어놓고 매일 스크럼 때 확인하고 넘어갈 수 있었기 때문에 까먹는 경우도 없고 다 같이 확인할 수 있어서 좋았습니다.

💻 프로젝트 개발

Git-Flow 전략

저희는 git-flow에 맞춰서 협업을 진행하였습니다. 배포용 main 브랜치와 개발용 develop 브랜치를 만들었습니다. 또한 develop에서 각자 맡은 기능을 개발하기 위해서 featuer 브랜치를 만들어서 작업하였습니다.

Issue와 PR, 그리고 코드리뷰

기능 구현 전에 항상 이슈를 먼저 작성하였습니다. 이슈 템플릿을 이용하여 작성한 후에 이슈 번호를 feature 브랜치 명에 넣어 개발하였습니다. 또한 개발 후 PR을 작성할 때 이슈 번호를 연결하여 쉽게 확인이 가능하도록 하였습니다. 저희팀에서는 꼭 2명 이상이 코드 리뷰를 하고 approve 할 시에 develop에 merge할 수 있는 규칙을 정하여 진행하였습니다.

프로젝트 초기 설정, 프로젝트 구조

프로젝트 초기 설정으로 prettier과 eslint에 대해서 팀원들과 얘기한 결과 너무 깊게 가져가지 말고 eslint는 기본 추천 eslint:recommended와 prettier은 printWidth 100, singleQuote는 true 등 기본적인 것들만 잡고 시작하였습니다. 시간안에 완성하는 것에 초점을 두었기 때문에 이렇게 잡았습니다.

폴더 구조

폴더 구조는 다음과 같습니다.

기본 컴포넌트들을 base, 그리고 base에서 가져다 사용하는 컴포넌트들을 domain이라는 폴더 이름으로 만들었는데 이 부분은 잘못된 폴더 이름으로 사용한 부분인 것 같다고 피드백 받았습니다.

멘토님은 domain이라는 폴더 이름은 도메인 성격을 나타내는 폴더로 작성해야 한다하셨습니다. 처음 폴더 구조를 잡을 때, base와 domain으로 기능을 구분하여 나눠서 사용하고자 하였지만 계속 개발을 하면서 기준이 모호해졌습니다. 그냥 flat하게 component안에다가 넣어서 개발했하는 것도 하나의 방법이라고 멘토님께서 말씀해주셨습니다.

폴더의 이름, 구분도 신중하게 만들고 구현해야한다는 것을 배우게 되었습니다.

router 설정

react router v6로 router 설정하기에 적었듯이 초기에 먼저 필요한 페이지들만 먼저 route설정을 해주었다.

API 모듈화

API를 편하게 사용하기 위해서 구조를 정해서 모듈화 하였습니다. 중간에 이슈도 생겼지만 원활하게 해결하여 진행하였습니다.

API 모듈화 과정에서 살펴볼 수 있습니다.

로그인과 회원가입

실제로 팀프로젝트를 하면서 제가 맡은 기능입니다. 다른 페이지들도 작업을 하긴 하였지만 아무래도 팀원들이 맡았던 부분이고 보완해주는 방향으로 진행했기 때문에 로그인/회원가입 쪽만 기능을 맡앗습니다. 로그인을 하였을 때 토큰을 어디에 저장할지, 전역상태에서 어떻게 관리를 할 지 등을 생각하면서 구현하였습니다.

이 부분에서 formik 라이브러리를 도입해서 사용해보았습니다. 라이브러리 안의 useFormik이라는 훅을 사용하여 validation, handleSubmit, handleChange등의 메서드를 사용하여 구현하였습니다. 처음에는 이해하기 어려웠지만 어느정도 감은 잡을 정도로 구현해본 것 같습니다. 그렇지만 아무래도 formik 라이브러리를 제대로 사용해보았다는 느낌은 받지 못했습니다. 구현에 급급하게 사용하여 많은 활용은 하지 못했던 부분이 아쉬웠습니다.

🧑‍🤝‍🧑 팀 회고록

중간 회고록
최종 회고록

👤 개인 회고

좋았던 점

원활한 소통

역시 우리 팀에서 가장 좋았던 부분은 원활한 소통이지 않을까 싶습니다. 노션, github, slack을 통해서 안건의 사용, 스크럼, 스프린트 등 꾸준히 회의하는 시간을 가졌고 그렇기 때문에 어려움이 있어도 빠르게 해결할 수 있었습니다.

일정 관리

프로젝트 마감 당일까지 개발을 하지 않고 발표 하는 전날 버그 수정까지 할 수 있도록 선택과 집중을 했던 부분이 좋았습니다. 기한 안에 가능할지 불가능할지 판단하여 기능별 우선사항을 나눠 중요한 부분부터 개발한 것이 좋았습니다. 팀원 분들께서도 이런 상황에 맞게 잘 개발해주셔서 프로젝트가 잘 마무리 된 것 같습니다.

API, context 모듈 분리

api를 처음에는 모듈화 하지 않고 호출 마다 토큰도 넣고 헤더값도 넣고 진행하다가 너무 반복되는 코드가 많아졌기 때문에 모듈화를 꼭 하면서 진행해야겠다고 생각이 들었습니다. 또한 context도 한 파일 안에 reducer, initialState, action이 모두 들어가 있어서 어떤 역할을 하는 지는 알지만 한 눈에 파악하기 힘들었기 때문에 모듈화 작업이 꼭 필요했습니다.

context 같은 경우는 다른 팀원분께서 만드신 부분이라 건들기가 조금 어려웠으나 솔직하게 말씀 드리니 편하게 작업하셔도 된다고 하셔서 구조만 변경하였습니다. 정말 잘 만들어주셔서 쉽게 분리할 수 있었습니다. 다음 프로젝트 때에는 직접 context를 만들어서 사용해보고 싶습니다. context api 를 사용할 때 아주 작은 부분도 provider로 감싸서 만들다던가, 예를 들어 하나의 authProvider를 상태를 제공하는 context와 상태를 조작하는 context로 구분해서 context에서 어떻게 성능을 끌어올릴지! 등을 생각하면서 구현해보고 싶습니다.

아쉬웠던 점

소통

위에는 원활한 소통이 매우 좋았다고 적었지만 스스로 반성하는 부분이 있습니다. 사실 프로젝트가 일주일 쯤 지났을 때 팀원분들께 팀장으로서 제가 지금 잘하고 있는지, 보완해주었으면 하는 점이 있는지 등에 대해서 각자 물어보았습니다. 너무 잘하고 계신다는 팀원도 계셨지만 반면에 고쳐주었으면 하는 부분도 있었습니다.

그 부분은 코드리뷰에 대한 부분이었습니다. 칭찬이 하나도 없고 코드에 대해서 변경해주었으면 하는 부분만 말하게 되어 그 리뷰를 받았을 때 기분이 조금 상한다는 말씀을 하셨습니다. 사실 그동안 과제를 리뷰할 때에는 같이 하는 프로젝트가 아니기 때문에 정성스럽게 코드리뷰도 달고 진행하였지만 지금은 같이 진행하기 때문에 제 코드 스타일을 팀원분들께 강요한게 아닐까 하는 생각이 들었습니다. 물론 클론코딩의 신이라는 말로 포장해주셨지만.. 아무래도 스스로 다시 되돌아보게 되었습니다. 그 이후로는 사소한 부분이라도 칭찬과 함께 조금 둥글둥글하게 리뷰를 달도록 노력하였습니다.

또 하나 스스로 반성하는 점이 있습니다. 팀에서 회의를 할 때 개발에 대해서 제가 생각하는 방향으로 설득을 하게 되어 그 방향으로 진행되는 느낌이 들었습니다. 팀장으로서 수용할 부분은 수용을 해야하는데 제가 그 선을 잘못 잡았다고 생각합니다. 그래서 다음 프로젝트 때 또 팀장을 할 수도, 안 할 수도 있지만 어떤 경우에서라도 팀원분들의 의견을 수용하고 이해하면서 조율해 나아가는 연습이 필요할 것 같습니다. 정말 많이 노력해야 하는 부분이라 차차 연습해 나아가겠습니다.

기획과 개발

주제를 정하고 기능에 대해서 세세하게 생각하지 못했던 부분이 많이 아쉬웠습니다. 기능하나에 대해서 구현을 할 때가 돼서야 '저희 이런 기능도 필요할 것 같아요' 혹은 '여기에서는 이게 필요하지 않을 것 같아요' 등의 의견이 생겼고 생각하지 못하게 기능들이 엮여 있던 부분이 많아서 다시 회의를 하고 시간을 많이 소요하게 되었습니다.

또한 개발을 할 때 로그인/회원가입과 공통적으로 사용할 api, router, context등에 집중하였고 리액트의 상태 변화에 따른 구현은 실제로 이번 프로젝트에서 겪지 못한 것 같아서 많이 아쉬웠습니다. 리액트를 사용할 때에 언제 상태변화가 되는지, 구현할 때 생명주기에서 상태는 어떻게 작용하는지, useEffect의 사용 등 이런 기본적인 구현에 대해서는 경험해보지 못했습니다.

또한 하나의 컴포넌트가 진짜 하나의 역할만 하는지, 가독성과 유지보수하기 쉽게 만들었는가 하는 부분들에 대해서도 기능 구현을 많이 하지 못했기 때문에 다른 팀원들의 코드를 보는 정도로 그쳤습니다. 아무래도 이 부분은 리팩토링을 진행하거나 새로운 프로젝트를 하면서 개발해보고 싶습니다.

📚 러북 프로젝트를 마치며..

막상 프로젝트 팀장을 맡고보니 너무 팀장의 무게가 많이 무겁고 부담되었습니다. 첫 팀장이었고 팀원분들이 제대로 진행되었던 팀 프로젝트를 경험해보신 분이 없었기 때문에 1부터 10까지 자료 조사와 프로젝트 초기 설정, 그리고 회의/스크럼/스프린트 진행을 모두 직접 맡아서 진행했기 때문에 프로젝트가 끝나기 2-3일 전 과부하가 찾아왔었습니다.

그래도 팀원분들께서 많이 도와주려고 하셔서 프로젝트가 잘 마무리 되었습니다. 이번 프로젝트를 진행하면서 짧았지만 많은 부분들을 배울 수 있었고 더 나은 개발자로 나아갈 수 있도록 한 걸음 더 내딛었다고 생각합니다.

아참, 이 프로젝트를 마지막으로 팀이 새로 바뀌었습니다. 데브코스를 시작하고 처음부터 14주동안 함께하며 울고 웃던 지은팀 잊지 못할 것 같아요!! 항상 감사했습니다.

러북 프로젝트 회고였습니다. 감사합니다! 화이팅🔥🔥🔥

📸 오랜만에 사진보고 추억돋아서 왔어용