1인 프로젝트 FSD(Feature-Sliced-Design) 도입기
최근 개인 프로젝트에서 FSD(Feature-Sliced-Design) 아키텍처를 도입해보고 있다. 이번 글에서는 FSD의 개념과 Next.js App Router 프로젝트에 적용하는 과정에서의 경험을 정리하고자 한다.
FSD란?
FSD(Feature-Sliced-Design)는 애플리케이션의 구조를 명확히 하기 위해 관심사를 기준으로 폴더와 파일을 계층적으로 나누는 아키텍처 설계 방식이다.
위 그림과 같은 Layer로 나누어지며, 각각의 Layer는 특정 관심사를 맡아 다음과 같은 역할을 한다.
app
: 애플리케이션 초기화 및 글로벌 설정
(삭제됨)process
: 여러 단계로 이루어진 페이지 처리pages
: 페이지 컴포넌트widgets
: 위젯 컴포넌트 (페이지에서 사용하는 재사용 가능한 구성 요소)features
: 기능별로 구성된 폴더 (독립적인 비즈니스 로직과 UI 포함)entities
: 엔터티 폴더 (도메인 모델, 상태 관리, API 통신 등)shared
: 공통 유틸리티, 컴포넌트, 훅 등
각 Layer들은 의존성을 갖는다(위 목록에서 내림차순으로). 즉 app에서는 shared를 가져올 수 있지만, shared에서는 app을 가져올 수 없다.
기존의 컴포넌트 기반 개발 방식에서는 역할별로 코드를 분리했지만, 기능 간의 결합도가 높아지는 문제를 완전히 피하기는 어려웠다. FSD 아키텍처는 이러한 결합도를 줄이고, 각 기능이 독립적으로 관리되도록 설계되었다.
Next.js App Router 프로젝트에 적용하기
├── app/ # Next.js의 App Router 폴더
├── src/
│ ├── app/ # FSD 패턴의 app 디렉토리
│ ├── views/ # FSD 패턴의 pages 디렉토리를 views로 변경
│ ├── widgets/
│ ├── (features/)
│ ├── (entities/)
│ ├── shared/
│── ...
-
app 폴더 분리
- Next.js의 App Router는 자체적으로
app
폴더를 사용한다. 이와 FSD의app
폴더를 구분하기 위해src/
를 기준으로 분리했다.
- Next.js의 App Router는 자체적으로
-
라우팅 폴더 충돌 방지를 위한 네이밍 수정
- App Router에서 앱라우팅은 기본적으로
/app
경로에서 이루어진다. 여기서/src/pages
경로를 사용하면 기존의 페이지 라우팅과 충돌되기 때문에, FSD 패턴의pages
->views
로 네이밍을 수정했다.
- App Router에서 앱라우팅은 기본적으로
-
개발 초기 단계, 폴더 구조 간소화
- 아직 개발 초기 단계로 코드 규모가 작기 때문에
features/
,entities/
폴더는 아직 작성하지 않았다. 화면 개발이 어느 정도 완료된 후 확장해 나갈 예정이다. - 개발 초기 단계에는 주로 화면을 구현하는데 초점이 맞춰지므로, 페이지(route)에 따라 화면을 나누고, 재사용이 필요한 컴포넌트는
shared/
폴더에 두기로 했다.
- 아직 개발 초기 단계로 코드 규모가 작기 때문에
-
화면 개발이 더 복잡해질 때
- 화면이 점점 복잡해지면, 페이지별로 상태 관리와 API 호출을 함께 묶어 관리한다.
-
화면 개발이 완료되면, 데이터(API 및 비즈니스 로직)를 주로 다루기
- 프로젝트의 막바지 단계에서는 화면을 만드는 것보다는 API와 비즈니스 로직의 처리가 주요 작업이 될 것이다. 이럴 때 필요한 것이 바로 도메인 데이터를 중심으로 정리하는 것이다.
- 즉, 화면을 그리는 뷰 컴포넌트와 데이터를 처리하는 비즈니스 로직을 각각 분리하고, 데이터 흐름을 명확하게 정의함으로써 데이터 관리와 화면 관리를 분리한다.
적용하면서 느낀 장단점
아직 개발 초기 단계로 장단점을 크게 느끼진 못했지만, 지금까지 느낀 장단점은 다음과 같다.
장점
- 편안해진 상태 관리 사용자 인증 상태(로그인 여부, 게시글 작성자 권한 등)와 같은 전역 상태 관리와 로직 분리가 명확하다.
단점
-
폴더 증가 관심사를 세분화하면서 폴더와 파일의 개수가 지나치게 많아지는 문제를 겪었다.
-
오버엔지니어링 프로젝트 규모에 비해 구조가 과도하게 복잡해질 수 있다는 점에서 고민이 있었다.
마무리
FSD는 초기 개발 과정에서는 폴더 구조의 복잡성 때문에 다소 부담스러울 수 있지만, 규모가 커질수록 효과가 커질 것으로 기대된다. 이번 프로젝트에서의 도입을 통해 FSD의 가능성을 체감할 수 있었고, 앞으로도 더 나은 활용 방안을 고민하며 적용해 나갈 계획이다.
References