<aside> 💡

패키지 매니저는 pnpm을 사용하면 좋을 것 같습니다. 모든 패키지를 병렬로 몰아서 설치해 빠르고 용량 절감도 가능합니다. 게다가 특정 패키지를 여러 곳에서 사용해도, 직접적으로 의존하는 패키지만 참조하므로 이 역시 용량 절감이 가능합니다.

</aside>

1. 프레임워크/빌드 도구

기술 장점 단점 추천 여부
Vite 빠른 개발 서버, HMR, 최신 번들러 (esbuild) 일부 구형 브라우저는 polyfill 필요 ✅ 적극 추천
CRA 전통적인 React CLI 느린 빌드, Vite보다 성능 낮음 ❌ 사용 지양

✅ 추천: Vite + React + TypeScript (빠른 빌드, DX 우수)

2. 언어

기술 장점 단점 추천 여부
TypeScript 타입 안전성, 협업 효율 향상 러닝 커브 ✅ 반드시 사용

✅ 추천: 타입 안정성 필수인 협업 프로젝트에 적합

3. 라우팅

기술 장점 단점 추천 여부
React Router v6 선언적 라우팅, 동적 라우트, Nested Routes SSR 미지원 (Next.js와 비교 시) ✅ 기본 선택

✅ 추천: 커뮤니티 서비스의 다양한 페이지 구성에 적합

4. 상태 관리

기술 장점 단점 추천 여부
Zustand 가볍고 간단, Redux보다 코드 간결 상태 변경 추적 어려울 수 있음 ✅ 소규모 상태에 적합

⇒ Zustand를 선택한 이유

  1. 결제 서비스, 커뮤니티 서비스 도입 전인 지금은 프로젝트의 규모가 엄청 크지도, 로직이 엄청 복잡하지도 않으니 간단하고 빠르게(가볍게) 사용할 수 있는 Zustand가 적합하리라 생각되었습니다.

  2. 조금 로직이 복잡해질 경우, Immer를 도입하여 가변적으로(실제로는 불변성을 유지) 코드를 짜면 가독성도 높아지고 코드의 양은 줄어서 좋을 것입니다.

  3. 실시간 알림 서비스도 서버 또는 소켓을 통하여 하게 될 것이고, Zustand는 그 데이터를 받아 화면에 반영만 하면 되기 때문에 문제될 것은 없을 것 같습니다.

  4. 나중에 복잡한 기능 추가로 인하여 더 복잡한 로직을 필요하게 되거나 사용자가 현저히 늘어 성능 면에서 부담이 될 경우, 그때 Redux로 마이그레이션을 고려하면 될 것 같습니다.

⇒ 전역적으로 거의 값이 바뀌지 않는 값의 경우, 필요에 따라 추가로 Context API를 사용하면 좋을 것 같습니다.(ex: 로그인 상태 여부)

———————————————————————

그런데 React Query를 사용할 경우 상태 관리를 사용할 일이 많이 없을 것으로 보입니다. | | Redux Toolkit | 확장성/툴링 뛰어남 | 설정 무거움, boilerplate | ⚠️ 규모 커질 경우 고려 | | Recoil | React 친화적, atom 기반 | 커뮤니티 성장 더딤 | ⚠️ 실험적 요소 존재

⇒ Recoil VS Zustand = Zustand인 이유

  1. Recoil도 사용하기 쉽고 간편한 전역 상태 관리 라이브러리지만, Zustand가 store 하나만 관리하면 될 뿐더러, React 훅처럼 사용이 가능해 좀 더 간단합니다.

  2. persist, devtools 등 미들웨어도 제공합니다.

Recoil은 persist 등 미들웨어 부분에서 제공하는 플러그인이 많지 않습니다.

  1. store 구조를 제외하곤 Redux와 흡사하여 나중에 Redux로 확장하기 더 쉽습니다.

Recoil은 Zustand에 비해서는 러닝 커브가 높고 아예 다른 패러다임이기 때문에 나중에 Redux로 확장하기도 어렵고 불편합니다.

  1. 모임, 후기, 댓글, 신청자 목록, 로그인 상태, 알림 등 단순한 리스트/객체 중심의 상태들이 많아 이런 상태를 도메인별로 쪼개서 관리하기 좋습니다.

  2. 무엇보다 비동기 코드와 결합하기가 쉽습니다.

Recoil은 비동기 데이터를 처리하기 위하여 selectorFamily, useRecoilCallback 등을 필요로 합니다. |

✅ 추천: Zustand (초기에는 적합, 확장성 필요 시 Redux 전환 고려)