[G1-Sync] Manual knowledge update

10_Wiki/Topics/AI_and_ML/대규모 프론트엔드 애플리케이션.md

@@ -2,135 +2,31 @@
 id: wiki-2026-0508-대규모-프론트엔드-애플리케이션
 title: 대규모 프론트엔드 애플리케이션
 category: 10_Wiki/Topics
-status: needs_review
-canonical_id: self
+status: duplicate
+canonical_id: large-frontend-projects
+duplicate_of: "[[Large_Frontend_Projects]]"
 aliases: []
-duplicate_of: none
 source_trust_level: A
-confidence_score: 0.92
-tags: [uncategorized]
-raw_sources: []
-last_reinforced: 2026-05-08
+confidence_score: 0.9
+verification_status: redirected
+tags: [duplicate, frontend, application]
+last_reinforced: 2026-05-10
 github_commit: pending
-inferred_by: Claude Opus 4.7 (auto-normalize 2026-05-08)
-tech_stack:
-  language: unspecified
-  framework: unspecified
 ---
 
-# [[대규모 프론트엔드 애플리케이션|대규모 프론트엔드 애플리케이션]]
+# 대규모 프론트엔드 애플리케이션
 
-## 📌 한 줄 통찰 (The Karpathy Summary)
-대규모 프론트엔드 애플리케이션은 단순한 스크립트 실행을 넘어 확장성, 유지보수성, 고성능을 요구하는 고도로 정교한 분산 소프트웨어 시스템입니다. 비즈니스 로직과 UI의 분리, 명확한 상태 소유권, 엄격한 폴더 구조(Feature-Sliced Design 등)를 통해 아키텍처의 붕괴를 방지합니다. 또한, 코드 스플리팅, 자동 메모이제이션, 세분화된 상태 관리 도구를 활용하여 최적의 렌더링 성능과 사용자 경험을 유지하는 것이 핵심입니다.
+> **이 문서는 [[Large_Frontend_Projects]] 의 중복본입니다.** Canonical 문서로 redirect.
 
-## 📖 구조화된 지식 (Synthesized Content)
-*   **아키텍처 및 폴더 구조 (Architecture & Folder Structure)**
-    *   과거의 파일 타입 기반(MVC 등) 폴더 구조는 규모가 커질수록 로직이 파편화되는 한계가 있습니다. 대규모 앱에서는 비즈니스 기능별로 코드를 구성하는 **기능 기반(Feature-based)** 또는 **FSD(Feature-Sliced Design)** 아키텍처가 표준으로 자리 잡았습니다 [1-13].
-    *   FSD는 앱을 공유(shared), 엔티티(entities), 기능(features), 위젯(widgets), 페이지(pages), 앱(app) 등의 계층으로 나누고, **단방향 의존성 규칙**(하위 계층만 참조 가능)과 **Public API 규칙**(index.ts를 통한 캡슐화)을 강제하여 결합도를 낮춥니다 [6, 9, 10, 14, 15].
-*   **상태 관리의 파편화 (Fragmentation of Global State)**
-    *   거대한 단일 스토어(Monolithic Redux) 대신, 데이터 유형에 따라 최적의 도구를 선택합니다. 로컬 상태는 `useState`, 전역 애플리케이션 상태는 `Zustand`나 `Jotai`, 서버(API) 상태는 `TanStack Query`를 사용하여 캐싱 및 동기화를 처리합니다 [16-24].
-    *   특히 Context API는 값이 변할 때마다 모든 구독 컴포넌트를 리렌더링하는 '브로드캐스트' 방식이므로 정적 데이터(테마 등)에 적합하며, 자주 변경되는 동적 상태는 선택자(Selector) 패턴으로 불필요한 리렌더링을 방지하는 Zustand 등이 유리합니다 [16, 17, 25-28].
-*   **성능 최적화 (Performance Optimization)**
-    *   **빌드/런타임 최적화:** Vite와 Rollup을 활용하여 자주 변경되지 않는 벤더 라이브러리(React 등)를 `manualChunks`로 분리하여 캐시 효율을 높이고, `React.lazy`와 `Suspense`를 통해 라우트 또는 컴포넌트 단위의 코드 스플리팅을 구현합니다 [29-37].
-    *   **렌더링 성능:** React 19/2025 생태계에서는 수동 메모이제이션(React.memo, useMemo)의 한계를 극복하기 위해 **React Compiler**를 도입하여 빌드 타임에 자동으로 렌더링 최적화를 수행합니다. 대량의 리스트 데이터는 가상화(Virtualization) 기술을 통해 DOM 비대화를 막습니다 [30-32, 38-44].
-*   **복원력 및 디버깅 (Resilience & Debugging)**
-    *   런타임 에러로 인한 '백지 화면(White screen of death)'을 방지하기 위해 **에러 바운더리(Error Boundaries)**를 대시보드나 서드파티 위젯 등 불안정한 UI 섹션에 전략적으로 배치하여 Fallback UI를 제공합니다 [45-53].
-    *   메모리 누수(Detached DOM nodes 등)는 성능 저하의 주원인이므로 Chrome DevTools의 Heap Snapshot 및 Allocation Timeline을 통해 추적하며, 프로덕션 환경에서는 Sentry, LogRocket, Datadog 등의 가시성(Observability) 도구로 모니터링합니다 [54-63].
-*   **클린 코드 및 거버넌스 (Clean Code & Governance)**
-    *   React의 함수형 컴포넌트에도 SOLID 원칙(단일 책임 원칙, 개방-폐쇄 원칙 등), DRY, KISS, YAGNI 원칙이 적용됩니다. 컴포넌트는 단일 책임을 가져야 하며 과도한 추상화는 지양해야 합니다 [64-69].
-    *   운영체제 간 호환성 및 빌드 오류 방지를 위해 파일 및 폴더명은 `kebab-case`, 컴포넌트는 `PascalCase` 사용을 표준화하며, ESLint, Prettier, Husky를 통해 CI/CD 파이프라인에서 아키텍처 경계와 코드 품질을 자동 강제합니다 [70-73].
+## 핵심 요약 (specialization aspects)
+- 매 application-level 관점 — runtime concerns, state management, code splitting.
+- 매 SaaS / enterprise dashboard 의 typical context.
 
