최근 스위프 11기에 참여하면서 함께 개발을 하게 된 프론트엔드 개발자분께 프로젝트는 FSD 아키텍처로 가는 게 좋아요! 라는 말을 처음 들었습니다.
FSD 아키텍처 도대체 왜 쓰는 걸까?
프론트엔드 개발자가 알아야 할 현대 구조 설계법
FSD…? 처음 듣는 순간 머릿속에 물음표가 수백 개 떠올랐지만 알고 보니 이게 요즘 프론트엔드에서 아주 핫한 구조라는 사실이 드러났습니다.
그래서 오늘은 처음 보는 사람도 바로 이해할 수 있게 FSD 아키텍처가 뭔지, 왜 쓰는지, 최신 트렌드는 어떤지 한 번에 정리해보려고 합니다.
프론트엔드 구조 왜 이렇게 복잡해질까?
프로젝트가 커지면 이런 경험 누구나 해본 적 있을 겁니다.
- “이 파일 왜 여기 있어?”
- “이 컴포넌트 어디서 쓰는 거지?”
- “로직이 여기저기 흩어져 있는데…?”
처음엔 귀엽던 폴더 구조가 몇 달 뒤엔 ‘스토리만 남기고 무너져버린 폐허’가 되기 십상입니다.
이 문제를 해결하기 위해 등장한 구조가 바로 FSD(Feature-Sliced Design) 입니다.
한 줄로 말하면
“프로젝트가 커져도 정신 나가지 않도록 도와주는 구조 설계법”
입니다.
FSD 아키텍처 한 방에 이해하기
FSD는 프로젝트를 5개의 큰 레이어로 나눕니다.
app
pages
features
entities
shared
이 구조의 핵심 규칙은 딱 하나입니다.
위에서 아래로는 참조 가능 아래에서 위로는 참조 불가.
즉 pages는 entities를 가져다 쓸 수 있지만 entities는 pages를 몰라야 합니다.
프론트엔드가 점점 커지는 상황에서 이 규칙 하나만으로도 코드 간섭이 엄청나게 줄어듭니다.
각 레이어 이렇게 이해하면 쉽다
1) app — “프로젝트의 인트로 씬”
앱이 동작하기 위해 반드시 필요한 전역 요소들만 모여있습니다.
- main.tsx
- 전역 Provider
- 라우터 설정
- 글로벌 스타일
영화로 치면 인트로 화면 같은 존재입니다. 여기서 프로젝트의 모든 분위기가 시작됩니다.
2) pages — “각 씬(Scene)을 담당하는 주인공들”
로그인 페이지, 마이페이지, 상품 상세 페이지처럼 하나의 화면을 보여주는 단위를 담당합니다.
대부분의 비즈니스 로직은 pages에서 이뤄집니다.
예를 들어:
- 폼 제출
- 버튼 클릭 이벤트
- 페이지 전용 UI
“그 페이지에서만 의미 있는 일”은 전부 여기서 처리합니다.
3) features — “여러 화면에서 재사용되는 기능 모음집”
프로젝트를 하다 보면 "어? 이 기능 저 페이지에서도 쓰네?" 이런 기능들이 생깁니다.
그럴 때 features에 모읍니다.
예:
- 공통 댓글 입력 UI
- 필터 기능
- 공용 form 컴포넌트
단 요즘 트렌드는 features를 과하게 만들지 않는 방향입니다. 필요할 때만 씁시다.
4) entities — “데이터의 원형(도메인)을 관리하는 곳”
프로젝트의 데이터는 여기에서 태어납니다.
- API 호출
- 모델 정의
- mockData
- 타입/스키마
쉽게 말해
“백엔드에서 온 데이터를 가장 처음으로 받는 관문”
이라고 보면 됩니다.
5) shared — “모든 곳에서 공용으로 활용되는 재료 창고”
프로젝트 전체에서 사용할 수 있는 것들만 넣습니다.
- 디자인 시스템 컴포넌트
- 공통 hooks
- api client
- util 함수들
한마디로 “모두가 공유하는 공통 자원 창고”입니다.
왜 FSD가 좋은가?
1) 구조가 커져도 안정적이다
레이어끼리 역할이 명확해서 “여기 넣어야 하나 저기 넣어야 하나” 고민할 일이 없습니다.
2) 기능 간 커플링을 강제로 줄인다
하위 레이어는 상위 레이어를 모릅니다. 의존성 역전, 사이드 이펙트 이런 문제들이 자연스럽게 줄어듭니다.
3) 협업이 쉬워진다
각자 담당하는 영역이 확실하기 때문에 작업 간섭이 거의 발생하지 않습니다.
4. FSD 세그먼트: 내부 폴더는 5개로 통일
각 레이어 안에서는 아래 세그먼트만 사용합니다.
ui
api
model
lib
config
이 규칙이 좋은 이유는 간단합니다. “파일을 어디에 넣어야 하죠…?” 하는 고민이 사라집니다.
- 화면 → ui
- 서버 통신 → api
- 타입/모델 → model
- 유틸 코드 → lib
- mockData/환경값 → config
이 정도만 기억하면 어떤 프로젝트든 관리가 쉬워집니다.
최신 FSD 트렌드: “features 최소화 · pages 중심 구조”
초기 FSD 문서에서는 features를 적극적으로 쓰라고 했지만 최근에는 방향이 조금 바뀌었습니다.
요즘 트렌드는 pages 중심 도메인 구조입니다.
- pages에서 대부분의 UI와 로직을 해결하고
- 여러 페이지에서 공유해야 할 때만 features를 만듭니다
- entities는 데이터를 다루는 곳으로 단순하게 유지합니다
이게 실제 유지보수에서도 가장 효율적이고 협업 시에도 복잡함이 줄어듭니다.
정리: 프론트엔드 구조를 지키는 가장 실용적인 방법
FSD는 어렵게 보이지만 결국 핵심은 단순합니다.
- 프로젝트를 app → pages → features → entities → shared 순으로 나눕니다.
- 상위 레이어만 하위 레이어를 사용합니다.
- 각 레이어 안에는 ui/api/model/lib/config만 둡니다.
- pages 중심으로 도메인을 나누고 공유 기능만 features로 보냅니다.
이 규칙만 따라도 프로젝트가 커져도 유지보수가 훨씬 쉬워지고 새 팀원이 와도 구조를 빠르게 이해할 수 있습니다.
FSD는 “깔끔한 프론트엔드 구조를 지키는 가장 실용적인 설계법”입니다.