# [[Large-scale Application Architecture]]

## 📌 Brief Summary
대규모 애플리케이션 아키텍처(Large-scale Application Architecture)는 단순한 스크립트를 넘어 복잡한 분산 소프트웨어 시스템으로 진화한 현대 프론트엔드를 지탱하기 위한 엄격한 구조적 기반입니다 [1]. 이는 유지보수성, 확장성, 성능을 극대화하기 위해 코드를 기술적 역할이 아닌 비즈니스 기능(Feature)과 도메인 중심으로 구성하는 것을 핵심으로 합니다 [1-3]. 대표적으로 Feature-Sliced Design(FSD)과 같은 방법론을 통해 명확한 경계와 캡슐화, 단방향 의존성을 강제하여 시스템의 예측 가능한 성장을 가능하게 합니다 [4-7].

## 📖 Core Content
* **아키텍처의 필요성과 실패 요인**: 리액트 시스템이 대규모로 성장할 때 마주하는 가장 흔한 실패 원인은 렌더링 속도 등의 기술적 요인이 아닌 '아키텍처의 붕괴'입니다 [8, 9]. 비즈니스 로직이 UI 컴포넌트로 새어나가거나, 상태 소유권이 중복되고 불분명해지면, 하나의 변경 사항이 시스템 전체에 영향을 미치는 숨겨진 결합(Hidden coupling)을 생성하여 개발 속도를 급격히 저하시킵니다 [8-10].
* **기능 기반 구조와 Feature-Sliced Design (FSD)**: 폴더를 컴포넌트, 훅 등 기술적 파일 유형별로 분리하는 방식은 소규모 앱에서는 직관적이나 대규모 환경에서는 확장성이 매우 떨어집니다 [2, 11-13]. 이에 대한 해결책으로 비즈니스 기능과 사용자 흐름을 중심으로 코드를 구성하는 FSD가 도입되었습니다 [3, 4, 14]. FSD는 프로젝트를 `app`, `pages`, `widgets`, `features`, `entities`, `shared`의 6가지 계층(Layer)으로 엄격히 나눕니다 [5, 7]. 특히 상위 계층은 하위 계층에 의존할 수 있지만 하위는 상위에 의존할 수 없는 '단방향 의존성'과 명시적인 Public API(`index.ts`)를 강제하여 모듈 간의 안정적인 격리를 보장합니다 [5, 6, 15, 16].
* **상태 관리(State Management)의 파편화 및 전문화**: 대규모 환경에서는 상태를 단일 스토어에 넣기보다 용도에 맞게 분리하여 관리합니다 [17]. 서버 API로부터 가져오는 데이터(서버 상태)는 TanStack Query를 통해 캐싱과 동기화를 처리하고, 테마와 같은 정적이고 전역적인 상태는 Context API를, 알림이나 장바구니처럼 빈번하게 변하는 동적 애플리케이션 상태는 Zustand를 사용하는 것이 권장됩니다 [18-22]. 단, 개발자가 10명 이상인 대규모 팀에서 얽혀있는 복잡한 상태를 다루고 일관된 패턴을 강제해야 할 때는 Redux가 산업 표준으로서 효과적입니다 [23-25].
* **클린 코드와 설계 원칙 (SOLID & DRY)**: 기능형 리액트 컴포넌트에서도 소프트웨어 공학 원칙은 필수적입니다 [16, 26]. 단일 책임 원칙(SRP)에 따라 컴포넌트는 한 가지의 역할만 해야 하며, 300줄이 넘어간다면 여러 개의 작은 컴포넌트로 분리해야 합니다 [27]. 중복 로직은 커스텀 훅으로 추출하여 DRY 원칙을 지키되, 과도한 추상화보다는 직관적이고 단순하게 유지하는 KISS, YAGNI 원칙의 균형이 필요합니다 [28-30].
* **성능 최적화 및 빌드 엔지니어링 (Performance & Build)**: 거대한 자바스크립트 번들은 초기 로드를 지연시킵니다 [31-33]. Vite 등의 번들러를 이용해 `manualChunks`로 무거운 벤더 라이브러리(React core 등)를 분리하고, `React.lazy`와 `Suspense`를 결합해 라우트나 기능 수준의 코드 스플리팅을 적용하여 성능을 높여야 합니다 [34-38]. 또한 2025년의 React Compiler는 빌드 타임에 자동으로 메모이제이션을 적용하여 수동 성능 최적화의 번거로움을 줄여줍니다 [34, 39-41].
* **복원력 (Resilience) 및 모니터링**: 대규모 앱은 단일 컴포넌트의 런타임 오류가 전체 화면을 백지화하는 것을 막기 위해 Error Boundaries를 주요 위젯이나 불안정한 섹션마다 전략적으로 배치해야 합니다 [42-45]. 또한 프로덕션 레벨에서는 Sentry, LogRocket, Datadog과 같은 도구를 통해 사용자의 에러 발생 맥락(Session Replay)과 메모리 누수 등을 추적하여 디버깅을 고도화합니다 [45-48].

## 🔗 Knowledge Connections
- **Related Topics:** [[Feature-Sliced Design]], [[State Management]], [[SOLID Principles]], [[Performance Optimization]], [[Clean Code]], [[Error Boundaries]]
- **Projects/Contexts:** [[React]], [[Next.js]], [[Vite]], [[Bulletproof React]]
- **Contradictions/Notes:** 
  - FSD 아키텍처의 적용에 대해 "모든 코드를 처음부터 세밀하게 슬라이싱하는 것보다 모놀리식으로 시작한 뒤 기능의 경계가 명확해졌을 때 분리하는 것이 낫다"는 상반된 의견이 존재합니다. 처음부터 무리하게 분할하면 3개면 충분할 조각이 수백 개로 나뉘는 부작용이 발생할 수 있습니다 [49]. 
  - FSD의 `shared` 계층에 대해서도, 조직이 커짐에 따라 관리가 통제 불능이 되고 버그의 온상이 되어 시스템 변경을 오히려 어렵게 만들 수 있다는 실무적 비판이 있습니다 [50].

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