[회고] 프론트엔드 2인 팀 프로젝트 '나무' 회고

프로젝트 명 : 나무(나누고 나눔 받는 무한 품앗이)

프로젝트 기간 : 2023.06.19 ~ 2023.07.28

프로젝트 소개 : 1:1 실시간 채팅 지식 공유 플랫폼

참여 인원 :  프론트엔드 2

기술 스택 : React, React-Query, Javascript, Styled-Components, Recoil, Firestore, Vercel, Mui

담당 기능: 

1. 나무 요청 실시간 데이터 업데이트 로직 구현
2. 메인 페이지 - 캐러셀 컴포넌트 UI 및 기능 구현
3. 검색, 게시글 작성, 태그 수정 페이지 UI 및 기능 구현
4. 마이 페이지 - 목패 변경 컴포넌트 UI 및 기능 구현
5. 공통 컴포넌트 구현(modal, 스켈레톤 UI, input 등)

배포 링크 : https://namu.vercel.app/

깃허브 링크 : https://github.com/sweetyr928/namu

---

나의 세 번째 팀 프로젝트이자 지금껏 진행해 본 프로젝트 중 가장 많이 배우고 성장할 수 있던 기회가 되었던 '나무'를 마무리 지었다. 지난 팀 프로젝트(맛피) 보다 더욱 발전된 프로젝트를 만들고 싶었다. useCallback을 사용하고, props drilling을 최소화했다. 더 나은 사용자 경험을 위해 로딩 컴포넌트를 구현하였고, 요청 기능에서의 원활한 실시간 데이터 업데이트를 위해 리액트 쿼리를 도입하였다. 중복 코드를 줄이기 위해 공통 컴포넌트 만들기에도 최선을 다했다. 디자인 적 완성도를 높이기 위해 포인트 컬러, 피그마 작업에도 시간을 많이 쏟았다. 지난 프로젝트에서는 적용해보지 못했던 '시멘틱 웹' 에 대한 리팩토링도 진행해보았다. 물론 아직 수정하고 고쳐야 할 부분이 많지만. 차근차근 리팩토링 해 나갈 예정이다.

 

처음에는 백엔드, 디자이너 팀원 없이 프론트엔드 두 명 만으로 프로젝트를 완성할 수 있을지, 우리가 원했던 개인 프로젝트와 팀 프로젝트의 이점(두 마리 토끼)를 모두 가져갈 수 있을지 상당한 고민과 걱정으로 시작했었다.

 

프론트엔드 두 명이서 프로젝트를 해야겠다고 결심한 뒤로 꼭 경험해보고 싶던 것을 기록하여 목표를 세웠었다.

첫째, 어차피 언젠간 풀 스택을 해야 한다. 미리 풀스택을 경험해 보자. 프론트엔드라도 백엔드, 데이터베이스에 대한 배경 지식은 있어야 한다. 데이터베이스 구조부터 직접 짜보자.

둘째, 작은 규모로 진행하는 프로젝트이기 때문에 개인 프로젝트의 이점인 주도권을 가지고 새로운 스택을 충분히 공부하고 진행함과 같은 자율성과 유연성을 가져감과 동시에 팀 프로젝트의 이점인 커뮤니케이션 스킬 향상, 다양한 상황에서의 문제 해결 능력 등을 함께 얻어보자. 한 마디로, 해보고 싶은 거 마음껏 해보자. 

세 번째, 새로운 기술에 대해 충분히 공부하고 프로젝트에 적용해 보자. 시간에 쫓겨 적용에만 급급해하지 말자.

정말 감사하게도 내가 원했던 것들을 넘치게 경험할 수 있었다.

첫째, 몇 날 며칠을 고민해 가며 데이터베이스 구조를 설계하고 간단하더라도 직접 백엔드 파트의 로직을 작성해 보며 백엔드의 중요성을 알게 되었고, 서버 데이터와 클라이언트 데이터의 구분에 대해 이해할 수 있었다. 파이어스토어와 스토리지를 사용해 백엔드 파트까지 개발하다 보니 시간이 더 오래 걸렸지만, 투자한 시간 그 이상으로 많이 배울 수 있었다. 특히 리액트 쿼리를 도입한 것이 너무 만족스러웠다. 로딩 로직 처리 하기에도 좋고, 데이터 refetch를 통한 실시간 데이터 업데이트 로직에 적용하기 편했다. 리액트 쿼리 덕분에 채팅과 요청 기능을 무사히 구현할 수 있었다.

