2nd/01_Archive/2026-04-20/Feature-Sliced Design.md

---
id: P-REINFORCE-AUTO-925C5C
category: "10_Wiki/💡 Topics/Design & Experience"
confidence_score: 0.90
tags: [auto-reinforced]
last_reinforced: 2026-04-20
github_commit: "[P-Reinforce] Continuous Worker - Feature-Sliced Design"
---

# [[Feature-Sliced Design|Feature-Sliced Design]]

## 📌 한 줄 통찰 (The Karpathy Summary)
> Feature-Sliced Design(FSD)은 프론트엔드 개발에서 복잡성을 줄이고 유지보수성과 확장성을 향상시키기 위해 등장한 아키텍처 방법론입니다. 기존의 역할 중심 폴더 및 코드 분리 방식의 한계를 극복하고자 기능(Feature)을 기준으로 코드를 분리하고 관련된 파일들을 한데 모아 관리하는 것을 목표로 합니다. 완전히 새로운 개념은 아니지만 공식적인 문서화와 표준을 제공하여 대규모 프로젝트에서 팀원 간의 멘탈 모델을 맞추고 합의를 이끌어내는 데 특히 유용합니다.

## 📖 구조화된 지식 (Synthesized Content)
- **등장 배경:** 프론트엔드 프로젝트의 규모가 커지면서 기존 역할별 폴더 구조(예: components, api, pages 등)만으로는 기능 간의 결합도가 높아지고, 관련된 파일들이 흩어져 코드를 관리하고 파악하기 어려워지는 한계가 명확해졌습니다. FSD는 이러한 문제를 해결하기 위해 기능을 중심으로 코드를 분리하는 대안으로 등장했습니다.
- **핵심 구조와 원리:** 하나의 기능 단위에 필요한 모든 파일들을 같은 폴더에 모아 관리합니다. 이를 통해 기능 간의 결합도를 줄이고, 각 기능이 독립적으로 관리될 수 있도록 설계되었습니다.
- **주요 장점:** FSD 이전에도 비슷한 구조적 제안은 있었으나, FSD의 가장 큰 의의는 **공식적인 형태를 갖추고 문서화되어 있다는 점**입니다. 폴더 구조 변경에 따르는 커뮤니케이션 비용을 줄여주고, 팀원 간의 멘탈 모델을 일치시키며 합의를 이끌어내기 용이하게 만들어 줍니다.
- **적용 시 주의사항 및 한계점:** 
  - FSD 공식 설명에서도 명시하듯 이 구조는 **프로젝트의 규모가 클 때** 유용합니다.
  - 모든 프로젝트에 완벽한 해결책이 되는 것은 아니며, 규모가 작은 프로젝트 등 상황에 따라서는 기존의 역할 기반 폴더 구조가 더 적합할 수 있습니다.
  - 절대적인 정답으로 삼기보다는, 프로젝트의 성장과 변화하는 관심사에 맞추어 폴더 구조를 진화시켜 나가는 하나의 접근법으로 활용해야 합니다.

## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
- **정책 변화:** Design & Experience 분야의 자동 자산화 수행.

## 🔗 지식 연결 (Graph)
- **Related Topics:** [[관심사의 분리(Separation of Concerns)|관심사의 분리(Separation of Concerns)]], 멘탈 모델
- **Projects/Contexts:** [[대규모 프론트엔드 프로젝트|대규모 프론트엔드 프로젝트]]
- **Contradictions/Notes:** FSD 아키텍처는 대규모 프로젝트의 복잡성 관리에 유용하지만, 모든 프로젝트에서 완벽한 해결책은 아니며 상황과 규모에 따라 오히려 기존의 폴더 구조가 더 효율적일 수도 있습니다.

---
*Last updated: 2026-04-18*
- Raw Source: 00_Raw/2026-04-20/Feature-Sliced Design.md
---