Untitled

Layers - Slices - Segments

1. FSD 개요


웹 서비스의 확장성을 고려해 FSD(Feature Sliced Design)을 적용했다.

기존 React 아키텍처의 문제점은 src 폴더 내부에 components, data, feature, models, router, store, styles, types 폴더를 만들어 관리하는 1 depth 형태로 구성을 했다.

FSD는 위계질서가 있는 아키텍처다. shared부터 app까지 계층을 의미하고 app은 그 아래 모든 계층을 참조할 수 있지만 하위 계층인 shared는 아래에 계층이 없기 때문에 참조할 계층이 없다.

2. FSD 구조 설명


2-1) layer

layer는 최상위 depth로 수는 아래에서 설명할 최대 6개로 제한되어 있다. 기존에는 7개였으나 process라는 layer가 현재 사용되지 않기에 6개로 설명 드릴 예정이다. 이 layer들은 src 폴더 아래에서 바로 보여지게 되는 구조라고 생각하시면 쉽다. 각 레이어는 관심사에 따라 분리가 되어 있으며 구성되는 레이어들은 아래와 같다.

레이어 역할 데이터/계산/액션 관점
app 애플리케이션 진입점– 라우터, 글로벌 프로바이더, 전역 스타일·테마 설정, 전역 타입 선언 등 데이터: 전역 상태 초기화(예: Auth 컨텍스트, 테마 설정)
계산: 앱 초기화 로직(예: 사용자 정보 로드 후 라우팅 결정)
액션: 전역 이벤트 처리(예: 글로벌 에러 핸들링), 라우팅 제어
pages URL 경로별 화면 조합 단위– 각 페이지에 필요한 위젯·피처 불러와 조립 데이터: 페이지별 API 페칭(예: 유저 상세 정보, 상품 리스트)
계산: 받은 데이터 가공·필터링(예: 페이징, 검색 필터 적용)
액션: 페이지 내 사용자 인터랙션 처리(예: 폼 제출, 필터 토글)
entities 도메인 모델의 데이터를 캡슐화
(순수 계산, side effect X) 데이터 정의: 타입·인터페이스·스키마– 상태 구조: Redux state, Zustand store 등
순수 연산: 엔티티 간 변형 (예: 가격 계산), 기본 검증 로직
features 비즈니스 로직의 계산·액션 담당
(행동을 담당, side effect O) 액션: API 호출, 사용자 인터랙션 처리, 사이드 이펙트
계산: entities 데이터를 조합·가공 (예: 장바구니 총합)– 플로우 제어: 프로세스 분기, 에러 핸들링 등
widgets 여러 shared/ui 컴포넌트(또는 다른 Widgets)를 조합해 하나의 UI 블록을 만든다.로컬 UI 상태(열림/닫힘, 선택 상태 등)만 관리하며, 비즈니스 로직(데이터 패칭·API 호출·내비게이션 등)은 직접 포함하지 않는다.Pages에서 내려준 콜백(Features 훅에서 래핑된 action 함수)을 받아 실행하는 순수 프레젠테이셔널 컴포넌트 역할. 재사용 가능한 UI 단위: 예) UserCard + FollowButton 조합, 검색어 입력창 + 버튼, 모달 + 리스트.순수 렌더링: 데이터 가공·계산 없이 props로 받은 값만 화면에 표시.액션 위임: 버튼 클릭 등 이벤트 발생 시 props로 받은 onClick, onUpload 같은 콜백만 호출.자체적인 로직은 “어떻게 보일지”에 한정하고, 핵심 비즈니스 처리는 모두 Features 훅으로 분리.
shared 애플리케이션 전역의 공통 요소 모음 (애플리케이션 전역에서 “모두”가 사용하는 기초 요소 모음) - UI 컴포넌트: Button, Input, Modal

위에서 설명한 6개의 layer들은 규칙이 있다. 계층이 있는데, app은 그 하위에 설명한 5개의 layer들을 가져와서 사용할 수 있지만, 예를 들어 features에서는 app을 가져와서 사용하지 못한다. 설명하는 순서가 계층 순서로 보면 된다. shared는 다른 layer에서 가져다 쓸 수는 있지만 shared가 다른 layer들은 가져다 쓸 수 없는 구조.