리액트 프로젝트에 FSD 아키텍처 적용. 이 구성이 맞을까요?

Question

안녕하세요.  
현재 진행 중인 리액트 프로젝트에서 유지보수성과 확장성에 어려움을 느껴 폴더 구조를 Feature-Sliced Design(FSD) 아키텍처 기반으로 전면 리팩토링했습니다.

기존에는 `components/`, `pages/`, `apis/` 등 기능과 역할이 섞인 구조로 되어 있어, 코드의 위치가 불분명하고 협업에 어려움이 있었습니다. 이를 해결하고자 다양한 아키텍처를 조사한 끝에, FSD의 레이어 개념(Layers)에 맞춰 다음과 같은 방식으로 구조를 정리했습니다.

- `app/`: `App.js`, `index.js` 등 프로젝트 진입점과 글로벌 설정 파일을 포함  
- ` entities/`: `User`, `Article`, `CodingZone` 등 주요 도메인의 데이터 모델과 API 연동 담당  
- `features/`: 로그인, 게시글 작성, 코딩존 출석 등 각 기능별로 모듈화하고, 필요한 경우 `hooks/` 등의 내부 디렉토리로 세분화  
- `pages/`: 라우팅과 연결된 실제 페이지 컴포넌트 관리 (예: `CreatePage`, `EditPage` 등)  
- `widgets/`: 재사용 가능한 독립 UI 요소들 (예: `Footer`, `Navbar`, `Pagination` 등)  
- `shared/`: 공통 API, 유틸, 모달 컴포넌트 등 여러 기능에서 공유되는 요소들을 배치

기능 중심의 구조로 바꾸면서, 각 요소의 역할이 명확해지고 코드 탐색 및 유지보수가 훨씬 쉬워졌습니다. 현재는 복잡한 비즈니스 로직이 없어 `processes/` 레이어는 생략했지만, 추후 워크플로우가 필요한 기능이 생긴다면 도입할 계획입니다.

제가 구성한 이 폴더 구조와 레이어 분리가 실제 FSD 아키텍처 가이드에 부합하는 방향인지, 혹시 보완하거나 개선할 부분이 있다면 조언을 구하고 싶습니다.

자세한 내용은 블로그에 정리해 두었습니다.  
👉 [https://juncci.tistory.com/4](https://juncci.tistory.com/4)

읽어주셔서 감사합니다!

상현 · Answer

저도 FSD를 참고한 아키텍쳐를 사용하고 있는데요. 제가 이해한 이 아키텍쳐의 논점은 크게 2가지입니다.

- 단방향 참조
- 래핑 바운더리

현재의 FSD 공식 문서에는 단방향 참조에 대한 이야기가 사라져있습니다만, shared > features >  widgets | pages 의 순으로 뒤가 앞을 참조할 순 있지만 앞이 뒤를 참조하지 못하도록 하는 위계 구조가 있었습니다. 참조의 방향이 정해져있기 때문에 헤매면서 다닐 필요가 없어지고 운영의 효율성을 아키텍쳐 레벨에서 잡으려던 시도를 한 것이죠.

또한 작업자가 정의하는 패킹시킬 모듈이 어디까지 추상화되어야 하는 것인가 하는 이야기입니다. 정의한 기능을 DRY 하게 사용하기 위해서는 독립적인 구성 - 제로 커플링 - 을 전제해야 하기에 features의 슬라이스나 세그먼트들은 해당 기능 내에서 다시 세부적으로 디커플링을 시킵니다. 결국은 이를 모아서 쓸 수 있는 래핑된 모듈이 필요하죠. 또 영역, 혹은 그보다 큰 페이지의 도메인에 따라 기능이 조합, 확장되는 경우에도 래핑이 필요합니다. 그래서 이 래핑된 모듈은 다시 재사용 여부에 따라 pages에 있어야 할 수도, features에 있어야 할 수 있습니다. 또는 shared에 있을 수도 있죠. 간단히 말하면 래핑의 기준을 순수하게 기능에 두느냐, 데이터나 영역의 특성을 부여하느냐에 따라 달라진다는 것이죠.

이 2가지 점에서 보았을 때 다음의 사례와 같아지면 FSD 아키텍쳐의 방향성을 충족할  겁니다.

shared에 API 인터페이스가 정의되어 있고, 
entities에 이를 이용한 데이터 도메인별 API가 정의되어 있고, 
features에 이를 이용한 로직과 view에 넘겨줄 UI 로직이 정의되어 있고,
pages에서 이것들을 참조하여 페이지 도메인에 맞게 정립된 컴포넌트가 정의되어 있습니다.

그리고 본문에는 없지만 app 이하에는 글로벌 스타일과 라우터가 있어야 합니다.