Feature-Sliced Design(FSD) 완벽 가이드

요약

Feature-Sliced Design(FSD)는 복잡한 프론트엔드 애플리케이션을 위한 기능 중심의 아키텍처입니다.

• 핵심 철학: 프로젝트를 레이어(Layers), 슬라이스(Slices), **세그먼트(Segments)**의 3단계로 구조화하여 관리합니다.
• 계층 구조: App부터 Shared까지 7개의 레이어로 구분되며, 하위 레이어는 상위 레이어를 참조할 수 없는 단방향 의존성을 가집니다.
• 모듈화와 캡슐화: 각 기능은 독립적인 슬라이스로 분리되며, **공개 API(Public API)**를 통해서만 외부와 소통하여 높은 응집도와 낮은 결합도를 유지합니다.
• 장점: 명확한 비즈니스 로직 분리, 용이한 리팩토링, 그리고 높은 코드 재사용성을 제공하여 대규모 프로젝트의 유지보수를 돕습니다.

Feature-Sliced Design(FSD)는 프론트엔드 애플리케이션의 구조를 잡는 아키텍처 방법론입니다. FSD는 이름 그대로 기능 단위로 분할하는 것에 초점을 맞추고 있으며, 현재 많은 주목을 받고 있는 아키텍처 중 하나입니다.

공식 문서에 따르면 FSD는 대부분의 프로젝트에 적합하다고 합니다. 프론트엔드를 개발하고 있는 모든 환경에 적합하며, 라이브러리가 아닌 애플리케이션을 만들고 있다면 FSD는 좋은 선택이 될 수 있습니다.

하지만 현실적으로는 어느 정도 규모가 있는 프로젝트에 권장되는 방법입니다. 도메인이 작다면 굳이 FSD를 사용할 필요는 없으며, 도메인이 많고 복잡할 때 더욱 빛을 발하는 방법론입니다.

주요 특징

명시적인 비즈니스 로직

도메인 스코프 덕분에 찾고자 하는 로직을 쉽게 발견할 수 있습니다.

유연성

아키텍처 구성 요소를 새로운 요구사항에 맞춰 유연하게 교체하고 추가할 수 있습니다.

기술 부채 및 리팩토링

각 모듈을 부작용 없이 독립적으로 수정하고 재작성할 수 있습니다.

명시적인 코드 재사용

DRY(Don't Repeat Yourself) 원칙과 로컬 커스터마이징 사이의 균형을 유지합니다.

FSD의 구조

FSD 구조는 크게 레이어(Layers), 슬라이스(Slices), **세그먼트(Segments)**의 세 가지 개념으로 구성됩니다. 이 3가지 구조에 대해 자세히 알아보겠습니다.

1. 레이어(Layers)

레이어는 FSD의 가장 상위 수준 구조입니다. 총 7개로 제한되어 있으며, 모든 레이어를 사용할 필요는 없지만 네이밍 규칙은 지키는 것이 권장됩니다.

각 레이어의 역할:

• App: 앱을 실행하는 모든 것 (라우팅, 진입점, 전역 스타일, 프로바이더 등)
• Processes (deprecated): 페이지 간 복잡한 시나리오 (현재는 더 이상 사용되지 않음)
• Pages: 전체 페이지 또는 중첩 라우팅에서 페이지의 주요 부분
• Widgets: 독립적으로 작동하는 대규모 기능 또는 UI 컴포넌트 (보통 하나의 완전한 기능)
• Features: 제품 전반에 걸쳐 재사용되는 기능 구현체로, 사용자에게 실질적인 비즈니스 가치를 제공하는 동작 (예: 리뷰 작성, 제품 평가 등)
• Entities: 프로젝트가 다루는 비즈니스 엔티티 (예: 사용자, 리뷰, 댓글 등)
• Shared: 재사용 가능한 기능, 특히 프로젝트/비즈니스의 특성과 분리되어 있을 때 (예: UI Kit, Axios 설정, 유틸리티 등)

참고: App과 Shared는 다른 레이어들과 달리 슬라이스를 가지지 않고, 세그먼트로만 구성됩니다.

위 계층 구조에서 하위 레이어는 상위 레이어의 컴포넌트를 사용할 수 없습니다. 계층 구조에서 레이어의 위치가 낮을수록 더 많은 곳에서 사용될 확률이 높으며, 이러한 선형적인 흐름을 유지해야 관리가 용이합니다.

2. 슬라이스(Slices)

슬라이스는 비즈니스 도메인별로 코드를 분할하는 단위입니다. 논리적으로 관련된 모듈들을 그룹화하고 이를 유지함으로써 독립성을 높여줍니다. 슬라이스는 같은 레이어 안에서 다른 슬라이스를 참조할 수 없으며, 이 규칙은 높은 응집도와 낮은 결합도를 유지하는 데 도움이 됩니다.

슬라이스 이름은 비즈니스 영역에 따라 결정되므로 표준화되어 있지 않습니다. 용도에 따라 팀 내에서 자유롭게 네이밍할 수 있습니다.

src/
├── features/
│   ├── auth/          # 인증 슬라이스
│   ├── order-list/    # 상품 리스트 슬라이스
│   └── buy-product/   # 상품 구매 슬라이스

3. 세그먼트(Segments)

세그먼트는 슬라이스 내의 코드를 나누는 역할을 합니다. 구성은 자유롭지만, 일반적으로 권장되는 몇 가지 세그먼트들이 있습니다.

• ui: UI와 관련된 모든 것 (UI 컴포넌트, 날짜 포맷터, 스타일 등)
• api: 백엔드 상호작용 (request 함수, 데이터 타입, mapper 등)
• model: 데이터 모델 (스키마, 인터페이스, 스토어, 비즈니스 로직)
• lib: 슬라이스 내 다른 모듈이 필요로 하는 라이브러리 코드
• config: 설정 파일과 기능
• const: 필요한 상수

공개 API (Public API)

각 슬라이스와 세그먼트는 외부에 노출할 수 있는 인터페이스인 공개 API를 가집니다. 보통 index.js 또는 index.ts로 정의하며, 이 파일을 통해 필요한 기능만 외부로 추출하여 독립성을 높일 수 있습니다.

공개 API 규칙:

• 애플리케이션의 슬라이스와 세그먼트는 오직 공개 API 인덱스 파일(index.ts)에 정의된 기능과 컴포넌트만 사용해야 합니다.
• 정의되지 않은 것들은 격리된 것으로 간주하여 슬라이스 혹은 세그먼트 내부에서만 접근할 수 있습니다.

// index.ts 예시
export { Button } from './Button';
export { Modal } from './Modal';
export { Input } from './Input';

마치며

FSD는 처음에는 복잡해 보일 수 있지만, 프로젝트 규모가 커질수록 유지보수성과 확장성 면에서 큰 이점을 제공합니다. 특히 팀 단위 개발에서 명확한 구조와 규칙을 제공하여 협업 효율을 높일 수 있는 강력한 아키텍처입니다.