폴더 구조

Jnnsu·2023년 12월 6일

서론

프로젝트를 할 때에 폴더 구조를 어떻게 짜야될까?

아직까지는 폴더가 많지 않아 내키는대로 정리해왔지만, 머릿속 한켠에는 항상 의문으로 남아있던 질문이다. 폴더구조를 어떻게 구성할지는 개인적인 부분이라 의견이 갈리는 부분이 많은 것 같다. 여러 블로그 글을 찾아보면 기능별로 구성, 파일타입 별로 구성, 관심사별로 구성 등 폴더구조를 구성하는 방식이 제각각이었다.

심지어 React 공식문서 상에도 명확한 방법이 없다고 명시되어 있다.

폴더 구조를 생각해봐야 하는 이유

프로젝트를 할 때에 파일들이 여기저기 산만하게 있다면 필요한 파일을 찾을 때 한세월이 걸릴 것이다.
폴더구조를 체계적으로 분류해두면 장기적으로 유지보수와 생산성을 끌어올려준다.

폴더 분류 방식

1. 파일 유형에 의한 분류

이 방법은 비슷한 파일을 그룹화하는 것이다. 예를 들면 다음과 같다.

├─ api
│  ├─ AboutAPI.js
│  ├─ ContactAPI.js
│  ├─ APIUtils.js
│  └─ APIUtils.test.js
└─ components
   ├─ About.js
   ├─ About.css
   ├─ Contact.js
   └─ Contact.css

이 유형 중 가장 유명한 방식은 Atomic Design이다.

위 사진에서 보듯이 각 요소들을 최소 단위로 쪼갠 후에 연관된 것들을 점점 큰 카테고리로 엮어 나가는 방식이다.

src
 └ components
   	   ├ pages
       ├ templates
       └ UI 
          ├ atom
          ├ molecules
          └ organism

장점

단위별 조합이 자유로워 유지보수가 좋다.
규모가 큰 프로젝트에서 구성이 용이하다.

단점

5단계의 부모자식 관계인 만큼 불필요한 props drilling이 발생하기 쉽다.
규모가 작은 프로젝트에서는 효율적이지 않을 수 있다.

2. 기능 또는 경로 별로 그룹화

어떤 기능을 담당하는지에 따라 CSS, JS 및 테스트를 함께 그룹화된 폴더 내에 두는 것이다. 혹은 특정 라우트에 속하는 기능들끼리만 묶어둘 수도 있을 것이다.

├─ common
│  ├─ Table.js
│  └─ Table.css
├─ about
│  ├─ index.js
│  ├─ About.js
│  └─ About.css
└─ contact
   ├─ index.js
   ├─ Contact.js
   └─ Contact.css

예를들어, 영화 리스트, 영화평 게시판, 관리자 페이지로 구성된 웹 페이지가 있다고 해보자. 세 가지 기능은 각각'/movie-list', '/movie-comment', '/admin'의 라우트에서 렌더링 된다. 그렇기 때문에 폴더 구조는 아래와 같이 구성될 수 있다.

src
 ├ list 
 │  └ info 
 ├ comment  	 
 │     └ form
 └ admin

"기능"은 그럼 무슨 기준으로 나누지?

공식문서에는 이렇게 나와있다.
"기능"의 정의는 보편적이지 않으며 세분성을 선택하는 것은 사용자의 몫입니다. 최상위 폴더 목록을 만들 수 없는 경우 제품 사용자에게 제품의 주요 부분이 무엇인지 물어보고 그들의 정신 모델을 청사진으로 사용할 수 있습니다.

.. 한마디로 "너가 알아서 정해라" 라는 거다.

장점

해당 폴더에서만 작업하면 되기 때문에 직관적이다.
불필요한 부모자식 관계가 최소화된다.

단점

재사용 가능성이 떨어질 수 있다.

❗️주의할 점

너무 깊은 폴더 구조의 중첩은 피하자.
깊은 폴더 구조가 형성되면 파일을 임포트하거나 파일 위치를 이동하게 될때면 어려움을 겪을 수 있으니 3단계 이상은 신중하게 생각해야 한다.

지나치게 생각하지 말기
React 공식문서에서는 프로젝트를 시작했다면 파일 구조를 선택하는 데에 5분 이상을 소비하지 말라고 한다. 위의 방식 중 하나를 선택하거나, 자신만의 방법으로 코드 작성을 시작하라고 한다. 왜냐면 어차피 코드를 작성하다보면 폴더 구조를 어떻게 짜야할지 다시 생각해보게 될것이기 때문이라나. 또 "colocation"이라는 방법도 추천해준다.

colocation

colocation은 서로 같이 쓰이는 파일들을 가까운 곳에 파일을 배치하는 방식이다.
예를 들어
sign-up-page.tsx
sign-up-page.test.tsx
이 두 파일은 성격적으로 전혀 다르지만 같이 둘 경우에 유지보수가 용이하다는 것이다.

처음에는 한곳에서만 사용됐지만, 프로젝트가 진행됨에 따라 다른 곳에서도 사용될 여지가 생긴다면 어쩌지?

https://xionwcfm.tistory.com/415
이 블로그 포스트를 보면
"공통으로 쓰일것이 확실한 파일 / 특정 부분에서만 쓰일것이 확실한 파일들을 분류하는것은 매우 쉽지만 그 중간 어딘가의 회색지대에 있는 파일들의 배치가 아주 애매했습니다. 예컨대 전체 애플리케이션에서 단 두 군데에서만 공유해서 사용하는 파일이 있다면 어떨까요? 혹은 원래는 한곳에서만 사용했는데 기획이 확장되며 여러곳에서 참조하게되면 어떨까요? 저는 일단은 한곳에서만 사용하면서 만약 공유해야하는 시점이 오면 그때에서야 공통적으로 사용할 수 있게 분리하는 편입니다만 이부분이 참 어렵게느껴지는 것 같습니다."

라고 되어있다. 그리고 해결 방안은 아래와 같았다고 한다.