Antigravity Agent
4.2 KiB
4.2 KiB
Feature-Sliced Design (FSD)
📌 Brief Summary
**Feature-Sliced Design (FSD)**는 프런트엔드 시스템 내 앱과 패키지의 코드를 체계적으로 조직화하여 조직 전체의 일관성을 보장하도록 돕는 아키텍처 방법론입니다 [1]. 명확한 책임과 의존성 규칙을 가진 계층(Layer)으로 코드베이스를 나누어, 개발자가 코드가 어디에 위치해야 하고 어떻게 임포트되어야 하는지 예측할 수 있게 합니다 [1, 2]. 결과적으로 '전역 공유 폴더'가 무분별한 스파게티 코드의 쓰레기장으로 변하는 것을 방지하고, 리팩토링의 안전성을 확보하며 새로운 팀원의 온보딩 시간을 단축합니다 [1-3].
📖 Core Content
- 명확한 계층적 구조 (Layered Structure): FSD는 코드베이스를 엄격한 책임에 따라 여러 계층으로 나눕니다. 일반적인 UI 컴포넌트나 헬퍼 함수, 디자인 토큰을 담는 가장 낮은 계층인
Shared부터 시작하여, 비즈니스 도메인을 나타내는Entities, 사용자를 위한 비즈니스 로직(예: 결제 처리)을 담은Features, 이러한 기능과 엔티티를 결합하는Widgets, 전체 화면을 구성하는Pages, 그리고 스타일 및 라우팅이 초기화되는 진입점인App으로 구성됩니다 [1]. - 의존성 방향 및 공개 API (Dependencies & Public APIs): FSD는 상위 계층이 하위 계층을 향해서만 의존성을 가지도록 방향성을 통제하며, 슬라이스(slice) 경계에서 명시적인 공개 API(Public APIs)를 노출할 것을 권장합니다 [4, 5]. 예를 들어, 앱은 패키지의 깊은 내부 파일을 직접 임포트해서는 안 되며(
index.ts등을 통해서만 접근), 기능(Features)은 의도된 공유 슬라이스가 없는 한 다른 기능을 직접 임포트하지 않아야 합니다 [4, 5]. - 도메인 주도 설계(DDD)의 구체화: 프런트엔드 환경에서 도메인 주도 설계를 실용적인 파일 시스템으로 변환하는 것은 까다롭지만, FSD는 이를 구체적인 프로젝트 구조로 맵핑해 줍니다 [6]. 핵심 도메인 개념은
entities/에, 사용자 대면 기능은features/에, 재사용 가능한 원시 요소는shared/에 배치함으로써 도메인 경계를 디렉토리 및 임포트 수준에서 시각적으로 명확하게 드러냅니다 [6]. - 모노레포 아키텍처와의 시너지: 모노레포(Monorepo) 환경에서 FSD를 적용하면 UI 키트나 API 클라이언트 등은 공유 패키지로 분리하고, 각 앱과 도메인 패키지 내부는 FSD 계층에 따라 구조화하는 "두 세계의 장점(best of both worlds)"을 취할 수 있습니다 [7]. 이는 대규모 시스템에서 우발적인 결합(accidental coupling)을 크게 줄여줍니다 [4].
🔗 Knowledge Connections
- Related Topics: Monorepo Architecture, Atomic Design, Domain-Driven Design (DDD), Public APIs
- Projects/Contexts: 대규모 확장성과 유지보수성이 요구되는 프런트엔드 모노레포 프로젝트, Turborepo 및 Nx와 같은 빌드 오케스트레이션 도구를 활용하는 대규모 조직의 React 시스템
- Contradictions/Notes: 소스에 따르면 Atomic Design은 UI 컴포넌트와 디자인 시스템을 구성하는 데는 강력한 언어지만 도메인 로직의 위치를 일관되게 지정하기 어렵게 만드는 반면, FSD는 명확한 기능(Feature) 경계와 의존성 방향을 제공하여 대규모 애플리케이션의 아키텍처적 일관성을 유지하는 데 더 적합하다고 비교됩니다 [4].
Last updated: 2026-04-26