FSD 아키텍처란?

Every GSM 프로젝트를 진행하면서 FSD 아키텍쳐를 처음 접해봤는데

더 자세히 알아보고 싶기도하고 복습 겸 적어보게 되었습니다.

 

 

FSD 아키텍처란 무엇일까?

공식 문서에 따르면 FSD(Feature-Sliced Design) 는 프론트엔드 애플리케이션 구조를 설계하기 위한 아키텍처 방법론입니다.
단순한 폴더 규칙이 아니라, 비즈니스 요구 사항에 안정적으로 대응하면서 프로젝트를 체계적으로 유지 및 확장할 수 있는 구조를 제공합니다.

여기서 아키텍처란 프로젝트 전체가 어떻게 구성되어 있는지에 대한 큰 구조를 의미합니다.

 

쉽게 말하면 프로젝트에서 기능이 많아질수록 구조가 복잡해지는데, FSD는 기능 단위로 구조를 명확히 나누어 유지보수성과 확장성을 높여주는 설계 방법이라 생각하면 됩니다.

 

 

참고 공식 문서: https://feature-sliced.design/docs/get-started/overview

Overview | Feature-Sliced Design

 

 

 

FSD의 철학과 목적

FSD의 설계 철학으로는

1. 비즈니스/사용자 요구 중심

프로젝트 구조를 기능(Feature) 기준으로 나누기 때문에, 코드가 실제 서비스 동작과 직결된 논리를 반영합니다.

2. 명시적 의존성 규칙

의존 관계가 한 방향으로 흐르도록 설계되어 있어, 순환 의존과 혼란을 방지합니다.

3. 명확한 코드 재사용

각 모듈이 공개 API를 갖고, 다른 모듈은 이를 통해서만 상호작용하기 때문에 재사용이 체계적입니다.

 

 

 

FSD 아키텍처 구조

FSD는 크게 레이어(Layers) -> 슬라이스(Slices) -> 세그먼트(Segments)로 구성됩니다.

출처: https://feature-sliced.design/docs/get-started/overview

 

그러면 이제 각 층에 대해 자세히 알아보도록 하겠습니다.

 

 

Layer (계층)

레이어는 프로젝트 전체 구조를 결정하는 최상위 분류입니다.

이 코드가 앱에서 어느 위치에 있고 가까운지를 기준으로 나눕니다.

 

FSD에서 권장하는 대표적인 주요 레이어는 밑에 표로 정리해봤습니다!

레이어	역할
app	애플리케이션의 진입점, 글로벌 설정, Provider, Router 구성
pages	URL 라우터 단위의 페이지
widgets	여러 기능을 조합한 큰 UI 블록
features	구체적인 사용자 행동/기능
entities	비즈니스 도메인(예: user, product) 모델과 데이터
shared	프로젝트 전체에서 공통으로 쓰는 재사용 유틸/컴포넌트

 

 

Layer의 핵심 특징으로는 의존성 방향이 정해져 있어 위에 있는 레이어는 아래만 참조가 가능합니다.

shared → entities → features → widgets → pages → app

 

예를 들어 이런 형태라면 pages는 widgets이,  widgets는 features이, features는 entities 사용이 가능하게 됩니다

아래로 갈 수록 작아지고 위로 갈수록 앱에 가깝다고 생각하면 될 것 같습니다.

 

 

---

 

Slice 

Slice는 Layer 안에서의 기능 또는 도메인 단위의 폴더입니다.

아까 위에서 설명한 Layer가 층이라면 Slice는 그 안에 있는 독립된 모듈 묶음입니다.

 

Slice가 나뉘는 기준을 설명하자면 아래와 같이 나눠지게 됩니다

 

entities에서는 도메인 개념 하나

• user
• article

features에서는 사용자 행동 하나

• login
• toggle-like

widgets에서는 화면 덩어리 하나

• header
• product-list

 

참고 Feature vs Widget 헷갈릴 때 구분법

• 사용자 행동 중심이면→ feature
• 화면 섹션이면→ widget
• 페이지에 꽂히면 → widget
• 단독 기능이면 → feature

 

 

 

 

예시를 들어 이런 폴더 구조가 있다면

features/
  auth/
  like-post/
  add-to-cart/

entities/
  user/
  product/

 

여기서 auth와 user는 각각 하나의 Slice가 됩니다!

 

Slice의 특징으로는 독립적으로 유지되어야 합니다. 

그래서 다른 Slice 내부를 직접 import하지 않고 공개 API(index.ts)를 통해서만 사용되어야합니다

또한 이름만 보고 역할이 보여야하기 떄문에 네이밍이 중요합니다..

 

 

---

 

 

Segment(기술 역할 단위)

Segment는 Slice 안에서 UI인지, 상태인지, API인지를 역할별로 나눈 폴더입니다.

 

공식에서 자주 쓰는 Segment 종류도 표로 정리해봤습니다.

Segment	역할
ui	React 컴포넌트
model	데이터 모델 (스키마, 인터페이스, 저장소 및 비스니스 로직)
api	서버 통신
lib	헬퍼 함수
config	설정 파일 및 기능 플래그

 

아까 설명한 Slice와 연관지어 예시를 들어보자면

features/login/
  ui/
    LoginForm.tsx
  model/
    useLogin.ts
  api/
    loginApi.ts

 

여기서 login은 Slice가 되고 그 안에 있는 ui, model, api는 세그먼트가 됩니다.

 

핵심으로만 요약하자면 

Layer는 큰 계층
Slice는 의미 단위 묶음
Segment는 기술 역할별 하위 폴더라고 기억하면 좋을 것 같습니다.

 

 

 

언제 FSD를 쓰는게 좋을까?

1. 기능이 계속 늘어날 예정인 프로젝트

FSD는 코드를 기능 단위(Slice) 로 나누기 때문에
새 기능이 추가될 때 기존 구조를 크게 흔들지 않고 확장할 수 있어서 편합니다.

예를 들어서

• 로그인 기능 추가 → features/login
• 좋아요 기능 추가 → features/toggle-like

이처럼 새로운 기능이 생길 때마다 정해진 위치에 새 슬라이스를 추가하면 되기 때문에
프로젝트 규모가 커질수록 좋을 것 같습니다.

 

 

2. 유지보수가 중요한 서비스

운영 중인 서비스는 기능 추가보다 기존 코드 수정이 더 많아지는데

이때 구조가 엉켜 있으면 어디까지 영향이 가는지 알기 어렵습니다

근데 FSD는 역할이 나눠져 있고 슬라이스 단위로 경계가 명확해서 리팩토링이 편해질 것 같습니다.

예를 들어 이번에 헬지도 마찬가지로 fsd 도입을 하는게 좋겠다고 생각합니다..

 

 

 

 

마무리

오늘은 fsd 아키텍처에 대해 알아봤습니다!

생각보다 장점이 많으니 상황 판단해서 fsd로 마이그레이션 해보는 걸 고려해 보는 것도 좋을 것 같네요

글을 쓰면서 내용을 한 번 더 정리해서 확실히 이해도가 올라간 것 같습니다