-## 🔗 지식 연결 (Graph)
-### Related Concepts
-- [[Feature-Sliced Design (FSD)|Feature-Sliced Design (FSD)]]
-  - 연결 이유: 대규모 프론트엔드 프로젝트의 폴더 구조와 모듈 의존성을 통제하는 핵심 아키텍처 방법론입니다.
-  - 이 개념을 통해 더 깊게 이해할 수 있는 부분: 비즈니스 도메인과 UI를 어떻게 계층적으로 분리하고, 순환 참조 및 강한 결합을 어떻게 방지할 수 있는지 이해할 수 있습니다.
-- [[상태 관리(State Management)|상태 관리 (State Management)]]
-  - 연결 이유: 대규모 앱에서는 전역 상태, 서버 상태, 로컬 상태를 명확히 분리해야 확장 및 성능 유지가 가능합니다.
-  - 이 개념을 통해 더 깊게 이해할 수 있는 부분: Context API의 성능적 한계(리렌더링 폭풍)와 Zustand의 Selector 패턴, TanStack Query를 통한 서버 상태 캐싱 원리를 이해할 수 있습니다.
-- [[성능 최적화(Performance Optimization)|성능 최적화 (Performance Optimization)]]
-  - 연결 이유: 대규모 코드베이스는 필연적으로 번들 크기 증가와 렌더링 병목을 초래하므로 이를 제어하는 기술이 필수적입니다.
-  - 이 개념을 통해 더 깊게 이해할 수 있는 부분: React Compiler의 자동화된 메모이제이션 원리, Vite의 manualChunks를 통한 번들 분할, React.lazy 기반의 코드 스플리팅 적용 방식을 파악할 수 있습니다.
-- 에러 바운더리 (Error Boundaries)
-  - 연결 이유: 컴포넌트 하나의 오류가 전체 앱의 크래시로 이어지지 않게 막아주는 대규모 시스템의 필수 안전망입니다.
-  - 이 개념을 통해 더 깊게 이해할 수 있는 부분: 컴포넌트 트리 내에서 에러를 격리하는 원리와 런타임 에러를 우아하게 처리(Graceful degradation)하는 방법을 배울 수 있습니다.
-- [[메모리 누수(Memory Leaks)|메모리 누수 (Memory Leaks)]]
-  - 연결 이유: 앱 사용 시간이 길어질수록 성능을 심각하게 저하시키는 숨은 원인입니다.
-  - 이 개념을 통해 더 깊게 이해할 수 있는 부분: 클로저(Closure)나 Detached DOM에 의해 가비지 컬렉터가 메모리를 회수하지 못하는 구조적 원인과 DevTools를 활용한 디버깅 기법을 이해할 수 있습니다.
+## 🔗 Graph
+- 부모: [[Large_Frontend_Projects]] (canonical)
 
