1. 기존 FE_Original 프로젝트 상태
- 리팩토링 전, 내가 작업 중인 프로젝트는 CRA (Create React App) 기반의 React 프로젝트임.
- 기존 프로젝트 코드가 FISA에서 배워서 익혔던 방식과 많이 차이 나서 이해하는데 시간이 걸림.
- Next.js에 익숙해져서 CRA가 많이 어색해짐. 전에 Vite로 하기로 했는데 CRA를 결국 사용함.
- 리팩토링 전에 Original 레포 프로젝트 코드를 분석하여 정리해두고 개선 방향을 찾으려 함.
/**pakage.json*/
"dependencies": {
...
"react-scripts": "5.0.1",
...
},
"scripts": {
"start": "react-scripts start",
"build": "react-scripts build",
"test": "react-scripts test",
"eject": "react-scripts eject"
}- react-scripts는 CRA의 핵심이라고 함.. (현재 react, react-dom 사용)
- proxy, axios, redux, react-query 등 다양한 라이브러리 사용 중
- 상태 관리 : Redux + React-Redux
- 기타 유틸 : dayjs, date-fns, styled-components, swiper, react-icons, 등
- 프로젝트 초기에 Vite로 하자는 FE 팀장님의 의견이 있었지만, 그때 당시 팀장님을 제외한 나 포함 2명의 팀원은 개발 초짜였기도 하고, FE, BE 팀장들도 CRA만 알고 있었기 때문에 이 방식을 선택했었다. (이제보니 CRA가 더 복잡한듯...)
2. CRA 프로젝트의 문제점 (1)
- 느린 속도 : 개발 서버(HMR) 반응 속도가 느리고, 빌드 시간이 김
- 구조 정리가 안 되어 있음 : 디렉토리/컴포넌트 분리 안 되어 복잡, 공통 로직 재사용 어려움
- 타입 안정성 없음 : JavaScript만 사용 → 타입 체크, 자동완성 부족
- 확장성에 한계 : 프로젝트가 커질수록 유지보수 어려워짐
| 항목 | CRA (react-scripts) | Vite |
| 번들러 | Webpack | ESBuild |
| 속도 | 느림 (특히 빌드) | 빠름 (HMR, 빌드 매우 빠름) |
| 설정 | 숨겨짐 | 오픈 (vite.config.js 커스터마이징) |
| 사용 명령어 | npm start, build, test | npm run dev, build |
| 지원 파일 | .js, .jsx | .js, .jsx (추가로 .ts, .tsx도 쉽게 지원) |
3. CRA 프로젝트의 문제점 (2) - 디렉토리
1. components/와 pages/가 혼재됨
- 일부 "페이지" 성격의 컴포넌트가 components/booking/에 있고, 또 다른 페이지는 pages/에 있어 명확하지 않음
- 컴포넌트 이름이 _page.js, book.js 등으로 혼동
- 역할이 명확히 드러나지 않음 (컴포넌트? 라우팅 페이지?)
2. 중복되거나 모호한 디렉토리
- Original에 있는 디렉토리 구조가 매우 복잡함.
- components/pages/ 와 pages/가 동시에 있음
- 기능 단위가 아니라 UI 단위로 구성됨 (재사용 어려움)
| 타입 | 접미사 추천 | 예시 |
| 페이지 컴포넌트 | Page | login_page.js => LoginPage.jsx, mypage_page.js => MyPage.jsx |
| 재사용 UI 컴포넌트 | 명확한 기능 이름 | Header.jsx, BookingCard.jsx |
| API 요청 | 기능 + Api | bookingApi.js, authApi.js |
| 훅 | use 접두사 | useBooking.js, useAuth.js |
| 유틸 | 기능 이름 그대로 | formatDate.js, validateInput.js |
4. 개선 방향: 리팩토링 전략
✅ 1차 리팩토링: JavaScript + Vite 기반으로 구조 정리
- CRA 탈출 → Vite 기반 개발환경 구축
- 속도 개선 + 설정 유연성 확보 (훨씬 빠른 HMR, 빌드 속도)
- 기존 JS 코드를 그대로 옮기며 구조, 코드 리팩토링
- 디렉토리 정리 (components, pages, hooks, api 등)
** 디렉토리 구조 정리 **
src/
├── assets/ # 정적 파일 (이미지, 폰트 등)
│ ├── images/
│ └── fonts/
│ ├── components/ # 공통 UI 컴포넌트 (공용/레이아웃)
│ ├── common/ # Button, Modal 등 재사용 컴포넌트
│ └── layout/ # Header, Footer 등 레이아웃 관련
│ ├── features/ # 기능 단위 폴더 (기능 중심 정리)
│ ├── booking/ # 예약 기능 관련 폴더
│ │ ├── components/ # 해당 기능 전용 컴포넌트
│ │ │ ├── BookingForm.jsx
│ │ │ └── BookingComplete.jsx
│ │ ├── pages/ # 해당 기능 전용 라우트 대상 페이지
│ │ │ └── BookingPage.jsx
│ │ ├── bookingApi.js # 기능 전용 API
│ │ └── useBooking.js # 기능 전용 커스텀 훅
│ ├── auth/
│ │ ├── components/
│ │ ├── pages/
│ │ ├── authApi.js
│ │ └── useAuth.js
│ └── ...
│ ├── pages/ # 전체 라우팅 대상 (빠른 참조용 or 라우트 직접 연결 시)
│ └── NotFoundPage.jsx
│ ├── routes/ # 라우터 정의
│ └── AppRouter.jsx
│ ├── hooks/ # 공통 커스텀 훅
│ └── useModal.js
│ ├── api/ # 공통 API 설정
│ └── axiosInstance.js
│ ├── utils/ # 공통 유틸 함수
│ └── formatDate.js
│ ├── styles/ # 전역 스타일, 테마
│ ├── global.css
│ └── variables.js
│ ├── App.jsx # App 루트 컴포넌트
└── main.jsx # Vite 기준 진입점 (CRA의 index.js 역할)
- 이 구조의 장점 : 한 기능에 필요한 컴포넌트, 페이지, 훅, API 모두 모아두고 공통 컴포넌트는 분리함.
- 확장성이 탁월하고 나중에 Next.js로 전화할 때 호환성 높음.
✅ 2차 리팩토링: TypeScript + Next.js로 확장
- Next.js의 SSR/SEO, 라우팅, API 등 고급 기능 활용
- 코드가 정리된 상태에서 TS 전환하므로 수월
- 타입 안전성 확보로 유지보수성 향상.
5. .js vs .jsx 차이?
- .js는 순수 자바스크립트 파일
- .jsx는 JSX(HTML-like) 문법을 포함하는 파일 (js의 확장 : JS + XML 문법 => 리액트 컴포넌트 만들 때 쓰는 형식)
- CRA나 Vite에서는 .js에서도 JSX 사용 가능하지만, .jsx로 명시하면 가독성과 협업에 좋음!!
6. 향후 계획 (마이그레이션 로드맵)
1. CRA 기반 JS 프로젝트 → Vite로 재세팅
2. 디렉토리 구조, 상태 관리 정리
3. 타입스크립트 환경 세팅 → 점진적 파일 전환 (.js → .ts)
4. Next.js로 마이그레이션 (파일 기반 라우팅, API routes 등)
- 코드를 단순히 보기 좋고 예쁘게 고치는 게 아니라, 앞으로의 확장성과 유지보수를 위한 "기반 설계 작업"을 진행할 것.
'Project > 감행' 카테고리의 다른 글
| 감행 - #2 컨벤션 및 디렉토리 구조 정리 (0) | 2025.07.15 |
|---|---|
| 감행 - #1 리팩토링 시작 및 일정 정리 (0) | 2025.07.15 |