# [[Frontend App Development Architecture]]

## 📌 Brief Summary
프론트엔드 앱 개발 아키텍처는 확장성, 유지보수성, 성능을 고려하여 프론트엔드 시스템을 설계하고 구성하는 기반 프레임워크입니다 [1, 2]. 과거의 단순한 기술적 파일 기반 분리에서 벗어나, 비즈니스 로직과 기능(Feature)을 중심으로 모듈화하고 결합도를 낮추는 방향으로 아키텍처 패러다임이 전환되었습니다 [3, 4]. 일관된 폴더 구조, 상태 관리 패러다임, 클린 코드 원칙을 적용함으로써 애플리케이션이 복잡해지더라도 안정적으로 확장할 수 있도록 돕습니다 [5, 6].

## 📖 Core Content
* **모듈화와 폴더 구조 (Folder Structure):** 
  과거에는 컴포넌트, 훅, 스타일 등 파일 유형(Type)별로 코드를 나누는 방식을 사용했으나, 이는 애플리케이션이 커질수록 확장성이 떨어집니다 [3, 7]. 현대 프론트엔드 아키텍처는 도메인이나 기능별로 코드를 캡슐화하는 기능 기반(Feature-based) 구조를 채택합니다 [4, 8, 9]. 특히 **Feature-Sliced Design (FSD)**은 프론트엔드 아키텍처에 특화된 방법론으로, 코드를 레이어(app, pages, widgets, features, entities, shared)로 나누고 상위 레이어에서 하위 레이어로만 의존성을 가지도록 강제하여 순환 참조를 방지하고 아키텍처 규율을 유지합니다 [10-13].
* **소프트웨어 공학 원칙 (SOLID & Clean Code):** 
  React 컴포넌트에도 객체지향 설계의 SOLID 원칙이 적용됩니다. 컴포넌트는 단일 책임(SRP)을 가져야 하며 300줄 이상 길어지면 분리를 고려해야 하고, Composition을 통해 확장에는 열려 있고 수정에는 닫혀 있도록(OCP) 설계해야 합니다 [14-16]. 또한 DRY(반복하지 마라), KISS(단순하게 유지하라), YAGNI(필요할 때만 구현하라) 원칙을 통해 과도한 추상화를 피하고, 현재 요구사항에 집중해 예측 가능하고 디버깅하기 쉬운 코드를 작성해야 합니다 [17-19].
* **상태 관리의 파편화 (State Management):** 
  모든 상태를 거대한 단일 스토어(예: Redux)에 넣는 방식에서 벗어나, 목적에 맞는 도구로 분리하는 것이 2025년의 트렌드입니다 [20]. API에서 가져온 '서버 상태'는 캐싱과 동기화를 지원하는 TanStack Query(React Query)로 관리하며, '전역 애플리케이션 상태'는 리렌더링 최적화가 뛰어난 Zustand 같은 가벼운 라이브러리를 사용합니다 [20-22]. 
* **명명 규칙과 거버넌스 (Naming Conventions & Governance):** 
  대소문자 구분이 없는 OS(Windows, macOS) 환경에서 발생할 수 있는 CI/CD 빌드 오류를 방지하기 위해 파일과 폴더 이름은 `kebab-case`를 사용합니다 [23, 24]. 반면 React 컴포넌트는 `PascalCase`를, 일반 변수와 커스텀 훅은 `camelCase`를 사용하는 것이 업계 표준입니다 [23, 25-27]. 자동화된 거버넌스를 위해 ESLint, Prettier, Husky를 도입하여 커밋 전에 린팅과 포매팅을 강제하는 것이 좋습니다 [25].
* **성능 최적화 및 안정성 (Performance & Reliability):** 
  Vite와 같은 현대적인 번들러를 사용하여 서드파티 라이브러리를 분리(manualChunks)하고, `React.lazy`와 동적 임포트를 통한 코드 스플리팅을 적용하면 초기 번들 크기와 로딩 시간을 획기적으로 줄일 수 있습니다 [28-32]. 런타임 오류 시 애플리케이션 전체가 멈추는 백화현상을 막기 위해 'React Error Boundaries'를 도입해 실패를 국소화하고 대체 UI를 렌더링해야 합니다 [33-35]. 최근 안정화된 React Compiler는 `useMemo`나 `useCallback`과 같은 수동 메모이제이션을 자동화해 주어 클린 코드를 유지하면서 불필요한 렌더링을 방지해 줍니다 [36-39].

## 🔗 Knowledge Connections
- **Related Topics:** [[Feature-Sliced Design]], [[SOLID Principles]], [[State Management]], [[React Error Boundaries]], [[React Compiler]]
- **Projects/Contexts:** [[React Project Structure]], [[Performance Optimization]], [[Frontend Refactoring]]
- **Contradictions/Notes:** Context API는 별도의 외부 종속성 없이 상태를 공유할 수 있는 React 내장 도구이지만, 하나의 값이 변경될 때 구독 중인 모든 컴포넌트를 리렌더링하는 문제(Re-render storm)가 있습니다 [40, 41]. 따라서 잦은 업데이트가 필요한 상태에는 부적합하며, 이 경우 Zustand 등의 툴이 권장됩니다 [22, 42]. 또한 DRY(반복 지양) 원칙은 유용하지만, 코드를 너무 과도하게 추상화하면 직관성을 해쳐 오히려 KISS(단순성 유지) 원칙에 위배될 수 있으므로, 동일 패턴이 세 번 이상 반복될 때만 추상화하는 것이 이상적입니다 [17, 18, 43]. Atomic Design 모델은 UI 컴포넌트의 재사용성을 높이는 데에는 훌륭하지만 비즈니스 로직과 상태를 구조화하는 데는 부족하므로, 대규모 앱에서는 FSD 방법론이 더욱 유용합니다 [44-46].

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