2nd/10_Wiki/Topics/Feature-Sliced Design.md

Feature-Sliced Design

📌 Brief Summary

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

📖 Core Content

• 계층화된 아키텍처 (Layered 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].

🔗 Knowledge Connections

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

---

Last updated: 2026-04-26