Next.js 15 App Directory 폴더 구조 알아보기
├── src/
│ ├── app/
│ │ ├── (auth)/ # 인증이 필요한 라우트 그룹
│ │ │ ├── dashboard/
│ │ │ ├── profile/
│ │ │ └── layout.tsx
│ │ ├── (marketing)/ # 마케팅/공개 페이지 라우트 그룹
│ │ │ ├── about/
│ │ │ ├── blog/
│ │ │ └── layout.tsx
│ │ ├── api/ # API 라우트
│ │ ├── error.tsx # 전역 에러 페이지
│ │ ├── layout.tsx # 루트 레이아웃
│ │ ├── loading.tsx # 전역 로딩 상태
│ │ └── page.tsx # 홈페이지
│ ├── components/
│ │ ├── common/ # 공통 컴포넌트
│ │ │ ├── Button/
│ │ │ ├── Input/
│ │ │ └── Card/
│ │ ├── features/ # 특정 기능 관련 컴포넌트
│ │ │ ├── auth/
│ │ │ ├── dashboard/
│ │ │ └── profile/
│ │ └── layout/ # 레이아웃 관련 컴포넌트
│ │ ├── Header/
│ │ ├── Footer/
│ │ └── Sidebar/
│ ├── hooks/ # 커스텀 훅
│ │ ├── useAuth.ts
│ │ └── useForm.ts
│ ├── lib/ # 유틸리티 함수와 설정
│ │ ├── utils/
│ │ ├── config/
│ │ └── constants/
│ │ └── store/
│ ├── services/ # API 서비스 로직
│ │ ├── auth.ts
│ │ └── api.ts
│ ├── styles/ # 전역 스타일
│ │ └── globals.css
│ └── types/ # 타입 정의
│ └── index.ts
├── public/ # 정적 파일
│ ├── images/
│ └── fonts/
└── middleware.ts # 인증, 로깅 등의 공통 기능 처리
└── package.json주요 디렉토리 설명
app 디렉토리
Next.js에서 페이지를 생성할 때 `page.tsx` 외에도 `error.tsx`, `loading.tsx`와 같은 예약된 파일명을 사용해야 합니다. 괄호(`()`)는 라우트를 그룹화할 때 사용되며, URL 경로에는 포함되지 않습니다.
(auth), (marketing): 라우트 그룹으로 관련 페이지들을 논리적으로 구분
api/: 서버리스 API 엔드포인트
layout.tsx: 전역 레이아웃 정의
error.tsx, loading.tsx: 전역 에러 및 로딩 상태 처리
components 디렉토리
`components` 디렉토리는 개인적으로 선호하는 분류 체계를 확립하는 것이 좋습니다. 예를 들어, 컴포넌트를 특정 카테고리별로 분리하거나, 기능별로 분류할 수 있습니다. 예: `Card/Card1.tsx`, `Card2.tsx`. 재사용성을 높이는 방향으로 분류하는 것이 중요합니다.
common/: 재사용 가능한 UI 컴포넌트
features/: 특정 기능이나 페이지에 종속된 컴포넌트
layout/: 페이지 구조를 구성하는 컴포넌트
lib 디렉토리
utils/: 유틸리티 함수
config/: 환경 설정
constants/: 상수 값 정의
store/: 전역 상태 관리
services 디렉토리
서버리스를 사용하면서 `services` 디렉토리까지 분류해야 하는지 고민해봤습니다. Reddit에서 확인한 자료에 따르면, 2,000명의 동시 사용자까지는 서버리스로 충분히 커버할 수 있다고 합니다. 하지만 직접 부하 테스트를 진행하지 않아 이 수치를 신뢰할 수 있을지는 의문입니다. 결과적으로, `services` 디렉토리는 선택적으로 사용하면 됩니다.
로직을 `route.tsx`에 모두 넣어도 정상 작동했습니다. 다만, 너무 긴 로직이나 복잡한 코드는 분리하는 것이 더 나은 방법일 수 있습니다. (현재의 서버리스 환경에서 복잡한 로직을 다루는 데 한계가 있습니다.)
API 통신 관련 로직 분리
각 도메인별 서비스 분리
폴더 구조 설계 원칙
1. 관심사 분리
각 폴더는 명확한 책임과 역할을 가짐
컴포넌트, 로직, 설정을 분리하여 관리
2. 확장성
새로운 기능 추가가 용이한 구조
도메인별 분리로 확장 가능
3. 재사용성
공통 컴포넌트와 유틸리티의 효율적 관리
중복 코드 최소화
4. 성능 최적화
라우트 그룹을 통한 코드 분할
컴포넌트 단위의 최적화 용이