최근 스위프 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는 “깔끔한 프론트엔드 구조를 지키는 가장 실용적인 설계법”이다.
