Feature-Sliced Design: 본질 및 기능 기반 분할 방법론

Feature-Sliced Design이란?

Feature-Sliced Design (FSD)는 2021년 feature-sliced.design 커뮤니티에서 처음 제안한 프론트엔드 애플리케이션 아키텍처 방법론입니다. FSD의 핵심 아이디어는 코드를 비즈니스 기능(슬라이스)별로 그룹화하는 것이며, 각 슬라이스는 자체 비즈니스 로직, 사용자 인터페이스, API 상호작용, 데이터 모델 및 테스트를 포함하는 자급자족 단위입니다. 이는 코드가 기술적 기준(controller, service, repository)으로 분할되는 기존의 계층형 아키텍처와 FSD를 구별합니다.

이 방법론은 Domain-Driven Design(DDD) 및 Bounded Context의 개념을 차용합니다. 애플리케이션의 각 기능은 명확한 경계를 가진 별도의 bounded context입니다. 슬라이스의 공개 API만 사용하는 경우 한 기능 내의 변경 사항이 다른 기능을 손상시켜서는 안 됩니다. State of Frontend 2024 설문조사에 따르면 FSD는 React 아키텍처 중 인기도에서 2위(23%)를 차지하며, 비공식적인 Feature-based 구조(31%)에 이어 두 번째입니다.

모바일 개발에서 FSD는 Android 모듈 및 iOS 프레임워크의 특성에 적응합니다. IT Sectr에서는 10개 이상의 화면과 3개 이상의 팀이 있는 프로젝트에 FSD를 사용합니다. 이 방법론은 독립적인 기능 개발을 가능하게 하며 슬라이스 경계가 없는 모노레포에 비해 git 충돌을 40% 줄입니다.

FSD의 7개 계층: 구조 및 가져오기 규칙

FSD는 7개의 계층 구조를 정의하며, 각 계층에는 특정 추상화 수준의 코드가 포함됩니다. 주요 아키텍처 규칙은 계층은 하위 계층에서만 코드를 가져올 수 있다는 것입니다. 이 규칙을 위반하면(entities에 features 계층 가져오기) 아키텍처 오류로 간주되며 린터에 의해 차단됩니다.

FSD 프로젝트의 디렉토리 구조 예시:

src/
├── app/                    // 애플리케이션 계층
│   ├── providers/
│   ├── router/
│   └── styles/
├── pages/                   // 페이지 — 기능 구성
│   └── main/
├── features/                // 기능 — 사용자 시나리오
│   ├── auth/                // 슬라이스 «인증»
│   │   ├── ui/
│   │   ├── model/
│   │   └── api/
│   └── productList/         // 슬라이스 «제품 목록»
│       ├── ui/
│       └── model/
├── entities/                // 비즈니스 엔터티
│   ├── user/
│   └── product/
├── widgets/                 // 복합 컴포넌트
│   └── header/
└── shared/                  // 공유 유틸리티 및 UI-kit
    └── ui/

«계층은 아래쪽만 본다» 규칙은 FSD의 초석입니다. feature auth가 entity user를 가져오는 것은 올바릅니다. entity user가 feature auth를 가져오기 시작하면 순환 종속성 및 격리 위반입니다. 이 규칙을 강제하기 위해 ESLint 플러그인(eslint-plugin-fsd) 또는 슬라이스 공개 API의 사용자 지정 린터가 사용됩니다.

슬라이스: 비즈니스 도메인의 경계

슬라이스(Slice) — FSD에서 그룹화의 기본 단위로, 하나의 비즈니스 기능 또는 엔터티에 해당합니다. 각 슬라이스는 7개 계층(features, entities, widgets, pages) 중 하나에 위치하며 특정 기능을 구현하기 위한 완전한 코드 세트(UI 컴포넌트, 데이터 모델, API 클라이언트, 상수, 테스트)를 포함합니다.

슬라이스 경계는 비즈니스 도메인에 의해 정의됩니다. feature auth는 인증과 관련된 모든 것(로그인 양식, 등록 양식, 비밀번호 재설정)을 포함합니다. entity user는 User 모델, UserRepository 및 직렬화를 포함합니다. 경계는 중복되어서는 안 됩니다. feature auth에 사용자 데이터가 필요한 경우 로직을 복제하는 대신 entity user를 가져옵니다. 모바일 개발에서 FSD 슬라이스는 종종 Android의 Gradle 모듈이나 iOS의 Swift 패키지에 해당합니다.

