💻 기술 스택 & 아키텍처

Category	Stack
Common
Frontend
Backend
Deployment
Collaboration

1. 패키지 매니저

// ... 자료 정 리 중 ...

2. 프론트엔드 (FE) 기술 스택

기술 범주	선정된 기술	이유
TS/JS	TypeScript	- 타입 정의로 인해 예기치 않은 오류 방지 - 협업 시 API 스키마 등 필요한 타입 미리 정의 ➡️ 효율성 증대
프레임워크	React	- SSR이 필요 없는 프로젝트 특성상 `React` 선택 - 필요 시 메인페이지에만 SEO 적용 예정
번들러	Vite	- 빠른 개발 환경 구축 및 빌드 시간 단축 - 다양한 플러그인 지원 및 방대해지고 있는 생태계
CSS	Tailwind CSS	- 직관적인 디자인 적용과 빠른 구축 가능 - `cva`, `clsx`, `twMerge` 사용으로 디자인 시스템 구축 용이
상태 관리 (클라이언트)	Zustand	- 상태관리 라이브러리는 `React` 훅만으로는 개발 속도가 느려지는 점을 보완하기 위해 도입 - `Recoil`은 유지 관리가 부족하고, `Redux`는 불필요한 기능과 큰 패키지 크기로 인해 제외 - 라이브러리 크기 비교에서 `Zustand`(2.9kB)와 `Jotai`(13.1kB)로 좁혀졌으나 Flux 패턴이 익숙한 `Zustand`로 결론 - Flux 구조를 사용하는 `Zustand`는 프로젝트가 커져도 상태 관리가 용이해, 장기적 관점에서 적합하다고 판단하여 선택
상태 관리 (서버)	React Query	- 클라이언트와 서버 상태를 분리하여 개발 속도를 높이고 유지보수를 용이하게 하기 위해 `React Query` 도입을 고려 - 프로젝트의 특성상 서버와의 실시간 동기화 및 데이터 무결성이 중요하며, 이를 위해 서버 상태를 관리할 커스텀 훅 및 전역 상태 구현 시간을 단축하고자 함 - 제한된 개발 기간 내에 효율성을 극대화하기 위해 `React Query`의 다양한 기능들이 유용하다고 판단 - `React Query`와 비교했을 때, `SWR`은 더 세밀한 렌더링 제어를 위해 커스텀 훅으로 추가적인 코드 작성이 필요하므로 적합하지 않다고 판단
테스트	X	- 시간 제한과 UI/DOM 테스트 중심 특성상 도입하지 않음 - 추후 복잡한 커스텀 훅/함수가 생길 시 도입 검토
컴포넌트 문서화	Storybook	- UI/UX 확인 및 테스트 & 컴포넌트 문서화 가능

애니메이션: 기본적으로 CSS 사용, 필요 시 Framer Motion 사용

3. 백엔드 (BE) 기술 스택

기술 범주	선정된 기술	이유
프레임워크	Nest.JS	- 내장된 라이브러리와 아키텍처 패턴으로 개발 효율성 증가 - 의존성 주입(DI)과 모듈화로 테스트 용이 - 스웨거 자동 문서화 및 DTO 정의 + 유효성 검사 용이
데이터베이스	MySQL, Redis	- 프로젝트의 실시간 멀티플레이어 게임 특성에 맞춰, `MySQL`은 문제 제시어와 같은 영구 데이터를 관리하기 위해 선택 - `Redis`는 낮은 메모리 사용량과 실시간 데이터 처리가 필요하여 게임방 정보, 점수, 상태 등의 임시 데이터를 효율적으로 관리하기 위해 도입 - `Redis`의 TTL 기능을 활용하여 종료된 게임방을 자동 정리하며, `Redis`의 단순한 key-value 구조로 빠른 데이터 접근을 용이하게 함

4. 코드 스타일

기술 범주	선정된 기술	설명
JSX 코드 formatter	ESlint - Airbnb	- 코드 일관성을 위해 초기에는 규칙을 타이트하게 설정하기로 함 - 개발 진행 중 팀원 간의 합의에 따라 규칙을 유연하게 변경할 수 있도록 하여 코드 정리에 더 용이할 것으로 판단
전체 코드 formatter	Prettier	- 코드 일관성 유지를 위해 사용