money-bridge 프로젝트 회고

프로젝트

실제 기업과 협업하여 진행한 증권사 PB 중개 플랫폼

 

GitHub - FINALALT1/money-bridge

 

---

KPT

Keep

• swagger를 통해 Web API를 자동으로 문서화하여 백엔드와의 소통이 원활했다
• 노션을 통해 문서를 정리하고 이를 바탕으로 체계적으로 개발을 진행하여 효율적으로 작업을 했다.
• 저녁 스크럼 시간 때는 모여서 함께 PR을 진행하고 해당 PR에 대한 코드 리뷰, 질의응답을 진행하며 서로의 코드에 대한 이해도를 높였다.
• 팀 내 코어 타임 규칙을 통해 해당 시간(낮 1시 ~ 밤 10시)에는 디스코드에 상주함으로서 문제가 생길 때마다 바로바로 소통하면서 신속하게 처리할 수 있었다.
• 매일 이뤄지는 프론트/백엔드 스크럼을 통해 서로의 이슈를 공유하고, 이슈에 대한 대처가 수월했다.

Problem

• 북마크 기능에 대해 실시간으로 반영되지 않았다.
• Next.js 13에서 카카오톡 공유기능이 제대로 적용되지 않았다.
• 백엔드 API가 나오기 전 msw로 모킹 데이터를 핸들링 해보려했지만 안됬다.
• 기능 추가에 대한 협의가 이루어 지지 않은 상태에서 개발을 시작했고, 개발 진행 중 기능들이 계속 추가되어 로직들을 수정하는데 시간을 많이 사용했다.
• 초기 기획 단계에서 PM의 부재로 인해 프로젝트 진행이 딜레이 되었고, 추가로 투입된 PM들도 프로젝트에 온전히 참여를 하지 않아 일정 산정과 프로젝트 진행 진척에 어려움이 있었다.
• 검색을 할 때 실시간으로 너무 많은 api요청을 보내 서버에 과부하가 발생했다.

Try

• useMutation의 refetchQueries를 사용하여 데이터가 변경 되었을 경우 최신 데이터로 다시 fetch함으로써 해결하였다.
• 가장 최상위 파일인 layout.tsx파일에서 head에 sdk를 넣어 해결하였다.
• 프로젝트를 시작할때 next 13버전이 출시한지 얼마 되지 않아 아직 msw가 지원되지 않는 이슈로 인해 직접 json파일로 임시로 데이터를 넣어서 작업했다
• 기능의 우선순위를 산정하여 기간 내에 완성하기 어려운 기능들은 Backlog에 추가하였고, 자신의 파트를 마무리한 팀원부터 Backlog 내용을 하나씩 순차적으로 구현하여 문제를 해결하였다.
• 개발 작업이 시작한뒤로 PM과 연락 및 소통이 이루어지지 않아, 프론트엔드에서 디자이너, 백엔드와 커뮤니케이션을 진행하며 기능을 정리 및 디자인 작업에 들어갔다. 전체적인 레이아웃 및 UX 관련 사항들을 디자이너와 소통하며 진행하였고, 그에 따른 API 변경 및 DTO 등 문제들은 백엔드와 소통하며 프로젝트를 완성해나갔다.
• lodash의 debounce를 이용하여 시간을 3초로 설정해 사용자가 검색시 입력해도 실시간으로 api 요청이 가지 않고 입력을 마친 후 3초 뒤에 요청을 보내게 하여 서버 과부하 문제를 해결하였다.

 

 

 

---

느낀점 및 마무리

이전까지 해왔던 팀 프로젝트는 개발자들끼리 모여서 했다면 이번 프로젝트는 PM, 디자이너, FE, BE가 다 같이 모여 작업했고 실제 기업에서 주어진 RFP 제안서를 통해 작업을 한 것이 가장 큰 차이점이다. 총 작업기간은 약 2달이 주어졌고 그중 1달은 기획서 작업과 디자인 작업기간이므로 개발자들은 각자 프로젝트에 필요한 기술들을 공부하기로 했다. FE 팀은 사전에 받은 초기 기획서를 토대로 SSR, SEO가 필요하다고 판단하여 React 대신 Next.js를 택하였다. 따라서 이번에 새롭게 출시된 Next.js 13버전을 배우기로 하였고 프로젝트에 적용하기 위해 나는 1달 동안 12버전과 달라진 점을 보면서 배워갔다.

