기존 디렉토리 구조에도 FSD 아키텍처를 차용했으나 app, pages, features, shared 레이어만 선택하여 사용하였다. 기능을 조금 더 세분화하고 컴포넌트 단위를 더 쪼갤 수 있도록 기존 구조에서 widgets과 entities를 추가하며 해당 문서를 작성하였다.

👩‍💻 Dev
실제 개발을 하며 적용한 내용을 본 형식의 인용문에 추가하였다.

📌FSD (Feature-Sliced Design)

FSD는 기능 분할 설계 아키텍처로, 복잡한 애플리케이션의 기능을 쪼개어 관리하는 프론트엔드 아키텍쳐 패턴이다.

큰 개념으로는 layer, slice, segment가 있다.

Layer

Layer는 애플리케이션의 구조를 기능 단위로 나누는 개념이다. 이를 통해 코드의 재사용성을 높이며 유지보수가 용이하다. 레어어는 최대 7개로 제한되어 있으며, 다음과 같이 구성할 수 있다.

src/
├── app/
├── processes/
├── pages/
├── widgets/
├── features/
├── entities/
└── shared/

• app

  애플리케이션의 초기 설정, 라우터, 전역 관리, 등이 정의된다.
  

• processes

  여러 단계로 이루어진 프로세스로 선택적 레이어이다. (→ 차용하지 않음)
  

• pages

  사용자에게 보여지는 개별 페이지를 가진다.
  

👩‍💻 Dev
페이지 컴포넌트를 포함하며 Header, Footer 와 같은 큰 단위의 컴포넌트가 해당 페이지에서 사용될 시 pages에 위치할 수 있다. 이 경우 페이지 컴포넌트와 구분하여 한눈에 알아보기 쉽도록 Header, Footer와 같이 단순하게 명명하기로 한다.

• widgets

  페이지에서 독립적으로 사용되는 UI를 포함한다.
  

👩‍💻 Dev
페이지에서 단독으로 사용되는 경우 pages에서 관리하기로 하였기에 여러 feature를 재조합하여 단일 기능을 만든 경우 widgets에 추가하기로 한다. widget은 단독으로 제작되지 않고, feautre를 조립하는 용도로 사용한다.

• features

  특정 기능을 독립적으로 처리하며 해당 기능에 관련된 상태와 UI를 관리한다.
  

👩‍💻 Dev
entities에서 정의된 api및 model을 가지고 기능을 구현하였을 때 해당 레이어에 위치시킨다.
Custom hook과 같은 로직을 이 곳에 위치시키는가에 대한 논의가 있었으나, 해당 로직이 사용되는 덩어리 단위로 생각하기로 한다. feature 단위에서 사용되는 로직의 경우 features에, widget단위에서 사용되는 로직의 경우 widgets에서 위치시킨다. 해당 로직이 여러 컴포넌트에서 동일하게 사용되는 경우 Hook을 shared에서 관리하기로 한다.

• entities

  데이터 구조와 로직을 관리한다.
  

👩‍💻 Dev
api와 같이 데이터를 다루는 경우 해당 레이어에서 관리한다. 기존에는 api를 하나의 파일로 모두 관리하였기 때문에, 어떤 기준으로 이를 나누어 줄 것인지에 대한 고민이 있었다. api를 위치시키는데 있어 팀원 간의 주관성을 최대한 줄이기 위해 백엔드 테이블을 기준으로 구분하되, 모호한 기준을 가진 테이블은 팀원과 합의하에 세분화하여 넣는다.

• shared

  전반적으로 재사용되는 코드 및 UI를 가진다.
  

👩‍💻 Dev
widget에 들어가는 컴포넌트와 shared의 ui에 들어가는 컴포넌트를 어떻게 구분해주어야 할 지에 대한 논의가 있었다. shared에 들어가는 컴포넌트는 비즈니스 로직을 포함하지 않고 전반적으로 재사용되는 컴포넌트들을 위치시켰다.

Layer 원칙

FSD는 위계적 구조(hierarchical structure)를 따른다.

💡 Layer 원칙
1. 아래 단계의 레이어에만 접근 가능
2. 위계가 낮을 수록 영향받는 곳이 많아 변경이 위험

Slice

layer는 Slice라는 하위 디렉토리를 가진다. Slice는 비지니스 영역에 따라 결정한다.

Segment

Slice는 Segment로 구성된다. Segment는 Slice를 목적 기반으로 분할한다. 일반적으로는 아래의 세그먼트들을 사용하지만, 팀원간의 합의에 따라 달라질 수 있다.

• api - api 요청
• ui - UI 컴포넌트
• model - 비즈니스 로직으로 actions, selectors 등이 해당
• lib - 슬라이스 내 보조 기능
• config - 슬라이스 내에서 필요한 설정을 포함 (세그먼트는 거의 필요하지 않음)
• consts - 상수 정의

Public API

Public API는 index.ts(index.js) 파일을 사용하고, 이 파일을 통해 슬라이스 또는 세그먼트에서 필요한 기능만 외부로 추출하고 불필요한 기능은 격리한다.

💡 Public API 원칙
1. 앱의 Slice와 Segment들은 Public API index 파일에 정의된 기능과 컴포넌트만 사용한다.
2. Public API에 정의되지 않은 부분은 자신의 Slice나 Segment만 접근할 수 있다.

📌후기

FSD를 사용하는데 있어 그 기준을 명확히 세우고 정의하는 것이 중요하다고 느꼈다.

어느정도의 틀은 차용하되, 세부적인 규칙은 팀원 간의 합의가 필요하며 최대한 주관성을 배제하여 어떤 ui 또는 로직이 어느 곳에 들어가야 할 지 명확해지도록 해야 팀원 간 혼동을 줄일 수 있다.

물론 이 기준을 세우는 것이 FSD를 사용하는 데 가장 큰 어려움이기에 많은 논의가 필요하다.

하지만 논의가 충분히 이루어진 뒤 개발 단계에서는 굉장히 명시적이고, 잘 통제된 구조를 사용할 수 있을 것 같다.