항해플러스 6주차 - 관심사 분리와 폴더구조 (FSD)

단일 책임 원칙 FSD2025-08-15
#FSD#항해플러스

6주차 FSD

6주차 과제는 관심사 분리와 함께 하는 FSD였다. 처음에는 유명한 Container/Presentational 패턴처럼 규칙에 맞추어 분리를 진행하면 될 줄 알았으나.. 진짜 어려웠다. 구조가 조금 바뀌었고 원칙이 바뀌었을 뿐인데 파일 하나 생성하는 것도 이게 맞나? 같은 고민이 진짜 많이 들었던 것 같다. 회고지만 내가 이해한 FSD를 한번 정리해보려 한다.

FSD (Feature-Sliced Design)

post image

Feature-Sliced Design (FSD)는 프론트엔드 애플리케이션 구조를 위한 아키텍처 방법론이다.

계층(Layer)

FSD는 **계층(Layer)**과 슬라이스(Slice), 그리고 세그먼트(Segment) 개념으로 구성된다. 각 계층은 특정한 책임을 가지며, 상위 계층은 하위 계층에만 의존할 수 있다.

  • app - 앱 설정, 라우팅, 프로바이더 등 글로벌한 설정
  • pages - 페이지 조합
  • widgets - 독립적인 대형 UI, 기능 블록
  • features - 사용자 기능 (인터랙션, 이벤트 처리)
  • entities - 비즈니스 엔티티 (데이터 모델, API)
  • shared - 공통 유틸리티, UI 컴포넌트

슬라이스(Slice)

슬라이스는 비즈니스 도메인에 따라 Layer 내에서 코드를 나누는 개념이다. 같은 Layer 내 다른 Slice를 참조할 수 없으며 이 규칙이 높은 응집도와 낮은 결합도를 보장해준다.

세그먼트(Segment)

각 슬라이스 내부는 다음과 같은 세그먼트로 구성된다.

  • model - 비즈니스 로직, 상태, hooks
  • ui - UI 컴포넌트
  • api - API 관련 로직
  • lib - 유틸리티 함수
  • config - 설정

프로젝트에 적용한 FSD 구조

src/
├── app/                    # 앱 설정 및 프로바이더
│   ├── providers/         
│   ├── routers/           
│   └── styles/            
├── pages/                  # 페이지 조합
│   └── postsManager/
│       └── ui/
│           └── PostsManagerPage.tsx
├── widgets/               # 독립적인 UI 블록
│   ├── header/
│   ├── footer/
│   ├── postsTable/
│   └── postsFilter/
├── features/              # 사용자 기능
│   ├── post/
│   │   ├── model/
│   │   │   └── hooks/
│   │   └── ui/
│   ├── comment/
│   └── tag/
├── entities/              # 비즈니스 엔티티
│   ├── post/
│   │   ├── model/
│   │   │   ├── hooks/
│   │   │   ├── stores/
│   │   │   ├── keys.ts
│   │   │   └── types.ts
│   │   └── index.ts
│   ├── comment/
│   ├── tag/
│   └── user/
└── shared/                # 공통 컴포넌트/유틸
    ├── api/
    ├── lib/
    └── ui/

FSD에 대한 생각

FSD는 확실히 응집도는 높이고 결합도는 낮추는 데 도움이 된다.
역할별(components, hooks, utils)로 분리할 때 프로젝트가 커질수록 점점 원하는 파일을 찾기 어려워진다. 하지만 단일 페이지, 혹은 복잡도가 높지 않은 프로젝트라면? FSD는 오히려 과도한 구조화로 인해 개발 속도를 늦출 수 있다고 생각한다.

FSD의 핵심은 비즈니스 로직에 따른 분리다. 같은 도메인의 코드들이 한 곳에 모여 있어 유지보수가 편하고, 계층 간 의존성 규칙으로 인해 순환 참조나 잘못된 의존성을 방지할 수 있다. 특히 팀 단위로 개발할 때 각자의 도메인 영역이 명확히 구분되어 충돌 없이 작업할 수 있다는 점이 가장 큰 장점인 것 같다.

하지만 초기 설정 비용이 높고, 작은 기능 하나를 추가하더라도 여러 계층을 거쳐야 하는 번거로움이 있다. 또한 FSD 규칙을 정확히 이해하지 못하면 오히려 잘못된 구조로 이어질 수 있어 학습 곡선이 존재한다.

결론적으로 FSD는 중대형 프로젝트나 팀 단위 개발에서 진가를 발휘하는 아키텍처라고 생각한다. 프로젝트 규모와 팀 상황을 고려해서 적절히 선택하는 것이 중요할 것 같다.