---
category: Unified
tags: [auto-consolidated, technical-documentation]
title: [[Feature-Sliced Design|Feature-Sliced Design]]
last_updated: 2026-05-02
---

# [[Feature-Sliced Design|Feature-Sliced Design]]

## 📌 Brief Summary
Feature-Sliced Design(FSD)은 조직 전반의 일관성을 보장하기 위해 애플리케이션 및 패키지 내의 코드를 구성하는 커뮤니티 주도의 프론트엔드 아키텍처 방법론입니다 [1, 2]. 이 방법론은 명확한 책임과 의존성 방향을 가진 여러 계층(layer)으로 코드베이스를 나누어, 예측 가능한 슬라이스(slice) 경계와 명시적인 공개 API(Public API)를 제공합니다 [1-3]. 이를 통해 '글로벌 공유 폴더(global shared folder)'가 무분별한 코드의 쓰레기장으로 변하는 것을 방지하고, 유지보수가 용이한 확장 가능한 프론트엔드 시스템을 구축할 수 있습니다 [4, 5].

---

피처 슬라이스 디자인(Feature-Sliced Design, FSD)은 전반적인 프론트엔드 아키텍처를 체계적으로 다루고 구성하기 위한 구조적 방법론입니다 [1]. 이 방법론은 애플리케이션을 여러 계층(layers)으로 분류하고, 엄격한 의존성 규칙과 명확한 모듈 경계를 정의하는 것이 특징입니다 [1]. 주로 BEM과 같은 CSS 방법론과 결합하여 사용되며, FSD는 프로젝트 전체의 구조를 관리하고 BEM은 스타일 구조를 관리함으로써 대규모 프로젝트의 기술 부채를 크게 줄여줍니다 [2, 3].

## 📖 Core Content
* **계층화된 아키텍처 (Layered [[Architecture|Architecture]]):** FSD는 명확한 책임을 가진 여러 계층으로 코드를 분리합니다 [1].
  * *Shared:* 가장 하위 계층으로 일반적인 UI 컴포넌트(원자), 헬퍼 함수, 디자인 토큰을 포함하며, 다른 어떤 계층에서도 가져올(import) 수 없습니다 [1, 6].
  * *Entities:* 핵심 비즈니스 도메인(예: 사용자, 제품, 주문)을 나타내며 데이터 구조와 도메인별 로직 및 UI/상태 표현을 포함합니다 [1, 6].
  * *Features:* 사용자에게 가치를 제공하는 비즈니스 로직(예: 장바구니 추가, 결제 진행)을 포함합니다 [1, 6].
  * *Widgets:* 기능(features)과 엔티티(entities)를 결합한 상위 수준의 UI 블록(예: 제품 카드, 네비게이션 헤더)입니다 [1].
  * *Pages:* 위젯과 기능을 기반으로 구축된 전체 페이지 구성입니다 [1].
  * *App:* 글로벌 프로바이더, 스타일, 라우팅이 초기화되는 최상위 진입점입니다 [1].

* **엄격한 의존성 방향 및 경계 규칙:** 우발적인 결합(coupling)을 줄이기 위해 강력한 제약 조건을 강제합니다 [3].
  * 앱(App)은 패키지의 깊은 내부 파일이 아닌 오직 공개 API에서만 임포트해야 합니다 [3, 7].
  * 의도적으로 공유된 슬라이스가 없는 한, 특정 기능(Feature)은 다른 기능(Feature)을 직접 가져올(import) 수 없습니다 [7].
  * Shared 패키지는 비즈니스 흐름을 포함하지 않고 오직 재사용 가능한 기본 요소로만 작게 유지되어야 합니다 [7].

* **도메인 주도 설계(DDD)와의 조화:** 기존 DDD의 추상적인 개념을 실용적인 파일 시스템 구조로 구체화하여, 임포트(import) 경로와 디렉토리 구조만으로도 도메인 경계를 명확히 식별할 수 있게 돕습니다 [6].

---

- **프론트엔드 아키텍처의 전반적 관리**: BEM이 CSS 구조와 클래스 명명 규칙에 초점을 맞추는 반면, 피처 슬라이스 디자인(FSD)은 프론트엔드 아키텍처의 전반적인 청사진을 다루는 방법론입니다 [1]. 
- **계층과 규칙의 분리**: FSD는 애플리케이션을 여러 계층(Layers)을 사용하여 조직화합니다 [1]. 각 계층에는 명확한 모듈 경계가 설정되며, 계층 간의 상호작용을 제어하는 엄격한 의존성 규칙(dependency rules)이 정의됩니다 [1].
- **BEM과의 강력한 시너지**: FSD 아키텍처 내부에서 컴포넌트의 스타일 구조를 잡기 위해 BEM을 통합하여 사용할 수 있습니다 [1]. FSD가 전체적인 '프로젝트 수준의 구조(project-level structure)'를 제공하고, BEM이 CSS가 모듈화되고 이해하기 쉽도록 보장함으로써 매우 강력한 프론트엔드 아키텍처를 형성합니다 [2, 3].
- **기술 부채(Technical Debt) 감소 및 확장성**: 명확한 역할 분담을 통해 확장 가능하고(scalable) 유지보수하기 좋은(maintainable) 프론트엔드 프로젝트를 구축할 수 있으며, 이 구조적 접근은 장기적으로 기술 부채를 현저히 감소시킵니다 [2-4].

## ⚖️ Trade-offs & Caveats
No trade-offs available.

## 🔗 Knowledge Connections
- **Related Topics:** [[Monorepo Architecture|Monorepo Architecture]], Atomic Design, Domain-Driven Design (DDD), [[Component Library Architecture|Component Library Architecture]], Public API
- **Projects/Contexts:** 대규모 프론트엔드 애플리케이션 및 디자인 시스템 구축, [[Turborepo|Turborepo]] 또는 Nx를 활용한 확장 가능한 프론트엔드 모노레포 관리 환경 [5, 8, 9].
- **Contradictions/Notes:** 소스에 따르면 FSD는 [[Atomic Design|Atomic Design]]과 경쟁하기보다는 상호 보완적으로 사용될 수 있습니다. UI 라이브러리에는 [[Atomic Design|Atomic Design]]을 사용하여 "원자(Atoms)"를 순수하게 유지하고, 애플리케이션의 비즈니스 로직은 FSD의 Feature 기반 구조를 따르도록 결합하는 방식이 성공적인 아키텍처 패턴으로 제시됩니다 [10].

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

---

- **Related Topics:** [[BEM (Block Element Modifier)|BEM (Block Element Modifier]], CSS Architecture, Frontend [[Architecture|Architecture]]
- **Projects/Contexts:** 대규모 프론트엔드 개발 ([[Large Frontend Projects|Large Frontend Projects]]), 유지보수 가능한 프론트엔드 구축 (Maintainable Frontend Architecture)
- **Contradictions/Notes:** 소스에 관련 정보가 부족하여 피처 슬라이스 디자인 자체의 내부 계층 구조(어떤 계층들이 존재하는지 등)에 대한 구체적이고 깊이 있는 설명은 포함할 수 없습니다.

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