티스토리 뷰

카테고리 없음

[React] FSD 아키텍처

예둥 2025. 1. 13. 15:49

1. FSD 아키텍처란?

FSD(Feature-Sliced-Design) 아키텍처는 소프트웨어 시스템을 기능 중심으로 나누어 모듈화하고, 각 기능을 독립적으로 관리하는 방식이다. 이 아키텍처는 특히 대규모 프론트엔드 애플리케이션에서 코드의 유지보수성과 재사용성을 높이기 위해 사용된다. FSD 아키텍처는 각 기능을 독립적인 도메인으로 분리하여 개발할 수 있도록 하고, 코드의 복잡도를 줄이며, 팀 협업을 개선하는 데 목적이 있다.

2. FSD 아키텍처의 기본 개념

FSD는 기능 중심(Feature-Oriented) 접근 방식을 사용한다. 이를 통해 프로젝트가 점진적으로 성장하면서도 유지보수가 용이하게 설계된다. FSD 아키텍처의 기본 원칙은 다음과 같다.

  1. 기능 기반 분할: 애플리케이션을 기능별로 나누어 각 기능을 독립적인 모듈로 관리하며, 기능은 시스템에서 특정한 비즈니스 로직이나 사용자 인터페이스의 한 부분을 담당한다.
  2. 레이어링: 기능을 레이어로 나누어 책임을 분리한다.
  3. 폴더 구조: 기능별로 폴더 구조를 구성하여 코드의 가독성과 유지보수성을 높이며, 각 폴더는 그 기능과 관련된 모든 것을 포함한다.
  4. 재사용성: 공통 기능이나 유틸리티는 재사용 가능하도록 Shared 레이어에 배치한다. 이를 통해 중복 코드를 줄이고 일관성을 유지한다.

 

2-1 세부구조

FSD는 아래와 같이 전체적으로 layer, slice, segment의 총 3depth로 이루어져 있습니다.

  • Layers(레이어): 프로젝트의 논리적 단위이며, 각 레이어는 특정 역할을 담당한다. 이는 다른 레이어에 의존하거나 영향을 미칠 수 있다.
  • Slices(슬라이스): 기능별로 나뉜 모듈들을 의미한다. 사진처럼 User, Post, Comment등의 슬라이스가 있을 수 있다.
  • Segments(세그먼트): 각 슬라이스 내에서 기능을 더 세분화한 단위이다. 일반적으로 UI, Model, API로 구분한다.

 

2-2 레이어(Layers)

Layer Can use
app pages, widgets, features, entities, shared
pages widgets, features, entities, shared
widgets featruers, entities, shared
featrues entities, shared
entities shared
shared -
  • app: 애플리케이션 전역 설정 및 초기화 (프로바이더, 라우터, 전역 스타일, 전역 선언)
  • pages: 사용자 인터페이스의 주요 화면 구성.
  • widgets: 해당 레이어는 재사용가능한 독립적인 UI 컴포넌트. (버튼, 입력 필드, 아이콘 등 기본 UI 요소)
  • featrues: 해당 레이어는 UI에 기능적인 부분을 포함한다. 예를 들어 다크모드, 좋아요 등이 있다.
  • entities : 애플리케이션의 핵심 데이터 모델과 비즈니스 로직. (도메인 모델, 데이터베이스 매핑, 엔티티 간 상호작용 정의)
  • shared: 전역적으로 사용되는 유틸리티 및 공통 코드. (API 클라이언트, 상수, 테마 )

 

2-3 슬라이스(Slices)

슬라이스는 FSD 구조의 두번째 계층으로, 레이어의 하위 디렉토리입니다. 각 슬라이스는 각 레이어 내에서 세부적인 기능을 나누어 그룹화한 것이다.

 

슬라이스의 이름은 표준화되어 있지 않으며 프로젝트 목적에 따라 다르게 설정된다. 예를 들어 사진 갤러리에는 사진, 앨범, 갤러리와 같은 슬라이스를 가지며, 소셜 네트워크에서는 게시물, 사용자, 뉴스피드와 같은 슬라이스를 가질 것이다.

 

