폴더구조 유목민의 FSD 발견

들어가며

한 달의 전의 나는 타인이다.

이 말을 아시나요? 제가 만들어낸 말입니다.

다른 사람의 코드를 볼 때마다, 과거의 내가 짠 코드를 볼 때마다 어디에 뭐가 있는지 모든게 리셋되서 파일을 찾는데 단단히 지쳐버렸습니다... 이제는 FSD를 받아들이기로 했습니다.

FSD란?

• Feature Sliced Design로 프론트엔드 애플리케이션 구조를 위한 아키텍처 방법론입니다.

• Layers, Slices, Segments는 모두 폴더 단위입니다.
• 각각의 Layers 안에는 Slices가 있고 각각의 Slices 안에는 Segments가 존재합니다

Layer

1. App* - Routing, Entrypoint, Global Styles, Provider 등 앱을 실행하는 모든 요소
2. Processes(더 이상 사용되지 않음) - 페이지 간 복합 시나리오
3. Pages - 전체 page 또는 중첩 Routing의 핵심 영역
4. Widgets - 독립적으로 동작하는 대형 UI·기능 블록
5. Features - 제품 전반에서 재사용되는 비즈니스 기능
6. Entities - user, product 같은 핵심 도메인 Entity
7. Shared - 프로젝트 전반에서 재사용되는 일반 유틸리티

• App·Shared Layer는 Slice 없이 곧바로 Segment로 구성됩니다.
  → 왜냐하면 두 폴더는 이미 공통된 영역이기 때문에, 별도의 Slice로 나눌 필요가 없습니다.
  
• 상위 Layer의 모듈은 자신보다 하위 Layer만 참조할 수 있습니다. 즉, 단방향으로 참조가 가능합니다.
  

→ ex) pages는 widgets를 참조할 수 있지만, widgets는 pages를 참조할 수 없습니다.
pages가 widgets의 상위 layer이기 때문입니다.
(= widgets → pages로 import ❌)
(= pages → widgets로 import ⭕️)

• Layer에 있는 모든 폴더를 써야하나요?
  • 필요할 때만 추가해도 됩니다.
    그러나 대부분의 프론트엔드 프로젝트에서는 최소한 shared , pages , app 은 포함합니다.

Slice

• Slice는 Layer 내부를 비즈니스 도메인별로 나눕니다.
  

⇒ 이름·개수에 제한이 없으며, 같은 Layer 내 다른 Slice를 참조할 수 없습니다.
왜냐하면 높은 응집도와 낮은 결합도를 유지하기 위해서입니다.

• ex) 로그인과 회원가입 기능이 features 폴더에 있다고 해봅시다.

  features/
   ├── sign-in/
   └── sign-up/
   

• features는 Layer 폴더이고 sign-in , sign-up은 features의 slice에 해당합니다.
  근데 이 둘은 서로 참조할 수 없습니다.
  (=sign-in → sign-up로 import ❌)
  (=sign-in ← sign-up로 import ❌)
  

Segment

• Slice와 App·Shared Layer는 Segment로 세분화되어, 기술적 목적에 따라 코드를 그룹화합니다.

  • ui - UI components, date formatter, styles 등 UI 표현과 직접 관련된 코드

  • api - request functions, data types, mappers 등 백엔드 통신 및 데이터 로직

  • model - schema, interfaces, store, business logic 등 애플리케이션 도메인 모델

  • lib - 해당 Slice에서 여러 모듈이 함께 사용하는 공통 library code

  • config - configuration files, feature flags 등 환경·기능 설정

    → 대부분의 Layer에서는 위 다섯 Segment로 충분합니다.

    필요하다면 App 또는 Shared Layer에서만 추가 Segment를 정의하세요. (필수 규칙은 아닙니다.)

아니 그래서 FSD 왜 써야됨 ?

• 일관성
  • 모든 팀원이 작성한 코드가 마치 한 사람이 작성한 것처럼 일관성을 가질 수 있습니다.
  • 폴더 구조와 참조 규칙이 미리 정의되어 있기 때문에, 여러 개발자가 동시에 작업하더라도 구조가 흐트러지지 않습니다.
  • 일관된 코드 구조는 유지보수를 쉽게 만들고, 새로운 팀원이 프로젝트에 빠르게 적응하도록 도와줍니다.
• 격리성
  • 단방향 참조와 기능 단위 분리 덕분에, 하나의 기능인 slice 를 삭제하거나 수정하더라도 다른 영역에 미치는 영향이 최소화됩니다.
    
  • “부분적인 변경이 전체를 깨뜨리지 않는다”는 점이 큰 장점입니다.
• 도메인 중심 구조
  • 폴더 구조가 비즈니스 도메인 중심(로그인, 장바구니, 결제 등) 으로 구성되어 있기 때문에 프로젝트의 전체 맥락을 몰라도 특정 기능을 독립적으로 개발할 수 있습니다.
  • 이는 기능 단위의 확장성과 테스트 용이성을 크게 높입니다.

그럼 언제 FSD를 써야됨?

• 프로젝트가 점점 커지면서, 기능 개발 속도가 느려졌을 때
• 새로운 팀원이 구조를 이해하기 어려운 상황일때

⇒ 즉, 우리 프로젝트에 구조 전환이 필요할 때 FSD를 고려하면 좋습니다.

마치며

완벽한 프로젝트 구조는 처음부터 나올 수 없다고 생각합니다.
하지만 꾸준히 다듬고 적용하다 보면, 한 달 뒤의 나는 지금의 나를 빠르게 이해하지 않을까요..?ㅎㅎ 아자아자 화이팅!

---

참고자료

https://feature-sliced.design/