[React] FSD 폴더구조 공부 후기

일단 FSD(Feature Slice Design) 폴더구조는 프론트엔드 애플리케이션을 도메인 단위(기능 단위)로 나누어 관리하는 아키텍처 패턴이다.

 

일반적으로 React폴더구조는 계층적인 구조로 components, hooks, pages 등으로 나누는데, FSD는 사용자 기능(feature)을 중심으로 코드를 묶어서 확장성과 유지보수성을 높이는 방식이다.

 

src/
 ├─ app/           # 앱 초기화, 라우팅, 글로벌 설정
 ├─ processes/     # 여러 feature를 묶은 비즈니스 프로세스
 ├─ pages/         # 페이지 단위 (feature 조합)
 ├─ features/      # 로그인, 장바구니, 댓글 등 기능 단위
 ├─ entities/      # User, Post 같은 핵심 도메인
 ├─ shared/        # 버튼, 유틸, 훅, 스타일 같은 공용 자원

 

위 폴더 구조를 가지고, app은 최상위, shared는 최하위 계층으로 구분한다.

그리고 상위 계층은 하위 계층의 코드를 가져올 수 있지만 하위 계층에서 상위 계층의 코드를 가져다 쓸 수 없다는 규칙이 있다.

일단 아주 간략히 이정도로 FSD 설명을 마치고.. 다음이야기를 이어나가보겠다.

 

그동안 일을 하면서도 폴더구조 변경을 여러차례 시도해봤었고, FSD를 도입해보려고 공부해봤지만 모호한 부분이 많아서 오히려 관리하기 어려워 지는 일이 많았다. 

 

그럼 내가 진행했던 과제 회고를 시작으로 후기를 남겨보겠다.

 

회고

일단 과제는 App.tsx파일에 모든 컴포넌트가 분리도 되지 않은 상태로 거대한 코드 덩어리 상태로 존재했다. 이 거대한 파일을 FSD구조에 알맞게 분리시키는것이 1차 과제이고, 분리가 되었다면 상태를 props로 넘겨줄 때 굉장히 깊은 props drilling이 발생하기 때문에 전역 상태관리까지 적용시키는것이 2차 과제였다.

 

먼저 느낀점은 프론트엔드에서도 entity 기준으로 분리하면 코드가 생각보다 관리가 쉽다는 점이였다.

나는 entities 폴더에 도메인을 기준으로 나누면 백엔드에 통신하는 코드들을 모아두고 관리하기 편리했다.

여기서 내가 생각하는 도메인이란 DB의 테이블을 기준으로 생각한다. 예를들면 user, product 등이다.

 

내가 FSD를 적용하려고 가장 애 쓴 부분

entities 폴더에 최대한 도메인 모델과 api만 넣으려고 했고, feature폴더엔 기능을 정의하는 코드들, 그리고 widget폴더엔 두 가지 이상의 기능이 조합된 코드를 넣으려고 했다.

그런데 막상 진행하다보면 "어라? 이건 좀 기준이 애매한데..?" 하는 부분들이 꽤 많았다.

 

막연하다고 느낀 부분

데이터를 기준으로 기능과 도메인모델을 구분하는것은 당연히 어렵지 않았다.

하지만 UI가 포함되면 이야기가 조금 달라진다.

entities폴더에 존재하는 UI, feature폴더에 존재하는 UI, widget폴더에 존재하는 UI, 혹은 shared로 빼야하는 UI 등 기준을 세워보면 약간 애매하는 것이 느껴진다.

 

왜냐??

뭔가 우리는 의식하지 않아도 같이 쓰는 코드들은 가까운 곳에 두고 싶어한다.

흔히 이것을 '응집도'가 높은 코드라고 부른다.

하지만 이미 계층을 나눠놓은 코드에 UI들이 존재하는데 그것을 조합해서 사용하다보면 약간 가독성이 떨어지기도 한다.

(사실 내가 UI를 제대로 나누지 못해서 응집도가 낮아진것이다.. 이것은 아래에서 다시 이야기한다.)

 

우리가 일반적으로 알고있던 폴더구조인 pages, components 이런 방식으로 하게되면 화면 구성을 기준으로 폴더구조를 나누기 때문에 이 경우엔 응집도 자체는 굉장히 높다.

 

 

그렇다면 왜 굳이 FSD를 고집하느냐..?

또 다른 문제인 결합도가 존재하기 때문이다.

결합도란 코드가 다른 코드에 얼마나 의존하는지를 의미한다.

즉 결합도가 높아지면 상호 독립적인 코드가 아니라 응집된 코드들이 서로 붙어있고, 어떤 함수 하나를 수정하면 꽤 많은 곳에서 오류가 발생할 가능성이 높아진다.

결국 우리가 원하는 코드는 유지보수에 유리한 코드이기 때문에.. 어떤 함수 하나를 확장하거나 수정하는것에서 많이 자유로워져야한다.

그렇기 때문에 우리는 프로젝트 사이즈가 커질수록, 프로젝트 유지보수를 진행할수록 폴더구조에 대한 집착을 하게 되는 것이다.

 

어떻게 FSD는 결합도를 낮추나..?

핵심은 바로 계층별로 코드를 나누고, Feature단위로 코드를 분리하기 때문이다.

이 구조는 다음과 같은 이점을 가져온다.

1. 변경 범위가 좁아진다.

- 예를 들어 로그인 기능을 수정해도 features/login 내부만 건드리면 된다. 다른 기능에는 영향이 가지 않는다.

2. 의존성이 단방향으로 흐른다.

- features는 entities를 사용할 수 있지만, 반대로 entities가 features를 참조하지 않는 규칙으로 만들었기때문에 결합도가 낮아진다.

 

 

그렇다면 FSD의 응집도가 정말 낮을까..?

아니다. 이 부분에 있어서 지금 생각은 내가 UI를 잘 나누지 못한 부분이 크다.

전통적인 폴더구조는 "UI응집도"가 굉장히 높다. 즉 우리는 눈에 보이는 부분은 직관적으로 이해하기 쉽기 때문에 이러한 폴더구조에서 응집도가 굉장히 높다고 느낀다.

하지만 실제 데이터/도메인 관점에서 살펴보면 응집도가 굉장히 낮다.

 

FSD 구조에서는 응집도가 낮다고 보일 수 있지만..

실제로는 도메인과 기능 단위의 응집도가 굉장히 높아진다.

게다가 우리는 처음 작은 프로젝트를 만들때는 화면 단위로 만드는게 빠르지만, 유지보수는 기능 단위로 하는 경우가 많다.

따라서 해당 기능이 변경되었을 때 그와 관련된 UI도 계층적으로 파고 들어가기 쉽기 때문에 오히려 찾기 쉬워진다.

 

 

마무리하며..

이번 FSD를 처음 적용해보고 왜 해야하는지, 그리고 어떤 이점들이 있는지를 확실히 느낄 수 있었다.

하지만 위에 작성했던것처럼 나는 그 이점을 확실하게 가져오지 못한 부분도 있다. (UI 구분의 실패로 응집도가 낮아짐..)

이런 실수를 가져오는 이유는 나만의 확고한 기준이 없기 때문이라고 생각한다.

잘못된 방향이랄건 없다고 생각한다.

본인의 기준만 확실하다면 그 기준에 알맞게 코드를 분리/작성하고 기본 규칙 (계층간 코드 공유 방식)만 잘 지킨다면 아주 좋은 폴더구조라고 느껴진다.