Antigravity Agent
4.4 KiB
4.4 KiB
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