-### Deeper Research Questions
-- FSD(Feature-Sliced Design) 도입 시 '인증(Auth)'이나 '라우팅'과 같은 Cross-cutting concern(공통 관심사)은 계층(Layer) 구조의 어느 부분에 배치하고 어떻게 관리하는 것이 가장 적합한가?
-- React Compiler가 자동 메모이제이션을 수행할 때, 서드파티 라이브러리(예: 불안정한 객체 참조를 반환하는 커스텀 훅)와의 호환성 충돌 문제를 해결하기 위한 구체적 방안은 무엇인가?
-- 대규모 리스트 데이터를 렌더링할 때 Virtualization(윈도윙) 기술이 DOM 노드 증가를 막는 원리는 무엇이며, 이 과정에서 `key` 프롭(prop)이 성능에 미치는 정확한 영향은 무엇인가?
-- 프로덕션 환경의 프론트엔드 모니터링(Sentry, Datadog 등)이 제공하는 세션 리플레이(Session Replay) 기능이 개발자의 디버깅에 어떻게 기여하며, 이때 발생할 수 있는 민감 데이터 유출 및 번들 사이즈 증가라는 트레이드오프는 어떻게 극복하는가?
-- Zustand, Jotai와 같은 최신 상태 관리 라이브러리가 기존의 Redux나 Context API와 비교하여 동적/실시간 렌더링 최적화(예: 리렌더링 스킵)를 내부적으로 어떻게 구현하고 있는가?
-
-### Practical Application Contexts
-- **Implementation:** 파일과 폴더 네이밍 규칙(파일: kebab-case, 컴포넌트: PascalCase)을 통일하고, 300줄이 넘어가는 컴포넌트는 단일 책임 원칙(SRP)에 따라 더 작은 훅(Hook)과 서브 컴포넌트로 리팩토링합니다.
-- **System Design:** 프로젝트 설계 시 폴더 구조를 기술 스택(components, hooks) 기반이 아닌 비즈니스 도메인(features/auth, features/dashboard 등) 기반으로 구성하여 각 모듈의 캡슐화를 보장합니다.
-- **Operation / Maintenance:** 개별 서드파티 위젯이나 불안정한 UI 파트에 Error Boundary를 씌워 메인 서비스의 동작을 보장하며, Memory Profiler를 사용해 Detached DOM node 등 메모리 누수 요인을 정기적으로 감사(Audit)합니다.
-- **Learning Path:** 리액트 핵심 원리(렌더링 트리거 이해) → 폴더 구조/아키텍처(FSD) 설계 → 상태 관리 도구 비교 및 도입 → 웹 성능 지표(Core Web Vitals) 및 번들러(Vite) 최적화 도구 체득의 순서로 학습을 고도화합니다.
-- **My Project Relevance:** 팀 단위의 협업 시 ESLint, Prettier, Husky를 도입해 아키텍처 규칙(다른 Feature에 직접 접근 금지 등)을 자동 강제하고, 코드 리뷰 시 일관된 아키텍처 원칙을 기준으로 삼을 수 있습니다.
-
-### Adjacent Topics
-- [[마이크로 프론트엔드 (Micro Frontends)|마이크로 프론트엔드 (Micro-Frontends)]]
-  - 확장 방향: 단일 저장소(Monorepo) 및 모듈화의 한계를 넘어, 초대형 엔터프라이즈 환경에서 여러 팀이 프론트엔드를 독립적으로 배포하고 운영하기 위한 런타임 통합 아키텍처로 지식을 확장합니다.
-- 시각적 회귀 테스트 (Visual Regression Testing)
-  - 확장 방향: Storybook을 활용한 컴포넌트 고립 개발을 넘어서, Happo, Chromatic 등의 도구를 통해 코드 변경이 UI나 접근성(Accessibility)에 의도치 않은 파괴적 영향을 미쳤는지 자동 검증하는 QA 고도화 영역으로 확장합니다.
-
----
-*Last updated: 2026-04-30*
-
-## 🤖 LLM 활용 힌트 (How to Use This Knowledge)
-
-**언제 이 지식을 쓰는가:**
-- *(TODO)*
-
-**언제 쓰면 안 되는가:**
-- *(TODO)*
-
-## 🧪 검증 상태 (Validation)
-
-- **정보 상태:** needs_review
-- **출처 신뢰도:** A
-- **검토 이유:** *(P-Reinforce Phase 1 자동 정규화. 본문 검증 필요.)*
-
-## 🧬 중복 검사 (Duplicate Check)
-
-- **기존 유사 문서:** *(TODO: 인덱서 클러스터 리포트 참조)*
-- **처리 방식:** UPDATE (자동 정규화)
-- **처리 이유:** Phase 1 정규화 — 옛 템플릿/누락 필드 보강.
-
-## ⚠️ 모순 및 업데이트 (Contradictions & Updates)
-
-- **과거 데이터와의 충돌:** 없음
-- **정책 변화:** 없음
-
-## 🕓 변경 이력 (Changelog)
-
-| 날짜 | 변경 내용 | 처리 방식 | 신뢰도 |
-|------|-----------|-----------|--------|
-| 2026-05-08 | P-Reinforce Phase 1 정규화 (frontmatter + 헤더 표준화) | UPDATE | A |
-
-## 💻 코드 패턴 (Code Patterns)
-
-**패턴 1:** *(TODO: 이 프로젝트 컨벤션 반영한 구조 스켈레톤)*
-
-```text
-# TODO
-```
-
-## 🤔 의사결정 기준 (Decision Criteria)
-
-**선택 A를 써야 할 때:**
-- *(TODO)*
-
-**선택 B를 써야 할 때:**
-- *(TODO)*
-
-**기본값:**
-> *(TODO)*
-
-## ❌ 안티패턴 (Anti-Patterns)
-
-- **[안티패턴]:** *(TODO: 무엇을 하면 안 되는가 + 이유 + 대신 무엇을)*
+## 🕓 변경 이력
+| 날짜 | 변경 |
+|---|---|
+| 2026-05-08 | Phase 1 |
+| 2026-05-10 | 중복 처리 — canonical 문서로 redirect |