Next.js 15 App Directory 폴더 구조 알아보기
KUKJIN LEE • 1주 전 작성
├── 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. 성능 최적화
-
라우트 그룹을 통한 코드 분할
-
컴포넌트 단위의 최적화 용이