배경

• domain 기준 관련있는 파일이 모여진 구조를 좋아해서 사이드 프로젝트 에 작업하다가,
  domain > components, common > components 같은 이상한 구조가 생겨서 좋은 구조를 찾다가 작년부터 유행하던 FSD 아키텍처를 적용하게 되었습니다.

FSD(Feature-Sliced Design)

• FSD는 기능 분할 설계를 의미, 2023년 7월에 공개.
  • 2018 React Berlin에 발표된 FDA(기능 주도 설계, Feature Driven Architecture)에서 파생
• 아키텍처의 스키마는 다음과 같습니다.

FSD 장점

1. 프로젝트 이해 난이도가 쉬워짐

• app, entities, pages, features, shared 로 분리된 프로젝트만 봐도 도메인, 초기 설정, 기능 등이 간결하게 분리되어 코드의 흐름이 눈에 잘 들어옴 -> 프로젝트의 복잡도와 규모가 빠르게 이해됩니다.
  • 프로젝트에 합류하는 신규 팀원이 코드를 찾는 속도가 다양한 구조에 비해 훨씬 빨랐습니다.

2. 여러 layer가 코드 복잡도를 낮춰서 생산성을 증가시킴

• 구조 기준때문에 한 파일에 복합적인 로직이 섞일 일이 적어지면서, 파일별 코드 이해도가 쉬워짐 -> 가독성up
• 순환 참조를 방지함
• 평소에도 layout, header 등 리렌더링이 필요없는 컴포넌트들을 나누는 게 맞지않나라는 생각을 가지고 있는데, widget layer의 존재덕분에 더이상 입씨름할 필요도 없어서 정말 마음이 편안합니다.

3. 디테일한 구조까지 잡을 수 있도록 문서가 상세함

• entity가 연관된 구조에 대한 문서도 존재 -> Cross-Import
  
  

4. FSD 구조를 아는 팀원들끼리 협업하면 정말 편함

• Material ui같은 유명한 ds 바탕으로 design system을 만들면 컴포넌트 구성에 대한 논의가 줄어드는것처럼, 사소하지만 중요한 파일 위치 & 폴더 구조에 대해 왈가왈부할 필요가 없어짐 -> PR review에 대한 에너지 소모가 줄어듭니다.
• FSD 아키텍처 linter도 존재해서, 컨벤션조차 필요없을 수 있습니다.
  • https://github.com/feature-sliced/steiger
  • https://github.com/feature-sliced/eslint-config/tree/master/rules/layers-slices

FSD 단점

1. hook 폴더가 segments 하단에 위치

• 보통 model or lib 폴더 아래에 hook이 존재하여, 폴더 구조에서 찾으려면 꽤 귀찮습니다.
• cursor 파일 검색이 jetbrain 제품에 비해 느려서 위 행동이 꽤 잦습니다.

2. 쉽게 추가하던 파일도 어디에 추가할지 고민이 생기고 시간이 소요됨

• 파일은 나중에 옮기면 되는데, 개발하기도 전에 components & hook 폴더에 추가하던 걸 어디에 추가할지 컨벤션 보면서 고민이 생기면서 짜증날 수 있음
  

3. FSD를 도입해도 도메인 로직이 흩어지는 부분은 있어서, 살짝 아쉬움

• PlacePage, PlaceDetailPage 분리 등
• review 는 어떤 layer에 들어가야할까? 그럼 review write는? 당연히 [ ]?

4. next의 page 폴더같이 프레임워크에서 정해진 rule이 있는 경우, 완벽한 fsd 구조를 만들기 힘듬

migration 순서

공식 문서 기준

내 기준

0. 폴더&파일 구조 분리에 재미를 느끼도록 최대한 고민이 필요없는 레이어부터 분리합니다.
1. 명확해서 분리하기 편한 App과 Entities 레이어를 기반으로 분리합니다.

• Entities를 먼저 하는 이유는 도메인 관련 코드 diff가 은근히 다방면으로 발생
• Entities > 도메인의 type, ui부터 분리하되 애매한 코드는 shared > domainName 폴더에 추가합니다. (entities? features?)

2. Page Layer에 화면별로 분리 후, Page Layer > ui 폴더로 파일&구조를 분리합니다.
   2.1 Header, GNB, App Bar 같은 ui를 컴포넌트로 쪼개서 Widget Layer 로 분리합니다.
3. shared > domainName 폴더 - store 관련 로직은 entities > model, react query 관련 코드는 features > model or api 폴더 이하에 분리합니다.
4. 사실 눈에 보이는 개선할 것들을 쭉쭉 개선하는 게 제일 재밌어서 상관없습니다.

결론

• 새로운 구조로 만드는 건 재밌으니까 꼭 해보세요

참조

• https://feature-sliced.design/kr/docs/get-started/overview
• https://feature-sliced.design/kr/examples
• (번역) 기능 분할 설계 - 최고의 프런트엔드 아키텍처
• 프론트엔드 개발자 관점으로 바라보는 관심사의 분리와 좋은 폴더 구조 (feat. FSD)
• FSD 관점으로 바라보는 코드 경계 찾기
• FSD Architecture - 기능 분할 설계