Intro

공부한 지 얼마 되지 않았을 때는 강의을 보며 공부를 하였기 때문에 프로젝트의 폴더 구조에 대해 많이 고민하지 않았습니다.

그러나 코드의 볼륨이 커질수록 프로젝트의 폴더 구조를 효율적으로 나누는 것의 중요성을 알게 되었고 최근 정착한 폴더 구조가 맘에 들어 글로 쓰게 되었습니다.

폴더 구조

프로젝트마다 다양한 폴더구조가 있고 Next.js는 다양한 폴더구조를 허용하는 편입니다. 그 중 최근 제가 사용하며 편하다고 느낀 Next.js 의 프로젝트의 폴더 구조입니다.

├── package.json
├── pages
├── public
├── src
│   ├── components
│   │   └── common
│   ├── constants
│   ├── containers
│   │   ├── landing
│   │   │   ├── LandingPage.tsx
│   │   │   └── components
│   │   └── searching
│   │       ├── DetailPage.tsx
│   │       └── components
│   ├── hooks
│   ├── remotes
│   ├── styles
│   ├── types
│   └── utils
├── tsconfig.json
└── yarn.lock

Next.js src 문서 에서 확인할 수 있듯이 next.js 는 최상위 폴더로 src 폴더를 만들어 사용하는 것을 지원하고 있습니다.

하지만 저는 페이지 폴더를 라우팅 목적으로만 사용하면 굳이 src 에 넣을 필요는 없다는 생각에 pages 를 src 에 넣지 않고 분리하는 편입니다.

pages 폴더에서 src 안에 작성된 컴포넌트를 import 하여 데이터를 패칭하여 페이지를 생성하고 라우팅 할 수 있도록 구성하였습니다.

컴포넌트들은 atomic 구조를 사용하여, src에 containers 폴더를 만들어 components의 컴포넌트를 결합하여 만든 Page 컴포넌트를 만들었습니다.

components 폴더 내부에는 Header나 Layout, Text, Modal, Card, SEO를 위한 컴포넌트 와 같이 공통으로 사용되는 컴포넌트를 넣어놓았고

containers 폴더에 도메인 별로 각 페이지 폴더를 만든 뒤 해당 페이지를 구성하는 컴포넌트를 components/common 을 사용하여 조합하였습니다.

이렇게 설계했을 때의 장점은 각 페이지에 필요한 컴포넌트를 containers/해당 페이지/components 에서 관리할 수 있다는 것이었고. 페이지별 컴포넌트 관리가 편리하다 느꼈습니다.

또한 같은 도메인에 포함되는 복수의 페이지를 containers 폴더에서 함께 관리할 수 있습니다.

containers 폴더를 분리하지 않고 src/componetns 에서 폴더별로 관리했다면 페이지가 늘어날수록 컴포넌트를 수정하거나 추가해야 할 때 페이지별 컴포넌트 관리가 불편했을 것입니다.

Outro

폴더 구조에 정답은 없는 것 같습니다. 프로젝트마다 볼륨도 다르고, 고려해야 할 사항도 모두 다르기 때문입니다. 프로젝트의 속도에 영향을 주지 않는 선에서 개발에 편리한 폴더 구조를 고민해 보는 일은 프로젝트 진행에 앞서 한 번쯤 생각해 보아야 할 일인 것 같습니다.