이번주 6주차는 발제 주제가 FSD 파일구조였다.
사실 나도 이 파일구조를 회사에 한번 도입하려고 팀원과 기존 프로젝트를 뜯어 본 적이 있는데 그때 테스트 해본 프로젝트는 애초에 기능도 작고, 도메인으로 나올만한 것들이 별로 없어서 그 후에는 기능 단위 위주의 폴더구조를 사용하고 있었다.
그러다 프로젝트 중에 점차 기능이 많아지고, 기능 단위 파일구조에서도 컴포넌트들이 점차 커지면서 컴포넌트 안에서 코드를 어떤 기준으로 폴더링을 나누고 합쳐야 할지가 애매해졌다.
예를들어 이커머스라고 설명을 해보면
src/
├── hooks/
│ ├── product/
│ └── cart/
├── components/
│ ├── product/
│ └── cart/
├── services/
│ ├── product/
│ └── cart/
├── mocks/
│ ├── product/
│ └── cart/
├── utils/
│ ├── product/
│ └── cart/
└── config/
├── product/
└── cart/이런 느낌이라고 할 수 있겠다. 기능별 묶음 > 도메인 단위
이렇게 되다보니 같은 도메인끼리의 코드들이 멀리 떨어진다는 단점이 있었고 기능단위로는 응집도가 있었지만, 도메인 단위로는 응집도가 떨어졌다. 여기서 service, mocks, hooks는 거의 1대1대1로 사용을 하고 있어 명확했지만 특히 component 안에 도메인 내에서 컴포넌트들을 어떻게 폴더를 나눠서 끌고갈지가 점점 애매해졌다.
아마 위의 폴더 구조를 FSD 파일 구조로 바꾼다면
src/
├── entities/
│ ├── product/
│ │ ├── ui/
│ │ ├── model/
│ │ └── api/
│ └── cart/
│ ├── ui/
│ ├── model/
│ └── api/
├── features/
│ ├── product-filter/
│ │ ├── ui/
│ │ └── model/
│ └── cart-sync/
│ ├── ui/
│ └── model/
├── widgets/
│ ├── product-list/
│ └── cart-summary/
├── pages/
│ ├── product-detail/
│ └── cart/
└── shared/
├── ui/
├── api/
├── lib/
└── config/이런 느낌이 되지 않을까 생각한다.
우리 회사에는 많은 프로젝트가 있는데 내 생각에는 모든 프로젝트를 fsd로 끌고가자! 라는 규칙을 세우는건 오버엔지니어링이라 생각을 한다. 또한 기존에 기능단위로 만들어진 프로젝트를 fsd로 리팩토링을 하려면 상당한 시간과 비용이 들어가기 때문에 기존 우리의 기능단위 폴더 구조와 fsd 그 사이의 중간 지점을 찾아야 한다고 생각을 하였다.
이번 발제 주제인 FSD를 들으면서 FSD 파일구조의 장,단점을 좀 더 잘 알 수 있었고 우리 회사에 어떻게 적용을 해볼 수 있을지 아이디어를 더 얻을 수 있었던 것 같다.
파일 구조에는 정답은 없다고 생각을 한다.
FSD가 한때 큰 이슈가 되어 여기저기서 FSD를 공부하고 이게 최신 폴더구조니 이걸 적용해야해! 하는 개발자들도 보았는데 나는 이런 태도는 지양해야한다고 생각한다. 이것도 어떻게 보면 하나의 기준인거고, 이 기준이 모든 상황을 해결해 줄 수는 없을것 이다. 꼭 FSD가 아니더라도 FSD를 변형을 했던, 아니면 기존의 기능단위 폴더구조를 쓰던, 해당 프로젝트와 잘맞고 팀끼리 같이 개발하는데 문제가 없으면 나는 그것이 좋은 컨벤션이라고 생각을 한다.
아마 우리 회사에서도 규모가 큰 신규 프로젝트에 FSD를 한번 도입을 해보지 않을까 생각한다.
