FE기술 선택 근거

🛠️ DX Settings

ESLint + Prettier

개발 환경 설정에서 ESLint와 Prettier를 도입했습니다.

ESLint는 JavaScript와 TypeScript 코드의 잠재적인 오류를 사전에 감지하고 일관된 코드 스타일을 강제합니다.

특히 TypeScript-ESLint 설정을 통해 타입 관련 오류를 조기에 발견하고 React 관련 규칙들도 적용해 컴포넌트 작성 시 발생할 수 있는 실수들을 방지할 수 있도록 했습니다.

Prettier는 코드 포맷팅을 자동화해 프론트엔드 일관성있는 스타일로 코드를 작성할 수 있습니다.

들여쓰기, 줄 바꿈, 따옴표 사용 등의 스타일을 통일함으로써 코드 리뷰 시 불필요한 스타일 관련 논의를 줄이고 코드 품질에 집중할 수 있었습니다.

특히 @trivago/prettier-plugin-sort-imports 플러그인을 활용해 import 구문을 일관된 순서로 정렬함으로써 코드의 구조화와 가독성을 향상시켰습니다.

---

🛠️ Package manager

NPM

패키지 매니저로는 NPM을 선택했습니다. 팀원들이 NPM을 주로 사용해왔기에 학습 없이 즉시 개발에 착수할 수 있다는 점이 가장 큰 선정 이유였습니다.

PNPM이 제공하는 Phantom Dependency 해결이나 디스크 공간 절약과 같은 이점들을 검토했지만, 현재 프로젝트의 규모와 복잡성을 고려했을 때 이러한 장점들이 크게 부각되지 않을 것으로 판단했습니다.

프로젝트가 frontend, backend, rss-notifier의 세 개의 독립적인 애플리케이션으로 구성되어 있지만, 각 애플리케이션의 규모가 크지 않고 공유하는 의존성이 적어 PNPM의 모노레포 지원 기능이 제공하는 이점을 충분히 활용하기 어렵다고 판단했습니다.

프로젝트 진행 상황을 모니터링하면서 의존성 관리에 문제가 발생하거나 애플리케이션 간 공유 코드가 늘어날 경우, PNPM으로의 마이그레이션을 검토할 예정입니다. 현 단계에서는 패키지 매니저 최적화보다 핵심 기능 개발에 리소스를 집중하는 것이 더 효율적이라 판단했습니다.

---

🛠️ Build tool

Vite

빌드 도구로는 Vite를 선택했습니다.

Vite는 esbuild, SWC, Rollup을 기반으로 구성되어 있어 강력한 개발 환경을 제공합니다.

esbuild는 의존성 모듈들의 사전 번들링을 담당합니다. JavaScript로 작성된 기존 번들러들과 비교해 10-100배 빠른 빌드 속도를 제공해 개발 서버 구동 시간을 크게 단축시켜 신속한 개발을 진행할 수 있을 것이라 판단했습니다.

SWC는 Rust로 작성된 컴파일러로, TypeScript와 JSX 코드를 JavaScript로 변환하는 역할을 수행합니다. Babel과 비교해 최대 20배 빠른 컴파일 속도를 제공합니다.

Rollup은 프로덕션 빌드 시 번들링을 담당하고, 트리 쉐이킹을 통해 사용하지 않는 코드를 제거합니다. ES 모듈을 기반으로 하는 번들링 방식으로, 더 작고 최적화된 번들을 생성할 수 있습니다.

마지막으로 HMR(Hot Module Replacement) 기능을 통해 변경된 모듈만 교체해 개발 시 바로 피드백을 받을 수 있었습니다.

---

🛠️ Language

TypeScript

개발 언어로 TypeScript를 선택했습니다.

백엔드와 프론트엔드 모두 TypeScript를 사용해 서비스 전반에서 일관성있는 개발을 수행할 수 있었습니다.

TypeScript는 컴파일 단계에서 타입 관련 오류를 감지해 런타임 에러를 방지했습니다.

---

🛠️ State management

Zustand + TanStack Query (구 React Query)

상태 관리 도구로 Zustand와 TanStack Query를 함께 사용합니다.

TanStack Query는 서버 상태 관리를 담당합니다. 자동 캐싱과 재검증 기능을 제공해 로딩, 에러와 같은 상태 플래그를 자동으로 관리합니다. 특히 무한 스크롤 구현 시 useState와 Fetch API를 사용할 때 발생하는 복잡한 상태 관리를 useInfiniteQuery를 통해 비교적 간단하고 직관적으로 관리할 수 있었습니다.

useInfiniteScrollQuery, useTrendingPosts와 같은 데이터 페칭 커스텀 훅에서 API 호출 관련 보일러플레이트 코드가 줄어들어 DX를 향상시킬 수 있었습니다.

Zustand는 클라이언트 상태 관리를 위해 선택했습니다. create 함수를 통해 상태를 선언하고 보일러플레이트가 적어 빠른 개발이 가능했습니다.

