이 글은 FSD 디자인패턴 공식문서 + 블로그 글 번역본을 참고하여 설명을 합친 글입니다.(https://emewjin.github.io/feature-sliced-design/ + https://feature-sliced.design/kr)
Feature-Sliced Design
Feature-Sliced Design(FSD)은 특히 React 생태계에서 확장 가능한 프론트엔드 애플리케이션을 구축하기 위해 설계된 최신 아키텍처 방법론입니다. 핵심 원칙은 기술적 레이어보다는 애플리케이션의 기능(Feature)을 중심으로 프로젝트 구조를 조직하는 것입니다.
기존 패러다임에서는 개발자들이 종종 컴포넌트, 서비스, 스타일과 같은 기술적 관심사별로 코드를 그룹화하곤 했습니다. 하지만 이런 방식은 파일이 거대해지고 의존성이 복잡해지는 문제를 초래합니다. Feature-Sliced Design은 이러한 문제를 해결하고자 기능 중심의 구조를 강조합니다. 이 접근법은 보다 직관적이고 깔끔한 구조를 제공하며, 협업과 유지보수를 용이하게 합니다.
EEAT(전문성, 경험, 권위, 신뢰성) 관점에서 보면, Feature-Sliced Design은 React 커뮤니티에서 널리 인정받는 모범 사례를 강조함으로써 코드베이스의 신뢰성과 견고성을 높입니다. 기능 중심의 사고방식을 적용하면 각 기능 단위가 일관성을 유지하며 확장이 쉬워집니다.
역사와 기원
Feature-Sliced Design의 뿌리는 대규모 프론트엔드 프로젝트에서 복잡성을 효과적으로 관리하는 방법에 대한 커뮤니티 논의에서 시작되었습니다. 개발자들은 전통적인 파일 그룹화 방식(예: components, containers, services)이 확장성 면에서 한계를 갖는다는 것을 깨달았습니다.
시간이 지나면서 오픈소스 기여자와 업계 리더들의 협력적 의견을 통해, 보다 직관적이고 비즈니스 중심적인 접근 방식이 필요하다는 인식이 생겼습니다. FSD는 도메인 주도 설계(Domain-Driven Design)나 모듈러 아키텍처와 유사한 개념을 공유하지만, React의 컴포넌트 중심 특성에 맞춰 복잡성을 분리하고 경계를 명확히 정의하도록 설계되었습니다.
Feature-Sliced Design의 핵심 요소
FSD의 핵심은 레이어(Layer), 슬라이스(Slice), 세그먼트(Segment)입니다.
- 레이어(Layer): 사용자의 여정과 비즈니스 로직을 기준으로 애플리케이션을 그룹화
- 슬라이스(Slice): 주요 기능을 더 작은 도메인으로 분리
- 세그먼트(Segment): 슬라이스 내에서 하위 작업이나 하위 컴포넌트를 논리적으로 구분
이러한 요소를 사용하면 프로젝트 구조가 보다 직관적이고, 테스트가 용이하며, 새로운 팀원이 빠르게 이해할 수 있는 코드베이스를 만들 수 있습니다.
대규모 React 프로젝트에서의 장점
FSD를 채택하면 자연스럽게 프로젝트 확장에 용이합니다. 대규모 React 애플리케이션은 기능이 늘어남에 따라 얽히고설킨 의존성 문제를 겪기 쉽습니다. FSD는 기능 중심으로 코드를 나누어 버그를 격리하고, 새로운 기능을 추가하며, 기존 코드를 리팩터링하기 쉽게 만듭니다.
팀 차원에서는 각자 다른 슬라이스에서 병렬로 작업할 수 있어, 기능 개발 속도가 빨라지고 지식 공유도 원활해집니다.
FSD 적용 시점
FSD는 다양한 규모의 프로젝트에 적용할 수 있지만, 특히 애플리케이션이 몇 페이지 또는 몇 컴포넌트 이상으로 확장될 때 가장 효과적입니다.
프로젝트가 빠르게 성장하거나 여러 팀이 협업할 경우 FSD 적용이 권장됩니다.
작은 프로젝트라도 일부 원칙을 도입하면 코드가 깔끔하고 미래에도 유지보수하기 쉬운 구조를 확보할 수 있습니다.
기존 아키텍처(MVC, MVP)와 비교
MVC(Model-View-Controller)나 MVP(Model-View-Presenter) 같은 전통적인 프레임워크에서는 기능을 책임 레이어별로 분리합니다. 이러한 방식은 소프트웨어 개발의 기본이 되었지만, React와 같은 컴포넌트 기반 라이브러리에는 완전히 맞지 않을 수 있습니다.
FSD는 기능과 사용자 흐름 중심으로 코드베이스를 정렬함으로써 재사용 가능한 컴포넌트와 복잡한 상태 관리에서 더 직관적인 구조를 제공합니다.
즉, MVC나 MVP는 때때로 프론트엔드 개발자가 백엔드 중심 아키텍처에 코드를 맞추도록 강요하지만, FSD는 React의 모듈러 특성을 최대한 활용합니다.
Atomic Design과의 차이
Atomic Design: UI 요소를 최소 단위(Atom)에서 시작해 분자(Molecule), 유기체(Organism), 템플릿, 페이지로 구성
Feature-Sliced Design: 모듈화는 하지만 비즈니스 로직과 사용자 기능 중심
Atomic Design은 UI 재사용성과 일관성에 초점을 맞추고, FSD는 기능 간 관계와 전체 애플리케이션 흐름에 집중합니다. 두 접근법은 프로젝트 내에서 공존 가능하지만, 초점이 서로 다릅니다.
주요 용어와 구조(Layer, Slice, Segment)
-
레이어(Layer): 관련 부분을 그룹화하는 아키텍처 계층 (예: app, process, page, widgets, feature, entity, shared)
레이어들은 코드베이스를 조직화하고, 모듈화되고 유지보수 용이한 확장 가능한 아키텍처를 촉진하는 데 도움이 됩니다.
아래 구조에서 features 레이어가 entities 레이어보다 더 위에 있기 때문에 entities 레이어는 features 레이어의 기능을 사용할 수 없습니다.
마찬가지로 features 레이어는 widgets 레이어나 processes 레이어의 컴포넌트를 사용할 수 없으며, 위 레이어는 아래 레이어만 활용할 수 있습니다. 이는 한 방향으로만 향하는 선형적인 흐름을 유지하기 위함입니다.
계층 구조에서 레이어의 위치가 낮을수록 코드의 더 많은 곳에서 사용될 가능성이 높기 때문에, 레이어를 변경하는 것이 더 위험합니다. 예를 들어 shared 레이어의 UI 키트는 features, widgets, 심지어 pages 레이어에서도 사용됩니다.- app: 애플리케이션 로직이 초기화되는 곳입니다. 프로바이더, 라우터, 전역 스타일, 전역 타입 선언 등이 여기에서 정의됩니다. 애플리케이션의 진입점 역할을 합니다.
- processes: 이 레이어는 여러 단계로 이루어진 등록과 같이 여러 페이지에 걸쳐 있는 프로세스를 처리합니다. 이 레이어는 더 이상 사용되지 않는 것으로 간주되지만 여전히 가끔씩 마주할 수 있습니다. 선택적 레이어입니다.
- pages: 이 레이어에는 애플리케이션의 페이지가 포함됩니다.
- widgets: 페이지에 사용되는 독립적인 UI 컴포넌트입니다.
- features: 이 레이어는 비즈니스 가치를 전달하는 사용자 시나리오와 기능을 다룹니다. 예를 들어 좋아요, 리뷰 작성, 제품 평가 등이 있습니다. 선택적 레이어입니다.
- entities: 이 레이어는 비즈니스 엔티티를 나타냅니다. 이러한 엔티티에는 사용자, 리뷰, 댓글 등이 포함될 수 있습니다. 선택적 레이어입니다.
- shared: 이 레이어에는 특정 비즈니스 로직에 종속되지 않은 재사용 가능한 컴포넌트와 유틸리티가 포함되어 있습니다. 여기에는 UI 키트, axios 설정, 애플리케이션 설정, 비즈니스 로직에 묶이지 않은 헬퍼 등이 포함됩니다.
-
슬라이스(Slice): 기능 단위의 경계, 독립적 모듈
각 레이어에는 애플리케이션 분해의 두 번째 수준인 슬라이스라는 하위 디렉토리가 있습니다. 슬라이스에서 연결은 추상적인 것이 아니라 특정 비즈니스 엔티티에 대한 것입니다. 슬라이스의 주요 목표는 코드를 값별로 그룹화하는 것입니다.
슬라이스 이름은 프로젝트의 비즈니스 영역에 따라 직접 결정되므로 표준화되어 있지 않습니다. 예를 들어 사진 갤러리에는 사진, 앨범, 갤러리와 같은 섹션이 있을 수 있습니다. 소셜 네트워크에는 게시물, 사용자, 뉴스피드와 같은 슬라이스가 필요할 수 있습니다.
밀접하게 관련된 조각들은 구조적으로 디렉토리 내에 그룹지을 수 있지만 다른 슬라이스와 동일한 격리 규칙을 준수해야 하며, 이 디렉토리에 있는 코드는 직접적으로 공유되지 않아야 합니다.
- 세그먼트(Segment): 슬라이스 내 세부 구분, 컴포넌트·로직·유틸리티 등
각 슬라이스는 세그먼트로 구성됩니다. 세그먼트는 목적에 따라 슬라이스 내의 코드를 나누는 데 도움이 됩니다. 팀의 합의에 따라 세그먼트의 구성과 이름이 변경될 수 있습니다. 일반적으로 사용되는 세그먼트들은 다음과 같습니다.
api - 필요한 서버 요청.
UI - 슬라이스의 UI 컴포넌트.
model - 비즈니스 로직, 즉 상태와의 상호 작용. actions 및 selectors가 이에 해당
lib - 슬라이스 내에서 사용되는 보조 기능.
config - 슬라이스에 필요한 구성값이지만 구성 세그먼트는 거의 필요하지 않음.
consts - 필요한 상수.
이 용어들은 프로젝트를 이해하고 탐색하는 데 도움이 되는 정신적 모델을 제공합니다.
공개 API
각 슬라이스와 세그먼트에는 공개 API가 있습니다. 공개 API는 index.js 또는 index.ts 파일이며, 이 파일을 통해 슬라이스 또는 세그먼트에서 필요한 기능만 외부로 추출하고 불필요한 기능은 격리할 수 있습니다. 인덱스 파일은 진입점 역할을 합니다.
공개 API에 대한 규칙은 다음과 같습니다.
- 애플리케이션 슬라이스와 세그먼트는 공개 API 인덱스 파일에 정의된 슬라이스의 기능과 컴포넌트만 사용합니다.
- 공개 API에 정의되지 않은 슬라이스 또는 세그먼트의 내부 부분은 격리된 것으로 간주되며 슬라이스 또는 세그먼트 내부에서만 접근할 수 있습니다.
- 공개 API는 import 및 export로 단순하게 작동하므로 애플리케이션을 변경할 때 코드의 모든 곳에서 import를 변경할 필요가 없습니다.
초기 어려움과 학습 곡선
기존의 파일 중심 또는 컴포넌트 중심 구조에 익숙한 개발자는 FSD 도입 시 초기 어려움을 겪을 수 있습니다.
- 주요 난관: 기능 중심 사고 방식으로 전환
- 디렉토리 레이아웃 구성: 애플리케이션 기능을 어떻게 슬라이스할지 결정
하지만 초기 학습을 마치면, FSD는 더 유지보수하기 쉽고 직관적인 워크플로우를 제공합니다.
사례: 간단한 To-Do 앱 구축
작은 투두 앱을 예로 들어보겠습니다. 기능:
- 작업 추가
- 작업 완료 표시
- 완료/진행 중 필터링
FSD 적용 시:
- 각 기능(작업 추가, 완료, 필터링)이 슬라이스로 구분
- 슬라이스 내부에 해당 기능 전용 컴포넌트, 로직, 스타일 존재
- 레이어는 애플리케이션 레벨 문제(인증, 라우팅)와 공유 유틸리티/UI를 분리
이 구조 덕분에 새로운 개발자가 프로젝트에 합류해도 각 기능이 어디에 위치하고 다른 기능과 어떻게 연결되는지 쉽게 이해할 수 있습니다.
결론
Feature-Sliced Design은 React 프로젝트 구조를 기능 중심으로 조직함으로써 명확성, 확장성, 유지보수 용이성을 제공합니다.
- 규모 사이드 프로젝트부터 대규모 엔터프라이즈 플랫폼까지 적용 가능
- 기능 중심 설계로 협업과 개발 효율성 향상
- 미래에도 견고한 코드베이스 구축이 가능
