diff --git a/.npmrc b/.npmrc new file mode 100644 index 00000000..e9ee3cb4 --- /dev/null +++ b/.npmrc @@ -0,0 +1 @@ +legacy-peer-deps=true \ No newline at end of file diff --git a/docs/back-end/back-end.md b/docs/back-end/.gitkeep similarity index 100% rename from docs/back-end/back-end.md rename to docs/back-end/.gitkeep diff --git a/docs/fornt-end/REFACTORING-DETAILS.md b/docs/fornt-end/REFACTORING-DETAILS.md new file mode 100644 index 00000000..694f7d7c --- /dev/null +++ b/docs/fornt-end/REFACTORING-DETAILS.md @@ -0,0 +1,339 @@ +# 리팩토링 상세 - 중간/낮은 우선순위 + +이 문서는 [메인 리팩토링 문서](./REFACTORING.md)의 중간 및 낮은 우선순위 항목들의 상세 내용을 담고 있습니다. + +## 🟡 중간 우선순위 + +### 4. 긴 컴포넌트 분리 + +**문제점:** + +- `BoardList.tsx` (236줄), `BoardDetail.tsx` (423줄) 등 컴포넌트가 과도하게 길음 +- 단일 책임 원칙 위반 + +**리팩토링 방안:** + +- 컴포넌트를 더 작은 단위로 분리 +- Custom Hook으로 로직 분리 +- Presentational/Container 패턴 적용 + +**예상 효과:** + +- 코드 가독성 향상 +- 재사용성 증가 +- 테스트 용이성 향상 + +--- + +### 5. 하드코딩된 값들 상수화 + +**문제점:** + +- 권한 체크 로직에 하드코딩된 문자열 배열 +- 메뉴 ID 매핑이 하드코딩됨 +- 매직 넘버 사용 + +**현재 코드:** + +```typescript +// BoardList.tsx +if (['sponsor', 'usage', 'notice', 'executive'].includes(url) && isAuthorizedOverSecretary) { + return true; +} + +// BoardDetail.tsx +switch (pathName1) { + case 'introduce': + menuId = 1; + break; + case 'activity': + menuId = 2; + // ... +} +``` + +**리팩토링 방안:** + +- 상수 파일 생성: `src/constants/boardTypes.ts`, `src/constants/menuIds.ts` +- Enum 또는 const 객체로 관리 +- 타입 안정성 확보 + +**예상 효과:** + +- 유지보수성 향상 +- 오타 방지 +- 타입 안정성 개선 + +--- + +### 6. 환경변수 관리 개선 + +**문제점:** + +- `.env` 파일 하나로 개발/프로덕션 구분이 안 됨 +- 환경변수 타입 체크 없음 + +**리팩토링 방안:** + +- `.env.development`, `.env.production` 분리 +- 환경변수 타입 정의 및 검증 함수 생성 +- `src/config/env.ts` 생성 + +**예상 효과:** + +- 환경별 설정 명확화 +- 설정 오류 조기 발견 +- 개발 환경 개선 + +--- + +## 🟢 낮은 우선순위 + +### 7. 주석 처리된 코드 제거 + +**문제점:** + +- `useFetch.tsx`에 주석 처리된 `console.log` 다수 +- 사용하지 않는 코드 존재 + +**리팩토링 방안:** + +- 주석 처리된 코드 제거 +- 필요시 로깅 라이브러리 도입 (예: `winston`, `pino`) + +--- + +### 8. Modal 컴포넌트 리팩토링 + +**문제점:** + +- `Modal.tsx`에서 조건부 렌더링이 복잡함 +- 타입별 모달 컴포넌트 매핑이 하드코딩됨 + +**현재 코드:** + +```typescript +{(modalType.type === "major" && ) || + (modalType.type === "changeName" && ) || + // ... 많은 조건들 +} +``` + +**리팩토링 방안:** + +- 모달 타입별 컴포넌트 매핑 객체 생성 +- Factory 패턴 적용 + +--- + +### 9. API 호출 패턴 통일 + +**문제점:** + +- 일부 컴포넌트에서 `useFetch` 사용 방식이 일관되지 않음 +- 토큰 필요 여부 판단 로직이 분산됨 + +**리팩토링 방안:** + +- API 호출 래퍼 함수 생성 +- 토큰 필요 여부를 URL 기반으로 자동 판단 + +--- + +### 10. 폴더 구조 개선 + +**문제점:** + +1. **Components 폴더 구조의 혼란** + + - `Common/`, `Component/`, `Container/`, `Page/`로 나뉘어 있지만 구분 기준이 모호함 + - `Component/`와 `Page/`의 차이가 명확하지 않음 + - `Container/`는 Presentational/Container 패턴을 따르지만 일관성이 없음 + +2. **도메인별 파일 분산** + + - `Page/IBAS/`와 `Component/IBAS/`가 분리되어 있음 + - 같은 도메인(IBAS)의 관련 파일들이 여러 곳에 흩어져 있음 + - 도메인별 응집도가 낮음 + +3. **타입 파일 구조 불일치** + + - `Types/IBAS/` 하위에 일부 타입이 있고, 루트에도 타입이 있음 + - 일관성 부족 + +4. **유틸리티 파일 명명** + + - `Functions/`라는 이름이 모호함 (함수만 있는 게 아님) + - `utils/` 또는 `helpers/`가 더 명확할 수 있음 + +5. **스타일 컴포넌트 위치** + - `styles/assets/`에 컴포넌트들이 있는데, 스타일인지 컴포넌트인지 모호함 + +**현재 구조:** + +``` +src/ +├── Components/ +│ ├── Common/ # 공통 컴포넌트 +│ ├── Component/ # ??? (Page와의 차이 불명확) +│ ├── Container/ # Container 컴포넌트 (일부만) +│ └── Page/ # 페이지 컴포넌트 +├── Functions/ # 유틸리티 함수들 +├── Types/ # 타입 정의 (일부는 IBAS/ 하위) +└── styles/ + └── assets/ # 스타일 컴포넌트들 +``` + +**리팩토링 방안:** + +#### 옵션 1: Feature-based 구조 (권장) + +도메인/기능별로 파일을 그룹화: + +``` +src/ +├── features/ # 기능별 모듈 +│ ├── board/ +│ │ ├── components/ # Board 관련 컴포넌트 +│ │ ├── pages/ # Board 페이지 +│ │ ├── hooks/ # Board 관련 hooks +│ │ ├── types/ # Board 타입 +│ │ └── utils/ # Board 유틸리티 +│ ├── ibas/ +│ │ ├── components/ +│ │ ├── pages/ +│ │ ├── hooks/ +│ │ ├── types/ +│ │ └── utils/ +│ ├── lecture/ +│ └── auth/ +├── shared/ # 공통 모듈 +│ ├── components/ # 공통 컴포넌트 +│ ├── hooks/ # 공통 hooks +│ ├── utils/ # 공통 유틸리티 +│ ├── types/ # 공통 타입 +│ └── styles/ # 공통 스타일 +├── layouts/ # 레이아웃 +└── routes/ # 라우팅 +``` + +**장점:** + +- 도메인별 응집도 향상 +- 기능 추가/수정 시 관련 파일을 한 곳에서 찾을 수 있음 +- 코드 탐색이 쉬움 + +**단점:** + +- 마이그레이션 비용이 큼 +- 기존 구조와 완전히 다름 + +#### 옵션 2: 개선된 계층 구조 (점진적 마이그레이션) + +현재 구조를 유지하면서 개선: + +``` +src/ +├── components/ # 모든 컴포넌트 +│ ├── ui/ # 재사용 가능한 UI 컴포넌트 +│ │ ├── Button/ +│ │ ├── Input/ +│ │ └── Modal/ +│ ├── features/ # 기능별 컴포넌트 +│ │ ├── board/ +│ │ ├── ibas/ +│ │ └── lecture/ +│ └── layouts/ # 레이아웃 컴포넌트 +├── pages/ # 페이지 컴포넌트 +│ ├── board/ +│ ├── ibas/ +│ └── lecture/ +├── hooks/ # 모든 hooks +├── utils/ # Functions → utils로 변경 +├── types/ # 모든 타입 (도메인별 폴더) +│ ├── board.ts +│ ├── ibas/ +│ └── common.ts +└── styles/ # 스타일 + ├── components/ # 스타일 컴포넌트 + ├── theme.ts + └── global.ts +``` + +**장점:** + +- 현재 구조와 유사하여 마이그레이션 비용이 낮음 +- 점진적으로 개선 가능 +- 명확한 구분 + +**단점:** + +- 여전히 계층 구조 (도메인별 응집도는 낮음) + +#### 옵션 3: 하이브리드 구조 (실용적) + +중요한 부분만 개선: + +``` +src/ +├── components/ +│ ├── ui/ # 공통 UI 컴포넌트 +│ ├── features/ # 기능별 컴포넌트 +│ └── layouts/ # 레이아웃 +├── pages/ # 페이지만 분리 +├── hooks/ # hooks 통합 +├── utils/ # Functions → utils +├── types/ # 타입 통합 +└── styles/ # 스타일 +``` + +**리팩토링 전략:** + +1. **1단계: 명명 개선** + + - `Functions/` → `utils/` + - `styles/assets/` → `styles/components/` + +2. **2단계: 컴포넌트 통합** + + - `Component/`, `Container/`, `Page/`의 구분 명확화 + - 또는 `components/` 하나로 통합 + +3. **3단계: 도메인별 그룹화** + + - 같은 도메인의 파일들을 가까이 배치 + - 예: `components/board/`, `pages/board/`, `types/board.ts` + +4. **4단계: Feature-based 구조로 전환** (선택사항) + - 큰 리팩토링 시점에 고려 + +**예상 소요 시간:** + +- 옵션 2 (개선된 계층 구조): 2-3주 +- 옵션 1 (Feature-based): 4-6주 + +**권장 사항:** + +- **옵션 2 (개선된 계층 구조)**를 권장 +- 현재 구조와 유사하여 마이그레이션 비용이 낮음 +- 점진적으로 개선 가능 +- 팀의 학습 곡선이 낮음 + +--- + +### 11. 스타일 컴포넌트 중복 제거 + +**문제점:** + +- 유사한 스타일 컴포넌트가 여러 파일에 중복 정의됨 +- 예: `HorizonScrollDiv`가 여러 파일에 존재 + +**리팩토링 방안:** + +- 공통 스타일 컴포넌트를 `src/styles/components/`로 이동 +- 재사용 가능한 스타일 컴포넌트 라이브러리화 + +--- + +[← 메인 리팩토링 문서로 돌아가기](./REFACTORING.md) + diff --git a/docs/fornt-end/REFACTORING-MIGRATION.md b/docs/fornt-end/REFACTORING-MIGRATION.md new file mode 100644 index 00000000..04adf049 --- /dev/null +++ b/docs/fornt-end/REFACTORING-MIGRATION.md @@ -0,0 +1,484 @@ +# 장기 마이그레이션 계획 + +이 문서는 [메인 리팩토링 문서](./REFACTORING.md)의 장기 마이그레이션 계획을 담고 있습니다. + +## 개요 + +이 문서는 현재 사용 중인 기술 스택(CRA, Recoil, styled-components)을 최신 기술로 마이그레이션하는 계획을 다룹니다. + +> ⚠️ **주의**: 이 마이그레이션들은 **선택사항**이며, 현재 기술 스택이 정상 작동 중이므로 급하게 진행할 필요는 없습니다. + +--- + +## 10. npm → pnpm 마이그레이션 + +**현재 상황:** + +- **npm** 사용 중 (`package-lock.json` 존재) +- `package.json`에 `npm`이 dependencies에 포함되어 있음 (의도치 않은 것 같음) + +**pnpm의 장점:** + +- 🚀 **빠른 설치 속도**: npm/yarn보다 2-3배 빠름 +- 💾 **디스크 공간 절약**: 하드 링크를 사용하여 중복 패키지 저장 방지 +- 🔒 **엄격한 의존성 관리**: phantom dependencies 방지 +- 📦 **작은 node_modules**: 심볼릭 링크로 효율적인 저장 +- ✅ **npm/yarn과 호환**: 대부분의 npm 스크립트 그대로 사용 가능 + +**마이그레이션 난이도:** **매우 낮음** (거의 즉시 가능) + +**장점:** + +- 설치 속도 향상 +- 디스크 공간 절약 +- 더 엄격한 의존성 관리 +- npm과 거의 동일한 사용법 + +**단점:** + +- 팀원들이 pnpm을 설치해야 함 +- CI/CD 파이프라인 수정 필요 +- 일부 레거시 도구와 호환성 문제 가능 (거의 없음) + +**마이그레이션 단계:** + +#### 1단계: pnpm 설치 + +```bash +# npm으로 전역 설치 +npm install -g pnpm + +# 또는 Homebrew (macOS) +brew install pnpm + +# 또는 curl +curl -fsSL https://get.pnpm.io/install.sh | sh - +``` + +#### 2단계: 기존 lock 파일 제거 및 pnpm 설치 + +```bash +# 기존 lock 파일 제거 +rm package-lock.json # 또는 yarn.lock + +# pnpm으로 의존성 설치 +pnpm install +``` + +#### 3단계: `.npmrc` 설정 (선택사항) + +**`.npmrc` 파일 생성:** + +``` +# 엄격한 peer dependencies 검사 비활성화 (필요시) +strict-peer-dependencies=false + +# 또는 활성화 (권장) +strict-peer-dependencies=true +``` + +#### 4단계: `.gitignore` 확인 + +**`.gitignore`에 추가 (없는 경우):** + +``` +# pnpm +pnpm-lock.yaml +.pnpm-store/ +``` + +#### 5단계: CI/CD 파이프라인 수정 + +**GitHub Actions 예시:** + +```yaml +# 기존 (npm) +- uses: actions/setup-node@v2 + with: + node-version: '18' +- run: npm ci +- run: npm run build + +# 변경 (pnpm) +- uses: pnpm/action-setup@v2 + with: + version: 8 +- uses: actions/setup-node@v2 + with: + node-version: '18' + cache: 'pnpm' +- run: pnpm install --frozen-lockfile +- run: pnpm run build +``` + +**주의사항:** + +1. **`package.json`에서 `npm` 의존성 제거**: `"npm": "^10.0.0"` 제거 (의도치 않은 것 같음) +2. **스크립트는 그대로 사용 가능**: `npm start` → `pnpm start` (동일) +3. **`pnpm-lock.yaml` 커밋**: `package-lock.json` 대신 `pnpm-lock.yaml` 커밋 +4. **팀원 공지**: 모든 팀원이 pnpm 설치 필요 + +**예상 소요 시간:** **1일 이내** (매우 빠름) + +**마이그레이션 체크리스트:** + +- [ ] pnpm 설치 +- [ ] `package-lock.json` 제거 +- [ ] `pnpm install` 실행 +- [ ] `.gitignore`에 `pnpm-lock.yaml` 확인 (일반적으로 커밋함) +- [ ] `package.json`에서 불필요한 `npm` 의존성 제거 +- [ ] CI/CD 파이프라인 수정 +- [ ] 팀원들에게 pnpm 설치 안내 +- [ ] 빌드 및 테스트 확인 + +**권장 사항:** + +- **매우 쉬운 마이그레이션**이므로 **우선순위 높게 고려** 권장 +- npm과 거의 동일하게 사용 가능하여 리스크가 낮음 +- 개발 경험 향상 (빠른 설치, 디스크 공간 절약) +- **CRA → Vite 마이그레이션과 함께 진행**하면 좋음 + +**참고 자료:** + +- [pnpm 공식 문서](https://pnpm.io/) +- [pnpm vs npm vs yarn 비교](https://pnpm.io/feature-comparison) +- [pnpm GitHub Actions](https://github.com/pnpm/action-setup) + +--- + +## 11. CRA → Vite 마이그레이션 + +**현재 상황:** + +- **Create React App (CRA)** 기반 프로젝트 +- `react-scripts: 5.0.1` 사용 +- `package.json`에 `react-scripts start`, `react-scripts build` 스크립트 사용 + +**문제점:** + +- CRA는 더 이상 활발히 유지보수되지 않음 +- 빌드 속도가 느림 (Webpack 기반) +- 개발 서버 시작이 느림 +- 번들 크기가 큼 +- 커스터마이징이 어려움 (eject 필요) + +**Vite의 장점:** + +- ⚡ **매우 빠른 개발 서버**: HMR(Hot Module Replacement)이 즉시 반영 +- 🚀 **빠른 빌드**: esbuild 기반으로 빌드 속도가 CRA보다 10-100배 빠름 +- 📦 **작은 번들 크기**: Tree-shaking이 더 효율적 +- 🔧 **쉬운 설정**: 설정 파일이 간단하고 명확함 +- 🎯 **최신 표준**: ES modules, 최신 JavaScript 기능 지원 + +**마이그레이션 난이도:** **중간** + +**장점:** + +- 개발 경험(DX)이 크게 향상됨 +- 빌드 시간 단축 +- 최신 도구 사용 가능 +- 커뮤니티 활성도 높음 + +**단점:** + +- 일부 CRA 전용 설정을 수동으로 마이그레이션해야 함 +- 환경변수 처리 방식이 다름 (`REACT_APP_` → `VITE_`) +- 일부 플러그인/설정이 다를 수 있음 + +**마이그레이션 단계:** + +#### 1단계: Vite 설치 및 기본 설정 + +```bash +# Vite 및 플러그인 설치 +npm install -D vite @vitejs/plugin-react + +# 기존 react-scripts 제거 +npm uninstall react-scripts +``` + +#### 2단계: 설정 파일 생성 + +**`vite.config.ts` 생성:** + +```typescript +import { defineConfig } from 'vite'; +import react from '@vitejs/plugin-react'; +import path from 'path'; + +export default defineConfig({ + plugins: [react()], + resolve: { + alias: { + '@': path.resolve(__dirname, './src'), + }, + }, + server: { + port: 3000, + open: true, + }, + build: { + outDir: 'build', + }, +}); +``` + +#### 3단계: `index.html` 수정 + +**`public/index.html` → `index.html` (루트로 이동):** + +```html + + + + + + IBAS + + +
+ + + +``` + +#### 4단계: 환경변수 변경 + +**`.env` 파일 수정:** + +```bash +# CRA 방식 (기존) +REACT_APP_API_URL=https://www.inhabas.com/api + +# Vite 방식 (변경) +VITE_API_URL=https://www.inhabas.com/api +``` + +**코드에서 사용:** + +```typescript +// CRA 방식 (기존) +process.env.REACT_APP_API_URL; + +// Vite 방식 (변경) +import.meta.env.VITE_API_URL; +``` + +#### 5단계: `package.json` 스크립트 수정 + +```json +{ + "scripts": { + "dev": "vite", + "build": "vite build", + "preview": "vite preview", + "test": "vitest" // 또는 기존 jest 유지 + } +} +``` + +#### 6단계: 타입 정의 추가 + +**`src/vite-env.d.ts` 생성:** + +```typescript +/// + +interface ImportMetaEnv { + readonly VITE_API_URL: string; + readonly VITE_BASE_URL: string; + // ... 기타 환경변수 +} + +interface ImportMeta { + readonly env: ImportMetaEnv; +} +``` + +**주의사항:** + +1. **환경변수 접두사 변경**: `REACT_APP_` → `VITE_` +2. **환경변수 접근 방식**: `process.env` → `import.meta.env` +3. **public 폴더**: `public/` 폴더는 그대로 유지 (자동 처리) +4. **절대 경로**: `tsconfig.json`의 `paths` 설정 필요 +5. **SVG/이미지 import**: Vite는 기본적으로 지원하지만 설정 확인 필요 + +**예상 소요 시간:** 1-2주 + +**마이그레이션 체크리스트:** + +- [ ] Vite 설치 및 기본 설정 +- [ ] `vite.config.ts` 생성 +- [ ] `index.html` 루트로 이동 및 수정 +- [ ] 환경변수 접두사 변경 (`REACT_APP_` → `VITE_`) +- [ ] 환경변수 접근 방식 변경 (`process.env` → `import.meta.env`) +- [ ] `package.json` 스크립트 수정 +- [ ] 타입 정의 추가 (`vite-env.d.ts`) +- [ ] 절대 경로 설정 확인 +- [ ] 빌드 테스트 +- [ ] 배포 프로세스 확인 + +**권장 사항:** + +- **CRA → Vite 마이그레이션은 비교적 쉬움** (다른 마이그레이션보다) +- 개발 경험 향상이 크므로 **우선순위를 높게 고려**해볼 만함 +- 환경변수 변경만 주의하면 대부분 자동으로 작동 +- 단계적으로 진행 가능 (새 브랜치에서 테스트 후 병합) + +**참고 자료:** + +- [Vite 공식 문서](https://vitejs.dev/) +- [CRA to Vite Migration Guide](https://github.com/vitejs/vite/discussions/3048) +- [Vite React Plugin](https://github.com/vitejs/vite-plugin-react) + +--- + +## 12. Recoil → Zustand/Jotai 마이그레이션 + +**현재 상황:** + +- Recoil 사용: **436개 매치, 74개 파일** +- Recoil은 Meta에서 개발했지만, 최근에는 Zustand, Jotai, Redux Toolkit 등이 더 인기 + +**문제점:** + +- Recoil의 공식 지원이 약해지고 있음 +- 커뮤니티 활성도가 상대적으로 낮음 +- 번들 크기가 상대적으로 큼 + +**마이그레이션 옵션:** + +#### 옵션 1: Zustand (권장) + +- **장점:** + - 매우 가벼움 (~1KB) + - 간단한 API + - TypeScript 지원 우수 + - Recoil보다 학습 곡선이 낮음 +- **단점:** + - Recoil의 atom 개념과 다름 (Context 기반) +- **마이그레이션 난이도:** 중간 + +#### 옵션 2: Jotai + +- **장점:** + - Recoil과 유사한 atom 기반 API + - 마이그레이션이 상대적으로 쉬움 + - 가벼움 +- **단점:** + - 커뮤니티가 Zustand보다 작음 +- **마이그레이션 난이도:** 낮음 (Recoil과 유사) + +#### 옵션 3: React Context + useReducer + +- **장점:** + - 외부 라이브러리 불필요 + - React 내장 기능만 사용 +- **단점:** + - 성능 최적화가 필요할 수 있음 + - 복잡한 상태 관리에 부적합 +- **마이그레이션 난이도:** 높음 + +**마이그레이션 전략:** + +1. **점진적 마이그레이션**: 한 번에 모든 것을 바꾸지 않고, 새 기능부터 새 라이브러리 사용 +2. **병행 운영**: Recoil과 새 라이브러리를 동시에 사용하며 점진적으로 전환 +3. **마이그레이션 도구**: 자동 변환 스크립트 작성 (가능한 경우) + +**예상 소요 시간:** 4-6주 (전체 마이그레이션) + +**권장 사항:** + +- **지금 당장 마이그레이션할 필요는 없음** +- Recoil이 여전히 작동하고 있으므로, 새로운 프로젝트나 큰 리팩토링 시점에 고려 +- 팀의 학습 곡선과 프로젝트 일정을 고려하여 결정 + +--- + +## 13. styled-components → Tailwind CSS / CSS Modules 마이그레이션 + +**현재 상황:** + +- styled-components 사용: **75개 매치, 44개 파일** +- styled-components는 여전히 사용되지만, Tailwind CSS가 최근 트렌드 + +**문제점:** + +- 런타임 오버헤드 (CSS-in-JS) +- 번들 크기가 큼 +- SSR 시 성능 이슈 가능성 +- 최근 React Server Components와의 호환성 문제 + +**마이그레이션 옵션:** + +#### 옵션 1: Tailwind CSS (권장) + +- **장점:** + - 매우 빠른 개발 속도 + - 작은 번들 크기 (사용한 클래스만 포함) + - 유틸리티 퍼스트 접근 + - 커뮤니티 활성도 높음 +- **단점:** + - HTML 클래스명이 길어질 수 있음 + - 학습 곡선 (유틸리티 클래스 학습 필요) +- **마이그레이션 난이도:** 중간-높음 + +#### 옵션 2: CSS Modules + +- **장점:** + - 순수 CSS 사용 + - 스코프 격리 자동 + - 런타임 오버헤드 없음 +- **단점:** + - 동적 스타일링이 제한적 + - 테마 관리가 복잡할 수 있음 +- **마이그레이션 난이도:** 중간 + +#### 옵션 3: Emotion (styled-components 대체) + +- **장점:** + - styled-components와 유사한 API + - 더 작은 번들 크기 + - 더 나은 성능 +- **단점:** + - 여전히 CSS-in-JS (런타임 오버헤드) +- **마이그레이션 난이도:** 낮음 (API가 유사) + +**마이그레이션 전략:** + +1. **하이브리드 접근**: 새 컴포넌트는 Tailwind로, 기존은 유지 +2. **점진적 전환**: 컴포넌트별로 하나씩 마이그레이션 +3. **코드 변환 도구**: styled-components → Tailwind 변환 스크립트 활용 + +**예상 소요 시간:** 6-8주 (전체 마이그레이션) + +**권장 사항:** + +- **styled-components가 여전히 잘 작동하므로 급하게 마이그레이션할 필요는 없음** +- 새 프로젝트나 대규모 리팩토링 시점에 고려 +- 팀의 선호도와 프로젝트 특성에 따라 결정 +- 성능 문제가 실제로 발생하는지 먼저 측정 + +--- + +## 마이그레이션 우선순위 결정 기준 + +**마이그레이션을 고려해야 하는 경우:** + +- ✅ 실제 성능 문제가 발생하고 있음 +- ✅ 유지보수가 어려워지고 있음 +- ✅ 새로운 기능 추가가 기술 부채로 인해 어려움 +- ✅ 팀이 새로운 기술 스택을 학습할 여유가 있음 +- ✅ 큰 리팩토링을 계획 중임 + +**마이그레이션을 보류해야 하는 경우:** + +- ❌ 단순히 "최신 기술"이라는 이유만으로 +- ❌ 프로젝트가 안정적으로 작동 중 +- ❌ 팀의 학습 여유가 없음 +- ❌ 다른 우선순위 높은 작업이 많음 +- ❌ 마이그레이션 리스크가 높음 + +--- + +[← 메인 리팩토링 문서로 돌아가기](./REFACTORING.md) diff --git a/docs/fornt-end/REFACTORING-TESTING.md b/docs/fornt-end/REFACTORING-TESTING.md new file mode 100644 index 00000000..4ccfd5db --- /dev/null +++ b/docs/fornt-end/REFACTORING-TESTING.md @@ -0,0 +1,367 @@ +# 테스트 전략 + +이 문서는 [메인 리팩토링 문서](./REFACTORING.md)의 테스트 작성 전략을 담고 있습니다. + +## 현재 상황 + +- ✅ 테스트 라이브러리 설치됨: `@testing-library/react`, `@testing-library/jest-dom` +- ✅ `setupTests.ts` 파일 존재 +- ❌ 실제 테스트 파일 없음 (0개) +- ✅ `package.json`에 test 스크립트 존재 + +## 테스트 작성 우선순위 + +### 🔴 1순위: 유틸리티 함수 테스트 (Unit Test) + +**대상:** + +- `src/Functions/dateFunction.tsx` +- `src/Functions/convertLabelFunctions.tsx` +- `src/utils/boardUrlMapper.ts` (리팩토링 후 생성 예정) + +**이유:** + +- 순수 함수라서 테스트가 쉬움 +- 의존성이 없어서 Mock 불필요 +- 비즈니스 로직의 핵심 +- 버그 발생 시 영향도가 큼 + +**예시:** + +```typescript +// src/Functions/__tests__/dateFunction.test.ts +import { DateFunction } from '../dateFunction'; + +describe('DateFunction', () => { + const { formatDateDay, formatDateMinute, formatDateT } = DateFunction(); + + describe('formatDateDay', () => { + it('날짜를 YYYY-MM-DD 형식으로 변환해야 함', () => { + const result = formatDateDay({ date: '2024-12-19T10:30:00' }); + expect(result).toBe('2024-12-19'); + }); + }); +}); +``` + +**예상 소요 시간:** 1주 + +--- + +### 🟡 2순위: Custom Hook 테스트 + +**대상:** + +- `src/Hooks/useFetch.tsx` + +**이유:** + +- 여러 컴포넌트에서 사용되는 핵심 Hook +- 복잡한 로직 (토큰 갱신, 에러 처리 등) +- 버그 발생 시 전체 앱에 영향 + +**주의사항:** + +- Recoil, React Router 의존성 Mock 필요 +- `@testing-library/react-hooks` 또는 `renderHook` 사용 + +**예시:** + +```typescript +// src/Hooks/__tests__/useFetch.test.tsx +import { renderHook, waitFor } from '@testing-library/react'; +import { RecoilRoot } from 'recoil'; +import useFetch from '../useFetch'; + +describe('useFetch', () => { + it('GET 요청이 성공하면 데이터를 반환해야 함', async () => { + // Mock fetch + global.fetch = jest.fn(() => + Promise.resolve({ + ok: true, + json: () => Promise.resolve({ data: 'test' }), + }) + ); + + const { result } = renderHook(() => useFetch(), { + wrapper: RecoilRoot, + }); + + await waitFor(() => { + expect(result.current[0]).toEqual({ data: 'test' }); + }); + }); +}); +``` + +**예상 소요 시간:** 1-2주 + +--- + +### 🟢 3순위: 공통 컴포넌트 테스트 (Component Test) + +**대상:** + +- `src/Components/Common/Loading.tsx` +- `src/Components/Common/Button.tsx` (스타일 컴포넌트) +- `src/Components/Common/Modal/Modal.tsx` +- `src/Components/Common/Dropdown.tsx` + +**이유:** + +- 여러 곳에서 재사용되는 컴포넌트 +- 상대적으로 테스트가 쉬움 +- UI 버그 조기 발견 + +**주의사항:** + +- Recoil, React Router 의존성 Mock 필요 +- 사용자 인터랙션 테스트 (`@testing-library/user-event`) + +**예시:** + +```typescript +// src/Components/Common/__tests__/Loading.test.tsx +import { render, screen } from '@testing-library/react'; +import Loading from '../Loading'; + +describe('Loading', () => { + it('로딩 스피너를 렌더링해야 함', () => { + render(); + expect(screen.getByRole('status')).toBeInTheDocument(); + }); +}); +``` + +**예상 소요 시간:** 2주 + +--- + +### 🔵 4순위: 페이지 컴포넌트 테스트 (Integration Test) + +**대상:** + +- `src/Components/Page/Board/BoardList.tsx` +- `src/Components/Page/Member/Login.tsx` +- `src/Components/Page/IBAS/Main.tsx` + +**이유:** + +- 사용자 플로우의 핵심 +- 복잡한 로직과 상태 관리 +- 통합 테스트로 전체 동작 확인 + +**주의사항:** + +- 많은 의존성 Mock 필요 (API, Recoil, Router 등) +- 테스트 작성 비용이 높음 +- 핵심 기능 위주로 작성 + +**예상 소요 시간:** 3-4주 + +--- + +### ⚪ 5순위: E2E 테스트 (선택사항) + +**대상:** + +- 주요 사용자 플로우 (로그인, 게시글 작성 등) + +**도구:** + +- Playwright +- Cypress + +**이유:** + +- 실제 사용자 시나리오 테스트 +- 브라우저 환경에서의 동작 확인 + +**주의사항:** + +- 설정 및 유지보수 비용이 높음 +- CI/CD 파이프라인 구축 필요 +- 우선순위 낮음 (선택사항) + +**예상 소요 시간:** 2-3주 (설정 포함) + +--- + +## 테스트 작성 전략 + +### 1. 점진적 접근 + +**단계별 진행:** + +1. **1단계**: 유틸리티 함수 테스트 (1주) +2. **2단계**: Custom Hook 테스트 (1-2주) +3. **3단계**: 공통 컴포넌트 테스트 (2주) +4. **4단계**: 페이지 컴포넌트 테스트 (3-4주) + +**원칙:** + +- 한 번에 모든 것을 테스트하려고 하지 않기 +- 새로 작성하는 코드부터 테스트 추가 +- 리팩토링하는 부분에 테스트 추가 + +--- + +### 2. 테스트 커버리지 목표 + +**현실적인 목표:** + +- **1년 목표**: 60-70% 커버리지 +- **우선순위 높은 파일**: 80% 이상 +- **유틸리티 함수**: 90% 이상 + +**주의:** + +- 커버리지 100%를 목표로 하지 않기 +- 의미 있는 테스트에 집중 +- 유지보수 비용 고려 + +--- + +### 3. 테스트 파일 구조 + +``` +src/ +├── Functions/ +│ ├── __tests__/ +│ │ ├── dateFunction.test.ts +│ │ └── convertLabelFunctions.test.ts +│ └── dateFunction.tsx +├── Hooks/ +│ ├── __tests__/ +│ │ └── useFetch.test.tsx +│ └── useFetch.tsx +└── Components/ + └── Common/ + ├── __tests__/ + │ └── Loading.test.tsx + └── Loading.tsx +``` + +**또는:** + +``` +src/ +├── Functions/ +│ ├── dateFunction.tsx +│ └── dateFunction.test.ts # 같은 폴더에 배치 +``` + +**권장:** 같은 폴더에 배치 (`.test.ts` 파일) + +--- + +### 4. 테스트 작성 가이드라인 + +**AAA 패턴 사용:** + +```typescript +describe('함수명', () => { + it('해야 할 일', () => { + // Arrange (준비) + const input = 'test'; + + // Act (실행) + const result = functionToTest(input); + + // Assert (검증) + expect(result).toBe('expected'); + }); +}); +``` + +**테스트 네이밍:** + +- `describe`: 테스트할 함수/컴포넌트명 +- `it`: "해야 할 일"을 명확하게 작성 +- 예: `it('날짜를 YYYY-MM-DD 형식으로 변환해야 함')` + +**Mock 사용 원칙:** + +- 외부 의존성만 Mock +- 순수 함수는 Mock 하지 않기 +- Mock은 최소한으로 사용 + +--- + +### 5. CI/CD 통합 + +**GitHub Actions 예시:** + +```yaml +name: Test +on: [push, pull_request] +jobs: + test: + runs-on: ubuntu-latest + steps: + - uses: actions/checkout@v2 + - uses: actions/setup-node@v2 + - run: npm ci + - run: npm test -- --coverage +``` + +**권장:** + +- PR 생성 시 자동 테스트 실행 +- 커버리지 리포트 생성 +- 테스트 실패 시 PR 머지 차단 + +--- + +## 테스트 작성 체크리스트 + +**유틸리티 함수:** + +- [ ] 정상 케이스 테스트 +- [ ] 엣지 케이스 테스트 (null, undefined, 빈 문자열 등) +- [ ] 에러 케이스 테스트 + +**Custom Hook:** + +- [ ] 초기 상태 테스트 +- [ ] 상태 변경 테스트 +- [ ] 에러 처리 테스트 +- [ ] 사이드 이펙트 테스트 + +**컴포넌트:** + +- [ ] 렌더링 테스트 +- [ ] 사용자 인터랙션 테스트 +- [ ] Props 변경 테스트 +- [ ] 조건부 렌더링 테스트 + +--- + +## 예상 소요 시간 및 리소스 + +**전체 테스트 작성:** + +- **1순위 (유틸리티)**: 1주 +- **2순위 (Hook)**: 1-2주 +- **3순위 (컴포넌트)**: 2주 +- **4순위 (페이지)**: 3-4주 +- **총 예상 시간**: 7-9주 + +**권장 접근:** + +- 새 기능 개발 시 테스트 함께 작성 +- 리팩토링 시 기존 테스트 보완 +- 점진적으로 커버리지 확대 + +--- + +## 참고 자료 + +- [React Testing Library 공식 문서](https://testing-library.com/react) +- [Jest 공식 문서](https://jestjs.io/) +- [Testing Best Practices](https://kentcdodds.com/blog/common-mistakes-with-react-testing-library) + +--- + +[← 메인 리팩토링 문서로 돌아가기](./REFACTORING.md) + diff --git a/docs/fornt-end/REFACTORING.md b/docs/fornt-end/REFACTORING.md new file mode 100644 index 00000000..32a322dc --- /dev/null +++ b/docs/fornt-end/REFACTORING.md @@ -0,0 +1,181 @@ +# 리팩토링 체크리스트 + +이 문서는 inhabas.com-front 프로젝트의 리팩토링이 필요한 부분들을 정리한 문서입니다. + +> 📚 **관련 문서** +> +> - [중간/낮은 우선순위 상세](./REFACTORING-DETAILS.md) +> - [장기 마이그레이션 계획](./REFACTORING-MIGRATION.md) +> - [테스트 전략](./REFACTORING-TESTING.md) + +## 🔴 높은 우선순위 + +### 1. 중복된 URL 매핑 로직 추출 + +**문제점:** + +- `BoardList.tsx`, `BoardDetail.tsx`, `BoardCreate.tsx`, `BoardSearch.tsx`에서 동일한 URL 매핑 로직이 반복됨 +- 새로운 게시판 타입 추가 시 여러 파일을 수정해야 함 + +**현재 코드:** + +```typescript +// 여러 파일에서 반복됨 +let fetchUrl: string; +if (url === 'alpha') { + fetchUrl = '/project/alpha'; +} else if (url === 'beta') { + fetchUrl = '/project/beta'; +} else if (url === 'sponsor') { + fetchUrl = '/scholarship/sponsor'; +} else if (url === 'usage') { + fetchUrl = '/scholarship/usage'; +} else if (url === 'opensource') { + fetchUrl = '/board/storage'; +} else if (url === 'contest') { + fetchUrl = '/contest/contest'; +} else if (url === 'activity') { + fetchUrl = '/contest/activity'; +} else { + fetchUrl = `/board/${url}`; +} +``` + +**리팩토링 방안:** + +- `src/utils/boardUrlMapper.ts` 생성 +- URL 매핑을 상수 객체로 관리 +- 타입 안정성 확보 (enum 또는 union type 사용) + +**예상 효과:** + +- 코드 중복 제거 (4개 파일 → 1개 유틸) +- 유지보수성 향상 +- 타입 안정성 개선 + +--- + +### 2. useFetch Hook 타입 안정성 개선 + +**문제점:** + +- `any` 타입 과다 사용 +- 반환 타입이 명확하지 않음 +- 제네릭 미활용 + +**현재 코드:** + +```typescript +const useFetch = (): [ + any, // ❌ any 타입 + (url: string, method: string, token?: string, sendData?: any, media?: boolean) => Promise +] => { + const [data, setData] = useState(null); // ❌ any 타입 + // ... +}; +``` + +**리팩토링 방안:** + +- 제네릭 타입 도입: `useFetch()` +- API 응답 타입 정의 +- 에러 타입 정의 + +**예상 효과:** + +- 타입 안정성 향상 +- IDE 자동완성 개선 +- 런타임 에러 감소 + +--- + +### 3. 에러 처리 로직 개선 + +**문제점:** + +- `useFetch.tsx`에서 에러 처리 로직이 복잡하고 중복됨 +- HTTP 상태 코드별 처리가 분산되어 있음 +- 에러 메시지가 `alert`로만 표시됨 + +**현재 코드:** + +```typescript +// 401 처리 +if (errorResponse.status === 401) { + navigate(-1); +} +// 403 처리 +if (errorResponse.status === 403) { + if (url === '/signUp') { + navigate('/'); + } else { + navigate(-1); + } +} +// 404 처리 +if (errorResponse.status === 404) { + navigate('/notfound'); +} +``` + +**리팩토링 방안:** + +- 에러 핸들러 클래스/함수 분리 +- HTTP 상태 코드별 처리 전략 패턴 적용 +- Toast 알림 시스템 도입 (alert 대신) + +**예상 효과:** + +- 에러 처리 일관성 향상 +- 사용자 경험 개선 +- 코드 가독성 향상 + +--- + +## 📋 리팩토링 실행 계획 + +### Phase 1: 기반 작업 (1-2주) + +1. ✅ URL 매핑 로직 추출 +2. ✅ 타입 정의 강화 +3. ✅ 상수 파일 생성 + +### Phase 2: 핵심 개선 (2-3주) + +4. ✅ useFetch 타입 안정성 개선 +5. ✅ 에러 처리 로직 개선 +6. ✅ 환경변수 관리 개선 + +### Phase 3: 구조 개선 (2-3주) + +7. ✅ 긴 컴포넌트 분리 +8. ✅ Modal 컴포넌트 리팩토링 +9. ✅ 폴더 구조 개선 (1단계: 명명 개선) +10. ✅ 스타일 컴포넌트 정리 + +### Phase 4: 마무리 (1주) + +11. ✅ 주석 코드 제거 +12. ✅ 테스트 작성 (자세한 내용은 [테스트 전략](./REFACTORING-TESTING.md) 참고) +13. ✅ 문서 업데이트 + +--- + +## 🎯 리팩토링 원칙 + +1. **점진적 개선**: 한 번에 모든 것을 바꾸지 않고 단계적으로 진행 +2. **기능 유지**: 리팩토링 중에도 기존 기능이 정상 작동해야 함 +3. **테스트 우선**: 리팩토링 전후 동작이 동일한지 확인 +4. **타입 안정성**: `any` 타입을 최대한 제거하고 명확한 타입 정의 +5. **코드 리뷰**: 리팩토링도 PR을 통해 리뷰 받기 + +--- + +## 📝 참고사항 + +- 리팩토링은 기능 추가와 분리하여 진행하는 것이 좋습니다 +- 각 리팩토링은 작은 PR로 나누어 진행하는 것을 권장합니다 +- 리팩토링 전후의 동작을 비교할 수 있도록 테스트 코드를 작성하는 것이 좋습니다 +- 중간/낮은 우선순위 항목은 [REFACTORING-DETAILS.md](./REFACTORING-DETAILS.md) 참고 +- 장기 마이그레이션 계획은 [REFACTORING-MIGRATION.md](./REFACTORING-MIGRATION.md) 참고 +- 테스트 전략은 [REFACTORING-TESTING.md](./REFACTORING-TESTING.md) 참고 diff --git a/docs/fornt-end/ROUTING.md b/docs/fornt-end/ROUTING.md new file mode 100644 index 00000000..08cb3388 --- /dev/null +++ b/docs/fornt-end/ROUTING.md @@ -0,0 +1,256 @@ +# 라우팅 구조 문서 + +## 개요 + +이 문서는 inhabas.com-front 프로젝트의 라우팅 구조와 권한별 접근 제한을 설명합니다. + +## 권한 체계 + +### 사용자 역할 (User Roles) + +1. **회장** (`CHIEF`) - 최고 권한 +2. **부회장** (`VICE_CHIEF`) - 부회장 권한 +3. **운영팀** (`EXECUTIVES`) - 운영팀 권한 +4. **총무** (`SECRETARY`) - 총무 권한 +5. **활동회원** (`BASIC`) - 일반 활동회원 +6. **비활동회원** (`DEACTIVATED`) - 비활동 회원 (졸업생 포함) +7. **미승인 회원** (`NOT_APPROVED`) - 승인 대기 중 +8. **회원가입 중** (`SIGNING_UP`) - 소셜로그인 직후 + +### 권한 레벨 + +- `OverVice`: 회장, 부회장 +- `OverExecutives`: 회장, 부회장, 운영팀 +- `OverSecretary`: 회장, 부회장, 운영팀, 총무 +- `OverBasic`: 회장, 부회장, 운영팀, 총무, 활동회원 +- `OverDeactivate`: 모든 승인된 회원 (비활동회원 포함) + +## 라우팅 구조 + +### 1. 최상위 라우트 (App.tsx) + +#### 인증이 필요 없는 페이지 + +``` +/login # 로그인 페이지 +/login/process # 로그인 처리 페이지 +/signup # 회원가입 페이지 +/signup/question # 회원가입 질문 페이지 +/rule/:id # 규칙 페이지 +/notfound # 404 페이지 +``` + +#### 인증이 필요한 페이지 (HeaderNavLayout) + +``` +/* # 모든 인증된 페이지 +``` + +### 2. 메인 네비게이션 라우트 (HeaderNavLayout.tsx) + +``` +/ # 메인 페이지 +/introduce # 소개 페이지 +/honor # 명예 페이지 +/myInfo # 내 정보 페이지 +/scholarship # 장학금 페이지 +/* # 기타 모든 페이지 (HeaderTitleLayout으로 위임) +``` + +### 3. 제목 헤더 라우트 (HeaderTitleLayout.tsx) + +``` +/* # 메인 라우트 (MainRoute) +/board/* # 게시판 라우트 (BoardRoute) +/lecture/* # 강의 라우트 (LectureRoute) +``` + +#### 관리자 전용 라우트 + +``` +/staff/member # 회원 관리 (OverSecretary 권한 필요) +/staff/member/newStudents # 신입생 관리 +/staff/member/application/:id # 신청서 관리 +/staff/member/students # 재학생 관리 +/staff/member/graduateStudents # 졸업생 관리 +/staff/manage # 직원 관리 (OverVice 권한 필요) +``` + +### 4. 메인 라우트 (MainRoute.tsx) + +``` +/activity # 활동 목록 +/activity/detail # 활동 상세 +/activity/detail/:id # 특정 활동 상세 +/activity/create # 활동 생성 +/activity/update/:id # 활동 수정 +``` + +#### 은행 관련 라우트 (OverDeactivate 권한 필요) + +``` +/bank # 은행 관리 +/bank/support # 지원금 관리 +/bank/support/detail/:id # 지원금 상세 +/bank/support/create # 지원금 생성 +/bank/support/update/:id # 지원금 수정 +``` + +### 5. 게시판 라우트 (BoardRoute.tsx) + +#### 비활동회원 이상 접근 가능 + +``` +/board/opensource # 오픈소스 게시판 +/board/opensource/detail/:id # 오픈소스 상세 +/board/opensource/create # 오픈소스 작성 +/board/opensource/update/:id # 오픈소스 수정 + +/board/sponsor # 후원 게시판 +/board/sponsor/detail/:id # 후원 상세 +/board/sponsor/create # 후원 작성 +/board/sponsor/update/:id # 후원 수정 + +/board/usage # 이용안내 게시판 +/board/usage/detail/:id # 이용안내 상세 +/board/usage/create # 이용안내 작성 +/board/usage/update/:id # 이용안내 수정 + +/board/contest # 공모전 게시판 +/board/contest/detail/:id # 공모전 상세 +/board/contest/create # 공모전 작성 +/board/contest/update/:id # 공모전 수정 + +/board/activity # 활동 게시판 +/board/activity/detail/:id # 활동 상세 +/board/activity/create # 활동 작성 +/board/activity/update/:id # 활동 수정 +``` + +#### 활동회원 이상 접근 가능 + +``` +/board/alpha # 알파 게시판 +/board/alpha/detail/:id # 알파 상세 +/board/alpha/create # 알파 작성 +/board/alpha/update/:id # 알파 수정 + +/board/beta # 베타 게시판 +/board/beta/detail/:id # 베타 상세 +/board/beta/create # 베타 작성 +/board/beta/update/:id # 베타 수정 +``` + +#### 비활동회원 이상 접근 가능 (내부 게시판) + +``` +/board/notice # 공지사항 +/board/notice/detail/:id # 공지사항 상세 +/board/notice/create # 공지사항 작성 +/board/notice/update/:id # 공지사항 수정 + +/board/free # 자유게시판 +/board/free/detail/:id # 자유게시판 상세 +/board/free/create # 자유게시판 작성 +/board/free/update/:id # 자유게시판 수정 + +/board/question # 질문게시판 +/board/question/detail/:id # 질문게시판 상세 +/board/question/create # 질문게시판 작성 +/board/question/update/:id # 질문게시판 수정 + +/board/suggest # 건의게시판 +/board/suggest/detail/:id # 건의게시판 상세 +/board/suggest/create # 건의게시판 작성 +/board/suggest/update/:id # 건의게시판 수정 +``` + +#### 총무 이상 접근 가능 + +``` +/board/executive # 임원 게시판 +/board/executive/detail/:id # 임원 게시판 상세 +/board/executive/create # 임원 게시판 작성 +/board/executive/update/:id # 임원 게시판 수정 +``` + +### 6. 강의 라우트 (LectureRoute.tsx) + +``` +/lecture/ # 강의 목록 +/lecture/detail # 강의 상세 +/lecture/create # 강의 생성 +/lecture/room # 강의실 목록 +/lecture/room/announce # 강의실 공지 +/lecture/room/detail # 강의실 상세 +/lecture/room/create # 강의실 생성 +``` + +## 로그인 없이 접근 가능한 페이지 + +다음 페이지들은 로그인 없이도 접근할 수 있습니다: + +- `/board/opensource` +- `/board/sponsor` +- `/board/usage` +- `/board/contest` +- `/board/activity` +- `/activity` +- `/activity/detail` +- `/introduce` +- `/login` +- `/signup` +- `/signup/question` + +## 권한별 접근 가능한 기능 + +### 회장/부회장 (OverVice) + +- 모든 페이지 접근 가능 +- 직원 관리 (`/staff/manage`) + +### 운영팀 (OverExecutives) + +- 회장/부회장 권한 + 운영팀 전용 기능 + +### 총무 (OverSecretary) + +- 운영팀 권한 + 회원 관리 기능 +- 회원 관리 (`/staff/member/*`) +- 임원 게시판 관리 + +### 활동회원 (OverBasic) + +- 일반 회원 기능 +- 알파/베타 게시판 작성 권한 +- 은행 관련 기능 + +### 비활동회원 (OverDeactivate) + +- 읽기 전용 대부분 기능 +- 공개 게시판만 접근 가능 + +## 라우팅 파일 구조 + +``` +src/ +├── App.tsx # 최상위 라우팅 +├── Layout/ +│ ├── HeaderNavLayout.tsx # 네비게이션 헤더가 있는 레이아웃 +│ └── HeaderTitleLayout.tsx # 제목 헤더가 있는 레이아웃 +└── Routes/ + ├── MainRoute.tsx # 메인 라우트 + ├── BoardRoute.tsx # 게시판 라우트 + └── LectureRoute.tsx # 강의 라우트 +``` + +## 주의사항 + +1. **권한 검사**: 각 라우트는 `GetRoleAuthorization` 함수를 통해 권한을 검사합니다. +2. **로그인 상태**: `failRefreshing` 상태를 통해 로그인 여부를 확인합니다. +3. **자동 리다이렉트**: 권한이 없는 페이지 접근 시 이전 페이지로 자동 리다이렉트됩니다. +4. **동적 라우트**: `:id` 파라미터를 사용하는 동적 라우트들이 있습니다. + +## 업데이트 이력 + +- 2024-12-19: 초기 라우팅 문서 작성 diff --git a/docs/fornt-end/front-end.md b/docs/fornt-end/front-end.md deleted file mode 100644 index e69de29b..00000000