[프론트엔드 아키텍처] FSD(Feature-Sliced Design)란?

FSD(Feature-Sliced Design)란?

FSD는 이름 그대로 기능(Feature)을 중심으로 애플리케이션을 얇게 조각내어(Sliced) 설계(Design)하는 방법론입니다.

기존의 기술 중심적인 분리(예: 단순히 components, hooks, utils로만 나누는 방식)에서 벗어나, 비즈니스 로직과 사용자 기능을 기준으로 프로젝트 구조를 체계화합니다. 이를 통해 프로젝트의 규모가 커져도 유지보수성과 확장성을 잃지 않도록 돕습니다.

---

FSD의 핵심 철학 : 단방향 의존성 규칙

FSD를 관통하는 단 하나의 절대적인 규칙이 있습니다. 이 규칙만 이해해도 FSD의 절반은 성공입니다.

 "상위 계층은 하위 계층을 import 할 수 있지만, 하위 계층은 절대 상위 계층을 import 할 수 없다."

FSD는 엄격한 계층구조를 가지고 있으며, 의존성은 항상 위에서 아래로만 흘러야 합니다.

이 규칙 덕분에 순환 참조(Circular Dependency) 문제가 원천 차단되고, 특정 모듈을 수정했을 때 영향받는 범위를 예측하기 쉬워집니다. 하위 계층일수록 더 범용적이고 재사용성이 높습니다.

FSD의 6단계 계층 구조 (Layer)

FSD는 표준화된 6개의 계층을 제안합니다. 위로 갈수록 구체적인 화면에 가깝고, 아래로 갈수록 추상적이고 범용적인 코드에 가깝습니다.

(위에서부터 아래로 설명합니다. 위 계층이 아래 계층을 사용합니다.)

1. App (애플리케이션)

프로젝트의 진입점이자 껍데기입니다.

• 역할: 전역적인 설정, 스타일, 레이아웃, Context Provider 등 애플리케이션 전체를 초기화하고 감싸는 역할을 합니다.
• 예시: App.tsx, 라우터 설정, 글로벌 스타일 시트, Redux/Recoil Store 초기화.

2. Pages (페이지)

사용자가 보는 완성된 하나의 화면 단위입니다.

• 역할: 하위 계층(주로 Widgets)을 조립하여 라우팅 경로에 해당하는 페이지를 구성합니다. 실제 비즈니스 로직은 거의 포함하지 않고 '배치'에 집중합니다.
• 예시: 메인 페이지, 로그인 페이지, 상품 상세 페이지.

3. Widgets (위젯)

페이지를 구성하는 굵직한 독립적인 UI 블록입니다.

• 역할: Entities와 Features를 조합하여 만듭니다. 페이지에 가져다 붙이기만 하면 완성된 기능을 제공하는 '조립품'입니다.
• 예시: GNB(헤더), 푸터, 메인 뉴스 피드 섹션, 상품 결제 폼 영역.

4. Features (기능)

사용자의 상호작용(User Action)이 일어나는 단위입니다. 비즈니스 가치를 제공하는 '동작(Verb)'에 집중합니다.

• 역할: "사용자가 무엇을 하는가"를 다룹니다. 특정 Entity를 조작하거나 상태를 변경하는 로직이 포함됩니다.
• 예시: '장바구니 담기' 버튼 클릭 동작, '검색어 입력 후 엔터' 동작, '좋아요 토글' 기능.

 Entities (비즈니스 엔티티)

비즈니스 도메인 데이터 모델 그 자체를 다룹니다.

• 역할: "무엇을 보여주는가"에 집중합니다. 데이터 구조(Model)를 정의하고, 데이터를 화면에 표시하기 위한 순수한 UI 컴포넌트들이 위치합니다. 재사용성이 높습니다.
• 예시: 사용자(User) 정보 카드 UI, 상품(Product) 정보 타입 정의 및 가격 표시 컴포넌트.

6. Shared (공용)

특정 비즈니스 로직에 종속되지 않은 가장 기초적인 계층입니다.

• 역할: 프로젝트 전반에서 재사용되는 유틸리티, UI 라이브러리(버튼, 인풋 등), 설정 파일 등이 위치합니다.
• 예시: UI 키트(공통 버튼, 입력창), API 호출을 위한 Axios 인스턴스, 커스텀 훅(useInput), 날짜 포맷팅 함수.

FSD를 도입하는 이유

1. 명확한 코드 위치와 역할
"이 코드를 어디에 둘까?"라는 고민이 사라집니다. 각 계층의 역할이 명확하므로 새로운 팀원이 합류해도 프로젝트 구조를 빠르게 파악할 수 있습니다.

2. 높은 응집도와 낮은 결합도 (격리된 환경)
기능별로 폴더가 격리(Sliced)되어 있습니다. A 기능을 수정할 때 B 기능이 영향을 받을 확률이 현저히 줄어듭니다. 이는 사이드 이펙트에 대한 두려움 없이 리팩토링과 기능 추가를 가능하게 합니다.

3. 뛰어난 확장성
프로젝트 초기에는 조금 복잡해 보일 수 있지만, 프로젝트 규모가 커질수록 이 견고한 구조가 빛을 발합니다. 수년간 유지보수해야 하는 대규모 프로젝트에 특히 적합합니다.

---

정리

FSD는 단순한 폴더 구조 규칙이 아니라, 지속 가능한 프론트엔드 개발을 위한 하나의 사고방식입니다.

처음에는 계층을 나누는 기준이 헷갈릴 수 있습니다. 특히 Features와 Entities, Widgets의 경계가 모호하게 느껴질 수 있습니다. 하지만 "의존성은 아래로만 흐른다"는 대원칙을 지키며 적용해 나가다 보면, 어느새 스파게티 코드가 사라지고 깔끔하게 정돈된 아키텍처를 마주하게 될 것입니다.