슬라이스는 엄격하게 격리됩니다. 한 슬라이스의 내부 구조는 다른 슬라이스에 보이지 않습니다. 슬라이스 간 상호작용을 위해 공개 API(index.ts/index.js 파일 — 외부 사용이 허용된 것만 내보냄)가 사용됩니다. 나머지는 모두 프라이빗 모듈입니다. 이 접근 방식은 우발적 종속성을 방지하고 리팩토링을 단순화합니다. 한 슬라이스의 프라이빗 구현을 변경해도 다른 슬라이스에 영향을 미치지 않습니다.

세그먼트: 슬라이스 내 UI, API, Model, Lib

각 FSD 슬라이스 내에서 코드는 세그먼트별로 더 조직화됩니다 — 모든 슬라이스에서 반복되는 기술적 카테고리입니다. 표준 세그먼트 세트에는 ui(인터페이스 컴포넌트), model(비즈니스 로직, Store, Actions, Reducer), api(서버 요청, 변이), lib(유틸리티 및 헬퍼) 및 config(기능 설정)가 포함됩니다.

세그먼트는 권장 사항이지 엄격한 규칙이 아닙니다. 슬라이스가 작은 경우 세그먼트를 병합할 수 있습니다. 큰 슬라이스(10개 이상의 파일이 있는 기능)의 경우 세분화가 필수입니다. 그렇지 않으면 내부 구조가 50개 파일의 «바구니»로 빠르게 변하여 필요한 컴포넌트를 찾는 데 몇 분이 걸립니다. 모바일 개발에서 세그먼트는 종종 유형별 파일 구조로 대체됩니다. 각 기능은 내부 유형이 있는 별도의 Swift 파일 또는 Kotlin 클래스입니다.

모바일 개발의 FSD: Android 및 iOS 적응

모바일 개발에서 FSD는 플랫폼별 기능(Android의 모듈식 구조(Gradle 모듈) 및 Swift Package Manager)에 적응합니다. Android 적응은 각 슬라이스가 자체 build.gradle을 가진 별도의 Gradle 모듈이라고 가정합니다. feature-auth, feature-profile, entity-user, shared-ui 모듈은 빌드 수준에서 서로 격리됩니다. feature-auth는 dependencies에 지정되지 않는 한 feature-profile을 가져올 수 없습니다.

iOS 적응은 Swift Package Manager를 기반으로 합니다. 각 슬라이스는 공개 API가 있는 Swift 패키지입니다. TCA 프로젝트에서 feature.auth 슬라이스에는 자체 Reducer, Store, View 및 API 클라이언트가 포함됩니다. Swift Community Survey 2024에 따르면 TCA를 사용하는 iOS 프로젝트의 28%가 FSD에 가까운 슬라이스 아키텍처를 사용합니다.

모바일 FSD 적응의 주요 문제는 shared 계층의 중복입니다. 모바일 개발에서 UI 컴포넌트(shared/ui)는 종종 플랫폼(Android Views vs Jetpack Compose vs SwiftUI)에 따라 달라지며, 각 기술에 대해 별도의 shared 모듈이 필요합니다. FSD에서 shared 계층은 일반적으로 플랫폼 독립적(유틸리티, 설정)이며 UI-kit은 별도의 모듈이나 컴포넌트 라이브러리로 이동됩니다.

Feature-Sliced Design의 장단점

장점 FSD는 10명 이상의 개발자가 있는 대규모 프로젝트에서 두드러집니다. 각 개발자 또는 팀은 다른 코드를 건드리지 않고 자체 슬라이스에서 작업합니다. git 충돌이 40~60% 감소합니다(feature-sliced.design 사례 연구 데이터). 새로운 기능은 슬라이스의 공개 API만 사용하는 경우 기존 기능을 손상시킬 위험 없이 추가됩니다. 하나의 기능 리팩토링은 다른 기능의 변경을 필요로 하지 않습니다. 공개 API를 유지하면서 하나의 슬라이스 내에서 ui/model/api를 다시 작성하면 됩니다.

단점 FSD의 — 소규모 프로젝트에는 과도한 중첩. 애플리케이션이 3~5개의 화면으로 구성된 경우 7개 계층과 각 슬라이스 내 세분화는 애플리케이션 자체보다 더 많은 조직 코드를 생성합니다. 진입 장벽이 높습니다. 새 개발자는 방법론을 배우는 데 2~4주가 걸립니다. 또한 FSD는 빠른 프로토타이핑과 호환성이 낮습니다. 프로토타이핑에는 빈번한 교차 계층 가져오기가 필요하지만 FSD에서는 금지되어 반복 속도가 느려집니다.

더 간단한 Feature-based 구조로 시작하고 화면 수가 20개를 초과하고 팀이 5명을 초과하면 FSD로 마이그레이션하는 것이 좋습니다.