이번 팀프로젝트를 진행하면서 사용한 폴더구조를 정리해보려 한다
프로젝트 초기 세팅을 맡아서 진행했는데, 시간이 촉박해서 항상 했던 모듈화로 진행했는데 팀원들에게 설명을 잘못했는지, 기존에 예상했던 거와 다르게 만들어진 것들이 있었다
그래서 여태까지 했던 방법과 개선도니 폴더구조를 구체적으로 정리해놓으려 한다
이번 프로젝트에서 적용하고 싶었던 건
1. styled-component를 사용하면서 스타일 코드를 다른 파일로 분리하고 import 해서 사용하기
2. RTK slice 사용하기
3. 최대한 컴포넌트 / 페이지 단위로 분리하기 (이게 제일 안 됐다 )
진행한 프로젝트 구조 + else
assets/ : 이미지와 같은 정적 자원
components/ : 재사용 가능한 컴포넌트
hooks/
layouts/
pages/
redux/
utils/
routes/
supabase/
assets
이미지와 같은 정적 자원을 모아두는 곳이다
components/
각 컴포넌트들을 별도의 폴더로 만들고, `컴포넌트.styled.jsx` 이름으로 styled-component를 분리했다
또한 각 컴포넌트에 index.js을 만들어 default 컴포넌트를 다시 내보내기를 진행했다 export {default} from ‘./component’
hooks/
커스텀 훅을 모아두는 곳이다
처음에 폴더 이름을 대문자로 적어놓고, 깃허브에 올라갔다
파일 이름은 변경이 되는데 이미 올라간 폴더 이름이 수정이 안됨 + 명령어 안먹음 ㅋㅋㅠㅠ
깃허브에서 직접 수정했다.. 하
layouts/
레이아웃을 모아둔 폴더
라우트에서 layout은 path가 없고, 해당 layout을 사용하는 페이지들을 children으로 넣어두었다
pages/
페이지 단위 컴포넌트로, 라우팅 처리를 진행한다
로그인 페이지, 회원가입 페이지, 대시보드 페이지 등
redux/
리덕스 관련 코드를 모아두는 곳이다
이번에 전역 상태를 거의 막바지에 설정하면서, mock data로 작성된 코드를 고치기가 너무 어려웠다 ㅠㅍㅠ
오히려 처음부터 작성하는게 빠를 정도로 하,,
utils/
formatData, fetcher처럼 공용 함수를 모아두는 곳이다
이번에는 사용하지 않았다
- 날짜 포맷, 문자열 처리 등..
api/
주로 API 호출을 관리하고, 서버 통신을 위한 코드가 모아져 있다
HTTP 요청/응답 처리나, API 엔드포인트에 대한 요청 및 응답 처리가 포함된다
// api/userApi.js
import axios from 'axios';
export async function getUser(userId) {
const response = await axios.get(`/api/users/${userId}`);
return response.data;
}
services/
utils와 비슷하게 공용 함수를 모아두는 곳인데, 비즈니스 관련 로직을 모아두는 곳이다
api처리를 담아놓기도 하는데, API 호출을 포함한 더 높은 수준의 기능을 제공하는 목적이다
// services/userService.js
import { getUser } from '../api/userApi';
export async function fetchAndFormatUser(userId) {
const userData = await getUser(userId); // api 폴더에서 가져옴
// 비즈니스 로직 처리 (예: 데이터 가공)
return {
id: userData.id,
name: `${userData.firstName} ${userData.lastName}`,
};
}
routes/
이번 프로젝트에서는 public route만 있었지만, privateRoute처럼 별도의 라우트를 사용할 수 있기 때문에 별도의 폴더를 구성한다
supabase/
이번에 supabase를 사용하면서 client와 호출 api를 이곳에 모아두었다
그런데 다음에는 supabase 설정 코드만 해당 폴더에 넣어두고, api는 api 폴더를 따로 만들어서 모아두어야겠다
폴더구조 조사
이것저것 찾아본 결과 모듈화된 폴더 구조(Modular Structure)와 대규모 애플리케이션 폴더 구조(Scalable Structure)가 있었다
모듈화된 폴더 구조(Modular Structure)
지금까지 사용했던 방법이다
간단한 구조로 빠르게 설정이 가능하고, 폴더를 기능별로 모듈화하여 관리하여 이해하기 편하다
해당 구조는 Feature-Based Structure 으로 각 기능별로 컴포넌트,서비스,스타일등을 포함하는 폴더를 만든다
my-app/
│
├── public/
│ ├── index.html
│ └── ...
│
├── src/
│ ├── components/ # 재사용 가능한 공통 컴포넌트
│ │ ├── Button.js
│ │ ├── Header.js
│ │ └── ...
│ │
│ ├── pages/ # 페이지 단위 컴포넌트
│ │ ├── HomePage.js
│ │ ├── AboutPage.js
│ │ └── ...
│ │
│ ├── services/ # API 호출 등 비즈니스 로직
│ │ ├── api.js
│ │ └── ...
│ │
│ ├── hooks/ # 커스텀 훅
│ │ ├── useAuth.js
│ │ └── ...
│ │
│ ├── context/ # 컨텍스트 API
│ │ ├── AuthContext.js
│ │ └── ...
│ │
│ ├── styles/ # CSS 파일
│ │ ├── App.css
│ │ └── ...
│ │
│ ├── App.js
│ ├── index.js
│ └── ...
│
├── package.json
└── README.md
대규모 애플리케이션 폴더 구조(Scalable Structure)
해당 폴더구조는 복잡하고 다양한 기능을 포함하는 대규모 프로젝트에 적합하다
해당 구조는 Domain-Driven Structure으로, 기능별로 모듈화하면서, 도메인 별(auth, dashboard)로 세분화하여 관리하는 것이 특징이다
my-app/
│
├── public/
│ ├── index.html
│ └── ...
│
├── src/
│ ├── components/
│ │ ├── common/ # 공통 컴포넌트
│ │ │ ├── Button.js
│ │ │ └── ...
│ │ └── layout/ # 레이아웃 관련 컴포넌트
│ │ ├── Header.js
│ │ └── ...
│ │
│ ├── features/ # 기능 단위 컴포넌트
│ │ ├── auth/ # 인증 관련 기능
│ │ │ ├── Login.js
│ │ │ ├── Register.js
│ │ │ └── ...
│ │ ├── dashboard/ # 대시보드 기능
│ │ │ ├── Dashboard.js
│ │ │ └── ...
│ │ └── ...
│ │
│ ├── services/
│ │ ├── api.js
│ │ └── ...
│ │
│ ├── hooks/
│ │ ├── useAuth.js
│ │ └── ...
│ │
│ ├── context/
│ │ ├── AuthContext.js
│ │ └── ...
│ │
│ ├── utils/ # 유틸리티 함수
│ │ ├── formatDate.js
│ │ └── ...
│ │
│ ├── styles/
│ │ ├── App.css
│ │ └── ...
│ │
│ ├── App.js
│ ├── index.js
│ └── ...
│
├── package.json
└── README.md