1. About Project
첫 프론트엔드 협업 개발
지난번에는 백엔드 파트를 맡았었기 때문에 팀 프로젝트에서 프론트엔드 개발을 담당한 것은 이번이 처음이었다. (1차 프로젝트 회고) 더군다나 처음 학습해본 React, Typescript를 실전에 적용하기로 결정한만큼 걱정도 됐다. 하지만 1차 프로젝트가 끝난지 얼마 지나지 않아 다시 새로운 사람들과 새로운 무언가를 만들 생각에 설레었다.
수월했던 기획과 설계
프로젝트 주제는 오래 고민하지 않았다. 각자 의견을 내고 다수결로 빠르게 결정했다. 하지만 그 이후의 기획과 UI 설계는 꼼꼼하게 진행하며 5일 정도의 시간을 투자했다. (FIGMA 링크) 팀원들이 함께 디스코드 음성통화를 하며 실시간으로 피드백을 주고받으며 피그마에서 공동으로 작업했기 때문에 와이어프레임 완성이 수월했다.
TripMatch : 여행 'Trip'과 짝을 맞추다 'Match'의 합성어로 국내 여행 동행자를 매칭하고 여행 정보를 나눌 수 있는 커뮤니티 서비스
-
코로나로 인해 해외보다 국내 여행객의 급증한 것을 고려해 국내를 타켓으로 7개 시/도를 기준으로 지역별 동행자를 매칭하기로 했다.
-
혼행객이 증가하면서 믿을 수 있는 동행자를 찾는 사람들이 늘어난 사회 분위기를 반영해 ‘신뢰’를 핵심가치로 한 국내 여행 동행 구인 사이트를 만들기로 결정했다.
-
기존 서비스와의 차별점
a) 여행 후 상대의 여행 점수를 평가하여 동행자 점수를 채점, 동행자 구인 시 신뢰도 향상
b) 서로 동행 신청 동의 시, 글 작성 시 작성한 연락 수단을 공개하여 추가적인 정보 교환
담당 기능
모두가 공평한 분량의 페이지를 담당하도록 사다리타기를 통해 각자의 부분을 정했다. 만약 원하던 부분이 있었으면 먼저 내 의사를 피력했을텐데, 이번에 프론트엔드를 처음 맡은 만큼 어떤 부분이어도 전혀 상관없었다. JWT를 활용한 회원인증을 구현해보고도 싶었고 웹 사이트의 핵심인 메인페이지를 맡았어도 좋았을것이고 아니면 우리 서비스의 차별 기능인 동행 신청을 다루는 마이페이지도 도전해보고 싶었다.
다양한 선택지들 가운데 자유 게시판 /동행 게시판 CRUD 일부를 구현 하게 됐다.
- 동행 모집 게시글 작성 및 수정
- 동행 모집 게시판 및 자유게시판 조회 (필터링 및 페이지네이션)
2. 기술 스택
+ RTK query
- API 요청부터 데이터를 받아서 바로 Store에 저장하는 단계를 쭉 이어서 처리하기 때문에 Redux에 비해 훨씬 적은 양의 코드로 처리하여 상태 관리를 할 수 있다.
- HTTP 클라이언트로 기본 제공되는fetchBaseQuery를 사용하여 코드를 더욱 간단하게 작성할 수 있다
- 전체 API를 보통 한곳에 정의하기 때문에 여러개의 커스텀 hooks들이 다른 파일들에 있는 것 보다 한곳에 위치하는게 요청, 캐시 무효화, 공통 앱 설정을 관리하기가 더욱 쉽다 (공식문서)
+ JWT
- 커뮤니티 사이트이므로 유저 수에 따른 서버의 확장성을 고려하여 선택하였고, 보안을 고려하여 refresh token까지 사용 계획함.
- axios interceptor를 사용하여 refresh token을 관리
- RTK query의 fetchBaseQuery를 axiosBaseQuery로 커스텀하여 비동기 작업을 처리함.
⇒ 이를 통해 로그인이 필요한 기능들에서 refresh토큰으로 access토큰을 갱신하는 반복되는 불필요한 과정들 처리
3. 작업하며 고민했던 점
1) About Code
Input 컴포넌트 관심사 분리
동행게시판 게시글을 작성 페이지에서 10개 가량의 input value를 받아야 했다.
input 타입 또한 radio button, check box, file, date, text, number 등 다양했다.
그래서 처음에는 이 모든 관심사들을 하나의 input 컴포넌트 안에서 분기를 처리했기 때문에 위와 같은 거대한 컴포넌트가 탄생했다.
이후에 확장성을 고려했을 때 다른 개발자들이 내가 만든 input 컴포넌트를 재활용할 경우를 생각해보면 위의 코드는 가독성이 떨어질 뿐더러 유지보수하기에도 어려워 보였다.
위의 코드처럼 실제 Input 컴포넌트를 페이지에 적용할 때도 한 눈에 어떤 type의 input 요소인지 눈에 잘 들어오지 않았다. 그래서 최대한 컴포넌트 하나의 역할을 줄이도록 관심사를 분리해서 리팩토링을 진행했다.
useRef VS useState
처음에는 동행게시판 글쓰기 페이지에서 form을 다룰 때 각 input value를 모두 state로 관리했다. 하지만 생각해보니
- 사용자가 입력한 값과 저장되는 값이 실시간으로 동기화 될 이유가 없었다.
- 인원수가 최소 1명이거나, 모든 input에 값이 필수로 입력돼야하는 것 이외에 유효성 검사가 크게 필요한 페이지는 아니었다.
이 두가지를 이유로 useRef를 활용해 비제어 컴포넌트로 폼을 다뤘다.
Props 지옥의 시작 ... react-tabs 라이브러리 활용
우선 스스로 칭찬하는 점은
- 첫째, 자주 활용되는 라이브러리 활용해 나의 프로젝트에 오류 동작없이 잘 응용해 적용했다는 점이다.
- 둘째, tap component 분리 후 동행 및 자유 게시판에서 재활용 해 코드의 효율성을 높였다는 것이다.
하지만 아쉬운 점도 있었다.
- 첫째, 아래 사진들처럼 props depth 가 깊어져 코드의 가독성이 좋지 않아졌던 점이다.
- 둘째, 개발을 진행하는데 스스로도 복잡함을 느껴 코드를 작성하는데 시간이 꽤나 걸려 '개발자 경험을 고려했을 때 좋은 코드인가?' 라는 생각이 들었다.
자유게시판 조회 페이지
자유게시판 조회 페이지 내의 FreePostPanel 컴포넌트
FreePostPanel 컴포넌트 내의 FreePostList
2) About Team
GIT - PR 잘게 쪼개서 올리기
최대한 다른 팀원들이 나의 코드를 보고 납득하고 이해할 수 있도록 잘게 기능 단위 별로 쪼개서 PR을 올렸다.
좋은 팀원은 나를 성장하게 만든다
이번 프로젝트의 개인적인 목표는 사실 이정도였다.
- 리액트와 타입스크립트에 익숙해지기
- 코드 로직에 대해 깊은 고민해보고 리팩토링 해보기
- 1인분의 역할 제대로 하기
하지만 새로운 지식을 공부해 적용해보려는 노력을 하는 팀원들 덕분에 Redux에 대해서 공부하게 됐고 RTK 쿼리를 나의 코드에 응용할 수 있었다. 더 나아가 RTK 캐싱 관련 오류에 대해서 함께 고민하고 해결해나갔다.
프로젝트 발표 바로 전날 다행히 검색페이지에서 에러를 발견했다.
검색값은 search api reducer에서 관리했더니, search에서 좋아요를 누르면 다른 페이지에서 적용이 안 됐다. 서치를 한번 했을 때 서치 데이터가 캐싱되고, 게시글을 추가하면 해당 게시판 데이터는 캐시가 무효화 돼서 새로 불러와지지만 서치데이터는 무효화가 안돼서 그대로 나타나는 것이었다.
search는 freePost, matchPost도 받아오기 때문에 한 리듀서에 넣기도 애매한 상황이었다.
그래서 search api를 freePost와 matchPost별로 받을 수 있도록 두가지로 나누었다. 백엔드 담당자에게 양해를 구하고 백엔드 코드 수정에 개입해 문제를 해결을 할 수 있었다.
4. 구현 화면
-
동행게시판 조회
-
동행게시판 글쓰기
-
자유게시판 조회
5. 맺으며
이번 프로젝트를 계기로 개발이 더 재밌어졌다. 새로운 지식을 차근차근 적용해보면서 구현되는 모습을 보는 게 뿌듯했다. 적극적으로 프로젝트를 발전시키기 위해 노력을 하는 팀원을 만난 게 작은 우연일지 모르겠지만, 나에게는 큰 울림을 줬던 이번 프로젝트였다. 곧 백엔드 파트 1명과 함께 팀 프로젝트를 시작할 예정인데, 이번 프로젝트에서 배웠던 개발자의 성장하는 매력을 다시 한번 느껴보고 싶다.
