FSD(Feature‑Sliced Design) 한눈에 보기

---

1) 요약

• 목적: 대규모 프런트엔드를 “기능 중심”으로 구조화해 변경 범위와 의존을 통제
• 원리: 레이어 → 슬라이스 → 세그먼트 3단 분할. 공개 API를 통해서만 상호작용
• 효과: 팀 병렬 개발, 코드 네비게이션, 재사용성, 테스트 용이성 향상
• 비교: 레이어드·클린과 달리 “비즈니스 기능 단위”를 1급 시민으로 삼아 UI·상태·데이터 코드를 같은 기능 폴더로 응집

1.1 기원과 배경

• 출발점: Feature‑Driven Architecture(FDA). 2018 React Day Berlin에서 Oleg Isonen이 기능 중심 분해와 병렬 개발 아이디어 소개
• 정식화: 커뮤니티에서 가이드를 정리하며 Feature‑Sliced Design(FSD)로 발전. Layers · Slices · Segments와 public API 규칙이 표준화
• 목적: 대규모 FE에서 탐색 용이성, 병렬 작업, 의존 통제를 강화하기 위한 실무적 아키텍처 가이드

---

2) 구조

레이어(Layers)
  app → pages → widgets → features → entities → shared
    • app: 전역 부팅·라우팅·프로바이더
    • pages: 라우팅 가능한 페이지(조립자)
    • widgets: 화면 영역(여러 피처 조합)
    • features: 사용자 가치 동작
    • entities: 도메인 엔티티
    • shared: 공용 UI·lib·api

슬라이스(Slices)
  • 레이어 내부의 비즈니스 단위 분해 (예: features/auth, entities/user)

세그먼트(Segments)
  • ui, model, api, lib, config
  • 공개 인터페이스는 루트 index.ts(또는 public API 파일)에서만 노출

핵심: 상위 레이어만 하위 레이어에 의존. 같은 레이어 간에는 각 슬라이스의 public API를 통해서만 상호작용.

---

3) 배경과 발전 흐름

3.1 참고: FDA(Feature‑Driven Architecture)

• 정의: 기능 중심으로 코드를 분해해 탐색성·병렬 개발·응집도를 높이는 프런트엔드 조직 원칙
• 목표: 기능 단위로 책임을 모으고, 공통 요소는 공유 레이어로 끌어내 중복과 결합을 줄임
• 핵심 아이디어
  • 기능별 모듈화: UI·로직·데이터 접근을 같은 기능 폴더에 응집
  • 팀 스케일링: 기능 단위 브랜치·리뷰·릴리즈가 가능하도록 경계를 명확히
  • 공용 추출: 토큰, 헬퍼, UI 키트 등은 공유 영역으로 승격
• FSD와의 관계
  • FSD는 FDA의 정신을 계승해 Layers · Slices · Segments, public API 규칙, 단방향 의존 등 실무 가드레일을 표준화한 접근
  • FDA가 아이디어 수준의 가이드였다면, FSD는 린팅·폴더 규칙·의존 규약까지 포함하는 구체적 방법론
• 클린/레이어드와의 비교
  • 레이어드: 기술 계층 분리를 통해 수평 구조를 만든다. FDA/FSD는 그 내부를 "기능 단위"로 수직 응집한다
  • 클린: 포트·어댑터로 경계를 만들고 의존을 코어 안쪽으로 돌린다. FDA/FSD는 FE 구현 레벨에서 폴더링·공개 인터페이스로 이를 보조한다
• FDA → FSD로 정제: 기능 응집, 병렬 개발, 탐색 용이성 목표 강화
• FE 실무 특화: 폴더 규율과 공개 인터페이스 규칙으로 현실적인 가드레일 제공
• UI 패턴과의 관계: MVVM·MVP 등은 슬라이스 내부에서 ui·model 역할을 정리하는 데 활용

---

4) 핵심 원칙

