FE 프로젝트 기술검토 - 100-hours-a-week/20-real-wiki GitHub Wiki

1. React v19.1

선택 이유

• 커뮤니티 규모와 생태계가 커서 다양한 라이브러리와의 호환성 뛰어나고, 팀 확장이나 유지보수 측면에서도 유리
• 기존 개발 경험이 있어 빠른 개발 가능

대체안과 비교

• Vue.js
  • v-if, v-for 등과 같은 템플릿 기반 문법은 컴포넌트 내부에서 분기를 명확히 파악하기 어려워 유지보수가 용이하지 않음
  • 국내 기준으로 React보다 사용률이 낮고, 관련 레퍼런스를 찾기 어렵다.
  • SSR, SSG 등 렌더링 기능은 Nuxt.js에 의존하며, Nuxt의 생태계는 Next.js보다 작고 안정성도 낮다.
• Svelte
  • 컴파일 기반으로 속도, 메모리 등 성능적으로 우수하지만, 생태계가 매우 작음
  • 빠른 개발을 위해선 라이브러리가 제공하는 기능 또는 커뮤니티의 지원이 필요히지만, 스벨트는 커뮤니티 지원이 부족

버전 선택

v19

• 수동으로 메모이제이션 하는 작업을 컴파일러를 통해 자동으로 처리
• Next.js v15 부터는 React v19에 대한 기능만 개발. React v18 관련은 커뮤니티 피드백만 유지보수

2. Next.js v15.3

선택 이유

• 렌더링 전략을 페이지 단위로 유연하게 설정 가능
  • 랜딩 페이지: 수정될 일이 거의 없고 모든 사용자에게 동일한 콘텐츠가 제공되므로 SSG로 사전 렌더링
  • 채팅 페이지: 클라이언트 상호작용 중심 화면이므로 CSR이 적합
  • 뉴스 페이지: 본문은 수정 빈도가 낮으므로 ISR로, 그 외 컴포넌트는 CSR로
• 이미지, 폰트 최적화, 코드 분할과 같은 최적화를 프레임워크 단에서 수행
  • 직접 구현 또는 외부 라이브러리를 이용할 때 발생하는 시간 및 유지보수 부담을 줄일 수 있음

대체안과 비교

• Remix
  • SSG같은 다양한 렌더링 전략을 제공하지 않음
• 프레임워크 없이 React 라이브러리만 사용
  • Next는 별도 SSR 설정이 필요 없고, 여러 편의기능을 제공하여 더 편리한 SSR을 제공해줌
  • Next 프레임워크에서 제공해주는 최적화 기법들을 직접 구현 또는 외부 라이브러리에 의존해야 함 → 유지보수/운영 리스크로 인한 개발 생산성 저하

버전 선택

v15

• Rust기반의 빌드 툴 Turbopack으로 초기 빌드, HMR 속도를 향상 시킬 수 있는데, v15부터 turbopack이 stable이 됐습니다.
• SSR에서의 비동기 요청 API로 렌더링 속도를 개선할 수 있습니다.
  • SSR에서 쿠키를 가져오는 동안 쿠키와 상관없는 요소 렌더링을 미리 할 수 있습니다.
• 서버 액션에서의 보안이 향상됐습니다.
  • 주기적으로 변하는 난수 기반 Server Action Id를 서버 액션시 함께 전송해 보안을 향상 시킵니다.
  • 서버 액션 내부에서 컴포넌트에 정의된 지역변수를 참조할 수 있는데, 서버로 전송할 때 자동으로 암호화합니다.

3. Typescript v5.8

선택 이유

• 정적 타입 검사를 통해 런타임 오류를 사전에 예방할 수 있음
• IDE 자동완성, 타입 추론 기능을 활용한 생산성 증가

4. TanStack Query (React Query) v5.74

선택 이유

• 서버 상태를 캐싱, 자동 리패치, 백그라운드 동기화 등을 통해 효율적으로 관리할 수 있음
• 무한 스크롤, 조건부 갱신 같은 기능을 선언적으로 처리할 수 있어 개발 생산성과 상태 관리 비용을 줄여줌

대체안과 비교

• SWR
  • 쿼리마다 개별적으로 컴포넌트를 업데이트하기 때문에 쿼리 개수가 많으면 렌더링 성능 하락
• 전역 상태 도구(Zustand 등)
  • TanStack Query는 로딩/에러/캐싱/동기화 같은 서버 상태에 최적화된 기능들을 제공
  • 서버 상태와 클라이언트 상태의 책임을 분리하여 개발 생산성 향상

5. Zustand v5.0

선택 이유

• 컴포넌트가 공유가 필요한 전역 클라이언트 상태를 간단하게 관리할 수 있음
• 서버 상태는 TanStack Query로, 전역 클라이언트 상태는 Zustand로 분리해서 사용

대체안과 비교

• Redux Toolkit
  • 구조화는 잘 되어 있지만 액션/리듀서 분리, 비동기 처리등으로 인해 진입 장벽이 높고, 단순한 상태 관리에는 오히려 개발 생산성이 떨어짐
• Jotai
  • 원자 단위 상태 관리는 상태 의존성이 복잡해질수록 전체 구조 파악과 디버깅이 어려워짐

6. Tailwind v4.1

선택 이유

• Class 네이밍을 고려할 필요가 없고, HTML과 스타일을 함께 관리할 수 있어, 소규모 프로젝트에서 개발 생산성을 높임
• 이 프로젝트는 복잡한 디자인 요소가 없어 Tailwind로 빠르게 개발하는 것이 유리

대체안과 비교

• SCSS
  • 믹스인, 변수 등을 통한 설계 유연성은 뛰어나지만, class 네이밍 및 파일 분리 설계가 필요해 개발 속도가 느림
  • tsx파일과 css파일의 분리로 책임이 나눠져 유지보수엔 용이하지만, 개발 생산성이 비교적 낮음

7. Storybook v8.6 & Chromatic

선택 이유

• 공통 컴포넌트의 사용 예시와 동작 방식을 문서화함으로써 재사용성을 높임
• 팀원이 문서화된 컴포넌트를 시각적으로 확인하여 피드백 가능
• Chromatic을 사용해 정적 배포와 UI 변경 리뷰를 자동화함

8. ESLint v9.24 & Prettier v3.5

선택 이유

• ESLint
  • 코드 일관성 유지 및 잠재적인 오류 방지를 위한 정적 분석 도구
  • 사전 정의된 규칙을 통해 팀 코드 스타일을 표준화
• Prettier
  • 코드 자동 정렬 및 포맷팅 도구, ESLint와 함께 사용 시 코드 스타일을 자동으로 유지

9. React Testing Library v16.3 & Jest v29.7

선택 이유

• Jest로 로직에 대한 Unit Test를 수행
• React Testing Library+Jest로 DOM에 접근하여 UI Test를 수행

10. react-kakao-login v2.1

선택 이유

• Kakao Javascript SDK를 react에서 사용할 수 있도록 래핑한 라이브러리
• 모바일 웹의 경우 카카오톡 앱을 통한 로그인을 지원