⛰️  Introduction

📦 structure
┣ 📂 **public**
┣ 📂 **pages**
┃  ┣ 📂 **collection**
┃  ┃  ┣ 📜 index.page.tsx
┃  ┃  ┗ 📂 **src**
┃  ┃     ┣ 📂 features
┃  ┃     ┣ 📂 ui
┃  ┃     ┣ 📂 container
┃  ┃     ┗ 📂 hooks
┃  ┣ 📂 **src**
┃  ┃  ┗ 📂 **app**
┣ 📂 **src**
┃  ┣ 📂 **api**
┃  ┣ 📂 **assets**
┃  ┣ 📂 **atoms**
┃  ┣ 📂 **common**
┃  ┣ 📂 **constants**
┃  ┣ 📂 **container**
┃  ┣ 📂 **contracts**
┃  ┣ 📂 **hooks**
┃  ┣ 📂 **layouts**
┃  ┣ 📂 **lib**
┃  ┣ 📂 **stories**
┃  ┣ 📂 **styles**
┃  ┣ 📂 **types**
┃  ┗ 📂 **utils**

보통 컨벤션들에서는 features라는 폴더에서 특정 기능이나 영역 또는 도메인을 기준으로 그룹핑해서 독립적이고 재사용 가능한 모듈로 정리해놓거나 components 폴더에서 도메인의 이름으로 폴더를 생성하는 방법으로 개발자들간의 충돌을 예방합니다.

그러나 프론트엔드의 상황에서는 도메인마다 다양한 기능과 UI/UX, 데이터들이 있어서 도메인에 종속된 컴포넌트들은 결국 그 페이지를 벗어나서 사용될 일이 크게 많지 않았다고 느꼈고 오히려 그 모듈이 사용되는 페이지와 다른 폴더에 있어서 매번 찾는 피곤함을 느꼈습니다.

우리는 도메인에 종속적인 컴포넌트들과 재사용 가능한 컴포넌트를 효율적으로 분리할 방법을 ****서칭하던 중 Next.js에서 특정 설정들을 발견했습니다.

<aside> ☝ 폴더 설정 옵션에 관한 Next config 글 테스트 파일이나 컴포넌트에서 사용하는 기타 파일을 페이지 디렉토리에 배치할 수 있습니다. next.config.js 내에 pageExtensions 구성을 추가합니다.

</aside>

다음 옵션들로 하여금 지금의 불편함을 해소할 새로운 Directory 구조를 찾아낼 수 있었습니다.

**pages** 폴더에서는 각 도메인(route)마다 페이지 파일(index.page.tsx)과 해당 도메인에서만 사용되는

들을 해당 도메인 src 폴더에 담아 묶었습니다.

최상위 **src** 폴더에서는 공용적으로 사용되고 재사용되는 모듈, UI, hooks, 함수, 상수, 타입 등이 관리됩니다.