* app과 shared 레이어는 다른 레이어들과 달리 슬라이스를 가지지 않으며, 직접 세그먼트로 구성된다. shared 레이어는 비즈니스 로직을 포함하지 않고, app 레이어는 전체 애플리케이션과 관련된 코드만 가지므로 분할할 필요가 없기 때문이다.

 

2-3-1 슬라이스에 대한 공개 API 규칙

모든 슬라이스(슬라이스가 없는 레이어의 세그먼트 포함)는 진입점이 되는 공개 API를 반드시 포함해야 합니다. 슬라이스는 직접적으로 참조될 수 없으며, 외부 모듈은 해당 슬라이스의 공개 API를 통해서만 접근할 수 있습니다.

 

각 슬라이스는 외부에 필요한 부분만 공개 API를 통해 노출하고, 노출을 원하지 않는 내부 로직은 숨길 수 있습니다. 이러한 캡슐화는 모듈 간 결합도를 낮춰 한 모듈의 변경이 다른 모듈에 주는 영향을 최소화합니다. 그 결과 코드의 유지보수성과 재사용성, 확장성 등이 크게 향상됩니다.

 

2-4 세그먼트 (Segment)

세그먼트는 FSD 구조의 세 번째이자 마지막 계층입니다. 세그먼트는 각 슬라이스 내에서 기능을 더 세분화하여 그룹화한 것입니다.

 

세그먼트 이름은 표준화되어 있지 않지만, 일반적으로 사용되는 세그먼트들은 다음과 같습니다.

  • ui : UI 화면과 관련된 모든 것을 포함하는 세그먼트입니다.
  • api : 백엔드와의 상호작용을 관리하는 세그먼트입니다.
  • model : 비즈니스 로직과 상태 관리를 담당하는 세그먼트입니다.
  • lib : 슬라이스 내에서 사용되는 보조 기능을 모아 놓은 세그먼트입니다.
  • config : 슬라이스에서 필요한 설정값을 관리하는 세그먼트입니다.

3. FSD 구조 적용 시 이점

  • 일관성 : FSD는 표준화된 구조를 가지고 있어 프로젝트 전반에 걸쳐 일관성을 유지합니다. 각 기능별로 동일한 디렉터리 구조와 명명 규칙을 따르므로, 프로젝트의 규모가 커지더라도 구조적 복잡성을 줄일 수 있습니다. 이를 통해 신규 개발자나 외부 인력이 쉽게 적응할 수 있고, 코드 베이스의 가독성 및 유지보수성이 향상됩니다.
  • 유지보수성 및 확장성 : 각 기능이 독립적인 모듈로 구성되어 있어 특정 기능의 변경이 다른 기능에 영향을 주지 않습니다. 새로운 기능을 추가하거나 기존 기능을 수정할 때, 충돌 위험이 적으며 변경 사항을 쉽게 추적할 수 있습니다. 따라서 애플리케이션 확장성도 크게 향상됩니다.
  • 재사용성 : 독립적인 기능 단위로 개발된 코드는 다른 프로젝트나 애플리케이션에서도 쉽게 재사용할 수 있어 코드의 활용도가 높아집니다.
  • 협업 효율성 : 기능을 중심으로 코드가 분리되어있어 팀원들이 병렬로 작업할 수 있는 환경을 제공합니다. 따라서 협업이 더 원활해지고 프로젝트 진행 속도를 높일 수 있습니다. 
  • 비즈니스 지향적 구조 : FSD 구조는 비즈니스 도메인 중심의 구조로, 애플리케이션을 비즈니스 요구 사항에 맞춰 개발하고 확장하는 데 유리합니다. 코드가 비즈니스 기능을 기준으로 분리되어 있기 때문에, 비즈니스 로직의 변경이 필요한 경우에도 해당 기능을 쉽게 찾아 수정할 수 있습니다.

4. FSD 구조 적용 시 고려사항

  • 오버 엔지니어링 : 작은 프로젝트나 간단한 요구사항에서는 오히려 불필요한 복잡성을 추가할 수 있습니다. 
  • 높은 진입 장벽 : 진입 장벽이 높아 학습하고 이해하는 데 시간이 소요될 수 있습니다.
  • 조직적 합의 : 팀 전체가 새로운 설계 방식을 수용하고, 일관된 개념을 유지할 수 있도록 협력해야 합니다.