기술선정 이유 - FE14-Part4-Team5/reser-on-do GitHub Wiki

🛠 기술 스택 선정 이유


💠 TypeScript

📌 분류: 언어 및 프레임워크

  • 체험 예약과 사용자 정보 처리에서 API 통신이 빈번하게 발생하는 구조이므로, 응답 데이터에 대한 정확한 타입 정의가 필수예요.
  • 특히 Swagger 기반으로 API가 명세되는 구조에서, 타입 자동 추론과 에러 방지에 TypeScript가 강점을 보여요.
  • 체험 등록, 예약 요청 등 다양한 데이터 구조를 타입 기반으로 안전하게 관리할 수 있어요.

💠 React

📌 분류: 언어 및 프레임워크

  • 캘린더, 지도, 체험 등록/조회, 마이페이지 등 다양한 UI를 컴포넌트 단위로 재사용하고 유연하게 구성할 수 있어요.
  • 조건부 렌더링과 동적 뷰 구성이 많기 때문에, React가 가장 적합한 선택이었어요.
  • Next.js도 고려했지만, 프로젝트 특성과 리소스를 고려할 때 React 단독 사용이 더 적절하다고 판단했어요.

⚠️ 우리가 Next.js를 사용하지 않은 이유


💠 TanStack Query & Zustand

📌 분류: 상태 관리 및 데이터 페칭

  • 서버 상태(예약, 일정, 현황 등)는 TanStack Query로 관리해 중복 요청을 줄이고 실시간 동기화를 구현했어요.
  • 클라이언트 상태(토큰, 로그인 여부, 날짜 선택 등)는 Zustand로 간단하고 효율적으로 관리했어요.
  • 이렇게 두 라이브러리를 분리해 사용함으로써 서버/클라이언트 상태의 경계를 명확히 할 수 있었고, 디버깅도 훨씬 수월했어요.

⚠️ zustand를 사용하는 것이 무조건 좋은 것은 아니지만, props 전달 구조를 치밀하게 설계 하는 데에 어려움이 있어 전역 상태 라이브러리를 사용했어요.


💠 React Hook Form & Zod & OAuth

📌 분류: 폼 / 유효성 / 인증

  • 체험 등록, 예약 신청, 프로필 수정 등 다양한 입력 폼을 React Hook Form으로 퍼포먼스 있게 처리했어요.
  • Zod와 함께 사용해서 폼 유효성 검사를 타입 기반으로 처리하고, 서버 전송 전에 오류를 줄일 수 있었어요.
  • 로그인과 회원가입은 카카오 기반 OAuth를 도입해 접근성을 높이고 가입 허들을 낮췄어요.

💠 외부 SDK (Address Lookup SDK, Map SDK)

📌 분류: 외부 연동

  • Daum 주소 검색 SDK를 통해 체험 등록 시 UX를 개선했어요.
  • Kakao 지도 API로 체험 장소 시각화와 위치 기반 필터링 기능을 구현했어요.
  • 캘린더 SDK는 API 제한과 버전 의존성이 커서 직접 구현했어요.

💠 GitHub & Vercel

📌 분류: 배포 및 인프라

  • GitHub 기반 협업으로 PR 리뷰, 브랜치 전략, 이슈 관리가 명확하게 가능했어요.
  • Vercel은 GitHub와 연동해 자동 배포를 구현했고, 빠른 테스트와 피드백이 필요한 프로젝트에 최적이었어요.