프론트엔드 개발자는 개발 과정에서 애플리케이션의 구조적 문제에 종종 직면합니다. 프로젝트가 커질수록 코드베이스는 점점 복잡해지고, 기능 확장은 물론 유지보수조차 어려워지는 상황이 발생합니다.
이 문제를 해결하기 위해서는 확장성, 모듈 간의 느슨한 결합, 그리고 높은 응집력을 제공할 수 있는 아키텍처가 필요합니다.
최근 많은 개발자들이 이러한 문제를 해결하기 위해 선택하는 아키텍처가 바로 Feature Sliced Design(FSD)입니다. 이번 글에서는 FSD란 무엇이고, 왜 주목받고 있는지 함께 알아보겠습니다.
FSD의 주요 요소
프론트엔드 아키텍처인 Feature Sliced Design(FSD)는 프로젝트의 확장성과 유지보수를 용이하게 만들기 위해 레이어(Layers), 슬라이스(Slices), 그리고 세그먼트(Segments)라는 개념을 사용합니다. 각 요소가 어떤 역할을 하는지 알아보겠습니다.
출처: dev.to
Layer
레이어는 최상위 레벨 디렉토리이자 분해의 첫 번째 단계로, 코드의 목적과 역할을 기반으로 프로젝트를 분리합니다.
출처: dev.to
- 레이어의 수는 최대 7개로 제한되어 있어 복잡도를 줄이고, 각 레이어의 역할이 명확해집니다.
- 핵심 개념은 책임 분리이며, 이를 통해 유지보수성과 확장성이 높은 아키텍처를 구현할 수 있습니다.
app: 애플리케이션 설정 및 루트 레이아웃을 관리
processes: 여러 페이지에서 사용되는 비즈니스 프로세스나 유저 흐름을 정의
pages: 페이지 단위의 컴포넌트
widgets: 페이지나 여러 feature를 조합한 UI 블럭
features: 프로젝트의 기능 단위로 구성
entities: 도메인 모델과 상태 관리를 담당
shared: 재사용 가능한 컴포넌트와 유틸리티
Layer 구조의 장점
- 책임 분리: 코드가 각자의 역할에 맞게 분리되어 가독성과 유지보수성이 향상됩니다.
- 확장성: 새로운 기능이나 페이지를 추가할 때 다른 레이어에 영향을 주지 않으므로 확장이 용이합니다.
- 유지보수: 특정 기능이나 프로세스의 위치가 명확해, 수정 및 관리가 쉬워집니다.
Slice
슬라이스는 각 레이어 안에서 기능(feature) 또는 도메인(domain) 단위로 코드를 그룹화하는 서브 디렉토리입니다. 슬라이스를 사용하면 관련된 코드들이
출처: dev.to
- 슬라이스를 사용하면 코드의 관련된 부분들이 한곳에 모여 있어 재사용성과 유지보수성이 향상됩니다.
- 기능 단위의 코드 구조를 유지하므로 새로운 기능을 추가하거나 기존 기능을 수정할 때도 프로젝트 전체에 영향을 미치지 않습니다.
- 슬라이스의 이름은 정해진 것이 없습니다.
Slice 구조의 장점
- 명확한 경로: 각 슬라이스는 특정 기능이나 도메인에 대한 모든 코드를 포함합니다.
- 독립성: 각 슬라이스는 다른 슬라이스와 독립적으로 동작하므로 수정이 용이합니다
- 확장성: 기능이 추가될 때 새로운 슬라이스를 생성하면 됩니다. 기존 구조에 영향을 주지 않습니다.
Segment
세그먼트는 슬라이스 내부의 코드를 목적에 따라 나우어 관리하는 단위입니다. 세그먼트를 사용하면 슬라이스 내의 코드 구조가 명확해지고, 유지보수성과 재사용성이 더욱 향상됩니다.
api: 필수적인 서버 요청
ui: 슬라이스의 UI 컴포넌트
model: 비즈니스 로직
lib: 슬라이스 안에서 사용되는 헬퍼 기능
config: 슬라이스에서 요구되는 필수적인 설정
consts: 상수
Public API
각 슬라이스와 세그먼트에는 공개 API(Publice API)가 있습니다. 이를 통해 슬라이스 또는 세그먼트에서 외부로 노출할 기능만 선택적으로 추출하고, 불필요한 내부 구현은 격리할 수 있습니다.
대부분 index.js 또는 index.ts 파일을 사용합니다.
features/
└── cart/
├── api/
├── ui/
├── model/
├── lib/
├── config/
├── consts/
└── index.js// features/cart/index.js
export { fetchCartItems } from './api';
export { CartItem } from './ui/CartItem';
export { $cart } from './model';
export { calculateTotal } from './lib/calculateTotal';
export { CART_API_URL } from './config';
export { CART_EMPTY_MESSAGE } from './consts';이제 외부에서 cart 슬라이스를 사용할 때 다음과 같이 명확하게 가져올 수 있습니다.
import { fetchCartItems, CartItem, calculateTotal } from 'features/cart';FSD를 도입할 때의 고려사항
❓ 언제 FSD를 도입해야 할까요?
❗️ 프로젝트 초기부터 도입하면 좋지만, 기능이 복잡해지고 구조가 무너지는 시점에 도입해도 좋습니다.
❓ 팀 협업에서의 장점이 있나요?
❗️ 팀원들이 특정 슬라이스에만 집중해 작업할 수 있어 병렬 개발이 수월해집니다.
❓ 기존 프로젝트에 적용할 수 있나요?
❗️ 특정 레이서부터 FSD로 전환하면 기존 프로젝트를 점진적으로 마이그레이션할 수 있습니다.
FSD의 장단점
| 장점 | 단점 |
|---|---|
| 유지보수성과 확장성이 뛰어남 | 초기 설정이 다소 복잡할 수 있음 |
| 관심사 분리가 명확함 | 소규모 프로젝트에는 과함 |
| 재사용성과 독립성이 높음 | 팀원이 아키텍처를 이해해야함 |
FSD와 다른 아키텍처 비교
| Atomic Design | MVC | FSD |
|---|---|---|
| UI 컴포넌트의 계층 구조에 초점을 맞춤 | 고전적인 구조 | 기능과 도메인에 집중 |
| 기능 단위 구조 부족 | 대규모 프로젝트에선 확장성이 부족 | 대규모 프로젝트에 적합 |
✅ 참고
