FSD(Feature-Sliced Design)는 프론트엔드 프로젝트의 구조를 설계하기 위한 아키텍처 방법론이다. 2021년부터 러시아 개발자 커뮤니티를 중심으로 발전했으며, 현재는 전 세계적으로 채택되고 있는 프론트엔드 아키텍처 패턴이다.
FSD의 핵심은 코드를 계층(Layer), 슬라이스(Slice), 세그먼트(Segment)라는 3단계 구조로 조직화하는 것이다. 이를 통해 프로젝트가 커지더라도 코드의 위치를 예측 가능하게 만들고, 팀원 간 커뮤니케이션 비용을 줄이며, 기능 간 의존성을 명확하게 관리할 수 있다.
기존의 React 프로젝트들은 대부분 components/, utils/, hooks/, services/ 같은 기술적 역할 기반으로 폴더를 나눴다. 하지만 이 방식은 프로젝트가 커질수록 "이 기능과 관련된 코드가 여러 폴더에 흩어져 있다"는 문제가 발생한다. FSD는 이를 비즈니스 도메인 중심으로 재구성하여 해결한다.
전통적인 프론트엔드 프로젝트 구조는 대부분 이런 형태다:
src/
├── components/
├── hooks/
├── utils/
├── services/
├── store/
├── types/
└── styles/
이 구조는 작은 프로젝트에서는 직관적이지만, 규모가 커지면 다음과 같은 문제가 발생한다.
문제 1. 순환 의존성 (Circular Dependency)components 폴더 안의 컴포넌트들이 서로를 import하면서 복잡한 의존성 그래프가 만들어진다. A 컴포넌트가 B를 참조하고, B가 C를, C가 다시 A를 참조하는 상황이 생기면 디버깅이 매우 어려워진다.
문제 2. 코드의 역할과 위치 불일치
"로그인 기능"을 수정하려면 components/LoginForm.tsx, hooks/useAuth.ts, services/authService.ts, store/authSlice.ts 등 여러 폴더를 오가며 작업해야 한다. 관련 코드가 물리적으로 멀리 떨어져 있어 인지 부담이 크다.
문제 3. 재사용 가능한 것과 그렇지 않은 것의 구분 부재
모든 컴포넌트가 components/ 폴더에 섞여 있어, "이 컴포넌트를 다른 곳에서 써도 되는가?"를 판단하기 어렵다. 프로젝트 전역에서 쓰이는 Button과 특정 페이지에서만 쓰이는 UserProfileCard가 같은 위치에 있으면 혼란스럽다.