📗 10.31 디자인 & 기술 선정

📋 디자인 & 기술 선정

1. 디자인 컨셉 및 시스템 정의

1.1 디자인 컨셉

• 레트로 + 8비트 스타일: 게임하는 느낌을 살리기 위해 레트로와 8비트 느낌의 아이콘과 폰트를 사용

1.2 참고 사이트

• 색상 추천 사이트: Color Hunt
• 피그마 템플릿 사이트: Free Figma Templates
  • 다양한 디자인 시스템 및 컴포넌트를 추출하기 좋음

1.3 아이콘 & 도트 디자인

• 아이콘 및 도트 리소스 사이트
  • 8-bit Icon Set (Figma Templates)
  • Pixilart: 다양한 도트 그래픽 참고 가능
  • Piskel: 도트를 찍어서 GIF 형식으로 애니메이션 제작 가능

1.4 폰트

• 기본 폰트: Pretendard
• 컨셉 폰트: 레트로와 8비트 느낌을 강조할 수 있는 폰트
  • DC인디게임 갤러리
  • 네이버 블로그 폰트 소개
  • 갈무리 폰트
  • Neo둥근모: 게임 로고에도 활용 가능 ➡️ 결정!
  • 달무리 폰트
• 선택 폰트: Neo둥근모
  • 자간이 적당하고 가독성이 좋아 주목도가 높음
  • 레트로 게임과 어울려서 감각적인 분위기 연출 가능

1.5 색상 팔레트

• Adobe Color: 이미지 기반의 색상 팔레트 생성 기능 활용
  • Adobe Color (이미지 기반 팔레트 생성)

---

2. 메인 페이지 디자인 1차 제작

• 헤더, 참가자 사이드 바, 캔버스 영역, 채팅, 타이틀 등 리액트 컴포넌트 단위로 세분화하여 구조화하기로 결정

---

3. 기술 선정

3.1 패키지 매니저

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

3.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.3 백엔드 (BE) 기술 스택

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

3.4 코드 스타일

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

3.5 기타 설정

• TypeDoc 문서화 & Github Action으로 배포
• clsx 사용 검토 (디자인 시스템 구축 시 유용)
• alias 설정 (@로 접근)
• husky 설정 (Git Hook 설정 & ESLint와 prettier 검사)

---

4. 프로젝트 폴더 구조

src/
├── 📂 components/              # 컴포넌트 폴더
│   ├── ui/                     # Headless UI 컴포넌트 (Button, Input 등)
│   ├── common/                 # 공통 컴포넌트
│   └── domains/                # 도메인별 컴포넌트 (Game, Draw 등)
│
├── 📂 apis/                     # API 관련 설정
│   ├── config.ts               # 환경변수, Fetch 설정
│   └── services/               # API 호출 함수
│
├── 📂 assets/                  # 빌드에 포함되는 정적 파일
│   ├── images/                 # svg, 이미지
│   └── fonts/                  # 폰트 파일
│
├── 📂 hooks/                   # 커스텀 훅
│   ├── apis/                   # React Query 관련 데이터 처리 훅 (/src/api와 동기화 필요)
│   └── custom/                 # 일반 커스텀 훅
│
├── 📂 types/                   # 타입 정의 (2개 이상 시)
│   ├── index.ts                # 타입 export 중앙 파일
│   └── *.types.ts              # 도메인별 타입 파일
│
├── 📂 constants/               # 상수 정의
│   └── index.ts                # USER_INFO 등 상수 모음
│
├── 📂 stores/                   # Zustand 전역 상태
│   ├── gameStore.ts            # 게임 관련 상태
│   └── userStore.ts            # 유저 관련 상태
│
├── 📂 utils/                   # 유틸리티 함수 (리액트 생명주기와 관련 없는 공통 함수)
│   ├── format.ts               # 포맷 관련
│   └── validation.ts           # 유효성 검사 등
│
└── 📂 public/                  # 빌드 제외 정적 파일
   └── favicon.ico              # 파비콘 등