[G1-Sync] Manual knowledge update

10_Wiki/Topics/Visual_Effects/Graphics & Performance/마이크로 프론트엔드.md

@@ -1,68 +1,32 @@
 ---
 id: wiki-2026-0508-마이크로-프론트엔드
-title: 마이크로 프론트엔드
-category: 10_Wiki/Topics_Art
-status: needs_review
-canonical_id: self
-aliases: [P-REINFORCE-AUTO-E74AFF]
-duplicate_of: none
+title: "마이크로 프론트엔드"
+category: "10_Wiki/Topics/Visual_Effects/Graphics & Performance"
+status: duplicate
+canonical_id: wiki-2026-0508-micro-frontends
+duplicate_of: "[[Micro Frontends]]"
+aliases: []
 source_trust_level: A
 confidence_score: 0.9
-tags: [auto-reinforced]
-raw_sources: []
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - 마이크로 프론트엔드"
-inferred_by: Claude Opus 4.7 (auto-normalize 2026-05-08)
+verification_status: redirected
+tags: [duplicate, micro-frontend]
+last_reinforced: 2026-05-10
+github_commit: pending
 ---
 
-# [[마이크로 프론트엔드]]
+# 마이크로 프론트엔드
 
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 마이크로 프론트엔드는 거대하고 복잡한 프론트엔드 애플리케이션을 백엔드의 마이크로서비스처럼 작고 독립적인 여러 조각으로 나누어 개발하는 아키텍처 접근 방식입니다 [1]. 이 방식을 통해 각 비즈니스 기능별로 전담 팀이 구성되어 선호하는 기술 스택을 활용해 독립적으로 모듈을 개발, 테스트 및 배포할 수 있습니다 [1-3]. 전통적인 모놀리식 프론트엔드 구조의 한계를 극복하고 팀의 자율성, 애플리케이션의 확장성 및 유지보수성을 향상시키는 데 목적이 있습니다 [2, 4].
+> **이 문서는 [[Micro Frontends]] 의 중복본입니다.** Canonical 문서로 redirect.
 
-## 📖 구조화된 지식 (Synthesized Content)
-- **동작 원리 및 아키텍처 패턴:** 호스트 애플리케이션이 런타임 통합(웹 컴포넌트, iframe 등), 동적 로딩, 모듈 페더레이션, 서버 사이드 합성 등을 활용하여 개별 마이크로 프론트엔드들을 로드하고 결합합니다 [5]. 아키텍처 구현 시에는 각 모듈이 특정 라우트를 담당하는 라우트 기반 합성이나, 단일 페이지 내에 위젯처럼 임베딩되는 컴포넌트 기반 합성 등을 적용할 수 있습니다 [6].
-- **독립성과 통신 방식:** 각 팀의 코드와 스타일은 충돌하지 않도록 철저히 격리되어야 합니다 [7]. 모듈 간의 통신은 독립성을 해치지 않도록 커스텀 이벤트, 공유 상태 스토어, URL 매개변수 등을 활용하는 가벼운 통신 규약(Contract)을 통해 이루어져야 하며, 전역 변수 사용은 피해야 합니다 [7-9].
-- **도입의 이점:** 대규모 웹 애플리케이션에서 기능 중심의 모듈화를 통해 팀 간의 기술적 간섭을 차단하고 개발 속도를 높일 수 있습니다 [3, 10]. 또한, 시스템 전체를 중단시키지 않고도 레거시 코드의 점진적인 업그레이드가 가능합니다 [4].
-- **도전 과제 및 한계점:** 분산된 코드베이스와 빌드 파이프라인 관리로 인해 시스템 복잡성이 크게 증가합니다 [8]. 여러 모듈과 자바스크립트 번들이 로드되면서 초기 로딩 성능에 오버헤드가 발생할 수 있으며, 공유 의존성의 버전 불일치나 CSS 스타일 누수와 같은 문제도 흔히 발생합니다 [3, 8].
-- **적용 시 주의사항:** 이 아키텍처는 데브옵스(DevOps) 기반의 자동화 파이프라인과 모니터링 체계가 필수적입니다 [9]. 프로젝트의 규모가 작거나, 기능들이 서로 강하게 결합되어 있거나, 적절한 데브옵스 지원이 없는 환경에서는 오버헤드가 커지므로 도입을 피해야 합니다 [11].
+## 핵심 요약
+- 독립 배포 가능한 frontend module들 (Module Federation, Single-SPA).
+- 팀 자율성 ↑, 통합 복잡도 ↑ trade-off.
 
-## ⚠️ 모순 및 업데이트 (Contradictions & Updates)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Graphics & Performance 분야의 자동 자산화 수행.
+## 🔗 Graph
+- 부모: [[Micro Frontends]] (canonical)
 
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[마이크로서비스 아키텍처]], [[모놀리식 프론트엔드]], [[관심사의 분리(SoC)]], [[모듈 페더레이션(Module Federation)]], [[웹 컴포넌트(Web Components)]]
-- **Projects/Contexts:** [[Spotify의 스쿼드(Squad) 모델 및 웹 플레이어]], [[Netflix의 대시보드 및 도구 현대화]], [[Zalando와 Amazon의 이커머스 모듈화]]
-- **Contradictions/Notes:** 마이크로 프론트엔드는 팀 간 의존성을 줄이고 자율성과 확장성을 높여주지만, 동시에 초기 로딩 성능 저하 및 빌드/배포 파이프라인의 복잡성 증가라는 뚜렷한 트레이드오프(Trade-off)를 수반합니다 [3, 8]. 소규모 프로젝트의 경우 오히려 관리 부담이 가중될 수 있어 권장되지 않습니다 [11].
-
----
-*Last updated: 2026-04-18*
-- Raw Source: [[00_Raw/2026-04-20/마이크로 프론트엔드.md]]
----
-
-## 🤖 LLM 활용 힌트 (How to Use This Knowledge)
-
-**언제 이 지식을 쓰는가:**
-- *(TODO)*
-
-**언제 쓰면 안 되는가:**
-- *(TODO)*
-
-## 🧪 검증 상태 (Validation)
-
-- **정보 상태:** needs_review
-- **출처 신뢰도:** A
-- **검토 이유:** *(P-Reinforce Phase 1 자동 정규화. 본문 검증 필요.)*
-
-## 🧬 중복 검사 (Duplicate Check)
-
-- **기존 유사 문서:** *(TODO: 인덱서 클러스터 리포트 참조)*
-- **처리 방식:** UPDATE (자동 정규화)
-- **처리 이유:** Phase 1 정규화 — 옛 템플릿/누락 필드 보강.
-
-## 🕓 변경 이력 (Changelog)
-
-| 날짜 | 변경 내용 | 처리 방식 | 신뢰도 |
-|------|-----------|-----------|--------|
-| 2026-05-08 | P-Reinforce Phase 1 정규화 (frontmatter + 헤더 표준화) | UPDATE | A |
+## 🕓 변경 이력
+| 날짜 | 변경 |
+|---|---|
+| 2026-05-08 | Phase 1 |
+| 2026-05-10 | 중복 처리 — canonical 문서로 redirect |