기획서가 나오고 개발자들은 생각보다 큰 규모에 놀랐는데 3주 만에 다하기에는 인원과 시간이 빠듯했기 때문이다. 하지만 어쩌겠는가 이러한 시련을 거쳐야지만 한층 더 성장하기 때문에 나는 고민도 하지 않고 바로 부딪혀 보기로 했다.

먼저 프로젝트 스택을 정하였는데 상태관리로는 zustand를 사용했다. 그 이유로는 일단 사용하기가 굉장히 편리하고 보일러플레이트가 거의 없기 때문이다. 스타일은 Tailwind를 사용하였는데 CSS를 작성할 때 시간을 많이 절약할 수 있고 반응형을 지원하며 커스터마이징이 간편하기 때문이다. 서버 통신으로는 React-Query를 사용했는데 캐싱을 효율적으로 관리해주고 같은 데이터에 대한 여러 번의 요청이 있을 시 중복을 제거해주며 동기적 실행, Data Fetching 로직 단순화에 따라 사용하기로 하였다.

또한 form을 효율적으로 관리하기 위해 react-hook-form을 사용하였다. react-hook-form은 비제어 컴포넌트의 장점은 그대로 살리면서 제어 컴포넌트에서만 다룰 수 있는 실시간 유효성 검사, 실시간 동기화 등의 API를 제공하여 실시간 유효성 검사 및 동기화가 가능하다. 한마디로 제어 컴포넌트를 사용할 때 보다 훨씬 적은 코드로 훨씬 더 나은 성능을 경험할 수 있게 해주는 라이브러리이다. 또한 타입스크립트도 제공하고 리렌더링을 최소화시켜 마운팅 속도를 높여주기 때문에 채택했다.

기획과 디자인이 어느 정도 마무리된 시점에서 FE팀과 BE팀이 디스코드에서 모여 필요한 API 리스트를 정한 후 개발에 들어갔다. 처음에는 기획된 디자인과 기획서대로 개발하면 될 줄 알았으나 개발하면 할수록 많이 빠진 느낌이 들어 중간에 PM과 디자이너, 개발자들이 수시로 모여 부족한 부분에 대해 회의를 많이 진행하였다.

또한 회의하면서 수정사항이 많이 발생하여 처음 기획을 바탕으로 구성한 코드를 수정해야 하는 일이 많이 발생하면서 시간을 많이 사용했다. 중간에 PM이 연락이 안 되어 디자이너와 개발자들끼리 모여 부족한 부분을 채우고 밤을 지새우면서 프로젝트를 완성했는데 이전까지 진행했던 팀 프로젝트 중에서 가장 힘들었던 프로젝트라 정이 많이 들었다.

기능 구현 중 검색 기능에서 문제가 발생했는데 입력하는 글자 하나마다 실시간으로 너무 많은 API 요청을 보내 서버에 과부하가 발생했다. 이 문제를 해결하기 위해 방법을 찾던 중 debouce와 throttle에 대해 알게 되었다. 나는 두 방법 중 debounce를 택했는데 연이어 호출되는 함수들 중 가장 마지막 함수만 호출하는 동작을 해서 검색에 적합하다고 생각했고 throttle은 함수가 주어진 시간 동안에 한 번 이상 호출되는 것을 막아주어 검색보단 무한스크롤에 적합하다고 생각했다. 그리하여 사용자가 입력하는 시간을 알 수 없기에 개발자가 시간을 임의로 정하는 것 보단 모든 입력이 마친 후 API 요청을 보내는 것이 효율적이라고 판단하여 debounce를 사용해 해결하였다.

FE 팀은 매일 밤 9시에 다 같이 모여 PR 및 코드리뷰시간을 가졌다. 전에 했던 팀 프로젝트에서는 코드리뷰를 진행하지 못하여 매우 아쉬웠는데 이번에는 시간이 촉박하더라도 다 같이 배우면서 얻어가는 것을 최대한 목표로 두었기 때문에 다들 열심히 진행하였다. 첫 코드리뷰를 경험하면서 시맨틱 태그의 적절한 사용법과 zustand의 persist에 대해서도 알게 되어 만족스러웠다.

아쉬웠던 점은 맨데이를 세팅한 후, 기간 내에 해당 기능을 다 완수할 수 있는지 점검하며 할 수 있는 것과 없는 것을 명확히 구분하지 못했던 것이 아쉬웠다.

이번 프로젝트를 통해서 실제 기업에서 이루어지는 웹 개발 프로세스와 협업 방식을 배웠고 이러한 경험을 통해 추후 프로젝트에 체계적인 방식을 적용해 봐야겠다고 생각했다.