둘째, 팀 프로젝트에서 동료와의 소통은 해도 해도 모자라다는 것을 깨달았다. 특히 팀원이 심적으로 힘든 부분이 없는지, 어떤 기능을 구현하고 있고 현재 어떤 부분이 문제인지 먼저 나서서 물어볼 수 있는 용기를 키우기 위해 더욱 노력해야겠다고 생각했다. 나는 남의 일에 질문 또는 말을 많이 하면 상대방에게 부담을 준다고 생각해 진행 상황이 궁금하거나 하고 싶은 말이 있어도 상대가 불편하지 않을까, 혹 무례하다고 느끼지 않을까, 상처받지 않을까 걱정돼 먼저 물어보거나 말을 꺼내지 않는 타입이다. 하지만 팀 프로젝트에서는 먼저 질문할 수 있는 용기가 필요하다. 나의 상황을 팀원에게 공유함과 동시에 내가 먼저 팀원의 상황을 물을 줄 알아야 한다. 

셋째, 데이터베이스 구조 설계를 위해 충분히 파이어베이스에 대해 공부하는 시간을, 요청 기능 구현을 위해 실시간 데이터 업데이트 로직과 서버데이터 관리, 로딩 컴포넌트 도입을 위해 리액트 쿼리에 대해 알아보고 예시를 살펴볼 수 있는 시간을 충분히 가져가며 프로젝트를 진행하여 후회 없이 프로젝트를 마무리할 수 있었다.  이전에는 울며 겨자 먹기로 구글링 후 빠르게 프로젝트에 덧입혀주기 바빴는데 이번에는 충분히 공부하는 시간도 가져갈 수 있어 만족스러웠다.

 

물론 힘들었던 순간들도 분명 있었다. 

1. 프로젝트 마지막 주에 파이어스토어가 터졌다. 것도 두 번이나. 이유를 살펴보니 무료 계정은 트래픽이 5만 정도가 넘으면 하루 동안 데이터베이스 사용이 불가하다고 한다. 급하게 팀원분의 아이디로 새로운 클라우드 파이어스토어 계정을 만들어 옮겨서 진행하였다. 그 가운데서 수많은 에러를 만났다.. 파이어스토어 무료 계정은 트래픽 눈치(?)를 봐야 한다는 점이 조금 슬펐다.

2. 파이어베이스로 배포하는 과정에서 진을 다 뺐다. 새로운 배포 환경을 사용해보고 싶어 파이어베이스 배포를 선택한 것인데, 배포 후 코드 업데이트 시 깃헙 액션 부분에서 상당히 난해한 에러가 떴고, 몇 시간을 붙들고 있어 봐도 전혀 해결이 안 됐다. 이때 정말 멘탈이 나갔던 것 같다. 배포할 때가 제일 무섭다. 결국 팀원 분이 커밋 기록을 되돌리셨고, 내가 되돌린 코드를 버셀로 배포하는 것으로 노선을 틀었다. 실시간 데이터 업데이트 기능 만들 때도 수많은 비동기 에러가 터졌지만, 배포 과정에서 만난 에러보단 착한 편이었다고 생각한다. 난 데브옵스는 정말 못할 것 같다..

3. 너비에 대한 반응형은 어느 정도 구현을 하였는데, 높이에 대한 반응형을 구현 못했다. 높이 반응형은 도대체 어떻게 구현해야 하는 것인가.. 높이 반응형 리팩토링은 숙제로 남겨두었다. 반응형에 능숙한 개발자가 되고 싶다. 사실 우리 프로젝트의 UI 구성 상 반응형을 적용하기가 좀 많이 애매해서 더 어려웠던 것 같다. 다음번에 UI 구성 및 디자인을 할 기회가 있다면, 그땐 기필코 반응형을 생각해 가며 짜야겠다.

 

추가적으로 느낀 점은, UI 구조를 짤 때 트래픽에 무리가 가지 않는지, 개발할 때 무리가 없을지 충분히 상의하고 고려하여 짜야한다는 것이다. 레퍼런스를 많이 찾아보는 습관을 들이자.

초기에 UI 디자인을 응용 프로그램의 느낌이 나도록 구상 했었다. 공통 컴포넌트를 최대한 많이 사용하여 통일성을 주고 싶었고, 하나의 페이지에서 여러 가지 일을 수행할 수 있게끔 하고 싶었다. 이게 화가 될 줄이야...

