기초 프로젝트 회고

프로젝트 소개

12월 10일부터 약 2주간 코드잇 기초프로젝트를 진행하게 되었습니다. 4가지 주제 중에서 팀원들과 회의 후 고르게 된 프로젝트는 ‘오픈마인드’입니다. 간략하게 서비스를 소개하자면 익명으로 질문과 답변을 하는 서비스입니다. 구현하게 될 기능에는 기본적인 질문과 답변의 CRUD를 구현하고, 무한스크롤 패칭, 화면사이즈에 반응하는 페이지네이션 리스트, sns 플랫폼으로 url을 공유하는 기능이 있습니다.

프로젝트를 선정할 때 제일 많이 고려한 점은 주어진 시간 내에 완성도 있게 완료할 수 있는 프로젝트를 선택하자는 의견이 많아서, 이 프로젝트가 선정이 되었습니다.

 

[REPO URL]

https://github.com/sprint12-part2/openmind

GitHub - sprint12-part2/openmind

 

[SITE URL]

https://openmind-sprint12.netlify.app/

OPENMIND

 

 

프로젝트 시작전

깃운용 연습하기

프로젝트를 시작하기 전에 우리 팀은 팀 프로젝트 경험이 없는 팀원들이 상황을 고려해서, 깃 운용 시나리오를 점검을 먼저 했습니다. 이슈를 만들고 작업할 브랜치를 생성 후 PR을 요청하는 시나리오를 팀원 각자가 스스로 운용할 수 있을 만큼 연습을 해서 팀프로젝트 진행에 문제가 없도록 훈련을 했습니다.

 

그리고 프로젝트를 시작 전 무작정 R&R을 분배하는 것보다 프로젝트의 유저플로우와 구현내용을 다 같이 리뷰하고 시작하는 것이 좋을 것 같아서 다 같이 피그마와 디스코드에 모여 프로젝트 전반적인 내용을 공유했습니다.

 

협업룰 정하기

1차적으로 commit rule, eslint, prettier 설정을 공유하고 이 규칙들로 자동적으로 해결이 되지 않는 부분에 대해서도 회의를 통해 규칙을 정해서 팀 노션에 작성하여 공유하였습니다. 멘토링시간에 멘토님이 ‘마치 한 사람이 작성한듯하게’ 코드를 정리해 보라는 조언도 큰 도움이 되었습니다.

 

기술스택 정하기

아직은 리액트 프로젝트를 많이 해보지 않아서, 어떤 라이브러리등을 미리 설치하고 진행해야 할지 정할 수가 없어서 진짜 필요하다고 생각한 기본적인 패키지들만 미리 세팅 후 추후 필요시 회의를 진행 후 패키지를 추가하기로 했습니다.

 

 

프로젝트 개선점

오픈마인드 프로젝트가 이전 기수부터 해서 많은 팀을 거쳐간 프로젝트일 것 같아서 우리 팀만의 특별한 차별점이 필요했었는데, 다른 곳에서 차별점을 찾는 것보다 문제점을 개선하는 것이 더 올바른 접근이라고 생각하여 필요한 개선점을 찾게 되었습니다.

 

유저플로우 개선

유저플로우를 직접 그려보니 자연스레 질문 작성자 위주로 흘러가는 유저플로우 때문에 정작 이 피드의 작성자가 본인의 피드를 찾아가거나 피드 작성자만 접근가능한 답변페이지로 이동하는 과정이 불편한 점을 알게 되었습니다.

그래서 저희 팀은 메인페이지에서 개인이 여러 피드를 생성했을 경우 선택을 해서 이동할 수 있고, 질문페이지에서 이 피드의 작성자일 경우 바로 답변을 하러 갈 수 있는 방법을 추가하기로 했습니다.

 

 

AS-IS

TO-BE

 

 

R&R 분배

프로젝트가 시작되면서 공용컴포넌트, 페이지 작업등이 팀원들에게 분배가 되었고, 각자 맡은 R&R을 처리하는 과정을 실시간으로 팀원들에게 알려주기 위해 노션에서 작업상황을 관리하게 되었습니다. 처음 하는 협업프로젝트임을 감안하여 최대한 작업파일이 겹치지 않게 작업을 분배해 큰 충돌해결 없이 프로젝트가 잘 진행되었습니다.

 

01

 

 

내가 맡게 된 역할

프로젝트 세팅, 배포 세팅