---

🛠️ Data fetching

Axios

데이터 페칭 라이브러리로 Axios를 선택했습니다.

Axios는 응답 데이터를 자동으로 JSON으로 변환해주어 추가 변환 과정이 필요하지 않고, 에러 처리가 간편합니다.

axios-mock-adapter를 활용해 백엔드 API 개발 전에 목업 테스트를 수행할 수 있어 초기 개발 단계에서 프론트엔드 작업을 병행할 수 있었습니다.

Fetch API는 브라우저 내장 API로 별도의 설치가 필요 없다는 장점이 있지만, 위 이점들을 고려해 Axios를 선택했습니다.

---

🛠️ Routing

React Router

라우팅 라이브러리로 React Router를 선택했습니다.

React Router는 리액트 생태계에서 사실상의 표준이었고, 프론트엔드 팀원 모두가 이전 프로젝트에서 사용한 경험이 있었습니다.

TanStack Router가 제공하는 타입 안정성과 자동 로딩/에러 처리 기능을 검토했지만 현재 프로젝트의 라우팅 구조가 단순하고 React Router로도 요구사항을 충분히 충족할 수 있어 채택하지 않았습니다.

---

🛠️ CSS Styling

Tailwind CSS + Shadcn

CSS 스타일링 도구로 Tailwind CSS를 선택했습니다.

CSS-in-JS는 동적 스타일링에 강점이 있으나, 저희 프로젝트에서는 동적 스타일링의 필요성이 적었습니다. 또한 CSS-in-CSS가 성능면에서 우수해 배제했습니다.

SCSS와 Tailwind CSS를 비교했을 때, Tailwind CSS는 유틸리티 클래스를 통해 빠른 개발이 가능하고 JIT 컴파일러로 번들 크기를 최적화할 수 있었습니다. 반응형 디자인 구현이 직관적이라는 장점 또한 매력적이었습니다.

개발을 진행하면서 프론트엔드 개발자들 각각의 컴포넌트 디자인이 약간씩 달라 일관성 있는 관리가 필요함을 느꼈습니다. 이를 위해 Tailwind CSS 기반의 Shadcn을 도입했습니다.

Shadcn은 라이브러리 설치 없이 컴포넌트 코드를 복사해서 사용할 수 있어 프로젝트에 유연하게 적용할 수 있었고 완성도 높은 디자인을 제공해 디자인에 대한 고민을 많이 줄여줌으로써 개발 생산성을 높일 수 있었습니다.

---

🛠️ Animation

Motion (구 Framer Motion)

애니메이션 라이브러리로 Motion을 선택했습니다.

Anime.js는 가벼운 용량과 다양한 대상에 대한 애니메이션 적용이 가능하지만, React와의 통합이 불편해 제외했습니다.

React Spring은 React와의 호환성이 좋고 useSpring 훅을 통한 유연한 구현이 가능하지만 학습 곡선이 높아 도입하기 어려웠습니다.

Motion은 직관적인 API를 제공하고 예제와 문서화가 잘 되어있어 빠른 개발이 가능합니다. 라이브러리 용량이 크다는 단점이 있으나, 개발 생산성을 위해 Motion을 선택했습니다.

---

🛠️ Hosting

Netlify

배포 플랫폼으로 Netlify를 선택했습니다.

Netlify는 GitHub와의 연동을 통해 자동으로 지속적 배포를 세팅해주어 정말 간편하게 배포를 할 수 있었습니다.

SSL 인증서 자동 발급, 커스텀 도메인 연결, 빌드 자동화 등 필요한 기능을 모두 제공하면서도 무료 티어로 충분히 서비스 운영이 가능해 도입하게 되었습니다.

---

🛠️ Testing

Vitest + React Testing Library

테스팅 도구로 Vitest와 React Testing Library를 선택했습니다.

Vitest는 Vite와 동일한 빌드 파이프라인을 사용해 별도의 설정이 필요하지 않습니다. Jest를 사용하는 경우 Babel 설정이 추가로 필요하지만, Vitest는 Vite의 설정을 그대로 활용할 수 있습니다.

React Testing Library는 사용자 관점에서 테스트 작성을 할 수 있어 비교적 신뢰성 있는 테스트 구현을 수행할 수 있었습니다.

---

🛠️ Git branch convention

GitHub-flow

Git 브랜치 전략으로 GitHub Flow를 채택했습니다.

main 브랜치 외 고정 브랜치 없이 단순하게 브랜치 구조를 가져갑니다.

Issue가 생성되면 브랜치가 생성되고, PR Merge로 Issue가 종료되면 브랜치를 삭제합니다.

브랜치 명은 다음과 같은 규칙을 따릅니다.

• 기능 개발: feature/기능명
• 버그 수정: fix/버그명
• 리팩토링: refactor/리팩토링명
• 문서 작성: docs/문서명