드디어 팀 프로젝트가 시작되었다.
코드스테이츠에서는 main project에 입성하기 전에 pre-project 기간을 두고 협업을 연습하는 시간을 2주 가량 갖는다. stackoverflow 사이트를 clone하는 프로젝트가 될 것이다.

나는 pre-project 팀장을 맡게되었다. pre-project이고 많이 넘어져보라고 도입된 기간이긴 하지만 막상 팀장이라는 직함을 달고 나니 긴장이 된다. 앞으로 2~3주동안 많은 산들과 갈림길들이 있을 것이고, 그 때마다 팀장으로서 현명하게 판단할 수 있으면 좋겠다. 설령 현명하지 못했더라도 현명하지 못했음을 정확하게 깨닫고 많은 것들을 배워나갈 수 있는 기간이 되었으면 좋겠다.

감자들 화이팅!!🥔
(팀 이름은 6명의 감자라는 뜻으로 '육감'으로 결정되었다. ㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋ)

프론트엔드 기술스택 사용 논의

Typescript

Redux-toolkit

styled-components

React-Query

React-hook-form

Vite

나는 Typescript, redux-toolkit, styled-components, react-hook-form을 제안했고 만장일치로 결정되었는데, 비동기 처리를 Redux Thunk로 갈지 React-Query로 갈지는 의견이 처음에 조금 갈렸다가 결국 조율이 잘 되어서 React-Query로 최종적으로 결정되었다. 그리고 Vite로 갈지 CRA로 갈지도 처음에 의견이 조금 갈렸다가 Vite로 최종 결정되었다.

비동기 처리: Redux Thunk vs React Query

✔️ React Query로 최종 결정

나는 상태관리로 Redux-toolkit을 쓰는 김에 비동기 처리도 store를 만들고 Redux Thunk를 사용하면 되겠다고 생각했는데, 경섭님이 React Query를 제안해주셨다. 움.. React Query.. 아주 잠깐 스쳐지나가듯 써봐서 잘 모르는 걸?? 당시에 우리 pre-project에 도입하기에 React-Query가 가장 나은 선택이 되려면

• 러닝커브가 지나치게 높지 않아야한다고 생각했다. (프론트 팀원 3명 중 나 포함 2명이 React-Query 입문자였다.) pre-project 기획 일정이 약 일주일 남짓 남았고 중간중간 각자 공부해야 하는데 학습할 시간이 그리 많지 않으므로, 프로젝트에 사용할 수 있을 정도로 학습해놓으려면 너무 어렵지 않아야 했다.
• 학습할 시간의 기회비용을 압도하는 장점(뭐가 될지는 모르지만)이 있어야 한다고 생각했다.

그래서 일단 주말에 각자 React-query를 공부해보고 디스코드에 감상평을 남기기로 하고 결정은 잠정 보류했다.

그리고 주말에 경섭님이 React-Query 자료를 보내주셨다.

카카오페이 프론트엔드 개발자들이 React Query를 선택한 이유
https://tech.kakaopay.com/post/react-query-1/#%EC%8B%9C%EC%9E%91%ED%95%98%EB%A9%B0

이 글을 읽고 설득되었다. ㅋㅋㅋㅋㅋㅋㅋ 👍👍
웬girl..? 리액트 쿼리 너무 좋아보이는 girl?

Redux thunk와 비교했을 때 장점이 뚜렷하다고 생각이 들었다.

• Redux thunk에는 없는 캐싱 기능이 있어서 데이터를 재사용할 수 있기 때문에 앱 성능이 향상될 수 있다.

  staleTime

  컴포넌트가 마운트된 상태이고 해당 쿼리가 활성 상태일 때, staleTime이 지나면 React Query는 데이터의 신선도가 떨어졌다고 판단하여 백그라운드에서 새 데이터를 가져와서 백그라운드에서 캐시를 업데이트 한다.

  cacheTime

  데이터가 캐시에 저장되는 시간. 컴포넌트가 언마운트된 상태일 때 stale되어도 cache에 저장되어 있다면, 컴포넌트가 다시 마운트될 때 캐시에 있는 데이터를 우선적으로 보여준다.

const fetchPosts = async () => {
  const response = await axios.get(EXAMPLE_URL);
  return response.data;
};

const { data: posts, isLoading, error } = useQuery('posts', fetchPosts, {
    staleTime: 1000 * 60 * 5, // 캐시 데이터가 5분 동안 신선하다고 간주된다.
    cacheTime: 1000 * 60 * 30, // 캐시 데이터가 30분 동안 저장된다.
  });

• Redux toolkit도 Redux의 Boiler plate을 줄여보겠다고 나왔는데, React Query는 그것보다 더 줄일 수 있다.
  • Redux store는 상태 관리에, React-Query는 비동기 처리에 구분해서 사용하게 된다면 (Redux thunk와 달리) 상태 관리가 굳이 필요 없는 비동기 처리를 위해 store를 만들 필요 없어진다.

위의 글 읽고 리액트 쿼리가 신기해서 블로그 여기저기 돌아다녀보다보니 나도 모르는 사이에 React-Query 코드가 익숙해졌고, 조금만 더 공부하면 프로젝트에 적용하기에 크게 무리가 없을 것이라는 생각이 들었다.
주말이 지나고 3인 만장일치로 React-Query로 최종 결정! 땅땅!

Create-React-App vs Vite

✔️ Vite로 최종 결정

나는 원래 CRA 외에는 크게 관심이 없었는데, 무생님이 둘 중에 어떤 게 더 좋을지 의논해보자고 제안을 해주셨다. 그리고 경섭님이 보내주신 사진!

100배 빠르다? CRA와 비교했을 때 실행 시간, 빌드 시간 다 빠르다고 한다. 나를 제외하고 두분 모두 Vite를 사용해보셨었고, CRA 사용할 때랑 크게 사용하는 방법이 다르지 않다고 말씀해주셨다.

음.. 러닝커브 0에 수렴, 속도는 100배 빠르다? 도입을 안할 이유가 없는 것으로 결론이 났다. 그런데 신기술은 안정성이 다소 떨어질 수도 있고, 한번도 안써본 도구여서 팀 프로젝트에서 설정이라도 잘못 건드렸다가 큰일날 것 같고 조심스럽게 다뤄야할 것 같다는 생각은 들었다.

회의 끝나고 공부해보니 webpack으로 빌드하는 CRA와 달리, Vite에서는 ES모듈과 RollUp을 사용하기 때문에 webpack이랑 비교할 때 빌드시간이 훨씬 빠르다는 걸 알게되었다. 개발 모드에서 Vite는 개발 서버를 실행하고, 브라우저의 기본 ES 모듈 로더를 활용하여 필요한 모듈만 HTTP 요청으로 불러오기 때문이라고 한다.

그리고 주말 Vite 사용 후기: 무지 빠르다. 핵 빠르다. CRA는 쓰다보면 저장할 때 변경 사항이 금방금방 변경이 안될 때가 많은데, Hot Module Replacement는 원래 이런 것인가? 신세계군!

이렇게 프론트엔드끼리의 기술스택이 잘 협의가 되었다. 개발할 때 어려움이 없으려면 미리 부족한 부분을 잘 공부해둬야지! 화이팅!! 🥔💪🏻!!