vite의 템플릿을 통해서 react 초기 프로젝트를 세팅하고, 필요한 패키지들을 설치 및 팀회의시간에 정한 eslint, prettier 등도 세팅하여 팀깃헙 레포에 업로드했습니다. 배포는 netlify 서비스를 이용해서 main과 develop 브랜치에 merge가 되면 자동배포되게 해 두었고, 팀원이 PR을 작성하면 해당 브랜치를 배포하여 Preview Deploy가 자동으로 PR에 달리도록 했습니다. (Any pull request against your production branch / branch deploy branches 옵션을 이용했습니다.)

 

공용컴포넌트

프로젝트에서 쓰일 공용 컴포넌트들을 개발할 때는 이 컴포넌트를 사용하는 팀원들이 유연하게 사용할 수 있도록 모든 케이스들을 고려하여 작성했습니다. 그중에 dropdown과 Icon 컴포넌트를 기록에 남겨보려고 합니다.

 

Select 컴포넌트, MoreMenu 컴포넌트

Select 컴포넌트와 MoreMenu(kebab 메뉴) 컴포넌트에서 trigger를 누르면 menu가 나타나는 부분을 공통으로 사용하고 싶어서 Dropdown 컴포넌트를 스타일링이 없는 headless ui 컴포넌트로 작성을 먼저 하고 두 컴포넌트에서 재사용했습니다. Dropdown은 Compound pattern과 Context api를 조합하여 작성했습니다.

 

Icon 컴포넌트

크기와 색상에 유연하게 대응하는 svg icon 컴포넌트를 만드는 게 목표였습니다. svg data에서 fill을 모두 지워버리고, color값은 currentColor를 이용해서 svg 컴포넌트가 직접 color를 받으면 해당 color를 사용하고 color props가 없으면 현재 color 속성값을 참조하도록 했습니다.

 

질문, 답변 CRUD

질문페이지와 답변페이지를 작업을 하게 되었습니다. 기본적으로 react query를 이용하였고 질문리스트를 패칭 할 때는 useInfiniteQuery과 react-intersection-observer의 useInView를 사용해서 무한스크롤을 구현했습니다.

질문과 답변의 작성, 수정, 삭제등은 react query의 useMutation을 사용하여 작업했습니다. useMutation의 onSuccess에서 invalidateQueries로 데이터를 다시 패칭 할 수 있었지만, 불필요한 데이터 요청을 막아보려고 성공요청으로 서버에서 보내오는 데이터를 가지고 queryData를 업데이트를 하는 방식으로 구현해 보았습니다.

 

 

프로젝트 관리

프로젝트는 과정도 중요하지만 기한 내에 완료를 해야 의미가 있다고 생각했습니다. 목표한 기간 내에 원하는 수준의 품질을 얻으려면 프로젝트 진행 중 QA관리도 중요하다고 생각하여 체크시트를 만들어서 관리했습니다. 기능, 수정, 개선, 검수 총 4개의 시트를 관리했으며 이 체크시트로 공정률을 관리하며 팀원들이 인지할 수 있도록 공유했습니다.

 

 

 

프로젝트 발표 후기

프로젝트가 마무리되고 발표준비도 팀원 모두가 다 같이 참여하여 작성했습니다. 각자가 공유하고 싶어 하는 토픽을 작성할 수 있도록 SPOTLIGHT 챕터도 준비했는데, 발표 시간제한때문에 발표를 하지 못해 아쉬웠습니다.

 

개인적인 프로젝트 회고

프로젝트를 시작 전에는 ‘내가 이 협업을 잘할 수 있을까?’라는 걱정에 휩싸여서 무엇부터 해야 할지 방향을 못 정했었는데 여러 인원이 모여서 같은 방향을 향해 의논을 하다 보니 우려했었던 걱정은 없어지고 더 잘해보고 싶은 욕심까지 생기게 되었습니다. 이것이 팀프로젝트의 좋은 영향력인 것 같았습니다. 특히 혼자 하는 프로젝트보다 좋았던 점은 특정 기능에 집중해서 개발을 할 수 있다는 점이었습니다. 다음 중급 프로젝트는 아마 더 복잡한 협업을 하게 될 거라고 예상되지만 기초 프로젝트에서 얻은 좋은 경험 덕분에 두려움 없이 시작할 수 있을 것 같습니다.

그리고 앞으로 좀 더 개선해야겠다고 생간 한 점은 조금 더 엄격한 룰에서 협업을 진행해 보는 경험을 가져보는 게 좋을 것 같고, 상배방의 코드를 리뷰를 해줄 수 있는 실력을 좀 올려야겠다고 생각했습니다.