feat: Wiki 지식 자산 업데이트 - UX Scenarios, Frontend, Game Design, Topics 추가 [2026-05-08]

10_Wiki/Topics/Frontend/One-way_Data_Flow.md

@@ -1,14 +1,26 @@
 ---
+id: wiki-2026-0508-one-way-data-flow
+title: One way Data Flow
 category: Frontend
+status: needs_review
+canonical_id: self
+aliases: []
+duplicate_of: none
+source_trust_level: A
+confidence_score: 0.92
 tags: [auto-wikified, technical-documentation, frontend]
-title: One-way Data Flow
-description: "단방향 데이터 흐름(One-way Data Flow)은 상태(State), 뷰(View), 그리고 액션(Actions)이라는 세 가지 핵심 요소로 구성된 독립적인 상태 관리 개념입니다 [1]."
-last_updated: 2026-05-04
+raw_sources: []
+last_reinforced: 2026-05-08
+github_commit: pending
+inferred_by: Claude Opus 4.7 (auto-normalize 2026-05-08)
+tech_stack:
+  language: unspecified
+  framework: unspecified
 ---
 
 # One-way Data Flow
 
-## 📌 Brief Summary
+## 📌 한 줄 통찰 (The Karpathy Summary)
 단방향 데이터 흐름(One-way Data Flow)은 상태(State), 뷰(View), 그리고 액션(Actions)이라는 세 가지 핵심 요소로 구성된 독립적인 상태 관리 개념입니다 [1]. 앱을 구동하는 '진실의 원천(Source of truth)'인 상태가 선언적으로 뷰에 매핑되고, 뷰에서의 사용자 입력에 반응하여 액션이 다시 상태를 변경하는 단방향의 사이클을 형성합니다 [1]. 그러나 여러 컴포넌트가 동일한 상태를 공유해야 하는 대규모 애플리케이션 환경에서는 프로프 드릴링(Prop Drilling) 등 구조적 한계에 부딪힐 수 있는 모델이기도 합니다 [2].
 
 ## 📖 Core 소 Content
@@ -18,13 +30,12 @@ last_updated: 2026-05-04
 - **취약한 상태 동기화 패턴의 위험성**: 상태 동기화를 위해 템플릿 참조(Template refs)를 통해 부모/자식 인스턴스에 직접 접근하거나, 이밋(Emitted) 이벤트를 통해 상태의 복사본을 변경하려 시도할 수 있습니다 [3]. 하지만 이러한 패턴은 코드를 쉽게 깨지게 만들고 장기적인 유지보수를 매우 어렵게 합니다 [3].
 - **글로벌 싱글톤(Global Singleton) 패턴으로의 진화**: 단방향 흐름의 한계를 해결하는 직관적이고 단순한 해결책은 공유 상태를 컴포넌트 외부로 추출하여 글로벌 싱글톤으로 관리하는 것입니다 [3]. 이 패턴을 적용하면 전체 컴포넌트 트리가 하나의 거대한 '뷰' 역할을 하게 되며, 트리의 깊이와 무관하게 어떤 컴포넌트든 상태에 접근하거나 액션을 트리거할 수 있게 됩니다 [3].
 
-## ⚖️ Trade-offs & Caveats
+## ⚠️ 모순 및 업데이트 (Contradictions & Updates)
 단방향 데이터 흐름 원칙에 따라 상태를 공유하기 위해 부모에서 자식으로 상태를 계속 전달(Props)하는 방식을 고수할 경우, 계층이 깊어질수록 코드가 비효율적으로 변하는 '프로프 드릴링(Prop Drilling)' 부작용이 발생합니다 [2]. 이를 우회하기 위해 인스턴스에 직접 접근하거나 이벤트를 통해 여러 상태 복사본을 변경하는 대안을 택하면, 결합도가 높아져 유지보수 불가능한 취약한 코드를 생산하게 되는 반대급부가 따릅니다 [3]. 
 
 이러한 제약 사항을 해결하기 위해 상태를 글로벌 싱글톤으로 추출할 수 있으나, 이 방식 역시 **서버 사이드 렌더링(SSR)** 환경과 결합될 경우 치명적인 제약을 갖습니다 [4, 5]. SSR 환경에서는 단일 싱글톤 스토어가 여러 클라이언트의 요청(Requests) 간에 공유되어 의도치 않은 데이터 유출이 발생할 수 있습니다 [4, 5]. 또한, 컴포넌트들이 외부의 전역 상태를 임의로 직접 수정(Mutate)하도록 방치하면 상태 관리의 유지보수성을 잃게 되므로, 반드시 의도를 명확하게 표현하는 메서드(Actions)를 통해서만 상태 변경 로직을 중앙집중화하여 제어해야 한다는 설계적 책임이 따릅니다 [6].
 
-## 🔗 Knowledge Connections
-
+## 🔗 지식 연결 (Graph)
 ### Related Concepts
 
 #### [구조적 한계 및 부작용 (아키텍처/기반 기술)]
@@ -64,4 +75,61 @@ last_updated: 2026-05-04
   - 확장 방향: 공유 상태(Shared State) 처리의 복잡성을 시스템 수준에서 캡슐화하는 전역 상태 관리 라이브러리의 동작 원리와 이들이 개발자 도구(DevTools)나 서버 사이드 렌더링(SSR) 환경과 결합되는 방식에 대해 학습할 수 있습니다 [4, 5, 8].
 
 ---
-*Last updated: 2026-05-03*
+*Last updated: 2026-05-03*
+
+## 📖 구조화된 지식 (Synthesized Content)
+
+**추출된 패턴:**
+> *(TODO)*
+
+**세부 내용:**
+- *(TODO)*
+
+## 🤖 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 |
+
+## 💻 코드 패턴 (Code Patterns)
+
+**패턴 1:** *(TODO: 이 프로젝트 컨벤션 반영한 구조 스켈레톤)*
+
+```text
+# TODO
+```
+
+## 🤔 의사결정 기준 (Decision Criteria)
+
+**선택 A를 써야 할 때:**
+- *(TODO)*
+
+**선택 B를 써야 할 때:**
+- *(TODO)*
+
+**기본값:**
+> *(TODO)*
+
+## ❌ 안티패턴 (Anti-Patterns)
+
+- **[안티패턴]:** *(TODO: 무엇을 하면 안 되는가 + 이유 + 대신 무엇을)*