왼쪽 오른쪽 여백에 공간이 너무 많이 남는 것이 허전하여 마이페이지를 제외한 모든 페이지에 채팅 섹션 컴포넌트를 넣었었다. 채팅 섹션 컴포넌트 탭 메뉴 중 나무 요청 리스트 컴포넌트는 실시간으로 받은 나무 요청을 업데이트하기 위해 리액트 쿼리를 사용하여 특정 시간 간격에 한 번씩 GET 요청을 보내도록 하였다. 마치 주식앱처럼 실시간으로 데이터가 업데이트되도록 하고 싶었다. 이게 문제였다. 어마무시한 양의 GET 요청들이 전송되었을 것이다. 이 것이 트래픽에 큰 부담이 될 것이라고는 상상도 못했는데, 파이어스토어가 터지고 나서야 깨달았다. 주식 애플리케이션의 서버들은 정말 얼마나 짱짱할까 혼자 상상해보게 되었다(주식 애플리케이션 개발하시는 개발자 분들 너무 멋진 것 같다).

 

여하튼, 프로젝트를 하길 참 잘한 것 같다. 오래 고민하고 깊이 생각할 수 있었다.

기획부터 구현까지 전부 참여하여 약 한 달 조금 넘는 시간 동안 최선을 다해 만들어나갔던 프로젝트 '나무', 마음을 많이 쏟은 만큼 갈팡 질팡했던 순간들도 많았지만 힘들었던 시간이 아깝지 않을 만큼 많이 배우고 얻었다.

유난히 비 오고 더웠던 2023년 7월, 빗소리를 백색 소음 삼고 키보드를 벗삼아 써내려갔던 나의 모든 기록들을 잊지 못할 것 같다.

---

프로젝트 종료 그 후...

프로젝트 종료 이후에도 꾸준히 팀원 분과 소통하며 기능 및 디자인 리팩토링을 진행하며 개인적으로 부족한 부분에 대한 보충 학습을 하고 있다. 한 번에 파악이 되지 않더라도 꾸준히 팀원 분이 작성하신 코드도 읽고, 처음 사용해본 스택의 개념을 다시 한 번 짚고 넘어가는 시간을 가지고 있다.

이번 프로젝트에서 새롭게 도입해본 리액트 쿼리!

리액트 쿼리가 제공하는 기술의 반의 반의 반의 반도 채 써보지 못한 터라 추가적인 개념 학습을 진행하고 있던 중, 정리가 너무 잘 된 글을 발견했다. 

https://beomy.github.io/tech/react/tanstack-query-v4/

[React] TanStack Query v4 (React Query)

이 글을 읽고 난 후 내가 리액트 쿼리의 아주 단편적인 조각만 보고 사용했다는 생각이 들었다. 글을 읽으며 내가 리액트 쿼리의 refetch, query key를 정확히 이해하지 못했다는 것을 알게 되었다. 나름 열심히 공부하고 프로젝트에 적용했다고 생각했는데 역시 내가 공부하고 찾아봤던 내용은 빙산의 일각 수준이였다.

앞으로 꾸준히 리액트 쿼리를 사용하고 싶기에 틈 나는 대로 리액트 쿼리 기초를 탄탄히 다져놓는 작업을 해야겠다.

 

프로젝트 종료 그 후의 그 후(?)...

요즘 나의 최대 관심사는 리액트 쿼리, 그 다음이 리덕스(또는 리덕스 툴킷)인 것 같다.

이전 프로젝트에서 서버 데이터 실시간 업데이트 부분에서 고민을 많이 해서 그런가, 리액트 쿼리가 제공하는 다양한 기능을 십분 활용하면 삶의 질과 더불어 코드의 질이 상승할 것 같다는 믿음이 있어 시간이 생기면 리액트 쿼리에 대해 서치해보고 있다.

진작 리액트 쿼리를 알았더라면... 커스텀 훅 만들어서 props drilling 해가며 가독성이 떨어지는 코드를 짜지 않았을텐데! 이제는 서버가 내려가 더 이상 이전 프로젝트의 리팩토링을 진행할 수 없지만, 앞으로 리액트 쿼리를 열심히 공부하여 서버 데이터를 효율적으로 관리하고 코드 가독성을 높이고 싶다.

이 글에서는 React Query에서 mutation 이후 데이터를 업데이트하는 다양한 방법들을 소개하고 있다. 내가 딱 필요했던 내용이다. 공식문서를 번역한 글이다. 이번 프로젝트 '나무'를 진행하며 공식 문서의 중요성을 뼈저리게 느끼고 있다. 공식 문서만큼 제대로 학습할 수 있는 도구는 없는 것 같다. 

새로운 스택을 공부할 땐 공식 문서를 제대로 보자!

https://parang.gatsbyjs.io/react/2022-react-13/

[번역] #12: 리액트 쿼리의 mutation 숙달하기

https://pozafly.github.io/react-query/mutation-after-data-update/

React Query에서 mutation 이후 데이터를 업데이트하는 4가지 방법