Antigravity Agent
4.3 KiB
Feature-Sliced Design
📌 Brief Summary
Feature-Sliced Design(FSD)은 프론트엔드 애플리케이션(특히 React)을 위해 특별히 고안된 최신 아키텍처 방법론입니다 [1, 2]. 코드를 기술적인 파일 유형이 아닌 비즈니스 로직, 사용자의 여정, 책임(Scope and responsibility)을 기준으로 구성하여 프로젝트의 유지보수성과 확장성을 높이는 것을 목표로 합니다 [2, 3]. 컴포넌트 기반 개발, 도메인 주도 설계(DDD), 모듈형 시스템 아키텍처의 원칙을 결합하여 명확하고 강제할 수 있는 폴더 및 코드 구조를 제공합니다 [1, 4].
📖 Core Content
-
핵심 계층 구조 (Layers, Slices, Segments): FSD는 프로젝트를 레이어(Layer), 슬라이스(Slice), 세그먼트(Segment) 개념으로 분할합니다 [5]. 가장 최상위 개념인 레이어는 다음과 같이 엄격하게 지정된 폴더 구조를 가집니다.
app: 애플리케이션 초기화 및 전역 설정 [3, 6]pages: 라우트 수준의 화면 조합 [3, 6]widgets: 기능(Feature)과 엔티티(Entity)를 조합한 재사용 가능한 대형 UI 블록 [3, 6]features: 사용자의 상호작용 시나리오 및 비즈니스 워크플로우 [3, 6]entities: 핵심 비즈니스 데이터 모델 [3, 6]shared: 도메인에 종속되지 않은 재사용 가능한 유틸리티 및 UI 컴포넌트 [3, 6]
-
단방향 의존성 규칙 (Unidirectional Dependencies): FSD의 가장 중요한 규칙으로, 코드는 오직 동일한 레이어 또는 자신보다 하위 레이어의 코드만 가져올(import) 수 있습니다 [3, 7]. 상위 레이어가 하위 레이어에 의존하는 것은 허용되지만, 하위 레이어는 절대 상위 레이어에 의존할 수 없습니다 [3]. 이를 통해 숨겨진 순환 참조를 제거하고 아키텍처의 규율을 강제할 수 있습니다 [7, 8].
-
공개 API 규칙 (Public API Rule): 각 슬라이스는 주로
index.ts를 통해 단일 진입점을 가져야 합니다 [9-11]. 외부 모듈은 오직 이 진입점에서 명시적으로 export된 요소에만 접근해야 하며, 내부 파일에 직접 접근할 수 없습니다 [9, 10]. 이는 캡슐화를 강화하고 명확한 인터페이스 계약을 생성하여 리팩토링 시 사이드 이펙트를 최소화합니다 [9, 11]. -
도입 이점 및 실무 적용: 대규모 프로젝트가 성장함에 따라 기능 간의 의존성이 얽히는(Tangled dependencies) 문제를 해결해 줍니다 [12]. 코드를 독립적으로 수정 및 테스트할 수 있게 해 주며 [13], 공유 상태를 줄이고 렌더링 경계를 좁혀 성능 최적화에도 자연스럽게 기여합니다 [14]. ESLint 규칙 등을 통해 아키텍처 경계를 자동화하여 관리하는 것이 권장됩니다 [15, 16].
-
한계 및 주의사항: 가장 큰 과제는 특정 기능이 정확히 어떤 "Feature" 경계에 속하는지 파악하는 것입니다 [17]. 인증(Auth)과 같은 교차 관심사는 한 번에 거대한 슬라이스로 만들기보다 '로그인', '가입', '비밀번호 재설정' 등 구체적이고 작은 기능 단위로 나누는 것이 좋습니다 [17-19]. 또한, 팀원 전체가 이 방법론을 완전히 이해하지 않으면 모듈 분류에 대한 의미론적 논쟁(Semantic overhead)이 길어지거나, 모든 코드가
shared레이어로 쏟아지는 문제가 발생할 수 있습니다 [16].
🔗 Knowledge Connections
- Related Topics: Frontend Folder Structure, Domain-Driven Design, Component-Based Architecture
- Projects/Contexts: 대규모 React 애플리케이션 및 엔터프라이즈 시스템 확장성 관리
- Contradictions/Notes: 소스 [1, 2]는 FSD가 대규모 프론트엔드 시스템에서 직관적이고 훌륭한 구조적 대안이라고 강조합니다. 반면, 소스 [16, 17]의 실제 개발자 논의에서는 특정 모듈이 기능(Feature)인지 위젯(Widget)인지 결정하는 과정이 종종 불필요한 의미론적 오버헤드를 유발하며, 팀의 학습 곡선이 높고 크로스 커팅 문제(Cross-cutting concerns)를 깔끔하게 분리하기 어렵다는 현실적인 비판을 제시합니다.
Last updated: 2026-04-26