• 단방향 의존: app → pages → widgets → features → entities → shared
• 경계 공개: 내부 파일 직접 import 금지. 슬라이스 루트의 public API만 허용
• 모델 분리: api에서 DTO ↔ 도메인 변환을 끝내고, 바깥에는 도메인 모델만 노출
• 상태 배치: 로컬 UI 상태는 ui, 전역·비즈니스·서버상태는 model에 배치
• 검증 일원화: api 경계에서 스키마 기반 검증 후 내부로 신뢰 가능한 타입만 반입

---

5) 다른 아키텍처와의 비교

• 레이어드와의 관계[1]
  • 공통: 계층과 단방향 의존으로 변경 영향 최소화
  • 차이: 레이어드는 기술 계층 분리 중심. FSD는 기능(도메인) 중심 응집으로 같은 기능의 UI·상태·데이터를 묶음
  • 조합: 레이어드의 수평 계층을 기본 골격으로, 각 계층 내부는 FSD로 폴더·의존 규칙 적용
• 클린과의 관계[2]
  • 공통: 경계·계약·의존 방향 통제의 중요성
  • 차이: 클린은 포트·어댑터로 “코어 안쪽” 의존을 강제. FSD는 FE 폴더링과 public API 규율을 제공
  • 조합: API 경계에서는 클린(Port/DTO/Adapter), 내부 구현은 FSD로 응집

---

6) 장단점

장점

• 기능 응집: 같은 기능의 UI·상태·데이터가 한 폴더에 있어 변화 추적이 쉬움
• 병렬 개발: 기능 단위 브랜치와 리뷰가 수월. 충돌과 컨텍스트 스위칭 감소
• 스케일 대응: 슬라이스 추가·분할로 점진 확장. 팀 온보딩 속도 향상
• 테스트 용이: public API 기준 유닛·통합 테스트가 구조적으로 정리됨

단점

• 초기 규율 비용: 경계·경로 룰과 배럴 파일 관리 필요
• 과응집 리스크: 슬라이스를 너무 작게 쪼개면 중복과 오버헤드 증가
• 횡단 관심사: 로깅·에러 처리 규칙을 공유 레이어로 풀지 않으면 중복 가능

---

7) 빠른 참고 표

항목	권장	주의
의존 규칙	app → pages → widgets → features → entities → shared	상향 의존, 동일 레이어 타 슬라이스 내부 경로 import
공개 인터페이스	슬라이스 루트 index.ts만 외부 노출	세그먼트 파일을 직접 import
서버 상태	model 훅으로 래핑해 캐시·에러 일관화	ui에서 직접 fetch 및 에러 처리
DTO 변환	api 경계에서 완료 후 도메인 모델만 노출	DTO가 UI·도메인 전반에 누수
확장 전략	슬라이스 분할로 점진 확장	거대 슬라이스에 누적

---

8) 적용 체크리스트

• 레이어 의존 방향을 위배하지 않는가(app → … → shared)
• 슬라이스 간 참조는 모두 public API를 경유하는가
• 세그먼트 경계를 침범하는 직접 import가 없는가(ui → model 내부 파일 등)
• 서버상태 훅은 model에서 래핑되어 재사용 가능한가
• DTO ↔ 도메인 변환이 api 경계에서 일관되게 수행되는가
• 페이지는 조립에 집중하고 로직을 하위로 위임하는가

---

9) 안티패턴과 회피법

• 통로 무시: 슬라이스 내부 경로로 직접 import → public API만 허용하도록 린팅
• 상향 의존: Presentation가 Data 구현을 직접 참조 → Business 추상 또는 Port를 경유
• UI 중심 누수: ui에서 서버 접근·비즈니스 로직 수행 → model·api로 이동
• 엔티티 침식: shared에 비즈니스 규칙 유출 → entities에 모델·규칙 배치

---

10) 결론

• FSD는 “기능 응집 + 명시적 공개 인터페이스 + 단방향 의존”으로 대규모 프런트엔드를 실용적으로 정렬한다.
• 레이어드의 단순함과 클린의 기술 독립성을 조합하되, FSD의 폴더 규율을 내부 구현 표준으로 삼으면 충돌 없이 보완적으로 운용 가능하다.