[119일차] 프론트엔드 FSD 아키텍처

 

융합 프로젝트를 진행하면서 현직자 멘토링을 통해 폴더 구조에 대한 피드백을 받았다.

FSD 아키텍처로 가는 것이 어떤 지 피드백을 주셔서 FSD 아키텍처에 대해서 알아보고자 한다.

 

 

FSD 아키텍처란?

FSD 아키텍처는 Feature-Sliced Design(기능 분할 설계) 의 약자로, 프론트엔드 애플리케이션 구조를 위한 아키텍처 방법론이다.

프론트엔드 개발자는 대부분 모듈 간 느슨한 결합 + 높은 응집력을 제공해야 하며, 쉽게 확장할 수 있는 아키텍처를 필요로 한다.

이를 위해 FSD 아키텍처를 도입하는 개발자들이 늘어나게 되었다.

 

FSD는 총 3가지의 개념이 존재한다: Layer, Slice, Segment

 

FSD 아키텍처 (FSD 공식문서)

 

 

레이어 (Layer)

레이어는 최상위 디렉토리이자, 애플리케이션 분해의 첫 번째 단계이다.

레이어의 수는 최대 7개로 제한되어 있으며 필요한 Layer만 추가하여 사 수 있다.

Layer 구분

 

 

구분	설명	특이사항
app	- 애플리케이션 로직이 초기화되는 곳 - 프로바이더, 라우터, 전역 스타일, 전역 타입 선언 등이 정의됨	- 애플리케이션의 진입점 역할
processess	- 여러 단계로 이루어진 등록과 같이 여러 페이지에 걸쳐 있는 프로세스 처리	- 선택적 레이어 - 잘 사용하지 않음
pages	- 애플리케이션 페이지가 포함됨	- 대부분 페이지 1개는 슬라이스 1개 (단, 유사 페이지는 하나의 슬라이스로 묶기 가능)
widgets	- 독립적으로 작동 - 여러 페이지에서 재사용되는 대규모 기능 or UI 컴포넌트 - 보통 하나의 완전한 기능
features	- 제품 전반에 걸쳐 재사용되는 기능 구현체 - 사용자에게 실질적인 비즈니스 가치를 제공하는 동작 - 동사적 개념 ("사용자가 ~한다")	- feature 간 직접 참조 금지
entities	- 비즈니스 데이터 - 명사적 개념 ("~이 뭔지 정의한다")	- entities → feature 참조 금지
shared	- 기본 구성 요소를 모아둠 - 재사용 가능한 기능, 특히 프로젝트/비즈니스의 특성과 분리되어 있을 때 (반드시 그럴 필요는 x) - UI 키드, axios 설정, 앱 설정, 비즈니스 로직에 묶이지 않은 헬퍼 등 포함

 

각 레이어의 사용 범위

 

레이어는 위에서 아래로의 단방향 의존성을 가진다는 특징이 있다.  ex) entities 레이어는 features 레이어 기능 사용 X

이는 레이어의 위치가 낮을수록 재사용될 가능성이 높기 때문이다.

 

 

 

슬라이스 (Slices)

슬라이스는 FSD 아키텍처에서 2번째 계층이며, 레이어 내에서 코드를 비즈니스 도메인별로 분해하는 역할을 한다. 슬라이스의 주요 목표는 코드를 값별로 그룹화하는 것이다.

슬라이스 이름은 프로젝트의 비즈니스 영역에 따라 직접 결정되므로 표준화되어 있지 않다.

같은 레이어 안에서 다른 슬라이스를 참조할 수 없으며, 이는 높은 응집도와 낮은 결합도를 유지하는 데 도움을 준다.

 

❗️ 응집도와 결합도란?

⋅ 응집도 (Coupling): 모듈의 독립성. 모듈 내부 구성요소 간 연관 정도

⋅ 결합도 (Coupling): 외부 모듈과의 연관도 or 모듈 간 상호의존성 정도

 

➡️ 응집도는 높게, 결합도는 낮게 유지하는 것이 좋다!

슬라이스 구조

 

 

 

세그먼트 (Segements)

세그먼트는 FSD 아키텍처에서 마지막 계층이며, 코드 내에서 기술적 목적에 따라 구분한다. 팀 합의에 따라 세그먼트의 구성과 이름이 변경될 수 있다. 일반적으로 사용되는 세그먼트는 아래와 같다.

네이밍	설명
api	필요한 서버 요청
ui	슬라이스의 ui 컴포넌트
model	- 비즈니스 로직, 즉 상태와의 상호작용 - actions 및 selectors가 이에 해당
lib	슬라이스 내에서 사용되는 보조 기능
config	슬라이스에 필요한 구성값이지만, 구성 세그먼트는 거의 필요 X
consts	필요한 상수

 

 

 

공개 API

각 슬라이스와 세그먼트에는 공개 API 가 있다. 공개 API는 `index.js` 또는 `index.ts` 파일이며, 이 파일을 통해 슬라이스 또는 세그먼트에서 필요한 기능만 외부로 추출하고 불필요한 기능은 격리할 수 있다.

 

규칙은 다음과 같다:

⋅ 애플리케이션 슬라이스와 세그먼트는 공개 API 인덱스 파일에 정의된 슬라이스의 기능과 컴포넌트만 사용

⋅ 공개 API에 정의되지 않은 슬라이스 또는 세그먼트의 내부 부분은 격리된 것으로 간주되며 슬라이스 또는 세그먼트 내부에서만 접근 가능

 

공개 API는 import 및 export로 단순하게 작동하므로 애플리케이션을 변경할 때 코드의 모든 곳에서 import를 변경할 필요가 없다.

index.js 예시

 

이를 활용하여 `tsconfig.json` 에서 경로를 지정해 주면 alias(@)를 활용하여 각 컴포넌트에서 간단하게 import 할 수 있다.

tsconfig.ts 예시

 

 

 

FSD의 장단점

장점

1️⃣ 구조가 명확하여, 팀 간 협업 및 신규 작업자 온보딩이 용이

2️⃣ 추가 기능 작업 시, Side Effect 발생 확률이 줄어듦 (레이어-슬라이스 로 코드가 구분되어 있기 때문)

3️⃣ 유지보수성 향상 (재사용 가능한 코드 레벨과 지역적으로만 사용하는 코드 레벨을 레이어에 따라 구분할 수 있기 때문)

 

단점

1️⃣ 높은 진입 장벽

2️⃣ 인식, 팀 문화 및 개념 준수가 필수

3️⃣ Challenge와 Problem을 즉시 해결해야 함 (코드 문제와 개념에서 벗어난 부분을 즉시 확인 할 수 있음)

 

---

회고

이제까지 프로젝트는 아래와 같이 전통적인 폴더구조로 작업을 했었다. 실제로 FSD를 알고 있긴 했으나, 잘 모르고 사용하기보다는 그냥 기존 폴더 구조 방향을 유지하려고 했었다.

그러나 이번 피드백을 통해 실제 현업에서 응집도/결합도를 고려한 폴더 구조를 사용하고 있다는 것을 알게 되었고 이제는 새로운 폴더 구조를 받아들여야 할 것 같다는 생각이 들었다.

생각했던 대로 마음으론 이해를 했지만, 머리로는 이해를 하지 못해서 아직도 어렵긴 해도 이번 프로젝트에 제대로 적용을 하여 혼날 건 혼나고 그 과정에서 새로운 지식을 학습하는 데 의의를 두고자 한다.

이전 폴더구조 예시