안녕하세요. 요청하신 유튜브 영상(https://www.youtube.com/watch?v=GHIVdWueets)의의) 핵심 내용을 고등학생도 쉽게 이해할 수 있는 예시를 포함하여 상세히 설명해 드리겠습니다.
💡 쉽고 간단한 설명: Clean FSD란 무엇인가?
이 영상은 웹 개발의 구조를 더 깔끔하고 효율적으로 만들기 위한 새로운 설계 방식인 **'클린 FSD(Clean Feature-Sliced Design)'**에 대해 설명하고 있습니다.
고등학생을 위한 쉬운 예시: 학교 프로젝트 파일 정리 📂
여러분들이 여러 명이 함께 학교 프로젝트를 진행한다고 상상해 보세요.
- 기존 FSD의 문제점 (경계가 모호할 때):
- 프로젝트 폴더 안에 '자료실'과 '활동'이라는 폴더가 있는데, '자료실'에 새로운 설문지 파일을 만드는 작업 파일과 이미 완성된 보고서를 보는 파일이 마구 섞여 있습니다.
- 새로운 팀원이 왔을 때, 어떤 폴더에서 무엇을 해야 할지 경계가 모호해서 실수하기 쉽고, 파일을 찾거나 수정하는 데 시간이 오래 걸립니다. (이것이 기존 FSD에서 Features와 Entities의 역할이 모호했던 상황과 유사합니다.)
- 클린 FSD의 해결책 (경계를 명확히):
- 클린 FSD는 폴더의 역할을 딱 두 가지로 명확하게 나눕니다.
- Features (쓰기/Write): '변경하는 작업' 전용 폴더입니다. (예: 새 설문지 작성, 퀴즈 정답 제출, 보고서 업데이트 등)
- Entities (읽기/Read): '단순히 보여주는 작업' 전용 폴더입니다. (예: 퀴즈 목록 조회, 완성된 보고서 열람, 설문 결과 보기 등)
- 이렇게 쓰기와 읽기를 명확히 분리하면, 팀원들은 **"무언가 바꾸려면 Features 폴더로, 그냥 보려면 Entities 폴더로 가면 돼"**라는 명확한 규칙을 따르게 됩니다. 이는 코딩에서 AI와 협업할 때 AI에게 명확한 명령(의도와 경계)을 전달할 수 있게 되어 작업 효율을 극대화합니다.
1. 영상의 핵심 내용 세 줄 요약
- Clean FSD는 기존 FSD의 경계 모호성을 극복하고자 Features를 '쓰기(Write)' 전용으로, Entities를 '읽기(Read)' 전용으로 명확히 구분한 새로운 설계 원칙입니다.
- 이 원칙은 백엔드 개념인 CQRS 패턴을 차용한 것이며, **넥스트JS(Next.js)**를 활용하여 읽기는 **RSC(React Server Component)**로, 쓰기는 폼 태그+서버 액션으로 구현하는 서버 퍼스트(Server-First) 전략과 연결됩니다.
- 결론적으로, Clean FSD는 개발의 의도와 경계를 명확화하여 AI와의 협업 효율을 높이고, UI부터 DB 조작까지 담당하는 **온전한 기능 단위 개발(풀스택)**을 가능하게 합니다.
2. 타임라인 별 핵심 내용 정리
| 시간대 | 핵심 내용 요약 |
| [00:27] | 기존 FSD의 한계: Features와 Entities 레이어의 구분이 모호하고, Features에 너무 많은 코드가 몰리는 문제가 있었습니다. |
| [00:40] | Clean FSD의 등장: 기존 한계를 극복하기 위해 의도와 경계를 명확히 한 새로운 FSD 설계가 등장했습니다. |
| [01:53] | 경계 명확화 기준: Features는 쓰기(Write), Entities는 **읽기(Read)**에 관한 코드를 위치시키자는 기준을 도입했습니다. |
| [02:33] | CQRS 패턴 차용: 쓰기와 읽기의 책임을 나누는 백엔드 아키텍처 패턴인 CQRS (Command Query Responsibility Segregation) 개념을 차용했습니다. |
| [04:05] | 퀴즈 앱 데이터 구조 예시: 퀴즈 앱의 데이터 모델링을 예로 들어, **쓰기(업데이트/확장)**에는 테이블을 분리하는 방식이, **읽기(페이지 조회)**에는 데이터를 포함하는 방식(JSON)이 각각 더 수월함을 설명하며 쓰기/읽기의 구조가 다르다는 점을 강조했습니다. |
| [09:19] | FSD 세그먼트 적용: 읽기/쓰기 기준을 FSD의 세부 세그먼트(API/UI)에 적용하여, Entities 하위의 UI는 뷰(View) 컴포넌트(읽기)로, Features 하위의 UI는 폼/버튼(유저 인터랙션, 쓰기)으로 명확히 구분했습니다. |
| [13:19] | 리액트의 미래 방향성: 리액트팀이 폼과 서버 액션을 활용하여 서버 퍼스트(Server-First) 전략을 지향하고 있으며, 클라이언트 JS 비율을 낮추려는 개발 방향성을 제시했습니다. |
| [15:53] | 읽기/쓰기 구현체: 읽기 동작은 **RSC(React Server Component)**로, 쓰기 동작은 폼 태그와 서버 액션 조합으로 구현하는 것이 가장 효율적이며, 이를 구현하기에 가장 적합한 프레임워크가 **넥스트JS(Next.js)**임을 설명했습니다. |
| [17:50] | 온전한 기능 단위 개발: 풀스택 환경이 가능해지면서 UI부터 DB 조작까지 담당하는 온전한 기능 단위 개발이 가능해짐을 설명했습니다. |
| [20:21] | 최종 목표: 효율적인 협업: Clean FSD와 Next.js 전략의 궁극적인 목적은 AI와의 효율적인 협업을 가능하게 하는 것이며, 명확한 **경로와 함수 이름(엔지니어를 위한 바이브 코딩)**을 지정하여 수정 작업을 최소화합니다. |
3. 구체적이고 전문적인 설명
Clean FSD의 핵심 개념: 쓰기(Write)와 읽기(Read)의 분리
Clean FSD의 기반이 되는 원칙은 CQRS(Command Query Responsibility Segregation) 패턴에서 왔습니다.
- Command (쓰기): 데이터를 **변경(Update, Create, Delete)**하는 역할로, FSD에서는 Features 레이어가 담당합니다. DB의 조작이 필요한 영역입니다.
- Query (읽기): 데이터를 **조회(Get)**하는 역할로, FSD에서는 Entities 레이어가 담당합니다. 단순 뷰(View)를 보여주는 영역입니다.
웹 개발 트렌드와의 연결: Server-First 전략
Clean FSD는 단순히 폴더 구조만 개선하는 것을 넘어, 최신 웹 개발 트렌드인 서버 퍼스트(Server-First) 전략을 구현하기 위한 최적의 구조입니다.
| 구분 | Clean FSD 역할 | Next.js/RSC 구현체 | 특징 |
| 읽기 (Read) | Entities | RSC (React Server Component) | 서버에서 컴포넌트를 실행하여 데이터를 읽고 HTML을 생성하여 전송. 클라이언트 측 JS를 최소화하고 빠른 로딩을 가능하게 합니다. |
| 쓰기 (Write) | Features | 폼 태그 + 서버 액션 | 순수 HTML 폼과 서버에서 실행되는 서버 액션을 조합하여 쓰기 동작을 처리. 클라이언트 측 상태 관리 없이 DB 조작까지 서버에서 담당하여 개발을 단순화합니다. |
자주 혼동하거나 실수하는 정보
- FSD와 Clean FSD의 혼동:
- 혼동: "FSD만으로도 충분히 역할 분리가 되지 않나요?"
- 팩트: 기존 FSD는 Features(비즈니스 로직)와 Entities(도메인 엔티티)의 구분이 모호하여 시간이 지날수록 코드가 복잡해지는 한계가 있었습니다. Clean FSD는 여기에 '쓰기'와 '읽기'라는 명확한 기준을 추가하여 모호함을 해소하고, 복잡한 코드가 Features에 몰리는 문제를 방지했습니다.
- RSC와 Server Actions의 오해:
- 혼동: "RSC와 서버 액션은 넥스트JS에서만 가능한 기능 아닌가요?"
- 팩트: 이 개념들은 리액트팀이 제시한 미래 개발 방향성입니다. 리액트만으로도 구현이 가능하지만, 넥스트JS는 RSC를 기본으로 제공하고 폼, 캐싱 등 서버 퍼스트 전략을 쉽게 구현할 수 있는 환경을 제공해 주기 때문에 가장 수월한 구현체로 활용되는 것입니다.
✅ 반드시 알아야 할 내용과 핵심 내용
| 구분 | 핵심 내용 |
| Clean FSD 목적 | 의도와 경계를 명확히 하여 AI와의 효율적인 협업 환경을 구축하는 것. |
| 개발 구조 | 읽기는 Entities와 RSC로, 쓰기는 Features와 폼/서버 액션으로 분리하여 서버 퍼스트 전략 구현. |
| 궁극적 의미 | UI부터 DB 조작까지 하나의 기능으로 처리하는 온전한 풀스택 기능 단위 개발을 가능하게 합니다. |
📋 최종 요약 및 정리 (장단점 포함)
| 구분 | 핵심 개념 | 장점 (Pros) | 단점/한계 (Cons) | 핵심 내용 |
| Clean FSD | **쓰기(Features)**와 **읽기(Entities)**를 명확하게 구분한 FSD 확장 설계. (CQRS 기반) | 1. 경계 명확화로 코드 복잡성 감소. 2. AI 협업 효율 극대화. | 1. 초기 설계 및 학습 비용이 있음. 2. 소규모 프로젝트에서는 과할 수 있음. | O |
| 쓰기 구현 | 넥스트JS의 폼 태그와 서버 액션 활용. | 클라이언트 JS를 최소화하며, DB 조작까지 포함하는 온전한 기능 구현이 용이함. | 서버 환경 설정 및 이해가 필수적임. | O |
| 읽기 구현 | 넥스트JS의 RSC (React Server Component) 활용. | 빠른 초기 로딩 속도와 향상된 SEO 효과. | 클라이언트 컴포넌트와의 데이터 공유 방식에 대한 이해가 필요함. | O |
| 개발 목표 | 서버 퍼스트 전략 기반의 온전한 기능 단위 풀스택 개발. | 프론트/백엔드 경계가 허물어져 개발 생산성 향상. | 풀스택 개발 역량을 요구하며, 백엔드 지식이 필요함. | O |
* 본 문서는 google gemini 로 작성되었습니다.
댓글