# [[Feature-Sliced Design (FSD)]]

## 📌 Brief Summary
Feature-Sliced Design (FSD)은 프론트엔드 애플리케이션, 특히 대규모 React 프로젝트를 구축하기 위해 고안된 현대적인 아키텍처 방법론으로, 코드를 기술적인 역할이 아닌 범위(scope)와 비즈니스 책임(responsibility)에 따라 구성합니다 [1-3]. 이 방법론은 컴포넌트 기반 개발과 도메인 주도 설계(DDD)의 원칙을 결합하여 명확한 경계를 설정합니다 [1]. 또한 애플리케이션을 여러 계층(Layer)과 슬라이스(Slice)로 나누고 단방향 의존성 규칙과 공개 API(Public API) 규칙을 강제함으로써 결합도를 낮추고 유지보수성과 확장성을 크게 높이는 것을 목표로 합니다 [2, 4-6].

## 📖 Core Content
* **구조적 모델 (Layers, Slices, Segments):** FSD는 애플리케이션을 `app`(전역 설정 및 초기화), `pages`(라우팅 수준 컴포넌트), `widgets`(기능과 엔티티로 구성된 재사용 가능한 UI 블록), `features`(사용자 상호작용 및 비즈니스 워크플로우), `entities`(핵심 비즈니스 모델), `shared`(도메인에 구애받지 않는 재사용 가능한 유틸리티)와 같은 구체적 계층(Layers)으로 분류합니다 [2, 7, 8]. 각 계층 내에서는 특정 기능을 위한 개념적 경계인 '슬라이스(Slice)'와 논리, 컴포넌트 등을 더 세분화하는 '세그먼트(Segment)'로 나뉘어 구성됩니다 [6, 8].
* **단방향 의존성 규칙 (Unidirectional Dependencies):** 상위 계층의 코드는 하위 계층에 의존하고 가져올 수 있지만, 하위 계층은 상위 계층에 의존할 수 없습니다 [2, 4]. 이 단일 제약 조건은 모듈 간의 순환 참조를 방지하고 아키텍처 내 규율을 강제하여 시스템 변경 시 파급 효과를 차단합니다 [4, 9]. ESLint와 같은 린팅(Linting) 도구를 통해 한 기능(Feature)이 다른 기능을 참조하는 것을 제한하는 방식으로 자동화할 수 있습니다 [10, 11].
* **공개 API 및 캡슐화 (Public APIs and Encapsulation):** 각 슬라이스는 단일 진입점(주로 `index.ts`)을 노출하여 외부와 통신해야 합니다 [5, 12, 13]. 외부의 다른 모듈은 이 진입점을 통해서만 해당 코드를 가져올 수 있습니다. 이로 인해 내부 파일(특정 UI 요소 등)이 철저하게 캡슐화되며, 외부 의존성을 깨뜨리지 않고 모듈 내부를 안전하게 리팩토링할 수 있습니다 [12, 13].
* **상태 관리의 위치 지정:** FSD는 특정 상태 관리 라이브러리(Context, Redux, Zustand 등)에 의존하지 않습니다 [14]. 대신 상태가 아키텍처적으로 어디에 위치해야 하는지만 정의합니다. 예를 들어 엔티티의 상태는 엔티티(entities) 계층에, 기능별 상호작용 상태는 기능(features) 계층에, 인프라의 전역 상태는 앱(app) 계층에 배치하여 상태 소유권을 명확히 합니다 [14].
* **도입 시 학습 곡선과 고려사항:** 파일이나 컴포넌트 유형 위주로 개발하던 개발자가 '비즈니스 기능' 위주의 FSD 패러다임으로 전환할 때는 학습 곡선이 존재합니다 [15]. 특히 특정 컴포넌트가 '기능(Feature)'인지 '위젯(Widget)'인지 결정하는 등 경계를 찾는 의미론적 논의에서 오버헤드가 발생할 수 있습니다 [11]. 

## 🔗 Knowledge Connections
- **Related Topics:** [[Frontend Folder Structure]], [[Clean Code Principles]], [[Domain-Driven Design (DDD)]], [[Component-Based Architecture]], [[State Management in React]], [[React Refactoring]]
- **Projects/Contexts:** [[Scalable React Apps]], [[Enterprise-level Frontend Systems]], [[Monorepo Environments]]
- **Contradictions/Notes:** FSD는 명확한 기능 분리를 강조하지만, 실제 개발자들은 '인증(Auth)'과 같은 교차 관심사(Cross-cutting concerns)가 발생할 때 경계를 찾는 것이 가장 어렵다고 지적합니다. 인증을 단일 기능으로 볼 것인지, 아니면 로그인, 회원가입, 비밀번호 찾기 등 여러 기능의 집합으로 쪼개야 하는지에 대한 설계상 딜레마가 생길 수 있습니다 [16-18]. 더불어 팀원들이 이 아키텍처를 완벽히 숙지하지 않으면, 오히려 모호한 모든 코드를 `/shared` 폴더에 몰아넣어 거대한 의존성 문제를 일으킬 위험이 있다는 실무자들의 경고도 있습니다 [11, 18].

---
*Last updated: 2026-04-26*