# [[기능 중심 아키텍처(Feature-Driven Architecture)|기능 중심 아키텍처(Feature-Driven Architecture]]

## 📌 Brief Summary
기능 중심 아키텍처(Feature-Driven [[Architecture|Architecture]])는 프로젝트를 파일의 유형(컴포넌트, 훅, 스타일 등)이 아닌 비즈니스 기능(Feature)이나 도메인을 기준으로 코드를 그룹화하는 프론트엔드 구조 설계 방식이다 [1-3]. 이 방식에서는 특정 기능과 관련된 컴포넌트, 비즈니스 로직, 스타일시트가 하나의 기능별 디렉터리 내에 함께 병치(co-located)된다 [1, 4]. 이를 통해 코드의 모듈성과 캡슐화를 높이고, 대규모 애플리케이션이 확장됨에 따라 발생할 수 있는 복잡성을 제어하여 유지보수성을 극대화한다 [1, 2, 5].

## 📖 Core Content
- **구조적 특징 및 모듈성:** 기능 중심 아키텍처에서는 코드를 앱의 실제 도메인(예: `market-data`, `user-profile`, `auth` 등)을 기반으로 `features/` 디렉터리에 분리하여 관리한다 [6]. 이러한 모듈성 덕분에 애플리케이션에서 특정 기능이 제거될 때 관련된 스타일과 코드도 자동으로 정리되므로, 레거시 코드베이스에 사용되지 않는 유령 스타일(ghost styles)이 축적되는 것을 방지할 수 있다 [4].
- **관심사의 분리와 캡슐화:** 라우트 파일(예: [[Next.js|Next.js]]의 `app/` 디렉터리)은 라우팅과 레이아웃 생성 등 최소한의 역할만 수행하도록 유지하고, 실제 비즈니스 로직과 상태 관리는 기능 폴더로 이동시킨다 [1, 6]. 이를 통해 버그가 발생했을 때 거대한 전역 컴포넌트 폴더를 뒤질 필요 없이 특정 기능 폴더 내부만 확인하면 되는 캡슐화(Encapsulation) 이점을 얻을 수 있다 [6].
- **[[Feature-Sliced Design|Feature-Sliced Design]] (FSD) 연계:** 전반적인 프론트엔드 아키텍처를 다루는 Feature-Sliced Design (FSD) 방법론은 애플리케이션을 여러 계층(layer)으로 구성하고 각 계층의 엄격한 의존성 규칙과 명확한 모듈 경계를 정의한다 [7]. FSD를 통해 프로젝트 구조를 관리하고 그 내부에서 BEM 또는 [[CSS Modules|CSS Modules]]를 활용하여 CSS 구조를 캡슐화하면 기술 부채를 크게 줄이는 강력하고 유지보수하기 쉬운 아키텍처가 형성된다 [7, 8].
- **확장성 및 팀 협업:** 코드가 비즈니스 기능별로 그룹화되어 있으므로 여러 팀이 동시에 작업하는 병렬 워크플로우(Parallel team workflows)가 가능해진다 [3]. 또한, 각 기능에 대한 코드 소유권(Ownership)이 명확해져 장기적인 유지보수와 리팩토링을 훨씬 안전하게 수행할 수 있다 [3].

## 🔗 Knowledge Connections
- **Related Topics:** [[Feature-Sliced Design (FSD)|Feature-Sliced Design (FSD]], Domain-Driven Architecture, BEM (Block Element Modifier), [[CSS Modules|CSS Modules]]
- **Projects/Contexts:** 대규모 프론트엔드 프로젝트의 아키텍처 설계, 대형 엔터프라이즈 환경의 유지보수 가능한 스타일 시스템 엔지니어링, 확장 가능한 Next.js 프로젝트 구조 수립 [2, 4, 5].
- **Contradictions/Notes:** 많은 개발자들이 컴포넌트, 훅, 로직 등을 같은 파일 유형끼리 묶는 전역 폴더 방식을 사용하지만, 애플리케이션이 성장하여 대시보드나 복잡한 사용자 흐름을 다루게 되면 이 방식은 관리가 불가능(unmanageable)해지므로 대규모 프로젝트에서는 기능 중심 아키텍처가 전역 스타일 디렉터리보다 우수하다고 평가받는다 [2, 5, 9].

---
*Last updated: 2026-04-26*