Antigravity Agent
4.0 KiB
4.0 KiB
id: P-Reinforce-AUTO-912710 category: Unified confidence_score: 0.90 tags: [auto-reinforced] last_reinforced: 2026-04-20 github_commit: "[P-Reinforce] Continuous Worker - FSD (Feature-Sliced Design)"
FSD (Feature-Sliced Design)
📌 한 줄 통찰 (The Karpathy Summary)
FSD(Feature-Sliced Design)는 프론트엔드 개발에서 프로젝트의 복잡성을 줄이고 유지보수성과 확장성을 향상시키기 위해 고안된 아키텍처입니다. 기존의 역할 중심 폴더 구조가 가지는 한계를 극복하고자 '기능(Feature)'을 기준으로 코드를 분리하는 방식을 채택합니다. 기능 간의 결합도를 낮추고 각 기능이 독립적으로 관리되도록 설계되어, 특히 대규모 프로젝트를 관리하는 데 효과적인 방법론입니다.
📖 구조화된 지식 (Synthesized Content)
- 등장 배경 및 기존 구조의 한계: 프로젝트의 규모가 커지고 복잡해짐에 따라 기존의 역할(Role) 중심 폴더 구조만으로는 다양한 관심사와 요구 사항을 관리하는 데 명확한 한계가 발생했습니다. 컴포넌트 기반 개발 방식에서 역할별로 코드를 분리하더라도 결국 기능 간의 결합도가 높아지는 문제를 피하기 어려웠고, 이를 해결하기 위해 FSD가 등장하게 되었습니다.
- 기능(Feature) 중심의 분리: FSD 아키텍처는 이름 그대로 '기능'을 기준으로 코드를 분리합니다. 하나의 기능을 구현하는 데 필요한 모든 파일과 코드를 같은 폴더에 모아 단위별로 관리하는 것을 목표로 합니다. 이를 통해 각 기능이 독립적으로 동작하게 하며, 불필요한 결합도를 줄여 유지보수성을 극대화합니다.
- 문서화된 표준으로서의 의의: FSD가 완전히 새롭거나 전례 없던 아키텍처는 아닙니다. 대규모 프로젝트에서 기능 단위로 묶어 관리하는 것이 효율적이라는 인식은 이전부터 존재했습니다. 하지만 FSD는 이러한 구조를 공식적인 형태로 갖추고 '문서화된 표준'으로 제공한다는 점에서 큰 의의가 있습니다. 명확한 공식 문서를 통해 팀원 간의 멘탈 모델(Mental Model)을 통일하고 구조에 대한 합의를 이끌어내는 데 드는 커뮤니케이션 비용을 줄여줍니다.
- 적용 시 주의사항 (은탄환은 없다): 공식 설명에서도 명시하듯 FSD 구조는 주로 '규모가 큰 프로젝트'에 유용합니다. 모든 프로젝트에 완벽한 해결책이 되는 것은 아니며, 상황과 규모에 따라 기존의 역할 기반 폴더 구조나 다른 방식이 훨씬 더 효율적일 수 있습니다. 프로젝트의 성장 단계와 관심사의 변화에 따라 구조 역시 유연하게 진화해야 합니다.
⚠️ 모순 및 업데이트 (Contradictions & RL Update)
- 과거 데이터와의 충돌: 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
- 정책 변화: Design & Experience 분야의 자동 자산화 수행.
🔗 지식 연결 (Graph)
- Related Topics: 관심사의 분리 (Separation of Concerns), 단일 책임 원칙 (SRP), 컴포넌트 기반 아키텍처
- Projects/Contexts: 대규모 프론트엔드 프로젝트 아키텍처 및 폴더 구조 설계
- Contradictions/Notes: 소스에서는 FSD가 기능 간 결합도를 줄이고 유지보수를 돕는 훌륭한 표준이지만, 모든 상황에서 완벽한 정답은 아니라고 주장합니다. 프로젝트의 크기나 특성에 따라 오히려 기존의 단순한 폴더 구조가 더 적합할 수도 있으므로 프로젝트 상황에 맞는 유연한 폴더 구조 적용을 권장합니다.
Last updated: 2026-04-18