diff --git a/.DS_Store b/.DS_Store
new file mode 100644
index 00000000..a2bcbc2a
Binary files /dev/null and b/.DS_Store differ
diff --git a/AI & Biology/Artificial Life (ALife).md b/AI & Biology/Artificial Life (ALife).md
deleted file mode 100644
index ea68a000..00000000
--- a/AI & Biology/Artificial Life (ALife).md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-7C3E9E
-category: "[[10_Wiki/💡 Topics/AI & Biology]]"
-confidence_score: 0.95
-tags: []
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Mega Batch 2 - Wikified Artificial Life (ALife)"
----
-
-# [[Artificial Life (ALife)]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 작업 중
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 지식 자산화 및 기존 네트워크 연동 단계.
-- **정책 변화:** AI & Biology 카테고리의 전문성 확보 및 링크 밀도 최적화.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Artificial Life (ALife).md]]
----
diff --git a/AI & Ethics/Algorithmic Bias in Art.md b/AI & Ethics/Algorithmic Bias in Art.md
deleted file mode 100644
index d45c0b7d..00000000
--- a/AI & Ethics/Algorithmic Bias in Art.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-DEC2D9
-category: "[[10_Wiki/💡 Topics/AI & Ethics]]"
-confidence_score: 0.95
-tags: []
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Batch 11 - Wikified Algorithmic Bias in Art"
----
-
-# [[Algorithmic Bias in Art]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 작업 중
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 신규 지식 카테고리화 및 연결성 강화.
-- **정책 변화:** AI & Ethics 분야의 지식 자산 보호 및 네트워크 확장.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Algorithmic Bias in Art.md]]
----
diff --git a/AI & Ethics/Algorithmic Decision Making.md b/AI & Ethics/Algorithmic Decision Making.md
deleted file mode 100644
index 4c83e582..00000000
--- a/AI & Ethics/Algorithmic Decision Making.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-E80494
-category: "[[10_Wiki/💡 Topics/AI & Ethics]]"
-confidence_score: 0.95
-tags: []
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Batch 11 - Wikified Algorithmic Decision Making"
----
-
-# [[Algorithmic Decision Making]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 작업 중
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 신규 지식 카테고리화 및 연결성 강화.
-- **정책 변화:** AI & Ethics 분야의 지식 자산 보호 및 네트워크 확장.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Algorithmic Decision Making.md]]
----
diff --git a/AI & Ethics/Artificial-Intelligence-Explainability.md b/AI & Ethics/Artificial-Intelligence-Explainability.md
deleted file mode 100644
index c4e361d0..00000000
--- a/AI & Ethics/Artificial-Intelligence-Explainability.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-935E0A
-category: "[[10_Wiki/💡 Topics/AI & Ethics]]"
-confidence_score: 0.95
-tags: []
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Mega Batch 2 - Wikified Artificial-Intelligence-Explainability"
----
-
-# [[Artificial-Intelligence-Explainability]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 작업 중
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 지식 자산화 및 기존 네트워크 연동 단계.
-- **정책 변화:** AI & Ethics 카테고리의 전문성 확보 및 링크 밀도 최적화.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Artificial-Intelligence-Explainability.md]]
----
diff --git a/AI & Games/AlphaZero Strategy.md b/AI & Games/AlphaZero Strategy.md
deleted file mode 100644
index 06feed44..00000000
--- a/AI & Games/AlphaZero Strategy.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-5267ED
-category: "[[10_Wiki/💡 Topics/AI & Games]]"
-confidence_score: 0.95
-tags: []
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Mega Batch - Wikified AlphaZero Strategy"
----
-
-# [[AlphaZero Strategy]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 핵심 요약 작업 진행 중
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 상세 구성 진행 중
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 지식 자산화 및 기존 네트워크 연동 단계.
-- **정책 변화:** AI & Games 카테고리의 전문성 확보 및 링크 밀도 최적화.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/AlphaZero Strategy.md]]
----
diff --git a/AI & ML MLOps/Concept Drift (개념 드리프트, 모델 지식의 부패).md b/AI & ML MLOps/Concept Drift (개념 드리프트, 모델 지식의 부패).md
deleted file mode 100644
index d9244c6d..00000000
--- a/AI & ML MLOps/Concept Drift (개념 드리프트, 모델 지식의 부패).md	
+++ /dev/null
@@ -1,32 +0,0 @@
----
-id: P-REINFORCE-AI-047
-category: "[[10_Wiki/💡 Topics/AI & ML MLOps]]"
-confidence_score: 0.96
-tags: [ai, machine learning, mlops, data science]
-last_reinforced: 2026-06-XX
-github_commit: "[P-Reinforce] Processed Concept Drift (개념 드리프트)."
----
-
-# [[Concept Drift (개념 드리프트)]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 시간이 지남에 따라 데이터의 통계적 특성이나 생성 메커니즘 자체가 변화하여, 이전에 학습된 AI 모델의 예측 정확도와 신뢰도가 점진적으로 떨어지는 현상이다.
-
-## 📖 구조화된 지식 (Synthesized Content)
-- **정의:** 머신러닝 시스템이 배포되고 운영되는 환경에서 발생하는 데이터 분포의 변화를 의미한다. 이는 단순한 '데이터 부족' 이상의 근본적인 모델 성능 저하 문제다.
-- **유형 및 원인:**
-    1. **Covariate Shift (공변량 드리프트):** 입력 데이터 $P(X)$가 변하는 경우. (예: 특정 계절에만 발생하는 트래픽 패턴 변화).
-    2. **Concept Drift (개념 드리프트):** 실제 데이터 생성 과정 자체가 변하여, 같은 입력 $X$에 대한 레이블 $Y$의 조건부 확률 $P(Y|X)$가 변하는 경우. (예: 사용자의 구매 행동 패턴이 시대에 따라 근본적으로 변화).
-- **탐지 및 대응:** 
-    1. **모니터링:** 모델 예측 결과와 실제 데이터 분포 간의 KL Divergence, JS Divergence 등을 주기적으로 측정하여 이상 징후를 포착한다.
-    2. **재학습 (Retraining):** 드리프트가 감지되면 최신 데이터를 반영하여 모델을 재학습하거나(Online Learning), 모델 자체를 업데이트해야 한다.
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 개념 드리프트는 '일회성 문제'가 아니라, AI/MLOps 운영의 *지속적인* 관리 영역임을 인식해야 하며, 이를 위한 자동화 파이프라인(Monitoring Pipeline) 구축이 필수적이다.
-- **정책 변화:** 최근에는 설명 가능한 AI (XAI) 기법을 결합하여, 모델이 왜 성능 저하를 겪고 있는지 '어떤 개념'에서 벗어났는지 진단하는 것이 중요해지고 있다.
-
-## 🔗 지식 연결 (Graph)
-- Parent: [[Model Collapse (모델 붕괴 현상)]]
-- Related: [[MLOps]] , [[Data Science in UX]] , [[Continuous Monitoring]]
-- Raw Source: [[00_Raw/Concept Drift (개념 드리프트).md]]
----
\ No newline at end of file
diff --git a/AI & Narrative/AI-Driven Narrative Systems.md b/AI & Narrative/AI-Driven Narrative Systems.md
deleted file mode 100644
index 639fdde5..00000000
--- a/AI & Narrative/AI-Driven Narrative Systems.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-8DB819
-category: "[[10_Wiki/💡 Topics/AI & Narrative]]"
-confidence_score: 0.95
-tags: []
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Batch 10 - Wikified AI-Driven Narrative Systems"
----
-
-# [[AI-Driven Narrative Systems]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 핵심 내용 요약 예정
-
-## 📖 구조화된 지식 (Synthesized Content)
-세부 본문 내용 구성 예정
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 신규 지식 유입에 따른 기존 지식과의 정합성 검증 단계.
-- **정책 변화:** AI & Narrative 분야의 체계적 지식 자산화 진행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/AI-Driven Narrative Systems.md]]
----
diff --git a/AI & Psychology/Affective Computing.md b/AI & Psychology/Affective Computing.md
deleted file mode 100644
index 86f6f21c..00000000
--- a/AI & Psychology/Affective Computing.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-E4FCEF
-category: "[[10_Wiki/💡 Topics/AI & Psychology]]"
-confidence_score: 0.95
-tags: []
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Batch 10 - Wikified Affective Computing"
----
-
-# [[Affective Computing]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 핵심 내용 요약 예정
-
-## 📖 구조화된 지식 (Synthesized Content)
-세부 본문 내용 구성 예정
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 신규 지식 유입에 따른 기존 지식과의 정합성 검증 단계.
-- **정책 변화:** AI & Psychology 분야의 체계적 지식 자산화 진행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Affective Computing.md]]
----
diff --git a/AI & Tools/AI Connect LLM Tool.md b/AI & Tools/AI Connect LLM Tool.md
deleted file mode 100644
index a2eb2126..00000000
--- a/AI & Tools/AI Connect LLM Tool.md	
+++ /dev/null
@@ -1,39 +0,0 @@
----
-id: P-REINFORCE-92F236
-category: "[[10_Wiki/💡 Topics/AI & Tools]]"
-confidence_score: 0.95
-tags: []
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Batch 10 - Wikified AI Connect LLM Tool"
----
-
-# [[AI Connect LLM Tool]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> **Connect AI**는 100% 로컬 및 오프라인 환경에서 작동하는 VS Code 전용 프리미엄 AI 코딩 에이전트입니다. 외부 서버 연결 없이 사용자의 하드웨어(Ollama/LM Studio)를 직접 활용하여 파일 생성, 편집, 터미널 명령 실행 및 개인 지식 기반(Second Brain) 연동을 지원합니다.
-
-## 📖 구조화된 지식 (Synthesized Content)
-
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 신규 지식 유입에 따른 기존 지식과의 정합성 검증 단계.
-- **정책 변화:** AI & Tools 분야의 체계적 지식 자산화 진행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[Ollama]], [[LM Studio]], [[VS Code Extension Development]], [[Agentic AI]]
-- **Projects/Contexts:** [[Connect-AI-Lab]], [[EZERAI Infrastructure]]
-- **Contradictions/Notes:** 
-    - **통합 구조:** 현재 프로젝트는 모든 로직(UI, 통신, 에이전트)이 `extension.ts` 하나에 집중된 모놀리식 구조를 가지고 있어, 향후 대규모 기능 추가 시 모듈화가 권장됩니다.
-    - **보안:** 모든 작업이 로컬에서 이루어지므로 기업 보안 환경에 매우 적합하나, `run_command` 실행 시 사용자의 최종 확인 절차가 보완될 필요가 있습니다.
-
----
-
-*Last updated: 2026-04-14*
-
----
-
-# 🕵️ 프로젝트 코드 리뷰 리포트
-
-`/Volumes/Data/project/Antigravity/local_module/resource` 프로젝트에 대한 상세 코드 리뷰 결과입니다.
-- Raw Source: [[00_Raw/2026-04-20/AI Connect LLM Tool.md]]
----
diff --git a/AI/20k skinned instances demo.md b/AI/20k skinned instances demo.md
deleted file mode 100644
index 98468692..00000000
--- a/AI/20k skinned instances demo.md	
+++ /dev/null
@@ -1,39 +0,0 @@
----
-id: P-REINFORCE-AUTO-EB3F3C
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - 20k skinned instances demo"
----
-
-# [[20k skinned instances demo]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> '20k skinned instances demo'는 Three.js 기반의 오픈 소스 라이브러리인 InstancedMesh2를 활용하여 20,000개의 개별적인 스킨드 인스턴스(Skinned instances)를 동시에 렌더링하는 성능 최적화 데모입니다 [1, 2]. 이 데모는 모바일 기기에서도 3,000개의 인스턴스를 원활하게 구동할 수 있도록 설계되었습니다 [2]. 프러스텀 컬링, 거리 기반 애니메이션 프레임 조절, 다중 LOD(Level of Detail) 생성 등 다양한 최적화 기법을 적용하여 단 5번의 드로우 콜만으로 렌더링을 처리하는 것이 특징입니다 [2, 3].
-
-## 📖 구조화된 지식 (Synthesized Content)
-이 데모는 제작자(agargaro)가 개발한 `instancedMesh2` 라이브러리를 기반으로 하며, 대규모 스킨드 메쉬를 렌더링하기 위해 다음과 같은 세부 최적화 기술들을 사용했습니다 [2].
-
-* **프러스텀 컬링 및 시야 기반 업데이트 (Frustum Culling & View-based Updates):** 
-  기본적인 프러스텀 컬링을 적용하여 카메라 시야(Frustum) 내에 존재하는 인스턴스들에 대해서만 뼈대(Bones) 연산을 업데이트합니다 [2].
-* **동적 애니메이션 프레임 제어:**
-  카메라와 각 인스턴스 간의 거리를 계산하여 애니메이션 FPS를 0에서 60 사이로 개별 설정함으로써 불필요한 연산을 줄입니다 [2].
-* **LOD(Level of Detail)의 적극적 활용:**
-  `meshoptimizer`를 활용해 5단계의 기하학적 LOD를 생성했습니다 [2]. 거리가 먼 인스턴스에 대해서는 일부 뼈대 계산을 생략하며, 각 LOD마다 1개의 드로우 콜(Draw Call)만 발생시켜 총 5개의 드로우 콜만으로 렌더링을 완료합니다 [2, 3]. 또한, 그림자(Shadows) 렌더링 시에도 LOD를 관리할 수 있도록 구성되어 있습니다 [4].
-* **개별 애니메이션 지원:**
-  단일 인스턴스들의 복제본들이 모두 동일한 애니메이션과 포즈를 공유하는 것이 아니라, 각 인스턴스마다 서로 다른 애니메이션을 가집니다 [5, 6]. 이 데모에서는 하나의 애니메이션 믹서(Mixer)를 사용했지만, 필요에 따라 인스턴스별로 믹서를 생성할 수도 있습니다 [6].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** AI 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[InstancedMesh2]], [[Frustum Culling]], [[Level of Detail (LOD)]], [[Skinned Mesh]], [[Draw Call]]
-- **Projects/Contexts:** [[three.js]]
-- **Contradictions/Notes:** 본 텍스처(Bone texture)의 부분 업데이트(Partial texture updates) 기능은 PC 환경에서 60FPS를 달성하는 데 도움이 될 수 있는 최적화 기법이지만, 모바일 기기와 파이어폭스(Mozilla Firefox) 브라우저에서는 이중 버퍼링(Double buffering) 부재로 인해 오히려 속도가 느려지는 문제가 있어 본 데모에서는 비활성화된 상태로 제공되었습니다 [2, 7].
-
----
-*Last updated: 2026-04-19*
-- Raw Source: [[00_Raw/2026-04-20/20k skinned instances demo.md]]
----
diff --git a/AI/AI Safety (AI 안전).md b/AI/AI Safety (AI 안전).md
deleted file mode 100644
index 294de58d..00000000
--- a/AI/AI Safety (AI 안전).md	
+++ /dev/null
@@ -1,27 +0,0 @@
----
-id: P-REINFORCE-AI-SAFETY
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 1.0
-tags: [AI Safety, Alignment, Risk Management, AI Ethics]
-last_reinforced: 2026-04-20
----
-
-# [[AI-Safety]] (AI 안전)
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> "브레이크 없는 기차는 재앙이다." 인간보다 강력한 지능이 탄생했을 때, 그 지능이 인간의 목표와 문명을 파괴하지 않도록 기술적/방어적 보호막을 구축하는 가장 시급한 연구 분야다.
-
-## 📖 구조화된 지식 (Synthesized Content)
-- **Robustness**:
-    - 적대적 공격(Adversarial Attack)이나 처음 보는 돌발 상황에서도 AI가 오작동하지 않고 안전하게 관리되는 성질.
-- **Interpretability**:
-    - 신경망이라는 블랙박스 내부에서 어떤 논리 구조로 판단을 내리는지 인간이 읽을 수 있게 시각화하고 분석하는 기술(Mechanistic Interpretability).
-- **Scalable Oversight**:
-    - 인간이 이해하기 힘든 복잡한 지능을 가진 AI를 다른 AI가 감시하게 하여, 인간의 통제력을 잃지 않게 하는 감시 체계.
-
-## ⚠️ 모순 및 업데이트 (RL Update)
-- AI 안전은 종종 모델의 성능 발전을 늦춘다는 비판을 받는다. 그러나 최근 연구에 따르면, 안전하게 설계된 모델(Aligned model)이 정제된 사고 능력 덕분에 실제 실무 성능도 더 높게 나타나는 '보안-성능 시너지'가 확인되고 있다.
-
-## 🔗 지식 연결 (Graph)
-- Related: [[AI-Alignment]] , [[AI-Governance]]
-- Strategy: [[Reliability_Safety_First]]
diff --git a/AI/AI 거버넌스 정책(AI Usage Policy).md b/AI/AI 거버넌스 정책(AI Usage Policy).md
deleted file mode 100644
index 42ace3fc..00000000
--- a/AI/AI 거버넌스 정책(AI Usage Policy).md	
+++ /dev/null
@@ -1,27 +0,0 @@
----
-id: P-REINFORCE-AI-GOV-POLICY
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.99
-tags: [AI Governance, Policy, Compliance, Risk Management]
-last_reinforced: 2026-04-20
----
-
-# [[AI-거버넌스-정책(AI-Usage-Policy)]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> "자율에는 책임이 따른다." 조직 내 AI 도입이 법적, 윤리적, 보안적으로 안전한 궤도를 유지하도록 규정하는 의사결정 프레임워크이자 규율이다.
-
-## 📖 구조화된 지식 (Synthesized Content)
-- **Data Privacy & IP Protection**:
-    - 기업의 민감 데이터나 지식 재산권이 외부 AI 서비스의 학습 데이터로 유출되지 않도록 하는 차단 가이드라인.
-- **Human-in-the-loop**:
-    - 중요한 비즈니스 의사결정이나 콘텐츠 생성 결과물에 대해 반드시 인간이 최종 검토하고 책임을 지게 하는 원칙.
-- **Accountability Framework**:
-    - AI 오작동으로 인한 피해 발생 시, 누가 책임을 지고 어떻게 복구할 것인지에 대한 법적 대응 절차.
-
-## ⚠️ 모순 및 업데이트 (RL Update)
-- 정책이 너무 경직되면 조직의 혁신 속도가 죽는다. 따라서 '무조건 금지'가 아니라, 승인된 도구 내에서 안전하게 실험할 수 있는 '샌드박스 정책'과 주기적인 'AI 리터러시 교육'이 병행되어야 한다.
-
-## 🔗 지식 연결 (Graph)
-- Related: [[Security-Governance]] , [[AI-Ethics]]
-- Authority: [[Deployment_Final_Gate]]
diff --git a/AI/AI 생성 코드 검증(AI Code Assurance).md b/AI/AI 생성 코드 검증(AI Code Assurance).md
deleted file mode 100644
index e5ba6e97..00000000
--- a/AI/AI 생성 코드 검증(AI Code Assurance).md	
+++ /dev/null
@@ -1,39 +0,0 @@
----
-id: P-REINFORCE-AUTO-254BE9
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - AI 생성 코드 검증(AI Code Assurance)"
----
-
-# [[AI 생성 코드 검증(AI Code Assurance)]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> AI Code Assurance(AI 생성 코드 검증)는 AI가 생성하거나 지원한 코드로 인해 발생할 수 있는 고유한 품질 및 보안 위험을 해결하기 위해 설계된 워크플로우이자 검증 프로세스입니다 [1]. 이를 통해 조직은 AI가 작성한 코드가 프로덕션 환경에 배포되기 전에 엄격한 보안, 신뢰성 및 품질 표준을 충족하는지 확인할 수 있습니다 [1, 2]. 주로 정적 애플리케이션 보안 테스트(SAST)와 자동화된 코드 리뷰를 활용하여 결함과 취약점을 조기에 식별하고 일관된 표준을 강제합니다 [2, 3].
-
-## 📖 구조화된 지식 (Synthesized Content)
-- **목적 및 필요성**
-  AI 어시스턴트가 생성한 코드는 스타일과 품질 측면에서 매우 일관성이 없고 변동성이 클 수 있습니다 [4, 5]. AI Code Assurance의 목적은 전체 소프트웨어 개발 수명 주기(SDLC)에서 AI 생성 코드의 비율이 증가하더라도 인간이 작성한 코드와 동일한 품질 게이트(Quality Gate) 표준을 적용하여, 유지보수성과 보안에 대한 일관된 규칙을 강제하는 것입니다 [1, 5].
-
-- **주요 기능 및 작동 방식**
-  - **AI 코드 감지 및 추적:** 시스템은 프로젝트 내에 AI 생성 코드가 존재함을 자동으로 감지하거나 개발자가 직접 태그를 지정할 수 있게 합니다 [3]. 이를 통해 명확한 라벨링과 배지를 부여하여 AI 코드의 관리, 유지보수 및 규정 준수 모니터링을 간소화합니다 [3].
-  - **정적 코드 분석(SAST) 적용:** 결정론적(deterministic)이고 독립적인 코드 검증 방식인 정적 코드 분석과 오염 분석(Taint Analysis)을 사용하여 코드를 스캔합니다 [4, 6]. 이를 통해 보안 취약점, 유출된 비밀 정보, 코드 냄새(Code smells), 논리적 결함 및 성능 위험을 풀 리퀘스트(Pull Request) 단계에서 조기에 표면화합니다 [4, 6, 7].
-  - **워크플로우 및 에이전트 통합:** IDE부터 CI/CD 파이프라인에 이르기까지 기존 개발 워크플로우에 원활하게 통합됩니다 [6, 8]. 특히, MCP(Model Context Protocol)를 통해 Cursor, Claude Code, Windsurf와 같은 AI 코딩 에이전트와 직접 연결되어, 코드가 생성되는 실시간 대화 흐름 속에서 보안 핫스팟 분석 및 피드백을 제공합니다 [4, 8, 9].
-
-- **기대 효과**
-  위험도가 가장 높은 문제를 자동으로 강조 표시하여 코드 리뷰어의 피로도를 크게 줄여주며, 배포 주기를 단축합니다 [4]. 또한 조직은 PCI, OWASP, CWE와 같은 널리 통용되는 규정 준수 및 보안 표준을 충족하면서 신뢰성 있게 AI 기여(contribution)를 수용할 수 있습니다 [10, 11].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** AI 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[Static Application Security Testing (SAST)]], [[Model Context Protocol (MCP)]], [[Automated Code Review]]
-- **Projects/Contexts:** [[SonarQube Server]], [[SonarQube Cloud]]
-- **Contradictions/Notes:** 소스에 따르면 AI 어시스턴트가 생성하는 코드는 본질적으로 일관성이 없고 예측하기 어려울 수 있지만, 이에 적용되는 정적 코드 분석 기술은 '결정론적(deterministic)'이므로 AI 코드의 불확실성을 극복하고 신뢰할 수 있는 독립적인 검증을 제공할 수 있다고 강조합니다 [4].
-
----
-*Last updated: 2026-04-19*
-- Raw Source: [[00_Raw/2026-04-20/AI 생성 코드 검증(AI Code Assurance).md]]
----
diff --git a/AI/AI 에이전트 (AI Agent).md b/AI/AI 에이전트 (AI Agent).md
deleted file mode 100644
index b27faacd..00000000
--- a/AI/AI 에이전트 (AI Agent).md	
+++ /dev/null
@@ -1,27 +0,0 @@
----
-id: P-REINFORCE-AI-AGENT
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 1.0
-tags: [AI Agent, Autonomy, Planning, Reasoning, Action]
-last_reinforced: 2026-04-20
----
-
-# [[AI-에이전트-(AI-Agent)]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> "단순한 계산기에서 자율적인 일꾼으로." 스스로 목표를 설정하고, 계획을 세우며, 도구(Browser, Terminal 등)를 사용하여 주어진 과업을 끝까지 완수하는 자율적 지능체다.
-
-## 📖 구조화된 지식 (Synthesized Content)
-- **Planning & Reasoning**:
-    - 거대 언어 모델(LLM)을 두뇌로 삼아 복잡한 문제를 작은 단계로 분해(Chain-of-Thought)하고 전략을 수립한다.
-- **Action & Tool Use**:
-    - API 호출, 웹 검색, 코드 실행 등 외부 환경과 상호작용할 수 있는 인터페이스를 통해 실제 세계에 변화를 일으킨다.
-- **Memory Management**:
-    - 대화의 맥락(Short-term)과 과거 지식(Long-term)을 RAG나 체크포인트 형태로 유지하여 일관된 수행 능력을 보유한다.
-
-## ⚠️ 모순 및 업데이트 (RL Update)
-- 현재의 에이전트는 '무한 루프'나 '환각'에 빠질 위험이 크다. 이를 극복하기 위해 에이전트가 자신의 결과물을 스스로 검토하는 'Self-Correction' 루프와, 인간이 중간에 개입하는 'Human-in-the-loop' 설계가 필수적이다.
-
-## 🔗 지식 연결 (Graph)
-- Related: [[Multi-Agent-System-(다중-에이전트-시스템)]] , [[Agent-Communication-Protocol-(에이전트-통신-규약)]]
-- Deployment: [[Deployment_Final_Gate]]
diff --git a/AI/AI 코드 리뷰 및 보안 취약점 점검(DevSecOps).md b/AI/AI 코드 리뷰 및 보안 취약점 점검(DevSecOps).md
deleted file mode 100644
index 2100bee7..00000000
--- a/AI/AI 코드 리뷰 및 보안 취약점 점검(DevSecOps).md	
+++ /dev/null
@@ -1,40 +0,0 @@
----
-id: P-REINFORCE-AUTO-4DB2F8
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - AI 코드 리뷰 및 보안 취약점 점검(DevSecOps)"
----
-
-# [[AI 코드 리뷰 및 보안 취약점 점검(DevSecOps)]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> AI 코드 리뷰 및 보안 취약점 점검(DevSecOps)은 소프트웨어 개발 수명 주기(SDLC)의 초기 단계에 AI 기반의 자동화된 정적 분석(SAST)과 인간의 수동 리뷰를 결합하여 코드의 품질과 보안을 선제적으로 확보하는 프로세스입니다 [1, 2]. 개발자는 IDE 내부나 CI/CD 파이프라인의 Pull Request(PR) 단계에서 실시간으로 버그, 로직 결함, 보안 취약점(예: 인젝션, 민감 정보 노출)을 식별하고 수정할 수 있습니다 [3-6]. 결과적으로 기계적이고 반복적인 코드 스타일 검사 및 패턴 기반 취약점 탐지는 AI에 위임하고, 인간은 아키텍처 결정이나 도메인 종속적인 비즈니스 로직을 검토하는 '하이브리드' 방식을 통해 개발 속도와 보안성의 균형을 맞춥니다 [2, 7, 8].
-
-## 📖 구조화된 지식 (Synthesized Content)
-* **하이브리드 코드 리뷰 모델의 부상**
-  2025년 기준 가장 이상적이고 안전한 코드 리뷰 방식은 자동화 도구와 인간의 통찰력을 결합한 하이브리드 모델입니다 [2]. 자동화된 리뷰 도구는 수천 줄의 코드를 단 몇 분 만에 스캔하여 문법 오류, 알려진 보안 취약점 패턴, 코드 스타일 위반 등을 일관성 있게 찾아냅니다 [6, 9]. 하지만 이러한 도구들은 시스템의 의도나 비즈니스 로직을 이해하는 데 한계가 있습니다 [10]. 따라서 자동화 스캔을 1차 방어선으로 사용하여 일상적인 문제를 해결하고, 고위험 아키텍처, 인증 로직, 교차 서비스 통신 및 비즈니스 규칙 검증과 같은 복잡한 판단은 숙련된 개발자의 수동 리뷰를 통해 진행해야 합니다 [11-14].
-
-* **AI 기반 정적 애플리케이션 보안 테스트(SAST)**
-  전통적인 SAST 도구는 규칙과 패턴 매칭에 의존하여 높은 오탐률(False Positive)과 알림 피로도를 유발했습니다 [10, 15, 16]. 그러나 Snyk Code, Corgea, GitHub Advanced Security와 같은 최신 AI 네이티브 SAST 도구들은 머신러닝과 대규모 언어 모델(LLM)을 결합하여 코드의 문맥(Semantic)을 파악합니다 [17-20]. 이 도구들은 오염 분석(Taint analysis)과 도달 가능성(Reachability)을 분석해 파일 간 데이터를 추적하며 실제 악용 가능한 위협만을 효과적으로 필터링합니다 [19, 21, 22]. 또한 Copilot Autofix나 DeepCode AI Fix처럼 발견된 취약점에 대해 검증된 수정안(Remediation)을 PR 단계에서 자동으로 제안하여 리뷰 시간을 대폭 단축시킵니다 [23-25].
-
-* **시프트 레프트(Shift-Left)와 파이프라인 자동화**
-  DevSecOps의 핵심은 소프트웨어 병합 및 배포 전에 보안 및 품질 문제를 원천 차단하는 시프트 레프트 전략입니다 [1, 26]. Husky와 lint-staged 등의 도구를 활용해 Git 사전 커밋(Pre-commit) 훅을 설정하면, 변경된 파일에 대해서만 ESLint(로직/품질)와 Prettier(포맷팅)를 강제 적용할 수 있습니다 [27-29]. 이후 CI/CD 파이프라인 내에 SAST 및 소프트웨어 구성 분석(SCA) 도구를 통합하여 임계치 이상의 치명적 취약점이 포함된 코드는 메인 브랜치로 병합되지 못하도록 '품질 게이트' 역할을 수행하게 합니다 [30, 31].
-
-* **자동화의 한계 및 AI 거버넌스 정책**
-  강력한 자동화 도구라 할지라도 맹신은 위험합니다. 연구에 따르면 SAST 및 자동화 도구는 실제 취약점의 약 22%를 감지하지 못하며 [32, 33], 개발자들이 자동화 시스템의 '녹색 체크마크'만 보고 코드를 제대로 이해하지 않은 채 통과시키는 '녹색 체크마크 증후군(Green Check Mark Syndrome)'과 같은 인지적 나태함을 유발할 수 있습니다 [34, 35]. 기업은 승인되지 않은 퍼블릭 AI 모델에 독점 소스 코드나 고객 데이터가 유출되지 않도록 명확한 AI 사용 정책(AUP)을 수립해야 합니다 [36-38]. 또한 AI가 생성하거나 수정한 코드라도 최종적으로는 반드시 인간 엔지니어의 엄격한 수동 리뷰를 거쳐 이해와 책임을 보장하는 'Human-in-the-Loop' 원칙을 준수해야 합니다 [38, 39].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** AI 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[정적 애플리케이션 보안 테스트(SAST)]], [[시프트 레프트(Shift-Left)]], [[하이브리드 코드 리뷰]]
-- **Projects/Contexts:** [[CI/CD 파이프라인 통합 및 Git 훅(Hooks)]]
-- **Contradictions/Notes:** 자동화 도구를 적극적으로 옹호하는 입장에서는 AI 기반 코드 리뷰와 수정안 자동 생성 기능이 개발자의 업무를 크게 대체하고 생산성을 극대화한다고 주장하지만, 보안 전문가 및 실제 성능 벤치마크 결과(Augment Code 등)에 따르면 자동화 도구는 여전히 30~60%의 오탐률을 보이며 실제 취약점의 약 22%를 놓치는 근본적 사각지대가 존재하므로, 아키텍처 설계와 비즈니스 로직에는 기계가 아닌 인간의 수동 판단이 필수 불가결하다고 반박합니다.
-
----
-*Last updated: 2026-04-18*
-- Raw Source: [[00_Raw/2026-04-20/AI 코드 리뷰 및 보안 취약점 점검(DevSecOps).md]]
----
diff --git a/AI/AI 코드 리뷰.md b/AI/AI 코드 리뷰.md
deleted file mode 100644
index 1418edb5..00000000
--- a/AI/AI 코드 리뷰.md	
+++ /dev/null
@@ -1,33 +0,0 @@
----
-id: P-REINFORCE-AUTO-76F9E4
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - AI 코드 리뷰"
----
-
-# [[AI 코드 리뷰]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> AI 코드 리뷰는 인공지능 에이전트나 머신러닝(ML) 기반의 정적 분석 도구(SAST)를 활용하여 소스 코드의 결함, 보안 취약점, 스타일 위반 및 로직 오류를 식별하는 자동화 프로세스입니다 [1-3]. IDE, CI/CD 파이프라인, 풀 리퀘스트(PR) 등 개발 워크플로우에 통합되어 개발자에게 실시간에 가까운 피드백과 자동 수정(Auto-fix) 제안을 제공합니다 [2, 4-8]. 이를 통해 코드 리뷰의 대기 시간을 줄이고 일관된 품질 표준을 강제할 수 있지만, 아키텍처 의도나 비즈니스 로직의 문맥을 깊이 이해하는 데는 한계가 있어 인간 검토자와의 하이브리드 접근 방식이 필수적으로 요구됩니다 [5, 9-12].
-
-## 📖 구조화된 지식 (Synthesized Content)
-- **작동 방식 및 주요 기술**: 기존의 규칙 기반 정적 분석에 머신러닝(ML), 대규모 언어 모델(LLM) 등을 결합하여 코드의 문맥, 데이터 흐름(Data flow), 오염 추적(Taint analysis) 등을 시맨틱하게 분석합니다 [4, 13-18].
-- **주요 이점**: 대규모 코드베이스를 단 몇 초에서 몇 분 안에 스캔하여 보안 취약점과 버그를 조기에 발견합니다 [19, 20]. 시니어 검토자의 큐(Queue)에서 저위험군 코멘트를 제거하여 PR 검토 주기를 최대 40%까지 단축시키며, 결과적으로 인간 검토자가 아키텍처 설계와 비즈니스 로직에 집중할 수 있도록 돕습니다 [5, 11, 19].
-- **한계점 및 위험성**: AI는 코드의 전반적인 아키텍처 의도나 비즈니스 로직을 완벽히 이해하지 못하는 '문맥 맹점(Context Blindness)'을 지닙니다 [12, 21, 22]. 또한, 오탐지(False Positives)를 발생시키거나 환각(Hallucination)에 의한 잘못된 수정안을 제안할 위험이 존재하며, 검토자가 AI를 맹신하여 비판적 사고가 저하되는 '녹색 체크 표시 증후군(Green Check Mark Syndrome)'을 초래할 수 있습니다 [12, 23-25].
-- **하이브리드 리뷰 모델 및 거버넌스**: 2025년 이후의 현대 소프트웨어 개발에서는 AI 자동화 리뷰와 인간의 수동 리뷰를 결합한 '하이브리드(Hybrid) 리뷰'가 모범 사례로 꼽힙니다 [9-11, 26-28]. 일반적인 취약점 패턴이나 문법 등 기계적인 검증은 AI 도구에 맡기고, 도메인 특화 비즈니스 로직이나 교차 서비스 영향도 평가는 인간이 담당해야 합니다 [28, 29]. 아울러 지적 재산(IP) 유출 방지와 보안을 위해 "인간 개입(Human-in-the-Loop)"을 의무화하는 명확한 AI 사용 정책(Governance) 수립이 필수적입니다 [30-34].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** AI 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[SAST]], [[풀 리퀘스트(Pull Request)]], [[DevSecOps]]
-- **Projects/Contexts:** [[SonarQube]], [[Snyk Code]], [[GitHub Advanced Security]], [[Corgea]]
-- **Contradictions/Notes:** AI 코드 리뷰 도구의 도입만으로는 배포 성능이나 품질이 보장되지 않는다는 점에 유의해야 합니다. 맹목적인 도구 도입과 높은 AI 사용률에도 불구하고 실제 PR 처리 시간이나 재작업 비율은 개선되지 않을 수 있으므로, 결과(DORA 지표 등)에 기반한 관리가 중요합니다 [35-37]. 또한 일부 AI 네이티브 도구들은 오탐률을 혁신적으로 줄였다고 주장하지만(예: Corgea 5% 미만, Veracode 1.1% 미만), 근본적으로 어떠한 도구도 오탐을 완벽히 제거할 수는 없으므로 인간의 검토와 검증 과정이 반드시 수반되어야 합니다 [38-40].
-
----
-*Last updated: 2026-04-19*
-- Raw Source: [[00_Raw/2026-04-20/AI 코드 리뷰.md]]
----
diff --git a/AI/AI와 기계에게 검열 맡기기_ - 정적 분석 툴 (ESLint  Prettier)).md b/AI/AI와 기계에게 검열 맡기기_ - 정적 분석 툴 (ESLint  Prettier)).md
deleted file mode 100644
index 1b011d53..00000000
--- a/AI/AI와 기계에게 검열 맡기기_ - 정적 분석 툴 (ESLint  Prettier)).md	
+++ /dev/null
@@ -1,44 +0,0 @@
----
-id: P-REINFORCE-AUTO-37563B
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - AI와 기계에게 검열 맡기기_ - 정적 분석 툴 (ESLint  Prettier))"
----
-
-# [[AI와 기계에게 검열 맡기기_ - 정적 분석 툴 (ESLint  Prettier))]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 현대 소프트웨어 개발에서는 주관적이고 반복적인 코드 평가 작업을 ESLint, Prettier와 같은 결정론적 도구와 AI 기반 에이전트(기계)에게 위임하여 코드를 자동으로 '검열'하는 구조를 갖추고 있습니다 [1]. Linter인 ESLint는 추상 구문 트리(AST)를 분석해 문법적 오류와 잠재적 버그를 식별하며, Formatter인 Prettier는 줄 바꿈이나 들여쓰기 등 시각적 일관성을 강제합니다 [2]. 나아가 단순한 패턴 매칭을 넘어 LLM 기반의 AI 정적 분석 도구(SAST)를 도입함으로써 문맥을 이해하고 복잡한 취약점을 분석하는 '에이전트적 거버넌스'로 진화하고 있습니다 [3, 4].
-
-## 📖 구조화된 지식 (Synthesized Content)
-* **결정론적 거버넌스의 기반 (ESLint & Prettier)**
-  * **ESLint (결정론적 Linter):** 소스 코드를 추상 구문 트리(AST)로 변환해 순회하면서 사용되지 않는 변수, 섀도잉 현상 등 논리적 버그와 의심스러운 구조를 식별하고 팀의 모범 사례를 강제합니다 [2, 5, 6].
-  * **Prettier (의견이 반영된 Formatter):** 코드의 로직에는 관여하지 않고 들여쓰기, 따옴표 일관성, 줄 바꿈 등 텍스트의 시각적 형태를 일관되게 재작성하여 코드 가독성을 높입니다 [2, 6, 7].
-  * **규칙 충돌 및 통합:** ESLint에도 포맷팅 스타일 규칙이 포함되어 있어 Prettier와 충돌할 수 있습니다. 이를 방지하기 위해 `eslint-config-prettier`를 사용하여 충돌하는 ESLint 규칙을 비활성화하고, `eslint-plugin-prettier`를 통해 Prettier를 ESLint의 규칙처럼 동작시키는 방식이 권장됩니다 [8-11].
-
-* **자동화 검열의 오케스트레이션 (Husky & lint-staged)**
-  * 이러한 검열 도구들은 `Husky`와 `lint-staged`를 활용해 Git의 'pre-commit' 단계에서 강제적으로 실행됩니다 [12-14]. 저장소 전체가 아닌 변경된 파일(staged files)에만 검열 에이전트를 실행시켜 검사 시간을 수 초 내로 단축하고, 품질 미달 코드가 저장소에 병합되는 것을 선제적으로 차단합니다 [13-15].
-
-* **AI를 활용한 시맨틱 지능과 에이전트적 거버넌스**
-  * 전통적인 Linter는 파일 내 패턴 매칭에 그쳐 문맥을 파악하지 못하는 한계(Context-blind)가 있습니다 [3, 16]. 이를 극복하기 위해 Snyk Code, SonarQube 등 AI 기반 정적 분석(SAST) 도구가 도입되고 있습니다 [3, 17, 18].
-  * 수백만 개의 커밋을 학습한 AI 모델은 오염 분석(Taint Analysis) 및 도달 가능성 분석을 수행하여 파일 경계를 넘나드는 복잡한 취약점을 파악하고 안전한 코드 수정을 제안합니다 [19, 20].
-
-* **기계 검열의 심리사회적 영향 및 한계**
-  * 기계에 코드 검열을 맡기면 사소한 스타일 논쟁을 없애고 개발자의 인지 부하를 줄여 비즈니스 로직 해결에 몰입(Flow)할 수 있게 돕습니다 [21, 22].
-  * 하지만 자동화에 과도하게 의존할 경우, 개발자의 비판적 사고 근육이 퇴화하고 자동화 도구의 검사만 통과하면 된다고 여기는 '녹색 체크마크 증후군(Green Check Mark Syndrome)'을 유발할 수 있습니다 [23, 24]. 또한 AI 도구 역시 전체 취약점의 약 22%를 놓치는 사각지대가 존재하므로, 아키텍처 설계와 도메인 비즈니스 로직 등 고위험 검토에는 여전히 인간의 판단(Human-in-the-loop)이 필수적입니다 [24-26].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** AI 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[SAST (정적 애플리케이션 보안 테스트)]], [[AST (추상 구문 트리)]], [[Husky & lint-staged]]
-- **Projects/Contexts:** [[Git Pre-commit 훅을 활용한 개발 워크플로우 자동화]], [[AI 코드 리뷰 및 보안 취약점 점검(DevSecOps)]]
-- **Contradictions/Notes:** 소스는 기계 주도의 검열이 개발 생산성과 코드 품질을 높인다고 긍정적으로 평가하면서도, 동시에 AI 모델이 실제 취약점의 일부를 놓치고 개발자의 비판적 사고를 약화시켜 표면적 문제 해결에 집착하는 '녹색 체크마크 증후군'을 초래할 수 있다는 역설적 한계를 분명히 지적합니다 [23, 24, 26].
-
----
-*Last updated: 2026-04-18*
-- Raw Source: [[00_Raw/2026-04-20/AI와 기계에게 검열 맡기기_ - 정적 분석 툴 (ESLint & Prettier)).md]]
----
diff --git a/AI/API 응답 모델링 및 상태 머신(State Machine) 설계.md b/AI/API 응답 모델링 및 상태 머신(State Machine) 설계.md
deleted file mode 100644
index a8a14092..00000000
--- a/AI/API 응답 모델링 및 상태 머신(State Machine) 설계.md	
+++ /dev/null
@@ -1,40 +0,0 @@
----
-id: P-REINFORCE-AUTO-9FD5CF
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - API 응답 모델링 및 상태 머신(State Machine) 설계"
----
-
-# [[API 응답 모델링 및 상태 머신(State Machine) 설계]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> TypeScript에서 API 응답과 상태 머신을 설계할 때는 식별 가능한 유니온(Discriminated Unions) 패턴이 핵심적으로 활용된다 [1, 2]. 이 패턴은 공통 판별자(Discriminant) 속성을 통해 데이터의 다양한 상태를 구분하며, 유효하지 않은 상태가 코드에 표현되는 것을 원천적으로 차단한다 [1, 3, 4]. 결과적으로 네트워크 요청의 다양한 결과나 복잡한 UI 상태 전이를 컴파일 단계에서 안전하게 모델링하고 관리할 수 있도록 보장한다 [2, 5, 6].
-
-## 📖 구조화된 지식 (Synthesized Content)
-- **상태 머신(State Machine) 패턴 모델링**: 
-  애플리케이션 내의 복잡한 상태(예: `Idle`, `Fetching`, `Success`, `Failure`, `Retry` 등)는 식별 가능한 유니온을 통해 상태 머신으로 완벽하게 모델링할 수 있다 [2]. 이 방식은 폼 제출 워크플로우(예: `validating`, `submitting`, `success`, `error`)나 비동기 작업 패턴을 명확히 정의하는 데 뛰어나며, 호환되지 않는 잘못된 상태들의 조합이 발생하는 것을 원천적으로 불가능(Impossible)하게 만든다 [3, 5].
-
-- **API 응답 데이터 구조화**:
-  API 응답은 성공, 실패, 대기 등 여러 형태를 취할 수 있으므로 식별 가능한 유니온을 통해 구조화하는 것이 효과적이다 [2]. 예를 들어, `NetworkState`라는 유니온 타입 내에 `NetworkLoadingState`, `NetworkFailedState`, `NetworkSuccessState`를 정의하고 `state`라는 리터럴 필드를 공유 판별자로 설계할 수 있다 [6]. 컴파일러는 이 판별자를 바탕으로 `code`나 `response`와 같은 고유 페이로드(Payload) 속성에 안전하게 접근하도록 타입을 좁혀준다(Narrowing) [6, 7].
-
-- **완전성 검사(Exhaustiveness Checking) 적용**:
-  상태 머신과 API 응답을 분기 처리할 때 `switch` 문과 `never` 타입을 활용하면, 개발자가 실수로 누락한 상태나 새롭게 추가된 API 응답 형태가 있을 경우 TypeScript 컴파일러가 에러를 발생시킨다 [3, 7-9]. 이는 모든 분기 및 상태가 빠짐없이 처리되도록 강제하는 강력한 안전장치가 되어 런타임 버그를 방지한다 [10-12].
-
-- **외부 데이터 런타임 검증과의 결합**:
-  외부 API에서 전달받은 응답은 TypeScript의 컴파일 타임 시스템만으로는 런타임에서의 완벽한 안전성을 보장할 수 없다 [12, 13]. 따라서 Zod와 같은 런타임 검증 라이브러리와 식별 가능한 유니온을 결합하여 사용하면, 예기치 않은 형태의 API 데이터로 인해 상태 머신이 망가지는 것을 방어할 수 있다 [12, 13].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** AI 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[식별 가능한 유니온(Discriminated Unions)]], [[완전성 검사(Exhaustiveness Checking)]], [[타입 좁히기(Type Narrowing)]]
-- **Projects/Contexts:** [[비동기 데이터 패칭(Async Data Fetching)]], [[상태 머신 기반 UI 폼 및 라우터 관리]]
-- **Contradictions/Notes:** API 응답 데이터를 변환할 때 타입 캐스팅(`as`)을 사용하면 잉여 속성이 존재하거나 형태가 잘못되어도 컴파일러가 이를 조용히 허용하여 안전성이 떨어질 수 있다. 따라서 엄격한 타입 계약을 강제하기 위해서는 `as` 대신 `satisfies` 키워드를 활용하는 것이 권장된다 [14, 15].
-
----
-*Last updated: 2026-04-18*
-- Raw Source: [[00_Raw/2026-04-20/API 응답 모델링 및 상태 머신(State Machine) 설계.md]]
----
diff --git a/AI/A_B-Testing-Platforms.md b/AI/A_B-Testing-Platforms.md
deleted file mode 100644
index 5a80c519..00000000
--- a/AI/A_B-Testing-Platforms.md
+++ /dev/null
@@ -1,27 +0,0 @@
----
-id: P-REINFORCE-AI-ABTEST
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.96
-tags: [A/B Testing, Statistics, Experiment, Growth Hacking]
-last_reinforced: 2026-04-20
----
-
-# [[A_B-Testing-Platforms]] (A/B 테스트 및 실험 설계)
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> "내 생각엔 이게 좋다"는 주관성을 버리고, "사용자는 실제로 이렇게 반응한다"를 통계적으로 증명하는 마케팅과 엔지니어링의 결합체다.
-
-## 📖 구조화된 지식 (Synthesized Content)
-- **Hypothesis Testing (가설 검증)**:
-    - "버튼 색상을 파란색에서 빨간색으로 바꾸면 클릭률(CTR)이 10% 오를 것이다"라는 명확한 가설을 세우고 실험군(A)과 대조군(B)으로 트래픽을 분할한다.
-- **Statistical Significance (p-value)**:
-    - 실험 결과가 '우연'에 의한 것인지 아니면 '의도된 변화'인지 판별한다. 보통 p-value < 0.05를 기준으로 유의미함을 결정한다.
-- **Multi-armed Bandit (MAB)**:
-    - 실험 중간에 성적이 좋은 쪽에 트래픽을 실시간으로 더 배분하여 '실험 비용'을 최소화하고 '수익'을 극대화하는 고도화된 타겟팅 알고리즘.
-
-## ⚠️ 모순 및 업데이트 (RL Update)
-- 한 번에 너무 많은 변수를 바꾸는 것은 금물이다(Simpsons Paradox). 오직 하나의 변인만 통제하여 결과의 인과관계를 명확히 해야 한다. 또한 장기적 영향(Late Arrival Bias)을 고려하여 최소 일주일 이상의 실험 기간을 확보하라.
-
-## 🔗 지식 연결 (Graph)
-- Related: [[Behavioral-Economics]] , [[Nudge Theory]]
-- Implementation: [[React_State_Management_Strategy]]
diff --git a/AI/Accessibility-Compliance-Audit.md b/AI/Accessibility-Compliance-Audit.md
deleted file mode 100644
index 1e3588b7..00000000
--- a/AI/Accessibility-Compliance-Audit.md
+++ /dev/null
@@ -1,27 +0,0 @@
----
-id: P-REINFORCE-AI-ACC-AUDIT
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.98
-tags: [Accessibility, Compliance, Audit, AI, Web]
-last_reinforced: 2026-04-20
----
-
-# [[Accessibility-Compliance-Audit]] (접근성 준수 감사)
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> "모두를 위한 웹은 기술이 아니라 권리다." 시각 장애인이나 고령자 등 모든 사용자가 웹 사이트의 정보를 평등하게 얻고 있는지 기술적으로 검증하는 프로세스다.
-
-## 📖 구조화된 지식 (Synthesized Content)
-- **Automated Testing**:
-    - AI가 DOM 트리와 ARIA 속성을 분석하여 텍스트 대안(Alt text) 누락, 충분하지 않은 색상 대비(Color Contrast) 등을 자동으로 적발한다.
-- **Manual Heuristic Evaluation**:
-    - 자동화 도구가 잡지 못하는 맥락적 접근성(예: 스크린 리더의 읽기 순서가 논리적인가?)을 전문가가 직접 점검한다.
-- **Reporting & Remediation**:
-    - 감사 결과를 리포트화하고, 개발팀에 즉각적인 수정 가이드를 제공하여 법적 리스크(WCAG 준수 등)를 방어한다.
-
-## ⚠️ 모순 및 업데이트 (RL Update)
-- 접근성 감사는 한 번의 '합격'으로 끝나지 않는다. 코드가 업데이트될 때마다 접근성 점수가 소리 없이 무너질 수 있으므로, CI/CD 파이프라인에 접근성 자동 검사를 통합하는 것이 핵심이다.
-
-## 🔗 지식 연결 (Graph)
-- Related: [[UI-UX-Foundations]] , [[Automated-Security-Audits]]
-- Standard: [[Web-Content-Accessibility-Guidelines-WCAG]]
diff --git a/AI/Adaptive Compute (적응형 계산량 조절).md b/AI/Adaptive Compute (적응형 계산량 조절).md
deleted file mode 100644
index d719c080..00000000
--- a/AI/Adaptive Compute (적응형 계산량 조절).md	
+++ /dev/null
@@ -1,27 +0,0 @@
----
-id: P-REINFORCE-AI-ADAPT-COMP
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.99
-tags: [Adaptive Compute, AI, Efficiency, Inference, Optimization]
-last_reinforced: 2026-04-20
----
-
-# [[Adaptive-Compute]] (적응형 계산량 조절)
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> "쉬운 문제는 빨리 풀고, 어려운 문제는 더 고민하라." 데이터의 복잡도에 따라 신경망의 층(Layer)이나 파라미터를 유동적으로 사용하여 연산 효율을 극대화하는 지능적 최적화다.
-
-## 📖 구조화된 지식 (Synthesized Content)
-- **Early Exit Strategies**:
-    - 하위 레이어에서 이미 결과가 확실할 경우, 상위 레이어 연산을 건너뛰고 정답을 출력하여 응답 속도를 높인다.
-- **Dynamic Gating**:
-    - 특정 입력값에 필요한 '전문가 신경망'만 선별적으로 활성화하여 전체 연산량을 줄이는 방식(Mixture of Experts와 궤를 같이함).
-- **Inference Cost Reduction**:
-    - 불필요한 연산을 줄임으로써 클라우드 API 호출 비용이나 온디바이스 AI의 배터리 소모를 획기적으로 절감한다.
-
-## ⚠️ 모순 및 업데이트 (RL Update)
-- 계산량을 줄이는 과정에서 아주 드물게 발생하는 '어려운 예외 상황(Edge case)'에서 성능이 소폭 하락할 수 있다. 따라서 성능 손실과 비용 절감 사이의 'Pareto Optimal' 지점을 찾는 것이 공학적 핵심이다.
-
-## 🔗 지식 연결 (Graph)
-- Related: [[Dense-vs-Sparse-Neural-Networks]] , [[Deep-Learning-Architecture-Patterns]]
-- Foundation: [[Computational-Efficiency]]
diff --git a/AI/Advanced-Interface-Design.md b/AI/Advanced-Interface-Design.md
deleted file mode 100644
index 8cd452f6..00000000
--- a/AI/Advanced-Interface-Design.md
+++ /dev/null
@@ -1,27 +0,0 @@
----
-id: P-REINFORCE-AI-ADV-IF-DESIGN
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.97
-tags: [Interface Design, UX, Human-Computer Interaction, AI]
-last_reinforced: 2026-04-20
----
-
-# [[Advanced-Interface-Design]] (고급 인터페이스 설계)
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> "보이지 않는 인터페이스가 가장 훌륭한 인터페이스다." 사용자의 의도를 예측하고 대화를 최소화하면서도 완벽한 경험을 선사하는 고도의 심미적/공학적 설계 체계다.
-
-## 📖 구조화된 지식 (Synthesized Content)
-- **Predictive Interaction**:
-    - 과거 행동 데이터를 기반으로 사용자가 다음에 무엇을 클릭할지 예측하여 미리 로딩하거나 인터페이스를 배치한다.
-- **Micro-animations & Feedback**:
-    - 미묘한 움직임으로 시스템의 상태를 알리고, 사용자의 행동에 즉각적이고 부드러운 심리적 만족감을 제공한다.
-- **Multi-modal Input**:
-    - 터치, 음성, 시선, 제스처 등 다양한 입력 수단을 통합하여 가장 자연스러운 맥락에서 시스템과 소통하게 한다.
-
-## ⚠️ 모순 및 업데이트 (RL Update)
-- 인터페이스가 너무 '지능적'이면 사용자가 통제권을 상실했다고 느낄 수 있다(Black box effect). 따라서 시스템이 왜 이런 제안을 하는지 투명하게 보여주는 '설명 가능한 인터페이스'의 조화가 필요하다.
-
-## 🔗 지식 연결 (Graph)
-- Related: [[UI-UX-Foundations]] , [[Psychology_Cognitive_Science]]
-- Context: [[Modern_Environment_Ecosystem]]
diff --git a/AI/Adversarial Code Stylometry.md b/AI/Adversarial Code Stylometry.md
deleted file mode 100644
index eabe6319..00000000
--- a/AI/Adversarial Code Stylometry.md	
+++ /dev/null
@@ -1,34 +0,0 @@
----
-id: P-REINFORCE-AUTO-36585B
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Adversarial Code Stylometry"
----
-
-# [[Adversarial Code Stylometry]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> Adversarial Code Stylometry(적대적 코드 문체론)는 프로그래머가 코드 문체 분석(Code Stylometry) 시스템의 추적을 우회하여 자신의 익명성을 보호하기 위해 의도적으로 코드를 변형하는 기법입니다 [1-3]. 주로 자신의 고유한 코딩 스타일을 숨기는 난독화(obfuscation)와 다른 프로그래머의 스타일을 흉내 내는 모방(mimicry) 기술을 사용합니다 [2-4]. 이는 감시와 검열에 맞서 프라이버시 향상 도구를 개발하는 오픈소스 기여자들이 신원 노출로 인한 탄압을 피하기 위한 핵심적인 방어 수단으로 연구되고 있습니다 [5-7].
-
-## 📖 구조화된 지식 (Synthesized Content)
-* **배경 및 필요성:** 인터넷 검열과 감시가 강화됨에 따라 프라이버시 향상 기술이나 검열 우회 도구를 개발하는 오픈소스 개발자들이 국가나 기관의 표적이 되는 사례가 늘고 있습니다 [5, 6, 8]. 코드 작성자의 코딩 스타일을 분석해 신원을 파악하는 소스 코드 문체론(Source Code Stylometry)은 이러한 개발자들에게 심각한 위협이 되며, 이에 대항하여 익명성을 유지할 수 있는 적대적 방어 기법이 필요해졌습니다 [7].
-* **공격 기법 (난독화 및 모방):** 적대적 코드 문체론은 크게 두 가지 접근법을 취합니다. 첫째는 자신의 식별 가능한 코딩 스타일을 모호하게 만드는 '난독화(obfuscation / masking)'이고, 둘째는 다른 특정 작가로 기계 학습 모델을 속이기 위해 의도적으로 대상의 스타일을 흉내 내는 '모방(mimicry / forgery)' 공격입니다 [2-4, 9].
-* **기존 문체 분석 시스템의 취약성:** 최첨단 소스 코드 문체 분석 시스템조차도 적대적 수정에 취약한 것으로 나타났습니다 [3, 9]. 변수 이름, 매크로, 리터럴, API 호출 등 국소적인 정보(local changes)나 표면적인 형식 변경만으로도 분류기(classifier)를 속여 다른 사람으로 오분류하게 만드는 것이 가능합니다 [10, 11].
-* **방어 지원 도구 (StyleCounsel):** 개발자가 다른 이의 스타일을 모방하고 자신의 스타일을 난독화할 수 있도록 돕는 `StyleCounsel`과 같은 시스템이 개발되었습니다 [2, 12]. 이 도구는 랜덤 포레스트(Random Forest)와 같은 기계 학습 모델의 의사 결정 트리를 분석하여, 오분류를 유도할 수 있는 구체적이고 최소한의 코드 변경 사항(예: 특정 구문의 사용 빈도 조절 등)을 사용자에게 추천합니다 [2, 13, 14].
-* **코드 포매팅을 통한 프라이버시 보호막:** Prettier나 Black 등과 같은 결정론적 코드 포매터(Formatter) 및 최소화(Minification) 도구를 적용하는 것만으로도 작성자 인식 정확도를 크게 떨어뜨릴 수 있습니다 [15, 16]. 연구에 따르면 코드 포매팅 적용 시 식별 정확도가 68%에서 53%로 하락하며, 최소화를 거치면 50%까지 떨어져 코드 문체론 분석에 대한 실질적인 프라이버시 보호막(Privacy shield) 역할을 수행합니다 [17-19].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** AI 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[Code Stylometry]], [[Obfuscation]], [[Mimicry Attack]], [[StyleCounsel]]
-- **Projects/Contexts:** [[오픈소스 기여자 익명성 보장]], [[검열 우회 및 프라이버시 보호 도구 개발]]
-- **Contradictions/Notes:** Caliskan-Islam 등의 기존 연구에서는 'Stunnix'와 같은 상용 난독화 도구를 사용해도 분류기의 식별 정확도가 거의 떨어지지 않는다고 보고했습니다. 그러나 Simko 등의 적대적 연구에서는 실험 참가자들이 표면적인 수준의 변수명 교체나 국소적인 구조 변경 등 간단한 조작을 가하는 것만으로도 기계 학습 모델을 성공적으로 속일 수 있음을 입증하며 기존 분류 시스템의 취약성과 한계를 지적했습니다 [11, 20].
-
----
-*Last updated: 2026-04-19*
-- Raw Source: [[00_Raw/2026-04-20/Adversarial Code Stylometry.md]]
----
diff --git a/AI/Algorithmic-Biology.md b/AI/Algorithmic-Biology.md
deleted file mode 100644
index 2bbefd59..00000000
--- a/AI/Algorithmic-Biology.md
+++ /dev/null
@@ -1,27 +0,0 @@
----
-id: P-REINFORCE-AI-BIO
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.99
-tags: [Algorithmic Biology, AI, Bioinformatics, Simulation]
-last_reinforced: 2026-04-20
----
-
-# [[Algorithmic-Biology]] (알고리즘 생물학)
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> "생명은 우주의 가장 복잡한 알고리즘이다." 유전자 서열 분석부터 단백질 구조 예측(AlphaFold)까지, 생명 현상을 계산 가능한 모델로 해석하는 초융합 분야다.
-
-## 📖 구조화된 지식 (Synthesized Content)
-- **Sequence Alignment**:
-    - 서로 다른 생물 종의 DNA/RNA 서열을 비교하여 진화적 관계를 밝히거나 질병 원인을 찾는 알고리즘.
-- **Protein Folding Simulation**:
-    - AI를 이용해 단백질이 어떻게 3차원 구조로 접히는지 예측하여 신약 개발의 시간을 수십 년 단축한다.
-- **Cellular Automata**:
-    - 단순한 규칙이 어떻게 복잡한 생명 패턴을 만들어내는지 시뮬레이션하는 수리 생물학적 접근.
-
-## ⚠️ 모순 및 업데이트 (RL Update)
-- 생물학적 데이터는 노이즈가 매우 심하고 복잡하다. 따라서 단순한 패턴 매칭을 넘어, 생체 내의 물리 법칙과 화학적 성질을 AI 모델에 주입하는 'Physics-informed Neural Networks'가 필수적이다.
-
-## 🔗 지식 연결 (Graph)
-- Related: [[Bioinformatics]] , [[Computational-Neuroscience]]
-- Foundation: [[Computational Theory & Math/Information Theory]]
diff --git a/AI/Algorithmic-Game-Theory.md b/AI/Algorithmic-Game-Theory.md
deleted file mode 100644
index db634582..00000000
--- a/AI/Algorithmic-Game-Theory.md
+++ /dev/null
@@ -1,27 +0,0 @@
----
-id: P-REINFORCE-AI-GAME-THEORY
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.99
-tags: [Algorithmic Game Theory, Mechanism Design, Nash Equilibrium, AI]
-last_reinforced: 2026-04-20
----
-
-# [[Algorithmic-Game-Theory]] (알고리즘 게임 이론)
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> "이기적인 경제 주체들을 위한 최적의 규칙." 게임 이론의 복잡한 균형점(Nash Equilibrium)을 컴퓨터 알고리즘으로 어떻게 빠르게 찾아낼 것인가를 다루는 학문이다.
-
-## 📖 구조화된 지식 (Synthesized Content)
-- **Computational Complexity of Equilibria**:
-    - 나쉬 균형을 찾는 것이 얼마나 어려운지(PPAD-complete) 분석하고, 이를 근사적으로 해결하는 알고리즘을 개발한다.
-- **Mechanism Design**:
-    - 참여자들이 자신의 리소스를 솔직하게 공개하는 것이 스스로에게도 이득이 되도록 시스템(경매, 매칭 등)을 설계한다.
-- **Price of Anarchy**:
-    - 개별 주체의 이기적 행동으로 인해 사회 전체의 효율성이 얼마나 감소하는지 정량화한다.
-
-## ⚠️ 모순 및 업데이트 (RL Update)
-- 전통적인 게임 이론은 주체들이 '완전하게 합리적'이라고 가정하지만, 현실의 AI나 인간은 '제한적 합리성'을 가진다. 따라서 최근에는 강화학습을 통해 실시간으로 변하는 전략 공간에 대응하는 연구가 주류다.
-
-## 🔗 지식 연결 (Graph)
-- Related: [[Nash-Equilibrium]] , [[Mechanism-Design]]
-- Foundation: [[Bounded-Rationality]]
diff --git a/AI/Ambient-Declarations.md b/AI/Ambient-Declarations.md
deleted file mode 100644
index 3af39c71..00000000
--- a/AI/Ambient-Declarations.md
+++ /dev/null
@@ -1,27 +0,0 @@
----
-id: P-REINFORCE-TS-AMBIENT
-category: "[[10_Wiki/💡 Topics/Design & Experience]]"
-confidence_score: 0.98
-tags: [TypeScript, Ambient Declarations, dts, Coding Standards]
-last_reinforced: 2026-04-20
----
-
-# [[Ambient-Declarations]] (앰비언트 선언)
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> "존재하지만 실체는 없는 것들에 대한 증명." 타입스크립트 컴파일러에게 "이 변수나 함수는 외부에 이미 있으니 타입만 믿고 통과시켜라"라고 알려주는 `declare` 키워드의 본질이다.
-
-## 📖 구조화된 지식 (Synthesized Content)
-- **declare keyword**:
-    - 실제 컴파일된 JS 파일에는 포함되지 않지만, 타입 전용 공간에서 전역 변수나 라이브러리의 구조를 선언할 때 사용한다.
-- **.d.ts files**:
-    - 앰비언트 선언들이 모여 있는 파일. 프로젝트 전체에 걸쳐 전역적인 타입 정보를 제공하는 '타입 명세서' 역할을 한다.
-- **External Library Integration**:
-    - 타입 정보가 없는 레거시 JS 라이브러리를 타입스크립트 프로젝트에서 에러 없이 사용하기 위한 필수 관문이다.
-
-## ⚠️ 모순 및 업데이트 (RL Update)
-- 무분별한 앰비언트 선언은 전역 네임스페이스를 오염시킨다. 현대적 가이드라인은 가능하면 `Module Augmentation`을 사용하거나 `@types` 패키지를 통해 엄격하게 관리하는 것을 권장한다.
-
-## 🔗 지식 연결 (Graph)
-- Related: [[Declaration-Files]] , [[Module-Augmentation]]
-- Standard: [[Branded-Types-for-Nominal-Typing]]
diff --git a/AI/Amdahls Law (암달의 법칙).md b/AI/Amdahls Law (암달의 법칙).md
deleted file mode 100644
index e8b345e6..00000000
--- a/AI/Amdahls Law (암달의 법칙).md	
+++ /dev/null
@@ -1,27 +0,0 @@
----
-id: P-REINFORCE-CS-AMDAHL
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 1.0
-tags: [Amdahls Law, Parallel Computing, Latency, Computer Architecture]
-last_reinforced: 2026-04-20
----
-
-# [[Amdahls-Law-(암달의-법칙)]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> "쇠사슬의 강도는 가장 약한 연결 고리에 의해 결정된다." 프로그램의 일부분만 병렬화했을 때 얻을 수 있는 이론적인 최대 성능 향상폭(Speedup)은 변하지 않는 '순차적 부분'에 의해 제한된다는 냉혹한 법칙이다.
-
-## 📖 구조화된 지식 (Synthesized Content)
-- **Theoretical Speedup**:
-    - 프로그램의 90%를 병렬화하더라도, 나머지 10%가 순차적으로 실행되어야 한다면 아무리 많은 코어(Processor)를 투입해도 속도는 10배 이상 빨라질 수 없다.
-- **Diminishing Returns**:
-    - 프로세서 개수가 늘어날수록 성능 향상률은 급격히 둔화되며, 특정 지점 이후에는 통신 오버헤드로 인해 오히려 성능이 떨어질 수도 있다.
-- **Optimization Strategy**:
-    - 전체 성능을 높이려면 병렬화 가능한 부분을 늘리기보다, '병렬화 불가능한 순차적 구간'을 최대한 짧게 만드는 데 집중해야 한다.
-
-## ⚠️ 모순 및 업데이트 (RL Update)
-- 암달의 법칙은 데이터 크기가 고정된 상황을 가정한다. 데이터 크기 자체가 늘어날 때는 병렬화 효율이 더 좋아진다는 '구스타프슨의 법칙(Gustafson's Law)'이 보완적인 시각을 제공한다.
-
-## 🔗 지식 연결 (Graph)
-- Related: [[Distributed-Systems-Engineering]] , [[Complexity-Theory]]
-- Foundation: [[Computational Theory & Math/Information Theory]]
diff --git a/AI/Artificial-Intelligence-in-Games.md b/AI/Artificial-Intelligence-in-Games.md
deleted file mode 100644
index f9e5cc1b..00000000
--- a/AI/Artificial-Intelligence-in-Games.md
+++ /dev/null
@@ -1,27 +0,0 @@
----
-id: P-REINFORCE-AI-GAMES
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.98
-tags: [Game AI, Pathfinding, FSM, Behavior Tree, Reinforcement Learning]
-last_reinforced: 2026-04-20
----
-
-# [[Artificial-Intelligence-in-Games]] (게임 속의 인공지능)
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> "플레이어의 즐거움을 위한 적당한 지능적 패배." 플레이어에게 도전과 몰입감을 주기 위해 설계된 NPC 제어 기술이자, 최근에는 환경 생성(PCG)까지 확장된 게임 디자인의 파트너다.
-
-## 📖 구조화된 지식 (Synthesized Content)
-- **Decision Making (FSM/BT)**:
-    - 유한 상태 기계(FSM)나 행동 트리(Behavior Tree)를 통해 상황에 맞는 NPC의 행동 로직을 계층적으로 설계한다.
-- **Dynamic Difficulty Adjustment (DDA)**:
-    - 실시간으로 플레이어의 실력을 파악하여 난이도를 조절, '몰입(Flow)' 상태를 유지하게 하는 기술.
-- **Emergent Behavior**:
-    - 고정된 스크립트가 아니라, 단순한 규칙들의 상호작용을 통해 개발자도 예상치 못한 흥미로운 상황을 만들어내는 기법.
-
-## ⚠️ 모순 및 업데이트 (RL Update)
-- 너무 똑똑한 AI는 게임의 재미를 망친다(절대 지지 않는 AI는 독재자와 같다). 따라서 게임 AI의 핵심은 '완벽한 승리'가 아니라 '설득력 있는 지능적 행동'을 보여주는 것이다.
-
-## 🔗 지식 연결 (Graph)
-- Related: [[Agency-in-Game-Design]] , [[Reinforcement-Learning]]
-- Context: [[Immersive-Sim-Genre]]
diff --git a/AI/Artificial-Intelligence.md b/AI/Artificial-Intelligence.md
deleted file mode 100644
index ffd18b90..00000000
--- a/AI/Artificial-Intelligence.md
+++ /dev/null
@@ -1,27 +0,0 @@
----
-id: P-REINFORCE-AI-GENERAL
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.99
-tags: [Artificial Intelligence, Machine Learning, Deep Learning, Scaling Laws]
-last_reinforced: 2026-04-20
----
-
-# [[Artificial-Intelligence]] (인공지능)
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> "기계의 사고가 아니라, 데이터의 압축과 예측이다." 인간의 지능적 행동을 흉내 내는 소프트웨어 체계를 넘어, 데이터 속에 숨겨진 고차원적 패턴을 찾아내어 미래를 통계적으로 추론하는 기술이다.
-
-## 📖 구조화된 지식 (Synthesized Content)
-- **Weak AI vs Strong AI**:
-    - 바둑이나 번역처럼 특정 작업만 수행하는 좁은 지능(ANI)과, 인간처럼 모든 영역에서 사고할 수 있는 광범위한 지능(AGI)의 구분.
-- **Information Processing**:
-    - 입력을 출력으로 매핑하는 거대한 수학 함수. 최근에는 '데이터(Data), 연산량(Compute), 알고리즘(Algorithm)'이라는 3요소의 폭발적 성장이 성패를 가른다.
-- **Societal Impact**:
-    - 노동의 자동화를 넘어, 인간의 창의 성과 의사결정 방식 자체를 재정의하는 문명적 도구.
-
-## ⚠️ 모순 및 업데이트 (RL Update)
-- AI는 '이해'하는 것이 아니라 '확률적 생성'을 하는 것이다. 이 차이를 간과할 때 환각(Hallucination) 문제가 발생하며, 이를 극복하기 위해 심볼릭 로직과 딥러닝을 결합하는 'Neuro-symbolic AI'가 대안으로 떠오르고 있다.
-
-## 🔗 지식 연결 (Graph)
-- Related: [[Deep-Learning-Architecture-Patterns]] , [[AI-Ethics]]
-- Foundation: [[Computational Thinking]]
diff --git a/AI/Autism Spectrum Disorder (ASD) Intervention.md b/AI/Autism Spectrum Disorder (ASD) Intervention.md
deleted file mode 100644
index 0ef3060b..00000000
--- a/AI/Autism Spectrum Disorder (ASD) Intervention.md	
+++ /dev/null
@@ -1,27 +0,0 @@
----
-id: P-REINFORCE-AI-ASD
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.96
-tags: [ASD, Autism, AI Intervention, Healthcare, Therapy]
-last_reinforced: 2026-04-20
----
-
-# [[Autism-Spectrum-Disorder-(ASD)-Intervention]] (ASD를 위한 기술적 개입)
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> "사회적 장벽을 허무는 디지털 동반자." 자폐 스펙트럼 장애(ASD)를 가진 이들이 겪는 의사소통과 감정 인식의 어려움을 AI 기술을 통해 보조하고 교육하는 인도적 기술이다.
-
-## 📖 구조화된 지식 (Synthesized Content)
-- **Emotion Recognition Training**:
-    - 사람의 표정을 분석하여 감정을 텍스트나 소리로 알려주는 안경(Smart glass)이나 앱을 통해 사회적 상호작용을 돕는다.
-- **Social Scenarios Simulation**:
-    - VR(가상 현실)과 AI를 결합하여 안전한 환경에서 사회적 상황을 반복 연습하게 함으로써 실제 상황에서의 불안감을 낮춘다.
-- **Personalized Learning Robots**:
-    - 사람과의 접촉을 부담스러워할 수 있는 환자를 위해, 감정이 일관되고 인내심이 강한 교육용 로봇을 통해 기초 교육을 수행한다.
-
-## ⚠️ 모순 및 업데이트 (RL Update)
-- 기술은 보조적 수단일 뿐, 인간 전문가나 가족의 사랑과 지지를 대체할 수 없다. 기술 과의존으로 인해 현실 세계와의 접촉이 더 줄어들지 않도록 인간 지향적 설계(Human-centered design)가 매우 중요하다.
-
-## 🔗 지식 연결 (Graph)
-- Related: [[Accessibility-Compliance-Audit]] , [[Psychology_Cognitive_Science]]
-- Ethics: [[AI-Ethics]]
diff --git a/AI/Automated-Game-Testing.md b/AI/Automated-Game-Testing.md
deleted file mode 100644
index cc03b3f8..00000000
--- a/AI/Automated-Game-Testing.md
+++ /dev/null
@@ -1,27 +0,0 @@
----
-id: P-REINFORCE-AI-AUTOTEST
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.97
-tags: [Automated Testing, Game QA, AI Testing, Bot Testing]
-last_reinforced: 2026-04-20
----
-
-# [[Automated-Game-Testing]] (지능형 게임 테스트 자동화)
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> QA는 단순히 버그를 찾는 행위를 넘어, AI 에이전트가 게이머처럼 플레이하게 함으로써 게임의 '밸런스'와 '재미의 영역'까지 검증하는 기술이다.
-
-## 📖 구조화된 지식 (Synthesized Content)
-- **Bot-driven Testing**:
-    - 단순 매크로가 아닌, 강화학습된 AI 봇을 투입하여 맵의 갈 수 없는 곳(Collision Error)을 찾거나 무한 루프에 빠지는 구간을 전수 조사한다.
-- **Performance Profiling Automation**:
-    - 대규모 전투나 복잡한 지형에서 프레임드랍(FPS Drop)이 발생하는 구간을 자동 감지하고, 해당 시점의 메모리 스택과 렌더링 부하를 기록하여 개발팀에 보고한다.
-- **Regression Guard**:
-    - 기능 추가 시 기존의 퀘스트 라인이나 밸런스가 무너지지 않았는지, 자동화된 시나리오 테스트를 통해 24시간 감시 체계를 유지한다.
-
-## ⚠️ 모순 및 업데이트 (RL Update)
-- 자동화 봇은 효율적이지만 '인간의 감정'을 느끼지 못한다. 버그는 없으나 재미가 없는 구역(Boring Zones)을 찾아내는 것은 여전히 인간 QA의 영역이며, AI는 이를 보조하는 증폭기로 사용되어야 한다.
-
-## 🔗 지식 연결 (Graph)
-- Related: [[Software Reliability]] , [[System_Debugging_Protocol]]
-- Foundation: [[Reinforcement Learning]]
diff --git a/AI/Automated-Map-Generation.md b/AI/Automated-Map-Generation.md
deleted file mode 100644
index 19852240..00000000
--- a/AI/Automated-Map-Generation.md
+++ /dev/null
@@ -1,28 +0,0 @@
----
-id: P-REINFORCE-AI-GENMAP
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.99
-tags: [PCG, Map Generation, Algorithm, Noise Nature]
-last_reinforced: 2026-04-20
----
-
-# [[Automated-Map-Generation]] (절차적 맵 생성 PCG)
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 무한한 우주는 수학 공식(Seed) 하나에서 탄생한다. 절차적 생성(PCG)은 개발자의 노동력을 '규칙의 창조'로 전이시켜 콘텐츠의 무한 확장을 가능케 한다.
-
-## 📖 구조화된 지식 (Synthesized Content)
-- **Perlin Noise & Simplex Noise**:
-    - 자연스러운 지형(산, 계곡, 해안선)을 만들기 위한 수학적 노이즈 알고리즘. 연속성을 가진 난수를 통해 자연의 불규칙성을 모사한다.
-- **Constraint-based Generation (제약 기반 생성)**:
-    - 단순히 무작위로 만드는 것이 아니라, "마을은 물 근처에 있어야 한다", "보스 방은 입구에서 가장 멀어야 한다"는 비즈니스 로직(제약 조건)을 알고리즘에 주입한다.
-- **Dungeon Generation (BSP, WFC)**:
-    - **BSP (Binary Space Partitioning)**: 공간을 이진 분할하여 방과 복도를 배치하는 정석적인 방식.
-    - **WFC (Wave Function Collapse)**: 인접한 타일 간의 관계성을 기반으로 복잡한 구조를 확률적으로 붕괴시켜 완성하는 최신 알고리즘.
-
-## ⚠️ 모순 및 업데이트 (RL Update)
-- PCG는 자칫 '반복적이고 지루한(Samey)' 느낌을 줄 수 있다. 이를 방지하기 위해 핵심 랜드마크는 수동 제작(Manual Polish)하고, 그 사이의 연결을 PCG가 담당하는 하이브리드 방식이 선호된다.
-
-## 🔗 지식 연결 (Graph)
-- Related: [[Systemic_Simulation_Principles]] , [[Art_Direction_Governance]]
-- Foundation: [[Information Theory]]
diff --git a/AI/Automated-Reasoning.md b/AI/Automated-Reasoning.md
deleted file mode 100644
index 48fa0f6b..00000000
--- a/AI/Automated-Reasoning.md
+++ /dev/null
@@ -1,27 +0,0 @@
----
-id: P-REINFORCE-AI-REASON
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.95
-tags: [Automated Reasoning, Logic, Inference, Knowledge Graph]
-last_reinforced: 2026-04-20
----
-
-# [[Automated-Reasoning]] (자동 추론)
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 단순한 '확률적 답변'을 넘어, 수학과 논리의 규칙에 따라 결론을 도출하는 기계의 사고방식이다.
-
-## 📖 구조화된 지식 (Synthesized Content)
-- **Symbolic AI (기호론적 AI)**:
-    - 데이터를 처리하는 신경망과 달리, 기호와 논리 법칙(If-Then)을 사용하여 참과 거짓을 판별하고 새로운 명제를 이끌어낸다.
-- **Inference Engine (추론 엔진)**:
-    - 지식 베이스(Knowledge Base)에 저장된 사실들을 바탕으로 사용자의 질문에 대한 답을 찾아가는 핵심 모듈. 순방향(Forward) 및 역방향(Backward) 추론 기법이 존재한다.
-- **SAT Solvers**:
-    - 주어진 불리언 공식이 참이 될 수 있는지 판별하는 고도로 최적화된 알고리즘. 복잡한 스케줄링, 베리피케이션, 하드웨어 설계 검증에 필수적으로 사용된다.
-
-## ⚠️ 모순 및 업데이트 (RL Update)
-- 최근에는 기호론적 추론과 딥러닝을 결합한 **Neuro-Symbolic AI**가 주목받고 있다. 딥러닝의 패턴 인식 능력과 기호론의 명확한 논리 구조를 결합하여 '설명 가능한 AI(XAI)'를 구축하는 것이 핵심 목표다.
-
-## 🔗 지식 연결 (Graph)
-- Related: [[Automated-Theorem-Proving]] , [[Distributed-Systems-Engineering]]
-- Context: [[Information Theory]]
diff --git a/AI/Automated-Refactoring-Tools.md b/AI/Automated-Refactoring-Tools.md
deleted file mode 100644
index ec4f1887..00000000
--- a/AI/Automated-Refactoring-Tools.md
+++ /dev/null
@@ -1,27 +0,0 @@
----
-id: P-REINFORCE-AI-REFACT
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.96
-tags: [Refactoring, Static Analysis, AI Code, Technical Debt]
-last_reinforced: 2026-04-20
----
-
-# [[Automated-Refactoring-Tools]] (자동 리팩토링 도구)
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 코드는 생명체와 같아서 방치하면 썩는다. 자동 리팩토링 도구는 코드의 악취를 맡고 실시간으로 해독제를 주입하는 '시스템의 면역계'다.
-
-## 📖 구조화된 지식 (Synthesized Content)
-- **Static Analysis (정적 분석)**:
-    - 코드를 실행하지 않고도 잠재적 버그, 중복 코드, 매직 넘버 등을 찾아내어 표준화된 스타일(Lint)로 교정한다.
-- **AI-Powered Code Assistant (Copilot, Cursor)**:
-    - LLM을 활용하여 단순한 린트를 넘어, 함수의 복잡도를 낮추거나 비효율적인 루프를 고성능 패턴으로 바꾸는 지능적 제안을 수행한다.
-- **Code Transformation Engines**:
-    - 대규모 프레임워크 업데이트(예: React 17 -> 18) 시 전체 코드 베이스를 기계적으로 변환하여 인간의 실수를 줄이고 마이그레이션 비용을 획기적으로 낮춘다 (e.g., CodeMods).
-
-## ⚠️ 모순 및 업데이트 (RL Update)
-- 자동화 도구에 100% 의존하는 것은 위험하다. 비즈니스 맥락(Business Context)을 모르는 기계적 리팩토링은 때로 의도된 우회 코드를 파괴할 수 있다. 최종 검사(Human-in-the-loop)는 여전히 필수적인 관문이다.
-
-## 🔗 지식 연결 (Graph)
-- Related: [[React_Clean_Code_Best_Practices]] , [[Software Reliability]]
-- Foundation: [[System_Debugging_Protocol]]
diff --git a/AI/Automated-Security-Audits.md b/AI/Automated-Security-Audits.md
deleted file mode 100644
index 794fc9de..00000000
--- a/AI/Automated-Security-Audits.md
+++ /dev/null
@@ -1,27 +0,0 @@
----
-id: P-REINFORCE-SEC-AUDIT
-category: "[[10_Wiki/💡 Topics/Security]]"
-confidence_score: 0.97
-tags: [Security Audits, Automation, Compliance, AI]
-last_reinforced: 2026-04-20
----
-
-# [[Automated-Security-Audits]] (자동 보안 감사)
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> "감사는 1년에 한 번 하는 행사가 아니라, 매 순간 일어나는 이벤트여야 한다." Continuous Security를 지향하는 현대적 보안 감사의 핵심 원칙이다.
-
-## 📖 구조화된 지식 (Synthesized Content)
-- **Policy as Code (PaC)**:
-    - 보안 규정(예: 모든 S3 버킷은 비공개여야 함)을 코드로 정의하고, 테라폼(Terraform)이나 쿠버네티스 배포 시 자동으로 검사한다.
-- **Compliance Monitoring**:
-    - ISO 27001, SOC2 같은 국제 표준 준수 여부를 실시간 대시보드로 확인하고, 규정 위반 시 자동으로 티켓을 생성한다.
-- **AI Pen-Testing**:
-    - AI 에이전트가 시스템의 약점을 수동태로 계속해서 찌르고 시뮬레이션하여(Red Teaming), 인간이 놓친 경로를 발굴한다.
-
-## ⚠️ 모순 및 업데이트 (RL Update)
-- 자동화는 효율적이지만 '제로 데이(Zero-day)' 취약점 앞에서는 무력할 수 있다. 자동 감사는 알려진 위협(Known unknowns)을 막는 방패이며, 알려지지 않은 위협(Unknown unknowns)은 화이트 해커의 창의적 수동 분석이 여전히 필요하다.
-
-## 🔗 지식 연결 (Graph)
-- Related: [[Security_Governance]] , [[SAST]]
-- Strategy: [[Reliability_Safety_First]]
diff --git a/AI/Automated-Theorem-Proving.md b/AI/Automated-Theorem-Proving.md
deleted file mode 100644
index 0666aa37..00000000
--- a/AI/Automated-Theorem-Proving.md
+++ /dev/null
@@ -1,27 +0,0 @@
----
-id: P-REINFORCE-AI-THEOREM
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.94
-tags: [Theorem Proving, Coq, Lean, Formal Verification]
-last_reinforced: 2026-04-20
----
-
-# [[Automated-Theorem-Proving]] (자동 정기 증명 ATP)
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> "코드가 맞다"고 믿는 것이 아니라, 수학적으로 "틀릴 수 없음"을 컴퓨터가 강제로 증명하게 만드는 소프트웨어 신뢰성의 정점이다.
-
-## 📖 구조화된 지식 (Synthesized Content)
-- **Hilbert's Program & Decidability**:
-    - 모든 수학적 명제를 기계적으로 판별할 수 있는지에 대한 질문에서 시작되었다. 비록 불완전성 정리에 의해 한계가 밝혀졌으나, 특정 영역에서의 자동 증명은 비약적으로 발전했다.
-- **Formal Verification (형식 검증)**:
-    - 운영체제 커널(seL4)이나 금융 스마트 컨트랙트처럼 단 하나의 버그도 허용되지 않는 곳에서, 프로그램이 사양(Specification)대로 동작함을 논리적으로 입증한다.
-- **Lean & Coq (Proof Assistants)**:
-    - 최근 AI(LLM)와 결합하여 인간이 수학 문제를 풀 듯 증명 과정을 생성하고 검증하는 '대화형 증명 도우미'가 대세다.
-
-## ⚠️ 모순 및 업데이트 (RL Update)
-- ATP는 엄청난 계산 자원을 소모하는 '탐색 문제'다. 모든 경로를 다 뒤지는 대신, 최근에는 신경망이 증명 전략(Tactics)을 제안하고 ATP가 이를 검증하는 하이브리드 방식이 각광받고 있다.
-
-## 🔗 지식 연결 (Graph)
-- Related: [[Automated-Reasoning]] , [[Amazon-AWS-Formal-Verification]]
-- Foundation: [[Computational Thinking]]
diff --git a/AI/Automated_Mapping.md b/AI/Automated_Mapping.md
deleted file mode 100644
index fc8bdd4a..00000000
--- a/AI/Automated_Mapping.md
+++ /dev/null
@@ -1,29 +0,0 @@
----
-id: P-REINFORCE-AI-004
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.91
-tags: [ai, slam, mapping, autonomous]
-last_reinforced: 2026-04-20
-github_commit: "batch-reinforce-05"
----
-
-# [[Automated Mapping & SLAM]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 미지의 공간을 탐사함과 동시에 자신의 위치를 파악하여 정밀한 지도를 그려내는 자율 주행의 눈과 지능.
-
-## 📖 구조화된 지식 (Synthesized Content)
-- **추출된 패턴:** LiDAR/카메라 데이터 퓨전을 통해 특징을 추출하고, 루프 폐쇄(Loop Closure)를 통해 지도 정합의 오차를 보정하며 전역 일관성을 확보하는 패턴.
-- **세부 내용:**
-    - 4단계 매핑 파이프라인: 데이터 획득 -> 특징 추출 -> 위상 구조 생성 -> 전역 최적화.
-    - 번들 조정(Bundle Adjustment)을 통한 그래프 기반 최적화 기법 적용.
-    - 고정밀(HD) 지도 자동 생성 및 실시간 업데이트 로직.
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 수동 지도 제작 방식에서 센서 기반의 완전 자율 매핑 시스템으로의 패러다임 변화.
-- **정책 변화:** 지식 구조(w2) 관점에서 자율 주행 에이전트의 '공간 지능' 핵심 요소로 정의.
-
-## 🔗 지식 연결 (Graph)
-- **Parent:** [[10_Wiki/💡 Topics/AI]]
-- **Related:** [[Computer_Vision]], [[VPS_NeRF]], [[Spatial-Computing]]
-- **Raw Source:** [[00_Raw/2026-04-20/Automated-Map-Generation.md]]
diff --git a/AI/Autonomous-Polling-Wait-Automation.md b/AI/Autonomous-Polling-Wait-Automation.md
deleted file mode 100644
index 91179239..00000000
--- a/AI/Autonomous-Polling-Wait-Automation.md
+++ /dev/null
@@ -1,35 +0,0 @@
----
-id: P-REINFORCE-AUTO-9B8C6B
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Autonomous-Polling-Wait-Automation"
----
-
-# [[Autonomous-Polling-Wait-Automation]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> Deep Research 작업의 완료를 에이전트가 스스로 감지하고, "가져오기" 버튼을 누를 필요 없이 즉시 데이터를 수집하는 지능형 대기 시스템입니다. 10초 단위의 상태 폴링(Polling)을 통해 NotebookLM의 작업 상태를 모니터링하며, 완료 시점에 즉각적으로 다음 단계(Synthesis)로 전이됩니다.
-
-## 📖 구조화된 지식 (Synthesized Content)
-NotebookLM의 'Deep Research' 기능은 대규모 데이터를 처리하므로 평균 3~10분의 시간이 소요됩니다. 이전 버전에서는 사용자가 브라우저를 모니터링하다가 수동으로 '합성하기' 버튼을 눌러야 루프가 이어졌으나, 이를 다음과 같이 자동화했습니다.
-
-1. **State Polling Interface**: `research_status` API를 호출하여 작업의 진행 상태를 JSON 형태로 실시간 수집합니다.
-2. **Hybrid Wait Strategy**: 
-    - **Auto Mode**: 최대 10분(60회 폴링) 동안 'completed' 상태를 추적하며, 감지 즉시 `research_import`를 실행합니다.
-    - **Manual Fallback**: 만약 10분이 지나도 완료되지 않거나 네트워크 오류가 발생하면, 시스템은 중단되지 않고 다시 '수동 대기' 모드로 전환되어 사용자의 판단을 기다립니다.
-3. **Promise-Level Sync**: JavaScript의 비동기 제어 구조(Async/Await)를 활용하여, 폴링 루프가 도는 동안 엔진의 메인 루프를 안전하게 일시 정지(Suspend) 시킵니다.
-
-이 자동화로 인해 에이전트는 진정한 의미의 '잠들지 않는 연구원'이 되었으며, 대규모 지식 수집 시 사용자의 피로도를 획기적으로 낮추었습니다.
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** AI 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[NotebookLM-Automated-Authentication-CLI]], [[Autonomous-Loop-State-Machine]]
-- **Projects/Contexts:** [[P-Reinforce-Agent-v2.6]]
-- **Contradictions/Notes:** 너무 잦은 폴링은 API 할당량(Quota) 이슈를 유발할 수 있으므로 10초 간격이 권장됩니다.
-- Raw Source: [[00_Raw/2026-04-20/Autonomous-Polling-Wait-Automation.md]]
----
diff --git a/AI/Autonomous-Vehicle-Path-Planning.md b/AI/Autonomous-Vehicle-Path-Planning.md
deleted file mode 100644
index e5373105..00000000
--- a/AI/Autonomous-Vehicle-Path-Planning.md
+++ /dev/null
@@ -1,27 +0,0 @@
----
-id: P-REINFORCE-AI-PATHPLAN
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.98
-tags: [Path Planning, A* Algorithm, Robotics, Autonomous Vehicle]
-last_reinforced: 2026-04-20
----
-
-# [[Autonomous-Vehicle-Path-Planning]] (자율주행 경로 계획)
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 경로 계획은 '가장 빠른 길'을 찾는 것이 아니라, '안전하고 부드러우며 예측 가능한' 움직임을 실시간으로 설계하는 확률적 탐색이다.
-
-## 📖 구조화된 지식 (Synthesized Content)
-- **Global Path Planning**:
-    - 출발지에서 목적지까지의 거시적인 경로를 설정한다. 고전적인 **A* (A-star)** 알고리즘이나 **Dijkstra** 알고리즘이 지도 데이터 위에서 작동한다.
-- **Local Motion Planning (실시간 회피)**:
-    - 갑자기 튀어나오는 보행자나 장애물을 피하기 위한 미시적인 궤적 최적화. **RRT* (Rapidly-exploring Random Tree)**나 **Hybrid A*** 등이 사용된다.
-- **Behavioral Decision (판단 레이어)**:
-    - 차선 변경, 추월, 일단 정지 등 도로의 법규(Traffic Laws)와 에티켓을 반영한 의사결정 알고리즘과 물리적 제어를 결합한다.
-
-## ⚠️ 모순 및 업데이트 (RL Update)
-- 과거에는 규칙 기반(Rule-based) 알고리즘이 주류였으나, 최근에는 복잡한 도심 상황을 해결하기 위해 'End-to-End' 딥러닝 방식과 '전통적 플래닝'을 결합한 계층적 구조가 표준으로 자리 잡았다.
-
-## 🔗 지식 연결 (Graph)
-- Related: [[Systemic_Simulation_Principles]] , [[Robotic Manipulation]]
-- Context: [[Digital Twins]]
diff --git a/AI/Axify.md b/AI/Axify.md
deleted file mode 100644
index 7a3221c1..00000000
--- a/AI/Axify.md
+++ /dev/null
@@ -1,33 +0,0 @@
----
-id: P-REINFORCE-AUTO-FB7EF7
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Axify"
----
-
-# [[Axify]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> Axify는 엔지니어링 리더와 소프트웨어 개발 팀의 생산성 및 배포 성과를 측정하고 최적화하도록 돕는 플랫폼입니다 [1-3]. DORA 지표, 가치 흐름 매핑(VSM), 개발자 생산성 등 다양한 소프트웨어 엔지니어링 지표를 실시간으로 추적 및 시각화합니다 [2, 4]. 특히 AI 기반 코드 리뷰 도구 등 새로운 기술의 도입이 개발 주기와 실제 배포 결과에 미치는 영향을 객관적인 데이터로 비교하고 분석하는 기능을 제공합니다 [5, 6].
-
-## 📖 구조화된 지식 (Synthesized Content)
-- **소프트웨어 딜리버리 및 지표 추적:** Axify는 DORA 지표 대시보드, 소프트웨어 엔지니어링 지표 추적, 목표 설정 및 진행률 보고 기능을 제공합니다 [2, 7]. 또한 가치 흐름 매핑(Value Stream Mapping)을 통해 전체 소프트웨어 개발 과정의 시각적 지도를 제공하여 배포 효율성을 높입니다 [2, 4].
-- **Axify Intelligence:** 엔지니어링 리더를 위한 AI 의사결정 파트너 기능입니다 [1, 2]. 범용 LLM과 달리 조직의 실제 저장소, 파이프라인, 과거 장애 기록 등 실제 전송 데이터를 기반으로 분석을 수행합니다 [8]. 지표가 변동된 원인을 설명하고 구체적인 워크플로우 조정 방안을 추천하며, 챗봇 인터페이스를 통해 사용자가 직접 질문하고 권장 조치를 적용할 수 있습니다 [8].
-- **AI 도입 영향(AI Impact) 측정:** AI 리뷰 에이전트와 같은 도구 도입 시, 단순한 사용량 지표(가짜 지표)가 아니라 팀 단위의 실제 PR(Pull Request) 주기 시간, 최초 리뷰까지의 시간, AI 지원 커밋 비율, 제안 수락률 등의 실질적 행동 변화를 추적합니다 [9-11]. 나아가 PR 데이터와 배포 데이터를 연결하여 배포 빈도 및 변경 리드 타임(Lead time for changes)이 AI 도입 전후로 어떻게 달라졌는지 명확한 추세 분석을 가능하게 합니다 [10, 12].
-- **통합성 및 활용 사례:** Slack, Microsoft Teams, Jira, Azure DevOps, GitHub, GitLab 등 개발팀이 널리 사용하는 기존 도구들과 원활하게 통합됩니다 [7]. Axify를 도입한 BDC는 최대 51%의 배포 속도 향상을, Newforma는 22배 많은 배포 성과를 달성한 사례가 있습니다 [13].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** AI 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[Axify Intelligence]], [[DORA Metrics]], [[Value Stream Mapping]]
-- **Projects/Contexts:** [[AI Adoption and Impact Measurement]], [[Developer Productivity Tracking]]
-- **Contradictions/Notes:** 소스 내에서 상충되는 의견은 발견되지 않았습니다. 다만 Axify는 새로운 AI 리뷰 도구를 단순히 설치하거나 제안 횟수 자체를 세는 것(Vanity metrics)만으로는 배포 개선을 증명할 수 없다고 지적하며, 실제 성과(DORA 지표 등)로 이어지는지 측정하는 것의 중요성을 강조합니다 [5, 9, 14].
-
----
-*Last updated: 2026-04-18*
-- Raw Source: [[00_Raw/2026-04-20/Axify.md]]
----
diff --git a/AI/Azure DevOps.md b/AI/Azure DevOps.md
deleted file mode 100644
index ef56a839..00000000
--- a/AI/Azure DevOps.md	
+++ /dev/null
@@ -1,35 +0,0 @@
----
-id: P-REINFORCE-AUTO-6BDC0C
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Azure DevOps"
----
-
-# [[Azure DevOps]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 소스에 관련 정보가 부족합니다. 주어진 소스에서는 Azure DevOps 자체에 대한 구체적인 정의나 기능에 대한 설명이 없으며, 단지 다른 소프트웨어 분석 및 관리 도구들이 연동을 지원하는 여러 개발 플랫폼 중 하나로만 간략히 언급되어 있습니다 [1, 2].
-
-## 📖 구조화된 지식 (Synthesized Content)
-소스에 관련 정보가 부족합니다. 
-
-제공된 소스에서 파악할 수 있는 Azure DevOps에 대한 단편적인 정보는 다음과 같습니다:
-* **도구 통합(Integrations) 플랫폼으로서의 활용:**
-  * AI 코드 리뷰 및 코드 품질/보안 검증 도구인 **SonarQube**는 개발자의 워크플로우를 지원하기 위해 GitHub, Bitbucket, GitLab 등과 함께 Azure DevOps와의 통합을 제공합니다 [1].
-  * 소프트웨어 엔지니어링 팀의 DORA 지표 측정 및 생산성 분석 도구인 **Axify** 또한 Slack, Microsoft Teams, Jira 등의 도구와 더불어 Azure DevOps와의 연동을 지원합니다 [2].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** AI 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[SonarQube]], [[Axify]]
-- **Projects/Contexts:** 외부 AI 코드 리뷰 도구 및 엔지니어링 생산성 분석 대시보드와의 파트너십 및 시스템 통합(Integration) 맥락 환경 [1, 2]
-- **Contradictions/Notes:** 소스에 관련 정보가 부족합니다.
-
----
-*Last updated: 2026-04-19*
-- Raw Source: [[00_Raw/2026-04-20/Azure DevOps.md]]
----
diff --git a/AI/B-Tree.md b/AI/B-Tree.md
deleted file mode 100644
index 2bcdb905..00000000
--- a/AI/B-Tree.md
+++ /dev/null
@@ -1,27 +0,0 @@
----
-id: P-REINFORCE-AI-B-TREE
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.99
-tags: [B-Tree, Data Structure, DB, Indexing]
-last_reinforced: 2026-04-20
----
-
-# [[B-Tree]] (B-트리)
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> "디스크의 느린 속도를 이겨내는 최적의 균형." 한 노드에 여러 데이터를 담고 층수를 낮게 유지하여, 수백만 건의 데이터도 단 3~4번의 읽기만으로 찾아내는 인덱스의 제왕이다.
-
-## 📖 구조화된 지식 (Synthesized Content)
-- **Multi-way Search Tree**:
-    - 이진 트리(2-way)와 달리 노드 하나가 수십~수백 개의 자식을 가질 수 있다. 이를 통해 트리의 높이(Height)를 극적으로 낮춘다.
-- **Self-Balancing**:
-    - 데이터가 추가되거나 삭제될 때마다 스스로 노드를 분할(Split)하거나 합치며(Merge) 높이 균형을 유지한다. 언제나 탐색 속도가 보장된다.
-- **Disk I/O Efficiency**:
-    - 노드 한 개의 크기를 하드디스크의 한 블록(Page) 크기에 맞춰 설계하여, 한 번의 스핀으로 최대한 많은 정보를 읽어오게 한다.
-
-## ⚠️ 모순 및 업데이트 (RL Update)
-- 현대의 SSD 환경에서는 랜덤 액세스 속도가 빨라져서 B-Tree 계열 외에도 LSM-Tree(NoSQL 등에서 사용) 같은 다양한 변종이 사용된다. 하지만 여전히 관계형 DB(MySQL, PostgreSQL)의 기본 인덱스는 B+Tree(B-Tree의 계층형 변형)가 압도적 표준이다.
-
-## 🔗 지식 연결 (Graph)
-- Related: [[Distributed-Systems-Engineering]] , [[Combinatorial-Optimization]]
-- Foundation: [[Computational Thinking]]
diff --git a/AI/Backpropagation.md b/AI/Backpropagation.md
deleted file mode 100644
index c02aa66f..00000000
--- a/AI/Backpropagation.md
+++ /dev/null
@@ -1,27 +0,0 @@
----
-id: P-REINFORCE-AI-BACKPROP
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 1.0
-tags: [Backpropagation, Deep Learning, Gradient Descent, Optimization]
-last_reinforced: 2026-04-20
----
-
-# [[Backpropagation]] (역전파)
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> "실수를 뒤에서부터 고쳐 나가는 지혜." 출력층에서 발생한 오차(Loss)가 각 신경망 층의 가중치(Weight)에 얼마나 기여했는지 거꾸로 계산하며 효율적으로 학습시키는 딥러닝의 핵심 학습 메커니즘이다.
-
-## 📖 구조화된 지식 (Synthesized Content)
-- **Chain Rule (미분의 연쇄 법칙)**:
-    - 전체 오차를 각 파라미터로 미분하기 위해, 각 단계의 부분 미분값을 곱해 나가는 미적분학적 과정.
-- **Gradient Computation**:
-    - 모든 파라미터에 대한 경사도(Gradient)를 한 번에 계산하여, 경사 하강법(Gradient Descent)을 통해 신경망을 정답에 가깝게 업데이트한다.
-- **Efficiency**:
-    - 모든 파라미터를 개별적으로 미분하는 것보다 수백만 배 빠르며, 이로 인해 수조 개의 파라미터를 가진 거대 모델의 학습이 가능해졌다.
-
-## ⚠️ 모순 및 업데이트 (RL Update)
-- 층이 너무 깊어지면 미분값이 0으로 사라지는 'Vanishing Gradient' 문제가 발생한다. 이를 위해 ReLU 활성화 함수나 ResNet 같은 잔차 연결(Residual Connection) 기술이 보완적으로 사용된다.
-
-## 🔗 지식 연결 (Graph)
-- Related: [[Deep-Learning-Architecture-Patterns]] , [[Gradient-Descent]]
-- Foundation: [[Computational Theory & Math/Information Theory]]
diff --git a/AI/Baseline Project.md b/AI/Baseline Project.md
deleted file mode 100644
index e4bd1ebb..00000000
--- a/AI/Baseline Project.md	
+++ /dev/null
@@ -1,35 +0,0 @@
----
-id: P-REINFORCE-AUTO-E3E3EF
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Baseline Project"
----
-
-# [[Baseline Project]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> Baseline Project는 Chrome, Edge, Firefox, Safari 등 주요 웹 브라우저에서 최소 30개월 이상 지속적으로 지원된 '널리 사용 가능한 브라우저 API(widely available browser APIs)'를 정의하는 프로젝트입니다 [1]. 이 프로젝트는 특정 웹 플랫폼 기능이 언제부터 모든 주요 브라우저에서 안전하게 사용될 수 있는지에 대한 타임라인을 제공하여 개발자들을 돕습니다 [1]. 브라우저의 네이티브 지원이 확대되어 베이스라인 기능이 늘어나면, 대체용 JavaScript 사용량이 줄어들어 결과적으로 웹 성능이 향상되는 이점이 있습니다 [2].
-
-## 📖 구조화된 지식 (Synthesized Content)
-- **정의 및 기준:** Baseline Project는 Chrome, Edge, Firefox, Safari 브라우저 모두에서 최소 30개월 동안 지원된 브라우저 API 기능들을 묶어 '널리 사용 가능한(widely available)' 기능으로 정의합니다 [1]. 
-- **성능 측정과 타임라인:** 지원되는 API 중 일부는 비교적 최근에 추가된 것일 수 있으며, Rick Viscomi가 만든 웹사이트를 통해 다양한 기능들이 언제 베이스라인으로 편입되었거나 될 예정인지 보여주는 타임라인을 확인할 수 있습니다 [1]. 예를 들어, Safari가 2023년에 '리소스 크기 측정(Measuring resources size)'과 '서버 타이밍 수집(Collecting server timings)' 기능 지원을 개선함에 따라, 해당 기능들은 2025년 9월을 기점으로 베이스라인이 되었습니다 [1, 2].
-- **주요 편입 기능 및 향후 예정:** 
-  - 컨테이너 쿼리(container queries), CompressionStream API, MathML 렌더링 기능은 2025년부터 널리 사용 가능한 베이스라인으로 편입되었습니다 [2].
-  - 이미지 포맷인 AVIF는 2026년 7월에 널리 사용 가능한 상태가 될 것이며, 리소스 로딩 우선순위를 정하는 `fetchpriority` 속성은 2027년 4월에 베이스라인에 편입될 예정입니다 [3].
-- **웹 성능에 미치는 영향:** 새로운 기능들이 네이티브 웹 플랫폼에서 널리 지원되어 베이스라인 수준에 도달하면, 이를 구현하기 위해 필요했던 JavaScript 코드의 양이 줄어들게 되어 결과적으로 더 나은 웹 성능을 제공할 수 있게 됩니다 [2].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** AI 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[Browser APIs]], [[Web Performance]]
-- **Projects/Contexts:** [[Web Platform Features]]
-- **Contradictions/Notes:** 소스에 관련 정보가 부족합니다.
-
----
-*Last updated: 2026-04-19*
-- Raw Source: [[00_Raw/2026-04-20/Baseline Project.md]]
----
diff --git a/AI/Bayesian Inference.md b/AI/Bayesian Inference.md
deleted file mode 100644
index e6c60eaa..00000000
--- a/AI/Bayesian Inference.md	
+++ /dev/null
@@ -1,29 +0,0 @@
----
-id: P-REINFORCE-AI-BAYESIAN
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.98
-tags: [Bayesian Inference, Probability, Stats, AI]
-last_reinforced: 2026-04-20
----
-
-# [[Bayesian-Inference]] (베이지안 추론)
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> "믿음은 고정된 것이 아니라 정보에 따라 진화한다." 기존의 배경 지식(Prior)에 새로운 근거(Evidence)를 더해 더 정확한 진실(Posterior)에 다가가는 통계학적 통찰이다.
-
-## 📖 구조화된 지식 (Synthesized Content)
-- **Prior Probability (사전 확률)**:
-    - 새로운 데이터를 보기 전에 우리가 이미 알고 있는 지식이나 가설의 확률.
-- **Likelihood (우도)**:
-    - 어떤 가설이 참일 때, 현재 관찰된 데이터가 나타날 확률.
-- **Posterior Probability (사후 확률)**:
-    - 새로운 데이터를 반영한 후 업데이트된 우리의 최종 믿음.
-- **Application**:
-    - 스팸 메일 필터링, 의료 진단, 자율주행 차의 센서 융합 등 불확실성이 큰 환경의 의사결정에 필수적이다.
-
-## ⚠️ 모순 및 업데이트 (RL Update)
-- 베이지안 추론은 '사전 확률'을 설정할 때 주관이 개입된다는 비판을 받기도 한다(빈도주의 통계학과의 논쟁). 하지만 데이터가 적은 초기 상태에서는 베이지만큼 강력한 예측 도구가 없다.
-
-## 🔗 지식 연결 (Graph)
-- Related: [[Automated-Reasoning]] , [[Behavioral-Economics]]
-- Foundation: [[Computational Theory & Math/Information Theory]]
diff --git a/AI/Behavioral Finance.md b/AI/Behavioral Finance.md
deleted file mode 100644
index 08b6a40c..00000000
--- a/AI/Behavioral Finance.md	
+++ /dev/null
@@ -1,27 +0,0 @@
----
-id: P-REINFORCE-AI-FINANCE
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.98
-tags: [Behavioral Finance, Psychology, Market, Investment]
-last_reinforced: 2026-04-20
----
-
-# [[Behavioral-Finance]] (행동 재무학)
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 주식 시장은 '가치'가 아니라 '군중의 광기와 공포'에 의해 움직이며, 이 비합리적 패턴을 수학적으로 모델링하여 초과 수익(Alpha)을 찾는 학문이다.
-
-## 📖 구조화된 지식 (Synthesized Content)
-- **Overconfidence Bias (자기과신 편향)**:
-    - 자신이 평균보다 정보를 더 잘 해석한다고 믿는 착각. 이로 인해 과도한 거래가 발생하고 수수료로 수익이 깎이는 현상이 발생한다.
-- **Herd Behavior (群集 심리)**:
-    - 뚜렷한 근거 없이 남들이 사니까 따라 사는 것. 버블(Bubble)이 형성되고 붕괴되는 심리적 메커니즘의 핵심이다.
-- **Mental Accounting (심적 회계)**:
-    - 공짜로 얻은 돈과 힘들게 번 돈을 다르게 대하는 태도. 도박꾼의 오류(Gambler's Fallacy)와 연결되어 비합리적인 베팅을 유도한다.
-
-## ⚠️ 모순 및 업데이트 (RL Update)
-- 행동 재무학은 시장의 비합리성을 말하지만, 이를 이용해 돈을 버는 것은 또 다른 문제다(효율적 시장 가설과의 충돌). 최근에는 AI를 통해 소셜 미디어의 감정(Sentiment)을 분석하여 군중 심리를 정량화하는 고도화된 퀀트(Quant) 전략이 사용된다.
-
-## 🔗 지식 연결 (Graph)
-- Related: [[Behavioral-Economics]] , [[Game Design Theory]]
-- Foundation: [[Information Theory]]
diff --git a/AI/Behavioral-Economics.md b/AI/Behavioral-Economics.md
deleted file mode 100644
index 79d13f98..00000000
--- a/AI/Behavioral-Economics.md
+++ /dev/null
@@ -1,27 +0,0 @@
----
-id: P-REINFORCE-AI-BEHAVE
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.97
-tags: [Behavioral Economics, Human Factor, Nudge, Psychology]
-last_reinforced: 2026-04-20
----
-
-# [[Behavioral-Economics]] (행동 경제학)
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 인간은 합리적이지 않다. 다만 '예측 가능하게 비합리적'일 뿐이다. 이 비합리성의 패턴을 이해하는 것이 최고의 사용자 경험(UX)을 만드는 열쇠다.
-
-## 📖 구조화된 지식 (Synthesized Content)
-- **Loss Aversion (손실 회피)**:
-    - 10,000원을 얻었을 때의 기쁨보다 10,000원을 잃었을 때의 고통이 훨씬 크다. 이 기제로 인해 사람들은 변화를 거부하고 형상 유지(Status Quo Bias)를 선호한다.
-- **Anchoring Effect (닻 내림 효과)**:
-    - 처음 제시된 정보(가격 등)가 기준점이 되어 이후 모든 판단에 영향을 준다. 할인 전 가격을 크게 써놓는 상술의 근거다.
-- **Nudge (넛지)**:
-    - 명령이나 금지가 아니라, 선택 설계(Choice Architecture)를 통해 타인의 행동을 부드럽게 유도하는 기술 (예: 소변기의 파리 그림, 디폴트 옵션 설정).
-
-## ⚠️ 모순 및 업데이트 (RL Update)
-- 행동 경제학의 실험들은 최근 '재현성 위기'를 겪고 있다. 특정 실험실 환경에서의 결과가 실제 웹 환경이나 문화권마다 다르게 나타날 수 있음을 인지하고, 항상 자사 서비스에서의 자가 테스트(A/B Test)가 병행되어야 한다.
-
-## 🔗 지식 연결 (Graph)
-- Related: [[Nudge Theory]] , [[A_B-Testing-Platforms]]
-- Design: [[Design_Psychology]]
diff --git a/AI/Bellman Equation.md b/AI/Bellman Equation.md
deleted file mode 100644
index f8047c6e..00000000
--- a/AI/Bellman Equation.md	
+++ /dev/null
@@ -1,27 +0,0 @@
----
-id: P-REINFORCE-AI-BELLMAN
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.99
-tags: [Bellman Equation, Reinforcement Learning, Math, Dynamic Programming]
-last_reinforced: 2026-04-20
----
-
-# [[Bellman-Equation]] (벨만 방정식)
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> "오늘의 보상(Step reward) + 내일의 가치(Future value) = 오늘의 가치." 시간의 흐름 속에 흩어진 가치를 하나로 묶어주는 재귀의 미학이다.
-
-## 📖 구조화된 지식 (Synthesized Content)
-- **Recursive Utility**:
-    - 현재 상태의 가치(Value)를 '즉각적 보상'과 '다음 상태의 기대 가치'의 합으로 정의한다. 이는 복잡한 미래 결정을 작은 현재 결정으로 쪼개어 풀 수 있게 한다.
-- **Dynamic Programming (동적 계획법)**:
-    - 벨만 방정식은 큰 문제를 작은 부분 문제로 나누어 푸는 근간이 된다. 바둑(AlphaGo)이나 체스 AI의 핵심 연산 원리다.
-- **Discount Factor (Gamma)**:
-    - 미래의 가치를 현재 시점으로 환산할 때 얼마나 깎을지(가중치)를 결정하는 변수. 1에 가까울수록 먼 미래를 보고, 0에 가까울수록 당장의 이익에 집중한다.
-
-## ⚠️ 모순 및 업데이트 (RL Update)
-- 실제 세계(Model-free)에서는 다음 상태의 가치를 정확히 알 수 없다. 그래서 벨만 방정식을 기반으로 경험을 통해 가치를 추측해가는 'Q-Learning'이나 'Deep Q-Networks(DQN)'로 발전해왔다.
-
-## 🔗 지식 연결 (Graph)
-- Related: [[Reinforcement Learning]] , [[Deep-Reinforcement-Learning]]
-- Foundation: [[Computational Theory & Math/Information Theory]]
diff --git a/AI/Bellman-Equation.md b/AI/Bellman-Equation.md
deleted file mode 100644
index 5b794cd4..00000000
--- a/AI/Bellman-Equation.md
+++ /dev/null
@@ -1,27 +0,0 @@
----
-id: P-REINFORCE-AI-BELLMAN
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 1.0
-tags: [Bellman Equation, Reinforcement Learning, Dynamic Programming, MDP]
-last_reinforced: 2026-04-20
----
-
-# [[Bellman-Equation]] (벨만 방정식)
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> "오늘의 선택은 내일의 가치를 품고 있다." 현재 상태의 가치를 '현재 받는 보상'과 '다음 상태의 기대 가치'의 합으로 정의하는 강화학습과 동적 계획법의 수학적 초석이다.
-
-## 📖 구조화된 지식 (Synthesized Content)
-- **Recursive Structure**:
-    - 복잡한 미래의 합을 현재와 바로 다음 단계의 관계로 쪼갬으로써, 거대한 의사결정 문제를 계산 가능한 단위로 분해한다.
-- **State-Value Function (V)**:
-    - 특정 상태에 있는 것이 장기적으로 볼 때 얼마나 좋은지 수치화한다.
-- **Action-Value Function (Q)**:
-    - 특정 상태에서 특정 행동을 하는 것이 얼마나 좋은지 수치화하며, 이는 Q-Learning의 핵심이 된다.
-
-## ⚠️ 모순 및 업데이트 (RL Update)
-- 벨만 방정식은 환경의 변화를 완벽히 안다는 가정하에 작동한다. 실제 세상처럼 환경이 불투명할 때는 근사치(Approximation)를 사용하는 Deep Q-Network(DQN) 등이 대안으로 사용된다.
-
-## 🔗 지식 연결 (Graph)
-- Related: [[DQN]] , [[Reinforcement-Learning]]
-- Foundation: [[Computational Theory & Math/Information Theory]]
diff --git a/AI/Bert-Language-Model.md b/AI/Bert-Language-Model.md
deleted file mode 100644
index 36cbb1c5..00000000
--- a/AI/Bert-Language-Model.md
+++ /dev/null
@@ -1,27 +0,0 @@
----
-id: P-REINFORCE-AI-BERT
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.99
-tags: [BERT, NLP, Transformer, Language Model, Transfer Learning]
-last_reinforced: 2026-04-20
----
-
-# [[Bert-Language-Model]] (BERT 언어 모델)
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> "단어의 앞뒤 맥락을 동시에 읽는 천재." 문장을 왼쪽에서 오른쪽으로만 읽던 기존 방식을 탈피하여, 양방향(Bidirectional)으로 문맥을 파악해 언어 이해 능력을 극대화한 트랜스포머 기반 모델이다.
-
-## 📖 구조화된 지식 (Synthesized Content)
-- **Masked Language Model (MLM)**:
-    - 문장의 일부 단어를 가리고(Masking), 주변 단어들을 통해 가려진 단어를 맞추는 방식으로 언어의 구조를 스스로 학습한다.
-- **Next Sentence Prediction (NSP)**:
-    - 두 문장이 이어지는 문장인지 판단하는 태스크를 통해 문장 간의 관계와 논리적 흐름을 파악한다.
-- **Transfer Learning**:
-    - 방대한 텍스트로 미리 학습(Pre-training)된 BERT를 특정 작업(질의응답, 감성 분석 등)에 맞춰 살짝 미세 조정(Fine-tuning)하여 최강의 성능을 낸다.
-
-## ⚠️ 모순 및 업데이트 (RL Update)
-- BERT는 '이해'는 뛰어나지만 '생성(Generation)'에는 적합하지 않다. 생성형 AI 시대에는 GPT 같은 디코더(Decoder) 기반 모델이 주류지만, 검색이나 분류 같은 분석 작업에서는 여전히 BERT가 가성비 최고의 왕좌를 지키고 있다.
-
-## 🔗 지식 연결 (Graph)
-- Related: [[Transformer-Architecture]] , [[Natural-Language-Processing]]
-- Context: [[Artificial-Intelligence]]
diff --git a/AI/Best SAST Tools in 2026.md b/AI/Best SAST Tools in 2026.md
deleted file mode 100644
index a95f7e1e..00000000
--- a/AI/Best SAST Tools in 2026.md	
+++ /dev/null
@@ -1,29 +0,0 @@
----
-id: P-REINFORCE-SEC-TOOLS
-category: "[[10_Wiki/💡 Topics/Security]]"
-confidence_score: 0.98
-tags: [SAST, Security Tools, 2026, Snyk, SonarQube]
-last_reinforced: 2026-04-20
----
-
-# [[Best-SAST-Tools-in-2026]] (2026년 최고의 SAST 도구)
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> "도구는 똑똑해졌고, 개발자는 더 안전해졌다." 2026년 현재, 단순 패턴 매칭을 넘어 코드의 '의도'를 파악하는 AI 기반 보안 도구가 시장을 지배하고 있다.
-
-## 📖 구조화된 지식 (Synthesized Content)
-- **SonarQube (Professional Edition)**:
-    - 코드 품질과 결합된 전통의 강자. 최근 딥러닝 엔진을 탑재하여 정교한 데이터 흐름 분석 기능을 강화했다.
-- **Snyk (Developer First)**:
-    - 개발자 친화적인 UI와 강력한 오픈소스 라이브러리 취약점 관리(SCA)를 동시에 제공한다. PR 단계에서 즉각적인 수정을 제안한다.
-- **Checkmarx One**:
-    - 엔터프라이즈 환경에서 수천 개의 마이크로서비스를 통합 관리할 수 있는 가시성을 제공한다.
-- **GitHub Advanced Security (CodeQL)**:
-    - 깃허브 네이티브 환경에서 코드를 쿼리처럼 검색하여 취약점을 찾는 독보적인 기능을 제공한다.
-
-## ⚠️ 모순 및 업데이트 (RL Update)
-- 최고 사양의 도구를 도입하더라도, 조직의 '문화(DevSecOps)'가 뒷받침되지 않으면 무용지물이다. 경고를 무시하지 않고 즉각 대응하는 거버넌스(Governance) 프로세스가 도구의 성능보다 중요하다.
-
-## 🔗 지식 연결 (Graph)
-- Related: [[SAST (Static Application Security Testing)]] , [[Deployment_Final_Gate]]
-- Context: [[Modern_Environment_Ecosystem]]
diff --git a/AI/Best-of-N Sampling ( ø).md b/AI/Best-of-N Sampling ( ø).md
deleted file mode 100644
index 72debf7e..00000000
--- a/AI/Best-of-N Sampling ( ø).md	
+++ /dev/null
@@ -1,27 +0,0 @@
----
-id: P-REINFORCE-AI-BESTN
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.98
-tags: [LLM, Sampling, Best-of-N, Search, Generation]
-last_reinforced: 2026-04-20
----
-
-# [[Best-of-N-Sampling]] (베스트 오브 N 샘플링)
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> "열 번 찍어 안 넘어가는 나무 없다." AI에게 N번 시도하게 하고, 그중 가장 '정답에 가까운' 결과물을 보상 모델(Reward Model)로 골라내는 필승 전략이다.
-
-## 📖 구조화된 지식 (Synthesized Content)
-- **추론 시간 연산 (Inference-time Compute)**:
-    - 모델의 크기를 키우는 대신, 추론 시점에 더 많은 계산을 수행하여 답변의 품질을 높이는 기법. 최근 OpenAI o1 등 추론 모델의 핵심 원리 중 하나다.
-- **Reward Modeling (RM)**:
-    - N개의 답변 중 어떤 것이 가장 좋은지 판별하는 별도의 '감별사 AI'를 투입한다. 인간의 선호도(RLHF)를 반영한 RM이 최종 선택을 담당한다.
-- **Majority Voting vs Selection**:
-    - 수학 문제라면 답변들 중 가장 많이 나온 값(Majority Vote)을 택하고, 창의적 답변이라면 RM 스코어가 가장 높은 것을 택한다.
-
-## ⚠️ 모순 및 업데이트 (RL Update)
-- N이 클수록 품질은 올라가지만 비용과 응답 지연 시간(Latency)이 기하급수적으로 늘어난다. 실시간 서비스에서는 N=3~5 수준의 타협점이 요구되며, 최근에는 자가 수정(Self-correction) 능력을 키우는 쪽으로 연구가 이동 중이다.
-
-## 🔗 지식 연결 (Graph)
-- Related: [[Reinforcement Learning]] , [[AI 모델 평가]]
-- Context: [[Information Theory]]
diff --git a/AI/Best-of-N Sampling (최적 샘플링).md b/AI/Best-of-N Sampling (최적 샘플링).md
deleted file mode 100644
index 0688a7be..00000000
--- a/AI/Best-of-N Sampling (최적 샘플링).md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-F28615
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Best-of-N Sampling (최적 샘플링)"
----
-
-# [[Best-of-N Sampling (최적 샘플링)]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** AI 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Best-of-N Sampling (최적 샘플링).md]]
----
diff --git a/AI/Best-of-N Sampling.md b/AI/Best-of-N Sampling.md
deleted file mode 100644
index 8bc95677..00000000
--- a/AI/Best-of-N Sampling.md	
+++ /dev/null
@@ -1,27 +0,0 @@
----
-id: P-REINFORCE-AI-BEST-OF-N
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.99
-tags: [Best-of-N, Sampling, Inference, Reward Model, AI Alignment]
-last_reinforced: 2026-04-20
----
-
-# [[Best-of-N-Sampling]] (Best-of-N 샘플링)
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> "열 정승보다 나은 한 명의 장군 찾기." LLM이 생성한 N개의 결과물 중, 보상 모델(Reward Model)이 가장 우수하다고 판단한 단 하나의 답변을 선택하여 품질을 극대화하는 추론 전략이다.
-
-## 📖 구조화된 지식 (Synthesized Content)
-- **Generation & Scoring**:
-    - 동일한 프롬프트에 대해 정책 모델(Policy)이 여러 개의 독립된 답변을 생성하고, 이를 별도의 채점 모델(Reward)이 평가한다.
-- **Inference Time Compute**:
-    - 모델을 더 키우는 대신 '추론 단계의 연산량'을 늘려 성능을 향상시키는 경제적인 성능 고도화 방법(Scaling Laws for Inference).
-- **Quality Control**:
-    - 환각이 발생한 답변이나 안전 가이드라인을 어긴 답변을 필터링하고 가장 논리적인 결과물을 도출한다.
-
-## ⚠️ 모순 및 업데이트 (RL Update)
-- N이 커질수록 품질은 좋아지지만 코스트(비용)와 지연 시간(Latency)이 기하급수적으로 늘어난다. 따라서 서비스의 실시간성 요구도에 따라 N의 적절한 값을 정하는 것이 엔지니어링의 묘미다.
-
-## 🔗 지식 연결 (Graph)
-- Related: [[Prompt-Engineering]] , [[Reinforcement-Learning-from-Human-Feedback-(RLHF)]]
-- Metric: [[Reward-Model-Training]]
diff --git a/AI/Bias-Correction-Algorithm.md b/AI/Bias-Correction-Algorithm.md
deleted file mode 100644
index 920d88e7..00000000
--- a/AI/Bias-Correction-Algorithm.md
+++ /dev/null
@@ -1,27 +0,0 @@
----
-id: P-REINFORCE-AI-BIAS-CORR
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.98
-tags: [Bias Correction, AI Ethics, Algorithmic Fairness, Statistics]
-last_reinforced: 2026-04-20
----
-
-# [[Bias-Correction-Algorithm]] (편향 보정 알고리즘)
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> "데이터의 편견은 모델의 차별이 된다." 특정 인구통계학적 특성에 치우친 데이터를 수학적으로 재조정하여, AI가 공정하고 객관적인 판결을 내리도록 강제하는 기술적 윤리 장치다.
-
-## 📖 구조화된 지식 (Synthesized Content)
-- **Pre-processing Techniques**:
-    - 학습 전 데이터셋에서 편향된 샘플의 가중치를 조절하거나(Reweighing), 정보를 제거하여 모델이 편견을 학습하지 못하게 한다.
-- **In-processing Approaches**:
-    - 손실 함수(Loss function)에 '공정성 제약 조건'을 추가하여, 정확도뿐만 아니라 공정성 점수도 함께 최적화한다.
-- **Post-processing Calibration**:
-    - 모델의 예측 결과가 나온 뒤, 특정 집단에 대해 임계값(Threshold)을 조정하여 최종 출력의 균형을 맞춘다.
-
-## ⚠️ 모순 및 업데이트 (RL Update)
-- 과도한 편향 보정은 모델의 전반적인 정확도(Accuracy)를 떨어뜨릴 수 있다. '정확도와 공정성 사이의 트레이드오프'를 비즈니스 가치에 맞게 합의하는 의사결정이 기술보다 더 중요하다.
-
-## 🔗 지식 연결 (Graph)
-- Related: [[AI-Ethics]] , [[Bias-Variance-Tradeoff]]
-- Strategy: [[Reliability_Safety_First]]
diff --git a/AI/Bias-Variance-Tradeoff.md b/AI/Bias-Variance-Tradeoff.md
deleted file mode 100644
index 21093563..00000000
--- a/AI/Bias-Variance-Tradeoff.md
+++ /dev/null
@@ -1,27 +0,0 @@
----
-id: P-REINFORCE-AI-BIAS-VAR
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 1.0
-tags: [Bias Variance Tradeoff, Overfitting, Underfitting, Machine Learning]
-last_reinforced: 2026-04-20
----
-
-# [[Bias-Variance-Tradeoff]] (편향-분산 트레이드오프)
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> "너무 단순해도, 너무 복잡해도 망한다." 모델이 데이터를 너무 대충 배워 생기는 오차(Bias)와, 너무 깐깐하게 배워 생기는 오차(Variance) 사이의 황금 밸런스를 찾는 머신러닝의 숙명적 과제다.
-
-## 📖 구조화된 지식 (Synthesized Content)
-- **High Bias (Underfitting)**:
-    - 모델이 너무 단순하여 데이터의 본질적 패턴을 잡지 못함. (예: 곡선을 직선으로 설명하려 할 때)
-- **High Variance (Overfitting)**:
-    - 모델이 너무 복잡하여 데이터의 노이즈까지 다 외워버림. 새로운 데이터를 넣으면 엉뚱한 결과가 나옴.
-- **Total Error Reduction**:
-    - 편향과 분산의 합이 최소가 되는 지점이 바로 모델의 일반화 성능(Generalization)이 가장 높은 구간이다.
-
-## ⚠️ 모순 및 업데이트 (RL Update)
-- 최근의 초거대 모델(LLM)들은 'Double Descent' 현상에 의해, 모델을 극한으로 키우면 오히려 분산이 다시 줄어들며 성능이 좋아지는 기이한 현상이 발견되고 있다. 이는 전통적인 트레이드오프 이론을 재정립하게 만들고 있다.
-
-## 🔗 지식 연결 (Graph)
-- Related: [[Regularization-Techniques]] , [[Model-Optimization-Strategies]]
-- Foundation: [[Computational Theory & Math/Information Theory]]
diff --git a/AI/BioShock (2007).md b/AI/BioShock (2007).md
deleted file mode 100644
index f2f4d10a..00000000
--- a/AI/BioShock (2007).md	
+++ /dev/null
@@ -1,27 +0,0 @@
----
-id: P-REINFORCE-AI-BIOSHOCK
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.98
-tags: [BioShock, Game AI, Immersive Sim, Narrative AI]
-last_reinforced: 2026-04-20
----
-
-# [[BioShock-(2007)]] (바이오쇼크의 서사적 AI)
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> "생태계가 살아있는 것처럼 느껴지게 하라." 바이오쇼크의 AI는 플레이어를 사냥하는 적이 아니라, 자기들만의 규칙(Big Daddy-Little Sister)에 따라 살아가는 '유기적인 배우'들이다.
-
-## 📖 구조화된 지식 (Synthesized Content)
-- **Ecological Interaction (생태계적 상호작용)**:
-    - AI가 플레이어에게만 반응하는 것이 아니라, 세계관 내의 다른 AI들과 특유의 관계(보호-수집)를 맺으며 독자적인 '상태 기계(FSM)'를 돌린다.
-- **Environmental Narrative (환경적 서사)**:
-    - AI의 배치와 일상적인 행동 자체가 랩처(Rapture)라는 몰락한 도시의 비극을 설명하는 장치로 활용된다.
-- **Emergent Gameplay**:
-    - 플라스미드(능력)와 AI의 속성이 충돌하며 플레이어가 예상치 못한 전략(예: 해킹된 터렛으로 빅대디 유인)을 창출하게 만든다.
-
-## ⚠️ 모순 및 업데이트 (RL Update)
-- 지금 보면 바이오쇼크의 AI는 매우 단순한 규칙 기반 시스템이다. 하지만 '서사(Narrative)'와 결합했을 때, 그 단순함은 오히려 예측 가능한 몰입감을 제공했다. 현대의 비선형적 AI보다 '의도된 연출'이 게임 디자인에서 얼마나 강력한지 보여주는 사례다.
-
-## 🔗 지식 연결 (Graph)
-- Related: [[BioShock-Critique]] , [[Game Design Theory]]
-- Foundation: [[Collective-Intelligence]]
diff --git a/AI/BioShock-Critique.md b/AI/BioShock-Critique.md
deleted file mode 100644
index 4380ec76..00000000
--- a/AI/BioShock-Critique.md
+++ /dev/null
@@ -1,27 +0,0 @@
----
-id: P-REINFORCE-AI-BIOSHOCK-CRIT
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.96
-tags: [BioShock, Critique, Ludonarrative Dissonance, Game Design]
-last_reinforced: 2026-04-20
----
-
-# [[BioShock-Critique]] (바이오쇼크 비평)
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> "이야기는 자유를 갈구하지만, 시스템은 살육을 강요한다." 루도내러티브 디스너넌스(Ludonarrative Dissonance)라는 용어를 대중화시킨 불완전한 걸작이다.
-
-## 📖 구조화된 지식 (Synthesized Content)
-- **Ludonarrative Dissonance**:
-    - 대의(Objectivism 비판)를 말하는 서사와 닥치는 대로 자원을 약탈하고 살인하는 게임 시스템 간의 괴리. 클린트 호킹이 이 지점에서 바이오쇼크를 날카롭게 비판했다.
-- **False Agency (거짓 주체성)**:
-    - "Would you kindly?" 반전은 플레이어의 선택이 실제로는 프로그래밍된 선형적 경로였음을 폭로하며, 게임 매체 자체의 본질을 메타적으로 공격한다.
-- **Atmospheric Success**:
-    - 시스템적 모순에도 불구하고, 아르 데코 스타일과 사운드 디자인이 결합된 '공간의 힘'이 모든 단점을 압도하는 몰입감을 생성했다.
-
-## ⚠️ 모순 및 업데이트 (RL Update)
-- 후속작인 `BioShock Infinite`에서는 이 디스너넌스가 더 심화되었다는 평이 많다. 이는 '서사를 중시하는 AAA 게임'이 가진 고질적인 한계(System vs Story)를 보여주는 지침석이다.
-
-## 🔗 지식 연결 (Graph)
-- Related: [[BioShock (2007)]] , [[Game Design Theory]]
-- Context: [[Behavioral-Economics]]
diff --git a/AI/Bioenergetics.md b/AI/Bioenergetics.md
deleted file mode 100644
index 25ae67f3..00000000
--- a/AI/Bioenergetics.md
+++ /dev/null
@@ -1,27 +0,0 @@
----
-id: P-REINFORCE-SCI-BIOEN
-category: "[[10_Wiki/💡 Topics/Science]]"
-confidence_score: 0.95
-tags: [Bioenergetics, Metabolism, ATP, Thermodynamics]
-last_reinforced: 2026-04-20
----
-
-# [[Bioenergetics]] (생체 에너지학)
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 생명체는 '열역학 제2법칙(엔트로피 증가)'에 저항하여 에너지를 수집하고 변환함으로써 질서를 유지하는 경이로운 화학 공장이다.
-
-## 📖 구조화된 지식 (Synthesized Content)
-- **ATP (Adenosine Triphosphate)**:
-    - 생명체의 '에너지 통화'. 세포 내에서 모든 화학적 활동을 수행하기 위해 사용되는 충전지 같은 분자다.
-- **Thermodynamics in Biology**:
-    - 생명체는 고립계가 아니므로 자유 에너지(Gibbs Free Energy)를 외부에서 섭취하여 상태를 유지한다. 이 과정의 효율성은 기계보다 압도적으로 높다.
-- **Metabolism (신진대사)**:
-    - 에너지를 얻는 이화 작용(Catabolism)과 질서를 만드는 동화 작용(Anabolism)의 끊임없는 순환 과정.
-
-## ⚠️ 모순 및 업데이트 (RL Update)
-- 인공지능이 생명체의 에너지 효율을 모사하는 **Neuromorphic Computing** 연구가 활발하다. 현재 AI 모델은 생물학적 뇌보다 수백만 배 많은 에너지를 소모하므로, 생체 에너지학의 효율성 원리는 차세대 컴퓨팅의 영감이 된다.
-
-## 🔗 지식 연결 (Graph)
-- Related: [[Information Theory]] , [[Complexity-Theory]]
-- Application: [[Digital Twins]]
diff --git a/AI/Bioinformatics-Structure-Prediction.md b/AI/Bioinformatics-Structure-Prediction.md
deleted file mode 100644
index 4d5dacfc..00000000
--- a/AI/Bioinformatics-Structure-Prediction.md
+++ /dev/null
@@ -1,27 +0,0 @@
----
-id: P-REINFORCE-SCI-BIOINFO
-category: "[[10_Wiki/💡 Topics/Science]]"
-confidence_score: 0.98
-tags: [Bioinformatics, AlphaFold, DNA Sequencing, Protein Structure]
-last_reinforced: 2026-04-20
----
-
-# [[Bioinformatics-Structure-Prediction]] (바이오 인포매틱스와 구조 예측)
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 생명과학의 난제인 '단백질 접힘(Protein Folding)' 문제를 딥러닝(AlphaFold)으로 해결함으로써, 신약 개발과 질병 정복의 속도를 100배 이상 가속화했다.
-
-## 📖 구조화된 지식 (Synthesized Content)
-- **DNA to Structure**:
-    - DNA 서열 정보에서 단백질의 3D 입체 구조를 예측하는 것은 생물학의 성배였다. 이 구조가 결정되어야 약물이 어디에 결합할지(Docking) 알 수 있기 때문이다.
-- **AlphaFold (DeepMind)**:
-    - 트랜스포머 아키텍처를 바이오 데이터에 이식하여 수십 년 걸리던 구조 분석을 단 며칠로 단축했다. 2억 개 이상의 단백질 구조 데이터를 전 세계에 공개하여 과학적 혁명을 일으켰다.
-- **Genome Sequencing**:
-    - 대량의 염기 서열 데이터를 고속으로 처리하고 통계적으로 분석하여 유전병의 원인을 찾아내는 머신러닝 분석 기법.
-
-## ⚠️ 모순 및 업데이트 (RL Update)
-- 정적인 구조 예측을 넘어, 이제는 단백질이 시간에 따라 어떻게 움직이는지(Dynamics)를 예측하는 것이 다음 과제다. 이는 항암제와 같은 정밀 의료의 핵심이 된다.
-
-## 🔗 지식 연결 (Graph)
-- Related: [[Digital Twins]] , [[Deep-Learning-Basics]]
-- Foundation: [[Information Theory]]
diff --git a/AI/Biological-Inspired-Algorithms.md b/AI/Biological-Inspired-Algorithms.md
deleted file mode 100644
index a5ca8bd8..00000000
--- a/AI/Biological-Inspired-Algorithms.md
+++ /dev/null
@@ -1,27 +0,0 @@
----
-id: P-REINFORCE-AI-BIO-INSPIRED
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.99
-tags: [Bio-Inspired Algorithms, Genetic Algorithms, Ant Colony Optimization, Evolution]
-last_reinforced: 2026-04-20
----
-
-# [[Biological-Inspired-Algorithms]] (생물 유래 알고리즘)
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> "자연은 수억 년 동안 검증된 최적화 라이브러리다." 진화, 군집 행동, 면역 체계 등 생물계의 생존 전략을 수학적으로 모델링하여 복잡한 공학적 난제를 해결하는 최적화 기법이다.
-
-## 📖 구조화된 지식 (Synthesized Content)
-- **Genetic Algorithms (GA)**:
-    - 선택, 교차(Crossover), 변이(Mutation) 과정을 반복하며 가장 '적합한' 해를 찾아가는 다윈의 진화론 기반 알고리즘.
-- **Swarm Intelligence (ACO/PSO)**:
-    - 개별 개체(개미, 새)는 단순하지만, 그들의 상호작용이 거대한 지능(최단 경로 찾기 등)을 만들어내는 현상을 이용한 최적화.
-- **Neural Networks**:
-    - 뇌의 뉴런 연결 구조를 모방한 인공 신경망 역시 가장 거대한 생물 유래 알고리즘의 범주에 속한다.
-
-## ⚠️ 모순 및 업데이트 (RL Update)
-- 자연 모방 알고리즘은 전역 최적해(Global Optimum)를 찾는 데 유용하지만, 수렴 속도가 느릴 수 있다. 따라서 최근에는 수학적인 경사 하강법과 하이브리드로 결합하여 '정밀도'와 '탐색 범위'를 동시에 잡는 추세다.
-
-## 🔗 지식 연결 (Graph)
-- Related: [[Reinforcement-Learning]] , [[Algorithmic-Biology]]
-- Strategy: [[Innovation-Management]]
diff --git a/AI/Biomechanics-of-Injury.md b/AI/Biomechanics-of-Injury.md
deleted file mode 100644
index 36160313..00000000
--- a/AI/Biomechanics-of-Injury.md
+++ /dev/null
@@ -1,27 +0,0 @@
----
-id: P-REINFORCE-SCI-BIOMECH
-category: "[[10_Wiki/💡 Topics/Science]]"
-confidence_score: 0.96
-tags: [Biomechanics, Injury, Physics, Safety Engineering]
-last_reinforced: 2026-04-20
----
-
-# [[Biomechanics-of-Injury]] (부상 생체역학)
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 인체는 정교한 '기계적 구조물'이며, 외부 충격 시 물리적 에너지가 조직의 한계치를 넘어서는 과정(부상)을 수학적으로 모델링하여 생명을 보호한다.
-
-## 📖 구조화된 지식 (Synthesized Content)
-- **Kinematics & Kinetics**:
-    - 충돌 시 몸의 움직임(운동학)과 그 움직임을 유발하는 힘(운동역학)을 계산하여 뼈와 장기에 가해지는 부하를 예측한다.
-- **Tolerance Limit (임계치)**:
-    - 각 신체 부위가 버틸 수 있는 최대 압력(Stress)과 변형률(Strain). 이를 넘어설 때 골절이나 파열이 발생하며, 차량 충돌 테스트 더미(Dummy)의 설계 기준이 된다.
-- **HIC (Head Injury Criterion)**:
-    - 뇌진탕 등 머리 부상의 위험도를 가속도와 시간의 함수로 정량화한 지표.
-
-## ⚠️ 모순 및 업데이트 (RL Update)
-- 수동적인 보호 장치(에어백 등)를 넘어, 이제는 AI 시뮬레이션으로 수천 가지 사고 시나리오를 미리 돌려보고 부상을 획기적으로 줄이는 '액티브 세이프티(Active Safety)' 설계가 주류가 되고 있다.
-
-## 🔗 지식 연결 (Graph)
-- Related: [[Autonomous-Vehicle-Path-Planning]] , [[Distributed-Systems-Engineering]]
-- Application: [[Digital Twins]]
diff --git a/AI/Biometrics.md b/AI/Biometrics.md
deleted file mode 100644
index 5f4a6053..00000000
--- a/AI/Biometrics.md
+++ /dev/null
@@ -1,30 +0,0 @@
----
-id: P-REINFORCE-SCI-BIOMETRIC
-category: "[[10_Wiki/💡 Topics/Science]]"
-confidence_score: 0.97
-tags: [Biometrics, Security, Authentication, Pattern Recognition]
-last_reinforced: 2026-04-20
----
-
-# [[Biometrics]] (생체 인식 보안)
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 비밀번호는 '내가 아는 것(What you know)'이지만, 생체 인식은 '나 자신(What you are)'을 증명하는 것이며 가장 보안이 강력하지만 복구 불가능한 인증 수단이다.
-
-## 📖 구조화된 지식 (Synthesized Content)
-- **Physiological vs Behavioral**:
-    - **생리학적 특성**: 지문, 안면, 홍채, 정맥 패턴 등 고정된 신체적 특징.
-    - **행동적 특성**: 걸음걸이(Gait), 타이핑 리듬, 음성 등 개인이 가진 고유한 행동 패턴.
-- **FAR vs FRR (보안의 저울질)**:
-    - **FAR (False Acceptance Rate)**: 타인을 나로 오인할 확률 (보안 위협).
-    - **FRR (False Rejection Rate)**: 나를 타인으로 오인할 확률 (사용자 불편).
-    - 이 두 지표가 만나는 지점(EER)을 최소화하는 것이 시스템 성능의 핵심이다.
-- **Anti-spoofing (Liveness Detection)**:
-    - 사진이나 가짜 지문(Spoof)을 가려내기 위해 눈 깜빡임, 혈류 감지 등으로 실제 살아있는 신체인지 확인하는 기술.
-
-## ⚠️ 모순 및 업데이트 (RL Update)
-- 생체 정보는 한 번 유출되면 '비밀번호 변경'이 불가능하다. 따라서 생체 데이터를 서버에 날것으로 저장하지 않고, 암호화된 요약본(Hash)으로만 관리하는 분산 인증 프레임워크(FIDO)가 필수적이다.
-
-## 🔗 지식 연결 (Graph)
-- Related: [[System_Protocol_Standard]] , [[Deployment_Final_Gate]]
-- Foundation: [[Information Theory]]
diff --git a/AI/Bloom-Filters.md b/AI/Bloom-Filters.md
deleted file mode 100644
index 7237c2f5..00000000
--- a/AI/Bloom-Filters.md
+++ /dev/null
@@ -1,27 +0,0 @@
----
-id: P-REINFORCE-AI-BLOOM-FILTER
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 1.0
-tags: [Bloom Filters, Probabilistic Data Structure, Search Optimization, Hashing]
-last_reinforced: 2026-04-20
----
-
-# [[Bloom-Filters]] (블룸 필터)
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> "없다는 것은 확실히 알지만, 있다는 것은 가끔 착각한다." 공간 효율성을 극대화한 확률적 자료구조로, 거대한 데이터 집합에서 특정 원소가 포함되어 있는지 '초고속'으로 확인하는 선별 장치다.
-
-## 📖 구조化된 지식 (Synthesized Content)
-- **Probabilistic Membership**:
-    - "원소가 집합에 있는가?"에 대해 "없음"(100% 확실) 또는 "있을지도 모름"(False Positive 발생 가능)으로 답한다.
-- **Space Efficiency**:
-    - 실제 원소를 저장하지 않고 해시 함수와 비트 배열(Bit Array)만 사용하므로, 메모리 사용량을 획기적으로 줄인다.
-- **Use Cases**:
-    - 데이터베이스의 불필요한 디스크 읽기 방지, 악성 URL 차단 목록 확인, 대규모 네트워크 라우팅 등에서 전방 필터로 활약한다.
-
-## ⚠️ 모순 및 업데이트 (RL Update)
-- 블룸 필터의 성능 관건은 False Positive 확률을 낮추는 것이다. 비트 배열의 크기와 해시 함수의 개수를 데이터 양에 맞게 정밀하게 계산하는 수학적 튜닝이 필수적이다.
-
-## 🔗 지식 연결 (Graph)
-- Related: [[Hash-Functions]] , [[Big-Data-Processing]]
-- Foundation: [[Computational Theory & Math/Information Theory]]
diff --git a/AI/Boosting-Algorithms-XGBoost-LightGBM.md b/AI/Boosting-Algorithms-XGBoost-LightGBM.md
deleted file mode 100644
index cb37c4bb..00000000
--- a/AI/Boosting-Algorithms-XGBoost-LightGBM.md
+++ /dev/null
@@ -1,27 +0,0 @@
----
-id: P-REINFORCE-AI-BOOSTING
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 1.0
-tags: [Boosting, XGBoost, LightGBM, Gradient Boosting, Machine Learning]
-last_reinforced: 2026-04-20
----
-
-# [[Boosting-Algorithms-XGBoost-LightGBM]] (부스팅 알고리즘)
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> "오답 노트를 돌려보며 완벽해지는 군단." 약한 예측기(Weak Learners)를 순차적으로 학습시키되, 앞선 모델이 틀린 데이터에 가중치를 두어 성능을 계단식으로 끌어올리는 강력한 앙상블 기법이다.
-
-## 📖 구조화된 지식 (Synthesized Content)
-- **Gradient Boosting (GBM)**:
-    - 잔여 오차(Residual Error)를 새로운 모델의 목표값으로 삼아 경사 하강법으로 오차를 줄여나가는 방식.
-- **XGBoost (Extreme Gradient Boosting)**:
-    - GBM에 병렬 처리, 규제(Regularization) 기능을 더해 캐글(Kaggle) 등 데이터 경연 대회를 휩쓴 전설적인 라이브러리.
-- **LightGBM**:
-    - 대규모 데이터셋에서 속도와 메모리 효율을 극대화한 알고리즘. 리프 중심(Leaf-wise) 분할 방식으로 더 깊고 정밀한 나무를 만든다.
-
-## ⚠️ 모순 및 업데이트 (RL Update)
-- 부스팅 모델은 강력하지만 과적합(Overfitting)에 취약하다. 이를 위해 학습률(Learning rate)을 낮추고, 나무의 깊이를 제한하며, 조기 종료(Early stopping) 전략을 반드시 사용해야 한다.
-
-## 🔗 지식 연결 (Graph)
-- Related: [[Decision-Tree]] , [[Bias-Variance-Tradeoff]]
-- Tool: [[Data-Science-Toolkit]]
diff --git a/AI/Bounded Contexts.md b/AI/Bounded Contexts.md
deleted file mode 100644
index de273986..00000000
--- a/AI/Bounded Contexts.md	
+++ /dev/null
@@ -1,27 +0,0 @@
----
-id: P-REINFORCE-AI-BOUNDED-CONTEXT
-category: "[[10_Wiki/💡 Topics/Software Architecture]]"
-confidence_score: 0.99
-tags: [DDD, Bounded Context, Software Architecture, Domain]
-last_reinforced: 2026-04-20
----
-
-# [[Bounded-Contexts]] (제한된 맥락)
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> "모두를 위한 언어는 아무도 위한 언어가 아니다." 특정 도메인 내에서만 유효한 '의미의 경계'를 설정하여 복잡한 시스템을 명료하게 관리하는 DDD의 핵심 기법이다.
-
-## 📖 구조화된 지식 (Synthesized Content)
-- **Linguistic Boundary (언어적 경계)**:
-    - 'Account'라는 단어가 '은행' 맥락에서는 계좌이지만, '로그인' 맥락에서는 유저 ID일 수 있다. 이 두 의미가 섞이지 않도록 코드와 모델의 영역을 물리적으로 나누는 것이 핵심이다.
-- **Ubiquitous Language (보편적 언어)**:
-    - 특정 바운디드 컨텍스트 안에서는 개발자나 기획자나 똑같은 단어를 똑같은 의미로 사용해야 한다.
-- **Context Mapping**:
-    - 서로 다른 컨텍스트들이 어떻게 데이터를 주고받는지(Shared Kernel, Anti-Corruption Layer 등)의 관계도를 그리는 작업.
-
-## ⚠️ 모순 및 업데이트 (RL Update)
-- 바운디드 컨텍스트를 너무 잘게 쪼개면 마이크로서비스(MSA)의 관리 복잡성(Distributed System complexity)이 폭발한다. 처음에는 '모놀리식'으로 시작하되, 도메인 경계가 명확해지는 시점에 분리하는 전략이 실용적이다.
-
-## 🔗 지식 연결 (Graph)
-- Related: [[Domain-Driven Design (DDD)]] , [[Bounded-Contexts-and-Interface-Segregation]]
-- Foundation: [[Clean-Architecture-Implementation]]
diff --git a/AI/Bounded Rationality.md b/AI/Bounded Rationality.md
deleted file mode 100644
index 9a165f4f..00000000
--- a/AI/Bounded Rationality.md	
+++ /dev/null
@@ -1,27 +0,0 @@
----
-id: P-REINFORCE-AI-BOUNDED-RAT
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.98
-tags: [Bounded Rationality, Decision Theory, AI, Economics]
-last_reinforced: 2026-04-20
----
-
-# [[Bounded-Rationality]] (제한적 합리성)
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> "완벽한 최선은 가능하지 않다. 그저 '충분히 좋은' 것에 만족할 뿐이다." 지능, 시간, 정보의 한계 속에서 내리는 실제적인 의사결정의 원리다.
-
-## 📖 구조화된 지식 (Synthesized Content)
-- **Satisficing (만족화)**:
-    - 헤르베르트 사이먼이 제안한 개념. 모든 대안을 전수 조사하는 '최적화' 대신, 자신의 기준(Threshold)을 넘는 첫 번째 대안을 선택하는 전략.
-- **Cognitive Limits (인지적 한계)**:
-    - 인간이나 AI 시스템의 연산 능력은 제한되어 있으므로, 모든 변수를 고려하는 것은 물리적으로 불가능하다.
-- **Heuristic Search**:
-    - 제한된 자원 내에서 해답을 찾기 위해 사용하는 '어림짐작'이나 '지름길' 알고리즘의 이론적 배경.
-
-## ⚠️ 모순 및 업데이트 (RL Update)
-- 현대 AI(LLM)는 방대한 데이터를 통해 인간보다 훨씬 넓은 합리성을 가진 것처럼 보이지만, 결국 '다음 단어 예측'이라는 확률적 휴리스틱에 기반하고 있다는 점에서 여전히 제한적 합리성의 틀 안에 있다.
-
-## 🔗 지식 연결 (Graph)
-- Related: [[Cognitive-Biases]] , [[Behavioral-Economics]]
-- Analysis: [[Complexity-Theory]]
diff --git a/AI/Bounded-Contexts-and-Interface-Segregation.md b/AI/Bounded-Contexts-and-Interface-Segregation.md
deleted file mode 100644
index 535ccfdc..00000000
--- a/AI/Bounded-Contexts-and-Interface-Segregation.md
+++ /dev/null
@@ -1,27 +0,0 @@
----
-id: P-REINFORCE-AI-ISP-DDD
-category: "[[10_Wiki/💡 Topics/Software Architecture]]"
-confidence_score: 0.97
-tags: [ISP, DDD, Bounded Context, SOLID]
-last_reinforced: 2026-04-20
----
-
-# [[Bounded-Contexts-and-Interface-Segregation]] (맥락 분리와 인터페이스 격리)
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> "내가 쓰지 않는 기능에 의존하지 마라." 객체 지향의 ISP(인터페이스 분리 원칙)를 도메인 레벨(DDD)로 확장하여 시스템 간의 불필요한 결합을 원천 차단하는 설계 패턴이다.
-
-## 📖 구조화된 지식 (Synthesized Content)
-- **Domain-Specific Interfaces**:
-    - 하나의 거대한 레포지토리 인터페이스 대신, 각 바운디드 컨텍스트가 필요로 하는 메서드만 정의된 작은 인터페이스로 쪼갠다.
-- **Decoupling Boundaries**:
-    - 결제 맥락(Payment Context)은 유저 맥락(User Context)의 전체 정보를 알 필요가 없다. 결제에 필요한 최소한의 인터페이스만 노출시켜 변경에 강한 구조를 만든다.
-- **Adhering to SOLID**:
-    - ISP를 준수함으로써 하나의 변화가 시스템 전체로 전파되는 '버터플라이 이펙트'를 제어한다.
-
-## ⚠️ 모순 및 업데이트 (RL Update)
-- 인터페이스를 과도하게 분리하면 '관리 포인트'가 늘어난다. 실제 의존성이 발생하지 않는 단순 조회(CRUD) 시스템에서는 과도한 격리보다 단순한 데이터 모델 공유가 더 효율적일 수 있다.
-
-## 🔗 지식 연결 (Graph)
-- Related: [[Bounded-Contexts]] , [[Clean-Architecture-Implementation]]
-- Principles: [[React_Clean_Code_Best_Practices]]
diff --git a/AI/Bounding-Box-Regression.md b/AI/Bounding-Box-Regression.md
deleted file mode 100644
index a5fb366f..00000000
--- a/AI/Bounding-Box-Regression.md
+++ /dev/null
@@ -1,27 +0,0 @@
----
-id: P-REINFORCE-AI-BBOX
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 1.0
-tags: [Bounding Box Regression, Object Detection, Computer Vision, IoU]
-last_reinforced: 2026-04-20
----
-
-# [[Bounding-Box-Regression]] (경계 박스 회귀)
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> "이미지 속 사물의 정확한 주소를 찾는 일." 물체가 어디에 있는지 대략적인 영역을 넘어, x, y, Width, Height라는 4개의 숫자를 정밀하게 예측하여 물체를 상자 안에 가두는 컴퓨터 비전의 핵심 기술이다.
-
-## 📖 구조화된 지식 (Synthesized Content)
-- **Coordinate Prediction**:
-    - 신경망의 마지막 층에서 물체의 중심점 좌표와 크기를 연속적인 실수값으로 출력한다.
-- **Intersection over Union (IoU)**:
-    - 예측한 박스와 실제 정답 박스가 얼마나 겹치는지(0~1 사이) 측정하여 박스의 정확도를 평가하는 지표.
-- **Anchor Boxes**:
-    - 다양한 크기와 비율의 가이드라인(Anchor)을 미리 뿌려두고, 물체와 가장 비슷한 앵커를 세밀하게 조정(Offset)하여 최종 위치를 결정한다.
-
-## ⚠️ 모순 및 업데이트 (RL Update)
-- 여러 물체가 겹쳐 있을 때 하나의 박스만 남겨야 하는 'Non-Maximum Suppression (NMS)' 과정이 성능에 큰 영향을 미친다. 최근에는 NMS 없이 직접 물체 집합을 예측하는 Transformer 기반(DETR) 방식이 각광받고 있다.
-
-## 🔗 지식 연결 (Graph)
-- Related: [[Object-Detection]] , [[Convolutional-Neural-Networks-(CNN)]]
-- Metric: [[Mean-Average-Precision-(mAP)]]
diff --git a/AI/Brain-Derived Neurotrophic Factor (BDNF).md b/AI/Brain-Derived Neurotrophic Factor (BDNF).md
deleted file mode 100644
index e624c577..00000000
--- a/AI/Brain-Derived Neurotrophic Factor (BDNF).md	
+++ /dev/null
@@ -1,27 +0,0 @@
----
-id: P-REINFORCE-SCI-BDNF
-category: "[[10_Wiki/💡 Topics/Science]]"
-confidence_score: 0.98
-tags: [BDNF, Neuroscience, Brain Health, Cognitive]
-last_reinforced: 2026-04-20
----
-
-# [[Brain-Derived-Neurotrophic-Factor-(BDNF)]] (뇌유래 신경영양인자)
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> "뇌를 위한 비료(Fertilizer)." BDNF는 시냅스의 가소성을 높여 학습 능력을 강화하고, 뇌가 늙지 않게 보호하는 마법의 단백질이다.
-
-## 📖 구조화된 지식 (Synthesized Content)
-- **Neuroplasticity (신경 가소성)**:
-    - BDNF는 뉴런의 생존뿐만 아니라 새로운 뉴런의 생성(Neurogenesis)과 연결을 돕는다. 학습과 기억 형성의 생화학적 토대다.
-- **Physical Exercise Connection**:
-    - 중강도 이상의 유산소 운동은 BDNF 수치를 즉각적으로 높인다. "공부가 안 될 땐 산책하라"는 조언의 과학적 근거다.
-- **Cognitive Reserve (인지 예비능)**:
-    - 높은 BDNF 수치는 치매나 뇌 손상에 대응할 수 있는 '방어력'을 키워준다.
-
-## ⚠️ 모순 및 업데이트 (RL Update)
-- 스트레스 호르몬인 코르티솔(Cortisol)은 BDNF의 생성을 억제한다. 따라서 고도의 인지 작업이 필요한 개발자에게 '번아웃 관리'는 단순히 휴식이 아니라 뇌 세척과 성장을 위한 필수 프로세스다.
-
-## 🔗 지식 연결 (Graph)
-- Related: [[Cognitive-Neuroscience-of-Flow]] , [[Burnout-Prevention-in-Professional-Gaming]]
-- Foundation: [[Information Theory]]
diff --git a/AI/Branded-Types-for-Nominal-Typing.md b/AI/Branded-Types-for-Nominal-Typing.md
deleted file mode 100644
index ca91a377..00000000
--- a/AI/Branded-Types-for-Nominal-Typing.md
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-6DAFA5
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Branded-Types-for-Nominal-Typing"
----
-
-# [[Branded-Types-for-Nominal-Typing]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** AI 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Branded-Types-for-Nominal-Typing.md]]
----
diff --git a/AI/Branded-Types.md b/AI/Branded-Types.md
deleted file mode 100644
index f7748434..00000000
--- a/AI/Branded-Types.md
+++ /dev/null
@@ -1,27 +0,0 @@
----
-id: P-REINFORCE-AI-BRANDED-TYPES
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.99
-tags: [TypeScript, Branded Types, Nominal Typing, Type Safety]
-last_reinforced: 2026-04-20
----
-
-# [[Branded-Types]] (브랜디드 타입)
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> "본질적으로 같은 `string`이라도, 유저 ID와 주문 ID는 엄격히 구분되어야 한다." 타입스크립트에 가짜 딱지를 붙여 '이름 기반 타입 시스템(Nominal Typing)'을 흉내 내는 고수의 기술이다.
-
-## 📖 구조화된 지식 (Synthesized Content)
-- **Problem: Structural Typing**:
-    - 타입스크립트는 구조가 같으면 같은 타입으로 본다. `type UserId = string; type PostId = string;`일 때, 둘을 바꿔 써도 컴파일러는 잡지 못한다.
-- **Solution: Intersecting with Unique Tag**:
-    - `type UserId = string & { __brand: "UserId" };` 처럼 실제 데이터에는 없지만 타입 세계에만 존재하는 고유 속성을 추가한다.
-- **Type Guards**:
-    - 단순 캐스팅(`as UserId`)보다는 검증 함수를 거쳐야만 해당 타입을 얻을 수 있게 설계하여 데이터 무결성을 보장한다.
-
-## ⚠️ 모순 및 업데이트 (RL Update)
-- 런타임에는 이 '낙인(Brand)'이 사라진다. 따라서 브랜디드 타입은 오직 컴파일 타임의 실수 방지용이다. 시스템이 매우 거대해져서 ID 값들이 혼동될 우려가 있는 엔터프라이즈급 프로젝트에서 그 가치가 증명된다.
-
-## 🔗 지식 연결 (Graph)
-- Related: [[TypeScript_Type_Safety]] , [[Branded-Types-for-Nominal-Typing]]
-- Foundation: [[Clean-Architecture-TypeScript]]
diff --git a/AI/Burnout Prevention in Professional Gaming.md b/AI/Burnout Prevention in Professional Gaming.md
deleted file mode 100644
index 632fa346..00000000
--- a/AI/Burnout Prevention in Professional Gaming.md	
+++ /dev/null
@@ -1,27 +0,0 @@
----
-id: P-REINFORCE-SCI-BURNOUT
-category: "[[10_Wiki/💡 Topics/Science]]"
-confidence_score: 0.96
-tags: [Burnout, Professional Gaming, Mental Health, Performance]
-last_reinforced: 2026-04-20
----
-
-# [[Burnout-Prevention-in-Professional-Gaming]] (프로게이머 번아웃 방지)
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> "휴식도 훈련의 일부다." 0.1초의 반응 속도를 다투는 프로의 세계에서 뇌의 피로(Cognitive Fatigue)를 관리하지 못하는 것은 승리를 포기하는 것과 같다.
-
-## 📖 구조화된 지식 (Synthesized Content)
-- **Cognitive Fatigability (인지적 피로도)**:
-    - 고도의 집중력이 지속될 때 전전두엽의 포도당 소모가 급증하며 의사결정 속도가 저하된다. 이를 방지하기 위해 정기적인 'Mental Reset' 루틴이 필수적이다.
-- **Dopamine Detox (도파민 디톡스)**:
-    - 게임의 강력한 시각적/청각적 자극에 노출된 뇌를 위해, 연습 시간 외에는 자극이 적은 환경(명상, 산책)을 제공하여 뇌의 보상 시스템을 안정화한다.
-- **Sleep Hygiene (수면 위생)**:
-    - 렘(REM) 수면 단계에서 당일 학습한 전략과 반응 기술이 장기 기억으로 전이된다. 하루 7시간 이상의 규칙적인 수면은 가장 강력한 기술 향상 도구다.
-
-## ⚠️ 모순 및 업데이트 (RL Update)
-- 무조건적인 연습 시간 증가는 오히려 '플래토(Plateau, 성체기)' 현상을 유발한다. 짧고 강렬한 '몰입 연습(Deliberate Practice)'과 완전한 단절을 동반한 휴식을 교차시키는 것이 롱런하는 선수의 공통점이다.
-
-## 🔗 지식 연결 (Graph)
-- Related: [[Behavioral-Economics]] , [[Complexity-Theory]]
-- Foundation: [[Information Theory]]
diff --git a/AI/CI_CD 및 Pull Request 자동화 리뷰.md b/AI/CI_CD 및 Pull Request 자동화 리뷰.md
deleted file mode 100644
index 7aaa50da..00000000
--- a/AI/CI_CD 및 Pull Request 자동화 리뷰.md	
+++ /dev/null
@@ -1,33 +0,0 @@
----
-id: P-REINFORCE-AUTO-877DCA
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - CI_CD 및 Pull Request 자동화 리뷰"
----
-
-# [[CI_CD 및 Pull Request 자동화 리뷰]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> CI/CD 및 Pull Request(PR) 자동화 리뷰는 소프트웨어 개발 수명 주기(SDLC)에서 코드 병합 이전에 정적 분석 도구(SAST), 린터(Linter), AI 코드 리뷰 봇 등을 활용하여 취약점, 버그, 스타일 위반을 자동으로 검사하는 과정입니다 [1, 2]. 이를 통해 빠른 피드백 루프를 형성하고, 일관된 코드 품질 기준을 강제하며, CI/CD 파이프라인 내에서 품질 게이트(Quality Gate) 역할을 수행하여 인간 리뷰어의 피로도를 줄이고 보안과 품질을 극대화합니다 [3-6].
-
-## 📖 구조화된 지식 (Synthesized Content)
-* **파이프라인 통합 및 품질 게이트 (Quality Gates):** SonarQube, Snyk, CodeQL과 같은 자동화 분석 도구는 CI/CD 파이프라인 및 PR 워크플로우에 직접 통합됩니다 [1, 7-9]. PR이 생성되거나 코드가 푸시될 때 자동으로 검사를 실행하며, 사전 정의된 품질 게이트 규칙이나 심각도 임계값에 따라 PR 병합을 차단하거나 빌드를 실패하게 만들어 불량 코드가 프로덕션 환경에 도달하는 것을 원천적으로 방지합니다 [5, 10, 11].
-* **Pre-commit 단계의 선제적 자동화 (Husky & lint-staged):** CI 파이프라인 이전에 로컬 개발 환경에서 문제를 잡기 위해 Husky와 lint-staged를 주로 결합하여 사용합니다 [12, 13]. Husky는 `pre-commit`과 같은 Git 훅(Git hooks)을 중앙에서 관리하고, lint-staged는 변경되어 커밋 대기 중인 파일(staged files)에 대해서만 ESLint(정적 분석 및 린팅)와 Prettier(코드 포매팅)를 빠르게 실행합니다 [14-17]. 이를 통해 오류가 없거나 스타일 규칙을 준수한 코드만 커밋되도록 강제합니다 [16, 18].
-* **AI 기반 PR 자동 리뷰:** 최근의 자동화 리뷰 생태계는 생성형 AI와 머신러닝을 활용하여 PR 요약, 보안 취약점 식별, 자동 수정(Auto-fix) 코드 제안 기능을 PR 스레드 내에 직접 제공합니다 [19-21]. CodeRabbit, PR-Agent, Snyk Code, GitHub Copilot 등은 팀의 표준을 강제하며 개발자에게 실시간에 가까운 인라인 피드백을 제공하여 PR 주기 시간과 최초 리뷰 대기 시간(Time to first review)을 크게 단축시킵니다 [4, 22-25].
-* **수동 리뷰와의 하이브리드 병행 (Hybrid Approach):** 자동화된 리뷰는 구문 오류, 코드 스멜(Code smells), 널리 알려진 보안 결함 등을 빠르고 일관되게 검출하는 데 탁월하지만, 코드의 근본적인 의도나 비즈니스 로직, 아키텍처 맥락을 이해하는 데에는 한계가 존재합니다 [26-28]. 따라서 CI/CD 및 Git 훅을 통한 자동화 도구로 1차적인 기계적 검증을 처리하고, 인간 리뷰어는 아키텍처 설계, 보안 문맥, 비즈니스 로직 검증에 집중하는 '하이브리드 코드 리뷰'가 현재의 가장 이상적인 모범 사례로 꼽힙니다 [6, 11, 29, 30].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** AI 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[Static Application Security Testing (SAST)]], [[Git Hooks]], [[AI Code Review]]
-- **Projects/Contexts:** [[CI/CD Pipelines]], [[DevSecOps]]
-- **Contradictions/Notes:** 소스들은 자동화된 리뷰 도구가 매우 빠르고 일관적이지만 인간 리뷰어를 완전히 대체할 수는 없다고 주장합니다. 자동화 도구나 AI 봇은 문맥 맹점(Context Blindness)이 있어 아키텍처 설계나 비즈니스 로직을 온전히 이해하지 못하므로, 기계가 루틴한 검사를 담당하고 사람은 고차원적인 판단을 내리는 하이브리드 방식이 필수적이라고 강조합니다 [28, 31, 32].
-
----
-*Last updated: 2026-04-19*
-- Raw Source: [[00_Raw/2026-04-20/CI_CD 및 Pull Request 자동화 리뷰.md]]
----
diff --git a/AI/CI_CD 파이프라인 및 IDE 통합 보안.md b/AI/CI_CD 파이프라인 및 IDE 통합 보안.md
deleted file mode 100644
index a5e28903..00000000
--- a/AI/CI_CD 파이프라인 및 IDE 통합 보안.md	
+++ /dev/null
@@ -1,32 +0,0 @@
----
-id: P-REINFORCE-AUTO-F8BCE8
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - CI_CD 파이프라인 및 IDE 통합 보안"
----
-
-# [[CI_CD 파이프라인 및 IDE 통합 보안]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> CI/CD 파이프라인 및 IDE 통합 보안은 소프트웨어 개발 프로세스 전반에 걸쳐 코드의 품질과 보안을 유지하기 위한 핵심 접근법입니다 [1], [2]. 개발자가 코드를 작성하는 IDE 환경과 코드가 병합 및 배포되는 CI/CD 워크플로우에 정적 분석(SAST) 및 자동화된 보안 검사 도구를 내장하여 실시간 피드백을 제공합니다 [3], [4]. 이를 통해 개발자는 코드의 결함과 취약점을 조기에 식별하고 수정할 수 있어 안전하고 효율적인 소프트웨어 개발 수명 주기(SDLC)를 확보할 수 있습니다 [5], [6].
-
-## 📖 구조화된 지식 (Synthesized Content)
-* **IDE 내 실시간 보안 검사:** SonarQube for IDE나 Snyk Code와 같은 플러그인은 Visual Studio, VS Code, JetBrains, Eclipse 등의 개발 환경에 직접 내장되어 작동합니다 [7], [8], [9]. 개발자가 코드를 작성하는 즉시 실시간으로 구문, 로직 및 보안 결함을 분석하여 즉각적인 피드백과 자동화된 수정 제안을 제공합니다 [7], [10]. 이를 통해 코드가 버전 관리 시스템에 커밋되기 전, 가장 이른 단계에서 보안 위험을 식별하고 제거할 수 있습니다 [11], [12].
-* **CI/CD 파이프라인 자동화 및 게이팅(Gating):** 코드가 풀 리퀘스트(Pull Request)나 브랜치에 푸시되어 빌드될 때, CI/CD 워크플로우 내에서 보안 스캔이 자동으로 실행됩니다 [5], [13], [9]. 조직은 심각도 임계값(Severity thresholds)이나 품질 게이트(Quality gates)를 설정하여, 기준을 충족하지 못하는 결함이나 보안 취약점이 발견되면 빌드를 실패하게 하거나 풀 리퀘스트 병합을 차단할 수 있습니다 [2], [14], [15], [16]. 이는 GitHub Actions, GitLab, Jenkins 등 다양한 DevOps 도구 체인과 긴밀하게 통합되어 이루어집니다 [4], [17], [15].
-* **시프트 레프트(Shift-Left) 및 규정 준수 강제:** IDE와 CI/CD 전반에 걸친 보안 통합은 취약점을 개발 과정의 초기에 발견하여 수정하는 '시프트 레프트' 보안 전략을 실현합니다 [11], [18]. 프로덕션 환경에 도달하기 전에 선제적으로 문제를 해결하므로 릴리스 이후 발생하는 결함을 수정하는 비용과 시간을 절감합니다 [6]. 또한, PCI, OWASP, CWE, STIG 등 주요 보안 및 규정 준수 표준을 조직 전체의 리포지토리와 팀에 일관되게 적용하고 강제할 수 있도록 지원합니다 [19], [20], [21], [22].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** AI 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[SAST(정적 애플리케이션 보안 테스트)]], [[Shift-left(시프트 레프트)]], [[SDLC(소프트웨어 개발 수명 주기)]]
-- **Projects/Contexts:** [[SonarQube]], [[Snyk Code]], [[DevSecOps]]
-- **Contradictions/Notes:** 소스 내용 중 이 주제에 대한 명시적인 모순이나 반대 의견은 존재하지 않습니다. 모든 소스가 조기 발견(Shift-left)의 효율성 및 통합의 필요성에 동의하고 있습니다.
-
----
-*Last updated: 2026-04-19*
-- Raw Source: [[00_Raw/2026-04-20/CI_CD 파이프라인 및 IDE 통합 보안.md]]
----
diff --git a/AI/CI_CD.md b/AI/CI_CD.md
deleted file mode 100644
index e8c5077f..00000000
--- a/AI/CI_CD.md
+++ /dev/null
@@ -1,33 +0,0 @@
----
-id: P-REINFORCE-AUTO-CFCF20
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - CI_CD"
----
-
-# [[CI_CD]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> CI/CD(Continuous Integration / Continuous Delivery)는 소프트웨어 개발 라이프사이클(SDLC) 전반에 걸쳐 코드의 빌드, 테스트, 병합 및 배포 과정을 자동화하는 워크플로우 파이프라인입니다 [1-3]. 주로 정적 애플리케이션 보안 테스트(SAST) 및 AI 코드 리뷰 도구와 결합하여 코드 결함과 보안 취약점을 프로덕션 배포 전에 조기에 발견하고 차단하는 역할을 합니다 [4-6]. 이를 통해 개발 팀은 품질 저하 없이 일관되고 빠른 소프트웨어 릴리스 주기를 유지할 수 있습니다 [7-9].
-
-## 📖 구조화된 지식 (Synthesized Content)
-* **자동화된 품질 및 보안 스캔 통합:** CI/CD 파이프라인은 SonarQube, Snyk, Qodana와 같은 정적 코드 분석(SAST) 도구 및 AI 기반 코드 리뷰 도구가 실행되는 주요 환경입니다 [2, 6, 10, 11]. 개발 환경에서 코드가 푸시되거나 풀 리퀘스트(PR)가 생성되면 파이프라인 내에서 스캔이 자동으로 트리거되어, 잠재적 버그, 보안 취약점, 유지보수성 문제 등을 찾아냅니다 [3, 12-14].
-* **품질 게이트(Quality Gate)를 통한 정책 시행:** 파이프라인 내부에는 특정 심각도 임계값(threshold)을 초과하는 결함이나 보안 취약점이 발견될 경우 빌드를 중단시키거나 코드 병합을 차단하는 품질 게이트가 존재합니다 [2, 13, 15, 16]. 이러한 장치는 불량 코드가 프로덕션 환경에 도달하는 것을 방지하는 강력한 가드레일 역할을 수행합니다 [14, 17, 18].
-* **신속한 피드백 루프와 성능 요구사항:** CI/CD에 스캔을 통합함으로써 개발자는 취약점에 대한 즉각적이고 시의적절한 피드백을 실시간에 가깝게 받을 수 있습니다 [7, 18, 19]. 하지만, 도구가 전체 코드베이스를 너무 오래 검사하여 파이프라인의 속도를 저하시키는 것은 큰 병목 현상을 유발할 수 있습니다 [9, 20]. 따라서 변경된 파일만 점검하거나 스캔 속도가 빠른 도구를 사용하여 CI/CD 파이프라인의 속도를 저해하지 않는 것이 중요합니다 [15, 21, 22].
-* **하이브리드 코드 리뷰 워크플로우의 기반:** CI/CD 파이프라인 내에서의 자동화된 검사(구문 오류, 스타일 위반, 알려진 취약점 등)는 개발 초기에 기계적인 오류를 신속히 잡아내므로, 이후 인간 리뷰어가 복잡한 아키텍처나 비즈니스 로직 검토에 온전히 집중할 수 있도록 돕는 다층적(Hybrid) 코드 리뷰 프로세스의 핵심 기반으로 작용합니다 [14, 16, 23].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** AI 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[SAST]], [[Quality Gate]], [[Pull Request]], [[Automated Code Review]]
-- **Projects/Contexts:** 보안 스캔을 개발 워크플로우에 통합하기 위해 자주 사용되는 [[SonarQube Cloud]], [[Snyk Code]], [[Qodana]], [[GitHub Actions]] 기반 파이프라인 환경.
-- **Contradictions/Notes:** 소스 문헌들은 CI/CD를 통한 자동화 검사가 빠르고 일관된 피드백을 제공하여 보안을 크게 향상시킨다고 주장하지만 [8], 자동화 도구는 비즈니스 로직이나 코드의 의도(Context)를 완전히 이해하지 못해 오탐(False Positive)을 유발할 수 있는 한계가 있으므로 파이프라인 자동화에만 의존해서는 안 되며 반드시 수동 리뷰와 결합해야 한다고 조언합니다 [14, 24, 25].
-
----
-*Last updated: 2026-04-18*
-- Raw Source: [[00_Raw/2026-04-20/CI_CD.md]]
----
diff --git a/AI/CPTED.md b/AI/CPTED.md
deleted file mode 100644
index 7f789558..00000000
--- a/AI/CPTED.md
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-9984E9
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - CPTED"
----
-
-# [[CPTED]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** AI 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/CPTED.md]]
----
diff --git a/AI/CV_Synthesis.md b/AI/CV_Synthesis.md
deleted file mode 100644
index 4680510f..00000000
--- a/AI/CV_Synthesis.md
+++ /dev/null
@@ -1,29 +0,0 @@
----
-id: P-REINFORCE-AI-002
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.95
-tags: [ai, graphics, nerf, synthesis]
-last_reinforced: 2026-04-20
-github_commit: "batch-reinforce-03"
----
-
-# [[Computer Vision Synthesis]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 정적 이미지 분석을 넘어 새로운 시점과 현실적인 영상을 생성해내는 '창조적 비전'의 영역.
-
-## 📖 구조화된 지식 (Synthesized Content)
-- **추출된 패턴:** NeRF(Neural Radiance Fields)와 같은 미분 가능한 렌더링 기법을 통해 2D 이미지로부터 3D 씬을 재구성하고 합성하는 패턴.
-- **세부 내용:**
-    - View Synthesis: 다른 각도에서 본 물체나 풍경을 사실적으로 생성.
-    - Generative Models: GAN 및 Diffusion 모델을 활용한 고해상도 이미지 합성.
-    - 3DGS(Gaussian Splatting)와의 기술적 접점 및 실시간성 확보.
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 단순 텍스처 매핑 기반 모델링에서 신경망 보간(Interpolation) 기반 합성으로의 전환.
-- **정책 변화:** 성능(w1) 대비 품질의 균형점을 NeRF 계열 지식 중심으로 재편.
-
-## 🔗 지식 연결 (Graph)
-- **Parent:** [[10_Wiki/💡 Topics/AI]]
-- **Related:** [[NeRF]], [[3D_Gaussian_Splatting]], [[Generative-AI]]
-- **Raw Source:** [[00_Raw/2026-04-20/Computer-Vision-Synthesis.md]]
diff --git a/AI/Caliskan-Islam 등의 프로그램 바이너리 작성자 식별 연구.md b/AI/Caliskan-Islam 등의 프로그램 바이너리 작성자 식별 연구.md
deleted file mode 100644
index 61426348..00000000
--- a/AI/Caliskan-Islam 등의 프로그램 바이너리 작성자 식별 연구.md	
+++ /dev/null
@@ -1,39 +0,0 @@
----
-id: P-REINFORCE-AUTO-0C1C8B
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Caliskan-Islam 등의 프로그램 바이너리 작성자 식별 연구"
----
-
-# [[Caliskan-Islam 등의 프로그램 바이너리 작성자 식별 연구]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-* **특징 추출 (Feature Extraction):** 
-  이 연구는 하이브리드 방식을 취하여 다양한 수준에서 프로그램의 특징을 추출했습니다. Netwide 및 Radare2 역어셈블러를 통해 어셈블리 코드 n-그램, 제어 흐름 그래프(CFG) 블록 유니그램 및 바이그램을 추출했습니다 [1, 2]. 또한 IDA Pro와 Hex-Rays 역컴파일러로 얻은 코드에서 단어 유니그램 및 라이브러리/내부 함수 이름을 추출하고, Joern 파서를 이용해 구문 분석을 수행하여 노드 유형 유니그램 같은 AST 기반의 특징도 활용했습니다 [1, 2].
-* **특징 차원 축소 (Feature Reduction):** 
-  초기에는 750,000개라는 방대하고 희소성(sparse)이 높은 특징 세트가 생성되었습니다. 랜덤 포레스트 훈련에 있어 희소성이 문제가 되자, 저자들은 이전 소스 코드 스타일로메트리 연구에서처럼 정보 이득(Information gain)을 기반으로 한 특징 선택 기법을 적용했습니다 [2]. 이를 통해 특징 차원을 2,000개 미만으로 줄였으며, 그 결과 분류 성공률이 30%에서 90%로 대폭 향상되었습니다 [2].
-* **통제된 환경에서의 식별 성능 (Google Code Jam 데이터):**
-  구글 코드 잼의 C++ 제출 코드를 바탕으로 동일한 9개 문제를 푼 프로그래머 100명의 데이터를 평가했습니다. 500개의 트리로 구성된 랜덤 포레스트 분류기를 사용하여 9겹 교차 검증(9-fold cross-validation)을 진행한 결과, 축소된 특징 세트로 89.8%의 정확도를 달성했습니다 [2, 3]. 겹치지 않는 다른 100명 그룹에 적용했을 때도 92.8%의 정확도를 보였으며, 작성자 수를 600명으로 확대했을 때도 78.1%라는 비교적 높은 정확도를 유지했습니다 [3].
-* **야생(In the wild) 환경에서의 식별 성능 (GitHub 데이터):**
-  실제 오픈소스 환경에서의 식별 가능성을 확인하기 위해 단일 기여자로 이루어진 GitHub의 C/C++ 저장소를 대상으로 테스트했습니다 [3, 4]. 복사된 코드나 라이브러리의 노이즈를 수작업으로 필터링한 후, 파일 수가 6~15개인 50명의 프로그래머 집단을 대상으로 실험했을 때 60.1%의 정확도를 기록했습니다 [3, 4].
-* **컴파일 최적화 및 난독화의 영향:**
-  최적화 레벨 3을 적용한 컴파일 환경에서는 100명의 작성자를 대상으로 한 정확도가 85.7%로 다소 감소했으며, 심볼(Symbol) 정보를 완전히 제거한 경우에는 정확도가 23%나 급락했습니다 [3]. 그러나 Obfuscator-LLVM과 같은 도구를 통한 전문적인 난독화를 적용했을 때는 정확도 하락 폭이 단 3.6%에 불과하여, 작성자의 특정 코딩 스타일 패턴이 강력하게 유지됨을 확인했습니다 [3].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** AI 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[Code Stylometry]], [[Random Forest]], [[Abstract Syntax Tree (AST)]], [[Control Flow Graph (CFG)]]
-- **Projects/Contexts:** [[Google Code Jam]], [[GitHub]]
-- **Contradictions/Notes:** 소스 [2, 3]에 따르면, 초기 75만 개의 특징을 그대로 머신러닝에 투입했을 때는 성능이 30%에 그쳤으나, 정보 이득(Information gain)을 사용하여 특징을 2,000개 미만으로 대폭 줄였음에도 불구하고 정확도가 90% 근방으로 상승하는 반직관적인 결과를 보였습니다. 또한 심볼 정보 제거는 23%의 뚜렷한 성능 저하를 일으켰으나, 본격적인 소스 코드 난독화(Obfuscator-LLVM)는 식별 성능을 겨우 3.6%만 낮췄다는 흥미로운 점을 발견했습니다 [3].
-
----
-*Last updated: 2026-04-19*
-- Raw Source: [[00_Raw/2026-04-20/Caliskan-Islam 등의 프로그램 바이너리 작성자 식별 연구.md]]
----
diff --git a/AI/Call Stack.md b/AI/Call Stack.md
deleted file mode 100644
index fa4eed17..00000000
--- a/AI/Call Stack.md	
+++ /dev/null
@@ -1,30 +0,0 @@
----
-id: P-REINFORCE-AUTO-081DEE
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Call Stack"
----
-
-# [[Call Stack]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 콜 스택(Call Stack)은 Chrome DevTools의 성능(Performance) 분석 패널에서 페이지 실행 중 호출된 함수들의 계층 구조와 연쇄적인 실행 순서를 나타내는 요소입니다 [1-3]. 플레임 차트(Flame chart)나 Call Tree와 같은 시각적 도구를 통해 어떤 상위 이벤트가 하위 이벤트를 발생시켰는지 그 인과 관계를 보여줍니다 [1, 3, 4]. 이를 통해 개발자는 런타임 성능을 저하시키는 가장 무거운 스택이나 불필요한 자바스크립트 함수 호출 과정을 추적할 수 있습니다 [2, 5].
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** AI 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[Chrome DevTools]], [[Flame Chart]], [[Performance Panel]]
-- **Projects/Contexts:** [[Analyze runtime performance]]
-- **Contradictions/Notes:** 소스에 제공된 콜 스택 관련 내용은 일반적인 프로그래밍 이론보다는 전적으로 Chrome DevTools의 런타임 성능 분석(Performance panel) 맥락에서만 설명되어 있습니다.
-
----
-*Last updated: 2026-04-19*
-- Raw Source: [[00_Raw/2026-04-20/Call Stack.md]]
----
diff --git a/AI/Central-Pattern-Generators.md b/AI/Central-Pattern-Generators.md
deleted file mode 100644
index 7c6ec523..00000000
--- a/AI/Central-Pattern-Generators.md
+++ /dev/null
@@ -1,27 +0,0 @@
----
-id: P-REINFORCE-AI-CPG
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.96
-tags: [CPG, Robotics, Neuroscience, Locomotion]
-last_reinforced: 2026-04-20
----
-
-# [[Central-Pattern-Generators]] (중추 패턴 생성기 CPG)
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 뇌의 복잡한 연산 없이도 척수 수준에서 리듬감 있는 동작(걷기, 수영, 비행)을 자동으로 만들어내는 생체 회로의 신비다.
-
-## 📖 구조화된 지식 (Synthesized Content)
-- **Neural Oscillators (신경 진동자)**:
-    - 외부의 지속적인 입력이 없어도 스스로 리드미컬한 신호를 만들어내는 뉴런의 집단. 생명체의 보행을 제어하는 핵심 엔진이다.
-- **Robotics Application**:
-    - 로봇이 험지에서 매 순간 계산을 통해 걷는 대신, CPG 모델을 적용하여 자연스러운 반사 신경(Reflex)처럼 장애물을 넘게 만드는 방식.
-- **Distributed Control (분산 제어)**:
-    - 중앙 집중 스케줄러가 아닌, 각 다리나 마디가 고유의 진동자를 가지고 서로 동기화(Synchronization)되어 전체의 조화를 이루는 구조.
-
-## ⚠️ 모순 및 업데이트 (RL Update)
-- CPG만으로는 복잡한 환경 변화에 대응하기 어렵다. 따라서 상위 레벨의 강화학습(RL)이 방향과 속도를 결정하고, 하위 레벨의 CPG가 실제 관절 리듬을 담당하는 계층적 제어(Hierarchical Control)가 현대 로보틱스의 정석이다.
-
-## 🔗 지식 연결 (Graph)
-- Related: [[Robotic Manipulation]] , [[Autonomous-Vehicle-Path-Planning]]
-- Foundation: [[Systemic_Simulation_Principles]]
diff --git a/AI/CesiumJS.md b/AI/CesiumJS.md
deleted file mode 100644
index 07d94958..00000000
--- a/AI/CesiumJS.md
+++ /dev/null
@@ -1,34 +0,0 @@
----
-id: P-REINFORCE-AUTO-39CDC5
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - CesiumJS"
----
-
-# [[CesiumJS]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> CesiumJS는 웹을 위한 오픈 소스 3D 시각화 엔진으로, 주로 대규모 지형 공간 데이터의 시각화를 선도하는 기술입니다 [1, 2]. 3D 타일(3D Tiles), 지형(terrain), 위성 이미지 등 방대한 양의 3D 콘텐츠를 스트리밍하고 렌더링하는 데 활용됩니다 [1, 2]. 지표면에서 우주 공간에 이르는 거대한 가상 세계를 효율적으로 처리하기 위해 z-파이팅(z-fighting)을 방지하는 다중 절두체(multiple frustums) 및 명시적 렌더링(explicit rendering)과 같은 독자적인 WebGL 렌더링 파이프라인을 구축하고 있습니다 [3, 4].
-
-## 📖 구조화된 지식 (Synthesized Content)
-- **렌더링 파이프라인 및 다중 절두체 (Multiple Frustums):** CesiumJS는 다양한 광원을 처리하는 씬이 드물기 때문에 전통적인 포워드 셰이딩(forward-shading) 파이프라인을 사용합니다 [4]. 특히 거대한 가시거리를 지원하면서 멀리 있는 객체 간의 z-파이팅(z-fighting) 아티팩트를 피하기 위해 뷰 볼륨을 여러 개의 절두체로 분할하여 관리하는 독특한 방식을 사용합니다 [3, 4]. 가장 먼 절두체부터 시작하여 매번 깊이 버퍼를 지우면서 순차적으로 명령을 실행합니다 [5].
-- **Scene.render와 Primitive 관리:** 프레임 렌더링의 핵심인 `Scene.render`는 애니메이션, 업데이트, 렌더링의 파이프라인을 관리합니다 [4, 6]. 업데이트 단계에서 씬의 기본 요소(Primitive, 예: 지형과 이미지를 처리하는 Globe 엔진)들이 WebGL 리소스를 생성하거나 업데이트하고, `DrawCommand` 객체 목록을 반환합니다 [7, 8]. 이 중 가시성 테스트를 통과한 '잠재적 가시 집합(Potentially Visible Set)'만이 파이프라인을 따라 렌더링됩니다 [8].
-- **투명도 처리 (OIT) 및 정렬:** 절두체 내에서 불투명(opaque) 명령을 먼저 실행한 후 반투명(translucent) 명령을 실행합니다 [5]. 하드웨어가 부동 소수점 텍스처를 지원하는 경우, 순서 비의존 투명도([[Order-Independent Transparency (OIT)]]) 기법을 적용하여 겹치는 반투명 객체의 시각적 품질을 높이고 CPU 정렬 오버헤드를 방지합니다 [5]. 
-- **명시적 렌더링 (Explicit Rendering / requestRenderMode):** 지속적으로 프레임을 렌더링하는 대신, 성능을 최적화하기 위해 `requestRenderMode` 기능을 지원합니다 [9]. 이 모드가 활성화되면 카메라 이동, 시뮬레이션 시간 변경, 또는 새로운 데이터(3D 타일 등)가 로드될 때만 명시적으로 새 프레임을 렌더링합니다 [9, 10]. 이를 통해 유휴 상태(idle)에서 CPU 사용률을 25.1%에서 3.0% 수준으로 크게 절약할 수 있습니다 [10, 11].
-- **가우시안 스플래팅(Gaussian Splatting) 이슈:** 최근 가우시안 스플랫 렌더링 시 대규모 데이터셋 처리 과정에서 여러 프레임에 걸친 깊이 정렬 수행 중 프로미스 간섭(promise interference)으로 인한 WebGL 오류와 미세 지연(micro-stuttering) 현상이 보고된 바 있습니다 [12-14]. 여러 개의 프로미스 체인이 중첩되면서 정렬 결과를 오염시켜 모델이 깜빡이거나 사라지는 문제를 유발합니다 [12, 14].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** AI 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[WebGL]], [[3D Tiles]], [[Order-Independent Transparency (OIT)]], [[Gaussian Splatting]], [[Multiple Frustums]]
-- **Projects/Contexts:** [[Geospatial Visualization]], [[requestRenderMode]]
-- **Contradictions/Notes:** 소스에 따르면, Cesium팀은 엔진을 지속적으로 최적화하고 있음에도 불구하고 OIT 및 지형 깊이 버퍼를 위한 전체 화면 패스(fullscreen passes) 기능이 추가되면서 채우기 속도(fillrate)가 제한된 환경에서는 구버전(예: 1.1)에 비해 최신 버전(예: 1.10)의 평균 프레임 속도(FPS)가 오히려 감소하는 사례가 보고되기도 했습니다 [15, 16].
-
----
-*Last updated: 2026-04-19*
-- Raw Source: [[00_Raw/2026-04-20/CesiumJS.md]]
----
diff --git a/AI/Chain-of-Thought (CoT  罽).md b/AI/Chain-of-Thought (CoT  罽).md
deleted file mode 100644
index 9b03c5ba..00000000
--- a/AI/Chain-of-Thought (CoT  罽).md	
+++ /dev/null
@@ -1,27 +0,0 @@
----
-id: P-REINFORCE-AI-COT
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.99
-tags: [LLM, Chain-of-Thought, CoT, Inference, Search]
-last_reinforced: 2026-04-20
----
-
-# [[Chain-of-Thought]] (사고의 사슬 CoT)
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 거대 언어 모델에게 "생각해 봐"라고 한마디 하는 것만으로도, 문제를 단계적으로 분해하여 정답 도출 가능성을 비약적으로 높이는 추론의 기적이다.
-
-## 📖 구조화된 지식 (Synthesized Content)
-- **Step-by-Step Reasoning**:
-    - 질문에 바로 답하지 않고, 중간 과정(Rationales)을 텍스트로 먼저 생성하게 유도함으로써 모델이 자신의 이전 출력을 다음 추론의 근거로 활용하게 하는 기법.
-- **Zero-shot CoT**:
-    - 프롬프트 끝에 "Let's think step by step"이라는 문구만 추가해도 상식 추론과 수학 문제 해결 능력이 폭발적으로 증가한다.
-- **Self-Consistency**:
-    - 여러 개의 CoT 경로를 생성하게 하여 가장 공통적으로 도출된 결론을 정답으로 선택하는 기법.
-
-## ⚠️ 모순 및 업데이트 (RL Update)
-- CoT는 항상 유리하지 않다. 단순 사실 확인 문제에서는 오히려 불필요한 텍스트 생성으로 인해 에러(Hallucination)가 발생할 확률이 있다. 최근에는 이를 고도화한 `Tree-of-Thoughts (ToT)` 또는 `OpenAI o1`처럼 내부적으로 강화학습을 통해 최적의 사고 경로를 찾는 모델로 진화 중이다.
-
-## 🔗 지식 연결 (Graph)
-- Related: [[Best-of-N-Sampling]] , [[Automated-Reasoning]]
-- Foundation: [[Information Theory]]
diff --git a/AI/Chain-of-Thought (CoT 사고 사슬).md b/AI/Chain-of-Thought (CoT 사고 사슬).md
deleted file mode 100644
index 35e3193e..00000000
--- a/AI/Chain-of-Thought (CoT 사고 사슬).md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-550B46
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Chain-of-Thought (CoT 사고 사슬)"
----
-
-# [[Chain-of-Thought (CoT 사고 사슬)]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** AI 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Chain-of-Thought (CoT, 사고 사슬).md]]
----
diff --git a/AI/Chrome DevTools Memory Profiling.md b/AI/Chrome DevTools Memory Profiling.md
deleted file mode 100644
index 16163032..00000000
--- a/AI/Chrome DevTools Memory Profiling.md	
+++ /dev/null
@@ -1,43 +0,0 @@
----
-id: P-REINFORCE-AUTO-B1B522
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Chrome DevTools Memory Profiling"
----
-
-# [[Chrome DevTools Memory Profiling]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> Chrome DevTools Memory Profiling은 JavaScript 애플리케이션 및 브라우저에서 발생하는 메모리 누수를 감지하고 분석하기 위한 분석 도구 모음입니다 [1, 2]. 주로 DevTools의 Memory 패널을 통해 제공되며, 객체의 메모리 할당 시점, 유지(Retaining) 경로, 가비지 컬렉션 여부를 시각적으로 추적하여 정상적으로 정리되지 않은 객체를 식별합니다 [3-6]. 이를 통해 개발자는 메모리 힙(Heap) 상태를 정밀하게 분석하고 메모리 부족 현상이나 성능 저하를 유발하는 코드의 근본 원인을 파악할 수 있습니다 [7-9].
-
-## 📖 구조화된 지식 (Synthesized Content)
-*   **핵심 프로파일링 도구 (Memory Panel Tools):**
-    *   **Heap Snapshot (힙 스냅샷):** 특정 시점의 전체 메모리 객체 그래프를 캡처하는 도구입니다 [3, 10]. 의심되는 작업 전, 작업 중, 작업 후의 세 번의 스냅샷을 찍어 비교하는 '3-스냅샷 기법(three-snapshot technique)'을 통해 일회성 할당을 필터링하고 실제 누수 후보를 안정적으로 식별할 수 있습니다 [7, 11]. 제공되는 뷰(View)에는 생성자별로 객체를 묶어 크기를 보여주는 Summary, 두 스냅샷 간의 차이를 보여주는 Comparison, 애플리케이션 구조를 조감도로 보여주는 Containment, 메모리 할당의 파이 차트를 보여주는 Statistics 등이 있습니다 [9].
-    *   **Allocation instrumentation on timeline (타임라인의 할당 계측):** 일정 기간 동안의 모든 메모리 할당을 스택 트레이스와 함께 기록하며, 최소 50ms 간격으로 스냅샷을 주기적으로 캡처합니다 [3, 12, 13]. 타임라인에서 파란색 막대는 기록 종료 시점까지 여전히 살아있는 객체(누수 후보)를 의미하며, 회색 막대는 할당 후 이미 가비지 컬렉션된 객체를 의미합니다 [3, 4, 14, 15].
-    *   **Allocation sampling (할당 샘플링):** 전체 할당 추적보다 오버헤드가 적은 통계적 샘플링 방법으로, 프로덕션 환경의 프로파일링에 적합합니다 [16].
-
-*   **주요 지표 및 분석 개념:**
-    *   **Shallow Size vs. Retained Size:** 'Shallow size'는 객체 자체가 독립적으로 차지하는 메모리 크기(일반적으로 문자열이나 배열이 큼)이며, 'Retained size'는 해당 객체를 삭제하여 참조가 끊어졌을 때 가비지 컬렉터를 통해 확보할 수 있는 총 메모리 크기를 의미합니다 [17].
-    *   **Retainers (유지 경로):** 특정 객체를 메모리에 살아있게 만들어 가비지 컬렉션을 방해하는 참조 체인을 보여줍니다 [3, 6]. 개발자는 이 트리를 확인하여 어떤 참조가 메모리 누수를 유발하는지 파악할 수 있습니다 [8, 18].
-    *   **객체 ID (Object ID):** 객체 이름 뒤에 붙는 `@` 기호와 숫자는 고유 ID로, 가비지 컬렉션 과정에서 객체가 이동하더라도 변하지 않아 여러 스냅샷에 걸쳐 특정 객체의 상태를 정확하게 추적 및 비교할 수 있게 해줍니다 [12, 19, 20].
-
-*   **프로파일링을 통해 식별되는 주요 메모리 누수 패턴:**
-    *   문서(DOM)에서는 제거되었으나 자바스크립트 변수, Map/Set, 또는 클로저 등에 의해 여전히 참조되고 있는 분리된 DOM 노드(Detached DOM nodes) [16, 21, 22].
-    *   생명 주기에 맞게 제거되지 않고 반복적으로 쌓이는 이벤트 리스너(Event listener accumulation) 및 잊혀진 타이머나 옵저버(Forgotten timers and observers) [23, 24].
-    *   여러 클로저가 스코프를 공유할 때, 큰 데이터를 캡처한 변수를 다른 클로저의 수명 때문에 메모리에서 해제하지 못하는 클로저 스코프 보존(Closure scope retention) [23].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** AI 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[Heap Snapshot]], [[Allocation Timeline]], [[Garbage Collection]], [[Retaining Path]], [[Shallow Size and Retained Size]]
-- **Projects/Contexts:** [[V8 Engine Memory Management]], [[Browser Memory Leak Detection]]
-- **Contradictions/Notes:** 소스 간의 직접적인 모순은 없습니다. 다만, 실무적 주의사항으로 `console.log`가 평가된 객체에 대한 참조를 계속 유지하여 가짜 양성(false positive)의 메모리 누수를 표시할 수 있으므로, 메모리 누수 조사 중에는 콘솔을 지우거나 큰 객체 기록을 피해야 한다고 경고하고 있습니다 [21, 25]. 또한 코드의 난독화(Minified code) 때문에 Retainer 체인을 읽기 어려울 수 있으므로, 의미 있는 함수/변수 명을 보려면 소스 맵(Source maps)을 활성화해야 합니다 [25].
-
----
-*Last updated: 2026-04-19*
-- Raw Source: [[00_Raw/2026-04-20/Chrome DevTools Memory Profiling.md]]
----
diff --git a/AI/Chrome DevTools 메모리 분석 및 성능 최적화.md b/AI/Chrome DevTools 메모리 분석 및 성능 최적화.md
deleted file mode 100644
index e1ad3672..00000000
--- a/AI/Chrome DevTools 메모리 분석 및 성능 최적화.md	
+++ /dev/null
@@ -1,30 +0,0 @@
----
-id: P-REINFORCE-AUTO-9DC3E3
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Chrome DevTools 메모리 분석 및 성능 최적화"
----
-
-# [[Chrome DevTools 메모리 분석 및 성능 최적화]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> Chrome DevTools는 웹 및 Node.js 애플리케이션의 메모리 누수를 감지하고 성능을 최적화하기 위한 강력한 메모리 분석 도구를 제공한다 [1, 2]. 핵심 기능으로는 특정 시점의 메모리 상태를 캡처하는 힙 스냅샷(Heap snapshot), 시간에 따른 객체 할당을 추적하는 할당 타임라인(Allocation timeline), 그리고 통계적 샘플링 방식의 할당 샘플링(Allocation sampling)이 있다 [3, 4]. 개발자는 이러한 도구를 사용하여 가비지 컬렉션(GC) 이후에도 메모리에 남아있는 객체와 그 참조 경로(Retaining path)를 식별함으로써, 메모리 누수와 성능 저하의 근본 원인을 파악하고 코드를 최적화할 수 있다 [1, 3, 5, 6].
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** AI 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[가비지 컬렉션(Garbage Collection)]], [[V8 JavaScript Engine]], [[힙 메모리(Heap Memory)]], [[메모리 누수(Memory Leak)]], [[Retainers(유지 경로)]]
-- **Projects/Contexts:** [[Node.js 프로덕션 메모리 병목 분석]], [[SPA 라우트 전환 성능 최적화]]
-- **Contradictions/Notes:** DevTools의 콘솔(Console)에 `console.log`를 통해 출력된 객체는 콘솔에 의해 지속적으로 참조가 유지되므로 가비지 컬렉션의 대상이 되지 않는다. 따라서 메모리 누수를 정확히 조사할 때는 대형 객체의 로깅을 피하거나 콘솔을 비워야 한다 [18]. 더불어, 원시 데이터인 숫자(Number)와 같은 비문자열 값은 캡처되지 않으며, 원시 힙 데이터에는 수많은 V8 내부 객체도 포함되어 있어 분석 시 "Constructor" 필터를 적용해 애플리케이션 객체에만 집중하는 것이 좋다 [9, 18].
-
----
-*Last updated: 2026-04-19*
-- Raw Source: [[00_Raw/2026-04-20/Chrome DevTools 메모리 분석 및 성능 최적화.md]]
----
diff --git a/AI/Chrome DevTools 메모리 프로파일링 및 힙 스냅샷 분석.md b/AI/Chrome DevTools 메모리 프로파일링 및 힙 스냅샷 분석.md
deleted file mode 100644
index b8d226d8..00000000
--- a/AI/Chrome DevTools 메모리 프로파일링 및 힙 스냅샷 분석.md	
+++ /dev/null
@@ -1,54 +0,0 @@
----
-id: P-REINFORCE-AUTO-EF52CE
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Chrome DevTools 메모리 프로파일링 및 힙 스냅샷 분석"
----
-
-# [[Chrome DevTools 메모리 프로파일링 및 힙 스냅샷 분석]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> Chrome DevTools의 메모리 프로파일링 및 힙 스냅샷 분석은 웹 애플리케이션 및 Node.js 환경에서 발생하는 메모리 누수를 찾아내고 객체의 보존 상태를 파악하는 데 사용되는 핵심 디버깅 기법입니다. 메모리 패널은 전체 객체 그래프를 캡처하는 힙 스냅샷, 시간에 따른 할당을 추적하는 타임라인 계측, 그리고 프로덕션에 적합한 샘플링 도구를 제공합니다. 개발자는 이러한 도구와 객체의 참조 체인(Retaining path)을 분석하여 가비지 컬렉터(GC)에 의해 해제되어야 할 객체가 왜 메모리에 남아있는지 근본 원인을 파악할 수 있습니다.
-
-## 📖 구조화된 지식 (Synthesized Content)
-- **DevTools 메모리 패널의 핵심 도구**
-  Chrome DevTools의 Memory 패널은 주로 세 가지 분석 도구를 제공합니다. 
-  1. **Heap snapshot (힙 스냅샷):** 특정 시점의 전체 객체 그래프를 캡처합니다 [1].
-  2. **Allocation instrumentation on timeline (타임라인에 할당 계측):** 특정 기간 동안의 모든 메모리 할당과 스택 트레이스를 기록합니다 [1]. 기록을 시작하면 50ms마다 힙 스냅샷을 주기적으로 캡처하고 기록이 끝날 때 최종 스냅샷을 생성합니다 [2, 3].
-  3. **Allocation sampling (할당 샘플링):** 전체 계측을 수행하는 대신 통계적 샘플링을 사용하여 오버헤드가 적기 때문에 프로덕션 환경의 프로파일링에 적합합니다 [4].
-
-- **힙 스냅샷 뷰(View)의 종류와 활용**
-  캡처한 힙 스냅샷은 목적에 맞게 여러 가지 뷰를 통해 분석할 수 있습니다 [5].
-  - **Summary(요약) 뷰:** 객체를 생성자(Constructor) 이름으로 그룹화하여 보여줍니다 [5, 6]. 각 객체가 점유하는 자체 메모리인 '얕은 크기(Shallow size)'와, 해당 객체가 삭제될 때 해제될 수 있는 최대 메모리 크기인 '보존된 크기(Retained size)'를 확인할 수 있습니다 [7].
-  - **Comparison(비교) 뷰:** 두 개 이상의 스냅샷 간의 차이를 보여줍니다. 특정 작업 전후의 스냅샷을 비교하여 메모리 누수의 존재와 원인을 확인하는 데 유용합니다 [5, 8].
-  - **Containment(포함) 뷰:** 애플리케이션 객체 구조를 조감(Bird's eye view)할 수 있으며, DOMWindow 객체, GC 루트(GC roots), 네이티브 객체를 통해 글로벌 네임스페이스에서 참조되는 객체를 분석할 수 있습니다 [5, 9, 10].
-
-- **타임라인 할당 분석을 통한 누수 추적**
-  타임라인을 이용한 할당 계측 시, 상단에 나타나는 막대의 높이는 할당된 객체의 크기를 의미하며 막대의 색상은 객체의 생존 여부를 나타냅니다 [11, 12].
-  - **파란색 막대:** 타임라인 기록이 끝날 때까지 여전히 살아있는(Live) 객체를 의미하며, 이 객체들이 메모리 누수 후보가 될 수 있습니다 [1, 11-13].
-  - **회색 막대:** 타임라인 동안 할당되었으나 이후 가비지 컬렉션(GC)에 의해 수집된 객체를 의미합니다 [1, 11-13].
-  타임라인에서 파란색 막대를 확대(Zoom in)한 뒤 'Retainers(보유자)' 패널을 확인하면, 해당 객체가 수집되지 못하고 계속 살아있게 만드는 참조 체인을 파악할 수 있습니다 [14-16].
-
-- **메모리 누수 탐지 전략: 3단계 스냅샷 기법(Three-snapshot technique)**
-  메모리 누수를 감지하는 가장 신뢰할 수 있는 방법은 3단계 스냅샷 기법입니다. 먼저 기준이 되는 스냅샷 1을 찍고, 누수가 의심되는 작업(예: 모달 열기/닫기 등)을 수행한 뒤 스냅샷 2를 찍습니다. 그다음 동일한 작업을 다시 반복하고 스냅샷 3을 캡처합니다. 이후 스냅샷 2와 3을 비교하여, 스냅샷 1과 2 사이에서 할당되었지만 스냅샷 3에서도 여전히 살아있는 객체를 찾음으로써 일회성 할당(False positives)을 걸러내고 실제 누수 후보를 특정할 수 있습니다 [17].
-
-- **분석 시 주의사항(Gotchas)**
-  - 힙 스냅샷에는 애플리케이션의 객체뿐만 아니라 `(compiled code)`, `(concatenated string)`, `InternalNode` 등 수많은 V8 내부 객체들이 포함되므로, 의미 있는 객체에 집중하려면 생성자(Constructor) 필터링을 사용하는 것이 좋습니다 [18-22].
-  - 난독화된(Minified) 코드에서는 변수나 함수 이름이 제대로 보이지 않으므로, 의미 있는 Retainer 트리를 확인하려면 DevTools에서 소스 맵(Source maps)을 사용해야 합니다 [18].
-  - 개발자 도구 콘솔에서 `console.log`로 출력된 객체는 계속해서 참조가 유지되므로 누수 조사 시에는 콘솔을 비우거나 대용량 객체 로깅을 피해야 합니다 [18].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** AI 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[메모리 누수(Memory Leaks)]], [[가비지 컬렉션(Garbage Collection)]], [[V8 엔진 메모리 구조]], [[객체 참조 체인(Retainers)]]
-- **Projects/Contexts:** [[Node.js 프로덕션 메모리 문제 해결]], [[웹 프론트엔드 성능 최적화]]
-- **Contradictions/Notes:** 단순히 메모리 그래프가 상승한다고 해서 모두 우발적인 메모리 누수인 것은 아닙니다. 애플리케이션의 캐시(Caches)나 실행 취소 기록(Undo histories) 등은 의도적으로 데이터를 보존하도록 설계되었으므로, 이러한 '의도된 보존'과 '우발적인 보존(누수)'을 명확하게 구분해야 합니다 [18].
-
----
-*Last updated: 2026-04-19*
-- Raw Source: [[00_Raw/2026-04-20/Chrome DevTools 메모리 프로파일링 및 힙 스냅샷 분석.md]]
----
diff --git a/AI/Chrome DevTools 메모리 프로파일링.md b/AI/Chrome DevTools 메모리 프로파일링.md
deleted file mode 100644
index 56bd3dca..00000000
--- a/AI/Chrome DevTools 메모리 프로파일링.md	
+++ /dev/null
@@ -1,33 +0,0 @@
----
-id: P-REINFORCE-AUTO-8471ED
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Chrome DevTools 메모리 프로파일링"
----
-
-# [[Chrome DevTools 메모리 프로파일링]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> Chrome DevTools 메모리 프로파일링은 개발자가 힙(Heap) 스냅샷을 캡처하고 시간에 따른 메모리 할당을 추적하여 브라우저 환경에서 발생하는 메모리 누수를 감지하고 분석하는 과정입니다 [1-4]. 이는 JavaScript 객체와 DOM 노드의 메모리 분포를 보여주며, 가비지 컬렉션(GC) 이후에도 불필요하게 남아있는 객체의 참조 경로(Retaining Path)를 시각적으로 파악할 수 있도록 돕습니다 [1, 4-6]. 이를 통해 브라우저 메모리 할당 시점별 힙의 상세한 동작과 메모리 보존(Retention) 원인을 명확히 식별할 수 있습니다 [2, 7].
-
-## 📖 구조화된 지식 (Synthesized Content)
-* **힙 스냅샷(Heap Snapshot)과 3-스냅샷 기법:** 힙 스냅샷은 특정 시점의 전체 객체 그래프를 캡처하는 도구입니다 [2, 3]. 메모리 누수 탐지에서 가장 신뢰할 수 있는 방법은 '3-스냅샷 기법'으로, 기준 스냅샷을 찍고 누수가 의심되는 작업을 수행한 뒤 두 번째 스냅샷을 찍고, 작업을 반복한 후 세 번째 스냅샷을 찍는 방식입니다 [8]. 이를 통해 일회성 메모리 할당을 필터링하고 실제 누수 후보를 찾아낼 수 있습니다 [8]. 스냅샷은 생성자별로 객체를 그룹화하는 'Summary' 뷰, 두 스냅샷 간의 차이를 보여주는 'Comparison' 뷰, 전역 네임스페이스에 참조된 객체의 구조를 파악하는 'Containment' 뷰 등을 제공합니다 [9].
-* **타임라인의 할당 계측(Allocation instrumentation on timeline):** 이 도구는 힙 프로파일러의 상세 스냅샷 정보와 타임라인 패널의 점진적인 업데이트 추적 기능을 결합한 것입니다 [10, 11]. 특정 기간 동안 발생한 모든 메모리 할당을 스택 트레이스와 함께 최소 50ms마다 주기적으로 기록합니다 [2, 12, 13]. 타임라인 상의 막대 높이는 할당된 객체의 크기를 의미하며, 파란색 막대는 타임라인 종료 시점까지 살아있는 객체를, 회색 막대는 할당 후 가비지 컬렉션(GC)된 객체를 나타냅니다 [5, 14, 15].
-* **할당 샘플링(Allocation sampling):** 모든 할당을 추적하는 타임라인 계측 방식에 비해 시스템 오버헤드가 없기 때문에, 운영(Production) 환경의 프로파일링에 적합한 가벼운 통계적 샘플링 방식입니다 [16].
-* **보존 경로(Retainers)와 고유 객체 식별자:** 메모리 패널 하단의 'Retainers' 섹션은 GC 루트(Root)에서부터 특정 객체를 계속 살아있게 유지하는 참조 체인을 역순으로 보여주어 메모리 누수의 근본 원인을 추적할 수 있게 합니다 [2, 7, 17]. 또한, 각 객체에는 가비지 컬렉션 과정에서 객체의 물리적 위치가 이동하더라도 여러 스냅샷 간에 동일하게 유지되는 고유 ID(`@` 기호 뒤의 숫자)가 부여되어 정밀한 개별 객체 단위의 비교 분석이 가능합니다 [12, 13, 18, 19].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** AI 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[힙 스냅샷(Heap Snapshot)]], [[타임라인 할당 계측(Allocation instrumentation on timeline)]], [[가비지 컬렉션(Garbage Collection)]], [[보존 경로(Retaining Path)]]
-- **Projects/Contexts:** [[V8 JavaScript Engine 메모리 관리 및 가비지 컬렉션]], [[브라우저 메모리 누수 탐지(Browser Memory Leak Detection)]]
-- **Contradictions/Notes:** 소스의 메모리 누수 분석 시 주의사항에 따르면, DevTools 콘솔에서의 `console.log` 출력은 로깅된 객체에 대한 참조를 계속 유지하므로 실제로는 누수가 아니더라도 가비지 컬렉션이 되지 않아 조사 과정에서 혼선을 줄 수 있습니다 [20].
-
----
-*Last updated: 2026-04-19*
-- Raw Source: [[00_Raw/2026-04-20/Chrome DevTools 메모리 프로파일링.md]]
----
diff --git a/AI/Chrome DevTools.md b/AI/Chrome DevTools.md
deleted file mode 100644
index de08af47..00000000
--- a/AI/Chrome DevTools.md	
+++ /dev/null
@@ -1,50 +0,0 @@
----
-id: P-REINFORCE-AUTO-6965B5
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Chrome DevTools"
----
-
-# [[Chrome DevTools]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> Chrome DevTools는 웹 성능 분석 및 메모리 누수 진단을 수행할 수 있는 브라우저 내장 개발자 도구이다 [1]. 이 도구의 메모리(Memory) 패널은 힙 스냅샷 캡처와 할당 타임라인 기록 기능을 제공하여 객체의 참조 상태와 메모리 상태를 추적할 수 있도록 돕는다 [1-3]. 개발자는 이를 통해 가비지 컬렉션(GC) 이후에도 살아남아 메모리를 점유하고 있는 객체들을 식별하고 분석할 수 있다 [4-6].
-
-## 📖 구조화된 지식 (Synthesized Content)
-* **메모리 패널(Memory Panel)의 핵심 기능:**
-  Chrome DevTools의 메모리 패널은 주로 세 가지 진단 도구를 제공한다 [1].
-  * **힙 스냅샷(Heap snapshot):** 특정 시점의 완전한 객체 그래프를 캡처하여 생성자(Constructor)별 객체, 유지된 크기(Retained Size), 참조 트리 등을 보여준다 [1, 7, 8].
-  * **타임라인 할당 계측(Allocation instrumentation on timeline):** 특정 기간 내의 모든 메모리 할당을 시간 순으로 스택 트레이스와 함께 기록한다 [1, 5, 9].
-  * **할당 샘플링(Allocation sampling):** 통계적 샘플링을 사용하여 가벼운 오버헤드로 메모리 할당을 추적하며 프로덕션 환경 분석에 적합하다 [10].
-
-* **힙 스냅샷 분석 뷰(Heap Snapshot Views):**
-  스냅샷 데이터는 목적에 따라 여러 가지 뷰(View)로 분석할 수 있다 [11].
-  * **Summary view:** 생성자 이름 및 소스 기준으로 객체를 그룹화하여 타입별 메모리 사용량 및 DOM 누수를 추적한다 [7, 11].
-  * **Comparison view:** 두 개 이상의 스냅샷을 비교하여 특정 작업 전후로 해제된 메모리와 추가/삭제된 객체의 델타를 확인해 누수 여부를 파악한다 [11-13].
-  * **Containment view:** 전역 네임스페이스(window)나 클로저 내에서 참조되는 객체의 전체적인 구조를 로우 레벨에서 보여준다 [11, 13].
-  * **Statistics:** 메모리 할당을 코드, 문자열, 배열 등의 범주로 나누어 파이 차트로 시각화한다 [11].
-  * **Retainers 패널:** 선택한 객체를 계속 살아있게 만드는 참조 체인(Retaining path)을 표시하여, 해당 객체가 가비지 컬렉션 되지 않는 이유를 확인하고 불필요한 참조를 코드에서 제거할 수 있게 돕는다 [1, 14-16].
-
-* **할당 타임라인 시각화:**
-  타임라인 보고서는 힙 프로파일러의 스냅샷 정보와 타임라인 패널의 점진적 업데이트 기능을 결합한 것이다 [5, 9]. 메모리 할당 과정은 최대 50ms 빈도로 기록되며 막대그래프로 표시된다 [2, 17]. 파란색 막대는 타임라인 기록이 끝날 때까지 여전히 살아있는 객체를 의미하며 메모리 누수 후보군이 되고, 회색 막대는 할당 후 가비지 컬렉터에 의해 정상적으로 수집된 객체를 의미한다 [18-21].
-
-* **메모리 누수 진단 시 유의사항:**
-  * DevTools 콘솔에 로깅(`console.log`)된 객체들은 콘솔 도구 자체에 의해 도달 가능한 상태로 유지되므로, 메모리 누수를 조사할 때는 콘솔을 지우거나 대형 객체 로깅을 피해야 한다 [22].
-  * 축소된(Minified) 코드는 Retainer 체인을 알아보기 어렵게 만들므로, 소스 맵(Source maps)을 활용해 원래의 변수 및 함수 이름을 복원해야 정확한 분석이 가능하다 [22].
-  * 문서(DOM)에서 제거되었음에도 불구하고 JavaScript 클로저나 Map/Set 엔트리에 의해 참조되어 남아 있는 분리된 DOM 노드(Detached DOM nodes)를 필터링하여 찾을 수 있다 [10, 23].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** AI 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[Heap Snapshot]], [[Allocation Timeline]], [[Garbage Collection]], [[Memory Leak]]
-- **Projects/Contexts:** [[Browser Memory Leak Detection]]
-- **Contradictions/Notes:** 가비지 컬렉션 과정에서 객체들이 이동할 수 있으므로 객체의 주소를 직접 추적하는 것은 의미가 없다. 대신 DevTools는 `@` 기호 뒤에 여러 스냅샷 간 유지되는 고유 식별자(Object ID)를 부여하여 정확하게 힙 상태와 객체를 비교할 수 있도록 한다 [2, 17, 24]. 
-
----
-*Last updated: 2026-04-19*
-- Raw Source: [[00_Raw/2026-04-20/Chrome DevTools.md]]
----
diff --git a/AI/Chrome 브라우저 렌더링 성능.md b/AI/Chrome 브라우저 렌더링 성능.md
deleted file mode 100644
index 252f4029..00000000
--- a/AI/Chrome 브라우저 렌더링 성능.md	
+++ /dev/null
@@ -1,42 +0,0 @@
----
-id: P-REINFORCE-AUTO-EC1033
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Chrome 브라우저 렌더링 성능"
----
-
-# [[Chrome 브라우저 렌더링 성능]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-소스에 Chrome의 핵심 렌더링 파이프라인(HTML/CSS 파싱, Layout, Paint, Composite 등)에 대한 관련 정보가 부족합니다. 단, 제공된 소스에서는 JavaScript 엔진(V8)의 메모리 관리 동작이 렌더링 및 화면 표시 성능에 미치는 영향을 다음과 같이 구체적으로 설명하고 있습니다.
-
-* **가비지 컬렉션(GC)과 렌더링 지연(Jank):**
-  V8과 같은 엔진에서 메모리를 관리하는 가비지 컬렉션 프로세스가 비효율적으로 실행될 경우, 길고 예측 불가능한 실행 일시 정지(Pause)가 발생할 수 있습니다 [1]. 이러한 일시 정지는 메인 스레드의 작업을 차단하여 상호작용이 많은 시스템이나 애니메이션의 렌더링 지연(Janky pages) 및 대기 시간(Latency) 저하 문제를 초래합니다 [2-4].
-
-* **Orinoco 프로젝트와 메인 스레드 부하 감소:**
-  V8은 메인 스레드의 부담을 줄이기 위해 병렬(Parallel), 점진적(Incremental), 동시(Concurrent) 기법을 활용하는 Orinoco 가비지 컬렉터를 도입했습니다 [3, 5-8]. 백그라운드 작업으로 GC 부하를 분산시킴으로써 메인 스레드가 JavaScript 실행 및 렌더링을 자유롭게 처리할 수 있게 되어 애니메이션, 스크롤 및 사용자 상호작용이 훨씬 매끄러워졌으며 무거운 WebGL 게임 등에서의 일시 정지 시간을 최대 50% 단축했습니다 [9].
-
-* **유휴 시간 가비지 컬렉션(Idle-time GC)을 통한 프레임 최적화:**
-  Chrome은 초당 60프레임(FPS)을 렌더링하기 위해 각 프레임당 약 16.6ms의 시간을 갖습니다 [10]. 애니메이션 및 렌더링 작업이 예상보다 일찍 완료될 경우, Chrome은 다음 프레임이 시작되기 전 남은 '유휴 시간(Idle time)'을 활용하여 백그라운드에서 GC 작업을 선제적으로 수행합니다 [9-11]. 이를 통해 메인 렌더링 작업의 중단을 방지하면서도 효과적으로 메모리를 관리할 수 있습니다.
-
-* **백그라운드 파싱(Background Parsing):**
-  페이지가 로드되는 동안 V8 엔진은 백그라운드 파싱을 활용하여 스크립트를 처리합니다. 파싱 완료 즉시 사용된 임시 메모리(Zone)를 해제함으로써 메모리 소비를 줄여, 전반적인 브라우저 리소스 효율성과 렌더링 준비 속도 향상에 기여합니다 [12].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** AI 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[가비지 컬렉션 (Garbage Collection)]], [[Orinoco]], [[유휴 시간 GC (Idle-time GC)]]
-- **Projects/Contexts:** [[V8 JavaScript Engine]], [[Blink Renderer]]
-- **Contradictions/Notes:** 소스에 관련 정보가 부족합니다. 제공된 문서는 전적으로 V8 메모리 관리, 힙 구조, 메모리 누수 분석 등 JavaScript 엔진 단의 최적화에 집중되어 있습니다. 따라서 Chrome 렌더링 파이프라인(DOM 트리, CSSOM, 컴포지팅 등) 또는 Core Web Vitals(LCP, CLS, INP)의 구체적 동작 원리에 대한 정보는 소스에 포함되어 있지 않아 기술하지 못했습니다.
-
----
-*Last updated: 2026-04-19*
-- Raw Source: [[00_Raw/2026-04-20/Chrome 브라우저 렌더링 성능.md]]
----
diff --git a/AI/Chronic-Pain-Management-Protocols.md b/AI/Chronic-Pain-Management-Protocols.md
deleted file mode 100644
index efada25b..00000000
--- a/AI/Chronic-Pain-Management-Protocols.md
+++ /dev/null
@@ -1,27 +0,0 @@
----
-id: P-REINFORCE-SCI-PAIN
-category: "[[10_Wiki/💡 Topics/Science]]"
-confidence_score: 0.94
-tags: [Pain Management, Medical, Chronic Pain, Neurology]
-last_reinforced: 2026-04-20
----
-
-# [[Chronic-Pain-Management-Protocols]] (만성 통증 관리 프로토콜)
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> "통증은 뇌의 해석이다." 실제 조직이 다 낫더라도 뇌가 '통증 회로'를 끄지 못해 발생하는 만성 고통을 신경 가소성을 이용해 재훈련하는 과정이다.
-
-## 📖 구조화된 지식 (Synthesized Content)
-- **Central Sensitization (중추 감작)**:
-    - 신경계가 과도하게 민감해져서 아주 작은 자극에도 극심한 통증으로 반응하게 된 상태. 뇌의 '경보 시스템'이 고장 난 것과 같다.
-- **Biopsychosocial Model**:
-    - 생물학적 요인뿐만 아니라 심리적(불안, 우울), 사회적 요인이 통증의 정도를 결정한다는 현대적 접근법.
-- **Gait Control Theory (관문 조절설)**:
-    - 가벼운 접촉이나 진동 같은 다른 자극을 근처 신경에 주어, 통증 신호가 뇌로 가는 '관문'을 닫게 하는 원리.
-
-## ⚠️ 모순 및 업데이트 (RL Update)
-- 단순 진통제 처방은 근본 원인을 해결하지 못하고 중독 위험만 키운다. 최근에는 명상, 점진적 운동 노출치료(Graded Motor Imagery) 등 뇌의 회로를 직접 재배열하는 치료법이 강조되고 있다.
-
-## 🔗 지식 연결 (Graph)
-- Related: [[Cognitive-Therapy-in-CBT]] , [[Biomechanics-of-Injury]]
-- Analysis: [[Clinical-Kinesiology-Assessment]]
diff --git a/AI/Circuit Discovery (ȸ ߰).md b/AI/Circuit Discovery (ȸ ߰).md
deleted file mode 100644
index c29a96bf..00000000
--- a/AI/Circuit Discovery (ȸ ߰).md	
+++ /dev/null
@@ -1,27 +0,0 @@
----
-id: P-REINFORCE-AI-CIRCUIT
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.98
-tags: [Interpretability, Neural Networks, Circuit Discovery, Mechanistic Interpretability]
-last_reinforced: 2026-04-20
----
-
-# [[Circuit-Discovery]] (회로 발견)
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> "인공신경망은 블랙박스가 아니다." 신경망 내부의 수억 개 파라미터들 사이에서 특정 로직(예: 덧셈, 문법 파악)을 수행하는 고유의 '신경 회로'를 찾아 지질학적으로 분석하는 고난도 기술이다.
-
-## 📖 구조화된 지식 (Synthesized Content)
-- **Mechanistic Interpretability**:
-    - 모델의 입력을 조금씩 바꿔보며 특정 뉴런들이 어떻게 활성화되는지(Activation Patching 등)를 분석하여, 가중치 속에 숨겨진 알고리즘을 역설계한다.
-- **Induction Heads**:
-    - 이전에 본 패턴을 기억하고 반복될 때 활성화되는 신경망 내의 특정 구조. LLM의 문맥 이해 능력의 핵심 원동력 중 하나로 밝혀졌다.
-- **Reverse Engineering**:
-    - 학습된 모델을 '읽기'를 통해 그 모델이 어떤 수학적 전략을 사용해 문제를 푸는지 인간의 언어로 설명하는 과정.
-
-## ⚠️ 모순 및 업데이트 (RL Update)
-- 대규모 모델(Llama-3, GPT-4)로 갈수록 회로가 너무 복잡해져서 일일이 분석하는 것이 불가능에 가까워진다. 최근에는 다른 '작은 AI'를 시켜서 큰 AI의 회로를 분석하게 하는 자동화된 해석 연구가 진행 중이다.
-
-## 🔗 지식 연결 (Graph)
-- Related: [[Automated-Reasoning]] , [[Complexity-Theory]]
-- Foundation: [[Information Theory]]
diff --git a/AI/Circuit Discovery (회로 발견).md b/AI/Circuit Discovery (회로 발견).md
deleted file mode 100644
index cca40c82..00000000
--- a/AI/Circuit Discovery (회로 발견).md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-0A3374
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Circuit Discovery (회로 발견)"
----
-
-# [[Circuit Discovery (회로 발견)]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** AI 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Circuit Discovery (회로 발견).md]]
----
diff --git a/AI/Circular Economy Transitions.md b/AI/Circular Economy Transitions.md
deleted file mode 100644
index fe924d5e..00000000
--- a/AI/Circular Economy Transitions.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-544952
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Circular Economy Transitions"
----
-
-# [[Circular Economy Transitions]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** AI 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Circular Economy Transitions.md]]
----
diff --git a/AI/Circular-Economy.md b/AI/Circular-Economy.md
deleted file mode 100644
index 18fe1fa3..00000000
--- a/AI/Circular-Economy.md
+++ /dev/null
@@ -1,27 +0,0 @@
----
-id: P-REINFORCE-SCI-CIRCULAR
-category: "[[10_Wiki/💡 Topics/Science]]"
-confidence_score: 0.94
-tags: [Circular Economy, Sustainability, Recycling, ESG]
-last_reinforced: 2026-04-20
----
-
-# [[Circular-Economy]] (순환 경제)
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 쓰레기는 설계 단계에서의 '지능 부족'의 결과물이다. 자원이 폐기되지 않고 영구적으로 순환하도록 시스템 자체를 다시 디자인하는 것이 순환 경제의 정수다.
-
-## 📖 구조화된 지식 (Synthesized Content)
-- **Design out Waste**:
-    - 처음부터 재활용이 불가능한 소재를 배제하고, 수리(Repair)와 분해(Disassembly)가 쉬운 제품 아키텍처를 설계한다.
-- **Product as a Service (PaaS)**:
-    - 제품을 판매하는 대신 '사용권'을 빌려주는 모델. 기업이 소유권을 유지하므로 제품의 내구성을 높이고 회수 후 재자원화하는 동기가 강화된다.
-- **Biological vs Technical Cycles**:
-    - 생물학적 자원은 안전하게 자연으로 돌아가고(Bio-degradable), 기술적 자원(금속, 플라스틱)은 에너지를 투입해 가치를 유지하며 순환시킨다.
-
-## ⚠️ 모순 및 업데이트 (RL Update)
-- 재활용 과정에서 소모되는 에너지와 탄소 배출량이 자원의 가치보다 클 때가 있다. 따라서 단순한 재활용(Recycling)보다 상위 개념인 재사용(Reuse)과 리퍼비시(Refurbish) 정책이 우선시되어야 한다.
-
-## 🔗 지식 연결 (Graph)
-- Related: [[Circular Economy Transitions]] , [[Climate Change Mitigation Frameworks]]
-- Context: [[Distributed-Systems-Engineering]]
diff --git a/AI/Clean-Architecture-Implementation.md b/AI/Clean-Architecture-Implementation.md
deleted file mode 100644
index d22681f4..00000000
--- a/AI/Clean-Architecture-Implementation.md
+++ /dev/null
@@ -1,30 +0,0 @@
----
-id: P-REINFORCE-AI-CLEANARCH-IMP
-category: "[[10_Wiki/💡 Topics/Software Architecture]]"
-confidence_score: 0.98
-tags: [Clean Architecture, Implementation, Layering, SOLID]
-last_reinforced: 2026-04-20
----
-
-# [[Clean-Architecture-Implementation]] (클린 아키텍처 구현)
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> "데이터베이스나 프레임워크는 세부 사항일 뿐이다." 비즈니스 규칙(Domain)을 외부 세계로부터 철저히 격리하여 평생 변하지 않는 단단한 원핵(Core)을 유지하는 아키텍처다.
-
-## 📖 구조화된 지식 (Synthesized Content)
-- **의존성 규칙 (Dependency Rule)**:
-    - 의존성의 방향은 항상 안쪽(Domain)으로만 향해야 한다. 도메인은 외부 라이브러리나 UI 라이브러리를 절대 알면 안 된다.
-- **4대 레이어 구성**:
-    1. **Entities**: 가장 핵심적인 비즈니스 객체 및 규칙.
-    2. **Use Cases**: 애플리케이션 특유의 비즈니스 논리 구현.
-    3. **Interface Adapters**: Controller, Presenter 등 데이터 변환기.
-    4. **Frameworks & Drivers**: DB, UI, 외부 API 등 인프라스트럭처.
-- **DIP (Dependency Inversion Principle)**:
-    - 중심부가 외부를 호출해야 할 땐 인터페이스를 정의하고, 실체는 외부에서 주입(Injection)받는다.
-
-## ⚠️ 모순 및 업데이트 (RL Update)
-- 작은 프로젝트에 클린 아키텍처를 도입하는 것은 '보일러플레이트 지옥'을 초래할 수 있다. 소규모일 땐 생산성을 챙기고, 코드 베이스가 1만 라인을 넘어가는 시점부터 점진적으로 레이어를 분리하는 **'점진적 아키텍처링'**이 실무에서 더 선호된다.
-
-## 🔗 지식 연결 (Graph)
-- Related: [[Separation_of_Concerns]] , [[Domain-Driven Design (DDD)]]
-- Foundation: [[React_Clean_Code_Best_Practices]]
diff --git a/AI/Clean-Architecture-TypeScript.md b/AI/Clean-Architecture-TypeScript.md
deleted file mode 100644
index dc5e100a..00000000
--- a/AI/Clean-Architecture-TypeScript.md
+++ /dev/null
@@ -1,27 +0,0 @@
----
-id: P-REINFORCE-AI-CLEANARCH-TS
-category: "[[10_Wiki/💡 Topics/Software Architecture]]"
-confidence_score: 0.99
-tags: [TypeScript, Clean Architecture, Type Safety, Mapping]
-last_reinforced: 2026-04-20
----
-
-# [[Clean-Architecture-TypeScript]] (타입스크립트와 클린 아키텍처)
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 타입스크립트의 강력한 타입 시스템은 클린 아키텍처의 '레이어 간 경계'를 물리적으로 강제하는 가장 완벽한 감시자다.
-
-## 📖 구조화된 지식 (Synthesized Content)
-- **Domain Interface First**:
-    - Use Case는 구체적인 레포지토리가 아닌, 타입스크립트 `interface`에만 의존하게 설계하라. 이렇게 하면 테스트 작성 시 가짜(Mock) 객체를 갈아 끼우는 것이 숨 쉬듯 쉬워진다.
-- **Data Transfer Object (DTO) Mapping**:
-    - DB 엔티티 타입을 UI까지 그대로 끌고 가지 마라. 레이어를 넘나들 때마다 `Mapper`를 통해 필요한 데이터만 추출한 전용 타입을 사용해야 '오염'을 막을 수 있다.
-- **Branded Types for ID**:
-    - `UserId`, `OrderId`를 단순한 `string`이 아닌 고유 타입으로 정의하여, 실수로 유저 ID 칸에 주문 ID를 넣는 실수를 컴파일 타임에 잡아낸다.
-
-## ⚠️ 모순 및 업데이트 (RL Update)
-- 과도한 'Mapping'은 런타임 성능과 개발 시간을 소모한다. 도메인과 데이터 계층의 모양이 90% 이상 일치한다면, 무리하게 분리하기보다 `Pick`이나 `Omit` 유틸리티 타입을 활용하여 유연하게 대응하는 것이 실용적이다.
-
-## 🔗 지식 연결 (Graph)
-- Related: [[TypeScript_Type_Safety]] , [[React_State_Management_Strategy]]
-- Foundation: [[Clean-Architecture-Implementation]]
diff --git a/AI/Climate Change Mitigation Frameworks.md b/AI/Climate Change Mitigation Frameworks.md
deleted file mode 100644
index e757d650..00000000
--- a/AI/Climate Change Mitigation Frameworks.md	
+++ /dev/null
@@ -1,27 +0,0 @@
----
-id: P-REINFORCE-SCI-CLIMATE
-category: "[[10_Wiki/💡 Topics/Science]]"
-confidence_score: 0.93
-tags: [Climate Change, Net Zero, Carbon Neutral, Mitigation]
-last_reinforced: 2026-04-20
----
-
-# [[Climate-Change-Mitigation-Frameworks]] (기후 변화 대응 프레임워크)
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 기후 변화는 단순한 환경 문제가 아니라 '에너지 시스템의 대전환' 문제이며, 과학적 실증 데이터에 기반한 탄소 예산(Carbon Budget) 관리가 핵심이다.
-
-## 📖 구조화된 지식 (Synthesized Content)
-- **Decarbonization (탈탄소화)**:
-    - 화석 연료 기반의 에너지 믹스를 태양광, 풍력, 원자력 등 저탄소 에너지원으로 전환하고 전력을 효율화한다.
-- **Carbon Capture & Storage (CCS)**:
-    - 배출된 이산화탄소를 포집하여 지하나 해저에 영구 격리하는 기술적 보완책. 넷 제로(Net Zero) 달성을 위한 최후의 수단이다.
-- **Emissions Trading System (ETS)**:
-    - 탄소 배출에 '가격'을 매겨 기업들이 자발적으로 배출량을 줄이도록 유도하는 시장 경제 기반의 정책 도구.
-
-## ⚠️ 모순 및 업데이트 (RL Update)
-- 선진국과 개도국 사이의 '기후 정의' 문제가 항상 충돌한다. 기술적 해결만큼이나 글로벌 거버넌스(Paris Agreement)와 금융 지원 체계가 동반되어야 실무적인 변화가 가능하다.
-
-## 🔗 지식 연결 (Graph)
-- Related: [[Circular-Economy]] , [[Distributed-Systems-Engineering]]
-- Policy: [[Collaboration_Governance]]
diff --git a/AI/Clinical-Kinesiology-Assessment.md b/AI/Clinical-Kinesiology-Assessment.md
deleted file mode 100644
index a0baae14..00000000
--- a/AI/Clinical-Kinesiology-Assessment.md
+++ /dev/null
@@ -1,27 +0,0 @@
----
-id: P-REINFORCE-SCI-KINESIO
-category: "[[10_Wiki/💡 Topics/Science]]"
-confidence_score: 0.95
-tags: [Kinesiology, Human Movement, Biomechanics, Assessment]
-last_reinforced: 2026-04-20
----
-
-# [[Clinical-Kinesiology-Assessment]] (임상 운동학 평가)
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 통증은 결과일 뿐, 원인은 '잘못된 움직임의 패턴'에 있다. 골격과 근육의 역학적 상호작용을 분석하여 신체의 기능을 최적화하는 과정이다.
-
-## 📖 구조화된 지식 (Synthesized Content)
-- **Joint Range of Motion (ROM)**:
-    - 관절이 가용할 수 있는 각도를 측정하여 유연성과 가동성을 평가한다. 특정 방향의 각도 제한은 부상으로 가는 조기 신호다.
-- **Muscle Imbalance Study**:
-    - 주동근(Agonist)과 길항근(Antagonist)의 힘의 균형을 분석한다. 한쪽이 너무 강하면 반대쪽은 늘어지고 약해지며(Lower Crossed Syndrome 등) 체형 불균형을 초래한다.
-- **Gait Analysis (보행 분석)**:
-    - 발바닥의 압력 분포와 걷는 자세를 분석하여 척추와 골반의 정렬 상태를 추론한다.
-
-## ⚠️ 모순 및 업데이트 (RL Update)
-- 과거에는 눈과 수동 측정기에 의존했으나, 최근에는 스마트폰 카메라를 통한 **AI 자세 분석(Pose Estimation)** 기술이 도입되어 훨씬 정밀하고 객관적인 평가가 가능해졌다.
-
-## 🔗 지식 연결 (Graph)
-- Related: [[Biomechanics-of-Injury]] , [[Biometrics]]
-- Tech: [[Computer Vision]]
diff --git a/AI/Code Review.md b/AI/Code Review.md
deleted file mode 100644
index 3705fbc5..00000000
--- a/AI/Code Review.md	
+++ /dev/null
@@ -1,40 +0,0 @@
----
-id: P-REINFORCE-AUTO-8EC3C3
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Code Review"
----
-
-# [[Code Review]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 코드 리뷰(Code Review)는 소프트웨어의 전반적인 코드 건강 상태를 개선하고 품질 및 보안을 보장하기 위해 소스 코드를 검사하는 과정입니다 [1-3]. 이는 인간 개발자가 직접 수행하는 수동 리뷰(Manual Code Review)와 정적 분석(SAST) 및 AI 도구를 활용하는 자동화된 리뷰(Automated Code Review)로 나뉩니다 [4, 5]. 최신 소프트웨어 개발 환경에서는 자동화 도구의 속도와 인간의 문맥 이해 능력을 결합하여 일관성과 보안성을 극대화하는 하이브리드 접근법이 필수적인 모범 사례로 권장됩니다 [5-8].
-
-## 📖 구조화된 지식 (Synthesized Content)
-* **수동 코드 리뷰 (Manual Code Review):**
-  개발자가 주로 풀 리퀘스트(PR)를 통해 코드를 한 줄씩 읽고 논의하는 인간 주도의 검사 방식입니다 [4, 9]. 도구가 파악할 수 없는 아키텍처의 의도, 비즈니스 로직, 복잡한 설계 결함을 찾아내는 데 탁월하며, 팀원 간의 지식 공유와 멘토링을 촉진하여 코드 가독성을 높입니다 [5, 6, 10, 11]. 구글의 코드 리뷰 표준에 따르면, 완벽한 코드를 추구하기보다는 시스템의 전반적인 코드 상태가 확실히 개선되는 방향(지속적 개선)을 기준으로 승인을 진행해야 합니다 [12, 13]. 하지만 수동 리뷰는 시간이 많이 소요되고 비용이 높으며, 리뷰어의 피로도나 편향에 의한 인적 오류가 발생할 수 있다는 단점이 있습니다 [14, 15]. 
-
-* **자동화된 코드 리뷰 (Automated Code Review):**
-  린터(Linter), 포매터(Formatter), SAST, AI 기반 리뷰 봇 등의 도구를 사용하여 코드를 실행하지 않고 정적으로 분석하는 방식입니다 [4, 16]. ESLint, Prettier, SonarQube, Snyk 등의 도구를 통해 구문 오류, 스타일 위반, 일반적인 보안 취약점(예: SQL 인젝션, XSS 등)을 대규모 코드베이스에서 빠르고 일관되게 찾아냅니다 [17-20]. 하지만 비즈니스 로직과 설계의 복잡한 의도를 이해하지 못하는 문맥의 맹점(Context Blindness)이 존재하며, 설정된 규칙에만 의존하기 때문에 잦은 오탐(False Positive)을 발생시켜 개발자의 피로도를 높일 수 있다는 한계가 있습니다 [21, 22].
-
-* **하이브리드 리뷰 워크플로우 (Hybrid Approach):**
-  2025년 기준 가장 이상적인 방식은 자동화와 인간의 통찰력을 계층화하여 결합하는 것입니다 [5, 23]. CI/CD 파이프라인이나 Git 훅(예: Husky, lint-staged)을 통해 기본 구문 검사와 정형화된 보안 결함, 스타일 교정은 자동화 도구가 코드 커밋 및 PR 단계에서 우선적으로 차단합니다 [24, 25]. 이후 인간 리뷰어는 도구가 정리한 코드를 바탕으로 아키텍처 설계, 보안 문맥, 서비스 간의 교차 영향도와 같은 고차원적인 판단에만 집중할 수 있습니다 [23, 25, 26].
-
-* **AI 기반 코드 리뷰 도구의 진화:**
-  최근에는 GitHub Copilot, Snyk Code, DeepCode 등 대규모 언어 모델(LLM)과 머신러닝 기반의 분석 도구들이 코드 리뷰에 적극 도입되고 있습니다 [27-29]. AI는 코드의 문맥을 어느 정도 해석하고, 데이터 흐름을 추적하여 오탐률을 줄이며, 리뷰 과정에서 자동으로 코드를 수정해 주는 제안(Auto-fix)을 통해 리뷰 주기를 크게 단축시킵니다 [28, 30, 31].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** AI 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[Manual Code Review]], [[Automated Code Review]], [[SAST]], [[Linting]], [[Prettier]], [[Husky]]
-- **Projects/Contexts:** [[CI/CD Pipelines]], [[SDLC]], [[Pull Request]]
-- **Contradictions/Notes:** 소스에 따르면 자동화된 리뷰 도구는 코드 검사 속도와 일관성을 극대화하지만, 비즈니스 로직과 아키텍처적 맥락을 이해하지 못해 실제 취약점의 약 22%를 놓치거나 오탐(False Positive)을 대량으로 양산할 수 있습니다 [22, 32]. 따라서 자동화 도구 단독으로는 완벽한 보안과 품질을 보장할 수 없으며, 복잡하고 위험도가 높은 코드는 반드시 인간 리뷰어의 수동 평가가 동반되어야 한다고 강조합니다 [5, 26, 33].
-
----
-*Last updated: 2026-04-19*
-- Raw Source: [[00_Raw/2026-04-20/Code Review.md]]
----
diff --git a/AI/Cognitive Biases.md b/AI/Cognitive Biases.md
deleted file mode 100644
index 933559d0..00000000
--- a/AI/Cognitive Biases.md	
+++ /dev/null
@@ -1,27 +0,0 @@
----
-id: P-REINFORCE-SCI-BIASES
-category: "[[10_Wiki/💡 Topics/Science]]"
-confidence_score: 0.99
-tags: [Cognitive Biases, Psychology, Thinking, Decision Making]
-last_reinforced: 2026-04-20
----
-
-# [[Cognitive-Biases]] (인지 편향: 생각의 함정)
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 우리의 뇌는 진화 과정에서 '정확성'보다 '생존 속도'를 택했다. 이 과정에서 발생하는 뇌의 지름길(Heuristics)이 현대 사회에서는 치명적인 판단 오류가 된다.
-
-## 📖 구조화된 지식 (Synthesized Content)
-- **Confirmation Bias (확증 편향)**:
-    - 자신의 신념과 일치하는 정보만 받아들이고, 반대되는 증거는 무시하거나 비하하는 경향. 에코 챔버(Echo Chamber) 현상의 원인이다.
-- **Availability Heuristic (가용성 휴리스틱)**:
-    - 가장 쉽게 떠오르는 기억(자극적인 뉴스 등)을 바탕으로 확률을 판단하는 오류. (예: 비행기 사고 뉴스 후 비행기가 자동차보다 위험하다고 느낌).
-- **Dunning-Kruger Effect (더닝-크루거 효과)**:
-    - 능력이 부족한 사람이 자신의 실력을 과대평가하고, 오히려 고수는 자신의 실력을 과소평가하는 현상. '자신감의 산'과 '절망의 계곡'으로 설명된다.
-
-## ⚠️ 모순 및 업데이트 (RL Update)
-- 모든 편향이 나쁜 것은 아니다. 위기 상황에서 즉각적인 본능적 판단은 생존에 유리했다. 중요한 것은 결정적인 순간에 나의 편향을 인지하고 '시스템 2(느리게 생각하기)'를 발동시키는 메타 인지 능력이다.
-
-## 🔗 지식 연결 (Graph)
-- Related: [[Behavioral-Economics]] , [[Game Design Theory]]
-- Foundation: [[Information Theory]]
diff --git a/AI/Cognitive Computing.md b/AI/Cognitive Computing.md
deleted file mode 100644
index ea8377be..00000000
--- a/AI/Cognitive Computing.md	
+++ /dev/null
@@ -1,27 +0,0 @@
----
-id: P-REINFORCE-AI-COGCOMP
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.98
-tags: [Cognitive Computing, AI, Machine Learning, Brain-Inspired]
-last_reinforced: 2026-04-20
----
-
-# [[Cognitive-Computing]] (코그니티브 컴퓨팅)
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 단순히 질문에 답하는 계산기를 넘어, 인간의 생각과 감정을 이해하고 복잡한 맥락 속에서 최적의 파트너로 진화하는 '지능의 동반자'다.
-
-## 📖 구조화된 지식 (Synthesized Content)
-- **Contextual Understanding (맥락 이해)**:
-    - 단순히 키워드를 매칭하는 것이 아니라, 대화의 전후 상황, 사용자의 의도, 감정 상태를 파악하여 가장 적절한 방식으로 정보를 제공한다.
-- **Self-Learning & Adaptive**:
-    - 정적인 알고리즘이 아니라, 상호작용이 반복될수록 사용자의 패턴을 학습하여 스스로를 최적화한다.
-- **Human-Machine Interface (HMI)**:
-    - 자연어 처리(NLP)를 넘어 시각, 청각, 촉각 등 오감을 통합한 멀티모달 인터랙션을 통해 인간과 더 자연스럽게 소통한다.
-
-## ⚠️ 모순 및 업데이트 (RL Update)
-- 과거 IBM Watson 등이 추구했던 모델이지만, 최근에는 LLM(거대 언어 모델)의 폭발적 발전으로 인해 '코그니티브'의 정의가 LLM 기반의 자율 에이전트(Autonomous Agent) 시스템으로 빠르게 재편되고 있다.
-
-## 🔗 지식 연결 (Graph)
-- Related: [[Chain-of-Thought]] , [[Automated-Reasoning]]
-- Foundation: [[Information Theory]]
diff --git a/AI/Cognitive Neuroscience of Flow.md b/AI/Cognitive Neuroscience of Flow.md
deleted file mode 100644
index 908f8ce1..00000000
--- a/AI/Cognitive Neuroscience of Flow.md	
+++ /dev/null
@@ -1,27 +0,0 @@
----
-id: P-REINFORCE-SCI-FLOW
-category: "[[10_Wiki/💡 Topics/Science]]"
-confidence_score: 0.97
-tags: [Flow State, Neuroscience, Concentration, Performance]
-last_reinforced: 2026-04-20
----
-
-# [[Cognitive-Neuroscience-of-Flow]] (몰입의 뇌과학)
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> "자아조차 잊게 만드는 완벽한 조화." 몰입(Flow)은 뇌의 보상 시스템과 주의력 시스템이 극한의 효율로 결합하여 에너지를 폭발시키는 상태다.
-
-## 📖 구조화된 지식 (Synthesized Content)
-- **Transient Hypofrontality**:
-    - 몰입 중에는 전전두엽(판단, 비판 담당)의 활동이 일시적으로 낮아진다. 이로 인해 자의식적 비판이 사라지고 오직 '하는 행위' 자체에만 매몰된다.
-- **Dopamine & Norepinephrine**:
-    - 도파민(보상)과 노르에피네프린(각성)이 다량 분비되며 학습 속도와 반응 속도를 비약적으로 높인다.
-- **Challenge-Skill Balance**:
-    - 과제의 난이도와 자신의 실력이 완벽한 균형을 이룰 때(지루함과 불안 사이) 뇌는 몰입 상태에 진입하기 가장 쉽다.
-
-## ⚠️ 모순 및 업데이트 (RL Update)
-- 몰입은 마법 같은 상태지만, 도파민 중독과 비슷한 양상을 보여 '중독성'이 있다. 건강한 몰입과 강박적 몰입을 구분하는 메타 인지가 장기적인 성장에 중요하다.
-
-## 🔗 지식 연결 (Graph)
-- Related: [[Burnout-Prevention-in-Professional-Gaming]] , [[Cognitive Psychology]]
-- Foundation: [[Information Theory]]
diff --git a/AI/Cognitive Psychology.md b/AI/Cognitive Psychology.md
deleted file mode 100644
index 2c5a4ac2..00000000
--- a/AI/Cognitive Psychology.md	
+++ /dev/null
@@ -1,27 +0,0 @@
----
-id: P-REINFORCE-SCI-COG-PSY
-category: "[[10_Wiki/💡 Topics/Science]]"
-confidence_score: 0.99
-tags: [Cognitive Psychology, Perception, Memory, Attention]
-last_reinforced: 2026-04-20
----
-
-# [[Cognitive-Psychology]] (인지 심리학)
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> "마음은 정보 처리 시스템이다." 인간의 사고 과정을 컴퓨터의 아키텍처처럼 입력(지각)-저장(기억)-처리(생각)-출력(행동)의 관점에서 분석하는 학문이다.
-
-## 📖 구조화된 지식 (Synthesized Content)
-- **Mental Representations**:
-    - 외부 세계를 뇌가 어떻게 내부 모델로 변환하여 저장하는가. (예: 스키마(Schema), 프레임(Frame)).
-- **Dual Process Theory**:
-    - 시스템 1(빠른 직관)과 시스템 2(느린 추론)가 어떻게 상호작용하며 결정을 내리는지 분석한다.
-- **Working Memory Theory**:
-    - 정보가 장기 기억으로 넘어가기 전, 머릿속에서 유지되고 처리되는 '메모리 공간'의 용량 제한(7±2 등)에 대한 연구.
-
-## ⚠️ 모순 및 업데이트 (RL Update)
-- 인지 심리학의 고전적 모델들은 '감정'을 배제한 경향이 있었다. 현대에는 인지적 처리와 감정적 처리가 뗄 수 없다는 '정서 지능(Emotional Intelligence)'과의 융합 연구가 대세다.
-
-## 🔗 지식 연결 (Graph)
-- Related: [[Cognitive-Biases]] , [[Cognitive-Therapy-in-CBT]]
-- Foundation: [[Information Theory]]
diff --git a/AI/Cognitive Reserve Theory.md b/AI/Cognitive Reserve Theory.md
deleted file mode 100644
index e708abf7..00000000
--- a/AI/Cognitive Reserve Theory.md	
+++ /dev/null
@@ -1,27 +0,0 @@
----
-id: P-REINFORCE-SCI-COG-RES
-category: "[[10_Wiki/💡 Topics/Science]]"
-confidence_score: 0.95
-tags: [Cognitive Reserve, Brain Health, Aging, Plasticity]
-last_reinforced: 2026-04-20
----
-
-# [[Cognitive-Reserve-Theory]] (인지 예비능 이론)
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> "뇌에도 저축(Savings)이 필요하다." 지적 활동과 다양한 경험은 뇌의 연결망을 복잡하게 만들어, 노화나 질병으로 인한 뇌 손상에도 일상 기능을 유지하는 '회복 탄력성'을 제공한다.
-
-## 📖 구조화된 지식 (Synthesized Content)
-- **Neural Redundancy (신경 중복성)**:
-    - 하나의 정보를 처리하는 경로가 여러 개일 때, 일부 경로가 파괴되어도 대체 경로를 통해 기능을 수행할 수 있는 능력.
-- **Enriched Environment**:
-    - 끊임없이 배우는 환경(책 읽기, 악기 배우기, 코딩 등)에 노출될수록 뇌의 예비능은 기하급수적으로 쌓인다.
-- **Active Lifestyle Impact**:
-    - 높은 교육 수준과 사회적 활동은 치매 증상의 발현을 몇 년씩 늦출 수 있는 강력한 방어막이다.
-
-## ⚠️ 모순 및 업데이트 (RL Update)
-- 인지 예비능이 무한한 것은 아니다. 어느 시점(Threshold)을 넘기면 손상이 급격히 표출될 수 있다. 따라서 '쌓는 것'만큼이나 '뇌를 혹사하지 않는 것'이 중요하다.
-
-## 🔗 지식 연결 (Graph)
-- Related: [[BDNF]] , [[Cognitive-Neuroscience-of-Flow]]
-- Foundation: [[Complex Systemic Modeling Protocols]]
diff --git a/AI/Cognitive Training Software (eg Aim Lab_KovaaKs).md b/AI/Cognitive Training Software (eg Aim Lab_KovaaKs).md
deleted file mode 100644
index 89eb66e5..00000000
--- a/AI/Cognitive Training Software (eg Aim Lab_KovaaKs).md	
+++ /dev/null
@@ -1,28 +0,0 @@
----
-id: P-REINFORCE-AI-AIMTRAIN
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.94
-tags: [Aim Lab, KovaaKs, Cognitive Training, Performance]
-last_reinforced: 2026-04-20
----
-
-# [[Cognitive-Training-Software]] (에임 및 인지 훈련 소프트웨어)
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 에임 훈련은 단순히 '마우스를 잘 흔드는 법'을 배우는 것이 아니라, 뇌의 시각 반응-근육 협응-판단 프로세스를 수만 번의 반복으로 최적화하는 '뉴로 머슬(Neuro-muscle) 프로그래밍'이다.
-
-## 📖 구조화된 지식 (Synthesized Content)
-- **Flick vs Tracking Training**:
-    - **Flick**: 특정 위치로 즉각적으로 조준을 옮기는 폭발적 인지 능력.
-    - **Tracking**: 움직이는 대상을 일정하게 따라가는 지속적 집중력과 미세 근육 제어.
-- **Micro-Metric Feedback**:
-    - 반응 속도(Reaction Time), 정확도(Accuracy), 조준의 흔들림(Shake) 등을 밀리초(ms) 단위로 측정하여 사용자의 약점(Weak point)을 데이터로 시각화한다.
-- **Skill Transferability**:
-    - 가상 환경에서의 훈련이 실제 게임(Valorant, Apex 등)의 성과로 전이되는 메커니즘은 '일관된 감도(Sensitivity)'와 '공포 반응 억제'에 기인한다.
-
-## ⚠️ 모순 및 업데이트 (RL Update)
-- 과도한 에임 훈련은 손목 부상(Carpal Tunnel)을 유발할 수 있으며, 실제 게임에서의 지형지물 활용이나 전략적 판단력(Game Sense)을 간과하게 만들 수 있다. 도구는 보조수단일 뿐, 실전 감각과의 균형이 필수적이다.
-
-## 🔗 지식 연결 (Graph)
-- Related: [[Burnout-Prevention-in-Professional-Gaming]] , [[Biomechanics-of-Injury]]
-- Analysis: [[Clinical-Kinesiology-Assessment]]
diff --git a/AI/Cognitive-Evaluation-Theory.md b/AI/Cognitive-Evaluation-Theory.md
deleted file mode 100644
index 316957cc..00000000
--- a/AI/Cognitive-Evaluation-Theory.md
+++ /dev/null
@@ -1,27 +0,0 @@
----
-id: P-REINFORCE-SCI-COGEVAL
-category: "[[10_Wiki/💡 Topics/Science]]"
-confidence_score: 0.97
-tags: [Cognitive Evaluation Theory, Motivation, Autonomy, Psychology]
-last_reinforced: 2026-04-20
----
-
-# [[Cognitive-Evaluation-Theory]] (인지 평가 이론)
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> "보상이 때로는 열정을 죽인다." 인간은 스스로 결정하고 유능하다고 느낄 때 가장 강력한 내적 동기를 발휘한다.
-
-## 📖 구조화된 지식 (Synthesized Content)
-- **Autonomy (자율성)**:
-    - 외부의 강요가 아니라 스스로의 선택에 의해 행동한다고 느낄 때 동기가 유발된다. (예: 게임에서의 자유로운 퀘스트 선택).
-- **Competence (유능성)**:
-    - 자신의 능력이 과제에 적합하거나 성장하고 있다고 느낄 때 재미와 보람을 느낀다. (예: 레벨업 시스템, 랭크 시스템).
-- **Extrinsic vs Intrinsic Motivation**:
-    - 금전적 보상 같은 외적 동기가 너무 크면, 즐거워서 하던 일(내적 동기)의 가치가 훼손되는 '과잉 정당화 효과(Over-justification effect)'가 발생할 수 있다.
-
-## ⚠️ 모순 및 업데이트 (RL Update)
-- 게임 기획 시 단순히 '데일리 보상'만 뿌리는 것은 위험하다. 사용자가 보상 때문에 숙제처럼 게임을 하게 만들지 말고, 자신의 실력이 늘어가는 과정 자체를 즐기게 하는 '마스터리의 경험'을 설계해야 한다.
-
-## 🔗 지식 연결 (Graph)
-- Related: [[Game Design Theory]] , [[Behavioral-Economics]]
-- Foundation: [[Cognitive-Biases]]
diff --git a/AI/Cognitive-Therapy-in-CBT.md b/AI/Cognitive-Therapy-in-CBT.md
deleted file mode 100644
index c3873db8..00000000
--- a/AI/Cognitive-Therapy-in-CBT.md
+++ /dev/null
@@ -1,27 +0,0 @@
----
-id: P-REINFORCE-SCI-CBT
-category: "[[10_Wiki/💡 Topics/Science]]"
-confidence_score: 0.96
-tags: [CBT, Cognitive Therapy, Psychology, Mental Health]
-last_reinforced: 2026-04-20
----
-
-# [[Cognitive-Therapy-in-CBT]] (인지 행동 치료 CBT)
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> "상황이 변하지 않아도, 상황을 바라보는 '나의 생각'이 변하면 감정과 행동이 변한다."
-
-## 📖 구조화된 지식 (Synthesized Content)
-- **Automatic Thoughts (자동적 사고)**:
-    - 어떤 상황을 마주했을 때 나도 모르게 떠오르는 즉각적인 생각들. (예: "실수했어, 나는 끝이야").
-- **Cognitive Distortions (인지적 왜곡)**:
-    - 흑백 논리, 과도한 일반화, 파국화 등 사실을 왜곡해서 받아들이는 뇌의 습관적 오류.
-- **Core Beliefs (핵심 신념)**:
-    - 인생 전반에 걸쳐 형성된 자신과 세상에 대한 근본적인 믿음. CBT는 이 핵심 신념을 탐색하고 건강하게 재구조화하는 것을 목표로 한다.
-
-## ⚠️ 모순 및 업데이트 (RL Update)
-- 최근에는 AI 챗봇이 CBT 기법을 활용하여 사용자의 우울감을 관리하고 멘탈 헬스를 보조하는 기술이 상용화되고 있다. 하지만 전문적인 심리 상담사의 공감과 개입을 완전히 대체하기에는 아직 윤리적, 감정적 한계가 존재한다.
-
-## 🔗 지식 연결 (Graph)
-- Related: [[Cognitive-Biases]] , [[Burnout-Prevention-in-Professional-Gaming]]
-- Foundation: [[Information Theory]]
diff --git a/AI/Collective-Intelligence.md b/AI/Collective-Intelligence.md
deleted file mode 100644
index e20106f7..00000000
--- a/AI/Collective-Intelligence.md
+++ /dev/null
@@ -1,27 +0,0 @@
----
-id: P-REINFORCE-AI-COLLECT-INT
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.98
-tags: [Collective Intelligence, Swarm Intelligence, Cooperation, AI]
-last_reinforced: 2026-04-20
----
-
-# [[Collective-Intelligence]] (집단 지능)
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> "전체는 부분의 합보다 똑똑하다." 개미 한 마리는 단순하지만 개미집은 정교한 것처럼, 수많은 개체의 협력이 만들어내는 창발적 지능이다.
-
-## 📖 구조화된 지식 (Synthesized Content)
-- **Swarm Intelligence**:
-    - 중앙 통제 없이 개체들 간의 로컬 상호작용만으로 복잡한 문제를 해결하는 능력. (예: 조류의 비행 군무, 슬라임 몰드의 최단 경로 찾기).
-- **Wisdom of Crowds**:
-    - 독립적이고 다양한 의견을 가진 집단이 투표나 시장 원리를 통해 내놓는 결론이 전문가 한 명의 결론보다 정확할 수 있음을 보여주는 현상.
-- **Multi-Agent Systems (MAS)**:
-    - AI 분야에서 서로 다른 전문성을 가진 에이전트들이 협력하여 하나의 큰 미션을 완수하도록 설계하는 시스템 설계 방식.
-
-## ⚠️ 모순 및 업데이트 (RL Update)
-- 집단 지능은 '집단 사고(Groupthink)'라는 함정에 빠질 수 있다. 다양성이 결여되고 한 목소리만 내게 되면 집단 지능은 순식간에 **'집단 우매함'**으로 전략하며 버블과 대량 학살 같은 비극을 초래하기도 한다.
-
-## 🔗 지식 연결 (Graph)
-- Related: [[Distributed-Systems-Engineering]] , [[Combinatorial-Optimization]]
-- Foundation: [[Complexity-Theory]]
diff --git a/AI/Combinatorial Game Theory.md b/AI/Combinatorial Game Theory.md
deleted file mode 100644
index 6fe4c17d..00000000
--- a/AI/Combinatorial Game Theory.md	
+++ /dev/null
@@ -1,27 +0,0 @@
----
-id: P-REINFORCE-AI-CGT
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.99
-tags: [Game Theory, Combinatorial, Logic, Math, Strategy]
-last_reinforced: 2026-04-20
----
-
-# [[Combinatorial-Game-Theory]] (조합론적 게임 이론 CGT)
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 우연도 숨겨진 정보도 없는 '완전 정보 게임'에서, 수학적으로 필승 전략(Winning Strategy)이 반드시 존재함을 증명하고 찾아내는 지적 유희다.
-
-## 📖 구조화된 지식 (Synthesized Content)
-- **Perfect Information Games**:
-    - 체스, 바둑, 님(Nim) 게임처럼 모든 정보가 공개되어 있고 주사위 같은 확률 요소가 없는 게임.
-- **Game Tree Search**:
-    - 모든 가능한 수의 경로를 트리 구조로 나타내고, 리프 노드(결과)에서부터 위로 거슬러 올라가며 최선의 수를 찾는 방식.
-- **Normal Play Convention**:
-    - "마지막 수를 두는 사람이 이긴다"는 규칙 하의 전략 분석. 게임을 숫자(Value)로 치환하여 복잡한 게임을 더 단순한 게임의 합으로 분해한다.
-
-## ⚠️ 모순 및 업데이트 (RL Update)
-- 바둑처럼 경우의 수가 우주 원자 수보다 많은 경우, 고전적인 CGT만으로는 해결이 불가능하다. 이때 알파고처럼 딥러닝과 몬테카를로 트리 탐색(MCTS)을 결합하여 '근사적 필승 전략'을 찾는 방식으로 현대적 진화가 일어났다.
-
-## 🔗 지식 연결 (Graph)
-- Related: [[AlphaGo (Monte Carlo Tree Search + RL)]] , [[Reinforcement Learning]]
-- Foundation: [[Computational Thinking]]
diff --git a/AI/Combinatorial-Optimization.md b/AI/Combinatorial-Optimization.md
deleted file mode 100644
index 76141c97..00000000
--- a/AI/Combinatorial-Optimization.md
+++ /dev/null
@@ -1,28 +0,0 @@
----
-id: P-REINFORCE-AI-COMBO-OPT
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.99
-tags: [Optimization, Combinatorial, NP-Hard, Algorithm]
-last_reinforced: 2026-04-20
----
-
-# [[Combinatorial-Optimization]] (조합 최적화)
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 무한에 가까운 선택지 속에서 '가장 싸거나', '가장 빠르거나', '가장 효율적인' 단 하나의 조합을 찾아내는 공학의 극한이다.
-
-## 📖 구조화된 지식 (Synthesized Content)
-- **NP-Hard Problems**:
-    - **외판원 문제 (TSP)**: 모든 도시를 한 번씩 방문하고 돌아오는 최단 경로 찾기.
-    - **배낭 문제 (Knapsack)**: 무게 제한 내에 가치가 최대가 되도록 짐 싸기.
-- **Heuristics & Meta-heuristics**:
-    - 최적해를 찾는 것이 불가능에 가까울 때, '적당히 좋은 해'를 빠르게 찾는 기법. (예: 유전 알고리즘, 담금질 기법(Simulated Annealing)).
-- **Integer Programming**:
-    - 변수가 정수여야 하는 제약 조건 하에서 최적의 해를 구하는 수학적 기법. 물류 최적화, 스케줄링 등에 필수적이다.
-
-## ⚠️ 모순 및 업데이트 (RL Update)
-- 최근에는 강화학습 에이전트가 조합 최적화 문제를 스스로 학습하여 푸는 연구가 활발하다. 특히 칩 설계(Chip Layout)나 데이터 센터 에너지 최적화 등에서 AI가 인간 설계자를 뛰어넘는 성과를 내고 있다.
-
-## 🔗 지식 연결 (Graph)
-- Related: [[Distributed-Systems-Engineering]] , [[Reinforcement Learning]]
-- Foundation: [[Computational Thinking]]
diff --git a/AI/CompCert-C-Compiler.md b/AI/CompCert-C-Compiler.md
deleted file mode 100644
index 8472b0e9..00000000
--- a/AI/CompCert-C-Compiler.md
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-4D22EB
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - CompCert-C-Compiler"
----
-
-# [[CompCert-C-Compiler]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** AI 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/CompCert-C-Compiler.md]]
----
diff --git a/AI/Complexity Theory.md b/AI/Complexity Theory.md
deleted file mode 100644
index aec28e98..00000000
--- a/AI/Complexity Theory.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-C7076A
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Complexity Theory"
----
-
-# [[Complexity Theory]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** AI 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Complexity Theory.md]]
----
diff --git a/AI/Computational Creativity.md b/AI/Computational Creativity.md
deleted file mode 100644
index 51340817..00000000
--- a/AI/Computational Creativity.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-E2FD01
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Computational Creativity"
----
-
-# [[Computational Creativity]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** AI 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Computational Creativity.md]]
----
diff --git a/AI/Computational Neuroscience of Reinforcement Learning.md b/AI/Computational Neuroscience of Reinforcement Learning.md
deleted file mode 100644
index d2f398e0..00000000
--- a/AI/Computational Neuroscience of Reinforcement Learning.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-457C50
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Computational Neuroscience of Reinforcement Learning"
----
-
-# [[Computational Neuroscience of Reinforcement Learning]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** AI 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Computational Neuroscience of Reinforcement Learning.md]]
----
diff --git a/AI/Computational-Creativity.md b/AI/Computational-Creativity.md
deleted file mode 100644
index 427780d3..00000000
--- a/AI/Computational-Creativity.md
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-90667E
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Computational-Creativity"
----
-
-# [[Computational-Creativity]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** AI 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Computational-Creativity.md]]
----
diff --git a/AI/Computer Vision.md b/AI/Computer Vision.md
deleted file mode 100644
index 980f2547..00000000
--- a/AI/Computer Vision.md	
+++ /dev/null
@@ -1,27 +0,0 @@
----
-id: P-REINFORCE-AI-CV
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.99
-tags: [Computer Vision, Deep Learning, Image Processing, Object Detection]
-last_reinforced: 2026-04-20
----
-
-# [[Computer-Vision]] (컴퓨터 비전)
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> "기계에게 눈을 부여하는 기술." 픽셀 데이터에서 패턴을 찾아내고, 그것이 '고양이'인지 '보행자'인지, 아니면 '암세포'인지 해석하는 AI의 시각 시스템이다.
-
-## 📖 구조화된 지식 (Synthesized Content)
-- **Image Recognition & Classification**:
-    - 사진을 보고 무엇인지 레이블링하는 기초 단계. CNN(Convolutional Neural Networks)의 등장으로 혁명적인 변화가 일어났다.
-- **Object Detection & Segmentation**:
-    - 화면 안의 사물 위치를 박스로 표시(Detection)하거나, 픽셀 단위로 경계를 칠하는(Segmentation) 정밀 작업. 자율주행의 핵심이다.
-- **Vision Transformers (ViT)**:
-    - 최근 NLP에서 쓰이는 'Attention' 기법을 이미지 처리에 도입하여, 기존 CNN의 한계를 넘어서는 성능을 보여주고 있다.
-
-## ⚠️ 모순 및 업데이트 (RL Update)
-- 컴퓨터 비전은 빛의 조건, 가림(Occlusion), 앵글의 변화에 여전히 취약한 면이 있다. 이를 극복하기 위해 다각도 카메라와 라이다(LiDAR) 데이터를 합치는 '센서 퓨전(Sensor Fusion)' 기술이 활발히 연구되고 있다.
-
-## 🔗 지식 연결 (Graph)
-- Related: [[Autonomous-Vehicle-Path-Planning]] , [[Robotic Manipulation]]
-- Foundation: [[Information Theory]]
diff --git a/AI/Computer-Aided-Design (CAD).md b/AI/Computer-Aided-Design (CAD).md
deleted file mode 100644
index e4ef2ac1..00000000
--- a/AI/Computer-Aided-Design (CAD).md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-518851
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Computer-Aided-Design (CAD)"
----
-
-# [[Computer-Aided-Design (CAD)]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** AI 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Computer-Aided-Design (CAD).md]]
----
diff --git a/AI/Computer_Vision.md b/AI/Computer_Vision.md
deleted file mode 100644
index 503fe54e..00000000
--- a/AI/Computer_Vision.md
+++ /dev/null
@@ -1,29 +0,0 @@
----
-id: P-REINFORCE-AI-001
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.97
-tags: [ai, computer-vision, cnn, transformer]
-last_reinforced: 2026-04-20
-github_commit: "batch-reinforce-03"
----
-
-# [[Computer Vision]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 디지털 이미지와 비디오에서 고차원적인 의미를 추출하여 기계가 세상을 '보고' '이해하게' 만드는 AI의 감각 기관.
-
-## 📖 구조화된 지식 (Synthesized Content)
-- **추출된 패턴:** 이미지 픽셀에서 특징(Feature)을 추출하고 이를 계층적으로 구조화하여 객체를 인식하는 비전 처리 패턴.
-- **세부 내용:**
-    - CNN(합성곱 신경망)에서 ViT(비전 트랜스포머)로의 아키텍처 진화.
-    - 이미지 분류, 객체 탐지, 세그멘테이션 등 핵심 태스크 Taxonomy 정의.
-    - 실시간 객체 추적 및 공간 이해를 위한 딥러닝 기법 통합.
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 기하학적 매칭 중심의 전통적 CV에서 데이터 기반의 신경망 학습 모델로 패러다임 완전 전환.
-- **정책 변화:** 기술적 정확도(w1)와 윤리적 프라이버시 보호의 가중치 균형 조절.
-
-## 🔗 지식 연결 (Graph)
-- **Parent:** [[10_Wiki/💡 Topics/AI]]
-- **Related:** [[CV_Synthesis]], [[Object-Detection]], [[CNN]]
-- **Raw Source:** [[00_Raw/2026-04-20/Computer Vision.md]]
diff --git a/AI/Concept Drift (개념 드리프트).md b/AI/Concept Drift (개념 드리프트).md
deleted file mode 100644
index ecddf505..00000000
--- a/AI/Concept Drift (개념 드리프트).md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-63C90D
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Concept Drift (개념 드리프트)"
----
-
-# [[Concept Drift (개념 드리프트)]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** AI 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Concept Drift (개념 드리프트).md]]
----
diff --git a/AI/Concept Mapping.md b/AI/Concept Mapping.md
deleted file mode 100644
index 5f2289eb..00000000
--- a/AI/Concept Mapping.md	
+++ /dev/null
@@ -1,27 +0,0 @@
----
-id: P-REINFORCE-AI-CONCMAP
-category: "[[10_Wiki/💡 Topics/Science]]"
-confidence_score: 0.96
-tags: [Concept Mapping, Learning Strategy, Metacognition, Education]
-last_reinforced: 2026-04-20
----
-
-# [[Concept-Mapping]] (개념 지도 제작)
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> "지식의 지도를 그려라." 파편화된 정보를 선과 화살표로 연결하여, 복잡한 개념들 사이의 인과 관계와 상부 구조를 한눈에 파악하는 학습의 시각화 전략이다.
-
-## 📖 구조화된 지식 (Synthesized Content)
-- **Hierarchical Structure**:
-    - 가장 포괄적인 주제를 상단(Root)에 두고, 하부로 갈수록 세부적인 개념이 연결되는 트리 또는 네트워크 구조.
-- **Cross-Links**:
-    - 서로 다른 영역에 있는 개념들을 연결함으로써 뜻밖의 통찰(Insight)을 얻게 해주는 가장 중요한 기능 중 하나.
-- **Cognitive Load Reduction**:
-    - 머릿속에서 어지럽게 뒤섞인 정보를 종이 위에 모델링함으로써 실제 사고하는 뇌의 부하를 줄여준다.
-
-## ⚠️ 모순 및 업데이트 (RL Update)
-- 개념 지도를 그리는 것 자체가 '목적'이 되면 시간 낭비가 될 수 있다(예쁜 맵 그리기 함정). 핵심은 맵을 완성하는 것이 아니라, 연결 고리를 고민하는 과정 그 자체다. 현대에는 Obsidian의 Graph View처럼 자동화된 맵 도구가 보조 수단으로 각광받고 있다.
-
-## 🔗 지식 연결 (Graph)
-- Related: [[Cognitive Psychology]] , [[Information Theory]]
-- Application: [[Complex Systemic Modeling Protocols]]
diff --git a/AI/Concurrent Programming.md b/AI/Concurrent Programming.md
deleted file mode 100644
index c2dd1796..00000000
--- a/AI/Concurrent Programming.md	
+++ /dev/null
@@ -1,28 +0,0 @@
----
-id: P-REINFORCE-AI-CONCUR
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.98
-tags: [Concurrent Programming, Multi-threading, Parallelism, Async]
-last_reinforced: 2026-04-20
----
-
-# [[Concurrent-Programming]] (동시성 프로그래밍)
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> "함께 달리는 기술." 여러 작업이 하나의 자원을 두고 싸우지 않게 조율하며, 한 번에 많은 일을 처리하는 오케스트레이션이다.
-
-## 📖 구조화된 지식 (Synthesized Content)
-- **Concurrecy vs Parallelism**:
-    - **Concurrency**: 논리적으로 여러 작업이 동시에 진행되는 것(Context Switch).
-    - **Parallelism**: 물리적으로 여러 CPU에서 작업이 동시에 돌아가는 것.
-- **Race Condition & Deadlock**:
-    - 자원을 두고 경쟁할 때 데이터가 꼬이거나(Race), 서로 기다리느라 멈춰버리는(Deadlock) 현상. 이를 해결하기 위해 Mutex, Semaphore, Actor model 등이 쓰인다.
-- **Asynchronous I/O**:
-    - 네트워크 요청처럼 오래 걸리는 일을 던져두고 다음 일을 처리하다가, 완료되면 알림을 받는 방식. (JS의 Event Loop가 대표적).
-
-## ⚠️ 모순 및 업데이트 (RL Update)
-- 동시성은 '공짜'가 아니다. 스레드나 프로세스를 전환하는 오버헤드가 더 클 수도 있다. 최근에는 Coroutine(Go, Rust)이나 가상 스레드(Java) 같이 아주 가벼운 단위의 동시성 모델이 주류로 자리 잡았다.
-
-## 🔗 지식 연결 (Graph)
-- Related: [[Distributed-Systems-Engineering]] , [[B-Tree]]
-- Foundation: [[Clean-Architecture-Implementation]]
diff --git a/AI/Conditioning and Learning (   ).md b/AI/Conditioning and Learning (   ).md
deleted file mode 100644
index 01a73c58..00000000
--- a/AI/Conditioning and Learning (   ).md	
+++ /dev/null
@@ -1,27 +0,0 @@
----
-id: P-REINFORCE-SCI-CONDITIONING
-category: "[[10_Wiki/💡 Topics/Science]]"
-confidence_score: 0.97
-tags: [Conditioning, Behavioral Science, Learning, Psychology]
-last_reinforced: 2026-04-20
----
-
-# [[Conditioning-and-Learning]] (조건 형성과 학습)
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> "행동은 보상의 결과물이다." 자극과 반응이 결합하여 습관이 되고, 보상의 타이밍에 따라 행동이 강화되거나 사라지는 메커니즘이다.
-
-## 📖 구조화된 지식 (Synthesized Content)
-- **Classical Conditioning (고전적 조건 형성)**:
-    - 비자발적 반사 반응 학습. 파블로프의 개 실험처럼 중립 자극이 무조건 자극과 결합하여 반응을 이끌어내는 방식.
-- **Operant Conditioning (조작적 조건 형성)**:
-    - 자발적 행동 학습. 행동의 결과가 보상(강화)이면 반복하고, 처벌이면 멈추는 방식. 스키너의 실험이 대표적이다.
-- **Variable Reward Schedule**:
-    - 보상을 가끔씩 예측 불가능하게 줄 때 행동이 가장 강력하게 유지된다(도박, 가챠 게임의 원리).
-
-## ⚠️ 모순 및 업데이트 (RL Update)
-- 인간은 단순히 보상에만 따라 움직이는 존재가 아니다(행동주의의 한계). 사회적 학습(관찰 학습)과 내면의 필터링이 작용한다. AI 분야의 강화학습(RL)은 이 조작적 조건 형성을 수학적으로 모델링하여 기계가 스스로 전략을 찾게 만든다.
-
-## 🔗 지식 연결 (Graph)
-- Related: [[Behavioral-Economics]] , [[Cognitive Evaluation Theory]]
-- Foundation: [[Reinforcement Learning]]
diff --git a/AI/Connect AI 기술 문서 및 사용 설명서.md b/AI/Connect AI 기술 문서 및 사용 설명서.md
deleted file mode 100644
index bf563d14..00000000
--- a/AI/Connect AI 기술 문서 및 사용 설명서.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-D1D238
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Connect AI 기술 문서 및 사용 설명서"
----
-
-# [[Connect AI 기술 문서 및 사용 설명서]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** AI 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Connect AI 기술 문서 및 사용 설명서.md]]
----
diff --git a/AI/Connect AI 시스템 아키텍처 및 데이터 흐름 분석.md b/AI/Connect AI 시스템 아키텍처 및 데이터 흐름 분석.md
deleted file mode 100644
index 612aad98..00000000
--- a/AI/Connect AI 시스템 아키텍처 및 데이터 흐름 분석.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-3841AD
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Connect AI 시스템 아키텍처 및 데이터 흐름 분석"
----
-
-# [[Connect AI 시스템 아키텍처 및 데이터 흐름 분석]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** AI 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Connect AI 시스템 아키텍처 및 데이터 흐름 분석.md]]
----
diff --git a/AI/Constitutional AI (헌법 AI).md b/AI/Constitutional AI (헌법 AI).md
deleted file mode 100644
index 39f11a2d..00000000
--- a/AI/Constitutional AI (헌법 AI).md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-938CE2
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Constitutional AI (헌법 AI)"
----
-
-# [[Constitutional AI (헌법 AI)]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** AI 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Constitutional AI (헌법 AI).md]]
----
diff --git a/AI/Constraint Satisfaction Problems (CSP).md b/AI/Constraint Satisfaction Problems (CSP).md
deleted file mode 100644
index 99a95409..00000000
--- a/AI/Constraint Satisfaction Problems (CSP).md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-075C49
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Constraint Satisfaction Problems (CSP)"
----
-
-# [[Constraint Satisfaction Problems (CSP)]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** AI 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Constraint Satisfaction Problems (CSP).md]]
----
diff --git a/AI/Constraint-Satisfaction-Problems.md b/AI/Constraint-Satisfaction-Problems.md
deleted file mode 100644
index 98fd2db3..00000000
--- a/AI/Constraint-Satisfaction-Problems.md
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-BE1BD5
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Constraint-Satisfaction-Problems"
----
-
-# [[Constraint-Satisfaction-Problems]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** AI 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Constraint-Satisfaction-Problems.md]]
----
diff --git a/AI/Continuous-Discovery.md b/AI/Continuous-Discovery.md
deleted file mode 100644
index d38db15f..00000000
--- a/AI/Continuous-Discovery.md
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-8E53F2
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Continuous-Discovery"
----
-
-# [[Continuous-Discovery]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** AI 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Continuous-Discovery.md]]
----
diff --git a/AI/Control Systems Engineering.md b/AI/Control Systems Engineering.md
deleted file mode 100644
index f2ac1e18..00000000
--- a/AI/Control Systems Engineering.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-5DA236
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Control Systems Engineering"
----
-
-# [[Control Systems Engineering]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** AI 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Control Systems Engineering.md]]
----
diff --git a/AI/Control-Theory.md b/AI/Control-Theory.md
deleted file mode 100644
index e8118f80..00000000
--- a/AI/Control-Theory.md
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-35251E
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Control-Theory"
----
-
-# [[Control-Theory]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** AI 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Control-Theory.md]]
----
diff --git a/AI/Conways On Numbers and Games.md b/AI/Conways On Numbers and Games.md
deleted file mode 100644
index 3e6033d6..00000000
--- a/AI/Conways On Numbers and Games.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-6026CC
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Conways On Numbers and Games"
----
-
-# [[Conways On Numbers and Games]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** AI 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Conway's On Numbers and Games.md]]
----
diff --git a/AI/Corgea.md b/AI/Corgea.md
deleted file mode 100644
index a059f4d2..00000000
--- a/AI/Corgea.md
+++ /dev/null
@@ -1,34 +0,0 @@
----
-id: P-REINFORCE-AUTO-DA5E03
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Corgea"
----
-
-# [[Corgea]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> Corgea는 대형 언어 모델(LLM)을 사후 스캔 분류가 아닌 핵심 스캐닝 엔진의 일부로 직접 활용하는 AI 네이티브 정적 애플리케이션 보안 테스트(SAST) 플랫폼입니다 [1]. 패턴 기반 스캐너가 놓치기 쉬운 복잡한 비즈니스 로직 결함을 깊이 있게 이해하고, 5% 미만의 낮은 오탐지율(False Positive rate)을 달성하여 기존 SAST 도구의 노이즈 문제를 해결합니다 [1-4]. 20개 이상의 언어를 지원하며, 검증된 AI 자동 수정(Auto-fix) 기능을 개발자의 작업 흐름(IDE 및 PR) 내에 직접 제공하는 것이 특징입니다 [2, 3].
-
-## 📖 구조화된 지식 (Synthesized Content)
-- **AI 네이티브 탐지 및 문맥 이해**: Corgea는 LLM을 스캐닝 과정에 활용하여 코드의 문맥과 의도를 파악합니다. 이를 통해 단순한 패턴 매칭만으로는 찾기 힘든 비즈니스 로직 취약점(예: 손상된 인증 시스템 등)을 탐지할 수 있습니다 [3, 5]. 이러한 접근 방식은 오탐지율을 5% 미만으로 크게 낮추는 데 기여합니다 [2, 4].
-- **PolicyIQ를 통한 맞춤형 문맥화**: 팀이 자연어를 사용하여 비즈니스 및 환경적 맥락을 제공할 수 있도록 하는 PolicyIQ 기능을 지원합니다 [3]. 스캐너는 이 컨텍스트를 활용하여 탐지 정확도를 개선하고 보다 적절한 수정안을 생성합니다 [3].
-- **도달 가능성 분석(Reachability Analysis)**: SAST 도달 가능성 분석을 수행하여 엔드포인트를 확인하고, 취약한 함수로 이어지는 콜 그래프(Call graph)를 생성하여 해당 취약점이 실제로 도달하여 악용될 수 있는지를 판별합니다 [3].
-- **워크플로우 통합 및 자동 수정**: Corgea는 IDE 및 Pull Request(PR) 단계에서 AI가 생성하고 검증한 수정안을 제공하여, 개발자가 평소 작업하는 흐름 내에서 직접 문제를 해결할 수 있도록 돕습니다 [2, 3]. 독립적인 Latio.tech 보고서에서 시중 최고의 자동 수정 도구로 평가받은 바 있습니다 [3].
-- **잠재적 한계점**: 시장 진입이 비교적 최근에 이루어졌기 때문에 Latio.tech 보고서 외에는 독립적인 벤치마킹 데이터가 아직 부족하다는 점이 한계로 꼽힙니다 [6]. 또한, AI를 통해 오탐지를 크게 줄이기는 하지만 완벽하게 제거할 수는 없으며, 기존의 확고한 레거시 벤더들에 비해 기업 내 도입 설득이 더 어려울 수 있습니다 [6].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** AI 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[SAST]], [[LLM]], [[PolicyIQ]], [[Reachability Analysis]]
-- **Projects/Contexts:** [[Latio.tech Report]], [[Best SAST Tools in 2026]]
-- **Contradictions/Notes:** 독립적인 평가(Latio.tech)에서 최고의 자동 수정 도구로 극찬을 받았으나, 신생 플랫폼인 탓에 다양한 객관적 벤치마킹 자료가 아직 부족하다는 점이 동시에 지적되고 있습니다 [3, 6].
-
----
-*Last updated: 2026-04-18*
-- Raw Source: [[00_Raw/2026-04-20/Corgea.md]]
----
diff --git a/AI/Corporate-LMS-Training.md b/AI/Corporate-LMS-Training.md
deleted file mode 100644
index a3555e87..00000000
--- a/AI/Corporate-LMS-Training.md
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-51DD02
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Corporate-LMS-Training"
----
-
-# [[Corporate-LMS-Training]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** AI 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Corporate-LMS-Training.md]]
----
diff --git a/AI/Creativity Research.md b/AI/Creativity Research.md
deleted file mode 100644
index 64a5f756..00000000
--- a/AI/Creativity Research.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-3C4B46
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Creativity Research"
----
-
-# [[Creativity Research]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** AI 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Creativity Research.md]]
----
diff --git a/AI/Credit Assignment Problem.md b/AI/Credit Assignment Problem.md
deleted file mode 100644
index c05018ab..00000000
--- a/AI/Credit Assignment Problem.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-55E155
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Credit Assignment Problem"
----
-
-# [[Credit Assignment Problem]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** AI 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Credit Assignment Problem.md]]
----
diff --git a/AI/Custom-ESLint-Rules-Development.md b/AI/Custom-ESLint-Rules-Development.md
deleted file mode 100644
index 7efab2e7..00000000
--- a/AI/Custom-ESLint-Rules-Development.md
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-4AB505
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Custom-ESLint-Rules-Development"
----
-
-# [[Custom-ESLint-Rules-Development]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** AI 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Custom-ESLint-Rules-Development.md]]
----
diff --git a/AI/Customer-Journey-Mapping.md b/AI/Customer-Journey-Mapping.md
deleted file mode 100644
index 97721ea2..00000000
--- a/AI/Customer-Journey-Mapping.md
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-47D82D
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Customer-Journey-Mapping"
----
-
-# [[Customer-Journey-Mapping]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** AI 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Customer-Journey-Mapping.md]]
----
diff --git a/AI/Cybernetics.md b/AI/Cybernetics.md
deleted file mode 100644
index 735ee1a0..00000000
--- a/AI/Cybernetics.md
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-F6EC43
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Cybernetics"
----
-
-# [[Cybernetics]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** AI 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Cybernetics.md]]
----
diff --git a/AI/DPO (Direct Preference Optimization).md b/AI/DPO (Direct Preference Optimization).md
deleted file mode 100644
index 457257da..00000000
--- a/AI/DPO (Direct Preference Optimization).md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-D43239
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - DPO (Direct Preference Optimization)"
----
-
-# [[DPO (Direct Preference Optimization)]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** AI 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/DPO (Direct Preference Optimization).md]]
----
diff --git a/AI/DQN.md b/AI/DQN.md
deleted file mode 100644
index b8376c88..00000000
--- a/AI/DQN.md
+++ /dev/null
@@ -1,27 +0,0 @@
----
-id: P-REINFORCE-AI-DQN
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.99
-tags: [DQN, Deep Q-Networks, Reinforcement Learning, AI]
-last_reinforced: 2026-04-20
----
-
-# [[DQN]] (심층 Q-네트워크)
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> "딥러닝이 강화학습의 눈이 되었다." 테이블 방식의 한계를 넘어, 복잡한 화면 이미지(픽셀)를 직접 보고 최적의 행동을 결정하게 만든 AI 역사의 한 획이다.
-
-## 📖 구조화된 지식 (Synthesized Content)
-- **Experience Replay**:
-    - 과거의 경험을 메모리 버퍼에 저장했다가 무작위로 꺼내 학습함으로써, 데이터 간의 상관관계를 끊고 학습 안전성을 높인다.
-- **Fixed Q-Targets**:
-    - 학습 대상(Target)이 계속 변해서 생기는 불안정성을 막기 위해, 별도의 타겟 네트워크를 두고 일정한 주기마다 업데이트한다.
-- **Application**:
-    - 아타리(Atari) 게임 정복부터 로봇 제어, 주식 트레이딩 등 불확실한 환경의 의사결정에 널리 쓰인다.
-
-## ⚠️ 모순 및 업데이트 (RL Update)
-- DQN은 행동 공간(Action Space)이 이산적(Discrete)일 때만 유리하다. 연속적인 움직임이 필요한 자율주행이나 로봇 팔 제어에는 `DDPG`나 `PPO` 같은 후속 알고리즘이 더 많이 사용된다.
-
-## 🔗 지식 연결 (Graph)
-- Related: [[Reinforcement Learning]] , [[Bellman-Equation]]
-- Foundation: [[Information Theory]]
diff --git a/AI/Data Cleaning Algorithms.md b/AI/Data Cleaning Algorithms.md
deleted file mode 100644
index f354b2c6..00000000
--- a/AI/Data Cleaning Algorithms.md	
+++ /dev/null
@@ -1,27 +0,0 @@
----
-id: P-REINFORCE-AI-DATA-CLEAN
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.97
-tags: [Data Cleaning, Machine Learning, Data Quality, Preprocessing]
-last_reinforced: 2026-04-20
----
-
-# [[Data-Cleaning-Algorithms]] (데이터 정제 알고리즘)
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> "품질이 성능을 이긴다." 모델의 구조를 바꾸는 것보다 데이터 속의 노이즈와 중복을 제거하는 것이 AI 성능 향상에 훨씬 더 드라마틱한 결과(Data-centric AI)를 준다.
-
-## 📖 구조화된 지식 (Synthesized Content)
-- **Outlier Detection**:
-    - 통계적 기법(Z-score, IQR) 또는 머신러닝(Isolation Forest)을 통해 정상 범위를 벗어난 이상치를 탐지하고 처리한다.
-- **Handling Missing Values**:
-    - 비어있는 값을 평균값으로 채울지, 아니면 예측 모델을 통해 추론해서 채울지(Imputation) 전략을 수립한다.
-- **Normalization & Scaling**:
-    - 데이터의 수치가 너무 제각각이면 학습이 불안정해지므로, 일정한 범위(0~1 등)로 맞추는 스케일링 과정이 필수적이다.
-
-## ⚠️ 모순 및 업데이트 (RL Update)
-- 무조건적인 데이터 삭제는 '중요한 예외 상황(Edge case)' 정보까지 날려버릴 수 있다. 특히 사고 예방이 중요한 보안이나 자율주행 분야에서는 이상 데이터를 버리기보다, 그것이 왜 발생했는지 분석하는 프로세스가 병행되어야 한다.
-
-## 🔗 지식 연결 (Graph)
-- Related: [[Information Theory]] , [[Reliability_Safety_First]]
-- Foundation: [[Computational Thinking]]
diff --git a/AI/Data Distillation (데이터 증류).md b/AI/Data Distillation (데이터 증류).md
deleted file mode 100644
index 1ea9bbb8..00000000
--- a/AI/Data Distillation (데이터 증류).md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-2EC269
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Data Distillation (데이터 증류)"
----
-
-# [[Data Distillation (데이터 증류)]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** AI 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Data Distillation (데이터 증류).md]]
----
diff --git a/AI/Data-Augmentation-for-Medical-Imaging.md b/AI/Data-Augmentation-for-Medical-Imaging.md
deleted file mode 100644
index 91aecaf2..00000000
--- a/AI/Data-Augmentation-for-Medical-Imaging.md
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-258909
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Data-Augmentation-for-Medical-Imaging"
----
-
-# [[Data-Augmentation-for-Medical-Imaging]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** AI 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Data-Augmentation-for-Medical-Imaging.md]]
----
diff --git a/AI/Data-Science-in-UX.md b/AI/Data-Science-in-UX.md
deleted file mode 100644
index af17dfec..00000000
--- a/AI/Data-Science-in-UX.md
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-235CC7
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Data-Science-in-UX"
----
-
-# [[Data-Science-in-UX]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** AI 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Data-Science-in-UX.md]]
----
diff --git a/AI/Data-Transfer-Object-Design.md b/AI/Data-Transfer-Object-Design.md
deleted file mode 100644
index c4ae231a..00000000
--- a/AI/Data-Transfer-Object-Design.md
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-21E554
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Data-Transfer-Object-Design"
----
-
-# [[Data-Transfer-Object-Design]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** AI 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Data-Transfer-Object-Design.md]]
----
diff --git a/AI/Dead Space (Series).md b/AI/Dead Space (Series).md
deleted file mode 100644
index afd55743..00000000
--- a/AI/Dead Space (Series).md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-989941
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Dead Space (Series)"
----
-
-# [[Dead Space (Series)]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** AI 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Dead Space (Series).md]]
----
diff --git a/AI/Deceptive Alignment (기만적 정렬).md b/AI/Deceptive Alignment (기만적 정렬).md
deleted file mode 100644
index edc172c7..00000000
--- a/AI/Deceptive Alignment (기만적 정렬).md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-EB9E46
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Deceptive Alignment (기만적 정렬)"
----
-
-# [[Deceptive Alignment (기만적 정렬)]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** AI 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Deceptive Alignment (기만적 정렬).md]]
----
diff --git a/AI/Decision Theory.md b/AI/Decision Theory.md
deleted file mode 100644
index 32c46eac..00000000
--- a/AI/Decision Theory.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-B8B3FB
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Decision Theory"
----
-
-# [[Decision Theory]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** AI 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Decision Theory.md]]
----
diff --git a/AI/Declaration Files (dts).md b/AI/Declaration Files (dts).md
deleted file mode 100644
index dd1ea1d1..00000000
--- a/AI/Declaration Files (dts).md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-D2F3A4
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Declaration Files (dts)"
----
-
-# [[Declaration Files (dts)]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** AI 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Declaration Files (.d.ts).md]]
----
diff --git a/AI/Declaration-Files.md b/AI/Declaration-Files.md
deleted file mode 100644
index 1b7e9c35..00000000
--- a/AI/Declaration-Files.md
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-2150D3
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Declaration-Files"
----
-
-# [[Declaration-Files]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** AI 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Declaration-Files.md]]
----
diff --git a/AI/Deep Q-Networks (DQN).md b/AI/Deep Q-Networks (DQN).md
deleted file mode 100644
index a054c788..00000000
--- a/AI/Deep Q-Networks (DQN).md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-704527
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Deep Q-Networks (DQN)"
----
-
-# [[Deep Q-Networks (DQN)]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** AI 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Deep Q-Networks (DQN).md]]
----
diff --git a/AI/Deep-Convolutional-GANs.md b/AI/Deep-Convolutional-GANs.md
deleted file mode 100644
index 3113d5e5..00000000
--- a/AI/Deep-Convolutional-GANs.md
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-84A34B
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Deep-Convolutional-GANs"
----
-
-# [[Deep-Convolutional-GANs]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** AI 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Deep-Convolutional-GANs.md]]
----
diff --git a/AI/DeepCode AI.md b/AI/DeepCode AI.md
deleted file mode 100644
index 76aa8cda..00000000
--- a/AI/DeepCode AI.md	
+++ /dev/null
@@ -1,37 +0,0 @@
----
-id: P-REINFORCE-AUTO-A75F29
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - DeepCode AI"
----
-
-# [[DeepCode AI]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> DeepCode AI는 수백만 개의 오픈소스 코드 커밋을 학습하여 취약점을 탐지하고 수정 사항을 제안하는 머신러닝(ML) 기반의 목적 맞춤형 보안 AI 엔진입니다 [1-3]. 2020년 보안 기업 Snyk이 스위스 AI 스타트업인 DeepCode를 인수하여 자사의 정적 애플리케이션 보안 테스트(SAST) 도구인 Snyk Code의 핵심 인텔리전스 계층으로 통합했습니다 [1, 2, 4]. 이 엔진은 단순한 규칙 기반 패턴 매칭을 넘어 기호적 AI(Symbolic AI)와 신경망을 결합하여 코드의 의미(semantics)와 데이터 흐름을 깊이 있게 이해합니다 [4, 5].
-
-## 📖 구조화된 지식 (Synthesized Content)
-- **엔진의 작동 방식 및 분석 기법**
-  DeepCode AI 엔진은 코드를 텍스트로 생성하는 일반적인 대형 언어 모델(LLM) 방식이 아니라, 기호적 추론(symbolic reasoning)과 신경망을 결합해 코드의 의미론적 표현(semantic representation)을 구축합니다 [1, 5]. 2,500만 개 이상의 데이터 흐름 사례와 19개 이상의 프로그래밍 언어를 지원하며, 파일 간 데이터 흐름(interfile dataflow analysis)을 추적하여 여러 파일이나 모듈의 경계를 넘나드는 복잡한 취약점을 파악합니다 [4, 6, 7]. 고정된 패턴이 아닌 코드의 의도를 이해하므로 대규모 변종 탐지(variant detection)에 매우 뛰어납니다 [6, 8].
-
-- **딥코드 AI 픽스(DeepCode AI Fix)를 통한 자동 수정**
-  이 엔진의 가장 눈에 띄는 기능 중 하나는 취약점 발견 시 해결 방안을 제안하는 'DeepCode AI Fix'입니다 [9]. 일반적인 LLM 생성 수정안과 달리, DeepCode AI Fix는 실제 오픈소스 프로젝트에서 개발자들이 해당 취약점을 해결했던 검증된 패턴들을 특별히 학습했습니다 [9]. 이를 통해 가짜 정보(Hallucination) 위험을 줄이고 보다 신뢰할 수 있으며 문맥에 알맞은 수정안을 제시합니다 [7, 9].
-
-- **낮은 오탐률(False Positive Rate)과 개발자 친화성**
-  수많은 실제 오픈소스 커밋의 취약점 패턴과 그에 대응하는 수정 데이터를 학습했기 때문에, 단순히 의심스러워 보이는 코드와 실제로 악용 가능한 코드를 정확히 식별합니다 [3, 10]. 그 결과, 기존의 전통적인 규칙 기반 SAST 도구들을 사용할 때 흔히 겪는 수많은 오탐(False Positives)과 노이즈를 크게 줄일 수 있습니다 [5, 10]. 또한 스캔 속도가 매우 빨라 IDE 내에서 개발 워크플로우를 방해하지 않고 실시간으로 실행될 수 있습니다 [2].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** AI 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[Snyk Code]], [[SAST (Static Application Security Testing)]], [[Symbolic AI]], [[Machine Learning]]
-- **Projects/Contexts:** [[Snyk 플랫폼을 통한 IDE 및 CI/CD 파이프라인 통합 보안 검토 프로젝트]]
-- **Contradictions/Notes:** DeepCode AI가 자동으로 취약점을 감지하고 수정안을 제시하지만, 일부 결과는 여전히 수동 검증이 필요하며 분석의 깊이는 언어에 따라 다를 수 있다는 점이 지적됩니다 [6]. 
-
----
-*Last updated: 2026-04-19*
-- Raw Source: [[00_Raw/2026-04-20/DeepCode AI.md]]
----
diff --git a/AI/Deepfake-Detection-Research.md b/AI/Deepfake-Detection-Research.md
deleted file mode 100644
index e8ec59a9..00000000
--- a/AI/Deepfake-Detection-Research.md
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-DD74C9
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Deepfake-Detection-Research"
----
-
-# [[Deepfake-Detection-Research]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** AI 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Deepfake-Detection-Research.md]]
----
diff --git a/AI/Default Mode Network (DMN).md b/AI/Default Mode Network (DMN).md
deleted file mode 100644
index 8221a382..00000000
--- a/AI/Default Mode Network (DMN).md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-B914F1
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Default Mode Network (DMN)"
----
-
-# [[Default Mode Network (DMN)]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** AI 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Default Mode Network (DMN).md]]
----
diff --git a/AI/DefinitelyTyped.md b/AI/DefinitelyTyped.md
deleted file mode 100644
index eb6ff2f5..00000000
--- a/AI/DefinitelyTyped.md
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-4BB90C
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - DefinitelyTyped"
----
-
-# [[DefinitelyTyped]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** AI 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/DefinitelyTyped.md]]
----
diff --git a/AI/Degrees-of-Freedom.md b/AI/Degrees-of-Freedom.md
deleted file mode 100644
index 01cf2a91..00000000
--- a/AI/Degrees-of-Freedom.md
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-B68509
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Degrees-of-Freedom"
----
-
-# [[Degrees-of-Freedom]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** AI 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Degrees-of-Freedom.md]]
----
diff --git a/AI/Deliberate-Practice.md b/AI/Deliberate-Practice.md
deleted file mode 100644
index f0850acd..00000000
--- a/AI/Deliberate-Practice.md
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-EE5EE5
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Deliberate-Practice"
----
-
-# [[Deliberate-Practice]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** AI 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Deliberate-Practice.md]]
----
diff --git a/AI/Denavit-Hartenberg-Parameters.md b/AI/Denavit-Hartenberg-Parameters.md
deleted file mode 100644
index 78b6dc26..00000000
--- a/AI/Denavit-Hartenberg-Parameters.md
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-B3CEC1
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Denavit-Hartenberg-Parameters"
----
-
-# [[Denavit-Hartenberg-Parameters]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** AI 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Denavit-Hartenberg-Parameters.md]]
----
diff --git a/AI/Dense vs Sparse Neural Networks.md b/AI/Dense vs Sparse Neural Networks.md
deleted file mode 100644
index d86eac42..00000000
--- a/AI/Dense vs Sparse Neural Networks.md	
+++ /dev/null
@@ -1,27 +0,0 @@
----
-id: P-REINFORCE-AI-DENSE-SPARSE
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.98
-tags: [Neural Networks, Dense, Sparse, MoE, Efficiency]
-last_reinforced: 2026-04-20
----
-
-# [[Dense-vs-Sparse-Neural-Networks]] (밀집 vs 희소 신경망)
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> "모두를 깨울 것인가, 필요한 놈만 깨울 것인가." 뇌가 모든 뉴런을 동시에 쓰지 않듯이, AI도 필요한 부위만 활성화하여 거대한 지능을 가볍게 유지하는 기술이다.
-
-## 📖 구조화된 지식 (Synthesized Content)
-- **Dense Neural Networks**:
-    - 모든 입력과 출력이 촘촘하게 연결된 구조. 계산량은 많지만 구현이 쉽고 소규모 모델에 적합하다.
-- **Sparse Neural Networks (Pruning)**:
-    - 중요하지 않은 가중치(영향력이 적은 연결)를 0으로 만들어 연산량을 줄이는 기법.
-- **Mixture of Experts (MoE)**:
-    - 최근 GPT-4 등 거대 모델의 핵심 기술. 모델 안에 수십 명의 '전문가'를 두고, 질문의 성격에 맞는 전문가만 골라 활성화하여 성능은 높이고 연산 비용은 낮춘다.
-
-## ⚠️ 모순 및 업데이트 (RL Update)
-- 희소 행렬 연산은 하드웨어(GPU) 가속기에서 효율적으로 처리하기가 까다로운 면이 있다. 따라서 소프트웨어적인 '희소화'와 하드웨어의 '가속 효율' 사이의 균형점을 찾는 것이 현대 AI 공학의 최대 화두다.
-
-## 🔗 지식 연결 (Graph)
-- Related: [[Differentiable-Programming]] , [[Deep-Reinforcement-Learning]]
-- Foundation: [[Information Theory]]
diff --git a/AI/Dependency-Graph-Analysis.md b/AI/Dependency-Graph-Analysis.md
deleted file mode 100644
index c19c1a08..00000000
--- a/AI/Dependency-Graph-Analysis.md
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-597DF8
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Dependency-Graph-Analysis"
----
-
-# [[Dependency-Graph-Analysis]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** AI 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Dependency-Graph-Analysis.md]]
----
diff --git a/AI/Dependency-Injection.md b/AI/Dependency-Injection.md
deleted file mode 100644
index 019b1bd6..00000000
--- a/AI/Dependency-Injection.md
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-D3C51B
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Dependency-Injection"
----
-
-# [[Dependency-Injection]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** AI 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Dependency-Injection.md]]
----
diff --git a/AI/Dependency-Inversion-Principle.md b/AI/Dependency-Inversion-Principle.md
deleted file mode 100644
index a340143b..00000000
--- a/AI/Dependency-Inversion-Principle.md
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-4C0291
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Dependency-Inversion-Principle"
----
-
-# [[Dependency-Inversion-Principle]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** AI 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Dependency-Inversion-Principle.md]]
----
diff --git a/AI/DevOps-and-UX-Convergence.md b/AI/DevOps-and-UX-Convergence.md
deleted file mode 100644
index e7575bec..00000000
--- a/AI/DevOps-and-UX-Convergence.md
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-9EB8EA
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - DevOps-and-UX-Convergence"
----
-
-# [[DevOps-and-UX-Convergence]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** AI 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/DevOps-and-UX-Convergence.md]]
----
diff --git a/AI/DevSecOps.md b/AI/DevSecOps.md
deleted file mode 100644
index 421de756..00000000
--- a/AI/DevSecOps.md
+++ /dev/null
@@ -1,32 +0,0 @@
----
-id: P-REINFORCE-AUTO-89C666
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - DevSecOps"
----
-
-# [[DevSecOps]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> DevSecOps는 소프트웨어 개발 수명 주기(SDLC) 전반에 걸쳐 보안을 통합하는 방법론입니다 [1]. 핵심적인 접근 방식은 보안 점검을 개발 초기 단계로 앞당기는 '시프트 레프트(Shift-left)' 전략입니다 [2]. 기존 개발 워크플로우를 늦추지 않으면서도 CI/CD 파이프라인이나 개발 환경(IDE)에 코드 검사 도구 및 AI 자동화를 도입하여 보안 위협을 조기에 탐지하고 대응하는 것을 목표로 합니다 [2, 3].
-
-## 📖 구조화된 지식 (Synthesized Content)
-* **시프트 레프트(Shift-Left) 전략:** DevSecOps의 핵심은 개발 프로세스의 가장 이른 시점에 취약점을 발견하고 조치하는 '시프트 레프트'에 있습니다 [2]. 지속적 통합 및 지속적 배포(CI/CD) 파이프라인이나 개발자의 IDE 환경에 정적 애플리케이션 보안 테스트(SAST) 도구와 코드 체커를 구현하는 것이 DevSecOps의 가장 널리 인정받는 모범 사례입니다 [2, 4].
-* **AI 및 자동화의 결합:** 최신 DevSecOps 환경은 AI와 자동화를 도입하여 복잡한 보안 과제를 해결하고 있습니다 [3]. AI 기반 보안 분석 도구는 코드의 문맥과 데이터 흐름을 추적하여 패턴 기반 도구가 놓치기 쉬운 취약점을 찾아내며, 자동 수정(Auto-fix) 기능을 통해 스캔부터 수정까지의 주기를 최적화하고 시간을 절약하도록 돕습니다 [5-7].
-* **원활한 워크플로우 통합:** 성공적인 DevSecOps를 구축하려면 개발자의 일상적인 작업 환경에 보안 도구가 매끄럽게 통합되어야 합니다 [4]. 실시간 또는 풀 리퀘스트(PR) 단계에서 소스 코드를 분석하여 코딩 실수, 아키텍처 결함, 보안 취약점이 운영 환경에 배포되기 전에 조기 피드백을 제공합니다 [2, 8].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** AI 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[SDLC]], [[Shift-Left]], [[SAST]], [[CI/CD]]
-- **Projects/Contexts:** [[Snyk]], [[GitHub Advanced Security]], [[SonarQube]] 등 코드 품질 및 보안 분석 도구들을 개발 워크플로우(IDE, 리포지토리, CI/CD)에 연동하여 실시간 보안 피드백을 제공하는 방식으로 구성됩니다 [1, 2, 9].
-- **Contradictions/Notes:** DevSecOps 워크플로우에서 자동화된 검사는 필수적이지만, AI나 스캐너 도구는 비즈니스 로직이나 의도를 파악하지 못하는 맹점(Context Blindness)을 가지고 있습니다 [10]. 따라서 자동화 도구가 일상적이고 반복적인 취약점을 빠르게 잡아내고, 인간 리뷰어가 아키텍처와 복잡한 보안 컨텍스트에 집중하는 '하이브리드(Hybrid)' 접근법이 가장 이상적인 모델로 권장됩니다 [11, 12].
-
----
-*Last updated: 2026-04-18*
-- Raw Source: [[00_Raw/2026-04-20/DevSecOps.md]]
----
diff --git a/AI/Differentiable Programming.md b/AI/Differentiable Programming.md
deleted file mode 100644
index 1aa32506..00000000
--- a/AI/Differentiable Programming.md	
+++ /dev/null
@@ -1,27 +0,0 @@
----
-id: P-REINFORCE-AI-DIF-PROG
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.98
-tags: [Differentiable Programming, AI, JAX, PyTorch, Optimization]
-last_reinforced: 2026-04-20
----
-
-# [[Differentiable-Programming]] (미분 가능한 프로그래밍)
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> "프로그램 자체가 학습의 대상이다." 조건문, 루프, 라이브러리 함수까지 모두 조절 가능한 파라미터로 보고, 경사 하강법(Gradient Descent)으로 프로그램을 최적화하는 혁명적 패러다임이다.
-
-## 📖 구조화된 지식 (Synthesized Content)
-- **End-to-End Optimization**:
-    - 입력부터 출력까지 모든 연산 과정이 연결되어 있어, 오차(Loss)가 발생하면 프로그램 전체로 미분 신호(Gradient)를 전파해 스스로 수정하게 한다.
-- **Software 2.0**:
-    - 안드레이 카파시가 제안한 개념. 사람이 일일이 로직을 짜는 Software 1.0에서, 데이터로부터 로직(신경망 가중치)이 생성되는 Software 2.0으로의 전환.
-- **Frameworks**:
-    - `JAX`, `PyTorch` 등 자동 미분(Auto-grad) 기능을 가진 프레임워크들이 이 패러다임의 중추 역할을 한다.
-
-## ⚠️ 모순 및 업데이트 (RL Update)
-- 모든 로직을 미분 가능하게 만들기는 어렵다(특히 불연속적인 이산적 선택). 이를 해결하기 위해 `Reinforce` 기법이나 `Gumbel-Softmax` 같은 트릭을 써서 확률적으로 미분 가능하게 연결하는 연구가 활발하다.
-
-## 🔗 지식 연결 (Graph)
-- Related: [[Deep-Reinforcement-Learning]] , [[Complexity-Theory]]
-- Foundation: [[Computational Theory & Math/Information Theory]]
diff --git a/AI/Diffusion-Models.md b/AI/Diffusion-Models.md
deleted file mode 100644
index b39bd05c..00000000
--- a/AI/Diffusion-Models.md
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-7C0B06
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Diffusion-Models"
----
-
-# [[Diffusion-Models]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** AI 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Diffusion-Models.md]]
----
diff --git a/AI/Digital Intellectual Property Rights.md b/AI/Digital Intellectual Property Rights.md
deleted file mode 100644
index 813bb828..00000000
--- a/AI/Digital Intellectual Property Rights.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-384956
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Digital Intellectual Property Rights"
----
-
-# [[Digital Intellectual Property Rights]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** AI 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Digital Intellectual Property Rights.md]]
----
diff --git a/AI/Digital Thread Integration.md b/AI/Digital Thread Integration.md
deleted file mode 100644
index e2eb8ea3..00000000
--- a/AI/Digital Thread Integration.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-A9FF14
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Digital Thread Integration"
----
-
-# [[Digital Thread Integration]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** AI 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Digital Thread Integration.md]]
----
diff --git a/AI/Digital-Twin-Technology.md b/AI/Digital-Twin-Technology.md
deleted file mode 100644
index da61cc32..00000000
--- a/AI/Digital-Twin-Technology.md
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-D08215
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Digital-Twin-Technology"
----
-
-# [[Digital-Twin-Technology]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** AI 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Digital-Twin-Technology.md]]
----
diff --git a/AI/Dijkstra's Algorithm.md b/AI/Dijkstra's Algorithm.md
deleted file mode 100644
index 2e3f4e4c..00000000
--- a/AI/Dijkstra's Algorithm.md	
+++ /dev/null
@@ -1,27 +0,0 @@
----
-id: P-REINFORCE-AI-DIJKSTRA
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.99
-tags: [Dijkstra, Algorithm, Pathfinding, Graph Theory]
-last_reinforced: 2026-04-20
----
-
-# [[Dijkstra's-Algorithm]] (데이크스트라 알고리즘)
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> "욕심쟁이(Greedy)의 가장 똑똑한 길 찾기." 출발점에서 다른 모든 지점까지의 최단 거리를 가장 효율적으로 확정해 나가는 알고리즘의 고전이자 정석이다.
-
-## 📖 구조화된 지식 (Synthesized Content)
-- **Shortest Path Tree**:
-    - 방문하지 않은 지점 중 거리가 가장 짧은 지점을 먼저 방문함으로써, 한 번 확정된 거리는 다시 계산할 필요가 없게 만든다.
-- **Priority Queue Usage**:
-    - 우선순위 큐(힙)를 사용하여 다음에 방문할 지점을 빠르게 찾아냄으로써 시간 복잡도를 극적으로 최적화한다.
-- **Application**:
-    - 구글 지도, 게임 길찾기, 네트워크 라우팅(OSPF) 등 연결된 네트워크가 있는 모든 곳에 쓰인다.
-
-## ⚠️ 모순 및 업데이트 (RL Update)
-- 데이크스트라는 음수 가중치(음수의 거리 등)가 있는 환경에서는 작동하지 않는다(이땐 벨만-포드 필요). 또한, 거대한 맵에서는 탐색 범위가 너무 넓어지므로, 목표 지점 방향으로 먼저 탐색하는 지능을 더한 `A* (A-Star) 알고리즘`이 실무에서 더 선호된다.
-
-## 🔗 지식 연결 (Graph)
-- Related: [[Autonomous-Vehicle-Path-Planning]] , [[Combinatorial-Optimization]]
-- Foundation: [[Computational Theory & Math/Information Theory]]
diff --git a/AI/Diminishing Returns (한계 수익 체감).md b/AI/Diminishing Returns (한계 수익 체감).md
deleted file mode 100644
index 87b4d51f..00000000
--- a/AI/Diminishing Returns (한계 수익 체감).md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-26A63C
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Diminishing Returns (한계 수익 체감)"
----
-
-# [[Diminishing Returns (한계 수익 체감)]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** AI 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Diminishing Returns (한계 수익 체감).md]]
----
diff --git a/AI/Directed-Acyclic-Graph-Build-Systems.md b/AI/Directed-Acyclic-Graph-Build-Systems.md
deleted file mode 100644
index 32c53ced..00000000
--- a/AI/Directed-Acyclic-Graph-Build-Systems.md
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-B5202A
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Directed-Acyclic-Graph-Build-Systems"
----
-
-# [[Directed-Acyclic-Graph-Build-Systems]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** AI 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Directed-Acyclic-Graph-Build-Systems.md]]
----
diff --git a/AI/Directed-Acyclic-Graph-Dependency-Management.md b/AI/Directed-Acyclic-Graph-Dependency-Management.md
deleted file mode 100644
index bd4db462..00000000
--- a/AI/Directed-Acyclic-Graph-Dependency-Management.md
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-5577CF
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Directed-Acyclic-Graph-Dependency-Management"
----
-
-# [[Directed-Acyclic-Graph-Dependency-Management]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** AI 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Directed-Acyclic-Graph-Dependency-Management.md]]
----
diff --git a/AI/Discriminated-Unions-for-Error-Handling.md b/AI/Discriminated-Unions-for-Error-Handling.md
deleted file mode 100644
index 993d78da..00000000
--- a/AI/Discriminated-Unions-for-Error-Handling.md
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-F4914A
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Discriminated-Unions-for-Error-Handling"
----
-
-# [[Discriminated-Unions-for-Error-Handling]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** AI 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Discriminated-Unions-for-Error-Handling.md]]
----
diff --git a/AI/Discriminated-Unions-for-State-Modeling.md b/AI/Discriminated-Unions-for-State-Modeling.md
deleted file mode 100644
index df9e09d0..00000000
--- a/AI/Discriminated-Unions-for-State-Modeling.md
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-326E8C
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Discriminated-Unions-for-State-Modeling"
----
-
-# [[Discriminated-Unions-for-State-Modeling]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** AI 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Discriminated-Unions-for-State-Modeling.md]]
----
diff --git a/AI/Discriminated-Unions.md b/AI/Discriminated-Unions.md
deleted file mode 100644
index f75978cd..00000000
--- a/AI/Discriminated-Unions.md
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-1AAB27
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Discriminated-Unions"
----
-
-# [[Discriminated-Unions]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** AI 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Discriminated-Unions.md]]
----
diff --git a/AI/Dissipative Structures.md b/AI/Dissipative Structures.md
deleted file mode 100644
index c011afd1..00000000
--- a/AI/Dissipative Structures.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-25ABE0
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Dissipative Structures"
----
-
-# [[Dissipative Structures]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** AI 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Dissipative Structures.md]]
----
diff --git a/AI/Distributed Reinforcement Learning.md b/AI/Distributed Reinforcement Learning.md
deleted file mode 100644
index 637cf120..00000000
--- a/AI/Distributed Reinforcement Learning.md	
+++ /dev/null
@@ -1,27 +0,0 @@
----
-id: P-REINFORCE-AI-DIST-RL
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.98
-tags: [Distributed RL, Scalability, AI, Apex, Impala]
-last_reinforced: 2026-04-20
----
-
-# [[Distributed-Reinforcement-Learning]] (분산 강화학습)
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> "혼자 배우면 1년, 함께 배우면 1시간." 수많은 에이전트를 가상 환경에 풀어 동시에 경험을 쌓게 하고, 이를 하나의 뇌로 집약하는 초고속 학습 기술이다.
-
-## 📖 구조화된 지식 (Synthesized Content)
-- **Parallel Data Collection**:
-    - 수백~수천 개의 CPU/GPU 환경에서 독립적인 에이전트들이 데이터를 수집하여 중앙 서버로 전송한다.
-- **Asynchronous vs Synchronous**:
-    - 에이전트들끼리 속도를 맞출지(Sync), 아니면 각자 데이터가 생기는 대로 업데이트할지(Async)에 따른 아키텍처 차이(A3C, IMPALA 등).
-- **Efficiency Boost**:
-    - 탐색(Exploration)의 손실을 방지하고, 더 다양한 환경 시나리오를 짧은 시간 안에 학습할 수 있게 한다.
-
-## ⚠️ 모순 및 업데이트 (RL Update)
-- 분산 학습은 엄청난 컴퓨팅 자원을 소모한다. 최근에는 자원 효율성을 높이기 위해 '오프 폴리시(Off-policy)' 데이터를 더 효과적으로 재활용하는 `R2D2`나 `MuZero` 같은 알고리즘이 주목받고 있다.
-
-## 🔗 지식 연결 (Graph)
-- Related: [[DQN]] , [[Collective-Intelligence]]
-- Foundation: [[Distributed-Systems-Engineering]]
diff --git a/AI/Distributed-System-Type-Safety.md b/AI/Distributed-System-Type-Safety.md
deleted file mode 100644
index 4426efde..00000000
--- a/AI/Distributed-System-Type-Safety.md
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-1E4141
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Distributed-System-Type-Safety"
----
-
-# [[Distributed-System-Type-Safety]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** AI 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Distributed-System-Type-Safety.md]]
----
diff --git a/AI/Domain Objects.md b/AI/Domain Objects.md
deleted file mode 100644
index 13ed12cb..00000000
--- a/AI/Domain Objects.md	
+++ /dev/null
@@ -1,35 +0,0 @@
----
-id: P-REINFORCE-AUTO-17D3D3
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Domain Objects"
----
-
-# [[Domain Objects]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 도메인 객체(Domain Objects)는 비즈니스 개념을 표현하고 전사적인 비즈니스 규칙과 데이터 구조를 캡슐화하는 핵심 객체입니다 [1, 2]. 소프트웨어 아키텍처의 가장 중심부에 위치하며 프레임워크나 사용자 인터페이스(UI), 데이터베이스 등 외부 계층에 전혀 의존하지 않고 독립적으로 존재합니다 [1, 3]. 복잡한 비즈니스 로직을 명확하게 모델링하고 시스템의 근본적인 뼈대를 형성하는 데 필수적인 역할을 합니다 [1, 4].
-
-## 📖 구조화된 지식 (Synthesized Content)
-* **비즈니스 개념의 직접적 표현:** 
-  도메인 객체는 소프트웨어가 해결하고자 하는 비즈니스 개념 자체를 코드로 표현합니다 [2]. 예를 들어, 쇼핑 애플리케이션에서는 사용자 정보나 상품 정보를 나타내는 `Product` 클래스가 도메인 객체의 역할을 수행하게 됩니다 [2].
-* **클린 아키텍처(Clean Architecture)에서의 중심 역할:** 
-  클린 아키텍처에서 도메인 객체는 시스템의 심장부인 '엔티티(Entities)' 또는 '도메인 계층'에 위치합니다 [1, 3]. 이들은 다른 외부 에이전시나 프레임워크, UI의 변화로부터 완벽하게 격리되어 순수한 엔터프라이즈 비즈니스 규칙만을 포함합니다 [1, 3].
-* **도메인 주도 설계(DDD)와 애그리게이트(Aggregates):** 
-  도메인 주도 설계에서 도메인 객체들은 단일 단위로 취급될 수 있는 객체들의 무리인 '애그리게이트'로 묶이게 됩니다 [5]. 예를 들어 '주문(Order)'이라는 애그리게이트는 '주문 내역(OrderLineItem)'이라는 도메인 객체들을 포함할 수 있습니다 [5]. 이때 애그리게이트의 루트(root)는 클러스터 전체의 일관성을 보장하여 트랜잭션 관리를 단순하게 만들어 줍니다 [5].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** AI 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[Domain-Driven Design]], [[Clean Architecture]], [[Entities]], [[Aggregates]]
-- **Projects/Contexts:** [[쇼핑 애플리케이션 도메인 모델]]
-- **Contradictions/Notes:** 소스 내에서 도메인 객체에 대한 모순이나 상반된 주장은 존재하지 않으며, 일관되게 시스템의 핵심 비즈니스 로직을 캡슐화하고 외부 의존성으로부터 철저히 분리되어야 하는 대상으로 강조됩니다 [1-3].
-
----
-*Last updated: 2026-04-18*
-- Raw Source: [[00_Raw/2026-04-20/Domain Objects.md]]
----
diff --git a/AI/Domain-Driven Design (DDD) Type Safety.md b/AI/Domain-Driven Design (DDD) Type Safety.md
deleted file mode 100644
index 55d61020..00000000
--- a/AI/Domain-Driven Design (DDD) Type Safety.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-BE347F
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Domain-Driven Design (DDD) Type Safety"
----
-
-# [[Domain-Driven Design (DDD) Type Safety]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** AI 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Domain-Driven Design (DDD) Type Safety.md]]
----
diff --git a/AI/Domain-Driven Design (DDD) in TypeScript.md b/AI/Domain-Driven Design (DDD) in TypeScript.md
deleted file mode 100644
index f7641527..00000000
--- a/AI/Domain-Driven Design (DDD) in TypeScript.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-F89598
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Domain-Driven Design (DDD) in TypeScript"
----
-
-# [[Domain-Driven Design (DDD) in TypeScript]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** AI 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Domain-Driven Design (DDD) in TypeScript.md]]
----
diff --git a/AI/Domain-Driven-Design (DDD) in TypeScript.md b/AI/Domain-Driven-Design (DDD) in TypeScript.md
deleted file mode 100644
index ce74c7d6..00000000
--- a/AI/Domain-Driven-Design (DDD) in TypeScript.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-D7AB12
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Domain-Driven-Design (DDD) in TypeScript"
----
-
-# [[Domain-Driven-Design (DDD) in TypeScript]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** AI 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Domain-Driven-Design (DDD) in TypeScript.md]]
----
diff --git a/AI/Domain-Driven-Design (DDD).md b/AI/Domain-Driven-Design (DDD).md
deleted file mode 100644
index 8bef2790..00000000
--- a/AI/Domain-Driven-Design (DDD).md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-7AB40D
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Domain-Driven-Design (DDD)"
----
-
-# [[Domain-Driven-Design (DDD)]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** AI 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Domain-Driven-Design (DDD).md]]
----
diff --git a/AI/Domain-Driven-Design-(DDD)-in-TypeScript.md b/AI/Domain-Driven-Design-(DDD)-in-TypeScript.md
deleted file mode 100644
index aadbe9a8..00000000
--- a/AI/Domain-Driven-Design-(DDD)-in-TypeScript.md
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-13548A
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Domain-Driven-Design-(DDD)-in-TypeScript"
----
-
-# [[Domain-Driven-Design-(DDD)-in-TypeScript]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** AI 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Domain-Driven-Design-(DDD)-in-TypeScript.md]]
----
diff --git a/AI/Domain-Driven-Design-(DDD).md b/AI/Domain-Driven-Design-(DDD).md
deleted file mode 100644
index 7a59df16..00000000
--- a/AI/Domain-Driven-Design-(DDD).md
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-C360C0
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Domain-Driven-Design-(DDD)"
----
-
-# [[Domain-Driven-Design-(DDD)]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** AI 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Domain-Driven-Design-(DDD).md]]
----
diff --git a/AI/Domain-Driven-Design-Bounded-Context.md b/AI/Domain-Driven-Design-Bounded-Context.md
deleted file mode 100644
index 396e23d4..00000000
--- a/AI/Domain-Driven-Design-Bounded-Context.md
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-551739
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Domain-Driven-Design-Bounded-Context"
----
-
-# [[Domain-Driven-Design-Bounded-Context]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** AI 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Domain-Driven-Design-Bounded-Context.md]]
----
diff --git a/AI/Domain-Driven-Design-Interface-Modeling.md b/AI/Domain-Driven-Design-Interface-Modeling.md
deleted file mode 100644
index f16e4017..00000000
--- a/AI/Domain-Driven-Design-Interface-Modeling.md
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-BE83DE
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Domain-Driven-Design-Interface-Modeling"
----
-
-# [[Domain-Driven-Design-Interface-Modeling]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** AI 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Domain-Driven-Design-Interface-Modeling.md]]
----
diff --git a/AI/Domain-Driven-Design-in-TypeScript.md b/AI/Domain-Driven-Design-in-TypeScript.md
deleted file mode 100644
index cc2f20ca..00000000
--- a/AI/Domain-Driven-Design-in-TypeScript.md
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-21D02B
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Domain-Driven-Design-in-TypeScript"
----
-
-# [[Domain-Driven-Design-in-TypeScript]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** AI 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Domain-Driven-Design-in-TypeScript.md]]
----
diff --git a/AI/Domain-Driven-Design-with-TypeScript.md b/AI/Domain-Driven-Design-with-TypeScript.md
deleted file mode 100644
index 9de9cabf..00000000
--- a/AI/Domain-Driven-Design-with-TypeScript.md
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-7451F4
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Domain-Driven-Design-with-TypeScript"
----
-
-# [[Domain-Driven-Design-with-TypeScript]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** AI 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Domain-Driven-Design-with-TypeScript.md]]
----
diff --git a/AI/Domain-Driven-Design.md b/AI/Domain-Driven-Design.md
deleted file mode 100644
index 8dcd7d05..00000000
--- a/AI/Domain-Driven-Design.md
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-CD0693
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Domain-Driven-Design"
----
-
-# [[Domain-Driven-Design]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** AI 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Domain-Driven-Design.md]]
----
diff --git a/AI/Dopaminergic Reward System.md b/AI/Dopaminergic Reward System.md
deleted file mode 100644
index 0c1d78b6..00000000
--- a/AI/Dopaminergic Reward System.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-1CE0DE
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Dopaminergic Reward System"
----
-
-# [[Dopaminergic Reward System]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** AI 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Dopaminergic Reward System.md]]
----
diff --git a/AI/Dopaminergic Reward Systems.md b/AI/Dopaminergic Reward Systems.md
deleted file mode 100644
index f7d5dcaf..00000000
--- a/AI/Dopaminergic Reward Systems.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-73B204
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Dopaminergic Reward Systems"
----
-
-# [[Dopaminergic Reward Systems]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** AI 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Dopaminergic Reward Systems.md]]
----
diff --git a/AI/Drama Management Systems.md b/AI/Drama Management Systems.md
deleted file mode 100644
index e52f97df..00000000
--- a/AI/Drama Management Systems.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-893F79
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Drama Management Systems"
----
-
-# [[Drama Management Systems]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** AI 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Drama Management Systems.md]]
----
diff --git a/AI/Dynamic Difficulty Adjustment (DDA).md b/AI/Dynamic Difficulty Adjustment (DDA).md
deleted file mode 100644
index b0414b78..00000000
--- a/AI/Dynamic Difficulty Adjustment (DDA).md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-478A4A
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Dynamic Difficulty Adjustment (DDA)"
----
-
-# [[Dynamic Difficulty Adjustment (DDA)]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** AI 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Dynamic Difficulty Adjustment (DDA).md]]
----
diff --git a/AI/Dynamic Few-Shot (동적 퓨샷 선택 전략).md b/AI/Dynamic Few-Shot (동적 퓨샷 선택 전략).md
deleted file mode 100644
index b736565e..00000000
--- a/AI/Dynamic Few-Shot (동적 퓨샷 선택 전략).md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-6118B8
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Dynamic Few-Shot (동적 퓨샷 선택 전략)"
----
-
-# [[Dynamic Few-Shot (동적 퓨샷 선택 전략)]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** AI 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Dynamic Few-Shot (동적 퓨샷 선택 전략).md]]
----
diff --git a/AI/Dynamic-Environment-Handling.md b/AI/Dynamic-Environment-Handling.md
deleted file mode 100644
index 3ae20227..00000000
--- a/AI/Dynamic-Environment-Handling.md
+++ /dev/null
@@ -1,27 +0,0 @@
----
-id: P-REINFORCE-AI-DYNAMIC-ENV
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.96
-tags: [Dynamic Environment, Autonomous Driving, Adaptation, AI]
-last_reinforced: 2026-04-20
----
-
-# [[Dynamic-Environment-Handling]] (동적 환경 대응)
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> "세상은 멈춰 있지 않다." 비, 눈, 안개, 갑자기 뛰어드는 아이처럼 끊임없이 변하는 현실 세계의 변덕에 실시간으로 적응하는 AI의 회복 탄력성이다.
-
-## 📖 구조화된 지식 (Synthesized Content)
-- **Robust Perception**:
-    - 센서 노이즈나 기상 악화 상황에서도 사물을 정확히 인식하는 강건한 시각 시스템.
-- **Real-time Path Planning**:
-    - 장애물이 나타날 때마다 수 밀리초(ms) 이내에 새로운 안전 경로를 계산하는 기술.
-- **Domain Adaptation**:
-    - 시뮬레이션 환경(Sim)과 실제 도로 환경(Real)의 차이를 메꾸어, 가상에서 배운 지식을 현실에서도 유효하게 만드는 전이 학습 기법.
-
-## ⚠️ 모순 및 업데이트 (RL Update)
-- 모든 시나리오를 미리 학습시키는 것은 불가능하다. 최근에는 '세계 모델(World Model)'을 통해 AI가 물리 법칙을 이해하게 함으로써, 처음 보는 돌발 상황에서도 상식적인 수준의 대응을 하도록 유도하는 연구가 대세다.
-
-## 🔗 지식 연결 (Graph)
-- Related: [[Autonomous-Vehicle-Path-Planning]] , [[Reliability_Safety_First]]
-- Foundation: [[Computational Thinking]]
diff --git a/AI/E-commerce-Catalog-Management.md b/AI/E-commerce-Catalog-Management.md
deleted file mode 100644
index 312a7986..00000000
--- a/AI/E-commerce-Catalog-Management.md
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-D52EF5
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - E-commerce-Catalog-Management"
----
-
-# [[E-commerce-Catalog-Management]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** AI 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/E-commerce-Catalog-Management.md]]
----
diff --git a/AI/E-commerce-Optimization.md b/AI/E-commerce-Optimization.md
deleted file mode 100644
index d2917674..00000000
--- a/AI/E-commerce-Optimization.md
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-5FD532
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - E-commerce-Optimization"
----
-
-# [[E-commerce-Optimization]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** AI 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/E-commerce-Optimization.md]]
----
diff --git a/AI/ESLint-Static-Analysis.md b/AI/ESLint-Static-Analysis.md
deleted file mode 100644
index f8f6e462..00000000
--- a/AI/ESLint-Static-Analysis.md
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-2B78F8
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - ESLint-Static-Analysis"
----
-
-# [[ESLint-Static-Analysis]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** AI 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/ESLint-Static-Analysis.md]]
----
diff --git a/AI/EU-Web-Accessibility-Directive.md b/AI/EU-Web-Accessibility-Directive.md
deleted file mode 100644
index 01912af8..00000000
--- a/AI/EU-Web-Accessibility-Directive.md
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-94ECB4
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - EU-Web-Accessibility-Directive"
----
-
-# [[EU-Web-Accessibility-Directive]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** AI 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/EU-Web-Accessibility-Directive.md]]
----
diff --git a/AI/EVE Online (Spreadsheet Economy).md b/AI/EVE Online (Spreadsheet Economy).md
deleted file mode 100644
index 04580c58..00000000
--- a/AI/EVE Online (Spreadsheet Economy).md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-442180
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - EVE Online (Spreadsheet Economy)"
----
-
-# [[EVE Online (Spreadsheet Economy)]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** AI 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/EVE Online (Spreadsheet Economy).md]]
----
diff --git a/AI/Ecology and Ecosystem Modeling.md b/AI/Ecology and Ecosystem Modeling.md
deleted file mode 100644
index 4e2897eb..00000000
--- a/AI/Ecology and Ecosystem Modeling.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-ED335C
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Ecology and Ecosystem Modeling"
----
-
-# [[Ecology and Ecosystem Modeling]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** AI 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Ecology and Ecosystem Modeling.md]]
----
diff --git a/AI/Elite-Sport-Science-Protocols.md b/AI/Elite-Sport-Science-Protocols.md
deleted file mode 100644
index 43841ac5..00000000
--- a/AI/Elite-Sport-Science-Protocols.md
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-04186E
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Elite-Sport-Science-Protocols"
----
-
-# [[Elite-Sport-Science-Protocols]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** AI 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Elite-Sport-Science-Protocols.md]]
----
diff --git a/AI/Elite-Strength-and-Conditioning.md b/AI/Elite-Strength-and-Conditioning.md
deleted file mode 100644
index 435a0daa..00000000
--- a/AI/Elite-Strength-and-Conditioning.md
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-4094F7
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Elite-Strength-and-Conditioning"
----
-
-# [[Elite-Strength-and-Conditioning]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** AI 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Elite-Strength-and-Conditioning.md]]
----
diff --git a/AI/Embodied Cognition.md b/AI/Embodied Cognition.md
deleted file mode 100644
index 3fb2cd12..00000000
--- a/AI/Embodied Cognition.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-D43081
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Embodied Cognition"
----
-
-# [[Embodied Cognition]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** AI 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Embodied Cognition.md]]
----
diff --git a/AI/Emotionally Intelligent Tutoring Systems (EITS).md b/AI/Emotionally Intelligent Tutoring Systems (EITS).md
deleted file mode 100644
index f96c40e2..00000000
--- a/AI/Emotionally Intelligent Tutoring Systems (EITS).md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-A7735A
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Emotionally Intelligent Tutoring Systems (EITS)"
----
-
-# [[Emotionally Intelligent Tutoring Systems (EITS)]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** AI 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Emotionally Intelligent Tutoring Systems (EITS).md]]
----
diff --git a/AI/Encapsulation-and-Information-Hiding.md b/AI/Encapsulation-and-Information-Hiding.md
deleted file mode 100644
index 4472271c..00000000
--- a/AI/Encapsulation-and-Information-Hiding.md
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-3AFE91
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Encapsulation-and-Information-Hiding"
----
-
-# [[Encapsulation-and-Information-Hiding]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** AI 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Encapsulation-and-Information-Hiding.md]]
----
diff --git a/AI/Encapsulation-of-Domain-Invariants.md b/AI/Encapsulation-of-Domain-Invariants.md
deleted file mode 100644
index 8cebb644..00000000
--- a/AI/Encapsulation-of-Domain-Invariants.md
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-3F0BE1
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Encapsulation-of-Domain-Invariants"
----
-
-# [[Encapsulation-of-Domain-Invariants]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** AI 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Encapsulation-of-Domain-Invariants.md]]
----
diff --git a/AI/Encapsulation-via-Access-Modifiers.md b/AI/Encapsulation-via-Access-Modifiers.md
deleted file mode 100644
index 926aef5b..00000000
--- a/AI/Encapsulation-via-Access-Modifiers.md
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-E8605B
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Encapsulation-via-Access-Modifiers"
----
-
-# [[Encapsulation-via-Access-Modifiers]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** AI 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Encapsulation-via-Access-Modifiers.md]]
----
diff --git a/AI/Endurance-Athletics-Cognition.md b/AI/Endurance-Athletics-Cognition.md
deleted file mode 100644
index a4e3fa36..00000000
--- a/AI/Endurance-Athletics-Cognition.md
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-BC701A
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Endurance-Athletics-Cognition"
----
-
-# [[Endurance-Athletics-Cognition]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** AI 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Endurance-Athletics-Cognition.md]]
----
diff --git a/AI/Enterprise-Design-Systems.md b/AI/Enterprise-Design-Systems.md
deleted file mode 100644
index d6e7f7ba..00000000
--- a/AI/Enterprise-Design-Systems.md
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-84FEDE
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Enterprise-Design-Systems"
----
-
-# [[Enterprise-Design-Systems]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** AI 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Enterprise-Design-Systems.md]]
----
diff --git a/AI/Enterprise-Resource-Planning-Systems.md b/AI/Enterprise-Resource-Planning-Systems.md
deleted file mode 100644
index 276cee10..00000000
--- a/AI/Enterprise-Resource-Planning-Systems.md
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-DDC6E0
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Enterprise-Resource-Planning-Systems"
----
-
-# [[Enterprise-Resource-Planning-Systems]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** AI 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Enterprise-Resource-Planning-Systems.md]]
----
diff --git a/AI/Enterprise-Scale-Monorepo-Management.md b/AI/Enterprise-Scale-Monorepo-Management.md
deleted file mode 100644
index d3fec48f..00000000
--- a/AI/Enterprise-Scale-Monorepo-Management.md
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-372DAD
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Enterprise-Scale-Monorepo-Management"
----
-
-# [[Enterprise-Scale-Monorepo-Management]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** AI 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Enterprise-Scale-Monorepo-Management.md]]
----
diff --git a/AI/Enterprise-Software-Architecture.md b/AI/Enterprise-Software-Architecture.md
deleted file mode 100644
index 611813bf..00000000
--- a/AI/Enterprise-Software-Architecture.md
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-4727C5
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Enterprise-Software-Architecture"
----
-
-# [[Enterprise-Software-Architecture]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** AI 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Enterprise-Software-Architecture.md]]
----
diff --git a/AI/Enterprise-Software-Engineering.md b/AI/Enterprise-Software-Engineering.md
deleted file mode 100644
index c41814f1..00000000
--- a/AI/Enterprise-Software-Engineering.md
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-EA62A1
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Enterprise-Software-Engineering"
----
-
-# [[Enterprise-Software-Engineering]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** AI 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Enterprise-Software-Engineering.md]]
----
diff --git a/AI/Europeana.md b/AI/Europeana.md
deleted file mode 100644
index c1804dd8..00000000
--- a/AI/Europeana.md
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-683994
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Europeana"
----
-
-# [[Europeana]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** AI 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Europeana.md]]
----
diff --git a/AI/Evolutionary Biology.md b/AI/Evolutionary Biology.md
deleted file mode 100644
index 2b610815..00000000
--- a/AI/Evolutionary Biology.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-926B28
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Evolutionary Biology"
----
-
-# [[Evolutionary Biology]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** AI 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Evolutionary Biology.md]]
----
diff --git a/AI/Evolutionary Computation.md b/AI/Evolutionary Computation.md
deleted file mode 100644
index e066d475..00000000
--- a/AI/Evolutionary Computation.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-2D52C6
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Evolutionary Computation"
----
-
-# [[Evolutionary Computation]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** AI 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Evolutionary Computation.md]]
----
diff --git a/AI/Evolutionary-Biology.md b/AI/Evolutionary-Biology.md
deleted file mode 100644
index 1fa67ec4..00000000
--- a/AI/Evolutionary-Biology.md
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-29AB70
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Evolutionary-Biology"
----
-
-# [[Evolutionary-Biology]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** AI 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Evolutionary-Biology.md]]
----
diff --git a/AI/Evolutionary-Computation.md b/AI/Evolutionary-Computation.md
deleted file mode 100644
index 57ef5767..00000000
--- a/AI/Evolutionary-Computation.md
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-314A2B
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Evolutionary-Computation"
----
-
-# [[Evolutionary-Computation]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** AI 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Evolutionary-Computation.md]]
----
diff --git a/AI/Excess-Property-Checking.md b/AI/Excess-Property-Checking.md
deleted file mode 100644
index 56c9e1f6..00000000
--- a/AI/Excess-Property-Checking.md
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-E8C633
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Excess-Property-Checking"
----
-
-# [[Excess-Property-Checking]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** AI 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Excess-Property-Checking.md]]
----
diff --git a/AI/Executive Dysfunction.md b/AI/Executive Dysfunction.md
deleted file mode 100644
index 3e2be4d2..00000000
--- a/AI/Executive Dysfunction.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-DDD1CE
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Executive Dysfunction"
----
-
-# [[Executive Dysfunction]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** AI 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Executive Dysfunction.md]]
----
diff --git a/AI/Executive-Function-Deficit.md b/AI/Executive-Function-Deficit.md
deleted file mode 100644
index 690ac61d..00000000
--- a/AI/Executive-Function-Deficit.md
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-598E63
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Executive-Function-Deficit"
----
-
-# [[Executive-Function-Deficit]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** AI 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Executive-Function-Deficit.md]]
----
diff --git a/AI/Exercise-Physiology.md b/AI/Exercise-Physiology.md
deleted file mode 100644
index c50382a3..00000000
--- a/AI/Exercise-Physiology.md
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-415D41
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Exercise-Physiology"
----
-
-# [[Exercise-Physiology]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** AI 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Exercise-Physiology.md]]
----
diff --git a/AI/Exhaustiveness-Checking.md b/AI/Exhaustiveness-Checking.md
deleted file mode 100644
index 8ff2d694..00000000
--- a/AI/Exhaustiveness-Checking.md
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-D4B087
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Exhaustiveness-Checking"
----
-
-# [[Exhaustiveness-Checking]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** AI 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Exhaustiveness-Checking.md]]
----
diff --git a/AI/Expected Utility Theory.md b/AI/Expected Utility Theory.md
deleted file mode 100644
index fdb89c2d..00000000
--- a/AI/Expected Utility Theory.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-289250
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Expected Utility Theory"
----
-
-# [[Expected Utility Theory]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** AI 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Expected Utility Theory.md]]
----
diff --git a/AI/Expo 2025 Osaka.md b/AI/Expo 2025 Osaka.md
deleted file mode 100644
index c76162f2..00000000
--- a/AI/Expo 2025 Osaka.md	
+++ /dev/null
@@ -1,33 +0,0 @@
----
-id: P-REINFORCE-AUTO-AE03AD
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Expo 2025 Osaka"
----
-
-# [[Expo 2025 Osaka]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> Expo 2025 Osaka는 고성능 WebGPU 및 Three.js 기술을 활용한 최첨단 3D 인터랙티브 경험이 전시된 행사입니다 [1-3]. 이곳에서는 100만 개의 파티클을 활용한 유체 시뮬레이션 설치물이 대형 4K 디스플레이에서 눈에 띄는 지연 없이 실시간으로 구동되었습니다 [2, 3]. 이 엑스포는 기존 아키텍처에 비해 WebGPU가 가져온 컴퓨팅 성능의 막대한 향상을 실증하는 주요 무대가 되었습니다 [1, 3].
-
-## 📖 구조화된 지식 (Synthesized Content)
-- **고성능 기술 실증 사례:** Expo 2025 Osaka는 수많은 드로우 콜이나 연산 집약적인 효과가 필요한 환경에서 WebGPU가 제공하는 막대한 성능 향상을 실제 프로덕션 수준에서 입증한 주요 사례로 언급됩니다 [1].
-- **주요 전시물 (Waves of Connection / Hokusai installation):** 인터랙티브 크리에이티브 스튜디오인 Utsubo는 이 행사에서 "Hokusai installation" (또는 "Waves of Connection")이라는 설치 미술을 선보였습니다 [2, 3].
-- **기술적 성과:** 해당 설치물은 98인치 4K 디스플레이 상에서 100만 개(1M)의 파티클로 구성된 유체 시뮬레이션을 실시간으로 렌더링하는 데 성공했습니다 [2, 3]. 특히 눈에 띄는 지연(lag) 현상 없이 다수의 인원을 동시에 추적(multi-person body tracking)하는 고도의 기술적 성과를 달성했습니다 [3].
-- **정보의 한계:** 제공된 데이터는 WebGPU 성능 최적화를 설명하기 위한 특정 설치물 사례에만 집중되어 있어, 엑스포 행사의 전체 규모나 다른 목적 등에 대해서는 소스에 관련 정보가 부족합니다.
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** AI 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[WebGPU]], [[Three.js]], [[Particle System]]
-- **Projects/Contexts:** [[Utsubo]], [[Hokusai installation]], [[Waves of Connection]]
-- **Contradictions/Notes:** 주어진 소스는 엑스포 내 특정 디지털 설치물(Utsubo의 유체 시뮬레이션)에 대한 기술적 성과만을 다루고 있으며, 엑스포 행사 전반에 대한 내용은 소스에 관련 정보가 부족합니다.
-
----
-*Last updated: 2026-04-19*
-- Raw Source: [[00_Raw/2026-04-20/Expo 2025 Osaka.md]]
----
diff --git a/AI/Feature Clamping (피처 고정).md b/AI/Feature Clamping (피처 고정).md
deleted file mode 100644
index 870a0a55..00000000
--- a/AI/Feature Clamping (피처 고정).md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-E1B41C
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Feature Clamping (피처 고정)"
----
-
-# [[Feature Clamping (피처 고정)]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** AI 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Feature Clamping (피처 고정).md]]
----
diff --git a/AI/Feedback-Control-Systems.md b/AI/Feedback-Control-Systems.md
deleted file mode 100644
index 8ff06242..00000000
--- a/AI/Feedback-Control-Systems.md
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-B4B48F
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Feedback-Control-Systems"
----
-
-# [[Feedback-Control-Systems]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** AI 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Feedback-Control-Systems.md]]
----
diff --git a/AI/Finite-Element-Analysis.md b/AI/Finite-Element-Analysis.md
deleted file mode 100644
index 29ed83d6..00000000
--- a/AI/Finite-Element-Analysis.md
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-31D804
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Finite-Element-Analysis"
----
-
-# [[Finite-Element-Analysis]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** AI 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Finite-Element-Analysis.md]]
----
diff --git a/AI/Firefox.md b/AI/Firefox.md
deleted file mode 100644
index f045c8eb..00000000
--- a/AI/Firefox.md
+++ /dev/null
@@ -1,47 +0,0 @@
----
-id: P-REINFORCE-AUTO-7265C7
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Firefox"
----
-
-# [[Firefox]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-**웹 성능 및 네트워크 최적화**
-*   Firefox는 Interop 2025 프로젝트의 일환으로 Largest Contentful Paint(LCP) 및 Interaction to Next Paint(INP) 지표 지원 작업을 시작했으며, 2025년 10월 배포된 버전 144부터 INP를 정식 지원하고 있습니다 [1].
-*   Time to First Byte(TTFB) 점수를 측정할 때 Firefox는 기존부터 early hint 응답 데이터를 포함하여 계산해왔으며, 2025년 2월 Chrome 역시 이 방식을 따르도록 변경되었습니다 [2]. 
-*   리소스의 사전 로딩을 위한 추측 규칙(Speculation Rules) 프로토타입을 작업 중이며 [3], 재방문 시 다운로드 크기를 줄일 수 있는 압축 딕셔너리(Compression Dictionaries) 지원도 활발히 개발하고 있습니다 [4].
-
-**이미지 포맷 지원**
-*   과거 Mozilla는 저수준 언어로 작성된 복잡한 디코더가 일으킬 수 있는 보안 위험을 우려하여 JPEG XL 도입을 꺼렸습니다 [5]. 그러나 2024년 9월 Google과 Rust 기반 디코더에 대해 논의한 후 입장을 선회했습니다 [5].
-
-**WebGL 지원 및 프로파일링**
-*   보안상의 이유로 듀얼 GPU를 사용하는 Mac 시스템에서는 WebGL 컨텍스트를 생성하기 전에 반드시 개별(Discrete) GPU로 전환하여 머물도록 강제합니다 [6]. GPU가 블랙리스트에 오르더라도 `WebGLRenderingContext` 객체 자체는 존재합니다 [7].
-*   개발자가 WebGL 성능을 분석할 때 `about:config`에서 `layers.acceleration.draw-fps`를 활성화하여 FPS 카운터를 표시할 수 있습니다 [8].
-*   Vsync를 비활성화하려면 `layout.frame_rate`를 0으로, `layers.offmainthreadcomposition.frame-rate`를 1000으로 설정하고, ANGLE을 우회하여 네이티브 OpenGL을 테스트하려면 `webgl.prefer-native-gl`을 활성화할 수 있습니다 [9, 10].
-*   다만, 보안을 이유로 `EXT_disjoint_timer_query` 확장은 지원이 중단되었으며, `EXT_disjoint_timer_query_webgl2`가 작동하지 않거나 브라우저 탭을 다운시키는 버그가 보고된 바 있습니다 [11-14].
-
-**WebGPU 생태계와 안정성**
-*   Firefox는 버전 141부터 Windows 플랫폼에 한정하여 WebGPU 지원을 도입하기 시작했습니다 [15]. 
-*   Firefox의 렌더링 엔진인 Gecko는 WebGPU 타임스탬프 쿼리(timestamp queries) 지원에 대해 긍정적인 입장을 냈습니다 [16, 17].
-*   하지만 현재 Firefox 내 WebGPU 생태계는 일부 하드웨어에서 여전히 불안정한 상태입니다. 특정 기기(예: Lenovo MX350)에서는 실행 시 "WebGPU is disabled by blocklist"라는 오류와 함께 차단되며, Intel NUC와 같은 환경에서는 타임스탬프 쿼리가 비정상적으로 긴 프레임 시간을 보고하는 버그가 존재합니다 [18].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** AI 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[WebGPU]], [[WebGL]], [[Interaction to Next Paint (INP)]], [[JPEG XL]]
-- **Projects/Contexts:** [[Interop 2025]]
-- **Contradictions/Notes:** 소스에 따르면 Firefox는 보안 문제를 이유로 WebGL의 타이머 쿼리(`EXT_disjoint_timer_query`) 기능을 지원하지 않았으나 [12, 14], WebGPU의 타임스탬프 쿼리 기능에 대해서는 긍정적인 도입 의사를 보였습니다 [16, 17].
-
----
-*Last updated: 2026-04-19*
-- Raw Source: [[00_Raw/2026-04-20/Firefox.md]]
----
diff --git a/AI/First Input Delay (FID).md b/AI/First Input Delay (FID).md
deleted file mode 100644
index e0ca40fd..00000000
--- a/AI/First Input Delay (FID).md	
+++ /dev/null
@@ -1,33 +0,0 @@
----
-id: P-REINFORCE-AUTO-DD1BE6
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - First Input Delay (FID)"
----
-
-# [[First Input Delay (FID)]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> First Input Delay(FID)는 사용자가 웹페이지에서 첫 상호작용을 시도할 때, 브라우저가 해당 이벤트를 처리하기 시작할 때까지 걸리는 지연 시간을 측정하는 지표이다 [1]. 이 지표는 이벤트 핸들러가 시작되기 전까지의 지연 시간만을 측정하며, 이후의 렌더링 지연이나 후속 상호작용은 고려하지 않는 한계가 있었다 [2]. 이러한 단점을 보완하기 위해 2024년 구글(Google)은 코어 웹 바이탈(Core Web Vitals)의 공식 상호작용 측정 지표를 FID에서 Interaction to Next Paint (INP)로 전면 대체하였다 [3, 4].
-
-## 📖 구조화된 지식 (Synthesized Content)
-- **FID의 발생 원인:** 사용자가 웹페이지가 준비되었다고 생각하여 클릭 등의 이벤트를 발생시켰을 때, 브라우저가 자바스크립트를 다운로드하거나 파싱 및 실행하느라 백그라운드 작업이 바쁜 상태라면 입력 지연이 발생하게 되며 FID는 바로 이 시간을 측정한다 [1].
-- **측정 방식의 한계:** FID는 페이지 방문 중 발생하는 여러 상호작용 중에서 오직 '첫 번째 상호작용(first interaction)'의 지연 시간만을 측정한다 [2]. 이벤트 핸들러가 시작되기 직전까지의 대기 시간만을 평가하기 때문에, 실제 이벤트가 처리되는 시간(processing time)이나 화면에 결과를 렌더링하는 데 걸리는 프레젠테이션 지연(presentation delay)을 무시한다는 명확한 한계가 존재했다 [2, 5].
-- **타 지표와의 연관성:** 크롬 라이트하우스(Chrome Lighthouse) 등에서 측정하는 Time to Interactive (TTI) 지표는 페이지가 완전히 상호작용 가능해질 때까지의 시간을 뜻하는데, 이 TTI는 First Input Delay (FID)뿐만 아니라 Largest Contentful Paint (LCP)와 같은 요소를 포함하여 산출된다 [6, 7].
-- **INP(Interaction to Next Paint)로의 진화:** 첫 상호작용만을 측정하던 FID 방식으로는 사용자 경험(UX)을 완벽하게 반영하기 어려웠다 [5]. 이에 구글은 2024년에 FID를 폐기하고, 페이지에 머무는 동안 발생하는 모든 상호작용(클릭, 탭, 키보드 입력 등)의 전체 지연 시간을 종합적으로 평가하는 INP 지표를 코어 웹 바이탈에 새롭게 도입하였다 [2, 3, 5].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** AI 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[Interaction to Next Paint (INP)]], [[Core Web Vitals]], [[Time to Interactive (TTI)]]
-- **Projects/Contexts:** [[Google Page Experience]], [[Chrome User Experience Report (CrUX)]]
-- **Contradictions/Notes:** 한때 구글 코어 웹 바이탈의 핵심 반응성 지표로 사용되었으나, 단일 상호작용만 측정하는 결함이 인정되어 2024년을 기점으로 공식 지표의 지위를 잃고 INP로 완전히 대체되었다 [3, 4].
-
----
-*Last updated: 2026-04-19*
-- Raw Source: [[00_Raw/2026-04-20/First Input Delay (FID).md]]
----
diff --git a/AI/Fixed Time Step vs Variable Time Step.md b/AI/Fixed Time Step vs Variable Time Step.md
deleted file mode 100644
index 21506c57..00000000
--- a/AI/Fixed Time Step vs Variable Time Step.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-5FB60B
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Fixed Time Step vs Variable Time Step"
----
-
-# [[Fixed Time Step vs Variable Time Step]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** AI 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Fixed Time Step vs Variable Time Step.md]]
----
diff --git a/AI/Flow State.md b/AI/Flow State.md
deleted file mode 100644
index de6cc2b0..00000000
--- a/AI/Flow State.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-E89B44
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Flow State"
----
-
-# [[Flow State]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** AI 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Flow State.md]]
----
diff --git a/AI/Flow-State.md b/AI/Flow-State.md
deleted file mode 100644
index 06e3bb44..00000000
--- a/AI/Flow-State.md
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-364080
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Flow-State"
----
-
-# [[Flow-State]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** AI 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Flow-State.md]]
----
diff --git a/AI/Functional-Programming-in-TypeScript.md b/AI/Functional-Programming-in-TypeScript.md
deleted file mode 100644
index 960d59d4..00000000
--- a/AI/Functional-Programming-in-TypeScript.md
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-80BECB
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Functional-Programming-in-TypeScript"
----
-
-# [[Functional-Programming-in-TypeScript]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** AI 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Functional-Programming-in-TypeScript.md]]
----
diff --git a/AI/GPU.md b/AI/GPU.md
deleted file mode 100644
index f00631b5..00000000
--- a/AI/GPU.md
+++ /dev/null
@@ -1,33 +0,0 @@
----
-id: P-REINFORCE-AUTO-DD4F11
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - GPU"
----
-
-# [[GPU]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> GPU(Graphics Processing Unit)는 실시간 3D 그래픽 렌더링과 병렬 연산 처리에 최적화된 하드웨어 장치이다 [1]. 최신 GPU는 수천 개의 프로세싱 코어를 갖추고 있어 그래픽 렌더링뿐만 아니라 물리 시뮬레이션, AI 추론 등 범용적인 병렬 작업에 뛰어난 성능을 발휘한다 [2, 3]. 웹 환경에서는 WebGL 및 WebGPU와 같은 그래픽 API를 통해 제어되며, 셰이더(Shader) 프로그램을 하드웨어 수준에서 매우 빠른 속도로 실행하여 시각적 결과물을 만들어낸다 [1, 4].
-
-## 📖 구조화된 지식 (Synthesized Content)
-* **웹 그래픽 파이프라인에서의 역할:** GPU는 WebGL이나 WebGPU API를 통해 전달된 셰이더 프로그램을 실행하여 HTML5 브라우저의 화면(`<canvas>`)에 3D 장면을 렌더링한다 [1, 4]. 렌더링 속도를 극대화하기 위해서는 애플리케이션 코드가 실행되는 환경과 GPU 간의 컨텍스트 스위칭(Context Switching) 및 통신을 최소화해야 하며, 가급적 렌더링에 필요한 모든 데이터를 GPU 메모리에 한 번만 복사하는 것이 이상적이다 [5-8].
-* **GPU 바운드(GPU Bound)와 CPU 병목 현상:** 성능 분석 시 렌더링 지연의 원인이 CPU인지 GPU인지 파악하는 것이 중요하다 [9, 10]. 복잡한 프래그먼트 셰이더 연산이나 과도한 드로우 콜(Draw Call)이 발생할 경우, CPU는 유휴 상태임에도 GPU가 지속적으로 작동하며 한계에 부딪히는 'GPU 바운드' 현상이 발생한다 [11]. 반대로, 단일 스레드로 명령을 전송하는 WebGL 아키텍처 하에서는 최신 GPU가 초당 수백만 개의 폴리곤을 처리할 수 있음에도 불구하고 CPU가 명령을 충분히 빨리 전달하지 못해 GPU가 유휴 상태로 대기하는 CPU 병목 현상이 발생하기도 한다 [2, 12].
-* **컴퓨트 셰이더를 통한 범용 병렬 처리(GPGPU):** 과거 WebGL은 GPU의 사용을 그래픽 렌더링에만 국한시켰으나, WebGPU는 컴퓨트 셰이더(Compute Shaders)를 도입하여 GPU를 범용 병렬 프로세서로 변모시켰다 [2, 3]. GPU의 SIMT(Single-Instruction-Multiple-Thread) 아키텍처를 활용하면 수십만 개의 파티클 시스템, 유체 시뮬레이션, 데이터 정렬, 기계학습 기반의 거대 언어 모델(LLM) 추론 등의 방대한 연산을 CPU 개입 없이 GPU 내부에서 직접 병렬로 처리할 수 있다 [3, 13-15].
-* **성능 및 전력 효율 극대화:** GPU 주도형(GPU-driven) 렌더링 방식을 도입하여 오클루전 컬링, 물리 시뮬레이션 등의 핵심 로직을 GPU로 옮기면 CPU와 GPU 간의 데이터 왕복 횟수 및 동기화 오버헤드를 크게 줄일 수 있다 [16, 17]. 이는 명령 생성에 따른 CPU 부하를 감소시켜 전력 소비와 발열을 낮추며, 특히 모바일 기기에서 열에 의한 스로틀링(Thermal Throttling)을 방지하여 일관된 프레임 속도와 렌더링 성능을 유지하도록 돕는다 [17-19].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** AI 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[WebGL]], [[WebGPU]], [[Compute Shader]], [[CPU]]
-- **Projects/Contexts:** [[WebSplatter]], [[Three.js]], [[CesiumJS]]
-- **Contradictions/Notes:** 과거 WebGL 생태계에서는 구조적 한계로 인해 물리 연산이나 정렬 작업을 CPU에서 처리해야 했고 이로 인해 GPU가 자주 유휴 상태(Idle)에 머무는 비효율이 존재했다. 그러나 WebGPU의 등장으로 컴퓨트 셰이더 기반의 연산이 가능해지면서, 렌더링과 연산 모두를 GPU에서 병렬 처리하여 GPU의 하드웨어 능력을 온전히 활용할 수 있게 되었다 [2, 3, 12, 20].
-
----
-*Last updated: 2026-04-19*
-- Raw Source: [[00_Raw/2026-04-20/GPU.md]]
----
diff --git a/AI/GRPO (Group Relative Policy Optimization).md b/AI/GRPO (Group Relative Policy Optimization).md
deleted file mode 100644
index 9058702b..00000000
--- a/AI/GRPO (Group Relative Policy Optimization).md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-1312F9
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - GRPO (Group Relative Policy Optimization)"
----
-
-# [[GRPO (Group Relative Policy Optimization)]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** AI 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/GRPO (Group Relative Policy Optimization).md]]
----
diff --git a/AI/Gacha Mechanics Analysis.md b/AI/Gacha Mechanics Analysis.md
deleted file mode 100644
index 91c15a67..00000000
--- a/AI/Gacha Mechanics Analysis.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-F5E08D
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Gacha Mechanics Analysis"
----
-
-# [[Gacha Mechanics Analysis]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** AI 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Gacha Mechanics Analysis.md]]
----
diff --git a/AI/Gait-Analysis-Laboratory.md b/AI/Gait-Analysis-Laboratory.md
deleted file mode 100644
index cacab3c5..00000000
--- a/AI/Gait-Analysis-Laboratory.md
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-3390EF
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Gait-Analysis-Laboratory"
----
-
-# [[Gait-Analysis-Laboratory]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** AI 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Gait-Analysis-Laboratory.md]]
----
diff --git a/AI/Gait-Analysis-Methodologies.md b/AI/Gait-Analysis-Methodologies.md
deleted file mode 100644
index e6399682..00000000
--- a/AI/Gait-Analysis-Methodologies.md
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-ECB110
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Gait-Analysis-Methodologies"
----
-
-# [[Gait-Analysis-Methodologies]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** AI 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Gait-Analysis-Methodologies.md]]
----
diff --git a/AI/Game Balance Theory.md b/AI/Game Balance Theory.md
deleted file mode 100644
index f4b69677..00000000
--- a/AI/Game Balance Theory.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-FE4B62
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Game Balance Theory"
----
-
-# [[Game Balance Theory]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** AI 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Game Balance Theory.md]]
----
diff --git a/AI/Game Economy Modeling.md b/AI/Game Economy Modeling.md
deleted file mode 100644
index 1bda3a09..00000000
--- a/AI/Game Economy Modeling.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-80302B
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Game Economy Modeling"
----
-
-# [[Game Economy Modeling]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** AI 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Game Economy Modeling.md]]
----
diff --git a/AI/Game Engine Architecture (Jason Gregory).md b/AI/Game Engine Architecture (Jason Gregory).md
deleted file mode 100644
index b1f1c45e..00000000
--- a/AI/Game Engine Architecture (Jason Gregory).md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-5CDF1A
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Game Engine Architecture (Jason Gregory)"
----
-
-# [[Game Engine Architecture (Jason Gregory)]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** AI 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Game Engine Architecture (Jason Gregory).md]]
----
diff --git a/AI/Game Engine Architecture.md b/AI/Game Engine Architecture.md
deleted file mode 100644
index e411e03e..00000000
--- a/AI/Game Engine Architecture.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-BD4476
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Game Engine Architecture"
----
-
-# [[Game Engine Architecture]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** AI 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Game Engine Architecture.md]]
----
diff --git a/AI/Game-Design-Ontology.md b/AI/Game-Design-Ontology.md
deleted file mode 100644
index 2bfb53c1..00000000
--- a/AI/Game-Design-Ontology.md
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-DCD5C6
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Game-Design-Ontology"
----
-
-# [[Game-Design-Ontology]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** AI 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Game-Design-Ontology.md]]
----
diff --git a/AI/Game-Design-Theory.md b/AI/Game-Design-Theory.md
deleted file mode 100644
index 366589f5..00000000
--- a/AI/Game-Design-Theory.md
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-25F5B7
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Game-Design-Theory"
----
-
-# [[Game-Design-Theory]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** AI 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Game-Design-Theory.md]]
----
diff --git a/AI/Game-Ontology-for-PCG.md b/AI/Game-Ontology-for-PCG.md
deleted file mode 100644
index 2f00f9fa..00000000
--- a/AI/Game-Ontology-for-PCG.md
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-D042FF
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Game-Ontology-for-PCG"
----
-
-# [[Game-Ontology-for-PCG]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** AI 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Game-Ontology-for-PCG.md]]
----
diff --git a/AI/Gamification Theory.md b/AI/Gamification Theory.md
deleted file mode 100644
index 7c04375b..00000000
--- a/AI/Gamification Theory.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-2DF448
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Gamification Theory"
----
-
-# [[Gamification Theory]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** AI 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Gamification Theory.md]]
----
diff --git a/AI/Generative Adversarial Networks (GANs) in Fine Arts.md b/AI/Generative Adversarial Networks (GANs) in Fine Arts.md
deleted file mode 100644
index 30077d7f..00000000
--- a/AI/Generative Adversarial Networks (GANs) in Fine Arts.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-B61BB5
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Generative Adversarial Networks (GANs) in Fine Arts"
----
-
-# [[Generative Adversarial Networks (GANs) in Fine Arts]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** AI 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Generative Adversarial Networks (GANs) in Fine Arts.md]]
----
diff --git a/AI/Generative-Adversarial-Networks.md b/AI/Generative-Adversarial-Networks.md
deleted file mode 100644
index 7834b4d7..00000000
--- a/AI/Generative-Adversarial-Networks.md
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-B87DE0
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Generative-Adversarial-Networks"
----
-
-# [[Generative-Adversarial-Networks]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** AI 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Generative-Adversarial-Networks.md]]
----
diff --git a/AI/Generics-and-Polymorphism.md b/AI/Generics-and-Polymorphism.md
deleted file mode 100644
index f9480826..00000000
--- a/AI/Generics-and-Polymorphism.md
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-E65F53
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Generics-and-Polymorphism"
----
-
-# [[Generics-and-Polymorphism]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** AI 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Generics-and-Polymorphism.md]]
----
diff --git a/AI/Geographic-Information-Systems (GIS).md b/AI/Geographic-Information-Systems (GIS).md
deleted file mode 100644
index d009d8d2..00000000
--- a/AI/Geographic-Information-Systems (GIS).md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-395A13
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Geographic-Information-Systems (GIS)"
----
-
-# [[Geographic-Information-Systems (GIS)]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** AI 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Geographic-Information-Systems (GIS).md]]
----
diff --git a/AI/Geriatric-Medicine.md b/AI/Geriatric-Medicine.md
deleted file mode 100644
index 6624c18c..00000000
--- a/AI/Geriatric-Medicine.md
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-88176E
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Geriatric-Medicine"
----
-
-# [[Geriatric-Medicine]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** AI 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Geriatric-Medicine.md]]
----
diff --git a/AI/GitLab CI.md b/AI/GitLab CI.md
deleted file mode 100644
index d7772e59..00000000
--- a/AI/GitLab CI.md	
+++ /dev/null
@@ -1,34 +0,0 @@
----
-id: P-REINFORCE-AUTO-0DF208
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - GitLab CI"
----
-
-# [[GitLab CI]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 소스에 관련 정보가 부족합니다. 제공된 소스에서 GitLab CI 자체의 아키텍처나 구체적인 기능에 대한 직접적인 설명은 없으며, 주로 Snyk Code나 SonarQube와 같은 정적 애플리케이션 보안 테스트(SAST) 및 AI 코드 리뷰 도구들이 원활하게 연동되는 대표적인 CI/CD 파이프라인 플랫폼 중 하나로만 간략히 언급됩니다 [1, 2].
-
-## 📖 구조화된 지식 (Synthesized Content)
-소스에 관련 정보가 부족합니다. 하지만 제공된 문서 내에서 외부 보안 및 분석 도구와의 연동 맥락을 통해 다음과 같은 제한적인 역할을 확인할 수 있습니다.
-
-* **보안 및 코드 리뷰 도구와의 원활한 통합:** GitLab CI는 SonarQube, Snyk Code, Axify, CodeAnt AI 및 다양한 풀 리퀘스트 리뷰 봇(Pull Request Review Bots) 등과 통합(Integration)되어 사용되는 주요 개발 플랫폼입니다 [1, 3-6].
-* **CI/CD 파이프라인 내 보안 스캔:** Snyk Code와 같은 도구는 GitLab CI 파이프라인에 통합되어 풀 리퀘스트(Pull request)가 발생할 때마다 변경된 파일을 스캔합니다 [2]. 발견된 취약점은 인라인 주석으로 게시되며, 심각한 취약점이 감지될 경우 코드 병합을 차단하도록 설정할 수 있습니다 [2].
-* **풀 리퀘스트(PR) 및 가드레일 환경:** 개발자들은 GitLab의 풀 리퀘스트 환경을 통해 수동으로 코드를 검토하거나, AI 및 머신러닝 기반의 리뷰 봇을 연동하여 팀의 코드 표준을 강제하고 구조화된 코멘트를 생성하는 자동화된 가드레일을 구축합니다 [5, 7, 8].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** AI 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[CI/CD 파이프라인]], [[SAST (정적 애플리케이션 보안 테스트)]]
-- **Projects/Contexts:** [[Snyk Code 파이프라인 통합]], [[SonarQube 개발 워크플로우 연동]]
-- **Contradictions/Notes:** 소스에 관련 정보가 부족합니다. GitLab CI만의 독자적인 기능이나 설정 방법에 대한 구체적인 내용은 소스에 존재하지 않으며, GitHub이나 Bitbucket 등과 함께 서드파티 보안/분석 도구가 지원하는 환경 목록으로만 등장합니다.
-
----
-*Last updated: 2026-04-19*
-- Raw Source: [[00_Raw/2026-04-20/GitLab CI.md]]
----
diff --git a/AI/Goal Misgeneralization (목표 오일반화).md b/AI/Goal Misgeneralization (목표 오일반화).md
deleted file mode 100644
index ee53e944..00000000
--- a/AI/Goal Misgeneralization (목표 오일반화).md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-85A1A5
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Goal Misgeneralization (목표 오일반화)"
----
-
-# [[Goal Misgeneralization (목표 오일반화)]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** AI 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Goal Misgeneralization (목표 오일반화).md]]
----
diff --git a/AI/Graph-Coloring-Problem.md b/AI/Graph-Coloring-Problem.md
deleted file mode 100644
index fc6b4b08..00000000
--- a/AI/Graph-Coloring-Problem.md
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-108994
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Graph-Coloring-Problem"
----
-
-# [[Graph-Coloring-Problem]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** AI 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Graph-Coloring-Problem.md]]
----
diff --git a/AI/Graph-Theory.md b/AI/Graph-Theory.md
deleted file mode 100644
index ff20564a..00000000
--- a/AI/Graph-Theory.md
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-961E9B
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Graph-Theory"
----
-
-# [[Graph-Theory]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** AI 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Graph-Theory.md]]
----
diff --git a/AI/GraphQL-Code-Generator.md b/AI/GraphQL-Code-Generator.md
deleted file mode 100644
index 146b908a..00000000
--- a/AI/GraphQL-Code-Generator.md
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-CFA98F
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - GraphQL-Code-Generator"
----
-
-# [[GraphQL-Code-Generator]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** AI 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/GraphQL-Code-Generator.md]]
----
diff --git a/AI/GraphRAG (그래프 기반 검색 증강 생성).md b/AI/GraphRAG (그래프 기반 검색 증강 생성).md
deleted file mode 100644
index 621244d5..00000000
--- a/AI/GraphRAG (그래프 기반 검색 증강 생성).md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-54AA1C
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - GraphRAG (그래프 기반 검색 증강 생성)"
----
-
-# [[GraphRAG (그래프 기반 검색 증강 생성)]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** AI 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/GraphRAG (그래프 기반 검색 증강 생성).md]]
----
diff --git a/AI/Grit.md b/AI/Grit.md
deleted file mode 100644
index 9a0a4236..00000000
--- a/AI/Grit.md
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-53ED1B
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Grit"
----
-
-# [[Grit]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** AI 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Grit.md]]
----
diff --git a/AI/Growth Mindset Intervention in Education.md b/AI/Growth Mindset Intervention in Education.md
deleted file mode 100644
index 743c6681..00000000
--- a/AI/Growth Mindset Intervention in Education.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-D9A336
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Growth Mindset Intervention in Education"
----
-
-# [[Growth Mindset Intervention in Education]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** AI 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Growth Mindset Intervention in Education.md]]
----
diff --git a/AI/Growth-Mindset.md b/AI/Growth-Mindset.md
deleted file mode 100644
index f863e494..00000000
--- a/AI/Growth-Mindset.md
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-73BBE5
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Growth-Mindset"
----
-
-# [[Growth-Mindset]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** AI 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Growth-Mindset.md]]
----
diff --git a/AI/Guilty-Gear-Xrd-Rendering-Pipeline.md b/AI/Guilty-Gear-Xrd-Rendering-Pipeline.md
deleted file mode 100644
index 4d46159e..00000000
--- a/AI/Guilty-Gear-Xrd-Rendering-Pipeline.md
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-44CE35
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Guilty-Gear-Xrd-Rendering-Pipeline"
----
-
-# [[Guilty-Gear-Xrd-Rendering-Pipeline]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** AI 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Guilty-Gear-Xrd-Rendering-Pipeline.md]]
----
diff --git a/AI/HANDOVER.md b/AI/HANDOVER.md
deleted file mode 100644
index 01d32516..00000000
--- a/AI/HANDOVER.md
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-5DA4F4
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - HANDOVER"
----
-
-# [[HANDOVER]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** AI 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/HANDOVER.md]]
----
diff --git a/AI/HBO Prestige Television.md b/AI/HBO Prestige Television.md
deleted file mode 100644
index 4fb8cd81..00000000
--- a/AI/HBO Prestige Television.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-4ED001
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - HBO Prestige Television"
----
-
-# [[HBO Prestige Television]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** AI 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/HBO Prestige Television.md]]
----
diff --git a/AI/HHH (Helpful Harmless Honest).md b/AI/HHH (Helpful Harmless Honest).md
deleted file mode 100644
index 9ac6c971..00000000
--- a/AI/HHH (Helpful Harmless Honest).md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-11A9D4
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - HHH (Helpful Harmless Honest)"
----
-
-# [[HHH (Helpful Harmless Honest)]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** AI 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/HHH (Helpful, Harmless, Honest).md]]
----
diff --git a/AI/Hardware-Verification.md b/AI/Hardware-Verification.md
deleted file mode 100644
index f76490c0..00000000
--- a/AI/Hardware-Verification.md
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-70F7A4
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Hardware-Verification"
----
-
-# [[Hardware-Verification]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** AI 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Hardware-Verification.md]]
----
diff --git a/AI/Health Informatics (mHealth).md b/AI/Health Informatics (mHealth).md
deleted file mode 100644
index 5a5e5da0..00000000
--- a/AI/Health Informatics (mHealth).md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-A9629D
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Health Informatics (mHealth)"
----
-
-# [[Health Informatics (mHealth)]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** AI 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Health Informatics (mHealth).md]]
----
diff --git a/AI/Heap Snapshot(힙 스냅샷).md b/AI/Heap Snapshot(힙 스냅샷).md
deleted file mode 100644
index a3fac0ac..00000000
--- a/AI/Heap Snapshot(힙 스냅샷).md	
+++ /dev/null
@@ -1,30 +0,0 @@
----
-id: P-REINFORCE-AUTO-7C13B9
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Heap Snapshot(힙 스냅샷)"
----
-
-# [[Heap Snapshot(힙 스냅샷)]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> **Heap Snapshot(힙 스냅샷)**은 특정 시점에 애플리케이션의 전체 객체 그래프와 힙 메모리 상태를 캡처한 데이터이다 [1, 2]. 주로 불필요하게 남아있는 객체의 유지 경로(Retaining path)를 식별하여 메모리 누수를 탐지하고 분석하기 위해 사용된다 [2, 3]. Chrome DevTools나 IntelliJ IDEA 같은 도구를 통해 생성할 수 있으며, 여러 스냅샷을 비교함으로써 메모리 할당 패턴과 가비지 컬렉션 이후의 잔존 메모리를 파악할 수 있다 [1, 4-6].
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** AI 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[Memory Leak (메모리 누수)]], [[Garbage Collection (가비지 컬렉션)]], [[Retained Size vs Shallow Size]], [[Closure Variable Retention]]
-- **Projects/Contexts:** [[Chrome DevTools Memory Panel]], [[V8 JavaScript Engine]], [[Node.js Production Monitoring]]
-- **Contradictions/Notes:** 미니파이(Minified)된 프로덕션 코드에서는 식별자 이름이 변형되어 Retainer 체인을 알아보기 어렵기 때문에, DevTools에 소스 맵(Source maps)을 연결하거나 처음부터 함수에 명시적으로 이름을 지정(Named functions)하는 것이 분석에 훨씬 유리하다 [19, 25]. 또한, 스냅샷에서 메모리가 증가했다고 해서 모두 누수인 것은 아니며, 캐시나 Undo 히스토리처럼 의도적으로 메모리를 유지하는 "의도된 보존(Intentional retention)"과 실제 누수를 구별해야 한다 [19].
-
----
-*Last updated: 2026-04-19*
-- Raw Source: [[00_Raw/2026-04-20/Heap Snapshot(힙 스냅샷).md]]
----
diff --git a/AI/Hebbian Theory.md b/AI/Hebbian Theory.md
deleted file mode 100644
index 947ba24b..00000000
--- a/AI/Hebbian Theory.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-D8B3D2
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Hebbian Theory"
----
-
-# [[Hebbian Theory]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** AI 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Hebbian Theory.md]]
----
diff --git a/AI/High-Cohesion-Low-Coupling.md b/AI/High-Cohesion-Low-Coupling.md
deleted file mode 100644
index 862af89d..00000000
--- a/AI/High-Cohesion-Low-Coupling.md
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-A143BE
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - High-Cohesion-Low-Coupling"
----
-
-# [[High-Cohesion-Low-Coupling]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** AI 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/High-Cohesion-Low-Coupling.md]]
----
diff --git a/AI/High-Frequency Trading Models.md b/AI/High-Frequency Trading Models.md
deleted file mode 100644
index 8b180f54..00000000
--- a/AI/High-Frequency Trading Models.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-6E0050
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - High-Frequency Trading Models"
----
-
-# [[High-Frequency Trading Models]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** AI 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/High-Frequency Trading Models.md]]
----
diff --git a/AI/High-Performance Training Programs (Tier 1 Orgs).md b/AI/High-Performance Training Programs (Tier 1 Orgs).md
deleted file mode 100644
index a9cb4f03..00000000
--- a/AI/High-Performance Training Programs (Tier 1 Orgs).md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-30B011
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - High-Performance Training Programs (Tier 1 Orgs)"
----
-
-# [[High-Performance Training Programs (Tier 1 Orgs)]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** AI 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/High-Performance Training Programs (Tier 1 Orgs).md]]
----
diff --git a/AI/High-Performance-Coaching.md b/AI/High-Performance-Coaching.md
deleted file mode 100644
index 6fc865e3..00000000
--- a/AI/High-Performance-Coaching.md
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-FF879B
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - High-Performance-Coaching"
----
-
-# [[High-Performance-Coaching]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** AI 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/High-Performance-Coaching.md]]
----
diff --git a/AI/High-Performance-Sports-Science.md b/AI/High-Performance-Sports-Science.md
deleted file mode 100644
index ca4857da..00000000
--- a/AI/High-Performance-Sports-Science.md
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-D74500
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - High-Performance-Sports-Science"
----
-
-# [[High-Performance-Sports-Science]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** AI 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/High-Performance-Sports-Science.md]]
----
diff --git a/AI/Homeostasis.md b/AI/Homeostasis.md
deleted file mode 100644
index b06eddc9..00000000
--- a/AI/Homeostasis.md
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-D75E8D
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Homeostasis"
----
-
-# [[Homeostasis]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** AI 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Homeostasis.md]]
----
diff --git a/AI/Human-Computer-Interaction.md b/AI/Human-Computer-Interaction.md
deleted file mode 100644
index 0652dc80..00000000
--- a/AI/Human-Computer-Interaction.md
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-3ED48D
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Human-Computer-Interaction"
----
-
-# [[Human-Computer-Interaction]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** AI 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Human-Computer-Interaction.md]]
----
diff --git a/AI/Hyperinflation in Closed-Loop Systems.md b/AI/Hyperinflation in Closed-Loop Systems.md
deleted file mode 100644
index 75b2932d..00000000
--- a/AI/Hyperinflation in Closed-Loop Systems.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-01FD40
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Hyperinflation in Closed-Loop Systems"
----
-
-# [[Hyperinflation in Closed-Loop Systems]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** AI 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Hyperinflation in Closed-Loop Systems.md]]
----
diff --git a/AI/IEEE P36521.md b/AI/IEEE P36521.md
deleted file mode 100644
index 7ccfc2bc..00000000
--- a/AI/IEEE P36521.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-5A9960
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - IEEE P36521"
----
-
-# [[IEEE P36521]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** AI 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/IEEE P3652.1.md]]
----
diff --git a/AI/Immersive Sim Design.md b/AI/Immersive Sim Design.md
deleted file mode 100644
index 8c18ab92..00000000
--- a/AI/Immersive Sim Design.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-A1E36D
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Immersive Sim Design"
----
-
-# [[Immersive Sim Design]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** AI 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Immersive Sim Design.md]]
----
diff --git a/AI/Immersive Sims (eg Deus Ex Dishonored).md b/AI/Immersive Sims (eg Deus Ex Dishonored).md
deleted file mode 100644
index 5c64c6ee..00000000
--- a/AI/Immersive Sims (eg Deus Ex Dishonored).md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-F70063
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Immersive Sims (eg Deus Ex Dishonored)"
----
-
-# [[Immersive Sims (eg Deus Ex Dishonored)]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** AI 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Immersive Sims (e.g., Deus Ex, Dishonored).md]]
----
diff --git a/AI/Immersive Sims (eg Deus Ex Thief).md b/AI/Immersive Sims (eg Deus Ex Thief).md
deleted file mode 100644
index c3d12af2..00000000
--- a/AI/Immersive Sims (eg Deus Ex Thief).md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-B11AD8
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Immersive Sims (eg Deus Ex Thief)"
----
-
-# [[Immersive Sims (eg Deus Ex Thief)]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** AI 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Immersive Sims (e.g., Deus Ex, Thief).md]]
----
diff --git a/AI/Immersive-Sim-Genre.md b/AI/Immersive-Sim-Genre.md
deleted file mode 100644
index 9e30a75b..00000000
--- a/AI/Immersive-Sim-Genre.md
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-F89165
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Immersive-Sim-Genre"
----
-
-# [[Immersive-Sim-Genre]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** AI 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Immersive-Sim-Genre.md]]
----
diff --git a/AI/Immutability-Patterns.md b/AI/Immutability-Patterns.md
deleted file mode 100644
index a4a3a999..00000000
--- a/AI/Immutability-Patterns.md
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-0F93B3
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Immutability-Patterns"
----
-
-# [[Immutability-Patterns]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** AI 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Immutability-Patterns.md]]
----
diff --git a/AI/In-Context Learning (ICL 문맥 내 학습).md b/AI/In-Context Learning (ICL 문맥 내 학습).md
deleted file mode 100644
index 6cc4acab..00000000
--- a/AI/In-Context Learning (ICL 문맥 내 학습).md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-0A8DD5
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - In-Context Learning (ICL 문맥 내 학습)"
----
-
-# [[In-Context Learning (ICL 문맥 내 학습)]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** AI 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/In-Context Learning (ICL, 문맥 내 학습).md]]
----
diff --git a/AI/Incremental-Computation.md b/AI/Incremental-Computation.md
deleted file mode 100644
index 41c0cadb..00000000
--- a/AI/Incremental-Computation.md
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-6A40F8
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Incremental-Computation"
----
-
-# [[Incremental-Computation]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** AI 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Incremental-Computation.md]]
----
diff --git a/AI/Indoor Wayfinding for Smart Cities.md b/AI/Indoor Wayfinding for Smart Cities.md
deleted file mode 100644
index d5a35407..00000000
--- a/AI/Indoor Wayfinding for Smart Cities.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-FA7892
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Indoor Wayfinding for Smart Cities"
----
-
-# [[Indoor Wayfinding for Smart Cities]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** AI 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Indoor Wayfinding for Smart Cities.md]]
----
diff --git a/AI/Industrial Metaverse.md b/AI/Industrial Metaverse.md
deleted file mode 100644
index a88b8819..00000000
--- a/AI/Industrial Metaverse.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-ED0741
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Industrial Metaverse"
----
-
-# [[Industrial Metaverse]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** AI 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Industrial Metaverse.md]]
----
diff --git a/AI/Industrial-Automation.md b/AI/Industrial-Automation.md
deleted file mode 100644
index 4f4ddb6c..00000000
--- a/AI/Industrial-Automation.md
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-879F81
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Industrial-Automation"
----
-
-# [[Industrial-Automation]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** AI 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Industrial-Automation.md]]
----
diff --git a/AI/Injury-Prevention-Protocols.md b/AI/Injury-Prevention-Protocols.md
deleted file mode 100644
index 7bbbfae3..00000000
--- a/AI/Injury-Prevention-Protocols.md
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-F84241
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Injury-Prevention-Protocols"
----
-
-# [[Injury-Prevention-Protocols]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** AI 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Injury-Prevention-Protocols.md]]
----
diff --git a/AI/InstancedMesh2 library.md b/AI/InstancedMesh2 library.md
deleted file mode 100644
index fbf16012..00000000
--- a/AI/InstancedMesh2 library.md	
+++ /dev/null
@@ -1,37 +0,0 @@
----
-id: P-REINFORCE-AUTO-F5A361
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - InstancedMesh2 library"
----
-
-# [[InstancedMesh2 library]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> InstancedMesh2는 Three.js의 공식 InstancedMesh가 가진 한계를 극복하고 대규모 객체 렌더링을 최적화하기 위해 agargaro가 개발한 오픈 소스 확장 라이브러리입니다. 이 라이브러리는 개별 인스턴스 단위의 절두체 컬링(Frustum culling), 정렬(Sorting), 가시성 관리(Visibility management), LOD(Level of Detail), BVH를 활용한 빠른 레이캐스팅 및 스키닝(Skinning) 기능을 제공합니다 [1-3]. 특히 수만 개의 스킨드 메시나 개별 애니메이션을 가진 객체들을 최소한의 드로우 콜로 렌더링할 수 있도록 설계되어 높은 프레임 레이트 유지를 돕습니다 [1, 4, 5].
-
-## 📖 구조화된 지식 (Synthesized Content)
-* **효율적인 데이터 구조와 참조 방식 (Indirection):**
-  InstancedMesh2는 렌더링할 인스턴스 인덱스를 관리하기 위해 `InstancedBufferAttribute`를 통한 간접 참조(Indirection) 방식을 사용합니다 [6]. 이를 통해 GPU로 데이터를 전송하기 전 속성 버퍼 전체를 재정렬할 필요 없이, 선택적 렌더링과 효율적인 컬링 및 정렬을 수행할 수 있습니다 [6]. 
-* **데이터 텍스처와 객체 핸들링 개선:**
-  인스턴스 변환 행렬과 데이터를 저장하기 위해 부분 업데이트(Partial updates)를 지원하는 `SquareDataTexture`를 활용합니다 [1, 6]. 또한 전체 인스턴스 개수에 맞춰 `Object3D`와 유사한 프록시 객체를 생성하므로, 사용자가 배열에서 직접 행렬을 추출하지 않고도 위치, 회전, 크기 등의 연산을 쉽게 처리할 수 있습니다 [7]. 객체를 숨길 때(가시성 관리)는 캐시 미스(Cache miss)를 방지하기 위해 해당 행렬을 배열의 끝으로 이동시키는 방식을 적용합니다 [7].
-* **스키닝(Skinning) 및 애니메이션 최적화:**
-  각각의 인스턴스가 서로 다른 애니메이션과 포즈를 가질 수 있습니다 [8]. 카메라 절두체 내에 위치한 인스턴스의 뼈대(Bones)만 업데이트하며, 카메라와의 거리에 따라 각 인스턴스의 애니메이션 FPS(0~60)를 조절할 수 있습니다 [1]. 또한 먼 거리에 있는 인스턴스는 불필요한 뼈대 계산을 생략하고 텍스처 업데이트의 렌더링 부하를 줄일 수 있습니다 [1].
-* **LOD 및 레이캐스팅 연동:**
-  `meshoptimizer`와 연계하여 지오메트리 LOD를 관리하며, 그림자에 대한 LOD 제어도 가능합니다 [1, 9]. 또한 Three.js 생태계의 `three-mesh-bvh`를 통합하여 수많은 인스턴스에 대해서도 빠르고 정확한 공간 인덱스(Spatial index) 기반 레이캐스팅과 절두체 컬링을 지원합니다 [2, 10].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** AI 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[InstancedMesh]], [[Frustum Culling]], [[Level of Detail (LOD)]], [[Skinned Mesh]], [[BVH (Bounding Volume Hierarchy)]]
-- **Projects/Contexts:** [[Three.js]]
-- **Contradictions/Notes:** 라이브러리 내에서 지원하는 `SquareDataTexture`의 뼈대 텍스처 부분 업데이트(Partial texture updates) 기능은 모바일 기기 및 Mozilla Firefox 브라우저 환경에서 속도가 느리게 작동할 수 있어, 특정 하드웨어나 브라우저에서는 이를 비활성화(또는 이중 버퍼링 구현 필요)해야 성능을 유지할 수 있습니다 [1, 11].
-
----
-*Last updated: 2026-04-19*
-- Raw Source: [[00_Raw/2026-04-20/InstancedMesh2 library.md]]
----
diff --git a/AI/Interaction to Next Paint (INP).md b/AI/Interaction to Next Paint (INP).md
deleted file mode 100644
index dd6971da..00000000
--- a/AI/Interaction to Next Paint (INP).md	
+++ /dev/null
@@ -1,48 +0,0 @@
----
-id: P-REINFORCE-AUTO-1BE349
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Interaction to Next Paint (INP)"
----
-
-# [[Interaction to Next Paint (INP)]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> INP(Interaction to Next Paint)는 웹 페이지의 전반적인 상호작용성(Interactivity)과 응답성(Responsiveness)을 측정하기 위해 2024년 Google이 공식 도입한 Core Web Vitals 지표입니다 [1-3]. 첫 번째 상호작용만 측정하던 기존의 FID(First Input Delay)와 달리, 페이지 방문 기간 동안 발생하는 모든 상호작용(클릭, 탭, 키 누름 등)의 전체 지연 시간을 측정하여 실제 사용자 경험을 더 정확하게 반영합니다 [4-6]. 사용자의 작업에 대해 즉각적인 시각적 피드백을 제공하는 것을 목표로 하며, 200밀리초(ms) 이하의 지연 시간을 기록해야 '좋음(Good)'으로 평가받을 수 있습니다 [5, 7].
-
-## 📖 구조화된 지식 (Synthesized Content)
-*   **도입 배경 및 영향:** 
-    INP는 2024년에 기존 Core Web Vitals 지표였던 First Input Delay (FID)를 공식적으로 대체했습니다 [1, 2]. FID가 첫 번째 상호작용의 이벤트 핸들러 시작 전 지연 시간만을 측정했던 반면, INP는 페이지 전체 수명 동안 발생하는 모든 상호작용을 추적하고 렌더링 지연까지 포함하여 측정합니다 [4-6]. 이 엄격해진 기준 변화로 인해 2024년 2월, 모바일 웹사이트들의 Core Web Vitals 통과율이 크게 하락하는 현상이 관찰되기도 했습니다 [1].
-
-*   **측정 및 산출 방식:** 
-    INP는 75백분위수(75th percentile)의 방문 데이터를 기준으로 계산됩니다 [8]. 페이지 내 상호작용이 50개 이하인 경우 가장 긴 상호작용 지연 시간을 INP로 간주하며, 상호작용이 50개를 초과할 경우 이상치(Outlier)의 영향을 줄이기 위해 50개 그룹당 가장 지연 시간이 긴 1개를 제외한 나머지 중 최댓값을 사용합니다 [8]. 
-    *   **평가 임계값:** 200ms 이하는 '좋음(Good)', 200ms 초과 500ms 이하는 '개선 필요(Needs improvement)', 500ms 초과는 '나쁨(Poor)'으로 분류됩니다 [5].
-    *   **브라우저 지원:** Chrome뿐만 아니라 Interop 2025 프로젝트를 통해 Firefox(버전 144부터 지원)와 Safari에서도 INP 측정 지표 구현 작업이 시작되었습니다 [9].
-
-*   **지연 시간의 세부 구성 요소 (Sub-parts):** 
-    사용자 상호작용의 전체 대기 시간은 크게 3단계로 나뉘며, Chrome DevTools를 통해 이 세부 정보(INP breakdown)를 확인할 수 있습니다 [4, 5, 10].
-    1.  **입력 지연 (Input delay):** 이벤트가 감지된 시점부터 이벤트 핸들러가 실행되기 전까지의 시간 [4, 5].
-    2.  **처리 시간 (Processing duration):** 이벤트 핸들러 코드가 실제로 실행되는 시간 [4]. 성능 병목이 가장 자주 발생하는 구간입니다 [10].
-    3.  **표시 지연 (Presentation delay):** 사용자 작업 이후 다음 프레임을 화면에 렌더링(페인트)할 때까지 걸리는 시간 [4].
-
-*   **최적화 전략:** 
-    INP를 최적화하기 위해서는 브라우저의 메인 스레드(Main thread) 차단을 최소화해야 합니다. 이를 위해 긴 작업(Long tasks)을 비동기 청크로 분할하고, 핵심 이벤트 핸들러의 우선순위를 높이며, 불필요한 JavaScript 지연 로드(Lazy load) 및 수동 이벤트 리스너(Passive event listeners) 사용, 레이아웃 스래싱(Layout thrashing) 감소 등의 전략이 필요합니다 [11-14]. Chrome DevTools의 성능 패널에 통합된 Long Animation Frames API를 활용하면 상호작용을 지연시키는 특정 스크립트와 그 원인을 직관적으로 파악할 수 있습니다 [15, 16].
-
-*   **특수 측정 사례 (텍스트 강조 표시):** 
-    웹 페이지에서 텍스트를 드래그하여 강조 표시(Highlighting)하는 행위도 일반적으로 INP 점수에 영향을 주는 사용자 상호작용으로 간주됩니다 [17]. 다만, 2025년 초 Chrome의 업데이트를 통해 사용자가 창의 가장자리에 도달하여 스크롤이 트리거되는 텍스트 강조 표시 상황에서는 INP 점수가 증가하지 않도록 측정 방식이 조정되었습니다 [17].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** AI 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[Core Web Vitals]], [[First Input Delay (FID)]], [[Long Animation Frames API]]
-- **Projects/Contexts:** [[Chrome User Experience Report (CrUX)]], [[Chrome DevTools]], [[Interop 2025]]
-- **Contradictions/Notes:** 초기 측정 방식에서는 모든 텍스트 강조 표시가 INP에 영향을 주었으나, 2025년 초 Chrome의 업데이트로 인해 스크롤을 동반하는 텍스트 강조 표시는 예외적으로 INP 지연 시간에 합산되지 않도록 변경되었습니다 [17].
-
----
-*Last updated: 2026-04-19*
-- Raw Source: [[00_Raw/2026-04-20/Interaction to Next Paint (INP).md]]
----
diff --git a/AI/Interface Segregation Principle.md b/AI/Interface Segregation Principle.md
deleted file mode 100644
index 25db9f4d..00000000
--- a/AI/Interface Segregation Principle.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-6A25D0
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Interface Segregation Principle"
----
-
-# [[Interface Segregation Principle]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** AI 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Interface Segregation Principle.md]]
----
diff --git a/AI/Interface-Segregation-Principle-in-TS.md b/AI/Interface-Segregation-Principle-in-TS.md
deleted file mode 100644
index 7f867bc2..00000000
--- a/AI/Interface-Segregation-Principle-in-TS.md
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-D46100
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Interface-Segregation-Principle-in-TS"
----
-
-# [[Interface-Segregation-Principle-in-TS]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** AI 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Interface-Segregation-Principle-in-TS.md]]
----
diff --git a/AI/Interop 2026.md b/AI/Interop 2026.md
deleted file mode 100644
index 40fb29f5..00000000
--- a/AI/Interop 2026.md	
+++ /dev/null
@@ -1,32 +0,0 @@
----
-id: P-REINFORCE-AUTO-36D047
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Interop 2026"
----
-
-# [[Interop 2026]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> Interop 2026은 웹 브라우저 간 코어 웹 바이탈(Core Web Vitals) 지원을 표준화하기 위한 후속 프로젝트로 언급된 제안입니다 [1]. 특히 파이어폭스(Firefox)나 사파리(Safari) 등에서 아직 지원이 계획되지 않은 누적 레이아웃 이동(Cumulative Layout Shift, CLS) 지표를 포함하기 위한 목적으로 제안되고 있습니다 [1].
-
-## 📖 구조화된 지식 (Synthesized Content)
-- **코어 웹 바이탈의 크로스 브라우저 지원 배경:** 2020년 구글이 발표한 코어 웹 바이탈은 오랫동안 크롬(Chrome) 전용 지표로 사용되었습니다 [1, 2]. 이 상황은 Interop 2025 프로젝트를 통해 파이어폭스와 사파리가 LCP(Largest Contentful Paint) 및 INP(Interaction to Next Paint) 지표 구현 작업을 시작하면서 변화하기 시작했습니다 [1].
-- **Interop 2026의 제안 사항:** 현재 진행 중인 브라우저 표준화 작업에는 누적 레이아웃 이동(CLS) 지표에 대한 지원이 계획되어 있지 않습니다 [1]. 이를 해결하기 위해 CLS 지표 지원을 Interop 2026에 포함시키자는 제안(proposal)이 나와 있는 상태입니다 [1].
-- **정보의 한계:** 소스에 관련 정보가 부족합니다. Interop 2026 프로젝트의 전체 범위, 구체적인 일정, CLS 외에 추가로 논의되는 웹 성능 지표 등에 대한 상세한 내용은 제공된 소스에 존재하지 않습니다.
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** AI 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[Core Web Vitals]], [[Cumulative Layout Shift]], [[Interop 2025]]
-- **Projects/Contexts:** [[크로스 브라우저 코어 웹 바이탈 지원 (Cross-browser support for Core Web Vitals)]]
-- **Contradictions/Notes:** 소스 내에서 Interop 2026은 확정된 프로젝트가 아니라 CLS 지표를 향후에 지원하기 위해 고려 중인 '제안' 단계로만 매우 짧게 언급되어 있습니다 [1].
-
----
-*Last updated: 2026-04-19*
-- Raw Source: [[00_Raw/2026-04-20/Interop 2026.md]]
----
diff --git a/AI/Interpolation and Extrapolation.md b/AI/Interpolation and Extrapolation.md
deleted file mode 100644
index 74fdb579..00000000
--- a/AI/Interpolation and Extrapolation.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-C3D464
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Interpolation and Extrapolation"
----
-
-# [[Interpolation and Extrapolation]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** AI 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Interpolation and Extrapolation.md]]
----
diff --git a/AI/InversifyJS.md b/AI/InversifyJS.md
deleted file mode 100644
index 265e6032..00000000
--- a/AI/InversifyJS.md
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-020B35
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - InversifyJS"
----
-
-# [[InversifyJS]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** AI 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/InversifyJS.md]]
----
diff --git a/AI/Irrational Games.md b/AI/Irrational Games.md
deleted file mode 100644
index 7a13e8c6..00000000
--- a/AI/Irrational Games.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-8F0A9E
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Irrational Games"
----
-
-# [[Irrational Games]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** AI 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Irrational Games.md]]
----
diff --git a/AI/Itô Calculus.md b/AI/Itô Calculus.md
deleted file mode 100644
index afa98168..00000000
--- a/AI/Itô Calculus.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-D65DD9
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Itô Calculus"
----
-
-# [[Itô Calculus]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** AI 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Itô Calculus.md]]
----
diff --git a/AI/J-curve  S-curve (AI 발전의 동학).md b/AI/J-curve  S-curve (AI 발전의 동학).md
deleted file mode 100644
index 7f1bbded..00000000
--- a/AI/J-curve  S-curve (AI 발전의 동학).md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-25FEC6
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - J-curve  S-curve (AI 발전의 동학)"
----
-
-# [[J-curve  S-curve (AI 발전의 동학)]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** AI 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/J-curve & S-curve (AI 발전의 동학).md]]
----
diff --git a/AI/JSON-Schema.md b/AI/JSON-Schema.md
deleted file mode 100644
index 3210abfd..00000000
--- a/AI/JSON-Schema.md
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-CF1F59
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - JSON-Schema"
----
-
-# [[JSON-Schema]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** AI 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/JSON-Schema.md]]
----
diff --git a/AI/Jailbreaking (탈옥).md b/AI/Jailbreaking (탈옥).md
deleted file mode 100644
index 4955b91d..00000000
--- a/AI/Jailbreaking (탈옥).md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-C6F5E9
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Jailbreaking (탈옥)"
----
-
-# [[Jailbreaking (탈옥)]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** AI 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Jailbreaking (탈옥).md]]
----
diff --git a/AI/Jenkins.md b/AI/Jenkins.md
deleted file mode 100644
index c5bcd1bd..00000000
--- a/AI/Jenkins.md
+++ /dev/null
@@ -1,32 +0,0 @@
----
-id: P-REINFORCE-AUTO-937A74
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Jenkins"
----
-
-# [[Jenkins]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-* **SonarQube와의 통합을 통한 품질 검사 자동화:** Jenkins는 SonarQube와 원활하게 통합될 수 있는 다양한 개발 도구 중 하나입니다 [1]. Jenkins와 같은 CI/CD 파이프라인에 SonarQube를 연동함으로써 개발자는 AI가 생성한 코드 등을 포함한 소스 코드에 대해 즉각적인 피드백을 받을 수 있습니다 [1, 2]. 이는 자동화된 품질 검사를 일상적인 개발 활동의 핵심 구성 요소로 유지하게 해줍니다 [2].
-* **Endor Labs 통합:** Jenkins는 소프트웨어 공급망 보안 플랫폼인 Endor Labs 시스템과 연동 가능한 통합(Integrations) 도구로도 활용됩니다 [3].
-* **정보 부족:** Jenkins의 아키텍처, 역사, 구체적인 기능 및 내부 메커니즘 등 루트 주제를 깊이 이해하는 데 필요한 상세 내용에 대해서는 소스에 관련 정보가 부족합니다.
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** AI 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[SonarQube]], [[CI/CD Pipelines]], [[Endor Labs]]
-- **Projects/Contexts:** [[Automated Code Review]], [[Software Supply Chain Security]]
-- **Contradictions/Notes:** 소스에 관련 정보가 부족합니다. 소스 문헌들은 Jenkins의 단독적인 기능이나 특성을 설명하지 않으며, 오직 다른 코드 분석/보안 도구(SonarQube, Endor Labs)가 연동할 수 있는 CI/CD 플랫폼의 예시로만 언급하고 있습니다.
-
----
-*Last updated: 2026-04-19*
-- Raw Source: [[00_Raw/2026-04-20/Jenkins.md]]
----
diff --git a/AI/KTO (Kahneman-Tversky Optimization).md b/AI/KTO (Kahneman-Tversky Optimization).md
deleted file mode 100644
index 6b3f793b..00000000
--- a/AI/KTO (Kahneman-Tversky Optimization).md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-085B91
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - KTO (Kahneman-Tversky Optimization)"
----
-
-# [[KTO (Kahneman-Tversky Optimization)]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** AI 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/KTO (Kahneman-Tversky Optimization).md]]
----
diff --git a/AI/Ken Levine-Design-Philosophy.md b/AI/Ken Levine-Design-Philosophy.md
deleted file mode 100644
index 2fe2f556..00000000
--- a/AI/Ken Levine-Design-Philosophy.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-DE50FF
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Ken Levine-Design-Philosophy"
----
-
-# [[Ken Levine-Design-Philosophy]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** AI 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Ken Levine-Design-Philosophy.md]]
----
diff --git a/AI/Keyof-Operator.md b/AI/Keyof-Operator.md
deleted file mode 100644
index 663515f1..00000000
--- a/AI/Keyof-Operator.md
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-D5D6DC
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Keyof-Operator"
----
-
-# [[Keyof-Operator]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** AI 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Keyof-Operator.md]]
----
diff --git a/AI/Kinematic-Modeling.md b/AI/Kinematic-Modeling.md
deleted file mode 100644
index 8ba31616..00000000
--- a/AI/Kinematic-Modeling.md
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-47456C
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Kinematic-Modeling"
----
-
-# [[Kinematic-Modeling]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** AI 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Kinematic-Modeling.md]]
----
diff --git a/AI/Knowledge-Representation-in-AI.md b/AI/Knowledge-Representation-in-AI.md
deleted file mode 100644
index 1c7c05a2..00000000
--- a/AI/Knowledge-Representation-in-AI.md
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-F03CAF
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Knowledge-Representation-in-AI"
----
-
-# [[Knowledge-Representation-in-AI]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** AI 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Knowledge-Representation-in-AI.md]]
----
diff --git a/AI/LLM Alignment (LLM 정렬).md b/AI/LLM Alignment (LLM 정렬).md
deleted file mode 100644
index da75e1fd..00000000
--- a/AI/LLM Alignment (LLM 정렬).md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-E3A7CD
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - LLM Alignment (LLM 정렬)"
----
-
-# [[LLM Alignment (LLM 정렬)]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** AI 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/LLM Alignment (LLM 정렬).md]]
----
diff --git a/AI/LLM Hallucination (언어 모델 환각).md b/AI/LLM Hallucination (언어 모델 환각).md
deleted file mode 100644
index f5717e5c..00000000
--- a/AI/LLM Hallucination (언어 모델 환각).md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-3DFBCC
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - LLM Hallucination (언어 모델 환각)"
----
-
-# [[LLM Hallucination (언어 모델 환각)]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** AI 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/LLM Hallucination (언어 모델 환각).md]]
----
diff --git a/AI/LLM.md b/AI/LLM.md
deleted file mode 100644
index 3aae01a2..00000000
--- a/AI/LLM.md
+++ /dev/null
@@ -1,37 +0,0 @@
----
-id: P-REINFORCE-AUTO-D415E3
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - LLM"
----
-
-# [[LLM]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> LLM(대규모 언어 모델)은 코드의 문맥과 의미를 이해하고, 인간이 놓칠 수 있는 복잡한 패턴을 감지하며 더욱 정교한 피드백을 제공하는 데 활용되는 인공지능 기술입니다 [1, 2]. 기존의 단순 규칙 기반 정적 분석 도구와 달리, LLM은 코드 컨텍스트와 비즈니스 로직의 결함을 파악하고 맥락에 맞는 자동 수정(AutoFix) 제안을 생성하는 데 강력한 성능을 보여줍니다 [3-5]. 현대 소프트웨어 개발 환경에서 LLM은 코드 복잡도 분석, 보안 취약점 탐지, 그리고 상용구(boilerplate) 코드 작성 등의 작업에 폭넓게 도입되어 개발자의 전반적인 생산성을 향상시키고 있습니다 [2, 6, 7].
-
-## 📖 구조화된 지식 (Synthesized Content)
-* **정적 분석(SAST) 및 자동 수정에서의 활용**
-  AI-native SAST 플랫폼(예: Corgea, Fortify Aviator 등)은 핵심 스캐닝 엔진에 LLM을 직접 결합하여, 단순한 문자열 패턴 매칭을 넘어 코드의 문맥과 의도를 깊이 있게 파악합니다 [4, 8]. 이를 통해 기존의 패턴 기반 스캐너들이 놓치기 쉬운 복잡한 비즈니스 로직의 결함과 인증 관련 문제 등을 효과적으로 찾아낼 수 있습니다 [3]. 또한, 탐지된 보안 문제나 코드 스멜(Code smells)에 대해 LLM을 활용하여 실제 코드 베이스에 적용 가능한 자동 수정(AutoFix) 패치를 생성 및 제안합니다 [5, 9].
-
-* **코드 복잡도 분석 및 버그 예측 모델**
-  LLM은 제어 흐름이나 순환 복잡도(Cyclomatic Complexity)를 직접 수치로 계산하지는 않지만, 조건문, 루프, 예외 처리 구조 및 코드 블록의 중첩 수준 등을 해석하여 복잡도와 유사한 패턴을 인지해냅니다 [7]. 이를 기반으로 자연어 기반의 구체적인 리팩토링 권장 사항을 개발자에게 제시할 수 있습니다 [10]. 또한 사전 학습된 LLM을 버그 예측에 도입할 경우, 복잡한 피처 엔지니어링 없이도 코드의 의미 자체를 이해하여 기존 머신러닝 기반 분류 모델보다 훨씬 높은 정확도로 잠재적 버그와 구성 논리 오류를 예측할 수 있는 가능성을 제공합니다 [2, 11].
-
-* **개발자 생산성 향상과 내재된 한계점**
-  개발자들은 LLM을 사용하여 반복적인 상용구(boilerplate) 코드를 신속하게 자동 생성하거나, 익숙하지 않은 프로그래밍 언어 및 프레임워크의 구조를 빠르게 파악함으로써 초기 작업 속도와 생산성을 획기적으로 높일 수 있습니다 [6, 12, 13]. 그러나 LLM은 여러 저장소(cross-repository)에 걸친 광범위한 문맥이나 깊이 얽힌 레거시 코드베이스를 완벽히 이해하는 데에는 명확한 한계를 보입니다 [14, 15]. 따라서 LLM이 생성한 코드는 환각(Hallucination)으로 인한 잘못된 함수 사용이나 보안 취약점을 포함할 위험성이 있으므로, 자동 생성된 패치나 코드는 반드시 품질 게이트(Quality gates) 검증과 인간의 꼼꼼한 리뷰 절차를 병행해야 합니다 [16-18].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** AI 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[SAST]], [[Static Analysis]], [[AI Code Review]]
-- **Projects/Contexts:** [[Corgea]], [[GitHub Copilot]], [[Snyk Code]], [[DeepCode AI]]
-- **Contradictions/Notes:** 대다수의 개발자들은 LLM이 반복적인 상용구 코드 작성을 줄여주고 낯선 도메인에서의 작업 효율을 크게 향상시킨다고 긍정적으로 평가하지만 [6, 13, 19], 반대로 대규모의 복잡한 레거시 코드베이스나 이전에 해결된 적 없는 새로운 문제(Frontier)에서는 LLM의 효과가 무의미해지며, 잦은 환각(Hallucination)이나 미세한 오류로 인해 오히려 심각한 디버깅 시간을 낭비하게 만든다고 강력히 반대(또는 경계)하는 의견도 존재합니다 [14, 20-22].
-
----
-*Last updated: 2026-04-19*
-- Raw Source: [[00_Raw/2026-04-20/LLM.md]]
----
diff --git a/AI/LOD.md b/AI/LOD.md
deleted file mode 100644
index 1fdc6ae3..00000000
--- a/AI/LOD.md
+++ /dev/null
@@ -1,33 +0,0 @@
----
-id: P-REINFORCE-AUTO-D34DEB
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - LOD"
----
-
-# [[LOD]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> LOD(Level of Detail)는 카메라와의 거리에 따라 고해상도(High-poly) 모델을 저해상도(Low-poly) 버전으로 동적으로 교체하여 렌더링 성능을 향상시키는 기법이다 [1, 2]. 대규모 3D 씬에서 먼 거리에 있는 객체의 기하학적 복잡도를 극적으로 낮추거나 단순한 평면(Impostor)으로 대체하여 불필요한 GPU 연산을 방지한다 [2, 3]. 이 시스템을 적절히 활용하면 프레임 속도 안정화에 기여하고 전체 씬의 폴리곤 수 및 GPU 처리량을 획기적으로 줄일 수 있다 [1, 4].
-
-## 📖 구조화된 지식 (Synthesized Content)
-- **LOD의 작동 원리 및 성능 이점:** 렌더링 엔진은 매 프레임마다 카메라와 객체 간의 거리를 측정하여 미리 정의된 적절한 LOD 수준으로 모델을 자동 전환한다 [5]. 일반적으로 가장 가까운 뷰(예: 50,000 폴리곤), 중간 거리, 원거리, 극단적 원거리(500 폴리곤 임포스터) 등 3~5단계의 LOD를 구성하는 방식이 사용된다 [5, 6]. 이 동적 스위칭은 GPU 프래그먼트 처리를 60~75% 절감하고 평균 폴리곤 수를 60~80% 감소시켜 프레임 속도를 크게 높인다 [4, 5].
-- **Instancing과의 결합 및 스킨드 메쉬 최적화:** 기본적으로 지오메트리 LOD는 각 LOD 단계별로 별도의 인스턴스 스택을 구성하지 않는 한 인스턴싱(Instancing)과 함께 사용하기 까다롭다 [7]. 그러나 `InstancedMesh2`와 같은 확장 라이브러리를 사용하면 개별 인스턴스에 대해서도 LOD 관리가 가능하다 [8, 9]. 애니메이션이 적용된 스킨드 메쉬(Skinned Mesh)의 경우, 기하학적 폴리곤뿐만 아니라 뼈대(Bone) 연산까지 LOD 단계에 맞춰 줄이고 관련 텍스처 크기(예: 32x32에서 8x8 해상도로 축소)를 대폭 삭감함으로써 렌더링 부하를 최소화할 수 있다 [10-12].
-- **팝핑(Popping) 현상 극복 및 CAD 렌더링 적용:** 단계별로 모델을 교체하는 이산형(Discrete) LOD 시스템은 전환 시 모델이 튀어 보이는 '팝핑' 현상이 발생할 수 있으며, 이는 정밀한 시각화가 필요한 CAD 환경에서는 부적합할 수 있다 [13]. 이를 해결하기 위해 동적으로 폴리곤을 단순화하는 연속적 LOD(Continuous LOD) 기법이나, 디더(Dither) 패턴을 활용해 두 단계의 LOD 모델을 겹쳐서 렌더링하여 부드럽게 전환하는 '디더링된 LOD 블렌드(Dithered LOD Blend)' 기술이 사용되기도 한다 [14].
-- **사용 시 주의사항 및 병목 해결의 순서:** 런타임에 동적으로 단순화된 지오메트리를 생성하여 LOD로 할당하는 방식은 엔진에 과도한 오버헤드를 유발하여 오히려 렌더링 성능을 악화시킬 수 있다 [15-17]. 따라서 모델 익스포트 단계에서 정적인 여러 LOD 단계를 미리 생성해 두는(Pre-created) 방식이 효과적이다 [18]. 또한, LOD는 애플리케이션이 드로우 콜(Draw call) 병목이 아닌 삼각형 처리 수(Triangle count) 한계에 도달했을 때 마지막 수단으로 고려해야 하는 최적화 기법이다 [17, 19, 20].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** AI 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[Frustum Culling]], [[Billboard impostors]], [[InstancedMesh]], [[Draw Calls]], [[Mipmaps]]
-- **Projects/Contexts:** [[Three.js]], [[React Three Fiber]] (Drei 라이브러리의 `<Detailed />` 컴포넌트 [1]), [[InstancedMesh2]], [[CAD Rendering]]
-- **Contradictions/Notes:** 소스에 따르면 LOD는 거리에 따라 렌더링 부하를 줄여주는 강력한 툴이지만, 런타임에 지오메트리 버전을 동적으로 연산하여 생성하려는 시도는 오히려 큰 성능 저하를 초래할 수 있으므로 상황(정적 자산 중심)에 맞게 적용해야 한다고 지적한다 [16-18].
-
----
-*Last updated: 2026-04-19*
-- Raw Source: [[00_Raw/2026-04-20/LOD.md]]
----
diff --git a/AI/Language-Acquisition-Apps.md b/AI/Language-Acquisition-Apps.md
deleted file mode 100644
index dd8ed69d..00000000
--- a/AI/Language-Acquisition-Apps.md
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-6239D3
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Language-Acquisition-Apps"
----
-
-# [[Language-Acquisition-Apps]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** AI 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Language-Acquisition-Apps.md]]
----
diff --git a/AI/Large-Scale-Enterprise-Frontend-Architectures.md b/AI/Large-Scale-Enterprise-Frontend-Architectures.md
deleted file mode 100644
index bdf8d42a..00000000
--- a/AI/Large-Scale-Enterprise-Frontend-Architectures.md
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-69DDE6
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Large-Scale-Enterprise-Frontend-Architectures"
----
-
-# [[Large-Scale-Enterprise-Frontend-Architectures]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** AI 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Large-Scale-Enterprise-Frontend-Architectures.md]]
----
diff --git a/AI/Large-Scale-Knowledge-Integration.md b/AI/Large-Scale-Knowledge-Integration.md
deleted file mode 100644
index c56c0fba..00000000
--- a/AI/Large-Scale-Knowledge-Integration.md
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-E04C5A
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Large-Scale-Knowledge-Integration"
----
-
-# [[Large-Scale-Knowledge-Integration]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** AI 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Large-Scale-Knowledge-Integration.md]]
----
diff --git a/AI/Large-scale-Frontend-Architecture.md b/AI/Large-scale-Frontend-Architecture.md
deleted file mode 100644
index b689d7b5..00000000
--- a/AI/Large-scale-Frontend-Architecture.md
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-06FE72
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Large-scale-Frontend-Architecture"
----
-
-# [[Large-scale-Frontend-Architecture]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** AI 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Large-scale-Frontend-Architecture.md]]
----
diff --git a/AI/Large-scale-TypeScript-Monorepos.md b/AI/Large-scale-TypeScript-Monorepos.md
deleted file mode 100644
index 3f3c1e1c..00000000
--- a/AI/Large-scale-TypeScript-Monorepos.md
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-EE05DB
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Large-scale-TypeScript-Monorepos"
----
-
-# [[Large-scale-TypeScript-Monorepos]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** AI 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Large-scale-TypeScript-Monorepos.md]]
----
diff --git a/AI/Largest Contentful Paint (LCP).md b/AI/Largest Contentful Paint (LCP).md
deleted file mode 100644
index 3a9ea31d..00000000
--- a/AI/Largest Contentful Paint (LCP).md	
+++ /dev/null
@@ -1,38 +0,0 @@
----
-id: P-REINFORCE-AUTO-C57B92
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Largest Contentful Paint (LCP)"
----
-
-# [[Largest Contentful Paint (LCP)]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> LCP(Largest Contentful Paint)는 웹 페이지의 로딩 성능을 측정하는 구글의 핵심 웹 바이탈(Core Web Vitals) 지표 중 하나로, 브라우저가 화면에 가장 큰 콘텐츠를 렌더링하는 데 걸리는 시간을 의미합니다 [1, 2]. 이는 사용자가 페이지의 주요 콘텐츠를 볼 수 있게 되는 시점을 나타내는 대리 지표로 사용됩니다 [2]. 구글은 좋은 사용자 경험을 위해 LCP를 2.5초 미만으로 유지할 것을 권장하며, 4.0초를 초과하면 불량한 것으로 간주합니다 [3, 4].
-
-## 📖 구조화된 지식 (Synthesized Content)
-* **LCP의 역할 및 측정 기준:**
-  LCP는 초기 시각적 응답 속도를 측정하며, 페이지 로드 시 가장 넓은 픽셀 영역을 차지하는 텍스트나 이미지 요소의 렌더링 완료 시점을 기준으로 합니다 [2, 5]. 데스크톱 및 모바일 환경의 실제 사용자 데이터를 기반으로 한 Chrome User Experience Report(CrUX)에서 75백분위수 방문자의 경험을 기준으로 평가됩니다 [6, 7].
-* **성능 최적화 및 디버깅:**
-  LCP를 개선하기 위해서는 서버 응답 시간 최적화, 사전 연결(preconnect), 주요 리소스 사전 로드(preload), 렌더링을 차단하는 CSS/JS의 감소가 필요합니다 [8]. 특히 LCP에 영향을 미치는 주요 이미지에는 `fetchpriority='high'` 속성을 부여하여 로딩 우선순위를 높이는 것이 권장됩니다 [9]. 개발자는 Chrome DevTools의 'Performance' 패널과 'Live metrics' 화면을 통해 로컬 및 실제 필드 데이터의 LCP를 실시간으로 확인하고, 지표에 영향을 미치는 LCP 요소를 직접 추적할 수 있습니다 [6, 9-11].
-* **최근 측정 및 지표 업데이트 (2025년 기준):**
-  * **LCP Subparts:** 2025년 2월부터 CrUX는 LCP를 구성하는 하위 요소(subparts) 데이터를 제공하여, 느린 서버 응답인지, 이미지 다운로드 지연인지 등 LCP 지연 원인을 세분화하여 파악할 수 있게 되었습니다 [12]. 이 하위 요소 데이터는 가장 큰 콘텐츠 요소가 이미지인 방문에 한해 적용됩니다 [13].
-  * **Cross-origin 이미지 측정 개선:** 기존에 Chrome은 `Timing-Allow-Origin` 응답 헤더가 없는 크로스 오리진 이미지의 경우 이미지가 화면에 표시되기 전 다운로드된 시간만 보고했으나, 2025년 2월부터 실제 렌더링 시간을 정확히 반영하도록 측정 방식을 변경했습니다 [14].
-  * **렌더링 시간의 세분화:** Chrome은 LCP 페인트 타이밍을 브라우저 렌더링이 완료된 시간(`paintTime`)과 실제 픽셀이 화면에 나타난 시간(`presentationTime`)으로 세분화하여 보고하기 시작했습니다 [15].
-  * **브라우저 지원 확대 및 Soft Navigation:** Interop 2025 프로젝트를 통해 기존에 Chrome에 국한되었던 LCP 지표가 Firefox 및 Safari(Technology Preview 버전)에서도 지원되기 시작했습니다 [16]. 또한 현재 LCP는 초기 네비게이션 시에만 로드 시간을 측정하지만, 2025년 8월 Chrome은 SPA(Single-Page Application)와 같은 Soft Navigation 환경에서도 LCP 로드 시간을 측정하기 위한 새로운 Origin Trial을 시작했습니다 [17].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** AI 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[Core Web Vitals]], [[Chrome User Experience Report (CrUX)]], [[Interaction to Next Paint (INP)]], [[Cumulative Layout Shift (CLS)]], [[Soft Navigation]]
-- **Projects/Contexts:** [[Interop 2025]], [[Chrome DevTools]], [[Lighthouse]]
-- **Contradictions/Notes:** 소스에 따르면 현재 LCP 지표는 웹 사이트의 초기 네비게이션(initial navigation)에 대한 로드 시간만을 측정하기 때문에, URL 변경 시 전체 새로고침이 일어나지 않는 Soft Navigation 기반의 단일 페이지 애플리케이션(SPA) 운영자와 개발자에게는 성능 분석에 상당한 사각지대가 발생한다는 한계가 지적됩니다 [17].
-
----
-*Last updated: 2026-04-19*
-- Raw Source: [[00_Raw/2026-04-20/Largest Contentful Paint (LCP).md]]
----
diff --git a/AI/Lerna-Legacy-Management.md b/AI/Lerna-Legacy-Management.md
deleted file mode 100644
index 40550359..00000000
--- a/AI/Lerna-Legacy-Management.md
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-0CDF64
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Lerna-Legacy-Management"
----
-
-# [[Lerna-Legacy-Management]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** AI 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Lerna-Legacy-Management.md]]
----
diff --git a/AI/Level Design Architecture.md b/AI/Level Design Architecture.md
deleted file mode 100644
index fdf64fe0..00000000
--- a/AI/Level Design Architecture.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-E822FE
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Level Design Architecture"
----
-
-# [[Level Design Architecture]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** AI 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Level Design Architecture.md]]
----
diff --git a/AI/Level Design Automation.md b/AI/Level Design Automation.md
deleted file mode 100644
index fa042bad..00000000
--- a/AI/Level Design Automation.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-1A2A10
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Level Design Automation"
----
-
-# [[Level Design Automation]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** AI 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Level Design Automation.md]]
----
diff --git a/AI/Level of Detail (LOD).md b/AI/Level of Detail (LOD).md
deleted file mode 100644
index 3e2cb83b..00000000
--- a/AI/Level of Detail (LOD).md	
+++ /dev/null
@@ -1,35 +0,0 @@
----
-id: P-REINFORCE-AUTO-B9CF3B
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Level of Detail (LOD)"
----
-
-# [[Level of Detail (LOD)]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> LOD(Level of Detail)는 카메라와의 거리에 따라 객체의 기하학적 복잡도(폴리곤 수)를 동적으로 조절하여 렌더링 성능을 최적화하는 기법입니다 [1-3]. 가까운 객체에는 고해상도(High-poly) 모델을 보여주고, 멀리 있는 객체는 저해상도(Low-poly) 모델이나 단순한 평면(Impostor)으로 교체하여 GPU 연산량을 줄입니다 [1, 2, 4, 5]. 이를 통해 화면의 시각적 품질을 유지하면서도 대규모 씬의 프레임 속도를 크게 개선할 수 있습니다 [6, 7].
-
-## 📖 구조화된 지식 (Synthesized Content)
-- **성능 개선 효과:** Three.js는 매 프레임 카메라와 객체 사이의 거리를 측정하여 적절한 폴리곤 밀도를 가진 메쉬로 자동 전환합니다 [3, 7, 8]. 대규모 씬에서 LOD를 적용하면 GPU 프래그먼트 처리량을 60~75% 감소시키고, 평균 폴리곤 수를 60~80% 줄일 수 있으며 [3, 7], 프레임 레이트를 30~40% 향상시킬 수 있습니다 [6]. 
-- **LOD 단계의 구성:** 일반적으로 3~5단계의 LOD 버전을 사전에 생성하여 사용합니다. 예를 들어, 근접 뷰용 5만 개(Hero), 중간 거리용 1만 5천 개, 배경용 5천 개, 그리고 극한의 거리를 위한 500개의 임포스터(Impostor) 메쉬로 구성하는 방식입니다 [4, 7]. 거리가 먼 객체는 드로우 콜과 삼각형 수를 줄이기 위해 질감이 입혀진 단일 평면(Billboard Impostor)으로 대체되기도 합니다 [2, 5].
-- **확장된 LOD 적용:** LOD 개념은 기하학적 메쉬뿐만 아니라 다른 렌더링 요소에도 적용됩니다. 애니메이션 최적화 시 뼈대(Bone)와 관련된 연산이나 텍스처 크기를 거리에 따라 줄이거나 [9-12], 텍스처 샘플링을 위해 해상도 피라미드를 구성하는 밉맵(Mipmaps) 기능도 일종의 거리 기반 디테일 조절 기법입니다 [13].
-- **성능적 트레이드오프 및 한계:** LOD 시스템은 보이지 않는 메쉬 레벨까지 모두 GPU 메모리에 유지해야 하므로 메모리 사용량이 증가합니다 [14]. 또한 매 프레임 거리를 계산하고 메쉬를 교체하는 작업이 개별 메쉬마다 CPU 오버헤드를 발생시킵니다 [8].
-- **LOD 적용의 적합성:** 장면 최적화 시 LOD는 드로우 콜(Draw Call) 병목 현상을 해결해 주지는 않습니다. 따라서 수천 개의 고유 요소를 렌더링하는 경우 드로우 콜 병목이 먼저 발생하므로 LOD가 성능 향상에 기여하지 못할 수 있습니다 [15]. LOD는 삼각형 수(예: 600만 개 이상)가 너무 많아 GPU가 한계에 도달했을 때 효과적이며, 거대한 오픈 월드나 매우 상세한 모델이 없는 한 후순위로 고려해야 할 최적화 기법입니다 [16-18].
-- **구현 방식:** Three.js에서는 `THREE.LOD` 객체를 사용하여 구현하며 [7], React Three Fiber에서는 Drei 라이브러리의 `<Detailed />` 컴포넌트를 통해 간편하게 설정할 수 있습니다 [1, 19]. InstancedMesh2 라이브러리 등을 통해 인스턴싱 기술과 LOD를 함께 활용하기도 합니다 [11, 20-22]. 런타임에 동적으로 모델을 단순화(Simplify)하여 LOD를 생성하는 것은 오버헤드를 유발하므로, 익스포트 단계에서 미리 LOD 메쉬를 만들어두는 것이 권장됩니다 [16, 23, 24].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** AI 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[Draw Calls]], [[Impostor]], [[InstancedMesh]], [[Frustum Culling]], [[Mipmaps]]
-- **Projects/Contexts:** [[Three.js]], [[React Three Fiber]], [[InstancedMesh2]]
-- **Contradictions/Notes:** LOD 기술이 항상 성능 향상을 가져오는 것은 아닙니다. 만약 애플리케이션이 드로우 콜 과부하 상태(Draw call bound)라면 LOD를 적용해도 드로우 콜 자체가 줄지 않으므로 성능이 오히려 약간 저하될 수 있으며, 메모리 부하와 교체 연산 오버헤드만 추가될 위험이 있습니다 [8, 14, 15].
-
----
-*Last updated: 2026-04-19*
-- Raw Source: [[00_Raw/2026-04-20/Level of Detail (LOD).md]]
----
diff --git a/AI/Level-Design-Automation.md b/AI/Level-Design-Automation.md
deleted file mode 100644
index 787fcaa7..00000000
--- a/AI/Level-Design-Automation.md
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-7DF19B
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Level-Design-Automation"
----
-
-# [[Level-Design-Automation]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** AI 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Level-Design-Automation.md]]
----
diff --git a/AI/Linear Representation Hypothesis (선형 표현 가설).md b/AI/Linear Representation Hypothesis (선형 표현 가설).md
deleted file mode 100644
index 890000df..00000000
--- a/AI/Linear Representation Hypothesis (선형 표현 가설).md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-CEDE85
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Linear Representation Hypothesis (선형 표현 가설)"
----
-
-# [[Linear Representation Hypothesis (선형 표현 가설)]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** AI 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Linear Representation Hypothesis (선형 표현 가설).md]]
----
diff --git a/AI/Live Service Game Design.md b/AI/Live Service Game Design.md
deleted file mode 100644
index 5b36a549..00000000
--- a/AI/Live Service Game Design.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-84B088
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Live Service Game Design"
----
-
-# [[Live Service Game Design]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** AI 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Live Service Game Design.md]]
----
diff --git a/AI/LiveOps Management.md b/AI/LiveOps Management.md
deleted file mode 100644
index c74ab2e8..00000000
--- a/AI/LiveOps Management.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-79CEB3
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - LiveOps Management"
----
-
-# [[LiveOps Management]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** AI 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/LiveOps Management.md]]
----
diff --git a/AI/LoRA (Low-Rank Adaptation).md b/AI/LoRA (Low-Rank Adaptation).md
deleted file mode 100644
index ee8d6745..00000000
--- a/AI/LoRA (Low-Rank Adaptation).md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-3C77A7
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - LoRA (Low-Rank Adaptation)"
----
-
-# [[LoRA (Low-Rank Adaptation)]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** AI 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/LoRA (Low-Rank Adaptation).md]]
----
diff --git a/AI/Locus of Control.md b/AI/Locus of Control.md
deleted file mode 100644
index 96fa72c7..00000000
--- a/AI/Locus of Control.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-83F003
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Locus of Control"
----
-
-# [[Locus of Control]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** AI 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Locus of Control.md]]
----
diff --git a/AI/Locus-of-Control.md b/AI/Locus-of-Control.md
deleted file mode 100644
index 2293abab..00000000
--- a/AI/Locus-of-Control.md
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-C947BF
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Locus-of-Control"
----
-
-# [[Locus-of-Control]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** AI 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Locus-of-Control.md]]
----
diff --git a/AI/Long Animation Frames API.md b/AI/Long Animation Frames API.md
deleted file mode 100644
index 04a6aec1..00000000
--- a/AI/Long Animation Frames API.md	
+++ /dev/null
@@ -1,32 +0,0 @@
----
-id: P-REINFORCE-AUTO-2A8383
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Long Animation Frames API"
----
-
-# [[Long Animation Frames API]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> Long Animation Frames API는 사용자 상호작용을 지연시키는 스크립트를 식별하고 세부 정보를 제공하는 데 사용되는 웹 성능 API입니다 [1]. Chrome 브라우저에서 INP(Interaction to Next Paint) 지표 측정을 위한 계측(instrumentation) 역할을 하여, 특정 상호작용 중에 실행된 자바스크립트 목록을 제공합니다 [2]. 이를 통해 개발자는 열악한 사용자 경험을 유발하는 스크립트와 함수를 효과적으로 탐지하고 최적화할 수 있습니다 [2].
-
-## 📖 구조화된 지식 (Synthesized Content)
-* **상호작용 처리 시간 및 스크립트 식별:** 이 API는 사용자의 입력(클릭, 탭, 포인터 등)에 대한 직접적 또는 간접적인 결과로 실행된 이벤트 리스너나 콜백 등의 스크립트 목록을 식별하게 해줍니다 [2]. Chrome DevTools에서 INP 값을 분석할 때, 이 API 덕분에 상호작용 처리 시간에 기여한 자바스크립트 코드의 상세 목록을 콘솔에서 확인할 수 있습니다 [2].
-* **성능 모니터링 도구에서의 활용:** DebugBear와 같은 웹 성능 모니터링 제품은 Long Animation Frames API에서 얻은 데이터를 활용하여 사용자 상호작용을 지연시키는 스크립트를 시각화합니다 [1]. 이를 통해 각 스크립트를 파비콘, 실행 이유에 대한 설명, 그리고 스크립팅 작업과 레이아웃 작업의 세부 항목으로 분류하여 표시할 수 있습니다 [1].
-* **INP(Interaction to Next Paint) 문제 해결:** 웹 사이트의 반응성을 측정하는 핵심 지표인 INP의 하위 요소 중 '처리 시간(Processing duration)'의 지연 원인을 분석할 때 매우 중요하게 활용됩니다 [2, 3].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** AI 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[INP (Interaction to Next Paint)]], [[Chrome DevTools]], [[Web Performance]]
-- **Projects/Contexts:** 사용자 상호작용 병목 현상을 파악하기 위한 [[Chrome DevTools]] 성능 패널 및 [[DebugBear]] 웹 성능 모니터링 대시보드
-- **Contradictions/Notes:** 소스에 모순되는 내용은 존재하지 않으며, 이 API는 웹 성능 분석 및 서드파티 모니터링 서비스에서 자바스크립트 실행 지연을 식별하는 주요 수단으로 일관되게 설명되고 있습니다.
-
----
-*Last updated: 2026-04-19*
-- Raw Source: [[00_Raw/2026-04-20/Long Animation Frames API.md]]
----
diff --git a/AI/Long Tasks.md b/AI/Long Tasks.md
deleted file mode 100644
index 24e1ad36..00000000
--- a/AI/Long Tasks.md	
+++ /dev/null
@@ -1,39 +0,0 @@
----
-id: P-REINFORCE-AUTO-183DC1
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Long Tasks"
----
-
-# [[Long Tasks]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 롱 태스크(Long Tasks)는 브라우저의 메인 스레드를 50ms 이상 장시간 차단하는 자바스크립트 연산 등의 CPU 처리 작업을 의미합니다 [1]. 이러한 작업은 짧은 여러 개의 작업보다 사용자 상호작용(Interaction)을 훨씬 더 지연시키며, 웹사이트를 느리게 느껴지게 만드는 주된 원인이 됩니다 [2].
-
-## 📖 구조화된 지식 (Synthesized Content)
-- **정의 및 성능에 미치는 영향:** 
-  롱 태스크는 브라우저의 메인 스레드를 50밀리초(ms) 이상 차단하는 자바스크립트 연산을 말합니다 [1]. 브라우저의 CPU 처리 작업 중 롱 태스크는 사용자 상호작용을 처리하는 것을 방해하여 응답성을 지연시킵니다 [2]. 이는 사용자 경험을 저하시키며, 구글의 Core Web Vitals 지표 중 하나인 INP(Interaction to Next Paint) 점수를 악화시키는 주요 원인이 됩니다 [1, 3].
-- **식별 및 모니터링 방법:** 
-  개발자는 Chrome DevTools의 Performance(성능) 패널을 통해 롱 태스크를 발견할 수 있습니다. 성능 프로파일링 시 긴 시간이 소요된 Task에는 빨간색 삼각형 경고가 표시되어 성능 병목 현상이 발생했음을 알립니다 [4, 5]. 또한 Long Animation Frames API를 활용하여 사용자 상호작용을 지연시키는 특정 스크립트를 식별하고 분석할 수도 있습니다 [6, 7].
-- **최적화 및 해결 전략:** 
-  상호작용 응답성을 개선하려면 롱 태스크를 쪼개어 브라우저가 렌더링 및 입력을 처리할 시간을 확보해야 합니다 [1]. 제공된 소스에서 권장하는 해결 방법은 다음과 같습니다.
-  - **작업 분할(Task Splitting):** 무거운 자바스크립트 함수를 더 작은 비동기 청크(async chunks)로 나눕니다 [1].
-  - **Scheduler API 사용:** `scheduler.yield()`와 같은 메서드를 사용하여 작업 중간에 브라우저 스케줄러로 제어권을 넘겨(yield) 사용자 상호작용을 먼저 처리하게 한 뒤 남은 작업을 계속 진행합니다 [2]. 
-  - **메인 스레드 오프로딩:** Web Workers를 활용하여 무거운 로직을 메인 스레드에서 분리하여 실행합니다 [1, 8].
-  - **스케줄링 및 지연 로딩:** `requestIdleCallback`을 사용하여 중요도가 낮은 작업의 실행을 미루거나, 중요하지 않은 자바스크립트의 로딩을 지연(defer) 및 지연 로딩(lazy load) 처리합니다 [1, 9].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** AI 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[Interaction to Next Paint (INP)]], [[Main Thread]], [[Scheduler API]], [[Chrome DevTools]]
-- **Projects/Contexts:** [[Core Web Vitals]], [[Web Performance Optimization]]
-- **Contradictions/Notes:** 소스 간의 모순된 내용은 발견되지 않았으며, 제공된 자료들은 공통적으로 웹 성능 향상을 위해 롱 태스크를 식별하고 분할하는 것의 중요성을 강조하고 있습니다.
-
----
-*Last updated: 2026-04-19*
-- Raw Source: [[00_Raw/2026-04-20/Long Tasks.md]]
----
diff --git a/AI/Ludology-vs-Narratology.md b/AI/Ludology-vs-Narratology.md
deleted file mode 100644
index 6632511b..00000000
--- a/AI/Ludology-vs-Narratology.md
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-977AD2
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Ludology-vs-Narratology"
----
-
-# [[Ludology-vs-Narratology]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** AI 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Ludology-vs-Narratology.md]]
----
diff --git a/AI/MDA-P-Framework.md b/AI/MDA-P-Framework.md
deleted file mode 100644
index bc3156be..00000000
--- a/AI/MDA-P-Framework.md
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-CCDD20
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - MDA-P-Framework"
----
-
-# [[MDA-P-Framework]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** AI 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/MDA-P-Framework.md]]
----
diff --git a/AI/MMORPG Economic Management.md b/AI/MMORPG Economic Management.md
deleted file mode 100644
index 16920a96..00000000
--- a/AI/MMORPG Economic Management.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-CD65EB
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - MMORPG Economic Management"
----
-
-# [[MMORPG Economic Management]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** AI 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/MMORPG Economic Management.md]]
----
diff --git a/AI/Machine Learning in Game Design.md b/AI/Machine Learning in Game Design.md
deleted file mode 100644
index 54fee637..00000000
--- a/AI/Machine Learning in Game Design.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-E6138D
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Machine Learning in Game Design"
----
-
-# [[Machine Learning in Game Design]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** AI 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Machine Learning in Game Design.md]]
----
diff --git a/AI/Machine-Learning-Animation.md b/AI/Machine-Learning-Animation.md
deleted file mode 100644
index 868adb1c..00000000
--- a/AI/Machine-Learning-Animation.md
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-223E1A
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Machine-Learning-Animation"
----
-
-# [[Machine-Learning-Animation]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** AI 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Machine-Learning-Animation.md]]
----
diff --git a/AI/Main Thread.md b/AI/Main Thread.md
deleted file mode 100644
index 674ff26e..00000000
--- a/AI/Main Thread.md	
+++ /dev/null
@@ -1,32 +0,0 @@
----
-id: P-REINFORCE-AUTO-905D08
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Main Thread"
----
-
-# [[Main Thread]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> Main Thread(메인 스레드)는 웹 브라우저에서 자바스크립트 실행, 렌더링, 이벤트 처리 등 핵심 작업이 순차적으로 실행되는 단일 작업 흐름을 의미합니다 [1, 2]. WebGL과 같은 환경에서는 그래픽 명령어 제출을 비롯한 무거운 연산이 메인 스레드에서 이루어질 경우 렌더링 파이프라인이 차단되어 지연(Latency)과 병목 현상이 발생할 수 있습니다 [1, 2]. Chrome DevTools와 같은 성능 분석 도구를 통해 메인 스레드의 활동을 시각적으로 추적하고 병목 지점을 최적화할 수 있습니다 [3-5].
-
-## 📖 구조화된 지식 (Synthesized Content)
-*   **단일 스레드 구조와 병목 현상:** WebGL은 단일 스레드(Single-threaded) 환경에서 작동하므로 모든 드로우 콜(draw call), 상태 변경, 리소스 업로드가 메인 스레드에서 순차적으로 실행됩니다 [2]. 이로 인해 자바스크립트 실행에 과도한 시간이 소요되면 메인 스레드가 차단(blocked)되고 렌더링 파이프라인이 지연되는 병목 현상이 발생하며, GPU는 다음 명령을 기다리며 유휴 상태(idle)로 남게 됩니다 [1, 2, 6, 7].
-*   **성능 모니터링 및 진단:** Chrome DevTools의 Performance 패널에서 'Main' 트랙을 사용하면 메인 스레드의 활동을 시간의 흐름에 따른 플레임 차트(flame chart) 형태로 분석할 수 있습니다 [3-5]. 개발자는 이를 통해 16.67ms의 프레임 예산을 초과하여 메인 스레드를 차단하는 구체적인 자바스크립트 함수를 식별하고 [8], 50ms를 초과하는 긴 작업(Long tasks)을 파악하여 성능 저하의 원인을 진단할 수 있습니다 [9, 10].
-*   **최적화 및 WebGPU로의 전환:** 메인 스레드의 차단을 방지하여 상호작용성(Responsiveness)을 높이려면, 무거운 자바스크립트 작업을 더 작은 비동기 조각으로 나누거나 웹 워커(Web Workers)를 활용하여 메인 스레드에서 작업을 분리해야 합니다 [9]. 최근에는 이러한 메인 스레드 병목 현상을 근본적으로 해결하기 위해, 애니메이션 로직과 명령어 생성을 다중 스레드(Multi-Threaded)로 분산하고 작업을 GPU로 오프로드할 수 있는 WebGPU 기술이 도입되고 있습니다 [11, 12].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** AI 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[WebGL]], [[WebGPU]], [[Total Blocking Time (TBT)]], [[Interaction to Next Paint (INP)]], [[Long Tasks]]
-- **Projects/Contexts:** [[Chrome DevTools Performance Panel]], [[Core Web Vitals]]
-- **Contradictions/Notes:** 소스는 WebGL이 메인 스레드에서 순차적으로 그래픽 명령을 처리하여 CPU 병목을 유발한다고 주장하는 반면, 새로운 WebGPU는 다중 스레드 명령 생성(Multi-Threaded Command Generation)을 지원하여 메인 스레드의 오버헤드를 대폭 줄일 수 있다고 대조하여 설명합니다 [2, 11, 12].
-
----
-*Last updated: 2026-04-19*
-- Raw Source: [[00_Raw/2026-04-20/Main Thread.md]]
----
diff --git a/AI/Market Regulation.md b/AI/Market Regulation.md
deleted file mode 100644
index 08d0b40c..00000000
--- a/AI/Market Regulation.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-E87A98
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Market Regulation"
----
-
-# [[Market Regulation]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** AI 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Market Regulation.md]]
----
diff --git a/AI/Mechanistic Interpretability (기계적 해석 가능성).md b/AI/Mechanistic Interpretability (기계적 해석 가능성).md
deleted file mode 100644
index 4db497aa..00000000
--- a/AI/Mechanistic Interpretability (기계적 해석 가능성).md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-2BBD92
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Mechanistic Interpretability (기계적 해석 가능성)"
----
-
-# [[Mechanistic Interpretability (기계적 해석 가능성)]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** AI 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Mechanistic Interpretability (기계적 해석 가능성).md]]
----
diff --git a/AI/Mesocortical Pathway.md b/AI/Mesocortical Pathway.md
deleted file mode 100644
index f9578d3d..00000000
--- a/AI/Mesocortical Pathway.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-F74D23
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Mesocortical Pathway"
----
-
-# [[Mesocortical Pathway]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** AI 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Mesocortical Pathway.md]]
----
diff --git a/AI/Metabolic Efficiency.md b/AI/Metabolic Efficiency.md
deleted file mode 100644
index a8457606..00000000
--- a/AI/Metabolic Efficiency.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-237ED8
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Metabolic Efficiency"
----
-
-# [[Metabolic Efficiency]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** AI 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Metabolic Efficiency.md]]
----
diff --git a/AI/Metabolic-Flexibility.md b/AI/Metabolic-Flexibility.md
deleted file mode 100644
index 0cdfa346..00000000
--- a/AI/Metabolic-Flexibility.md
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-1081E3
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Metabolic-Flexibility"
----
-
-# [[Metabolic-Flexibility]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** AI 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Metabolic-Flexibility.md]]
----
diff --git a/AI/Metabolic-Resource-Allocation.md b/AI/Metabolic-Resource-Allocation.md
deleted file mode 100644
index f1702482..00000000
--- a/AI/Metabolic-Resource-Allocation.md
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-9E2C0F
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Metabolic-Resource-Allocation"
----
-
-# [[Metabolic-Resource-Allocation]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** AI 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Metabolic-Resource-Allocation.md]]
----
diff --git a/AI/Metro Exodus.md b/AI/Metro Exodus.md
deleted file mode 100644
index 5c8daf1c..00000000
--- a/AI/Metro Exodus.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-0E2C65
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Metro Exodus"
----
-
-# [[Metro Exodus]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** AI 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Metro Exodus.md]]
----
diff --git a/AI/Microservices-Architecture-Bounded-Contexts.md b/AI/Microservices-Architecture-Bounded-Contexts.md
deleted file mode 100644
index 5088915f..00000000
--- a/AI/Microservices-Architecture-Bounded-Contexts.md
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-018DBB
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Microservices-Architecture-Bounded-Contexts"
----
-
-# [[Microservices-Architecture-Bounded-Contexts]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** AI 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Microservices-Architecture-Bounded-Contexts.md]]
----
diff --git a/AI/Microservices-Architecture-Type-Safety.md b/AI/Microservices-Architecture-Type-Safety.md
deleted file mode 100644
index c0fdea89..00000000
--- a/AI/Microservices-Architecture-Type-Safety.md
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-E27CC2
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Microservices-Architecture-Type-Safety"
----
-
-# [[Microservices-Architecture-Type-Safety]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** AI 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Microservices-Architecture-Type-Safety.md]]
----
diff --git a/AI/Microservices-Communication-Patterns.md b/AI/Microservices-Communication-Patterns.md
deleted file mode 100644
index eeb134be..00000000
--- a/AI/Microservices-Communication-Patterns.md
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-8E2D1A
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Microservices-Communication-Patterns"
----
-
-# [[Microservices-Communication-Patterns]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** AI 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Microservices-Communication-Patterns.md]]
----
diff --git a/AI/Mipmap.md b/AI/Mipmap.md
deleted file mode 100644
index 64603128..00000000
--- a/AI/Mipmap.md
+++ /dev/null
@@ -1,33 +0,0 @@
----
-id: P-REINFORCE-AUTO-F5788A
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Mipmap"
----
-
-# [[Mipmap]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> Mipmap(또는 Mipmapping)은 거리 기반의 디테일 수준(LOD, Level of Detail) 샘플링을 위해 미리 계산된 다단계 텍스처 해상도 피라미드입니다 [1]. 텍스처 렌더링 시 발생하는 계단 현상(aliasing artifacts)을 제거하고, 화면상에 에셋이 매끄럽게 표시되도록 돕는 역할을 합니다 [1, 2]. 하지만 Mipmap을 저장하기 위해 추가적인 GPU 메모리 공간이 필요하며, 특정 최적화 기법(텍스처 아틀라스)과 결합할 때 텍스처 간 번짐 현상을 유발할 수 있다는 특징이 있습니다 [3, 4].
-
-## 📖 구조화된 지식 (Synthesized Content)
-- **시각적 품질 향상 및 에일리어싱 방지:** 밉맵은 카메라와의 거리를 기준으로 텍스처의 해상도를 조절(LOD 샘플링)하기 위해 만들어집니다 [1]. 이를 통해 텍스처 처리 과정에서 나타나는 에일리어싱(Aliasing) 아티팩트 문제를 제거하여 3D 에셋 렌더링 시 부드러운 스케일링과 시각적 품질을 제공할 수 있습니다 [1, 2].
-- **메모리 오버헤드 증가:** 여러 해상도의 텍스처 버전을 함께 생성하여 보관해야 하므로 상당한 GPU 메모리 대역폭을 소비합니다 [4]. 예를 들어, 고해상도 텍스처를 적용한 단일 모델은 밉맵 데이터를 포함하기 전에도 256MB의 VRAM을 차지할 수 있으며, 밉맵 적용 시 메모리 용량 부담은 더 커집니다 [4].
-- **텍스처 아틀라스(Texture Atlas)의 경계 번짐(Edge Bleeding) 부작용:** 모델 최적화를 위해 여러 텍스처를 한 장으로 합치는 '텍스처 아틀라스' 기법을 사용할 때, 해상도가 낮아진 밉 레벨(lower mip levels)에서는 텍스처 필터링 중 인접한 텍스처 영역이 흐려지고 서로 섞이는 '에지 블리딩' 현상이 발생합니다 [3]. 이를 막기 위해 텍스처 사이에 여백(Padding)을 추가해야 하지만, 이는 결국 메모리 낭비를 초래합니다 [3].
-- **배열 텍스처(Array Textures)를 통한 해결:** 기존 아틀라스 방식의 한계를 극복하기 위해 배열 텍스처(Data Array Textures)를 도입하면, 레이어 간 교차 오염(cross-contamination) 없이 각 텍스처 레이어에 대해 올바른 밉맵을 온전하게 생성할 수 있습니다 [5].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** AI 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[Level of Detail (LOD)]], [[Texture Atlas]], [[Data Array Textures]], [[Aliasing]]
-- **Projects/Contexts:** [[Three.js 최적화 파이프라인]], [[GPU 메모리 및 텍스처 압축]]
-- **Contradictions/Notes:** 소스에 따르면 단일 텍스처 아틀라스 기법은 밉맵의 낮은 레벨(low mip levels)에서 텍스처 혼합 현상(블리딩)이라는 단점을 수반하지만 [3], 배열 텍스처(Array Textures) 기법을 사용하면 이러한 Mipmap 간섭 현상을 완전히 배제하고 네이티브 랩핑(wrapping)과 타일링(tiling)을 지원할 수 있습니다 [5].
-
----
-*Last updated: 2026-04-19*
-- Raw Source: [[00_Raw/2026-04-20/Mipmap.md]]
----
diff --git a/AI/Mobile-App-Development.md b/AI/Mobile-App-Development.md
deleted file mode 100644
index 13bbe0ae..00000000
--- a/AI/Mobile-App-Development.md
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-C0F26C
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Mobile-App-Development"
----
-
-# [[Mobile-App-Development]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** AI 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Mobile-App-Development.md]]
----
diff --git a/AI/Model Collapse (모델 붕괴 현상).md b/AI/Model Collapse (모델 붕괴 현상).md
deleted file mode 100644
index b31ce0d1..00000000
--- a/AI/Model Collapse (모델 붕괴 현상).md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-F2D3E0
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Model Collapse (모델 붕괴 현상)"
----
-
-# [[Model Collapse (모델 붕괴 현상)]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** AI 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Model Collapse (모델 붕괴 현상).md]]
----
diff --git a/AI/Model Context Protocol (MCP).md b/AI/Model Context Protocol (MCP).md
deleted file mode 100644
index 77120f81..00000000
--- a/AI/Model Context Protocol (MCP).md	
+++ /dev/null
@@ -1,32 +0,0 @@
----
-id: P-REINFORCE-AUTO-C8F96B
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Model Context Protocol (MCP)"
----
-
-# [[Model Context Protocol (MCP)]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> Model Context Protocol (MCP)은 Cursor, Claude Code, Windsurf, GitHub Copilot 등과 같은 AI 코딩 어시스턴트(AI 에이전트)를 분석 엔진과 직접 연결할 수 있도록 지원하는 프로토콜입니다 [1, 2]. 이 프로토콜을 통해 AI는 대화형 워크플로우 내에서 실시간으로 쿼리를 보내고 통제된 피드백을 받을 수 있습니다 [1, 3]. 결과적으로 AI를 활용한 생산성과 코드 품질 및 보안 사이의 간격을 메워주는 특수한 브릿지 역할을 수행합니다 [2, 4].
-
-## 📖 구조화된 지식 (Synthesized Content)
-- **AI 에이전트와의 직접 통합**: MCP는 SonarQube MCP 서버와 같은 분석 도구를 Cursor, Claude Code, Windsurf 등의 AI 코딩 에이전트에 직접 연결하는 표준 방식을 제공합니다 [1].
-- **실시간 쿼리 및 분석 수행**: AI 어시스턴트는 MCP를 활용해 신뢰할 수 있는 분석 엔진과 실시간으로 상호작용합니다 [2, 3]. 이를 통해 AI는 코드 스니펫을 분석하고, Quality Gate 상태를 확인하며, 보안 핫스팟(Security Hotspots)을 즉각적으로 찾아낼 수 있습니다 [4].
-- **사전 코드 검토 및 워크플로우 최적화**: MCP를 통한 통합은 AI가 코드를 생성하는 과정에서 실시간으로 검토 및 개선이 이루어지도록 보장합니다 [3]. 이는 코드가 풀 리퀘스트(Pull Request) 단계에 도달하기 훨씬 전부터 작동하므로, 에이전틱(Agentic) 워크플로우를 최적화하고 안전한 코드 전달을 가능하게 합니다 [3].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** AI 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[AI Agents]], [[Static Code Analysis]], [[Automated Code Review]]
-- **Projects/Contexts:** [[SonarQube MCP Server]], [[Cursor]], [[Claude Code]], [[Windsurf]], [[GitHub Copilot]]
-- **Contradictions/Notes:** 소스에 관련 정보가 부족합니다. (제공된 소스에서는 주로 SonarQube 환경에서의 통합 사례를 통해서만 MCP가 설명되고 있으며, 프로토콜 자체의 심층적인 기술적 사양이나 다른 활용 사례에 대한 정보는 없습니다.)
-
----
-*Last updated: 2026-04-19*
-- Raw Source: [[00_Raw/2026-04-20/Model Context Protocol (MCP).md]]
----
diff --git a/AI/Model Predictive Control (MPC).md b/AI/Model Predictive Control (MPC).md
deleted file mode 100644
index 531fd7be..00000000
--- a/AI/Model Predictive Control (MPC).md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-212A93
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Model Predictive Control (MPC)"
----
-
-# [[Model Predictive Control (MPC)]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** AI 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Model Predictive Control (MPC).md]]
----
diff --git a/AI/Model Spec (모델 스펙 AI 행동 명세서).md b/AI/Model Spec (모델 스펙 AI 행동 명세서).md
deleted file mode 100644
index af612110..00000000
--- a/AI/Model Spec (모델 스펙 AI 행동 명세서).md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-73F6B2
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Model Spec (모델 스펙 AI 행동 명세서)"
----
-
-# [[Model Spec (모델 스펙 AI 행동 명세서)]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** AI 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Model Spec (모델 스펙, AI 행동 명세서).md]]
----
diff --git a/AI/Module Augmentation.md b/AI/Module Augmentation.md
deleted file mode 100644
index 17a0440f..00000000
--- a/AI/Module Augmentation.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-43A3F8
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Module Augmentation"
----
-
-# [[Module Augmentation]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** AI 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Module Augmentation.md]]
----
diff --git a/AI/Module-Augmentation.md b/AI/Module-Augmentation.md
deleted file mode 100644
index 26baad29..00000000
--- a/AI/Module-Augmentation.md
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-C5A5E7
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Module-Augmentation"
----
-
-# [[Module-Augmentation]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** AI 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Module-Augmentation.md]]
----
diff --git a/AI/Module-Boundary-Enforcement.md b/AI/Module-Boundary-Enforcement.md
deleted file mode 100644
index 1102bc0b..00000000
--- a/AI/Module-Boundary-Enforcement.md
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-32A387
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Module-Boundary-Enforcement"
----
-
-# [[Module-Boundary-Enforcement]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** AI 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Module-Boundary-Enforcement.md]]
----
diff --git a/AI/Monetary Policy in Virtual Worlds.md b/AI/Monetary Policy in Virtual Worlds.md
deleted file mode 100644
index 78ac73fd..00000000
--- a/AI/Monetary Policy in Virtual Worlds.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-26E3C1
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Monetary Policy in Virtual Worlds"
----
-
-# [[Monetary Policy in Virtual Worlds]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** AI 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Monetary Policy in Virtual Worlds.md]]
----
diff --git a/AI/Monetary Policy.md b/AI/Monetary Policy.md
deleted file mode 100644
index 4cec84e4..00000000
--- a/AI/Monetary Policy.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-97D263
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Monetary Policy"
----
-
-# [[Monetary Policy]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** AI 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Monetary Policy.md]]
----
diff --git a/AI/Monosemanticity (일의성).md b/AI/Monosemanticity (일의성).md
deleted file mode 100644
index c55e10a6..00000000
--- a/AI/Monosemanticity (일의성).md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-5B0FC9
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Monosemanticity (일의성)"
----
-
-# [[Monosemanticity (일의성)]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** AI 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Monosemanticity (일의성).md]]
----
diff --git a/AI/Multi-Agent Debate (에이전트 간 토론 전략).md b/AI/Multi-Agent Debate (에이전트 간 토론 전략).md
deleted file mode 100644
index 89f47783..00000000
--- a/AI/Multi-Agent Debate (에이전트 간 토론 전략).md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-A5AF0B
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Multi-Agent Debate (에이전트 간 토론 전략)"
----
-
-# [[Multi-Agent Debate (에이전트 간 토론 전략)]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** AI 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Multi-Agent Debate (에이전트 간 토론 전략).md]]
----
diff --git a/AI/Multi-Agent System (다중 에이전트 시스템).md b/AI/Multi-Agent System (다중 에이전트 시스템).md
deleted file mode 100644
index c6b0063f..00000000
--- a/AI/Multi-Agent System (다중 에이전트 시스템).md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-51D384
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Multi-Agent System (다중 에이전트 시스템)"
----
-
-# [[Multi-Agent System (다중 에이전트 시스템)]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** AI 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Multi-Agent System (다중 에이전트 시스템).md]]
----
diff --git a/AI/Multi-Hop Reasoning (다중 홉 추론).md b/AI/Multi-Hop Reasoning (다중 홉 추론).md
deleted file mode 100644
index 76c72a08..00000000
--- a/AI/Multi-Hop Reasoning (다중 홉 추론).md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-411F75
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Multi-Hop Reasoning (다중 홉 추론)"
----
-
-# [[Multi-Hop Reasoning (다중 홉 추론)]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** AI 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Multi-Hop Reasoning (다중 홉 추론).md]]
----
diff --git a/AI/Multimodal Sentiment Analysis.md b/AI/Multimodal Sentiment Analysis.md
deleted file mode 100644
index 290bf024..00000000
--- a/AI/Multimodal Sentiment Analysis.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-DF5F90
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Multimodal Sentiment Analysis"
----
-
-# [[Multimodal Sentiment Analysis]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** AI 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Multimodal Sentiment Analysis.md]]
----
diff --git a/AI/Natural Language Processing (NLP) in Narrative.md b/AI/Natural Language Processing (NLP) in Narrative.md
deleted file mode 100644
index 3f8d1dbb..00000000
--- a/AI/Natural Language Processing (NLP) in Narrative.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-B5A38A
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Natural Language Processing (NLP) in Narrative"
----
-
-# [[Natural Language Processing (NLP) in Narrative]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** AI 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Natural Language Processing (NLP) in Narrative.md]]
----
diff --git a/AI/Natural-Language-Processing.md b/AI/Natural-Language-Processing.md
deleted file mode 100644
index f5885d01..00000000
--- a/AI/Natural-Language-Processing.md
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-92B46C
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Natural-Language-Processing"
----
-
-# [[Natural-Language-Processing]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** AI 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Natural-Language-Processing.md]]
----
diff --git a/AI/Naughty Dog Development.md b/AI/Naughty Dog Development.md
deleted file mode 100644
index e4c74ae4..00000000
--- a/AI/Naughty Dog Development.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-45FC87
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Naughty Dog Development"
----
-
-# [[Naughty Dog Development]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** AI 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Naughty Dog Development.md]]
----
diff --git a/AI/NestJS-Architecture.md b/AI/NestJS-Architecture.md
deleted file mode 100644
index 0b9a5e82..00000000
--- a/AI/NestJS-Architecture.md
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-641044
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - NestJS-Architecture"
----
-
-# [[NestJS-Architecture]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** AI 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/NestJS-Architecture.md]]
----
diff --git a/AI/Network Synchronization in Multiplayer Games.md b/AI/Network Synchronization in Multiplayer Games.md
deleted file mode 100644
index d21533ab..00000000
--- a/AI/Network Synchronization in Multiplayer Games.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-DDB7C3
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Network Synchronization in Multiplayer Games"
----
-
-# [[Network Synchronization in Multiplayer Games]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** AI 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Network Synchronization in Multiplayer Games.md]]
----
diff --git a/AI/Neural-Symbolic-Integration.md b/AI/Neural-Symbolic-Integration.md
deleted file mode 100644
index b31e6e8c..00000000
--- a/AI/Neural-Symbolic-Integration.md
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-86032B
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Neural-Symbolic-Integration"
----
-
-# [[Neural-Symbolic-Integration]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** AI 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Neural-Symbolic-Integration.md]]
----
diff --git a/AI/Neuro-Symbolic-AI.md b/AI/Neuro-Symbolic-AI.md
deleted file mode 100644
index f9f71017..00000000
--- a/AI/Neuro-Symbolic-AI.md
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-3BA811
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Neuro-Symbolic-AI"
----
-
-# [[Neuro-Symbolic-AI]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** AI 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Neuro-Symbolic-AI.md]]
----
diff --git a/AI/Neurobiology-of-Reward.md b/AI/Neurobiology-of-Reward.md
deleted file mode 100644
index 682ec0b7..00000000
--- a/AI/Neurobiology-of-Reward.md
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-C81C25
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Neurobiology-of-Reward"
----
-
-# [[Neurobiology-of-Reward]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** AI 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Neurobiology-of-Reward.md]]
----
diff --git a/AI/Neurodevelopmental Disorders.md b/AI/Neurodevelopmental Disorders.md
deleted file mode 100644
index c8416f7f..00000000
--- a/AI/Neurodevelopmental Disorders.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-8D1E77
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Neurodevelopmental Disorders"
----
-
-# [[Neurodevelopmental Disorders]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** AI 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Neurodevelopmental Disorders.md]]
----
diff --git a/AI/Neuroeconomics.md b/AI/Neuroeconomics.md
deleted file mode 100644
index b0c4ef99..00000000
--- a/AI/Neuroeconomics.md
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-9E20C8
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Neuroeconomics"
----
-
-# [[Neuroeconomics]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** AI 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Neuroeconomics.md]]
----
diff --git a/AI/Neuroergonomics.md b/AI/Neuroergonomics.md
deleted file mode 100644
index 8bea9aee..00000000
--- a/AI/Neuroergonomics.md
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-FA4D6C
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Neuroergonomics"
----
-
-# [[Neuroergonomics]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** AI 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Neuroergonomics.md]]
----
diff --git a/AI/Neuromuscular-Adaptation.md b/AI/Neuromuscular-Adaptation.md
deleted file mode 100644
index b31689d1..00000000
--- a/AI/Neuromuscular-Adaptation.md
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-6E8355
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Neuromuscular-Adaptation"
----
-
-# [[Neuromuscular-Adaptation]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** AI 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Neuromuscular-Adaptation.md]]
----
diff --git a/AI/Neuromuscular-Control.md b/AI/Neuromuscular-Control.md
deleted file mode 100644
index 958cac14..00000000
--- a/AI/Neuromuscular-Control.md
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-AAABCA
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Neuromuscular-Control"
----
-
-# [[Neuromuscular-Control]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** AI 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Neuromuscular-Control.md]]
----
diff --git a/AI/Neuropharmacology of Substance Use Disorders.md b/AI/Neuropharmacology of Substance Use Disorders.md
deleted file mode 100644
index 1f0142ac..00000000
--- a/AI/Neuropharmacology of Substance Use Disorders.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-8A9F4F
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Neuropharmacology of Substance Use Disorders"
----
-
-# [[Neuropharmacology of Substance Use Disorders]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** AI 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Neuropharmacology of Substance Use Disorders.md]]
----
diff --git a/AI/Neuroplasticity in Addiction.md b/AI/Neuroplasticity in Addiction.md
deleted file mode 100644
index b8df4c3d..00000000
--- a/AI/Neuroplasticity in Addiction.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-623B58
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Neuroplasticity in Addiction"
----
-
-# [[Neuroplasticity in Addiction]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** AI 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Neuroplasticity in Addiction.md]]
----
diff --git a/AI/Neuroplasticity in Motor Learning.md b/AI/Neuroplasticity in Motor Learning.md
deleted file mode 100644
index a51d5a4b..00000000
--- a/AI/Neuroplasticity in Motor Learning.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-C1E899
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Neuroplasticity in Motor Learning"
----
-
-# [[Neuroplasticity in Motor Learning]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** AI 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Neuroplasticity in Motor Learning.md]]
----
diff --git a/AI/Neuroplasticity-in-Motor-Learning.md b/AI/Neuroplasticity-in-Motor-Learning.md
deleted file mode 100644
index 1e853588..00000000
--- a/AI/Neuroplasticity-in-Motor-Learning.md
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-AA0D20
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Neuroplasticity-in-Motor-Learning"
----
-
-# [[Neuroplasticity-in-Motor-Learning]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** AI 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Neuroplasticity-in-Motor-Learning.md]]
----
diff --git a/AI/Neuroprosthetics-Development.md b/AI/Neuroprosthetics-Development.md
deleted file mode 100644
index 2c362e8a..00000000
--- a/AI/Neuroprosthetics-Development.md
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-F99D73
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Neuroprosthetics-Development"
----
-
-# [[Neuroprosthetics-Development]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** AI 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Neuroprosthetics-Development.md]]
----
diff --git a/AI/Neuropsychiatric Disorders.md b/AI/Neuropsychiatric Disorders.md
deleted file mode 100644
index b7ac7c1c..00000000
--- a/AI/Neuropsychiatric Disorders.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-57B916
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Neuropsychiatric Disorders"
----
-
-# [[Neuropsychiatric Disorders]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** AI 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Neuropsychiatric Disorders.md]]
----
diff --git a/AI/Neuropsychology.md b/AI/Neuropsychology.md
deleted file mode 100644
index 128dae8e..00000000
--- a/AI/Neuropsychology.md
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-A63619
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Neuropsychology"
----
-
-# [[Neuropsychology]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** AI 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Neuropsychology.md]]
----
diff --git a/AI/Neurorehabilitation after Stroke.md b/AI/Neurorehabilitation after Stroke.md
deleted file mode 100644
index f18910a9..00000000
--- a/AI/Neurorehabilitation after Stroke.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-EB034B
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Neurorehabilitation after Stroke"
----
-
-# [[Neurorehabilitation after Stroke]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** AI 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Neurorehabilitation after Stroke.md]]
----
diff --git a/AI/Neurorehabilitation-Post-Stroke.md b/AI/Neurorehabilitation-Post-Stroke.md
deleted file mode 100644
index 944b5277..00000000
--- a/AI/Neurorehabilitation-Post-Stroke.md
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-DBB9EB
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Neurorehabilitation-Post-Stroke"
----
-
-# [[Neurorehabilitation-Post-Stroke]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** AI 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Neurorehabilitation-Post-Stroke.md]]
----
diff --git a/AI/No Mans Sky (Large-scale planetary generation).md b/AI/No Mans Sky (Large-scale planetary generation).md
deleted file mode 100644
index 91e0bf20..00000000
--- a/AI/No Mans Sky (Large-scale planetary generation).md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-3EC0AE
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - No Mans Sky (Large-scale planetary generation)"
----
-
-# [[No Mans Sky (Large-scale planetary generation)]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** AI 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/No Man's Sky (Large-scale planetary generation).md]]
----
diff --git a/AI/No Mans Sky.md b/AI/No Mans Sky.md
deleted file mode 100644
index e7c2967e..00000000
--- a/AI/No Mans Sky.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-D9AC35
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - No Mans Sky"
----
-
-# [[No Mans Sky]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** AI 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/No Man's Sky.md]]
----
diff --git a/AI/Nodejs 메모리 누수 분석.md b/AI/Nodejs 메모리 누수 분석.md
deleted file mode 100644
index c0aadc5c..00000000
--- a/AI/Nodejs 메모리 누수 분석.md	
+++ /dev/null
@@ -1,41 +0,0 @@
----
-id: P-REINFORCE-AUTO-92E707
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Nodejs 메모리 누수 분석"
----
-
-# [[Nodejs 메모리 누수 분석]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> Node.js의 메모리 누수는 가비지 컬렉션(GC)되어야 할 객체들이 클로저, 이벤트 리스너, 타이머 등의 루트(Root) 객체에 계속 참조되어 메모리에서 해제되지 않을 때 발생합니다 [1, 2]. Node.js는 단일 프로세스로 장기간 실행되는 특성이 있어, 누수된 참조는 모든 요청에 걸쳐 지속적으로 축적되며 결국 V8 힙 한계에 도달하여 OOM(Out-Of-Memory) 크래시를 유발합니다 [3, 4]. 이 문제를 해결하기 위해서는 힙 스냅샷과 메모리 할당 타임라인 도구를 활용하여, 지속적으로 증가하는 객체의 참조 경로(Retaining Path)를 추적하고 참조를 끊어 GC가 정상 작동하도록 근본적인 원인을 수정해야 합니다 [5-7].
-
-## 📖 구조화된 지식 (Synthesized Content)
-*   **메모리 누수 패턴 및 주요 원인**
-    *   정상적인 Node.js 프로세스는 트래픽 발생 시 힙 메모리가 증가하고 가비지 컬렉션(GC) 이후 원래 수준으로 회복되는 톱니바퀴(Sawtooth) 패턴을 보입니다 [8]. 그러나 누수가 발생하면 GC가 동작한 후에도 메모리가 떨어지지 않고 지속적으로 상승하는 래칫(Ratchet) 패턴이 나타납니다 [7, 8].
-    *   프로덕션 환경에서 가장 흔히 발생하는 7가지 누수 패턴은 다음과 같습니다: EventEmitter 리스너 누적(가장 흔함), 클로저(Closure) 변수의 의도치 않은 상태 유지, 제한 없이 증가하는 인메모리 캐시, 정리되지 않은 타이머(Timer) 및 인터벌, 복잡한 순환 참조, 닫히지 않은 스트림(Stream) 및 소켓, 그리고 AsyncLocalStorage 컨텍스트 누수입니다 [9-12].
-
-*   **탐지 및 분석 도구**
-    *   **힙 스냅샷(Heap Snapshots):** 의심스러운 작업을 수행하기 전(Baseline)과 부하 발생 후를 나누어 스냅샷을 촬영하고, 이 두 스냅샷 사이에서 할당된 후 해제되지 않은 객체들("Objects allocated between snapshots")을 비교하여 누수 후보를 도출합니다 [6, 13]. 브라우저나 프론트엔드 앱 분석 시 일회성 할당에 의한 오탐지를 필터링하기 위해 스냅샷을 3번 캡처하여 비교하는 3-스냅샷 기법(Three-snapshot technique)이 신뢰성이 높습니다 [14].
-    *   **할당 타임라인(Allocation Timeline):** Chrome DevTools를 `--inspect` 플래그와 함께 연결하여 시간에 따른 메모리 할당 기록을 수집합니다 [5, 8]. GC 이후에도 회수되지 않아 파란색 막대로 남은 객체들을 통해 어떤 함수나 생성자가 누수를 유발하는지 추적할 수 있습니다 [8, 15-17].
-    *   **프로그램 및 패키지 기반 모니터링:** `process.memoryUsage()`를 이용해 RSS(Resident Set Size) 및 `heapUsed` 값의 지속적 증가를 확인하거나 [18, 19], `heapdump`, `clinic.js` 등의 도구를 사용해 자동화된 분석으로 메모리 누수 발생 위치를 식별할 수 있습니다 [5, 9].
-
-*   **진단 로깅 및 GC 튜닝**
-    *   `--trace-gc` 플래그를 적용하면 콘솔에 V8 엔진의 GC 이벤트(Scavenge 및 Mark-sweep) 발생 시간, 빈도, 회수된 메모리양 등이 기록되어 애플리케이션의 메모리 부족 현상과 누수를 파악할 수 있습니다 [20-23].
-    *   만약 V8의 힙 영역 중 장기 생존 객체가 저장되는 공간에 큰 메모리가 필요하다면, `--max-old-space-size` 명령줄 플래그로 Old Space 크기를 늘려 애플리케이션 충돌과 과도한 GC 지연을 방지할 수 있습니다 [24]. 반대로, 짧은 주기의 객체 생성이 많은 경우에는 `--max-semi-space-size` 플래그로 New Space를 늘려 마이너 GC 주기를 조절할 수 있습니다 [25].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** AI 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[가비지 컬렉션 (Garbage Collection)]], [[V8 엔진 (V8 Engine)]], [[힙 스냅샷 (Heap Snapshots)]], [[Mark-Sweep]]
-- **Projects/Contexts:** [[Chrome DevTools]], [[clinic.js]], [[Node.js Production Monitoring]]
-- **Contradictions/Notes:** 소스에 따르면 모던 프론트엔드 환경의 브라우저에서는 메모리 누수의 가장 주요한 원인(1위)으로 SPA(Single Page Application) 경로 전환을 꼽고 있지만 [26], Node.js 프로덕션 서버 환경에서는 EventEmitter 리스너 누적이 가장 흔한 메모리 누수 패턴으로 언급되는 차이가 있습니다 [9].
-
----
-*Last updated: 2026-04-19*
-- Raw Source: [[00_Raw/2026-04-20/Node.js 메모리 누수 분석.md]]
----
diff --git a/AI/Nodejs 프로덕션 메모리 누수 진단.md b/AI/Nodejs 프로덕션 메모리 누수 진단.md
deleted file mode 100644
index d1e15e6f..00000000
--- a/AI/Nodejs 프로덕션 메모리 누수 진단.md	
+++ /dev/null
@@ -1,50 +0,0 @@
----
-id: P-REINFORCE-AUTO-AF2866
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Nodejs 프로덕션 메모리 누수 진단"
----
-
-# [[Nodejs 프로덕션 메모리 누수 진단]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> Node.js 프로덕션 메모리 누수는 단일 프로세스로 장기 실행되는 Node.js의 특성상 참조가 누적되어 V8 가비지 컬렉터(GC)가 메모리를 회수할 수 없게 되면서 발생합니다 [1, 2]. 정상적인 프로세스와 달리 가비지 컬렉션 이후에도 힙 메모리 사용량이 원래 수준으로 떨어지지 않고 계단식(Ratchet)으로 상승하는 패턴을 보이는 것이 주된 특징입니다 [3, 4]. 이를 진단하고 해결하려면 힙 스냅샷 비교, 힙 프로파일링, 메모리를 계속 참조하고 있는 요인(Retainer)을 추적하는 체계적인 과정이 필수적입니다 [4, 5].
-
-## 📖 구조화된 지식 (Synthesized Content)
-**누수의 원리와 증상 (Principles and Symptoms)**
-- Node.js 메모리 누수는 객체가 "유실"되는 것이 아니라 코드 어딘가에서 계속 참조되고 있어 GC가 도달할 수 없는 객체로 식별하지 못해 발생합니다 [2, 6].
-- 정상적인 프로세스는 트래픽 발생 시 힙이 증가하고 GC 이후 기준선으로 떨어지는 '톱니바퀴(Sawtooth)' 패턴을 보이지만, 누수가 발생하면 GC 후에도 힙 사용량이 떨어지지 않는 '계단식(Ratchet)' 패턴을 나타냅니다 [3, 4].
-- 주요 증상으로는 점진적인 메모리 증가, 잦고 긴 GC 일시 정지 시간, 응답 시간 저하, 그리고 궁극적으로 OOM(Out of Memory) 충돌 현상이 있습니다 [7].
-
-**핵심 진단 도구 (Core Diagnostic Tools)**
-- **`--inspect` 및 Chrome DevTools:** 서버를 `--inspect` 플래그로 실행하여 Chrome에 연결한 후, 메모리 패널에서 힙 스냅샷을 캡처해 스냅샷 사이에 할당된 객체를 비교 분석할 수 있습니다 [3, 8, 9].
-- **`heapdump`:** 프로덕션 환경(Chrome DevTools 접근이 어려운 경우)에서 프로그래밍 방식으로 힙 스냅샷을 기록하여 로컬로 다운로드 및 분석할 수 있게 돕습니다 [8, 10, 11].
-- **`--heap-prof` 플래그:** 외부 패키지 없이 Node.js 자체에 내장된 V8 네이티브 프로파일링을 활성화하여 함수 수준의 할당 세부 내역을 파악할 수 있습니다 [12].
-- **`process.memoryUsage()`:** RSS(Resident Set Size), heapTotal, heapUsed 값을 지속적으로 확인하여 프로그래밍 방식으로 힙의 점진적인 증가 여부를 감시할 수 있습니다 [13, 14].
-
-**일반적인 누수 발생 패턴 (Common Leak Patterns)**
-- **이벤트 리스너 누적 (EventEmitter Listener Accumulation):** 요청 핸들러 내에서 리스너를 추가하고 제거하지 않으면 참조가 계속 누적되며, 프로덕션 환경에서는 보통 `MaxListenersExceededWarning` 경고가 명확한 누수 신호로 간주됩니다 [5, 11, 15].
-- **클로저 변수 유지 (Closure Variable Retention):** 비동기 체인이나 타이머 콜백 등에서 대규모 데이터(예: 전체 요청/응답 객체)를 캡처하는 클로저를 사용하여 객체 수명이 불필요하게 늘어나는 경우입니다 [15-17].
-- **무제한 캐시 증가 (Unbounded Cache Growth):** 최대 크기나 제한을 두지 않은 인메모리 캐시 변수에 객체가 무한정 쌓이는 패턴입니다 [15].
-- **타이머/관찰자 및 소켓 누수:** `clearInterval` 처리되지 않은 `setInterval` 콜백이나, 데이터 송수신 후 닫히지 않은 스트림/소켓이 버퍼와 네트워크 핸들을 점유하여 메모리를 해제하지 못하게 만듭니다 [17, 18].
-
-**진단 및 해결 워크플로우 (Diagnosis & Fix Workflow)**
-- 모니터링을 통해 메모리의 계단식 증가 패턴(Ratchet)을 확인한 뒤 베이스라인 힙 스냅샷을 캡처합니다 [4].
-- 트래픽 부하를 유발하는 행동을 실행한 후 두 번째 스냅샷을 캡처하고 두 스냅샷을 비교합니다 [4, 19].
-- 비교 결과에서 유출된 객체를 찾은 후, 해당 객체를 유지하고 있는 리테이너(Retainer) 트리를 GC 루트까지 따라가 코드를 수정하고, 수정을 확인하기 위해 테스트를 반복합니다 [4, 20].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** AI 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[V8 Garbage Collection]], [[Heap Snapshot]], [[Retaining Path]], [[process.memoryUsage()]]
-- **Projects/Contexts:** [[Node.js Production Environment]], [[Chrome DevTools Memory Panel]]
-- **Contradictions/Notes:** 일반적으로 누수 후보를 찾기 위해 트래픽 전/후 두 개의 힙 스냅샷을 비교하는 방법이 자주 소개되지만, 일회성 메모리 할당으로 인한 오탐(False Positive)을 걸러내기 위해서는 세 개의 스냅샷을 연달아 캡처해 비교하는 "Three-snapshot technique" 기법이 가장 신뢰할 수 있는 수단이라는 점을 유의해야 합니다 [19].
-
----
-*Last updated: 2026-04-19*
-- Raw Source: [[00_Raw/2026-04-20/Node.js 프로덕션 메모리 누수 진단.md]]
----
diff --git a/AI/Nodejs 프로덕션 메모리 문제 해결.md b/AI/Nodejs 프로덕션 메모리 문제 해결.md
deleted file mode 100644
index 0a63f4bd..00000000
--- a/AI/Nodejs 프로덕션 메모리 문제 해결.md	
+++ /dev/null
@@ -1,30 +0,0 @@
----
-id: P-REINFORCE-AUTO-490C25
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Nodejs 프로덕션 메모리 문제 해결"
----
-
-# [[Nodejs 프로덕션 메모리 문제 해결]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> Node.js는 단일 프로세스로 장기간 실행되는 런타임이므로, 코드 내에서 참조가 제대로 해제되지 않은 객체가 누적되면 V8 힙(Heap) 메모리가 점진적으로 고갈되어 궁극적으로 OOM(Out of Memory) 크래시가 발생할 수 있습니다 [1-3]. 프로덕션 환경에서의 메모리 문제 해결은 정상적인 가비지 컬렉션(GC) 패턴과 누수 패턴을 구분하고, 타임라인 및 힙 스냅샷 분석을 통해 누수 객체의 보존 경로(Retaining Path)를 추적하여 근본 원인을 찾아 수정하는 체계적인 과정을 의미합니다 [4-8].
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** AI 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[Garbage Collection (V8)]], [[Heap Snapshot]], [[Memory Leak Patterns]], [[Orinoco Garbage Collector]]
-- **Projects/Contexts:** [[Chrome DevTools Memory Panel]], [[Node.js Production Monitoring]]
-- **Contradictions/Notes:** 가비지 컬렉션(GC)은 애플리케이션의 힙 메모리를 정리해주지만, 메인 스레드 실행을 멈추는 'stop-the-world' 특성을 지닙니다. V8은 Orinoco 프로젝트를 통해 병렬(Parallel), 점진적(Incremental), 동시적(Concurrent) 처리 기법을 도입하여 지연(Pause) 시간을 최소화했지만 [28-32], 개발자가 `--expose-gc`를 활성화하여 `global.gc()`를 수동으로 강제 호출하는 것은 시스템 성능을 악화시킬 수 있으므로 매우 주의해서 사용해야 한다고 경고하고 있습니다 [33, 34].
-
----
-*Last updated: 2026-04-19*
-- Raw Source: [[00_Raw/2026-04-20/Node.js 프로덕션 메모리 문제 해결.md]]
----
diff --git a/AI/Nodejs 프로덕션 메모리 병목 분석.md b/AI/Nodejs 프로덕션 메모리 병목 분석.md
deleted file mode 100644
index a82f2a42..00000000
--- a/AI/Nodejs 프로덕션 메모리 병목 분석.md	
+++ /dev/null
@@ -1,53 +0,0 @@
----
-id: P-REINFORCE-AUTO-76BE33
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Nodejs 프로덕션 메모리 병목 분석"
----
-
-# [[Nodejs 프로덕션 메모리 병목 분석]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> Node.js는 단일 프로세스로 장기간 실행되는 특성이 있어, 더 이상 필요하지 않은 객체의 참조가 유지될 경우 V8 힙(Heap) 메모리가 해제되지 않고 지속적으로 누적되는 메모리 누수 현상이 발생할 수 있습니다 [1, 2]. 프로덕션 환경에서 이러한 누수는 가비지 컬렉션(GC)의 오버헤드를 늘려 애플리케이션의 응답 지연이나 OOM(Out of Memory) 크래시 같은 심각한 병목 현상을 유발합니다 [3]. 이를 분석하고 해결하기 위해 개발자는 `--trace-gc` 같은 실행 플래그, `heapdump`를 통한 힙 스냅샷(Heap Snapshot) 획득, 그리고 크롬 개발자 도구(Chrome DevTools) 등을 활용하여 지속적으로 증가하는 객체와 이를 잡아두는 유지 경로(Retaining Path)를 추적해야 합니다 [4-6].
-
-## 📖 구조화된 지식 (Synthesized Content)
-*   **V8 메모리 구조와 가비지 컬렉션(GC) 메커니즘**
-    Node.js의 기반인 V8 엔진은 동적 데이터를 **힙(Heap) 공간**에 할당하며, 대부분의 객체는 짧은 수명을 가진다는 '세대별 가설(Generational Hypothesis)'을 기반으로 설계되었습니다 [7-9]. 
-    *   **New Space (Young Generation):** 새롭게 생성된 객체가 할당되는 공간으로, 꽉 차면 빠르게 작동하는 **스캐빈지(Scavenge, Minor GC)** 알고리즘이 발생해 불필요한 객체를 정리하고 살아남은 객체를 옮깁니다 [10-13].
-    *   **Old Space:** 스캐빈지 과정을 여러 번 통과한 수명이 긴 객체들이 승격(Promotion)되어 머무는 공간입니다 [9, 10, 14]. 이곳은 **Mark-Sweep-Compact (Major GC)** 알고리즘이 작동하며 메모리 파편화를 줄이고 남은 공간을 확보하지만, 스캐빈지에 비해 실행 비용(오버헤드)이 큽니다 [15, 16].
-
-*   **메모리 병목 및 누수의 주요 증상과 패턴**
-    건강한 프로세스는 GC가 일어날 때마다 메모리 사용량이 다시 줄어드는 **톱니바퀴(Sawtooth)** 패턴을 보이지만, 메모리 누수가 발생하면 할당량이 줄어들지 않고 계속 증가하는 **라쳇(Ratchet)** 패턴이 관찰됩니다 [4]. Node.js 환경에서 주로 발생하는 **7가지 주요 누수 패턴**은 다음과 같습니다 [17-19]:
-    1.  **EventEmitter 리스너 누적:** 이벤트 리스너를 계속 추가만 하고 제거하지 않아 발생하는 가장 흔한 누수로, `MaxListenersExceededWarning`이 발생하면 의심해야 합니다 [17, 18].
-    2.  **클로저(Closure) 변수 유지:** 요청/응답 객체 등 거대한 변수가 클로저에 의해 캡처된 상태로 요청 수명주기 이후에도 남아있는 경우입니다 [18].
-    3.  **무제한 캐시 증식:** LRU와 같은 크기 제한 로직이 없는 인메모리 캐시를 사용할 때 발생합니다 [18].
-    4.  **타이머 누수:** `clearInterval` 처리 없이 `setInterval`이 계속 실행되며 클로저 내부 객체의 GC를 방해합니다 [19].
-    5.  **복잡한 순환 참조:** C++ 네이티브 바인딩 또는 잘못 사용된 `WeakRef`와 결합한 복잡한 순환 참조가 GC를 방해할 수 있습니다 [19].
-    6.  **종료되지 않은 스트림/소켓:** `.destroy()` 처리되지 않은 스트림이 버퍼와 네트워크 핸들을 점유합니다 [19].
-    7.  **`AsyncLocalStorage` 컨텍스트 누수:** 저장소가 적절한 클린업 없이 과도하게 커지는 경우입니다 [19].
-
-*   **프로덕션 메모리 병목 진단 및 프로파일링 도구**
-    *   **`process.memoryUsage()` 모니터링:** `rss`(상주 집합 크기), `heapTotal`, `heapUsed` 메트릭을 추적하여 힙 사용량이 지속해서 증가하는지 감시할 수 있습니다 [20, 21].
-    *   **GC 로그 추적 (`--trace-gc`):** 이 플래그를 활성화하면 Scavenge와 Mark-Sweep 이벤트의 발생 빈도와 소요 시간, 회수된 메모리양을 확인할 수 있습니다 [22, 23]. 두 GC 사이의 간격보다 GC 처리에 걸리는 시간이 더 크다면 심각한 메모리 병목을 겪고 있는 것입니다 [24].
-    *   **힙 스냅샷(Heap Snapshot) 분석:** 운영 서버에서는 `heapdump` 패키지 등으로 스냅샷을 생성하거나 로드 테스트 시 `--inspect` 플래그를 사용해 **크롬 개발자 도구(Chrome DevTools)**와 연결할 수 있습니다 [4, 5, 17]. 개발자 도구의 '할당 타임라인(Allocation timeline)'을 통해 GC 후에도 남아있는 파란색 막대를 찾고, 스냅샷 비교(Comparison view) 기능을 사용하여 누수된 객체와 해당 객체가 참조를 유지하고 있는 경로(Retainers tree)를 짚어낼 수 있습니다 [25-30].
-
-*   **메모리 튜닝 플래그**
-    메모리 누수 자체의 해결책은 아니지만, 프로세스 특성에 맞춰 V8 엔진의 메모리 한도를 조정함으로써 병목을 완화할 수 있습니다 [31]. 
-    *   `--max-old-space-size`: 롱 폴링이나 캐시 등 영구적인 데이터가 많은 앱에서 Old Space의 크기 제한(기본 제약)을 늘릴 때 사용합니다 [31].
-    *   `--max-semi-space-size`: 초당 요청 수가 많아 수명이 짧은 임시 객체가 대량 생성되는 환경에서 New Space의 크기를 늘려 잦은 Minor GC 실행을 줄입니다 [32, 33].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** AI 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[V8 가비지 컬렉션 (Garbage Collection)]], [[힙 스냅샷 (Heap Snapshot)]], [[메모리 누수 (Memory Leaks)]]
-- **Projects/Contexts:** [[Chrome DevTools (크롬 개발자 도구)]], [[Node.js 모니터링 및 튜닝]]
-- **Contradictions/Notes:** 애플리케이션 내에서 수동으로 GC를 제어하기 위해 `--expose-gc` 플래그를 켜고 `global.gc()`를 호출할 수 있지만, 이 기능은 V8의 자동 가비지 컬렉션을 비활성화하지는 않습니다. 오히려 수동 호출의 남용은 애플리케이션의 응답 속도 등 전체적인 성능에 부정적인 영향을 미칠 수 있으므로 주의해서 사용해야 한다고 소스는 경고합니다 [34, 35].
-
----
-*Last updated: 2026-04-19*
-- Raw Source: [[00_Raw/2026-04-20/Node.js 프로덕션 메모리 병목 분석.md]]
----
diff --git a/AI/Nodejs-Global-Namespace-Augmentation.md b/AI/Nodejs-Global-Namespace-Augmentation.md
deleted file mode 100644
index d761ba5f..00000000
--- a/AI/Nodejs-Global-Namespace-Augmentation.md
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-D512F0
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Nodejs-Global-Namespace-Augmentation"
----
-
-# [[Nodejs-Global-Namespace-Augmentation]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** AI 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Node.js-Global-Namespace-Augmentation.md]]
----
diff --git a/AI/Nominal-Typing-in-TypeScript.md b/AI/Nominal-Typing-in-TypeScript.md
deleted file mode 100644
index 723e9eae..00000000
--- a/AI/Nominal-Typing-in-TypeScript.md
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-C4D501
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Nominal-Typing-in-TypeScript"
----
-
-# [[Nominal-Typing-in-TypeScript]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** AI 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Nominal-Typing-in-TypeScript.md]]
----
diff --git a/AI/Non-Photorealistic-Rendering-in-Level-Design.md b/AI/Non-Photorealistic-Rendering-in-Level-Design.md
deleted file mode 100644
index f61f750d..00000000
--- a/AI/Non-Photorealistic-Rendering-in-Level-Design.md
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-7D2198
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Non-Photorealistic-Rendering-in-Level-Design"
----
-
-# [[Non-Photorealistic-Rendering-in-Level-Design]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** AI 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Non-Photorealistic-Rendering-in-Level-Design.md]]
----
diff --git a/AI/Nuclear Deterrence Models.md b/AI/Nuclear Deterrence Models.md
deleted file mode 100644
index e8e4ec47..00000000
--- a/AI/Nuclear Deterrence Models.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-D14EE1
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Nuclear Deterrence Models"
----
-
-# [[Nuclear Deterrence Models]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** AI 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Nuclear Deterrence Models.md]]
----
diff --git a/AI/Nutritional-Biochemistry.md b/AI/Nutritional-Biochemistry.md
deleted file mode 100644
index 540161da..00000000
--- a/AI/Nutritional-Biochemistry.md
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-FFA78C
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Nutritional-Biochemistry"
----
-
-# [[Nutritional-Biochemistry]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** AI 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Nutritional-Biochemistry.md]]
----
diff --git a/AI/OWA vs CWA (개방 세계 vs 폐쇄 세계 가정).md b/AI/OWA vs CWA (개방 세계 vs 폐쇄 세계 가정).md
deleted file mode 100644
index dd87be04..00000000
--- a/AI/OWA vs CWA (개방 세계 vs 폐쇄 세계 가정).md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-BB45FB
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - OWA vs CWA (개방 세계 vs 폐쇄 세계 가정)"
----
-
-# [[OWA vs CWA (개방 세계 vs 폐쇄 세계 가정)]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** AI 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/OWA vs CWA (개방 세계 vs 폐쇄 세계 가정).md]]
----
diff --git a/AI/Object Pooling (가비지 컬렉션 최적화).md b/AI/Object Pooling (가비지 컬렉션 최적화).md
deleted file mode 100644
index 0e10309f..00000000
--- a/AI/Object Pooling (가비지 컬렉션 최적화).md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-345FBB
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Object Pooling (가비지 컬렉션 최적화)"
----
-
-# [[Object Pooling (가비지 컬렉션 최적화)]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** AI 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Object Pooling (가비지 컬렉션 최적화).md]]
----
diff --git a/AI/Object-Oriented-Design-Patterns.md b/AI/Object-Oriented-Design-Patterns.md
deleted file mode 100644
index efa2a158..00000000
--- a/AI/Object-Oriented-Design-Patterns.md
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-A48A29
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Object-Oriented-Design-Patterns"
----
-
-# [[Object-Oriented-Design-Patterns]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** AI 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Object-Oriented-Design-Patterns.md]]
----
diff --git a/AI/Objectivism.md b/AI/Objectivism.md
deleted file mode 100644
index c56cc9dd..00000000
--- a/AI/Objectivism.md
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-AAD455
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Objectivism"
----
-
-# [[Objectivism]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** AI 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Objectivism.md]]
----
diff --git a/AI/Occupational-Therapy.md b/AI/Occupational-Therapy.md
deleted file mode 100644
index 7804468a..00000000
--- a/AI/Occupational-Therapy.md
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-5178EE
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Occupational-Therapy"
----
-
-# [[Occupational-Therapy]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** AI 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Occupational-Therapy.md]]
----
diff --git a/AI/Okami-Ink-Wash-Aesthetics.md b/AI/Okami-Ink-Wash-Aesthetics.md
deleted file mode 100644
index b8d99039..00000000
--- a/AI/Okami-Ink-Wash-Aesthetics.md
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-442A85
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Okami-Ink-Wash-Aesthetics"
----
-
-# [[Okami-Ink-Wash-Aesthetics]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** AI 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Okami-Ink-Wash-Aesthetics.md]]
----
diff --git a/AI/Olympic-Training-Cycles.md b/AI/Olympic-Training-Cycles.md
deleted file mode 100644
index 62fa65ee..00000000
--- a/AI/Olympic-Training-Cycles.md
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-0425FA
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Olympic-Training-Cycles"
----
-
-# [[Olympic-Training-Cycles]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** AI 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Olympic-Training-Cycles.md]]
----
diff --git a/AI/Olympic-Training-Models.md b/AI/Olympic-Training-Models.md
deleted file mode 100644
index 104ad800..00000000
--- a/AI/Olympic-Training-Models.md
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-89D68B
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Olympic-Training-Models"
----
-
-# [[Olympic-Training-Models]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** AI 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Olympic-Training-Models.md]]
----
diff --git a/AI/Olympic-Training-Protocols.md b/AI/Olympic-Training-Protocols.md
deleted file mode 100644
index 32faa7a0..00000000
--- a/AI/Olympic-Training-Protocols.md
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-553F3F
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Olympic-Training-Protocols"
----
-
-# [[Olympic-Training-Protocols]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** AI 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Olympic-Training-Protocols.md]]
----
diff --git a/AI/Ontology-Driven-Relevancy-Filtering.md b/AI/Ontology-Driven-Relevancy-Filtering.md
deleted file mode 100644
index 8dda4c3d..00000000
--- a/AI/Ontology-Driven-Relevancy-Filtering.md
+++ /dev/null
@@ -1,35 +0,0 @@
----
-id: P-REINFORCE-AUTO-9231E5
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Ontology-Driven-Relevancy-Filtering"
----
-
-# [[Ontology-Driven-Relevancy-Filtering]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 탐사 과정에서 발생할 수 있는 '주제 이탈(Topic Drift)'을 방지하기 위해 도입된 의미론적 제약 엔진입니다. 최초 입력된 'Root Topic'을 모든 하위 연구 단계에 주입하여, 추출된 연관 주제가 뿌리 지식과 얼마나 밀접한지를 LLM이 스스로 판단하게 합니다.
-
-## 📖 구조화된 지식 (Synthesized Content)
-지능형 에이전트가 자율적으로 연구를 수행할 때 발생하는 가장 큰 위험은, 연관 주제를 타고 가다가 원래의 목적과 상관없는 지식(예: '프로그래밍'에서 시작해 '인류의 역사'로 끝남)을 수집하는 것입니다. 이를 해결하기 위해 다음의 '필터링 레이어'를 구축했습니다.
-
-1. **Root Topic Injection**: 미션 시작 시 입력된 주제를 전역 상태(`rootTopic`)로 고정하고, 모든 프롬프트에 "최초 주제인 [Root Topic]을 이해하는 데 반드시 필요한 정보만 수집하라"는 강력한 지침을 포함시킵니다.
-2. **Strict Extraction Rule**: 
-    - `[[Link]]` 추출 시, 해당 주제가 Root Topic과 70% 이상의 의미론적 연관성을 가질 때만 큐(Queue)에 추가하도록 LLM 가이드라인을 설정했습니다.
-    - 단순 나열(Tangential topics)은 수집 대상에서 제외합니다.
-3. **Contextual Continuity**: 다음 태스크를 생성할 때 이전 태스크의 맥락을 `context` 변수로 전달하여, 지식의 연결성이 끊기지 않도록 관리합니다.
-
-이 메커니즘은 지식 그래프의 '확산' 대신 '심화'에 집중하게 하여, 사용자가 원하는 전문 지식의 밀도를 극대화합니다.
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** AI 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[Autonomous-Loop-State-Machine]], [[Gemini-Based-Knowledge-Synthesis]]
-- **Projects/Contexts:** [[Knowledge-Graph-Expansion]]
-- **Contradictions/Notes:** 필터링이 너무 강력하면 지식의 '참신한 연결'이 저해될 수 있으므로, 프롬프트의 강도 조절이 중요합니다.
-- Raw Source: [[00_Raw/2026-04-20/Ontology-Driven-Relevancy-Filtering.md]]
----
diff --git a/AI/Ontology-Engineering.md b/AI/Ontology-Engineering.md
deleted file mode 100644
index 1fca48d7..00000000
--- a/AI/Ontology-Engineering.md
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-8A5DA4
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Ontology-Engineering"
----
-
-# [[Ontology-Engineering]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** AI 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Ontology-Engineering.md]]
----
diff --git a/AI/Ontology-Guided Knowledge Extraction.md b/AI/Ontology-Guided Knowledge Extraction.md
deleted file mode 100644
index d6fec33e..00000000
--- a/AI/Ontology-Guided Knowledge Extraction.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-691936
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Ontology-Guided Knowledge Extraction"
----
-
-# [[Ontology-Guided Knowledge Extraction]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** AI 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Ontology-Guided Knowledge Extraction.md]]
----
diff --git a/AI/Opaque-Types.md b/AI/Opaque-Types.md
deleted file mode 100644
index 08ac206d..00000000
--- a/AI/Opaque-Types.md
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-9E90BE
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Opaque-Types"
----
-
-# [[Opaque-Types]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** AI 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Opaque-Types.md]]
----
diff --git a/AI/Open-Access-Movement.md b/AI/Open-Access-Movement.md
deleted file mode 100644
index 38b5aa35..00000000
--- a/AI/Open-Access-Movement.md
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-F5F460
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Open-Access-Movement"
----
-
-# [[Open-Access-Movement]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** AI 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Open-Access-Movement.md]]
----
diff --git a/AI/Operations-Research.md b/AI/Operations-Research.md
deleted file mode 100644
index f9476289..00000000
--- a/AI/Operations-Research.md
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-1BE13E
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Operations-Research"
----
-
-# [[Operations-Research]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** AI 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Operations-Research.md]]
----
diff --git a/AI/Organizational Psychology.md b/AI/Organizational Psychology.md
deleted file mode 100644
index 13bcd8e2..00000000
--- a/AI/Organizational Psychology.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-D27512
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Organizational Psychology"
----
-
-# [[Organizational Psychology]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** AI 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Organizational Psychology.md]]
----
diff --git a/AI/Outer Alignment vs Inner Alignment.md b/AI/Outer Alignment vs Inner Alignment.md
deleted file mode 100644
index 204d9d99..00000000
--- a/AI/Outer Alignment vs Inner Alignment.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-5C9E29
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Outer Alignment vs Inner Alignment"
----
-
-# [[Outer Alignment vs Inner Alignment]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** AI 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Outer Alignment vs Inner Alignment.md]]
----
diff --git a/AI/PCGML-Frameworks.md b/AI/PCGML-Frameworks.md
deleted file mode 100644
index 0df8e152..00000000
--- a/AI/PCGML-Frameworks.md
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-294A76
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - PCGML-Frameworks"
----
-
-# [[PCGML-Frameworks]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** AI 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/PCGML-Frameworks.md]]
----
diff --git a/AI/PEFT (Parameter-Efficient Fine-Tuning).md b/AI/PEFT (Parameter-Efficient Fine-Tuning).md
deleted file mode 100644
index 5bcadf1a..00000000
--- a/AI/PEFT (Parameter-Efficient Fine-Tuning).md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-5B20CE
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - PEFT (Parameter-Efficient Fine-Tuning)"
----
-
-# [[PEFT (Parameter-Efficient Fine-Tuning)]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** AI 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/PEFT (Parameter-Efficient Fine-Tuning).md]]
----
diff --git a/AI/PRM (Process Reward Model).md b/AI/PRM (Process Reward Model).md
deleted file mode 100644
index 1fa2dd2a..00000000
--- a/AI/PRM (Process Reward Model).md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-58769F
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - PRM (Process Reward Model)"
----
-
-# [[PRM (Process Reward Model)]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** AI 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/PRM (Process Reward Model).md]]
----
diff --git a/AI/PageSpeed Insights.md b/AI/PageSpeed Insights.md
deleted file mode 100644
index 4c2b6dfa..00000000
--- a/AI/PageSpeed Insights.md	
+++ /dev/null
@@ -1,32 +0,0 @@
----
-id: P-REINFORCE-AUTO-FB1C7F
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - PageSpeed Insights"
----
-
-# [[PageSpeed Insights]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> PageSpeed Insights는 웹 페이지의 로딩 속도와 사용자 경험 성능을 측정하고 개선을 위한 진단 결과를 제공하는 도구입니다. 이 도구의 진단 기능은 주로 Lighthouse에 의해 구동되며, 최근에는 INP(Interaction to Next Paint)를 비롯한 코어 웹 바이탈(Core Web Vitals) 지표를 통합하여 웹사이트의 전반적인 반응성을 평가합니다 [1-3].
-
-## 📖 구조화된 지식 (Synthesized Content)
-* **Lighthouse 기반의 진단 엔진:** PageSpeed Insights에서 제공하는 성능 진단 및 개선 권장 사항은 페이지 속도 측정 무료 도구인 Lighthouse의 코어 엔진을 기반으로 구동됩니다 [1].
-* **코어 웹 바이탈(Core Web Vitals) 평가:** PageSpeed Insights는 웹 성능을 평가하는 필수 측정 기준인 코어 웹 바이탈을 분석하는 주요 도구 중 하나입니다. 과거의 FID(First Input Delay) 지표를 대신하여, 이제는 사용자의 모든 상호작용 지연 시간을 포괄적으로 측정하는 INP(Interaction to Next Paint) 지표를 평가하도록 업데이트되었습니다 [2, 3].
-* **데이터 표출의 한계점:** PageSpeed Insights는 유용한 성능 지표를 제공하지만, 모든 세부 데이터를 직접 보여주지는 않습니다. 예를 들어, 로딩 속도 저하의 정확한 원인을 파악하는 데 유용한 크롬 사용자 경험 보고서(CrUX)의 LCP(Largest Contentful Paint) 하위 요소(subparts) 실제 사용자 데이터는 PageSpeed Insights 화면에 표출되지 않으며, 이를 확인하려면 CrUX Vis나 DebugBear와 같은 외부 도구를 이용해야 합니다 [4, 5].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** AI 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[Lighthouse]], [[Core Web Vitals]], [[Interaction to Next Paint (INP)]], [[Largest Contentful Paint (LCP)]]
-- **Projects/Contexts:** [[Web Performance Optimization]], [[Chrome User Experience Report (CrUX)]]
-- **Contradictions/Notes:** PageSpeed Insights는 웹 성능을 평가하는 공식적이고 강력한 도구이지만, LCP 하위 요소 데이터와 같은 특정 세부 지표는 도구 내에서 직접 확인할 수 없어 다른 시각화 도구의 병행 사용이 필요할 수 있습니다 [5].
-
----
-*Last updated: 2026-04-19*
-- Raw Source: [[00_Raw/2026-04-20/PageSpeed Insights.md]]
----
diff --git a/AI/Papers Please (Bureaucratic Simulation).md b/AI/Papers Please (Bureaucratic Simulation).md
deleted file mode 100644
index 535ddd96..00000000
--- a/AI/Papers Please (Bureaucratic Simulation).md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-5F8F7B
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Papers Please (Bureaucratic Simulation)"
----
-
-# [[Papers Please (Bureaucratic Simulation)]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** AI 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Papers, Please (Bureaucratic Simulation).md]]
----
diff --git a/AI/Papers-Please.md b/AI/Papers-Please.md
deleted file mode 100644
index 8772fdde..00000000
--- a/AI/Papers-Please.md
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-6CA77E
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Papers-Please"
----
-
-# [[Papers-Please]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** AI 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Papers-Please.md]]
----
diff --git a/AI/Pedestrian-Modeling.md b/AI/Pedestrian-Modeling.md
deleted file mode 100644
index b7b84f33..00000000
--- a/AI/Pedestrian-Modeling.md
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-9FF9E8
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Pedestrian-Modeling"
----
-
-# [[Pedestrian-Modeling]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** AI 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Pedestrian-Modeling.md]]
----
diff --git a/AI/Perceptual-Motor-Skills.md b/AI/Perceptual-Motor-Skills.md
deleted file mode 100644
index b2ec6da6..00000000
--- a/AI/Perceptual-Motor-Skills.md
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-49DAC5
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Perceptual-Motor-Skills"
----
-
-# [[Perceptual-Motor-Skills]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** AI 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Perceptual-Motor-Skills.md]]
----
diff --git a/AI/Performance Management Systems.md b/AI/Performance Management Systems.md
deleted file mode 100644
index 6b037f43..00000000
--- a/AI/Performance Management Systems.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-AE7AD2
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Performance Management Systems"
----
-
-# [[Performance Management Systems]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** AI 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Performance Management Systems.md]]
----
diff --git a/AI/Performance Psychology.md b/AI/Performance Psychology.md
deleted file mode 100644
index 083c8146..00000000
--- a/AI/Performance Psychology.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-D603B6
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Performance Psychology"
----
-
-# [[Performance Psychology]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** AI 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Performance Psychology.md]]
----
diff --git a/AI/Periodization-Theory.md b/AI/Periodization-Theory.md
deleted file mode 100644
index 981d727a..00000000
--- a/AI/Periodization-Theory.md
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-02B992
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Periodization-Theory"
----
-
-# [[Periodization-Theory]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** AI 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Periodization-Theory.md]]
----
diff --git a/AI/Personalization-Engines.md b/AI/Personalization-Engines.md
deleted file mode 100644
index a4de562a..00000000
--- a/AI/Personalization-Engines.md
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-A74003
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Personalization-Engines"
----
-
-# [[Personalization-Engines]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** AI 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Personalization-Engines.md]]
----
diff --git a/AI/Persuasive Games.md b/AI/Persuasive Games.md
deleted file mode 100644
index 904a6bd2..00000000
--- a/AI/Persuasive Games.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-11DC29
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Persuasive Games"
----
-
-# [[Persuasive Games]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** AI 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Persuasive Games.md]]
----
diff --git a/AI/Phase Transition (위상 변이).md b/AI/Phase Transition (위상 변이).md
deleted file mode 100644
index b9b33041..00000000
--- a/AI/Phase Transition (위상 변이).md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-F09281
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Phase Transition (위상 변이)"
----
-
-# [[Phase Transition (위상 변이)]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** AI 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Phase Transition (위상 변이).md]]
----
diff --git a/AI/Phyllotaxis-Modeling.md b/AI/Phyllotaxis-Modeling.md
deleted file mode 100644
index c82e6797..00000000
--- a/AI/Phyllotaxis-Modeling.md
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-AAE034
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Phyllotaxis-Modeling"
----
-
-# [[Phyllotaxis-Modeling]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** AI 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Phyllotaxis-Modeling.md]]
----
diff --git a/AI/Physics-Based-Simulation.md b/AI/Physics-Based-Simulation.md
deleted file mode 100644
index cd3b7c18..00000000
--- a/AI/Physics-Based-Simulation.md
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-1E824D
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Physics-Based-Simulation"
----
-
-# [[Physics-Based-Simulation]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** AI 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Physics-Based-Simulation.md]]
----
diff --git a/AI/Platform Economics.md b/AI/Platform Economics.md
deleted file mode 100644
index bf00dc88..00000000
--- a/AI/Platform Economics.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-2B537F
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Platform Economics"
----
-
-# [[Platform Economics]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** AI 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Platform Economics.md]]
----
diff --git a/AI/Play-to-Earn (P2E) Economies.md b/AI/Play-to-Earn (P2E) Economies.md
deleted file mode 100644
index d532c567..00000000
--- a/AI/Play-to-Earn (P2E) Economies.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-43C745
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Play-to-Earn (P2E) Economies"
----
-
-# [[Play-to-Earn (P2E) Economies]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** AI 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Play-to-Earn (P2E) Economies.md]]
----
diff --git a/AI/Player-Agency.md b/AI/Player-Agency.md
deleted file mode 100644
index 187ecedf..00000000
--- a/AI/Player-Agency.md
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-058473
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Player-Agency"
----
-
-# [[Player-Agency]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** AI 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Player-Agency.md]]
----
diff --git a/AI/PolicyIQ.md b/AI/PolicyIQ.md
deleted file mode 100644
index 1ec5711d..00000000
--- a/AI/PolicyIQ.md
+++ /dev/null
@@ -1,32 +0,0 @@
----
-id: P-REINFORCE-AUTO-B7D200
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - PolicyIQ"
----
-
-# [[PolicyIQ]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> PolicyIQ는 AI 네이티브 SAST(정적 애플리케이션 보안 테스트) 플랫폼인 Corgea에서 제공하는 기능입니다 [1, 2]. 팀이 자연어를 사용하여 비즈니스 및 환경적 맥락을 시스템에 제공할 수 있도록 지원하며, 스캐너는 이를 활용하여 취약점 탐지 정확도를 높이고 코드 수정안(fix) 생성 능력을 향상시킵니다 [2].
-
-## 📖 구조화된 지식 (Synthesized Content)
-* **자연어 기반 컨텍스트 제공:** PolicyIQ를 통해 보안 및 개발 팀은 복잡한 규칙 작성 대신 자연어(natural language)를 사용하여 자신들의 비즈니스 및 환경적 맥락을 쉽게 시스템에 전달할 수 있습니다 [2].
-* **맞춤형 탐지 및 해결책 생성:** PolicyIQ의 정책 기반 맥락화(Policy-driven contextualization) 기술을 통해, 보안 스캔 결과와 AI가 생성하는 코드 수정안이 조직의 실제 비즈니스 작동 방식에 맞게 조정(tailor)됩니다 [2]. 
-* **Corgea 스캐닝 엔진과의 결합:** 사후 분석에만 AI를 사용하는 다른 도구들과 달리, PolicyIQ는 코어 스캐닝 엔진 자체에 대형 언어 모델(LLM)을 사용하는 Corgea의 시스템 내에서 작동합니다 [1, 2]. 이를 통해 패턴 기반 탐지에만 의존할 때 발생하는 오탐(False Positives)을 줄이고, 비즈니스 로직 결함 검출과 같은 고차원적인 분석을 가능하게 합니다 [1, 2].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** AI 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[Corgea]], [[SAST]], [[Large Language Models (LLMs)]]
-- **Projects/Contexts:** [[Corgea AI-native SAST Platform]]
-- **Contradictions/Notes:** PolicyIQ의 심층적인 기술 작동 원리나 세부적인 설정 방법 등은 소스에 관련 정보가 부족합니다.
-
----
-*Last updated: 2026-04-19*
-- Raw Source: [[00_Raw/2026-04-20/PolicyIQ.md]]
----
diff --git a/AI/Positive-Education.md b/AI/Positive-Education.md
deleted file mode 100644
index 12189f01..00000000
--- a/AI/Positive-Education.md
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-E6C93F
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Positive-Education"
----
-
-# [[Positive-Education]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** AI 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Positive-Education.md]]
----
diff --git a/AI/Post-structuralism.md b/AI/Post-structuralism.md
deleted file mode 100644
index 5afc10e2..00000000
--- a/AI/Post-structuralism.md
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-49AC0F
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Post-structuralism"
----
-
-# [[Post-structuralism]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** AI 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Post-structuralism.md]]
----
diff --git a/AI/Precision Medicine Training.md b/AI/Precision Medicine Training.md
deleted file mode 100644
index 4b7b1fd1..00000000
--- a/AI/Precision Medicine Training.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-95109A
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Precision Medicine Training"
----
-
-# [[Precision Medicine Training]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** AI 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Precision Medicine Training.md]]
----
diff --git a/AI/Predictive Maintenance (PdM).md b/AI/Predictive Maintenance (PdM).md
deleted file mode 100644
index 1f069a3a..00000000
--- a/AI/Predictive Maintenance (PdM).md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-E3A437
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Predictive Maintenance (PdM)"
----
-
-# [[Predictive Maintenance (PdM)]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** AI 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Predictive Maintenance (PdM).md]]
----
diff --git a/AI/Predictive-Modeling.md b/AI/Predictive-Modeling.md
deleted file mode 100644
index 4fe2ef56..00000000
--- a/AI/Predictive-Modeling.md
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-2ADF8A
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Predictive-Modeling"
----
-
-# [[Predictive-Modeling]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** AI 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Predictive-Modeling.md]]
----
diff --git a/AI/Predictive-Urban-Modeling.md b/AI/Predictive-Urban-Modeling.md
deleted file mode 100644
index 5c59f978..00000000
--- a/AI/Predictive-Urban-Modeling.md
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-FBB603
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Predictive-Urban-Modeling"
----
-
-# [[Predictive-Urban-Modeling]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** AI 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Predictive-Urban-Modeling.md]]
----
diff --git a/AI/Prefrontal Cortex Dysfunction.md b/AI/Prefrontal Cortex Dysfunction.md
deleted file mode 100644
index 4c94c5d7..00000000
--- a/AI/Prefrontal Cortex Dysfunction.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-A5833A
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Prefrontal Cortex Dysfunction"
----
-
-# [[Prefrontal Cortex Dysfunction]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** AI 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Prefrontal Cortex Dysfunction.md]]
----
diff --git a/AI/Prefrontal-Cortex-Dysfunction.md b/AI/Prefrontal-Cortex-Dysfunction.md
deleted file mode 100644
index cb016890..00000000
--- a/AI/Prefrontal-Cortex-Dysfunction.md
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-832BDA
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Prefrontal-Cortex-Dysfunction"
----
-
-# [[Prefrontal-Cortex-Dysfunction]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** AI 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Prefrontal-Cortex-Dysfunction.md]]
----
diff --git a/AI/Probability Theory (Stochastic Processes).md b/AI/Probability Theory (Stochastic Processes).md
deleted file mode 100644
index be602db9..00000000
--- a/AI/Probability Theory (Stochastic Processes).md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-D3B247
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Probability Theory (Stochastic Processes)"
----
-
-# [[Probability Theory (Stochastic Processes)]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** AI 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Probability Theory (Stochastic Processes).md]]
----
diff --git a/AI/Probability Theory.md b/AI/Probability Theory.md
deleted file mode 100644
index c5a1d2dd..00000000
--- a/AI/Probability Theory.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-28E2A8
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Probability Theory"
----
-
-# [[Probability Theory]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** AI 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Probability Theory.md]]
----
diff --git a/AI/Procedural Content Generation (PCG) Balancing.md b/AI/Procedural Content Generation (PCG) Balancing.md
deleted file mode 100644
index c1d75687..00000000
--- a/AI/Procedural Content Generation (PCG) Balancing.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-231525
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Procedural Content Generation (PCG) Balancing"
----
-
-# [[Procedural Content Generation (PCG) Balancing]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** AI 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Procedural Content Generation (PCG) Balancing.md]]
----
diff --git a/AI/Procedural Content Generation (PCG).md b/AI/Procedural Content Generation (PCG).md
deleted file mode 100644
index bfbe8443..00000000
--- a/AI/Procedural Content Generation (PCG).md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-8E0344
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Procedural Content Generation (PCG)"
----
-
-# [[Procedural Content Generation (PCG)]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** AI 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Procedural Content Generation (PCG).md]]
----
diff --git a/AI/Procedural Content Generation via Machine Learning (PCGML).md b/AI/Procedural Content Generation via Machine Learning (PCGML).md
deleted file mode 100644
index 241da341..00000000
--- a/AI/Procedural Content Generation via Machine Learning (PCGML).md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-234400
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Procedural Content Generation via Machine Learning (PCGML)"
----
-
-# [[Procedural Content Generation via Machine Learning (PCGML)]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** AI 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Procedural Content Generation via Machine Learning (PCGML).md]]
----
diff --git a/AI/Procedural Content Generation.md b/AI/Procedural Content Generation.md
deleted file mode 100644
index f932c1a9..00000000
--- a/AI/Procedural Content Generation.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-7E4074
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Procedural Content Generation"
----
-
-# [[Procedural Content Generation]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** AI 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Procedural Content Generation.md]]
----
diff --git a/AI/Procedural Rhetoric.md b/AI/Procedural Rhetoric.md
deleted file mode 100644
index d0cf89af..00000000
--- a/AI/Procedural Rhetoric.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-DDAA23
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Procedural Rhetoric"
----
-
-# [[Procedural Rhetoric]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** AI 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Procedural Rhetoric.md]]
----
diff --git a/AI/Procedural-Content-Generation (PCG).md b/AI/Procedural-Content-Generation (PCG).md
deleted file mode 100644
index 7c9046d6..00000000
--- a/AI/Procedural-Content-Generation (PCG).md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-D3BC93
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Procedural-Content-Generation (PCG)"
----
-
-# [[Procedural-Content-Generation (PCG)]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** AI 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Procedural-Content-Generation (PCG).md]]
----
diff --git a/AI/Procedural-Content-Generation-via-Machine-Learning.md b/AI/Procedural-Content-Generation-via-Machine-Learning.md
deleted file mode 100644
index 1ecca8bc..00000000
--- a/AI/Procedural-Content-Generation-via-Machine-Learning.md
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-1F2C54
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Procedural-Content-Generation-via-Machine-Learning"
----
-
-# [[Procedural-Content-Generation-via-Machine-Learning]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** AI 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Procedural-Content-Generation-via-Machine-Learning.md]]
----
diff --git a/AI/Procedural-Content-Generation.md b/AI/Procedural-Content-Generation.md
deleted file mode 100644
index 117c8a06..00000000
--- a/AI/Procedural-Content-Generation.md
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-CE4240
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Procedural-Content-Generation"
----
-
-# [[Procedural-Content-Generation]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** AI 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Procedural-Content-Generation.md]]
----
diff --git a/AI/Procedural-Texture-Generation.md b/AI/Procedural-Texture-Generation.md
deleted file mode 100644
index 8db62eec..00000000
--- a/AI/Procedural-Texture-Generation.md
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-5EABE9
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Procedural-Texture-Generation"
----
-
-# [[Procedural-Texture-Generation]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** AI 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Procedural-Texture-Generation.md]]
----
diff --git a/AI/Process Supervision (과정 감독).md b/AI/Process Supervision (과정 감독).md
deleted file mode 100644
index ec4e8b4e..00000000
--- a/AI/Process Supervision (과정 감독).md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-DD3E5C
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Process Supervision (과정 감독)"
----
-
-# [[Process Supervision (과정 감독)]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** AI 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Process Supervision (과정 감독).md]]
----
diff --git a/AI/Product-Types.md b/AI/Product-Types.md
deleted file mode 100644
index d67aaeb6..00000000
--- a/AI/Product-Types.md
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-9999F1
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Product-Types"
----
-
-# [[Product-Types]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** AI 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Product-Types.md]]
----
diff --git a/AI/Prompt Injection (프롬프트 주입 공격).md b/AI/Prompt Injection (프롬프트 주입 공격).md
deleted file mode 100644
index 3459a1b9..00000000
--- a/AI/Prompt Injection (프롬프트 주입 공격).md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-755BF7
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Prompt Injection (프롬프트 주입 공격)"
----
-
-# [[Prompt Injection (프롬프트 주입 공격)]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** AI 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Prompt Injection (프롬프트 주입 공격).md]]
----
diff --git a/AI/Prospect Theory.md b/AI/Prospect Theory.md
deleted file mode 100644
index 5f97c1c9..00000000
--- a/AI/Prospect Theory.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-95BA10
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Prospect Theory"
----
-
-# [[Prospect Theory]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** AI 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Prospect Theory.md]]
----
diff --git a/AI/Prosthetic-Design-Optimization.md b/AI/Prosthetic-Design-Optimization.md
deleted file mode 100644
index 11ce1de9..00000000
--- a/AI/Prosthetic-Design-Optimization.md
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-67AEBB
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Prosthetic-Design-Optimization"
----
-
-# [[Prosthetic-Design-Optimization]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** AI 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Prosthetic-Design-Optimization.md]]
----
diff --git a/AI/Psychophysiology.md b/AI/Psychophysiology.md
deleted file mode 100644
index 78041d1f..00000000
--- a/AI/Psychophysiology.md
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-DD660D
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Psychophysiology"
----
-
-# [[Psychophysiology]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** AI 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Psychophysiology.md]]
----
diff --git a/AI/Pull Request (PR) 워크플로우.md b/AI/Pull Request (PR) 워크플로우.md
deleted file mode 100644
index 66f62ffb..00000000
--- a/AI/Pull Request (PR) 워크플로우.md	
+++ /dev/null
@@ -1,33 +0,0 @@
----
-id: P-REINFORCE-AUTO-47A74B
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Pull Request (PR) 워크플로우"
----
-
-# [[Pull Request (PR) 워크플로우]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> Pull Request (PR) 워크플로우는 소프트웨어 개발 과정에서 코드 변경 사항이 메인 브랜치에 병합(merge)되기 전에 검토, 분석 및 승인되는 핵심 단계입니다 [1, 2]. 현대적인 PR 워크플로우는 인간 개발자의 수동 리뷰와 AI 기반 코드 리뷰, 정적 분석(SAST) 등의 자동화 도구를 결합한 하이브리드 방식을 채택합니다 [3, 4]. 이를 통해 보안 취약점과 버그를 조기에 발견하고 PR 처리 시간을 크게 단축하여 전체적인 소프트웨어 배포의 안정성과 속도를 향상시킵니다 [5, 6].
-
-## 📖 구조화된 지식 (Synthesized Content)
-- **자동화 검증 및 품질 게이트 (Quality Gates) 통합:** PR이 생성되면 즉각적으로 린터(Linter), 정적 애플리케이션 보안 테스트(SAST), AI 리뷰 봇 등이 병렬로 실행되어 코드 변경 사항을 스캔합니다 [1, 7, 8]. 이 과정에서 보안 취약점, 메모리 누수, 코드 스멜 등을 사전에 찾아내며, 조직에서 설정한 코드 품질 및 보안 기준(Quality Gates)을 통과하지 못하면 PR 병합이 시스템적으로 차단됩니다 [9-11].
-- **하이브리드 리뷰(Hybrid Review) 체계:** 가장 효율적인 PR 워크플로우는 기계와 인간의 장점을 결합하여 이루어집니다 [12]. 자동화 도구는 구문 오류, 스타일 위반, 알려진 취약점 등 기계적인 검증과 사전 필터링을 빠르게 처리하여 리뷰어의 피로도를 낮춥니다 [3, 13]. 인간 리뷰어는 도구가 파악할 수 없는 아키텍처 결정의 트레이드오프, 복잡한 비즈니스 로직, 서비스 간의 상호 작용 등 문맥 파악이 필수적인 고차원적 판단에 집중합니다 [3, 4, 14].
-- **경로 기반 라우팅과 필수 승인 (Path-Based Routing):** GitHub의 CODEOWNERS나 GitLab의 승인 규칙 같은 기능을 통해, PR 내에서 변경된 파일 경로(예: 결제 모듈, 인증 로직)에 따라 적절한 전문 팀(보안 팀, 시니어 개발자 등)에게 자동으로 리뷰 요청을 할당합니다 [15, 16]. 자동화된 검사를 통과하고 지정된 검토자의 필수 승인을 모두 확보해야만 코드 병합(Merge)이 활성화되는 다단계 아키텍처를 가집니다 [8, 16].
-- **PR 주기 시간(Cycle Time) 단축 및 지표 관리:** 자동화된 리뷰 어시스턴트를 도입한 조직은 PR 생성부터 병합까지 걸리는 'PR 사이클 타임'과 '첫 리뷰까지의 시간'을 최대 40%까지 단축할 수 있습니다 [3, 5]. 이는 검토 대기열(Backlog)이 쌓이는 병목 현상을 방지하여, 개발자의 컨텍스트 스위칭 비용을 줄이고 배포 빈도(Deployment frequency)를 높이는 핵심 요소로 작용합니다 [5, 17].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** AI 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[수동 코드 리뷰(Manual Code Review)]], [[자동화된 코드 리뷰(Automated Code Review)]], [[정적 애플리케이션 보안 테스트(SAST)]], [[Quality Gates]]
-- **Projects/Contexts:** [[GitHub CODEOWNERS]], [[CI/CD 파이프라인]]
-- **Contradictions/Notes:** 자동화된 AI PR 리뷰 봇은 프로세스를 가속화하지만, 때로는 사소하거나 가치 없는 코멘트를 대량으로 발생시켜 리뷰어에게 '경고 피로(Alert Fatigue)'를 유발할 수 있습니다 [18, 19]. 따라서 자동화 도구는 보조 수단일 뿐, 심층적인 아키텍처 결정은 여전히 인간의 수동 검토에 의존해야 합니다 [18].
-
----
-*Last updated: 2026-04-19*
-- Raw Source: [[00_Raw/2026-04-20/Pull Request (PR) 워크플로우.md]]
----
diff --git a/AI/Pull Request (PR).md b/AI/Pull Request (PR).md
deleted file mode 100644
index 214f2a35..00000000
--- a/AI/Pull Request (PR).md	
+++ /dev/null
@@ -1,37 +0,0 @@
----
-id: P-REINFORCE-AUTO-3B4223
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Pull Request (PR)"
----
-
-# [[Pull Request (PR)]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 풀 리퀘스트(Pull Request, PR)는 소프트웨어 개발 과정에서 개발자가 자신이 수정한 코드를 메인 브랜치에 병합(merge)하기 전, 다른 팀원이나 자동화 도구에게 코드 검토를 요청하는 워크플로우를 의미합니다 [1-3]. 이는 매뉴얼 코드 리뷰와 자동화된 정적 애플리케이션 보안 테스트(SAST) 및 AI 코드 리뷰가 실행되는 주요 환경으로 작용합니다 [1, 3-5]. PR 단계에서 코드의 품질, 보안 취약점, 로직 오류 등을 사전에 식별하고 논의함으로써 프로덕션 환경에 결함이 배포되는 것을 방지하고 유지보수성을 높일 수 있습니다 [4, 6-8].
-
-## 📖 구조화된 지식 (Synthesized Content)
-* **코드 리뷰의 핵심 컨텍스트**
-  풀 리퀘스트 워크플로우는 수동 및 자동화된 코드 리뷰가 이루어지는 필수적인 단계입니다 [3, 4]. 개발자들은 PR을 통해 코드를 병합하기 전에 버그, 보안 취약점, 스타일 위반, 성능 및 유지보수성 문제 등을 종합적으로 평가합니다 [1, 4]. 수동 리뷰에서 동료 개발자들은 PR을 검토하며 비즈니스 로직, 아키텍처 결정, 코드 가독성 등 자동화 도구가 파악하기 어려운 문맥과 의도를 검증합니다 [3, 8]. 동시에 SonarQube, Snyk, Semgrep 등의 정적 분석 도구들은 PR 생성 시 CI/CD 파이프라인과 연동되어 코드를 스캔하고, 품질 기준을 충족하지 못할 경우 병합을 차단하는 게이트(gate) 역할을 수행합니다 [7, 9-11].
-
-* **AI 기반 도구의 PR 통합**
-  최근에는 다양한 AI 기반 코드 리뷰 및 보안 도구들이 PR 워크플로우 내에 직접 통합되어 개발자 경험과 리뷰 속도를 향상시키고 있습니다 [4, 7]. 예를 들어, GitHub Copilot이나 Semgrep Assistant, Snyk Code와 같은 도구는 PR 토론(discussion) 스레드 내에 직접 컨텍스트 기반의 제안을 추가하거나 인라인으로 수정 코드를 제공합니다 [4, 9, 12-14]. 이 과정에서 AI는 단순한 오류 탐지를 넘어 PR 요약본을 생성하고 발견된 취약점에 대한 수정안을 자동으로 검증(Autofix)하여 시니어 개발자 및 리뷰어의 피로도를 크게 줄여줍니다 [12, 15-17].
-
-* **생산성 및 딜리버리 지표 (Metrics)**
-  PR 워크플로우의 효율성은 조직의 소프트웨어 딜리버리 성과를 결정짓는 중요한 요소입니다 [18, 19]. AI 및 자동화 코드 리뷰 도구를 PR에 성공적으로 도입할 경우, 첫 리뷰까지 걸리는 시간(Time to first review)과 전체 PR 사이클 타임(PR cycle time)이 단축되어 최대 40%까지 리뷰 주기를 줄일 수 있습니다 [20, 21]. 결과적으로 PR 백로그가 누적되는 것을 막고 배포 빈도(Deployment frequency)를 높이며, 병합 후 발생하는 재작업(Post-merge rework) 및 핫픽스 비율을 낮추는 데 직접적으로 기여합니다 [20-22].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** AI 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[Code Review]], [[Static Application Security Testing (SAST)]], [[Continuous Integration/Continuous Deployment (CI/CD)]]
-- **Projects/Contexts:** [[DevSecOps]], [[GitHub]]
-- **Contradictions/Notes:** 자동화 및 AI 도구는 PR 내에서 발생하는 문법 오류나 알려진 보안 취약점을 빠르게 찾아내고 수정 제안을 제공하지만, 비즈니스 로직이나 아키텍처, 코드의 근본적인 의도를 파악하는 데에는 한계가 있으므로, 중요하고 민감한 변경 사항에 대해서는 인간 개발자의 수동 PR 리뷰가 반드시 병행되어야 합니다 [3, 8, 23].
-
----
-*Last updated: 2026-04-19*
-- Raw Source: [[00_Raw/2026-04-20/Pull Request (PR).md]]
----
diff --git a/AI/Quality Gates.md b/AI/Quality Gates.md
deleted file mode 100644
index c2adf2ca..00000000
--- a/AI/Quality Gates.md	
+++ /dev/null
@@ -1,33 +0,0 @@
----
-id: P-REINFORCE-AUTO-B577EF
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Quality Gates"
----
-
-# [[Quality Gates]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> Quality Gates(품질 게이트)는 소프트웨어 개발 수명 주기(SDLC)에서 코드 병합이나 배포 전에 사전에 정의된 품질 및 보안 표준을 충족하는지 평가하는 정책 기반의 검사 메커니즘입니다 [1, 2]. 주로 풀 리퀘스트(Pull Request) 단계에서 실행되어 복잡도, 취약점, 중복 등의 지표를 평가한 후 통과(Pass) 또는 실패(Fail) 상태를 이진(binary) 신호로 명확히 할당합니다 [2-4]. 이를 통해 팀은 비공식적인 리뷰 코멘트에 의존하지 않고 객관적인 규칙 세트에 따라 코드 품질을 일관되게 유지하며, 규모에 맞는 안전한 코드 배포를 보장할 수 있습니다 [2, 5].
-
-## 📖 구조화된 지식 (Synthesized Content)
-*   **동작 원리 및 적용 시점:** Quality Gates는 IDE부터 CI/CD 파이프라인 전반에 걸쳐 워크플로우에 통합되어 작동하는 정책 기반의 통제 장치(policy-driven gates)입니다 [1, 6]. 주로 풀 리퀘스트(PR)나 브랜치 병합 전에 코드를 분석하여 사전에 설정된 명시적인 규칙 세트를 만족하는지 확인합니다 [2]. 기준을 충족하지 못하는 "새로운 문제(new issues)"가 발견될 경우 실패(Fail) 신호를 보내어 코드 병합을 직접적으로 차단(merge blocking)합니다 [2].
-*   **개발 워크플로우 및 품질 관리에 미치는 영향:** Quality Gates는 대시보드 형태의 집계뿐만 아니라 PR 수준에서 직접적으로 품질 상태, 코드 중복, 복잡성 및 테스트 커버리지 등의 가시적인 신호를 제공합니다 [3]. 비공식적인 리뷰 코멘트 대신 이진(binary) 형태의 명확한 통과/실패 신호를 부여하기 때문에 실시간으로 개발자의 코드 병합 행동에 즉각적인 영향을 미치며, 시간에 따른 품질 저하(quality drift) 현상을 추적하고 측정할 수 있도록 돕습니다 [2-4].
-*   **컴플라이언스 준수 및 표준화:** 조직 내 여러 리포지토리 전반에 걸쳐 일관된 표준을 강제하여 소프트웨어의 유지보수성과 신뢰성을 향상시킵니다 [1, 7, 8]. 또한 OWASP, ISO/IEC 등과 같은 업계 컴플라이언스와 보안 표준을 충족하는 데 핵심적인 역할을 수행합니다 [8].
-*   **AI 생성 코드 및 도구 연동:** Quality Gates는 사람이 작성한 코드뿐만 아니라 AI가 생성한 코드에 대해서도 동일한 품질 표준을 강제합니다 [9]. 최근의 AI 네이티브 개발 환경에서는 AI 코딩 어시스턴트(예: Cursor, Windsurf)가 직접 Quality Gate 상태를 쿼리(query)하고 피드백을 받을 수 있도록 연동이 지원됩니다 [10]. 나아가 AI가 코드를 자동 수정(Auto-fix)할 때 발생할 수 있는 환각(hallucination) 위험을 검증하고 줄이는 품질 게이트 역할로도 활용됩니다 [11]. 이러한 워크플로우를 강력하게 지원하는 도구로는 SonarQube, Codacy 등이 있습니다 [2, 3, 12].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** AI 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[Static Application Security Testing (SAST)]], [[CI/CD pipelines]], [[Pull Request (PR)]]
-- **Projects/Contexts:** [[SonarQube Cloud]], [[Codacy]], [[AI Code Assurance]]
-- **Contradictions/Notes:** 소스는 팀 내 비공식적인 코드 리뷰 코멘트에 의존하여 병합을 결정하는 것보다, Quality Gates와 같은 명시적인 규칙 세트 기반의 이진 신호(통과/실패)를 통해 병합을 차단하는 방식이 시간이 지남에 따른 품질 변화를 더 명확하게 측정하고 통제할 수 있다고 강조합니다 [2].
-
----
-*Last updated: 2026-04-19*
-- Raw Source: [[00_Raw/2026-04-20/Quality Gates.md]]
----
diff --git a/AI/Quantitative-Usability-Testing.md b/AI/Quantitative-Usability-Testing.md
deleted file mode 100644
index 936664bf..00000000
--- a/AI/Quantitative-Usability-Testing.md
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-8A68D1
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Quantitative-Usability-Testing"
----
-
-# [[Quantitative-Usability-Testing]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** AI 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Quantitative-Usability-Testing.md]]
----
diff --git a/AI/RAG (검색 증강 생성).md b/AI/RAG (검색 증강 생성).md
deleted file mode 100644
index d0b9be70..00000000
--- a/AI/RAG (검색 증강 생성).md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-937086
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - RAG (검색 증강 생성)"
----
-
-# [[RAG (검색 증강 생성)]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** AI 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/RAG (검색 증강 생성).md]]
----
diff --git a/AI/RLAIF (AI 피드백 기반 강화학습).md b/AI/RLAIF (AI 피드백 기반 강화학습).md
deleted file mode 100644
index 56a4fabb..00000000
--- a/AI/RLAIF (AI 피드백 기반 강화학습).md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-77C4FB
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - RLAIF (AI 피드백 기반 강화학습)"
----
-
-# [[RLAIF (AI 피드백 기반 강화학습)]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** AI 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/RLAIF (AI 피드백 기반 강화학습).md]]
----
diff --git a/AI/RLHF (인간 피드백 기반 강화학습).md b/AI/RLHF (인간 피드백 기반 강화학습).md
deleted file mode 100644
index c2e7b021..00000000
--- a/AI/RLHF (인간 피드백 기반 강화학습).md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-628311
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - RLHF (인간 피드백 기반 강화학습)"
----
-
-# [[RLHF (인간 피드백 기반 강화학습)]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** AI 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/RLHF (인간 피드백 기반 강화학습).md]]
----
diff --git a/AI/RL_Neuroscience.md b/AI/RL_Neuroscience.md
deleted file mode 100644
index 4580cf5a..00000000
--- a/AI/RL_Neuroscience.md
+++ /dev/null
@@ -1,29 +0,0 @@
----
-id: P-REINFORCE-AI-003
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.98
-tags: [ai, rl, neuroscience, brain]
-last_reinforced: 2026-04-20
-github_commit: "batch-reinforce-04"
----
-
-# [[RL_Neuroscience (Computational Reinforcement Learning)]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 보상 학습의 생물학적 기제와 기계 학습 알고리즘의 수렴을 통해 지능의 본질을 규명하는 계산 뇌과학의 정점.
-
-## 📖 구조화된 지식 (Synthesized Content)
-- **추출된 패턴:** 환경과의 상호작용에서 얻은 보상 신호를 사용하여 정책(Policy)과 가치 함수(Value Function)를 업데이트하는 순환적 최적화 패턴.
-- **세부 내용:**
-    - TD-Learning(Temporal Difference)과 도파민 신호의 수학적 일치성 입증.
-    - 모델 기반(Model-based) vs 모델 자유(Model-free) 학습의 뇌내 처리 경로 분석.
-    - 탐색(Exploration)과 착취(Exploitation)의 균형을 맞추는 전두엽의 기능 모사.
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 단순 조건 반사 모델에서 미래 가치를 예측하는 '계산적 에이전트' 모델로 확장.
-- **정책 변화:** P-Reinforce 엔진의 핵심 로직(Self-Optimization)을 뒷받침하는 이론적 근거로 최상단 배치.
-
-## 🔗 지식 연결 (Graph)
-- **Parent:** [[10_Wiki/💡 Topics/AI]]
-- **Related:** [[Dopamine]], [[Operant_Conditioning]], [[Reinforcement-Learning]]
-- **Raw Source:** [[00_Raw/2026-04-20/Computational Neuroscience of Reinforcement Learning.md]]
diff --git a/AI/ReAct (Reasoning  Acting).md b/AI/ReAct (Reasoning  Acting).md
deleted file mode 100644
index e94ee50d..00000000
--- a/AI/ReAct (Reasoning  Acting).md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-382E0C
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - ReAct (Reasoning  Acting)"
----
-
-# [[ReAct (Reasoning  Acting)]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** AI 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/ReAct (Reasoning + Acting).md]]
----
diff --git a/AI/Real-Time-Game-Engines.md b/AI/Real-Time-Game-Engines.md
deleted file mode 100644
index 0ffdab01..00000000
--- a/AI/Real-Time-Game-Engines.md
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-9DBB1E
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Real-Time-Game-Engines"
----
-
-# [[Real-Time-Game-Engines]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** AI 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Real-Time-Game-Engines.md]]
----
diff --git a/AI/Redux-Reducers-Design.md b/AI/Redux-Reducers-Design.md
deleted file mode 100644
index 9784b87c..00000000
--- a/AI/Redux-Reducers-Design.md
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-4EB691
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Redux-Reducers-Design"
----
-
-# [[Redux-Reducers-Design]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** AI 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Redux-Reducers-Design.md]]
----
diff --git a/AI/Redux-State-Management.md b/AI/Redux-State-Management.md
deleted file mode 100644
index 962f9c3a..00000000
--- a/AI/Redux-State-Management.md
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-DBA4CB
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Redux-State-Management"
----
-
-# [[Redux-State-Management]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** AI 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Redux-State-Management.md]]
----
diff --git a/AI/Regenerative Design.md b/AI/Regenerative Design.md
deleted file mode 100644
index 8acaf1d5..00000000
--- a/AI/Regenerative Design.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-6EFEA1
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Regenerative Design"
----
-
-# [[Regenerative Design]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** AI 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Regenerative Design.md]]
----
diff --git a/AI/Regenerative-Design.md b/AI/Regenerative-Design.md
deleted file mode 100644
index c7affdd1..00000000
--- a/AI/Regenerative-Design.md
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-9E754B
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Regenerative-Design"
----
-
-# [[Regenerative-Design]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** AI 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Regenerative-Design.md]]
----
diff --git a/AI/Rehabilitative-Medicine.md b/AI/Rehabilitative-Medicine.md
deleted file mode 100644
index 471c45a5..00000000
--- a/AI/Rehabilitative-Medicine.md
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-2E9085
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Rehabilitative-Medicine"
----
-
-# [[Rehabilitative-Medicine]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** AI 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Rehabilitative-Medicine.md]]
----
diff --git a/AI/Reinforcement Learning (RL).md b/AI/Reinforcement Learning (RL).md
deleted file mode 100644
index 6ec2645e..00000000
--- a/AI/Reinforcement Learning (RL).md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-81D53F
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Reinforcement Learning (RL)"
----
-
-# [[Reinforcement Learning (RL)]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** AI 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Reinforcement Learning (RL).md]]
----
diff --git a/AI/Reinforcement Learning for Automated Playtesting.md b/AI/Reinforcement Learning for Automated Playtesting.md
deleted file mode 100644
index 808eb5f3..00000000
--- a/AI/Reinforcement Learning for Automated Playtesting.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-01F691
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Reinforcement Learning for Automated Playtesting"
----
-
-# [[Reinforcement Learning for Automated Playtesting]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** AI 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Reinforcement Learning for Automated Playtesting.md]]
----
diff --git a/AI/Reinforcement Learning in Economics.md b/AI/Reinforcement Learning in Economics.md
deleted file mode 100644
index b06c53f9..00000000
--- a/AI/Reinforcement Learning in Economics.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-169C30
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Reinforcement Learning in Economics"
----
-
-# [[Reinforcement Learning in Economics]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** AI 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Reinforcement Learning in Economics.md]]
----
diff --git a/AI/Reinforcement Learning.md b/AI/Reinforcement Learning.md
deleted file mode 100644
index b8c10a40..00000000
--- a/AI/Reinforcement Learning.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-AE51CB
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Reinforcement Learning"
----
-
-# [[Reinforcement Learning]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** AI 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Reinforcement Learning.md]]
----
diff --git a/AI/Reinforcement Schedules.md b/AI/Reinforcement Schedules.md
deleted file mode 100644
index a5591a2f..00000000
--- a/AI/Reinforcement Schedules.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-8A0BA0
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Reinforcement Schedules"
----
-
-# [[Reinforcement Schedules]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** AI 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Reinforcement Schedules.md]]
----
diff --git a/AI/Resilience Science.md b/AI/Resilience Science.md
deleted file mode 100644
index 0f7a27c1..00000000
--- a/AI/Resilience Science.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-06F1DA
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Resilience Science"
----
-
-# [[Resilience Science]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** AI 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Resilience Science.md]]
----
diff --git a/AI/Resilience-Engineering.md b/AI/Resilience-Engineering.md
deleted file mode 100644
index ec2bebc1..00000000
--- a/AI/Resilience-Engineering.md
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-49D143
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Resilience-Engineering"
----
-
-# [[Resilience-Engineering]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** AI 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Resilience-Engineering.md]]
----
diff --git a/AI/Retainers(유지 경로).md b/AI/Retainers(유지 경로).md
deleted file mode 100644
index 01d62ba6..00000000
--- a/AI/Retainers(유지 경로).md	
+++ /dev/null
@@ -1,40 +0,0 @@
----
-id: P-REINFORCE-AUTO-77A920
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Retainers(유지 경로)"
----
-
-# [[Retainers(유지 경로)]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> Retainers(유지 경로)는 가비지 컬렉터(GC) 루트부터 특정 객체까지 연결된 참조 체인을 의미한다 [1, 2]. 이는 객체가 가비지 컬렉션의 대상이 되지 않고 메모리에 계속 남아있게 만드는 원인을 파악하는 데 사용된다 [1, 2]. 개발자는 Chrome DevTools나 IntelliJ IDEA와 같은 메모리 프로파일링 도구에서 제공하는 Retainers 패널을 통해 이 경로를 역추적하여 메모리 누수의 근본 원인을 식별하고 해결할 수 있다 [3-5].
-
-## 📖 구조화된 지식 (Synthesized Content)
-* **Retainers의 역할 및 정의**
-  Retainers는 선택한 객체를 가리키는 객체들의 목록(역방향 참조 및 루프 포함)을 보여준다 [5, 6]. V8 엔진은 전역 루트(GC root)에서부터 포인터 체인을 통해 도달 가능한 객체를 살아있는(live) 객체로 간주하기 때문에, Retainers는 메모리 누수가 의심되는 객체가 왜 회수되지 않는지를 이해하는 핵심 지표 역할을 한다 [4]. 이 패널은 유출된 객체에서부터 GC 루트로 돌아가는 경로를 역방향으로 표시한다 [4].
-
-* **디버깅 및 메모리 누수 분석**
-  개발자는 힙 스냅샷(Heap Snapshot)이나 할당 타임라인 도구를 사용하여 유출된 객체를 찾아낸 뒤, 해당 객체의 Retainers 트리를 확인하여 GC 루트까지 유지되는 참조 체인을 파악할 수 있다 [2, 3, 7]. 이 유지 경로를 면밀히 검토하면 불필요한 객체가 클로저(Closure) 스코프 등에 의해 계속 참조되고 있는 이유를 파악할 수 있으며, 이를 바탕으로 불필요한 참조를 제거하는 코드 수정이 가능하다 [3, 7, 8]. 
-
-* **도구 내 활용 및 필터링 기능**
-  Chrome DevTools의 Retainers 섹션에서는 특정 항목을 우클릭하여 'Ignore this retainer(이 유지 경로 무시)' 기능을 사용할 수 있다 [9]. 이를 통해 코드를 직접 수정하거나 힙 스냅샷을 다시 찍지 않고도, 해당 참조를 제외했을 때 객체를 계속 유지하게 만드는 다른 경로가 있는지 확인할 수 있다 [9]. 한편, 축소(Minified)된 코드에서는 Retainer 체인을 읽기 어려울 수 있으므로, 의미 있는 함수 및 변수 이름을 얻기 위해서는 소스 맵(Source Maps)을 활용해야 한다 [10].
-
-* **고급 추적 기법**
-  매우 복잡한 형태의 메모리 누수를 분석할 때는 V8 내부 기능인 `%DebugTrackRetainingPath(object)`를 이용할 수 있다 [4, 11]. `--allow-natives-syntax` 및 `--track-retaining-path` 런타임 플래그와 함께 사용하면, 가비지 컬렉션이 발생할 때마다 해당 객체의 실제 유지 경로를 콘솔에 직접 출력하여 DevTools UI의 추상화를 거치지 않고도 저수준의 세부 정보를 확인할 수 있다 [4, 11].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** AI 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[Garbage Collection(GC)]], [[Memory Leak]], [[Heap Snapshot]], [[GC Roots]]
-- **Projects/Contexts:** [[Chrome DevTools Memory Panel]], [[V8 JavaScript Engine]], [[IntelliJ IDEA V8 CPU and Memory Profiling]]
-- **Contradictions/Notes:** 소스에 관련 정보가 부족합니다.
-
----
-*Last updated: 2026-04-19*
-- Raw Source: [[00_Raw/2026-04-20/Retainers(유지 경로).md]]
----
diff --git a/AI/Retaining Path.md b/AI/Retaining Path.md
deleted file mode 100644
index c260709b..00000000
--- a/AI/Retaining Path.md	
+++ /dev/null
@@ -1,39 +0,0 @@
----
-id: P-REINFORCE-AUTO-B5755B
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Retaining Path"
----
-
-# [[Retaining Path]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> Retaining Path(유지 경로)는 가비지 컬렉터가 객체를 메모리에서 해제하지 못하도록 계속 살아있게(live) 만드는 참조의 사슬(chain of references)을 의미합니다 [1, 2]. V8 엔진은 전역 객체나 활성 스택과 같은 GC 루트(GC root)로부터 포인터 사슬을 통해 도달할 수 있는 객체를 살아있는 것으로 판단합니다 [3]. 따라서 이 경로를 분석하는 것은 애플리케이션의 메모리 누수(memory leak) 원인을 식별하고 불필요한 참조를 제거하는 데 핵심적인 역할을 합니다 [4, 5].
-
-## 📖 구조화된 지식 (Synthesized Content)
-- **개념적 원리:** 
-  메모리 누수는 메모리에서 잃어버린 것이 아니라, 객체가 더 이상 사용되지 않음에도 불구하고 GC 루트(예: window, 활성 클로저, 이벤트 리스너, 타이머 등)로부터 계속 연결되어 있어 가비지 컬렉터가 이를 회수하지 못할 때 발생합니다 [1]. Retaining Path는 누수된 객체에서 시작하여 해당 객체를 붙잡고 있는 GC 루트까지 역방향으로 이어지는 참조 체인을 보여줍니다 [3, 5].
-
-- **식별 및 분석 도구:**
-  - **Chrome DevTools (Memory 패널):** 힙 스냅샷(Heap snapshot)이나 할당 타임라인(Allocation timeline) 기능을 통해 객체가 생성된 위치와 해당 객체의 Retaining Path를 파악할 수 있습니다 [2, 6]. Retainers 패널은 선택된 객체를 가리키는 다른 객체들의 트리 구조를 보여줍니다 [4, 7].
-  - **Retainer 숨기기 (Ignore this retainer):** 코드를 직접 수정하여 참조를 제거한 후 힙 스냅샷을 다시 찍는 수고를 덜기 위해, 특정 retainer를 우클릭하여 무시(Ignore)함으로써 다른 객체가 여전히 해당 객체를 유지하고 있는지 빠르게 확인할 수 있습니다 [8].
-  - **`%DebugTrackRetainingPath(object)` 함수:** 극도로 복잡한 누수를 조사할 때는 V8 내부 함수를 활용할 수 있습니다 [3, 9]. `--allow-natives-syntax` 및 `--track-retaining-path` 플래그를 적용하여 실행하면, GC가 발생할 때마다 해당 객체의 실제 Retaining Path가 출력됩니다 [9]. 이 로그는 DevTools UI의 추상화를 우회하여 매우 낮은 수준(low-level)의 메모리 주소와 타입 정보를 제공합니다 [3].
-
-- **디버깅 워크플로우:**
-  메모리 누수 문제를 해결하려면 할당된 채 수집되지 않는 객체를 식별한 뒤, 해당 객체의 Retainer 트리를 클릭하여 GC 루트까지 이어지는 사슬을 추적해야 합니다 [5]. 이 경로를 자세히 검사하면 객체가 수집되지 않은 근본 원인을 이해할 수 있으며, 코드에서 불필요한 참조를 제거하는 정확한 수정이 가능해집니다 [4, 5].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** AI 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[Memory Leak]], [[Garbage Collection]], [[GC Root]], [[Heap Snapshot]]
-- **Projects/Contexts:** [[Chrome DevTools]], [[V8 JavaScript Engine]]
-- **Contradictions/Notes:** 소스 내에 모순된 주장은 존재하지 않습니다. 제공된 자료들은 모두 메모리 누수를 추적하고 V8 엔진에서 객체가 유지되는 이유를 파악하는 데 있어 Retaining Path의 중요성을 일관되게 강조하고 있습니다.
-
----
-*Last updated: 2026-04-19*
-- Raw Source: [[00_Raw/2026-04-20/Retaining Path.md]]
----
diff --git a/AI/Retrograde-Games.md b/AI/Retrograde-Games.md
deleted file mode 100644
index 004442ed..00000000
--- a/AI/Retrograde-Games.md
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-3F21E0
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Retrograde-Games"
----
-
-# [[Retrograde-Games]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** AI 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Retrograde-Games.md]]
----
diff --git a/AI/Reward Hacking (보상 해킹).md b/AI/Reward Hacking (보상 해킹).md
deleted file mode 100644
index 0f3236b4..00000000
--- a/AI/Reward Hacking (보상 해킹).md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-7F2CC8
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Reward Hacking (보상 해킹)"
----
-
-# [[Reward Hacking (보상 해킹)]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** AI 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Reward Hacking (보상 해킹).md]]
----
diff --git a/AI/Reward Prediction Error.md b/AI/Reward Prediction Error.md
deleted file mode 100644
index a8a92180..00000000
--- a/AI/Reward Prediction Error.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-08768A
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Reward Prediction Error"
----
-
-# [[Reward Prediction Error]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** AI 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Reward Prediction Error.md]]
----
diff --git a/AI/Risk Management in Finance.md b/AI/Risk Management in Finance.md
deleted file mode 100644
index e8bf77fb..00000000
--- a/AI/Risk Management in Finance.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-5DD3BE
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Risk Management in Finance"
----
-
-# [[Risk Management in Finance]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** AI 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Risk Management in Finance.md]]
----
diff --git a/AI/Robotic Manipulation Control.md b/AI/Robotic Manipulation Control.md
deleted file mode 100644
index d2cd6c09..00000000
--- a/AI/Robotic Manipulation Control.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-913A3C
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Robotic Manipulation Control"
----
-
-# [[Robotic Manipulation Control]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** AI 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Robotic Manipulation Control.md]]
----
diff --git a/AI/Robotic-Prosthetics-Control-Systems.md b/AI/Robotic-Prosthetics-Control-Systems.md
deleted file mode 100644
index 880bea42..00000000
--- a/AI/Robotic-Prosthetics-Control-Systems.md
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-A360D1
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Robotic-Prosthetics-Control-Systems"
----
-
-# [[Robotic-Prosthetics-Control-Systems]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** AI 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Robotic-Prosthetics-Control-Systems.md]]
----
diff --git a/AI/Robustness (강건성).md b/AI/Robustness (강건성).md
deleted file mode 100644
index 977d25e3..00000000
--- a/AI/Robustness (강건성).md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-EB7908
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Robustness (강건성)"
----
-
-# [[Robustness (강건성)]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** AI 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Robustness (강건성).md]]
----
diff --git a/AI/SAST (Static Application Security Testing).md b/AI/SAST (Static Application Security Testing).md
deleted file mode 100644
index 7ef93731..00000000
--- a/AI/SAST (Static Application Security Testing).md	
+++ /dev/null
@@ -1,27 +0,0 @@
----
-id: P-REINFORCE-SEC-SAST
-category: "[[10_Wiki/💡 Topics/Security]]"
-confidence_score: 0.99
-tags: [SAST, Security, SDLC, Code Analysis]
-last_reinforced: 2026-04-20
----
-
-# [[SAST-(Static-Application-Security-Testing)]] (정적 보안 테스트)
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> "코드를 실행하기도 전에 구멍을 찾아라." 소프트웨어 개발 생명 주기(SDLC)의 가장 앞단(Shift-Left)에서 소스 코드를 스캔하여 보안 취약점을 조기에 격리하는 기술이다.
-
-## 📖 구조화된 지식 (Synthesized Content)
-- **White-box Testing**:
-    - 프로그램의 내부 구조와 소스 코드를 모두 알고 있는 상태에서 진행하는 분석. 데이터 흐름(Data Flow)과 제어 흐름(Control Flow)을 추적한다.
-- **Vulnerability Coverage**:
-    - SQL Injection, Cross-Site Scripting(XSS), Buffer Overflow 등 잘 알려진 보안 패턴(OWASP Top 10 등)을 자동으로 감시한다.
-- **Shift-Left Security**:
-    - 배포 후(DAST)가 아니라 코딩 시점(IDE 통합)에 피드백을 주어, 보안 수정 비용을 수십 배 이상 절감한다.
-
-## ⚠️ 모순 및 업데이트 (RL Update)
-- SAST의 가장 큰 적은 '오탐(False Positive)'이다. 실제로 안전하지만 위험하다고 경고하는 경우가 많아 개발자들의 피로도를 높인다. 이를 해결하기 위해 최근에는 AI가 오탐을 걸러주는 'AI-Driven SAST'가 주류로 자리 잡고 있다.
-
-## 🔗 지식 연결 (Graph)
-- Related: [[Best-SAST-Tools-in-2026]] , [[Deployment_Final_Gate]]
-- Foundation: [[Reliability_Safety_First]]
diff --git a/AI/SAST (정적 애플리케이션 보안 테스트).md b/AI/SAST (정적 애플리케이션 보안 테스트).md
deleted file mode 100644
index 23f8c11d..00000000
--- a/AI/SAST (정적 애플리케이션 보안 테스트).md	
+++ /dev/null
@@ -1,40 +0,0 @@
----
-id: P-REINFORCE-AUTO-4C10C5
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - SAST (정적 애플리케이션 보안 테스트)"
----
-
-# [[SAST (정적 애플리케이션 보안 테스트)]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> SAST(정적 애플리케이션 보안 테스트)는 애플리케이션을 실행하지 않고 소스 코드나 바이트코드 자체를 분석하여 잠재적인 보안 취약점을 찾아내는 화이트박스 테스트(White-box testing) 기법입니다 [1]. 소프트웨어 개발 수명 주기(SDLC)의 초기 단계에 통합되어 결함을 사전에 식별하고 조치함으로써 보안 문제를 빠르고 저렴하게 해결하는 '시프트 레프트(Shift-Left)' 접근법의 핵심입니다 [2-4]. 최근에는 전통적인 규칙 기반의 한계를 극복하기 위해 머신러닝과 LLM을 결합하여 코드의 문맥을 이해하고 오탐을 줄이는 AI 기반 SAST로 발전하고 있습니다 [5, 6].
-
-## 📖 구조화된 지식 (Synthesized Content)
-* **탐지 영역 및 작동 방식:** SAST는 코드가 실행되기 전 구문, 구조, 제어 및 데이터 흐름을 정적으로 분석합니다 [1, 7]. 이 검사를 통해 SQL 인젝션, 크로스 사이트 스크립팅(XSS), 하드코딩된 민감정보(비밀번호 및 API 키), 경로 탐색, 불충분한 입력 검증 등 다양한 보안 결함을 식별합니다 [2, 8, 9].
-* **주요 이점:**
-  * **빠르고 독립적인 분석:** 테스트 케이스를 설계하거나 애플리케이션을 실행할 필요가 없어 전체 코드베이스를 신속하게 스캔할 수 있습니다 [10].
-  * **정확한 위치 안내:** 취약점이 발생한 소스 코드의 정확한 파일 및 줄 번호와 데이터 흐름을 짚어주어 개발자가 즉각적으로 문제를 파악하고 수정할 수 있도록 돕습니다 [10].
-* **전통적인 SAST의 한계점:** 
-  * 애플리케이션 실행 런타임의 컨텍스트나 비즈니스 로직의 의도를 완벽히 이해하지 못하기 때문에 다수의 오탐(False Positives)과 미탐(False Negatives)을 발생시킵니다 [11].
-  * 분석이 사용된 특정 프로그래밍 언어의 지원 여부에 크게 종속된다는 단점이 있습니다 [11].
-* **AI 네이티브(AI-native) SAST의 등장:** 
-  * 기존의 단순 패턴 매칭 규칙을 넘어 머신러닝을 도입한 최신 SAST 엔진(예: Snyk Code의 DeepCode AI, Corgea 등)은 수백만 건의 실제 오픈소스 커밋과 수정 패턴을 학습하여 코드의 의미를 파악합니다 [6, 12, 13].
-  * 여러 모듈이나 함수 경계를 넘어 데이터를 추적하는 파일 간 분석(Interfile analysis)이 가능해졌으며, 탐지된 취약점에 대해 AI가 자동 수정 코드(Auto-remediation)를 제안하고, 개발자에게 불필요한 경고를 줄여줍니다 [14-17].
-* **타 보안 테스트와의 연계:** SAST는 작동 중인 애플리케이션 외부에서 런타임 문제를 진단하는 DAST(동적 애플리케이션 보안 테스트), 서드파티 오픈소스 라이브러리의 취약점을 스캔하는 SCA(소프트웨어 구성 분석) 등과 함께 사용될 때 상호 보완적으로 전체 애플리케이션 보안을 극대화할 수 있습니다 [7, 18-20].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** AI 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[DAST (동적 애플리케이션 보안 테스트)]], [[SCA (소프트웨어 구성 분석)]], [[시프트 레프트 (Shift-Left)]], [[오탐 (False Positive)]], [[코드 리뷰 (Code Review)]]
-- **Projects/Contexts:** [[Snyk Code]], [[Corgea]], [[SonarQube]], [[소프트웨어 개발 수명 주기 (SDLC)]]
-- **Contradictions/Notes:** 소스에 따르면 수동 코드 리뷰는 문맥과 비즈니스 로직, 아키텍처를 깊이 이해하지만 속도가 느리고 비용이 큰 반면, 자동화된 SAST 도구는 매우 빠르고 일관적이지만 코드의 의도를 파악하지 못해 오탐이 발생한다는 뚜렷한 대비가 있습니다 [21-23]. 이에 따라 2025년의 모범 사례는 SAST와 같은 자동화 스캔 도구로 코드 스타일과 일반적인 보안 결함을 1차적으로 걸러내고, 인간 검토자는 자동화가 놓치는 핵심 로직 및 크로스 서비스 영향도 평가에 집중하는 '하이브리드 코드 리뷰' 모델을 채택하는 것입니다 [21, 24, 25].
-
----
-*Last updated: 2026-04-18*
-- Raw Source: [[00_Raw/2026-04-20/SAST (정적 애플리케이션 보안 테스트).md]]
----
diff --git a/AI/SAST (정적 애플리케이션 보안 테스팅).md b/AI/SAST (정적 애플리케이션 보안 테스팅).md
deleted file mode 100644
index e8d599e6..00000000
--- a/AI/SAST (정적 애플리케이션 보안 테스팅).md	
+++ /dev/null
@@ -1,37 +0,0 @@
----
-id: P-REINFORCE-AUTO-8D39DE
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - SAST (정적 애플리케이션 보안 테스팅)"
----
-
-# [[SAST (정적 애플리케이션 보안 테스팅)]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> SAST(정적 애플리케이션 보안 테스팅)는 애플리케이션을 실행하지 않고 소스 코드나 바이트코드를 정적으로 분석하여 보안 취약점을 찾아내는 '화이트박스 테스팅' 기법입니다 [1, 2]. 개발 초기 단계(CI/CD 파이프라인이나 IDE)에 통합되어 취약점이 프로덕션 환경에 도달하기 전에 예방하는 Shift-Left 보안을 실현합니다 [3, 4]. 최근에는 규칙 기반 패턴 매칭의 한계를 넘어, 대형 언어 모델(LLM)과 기계 학습(ML)을 결합하여 문맥을 이해하고 자동으로 코드를 수정해주는 AI 기반 SAST로 진화하고 있습니다 [5-7].
-
-## 📖 구조화된 지식 (Synthesized Content)
-*   **작동 방식 및 주요 탐지 영역:**
-    SAST 도구는 소스 코드를 파싱하여 구문 트리(Syntax Tree)를 구축한 후, 의미론(Semantic), 제어 흐름(Control flow), 데이터 흐름(Data flow), 구조적 분석 등을 적용하여 잠재적 문제를 탐지합니다 [8-10]. 이를 통해 인젝션 결함(SQL, NoSQL, Command 등), 크로스 사이트 스크립팅(XSS), 경로 탐색, 하드코딩된 자격 증명(비밀번호, API 키), 취약한 암호화, 메모리 관리 문제, 잘못 구성된 설정 등을 찾아냅니다 [1, 2, 11]. 
-*   **SAST의 주요 장점:**
-    SAST는 코드를 실행하거나 별도의 테스트 케이스를 작성할 필요가 없으며, 개발자가 코드를 작성하는 즉시 실시간(Real-time)으로 매우 빠르게 스캔할 수 있습니다 [12, 13]. 문제가 있는 코드의 정확한 위치와 데이터 흐름을 짚어주기 때문에 취약점을 조기에 수정할 수 있어 시간과 비용을 크게 절약합니다 [13, 14].
-*   **기존 SAST의 한계점:**
-    기존 SAST 도구들은 실행 런타임의 컨텍스트나 비즈니스 로직의 의도를 온전히 파악하지 못해 오탐지(False Positive)를 많이 발생시키며(일부 레거시 도구의 경우 50~80%), 이로 인해 개발자가 알림 피로도(Alert fatigue)를 느끼게 됩니다 [15, 16]. 또한, 특정 프로그래밍 언어에 대한 의존성이 강하며, 프론트엔드와 백엔드를 오가는 복잡한 데이터 흐름을 완벽히 쫓아가지 못하는 한계가 있습니다 [9, 16].
-*   **AI 기반 SAST의 등장:**
-    최근의 SAST는 단순한 정적 패턴 매칭을 넘어 LLM 등 AI 엔진을 도입하여 맥락을 이해하는 방향으로 발전하고 있습니다 [3, 5]. AI 기반 SAST(예: Corgea, Snyk Code 등)는 규칙만으로는 표현할 수 없는 복잡한 비즈니스 로직의 결함을 탐지하고, 오탐을 크게 줄여줍니다 [6, 7, 17]. 나아가 식별된 문제에 대해 실행 가능한 코드 패치(Auto-fix)를 자동으로 제안하고 검증하는 기능까지 제공합니다 [5, 18].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** AI 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[DAST (동적 애플리케이션 보안 테스팅)]], [[SCA (소프트웨어 구성 분석)]], [[AI-powered SAST]], [[수동 코드 리뷰 (Manual Code Review)]]
-- **Projects/Contexts:** [[Shift-Left 보안]], [[CI/CD 및 IDE 통합]], [[OWASP Top 10]]
-- **Contradictions/Notes:** 자동화된 SAST는 매우 빠르고 일관되게 코드를 검사하지만 비즈니스 로직과 의도를 파악하는 데는 맹점이 존재하므로(Context Blindness), 런타임 환경을 분석하는 DAST 또는 설계와 맥락을 깊이 이해하는 수동 코드 리뷰(Manual Review)와 결합된 하이브리드 접근 방식이 권장됩니다 [15, 19, 20].
-
----
-*Last updated: 2026-04-18*
-- Raw Source: [[00_Raw/2026-04-20/SAST (정적 애플리케이션 보안 테스팅).md]]
----
diff --git a/AI/SAST.md b/AI/SAST.md
deleted file mode 100644
index 611fd4cd..00000000
--- a/AI/SAST.md
+++ /dev/null
@@ -1,30 +0,0 @@
----
-id: P-REINFORCE-AUTO-205541
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - SAST"
----
-
-# [[SAST]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> SAST(Static Application Security Testing, 정적 애플리케이션 보안 테스트)는 애플리케이션을 실행하지 않고 소스 코드, 바이트코드 또는 바이너리를 정적으로 분석하여 보안 취약점을 찾아내는 화이트박스 테스트 기법입니다 [1-3]. 개발 초기 단계인 IDE나 CI/CD 파이프라인에 통합되어 결함을 사전에 해결하는 '시프트 레프트(Shift-left)' 보안 접근법의 핵심적인 역할을 수행합니다 [4-7]. 최근에는 높은 오탐률(False Positive)과 문맥 파악의 한계를 극복하기 위해 머신러닝(ML)과 대규모 언어 모델(LLM)을 결합한 AI 기반 SAST로 진화하여 더욱 정확한 탐지와 자동 수정(Auto-fix) 기능을 제공하고 있습니다 [8-10].
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** AI 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[DAST]], [[SCA]], [[IAST]], [[Shift-Left]], [[False Positives]]
-- **Projects/Contexts:** [[CI/CD Pipeline Integration]], [[Snyk Code]], [[Corgea]], [[Checkmarx]], [[SonarQube]]
-- **Contradictions/Notes:** 자동화된 SAST 도구는 코드 기반의 패턴 매칭에 빠르고 일관되지만, 복잡한 비즈니스 로직과 아키텍처 트레이드오프를 이해하지 못하므로, 완벽한 보안과 코드 품질 확보를 위해서는 인간 개발자가 직접 수행하는 수동 코드 리뷰(Manual Code Review)를 반드시 병행해야 한다고 강조됩니다 [16, 26-28].
-
----
-*Last updated: 2026-04-19*
-- Raw Source: [[00_Raw/2026-04-20/SAST.md]]
----
diff --git a/AI/SDLC (소프트웨어 개발 수명 주기).md b/AI/SDLC (소프트웨어 개발 수명 주기).md
deleted file mode 100644
index 9e5af0ed..00000000
--- a/AI/SDLC (소프트웨어 개발 수명 주기).md	
+++ /dev/null
@@ -1,33 +0,0 @@
----
-id: P-REINFORCE-AUTO-9A0FE1
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - SDLC (소프트웨어 개발 수명 주기)"
----
-
-# [[SDLC (소프트웨어 개발 수명 주기)]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> SDLC(소프트웨어 개발 수명 주기)는 소프트웨어를 개발하고 유지보수하기 위해 조직에서 사용하는 전체 프로세스입니다 [1, 2]. 현대의 SDLC는 코드 생성 및 디버깅을 돕는 AI 도구들이 필수적으로 통합되고 있으며, 이에 따라 초기 단계부터 보안 및 품질 검증을 수행하는 것이 매우 중요해졌습니다 [2, 3]. 특히 정적 분석(SAST) 및 자동화된 코드 리뷰 도구를 SDLC 전반에 통합하여 취약점과 결함을 조기에 발견하고 안전한 코드를 대규모로 배포하는 데 중점을 둡니다 [1, 4].
-
-## 📖 구조화된 지식 (Synthesized Content)
-- **보안의 조기 통합 (Shift-Left):** SDLC의 초기 단계부터 정적 애플리케이션 보안 테스트(SAST) 및 실시간 코드 검사를 통합하면, 보안 취약점, 유지보수성 문제 및 논리적 결함을 배포 전에 미리 발견할 수 있습니다 [1, 3]. SDLC 초기에 스캔을 시작하여 기준선을 설정하고, 이후 각 단계에 걸쳐 코드를 자주 스캔함으로써 새롭게 발생하는 보안 문제를 지속적으로 포착해야 합니다 [5].
-- **SDLC 거버넌스와 품질 게이트 (Quality Gates):** SDLC 전반에 걸쳐 동기화된 품질 게이트(Quality Gates)를 적용하면 조직이 대규모 환경에서도 일관된 고품질의 안전한 코드를 제공할 수 있습니다 [4]. 또한 SDLC 거버넌스는 AI가 생성한 코드와 인간 개발자의 표준을 일치시키고, 보안 및 규정 준수를 자동화하는 데 핵심적인 역할을 합니다 [6, 7].
-- **AI 도구의 도입 및 위험 관리:** GitHub Copilot이나 ChatGPT 같은 AI 도구들은 SDLC에서 빼놓을 수 없는 필수 요소로 자리 잡으며 생산성을 높이고 있습니다 [2]. 그러나 이러한 강력한 도구의 통제되지 않은 사용은 지적 재산 유출이나 코드 품질 저하 등의 보안 취약점을 유발할 수 있으므로, SDLC 내에서 안전하게 AI를 활용하기 위한 명확한 사용 정책과 보안 도구의 결합이 요구됩니다 [2, 8].
-- **보안 소프트웨어 개발 수명 주기 (SSDLC):** 개발 프로세스의 모든 단계(코드 리뷰, 병합 방식, 브랜칭 정책, 보안 코딩 가이드라인 등)에 보안을 내재화하여 SSDLC(안전한 소프트웨어 개발 수명 주기) 또는 DevSecOps 환경을 구축하는 것이 현대 소프트웨어 개발의 모범 사례로 권장됩니다 [3, 8, 9].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** AI 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[SAST (정적 애플리케이션 보안 테스트)]], [[Quality Gates (품질 게이트)]], [[SSDLC (안전한 소프트웨어 개발 수명 주기)]], [[AI Code Review (AI 코드 리뷰)]]
-- **Projects/Contexts:** [[SonarQube]], [[Snyk]], [[GitHub Code Security]]
-- **Contradictions/Notes:** 소스에 따르면 SDLC에 AI 도구가 빠르게 도입되어 생산성이 혁신적으로 향상되고 있으나, 이를 뒷받침할 적절한 거버넌스와 보안 정책(SAST 도구 검사 등)이 동반되지 않을 경우 오히려 심각한 보안 취약점과 기술 부채의 증가를 초래할 수 있다고 경고합니다 [2].
-
----
-*Last updated: 2026-04-18*
-- Raw Source: [[00_Raw/2026-04-20/SDLC (소프트웨어 개발 수명 주기).md]]
----
diff --git a/AI/SFT (Supervised Fine-Tuning).md b/AI/SFT (Supervised Fine-Tuning).md
deleted file mode 100644
index befa3546..00000000
--- a/AI/SFT (Supervised Fine-Tuning).md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-ACC5DA
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - SFT (Supervised Fine-Tuning)"
----
-
-# [[SFT (Supervised Fine-Tuning)]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** AI 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/SFT (Supervised Fine-Tuning).md]]
----
diff --git a/AI/SHACL (Shapes Constraint Language).md b/AI/SHACL (Shapes Constraint Language).md
deleted file mode 100644
index 4b9b4087..00000000
--- a/AI/SHACL (Shapes Constraint Language).md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-B7C59C
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - SHACL (Shapes Constraint Language)"
----
-
-# [[SHACL (Shapes Constraint Language)]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** AI 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/SHACL (Shapes Constraint Language).md]]
----
diff --git a/AI/STEM Laboratory Virtualization.md b/AI/STEM Laboratory Virtualization.md
deleted file mode 100644
index 24c6090f..00000000
--- a/AI/STEM Laboratory Virtualization.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-E8F7C8
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - STEM Laboratory Virtualization"
----
-
-# [[STEM Laboratory Virtualization]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** AI 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/STEM Laboratory Virtualization.md]]
----
diff --git a/AI/Scaffolding (Instructional Technique).md b/AI/Scaffolding (Instructional Technique).md
deleted file mode 100644
index fee5e97f..00000000
--- a/AI/Scaffolding (Instructional Technique).md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-B407CA
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Scaffolding (Instructional Technique)"
----
-
-# [[Scaffolding (Instructional Technique)]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** AI 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Scaffolding (Instructional Technique).md]]
----
diff --git a/AI/Scheduling-and-Timetabling.md b/AI/Scheduling-and-Timetabling.md
deleted file mode 100644
index 3c2d8903..00000000
--- a/AI/Scheduling-and-Timetabling.md
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-FEBDAB
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Scheduling-and-Timetabling"
----
-
-# [[Scheduling-and-Timetabling]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** AI 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Scheduling-and-Timetabling.md]]
----
diff --git a/AI/Section-508-Compliance.md b/AI/Section-508-Compliance.md
deleted file mode 100644
index e6c1c5cd..00000000
--- a/AI/Section-508-Compliance.md
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-A56544
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Section-508-Compliance"
----
-
-# [[Section-508-Compliance]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** AI 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Section-508-Compliance.md]]
----
diff --git a/AI/Security-Governance.md b/AI/Security-Governance.md
deleted file mode 100644
index 0e42f4ee..00000000
--- a/AI/Security-Governance.md
+++ /dev/null
@@ -1,27 +0,0 @@
----
-id: P-REINFORCE-SEC-GOV
-category: "[[10_Wiki/💡 Topics/Security]]"
-confidence_score: 0.98
-tags: [Security Governance, Policy, Risk Management, Compliance]
-last_reinforced: 2026-04-20
----
-
-# [[Security-Governance]] (보안 거버넌스)
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> "보안은 기술의 문제가 아니라 의사결정의 제도 모델이다." 조직 전체의 위험(Risk)을 관리하고, 보안이 사업의 영속성을 보장하도록 설계된 최고 의사결정 체계다.
-
-## 📖 구조화된 지식 (Synthesized Content)
-- **Risk Assessment Framework**:
-    - 우리 자산 중 무엇이 가장 소중한지 파악하고, 위협 발생 시의 파급력(Impact)과 가능성(Likelihood)을 정량적으로 산출한다.
-- **Roles and Responsibilities (R&R)**:
-    - CISO(정보보호최고책임자)부터 현업 개발자까지 각자가 져야 할 보안적 책임을 명확히 정의한다.
-- **Identity and Access Management (IAM)**:
-    - "최소 권한의 원칙(Least Privilege)". 누구에게 어떤 파일에 대한 접근권을 줄지 엄격히 통제하는 거버넌스의 최전선이다.
-
-## ⚠️ 모순 및 업데이트 (RL Update)
-- 거버넌스가 너무 엄격하면 생산성을 파괴한다. 현대의 '자율적 거버넌스'는 개발자의 창의성을 억누르는 금지 조항이 아니라, 안전하게 개발할 수 있는 '안전 가이드라인'과 셀프 서비스 도구를 제공하는 방향으로 진화하고 있다.
-
-## 🔗 지식 연결 (Graph)
-- Related: [[Collaboration_Governance]] , [[Deployment_Final_Gate]]
-- Foundation: [[Reliability_Safety_First]]
diff --git a/AI/Segmentsai.md b/AI/Segmentsai.md
deleted file mode 100644
index 0866f322..00000000
--- a/AI/Segmentsai.md
+++ /dev/null
@@ -1,33 +0,0 @@
----
-id: P-REINFORCE-AUTO-A08DC7
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Segmentsai"
----
-
-# [[Segmentsai]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> Segments.ai는 수백만 개의 3D 포인트와 원활하게 상호작용할 수 있는 기능을 제공하는 3D 분할(segmentation) 플랫폼이자 라이다(LiDAR) 포인트 클라우드 라벨링 도구입니다 [1, 2]. 2025년에서 2026년 사이에 렌더링 파이프라인을 WebGL에서 WebGPU로 성공적으로 전환하여 100배의 성능 향상을 달성했습니다 [1, 3]. 이 플랫폼은 깊은 그래픽스 전문 지식 없이도 Three.js를 활용하여 특화된 성능 최적화를 구현한 대표적인 사례입니다 [2].
-
-## 📖 구조화된 지식 (Synthesized Content)
-* **라이다(LiDAR) 포인트 클라우드 라벨링 도구:** Segments.ai는 방대한 3D 포인트 클라우드 데이터를 처리하고 라벨링하는 도구를 제공하는 3D 분할 플랫폼입니다 [1].
-* **WebGPU로의 성공적인 마이그레이션:** 2025년과 2026년 사이에 기존의 WebGL 기반 시스템에서 Three.js의 WebGPURenderer를 사용하는 WebGPU 환경으로 성공적으로 마이그레이션했습니다 [1, 2]. 이 프로젝트는 크리에이티브 스튜디오인 Utsubo의 작업 포트폴리오에도 주요 성과로 포함되어 있습니다 [3].
-* **100배의 성능 향상(100x performance boost):** WebGPU로의 전환을 통해 기존 대비 100배에 달하는 극적인 성능 향상을 이뤄냈습니다 [1-3].
-* **대규모 데이터 처리의 효율성 확보:** 이러한 렌더링 성능 개선 덕분에 수백만 개의 점으로 구성된 방대한 데이터셋에서도 끊김 없이 부드럽고 원활한 상호작용(seamless interaction)이 가능해졌습니다 [1, 2].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** AI 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[WebGPU]], [[Three.js]], [[WebGL]], [[LiDAR point cloud]]
-- **Projects/Contexts:** [[Utsubo]], [[Three.js WebGPU 마이그레이션 사례]]
-- **Contradictions/Notes:** 소스에 관련하여 모순되는 정보는 없습니다.
-
----
-*Last updated: 2026-04-19*
-- Raw Source: [[00_Raw/2026-04-20/Segments.ai.md]]
----
diff --git a/AI/Self-Consistency (자기 일관성 디코딩).md b/AI/Self-Consistency (자기 일관성 디코딩).md
deleted file mode 100644
index 1cbae5eb..00000000
--- a/AI/Self-Consistency (자기 일관성 디코딩).md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-E25B8B
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Self-Consistency (자기 일관성 디코딩)"
----
-
-# [[Self-Consistency (자기 일관성 디코딩)]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** AI 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Self-Consistency (자기 일관성 디코딩).md]]
----
diff --git a/AI/Self-Organized Criticality.md b/AI/Self-Organized Criticality.md
deleted file mode 100644
index 69cb80dd..00000000
--- a/AI/Self-Organized Criticality.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-01E518
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Self-Organized Criticality"
----
-
-# [[Self-Organized Criticality]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** AI 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Self-Organized Criticality.md]]
----
diff --git a/AI/Self-Play (자기 대결 기반 강화학습).md b/AI/Self-Play (자기 대결 기반 강화학습).md
deleted file mode 100644
index c72008ba..00000000
--- a/AI/Self-Play (자기 대결 기반 강화학습).md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-4CE048
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Self-Play (자기 대결 기반 강화학습)"
----
-
-# [[Self-Play (자기 대결 기반 강화학습)]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** AI 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Self-Play (자기 대결 기반 강화학습).md]]
----
diff --git a/AI/Self-Regulation.md b/AI/Self-Regulation.md
deleted file mode 100644
index 76a415f7..00000000
--- a/AI/Self-Regulation.md
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-70F3AC
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Self-Regulation"
----
-
-# [[Self-Regulation]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** AI 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Self-Regulation.md]]
----
diff --git a/AI/Semantic Grounding  Provenance.md b/AI/Semantic Grounding  Provenance.md
deleted file mode 100644
index c5febfd4..00000000
--- a/AI/Semantic Grounding  Provenance.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-479D8D
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Semantic Grounding  Provenance"
----
-
-# [[Semantic Grounding  Provenance]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** AI 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Semantic Grounding & Provenance.md]]
----
diff --git a/AI/Semgrep Assistant.md b/AI/Semgrep Assistant.md
deleted file mode 100644
index 777c4e9f..00000000
--- a/AI/Semgrep Assistant.md	
+++ /dev/null
@@ -1,41 +0,0 @@
----
-id: P-REINFORCE-AUTO-484EAB
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Semgrep Assistant"
----
-
-# [[Semgrep Assistant]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> Semgrep Assistant는 빠른 패턴 매칭 기반의 정적 분석 도구인 Semgrep에 대형 언어 모델(LLM)을 결합하여 코드 리뷰 및 보안 분석을 고도화한 솔루션입니다. 이 도구는 노이즈 필터링, 취약점 결과 설명, 그리고 Pull Request(PR) 워크플로우 내에서의 자동 수정(autofix) 제안 등의 AI 기반 기능을 제공합니다. 과거의 트리아지(triage) 결정을 재사용하고 상황적 맥락(context)을 이해함으로써 오탐지(False Positives)를 대폭 줄여주며, 결과적으로 보안 엔지니어와 개발 플랫폼 팀의 분석 병목 현상을 해소하는 데 적합합니다.
-
-## 📖 구조화된 지식 (Synthesized Content)
-**주요 기능 및 AI 활용 방식**
-* **노이즈 필터링 (Noise Filtering):** 완화 가능한 컨텍스트(mitigating context)를 파악하여 가능성이 높은 오탐지(False Positives)를 억제합니다. Semgrep 측에 따르면 해당 기능을 켜는 당일에 20%의 노이즈가 감소하며, 최대 98%까지 오탐지를 필터링할 수 있습니다. 
-* **메모리(Memories) 및 자동 트리아지:** 사용자의 과거 트리아지(triage) 결정 사항을 기억하고 재사용하여 동일한 분석 작업을 반복하지 않도록 방지합니다.
-* **개발자 친화적인 PR 중심 워크플로우:** 발견된 보안 이슈에 대한 설명과 수정(remediation) 가이드가 개발자가 실제 작업하는 Pull Request 내에 직접 표시되어 신속한 문제 해결을 돕습니다.
-
-**주요 강점 (Key Strengths)**
-* **오픈소스 생태계와 속도:** 강력한 커뮤니티 룰(rule) 라이브러리를 보유한 오픈소스 기반 도구로, CI 스캔 시간이 중간값 기준 약 10초에 불과할 정도로 매우 빠르고 오버헤드가 적습니다.
-* **높은 정확성 입증:** 보안 중심의 구성(security-focused configuration) 하에서 진행된 독립적인 테스트(Doyensec) 결과, OWASP 벤치마크에서 오탐지 0건을 기록하며 정확성을 입증했습니다.
-
-**잠재적 한계점 (Potential Limitations)**
-* **기능 지원의 제한:** 커스텀 룰이나 커뮤니티 룰에서는 Assistant의 일부 기능이 작동하지 않을 수 있습니다.
-* **베타 기능 및 구조적 한계:** 핵심 기능 중 하나인 노이즈 필터링이 여전히 '베타(beta)'로 명시되어 있어 대규모 도입 시 주의가 필요합니다. 또한 기반 기술이 '패턴 매칭'에 의존하기 때문에, 복잡한 비즈니스 로직이나 교차 파일(cross-file) 간의 데이터 흐름 문제를 탐지하는 데는 근본적인 한계가 존재합니다.
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** AI 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[Static Application Security Testing (SAST)]], [[False Positive]], [[Pull Request (PR)]], [[LLM (Large Language Model)]]
-- **Projects/Contexts:** [[DevSecOps Workflow]], [[AppSec (Application Security)]]
-- **Contradictions/Notes:** 소스 분석에 따르면 Semgrep Assistant는 독립된 테스트에서 OWASP 벤치마크 기준 오탐지(False Positives) 제로(0)를 기록할 만큼 강력한 신호(signal)를 제공하지만, 동시에 AI 기반의 노이즈 필터링 기능은 공식적으로 '베타(beta)' 상태이므로 엔터프라이즈 규모로 운영 시 이를 인지하고 적용해야 한다는 상충되는 주의 사항이 존재합니다.
-
----
-*Last updated: 2026-04-18*
-- Raw Source: [[00_Raw/2026-04-20/Semgrep Assistant.md]]
----
diff --git a/AI/Serious Games.md b/AI/Serious Games.md
deleted file mode 100644
index 982269ee..00000000
--- a/AI/Serious Games.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-4A3ECC
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Serious Games"
----
-
-# [[Serious Games]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** AI 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Serious Games.md]]
----
diff --git a/AI/Service-Design-Blueprinting.md b/AI/Service-Design-Blueprinting.md
deleted file mode 100644
index 8c277099..00000000
--- a/AI/Service-Design-Blueprinting.md
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-07A1AA
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Service-Design-Blueprinting"
----
-
-# [[Service-Design-Blueprinting]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** AI 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Service-Design-Blueprinting.md]]
----
diff --git a/AI/Shannon-Entropy.md b/AI/Shannon-Entropy.md
deleted file mode 100644
index 45f65bc6..00000000
--- a/AI/Shannon-Entropy.md
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-2A9F66
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Shannon-Entropy"
----
-
-# [[Shannon-Entropy]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** AI 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Shannon-Entropy.md]]
----
diff --git a/AI/SimCity (as a model of systemic interaction).md b/AI/SimCity (as a model of systemic interaction).md
deleted file mode 100644
index 8bdfa7d4..00000000
--- a/AI/SimCity (as a model of systemic interaction).md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-10C76A
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - SimCity (as a model of systemic interaction)"
----
-
-# [[SimCity (as a model of systemic interaction)]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** AI 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/SimCity (as a model of systemic interaction).md]]
----
diff --git a/AI/Simulated History.md b/AI/Simulated History.md
deleted file mode 100644
index cec80aef..00000000
--- a/AI/Simulated History.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-DEC9B0
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Simulated History"
----
-
-# [[Simulated History]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** AI 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Simulated History.md]]
----
diff --git a/AI/Simulator Sickness Questionnaire (SSQ).md b/AI/Simulator Sickness Questionnaire (SSQ).md
deleted file mode 100644
index 6a3fef07..00000000
--- a/AI/Simulator Sickness Questionnaire (SSQ).md	
+++ /dev/null
@@ -1,36 +0,0 @@
----
-id: P-REINFORCE-AUTO-73720A
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Simulator Sickness Questionnaire (SSQ)"
----
-
-# [[Simulator Sickness Questionnaire (SSQ)]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 시뮬레이터 멀미 설문지(Simulator Sickness Questionnaire, SSQ)는 가상현실(VR) 및 시뮬레이터 연구에서 가상현실 멀미 증상을 자가 보고 방식으로 측정하기 위해 가장 널리 사용되는 도구입니다 [1]. 16개의 증상 목록을 바탕으로 0(없음)에서 3(심각함)까지의 4점 척도로 평가하며, 측정된 증상은 크게 메스꺼움, 안구 운동, 방향 감각 상실의 세 가지 하위 범주로 분류됩니다 [1].
-
-## 📖 구조화된 지식 (Synthesized Content)
-- **구조 및 척도:** SSQ는 16개의 증상 항목으로 구성된 인벤토리로, 사용자는 각 증상의 심각도를 0점(없음)부터 3점(심각함)까지의 4점 척도로 평가합니다 [1].
-- **증상 하위 척도(Subscales):** 증상 클러스터는 3가지 범주로 나뉘며, 일부 증상은 다른 하위 척도와 중복되어 포함됩니다 [1].
-  - **메스꺼움(Nausea):** 타액 분비 증가, 트림, 위장 자극(stomach awareness) 등 위장 불편감과 관련된 7가지 증상 [1].
-  - **안구 운동(Oculomotor):** 눈의 피로, 피로감, 초점 맞추기 등과 관련된 7가지 증상 [1].
-  - **방향 감각 상실(Disorientation):** 현기증 및 현훈(vertigo)과 관련된 7가지 증상 [1].
-- **점수 산출 및 분류:** 원시 점수(Raw scores)는 총점과 각 하위 척도 점수를 계산하기 위해 서로 다른 가중치가 적용됩니다 [1]. 가중치가 적용된 SSQ 점수는 멀미 수준에 따라 '낮음(0-10)', '중간(10 초과-20)', '높음(20 초과)'의 3단계로 분류될 수 있습니다 [2]. 특히, 총점이 20점을 초과할 경우 해당 시뮬레이터는 문제가 있는(problem simulator) 것으로 간주됩니다 [3].
-- **활용 및 연구 결과:** VR 게임 및 시뮬레이션 경험이 사용자에게 미치는 부작용을 연구할 때 주로 사용됩니다 [1]. 예를 들어, 신체 활동을 동반하는 VR 게임 연구에서는 노출 직후 SSQ 총점과 하위 척도 점수가 모두 크게 증가하는 것으로 나타났습니다 [4, 5].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** AI 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[Virtual Reality Sickness]], [[Nausea]], [[Oculomotor]], [[Disorientation]]
-- **Projects/Contexts:** [[Beat Saber Exergaming Study]]
-- **Contradictions/Notes:** 연구에 따르면 SSQ 점수가 20점 이상일 경우 문제가 있는 시뮬레이터로 판단하지만, 이러한 높은 SSQ 점수가 사용자의 실제 일상생활 수행 능력 저하와 어떻게 연결되는지에 대해서는 아직 명확히 밝혀지지 않았으며 이는 향후 VR의 안전한 사용을 위해 해결해야 할 지식의 공백으로 남아있습니다 [3].
-
----
-*Last updated: 2026-04-19*
-- Raw Source: [[00_Raw/2026-04-20/Simulator Sickness Questionnaire (SSQ).md]]
----
diff --git a/AI/Single-Source-of-Truth.md b/AI/Single-Source-of-Truth.md
deleted file mode 100644
index 713f6863..00000000
--- a/AI/Single-Source-of-Truth.md
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-9158CA
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Single-Source-of-Truth"
----
-
-# [[Single-Source-of-Truth]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** AI 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Single-Source-of-Truth.md]]
----
diff --git a/AI/Singularity (기술적 특이점).md b/AI/Singularity (기술적 특이점).md
deleted file mode 100644
index ed90d836..00000000
--- a/AI/Singularity (기술적 특이점).md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-04DB11
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Singularity (기술적 특이점)"
----
-
-# [[Singularity (기술적 특이점)]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** AI 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Singularity (기술적 특이점).md]]
----
diff --git a/AI/Skybound Protocol 구조 및 의존성 분석 (Dependency Mapping).md b/AI/Skybound Protocol 구조 및 의존성 분석 (Dependency Mapping).md
deleted file mode 100644
index 006cd5f6..00000000
--- a/AI/Skybound Protocol 구조 및 의존성 분석 (Dependency Mapping).md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-A04161
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Skybound Protocol 구조 및 의존성 분석 (Dependency Mapping)"
----
-
-# [[Skybound Protocol 구조 및 의존성 분석 (Dependency Mapping)]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** AI 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Skybound Protocol 구조 및 의존성 분석 (Dependency Mapping).md]]
----
diff --git a/AI/Skybound Protocol 데이터 및 제어 흐름 (Control Flow).md b/AI/Skybound Protocol 데이터 및 제어 흐름 (Control Flow).md
deleted file mode 100644
index 3ddfbb82..00000000
--- a/AI/Skybound Protocol 데이터 및 제어 흐름 (Control Flow).md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-1B8F72
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Skybound Protocol 데이터 및 제어 흐름 (Control Flow)"
----
-
-# [[Skybound Protocol 데이터 및 제어 흐름 (Control Flow)]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** AI 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Skybound Protocol 데이터 및 제어 흐름 (Control Flow).md]]
----
diff --git a/AI/Skybound Protocol 코드리뷰.md b/AI/Skybound Protocol 코드리뷰.md
deleted file mode 100644
index 60250a11..00000000
--- a/AI/Skybound Protocol 코드리뷰.md	
+++ /dev/null
@@ -1,37 +0,0 @@
----
-id: P-REINFORCE-AUTO-274080
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Skybound Protocol 코드리뷰"
----
-
-# [[Skybound Protocol 코드리뷰]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> **Skybound Protocol**은 React와 TypeScript로 구현된 고성능 아카이브 스타일 슈팅 게임 엔진입니다. "Code-as-Data" 원칙에 따라 모든 게임 밸런스와 AI 행동 양식을 상수화하여 관리하며, 수만 개의 파티클과 복잡한 탄막 패턴을 웹 브라우저에서 60FPS로 유지하도록 최적화되어 있습니다.
-
-## 📖 구조화된 지식 (Synthesized Content)
-
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** AI 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[React Game Development]], [[Entity Component System (ECS)]], [[Canvas Physics]], [[Data-Driven Design]]
-- **Projects/Contexts:** [[Antigravity Games]], [[Technical Bible Project]]
-- **Contradictions/Notes:** 
-    - **연산 최적화:** 현재 모든 거리 계산에 `Math.hypot`을 사용 중이나, 개체가 수천 개로 늘어날 경우 제곱근 연산 부하를 줄이기 위해 제곱 거리 비교(`dx*dx + dy*dy`) 방식 도입이 필요할 수 있습니다.
-    - **상태 관리:** React 환경임에도 불구하고 실시간 성능을 위해 가변(Mutable) 객체와 `ctx`를 통한 직접 수정을 혼용하고 있습니다.
-
----
-
-*Last updated: 2026-04-14*
-
----
-
-# 🕵️ Skybound Protocol 코드 리뷰 리포트
-- Raw Source: [[00_Raw/2026-04-20/Skybound Protocol 코드리뷰.md]]
----
diff --git a/AI/Snyk Checkmarx Endor Labs 등 종합 애플리케이션 보안 플랫폼.md b/AI/Snyk Checkmarx Endor Labs 등 종합 애플리케이션 보안 플랫폼.md
deleted file mode 100644
index b6ccdec2..00000000
--- a/AI/Snyk Checkmarx Endor Labs 등 종합 애플리케이션 보안 플랫폼.md	
+++ /dev/null
@@ -1,33 +0,0 @@
----
-id: P-REINFORCE-AUTO-1D1222
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Snyk Checkmarx Endor Labs 등 종합 애플리케이션 보안 플랫폼"
----
-
-# [[Snyk Checkmarx Endor Labs 등 종합 애플리케이션 보안 플랫폼]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> Snyk, Checkmarx, Endor Labs 등은 소프트웨어 개발 수명 주기(SDLC) 전반에 걸쳐 코드의 취약점을 탐지하고 수정을 지원하는 종합 애플리케이션 보안 플랫폼입니다 [1-4]. 이들 플랫폼은 정적 애플리케이션 보안 테스트(SAST), 소프트웨어 구성 분석(SCA), 컨테이너 및 IaC(코드형 인프라) 스캔 등 다양한 보안 영역을 제공하며, '시프트 레프트(Shift-Left)' 전략을 통해 개발 초기 단계에서 보안 이슈를 해결하도록 돕습니다 [2, 3, 5, 6]. 최근에는 인공지능(AI)과 머신러닝 기술을 결합하여 오탐율을 줄이고 실시간 자동 수정 제안을 제공하는 형태로 고도화되고 있습니다 [7, 8].
-
-## 📖 구조화된 지식 (Synthesized Content)
-- **Snyk (Snyk Code 및 플랫폼군)**: 개발자 친화적인(Developer-first) 플랫폼을 지향하며, 자체 머신러닝 엔진인 DeepCode AI를 통해 빠르고 정확한 SAST 스캔(Snyk Code)을 제공합니다 [4, 6]. IDE, PR(Pull Request), CI/CD 파이프라인 워크플로우에 완벽히 통합되며, Snyk Open Source(SCA), Snyk Container, Snyk IaC 제품들과 결합하여 단일 대시보드에서 포괄적인 보안 가시성을 제공합니다 [6, 9, 10]. AI가 생성한 수정 사항을 자동으로 재테스트하여 검증하는 Agent Fix 기능이 특징입니다 [6, 11].
-- **Checkmarx**: 대규모 엔터프라이즈 환경과 복잡한 거버넌스를 지닌 조직에 적합한 플랫폼입니다 [11, 12]. SAST를 핵심으로 하여 SCA, 비밀키(Secrets), IaC 스캔을 지원하며, 최신 AI Query Builder를 도입하여 자연어로 탐지 로직을 커스터마이징할 수 있습니다 [2]. IDE 내에서 코드를 수정해주는 에이전트 기반의 'Developer Assist' 기능을 통해 AI 지원 문제 해결(AI-assisted remediation)을 제공합니다 [2].
-- **Endor Labs**: 소프트웨어 구성 분석(SCA) 배경에서 출발해 SAST 영역으로 확장한 플랫폼으로, '도달 가능성(Reachability) 분석'에 독보적인 강점을 가집니다 [3, 11]. 서드파티 의존성 패키지와 자사 코드의 취약점이 실제 프로덕션의 함수 실행 경로(Call-graph)에서 호출되는지를 분석하여, SAST와 SCA 발견 항목을 통합된 단일 위험 뷰로 제공함으로써 개발자의 경고 피로(Alert fatigue)를 크게 줄여줍니다 [3, 13, 14].
-- **AI 기반 탐지 및 수정 자동화**: 기존의 단순 규칙 및 패턴 매칭 기반 도구의 한계(비즈니스 로직 이해 부족 및 높은 오탐률)를 극복하기 위해, 이들 플랫폼은 AI-Native 구조를 채택하여 코드의 문맥과 데이터 흐름(Data flow)을 심층 분석하고, 취약점의 우선순위를 평가하여 개발자에게 실행 가능한(Actionable) 패치 코드를 즉시 제안합니다 [2, 6-8, 15].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** AI 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[Static Application Security Testing (SAST)]], [[Software Composition Analysis (SCA)]], [[DevSecOps]]
-- **Projects/Contexts:** [[Shift-Left Security]], [[Reachability Analysis]], [[AI-powered Remediation]]
-- **Contradictions/Notes:** 소스에 따르면 각 플랫폼은 명확한 타겟층과 상충되는 트레이드오프를 가집니다. Checkmarx는 엔터프라이즈 수준의 맞춤 설정과 거버넌스에 강력하지만 소규모 팀에게는 무거울 수 있습니다 [12]. 반면 Snyk은 빠른 IDE 통합과 채택률로 개발자 경험에 탁월하지만, 언어 지원 범위가 타 엔터프라이즈 벤더보다 다소 좁을 수 있습니다 [16, 17]. 또한, Endor Labs는 강력한 도달 가능성 분석을 자랑하지만 전용 SAST 도구에 비해 SAST 룰 커버리지나 언어 지원 확장이 아직 진행 중이라는 한계가 있습니다 [13].
-
----
-*Last updated: 2026-04-18*
-- Raw Source: [[00_Raw/2026-04-20/Snyk, Checkmarx, Endor Labs 등 종합 애플리케이션 보안 플랫폼.md]]
----
diff --git a/AI/Social Constructivism.md b/AI/Social Constructivism.md
deleted file mode 100644
index dd0b1ebc..00000000
--- a/AI/Social Constructivism.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-A416E7
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Social Constructivism"
----
-
-# [[Social Constructivism]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** AI 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Social Constructivism.md]]
----
diff --git a/AI/Social Systems Theory.md b/AI/Social Systems Theory.md
deleted file mode 100644
index 88566ee4..00000000
--- a/AI/Social Systems Theory.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-700A72
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Social Systems Theory"
----
-
-# [[Social Systems Theory]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** AI 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Social Systems Theory.md]]
----
diff --git a/AI/Soft Navigation.md b/AI/Soft Navigation.md
deleted file mode 100644
index e3628305..00000000
--- a/AI/Soft Navigation.md	
+++ /dev/null
@@ -1,32 +0,0 @@
----
-id: P-REINFORCE-AUTO-A5364E
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Soft Navigation"
----
-
-# [[Soft Navigation]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 소프트 내비게이션(Soft Navigation)은 단일 페이지 자바스크립트 애플리케이션(SPA)에서 URL이 변경될 때 웹사이트 전체를 다시 로드하지 않고 콘텐츠를 전환하는 방식을 의미합니다 [1]. 기존의 성능 지표인 최대 콘텐츠 풀 페인트(Largest Contentful Paint, LCP)는 초기 내비게이션의 로드 시간만 측정하기 때문에, 후속 탐색 성능을 파악하는 데 큰 사각지대가 존재해 왔습니다 [2]. 이를 해결하기 위해 Chrome은 소프트 내비게이션 발생을 감지하고 상호작용에 따른 DOM 수정 사항을 관찰하여 개별 로드 시간을 측정할 수 있는 새로운 API를 테스트하고 있습니다 [2].
-
-## 📖 구조화된 지식 (Synthesized Content)
-- **소프트 내비게이션의 작동 방식:** 오늘날 많은 웹사이트는 URL이 변경될 때마다 전체를 새로고침하지 않습니다 [1]. 대신 단일 페이지 애플리케이션 구조를 취하여, 사용자가 링크를 클릭할 때 전체 로드가 아닌 소프트 내비게이션만을 발생시킵니다 [1].
-- **성능 측정의 사각지대와 한계:** 현재 LCP 지표는 웹사이트의 초기 로드 시간만을 측정합니다 [2]. 단일 페이지 앱은 흔히 초기 로딩 속도가 느린 대신 이후의 탐색(소프트 내비게이션)이 빠르다고 주장하지만, 현재로서는 이를 명확히 측정할 성능 데이터가 비어있어 개발자와 운영자에게 상당한 사각지대를 형성하고 있습니다 [2, 3]. 
-- **Chrome의 오리진 트라이얼(Origin Trial) 및 해결 노력:** Google은 2024년에 소프트 내비게이션 성능을 측정하기 위한 실험을 진행했으나 완성된 API를 도출하지는 못했습니다 [2]. 이후 2025년 8월, Chrome은 새로운 오리진 트라이얼을 시작했습니다 [2]. 제안된 API는 소프트 내비게이션이 발생하는 시점을 감지하고, 사용자 상호작용에 대응해 일어나는 DOM의 수정 사항을 관찰하여 각 소프트 내비게이션의 로드 시간을 브라우저가 측정할 수 있도록 합니다 [2].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** AI 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[Single-Page JavaScript Applications]], [[Largest Contentful Paint]], [[Origin Trials]]
-- **Projects/Contexts:** [[Chrome 2025 Soft Navigations Origin Trial]]
-- **Contradictions/Notes:** 소스 내에 상충하는 정보는 없습니다. 다만, 단일 페이지 앱이 '더 빠른 후속 탐색'을 제공한다는 약속을 실제로 이행하고 있는지 여부를 알기 위해서는 Chrome에 소프트 내비게이션 성능 측정 지원이 반드시 도입되어야 한다는 점이 개발자들의 더 나은 의사결정을 위한 핵심 과제로 지적되고 있습니다 [3].
-
----
-*Last updated: 2026-04-19*
-- Raw Source: [[00_Raw/2026-04-20/Soft Navigation.md]]
----
diff --git a/AI/SonarQube.md b/AI/SonarQube.md
deleted file mode 100644
index 8dd469fb..00000000
--- a/AI/SonarQube.md
+++ /dev/null
@@ -1,33 +0,0 @@
----
-id: P-REINFORCE-AUTO-0785CD
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - SonarQube"
----
-
-# [[SonarQube]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> SonarQube는 소프트웨어의 품질, 보안, 유지보수성을 보장하기 위해 설계된 강력한 정적 애플리케이션 보안 테스트(SAST) 및 자동화된 코드 리뷰 플랫폼이다 [1-3]. 결정론적인 정적 분석 엔진과 AI 기능을 활용하여 사람이 작성한 코드뿐만 아니라 AI가 생성한 코드의 결함, 보안 취약점, 코드 스멜을 자동으로 식별한다 [3-5]. 개발자의 IDE부터 CI/CD 파이프라인, 풀 리퀘스트(PR) 워크플로우에 원활하게 통합되어 코드가 릴리스되기 전에 일관된 품질 표준과 규정 준수를 강제한다 [6-8].
-
-## 📖 구조화된 지식 (Synthesized Content)
-- **다양한 제품군 및 확장성:** 자체 관리형 환경을 위한 'SonarQube Server', SaaS 솔루션인 'SonarQube Cloud', IDE에서 실시간 피드백을 제공하는 무료 플러그인 'SonarQube for IDE', 그리고 AI 코딩 어시스턴트(Cursor, Claude Code, Windsurf 등)와 분석 엔진을 직접 연결하는 'SonarQube MCP Server'로 구성된다 [9-11]. 이 플랫폼은 35개 이상의 프로그래밍 언어와 프레임워크를 지원하며, 사용자 수, 프로젝트 수, 스캔 횟수에 제한이 없는 무제한 확장을 지원한다 [4, 6, 12, 13].
-- **보안 및 규정 준수 검사:** 고급 SAST(Static Application Security Testing) 및 테인트(Taint) 분석을 통해 소스 코드 전반에서 보안 취약점, 유출된 비밀(secrets), 위험한 데이터 흐름을 릴리스 전에 찾아낸다 [14-16]. 이를 통해 코드가 PCI, OWASP, CWE, STIG, CASA 등의 주요 보안 및 규정 준수 표준을 만족하도록 돕는다 [14, 16].
-- **AI 생성 코드 검증 (AI Code Assurance):** AI가 작성한 코드는 스타일과 품질 면에서 매우 불규칙할 수 있으므로, SonarQube는 이를 자동으로 감지하고 명확한 라벨링과 배지(badging)를 통해 관리 및 모니터링한다 [4, 12]. 비결정적인 AI 어시스턴트의 코드에 대해 독립적이고 결정론적인 검증을 제공하여 취약점과 정확성 문제를 조기에 차단한다 [17]. 또한 일부 버전에서는 LLM을 활용해 보안 문제와 코드 스멜에 대한 수정 제안을 제공하는 'AI CodeFix' 기능을 지원한다 [3].
-- **품질 게이트와 'Clean as You Code' 방법론:** CI/CD 파이프라인 및 PR 리뷰 단계에서 정책 기반의 '품질 게이트(Quality Gates)'를 강제하여 합격/불합격 여부를 결정한다 [6, 8]. 특히, 기존 코드의 백로그를 처리하기보다는 새롭게 추가되거나 변경된 코드에 집중하여 코드의 품질을 점진적으로 개선해 나가는 "Clean as You Code" 방법론을 채택하고 있다 [3, 18].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** AI 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[SAST]], [[Quality Gates]], [[Model Context Protocol (MCP)]], [[Clean as You Code]]
-- **Projects/Contexts:** [[CI/CD 및 Pull Request 자동화 리뷰]], [[AI 생성 코드 검증(AI Code Assurance)]]
-- **Contradictions/Notes:** SonarQube는 코드 품질과 보안을 통합적으로 제공하는 매우 강력한 플랫폼이지만, 취약점 탐지 방식이 주로 규칙(Rule) 및 패턴에 의존하고 있다. 따라서 컨텍스트와 비즈니스 로직을 자체적으로 이해해야 하는 새로운 형태의 결함이나 취약점을 탐지하는 데는 최신 AI 네이티브 기반 스캐너에 비해 덜 효과적일 수 있다는 한계가 지적된다 [3, 19].
-
----
-*Last updated: 2026-04-18*
-- Raw Source: [[00_Raw/2026-04-20/SonarQube.md]]
----
diff --git a/AI/Sparse Autoencoder (SAE).md b/AI/Sparse Autoencoder (SAE).md
deleted file mode 100644
index 342d2ec6..00000000
--- a/AI/Sparse Autoencoder (SAE).md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-A11EAF
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Sparse Autoencoder (SAE)"
----
-
-# [[Sparse Autoencoder (SAE)]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** AI 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Sparse Autoencoder (SAE).md]]
----
diff --git a/AI/Spatial UI.md b/AI/Spatial UI.md
deleted file mode 100644
index a96e39d0..00000000
--- a/AI/Spatial UI.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-E02F81
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Spatial UI"
----
-
-# [[Spatial UI]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** AI 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Spatial UI.md]]
----
diff --git a/AI/Specification Gaming (명세 우회).md b/AI/Specification Gaming (명세 우회).md
deleted file mode 100644
index 991b6984..00000000
--- a/AI/Specification Gaming (명세 우회).md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-1BD229
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Specification Gaming (명세 우회)"
----
-
-# [[Specification Gaming (명세 우회)]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** AI 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Specification Gaming (명세 우회).md]]
----
diff --git a/AI/Sports Neuroscience.md b/AI/Sports Neuroscience.md
deleted file mode 100644
index 06440731..00000000
--- a/AI/Sports Neuroscience.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-80CF35
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Sports Neuroscience"
----
-
-# [[Sports Neuroscience]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** AI 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Sports Neuroscience.md]]
----
diff --git a/AI/Sports-Medicine-Rehabilitation.md b/AI/Sports-Medicine-Rehabilitation.md
deleted file mode 100644
index fcd57b04..00000000
--- a/AI/Sports-Medicine-Rehabilitation.md
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-727225
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Sports-Medicine-Rehabilitation"
----
-
-# [[Sports-Medicine-Rehabilitation]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** AI 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Sports-Medicine-Rehabilitation.md]]
----
diff --git a/AI/Sports-Performance-Optimization.md b/AI/Sports-Performance-Optimization.md
deleted file mode 100644
index 0a82981e..00000000
--- a/AI/Sports-Performance-Optimization.md
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-FEEFC9
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Sports-Performance-Optimization"
----
-
-# [[Sports-Performance-Optimization]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** AI 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Sports-Performance-Optimization.md]]
----
diff --git a/AI/Sports-Psychology.md b/AI/Sports-Psychology.md
deleted file mode 100644
index 460ce457..00000000
--- a/AI/Sports-Psychology.md
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-D4C5E8
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Sports-Psychology"
----
-
-# [[Sports-Psychology]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** AI 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Sports-Psychology.md]]
----
diff --git a/AI/Sports-Science-Training.md b/AI/Sports-Science-Training.md
deleted file mode 100644
index 038b4bb7..00000000
--- a/AI/Sports-Science-Training.md
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-9A7390
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Sports-Science-Training"
----
-
-# [[Sports-Science-Training]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** AI 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Sports-Science-Training.md]]
----
diff --git a/AI/Sprague-Grundy Theorem.md b/AI/Sprague-Grundy Theorem.md
deleted file mode 100644
index 6a305e3b..00000000
--- a/AI/Sprague-Grundy Theorem.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-3D42A2
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Sprague-Grundy Theorem"
----
-
-# [[Sprague-Grundy Theorem]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** AI 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Sprague-Grundy Theorem.md]]
----
diff --git a/AI/Static Application Security Testing (SAST).md b/AI/Static Application Security Testing (SAST).md
deleted file mode 100644
index 58bbf095..00000000
--- a/AI/Static Application Security Testing (SAST).md	
+++ /dev/null
@@ -1,34 +0,0 @@
----
-id: P-REINFORCE-AUTO-95EC02
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Static Application Security Testing (SAST)"
----
-
-# [[Static Application Security Testing (SAST)]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> Static Application Security Testing(SAST)는 애플리케이션을 직접 실행하지 않고 소스 코드나 바이트코드를 분석하여 잠재적인 보안 취약점과 결함을 찾아내는 화이트박스 테스트(white-box testing) 기법입니다 [1, 2]. 이 방식은 소프트웨어 개발 수명 주기(SDLC)의 초기 단계에 적용되어 코드가 배포되기 전에 문제를 식별하고 수정할 수 있게 해줍니다 [1, 3, 4]. 최근에는 인공지능(AI)과 기계 학습(ML) 기술이 결합되어 전통적인 규칙 기반 탐지의 한계를 넘어 코드의 문맥을 이해하고, 자동으로 수정 코드를 제안하는 수준으로 진화하고 있습니다 [5-7].
-
-## 📖 구조화된 지식 (Synthesized Content)
-* **작동 원리 및 주요 탐지 영역:** SAST는 코드의 구조와 구문을 분석하며, 데이터 흐름(Data flow), 테인트 분석(Taint tracking) 및 의미론적 분석을 수행하여 외부에서 유입된 신뢰할 수 없는 데이터가 안전하게 처리되는지 추적합니다 [2, 8, 9]. 이를 통해 SQL 주입(SQL Injection), 크로스 사이트 스크립팅(XSS), 경로 탐색(Path traversal), 하드코딩된 비밀번호(Secrets) 등 OWASP Top 10에 해당하는 주요 보안 취약점을 탐지합니다 [10, 11].
-* **개발 워크플로우 통합 (Shift-Left 전략):** SAST의 가장 큰 장점 중 하나는 개발 초기에 보안을 내재화하는 'Shift-Left' 접근법을 가능하게 한다는 것입니다 [12-14]. IDE(통합 개발 환경), 풀 리퀘스트(Pull Request), CI/CD 파이프라인 등 개발자의 기존 워크플로우에 긴밀하게 통합되어 실시간 피드백을 제공하므로, 취약점을 발견하고 수정하는 데 드는 비용과 시간을 크게 절감할 수 있습니다 [15-20].
-* **전통적 SAST의 장점과 한계:** 앱을 실행할 필요가 없고, 테스트 케이스를 작성하지 않아도 전체 코드베이스를 검사할 수 있으며 자동화가 용이합니다 [19]. 더불어 PCI, OWASP, CWE 등 산업 표준 규정 준수를 증명하는 데 기여합니다 [11, 21]. 반면 런타임 컨텍스트가 부족하여 오탐률(False Positive)이 높을 수 있고(기존 도구의 경우 50~80%에 달함), 지원하는 프로그래밍 언어에 대한 의존성이 존재한다는 단점이 있습니다 [22-24].
-* **AI 기반 SAST의 등장:** 최근에는 Snyk Code, Corgea 등 거대 언어 모델(LLM)과 기계 학습을 도입한 차세대 SAST 도구들이 등장했습니다 [6, 7, 18, 22]. 이들은 파일 간 분석(Interfile analysis)을 통해 여러 모듈에 걸친 취약점을 추적하고 의미론적으로 코드를 이해함으로써 오탐률을 줄입니다 [25, 26]. 뿐만 아니라, 개발자가 즉각적으로 적용할 수 있는 자동 수정 코드(Auto-fix)까지 생성하여 신속한 조치를 돕습니다 [6, 27-30].
-* **타 보안 테스트 도구와의 차이점:** 실행 중인 상태의 애플리케이션을 외부에서 블랙박스 형태로 테스트하는 DAST(Dynamic Application Security Testing)와 대조적입니다 [1, 31]. 또한 서드파티 오픈소스 라이브러리의 알려진 취약점(CVE)과 라이선스를 검사하는 SCA(Software Composition Analysis)와 달리, SAST는 개발 팀이 직접 작성한 1사(자체) 소스 코드 내의 로직 결함을 찾아내는 데 집중합니다 [32, 33].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** AI 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[Dynamic Application Security Testing (DAST)]], [[Software Composition Analysis (SCA)]], [[Shift-Left]], [[False Positives]], [[Artificial Intelligence (AI) Code Review]]
-- **Projects/Contexts:** 소프트웨어 개발 수명 주기(SDLC) 내에서 보안을 강화하기 위해 CI/CD 파이프라인, IDE 플러그인, Pull Request 등에 연동하여 사용되는 맥락을 가집니다. 대표적인 도구로는 [[Snyk Code]], [[Corgea]], [[SonarQube]], [[Checkmarx]], [[Semgrep]], [[Veracode]], [[GitHub Advanced Security]] 등이 널리 사용되고 있습니다 [7, 18, 22, 27, 34-38].
-- **Contradictions/Notes:** 전통적인 정적 분석(SAST)은 빠르고 일관된 검사를 제공하지만, 비즈니스 로직에 대한 문맥 이해 부족과 높은 오탐률(False Positives)이라는 한계가 지적됩니다 [23, 24]. 이를 해결하기 위해 최근에는 사람이 판단을 내리는 수동 코드 리뷰(Manual Code Review)와 AI가 결합된 정적 분석을 혼합하여 사용하는 하이브리드(Hybrid) 접근 방식이 필수적인 보안 검토의 모범 사례로 권장되고 있습니다 [39-41].
-
----
-*Last updated: 2026-04-19*
-- Raw Source: [[00_Raw/2026-04-20/Static Application Security Testing (SAST).md]]
----
diff --git a/AI/Static-Analysis-in-JavaScript-Ecosystem.md b/AI/Static-Analysis-in-JavaScript-Ecosystem.md
deleted file mode 100644
index 02e33980..00000000
--- a/AI/Static-Analysis-in-JavaScript-Ecosystem.md
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-6BE2FD
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Static-Analysis-in-JavaScript-Ecosystem"
----
-
-# [[Static-Analysis-in-JavaScript-Ecosystem]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** AI 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Static-Analysis-in-JavaScript-Ecosystem.md]]
----
diff --git a/AI/Static-Analysis-in-JavaScript.md b/AI/Static-Analysis-in-JavaScript.md
deleted file mode 100644
index 1026c06c..00000000
--- a/AI/Static-Analysis-in-JavaScript.md
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-AC87D9
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Static-Analysis-in-JavaScript"
----
-
-# [[Static-Analysis-in-JavaScript]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** AI 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Static-Analysis-in-JavaScript.md]]
----
diff --git a/AI/Static-Analysis-in-Software-Engineering.md b/AI/Static-Analysis-in-Software-Engineering.md
deleted file mode 100644
index af2bb74a..00000000
--- a/AI/Static-Analysis-in-Software-Engineering.md
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-97FE65
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Static-Analysis-in-Software-Engineering"
----
-
-# [[Static-Analysis-in-Software-Engineering]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** AI 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Static-Analysis-in-Software-Engineering.md]]
----
diff --git a/AI/Static-Analysis-of-Interfaces.md b/AI/Static-Analysis-of-Interfaces.md
deleted file mode 100644
index b0e98dd7..00000000
--- a/AI/Static-Analysis-of-Interfaces.md
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-FCF0B0
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Static-Analysis-of-Interfaces"
----
-
-# [[Static-Analysis-of-Interfaces]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** AI 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Static-Analysis-of-Interfaces.md]]
----
diff --git a/AI/Stochastic Processes.md b/AI/Stochastic Processes.md
deleted file mode 100644
index 52d69fb0..00000000
--- a/AI/Stochastic Processes.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-71E76D
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Stochastic Processes"
----
-
-# [[Stochastic Processes]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** AI 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Stochastic Processes.md]]
----
diff --git a/AI/Stochastic-Games.md b/AI/Stochastic-Games.md
deleted file mode 100644
index 3817d518..00000000
--- a/AI/Stochastic-Games.md
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-4892A4
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Stochastic-Games"
----
-
-# [[Stochastic-Games]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** AI 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Stochastic-Games.md]]
----
diff --git a/AI/Sum-Types.md b/AI/Sum-Types.md
deleted file mode 100644
index d7a13309..00000000
--- a/AI/Sum-Types.md
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-BDFB36
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Sum-Types"
----
-
-# [[Sum-Types]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** AI 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Sum-Types.md]]
----
diff --git a/AI/Superposition (중첩).md b/AI/Superposition (중첩).md
deleted file mode 100644
index 3fe1778c..00000000
--- a/AI/Superposition (중첩).md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-1840DD
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Superposition (중첩)"
----
-
-# [[Superposition (중첩)]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** AI 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Superposition (중첩).md]]
----
diff --git a/AI/Supply-Chain-Management.md b/AI/Supply-Chain-Management.md
deleted file mode 100644
index 35dc7d38..00000000
--- a/AI/Supply-Chain-Management.md
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-58899C
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Supply-Chain-Management"
----
-
-# [[Supply-Chain-Management]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** AI 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Supply-Chain-Management.md]]
----
diff --git a/AI/Surreal Numbers.md b/AI/Surreal Numbers.md
deleted file mode 100644
index 2a574be5..00000000
--- a/AI/Surreal Numbers.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-785AE1
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Surreal Numbers"
----
-
-# [[Surreal Numbers]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** AI 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Surreal Numbers.md]]
----
diff --git a/AI/Survival Horror Genre.md b/AI/Survival Horror Genre.md
deleted file mode 100644
index c761fbf5..00000000
--- a/AI/Survival Horror Genre.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-2AE52E
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Survival Horror Genre"
----
-
-# [[Survival Horror Genre]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** AI 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Survival Horror Genre.md]]
----
diff --git a/AI/Sustainable Development Goals (SDGs).md b/AI/Sustainable Development Goals (SDGs).md
deleted file mode 100644
index 65255e96..00000000
--- a/AI/Sustainable Development Goals (SDGs).md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-189E36
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Sustainable Development Goals (SDGs)"
----
-
-# [[Sustainable Development Goals (SDGs)]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** AI 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Sustainable Development Goals (SDGs).md]]
----
diff --git a/AI/Sustainable-Development-Goals (SDGs).md b/AI/Sustainable-Development-Goals (SDGs).md
deleted file mode 100644
index 96b46bc8..00000000
--- a/AI/Sustainable-Development-Goals (SDGs).md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-C74AAC
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Sustainable-Development-Goals (SDGs)"
----
-
-# [[Sustainable-Development-Goals (SDGs)]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** AI 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Sustainable-Development-Goals (SDGs).md]]
----
diff --git a/AI/Sycophancy (LLM 아첨 문제).md b/AI/Sycophancy (LLM 아첨 문제).md
deleted file mode 100644
index 87611aa9..00000000
--- a/AI/Sycophancy (LLM 아첨 문제).md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-0AA310
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Sycophancy (LLM 아첨 문제)"
----
-
-# [[Sycophancy (LLM 아첨 문제)]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** AI 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Sycophancy (LLM 아첨 문제).md]]
----
diff --git a/AI/Symbolic-Logic.md b/AI/Symbolic-Logic.md
deleted file mode 100644
index d5de31a8..00000000
--- a/AI/Symbolic-Logic.md
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-5793E0
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Symbolic-Logic"
----
-
-# [[Symbolic-Logic]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** AI 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Symbolic-Logic.md]]
----
diff --git a/AI/Synaptic Plasticity.md b/AI/Synaptic Plasticity.md
deleted file mode 100644
index 39785997..00000000
--- a/AI/Synaptic Plasticity.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-DC2DA0
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Synaptic Plasticity"
----
-
-# [[Synaptic Plasticity]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** AI 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Synaptic Plasticity.md]]
----
diff --git a/AI/SynthID (구글 AI 식별 기술).md b/AI/SynthID (구글 AI 식별 기술).md
deleted file mode 100644
index b33b1360..00000000
--- a/AI/SynthID (구글 AI 식별 기술).md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-A89657
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - SynthID (구글 AI 식별 기술)"
----
-
-# [[SynthID (구글 AI 식별 기술)]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** AI 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/SynthID (구글 AI 식별 기술).md]]
----
diff --git a/AI/Synthetic Data (합성 데이터).md b/AI/Synthetic Data (합성 데이터).md
deleted file mode 100644
index d779d41f..00000000
--- a/AI/Synthetic Data (합성 데이터).md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-532E5E
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Synthetic Data (합성 데이터)"
----
-
-# [[Synthetic Data (합성 데이터)]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** AI 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Synthetic Data (합성 데이터).md]]
----
diff --git a/AI/System Prompt (시스템 프롬프트).md b/AI/System Prompt (시스템 프롬프트).md
deleted file mode 100644
index 31349567..00000000
--- a/AI/System Prompt (시스템 프롬프트).md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-BEA248
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - System Prompt (시스템 프롬프트)"
----
-
-# [[System Prompt (시스템 프롬프트)]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** AI 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/System Prompt (시스템 프롬프트).md]]
----
diff --git a/AI/Systemic-Cohesion.md b/AI/Systemic-Cohesion.md
deleted file mode 100644
index 10b43a27..00000000
--- a/AI/Systemic-Cohesion.md
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-E0B412
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Systemic-Cohesion"
----
-
-# [[Systemic-Cohesion]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** AI 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Systemic-Cohesion.md]]
----
diff --git a/AI/Systems Thinking in Management.md b/AI/Systems Thinking in Management.md
deleted file mode 100644
index 9e4936c1..00000000
--- a/AI/Systems Thinking in Management.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-8B0A69
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Systems Thinking in Management"
----
-
-# [[Systems Thinking in Management]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** AI 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Systems Thinking in Management.md]]
----
diff --git a/AI/Systems Thinking.md b/AI/Systems Thinking.md
deleted file mode 100644
index 96cfd529..00000000
--- a/AI/Systems Thinking.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-6EBBC9
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Systems Thinking"
----
-
-# [[Systems Thinking]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** AI 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Systems Thinking.md]]
----
diff --git a/AI/Taxonomy-and-Ontology.md b/AI/Taxonomy-and-Ontology.md
deleted file mode 100644
index 1c051f5b..00000000
--- a/AI/Taxonomy-and-Ontology.md
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-93E139
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Taxonomy-and-Ontology"
----
-
-# [[Taxonomy-and-Ontology]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** AI 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Taxonomy-and-Ontology.md]]
----
diff --git a/AI/Temporal Difference Learning.md b/AI/Temporal Difference Learning.md
deleted file mode 100644
index 0b58a573..00000000
--- a/AI/Temporal Difference Learning.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-92B6E9
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Temporal Difference Learning"
----
-
-# [[Temporal Difference Learning]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** AI 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Temporal Difference Learning.md]]
----
diff --git a/AI/Test-Time Compute Scaling (추론 시간 계산 스케일링).md b/AI/Test-Time Compute Scaling (추론 시간 계산 스케일링).md
deleted file mode 100644
index e8f261a6..00000000
--- a/AI/Test-Time Compute Scaling (추론 시간 계산 스케일링).md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-E16EB6
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Test-Time Compute Scaling (추론 시간 계산 스케일링)"
----
-
-# [[Test-Time Compute Scaling (추론 시간 계산 스케일링)]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** AI 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Test-Time Compute Scaling (추론 시간 계산 스케일링).md]]
----
diff --git a/AI/Texture-Synthesis.md b/AI/Texture-Synthesis.md
deleted file mode 100644
index a12c2351..00000000
--- a/AI/Texture-Synthesis.md
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-197D49
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Texture-Synthesis"
----
-
-# [[Texture-Synthesis]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** AI 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Texture-Synthesis.md]]
----
diff --git a/AI/The Immersive Sim Taxonomy Debate.md b/AI/The Immersive Sim Taxonomy Debate.md
deleted file mode 100644
index 858d5746..00000000
--- a/AI/The Immersive Sim Taxonomy Debate.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-4613F1
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - The Immersive Sim Taxonomy Debate"
----
-
-# [[The Immersive Sim Taxonomy Debate]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** AI 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/The 'Immersive Sim' Taxonomy Debate.md]]
----
diff --git a/AI/The Last of Us Series.md b/AI/The Last of Us Series.md
deleted file mode 100644
index ff05119e..00000000
--- a/AI/The Last of Us Series.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-2121F1
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - The Last of Us Series"
----
-
-# [[The Last of Us Series]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** AI 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/The Last of Us Series.md]]
----
diff --git a/AI/The Overwatch League Case Study.md b/AI/The Overwatch League Case Study.md
deleted file mode 100644
index 2960c83d..00000000
--- a/AI/The Overwatch League Case Study.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-B644A1
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - The Overwatch League Case Study"
----
-
-# [[The Overwatch League Case Study]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** AI 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/The Overwatch League Case Study.md]]
----
diff --git a/AI/The Science of Well-Being (Yale).md b/AI/The Science of Well-Being (Yale).md
deleted file mode 100644
index 159c2a95..00000000
--- a/AI/The Science of Well-Being (Yale).md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-C3C1C2
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - The Science of Well-Being (Yale)"
----
-
-# [[The Science of Well-Being (Yale)]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** AI 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/The Science of Well-Being (Yale).md]]
----
diff --git a/AI/The-Collapse-of-Utopian-Ideologies.md b/AI/The-Collapse-of-Utopian-Ideologies.md
deleted file mode 100644
index 324d452b..00000000
--- a/AI/The-Collapse-of-Utopian-Ideologies.md
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-12C4DD
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - The-Collapse-of-Utopian-Ideologies"
----
-
-# [[The-Collapse-of-Utopian-Ideologies]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** AI 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/The-Collapse-of-Utopian-Ideologies.md]]
----
diff --git a/AI/Themework-Integration.md b/AI/Themework-Integration.md
deleted file mode 100644
index fdd0e2a8..00000000
--- a/AI/Themework-Integration.md
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-159F6C
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Themework-Integration"
----
-
-# [[Themework-Integration]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** AI 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Themework-Integration.md]]
----
diff --git a/AI/Threejs WebGL 렌더링 최적화.md b/AI/Threejs WebGL 렌더링 최적화.md
deleted file mode 100644
index d65c7bb0..00000000
--- a/AI/Threejs WebGL 렌더링 최적화.md	
+++ /dev/null
@@ -1,47 +0,0 @@
----
-id: P-REINFORCE-AUTO-FE50FB
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Threejs WebGL 렌더링 최적화"
----
-
-# [[Threejs WebGL 렌더링 최적화]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> Three.js WebGL 렌더링 최적화는 주로 CPU와 GPU 간의 통신 병목 현상을 유발하는 드로우 콜(Draw Call)을 줄이고, 메모리 및 렌더링 연산 효율을 극대화하는 일련의 과정입니다 [1-6]. 이를 위해 인스턴싱(Instancing), 배칭(Batching), 기하학적 병합, 텍스처/모델 압축 및 LOD(Level of Detail)와 같은 다양한 기법이 복합적으로 적용됩니다 [7-12]. 최적화를 통해 렌더링 프레임 속도를 방어할 수 있으나, 각 기법은 절두체 컬링(Frustum Culling) 정밀도 저하나 오버드로우(Overdraw) 유발과 같은 구조적 한계와 트레이드오프를 가지므로 씬(Scene)의 특성에 맞는 전략적 접근이 필수적입니다 [13-17].
-
-## 📖 구조화된 지식 (Synthesized Content)
-**드로우 콜(Draw Call) 최소화 전략**
-*   **드로우 콜의 병목:** 드로우 콜은 CPU가 GPU에 렌더링 상태를 설정하고 기하학적 데이터를 그리도록 지시하는 명령으로, 원활한 60fps 성능을 위해서는 프레임당 100개 미만으로 유지하는 것이 강력히 권장됩니다 [3, 9, 18, 19]. 폴리곤 수보다 드로우 콜의 수가 CPU를 마비시키는 주된 원인이 됩니다 [5].
-*   **InstancedMesh:** 동일한 지오메트리와 재질을 공유하는 다수의 객체를 단 한 번의 드로우 콜로 렌더링합니다 [9, 20]. 렌더링 속도와 메모리 효율을 크게 높이지만, 엔진 레벨에서 전체 인스턴스에 대한 단일 바운딩 볼륨을 사용하여 개별 객체의 시야 절두체 컬링(Frustum Culling)이 불가합니다 [13, 21]. 또한 렌더링 순서 자동 정렬이 되지 않아 픽셀 중복 연산(Overdraw)이 발생할 수 있으며 스킨드 애니메이션 적용이 매우 제한적입니다 [15, 16, 22].
-*   **BatchedMesh:** 동일한 재질을 사용하지만 지오메트리가 서로 다른 객체들을 하나의 드로우 콜로 묶어 처리할 수 있게 합니다 [10, 23-27]. 인스턴스별 컬링 및 가시성 제어가 가능하여 다양성을 확보할 수 있으나, 내부적인 정렬(Sorting)과 컬링 과정에서 막대한 CPU 부하를 유발하여 오히려 프레임이 하락하는 사례도 존재합니다 [27-30].
-*   **Geometry 병합(Merging):** 움직이지 않는 정적인 환경 요소는 `BufferGeometryUtils`를 사용하여 하나의 지오메트리로 병합하면 드로우 콜을 효과적으로 1회로 줄일 수 있습니다 [10, 31, 32].
-
-**에셋 데이터 및 메모리 관리**
-*   **데이터 압축:** Draco 압축을 적용하여 지오메트리 파일 크기를 최대 90-95% 줄일 수 있습니다 [7, 12, 18]. 텍스처는 KTX2 및 Basis Universal 형식으로 압축하여 VRAM 메모리 점유율을 PNG 대비 약 75~90% 낮출 수 있습니다 [7, 18, 33, 34].
-*   **LOD (Level of Detail):** 카메라와의 거리에 따라 폴리곤 수가 적은 메쉬로 교체하거나 원경의 객체를 임포스터(Billboard Impostor)로 대체하여 연산량을 크게 줄일 수 있습니다 [8, 11, 19, 35, 36].
-*   **명시적 리소스 해제:** Three.js는 GPU 리소스를 자동으로 가비지 컬렉팅하지 않으므로, 사용이 끝난 지오메트리, 재질, 텍스처, 렌더 타겟에 대해 반드시 `.dispose()`를 호출하여 GPU 메모리 누수를 방지해야 합니다 [37-40].
-
-**셰이더, 라이팅 및 포스트 프로세싱 최적화**
-*   텍스처 아틀라스(Texture Atlas)나 배열 텍스처(Data Array Textures)를 사용하여 여러 재질을 하나로 통합하면, 재질 스위칭으로 인한 상태 변경 오버헤드를 대폭 줄일 수 있습니다 [26, 41-44].
-*   모바일 기기에서는 셰이더 정밀도를 `mediump`로 설정하여 성능을 높이고, 분기문(Branching/Conditionals) 대신 `mix()` 및 `step()`을 활용하며, 동적 루프를 피해야 합니다 [45, 46]. 
-*   복잡한 씬에서는 Depth Pre-Pass 기법을 도입하여 보이지 않는 프래그먼트에 대한 무거운 셰이더 연산(오버드로우)을 사전에 차단할 수 있습니다 [47, 48].
-*   정적 씬에서는 라이트맵과 그림자를 런타임 이전에 베이크(Bake)하여 실시간 연산을 피하는 것이 좋습니다 [49].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** AI 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[드로우 콜 (Draw Call)]], [[InstancedMesh]], [[BatchedMesh]], [[LOD (Level of Detail)]], [[Frustum Culling]], [[Draco 압축]], [[Texture Atlas]], [[WebGPU]]
-- **Projects/Contexts:** [[Utsubo Three.js Optimization Tips (2026)]], [[InstancedMesh2 라이브러리]], [[Threedium Image-To-3D WebGL 파이프라인]], [[Three.js Roadmap: Draw Calls]]
-- **Contradictions/Notes:**
-  - `InstancedMesh`는 드로우 콜을 혁신적으로 줄여주지만, 자동 정렬 기능이 없고 전체를 렌더링하는 특성 때문에 씬 내 객체들이 중첩될 경우 막대한 오버드로우 연산이 발생하여, 1회 드로우 콜임에도 다수의 개별 메쉬를 렌더링할 때보다 오히려 프레임률(FPS)이 낮아지는 기현상이 발생할 수 있습니다 [13-16, 50].
-  - `BatchedMesh`는 여러 지오메트리를 하나의 드로우 콜로 모아주어 효율적인 것으로 소개되나, 객체의 가시성을 확인하고 렌더링 순서를 정렬하는 연산 비용이 커 특정 다량의 객체 렌더링 씬에서는 병합 메쉬(Merged Mesh)를 사용할 때보다 CPU 사용량을 치솟게 만들고 30~50% 더 낮은 FPS를 기록하는 성능 병목 현상이 보고되고 있습니다 [28-30, 51, 52].
-
----
-*Last updated: 2026-04-19*
-- Raw Source: [[00_Raw/2026-04-20/Three.js WebGL 렌더링 최적화.md]]
----
diff --git a/AI/Threejs WebGPURenderer.md b/AI/Threejs WebGPURenderer.md
deleted file mode 100644
index 92cb20e2..00000000
--- a/AI/Threejs WebGPURenderer.md	
+++ /dev/null
@@ -1,37 +0,0 @@
----
-id: P-REINFORCE-AUTO-2EFC4E
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Threejs WebGPURenderer"
----
-
-# [[Threejs WebGPURenderer]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> Three.js WebGPURenderer는 2025년 r171 버전부터 프로덕션 환경에 도입된 그래픽 렌더러로, 브라우저가 3D 그래픽을 처리하는 방식에 근본적인 전환을 가져왔습니다 [1-3]. 복잡한 설정 없이 `three/webgpu`에서 모듈을 불러와 사용할 수 있으며, 브라우저가 WebGPU를 지원하지 않을 경우 자동으로 WebGL 2로 대체(fallback)되는 기능을 제공합니다 [2, 4, 5]. 드로우 콜(Draw call)이 많은 장면이나 컴퓨트 셰이더(Compute Shader)가 필요한 복잡한 효과에서 기존 대비 2~10배 이상의 성능 향상을 가능하게 합니다 [5, 6].
-
-## 📖 구조화된 지식 (Synthesized Content)
-* **초기화 및 호환성 처리:** 
-  WebGPURenderer를 사용하기 위해서는 GPU 어댑터 및 디바이스를 요청하는 비동기 초기화(`await renderer.init()`)가 필수적이며, 이를 누락하면 렌더링이 소리 없이 실패합니다 [2, 7]. 모든 주요 브라우저에서 WebGPU를 지원하지 않더라도 자동으로 WebGL 2로 전환하여 호환성을 유지하므로 별도의 코드 패스를 작성할 필요가 없습니다 [4]. 필요에 따라 테스트나 디버깅을 위해 `forceWebGL: true` 옵션을 사용하여 강제로 WebGL 모드로 렌더링할 수도 있습니다 [8].
-* **성능 및 컴퓨트 셰이더(Compute Shader) 활용:** 
-  이 렌더러의 가장 큰 강점 중 하나는 컴퓨트 셰이더의 지원입니다. 이를 통해 50,000개 수준에서 병목이 생기던 CPU 기반 입자 시스템이나 물리 시뮬레이션을 GPU로 오프로드하여 수백만 단위까지 실시간으로 처리할 수 있습니다 [9-12]. 컴퓨트 연산이 포함된 씬을 렌더링할 때는 GPU 작업의 올바른 동기화를 위해 일반 `render()` 대신 `await renderer.renderAsync(scene, camera)` 함수를 사용해야 합니다 [13].
-* **TSL(Three Shader Language)과의 통합:** 
-  커스텀 셰이더나 포스트 프로세싱 구현 시 TSL을 사용하는 것이 표준으로 자리 잡았습니다 [4, 14]. TSL로 작성된 코드는 WebGPU용 WGSL과 WebGL용 GLSL 양쪽으로 자동 컴파일되어 코드를 두 번 작성할 필요가 없습니다 [4, 15]. WebGPU 환경의 포스트 프로세싱 역시 기존 `pmndrs/postprocessing` 라이브러리 대신 TSL 노드를 기반으로 한 Three.js의 내장 포스트 프로세싱 파이프라인을 사용합니다 [14].
-* **메모리 및 렌더링 구조 최적화:** 
-  WebGPURenderer는 렌더 루프 과정에서 불필요한 객체 할당을 제거하여 가비지 컬렉터 부하를 방지하고, 리소스를 바인드 그룹(Bind group)으로 묶어 배치(Batch) 처리하는 구조를 채택하여 성능을 최적화했습니다 [11, 16]. 실제로 3D 데이터 플랫폼인 Segments.ai는 이 렌더러로 마이그레이션하여 수백만 개의 포인트 클라우드를 렌더링할 때 100배의 성능 향상을 거두었습니다 [17, 18].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** AI 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[TSL (Three Shader Language)]], [[Compute Shaders]], [[WebGL 2 fallback]]
-- **Projects/Contexts:** [[Segments.ai]], [[Expo 2025 Osaka]]
-- **Contradictions/Notes:** 소스는 WebGPU가 분명한 성능 우위를 제공하지만, 기존의 WebGL 기반 프로젝트가 이미 60fps로 부드럽게 실행되고 있으며 성능 한계에 부딪히지 않았다면 무리해서 시급히 마이그레이션할 필요는 없다고 조언합니다 [9, 19, 20]. 
-
----
-*Last updated: 2026-04-19*
-- Raw Source: [[00_Raw/2026-04-20/Three.js WebGPURenderer.md]]
----
diff --git a/AI/Threejs 성능 최적화.md b/AI/Threejs 성능 최적화.md
deleted file mode 100644
index 51af4e6b..00000000
--- a/AI/Threejs 성능 최적화.md	
+++ /dev/null
@@ -1,49 +0,0 @@
----
-id: P-REINFORCE-AUTO-965BAB
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Threejs 성능 최적화"
----
-
-# [[Threejs 성능 최적화]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> Three.js 성능 최적화는 CPU와 GPU 간의 통신 병목 현상을 유발하는 드로우 콜(Draw Call)을 줄이고 렌더링 파이프라인의 효율을 극대화하여 높은 프레임 속도를 유지하는 과정이다 [1-3]. 주로 `InstancedMesh` 및 `BatchedMesh`를 활용한 인스턴싱/배칭 기법, 텍스처와 지오메트리 압축, 프러스텀 컬링(Frustum Culling) 및 LOD(Level of Detail) 기법이 핵심적으로 사용된다 [4-9]. 최근에는 WebGL의 구조적 한계를 극복하기 위해 WebGPU와 컴퓨트 셰이더를 기반으로 한 GPU 주도 렌더링(GPU-driven Rendering) 기술로 발전하고 있다 [10, 11].
-
-## 📖 구조화된 지식 (Synthesized Content)
-*   **드로우 콜 최적화 (Draw Call Optimization)**
-    *   드로우 콜은 CPU가 GPU에 렌더링 명령을 내리는 과정으로, 프레임당 100개 이하로 유지하는 것이 부하를 막는 핵심 규칙이다 [1, 2, 4]. 
-    *   동일한 지오메트리와 재질을 여러 번 렌더링할 때는 `InstancedMesh`를 사용하여 단일 드로우 콜로 처리해야 한다 [4, 6]. 
-    *   재질은 같지만 지오메트리가 다를 경우에는 여러 지오메트리를 하나의 렌더링 호출로 묶어주는 `BatchedMesh`를 사용하는 것이 효율적이다 [12-14]. 
-    *   서로 독립적으로 움직일 필요가 없는 정적인 배경이나 환경 객체는 `BufferGeometryUtils`를 사용하여 로드 시점에 하나의 메쉬로 병합(Merge)하는 것이 좋다 [12, 15].
-
-*   **에셋 및 메모리 관리 (Asset & Memory Management)**
-    *   형상을 유지하며 폴리곤을 줄이는 데시메이션(Decimation) 작업을 거치고, Draco 확장을 통해 지오메트리 파일 크기를 최대 95%까지 압축할 수 있다 [16-18]. 
-    *   텍스처의 경우, GPU 메모리에서 압축 상태를 유지하는 KTX2나 Basis Universal 포맷을 사용해 메모리 대역폭 점유율을 크게 낮춰야 한다 [16, 19].
-    *   수백 개의 텍스처가 필요할 때는 바인딩 오버헤드를 막기 위해 텍스처 아틀라스(Texture Atlas)나 여러 텍스처 레이어를 인덱스로 접근할 수 있는 배열 텍스처(Data Array Textures)를 활용해야 한다 [7, 20, 21].
-    *   Three.js는 GPU 자원을 자동으로 가비지 컬렉션하지 않으므로, 사용이 끝난 지오메트리, 재질, 텍스처는 반드시 `.dispose()`를 명시적으로 호출해 메모리 누수를 방지해야 한다 [22, 23].
-
-*   **가시성 판단 및 LOD (Visibility & Level of Detail)**
-    *   카메라와의 거리에 따라 고해상도 메쉬를 저해상도 메쉬나 임포스터(Impostor)로 교체하는 LOD 기법을 통해 폴리곤 렌더링 비용을 크게 절감할 수 있다 [8, 24-26].
-    *   Three.js의 프러스텀 컬링(Frustum Culling)은 화면 밖의 객체를 렌더링에서 제외하지만, `InstancedMesh`의 경우 개별 인스턴스가 아닌 전체 바운딩 볼륨을 기준으로 컬링하기 때문에 보이지 않는 객체까지 GPU 정점 연산을 수행하는 낭비가 발생할 수 있다 [27]. 이를 보완하기 위해 BVH(Bounding Volume Hierarchy)와 같은 공간 분할 자료구조를 사용하거나 GPU 컴퓨트 셰이더 기반의 컬링 기법이 필요하다 [28, 29].
-
-*   **WebGPU 전환 및 GPU 주도 렌더링 (WebGPU & Compute Shaders)**
-    *   전통적인 `InstancedMesh`는 자동 정렬의 부재로 인해 깊이 오버드로우(Overdraw)가 발생하고 투명도 블렌딩 오류를 야기하며, 본(Bone) 기반 애니메이션 처리에 취약하다는 구조적 한계가 있다 [30-32].
-    *   이러한 병목을 해소하기 위해 Three.js는 WebGPU 렌더러와 단일 코드로 관리되는 TSL(Three Shader Language)을 전면 도입했다 [33, 34].
-    *   컴퓨트 셰이더를 활용하면 CPU에서 처리하던 충돌 감지, 지형 생성, 수백만 개의 파티클 업데이트 및 컬링을 GPU에서 병렬로 직접 수행할 수 있어 극적인 성능 향상을 이룰 수 있다 [35-37].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** AI 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[InstancedMesh]], [[BatchedMesh]], [[WebGPU]], [[드로우 콜 (Draw Call)]], [[LOD (Level of Detail)]]
-- **Projects/Contexts:** [[Utsubo의 WebGPU 도입 (Segments.ai 등)]], [[InstancedMesh2 라이브러리]], [[Three.js r171 WebGPURenderer]]
-- **Contradictions/Notes:** 드로우 콜을 줄이기 위해 `InstancedMesh`나 `BatchedMesh`를 도입하더라도 항상 성능이 향상되는 것은 아니다. `InstancedMesh`는 개별 컬링의 부재와 오버드로우로 인해 오히려 개별 렌더링보다 GPU FPS를 떨어뜨릴 수 있다는 점이 지적된다 [27, 30, 38]. 또한 `BatchedMesh`의 경우에도 천만 개 이상의 많은 폴리곤과 지오메트리를 처리할 때는 내부적인 다중 그리기(multi-draw) 버퍼 업로드 및 패킹 오버헤드로 인해 CPU 점유율이 40~60%까지 치솟고 프레임이 급감하는 현상이 보고되어, 상황에 따른 벤치마킹이 필수적이다 [39-43].
-
----
-*Last updated: 2026-04-19*
-- Raw Source: [[00_Raw/2026-04-20/Three.js 성능 최적화.md]]
----
diff --git a/AI/Time Series Analysis.md b/AI/Time Series Analysis.md
deleted file mode 100644
index e4bbe742..00000000
--- a/AI/Time Series Analysis.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-D84BD7
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Time Series Analysis"
----
-
-# [[Time Series Analysis]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** AI 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Time Series Analysis.md]]
----
diff --git a/AI/Time to Interactive (TTI).md b/AI/Time to Interactive (TTI).md
deleted file mode 100644
index 0d2efe79..00000000
--- a/AI/Time to Interactive (TTI).md	
+++ /dev/null
@@ -1,30 +0,0 @@
----
-id: P-REINFORCE-AUTO-8492DF
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Time to Interactive (TTI)"
----
-
-# [[Time to Interactive (TTI)]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> Time to Interactive (TTI)는 Chrome Lighthouse에서 주로 사용되는 웹 성능 측정 지표입니다 [1]. 이는 페이지 렌더링이 완료되고, JavaScript 실행이 끝나며, 브라우저의 백그라운드 작업이 완료되어 페이지가 완전히 상호작용 가능한 상태(fully interactive)가 될 때까지 걸리는 시간을 측정합니다 [1].
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** AI 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[Largest Contentful Paint (LCP)]], [[First Input Delay (FID)]]
-- **Projects/Contexts:** [[Chrome Lighthouse]]
-- **Contradictions/Notes:** 소스에 관련 정보가 부족합니다.
-
----
-*Last updated: 2026-04-19*
-- Raw Source: [[00_Raw/2026-04-20/Time to Interactive (TTI).md]]
----
diff --git a/AI/Tokenomics.md b/AI/Tokenomics.md
deleted file mode 100644
index 9008567b..00000000
--- a/AI/Tokenomics.md
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-84C772
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Tokenomics"
----
-
-# [[Tokenomics]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** AI 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Tokenomics.md]]
----
diff --git a/AI/Topology-of-Strategy-Spaces.md b/AI/Topology-of-Strategy-Spaces.md
deleted file mode 100644
index a1df60fd..00000000
--- a/AI/Topology-of-Strategy-Spaces.md
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-2D6874
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Topology-of-Strategy-Spaces"
----
-
-# [[Topology-of-Strategy-Spaces]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** AI 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Topology-of-Strategy-Spaces.md]]
----
diff --git a/AI/Trajectory-Planning.md b/AI/Trajectory-Planning.md
deleted file mode 100644
index 9a885658..00000000
--- a/AI/Trajectory-Planning.md
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-A39C55
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Trajectory-Planning"
----
-
-# [[Trajectory-Planning]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** AI 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Trajectory-Planning.md]]
----
diff --git a/AI/Transhumanism.md b/AI/Transhumanism.md
deleted file mode 100644
index 159822f8..00000000
--- a/AI/Transhumanism.md
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-B576FD
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Transhumanism"
----
-
-# [[Transhumanism]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** AI 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Transhumanism.md]]
----
diff --git a/AI/Transient Hypofrontality.md b/AI/Transient Hypofrontality.md
deleted file mode 100644
index dcc75aad..00000000
--- a/AI/Transient Hypofrontality.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-DFE168
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Transient Hypofrontality"
----
-
-# [[Transient Hypofrontality]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** AI 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Transient Hypofrontality.md]]
----
diff --git a/AI/Transient-Hypofrontality.md b/AI/Transient-Hypofrontality.md
deleted file mode 100644
index fd44afb6..00000000
--- a/AI/Transient-Hypofrontality.md
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-18B59B
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Transient-Hypofrontality"
----
-
-# [[Transient-Hypofrontality]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** AI 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Transient-Hypofrontality.md]]
----
diff --git a/AI/Transit-Oriented-Development (TOD).md b/AI/Transit-Oriented-Development (TOD).md
deleted file mode 100644
index 0d6b7a09..00000000
--- a/AI/Transit-Oriented-Development (TOD).md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-50DD5F
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Transit-Oriented-Development (TOD)"
----
-
-# [[Transit-Oriented-Development (TOD)]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** AI 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Transit-Oriented-Development (TOD).md]]
----
diff --git a/AI/Tree-of-Thought (ToT 사고 트리).md b/AI/Tree-of-Thought (ToT 사고 트리).md
deleted file mode 100644
index 14f2e74a..00000000
--- a/AI/Tree-of-Thought (ToT 사고 트리).md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-E38A5C
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Tree-of-Thought (ToT 사고 트리)"
----
-
-# [[Tree-of-Thought (ToT 사고 트리)]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** AI 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Tree-of-Thought (ToT, 사고 트리).md]]
----
diff --git a/AI/Type Definition Files (DefinitelyTyped).md b/AI/Type Definition Files (DefinitelyTyped).md
deleted file mode 100644
index 177483ee..00000000
--- a/AI/Type Definition Files (DefinitelyTyped).md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-CF3F9B
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Type Definition Files (DefinitelyTyped)"
----
-
-# [[Type Definition Files (DefinitelyTyped)]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** AI 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Type Definition Files (DefinitelyTyped).md]]
----
diff --git a/AI/Type-Composition-via-Intersection-Types.md b/AI/Type-Composition-via-Intersection-Types.md
deleted file mode 100644
index a81ee9bc..00000000
--- a/AI/Type-Composition-via-Intersection-Types.md
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-FBAE38
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Type-Composition-via-Intersection-Types"
----
-
-# [[Type-Composition-via-Intersection-Types]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** AI 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Type-Composition-via-Intersection-Types.md]]
----
diff --git a/AI/Type-Guards.md b/AI/Type-Guards.md
deleted file mode 100644
index 0ac69c2e..00000000
--- a/AI/Type-Guards.md
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-1B3627
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Type-Guards"
----
-
-# [[Type-Guards]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** AI 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Type-Guards.md]]
----
diff --git a/AI/Type-Inference.md b/AI/Type-Inference.md
deleted file mode 100644
index d8503fd1..00000000
--- a/AI/Type-Inference.md
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-37FB9B
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Type-Inference"
----
-
-# [[Type-Inference]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** AI 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Type-Inference.md]]
----
diff --git a/AI/Type-Intersection.md b/AI/Type-Intersection.md
deleted file mode 100644
index 0e5645db..00000000
--- a/AI/Type-Intersection.md
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-D16150
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Type-Intersection"
----
-
-# [[Type-Intersection]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** AI 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Type-Intersection.md]]
----
diff --git a/AI/Type-Safety-in-Distributed-Systems.md b/AI/Type-Safety-in-Distributed-Systems.md
deleted file mode 100644
index 86cb59ed..00000000
--- a/AI/Type-Safety-in-Distributed-Systems.md
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-D64613
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Type-Safety-in-Distributed-Systems"
----
-
-# [[Type-Safety-in-Distributed-Systems]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** AI 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Type-Safety-in-Distributed-Systems.md]]
----
diff --git a/AI/Type-Safety-in-Domain-Driven-Design.md b/AI/Type-Safety-in-Domain-Driven-Design.md
deleted file mode 100644
index 8be9bee6..00000000
--- a/AI/Type-Safety-in-Domain-Driven-Design.md
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-C88D89
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Type-Safety-in-Domain-Driven-Design"
----
-
-# [[Type-Safety-in-Domain-Driven-Design]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** AI 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Type-Safety-in-Domain-Driven-Design.md]]
----
diff --git a/AI/Type-Safety-in-Generics.md b/AI/Type-Safety-in-Generics.md
deleted file mode 100644
index a530c1b2..00000000
--- a/AI/Type-Safety-in-Generics.md
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-D5AEC1
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Type-Safety-in-Generics"
----
-
-# [[Type-Safety-in-Generics]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** AI 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Type-Safety-in-Generics.md]]
----
diff --git a/AI/Type-Soundness.md b/AI/Type-Soundness.md
deleted file mode 100644
index 9358beb3..00000000
--- a/AI/Type-Soundness.md
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-9C23CB
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Type-Soundness"
----
-
-# [[Type-Soundness]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** AI 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Type-Soundness.md]]
----
diff --git a/AI/Type-Theory.md b/AI/Type-Theory.md
deleted file mode 100644
index bcc8d1db..00000000
--- a/AI/Type-Theory.md
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-3E115A
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Type-Theory"
----
-
-# [[Type-Theory]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** AI 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Type-Theory.md]]
----
diff --git a/AI/Type-Unification.md b/AI/Type-Unification.md
deleted file mode 100644
index 187972c5..00000000
--- a/AI/Type-Unification.md
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-190EA7
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Type-Unification"
----
-
-# [[Type-Unification]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** AI 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Type-Unification.md]]
----
diff --git a/AI/TypeScript Compiler (tsc).md b/AI/TypeScript Compiler (tsc).md
deleted file mode 100644
index 861f2e6d..00000000
--- a/AI/TypeScript Compiler (tsc).md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-E23D67
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - TypeScript Compiler (tsc)"
----
-
-# [[TypeScript Compiler (tsc)]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** AI 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/TypeScript Compiler (tsc).md]]
----
diff --git a/AI/TypeScript Declaration Files (dts) Design.md b/AI/TypeScript Declaration Files (dts) Design.md
deleted file mode 100644
index 6ea7e836..00000000
--- a/AI/TypeScript Declaration Files (dts) Design.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-EE6A06
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - TypeScript Declaration Files (dts) Design"
----
-
-# [[TypeScript Declaration Files (dts) Design]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** AI 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/TypeScript Declaration Files (.d.ts) Design.md]]
----
diff --git a/AI/TypeScript Interface Design.md b/AI/TypeScript Interface Design.md
deleted file mode 100644
index fd9506be..00000000
--- a/AI/TypeScript Interface Design.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-2B3B7E
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - TypeScript Interface Design"
----
-
-# [[TypeScript Interface Design]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** AI 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/TypeScript Interface Design.md]]
----
diff --git a/AI/TypeScript Type System Design.md b/AI/TypeScript Type System Design.md
deleted file mode 100644
index 7761a326..00000000
--- a/AI/TypeScript Type System Design.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-616782
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - TypeScript Type System Design"
----
-
-# [[TypeScript Type System Design]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** AI 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/TypeScript Type System Design.md]]
----
diff --git a/AI/TypeScript-Advanced-Type-System-Design.md b/AI/TypeScript-Advanced-Type-System-Design.md
deleted file mode 100644
index 11afb726..00000000
--- a/AI/TypeScript-Advanced-Type-System-Design.md
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-3E5992
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - TypeScript-Advanced-Type-System-Design"
----
-
-# [[TypeScript-Advanced-Type-System-Design]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** AI 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/TypeScript-Advanced-Type-System-Design.md]]
----
diff --git a/AI/TypeScript-Compiler-API-Integration.md b/AI/TypeScript-Compiler-API-Integration.md
deleted file mode 100644
index 604d403d..00000000
--- a/AI/TypeScript-Compiler-API-Integration.md
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-C996EE
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - TypeScript-Compiler-API-Integration"
----
-
-# [[TypeScript-Compiler-API-Integration]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** AI 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/TypeScript-Compiler-API-Integration.md]]
----
diff --git a/AI/TypeScript-Domain-Driven-Design.md b/AI/TypeScript-Domain-Driven-Design.md
deleted file mode 100644
index 918341be..00000000
--- a/AI/TypeScript-Domain-Driven-Design.md
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-1EE94B
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - TypeScript-Domain-Driven-Design"
----
-
-# [[TypeScript-Domain-Driven-Design]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** AI 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/TypeScript-Domain-Driven-Design.md]]
----
diff --git a/AI/TypeScript-Interface-Design.md b/AI/TypeScript-Interface-Design.md
deleted file mode 100644
index 3de67588..00000000
--- a/AI/TypeScript-Interface-Design.md
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-8A42E4
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - TypeScript-Interface-Design"
----
-
-# [[TypeScript-Interface-Design]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** AI 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/TypeScript-Interface-Design.md]]
----
diff --git a/AI/TypeScript-Type-System-Architecture.md b/AI/TypeScript-Type-System-Architecture.md
deleted file mode 100644
index 30caeb9d..00000000
--- a/AI/TypeScript-Type-System-Architecture.md
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-82C949
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - TypeScript-Type-System-Architecture"
----
-
-# [[TypeScript-Type-System-Architecture]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** AI 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/TypeScript-Type-System-Architecture.md]]
----
diff --git a/AI/TypeScript-Type-System-Design.md b/AI/TypeScript-Type-System-Design.md
deleted file mode 100644
index 1eadf4b1..00000000
--- a/AI/TypeScript-Type-System-Design.md
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-F844F1
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - TypeScript-Type-System-Design"
----
-
-# [[TypeScript-Type-System-Design]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** AI 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/TypeScript-Type-System-Design.md]]
----
diff --git a/AI/TypeScript-Type-System-Interface-Design.md b/AI/TypeScript-Type-System-Interface-Design.md
deleted file mode 100644
index 313458af..00000000
--- a/AI/TypeScript-Type-System-Interface-Design.md
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-9A759D
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - TypeScript-Type-System-Interface-Design"
----
-
-# [[TypeScript-Type-System-Interface-Design]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** AI 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/TypeScript-Type-System-Interface-Design.md]]
----
diff --git a/AI/TypeScript-Type-System.md b/AI/TypeScript-Type-System.md
deleted file mode 100644
index 1c6f3276..00000000
--- a/AI/TypeScript-Type-System.md
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-6060FE
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - TypeScript-Type-System"
----
-
-# [[TypeScript-Type-System]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** AI 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/TypeScript-Type-System.md]]
----
diff --git a/AI/UX-Design-and-Engagement.md b/AI/UX-Design-and-Engagement.md
deleted file mode 100644
index d5ea0967..00000000
--- a/AI/UX-Design-and-Engagement.md
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-6D50AA
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - UX-Design-and-Engagement"
----
-
-# [[UX-Design-and-Engagement]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** AI 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/UX-Design-and-Engagement.md]]
----
diff --git a/AI/UX-Research-Methodologies.md b/AI/UX-Research-Methodologies.md
deleted file mode 100644
index d4310520..00000000
--- a/AI/UX-Research-Methodologies.md
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-037092
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - UX-Research-Methodologies"
----
-
-# [[UX-Research-Methodologies]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** AI 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/UX-Research-Methodologies.md]]
----
diff --git a/AI/Ubiquitous Computing Paradigm.md b/AI/Ubiquitous Computing Paradigm.md
deleted file mode 100644
index bd90d979..00000000
--- a/AI/Ubiquitous Computing Paradigm.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-C59CA1
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Ubiquitous Computing Paradigm"
----
-
-# [[Ubiquitous Computing Paradigm]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** AI 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Ubiquitous Computing Paradigm.md]]
----
diff --git a/AI/Ubiquitous Computing.md b/AI/Ubiquitous Computing.md
deleted file mode 100644
index f842b465..00000000
--- a/AI/Ubiquitous Computing.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-8C0151
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Ubiquitous Computing"
----
-
-# [[Ubiquitous Computing]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** AI 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Ubiquitous Computing.md]]
----
diff --git a/AI/Ubiquitous-Computing.md b/AI/Ubiquitous-Computing.md
deleted file mode 100644
index 66f4f900..00000000
--- a/AI/Ubiquitous-Computing.md
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-6333BB
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Ubiquitous-Computing"
----
-
-# [[Ubiquitous-Computing]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** AI 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Ubiquitous-Computing.md]]
----
diff --git a/AI/Ubiquitous-Language-Encoding.md b/AI/Ubiquitous-Language-Encoding.md
deleted file mode 100644
index 2792dc21..00000000
--- a/AI/Ubiquitous-Language-Encoding.md
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-3B5892
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Ubiquitous-Language-Encoding"
----
-
-# [[Ubiquitous-Language-Encoding]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** AI 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Ubiquitous-Language-Encoding.md]]
----
diff --git a/AI/Union-Types-vs-Overloading.md b/AI/Union-Types-vs-Overloading.md
deleted file mode 100644
index 39e5bcda..00000000
--- a/AI/Union-Types-vs-Overloading.md
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-13D0FE
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Union-Types-vs-Overloading"
----
-
-# [[Union-Types-vs-Overloading]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** AI 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Union-Types-vs-Overloading.md]]
----
diff --git a/AI/Universal-Design-Principles.md b/AI/Universal-Design-Principles.md
deleted file mode 100644
index c655002d..00000000
--- a/AI/Universal-Design-Principles.md
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-701DFC
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Universal-Design-Principles"
----
-
-# [[Universal-Design-Principles]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** AI 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Universal-Design-Principles.md]]
----
diff --git a/AI/Urban Resilience Strategies.md b/AI/Urban Resilience Strategies.md
deleted file mode 100644
index a6ef41ab..00000000
--- a/AI/Urban Resilience Strategies.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-C3A9D0
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Urban Resilience Strategies"
----
-
-# [[Urban Resilience Strategies]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** AI 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Urban Resilience Strategies.md]]
----
diff --git a/AI/Urban-Planning.md b/AI/Urban-Planning.md
deleted file mode 100644
index 0916ab65..00000000
--- a/AI/Urban-Planning.md
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-A67C66
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Urban-Planning"
----
-
-# [[Urban-Planning]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** AI 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Urban-Planning.md]]
----
diff --git a/AI/Utility Theory.md b/AI/Utility Theory.md
deleted file mode 100644
index 2c196da9..00000000
--- a/AI/Utility Theory.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-D4C836
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Utility Theory"
----
-
-# [[Utility Theory]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** AI 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Utility Theory.md]]
----
diff --git a/AI/VIA Institute on Character.md b/AI/VIA Institute on Character.md
deleted file mode 100644
index c4749b5c..00000000
--- a/AI/VIA Institute on Character.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-4C752E
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - VIA Institute on Character"
----
-
-# [[VIA Institute on Character]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** AI 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/VIA Institute on Character.md]]
----
diff --git a/AI/Value Object Pattern.md b/AI/Value Object Pattern.md
deleted file mode 100644
index 8a9ba032..00000000
--- a/AI/Value Object Pattern.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-314692
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Value Object Pattern"
----
-
-# [[Value Object Pattern]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** AI 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Value Object Pattern.md]]
----
diff --git a/AI/Value-Objects.md b/AI/Value-Objects.md
deleted file mode 100644
index 86709d91..00000000
--- a/AI/Value-Objects.md
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-038FBF
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Value-Objects"
----
-
-# [[Value-Objects]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** AI 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Value-Objects.md]]
----
diff --git a/AI/Variational-Autoencoders.md b/AI/Variational-Autoencoders.md
deleted file mode 100644
index aea9d8dd..00000000
--- a/AI/Variational-Autoencoders.md
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-92A652
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Variational-Autoencoders"
----
-
-# [[Variational-Autoencoders]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** AI 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Variational-Autoencoders.md]]
----
diff --git a/AI/Visual Positioning Systems (VPS).md b/AI/Visual Positioning Systems (VPS).md
deleted file mode 100644
index 9d8b2464..00000000
--- a/AI/Visual Positioning Systems (VPS).md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-5B3EE3
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Visual Positioning Systems (VPS)"
----
-
-# [[Visual Positioning Systems (VPS)]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** AI 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Visual Positioning Systems (VPS).md]]
----
diff --git a/AI/WAI-ARIA-Accessible-Rich-Internet-Applications.md b/AI/WAI-ARIA-Accessible-Rich-Internet-Applications.md
deleted file mode 100644
index 40b1fce2..00000000
--- a/AI/WAI-ARIA-Accessible-Rich-Internet-Applications.md
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-6F7B37
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - WAI-ARIA-Accessible-Rich-Internet-Applications"
----
-
-# [[WAI-ARIA-Accessible-Rich-Internet-Applications]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** AI 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/WAI-ARIA-Accessible-Rich-Internet-Applications.md]]
----
diff --git a/AI/Wang-Tiles.md b/AI/Wang-Tiles.md
deleted file mode 100644
index 582422c3..00000000
--- a/AI/Wang-Tiles.md
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-1C2064
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Wang-Tiles"
----
-
-# [[Wang-Tiles]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** AI 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Wang-Tiles.md]]
----
diff --git a/AI/Watermarking (AI 워터마킹).md b/AI/Watermarking (AI 워터마킹).md
deleted file mode 100644
index fa75ccda..00000000
--- a/AI/Watermarking (AI 워터마킹).md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-948507
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Watermarking (AI 워터마킹)"
----
-
-# [[Watermarking (AI 워터마킹)]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** AI 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Watermarking (AI 워터마킹).md]]
----
diff --git a/AI/Wavefunction-Collapse-Algorithm.md b/AI/Wavefunction-Collapse-Algorithm.md
deleted file mode 100644
index 9a1e0b1e..00000000
--- a/AI/Wavefunction-Collapse-Algorithm.md
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-E0FD1F
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Wavefunction-Collapse-Algorithm"
----
-
-# [[Wavefunction-Collapse-Algorithm]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** AI 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Wavefunction-Collapse-Algorithm.md]]
----
diff --git a/AI/Web Performance Optimization.md b/AI/Web Performance Optimization.md
deleted file mode 100644
index c01493f0..00000000
--- a/AI/Web Performance Optimization.md	
+++ /dev/null
@@ -1,47 +0,0 @@
----
-id: P-REINFORCE-AUTO-3862CA
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Web Performance Optimization"
----
-
-# [[Web Performance Optimization]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 웹 성능 최적화(Web Performance Optimization)는 웹사이트가 사용자에게 얼마나 빠르게 느껴지는지(인지된 성능)를 측정하고 개선하는 과정이다 [1]. 느린 웹사이트는 사용자의 좌절감을 유발하고 이탈률을 높이며 검색 엔진 순위(SEO)에도 악영향을 미치므로, 코어 웹 바이탈(Core Web Vitals)과 같은 표준화된 지표를 바탕으로 로딩 속도, 상호작용성, 시각적 안정성을 최적화하는 것이 필수적이다 [1-5].
-
-## 📖 구조화된 지식 (Synthesized Content)
-*   **주요 성능 측정 지표 (Core Web Vitals 등)**
-    *   Google은 사용자 경험을 측정하기 위해 LCP(Largest Contentful Paint, 최대 콘텐츠 렌더링 시간), INP(Interaction to Next Paint, 다음 페인트에 대한 상호작용), CLS(Cumulative Layout Shift, 누적 레이아웃 이동)를 코어 웹 바이탈 지표로 사용한다 [2, 6].
-    *   INP는 첫 번째 상호작용만 측정하던 기존의 FID(First Input Delay)를 대체한 지표로, 페이지 방문 중 발생하는 모든 클릭이나 키보드 입력 등의 전체 지연 시간을 측정하여 더욱 현실적인 반응성을 반영한다 [7-10].
-    *   이 외에도 TTFB(Time to First Byte), TTI(Time to Interactive), TBT(Total Blocking Time) 등의 보조 지표가 성능 평가에 활용된다 [11, 12].
-
-*   **데이터 수집 및 분석 방식**
-    *   **실험실 데이터(Lab Data):** Lighthouse나 WebPageTest와 같이 통제된 기기와 네트워크 환경에서 수집되는 합성 테스트(Synthetic Testing) 데이터로, 개발 과정에서 병목 현상을 디버깅하는 데 유용하다 [13-15].
-    *   **필드 데이터(Field Data):** CrUX(Chrome User Experience Report)나 실제 사용자 모니터링(RUM) 도구를 통해 실제 사용자가 겪는 성능을 측정한 데이터이다 [16, 17]. 소수 예외 값에 의한 평균의 왜곡을 피하기 위해 중앙값(p50)이나 75백분위수(p75), 95백분위수 등을 기준으로 성능을 평가한다 [18-20].
-
-*   **일반적인 웹 성능 최적화 기법**
-    *   **JavaScript 및 메인 스레드 최적화:** 50ms를 초과하는 긴 작업(Long tasks)을 작게 쪼개거나 웹 워커(Web workers)로 분리하고, 필수적이지 않은 JS의 로드를 지연(Defer)시켜야 한다 [21, 22]. Firefox 등에서 지원하는 Scheduler API(`scheduler.yield()`)를 통해 브라우저 스케줄러에 제어권을 양보하여 상호작용 지연을 줄일 수도 있다 [23].
-    *   **이미지 및 렌더링 최적화:** WebP, AVIF, JPEG XL 등 효율적인 최신 이미지 포맷을 사용하고, 뷰포트 크기에 맞는 적절한 해상도를 제공해야 한다 [24-29]. 또한 화면 밖 콘텐츠의 렌더링을 건너뛰는 CSS `content-visibility` 속성을 활용하면 초기 렌더링 성능을 크게 높일 수 있다 [30, 31]. 강제 동기식 레이아웃(Layout thrashing)을 유발하는 코드는 피해야 한다 [32, 33].
-    *   **추측 규칙(Speculation Rules):** 사용자가 링크에 마우스를 올리는 등의 상호작용 시, 향후 필요할 수 있는 리소스나 페이지를 미리 렌더링 및 로드하여 탐색 속도를 대폭 단축할 수 있다 [34, 35].
-
-*   **3D 웹 그래픽 (WebGL / WebGPU) 성능 최적화**
-    *   WebGL 환경에서는 CPU와 GPU 간의 통신과 상태 변경이 오버헤드를 유발하므로, 드로우 콜(Draw calls) 횟수를 최소화(배칭, 인스턴싱 등)하는 것이 모바일과 데스크톱 모두에서 성능을 높이는 핵심이다 [36-42]. 
-    *   WebGPU는 WebGL의 단일 스레드 구조를 벗어나 다중 스레드 명령 생성(Multi-threaded command generation)과 컴퓨트 셰이더(Compute shader)를 제공한다 [43-45]. 이를 통해 입자 시뮬레이션, 3D 가우시안 스플래팅(3DGS)에서의 심도 정렬(Depth sorting) 등 무거운 연산을 GPU로 완전히 오프로드하여 CPU 병목을 제거하고 수 배 이상의 프레임 속도 향상을 이끌어낼 수 있다 [45-51].
-    *   Cesium과 같은 3D 엔진은 씬(Scene)이 정적일 때 일정 프레임 속도로 계속 렌더링하는 대신, 카메라의 움직임이나 데이터 로드, 시간의 변화 등 꼭 필요할 때만 렌더링을 수행하는 명시적 렌더링(Explicit Rendering) 모드를 사용하여 유휴 상태의 CPU 사용량을 25%대에서 3%대로 크게 감소시켰다 [52-55].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** AI 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[Core Web Vitals]], [[Largest Contentful Paint]], [[Interaction to Next Paint]], [[Cumulative Layout Shift]], [[WebGPU]], [[WebGL]]
-- **Projects/Contexts:** [[Chrome DevTools]], [[Lighthouse]], [[Chrome User Experience Report]], [[WebPageTest]]
-- **Contradictions/Notes:** FID(First Input Delay)는 사용자의 첫 번째 상호작용 지연 시간만을 측정하는 한계가 있어, 페이지 생명주기 전체의 모든 상호작용 응답성을 추적하는 INP로 대체되었다 [7-10]. 또한, WebGL은 단일 스레드 명령 제출 구조로 인해 GPU가 유휴 상태임에도 CPU 병목이 발생하는 한계가 있었으나, WebGPU는 다중 스레드 명령 생성과 컴퓨트 셰이더를 통해 이러한 아키텍처적 한계를 해결한다 [44, 45, 56-59].
-
----
-*Last updated: 2026-04-19*
-- Raw Source: [[00_Raw/2026-04-20/Web Performance Optimization.md]]
----
diff --git a/AI/Web-Content-Accessibility-Guidelines-WCAG.md b/AI/Web-Content-Accessibility-Guidelines-WCAG.md
deleted file mode 100644
index 6e26e524..00000000
--- a/AI/Web-Content-Accessibility-Guidelines-WCAG.md
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-52EA66
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Web-Content-Accessibility-Guidelines-WCAG"
----
-
-# [[Web-Content-Accessibility-Guidelines-WCAG]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** AI 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Web-Content-Accessibility-Guidelines-WCAG.md]]
----
diff --git a/AI/WebSplatter (3D Gaussian Splatting).md b/AI/WebSplatter (3D Gaussian Splatting).md
deleted file mode 100644
index 8d000a9a..00000000
--- a/AI/WebSplatter (3D Gaussian Splatting).md	
+++ /dev/null
@@ -1,40 +0,0 @@
----
-id: P-REINFORCE-AUTO-166181
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - WebSplatter (3D Gaussian Splatting)"
----
-
-# [[WebSplatter (3D Gaussian Splatting)]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> WebSplatter는 이기종 웹 생태계를 위해 WebGPU를 기반으로 설계된 엔드투엔드(end-to-end) 3D 가우시안 스플래팅(3D Gaussian Splatting, 3DGS) 렌더링 파이프라인입니다. 기존 WebGL 기반 방식이 겪는 CPU 정렬의 병목 현상을 해결하기 위해 깊이 정렬과 뷰 적응형 평가를 모두 GPU 컴퓨트 셰이더로 이동시켰습니다. 글로벌 원자성(global atomics)이 부족한 WebGPU의 한계를 우회하는 '대기 없는 계층적 기수 정렬(wait-free hierarchical radix sort)'과 불투명도 인식 기하학 컬링을 도입하여 기존 웹 뷰어 대비 1.18배에서 4.5배의 렌더링 속도 향상과 뛰어난 메모리 효율성을 달성했습니다 [1-3].
-
-## 📖 구조화된 지식 (Synthesized Content)
-- **3D 가우시안 스플래팅과 기존 웹 렌더링의 한계**
-  3DGS 기법은 렌더링을 위해 수백만 개의 타원체를 카메라와의 깊이에 따라 매 프레임 뒤에서 앞으로 정렬해야 합니다 [4, 5]. 기존 WebGL 기반 구현에서는 이러한 정렬을 CPU(JavaScript 또는 WebAssembly)로 오프로드하고 이를 다시 대규모 버퍼 전송을 통해 GPU로 업로드했기 때문에, 심각한 동기화 병목 현상과 확장성 저하가 발생했습니다 [1, 6, 7].
-
-- **하이브리드 컴퓨트-렌더 파이프라인 (Hybrid Compute-Render Pipeline)**
-  WebSplatter는 이기종 디바이스에서 최적의 성능을 끌어내기 위해 세 단계의 파이프라인을 도입했습니다 [8].
-  - **사전 처리 단계 (Pre-processing Stage):** 컴퓨트 셰이더를 사용하여 카메라 뷰포트를 벗어나는 가우시안을 제거하는 바운딩 박스 컬링(Bounding Box Culling)과 시점 종속적 색상 계산(View-Dependent Color Calculation)을 수행합니다 [9, 10]. 이때 계산된 색상 및 불투명도 등의 데이터를 32비트 부호 없는 정수로 압축하여 이후 래스터화 단계에서의 메모리 대역폭 요구량을 대폭 줄입니다 [10, 11].
-  - **정렬 단계 (Sort Stage):** WebGPU 환경은 하드웨어별 작업 그룹 스케줄링 순서나 세밀한 글로벌 원자적 연산을 보장하지 않아, 기존에 많이 쓰이는 스핀 대기(spin-wait) 패턴을 사용할 경우 성능을 낭비하는 바쁜 대기(busy-wait) 상태에 빠질 수 있습니다 [12, 13]. WebSplatter는 이를 해결하기 위해 '대기 없는 계층적 Blelloch 스캔(wait-free hierarchical Blelloch scan)' 방식에 기반한 GPU 기수 정렬(Radix Sort) 알고리즘을 사용합니다 [14, 15].
-  - **래스터화 단계 (Rasterization Stage):** 모바일 등 대역폭이 제한된 기기에서 병목을 일으킬 수 있는 타일 기반 래스터라이저 대신, 하드웨어 가속 버텍스 및 프래그먼트 셰이더 파이프라인을 활용합니다 [16]. 가우시안의 피크 불투명도(peak opacity)를 기반으로 각 쿼드(quad)의 크기를 동적으로 계산하여 불필요한 프래그먼트 처리(오버드로우)를 최소화합니다 [17-19].
-
-- **성능 및 확장성 (메모리 효율성)**
-  WebSplatter는 고성능 데스크톱(RTX 3070)부터 Apple M시리즈 칩, 모바일 기기에 이르기까지 다양한 이기종 장치에서 일관된 성능 향상을 보여줍니다 [20-22]. 기존의 가장 우수한 WebGPU 뷰어 대비 최대 57%까지 피크 GPU 메모리 사용량을 줄여, 메모리가 극도로 제한된 모바일 스마트폰 환경에서도 브라우저 충돌(out-of-memory crash) 없이 실시간 렌더링을 안정적으로 지원합니다 [23, 24].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** AI 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[WebGPU]], [[3D Gaussian Splatting]], [[Compute Shaders]], [[Radix Sort]]
-- **Projects/Contexts:** [[Web-Based 3D Rendering]], [[Generative 3D Modeling]]
-- **Contradictions/Notes:** 소스에 따르면 기존 WebGL 뷰어는 CPU 정렬로 인해 대규모 장면에서 병목이 발생하고, 단순 네이티브 GPU 포팅 방식의 WebGPU 뷰어들은 '스핀 대기(spin-wait)' 구현으로 인해 스케줄링 순서가 보장되지 않는 하드웨어(예: Apple M1)에서 매우 심각한 성능 저하(busy-wait)를 겪습니다. WebSplatter는 자체적인 '대기 없는 기수 정렬(wait-free radix sort)' 알고리즘을 적용하여 이 문제를 완벽히 회피하였으며, 동일한 환경에서 기존 WebGPU 대비 4.5배 이상의 속도 향상을 입증했습니다 [22, 25].
-
----
-*Last updated: 2026-04-19*
-- Raw Source: [[00_Raw/2026-04-20/WebSplatter (3D Gaussian Splatting).md]]
----
diff --git a/AI/Wellbeing-Science.md b/AI/Wellbeing-Science.md
deleted file mode 100644
index 29bb11c4..00000000
--- a/AI/Wellbeing-Science.md
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-59A0A3
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Wellbeing-Science"
----
-
-# [[Wellbeing-Science]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** AI 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Wellbeing-Science.md]]
----
diff --git a/AI/Width-Subtyping.md b/AI/Width-Subtyping.md
deleted file mode 100644
index a10c74f8..00000000
--- a/AI/Width-Subtyping.md
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-20758B
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Width-Subtyping"
----
-
-# [[Width-Subtyping]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** AI 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Width-Subtyping.md]]
----
diff --git a/AI/Wikidata.md b/AI/Wikidata.md
deleted file mode 100644
index 3ddcba17..00000000
--- a/AI/Wikidata.md
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-244AE9
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Wikidata"
----
-
-# [[Wikidata]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** AI 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Wikidata.md]]
----
diff --git a/AI/Work-Engagement-Models.md b/AI/Work-Engagement-Models.md
deleted file mode 100644
index d528ac7b..00000000
--- a/AI/Work-Engagement-Models.md
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-CBB42F
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Work-Engagement-Models"
----
-
-# [[Work-Engagement-Models]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** AI 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Work-Engagement-Models.md]]
----
diff --git a/AI/World of Warcraft (Gold Sink Mechanics).md b/AI/World of Warcraft (Gold Sink Mechanics).md
deleted file mode 100644
index bb57531a..00000000
--- a/AI/World of Warcraft (Gold Sink Mechanics).md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-DA62AF
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - World of Warcraft (Gold Sink Mechanics)"
----
-
-# [[World of Warcraft (Gold Sink Mechanics)]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** AI 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/World of Warcraft (Gold Sink Mechanics).md]]
----
diff --git a/AI/_뇌와 팔다리의 분리_ - 관심사의 분리 (Separation of Concerns).md b/AI/_뇌와 팔다리의 분리_ - 관심사의 분리 (Separation of Concerns).md
deleted file mode 100644
index 16099af8..00000000
--- a/AI/_뇌와 팔다리의 분리_ - 관심사의 분리 (Separation of Concerns).md	
+++ /dev/null
@@ -1,48 +0,0 @@
----
-id: P-REINFORCE-AUTO-53B106
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - _뇌와 팔다리의 분리_ - 관심사의 분리 (Separation of Concerns)"
----
-
-# [[_뇌와 팔다리의 분리_ - 관심사의 분리 (Separation of Concerns)]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-**개념적 비유의 의미**
-관심사 분리(SoC)를 다루는 '뇌와 팔다리'의 이분법은 소프트웨어의 복잡성을 관리하기 위해 논리적 단위들을 명확하게 격리하는 아키텍처 철학입니다 [1, 4]. 
-
-*   **뇌 (Brain) - 고수준 도메인과 비즈니스 로직:** 
-    *   아키텍처의 중추 역할을 하며 시스템이 존재하는 근본적인 이유인 '핵심 업무 규칙'을 포함합니다 [1].
-    *   뇌는 엔티티(Entity)와 유스케이스(Use Case)로 구성됩니다 [2]. 엔티티는 비즈니스의 가장 본질적인 로직을 수행하고, 유스케이스는 엔티티들의 상호작용을 제어합니다 [2].
-    *   마치 뇌가 신체의 중심인 것처럼, 데이터베이스, UI, 특정 프레임워크와 같은 외부 요소에 오염되지 않는 가장 독립적이고 순수한 코드로 유지되어야 합니다 [2].
-
-*   **팔다리 (Limbs) - 인프라스트럭처와 세부 구현:** 
-    *   핵심 로직을 감싸고 외부 세계와 소통하는 저수준의 세부 사항을 의미하며, 웹 인터페이스, 데이터베이스, 서드파티 API 등이 포함됩니다 [2].
-    *   아키텍처 관점에서 팔다리는 정보를 전달하거나 저장하는 부속품이자 지엽적인 관심사로 취급됩니다 [1, 2].
-    *   팔다리가 바뀌어도 뇌의 사고방식이 변하지 않는 것처럼, 외부 시스템은 언제든 교체 가능하도록 시스템의 심장부에 '플러그인' 형태로 연결되어야 합니다 [2].
-
-*   **신경계 (Wiring) - 결합도 관리:** 
-    *   뇌와 팔다리 사이의 느슨한 결합을 유지하기 위해 인터페이스, 추상 클래스, DTO 등의 추상화된 소통 경로(신경계)가 사용됩니다 [3].
-
-*   **의존성 규칙 (Dependency Rule):** 
-    *   고수준과 저수준의 분리는 의존성의 방향이 항상 저수준(팔다리)에서 고수준(뇌)을 향하게 함으로써 달성됩니다 [3]. 
-    *   외부 시스템(팔다리)은 핵심 로직(뇌)을 알고 있지만, 뇌는 외부를 전혀 몰라야 하며, 이를 통해 도메인 로직을 수정하지 않고도 UI 기술이나 데이터베이스 구현체를 자유롭게 교체할 수 있게 됩니다 [3].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** AI 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[관심사의 분리 (Separation of Concerns)]], [[단일 책임 원칙 (SRP)]], [[의존성 역전 (Dependency Inversion)]]
-- **Projects/Contexts:** [[클린 아키텍처 (Clean Architecture)]], [[계층화 아키텍처 (Layered Architecture)]], [[도메인 주도 설계 (DDD)]]
-- **Contradictions/Notes:** 소스에 명시적인 모순점은 없으나, "뇌와 팔다리의 분리"와 같은 관심사의 분리 원칙을 맹목적으로 추구할 경우 함수 호출의 뎁스가 깊어지고 성능 오버헤드나 통신 비용이 증가할 수 있다고 경고합니다 [5]. 너무 많은 레이어와 추상화는 개발자를 미궁에 빠뜨리는 오버엔지니어링이 될 수 있으므로, 응집도와 결합도를 잣대로 최적의 분리 지점을 모색하는 절제가 필요합니다 [6, 7].
-
----
-*Last updated: 2026-04-18*
-- Raw Source: [[00_Raw/2026-04-20/_뇌와 팔다리의 분리_ - 관심사의 분리 (Separation of Concerns).md]]
----
diff --git a/AI/agargaro의 오픈 소스 라이브러리.md b/AI/agargaro의 오픈 소스 라이브러리.md
deleted file mode 100644
index 89e7f7fb..00000000
--- a/AI/agargaro의 오픈 소스 라이브러리.md	
+++ /dev/null
@@ -1,44 +0,0 @@
----
-id: P-REINFORCE-AUTO-B271A4
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - agargaro의 오픈 소스 라이브러리"
----
-
-# [[agargaro의 오픈 소스 라이브러리]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> agargaro가 개발한 오픈 소스 라이브러리는 주로 Three.js의 기본 `InstancedMesh` 성능과 기능을 획기적으로 확장한 `InstancedMesh2`를 지칭합니다 [1, 2]. 이 라이브러리는 개별 인스턴스 단위의 절두체 컬링(Frustum Culling), LOD(Level of Detail), 가시성(Visibility) 관리 및 BVH를 활용한 빠른 레이캐스팅 기능을 제공하여 대규모 3D 렌더링 성능을 최적화합니다 [2, 3]. 이 밖에도 `BatchedMesh`를 위한 확장 라이브러리인 `batched-mesh-extensions`를 제공하여 오픈 월드 수준의 환경 구현을 돕고 있습니다 [4, 5].
-
-## 📖 구조화된 지식 (Synthesized Content)
-- **InstancedMesh2의 주요 렌더링 및 제어 메커니즘**
-  - **간접 참조(Indirection) 기반 인스턴스 관리:** `InstancedBufferAttribute`를 활용하여 렌더링할 인스턴스의 인덱스를 관리합니다 [6]. 이를 통해 원본 버퍼 배열을 재정렬하지 않고도 선택적 렌더링, 효율적인 절두체 컬링, 기수 정렬(Radix sort) 기반의 깊이 정렬이 가능합니다 [6, 7]. 셰이더 작동 방식은 `BatchedMesh`와 유사하게 구현되었습니다 [8].
-  - **부분 업데이트 텍스처:** 데이터와 행렬(Matrix) 정보를 저장하기 위해 부분 업데이트(partial updates)를 지원하는 `SquareDataTexture` 자료구조를 활용하여 CPU 및 GPU 간의 데이터 전송을 최적화합니다 [6]. 
-
-- **스킨드 메쉬(Skinned Mesh) 및 애니메이션 최적화**
-  - 개별 인스턴스마다 서로 다른 애니메이션 상태를 가질 수 있습니다 [9].
-  - 카메라 절두체(Frustum) 내부에 있는 인스턴스에 대해서만 뼈대(Bone)를 업데이트합니다 [1].
-  - 카메라와의 거리에 따라 각 인스턴스의 애니메이션 FPS를 0에서 60까지 동적으로 설정하여 연산량을 줄입니다 [1].
-  - 거리가 먼 인스턴스는 일부 뼈대 계산을 피하고, meshoptimizer를 통해 생성된 최대 5단계의 지오메트리 LOD 및 그림자(Shadow) LOD를 적용할 수 있습니다 [1, 10].
-
-- **BatchedMesh 확장 라이브러리**
-  - agargaro는 다수의 서로 다른 지오메트리를 렌더링하는 데 쓰이는 `BatchedMesh`에서도 LOD 등을 구현할 수 있도록 돕는 `batched-mesh-extensions` 라이브러리를 추가로 개발했습니다 [4, 5].
-
-- **독립 라이브러리로 개발된 이유**
-  - 개별 인스턴스 절두체 컬링 기능을 Three.js 메인 레포지토리의 `InstancedMesh`에 직접 통합할 경우, 셰이더의 하위 호환성 단절(breaking changes)과 유지보수해야 할 복잡한 코드가 지나치게 많아지는 문제가 발생합니다 [11, 12]. 따라서 복잡성을 분리하기 위해 외부 라이브러리 형태로 제공되고 있습니다 [12].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** AI 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[InstancedMesh2]], [[Frustum Culling]], [[LOD(Level of Detail)]], [[BVH(Bounding Volume Hierarchy)]], [[BatchedMesh]]
-- **Projects/Contexts:** [[20k skinned instances 데모]], [[batched-mesh-extensions]]
-- **Contradictions/Notes:** 애니메이션 최적화 기법 중 뼈대 텍스처(Bone texture)의 부분 업데이트 기능이 있으나, 일부 모바일 기기 및 Firefox 브라우저에서는 해당 연산이 오히려 느리게 동작하여(이중 버퍼링 구현 필요) 기본적으로 비활성화해 두는 등 플랫폼 간 성능 편차가 존재합니다 [1, 13]. 
-
----
-*Last updated: 2026-04-19*
-- Raw Source: [[00_Raw/2026-04-20/agargaro의 오픈 소스 라이브러리.md]]
----
diff --git a/AI/clinicjs.md b/AI/clinicjs.md
deleted file mode 100644
index 26832f64..00000000
--- a/AI/clinicjs.md
+++ /dev/null
@@ -1,33 +0,0 @@
----
-id: P-REINFORCE-AUTO-B7F89C
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - clinicjs"
----
-
-# [[clinicjs]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> `clinic.js`는 Node.js 개발 환경에서 메모리 누수(Memory Leak)의 원인을 빠르고 자동화된 방식으로 분석하기 위해 사용하는 도구입니다 [1, 2]. 힙(Heap) 시각화 기능을 제공하여 애플리케이션 내 어떤 함수가 많은 메모리를 점유하고 있는지 식별하도록 돕습니다 [2]. 터미널에서 `clinic doctor -- node app.js`와 같은 명령어 형태로 실행되어 자동 분석을 수행합니다 [1].
-
-## 📖 구조화된 지식 (Synthesized Content)
-- **자동화된 힙 시각화:** `clinic.js`는 개발 중인 애플리케이션에서 메모리 누수의 근원지를 가장 빠르게 찾아내기 위한 힙 시각화(Heap Visualization) 분석 기능을 지원합니다 [2]. 
-- **메모리 점유 분석:** 분석 결과물인 차트(chart)를 통해 어떤 함수들이 가장 많은 메모리를 유지(retaining)하고 있는지 보여줍니다 [2]. 개발자는 자신이 작성한 코드의 프레임(frames) 중 예상치 못하게 차트 깊숙한 곳에 위치한 부분을 찾아내어 문제를 진단할 수 있습니다 [2].
-- **명령어 기반 실행:** 대화형 디버깅을 제공하는 `--inspect`와 같은 다른 도구와 달리, `clinic.js`는 `clinic doctor -- node app.js`와 같은 명령어를 통해 자동화된 분석(Automated analysis)을 수행하는 것이 특징입니다 [1].
-- *참고: 도구의 구체적인 내부 작동 원리 등 그 외 상세 내용에 대해서는 소스에 관련 정보가 부족합니다.*
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** AI 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[Memory Leak]], [[Heap Visualization]], [[Garbage Collection]]
-- **Projects/Contexts:** [[Node.js Performance Debugging]]
-- **Contradictions/Notes:** 소스에는 `clinic.js`의 목적과 명령어 사용법 위주의 정보만 간략히 등장하므로, 세부 아키텍처나 추가 프로파일링 기능에 대해서는 소스에 관련 정보가 부족합니다.
-
----
-*Last updated: 2026-04-19*
-- Raw Source: [[00_Raw/2026-04-20/clinic.js.md]]
----
diff --git a/AI/e스포츠 인지 상태 및 성과 위험 평가.md b/AI/e스포츠 인지 상태 및 성과 위험 평가.md
deleted file mode 100644
index fb0f4a30..00000000
--- a/AI/e스포츠 인지 상태 및 성과 위험 평가.md	
+++ /dev/null
@@ -1,40 +0,0 @@
----
-id: P-REINFORCE-AUTO-52CDF0
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - e스포츠 인지 상태 및 성과 위험 평가"
----
-
-# [[e스포츠 인지 상태 및 성과 위험 평가]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-- **생체 신호를 통한 인지 상태 감지 (Detection of Cognitive States)**
-  e스포츠 선수들이 경험하는 정신적 작업 부하(Mental Workload), 스트레스, 인지적 피로는 다양한 센서를 통해 정량화됩니다 [5]. 안구 측정에서 **동공 크기는 단기적인 인지적 노력에 비례하여 확장되지만, 장시간 플레이로 인해 인지적 피로(Cognitive Fatigue)가 누적될 경우 반대로 수축(Pupil constriction)하는 특징을 보입니다** [5], [6]. 또한, 뇌파(EEG) 데이터를 활용한 기계 학습(Gradient Boosting 등) 모델은 선수가 '상쾌한(fresh)' 상태인지 '지친(tired)' 상태인지를 최대 88%의 정확도로 성공적으로 예측해 냅니다 [6].
-
-- **자율신경계 반응과 몰입 상태 (Autonomic Responses and Flow State)**
-  심박 변이도(HRV)와 피부 전도도(EDA/GSR)는 인지 부하 및 스트레스 수준을 측정하는 핵심 지표로 활용됩니다 [3]. 급성 인지적 스트레스나 높은 작업 부하가 요구되는 경쟁 상황에서는 교감신경의 활성화로 인해 HRV가 감소하고 EDA가 크게 증가합니다 [5], [7]. 그러나 선수의 기술과 과제의 난이도가 완벽한 균형을 이루는 최적의 수행 상태인 **'몰입(Flow)' 상태에서는 부교감신경이 우세해져 HRV 지표가 오히려 증가하는 현상**이 나타납니다 [8], [9].
-
-- **전문성 평가 및 행동 지표 (Differentiating Player Expertise)**
-  생체 신호는 선수의 숙련도를 명확히 구분하는 데에도 유용합니다 [10]. 뇌파(EEG) 분석 결과, **프로 선수들은 초보자에 비해 사건 관련 전위(ERP) 반응이 20~70ms 더 빠르고 진폭이 7~9µV 더 크며**, 이를 바탕으로 숙련도를 92%의 정확도로 분류할 수 있습니다 [10]. FPS 게임에서는 중요한 운동 행동을 시작하기 전 표적에 시선을 고정하는 **'조용한 시선(Quiet Eye)'의 지속 시간이 숙련된 엘리트 선수일수록 유의미하게 길게 나타납니다** [11].
-
-- **틸트(Tilt) 및 성과 저하 예측 (Predicting Tilt and Performance Decline)**
-  회귀 트리(Regression Tree)나 SVM 등의 기계 학습 알고리즘을 다중 모달(Multimodal) 생체 신호 데이터에 적용하면, 선수의 성과가 급격히 하락하는 **'틸트(Tilt)' 상태의 시작을 실시간으로 예측**할 수 있습니다 [12], [13]. 한 연구에 따르면 과거 10~15분간의 센서 데이터를 사용하여 게임 장르에 따라 76.6%에서 87%의 높은 정확도로 틸트 상태를 예측하는 데 성공했습니다 [12]. 단, 이러한 예측 모델은 선수 개인마다 고유한 생리적 반응을 보이므로 일반화된 모델보다 **개인화된(User-dependent) 모델을 적용할 때 분류 성능이 현저히 향상(약 27% 향상)**됩니다 [14].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** AI 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[기계 학습(Machine Learning)]], [[생체 신호(Physiological Signals)]], [[심박 변이도(HRV)]], [[틸트(Tilt)]], [[몰입(Flow State)]]
-- **Projects/Contexts:** 웨어러블 센서(EEG, EDA, 시선 추적기 등)를 기반으로 한 기계 학습 모델을 통해 e스포츠 선수의 실시간 인지 상태(작업 부하, 인지적 피로)를 감지하고 성과 하락(틸트)을 예측하기 위한 프레임워크 연구 [15], [12].
-- **Contradictions/Notes:** HRV 수치는 인지적 요구와 스트레스가 높은 압박 상황에서는 감소하지만, 플레이어가 고도의 집중과 기술적 균형을 이루는 '몰입(Flow)'에 진입했을 때는 반대로 증가하므로 측정 당시의 게임 문맥에 따른 세심한 해석이 필수적입니다 [7], [8]. 동공 크기 역시 단기적인 인지적 노력의 증가에는 확장되지만, 2시간 이상의 장기적인 인지적 피로 상태에서는 수축하는 상반된 반응을 보입니다 [5], [6].
-
----
-*Last updated: 2026-04-19*
-- Raw Source: [[00_Raw/2026-04-20/e스포츠 인지 상태 및 성과 위험 평가.md]]
----
diff --git a/AI/가상화 (Virtualization).md b/AI/가상화 (Virtualization).md
deleted file mode 100644
index 2e4fb06b..00000000
--- a/AI/가상화 (Virtualization).md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-9E9923
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - 가상화 (Virtualization)"
----
-
-# [[가상화 (Virtualization)]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** AI 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/가상화 (Virtualization).md]]
----
diff --git a/AI/강화학습 (Reinforcement Learning).md b/AI/강화학습 (Reinforcement Learning).md
deleted file mode 100644
index 0eb47e3f..00000000
--- a/AI/강화학습 (Reinforcement Learning).md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-FE1230
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - 강화학습 (Reinforcement Learning)"
----
-
-# [[강화학습 (Reinforcement Learning)]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** AI 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/강화학습 (Reinforcement Learning).md]]
----
diff --git a/AI/공급망 공격 (Supply Chain Attack).md b/AI/공급망 공격 (Supply Chain Attack).md
deleted file mode 100644
index c7cb3f13..00000000
--- a/AI/공급망 공격 (Supply Chain Attack).md	
+++ /dev/null
@@ -1,40 +0,0 @@
----
-id: P-REINFORCE-AUTO-2BF446
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - 공급망 공격 (Supply Chain Attack)"
----
-
-# [[공급망 공격 (Supply Chain Attack)]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 공급망 공격(Supply Chain Attack)은 오픈소스 파이프라인이 상호 신뢰를 바탕으로 운영된다는 점을 악용하여, 널리 사용되는 합법적인 패키지나 개발 도구의 유지보수자 계정을 탈취해 악성 코드를 다운스트림 환경에 유포하는 공격 방식입니다 [1]. 한 명의 유지보수자 계정이나 단일 패키지가 손상되는 것만으로도 수천만 건의 설치로 피해가 파급될 수 있어 소프트웨어 생태계 전반에 대규모 위험을 초래합니다 [1, 2]. 코드 품질과 안전을 보장하기 위해 사용하는 도구 자체가 개발자를 공격하는 무기로 돌변할 수 있다는 점에서 현대 소프트웨어 개발의 중대한 위협으로 꼽힙니다 [2].
-
-## 📖 구조화된 지식 (Synthesized Content)
-* **공급망 공격의 원리와 위험성:**
-  대부분의 소프트웨어 프로젝트는 수많은 서드파티 오픈소스 패키지와 의존성(Dependencies)을 바탕으로 구축됩니다. 공격자는 이러한 소프트웨어 공급망을 노리며, 유지보수자의 권한(예: npm 인증 토큰)을 피싱과 같은 기법으로 탈취합니다 [3, 4]. 이후 소스 코드 저장소(GitHub 등)에는 어떠한 커밋 흔적도 남기지 않고, 패키지 관리 레지스트리에 직접 악성 버전의 패키지를 게시하여 신뢰 체인을 무너뜨립니다 [3].
-
-* **실제 공격 사례 (CVE-2025-54313):**
-  2025년 7월 18일, 주당 3,000만 회 이상 다운로드되는 인기 npm 라이브러리인 `eslint-config-prettier`를 대상으로 대규모 공급망 공격이 발생했습니다 [2, 4, 5]. 공격자는 `npmjs.com` 로그인 페이지를 위장한 피싱 이메일로 메인테이너를 속여 권한 토큰을 탈취한 후, 4개 버전(8.10.1, 9.1.1, 10.1.6, 10.1.7)에 악성 코드를 심어 배포했습니다 [3, 4, 6]. 이 외에도 `eslint-plugin-prettier`, `synckit` 등 여러 패키지가 동시에 피해를 입었습니다 [6].
-
-* **악성 페이로드 작동 방식:**
-  해당 공격은 npm의 설치 후 스크립트(post-install script) 기능을 악용했습니다. 패키지가 설치되는 즉시 `install.js` 파일이 실행되며, 내부의 `logDiskSpace()`라는 위장된 함수를 통해 `node-gyp.dll`이라는 악성 DLL 파일을 드롭(drop)하고 Windows의 `rundll32` 시스템 프로세스로 이를 실행시켰습니다 [7]. 이를 통해 공격자는 Windows를 사용하는 개발자의 로컬 머신이나 CI(지속적 통합) 호스트에서 원격 코드 실행(RCE) 권한을 획득할 수 있었습니다 [2, 3]. (이 악성 코드는 Linux나 macOS 환경에서는 즉시 종료되도록 설계되었습니다 [7, 8]).
-
-* **대응 및 방어 전략:**
-  "유지보수자의 보안이 곧 공급망 보안(Maintainer Security is Supply Chain Security)"입니다 [1]. 향후 이러한 공격을 예방하기 위해서는 다중 인증(MFA)의 강제 적용, 권한이 좁게 제한된 토큰(scoped tokens)의 사용, 더 엄격한 npm 게시 정책이 필수적입니다 [1]. 프로젝트 차원에서는 `package-lock.json`이나 `yarn.lock` 파일을 검토해 침해된 버전을 배제하고 알려진 안전한 버전으로 고정(Pinning)해야 하며, 빌드 파이프라인의 비정상적인 활동을 즉각 감사해야 합니다 [9]. 또한, 서드파티 라이브러리의 취약점을 파악하고 공급망 리스크를 완화하기 위해 SCA(Software Composition Analysis) 도구를 정기적으로 활용해야 합니다 [10, 11].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** AI 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[CVE-2025-54313]], [[Software Composition Analysis (SCA)]], [[eslint-config-prettier]]
-- **Projects/Contexts:** [[npm registry]], [[Open Source Security]]
-- **Contradictions/Notes:** 소스에 관련된 모순점은 발견되지 않았습니다.
-
----
-*Last updated: 2026-04-19*
-- Raw Source: [[00_Raw/2026-04-20/공급망 공격 (Supply Chain Attack).md]]
----
diff --git a/AI/대규모 React 프론트엔드 최적화.md b/AI/대규모 React 프론트엔드 최적화.md
deleted file mode 100644
index 722de782..00000000
--- a/AI/대규모 React 프론트엔드 최적화.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-FAAB3D
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - 대규모 React 프론트엔드 최적화"
----
-
-# [[대규모 React 프론트엔드 최적화]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** AI 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/대규모 React 프론트엔드 최적화.md]]
----
diff --git a/AI/도메인 주도 설계 (Domain-Driven Design DDD).md b/AI/도메인 주도 설계 (Domain-Driven Design DDD).md
deleted file mode 100644
index 17be026d..00000000
--- a/AI/도메인 주도 설계 (Domain-Driven Design DDD).md	
+++ /dev/null
@@ -1,40 +0,0 @@
----
-id: P-REINFORCE-AUTO-B7F6A8
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - 도메인 주도 설계 (Domain-Driven Design DDD)"
----
-
-# [[도메인 주도 설계 (Domain-Driven Design DDD)]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 도메인 주도 설계(DDD)는 비즈니스 도메인에 대한 깊은 이해를 중심으로 소프트웨어 개발 프로세스를 구성하는 설계 접근 방식입니다 [1]. 기술 팀과 도메인 전문가 간의 긴밀한 협력을 바탕으로 현실 세계의 비즈니스 프로세스를 정확하게 반영하는 소프트웨어 모델을 생성하는 것을 목표로 합니다 [1]. 이를 통해 시스템의 복잡성을 해결하고 개발자와 비즈니스 이해관계자 간의 의사소통 격차를 해소하여, 결과적으로 소프트웨어가 올바른 문제를 해결할 수 있도록 보장합니다 [1].
-
-## 📖 구조화된 지식 (Synthesized Content)
-- **유비쿼터스 언어(Ubiquitous Language)의 확립:**
-  DDD의 핵심 목표 중 하나는 프로젝트에 참여하는 모든 사람(개발자 및 도메인 전문가 등)이 공유하는 공통 어휘 사전인 '유비쿼터스 언어'를 만드는 것입니다 [1, 2]. 이 언어는 일상적인 대화, 문서화는 물론 실제 코드 자체에서도 동일하게 사용되어야 하며, 이를 통해 요구사항에 대한 오해를 방지하고 도메인 모델을 명확히 합니다 [1, 2].
-- **제한된 컨텍스트(Bounded Contexts)를 통한 복잡성 관리:**
-  크고 복잡한 도메인은 '주문 관리'나 '고객 지원'과 같이 더 작고 관리하기 쉬운 하위 도메인인 '제한된 컨텍스트'로 분할됩니다 [3]. 각 컨텍스트는 고유한 모델과 유비쿼터스 언어를 유지하여 모델의 순수성을 보장하고, 각기 다른 책임 영역 간의 명확한 경계를 정의하여 도메인 로직을 캡슐화합니다 [3-5].
-- **전략적 모델링 구성 요소:**
-  - **애그리게잇(Aggregates):** 단일 단위로 취급할 수 있는 도메인 객체들의 클러스터입니다(예: `OrderLineItem` 객체를 포함하는 `Order`). 애그리게잇의 루트는 전체 클러스터의 일관성을 보장하며 트랜잭션 관리를 단순화하는 역할을 합니다 [3].
-  - **엔티티(Entities)와 값 객체(Value Objects):** 고유한 정체성(Identity)을 바탕으로 구별되는 객체(예: `Customer` 엔티티)와, 고유 식별자 없이 오직 속성으로만 정의되는 객체(예: `ShippingAddress` 값 객체)를 명확히 구분하여 설계합니다 [3].
-- **도메인 로직의 격리 및 이벤트 스토밍(Event Storming):**
-  핵심 비즈니스 로직은 데이터베이스나 UI 프레임워크와 같은 외부 인프라스트럭처 문제와 철저히 분리되어야 하며, 이를 통해 깔끔하고 테스트 및 유지보수가 쉬운 도메인 모델을 생성할 수 있습니다 [2]. 또한 비즈니스 도메인을 빠르게 탐색하고 도메인 이벤트, 명령, 애그리게잇을 식별하기 위해 '이벤트 스토밍(Event Storming)'과 같은 협업 워크샵을 적극적으로 활용하는 것이 권장됩니다 [2].
-- **도입 시 특징 및 적합한 환경:**
-  DDD는 깊은 도메인 모델링과 이해관계자의 지속적인 협업이 필수적이므로 초기 구현 복잡도와 리소스 요구 사항(분석 시간, 도메인 전문가 참여 등)이 상대적으로 높은 편입니다 [6]. 따라서 단순한 시스템보다는 금융, 의료, 이커머스와 같이 비즈니스 도메인이 매우 복잡한 엔터프라이즈 시스템 구축에 가장 이상적인 아키텍처 베스트 프랙티스입니다 [6].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** AI 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[유비쿼터스 언어(Ubiquitous Language)]], [[제한된 컨텍스트(Bounded Contexts)]], [[애그리게잇(Aggregates)]], [[관심사의 분리(Separation of Concerns)]]
-- **Projects/Contexts:** [[복잡한 비즈니스 도메인(금융, 의료, 이커머스 등)을 다루는 대규모 시스템 개발 프로젝트]]
-- **Contradictions/Notes:** 소스 내에서 상충하는 주장은 발견되지 않으나, DDD는 비즈니스 구조와의 강력한 일치와 명확한 도메인 모델을 제공하는 큰 장점이 있는 반면, 도입 시 도메인 전문가와의 심도 있는 협업 모델링이 필요하여 중간에서 높음(Medium-High) 수준의 복잡성과 리소스가 요구된다는 점이 주의사항으로 지적됩니다 [6].
-
----
-*Last updated: 2026-04-18*
-- Raw Source: [[00_Raw/2026-04-20/도메인 주도 설계 (Domain-Driven Design, DDD).md]]
----
diff --git a/AI/도파민 보상 체계 (Dopaminergic Reward System).md b/AI/도파민 보상 체계 (Dopaminergic Reward System).md
deleted file mode 100644
index 6511532f..00000000
--- a/AI/도파민 보상 체계 (Dopaminergic Reward System).md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-90ACEA
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - 도파민 보상 체계 (Dopaminergic Reward System)"
----
-
-# [[도파민 보상 체계 (Dopaminergic Reward System)]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** AI 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/도파민 보상 체계 (Dopaminergic Reward System).md]]
----
diff --git a/AI/디자인 시스템 (Design Systems).md b/AI/디자인 시스템 (Design Systems).md
deleted file mode 100644
index 76c25be9..00000000
--- a/AI/디자인 시스템 (Design Systems).md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-891E2B
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - 디자인 시스템 (Design Systems)"
----
-
-# [[디자인 시스템 (Design Systems)]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** AI 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/디자인 시스템 (Design Systems).md]]
----
diff --git a/AI/마이크로서비스 아키텍처 (Microservices Architecture).md b/AI/마이크로서비스 아키텍처 (Microservices Architecture).md
deleted file mode 100644
index 16169ed4..00000000
--- a/AI/마이크로서비스 아키텍처 (Microservices Architecture).md	
+++ /dev/null
@@ -1,46 +0,0 @@
----
-id: P-REINFORCE-AUTO-303610
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - 마이크로서비스 아키텍처 (Microservices Architecture)"
----
-
-# [[마이크로서비스 아키텍처 (Microservices Architecture)]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 마이크로서비스 아키텍처(MSA)는 크고 복잡한 단일 애플리케이션을 비즈니스 도메인(Business Domain)을 중심으로 작고 독립적이며 자율적인 서비스들의 집합으로 구조화하는 소프트웨어 개발 접근 방식입니다 [1-3]. 각 마이크로서비스는 자체 프로세스에서 실행되며 주로 HTTP/REST API나 비동기 메시징 큐와 같은 경량화된 네트워크 메커니즘을 통해 통신합니다 [3, 4]. 이 아키텍처는 개별 서비스의 독립적인 개발, 배포 및 확장을 가능하게 하여 시스템의 유지보수성, 유연성 및 장애 복원력을 크게 향상시킵니다 [1, 5].
-
-## 📖 구조화된 지식 (Synthesized Content)
-*   **핵심 개념 및 특징**
-    *   마이크로서비스는 단일 비즈니스 기능(Single business task)에 집중하며, 각 서비스가 자체 코드베이스, CI/CD 파이프라인 및 독립적인 데이터 저장소를 가집니다 [4, 6, 7].
-    *   시스템을 작은 단위로 분해함으로써 각 팀은 자신이 담당한 서비스를 처음부터 끝까지 독립적으로 소유(End-to-End Ownership)할 수 있습니다 [5, 8].
-    *   다양한 기술을 융합하여 사용할 수 있는 기술적 이질성(Technology Heterogeneity)을 지원하므로, 각 서비스의 특성에 맞는 최적의 도구와 데이터베이스(폴리글랏 프로그래밍 및 영속성)를 자율적으로 선택할 수 있습니다 [4, 9, 10].
-
-*   **마이크로서비스 도입의 주요 장점**
-    *   **민첩성 및 확장성:** 단일 구조(Monolithic)와 달리 전체 애플리케이션을 재배포할 필요 없이 필요한 개별 서비스만 병렬로 개발하고 자주 업데이트하며, 유연하게 자원을 확장할 수 있습니다 [1, 9, 11].
-    *   **장애 복원력(Resilience):** 고장 격리(Fault isolation)를 통해 한 서비스에 장애가 발생하더라도 문제의 범위(Blast radius)를 최소화하여 전체 시스템의 중단으로 이어지지 않도록 설계할 수 있습니다 [9, 12, 13].
-    *   **조직적 효율성:** 넷플릭스(Netflix), 아마존(Amazon), 스포티파이(Spotify) 등의 기업 사례처럼 소규모 전담 팀에게 비즈니스 역량에 따른 책임을 분산하여 개발 속도와 혁신성을 크게 높일 수 있습니다 [1, 14, 15].
-
-*   **주요 단점 및 해결 과제**
-    *   분산 시스템의 본질적인 복잡성으로 인해 서비스 간 통신, 부분적 실패 처리, 모니터링 등의 추가적인 분산 처리 로직을 직접 구현해야 하며, 이를 지원할 고도로 숙련된 엔지니어가 필요합니다 [10, 11, 16].
-    *   여러 서비스에 걸쳐 동작하는 요청과 트랜잭션을 관리하는 것이 매우 까다로우며, 각 서비스마다 독립적인 런타임(JVM 등)과 서버 공간을 유지해야 하므로 인프라 및 운영 비용이 증가합니다 [11, 16, 17].
-    *   이에 대응하기 위해 회로 차단기(Circuit Breakers), 재시도(Retries) 등 실패를 대비한 설계와 컨테이너(Docker), 오케스트레이션(Kubernetes)을 활용한 운영 자동화의 도입이 필수적입니다 [18].
-
-*   **구성 패턴 (Composition Patterns)**
-    *   마이크로서비스 간의 통신과 흐름을 제어하기 위해 Aggregator, Proxy, Branch, Chained, Shared Resource 등 다양한 구성 패턴이 실무에서 활용됩니다 [19, 20].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** AI 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[단일 애플리케이션 아키텍처 (Monolithic Architecture)]], [[관심사의 분리 (Separation of Concerns)]], [[도메인 주도 설계 (Domain-Driven Design)]], [[컨테이너 및 오케스트레이션 (Containers and Orchestration)]]
-- **Projects/Contexts:** [[넷플릭스 코스모스 플랫폼 (Netflix Cosmos Platform)]], [[스포티파이 스쿼드 모델 (Spotify Squad Model)]]
-- **Contradictions/Notes:** 일반적으로 마이크로서비스는 완벽한 모듈의 결합 분리와 배포 독립성을 가져다주는 것으로 간주되지만, 실제로는 시스템이 횡단 관심사(Cross-cutting concerns)나 공유 데이터 모델에 얽혀있을 경우 여러 서비스가 강하게 결합되는 '결합 분리의 오류' 및 '개발 및 배포 독립성의 오류'가 발생할 수 있습니다. 즉 서비스 간의 단순 물리적 분리만으로는 충분치 않으며, 서비스 내부의 아키텍처 경계와 의존성 규칙이 제대로 설계되어야 진정한 독립성을 확보할 수 있습니다 [21-24].
-
----
-*Last updated: 2026-04-18*
-- Raw Source: [[00_Raw/2026-04-20/마이크로서비스 아키텍처 (Microservices Architecture).md]]
----
diff --git a/AI/벡터 데이터베이스 (Vector Database).md b/AI/벡터 데이터베이스 (Vector Database).md
deleted file mode 100644
index f23cafd4..00000000
--- a/AI/벡터 데이터베이스 (Vector Database).md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-A4C204
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - 벡터 데이터베이스 (Vector Database)"
----
-
-# [[벡터 데이터베이스 (Vector Database)]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** AI 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/벡터 데이터베이스 (Vector Database).md]]
----
diff --git a/AI/보존 경로(Retaining Path).md b/AI/보존 경로(Retaining Path).md
deleted file mode 100644
index c8efb674..00000000
--- a/AI/보존 경로(Retaining Path).md	
+++ /dev/null
@@ -1,33 +0,0 @@
----
-id: P-REINFORCE-AUTO-97AEC6
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - 보존 경로(Retaining Path)"
----
-
-# [[보존 경로(Retaining Path)]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 보존 경로(Retaining Path)는 메모리 누수를 조사할 때 특정 객체가 가비지 컬렉션(GC)에 의해 수거되지 않고 살아남게 만드는 참조 체인(chain of references)을 의미합니다 [1, 2]. V8 엔진은 전역 창(window) 객체나 활성 스택의 로컬 변수와 같은 루트 객체(GC Root)로부터 포인터 체인을 통해 도달 가능한 객체를 메모리에 유지해야 할 객체로 간주합니다 [3]. 개발자는 힙 스냅샷 도구나 특수 디버깅 플래그를 사용하여 이러한 보존 경로를 역추적하고 불필요한 참조를 식별하여 메모리 누수 문제를 해결할 수 있습니다 [2-4].
-
-## 📖 구조화된 지식 (Synthesized Content)
-* **보존 경로의 개념 및 역할:** 가비지 컬렉터는 루트 객체로부터 참조를 통해 도달할 수 있는 객체를 '살아있는(live)' 객체로 판단하여 수거 대상에서 제외합니다 [3, 5]. 메모리 누수가 발생했을 때, 객체가 왜 수거되지 않는지를 파악하기 위해서는 이 보존 경로를 추적하는 것이 필수적입니다 [4]. 모든 힙 스냅샷은 많은 후방(back) 참조와 루프를 포함하고 있어 하나의 객체에 여러 보존자가 존재할 수 있습니다 [5].
-* **개발자 도구(DevTools)를 통한 분석:** Chrome DevTools의 Memory 패널에서 힙 스냅샷(Heap Snapshot)이나 할당 타임라인(Allocation timeline)을 통해 특정 객체를 선택하면, 'Retainers(보존자)' 섹션에서 해당 객체의 보존 트리(Retaining tree)를 확인할 수 있습니다 [1, 2, 4, 6]. 이 트리는 누수된 객체에서부터 이를 붙잡고 있는 GC 루트까지의 경로를 역순(reverse)으로 보여줍니다 [3, 7].
-* **보존자 무시(Ignore retainers) 기능:** DevTools에서는 특정 보존자를 마우스 우클릭하여 "Ignore this retainer"를 선택함으로써 해당 참조를 숨길 수 있습니다 [8]. 이를 통해 코드를 직접 수정하여 참조를 제거한 뒤 스냅샷을 다시 찍는 번거로운 과정 없이, 다른 객체가 해당 객체를 계속 보존하고 있는지 쉽게 파악할 수 있습니다 [8].
-* **로우레벨(Low-level) 추적:** 매우 복잡한 누수의 경우 V8의 내부 함수인 `%DebugTrackRetainingPath(object)`를 사용할 수 있습니다 [3, 9]. `--allow-natives-syntax` 및 `--track-retaining-path` 런타임 플래그와 함께 실행하면, GC가 발생할 때마다 보존 경로 내 모든 내부 객체의 16진수 주소와 타입을 출력하여 DevTools UI의 추상화를 우회하는 세부적인 로그를 얻을 수 있습니다 [3, 9]. gdb나 lldb와 같은 디버거 세션 중에도 `isolate->heap()->PrintRetainingPath(HeapObject*)` 명령을 통해 객체의 보존 경로를 출력할 수 있습니다 [10].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** AI 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[Garbage Collection]], [[Heap Snapshot]], [[GC Root]], [[Memory Leak]]
-- **Projects/Contexts:** [[V8 Engine]], [[Chrome DevTools]], [[Node.js Memory Management]]
-- **Contradictions/Notes:** 소스 내에 상충되는 내용은 없습니다. 보존 경로는 개념적으로 루트(Root) 객체로부터 시작되는 포인터의 체인이지만, DevTools 등의 분석 도구에서는 누수된 객체에서 루트로 올라가는 역순(reverse)으로 경로를 시각화하여 디버깅을 돕습니다 [3].
-
----
-*Last updated: 2026-04-19*
-- Raw Source: [[00_Raw/2026-04-20/보존 경로(Retaining Path).md]]
----
diff --git a/AI/보편적 언어 (Ubiquitous Language).md b/AI/보편적 언어 (Ubiquitous Language).md
deleted file mode 100644
index 3e05d30e..00000000
--- a/AI/보편적 언어 (Ubiquitous Language).md	
+++ /dev/null
@@ -1,32 +0,0 @@
----
-id: P-REINFORCE-AUTO-560AB4
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - 보편적 언어 (Ubiquitous Language)"
----
-
-# [[보편적 언어 (Ubiquitous Language)]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 보편적 언어(Ubiquitous Language)는 도메인 주도 설계(Domain-Driven Design)에서 복잡성을 해결하기 위해 프로젝트의 모든 참여자가 공통으로 사용하는 공유 언어입니다 [1]. 이는 개발자와 비즈니스 이해관계자 간의 의사소통 격차를 해소하는 공통 어휘 역할을 합니다 [1]. 궁극적으로 소프트웨어가 올바른 비즈니스 문제를 해결하도록 보장하는 데 핵심적인 목적이 있습니다 [1].
-
-## 📖 구조화된 지식 (Synthesized Content)
-- **개념 및 목적:** 보편적 언어는 도메인 전문가와 긴밀히 협력하여 용어에 대한 공유 사전(glossary)을 생성하고 유지함으로써 비즈니스 도메인의 복잡성을 다루는 방식입니다 [1, 2]. 
-- **적용 범위:** 이 언어는 단순히 구두 대화에만 국한되지 않으며, 프로젝트의 문서화 작업은 물론 실제 소프트웨어 코드 자체에서도 동일하고 일관되게 사용되어야 합니다 [2].
-- **Bounded Contexts와의 연관성:** 크고 복잡한 도메인은 '주문 관리'나 '고객 지원'과 같이 더 작고 관리하기 쉬운 'Bounded Contexts'로 나뉩니다 [3]. 각각의 Bounded Context는 고유한 모델과 자신만의 보편적 언어를 가지며, 이를 통해 각 소프트웨어 모델을 순수하고 집중된 상태로 유지할 수 있습니다 [3].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** AI 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[Domain-Driven Design (DDD)]], [[Bounded Contexts]]
-- **Projects/Contexts:** [[소프트웨어 아키텍처 설계]]
-- **Contradictions/Notes:** 소스에 관련 정보가 부족합니다.
-
----
-*Last updated: 2026-04-18*
-- Raw Source: [[00_Raw/2026-04-20/보편적 언어 (Ubiquitous Language).md]]
----
diff --git a/AI/브라우저 메모리 누수 탐지(Browser Memory Leak Detection).md b/AI/브라우저 메모리 누수 탐지(Browser Memory Leak Detection).md
deleted file mode 100644
index 8b6b3a29..00000000
--- a/AI/브라우저 메모리 누수 탐지(Browser Memory Leak Detection).md	
+++ /dev/null
@@ -1,40 +0,0 @@
----
-id: P-REINFORCE-AUTO-CC0FCE
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - 브라우저 메모리 누수 탐지(Browser Memory Leak Detection)"
----
-
-# [[브라우저 메모리 누수 탐지(Browser Memory Leak Detection)]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 브라우저 메모리 누수는 가비지 컬렉션(GC) 대상이 되어야 할 객체들이 Window, 클로저, 이벤트 리스너 등의 GC 루트(Roots)에 의해 계속 참조되어 메모리에서 해제되지 않는 현상이다 [1]. 이를 탐지하고 원인을 파악하기 위해 주로 Chrome DevTools의 힙 스냅샷(Heap snapshot)과 할당 타임라인(Allocation timeline) 도구가 사용된다 [1, 2]. 이러한 도구들을 활용하면 메모리에 남아 있는 객체의 참조 체인(Retainers)과 할당된 스택 트레이스를 분석하여 애플리케이션의 메모리 누수 근본 원인을 식별할 수 있다 [2].
-
-## 📖 구조화된 지식 (Synthesized Content)
-* **메모리 누수의 정의 및 주요 원인:**
-  브라우저 자바스크립트에서 메모리 누수는 메모리가 단순히 '손실'되는 것이 아니라, 더 이상 사용할 필요가 없는 객체가 참조를 유지하여 가비지 컬렉터가 회수하지 못하는 상태를 의미한다 [1]. 현대 프론트엔드 애플리케이션의 주요 누수 패턴으로는 문서에서 제거된 DOM 요소가 자바스크립트 변수에 계속 참조되는 '분리된 DOM 노드(Detached DOM nodes)', 해제되지 않은 '이벤트 리스너 누적', 공유 스코프 객체로 인한 '클로저 스코프 보존(Closure scope retention)', 그리고 정리되지 않은 '타이머 및 옵저버(Forgotten timers and observers)' 등이 있다 [3-5]. 특히 SPA(Single Page Application)의 라우트 전환 시 이전 라우트의 컴포넌트가 제대로 정리되지 않는 것이 누수의 가장 큰 원인 중 하나이다 [6].
-
-* **힙 스냅샷(Heap Snapshot)을 활용한 탐지:**
-  힙 스냅샷은 특정 시점의 전체 객체 그래프를 캡처한다 [2]. 누수를 찾는 가장 신뢰할 수 있는 방법은 '3-스냅샷 기법(Three-snapshot technique)'이다. 기준점(스냅샷 1)을 잡고 누수 의심 작업을 수행한 뒤 스냅샷 2를 캡처하고, 같은 작업을 반복한 뒤 스냅샷 3을 캡처한다 [7]. 이후 스냅샷 2와 3을 비교(Comparison 뷰 활용)하여 지속적으로 살아남는 객체를 찾으면 일회성 할당에 의한 오탐지를 필터링할 수 있다 [2, 7, 8]. 'Retainers' 패널을 통해 해당 객체를 메모리에 살아있게 만드는 참조 체인을 추적하여 원인을 파악할 수 있다 [2, 9].
-
-* **할당 타임라인(Allocation Timeline):**
-  할당 타임라인 도구는 일정 기간 동안의 모든 메모리 할당과 스택 트레이스를 기록한다 [2]. 타임라인에 표시되는 파란색 막대는 타임라인 종료 시점까지 여전히 살아있는(누수 의심) 객체를, 회색 막대는 이미 가비지 컬렉션된 객체를 나타낸다 [2, 10-12]. 특정 시간대의 파란색 막대를 확대하여 생성자(Constructor)와 할당 스택(Allocation stack)을 확인하면, 해당 객체가 코드의 어느 위치에서 생성되었는지 정확히 추적할 수 있다 [2, 11, 13].
-
-* **주의사항 및 프로덕션 환경 측정:**
-  DevTools 힙 스냅샷에는 V8 내부 객체도 수천 개 포함되므로 애플리케이션 객체에 집중하기 위해 필터링이 필요하다 [6]. 또한, `console.log`는 로깅된 객체에 대한 참조를 유지하므로 누수 조사 중에는 사용을 피하거나 콘솔을 주기적으로 지워야 한다 [6]. 프로덕션 환경에서는 전체 추적에 따른 오버헤드를 피하기 위해 통계적 샘플링을 사용하는 '할당 샘플링(Allocation sampling)'이나 프로그래밍 방식으로 메모리 사용량을 측정하는 `performance.measureUserAgentSpecificMemory()` API를 활용할 수 있다 [3, 6].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** AI 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[가비지 컬렉션(Garbage Collection)]], [[힙 스냅샷(Heap Snapshot)]], [[클로저(Closures)]], [[V8 엔진(V8 Engine)]]
-- **Projects/Contexts:** [[Chrome DevTools]], [[Single Page Applications (SPA)]]
-- **Contradictions/Notes:** 메모리 사용량 그래프가 증가한다고 해서 모두 누수는 아니다. 캐시, 실행 취소 내역, 가상화된 리스트 버퍼 등은 의도적으로 데이터를 유지하는 것이므로, 의도적인 보존(Intentional retention)과 우발적인 누수(Accidental retention)를 반드시 구별해야 한다 [6]. 또한, `WeakRef`와 `FinalizationRegistry`를 사용해 누수에 강한 패턴을 작성할 수는 있으나, GC의 실행 시점은 비결정적이므로 이를 적절한 생명주기 관리의 대체재로 사용해서는 안 된다 [5].
-
----
-*Last updated: 2026-04-19*
-- Raw Source: [[00_Raw/2026-04-20/브라우저 메모리 누수 탐지(Browser Memory Leak Detection).md]]
----
diff --git a/AI/비즈니스 도메인 모델링 (Business Domain Modeling).md b/AI/비즈니스 도메인 모델링 (Business Domain Modeling).md
deleted file mode 100644
index 7e9b0cf2..00000000
--- a/AI/비즈니스 도메인 모델링 (Business Domain Modeling).md	
+++ /dev/null
@@ -1,39 +0,0 @@
----
-id: P-REINFORCE-AUTO-980499
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - 비즈니스 도메인 모델링 (Business Domain Modeling)"
----
-
-# [[비즈니스 도메인 모델링 (Business Domain Modeling)]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 비즈니스 도메인 모델링은 기술 팀과 도메인 전문가가 긴밀히 협력하여 실제 비즈니스 프로세스를 정확하게 반영하는 소프트웨어 모델을 구축하는 접근 방식입니다 [1]. 이 모델링 과정은 복잡한 비즈니스 로직을 부차적인 것으로 취급하지 않고 애플리케이션의 핵심으로 삼으며, 개발자와 비즈니스 이해관계자 간의 의사소통 격차를 줄이는 '보편적 언어(Ubiquitous Language)'를 생성하여 시스템의 복잡성을 해결하는 것을 목표로 합니다 [1]. 이를 통해 크고 복잡한 비즈니스 도메인을 작고 관리하기 쉬운 하위 도메인으로 나누어 체계적으로 구조화할 수 있습니다 [2].
-
-## 📖 구조화된 지식 (Synthesized Content)
-**비즈니스 도메인 모델의 핵심 구성 요소**
-비즈니스 도메인 모델링(도메인 주도 설계, DDD)을 실무에 적용할 때는 아키텍처를 주도하는 상호 연결된 개념들의 집합으로 비즈니스 도메인을 모델링합니다 [2].
-*   **제한된 컨텍스트 (Bounded Contexts):** 크고 복잡한 도메인을 '주문 관리'나 '고객 지원'과 같이 작고 관리하기 쉬운 하위 도메인으로 분할한 것입니다 [2]. 각 컨텍스트는 고유한 모델과 보편적 언어를 가져 모델을 순수하고 집중된 상태로 유지합니다 [2].
-*   **집재체 (Aggregates):** 단일 단위로 취급될 수 있는 도메인 객체들의 클러스터를 의미합니다 [2]. 예를 들어, '주문'은 '주문 명세(OrderLineItem)' 객체를 포함하는 집재체가 될 수 있으며, 집재체의 루트는 클러스터 전체의 일관성을 보장하여 트랜잭션 관리를 단순화합니다 [2].
-*   **엔티티(Entities)와 값 객체(Value Objects):** 비즈니스 개념은 뚜렷한 정체성을 가진 객체인 '엔티티'와 순전히 속성에 의해서만 정의되는 '값 객체'로 구분됩니다 [2]. 고객은 엔티티이고 배송지 주소는 값 객체가 될 수 있습니다 [2]. 특히 엔티티는 핵심 업무 데이터를 기반으로 동작하는 핵심 업무 규칙을 구체화하며, 시스템의 표현 형식이나 데이터 저장 방식과 무관하게 독립적으로 존재해야 합니다 [3-5].
-
-**성공적인 모델링을 위한 실행 전략**
-*   **보편적 언어 (Ubiquitous Language) 확립:** 도메인 전문가와 긴밀히 협력하여 대화, 문서, 나아가 코드 자체에서도 사용되는 용어의 공유 사전을 만들어야 합니다 [1, 6]. 
-*   **도메인 로직의 격리:** 핵심 비즈니스 로직을 데이터베이스나 UI 프레임워크와 같은 인프라 관심사로부터 엄격히 분리해야 합니다 [6]. 이는 클린 아키텍처(Clean Architecture)의 핵심 원칙과도 맞닿아 있으며, 유지보수와 테스트가 용이한 도메인 모델을 생성합니다 [6, 7].
-*   **이벤트 스토밍 (Event Storming) 활용:** 팀이 비즈니스 도메인을 탐색하기 위해 협력적인 워크샵을 진행하며, 이를 통해 도메인 이벤트, 명령 및 집재체를 빠르게 식별하여 모델의 탄탄한 기반을 마련할 수 있습니다 [6].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** AI 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[Domain-Driven Design (DDD)]], [[Bounded Contexts]], [[Ubiquitous Language]], [[Entities]], [[Clean Architecture]]
-- **Projects/Contexts:** [[마이크로서비스 아키텍처 (Microservices Architecture)]] (비즈니스 도메인 역량을 중심으로 세분화된 작고 자율적인 서비스 집합으로 시스템을 구축할 때 주요하게 활용됩니다 [8]), [[복잡한 비즈니스 도메인 프로젝트]] (금융, 의료, 이커머스 등 비즈니스 규칙이 방대하고 복잡한 엔터프라이즈 시스템 구축에 특히 이상적입니다 [9]).
-- **Contradictions/Notes:** 관련 주제 및 구현 방식에 있어서 소스 간 직접적인 모순은 없으나, 도메인 중심 모델링은 심층적인 도메인 분석과 도메인 전문가와의 지속적인 협력이 요구되므로 구현 복잡성(Implementation Complexity)이 매우 높습니다 [9]. 따라서 단순한 시스템보다는 비즈니스 로직이 핵심인 장기적이고 중대한(Mission-critical) 시스템에 적용하는 것이 권장됩니다 [7, 9].
-
----
-*Last updated: 2026-04-18*
-- Raw Source: [[00_Raw/2026-04-20/비즈니스 도메인 모델링 (Business Domain Modeling).md]]
----
diff --git a/AI/빌보드 임포스터(Billboard Impostors).md b/AI/빌보드 임포스터(Billboard Impostors).md
deleted file mode 100644
index 2eba1e4c..00000000
--- a/AI/빌보드 임포스터(Billboard Impostors).md	
+++ /dev/null
@@ -1,32 +0,0 @@
----
-id: P-REINFORCE-AUTO-143607
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - 빌보드 임포스터(Billboard Impostors)"
----
-
-# [[빌보드 임포스터(Billboard Impostors)]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 빌보드 임포스터(Billboard Impostor)는 카메라에서 멀리 떨어진 복잡한 3D 지오메트리를 미리 렌더링된 이미지가 맵핑된 카메라를 향하는 2D 평면(Quad)으로 대체하는 렌더링 최적화 기법입니다 [1]. 모델을 여러 각도(보통 8~16개)에서 캡처한 이미지를 사용하여 3D 객체와 같은 착시를 만들어냅니다 [1]. 렌더링에 필요한 폴리곤 수를 단 2개로 줄여 GPU 리소스 소모를 99.9%까지 감소시키며, 배경 캐릭터나 식생, 먼 거리의 환경 디테일을 표현하는 데 매우 효과적입니다 [1, 2].
-
-## 📖 구조화된 지식 (Synthesized Content)
-*   **작동 원리 및 데이터 구조:** 빌보드 임포스터는 다양한 수평 각도에서 미리 렌더링된 3D 객체의 이미지 뷰(보통 8~16개)를 텍스처 배열이나 플립북 애니메이션 형태로 저장해 둡니다 [1]. 모델이 최대 LOD(Level of Detail) 거리를 초과하면, 시스템은 2개의 폴리곤으로 이루어진 단순한 2D 평면(Quad) 위에 카메라의 현재 시야각과 가장 일치하는 텍스처 뷰를 매칭하여 렌더링합니다 [1].
-*   **성능 최적화 이점:** 멀리 떨어진 객체를 매우 단순한 지오메트리(단일 평면)로 렌더링하여 GPU 자원 소모를 99.9%가량 줄여줍니다 [1, 3]. 자세히 관찰되지 않는 배경 캐릭터, 환경의 세부 장식 요소뿐만 아니라, 주로 실루엣만이 필요한 그림자(Shadows) 생성 시에도 매우 뛰어난 단일 LOD 역할을 수행합니다 [1, 2].
-*   **시각적 한계 및 대안적 접근:** 2D 스프라이트 기반의 임포스터는 시점을 변경할 때 이미지가 튀는 듯한 '팝핑(Popping)' 현상이 매우 두드러지게 나타날 수 있으며, 여러 장의 텍스처를 저장하기 위한 메모리 비용이 발생합니다 [4]. 밀집된 숲과 같은 환경에서 이러한 한계를 극복하기 위해, 여러 평면을 교차시켜 팝핑을 줄인 '카드보드 임포스터(Cardboard Impostors)'나 메모리 비용을 낮추고 시각적 3D 전환이 부드러운 '볼륨 헐 임포스터(Volume Hull Impostors, VHI)' 기술 등이 대안으로 사용되기도 합니다 [4, 5].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** AI 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[Level of Detail (LOD)]], [[Texture Atlas/Array]], [[Draw Call Optimization]]
-- **Projects/Contexts:** [[대규모 3D 환경 렌더링(Large-scale environments)]], [[Three.js 성능 최적화]], [[Tesseract 엔진(Tesseract Engine)]]
-- **Contradictions/Notes:** 소스에 따르면 빌보드 임포스터는 GPU 연산량을 획기적으로 줄여주지만, 다각도의 텍스처를 유지해야 하는 메모리 비용 부담이 따르며 각도 전환 시 시각적인 '팝핑(Popping)' 결함이 발생할 수 있습니다 [4].
-
----
-*Last updated: 2026-04-19*
-- Raw Source: [[00_Raw/2026-04-20/빌보드 임포스터(Billboard Impostors).md]]
----
diff --git a/AI/상태 관리 최적화 (Zustand Jotai Valtio).md b/AI/상태 관리 최적화 (Zustand Jotai Valtio).md
deleted file mode 100644
index b933142b..00000000
--- a/AI/상태 관리 최적화 (Zustand Jotai Valtio).md	
+++ /dev/null
@@ -1,48 +0,0 @@
----
-id: P-REINFORCE-AUTO-5B0AFD
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - 상태 관리 최적화 (Zustand Jotai Valtio)"
----
-
-# [[상태 관리 최적화 (Zustand Jotai Valtio)]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> React의 기본 Context API가 유발하는 불필요한 연쇄 리렌더링 문제를 극복하기 위해, 상태 업데이트 빈도와 아키텍처에 맞춰 각기 다른 철학(Flux, Atomic, Proxy)을 가진 최신 경량 상태 관리 라이브러리를 도입하여 필요한 컴포넌트만 정밀하게 렌더링(Fine-grained reactivity)하는 성능 최적화 기법입니다.
-
-## 📖 구조화된 지식 (Synthesized Content)
-**1. React Context의 성능 병목 한계** React Context는 애플리케이션의 테마나 사용자 정보처럼 가끔 변하는 데이터를 공유하기에는 훌륭하지만, 내부 값 중 하나만 변경되어도 이를 구독하는 전체 컴포넌트 트리가 리렌더링되는 폭포수(Cascading) 현상을 유발합니다. 고빈도 업데이트가 필요한 실시간 대시보드나 게임 등에서는 이러한 Context를 분할하거나, Zustand, Jotai, Valtio 같은 최적화된 대안 상태 관리 라이브러리로 대체해야 합니다.
-
-**2. Zustand (단순화된 Flux 패턴)** 보일러플레이트를 최소화한 약 1.1KB 크기의 경량 중앙 집중식 스토어입니다.
-
-- **특징 및 최적화:** 컴포넌트는 `useStore(state => state.value)`와 같은 선택적 구독(Selector) 패턴을 통해 자신이 필요한 상태가 변할 때만 리렌더링되도록 제어할 수 있습니다.
-- **주의사항:** Zustand는 기본적으로 얕은 비교(Shallow equality)를 수행하므로, 셀렉터 내부에서 `filter`나 `map`을 통해 매 렌더링마다 새로운 배열이나 객체를 반환하게 하면 최적화가 무력화되어 전체 리렌더링이 발생합니다. 따라서 셀렉터를 분할하여 사용하는 수동 최적화가 중요합니다.
-
-**3. Jotai (원자적 상태 구성)** 상태를 가장 작은 독립 단위인 '아톰(Atom)'으로 분해하여 관리하는 상향식(Bottom-up) 모델입니다.
-
-- **특징 및 최적화:** 파생된 아톰(Derived atom)들은 종속성이 변경될 때 자동으로 재계산되며, 컴포넌트는 자신이 읽는 아톰이 변경될 때만 리렌더링됩니다. Zustand처럼 수동으로 셀렉터를 최적화할 필요 없이 자동 최적화가 이루어지므로 미세 조정이 매우 뛰어납니다.
-- **활용:** 다중 사용자가 다른 부분을 수정하는 실시간 협업 에디터와 같이 복잡한 파생 상태 및 실시간 업데이트가 잦은 앱에 가장 탁월합니다. 번들 크기는 약 2.9KB입니다.
-
-**4. Valtio (Proxy 기반 가변 상태)** ES6 Proxy를 활용하여 개발자가 일반 객체를 다루듯 상태를 직접 변형(Mutation)하면, 라이브러리 내부에서 이를 추적해 불변(Immutable) 상태 업데이트로 변환해 주는 방식입니다.
-
-- **특징 및 최적화:** 컴포넌트가 렌더링 중 어떤 속성(Property)에 접근했는지를 프록시가 자동으로 추적하여, 정확히 해당 속성이 변경될 때만 리렌더링을 발생시킵니다. 깊게 중첩된 객체를 업데이트할 때 전개 연산자(Spread operator)를 쓸 필요가 없어 보일러플레이트가 크게 줄어듭니다.
-- **활용:** 복잡한 설정 패널, 깊은 중첩 상태, 잦은 작은 업데이트가 필요한 게임 상태 관리에 최적화되어 있습니다. 번들 크기는 약 3.5KB입니다.
-
-**5. 하이브리드 아키텍처 전략** 복잡한 프로덕션 앱(예: 대규모 게임 엔진)에서는 반드시 하나의 상태 관리 도구만 고집할 필요가 없습니다. 예를 들어, 사용자의 점수, 게임 스테이지 같은 '저빈도 전역 상태'는 Zustand로 관리하고, 물리 엔진과 연동되어 매 프레임 좌표가 변하는 3D 엔티티들의 '고빈도 세부 상태'는 Valtio를 통해 렌더링을 제어하는 식으로 각 도구의 장점을 살린 아키텍처 역할 분담이 권장됩니다.
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** AI 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[불필요한 리렌더링 방지]], [[React Context API 한계]], [[React Performance Optimization]], [[가변 프록시(Mutable Proxy) 상태]]
-- **Projects/Contexts:** [[장기 실행되는 실시간 데이터 대시보드 최적화]], [[고성능 실시간 상호작용 시스템을 위한 React 기반 게임 엔진 아키텍처]]
-- **Contradictions/Notes:** 많은 개발자들이 Zustand를 도입하기만 하면 성능이 좋아질 것이라 오해하지만, 컴포넌트에서 전체 상태를 가져오거나 셀렉터에서 파생 객체를 무분별하게 반환하면 오히려 성능이 악화될 수 있습니다. 최적의 성능을 위해서는 사용 패턴에 대한 정확한 이해(수동 셀렉터 분리)가 동반되어야 합니다.
-
----
-
-_Last updated: 2026-04-15_
-- Raw Source: [[00_Raw/2026-04-20/상태 관리 최적화 (Zustand, Jotai, Valtio).md]]
----
diff --git a/AI/서플라이 체인 보안 (Supply Chain Security).md b/AI/서플라이 체인 보안 (Supply Chain Security).md
deleted file mode 100644
index 022b0dfe..00000000
--- a/AI/서플라이 체인 보안 (Supply Chain Security).md	
+++ /dev/null
@@ -1,39 +0,0 @@
----
-id: P-REINFORCE-AUTO-E85988
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - 서플라이 체인 보안 (Supply Chain Security)"
----
-
-# [[서플라이 체인 보안 (Supply Chain Security)]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 서플라이 체인 보안(Supply Chain Security)은 소프트웨어 공급망, 특히 애플리케이션에 통합되는 오픈소스 종속성 및 서드파티 컴포넌트와 관련된 위험을 완화하는 데 중점을 두는 보안 영역입니다 [1, 2]. 이는 합법적인 패키지가 손상되거나 메인테이너 계정이 탈취되어 악성 코드가 배포되는 공급망 공격으로부터 소프트웨어 개발 파이프라인을 보호하는 과정을 포함합니다 [3-5]. 이러한 공급망 위험을 관리하고 라이선스 정책 등을 강제하기 위해 SCA(소프트웨어 구성 분석) 도구와 SBOM(소프트웨어 자재 명세서) 활용이 필수적입니다 [1, 2].
-
-## 📖 구조화된 지식 (Synthesized Content)
-* **공급망 공격의 본질 및 위협**
-  최근의 오픈소스 공급망 공격은 주로 시스템 내의 비밀 정보(secrets)를 유출하는 데 초점을 맞추고 있습니다 [6]. 대부분의 오픈소스 파이프라인은 '신뢰'를 기반으로 작동하기 때문에 공격자들은 피싱 등을 통해 메인테이너의 계정(예: npm 토큰)을 탈취하는 방식을 사용합니다 [4, 7]. 메인테이너 한 명의 계정이 손상되더라도 인기 있는 패키지의 악성 버전이 게시되어 수천만 건의 다운스트림 설치에 연쇄적인 피해를 줄 수 있습니다 [4].
-
-* **주요 공급망 공격 사례**
-  대표적인 사례로 `eslint-config-prettier` 패키지의 손상(CVE-2025-54313)이 있습니다. 공격자는 탈취한 토큰을 통해 악성 설치 스크립트(`install.js`)를 삽입하여 Windows 개발자 머신이나 CI 호스트를 표적으로 삼고 원격 코드 실행(RCE)을 시도했습니다 [3, 7, 8]. 또한, `tj-actions/changed-files` GitHub Action을 표적으로 삼아 합법적인 오픈소스 패키지를 손상시킨 공급망 공격 사례도 보고되었습니다 [5].
-
-* **위험 완화 및 방어 전략**
-  * **메인테이너 보안 강화:** 메인테이너의 보안이 곧 서플라이 체인 보안의 핵심입니다. 이를 위해 다중 인증(MFA) 적용, 권한이 제한된 토큰(scoped tokens) 사용, 엄격한 패키지 게시 관행의 도입이 필요합니다 [4].
-  * **보안 도구 및 인벤토리 관리:** 서드파티 및 오픈소스 종속성을 대량으로 사용하는 환경에서는 알려진 취약점을 찾아내는 SCA(Software Composition Analysis) 도구를 통해 위험을 관리해야 합니다 [2]. 또한 SBOM(Software Bill of Materials)을 생성하여 소프트웨어 인벤토리를 명확히 하고 종속성 위험을 모니터링해야 합니다 [1].
-  * **침해 발생 시 대응:** 손상된 패키지가 발견되면 해당 버전의 설치를 피하고 안전한 버전으로 종속성을 고정(pinning)해야 합니다 [9]. 아울러 `package-lock.json`이나 `yarn.lock` 파일을 검토하고, CI/CD 파이프라인의 이상 징후를 감사하며, 빌드 과정에서 노출되었을 가능성이 있는 모든 비밀 정보(secrets)를 즉시 교체해야 합니다 [9].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** AI 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[Software Composition Analysis (SCA)]], [[SBOM (Software Bill of Materials)]], [[오픈소스 보안]]
-- **Projects/Contexts:** [[CVE-2025-54313 (`eslint-config-prettier` 공격)]], [[`tj-actions/changed-files` 공격]]
-- **Contradictions/Notes:** 소스에 따르면 오픈소스 생태계는 '신뢰'에 극도로 의존하여 운영되고 있으나, 바로 이러한 신뢰 모델 때문에 한 명의 개발자 계정에 대한 피싱 공격이 거대한 소프트웨어 서플라이 체인 전체를 위험에 빠뜨리는 구조적 취약점이 됨을 경고하고 있습니다 [4].
-
----
-*Last updated: 2026-04-18*
-- Raw Source: [[00_Raw/2026-04-20/서플라이 체인 보안 (Supply Chain Security).md]]
----
diff --git a/AI/소프트웨어 개발 수명 주기 (SDLC).md b/AI/소프트웨어 개발 수명 주기 (SDLC).md
deleted file mode 100644
index 00ebed66..00000000
--- a/AI/소프트웨어 개발 수명 주기 (SDLC).md	
+++ /dev/null
@@ -1,33 +0,0 @@
----
-id: P-REINFORCE-AUTO-C931C8
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - 소프트웨어 개발 수명 주기 (SDLC)"
----
-
-# [[소프트웨어 개발 수명 주기 (SDLC)]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 소프트웨어 개발 수명 주기(SDLC)는 소프트웨어를 개발하고 유지보수하는 전체 과정을 의미합니다. 현대의 SDLC는 정적 분석(SAST)과 AI 도구를 초기 단계부터 통합하여 취약점을 조기에 발견하고 수정하는 '시프트 레프트(Shift-Left)' 접근법을 강조합니다 [1-3]. 이를 통해 조직은 개발 수명 주기 내내 AI가 생성한 코드를 포함한 모든 소프트웨어의 보안, 유지보수성, 품질을 효율적으로 관리할 수 있습니다 [1, 4, 5].
-
-## 📖 구조화된 지식 (Synthesized Content)
-- **초기 결함 탐지 및 시프트 레프트(Shift-Left):** SDLC의 초기 단계(예: 풀 리퀘스트 워크플로우)에 정적 코드 분석(SAST) 및 실시간 검사를 통합하면 보안 취약점, 유지보수 문제, 논리적 결함을 조기에 발견할 수 있습니다 [1]. 이는 개발 프로세스 초기에 취약점을 감지하고 수정하는 DevSecOps의 핵심 원칙인 '시프트 레프트' 접근 방식을 의미합니다 [3].
-- **지속적인 모니터링 및 품질 게이트 적용:** 안전한 SDLC(SSDLC)를 위해서는 개발 주기 초기에 스캔을 시작하여 보안 기준선을 설정해야 합니다 [2, 6]. 이후 SDLC의 다양한 단계 전반에 걸쳐 코드를 자주 스캔하여 새롭게 발생하는 보안 문제를 지속적으로 포착하는 것이 모범 사례로 권장됩니다 [6]. 또한 SDLC 전반에 걸쳐 동기화된 품질 게이트(Quality Gates)를 적용하면 대규모 개발 환경에서도 고품질의 안전한 코드 배포를 유지할 수 있습니다 [4].
-- **AI 도구의 통합:** AI 도구들은 점차 SDLC에서 필수 불가결한 요소로 자리 잡고 있습니다 [5]. AI 기반 코드 검사기를 활용하면 개발자는 동료 코드 리뷰 등에서 놓칠 수 있는 복잡한 코드 문제나 보안 위험을 SDLC 초기에 더 빠르고 정확하게 식별 및 해결할 수 있습니다 [2].
-- **SDLC 거버넌스:** 조직은 AI 생성 코드와 기존 개발자 표준을 일치시키기 위해 SDLC 거버넌스를 확립해야 합니다 [7]. 규정 준수를 자동화하고 정책 기반의 품질 게이트를 적용함으로써 소프트웨어 품질 보증 과정을 강화할 수 있습니다 [7, 8].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** AI 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[시프트 레프트 (Shift-Left)]], [[정적 애플리케이션 보안 테스트 (SAST)]], [[DevSecOps]]
-- **Projects/Contexts:** [[AI 코드 리뷰]], [[풀 리퀘스트 워크플로우]]
-- **Contradictions/Notes:** 소스 간의 명백한 모순은 존재하지 않으며, 모든 소스가 공통적으로 SDLC 전반(특히 초기 단계)에 걸친 보안 스캔 자동화 및 AI 도구 도입의 중요성을 일관되게 강조하고 있습니다.
-
----
-*Last updated: 2026-04-18*
-- Raw Source: [[00_Raw/2026-04-20/소프트웨어 개발 수명 주기 (SDLC).md]]
----
diff --git a/AI/스캐빈저(Scavenger).md b/AI/스캐빈저(Scavenger).md
deleted file mode 100644
index 528b00bb..00000000
--- a/AI/스캐빈저(Scavenger).md
+++ /dev/null
@@ -1,30 +0,0 @@
----
-id: P-REINFORCE-AUTO-07787D
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - 스캐빈저(Scavenger)"
----
-
-# [[스캐빈저(Scavenger)]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 스캐빈저(Scavenger)는 V8 및 기타 가상 머신에서 새롭게 생성된 수명이 짧은 객체들이 모여 있는 '새로운 공간(New Space 또는 Nursery)'의 메모리를 회수하기 위해 작동하는 마이너 가비지 컬렉션(Minor GC) 메커니즘입니다 [1-3]. 새로운 객체를 위한 공간을 할당하다가 한계에 도달하여 '할당 실패(Allocation failure)'가 발생했을 때 빠르게 실행됩니다 [3, 4]. 살아남은 객체만을 다른 메모리 영역으로 복사하여 단편화를 없애며, 이 과정을 반복하여 오래 살아남은 객체를 기존 세대(Old Generation)로 승격(Promotion)시킵니다 [5, 6].
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** AI 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[마이너 가비지 컬렉션(Minor GC)]], [[New Space(Young Generation)]], [[할당 실패(Allocation Failure)]], [[Old Space(Old Generation)]], [[메모리 단편화(Fragmentation)]]
-- **Projects/Contexts:** [[V8 엔진 힙 아키텍처]], [[Orinoco 가비지 컬렉터]], [[브라우저 및 Node.js 메모리 튜닝]]
-- **Contradictions/Notes:** 스캐빈저 알고리즘은 빠른 메모리 할당 및 단편화 제거에 매우 효율적이지만, `To-Space`와 `From-Space` 두 영역의 물리적 메모리를 모두 확보해야 하므로 공간 오버헤드가 크다는 단점이 있습니다 [9, 22]. 따라서 몇 메가바이트 이상의 큰 용량을 관리하는 데에는 비실용적이며, 이를 극복하기 위해 크기가 큰 Old Space에서는 Mark-Sweep 및 Mark-Compact 알고리즘을 혼용합니다 [22, 23].
-
----
-*Last updated: 2026-04-19*
-- Raw Source: [[00_Raw/2026-04-20/스캐빈저(Scavenger).md]]
----
diff --git a/AI/시뮬레이터 멀미 설문지(SSQ).md b/AI/시뮬레이터 멀미 설문지(SSQ).md
deleted file mode 100644
index 1ca69b6a..00000000
--- a/AI/시뮬레이터 멀미 설문지(SSQ).md	
+++ /dev/null
@@ -1,42 +0,0 @@
----
-id: P-REINFORCE-AUTO-30F8D3
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - 시뮬레이터 멀미 설문지(SSQ)"
----
-
-# [[시뮬레이터 멀미 설문지(SSQ)]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 시뮬레이터 멀미 설문지(SSQ, Simulator Sickness Questionnaire)는 가상현실(VR) 기기나 시뮬레이터 사용 시 나타나는 멀미 증상과 부작용을 측정하기 위해 널리 사용되는 주관적 자기 보고식 평가 도구입니다 [1]. 16개의 증상 항목에 대해 0점(없음)부터 3점(심각함)까지의 4점 척도로 응답하도록 구성되어 있습니다 [1]. 수집된 점수는 메스꺼움, 안구운동, 방향 감각 상실이라는 세 가지 주요 하위 범주로 분류되어 사용자의 멀미 심각도를 정량화합니다 [1].
-
-## 📖 구조화된 지식 (Synthesized Content)
-- **평가 항목 및 하위 범주:** SSQ는 총 16개의 증상 목록을 기반으로 하며, 증상의 군집은 크게 세 가지 하위 범주로 나뉩니다 [1].
-  - **메스꺼움(Nausea):** 타액 분비 증가, 트림, 위장 인식 등 위장의 불쾌감과 관련된 7가지 증상을 포함합니다 [1].
-  - **안구운동(Oculomotor):** 눈의 피로, 전반적인 피로감, 초점 저하 등과 관련된 7가지 증상으로 구성됩니다 [1].
-  - **방향 감각 상실(Disorientation):** 현기증 및 어지럼증과 관련된 7가지 증상을 포함합니다 [1].
-  - 세 가지 하위 척도에는 서로 겹치는 증상 항목들이 존재하며, 최종 총점과 하위 척도 점수를 산출할 때 원점수(raw scores)에 각기 다른 가중치가 적용됩니다 [1].
-
-- **점수의 해석 및 멀미 수준 분류:** 
-  - 가중치가 적용된 SSQ 총점은 증상의 심각도에 따라 '낮음(0-10)', '중간(10 초과 20 이하)', '높음(20 초과)'의 세 가지 수준으로 분류할 수 있습니다 [2]. 
-  - 특히 20점을 초과하는 높은 점수는 해당 시뮬레이터(또는 VR 콘텐츠)가 사용자에게 문제를 일으키는 '문제 시뮬레이터(problem simulator)'임을 나타내는 주요 지표로 활용됩니다 [3].
-
-- **학술적 활용 및 한계점:** 
-  - SSQ는 VR이나 시뮬레이터 환경 노출 기간에 따른 가상현실 멀미(VR sickness)의 악화 및 회복 시간을 평가하는 데 자주 사용됩니다 [4, 5]. 
-  - 다만, 높은 SSQ 점수가 현실 세계에서의 일상적인 행동 성과 저하(예: 운전 등 사고 위험이 있는 활동)와 어떻게 실질적으로 연결되는지에 대해서는 아직 명확히 규명되지 않은 지식적 공백이 남아있습니다 [3, 6].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** AI 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[가상현실 멀미(VR sickness)]], [[사후 영향(Aftereffects)]]
-- **Projects/Contexts:** [[비트 세이버(Beat Saber)를 활용한 가상현실 엑서게이밍 사후 영향 연구]]
-- **Contradictions/Notes:** 소스에 관련 정보가 부족합니다.
-
----
-*Last updated: 2026-04-19*
-- Raw Source: [[00_Raw/2026-04-20/시뮬레이터 멀미 설문지(SSQ).md]]
----
diff --git a/AI/시뮬레이터 멀미 설문지(Simulator Sickness Questionnaire).md b/AI/시뮬레이터 멀미 설문지(Simulator Sickness Questionnaire).md
deleted file mode 100644
index 6df792ac..00000000
--- a/AI/시뮬레이터 멀미 설문지(Simulator Sickness Questionnaire).md	
+++ /dev/null
@@ -1,36 +0,0 @@
----
-id: P-REINFORCE-AUTO-C8E657
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - 시뮬레이터 멀미 설문지(Simulator Sickness Questionnaire)"
----
-
-# [[시뮬레이터 멀미 설문지(Simulator Sickness Questionnaire)]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 시뮬레이터 멀미 설문지(SSQ)는 시뮬레이터 및 가상현실(VR) 연구에서 멀미 증상을 정량화하기 위해 가장 널리 사용되는 평가 도구입니다 [1]. 이 설문지는 총 16개의 증상 항목을 0점(없음)부터 3점(심각함)까지의 4점 척도로 평가합니다 [1]. 수집된 데이터는 메스꺼움, 안구 운동, 방향 상실이라는 세 가지 주요 하위 범주로 분류되어 사용자의 신체적, 인지적 불편함을 측정합니다 [1].
-
-## 📖 구조화된 지식 (Synthesized Content)
-- **구조 및 평가 체계:** SSQ는 사용자의 주관적인 증상을 측정하며 16개의 증상 목록을 사용합니다 [1]. 원점수(Raw scores)는 단순 합산이 아니라, 전체 점수(Total scores)와 각 하위 척도(Subscales)에 대해 다르게 가중치가 부여되어 최종 점수가 계산됩니다 [1].
-- **세 가지 하위 범주(Subscales):** 각 하위 척도에는 다른 하위 척도와 일부 중복되는 증상들이 포함되어 있습니다 [1].
-  - **메스꺼움(Nausea):** 타액 분비 증가, 트림, 위장 인식 등 위장 불쾌감과 관련된 7가지 증상으로 구성됩니다 [1].
-  - **안구 운동(Oculomotor):** 눈의 피로감, 전반적인 피로, 초점 문제와 관련된 7가지 증상으로 구성됩니다 [1].
-  - **방향 상실(Disorientation):** 현기증(dizziness) 및 어지러움(vertigo)과 관련된 7가지 증상을 포함합니다 [1].
-- **점수 해석 및 활용의 한계:** 과거 연구에서는 SSQ 점수가 20점을 초과할 경우 해당 시뮬레이터에 문제가 있다는 지표로 제안되었습니다 [2]. 하지만 이렇게 높게 측정된 SSQ 점수가 사용자의 일상 활동이나 실제 현실에서의 수행 능력 저하에 어떠한 영향을 미치는지는 아직 명확히 밝혀지지 않았으며, 이는 해당 분야의 중요한 지식적 공백으로 남아 있습니다 [2].
-- **가상현실(VR) 노출과의 관계:** SSQ 점수는 가상현실 환경에서의 노출 시간(exposure duration) 및 시뮬레이션 된 움직임(simulated motion)이 증가할수록 함께 높아지는 경향을 보입니다 [3]. 또한, 대형 화면을 통해 시청할 때보다 헤드마운트 디스플레이(HMD)를 사용할 때 SSQ 점수가 상당히 더 높게 나타납니다 [3].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** AI 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[가상현실 멀미(VR Sickness)]], [[가상현실(Virtual Reality)]]
-- **Projects/Contexts:** [[Beat Saber VR 엑서게임 연구]]
-- **Contradictions/Notes:** 소스에 따르면 높은 SSQ 점수(20점 초과)는 시뮬레이터의 문제를 시사하는 것으로 제안되지만, 정작 이 높은 점수가 사용자의 실제 일상생활 및 수행 능력 저하와 어떻게 연결되는지는 명확히 규명되지 않은 채로 남아 있습니다 [2]. 
-
----
-*Last updated: 2026-04-19*
-- Raw Source: [[00_Raw/2026-04-20/시뮬레이터 멀미 설문지(Simulator Sickness Questionnaire).md]]
----
diff --git a/AI/애그리거트 (Aggregates).md b/AI/애그리거트 (Aggregates).md
deleted file mode 100644
index 53abda71..00000000
--- a/AI/애그리거트 (Aggregates).md	
+++ /dev/null
@@ -1,32 +0,0 @@
----
-id: P-REINFORCE-AUTO-8D448D
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - 애그리거트 (Aggregates)"
----
-
-# [[애그리거트 (Aggregates)]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 애그리거트(Aggregates)는 도메인 주도 설계(Domain-Driven Design, DDD)에서 단일 단위로 취급될 수 있는 도메인 객체들의 군집을 의미합니다 [1]. 비즈니스 도메인을 모델링할 때 트랜잭션 관리를 단순화하고, 해당 군집 내 객체들의 일관성을 보장하는 핵심적인 역할을 수행합니다 [1].
-
-## 📖 구조화된 지식 (Synthesized Content)
-- **단일 단위로서의 도메인 객체 군집:** 애그리거트는 여러 도메인 객체들을 하나의 클러스터로 묶어 단일 유닛으로 다룰 수 있게 해줍니다 [1]. 대표적인 예로, '주문(Order)'이라는 애그리거트 내부에 여러 개의 '주문 항목(OrderLineItem)' 객체들이 포함되는 구조를 들 수 있습니다 [1].
-- **일관성 유지 및 트랜잭션 관리 단순화:** 애그리거트의 루트(root)는 해당 클러스터 전체의 일관성을 보장하는 역할을 책임집니다 [1]. 이러한 구조적 특징 덕분에 시스템 내에서 트랜잭션 관리가 크게 단순해집니다 [1].
-- **이벤트 스토밍(Event Storming)을 통한 식별:** 팀원들과 도메인 전문가가 함께 참여하는 협업 워크숍인 이벤트 스토밍 기법을 활용하면 비즈니스 도메인을 효과적으로 탐색할 수 있습니다 [2]. 이 과정을 통해 도메인 이벤트(domain events), 명령(commands)과 함께 애그리거트를 빠르게 식별할 수 있으며, 이는 소프트웨어 모델을 위한 탄탄한 기반을 제공합니다 [2].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** AI 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[Domain-Driven Design (DDD)]], [[Event Storming]], [[Domain Objects]]
-- **Projects/Contexts:** [[비즈니스 도메인 모델링 (Business Domain Modeling)]]
-- **Contradictions/Notes:** 소스에 관련 정보가 제한적이며, 애그리거트의 구체적인 구현 방식이나 상반된 주장에 대한 정보는 소스에 부족합니다.
-
----
-*Last updated: 2026-04-18*
-- Raw Source: [[00_Raw/2026-04-20/애그리거트 (Aggregates).md]]
----
diff --git a/AI/양자화 (Quantization).md b/AI/양자화 (Quantization).md
deleted file mode 100644
index f41cfe22..00000000
--- a/AI/양자화 (Quantization).md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-7321F3
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - 양자화 (Quantization)"
----
-
-# [[양자화 (Quantization)]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** AI 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/양자화 (Quantization).md]]
----
diff --git a/AI/에듀테크 기반 게이미피케이션 전략.md b/AI/에듀테크 기반 게이미피케이션 전략.md
deleted file mode 100644
index ecf1f266..00000000
--- a/AI/에듀테크 기반 게이미피케이션 전략.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-4FA22A
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - 에듀테크 기반 게이미피케이션 전략"
----
-
-# [[에듀테크 기반 게이미피케이션 전략]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** AI 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/에듀테크 기반 게이미피케이션 전략.md]]
----
diff --git a/AI/연합 학습 (Associative Learning).md b/AI/연합 학습 (Associative Learning).md
deleted file mode 100644
index 7eb360ed..00000000
--- a/AI/연합 학습 (Associative Learning).md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-0E1EE5
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - 연합 학습 (Associative Learning)"
----
-
-# [[연합 학습 (Associative Learning)]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** AI 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/연합 학습 (Associative Learning).md]]
----
diff --git a/AI/오사카 엑스포 2025 호쿠사이 인스톨레이션(Hokusai installation).md b/AI/오사카 엑스포 2025 호쿠사이 인스톨레이션(Hokusai installation).md
deleted file mode 100644
index a571018a..00000000
--- a/AI/오사카 엑스포 2025 호쿠사이 인스톨레이션(Hokusai installation).md	
+++ /dev/null
@@ -1,32 +0,0 @@
----
-id: P-REINFORCE-AUTO-6697EE
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - 오사카 엑스포 2025 호쿠사이 인스톨레이션(Hokusai installation)"
----
-
-# [[오사카 엑스포 2025 호쿠사이 인스톨레이션(Hokusai installation)]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 오사카 엑스포 2025 호쿠사이 인스톨레이션(Hokusai installation)은 인터랙티브 크리에이티브 스튜디오인 Utsubo가 2025년 오사카 엑스포를 위해 제작한 대규모 유체 시뮬레이션 프로젝트입니다 [1]. 이 인스톨레이션은 Three.js의 WebGPU 렌더러를 적극 활용하여 기존의 한계를 뛰어넘는 100만 개 단위의 파티클을 실시간으로 렌더링하는 그래픽 성능을 입증했습니다 [1]. 98인치 4K 디스플레이 상에서 지연 없는 실시간 다인원 신체 추적(multi-person body tracking) 기능과 결합되어, WebGPU 마이그레이션을 통한 성공적인 프로덕션 벤치마크 사례로 평가받고 있습니다 [2, 3].
-
-## 📖 구조화된 지식 (Synthesized Content)
-- **제작사 및 개발 배경:** 이 프로젝트는 브랜드 웹사이트 및 물리적 인스톨레이션을 전문으로 하는 기술 중심 크리에이티브 스튜디오 'Utsubo'에 의해 2025년 오사카 엑스포를 겨냥하여 구축되었습니다 [1]. 
-- **WebGPU를 통한 파티클 시뮬레이션 구현:** 이 인스톨레이션의 가장 큰 기술적 성과는 Three.js WebGPU 렌더러를 기반으로 100만 개(1M) 규모의 파티클 유체 시뮬레이션(particle fluid simulation)을 실시간으로 구현해 냈다는 점입니다 [1]. 이는 무거운 드로우 콜이나 복잡한 연산이 필요한 환경에서 WebGPU가 제공하는 2~10배의 실질적인 성능 향상을 입증하는 사례입니다 [2].
-- **디스플레이 및 사용자 상호작용:** 오사카 엑스포 현장에 설치된 98인치 4K 디스플레이를 통해 구동되었으며, 사용자 참여를 위해 다수의 사람을 동시에 인식하는 '다인원 신체 추적(multi-person body tracking)' 기술이 적용되었습니다 [3]. 수많은 파티클 연산에도 불구하고 체감할 수 있는 지연 현상(lag) 없이 매끄럽게 렌더링되는 성능을 보여주었습니다 [3].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** AI 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[WebGPU]], [[Three.js]], [[Particle Fluid Simulation]]
-- **Projects/Contexts:** [[Utsubo]], [[Expo 2025 Osaka]], [[Waves of Connection]]
-- **Contradictions/Notes:** 소스 문서 내에서 오사카 엑스포 2025의 '호쿠사이 인스톨레이션(Hokusai installation)'과 'Waves of Connection' 인스톨레이션은 모두 100만 개의 파티클을 실시간 렌더링한 Utsubo 스튜디오의 동일하거나 밀접하게 연관된 WebGPU 프로덕션 사례로 교차 언급되고 있습니다 [1, 3].
-
----
-*Last updated: 2026-04-19*
-- Raw Source: [[00_Raw/2026-04-20/오사카 엑스포 2025 호쿠사이 인스톨레이션(Hokusai installation).md]]
----
diff --git a/AI/온톨로지 (Ontology).md b/AI/온톨로지 (Ontology).md
deleted file mode 100644
index 30f18cbc..00000000
--- a/AI/온톨로지 (Ontology).md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-25F9C5
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - 온톨로지 (Ontology)"
----
-
-# [[온톨로지 (Ontology)]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** AI 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/온톨로지 (Ontology).md]]
----
diff --git a/AI/온톨로지 지식 베이스.md b/AI/온톨로지 지식 베이스.md
deleted file mode 100644
index ffc14201..00000000
--- a/AI/온톨로지 지식 베이스.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-A3EA4F
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - 온톨로지 지식 베이스"
----
-
-# [[온톨로지 지식 베이스]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** AI 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/온톨로지 지식 베이스.md]]
----
diff --git a/AI/유비쿼터스 언어 (Ubiquitous Language).md b/AI/유비쿼터스 언어 (Ubiquitous Language).md
deleted file mode 100644
index 78dee10f..00000000
--- a/AI/유비쿼터스 언어 (Ubiquitous Language).md	
+++ /dev/null
@@ -1,32 +0,0 @@
----
-id: P-REINFORCE-AUTO-34F79B
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - 유비쿼터스 언어 (Ubiquitous Language)"
----
-
-# [[유비쿼터스 언어 (Ubiquitous Language)]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 유비쿼터스 언어(Ubiquitous Language)는 소프트웨어 개발 프로젝트의 복잡성을 해결하기 위해 프로젝트에 참여하는 모든 사람이 공통으로 사용하는 공유 언어입니다 [1]. 이는 개발자와 비즈니스 이해관계자(도메인 전문가) 간의 의사소통 격차를 해소하여, 개발된 소프트웨어가 비즈니스의 올바른 문제를 해결할 수 있도록 보장하는 역할을 합니다 [1].
-
-## 📖 구조화된 지식 (Synthesized Content)
-- **도메인 주도 설계(DDD)의 핵심:** 유비쿼터스 언어는 비즈니스 도메인에 대한 깊은 이해를 중심으로 하는 도메인 주도 설계([[Domain-Driven Design (DDD)]]) 접근 방식의 주요 목표 중 하나입니다 [1].
-- **생성 및 적용 범위:** 기술 팀은 도메인 전문가와 긴밀하게 협력하여 용어의 공유집(shared glossary)을 생성하고 유지 관리해야 합니다 [2]. 이렇게 정의된 유비쿼터스 언어는 일상적인 대화, 문서화는 물론 실제 작성되는 코드 자체에도 일관되게 사용되어야 합니다 [2].
-- **제한된 컨텍스트(Bounded Contexts) 내의 언어:** 크고 복잡한 도메인은 더 작고 관리하기 쉬운 하위 도메인인 '바운디드 컨텍스트(Bounded Contexts)'로 나뉩니다 [3]. "주문 관리"나 "고객 지원"과 같은 각 컨텍스트는 고유한 모델과 유비쿼터스 언어를 가지며, 이를 통해 시스템 모델을 순수하고 명확하게 집중된 상태로 유지할 수 있습니다 [3].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** AI 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[Domain-Driven Design (DDD)]], [[Bounded Contexts]]
-- **Projects/Contexts:** [[소프트웨어 아키텍처 설계]]
-- **Contradictions/Notes:** 소스 내에 유비쿼터스 언어와 관련하여 대립하거나 상충하는 정보는 없습니다. 
-
----
-*Last updated: 2026-04-18*
-- Raw Source: [[00_Raw/2026-04-20/유비쿼터스 언어 (Ubiquitous Language).md]]
----
diff --git a/AI/인간-컴퓨터 상호작용 (HCI).md b/AI/인간-컴퓨터 상호작용 (HCI).md
deleted file mode 100644
index 2b03a807..00000000
--- a/AI/인간-컴퓨터 상호작용 (HCI).md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-5A206B
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - 인간-컴퓨터 상호작용 (HCI)"
----
-
-# [[인간-컴퓨터 상호작용 (HCI)]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** AI 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/인간-컴퓨터 상호작용 (HCI).md]]
----
diff --git a/AI/인공지능 상호작용 (HAI).md b/AI/인공지능 상호작용 (HAI).md
deleted file mode 100644
index bc8e714d..00000000
--- a/AI/인공지능 상호작용 (HAI).md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-BA3F26
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - 인공지능 상호작용 (HAI)"
----
-
-# [[인공지능 상호작용 (HAI)]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** AI 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/인공지능 상호작용 (HAI).md]]
----
diff --git a/AI/인적 자원 관리(HRM) 전략 수립.md b/AI/인적 자원 관리(HRM) 전략 수립.md
deleted file mode 100644
index d22c43d7..00000000
--- a/AI/인적 자원 관리(HRM) 전략 수립.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-AD8C86
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - 인적 자원 관리(HRM) 전략 수립"
----
-
-# [[인적 자원 관리(HRM) 전략 수립]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** AI 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/인적 자원 관리(HRM) 전략 수립.md]]
----
diff --git a/AI/인지 행동 치료 (CBT).md b/AI/인지 행동 치료 (CBT).md
deleted file mode 100644
index beb72a87..00000000
--- a/AI/인지 행동 치료 (CBT).md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-A19886
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - 인지 행동 치료 (CBT)"
----
-
-# [[인지 행동 치료 (CBT)]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** AI 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/인지 행동 치료 (CBT).md]]
----
diff --git a/AI/인지행동치료(CBT).md b/AI/인지행동치료(CBT).md
deleted file mode 100644
index e26dad98..00000000
--- a/AI/인지행동치료(CBT).md
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-624537
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - 인지행동치료(CBT)"
----
-
-# [[인지행동치료(CBT)]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** AI 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/인지행동치료(CBT).md]]
----
diff --git a/AI/인터랙티브 스토리텔링 연구.md b/AI/인터랙티브 스토리텔링 연구.md
deleted file mode 100644
index 84b317f7..00000000
--- a/AI/인터랙티브 스토리텔링 연구.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-5DBDA2
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - 인터랙티브 스토리텔링 연구"
----
-
-# [[인터랙티브 스토리텔링 연구]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** AI 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/인터랙티브 스토리텔링 연구.md]]
----
diff --git a/AI/정적 애플리케이션 보안 테스트 (SAST).md b/AI/정적 애플리케이션 보안 테스트 (SAST).md
deleted file mode 100644
index a68df355..00000000
--- a/AI/정적 애플리케이션 보안 테스트 (SAST).md	
+++ /dev/null
@@ -1,34 +0,0 @@
----
-id: P-REINFORCE-AUTO-517F55
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - 정적 애플리케이션 보안 테스트 (SAST)"
----
-
-# [[정적 애플리케이션 보안 테스트 (SAST)]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> SAST(정적 애플리케이션 보안 테스트)는 애플리케이션의 소스 코드나 바이트코드를 실행하기 전에 정적으로 분석하여 잠재적인 보안 취약점을 식별하는 화이트박스 테스트 기법이다 [1]. 개발 수명 주기(SDLC) 초기에 취약점을 발견하여 수정 비용과 시간을 대폭 절감하게 해주는 '시프트 레프트(Shift-Left)' 보안 전략의 핵심 도구이다 [1, 2]. 최근에는 단순한 규칙 기반 패턴 매칭의 한계를 극복하기 위해 인공지능(AI)과 머신러닝 모델을 통합하여, 코드의 문맥과 의미를 이해하고 수정안까지 자동으로 제안하는 방향으로 진화하고 있다 [3, 4].
-
-## 📖 구조화된 지식 (Synthesized Content)
-*   **작동 방식 및 주요 분석 기법**: SAST는 소스 코드를 구문 분석하여 추상 구문 트리(AST)를 구축하고 코드의 구조, 의미론적 흐름, 데이터 흐름(Data Flow) 등을 정적으로 분석한다 [5, 6]. 가장 중요한 기법 중 하나인 오염 분석(Taint analysis)은 사용자 입력 같은 신뢰할 수 없는 데이터 소스가 데이터베이스 쿼리나 파일 시스템 조작 같은 민감한 싱크(Sink)로 데이터 무결성 검증 없이 흘러가는지를 추적한다 [7, 8].
-*   **탐지 가능한 주요 취약점**: 인젝션 공격(SQL, NoSQL, 명령어 등), 크로스 사이트 스크립팅(XSS), 경로 탐색(Path traversal), 하드코딩된 비밀번호 및 민감 정보 노출, 안전하지 않은 암호화 알고리즘, 서버 측 요청 위조(SSRF) 등 주로 코드 레벨에서 발생하는 광범위한 결함을 찾아낸다 [1, 9-11].
-*   **전통적 SAST의 한계점**: 기존의 SAST는 정해진 규칙에 전적으로 의존하므로 비즈니스 로직의 의도나 런타임 컨텍스트를 이해하지 못해 가짜 경고인 오탐(False Positive)을 다수 발생시킬 수 있다 [3, 12, 13]. 또한 분석 대상의 프로그래밍 언어에 강하게 종속적이며, 프론트엔드와 백엔드가 다른 저장소로 분리된 경우 전체 맥락을 잃는다는 한계가 존재한다 [13]. 
-*   **AI 기반 SAST로의 진화**: 최신의 SAST 도구들(예: Snyk Code, Corgea 등)은 대규모 언어 모델(LLM)과 머신러닝을 도입하여 전통적 SAST의 오탐률을 획기적으로 낮추고 있다 [14-17]. 이들은 여러 파일에 걸친(Interfile) 데이터 흐름을 이해하여 숨겨진 로직 결함을 찾아내며, 개발자의 통합 개발 환경(IDE)이나 Pull Request 환경에서 적절한 코드 수정안(Auto-fix)을 자동 제안하고 적용 전 자체 검증까지 거치는 수준으로 발전하고 있다 [18-21].
-*   **다른 애플리케이션 보안(AppSec) 도구와의 관계**: SAST는 개발 조직이 직접 작성한 1사(First-party) 코드를 검사한다 [22]. 반면, 실행 중인 애플리케이션을 블랙박스 형태로 테스트하는 것은 동적 애플리케이션 보안 테스트(DAST)이며, 서드파티 오픈소스 종속성 내의 알려진 취약점(CVE)이나 라이선스 위험을 분석하는 것은 소프트웨어 구성 분석(SCA)이다 [22-24]. 견고한 보안을 위해서는 이들 도구를 상호 보완적인 하이브리드 방식으로 CI/CD 파이프라인에 구축해야 한다 [25-27].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** AI 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[정적 코드 분석]], [[시프트 레프트 (Shift-Left)]], [[오염 분석 (Taint Analysis)]], [[동적 애플리케이션 보안 테스트 (DAST)]], [[소프트웨어 구성 분석 (SCA)]], [[자동화된 코드 거버넌스]]
-- **Projects/Contexts:** [[Snyk Code]], [[Corgea]], [[GitHub Advanced Security]], [[DevSecOps 파이프라인]]
-- **Contradictions/Notes:** 자동화된 SAST 도구들은 처리 속도와 규모 확장성이 뛰어나지만, 정해진 규칙에 벗어나거나 복잡한 비즈니스 로직 및 새로운 아키텍처 맥락에 따른 취약점은 놓칠 수 있다. 연구에 따르면 SAST 툴들은 실제 취약점의 약 22% 정도를 탐지하지 못하거나 30~60%의 높은 오탐률로 경고 피로도(Alert fatigue)를 일으킨다 [12, 28, 29]. 따라서 AI로 개선된 SAST 도구를 사용하여 일차적인 검열을 수행하더라도, 고위험 코드나 복잡한 시스템 로직의 최종 보안 검증을 위해서는 반드시 인간 중심의 '수동 코드 리뷰(Manual Code Review)'를 결합하는 하이브리드 리뷰가 필수적으로 요구된다 [30-32].
-
----
-*Last updated: 2026-04-18*
-- Raw Source: [[00_Raw/2026-04-20/정적 애플리케이션 보안 테스트 (SAST).md]]
----
diff --git a/AI/정적 애플리케이션 보안 테스트(SAST).md b/AI/정적 애플리케이션 보안 테스트(SAST).md
deleted file mode 100644
index 5fffa116..00000000
--- a/AI/정적 애플리케이션 보안 테스트(SAST).md	
+++ /dev/null
@@ -1,48 +0,0 @@
----
-id: P-REINFORCE-AUTO-E9615F
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - 정적 애플리케이션 보안 테스트(SAST)"
----
-
-# [[정적 애플리케이션 보안 테스트(SAST)]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 정적 애플리케이션 보안 테스트(SAST)는 애플리케이션을 실행하지 않고 소스 코드, 바이트코드 등의 구조와 구문을 정적으로 분석하여 보안 취약점과 논리적 오류를 식별하는 화이트박스 테스트 기법입니다 [1, 2]. 소프트웨어 개발 생명주기(SDLC)의 가장 초기 단계(코드 작성 및 CI/CD 파이프라인)에 적용되어 문제를 발견하므로, 수정에 드는 비용과 시간을 크게 절감할 수 있습니다 [1, 3, 4]. 최근의 SAST 도구들은 단순한 패턴 매칭을 넘어 머신러닝 및 대형 언어 모델(LLM)을 결합하여 코드의 문맥을 이해하고, 자동으로 수정 코드를 제안하는 AI 기반으로 진화하고 있습니다 [5, 6].
-
-## 📖 구조화된 지식 (Synthesized Content)
-* **작동 원리 및 주요 탐지 항목:**
-  SAST는 소스 코드를 구문 분석하여 추상 구문 트리(AST)를 구축하고 제어 흐름, 데이터 흐름(오염 분석 등) 및 의미론적 분석을 적용하여 취약점을 찾아냅니다 [2, 7, 8]. 이를 통해 SQL 인젝션, 크로스 사이트 스크립팅(XSS), 경로 탐색, 하드코딩된 비밀번호, 안전하지 않은 암호화 알고리즘 등 OWASP Top 10에 해당하는 주요 보안 위협을 애플리케이션 배포 전에 식별합니다 [9-12].
-
-* **SAST 도입의 장점:**
-  * **조기 발견 및 수정(시프트 레프트):** IDE 플러그인이나 커밋 이전 단계(Pre-commit hook)에 연동되어, 개발자가 코드를 작성하는 즉시 피드백을 제공받고 실시간으로 문제를 해결할 수 있습니다 [13-15].
-  * **명확한 가이드 제공:** 취약점이 발생한 정확한 코드 위치와 데이터 흐름을 시각적으로 제공하여 원인 파악 및 수정이 매우 용이합니다 [14, 16].
-  * **실행 환경 불필요:** 코드를 실행하지 않고도 분석이 가능해 동적 테스트(DAST)에 비해 스캔 속도가 빠르고 자동화가 쉽습니다 [14, 17].
-
-* **한계 및 단점:**
-  * **컨텍스트 부족 및 오탐(False Positive):** 런타임 환경이나 비즈니스 로직의 의도를 완전히 이해하지 못해, 실제로는 안전한 코드임에도 취약점으로 경고하는 오탐(False Positive)과 미탐(False Negative)이 발생할 수 있습니다 [18, 19].
-  * **언어 종속성:** 분석 대상 코드가 작성된 특정 프로그래밍 언어와 프레임워크를 해당 도구가 명시적으로 지원해야만 작동합니다 [19].
-
-* **AI 기반 SAST의 등장:**
-  전통적인 SAST는 정해진 규칙과 패턴에 의존하지만, 현대의 AI 기반 SAST(예: Snyk Code, Corgea 등)는 수백만 개의 오픈소스 커밋 데이터를 학습한 머신러닝/LLM 엔진을 활용합니다 [6, 20, 21]. 이를 통해 여러 파일과 모듈에 걸친 복잡한 데이터 흐름(Interfile analysis)을 추적하고, 단순 경고를 넘어 개발자가 즉각 반영할 수 있는 상황에 맞는 자동 수정(Auto-fix) 코드를 제안합니다 [22-24].
-
-* **효과적인 활용을 위한 하이브리드 코드 리뷰:**
-  자동화된 SAST는 알려진 보안 취약점과 스타일 오류를 기계적인 속도로 일관되게 찾아내는 데 탁월합니다 [25, 26]. 그러나 도구는 아키텍처의 트레이드오프나 도메인 특화 비즈니스 로직을 평가할 수 없습니다 [27, 28]. 따라서 SAST를 CI/CD 파이프라인의 1차 품질 게이트로 자동화하여 반복적인 결함을 걸러내고, 아키텍처나 민감한 권한 로직 등에 대해서는 사람이 직접 문맥을 파악하는 수동 코드 리뷰(Manual Review)를 결합하는 하이브리드 접근법이 가장 이상적입니다 [29-31].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** AI 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[동적 애플리케이션 보안 테스트(DAST)]], [[소프트웨어 구성 분석(SCA)]], [[시프트 레프트(Shift-Left)]], [[추상 구문 트리(AST)]]
-- **Projects/Contexts:** [[CI/CD 파이프라인]], [[OWASP Top 10]], [[하이브리드 코드 리뷰]]
-- **Contradictions/Notes:** 
-  * "전통적인 규칙 기반의 SAST 도구는 50~80%에 이르는 높은 오탐률(False Positive)을 보여 개발자의 피로도를 높일 수 있지만, 최근의 AI 및 기계 학습 기반 SAST(예: Veracode, Corgea 등)는 컨텍스트를 이해함으로써 오탐률을 5% 이하(일부 1.1% 미만)로 현저히 줄일 수 있다고 보고됩니다." [19, 32].
-  * "자동화된 정적 분석 도구만으로 모든 보안 오류를 막을 수 있다고 기대하는 것은 위험합니다. 실증 연구에 따르면 SAST 도구는 실제 존재하는 취약점의 약 22%를 완전히 놓칠 수 있으며, 따라서 자동화 도구를 맹신하지 말고 고위험 코드 변경에 대해서는 반드시 수동 코드 리뷰를 병행해야 합니다." [18, 33-35].
-
----
-*Last updated: 2026-04-18*
-- Raw Source: [[00_Raw/2026-04-20/정적 애플리케이션 보안 테스트(SAST).md]]
----
diff --git a/AI/지식 베이스 (Knowledge Base).md b/AI/지식 베이스 (Knowledge Base).md
deleted file mode 100644
index a63a6229..00000000
--- a/AI/지식 베이스 (Knowledge Base).md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-295580
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - 지식 베이스 (Knowledge Base)"
----
-
-# [[지식 베이스 (Knowledge Base)]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** AI 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/지식 베이스 (Knowledge Base).md]]
----
diff --git a/AI/직렬화(Serialization) 및 병목 현상.md b/AI/직렬화(Serialization) 및 병목 현상.md
deleted file mode 100644
index 3d327fae..00000000
--- a/AI/직렬화(Serialization) 및 병목 현상.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-9AD769
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - 직렬화(Serialization) 및 병목 현상"
----
-
-# [[직렬화(Serialization) 및 병목 현상]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** AI 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/직렬화(Serialization) 및 병목 현상.md]]
----
diff --git a/AI/창발 능력 (Emergent Abilities).md b/AI/창발 능력 (Emergent Abilities).md
deleted file mode 100644
index 7d8ef2d1..00000000
--- a/AI/창발 능력 (Emergent Abilities).md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-9DBA7B
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - 창발 능력 (Emergent Abilities)"
----
-
-# [[창발 능력 (Emergent Abilities)]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** AI 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/창발 능력 (Emergent Abilities).md]]
----
diff --git a/AI/카산드라(Cassandra).md b/AI/카산드라(Cassandra).md
deleted file mode 100644
index 5cafeb73..00000000
--- a/AI/카산드라(Cassandra).md
+++ /dev/null
@@ -1,38 +0,0 @@
----
-id: P-REINFORCE-AUTO-A802F0
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - 카산드라(Cassandra)"
----
-
-# [[카산드라(Cassandra)]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 카산드라(Cassandra)는 기존의 RDBMS를 대체하여 대규모 데이터 환경(NoSQL at scale)을 지원하기 위해 사용되는 오픈 소스 기반의 데이터베이스입니다 [1]. 다중 리전(Multi-Regional) 및 다방향(Multi-directional) 아키텍처를 지원하며, 가용성(Available)과 파티션 허용성(Partition Tolerance)을 제공하는 것이 특징입니다 [1]. 넷플릭스(Netflix)의 마이크로서비스 아키텍처에서 인프라의 핵심 데이터 저장소로 활용되었습니다 [1, 2].
-
-## 📖 구조화된 지식 (Synthesized Content)
-소스에 기반한 카산드라(Cassandra)의 주요 특징 및 활용 맥락은 다음과 같습니다:
-
-* **대규모 NoSQL 데이터베이스:** 관계형 데이터베이스(RDBMS) 모델에서 전환하여, 대규모 확장에 최적화된 NoSQL 솔루션으로 채택되었습니다 [1]. 
-* **분산 시스템 아키텍처 특성:** 
-  * 오픈 소스 기술로 설계되었습니다 [1].
-  * 다중 리전 및 다방향으로 동작할 수 있어 글로벌 스케일의 시스템에 적합합니다 [1].
-  * 분산 컴퓨팅의 핵심 특성인 높은 가용성(Available)과 네트워크 단절 시에도 시스템이 동작하는 파티션 허용성(Partition Tolerance)을 보장합니다 [1].
-  * 상황에 따라 데이터의 일관성 수준을 조절할 수 있는 '조정 가능한 일관성(Tunable Consistency)'을 제공합니다 [1].
-* **넷플릭스(Netflix) 아키텍처 내의 역할:** 넷플릭스의 마이크로서비스 구조 내에서 EVCache, ELB, Zuul 등과 함께 미들 티어 및 플랫폼 인프라의 주요 데이터 레이어로 기능하고 있습니다 [2].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** AI 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[NoSQL]], [[RDBMS]], [[Microservices Architecture]], [[Tunable Consistency]]
-- **Projects/Contexts:** [[넷플릭스 마이크로서비스 아키텍처 전환(Adopting Microservices at Netflix)]]
-- **Contradictions/Notes:** 카산드라 자체에 대한 깊이 있는 기술적 원리보다는 넷플릭스의 마이크로서비스 도입 과정에서 RDBMS를 대체한 대규모 NoSQL 솔루션의 사례로서만 간략하게 언급되어 있어 추가적인 기술적 세부 정보는 소스에 관련 정보가 부족합니다 [1]. 
-
----
-*Last updated: 2026-04-18*
-- Raw Source: [[00_Raw/2026-04-20/카산드라(Cassandra).md]]
----
diff --git a/AI/코드 리뷰(Code Review).md b/AI/코드 리뷰(Code Review).md
deleted file mode 100644
index 837ff3a0..00000000
--- a/AI/코드 리뷰(Code Review).md	
+++ /dev/null
@@ -1,40 +0,0 @@
----
-id: P-REINFORCE-AUTO-119026
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - 코드 리뷰(Code Review)"
----
-
-# [[코드 리뷰(Code Review)]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 코드 리뷰는 소프트웨어의 품질, 보안 및 전반적인 코드 건강 상태를 개선하고 유지하기 위해 개발자들이 작성한 코드 변경 사항을 검사하는 프로세스입니다[1, 2]. 이 과정은 사람이 직접 코드를 읽고 분석하는 수동 리뷰와 정적 분석 도구 및 AI를 활용하는 자동화된 리뷰로 구성됩니다[3, 4]. 성공적인 코드 리뷰는 완벽한 코드만을 추구하기보다는 지속적인 개선과 개발 진행 속도 간의 적절한 균형을 맞추는 것을 목표로 합니다[5, 6].
-
-## 📖 구조화된 지식 (Synthesized Content)
-* **목적과 핵심 원칙:** 
-  코드 리뷰의 주된 목적은 시간이 지남에 따라 코드베이스의 전반적인 건강 상태를 개선하는 것입니다[2]. 리뷰어는 코드가 완벽하지 않더라도 전체적인 코드 건강을 향상시킨다면 승인을 고려해야 하며, 개발의 진척과 품질 사이에서 균형을 유지해야 합니다[5, 6]. 리뷰 중 발생하는 의견 충돌 시에는 개인적 선호보다 기술적인 사실과 데이터를 우선시해야 하며, 스타일 문제에 대해서는 정해진 스타일 가이드를 절대적인 기준으로 삼습니다[7]. 또한, 코드 리뷰는 개발자에게 새로운 언어, 프레임워크 또는 설계 원칙을 가르치는 멘토링과 지식 공유의 중요한 기능도 수행합니다[8, 9].
-
-* **수동 코드 리뷰 (Manual Code Review):** 
-  사람이 직접 코드를 줄 단위로 읽고 논의하는 방식입니다[1, 3]. 수동 리뷰는 아키텍처 설계의 트레이드오프 결정, 복잡한 비즈니스 로직 검증, 교차 서비스 영향 평가 및 코드 작성의 근본적인 의도를 파악하는 데 매우 뛰어납니다[1, 10, 11]. 반면, 코드를 검토하는 데 많은 시간과 비용이 소요되며, 리뷰어의 피로나 편견에 의해 인적 오류가 발생할 수 있어 일관된 검사 범위를 유지하기 어렵다는 단점이 있습니다[8, 12, 13].
-
-* **자동화된 코드 리뷰 (Automated Code Review):** 
-  정적 애플리케이션 보안 테스트(SAST), 린터(Linter), 포매터(Formatter), AI 도구 등을 사용하여 소스 코드를 실행하지 않고 자동으로 검사하는 방식입니다[3, 14]. 수천 줄의 코드를 단 몇 초 만에 스캔하여 구문 오류, 코딩 스타일 위반 및 알려진 보안 취약점을 일관되게 찾아냅니다[15, 16]. 대표적으로 SonarQube, ESLint, Prettier를 비롯해 GitHub Copilot, Snyk Code, DeepCode AI 등 기계 학습 기반의 AI 리뷰 도구들이 활용됩니다[17-20]. 그러나 자동화 도구는 비즈니스 로직이나 아키텍처의 의도를 완벽히 이해하지 못해 오탐(False Positive)을 다수 발생시킬 수 있다는 한계가 있습니다[21-23].
-
-* **하이브리드 리뷰 워크플로우 (Hybrid Review Workflow):** 
-  최신 소프트웨어 개발 환경에서는 수동 리뷰와 자동화된 리뷰를 결합한 하이브리드 모델이 가장 이상적인 모범 사례로 꼽힙니다[4, 24]. Husky와 lint-staged 같은 도구를 이용해 커밋 전이나 CI/CD 파이프라인에서 자동화된 스캔(스타일 검사, 보안 취약점 탐지)을 우선적으로 실행하여 반복적이고 기본적인 오류를 차단합니다[25-27]. 이렇게 자동화된 관문을 통과한 코드에 한해서 인간 리뷰어가 아키텍처 결정, 비즈니스 로직 검증 등 고차원적인 맥락 평가와 보안 영역에 집중하여 수동 리뷰를 진행합니다[26, 28].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** AI 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[수동 코드 리뷰(Manual Code Review)]], [[자동화된 코드 리뷰(Automated Code Review)]], [[정적 애플리케이션 보안 테스트(SAST)]]
-- **Projects/Contexts:** [[하이브리드 코드 리뷰 워크플로우]], [[Google의 코드 리뷰 표준]], [[DevSecOps 및 CI/CD 파이프라인]]
-- **Contradictions/Notes:** 자동화된 코드 리뷰 도구는 스캔 속도가 빠르고 규칙을 일관되게 적용하지만 비즈니스 로직의 의도를 이해하지 못해 다수의 오탐(False Positive)을 발생시킬 수 있습니다[22]. 반면 수동 코드 리뷰는 문맥을 이해하고 복잡한 아키텍처를 검토하는 데 필수적이지만 시간이 오래 걸리고 인적 오류의 위험이 병존합니다[13]. 따라서 이 두 가지 리뷰 방식은 상호 배타적인 것이 아니라, 장단점을 상호 보완하는 하이브리드 방식(기계적 검증 후 인간의 논리적 판단)으로 결합하여 사용하는 것이 권장됩니다[4, 26].
-
----
-*Last updated: 2026-04-19*
-- Raw Source: [[00_Raw/2026-04-20/코드 리뷰(Code Review).md]]
----
diff --git a/AI/풀 리퀘스트 워크플로우.md b/AI/풀 리퀘스트 워크플로우.md
deleted file mode 100644
index 7e257cb5..00000000
--- a/AI/풀 리퀘스트 워크플로우.md	
+++ /dev/null
@@ -1,33 +0,0 @@
----
-id: P-REINFORCE-AUTO-9C30BC
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - 풀 리퀘스트 워크플로우"
----
-
-# [[풀 리퀘스트 워크플로우]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 풀 리퀘스트 워크플로우(Pull Request Workflow)는 개발자가 작성한 소스 코드 변경 사항을 메인 브랜치에 병합(Merge)하기 전에 검토하고 검증하는 소프트웨어 개발 수명 주기(SDLC)의 핵심 단계입니다 [1, 2]. 현대의 풀 리퀘스트 워크플로우는 정적 애플리케이션 보안 테스트(SAST) 및 AI 기반 코드 리뷰 도구들과 긴밀하게 통합되어 작동합니다 [2, 3]. 이를 통해 코드의 품질과 보안을 자동으로 평가하고 수동 검토와 결합함으로써 리뷰 지연을 줄이고 결함이 프로덕션으로 넘어가는 것을 방지합니다 [4, 5].
-
-## 📖 구조화된 지식 (Synthesized Content)
-- **자동화 및 AI 도구의 통합:** 최신 풀 리퀘스트 워크플로우에서는 코드가 병합되기 전에 AI 및 정적 코드 분석(SAST) 도구가 자동으로 스캔을 수행합니다 [1, 3]. SonarQube, Snyk, Codacy, GitHub Advanced Security와 같은 도구들은 풀 리퀘스트 스레드 내에 직접 분석 요약, 수정 제안(Autofix) 및 품질 게이트 통과 여부를 표시하여 개발자와 리뷰어에게 즉각적인 피드백을 제공합니다 [6-9].
-- **수동 및 자동화 리뷰의 하이브리드 접근:** 풀 리퀘스트 워크플로우에서 자동화 도구는 구문 오류, 코드 스멜, 알려진 보안 취약점을 기계적인 속도로 찾아내는 데 탁월합니다 [10]. 하지만 비즈니스 로직, 아키텍처 설계의 트레이드오프, 문맥 의존적인 보안 위험은 여전히 인간 리뷰어의 전문성이 요구됩니다 [11-13]. 따라서 풀 리퀘스트 시 자동화 스캔을 먼저 실행하여 일상적인 문제를 걸러낸 후, 인간 리뷰어가 중요 로직 검토에 집중하는 하이브리드 방식이 가장 이상적입니다 [5, 14].
-- **워크플로우 성과 측정 지표:** 풀 리퀘스트 워크플로우의 효율성과 AI 도구 도입의 영향은 여러 지표를 통해 측정됩니다. 대표적으로 '풀 리퀘스트 사이클 시간(PR cycle time)', '최초 리뷰까지 걸린 시간(Time to first review)', '리뷰 백로그 크기(Review backlog size)', 그리고 '병합 후 재작업률(Post-merge rework rate)'이 사용됩니다 [15, 16]. 
-- **사전 커밋(Pre-commit) 단계와의 연계:** 풀 리퀘스트 워크플로우로 코드가 올라오기 전, 개발 환경 로컬 단에서 Husky와 lint-staged 같은 Git 훅(Git Hooks) 도구를 사용하여 사전 검증을 구성할 수 있습니다 [17, 18]. 이 도구들은 커밋을 시도하는 변경된 파일에 대해서만 ESLint 및 Prettier 등을 실행하여 오류를 수정하고 포맷팅을 강제함으로써, 풀 리퀘스트 리뷰 시 스타일 관련 논쟁을 없애고 워크플로우의 속도를 높여줍니다 [18, 19].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** AI 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[자동화된 코드 리뷰]], [[수동 코드 리뷰]], [[SAST (정적 애플리케이션 보안 테스트)]], [[Git 훅 (Git Hooks)]]
-- **Projects/Contexts:** [[DevSecOps]], [[CI/CD 파이프라인]]
-- **Contradictions/Notes:** 소스들은 AI 및 자동화 도구가 풀 리퀘스트 리뷰 주기를 단축시킨다고 주장하지만, 올바른 워크플로우 체계 없이 단순히 도구만 도입할 경우 오히려 무의미한 경고(False Positives)가 쏟아져 리뷰어의 경고 피로도(Alert Fatigue)를 높이고 리뷰 지연을 초래할 수 있다고 경고합니다 [11, 20, 21].
-
----
-*Last updated: 2026-04-19*
-- Raw Source: [[00_Raw/2026-04-20/풀 리퀘스트 워크플로우.md]]
----
diff --git a/AI/풀 리퀘스트(PR) 기반 보안 검토.md b/AI/풀 리퀘스트(PR) 기반 보안 검토.md
deleted file mode 100644
index a738a738..00000000
--- a/AI/풀 리퀘스트(PR) 기반 보안 검토.md	
+++ /dev/null
@@ -1,33 +0,0 @@
----
-id: P-REINFORCE-AUTO-8FBB2B
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - 풀 리퀘스트(PR) 기반 보안 검토"
----
-
-# [[풀 리퀘스트(PR) 기반 보안 검토]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 풀 리퀘스트(PR) 기반 보안 검토는 소프트웨어 개발 수명 주기(SDLC)에서 코드 변경 사항이 메인 브랜치에 병합되기 전에 보안 취약점과 품질 문제를 검사하는 핵심 과정입니다 [1, 2]. 이 과정은 자동화된 정적 분석(SAST) 및 AI 도구를 통한 사전 필터링과 개발자의 수동 피어 리뷰(Peer Review)를 결합하여, 개발 속도를 저하시키지 않으면서 코드의 보안성과 유지보수성을 확보하는 것을 목표로 합니다 [3, 4].
-
-## 📖 구조화된 지식 (Synthesized Content)
-- **조기 결함 발견 및 시프트 레프트(Shift-Left):** PR은 개발자들이 변경 사항을 검토하고 승인하는 병합 지점이므로, 코드가 출시되기 전에 보안 위험을 가장 효과적으로 표면화하고 해결할 수 있는 단계입니다 [5, 6]. CI/CD 파이프라인 및 PR 워크플로우에 정적 코드 분석과 실시간 검사를 통합함으로써 개발자는 배포 이후가 아닌 병합 이전에 성능 문제와 보안 취약점을 조기에 발견하여 '시프트 레프트(Shift-Left)' 보안을 실현할 수 있습니다 [1, 7, 8].
-- **자동화 및 AI 기반 PR 리뷰:** 최신 보안 검토는 AI 코드 리뷰 도구와 SAST 엔진을 활용하여 PR 생성 시 자동으로 코드를 스캔합니다 [2, 9]. SonarQube, Snyk Code, GitHub Code Security 등의 도구는 PR 내에 인라인 주석이나 경고 형태로 취약점(예: 누출된 비밀번호, 인젝션, 코드 스멜)을 직접 표시하여 개발자가 즉각적으로 피드백을 받을 수 있도록 합니다 [10-13]. 또한, 사전 정의된 품질 게이트(Quality Gates) 정책을 통해 보안 기준을 충족하지 못하는 PR의 병합을 차단할 수 있으며, AI가 생성한 수정 제안(Auto-fix)을 제공하여 리뷰어의 피로도를 줄이고 해결 속도를 극대화합니다 [10, 14-16].
-- **인간과 자동화의 하이브리드 검토 프로세스:** 자동화 도구는 수천 줄의 코드를 몇 분 만에 스캔하고 일관된 규칙을 적용하는 데 뛰어나지만, 비즈니스 로직이나 아키텍처 맥락을 이해하는 데는 한계가 있습니다 [17, 18]. 따라서 최근의 권장 워크플로우는 1차적으로 자동화 스캔을 통해 단순 구문 오류나 알려진 보안 결함을 걸러내고, 2차적으로 인간 리뷰어가 인증 로직이나 교차 서비스(Cross-Service)의 영향 등 자동화가 놓치기 쉬운 심층적인 보안 컨텍스트를 수동으로 점검하는 하이브리드 프로세스(Hybrid Code Review)를 채택하고 있습니다 [3, 4, 19, 20].
-- **측정 지표 및 컴플라이언스:** PR 검토의 효율성과 영향력은 PR 사이클 타임(Cycle time), 첫 리뷰까지 걸리는 시간, 리뷰 백로그 크기, 병합 전 발견된 결함 수 등의 지표로 측정됩니다 [21, 22]. 올바르게 수행된 PR 보안 검토, 티켓 코멘트, 그리고 승인 기록은 SOC 2, PCI DSS와 같은 규정 준수 감사를 위한 필수적인 증명(Audit Trail) 자료로 활용됩니다 [23, 24].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** AI 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[정적 애플리케이션 보안 테스트(SAST)]], [[AI 기반 코드 리뷰]], [[시프트 레프트(Shift-Left)]], [[품질 게이트(Quality Gates)]], [[하이브리드 코드 리뷰(Hybrid Code Review)]]
-- **Projects/Contexts:** [[GitHub Code Security 및 Copilot Autofix]], [[SonarQube PR 분석]], [[Snyk Code PR 통합]]
-- **Contradictions/Notes:** 자동화된 PR 코드 검토는 속도와 확장성 측면에서 매우 우수하지만 코드의 의도나 아키텍처 맥락을 이해하지 못해 오탐(False Positive)을 유발할 수 있습니다. 따라서 도구의 결과에만 의존하기보다는 복잡한 비즈니스 로직과 보안 컨텍스트 평가는 반드시 인간의 수동 검토가 동반되어야 상호 보완적인 보안 품질을 달성할 수 있습니다 [18, 25, 26].
-
----
-*Last updated: 2026-04-19*
-- Raw Source: [[00_Raw/2026-04-20/풀 리퀘스트(PR) 기반 보안 검토.md]]
----
diff --git a/AI/프론트엔드 및 Nodejs 개발 워크플로우.md b/AI/프론트엔드 및 Nodejs 개발 워크플로우.md
deleted file mode 100644
index 22741ec7..00000000
--- a/AI/프론트엔드 및 Nodejs 개발 워크플로우.md	
+++ /dev/null
@@ -1,43 +0,0 @@
----
-id: P-REINFORCE-AUTO-D024EA
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - 프론트엔드 및 Nodejs 개발 워크플로우"
----
-
-# [[프론트엔드 및 Nodejs 개발 워크플로우]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 프론트엔드 및 Node.js 개발 워크플로우는 소스 코드의 품질, 일관성, 그리고 보안을 자동화된 방식으로 유지하기 위해 일련의 도구들을 파이프라인에 결합하는 과정입니다. 주축이 되는 도구로는 코드 에러를 정적으로 분석하는 ESLint와 코드 스타일을 자동으로 정렬해주는 Prettier가 있으며, 이를 Git 훅(Git Hooks) 관리 도구인 Husky와 변경된 파일만 검사하는 lint-staged를 통해 커밋 전에 강제합니다. 최근에는 이러한 파이프라인과 IDE에 AI 기반의 정적 애플리케이션 보안 테스트(SAST)를 결합하여 취약점을 조기에 탐지하고 자동 수정하는 체계가 필수적으로 자리 잡고 있습니다.
-
-## 📖 구조화된 지식 (Synthesized Content)
-*   **코드 품질 및 스타일 자동화 도구 (ESLint & Prettier)**
-    자바스크립트 및 타입스크립트 기반의 프론트엔드와 Node.js 환경에서는 코드 품질과 스타일을 일관되게 유지하기 위해 ESLint와 Prettier를 핵심 도구로 사용합니다 [1, 2]. ESLint는 문법적 오류와 잠재적 버그, 안티 패턴을 찾아내고 규칙을 강제하는 린터(Linter)이며, Prettier는 줄 바꿈, 공백, 들여쓰기 등의 코드 스타일을 일관되게 변환해주는 포매터(Formatter)입니다 [1, 3, 4]. 이 두 도구를 함께 사용할 때 포맷팅 역할이 겹쳐 충돌이 발생할 수 있는데, 이를 방지하기 위해 `eslint-config-prettier` 패키지를 사용하여 Prettier와 충돌하는 ESLint 규칙을 비활성화하는 방식이 표준으로 권장됩니다 [5-7].
-    
-*   **Git 훅을 통한 검증 자동화 (Husky & lint-staged)**
-    개발자가 컨벤션에 맞지 않는 코드를 저장소에 커밋하는 것을 방지하기 위해 Git 훅(Git Hooks)을 자동화하는 Husky와 lint-staged가 폭넓게 사용됩니다 [8, 9]. Husky는 `pre-commit`이나 `pre-push` 등의 훅을 쉽게 공유하고 설정하게 해주며, lint-staged는 전체 코드베이스가 아닌 커밋 대기 중인 '스테이징된(staged) 파일'에 대해서만 검사와 포맷팅을 실행하도록 오케스트레이션하여 실행 속도를 획기적으로 높입니다 [9-11]. 이 설정은 `package.json`의 `prepare` 스크립트와 연동되어 팀원 누구나 의존성을 설치할 때 동일한 검증 파이프라인을 구축하게 해줍니다 [12, 13].
-
-*   **모노레포 환경에서의 워크플로우 구성**
-    React, Next.js 등 다양한 애플리케이션과 공유 라이브러리를 단일 저장소에서 관리하는 Turborepo 같은 모노레포(Monorepo) 환경에서는 린팅 설정의 파편화와 중복을 막기 위해 중앙집중식 관리를 수행합니다 [14, 15]. 중앙 패키지(예: `@repo/eslint-config`)에 Base, Next.js, 라이브러리 용의 사전 설정(preset)을 정의해두고, 각 개별 패키지에서는 이를 상속하여 사용합니다 [16-18]. 이후 프로젝트 루트 디렉토리에서 lint-staged를 실행할 때, 오케스트레이션 설정을 통해 변경된 파일이 어느 패키지에 속하는지 파악하고 각 패키지의 린팅 규칙을 독립적으로 적용함으로써 유지보수성을 극대화합니다 [18-20].
-
-*   **정적 애플리케이션 보안 테스트(SAST) 및 AI의 결합**
-    코드 품질 검증과 함께 Snyk Code, SonarQube, Checkmarx와 같은 SAST 도구들이 IDE 및 CI/CD 파이프라인에 통합되어 실시간으로 보안 취약점을 점검합니다 [21-23]. 기존의 단순 패턴 매칭을 넘어, 최근 워크플로우에는 LLM과 기계학습(ML)을 기반으로 한 AI 에이전트가 도입되어 파일 간의 데이터 흐름(Interfile analysis)이나 XSS, SQL 인젝션, 하드코딩된 비밀번호 등 복잡한 문맥의 취약점을 탐지합니다 [24-26]. 나아가 발견된 오류에 대해 단순 경고를 넘어 AI 기반의 자동 수정(Auto-fix) 코드를 제안하여 개발자가 즉각적으로 코드를 리팩토링하고 병합할 수 있도록 돕습니다 [27-29].
-
-*   **개발 워크플로우 내 공급망 보안 위협**
-    개발 워크플로우를 구성하는 도구 자체의 보안 검증 또한 중요합니다. 실제로 워크플로우 구축 시 가장 흔하게 사용되는 `eslint-config-prettier` 패키지가 2025년에 공급망 공격(CVE-2025-54313)의 타겟이 된 사례가 있습니다 [30-32]. 관리자의 토큰 탈취를 통해 배포된 악성 버전은 `npm install` 실행 시 윈도우(Windows) 개발자 머신에 원격 코드 실행(RCE)을 가능하게 하는 악성 DLL을 드롭하도록 조작되어 있어, 코드 검증 도구와 서드파티 패키지 사용에 대한 지속적인 보안 및 의존성 관리가 필수적임을 시사합니다 [31-33].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** AI 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[ESLint]], [[Prettier]], [[Husky]], [[lint-staged]], [[정적 애플리케이션 보안 테스트 (SAST)]], [[공급망 공격 (Supply Chain Attack)]]
-- **Projects/Contexts:** [[React 및 Next.js 개발 환경]], [[Turborepo 기반 모노레포 워크플로우]]
-- **Contradictions/Notes:** ESLint와 Prettier를 결합할 때, `eslint-plugin-prettier`를 사용하여 Prettier를 ESLint 규칙의 일부로 실행하는 방식이 존재하지만, Prettier 공식 문서 및 실무 환경에서는 성능 저하 문제와 에디터 내 과도한 경고(빨간 밑줄) 발생 등의 피로도 문제로 인해 `eslint-config-prettier`를 활용해 역할(규칙 검사는 ESLint, 포맷팅은 Prettier)을 명확히 분리하는 것을 가장 권장합니다 [5, 34, 35].
-
----
-*Last updated: 2026-04-18*
-- Raw Source: [[00_Raw/2026-04-20/프론트엔드 및 Node.js 개발 워크플로우.md]]
----
diff --git a/AI/하이브리드 코드 리뷰 (Hybrid Code Review).md b/AI/하이브리드 코드 리뷰 (Hybrid Code Review).md
deleted file mode 100644
index 2c60cc78..00000000
--- a/AI/하이브리드 코드 리뷰 (Hybrid Code Review).md	
+++ /dev/null
@@ -1,44 +0,0 @@
----
-id: P-REINFORCE-AUTO-4CD9A4
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - 하이브리드 코드 리뷰 (Hybrid Code Review)"
----
-
-# [[하이브리드 코드 리뷰 (Hybrid Code Review)]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 하이브리드 코드 리뷰는 자동화된 정적 분석 및 AI 도구 스캔과 사람(개발자)에 의한 수동 코드 리뷰를 결합한 접근 방식입니다 [1]. 자동화 도구를 통해 구문 오류나 알려진 보안 취약점을 빠르고 일관되게 찾아내는 동시에, 복잡한 비즈니스 로직, 아키텍처 설계 및 맥락 판단은 인간의 전문성에 맡깁니다 [1, 2]. 두 방식의 장점을 상호 보완적으로 활용하여 릴리스 속도를 높이면서도 코드의 품질과 보안을 극대화하는 현대적인 소프트웨어 개발 워크플로우입니다 [1, 3, 4].
-
-## 📖 구조화된 지식 (Synthesized Content)
-**하이브리드 리뷰의 필요성 및 개념**
-수동 코드 리뷰와 자동화된 코드 리뷰는 각각 뚜렷한 장단점을 지니고 있습니다 [1]. 수동 리뷰는 코드의 작성 의도, 아키텍처, 비즈니스 로직의 맥락을 깊이 이해할 수 있지만, 라인별로 코드를 읽어야 하므로 속도가 느리고 인적 오류나 편향이 발생할 수 있습니다 [5, 6]. 반면 자동화된 리뷰(SAST, 린터 등)는 수천 줄의 코드를 몇 초 만에 스캔하는 속도와 일관성을 제공하지만, 비즈니스 로직이나 맥락을 이해하지 못해 '오탐(False Positives)'을 다수 발생시킬 수 있습니다 [7, 8]. 따라서 자동화 도구가 일상적이고 기계적인 검증을 처리하고, 인간은 맥락 기반의 비판적 사고가 필요한 부분에 집중하는 하이브리드 모델이 최적의 대안으로 평가받습니다 [1, 2].
-
-**단계별 하이브리드 워크플로우 (Sequential Gates Architecture)**
-성공적인 하이브리드 코드 리뷰 파이프라인은 다음과 같은 단계적 구조로 구성됩니다:
-*   **1단계 - 자동화 스캔 수행 (Automated Pre-Merge Checks):** Pull Request가 생성되면 CI/CD 파이프라인에서 코드 포맷팅, 린팅, SAST(정적 애플리케이션 보안 테스트), 단위 테스트, 의존성 취약점 스캔 등을 자동으로 병렬 실행하여 기본 규칙 위반과 단순 결함을 조기에 차단합니다 [9-11].
-*   **2단계 - 결과의 신속한 분석 및 수정:** 자동화 리포트에서 발견된 구문 오류 등 우선순위가 높은(또는 쉽게 해결 가능한) 경고를 먼저 수정하고 분류(Triage)하여 이후 수동 리뷰에 소요되는 시간을 단축합니다 [9].
-*   **3단계 - 조건부 수동 리뷰 (Conditional Human Review Routing):** 자동화 단계를 통과한 후, 고위험 경로(예: 결제, 인증 로직), 아키텍처 변경, 교차 서비스 영향 평가 등 사람의 통찰이 반드시 필요한 영역에 한해 심층적인 수동 검토를 진행합니다 [2, 9, 12]. 
-*   **4단계 - 지속적인 피드백 루프:** 놓친 패턴이나 과도한 오탐이 발생할 경우, 이를 툴체인의 규칙 조정에 반영하여 자동화의 정확도를 지속적으로 향상시킵니다 [9].
-
-**하이브리드 리뷰 도입 시 주의해야 할 안티 패턴**
-조직 내에서 하이브리드 리뷰를 구축할 때 다음과 같은 위험 요소들을 주의하여야 합니다 [13].
-*   **거짓 양성 역설 (The False Positive Paradox):** 자동화 도구를 적절히 튜닝하지 않으면 너무 많은 알림이 발생하여 경고 피로(Alert Fatigue)가 생기고, 개발자가 진짜 치명적인 취약점마저 무시하게 됩니다 [8, 13].
-*   **자동화에 대한 과도한 신뢰 (Over-Confidence in Automation):** 실제 연구에 따르면 SAST 도구는 실제 취약점의 약 22%를 놓칠 수 있습니다. 자동화 검사를 통과했다고 해서 완벽하다고 맹신하지 말고 고위험 변경 사항은 반드시 인간의 확인을 거쳐야 합니다 [13, 14].
-*   **"녹색 체크 마크" 증후군 (The "Green Check Mark" Syndrome):** 실제 아키텍처 개선이나 코드 품질 이해보다는 단순히 자동화된 파이프라인(린터 등)을 통과하는 것에만 초점을 맞추어 겉핥기식 수정만 이루어지는 현상입니다 [13, 15].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** AI 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[수동 코드 리뷰 (Manual Code Review)]], [[자동화된 코드 리뷰 (Automated Code Review)]], [[정적 애플리케이션 보안 테스트 (SAST)]], [[소프트웨어 구성 분석 (SCA)]]
-- **Projects/Contexts:** [[지속적 통합/지속적 배포 (CI/CD) 파이프라인]], [[Pull Request (PR) 승인 워크플로우]]
-- **Contradictions/Notes:** 소스는 수동 리뷰와 자동화 리뷰 중 어느 하나가 다른 하나를 완벽히 대체할 수 없음을 강조합니다. 자동화 도구(AI 포함)는 속도와 확장성이 뛰어나나 비즈니스 로직과 설계의 맥락을 파악하지 못해 한계(Context Blindness)를 보이며, 반대로 사람은 피로도와 비용 문제로 모든 코드를 완벽히 리뷰할 수 없습니다. 따라서 양쪽을 결합하는 하이브리드 접근이 보안과 품질 유지의 핵심 타협점으로 꼽힙니다 [1, 8, 16, 17].
-
----
-*Last updated: 2026-04-19*
-- Raw Source: [[00_Raw/2026-04-20/하이브리드 코드 리뷰 (Hybrid Code Review).md]]
----
diff --git a/AI/하이브리드 코드 리뷰.md b/AI/하이브리드 코드 리뷰.md
deleted file mode 100644
index 2096d982..00000000
--- a/AI/하이브리드 코드 리뷰.md	
+++ /dev/null
@@ -1,50 +0,0 @@
----
-id: P-REINFORCE-AUTO-F958B3
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - 하이브리드 코드 리뷰"
----
-
-# [[하이브리드 코드 리뷰]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 하이브리드 코드 리뷰는 인공지능(AI) 및 자동화 도구의 처리 속도와 인간 개발자의 깊은 통찰력을 결합한 최적의 코드 리뷰 모델입니다 [1]. 자동화 도구가 반복적인 구문 검사와 알려진 취약점을 신속하고 일관되게 찾아내는 동안, 인간 리뷰어는 도구가 파악할 수 없는 아키텍처의 트레이드오프, 복잡한 비즈니스 로직 및 보안 컨텍스트에 집중합니다 [1-3]. 두 방식의 단점을 상호 보완함으로써 개발 속도를 늦추지 않으면서도 소프트웨어의 보안과 코드 품질을 극대화하는 것이 이 접근법의 핵심입니다 [1, 4].
-
-## 📖 구조화된 지식 (Synthesized Content)
-**1. 하이브리드 코드 리뷰 프로세스 단계**
-성공적인 하이브리드 접근법은 자동화와 인간의 판단을 단계별로 배치합니다 [5].
-*   **자동화 스캔 우선 실행:** CI/CD 파이프라인에 정적 분석(SAST) 및 린팅을 통합하여 모든 푸시 단계에서 구문 오류, 단순 보안 결함, 코드 스타일 등을 즉시 검사하여 정책을 강제합니다 [5].
-*   **결과 신속 분석 및 조치:** 자동화 도구의 보고서에서 주요 문제를 빠르게 해결하여 이후 단계의 속도를 높입니다 [5].
-*   **수동 리뷰 수행:** 기본 문제가 해결된 코드를 바탕으로, 인간 리뷰어는 보안에 민감한 영역, 복잡한 알고리즘, 교차 서비스 영향 등 기계가 파악하기 힘든 문맥 및 설계 요소에 집중하여 검사합니다 [5-7].
-*   **지속적인 피드백 루프 및 온보딩:** 놓친 패턴이나 잦은 오탐지가 발생하면 자동화 도구의 규칙을 재조정하며, 수동 리뷰 과정은 주니어 개발자를 위한 멘토링 기회로 활용됩니다 [5].
-
-**2. 하이브리드 리뷰 워크플로우 아키텍처 (순차적 게이트)**
-기술 리더는 경로 기반 라우팅(Path-Based Routing)과 순차적 게이트(Sequential Gates) 아키텍처를 사용하여 워크플로우를 구축할 수 있습니다 [8-10].
-*   **1단계 (자동화된 병합 전 검사):** 풀 리퀘스트 생성 시 린팅, 테스트, SAST 및 의존성 취약점 스캔이 병렬로 실행됩니다 [9].
-*   **2단계 (조건부 인간 리뷰 라우팅):** 자동화 검사를 통과한 후, 변경된 파일 경로(예: `auth/*`, `payment/*`)나 코드의 복잡성, 변경 규모에 따라 적절한 인간 리뷰어(시니어 엔지니어, 보안 전문가 등)에게 자동으로 리뷰를 요청합니다 [10].
-*   **3단계 (병합 활성화):** 자동화 상태 검사 통과 및 요구되는 인간의 승인이 모두 확보된 경우에만 코드 병합(Merge)이 허용됩니다 [10].
-
-**3. 보안 및 컴플라이언스 측면의 이점**
-산업 표준(NIST SSDF, SOC 2, PCI DSS 등)은 코드 리뷰와 분석을 모두 요구합니다 [11]. 하이브리드 리뷰는 자동화 도구가 알려진 취약점 패턴과 코드 정책(예: 비밀키 하드코딩 방지)을 강제하는 동시에, 수동 리뷰가 문맥별 규정 준수(예: 신용카드 필드가 보안 정책에 맞게 처리되는지 확인)를 검증하므로 강력한 감사 추적(Audit Trail)과 보안 태세를 제공합니다 [11, 12].
-
-**4. 주의해야 할 안티패턴**
-하이브리드 리뷰 시스템을 구현할 때 피해야 할 주요 안티패턴은 다음과 같습니다 [13].
-*   **오탐지 역설 (False Positive Paradox):** SAST 도구를 제대로 튜닝하지 않으면 너무 많은 오탐지가 발생해, 알림 피로(Alert fatigue)로 인해 개발자가 진짜 중요한 취약점마저 무시하게 됩니다 [2, 13].
-*   **자동화에 대한 과신:** 자동화 도구가 실제 취약점의 약 22%를 놓친다는 연구 결과가 있음에도 불구하고, 모든 검사가 끝났다고 착각하여 고위험 변경 사항에 대한 인간의 필수 리뷰를 생략하는 위험입니다 [13, 14].
-*   **녹색 체크마크 증후군 (Green Check Mark Syndrome):** 코드의 실질적 품질과 아키텍처 건전성을 이해하기보다는, 단순히 자동화 검사 통과를 위해 피상적인 수정(Superficial fixes)만 적용하는 현상입니다 [13, 15].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** AI 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[수동 코드 리뷰]], [[자동화된 코드 리뷰]], [[SAST (Static Application Security Testing)]]
-- **Projects/Contexts:** [[CI/CD 파이프라인]], [[순차적 게이트 아키텍처]]
-- **Contradictions/Notes:** 자동화 도구는 속도와 확장성 측면에서 훌륭하지만 비즈니스 로직과 의도를 파악하는 "문맥맹(Context Blindness)"의 한계가 있어 30~60%의 높은 오탐지율을 발생시키거나 특정 취약점(예: 신종 논리 공격)을 완전히 놓칠 수 있습니다. 따라서 오직 자동화에만 의존하는 것은 위험하며, 인간의 문맥 이해를 결합한 하이브리드 접근이 필수적이라고 소스들은 공통적으로 지적합니다 [2, 14].
-
----
-*Last updated: 2026-04-18*
-- Raw Source: [[00_Raw/2026-04-20/하이브리드 코드 리뷰.md]]
----
diff --git a/AI/할당 실패(Allocation Failure).md b/AI/할당 실패(Allocation Failure).md
deleted file mode 100644
index fe25cd28..00000000
--- a/AI/할당 실패(Allocation Failure).md	
+++ /dev/null
@@ -1,37 +0,0 @@
----
-id: P-REINFORCE-AUTO-32A771
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - 할당 실패(Allocation Failure)"
----
-
-# [[할당 실패(Allocation Failure)]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 할당 실패(Allocation Failure)는 애플리케이션이 새로운 객체를 생성하기 위해 메모리를 요청했으나, 현재의 메모리 공간(주로 New Space나 Java 객체 힙)에 연속된 여유 메모리가 충분하지 않을 때 발생하는 이벤트이다 [1, 2]. 이 실패 현상은 시스템이 메모리 요청을 충족시키기 위해 가비지 컬렉션(GC)을 강제로 실행하도록 만드는 가장 주요한 트리거(trigger) 역할을 한다 [1, 3]. V8 엔진이나 Java 가상 머신(JVM) 등에서 공통적으로 발생하며, 할당 실패가 감지되면 엔진은 즉시 Scavenge(마이너 GC) 또는 전역 GC 사이클을 시작하여 메모리를 확보한다 [4, 5].
-
-## 📖 구조화된 지식 (Synthesized Content)
-*   **발생 원인과 메커니즘**
-    애플리케이션이 새 객체를 메모리에 할당하려고 시도할 때, 메모리 할당 포인터가 New Space(또는 Nursery 영역)의 경계에 도달하여 요구하는 만큼의 충분한 연속 여유 공간을 찾지 못하면 할당 실패가 발생한다 [1, 4, 5]. Java 환경의 경우, Java 객체 힙에 사용 가능한 메모리가 충분하지 않아 프로그램의 메모리 할당 요청이 거부될 때 발생하는 현상으로 정의된다 [2].
-
-*   **가비지 컬렉션(GC) 사이클 촉발**
-    할당 실패는 메모리 관리를 위해 가비지 컬렉터를 가동하는 핵심적인 내부 메커니즘이다 [3]. V8 엔진의 경우 New Space에서 할당 실패가 발생하면 즉시 'Scavenge'라 불리는 마이너 가비지 컬렉션 사이클을 트리거한다 [5]. 시스템은 애플리케이션의 후속 코드 실행을 재개하기 전에 반드시 GC를 강제로 실행하여 쓸모없는 객체를 치우고 여유 메모리 공간을 먼저 확보해야만 한다 [1].
-
-*   **로깅(Logging) 및 모니터링**
-    `--trace-gc` 플래그 등을 통해 출력되는 런타임 힙 로그에서, 할당 실패는 GC 이벤트가 발생한 '이유(Reason)' 항목으로 명확하게 기록된다 [1, 6]. IBM Java 환경의 상세 GC 로그(Verbose GC logs)에서도 `<af-start>`라는 XML 요소를 사용하여 할당 실패에 의한 GC 트리거 시작을 기록한다 [2]. 개발자는 이러한 기록을 분석하여 할당 타이밍과 애플리케이션의 메모리 부족(Memory pressure) 상태를 파악할 수 있다 [1, 7]. 또한, 전역 GC 사이클을 트리거한 최근의 할당 실패 작업이 힙을 압축(compact)하지 않았을 경우, 이후 명시적인 GC 요청 시 힙 압축을 유발하는 조건으로 작용하기도 한다 [8].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** AI 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** `[[가비지 컬렉션(Garbage Collection)]]`, `[[Scavenge(마이너 GC)]]`, `[[New Space(Young Generation)]]`
-- **Projects/Contexts:** `[[V8 자바스크립트 엔진의 메모리 관리 메커니즘]]`, `[[IBM Java 가상 머신(JVM)의 가비지 컬렉션 로깅 분석]]`
-- **Contradictions/Notes:** 소스 간의 모순점은 발견되지 않았으며, 할당 실패는 V8 엔진과 Java JVM 환경 모두에서 연속된 여유 메모리가 부족할 때 가비지 컬렉션을 즉각적으로 유발하는 동일한 트리거 원리로 일관되게 설명되고 있다.
-
----
-*Last updated: 2026-04-19*
-- Raw Source: [[00_Raw/2026-04-20/할당 실패(Allocation Failure).md]]
----
diff --git a/AI/함수 호출 (Function Calling).md b/AI/함수 호출 (Function Calling).md
deleted file mode 100644
index 38b59906..00000000
--- a/AI/함수 호출 (Function Calling).md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-34CE7C
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - 함수 호출 (Function Calling)"
----
-
-# [[함수 호출 (Function Calling)]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** AI 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/함수 호출 (Function Calling).md]]
----
diff --git a/AI/힙 스냅샷(Heap Snapshot).md b/AI/힙 스냅샷(Heap Snapshot).md
deleted file mode 100644
index 318b57c8..00000000
--- a/AI/힙 스냅샷(Heap Snapshot).md	
+++ /dev/null
@@ -1,47 +0,0 @@
----
-id: P-REINFORCE-AUTO-BE247C
-category: "[[10_Wiki/💡 Topics/AI]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - 힙 스냅샷(Heap Snapshot)"
----
-
-# [[힙 스냅샷(Heap Snapshot)]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-*   **작동 원리 및 고유 ID 식별:**
-    *   힙 스냅샷은 글로벌 객체(Global Object)에서 도달할 수 있는(Reachable) 객체들만 캡처하며, 캡처를 시작할 때 항상 가비지 컬렉션을 먼저 수행하여 살아있는 객체만 남깁니다 [5].
-    *   스냅샷 내의 각 객체에는 `@` 기호 뒤에 고유 ID(예: `@12345`)가 부여됩니다 [6, 7]. 이 ID는 가비지 컬렉션 중 객체의 메모리 주소가 변경되더라도 여러 스냅샷 세션 간에 동일하게 유지되므로, 힙 상태를 객체 단위로 정확히 비교할 수 있게 해줍니다 [6-10].
-
-*   **메모리 크기 측정 방식:**
-    *   **Shallow Size (얕은 크기):** 객체 자체가 차지하는 메모리 크기입니다. 일반적으로 배열과 문자열이 큰 얕은 크기를 가집니다 [11].
-    *   **Retained Size (보존된 크기):** 해당 객체를 삭제하여 그에 종속된 객체들이 더 이상 도달할 수 없게(Unreachable) 될 때 확보할 수 있는 최대 메모리 크기입니다 [11].
-
-*   **동작 상세 로그 추적을 위한 주요 분석 뷰(Views):**
-    *   **Summary (요약 뷰):** 생성자(Constructor) 이름별로 객체를 그룹화하여 보여주며, 분리된 DOM 노드(Detached DOM nodes)와 같은 누수를 추적하는 데 유용합니다 [4, 12, 13].
-    *   **Comparison (비교 뷰):** 특정 작업(예: 모달 열기/닫기) 전후로 캡처한 두 스냅샷 간의 차이점(Delta)을 보여주어, 해제되지 않고 새로 추가된 객체를 통해 메모리 누수를 확인합니다 [1, 3, 4, 14, 15].
-    *   **Containment (포함 뷰):** 애플리케이션의 객체 구조를 조감도(Bird's eye view)처럼 보여주어 클로저(Closure) 내부나 GC 루트(Roots)를 분석할 수 있습니다 [4, 15].
-    *   **Retainers (보유자 패널):** 특정 객체를 참조하여 메모리에 살아있게 만드는 참조 체인(Chain of references)을 보여줍니다 [1, 16]. 이 체인을 거슬러 올라가면 누수의 근본 원인을 찾을 수 있습니다 [1].
-
-*   **분석 시 주의 사항(Gotchas):**
-    *   원시 힙에는 수천 개의 V8 내부 객체(예: `(compiled code)`, `system / Context`)가 포함되어 있으므로, 애플리케이션의 객체에 집중하려면 "Constructor" 필터를 사용해야 합니다 [17-19].
-    *   코드 축소(Minification)로 인해 참조 체인을 읽기 어려울 수 있으므로, 소스 맵(Source Maps)을 사용하거나 익명 함수 대신 기명 함수를 사용하여 클로저를 쉽게 식별할 수 있도록 해야 합니다 [17, 20].
-    *   숫자와 같은 비문자열 값이나 네이티브 코드를 실행하는 Getter로 구현된 속성들은 자바스크립트 힙에 저장되지 않아 캡처되지 않을 수 있습니다 [12].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** AI 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[메모리 누수(Memory Leak)]], [[가비지 컬렉션(Garbage Collection)]], [[Allocation Timeline]]
-- **Projects/Contexts:** [[Chrome DevTools Memory Panel]], [[V8 Engine Heap Management]]
-- **Contradictions/Notes:** 메모리 그래프가 증가한다고 해서 무조건 메모리 누수인 것은 아닙니다. 캐시(Caches), 실행 취소 내역, 가상화된 목록 버퍼 등은 의도적으로 데이터를 보존하므로 의도적인 메모리 보존과 사고에 의한 메모리 누수를 명확히 구별해야 합니다 [17]. 
-
----
-*Last updated: 2026-04-19*
-- Raw Source: [[00_Raw/2026-04-20/힙 스냅샷(Heap Snapshot).md]]
----
diff --git a/API_Communication_Patterns.md b/API_Communication_Patterns.md
deleted file mode 100644
index 07b8125c..00000000
--- a/API_Communication_Patterns.md
+++ /dev/null
@@ -1,26 +0,0 @@
----
-title: 효율적인 API 통신 패턴 (Axios & Interceptors)
-category: Software Architecture
-tags: [API, Axios, Interceptor, Error Handling, Network]
-created: 2026-04-20
----
-
-# [[API_Communication_Patterns]] (API 통신 패턴)
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 서버와의 대화는 항상 '정중하되 의심하며' 처리하라. 모든 요청은 중앙 통제소(Interceptor)를 거치고 모든 에러는 시나리오가 준비되어 있어야 한다.
-
-## 📖 구조화된 지식 (Synthesized Content)
-- **Service Layer (서비스 레이어) 추상화**:
-    - 컴포넌트 내에 `axios` 코드를 기생시키지 마라. `userService.js`, `productApi.js` 처럼 API별로 모듈화하여 컴포넌트는 오직 '함수 호출'만 알게 하라.
-- **Axios Interceptors (심사 통로)**:
-    - 모든 요청에 인증 토큰을 자동으로 붙이거나, 백엔드에서 내려오는 401 에러를 가로채서 자동으로 토큰을 갱신(Silent Refresh)하는 로직을 중앙 집권화한다.
-- **Error Scenario Planning**:
-    - 400(잘못된 요청), 403(권한 없음), 500(서버 죽음) 등 각 에러 코드별로 사용자가 경험할 UI 처리 방침을 미리 약속하라.
-
-## ⚠️ 모순 및 업데이트 (RL Update)
-- 모든 통신에 Axios가 정답은 아니다. 브라우저 네이티브인 `fetch`로도 충분한 경우가 많으며, 라이브러리 의존성을 낮추는 것이 가벼운 앱을 만드는 첫걸음일 수 있다.
-
-## 🔗 지식 연결 (Graph)
-- Related: [[System_Protocol_Standard]] , [[React_State_Management_Strategy]]
-- Foundation: [[Reliability_Safety_First]]
diff --git a/Accessibility_Inclusivity.md b/Accessibility_Inclusivity.md
deleted file mode 100644
index c6af0e18..00000000
--- a/Accessibility_Inclusivity.md
+++ /dev/null
@@ -1,26 +0,0 @@
----
-title: 웹 접근성 및 포용적 설계 (a11y)
-category: Software Architecture
-tags: [Accessibility, a11y, Semantic HTML, Inclusivity]
-created: 2026-04-20
----
-
-# [[Accessibility_Inclusivity]] (포용적 설계와 접근성)
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 웹은 '모두'를 위한 공간이어야 한다. 신체적 제약이 시스템 이용의 제약이 되지 않게 하는 것은 '매너'가 아니라 전문 개발자의 '책임'이다.
-
-## 📖 구조화된 지식 (Synthesized Content)
-- **Semantic HTML (의미론적 태그)**:
-    - `<div>`로만 도배하지 마라. `<main>`, `<article>`, `<section>`, `<nav>` 등 의미가 담긴 태그를 써야 기계(스크린 리더)와 검색 엔진이 내 콘텐츠의 중요도를 파악한다.
-- **ARIA & States**:
-    - 표준 HTML로 설명이 불가능한 인터랙션(예: 커스텀 탭 메뉴)은 `aria-label`, `aria-hidden` 등을 통해 기계에게 보조 설명을 전한다.
-- **Keyboard Navigation**:
-    - 마우스 없이 `Tab` 키와 `Enter` 키만으로 내 앱의 모든 핵심 기능을 수행할 수 있는지 검증하라. 포커스링을 숨기지 마라. 누군가에게는 유일한 가이드라인이다.
-
-## ⚠️ 모순 및 업데이트 (RL Update)
-- 접근성을 챙기는 것은 단순히 윤리적인 문제를 넘어, **SEO(검색 노출)** 성적과 직결된다. 구글 검색 로봇은 눈이 없기에, 스크린 리더와 유사한 방식으로 우리 사이트를 평가하기 때문이다.
-
-## 🔗 지식 연결 (Graph)
-- Related: [[Styling_Governance]] , [[React_Clean_Code_Best_Practices]]
-- Ethic: [[Collaboration_Governance]]
diff --git a/Automation & Industry/3D Web-based HMI.md b/Automation & Industry/3D Web-based HMI.md
deleted file mode 100644
index 59378a78..00000000
--- a/Automation & Industry/3D Web-based HMI.md	
+++ /dev/null
@@ -1,34 +0,0 @@
----
-id: P-REINFORCE-AI-074AE7
-category: "[[10_Wiki/💡 Topics/Automation & Industry]]"
-confidence_score: 0.95
-tags: []
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Batch 9 - Wikified 3D Web-based HMI"
----
-
-# [[3D Web-based HMI]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 3D Web-based HMI는 사용자가 기계 또는 자동화 시스템과 통신할 수 있도록 지원하는 소프트웨어 인터페이스로, 주로 SCADA(Supervisory Control and Data Acquisition) 시스템의 기기 모니터링 및 제어를 위한 디스플레이 역할을 수행합니다 [1, 2]. 기존 HMI 시스템의 특정 플랫폼 종속성과 별도의 소프트웨어 설치 요구라는 한계를 극복하기 위해 제안되었습니다 [3]. WebGL과 WebSocket 기술을 활용하여 사용자는 별도의 소프트웨어 설치 없이 모든 플랫폼의 HTML5 웹 브라우저에서 실시간 데이터 통신 및 3D 그래픽 렌더링을 경험할 수 있습니다 [3-5].
-
-## 📖 구조화된 지식 (Synthesized Content)
-* **도입 배경 및 기존 HMI의 한계:** 공장 및 빌딩 자동화 분야에서 널리 쓰이는 SCADA 시스템의 벤더들은 전통적으로 독점적인 HMI 소프트웨어를 제공해 왔습니다 [2]. 예를 들어, 상용 제품인 Genesis64의 GraphWorX64 컴포넌트는 Windows 운영 체제, .NET Framework, DirectX 설치 및 Internet Explorer 사용을 강제하는 플랫폼 종속적인 한계가 있었습니다 [6, 7]. 3D Web-based HMI는 이러한 문제점을 극복하고자 웹 기술을 바탕으로 고안되었습니다 [2, 3].
-* **핵심 렌더링 및 통신 기술:** 3D Web-based HMI는 OpenGL ES 2.0을 기반으로 하는 크로스 플랫폼 웹 그래픽 라이브러리인 WebGL을 사용하여 3D 장면을 구성합니다 [4]. 저수준 API인 WebGL의 복잡성을 줄이기 위해 Three.js 라이브러리의 `WebGLRenderer()`를 활용하며, 화면 주사율에 맞춰 자연스러운 애니메이션을 처리하기 위해 `RequestAnimationFrame()`을 사용합니다 [4, 8]. 데이터 통신 측면에서는 HTTP 대신 WebSocket을 사용하여 서버와 클라이언트 간의 데이터가 빠르게 변경되는 상황에서도 효율적으로 대처할 수 있습니다 [3].
-* **초당 프레임 수(FPS) 성능:** 상용 3D HMI 제품(GraphWorX64)과 성능을 비교 평가한 결과, 3D Web-based HMI는 브라우저(Internet Explorer 및 Chrome) 환경에서 큐브(Cube) 개수가 0.5K~0.8K일 때 목표 최대 성능인 60 FPS를 안정적으로 유지했습니다 [1, 9]. 큐브 개수가 증가하여 1.1K~1.6K에 도달했을 때는 인간의 눈이 프레임 건너뛰기를 감지하지 못하는 최소 기준인 30 FPS를 기록했습니다 [1, 9, 10].
-* **프레임 지연 시간(Frame Time Latency) 및 디스플레이 품질:** FPS가 높더라도 프레임 시간이 불규칙하면 화면 끊김(Stuttering)이 발생할 수 있습니다 [10]. 실험 결과, 3D Web-based HMI는 객체가 5K에 이를 때까지 상용 제품보다 각 프레임을 렌더링하는 데 걸리는 시간 편차가 적어 훨씬 부드럽고 일관된 디스플레이를 제공했습니다 [1, 11, 12]. 
-* **시스템 리소스 소모:** CPU 사용량은 약 40%, 메모리 사용량은 약 180MB 수준으로 상용 HMI(약 240MB)보다 메모리를 더 적게 사용하여 안정적인 모습을 보였습니다 [5, 13]. 다만 GPU 사용량은 상용 제품과 비교했을 때 평균적으로 약 5% 정도 더 높게 나타났습니다 [5, 13].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 신규 문서로, 기존 정보와의 충돌 분석 예정.
-- **정책 변화:** Automation & Industry 카테고리의 지식 연결망 강화를 위한 표준 위키화 적용.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[SCADA]], [[WebGL]], [[Three.js]], [[WebSocket]], [[Frame Time Latency]]
-- **Projects/Contexts:** [[Genesis64 상용 제품과의 웹 기반 3D 렌더링 성능 벤치마크]]
-- **Contradictions/Notes:** 3D Web-based HMI는 프레임의 부드러움(일관성)에서는 상용 제품보다 뛰어나지만, 전체 프로세스 소요 시간 중 약 96% 이상이 객체를 생성하는 실행 시간(Execution Time)이 아닌 렌더링 시간(Rendering Time)에 집중되어 있습니다. 이는 향후 렌더링 코드 최적화를 통해 성능을 더욱 개선해야 할 주요 병목 지점임을 시사합니다 [9, 14].
-
----
-*Last updated: 2026-04-19*
-- Raw Source: [[00_Raw/2026-04-20/3D Web-based HMI.md]]
----
diff --git a/Automation/IoT.md b/Automation/IoT.md
deleted file mode 100644
index 87d8b658..00000000
--- a/Automation/IoT.md
+++ /dev/null
@@ -1,29 +0,0 @@
----
-id: P-REINFORCE-AUTO-002
-category: "[[10_Wiki/💡 Topics/Automation]]"
-confidence_score: 0.91
-tags: [automation, iot, telemetry, connectivity]
-last_reinforced: 2026-04-20
-github_commit: "batch-reinforce-07"
----
-
-# [[Internet of Things (IoT) Telemetry]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 보이지 않는 물리 현상을 디지털 신호로 변환하여 네트워크로 송출함으로써 만물에 '말문'을 틔워주는 기술.
-
-## 📖 구조화된 지식 (Synthesized Content)
-- **추출된 패턴:** 센서 데이터 스트리밍, 게이트웨이 집계, 클라우드 분석으로 이어지는 엔드-투-엔드 데이터 흐름 패턴.
-- **세부 내용:**
-    - 저전력 광대역 네트워크(LPWAN)를 통한 광범위한 연결성 확보.
-    - MQTT, HTTP 등 경량화된 프로토콜을 사용한 실시간 텔레메트리 전송.
-    - 엣지 컴퓨팅(Edge Computing)을 통한 데이터 필터링 및 실시간성 강화.
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 단방향 데이터 수집에서 이제는 양방향 제어 및 실시간 자가 진단이 가능한 지능형 IoT로 진화.
-- **정책 변화:** 구조적 연결성(w2) 관점에서 Digital_Twin의 실시간성을 보장하는 핵심 인프라로 정의.
-
-## 🔗 지식 연결 (Graph)
-- **Parent:** [[10_Wiki/💡 Topics/Automation]]
-- **Related:** [[SCADA]], [[Digital_Twin]], [[Edge-Computing]]
-- **Raw Source:** [[00_Raw/2026-04-20/Internet of Things (IoT) Telemetry.md]]
diff --git a/Automation/SCADA.md b/Automation/SCADA.md
deleted file mode 100644
index ce72de7d..00000000
--- a/Automation/SCADA.md
+++ /dev/null
@@ -1,29 +0,0 @@
----
-id: P-REINFORCE-AUTO-001
-category: "[[10_Wiki/💡 Topics/Automation]]"
-confidence_score: 0.90
-tags: [automation, scada, industrial, control]
-last_reinforced: 2026-04-20
-github_commit: "batch-reinforce-06"
----
-
-# [[SCADA (Supervisory Control and Data Acquisition)]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 광범위한 산업 현장의 데이터를 실시간으로 수집하고 원격에서 제어함으로써 제조 지능화를 구현하는 중앙 통제 센터.
-
-## 📖 구조화된 지식 (Synthesized Content)
-- **추출된 패턴:** 현장 하드웨어(PLC/RTU)와 상위 관리 시스템을 연결하여 데이터 획득 및 시각적 감시를 통합하는 루프 제어 패턴.
-- **세부 내용:**
-    - 실시간 경보(Alarming) 및 데이터 로깅을 통한 장애 대응.
-    - HMI(Human-Machine Interface)와 결합하여 운영자에게 직관적 조작 환경 제공.
-    - 산업용 통신 프로토콜(Modbus, OPC-UA 등) 기반의 상호 운용성 확보.
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 고립된 폐쇄망 기반 시스템에서 현재는 클라우드 및 AI와 결합한 '개방형 스마트 팩토리' 모델로 진화.
-- **정책 변화:** 구조적 연결성(w2) 관점에서 3D_Web_HMI 및 Digital_Twin과의 데이터 정합성 강조.
-
-## 🔗 지식 연결 (Graph)
-- **Parent:** [[10_Wiki/💡 Topics/Automation]]
-- **Related:** [[3D_Web_HMI]], [[Digital_Twin]], [[Industrial-IoT]]
-- **Raw Source:** [[00_Raw/2026-04-20/Industrial-Automation.md]]
diff --git a/Coding/AST_Traversal.md b/Coding/AST_Traversal.md
deleted file mode 100644
index f816aa25..00000000
--- a/Coding/AST_Traversal.md
+++ /dev/null
@@ -1,29 +0,0 @@
----
-id: P-REINFORCE-CODING-001
-category: "[[10_Wiki/💡 Topics/Coding]]"
-confidence_score: 0.92
-tags: [coding, ast, compiler]
-last_reinforced: 2026-04-20
-github_commit: "batch-reinforce-01"
----
-
-# [[Abstract Syntax Tree Traversal]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 소스 코드의 추상적인 구조를 정의된 규칙에 따라 탐색하며 변환 및 분석의 기틀을 마련하는 컴파일러의 핵심 여정.
-
-## 📖 구조화된 지식 (Synthesized Content)
-- **추출된 패턴:** 비지터 패턴(Visitor Pattern)을 활용하여 데이터 구조와 알고리즘을 분리하고 트리 노드를 순회하는 재귀적 처리 패턴.
-- **세부 내용:**
-    - 전위/중위/후위 순회를 통한 코드 분석 시점 최적화.
-    - 정적 분석 및 린팅(Linting) 툴의 기초 로직 제공.
-    - 리팩토링 및 코드 자동 생성 도구의 엔진 역할.
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 단순 텍스트 기반 검색과 달리 문맥(Context)을 이해하는 구조적 접근의 필수성 강조.
-- **정책 변화:** 코딩 표준(w1) 강화에 따라 AST 기반 자동 수정 가중치 상향.
-
-## 🔗 지식 연결 (Graph)
-- **Parent:** [[10_Wiki/💡 Topics/Coding]]
-- **Related:** [[CST]], [[Parser]], [[Visitor-Pattern]]
-- **Raw Source:** [[00_Raw/2026-04-20/Abstract-Syntax-Tree-Traversal.md]]
diff --git a/Coding/CST.md b/Coding/CST.md
deleted file mode 100644
index 8d320118..00000000
--- a/Coding/CST.md
+++ /dev/null
@@ -1,29 +0,0 @@
----
-id: P-REINFORCE-CODING-002
-category: "[[10_Wiki/💡 Topics/Coding]]"
-confidence_score: 0.95
-tags: [coding, cst, compiler, parsing]
-last_reinforced: 2026-04-20
-github_commit: "batch-reinforce-06"
----
-
-# [[Concrete Syntax Tree (CST)]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 소스 코드의 문법적 구조를 생략 없이 문자 그대로 담아내어, 텍스트와 의미 사이의 가교 역할을 하는 정밀한 기록.
-
-## 📖 구조화된 지식 (Synthesized Content)
-- **추출된 패턴:** 구두점, 공백, 키워드 등 코드의 모든 텍스트 요소를 노드로 보존하여 파싱 트리를 구성하는 패턴.
-- **세부 내용:**
-    - AST(추상 구문 트리)와 달리 원본 소스로의 완벽한 복원이 가능함.
-    - 서식 보존 리팩토링(Fidelity-preserving Refactoring) 도구의 근간.
-    - 파서 생성기(ANTLR 등)에서 소스 코드의 물리적 배치를 분석할 때 활용.
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 효율성을 위해 세부 정보를 생략하는 AST와 정보량 측면에서 상보적 관계를 형성.
-- **정책 변화:** 지식 연결성(w2) 관점에서 AST 문서와 1:1 비교 분석 구도 형성.
-
-## 🔗 지식 연결 (Graph)
-- **Parent:** [[10_Wiki/💡 Topics/Coding]]
-- **Related:** [[AST_Traversal]], [[Parser]], [[Formatting-Tools]]
-- **Raw Source:** [[00_Raw/2026-04-20/Concrete Syntax Tree (CST).md]]
diff --git a/Coding/Formatting.md b/Coding/Formatting.md
deleted file mode 100644
index ecdafca9..00000000
--- a/Coding/Formatting.md
+++ /dev/null
@@ -1,29 +0,0 @@
----
-id: P-REINFORCE-CODING-004
-category: "[[10_Wiki/💡 Topics/Coding]]"
-confidence_score: 0.93
-tags: [coding, formatting, style-guide, standard]
-last_reinforced: 2026-04-20
-github_commit: "batch-reinforce-07"
----
-
-# [[Code Formatting (코드 정제 표준)]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 코드의 의미를 바꾸지 않으면서 가독성과 협업의 효율성을 극대화하는 '시각적 문법'의 정립.
-
-## 📖 구조화된 지식 (Synthesized Content)
-- **추출된 패턴:** CST(구체 구문 트리)의 정보를 보존하며 통일된 스타일 가이드에 따라 텍스트 배치를 재정렬하는 서식화 패턴.
-- **세부 내용:**
-    - Prettier, ESLint 등 도구를 활용한 자동화된 스타일 교정.
-    - 들여쓰기, 개행 규칙, 식별자 명명 규칙 등 팀 내 합의된 표준 준수.
-    - 코드 리뷰 시 로직에 집중할 수 있도록 서식 관련 논쟁 원천 차단.
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 개발자의 개성보다 협업을 위한 일관성(Consistency)의 가치를 우선시함.
-- **정책 변화:** 지식 구조(w2) 관점에서 CST 기반 리샘플링 가중치를 상향하여 위키 생성 표준에 반영.
-
-## 🔗 지식 연결 (Graph)
-- **Parent:** [[10_Wiki/💡 Topics/Coding]]
-- **Related:** [[CST]], [[Linting]], [[Clean-Code]]
-- **Raw Source:** [[00_Raw/2026-04-20/Code Formatting.md]]
diff --git a/Coding/Parser.md b/Coding/Parser.md
deleted file mode 100644
index 19fbccb6..00000000
--- a/Coding/Parser.md
+++ /dev/null
@@ -1,29 +0,0 @@
----
-id: P-REINFORCE-CODING-003
-category: "[[10_Wiki/💡 Topics/Coding]]"
-confidence_score: 0.97
-tags: [coding, scaling, compiler, parser, typescript]
-last_reinforced: 2026-04-20
-github_commit: "batch-reinforce-07"
----
-
-# [[Parser (구문 분석기)]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 텍스트의 나열을 의미 있는 구조(Tree)로 변환하여, 기계가 코드의 문법과 의도를 이해하게 만드는 지적 번역기.
-
-## 📖 구조화된 지식 (Synthesized Content)
-- **추출된 패턴:** 스캐너(Scanner/Lexer)가 생성한 토큰 스트림을 입력받아, 언어의 문법 규칙에 따라 CST 및 AST를 생성하는 재귀적 하강(Recursive Descent) 패턴.
-- **세부 내용:**
-    - TypeScript 사례: 선언적 문법 사양보다는 성능 최적화를 위해 손으로 작성된(Hand-written) 파서 선호.
-    - 에러 복구(Error Recovery) 메커니즘을 통해 불완전한 코드에서도 유효한 트리를 구성하는 능력.
-    - 바인더(Binder)와 연계하여 심볼 표를 구축하고 의미론적 분석의 토대 마련.
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 엄격한 문법 검사기에서, 현대의 IDE를 지탱하는 '유연하고 지능적인 정적 분석 도구'로 역할 확장.
-- **정책 변화:** 기술적 정확성(w1)을 위해 최신 파싱 알고리즘 가중치 반영 및 코딩 표준 연결.
-
-## 🔗 지식 연결 (Graph)
-- **Parent:** [[10_Wiki/💡 Topics/Coding]]
-- **Related:** [[AST_Traversal]], [[CST]], [[TypeScript-Architecture]]
-- **Raw Source:** [[00_Raw/2026-04-20/TypeScript-Compiler-Architecture.md]]
diff --git a/Collaboration_Governance.md b/Collaboration_Governance.md
deleted file mode 100644
index 6dbed316..00000000
--- a/Collaboration_Governance.md
+++ /dev/null
@@ -1,26 +0,0 @@
----
-title: 협업 가이드라인 및 코드 거버넌스
-category: Software Architecture
-tags: [Collaboration, PR, Code Review, Documentation, Governance]
-created: 2026-04-20
----
-
-# [[Collaboration_Governance]] (협업과 코드 품격)
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 코드는 혼자 쓰는 일기장이 아니라 함께 짓는 건축물이다. 동료의 시간을 아껴주는 문서화와 소통 방식이 당신의 가치를 증명한다.
-
-## 📖 구조화된 지식 (Synthesized Content)
-- **Pull Request (PR) 에티켓**:
-    - "이거 고쳤습니다"는 최악의 PR이다. 무엇을(What), 왜(Why), 어떻게(How) 했는지 명시하고 가능한 시각적 결과물(스크린샷, GIF)을 첨부하여 리뷰어의 인지 부하를 줄여라.
-- **Code Review Protocol**:
-    - P1(필수 반영), P2(권장), P3(질문/의견) 식으로 중요도를 표시하라. 비판은 날카롭게 하되 표현은 따뜻하게 하여 팀의 심리적 안정성을 유지하라.
-- **The Living Document**:
-    - 복잡한 비즈니스 로직이나 기묘한 버그 픽스는 반드시 주석이나 README에 '의도'를 남겨라. 주석은 '무엇을 하는지'가 아니라 '왜 이렇게 했는지'를 적는 곳이다.
-
-## ⚠️ 모순 및 업데이트 (RL Update)
-- 완벽한 거버넌스를 추구하느라 소통이 무거워지면 안 된다. 빠른 배포가 필요한 시점에는 '기술 부채'를 명문화하고 나중에 갚는 기민함(Agile)도 필요하다.
-
-## 🔗 지식 연결 (Graph)
-- Related: [[React_Clean_Code_Best_Practices]] , [[Deployment_Final_Gate]]
-- Foundation: [[System_Debugging_Protocol]]
diff --git a/Communication & Tech/Algorithmic Rhetoric.md b/Communication & Tech/Algorithmic Rhetoric.md
deleted file mode 100644
index 199a0519..00000000
--- a/Communication & Tech/Algorithmic Rhetoric.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-9E51FB
-category: "[[10_Wiki/💡 Topics/Communication & Tech]]"
-confidence_score: 0.95
-tags: []
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Batch 11 - Wikified Algorithmic Rhetoric"
----
-
-# [[Algorithmic Rhetoric]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 작업 중
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 신규 지식 카테고리화 및 연결성 강화.
-- **정책 변화:** Communication & Tech 분야의 지식 자산 보호 및 네트워크 확장.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Algorithmic Rhetoric.md]]
----
diff --git a/Component_Design_Patterns.md b/Component_Design_Patterns.md
deleted file mode 100644
index 11564c7a..00000000
--- a/Component_Design_Patterns.md
+++ /dev/null
@@ -1,28 +0,0 @@
----
-title: 컴포넌트 설계 패턴 (Atomic & Composition)
-category: Software Architecture
-tags: [Design Pattern, Atomic Design, Composition, Architecture]
-created: 2026-04-20
----
-
-# [[Component_Design_Patterns]] (컴포넌트 설계 패턴)
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 컴포넌트는 작을수록 강하고, 단순할수록 재사용성이 극대화된다. 복잡한 컴포넌트는 여러 개의 작고 순수한(Pure) 컴포넌트로 해체하라.
-
-## 📖 구조화된 지식 (Synthesized Content)
-- **Container-Presenter 패턴**:
-    - **Container**: 데이터(State, API)를 가져오고 관리하는 '머리'.
-    - **Presenter**: 오직 Props만 받아 화면을 그리는 '몸통'. 스타일과 UI 구조에만 집중하여 테스트 가능성을 높인다.
-- **Compound Components (복합 컴포넌트)**:
-    - `<Select><Option /></Select>` 처럼 부모와 자식이 상태를 공유하며 하나의 긴밀한 기능을 수행하는 패턴. 사용자가 UI 구조를 자유롭게 배치할 수 있게 유연성을 제공한다.
-- **Atomic Design (원자 중심 설계)**:
-    - Atom(버튼, 입력창) $\rightarrow$ Molecule(검색바) $\rightarrow$ Organism(헤더) $\rightarrow$ Template $\rightarrow$ Page. 
-    - 가장 하위의 Atom이 프로젝트 전반에서 동일한 디자인 언어인 '디자인 토큰'을 반영하게 한다.
-
-## ⚠️ 모순 및 업데이트 (RL Update)
-- 너무 과도한 컴포넌트 분할은 프로토타이핑 속도를 늦춘다. 처음에는 크게 짜고, 중복이 발생하거나 복잡도가 높아질 때 '사후적 리팩토링'을 통해 분리하는 것이 실무적으로 현명하다.
-
-## 🔗 지식 연결 (Graph)
-- Related: [[Project_Architecture_Guidelines]] , [[Styling_Governance]]
-- Design: [[Accessibility_Inclusivity]]
diff --git a/Computational Theory & Math/Graph Theory.md b/Computational Theory & Math/Graph Theory.md
deleted file mode 100644
index 9f90c778..00000000
--- a/Computational Theory & Math/Graph Theory.md	
+++ /dev/null
@@ -1,33 +0,0 @@
----
-id: P-REINFORCE-AI-055
-category: "[[10_Wiki/💡 Topics/Computational Theory & Math]]"
-confidence_score: 0.97
-tags: [graph theory, network science, graph algorithm, relationship]
-last_reinforced: 2026-06-XX
-github_commit: "[P-Reinforce] Processed Graph Theory."
----
-
-# [[Graph Theory]] (그래프 이론)
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 객체와 그들 사이의 관계를 노드(Vertex)와 엣지(Edge)로 모델링하여, 복잡한 네트워크 구조 내에서 최단 경로, 연결성, 커뮤니티 등을 수학적으로 분석하는 학문이다.
-
-## 📖 구조화된 지식 (Synthesized Content)
-- **정의:** 시스템을 단순한 데이터 집합이 아닌 '관계형 구조'로 보는 관점이다. 현대 AI/ML에서 관계를 이해하는 데 가장 기본적이며 강력한 모델링 도구이다.
-- **핵심 구성 요소:** 
-    1. **Vertex (노드):** 개체(Object) 자체. (예: 사용자, 상품).
-    2. **Edge (간선):** 노드 간의 관계(Relationship). (예: '구매했다', '친구이다').
-    3. **가중치 (Weight):** 엣지에 부여되는 값으로, 연결의 강도나 비용을 나타낸다.
-- **주요 알고리즘 및 응용:**
-    *   **최단 경로 (Shortest Path):** 다익스트라(Dijkstra's) 알고리즘 등을 사용하여 가장 효율적인 흐름 경로를 찾는다.
-    *   **커뮤니티 탐지 (Community Detection):** 그래프 내에서 상호 연결성이 높은 작은 그룹을 찾아내, 숨겨진 패턴이나 영향력을 분석하는 데 사용된다.
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 모든 현실의 관계가 깔끔한 '엣지'로 정의되지 않을 수 있다. 비정형적인 상호작용이나 시간적 맥락이 중요한 경우, 그래프에 추가적인 속성(Temporal Edge)을 부여하는 것이 필요하다.
-- **정책 변화:** Knowledge Graph (온톨로지)의 핵심 기반 이론이며, 단순한 관계를 넘어 '왜' 그런 관계가 성립했는지에 대한 근거(Provenance)까지 기록하는 방향으로 발전하고 있다.
-
-## 🔗 지식 연결 (Graph)
-- Parent: [[Knowledge Graphs]]
-- Related: [[Network Science]] , [[Cybernetics]] , [[Complex Adaptive Systems]]
-- Raw Source: [[00_Raw/Graph Theory.md]]
----
\ No newline at end of file
diff --git a/Computational Theory & Math/Information Theory.md b/Computational Theory & Math/Information Theory.md
deleted file mode 100644
index cf066d66..00000000
--- a/Computational Theory & Math/Information Theory.md	
+++ /dev/null
@@ -1,32 +0,0 @@
----
-id: P-REINFORCE-AI-052
-category: "[[10_Wiki/💡 Topics/Computational Theory & Math]]"
-confidence_score: 0.98
-tags: [information theory, shannon entropy, compression, information]
-last_reinforced: 2026-06-XX
-github_commit: "[P-Reinforce] Processed Information Theory."
----
-
-# [[Information Theory]] (정보 이론)
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 정보의 양과 질을 수학적으로 측정하는 학문으로, 불확실성을 감소시키는 정도를 '엔트로피'로 정의하여 데이터 압축, AI 모델의 효율성, 그리고 지식의 전달 과정을 정량화한다.
-
-## 📖 구조화된 지식 (Synthesized Content)
-- **핵심 개념:** 정보는 그 자체로 물리적인 실체가 아니며, 불확실성을 해소하는 과정에서 발생하는 '측정 가능한 엔트로피 감소'로 정의된다.
-- **주요 이론 및 공식:**
-    1. **엔트로피 (Entropy):** 시스템의 무질서도 또는 평균 정보량을 측정한다. 확률 분포가 균일할수록 엔트로피는 높아진다.
-    2. **상호 정보량 (Mutual Information):** 두 변수 간에 얼마나 많은 정보를 공유하는지를 측정한다. $I(X; Y)$로 표기하며, AI 모델의 특징 추출 과정에서 중요한 개념이다.
-- **응용 분야:**
-    *   **데이터 압축:** 데이터 중 엔트로피가 낮은 부분은 예측 가능하여 효율적으로 압축할 수 있다.
-    *   **머신러닝:** 정보 이론 기반 분류기는 입력 특성 간의 독립성을 측정하여 최적의 특징을 선택한다.
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 정보를 '양'으로만 볼 것이 아니라, 그 '질'(Contextual Meaning)이 더 중요하다는 점을 인지해야 한다. 단순한 양적 측정은 지식의 맥락(Semantic Grounding)을 놓치게 만든다.
-- **정책 변화:** 최근에는 LLM의 성능 평가에 단순히 Perplexity 같은 전통적인 엔트로피 개념뿐만 아니라, '일관성 (Coherence)'과 '사실 정확도'를 결합한 새로운 측정 지표가 요구되고 있다.
-
-## 🔗 지식 연결 (Graph)
-- Parent: [[Computational Thinking]]
-- Related: [[Shannon Entropy]] , [[Information-Architecture]] , [[AI 모델 평가]]
-- Raw Source: [[00_Raw/Information Theory.md]]
----
\ No newline at end of file
diff --git a/Computer Science & Math/Algebraic-Data-Types.md b/Computer Science & Math/Algebraic-Data-Types.md
deleted file mode 100644
index ece755b1..00000000
--- a/Computer Science & Math/Algebraic-Data-Types.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-A4D1B5
-category: "[[10_Wiki/💡 Topics/Computer Science & Math]]"
-confidence_score: 0.95
-tags: []
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Batch 11 - Wikified Algebraic-Data-Types"
----
-
-# [[Algebraic-Data-Types]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 작업 중
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 신규 지식 카테고리화 및 연결성 강화.
-- **정책 변화:** Computer Science & Math 분야의 지식 자산 보호 및 네트워크 확장.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Algebraic-Data-Types.md]]
----
diff --git a/Deployment_Final_Gate.md b/Deployment_Final_Gate.md
deleted file mode 100644
index 7196cc46..00000000
--- a/Deployment_Final_Gate.md
+++ /dev/null
@@ -1,26 +0,0 @@
----
-title: 배포 프로토콜 및 CI/CD 자동화
-category: Software Architecture
-tags: [Deployment, CI/CD, GitHub Actions, Vercel, DevOps]
-created: 2026-04-20
----
-
-# [[Deployment_Final_Gate]] (배포 및 자동화)
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 수동 배포는 '실버 불렛'이 아니라 '시한폭탄'이다. 인간의 손을 거치지 않는 자동화된 보급로만이 시스템의 영속성을 보장한다.
-
-## 📖 구조화된 지식 (Synthesized Content)
-- **CI (Continuous Integration)**:
-    - 코드가 저장소에 합쳐지기 전, 린트(Lint) 검사, 빌드 테스트, 유닛 테스트를 자동으로 수행하여 '오염된 코드'의 유입을 원천 차단한다.
-- **CD (Continuous Deployment)**:
-    - 검증된 코드를 실서버에 자동으로 릴리즈한다. `Vercel`, `Netlify` 같은 플랫폼은 브랜치별 '미리보기' 주소를 제공하여 배포 전 최종 검수를 돕는다.
-- **Environment Variables (보안 환경)**:
-    - `.env` 파일을 통한 민감 정보 격리는 기본 중의 기본이다. 깃허브에 API Key가 하나라도 노출되는 순간, 그 프로젝트는 보안적으로 사망한 것과 다름없다.
-
-## ⚠️ 모순 및 업데이트 (RL Update)
-- 무조건적인 '자동 배포'가 늘 정답은 아니다. 운영 단계에서는 '블루-그린 배포'나 '카나리 배포'처럼 트래픽을 조금씩 흘려보내며 안정성을 확인하는 고급 전략이 필요하다.
-
-## 🔗 지식 연결 (Graph)
-- Related: [[Modern_Environment_Ecosystem]] , [[Collaboration_Governance]]
-- Pre-requisite: [[React_Testing_Strategy]]
diff --git a/Design & Experience/AODA-Accessibility-for-Ontarians-with-Disabilities-Act.md b/Design & Experience/AODA-Accessibility-for-Ontarians-with-Disabilities-Act.md
deleted file mode 100644
index f322c82a..00000000
--- a/Design & Experience/AODA-Accessibility-for-Ontarians-with-Disabilities-Act.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-03FE7E
-category: "[[10_Wiki/💡 Topics/Design & Experience]]"
-confidence_score: 0.95
-tags: []
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Mega Batch - Wikified AODA-Accessibility-for-Ontarians-with-Disabilities-Act"
----
-
-# [[AODA-Accessibility-for-Ontarians-with-Disabilities-Act]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 핵심 요약 작업 진행 중
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 상세 구성 진행 중
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 지식 자산화 및 기존 네트워크 연동 단계.
-- **정책 변화:** Design & Experience 카테고리의 전문성 확보 및 링크 밀도 최적화.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/AODA-Accessibility-for-Ontarians-with-Disabilities-Act.md]]
----
diff --git a/Design & Experience/API 응답 및 상태 모델링 (State Modeling and API Responses).md b/Design & Experience/API 응답 및 상태 모델링 (State Modeling and API Responses).md
deleted file mode 100644
index 2aa68a8d..00000000
--- a/Design & Experience/API 응답 및 상태 모델링 (State Modeling and API Responses).md	
+++ /dev/null
@@ -1,40 +0,0 @@
----
-id: P-REINFORCE-AUTO-09EEF3
-category: "[[10_Wiki/💡 Topics/Design & Experience]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - API 응답 및 상태 모델링 (State Modeling and API Responses)"
----
-
-# [[API 응답 및 상태 모델링 (State Modeling and API Responses)]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> API 응답 및 상태 모델링은 애플리케이션에서 발생할 수 있는 네트워크 통신 결과나 UI의 변화 과정을 타입 시스템을 통해 안전하고 예측 가능하게 설계하는 기법이다 [1, 2]. 이 모델링은 주로 식별 가능한 유니온(Discriminated Unions)이나 명시적인 Result 객체를 활용하여 존재해서는 안 될 유효하지 않은 상태를 원천적으로 차단한다 [3, 4]. 궁극적으로 컴파일러가 모든 가능한 응답 상태를 검사(Exhaustiveness checking)하도록 강제함으로써, 런타임 버그를 줄이고 코드의 안정성과 가독성을 높여준다 [5-7].
-
-## 📖 구조화된 지식 (Synthesized Content)
-*   **식별 가능한 유니온(Discriminated Unions)을 활용한 응답 상태 구조화**
-    네트워크 통신이나 API 응답은 대체로 '로딩 중(loading)', '실패(failed)', '성공(success)'과 같이 명확히 구분되는 상태를 가진다 [8]. TypeScript에서는 `kind`나 `state`와 같은 공통된 리터럴 타입 판별자(Discriminator)를 사용하여 이런 상태들을 하나로 묶어 식별 가능한 유니온으로 모델링한다 [8-10]. 이를 통해 각 상태에 불가능한 속성 조합(예: 에러 상태인데 성공 데이터가 존재하는 등)이 생성되는 것을 방지하고 타입 안정성을 확보할 수 있다 [1, 3, 5].
-
-*   **상태 머신(State Machine)과 워크플로우 적용**
-    API 요청의 생명주기뿐만 아니라, 복잡한 폼 제출의 여러 단계(검증, 제출 중, 에러 등), 비동기 작업 패턴, 라우터 상태 또한 식별 가능한 유니온을 활용한 상태 머신으로 표현하기 적합하다 [3, 11-13]. 이 패턴을 `switch` 문과 함께 사용하면, 특정 상태가 새롭게 추가되었을 때 코드를 누락하는 실수를 방지하도록 컴파일러가 완전성 검사(Exhaustiveness checking)를 수행하여 런타임 오류를 예방한다 [5, 6, 14, 15].
-
-*   **예외 발생을 지양하는 Result 타입 기반 에러 모델링**
-    예상 가능한 애플리케이션의 오류를 단순히 `throw`를 이용해 예외(Exception)로 던지기보다는 성공 데이터(`Ok`) 또는 에러(`Err`/`Fail`)를 나타내는 명시적인 Result 타입 객체로 감싸서 반환하는 접근 방식이 권장된다 [4, 16-18]. 이 방식은 함수 시그니처만 보아도 어떠한 오류 응답이 발생할 수 있는지 사전에 파악할 수 있게 해주며, C# 같은 언어의 API 컨트롤러에서도 철저한 오류 검증을 위해 폭넓게 활용되곤 한다 [7, 19-22].
-
-*   **메타데이터를 통한 API 제어 흐름 분리**
-    내부 로직을 원활하게 디버깅하고 시스템의 옵저버빌리티를 높이기 위해, 응답 객체에 `_tag`와 같은 내부 식별용 메타데이터를 추가하여 상태를 정의하는 패턴도 사용된다 [23-25]. 이를 활용하면 클라이언트에서는 단순한 HTTP 상태 코드를 넘어, 각각의 메타데이터 값에 맞게 세밀한 맞춤형 제어 및 에러 처리를 수행할 수 있다 [25].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Design & Experience 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[식별 가능한 유니온 (Discriminated Unions)]], [[완전성 검사 (Exhaustiveness checking)]], [[Result 타입 (Result Type)]]
-- **Projects/Contexts:** [[상태 머신 (State Machine)]], [[오류 처리 아키텍처 (Error Handling Architecture)]]
-- **Contradictions/Notes:** API나 시스템의 에러 응답을 모델링할 때 'Result 타입'을 사용하는 방식에 대해 개발자 간의 이견이 존재한다. 예상된 실패를 Result로 강제 반환하면 실행 흐름이 예측 가능해진다는 찬성 측 주장이 있는 반면, 전역 예외 처리기(Global Exception Handler)를 사용하는 쪽이 예외를 단순히 위로 올려보낼 수 있어 불필요한 보일러플레이트 코드 및 과도한 제어 흐름 분기(`switch`문 등)를 줄이고 컨트롤러를 더 깔끔하게 유지할 수 있다는 반대 주장도 팽팽하게 맞선다 [7, 20, 26-31].
-
----
-*Last updated: 2026-04-18*
-- Raw Source: [[00_Raw/2026-04-20/API 응답 및 상태 모델링 (State Modeling and API Responses).md]]
----
diff --git a/Design & Experience/AST-Manipulation-Techniques.md b/Design & Experience/AST-Manipulation-Techniques.md
deleted file mode 100644
index cdb6d74c..00000000
--- a/Design & Experience/AST-Manipulation-Techniques.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-7C91FA
-category: "[[10_Wiki/💡 Topics/Design & Experience]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - AST-Manipulation-Techniques"
----
-
-# [[AST-Manipulation-Techniques]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Design & Experience 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/AST-Manipulation-Techniques.md]]
----
diff --git a/Design & Experience/Abstract-Syntax-Tree-Transformation.md b/Design & Experience/Abstract-Syntax-Tree-Transformation.md
deleted file mode 100644
index 4f9992b0..00000000
--- a/Design & Experience/Abstract-Syntax-Tree-Transformation.md	
+++ /dev/null
@@ -1,27 +0,0 @@
----
-id: P-REINFORCE-AST-TRANS
-category: "[[10_Wiki/💡 Topics/Design & Experience]]"
-confidence_score: 0.99
-tags: [AST, Abstract Syntax Tree, Transformation, Compiler, Babel]
-last_reinforced: 2026-04-20
----
-
-# [[Abstract-Syntax-Tree-Transformation]] (AST 변환)
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> "코드를 조각하듯 변형하라." 소스 코드를 트리 구조로 분해한 뒤, 특정 노드를 추가, 삭제, 수정하여 완전히 새로운 기능이 담긴 코드로 재생산하는 현대 개발 도구의 핵심 마술이다.
-
-## 📖 구조화된 지식 (Synthesized Content)
-- **Code Transpilation**:
-    - 최신 자바스크립트(ES6+)를 구형 브라우저에서도 돌아가게 하는 `Babel` 같은 도구가 AST 변환의 가장 대표적인 사례다.
-- **Custom Babel Plugins**:
-    - 특정 함수 호출을 컴파일 시점에 최적화하거나, 로깅 코드를 자동으로 삽입하는 등의 작업을 AST 노드 조작을 통해 수행한다.
-- **Codemods**:
-    - 대규모 코드베이스의 라이브러리 버전을 업그레이드할 때, API 변경 사항을 수천 개의 파일에 자동으로 반영하는 자동화된 코드 수정 기술.
-
-## ⚠️ 모순 및 업데이트 (RL Update)
-- 무분별한 AST 변환은 디버깅을 지옥으로 만든다. 실행되는 코드와 원본 소스 코드가 결합력을 잃기 때문이다. 따라서 `Source Map` 생성을 철저히 관리하여 변환 후에도 원본 위치를 추적할 수 있게 해야 한다.
-
-## 🔗 지식 연결 (Graph)
-- Related: [[Abstract-Syntax-Tree-Traversal]] , [[Custom-ESLint-Rules-Development]]
-- Foundation: [[Computational Theory & Math/Information Theory]]
diff --git a/Design & Experience/Abstract-Syntax-Tree-Traversal.md b/Design & Experience/Abstract-Syntax-Tree-Traversal.md
deleted file mode 100644
index 765720ed..00000000
--- a/Design & Experience/Abstract-Syntax-Tree-Traversal.md	
+++ /dev/null
@@ -1,27 +0,0 @@
----
-id: P-REINFORCE-AST-TRAVERSAL
-category: "[[10_Wiki/💡 Topics/Design & Experience]]"
-confidence_score: 0.99
-tags: [AST, Abstract Syntax Tree, Traversal, Visitor Pattern, Static Analysis]
-last_reinforced: 2026-04-20
----
-
-# [[Abstract-Syntax-Tree-Traversal]] (AST 순회)
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> "언어의 숲을 여행하는 지도 제작자." 코드의 나무(AST)를 뿌리부터 잎새까지 탐험하며, 특정 패턴(예: 변수 선언, 함수 호출)을 찾아내 분석하고 수집하는 행위다.
-
-## 📖 구조화된 지식 (Synthesized Content)
-- **Visitor Pattern**:
-    - AST의 각 노드 타입(FunctionDeclaration, Identifier 등)에 방문할 때 실행될 콜백 함수를 정의하여 순회 과정을 구조화하는 설계 패턴.
-- **Static Code Analysis**:
-    - 코드를 실행하지 않고 순회만 함으로써, 선언되지 않은 변수 사용, 도달할 수 없는 코드(Unreachable code) 등을 사전에 찾아내는 린팅(Linting)의 기반 기술.
-- **Scope Analysis**:
-    - 변수가 어디서 선언되고 어디까지 유효한지(Scope)를 파악하기 위해 트리 위아래를 오가며 참조 관계를 분석한다.
-
-## ⚠️ 모순 및 업데이트 (RL Update)
-- 트리가 너무 거대하면(수만 줄의 코드) 순회 성능이 급격히 저하된다. 이를 위해 필요한 노드만 선택적으로 방문하거나, 증분식(Incremental) 분석을 통해 변경된 부분만 다시 순회하는 최적화 전략이 실무 도구(ESLint 등)에 필수적이다.
-
-## 🔗 지식 연결 (Graph)
-- Related: [[Abstract-Syntax-Tree-Transformation]] , [[ESLint-Static-Analysis]]
-- Strategy: [[Reliability_Safety_First]]
diff --git a/Design & Experience/Accessibility (A11y).md b/Design & Experience/Accessibility (A11y).md
deleted file mode 100644
index 32760bea..00000000
--- a/Design & Experience/Accessibility (A11y).md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AI-99D2E0
-category: "[[10_Wiki/💡 Topics/Design & Experience]]"
-confidence_score: 0.95
-tags: []
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Batch 9 - Wikified Accessibility (A11y)"
----
-
-# [[Accessibility (A11y)]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 
-
-## 📖 구조화된 지식 (Synthesized Content)
-
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 신규 문서로, 기존 정보와의 충돌 분석 예정.
-- **정책 변화:** Design & Experience 카테고리의 지식 연결망 강화를 위한 표준 위키화 적용.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Accessibility (A11y).md]]
----
diff --git a/Design & Experience/Accessibility-Compliance-WCAG.md b/Design & Experience/Accessibility-Compliance-WCAG.md
deleted file mode 100644
index a68f4f81..00000000
--- a/Design & Experience/Accessibility-Compliance-WCAG.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-2801A2
-category: "[[10_Wiki/💡 Topics/Design & Experience]]"
-confidence_score: 0.95
-tags: []
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Batch 10 - Wikified Accessibility-Compliance-WCAG"
----
-
-# [[Accessibility-Compliance-WCAG]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 핵심 내용 요약 예정
-
-## 📖 구조화된 지식 (Synthesized Content)
-세부 본문 내용 구성 예정
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 신규 지식 유입에 따른 기존 지식과의 정합성 검증 단계.
-- **정책 변화:** Design & Experience 분야의 체계적 지식 자산화 진행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Accessibility-Compliance-WCAG.md]]
----
diff --git a/Design & Experience/Additive-Type-Logic.md b/Design & Experience/Additive-Type-Logic.md
deleted file mode 100644
index b5690afe..00000000
--- a/Design & Experience/Additive-Type-Logic.md	
+++ /dev/null
@@ -1,27 +0,0 @@
----
-id: P-REINFORCE-AI-ADDITIVE-TYPE
-category: "[[10_Wiki/💡 Topics/Design & Experience]]"
-confidence_score: 0.97
-tags: [Type Theory, Additive Type Logic, TypeScript, Category Theory]
-last_reinforced: 2026-04-20
----
-
-# [[Additive-Type-Logic]] (가법 타입 논리)
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> "타입은 집합이다." 서로 다른 타입 지식을 더하여 더 크고 정교한 타입을 형성하고, 이를 통해 런타임 오류 가능성을 원천 봉쇄하는 조합론적 타입 설계 철학이다.
-
-## 📖 구조화된 지식 (Synthesized Content)
-- **Union Types (|)**:
-    - "A이거나 B일 수 있는" 집합의 합집합 개념. 다형성(Polymorphism)을 안전하게 구현하는 기초다.
-- **Intersection Types (&)**:
-    - "A이면서 동시에 B여야 하는" 집합의 교집합 개념. 여러 기능을 가진 믹스인(Mixin) 객체를 정의할 때 강력하다.
-- **Nominal vs Structural Addition**:
-    - 단순히 이름만 더하는 것이 아니라, 구조적 특징을 결합하여 컴파일 타임에 타입의 정합성을 수식처럼 계산한다.
-
-## ⚠️ 모순 및 업데이트 (RL Update)
-- 과도한 타입 덧셈(Intersection)은 타입 추론 속도를 늦추고 에러 메시지를 난해하게 만든다. 특히 무한 재귀적인 타입 결합은 컴파일러가 포기하게 만들 수 있으므로, `Interface Extension`을 통해 적절히 계층화하는 설계가 권장된다.
-
-## 🔗 지식 연결 (Graph)
-- Related: [[TypeScript-Advanced-Type-System-Design]] , [[Category_Theory]]
-- Foundation: [[Computational Theory & Math/Information Theory]]
diff --git a/Design & Experience/Affective User Interfaces (AUI).md b/Design & Experience/Affective User Interfaces (AUI).md
deleted file mode 100644
index b426e43f..00000000
--- a/Design & Experience/Affective User Interfaces (AUI).md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-30D321
-category: "[[10_Wiki/💡 Topics/Design & Experience]]"
-confidence_score: 0.95
-tags: []
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Batch 10 - Wikified Affective User Interfaces (AUI)"
----
-
-# [[Affective User Interfaces (AUI)]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 핵심 내용 요약 예정
-
-## 📖 구조화된 지식 (Synthesized Content)
-세부 본문 내용 구성 예정
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 신규 지식 유입에 따른 기존 지식과의 정합성 검증 단계.
-- **정책 변화:** Design & Experience 분야의 체계적 지식 자산화 진행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Affective User Interfaces (AUI).md]]
----
diff --git a/Design & Experience/Agency-in-Game-Design.md b/Design & Experience/Agency-in-Game-Design.md
deleted file mode 100644
index 68074e80..00000000
--- a/Design & Experience/Agency-in-Game-Design.md	
+++ /dev/null
@@ -1,27 +0,0 @@
----
-id: P-REINFORCE-AI-AGENCY
-category: "[[10_Wiki/💡 Topics/Design & Experience]]"
-confidence_score: 0.98
-tags: [Agency, Game Design, Player Choice, Narrative, Ludology]
-last_reinforced: 2026-04-20
----
-
-# [[Agency-in-Game-Design]] (게임 디자인에서의 에이전시)
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> "내가 한 행동이 세상을 바꿨다." 플레이어가 자신의 의지대로 선택을 내리고, 그 선택이 게임의 상태나 서사에 유의미한 변화를 일으킬 때 발생하는 강력한 몰입의 근원이다.
-
-## 📖 구조화된 지식 (Synthesized Content)
-- **Meaningful Choice**:
-    - 단순히 버튼을 누르는 것이 아니라, 결과가 예측 가능하면서도 결과에 대한 책임을 느낄 수 있는 선택의 설계.
-- **Feedback Loops**:
-    - 플레이어의 행동(Input)에 대해 게임 세계가 즉각적이고 가시적(시각/청각/서사적)으로 반응하여 '영향력'을 확인시켜 주는 과정.
-- **Ludonarrative Synergie**:
-    - 게임의 조작(메카닉)과 이야기(내러티브)가 같은 방향으로 에이전시를 발휘할 때 발생하는 일체감.
-
-## ⚠️ 모순 및 업데이트 (RL Update)
-- '에이전시의 환상'도 기술이다. 사실은 정해진 길을 가고 있어도, 마치 자신이 선택한 것처럼 느끼게 만드는 레벨 디자인의 기교(Invisible hand)가 플레이어의 스트레스를 줄이면서 만족감을 극대화한다.
-
-## 🔗 지식 연결 (Graph)
-- Related: [[BioShock (2007)]] , [[Ludo-Narrative-Dissonance]]
-- Context: [[Immersive-Sim-Genre]]
diff --git a/Design & Experience/Agent Communication Protocol (에이전트 통신 규약).md b/Design & Experience/Agent Communication Protocol (에이전트 통신 규약).md
deleted file mode 100644
index 118e751e..00000000
--- a/Design & Experience/Agent Communication Protocol (에이전트 통신 규약).md	
+++ /dev/null
@@ -1,27 +0,0 @@
----
-id: P-REINFORCE-AI-AGENT-PROTOCOL
-category: "[[10_Wiki/💡 Topics/Design & Experience]]"
-confidence_score: 0.99
-tags: [Agent Protocol, AI Agents, Communication, Multi-Agent System]
-last_reinforced: 2026-04-20
----
-
-# [[Agent-Communication-Protocol-(에이전트-통신-규약)]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> "기계끼리 대화하는 법." 서로 다른 제작자나 목적을 가진 AI 에이전트들이 정보를 공유하고 협력하기 위해 지켜야 할 약속된 언어와 절차적 문법이다.
-
-## 📖 구조화된 지식 (Synthesized Content)
-- **Message Semantics**:
-    - "무엇을(Action)", "어떤 정보로(Data)", "어떤 상태에서(Context)" 요청하는지에 대한 표준화된 구조(예: JSON-RPC, MCP).
-- **Handshake & Auth**:
-    - 연결 시작 시 서로의 신원과 권한을 확인하고, 통신 암호화 방식을 합의하는 신뢰 구축 프로토콜.
-- **Error Propagation**:
-    - 한 에이전트에서 발생한 오류가 전체 시스템으로 번지지 않도록 에러 코드를 표준화하고 예외 상황에 대한 전파 방식을 정의한다.
-
-## ⚠️ 모순 및 업데이트 (RL Update)
-- 과도하게 복잡한 프로토콜은 통신 지연(Latency)을 발생시킨다. 특히 LLM 기반 에이전트들은 텍스트 기반 소통을 하므로, 토큰 소모를 줄이면서도 의도를 정확히 전달하는 '압축된 프로토콜' 설계가 신기술의 핵심이다.
-
-## 🔗 지식 연결 (Graph)
-- Related: [[Multi-Agent-System-(다중-에이전트-시스템)]] , [[Distributed-Systems-Engineering]]
-- Context: [[P-Reinforce Knowledge Management System]]
diff --git a/Design & Experience/Agile-UX-Integration.md b/Design & Experience/Agile-UX-Integration.md
deleted file mode 100644
index 402c2a92..00000000
--- a/Design & Experience/Agile-UX-Integration.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-1363FF
-category: "[[10_Wiki/💡 Topics/Design & Experience]]"
-confidence_score: 0.95
-tags: []
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Batch 10 - Wikified Agile-UX-Integration"
----
-
-# [[Agile-UX-Integration]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 핵심 내용 요약 예정
-
-## 📖 구조화된 지식 (Synthesized Content)
-세부 본문 내용 구성 예정
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 신규 지식 유입에 따른 기존 지식과의 정합성 검증 단계.
-- **정책 변화:** Design & Experience 분야의 체계적 지식 자산화 진행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Agile-UX-Integration.md]]
----
diff --git a/Design & Experience/Americans-with-Disabilities-Act-ADA.md b/Design & Experience/Americans-with-Disabilities-Act-ADA.md
deleted file mode 100644
index dc856896..00000000
--- a/Design & Experience/Americans-with-Disabilities-Act-ADA.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-4B67E4
-category: "[[10_Wiki/💡 Topics/Design & Experience]]"
-confidence_score: 0.95
-tags: []
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Mega Batch - Wikified Americans-with-Disabilities-Act-ADA"
----
-
-# [[Americans-with-Disabilities-Act-ADA]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 핵심 요약 작업 진행 중
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 상세 구성 진행 중
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 지식 자산화 및 기존 네트워크 연동 단계.
-- **정책 변화:** Design & Experience 카테고리의 전문성 확보 및 링크 밀도 최적화.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Americans-with-Disabilities-Act-ADA.md]]
----
diff --git a/Design & Experience/Apple Human Interface Guidelines.md b/Design & Experience/Apple Human Interface Guidelines.md
deleted file mode 100644
index 63625da9..00000000
--- a/Design & Experience/Apple Human Interface Guidelines.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-35F340
-category: "[[10_Wiki/💡 Topics/Design & Experience]]"
-confidence_score: 0.95
-tags: []
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Mega Batch - Wikified Apple Human Interface Guidelines"
----
-
-# [[Apple Human Interface Guidelines]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 핵심 요약 작업 진행 중
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 상세 구성 진행 중
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 지식 자산화 및 기존 네트워크 연동 단계.
-- **정책 변화:** Design & Experience 카테고리의 전문성 확보 및 링크 밀도 최적화.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Apple Human Interface Guidelines.md]]
----
diff --git a/Design & Experience/Arkane-Studios.md b/Design & Experience/Arkane-Studios.md
deleted file mode 100644
index ee482f51..00000000
--- a/Design & Experience/Arkane-Studios.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-1A4850
-category: "[[10_Wiki/💡 Topics/Design & Experience]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Arkane-Studios"
----
-
-# [[Arkane-Studios]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Design & Experience 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Arkane-Studios.md]]
----
diff --git a/Design & Experience/Assignability-Rules.md b/Design & Experience/Assignability-Rules.md
deleted file mode 100644
index b37d7af4..00000000
--- a/Design & Experience/Assignability-Rules.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-DF407B
-category: "[[10_Wiki/💡 Topics/Design & Experience]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Assignability-Rules"
----
-
-# [[Assignability-Rules]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Design & Experience 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Assignability-Rules.md]]
----
diff --git a/Design & Experience/Assistive-Technology-Interoperability.md b/Design & Experience/Assistive-Technology-Interoperability.md
deleted file mode 100644
index 6351729f..00000000
--- a/Design & Experience/Assistive-Technology-Interoperability.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-6974BC
-category: "[[10_Wiki/💡 Topics/Design & Experience]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Assistive-Technology-Interoperability"
----
-
-# [[Assistive-Technology-Interoperability]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Design & Experience 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Assistive-Technology-Interoperability.md]]
----
diff --git a/Design & Experience/Atomic Design Pattern.md b/Design & Experience/Atomic Design Pattern.md
deleted file mode 100644
index b7a4dbb0..00000000
--- a/Design & Experience/Atomic Design Pattern.md	
+++ /dev/null
@@ -1,33 +0,0 @@
----
-id: P-REINFORCE-E24948
-category: "[[10_Wiki/💡 Topics/Design & Experience]]"
-confidence_score: 0.95
-tags: []
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Mega Batch 2 - Wikified Atomic Design Pattern"
----
-
-# [[Atomic Design Pattern]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> Atomic Design Pattern은 UI 컴포넌트의 역할과 계층을 분명하게 만들어 관심사를 분리하기 위해 도입된 계층 구조화 방법론입니다 [1]. 이는 단순히 컴포넌트의 이름이나 분리 그 자체보다, 복잡하게 얽혀 있던 컴포넌트들을 세밀한 기준에 따라 역할과 범주별로 쉽게 정돈할 수 있도록 돕는 역할을 합니다 [1].
-
-## 📖 구조화된 지식 (Synthesized Content)
-소스에 관련 정보가 부족합니다. 업로드된 문서에서는 해당 패턴에 대해 프론트엔드 구조 진화와 관련된 단락에서만 간략하게 설명하고 있으며, 도출된 상세 내용은 다음과 같습니다.
-
-*   **계층을 통한 관심사 분리:** 프론트엔드 개발 환경에서 UI 컴포넌트의 역할과 계층을 분명히 구분하여, 비대해지고 복잡해진 컴포넌트들의 관심사를 효과적으로 분리하는 데 사용됩니다 [1].
-*   **세밀한 분류 기준 제공:** 이 패턴은 단순히 원자(atoms), 분자(molecules), 유기체(organisms)라는 명칭으로 계층을 나누는 것 자체에 목적이 있는 것이 아닙니다 [1]. 그보다는 한 곳에 무질서하게 모여 있던 컴포넌트들을 명확한 기준으로 쪼개어, 역할과 범주에 따라 다시 정돈하기 쉽게 만들어준다는 점이 핵심적인 의의입니다 [1].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 지식 자산화 및 기존 네트워크 연동 단계.
-- **정책 변화:** Design & Experience 카테고리의 전문성 확보 및 링크 밀도 최적화.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[UI 컴포넌트]], [[관심사의 분리]]
-- **Projects/Contexts:** [[프론트엔드 개발]]
-- **Contradictions/Notes:** 소스에서는 Atomic Design Pattern을 도입할 때 atoms, molecules, organisms 같은 이름과 단순한 구조적 분리에 집착하기보다는, 컴포넌트를 세밀하게 나눌 수 있는 '기준'을 마련하여 복잡성을 정돈하는 것이 이 패턴의 주요한 역할이라고 강조합니다 [1].
-
----
-*Last updated: 2026-04-18*
-- Raw Source: [[00_Raw/2026-04-20/Atomic Design Pattern.md]]
----
diff --git a/Design & Experience/Auction-Theory.md b/Design & Experience/Auction-Theory.md
deleted file mode 100644
index f8fb7555..00000000
--- a/Design & Experience/Auction-Theory.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-50A53E
-category: "[[10_Wiki/💡 Topics/Design & Experience]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Auction-Theory"
----
-
-# [[Auction-Theory]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Design & Experience 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Auction-Theory.md]]
----
diff --git a/Design & Experience/Augmented Reality (AR) Interfaces.md b/Design & Experience/Augmented Reality (AR) Interfaces.md
deleted file mode 100644
index 47ecd2ae..00000000
--- a/Design & Experience/Augmented Reality (AR) Interfaces.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-0213E9
-category: "[[10_Wiki/💡 Topics/Design & Experience]]"
-confidence_score: 0.95
-tags: []
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Mega Batch 2 - Wikified Augmented Reality (AR) Interfaces"
----
-
-# [[Augmented Reality (AR) Interfaces]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 작업 중
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 지식 자산화 및 기존 네트워크 연동 단계.
-- **정책 변화:** Design & Experience 카테고리의 전문성 확보 및 링크 밀도 최적화.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Augmented Reality (AR) Interfaces.md]]
----
diff --git a/Design & Experience/Automated-Client-Generation.md b/Design & Experience/Automated-Client-Generation.md
deleted file mode 100644
index a2341e2c..00000000
--- a/Design & Experience/Automated-Client-Generation.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-D03F74
-category: "[[10_Wiki/💡 Topics/Design & Experience]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Automated-Client-Generation"
----
-
-# [[Automated-Client-Generation]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Design & Experience 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Automated-Client-Generation.md]]
----
diff --git a/Design & Experience/Bay 12 Games.md b/Design & Experience/Bay 12 Games.md
deleted file mode 100644
index 9d7bb1fe..00000000
--- a/Design & Experience/Bay 12 Games.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-F3ADB5
-category: "[[10_Wiki/💡 Topics/Design & Experience]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Bay 12 Games"
----
-
-# [[Bay 12 Games]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Design & Experience 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Bay 12 Games.md]]
----
diff --git a/Design & Experience/Bazel.md b/Design & Experience/Bazel.md
deleted file mode 100644
index de093715..00000000
--- a/Design & Experience/Bazel.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-C6F58A
-category: "[[10_Wiki/💡 Topics/Design & Experience]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Bazel"
----
-
-# [[Bazel]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Design & Experience 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Bazel.md]]
----
diff --git a/Design & Experience/Behavior-Driven-Development (BDD).md b/Design & Experience/Behavior-Driven-Development (BDD).md
deleted file mode 100644
index 52f6c2ef..00000000
--- a/Design & Experience/Behavior-Driven-Development (BDD).md	
+++ /dev/null
@@ -1,27 +0,0 @@
----
-id: P-REINFORCE-AI-BDD
-category: "[[10_Wiki/💡 Topics/Design & Experience]]"
-confidence_score: 0.98
-tags: [BDD, Behavior Driven Development, TDD, Agile, Gherkin]
-last_reinforced: 2026-04-20
----
-
-# [[Behavior-Driven-Development-(BDD)]] (행동 중심 개발)
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> "코딩하기 전에 대화부터 하라." 기획자, 디자이너, 개발자가 모여 사용자의 행동 시나리오(Given/When/Then)를 명확히 정의하고, 이를 검증하는 테스트 코드를 먼저 작성하며 개발하는 협업 중심 방법론이다.
-
-## 📖 구조화된 지식 (Synthesized Content)
-- **Ubiquitous Language**:
-    - 비즈니스 언어와 코드 언어의 간극을 줄이기 위해 누구나 이해할 수 있는 자연어 기반의 시나리오를 사용한다(예: Gherkin 문법).
-- **Executive Documentation**:
-    - 작성된 테스트 시나리오는 그대로 시스템의 최신 사양서(Living Documentation)가 되어 문서 관리의 고통을 덜어준다.
-- **User-Centric**:
-    - '어떻게 구현할까'보다 '사용자가 무엇을 얻을까'에 집중하게 하여, 엉뚱한 기능을 만드는 리스크를 원천 차단한다.
-
-## ⚠️ 모순 및 업데이트 (RL Update)
-- BDD는 초기 시나리오 작성에 시간이 많이 든다. 하지만 개발 중반 이후 발생하는 '기획 번복'과 '커뮤니케이션 미스'로 인한 손실을 생각하면, 장기적으로는 반드시 이득이 남는 고수익 투자다.
-
-## 🔗 지식 연결 (Graph)
-- Related: [[Test-Driven-Development-(TDD)]] , [[Agile-Software-Development]]
-- Strategy: [[User-Experience-Design]]
diff --git a/Design & Experience/BioShock (Rapture)] [Dark Souls (Environmental Lore)] [Gone Home (Domestic Narrative Architecture).md b/Design & Experience/BioShock (Rapture)] [Dark Souls (Environmental Lore)] [Gone Home (Domestic Narrative Architecture).md
deleted file mode 100644
index a4587ae8..00000000
--- a/Design & Experience/BioShock (Rapture)] [Dark Souls (Environmental Lore)] [Gone Home (Domestic Narrative Architecture).md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-395B33
-category: "[[10_Wiki/💡 Topics/Design & Experience]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - BioShock (Rapture)] [Dark Souls (Environmental Lore)] [Gone Home (Domestic Narrative Architecture)"
----
-
-# [[BioShock (Rapture)] [Dark Souls (Environmental Lore)] [Gone Home (Domestic Narrative Architecture)]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Design & Experience 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/BioShock (Rapture)], [Dark Souls (Environmental Lore)], [Gone Home (Domestic Narrative Architecture).md]]
----
diff --git a/Design & Experience/Borderlands-Art-Direction.md b/Design & Experience/Borderlands-Art-Direction.md
deleted file mode 100644
index e11134ec..00000000
--- a/Design & Experience/Borderlands-Art-Direction.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-37BB2D
-category: "[[10_Wiki/💡 Topics/Design & Experience]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Borderlands-Art-Direction"
----
-
-# [[Borderlands-Art-Direction]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Design & Experience 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Borderlands-Art-Direction.md]]
----
diff --git a/Design & Experience/Boundary-Layer-Validation.md b/Design & Experience/Boundary-Layer-Validation.md
deleted file mode 100644
index b0d0a89c..00000000
--- a/Design & Experience/Boundary-Layer-Validation.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-F8764E
-category: "[[10_Wiki/💡 Topics/Design & Experience]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Boundary-Layer-Validation"
----
-
-# [[Boundary-Layer-Validation]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Design & Experience 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Boundary-Layer-Validation.md]]
----
diff --git a/Design & Experience/Branded Types in TypeScript.md b/Design & Experience/Branded Types in TypeScript.md
deleted file mode 100644
index 63bb0343..00000000
--- a/Design & Experience/Branded Types in TypeScript.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-3CA58B
-category: "[[10_Wiki/💡 Topics/Design & Experience]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Branded Types in TypeScript"
----
-
-# [[Branded Types in TypeScript]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Design & Experience 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Branded Types in TypeScript.md]]
----
diff --git a/Design & Experience/Buck2.md b/Design & Experience/Buck2.md
deleted file mode 100644
index caec7019..00000000
--- a/Design & Experience/Buck2.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-849CEC
-category: "[[10_Wiki/💡 Topics/Design & Experience]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Buck2"
----
-
-# [[Buck2]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Design & Experience 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Buck2.md]]
----
diff --git a/Design & Experience/Business-Strategy.md b/Design & Experience/Business-Strategy.md
deleted file mode 100644
index ae50611d..00000000
--- a/Design & Experience/Business-Strategy.md	
+++ /dev/null
@@ -1,27 +0,0 @@
----
-id: P-REINFORCE-BIZ-STRATEGY
-category: "[[10_Wiki/💡 Topics/Design & Experience]]"
-confidence_score: 0.98
-tags: [Business Strategy, Market Analysis, Competitive Advantage, Innovation]
-last_reinforced: 2026-04-20
----
-
-# [[Business-Strategy]] (비즈니스 전략)
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> "어디서 싸울 것인가보다, 어떻게 이길 것인가를 결정하는 것." 한정된 자원을 집중하여 지속 가능한 경쟁 우위를 창출하고, 고객에게 독보적인 가치를 전달하는 의사결정의 지도다.
-
-## 📖 구조화된 지식 (Synthesized Content)
-- **Competitive Advantage (Moore/Porter)**:
-    - 비용 우위(Cost Leadership)나 차별화(Differentiation)를 통해 경쟁자가 따라올 수 없는 '경제적 해자(Moat)'를 구축하는 전략.
-- **Resource-Based View (RBV)**:
-    - 외부 환경보다 기업 내부의 독특한 자원(특허, 브랜드, 인적 자본)이 성패를 가른다는 관점.
-- **Blue Ocean Strategy**:
-    - 경쟁이 치열한 기존 시장(Red Ocean)을 벗어나, 경쟁이 없는 새로운 시장을 창출하는 혁신 프로세스.
-
-## ⚠️ 모순 및 업데이트 (RL Update)
-- 현대의 전략은 '고정된 계획'이 아니라 '유연한 적응'이다. AI 시대에는 데이터 피드백 루프를 통해 전략을 실시간으로 수정하는 'Agile Strategy'가 전통적인 5개년 계획을 대체하고 있다.
-
-## 🔗 지식 연결 (Graph)
-- Related: [[Business-Driven-Security]] , [[Innovation-Management]]
-- Strategy: [[User-Experience-Design]]
diff --git a/Design & Experience/Causal Loop Diagramming.md b/Design & Experience/Causal Loop Diagramming.md
deleted file mode 100644
index e3ddd9b6..00000000
--- a/Design & Experience/Causal Loop Diagramming.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-658665
-category: "[[10_Wiki/💡 Topics/Design & Experience]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Causal Loop Diagramming"
----
-
-# [[Causal Loop Diagramming]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Design & Experience 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Causal Loop Diagramming.md]]
----
diff --git a/Design & Experience/Choice Architecture in Digital UX.md b/Design & Experience/Choice Architecture in Digital UX.md
deleted file mode 100644
index 84a2b818..00000000
--- a/Design & Experience/Choice Architecture in Digital UX.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-BE3FDC
-category: "[[10_Wiki/💡 Topics/Design & Experience]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Choice Architecture in Digital UX"
----
-
-# [[Choice Architecture in Digital UX]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Design & Experience 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Choice Architecture in Digital UX.md]]
----
diff --git a/Design & Experience/Chrome User Experience Report (CrUX).md b/Design & Experience/Chrome User Experience Report (CrUX).md
deleted file mode 100644
index f2911f70..00000000
--- a/Design & Experience/Chrome User Experience Report (CrUX).md	
+++ /dev/null
@@ -1,40 +0,0 @@
----
-id: P-REINFORCE-AUTO-C2220F
-category: "[[10_Wiki/💡 Topics/Design & Experience]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Chrome User Experience Report (CrUX)"
----
-
-# [[Chrome User Experience Report (CrUX)]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-* **데이터의 성격 및 수집 방식:**
-  CrUX는 실험실 데이터(Lab Data)가 아닌, 실제 사용자 모니터링(RUM, Real-User Monitoring)을 통한 필드 데이터입니다 [3, 5]. Chrome 브라우저가 옵트인 사용자들의 데이터를 수집하여 매월 발행하며, 주로 최상위 수백만 개의 도메인을 대상으로 전체 도메인 단위로 요약된 성능 측정치를 제공합니다 [3, 6].
-
-* **주요 측정 지표 (Core Web Vitals):**
-  CrUX 보고서는 LCP(Largest Contentful Paint), CLS(Cumulative Layout Shift), INP(Interaction to Next Paint)와 같은 코어 웹 바이탈을 75백분위수(75th percentile)를 기준으로 기록합니다 [4, 7]. 또한 사용자의 데스크톱 및 모바일 접속 비율, 75백분위수 네트워크 속도(예: Slow 4G 환경)와 같은 접속 환경 데이터도 함께 제공하여 개발자가 실제 방문자의 환경과 유사한 조건에서 성능을 테스트할 수 있도록 돕습니다 [8].
-
-* **고급 데이터 및 세부 지표:**
-  CrUX는 이미지 기반 콘텐츠를 위한 'LCP 하위 요소(LCP subparts)' 데이터도 제공하지만, 이 세부 데이터는 PageSpeed Insights에는 직접 표시되지 않으므로 CrUX Vis나 DebugBear 같은 외부 도구를 통해서 확인해야 합니다 [1, 9]. 
-
-* **데이터 접근성 및 한계:**
-  CrUX 데이터에 접근하기 위해서는 Google의 데이터 웨어하우스 도구인 BigQuery나 DataStudio를 사용해야 합니다 [6]. 무엇보다 중요한 한계점은, 특정 URL이나 도메인이 CrUX 데이터에 포함되기 위해서는 '최소 데이터 볼륨(minimum data volume)' 기준을 충족해야 한다는 것입니다 [8]. 따라서 수명이 짧은 웹페이지나 트래픽이 적은 소규모 웹사이트는 데이터를 확인할 수 없습니다 [6, 8].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Design & Experience 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[Core Web Vitals]], [[Largest Contentful Paint (LCP)]], [[Interaction to Next Paint (INP)]], [[Real User Monitoring (RUM)]]
-- **Projects/Contexts:** [[PageSpeed Insights]], [[BigQuery]], [[Chrome DevTools]]
-- **Contradictions/Notes:** 소스에 따르면 CrUX는 실제 사용자 성능을 파악하는 데 매우 유용한 지표지만, 최소 트래픽 기준을 충족하지 못하는 페이지는 데이터가 수집/표시되지 않는다는 한계가 명확히 존재합니다 [6, 8]. 또한 특정 세부 데이터(LCP 하위 요소)는 PageSpeed Insights가 아닌 별도의 서드파티 도구에서만 조회 가능하다는 점을 유의해야 합니다 [9].
-
----
-*Last updated: 2026-04-19*
-- Raw Source: [[00_Raw/2026-04-20/Chrome User Experience Report (CrUX).md]]
----
diff --git a/Design & Experience/Code Formatting.md b/Design & Experience/Code Formatting.md
deleted file mode 100644
index 4b702ffd..00000000
--- a/Design & Experience/Code Formatting.md	
+++ /dev/null
@@ -1,40 +0,0 @@
----
-id: P-REINFORCE-AUTO-E4F919
-category: "[[10_Wiki/💡 Topics/Design & Experience]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Code Formatting"
----
-
-# [[Code Formatting]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 코드 포맷팅(Code Formatting)은 들여쓰기, 공백, 줄 바꿈, 따옴표 등 소스 코드의 시각적 스타일과 레이아웃을 일관된 규칙에 맞게 정리하는 과정입니다. 이는 코드의 런타임 논리나 실행 의미를 변경하지 않고 코드의 구조적 형태만 변환하며, 일반적으로 Prettier나 Black과 같은 자동화 도구(Formatter)를 통해 수행됩니다. 일관된 코드 포맷팅은 가독성을 향상시키고 협업 시 개발자 간의 미적 선호도 차이로 인한 마찰과 인지적 부하를 줄여주는 핵심적인 역할을 합니다.
-
-## 📖 구조화된 지식 (Synthesized Content)
-* **코드 포맷팅의 목적 및 이점:** 
-  일관되고 명확한 포맷팅 규칙은 코드를 명확하게 이해하고 논리적 흐름을 빠르게 파악할 수 있도록 도와 인지적 오버헤드(cognitive overhead)를 줄여줍니다 [1]. 개발자들은 코드 작성 시 스타일에 대한 고민을 덜고 핵심 비즈니스 로직과 아키텍처에 집중할 수 있으며, 일관된 코드는 동료들의 코드 리뷰 과정을 더욱 원활하게 만들어 생산성을 극대화합니다 [2-4].
-
-* **자동화 도구 (Formatter)의 활용:**
-  개발 생태계에서는 Prettier(JavaScript/TypeScript 등)와 Black(Python) 같은 독단적(opinionated)인 코드 포맷터가 널리 쓰입니다. 이 도구들은 작성자가 코드를 어떻게 입력했는지와 무관하게 코드를 파싱한 후, 줄 길이(line width), 들여쓰기(indentation) 등 자체적인 규칙에 따라 코드를 완전히 새로 작성(reprint)하여 시각적 통일성을 강제합니다 [5-8].
-
-* **Linter와의 차이점 및 연동 시 주의사항:**
-  Linter(예: ESLint)는 코드의 문법적 오류나 잠재적 버그를 식별하는 '정적 분석 및 품질 관리' 도구인 반면, Formatter(예: Prettier)는 '스타일 교정'에 특화되어 있습니다 [2, 7, 9]. Linter 자체에도 일부 코드 포맷팅 기능이 포함되어 있기 때문에 이 둘을 함께 사용할 경우 규칙이 충돌하여 무한 경고 루프를 유발할 수 있습니다. 따라서 `eslint-config-prettier` 등을 통해 Linter의 포맷팅 규칙을 비활성화하고, 포맷팅 역할은 전적으로 Formatter에 위임하는 방식이 표준으로 자리 잡고 있습니다 [10-12].
-
-* **코드 스타일로메트리(Code Stylometry)에 미치는 영향:**
-  코드 포맷팅은 컴파일러가 코드를 이해하는 추상 구문 트리(AST)를 변경하지 않지만, 소스 코드의 표면적 특성을 담는 구체 구문 트리(CST)를 크게 변경합니다 [13]. 이 과정에서 코드 작성자 고유의 띄어쓰기나 들여쓰기 등 스타일적 지문(stylistic fingerprints)이 지워지게 됩니다. 그 결과, 소스 코드를 통해 작성자를 추적하는 코드 스타일로메트리 분석의 정확도가 눈에 띄게 하락(약 68%에서 53%로 감소)하며, 이는 억압적인 환경에 있는 오픈소스 기여자들에게 일종의 프라이버시 보호막(Privacy Shield) 역할을 제공할 수 있습니다 [14-17].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Design & Experience 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[Linter]], [[Prettier]], [[Code Stylometry]], [[Code Readability]]
-- **Projects/Contexts:** [[Automated Code Governance]], [[CI/CD Pipeline]]
-- **Contradictions/Notes:** ESLint와 같은 Linter 도구 내에도 자체적인 포맷팅 규칙이 존재하여 Prettier와 동시 사용 시 규칙 충돌(Infinite feedback loop)이 일어날 수 있습니다. 따라서 Linter의 포맷팅 기능을 끄고 이를 Prettier에 전담시키는 구성 최적화가 필수적입니다 [12, 18].
-
----
-*Last updated: 2026-04-19*
-- Raw Source: [[00_Raw/2026-04-20/Code Formatting.md]]
----
diff --git a/Design & Experience/Cognitive Aging Research.md b/Design & Experience/Cognitive Aging Research.md
deleted file mode 100644
index 303dfce0..00000000
--- a/Design & Experience/Cognitive Aging Research.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-8C858F
-category: "[[10_Wiki/💡 Topics/Design & Experience]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Cognitive Aging Research"
----
-
-# [[Cognitive Aging Research]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Design & Experience 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Cognitive Aging Research.md]]
----
diff --git a/Design & Experience/Cognitive Dissonance.md b/Design & Experience/Cognitive Dissonance.md
deleted file mode 100644
index 8c84338d..00000000
--- a/Design & Experience/Cognitive Dissonance.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-0C898E
-category: "[[10_Wiki/💡 Topics/Design & Experience]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Cognitive Dissonance"
----
-
-# [[Cognitive Dissonance]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Design & Experience 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Cognitive Dissonance.md]]
----
diff --git a/Design & Experience/Cognitive-Flexibility.md b/Design & Experience/Cognitive-Flexibility.md
deleted file mode 100644
index b1c1062f..00000000
--- a/Design & Experience/Cognitive-Flexibility.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-634AD5
-category: "[[10_Wiki/💡 Topics/Design & Experience]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Cognitive-Flexibility"
----
-
-# [[Cognitive-Flexibility]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Design & Experience 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Cognitive-Flexibility.md]]
----
diff --git a/Design & Experience/Cognitive-Psychology.md b/Design & Experience/Cognitive-Psychology.md
deleted file mode 100644
index 1d6f7357..00000000
--- a/Design & Experience/Cognitive-Psychology.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-7EA6B8
-category: "[[10_Wiki/💡 Topics/Design & Experience]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Cognitive-Psychology"
----
-
-# [[Cognitive-Psychology]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Design & Experience 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Cognitive-Psychology.md]]
----
diff --git a/Design & Experience/Complexity Science in Economics.md b/Design & Experience/Complexity Science in Economics.md
deleted file mode 100644
index 3a49b59a..00000000
--- a/Design & Experience/Complexity Science in Economics.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-527F62
-category: "[[10_Wiki/💡 Topics/Design & Experience]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Complexity Science in Economics"
----
-
-# [[Complexity Science in Economics]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Design & Experience 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Complexity Science in Economics.md]]
----
diff --git a/Design & Experience/Computation-Caching-Strategies.md b/Design & Experience/Computation-Caching-Strategies.md
deleted file mode 100644
index a2f53932..00000000
--- a/Design & Experience/Computation-Caching-Strategies.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-802544
-category: "[[10_Wiki/💡 Topics/Design & Experience]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Computation-Caching-Strategies"
----
-
-# [[Computation-Caching-Strategies]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Design & Experience 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Computation-Caching-Strategies.md]]
----
diff --git a/Design & Experience/Computational Thinking.md b/Design & Experience/Computational Thinking.md
deleted file mode 100644
index 148f9b9d..00000000
--- a/Design & Experience/Computational Thinking.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-45C605
-category: "[[10_Wiki/💡 Topics/Design & Experience]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Computational Thinking"
----
-
-# [[Computational Thinking]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Design & Experience 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Computational Thinking.md]]
----
diff --git a/Design & Experience/Computational-Fluid-Dynamics.md b/Design & Experience/Computational-Fluid-Dynamics.md
deleted file mode 100644
index c3403d3b..00000000
--- a/Design & Experience/Computational-Fluid-Dynamics.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-668FCE
-category: "[[10_Wiki/💡 Topics/Design & Experience]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Computational-Fluid-Dynamics"
----
-
-# [[Computational-Fluid-Dynamics]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Design & Experience 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Computational-Fluid-Dynamics.md]]
----
diff --git a/Design & Experience/Conditional-Types.md b/Design & Experience/Conditional-Types.md
deleted file mode 100644
index 392e24ad..00000000
--- a/Design & Experience/Conditional-Types.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-F3246D
-category: "[[10_Wiki/💡 Topics/Design & Experience]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Conditional-Types"
----
-
-# [[Conditional-Types]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Design & Experience 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Conditional-Types.md]]
----
diff --git a/Design & Experience/Content-Strategy.md b/Design & Experience/Content-Strategy.md
deleted file mode 100644
index 15ab5375..00000000
--- a/Design & Experience/Content-Strategy.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-ED632C
-category: "[[10_Wiki/💡 Topics/Design & Experience]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Content-Strategy"
----
-
-# [[Content-Strategy]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Design & Experience 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Content-Strategy.md]]
----
diff --git a/Design & Experience/Contract-Driven-Development.md b/Design & Experience/Contract-Driven-Development.md
deleted file mode 100644
index cd13c8f7..00000000
--- a/Design & Experience/Contract-Driven-Development.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-1F7EE7
-category: "[[10_Wiki/💡 Topics/Design & Experience]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Contract-Driven-Development"
----
-
-# [[Contract-Driven-Development]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Design & Experience 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Contract-Driven-Development.md]]
----
diff --git a/Design & Experience/Contract-First-Development.md b/Design & Experience/Contract-First-Development.md
deleted file mode 100644
index d7b5a5d2..00000000
--- a/Design & Experience/Contract-First-Development.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-B0C45D
-category: "[[10_Wiki/💡 Topics/Design & Experience]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Contract-First-Development"
----
-
-# [[Contract-First-Development]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Design & Experience 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Contract-First-Development.md]]
----
diff --git a/Design & Experience/Contract-Testing.md b/Design & Experience/Contract-Testing.md
deleted file mode 100644
index 723cbd87..00000000
--- a/Design & Experience/Contract-Testing.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-7A6306
-category: "[[10_Wiki/💡 Topics/Design & Experience]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Contract-Testing"
----
-
-# [[Contract-Testing]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Design & Experience 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Contract-Testing.md]]
----
diff --git a/Design & Experience/Contravariance-and-Covariance.md b/Design & Experience/Contravariance-and-Covariance.md
deleted file mode 100644
index e2dc2dbc..00000000
--- a/Design & Experience/Contravariance-and-Covariance.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-62A6A2
-category: "[[10_Wiki/💡 Topics/Design & Experience]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Contravariance-and-Covariance"
----
-
-# [[Contravariance-and-Covariance]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Design & Experience 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Contravariance-and-Covariance.md]]
----
diff --git a/Design & Experience/Creativity-and-Cognitive-Complexity.md b/Design & Experience/Creativity-and-Cognitive-Complexity.md
deleted file mode 100644
index 4b31371d..00000000
--- a/Design & Experience/Creativity-and-Cognitive-Complexity.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-091CD8
-category: "[[10_Wiki/💡 Topics/Design & Experience]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Creativity-and-Cognitive-Complexity"
----
-
-# [[Creativity-and-Cognitive-Complexity]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Design & Experience 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Creativity-and-Cognitive-Complexity.md]]
----
diff --git a/Design & Experience/Critical Design.md b/Design & Experience/Critical Design.md
deleted file mode 100644
index fb232a44..00000000
--- a/Design & Experience/Critical Design.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-A653EF
-category: "[[10_Wiki/💡 Topics/Design & Experience]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Critical Design"
----
-
-# [[Critical Design]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Design & Experience 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Critical Design.md]]
----
diff --git a/Design & Experience/Cryptoeconomics.md b/Design & Experience/Cryptoeconomics.md
deleted file mode 100644
index 17ec9c33..00000000
--- a/Design & Experience/Cryptoeconomics.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-5B4AE2
-category: "[[10_Wiki/💡 Topics/Design & Experience]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Cryptoeconomics"
----
-
-# [[Cryptoeconomics]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Design & Experience 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Cryptoeconomics.md]]
----
diff --git a/Design & Experience/Dark Souls (Environmental Storytelling).md b/Design & Experience/Dark Souls (Environmental Storytelling).md
deleted file mode 100644
index 1b229e6d..00000000
--- a/Design & Experience/Dark Souls (Environmental Storytelling).md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-938B32
-category: "[[10_Wiki/💡 Topics/Design & Experience]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Dark Souls (Environmental Storytelling)"
----
-
-# [[Dark Souls (Environmental Storytelling)]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Design & Experience 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Dark Souls (Environmental Storytelling).md]]
----
diff --git a/Design & Experience/Data-Sanitization.md b/Design & Experience/Data-Sanitization.md
deleted file mode 100644
index 008f84d9..00000000
--- a/Design & Experience/Data-Sanitization.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-476815
-category: "[[10_Wiki/💡 Topics/Design & Experience]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Data-Sanitization"
----
-
-# [[Data-Sanitization]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Design & Experience 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Data-Sanitization.md]]
----
diff --git a/Design & Experience/Declaration Merging.md b/Design & Experience/Declaration Merging.md
deleted file mode 100644
index acd7dd63..00000000
--- a/Design & Experience/Declaration Merging.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-164A4F
-category: "[[10_Wiki/💡 Topics/Design & Experience]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Declaration Merging"
----
-
-# [[Declaration Merging]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Design & Experience 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Declaration Merging.md]]
----
diff --git a/Design & Experience/Declaration-Merging.md b/Design & Experience/Declaration-Merging.md
deleted file mode 100644
index bbfd6ef9..00000000
--- a/Design & Experience/Declaration-Merging.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-6586E8
-category: "[[10_Wiki/💡 Topics/Design & Experience]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Declaration-Merging"
----
-
-# [[Declaration-Merging]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Design & Experience 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Declaration-Merging.md]]
----
diff --git a/Design & Experience/Depth-Subtyping.md b/Design & Experience/Depth-Subtyping.md
deleted file mode 100644
index 47cec662..00000000
--- a/Design & Experience/Depth-Subtyping.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-408E53
-category: "[[10_Wiki/💡 Topics/Design & Experience]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Depth-Subtyping"
----
-
-# [[Depth-Subtyping]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Design & Experience 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Depth-Subtyping.md]]
----
diff --git a/Design & Experience/Design-Thinking.md b/Design & Experience/Design-Thinking.md
deleted file mode 100644
index ae3c293d..00000000
--- a/Design & Experience/Design-Thinking.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-F6D12C
-category: "[[10_Wiki/💡 Topics/Design & Experience]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Design-Thinking"
----
-
-# [[Design-Thinking]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Design & Experience 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Design-Thinking.md]]
----
diff --git a/Design & Experience/Design-Tokens.md b/Design & Experience/Design-Tokens.md
deleted file mode 100644
index 9998ed1d..00000000
--- a/Design & Experience/Design-Tokens.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-2C4230
-category: "[[10_Wiki/💡 Topics/Design & Experience]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Design-Tokens"
----
-
-# [[Design-Tokens]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Design & Experience 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Design-Tokens.md]]
----
diff --git a/Design & Experience/Diegetic UI.md b/Design & Experience/Diegetic UI.md
deleted file mode 100644
index be406d08..00000000
--- a/Design & Experience/Diegetic UI.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-FE01D2
-category: "[[10_Wiki/💡 Topics/Design & Experience]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Diegetic UI"
----
-
-# [[Diegetic UI]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Design & Experience 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Diegetic UI.md]]
----
diff --git a/Design & Experience/Diegetic-Interface.md b/Design & Experience/Diegetic-Interface.md
deleted file mode 100644
index 0f218de9..00000000
--- a/Design & Experience/Diegetic-Interface.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-9F62F4
-category: "[[10_Wiki/💡 Topics/Design & Experience]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Diegetic-Interface"
----
-
-# [[Diegetic-Interface]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Design & Experience 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Diegetic-Interface.md]]
----
diff --git a/Design & Experience/Digital Humanities.md b/Design & Experience/Digital Humanities.md
deleted file mode 100644
index 5f41d732..00000000
--- a/Design & Experience/Digital Humanities.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-1CBB5B
-category: "[[10_Wiki/💡 Topics/Design & Experience]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Digital Humanities"
----
-
-# [[Digital Humanities]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Design & Experience 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Digital Humanities.md]]
----
diff --git a/Design & Experience/Digital Twin Interfaces.md b/Design & Experience/Digital Twin Interfaces.md
deleted file mode 100644
index 60410195..00000000
--- a/Design & Experience/Digital Twin Interfaces.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-6DF617
-category: "[[10_Wiki/💡 Topics/Design & Experience]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Digital Twin Interfaces"
----
-
-# [[Digital Twin Interfaces]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Design & Experience 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Digital Twin Interfaces.md]]
----
diff --git a/Design & Experience/Digital-Heritage-Preservation.md b/Design & Experience/Digital-Heritage-Preservation.md
deleted file mode 100644
index a7736b29..00000000
--- a/Design & Experience/Digital-Heritage-Preservation.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-C13BDE
-category: "[[10_Wiki/💡 Topics/Design & Experience]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Digital-Heritage-Preservation"
----
-
-# [[Digital-Heritage-Preservation]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Design & Experience 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Digital-Heritage-Preservation.md]]
----
diff --git a/Design & Experience/Digital-Humanities.md b/Design & Experience/Digital-Humanities.md
deleted file mode 100644
index 90c06d3e..00000000
--- a/Design & Experience/Digital-Humanities.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-B1AF91
-category: "[[10_Wiki/💡 Topics/Design & Experience]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Digital-Humanities"
----
-
-# [[Digital-Humanities]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Design & Experience 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Digital-Humanities.md]]
----
diff --git a/Design & Experience/Digital-Transformation-Strategy.md b/Design & Experience/Digital-Transformation-Strategy.md
deleted file mode 100644
index bb109fbb..00000000
--- a/Design & Experience/Digital-Transformation-Strategy.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-5767B8
-category: "[[10_Wiki/💡 Topics/Design & Experience]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Digital-Transformation-Strategy"
----
-
-# [[Digital-Transformation-Strategy]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Design & Experience 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Digital-Transformation-Strategy.md]]
----
diff --git a/Design & Experience/Divergent-Thinking.md b/Design & Experience/Divergent-Thinking.md
deleted file mode 100644
index d588b6eb..00000000
--- a/Design & Experience/Divergent-Thinking.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-52E973
-category: "[[10_Wiki/💡 Topics/Design & Experience]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Divergent-Thinking"
----
-
-# [[Divergent-Thinking]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Design & Experience 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Divergent-Thinking.md]]
----
diff --git a/Design & Experience/Duck-Typing.md b/Design & Experience/Duck-Typing.md
deleted file mode 100644
index 0531c7e3..00000000
--- a/Design & Experience/Duck-Typing.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-31CA9B
-category: "[[10_Wiki/💡 Topics/Design & Experience]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Duck-Typing"
----
-
-# [[Duck-Typing]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Design & Experience 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Duck-Typing.md]]
----
diff --git a/Design & Experience/Dwarf Fortress.md b/Design & Experience/Dwarf Fortress.md
deleted file mode 100644
index 0c4abdd8..00000000
--- a/Design & Experience/Dwarf Fortress.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-8B5736
-category: "[[10_Wiki/💡 Topics/Design & Experience]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Dwarf Fortress"
----
-
-# [[Dwarf Fortress]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Design & Experience 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Dwarf Fortress.md]]
----
diff --git a/Design & Experience/E-commerce-Conversion-Optimization.md b/Design & Experience/E-commerce-Conversion-Optimization.md
deleted file mode 100644
index 5d849949..00000000
--- a/Design & Experience/E-commerce-Conversion-Optimization.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-E7164D
-category: "[[10_Wiki/💡 Topics/Design & Experience]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - E-commerce-Conversion-Optimization"
----
-
-# [[E-commerce-Conversion-Optimization]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Design & Experience 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/E-commerce-Conversion-Optimization.md]]
----
diff --git a/Design & Experience/ESL Pro Tour.md b/Design & Experience/ESL Pro Tour.md
deleted file mode 100644
index f62105b5..00000000
--- a/Design & Experience/ESL Pro Tour.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-6D8C66
-category: "[[10_Wiki/💡 Topics/Design & Experience]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - ESL Pro Tour"
----
-
-# [[ESL Pro Tour]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Design & Experience 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/ESL Pro Tour.md]]
----
diff --git a/Design & Experience/ESLint-Plugin-TypeScript.md b/Design & Experience/ESLint-Plugin-TypeScript.md
deleted file mode 100644
index af1d5ec8..00000000
--- a/Design & Experience/ESLint-Plugin-TypeScript.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-787585
-category: "[[10_Wiki/💡 Topics/Design & Experience]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - ESLint-Plugin-TypeScript"
----
-
-# [[ESLint-Plugin-TypeScript]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Design & Experience 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/ESLint-Plugin-TypeScript.md]]
----
diff --git a/Design & Experience/Edge-Detection-Algorithms.md b/Design & Experience/Edge-Detection-Algorithms.md
deleted file mode 100644
index 2faba7cd..00000000
--- a/Design & Experience/Edge-Detection-Algorithms.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-D5E910
-category: "[[10_Wiki/💡 Topics/Design & Experience]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Edge-Detection-Algorithms"
----
-
-# [[Edge-Detection-Algorithms]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Design & Experience 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Edge-Detection-Algorithms.md]]
----
diff --git a/Design & Experience/Educational Pedagogy (Zone of Proximal Development).md b/Design & Experience/Educational Pedagogy (Zone of Proximal Development).md
deleted file mode 100644
index 52870a3d..00000000
--- a/Design & Experience/Educational Pedagogy (Zone of Proximal Development).md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-A6B581
-category: "[[10_Wiki/💡 Topics/Design & Experience]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Educational Pedagogy (Zone of Proximal Development)"
----
-
-# [[Educational Pedagogy (Zone of Proximal Development)]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Design & Experience 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Educational Pedagogy (Zone of Proximal Development).md]]
----
diff --git a/Design & Experience/Educational-Psychology.md b/Design & Experience/Educational-Psychology.md
deleted file mode 100644
index 6695e5bd..00000000
--- a/Design & Experience/Educational-Psychology.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-F3112C
-category: "[[10_Wiki/💡 Topics/Design & Experience]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Educational-Psychology"
----
-
-# [[Educational-Psychology]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Design & Experience 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Educational-Psychology.md]]
----
diff --git a/Design & Experience/Electromyography.md b/Design & Experience/Electromyography.md
deleted file mode 100644
index 633fbf56..00000000
--- a/Design & Experience/Electromyography.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-D6647F
-category: "[[10_Wiki/💡 Topics/Design & Experience]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Electromyography"
----
-
-# [[Electromyography]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Design & Experience 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Electromyography.md]]
----
diff --git a/Design & Experience/Environmental Storyability.md b/Design & Experience/Environmental Storyability.md
deleted file mode 100644
index 83b1e003..00000000
--- a/Design & Experience/Environmental Storyability.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-61BAD9
-category: "[[10_Wiki/💡 Topics/Design & Experience]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Environmental Storyability"
----
-
-# [[Environmental Storyability]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Design & Experience 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Environmental Storyability.md]]
----
diff --git a/Design & Experience/Environmental Storytelling.md b/Design & Experience/Environmental Storytelling.md
deleted file mode 100644
index 26839ea4..00000000
--- a/Design & Experience/Environmental Storytelling.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-415A1C
-category: "[[10_Wiki/💡 Topics/Design & Experience]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Environmental Storytelling"
----
-
-# [[Environmental Storytelling]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Design & Experience 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Environmental Storytelling.md]]
----
diff --git a/Design & Experience/Environmental-Storytelling.md b/Design & Experience/Environmental-Storytelling.md
deleted file mode 100644
index 2cd47b89..00000000
--- a/Design & Experience/Environmental-Storytelling.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-BB91DD
-category: "[[10_Wiki/💡 Topics/Design & Experience]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Environmental-Storytelling"
----
-
-# [[Environmental-Storytelling]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Design & Experience 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Environmental-Storytelling.md]]
----
diff --git a/Design & Experience/Ergodic Literature.md b/Design & Experience/Ergodic Literature.md
deleted file mode 100644
index 1ca3c70f..00000000
--- a/Design & Experience/Ergodic Literature.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-96D046
-category: "[[10_Wiki/💡 Topics/Design & Experience]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Ergodic Literature"
----
-
-# [[Ergodic Literature]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Design & Experience 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Ergodic Literature.md]]
----
diff --git a/Design & Experience/Ergodic-Literature.md b/Design & Experience/Ergodic-Literature.md
deleted file mode 100644
index 7dc63d18..00000000
--- a/Design & Experience/Ergodic-Literature.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-CB2F13
-category: "[[10_Wiki/💡 Topics/Design & Experience]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Ergodic-Literature"
----
-
-# [[Ergodic-Literature]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Design & Experience 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Ergodic-Literature.md]]
----
diff --git a/Design & Experience/Executive Function.md b/Design & Experience/Executive Function.md
deleted file mode 100644
index 75044686..00000000
--- a/Design & Experience/Executive Function.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-8909A3
-category: "[[10_Wiki/💡 Topics/Design & Experience]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Executive Function"
----
-
-# [[Executive Function]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Design & Experience 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Executive Function.md]]
----
diff --git a/Design & Experience/Exhaustiveness-Checking-with-Never.md b/Design & Experience/Exhaustiveness-Checking-with-Never.md
deleted file mode 100644
index cc0c9d76..00000000
--- a/Design & Experience/Exhaustiveness-Checking-with-Never.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-A2E3FE
-category: "[[10_Wiki/💡 Topics/Design & Experience]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Exhaustiveness-Checking-with-Never"
----
-
-# [[Exhaustiveness-Checking-with-Never]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Design & Experience 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Exhaustiveness-Checking-with-Never.md]]
----
diff --git a/Design & Experience/FSD (Feature-Sliced Design).md b/Design & Experience/FSD (Feature-Sliced Design).md
deleted file mode 100644
index b931d0bc..00000000
--- a/Design & Experience/FSD (Feature-Sliced Design).md	
+++ /dev/null
@@ -1,37 +0,0 @@
----
-id: P-REINFORCE-AUTO-912710
-category: "[[10_Wiki/💡 Topics/Design & Experience]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - FSD (Feature-Sliced Design)"
----
-
-# [[FSD (Feature-Sliced Design)]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> FSD(Feature-Sliced Design)는 프론트엔드 개발에서 프로젝트의 복잡성을 줄이고 유지보수성과 확장성을 향상시키기 위해 고안된 아키텍처입니다. 기존의 역할 중심 폴더 구조가 가지는 한계를 극복하고자 '기능(Feature)'을 기준으로 코드를 분리하는 방식을 채택합니다. 기능 간의 결합도를 낮추고 각 기능이 독립적으로 관리되도록 설계되어, 특히 대규모 프로젝트를 관리하는 데 효과적인 방법론입니다.
-
-## 📖 구조화된 지식 (Synthesized Content)
-*   **등장 배경 및 기존 구조의 한계:** 
-    프로젝트의 규모가 커지고 복잡해짐에 따라 기존의 역할(Role) 중심 폴더 구조만으로는 다양한 관심사와 요구 사항을 관리하는 데 명확한 한계가 발생했습니다. 컴포넌트 기반 개발 방식에서 역할별로 코드를 분리하더라도 결국 기능 간의 결합도가 높아지는 문제를 피하기 어려웠고, 이를 해결하기 위해 FSD가 등장하게 되었습니다.
-*   **기능(Feature) 중심의 분리:** 
-    FSD 아키텍처는 이름 그대로 '기능'을 기준으로 코드를 분리합니다. 하나의 기능을 구현하는 데 필요한 모든 파일과 코드를 같은 폴더에 모아 단위별로 관리하는 것을 목표로 합니다. 이를 통해 각 기능이 독립적으로 동작하게 하며, 불필요한 결합도를 줄여 유지보수성을 극대화합니다.
-*   **문서화된 표준으로서의 의의:** 
-    FSD가 완전히 새롭거나 전례 없던 아키텍처는 아닙니다. 대규모 프로젝트에서 기능 단위로 묶어 관리하는 것이 효율적이라는 인식은 이전부터 존재했습니다. 하지만 FSD는 이러한 구조를 공식적인 형태로 갖추고 '문서화된 표준'으로 제공한다는 점에서 큰 의의가 있습니다. 명확한 공식 문서를 통해 팀원 간의 멘탈 모델(Mental Model)을 통일하고 구조에 대한 합의를 이끌어내는 데 드는 커뮤니케이션 비용을 줄여줍니다.
-*   **적용 시 주의사항 (은탄환은 없다):** 
-    공식 설명에서도 명시하듯 FSD 구조는 주로 '규모가 큰 프로젝트'에 유용합니다. 모든 프로젝트에 완벽한 해결책이 되는 것은 아니며, 상황과 규모에 따라 기존의 역할 기반 폴더 구조나 다른 방식이 훨씬 더 효율적일 수 있습니다. 프로젝트의 성장 단계와 관심사의 변화에 따라 구조 역시 유연하게 진화해야 합니다.
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Design & Experience 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[관심사의 분리 (Separation of Concerns)]], [[단일 책임 원칙 (SRP)]], [[컴포넌트 기반 아키텍처]]
-- **Projects/Contexts:** [[대규모 프론트엔드 프로젝트 아키텍처 및 폴더 구조 설계]]
-- **Contradictions/Notes:** 소스에서는 FSD가 기능 간 결합도를 줄이고 유지보수를 돕는 훌륭한 표준이지만, 모든 상황에서 완벽한 정답은 아니라고 주장합니다. 프로젝트의 크기나 특성에 따라 오히려 기존의 단순한 폴더 구조가 더 적합할 수도 있으므로 프로젝트 상황에 맞는 유연한 폴더 구조 적용을 권장합니다.
-
----
-*Last updated: 2026-04-18*
-- Raw Source: [[00_Raw/2026-04-20/FSD (Feature-Sliced Design).md]]
----
diff --git a/Design & Experience/Fallout (Pip-Boy Mechanic).md b/Design & Experience/Fallout (Pip-Boy Mechanic).md
deleted file mode 100644
index 563427cc..00000000
--- a/Design & Experience/Fallout (Pip-Boy Mechanic).md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-C110F3
-category: "[[10_Wiki/💡 Topics/Design & Experience]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Fallout (Pip-Boy Mechanic)"
----
-
-# [[Fallout (Pip-Boy Mechanic)]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Design & Experience 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Fallout (Pip-Boy Mechanic).md]]
----
diff --git a/Design & Experience/Feature-Sliced Design.md b/Design & Experience/Feature-Sliced Design.md
deleted file mode 100644
index 2e438ed1..00000000
--- a/Design & Experience/Feature-Sliced Design.md	
+++ /dev/null
@@ -1,36 +0,0 @@
----
-id: P-REINFORCE-AUTO-925C5C
-category: "[[10_Wiki/💡 Topics/Design & Experience]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Feature-Sliced Design"
----
-
-# [[Feature-Sliced Design]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> Feature-Sliced Design(FSD)은 프론트엔드 개발에서 복잡성을 줄이고 유지보수성과 확장성을 향상시키기 위해 등장한 아키텍처 방법론입니다. 기존의 역할 중심 폴더 및 코드 분리 방식의 한계를 극복하고자 기능(Feature)을 기준으로 코드를 분리하고 관련된 파일들을 한데 모아 관리하는 것을 목표로 합니다. 완전히 새로운 개념은 아니지만 공식적인 문서화와 표준을 제공하여 대규모 프로젝트에서 팀원 간의 멘탈 모델을 맞추고 합의를 이끌어내는 데 특히 유용합니다.
-
-## 📖 구조화된 지식 (Synthesized Content)
-- **등장 배경:** 프론트엔드 프로젝트의 규모가 커지면서 기존 역할별 폴더 구조(예: components, api, pages 등)만으로는 기능 간의 결합도가 높아지고, 관련된 파일들이 흩어져 코드를 관리하고 파악하기 어려워지는 한계가 명확해졌습니다. FSD는 이러한 문제를 해결하기 위해 기능을 중심으로 코드를 분리하는 대안으로 등장했습니다.
-- **핵심 구조와 원리:** 하나의 기능 단위에 필요한 모든 파일들을 같은 폴더에 모아 관리합니다. 이를 통해 기능 간의 결합도를 줄이고, 각 기능이 독립적으로 관리될 수 있도록 설계되었습니다.
-- **주요 장점:** FSD 이전에도 비슷한 구조적 제안은 있었으나, FSD의 가장 큰 의의는 **공식적인 형태를 갖추고 문서화되어 있다는 점**입니다. 폴더 구조 변경에 따르는 커뮤니케이션 비용을 줄여주고, 팀원 간의 멘탈 모델을 일치시키며 합의를 이끌어내기 용이하게 만들어 줍니다.
-- **적용 시 주의사항 및 한계점:** 
-  - FSD 공식 설명에서도 명시하듯 이 구조는 **프로젝트의 규모가 클 때** 유용합니다.
-  - 모든 프로젝트에 완벽한 해결책이 되는 것은 아니며, 규모가 작은 프로젝트 등 상황에 따라서는 기존의 역할 기반 폴더 구조가 더 적합할 수 있습니다.
-  - 절대적인 정답으로 삼기보다는, 프로젝트의 성장과 변화하는 관심사에 맞추어 폴더 구조를 진화시켜 나가는 하나의 접근법으로 활용해야 합니다.
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Design & Experience 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[관심사의 분리(Separation of Concerns)]], [[멘탈 모델]]
-- **Projects/Contexts:** [[대규모 프론트엔드 프로젝트]]
-- **Contradictions/Notes:** FSD 아키텍처는 대규모 프로젝트의 복잡성 관리에 유용하지만, 모든 프로젝트에서 완벽한 해결책은 아니며 상황과 규모에 따라 오히려 기존의 폴더 구조가 더 효율적일 수도 있습니다.
-
----
-*Last updated: 2026-04-18*
-- Raw Source: [[00_Raw/2026-04-20/Feature-Sliced Design.md]]
----
diff --git a/Design & Experience/Flow-Sensitive-Typing.md b/Design & Experience/Flow-Sensitive-Typing.md
deleted file mode 100644
index d835f406..00000000
--- a/Design & Experience/Flow-Sensitive-Typing.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-D1B53D
-category: "[[10_Wiki/💡 Topics/Design & Experience]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Flow-Sensitive-Typing"
----
-
-# [[Flow-Sensitive-Typing]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Design & Experience 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Flow-Sensitive-Typing.md]]
----
diff --git a/Design & Experience/Formalism vs Structuralism.md b/Design & Experience/Formalism vs Structuralism.md
deleted file mode 100644
index d42a68b3..00000000
--- a/Design & Experience/Formalism vs Structuralism.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-9613E1
-category: "[[10_Wiki/💡 Topics/Design & Experience]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Formalism vs Structuralism"
----
-
-# [[Formalism vs Structuralism]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Design & Experience 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Formalism vs. Structuralism.md]]
----
diff --git a/Design & Experience/Formalist Criticism.md b/Design & Experience/Formalist Criticism.md
deleted file mode 100644
index 7f5c6e9e..00000000
--- a/Design & Experience/Formalist Criticism.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-6E52E3
-category: "[[10_Wiki/💡 Topics/Design & Experience]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Formalist Criticism"
----
-
-# [[Formalist Criticism]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Design & Experience 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Formalist Criticism.md]]
----
diff --git a/Design & Experience/Game Studies (Game Studies Journal).md b/Design & Experience/Game Studies (Game Studies Journal).md
deleted file mode 100644
index 0c96ea54..00000000
--- a/Design & Experience/Game Studies (Game Studies Journal).md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-266459
-category: "[[10_Wiki/💡 Topics/Design & Experience]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Game Studies (Game Studies Journal)"
----
-
-# [[Game Studies (Game Studies Journal)]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Design & Experience 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Game Studies (Game Studies Journal).md]]
----
diff --git a/Design & Experience/Game Systems Design.md b/Design & Experience/Game Systems Design.md
deleted file mode 100644
index d3e79cff..00000000
--- a/Design & Experience/Game Systems Design.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-1D378F
-category: "[[10_Wiki/💡 Topics/Design & Experience]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Game Systems Design"
----
-
-# [[Game Systems Design]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Design & Experience 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Game Systems Design.md]]
----
diff --git a/Design & Experience/Game-Level-Design.md b/Design & Experience/Game-Level-Design.md
deleted file mode 100644
index 46e74b79..00000000
--- a/Design & Experience/Game-Level-Design.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-B42B04
-category: "[[10_Wiki/💡 Topics/Design & Experience]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Game-Level-Design"
----
-
-# [[Game-Level-Design]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Design & Experience 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Game-Level-Design.md]]
----
diff --git a/Design & Experience/Game-Studies-Academic-Discourse.md b/Design & Experience/Game-Studies-Academic-Discourse.md
deleted file mode 100644
index ba500fad..00000000
--- a/Design & Experience/Game-Studies-Academic-Discourse.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-A0CB96
-category: "[[10_Wiki/💡 Topics/Design & Experience]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Game-Studies-Academic-Discourse"
----
-
-# [[Game-Studies-Academic-Discourse]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Design & Experience 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Game-Studies-Academic-Discourse.md]]
----
diff --git a/Design & Experience/Game-Studies-Journal.md b/Design & Experience/Game-Studies-Journal.md
deleted file mode 100644
index 47005a90..00000000
--- a/Design & Experience/Game-Studies-Journal.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-66A318
-category: "[[10_Wiki/💡 Topics/Design & Experience]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Game-Studies-Journal"
----
-
-# [[Game-Studies-Journal]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Design & Experience 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Game-Studies-Journal.md]]
----
diff --git a/Design & Experience/Gamification in Pedagogy.md b/Design & Experience/Gamification in Pedagogy.md
deleted file mode 100644
index afa91743..00000000
--- a/Design & Experience/Gamification in Pedagogy.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-0CBD32
-category: "[[10_Wiki/💡 Topics/Design & Experience]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Gamification in Pedagogy"
----
-
-# [[Gamification in Pedagogy]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Design & Experience 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Gamification in Pedagogy.md]]
----
diff --git a/Design & Experience/Gamification-Mechanics.md b/Design & Experience/Gamification-Mechanics.md
deleted file mode 100644
index 0a3eb006..00000000
--- a/Design & Experience/Gamification-Mechanics.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-687945
-category: "[[10_Wiki/💡 Topics/Design & Experience]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Gamification-Mechanics"
----
-
-# [[Gamification-Mechanics]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Design & Experience 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Gamification-Mechanics.md]]
----
diff --git a/Design & Experience/GitHub Actions.md b/Design & Experience/GitHub Actions.md
deleted file mode 100644
index 7f22201e..00000000
--- a/Design & Experience/GitHub Actions.md	
+++ /dev/null
@@ -1,34 +0,0 @@
----
-id: P-REINFORCE-AUTO-4CFD51
-category: "[[10_Wiki/💡 Topics/Design & Experience]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - GitHub Actions"
----
-
-# [[GitHub Actions]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> GitHub Actions는 주로 리눅스(Linux) 이미지를 기본 환경으로 사용하는 CI/CD(지속적 통합/지속적 배포) 파이프라인 도구(CI Runner)입니다 [1]. 정적 애플리케이션 보안 테스트(SAST) 및 취약점 스캔 도구들과 연동되어 개발 워크플로우 내에서 보안 검사를 자동화하는 데 주요하게 활용됩니다 [2, 3]. 다만 제공된 소스에서는 타 솔루션의 연동 환경 또는 공급망 공격의 사례로만 제한적으로 언급되고 있어 소스에 관련 정보가 부족합니다.
-
-## 📖 구조화된 지식 (Synthesized Content)
-소스에 관련 정보가 부족합니다. 제공된 문헌을 바탕으로 파악할 수 있는 GitHub Actions의 활용 맥락은 다음과 같습니다.
-
-* **보안 도구와의 CI/CD 통합:** GitHub Actions는 Snyk Code나 Endor Labs와 같은 애플리케이션 보안 스캐닝 도구들을 CI 워크플로우에 끊김 없이 연동할 수 있도록 지원합니다 [2, 4]. 개발자가 코드를 푸시(push)할 때 `snyk test`를 실행하게 하거나, Snyk Monitor 및 GitHub Code Scanning과 결합하여 자동화된 취약점 스캔 환경을 구축할 수 있습니다 [2, 3].
-* **운영 환경 특징:** CircleCI, GitLab과 같은 다른 CI 러너(runner) 도구들과 마찬가지로, GitHub Actions는 기본적으로 리눅스(Linux) 이미지 환경에서 동작합니다 [1]. 
-* **오픈소스 공급망 공격 리스크:** GitHub Actions의 액션(Action) 생태계 역시 공급망 공격의 대상이 될 수 있습니다. 합법적인 오픈소스 패키지가 손상되는 보안 위협(OWASP OSS Risk 2)의 대표적인 심층 연구 사례로 `tj-actions/changed-files` GitHub Action을 타깃으로 한 공급망 공격이 언급되었습니다 [5].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Design & Experience 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[CI/CD]], [[Static Application Security Testing (SAST)]], [[Supply Chain Attack]]
-- **Projects/Contexts:** [[Snyk]], [[Endor Labs]]
-- **Contradictions/Notes:** 소스에 GitHub Actions 자체의 동작 원리, 문법, 고유 기능 등에 대한 세부 정보는 전무하며, 단순히 외부 보안 솔루션 연동을 위한 파이프라인 환경 및 공급망 공격 사례의 일부로만 등장합니다.
-
----
-*Last updated: 2026-04-19*
-- Raw Source: [[00_Raw/2026-04-20/GitHub Actions.md]]
----
diff --git a/Design & Experience/Global Augmentation.md b/Design & Experience/Global Augmentation.md
deleted file mode 100644
index 90311745..00000000
--- a/Design & Experience/Global Augmentation.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-2CC24D
-category: "[[10_Wiki/💡 Topics/Design & Experience]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Global Augmentation"
----
-
-# [[Global Augmentation]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Design & Experience 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Global Augmentation.md]]
----
diff --git a/Design & Experience/Grammar-based-Synthesis.md b/Design & Experience/Grammar-based-Synthesis.md
deleted file mode 100644
index 5b0c9d69..00000000
--- a/Design & Experience/Grammar-based-Synthesis.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-35F81E
-category: "[[10_Wiki/💡 Topics/Design & Experience]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Grammar-based-Synthesis"
----
-
-# [[Grammar-based-Synthesis]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Design & Experience 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Grammar-based-Synthesis.md]]
----
diff --git a/Design & Experience/HUD-less Design Paradigms.md b/Design & Experience/HUD-less Design Paradigms.md
deleted file mode 100644
index 656103c9..00000000
--- a/Design & Experience/HUD-less Design Paradigms.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-4CD4F1
-category: "[[10_Wiki/💡 Topics/Design & Experience]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - HUD-less Design Paradigms"
----
-
-# [[HUD-less Design Paradigms]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Design & Experience 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/HUD-less Design Paradigms.md]]
----
diff --git a/Design & Experience/Haptic Feedback Technology.md b/Design & Experience/Haptic Feedback Technology.md
deleted file mode 100644
index f6aca0b8..00000000
--- a/Design & Experience/Haptic Feedback Technology.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-3637D3
-category: "[[10_Wiki/💡 Topics/Design & Experience]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Haptic Feedback Technology"
----
-
-# [[Haptic Feedback Technology]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Design & Experience 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Haptic Feedback Technology.md]]
----
diff --git a/Design & Experience/Hierarchical Reinforcement Learning (HRL).md b/Design & Experience/Hierarchical Reinforcement Learning (HRL).md
deleted file mode 100644
index bc4fc619..00000000
--- a/Design & Experience/Hierarchical Reinforcement Learning (HRL).md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-535DD0
-category: "[[10_Wiki/💡 Topics/Design & Experience]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Hierarchical Reinforcement Learning (HRL)"
----
-
-# [[Hierarchical Reinforcement Learning (HRL)]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Design & Experience 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Hierarchical Reinforcement Learning (HRL).md]]
----
diff --git a/Design & Experience/High-Performance-Human-Factors.md b/Design & Experience/High-Performance-Human-Factors.md
deleted file mode 100644
index 56eadf78..00000000
--- a/Design & Experience/High-Performance-Human-Factors.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-0DEE60
-category: "[[10_Wiki/💡 Topics/Design & Experience]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - High-Performance-Human-Factors"
----
-
-# [[High-Performance-Human-Factors]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Design & Experience 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/High-Performance-Human-Factors.md]]
----
diff --git a/Design & Experience/Human-Computer Interaction (HCI).md b/Design & Experience/Human-Computer Interaction (HCI).md
deleted file mode 100644
index 7ab258ea..00000000
--- a/Design & Experience/Human-Computer Interaction (HCI).md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-5F4DD2
-category: "[[10_Wiki/💡 Topics/Design & Experience]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Human-Computer Interaction (HCI)"
----
-
-# [[Human-Computer Interaction (HCI)]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Design & Experience 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Human-Computer Interaction (HCI).md]]
----
diff --git a/Design & Experience/Human-Computer-Interaction (HCI).md b/Design & Experience/Human-Computer-Interaction (HCI).md
deleted file mode 100644
index 8f9890df..00000000
--- a/Design & Experience/Human-Computer-Interaction (HCI).md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-AFBB70
-category: "[[10_Wiki/💡 Topics/Design & Experience]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Human-Computer-Interaction (HCI)"
----
-
-# [[Human-Computer-Interaction (HCI)]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Design & Experience 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Human-Computer-Interaction (HCI).md]]
----
diff --git a/Design & Experience/Human-Machine Interface (HMI) Design.md b/Design & Experience/Human-Machine Interface (HMI) Design.md
deleted file mode 100644
index a1b439e4..00000000
--- a/Design & Experience/Human-Machine Interface (HMI) Design.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-F753F2
-category: "[[10_Wiki/💡 Topics/Design & Experience]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Human-Machine Interface (HMI) Design"
----
-
-# [[Human-Machine Interface (HMI) Design]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Design & Experience 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Human-Machine Interface (HMI) Design.md]]
----
diff --git a/Design & Experience/Human-Robot Interaction (HRI).md b/Design & Experience/Human-Robot Interaction (HRI).md
deleted file mode 100644
index 5ce0173f..00000000
--- a/Design & Experience/Human-Robot Interaction (HRI).md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-695BBA
-category: "[[10_Wiki/💡 Topics/Design & Experience]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Human-Robot Interaction (HRI)"
----
-
-# [[Human-Robot Interaction (HRI)]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Design & Experience 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Human-Robot Interaction (HRI).md]]
----
diff --git a/Design & Experience/Human-Robot-Interaction.md b/Design & Experience/Human-Robot-Interaction.md
deleted file mode 100644
index 11867614..00000000
--- a/Design & Experience/Human-Robot-Interaction.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-419DF4
-category: "[[10_Wiki/💡 Topics/Design & Experience]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Human-Robot-Interaction"
----
-
-# [[Human-Robot-Interaction]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Design & Experience 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Human-Robot-Interaction.md]]
----
diff --git a/Design & Experience/Hypertextuality.md b/Design & Experience/Hypertextuality.md
deleted file mode 100644
index 9ce325ee..00000000
--- a/Design & Experience/Hypertextuality.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-B134AC
-category: "[[10_Wiki/💡 Topics/Design & Experience]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Hypertextuality"
----
-
-# [[Hypertextuality]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Design & Experience 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Hypertextuality.md]]
----
diff --git a/Design & Experience/ISO 9241 표준.md b/Design & Experience/ISO 9241 표준.md
deleted file mode 100644
index 430238d4..00000000
--- a/Design & Experience/ISO 9241 표준.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-E70ECC
-category: "[[10_Wiki/💡 Topics/Design & Experience]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - ISO 9241 표준"
----
-
-# [[ISO 9241 표준]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Design & Experience 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/ISO 9241 표준.md]]
----
diff --git a/Design & Experience/Immersive Analytics.md b/Design & Experience/Immersive Analytics.md
deleted file mode 100644
index b3c27365..00000000
--- a/Design & Experience/Immersive Analytics.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-4B1137
-category: "[[10_Wiki/💡 Topics/Design & Experience]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Immersive Analytics"
----
-
-# [[Immersive Analytics]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Design & Experience 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Immersive Analytics.md]]
----
diff --git a/Design & Experience/Incremental-Compilation.md b/Design & Experience/Incremental-Compilation.md
deleted file mode 100644
index e5cb46df..00000000
--- a/Design & Experience/Incremental-Compilation.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-836C53
-category: "[[10_Wiki/💡 Topics/Design & Experience]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Incremental-Compilation"
----
-
-# [[Incremental-Compilation]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Design & Experience 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Incremental-Compilation.md]]
----
diff --git a/Design & Experience/Information-Architecture.md b/Design & Experience/Information-Architecture.md
deleted file mode 100644
index ee9f1236..00000000
--- a/Design & Experience/Information-Architecture.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-B98E5E
-category: "[[10_Wiki/💡 Topics/Design & Experience]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Information-Architecture"
----
-
-# [[Information-Architecture]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Design & Experience 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Information-Architecture.md]]
----
diff --git a/Design & Experience/Inquiry-Based Learning.md b/Design & Experience/Inquiry-Based Learning.md
deleted file mode 100644
index c4ea3492..00000000
--- a/Design & Experience/Inquiry-Based Learning.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-0A7A61
-category: "[[10_Wiki/💡 Topics/Design & Experience]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Inquiry-Based Learning"
----
-
-# [[Inquiry-Based Learning]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Design & Experience 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Inquiry-Based Learning.md]]
----
diff --git a/Design & Experience/Interface Segregation Principle (ISP).md b/Design & Experience/Interface Segregation Principle (ISP).md
deleted file mode 100644
index f9fd6316..00000000
--- a/Design & Experience/Interface Segregation Principle (ISP).md	
+++ /dev/null
@@ -1,33 +0,0 @@
----
-id: P-REINFORCE-AUTO-317AB6
-category: "[[10_Wiki/💡 Topics/Design & Experience]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Interface Segregation Principle (ISP)"
----
-
-# [[Interface Segregation Principle (ISP)]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 인터페이스 분리 원칙(Interface Segregation Principle, ISP)은 클라이언트가 자신이 사용하지 않는 동작이나 액션에 의존하도록 강요받아서는 안 된다는 소프트웨어 설계 원칙입니다 [1, 2]. 이 원칙은 불필요한 기능까지 묶여 있는 방대한 '뚱뚱한(fat)' 인터페이스 대신, 목적이 뚜렷하고 초점이 맞춰진(focused) 인터페이스를 사용할 것을 권장합니다 [2]. 이를 통해 각 클라이언트는 정확히 필요한 기능에만 의존할 수 있으며, 불필요한 코드의 무게를 줄이고 테스트 및 업그레이드를 단순화할 수 있습니다 [3].
-
-## 📖 구조화된 지식 (Synthesized Content)
-- **초점이 맞춰진 계약(Focused Contracts)**: ISP는 SOLID 원칙의 'I'에 해당하며, 클라이언트가 사용하지 않는 인터페이스에 의존하지 않도록 계약의 범위를 명확히 제한해야 함을 강조합니다 [1, 2].
-- **분리의 신호(Sign to Split)**: 인터페이스에 하나 이상의 '도메인 동사(domain verb)'가 포함되어 있다면(예: `play`, `record`, `stream` 기능을 모두 포함한 `MediaPlayer` 인터페이스), 이는 해당 인터페이스를 분리해야 한다는 강력한 신호입니다 [2, 3].
-- **유연한 조합과 의존성 최소화**: 기존의 방대한 인터페이스를 `Playable`, `Recordable`, `Streamable`과 같이 분리된 단위로 쪼개면, 클라이언트는 필요한 인터페이스만 선택적으로 가져올 수 있습니다 [3]. 이는 불필요한 의존성(dead weight)을 제거하여 향후 시스템 업그레이드와 테스트 과정을 크게 단순화합니다 [3].
-- **결합도 감소와 확장성 확보**: 하나의 인터페이스가 너무 많은 책임을 갖게 되면 시스템이 변경에 취약해집니다 [4]. 인터페이스를 최소 단위로 분리하고 이를 필요한 시점에 조합하여 사용하는 방식은 시스템 간의 결합도를 낮추고, 수정에는 닫혀 있고 확장에는 열려 있는 견고한 아키텍처를 구축하는 핵심 전략이 됩니다 [4].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Design & Experience 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[SOLID Design Principles]], [[Single Responsibility Principle (SRP)]], [[Facade Pattern]]
-- **Projects/Contexts:** [[TypeScript/JavaScript Architecture]], [[Toss Front SDK]]
-- **Contradictions/Notes:** 소스 내에 ISP에 반대되는 주장은 없습니다. 추가적인 참고 사항으로, 소스는 인터페이스에 여러 도메인 동사가 존재할 경우 이를 분리하는 기준으로 삼으라고 조언합니다 [3].
-
----
-*Last updated: 2026-04-18*
-- Raw Source: [[00_Raw/2026-04-20/Interface Segregation Principle (ISP).md]]
----
diff --git a/Design & Experience/Interface-Extension-vs-Augmentation.md b/Design & Experience/Interface-Extension-vs-Augmentation.md
deleted file mode 100644
index bd19cde5..00000000
--- a/Design & Experience/Interface-Extension-vs-Augmentation.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-326071
-category: "[[10_Wiki/💡 Topics/Design & Experience]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Interface-Extension-vs-Augmentation"
----
-
-# [[Interface-Extension-vs-Augmentation]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Design & Experience 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Interface-Extension-vs-Augmentation.md]]
----
diff --git a/Design & Experience/Interface-Extension.md b/Design & Experience/Interface-Extension.md
deleted file mode 100644
index 7559ba4f..00000000
--- a/Design & Experience/Interface-Extension.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-B72832
-category: "[[10_Wiki/💡 Topics/Design & Experience]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Interface-Extension"
----
-
-# [[Interface-Extension]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Design & Experience 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Interface-Extension.md]]
----
diff --git a/Design & Experience/Interface-Merging.md b/Design & Experience/Interface-Merging.md
deleted file mode 100644
index 1e53551f..00000000
--- a/Design & Experience/Interface-Merging.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-223BC6
-category: "[[10_Wiki/💡 Topics/Design & Experience]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Interface-Merging"
----
-
-# [[Interface-Merging]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Design & Experience 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Interface-Merging.md]]
----
diff --git a/Design & Experience/Interface-Segregation-Principle-in-TypeScript.md b/Design & Experience/Interface-Segregation-Principle-in-TypeScript.md
deleted file mode 100644
index e34c754e..00000000
--- a/Design & Experience/Interface-Segregation-Principle-in-TypeScript.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-44AA84
-category: "[[10_Wiki/💡 Topics/Design & Experience]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Interface-Segregation-Principle-in-TypeScript"
----
-
-# [[Interface-Segregation-Principle-in-TypeScript]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Design & Experience 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Interface-Segregation-Principle-in-TypeScript.md]]
----
diff --git a/Design & Experience/Interface-Segregation-Principle.md b/Design & Experience/Interface-Segregation-Principle.md
deleted file mode 100644
index 813b7a85..00000000
--- a/Design & Experience/Interface-Segregation-Principle.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-92EBE7
-category: "[[10_Wiki/💡 Topics/Design & Experience]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Interface-Segregation-Principle"
----
-
-# [[Interface-Segregation-Principle]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Design & Experience 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Interface-Segregation-Principle.md]]
----
diff --git a/Design & Experience/Interoperability Standards.md b/Design & Experience/Interoperability Standards.md
deleted file mode 100644
index 14469852..00000000
--- a/Design & Experience/Interoperability Standards.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-3EE866
-category: "[[10_Wiki/💡 Topics/Design & Experience]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Interoperability Standards"
----
-
-# [[Interoperability Standards]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Design & Experience 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Interoperability Standards.md]]
----
diff --git a/Design & Experience/Intersection-Types-vs-Interface-Extension.md b/Design & Experience/Intersection-Types-vs-Interface-Extension.md
deleted file mode 100644
index 2cabab52..00000000
--- a/Design & Experience/Intersection-Types-vs-Interface-Extension.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-94C8CB
-category: "[[10_Wiki/💡 Topics/Design & Experience]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Intersection-Types-vs-Interface-Extension"
----
-
-# [[Intersection-Types-vs-Interface-Extension]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Design & Experience 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Intersection-Types-vs-Interface-Extension.md]]
----
diff --git a/Design & Experience/Inverse-Kinematics.md b/Design & Experience/Inverse-Kinematics.md
deleted file mode 100644
index f0b3e550..00000000
--- a/Design & Experience/Inverse-Kinematics.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-67139B
-category: "[[10_Wiki/💡 Topics/Design & Experience]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Inverse-Kinematics"
----
-
-# [[Inverse-Kinematics]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Design & Experience 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Inverse-Kinematics.md]]
----
diff --git a/Design & Experience/JSON-Schema-Validation.md b/Design & Experience/JSON-Schema-Validation.md
deleted file mode 100644
index d5d37219..00000000
--- a/Design & Experience/JSON-Schema-Validation.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-6A507C
-category: "[[10_Wiki/💡 Topics/Design & Experience]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - JSON-Schema-Validation"
----
-
-# [[JSON-Schema-Validation]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Design & Experience 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/JSON-Schema-Validation.md]]
----
diff --git a/Design & Experience/K-12-EdTech.md b/Design & Experience/K-12-EdTech.md
deleted file mode 100644
index 31527647..00000000
--- a/Design & Experience/K-12-EdTech.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-5653C7
-category: "[[10_Wiki/💡 Topics/Design & Experience]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - K-12-EdTech"
----
-
-# [[K-12-EdTech]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Design & Experience 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/K-12-EdTech.md]]
----
diff --git a/Design & Experience/Kinetics.md b/Design & Experience/Kinetics.md
deleted file mode 100644
index 94ecba11..00000000
--- a/Design & Experience/Kinetics.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-11AAD0
-category: "[[10_Wiki/💡 Topics/Design & Experience]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Kinetics"
----
-
-# [[Kinetics]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Design & Experience 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Kinetics.md]]
----
diff --git a/Design & Experience/Knowledge-Graph-Construction.md b/Design & Experience/Knowledge-Graph-Construction.md
deleted file mode 100644
index 4398c9ea..00000000
--- a/Design & Experience/Knowledge-Graph-Construction.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-84AB19
-category: "[[10_Wiki/💡 Topics/Design & Experience]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Knowledge-Graph-Construction"
----
-
-# [[Knowledge-Graph-Construction]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Design & Experience 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Knowledge-Graph-Construction.md]]
----
diff --git a/Design & Experience/LCS (League of Legends Championship Series).md b/Design & Experience/LCS (League of Legends Championship Series).md
deleted file mode 100644
index ba3c96f8..00000000
--- a/Design & Experience/LCS (League of Legends Championship Series).md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-FC3F77
-category: "[[10_Wiki/💡 Topics/Design & Experience]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - LCS (League of Legends Championship Series)"
----
-
-# [[LCS (League of Legends Championship Series)]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Design & Experience 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/LCS (League of Legends Championship Series).md]]
----
diff --git a/Design & Experience/Lean-UX.md b/Design & Experience/Lean-UX.md
deleted file mode 100644
index 7c2198ad..00000000
--- a/Design & Experience/Lean-UX.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-D3F181
-category: "[[10_Wiki/💡 Topics/Design & Experience]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Lean-UX"
----
-
-# [[Lean-UX]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Design & Experience 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Lean-UX.md]]
----
diff --git a/Design & Experience/Level Design Theory.md b/Design & Experience/Level Design Theory.md
deleted file mode 100644
index c8bdb402..00000000
--- a/Design & Experience/Level Design Theory.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-9BB940
-category: "[[10_Wiki/💡 Topics/Design & Experience]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Level Design Theory"
----
-
-# [[Level Design Theory]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Design & Experience 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Level Design Theory.md]]
----
diff --git a/Design & Experience/Level-Design-Theory.md b/Design & Experience/Level-Design-Theory.md
deleted file mode 100644
index dcc354d8..00000000
--- a/Design & Experience/Level-Design-Theory.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-5EAC4F
-category: "[[10_Wiki/💡 Topics/Design & Experience]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Level-Design-Theory"
----
-
-# [[Level-Design-Theory]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Design & Experience 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Level-Design-Theory.md]]
----
diff --git a/Design & Experience/Linguistics.md b/Design & Experience/Linguistics.md
deleted file mode 100644
index 60f82eb3..00000000
--- a/Design & Experience/Linguistics.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-0C81F3
-category: "[[10_Wiki/💡 Topics/Design & Experience]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Linguistics"
----
-
-# [[Linguistics]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Design & Experience 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Linguistics.md]]
----
diff --git a/Design & Experience/Linked-Data-Principles.md b/Design & Experience/Linked-Data-Principles.md
deleted file mode 100644
index 320e5d38..00000000
--- a/Design & Experience/Linked-Data-Principles.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-878BEE
-category: "[[10_Wiki/💡 Topics/Design & Experience]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Linked-Data-Principles"
----
-
-# [[Linked-Data-Principles]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Design & Experience 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Linked-Data-Principles.md]]
----
diff --git a/Design & Experience/Liskov-Substitution-Principle.md b/Design & Experience/Liskov-Substitution-Principle.md
deleted file mode 100644
index 97279c2a..00000000
--- a/Design & Experience/Liskov-Substitution-Principle.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-A4E734
-category: "[[10_Wiki/💡 Topics/Design & Experience]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Liskov-Substitution-Principle"
----
-
-# [[Liskov-Substitution-Principle]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Design & Experience 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Liskov-Substitution-Principle.md]]
----
diff --git a/Design & Experience/Ludo-Narrative-Dissonance.md b/Design & Experience/Ludo-Narrative-Dissonance.md
deleted file mode 100644
index 7473ac48..00000000
--- a/Design & Experience/Ludo-Narrative-Dissonance.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-D2276C
-category: "[[10_Wiki/💡 Topics/Design & Experience]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Ludo-Narrative-Dissonance"
----
-
-# [[Ludo-Narrative-Dissonance]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Design & Experience 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Ludo-Narrative-Dissonance.md]]
----
diff --git a/Design & Experience/Ludo-narrative Dissonance.md b/Design & Experience/Ludo-narrative Dissonance.md
deleted file mode 100644
index 12079d3a..00000000
--- a/Design & Experience/Ludo-narrative Dissonance.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-2B9D2D
-category: "[[10_Wiki/💡 Topics/Design & Experience]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Ludo-narrative Dissonance"
----
-
-# [[Ludo-narrative Dissonance]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Design & Experience 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Ludo-narrative Dissonance.md]]
----
diff --git a/Design & Experience/Ludonarrative-Dissonance.md b/Design & Experience/Ludonarrative-Dissonance.md
deleted file mode 100644
index eb74a0dc..00000000
--- a/Design & Experience/Ludonarrative-Dissonance.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-488A12
-category: "[[10_Wiki/💡 Topics/Design & Experience]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Ludonarrative-Dissonance"
----
-
-# [[Ludonarrative-Dissonance]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Design & Experience 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Ludonarrative-Dissonance.md]]
----
diff --git a/Design & Experience/Mapped-Types.md b/Design & Experience/Mapped-Types.md
deleted file mode 100644
index 5b13e7a7..00000000
--- a/Design & Experience/Mapped-Types.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-A475F9
-category: "[[10_Wiki/💡 Topics/Design & Experience]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Mapped-Types"
----
-
-# [[Mapped-Types]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Design & Experience 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Mapped-Types.md]]
----
diff --git a/Design & Experience/Material Design System.md b/Design & Experience/Material Design System.md
deleted file mode 100644
index 2f4649e2..00000000
--- a/Design & Experience/Material Design System.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-ABFF7B
-category: "[[10_Wiki/💡 Topics/Design & Experience]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Material Design System"
----
-
-# [[Material Design System]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Design & Experience 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Material Design System.md]]
----
diff --git a/Design & Experience/Material Design.md b/Design & Experience/Material Design.md
deleted file mode 100644
index 7760b59c..00000000
--- a/Design & Experience/Material Design.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-2349C5
-category: "[[10_Wiki/💡 Topics/Design & Experience]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Material Design"
----
-
-# [[Material Design]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Design & Experience 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Material Design.md]]
----
diff --git a/Design & Experience/Material-Design.md b/Design & Experience/Material-Design.md
deleted file mode 100644
index e304dbed..00000000
--- a/Design & Experience/Material-Design.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-03A898
-category: "[[10_Wiki/💡 Topics/Design & Experience]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Material-Design"
----
-
-# [[Material-Design]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Design & Experience 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Material-Design.md]]
----
diff --git a/Design & Experience/Mechanism Design in Auctions.md b/Design & Experience/Mechanism Design in Auctions.md
deleted file mode 100644
index e0294b13..00000000
--- a/Design & Experience/Mechanism Design in Auctions.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-03623E
-category: "[[10_Wiki/💡 Topics/Design & Experience]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Mechanism Design in Auctions"
----
-
-# [[Mechanism Design in Auctions]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Design & Experience 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Mechanism Design in Auctions.md]]
----
diff --git a/Design & Experience/Mechanism Design.md b/Design & Experience/Mechanism Design.md
deleted file mode 100644
index 601fed02..00000000
--- a/Design & Experience/Mechanism Design.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-3A7080
-category: "[[10_Wiki/💡 Topics/Design & Experience]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Mechanism Design"
----
-
-# [[Mechanism Design]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Design & Experience 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Mechanism Design.md]]
----
diff --git a/Design & Experience/Mechanism-Design.md b/Design & Experience/Mechanism-Design.md
deleted file mode 100644
index b5f600d5..00000000
--- a/Design & Experience/Mechanism-Design.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-F9F796
-category: "[[10_Wiki/💡 Topics/Design & Experience]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Mechanism-Design"
----
-
-# [[Mechanism-Design]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Design & Experience 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Mechanism-Design.md]]
----
diff --git a/Design & Experience/Micro-Frontend-Architecture.md b/Design & Experience/Micro-Frontend-Architecture.md
deleted file mode 100644
index 592ba0af..00000000
--- a/Design & Experience/Micro-Frontend-Architecture.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-070141
-category: "[[10_Wiki/💡 Topics/Design & Experience]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Micro-Frontend-Architecture"
----
-
-# [[Micro-Frontend-Architecture]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Design & Experience 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Micro-Frontend-Architecture.md]]
----
diff --git a/Design & Experience/Mobile-App-Onboarding.md b/Design & Experience/Mobile-App-Onboarding.md
deleted file mode 100644
index 8cab5c88..00000000
--- a/Design & Experience/Mobile-App-Onboarding.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-D7506D
-category: "[[10_Wiki/💡 Topics/Design & Experience]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Mobile-App-Onboarding"
----
-
-# [[Mobile-App-Onboarding]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Design & Experience 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Mobile-App-Onboarding.md]]
----
diff --git a/Design & Experience/Module Resolution Algorithm.md b/Design & Experience/Module Resolution Algorithm.md
deleted file mode 100644
index 35959b6f..00000000
--- a/Design & Experience/Module Resolution Algorithm.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-DE6CBC
-category: "[[10_Wiki/💡 Topics/Design & Experience]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Module Resolution Algorithm"
----
-
-# [[Module Resolution Algorithm]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Design & Experience 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Module Resolution Algorithm.md]]
----
diff --git a/Design & Experience/Module-Augmentation-Patterns.md b/Design & Experience/Module-Augmentation-Patterns.md
deleted file mode 100644
index db93c019..00000000
--- a/Design & Experience/Module-Augmentation-Patterns.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-D54DFE
-category: "[[10_Wiki/💡 Topics/Design & Experience]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Module-Augmentation-Patterns"
----
-
-# [[Module-Augmentation-Patterns]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Design & Experience 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Module-Augmentation-Patterns.md]]
----
diff --git a/Design & Experience/Module-Resolution-Strategy.md b/Design & Experience/Module-Resolution-Strategy.md
deleted file mode 100644
index d2ae2f13..00000000
--- a/Design & Experience/Module-Resolution-Strategy.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-029B7A
-category: "[[10_Wiki/💡 Topics/Design & Experience]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Module-Resolution-Strategy"
----
-
-# [[Module-Resolution-Strategy]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Design & Experience 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Module-Resolution-Strategy.md]]
----
diff --git a/Design & Experience/Monorepo-Architecture-Design.md b/Design & Experience/Monorepo-Architecture-Design.md
deleted file mode 100644
index 5ebe3d0d..00000000
--- a/Design & Experience/Monorepo-Architecture-Design.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-4265B0
-category: "[[10_Wiki/💡 Topics/Design & Experience]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Monorepo-Architecture-Design"
----
-
-# [[Monorepo-Architecture-Design]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Design & Experience 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Monorepo-Architecture-Design.md]]
----
diff --git a/Design & Experience/Monorepo-Architecture.md b/Design & Experience/Monorepo-Architecture.md
deleted file mode 100644
index 07bed307..00000000
--- a/Design & Experience/Monorepo-Architecture.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-69C266
-category: "[[10_Wiki/💡 Topics/Design & Experience]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Monorepo-Architecture"
----
-
-# [[Monorepo-Architecture]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Design & Experience 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Monorepo-Architecture.md]]
----
diff --git a/Design & Experience/Monorepo-Dependency-Graph-Analysis.md b/Design & Experience/Monorepo-Dependency-Graph-Analysis.md
deleted file mode 100644
index b4fec12d..00000000
--- a/Design & Experience/Monorepo-Dependency-Graph-Analysis.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-99AA42
-category: "[[10_Wiki/💡 Topics/Design & Experience]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Monorepo-Dependency-Graph-Analysis"
----
-
-# [[Monorepo-Dependency-Graph-Analysis]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Design & Experience 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Monorepo-Dependency-Graph-Analysis.md]]
----
diff --git a/Design & Experience/Monte Carlo Tree Search (MCTS).md b/Design & Experience/Monte Carlo Tree Search (MCTS).md
deleted file mode 100644
index 99145087..00000000
--- a/Design & Experience/Monte Carlo Tree Search (MCTS).md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-2E53F8
-category: "[[10_Wiki/💡 Topics/Design & Experience]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Monte Carlo Tree Search (MCTS)"
----
-
-# [[Monte Carlo Tree Search (MCTS)]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Design & Experience 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Monte Carlo Tree Search (MCTS).md]]
----
diff --git a/Design & Experience/Motor-Learning-Theory.md b/Design & Experience/Motor-Learning-Theory.md
deleted file mode 100644
index 06763722..00000000
--- a/Design & Experience/Motor-Learning-Theory.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-D69E40
-category: "[[10_Wiki/💡 Topics/Design & Experience]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Motor-Learning-Theory"
----
-
-# [[Motor-Learning-Theory]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Design & Experience 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Motor-Learning-Theory.md]]
----
diff --git a/Design & Experience/Motor-Learning.md b/Design & Experience/Motor-Learning.md
deleted file mode 100644
index db3f0111..00000000
--- a/Design & Experience/Motor-Learning.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-F3DEAC
-category: "[[10_Wiki/💡 Topics/Design & Experience]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Motor-Learning"
----
-
-# [[Motor-Learning]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Design & Experience 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Motor-Learning.md]]
----
diff --git a/Design & Experience/Narrative Design.md b/Design & Experience/Narrative Design.md
deleted file mode 100644
index 5d493154..00000000
--- a/Design & Experience/Narrative Design.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-680D4B
-category: "[[10_Wiki/💡 Topics/Design & Experience]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Narrative Design"
----
-
-# [[Narrative Design]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Design & Experience 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Narrative Design.md]]
----
diff --git a/Design & Experience/Narrative Intelligence.md b/Design & Experience/Narrative Intelligence.md
deleted file mode 100644
index 96d07bd2..00000000
--- a/Design & Experience/Narrative Intelligence.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-89EE25
-category: "[[10_Wiki/💡 Topics/Design & Experience]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Narrative Intelligence"
----
-
-# [[Narrative Intelligence]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Design & Experience 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Narrative Intelligence.md]]
----
diff --git a/Design & Experience/Nash Equilibrium.md b/Design & Experience/Nash Equilibrium.md
deleted file mode 100644
index d1cb5318..00000000
--- a/Design & Experience/Nash Equilibrium.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-762E86
-category: "[[10_Wiki/💡 Topics/Design & Experience]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Nash Equilibrium"
----
-
-# [[Nash Equilibrium]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Design & Experience 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Nash Equilibrium.md]]
----
diff --git a/Design & Experience/Nash-Equilibrium.md b/Design & Experience/Nash-Equilibrium.md
deleted file mode 100644
index c311dae1..00000000
--- a/Design & Experience/Nash-Equilibrium.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-453B61
-category: "[[10_Wiki/💡 Topics/Design & Experience]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Nash-Equilibrium"
----
-
-# [[Nash-Equilibrium]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Design & Experience 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Nash-Equilibrium.md]]
----
diff --git a/Design & Experience/Ninja-Build-System.md b/Design & Experience/Ninja-Build-System.md
deleted file mode 100644
index 43ec8036..00000000
--- a/Design & Experience/Ninja-Build-System.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-18A8ED
-category: "[[10_Wiki/💡 Topics/Design & Experience]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Ninja-Build-System"
----
-
-# [[Ninja-Build-System]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Design & Experience 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Ninja-Build-System.md]]
----
diff --git a/Design & Experience/Nodejs-Backend-Architecture.md b/Design & Experience/Nodejs-Backend-Architecture.md
deleted file mode 100644
index 61e860e9..00000000
--- a/Design & Experience/Nodejs-Backend-Architecture.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-A782C0
-category: "[[10_Wiki/💡 Topics/Design & Experience]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Nodejs-Backend-Architecture"
----
-
-# [[Nodejs-Backend-Architecture]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Design & Experience 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Node.js-Backend-Architecture.md]]
----
diff --git a/Design & Experience/Nominal Typing.md b/Design & Experience/Nominal Typing.md
deleted file mode 100644
index dd9a9aca..00000000
--- a/Design & Experience/Nominal Typing.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-29D050
-category: "[[10_Wiki/💡 Topics/Design & Experience]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Nominal Typing"
----
-
-# [[Nominal Typing]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Design & Experience 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Nominal Typing.md]]
----
diff --git a/Design & Experience/Nominal-Typing-via-Branded-Types.md b/Design & Experience/Nominal-Typing-via-Branded-Types.md
deleted file mode 100644
index e8e832f6..00000000
--- a/Design & Experience/Nominal-Typing-via-Branded-Types.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-695155
-category: "[[10_Wiki/💡 Topics/Design & Experience]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Nominal-Typing-via-Branded-Types"
----
-
-# [[Nominal-Typing-via-Branded-Types]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Design & Experience 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Nominal-Typing-via-Branded-Types.md]]
----
diff --git a/Design & Experience/Nominal-Typing-vs-Structural-Typing.md b/Design & Experience/Nominal-Typing-vs-Structural-Typing.md
deleted file mode 100644
index b857e52c..00000000
--- a/Design & Experience/Nominal-Typing-vs-Structural-Typing.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-1B9D2D
-category: "[[10_Wiki/💡 Topics/Design & Experience]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Nominal-Typing-vs-Structural-Typing"
----
-
-# [[Nominal-Typing-vs-Structural-Typing]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Design & Experience 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Nominal-Typing-vs-Structural-Typing.md]]
----
diff --git a/Design & Experience/Nominal-vs-Structural-Typing.md b/Design & Experience/Nominal-vs-Structural-Typing.md
deleted file mode 100644
index 59c16485..00000000
--- a/Design & Experience/Nominal-vs-Structural-Typing.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-F75BC3
-category: "[[10_Wiki/💡 Topics/Design & Experience]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Nominal-vs-Structural-Typing"
----
-
-# [[Nominal-vs-Structural-Typing]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Design & Experience 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Nominal-vs-Structural-Typing.md]]
----
diff --git a/Design & Experience/Non-Diegetic UI.md b/Design & Experience/Non-Diegetic UI.md
deleted file mode 100644
index e8bf6f0b..00000000
--- a/Design & Experience/Non-Diegetic UI.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-0D2F57
-category: "[[10_Wiki/💡 Topics/Design & Experience]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Non-Diegetic UI"
----
-
-# [[Non-Diegetic UI]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Design & Experience 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Non-Diegetic UI.md]]
----
diff --git a/Design & Experience/Nx-Build-System.md b/Design & Experience/Nx-Build-System.md
deleted file mode 100644
index 404e8e51..00000000
--- a/Design & Experience/Nx-Build-System.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-D6169C
-category: "[[10_Wiki/💡 Topics/Design & Experience]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Nx-Build-System"
----
-
-# [[Nx-Build-System]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Design & Experience 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Nx-Build-System.md]]
----
diff --git a/Design & Experience/Object-Literal-Assignment.md b/Design & Experience/Object-Literal-Assignment.md
deleted file mode 100644
index a7546121..00000000
--- a/Design & Experience/Object-Literal-Assignment.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-8E1BDB
-category: "[[10_Wiki/💡 Topics/Design & Experience]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Object-Literal-Assignment"
----
-
-# [[Object-Literal-Assignment]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Design & Experience 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Object-Literal-Assignment.md]]
----
diff --git a/Design & Experience/Object-Oriented-Interface-Design.md b/Design & Experience/Object-Oriented-Interface-Design.md
deleted file mode 100644
index 5e7a9b3d..00000000
--- a/Design & Experience/Object-Oriented-Interface-Design.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-8CEF52
-category: "[[10_Wiki/💡 Topics/Design & Experience]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Object-Oriented-Interface-Design"
----
-
-# [[Object-Oriented-Interface-Design]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Design & Experience 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Object-Oriented-Interface-Design.md]]
----
diff --git a/Design & Experience/Occupational-Ergonomics.md b/Design & Experience/Occupational-Ergonomics.md
deleted file mode 100644
index 79c651a8..00000000
--- a/Design & Experience/Occupational-Ergonomics.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-92FABA
-category: "[[10_Wiki/💡 Topics/Design & Experience]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Occupational-Ergonomics"
----
-
-# [[Occupational-Ergonomics]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Design & Experience 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Occupational-Ergonomics.md]]
----
diff --git a/Design & Experience/OpenAPI-Specification.md b/Design & Experience/OpenAPI-Specification.md
deleted file mode 100644
index 6eb45bbd..00000000
--- a/Design & Experience/OpenAPI-Specification.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-B4497C
-category: "[[10_Wiki/💡 Topics/Design & Experience]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - OpenAPI-Specification"
----
-
-# [[OpenAPI-Specification]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Design & Experience 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/OpenAPI-Specification.md]]
----
diff --git a/Design & Experience/Optimal-Experience-Research.md b/Design & Experience/Optimal-Experience-Research.md
deleted file mode 100644
index 3fa7eecc..00000000
--- a/Design & Experience/Optimal-Experience-Research.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-BDC058
-category: "[[10_Wiki/💡 Topics/Design & Experience]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Optimal-Experience-Research"
----
-
-# [[Optimal-Experience-Research]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Design & Experience 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Optimal-Experience-Research.md]]
----
diff --git a/Design & Experience/Organizational Learning Culture.md b/Design & Experience/Organizational Learning Culture.md
deleted file mode 100644
index 9186976e..00000000
--- a/Design & Experience/Organizational Learning Culture.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-97FF1D
-category: "[[10_Wiki/💡 Topics/Design & Experience]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Organizational Learning Culture"
----
-
-# [[Organizational Learning Culture]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Design & Experience 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Organizational Learning Culture.md]]
----
diff --git a/Design & Experience/Organizational-Innovation-Management.md b/Design & Experience/Organizational-Innovation-Management.md
deleted file mode 100644
index 4f1280b5..00000000
--- a/Design & Experience/Organizational-Innovation-Management.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-27E3D1
-category: "[[10_Wiki/💡 Topics/Design & Experience]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Organizational-Innovation-Management"
----
-
-# [[Organizational-Innovation-Management]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Design & Experience 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Organizational-Innovation-Management.md]]
----
diff --git a/Design & Experience/Orthopedic-Implant-Validation.md b/Design & Experience/Orthopedic-Implant-Validation.md
deleted file mode 100644
index 349d8d72..00000000
--- a/Design & Experience/Orthopedic-Implant-Validation.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-9F5A29
-category: "[[10_Wiki/💡 Topics/Design & Experience]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Orthopedic-Implant-Validation"
----
-
-# [[Orthopedic-Implant-Validation]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Design & Experience 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Orthopedic-Implant-Validation.md]]
----
diff --git a/Design & Experience/Player Agency.md b/Design & Experience/Player Agency.md
deleted file mode 100644
index 380ee101..00000000
--- a/Design & Experience/Player Agency.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-83E12E
-category: "[[10_Wiki/💡 Topics/Design & Experience]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Player Agency"
----
-
-# [[Player Agency]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Design & Experience 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Player Agency.md]]
----
diff --git a/Design & Experience/Player-Autonomy.md b/Design & Experience/Player-Autonomy.md
deleted file mode 100644
index 34cff024..00000000
--- a/Design & Experience/Player-Autonomy.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-85AECB
-category: "[[10_Wiki/💡 Topics/Design & Experience]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Player-Autonomy"
----
-
-# [[Player-Autonomy]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Design & Experience 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Player-Autonomy.md]]
----
diff --git a/Design & Experience/Political-Philosophy-in-Games.md b/Design & Experience/Political-Philosophy-in-Games.md
deleted file mode 100644
index 5ededdfb..00000000
--- a/Design & Experience/Political-Philosophy-in-Games.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-9F478E
-category: "[[10_Wiki/💡 Topics/Design & Experience]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Political-Philosophy-in-Games"
----
-
-# [[Political-Philosophy-in-Games]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Design & Experience 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Political-Philosophy-in-Games.md]]
----
diff --git a/Design & Experience/Product-Analytics-Infrastructure.md b/Design & Experience/Product-Analytics-Infrastructure.md
deleted file mode 100644
index 31eb7711..00000000
--- a/Design & Experience/Product-Analytics-Infrastructure.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-B3941E
-category: "[[10_Wiki/💡 Topics/Design & Experience]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Product-Analytics-Infrastructure"
----
-
-# [[Product-Analytics-Infrastructure]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Design & Experience 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Product-Analytics-Infrastructure.md]]
----
diff --git a/Design & Experience/Protocol-Buffers-TypeScript.md b/Design & Experience/Protocol-Buffers-TypeScript.md
deleted file mode 100644
index 58fb9b91..00000000
--- a/Design & Experience/Protocol-Buffers-TypeScript.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-1F2F42
-category: "[[10_Wiki/💡 Topics/Design & Experience]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Protocol-Buffers-TypeScript"
----
-
-# [[Protocol-Buffers-TypeScript]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Design & Experience 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Protocol-Buffers-TypeScript.md]]
----
diff --git a/Design & Experience/Public Policy Design.md b/Design & Experience/Public Policy Design.md
deleted file mode 100644
index 07f74a09..00000000
--- a/Design & Experience/Public Policy Design.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-444363
-category: "[[10_Wiki/💡 Topics/Design & Experience]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Public Policy Design"
----
-
-# [[Public Policy Design]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Design & Experience 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Public Policy Design.md]]
----
diff --git a/Design & Experience/Quantum-Computing-Simulations.md b/Design & Experience/Quantum-Computing-Simulations.md
deleted file mode 100644
index 19440c55..00000000
--- a/Design & Experience/Quantum-Computing-Simulations.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-5FB7B9
-category: "[[10_Wiki/💡 Topics/Design & Experience]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Quantum-Computing-Simulations"
----
-
-# [[Quantum-Computing-Simulations]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Design & Experience 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Quantum-Computing-Simulations.md]]
----
diff --git a/Design & Experience/Rapier 물리 엔진 스냅샷(Snapshot) 기반 상태 복원.md b/Design & Experience/Rapier 물리 엔진 스냅샷(Snapshot) 기반 상태 복원.md
deleted file mode 100644
index b5fdfad3..00000000
--- a/Design & Experience/Rapier 물리 엔진 스냅샷(Snapshot) 기반 상태 복원.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-D58438
-category: "[[10_Wiki/💡 Topics/Design & Experience]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Rapier 물리 엔진 스냅샷(Snapshot) 기반 상태 복원"
----
-
-# [[Rapier 물리 엔진 스냅샷(Snapshot) 기반 상태 복원]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Design & Experience 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Rapier 물리 엔진 스냅샷(Snapshot) 기반 상태 복원.md]]
----
diff --git a/Design & Experience/React Native 게임 최적화 (JSI Hermes).md b/Design & Experience/React Native 게임 최적화 (JSI Hermes).md
deleted file mode 100644
index b41daadd..00000000
--- a/Design & Experience/React Native 게임 최적화 (JSI Hermes).md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-23E022
-category: "[[10_Wiki/💡 Topics/Design & Experience]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - React Native 게임 최적화 (JSI Hermes)"
----
-
-# [[React Native 게임 최적화 (JSI Hermes)]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Design & Experience 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/React Native 게임 최적화 (JSI, Hermes).md]]
----
diff --git a/Design & Experience/React Performance Optimization.md b/Design & Experience/React Performance Optimization.md
deleted file mode 100644
index 7f76fce0..00000000
--- a/Design & Experience/React Performance Optimization.md	
+++ /dev/null
@@ -1,41 +0,0 @@
----
-id: P-REINFORCE-AUTO-B068E2
-category: "[[10_Wiki/💡 Topics/Design & Experience]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - React Performance Optimization"
----
-
-# [[React Performance Optimization]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> React 애플리케이션에서 불필요한 렌더링을 줄이고, 자바스크립트 번들 크기를 최소화하며, 상태 관리 및 렌더링 파이프라인을 효율적으로 구성하여 빠르고 매끄러운 사용자 경험(UX)과 우수한 Core Web Vitals 지표를 달성하는 핵심 기술 및 아키텍처 전략입니다.
-
-## 📖 구조화된 지식 (Synthesized Content)
-**1. 렌더링 파이프라인과 재조정(Reconciliation) 최적화** React는 상태(State), 프롭스(Props), 컨텍스트(Context) 변경 시 혹은 부모 컴포넌트가 렌더링될 때 재렌더링을 수행합니다. 불필요한 하위 컴포넌트의 렌더링을 막기 위해 `React.memo`, `useMemo`, `useCallback`을 사용하여 참조 안정성(Reference Stability)을 유지합니다. 최신 React 19의 'React Compiler'를 도입하면 대부분의 메모이제이션이 빌드 타임에 자동으로 처리되어 수동 최적화 보일러플레이트 코드를 획기적으로 줄일 수 있습니다.
-
-**2. 코드 스플리팅(Code Splitting)과 지연 로딩(Lazy Loading)** 하나의 거대한 자바스크립트 번들은 초기 로딩 속도를 크게 저하시킵니다. `React.lazy`와 `Suspense`를 활용하여 라우트(Route) 기반 또는 무거운 컴포넌트(예: 차트, 비디오 에디터) 단위로 번들을 분할하면 초기 다운로드 용량을 줄여 앱의 반응 속도(TTI, Time to Interactive)를 높일 수 있습니다.
-
-**3. 효율적인 상태 관리 (State Management)** 상태는 부모로 과도하게 끌어올리지(State Lifting) 않고 최대한 사용하는 곳과 가까운 위치(Local)에 두어야 합니다. React 기본 Context API는 내부의 어떤 값이라도 변경되면 모든 소비자를 리렌더링시키므로 병목을 유발하기 쉽습니다. 따라서 고빈도로 업데이트되는 상태의 경우 컨텍스트를 도메인별로 잘게 쪼개거나, Zustand, Jotai, Valtio와 같이 선택적 구독(Selective Subscription)과 미세 조정(Fine-grained) 업데이트를 지원하는 고성능 전역 상태 관리 라이브러리를 도입하는 것이 유리합니다.
-
-**4. 대규모 리스트 가상화 (Virtualization / Windowing)** 수천 개의 항목을 한 번에 렌더링하면 DOM 노드가 폭증하여 브라우저가 멈출 수 있습니다. `react-window`나 `react-virtualized` 같은 라이브러리를 사용하여 현재 화면(Viewport)에 보이는 수십 개의 항목만 렌더링하고 나머지는 스크롤 시 동적으로 마운트하는 '가상화' 기법을 적용하면 렌더링 시간을 수 밀리초(ms) 단위로 줄일 수 있습니다. 이때 안정적이고 고유한 `key` 속성을 부여하는 것도 매우 중요합니다.
-
-**5. 동시성 기능(Concurrent Features)과 비동기 처리** React 18 이상에서 제공하는 `useTransition`과 `useDeferredValue` 훅을 사용하면 무거운 UI 업데이트를 비긴급(Non-urgent) 작업으로 미루고, 사용자의 타이핑이나 클릭 같은 긴급한 인터랙션을 끊김 없이 즉각적으로 처리할 수 있습니다. 더 나아가 이미지 처리나 물리 연산 등 CPU를 많이 소모하는 작업은 Web Worker(또는 `useWorker`)로 오프로딩하여 메인 스레드의 블로킹을 방지합니다.
-
-**6. React Server Components (RSC) 활용** Next.js와 같은 프레임워크 환경에서는 React Server Components를 적극 활용합니다. 인터랙션이 필요 없는 정적 UI는 서버에서 렌더링을 끝마친 채로 전송하여 클라이언트 측 자바스크립트 번들 사이즈를 획기적으로 줄이고 초기 페인팅 속도를 비약적으로 향상시킵니다.
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Design & Experience 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[React 19 Compiler]], [[재조정 (Reconciliation)]], [[상태 관리 최적화 (Zustand, Jotai, Valtio)]], [[Code Splitting & Lazy Loading]], [[React Server Components (RSC)]]
-- **Projects/Contexts:** [[대규모 E-commerce 및 대시보드 애플리케이션 구축]], [[고성능 멀티스레드 React 앱 아키텍처]], [[Next.js 기반 App Router 마이그레이션]]
-- **Contradictions/Notes:** 많은 개발자들이 컴포넌트가 느려지면 습관적으로 `useMemo`나 `React.memo`를 추가(Premature Memoization)하지만, 메모이제이션 자체에도 얕은 비교(Shallow Compare)라는 오버헤드가 발생합니다. 렌더링 자체가 빠르고 프롭스 변경이 빈번한 단순 컴포넌트에 이를 남용하면 오히려 메모리와 연산 자원만 낭비하므로 반드시 React DevTools Profiler로 측정한 후 적용해야 합니다. 또한 React 19 컴파일러가 아무리 자동화를 해주어도, 무분별한 상태 구조 등 근본적인 아키텍처 설계 결함을 고쳐주지는 않습니다.
-
----
-
-_Last updated: 2026-04-14_
-- Raw Source: [[00_Raw/2026-04-20/React Performance Optimization.md]]
----
diff --git a/Design & Experience/React 상태 관리 (React State Management).md b/Design & Experience/React 상태 관리 (React State Management).md
deleted file mode 100644
index 102ec073..00000000
--- a/Design & Experience/React 상태 관리 (React State Management).md	
+++ /dev/null
@@ -1,39 +0,0 @@
----
-id: P-REINFORCE-AUTO-3FAE48
-category: "[[10_Wiki/💡 Topics/Design & Experience]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - React 상태 관리 (React State Management)"
----
-
-# [[React 상태 관리 (React State Management)]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> React 상태 관리(React State Management)는 사용자 입력, API 응답, UI 설정 등 애플리케이션 내에서 시간에 따라 변화하는 데이터를 추적하고 유지하는 과정입니다 [1]. 타입스크립트 환경의 React에서는 구분된 유니언(Discriminated Unions)과 불변성(Immutability) 패턴을 활용하여 유효하지 않은 상태를 원천적으로 차단하는 것에 중점을 둡니다 [2-4]. 전반적인 React 자체의 상태 관리 메커니즘이나 라이브러리 생태계에 대해서는 소스에 관련 정보가 부족합니다.
-
-## 📖 구조화된 지식 (Synthesized Content)
-소스에 관련 정보가 부족합니다. (제공된 소스는 React의 전반적인 상태 관리 생태계보다는 TypeScript를 활용한 상태 보호 및 타입 패턴에 내용이 집중되어 있습니다. 확인 가능한 핵심 정보는 다음과 같습니다.)
-
-- **상태 관리의 중요성과 위험성**: 
-  상태(State)는 여러 위치에서 명확한 패턴 없이 수정될 경우 동작 예측이 불가능해지고 디버깅이 매우 어려워집니다 [5]. 또한, 불필요한 리렌더링이나 메모리 누수와 같은 심각한 성능 문제를 유발할 수 있으므로 철저한 관리가 필요합니다 [5].
-- **구분된 유니언(Discriminated Unions)의 활용**: 
-  React 상태 관리 방식을 혁신적으로 바꾸는 강력한 타입스크립트 패턴은 바로 '구분된 유니언'입니다 [2]. 이 패턴은 호환되지 않는 잘못된 상태(Invalid states)가 조합되는 것을 아예 불가능하게 만듭니다 [3]. 특히, Redux 스타일의 리듀서(Reducer) 로직, 라우터(Router) 상태 관리, 그리고 비동기 데이터 패칭(로딩, 성공, 실패 등)의 상태 머신(State Machine)을 모델링할 때 매우 효과적입니다 [6, 7].
-- **불변성(Immutability)의 강제**: 
-  안전한 상태 관리 및 리듀서 구현을 위해 객체의 데이터 변경(Mutation)을 방지해야 합니다 [8]. 이를 위해 `readonly` 수식어나 `Readonly<T>`, `DeepReadonly` 유틸리티 타입을 적용하여 상태 데이터가 초기화된 후 의도치 않게 조작되는 것을 컴파일 타임에 원천 차단할 수 있습니다 [4, 8, 9].
-- **주요 연관 패턴**: 
-  `useState` 및 `useEffect`를 활용한 기본적인 데이터 패칭 프로세스, 낙관적 업데이트(Optimistic Updates) 처리, 그리고 Context API를 사용할 때의 엄격한 타입 지정(Context 및 Selector 타이핑) 등이 React 상태 관리의 주요 구성 요소로 활용됩니다 [10, 11].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Design & Experience 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[Discriminated Unions]], [[Immutability]], [[State Machine Pattern]]
-- **Projects/Contexts:** [[Redux-style Reducers]], [[Context API]]
-- **Contradictions/Notes:** 소스 문서는 React 프레임워크 자체의 상태 관리 동작 원리(예: Virtual DOM과의 관계, 훅의 내부 원리 등)를 깊이 있게 다루기보다는, TypeScript의 타입 시스템(구분된 유니언, 불변성 등)을 React 상태 관리에 어떻게 접목하여 안정성을 높이는지에 초점이 맞추어져 있습니다.
-
----
-*Last updated: 2026-04-18*
-- Raw Source: [[00_Raw/2026-04-20/React 상태 관리 (React State Management).md]]
----
diff --git a/Design & Experience/React 상태 관리 및 API 응답 처리.md b/Design & Experience/React 상태 관리 및 API 응답 처리.md
deleted file mode 100644
index f5143aec..00000000
--- a/Design & Experience/React 상태 관리 및 API 응답 처리.md	
+++ /dev/null
@@ -1,34 +0,0 @@
----
-id: P-REINFORCE-AUTO-3E04B1
-category: "[[10_Wiki/💡 Topics/Design & Experience]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - React 상태 관리 및 API 응답 처리"
----
-
-# [[React 상태 관리 및 API 응답 처리]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> React 애플리케이션에서 상태 관리 및 API 응답 처리를 다룰 때, TypeScript의 식별 가능한 유니온(Discriminated Unions) 패턴을 활용하면 매우 효과적입니다 [1, 2]. 이 패턴은 상태의 유효하지 않은 조합을 원천적으로 불가능하게 만들고 컴파일러를 통해 안전한 타입 좁히기를 제공합니다 [3, 4]. 결과적으로 비동기 로딩, 성공, 에러 등의 API 응답 상태와 복잡한 UI 상태를 철저하게 제어하고 예측 가능하게 만들어 줍니다 [2, 5].
-
-## 📖 구조화된 지식 (Synthesized Content)
-- **식별 가능한 유니온(Discriminated Unions) 도입:** React 상태 관리에 대한 사고방식을 변화시키는 가장 강력한 TypeScript 패턴 중 하나입니다 [1]. 식별 가능한 유니온(또는 태그된 유니온)을 사용하면 여러 데이터 형태 중 어떤 형태를 다루고 있는지 구별할 수 있는 공통 속성(판별자)을 통해 데이터를 안전하게 모델링할 수 있습니다 [1, 6].
-- **API 응답 및 비동기 작업 처리:** API 응답을 모델링하는 데 있어 식별 가능한 유니온은 탁월한 성능을 발휘합니다 [2]. 데이터를 불러오는(data fetching) React 컴포넌트를 설계할 때, 상태 머신 패턴을 결합하여 `FETCH_START`, `FETCH_SUCCESS`, `FETCH_FAILURE` 등과 같은 상태 전환을 명확하게 구분하고 관리할 수 있습니다 [2, 4].
-- **유효하지 않은 상태 원천 차단 (Making Invalid States Impossible):** 이 패턴의 가장 큰 힘은 잘못된 상태 자체를 코드상에 표현할 수 없도록 만든다는 점입니다 [4]. 판별자를 통해 TypeScript가 자동으로 타입을 좁혀주기 때문에, 로딩 상태이면서 동시에 성공 데이터가 존재하거나 에러와 데이터가 공존하는 등의 모순된 조합을 방지해 수많은 버그를 예방합니다 [3, 4, 7].
-- **리듀서 및 폼(Form) 상태 관리:** 식별 가능한 유니온은 Redux 스타일의 액션과 리듀서 구조에서 특히 빛을 발합니다 [5]. 또한, 유효성 검사(validating), 유효성 에러(validation-error), 제출 중(submitting), 성공(success), 에러(error) 등의 태그된 상태 구분이 필수적인 복잡한 폼 워크플로우를 처리할 때 매우 유용합니다 [4, 5].
-- **철저한 검사 (Exhaustiveness Checking):** switch 문 등과 결합하여 API 응답이나 상태를 처리할 때, TypeScript는 가능한 모든 케이스가 처리되었는지 컴파일 타임에 철저하게 보장합니다 [3, 7, 8]. 만약 새로운 상태 변형(variant)을 추가하고 핸들러를 업데이트하지 않으면 컴파일 에러를 발생시켜 실수를 방지합니다 [8].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Design & Experience 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[Discriminated Unions]], [[State Machine Pattern]], [[TypeScript]]
-- **Projects/Contexts:** [[비동기 작업 패턴(Async Operations Pattern)]], [[Redux 스타일 리듀서(Redux-style reducers)]]
-- **Contradictions/Notes:** 소스에 관련 정보가 부족합니다. (React 상태 관리 및 API 응답 처리와 관련하여 소스 간의 상충되는 주장이 포함되어 있지 않습니다.)
-
----
-*Last updated: 2026-04-18*
-- Raw Source: [[00_Raw/2026-04-20/React 상태 관리 및 API 응답 처리.md]]
----
diff --git a/Design & Experience/React 컴포넌트 Props 검증.md b/Design & Experience/React 컴포넌트 Props 검증.md
deleted file mode 100644
index b5973ce4..00000000
--- a/Design & Experience/React 컴포넌트 Props 검증.md	
+++ /dev/null
@@ -1,35 +0,0 @@
----
-id: P-REINFORCE-AUTO-F45907
-category: "[[10_Wiki/💡 Topics/Design & Experience]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - React 컴포넌트 Props 검증"
----
-
-# [[React 컴포넌트 Props 검증]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> React 컴포넌트 Props 검증은 TypeScript를 활용하여 컴포넌트에 전달되는 속성(Props)의 타입 안전성을 보장하고, 유효하지 않은 상태 표현을 원천적으로 차단하는 과정입니다 [1, 2]. 컴파일 타임에는 식별 가능한 유니온(Discriminated Unions)과 초과 속성 검사 등의 기법으로 잘못된 Props 조합을 방지하며, 런타임에는 외부 데이터에 대한 추가적인 유효성 검사를 수행하여 안정성을 확보합니다 [3-5].
-
-## 📖 구조화된 지식 (Synthesized Content)
-- **기본 타입 지정 (Type vs Interface)**: React 컴포넌트의 기본적인 Props를 정의할 때 `type`이나 `interface` 중 어느 것을 사용할지는 성능에 큰 차이가 없으며 상황과 선호에 따라 무방하게 사용될 수 있습니다 [6].
-- **식별 가능한 유니온(Discriminated Unions)의 활용**: 텍스트 필드나 셀렉트 필드 등 서로 다른 형태의 입력을 처리하는 유연한 컴포넌트를 설계할 때 핵심적인 역할을 합니다 [3]. 이를 통해 특정 컴포넌트 변형(variant)에 호환되지 않는 Props(예: Select 필드에 placeholder 옵션 지정)를 혼용하는 것을 TypeScript가 엄격하게 방지합니다 [3].
-- **배타적 속성 (Exclusive Props) 패턴**: 명시적인 판별자(discriminant prop) 없이 두 Props 묶음 간의 상호 배타성을 보장하고 싶을 때 사용됩니다 [3]. 유니온 타입과 `never` 타입을 활용해 한쪽 타입이 활성화될 때 다른 쪽의 속성 사용을 차단하여 혼합 사용을 막을 수 있습니다 [3].
-- **초과 속성 검사 (Excess Property Checking)**: 정의되지 않은 초과 속성이 컴포넌트에 간접적으로 전달되면 유효하지 않은 속성이 DOM으로 넘어가 React 경고를 발생시키거나, 의도치 않은 리렌더링 및 잘못된 코드가 복제되는 등의 부작용을 유발할 수 있습니다 [5]. 이를 막기 위해 제네릭과 `never` 타입을 조합하여 실제 입력값과 예상되는 Props 간의 초과 속성을 감지해내는 방식을 React 컴포넌트에도 적용할 수 있습니다 [7-9].
-- **`satisfies` 연산자 도입**: 컴포넌트의 Props가 특정 구조를 만족하도록 제약하는 동시에, TypeScript가 해당 Props의 가장 구체적인 타입(literal type)을 추론하게 만들 때 `satisfies` 연산자를 활용하여 유연함과 안전성을 모두 챙길 수 있습니다 [10].
-- **Zod를 이용한 런타임 유효성 검사 (Runtime Validation)**: API 응답이나 외부 설정 파일 등 외부 소스로부터 전달받는 Props의 경우 TypeScript의 정적 검사만으로는 검증할 수 없습니다 [4]. 데이터 무결성이 중요할 경우 식별 가능한 유니온과 Zod와 같은 런타임 유효성 검사 도구를 결합하여 런타임 수준의 안전성을 확보해야 합니다 [4, 11].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Design & Experience 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[Discriminated Unions]], [[Exclusive Props]], [[Excess Property Checking]], [[Zod 런타임 검증]], [[satisfies 연산자]]
-- **Projects/Contexts:** [[React 상태 및 Props 관리]], [[외부 API 데이터 연동 컴포넌트]]
-- **Contradictions/Notes:** TypeScript의 컴파일 타임 검사는 무결성을 보장하지만, 런타임에 외부(API, 설정 파일 등)에서 주입되는 잘못된 Props 데이터까지는 막아주지 못하므로 외부 데이터 연동 컴포넌트에서는 런타임 검증이 동반되어야 합니다 [4].
-
----
-*Last updated: 2026-04-18*
-- Raw Source: [[00_Raw/2026-04-20/React 컴포넌트 Props 검증.md]]
----
diff --git a/Design & Experience/Redstone Engineering.md b/Design & Experience/Redstone Engineering.md
deleted file mode 100644
index 3bb66b17..00000000
--- a/Design & Experience/Redstone Engineering.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-F36E08
-category: "[[10_Wiki/💡 Topics/Design & Experience]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Redstone Engineering"
----
-
-# [[Redstone Engineering]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Design & Experience 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Redstone Engineering.md]]
----
diff --git a/Design & Experience/Redux 등 상태 관리 (State Management).md b/Design & Experience/Redux 등 상태 관리 (State Management).md
deleted file mode 100644
index cbc1adb4..00000000
--- a/Design & Experience/Redux 등 상태 관리 (State Management).md	
+++ /dev/null
@@ -1,32 +0,0 @@
----
-id: P-REINFORCE-AUTO-8514DD
-category: "[[10_Wiki/💡 Topics/Design & Experience]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Redux 등 상태 관리 (State Management)"
----
-
-# [[Redux 등 상태 관리 (State Management)]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 상태 관리는 사용자 입력, API 응답, 애플리케이션 설정 등 시간에 따라 변화하는 데이터를 추적하고 유지하는 방법론입니다 [1]. 상태 관리를 잘못하면 예측 불가능한 동작, 디버깅의 어려움, 기술 부채 축적 및 성능 문제(불필요한 리렌더링 등)가 발생할 수 있습니다 [2]. TypeScript 환경에서는 Redux 스타일의 리듀서와 액션을 안전하게 제어하기 위해 식별 가능한 유니온(Discriminated Unions)과 읽기 전용(Readonly) 타입을 활용한 불변성 유지가 상태 관리의 핵심 패턴으로 사용됩니다 [3-6].
-
-## 📖 구조화된 지식 (Synthesized Content)
-- **상태 관리의 정의와 실패 시 문제점:** 상태 관리는 애플리케이션 내의 다양한 데이터 흐름을 다루는 필수적인 과정입니다 [1]. 상태 관리에 실패하면 명확한 패턴 없이 여러 곳에서 상태가 수정되어 동작을 예측할 수 없게 되며, 중복되거나 오래된 상태로 인한 기술 부채, 불필요한 리렌더링 및 메모리 누수와 같은 성능 문제를 야기합니다 [2].
-- **Redux와 식별 가능한 유니온(Discriminated Unions) 패턴:** TypeScript를 활용한 상태 관리, 특히 Redux 스타일의 리듀서와 액션에서는 식별 가능한 유니온 패턴이 빛을 발합니다 [3, 6]. 이 패턴은 상태와 에러 처리에 있어서 "불가능한 상태를 표현 불가능하게 만드는" 마법과 같은 효과를 제공합니다 [7]. 이를 통해 컴파일러의 철저한 타입 검사를 지원받아 유효하지 않은 상태의 조합을 원천적으로 차단할 수 있습니다 [3, 8, 9].
-- **상태의 불변성(Immutability) 보장:** 상태 관리 패턴과 리듀서에서 데이터의 무결성을 유지하기 위해서는 불변성을 강제해야 합니다 [5, 10]. `Readonly` 타입이나 재귀적으로 중첩된 구조까지 보호하는 `DeepReadonly` 유틸리티 타입을 활용하면, 상태 객체가 생성된 이후 어떠한 부분도 임의로 수정될 수 없도록 보장하여 우발적인 상태 변이(Mutation)로 인한 버그를 방지할 수 있습니다 [4, 5].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Design & Experience 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[식별 가능한 유니온 (Discriminated Unions)]], [[불변성 (Immutability)]], [[Readonly 타입]]
-- **Projects/Contexts:** [[TypeScript 기반 React 애플리케이션의 Redux 스타일 리듀서 구현]]
-- **Contradictions/Notes:** 소스에서는 Redux 라이브러리 자체의 세부적인 API나 동작 원리보다는, TypeScript의 강력한 타입 시스템(식별 가능한 유니온, Readonly)을 결합하여 상태 관리의 복잡성과 부작용을 통제하는 아키텍처적 관점이 주로 강조되어 있습니다 [1, 3, 4, 7].
-
----
-*Last updated: 2026-04-18*
-- Raw Source: [[00_Raw/2026-04-20/Redux 등 상태 관리 (State Management).md]]
----
diff --git a/Design & Experience/Redux 스타일 리듀서 및 액션 관리.md b/Design & Experience/Redux 스타일 리듀서 및 액션 관리.md
deleted file mode 100644
index f0daa6cc..00000000
--- a/Design & Experience/Redux 스타일 리듀서 및 액션 관리.md	
+++ /dev/null
@@ -1,32 +0,0 @@
----
-id: P-REINFORCE-AUTO-EFAFFE
-category: "[[10_Wiki/💡 Topics/Design & Experience]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Redux 스타일 리듀서 및 액션 관리"
----
-
-# [[Redux 스타일 리듀서 및 액션 관리]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> Redux 스타일 리듀서 및 액션 관리는 TypeScript의 식별 가능한 유니언(Discriminated Unions) 패턴이 가장 효과적으로 적용되는 대표적인 사례 중 하나입니다 [1, 2]. 이 패턴을 통해 다양한 액션 객체들을 타입 안전하게 구분하고 상태를 처리할 수 있습니다. 다만, 제공된 소스에서는 이 주제가 식별 가능한 유니언의 단순 활용 예시로만 간략히 언급되어 있어 전반적인 Redux 아키텍처에 대해 논하기에는 소스에 관련 정보가 부족합니다.
-
-## 📖 구조화된 지식 (Synthesized Content)
-- **식별 가능한 유니언(Discriminated Unions)의 적용:** TypeScript의 식별 가능한 유니언(또는 태그된 유니언) 패턴은 Redux 스타일의 리듀서를 작성할 때 탁월한 성능과 타입 안전성을 제공합니다 [1]. 이 패턴은 공통된 리터럴 타입의 속성(discriminator)을 사용하여 여러 액션 데이터의 형태 중 현재 어떤 액션이 발생했는지 컴파일러가 정확히 추론할 수 있게 해줍니다 [3, 4].
-- **프레임워크 전반의 표준 패턴:** 식별 가능한 유니언을 활용한 방식은 단지 특정 라이브러리에 국한되지 않으며, Redux 액션을 비롯하여 API 응답 상태, 컴포넌트 변형(variants) 등 프레임워크 전반에서 데이터를 모델링할 때 널리 사용되는 강력한 패턴입니다 [2].
-- **정보 부족 명시:** Redux 스타일 리듀서의 구체적인 로직 구성, 미들웨어 처리, 혹은 액션 관리의 심층적인 구조적 설계 등 상세한 내용은 제공된 문서에 포함되어 있지 않으므로 소스에 관련 정보가 부족합니다.
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Design & Experience 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[Discriminated Unions]], [[Type Narrowing]]
-- **Projects/Contexts:** [[상태 관리 및 프레임워크의 액션 처리]]
-- **Contradictions/Notes:** 소스에 관련 정보가 부족합니다. 소스는 Redux 자체에 대한 깊은 설명보다는 TypeScript의 타입 시스템을 설명하면서 그 예시로만 Redux를 간략하게 다루고 있습니다.
-
----
-*Last updated: 2026-04-18*
-- Raw Source: [[00_Raw/2026-04-20/Redux 스타일 리듀서 및 액션 관리.md]]
----
diff --git a/Design & Experience/Redux-Reducers.md b/Design & Experience/Redux-Reducers.md
deleted file mode 100644
index 77a66dfa..00000000
--- a/Design & Experience/Redux-Reducers.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-20A7B7
-category: "[[10_Wiki/💡 Topics/Design & Experience]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Redux-Reducers"
----
-
-# [[Redux-Reducers]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Design & Experience 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Redux-Reducers.md]]
----
diff --git a/Design & Experience/Redux-Toolkit-Architecture.md b/Design & Experience/Redux-Toolkit-Architecture.md
deleted file mode 100644
index 138d8750..00000000
--- a/Design & Experience/Redux-Toolkit-Architecture.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-5308B9
-category: "[[10_Wiki/💡 Topics/Design & Experience]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Redux-Toolkit-Architecture"
----
-
-# [[Redux-Toolkit-Architecture]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Design & Experience 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Redux-Toolkit-Architecture.md]]
----
diff --git a/Design & Experience/Reinforcement Learning Reward Shaping.md b/Design & Experience/Reinforcement Learning Reward Shaping.md
deleted file mode 100644
index 8d8c5ee1..00000000
--- a/Design & Experience/Reinforcement Learning Reward Shaping.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-390731
-category: "[[10_Wiki/💡 Topics/Design & Experience]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Reinforcement Learning Reward Shaping"
----
-
-# [[Reinforcement Learning Reward Shaping]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Design & Experience 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Reinforcement Learning Reward Shaping.md]]
----
diff --git a/Design & Experience/Roguelike Subgenre.md b/Design & Experience/Roguelike Subgenre.md
deleted file mode 100644
index 89befafc..00000000
--- a/Design & Experience/Roguelike Subgenre.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-3475FE
-category: "[[10_Wiki/💡 Topics/Design & Experience]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Roguelike Subgenre"
----
-
-# [[Roguelike Subgenre]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Design & Experience 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Roguelike Subgenre.md]]
----
diff --git a/Design & Experience/SeL4-Microkernel.md b/Design & Experience/SeL4-Microkernel.md
deleted file mode 100644
index c824e6f2..00000000
--- a/Design & Experience/SeL4-Microkernel.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-0A0995
-category: "[[10_Wiki/💡 Topics/Design & Experience]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - SeL4-Microkernel"
----
-
-# [[SeL4-Microkernel]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Design & Experience 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/SeL4-Microkernel.md]]
----
diff --git a/Design & Experience/Self-Determination Theory.md b/Design & Experience/Self-Determination Theory.md
deleted file mode 100644
index 4b9aabf0..00000000
--- a/Design & Experience/Self-Determination Theory.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-2C7B68
-category: "[[10_Wiki/💡 Topics/Design & Experience]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Self-Determination Theory"
----
-
-# [[Self-Determination Theory]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Design & Experience 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Self-Determination Theory.md]]
----
diff --git a/Design & Experience/Self-Determination-Theory.md b/Design & Experience/Self-Determination-Theory.md
deleted file mode 100644
index 798ca219..00000000
--- a/Design & Experience/Self-Determination-Theory.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-576385
-category: "[[10_Wiki/💡 Topics/Design & Experience]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Self-Determination-Theory"
----
-
-# [[Self-Determination-Theory]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Design & Experience 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Self-Determination-Theory.md]]
----
diff --git a/Design & Experience/Service-Design.md b/Design & Experience/Service-Design.md
deleted file mode 100644
index 31a90400..00000000
--- a/Design & Experience/Service-Design.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-92A8B5
-category: "[[10_Wiki/💡 Topics/Design & Experience]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Service-Design"
----
-
-# [[Service-Design]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Design & Experience 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Service-Design.md]]
----
diff --git a/Design & Experience/SimCity-Series.md b/Design & Experience/SimCity-Series.md
deleted file mode 100644
index 207aa0f4..00000000
--- a/Design & Experience/SimCity-Series.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-5D71A8
-category: "[[10_Wiki/💡 Topics/Design & Experience]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - SimCity-Series"
----
-
-# [[SimCity-Series]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Design & Experience 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/SimCity-Series.md]]
----
diff --git a/Design & Experience/Single-Responsibility-Principle.md b/Design & Experience/Single-Responsibility-Principle.md
deleted file mode 100644
index 0b5f1677..00000000
--- a/Design & Experience/Single-Responsibility-Principle.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-91F776
-category: "[[10_Wiki/💡 Topics/Design & Experience]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Single-Responsibility-Principle"
----
-
-# [[Single-Responsibility-Principle]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Design & Experience 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Single-Responsibility-Principle.md]]
----
diff --git a/Design & Experience/Single-Source-of-Truth-Principle.md b/Design & Experience/Single-Source-of-Truth-Principle.md
deleted file mode 100644
index ee988ef3..00000000
--- a/Design & Experience/Single-Source-of-Truth-Principle.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-A292A4
-category: "[[10_Wiki/💡 Topics/Design & Experience]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Single-Source-of-Truth-Principle"
----
-
-# [[Single-Source-of-Truth-Principle]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Design & Experience 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Single-Source-of-Truth-Principle.md]]
----
diff --git a/Design & Experience/Smithsonian-Digital-Repository.md b/Design & Experience/Smithsonian-Digital-Repository.md
deleted file mode 100644
index eef31f89..00000000
--- a/Design & Experience/Smithsonian-Digital-Repository.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-F0CD87
-category: "[[10_Wiki/💡 Topics/Design & Experience]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Smithsonian-Digital-Repository"
----
-
-# [[Smithsonian-Digital-Repository]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Design & Experience 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Smithsonian-Digital-Repository.md]]
----
diff --git a/Design & Experience/Snyk Open Source.md b/Design & Experience/Snyk Open Source.md
deleted file mode 100644
index c55d60c8..00000000
--- a/Design & Experience/Snyk Open Source.md	
+++ /dev/null
@@ -1,32 +0,0 @@
----
-id: P-REINFORCE-AUTO-F26CB3
-category: "[[10_Wiki/💡 Topics/Design & Experience]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Snyk Open Source"
----
-
-# [[Snyk Open Source]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> Snyk Open Source는 애플리케이션을 구성하는 서드파티 종속성(third-party dependencies)을 스캔하여 알려진 보안 취약점을 탐지하는 소프트웨어 구성 분석(SCA, Software Composition Analysis) 도구입니다 [1, 2]. 이 도구는 `package.json`, `pom.xml`, `requirements.txt`와 같은 매니페스트 파일을 검사하고 Snyk의 엄선된 취약점 데이터베이스와 대조하여 위험 요소를 식별합니다 [3]. 또한, 취약한 패키지를 안전한 버전으로 업그레이드할 수 있도록 풀 리퀘스트(Pull Request)를 자동으로 생성하는 기능을 제공하여 신속한 보안 패치를 돕습니다 [3].
-
-## 📖 구조화된 지식 (Synthesized Content)
-- **오픈소스 종속성 관리의 중요성:** 오늘날 애플리케이션의 80~90%는 오픈소스 종속성으로 구성되어 있습니다 [4]. 따라서 이 도구를 활용해 npm, Maven, PyPI 등 패키지 매니저의 알려진 CVE(Common Vulnerabilities and Exposures)를 감지하고 지속적으로 업데이트하는 것은 소프트웨어 공급망 보안의 필수 권장 사항입니다 [1, 4].
-- **Snyk Code(SAST)와의 차이점:** 두 도구는 종종 혼동되지만 스캔하는 대상과 방어하는 위협 벡터가 완전히 다릅니다 [3, 5]. Snyk Code가 개발팀이 직접 작성한 퍼스트파티(first-party) 코드의 취약점을 탐지하는 SAST 도구라면, Snyk Open Source는 외부에서 가져온(import) 서드파티(third-party) 라이브러리의 취약점을 찾아내는 SCA 도구입니다 [1, 2].
-- **플랫폼 통합 및 시너지:** Snyk Open Source는 Snyk Code, Snyk Container, Snyk IaC, Snyk Cloud와 함께 Snyk 보안 플랫폼을 구성하는 5대 제품 중 하나입니다 [6]. 전체 공격 표면(Attack Surface)을 커버하기 위해서는 내부 코드 스캔과 외부 종속성 스캔이 모두 필요하므로 보안 성숙도가 높은 팀은 이 도구들을 함께 실행합니다 [2, 5]. 이를 통해 단일 대시보드와 통합 리포팅 환경에서 보안 검사를 효율적으로 관리할 수 있습니다 [7].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Design & Experience 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[SCA (Software Composition Analysis)]], [[Snyk Code]], [[서드파티 종속성 (Third-party dependencies)]], [[CVE (Common Vulnerabilities and Exposures)]]
-- **Projects/Contexts:** [[Snyk Security Platform]]
-- **Contradictions/Notes:** 소스의 내용 간에 특별한 모순은 발견되지 않았습니다. 소스는 Snyk Open Source(SCA)와 Snyk Code(SAST)가 경쟁 관계가 아니라 완전히 다른 영역을 검사하며, 강력한 보안 태세를 위해 상호 보완적으로 사용되어야 한다는 점을 거듭 강조합니다 [2, 3, 5].
-
----
-*Last updated: 2026-04-19*
-- Raw Source: [[00_Raw/2026-04-20/Snyk Open Source.md]]
----
diff --git a/Design & Experience/Social Learning Theory.md b/Design & Experience/Social Learning Theory.md
deleted file mode 100644
index f8266839..00000000
--- a/Design & Experience/Social Learning Theory.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-26C0EB
-category: "[[10_Wiki/💡 Topics/Design & Experience]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Social Learning Theory"
----
-
-# [[Social Learning Theory]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Design & Experience 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Social Learning Theory.md]]
----
diff --git a/Design & Experience/Socially Assistive Robotics (SAR).md b/Design & Experience/Socially Assistive Robotics (SAR).md
deleted file mode 100644
index 3d5c1bf1..00000000
--- a/Design & Experience/Socially Assistive Robotics (SAR).md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-22DA21
-category: "[[10_Wiki/💡 Topics/Design & Experience]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Socially Assistive Robotics (SAR)"
----
-
-# [[Socially Assistive Robotics (SAR)]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Design & Experience 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Socially Assistive Robotics (SAR).md]]
----
diff --git a/Design & Experience/Software Architecture  API Contract Design.md b/Design & Experience/Software Architecture  API Contract Design.md
deleted file mode 100644
index 6b92d06f..00000000
--- a/Design & Experience/Software Architecture  API Contract Design.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-A7EF2F
-category: "[[10_Wiki/💡 Topics/Design & Experience]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Software Architecture  API Contract Design"
----
-
-# [[Software Architecture  API Contract Design]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Design & Experience 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Software Architecture & API Contract Design.md]]
----
diff --git a/Design & Experience/Software-Contract-Enforcement.md b/Design & Experience/Software-Contract-Enforcement.md
deleted file mode 100644
index ec2a7f99..00000000
--- a/Design & Experience/Software-Contract-Enforcement.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-B29206
-category: "[[10_Wiki/💡 Topics/Design & Experience]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Software-Contract-Enforcement"
----
-
-# [[Software-Contract-Enforcement]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Design & Experience 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Software-Contract-Enforcement.md]]
----
diff --git a/Design & Experience/Software-Product-Management.md b/Design & Experience/Software-Product-Management.md
deleted file mode 100644
index 00183a34..00000000
--- a/Design & Experience/Software-Product-Management.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-7094F5
-category: "[[10_Wiki/💡 Topics/Design & Experience]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Software-Product-Management"
----
-
-# [[Software-Product-Management]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Design & Experience 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Software-Product-Management.md]]
----
diff --git a/Design & Experience/Spatial Cognition.md b/Design & Experience/Spatial Cognition.md
deleted file mode 100644
index 284b54a3..00000000
--- a/Design & Experience/Spatial Cognition.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-06C479
-category: "[[10_Wiki/💡 Topics/Design & Experience]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Spatial Cognition"
----
-
-# [[Spatial Cognition]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Design & Experience 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Spatial Cognition.md]]
----
diff --git a/Design & Experience/Spatial Computing.md b/Design & Experience/Spatial Computing.md
deleted file mode 100644
index a69b4fba..00000000
--- a/Design & Experience/Spatial Computing.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-C2600F
-category: "[[10_Wiki/💡 Topics/Design & Experience]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Spatial Computing"
----
-
-# [[Spatial Computing]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Design & Experience 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Spatial Computing.md]]
----
diff --git a/Design & Experience/State-Machine-Implementation.md b/Design & Experience/State-Machine-Implementation.md
deleted file mode 100644
index 224da0ad..00000000
--- a/Design & Experience/State-Machine-Implementation.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-CB6F5B
-category: "[[10_Wiki/💡 Topics/Design & Experience]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - State-Machine-Implementation"
----
-
-# [[State-Machine-Implementation]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Design & Experience 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/State-Machine-Implementation.md]]
----
diff --git a/Design & Experience/Static Type Checking Systems.md b/Design & Experience/Static Type Checking Systems.md
deleted file mode 100644
index b69a0ea6..00000000
--- a/Design & Experience/Static Type Checking Systems.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-AB0264
-category: "[[10_Wiki/💡 Topics/Design & Experience]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Static Type Checking Systems"
----
-
-# [[Static Type Checking Systems]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Design & Experience 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Static Type Checking Systems.md]]
----
diff --git a/Design & Experience/Static-Program-Analysis.md b/Design & Experience/Static-Program-Analysis.md
deleted file mode 100644
index 17f1e86e..00000000
--- a/Design & Experience/Static-Program-Analysis.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-295D6F
-category: "[[10_Wiki/💡 Topics/Design & Experience]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Static-Program-Analysis"
----
-
-# [[Static-Program-Analysis]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Design & Experience 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Static-Program-Analysis.md]]
----
diff --git a/Design & Experience/Structural Type System.md b/Design & Experience/Structural Type System.md
deleted file mode 100644
index 635221a0..00000000
--- a/Design & Experience/Structural Type System.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-8CDABA
-category: "[[10_Wiki/💡 Topics/Design & Experience]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Structural Type System"
----
-
-# [[Structural Type System]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Design & Experience 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Structural Type System.md]]
----
diff --git a/Design & Experience/Structural-Subtyping.md b/Design & Experience/Structural-Subtyping.md
deleted file mode 100644
index bfd8b65c..00000000
--- a/Design & Experience/Structural-Subtyping.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-ED919D
-category: "[[10_Wiki/💡 Topics/Design & Experience]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Structural-Subtyping"
----
-
-# [[Structural-Subtyping]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Design & Experience 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Structural-Subtyping.md]]
----
diff --git a/Design & Experience/Structural-Type-System.md b/Design & Experience/Structural-Type-System.md
deleted file mode 100644
index 2bb3304f..00000000
--- a/Design & Experience/Structural-Type-System.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-51BF6C
-category: "[[10_Wiki/💡 Topics/Design & Experience]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Structural-Type-System"
----
-
-# [[Structural-Type-System]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Design & Experience 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Structural-Type-System.md]]
----
diff --git a/Design & Experience/Structural-Typing-Analysis.md b/Design & Experience/Structural-Typing-Analysis.md
deleted file mode 100644
index 9b1c80cd..00000000
--- a/Design & Experience/Structural-Typing-Analysis.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-7B4F4E
-category: "[[10_Wiki/💡 Topics/Design & Experience]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Structural-Typing-Analysis"
----
-
-# [[Structural-Typing-Analysis]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Design & Experience 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Structural-Typing-Analysis.md]]
----
diff --git a/Design & Experience/Structural-Typing-Compatibility.md b/Design & Experience/Structural-Typing-Compatibility.md
deleted file mode 100644
index 484f5a11..00000000
--- a/Design & Experience/Structural-Typing-Compatibility.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-61CE6C
-category: "[[10_Wiki/💡 Topics/Design & Experience]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Structural-Typing-Compatibility"
----
-
-# [[Structural-Typing-Compatibility]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Design & Experience 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Structural-Typing-Compatibility.md]]
----
diff --git a/Design & Experience/Structural-Typing-Mechanics.md b/Design & Experience/Structural-Typing-Mechanics.md
deleted file mode 100644
index 7942f8ae..00000000
--- a/Design & Experience/Structural-Typing-Mechanics.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-472330
-category: "[[10_Wiki/💡 Topics/Design & Experience]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Structural-Typing-Mechanics"
----
-
-# [[Structural-Typing-Mechanics]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Design & Experience 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Structural-Typing-Mechanics.md]]
----
diff --git a/Design & Experience/Structural-Typing-Mechanisms.md b/Design & Experience/Structural-Typing-Mechanisms.md
deleted file mode 100644
index e6b0eddb..00000000
--- a/Design & Experience/Structural-Typing-Mechanisms.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-88EAEF
-category: "[[10_Wiki/💡 Topics/Design & Experience]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Structural-Typing-Mechanisms"
----
-
-# [[Structural-Typing-Mechanisms]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Design & Experience 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Structural-Typing-Mechanisms.md]]
----
diff --git a/Design & Experience/Structural-Typing-System.md b/Design & Experience/Structural-Typing-System.md
deleted file mode 100644
index 5c6454ec..00000000
--- a/Design & Experience/Structural-Typing-System.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-CB5A39
-category: "[[10_Wiki/💡 Topics/Design & Experience]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Structural-Typing-System"
----
-
-# [[Structural-Typing-System]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Design & Experience 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Structural-Typing-System.md]]
----
diff --git a/Design & Experience/Structural-Typing-and-Compatibility.md b/Design & Experience/Structural-Typing-and-Compatibility.md
deleted file mode 100644
index 76ee5c69..00000000
--- a/Design & Experience/Structural-Typing-and-Compatibility.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-8A9CF7
-category: "[[10_Wiki/💡 Topics/Design & Experience]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Structural-Typing-and-Compatibility"
----
-
-# [[Structural-Typing-and-Compatibility]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Design & Experience 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Structural-Typing-and-Compatibility.md]]
----
diff --git a/Design & Experience/Structural-Typing-vs-Nominal-Typing.md b/Design & Experience/Structural-Typing-vs-Nominal-Typing.md
deleted file mode 100644
index e972cea5..00000000
--- a/Design & Experience/Structural-Typing-vs-Nominal-Typing.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-AA252C
-category: "[[10_Wiki/💡 Topics/Design & Experience]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Structural-Typing-vs-Nominal-Typing"
----
-
-# [[Structural-Typing-vs-Nominal-Typing]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Design & Experience 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Structural-Typing-vs-Nominal-Typing.md]]
----
diff --git a/Design & Experience/Structural-Typing.md b/Design & Experience/Structural-Typing.md
deleted file mode 100644
index 4d9e9cf6..00000000
--- a/Design & Experience/Structural-Typing.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-65A250
-category: "[[10_Wiki/💡 Topics/Design & Experience]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Structural-Typing"
----
-
-# [[Structural-Typing]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Design & Experience 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Structural-Typing.md]]
----
diff --git a/Design & Experience/Structural-vs-Nominal-Typing-in-TS.md b/Design & Experience/Structural-vs-Nominal-Typing-in-TS.md
deleted file mode 100644
index 77f71efc..00000000
--- a/Design & Experience/Structural-vs-Nominal-Typing-in-TS.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-1623C6
-category: "[[10_Wiki/💡 Topics/Design & Experience]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Structural-vs-Nominal-Typing-in-TS"
----
-
-# [[Structural-vs-Nominal-Typing-in-TS]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Design & Experience 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Structural-vs-Nominal-Typing-in-TS.md]]
----
diff --git a/Design & Experience/Structural-vs-Nominal-Typing.md b/Design & Experience/Structural-vs-Nominal-Typing.md
deleted file mode 100644
index e551e47b..00000000
--- a/Design & Experience/Structural-vs-Nominal-Typing.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-AD6E98
-category: "[[10_Wiki/💡 Topics/Design & Experience]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Structural-vs-Nominal-Typing"
----
-
-# [[Structural-vs-Nominal-Typing]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Design & Experience 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Structural-vs-Nominal-Typing.md]]
----
diff --git a/Design & Experience/Subtyping-Relations.md b/Design & Experience/Subtyping-Relations.md
deleted file mode 100644
index 39e58f79..00000000
--- a/Design & Experience/Subtyping-Relations.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-4C9B28
-category: "[[10_Wiki/💡 Topics/Design & Experience]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Subtyping-Relations"
----
-
-# [[Subtyping-Relations]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Design & Experience 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Subtyping-Relations.md]]
----
diff --git a/Design & Experience/Subtyping-Rules.md b/Design & Experience/Subtyping-Rules.md
deleted file mode 100644
index 358c3596..00000000
--- a/Design & Experience/Subtyping-Rules.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-FFBE65
-category: "[[10_Wiki/💡 Topics/Design & Experience]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Subtyping-Rules"
----
-
-# [[Subtyping-Rules]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Design & Experience 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Subtyping-Rules.md]]
----
diff --git a/Design & Experience/Subtyping-and-Variance.md b/Design & Experience/Subtyping-and-Variance.md
deleted file mode 100644
index 7407aa19..00000000
--- a/Design & Experience/Subtyping-and-Variance.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-B1CA51
-category: "[[10_Wiki/💡 Topics/Design & Experience]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Subtyping-and-Variance"
----
-
-# [[Subtyping-and-Variance]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Design & Experience 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Subtyping-and-Variance.md]]
----
diff --git a/Design & Experience/Systemic Design.md b/Design & Experience/Systemic Design.md
deleted file mode 100644
index 3f861d93..00000000
--- a/Design & Experience/Systemic Design.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-0B8492
-category: "[[10_Wiki/💡 Topics/Design & Experience]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Systemic Design"
----
-
-# [[Systemic Design]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Design & Experience 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Systemic Design.md]]
----
diff --git a/Design & Experience/Systemic Game Design.md b/Design & Experience/Systemic Game Design.md
deleted file mode 100644
index d8c474d1..00000000
--- a/Design & Experience/Systemic Game Design.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-364762
-category: "[[10_Wiki/💡 Topics/Design & Experience]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Systemic Game Design"
----
-
-# [[Systemic Game Design]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Design & Experience 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Systemic Game Design.md]]
----
diff --git a/Design & Experience/Systemic-Design.md b/Design & Experience/Systemic-Design.md
deleted file mode 100644
index bbf33a6d..00000000
--- a/Design & Experience/Systemic-Design.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-9123E5
-category: "[[10_Wiki/💡 Topics/Design & Experience]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Systemic-Design"
----
-
-# [[Systemic-Design]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Design & Experience 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Systemic-Design.md]]
----
diff --git a/Design & Experience/Systems-Thinking.md b/Design & Experience/Systems-Thinking.md
deleted file mode 100644
index 2b756aa7..00000000
--- a/Design & Experience/Systems-Thinking.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-2028E0
-category: "[[10_Wiki/💡 Topics/Design & Experience]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Systems-Thinking"
----
-
-# [[Systems-Thinking]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Design & Experience 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Systems-Thinking.md]]
----
diff --git a/Design & Experience/Template-Literal-Types.md b/Design & Experience/Template-Literal-Types.md
deleted file mode 100644
index 9aac9d74..00000000
--- a/Design & Experience/Template-Literal-Types.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-CBED64
-category: "[[10_Wiki/💡 Topics/Design & Experience]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Template-Literal-Types"
----
-
-# [[Template-Literal-Types]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Design & Experience 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Template-Literal-Types.md]]
----
diff --git a/Design & Experience/The Emergence Theory in Game Design.md b/Design & Experience/The Emergence Theory in Game Design.md
deleted file mode 100644
index c01715b0..00000000
--- a/Design & Experience/The Emergence Theory in Game Design.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-A4804A
-category: "[[10_Wiki/💡 Topics/Design & Experience]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - The Emergence Theory in Game Design"
----
-
-# [[The Emergence Theory in Game Design]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Design & Experience 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/The Emergence Theory in Game Design.md]]
----
diff --git a/Design & Experience/The Last of Us (Resource Scarcity and Character Bond).md b/Design & Experience/The Last of Us (Resource Scarcity and Character Bond).md
deleted file mode 100644
index df00de73..00000000
--- a/Design & Experience/The Last of Us (Resource Scarcity and Character Bond).md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-B7E710
-category: "[[10_Wiki/💡 Topics/Design & Experience]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - The Last of Us (Resource Scarcity and Character Bond)"
----
-
-# [[The Last of Us (Resource Scarcity and Character Bond)]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Design & Experience 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/The Last of Us (Resource Scarcity and Character Bond).md]]
----
diff --git a/Design & Experience/Topological-Sorting.md b/Design & Experience/Topological-Sorting.md
deleted file mode 100644
index 202354fd..00000000
--- a/Design & Experience/Topological-Sorting.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-2CF8FE
-category: "[[10_Wiki/💡 Topics/Design & Experience]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Topological-Sorting"
----
-
-# [[Topological-Sorting]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Design & Experience 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Topological-Sorting.md]]
----
diff --git a/Design & Experience/Touchpoint-Analysis.md b/Design & Experience/Touchpoint-Analysis.md
deleted file mode 100644
index 7b302892..00000000
--- a/Design & Experience/Touchpoint-Analysis.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-5E6FFB
-category: "[[10_Wiki/💡 Topics/Design & Experience]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Touchpoint-Analysis"
----
-
-# [[Touchpoint-Analysis]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Design & Experience 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Touchpoint-Analysis.md]]
----
diff --git a/Design & Experience/Tree Shaking (번들 크기 최적화).md b/Design & Experience/Tree Shaking (번들 크기 최적화).md
deleted file mode 100644
index 26cda4d5..00000000
--- a/Design & Experience/Tree Shaking (번들 크기 최적화).md	
+++ /dev/null
@@ -1,42 +0,0 @@
----
-id: P-REINFORCE-AUTO-5A7457
-category: "[[10_Wiki/💡 Topics/Design & Experience]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Tree Shaking (번들 크기 최적화)"
----
-
-# [[Tree Shaking (번들 크기 최적화)]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 최신 모듈 번들러(Webpack, Vite 등)를 사용하여 애플리케이션의 최종 프로덕션 번들에서 사용되지 않는 '죽은 코드(Dead Code)'를 제거함으로써, 전체 자바스크립트 파일 크기를 최적화하는 기법입니다.
-
-## 📖 구조화된 지식 (Synthesized Content)
-**1. Tree Shaking의 기본 원리** 최신 번들러는 프로덕션 빌드 시 사용되지 않는 코드를 번들에서 제외할 수 있지만, 이를 위해서는 개발자가 올바른 모듈 가져오기 패턴과 빌드 구성을 제공해야 합니다. 올바르게 적용될 경우 번들 크기를 20~40%가량 줄일 수 있으며 파괴적 변경(Breaking Change)의 위험이 적습니다.
-
-**2. Tree Shaking 적용을 위한 4가지 필수 조건**
-
-- **ES6 모듈 문법 사용:** CommonJS 방식의 `require` 대신 정적 분석이 가능한 `import` 및 `export` 문법을 사용해야 합니다.
-- **필요한 모듈만 명시적 가져오기:** 패키지 전체를 불러오는 기본 내보내기(Default Export)를 피하고, 기명 내보내기(Named Export)를 사용해야 합니다. (예: 거대한 `lodash` 라이브러리 전체를 불러오는 대신, `import debounce from 'lodash-es/debounce'`와 같이 필요한 개별 함수만 직접 가져와야 합니다).
-- **번들러 설정:** 번들러가 안전하게 코드를 제거할 수 있도록 `package.json` 파일 내에 `sideEffects` 필드를 설정해야 합니다.
-- **라이브러리의 Default Export 피하기:** 라이브러리를 만들거나 가져올 때 Tree Shaking 호환성을 위해 Named Export 구조를 유지하는 것이 좋습니다.
-
-**3. 부수 효과(Side Effects) 처리 주의사항** 공격적인 Tree Shaking은 전역 변수를 초기화하거나 CSS를 임포트하는 등 코드 실행 자체로 부수 효과(Side Effects)를 일으키는 라이브러리를 실수로 제거하여 앱을 망가뜨릴 수 있습니다. 이를 방지하기 위해 `package.json`에 `"sideEffects": ["*.css", "./src/polyfills.js"]`와 같이 예외가 되는 파일들을 명시해 주어야 합니다.
-
-**4. 번들 분석 및 모니터링 (Bundle Analysis)** 눈에 보이지 않는 번들 비대화를 막기 위해 `webpack-bundle-analyzer`와 같은 도구를 활용하여 어떤 코드가 번들 용량을 차지하는지 시각적인 트리맵(Treemap)으로 분석해야 합니다. 이를 CI 파이프라인에 통합하여 번들 크기가 10% 이상 증가할 경우 빌드를 실패하게 설정하면, 시간이 지남에 따라 번들이 비대해지는 성능 저하 현상을 구조적으로 방지할 수 있습니다.
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Design & Experience 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[Code Splitting & Lazy Loading]], [[React Performance Optimization]], [[Webpack 번들 분석기 (webpack-bundle-analyzer)]], [[First Contentful Paint (FCP) 개선]]
-- **Projects/Contexts:** [[대규모 React 프론트엔드 최적화]], [[모바일 웹 성능 향상 프로젝트]]
-- **Contradictions/Notes:** 모듈을 가져올 때 구조 분해 할당(예: `import { debounce } from 'lodash'`)을 하더라도 해당 라이브러리가 본래 ES6 모듈 기반으로 작성되지 않았다면 전체 코드가 번들에 포함될 수 있습니다. 따라서 `lodash` 대신 Tree Shaking이 지원되는 `lodash-es`를 사용하는 등, 종속성을 추가할 때 라이브러리 자체의 지원 여부를 확인하는 것이 매우 중요합니다.
-
----
-
-_Last updated: 2026-04-14_
-- Raw Source: [[00_Raw/2026-04-20/Tree Shaking (번들 크기 최적화).md]]
----
diff --git a/Design & Experience/Turborepo-Orchestration.md b/Design & Experience/Turborepo-Orchestration.md
deleted file mode 100644
index d888bd38..00000000
--- a/Design & Experience/Turborepo-Orchestration.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-05096A
-category: "[[10_Wiki/💡 Topics/Design & Experience]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Turborepo-Orchestration"
----
-
-# [[Turborepo-Orchestration]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Design & Experience 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Turborepo-Orchestration.md]]
----
diff --git a/Design & Experience/Type Alias.md b/Design & Experience/Type Alias.md
deleted file mode 100644
index fca16223..00000000
--- a/Design & Experience/Type Alias.md	
+++ /dev/null
@@ -1,32 +0,0 @@
----
-id: P-REINFORCE-AUTO-D2A4B8
-category: "[[10_Wiki/💡 Topics/Design & Experience]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Type Alias"
----
-
-# [[Type Alias]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> Type Alias(타입 별칭)는 기존 타입에 새로운 이름을 부여하는 TypeScript의 타입 정의 방식이다 [1]. 인터페이스(Interface)와 유사하게 객체의 형태를 정의할 수 있지만, 이에 국한되지 않고 원시 타입(primitives), 유니온(unions), 튜플(tuples) 등 복잡한 타입 구성에도 이름을 지정할 수 있다 [1]. 동일한 이름으로 재선언 시 병합되지 않고 에러를 발생시키므로, 예기치 않은 타입 확장을 방지하는 엄격한 코드 관리에 유용하다 [2, 3].
-
-## 📖 구조화된 지식 (Synthesized Content)
-* **표현력과 활용 범위:** 타입 별칭은 인터페이스보다 더 넓은 표현력을 가진다 [4]. 객체 형태를 정의할 수 있을 뿐만 아니라 원시 타입, 유니온 타입, 교집합(Intersection) 타입, 매핑된 타입(Mapped Types), 조건부 타입(Conditional Types) 등 복잡한 타입 변환을 자유롭게 지원한다 [1, 4, 5]. 주로 함수 인수나 데이터 구조의 구체적인 형태를 선언할 때, 또는 인터페이스가 지원하지 않는 복잡한 기능이 필요할 때 사용된다 [5, 6].
-* **선언 병합(Declaration Merging) 방지:** 인터페이스는 동일한 이름으로 여러 번 선언할 경우 자동으로 합쳐지는 선언 병합 기능이 있어 확장에는 유리하지만, 종종 의도치 않은 구조 변경을 유발할 수 있다 [3, 4]. 반면, 타입 별칭은 동일한 이름을 재선언할 수 없으므로 실수로 인한 병합 시 즉각적인 컴파일 에러를 발생시킨다 [2, 3]. 이러한 특성 때문에 더 엄격한 관리가 가능하여 핵심 비즈니스 로직에서 예상치 못한 데이터 병합을 방어하는 데 적합하다 [2, 3].
-* **컴파일러 성능과 캐싱의 차이:** TypeScript 컴파일러는 인터페이스를 처리할 때 이름을 기준으로 타입 관계를 캐싱하지만, 타입 별칭을 통한 교집합 타입(`&`)은 매번 구조를 재귀적으로 병합하고 평탄화(flattening)하여 속성 충돌을 확인해야 한다 [7, 8]. 이로 인해 대규모 프로젝트에서는 복잡한 교집합 형태의 타입 별칭이 컴파일 성능을 저하시키는 원인이 될 수 있으며, TypeScript 성능 가이드에서는 객체 확장 시 인터페이스의 `extends`를 사용할 것을 권장한다 [7, 9, 10].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Design & Experience 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[Interface]], [[Union Types]], [[Intersection Types]]
-- **Projects/Contexts:** [[TypeScript Type System 설계]], [[대규모 애플리케이션의 도메인 모델링]]
-- **Contradictions/Notes:** 소스 내 개발자 커뮤니티에서는 Type Alias와 Interface의 사용을 두고 뚜렷한 논쟁이 존재한다. 일부 개발자들은 선언 병합으로 인한 잠재적 오류를 피하고 일관성을 유지하기 위해 전적으로 Type Alias만 사용할 것을 주장한다 [2, 4, 11]. 반면, TypeScript 공식 가이드 및 다른 개발자들은 컴파일러 캐싱에 따른 성능 최적화와 에러 메시지의 직관성(불투명한 이름 표시)을 이유로 Interface를 기본으로 사용해야 한다고 반론한다 [7, 12-15].
-
----
-*Last updated: 2026-04-18*
-- Raw Source: [[00_Raw/2026-04-20/Type Alias.md]]
----
diff --git a/Design & Experience/Type Branding.md b/Design & Experience/Type Branding.md
deleted file mode 100644
index cfb884a1..00000000
--- a/Design & Experience/Type Branding.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-62F9F5
-category: "[[10_Wiki/💡 Topics/Design & Experience]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Type Branding"
----
-
-# [[Type Branding]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Design & Experience 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Type Branding.md]]
----
diff --git a/Design & Experience/Type Declaration.md b/Design & Experience/Type Declaration.md
deleted file mode 100644
index b26ab9fe..00000000
--- a/Design & Experience/Type Declaration.md	
+++ /dev/null
@@ -1,33 +0,0 @@
----
-id: P-REINFORCE-AUTO-D3F069
-category: "[[10_Wiki/💡 Topics/Design & Experience]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Type Declaration"
----
-
-# [[Type Declaration]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 타입 선언(Type Declaration)은 TypeScript에서 변수, 함수, 객체 등의 데이터 형태와 규칙을 명시적으로 정의하여 시스템의 예측 가능성을 높이는 과정이다[1, 2]. 주로 `type` 별칭(Type Alias)이나 `interface` 키워드를 사용하여 정의하며, 외부 자바스크립트 라이브러리 사용 시에는 구현부 없이 타입 정보만 제공하는 `.d.ts` 선언 파일을 통해 활용된다[3]. 타입 단언(Type Assertion) 방식과 달리, 명시적인 타입 선언을 활용하면 컴파일러의 엄격한 구조적 타입 검사를 통해 런타임 에러를 사전에 방지할 수 있다[1].
-
-## 📖 구조화된 지식 (Synthesized Content)
-- **명시적 타입 선언의 안정성 보장**: 변수나 객체를 생성할 때 타입 단언(`as Type`)을 사용하면 필수 속성이 누락되더라도 타입 에러를 무시하고 넘어가 런타임 버그를 유발할 수 있다[1]. 반면, 올바른 타입 선언(Type Declaration) 문법을 사용해 값을 할당하면 요구되는 속성이 없을 때 컴파일러가 즉시 에러를 발생시켜 안전한 코드를 강제한다[1, 4].
-- **Interface와 Type Alias의 선언 방식 차이**: TypeScript에서 형태를 선언하는 두 가지 주요 도구는 인터페이스(Interface)와 타입 별칭(Type Alias)이다[2]. 인터페이스는 동일한 이름으로 여러 번 선언할 경우 TypeScript가 이를 하나로 합치는 '선언 병합(Declaration Merging)'을 지원하여 라이브러리 확장에 유리하다[5]. 반면, 타입 별칭은 동일한 이름으로 재선언할 수 없어 더 엄격한 상태 관리가 가능하며, 유니온(Union)이나 튜플(Tuple) 등의 복잡한 타입을 선언할 때 활용된다[2, 5, 6]. 
-- **선언 파일 (Declaration Files, `.d.ts`)**: JavaScript 라이브러리를 TypeScript 환경에서 사용할 때는 타입 정의가 필요하다. 이를 위해 실제 구현 코드 없이 타입 정보만을 제공하는 `.d.ts` 선언 파일을 사용하여 컴파일러에게 해당 라이브러리의 형태를 알려줄 수 있다[3]. 
-- **불필요한 타입 선언의 생략 (Type Inference)**: 코드를 작성할 때 모든 곳에 명시적인 타입 선언을 할 필요는 없다. TypeScript가 초깃값을 기반으로 값의 타입을 완벽히 유추(Type Inference)할 수 있는 상황에서는 굳이 명시적인 타입을 선언하지 않고 시스템의 추론을 신뢰하는 것이 코드를 간결하고 가독성 있게 유지하는 모범 사례이다[7].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Design & Experience 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[Type Alias]], [[Interface]], [[Type Assertion]], [[Declaration Merging]], [[Type Inference]]
-- **Projects/Contexts:** [[TypeScript Type System]], [[TypeScript Best Practices]]
-- **Contradictions/Notes:** 객체 타입을 선언할 때 `interface`와 `type` 중 어느 것을 사용할지에 대한 개발자 간의 선호도 논쟁이 존재한다. 일부는 선언 병합의 이점과 성능 최적화를 위해 `interface`를 선호하지만[8-10], 다른 진영에서는 의도치 않은 선언 병합에 의한 오작동을 막고 오류를 명확히 잡기 위해 `type` 선언을 엄격히 사용하는 것을 지향한다[6, 11].
-
----
-*Last updated: 2026-04-18*
-- Raw Source: [[00_Raw/2026-04-20/Type Declaration.md]]
----
diff --git a/Design & Experience/Type-Aware-Linting.md b/Design & Experience/Type-Aware-Linting.md
deleted file mode 100644
index 1ace3b43..00000000
--- a/Design & Experience/Type-Aware-Linting.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-CAD7C2
-category: "[[10_Wiki/💡 Topics/Design & Experience]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Type-Aware-Linting"
----
-
-# [[Type-Aware-Linting]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Design & Experience 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Type-Aware-Linting.md]]
----
diff --git a/Design & Experience/Type-Compatibility-Rules.md b/Design & Experience/Type-Compatibility-Rules.md
deleted file mode 100644
index e875d1c6..00000000
--- a/Design & Experience/Type-Compatibility-Rules.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-A6932F
-category: "[[10_Wiki/💡 Topics/Design & Experience]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Type-Compatibility-Rules"
----
-
-# [[Type-Compatibility-Rules]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Design & Experience 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Type-Compatibility-Rules.md]]
----
diff --git a/Design & Experience/Type-Compatibility-and-Subtyping.md b/Design & Experience/Type-Compatibility-and-Subtyping.md
deleted file mode 100644
index 5d870cf8..00000000
--- a/Design & Experience/Type-Compatibility-and-Subtyping.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-DAF93E
-category: "[[10_Wiki/💡 Topics/Design & Experience]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Type-Compatibility-and-Subtyping"
----
-
-# [[Type-Compatibility-and-Subtyping]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Design & Experience 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Type-Compatibility-and-Subtyping.md]]
----
diff --git a/Design & Experience/Type-Compatibility.md b/Design & Experience/Type-Compatibility.md
deleted file mode 100644
index 9d97f169..00000000
--- a/Design & Experience/Type-Compatibility.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-BEFC96
-category: "[[10_Wiki/💡 Topics/Design & Experience]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Type-Compatibility"
----
-
-# [[Type-Compatibility]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Design & Experience 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Type-Compatibility.md]]
----
diff --git a/Design & Experience/Type-Composition-via-Intersections.md b/Design & Experience/Type-Composition-via-Intersections.md
deleted file mode 100644
index d5102adb..00000000
--- a/Design & Experience/Type-Composition-via-Intersections.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-F4AFF9
-category: "[[10_Wiki/💡 Topics/Design & Experience]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Type-Composition-via-Intersections"
----
-
-# [[Type-Composition-via-Intersections]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Design & Experience 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Type-Composition-via-Intersections.md]]
----
diff --git a/Design & Experience/Type-Driven-Development.md b/Design & Experience/Type-Driven-Development.md
deleted file mode 100644
index b4d6cd20..00000000
--- a/Design & Experience/Type-Driven-Development.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-1CC60F
-category: "[[10_Wiki/💡 Topics/Design & Experience]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Type-Driven-Development"
----
-
-# [[Type-Driven-Development]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Design & Experience 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Type-Driven-Development.md]]
----
diff --git a/Design & Experience/Type-Erasure-and-Runtime-Behavior.md b/Design & Experience/Type-Erasure-and-Runtime-Behavior.md
deleted file mode 100644
index 8b70ad22..00000000
--- a/Design & Experience/Type-Erasure-and-Runtime-Behavior.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-BD9DA5
-category: "[[10_Wiki/💡 Topics/Design & Experience]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Type-Erasure-and-Runtime-Behavior"
----
-
-# [[Type-Erasure-and-Runtime-Behavior]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Design & Experience 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Type-Erasure-and-Runtime-Behavior.md]]
----
diff --git a/Design & Experience/Type-Guards-and-Narrowing.md b/Design & Experience/Type-Guards-and-Narrowing.md
deleted file mode 100644
index 489013fb..00000000
--- a/Design & Experience/Type-Guards-and-Narrowing.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-9DB0ED
-category: "[[10_Wiki/💡 Topics/Design & Experience]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Type-Guards-and-Narrowing"
----
-
-# [[Type-Guards-and-Narrowing]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Design & Experience 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Type-Guards-and-Narrowing.md]]
----
diff --git a/Design & Experience/Type-Narrowing.md b/Design & Experience/Type-Narrowing.md
deleted file mode 100644
index 76080a5e..00000000
--- a/Design & Experience/Type-Narrowing.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-60D972
-category: "[[10_Wiki/💡 Topics/Design & Experience]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Type-Narrowing"
----
-
-# [[Type-Narrowing]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Design & Experience 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Type-Narrowing.md]]
----
diff --git a/Design & Experience/Type-Safe-API-Design.md b/Design & Experience/Type-Safe-API-Design.md
deleted file mode 100644
index dbc9786f..00000000
--- a/Design & Experience/Type-Safe-API-Design.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-BDDBAD
-category: "[[10_Wiki/💡 Topics/Design & Experience]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Type-Safe-API-Design"
----
-
-# [[Type-Safe-API-Design]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Design & Experience 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Type-Safe-API-Design.md]]
----
diff --git a/Design & Experience/Type-Safety-and-Exhaustiveness-Checking.md b/Design & Experience/Type-Safety-and-Exhaustiveness-Checking.md
deleted file mode 100644
index e4868c9f..00000000
--- a/Design & Experience/Type-Safety-and-Exhaustiveness-Checking.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-5C9108
-category: "[[10_Wiki/💡 Topics/Design & Experience]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Type-Safety-and-Exhaustiveness-Checking"
----
-
-# [[Type-Safety-and-Exhaustiveness-Checking]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Design & Experience 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Type-Safety-and-Exhaustiveness-Checking.md]]
----
diff --git a/Design & Experience/Type-Safety.md b/Design & Experience/Type-Safety.md
deleted file mode 100644
index 74099882..00000000
--- a/Design & Experience/Type-Safety.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-0FE004
-category: "[[10_Wiki/💡 Topics/Design & Experience]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Type-Safety"
----
-
-# [[Type-Safety]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Design & Experience 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Type-Safety.md]]
----
diff --git a/Design & Experience/Type-Variance-in-TypeScript.md b/Design & Experience/Type-Variance-in-TypeScript.md
deleted file mode 100644
index 9a63f635..00000000
--- a/Design & Experience/Type-Variance-in-TypeScript.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-E14411
-category: "[[10_Wiki/💡 Topics/Design & Experience]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Type-Variance-in-TypeScript"
----
-
-# [[Type-Variance-in-TypeScript]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Design & Experience 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Type-Variance-in-TypeScript.md]]
----
diff --git a/Design & Experience/TypeScript Compiler API.md b/Design & Experience/TypeScript Compiler API.md
deleted file mode 100644
index a195183b..00000000
--- a/Design & Experience/TypeScript Compiler API.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-A553B6
-category: "[[10_Wiki/💡 Topics/Design & Experience]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - TypeScript Compiler API"
----
-
-# [[TypeScript Compiler API]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Design & Experience 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/TypeScript Compiler API.md]]
----
diff --git a/Design & Experience/TypeScript Type System (Interface Design).md b/Design & Experience/TypeScript Type System (Interface Design).md
deleted file mode 100644
index c65ad3de..00000000
--- a/Design & Experience/TypeScript Type System (Interface Design).md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-FE2C59
-category: "[[10_Wiki/💡 Topics/Design & Experience]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - TypeScript Type System (Interface Design)"
----
-
-# [[TypeScript Type System (Interface Design)]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Design & Experience 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/TypeScript Type System (Interface Design).md]]
----
diff --git a/Design & Experience/TypeScript 라이브러리 타입 확장.md b/Design & Experience/TypeScript 라이브러리 타입 확장.md
deleted file mode 100644
index a2f4d89c..00000000
--- a/Design & Experience/TypeScript 라이브러리 타입 확장.md	
+++ /dev/null
@@ -1,33 +0,0 @@
----
-id: P-REINFORCE-AUTO-BF50D4
-category: "[[10_Wiki/💡 Topics/Design & Experience]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - TypeScript 라이브러리 타입 확장"
----
-
-# [[TypeScript 라이브러리 타입 확장]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-- **선언 병합(Declaration Merging)을 통한 확장**: TypeScript에서 동일한 이름의 인터페이스를 여러 번 선언하면, 컴파일러가 이를 자동으로 하나의 인터페이스로 합칩니다 [1, 2]. 이 기능은 라이브러리 코드를 작성할 때 사용자가 필요에 따라 선언부를 유연하게 확장(extend)할 수 있도록 허용하는 핵심 메커니즘입니다 [2, 3]. 반면, 타입 별칭(Type Alias)은 동일한 이름으로 재선언할 수 없으므로 이러한 방식의 확장이 불가능합니다 [2, 4].
-- **성능을 고려한 인터페이스 확장(extends) 전략**: 타입을 확장할 때 교집합(Intersection, `&`)을 사용하는 것보다 `interface extends`를 사용하는 것이 권장됩니다 [5, 6]. TypeScript 컴파일러는 인터페이스를 처리할 때 이름 기준으로 타입 관계를 캐싱하여 활용하지만, 교집합 연산은 사용될 때마다 속성을 재귀적으로 병합하고 계산해야 하므로 대규모 프로젝트나 라이브러리 사용 시 컴파일 성능을 저하시킬 수 있습니다 [5, 7, 8].
-- **외부 라이브러리 타입 선언 파일(.d.ts)**: 기존 JavaScript 라이브러리를 TypeScript에서 사용할 때는 구현부 없이 타입 정보만을 제공하는 선언 파일(`.d.ts`)이 필요합니다 [9]. 많은 인기 라이브러리들이 자체 타입을 제공하지만, 타입이 존재하지 않는 경우 사용자가 직접 모듈을 선언하여 타입 확장을 하거나 에러를 억제할 수 있습니다 [9].
-- **내부 코드와 외부 라이브러리 코드 간의 이원화 설계**: 개발 커뮤니티에서는 "내부는 Types, 외부는 Interfaces를 사용하라"는 전략이 제안되기도 합니다 [6]. 애플리케이션 내부 핵심 도메인 로직에서는 의도치 않은 선언 병합으로 인한 버그나 충돌을 막기 위해 타입 별칭(Type)을 사용하여 엄격하게 관리하는 것이 좋습니다 [2, 10]. 반대로 외부 라이브러리로 제공되거나 외부와의 소통이 잦은 계약 지점의 코드에서는 소비자의 유연한 확장을 위해 인터페이스(Interface)를 사용하는 것이 바람직합니다 [2, 3].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Design & Experience 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[선언 병합(Declaration Merging)]], [[Interface]], [[Type Alias]], [[교집합 타입(Intersection Type)]]
-- **Projects/Contexts:** [[외부 라이브러리 API 설계]], [[TypeScript 컴파일러 캐싱 최적화]], [[선언 파일(.d.ts)]]
-- **Contradictions/Notes:** 애플리케이션 내부 코드의 경우, 인터페이스의 확장성을 '의도치 않은 속성 병합(Bad Thing)'으로 간주하여 타입 별칭(Type Alias)의 사용을 선호하는 실무적 의견이 다수 존재합니다 [4, 10-12]. 하지만 외부 패키지나 라이브러리 생태계에서는 여전히 사용자에게 타입 확장을 허용하기 위해 인터페이스를 채택하는 것이 정석으로 평가받고 있습니다 [2, 3]. 또한, 객체를 확장할 때 교집합(`&`) 방식은 유연해 보이지만, 성능 이슈와 충돌 검사 한계로 인해 `interface extends` 방식에 비해 상대적으로 지양됩니다 [5, 7, 13].
-
----
-*Last updated: 2026-04-18*
-- Raw Source: [[00_Raw/2026-04-20/TypeScript 라이브러리 타입 확장.md]]
----
diff --git a/Design & Experience/TypeScript 인터페이스 및 시스템 보호 아키텍처 설계.md b/Design & Experience/TypeScript 인터페이스 및 시스템 보호 아키텍처 설계.md
deleted file mode 100644
index b202c2f8..00000000
--- a/Design & Experience/TypeScript 인터페이스 및 시스템 보호 아키텍처 설계.md	
+++ /dev/null
@@ -1,40 +0,0 @@
----
-id: P-REINFORCE-AUTO-6ECC4D
-category: "[[10_Wiki/💡 Topics/Design & Experience]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - TypeScript 인터페이스 및 시스템 보호 아키텍처 설계"
----
-
-# [[TypeScript 인터페이스 및 시스템 보호 아키텍처 설계]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> TypeScript의 타입 시스템은 구조적 타이핑을 기반으로 하여 복잡한 비즈니스 로직을 보호하고 개발자의 의도를 명확히 규정하는 아키텍처적 도구이다 [1]. 인터페이스(Interface)와 타입 별칭(Type Alias)을 전략적으로 선택하여 컴파일 성능과 확장성을 최적화하며, `readonly` 수식어와 `satisfies` 연산자 등을 통해 예기치 않은 데이터 오염과 상태 변경을 원천적으로 차단한다 [2-4]. 이러한 견고한 인터페이스 설계는 시스템의 결합도를 낮추고 예측 가능성을 극대화하여 대규모 애플리케이션에서 철벽과 같은 수비 체계를 구축한다 [5, 6].
-
-## 📖 구조화된 지식 (Synthesized Content)
-- **인터페이스(Interface)와 타입 별칭(Type Alias)의 전략적 분리**
-  TypeScript 컴파일러는 인터페이스를 처리할 때 이름을 기준으로 타입 관계를 캐싱하여 대규모 프로젝트에서 컴파일 성능을 최적화한다 [2]. 반면, 타입 별칭을 이용한 교집합 타입(`&`)은 매번 구조를 평탄화하고 충돌을 확인해야 하므로 성능 저하를 유발할 수 있다 [2]. 따라서 외부와의 소통이 잦은 계약 지점이나 확장 지점 제공에는 선언 병합(Declaration Merging)이 가능한 인터페이스를, 핵심 비즈니스 로직의 엄격한 관리에는 예기치 않은 병합을 막는 타입 별칭을 사용하는 이원화 전략이 필요하다 [7].
-
-- **불변성(Immutability) 확립과 데이터 오염 방지**
-  `readonly` 수식어는 객체와 배열의 수정을 컴파일 수준에서 금지하여 데이터 무결성을 보장하며, 런타임 성능 오버헤드가 발생하는 `Object.freeze()`보다 효율적이다 [3]. 깊은 수준의 중첩된 객체까지 예기치 않은 변경으로부터 방어하려면, 매핑 타입과 조건부 타입을 결합한 재귀적 불변성(`DeepReadonly<T>`)을 구축하는 것이 복잡한 상태 관리 아키텍처에서 필수적이다 [8].
-
-- **과잉 속성 체크(EPC)의 한계와 `satisfies` 연산자를 통한 경계면 수비**
-  객체 리터럴을 직접 할당할 때 발생하는 과잉 속성 체크(Excess Property Checking)는 선언되지 않은 속성의 유입을 차단하는 첫 번째 방어선이다 [9, 10]. 하지만 간접 할당(변수 선언 후 할당) 과정을 거치면 이 기제가 우회되는 취약점이 있다 [10]. 이를 극복하기 위해 `satisfies` 연산자를 활용하면, 대상 인터페이스의 요구사항을 충족하는지 검사하면서도 리터럴 타입 등 속성의 구체적인 값을 잃지 않아 더욱 정밀한 수비가 가능해진다 [4].
-
-- **아키텍처적 관점에서의 인터페이스 설계 (SOLID 원칙)**
-  하나의 인터페이스가 너무 많은 책임을 지는 것을 피하고 최소 단위로 쪼개어 결합도를 낮추는 인터페이스 분리 원칙(ISP)을 지향해야 한다 [5]. 복잡한 내부 시스템을 단순한 인터페이스로 감싸는 퍼사드(Facade) 패턴을 활용하면 개발자의 인지 부하를 줄일 수 있다 [5]. 더 나아가, 단순히 데이터의 유효성을 체크하는 것을 넘어 더 구체적이고 신뢰할 수 있는 타입의 객체로 변환하는 "검증하지 말고 파싱하라"는 수비적 프로그래밍 철학을 실천해야 한다 [5].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Design & Experience 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[구조적 타이핑 (Structural Typing)]], [[과잉 속성 체크 (Excess Property Checking)]], [[재귀적 불변성 (DeepReadonly)]], [[식별 가능한 유니온 (Discriminated Unions)]], [[브랜디드 타입 (Branded Types)]], [[SOLID 원칙]]
-- **Projects/Contexts:** [[Toss Front SDK의 Facade 패턴 적용 사례]]
-- **Contradictions/Notes:** TypeScript의 구조적 타이핑은 최소 요건만 충족하면 호환성을 허용하므로 매우 유연하지만, 이메일 주소와 이름이 같은 `string`으로 취급되는 등 "기본 타입에의 집착(Primitive Obsession)" 문제를 야기한다 [11]. 이를 방어하기 위해 컴파일 시점에만 존재하는 고유 속성을 부여하는 브랜디드 타입(Branded Types)을 사용하여 데이터의 무분별한 혼용을 차단해야 한다 [10, 11].
-
----
-*Last updated: 2026-04-18*
-- Raw Source: [[00_Raw/2026-04-20/TypeScript 인터페이스 및 시스템 보호 아키텍처 설계.md]]
----
diff --git a/Design & Experience/TypeScript 컴파일러 캐싱 최적화.md b/Design & Experience/TypeScript 컴파일러 캐싱 최적화.md
deleted file mode 100644
index 42e355ef..00000000
--- a/Design & Experience/TypeScript 컴파일러 캐싱 최적화.md	
+++ /dev/null
@@ -1,32 +0,0 @@
----
-id: P-REINFORCE-AUTO-3D0990
-category: "[[10_Wiki/💡 Topics/Design & Experience]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - TypeScript 컴파일러 캐싱 최적화"
----
-
-# [[TypeScript 컴파일러 캐싱 최적화]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> TypeScript 컴파일러는 타입 검사 속도와 IDE 응답성을 향상시키기 위해 타입 관계를 캐싱하는 최적화 메커니즘을 사용합니다. 이 캐싱 메커니즘은 객체를 확장할 때 주로 `interface extends`를 사용할 경우 해당 이름을 기준으로 효과적으로 작동하며, 타입 검사 성능을 향상시키는 핵심적인 역할을 합니다 [1-3].
-
-## 📖 구조화된 지식 (Synthesized Content)
-- **인터페이스 확장(Interface Extends)의 캐싱 이점**: TypeScript 컴파일러는 `interface extends`를 통해 객체를 확장할 때 해당 인터페이스의 이름을 기준으로 타입 관계를 캐싱합니다 [1-3]. 한 번 캐시가 만들어지면 해당 이름이 사용되는 모든 곳에서 캐시를 참조하게 되므로 타입 검사가 효율적으로 이루어집니다 [1, 2].
-- **교집합(Intersection Types)의 연산 오버헤드**: `type` 선언 시 앰퍼샌드(`&`) 기호를 사용하는 교집합은 인터페이스와 달리 전체 교집합 타입 자체가 캐싱되지 않습니다 [3]. 교집합은 속성을 재귀적으로 병합해야 하고 처리가 복잡하여, 코드가 사용될 때마다 거의 매번 구조를 새롭게 계산해야 합니다 [1-3]. 특히 검사 대상이 되는 교집합 타입에 대해 "유효하거나 평탄화된(flattened)" 타입을 확인하기 전에 모든 구성 요소를 일일이 확인해야 하는 오버헤드가 발생합니다 [3].
-- **성능 가이드라인의 권장 사항**: TypeScript 성능 가이드(Performance Guide)에서는 위와 같은 컴파일러의 캐싱 동작 방식 때문에, 가능하면 교집합보다는 `interface extends`를 사용할 것을 권장합니다 [1-3]. 이를 통해 TypeScript 컴파일러가 캐싱을 보다 잘 활용할 수 있으며, 결과적으로 타입 검사(Type Checking) 및 IDE의 코드 기반 업데이트 성능이 약간 더 빨라집니다 [4, 5].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Design & Experience 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[인터페이스 확장(Interface Extends)]], [[교집합 타입(Intersection Types)]]
-- **Projects/Contexts:** [[TypeScript Performance Guide]]
-- **Contradictions/Notes:** 인터페이스 간의 타입 관계는 이름 기반으로 캐싱되어 성능상 이점을 제공하지만, 교집합 타입은 전체가 캐싱되지 않고 사용할 때마다 평탄화 및 재계산을 거쳐야 한다는 구조적 차이가 존재합니다 [3].
-
----
-*Last updated: 2026-04-18*
-- Raw Source: [[00_Raw/2026-04-20/TypeScript 컴파일러 캐싱 최적화.md]]
----
diff --git a/Design & Experience/TypeScript-Compiler-API-Design.md b/Design & Experience/TypeScript-Compiler-API-Design.md
deleted file mode 100644
index 1e0d4773..00000000
--- a/Design & Experience/TypeScript-Compiler-API-Design.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-D06F7B
-category: "[[10_Wiki/💡 Topics/Design & Experience]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - TypeScript-Compiler-API-Design"
----
-
-# [[TypeScript-Compiler-API-Design]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Design & Experience 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/TypeScript-Compiler-API-Design.md]]
----
diff --git a/Design & Experience/TypeScript-Compiler-API.md b/Design & Experience/TypeScript-Compiler-API.md
deleted file mode 100644
index 8237d687..00000000
--- a/Design & Experience/TypeScript-Compiler-API.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-9F7F6E
-category: "[[10_Wiki/💡 Topics/Design & Experience]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - TypeScript-Compiler-API"
----
-
-# [[TypeScript-Compiler-API]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Design & Experience 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/TypeScript-Compiler-API.md]]
----
diff --git a/Design & Experience/TypeScript-Compiler-Architecture.md b/Design & Experience/TypeScript-Compiler-Architecture.md
deleted file mode 100644
index 0f86439f..00000000
--- a/Design & Experience/TypeScript-Compiler-Architecture.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-98247B
-category: "[[10_Wiki/💡 Topics/Design & Experience]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - TypeScript-Compiler-Architecture"
----
-
-# [[TypeScript-Compiler-Architecture]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Design & Experience 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/TypeScript-Compiler-Architecture.md]]
----
diff --git a/Design & Experience/TypeScript-Language-Service-API.md b/Design & Experience/TypeScript-Language-Service-API.md
deleted file mode 100644
index 04eba6ce..00000000
--- a/Design & Experience/TypeScript-Language-Service-API.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-C7C758
-category: "[[10_Wiki/💡 Topics/Design & Experience]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - TypeScript-Language-Service-API"
----
-
-# [[TypeScript-Language-Service-API]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Design & Experience 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/TypeScript-Language-Service-API.md]]
----
diff --git a/Design & Experience/TypeScript-Project-References.md b/Design & Experience/TypeScript-Project-References.md
deleted file mode 100644
index 000e6e4a..00000000
--- a/Design & Experience/TypeScript-Project-References.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-E852BD
-category: "[[10_Wiki/💡 Topics/Design & Experience]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - TypeScript-Project-References"
----
-
-# [[TypeScript-Project-References]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Design & Experience 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/TypeScript-Project-References.md]]
----
diff --git a/Design & Experience/TypeScript의 안전한 인터페이스 설계.md b/Design & Experience/TypeScript의 안전한 인터페이스 설계.md
deleted file mode 100644
index ea4987b5..00000000
--- a/Design & Experience/TypeScript의 안전한 인터페이스 설계.md	
+++ /dev/null
@@ -1,46 +0,0 @@
----
-id: P-REINFORCE-AUTO-08AE3A
-category: "[[10_Wiki/💡 Topics/Design & Experience]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - TypeScript의 안전한 인터페이스 설계"
----
-
-# [[TypeScript의 안전한 인터페이스 설계]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> TypeScript의 인터페이스 설계는 언어의 근본적인 특성인 구조적 타이핑(Structural Typing)의 유연성을 수용하면서도, 의도치 않은 데이터 유입과 런타임 에러를 방어하는 것을 핵심으로 합니다 [1-3]. 이를 위해 개발자는 `interface`와 `type alias`를 전략적으로 선택하고, `readonly`를 통한 불변성 확보, 식별 가능한 유니온을 활용한 상태 관리, 그리고 `satisfies` 연산자나 브랜디드 타입(Branded Types) 같은 고급 기법을 동원해야 합니다 [4-8]. 결과적으로 안전한 인터페이스 설계는 시스템의 예측 가능성을 높이고 변경에 따른 부작용을 최소화하는 견고한 아키텍처적 도구로 작용합니다 [9].
-
-## 📖 구조화된 지식 (Synthesized Content)
-*   **구조적 타이핑과 과잉 속성 체크 (Structural Typing & EPC)**
-    TypeScript는 객체의 실제 구조가 일치하면 동일한 타입으로 간주하는 구조적 타이핑을 사용합니다 [3, 10]. 이러한 유연성은 예기치 않은 속성의 유입이라는 허점을 만드는데, 이를 방어하기 위해 객체 리터럴 직접 할당 시 과잉 속성 체크(Excess Property Checking, EPC)가 작동합니다 [1, 3]. 더 나아가 할당 과정에서 타입 단언(`as`)을 사용하기보다 `satisfies` 연산자를 활용하면, 객체의 구체적인 속성(리터럴 타입 등)을 유지하면서도 인터페이스 요구사항을 엄격하게 검증하여 과잉 속성과 오타를 컴파일 시점에 차단할 수 있습니다 [8, 11-13].
-
-*   **Interface와 Type Alias의 전략적 선택**
-    성능과 확장성 측면에서 두 도구는 명확한 차이를 가집니다. `interface`는 컴파일러가 이름을 기준으로 캐싱을 수행하며 선언 병합(Declaration Merging)이 가능해 확장에 유리하므로, 핵심 도메인 모델이나 외부 API 계약에 적합합니다 [4, 14, 15]. 반면 `type alias`의 교집합(`&`)은 매번 구조를 재계산하여 성능을 저하시킬 수 있으나, 동일한 이름의 재선언을 막아 엄격한 관리가 가능하므로 비즈니스 로직 내부에서 유용합니다 [4, 15-17].
-
-*   **불변성(Immutability)을 통한 데이터 보호**
-    객체나 배열이 예기치 않게 변경되는 것을 막기 위해 `readonly` 수식어를 사용합니다 [5, 18]. 런타임 오버헤드가 발생하는 `Object.freeze()`와 달리 `readonly`는 컴파일 시점에 완벽히 동작하여 효율적인 데이터 무결성을 제공합니다 [5, 19, 20]. 단, 기본 `readonly`는 얕은(shallow) 수준만 보호하므로, 중첩된 객체를 다룰 때는 매핑 타입과 조건부 타입을 결합한 `DeepReadonly`와 같은 재귀적 타입을 설계해야 완벽한 방어가 가능합니다 [6, 21, 22].
-
-*   **식별 가능한 유니온(Discriminated Unions)과 완전성 검사**
-    공통된 리터럴 속성(태그)을 사용하여 타입을 좁히는(Narrowing) 식별 가능한 유니온 패턴은 상태 관리에서 불가능한 상태를 원천 차단합니다 [6, 23, 24]. 이와 함께 `never` 타입을 활용한 완전성 검사(Exhaustiveness Checking)를 적용하면, 새로운 타입이나 상태가 추가되었을 때 개발자가 이를 누락하지 않도록 컴파일 에러를 발생시켜 빈틈없는 수비 체계를 유지할 수 있습니다 [24-26].
-
-*   **브랜디드 타입(Branded Types)을 활용한 명목적 타이핑**
-    구조적 타이핑의 한계로 인해 본질적으로 다른 데이터(예: 이메일과 일반 이름 문자열)가 섞이는 것을 막기 위해 브랜디드 타입을 사용합니다 [7, 27]. 고유한 표식(`__brand` 등)이나 `unique symbol`을 타입에 부여함으로써 컴파일 시점에 엄격한 명목적 타이핑(Nominal Typing)을 에뮬레이트하며, 외부의 오염된 데이터가 시스템 핵심 로직으로 침투하는 것을 차단합니다 [7, 28, 29].
-
-*   **SOLID 원칙에 기반한 인터페이스 설계**
-    안전한 설계는 객체 지향의 원칙과 궤를 같이합니다. 인터페이스 분리 원칙(ISP)에 따라 한 인터페이스에 너무 많은 책임을 부여하지 않고 최소 단위로 쪼개야 변경에 유연하게 대응할 수 있습니다 [30, 31]. 또한, 복잡한 내부 서브시스템을 단순한 인터페이스로 노출하는 퍼사드(Facade) 패턴을 적용하면, 개발자의 인지 부하를 줄이고 휴먼 에러를 방지할 수 있습니다 [31-33].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Design & Experience 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[구조적 타이핑]], [[과잉 속성 체크(EPC)]], [[식별 가능한 유니온]], [[브랜디드 타입]], [[불변성(Immutability)]]
-- **Projects/Contexts:** [[대규모 애플리케이션 개발]], [[프론트엔드 아키텍처 및 SDK 설계]]
-- **Contradictions/Notes:** `type`과 `interface`의 사용 지침과 관련하여, TypeScript 성능과 캐싱을 고려해 객체 확장에 `interface extends`를 권장하는 측면과 [4, 14], 선언 병합(Declaration Merging)으로 인한 의도치 않은 타입 변경을 방지하기 위해 보다 엄격한 `type`의 사용을 선호하는 개발자들의 의견이 대립하는 사례가 존재합니다 [15, 17, 34, 35].
-
----
-*Last updated: 2026-04-18*
-- Raw Source: [[00_Raw/2026-04-20/TypeScript의 안전한 인터페이스 설계.md]]
----
diff --git a/Design & Experience/TypeScript의 인터페이스 및 객체 타입 설계.md b/Design & Experience/TypeScript의 인터페이스 및 객체 타입 설계.md
deleted file mode 100644
index 1af6b310..00000000
--- a/Design & Experience/TypeScript의 인터페이스 및 객체 타입 설계.md	
+++ /dev/null
@@ -1,47 +0,0 @@
----
-id: P-REINFORCE-AUTO-844A65
-category: "[[10_Wiki/💡 Topics/Design & Experience]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - TypeScript의 인터페이스 및 객체 타입 설계"
----
-
-# [[TypeScript의 인터페이스 및 객체 타입 설계]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> TypeScript의 인터페이스와 객체 타입 설계는 명시적인 이름이 아닌 객체의 실제 형태와 속성을 기준으로 타입 호환성을 결정하는 구조적 타이핑(Structural Typing)을 근간으로 합니다. 확장성과 컴파일 성능을 고려하여 인터페이스(Interface)와 타입 별칭(Type Alias)을 전략적으로 선택해야 하며, `readonly` 수식어, 초과 속성 검사(Excess Property Checking), `satisfies` 연산자 등의 도구를 활용해 런타임 오류를 방지하고 견고하고 예측 가능한 객체 경계를 구축하는 것이 설계의 핵심입니다.
-
-## 📖 구조화된 지식 (Synthesized Content)
-**구조적 타이핑 (Structural Typing) 메커니즘**
-TypeScript의 객체 타입은 명목적 타이핑(Nominal Typing)과 달리 명시적인 상속 선언 없이도 객체가 가진 속성과 메서드의 "구조"가 일치하면 동일한 타입으로 간주하는 덕 타이핑(Duck Typing) 방식을 따릅니다 [1-3]. 예를 들어, 객체 타입 `{}`는 단순히 빈 객체를 의미하는 것이 아니라 "속성에 접근할 수는 있으나 특정 속성을 강제하지 않는 값"의 집합을 의미합니다 [4]. 이러한 구조적 타이핑은 유연성을 제공하지만, 의도하지 않은 데이터가 객체에 유입될 위험이 있어 세심한 타입 설계가 필요합니다 [3, 5].
-
-**인터페이스(Interface)와 타입 별칭(Type Alias)의 전략적 선택**
-객체의 형태를 정의할 때 인터페이스와 타입 별칭은 각기 다른 성능과 확장성 특성을 가집니다.
-*   **성능과 캐싱**: TypeScript 컴파일러는 인터페이스를 처리할 때 해당 이름을 기준으로 타입 관계를 캐싱하여 재사용합니다 [6-8]. 반면 타입 별칭을 통한 교집합(`&`) 연산은 매번 객체의 구조를 평탄화하고 계산해야 하므로 대규모 프로젝트에서는 컴파일 성능을 저하시킬 수 있습니다 [7-9]. 따라서 객체 확장 시에는 교집합 대신 인터페이스의 `extends`를 사용하는 것이 성능상 권장됩니다 [7, 9, 10].
-*   **선언 병합(Declaration Merging)과 관리**: 인터페이스는 동일한 이름으로 여러 번 선언하면 하나의 인터페이스로 합쳐지는 선언 병합을 지원하여, 라이브러리 제작자가 사용자에게 확장 지점을 제공할 때 유용합니다 [11, 12]. 그러나 핵심 비즈니스 로직에서는 예기치 않은 병합으로 인한 오류를 방지하기 위해 타입 별칭을 선호하는 방식도 유효하며, 이를 적절히 이원화하여 사용하는 전략이 필요합니다 [12-14].
-
-**초과 속성 검사(EPC)와 `satisfies` 연산자를 통한 경계 방어**
-*   **초과 속성 검사 (Excess Property Checking)**: 객체 리터럴을 직접 할당하거나 함수 인자로 전달할 때 대상 인터페이스에 정의되지 않은 초과 속성이 포함되는 것을 차단하는 기능입니다 [3, 15]. 이는 오타나 잘못된 속성 전달을 컴파일 시점에 포착하게 해줍니다 [16, 17]. 하지만 변수에 먼저 선언 및 할당한 후 전달하면 구조적 타이핑의 "최소 요건 충족" 원칙에 따라 이 검사가 작동하지 않는 한계가 있습니다 [5, 18, 19].
-*   **`satisfies` 연산자 도입**: 이러한 한계를 극복하기 위해 `satisfies` 연산자를 활용할 수 있습니다. `satisfies`는 객체가 특정 인터페이스를 만족하는지 엄격히 검사하면서도, 타입 단언(`as`)이나 명시적 어노테이션(`:`)과 달리 객체가 가진 구체적인 리터럴 속성 타입과 추가된 속성에 대한 추론 정보를 잃지 않게 유지해 줍니다 [20-22].
-
-**선택적(Optional) 속성과 불변성(Immutability) 설계**
-*   **선택적 속성 (`?`)**: 인터페이스 내에서 불확실하거나 조건부로 존재하는 데이터를 모델링할 때 사용되며, 내부적으로는 `undefined`와의 유니온 타입으로 처리되어 타입 안전성을 제공합니다 [23, 24].
-*   **읽기 전용 속성 (`readonly`)**: 런타임 오버헤드 없이 컴파일 시점에 객체 속성의 수정을 금지하여 불변성을 보장합니다 [25-27]. 단, `readonly`는 해당 속성 자체에 대한 얕은(shallow) 보호만 제공하므로, 중첩된 객체 구조 전체를 보호해야 할 때는 재귀적 타입(DeepReadonly) 패턴을 구성해 활용해야 합니다 [28, 29]. 
-
-**객체지향 설계 원칙(SOLID)의 반영**
-거대한 인터페이스 하나에 너무 많은 책임을 부여하면 시스템이 변경에 취약해집니다 [30, 31]. 인터페이스 분리 원칙(Interface Segregation Principle)을 적용하여, 클라이언트가 실제로 사용하는 기능에만 의존하도록 인터페이스를 작게 나누고 이를 합성(Composition)하여 사용하는 것이 유연하고 견고한 설계의 핵심입니다 [12, 30, 32].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Design & Experience 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[구조적 타이핑 (Structural Typing)]], [[초과 속성 검사 (Excess Property Checking)]], [[선언 병합 (Declaration Merging)]], [[satisfies 연산자]]
-- **Projects/Contexts:** [[대규모 TypeScript 애플리케이션 아키텍처 구축]], [[SOLID 원칙 기반의 타입 시스템 설계]]
-- **Contradictions/Notes:** 소스 간 의견 대립이 존재합니다. 일부 개발자(소스 52, 138, 141)는 캐싱 성능 최적화와 외부 확장을 위한 선언 병합 기능 때문에 '인터페이스(Interface) 우선 사용'을 강력히 주장하지만, 또 다른 현업 개발자(소스 138, 140, 147)는 의도치 않은 선언 병합으로 인해 런타임 로직이 오염될 위험과 일관된 문법을 이유로 '모든 상황에서 타입 별칭(Type)만을 사용하는 규칙'을 조직 내에 강제하는 것이 장기 유지보수에 유리하다고 반박합니다.
-
----
-*Last updated: 2026-04-18*
-- Raw Source: [[00_Raw/2026-04-20/TypeScript의 인터페이스 및 객체 타입 설계.md]]
----
diff --git a/Design & Experience/UX-Gamification.md b/Design & Experience/UX-Gamification.md
deleted file mode 100644
index a13b4115..00000000
--- a/Design & Experience/UX-Gamification.md	
+++ /dev/null
@@ -1,34 +0,0 @@
----
-id: P-REINFORCE-AI-042
-category: "[[10_Wiki/💡 Topics/Design & Experience]]"
-confidence_score: 0.95
-tags: [ux, gamification, design, psychology]
-last_reinforced: 2026-06-XX
-github_commit: "[P-Reinforce] Processed UX_Gamification.md"
----
-
-# [[UX - Gamification]] (사용자 경험 및 게이미피케이션)
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 게임 메커니즘을 활용해 사용자의 동기를 유발하고 지속적인 참여를 설계하는 것은, 사용자 경험(UX)의 목표와 행동 심리학적 원리를 결합한 필수 전략이다.
-
-## 📖 구조화된 지식 (Synthesized Content)
-- **핵심 정의:** 게이미피케이션은 게임을 직접 사용하지 않더라도, 게임 디자인 요소(점수, 배지, 순위 등)를 비게임 영역에 적용하여 사용자 행동 변화를 유도하는 설계 기법이다.
-- **적용 원리 (Psychology & Design):**
-    1. **동기 이론 결합:** 내재적 동기(Intrinsic Motivation)와 외재적 동기(Extrinsic Motivation)의 균형을 맞추는 것이 핵심. 성취감, 자율성, 연관성(Self-Determination Theory, SDT) 충족에 초점을 둔다.
-    2. **행동 심리:** 보상 체계 설계가 중요하며, 즉각적인 피드백과 작은 성공 경험을 반복적으로 제공하여 참여를 유지시킨다 (Variable Ratio Reinforcement).
-    3. **UX 흐름:** 사용자 여정 지도(User Journey Map) 상에서 지루하거나 이탈 가능성이 높은 구간에 게이미피케이션 요소를 배치하는 것이 효과적이다.
-- **구현 요소 (Mechanics):** 
-    - 포인트 시스템, 배지/트로피, 리더보드 (가장 일반적).
-    - 스토리텔링을 통한 목표 부여 (Narrative Integration).
-    - 도전 과제(Challenges)와 피드백 루프 설계.
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 단순히 재미 요소를 추가하는 것만으로는 부족하며, 반드시 비즈니스/학습 목표 달성이라는 명확한 목적(Goal-Oriented Design)이 있어야 한다.
-- **정책 변화:** 게이미피케이션의 남용은 '보상의 역효과 (Overjustification Effect)'를 초래할 수 있으므로, 보상이 학습 자체를 방해하지 않도록 신중하게 설계해야 한다.
-
-## 🔗 지식 연결 (Graph)
-- Parent: [[User Experience (UX) Design]]
-- Related: [[Self-Determination Theory]] , [[Behavioral Economics]] , [[Gamification-Design]]
-- Raw Source: [[00_Raw/UX_Gamification.md]]
----
\ No newline at end of file
diff --git a/Design & Experience/UX_UI in Interactive Media.md b/Design & Experience/UX_UI in Interactive Media.md
deleted file mode 100644
index c1b4db6a..00000000
--- a/Design & Experience/UX_UI in Interactive Media.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-8F3CFA
-category: "[[10_Wiki/💡 Topics/Design & Experience]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - UX_UI in Interactive Media"
----
-
-# [[UX_UI in Interactive Media]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Design & Experience 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/UX_UI in Interactive Media.md]]
----
diff --git a/Design & Experience/Unified-User-Experience.md b/Design & Experience/Unified-User-Experience.md
deleted file mode 100644
index b2030c37..00000000
--- a/Design & Experience/Unified-User-Experience.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-0A5862
-category: "[[10_Wiki/💡 Topics/Design & Experience]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Unified-User-Experience"
----
-
-# [[Unified-User-Experience]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Design & Experience 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Unified-User-Experience.md]]
----
diff --git a/Design & Experience/Union-Types.md b/Design & Experience/Union-Types.md
deleted file mode 100644
index afc5641c..00000000
--- a/Design & Experience/Union-Types.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-A21B05
-category: "[[10_Wiki/💡 Topics/Design & Experience]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Union-Types"
----
-
-# [[Union-Types]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Design & Experience 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Union-Types.md]]
----
diff --git a/Design & Experience/Urban-Morphology.md b/Design & Experience/Urban-Morphology.md
deleted file mode 100644
index 9d0c3d18..00000000
--- a/Design & Experience/Urban-Morphology.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-27741A
-category: "[[10_Wiki/💡 Topics/Design & Experience]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Urban-Morphology"
----
-
-# [[Urban-Morphology]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Design & Experience 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Urban-Morphology.md]]
----
diff --git a/Design & Experience/Urban-Planning-Simulations.md b/Design & Experience/Urban-Planning-Simulations.md
deleted file mode 100644
index dc07ff82..00000000
--- a/Design & Experience/Urban-Planning-Simulations.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-F27EBE
-category: "[[10_Wiki/💡 Topics/Design & Experience]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Urban-Planning-Simulations"
----
-
-# [[Urban-Planning-Simulations]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Design & Experience 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Urban-Planning-Simulations.md]]
----
diff --git a/Design & Experience/User Experience (UX) Design.md b/Design & Experience/User Experience (UX) Design.md
deleted file mode 100644
index a322a496..00000000
--- a/Design & Experience/User Experience (UX) Design.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-A613D6
-category: "[[10_Wiki/💡 Topics/Design & Experience]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - User Experience (UX) Design"
----
-
-# [[User Experience (UX) Design]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Design & Experience 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/User Experience (UX) Design.md]]
----
diff --git a/Design & Experience/User Experience (UX) in Game Design.md b/Design & Experience/User Experience (UX) in Game Design.md
deleted file mode 100644
index 6b55c693..00000000
--- a/Design & Experience/User Experience (UX) in Game Design.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-94EC93
-category: "[[10_Wiki/💡 Topics/Design & Experience]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - User Experience (UX) in Game Design"
----
-
-# [[User Experience (UX) in Game Design]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Design & Experience 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/User Experience (UX) in Game Design.md]]
----
diff --git a/Design & Experience/User-Experience-Design.md b/Design & Experience/User-Experience-Design.md
deleted file mode 100644
index dd2b2867..00000000
--- a/Design & Experience/User-Experience-Design.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-41A69F
-category: "[[10_Wiki/💡 Topics/Design & Experience]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - User-Experience-Design"
----
-
-# [[User-Experience-Design]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Design & Experience 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/User-Experience-Design.md]]
----
diff --git a/Design & Experience/Variance (Covariance Contravariance Invariance).md b/Design & Experience/Variance (Covariance Contravariance Invariance).md
deleted file mode 100644
index a600cb20..00000000
--- a/Design & Experience/Variance (Covariance Contravariance Invariance).md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-372429
-category: "[[10_Wiki/💡 Topics/Design & Experience]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Variance (Covariance Contravariance Invariance)"
----
-
-# [[Variance (Covariance Contravariance Invariance)]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Design & Experience 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Variance (Covariance, Contravariance, Invariance).md]]
----
diff --git a/Design & Experience/Variance-(Covariance-Contravariance-Invariance).md b/Design & Experience/Variance-(Covariance-Contravariance-Invariance).md
deleted file mode 100644
index 818208fa..00000000
--- a/Design & Experience/Variance-(Covariance-Contravariance-Invariance).md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-84D6F1
-category: "[[10_Wiki/💡 Topics/Design & Experience]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Variance-(Covariance-Contravariance-Invariance)"
----
-
-# [[Variance-(Covariance-Contravariance-Invariance)]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Design & Experience 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Variance-(Covariance-Contravariance-Invariance).md]]
----
diff --git a/Design & Experience/Variance-Covariance-Contravariance.md b/Design & Experience/Variance-Covariance-Contravariance.md
deleted file mode 100644
index a17ca64c..00000000
--- a/Design & Experience/Variance-Covariance-Contravariance.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-429958
-category: "[[10_Wiki/💡 Topics/Design & Experience]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Variance-Covariance-Contravariance"
----
-
-# [[Variance-Covariance-Contravariance]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Design & Experience 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Variance-Covariance-Contravariance.md]]
----
diff --git a/Design & Experience/Video Game Design.md b/Design & Experience/Video Game Design.md
deleted file mode 100644
index abcdb1d6..00000000
--- a/Design & Experience/Video Game Design.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-FE3DA6
-category: "[[10_Wiki/💡 Topics/Design & Experience]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Video Game Design"
----
-
-# [[Video Game Design]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Design & Experience 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Video Game Design.md]]
----
diff --git a/Design & Experience/Visual-Hierarchy-in-Game-Design.md b/Design & Experience/Visual-Hierarchy-in-Game-Design.md
deleted file mode 100644
index cd1b1fa7..00000000
--- a/Design & Experience/Visual-Hierarchy-in-Game-Design.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-827C0B
-category: "[[10_Wiki/💡 Topics/Design & Experience]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Visual-Hierarchy-in-Game-Design"
----
-
-# [[Visual-Hierarchy-in-Game-Design]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Design & Experience 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Visual-Hierarchy-in-Game-Design.md]]
----
diff --git a/Design & Experience/Von Neumann-Morgenstern Axioms.md b/Design & Experience/Von Neumann-Morgenstern Axioms.md
deleted file mode 100644
index 4bd8bec6..00000000
--- a/Design & Experience/Von Neumann-Morgenstern Axioms.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-E77B4E
-category: "[[10_Wiki/💡 Topics/Design & Experience]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Von Neumann-Morgenstern Axioms"
----
-
-# [[Von Neumann-Morgenstern Axioms]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Design & Experience 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Von Neumann-Morgenstern Axioms.md]]
----
diff --git a/Design & Experience/W3C-Semantic-Web-Standards.md b/Design & Experience/W3C-Semantic-Web-Standards.md
deleted file mode 100644
index 993cfd07..00000000
--- a/Design & Experience/W3C-Semantic-Web-Standards.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-CEA1E7
-category: "[[10_Wiki/💡 Topics/Design & Experience]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - W3C-Semantic-Web-Standards"
----
-
-# [[W3C-Semantic-Web-Standards]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Design & Experience 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/W3C-Semantic-Web-Standards.md]]
----
diff --git a/Design & Experience/Wayfinding-Design.md b/Design & Experience/Wayfinding-Design.md
deleted file mode 100644
index 86fa91fa..00000000
--- a/Design & Experience/Wayfinding-Design.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-9E4F37
-category: "[[10_Wiki/💡 Topics/Design & Experience]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Wayfinding-Design"
----
-
-# [[Wayfinding-Design]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Design & Experience 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Wayfinding-Design.md]]
----
diff --git a/Design & Experience/Wicked-Problems.md b/Design & Experience/Wicked-Problems.md
deleted file mode 100644
index 5a9a6689..00000000
--- a/Design & Experience/Wicked-Problems.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-9805C7
-category: "[[10_Wiki/💡 Topics/Design & Experience]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Wicked-Problems"
----
-
-# [[Wicked-Problems]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Design & Experience 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Wicked-Problems.md]]
----
diff --git a/Design & Experience/Width-and-Depth-Subtyping.md b/Design & Experience/Width-and-Depth-Subtyping.md
deleted file mode 100644
index a1fdf8ab..00000000
--- a/Design & Experience/Width-and-Depth-Subtyping.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-B088E5
-category: "[[10_Wiki/💡 Topics/Design & Experience]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Width-and-Depth-Subtyping"
----
-
-# [[Width-and-Depth-Subtyping]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Design & Experience 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Width-and-Depth-Subtyping.md]]
----
diff --git a/Design & Experience/Zod-Runtime-Validation.md b/Design & Experience/Zod-Runtime-Validation.md
deleted file mode 100644
index 063a2214..00000000
--- a/Design & Experience/Zod-Runtime-Validation.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-869303
-category: "[[10_Wiki/💡 Topics/Design & Experience]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Zod-Runtime-Validation"
----
-
-# [[Zod-Runtime-Validation]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Design & Experience 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Zod-Runtime-Validation.md]]
----
diff --git a/Design & Experience/Zod-Schema-Validation.md b/Design & Experience/Zod-Schema-Validation.md
deleted file mode 100644
index ffbe16b3..00000000
--- a/Design & Experience/Zod-Schema-Validation.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-1B08D2
-category: "[[10_Wiki/💡 Topics/Design & Experience]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Zod-Schema-Validation"
----
-
-# [[Zod-Schema-Validation]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Design & Experience 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Zod-Schema-Validation.md]]
----
diff --git a/Design & Experience/eSports Performance Psychology.md b/Design & Experience/eSports Performance Psychology.md
deleted file mode 100644
index e1c7cad9..00000000
--- a/Design & Experience/eSports Performance Psychology.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-29AB4C
-category: "[[10_Wiki/💡 Topics/Design & Experience]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - eSports Performance Psychology"
----
-
-# [[eSports Performance Psychology]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Design & Experience 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/eSports Performance Psychology.md]]
----
diff --git a/Design & Experience/가상 DOM (Virtual DOM).md b/Design & Experience/가상 DOM (Virtual DOM).md
deleted file mode 100644
index 29f895f4..00000000
--- a/Design & Experience/가상 DOM (Virtual DOM).md	
+++ /dev/null
@@ -1,40 +0,0 @@
----
-id: P-REINFORCE-AUTO-181AC7
-category: "[[10_Wiki/💡 Topics/Design & Experience]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - 가상 DOM (Virtual DOM)"
----
-
-# [[가상 DOM (Virtual DOM)]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 실제 DOM을 매번 직접 조작하는 대신, 메모리 상에 UI의 가상 표현을 구축한 뒤 이전 상태와 비교(Diffing)하여 실제 변경이 필요한 최소한의 부분만 DOM에 반영함으로써 렌더링 성능을 최적화하는 React의 핵심 아키텍처입니다.
-
-## 📖 구조화된 지식 (Synthesized Content)
-**1. 가상 DOM의 작동 원리 (디핑 알고리즘)** React는 렌더링 시 **실제 DOM을 직접 조작하지 않고, UI가 어떻게 보여야 하는지에 대한 가상 트리(Virtual Tree)를 메모리에 구축**합니다. 애플리케이션의 상태가 변경되면 새로운 가상 DOM을 생성하고, 이를 실제 DOM의 복사본 역할을 하는 이전 가상 DOM과 비교합니다. 이 비교 과정을 통해 두 트리 간의 차이점을 찾아내고, **오직 변경이 발생한 노드나 속성만을 실제 DOM에 업데이트**하여 연산 과정을 더 빠르고 효율적으로 만듭니다.
-
-**2. 렌더 단계(Render Phase)와 커밋 단계(Commit Phase)** 가상 DOM을 활용한 업데이트는 명확히 두 단계로 나뉘어 실행됩니다.
-
-- **렌더 단계:** React가 컴포넌트를 호출하여 새로운 가상 트리를 구축하는 과정입니다.
-- **커밋 단계:** 계산된 최소한의 변경 사항들을 실제 DOM에 적용하는 과정입니다.
-
-**3. 실제 DOM 조작 비용의 최소화** 기본적으로 브라우저에서 실제 DOM을 조작하고 레이아웃을 다시 계산하는 작업은 매우 무겁고 비용이 많이 듭니다. 가상 DOM은 이러한 값비싼 DOM 조작 횟수를 최소화하여 성능을 크게 높여줍니다.
-
-**4. 가상 DOM 연산의 한계와 주의점** 가상 DOM이 실제 DOM 조작 비용을 줄여주지만, 가상 DOM을 업데이트하는 연산 자체도 비용이 듭니다. 컴포넌트 트리가 너무 깊게 중첩되어 있거나, 무의미한 상태 변화로 인해 너무 많은 컴포넌트가 불필요하게 리렌더링될 경우 가상 DOM 트리 생성 및 비교 과정에서 성능 병목이 발생할 수 있습니다.
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Design & Experience 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[재조정 (Reconciliation)]], [[React Performance Optimization]], [[불필요한 리렌더링 방지]]
-- **Projects/Contexts:** [[대규모 데이터 렌더링 및 가상화 최적화]], [[고성능 실시간 상호작용 시스템을 위한 React 기반 게임 엔진 아키텍처]]
-- **Contradictions/Notes:** 가상 DOM과 재조정 알고리즘은 일반적인 웹 애플리케이션의 선언적 UI 관리에는 압도적으로 훌륭하지만, 매 프레임 수만 개의 속성이 변해야 하는 3D 게임이나 무거운 애니메이션 환경에서는 오히려 가상 DOM을 비교하는 $O(n)$ 연산 자체가 프레임 저하(Lag)를 유발하는 치명적인 원인이 됩니다. 이러한 특수 환경에서는 가상 DOM을 우회하여 참조(`ref`)를 통한 **명령형 직접 조작(Imperative Manipulation)**을 사용해야만 60FPS를 달성할 수 있습니다.
-
----
-
-_Last updated: 2026-04-15_
-- Raw Source: [[00_Raw/2026-04-20/가상 DOM (Virtual DOM).md]]
----
diff --git a/Design & Experience/계층형 아키텍처 (Layered Architecture).md b/Design & Experience/계층형 아키텍처 (Layered Architecture).md
deleted file mode 100644
index cd0a6b99..00000000
--- a/Design & Experience/계층형 아키텍처 (Layered Architecture).md	
+++ /dev/null
@@ -1,41 +0,0 @@
----
-id: P-REINFORCE-AUTO-28439B
-category: "[[10_Wiki/💡 Topics/Design & Experience]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - 계층형 아키텍처 (Layered Architecture)"
----
-
-# [[계층형 아키텍처 (Layered Architecture)]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 계층형 아키텍처(Layered Architecture), 또는 n-tier 아키텍처는 시스템을 수평적인 계층(Layer)들로 나누어 구성하는 전통적이고 영향력 있는 소프트웨어 설계 패턴입니다 [1, 2]. 각 계층은 특정한 책임을 가지며, 인접한 하위 계층하고만 소통하도록 통신을 제한하여 엄격한 관심사의 분리(Separation of Concerns)를 강제합니다 [2, 3]. 이 아키텍처의 주된 목표는 시스템을 명확히 구조화하여 개발, 테스트, 유지보수성을 단순화하고 모듈성을 향상시키는 것입니다 [2, 4].
-
-## 📖 구조화된 지식 (Synthesized Content)
-- **3계층 구조의 역할 분리:** 가장 보편적인 애플리케이션의 계층 구조는 3가지 영역으로 나뉘어 구현됩니다 [3, 5, 6].
-  - **프레젠테이션 계층 (Presentation Layer):** 사용자 인터페이스(UI)와 사용자 경험(UX) 로직을 전담하며, 데이터를 표시하고 사용자의 입력을 캡처합니다 (예: HTML, CSS, JavaScript 등) [3, 5, 7].
-  - **비즈니스 로직 계층 (Business Logic/Domain Layer):** 애플리케이션의 핵심 비즈니스 규칙과 워크플로우를 처리합니다 [5, 7]. 프레젠테이션 계층의 명령을 처리하고, 데이터 액세스 계층과 상호작용을 조정합니다 [3, 5].
-  - **데이터 액세스 계층 (Data Access/Persistence Layer):** 데이터베이스와 같은 외부 데이터 소스와의 통신(CRUD 작업 등)을 전담하여, 핵심 비즈니스 로직을 데이터 저장의 구체적 구현 방식으로부터 격리시킵니다 [3, 5, 7].
-  
-- **구현 원칙 및 모범 사례:** 
-  - **엄격한 계층 통신 강제:** 한 계층은 바로 아래에 위치한 인접 계층하고만 통신해야 합니다 [3, 8]. 예를 들어 프레젠테이션 계층이 데이터 액세스 계층을 직접 호출하지 못하게 차단하여 강한 결합(Tight coupling)을 예방합니다 [8].
-  - **의존성 주입(DI) 활용:** 계층 간의 의존성을 직접 생성하지 않고 외부에서 주입받도록 하여 느슨한 결합(Loose coupling)과 향상된 테스트 용이성을 촉진합니다 [8, 9].
-  - **명확한 인터페이스 정의:** 각 계층 사이에 잘 정의된 인터페이스를 생성하여, 상위 계층에 영향을 주지 않고 하위 계층의 구현(예: 데이터베이스 종류 변경 등)을 유연하게 교체할 수 있도록 해야 합니다 [8].
-
-- **장점 및 적용 사례:** 
-  이 패턴은 구조가 잘 알려져 있어 구현 복잡도가 비교적 낮으며, 전통적인 엔터프라이즈 애플리케이션이나 3-Tier 시스템 구축에 이상적입니다 [9]. 각 책임을 독립적인 계층으로 격리시키기 때문에 모듈성과 재사용성이 높아지며, 특정 계층의 변화가 다른 계층에 미치는 파급 효과를 차단하여 결과적으로 각 계층별 독립적인 테스트와 유지보수가 매우 쉬워집니다 [2, 9, 10].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Design & Experience 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[관심사의 분리 (Separation of Concerns)]], [[N-Tier 아키텍처 (N-Tier Architecture)]], [[의존성 주입 (Dependency Injection)]], [[단일 책임 원칙 (SRP)]]
-- **Projects/Contexts:** [[엔터프라이즈 애플리케이션]], [[웹 애플리케이션 3계층 시스템 (3-Tier Systems)]]
-- **Contradictions/Notes:** 소스에 따르면, 계층형 아키텍처는 명확한 분리를 제공해 주지만 레이어를 무겁게 만들면 오히려 시스템 관리가 비효율적일 수 있으므로, 계층을 얇게 유지(Keep layers thin)하고 인터페이스와 의존성 주입을 적극 활용하여 경계를 명확히 보호할 것을 권장하고 있습니다 [8, 9].
-
----
-*Last updated: 2026-04-18*
-- Raw Source: [[00_Raw/2026-04-20/계층형 아키텍처 (Layered Architecture).md]]
----
diff --git a/Design & Experience/고성능 실시간 상호작용 시스템을 위한 React 기반 게임 엔진 아키텍처.md b/Design & Experience/고성능 실시간 상호작용 시스템을 위한 React 기반 게임 엔진 아키텍처.md
deleted file mode 100644
index df8384c4..00000000
--- a/Design & Experience/고성능 실시간 상호작용 시스템을 위한 React 기반 게임 엔진 아키텍처.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-416C0F
-category: "[[10_Wiki/💡 Topics/Design & Experience]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - 고성능 실시간 상호작용 시스템을 위한 React 기반 게임 엔진 아키텍처"
----
-
-# [[고성능 실시간 상호작용 시스템을 위한 React 기반 게임 엔진 아키텍처]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Design & Experience 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/고성능 실시간 상호작용 시스템을 위한 React 기반 게임 엔진 아키텍처.md]]
----
diff --git a/Design & Experience/교육 심리학에서의 보상 설계.md b/Design & Experience/교육 심리학에서의 보상 설계.md
deleted file mode 100644
index a2234e31..00000000
--- a/Design & Experience/교육 심리학에서의 보상 설계.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-DD5110
-category: "[[10_Wiki/💡 Topics/Design & Experience]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - 교육 심리학에서의 보상 설계"
----
-
-# [[교육 심리학에서의 보상 설계]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Design & Experience 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/교육 심리학에서의 보상 설계.md]]
----
diff --git a/Design & Experience/교육학의 모델링 전략.md b/Design & Experience/교육학의 모델링 전략.md
deleted file mode 100644
index 24593bf4..00000000
--- a/Design & Experience/교육학의 모델링 전략.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-8413FB
-category: "[[10_Wiki/💡 Topics/Design & Experience]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - 교육학의 모델링 전략"
----
-
-# [[교육학의 모델링 전략]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Design & Experience 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/교육학의 모델링 전략.md]]
----
diff --git a/Design & Experience/뇌과학 기반 중독 재활 프로그램.md b/Design & Experience/뇌과학 기반 중독 재활 프로그램.md
deleted file mode 100644
index 1d5927dc..00000000
--- a/Design & Experience/뇌과학 기반 중독 재활 프로그램.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-563E3F
-category: "[[10_Wiki/💡 Topics/Design & Experience]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - 뇌과학 기반 중독 재활 프로그램"
----
-
-# [[뇌과학 기반 중독 재활 프로그램]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Design & Experience 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/뇌과학 기반 중독 재활 프로그램.md]]
----
diff --git a/Design & Experience/대규모 프론트엔드 웹 프로젝트 폴더 구조화.md b/Design & Experience/대규모 프론트엔드 웹 프로젝트 폴더 구조화.md
deleted file mode 100644
index c97f6368..00000000
--- a/Design & Experience/대규모 프론트엔드 웹 프로젝트 폴더 구조화.md	
+++ /dev/null
@@ -1,43 +0,0 @@
----
-id: P-REINFORCE-AUTO-71F406
-category: "[[10_Wiki/💡 Topics/Design & Experience]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - 대규모 프론트엔드 웹 프로젝트 폴더 구조화"
----
-
-# [[대규모 프론트엔드 웹 프로젝트 폴더 구조화]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 대규모 프론트엔드 웹 프로젝트의 폴더 구조화는 프로젝트의 규모와 복잡성이 증가함에 따라 관심사를 효과적으로 분리하여 유지보수성과 확장성을 높이는 설계 과정이다 [1, 2]. 초기에는 개발의 속도를 높일 수 있는 역할 중심의 폴더 구조가 주로 사용되지만, 프로젝트가 성장함에 따라 관련 파일을 하나의 단위로 묶어 관리하는 기능 중심의 구조(예: Feature-Sliced Design 아키텍처)로 진화하게 된다 [1, 3, 4]. 이는 데이터와 화면 간의 의존성을 줄이고 컴포넌트 및 기능의 결합도를 낮추어 코드 관리를 용이하게 하기 위한 필수적인 원칙이다 [5, 6].
-
-## 📖 구조화된 지식 (Synthesized Content)
-*   **역할 중심 폴더 구조와 한계:**
-    현대의 프론트엔드 프로젝트는 주로 `/api`(백엔드 통신), `/components`(공통 컴포넌트), `/hooks`, `/pages`(라우팅), `/store`(상태 관리), `/utils` 등 세부적인 역할을 기준으로 폴더를 분리하는 방식을 사용한다 [7, 8]. 이 방식은 규모가 작을 때는 매우 효율적이지만, 대규모 프로젝트가 될 경우 특정 관심사(기능)를 찾아 수정할 때 관련 파일들이 여러 역할 폴더에 흩어져(파편화) 파악이 어려워지고, 불필요한 코드까지 건드리게 되는 등 유지보수와 기능 확장의 명확한 한계를 맞이하게 된다 [3, 4, 9].
-
-*   **프로젝트 진화에 따른 폴더 구조의 변화:**
-    프로젝트의 성장에 따라 관심사의 방향이 달라지므로 폴더 구조 또한 지속적으로 진화해야 한다 [4, 10].
-    *   **초기 단계:** 화면 구현에 초점을 맞추어 페이지(route)별로 화면을 나누고, 공통 컴포넌트는 `/shared` 등에 보관하는 형태가 적합하다 [2].
-    *   **성장기:** 공통 로직을 제외하고, 각 페이지별로 독립적인 상태 관리와 API 호출을 묶어 페이지 폴더 안에 포함시킴으로써 책임 범위를 명확히 하는 방식이 효율적이다 [2, 6].
-    *   **릴리즈 막바지 및 유지보수 시기:** 데이터 처리와 비즈니스 로직 중심의 대화가 주를 이루기 시작한다 [6]. 이때 화면을 그리는 뷰(View) 컴포넌트와 데이터를 다루는 도메인 컴포넌트를 명확히 분리해야 하며, 신규 기능의 추가나 삭제 시 커밋 범위를 제한하기 위해 코드를 **기능(Feature) 단위**로 모아 관리해야 한다 [4, 6, 9].
-
-*   **기능 중심 아키텍처 (Feature-Sliced Design, FSD) 도입:**
-    대규모 프로젝트에서 발생하는 기능 간 결합도 상승 및 관리의 어려움을 근본적으로 해결하기 위해 기능(Feature)을 기준으로 코드를 분리하는 FSD 아키텍처가 대두되었다 [1, 5]. 하나의 기능과 관련된 모든 파일을 같은 폴더에 묶어 독립적으로 관리하도록 설계함으로써 복잡성을 줄이고, 여러 개발자가 협업할 때 필요한 멘탈 모델을 일치시켜 확장성을 크게 향상시킨다 [1, 5, 11].
-
-*   **마이크로 프론트엔드 (Micro Frontends) 활용:**
-    수백 개의 화면과 다양한 기능이 혼재된 아주 거대한 규모의 경우, 모놀리식 프론트엔드를 분해하여 마이크로 프론트엔드 아키텍처를 채택하기도 한다 [12-14]. 이 접근 방식은 장바구니, 상품 목록 등의 비즈니스 기능 단위를 별도의 개발 팀이 소유하게 하여, 프레임워크나 기술 스택에 구애받지 않고 독립적인 개발, 테스트, 배포가 가능하게 함으로써 팀의 자율성과 유지보수성을 극대화한다 [13, 15].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Design & Experience 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[관심사의 분리 (Separation of Concerns)]], [[Feature-Sliced Design (FSD)]], [[마이크로 프론트엔드 (Micro Frontends)]]
-- **Projects/Contexts:** [[항해 DEV LAB 미니 학술회]] (FSD와 프론트엔드 관심사 분리에 관한 시각과 발표 내용이 논의된 맥락 [16]), [[스포티파이 (Spotify)]] (자율적인 기능 단위 '스쿼드' 모델과 프론트엔드를 분리하는 마이크로 프론트엔드를 결합하여 대규모 웹 앱 개발의 확장성을 획기적으로 개선한 실제 기업 사례 [17, 18])
-- **Contradictions/Notes:** 소스에 따르면 폴더 구조 설계에 있어서 절대적으로 "이것이 정답"이라고 할 수 있는 완벽한 구조는 존재하지 않는다. 프로젝트의 특성과 규모, 팀의 요구사항, 그리고 시기에 따라 기능 중심, 역할 중심, 혹은 도메인 중심 등으로 유연하게 폴더 구조를 진화시키고 균형을 맞추는 것이 핵심이라고 조언한다 [11, 19].
-
----
-*Last updated: 2026-04-18*
-- Raw Source: [[00_Raw/2026-04-20/대규모 프론트엔드 웹 프로젝트 폴더 구조화.md]]
----
diff --git a/Design & Experience/데이터 지향 설계 (Data-Oriented Design).md b/Design & Experience/데이터 지향 설계 (Data-Oriented Design).md
deleted file mode 100644
index 801de48b..00000000
--- a/Design & Experience/데이터 지향 설계 (Data-Oriented Design).md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-D9E964
-category: "[[10_Wiki/💡 Topics/Design & Experience]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - 데이터 지향 설계 (Data-Oriented Design)"
----
-
-# [[데이터 지향 설계 (Data-Oriented Design)]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Design & Experience 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/데이터 지향 설계 (Data-Oriented Design).md]]
----
diff --git a/Design & Experience/도메인 주도 설계 (DDD).md b/Design & Experience/도메인 주도 설계 (DDD).md
deleted file mode 100644
index dcb307f5..00000000
--- a/Design & Experience/도메인 주도 설계 (DDD).md	
+++ /dev/null
@@ -1,34 +0,0 @@
----
-id: P-REINFORCE-AUTO-ADBB0E
-category: "[[10_Wiki/💡 Topics/Design & Experience]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - 도메인 주도 설계 (DDD)"
----
-
-# [[도메인 주도 설계 (DDD)]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 도메인 주도 설계(DDD)는 비즈니스 도메인에 대한 깊은 이해를 중심으로 소프트웨어 개발 프로세스를 진행하는 설계 접근법입니다 [1]. 이 방식은 핵심 비즈니스 로직(뇌)을 데이터베이스나 UI 프레임워크와 같은 인프라스트럭처 관심사(팔다리)로부터 철저히 격리하여 깨끗하고 테스트 가능한 도메인 모델을 구축하는 것을 목표로 합니다 [2]. 결과적으로 DDD는 전통적인 기술 중심의 계층화를 넘어 '비즈니스 역량 중심'의 수직적 분리로 관심사의 분리(SoC) 원칙의 지평을 크게 넓혔습니다 [3].
-
-## 📖 구조화된 지식 (Synthesized Content)
-- **도메인 로직의 격리 (뇌와 팔다리의 분리):** DDD는 시스템의 핵심 비즈니스 로직을 인프라스트럭처나 사용자 인터페이스(UI) 프레임워크와 같은 외부 요소와 분리할 것을 강조합니다 [2]. 이는 시스템의 본질적인 정책(뇌)과 외부 세계를 구현하는 세부 사항(팔다리)을 격리하는 관심사의 분리 원칙을 직접적으로 실천하는 것이며, 이를 통해 순수하고 유지보수하기 쉬운 도메인 모델을 생성할 수 있습니다 [2].
-- **바운디드 컨텍스트 (Bounded Contexts)를 통한 수직적 분리:** 대규모의 복잡한 도메인은 관리하기 쉬운 하위 도메인인 '바운디드 컨텍스트' 단위로 쪼개집니다 [4]. 각 컨텍스트는 독립적인 모델과 언어를 가지며, 이는 기능들을 비즈니스 영역에 따라 독립적인 모듈로 수직 분리하여 한 모듈의 변경이 다른 모듈에 미치는 영향을 차단합니다 [3].
-- **유비쿼터스 언어 (Ubiquitous Language):** 개발팀과 도메인 전문가(비즈니스 이해관계자) 간의 의사소통 간극을 메우기 위해, 프로젝트 전반(대화, 문서, 실제 코드)에서 공통으로 사용되는 '유비쿼터스 언어'를 정의하고 사용합니다 [1, 2].
-- **주요 도메인 모델링 패턴:** 비즈니스 도메인을 모델링하기 위해 뚜렷한 정체성을 가지는 '엔티티(Entities)', 속성으로만 정의되는 '값 객체(Value Objects)', 그리고 데이터의 일관성을 유지하기 위해 단일 단위로 취급되는 도메인 객체들의 군집인 '애그리거트(Aggregates)' 등의 패턴을 사용합니다 [4].
-- **마이크로서비스 아키텍처(MSA)의 논리적 기반:** DDD의 바운디드 컨텍스트 개념은 비즈니스 역량 중심의 분리를 가능하게 함으로써, 오늘날의 마이크로서비스 아키텍처(MSA)를 구축하고 분산 시스템을 설계하는 논리적인 기반이 됩니다 [3].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Design & Experience 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[바운디드 컨텍스트 (Bounded Context)]], [[유비쿼터스 언어 (Ubiquitous Language)]], [[관심사의 분리 (Separation of Concerns)]], [[애그리거트 (Aggregates)]]
-- **Projects/Contexts:** [[마이크로서비스 아키텍처 (MSA)]], [[복잡한 비즈니스 도메인 (금융, 헬스케어, 이커머스 등)]]
-- **Contradictions/Notes:** 소스 내용 간의 모순점은 발견되지 않았습니다. 다만, 도메인 주도 설계(DDD)는 비즈니스와 강하게 결합된 명확한 모델을 도출하는 데 큰 장점이 있지만, 도메인 전문가와의 긴밀한 협업과 깊은 모델링 분석 시간이 필요하여 구현 복잡도와 리소스 요구량이 높다는 특징이 있습니다 [5].
-
----
-*Last updated: 2026-04-18*
-- Raw Source: [[00_Raw/2026-04-20/도메인 주도 설계 (DDD).md]]
----
diff --git a/Design & Experience/도메인 주도 설계(DDD).md b/Design & Experience/도메인 주도 설계(DDD).md
deleted file mode 100644
index 52becd14..00000000
--- a/Design & Experience/도메인 주도 설계(DDD).md	
+++ /dev/null
@@ -1,36 +0,0 @@
----
-id: P-REINFORCE-AUTO-4DC206
-category: "[[10_Wiki/💡 Topics/Design & Experience]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - 도메인 주도 설계(DDD)"
----
-
-# [[도메인 주도 설계(DDD)]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 도메인 주도 설계(DDD)는 비즈니스 도메인에 대한 깊은 이해를 중심으로 소프트웨어 개발 프로세스를 구성하는 설계 방식입니다 [1]. 이 접근법은 복잡한 비즈니스 로직을 애플리케이션의 핵심에 두고, 개발팀과 비즈니스 이해관계자 간의 긴밀한 협력을 통해 현실 세계의 비즈니스 프로세스를 정확히 반영하는 모델을 생성합니다 [1]. 결과적으로 DDD는 기술 중심의 분리에서 벗어나 비즈니스 역량 중심의 관심사 분리를 가능하게 합니다 [2].
-
-## 📖 구조화된 지식 (Synthesized Content)
-*   **핵심 원칙 및 목표**: DDD의 주요 목표는 프로젝트의 모든 참여자가 사용하는 공통 어휘인 '보편적 언어(Ubiquitous Language)'를 구축하여 개발자와 비즈니스 이해관계자 간의 의사소통 격차를 해소하고 복잡성을 관리하는 것입니다 [1]. 또한, 핵심 비즈니스 로직을 데이터베이스나 UI 프레임워크와 같은 외부 인프라로부터 철저히 분리하고 보호하여 유지보수성과 테스트 가능성을 높이는 데 중점을 둡니다 [3, 4].
-*   **주요 패턴 및 요소**:
-    *   **제한된 문맥(Bounded Contexts)**: 크고 복잡한 도메인을 관리하기 쉬운 하위 도메인(예: '주문 관리', '고객 지원')으로 나눕니다. 각 문맥은 고유한 모델과 보편적 언어를 가지며 [5], 이는 마이크로서비스 아키텍처(MSA)를 위한 논리적 기반을 제공하여 모듈 간의 부작용(Side Effects)을 차단합니다 [2].
-    *   **애그리게이트(Aggregates)**: 단일 단위로 취급할 수 있는 도메인 객체들의 군집입니다. 애그리게이트의 루트(root)는 전체 군집의 일관성을 보장하고 트랜잭션 관리를 단순화합니다 [5].
-    *   **엔티티(Entities)와 값 객체(Value Objects)**: 명확한 식별성을 지닌 객체는 '엔티티'(예: 고객)로 정의하고, 고유 식별성 없이 속성만으로 정의되는 객체는 '값 객체'(예: 배송지 주소)로 구분하여 모델링합니다 [5].
-*   **실천 전략**: DDD를 효과적으로 구현하기 위해서는 도메인 전문가와의 협업을 통해 공유 언어 사전을 개발 및 유지해야 합니다 [3]. 또한, 비즈니스 도메인을 탐색하고 도메인 이벤트, 명령, 애그리게이트를 신속하게 식별하기 위해 '이벤트 스토밍(Event Storming)'과 같은 협업 워크숍을 활용하는 것이 권장됩니다 [3].
-*   **적용 환경 및 특징**: 금융, 의료, 이커머스와 같이 비즈니스 도메인이 복잡한 시스템에 이상적입니다 [6]. 비즈니스와의 강력한 정렬을 제공하지만, 깊은 도메인 모델링과 도메인 전문가의 분석 시간 등이 요구되어 구현 복잡도와 리소스 요구 사항이 높은 편입니다 [6].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Design & Experience 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[보편적 언어(Ubiquitous Language)]], [[제한된 문맥(Bounded Contexts)]], [[마이크로서비스 아키텍처(MSA)]], [[관심사의 분리(SoC)]]
-- **Projects/Contexts:** [[이벤트 스토밍(Event Storming)]], [[복잡한 비즈니스 도메인(금융, 의료, 이커머스 등)]]
-- **Contradictions/Notes:** 도메인 주도 설계는 비즈니스 도메인을 명확하게 반영하고 강력한 기반을 제공하지만, 깊은 수준의 모델링과 조직적 협력이 필요하므로 구현 복잡성이 높고 상당한 리소스(도메인 전문가, 분석 시간 등)가 요구된다는 제약이 있습니다 [6].
-
----
-*Last updated: 2026-04-18*
-- Raw Source: [[00_Raw/2026-04-20/도메인 주도 설계(DDD).md]]
----
diff --git a/Design & Experience/도파민 보상 체계.md b/Design & Experience/도파민 보상 체계.md
deleted file mode 100644
index 342e0042..00000000
--- a/Design & Experience/도파민 보상 체계.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-19D38E
-category: "[[10_Wiki/💡 Topics/Design & Experience]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - 도파민 보상 체계"
----
-
-# [[도파민 보상 체계]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Design & Experience 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/도파민 보상 체계.md]]
----
diff --git a/Design & Experience/라이브러리 타입 선언 (dts) 확장.md b/Design & Experience/라이브러리 타입 선언 (dts) 확장.md
deleted file mode 100644
index e5bbd9e5..00000000
--- a/Design & Experience/라이브러리 타입 선언 (dts) 확장.md	
+++ /dev/null
@@ -1,37 +0,0 @@
----
-id: P-REINFORCE-AUTO-73EE30
-category: "[[10_Wiki/💡 Topics/Design & Experience]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - 라이브러리 타입 선언 (dts) 확장"
----
-
-# [[라이브러리 타입 선언 (dts) 확장]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 라이브러리 타입 선언(.d.ts) 확장은 타입스크립트 환경에서 외부 자바스크립트 라이브러리의 타입 정보를 제공, 패치(patch) 또는 연장하기 위해 수행하는 작업입니다 [1-3]. 주로 인터페이스(Interface)의 '선언 병합(Declaration Merging)' 기능을 활용하여, 기존 라이브러리 코드의 수정 없이 소비자가 필요한 타입 선언을 유연하게 추가할 수 있도록 지원합니다 [2, 4, 5].
-
-## 📖 구조화된 지식 (Synthesized Content)
-* **d.ts 파일의 목적과 활용**
-  타입스크립트에서 자바스크립트 라이브러리를 사용할 때는 실제 구현부 없이 타입 정보만 제공하는 선언 파일(.d.ts)이 필요합니다 [3]. 많은 인기 라이브러리는 자체적으로 타입을 제공하거나 `DefinitelyTyped`를 통해 설치할 수 있습니다 [3]. 만약 라이브러리에 타입이 존재하지 않는다면, 개발자가 직접 모듈을 선언하여 컴파일 에러를 억제할 수 있습니다 [3, 6].
-* **선언 병합(Declaration Merging)을 이용한 타입 패치**
-  라이브러리의 타입 선언을 확장하거나 패치하는 데에는 '인터페이스(Interface)'가 핵심적으로 사용됩니다 [1, 2]. 타입스크립트는 동일한 이름의 인터페이스가 여러 번 선언될 경우 이를 하나의 인터페이스로 자동 병합하는 기능을 갖추고 있습니다 [4, 5]. 
-* **라이브러리 확장 지점(Extension Point) 제공**
-  인터페이스의 병합 특성은 라이브러리 제작자가 패키지 사용자(소비자)에게 유용한 타입 확장 지점을 제공할 때 매우 효과적입니다 [2, 5]. 반면 타입 별칭(Type Alias)은 동일한 이름으로 재선언 및 병합이 불가능하므로, 라이브러리 수준의 타입 패치나 확장 용도로는 인터페이스가 권장됩니다 [5, 7].
-
-*(참고: 구체적인 글로벌(Global) 환경에서의 모듈 수정 템플릿이나, d.ts 파일을 직접 생성하고 퍼블리싱하는 상세한 코드 작성 문법에 대해서는 소스에 관련 정보가 부족합니다 [8].)*
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Design & Experience 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[인터페이스(Interface)]], [[선언 병합(Declaration Merging)]], [[타입 별칭(Type Alias)]]
-- **Projects/Contexts:** [[TypeScript 라이브러리 생태계 및 DefinitelyTyped]]
-- **Contradictions/Notes:** 소스에 따르면, 일반적인 애플리케이션 코드 작성 시에는 엄격한 관리가 가능한 타입 별칭(Type)을 선호하는 실무 의견이 많지만, 외부 라이브러리 사용자가 타입을 확장해야 하는 특수한 상황에서는 선언 병합이 가능한 인터페이스(Interface)가 절대적으로 더 적합하다는 뚜렷한 용도 차이를 보입니다 [1, 2, 5, 7].
-
----
-*Last updated: 2026-04-18*
-- Raw Source: [[00_Raw/2026-04-20/라이브러리 타입 선언 (d.ts) 확장.md]]
----
diff --git a/Design & Experience/마이크로 프론트엔드 (Micro Frontends).md b/Design & Experience/마이크로 프론트엔드 (Micro Frontends).md
deleted file mode 100644
index 20e3c23d..00000000
--- a/Design & Experience/마이크로 프론트엔드 (Micro Frontends).md	
+++ /dev/null
@@ -1,30 +0,0 @@
----
-id: P-REINFORCE-AUTO-039AAE
-category: "[[10_Wiki/💡 Topics/Design & Experience]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - 마이크로 프론트엔드 (Micro Frontends)"
----
-
-# [[마이크로 프론트엔드 (Micro Frontends)]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 마이크로 프론트엔드(Micro Frontends)는 백엔드의 마이크로서비스 아키텍처와 유사하게, 방대하고 복잡한 프론트엔드 애플리케이션을 작고 독립적인 여러 모듈로 나누어 개발하는 접근 방식이다 [1]. 이 아키텍처는 비즈니스 기능에 따라 프론트엔드를 분할하여, 각 부분을 전담 팀이 독립적으로 개발, 테스트, 배포할 수 있도록 지원한다 [1]. 기존 모놀리식 구조의 한계를 극복하여 팀의 자율성, 확장성, 유지보수성을 크게 향상시키는 현대 웹 개발의 솔루션이다 [1-3].
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Design & Experience 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[마이크로서비스 아키텍처 (Microservices Architecture)]], [[모놀리식 아키텍처 (Monolithic Architecture)]], [[관심사의 분리 (Separation of Concerns)]], [[웹 컴포넌트 (Web Components)]], [[모듈 페더레이션 (Module federation)]]
-- **Projects/Contexts:** [[Spotify의 마이크로 프론트엔드 도입 (스쿼드 모델)]], [[Netflix의 레거시 현대화 및 대시보드]], [[Zalando의 이커머스 모듈 분리]], [[IKEA와 Amazon의 독립적 UX 커스터마이징]]
-- **Contradictions/Notes:** 소스에 따르면 마이크로 프론트엔드는 팀의 자율성과 시스템의 유지보수성을 비약적으로 높여주지만, 동시에 여러 마이크로 프론트엔드 번들이 로드되면서 초기 로딩 성능에 오버헤드(Performance Overhead)가 발생하고, 스타일이나 버전 충돌 등 새로운 복잡성이 추가될 수 있다는 단점(과제)을 명확히 동반한다 [5, 9]. 따라서 소규모 프로젝트나 적절한 DevOps 기반이 없는 환경에서는 오버헤드가 장점을 상쇄하므로 피해야 한다고 경고한다 [11].
-
----
-*Last updated: 2026-04-18*
-- Raw Source: [[00_Raw/2026-04-20/마이크로 프론트엔드 (Micro Frontends).md]]
----
diff --git a/Design & Experience/맞춤형 개별화 학습 설계.md b/Design & Experience/맞춤형 개별화 학습 설계.md
deleted file mode 100644
index 16456e84..00000000
--- a/Design & Experience/맞춤형 개별화 학습 설계.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-6B106E
-category: "[[10_Wiki/💡 Topics/Design & Experience]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - 맞춤형 개별화 학습 설계"
----
-
-# [[맞춤형 개별화 학습 설계]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Design & Experience 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/맞춤형 개별화 학습 설계.md]]
----
diff --git a/Design & Experience/모바일 앱 및 웹 인터페이스 설계.md b/Design & Experience/모바일 앱 및 웹 인터페이스 설계.md
deleted file mode 100644
index 7f6ed961..00000000
--- a/Design & Experience/모바일 앱 및 웹 인터페이스 설계.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-B1EC47
-category: "[[10_Wiki/💡 Topics/Design & Experience]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - 모바일 앱 및 웹 인터페이스 설계"
----
-
-# [[모바일 앱 및 웹 인터페이스 설계]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Design & Experience 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/모바일 앱 및 웹 인터페이스 설계.md]]
----
diff --git a/Design & Experience/몰입감 (Presence).md b/Design & Experience/몰입감 (Presence).md
deleted file mode 100644
index e552e2b2..00000000
--- a/Design & Experience/몰입감 (Presence).md	
+++ /dev/null
@@ -1,40 +0,0 @@
----
-id: P-REINFORCE-AUTO-589F08
-category: "[[10_Wiki/💡 Topics/Design & Experience]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - 몰입감 (Presence)"
----
-
-# [[몰입감 (Presence)]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 몰입감(Presence)은 사용자가 가상 현실이나 전자 환경을 현실 세계보다 우선적으로 수용하여, 비물리적 세계에 실제로 "존재하는 것(being there)"처럼 느끼는 심리적 상태를 의미합니다 [1, 2]. 이는 가상현실(VR) 및 혼합현실(MR) 경험의 성공을 결정짓는 핵심 요소로, 사용자의 참여도, 몰입(Immersion), 그리고 학습 성과를 향상시킵니다 [3, 4]. 그러나 고도의 몰입감을 유지하는 것은 인지 부하(Cognitive Load)를 증가시킬 수 있으며, 사이버 멀미(VR sickness)와 같은 요인에 의해 쉽게 파괴될 수 있습니다 [3, 5].
-
-## 📖 구조화된 지식 (Synthesized Content)
-- **몰입감의 정의와 3대 환상(Illusions):** 
-  몰입감(Presence)은 가상의 현실을 실제 현실처럼 일시적으로 수용하는 감각을 뜻합니다 [1]. 학자 Slater(2009)에 따르면, 가상 환경에서의 몰입감은 크게 세 가지로 구성됩니다. 첫째는 묘사된 장소에 있는 것처럼 느끼는 '장소의 환상(Place illusion)'이고, 둘째는 가상의 사건이 실제로 일어나고 있다고 믿는 '그럴듯함의 환상(Plausibility illusion)'이며, 셋째는 가상 신체에 대한 '소유권의 환상(Illusion of ownership)'입니다 [6].
-
-- **유사 개념(Immersion 및 Engagement)과의 관계:** 
-  몰입감(Presence)이 가상 세계에 "존재한다"는 감각에 초점을 맞춘다면, 'Immersion(몰입)'은 사용자가 가상 환경에 얼마나 깊이 관여(involvement)되어 있는지를 나타내는 지표로 자주 혼용됩니다 [1]. 반면 'Engagement(참여)'는 내러티브나 시청각적 자극보다는 주로 실제 게임플레이와 상호작용을 통해 발생하는 깊은 개입을 뜻합니다 [7].
-
-- **학습 성과 및 플로우(Flow)와의 연결:** 
-  가상현실과 같은 몰입형 환경에서 몰입감은 사용자 경험을 성공으로 이끄는 초석입니다. 다른 화면 기반의 활동들에 비해 더 뛰어난 과업 수행 능력과 강력한 생리적 반응을 유도합니다 [4]. 이러한 상태는 긍정적인 감정과 강렬한 집중을 수반하는 '플로우(Flow State)' 경험으로 이어져 학습자의 지식 습득과 참여를 효과적으로 촉진합니다 [8, 9].
-
-- **인지 부하 및 몰입감 저해 요인:** 
-  가상 환경에서 높은 실재감을 느끼는 것은 사용자의 정보 처리 과정을 수반하므로, 몰입감이 높아질수록 인지 부하(Cognitive Load) 역시 함께 증가하는 경향을 보입니다 [3, 10]. 더욱이, 시각적-전정 감각의 불일치로 인해 발생하는 사이버 멀미(VR sickness)나 인터페이스의 마찰(Friction) 등은 사용자의 경험을 방해하고 형성된 몰입감을 크게 저하시키거나 파괴할 수 있습니다 [5].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Design & Experience 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[Flow State]], [[Cognitive Load]], [[Immersion]], [[Virtual Reality (VR)]]
-- **Projects/Contexts:** [[Mixed Reality (MR) Tasks]], [[VR Exergaming]]
-- **Contradictions/Notes:** 소스에 따르면 높은 수준의 가상 몰입감(Virtual Presence)은 학습 성과와 참여도를 긍정적으로 향상시키지만, 가상 콘텐츠를 처리하기 위한 정신적 노력이 요구되어 필연적으로 인지 부하(Cognitive Load)를 증가시킨다는 이중적 특성을 지닙니다 [3, 10].
-
----
-*Last updated: 2026-04-19*
-- Raw Source: [[00_Raw/2026-04-20/몰입감 (Presence).md]]
----
diff --git a/Design & Experience/바운디드 컨텍스트 (Bounded Context).md b/Design & Experience/바운디드 컨텍스트 (Bounded Context).md
deleted file mode 100644
index 84ea82f6..00000000
--- a/Design & Experience/바운디드 컨텍스트 (Bounded Context).md	
+++ /dev/null
@@ -1,33 +0,0 @@
----
-id: P-REINFORCE-AUTO-7B2713
-category: "[[10_Wiki/💡 Topics/Design & Experience]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - 바운디드 컨텍스트 (Bounded Context)"
----
-
-# [[바운디드 컨텍스트 (Bounded Context)]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 바운디드 컨텍스트(Bounded Context)는 도메인 주도 설계(DDD)에서 크고 복잡한 비즈니스 도메인을 더 작고 관리하기 쉬운 하위 도메인으로 분할한 단위를 의미합니다 [1, 2]. 각 컨텍스트는 고유한 소프트웨어 모델과 보편적 언어(Ubiquitous Language)를 가지며, 도메인의 논리를 캡슐화하여 서로 다른 책임 영역 간의 명확한 경계를 정의합니다 [1, 3]. 이를 통해 소프트웨어 모델을 순수하고 기능에 집중된 상태로 유지하며, 시스템의 복잡성을 효과적으로 관리할 수 있게 돕습니다 [1, 3].
-
-## 📖 구조화된 지식 (Synthesized Content)
-* **도메인 분할과 경계 설정**: 바운디드 컨텍스트는 비즈니스 도메인에 대한 깊은 이해를 바탕으로 아키텍처를 설계하는 도메인 주도 설계(DDD)의 핵심 접근법입니다 [1, 4]. 거대하고 복잡한 도메인을 '주문 관리(Order Management)'나 '고객 지원(Customer Support)'과 같이 관리하기 용이한 바운디드 컨텍스트 단위로 나눕니다 [1].
-* **독립적인 모델과 보편적 언어 보장**: 분할된 각 바운디드 컨텍스트는 자신만의 독립적인 모델과 보편적 언어(Ubiquitous Language)를 갖습니다 [1, 2]. 이는 개발 팀과 비즈니스 전문가 간의 공통된 어휘를 제공하여 커뮤니케이션의 간극을 좁히고, 해당 컨텍스트 내의 모델이 다른 영역의 간섭 없이 순수성을 유지할 수 있도록 만듭니다 [1, 4].
-* **관심사의 분리(SoC) 실현**: 바운디드 컨텍스트는 시스템 설계 수준에서 관심사의 분리(Separation of Concerns)를 구현하는 방법입니다 [3, 5]. 핵심 도메인의 논리를 식별하고 이를 바운디드 컨텍스트로 캡슐화함으로써, 책임 영역 간의 명확한 경계를 설정하여 유지보수성을 높이고 코드를 모듈화합니다 [3].
-* **마이크로서비스 아키텍처(MSA)의 논리적 기반**: 복잡한 시스템에서 바운디드 컨텍스트는 마이크로서비스 아키텍처를 설계하는 논리적인 토대가 됩니다 [2]. 사용자 관리, 상품 관리, 주문 관리 등의 기능을 독립적인 모듈로 분리하여 각 영역이 독립적인 모델과 언어를 갖게 함으로써, 한 모듈의 변경이 다른 모듈에 미치는 파급 효과를 효과적으로 차단할 수 있습니다 [2].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Design & Experience 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[도메인 주도 설계 (Domain-Driven Design, DDD)]], [[보편적 언어 (Ubiquitous Language)]], [[마이크로서비스 아키텍처 (Microservices Architecture)]], [[관심사의 분리 (Separation of Concerns, SoC)]]
-- **Projects/Contexts:** 복잡한 비즈니스 도메인 모델링 [1], 객체 지향 및 모듈러 소프트웨어 시스템 설계 [3, 5], 마이크로서비스로의 서비스 분리 및 마이그레이션 [2]
-- **Contradictions/Notes:** 소스 내에 바운디드 컨텍스트의 효용이나 개념에 대한 상반된 주장은 존재하지 않으며, 일관되게 시스템 복잡성 완화와 마이크로서비스 확장을 위한 핵심 기반으로 설명되고 있습니다.
-
----
-*Last updated: 2026-04-18*
-- Raw Source: [[00_Raw/2026-04-20/바운디드 컨텍스트 (Bounded Context).md]]
----
diff --git a/Design & Experience/반응형 윈도우 리사이즈(Resize) 이벤트 처리.md b/Design & Experience/반응형 윈도우 리사이즈(Resize) 이벤트 처리.md
deleted file mode 100644
index 8a5f4d8a..00000000
--- a/Design & Experience/반응형 윈도우 리사이즈(Resize) 이벤트 처리.md	
+++ /dev/null
@@ -1,40 +0,0 @@
----
-id: P-REINFORCE-AUTO-DC2EFA
-category: "[[10_Wiki/💡 Topics/Design & Experience]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - 반응형 윈도우 리사이즈(Resize) 이벤트 처리"
----
-
-# [[반응형 윈도우 리사이즈(Resize) 이벤트 처리]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 윈도우 창 크기 조절 시 초당 수십 번씩 발생하는 `resize` 이벤트로 인한 UI 렌더링 병목 현상을 방지하기 위해, 디바운싱(Debouncing) 적용 및 이벤트 리스너 해제(Cleanup)를 통해 브라우저 과부하와 메모리 누수를 막는 성능 최적화 기법입니다.
-
-## 📖 구조화된 지식 (Synthesized Content)
-**1. 리사이즈 이벤트의 성능 병목 현상** 브라우저 창 크기를 조절할 때, 브라우저는 아주 짧은 시간에 수십에서 수백 번의 `resize` 이벤트를 연속적으로 발생시킵니다. 만약 이 이벤트 핸들러 내부에서 React의 상태(State)를 업데이트하거나 무거운 연산을 수행하게 되면, 컴포넌트 트리가 매 틱마다 리렌더링을 시도하여 심각한 프레임 드랍과 브라우저 멈춤 현상(Bottleneck)이 발생합니다.
-
-**2. 스로틀링(Throttling)과 디바운싱(Debouncing) 적용** 과도한 이벤트 실행을 제어하기 위해 핸들러 함수에 디바운싱이나 스로틀링을 적용해야 합니다.
-
-- **디바운스(Debounce):** 사용자가 창 크기 조절을 멈춘 후 일정 시간(예: 200ms)이 지났을 때 마지막에 단 한 번만 리사이즈 로직(상태 업데이트 등)을 처리합니다. 레이아웃 재계산 비용이 큰 경우 가장 적합한 해결책입니다.
-- **스로틀(Throttle):** 창 크기를 조절하는 중에도 실시간으로 부드러운 UI 업데이트가 필요할 때, 이벤트를 일정한 시간 간격(예: 16ms, 약 60FPS)으로만 실행되도록 강제합니다.
-
-**3. 이벤트 리스너 해제와 메모리 누수(Memory Leak) 방지** React 컴포넌트 내부(주로 `useEffect` 훅)에서 `window.addEventListener('resize', handleResize)`를 등록했다면, **반드시 컴포넌트가 화면에서 사라질 때(Unmount) `window.removeEventListener`를 호출하는 클린업(Cleanup) 함수를 반환**해야 합니다. 이 정리 작업을 누락하면 컴포넌트가 파괴된 후에도 숨겨진 백그라운드에서 이벤트가 계속 수신되어, 시간이 지날수록 앱이 느려지고 결국 크래시를 유발하는 심각한 메모리 누수로 이어집니다.
-
-**4. 외부 지식: ResizeObserver API 활용 (※ 외부 지식 참고)** _이 내용은 제공된 소스 외부의 지식입니다._ 최신 웹 개발에서는 전역 `window` 객체에 `resize` 이벤트를 거는 대신, DOM 요소 자체의 크기 변화만 독립적으로 감지하는 브라우저 내장 API인 `ResizeObserver`를 활용하는 추세입니다. 이를 사용하면 전체 윈도우가 아닌 특정 컴포넌트(예: 반응형 3D 캔버스나 대규모 데이터 그리드 영역)의 크기가 변할 때만 타겟팅하여 반응할 수 있어 성능과 모듈성 면에서 훨씬 효율적입니다.
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Design & Experience 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[Throttling & Debouncing]], [[React Performance Optimization]], [[Memory Leak Prevention (메모리 누수 방지)]], [[useEffect 클린업(Cleanup)]]
-- **Projects/Contexts:** [[반응형 3D 캔버스(Three.js/R3F) 크기 최적화]], [[실시간 데이터 대시보드 레이아웃 조절 시스템]]
-- **Contradictions/Notes:** 단순히 윈도우 크기에 맞춰 CSS 요소의 크기나 배치를 조정하는 것이 목적이라면, 자바스크립트의 `resize` 이벤트를 아예 사용하지 않고 CSS의 미디어 쿼리(Media Queries)나 상대 단위(`vw`, `vh`, `100%`)를 사용하는 것이 렌더링 파이프라인 성능 측면에서 가장 비용이 낮고 완벽한 방법입니다. 자바스크립트 이벤트는 캔버스 렌더러 리사이즈나 복잡한 가상화 리스트(Virtualization) 재계산 등 CSS만으로 해결할 수 없는 경우에만 제한적으로 사용해야 합니다.
-
----
-
-_Last updated: 2026-04-14_
-- Raw Source: [[00_Raw/2026-04-20/반응형 윈도우 리사이즈(Resize) 이벤트 처리.md]]
----
diff --git a/Design & Experience/비동기 데이터 패칭 (Async Operations Pattern).md b/Design & Experience/비동기 데이터 패칭 (Async Operations Pattern).md
deleted file mode 100644
index bdf06d92..00000000
--- a/Design & Experience/비동기 데이터 패칭 (Async Operations Pattern).md	
+++ /dev/null
@@ -1,32 +0,0 @@
----
-id: P-REINFORCE-AUTO-C7F096
-category: "[[10_Wiki/💡 Topics/Design & Experience]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - 비동기 데이터 패칭 (Async Operations Pattern)"
----
-
-# [[비동기 데이터 패칭 (Async Operations Pattern)]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 비동기 데이터 패칭(Async Operations Pattern)은 API 요청과 같은 비동기 작업 및 UI 상태를 안전하게 관리하기 위한 재사용 가능한 아키텍처 패턴입니다. 주로 식별 가능한 유니온(Discriminated Unions)을 활용하여 로딩, 성공, 실패와 같은 다양한 상태를 모델링하며, 런타임 및 컴파일 단계에서 유효하지 않은 상태가 발생하는 것을 원천적으로 차단합니다. 이를 통해 애플리케이션의 상태 전환을 예측 가능하고 타입 안전(Type-safe)하게 만듭니다 [1-3].
-
-## 📖 구조화된 지식 (Synthesized Content)
-*   **식별 가능한 유니온을 통한 상태 모델링:** 비동기 작업 패턴은 '식별 가능한 유니온(Discriminated Unions)'을 핵심으로 사용합니다. 비동기 작업 처리 시 API 응답을 모델링하는 데 탁월하며, 상태를 나타내는 판별자(Discriminator)를 통해 유효하지 않은 조합의 상태가 나타나는 것을 방지합니다 [1, 2, 4].
-*   **상태 머신 패턴(State Machine Pattern)과의 결합:** 비동기 데이터 패칭은 일종의 상태 머신처럼 동작합니다. `FETCH_START`, `FETCH_SUCCESS`, `FETCH_FAILURE` 혹은 `Idle`, `Fetching`, `Success`, `Failure`, `RETRY`, `REFRESH`와 같은 명확한 상태(State)들을 정의하고 전환합니다 [5]. 타입스크립트의 철저한 검사(Exhaustive Checking)를 통해 개발자가 특정 비동기 상태의 처리를 누락하는 것을 컴파일 타임에 방지할 수 있습니다 [2, 4]. 
-*   **비동기 UI 상태를 위한 런타임 유효성 검사 (Runtime Validation):** 타입스크립트의 타입 검사는 런타임 오버헤드가 없는 컴파일 타임 기능이지만, 외부 API 등에서 유입되는 데이터는 타입스크립트만으로 제어할 수 없습니다. 따라서 비동기 데이터 패칭 패턴은 Zod와 같은 유효성 검사 라이브러리를 결합하여 태그된 UI 상태(Tagged UI State)를 런타임에 검증하는 재사용 가능한 스키마 팩토리(schema factory) 형태로 사용될 수 있습니다 [6, 7].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Design & Experience 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[식별 가능한 유니온 (Discriminated Unions)]], [[상태 머신 (State Machine Pattern)]], [[런타임 유효성 검사 (Runtime Validation)]]
-- **Projects/Contexts:** [[API 응답 처리 (API Response Handling)]], [[비동기 UI 상태 관리 (Async UI State)]]
-- **Contradictions/Notes:** 소스 내에서 비동기 데이터 패칭 패턴 자체에 대한 상충되는 의견은 없으나, 타입스크립트의 구조적 타이핑 특성상 컴파일 타임의 에러 방지만으로는 외부 비동기 데이터의 무결성을 완벽히 보장할 수 없다는 한계가 존재합니다. 따라서 외부 API나 설정 파일에서 전달받는 비동기 상태 데이터는 반드시 런타임 유효성 검사를 병행해야 한다고 강조하고 있습니다 [6, 7]. (소스에 비동기 데이터 패칭의 구체적인 코드 구현 예시 정보는 일부 누락되어 있어 관련 정보가 부족합니다.)
-
----
-*Last updated: 2026-04-18*
-- Raw Source: [[00_Raw/2026-04-20/비동기 데이터 패칭 (Async Operations Pattern).md]]
----
diff --git a/Design & Experience/사용성 공학 (Usability Engineering).md b/Design & Experience/사용성 공학 (Usability Engineering).md
deleted file mode 100644
index d51d4df4..00000000
--- a/Design & Experience/사용성 공학 (Usability Engineering).md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-5E0332
-category: "[[10_Wiki/💡 Topics/Design & Experience]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - 사용성 공학 (Usability Engineering)"
----
-
-# [[사용성 공학 (Usability Engineering)]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Design & Experience 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/사용성 공학 (Usability Engineering).md]]
----
diff --git a/Design & Experience/사용자 경험 (UX) 디자인.md b/Design & Experience/사용자 경험 (UX) 디자인.md
deleted file mode 100644
index 7e17747a..00000000
--- a/Design & Experience/사용자 경험 (UX) 디자인.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-A602EE
-category: "[[10_Wiki/💡 Topics/Design & Experience]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - 사용자 경험 (UX) 디자인"
----
-
-# [[사용자 경험 (UX) 디자인]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Design & Experience 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/사용자 경험 (UX) 디자인.md]]
----
diff --git a/Design & Experience/사용자 경험 (UX).md b/Design & Experience/사용자 경험 (UX).md
deleted file mode 100644
index 4bb8c014..00000000
--- a/Design & Experience/사용자 경험 (UX).md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-121347
-category: "[[10_Wiki/💡 Topics/Design & Experience]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - 사용자 경험 (UX)"
----
-
-# [[사용자 경험 (UX)]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Design & Experience 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/사용자 경험 (UX).md]]
----
diff --git a/Design & Experience/사용자 경험 디자인 (UX Design).md b/Design & Experience/사용자 경험 디자인 (UX Design).md
deleted file mode 100644
index 873b71d8..00000000
--- a/Design & Experience/사용자 경험 디자인 (UX Design).md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-EA48D7
-category: "[[10_Wiki/💡 Topics/Design & Experience]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - 사용자 경험 디자인 (UX Design)"
----
-
-# [[사용자 경험 디자인 (UX Design)]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Design & Experience 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/사용자 경험 디자인 (UX Design).md]]
----
diff --git a/Design & Experience/사회 인지 이론(Social Cognitive Theory).md b/Design & Experience/사회 인지 이론(Social Cognitive Theory).md
deleted file mode 100644
index 4c6af097..00000000
--- a/Design & Experience/사회 인지 이론(Social Cognitive Theory).md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-091F7D
-category: "[[10_Wiki/💡 Topics/Design & Experience]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - 사회 인지 이론(Social Cognitive Theory)"
----
-
-# [[사회 인지 이론(Social Cognitive Theory)]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Design & Experience 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/사회 인지 이론(Social Cognitive Theory).md]]
----
diff --git a/Design & Experience/상태 관리 최적화 (Zustand Valtio).md b/Design & Experience/상태 관리 최적화 (Zustand Valtio).md
deleted file mode 100644
index 11a8ee4e..00000000
--- a/Design & Experience/상태 관리 최적화 (Zustand Valtio).md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-C69D47
-category: "[[10_Wiki/💡 Topics/Design & Experience]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - 상태 관리 최적화 (Zustand Valtio)"
----
-
-# [[상태 관리 최적화 (Zustand Valtio)]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Design & Experience 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/상태 관리 최적화 (Zustand, Valtio).md]]
----
diff --git a/Design & Experience/상태 관리(State Management).md b/Design & Experience/상태 관리(State Management).md
deleted file mode 100644
index b92fecbe..00000000
--- a/Design & Experience/상태 관리(State Management).md	
+++ /dev/null
@@ -1,32 +0,0 @@
----
-id: P-REINFORCE-AUTO-58EC09
-category: "[[10_Wiki/💡 Topics/Design & Experience]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - 상태 관리(State Management)"
----
-
-# [[상태 관리(State Management)]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 상태 관리(State Management)는 사용자 입력, API 응답, UI 구성 및 애플리케이션 설정 등 시간이 지남에 따라 변경되는 데이터를 추적하고 유지하는 방법론입니다 [1]. 상태 흐름을 명확하게 관리하지 못하면 애플리케이션의 동작을 예측할 수 없게 되고 디버깅이 심각하게 어려워지며, 기술 부채와 성능 문제(불필요한 리렌더링, 메모리 누수 등)를 유발합니다 [2]. TypeScript 환경에서는 식별 가능한 유니온(Discriminated Unions)과 불변성(Immutability) 강제를 통해 무효한 상태를 원천 차단하고 안전하게 상태를 제어할 수 있습니다 [3-5].
-
-## 📖 구조화된 지식 (Synthesized Content)
-- **상태 관리의 중요성과 오남용의 위험성:** 명확한 패턴 없이 여러 곳에서 상태가 수정될 수 있으면 애플리케이션은 예측 불가능해집니다. 이는 버그의 근본 원인 파악을 매우 어렵게 만들고, 중복되거나 오래된 상태(stale state) 및 부수 효과(side-effects)로 인한 기술 부채를 축적시킵니다. 결과적으로 신규 개발자의 코드 이해도를 떨어뜨리고 렌더링 저하나 네트워크 요청 중복 같은 성능 문제를 야기합니다 [1, 2].
-- **식별 가능한 유니온(Discriminated Unions)을 활용한 상태 모델링:** TypeScript에서 상태 관리 방식을 혁신하는 핵심 패턴은 식별 가능한 유니온입니다 [3, 5]. 이는 '검증 중(validating)', '제출 중(submitting)', '성공(success)', '오류(error)'와 같은 비동기 UI 상태나 폼 제출 워크플로우, Redux 스타일의 리듀서, 라우터 상태 등을 모델링하는 데 완벽하게 작동합니다 [6, 7]. 이 패턴을 사용하면 TypeScript 컴파일러가 모든 분기 처리를 강제하여, 유효하지 않은 상태의 조합 자체를 물리적으로 불가능하게 만듭니다 [5, 8]. 이는 상태 기계(State Machine)를 구축하는 데에도 이상적입니다 [9, 10].
-- **타입 시스템을 통한 불변성(Immutability) 강제:** 무분별한 상태 변경은 상태 관리에서 애플리케이션의 예측 가능성을 떨어뜨리는 가장 큰 위협입니다 [11]. 이를 막기 위해 TypeScript의 `readonly` 수식어를 사용하여 리듀서나 전역 상태 관리 객체의 불변성을 강제할 수 있습니다 [4, 12]. 특히 복잡한 상태 관리가 필요한 프론트엔드 아키텍처에서는 단순한 얕은(shallow) 보호를 넘어, 중첩된 객체의 모든 속성이 예기치 않게 변경되지 않도록 보장하는 재귀적 불변성(Deep Readonly) 설계가 필수적인 요소로 꼽힙니다 [5].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Design & Experience 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[식별 가능한 유니온(Discriminated Unions)]], [[불변성(Immutability)]], [[상태 기계(State Machine)]], [[리듀서(Reducer)]]
-- **Projects/Contexts:** [[React 프론트엔드 개발]], [[Redux 아키텍처]]
-- **Contradictions/Notes:** 소스 전반에 걸쳐 상태 관리에 있어 불변성 유지(`readonly` 활용)와 타입 시스템(Discriminated Unions)을 통한 엄격한 상태 제어의 중요성에 동의하고 있으며, 상태 관리에 대한 상반된 주장이나 모순점은 발견되지 않았습니다.
-
----
-*Last updated: 2026-04-18*
-- Raw Source: [[00_Raw/2026-04-20/상태 관리(State Management).md]]
----
diff --git a/Design & Experience/상태 머신 (State Machine) 모델링 및 Redux 액션_리듀서 설계.md b/Design & Experience/상태 머신 (State Machine) 모델링 및 Redux 액션_리듀서 설계.md
deleted file mode 100644
index b46bbdb7..00000000
--- a/Design & Experience/상태 머신 (State Machine) 모델링 및 Redux 액션_리듀서 설계.md	
+++ /dev/null
@@ -1,34 +0,0 @@
----
-id: P-REINFORCE-AUTO-D423C6
-category: "[[10_Wiki/💡 Topics/Design & Experience]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - 상태 머신 (State Machine) 모델링 및 Redux 액션_리듀서 설계"
----
-
-# [[상태 머신 (State Machine) 모델링 및 Redux 액션_리듀서 설계]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 상태 머신(State Machine) 모델링과 Redux 액션/리듀서 설계는 애플리케이션의 복잡한 상태 전이를 명확하게 정의하고 관리하기 위한 구조적 접근법입니다. 타입스크립트(TypeScript) 환경에서는 주로 식별 가능한 유니온(Discriminated Unions) 패턴을 활용하여 이러한 상태 및 액션들을 안전하고 완벽하게 구현할 수 있습니다 [1-3]. 다만, 제공된 소스에는 이를 구체적으로 설계하는 세부 방법론이나 코드 레벨의 상세한 정보가 부족합니다.
-
-## 📖 구조화된 지식 (Synthesized Content)
-- **식별 가능한 유니온(Discriminated Unions)과의 시너지**: 타입스크립트의 식별 가능한 유니온 패턴은 Redux 스타일의 리듀서를 설계하거나 상태 머신을 모델링하는 데 완벽하게 부합하며 그 진가를 발휘합니다 [1, 2]. 
-- **상태 머신 패턴 (State Machine Pattern)의 상태와 전이**: 식별 가능한 유니온을 사용하여 상태 머신을 모델링하면 명확한 상태 전이(State transitions)를 타입으로 강제하고 표현할 수 있습니다 [3, 4]. 소스에서 언급된 상태 머신 모델링의 예시는 다음과 같습니다 [3]:
-  - **상태 (States)**: `Idle` (대기), `Fetching` (가져오는 중), `Success` (성공), `Failure` (실패)
-  - **액션/전이 (Actions/Transitions)**: `FETCH_START`, `FETCH_SUCCESS`, `FETCH_FAILURE`, `RETRY` (재시도 횟수가 남은 경우), `REFRESH`
-- **데이터 부족 안내**: **소스에 관련 정보가 부족합니다.** 업로드된 소스 데이터에서는 식별 가능한 유니온이 상태 머신 모델링 및 Redux 액션/리듀서 설계에 아주 적합하다는 점과 간단한 상태 목록만 언급될 뿐, 이들을 어떻게 아키텍처 관점에서 설계하고 구현해야 하는지에 대한 구체적인 설명이나 예제 코드는 포함되어 있지 않습니다.
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Design & Experience 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[식별 가능한 유니온 (Discriminated Unions)]], [[타입 안전성 (Type Safety)]]
-- **Projects/Contexts:** [[React 상태 관리 (React State Management)]], [[비동기 데이터 패칭 (Async Operations Pattern)]]
-- **Contradictions/Notes:** 소스에 관련 정보가 부족합니다. 상태 머신 및 Redux 패턴 설계 지침을 다루기보다는, 타입스크립트의 '식별 가능한 유니온'이 활용되기 좋은 대표적인 사례(Use Case) 중 하나로서만 간략히 소개되어 있습니다.
-
----
-*Last updated: 2026-04-18*
-- Raw Source: [[00_Raw/2026-04-20/상태 머신 (State Machine) 모델링 및 Redux 액션_리듀서 설계.md]]
----
diff --git a/Design & Experience/상태 모델링 (State Modeling).md b/Design & Experience/상태 모델링 (State Modeling).md
deleted file mode 100644
index b38dca11..00000000
--- a/Design & Experience/상태 모델링 (State Modeling).md	
+++ /dev/null
@@ -1,34 +0,0 @@
----
-id: P-REINFORCE-AUTO-BC8C33
-category: "[[10_Wiki/💡 Topics/Design & Experience]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - 상태 모델링 (State Modeling)"
----
-
-# [[상태 모델링 (State Modeling)]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 상태 모델링은 애플리케이션에서 시간에 따라 변화하는 데이터(사용자 입력, API 응답, UI 설정 등)를 구조화하고 추적하는 과정입니다 [1]. 잘못된 상태 관리는 예측 불가능한 동작과 디버깅의 어려움 등 기술 부채를 초래하므로, 견고한 모델링이 필수적입니다 [2]. TypeScript에서는 주로 식별 가능한 유니온(Discriminated Unions)을 활용하여 "유효하지 않은 상태를 원천적으로 불가능하게 만드는" 상태 머신 패턴을 통해 안전하고 명확하게 상태를 모델링합니다 [3-5].
-
-## 📖 구조화된 지식 (Synthesized Content)
-* **상태 관리의 중요성과 문제점:** 애플리케이션의 상태는 여러 위치에서 명확한 패턴 없이 수정될 경우 예측 불가능한 동작, 디버깅의 악몽, 불필요한 리렌더링 및 기술 부채를 유발할 수 있습니다 [2]. 따라서 변화하는 데이터를 체계적으로 통제하고 추적하는 모델링 설계가 매우 중요합니다.
-* **식별 가능한 유니온(Discriminated Unions)의 활용:** TypeScript에서 복잡한 상태를 모델링하는 가장 강력한 패턴은 식별 가능한 유니온(또는 태그된 유니온)입니다 [3, 6]. `state`나 `kind`와 같은 공통 리터럴 속성(식별자)을 사용하여 각기 다른 형태의 데이터를 구별함으로써, 타입 시스템이 안전하게 타입을 좁혀나갈 수 있도록 돕습니다 [7-9].
-* **유효하지 않은 상태의 원천 차단 (Making Invalid States Impossible):** 상태 모델링의 핵심 목표 중 하나는 컴파일 단계에서 잘못된 상태 조합을 표현할 수 없게 만드는 것입니다 [4, 5, 10]. 이는 타입 자체가 가능한 상태들을 스스로 문서화하고, 코드의 아키텍처적 무결성을 보장하는 효과를 가져옵니다 [10].
-* **상태 머신(State Machine) 패턴 구현:** 식별 가능한 유니온은 애플리케이션 내의 상태 머신을 구현하는 데 완벽하게 적합합니다 [11, 12]. 네트워크 요청이나 데이터 로딩 상태를 `Idle`, `Fetching`, `Success`, `Failure` 등으로 명확히 나누거나 [8, 12, 13], 복잡한 폼 제출 워크플로우(검증 중, 검증 에러, 제출 중, 성공 등)를 태그된 상태로 모델링할 때 강력한 힘을 발휘합니다 [4].
-* **완전성 검사(Exhaustiveness Checking)를 통한 안전성 보장:** 상태 모델링을 사용할 때 `never` 타입을 활용한 완전성 검사 기법을 적용할 수 있습니다 [14-17]. 이는 유니온 타입에 새로운 상태가 추가되었을 때 개발자가 이를 처리하는 로직(예: switch 문)을 누락하면 컴파일러가 에러를 발생시키는 방식입니다 [16-18]. 이 메커니즘은 시스템 확장에 따른 부작용과 런타임 버그를 사전에 철저히 차단합니다 [17, 19].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Design & Experience 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[식별 가능한 유니온 (Discriminated Unions)]], [[완전성 검사 (Exhaustiveness Checking)]], [[상태 머신 (State Machine)]]
-- **Projects/Contexts:** [[API 응답 처리 (API Response Handling)]], [[폼 제출 워크플로우 (Form Submission Workflow)]]
-- **Contradictions/Notes:** 소스에 관련 정보가 부족합니다.
-
----
-*Last updated: 2026-04-18*
-- Raw Source: [[00_Raw/2026-04-20/상태 모델링 (State Modeling).md]]
----
diff --git a/Design & Experience/선언 병합(Declaration Merging).md b/Design & Experience/선언 병합(Declaration Merging).md
deleted file mode 100644
index 715e0a6c..00000000
--- a/Design & Experience/선언 병합(Declaration Merging).md	
+++ /dev/null
@@ -1,33 +0,0 @@
----
-id: P-REINFORCE-AUTO-18CC73
-category: "[[10_Wiki/💡 Topics/Design & Experience]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - 선언 병합(Declaration Merging)"
----
-
-# [[선언 병합(Declaration Merging)]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 선언 병합(Declaration Merging)은 TypeScript에서 동일한 이름을 가진 여러 개의 인터페이스를 선언할 경우, 컴파일러가 이를 자동으로 하나의 단일 인터페이스로 합치는 고유한 기능입니다 [1]. 주로 라이브러리 제작자가 사용자에게 타입 확장 지점을 제공하거나 패치할 때 유용하게 사용되지만, 일반 애플리케이션 코드에서는 의도치 않은 타입 병합을 막기 위해 사용을 지양하는 경우도 많습니다 [2-4].
-
-## 📖 구조화된 지식 (Synthesized Content)
-* **동작 원리**: TypeScript에서 인터페이스(Interface)를 동일한 이름으로 여러 번 선언하면, 타입 시스템이 이를 하나의 인터페이스로 합칩니다 [1]. 
-* **주요 사용 사례 (라이브러리 수준)**: 이 기능은 특히 라이브러리 코드에서 진가를 발휘합니다 [4]. 라이브러리 소비자가 필요에 따라 기존 선언을 확장(extend)하거나 타입을 패치(patch)할 수 있도록 유용한 확장 지점을 제공하기 때문입니다 [1, 3, 4].
-* **타입 별칭(Type Alias)과의 차이점**: 인터페이스와 달리, 타입 별칭(Type)은 동일한 이름으로 재선언할 수 없으므로 선언 병합이 발생하지 않습니다 [1]. 이러한 특징 덕분에 타입 별칭을 사용하면 예기치 않은 병합을 방지하고 더 엄격하게 타입을 관리할 수 있습니다 [1, 5].
-* **개발자 커뮤니티의 관점 및 주의점**: 많은 개발자와 팀은 의도치 않은 선언 병합을 피하고자 애플리케이션 코드 내에서 인터페이스 대신 타입 별칭을 사용하는 방식을 채택합니다 [2, 6]. 호환되지 않는 필드를 가진 두 형태가 우연히 합쳐질 때 발생할 수 있는 오류를 피하기 위해, 선언 병합을 나쁜 관행(Bad Thing™)으로 간주하고 이를 방지하고자 린트(eslint) 규칙으로 인터페이스 사용을 금지하는 사례도 있습니다 [7, 8].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Design & Experience 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[인터페이스(Interface)]], [[타입 별칭(Type Alias)]]
-- **Projects/Contexts:** [[라이브러리 코드 작성]], [[TypeScript 타입 시스템]]
-- **Contradictions/Notes:** 소스에 따르면 라이브러리 제작 관점에서는 소비자에게 확장을 허용하는 매우 유용한 기능으로 평가받지만 [1, 4], 애플리케이션 개발 팀 관점에서는 의도치 않은 병합 버그를 유발할 수 있어 피해야 할 기능으로 강하게 반대되기도 합니다 [2, 8].
-
----
-*Last updated: 2026-04-18*
-- Raw Source: [[00_Raw/2026-04-20/선언 병합(Declaration Merging).md]]
----
diff --git a/Design & Experience/소프트웨어 시스템 설계 및 아키텍처 구축.md b/Design & Experience/소프트웨어 시스템 설계 및 아키텍처 구축.md
deleted file mode 100644
index b80f4d52..00000000
--- a/Design & Experience/소프트웨어 시스템 설계 및 아키텍처 구축.md	
+++ /dev/null
@@ -1,42 +0,0 @@
----
-id: P-REINFORCE-AUTO-6B386C
-category: "[[10_Wiki/💡 Topics/Design & Experience]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - 소프트웨어 시스템 설계 및 아키텍처 구축"
----
-
-# [[소프트웨어 시스템 설계 및 아키텍처 구축]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 소프트웨어 시스템 설계 및 아키텍처 구축은 변화하는 비즈니스 요구에 적응하고 시스템의 복잡성을 제어하기 위해 확장 가능하고 유지보수가 용이한 애플리케이션의 뼈대를 설계하는 과정입니다 [1, 2]. 이 과정은 시스템을 관리 가능한 독립적 모듈로 분할하는 '관심사의 분리(SoC)'를 핵심 원리로 삼으며, 고수준의 비즈니스 규칙과 저수준의 인프라(UI, DB 등)를 격리하는 것을 목표로 합니다 [3, 4]. 이를 통해 개발 조직은 코드의 재사용성을 높이고, 독립적인 테스트와 배포를 가능하게 하여 소프트웨어의 생명주기를 효과적으로 지원할 수 있습니다 [5, 6].
-
-## 📖 구조화된 지식 (Synthesized Content)
-- **핵심 설계 원칙 (Core Design Principles):**
-  - **관심사의 분리 (Separation of Concerns, SoC):** 프로그램을 각기 다른 관심사나 기능에만 집중하도록 분리하여, 모듈 간의 결합도(Coupling)를 낮추고 응집도(Cohesion)를 높이는 가장 근본적인 아키텍처 원칙입니다 [3, 7-9]. 이를 통해 시스템의 가독성을 높이고 특정 모듈 변경 시 발생하는 파급 효과를 최소화할 수 있습니다 [10, 11].
-  - **클린 아키텍처 (Clean Architecture):** 비즈니스 로직(엔티티와 유스케이스)을 시스템의 중심에 두고, 프레임워크나 데이터베이스와 같은 세부 구현을 외부 계층으로 밀어냅니다 [12-15]. 소스 코드 의존성은 항상 외부에서 내부(고수준 정책)로만 향해야 한다는 '의존성 규칙(Dependency Rule)'을 통해 기술적 변화로부터 핵심 비즈니스를 보호합니다 [4, 16].
-  - **SOLID 원칙 및 DRY:** 단일 책임 원칙(SRP)과 인터페이스 분리 원칙(ISP)을 포함하는 SOLID와 코드 중복을 방지하는 DRY 원칙은, 유연하고 테스트 가능한 객체 지향 설계를 돕는 아키텍처의 필수 도구입니다 [17-19].
-
-- **주요 아키텍처 패턴 (Architectural Patterns):**
-  - **계층화 아키텍처 (Layered Architecture):** 시스템을 프레젠테이션, 비즈니스 로직, 데이터 액세스 등 수평적인 계층으로 나누어 계층 간 통신을 제어하는 전통적인 구조입니다 [20-22].
-  - **마이크로서비스 아키텍처 (Microservices Architecture):** 시스템을 특정 비즈니스 역량 중심의 자율적인 서비스들로 분해합니다 [23, 24]. 넷플릭스(Netflix)는 거대한 모놀리식 구조를 마이크로서비스로 분리하여 팀의 개발 속도와 혁신성을 높였으며, 이후 이를 확장하여 마이크로서비스, 비동기 워크플로우, 서버리스 함수를 결합한 '코스모스(Cosmos)' 플랫폼으로 발전시켰습니다 [25-28].
-  - **이벤트 기반 아키텍처 (Event-Driven Architecture):** 서비스들이 이벤트를 생산하고 소비하는 비동기 방식으로 통신하게 하여, 시스템 결합도를 느슨하게 만들고 실시간 데이터 처리와 확장성을 극대화합니다 [29, 30].
-
-- **프론트엔드 및 AI 아키텍처로의 확장:**
-  - 프론트엔드 환경에서도 모놀리식 구조의 한계를 극복하고자 '마이크로 프론트엔드(Micro Frontends)' 및 '기능 중심 설계(FSD)'를 도입하여 각 팀이 화면의 특정 기능을 독립적으로 개발하고 배포할 수 있도록 구성합니다 [31-33].
-  - AI 시스템의 경우 비결정론적 특성을 감안하여, TDD(테스트 주도 개발) 원칙을 적용해 데이터 전처리, 모델 추론 등 개별 구성 요소의 경계를 명확히 하고 통계적 검증을 결합하는 아키텍처적 규칙을 수립합니다 [34-37].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Design & Experience 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[Separation of Concerns (SoC)]], [[Clean Architecture]], [[Microservices Architecture]], [[SOLID Principles]]
-- **Projects/Contexts:** [[Netflix Microservices & Cosmos Platform]], [[Feature-Sliced Design (FSD)]]
-- **Contradictions/Notes:** 마이크로서비스 아키텍처는 유연성과 독립적 배포를 제공하지만 분산 시스템 간의 통신, 배포의 복잡성, 메모리 오버헤드를 유발하므로 무조건적인 도입은 지양해야 합니다 [38, 39]. 또한 완벽한 관심사 분리를 위한 과도한 추상화(Over-engineering)나 너무 이른 계층 분리는 오히려 시스템을 복잡하게 만들어 가독성을 해치고 인지적 부하를 유발할 수 있으므로, 응집도와 결합도를 실무적 상황에 맞게 조율해야 합니다 [40-42].
-
----
-*Last updated: 2026-04-18*
-- Raw Source: [[00_Raw/2026-04-20/소프트웨어 시스템 설계 및 아키텍처 구축.md]]
----
diff --git a/Design & Experience/실시간 데이터 대시보드 레이아웃 조절 시스템.md b/Design & Experience/실시간 데이터 대시보드 레이아웃 조절 시스템.md
deleted file mode 100644
index c4994f39..00000000
--- a/Design & Experience/실시간 데이터 대시보드 레이아웃 조절 시스템.md	
+++ /dev/null
@@ -1,42 +0,0 @@
----
-id: P-REINFORCE-AUTO-BAC69B
-category: "[[10_Wiki/💡 Topics/Design & Experience]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - 실시간 데이터 대시보드 레이아웃 조절 시스템"
----
-
-# [[실시간 데이터 대시보드 레이아웃 조절 시스템]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 실시간으로 쏟아지는 대규모 데이터를 시각화하는 대시보드 환경에서, 사용자의 레이아웃 변경(위젯 크기 조절, 드래그 등)과 잦은 데이터 업데이트가 충돌하여 UI가 멈추거나 버벅거리는 현상을 방지하는 고성능 렌더링 및 상태 제어 시스템입니다.
-
-## 📖 구조화된 지식 (Synthesized Content)
-**1. 리사이즈 및 레이아웃 이벤트 제어 (Debouncing & Throttling)** 대시보드의 위젯 크기 조절이나 윈도우 창 변경 시에는 아주 짧은 시간에 수많은 레이아웃 연산 이벤트가 발생합니다. 브라우저 과부하와 UI 병목 현상을 막기 위해, `lodash`의 **디바운스(Debounce)나 스로틀(Throttle) 기법을 적용하여 무거운 연산이나 리렌더링이 연속적으로 실행되는 것을 제어**해야 합니다.
-
-**2. 고빈도 업데이트를 위한 상태 관리 최적화** 실시간 대시보드는 차트나 데이터 그리드가 초당 수십 번씩 업데이트될 수 있습니다. 이때 React의 기본 Context API를 전역 상태처럼 사용하면, 내부 값 하나만 변경되어도 이를 구독하는 모든 위젯과 컴포넌트가 리렌더링되는 심각한 폭포수(Cascading) 현상이 발생합니다. 이를 방지하려면 **컨텍스트를 도메인별로 잘게 분리하거나 `useContextSelector`를 도입**하고, 세밀한 단위의(Granular) 업데이트에 최적화된 **Zustand, Jotai, Valtio 같은 전용 상태 관리 라이브러리를 사용**해야 합니다.
-
-**3. 무거운 위젯의 지연 로딩(Lazy Loading)과 가상화(Virtualization)**
-
-- **지연 로딩:** 초기 로딩 속도를 높이기 위해, 당장 화면에 보이지 않거나 무거운 대시보드 위젯(예: 차트 위젯)은 `React.lazy`와 `<Suspense>`를 활용해 온디맨드 방식으로 동적 로드해야 합니다.
-- **리스트 가상화:** 대규모 로그나 데이터 테이블을 렌더링할 때는 수천 개의 DOM 노드가 생성되어 메모리를 낭비하지 않도록, `react-window`나 `react-virtualized`를 사용하여 **현재 화면(Viewport)에 노출되는 항목만 렌더링**하는 가상화 기법을 적용해야 합니다.
-
-**4. 동시성(Concurrent) 기능을 통한 UI 반응성 확보** 무거운 차트를 렌더링하거나 대규모 데이터를 필터링할 때 사용자의 클릭이나 타이핑이 버벅거리지 않도록, React 18의 동시성 훅을 적극 활용합니다. **`useTransition`을 사용하여 무거운 필터링이나 뷰 업데이트를 비긴급 작업으로 미루고**, **`useDeferredValue`를 사용해 파생 데이터의 계산을 지연시켜 메인 스레드의 과부하 시에도 UI 입력 반응성을 부드럽게 유지**합니다.
-
-**5. 웹 워커(Web Worker)를 이용한 연산 오프로딩** 대용량 JSON 파싱, 복잡한 데이터 정렬이나 물리 연산과 같이 CPU 집약적인 작업은 자바스크립트의 메인 스레드를 차단합니다. 이러한 작업은 **Web Worker나 `useWorker` 훅을 활용하여 백그라운드 스레드로 넘김(Offloading)으로써, 무거운 데이터 처리 중에도 대시보드가 60FPS의 매끄러운 반응성을 유지**할 수 있도록 설계해야 합니다.
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Design & Experience 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[Throttling & Debouncing]], [[React 동시성 훅 (useTransition, useDeferredValue)]], [[상태 관리 최적화 (Zustand, Jotai, Valtio)]], [[Virtualization (리스트 가상화)]], [[Web Worker (웹 워커)]]
-- **Projects/Contexts:** [[대용량 데이터 분석 플랫폼 및 모니터링 시스템]], [[고성능 금융/주식 실시간 거래 대시보드]]
-- **Contradictions/Notes:** React에 내장된 Context API는 테마나 로그인 정보처럼 가끔 변하는 데이터에는 훌륭하지만, 고빈도로 상태가 업데이트되는 실시간 대시보드에서는 성능을 조용히 갉아먹는 주범이 되므로 대안 상태 관리 도구가 필수적입니다.
-
----
-
-_Last updated: 2026-04-15_
-- Raw Source: [[00_Raw/2026-04-20/실시간 데이터 대시보드 레이아웃 조절 시스템.md]]
----
diff --git a/Design & Experience/아보(Bobo) 인형 실험.md b/Design & Experience/아보(Bobo) 인형 실험.md
deleted file mode 100644
index 991d3c37..00000000
--- a/Design & Experience/아보(Bobo) 인형 실험.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-8F65AF
-category: "[[10_Wiki/💡 Topics/Design & Experience]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - 아보(Bobo) 인형 실험"
----
-
-# [[아보(Bobo) 인형 실험]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Design & Experience 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/아보(Bobo) 인형 실험.md]]
----
diff --git a/Design & Experience/엔티티 (Entities).md b/Design & Experience/엔티티 (Entities).md
deleted file mode 100644
index c249126d..00000000
--- a/Design & Experience/엔티티 (Entities).md	
+++ /dev/null
@@ -1,40 +0,0 @@
----
-id: P-REINFORCE-AUTO-8E681E
-category: "[[10_Wiki/💡 Topics/Design & Experience]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - 엔티티 (Entities)"
----
-
-# [[엔티티 (Entities)]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 엔티티(Entities)는 소프트웨어 아키텍처 및 도메인 주도 설계(DDD)에서 핵심 업무 데이터와 이를 기반으로 동작하는 전사적인 핵심 업무 규칙을 캡슐화하는 고수준의 객체입니다 [1-3]. 이들은 아키텍처의 가장 중심 계층에 위치하며, 데이터베이스나 사용자 인터페이스(UI), 프레임워크와 같은 외부 요소에 전혀 의존하지 않고 독립적으로 존재합니다 [1, 4]. 본질적으로 시스템의 입출력 방식이나 외부 기술의 변화에 영향을 받지 않는, 비즈니스의 가장 핵심적이고 순수한 개념을 구체화합니다 [3-5].
-
-## 📖 구조화된 지식 (Synthesized Content)
-* **엔티티의 정의 및 식별성**
-  도메인 주도 설계(DDD)에서 엔티티는 고유한 식별성(identity)을 갖는 객체로 정의되며, 오직 속성으로만 정의되는 값 객체(Value Object)와 엄격히 구분됩니다 [6]. 예를 들어, '고객(Customer)'은 고유한 정체성을 가진 엔티티에 해당하고, '배송지 주소'는 값 객체로 취급됩니다 [6]. 엔티티는 핵심 업무 데이터를 직접 포함하거나 쉽게 접근할 수 있으며, 이 데이터를 조작하는 업무 규칙 함수들을 인터페이스로 제공합니다 [2].
-
-* **클린 아키텍처에서의 중심 역할**
-  클린 아키텍처 구조에서 엔티티는 시스템의 가장 안쪽이자 중심인 도메인 계층에 위치합니다 [1, 7]. 외부의 어떠한 세부 사항(웹, 데이터베이스, 서드파티 프레임워크 등)으로 인해 오염되어서는 안 되며, 외부 계층에 대해 전혀 알지 못해야 합니다 [4, 8]. 이를 위해 엔티티 객체는 프레임워크 등에 의존하지 않는 오래된 방식의 간단하고 평범한 객체(plain old object) 형태로 유지되어야 합니다 [9, 10].
-
-* **유스케이스(Use Cases)와의 관계**
-  엔티티는 시스템에서 가장 범용적이고 높은 수준(고수준)을 갖는 개념입니다 [11]. 단일 애플리케이션에 특화된 저수준 개념인 유스케이스는 엔티티에 의존하고 엔티티의 핵심 업무 규칙을 호출하지만, 반대로 엔티티는 자신을 제어하는 유스케이스에 대해 아무것도 알지 못합니다 [5, 12]. 유스케이스는 엔티티로 들어오고 나가는 데이터 흐름을 조정하는 역할을 수행합니다 [13].
-
-* **변경에 대한 독립성과 유의사항**
-  엔티티는 전사적인 핵심 규칙을 담고 있기 때문에, 페이지 네비게이션이나 보안과 같은 외부 요구사항이 변경되더라도 엔티티가 변경될 가능성은 지극히 낮습니다 [3]. 또한, 엔티티와 애플리케이션의 요청/응답 모델이 상당히 많은 데이터를 공유하더라도, 두 객체의 목적이 완전히 다르므로 결코 결합(참조)해서는 안 됩니다 [14]. 이를 결합하면 공통 폐쇄 원칙과 단일 책임 원칙을 위배하게 되어 코드베이스를 오염시킵니다 [14].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Design & Experience 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[도메인 주도 설계 (Domain-Driven Design)]], [[클린 아키텍처 (Clean Architecture)]], [[유스케이스 (Use Cases)]], [[값 객체 (Value Objects)]]
-- **Projects/Contexts:** [[엔터프라이즈급 소프트웨어 아키텍처 설계]], [[VIPER 아키텍처 기반 iOS 애플리케이션 개발]]
-- **Contradictions/Notes:** 엔티티와 시스템의 요청 및 응답 모델은 많은 데이터를 공유하기 때문에 서로 참조하거나 결합하려는 유혹에 빠지기 쉽지만, 이는 장기적으로 공통 폐쇄 원칙을 위반하고 코드베이스에 혼란을 초래하므로 엄격히 분리해야 한다고 경고합니다 [14].
-
----
-*Last updated: 2026-04-18*
-- Raw Source: [[00_Raw/2026-04-20/엔티티 (Entities).md]]
----
diff --git a/Design & Experience/응용 행동 분석(ABA)] [행동 경제학] [교육 심리학의 행동주의 모델.md b/Design & Experience/응용 행동 분석(ABA)] [행동 경제학] [교육 심리학의 행동주의 모델.md
deleted file mode 100644
index 7970d89b..00000000
--- a/Design & Experience/응용 행동 분석(ABA)] [행동 경제학] [교육 심리학의 행동주의 모델.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-5A7860
-category: "[[10_Wiki/💡 Topics/Design & Experience]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - 응용 행동 분석(ABA)] [행동 경제학] [교육 심리학의 행동주의 모델"
----
-
-# [[응용 행동 분석(ABA)] [행동 경제학] [교육 심리학의 행동주의 모델]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Design & Experience 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/응용 행동 분석(ABA)], [행동 경제학], [교육 심리학의 행동주의 모델.md]]
----
diff --git a/Design & Experience/의존성 규칙 (Dependency Rule).md b/Design & Experience/의존성 규칙 (Dependency Rule).md
deleted file mode 100644
index 5f13161d..00000000
--- a/Design & Experience/의존성 규칙 (Dependency Rule).md	
+++ /dev/null
@@ -1,40 +0,0 @@
----
-id: P-REINFORCE-AUTO-57A5BA
-category: "[[10_Wiki/💡 Topics/Design & Experience]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - 의존성 규칙 (Dependency Rule)"
----
-
-# [[의존성 규칙 (Dependency Rule)]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 의존성 규칙(Dependency Rule)은 클린 아키텍처(Clean Architecture)의 핵심 원칙으로, 모든 소스 코드 의존성이 반드시 고수준의 핵심 비즈니스 로직을 향해 '안쪽으로만' 향해야 한다는 원칙입니다 [1-3]. 이 규칙은 내부 계층(뇌)이 외부 계층(팔다리)의 존재에 대해 전혀 알지 못하도록 통제하여 시스템의 결합도를 낮추고 독립성을 극대화합니다 [2-4]. 결과적으로 비즈니스의 본질적인 규칙을 UI, 데이터베이스, 프레임워크 등 변동성이 높은 기술적 세부 사항으로부터 완벽하게 격리하고 보호하는 역할을 수행합니다 [1, 4, 5].
-
-## 📖 구조화된 지식 (Synthesized Content)
-*   **의존성의 방향 (Direction of Dependencies)**
-    의존성 규칙에 따르면 소프트웨어의 소스 코드 의존성은 오직 안쪽, 즉 중앙의 핵심 비즈니스 로직(엔티티 및 유스케이스 등)으로만 향해야 합니다 [1, 3]. 이는 저수준의 모듈(외부의 프레임워크나 UI)이 고수준의 모듈(내부의 도메인)에 의존해야 하며, 고수준 모듈은 외부 기관에 결코 의존해서는 안 된다는 것을 의미합니다 [2].
-
-*   **내부 계층의 완전한 격리 (Isolation of Inner Layers)**
-    내부의 원에 속한 코드(뇌)는 외부의 원에 선언된 어떤 것(팔다리)에 대해서도 그 이름을 언급해서는 안 됩니다 [3]. 즉, 함수, 클래스, 변수 등 외부에 존재하는 모든 소프트웨어 요소의 존재를 내부 계층은 몰라야 합니다 [3]. 이를 통해 외부의 인프라스트럭처가 변경되더라도 핵심 비즈니스 규칙이 영향을 받지 않도록 보장합니다 [4, 6].
-
-*   **데이터 형식의 독립성 (Data Format Independence)**
-    외부 원에서 선언된 데이터 형식이나 특정 프레임워크가 생성한 데이터 구조를 내부 원에서 절대로 사용해서는 안 됩니다 [3]. 계층의 경계를 가로질러 데이터를 전달할 때는, 데이터베이스의 행(Row) 같은 외부 포맷이 아닌 내부의 원에서 사용하기 편리한 형태(간단한 데이터 전송 객체나 구조체)로 변환되어 전달되어야 합니다 [6, 7]. 
-
-*   **경계 횡단과 의존성 역전 원칙 (Crossing Boundaries and DIP)**
-    시스템의 제어 흐름이 의존성 규칙과 반대 방향으로 향해야 하는 경우(예를 들어, 내부의 유스케이스 계층이 외부의 프레젠터 계층을 호출해야 할 때), 이를 직접 호출하면 의존성 규칙을 위배하게 됩니다 [8]. 이 문제는 의존성 역전 원칙(DIP)과 동적 다형성을 활용하여 해결합니다 [8, 9]. 내부 계층에 인터페이스를 정의하고 외부 계층이 이를 구현하게 함으로써, 제어 흐름이 밖으로 향하더라도 소스 코드 의존성은 계속 안쪽을 유지할 수 있게 만듭니다 [8-10].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Design & Experience 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[클린 아키텍처 (Clean Architecture)]], [[의존성 역전 원칙 (Dependency Inversion Principle, DIP)]], [[엔티티 (Entities)]], [[유스케이스 (Use Cases)]]
-- **Projects/Contexts:** [[엔터프라이즈 소프트웨어 시스템 설계]], [[모듈화 및 아키텍처 경계 설정]]
-- **Contradictions/Notes:** 의존성 규칙을 엄격하게 준수하기 위해 완벽한 아키텍처 경계(쌍방향 다형적 인터페이스, 분리된 입/출력 데이터 구조 등)를 만드는 것은 초기 설정 및 유지보수 비용이 상당히 큽니다 [11]. 따라서 모든 상황에 이 규칙을 엄격히 적용하기보다는, 프로젝트의 규모에 따라 전략 패턴이나 퍼사드(Facade) 패턴을 활용한 부분적 경계(Partial Boundary)를 두거나 실무적 타협을 하는 경우도 존재합니다 [11-13].
-
----
-*Last updated: 2026-04-18*
-- Raw Source: [[00_Raw/2026-04-20/의존성 규칙 (Dependency Rule).md]]
----
diff --git a/Design & Experience/인간 요인 공학 (Human Factors Engineering).md b/Design & Experience/인간 요인 공학 (Human Factors Engineering).md
deleted file mode 100644
index b74ad667..00000000
--- a/Design & Experience/인간 요인 공학 (Human Factors Engineering).md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-E342BB
-category: "[[10_Wiki/💡 Topics/Design & Experience]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - 인간 요인 공학 (Human Factors Engineering)"
----
-
-# [[인간 요인 공학 (Human Factors Engineering)]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Design & Experience 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/인간 요인 공학 (Human Factors Engineering).md]]
----
diff --git a/Design & Experience/인지 부조화 이론.md b/Design & Experience/인지 부조화 이론.md
deleted file mode 100644
index 14de5b24..00000000
--- a/Design & Experience/인지 부조화 이론.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-CE996D
-category: "[[10_Wiki/💡 Topics/Design & Experience]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - 인지 부조화 이론"
----
-
-# [[인지 부조화 이론]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Design & Experience 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/인지 부조화 이론.md]]
----
diff --git a/Design & Experience/인지 부하 이론(Cognitive Load Theory).md b/Design & Experience/인지 부하 이론(Cognitive Load Theory).md
deleted file mode 100644
index 6d4193c6..00000000
--- a/Design & Experience/인지 부하 이론(Cognitive Load Theory).md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-AA8C86
-category: "[[10_Wiki/💡 Topics/Design & Experience]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - 인지 부하 이론(Cognitive Load Theory)"
----
-
-# [[인지 부하 이론(Cognitive Load Theory)]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Design & Experience 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/인지 부하 이론(Cognitive Load Theory).md]]
----
diff --git a/Design & Experience/인지 심리학 (Cognitive Psychology).md b/Design & Experience/인지 심리학 (Cognitive Psychology).md
deleted file mode 100644
index ec1f1ae8..00000000
--- a/Design & Experience/인지 심리학 (Cognitive Psychology).md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-30DB87
-category: "[[10_Wiki/💡 Topics/Design & Experience]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - 인지 심리학 (Cognitive Psychology)"
----
-
-# [[인지 심리학 (Cognitive Psychology)]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Design & Experience 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/인지 심리학 (Cognitive Psychology).md]]
----
diff --git a/Design & Experience/인지 평가 이론 (Cognitive Evaluation Theory).md b/Design & Experience/인지 평가 이론 (Cognitive Evaluation Theory).md
deleted file mode 100644
index a77b6760..00000000
--- a/Design & Experience/인지 평가 이론 (Cognitive Evaluation Theory).md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-C0AA85
-category: "[[10_Wiki/💡 Topics/Design & Experience]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - 인지 평가 이론 (Cognitive Evaluation Theory)"
----
-
-# [[인지 평가 이론 (Cognitive Evaluation Theory)]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Design & Experience 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/인지 평가 이론 (Cognitive Evaluation Theory).md]]
----
diff --git a/Design & Experience/인터페이스 (Interface).md b/Design & Experience/인터페이스 (Interface).md
deleted file mode 100644
index 277757f3..00000000
--- a/Design & Experience/인터페이스 (Interface).md	
+++ /dev/null
@@ -1,30 +0,0 @@
----
-id: P-REINFORCE-AUTO-DEED85
-category: "[[10_Wiki/💡 Topics/Design & Experience]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - 인터페이스 (Interface)"
----
-
-# [[인터페이스 (Interface)]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> TypeScript에서 인터페이스(Interface)는 객체의 형태(Shape)를 정의하고 내부 및 외부 코드 간의 계약(Contract)을 명시하는 구조적 타이핑(Structural Typing) 도구입니다 [1, 2]. 선택적 속성(Optional)과 읽기 전용 속성(Readonly) 등을 통해 유연하면서도 안전한 데이터 구조를 모델링할 수 있습니다 [2-4]. Type Alias와 비교할 때 캐싱 및 평탄화를 통해 컴파일 성능상 이점을 제공하며, 선언 병합(Declaration Merging)이라는 고유한 확장 기능을 갖추고 있습니다 [5-7].
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Design & Experience 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[Type Alias]], [[구조적 타이핑 (Structural Typing)]], [[선언 병합 (Declaration Merging)]], [[Interface Segregation Principle (ISP)]], [[객체 타입 (Object Types)]]
-- **Projects/Contexts:** [[대규모 TypeScript 애플리케이션 아키텍처 설계]], [[라이브러리 타입 선언 (d.ts) 확장]]
-- **Contradictions/Notes:** 인터페이스의 핵심 기능 중 하나인 '선언 병합'에 대하여, 라이브러리 확장을 위해서는 매우 유용하다는 주장이 있지만, 일반적인 애플리케이션 코드베이스에서는 의도치 않게 호환되지 않는 필드가 병합되어 버그를 유발할 수 있으므로 병합 기능이 없는 `type` 사용을 선호하는 개발자들도 다수 존재합니다 [14, 19-22].
-
----
-*Last updated: 2026-04-18*
-- Raw Source: [[00_Raw/2026-04-20/인터페이스 (Interface).md]]
----
diff --git a/Design & Experience/인터페이스 분리 원칙 (Interface Segregation Principle).md b/Design & Experience/인터페이스 분리 원칙 (Interface Segregation Principle).md
deleted file mode 100644
index b810b720..00000000
--- a/Design & Experience/인터페이스 분리 원칙 (Interface Segregation Principle).md	
+++ /dev/null
@@ -1,35 +0,0 @@
----
-id: P-REINFORCE-AUTO-FD8793
-category: "[[10_Wiki/💡 Topics/Design & Experience]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - 인터페이스 분리 원칙 (Interface Segregation Principle)"
----
-
-# [[인터페이스 분리 원칙 (Interface Segregation Principle)]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 인터페이스 분리 원칙(ISP)은 객체 지향 프로그래밍(OOP)을 위한 5가지 기본 설계 원칙인 SOLID 중 하나로, 로버트 C. 마틴(Robert C. Martin)에 의해 정립되었습니다 [1-3]. 이 원칙은 클라이언트가 자신이 사용하지 않는 인터페이스에 의존하도록 강요받아서는 안 된다는 것을 핵심으로 합니다 [2, 4]. 이를 달성하기 위해 하나의 크고 범용적인 인터페이스 대신, 작고 구체적이며 특화된 인터페이스를 여러 개 설계하는 것을 권장합니다 [2, 4].
-
-## 📖 구조화된 지식 (Synthesized Content)
-* **핵심 개념 및 구현 방식:** 
-  인터페이스 분리 원칙은 클라이언트가 자신의 목적을 달성하는 데 꼭 필요한 메서드만 사용해야 함을 의미합니다 [4]. 이를 구현하기 위해 개발자는 다목적의 큰 인터페이스를 구축하는 것을 지양하고, 대신 역할이 제한된 작고 구체적인 전문 인터페이스를 여러 개 생성해야 합니다 [2, 4].
-* **시스템 설계에서의 기대 효과:** 
-  클라이언트가 불필요한 인터페이스에 의존하지 않게 함으로써, 코드 변경 시 발생할 수 있는 파급 효과(effects of changes)를 최소화하고 시스템의 유연성을 크게 높일 수 있습니다 [4]. 궁극적으로 이 원칙은 더 모듈화되고 느슨하게 결합된(loosely coupled) 시스템을 설계하는 데 직접적으로 기여합니다 [3].
-* **관심사의 분리(SoC)와의 관계:** 
-  소프트웨어 개발의 가장 기본적이고 핵심적인 원칙 중 하나인 '관심사의 분리(Separation of Concerns, SoC)' 개념에서 직접적으로 파생된 두 가지 SOLID 원칙 중 하나가 바로 인터페이스 분리 원칙(나머지 하나는 단일 책임 원칙)입니다 [5-7]. 이는 복잡한 시스템을 관리 가능하게 분해하고 모듈성을 향상시키는 데 있어 해당 원칙이 얼마나 중요한지를 보여줍니다 [6, 7].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Design & Experience 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[SOLID Principles]], [[Separation of Concerns (SoC)]], [[Object-Oriented Programming (OOP)]]
-- **Projects/Contexts:** [[Clean Architecture]], [[Software System Design]]
-- **Contradictions/Notes:** 주어진 소스 내에서 인터페이스 분리 원칙에 대한 모순된 주장은 발견되지 않으며, 모든 소스가 이 원칙이 관심사의 분리(SoC) 개념에 뿌리를 두고 있으며 모듈성과 시스템 유연성을 향상시킨다는 점에 동의하고 있습니다.
-
----
-*Last updated: 2026-04-18*
-- Raw Source: [[00_Raw/2026-04-20/인터페이스 분리 원칙 (Interface Segregation Principle).md]]
----
diff --git a/Design & Experience/자기 효능감 (Self-Efficacy).md b/Design & Experience/자기 효능감 (Self-Efficacy).md
deleted file mode 100644
index b2576745..00000000
--- a/Design & Experience/자기 효능감 (Self-Efficacy).md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-43FFC2
-category: "[[10_Wiki/💡 Topics/Design & Experience]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - 자기 효능감 (Self-Efficacy)"
----
-
-# [[자기 효능감 (Self-Efficacy)]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Design & Experience 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/자기 효능감 (Self-Efficacy).md]]
----
diff --git a/Design & Experience/자기 효능감(Self-Efficacy).md b/Design & Experience/자기 효능감(Self-Efficacy).md
deleted file mode 100644
index a8a212ae..00000000
--- a/Design & Experience/자기 효능감(Self-Efficacy).md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-C2A5ED
-category: "[[10_Wiki/💡 Topics/Design & Experience]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - 자기 효능감(Self-Efficacy)"
----
-
-# [[자기 효능감(Self-Efficacy)]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Design & Experience 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/자기 효능감(Self-Efficacy).md]]
----
diff --git a/Design & Experience/자기조절학습(Self-Regulated Learning).md b/Design & Experience/자기조절학습(Self-Regulated Learning).md
deleted file mode 100644
index 8b90da51..00000000
--- a/Design & Experience/자기조절학습(Self-Regulated Learning).md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-282D40
-category: "[[10_Wiki/💡 Topics/Design & Experience]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - 자기조절학습(Self-Regulated Learning)"
----
-
-# [[자기조절학습(Self-Regulated Learning)]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Design & Experience 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/자기조절학습(Self-Regulated Learning).md]]
----
diff --git a/Design & Experience/재조정 (Reconciliation).md b/Design & Experience/재조정 (Reconciliation).md
deleted file mode 100644
index 7248078f..00000000
--- a/Design & Experience/재조정 (Reconciliation).md	
+++ /dev/null
@@ -1,47 +0,0 @@
----
-id: P-REINFORCE-AUTO-EDDCE3
-category: "[[10_Wiki/💡 Topics/Design & Experience]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - 재조정 (Reconciliation)"
----
-
-# [[재조정 (Reconciliation)]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> React가 렌더링 시 새로운 가상 DOM(Virtual DOM) 트리와 이전 트리를 비교하여, 실제 DOM에 적용해야 할 최소한의 변경 사항만을 찾아내어 업데이트하는 $O(n)$ 복잡도의 핵심 디핑(Diffing) 알고리즘 프로세스입니다.
-
-## 📖 구조화된 지식 (Synthesized Content)
-**1. 재조정의 2단계 프로세스** React는 렌더링 중 실제 DOM을 직접 조작하지 않습니다. 대신 재조정은 두 가지 단계로 나뉘어 실행됩니다.
-
-- **렌더 단계 (Render Phase):** 컴포넌트를 호출하여 UI가 어떻게 보여야 하는지를 나타내는 새로운 가상 트리를 구축합니다.
-- **커밋 단계 (Commit Phase):** 이전 트리와의 비교(Diffing)를 통해 계산된 변경 사항만을 실제 DOM에 적용합니다.
-
-**2. 재조정의 3가지 핵심 규칙** React의 디핑 알고리즘은 예측 가능한 규칙에 따라 컴포넌트의 리렌더링 여부를 결정합니다.
-
-- **타입이 다른 요소:** 같은 위치에 다른 타입의 요소(`div`에서 `span` 등)가 들어오면, React는 이전 하위 트리를 완전히 파괴(언마운트)하고 새로운 트리를 처음부터 다시 구축합니다.
-- **Key를 통한 식별:** 배열이나 리스트 렌더링 시 고유한 `key`를 부여하면, 위치가 바뀌더라도 React가 `key`를 통해 기존 항목을 식별하여 불필요한 재생성 없이 효율적으로 재배치합니다.
-- **동일한 컴포넌트 타입:** 같은 타입의 컴포넌트가 동일한 위치에 유지되면, 컴포넌트 인스턴스와 내부 상태(State)는 그대로 보존된 채 변경된 프롭스(Props)만 업데이트됩니다.
-
-**3. 성능 오버헤드와 한계** 재조정은 일반적인 웹 애플리케이션에서는 매우 효율적이지만, 대규모 DOM 조작이나 고빈도 업데이트가 발생하는 게임 및 애니메이션 환경에서는 심각한 병목 현상을 유발합니다. 예를 들어 60FPS를 유지하기 위한 프레임 예산은 약 16.67ms인데, 약 3,000개의 노드를 가진 복잡한 뷰에서 상태 업데이트가 발생하면 이 트리 비교 연산에 CPU 자원이 크게 소모되어 프레임 레이트가 7 FPS 이하로 급락할 수 있습니다.
-
-**4. 최신 개선 사항 (React 19)** React 19에서는 재조정의 효율성을 높이기 위한 기능들이 강화되었습니다. `setTimeout`, 프로미스(Promises), 네이티브 이벤트 핸들러 등 모든 컨텍스트에서 **자동 배칭(Automatic Batching)**이 일관되게 적용되어 여러 상태 업데이트를 한 번의 리렌더링으로 묶어 처리합니다. 또한 동시성 렌더링(Concurrent Rendering) 기능이 향상되어, 백그라운드에서 실행되는 무거운 렌더링(저우선순위)을 잠시 중단하고 사용자의 타이핑과 같은 긴급한 고우선순위 업데이트를 즉각적으로 처리할 수 있게 되었습니다.
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Design & Experience 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[가상 DOM (Virtual DOM)]], [[React 동시성 기능 (Concurrent Features)]], [[불필요한 리렌더링 방지]], [[명령형 조작 (Imperative Manipulation)]]
-    
-- **Projects/Contexts:** [[고성능 실시간 상호작용 시스템을 위한 React 기반 게임 엔진 아키텍처]], [[대규모 데이터 렌더링 및 가상화 최적화]]
-    
-- **Contradictions/Notes:** 재조정 알고리즘은 선언적 UI 관리를 가능하게 하는 훌륭한 기능이지만 만능은 아닙니다. Three.js(R3F) 기반의 게임이나 대규모 애니메이션 환경처럼 매 프레임 수만 개의 좌표나 속성이 변하는 경우, React의 재조정 과정을 거치면 성능이 붕괴되므로 `useFrame` 등을 활용해 참조(Ref)의 속성을 직접 조작(Direct/Imperative Mutation)하여 재조정을 우회하는 기법이 반드시 필요합니다.
-    
-
----
-
-_Last updated: 2026-04-15_
-- Raw Source: [[00_Raw/2026-04-20/재조정 (Reconciliation).md]]
----
diff --git a/Design & Experience/조직 시민 행동 (OCB).md b/Design & Experience/조직 시민 행동 (OCB).md
deleted file mode 100644
index 8414062e..00000000
--- a/Design & Experience/조직 시민 행동 (OCB).md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-03634D
-category: "[[10_Wiki/💡 Topics/Design & Experience]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - 조직 시민 행동 (OCB)"
----
-
-# [[조직 시민 행동 (OCB)]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Design & Experience 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/조직 시민 행동 (OCB).md]]
----
diff --git a/Design & Experience/조직 행동론의 성과급 체계 분석.md b/Design & Experience/조직 행동론의 성과급 체계 분석.md
deleted file mode 100644
index a0750139..00000000
--- a/Design & Experience/조직 행동론의 성과급 체계 분석.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-6AFB3F
-category: "[[10_Wiki/💡 Topics/Design & Experience]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - 조직 행동론의 성과급 체계 분석"
----
-
-# [[조직 행동론의 성과급 체계 분석]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Design & Experience 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/조직 행동론의 성과급 체계 분석.md]]
----
diff --git a/Design & Experience/중독 의학 및 정신 병리학.md b/Design & Experience/중독 의학 및 정신 병리학.md
deleted file mode 100644
index d4e26051..00000000
--- a/Design & Experience/중독 의학 및 정신 병리학.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-E50291
-category: "[[10_Wiki/💡 Topics/Design & Experience]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - 중독 의학 및 정신 병리학"
----
-
-# [[중독 의학 및 정신 병리학]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Design & Experience 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/중독 의학 및 정신 병리학.md]]
----
diff --git a/Design & Experience/중독 재활 프로그램.md b/Design & Experience/중독 재활 프로그램.md
deleted file mode 100644
index 591be115..00000000
--- a/Design & Experience/중독 재활 프로그램.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-383266
-category: "[[10_Wiki/💡 Topics/Design & Experience]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - 중독 재활 프로그램"
----
-
-# [[중독 재활 프로그램]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Design & Experience 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/중독 재활 프로그램.md]]
----
diff --git a/Design & Experience/철벽 수비대_ - TypeScript 타입 시스템 (인터페이스 설계).md b/Design & Experience/철벽 수비대_ - TypeScript 타입 시스템 (인터페이스 설계).md
deleted file mode 100644
index 0a236630..00000000
--- a/Design & Experience/철벽 수비대_ - TypeScript 타입 시스템 (인터페이스 설계).md	
+++ /dev/null
@@ -1,43 +0,0 @@
----
-id: P-REINFORCE-AUTO-A8177A
-category: "[[10_Wiki/💡 Topics/Design & Experience]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - 철벽 수비대_ - TypeScript 타입 시스템 (인터페이스 설계)"
----
-
-# [[철벽 수비대_ - TypeScript 타입 시스템 (인터페이스 설계)]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> TypeScript의 타입 시스템은 구조적 타이핑(Structural Typing)을 기반으로 유연성을 제공하면서도, 런타임 에러와 예기치 않은 상태 변경으로부터 애플리케이션을 보호하는 아키텍처적 도구입니다. 견고한 수비 체계를 구축하기 위해서는 성능과 확장성을 고려하여 인터페이스(Interface)와 타입 별칭(Type Alias)을 전략적으로 선택해야 합니다. 또한, 불변성 보장, 식별 가능한 유니온, 브랜디드 타입 등 고급 설계 기법을 활용하여 외부의 불안정한 데이터와 내부의 예기치 않은 상태 변경으로부터 시스템을 안전하게 지켜낼 수 있습니다.
-
-## 📖 구조화된 지식 (Synthesized Content)
-* **구조적 타이핑과 과잉 속성 체크(Excess Property Checking)**
-  TypeScript는 객체의 구조가 일치하면 동일한 타입으로 간주하는 덕 타이핑(Duck Typing)을 따릅니다 [1]. 이로 인한 보안 허점을 막기 위해 과잉 속성 체크를 도입하여, 객체 리터럴이 직접 할당될 때 인터페이스에 정의되지 않은 속성이 포함되는 것을 컴파일 시점에 차단합니다 [2].
-
-* **인터페이스(Interface)와 타입 별칭(Type Alias)의 전략적 선택**
-  컴파일 성능 측면에서 인터페이스는 타입 관계를 캐싱하여 효율적인 반면, 타입 별칭의 교집합(&)은 매번 구조를 재계산하므로 핵심 도메인 모델에는 인터페이스가 유리합니다 [3]. 확장성 측면에서 인터페이스는 '선언 병합(Declaration Merging)'이 가능하여 라이브러리 확장에 유용하며, 타입 별칭은 동일한 이름 재선언이 불가해 더 엄격한 관리에 적합합니다 [3, 4]. 또한, 깊은 상속보다는 작은 단위의 인터페이스를 조합하는 '합성(Composition)' 방식이 시스템 결합도를 낮추어 변화에 강한 수비력을 제공합니다 [4].
-
-* **불변성(Immutability)의 확립**
-  `readonly` 수식어를 통해 컴파일 수준에서 객체와 배열의 수정을 금지하여 데이터의 무결성을 보장할 수 있습니다 [5]. 얕은 수준의 보호 한계를 극복하기 위해 매핑 타입(Mapped Types)과 조건부 타입(Conditional Types)을 결합한 재귀적 `DeepReadonly`를 구축하면, 트리 구조나 복잡한 중첩 데이터의 수정까지 완벽히 차단할 수 있습니다 [5, 6].
-
-* **식별 가능한 유니온(Discriminated Unions)과 완전성 검사**
-  공통된 리터럴 속성을 태그로 사용하여 타입을 좁히는(Narrowing) 기법으로 자동 완성과 타입 안전성을 극대화합니다 [7]. `never` 타입을 활용한 완전성 검사(Exhaustiveness Checking)는 새로운 상태가 유니온에 추가되었을 때 처리되지 않은 분기를 컴파일 에러로 찾아내어 시스템의 빈틈을 방어합니다 [7].
-
-* **명목적 타이핑의 수복과 경계면 수비**
-  의미적으로 다른 데이터(예: 이메일과 이름)가 혼용되는 것을 막기 위해, 컴파일 시점에만 존재하는 고유 속성을 부여하는 브랜디드 타입(Branded Types)을 사용하여 엄격한 격리를 보장할 수 있습니다 [8, 9]. 나아가 할당 과정에서 우회될 수 있는 과잉 속성 체크의 한계를 보완하기 위해 `satisfies` 연산자를 활용하면, 객체가 특정 타입을 만족하는지 검사하면서도 리터럴 타입의 구체성을 잃지 않고 예기치 않은 데이터 침투를 막아냅니다 [9, 10].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Design & Experience 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[구조적 타이핑 (Structural Typing)]], [[선언 병합 (Declaration Merging)]], [[식별 가능한 유니온 (Discriminated Unions)]], [[브랜디드 타입 (Branded Types)]], [[satisfies 연산자]]
-- **Projects/Contexts:** [[대규모 애플리케이션 개발]], [[도메인 기반 설계 (DDD)]]
-- **Contradictions/Notes:** 과잉 속성 체크(EPC)는 객체 리터럴을 직접 다룰 때만 활성화되어 간접 할당 시 우회될 수 있다는 취약점이 있으나, TypeScript 4.9부터 도입된 satisfies 연산자를 통해 이 문제를 해결하고 엄격한 속성 검사를 수행할 수 있습니다 [9, 10].
-
----
-*Last updated: 2026-04-18*
-- Raw Source: [[00_Raw/2026-04-20/철벽 수비대_ - TypeScript 타입 시스템 (인터페이스 설계).md]]
----
diff --git a/Design & Experience/치타 사람 이미지 프롬프트.md b/Design & Experience/치타 사람 이미지 프롬프트.md
deleted file mode 100644
index 5a528a9b..00000000
--- a/Design & Experience/치타 사람 이미지 프롬프트.md	
+++ /dev/null
@@ -1,34 +0,0 @@
----
-id: P-REINFORCE-AUTO-8EC391
-category: "[[10_Wiki/💡 Topics/Design & Experience]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - 치타 사람 이미지 프롬프트"
----
-
-# [[치타 사람 이미지 프롬프트]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 거대한 모래 치타의 추격을 받으며 사막을 질주하는 육상 선수를 통해 속도감과 자연의 힘을 초현실적으로 담아낸 시네마틱 컨셉 아트 프롬프트입니다.
-
-## 📖 구조화된 지식 (Synthesized Content)
-본 데이터는 입자 시뮬레이션(모래/먼지)과 로우 앵글의 24mm 광각 렌즈를 활용해 거대한 모래 괴물과 인간의 스케일 대비를 극대화하며, 의상 및 신발에 특정 스포츠 브랜드 로고를 자유롭게 커스터마이징할 수 있도록 설계된 하이엔드 광고용 시각 에셋입니다.
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Design & Experience 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[VFX Particle Simulation]], [[Cinematic Sports Advertising]], [[Surrealism Concept Art]]
-    
-- **Projects/Contexts:** [[Sportswear Brand Campaign Visuals]]
-    
-- **Contradictions/Notes:** 치타는 고체 형태의 동물이 아니라 수백만 개의 모래와 먼지로 이루어진 볼륨 시뮬레이션(Volumetric Simulation)이므로 경계면이 모래폭풍 속으로 자연스럽게 흩어지도록 연출 요망
-    
-
----
-
-_Last updated: 2026년 4월 14일_
-- Raw Source: [[00_Raw/2026-04-20/치타 사람 이미지 프롬프트.md]]
----
diff --git a/Design & Experience/컴포넌트 기반 웹 프레임워크 아키텍처 설계.md b/Design & Experience/컴포넌트 기반 웹 프레임워크 아키텍처 설계.md
deleted file mode 100644
index 0140dbb5..00000000
--- a/Design & Experience/컴포넌트 기반 웹 프레임워크 아키텍처 설계.md	
+++ /dev/null
@@ -1,38 +0,0 @@
----
-id: P-REINFORCE-AUTO-F36267
-category: "[[10_Wiki/💡 Topics/Design & Experience]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - 컴포넌트 기반 웹 프레임워크 아키텍처 설계"
----
-
-# [[컴포넌트 기반 웹 프레임워크 아키텍처 설계]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 컴포넌트 기반 웹 프레임워크 아키텍처는 특정 기능이나 UI 요소를 구현하기 위해 HTML 구조, CSS 스타일, JavaScript 동작을 하나의 단위(컴포넌트)로 묶어 다루는 설계 방식입니다 [1]. 과거 기술적 역할 중심의 분리에서 벗어나 기능 중심의 수직적 모듈화를 통해 코드의 재사용성을 높이고 독립적인 개발과 테스트를 가능하게 합니다 [1, 2]. 프로젝트 규모가 커짐에 따라 발생하는 결합도 증가와 컴포넌트 비대화 문제를 해결하기 위해, 현대에는 마이크로 프론트엔드 및 FSD(Feature-Sliced Design)와 같은 발전된 아키텍처 방법론과 결합되어 사용됩니다 [3-5].
-
-## 📖 구조화된 지식 (Synthesized Content)
-- **웹 패러다임의 변화와 컴포넌트의 등장:** 초기 웹 개발은 HTML(구조), CSS(표현), JS(동작)로 기술적 역할을 나누는 수평적 관심사 분리 방식을 사용했습니다 [6, 7]. 하지만 웹 프레임워크의 발전과 함께 이들을 하나의 기능 단위로 묶는 '컴포넌트' 패러다임이 등장했습니다 [1]. 이는 기존 계층구조를 수직으로 관통하며 기능 중심의 모듈화를 이끌었고, 개발 생산성과 유지보수성을 크게 향상시켰습니다 [2].
-- **컴포넌트 아키텍처의 한계와 결합도 문제:** 컴포넌트 구조는 만능이 아니었으며, 대규모 프로젝트에서는 하위 컴포넌트로 데이터를 단순히 전달하기 위해 불필요한 속성(props)을 여러 단계에 걸쳐 통과시켜야 하는 'Props drilling' 문제로 인해 결합도가 높아지는 한계에 직면했습니다 [8]. 또한, 하나의 컴포넌트 안에 데이터 관리, 표현, 비즈니스 로직 등 너무 많은 책임이 집중되어 단일 책임 원칙(SRP)을 위반하는 '컴포넌트 비대화' 현상이 발생했습니다 [4].
-- **계층적 관심사의 재도입과 발전:** 컴포넌트의 한계를 극복하기 위해 프론트엔드 아키텍처는 컴포넌트 내부에서 다시 계층적 관심사를 분리하는 방향으로 진화했습니다 [9].
-  - **UI 계층 구조화:** Atomic Design Pattern 등을 도입하여 UI 컴포넌트의 계층을 세밀하게 분리하고 역할을 분명히 했습니다 [10].
-  - **단방향 의존성 구축:** CSS-in-JS, CSS Modules 등을 통해 CSS가 HTML 구조와 JavaScript 논리를 따라가도록 단방향 의존성(데이터 → 화면)을 만들었습니다 [11, 12].
-  - **상태 관리 및 비즈니스 로직 분리:** 뷰(화면)와 데이터 로직을 분리하고, 비동기 통신이나 캐싱과 같은 서버 상태 관리를 별도의 계층으로 위임하여 컴포넌트는 화면을 그리고 이벤트를 받는 역할에만 집중하도록 설계했습니다 [12-14].
-- **대규모 확장을 위한 FSD와 마이크로 프론트엔드:**
-  - **Feature-Sliced Design (FSD):** 프로젝트가 거대해지면 전통적인 역할별 폴더 구조(/components, /api 등)만으로는 복잡성을 감당하기 어렵습니다 [5, 15]. FSD 아키텍처는 기능을 기준으로 코드를 분리하여 하나의 기능 단위에 필요한 모든 파일을 같은 폴더에 모아 관리함으로써 모듈 간 결합도를 줄이고 독립성을 높입니다 [5, 16].
-  - **마이크로 프론트엔드 (Micro Frontends):** 거대한 단일 프론트엔드(Frontend Monolith)를 작고 독립적인 여러 조각으로 나누어 각 개발팀이 기술 스택에 구애받지 않고 자율적으로 개발 및 배포할 수 있게 하는 아키텍처입니다 [3, 17]. 런타임 통합, 웹 컴포넌트, 모듈 페더레이션, 라우트 기반 또는 컴포넌트 기반 합성 등의 방식을 활용해 어플리케이션을 조립합니다 [18, 19].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Design & Experience 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[관심사의 분리(Separation of Concerns)]], [[마이크로 프론트엔드(Micro Frontends)]], [[Feature-Sliced Design(FSD)]], [[단일 책임 원칙(SRP)]]
-- **Projects/Contexts:** [[Spotify, Netflix, Amazon의 마이크로 프론트엔드 도입]], [[대규모 웹 애플리케이션의 폴더 구조 진화]]
-- **Contradictions/Notes:** 컴포넌트 기반 아키텍처는 초기에 관심사 분리의 혁신으로 여겨졌으나, 점차 하나의 컴포넌트에 너무 많은 로직이 집중되며 독립성이 훼손되는 모순이 발생했습니다. 이를 해결하기 위해 기능 단위로 묶인 컴포넌트 내부에서 다시 데이터 로직과 뷰 로직의 역할을 나누는 계층적(Layer) 분리 방식이 재도입되었습니다 [4, 9, 12].
-
----
-*Last updated: 2026-04-18*
-- Raw Source: [[00_Raw/2026-04-20/컴포넌트 기반 웹 프레임워크 아키텍처 설계.md]]
----
diff --git a/Design & Experience/클린 아키텍처 (Clean Architecture).md b/Design & Experience/클린 아키텍처 (Clean Architecture).md
deleted file mode 100644
index e95b966e..00000000
--- a/Design & Experience/클린 아키텍처 (Clean Architecture).md	
+++ /dev/null
@@ -1,47 +0,0 @@
----
-id: P-REINFORCE-AUTO-0A3765
-category: "[[10_Wiki/💡 Topics/Design & Experience]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - 클린 아키텍처 (Clean Architecture)"
----
-
-# [[클린 아키텍처 (Clean Architecture)]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 클린 아키텍처는 로버트 C. 마틴(Uncle Bob)이 창안한 소프트웨어 설계 철학으로, 시스템을 '관심사의 분리(Separation of Concerns)' 원칙에 따라 명확한 계층으로 나누는 아키텍처 구조입니다 [1-3]. 이 아키텍처는 시스템의 핵심인 비즈니스 로직을 프레임워크, UI, 데이터베이스와 같은 외부 기술 요소로부터 완벽히 분리시켜 유지보수성, 확장성, 그리고 테스트 용이성을 극대화하는 것을 목표로 합니다 [1, 4, 5]. 핵심 원리는 소스 코드의 의존성이 오직 내부의 고수준 정책(비즈니스 로직)을 향하도록 통제하는 '의존성 규칙(Dependency Rule)'을 엄격히 준수하는 것입니다 [1, 6, 7].
-
-## 📖 구조화된 지식 (Synthesized Content)
-**1. "뇌와 팔다리의 분리" 메타포를 통한 관심사 분리의 구현**
-클린 아키텍처는 시스템을 '뇌(핵심 비즈니스 로직)'와 '팔다리(인프라스트럭처 및 외부 요소)'로 엄격하게 이분화하여 관심사의 분리(SoC)를 실현합니다 [8, 9]. 
-*   **뇌 (핵심 계층):** 도메인의 본질적인 규칙을 담고 있는 엔티티(Entities)와 이를 제어하는 유스케이스(Use Cases)로 구성됩니다 [9]. 뇌가 신체의 중심인 것처럼 이 계층은 외부 세계(DB, UI 등)에 대해 전혀 알지 못하는 가장 독립적이고 순수한 형태를 유지해야 합니다 [9, 10].
-*   **팔다리 (외부 계층):** 웹 인터페이스, 데이터베이스, 서드파티 프레임워크 등 핵심 로직을 감싸고 외부와 소통하는 저수준의 세부 사항입니다 [9, 11]. 팔다리는 언제든 다른 기술로 교체 가능하도록 시스템의 심장부에 '플러그인' 형태로 연결되어야 합니다 [9, 12].
-
-**2. 의존성 규칙 (Dependency Rule)**
-클린 아키텍처가 동작하게 하는 가장 핵심적인 규칙으로, 모든 소스 코드의 의존성은 반드시 바깥쪽(저수준 메커니즘)에서 안쪽(고수준 정책)으로만 향해야 합니다 [1, 6, 7]. 내부의 원에 속한 코드는 외부 원에 선언된 함수, 클래스, 변수 등 어떠한 것도 이름조차 언급해서는 안 되며, 외부의 데이터 형식에 의존해서도 안 됩니다 [7].
-
-**3. 4가지 주요 동심원 계층 구조**
-클린 아키텍처는 통상적으로 4가지 동심원 계층으로 소프트웨어를 구성합니다 [3, 7, 13].
-*   **엔티티 (Entities):** 전사적인 핵심 업무 규칙과 데이터를 캡슐화한 가장 안쪽의 중심 계층입니다 [3, 10, 13]. 외부의 무언가가 변경되더라도 가장 영향을 받지 않습니다 [10].
-*   **유스케이스 (Use Cases / Interactors):** 특정 애플리케이션에 특화된 업무 규칙을 포함하며, 엔티티로 들어오고 나가는 데이터 흐름을 조정합니다 [3, 13, 14].
-*   **인터페이스 어댑터 (Interface Adapters):** 유스케이스와 엔티티에 편리한 형식의 데이터를 외부 에이전시(DB, 웹 등)가 사용하기 편리한 형식으로 변환해 주는 어댑터(프레젠터, 뷰, 컨트롤러 등)들의 모임입니다 [3, 11, 13, 14].
-*   **프레임워크와 드라이버 (Frameworks & Drivers):** 데이터베이스, 웹 프레임워크, UI 등이 위치하는 가장 바깥쪽의 변동성이 큰 계층입니다 [3, 11, 13].
-
-**4. 클린 아키텍처의 주요 이점**
-*   **완벽한 격리 및 테스트 용이성:** 업무 규칙은 UI, 데이터베이스, 웹 서버 등의 외부 요소가 없어도 독립적으로 테스트할 수 있습니다 [4, 5, 15].
-*   **기술적 독립성 및 유연성:** 시스템은 특정 프레임워크에 종속되지 않으며, 외부 계층(팔다리)을 변경하더라도 내부 계층(뇌)의 핵심 기능은 아무런 영향을 받지 않기 때문에 기술 변화에 유연하게 대응할 수 있습니다 [4, 5, 15].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Design & Experience 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[관심사의 분리 (Separation of Concerns)]], [[의존성 역전 원칙 (Dependency Inversion Principle)]], [[단일 책임 원칙 (Single Responsibility Principle)]]
-- **Projects/Contexts:** [[웹 애플리케이션의 3계층 구조]], [[도메인 주도 설계 (DDD)]], [[넷플릭스의 코스모스 플랫폼 및 마이크로서비스 전환]]
-- **Contradictions/Notes:** 소스에 따르면 클린 아키텍처는 유지보수성과 확장성을 비약적으로 높여주지만, 초기 개발 시간이 증가하고 계층과 추상화가 너무 많아질 경우 시스템 구조가 지나치게 복잡해지는 오버엔지니어링(Over-Engineering) 및 간접 참조에 의한 가독성 저하를 유발할 수 있습니다 [16, 17]. 따라서 과도한 추상화를 경계하고, 실용적 필요에 맞게 응집도와 결합도를 고려하여 아키텍처의 균형을 맞추는 것이 중요합니다 [16, 18].
-
----
-*Last updated: 2026-04-18*
-- Raw Source: [[00_Raw/2026-04-20/클린 아키텍처 (Clean Architecture).md]]
----
diff --git a/Design & Experience/클린 아키텍처(Clean Architecture).md b/Design & Experience/클린 아키텍처(Clean Architecture).md
deleted file mode 100644
index 8cee9904..00000000
--- a/Design & Experience/클린 아키텍처(Clean Architecture).md	
+++ /dev/null
@@ -1,48 +0,0 @@
----
-id: P-REINFORCE-AUTO-2298F3
-category: "[[10_Wiki/💡 Topics/Design & Experience]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - 클린 아키텍처(Clean Architecture)"
----
-
-# [[클린 아키텍처(Clean Architecture)]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> **클린 아키텍처(Clean Architecture)**는 로버트 C. 마틴(Robert C. Martin, "Uncle Bob")이 대중화한 소프트웨어 설계 철학으로, 비즈니스 로직과 애플리케이션 규칙을 시스템의 중심에 두어 코드의 품질을 높이는 것을 목표로 합니다 [1], [2]. 이 접근 방식은 시스템을 각기 다른 책임을 지는 여러 동심원 계층으로 분리하여 **관심사의 분리(Separation of Concerns)**를 촉진합니다 [1], [3]. 핵심 원칙인 **'의존성 규칙(Dependency Rule)'**을 강제하여 소스 코드 의존성이 오직 내부로만 향하게 함으로써 프레임워크, UI, 데이터베이스 등의 외부 요소로부터 독립적이고, 유지보수성, 확장성 및 테스트 용이성이 뛰어난 시스템을 구축할 수 있습니다 [1], [4], [5], [6].
-
-## 📖 구조화된 지식 (Synthesized Content)
-*   **주요 설계 원칙**
-    *   **의존성 규칙 (Dependency Rule):** 소스 코드 의존성은 반드시 외부 계층에서 내부 계층(고수준 정책 방향)으로만 향해야 합니다 [1], [7], [6]. 내부 원에 속한 코드는 외부에 선언된 어떤 것(함수, 클래스, 변수 등)에 대해서도 알아서는 안 됩니다 [6].
-    *   **독립성:** 시스템은 특정 프레임워크나 데이터베이스, UI, 그리고 기타 외부 에이전시에 종속되지 않고 독립적으로 동작해야 합니다 [1], [4], [5], [6].
-    *   **테스트 용이성 (Testability):** 아키텍처의 중심에 있는 핵심 비즈니스 규칙은 UI, 데이터베이스, 웹 서버 등의 외부 환경 없이도 격리된 상태에서 독립적으로 테스트할 수 있어야 합니다 [8], [4], [7], [6].
-
-*   **클린 아키텍처의 4가지 주요 계층**
-    *   **엔티티 (Entities):** 가장 안쪽 계층으로 전사적인 핵심 업무 규칙이나 데이터 구조를 캡슐화합니다 [9], [10], [11]. 프레임워크나 데이터베이스에 의존하지 않는 순수한 객체로, 외부의 변경(UI, 보안 등)에 의해 영향을 받지 않습니다 [12], [11].
-    *   **유스케이스 (Use Cases):** 애플리케이션에 특화된 비즈니스 규칙을 구현하며, 엔티티로 들어오고 나가는 데이터 흐름을 조정합니다 [9], [10], [13]. 데이터베이스나 UI 등 외부 요소의 변경으로부터 격리되어 있습니다 [13].
-    *   **인터페이스 어댑터 (Interface Adapters):** 유스케이스나 엔티티에서 사용하기 편리한 데이터 형식을 웹, UI, 또는 데이터베이스 같은 외부 에이전시에게 편리한 형식으로 변환하는 역할을 합니다 [9], [10], [13]. GUI의 MVC 구조에서 프레젠터(Presenter), 뷰(View), 컨트롤러(Controller)와 데이터베이스 게이트웨이가 이 계층에 속합니다 [9], [13], [14].
-    *   **프레임워크와 드라이버 (Frameworks & Drivers):** 가장 바깥쪽 계층으로 데이터베이스, 웹 프레임워크, UI 시스템 등 변동성이 크고 시스템의 구체적인 세부 사항들이 위치하는 곳입니다 [9], [10], [15].
-
-*   **경계 횡단 (Crossing Boundaries) 및 데이터 전달**
-    *   제어 흐름과 의존성의 방향이 반대가 되는 상황에서는 **의존성 역전 원칙(DIP)**과 동적 다형성을 사용하여 소스 코드 의존성이 내부를 향하도록 만들어야 합니다 [16], [8], [17]. (예를 들어, 유스케이스가 직접 프레젠터를 호출하지 않고, 내부의 인터페이스를 호출하면 외부의 프레젠터가 이를 구현하도록 함) [17].
-    *   계층 경계를 가로지르는 데이터는 DTO(Data Transfer Object)와 같이 캡슐화 및 격리된 매우 단순한 데이터 구조를 가져야만 의존성 규칙을 위배하지 않습니다 [18].
-
-*   **도입 시 도전 과제 및 해결책**
-    *   **과엔지니어링(Over-Engineering) 및 초기 비용:** 클린 아키텍처의 여러 계층과 추상화를 도입하면 시스템이 장황해지고 초기 개발 시간이 길어질 수 있습니다 [19]. 
-    *   **해결책:** 소프트웨어 개발에 실질적인 이점이 있을 때만 레이어와 추상화를 추가하는 실용적인 접근(Pragmatism)이 필요하며, 점진적인 도입을 통해 레거시 코드를 개선하는 것이 좋습니다 [19], [20].
-    *   **테스트의 복잡성:** 여러 계층을 테스트하는 것은 까다로울 수 있으므로 목(Mock) 객체를 생성하여 독립적인 컴포넌트의 동작에 초점을 맞추는 것이 권장됩니다 [19].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Design & Experience 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[관심사의 분리(Separation of Concerns)]], [[의존성 역전 원칙(Dependency Inversion Principle)]], [[SOLID 원칙(SOLID Principles)]]
-- **Projects/Contexts:** [[안드로이드 애플리케이션(Android Applications)]], [[iOS 애플리케이션의 VIPER 패턴(VIPER Architecture)]], [[ASP.NET Core 애플리케이션]], [[넷플릭스 마이크로서비스(Netflix Microservices)]]
-- **Contradictions/Notes:** 소스 출처 "Complete Guide to Clean Architecture - GeeksforGeeks"는 클린 아키텍처가 시스템의 장기적인 유지보수성, 테스트 가능성, 유연성을 제공한다고 강조하지만, 동시에 도입 초기에는 여러 추상화 계층을 구축해야 하므로 초기 개발 시간이 증가하고 오버엔지니어링(Over-Engineering)에 빠질 위험이 있다고 지적합니다. 따라서 실용적인 관점과의 균형 유지가 필수적입니다 [21], [19].
-
----
-*Last updated: 2026-04-18*
-- Raw Source: [[00_Raw/2026-04-20/클린 아키텍처(Clean Architecture).md]]
----
diff --git a/Design & Experience/클린 아키텍처.md b/Design & Experience/클린 아키텍처.md
deleted file mode 100644
index 9d4a9fab..00000000
--- a/Design & Experience/클린 아키텍처.md	
+++ /dev/null
@@ -1,47 +0,0 @@
----
-id: P-REINFORCE-AUTO-417677
-category: "[[10_Wiki/💡 Topics/Design & Experience]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - 클린 아키텍처"
----
-
-# [[클린 아키텍처]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 클린 아키텍처(Clean Architecture)는 로버트 C. 마틴(Robert C. Martin)이 제안한 소프트웨어 설계 철학으로, 비즈니스 로직과 애플리케이션 규칙을 시스템의 중심에 배치하는 구조를 갖습니다 [1, 2]. 소프트웨어를 여러 동심원 계층으로 분리하여 관심사를 철저히 분리하며, 프레임워크, 사용자 인터페이스(UI), 데이터베이스 등 외부 요소로부터 시스템을 완전히 독립시키는 것을 목표로 합니다 [1, 3-5]. 이 아키텍처의 핵심은 소스 코드의 의존성이 오직 내부의 고수준 정책만을 향해야 한다는 '의존성 규칙(Dependency Rule)'입니다 [1, 5, 6]. 이를 통해 시스템은 프레임워크나 외부 에이전시의 변경에 영향을 받지 않으며, 유지보수성, 확장성, 그리고 테스트 용이성을 극대화할 수 있습니다 [5, 7, 8].
-
-## 📖 구조화된 지식 (Synthesized Content)
-*   **핵심 목적과 이점:** 클린 아키텍처의 주된 목적은 관심사의 분리(Separation of Concerns)를 통해 시스템을 모듈화하고, 프레임워크, UI, 데이터베이스로부터 독립적인 시스템을 만드는 것입니다 [3-5]. 이를 통해 개발자는 외부 요소의 개입 없이 핵심 비즈니스 로직을 격리하여 단위 테스트를 수행할 수 있으며(Testability), 시스템의 생명주기를 늘리고 새로운 요구사항에 유연하게 대응할 수 있는 확장성(Scalability) 및 유지보수성(Maintainability)을 확보할 수 있습니다 [3, 5, 8].
-
-*   **동심원 계층 구조:** 클린 아키텍처는 보통 4가지의 계층으로 시스템을 나눕니다 [9, 10].
-    *   **엔티티 (Entities):** 시스템의 가장 안쪽에 위치하며, 전사적이고 가장 일반적인 핵심 업무 규칙을 캡슐화합니다 [9-11]. 페이지 네비게이션이나 보안 등 외부의 변경 사항에 절대 영향을 받지 않아야 합니다 [11].
-    *   **유스케이스 (Use Cases):** 애플리케이션에 특화된 업무 규칙을 포함하며, 엔티티로 들어가고 나가는 데이터의 흐름을 조정합니다 [9, 10, 12].
-    *   **인터페이스 어댑터 (Interface Adapters):** 유스케이스나 엔티티에게 편리한 데이터 형식을 데이터베이스나 웹 같은 외부 에이전시가 이용하기 편리한 형식으로 변환하는 어댑터 역할을 합니다 [9, 10, 12]. 프레젠터(Presenter), 뷰(View), 컨트롤러(Controller) 등의 MVC 구조가 이곳에 속합니다 [9, 12].
-    *   **프레임워크와 드라이버 (Frameworks & Drivers):** 가장 바깥쪽 계층으로, 데이터베이스, 웹 프레임워크, UI 등 변동성이 매우 큰 외부 도구들로 구성됩니다 [9, 10, 13].
-
-*   **핵심 설계 원칙:**
-    *   **의존성 규칙 (Dependency Rule):** 소스 코드의 의존성은 반드시 바깥쪽에서 안쪽으로, 즉 고수준의 정책(비즈니스 로직)을 향해야 합니다 [1, 5, 6]. 내부 원의 코드는 외부 원에 선언된 어떤 요소(함수, 클래스, 변수 등)의 이름도 언급해서는 안 됩니다 [5].
-    *   **의존성 역전 원칙 (DIP) 활용:** 제어 흐름이 내부에서 외부로 향해야 할 때는 의존성 역전 원칙을 사용하여 소스 코드 의존성이 제어 흐름과 반대 방향이 되도록 만듭니다 [14, 15]. 예를 들어 유스케이스가 프레젠터를 호출해야 할 경우, 직접 호출하는 대신 내부 원의 인터페이스를 호출하고 외부 원의 프레젠터가 이를 구현하도록 합니다 [15].
-    *   **경계를 횡단하는 데이터:** 계층의 경계를 가로지르는 데이터는 엔티티나 데이터베이스의 행(Row)이 아닌, 격리되고 단순한 데이터 구조(DTO 등)여야 합니다 [16, 17]. 
-
-*   **적용 시의 과제 및 한계:** 
-    클린 아키텍처는 유지보수성과 유연성을 가져오지만, 다수의 계층과 추상화를 도입해야 하므로 초기 개발 시간이 늘어나고 시스템이 불필요하게 복잡해지는 오버 엔지니어링(Over-Engineering)을 유발할 수 있습니다 [18]. 또한, 여러 계층 간의 상호작용으로 인해 통합 테스트의 복잡성이 증가할 수 있습니다 [18]. 
-
-*   **실제 적용 사례:**
-    클린 아키텍처의 원칙은 구글이 권장하는 Android 애플리케이션 아키텍처, iOS의 VIPER 아키텍처, ASP.NET Core 웹 애플리케이션, 그리고 Netflix의 마이크로서비스 설계 등 다양한 플랫폼과 환경에서 실질적으로 적용되어 견고한 시스템 구축에 기여하고 있습니다 [19-21].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Design & Experience 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[관심사의 분리]], [[의존성 규칙]], [[의존성 역전 원칙]], [[SOLID 원칙]]
-- **Projects/Contexts:** [[Netflix 마이크로서비스]], [[Android 애플리케이션 아키텍처]], [[VIPER 아키텍처]]
-- **Contradictions/Notes:** 클린 아키텍처는 시스템의 유지보수성과 유연성을 극대화하지만, 동시에 여러 계층과 추상화의 추가로 인해 초기 개발 시간이 늘어나고 구조가 복잡해지는 '오버 엔지니어링'의 위험을 동반하므로 실용성과의 적절한 균형이 필요하다는 점을 주의해야 합니다 [18].
-
----
-*Last updated: 2026-04-18*
-- Raw Source: [[00_Raw/2026-04-20/클린 아키텍처.md]]
----
diff --git a/Design & Experience/타입 가드 (Type Guards).md b/Design & Experience/타입 가드 (Type Guards).md
deleted file mode 100644
index bde41260..00000000
--- a/Design & Experience/타입 가드 (Type Guards).md	
+++ /dev/null
@@ -1,41 +0,0 @@
----
-id: P-REINFORCE-AUTO-5D0418
-category: "[[10_Wiki/💡 Topics/Design & Experience]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - 타입 가드 (Type Guards)"
----
-
-# [[타입 가드 (Type Guards)]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 타입 가드(Type Guards)는 TypeScript에서 `unknown` 변수나 유니온(Union) 타입 변수의 실제 타입을 안전하게 판별하고 확신할 수 있게 해주는 기법입니다 [1, 2]. 이를 통해 TypeScript의 제어 흐름 분석(Control Flow Analysis)이 실행되어, 특정 조건문 블록 내에서 변수의 가능한 타입을 좁혀(Narrowing) 안전하게 속성에 접근할 수 있도록 돕습니다 [2, 3].
-
-## 📖 구조화된 지식 (Synthesized Content)
-- **기본 타입 가드 (Built-in Type Guards):**
-  - **`typeof` 검사:** `typeof v === "typename"` ("number", "string", "boolean", "symbol" 등)과 같은 형태를 평가하여 TypeScript가 해당 스코프 내에서 타입을 자동으로 좁힙니다 [2, 3].
-  - **`instanceof` 검사:** 우변에 생성자 함수를 두어 해당 객체가 특정 프로토타입에 속하는지 확인하고 타입을 좁힙니다 [2, 3].
-  - **`in` 연산자 및 동등성 검사:** 객체 내 특정 속성의 존재 여부(`in`)나 값의 동등성을 검사하여 타입을 좁히는 데 활용할 수 있습니다 [3, 4].
-
-- **사용자 정의 타입 가드 (Custom Type Guards / Type Predicates):**
-  - 일반 함수와 유사하지만, 반환 타입에 `is` 키워드를 사용하는 특수한 구문(예: `pet is Fish`, `value is Positive`)을 갖는 함수를 정의할 수 있습니다 [2, 5].
-  - 이러한 함수(타입 서술어)가 런타임에 참(true)을 반환하면, TypeScript 타입 시스템은 조건문 내부에서 해당 파라미터가 명시된 타입이라고 인지하고 타입을 좁힙니다 [2, 5].
-  - **주의점:** TypeScript는 타입 서술어 함수의 내부 로직이 실제로 해당 타입의 의도를 정확히 따르는지 검증하지 않습니다 [5]. 따라서 코드를 작성하는 개발자가 로직의 정확성을 전적으로 책임져야 하며, 잘못 작성될 경우 `as` 단언문(assertion)보다 크게 더 안전하지 않을 수 있습니다 [5].
-
-- **사용 목적:**
-  - `unknown` 타입의 데이터를 다루거나, 여러 타입이 섞인 유니온 타입(Union Types)을 처리할 때 반복적인 타입 단언(Type Assertions)을 피하고 예측 가능한 코드를 작성하기 위해 사용됩니다 [1, 2].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Design & Experience 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[Type Narrowing]], [[Union Types]], [[Type Predicates]], [[unknown type]]
-- **Projects/Contexts:** [[외부 API의 불확실한(unknown) 데이터 검증 로직]], [[복잡한 유니온 타입 분기 처리]]
-- **Contradictions/Notes:** 사용자 정의 타입 가드는 타입 좁히기에 매우 유용하지만, TypeScript가 내부 판별 로직의 논리적 오류를 잡아주지 못하기 때문에 개발자의 부주의로 인해 타입 안정성이 훼손될 위험이 존재합니다 [5].
-
----
-*Last updated: 2026-04-18*
-- Raw Source: [[00_Raw/2026-04-20/타입 가드 (Type Guards).md]]
----
diff --git a/Design & Experience/타입 별칭 (Type Alias).md b/Design & Experience/타입 별칭 (Type Alias).md
deleted file mode 100644
index d7fdcd1f..00000000
--- a/Design & Experience/타입 별칭 (Type Alias).md	
+++ /dev/null
@@ -1,42 +0,0 @@
----
-id: P-REINFORCE-AUTO-37A8A8
-category: "[[10_Wiki/💡 Topics/Design & Experience]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - 타입 별칭 (Type Alias)"
----
-
-# [[타입 별칭 (Type Alias)]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 타입 별칭(Type Alias)은 TypeScript에서 기존 타입에 새로운 이름을 부여하여 재사용성을 높이는 기능입니다 [1]. 인터페이스(Interface)와 유사하게 객체의 형태를 정의하는 데 사용할 수 있으며, 그 외에도 원시 타입(Primitives), 유니온(Union), 튜플(Tuple) 및 기타 복잡한 타입 조합을 명명할 수 있는 폭넓은 표현력을 갖습니다 [1]. 인터페이스와 달리 선언 병합(Declaration Merging)을 허용하지 않아, 동일한 이름으로 재선언 시 에러를 발생시킴으로써 더 엄격한 타입 관리를 가능하게 합니다 [2, 3].
-
-## 📖 구조화된 지식 (Synthesized Content)
-* **유연한 타입 표현력**
-  타입 별칭은 단순히 객체의 형태를 정의하는 것을 넘어 유니온 타입, 교집합(Intersection), 매핑된 타입(Mapped Types), 조건부 타입(Conditional Types) 등 복잡한 타입 구성을 표현하는 데 매우 적합합니다 [1, 4, 5]. 값이 특정 원시 타입이거나 튜플, 혹은 `Record<string, unknown>`과 같은 특수한 유틸리티 타입일 때 이를 간결하게 명명하는 역할을 수행합니다 [1, 6].
-
-* **인터페이스(Interface)와의 구조적 차이**
-  타입 별칭은 인터페이스와 목적이 겹치는 부분이 많으나 핵심적인 차이가 존재합니다. 가장 큰 차이는 **선언 병합(Declaration Merging)**의 지원 여부입니다. 인터페이스는 동일한 이름으로 여러 번 선언하면 자동으로 하나로 병합되지만, 타입 별칭은 동일한 이름을 재선언하면 컴파일 에러를 반환합니다 [2, 3]. 이 특성 때문에 외부에서 확장해야 하는 라이브러리 코드에는 인터페이스가 유리하지만, 예기치 않은 타입 확장을 막아야 하는 애플리케이션 수준의 비즈니스 로직에는 타입 별칭이 더 안전한 선택이 될 수 있습니다 [2, 3, 7].
-
-* **컴파일 성능 및 동작 방식**
-  TypeScript 컴파일러는 인터페이스를 처리할 때 해당 이름을 기준으로 평탄화된 단일 객체 타입을 만들고 타입 관계를 캐싱합니다 [8, 9]. 반면, 타입 별칭을 통한 교집합 타입(`&`)은 참조될 때마다 매번 속성을 재귀적으로 병합하고 충돌을 확인해야 하므로 대규모 프로젝트에서는 컴파일 성능 저하의 원인이 될 수 있습니다 [8, 9]. 따라서 TypeScript 성능 가이드에서는 가능하면 교집합보다는 인터페이스 상속(extends)을 사용할 것을 권장하고 있습니다 [8, 10]. 
-
-* **실무적 사용 전략**
-  이러한 특성들로 인해, 개발자들 사이에서는 어떤 것을 기본으로 사용할지에 대한 논쟁과 다양한 전략이 존재합니다 [11, 12]. 
-  - **이원화 전략**: 확장 지점이 필요한 외부와의 계약(Contract)이나 다형성을 띠는 도메인 모델에는 인터페이스를 사용하고, 확장이 필요 없는 내부 비즈니스 로직이나 단순 형태 선언에는 타입 별칭을 사용하는 전략입니다 [3, 13].
-  - **단일화 전략**: 팀 내 혼란("이 경우에는 어떤 걸 써야 하지?")을 방지하기 위해 더 다채로운 표현이 가능하고 선언 병합의 부작용이 없는 타입 별칭만으로 코드베이스를 통일하는 팀도 다수 존재합니다 [4, 6, 14].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Design & Experience 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[인터페이스 (Interface)]], [[유니온 타입 (Union Types)]], [[구조적 타이핑 (Structural Typing)]], [[선언 병합 (Declaration Merging)]]
-- **Projects/Contexts:** [[대규모 TypeScript 프로젝트의 컴파일 성능 최적화]], [[견고한 도메인 모델 및 API 계약 설계]]
-- **Contradictions/Notes:** TypeScript 핸드북 및 성능 가이드라인은 컴파일러의 캐싱 이점과 성능 최적화를 이유로 객체 확장 시 교집합을 사용하는 타입 별칭보다 인터페이스 상속(extends)을 사용할 것을 권장합니다 [8-10]. 하지만 실무 현장에서는 의도치 않은 선언 병합을 방지하고 유연성을 얻고자 린팅(Linting) 규칙을 통해 인터페이스 사용을 아예 금지하고 타입 별칭(Type Alias)만을 전면적으로 사용하는 개발 팀들도 많아 명확한 대립이 존재합니다 [4, 6, 15].
-
----
-*Last updated: 2026-04-18*
-- Raw Source: [[00_Raw/2026-04-20/타입 별칭 (Type Alias).md]]
----
diff --git a/Design & Experience/테스트 용이성 (Testability).md b/Design & Experience/테스트 용이성 (Testability).md
deleted file mode 100644
index 3790faee..00000000
--- a/Design & Experience/테스트 용이성 (Testability).md	
+++ /dev/null
@@ -1,34 +0,0 @@
----
-id: P-REINFORCE-AUTO-BF1A40
-category: "[[10_Wiki/💡 Topics/Design & Experience]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - 테스트 용이성 (Testability)"
----
-
-# [[테스트 용이성 (Testability)]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 테스트 용이성이란 소프트웨어 시스템의 다양한 부분에 대해 자동화된 테스트를 직관적이고 쉽게 생성할 수 있도록 설계된 정도를 의미합니다 [1]. 이는 비즈니스 로직을 데이터베이스나 UI 같은 외부 환경으로부터 완전히 격리하여, 복잡한 설정이나 거대한 통합 테스트 없이 핵심 로직만을 검증할 수 있게 하는 아키텍처 및 코드의 특성입니다 [2, 3]. 테스트가 용이한 코드는 각 모듈이 독립적이고 결합도가 낮아 전체 시스템을 설정할 필요 없이 개별 관심사에 초점을 맞춘 단위 테스트를 용이하게 만듭니다 [4, 5].
-
-## 📖 구조화된 지식 (Synthesized Content)
-- **설계 및 아키텍처 차원의 테스트 용이성:** 클린 아키텍처와 같은 소프트웨어 설계 패러다임은 시스템을 계층화하여 테스트 용이성을 극대화합니다 [6, 7]. 핵심 비즈니스 규칙을 프레임워크나 외부 에이전시로부터 독립시킴으로써, 외부 의존성이나 복잡한 설정 없이 순수한 비즈니스 로직에 대한 단위 테스트를 수월하게 작성할 수 있도록 보장합니다 [1, 3].
-- **관심사의 분리(SoC)와 응집도/결합도의 영향:** 관심사의 분리 원칙을 적용하여 모듈의 응집도를 높이고 결합도를 낮추면 각 모듈이 독립적으로 동작하게 되어 테스트의 복잡도가 현저히 낮아집니다 [8, 9]. 개발자는 전체 환경을 구축할 필요 없이 가짜 데이터(Fake data)나 더미 모듈을 사용하여 모듈을 블랙박스 또는 화이트박스 형태로 독립적으로 테스트할 수 있게 됩니다 [5, 10]. 
-- **의존성 주입(Dependency Injection)의 활용:** 클래스 내부에 의존성이 하드 코딩되어 있으면 실질적인 테스트가 불가능해질 수 있습니다 [11]. 의존성 주입을 사용하면 테스트 시 실제 의존성 대신 테스트 더블(Test Double)을 주입할 수 있어 복잡한 설정을 단순화하고 테스트 용이성을 확보할 수 있습니다 [12, 13].
-- **테스트 더블(Test Double)을 통한 격리:** 설정이 까다롭거나 부수 효과(Side effect)를 발생시키는 실제 외부 의존성 대신, 목(Mock), 스텁(Stub), 페이크(Fake) 등의 테스트 더블을 사용하면 외부 세계의 비결정론적 변화로부터 테스트를 보호하고 격리된 단위 테스트를 수행할 수 있습니다 [10, 12]. 
-- **분산 시스템 및 AI 시스템에서의 양면성:** 마이크로서비스 아키텍처는 개별 서비스 단위로는 높은 테스트 가능성을 제공하지만, 서비스 간 상호작용과 분산 시스템을 테스트하는 것은 더 어려워지는 구조적 특징을 갖습니다 [14, 15]. 반면 확률적이고 비결정론적인 성격을 지닌 AI 시스템 아키텍처라도 명확한 경계와 관찰 가능한 상태를 가지도록 컴포넌트를 설계하고 TDD(테스트 주도 개발)를 적용하면 높은 수준의 테스트 용이성과 유지보수성을 달성할 수 있습니다 [16-18].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Design & Experience 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[관심사의 분리 (Separation of Concerns)]], [[의존성 주입 (Dependency Injection)]], [[클린 아키텍처 (Clean Architecture)]], [[테스트 더블 (Test Double)]]
-- **Projects/Contexts:** [[소프트웨어 아키텍처 설계]], [[AI 시스템 아키텍처 개발]], [[마이크로서비스 아키텍처 구축]]
-- **Contradictions/Notes:** 모의 객체(Mock)와 스텁(Stub) 사용에 있어, 테스트를 단순하게 하고 외부 시스템으로부터 코드를 보호해 준다는 강력한 장점이 있지만, 너무 남용할 경우 코드가 실제와 다르게 동작할 수 있고 구현 세부 사항과 강하게 결합되어 테스트의 신뢰성을 떨어뜨릴 수 있다는 classicist 관점의 경고가 존재합니다 [19, 20].
-
----
-*Last updated: 2026-04-18*
-- Raw Source: [[00_Raw/2026-04-20/테스트 용이성 (Testability).md]]
----
diff --git a/Design & Experience/프론트엔드 컴포넌트 구조화.md b/Design & Experience/프론트엔드 컴포넌트 구조화.md
deleted file mode 100644
index 00543dca..00000000
--- a/Design & Experience/프론트엔드 컴포넌트 구조화.md	
+++ /dev/null
@@ -1,33 +0,0 @@
----
-id: P-REINFORCE-AUTO-353103
-category: "[[10_Wiki/💡 Topics/Design & Experience]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - 프론트엔드 컴포넌트 구조화"
----
-
-# [[프론트엔드 컴포넌트 구조화]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 프론트엔드 컴포넌트 구조화는 웹 개발에서 복잡성을 줄이고 유지보수성을 높이기 위해 기능과 역할 단위로 코드를 분리하고 조직하는 방법론입니다 [1, 2]. 초기에는 HTML, CSS, JavaScript라는 언어적 역할에 따라 분리되었으나, 특정 기능과 UI 요소를 하나의 단위로 묶는 컴포넌트 기반 아키텍처로 진화했습니다 [3]. 프로젝트의 규모가 커짐에 따라 발생하는 컴포넌트 간의 높은 결합도를 해결하기 위해, 관심사의 분리(SoC) 원칙을 다시 적용하여 Feature-Sliced Design(FSD)과 같이 기능 중심으로 구조를 세분화하는 방향으로 발전하고 있습니다 [2, 4].
-
-## 📖 구조화된 지식 (Synthesized Content)
-- **컴포넌트 패러다임의 등장과 한계:** 프론트엔드의 개발은 본래 문서의 구조, 표현, 동작을 위해 각각 HTML, CSS, JS라는 수평적 계층으로 나뉘어 있었으나, 웹 프레임워크의 도입과 함께 기능 중심의 모듈화를 의미하는 수직적 '컴포넌트' 방식으로 변화했습니다 [1, 3, 5]. 하지만 프로젝트가 비대해짐에 따라 하나의 컴포넌트 안에 데이터 관리, 표현 로직, 비즈니스 로직이 집중되어 단일 책임 원칙을 위반하고, 'props drilling'으로 인한 컴포넌트 간의 결합도가 지나치게 높아지는 문제가 발생했습니다 [4, 6].
-- **계층적 관심사로의 회귀:** 컴포넌트의 한계를 극복하기 위해 다시 계층적 분리가 도입되었습니다 [7]. UI 컴포넌트의 명확한 역할과 계층을 나누기 위한 Atomic Design Pattern의 도입, CSS가 HTML의 구조를 단방향으로 따라가게 만드는 의존성 해결, 그리고 화면(View)과 데이터 로직을 분리하여 단방향 데이터 흐름을 만드는 상태 관리(State Management) 기법이 적용되었습니다 [8-10].
-- **폴더 구조의 진화와 FSD 아키텍처:** 전통적인 폴더 구조는 역할(api, components, pages 등)을 중심으로 분리되었으나, 대규모 프로젝트에서는 기능 단위로 코드가 흩어지게 되어 파악이 어렵습니다 [11, 12]. 이에 따라 기능을 기준으로 필요한 모든 파일을 한 폴더에 모아 관리하는 Feature-Sliced Design(FSD) 아키텍처가 대안으로 등장했습니다 [2]. 이를 통해 기능 간의 결합도를 줄이고 독립적인 관리가 가능해집니다 [13].
-- **올바른 컴포넌트 분리 원칙:** 프론트엔드 구조화에서 가장 흔한 실수는 겉모양이 비슷하다는 이유로 완전히 다른 도메인 데이터를 다루는 컴포넌트들을 하나로 묶어 재사용하려는 것입니다 [14]. 화면을 다루는 뷰 컴포넌트와 비즈니스 로직을 다루는 도메인 컴포넌트는 명확히 분리해야 하며, 만약 같은 화면 컴포넌트를 여러 도메인에서 공유해야 한다면 데이터를 변환하는 어댑터를 활용해 도메인별 데이터 규격을 화면 컴포넌트가 받아들일 수 있는 형태로 맞추어 전달하는 구조를 취해야 합니다 [15, 16].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Design & Experience 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[관심사의 분리]], [[Feature-Sliced Design]], [[단일 책임 원칙 (SRP)]], [[Atomic Design Pattern]]
-- **Projects/Contexts:** [[대규모 프론트엔드 웹 프로젝트 폴더 구조화]], [[컴포넌트 기반 웹 프레임워크 아키텍처 설계]]
-- **Contradictions/Notes:** 초기 웹 개발은 HTML, CSS, JS라는 역할 중심의 계층 구조로 이루어졌으나, 컴포넌트 패러다임의 등장으로 기능 중심의 융합 구조로 변하였습니다 [1, 3]. 하지만 컴포넌트 비대화와 결합도 증가라는 복잡성 문제가 다시 발생함에 따라, 현대에는 컴포넌트 내외부를 다시 세분화된 역할과 기능(Feature) 단위로 분리하는 FSD 아키텍처 구조로 나아가는 진화 흐름을 보입니다 [2, 4, 7].
-
----
-*Last updated: 2026-04-18*
-- Raw Source: [[00_Raw/2026-04-20/프론트엔드 컴포넌트 구조화.md]]
----
diff --git a/Design & Experience/프론트엔드 컴포넌트 설계.md b/Design & Experience/프론트엔드 컴포넌트 설계.md
deleted file mode 100644
index b97ee8da..00000000
--- a/Design & Experience/프론트엔드 컴포넌트 설계.md	
+++ /dev/null
@@ -1,44 +0,0 @@
----
-id: P-REINFORCE-AUTO-F2362F
-category: "[[10_Wiki/💡 Topics/Design & Experience]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - 프론트엔드 컴포넌트 설계"
----
-
-# [[프론트엔드 컴포넌트 설계]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 프론트엔드 컴포넌트 설계는 웹 개발에서 특정 기능이나 UI 요소를 구현하기 위해 HTML 구조, CSS 스타일, JavaScript 동작을 하나의 기능적 단위로 묶어 다루는 개발 방식입니다 [1]. 기존의 역할 중심 분리에서 기능 중심의 모듈화로 패러다임이 전환되면서 코드의 재사용성을 높이고 독립적인 테스트를 가능하게 했습니다 [1, 2]. 하지만 프로젝트 규모가 커짐에 따라 발생하는 컴포넌트의 비대화와 강한 결합도를 해결하기 위해, 다시 계층을 나누고 관심사를 분리하는 고도화된 설계 원칙이 요구됩니다 [3, 4].
-
-## 📖 구조화된 지식 (Synthesized Content)
-* **프론트엔드 컴포넌트 패러다임의 등장과 한계**
-  과거 웹 개발은 HTML(구조), CSS(표현), JS(동작)로 각자의 언어에 역할을 분리했으나, 웹 프레임워크의 도입과 함께 이를 수직으로 관통하는 컴포넌트 기반 아키텍처로 발전했습니다 [1, 5]. 하지만 대규모 프로젝트에서는 하위 컴포넌트로 데이터를 전달하기 위한 'props drilling'으로 인해 결합도가 지나치게 높아졌고, 하나의 컴포넌트에 데이터 관리와 표현, 비즈니스 로직이 모두 집중되면서 단일 책임 원칙(SRP)을 위반하는 비대화 문제가 발생했습니다 [3, 6].
-
-* **효과적인 컴포넌트 설계를 위한 계층적 관심사 분리**
-  비대해진 컴포넌트 문제를 해결하기 위해 프론트엔드 진영은 컴포넌트 내부와 외부를 다시 계층적으로 분리하기 시작했습니다 [4].
-  * **UI 컴포넌트의 계층화:** 아토믹 디자인 패턴(Atomic Design Pattern) 등을 도입하여 컴포넌트를 더 세밀한 기준과 역할로 분리해 정돈했습니다 [7].
-  * **HTML-CSS의 단방향 의존성:** CSS Modules나 CSS-in-JS 등을 활용하여 구조(HTML) 변경 시 스타일(CSS)이 종속적으로 따라가도록 의존성의 방향을 단방향으로 통제했습니다 [7, 8].
-  * **뷰 로직과 비즈니스/서버 상태 로직의 분리:** 상태 관리(State Management) 개념을 통해 컴포넌트는 오직 화면 렌더링과 사용자 이벤트 수신에만 집중하도록 하고, 데이터 로직이나 비동기 처리(API 호출, 캐싱 등)는 별도의 계층으로 위임하여 단방향 데이터 흐름을 구축했습니다 [9, 10].
-
-* **실무적인 컴포넌트 분리 및 재사용 원칙**
-  * **도메인과 UI의 분리:** 시각적인 모양이 유사하더라도 다루는 도메인 데이터가 다르다면 같은 컴포넌트로 묶어 재사용하는 것은 지양해야 합니다. 재사용할 컴포넌트는 도메인에 종속되지 않은 순수 UI 요소로만 구성하여 응집도를 높이고 독립시켜야 합니다 [11, 12].
-  * **어댑터(Adapter) 패턴 활용:** 만능 관리자 게시판처럼 동일한 UI 화면에 다양한 도메인 데이터를 렌더링해야 할 경우, 컴포넌트 내부에 분기문(if)을 무한히 추가하는 것은 안티 패턴입니다. 대신 각 도메인의 데이터를 UI 컴포넌트의 규격에 맞게 변환해 주는 어댑터를 두어 화면과 데이터 간의 단방향 의존성을 지켜야 합니다 [12, 13].
-
-* **설계 패러다임에 따른 폴더 구조의 진화 (FSD)**
-  프론트엔드 프로젝트의 설계는 폴더 구조와 직결됩니다. 초기에는 역할(api, components, pages 등) 단위의 분리가 유리하지만, 프로젝트가 고도화되면 역할 중심의 구조는 유지보수를 어렵게 합니다 [14, 15]. 이에 따라 코드를 기능(Feature) 단위로 응집시키는 FSD(Feature-Sliced Design) 아키텍처 방식이 대안으로 등장하여, 기능 간의 결합도를 줄이고 프론트엔드의 복잡성을 관리하고 있습니다 [16, 17].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Design & Experience 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[관심사의 분리 (SoC)]], [[단일 책임 원칙 (SRP)]], [[아토믹 디자인 패턴 (Atomic Design Pattern)]], [[단방향 데이터 흐름]], [[FSD (Feature-Sliced Design)]]
-- **Projects/Contexts:** [[대규모 프론트엔드 애플리케이션 아키텍처 구축 및 리팩토링]]
-- **Contradictions/Notes:** 소스에서는 시각적 형태가 비슷하다고 무작정 동일한 컴포넌트로 묶는 것을 프론트엔드 개발자들이 흔히 하는 실수로 지적합니다. 데이터(도메인)가 다를 경우 결합도가 급증하여 오히려 유지보수성이 저해되므로, UI 컴포넌트와 도메인 컴포넌트를 명확히 분리해야 한다고 강조합니다.
-
----
-*Last updated: 2026-04-18*
-- Raw Source: [[00_Raw/2026-04-20/프론트엔드 컴포넌트 설계.md]]
----
diff --git a/Design & Experience/플레이어 경험 디자인 (Player Experience Design).md b/Design & Experience/플레이어 경험 디자인 (Player Experience Design).md
deleted file mode 100644
index 42764780..00000000
--- a/Design & Experience/플레이어 경험 디자인 (Player Experience Design).md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-216B69
-category: "[[10_Wiki/💡 Topics/Design & Experience]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - 플레이어 경험 디자인 (Player Experience Design)"
----
-
-# [[플레이어 경험 디자인 (Player Experience Design)]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Design & Experience 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/플레이어 경험 디자인 (Player Experience Design).md]]
----
diff --git a/Design & Experience/행동 치료 및 인지 행동 치료 (CBT).md b/Design & Experience/행동 치료 및 인지 행동 치료 (CBT).md
deleted file mode 100644
index 8e0417ea..00000000
--- a/Design & Experience/행동 치료 및 인지 행동 치료 (CBT).md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-121D57
-category: "[[10_Wiki/💡 Topics/Design & Experience]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - 행동 치료 및 인지 행동 치료 (CBT)"
----
-
-# [[행동 치료 및 인지 행동 치료 (CBT)]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Design & Experience 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/행동 치료 및 인지 행동 치료 (CBT).md]]
----
diff --git a/Design & Experience/현대 웹 애플리케이션 설계.md b/Design & Experience/현대 웹 애플리케이션 설계.md
deleted file mode 100644
index 4e57c443..00000000
--- a/Design & Experience/현대 웹 애플리케이션 설계.md	
+++ /dev/null
@@ -1,34 +0,0 @@
----
-id: P-REINFORCE-AUTO-21E1FE
-category: "[[10_Wiki/💡 Topics/Design & Experience]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - 현대 웹 애플리케이션 설계"
----
-
-# [[현대 웹 애플리케이션 설계]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 현대 웹 애플리케이션 설계는 시스템의 확장성, 유지보수성, 그리고 개발 속도를 향상시키기 위해 복잡성을 효과적으로 분리하고 관리하는 구조적 접근 방식을 의미한다 [1-3]. 전통적인 모놀리식 구조의 한계를 극복하기 위해 관심사의 분리(SoC) 원칙을 기반으로 시스템을 독립적인 모듈과 계층으로 철저히 분할한다 [4-6]. 백엔드의 마이크로서비스 아키텍처부터 프론트엔드의 마이크로 프론트엔드, API 우선 설계, 클린 아키텍처에 이르기까지 다양한 패러다임이 결합되어 대규모 팀의 자율적이고 병렬적인 개발과 안정적인 서비스 배포를 지원한다 [7-10].
-
-## 📖 구조화된 지식 (Synthesized Content)
-*   **관심사의 분리(SoC) 및 다계층 구조:** 현대 웹 애플리케이션 설계의 가장 핵심적인 원칙은 관심사의 분리(SoC)이다 [2, 11]. 이는 애플리케이션을 프레젠테이션 계층(UI 및 사용자 상호작용), 비즈니스 로직 계층(데이터 처리 및 애플리케이션 규칙), 데이터 액세스 계층(데이터베이스 통신) 등 명확한 목적을 가진 계층으로 나누는 MVC 또는 N-Tier 아키텍처 패턴을 따른다 [12-14]. 이를 통해 특정 계층의 변경이 다른 계층에 영향을 미치지 않도록 방지하고, 코드의 응집도(Cohesion)를 높이며 결합도(Coupling)를 낮춘다 [15-17].
-*   **API 우선 아키텍처(API-First Architecture):** 애플리케이션의 API를 나중에 덧붙이는 것이 아니라 일차적인 제품으로 취급하여 먼저 설계하는 방식이다 [18]. 프론트엔드와 백엔드 개발팀이 합의된 API 명세(예: OpenAPI)를 기반으로 병렬 작업을 수행할 수 있도록 하며, 분산된 시스템 통합의 일관된 접점 역할을 한다 [7, 19, 20].
-*   **마이크로서비스 및 클라우드 네이티브 환경:** 대규모 웹 애플리케이션은 촘촘하게 결합된 모놀리식 구조에서 벗어나, 독립적으로 배포 및 확장이 가능한 마이크로서비스 아키텍처로 진화했다 [5, 21, 22]. 각 서비스는 특정 비즈니스 기능(도메인)에 집중하며, 넷플릭스(Netflix)의 사례처럼 시스템을 분할하여 개발 조직의 혁신 속도와 시스템 가용성을 크게 향상시킨다 [9, 23]. 또한, 컨테이너(Docker) 기반 배포와 오케스트레이션(Kubernetes)을 활용하는 클라우드 네이티브 구조를 통해 탄력적인 자원 확장과 무중단 배포를 구현한다 [24, 25].
-*   **프론트엔드 아키텍처의 진화 (마이크로 프론트엔드 및 FSD):** 프론트엔드 역시 복잡성을 다루기 위해 발전을 거듭했다. 단일 프론트엔드 애플리케이션의 비대화를 막기 위해 UI를 독립적으로 개발하고 런타임에 결합하는 마이크로 프론트엔드 아키텍처가 채택되고 있다 [6, 26, 27]. 또한, 프로젝트의 규모가 커짐에 따라 단순한 역할(컴포넌트, 훅 등) 기반 폴더 구조를 넘어 기능(Feature)을 기준으로 코드를 슬라이스하여 관리하는 FSD(Feature-Sliced Design) 방법론이 도입되어 프론트엔드의 유지보수성을 극대화하고 있다 [28, 29].
-*   **클린 아키텍처의 적용:** 비즈니스의 핵심 규칙(엔티티 및 유스케이스)을 아키텍처의 중심에 배치하고, UI나 웹 프레임워크, 데이터베이스와 같은 세부 사항들을 외부 계층으로 밀어내는 클린 아키텍처 패러다임이 필수적이다 [10, 30, 31]. 소스 코드의 의존성은 항상 고수준의 정책을 향해 안쪽으로만 흐르게 하여(의존성 규칙), 애플리케이션이 특정 웹 프레임워크나 외부 DB 기술에 종속되지 않도록 설계해야 한다 [32, 33].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Design & Experience 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[관심사의 분리(SoC)]], [[마이크로서비스 아키텍처]], [[마이크로 프론트엔드]], [[클린 아키텍처]], [[Feature-Sliced Design (FSD)]], [[API 우선 아키텍처]]
-- **Projects/Contexts:** [[넷플릭스(Netflix) 마이크로서비스 도입]], [[스포티파이(Spotify) 스쿼드 모델 및 마이크로 프론트엔드]]
-- **Contradictions/Notes:** 마이크로서비스나 모듈화를 통한 관심사의 분리는 개발 및 배포의 완벽한 독립성을 제공하는 것처럼 보이지만, 횡단 관심사(Cross-cutting concerns)나 공유 데이터 구조 변경 시에는 여러 서비스가 간접적으로 결합되어 파급 효과가 발생할 수 있다는 맹점이 존재한다 [34-36]. 또한, 과도한 계층 분리와 추상화는 네트워크 지연 시간 증가, 데이터 변환 오버헤드, 가독성 저하 등의 '오버엔지니어링'을 초래할 수 있으므로 프로젝트의 규모와 실용성에 맞춘 적절한 트레이드오프와 조율이 필요하다 [37-39].
-
----
-*Last updated: 2026-04-18*
-- Raw Source: [[00_Raw/2026-04-20/현대 웹 애플리케이션 설계.md]]
----
diff --git a/Design & Web Performance/Core Web Vitals.md b/Design & Web Performance/Core Web Vitals.md
deleted file mode 100644
index 781e035a..00000000
--- a/Design & Web Performance/Core Web Vitals.md	
+++ /dev/null
@@ -1,31 +0,0 @@
----
-id: P-REINFORCE-AI-045
-category: "[[10_Wiki/💡 Topics/Design & Web Performance]]"
-confidence_score: 0.98
-tags: [web, performance, web vitals, user experience]
-last_reinforced: 2026-06-XX
-github_commit: "[P-Reinforce] Processed Core_Web_Vitals.md"
----
-
-# [[Core Web Vitals]] (핵심 웹 지표)
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 구글이 제시하는 사용자 경험 중심의 핵심 측정 기준들로, 단순한 기술 스펙을 넘어 실제 사용자가 체감하는 페이지 로딩 속도와 인터랙션 품질을 종합적으로 평가한다.
-
-## 📖 구조화된 지식 (Synthesized Content)
-- **개념:** 웹사이트의 성능을 평가하는 가장 중요한 세 가지 지표를 통칭하며, 사용자 경험(UX)과 직접적으로 연결된다는 것이 핵심이다.
-- **세부 구성 요소:**
-    1. **LCP (Largest Contentful Paint):** 사용자가 페이지에서 가장 큰 콘텐츠가 로드되는 시점의 시간 측정. (인지적 만족도와 직결).
-    2. **FID (First Input Delay) / INP (Interaction to Next Paint):** 사용자의 첫 번째 입력(클릭, 터치 등)을 시스템이 인지하고 반응하는 데 걸리는 지연 시간 측정. (반응성 평가). *최근에는 FID 대신 INP가 표준화되는 추세.*
-    3. **CLS (Cumulative Layout Shift):** 콘텐츠가 로드되거나 변경될 때 레이아웃이 얼마나 불안정하게 흔들리는지를 측정. (시각적 안정성 평가).
-- **기술적 중요성:** 이 지표들은 단순히 Lighthouse 점수 몇 점을 넘기는 것을 넘어, 웹 애플리케이션의 아키텍처(Code Splitting, Lazy Loading) 설계와 직접 연관되어 최적화가 요구된다.
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 과거에는 단순히 로딩 바 속도만 중요하게 여겼으나, 이제는 LCP/FID/CLS를 통해 '사용자가 체감하는 경험'이라는 관점으로 패러다임이 완전히 전환되었다.
-- **정책 변화:** 기술적 개선(예: WebGPU 도입)만큼이나 사용자에게 이 성능 향상을 어떻게 인지시키고 가치를 전달할 것인지(UX 측면)가 중요해지고 있다.
-
-## 🔗 지식 연결 (Graph)
-- Parent: [[Web Performance Optimization]]
-- Related: [[Largest Contentful Paint (LCP)]] , [[Interaction to Next Paint (INP)]] , [[Cumulative Layout Shift (CLS)]]
-- Raw Source: [[00_Raw/Core_Web_Vitals.md]]
----
\ No newline at end of file
diff --git a/Design/Accessibility.md b/Design/Accessibility.md
deleted file mode 100644
index b9f40767..00000000
--- a/Design/Accessibility.md
+++ /dev/null
@@ -1,29 +0,0 @@
----
-id: P-REINFORCE-DESIGN-001
-category: "[[10_Wiki/💡 Topics/Design]]"
-confidence_score: 0.94
-tags: [design, accessibility, a11y, ux]
-last_reinforced: 2026-04-20
-github_commit: "batch-reinforce-01"
----
-
-# [[Accessibility (A11y)]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 기술적 장벽을 허물어 모든 사용자가 정보에 평등하게 접근할 수 있도록 보장하는 포괄적 설계의 핵심 원칙.
-
-## 📖 구조화된 지식 (Synthesized Content)
-- **추출된 패턴:** WCAG 2.1 가이드라인을 준수하며 시각/청각/운동 능력의 제약과 관계없이 인터페이스를 인지 가능하게 만드는 접근성 수립 패턴.
-- **세부 내용:**
-    - 의미론적 HTML 태그 사용 및 ARIA 속성 적용.
-    - 키보드 내비게이션 및 스크린 리더 호환성 확보.
-    - 텍스트 대비 및 폰트 크기 조절 등 시각적 보완 기능.
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 부수적인 기능으로 여겨지던 '접근성'을 제품 설계의 근간(First-class Citizen)으로 재정의.
-- **정책 변화:** 사용자 만족도(w3)의 필수 지표로 접근성 점수를 채택.
-
-## 🔗 지식 연결 (Graph)
-- **Parent:** [[10_Wiki/💡 Topics/Design]]
-- **Related:** [[WCAG]], [[Inclusive-Design]], [[ARIA]]
-- **Raw Source:** [[00_Raw/2026-04-20/Accessibility (A11y).md]]
diff --git a/Design/Cognitive_Load.md b/Design/Cognitive_Load.md
deleted file mode 100644
index f6a2656c..00000000
--- a/Design/Cognitive_Load.md
+++ /dev/null
@@ -1,29 +0,0 @@
----
-id: P-REINFORCE-DESIGN-004
-category: "[[10_Wiki/💡 Topics/Design]]"
-confidence_score: 0.94
-tags: [design, hci, psychology, cognitive-load]
-last_reinforced: 2026-04-20
-github_commit: "batch-reinforce-07"
----
-
-# [[Cognitive Load Theory (인지 부하 이론)]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 우리 뇌의 작업 기억(Working Memory) 용량은 한정되어 있음을 인정하고, 정보 전달의 효율을 위해 마찰을 설계하는 기술.
-
-## 📖 구조화된 지식 (Synthesized Content)
-- **추출된 패턴:** 내재적 부하(Intrinsic), 외재적 부하(Extraneous), 본질적 부하(Germane)를 구분하여 학습 및 정보 처리를 최적화하는 인지 설계 패턴.
-- **세부 내용:**
-    - Interface 디자인 시 불필요한 시각적 노이즈를 제거하여 외재적 부하를 최소화.
-    - 정보의 청킹(Chunking)을 통해 제한된 작업 기억 공간을 효율적으로 활용.
-    - 복잡한 데이터 시각화 시 점진적 노출(Progressive Disclosure) 기법 적용.
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 단순한 미학적 디자인(Beautiful)에서 뇌의 작동 방식에 부합하는 사용성(Usable) 중심으로 패러다임 이동.
-- **정책 변화:** 사용자 만족도(w3) 지표로 인지 부하 측정 가이던스 도입.
-
-## 🔗 지식 연결 (Graph)
-- **Parent:** [[10_Wiki/💡 Topics/Design]]
-- **Related:** [[HCI]], [[UX-Design]], [[Inclusive_Design]]
-- **Raw Source:** [[00_Raw/2026-04-20/Cognitive Load Theory.md]]
diff --git a/Design/CrUX.md b/Design/CrUX.md
deleted file mode 100644
index 54c29841..00000000
--- a/Design/CrUX.md
+++ /dev/null
@@ -1,29 +0,0 @@
----
-id: P-REINFORCE-DESIGN-005
-category: "[[10_Wiki/💡 Topics/Design]]"
-confidence_score: 0.89
-tags: [design, web, ux, performance, crux]
-last_reinforced: 2026-04-20
-github_commit: "batch-reinforce-07"
----
-
-# [[Chrome User Experience Report (CrUX)]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 실제 사용자가 웹에서 느끼는 속도와 사용성을 데이터로 입증하며 제품 개선의 근거를 제시하는 성능 리포트.
-
-## 📖 구조화된 지식 (Synthesized Content)
-- **추출된 패턴:** 실제 사용자 경험 데이터(RUM)를 기반으로 Core Web Vitals 지표를 분석하여 성능 병목 지점을 포착하는 패턴.
-- **세부 내용:**
-    - LCP(최대 콘텐츠 렌더링 시간), INP(다음 페인트와의 상호작용) 등 사용자 체감 지표 관리.
-    - BigQuery 및 PageSpeed Insights를 통한 데이터 접근 및 심층 분석.
-    - 최소 데이터 볼륨 기준을 통해 데이터의 신뢰성과 대표성 확보.
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 실험실 환경(Lab Data)의 측정값과 실제 현장(Field Data)의 격차를 해소.
-- **정책 변화:** 사용자 만족도(w3) 측정 시 CrUX 리포트의 성능 지표를 가중치로 적극 반영.
-
-## 🔗 지식 연결 (Graph)
-- **Parent:** [[10_Wiki/💡 Topics/Design]]
-- **Related:** [[Core-Web-Vitals]], [[Performance-Optimization]], [[UX-Design]]
-- **Raw Source:** [[00_Raw/2026-04-20/Chrome User Experience Report (CrUX).md]]
diff --git a/Design/HCI.md b/Design/HCI.md
deleted file mode 100644
index 2d28557c..00000000
--- a/Design/HCI.md
+++ /dev/null
@@ -1,29 +0,0 @@
----
-id: P-REINFORCE-DESIGN-003
-category: "[[10_Wiki/💡 Topics/Design]]"
-confidence_score: 0.96
-tags: [design, hci, ux, cognitive]
-last_reinforced: 2026-04-20
-github_commit: "batch-reinforce-06"
----
-
-# [[Human-Computer Interaction (HCI)]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 기계의 효율성과 인간의 인지를 잇는 접점에서, 가장 마찰 없는(Frictionless) 소통의 언어를 설계하는 학문.
-
-## 📖 구조화된 지식 (Synthesized Content)
-- **추출된 패턴:** 사용자의 멘탈 모델(Mental Model)과 시스템의 개념 모델을 일치시켜 인지 부하를 최소화하는 상호작용 패턴.
-- **세부 내용:**
-    - 닐슨의 10가지 유리스틱(Heuristics)을 활용한 사용성 평가.
-    - 피츠의 법칙(Fitts's Law) 등 인간 공학적 데이터 기반 인터페이스 설계.
-    - 감성 컴퓨팅(Affective Computing)을 통한 교감형 상호작용 연구.
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 도구로서의 컴퓨터에서 '협력적 지능 에이전트'로의 상호작용 대상 변화 인식.
-- **정책 변화:** 지식 구조(w2) 관점에서 AI 인터페이스 설계 가이드라인의 중추로 설정.
-
-## 🔗 지식 연결 (Graph)
-- **Parent:** [[10_Wiki/💡 Topics/Design]]
-- **Related:** [[UX-Design]], [[Cognitive-Load]], [[Fitts-Law]]
-- **Raw Source:** [[00_Raw/2026-04-20/Human-Computer-Interaction.md]]
diff --git a/Design/Inclusive_Design.md b/Design/Inclusive_Design.md
deleted file mode 100644
index 9ad1993e..00000000
--- a/Design/Inclusive_Design.md
+++ /dev/null
@@ -1,29 +0,0 @@
----
-id: P-REINFORCE-DESIGN-002
-category: "[[10_Wiki/💡 Topics/Design]]"
-confidence_score: 0.94
-tags: [design, inclusive, universal, accessibility]
-last_reinforced: 2026-04-20
-github_commit: "batch-reinforce-06"
----
-
-# [[Inclusive Design (포용적 설계)]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 인간의 다양성을 설계의 중심에 두고, 특정 그룹을 배제하지 않는 보편적 접근을 통해 기술의 인간성을 실현하는 일.
-
-## 📖 구조화된 지식 (Synthesized Content)
-- **추출된 패턴:** 극단적 사용자(Extreme Users)의 요구사항을 해결함으로써 일반 사용자까지 혜택을 입게 만드는 '에지 케이스' 기반 설계 패턴.
-- **세부 내용:**
-    - 상황적 제약(손에 짐을 든 경우 등)까지 고려한 UX 시나리오 확장.
-    - 유니버설 디자인(Universal Design) 7원칙의 디지털 인터페이스 적용.
-    - 공감(Empathy) 기반의 사용자 리서치를 통한 잠재적 장벽 제거.
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 단순 사후 보완(Compliance) 개념이었던 접근성을 사전 설계 전략(Strategy)으로 격상.
-- **정책 변화:** 사용자 만족도(w3) 피드백에서 '포용성 점수'의 비준을 강화.
-
-## 🔗 지식 연결 (Graph)
-- **Parent:** [[10_Wiki/💡 Topics/Design]]
-- **Related:** [[Accessibility]], [[ISO-9241]], [[User-Centered-Design]]
-- **Raw Source:** [[00_Raw/2026-04-20/Universal-Design-Principles.md]]
diff --git a/DevOps_Environment_Setup.md b/DevOps_Environment_Setup.md
deleted file mode 100644
index c24517d5..00000000
--- a/DevOps_Environment_Setup.md
+++ /dev/null
@@ -1,24 +0,0 @@
----
-title: 개발 환경 및 실행 프로세스 관리 (DevOps & Setup)
-category: DevOps
-tags: [DevOps, Environment, CI/CD, Process Management]
-created: 2026-04-20
----
-
-# 개발 환경 및 실행 프로세스 관리
-
-## 🎯 개요 (Overview)
-코딩 완성도만큼이나 중요한 **실행 환경(Runtime Environment)**과 **설정 파일(Configuration)**의 무결성을 확보하여, '내 컴퓨터에선 되는데 왜 저기선 안 되지?'라는 문제를 해결하는 프로세스입니다.
-
-## 🚀 필수 체크리스트 (Checklist)
-- **의존성 관리**: `npm install` 등 패키지 무결성 확인.
-- **물리적 파일 구조**: `index.html` 등 필수 진입점 파일 존재 확인.
-- **보안 및 권한**: OS 레벨의 실행 정책(`Execution Policy`) 및 권한 설정.
-
-## 💡 레슨 런 (Lesson Learned)
-> [!NOTE]
-> **"운영 환경에 대한 이해는 코딩 능력의 절반이다."**
-> 논리적 로직의 완성뿐만 아니라, 그것이 실제로 구동되는 물리적 인프라 설정을 문서화하고 자동화하는 능력이 필수적입니다.
-
-## 🔗 연결된 지식
-- [[Systemic_Simulation_Principles]]
diff --git a/Developer Productivity Tracking.md b/Developer Productivity Tracking.md
deleted file mode 100644
index e69de29b..00000000
diff --git a/Economics & Algorithms/Algorithmic Mechanism Design.md b/Economics & Algorithms/Algorithmic Mechanism Design.md
deleted file mode 100644
index 2b0226b5..00000000
--- a/Economics & Algorithms/Algorithmic Mechanism Design.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-29EF85
-category: "[[10_Wiki/💡 Topics/Economics & Algorithms]]"
-confidence_score: 0.95
-tags: []
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Batch 11 - Wikified Algorithmic Mechanism Design"
----
-
-# [[Algorithmic Mechanism Design]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 작업 중
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 신규 지식 카테고리화 및 연결성 강화.
-- **정책 변화:** Economics & Algorithms 분야의 지식 자산 보호 및 네트워크 확장.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Algorithmic Mechanism Design.md]]
----
diff --git a/Economics & Algorithms/Auction Theory.md b/Economics & Algorithms/Auction Theory.md
deleted file mode 100644
index b53b86fb..00000000
--- a/Economics & Algorithms/Auction Theory.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-375B82
-category: "[[10_Wiki/💡 Topics/Economics & Algorithms]]"
-confidence_score: 0.95
-tags: []
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Mega Batch 2 - Wikified Auction Theory"
----
-
-# [[Auction Theory]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 작업 중
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 지식 자산화 및 기존 네트워크 연동 단계.
-- **정책 변화:** Economics & Algorithms 카테고리의 전문성 확보 및 링크 밀도 최적화.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Auction Theory.md]]
----
diff --git a/Education & AI/Adaptive-Learning-Systems.md b/Education & AI/Adaptive-Learning-Systems.md
deleted file mode 100644
index 960a4ff6..00000000
--- a/Education & AI/Adaptive-Learning-Systems.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AI-A2C439
-category: "[[10_Wiki/💡 Topics/Education & AI]]"
-confidence_score: 0.95
-tags: []
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Batch 9 - Wikified Adaptive-Learning-Systems"
----
-
-# [[Adaptive-Learning-Systems]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 
-
-## 📖 구조화된 지식 (Synthesized Content)
-
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 신규 문서로, 기존 정보와의 충돌 분석 예정.
-- **정책 변화:** Education & AI 카테고리의 지식 연결망 강화를 위한 표준 위키화 적용.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Adaptive-Learning-Systems.md]]
----
diff --git a/Education/Adaptive_Learning.md b/Education/Adaptive_Learning.md
deleted file mode 100644
index 6cb2ca24..00000000
--- a/Education/Adaptive_Learning.md
+++ /dev/null
@@ -1,29 +0,0 @@
----
-id: P-REINFORCE-EDUC-001
-category: "[[10_Wiki/💡 Topics/Education]]"
-confidence_score: 0.91
-tags: [education, ai, adaptive, learning]
-last_reinforced: 2026-04-20
-github_commit: "batch-reinforce-01"
----
-
-# [[Adaptive Learning Systems]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 학습자의 수준과 속도를 실시간으로 분석하여 개인별 최적의 학습 경로를 동적으로 제안하는 지능형 교수 시스템.
-
-## 📖 구조화된 지식 (Synthesized Content)
-- **추출된 패턴:** 학습 데이터를 기반으로 지식의 간극(Knowledge Gap)을 진단하고 다음 학습 콘텐츠를 추천하는 순환적 피드백 패턴.
-- **세부 내용:**
-    - IRT(문항 반응 이론)를 활용한 정확한 숙련도 측정.
-    - 학습 동기 유지를 위한 동적 난이도 조절.
-    - 시각적 데이터 대시보드를 통한 학습 성취도 체계적 관리.
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 일방향적인 주입식 교육에서 상호작용 중심의 개인화 교육으로의 전환.
-- **정책 변화:** 사용자 만족도(w3) 피드백에 따라 학습자 이탈 방지 알고리즘 우선순위 상향.
-
-## 🔗 지식 연결 (Graph)
-- **Parent:** [[10_Wiki/💡 Topics/Education]]
-- **Related:** [[IRT]], [[Personalized-Learning]], [[Educational-AI]]
-- **Raw Source:** [[00_Raw/2026-04-20/Adaptive-Learning-Systems.md]]
diff --git a/Financial Modeling & Math/Quantitative Finance.md b/Financial Modeling & Math/Quantitative Finance.md
deleted file mode 100644
index 5c7824a6..00000000
--- a/Financial Modeling & Math/Quantitative Finance.md	
+++ /dev/null
@@ -1,30 +0,0 @@
----
-id: P-REINFORCE-AI-057
-category: "[[10_Wiki/💡 Topics/Financial Modeling & Math]]"
-confidence_score: 0.98
-tags: [finance, quantitative finance, stochastics, risk management]
-last_reinforced: 2026-06-XX
-github_commit: "[P-Reinforce] Processed Quantitative Finance."
----
-
-# [[Quantitative Finance]] (계량 금융)
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 수학적 모델링, 통계학, 컴퓨터 과학을 결합하여 시장의 복잡한 데이터를 분석하고, 위험을 관리하며, 최적의 거래 전략을 수립하는 학문이다.
-
-## 📖 구조화된 지식 (Synthesized Content)
-- **핵심 방법론:** 직관에 의존하는 전통 금융 방식을 벗어나, 수학적으로 검증 가능한 모델(Model-Based Approach)을 사용한다. 확률 과정과 통계적 추정을 핵심으로 한다.
-- **주요 이론 및 적용:**
-    1. **확률 및 시계열 분석:** 주가 변동 같은 무작위 현상을 수학적 확률 분포로 가정하고, 이를 기반으로 예측 모델(예: GARCH)을 만든다. (Probability Theory).
-    2. **최적화와 의사결정:** 투자 포트폴리오의 위험 대비 수익률을 극대화하는 최적 배분을 계산한다 (Optimization Theory).
-    3. **위험 관리 (Risk Management):** VaR(Value at Risk)나 스트레스 테스트 등, 시스템이 감당할 수 있는 최대 손실 범위를 수학적으로 정의하고 관리한다.
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 시장은 본질적으로 예측 불가능한 '카오스'의 영역이다. 따라서 모델링 자체에 대한 겸손함(Humility)을 유지해야 하며, 모델이 실패할 경우를 대비하는 비상 계획이 필수적이다.
-- **정책 변화:** 최근에는 강화학습 (RL)과 결합하여, 시장 상황이라는 환경 속에서 에이전트가 최적의 행동 정책을 학습하게 하는 방향으로 진화하고 있다.
-
-## 🔗 지식 연결 (Graph)
-- Parent: [[Probability Theory]]
-- Related: [[Reinforcement Learning in Economics]] , [[Risk Management in Finance]] , [[Stochastic Processes]]
-- Raw Source: [[00_Raw/Quantitative Finance.md]]
----
\ No newline at end of file
diff --git a/Frontend & Concurrency/Web Worker (웹 워커).md b/Frontend & Concurrency/Web Worker (웹 워커).md
deleted file mode 100644
index 65bef19f..00000000
--- a/Frontend & Concurrency/Web Worker (웹 워커).md	
+++ /dev/null
@@ -1,30 +0,0 @@
----
-id: P-REINFORCE-AI-049
-category: "[[10_Wiki/💡 Topics/Frontend & Concurrency]]"
-confidence_score: 0.98
-tags: [webworker, concurrency, javascript, performance]
-last_reinforced: 2026-06-XX
-github_commit: "[P-Reinforce] Processed Web Worker (웹 워커)."
----
-
-# [[Web Worker (웹 워커)]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 웹 브라우저의 메인 스레드(Main Thread)가 UI 및 사용자 입력 처리라는 중요한 임무를 수행할 수 있도록, 무겁고 시간이 오래 걸리는 계산 작업을 별도의 백그라운드 스레드에서 분리 실행하는 기술이다.
-
-## 📖 구조화된 지식 (Synthesized Content)
-- **문제 인식:** 웹 애플리케이션의 성능 저하 주범은 메인 스레드의 '블로킹(Blocking)' 현상이다. 복잡한 데이터 처리, 대용량 JSON 파싱, 이미지 필터링 등이 메인 스레드에서 실행되면 UI가 멈추는 (Jank) 현상이 발생한다.
-- **Web Worker의 역할:** Web Worker는 OS 레벨의 독립된 스레드를 생성하여 JavaScript 코드를 백그라운드에서 실행시킨다. 이로 인해 메인 스레드는 항상 사용자와 상호작용할 준비 상태(Responsive)를 유지할 수 있다.
-- **통신 방식과 제약:** 
-    1. **Message Passing:** Worker와 Main Thread 간의 데이터는 `postMessage` API를 통해 비동기적으로 전달되어야 한다. (데이터 복사/직렬화 과정이 필요하다).
-    2. **SharedArrayBuffer & Atomics:** 성능 병목이 심할 경우, 메모리 전체를 공유하고 원자적 연산(Atomics)을 사용하여 통신 오버헤드를 극도로 줄이는 고급 기법도 가능하다.
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** Web Worker가 모든 문제를 해결하는 마법의 지팡이가 아니다. 스레드 간 데이터 전송 과정에서 발생하는 직렬화/역직렬화 비용(Serialization Overhead)을 고려해야 한다.
-- **정책 변화:** 고성능 컴퓨팅이 요구되는 환경에서는 `SharedArrayBuffer`와 같은 고급 메모리 공유 기법과 함께, 웹 워커를 활용하여 병목 현상을 근본적으로 해결하는 아키텍처 설계가 표준화되고 있다.
-
-## 🔗 지식 연결 (Graph)
-- Parent: [[Web Worker (웹 워커)]]
-- Related: [[Concurrency]] , [[JavaScript 메모리 관리(JavaScript Memory Management)]] , [[SharedArrayBuffer]]
-- Raw Source: [[00_Raw/Web Worker (웹 워커).md]]
----
\ No newline at end of file
diff --git a/Game Design & Math/Algorithmic Game Theory.md b/Game Design & Math/Algorithmic Game Theory.md
deleted file mode 100644
index bae0f0d9..00000000
--- a/Game Design & Math/Algorithmic Game Theory.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-CD6723
-category: "[[10_Wiki/💡 Topics/Game Design & Math]]"
-confidence_score: 0.95
-tags: []
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Batch 11 - Wikified Algorithmic Game Theory"
----
-
-# [[Algorithmic Game Theory]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 작업 중
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 신규 지식 카테고리화 및 연결성 강화.
-- **정책 변화:** Game Design & Math 분야의 지식 자산 보호 및 네트워크 확장.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Algorithmic Game Theory.md]]
----
diff --git a/Game Design/ARG-Alternate-Reality-Games.md b/Game Design/ARG-Alternate-Reality-Games.md
deleted file mode 100644
index 87d3fc13..00000000
--- a/Game Design/ARG-Alternate-Reality-Games.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AEB866
-category: "[[10_Wiki/💡 Topics/Game Design]]"
-confidence_score: 0.95
-tags: []
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Mega Batch 2 - Wikified ARG-Alternate-Reality-Games"
----
-
-# [[ARG-Alternate-Reality-Games]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 작업 중
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 지식 자산화 및 기존 네트워크 연동 단계.
-- **정책 변화:** Game Design 카테고리의 전문성 확보 및 링크 밀도 최적화.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/ARG-Alternate-Reality-Games.md]]
----
diff --git a/Game Design/Agency and Player Autonomy.md b/Game Design/Agency and Player Autonomy.md
deleted file mode 100644
index c97e69c7..00000000
--- a/Game Design/Agency and Player Autonomy.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-72AAF4
-category: "[[10_Wiki/💡 Topics/Game Design]]"
-confidence_score: 0.95
-tags: []
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Batch 10 - Wikified Agency and Player Autonomy"
----
-
-# [[Agency and Player Autonomy]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 핵심 내용 요약 예정
-
-## 📖 구조화된 지식 (Synthesized Content)
-세부 본문 내용 구성 예정
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 신규 지식 유입에 따른 기존 지식과의 정합성 검증 단계.
-- **정책 변화:** Game Design 분야의 체계적 지식 자산화 진행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Agency and Player Autonomy.md]]
----
diff --git a/Game Design/Albion Online (Full LootPlayer-Driven Production).md b/Game Design/Albion Online (Full LootPlayer-Driven Production).md
deleted file mode 100644
index 3af923f1..00000000
--- a/Game Design/Albion Online (Full LootPlayer-Driven Production).md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-750784
-category: "[[10_Wiki/💡 Topics/Game Design]]"
-confidence_score: 0.95
-tags: []
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Batch 11 - Wikified Albion Online (Full Loot/Player-Driven Production)"
----
-
-# [[Albion Online (Full Loot/Player-Driven Production)]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 작업 중
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 신규 지식 카테고리화 및 연결성 강화.
-- **정책 변화:** Game Design 분야의 지식 자산 보호 및 네트워크 확장.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Albion Online (Full Loot_Player-Driven Production).md]]
----
diff --git a/Game Design/Arkane Studios.md b/Game Design/Arkane Studios.md
deleted file mode 100644
index 7c857b24..00000000
--- a/Game Design/Arkane Studios.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-503A13
-category: "[[10_Wiki/💡 Topics/Game Design]]"
-confidence_score: 0.95
-tags: []
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Mega Batch 2 - Wikified Arkane Studios"
----
-
-# [[Arkane Studios]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 작업 중
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 지식 자산화 및 기존 네트워크 연동 단계.
-- **정책 변화:** Game Design 카테고리의 전문성 확보 및 링크 밀도 최적화.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Arkane Studios.md]]
----
diff --git a/Game Design/Cyber-Physical Systems (CPS).md b/Game Design/Cyber-Physical Systems (CPS).md
deleted file mode 100644
index 70c6e259..00000000
--- a/Game Design/Cyber-Physical Systems (CPS).md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-5C9113
-category: "[[10_Wiki/💡 Topics/Game Design]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Cyber-Physical Systems (CPS)"
----
-
-# [[Cyber-Physical Systems (CPS)]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Game Design 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Cyber-Physical Systems (CPS).md]]
----
diff --git a/Game Design/Elite-Athletic-Development.md b/Game Design/Elite-Athletic-Development.md
deleted file mode 100644
index 75e6f6fa..00000000
--- a/Game Design/Elite-Athletic-Development.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-6DB4E1
-category: "[[10_Wiki/💡 Topics/Game Design]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Elite-Athletic-Development"
----
-
-# [[Elite-Athletic-Development]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Game Design 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Elite-Athletic-Development.md]]
----
diff --git a/Game Design/Post-Modernist Literature in Gaming.md b/Game Design/Post-Modernist Literature in Gaming.md
deleted file mode 100644
index dd31bbc1..00000000
--- a/Game Design/Post-Modernist Literature in Gaming.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-BC9437
-category: "[[10_Wiki/💡 Topics/Game Design]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Post-Modernist Literature in Gaming"
----
-
-# [[Post-Modernist Literature in Gaming]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Game Design 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Post-Modernist Literature in Gaming.md]]
----
diff --git a/Game Design/Quantum-Game-Theory.md b/Game Design/Quantum-Game-Theory.md
deleted file mode 100644
index 25053b79..00000000
--- a/Game Design/Quantum-Game-Theory.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-238ED6
-category: "[[10_Wiki/💡 Topics/Game Design]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Quantum-Game-Theory"
----
-
-# [[Quantum-Game-Theory]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Game Design 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Quantum-Game-Theory.md]]
----
diff --git a/Game Design/Roguelike Procedural Generation.md b/Game Design/Roguelike Procedural Generation.md
deleted file mode 100644
index 020d8e6c..00000000
--- a/Game Design/Roguelike Procedural Generation.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-537B8F
-category: "[[10_Wiki/💡 Topics/Game Design]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Roguelike Procedural Generation"
----
-
-# [[Roguelike Procedural Generation]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Game Design 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Roguelike Procedural Generation.md]]
----
diff --git a/Game Design/Systems Biology.md b/Game Design/Systems Biology.md
deleted file mode 100644
index e8669e34..00000000
--- a/Game Design/Systems Biology.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-2A4288
-category: "[[10_Wiki/💡 Topics/Game Design]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Systems Biology"
----
-
-# [[Systems Biology]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Game Design 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Systems Biology.md]]
----
diff --git a/Game Design/인문학적 게임 비평 및 서사학.md b/Game Design/인문학적 게임 비평 및 서사학.md
deleted file mode 100644
index 300a3343..00000000
--- a/Game Design/인문학적 게임 비평 및 서사학.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-AC421C
-category: "[[10_Wiki/💡 Topics/Game Design]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - 인문학적 게임 비평 및 서사학"
----
-
-# [[인문학적 게임 비평 및 서사학]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Game Design 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/인문학적 게임 비평 및 서사학.md]]
----
diff --git a/General Knowledge/2026-04-15.md b/General Knowledge/2026-04-15.md
deleted file mode 100644
index 1a5b4941..00000000
--- a/General Knowledge/2026-04-15.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-D3F316
-category: "[[10_Wiki/💡 Topics/General Knowledge]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - 2026-04-15"
----
-
-# [[2026-04-15]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** General Knowledge 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/2026-04-15.md]]
----
diff --git a/General Knowledge/Blog_Content_Rules.md b/General Knowledge/Blog_Content_Rules.md
deleted file mode 100644
index 571b89bf..00000000
--- a/General Knowledge/Blog_Content_Rules.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-1FF145
-category: "[[10_Wiki/💡 Topics/General Knowledge]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Blog_Content_Rules"
----
-
-# [[Blog_Content_Rules]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** General Knowledge 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Blog_Content_Rules.md]]
----
diff --git a/General Knowledge/Blog_Title_Rules.md b/General Knowledge/Blog_Title_Rules.md
deleted file mode 100644
index ac69aaf4..00000000
--- a/General Knowledge/Blog_Title_Rules.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-566F32
-category: "[[10_Wiki/💡 Topics/General Knowledge]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Blog_Title_Rules"
----
-
-# [[Blog_Title_Rules]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** General Knowledge 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Blog_Title_Rules.md]]
----
diff --git a/General Knowledge/Brand-Identity-Management.md b/General Knowledge/Brand-Identity-Management.md
deleted file mode 100644
index cf5e53d9..00000000
--- a/General Knowledge/Brand-Identity-Management.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-F8EDF9
-category: "[[10_Wiki/💡 Topics/General Knowledge]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Brand-Identity-Management"
----
-
-# [[Brand-Identity-Management]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** General Knowledge 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Brand-Identity-Management.md]]
----
diff --git a/General Knowledge/Code Splitting  Lazy Loading.md b/General Knowledge/Code Splitting  Lazy Loading.md
deleted file mode 100644
index 8f70d49f..00000000
--- a/General Knowledge/Code Splitting  Lazy Loading.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-B933B1
-category: "[[10_Wiki/💡 Topics/General Knowledge]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Code Splitting  Lazy Loading"
----
-
-# [[Code Splitting  Lazy Loading]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** General Knowledge 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Code Splitting & Lazy Loading.md]]
----
diff --git a/General Knowledge/Description-Logics.md b/General Knowledge/Description-Logics.md
deleted file mode 100644
index 5b16b54e..00000000
--- a/General Knowledge/Description-Logics.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-088907
-category: "[[10_Wiki/💡 Topics/General Knowledge]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Description-Logics"
----
-
-# [[Description-Logics]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** General Knowledge 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Description-Logics.md]]
----
diff --git a/General Knowledge/Dopamine Signaling.md b/General Knowledge/Dopamine Signaling.md
deleted file mode 100644
index cd95038a..00000000
--- a/General Knowledge/Dopamine Signaling.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-C204E9
-category: "[[10_Wiki/💡 Topics/General Knowledge]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Dopamine Signaling"
----
-
-# [[Dopamine Signaling]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** General Knowledge 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Dopamine Signaling.md]]
----
diff --git a/General Knowledge/Markov-Random-Fields.md b/General Knowledge/Markov-Random-Fields.md
deleted file mode 100644
index 0105ada7..00000000
--- a/General Knowledge/Markov-Random-Fields.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-B14FE1
-category: "[[10_Wiki/💡 Topics/General Knowledge]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Markov-Random-Fields"
----
-
-# [[Markov-Random-Fields]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** General Knowledge 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Markov-Random-Fields.md]]
----
diff --git a/General Knowledge/Metaverse Aesthetics.md b/General Knowledge/Metaverse Aesthetics.md
deleted file mode 100644
index a3b2f761..00000000
--- a/General Knowledge/Metaverse Aesthetics.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-30803A
-category: "[[10_Wiki/💡 Topics/General Knowledge]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Metaverse Aesthetics"
----
-
-# [[Metaverse Aesthetics]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** General Knowledge 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Metaverse Aesthetics.md]]
----
diff --git a/General Knowledge/Model-Free RL vs Model-Based RL.md b/General Knowledge/Model-Free RL vs Model-Based RL.md
deleted file mode 100644
index 1ad169a1..00000000
--- a/General Knowledge/Model-Free RL vs Model-Based RL.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-B8C5BC
-category: "[[10_Wiki/💡 Topics/General Knowledge]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Model-Free RL vs Model-Based RL"
----
-
-# [[Model-Free RL vs Model-Based RL]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** General Knowledge 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Model-Free RL vs Model-Based RL.md]]
----
diff --git a/General Knowledge/Motion-Capture-Retargeting.md b/General Knowledge/Motion-Capture-Retargeting.md
deleted file mode 100644
index 7253426f..00000000
--- a/General Knowledge/Motion-Capture-Retargeting.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-34FAC7
-category: "[[10_Wiki/💡 Topics/General Knowledge]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Motion-Capture-Retargeting"
----
-
-# [[Motion-Capture-Retargeting]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** General Knowledge 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Motion-Capture-Retargeting.md]]
----
diff --git a/General Knowledge/Mycological Horror.md b/General Knowledge/Mycological Horror.md
deleted file mode 100644
index 6cd5ba75..00000000
--- a/General Knowledge/Mycological Horror.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-1D7BB8
-category: "[[10_Wiki/💡 Topics/General Knowledge]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Mycological Horror"
----
-
-# [[Mycological Horror]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** General Knowledge 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Mycological Horror.md]]
----
diff --git a/General Knowledge/OffscreenCanvas (멀티스레딩).md b/General Knowledge/OffscreenCanvas (멀티스레딩).md
deleted file mode 100644
index 6425c663..00000000
--- a/General Knowledge/OffscreenCanvas (멀티스레딩).md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-811DEC
-category: "[[10_Wiki/💡 Topics/General Knowledge]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - OffscreenCanvas (멀티스레딩)"
----
-
-# [[OffscreenCanvas (멀티스레딩)]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** General Knowledge 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/OffscreenCanvas (멀티스레딩).md]]
----
diff --git a/General Knowledge/README.md b/General Knowledge/README.md
deleted file mode 100644
index 571ee145..00000000
--- a/General Knowledge/README.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-698D8B
-category: "[[10_Wiki/💡 Topics/General Knowledge]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - README"
----
-
-# [[README]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** General Knowledge 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/README.md]]
----
diff --git a/General Knowledge/SharedArrayBuffer 보안 이슈와 Cross-Origin Isolation 설정법.md b/General Knowledge/SharedArrayBuffer 보안 이슈와 Cross-Origin Isolation 설정법.md
deleted file mode 100644
index 024371d9..00000000
--- a/General Knowledge/SharedArrayBuffer 보안 이슈와 Cross-Origin Isolation 설정법.md	
+++ /dev/null
@@ -1,40 +0,0 @@
----
-id: P-REINFORCE-AUTO-3E2EC5
-category: "[[10_Wiki/💡 Topics/General Knowledge]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - SharedArrayBuffer 보안 이슈와 Cross-Origin Isolation 설정법"
----
-
-# [[SharedArrayBuffer 보안 이슈와 Cross-Origin Isolation 설정법]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> `SharedArrayBuffer`는 멀티스레드 간 복사 비용 0으로 데이터를 공유할 수 있는 강력한 기능이지만, 타이밍 공격(Spectre 등)을 유발할 수 있는 보안 취약점이 존재하여 이를 안전하게 사용하려면 웹 서버에 **COOP 및 COEP HTTP 보안 헤더를 통한 Cross-Origin Isolation(교차 출처 격리)** 설정이 반드시 필요합니다.
-
-## 📖 구조화된 지식 (Synthesized Content)
-**1. 보안 이슈의 배경: 스펙터(Spectre) 취약점** `SharedArrayBuffer`를 고해상도 타이머와 결합하면 CPU의 예측 실행(Speculative Execution) 과정에서 발생하는 미세한 시간 차이를 측정할 수 있습니다. 해커들은 이를 악용하여 같은 브라우저 프로세스 내에 로드된 다른 사이트의 메모리 데이터(비밀번호, 세션 등)를 훔쳐보는 **부채널 공격(스펙터 취약점)**이 가능함을 발견했습니다. 이로 인해 브라우저 벤더들은 기본적으로 이 API의 사용을 전면 차단했습니다.
-
-**2. Cross-Origin Isolation (교차 출처 격리)의 도입** 멀티스레딩의 뛰어난 성능적 이점을 포기할 수 없었기에, 브라우저는 현재 웹 페이지를 외부의 신뢰할 수 없는 리소스로부터 완전히 샌드박싱하여 격리하는 **'Cross-Origin Isolated'** 상태에서만 `SharedArrayBuffer`를 예외적으로 생성할 수 있도록 보안 정책을 변경했습니다.
-
-**3. 필수 HTTP 보안 헤더 설정법 (COOP / COEP)** 이 강력한 격리 환경을 활성화하려면, 웹 애플리케이션을 호스팅하는 서버(Nginx, Node.js, Vercel 등)가 HTML 문서를 응답할 때 반드시 다음 **두 가지 HTTP 헤더를 포함**하도록 설정해야 합니다.
-
-- **`Cross-Origin-Opener-Policy: same-origin` (COOP)**: 최상위 문서가 다른 출처의 문서(예: 타 사이트가 연 팝업창)와 브라우징 컨텍스트 그룹을 공유하지 못하도록 차단하여 해커의 메모리 간섭을 막습니다.
-- **`Cross-Origin-Embedder-Policy: require-corp` (COEP)** (또는 `credentialless`): 명시적으로 CORS(교차 출처 리소스 공유) 허가를 받지 않은 모든 외부 리소스(외부 CDN 이미지, 서드파티 스크립트, iframe 등)가 내 페이지에 임베드되는 것을 원천적으로 차단합니다.
-
-**4. 설정 후 확인 및 주의사항** 서버 설정이 완료되면 클라이언트의 브라우저 콘솔에서 `crossOriginIsolated` 속성이 `true`로 반환되며, 비로소 에러 없이 `SharedArrayBuffer`를 사용할 수 있습니다. 단, 이 보안 정책은 매우 엄격하기 때문에 기존에 잘 불러와지던 **외부 이미지나 구글 애널리틱스 같은 스크립트가 렌더링 차단되는 사이드 이펙트**가 발생할 수 있습니다. 이를 해결하려면 모든 외부 리소스 태그에 `crossorigin="anonymous"` 속성을 추가하고 리소스 서버 측에서 CORS 헤더를 올바르게 열어주어야 합니다.
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** General Knowledge 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[Spectre Vulnerability]], [[HTTP Security Headers (COOP/COEP)]], [[CORS (Cross-Origin Resource Sharing)]], [[Web Worker Multi-threading]]
-- **Projects/Contexts:** [[보안이 강화된 멀티스레드 기반 React WebGL 게임 엔진 구축]]
-- **Contradictions/Notes:** 제공된 소스에 따르면 `SharedArrayBuffer`는 성능과 속도 면에서 가장 이상적이지만 로우 레벨(Low-level)의 원시 이진 데이터를 다루어야 해서 구현이 까다롭습니다. 여기에 더해 COOP/COEP 보안 헤더까지 설정해야 하므로 인프라 구축 및 외부 리소스 관리의 복잡성이 급격히 증가한다는 점을 프로젝트 기획 단계에서 반드시 고려해야 합니다.
-
----
-
-_Last updated: 2026-04-14_
-- Raw Source: [[00_Raw/2026-04-20/SharedArrayBuffer 보안 이슈와 Cross-Origin Isolation 설정법.md]]
----
diff --git a/General Knowledge/Variance-Rules.md b/General Knowledge/Variance-Rules.md
deleted file mode 100644
index 10886599..00000000
--- a/General Knowledge/Variance-Rules.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-85151B
-category: "[[10_Wiki/💡 Topics/General Knowledge]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Variance-Rules"
----
-
-# [[Variance-Rules]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** General Knowledge 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Variance-Rules.md]]
----
diff --git a/General Knowledge/마크-스위프-컴팩트(Mark-Sweep-Compact).md b/General Knowledge/마크-스위프-컴팩트(Mark-Sweep-Compact).md
deleted file mode 100644
index 49ff4761..00000000
--- a/General Knowledge/마크-스위프-컴팩트(Mark-Sweep-Compact).md	
+++ /dev/null
@@ -1,40 +0,0 @@
----
-id: P-REINFORCE-AUTO-F94637
-category: "[[10_Wiki/💡 Topics/General Knowledge]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - 마크-스위프-컴팩트(Mark-Sweep-Compact)"
----
-
-# [[마크-스위프-컴팩트(Mark-Sweep-Compact)]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-* **마크(Mark) 단계:** 
-  가비지 컬렉터가 힙 내부의 모든 객체를 탐색하여 사용 중인 라이브 객체와 그렇지 않은 객체를 식별하는 단계이다 [8, 9]. 루트(Root) 객체부터 시작하여 포인터로 연결된 객체들을 깊이 우선 탐색(DFS) 방식으로 쫓아가며 도달 가능성을 확인한다 [10, 11]. 이 과정에서 객체들은 세 가지 색상(Tri-color)으로 분류되어 마킹된다 [4, 8]. 가비지 컬렉터가 아직 발견하지 못한 객체는 '흰색(White)', 발견되었지만 이웃 객체들의 처리가 완료되지 않은 상태는 '회색(Grey)', 그리고 객체 자신과 그 이웃까지 모두 처리가 완료된 상태는 '검은색(Black)'으로 표시된다 [8, 12].
-
-* **스위프(Sweep) 단계:** 
-  마킹 단계가 끝난 후에도 도달할 수 없어 '흰색'으로 남아있는 데드 객체들의 연속된 범위를 스캔하는 단계이다 [4, 13, 14]. 가비지 컬렉터는 이 데드 객체 영역을 빈 공간(Free spaces)으로 변환하고 이를 가용 목록(Free lists)에 추가한다 [13, 14]. 가용 목록은 크기별(Small, Medium, Large 등)로 구분되어 관리되며, 이후 새로운 객체를 할당하거나 스캐빈저(Scavenger) 알고리즘에 의해 살아남은 객체들이 이전 세대(Old space)로 승격(Promotion)될 때 사용된다 [13, 14].
-
-* **컴팩트(Compact) 단계:** 
-  힙 메모리의 단편화(Fragmentation)를 줄이기 위해, 빈 공간이 많아 파편화된 페이지에서 라이브 객체들을 가용 공간이나 완전히 새로운 페이지로 이주시키는 과정이다 [2, 15, 16]. 객체가 새로운 위치로 복사되면, 원본 객체의 첫 번째 워드에 새로운 위치를 가리키는 포워딩 주소(Forwarding address)가 남겨진다 [15, 17]. 대규모 힙 공간에서 객체를 이동시키고 이를 참조하는 모든 포인터를 일일이 업데이트하는 작업은 계산 비용이 크기 때문에, 모든 스위프 주기마다 컴팩트가 일어나는 것은 아니며 메모리 파편화가 심각할 때 선택적으로 수행된다 [7, 18].
-
-* **성능 및 최적화 전략 (Orinoco 및 동시성 기법):** 
-  마크-스위프-컴팩트는 수백 메가바이트의 데이터를 처리하므로 애플리케이션 실행을 멈추는 긴 중단 시간(수백 밀리초 단위)을 초래할 수 있다 [2, 5]. V8 엔진의 Orinoco 프로젝트 등 최신 구현체들은 이를 해결하기 위해 백그라운드 스레드를 이용해 자바스크립트 실행과 동시에 마킹 작업을 수행하는 동시 마킹(Concurrent marking), 작업을 잘게 쪼개어 배분하는 점진적 마킹(Incremental marking), 그리고 당장 빈 공간이 필요해질 때까지 스위핑을 늦추는 지연 스위핑(Lazy sweeping) 기법 등을 도입하여 메인 스레드의 부담을 최소화하고 있다 [5, 19-21].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** General Knowledge 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[가비지 컬렉션(Garbage Collection)]], [[이전 세대(Old Generation/Space)]], [[스캐빈저(Scavenger)]], [[동시성 및 점진적 마킹(Concurrent & Incremental Marking)]]
-- **Projects/Contexts:** [[V8 자바스크립트 엔진]], [[자바 가상 머신(JVM)]], [[Orinoco 프로젝트]]
-- **Contradictions/Notes:** 소스 전반에서 마크-스위프-컴팩트의 기본 원리에는 차이가 없으나, 작동 환경(예: V8 엔진 대 IBM JVM)에 따라 이 알고리즘을 트리거하는 조건이나 조정 가능한 커맨드라인 옵션(`-Xcompactgc`, `--trace-gc` 등)은 구체적인 구현체에 따라 각기 다르게 제어된다는 점이 확인된다 [18, 22].
-
----
-*Last updated: 2026-04-19*
-- Raw Source: [[00_Raw/2026-04-20/마크-스위프-컴팩트(Mark-Sweep-Compact).md]]
----
diff --git a/General Knowledge/무제.md b/General Knowledge/무제.md
deleted file mode 100644
index afe88b10..00000000
--- a/General Knowledge/무제.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-D69A80
-category: "[[10_Wiki/💡 Topics/General Knowledge]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - 무제"
----
-
-# [[무제]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** General Knowledge 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/무제.md]]
----
diff --git a/General Knowledge/이벤트 포워딩(Event Forwarding).md b/General Knowledge/이벤트 포워딩(Event Forwarding).md
deleted file mode 100644
index 6ac7a117..00000000
--- a/General Knowledge/이벤트 포워딩(Event Forwarding).md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-797EC7
-category: "[[10_Wiki/💡 Topics/General Knowledge]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - 이벤트 포워딩(Event Forwarding)"
----
-
-# [[이벤트 포워딩(Event Forwarding)]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** General Knowledge 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/이벤트 포워딩(Event Forwarding).md]]
----
diff --git a/General Knowledge/환영합니다.md b/General Knowledge/환영합니다.md
deleted file mode 100644
index f6002d14..00000000
--- a/General Knowledge/환영합니다.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-BD84CA
-category: "[[10_Wiki/💡 Topics/General Knowledge]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - 환영합니다"
----
-
-# [[환영합니다]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** General Knowledge 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/환영합니다!.md]]
----
diff --git a/Graphics & Performance/3D Gaussian Splatting (3DGS).md b/Graphics & Performance/3D Gaussian Splatting (3DGS).md
deleted file mode 100644
index 807a59d4..00000000
--- a/Graphics & Performance/3D Gaussian Splatting (3DGS).md	
+++ /dev/null
@@ -1,37 +0,0 @@
----
-id: P-REINFORCE-AI-AC09DA
-category: "[[10_Wiki/💡 Topics/Graphics & Performance]]"
-confidence_score: 0.95
-tags: []
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Batch 9 - Wikified 3D Gaussian Splatting (3DGS)"
----
-
-# [[3D Gaussian Splatting (3DGS)]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 3D Gaussian Splatting (3DGS)은 3D 스플랫(splat)들로 구성된 명시적 표현을 사용하여 고품질의 실시간 렌더링을 구현하는 혁신적인 기법이다 [1, 2]. 각 3D 가우시안은 중심 위치, 3D 공분산 행렬, 최대 불투명도, 그리고 구면 조화(Spherical Harmonics) 계수를 활용한 시점 종속적 색상으로 정의된다 [2]. 올바른 렌더링을 위해 카메라로부터의 거리를 기준으로 가우시안들을 뒤에서 앞으로 정렬(depth sorting)하고 알파 블렌딩(alpha-blending)하는 과정이 필수적이며 [3, 4], 미분 가능한 특성 덕분에 브라우저 환경에서 고품질 재구성 및 생성적 3D 모델링에 활발히 응용되고 있다 [1].
-
-## 📖 구조화된 지식 (Synthesized Content)
-- **기본 동작 원리와 렌더링 구조:**
-  3DGS는 장면을 구성하는 3D 가우시안들을 2D 이미지 평면으로 투영하여 렌더링을 수행한다 [2, 4]. 투영된 2D 공분산 행렬과 학습된 불투명도를 기반으로 각 픽셀에 대한 알파 기여도를 계산하며, 카메라 시점 방향에 따른 구면 조화 함수를 평가하여 반사 효과 및 최종 색상을 결정한다 [2, 4]. 투명도를 올바르게 처리하기 위해 수백만 개의 가우시안을 매 프레임마다 카메라와의 거리에 따라 뒤에서 앞으로 정렬해야 하는 막대한 연산이 요구된다 [3-5].
-
-- **WebGL 환경에서의 성능 한계 및 오류:**
-  기존의 WebGL API는 범용적인 GPU 연산(Compute) 기능을 지원하지 않아, 3DGS의 핵심인 깊이 정렬 작업을 JavaScript나 WebAssembly를 통해 CPU에 오프로드해야 한다 [6-8]. 이는 CPU가 정렬을 마친 뒤 큰 버퍼를 GPU로 업로드하고 드로우 콜을 발생시켜야 하는 심각한 동기화 병목 현상을 유발하며, 장면이 복잡해질수록 16.67ms의 프레임 예산을 맞추지 못하게 만든다 [6, 8]. 실제로 CesiumJS와 같은 시스템에서는 대규모 데이터셋 처리 시 1프레임 내에 정렬이 끝나지 않아 여러 개의 Promise 체인이 서로 간섭하는 경합 조건(race condition)이 발생하며, 이로 인해 모델이 깜빡이거나 렌더링되지 않는 WebGL 오류 및 마이크로 스터터링(micro-stuttering)이 보고되었다 [9-12].
-
-- **WebGPU 및 WebSplatter를 통한 GPU 파이프라인 최적화:**
-  WebGL의 구조적 한계를 극복하기 위해 WebGPU의 컴퓨트 셰이더(Compute Shader)를 활용하는 접근법이 대두되었다 [6, 7, 13]. 대표적으로 WebSplatter 프레임워크는 깊이 정렬과 시점 적응형 평가를 모두 GPU 연산으로 이전하여 CPU-GPU 간의 동기화 오버헤드를 제거하였다 [6, 14]. 특히 WebGPU 환경에 글로벌 아토믹(global atomics) 기능이 부족한 점을 우회하기 위해, 하드웨어 스케줄링에 구애받지 않는 '대기 없는(wait-free) 계층적 기수 정렬(radix sort)' 알고리즘을 도입하였다 [6, 15, 16]. 또한, 래스터화 이전 단계에서 불투명도 및 시야 범위(Bounding Box)를 기준으로 화면 밖 스플랫을 선제적으로 제거하는 동적 컬링(culling)을 적용하여 메모리 대역폭과 오버드로우를 크게 줄였다 [15, 17-19].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 신규 문서로, 기존 정보와의 충돌 분석 예정.
-- **정책 변화:** Graphics & Performance 카테고리의 지식 연결망 강화를 위한 표준 위키화 적용.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[WebGPU]], [[WebGL]], [[Compute Shader]]
-- **Projects/Contexts:** [[WebSplatter]], [[CesiumJS]]
-- **Contradictions/Notes:** WebGL 기반의 기존 3DGS 구현은 정렬 작업을 CPU에 의존하므로 동기화 병목과 프레임 지연이 발생하지만, WebGPU 기반의 WebSplatter는 파이프라인 전체를 GPU에서 병렬 연산함으로써 기존 웹 뷰어 대비 최대 4.5배의 렌더링 속도 향상과 낮은 메모리 소모를 달성한다 [6, 8, 15, 20].
-
----
-*Last updated: 2026-04-19*
-- Raw Source: [[00_Raw/2026-04-20/3D Gaussian Splatting (3DGS).md]]
----
diff --git a/Graphics & Performance/ANGLE (Almost Native Graphics Layer Engine).md b/Graphics & Performance/ANGLE (Almost Native Graphics Layer Engine).md
deleted file mode 100644
index 3235896a..00000000
--- a/Graphics & Performance/ANGLE (Almost Native Graphics Layer Engine).md	
+++ /dev/null
@@ -1,33 +0,0 @@
----
-id: P-REINFORCE-AUTO-46B173
-category: "[[10_Wiki/💡 Topics/Graphics & Performance]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - ANGLE (Almost Native Graphics Layer Engine)"
----
-
-# [[ANGLE (Almost Native Graphics Layer Engine)]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> ANGLE(Almost Native Graphics Layer Engine)은 주로 Windows 플랫폼의 웹 브라우저(Chrome, Firefox, Opera 등)에서 사용되는 그래픽 명령어 변환기입니다. 이 엔진은 WebGL의 OpenGL ES 호출을 Direct3D 11 또는 12 명령으로 변환하는 역할을 수행합니다 [1, 2]. 고도로 최적화되어 있지만, 변환 과정에서 각 드로우 콜(Draw call)마다 고정된 마이크로 레이턴시(Micro-latency)를 유발하는 성능적 특징이 있습니다 [1, 3].
-
-## 📖 구조화된 지식 (Synthesized Content)
-- **역할 및 플랫폼:** ANGLE은 Windows 환경에서 Chrome, Firefox, Opera와 같은 주요 브라우저가 WebGL(OpenGL ES) 호출을 Direct3D 11 또는 12로 변환할 때 사용됩니다 [1, 2].
-- **명령어 변환 오버헤드:** 이 변환 과정은 고도로 최적화되어 있음에도 불구하고, 명령어 제출(Command submission) 단계에 상당한 마이크로 레이턴시를 추가합니다 [1]. 각 드로우 콜마다 수 마이크로초(microseconds)의 고정된 오버헤드가 발생합니다 [3].
-- **성능 병목 현상:** 수천 개의 드로우 콜이 발생하는 애플리케이션의 경우 이러한 작은 오버헤드들이 누적되어, GPU가 비교적 유휴 상태임에도 불구하고 CPU가 병목의 원인이 되는 현상(death by a thousand cuts)을 초래합니다 [3].
-- **디버깅 및 우회 방법:** 개발자는 네이티브 OpenGL 구현을 테스트하기 위해 ANGLE을 우회할 수 있습니다 [2]. Chrome에서는 `--use-gl=desktop` 명령줄 인수를 사용하여 시작하고, Firefox에서는 `about:config`에서 `webgl.prefer-native-gl`을 활성화하여 우회합니다 [2]. 현재 ANGLE이 사용 중인지는 WebGL Report나 `chrome://gpu/` 페이지에서 확인할 수 있습니다 [2].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Graphics & Performance 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[WebGL]], [[OpenGL ES]], [[Direct3D]], [[Micro-latency]], [[Draw Call]]
-- **Projects/Contexts:** [[Chrome]], [[Firefox]], [[Opera]]
-- **Contradictions/Notes:** ANGLE은 브라우저에서 원활한 그래픽 처리를 위해 도입된 고도로 최적화된 변환기이지만, 드로우 콜이 많은 환경에서는 역설적이게도 이 변환 작업 자체가 누적되어 CPU 병목을 일으키는 주된 원인이 됩니다 [3].
-
----
-*Last updated: 2026-04-19*
-- Raw Source: [[00_Raw/2026-04-20/ANGLE (Almost Native Graphics Layer Engine).md]]
----
diff --git a/Graphics & Performance/ANGLE.md b/Graphics & Performance/ANGLE.md
deleted file mode 100644
index 483050f8..00000000
--- a/Graphics & Performance/ANGLE.md	
+++ /dev/null
@@ -1,33 +0,0 @@
----
-id: P-REINFORCE-26A7F5
-category: "[[10_Wiki/💡 Topics/Graphics & Performance]]"
-confidence_score: 0.95
-tags: []
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Mega Batch - Wikified ANGLE"
----
-
-# [[ANGLE]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> ANGLE(Almost Native Graphics Layer Engine)은 Windows 플랫폼에서 WebGL(OpenGL ES) 명령을 Direct3D 11 또는 12로 변환해 주는 변환기(translator)입니다 [1, 2]. Chrome, Firefox, Opera와 같은 브라우저에서 널리 사용되며, 고도로 최적화되어 있음에도 불구하고 그래픽 파이프라인의 명령 제출(command submission) 단계에서 마이크로 레이턴시(micro-latency)를 유발하는 주요 원인 중 하나로 작용합니다 [1-3].
-
-## 📖 구조화된 지식 (Synthesized Content)
-* **주요 기능 및 사용 환경:** Windows 플랫폼에서 Chrome, Firefox, Opera 등의 웹 브라우저는 WebGL API의 기반이 되는 OpenGL ES 호출을 Direct3D로 번역하기 위해 ANGLE을 사용합니다 [1, 2]. 일반적인 Windows 엔드 유저들은 기본적으로 ANGLE이 활성화된 상태로 웹 브라우저를 사용하게 됩니다 [2].
-* **마이크로 레이턴시(Micro-latency) 발생:** ANGLE의 변환 프로세스는 매우 고도로 최적화되어 있으나, 여전히 각 드로우 콜(draw call)마다 수 마이크로초(microseconds) 단위의 고정된 오버헤드를 발생시킵니다 [3]. 이는 그래픽 파이프라인의 명령 제출 단계에 상당한 마이크로 레이턴시를 추가합니다 [1, 4].
-* **CPU 병목 현상 유발:** 수천 개의 드로우 콜이 발생하는 3D 애플리케이션에서는 ANGLE로 인한 미세한 오버헤드가 지속적으로 누적됩니다 [3]. 이로 인해 GPU가 비교적 유휴(idle) 상태에 있음에도 불구하고 CPU가 처리 한계에 부딪히는 "가랑비에 옷 젖는(death by a thousand cuts)" 형태의 병목 현상이 발생할 수 있습니다 [3].
-* **테스트 및 디버깅:** 개발자는 성능 프로파일링이나 네이티브 OpenGL 구현을 테스트할 목적으로 특정 브라우저 명령줄 인수(예: Chrome의 `--use-gl=desktop`)를 사용하거나 설정을 변경하여 ANGLE을 우회(bypass)할 수 있습니다 [2].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 지식 자산화 및 기존 네트워크 연동 단계.
-- **정책 변화:** Graphics & Performance 카테고리의 전문성 확보 및 링크 밀도 최적화.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[WebGL]], [[OpenGL ES]], [[Direct3D]], [[Micro-latency]]
-- **Projects/Contexts:** [[Web Graphics Pipelines]]
-- **Contradictions/Notes:** ANGLE의 변환 작업은 "고도로 최적화(highly optimized)"되어 있지만, 역설적으로 많은 드로우 콜을 요구하는 환경에서는 이 최적화된 변환 작업조차 누적되어 CPU 병목의 주요 원인이 됩니다 [3].
-
----
-*Last updated: 2026-04-19*
-- Raw Source: [[00_Raw/2026-04-20/ANGLE.md]]
----
diff --git a/Graphics & Performance/Agency-Narrative Integration.md b/Graphics & Performance/Agency-Narrative Integration.md
deleted file mode 100644
index 3567a743..00000000
--- a/Graphics & Performance/Agency-Narrative Integration.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-2E74EC
-category: "[[10_Wiki/💡 Topics/Graphics & Performance]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Agency-Narrative Integration"
----
-
-# [[Agency-Narrative Integration]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Graphics & Performance 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Agency-Narrative Integration.md]]
----
diff --git a/Graphics & Performance/Alpha Blending.md b/Graphics & Performance/Alpha Blending.md
deleted file mode 100644
index 7963e00b..00000000
--- a/Graphics & Performance/Alpha Blending.md	
+++ /dev/null
@@ -1,32 +0,0 @@
----
-id: P-REINFORCE-25F1DA
-category: "[[10_Wiki/💡 Topics/Graphics & Performance]]"
-confidence_score: 0.95
-tags: []
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Mega Batch - Wikified Alpha Blending"
----
-
-# [[Alpha Blending]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 투명하거나 반투명한 객체를 렌더링할 때 시각적 결함 없이 정확한 투명도를 표현하기 위한 렌더링 혼합 기법입니다 [1]. 올바른 알파 블렌딩 결과를 얻기 위해서는 반드시 객체를 '뒤에서 앞으로(Back-to-Front)' 순서로 정렬하여 그려야 한다는 제약이 있습니다 [1]. 그 외 알파 블렌딩의 구체적인 수학적 원리나 연산식에 대해서는 소스에 관련 정보가 부족합니다.
-
-## 📖 구조화된 지식 (Synthesized Content)
-- **투명도 렌더링과 정렬의 필수성:** 투명하거나 반투명한 3D 객체에서 올바른 알파 블렌딩(Alpha Blending) 결과를 얻어내려면, 렌더링 파이프라인에서 카메라와 멀리 있는 객체부터 가까운 객체 순으로 렌더링하는 '뒤에서 앞으로(Back-to-Front)' 정렬 과정이 필수적으로 동반되어야 합니다 [1].
-- **InstancedMesh 환경에서의 구조적 한계:** 대규모 렌더링 최적화에 쓰이는 `InstancedMesh`는 단일 드로우 콜 내에서 인스턴스들의 렌더링 순서를 동적으로 변경하는 기본 기능을 제공하지 않습니다 [1]. 따라서 카메라 시점이 변할 때마다 객체 간의 앞뒤 관계가 뒤섞이게 되며, 이로 인해 알파 블렌딩이 비정상적으로 계산되어 투명도가 깨지는 시각적 결함이 발생합니다 [1].
-- **해결 방식 및 병목 현상:** 알파 블렌딩을 위한 투명도 정렬(Transparency sorting) 문제를 해결하려면 매 프레임마다 카메라와의 거리를 계산하고 버퍼 내의 행렬 데이터를 재정렬(예: Radix Sort)하는 로직을 추가해야 합니다 [1, 2]. 그러나 수만 개의 객체에 대해 이를 수행할 경우 CPU 메인 스레드에 치명적인 부하를 야기하므로 성능과 품질 사이의 타협이 필요합니다 [1].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 지식 자산화 및 기존 네트워크 연동 단계.
-- **정책 변화:** Graphics & Performance 카테고리의 전문성 확보 및 링크 밀도 최적화.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[Transparency Sorting]], [[InstancedMesh]], [[Overdraw]]
-- **Projects/Contexts:** 대규모 유리창 건물이나 투명한 숲 등 다수의 반투명 객체를 `InstancedMesh` 등을 사용하여 실시간으로 렌더링하고 최적화해야 하는 웹 그래픽스 및 게임 프로젝트 맥락 [1, 2].
-- **Contradictions/Notes:** 소스에 관련 정보가 부족합니다. (제공된 소스에서는 알파 블렌딩 자체의 개념보다는, 투명 객체 렌더링 정렬 문제의 원인으로서만 간략히 언급되고 있습니다.)
-
----
-*Last updated: 2026-04-19*
-- Raw Source: [[00_Raw/2026-04-20/Alpha Blending.md]]
----
diff --git a/Graphics & Performance/Apple-Human-Interface-Guidelines.md b/Graphics & Performance/Apple-Human-Interface-Guidelines.md
deleted file mode 100644
index d9651b9b..00000000
--- a/Graphics & Performance/Apple-Human-Interface-Guidelines.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-D4F8B4
-category: "[[10_Wiki/💡 Topics/Graphics & Performance]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Apple-Human-Interface-Guidelines"
----
-
-# [[Apple-Human-Interface-Guidelines]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Graphics & Performance 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Apple-Human-Interface-Guidelines.md]]
----
diff --git a/Graphics & Performance/Augmented Reality (AR).md b/Graphics & Performance/Augmented Reality (AR).md
deleted file mode 100644
index 33a973a6..00000000
--- a/Graphics & Performance/Augmented Reality (AR).md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-003033
-category: "[[10_Wiki/💡 Topics/Graphics & Performance]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Augmented Reality (AR)"
----
-
-# [[Augmented Reality (AR)]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Graphics & Performance 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Augmented Reality (AR).md]]
----
diff --git a/Graphics & Performance/Augmented Reality Navigation Systems.md b/Graphics & Performance/Augmented Reality Navigation Systems.md
deleted file mode 100644
index ad0b82ba..00000000
--- a/Graphics & Performance/Augmented Reality Navigation Systems.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-054006
-category: "[[10_Wiki/💡 Topics/Graphics & Performance]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Augmented Reality Navigation Systems"
----
-
-# [[Augmented Reality Navigation Systems]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Graphics & Performance 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Augmented Reality Navigation Systems.md]]
----
diff --git a/Graphics & Performance/Autonomous Vehicle Perception.md b/Graphics & Performance/Autonomous Vehicle Perception.md
deleted file mode 100644
index 93024317..00000000
--- a/Graphics & Performance/Autonomous Vehicle Perception.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-A226DB
-category: "[[10_Wiki/💡 Topics/Graphics & Performance]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Autonomous Vehicle Perception"
----
-
-# [[Autonomous Vehicle Perception]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Graphics & Performance 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Autonomous Vehicle Perception.md]]
----
diff --git a/Graphics & Performance/BIM 모델 렌더링.md b/Graphics & Performance/BIM 모델 렌더링.md
deleted file mode 100644
index 20dca128..00000000
--- a/Graphics & Performance/BIM 모델 렌더링.md	
+++ /dev/null
@@ -1,43 +0,0 @@
----
-id: P-REINFORCE-AUTO-B22078
-category: "[[10_Wiki/💡 Topics/Graphics & Performance]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - BIM 모델 렌더링"
----
-
-# [[BIM 모델 렌더링]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> BIM(건축 정보 모델) 및 CAD 모델 렌더링은 수십만 개의 고유하거나 반복되는 기하학적 요소로 이루어진 대규모 건설 데이터를 웹 브라우저 등에서 효율적으로 시각화하는 과정입니다 [1-3]. 이 과정에서는 막대한 드로우 콜(Draw call)과 메모리 대역폭 한계로 인한 성능 저하를 방지하기 위해 형상 병합(Merging), 인스턴싱(Instancing), 배칭(Batching) 등의 기법을 적재적소에 활용해야 합니다 [4-7]. 최근에는 WebGPU를 도입하여 500MB 이상의 거대 BIM 데이터를 실시간으로 렌더링하고 컴퓨트 셰이더를 통해 무거운 연산을 병렬 처리하는 방식이 대규모 건설 뷰어의 핵심 기술로 부상하고 있습니다 [8-10].
-
-## 📖 구조화된 지식 (Synthesized Content)
-- **BIM 모델의 구조적 특징과 렌더링 과제:**
-  BIM 또는 CAD 모델은 벽, 바닥, 파이프, 문, 창문 등 수많은 개별 부품(Component)으로 구성되어 있습니다 [1]. 이를 각각 개별적인 메쉬(Mesh)로 렌더링할 경우 CPU에서 GPU로 그리기 명령을 보내는 드로우 콜이 폭증하여 심각한 병목 현상이 발생합니다 [3]. 특히 통합 GPU 환경 등에서는 대용량 정점 데이터를 처리할 때 메모리 대역폭의 한계에 부딪혀 프레임 스터터링이 일어날 수 있습니다 [11, 12].
-
-- **하이브리드 렌더링 및 최적화 전략 (Fragment 시스템):**
-  건설 데이터의 렌더링 효율을 높이기 위해 IFC.js 프로젝트 등에서는 객체의 특성에 맞춘 하이브리드 방식을 제안합니다 [5, 13]. 벽이나 바닥처럼 폴리곤 수는 적으나 형태가 고유한 객체들은 단일 `BufferGeometry`로 병합(Merging)하여 드로우 콜을 최소화합니다 [5, 14]. 반면, 의자나 문 등 형태가 동일하고 폴리곤이 많은 객체는 메모리 사용량이 적은 `InstancedMesh`를 활용하여 수백, 수천 개의 복제본을 단 한 번의 드로우 콜로 렌더링합니다 [4-6].
-
-- **BatchedMesh를 활용한 이질적 기하학 처리:**
-  Revit 등에서 추출한 모델 내에서 재질은 같으나 기하학적 형태가 다른 수많은 벽이나 부품들을 렌더링할 때는 `BatchedMesh`가 유용하게 사용됩니다 [6, 15, 16]. 이는 단일 렌더 콜로 거대한 어셈블리를 그리면서도 각 객체의 가시성과 변환 행렬, 색상 등을 개별적으로 쉽게 제어 및 수정할 수 있게 해줍니다 [7, 16].
-
-- **WebGPU를 통한 대규모 건설 뷰어의 진화:**
-  2026년 기준, 500MB 이상의 거대한 대형 건설 뷰어에서는 성능 한계를 극복하기 위해 WebGPU의 네이티브 기능이 필수적입니다 [8, 9]. WebGPU의 컴퓨트 셰이더(Compute Shader)를 활용하면 대규모 BIM 데이터 세트의 실시간 필터링, 물리 연산, 충돌 감지 등을 GPU에서 병렬로 처리하여 메인 스레드의 부하를 없애고 기존보다 100배 이상의 엄청난 처리 속도 향상을 이끌어낼 수 있습니다 [10, 17, 18].
-
-- **CAD 데이터 특화 렌더링 최적화 기법:**
-  거대한 좌표계를 가지는 CAD 모델 렌더링 시 32-bit 부동소수점 한계로 인해 모델이 떨리는 정밀도 저하(Precision collapse) 현상을 막기 위해 기하학적 데이터를 GPU에 업로드하기 전 기준점을 중심으로 좌표를 오프셋(Re-centering)하는 작업이 필요합니다 [19]. 또한 내부 구조가 겹겹이 존재하는 복잡한 어셈블리 모델은 오버드로우(Overdraw)가 심하므로, 색상 기록 없이 Z-버퍼만 채우는 깊이 사전 패스(Depth Pre-pass)를 수동으로 적용하여 프래그먼트 셰이더의 연산 부하를 획기적으로 줄일 수 있습니다 [20, 21].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Graphics & Performance 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[InstancedMesh]], [[BatchedMesh]], [[WebGPU]], [[Draw Call]]
-- **Projects/Contexts:** [[IFC.js]], [[Revit 모델 렌더링]], [[대규모 건설 뷰어(Construction Viewers)]]
-- **Contradictions/Notes:** 다양한 형태의 객체를 단일 드로우 콜로 처리하여 성능을 높이기 위해 `BatchedMesh`를 사용하는 것이 일반적으로 권장되지만, 수백만 개의 정점과 수십만 개의 서브 지오메트리가 있는 거대한 Revit 기반 건축 모델에 이를 그대로 적용할 경우, 내부 버퍼 업데이트와 데이터 복사 등의 오버헤드로 인해 오히려 CPU 사용량이 40~60% 이상 폭증하고 프레임(FPS)이 급락하는 심각한 성능 역전 현상이 보고되기도 하므로 데이터 규모에 따른 주의가 필요합니다 [15, 22-25].
-
----
-*Last updated: 2026-04-19*
-- Raw Source: [[00_Raw/2026-04-20/BIM 모델 렌더링.md]]
----
diff --git a/Graphics & Performance/BIM 모델 시뮬레이션.md b/Graphics & Performance/BIM 모델 시뮬레이션.md
deleted file mode 100644
index aa4723dc..00000000
--- a/Graphics & Performance/BIM 모델 시뮬레이션.md	
+++ /dev/null
@@ -1,37 +0,0 @@
----
-id: P-REINFORCE-AUTO-B4BA95
-category: "[[10_Wiki/💡 Topics/Graphics & Performance]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - BIM 모델 시뮬레이션"
----
-
-# [[BIM 모델 시뮬레이션]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> BIM(Building Information Modeling) 모델 시뮬레이션은 수십만 개의 개별 부품으로 구성된 건축 및 건설 데이터를 웹 환경 등에서 실시간으로 렌더링하고 상호작용하는 기술입니다 [1, 2]. 이러한 대규모 데이터셋은 CPU와 GPU 간의 병목 현상을 쉽게 유발하므로 성능 유지를 위해 인스턴싱, 지오메트리 병합, 그리고 최신 그래픽스 API의 활용이 필수적입니다 [2, 3]. 최근에는 대형 모델 처리를 위해 WebGPU의 컴퓨트 셰이더를 활용하여 연산 부하를 획기적으로 낮추는 방법이 도입되고 있습니다 [4, 5].
-
-## 📖 구조화된 지식 (Synthesized Content)
-*   **BIM 데이터의 렌더링 한계**
-    BIM 및 CAD 모델은 벽, 바닥, 파이프, 공조 시스템 등 수천에서 수십만 개의 서로 다른 부품으로 구성되는 경우가 많습니다 [1-3]. 이 때문에 모든 객체가 동일한 기하학적 구조를 공유해야만 하는 **`InstancedMesh` 최적화 기법을 단독으로 적용하는 것은 불가능하거나 매우 비효율적**입니다 [3]. 예를 들어, 건물의 콘크리트 벽면들은 동일한 재질을 공유하지만 고유한 형태와 크기를 가지기 때문입니다 [6].
-*   **하이브리드 및 배치(Batching) 렌더링 전략**
-    문이나 창문처럼 기하학적 형태가 반복되는 객체는 인스턴싱(`InstancedMesh`)을 사용하고, 고유한 형태를 지닌 벽이나 바닥 같은 객체는 `BatchedMesh`를 사용하여 단일 드로우 콜로 묶어 처리하는 방식이 고려됩니다 [1, 7]. 하지만 1,200만 개 이상의 너무 거대한 폴리곤 데이터를 `BatchedMesh`로 묶을 경우, 버퍼 패킹 과정에서 오히려 CPU 오버헤드가 급증하여 일반적인 메쉬 렌더링보다 프레임이 심각하게 떨어지는 병목 현상이 보고되기도 합니다 [8-11]. 
-*   **WebGPU와 컴퓨트 셰이더(Compute Shader)의 활용**
-    대규모 BIM 데이터셋의 실시간 필터링, 충돌 감지, 구조 시뮬레이션과 같이 자원 소모가 큰 작업에는 **WebGPU의 컴퓨트 셰이더가 게임 체인저로 활용**됩니다 [4, 5]. 이는 CPU의 메인 스레드를 짓누르던 병목 작업들을 GPU의 수많은 코어에서 병렬로 처리하게 함으로써, 성능을 기존 대비 10배에서 100배까지 향상시킬 수 있습니다 [2, 5].
-*   **프로젝트 규모에 따른 플랫폼 선택 기준**
-    500MB 이하의 표준적인 BIM 뷰어나 모델 구성기(Configurator)를 개발할 때는, 빠르고 풍부한 생태계를 갖춘 **Three.js**를 사용하는 것이 엔지니어링 노력 대비 훌륭한 성능을 제공합니다 [12, 13]. 그러나 모델 용량이 500MB를 초과하는 도시 규모의 디지털 트윈이거나, 실시간 구조 응력 시뮬레이션 같은 극단적인 성능이 요구될 경우에는 직접적인 GPU 메모리 관리와 파이프라인 제어가 가능한 **Native WebGPU** 시스템을 구축하는 것이 필수적입니다 [14, 15].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Graphics & Performance 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[WebGPU]], [[InstancedMesh]], [[BatchedMesh]], [[Compute Shader]]
-- **Projects/Contexts:** [[대규모 건설 뷰어(Large-Scale Construction Viewers)]]
-- **Contradictions/Notes:** 다양한 부품이 혼재된 BIM 모델 최적화를 위해 다중 드로우를 하나로 묶는 `BatchedMesh`가 대안으로 제시되지만, 정점 및 면(face)의 수가 1,000만 개 단위를 넘어갈 정도로 너무 큰 경우에는 과도한 버퍼 연산으로 인해 CPU 점유율이 오히려 치솟는 치명적인 성능 저하가 발생한다는 한계가 있습니다 [8, 9, 11]. 
-
----
-*Last updated: 2026-04-19*
-- Raw Source: [[00_Raw/2026-04-20/BIM 모델 시뮬레이션.md]]
----
diff --git a/Graphics & Performance/BVH.md b/Graphics & Performance/BVH.md
deleted file mode 100644
index 5851c9fe..00000000
--- a/Graphics & Performance/BVH.md	
+++ /dev/null
@@ -1,33 +0,0 @@
----
-id: P-REINFORCE-AUTO-D211FC
-category: "[[10_Wiki/💡 Topics/Graphics & Performance]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - BVH"
----
-
-# [[BVH]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> BVH(Bounding Volume Hierarchy)는 3D 환경에서 빠르고 효율적인 레이캐스팅(Raycasting), 절두체 컬링(Frustum Culling) 및 공간 질의(Spatial Queries)를 가능하게 하는 정교한 공간 분할 자료구조입니다 [1, 2]. 이는 렌더링, 조명 및 그림자 연산, 충돌 처리, 자산의 메모리 로딩 등 광범위한 최적화를 주도하는 핵심 기반 기술입니다 [3]. Three.js 생태계에서는 주로 대규모 폴리곤이나 복잡한 인스턴스 씬에서의 성능을 극대화하기 위해 활용됩니다 [1, 4].
-
-## 📖 구조화된 지식 (Synthesized Content)
-- **성능 최적화 및 고속 레이캐스팅:** BVH는 복잡한 기하학적 구조를 가진 대화형 씬에서 레이캐스팅을 가속화하는 데 필수적인 요소입니다 [4]. `three-mesh-bvh` 라이브러리를 사용할 경우 60fps 환경에서 8만 개 이상의 폴리곤에 대한 레이캐스팅을 병목 없이 수행할 수 있습니다 [4, 5].
-- **대규모 씬의 공간 분할(Spatial Partitioning):** BVH는 공간 분할 및 인덱싱(Indexing) 스키마를 통해 CPU 측의 연산 부담을 줄여줍니다 [3, 6]. 수만 개의 인스턴스가 존재하는 대규모 씬에서 겹쳐 있거나 가려진 객체를 정밀하게 선택(Lasso Selection 등)하려면 BVH와 같은 공간 분할 자료구조 구축이 필수적입니다 [2]. 
-- **InstancedMesh와의 통합 메커니즘:** 기본적으로 `three-mesh-bvh`는 `InstancedMesh` 내의 개별 기하학적 구조(Geometry)에 대한 BVH 기반 레이캐스팅은 지원하지만, 인스턴스 객체들의 전체 집합 자체를 대상으로 작동하지는 않습니다 [7, 8]. 그러나 `InstancedMesh2`와 같은 확장 라이브러리들은 내부적으로 BVH 공간 인덱스(Spatial Index)를 구축하여, 인스턴스 단위의 빠른 레이캐스팅과 개별 절두체 컬링(Frustum Culling)을 효과적으로 지원하도록 설계되었습니다 [9-12].
-- **API 및 유틸리티:** 개발 시 BVH의 바운딩 트리 구조를 시각화하기 위해 과거에 사용되던 `MeshBVHVisualizer` 클래스는 더 이상 사용되지 않으며(deprecated), 최신 라이브러리에서는 `MeshBVHHelper`의 사용을 권장합니다 [8, 13].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Graphics & Performance 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[Raycasting]], [[Frustum Culling]], [[InstancedMesh]], [[Spatial Indexing]]
-- **Projects/Contexts:** [[three-mesh-bvh]], [[InstancedMesh2]]
-- **Contradictions/Notes:** 기본 `three-mesh-bvh` 라이브러리만으로는 `InstancedMesh`의 전체 인스턴스 집합에 대한 직접적인 공간 조회가 제한적이라는 점이 지적되지만 [7], 커뮤니티에서 개발된 `InstancedMesh2` 라이브러리가 BVH 공간 인덱스를 내장함으로써 이러한 한계를 성공적으로 극복하고 전체 인스턴스의 빠른 컬링 및 레이캐스팅을 가능하게 합니다 [10, 12].
-
----
-*Last updated: 2026-04-19*
-- Raw Source: [[00_Raw/2026-04-20/BVH.md]]
----
diff --git a/Graphics & Performance/Babylonjs.md b/Graphics & Performance/Babylonjs.md
deleted file mode 100644
index 2be3b45c..00000000
--- a/Graphics & Performance/Babylonjs.md	
+++ /dev/null
@@ -1,41 +0,0 @@
----
-id: P-REINFORCE-AUTO-852A59
-category: "[[10_Wiki/💡 Topics/Graphics & Performance]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Babylonjs"
----
-
-# [[Babylonjs]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> Babylon.js는 수천에서 수만 개의 메쉬로 구성된 대규모 3D 씬을 웹 환경에서 렌더링하고 관리하는 데 사용되는 그래픽 엔진입니다. 렌더링 성능 및 메모리 최적화를 위해 MergeMesh, 인스턴스 메쉬(Instanced Meshes), 그리고 솔리드 파티클 시스템(Solid Particle System, SPS) 등의 기법을 지원합니다. 대규모 인스턴스 처리 시 발생하는 CPU 병목 현상을 극복하기 위해 하드웨어 제어력이 높은 WebGPU 기술의 도입이 적극적으로 논의되고 있습니다.
-
-## 📖 구조화된 지식 (Synthesized Content)
-* **렌더링 최적화 기법**
-  대량의 객체를 렌더링할 때 발생하는 메쉬 생성 시간, FPS 성능 저하, 메모리 소비 문제를 해결하기 위해 `MergeMesh`, 솔리드 파티클 시스템(SPS), 인스턴스 메쉬(Instanced Meshes) 기술이 주로 사용됩니다 [1, 2].
-
-* **인스턴스 메쉬(Instanced Meshes)와 SPS의 특성 비교**
-  * **인스턴스 메쉬**: 지오메트리 복제를 방지하여 메모리 효율성이 높지만, 매 프레임마다 월드 매트릭스(World Matrix), 바운딩 박스, 바운딩 스피어 및 절두체(Frustum) 검사를 계산합니다 [3]. 인스턴스가 수만 개로 늘어나고 개별 스케일(Scale) 등이 적용될 경우 막대한 CPU 병목을 유발하여 프레임 속도를 급격히 떨어뜨립니다 [4, 5].
-  * **솔리드 파티클 시스템(SPS)**: `setParticles()`가 호출될 때만 전용 월드 매트릭스를 계산하며 기본적으로 절두체 검사가 비활성화되어 있어 CPU 오버헤드가 적습니다. 런타임에 개별 파티클의 색상이나 재질을 유연하게 변경할 수 있는 장점이 있으나, 지오메트리와 색상 버퍼 데이터를 내부적으로 모두 복제하기 때문에 10만 개의 실린더를 렌더링할 때 약 600MB의 엄청난 메모리를 소모합니다 [1, 3, 6, 7].
-
-* **CPU 병목 현상 및 완화 전략**
-  Babylon.js는 버퍼 내의 매트릭스를 재배열하는 방식으로 CPU 단에서 정렬(Sorting) 및 절두체 컬링(Frustum Culling)을 수행합니다 [8]. 따라서 렌더링 시 매 프레임마다 발생하는 월드 매트릭스 계산 부하를 줄이려면 `freezeWorldMatrix()` 함수를 사용하여 정적 객체의 연산을 비활성화하거나, 시야 밖의 객체 관리를 별도의 웹 워커(Web Worker)로 분리하는 기법이 권장됩니다 [4, 9].
-
-* **한계와 WebGPU의 역할**
-  현재의 WebGL 상태에서는 인스턴스 메쉬라 할지라도 수만 개의 객체를 처리하기에는 무리가 있습니다 [10]. 2,000개 미만의 메쉬에서는 원활하지만 그 이상의 거대한 스케일을 처리하기 위해서는 금속(하드웨어) 수준에 더 가깝게 접근할 수 있는 WebGPU를 대안으로 사용해야 합니다 [10].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Graphics & Performance 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[Instanced Meshes]], [[Solid Particle System (SPS)]], [[Frustum Culling]], [[WebGPU]]
-- **Projects/Contexts:** [[대규모 3D 환경 렌더링 최적화 프로젝트]]
-- **Contradictions/Notes:** 인스턴스 메쉬는 지오메트리를 복제하지 않아 메모리가 절약되어야 하지만, 한 사용자는 10,000개의 인스턴스당 100MB의 힙 메모리가 증가(인스턴스당 약 8~10KB)한다는 프로파일링 결과를 제기했습니다 [7, 11]. 이에 대해 Babylon.js 개발진(Deltakosh)은 실제 인스턴스 1개당 차지하는 메모리는 약 400바이트 수준이라고 확인하며 오해를 정정했습니다 [12].
-
----
-*Last updated: 2026-04-19*
-- Raw Source: [[00_Raw/2026-04-20/Babylon.js.md]]
----
diff --git a/Graphics & Performance/BatchedMesh 및 InstancedMesh 성능 벤치마크.md b/Graphics & Performance/BatchedMesh 및 InstancedMesh 성능 벤치마크.md
deleted file mode 100644
index e4cd1bb7..00000000
--- a/Graphics & Performance/BatchedMesh 및 InstancedMesh 성능 벤치마크.md	
+++ /dev/null
@@ -1,43 +0,0 @@
----
-id: P-REINFORCE-AUTO-6B3697
-category: "[[10_Wiki/💡 Topics/Graphics & Performance]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - BatchedMesh 및 InstancedMesh 성능 벤치마크"
----
-
-# [[BatchedMesh 및 InstancedMesh 성능 벤치마크]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> BatchedMesh와 InstancedMesh는 Three.js 환경에서 드로우 콜(Draw Call)을 줄여 렌더링 성능을 대폭 개선하는 대표적인 최적화 기법입니다 [1, 2]. InstancedMesh는 동일한 형태의 객체를 대량으로 그릴 때 탁월한 효율을 보이지만 다양한 지오메트리를 한 번에 처리할 수는 없으며, BatchedMesh는 서로 다른 지오메트리를 하나의 드로우 콜로 묶을 수 있는 높은 유연성을 제공합니다 [3, 4]. 하지만 벤치마크 사례 연구에 따르면, 대규모 객체를 처리할 때 BatchedMesh는 내부적인 객체 정렬 및 버퍼 업로드 오버헤드로 인해 오히려 심각한 CPU 병목 현상과 렌더링 성능 저하를 유발할 수 있음이 확인되었습니다 [5, 6].
-
-## 📖 구조화된 지식 (Synthesized Content)
-- **최적화 메커니즘과 적용 기준**
-  InstancedMesh는 동일한 기하학적 구조(BufferGeometry)와 재질(Material)을 공유하는 수많은 복제본을 단일 드로우 콜로 GPU에 전달해 처리합니다 [7, 8]. 고유한 지오메트리가 1,000개 미만이면서 수만 개의 복제본이 존재하는 환경에서 최상의 성능(`drawElementsInstanced`)을 발휘합니다 [9, 10]. 반면 BatchedMesh는 재질은 같으나 형태가 각기 다른 여러 지오메트리를 하나의 버퍼에 통합(`multiDrawElementsWEBGL` 활용)하여 한 번에 렌더링할 수 있으므로 지오메트리가 매우 다양한 씬에 적합합니다 [9, 11-13].
-
-- **BatchedMesh의 대규모 씬 성능 병목 현상**
-  실제 건축 BIM 모델이나 대규모 씬(예: 1,200만 개의 삼각형, 수십만 개의 고유 지오메트리)을 BatchedMesh로 렌더링한 벤치마크 테스트에서 막대한 성능 하락이 보고되었습니다 [5, 14, 15]. 동일한 환경에서 모든 객체를 하나로 병합한 Merged Mesh 방식이 60 FPS(CPU 15%, GPU 90%)의 성능을 보인 반면, BatchedMesh는 약 20 FPS 이하(CPU 40~60%, GPU 30%)로 프레임이 급락하며 극심한 CPU 부하를 보였습니다 [5, 15-17]. 
-
-- **성능 저하의 주요 원인**
-  BatchedMesh의 CPU 오버헤드는 매 프레임마다 GPU로 그려야 할 부분의 '시작(starts)' 지점과 '카운트(counts)' 배열 데이터를 재업로드해야 하는 구조에서 비롯될 확률이 높습니다(약 20만 개 항목 기준 1.6MB의 데이터를 매 프레임 전송) [6, 18, 19]. 더불어 개별 객체마다 가시성을 판별하는 시야 절두체 컬링(Frustum Culling) 및 심도 정렬(Sorting) 작업이 CPU 자원을 크게 소모하며, 특히 정렬 기능을 켤 경우 `texSubImage2D` 작업 병목으로 인해 FPS가 30에서 9로 떨어지는 현상까지 관찰되었습니다 [20-22].
-
-- **오버드로우(Overdraw)와 심도 정렬의 한계**
-  InstancedMesh는 내부적으로 인스턴스를 자동으로 정렬하지 않기 때문에, 불투명 객체들이 겹칠 때 발생하는 오버드로우 현상으로 인해 프래그먼트 바운드(Fragment-bound) 성능 저하를 겪을 수 있습니다 [23-25]. BatchedMesh는 이러한 문제를 덜기 위해 자체적인 정렬 기능을 제공하지만, 앞서 언급한 바와 같이 수많은 요소를 CPU에서 정렬하는 연산 자체가 새로운 렌더링 지연의 원인이 됩니다 [22, 24].
-
-- **성능 벤치마크 기반의 선택 가이드라인**
-  동적인 씬에서 객체의 종류가 1,000개 이하라면 InstancedMesh가 압도적으로 효율적입니다 [10, 26]. 만일 고유 객체가 1,000개 이상이라면 BatchedMesh를 고려할 수 있으나, 수만~수십만 개의 극대규모 객체 단위로 넘어가면 한계에 부딪힙니다 [10, 27]. 씬이 정적이라면 지오메트리를 하나의 거대한 버퍼로 완전히 병합(Merge)해버리는 것이 성능에 훨씬 이로우며, 매우 방대하고 동적인 처리가 필수적이라면 WebGPU 기반의 컴퓨트 셰이더와 간접 드로우(Indirect Draw) 파이프라인으로 전환하는 것이 근본적인 해결책입니다 [6, 28, 29].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Graphics & Performance 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[드로우 콜 (Draw Call)]], [[Frustum Culling (시야 절두체 컬링)]], [[오버드로우 (Overdraw)]]
-- **Projects/Contexts:** [[Revit 및 BIM 건축 모델 렌더링 최적화]], [[WebGPU 및 Indirect Draw]]
-- **Contradictions/Notes:** BatchedMesh는 여러 종류의 지오메트리 렌더링 시 발생하는 CPU의 드로우 콜 오버헤드를 줄이고 성능을 최적화하기 위해 고안되었으나, 대규모(10만 개 이상) 지오메트리 벤치마크 환경에서는 내부 상태 업데이트 및 버퍼 데이터 전송 부하로 인해 도리어 Merged Mesh 방식보다 CPU 사용량을 최대 3배 이상 폭증시키고 FPS를 심각하게 떨어뜨리는 역설적인 결과를 보입니다 [5, 15, 30].
-
----
-*Last updated: 2026-04-19*
-- Raw Source: [[00_Raw/2026-04-20/BatchedMesh 및 InstancedMesh 성능 벤치마크.md]]
----
diff --git a/Graphics & Performance/BatchedMesh.md b/Graphics & Performance/BatchedMesh.md
deleted file mode 100644
index b97497a1..00000000
--- a/Graphics & Performance/BatchedMesh.md	
+++ /dev/null
@@ -1,42 +0,0 @@
----
-id: P-REINFORCE-AUTO-AADCDE
-category: "[[10_Wiki/💡 Topics/Graphics & Performance]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - BatchedMesh"
----
-
-# [[BatchedMesh]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-* **동작 원리와 초기화:** 
-  BatchedMesh는 렌더링 시 CPU의 명령 발행 횟수(드로우 콜)를 줄이기 위한 기술입니다. 초기화 시 `maxInstanceCount`(최대 인스턴스 수), `maxVertexCount`(최대 정점 수), `maxIndexCount`(최대 인덱스 수)와 인스턴스들이 공유할 단일 `material`을 정의합니다. 이후 여러 지오메트리를 추가(`addGeometry`)하고, 개별 인스턴스에 고유한 변환 행렬(Matrix)을 적용(`setMatrixAt`)하여 위치, 회전, 크기를 설정할 수 있습니다 [1-6].
-
-* **InstancedMesh와의 차이점:**
-  InstancedMesh가 `instancedDraw`를 사용하여 동일한 지오메트리만을 수없이 복제하는 방식이라면, BatchedMesh는 `WEBGL_multi_draw` 확장(WebGPU에서는 indirect draw)을 활용하여 서로 다른 지오메트리를 한 번에 그릴 수 있습니다. 또한 `setVisibleAt` 메서드를 제공하여 개별 객체의 가시성(Visibility)을 제어할 수 있는 유연성을 갖추고 있습니다 [7-11].
-
-* **성능 한계 및 병목 현상:**
-  BatchedMesh는 소규모 또는 다양한 지오메트리가 혼합된 씬(예: 각기 다른 모양의 수많은 벽이나 식물들)에서는 강력하지만, 확장성 측면에서 뚜렷한 한계를 보입니다.
-  * **버퍼 패킹 및 통신 오버헤드:** 인스턴스가 수만에서 수십만 개(예: 200,000개)로 늘어나면 GPU로 전송할 드로우 시작 지점 및 개수 버퍼 데이터가 커집니다. 매 프레임 이를 업데이트하고 `multiDrawElementsWEBGL`을 호출하는 데 막대한 CPU 자원이 소모됩니다 [11-14]. 
-  * **정렬 및 컬링 비용:** 시야 절두체 컬링(`perObjectFrustumCulled`)과 투명도 처리를 위한 객체 정렬(`sortObjects`)을 수행할 때, 이 연산이 CPU의 메인 스레드를 장악하여 프레임 속도(FPS)를 60FPS에서 10~20FPS 수준으로 급락시키는 병목을 유발합니다 [13, 15-17].
-
-* **최적화 적용 전략:**
-  동적인 씬에서 고유한(Unique) 객체가 1,000개 이상일 때는 BatchedMesh(`multiDrawElementsWEBGL`)가 적합하지만, 고유 객체가 적고 인스턴스만 수십만 개인 경우에는 InstancedMesh(`drawElementsInstanced`)를 사용하는 것이 훨씬 효율적입니다 [18]. 모델의 삼각형 수가 천만 개를 넘어가거나 고정된 구조물이라면 지오메트리를 하나로 병합(Merging)하는 방식이 CPU 점유율 방어 측면에서 BatchedMesh보다 성능이 우수할 수 있습니다 [19-21].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Graphics & Performance 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[InstancedMesh]], [[Draw Call Optimization]], [[WEBGL_multi_draw]], [[Frustum Culling]]
-- **Projects/Contexts:** [[Three.js 렌더링 최적화]], [[대규모 3D 건축 모델(BIM) 시각화]], [[InstancedMesh 사용 시 드로우 콜 최적화의 한계점 사례 연구]]
-- **Contradictions/Notes:** 소스에서는 BatchedMesh가 여러 지오메트리를 한 번에 그려 드로우 콜을 획기적으로 줄여준다고 설명하지만, 동시에 인스턴스 수가 10만 개 이상이거나 1,200만 폴리곤 이상의 환경에서는 CPU의 버퍼 패킹 및 다중 드로우 처리 부하로 인해 병합된 일반 메쉬(Merged Mesh)나 InstancedMesh보다 FPS가 30~50% 이상 떨어지는 모순적 한계를 지니고 있음을 실증 사례로 지적합니다.
-
----
-*Last updated: 2026-04-19*
-- Raw Source: [[00_Raw/2026-04-20/BatchedMesh.md]]
----
diff --git a/Graphics & Performance/Batching.md b/Graphics & Performance/Batching.md
deleted file mode 100644
index c9ad9e69..00000000
--- a/Graphics & Performance/Batching.md	
+++ /dev/null
@@ -1,38 +0,0 @@
----
-id: P-REINFORCE-AUTO-723577
-category: "[[10_Wiki/💡 Topics/Graphics & Performance]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Batching"
----
-
-# [[Batching]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> Batching(배칭)은 렌더링 성능을 최적화하기 위해 여러 개의 렌더링 객체나 처리 명령을 하나의 그룹으로 묶어 일괄적으로 실행하는 기법입니다. 주로 3D 그래픽스(WebGL, WebGPU) 환경에서 GPU로 보내는 드로우 콜(Draw Call) 횟수를 줄여 성능 오버헤드를 최소화하는 데 사용됩니다. 또한 웹 개발 환경에서는 DOM의 읽기 및 쓰기 작업을 묶어 불필요한 레이아웃 재계산을 방지하는 목적으로도 활용됩니다.
-
-## 📖 구조화된 지식 (Synthesized Content)
-* **드로우 콜(Draw Call) 최소화 전략**
-  성능은 종종 실행되는 명령(드로우 콜)의 수에 크게 의존하기 때문에, 여러 그리기 호출을 하나의 WebGL 호출로 병합하는 배칭 기능은 성능 향상의 핵심입니다 [1, 2].
-* **3D 그래픽스 엔진에서의 활용**
-  * **Cesium:** 여러 객체를 하나의 명령으로 결합하기 위해 배칭을 사용합니다. 예를 들어, `BillboardCollection`은 가능한 한 많은 빌보드(Billboard)를 하나의 정점 버퍼(Vertex Buffer)에 저장하고, 이를 동일한 셰이더를 통해 렌더링함으로써 명령의 수를 대폭 줄입니다 [1]. 또한 엔진이 가시 절두체(Frustum)를 분할할 때마다 명령을 개별적으로 정렬 및 배칭(Batch)하여 작동 지연 시간을 최소화합니다 [3].
-  * **Wonderland Engine:** 배칭 기능을 극한으로 적용하여, 수만 개의 동적 객체가 포함된 장면(Scene)을 자동으로 10개 미만의 드로우 콜로 렌더링해 냅니다 [2].
-* **WebGPU에서의 명령어 배칭(Command Batching)**
-  WebGPU는 명령어 기록과 제출을 분리하는 구조를 가집니다. 명령들은 명령 버퍼(Command buffers)에 기록된 후, 일괄적으로(in batches) GPU 큐(Queue)에 제출됩니다 [4]. 이는 프레임당 API 오버헤드를 크게 줄여주며, GPU 드라이버가 명령어 실행을 더 효과적으로 최적화할 수 있게 만듭니다 [4].
-* **UI 레이아웃 및 DOM 성능 최적화**
-  웹 성능 지표(Core Web Vitals) 중 하나인 INP(Interaction to Next Paint)를 최적화하기 위해서도 배칭 개념이 쓰입니다. 읽기 작업 직후 쓰기 작업을 수행하여 발생하는 과도한 동기식 레이아웃 재계산(레이아웃 스래싱)을 방지하기 위해, DOM 읽기 및 쓰기 작업을 현명하게 배칭(Batch)하여 처리하는 것이 권장됩니다 [5].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Graphics & Performance 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[Draw Calls]], [[WebGL]], [[WebGPU]], [[Interaction to Next Paint (INP)]]
-- **Projects/Contexts:** [[Cesium]], [[Wonderland Engine]]
-- **Contradictions/Notes:** 소스 내에서 배칭에 관한 상충되는 의견은 없으나, 3D 엔진에서의 '드로우 콜 병합'과 프론트엔드 최적화에서의 'DOM 연산 일괄 처리'라는 서로 다른 두 가지 시스템 컨텍스트에서 성능 개선을 위한 공통된 원리로 작용하고 있음을 보여줍니다.
-
----
-*Last updated: 2026-04-19*
-- Raw Source: [[00_Raw/2026-04-20/Batching.md]]
----
diff --git a/Graphics & Performance/Behavioral Economics in Digital Ecosystems.md b/Graphics & Performance/Behavioral Economics in Digital Ecosystems.md
deleted file mode 100644
index d31d7f36..00000000
--- a/Graphics & Performance/Behavioral Economics in Digital Ecosystems.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-CAA259
-category: "[[10_Wiki/💡 Topics/Graphics & Performance]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Behavioral Economics in Digital Ecosystems"
----
-
-# [[Behavioral Economics in Digital Ecosystems]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Graphics & Performance 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Behavioral Economics in Digital Ecosystems.md]]
----
diff --git a/Graphics & Performance/Behavioral Economics.md b/Graphics & Performance/Behavioral Economics.md
deleted file mode 100644
index bb4e6489..00000000
--- a/Graphics & Performance/Behavioral Economics.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-612A46
-category: "[[10_Wiki/💡 Topics/Graphics & Performance]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Behavioral Economics"
----
-
-# [[Behavioral Economics]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Graphics & Performance 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Behavioral Economics.md]]
----
diff --git a/Graphics & Performance/Bio-mechanical-Modeling.md b/Graphics & Performance/Bio-mechanical-Modeling.md
deleted file mode 100644
index fe832a77..00000000
--- a/Graphics & Performance/Bio-mechanical-Modeling.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-8DE8EF
-category: "[[10_Wiki/💡 Topics/Graphics & Performance]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Bio-mechanical-Modeling"
----
-
-# [[Bio-mechanical-Modeling]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Graphics & Performance 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Bio-mechanical-Modeling.md]]
----
diff --git a/Graphics & Performance/Bioregionalism.md b/Graphics & Performance/Bioregionalism.md
deleted file mode 100644
index 67130871..00000000
--- a/Graphics & Performance/Bioregionalism.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-01D600
-category: "[[10_Wiki/💡 Topics/Graphics & Performance]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Bioregionalism"
----
-
-# [[Bioregionalism]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Graphics & Performance 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Bioregionalism.md]]
----
diff --git a/Graphics & Performance/Bounding Volume Hierarchy (BVH).md b/Graphics & Performance/Bounding Volume Hierarchy (BVH).md
deleted file mode 100644
index 9c460482..00000000
--- a/Graphics & Performance/Bounding Volume Hierarchy (BVH).md	
+++ /dev/null
@@ -1,33 +0,0 @@
----
-id: P-REINFORCE-AUTO-68A235
-category: "[[10_Wiki/💡 Topics/Graphics & Performance]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Bounding Volume Hierarchy (BVH)"
----
-
-# [[Bounding Volume Hierarchy (BVH)]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-- **빠른 레이캐스팅과 공간 쿼리:** `three-mesh-bvh`와 같은 구현체는 Three.js 환경에서 8만 개 이상의 폴리곤에 대한 레이캐스팅을 60fps의 속도로 원활하게 수행할 수 있도록 지원합니다 [4]. 이는 복잡한 지오메트리를 가진 인터랙티브 씬이나 다수의 레이캐스트가 발생하는 상황에서 성능 저하를 방지하는 강력한 수단입니다 [4, 7].
-- **효율적인 공간 분할과 포괄적 최적화:** 잘 설계된 BVH 스키마는 공간을 효율적으로 분할하고 인덱싱하여, 렌더링뿐만 아니라 조명 및 그림자 계산, 충돌 감지(Collisions), 그리고 에셋의 다운로드와 메모리 로딩 및 폐기에 이르는 전방위적인 최적화를 주도할 수 있습니다 [3]. 특히 정적인(static) 객체에 대해 초기화 시점에 BVH를 계산해두면, CPU 연산 단계에서 해당 객체들을 화면에 그릴지(Culling) 여부를 극도로 빠르고 효율적으로 판별할 수 있습니다 [6, 8].
-- **InstancedMesh 환경에서의 적용:** 인스턴싱 기술(예: `InstancedMesh2` 라이브러리)에 BVH 형태의 공간 인덱스를 결합하면 개별 인스턴스에 대한 매우 빠른 레이캐스팅과 프러스텀 컬링을 구현할 수 있습니다 [5, 9, 10]. 기존 `InstancedMesh` 자체에 대해서는 전체 인스턴스 세트가 아닌 내부의 개별 지오메트리 단위로 BVH 기반 레이캐스팅을 수행하므로, 지오메트리에 대한 바운드 트리(bounds tree)를 생성하여 적용해야 합니다 [11, 12].
-- **도입 시의 기술적 난제와 트레이드오프:** 대규모 인스턴스 씬에서 여러 객체가 겹쳐 있거나 가려진 객체를 정밀하게 선택(GPU Picking의 한계 극복)하기 위해서는 BVH와 같은 정교한 공간 분할 자료구조를 별도로 구축해야 합니다 [2]. 하지만 이러한 고도화된 자료구조를 추가로 구축하는 과정은 `InstancedMesh`가 본래 제공하는 '사용의 단순함'이라는 장점을 퇴색시킬 수 있다는 구조적 한계를 동반합니다 [2].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Graphics & Performance 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[Raycasting]], [[Frustum Culling]], [[InstancedMesh]], [[Spatial Partitioning]]
-- **Projects/Contexts:** [[three-mesh-bvh]], [[InstancedMesh2]]
-- **Contradictions/Notes:** BVH 모델을 씬에서 직접 시각화하여 확인하고자 할 때, 최신 라이브러리 환경에서는 기존에 사용되던 `MeshBVHVisualizer`가 더 이상 지원되지 않으므로(deprecated) 반드시 문서를 참조하여 `MeshBVHHelper`를 사용해야 합니다 [12].
-
----
-*Last updated: 2026-04-19*
-- Raw Source: [[00_Raw/2026-04-20/Bounding Volume Hierarchy (BVH).md]]
----
diff --git a/Graphics & Performance/Buffer Allocation.md b/Graphics & Performance/Buffer Allocation.md
deleted file mode 100644
index 6694e3ea..00000000
--- a/Graphics & Performance/Buffer Allocation.md	
+++ /dev/null
@@ -1,34 +0,0 @@
----
-id: P-REINFORCE-AUTO-B20BA9
-category: "[[10_Wiki/💡 Topics/Graphics & Performance]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Buffer Allocation"
----
-
-# [[Buffer Allocation]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 버퍼 할당(Buffer Allocation)은 WebGL 및 WebGPU 환경에서 정점, 인덱스, 인스턴스 변환 행렬 등의 데이터를 저장하기 위해 GPU 메모리 공간을 확보하는 과정입니다. 렌더링 중 동적으로 버퍼 크기를 늘리거나 빈번하게 데이터를 업데이트할 경우 심각한 프레임 지연 및 메모리 오류가 발생할 수 있습니다. 따라서 최대 예상치에 맞춰 사전에 버퍼를 할당하고, 재사용 가능한 영구적인 GPU 버퍼를 활용하는 것이 3D 애플리케이션 성능 최적화에 필수적입니다.
-
-## 📖 구조화된 지식 (Synthesized Content)
-* **동적 버퍼 확장의 성능 병목 현상:** 인스턴싱(Instancing) 시스템이 초기에 낮은 버퍼 용량으로 시작하여 런타임에 동적으로 크기를 확장(Growing Buffer)하게 되면, 심각한 성능 지연(예: 앱 시작 시 수 초간의 멈춤 현상) 및 메모리 할당 오류가 발생할 수 있습니다 [1, 2]. 
-* **최대 용량 사전 할당 (Preallocation):** 이를 방지하기 위해 엔진 시작 시점에 예상되는 최대 인스턴스 수에 맞춰 충분한 크기의 버퍼를 사전에 할당하는 방식이 권장됩니다 [1]. 여유 용량(Excess capacity)을 미리 확보하는 것은 약간의 메모리 오버헤드를 발생시키지만, 실제 렌더링 연산 비용에는 부정적인 영향을 주지 않습니다 [3].
-* **GPU 영구 버퍼 및 업데이트 최소화:** WebGPU 환경에서 매 프레임 수많은 작은 버퍼를 반복 업데이트하는 것은 비용이 매우 큽니다 [4]. 따라서 `instancedArray`와 같은 영구적인 GPU 버퍼를 생성하여 사용하면 프레임 간 데이터가 유지되어, 성능 저하의 주원인인 CPU-GPU 간의 데이터 전송을 제거할 수 있습니다 [4, 5].
-* **오브젝트 풀링(Object Pooling) 활용:** 객체를 빈번하게 생성하고 파괴하는 작업은 버퍼 할당 오버헤드와 가비지 컬렉션(GC)에 의한 일시 정지를 유발합니다. 런타임 할당 스파이크를 피하려면 로딩 단계에서 풀을 미리 데워두는(Pre-warm) 방식의 오브젝트 풀링을 사용해야 합니다 [6].
-* **버퍼 재할당 시 메모리 누수 주의:** WebGL 컨텍스트는 디바이스에 따라 유한한 메모리 한도(일반적으로 256MB~1GB)를 가지며, 한도를 초과하면 뷰어가 다운될 수 있습니다 [7]. 또한, 기존의 인스턴스 메쉬 자원을 깔끔하게 폐기(Dispose)하지 못한 상태에서 동적으로 버퍼 용량을 늘리려 할 경우 메모리 누수가 발생할 수 있습니다 [8].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Graphics & Performance 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[GPU Instancing]], [[Memory Management]], [[Object Pooling]], [[Garbage Collection]]
-- **Projects/Contexts:** [[Three.js]], [[Needle Engine]], [[WebGPU]]
-- **Contradictions/Notes:** 소스에서는 실행 중 버퍼 크기를 동적으로 늘리는 방식(Dynamic Growth)은 성능 지연과 오류를 낳으므로, 초기에 넉넉하게 메모리 공간을 사전 할당(Preallocate)하는 방식이 훨씬 안정적이라고 강조합니다 [1-3].
-
----
-*Last updated: 2026-04-19*
-- Raw Source: [[00_Raw/2026-04-20/Buffer Allocation.md]]
----
diff --git a/Graphics & Performance/BufferAttribute.md b/Graphics & Performance/BufferAttribute.md
deleted file mode 100644
index f4f24bf4..00000000
--- a/Graphics & Performance/BufferAttribute.md	
+++ /dev/null
@@ -1,33 +0,0 @@
----
-id: P-REINFORCE-AUTO-7E5F3E
-category: "[[10_Wiki/💡 Topics/Graphics & Performance]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - BufferAttribute"
----
-
-# [[BufferAttribute]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> `BufferAttribute`는 Three.js에서 3D 모델의 지오메트리 데이터를 저장하고 관리하기 위해 사용되는 핵심 클래스입니다 [1, 2]. 이 클래스는 Web Worker와 메인 스레드 간에 데이터를 중복 복사 없이 효율적으로 공유할 수 있게 해주며, 데이터 압축을 통한 메모리 최적화를 지원합니다 [2, 3]. 또한, 파생 클래스인 `InstancedBufferAttribute`를 통해 인스턴스 기반 렌더링에서 객체별 고유 데이터를 GPU로 전송하는 필수적인 역할을 수행합니다 [4, 5].
-
-## 📖 구조화된 지식 (Synthesized Content)
-- **메모리 최적화 및 제로 카피(Zero-copy) 아키텍처:** Electron 등 메모리가 제한적인 환경에서 Web Worker가 STL 데이터를 `SharedArrayBuffer`로 파싱하면, 메인 스레드는 이 공유 메모리 공간을 직접 가리키는 `BufferAttribute`를 생성할 수 있습니다. 이러한 '제로 카피' 아키텍처를 활용하면 데이터 중복 복사로 인한 메모리 오버헤드 없이 멀티스레드 지오메트리 생성이 가능합니다 [2].
-- **지오메트리 데이터 압축 지원:** `BufferAttribute`는 정규화된 정수 타입(normalized integer types)과 결합하여 지오메트리 압축을 지원함으로써 정점 버퍼의 크기를 대폭 줄일 수 있습니다 [3].
-- **다양한 타입의 파생 클래스 제공:** Three.js의 코어 API에는 데이터 타입 및 메모리 정밀도에 맞춰 `Float32BufferAttribute`, `Float16BufferAttribute`, `Int16BufferAttribute`, `Uint8BufferAttribute` 등 다양한 형태의 파생 클래스들이 존재합니다 [1].
-- **인스턴싱 연동 (InstancedBufferAttribute):** 대규모 객체 렌더링 시, 개별 인스턴스마다 다른 변환 행렬(`instanceMatrix`)이나 색상(`instanceColor`)을 적용하기 위해 파생 클래스인 `InstancedBufferAttribute`가 사용됩니다 [5, 6]. 또한, 텍스처 아틀라스 내에서 각 인스턴스별 텍스처 UV 오프셋을 전달하거나, 가시성(visibility) 및 컬링(culling) 상태 인덱스를 셰이더로 전달할 때도 핵심적으로 활용됩니다 [4, 7-9]. 매 프레임 수많은 지오메트리를 재생성하는 대신, `InstancedBufferAttribute` 일부만 갱신하여 렌더링 성능을 높일 수 있습니다 [10].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Graphics & Performance 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[InstancedBufferAttribute]], [[BufferGeometry]], [[SharedArrayBuffer]], [[InstancedMesh]]
-- **Projects/Contexts:** [[WebGL/Three.js 대규모 CAD 렌더링 메모리 최적화]], [[다중 객체 드로우 콜 최적화 및 커스텀 셰이더 적용 맥락]]
-- **Contradictions/Notes:** 소스에 관련 정보가 부족합니다.
-
----
-*Last updated: 2026-04-19*
-- Raw Source: [[00_Raw/2026-04-20/BufferAttribute.md]]
----
diff --git a/Graphics & Performance/BufferGeometry.md b/Graphics & Performance/BufferGeometry.md
deleted file mode 100644
index cca2ca7f..00000000
--- a/Graphics & Performance/BufferGeometry.md	
+++ /dev/null
@@ -1,33 +0,0 @@
----
-id: P-REINFORCE-AUTO-2887C6
-category: "[[10_Wiki/💡 Topics/Graphics & Performance]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - BufferGeometry"
----
-
-# [[BufferGeometry]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> BufferGeometry는 Three.js의 핵심 3D 기하학 구조를 정의하는 객체이다 [1]. InstancedMesh 기술에서 수많은 인스턴스가 공통으로 공유하는 기하학적 데이터로 사용된다 [2, 3]. 또한 여러 개의 지오메트리를 단일 BufferGeometry로 병합하여 렌더링 과정에서 발생하는 드로우 콜(Draw Call)을 최소화하는 성능 최적화의 핵심 단위로도 활용된다 [4, 5].
-
-## 📖 구조화된 지식 (Synthesized Content)
-* **InstancedMesh의 기본 데이터 레이어:** InstancedMesh 구조에서 BufferGeometry는 모든 개별 인스턴스가 공통으로 공유하는 기하학적 정의를 담당하는 주요 데이터 레이어이다 [2]. 다만, 하나의 InstancedMesh 인스턴스는 오직 하나의 BufferGeometry만을 참조할 수 있다는 기하학적 단일성의 제약이 존재한다 [6].
-* **지오메트리 병합(Merging)을 통한 최적화:** 정적인 환경이나 여러 개의 객체들을 렌더링할 때, `BufferGeometryUtils.mergeBufferGeometries()` 메서드를 사용하여 서로 다른 기하학적 데이터를 단일 BufferGeometry로 병합할 수 있다 [5, 7, 8]. 이를 통해 여러 객체를 단 한 번의 드로우 콜로 렌더링함으로써 CPU 오버헤드를 획기적으로 낮출 수 있다 [4].
-* **메모리 집약성 및 컬링(Culling) 효율의 한계:** 여러 객체를 하나의 BufferGeometry로 묶는 방식은 드로우 콜을 줄여주지만, 객체를 복제할 때마다 RAM 사용량이 정비례로 증가하는 메모리 집약적인 특성을 띤다 [4]. 더욱이 병합된 메쉬 전체가 하나의 단일 바운딩 볼륨(Bounding Volume)으로 취급되기 때문에, 화면 밖의 객체를 제외하는 시야 절두체 컬링(Frustum Culling)의 정밀도가 떨어지는 한계가 발생한다 [5].
-* **개별 항목의 식별 및 접근:** 여러 객체를 거대한 BufferGeometry 하나로 병합한 후 특정 개별 요소를 선택하거나 수정하는 것은 까다롭지만, 버퍼 내 각 객체의 위치(Position) 데이터를 저장하는 매핑(Map) 구조를 구축하여 개별 항목을 효율적으로 조회하고 제어할 수 있다 [4].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Graphics & Performance 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[InstancedMesh]], [[Draw Call]], [[BufferGeometryUtils]]
-- **Projects/Contexts:** [[Three.js]], [[IFC.js Fragment]]
-- **Contradictions/Notes:** 소스 문헌들은 성능 개선을 위해 객체들을 단일 BufferGeometry로 병합할 것을 권장하면서도, 이 방식이 드로우 콜을 최소화하는 대신 RAM 소모량을 높이고 시야 절두체 컬링의 효율을 저하시키는 트레이드오프(Trade-off)를 유발한다고 경고한다 [4, 5].
-
----
-*Last updated: 2026-04-19*
-- Raw Source: [[00_Raw/2026-04-20/BufferGeometry.md]]
----
diff --git a/Graphics & Performance/CPU Bottleneck.md b/Graphics & Performance/CPU Bottleneck.md
deleted file mode 100644
index ab449bed..00000000
--- a/Graphics & Performance/CPU Bottleneck.md	
+++ /dev/null
@@ -1,33 +0,0 @@
----
-id: P-REINFORCE-AUTO-944A15
-category: "[[10_Wiki/💡 Topics/Graphics & Performance]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - CPU Bottleneck"
----
-
-# [[CPU Bottleneck]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 3D 그래픽스 및 실시간 렌더링 환경에서 CPU 병목(CPU Bottleneck)이란, CPU가 렌더링 명령어(드로우 콜)를 준비하고 GPU로 전송하거나 필요한 데이터 연산을 처리하는 속도가 느려져 GPU가 제 성능을 발휘하지 못하고 대기(Starve)하게 되는 현상을 말합니다 [1]. 주로 개별 모델에 대한 과도한 드로우 콜 발행이나 자바스크립트 메인 스레드에서의 무거운 연산(애니메이션, 정렬, 컬링 등)으로 인해 발생하며 [2-4], 이를 해결하기 위해 인스턴싱(Instancing)이나 연산의 GPU 오프로딩 기법이 사용됩니다 [5, 6].
-
-## 📖 구조화된 지식 (Synthesized Content)
-- **드로우 콜 오버헤드 (Draw Call Overhead):** CPU 병목의 가장 주요한 원인입니다. CPU는 GPU에 그리기 명령을 내릴 때마다 변환 행렬, 셰이더 참조, 유니폼, 정점 버퍼 등의 렌더링 상태를 준비하고 통신해야 합니다 [2, 7]. 수백~수천 개의 개별 객체를 렌더링할 경우, 실제 폴리곤을 그리는 연산보다 CPU가 명령을 준비하고 발행하는 오버헤드가 시스템 버스에 막대한 부하를 가하여 병목을 유발합니다 [1, 7, 8].
-- **자바스크립트 메인 스레드 한계:** 웹 렌더링(Three.js 등) 환경에서 수만 개의 객체에 대해 수동으로 시야 절두체 컬링(Frustum Culling)을 계산하거나, 투명 객체의 깊이 정렬(예: Radix Sort)을 수행할 경우 막대한 CPU 연산 비용이 발생합니다 [4, 9]. 단일 스레드 기반인 자바스크립트에서 렌더링 루프 내의 대규모 배열 조작은 메인 스레드를 점유하여 프레임 드랍을 유발하는 치명적인 CPU 병목을 낳습니다 [4, 9].
-- **애니메이션 및 레이캐스팅 부하:** 스킨드 메시(Skinned Mesh)의 뼈대(Bone) 애니메이션 시스템은 매 프레임 CPU에서 행렬 업데이트 연산을 요구하므로 다수의 캐릭터가 있을 경우 렌더링 예산을 초과하는 CPU 시간을 소모합니다 [3]. 또한 수만 개의 인스턴스 환경에서 CPU 기반 레이캐스팅(Raycasting)을 수행하면 각 인스턴스의 행렬을 일일이 역산해야 하므로 즉각적인 반응을 불가능하게 만드는 동기화 병목이 발생합니다 [10].
-- **입자 시스템 및 물리 연산:** CPU를 활용한 파티클 시스템 업데이트는 일반적인 하드웨어 기준 약 50,000개 수준에서 CPU 병목에 도달합니다 [5]. 이러한 연산 병목은 WebGPU의 컴퓨트 셰이더(Compute Shaders)를 활용해 메인 스레드의 작업을 GPU 코어로 병렬 오프로드함으로써 해결할 수 있습니다 [5, 11].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Graphics & Performance 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[Draw Call]], [[InstancedMesh]], [[Frustum Culling]]
-- **Projects/Contexts:** [[Three.js]], [[WebGL]], [[WebGPU]]
-- **Contradictions/Notes:** `InstancedMesh` 기술은 수천 개의 객체를 단 한 번의 드로우 콜로 처리하여 CPU 병목을 획기적으로 해결하는 기술로 알려져 있습니다 [6, 12]. 그러나 이 방식은 개별 객체의 컬링이나 정렬 같은 내부 최적화를 지원하지 않으므로, 이를 극복하기 위해 CPU 단에서 수동으로 위치를 검사하고 버퍼를 재정렬하는 로직을 추가할 경우 오히려 이전보다 더 극심한 CPU 연산 병목이 발생하는 역설적인 상황이 빈번하게 발생합니다 [4, 9].
-
----
-*Last updated: 2026-04-19*
-- Raw Source: [[00_Raw/2026-04-20/CPU Bottleneck.md]]
----
diff --git a/Graphics & Performance/CPU Overhead.md b/Graphics & Performance/CPU Overhead.md
deleted file mode 100644
index a641cf9f..00000000
--- a/Graphics & Performance/CPU Overhead.md	
+++ /dev/null
@@ -1,37 +0,0 @@
----
-id: P-REINFORCE-AUTO-38FA31
-category: "[[10_Wiki/💡 Topics/Graphics & Performance]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - CPU Overhead"
----
-
-# [[CPU Overhead]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> CPU 오버헤드(CPU Overhead)는 웹 그래픽 렌더링 및 브라우저 실행 중에 중앙 처리 장치(CPU)에 가해지는 계산 부담 및 처리 지연을 의미합니다 [1, 2]. WebGL과 같은 기존 API에서는 단일 스레드 기반의 명령 제출과 JavaScript 실행이 CPU 병목 현상을 일으켜 GPU가 유휴 상태에 빠지게 만듭니다 [2, 3]. WebGPU와 같은 최신 API는 멀티 스레드 명령 생성과 컴퓨트 셰이더를 통한 연산 오프로딩을 통해 이러한 CPU 오버헤드를 대폭 감소시킵니다 [4, 5].
-
-## 📖 구조화된 지식 (Synthesized Content)
-* **WebGL에서의 CPU 오버헤드 원인:** 
-  WebGL은 단일 스레드 실행 모델로 작동하여 모든 드로우 콜(Draw call), 상태 변경, 리소스 업로드가 순차적으로 실행되며 메인 스레드를 차단합니다 [2, 3]. 또한 브라우저의 보안 검사, 프로세스 격리를 위한 마샬링(marshalling), 그리고 ANGLE을 통한 API 변환(OpenGL ES를 Direct3D로 변환) 과정은 드로우 콜마다 고정적인 오버헤드를 발생시킵니다 [6, 7]. 이는 결과적으로 GPU가 유휴 상태임에도 CPU가 병목이 되는 현상을 초래합니다 [6, 8].
-
-* **성능 및 사용자 환경에 미치는 영향:** 
-  CPU 오버헤드는 프레임 드롭, 미세 지연(Micro-latency) 및 화면 끊김(Stuttering)의 주요 원인이 됩니다 [3, 9, 10]. 예를 들어 3D 가우시안 스플래팅(3DGS)과 같은 데이터 집약적 렌더링에서 수백만 개의 객체를 CPU에서 정렬할 경우, CPU-GPU 간 대규모 버퍼 전송과 동기화 병목 현상이 발생하여 프레임 예산을 초과하게 됩니다 [11, 12]. 특히 모바일 기기에서는 높은 CPU 오버헤드가 과도한 전력 소비와 발열로 이어지며, 이는 곧 열 쓰로틀링(Thermal throttling)에 의한 심각한 성능 저하를 유발합니다 [13-15].
-
-* **WebGPU와 구조적 최적화를 통한 해결:** 
-  WebGPU는 멀티 스레드를 통한 렌더링 명령 준비와 명시적이고 정적인 리소스 관리(GPU 리소스 읽기 전용화 등)를 지원하여 CPU 측의 재검증 오버헤드를 획기적으로 줄입니다 [4, 5, 16-18]. 컴퓨트 셰이더를 사용하여 물리 시뮬레이션이나 입자 시스템 같은 연산 논리를 GPU로 오프로딩하면 CPU-GPU 간의 왕복 통신과 JavaScript 실행 지연을 최소화하는 'GPU 주도(GPU-driven)' 렌더링이 가능해집니다 [13, 19]. 또한, 엔진 차원에서는 인스턴싱이나 배칭(Batching)을 통해 절대적인 드로우 콜 횟수를 최소화하는 것이 오버헤드 감소의 핵심입니다 [8, 20].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Graphics & Performance 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[WebGL]], [[WebGPU]], [[Draw Calls]], [[Micro-latency]], [[Compute Shaders]]
-- **Projects/Contexts:** [[3D Gaussian Splatting (3DGS)]], [[WebSplatter]], [[ANGLE]]
-- **Contradictions/Notes:** 제공된 소스들 사이에서 명백한 모순은 발견되지 않습니다. 모든 소스가 WebGL의 단일 스레드 아키텍처가 야기하는 CPU 병목 현상을 WebGPU의 멀티 스레드 도입 및 명시적 리소스 관리로 극복한다는 공통된 기술적 진화를 설명하고 있습니다.
-
----
-*Last updated: 2026-04-19*
-- Raw Source: [[00_Raw/2026-04-20/CPU Overhead.md]]
----
diff --git a/Graphics & Performance/Cel-Shading-Techniques.md b/Graphics & Performance/Cel-Shading-Techniques.md
deleted file mode 100644
index 838bf8df..00000000
--- a/Graphics & Performance/Cel-Shading-Techniques.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-6E2113
-category: "[[10_Wiki/💡 Topics/Graphics & Performance]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Cel-Shading-Techniques"
----
-
-# [[Cel-Shading-Techniques]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Graphics & Performance 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Cel-Shading-Techniques.md]]
----
diff --git a/Graphics & Performance/Cellular Automata.md b/Graphics & Performance/Cellular Automata.md
deleted file mode 100644
index 5765d0e0..00000000
--- a/Graphics & Performance/Cellular Automata.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-5EDE2E
-category: "[[10_Wiki/💡 Topics/Graphics & Performance]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Cellular Automata"
----
-
-# [[Cellular Automata]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Graphics & Performance 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Cellular Automata.md]]
----
diff --git a/Graphics & Performance/Cesium.md b/Graphics & Performance/Cesium.md
deleted file mode 100644
index 39c672d8..00000000
--- a/Graphics & Performance/Cesium.md	
+++ /dev/null
@@ -1,34 +0,0 @@
----
-id: P-REINFORCE-AUTO-8A58ED
-category: "[[10_Wiki/💡 Topics/Graphics & Performance]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Cesium"
----
-
-# [[Cesium]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 소스에 관련 정보가 부족합니다. 제공된 문서에서 Cesium은 3D 렌더링 중 메쉬 배칭(Mesh batching) 기능인 `Batched3DModel`을 지원하는 환경으로 매우 짧게 언급되며, 주로 Three.js의 `BatchedMesh` 성능과 비교하기 위한 대조군으로 등장합니다 [1, 2].
-
-## 📖 구조화된 지식 (Synthesized Content)
-소스에 관련 정보가 부족합니다. 
-
-문서에 등장하는 Cesium과 관련된 단편적인 정보는 다음과 같습니다:
-* **Batched3DModel 렌더링**: Cesium은 3D 모델을 처리할 때 `Batched3DModel`을 사용하여 메쉬 배칭(Mesh Batching)을 수행합니다 [1, 2].
-* **Three.js와의 성능 대조**: 한 사용자의 경험에 따르면, 1,200만 개의 삼각형과 1,600만 개의 정점으로 이루어진 대규모 모델을 렌더링할 때 Three.js의 `BatchedMesh`에서는 극심한 CPU 성능 소모 이슈가 발생했으나, Cesium에서 렌더링할 때는 그러한 문제가 발생하지 않았습니다 [1, 2]. 사용자는 두 시스템의 메쉬 배칭 구조가 상당히 유사할 것으로 추측하고 있습니다 [1, 2].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Graphics & Performance 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[Batched3DModel]], [[BatchedMesh]]
-- **Projects/Contexts:** [[Three.js BatchedMesh 성능 이슈 비교]]
-- **Contradictions/Notes:** 소스에 관련 정보가 부족합니다. 작성자는 Cesium의 배칭과 Three.js의 `BatchedMesh`가 매우 유사할 것이라고 추측하지만 [1, 2], 실제로 두 기술 간의 구체적인 아키텍처 차이나 성능 차이의 근본적 원인을 설명하는 기술적 정보는 소스에 존재하지 않습니다.
-
----
-*Last updated: 2026-04-19*
-- Raw Source: [[00_Raw/2026-04-20/Cesium.md]]
----
diff --git a/Graphics & Performance/Chrome (Blink_Dawn).md b/Graphics & Performance/Chrome (Blink_Dawn).md
deleted file mode 100644
index 8974db94..00000000
--- a/Graphics & Performance/Chrome (Blink_Dawn).md	
+++ /dev/null
@@ -1,32 +0,0 @@
----
-id: P-REINFORCE-AUTO-3115F7
-category: "[[10_Wiki/💡 Topics/Graphics & Performance]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Chrome (Blink_Dawn)"
----
-
-# [[Chrome (Blink_Dawn)]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> Chrome(Blink/Dawn)은 구글 크롬 브라우저의 핵심 엔진인 Blink와 WebGPU 백엔드인 Dawn을 지칭합니다 [1, 2]. 이들은 웹 환경에서 고성능 그래픽 및 연산 파이프라인을 처리하는 동시에, Spectre 및 Meltdown과 같은 보안 취약점을 방지하기 위해 정밀 타이머 접근을 제한하는 보안 메커니즘을 구현하고 있습니다 [1, 2]. 또한 개발자가 웹 애플리케이션의 성능 병목 현상을 식별할 수 있도록 심층적인 프로세스 트레이싱 및 프로파일링 환경을 제공합니다 [3-5].
-
-## 📖 구조화된 지식 (Synthesized Content)
-- **WebGPU 백엔드(Dawn)와 타임스탬프 양자화:** Dawn은 Chrome의 WebGPU 백엔드로 작동하며, 타이밍 기반의 정보 유출(timing-based information leaks)을 막기 위해 '타임스탬프 양자화(timestamp quantization)' 기능을 구현하고 있습니다 [1]. 이 기능은 쿼리의 해상도를 100 마이크로초 단위 등으로 의도적으로 낮추어 제공하며, 격리된 컨텍스트(isolated contexts)에 한해 이 해상도로 노출됩니다 [1, 6]. Dawn에는 "timestamp_quantization"이라는 디바이스 토글이 존재하며 이는 기본적으로 활성화되어 있습니다 [7]. 다만, 성능 프로파일링이 필요한 개발자의 경우 로컬 환경에서 "WebGPU Developer Features" 플래그를 활성화하여 이러한 양자화 제한을 우회할 수 있습니다 [1, 7].
-- **렌더링 엔진(Blink)의 보안 아키텍처 재설계:** Spectre와 Meltdown 취약점이 발견된 이후, 웹 타이밍 보안에 대한 근본적인 재설계가 이루어졌습니다 [2]. 이에 따라 Chrome의 Blink 엔진은 타이머 정밀도를 감소시키고 분기 없는(branchless) 보안 검사를 구현하는 형태의 2단계 방어 체계로 전환하여 공격자가 캐시 사이드 채널 공격을 위해 필요한 서브-마이크로초 단위의 타이밍 차이를 관찰하지 못하도록 조치했습니다 [2, 8].
-- **다중 프로세스 아키텍처 및 프로파일링:** Chrome의 `about:tracing` 도구를 사용하면 브라우저 내부의 다중 프로세스 아키텍처를 상세하게 검사할 수 있습니다 [3]. 특히 JavaScript가 실행되는 렌더러 프로세스인 "CrRendererMain" 스레드와 드라이버 인터페이스가 위치한 GPU 프로세스인 "CrGpuMain" 스레드 간의 통신과 부하를 분석하는 데 유용합니다 [3, 4, 9]. 엔지니어는 트레이스를 분석하여 "CrRendererMain"은 비어있으나 "CrGpuMain"이 계속 활성화되어 있는 것을 보고 시스템이 GPU 바운드(GPU bound) 상태인지 등을 정확히 파악할 수 있습니다 [4, 10, 11].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Graphics & Performance 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[WebGPU]], [[Timestamp Queries]], [[Spectre and Meltdown]]
-- **Projects/Contexts:** [[Chrome DevTools]], [[about:tracing]]
-- **Contradictions/Notes:** 타임스탬프 쿼리 해상도와 관련하여 초기에는 격리된 컨텍스트(isolated contexts) 여부에 따라 다르게 노출되는 방안이 논의되었으나, 향후 W3C의 High Resolution Time 사양과 일치시켜 사이트 격리 여부와 관계없이 100 마이크로초(100us) 해상도를 허용하는 방향으로 GPU for the Web Community Group에서 합의를 이루었습니다 [6, 12, 13].
-
----
-*Last updated: 2026-04-19*
-- Raw Source: [[00_Raw/2026-04-20/Chrome (Blink_Dawn).md]]
----
diff --git a/Graphics & Performance/Chrome WebGPU 구현.md b/Graphics & Performance/Chrome WebGPU 구현.md
deleted file mode 100644
index eca2fc5f..00000000
--- a/Graphics & Performance/Chrome WebGPU 구현.md	
+++ /dev/null
@@ -1,37 +0,0 @@
----
-id: P-REINFORCE-AUTO-7CCB76
-category: "[[10_Wiki/💡 Topics/Graphics & Performance]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Chrome WebGPU 구현"
----
-
-# [[Chrome WebGPU 구현]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> Chrome은 113 버전부터 WebGPU를 기본으로 활성화하여 차세대 웹 그래픽스 및 컴퓨팅 API를 지원하기 시작했습니다 [1, 2]. Chrome의 WebGPU 구현체는 'Dawn'이라는 백엔드와 'Tint' 셰이더 컴파일러를 기반으로 작동하며, 성능 향상과 보안 강화를 위한 다양한 기능(예: 16비트 부동소수점 지원, 타임스탬프 양자화 등)을 지속적으로 업데이트하고 있습니다 [3-5]. 초기 데스크톱 지원을 시작으로 현재는 Android 환경까지 지원을 확장하여 이식성 높고 강력한 GPU 가속 환경을 제공합니다 [6].
-
-## 📖 구조화된 지식 (Synthesized Content)
-*   **Dawn 백엔드 및 구조:** 
-    Chrome의 WebGPU 구현은 자체 백엔드 엔진인 'Dawn'과 셰이더 컴파일을 담당하는 'Tint'를 중심으로 구축되었습니다 [3, 7]. Chromium 프로젝트는 WebGPU 및 WGSL의 적합성 테스트(CTS)를 정기적으로 통합하여 이들 컴포넌트의 안정성과 스펙 준수 여부를 검증하고 있습니다 [3].
-*   **성능 최적화 및 WGSL 확장:** 
-    Chrome 120부터는 WGSL(WebGPU Shading Language)에서 16비트 부동소수점(`f16`) 타입을 지원합니다 [4]. 이는 32비트(`f32`) 타입 대비 메모리 사용량을 크게 줄여주어, WebLLM과 같은 대용량 머신러닝 모델을 브라우저에서 실행할 때 사전 채우기(prefill) 속도 28%, 디코딩 속도 41% 향상 등 극적인 성능 개선을 제공합니다 [4]. 더불어 `maxColorAttachmentBytesPerSample`, `maxStorageBuffersPerShaderStage` 등 파이프라인 리소스의 최대 제한(Limits)을 확장하여 더욱 복잡한 렌더링을 수용할 수 있도록 하였습니다 [8, 9].
-*   **보안과 타임스탬프 쿼리(Timestamp Queries) 구현:** 
-    GPU 명령의 실행 시간을 나노초 단위로 정밀 측정할 수 있는 타임스탬프 쿼리 기능이 구현되었습니다 [10]. 그러나 고해상도 타이머를 악용한 부채널 공격(예: Spectre)을 방지하기 위해, Chrome은 해당 타이밍 데이터의 해상도를 100마이크로초(100us) 단위로 강제 양자화(Quantization)하여 노출합니다 [5, 11, 12]. 성능 프로파일링이 필요한 개발자의 경우, `chrome://flags`에서 `enable-webgpu-developer-features` 및 `enable-unsafe-webgpu` 플래그를 활성화하여 이 양자화 조치를 끄고 정밀 측정을 수행할 수 있습니다 [7, 13].
-*   **플랫폼 지원 확대:** 
-    Chrome 121 버전부터는 Android 기기에서의 WebGPU 지원이 공식 추가되었으며, Windows 시스템에서는 셰이더 컴파일러를 기존 FXC에서 더 효율적인 DXC로 교체하여 컴파일 성능을 최적화했습니다 [6]. 이후로도 서브그룹(Subgroups) 기능 실험, 다중 간접 그리기(multi-draw indirect), HDR 톤 매핑 지원 등 매 버전마다 지속적으로 GPU 기능이 추가되고 있습니다 [6, 14-16].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Graphics & Performance 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[Dawn]], [[WGSL]], [[타임스탬프 쿼리 (Timestamp Queries)]], [[f16 부동소수점]]
-- **Projects/Contexts:** [[Chromium]], [[GPU for the Web Community Group]]
-- **Contradictions/Notes:** 소스에 따르면 WebGPU 타임스탬프 쿼리의 노출 정책에 대한 변화가 있었습니다. 초기에는 보안 문제로 인해 "사이트 격리(Site isolation)가 된 컨텍스트에서만 100마이크로초로 노출하고 비격리 상태에서는 아예 노출하지 않는 방안"이 크롬 팀에 의해 제안되었습니다 [12]. 그러나 플랫폼 간의 상호 운용성(Interop) 문제를 지적하는 의견에 따라, 최종적으로는 격리 여부와 관계없이 고해상도 시간(hr-time) 스펙에 맞춰 일괄적으로 100마이크로초 해상도로 노출하는 것으로 합의되었습니다 [17, 18].
-
----
-*Last updated: 2026-04-19*
-- Raw Source: [[00_Raw/2026-04-20/Chrome WebGPU 구현.md]]
----
diff --git a/Graphics & Performance/Chrome _ Blink WebGPU Implementation.md b/Graphics & Performance/Chrome _ Blink WebGPU Implementation.md
deleted file mode 100644
index ca5ae050..00000000
--- a/Graphics & Performance/Chrome _ Blink WebGPU Implementation.md	
+++ /dev/null
@@ -1,43 +0,0 @@
----
-id: P-REINFORCE-AUTO-4FF4D6
-category: "[[10_Wiki/💡 Topics/Graphics & Performance]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Chrome _ Blink WebGPU Implementation"
----
-
-# [[Chrome _ Blink WebGPU Implementation]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> Chrome과 Blink 엔진에서 WebGPU를 구현한 방식은 현대적인 GPU 파이프라인의 이점을 웹에 제공하면서도 하드웨어 보안을 유지하도록 설계되었습니다. 특히 타이밍 공격을 방지하기 위해 타임스탬프 쿼리에 양자화(Quantization)를 적용하여 해상도를 제한합니다. Chrome 백엔드 엔진인 Dawn을 기반으로 구동되며, 지속적인 업데이트(예: Chrome 120)를 통해 16비트 부동소수점 지원 및 GPU 리소스 할당 한계를 확장하여 성능과 개발자 경험을 향상시키고 있습니다.
-
-## 📖 구조화된 지식 (Synthesized Content)
-* **Dawn 백엔드와 타임스탬프 양자화(Timestamp Quantization):** 
-  Chrome의 WebGPU 백엔드인 Dawn과 Blink 엔진은 `timestamp-query`와 `GPUQuerySet`을 통해 연산 및 렌더링 패스 경계에서 나노초 단위의 정밀한 타이밍 측정이 가능한 API를 구현했습니다 [1, 2]. 그러나 Spectre 및 Meltdown과 같은 타이밍 기반의 사이드 채널 공격(Side-channel attacks)을 방지하기 위해, 브라우저 구현체는 타임스탬프 양자화를 강제하여 타이머의 해상도를 100 마이크로초 단위로 낮추어(Coarsening) 제공합니다 [1, 3-5].
-
-* **사이트 격리(Site Isolation) 정책 변경:**
-  타임스탬프 쿼리의 노출은 초기에는 사이트 격리 환경(Isolated contexts)에서는 100 마이크로초로 제한하고 비격리 환경에서는 아예 노출하지 않는 방향으로 제안되었습니다 [5]. 그러나 최종적으로 GPU for the Web Community Group의 합의를 거쳐, 사이트 격리 여부와 무관하게 `hr-time`의 해상도에 맞춰 항상 100 마이크로초 단위로 타임스탬프를 허용하는 것으로 변경 및 적용되었습니다 [6-8].
-
-* **개발자 환경에서의 보안 우회:** 
-  성능 프로파일링을 위해 로컬 환경에서 정확한 나노초 단위의 타이밍 측정이 필요한 개발자는 `chrome://flags/#enable-webgpu-developer-features` 및 `chrome://flags/#enable-unsafe-webgpu` 플래그를 활성화하여 타임스탬프 양자화를 비활성화할 수 있습니다 [3, 9]. 이 경우 Dawn 내부의 `timestamp_quantization` 디바이스 토글이 해제된 상태로 WebGPU 디바이스가 요청됩니다 [9].
-
-* **WGSL 기능 확장 및 리소스 제한 상향 (Chrome 120 기준):**
-  Chrome 120 업데이트부터 WebGPU 구현은 WGSL(WebGPU Shading Language)에서 16비트 부동소수점 값(`f16`)을 지원하기 시작했습니다. 이는 기존 `f32` 대비 메모리 사용량을 줄여 대규모 데이터를 처리하는 머신러닝(LLM 등) 구동 시 로딩 및 디코딩 속도를 대폭 향상시킵니다 [10, 11]. 이 외에도 `maxColorAttachmentBytesPerSample`을 최대 64바이트로 상향하고, `maxStorageBuffersPerShaderStage`를 최대 10개까지, `maxBindGroupsPlusVertexBuffers`의 기본값을 24로 늘리는 등 하드웨어 리소스의 한계를 확장했습니다 [12, 13]. 
-
-* **상태 관리 및 어댑터 정보 간소화:** 
-  개발자 편의를 위해 `depthWriteEnabled`와 `depthCompare`와 같은 Depth-stencil 상태 속성이 항상 필수로 요구되지 않도록 동작이 개선되었습니다 [14]. 또한 `requestAdapterInfo()`를 호출할 때 "discrete GPU", "integrated GPU" 같은 디바이스 타입과 "D3D12", "metal", "vulkan" 등 백엔드 API에 대한 세부적인 정보를 조회할 수 있는 기능이 추가되었습니다 [14].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Graphics & Performance 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[WebGPU Timestamp Queries]], [[Dawn]], [[Spectre and Meltdown]], [[WGSL]]
-- **Projects/Contexts:** [[Chrome 120 WebGPU Updates]]
-- **Contradictions/Notes:** 소스에 따르면, 타임스탬프 노출에 대한 초기 제안은 보안을 이유로 비격리 컨텍스트에서는 타임스탬프를 전혀 제공하지 않는 것이었으나 [5], 이후 상호 운용성(Interop) 문제를 해결하기 위해 GPU for the Web 커뮤니티 그룹의 합의를 거쳐 컨텍스트의 격리 여부와 상관없이 100 마이크로초 단위로 값을 제공하는 것으로 정책이 수정되었습니다 [6].
-
----
-*Last updated: 2026-04-19*
-- Raw Source: [[00_Raw/2026-04-20/Chrome _ Blink WebGPU Implementation.md]]
----
diff --git a/Graphics & Performance/Chrome.md b/Graphics & Performance/Chrome.md
deleted file mode 100644
index d7496f2d..00000000
--- a/Graphics & Performance/Chrome.md	
+++ /dev/null
@@ -1,34 +0,0 @@
----
-id: P-REINFORCE-AUTO-5D281C
-category: "[[10_Wiki/💡 Topics/Graphics & Performance]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Chrome"
----
-
-# [[Chrome]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> Chrome은 웹 성능 표준과 최신 웹 그래픽 기술을 주도하는 Google의 웹 브라우저이다 [1, 2]. 강력한 개발자 도구인 Chrome DevTools를 제공하여 애플리케이션의 런타임 및 로드 성능을 심층적으로 분석할 수 있게 하며, WebGL 및 WebGPU와 같은 차세대 그래픽 API를 적극적으로 지원한다 [3, 4]. 또한 Chrome 사용자 환경 보고서(CrUX)를 통해 실제 사용자의 성능 데이터를 수집하여 Core Web Vitals를 측정하는 핵심적인 역할을 담당한다 [5, 6].
-
-## 📖 구조화된 지식 (Synthesized Content)
-- **웹 성능 측정 및 Core Web Vitals**: Chrome은 LCP, CLS, INP(기존 FID 대체)와 같은 Core Web Vitals 지표를 브라우저 단에서 직접 측정하며, 이를 Chrome UX Report (CrUX)를 통해 필드 데이터로 수집한다 [5-7]. 최근에는 교차 출처 이미지에 대한 LCP 측정 방식이나 텍스트 강조 시의 INP 처리 방식 등 지표의 정확도를 높이기 위해 측정 방식을 지속적으로 업데이트하고 있다 [8-10].
-- **Chrome DevTools 및 프로파일링**: Chrome DevTools의 Performance 패널을 통해 런타임 성능, CPU 및 네트워크 스로틀링(Throttling), 메인 스레드의 Flame chart 등을 분석할 수 있다 [11-13]. Chrome 129 버전부터는 Performance 탭에서 CrUX 필드 데이터와 로컬 데이터를 실시간으로 비교하는 Live metrics 기능이 추가되었다 [14, 15]. 또한 `about:tracing` 도구를 제공하여 `CrGpuMain`, `CrRendererMain` 등 CPU와 GPU의 저수준 활동을 나노초 단위로 정밀하게 프로파일링할 수 있다 [16-18].
-- **차세대 그래픽 기술 (WebGPU 및 WebGL) 지원**: Chrome은 113 버전부터 WebGPU를 기본적으로 지원하기 시작했으며 [2], Dawn이라는 WebGPU 백엔드를 사용한다 [19]. Chrome 120~146 버전에 걸쳐 WGSL의 16비트 부동소수점(`f16`) 지원, subgroup 기능, 호환성 모드(Compatibility mode) 등 WebGPU의 기능을 지속적으로 확장하고 있다 [20-22].
-- **보안 및 타이밍 제어**: Spectre 및 Meltdown과 같은 보안 취약점에 대응하기 위해, Chrome은 `performance.now()` 및 WebGPU 타임스탬프 쿼리의 정밀도를 제한(Quantization)한다 [19, 23, 24]. 교차 출처 격리(Cross-origin isolated) 상태에 따라 100 마이크로초 단위로 해상도를 낮추며, 개발자 플래그(`chrome://flags/`)를 통해서만 제한을 해제할 수 있도록 보안과 디버깅의 균형을 맞추고 있다 [19, 24, 25].
-- **실험적 기능 (Origin Trials) 및 AI 도입**: 웹 페이지가 전환될 때의 소프트 내비게이션(Soft navigations) 성능을 측정하기 위한 API 실험을 진행 중이며 [26], Speculation rules를 통해 미래의 내비게이션에 필요한 리소스를 미리 렌더링하는 기능도 지원한다 [10, 27]. 더 나아가 DevTools 내에 AI 디버깅 기능과 Model Context Protocol (MCP) 서버를 도입하여 성능 데이터를 기반으로 코드 변경을 자동화하는 실험도 제공하고 있다 [28, 29].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Graphics & Performance 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[Chrome DevTools]], [[WebGPU]], [[Core Web Vitals]], [[CrUX]], [[WebGL]]
-- **Projects/Contexts:** [[Interop 2025]], [[Baseline Project]]
-- **Contradictions/Notes:** 타이밍 공격(Spectre 등) 보안 문제로 인해 WebGPU의 타임스탬프 쿼리나 `EXT_disjoint_timer_query`의 해상도를 하드웨어 성능 그대로 제공하지 못하고, Chrome 자체적으로 사이트 격리 상태에 따라 정밀도를 의도적으로 낮추어(Quantization) 노출해야만 하는 한계가 존재한다 [19, 23, 24].
-
----
-*Last updated: 2026-04-19*
-- Raw Source: [[00_Raw/2026-04-20/Chrome.md]]
----
diff --git a/Graphics & Performance/Chromium WebGPU Implementation.md b/Graphics & Performance/Chromium WebGPU Implementation.md
deleted file mode 100644
index 3c1c1100..00000000
--- a/Graphics & Performance/Chromium WebGPU Implementation.md	
+++ /dev/null
@@ -1,32 +0,0 @@
----
-id: P-REINFORCE-AUTO-7025AF
-category: "[[10_Wiki/💡 Topics/Graphics & Performance]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Chromium WebGPU Implementation"
----
-
-# [[Chromium WebGPU Implementation]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> Chromium의 WebGPU 구현은 **Dawn**이라는 백엔드를 기반으로 하는 차세대 웹 그래픽 및 컴퓨팅 API입니다 [1, 2]. 보안 이슈를 방지하기 위한 타임스탬프 양자화(Timestamp Quantization)와 같은 세밀한 기능이 구현되어 있으며, 싱글 스레드 기반인 WebGL의 한계를 넘어 멀티 스레드 명령 생성과 강력한 컴퓨트 셰이더 기능을 통해 브라우저 내에서 고성능 그래픽과 병렬 연산을 지원합니다 [1, 3, 4].
-
-## 📖 구조화된 지식 (Synthesized Content)
-*   **Dawn 백엔드 및 구조:** Chromium에서 WebGPU API를 구동하는 내부 백엔드 엔진의 이름은 Dawn입니다 [1, 2]. 이 구현체는 WebGL의 기존 싱글 스레드 명령 제출 모델에서 벗어나, 여러 스레드에서 동시에 렌더링 명령을 준비(Multi-Threaded Command Generation)할 수 있도록 설계되어 CPU 오버헤드를 대폭 줄이고 GPU 활용도를 극대화합니다 [3].
-*   **보안 및 타임스탬프 양자화 (Timestamp Quantization):** 고정밀 타이머를 악용한 캐시 사이드 채널 공격(예: Spectre 및 Meltdown)을 방지하기 위해, Blink 및 Dawn 구현체는 타임스탬프 쿼리 결과의 해상도를 100 마이크로초(µs)로 양자화(Coarsening)하여 제공합니다 [1, 5, 6]. Chrome은 초기에는 보안을 위해 격리되지 않은 컨텍스트(non-isolated contexts)에서 이를 완전히 비활성화하려 했으나, 최종적으로 웹 표준 상호 운용성을 고려해 격리 여부와 무관하게 100µs 해상도를 제공하는 것으로 합의되었습니다 [5-7]. 단, 로컬 개발 환경에서 정밀한 성능 프로파일링이 필요할 때는 `chrome://flags`에서 "WebGPU Developer Features" 및 "Unsafe WebGPU Support" 플래그를 켜서 이 양자화를 비활성화할 수 있습니다 [1, 2].
-*   **버전별 주요 진화 과정:** Chrome 113 버전에서 WebGPU가 최초로 기본 활성화된 이후, Chromium 팀은 렌더링 및 머신러닝 기능 확장을 지속해 왔습니다 [8, 9]. 예를 들어, Chrome 120에서는 WGSL 내 16비트 부동소수점(`f16`) 지원을 추가하여 Llama2 모델과 같은 LLM 추론 속도를 비약적으로 향상시켰습니다 [10]. 이후 버전들에서는 서브그룹(Subgroup) 연산 확장, 3D 텍스처 포맷 지원, OpenGL ES 3.1 호환성 모드 등 다양한 GPU 메모리 및 파이프라인 한도(limits)를 상향 조정해나가고 있습니다 [11-14].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Graphics & Performance 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[WebGPU]], [[Dawn]], [[Timestamp Quantization]], [[WGSL]]
-- **Projects/Contexts:** [[Chromium Project]], [[GPU for the Web Community Group]]
-- **Contradictions/Notes:** 타임스탬프 쿼리 기능 노출과 관련하여, 초기 Chromium(Blink) 인텐트는 Cross-Origin 격리되지 않은 컨텍스트에서 타임스탬프 쿼리를 완전히 비활성화할 계획을 세웠으나(보안 우려), 다른 브라우저 벤더 및 W3C 그룹과의 상호 운용성 논의를 거쳐 격리 여부와 무관하게 hr-time과 동일한 100µs 단위로 노출하는 방향으로 스펙 및 구현 방침이 변경되었습니다 [5-7].
-
----
-*Last updated: 2026-04-19*
-- Raw Source: [[00_Raw/2026-04-20/Chromium WebGPU Implementation.md]]
----
diff --git a/Graphics & Performance/Cognitive Load Theory.md b/Graphics & Performance/Cognitive Load Theory.md
deleted file mode 100644
index ecd3a5f1..00000000
--- a/Graphics & Performance/Cognitive Load Theory.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-29F633
-category: "[[10_Wiki/💡 Topics/Graphics & Performance]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Cognitive Load Theory"
----
-
-# [[Cognitive Load Theory]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Graphics & Performance 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Cognitive Load Theory.md]]
----
diff --git a/Graphics & Performance/Cognitive-Load-Theory.md b/Graphics & Performance/Cognitive-Load-Theory.md
deleted file mode 100644
index ff8f722c..00000000
--- a/Graphics & Performance/Cognitive-Load-Theory.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-B1006C
-category: "[[10_Wiki/💡 Topics/Graphics & Performance]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Cognitive-Load-Theory"
----
-
-# [[Cognitive-Load-Theory]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Graphics & Performance 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Cognitive-Load-Theory.md]]
----
diff --git a/Graphics & Performance/Collaborative Learning Environments.md b/Graphics & Performance/Collaborative Learning Environments.md
deleted file mode 100644
index fa20385d..00000000
--- a/Graphics & Performance/Collaborative Learning Environments.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-617D95
-category: "[[10_Wiki/💡 Topics/Graphics & Performance]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Collaborative Learning Environments"
----
-
-# [[Collaborative Learning Environments]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Graphics & Performance 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Collaborative Learning Environments.md]]
----
diff --git a/Graphics & Performance/Competitive Esports Ecosystems.md b/Graphics & Performance/Competitive Esports Ecosystems.md
deleted file mode 100644
index 2a410c42..00000000
--- a/Graphics & Performance/Competitive Esports Ecosystems.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-69DA0B
-category: "[[10_Wiki/💡 Topics/Graphics & Performance]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Competitive Esports Ecosystems"
----
-
-# [[Competitive Esports Ecosystems]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Graphics & Performance 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Competitive Esports Ecosystems.md]]
----
diff --git a/Graphics & Performance/Complexity-Theory.md b/Graphics & Performance/Complexity-Theory.md
deleted file mode 100644
index bcc84c77..00000000
--- a/Graphics & Performance/Complexity-Theory.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-F606A9
-category: "[[10_Wiki/💡 Topics/Graphics & Performance]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Complexity-Theory"
----
-
-# [[Complexity-Theory]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Graphics & Performance 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Complexity-Theory.md]]
----
diff --git a/Graphics & Performance/Computational Ecology.md b/Graphics & Performance/Computational Ecology.md
deleted file mode 100644
index 7b0b5354..00000000
--- a/Graphics & Performance/Computational Ecology.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-563573
-category: "[[10_Wiki/💡 Topics/Graphics & Performance]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Computational Ecology"
----
-
-# [[Computational Ecology]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Graphics & Performance 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Computational Ecology.md]]
----
diff --git a/Graphics & Performance/Computational Geometry.md b/Graphics & Performance/Computational Geometry.md
deleted file mode 100644
index 1948eee8..00000000
--- a/Graphics & Performance/Computational Geometry.md	
+++ /dev/null
@@ -1,30 +0,0 @@
----
-id: P-REINFORCE-AI-053
-category: "[[10_Wiki/💡 Topics/Graphics & Performance]]"
-confidence_score: 0.97
-tags: [geometry, computational geometry, 3d, rendering]
-last_reinforced: 2026-06-XX
-github_commit: "[P-Reinforce] Processed Computational Geometry."
----
-
-# [[Computational Geometry]] (계산 기하학)
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 수학적 알고리즘을 사용하여 컴퓨터가 점, 곡선, 다각형 같은 기하학적 객체들 사이의 관계와 공간 구조를 효율적으로 분석하고 조작하는 기술 분야이다.
-
-## 📖 구조화된 지식 (Synthesized Content)
-- **정의:** 수학과 컴퓨터 과학이 만나는 영역으로, 현실 세계의 형태(건축물, 인체 모델, 게임 오브젝트 등)를 디지털로 표현하고 이를 바탕으로 물리적/시각적 시뮬레이션을 수행하는 기반 기술이다.
-- **핵심 알고리즘 및 구조:**
-    1. **메쉬 데이터 구조:** 3D 객체를 삼각형(Triangle)의 집합으로 근사화하여 저장하고 처리한다. (Vertices, Edges, Faces).
-    2. **공간 분할 기법:** 대규모 데이터를 효율적으로 검색하기 위해 공간을 나누는 방법들 (예: Octree, BVH - Bounding Volume Hierarchy). 이는 렌더링의 성능(Culling)에 필수적이다.
-    3. **좌표 변환 및 근사화:** 카메라 위치나 오브젝트 이동에 따른 좌표계 변환(Transformation Matrix), 그리고 복잡한 곡선을 단순화하는 과정이 포함된다.
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 기하학적 모델링은 단순히 형태를 만드는 것을 넘어, 물리 엔진과의 결합을 통해 '물리 법칙'을 시뮬레이션하고 그 결과를 예측하는 데 사용된다.
-- **정책 변화:** 최신 트렌드는 하드웨어 가속(GPU)과 연동하여 복잡한 기하학적 계산(예: Ray Tracing)을 실시간으로 처리하는 방향으로 진화하고 있다.
-
-## 🔗 지식 연결 (Graph)
-- Parent: [[Computational Geometry]]
-- Related: [[Bounding Volume Hierarchy (BVH)]] , [[Three.js 렌더링 최적화]] , [[Physics-Based-Simulation]]
-- Raw Source: [[00_Raw/Computational Geometry.md]]
----
\ No newline at end of file
diff --git a/Graphics & Performance/Compute Shader.md b/Graphics & Performance/Compute Shader.md
deleted file mode 100644
index d577204b..00000000
--- a/Graphics & Performance/Compute Shader.md	
+++ /dev/null
@@ -1,34 +0,0 @@
----
-id: P-REINFORCE-AUTO-38086E
-category: "[[10_Wiki/💡 Topics/Graphics & Performance]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Compute Shader"
----
-
-# [[Compute Shader]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 컴퓨트 셰이더(Compute Shader)는 자바스크립트 메인 스레드나 CPU가 처리하던 무거운 연산 작업을 수천 개의 GPU 코어를 활용해 병렬로 처리할 수 있게 해주는 WebGPU의 핵심 기능입니다 [1]. 주로 입자(Particle) 시스템, 물리 연산, 실시간 필터링, 그리고 대규모 객체의 가시성 판별(Culling)과 같은 범용 GPU 연산(GPGPU)에 사용되어, 기존 WebGL 기반 환경의 한계를 뛰어넘는 압도적인 성능 향상을 제공합니다 [1-3].
-
-## 📖 구조화된 지식 (Synthesized Content)
-* **대규모 데이터 연산 및 성능 향상:** CPU 기반의 입자 시스템은 일반적으로 5만 개 정도에서 성능 병목을 겪지만, WebGPU 컴퓨트 셰이더를 도입하면 이를 수백만 개 단위로 확장할 수 있습니다 [2, 4]. 예를 들어, 1만 개의 입자를 CPU에서 업데이트할 때 30ms가 걸리던 작업을 컴퓨트 셰이더를 사용하면 10만 개의 입자를 2ms 이내에 처리하여 150배 이상의 성능 향상을 얻을 수 있습니다 [5]. 
-* **주요 활용 분야:** 컴퓨트 셰이더는 충돌 감지(Collision detection), 실시간 조명 계산, 대규모 데이터 필터링, 구조 시뮬레이션 등에 효과적으로 적용됩니다 [1, 4]. 실시간 편집과 거대한 스케일이 필요한 절차적 지형 생성(Procedural terrain generation)도 가능하게 해줍니다 [6]. 또한, 메쉬의 정점 변환을 컴퓨트 단계에서 미리 처리해 버퍼에 저장해두고 여러 렌더 패스에서 재사용하는 '컴퓨트 스키닝(Compute Skinning)' 기법도 지원합니다 [5].
-* **메모리 활용 및 스토리지 텍스처:** 일반적인 텍스처와 달리 컴퓨트 셰이더 환경에서는 '스토리지 텍스처(Storage textures)'를 통해 셰이더 내에서 읽기와 쓰기 작업을 동시에 수행할 수 있으며, 이는 유체 시뮬레이션이나 이미지 처리 등에 필수적입니다 [7, 8]. 더불어 스레드 간 데이터 공유가 필요한 작업에서는 작업 그룹 변수(Workgroup variables)를 사용한 공유 메모리를 활용할 수 있는데, 이는 반복적인 데이터 접근 패턴에서 전역 메모리보다 10~100배 더 빠른 속도를 제공합니다 [6, 9].
-* **GPU 주도 렌더링(GPU-driven Rendering)과 간접 그리기:** 컴퓨트 셰이더는 간접 그리기(Indirect draw)와 결합하여 렌더링 파이프라인의 효율성을 극대화합니다 [9]. CPU가 인스턴스의 위치를 검사하고 그리기 명령을 준비하는 대신, 컴퓨트 셰이더가 직접 시야 포함 여부나 오클루전(가림 현상)을 판별한 뒤 시각적으로 유효한 객체들로만 간접 그리기 버퍼를 채웁니다 [3, 10, 11]. 이 방식을 통해 CPU와 GPU 간의 데이터 전송량을 거의 0으로 수렴하게 만들 수 있습니다 [3].
-* **렌더링 동기화:** 컴퓨트 셰이더가 포함된 씬을 렌더링할 때는 GPU 작업의 적절한 동기화가 필요합니다 [12]. 종속적인 렌더 패스가 시작되기 전에 컴퓨트 패스의 작업이 완전히 완료되도록 보장하기 위해 `renderAsync`와 같은 비동기 렌더링 방식의 사용이 권장됩니다 [12].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Graphics & Performance 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[WebGPU]], [[GPU-driven Rendering]], [[Indirect Draw]], [[Frustum Culling]]
-- **Projects/Contexts:** 대규모 건설 및 BIM 모델 플랫폼(수백만 개의 컴포넌트 렌더링 최적화) [13, 14], 엑스포 2025 오사카에 전시된 100만 파티클 유체 시뮬레이션 설치물(Hokusai) [15, 16]. 
-- **Contradictions/Notes:** 컴퓨트 셰이더는 최신 그래픽 API인 WebGPU에서 기본 지원되지만, 구형 WebGL이나 WebGL2 환경에서는 직접적으로 지원되지 않으므로 이를 활용하기 위해서는 반드시 WebGPU 기반의 렌더러 환경을 사용해야 한다는 제약이 있습니다 [3, 17].
-
----
-*Last updated: 2026-04-19*
-- Raw Source: [[00_Raw/2026-04-20/Compute Shader.md]]
----
diff --git a/Graphics & Performance/Compute Shaders.md b/Graphics & Performance/Compute Shaders.md
deleted file mode 100644
index 2f0bc0a9..00000000
--- a/Graphics & Performance/Compute Shaders.md	
+++ /dev/null
@@ -1,34 +0,0 @@
----
-id: P-REINFORCE-AUTO-B1DBB3
-category: "[[10_Wiki/💡 Topics/Graphics & Performance]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Compute Shaders"
----
-
-# [[Compute Shaders]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 컴퓨트 셰이더(Compute Shaders)는 WebGPU 환경에서 지원되는 기능으로, CPU의 메인 스레드에서 수행되던 무거운 범용 연산 작업을 GPU로 오프로드하는 핵심 기술입니다 [1, 2]. GPU의 수천 개 코어를 활용한 병렬 처리를 통해 물리 시뮬레이션, 충돌 감지, 대규모 파티클 시스템 등의 작업 성능을 비약적으로 향상시킵니다 [2]. 또한 간접 그리기(Indirect Drawing) 기술과 결합하여 CPU의 개입 없이 가시성을 판별하고 화면을 그리는 완전한 GPU 주도 렌더링(GPU-driven Rendering) 파이프라인을 구축하는 데 사용됩니다 [3, 4].
-
-## 📖 구조화된 지식 (Synthesized Content)
-* **범용 GPU 연산 및 성능 향상:** 컴퓨트 셰이더는 물리 시뮬레이션, 충돌 감지, 유체 시뮬레이션, 이미지 처리, 대규모 데이터 필터링, 절차적 지형 생성 등 복잡한 연산을 CPU 대신 GPU에서 병렬로 처리합니다 [2, 5-8]. 기존 CPU 기반 파티클 업데이트는 약 5만 개 수준에서 병목이 발생하지만, WebGPU 컴퓨트 셰이더를 활용하면 10만 개의 파티클을 2ms 이내에 업데이트하여 최대 150배의 성능 향상을 내며 수백만 개의 유닛을 처리할 수 있습니다 [9-12].
-* **GPU 주도 렌더링 및 컬링 (GPU-driven Rendering & Culling):** 간접 그리기(Indirect Drawing) 명령과 결합하여 극도로 효율적인 렌더링 파이프라인을 구성합니다 [4, 13]. 컴퓨트 셰이더가 모든 인스턴스에 대해 시야 절두체(Frustum) 및 오클루전(Occlusion) 컬링 판별을 수행하고, 화면에 보이는 객체 정보만 원자적 카운터(Atomic Counter)를 통해 간접 그리기 버퍼에 추가합니다 [3, 4, 14]. 이를 통해 CPU와 GPU 간의 데이터 동기화 지연과 명령 발행 오버헤드가 사실상 0에 수렴하게 됩니다 [4, 15].
-* **데이터 공유 및 메모리 최적화:** 읽기와 쓰기가 모두 가능한 스토리지 텍스처(Storage Textures)를 활용해 GPU 기반 렌더링과 효과 처리를 유연하게 수행합니다 [6, 16]. 또한 스레드 간 데이터 공유가 필요한 경우, 반복 접근 패턴에서 전역 메모리보다 10~100배 더 빠른 작업 그룹 공유 메모리(Workgroup Shared Memory)를 활용할 수 있습니다 [7, 13].
-* **고급 연산 기법 지원:** 컴퓨트 단계에서 메쉬 정점 변환을 처리하고 그 결과를 버퍼에 저장해 불필요한 중복 연산을 제거하는 '컴퓨트 스키닝(Compute Skinning)'이 가능해집니다 [12]. 또한 glTF 모델에 흔히 쓰이는 8비트/16비트 정수 데이터를 32비트 포맷으로 압축 해제하는 작업도 렌더링 파이프라인 외곽에서 효율적으로 수행할 수 있습니다 [12].
-* **동기화 및 파이프라인 제어 베스트 프랙티스:** 연산 의존성이 높은 씬을 Three.js에서 렌더링할 때는 `renderAsync`를 사용하여 렌더 패스가 시작되기 전에 컴퓨트 패스가 완전히 끝나도록 동기화해야 합니다 [17]. 성능 처리량을 극대화하기 위해서는 스테이징 버퍼(Staging Buffers)를 활용한 이중 버퍼링(Double-buffering)을 적용하는 것이 좋으며, 디스패치 사이에 `await mapAsync()`를 호출할 경우 GPU 파이프라인을 멈추게 만들 수 있으므로 지양해야 합니다 [18].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Graphics & Performance 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** `[[WebGPU]]`, `[[GPU-driven Rendering]]`, `[[Indirect Drawing]]`, `[[Storage Textures]]`, `[[Frustum Culling]]`
-- **Projects/Contexts:** `[[Three.js]]`, `[[Segments.ai]]`, `[[BIM Datasets]]`
-- **Contradictions/Notes:** 컴퓨트 셰이더는 엄청난 성능 향상을 제공하지만 구형 API인 WebGL이나 WebGL 2에서는 지원되지 않아 WebGPU 환경이 필수적입니다 [1]. 또한 GPU 최적화를 제대로 다루지 못해 동기화 대기(`await mapAsync()`)를 남용할 경우, 오히려 GPU가 최대 60%의 시간 동안 유휴 상태(Idle)에 빠지는 병목 현상을 유발할 수 있습니다 [18].
-
----
-*Last updated: 2026-04-19*
-- Raw Source: [[00_Raw/2026-04-20/Compute Shaders.md]]
----
diff --git a/Graphics & Performance/Computer-Vision-Synthesis.md b/Graphics & Performance/Computer-Vision-Synthesis.md
deleted file mode 100644
index 59af25e9..00000000
--- a/Graphics & Performance/Computer-Vision-Synthesis.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-C1EBB8
-category: "[[10_Wiki/💡 Topics/Graphics & Performance]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Computer-Vision-Synthesis"
----
-
-# [[Computer-Vision-Synthesis]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Graphics & Performance 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Computer-Vision-Synthesis.md]]
----
diff --git a/Graphics & Performance/Creative Process.md b/Graphics & Performance/Creative Process.md
deleted file mode 100644
index 8ae7245a..00000000
--- a/Graphics & Performance/Creative Process.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-DF48CA
-category: "[[10_Wiki/💡 Topics/Graphics & Performance]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Creative Process"
----
-
-# [[Creative Process]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Graphics & Performance 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Creative Process.md]]
----
diff --git a/Graphics & Performance/Critical-Play.md b/Graphics & Performance/Critical-Play.md
deleted file mode 100644
index e42bd858..00000000
--- a/Graphics & Performance/Critical-Play.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-0C480C
-category: "[[10_Wiki/💡 Topics/Graphics & Performance]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Critical-Play"
----
-
-# [[Critical-Play]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Graphics & Performance 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Critical-Play.md]]
----
diff --git a/Graphics & Performance/Cultural-Heritage-Informatics.md b/Graphics & Performance/Cultural-Heritage-Informatics.md
deleted file mode 100644
index 93a5c5c7..00000000
--- a/Graphics & Performance/Cultural-Heritage-Informatics.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-90A1AA
-category: "[[10_Wiki/💡 Topics/Graphics & Performance]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Cultural-Heritage-Informatics"
----
-
-# [[Cultural-Heritage-Informatics]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Graphics & Performance 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Cultural-Heritage-Informatics.md]]
----
diff --git a/Graphics & Performance/CyArk.md b/Graphics & Performance/CyArk.md
deleted file mode 100644
index c7bee9bb..00000000
--- a/Graphics & Performance/CyArk.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-78F905
-category: "[[10_Wiki/💡 Topics/Graphics & Performance]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - CyArk"
----
-
-# [[CyArk]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Graphics & Performance 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/CyArk.md]]
----
diff --git a/Graphics & Performance/Cybertext Theory.md b/Graphics & Performance/Cybertext Theory.md
deleted file mode 100644
index 024f5695..00000000
--- a/Graphics & Performance/Cybertext Theory.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-896181
-category: "[[10_Wiki/💡 Topics/Graphics & Performance]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Cybertext Theory"
----
-
-# [[Cybertext Theory]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Graphics & Performance 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Cybertext Theory.md]]
----
diff --git a/Graphics & Performance/DBpedia.md b/Graphics & Performance/DBpedia.md
deleted file mode 100644
index a4e39c25..00000000
--- a/Graphics & Performance/DBpedia.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-0B4232
-category: "[[10_Wiki/💡 Topics/Graphics & Performance]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - DBpedia"
----
-
-# [[DBpedia]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Graphics & Performance 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/DBpedia.md]]
----
diff --git a/Graphics & Performance/Data Array Textures.md b/Graphics & Performance/Data Array Textures.md
deleted file mode 100644
index e0b2ef96..00000000
--- a/Graphics & Performance/Data Array Textures.md	
+++ /dev/null
@@ -1,33 +0,0 @@
----
-id: P-REINFORCE-AUTO-8AF01A
-category: "[[10_Wiki/💡 Topics/Graphics & Performance]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Data Array Textures"
----
-
-# [[Data Array Textures]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> Data Array Textures(배열 텍스처)는 셰이더에서 인덱스를 통해 접근할 수 있는 여러 2D 텍스처들의 스택 또는 레이어 구조를 의미합니다 [1, 2]. 이는 여러 이미지를 단일 이미지로 패킹하는 전통적인 텍스처 아틀라스(Texture Atlas)의 문제점들을 해결하는 현대적인 접근 방식입니다 [2]. 특히 다양한 텍스처를 사용하는 여러 객체를 `BatchedMesh`와 결합하여 최소한의 드로우 콜(Draw Call)로 렌더링할 수 있게 해주어 3D 렌더링 성능 최적화에 핵심적인 역할을 합니다 [1, 2].
-
-## 📖 구조화된 지식 (Synthesized Content)
-- **주요 장점:** 배열 텍스처는 인접한 텍스처가 섞이는 경계 번짐(Edge bleeding) 현상을 제거하고, 네이티브 텍스처 래핑(Wrapping) 및 타일링(Tiling)을 지원하며, 교차 오염 없이 각 레이어별로 올바른 밉맵(Mipmap)을 생성할 수 있습니다 [2]. 또한 복잡한 UV 오프셋 계산이나 아틀라스 패킹 알고리즘이 필요하지 않아 셰이더 코드가 크게 단순화됩니다 [2].
-- **렌더링 성능 및 활용:** `BatchedMesh`와 함께 사용하면 셰이더 분기(Branching) 처리 대신 하드웨어 인덱싱을 직접 사용하여 한 번의 드로우 콜만으로 서로 다른 텍스처를 가진 수많은 객체를 렌더링할 수 있습니다 [2]. 또한 노멀 맵, 러프니스 맵, 메탈니스 맵 등을 TextureArray로 저장하여 객체별로 고유한 질감을 부여하거나 [3], 원거리 객체를 표시하기 위한 빌보드 임포스터(Billboard impostors)의 다각도 뷰를 텍스처 배열로 저장하여 렌더링하는 데에도 활용될 수 있습니다 [4].
-- **구조적 한계 및 단점:** 배열 텍스처 내에 포함되는 모든 텍스처는 반드시 동일한 크기(Dimensions)를 가져야만 합니다 [5]. 다양한 해상도를 섞어 써야 한다면 여러 개의 배열 텍스처를 생성하거나 기존의 텍스처 아틀라스를 사용해야 합니다 [5]. 
-- **메모리 및 호환성:** 텍스처 아틀라스가 메모리를 더 밀도 있게 패킹할 수 있는 반면, 배열 텍스처는 런타임에 모든 레이어의 메모리를 사전에 할당해야 하는 메모리 오버헤드가 있습니다 [5]. 이 기술은 WebGL2 환경을 요구하지만, 2025년 기준 브라우저 지원이 매우 우수하여 동일한 크기의 텍스처를 다루는 현대 웹 그래픽 프로젝트에서는 전통적 아틀라싱보다 뛰어난 성능을 발휘합니다 [5].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Graphics & Performance 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[Texture Atlas]], [[BatchedMesh]], [[Draw Calls]], [[WebGL2]]
-- **Projects/Contexts:** [[Three.js 성능 최적화]], [[빌보드 임포스터(Billboard Impostors)]]
-- **Contradictions/Notes:** 소스에 따르면 Data Array Textures는 텍스처 아틀라스의 단점들을 완벽히 보완하는 현대적 대안이지만, '모든 텍스처의 크기가 같아야 한다'는 엄격한 제약과 '메모리 선할당'의 부담이 존재하므로, 가변적인 크기의 텍스처를 압축하거나 구형 WebGL1 환경을 지원해야 할 때는 여전히 텍스처 아틀라스(Texture Atlas)가 가치 있는 선택지로 남는다고 지적합니다 [5].
-
----
-*Last updated: 2026-04-19*
-- Raw Source: [[00_Raw/2026-04-20/Data Array Textures.md]]
----
diff --git a/Graphics & Performance/Digital Sandbox Theory.md b/Graphics & Performance/Digital Sandbox Theory.md
deleted file mode 100644
index d022cb94..00000000
--- a/Graphics & Performance/Digital Sandbox Theory.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-A1EFBC
-category: "[[10_Wiki/💡 Topics/Graphics & Performance]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Digital Sandbox Theory"
----
-
-# [[Digital Sandbox Theory]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Graphics & Performance 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Digital Sandbox Theory.md]]
----
diff --git a/Graphics & Performance/Digital Twin Visualization.md b/Graphics & Performance/Digital Twin Visualization.md
deleted file mode 100644
index fb69fef0..00000000
--- a/Graphics & Performance/Digital Twin Visualization.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-F0B4B1
-category: "[[10_Wiki/💡 Topics/Graphics & Performance]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Digital Twin Visualization"
----
-
-# [[Digital Twin Visualization]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Graphics & Performance 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Digital Twin Visualization.md]]
----
diff --git a/Graphics & Performance/Direct3D.md b/Graphics & Performance/Direct3D.md
deleted file mode 100644
index b54b6dba..00000000
--- a/Graphics & Performance/Direct3D.md	
+++ /dev/null
@@ -1,32 +0,0 @@
----
-id: P-REINFORCE-AUTO-D41B4F
-category: "[[10_Wiki/💡 Topics/Graphics & Performance]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Direct3D"
----
-
-# [[Direct3D]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> Direct3D(D3D11, D3D12 등 포함)는 주요 네이티브 그래픽스 API로, Windows 환경의 웹 브라우저에서 그래픽 렌더링의 핵심 백엔드 역할을 합니다 [1, 2]. 최신 버전인 Direct3D 12는 Vulkan, Metal과 함께 차세대 웹 그래픽스 표준인 WebGPU의 설계와 아키텍처에 직접적인 영감을 준 현대적인 API입니다 [3].
-
-## 📖 구조화된 지식 (Synthesized Content)
-- **WebGL 호출 변환 (ANGLE의 활용):** Windows 운영 체제에서 Chrome, Firefox, Opera 등의 웹 브라우저는 ANGLE(Almost Native Graphics Layer Engine)을 사용하여 WebGL(OpenGL ES) 호출을 Direct3D로 변환하여 처리합니다 [1]. (필요에 따라 개발자는 ANGLE을 우회하여 네이티브 OpenGL 구현을 테스트할 수 있습니다 [1]).
-- **WebGPU 아키텍처 설계의 기반:** WebGPU는 기존의 노후화된 OpenGL 표준을 기반으로 구축된 WebGL과 달리, 처음부터 최신 GPU 하드웨어를 위해 설계되었습니다 [3]. 이 과정에서 Direct3D 12는 Vulkan, Metal과 같은 여타 최신 API들과 함께 WebGPU가 차용하고 참고한 핵심적인 현대 그래픽스 API로 평가받습니다 [3].
-- **WebGPU 백엔드 어댑터 지원:** WebGPU 환경에서 `requestAdapterInfo()`를 호출하여 확인할 수 있는 백엔드(backend) 속성 값에는 'D3D11'과 'D3D12'가 포함되어 있습니다 [2]. Chrome 115 릴리스에서는 Direct3D 11에 대한 실험적 지원(Experimental support)이 추가되기도 하였습니다 [4].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Graphics & Performance 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[WebGL]], [[WebGPU]], [[ANGLE]], [[Vulkan]], [[Metal]]
-- **Projects/Contexts:** [[브라우저 그래픽 렌더링 백엔드]], [[Chrome WebGPU 구현]]
-- **Contradictions/Notes:** Direct3D 자체의 내부 구조나 깊이 있는 기술적 명세에 대해서는 소스에 관련 정보가 부족합니다.
-
----
-*Last updated: 2026-04-19*
-- Raw Source: [[00_Raw/2026-04-20/Direct3D.md]]
----
diff --git a/Graphics & Performance/Drama-Management-Systems.md b/Graphics & Performance/Drama-Management-Systems.md
deleted file mode 100644
index 8f21b4f8..00000000
--- a/Graphics & Performance/Drama-Management-Systems.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-6D19F6
-category: "[[10_Wiki/💡 Topics/Graphics & Performance]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Drama-Management-Systems"
----
-
-# [[Drama-Management-Systems]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Graphics & Performance 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Drama-Management-Systems.md]]
----
diff --git a/Graphics & Performance/Draw Call.md b/Graphics & Performance/Draw Call.md
deleted file mode 100644
index be333249..00000000
--- a/Graphics & Performance/Draw Call.md	
+++ /dev/null
@@ -1,39 +0,0 @@
----
-id: P-REINFORCE-AUTO-E9A644
-category: "[[10_Wiki/💡 Topics/Graphics & Performance]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Draw Call"
----
-
-# [[Draw Call]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 드로우 콜(Draw Call)은 CPU가 GPU에게 렌더링할 기하학적 구조, 재질 및 렌더링 상태를 전달하며 객체를 화면에 그리도록 지시하는 명령입니다 [1, 2]. 실제 그래픽을 렌더링하는 연산 자체보다, 렌더링을 준비하고 상태를 변경하는 과정에서 발생하는 CPU 오버헤드가 매우 커서 성능 병목의 주된 원인이 됩니다 [3-5]. 따라서 실시간 3D 그래픽 애플리케이션에서는 높은 프레임 속도 유지를 위해 인스턴싱, 배칭, 지오메트리 병합 등의 최적화 기법을 통해 드로우 콜의 횟수를 최소화해야 합니다 [6-9].
-
-## 📖 구조화된 지식 (Synthesized Content)
-*   **드로우 콜의 작동 원리**
-    드로우 콜이 발생할 때마다 시스템은 여러 단계를 거칩니다. 첫째, CPU가 변환 행렬, 셰이더 참조, 유니폼(Uniform) 및 정점 버퍼 등을 수집하여 준비합니다 [3]. 둘째, GPU 내에서 셰이더 프로그램 전환, 텍스처 바인딩, 렌더링 상태 구성 등의 렌더링 상태 변경(State Change)이 일어납니다 [3, 5, 10]. 셋째, 시스템 버스를 통해 CPU-GPU 간 통신이 이루어진 후 마지막으로 GPU가 실제 정점을 처리하고 렌더링하게 됩니다 [3]. 
-
-*   **드로우 콜 오버헤드와 CPU 병목**
-    삼각형이 10개이든 10,000개이든 렌더링을 준비하는 1~3단계의 시간은 거의 동일하게 소모됩니다 [3]. 즉, 화면에 그리는 폴리곤의 개수보다 드로우 콜의 횟수가 성능에 훨씬 더 결정적인 영향을 미칩니다 [11]. 만약 수천 개의 객체를 개별적으로 렌더링한다면 CPU가 명령을 발행하는 속도가 GPU의 렌더링 속도를 따라가지 못해 병목 현상이 발생하고 GPU가 굶주리는(Starve) 상태가 됩니다 [6]. 일반적으로 원활한 60fps 성능을 유지하기 위해서는 프레임당 100회 미만의 드로우 콜을 목표로 하는 것이 좋으며 [11, 12], 기기나 브라우저에 따라 1,000~2,000회를 초과하면 CPU 바운드에 의한 심각한 프레임 저하가 발생합니다 [8].
-
-*   **주요 드로우 콜 최적화 기법**
-    *   **인스턴싱(Instancing):** 동일한 기하학적 구조와 재질을 공유하는 여러 객체(예: 풀잎, 나무, 입자 등)의 경우, 변환 행렬만 다르게 적용하여 단 한 번의 드로우 콜로 수백~수천 개의 객체를 렌더링할 수 있습니다 (`InstancedMesh` 활용) [7, 13, 14].
-    *   **배칭(Batching) 및 병합(Merging):** 구조가 다르더라도 동일한 재질을 공유하는 객체들을 묶어 하나의 드로우 콜로 처리하거나(`BatchedMesh`), 아예 움직이지 않는 정적 객체들의 기하학적 구조를 하나로 병합(Geometry Merging)하여 호출 횟수를 획기적으로 줄입니다 [9, 15, 16].
-    *   **상태 변경 최소화:** 여러 개의 텍스처를 텍스처 아틀라스(Texture Atlases)나 데이터 배열 텍스처(Data Array Textures)로 결합하여, 드로우 콜 중간에 텍스처를 전환하며 발생하는 GPU 렌더링 상태 변경 오버헤드를 방지합니다 [17-19].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Graphics & Performance 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[Render State]], [[CPU Bottleneck]], [[InstancedMesh]], [[BatchedMesh]], [[Geometry Merging]], [[Texture Atlas]]
-- **Projects/Contexts:** [[Three.js]], [[WebGL]], [[WebGPU]], [[Unity]]
-- **Contradictions/Notes:** 소스에 따르면, 드로우 콜을 1회로 줄이는 것(`InstancedMesh` 등의 도입)이 무조건 프레임 속도 상승으로 이어지지는 않습니다. 수만 개의 객체가 하나의 드로우 콜로 묶이게 되면 엔진의 시야 절두체 컬링(Frustum Culling) 정밀도가 떨어지거나 투명 객체의 정렬(Sorting) 부재로 인해 막대한 오버드로우(Overdraw)가 발생하여, 결과적으로 CPU 명령은 줄어도 GPU 연산량은 오히려 기하급수적으로 늘어나는 현상이 일어날 수 있습니다 [10, 20-22]. 
-
----
-*Last updated: 2026-04-19*
-- Raw Source: [[00_Raw/2026-04-20/Draw Call.md]]
----
diff --git a/Graphics & Performance/Dual-Track-Agile.md b/Graphics & Performance/Dual-Track-Agile.md
deleted file mode 100644
index 439a5702..00000000
--- a/Graphics & Performance/Dual-Track-Agile.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-92B7C5
-category: "[[10_Wiki/💡 Topics/Graphics & Performance]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Dual-Track-Agile"
----
-
-# [[Dual-Track-Agile]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Graphics & Performance 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Dual-Track-Agile.md]]
----
diff --git a/Graphics & Performance/Duolingo (Language Learning)] [Fitness Tracking Apps (Strava_Fitbit)] [EdTech Gamification] [FinTech Engagement Strategies.md b/Graphics & Performance/Duolingo (Language Learning)] [Fitness Tracking Apps (Strava_Fitbit)] [EdTech Gamification] [FinTech Engagement Strategies.md
deleted file mode 100644
index 5525c230..00000000
--- a/Graphics & Performance/Duolingo (Language Learning)] [Fitness Tracking Apps (Strava_Fitbit)] [EdTech Gamification] [FinTech Engagement Strategies.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-259FF2
-category: "[[10_Wiki/💡 Topics/Graphics & Performance]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Duolingo (Language Learning)] [Fitness Tracking Apps (Strava_Fitbit)] [EdTech Gamification] [FinTech Engagement Strategies"
----
-
-# [[Duolingo (Language Learning)] [Fitness Tracking Apps (Strava_Fitbit)] [EdTech Gamification] [FinTech Engagement Strategies]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Graphics & Performance 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Duolingo (Language Learning)], [Fitness Tracking Apps (Strava_Fitbit)], [EdTech Gamification], [FinTech Engagement Strategies.md]]
----
diff --git a/Graphics & Performance/Dynamic Assessment.md b/Graphics & Performance/Dynamic Assessment.md
deleted file mode 100644
index 991c166d..00000000
--- a/Graphics & Performance/Dynamic Assessment.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-240DDB
-category: "[[10_Wiki/💡 Topics/Graphics & Performance]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Dynamic Assessment"
----
-
-# [[Dynamic Assessment]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Graphics & Performance 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Dynamic Assessment.md]]
----
diff --git a/Graphics & Performance/Dynamical Systems Theory.md b/Graphics & Performance/Dynamical Systems Theory.md
deleted file mode 100644
index c3fefa76..00000000
--- a/Graphics & Performance/Dynamical Systems Theory.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-9A39F2
-category: "[[10_Wiki/💡 Topics/Graphics & Performance]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Dynamical Systems Theory"
----
-
-# [[Dynamical Systems Theory]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Graphics & Performance 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Dynamical Systems Theory.md]]
----
diff --git a/Graphics & Performance/EXT_disjoint_timer_query.md b/Graphics & Performance/EXT_disjoint_timer_query.md
deleted file mode 100644
index fe6603f2..00000000
--- a/Graphics & Performance/EXT_disjoint_timer_query.md	
+++ /dev/null
@@ -1,30 +0,0 @@
----
-id: P-REINFORCE-AUTO-496C9B
-category: "[[10_Wiki/💡 Topics/Graphics & Performance]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - EXT_disjoint_timer_query"
----
-
-# [[EXT_disjoint_timer_query]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> `EXT_disjoint_timer_query`는 렌더링 파이프라인을 멈추지 않고 GPU에서 실행되는 GL 명령어 세트의 소요 시간을 측정할 수 있게 해주는 WebGL API 확장 기능입니다 [1, 2]. 개발자들은 이를 통해 하드웨어 수준에서 명령어 실행의 시작과 끝을 기록하여 비동기 실행 모델의 미세 지연(Micro-latency)을 정확히 측정할 수 있었습니다 [1, 3]. 그러나 이 고정밀 타이머가 메모리 접근 패턴 관찰 등 부채널 공격(Side-channel attacks)에 악용될 수 있다는 보안상 취약점이 발견되어, 현재 대부분의 브라우저에서 비활성화되거나 정밀도가 크게 제한되었습니다 [3-5].
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Graphics & Performance 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[Micro-latency]], [[Side-channel attacks]], [[Spectre and Meltdown]], [[Rowhammer attack]]
-- **Projects/Contexts:** [[WebGL API]], [[WebGPU Timestamp Queries]]
-- **Contradictions/Notes:** 소스 213은 Chrome이 Site Isolation이 적용된 플랫폼에서 `EXT_disjoint_timer_query`를 노출하여 작동한다고 보고하지만, 소스 380의 사용자는 Rowhammer 공격 방지를 이유로 "모든 브라우저에서 비활성화되어 전혀 작동하지 않는다(it is disabled in all browsers)"고 모순되게 주장합니다.
-
----
-*Last updated: 2026-04-19*
-- Raw Source: [[00_Raw/2026-04-20/EXT_disjoint_timer_query.md]]
----
diff --git a/Graphics & Performance/Ecosystem-Modeling.md b/Graphics & Performance/Ecosystem-Modeling.md
deleted file mode 100644
index f0f3c9a0..00000000
--- a/Graphics & Performance/Ecosystem-Modeling.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-6E0EC9
-category: "[[10_Wiki/💡 Topics/Graphics & Performance]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Ecosystem-Modeling"
----
-
-# [[Ecosystem-Modeling]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Graphics & Performance 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Ecosystem-Modeling.md]]
----
diff --git a/Graphics & Performance/EdTech (Gamified Learning).md b/Graphics & Performance/EdTech (Gamified Learning).md
deleted file mode 100644
index 0d0a4236..00000000
--- a/Graphics & Performance/EdTech (Gamified Learning).md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-5D4E83
-category: "[[10_Wiki/💡 Topics/Graphics & Performance]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - EdTech (Gamified Learning)"
----
-
-# [[EdTech (Gamified Learning)]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Graphics & Performance 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/EdTech (Gamified Learning).md]]
----
diff --git a/Graphics & Performance/Educational-Gamification.md b/Graphics & Performance/Educational-Gamification.md
deleted file mode 100644
index 7ec5f3ca..00000000
--- a/Graphics & Performance/Educational-Gamification.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-8F5AE3
-category: "[[10_Wiki/💡 Topics/Graphics & Performance]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Educational-Gamification"
----
-
-# [[Educational-Gamification]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Graphics & Performance 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Educational-Gamification.md]]
----
diff --git a/Graphics & Performance/Embodied Cognition in Virtual Reality.md b/Graphics & Performance/Embodied Cognition in Virtual Reality.md
deleted file mode 100644
index 928b0d0a..00000000
--- a/Graphics & Performance/Embodied Cognition in Virtual Reality.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-C2E060
-category: "[[10_Wiki/💡 Topics/Graphics & Performance]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Embodied Cognition in Virtual Reality"
----
-
-# [[Embodied Cognition in Virtual Reality]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Graphics & Performance 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Embodied Cognition in Virtual Reality.md]]
----
diff --git a/Graphics & Performance/Employee Engagement Systems.md b/Graphics & Performance/Employee Engagement Systems.md
deleted file mode 100644
index 9e153748..00000000
--- a/Graphics & Performance/Employee Engagement Systems.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-9F0879
-category: "[[10_Wiki/💡 Topics/Graphics & Performance]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Employee Engagement Systems"
----
-
-# [[Employee Engagement Systems]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Graphics & Performance 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Employee Engagement Systems.md]]
----
diff --git a/Graphics & Performance/Epidemiological Forecasting.md b/Graphics & Performance/Epidemiological Forecasting.md
deleted file mode 100644
index 77b625c5..00000000
--- a/Graphics & Performance/Epidemiological Forecasting.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-D5D1FD
-category: "[[10_Wiki/💡 Topics/Graphics & Performance]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Epidemiological Forecasting"
----
-
-# [[Epidemiological Forecasting]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Graphics & Performance 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Epidemiological Forecasting.md]]
----
diff --git a/Graphics & Performance/Epidemiological Modeling.md b/Graphics & Performance/Epidemiological Modeling.md
deleted file mode 100644
index 8bde0fad..00000000
--- a/Graphics & Performance/Epidemiological Modeling.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-5B9D2F
-category: "[[10_Wiki/💡 Topics/Graphics & Performance]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Epidemiological Modeling"
----
-
-# [[Epidemiological Modeling]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Graphics & Performance 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Epidemiological Modeling.md]]
----
diff --git a/Graphics & Performance/Expressjs-Type-Extensions.md b/Graphics & Performance/Expressjs-Type-Extensions.md
deleted file mode 100644
index be49591a..00000000
--- a/Graphics & Performance/Expressjs-Type-Extensions.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-1B7084
-category: "[[10_Wiki/💡 Topics/Graphics & Performance]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Expressjs-Type-Extensions"
----
-
-# [[Expressjs-Type-Extensions]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Graphics & Performance 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Express.js-Type-Extensions.md]]
----
diff --git a/Graphics & Performance/FXAA.md b/Graphics & Performance/FXAA.md
deleted file mode 100644
index 304455ff..00000000
--- a/Graphics & Performance/FXAA.md	
+++ /dev/null
@@ -1,30 +0,0 @@
----
-id: P-REINFORCE-AUTO-332A17
-category: "[[10_Wiki/💡 Topics/Graphics & Performance]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - FXAA"
----
-
-# [[FXAA]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> FXAA는 실시간 3D 렌더링 환경에서 사용되는 포스트 프로세싱(Post-processing) 안티앨리어싱(Anti-aliasing) 기법입니다. 화면 공간(Screen-space) 셰이더로 실행되어 오브젝트의 가장자리를 부드럽게 만들어 줍니다 [1]. 특히 모바일이나 저사양 기기에서 네이티브 안티앨리어싱을 대체하여 높은 렌더링 프레임 속도를 유지할 수 있도록 하는 매우 성능 효율적인 최적화 기술입니다 [1, 2].
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Graphics & Performance 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[Anti-aliasing]], [[SMAA]], [[MSAA]], [[Post-Processing]]
-- **Projects/Contexts:** [[Three.js]], [[WebGL]]
-- **Contradictions/Notes:** 소스 간의 모순점은 없으며, 모든 소스가 공통적으로 무거운 네이티브 안티앨리어싱을 비활성화하고 FXAA를 포스트 프로세싱 후반부에 적용하는 것이 성능 확보에 필수적이라고 일관되게 권장합니다 [1-3].
-
----
-*Last updated: 2026-04-19*
-- Raw Source: [[00_Raw/2026-04-20/FXAA.md]]
----
diff --git a/Graphics & Performance/Fill Rate.md b/Graphics & Performance/Fill Rate.md
deleted file mode 100644
index 1dac5711..00000000
--- a/Graphics & Performance/Fill Rate.md	
+++ /dev/null
@@ -1,32 +0,0 @@
----
-id: P-REINFORCE-AUTO-477640
-category: "[[10_Wiki/💡 Topics/Graphics & Performance]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Fill Rate"
----
-
-# [[Fill Rate]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 'Fill Rate'는 그래픽 처리 장치(GPU)의 픽셀 처리 속도 및 성능을 나타내는 지표입니다 [1, 2]. 주로 복잡한 프래그먼트 셰이더(Fragment Shader) 연산이나 겹쳐진 투명한 객체들로 인해 발생하는 오버드로우(Overdraw)에 의해 직접적인 영향을 받으며, 효과적인 렌더링 최적화를 위해서는 CPU의 드로우 콜 병목과 구분하여 관리되어야 합니다 [1-3].
-
-## 📖 구조화된 지식 (Synthesized Content)
-- **셰이더 복잡도에 따른 성능 저하**: 다수의 텍스처 룩업(Texture lookups), 수학적 연산 및 조건부 논리가 포함된 복잡한 프래그먼트 셰이더는 중급 사양의 GPU 환경에서 Fill Rate를 50~70%가량 크게 감소시킬 수 있습니다 [1].
-- **오버드로우(Overdraw)와 Fill Rate의 비례적 감소**: 투명한 기하학적 구조(예: 투명한 머리카락, 옷 레이어, 액세서리 등)가 겹칠 경우 동일한 픽셀이 한 프레임 내에서 5~10회 반복해서 렌더링되며, 이는 유효 Fill Rate를 그에 비례하여 크게 떨어뜨립니다 [3].
-- **성능 프로파일링에서의 역할**: 실시간 렌더링 최적화 전략을 세울 때는 씬의 병목 현상이 CPU의 명령 발행(Draw Call)에 있는지, 아니면 GPU의 픽셀 처리(Fill Rate/Overdraw) 한계에 있는지를 명확하게 구분해야 합니다 [2].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Graphics & Performance 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[Overdraw]], [[Fragment Shaders]], [[GPU]]
-- **Projects/Contexts:** [[Image-To-3D Models in Three.js]]
-- **Contradictions/Notes:** 소스 내에서 Fill Rate와 관련된 상충되는 주장이나 모순은 발견되지 않았습니다.
-
----
-*Last updated: 2026-04-19*
-- Raw Source: [[00_Raw/2026-04-20/Fill Rate.md]]
----
diff --git a/Graphics & Performance/Flow State Theory.md b/Graphics & Performance/Flow State Theory.md
deleted file mode 100644
index 25b525a4..00000000
--- a/Graphics & Performance/Flow State Theory.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-546D8F
-category: "[[10_Wiki/💡 Topics/Graphics & Performance]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Flow State Theory"
----
-
-# [[Flow State Theory]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Graphics & Performance 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Flow State Theory.md]]
----
diff --git a/Graphics & Performance/Formal-Grammar.md b/Graphics & Performance/Formal-Grammar.md
deleted file mode 100644
index 4fa3cbbd..00000000
--- a/Graphics & Performance/Formal-Grammar.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-410500
-category: "[[10_Wiki/💡 Topics/Graphics & Performance]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Formal-Grammar"
----
-
-# [[Formal-Grammar]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Graphics & Performance 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Formal-Grammar.md]]
----
diff --git a/Graphics & Performance/Formalism-vs-Structuralism.md b/Graphics & Performance/Formalism-vs-Structuralism.md
deleted file mode 100644
index cb550c0a..00000000
--- a/Graphics & Performance/Formalism-vs-Structuralism.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-AE318B
-category: "[[10_Wiki/💡 Topics/Graphics & Performance]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Formalism-vs-Structuralism"
----
-
-# [[Formalism-vs-Structuralism]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Graphics & Performance 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Formalism-vs-Structuralism.md]]
----
diff --git a/Graphics & Performance/Formalist Game Design.md b/Graphics & Performance/Formalist Game Design.md
deleted file mode 100644
index 6442e3e0..00000000
--- a/Graphics & Performance/Formalist Game Design.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-E0F58C
-category: "[[10_Wiki/💡 Topics/Graphics & Performance]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Formalist Game Design"
----
-
-# [[Formalist Game Design]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Graphics & Performance 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Formalist Game Design.md]]
----
diff --git a/Graphics & Performance/Fragment Shading.md b/Graphics & Performance/Fragment Shading.md
deleted file mode 100644
index 61a98271..00000000
--- a/Graphics & Performance/Fragment Shading.md	
+++ /dev/null
@@ -1,33 +0,0 @@
----
-id: P-REINFORCE-AUTO-809D81
-category: "[[10_Wiki/💡 Topics/Graphics & Performance]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Fragment Shading"
----
-
-# [[Fragment Shading]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 프래그먼트 셰이딩(Fragment Shading)은 렌더링 파이프라인 후반부에서 픽셀 단위의 렌더링 계산(퍼 픽셀 조명 연산 등)을 수행하여 최종 색상 값을 결정하는 프로세스이다 [1, 2]. 다수의 텍스처 룩업이나 복잡한 연산이 포함될 경우 필 레이트(Fill Rate)를 크게 저하시킬 수 있으며 [2], 동일 픽셀에 여러 번 렌더링 연산이 중첩되는 오버드로우(Overdraw) 현상이 발생할 경우 GPU 성능 병목의 주요 원인이 되기도 한다 [3].
-
-## 📖 구조화된 지식 (Synthesized Content)
-- **픽셀 단위 연산의 수행:** 프래그먼트 셰이더는 픽셀의 최종 색상 값을 결정하는 픽셀 단위의 계산을 전담한다 [2]. 버텍스 셰이더(Vertex Shader)와 프래그먼트 셰이더 사이에서는 varying 변수를 통해 데이터가 전달되며 [4], 구워진 노멀 맵(baked normal maps) 등을 활용해 복잡한 표면 디테일을 픽셀 셰이딩(pixel shading) 방식으로 렌더링한다 [1].
-- **셰이더 복잡도와 필 레이트(Fill Rate):** 프래그먼트 셰이더 내에서 여러 텍스처를 조회하거나, 수학적 연산 및 조건 논리가 복잡해질 경우 중간 사양의 GPU에서는 필 레이트가 50-70%가량 감소할 수 있다 [2]. 특히 PBR(물리 기반 렌더링) 환경에서는 각 픽셀마다 다수의 텍스처 샘플링(알베도, 노멀, 메탈릭, 러프니스 등) 및 환경 반사 연산을 처리해야 하므로 프래그먼트 처리 시간이 급증하게 된다 [2].
-- **오버드로우(Overdraw)의 영향:** 프래그먼트 셰이딩 단계에서 나타나는 오버드로우는 투명한 기하학적 구조가 겹치거나 깊이 정렬(Depth sorting)이 효율적이지 않아 동일한 픽셀 위치에 렌더링 쓰기 작업이 여러 번 중첩되는 현상이다 [3, 5]. 이는 화면에 보이지 않는 픽셀의 연산에까지 GPU 자원을 낭비하게 만든다 [5].
-- **정렬 부재와 프래그먼트 바운드(Fragment-bound) 현상:** 불투명 객체를 렌더링할 때 객체를 '앞에서 뒤로(Front-to-Back)' 정렬하면 가려진 픽셀 연산을 일찍 종료하는 Early-Z 최적화를 통해 성능을 확보할 수 있다 [3]. 하지만 InstancedMesh처럼 인스턴스들이 정렬되지 않은 상태로 렌더링되는 경우 이 최적화가 불가능해 막대한 오버드로우 비용을 발생시키며, 결과적으로 전체 씬(Scene)의 렌더링이 프래그먼트 연산의 한계에 부딪히는 프래그먼트 바운드 상태에 빠질 수 있다 [3, 6].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Graphics & Performance 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[Overdraw]], [[Vertex Shader]], [[Fill Rate]], [[PBR]]
-- **Projects/Contexts:** [[Three.js WebGL Rendering Optimization]], [[InstancedMesh Performance Bottlenecks]]
-- **Contradictions/Notes:** 소스에 관련 정보가 부족합니다.
-
----
-*Last updated: 2026-04-19*
-- Raw Source: [[00_Raw/2026-04-20/Fragment Shading.md]]
----
diff --git a/Graphics & Performance/Fragment-bound.md b/Graphics & Performance/Fragment-bound.md
deleted file mode 100644
index 3f2f612a..00000000
--- a/Graphics & Performance/Fragment-bound.md	
+++ /dev/null
@@ -1,35 +0,0 @@
----
-id: P-REINFORCE-AUTO-589695
-category: "[[10_Wiki/💡 Topics/Graphics & Performance]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Fragment-bound"
----
-
-# [[Fragment-bound]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 'Fragment-bound(프래그먼트 바운드)'는 3D 그래픽스 렌더링 파이프라인에서 GPU의 프래그먼트 셰이딩(픽셀 처리) 용량이 한계에 도달하여 전체 시스템의 성능 병목이 되는 상태를 의미합니다 [1, 2]. 이 상태는 주로 객체들이 카메라 기준 깊이(Depth)에 따라 정렬되지 않은 채 렌더링될 때, 동일한 픽셀에 여러 번 그리기 연산이 수행되는 '오버드로우(Overdraw)' 현상으로 인해 촉발됩니다 [1, 2]. 특히 연산 비용이 높은 재질을 사용할 때 이 병목 현상은 더욱 극심해집니다 [2, 3].
-
-## 📖 구조화된 지식 (Synthesized Content)
-- **오버드로우(Overdraw)에 의한 연산 과부하:** 
-  프래그먼트 바운드 상태는 화면의 동일한 픽셀 영역에 대해 셰이더 연산과 쓰기 작업이 여러 번 중첩되어 발생하는 오버드로우에 의해 야기됩니다 [1, 2]. GPU가 최종 화면에 보이지 않고 가려질 픽셀까지 모두 계산하게 되면서 픽셀 처리 성능을 상회하는 부하가 발생합니다 [2].
-- **InstancedMesh의 정렬 부재와 병목:** 
-  Three.js의 `InstancedMesh`는 단일 드로우 콜로 렌더링을 수행하지만 개별 인스턴스들의 렌더링 순서를 자동으로 정렬(Sorting)하지 않습니다 [1, 2]. 만약 카메라와 가장 멀리 있는 인스턴스가 먼저 그려지고 가까운 인스턴스가 나중에 그려진다면 막대한 오버드로우 비용이 발생하게 되며, 이로 인해 씬(Scene)이 프래그먼트 바운드 상태에 빠지게 됩니다 [2].
-- **재질(Material) 복잡도의 영향과 해결책:** 
-  복잡한 조명 및 그림자 연산이 포함된 `MeshStandardMaterial`과 같은 셰이더를 사용할 경우 프래그먼트 바운드 현상은 훨씬 더 심화됩니다 [2, 3]. 이 문제를 완화하기 위해서는 오버드로우의 비용 자체를 줄일 수 있는 단순한 `MeshBasicMaterial`을 사용하여 비교하거나 [3], 자동으로 인스턴스 정렬을 지원하는 `BatchedMesh`로 전환하여 렌더링 효율을 높이는 것이 대안으로 제시됩니다 [1].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Graphics & Performance 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[Overdraw]], [[InstancedMesh]], [[MeshStandardMaterial]], [[BatchedMesh]]
-- **Projects/Contexts:** [[Three.js 렌더링 성능 최적화]]
-- **Contradictions/Notes:** 드로우 콜을 줄여 성능을 향상시키기 위해 고안된 `InstancedMesh`가, 정렬 기능의 부재로 인해 오히려 심각한 오버드로우와 프래그먼트 바운드를 유발하여 일반 `Mesh`를 여러 번 그릴 때보다 프레임 레이트(FPS)를 더 하락시킬 수 있다는 점이 주의사항으로 보고됩니다 [2, 4].
-
----
-*Last updated: 2026-04-19*
-- Raw Source: [[00_Raw/2026-04-20/Fragment-bound.md]]
----
diff --git a/Graphics & Performance/Frustum Culling.md b/Graphics & Performance/Frustum Culling.md
deleted file mode 100644
index ed6bbc4d..00000000
--- a/Graphics & Performance/Frustum Culling.md	
+++ /dev/null
@@ -1,39 +0,0 @@
----
-id: P-REINFORCE-AUTO-7A315B
-category: "[[10_Wiki/💡 Topics/Graphics & Performance]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Frustum Culling"
----
-
-# [[Frustum Culling]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 시야 절두체 컬링(Frustum Culling)은 카메라의 시야(View Frustum) 밖으로 벗어난 객체를 렌더링 연산에서 제외하여 불필요한 GPU 자원 소모를 방지하는 최적화 기법이다 [1]. 하지만 InstancedMesh를 적용할 경우 엔진 수준에서 전체를 단일 객체로 취급하므로, 모든 인스턴스를 포함하는 거대한 바운딩 볼륨을 기준으로 한 번만 컬링이 수행되는 '전부 아니면 전무(All-or-Nothing)' 방식으로 작동한다 [2]. 이로 인해 화면에 극히 일부의 인스턴스만 노출되더라도 보이지 않는 나머지 모든 인스턴스의 정점 변환 연산을 GPU가 강제로 수행해야 하는 구조적 한계를 야기한다 [2].
-
-## 📖 구조화된 지식 (Synthesized Content)
-- **InstancedMesh에서의 구조적 비효율성**
-  Three.js는 기본적으로 카메라 시야 밖의 객체를 자동으로 컬링해 드로우 콜 생성을 방지한다 [3]. 그러나 InstancedMesh를 사용하면 개별 인스턴스 단위의 네이티브 시야 절두체 컬링 기능이 상실된다 [4]. 엔진은 전체 인스턴스의 바운딩 볼륨만을 검사하기 때문에, 10,000개의 객체 중 단 1개만 시야에 들어와도 GPU는 9,999개의 보이지 않는 객체에 대한 정점 셰이더(Vertex Shader) 행렬 곱셈 연산을 처리해야 한다 [2]. 이는 특히 저사양 모바일 기기나 통합 GPU 환경에서 치명적인 GPU 점유율 상승 및 프레임 드랍을 유발한다 [2, 5].
-
-- **수동 CPU 컬링의 병목 현상**
-  GPU 낭비를 막기 위해 자바스크립트(CPU) 수준에서 각 인스턴스의 위치를 카메라 평면과 대조하여 가시성을 판단하고 렌더링할 버퍼를 매 프레임 재구성(Reordering)할 수 있다 [5, 6]. 하지만 단일 스레드 특성을 갖는 자바스크립트에서 대규모 배열을 매번 순회하고 조작하는 것은 치명적인 CPU 메인 스레드 병목과 가비지 컬렉션(GC) 부하를 일으킨다 [5].
-
-- **한계 극복을 위한 대안 전략**
-  1. **공간 분할 기반 그룹화 전략**: 수만 개의 인스턴스를 하나의 거대한 InstancedMesh로 묶는 대신, 공간적으로 인접한 객체들을 100~500개 단위의 소규모 InstancedMesh로 분할 관리하는 방법이다. 이 경우 드로우 콜 횟수는 다소 증가하지만 시야 절두체 컬링 정밀도가 크게 향상되어 GPU의 무의미한 정점 연산을 극적으로 줄일 수 있다 [7].
-  2. **GPU 컴퓨트 컬링 및 간접 그리기(Indirect Draw)**: WebGPU 환경의 컴퓨트 셰이더(Compute Shader)를 활용해 GPU가 직접 인스턴스의 가시성을 판별하도록 처리하는 방식이다 [8, 9]. 판별 결과는 GPU 내부 버퍼에 저장되어 `drawIndirect` 명령으로 즉각 렌더링되므로, CPU 연산 및 CPU-GPU 간 데이터 전송 병목을 완벽히 회피할 수 있다 [9].
-  3. **확장 라이브러리 도입**: BVH(Bounding Volume Hierarchy)를 이용한 고속 공간 쿼리와 `InstancedBufferAttribute`를 활용한 간접 참조(Indirection) 방식을 통해 기존 InstancedMesh를 확장하여 효율적인 개별 컬링을 제공하는 `InstancedMesh2`와 같은 외부 라이브러리 활용이 대안이 될 수 있다 [10-12].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Graphics & Performance 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[InstancedMesh]], [[Draw Call]], [[WebGPU]], [[Bounding Volume Hierarchy (BVH)]]
-- **Projects/Contexts:** [[Three.js]], [[InstancedMesh2]]
-- **Contradictions/Notes:** InstancedMesh 기술은 드로우 콜 감소를 통해 CPU 병목을 획기적으로 해결할 수 있도록 설계되었으나, 동시에 개별 시야 절두체 컬링을 무력화시킴으로써 결과적으로 GPU 측면에 새로운 정점 연산 병목을 유발하는 모순적인 절충(Trade-off)을 요구한다 [5, 13].
-
----
-*Last updated: 2026-04-19*
-- Raw Source: [[00_Raw/2026-04-20/Frustum Culling.md]]
----
diff --git a/Graphics & Performance/GPU Resources.md b/Graphics & Performance/GPU Resources.md
deleted file mode 100644
index 9098529f..00000000
--- a/Graphics & Performance/GPU Resources.md	
+++ /dev/null
@@ -1,33 +0,0 @@
----
-id: P-REINFORCE-AUTO-4AA291
-category: "[[10_Wiki/💡 Topics/Graphics & Performance]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - GPU Resources"
----
-
-# [[GPU Resources]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> GPU 리소스는 Three.js 및 WebGL 환경에서 렌더링을 위해 할당되는 VRAM 자원으로, 기하학적 구조(Geometries), 재질(Materials), 텍스처(Textures), 렌더 타겟(Render targets) 등을 포함합니다 [1-3]. 브라우저 렌더링 엔진은 이러한 리소스들을 자동으로 가비지 컬렉트(Garbage Collect)하지 않기 때문에 사용이 끝나면 개발자가 직접 명시적으로 메모리에서 해제해야 합니다 [1]. 효율적인 GPU 리소스 관리가 이루어지지 않으면 심각한 메모리 누수(Memory Leaks)가 발생하며, 궁극적으로 브라우저의 제한된 GPU 메모리를 초과하여 컨텍스트 손실(Context Lost)과 화면 멈춤 현상을 유발합니다 [3, 4].
-
-## 📖 구조화된 지식 (Synthesized Content)
-- **GPU 리소스의 구성 및 메모리 소비량:** 3D 모델을 렌더링할 때 GPU 메모리에는 정점 버퍼(Vertex buffers), 인덱스 버퍼(Index buffers), 텍스처 맵, 그리고 셰이더 프로그램 등이 할당됩니다 [3]. 고해상도 텍스처는 막대한 메모리를 차지하여, 단일 4K(4096x4096) 압축 해제 텍스처의 경우 VRAM의 64MB 이상을 단독으로 소비할 수 있습니다 [1, 5]. 추가적으로 후처리(Post-processing) 단계에서 사용되는 개별 렌더 타겟들 또한 프레임 버퍼 메모리를 추가 할당합니다 [2].
-- **명시적인 자원 해제(Disposal) 필수성:** Three.js 프레임워크는 GPU 리소스를 추적하여 자동으로 메모리에서 지워주지 않습니다 [1]. 따라서 메모리 누수를 방지하기 위해서는 에셋이 더 이상 필요하지 않을 때 반드시 `geometry.dispose()`, `material.dispose()`, `texture.dispose()` 함수를 호출해 GPU 자원을 명시적으로 해제해야 합니다 [1, 4, 6]. 
-- **특수 텍스처 및 빈번한 생성 객체 관리:** GLTF 모델 파일에서 `ImageBitmap` 형태로 로드된 텍스처 리소스의 경우, 기본 폐기 메서드 외에도 명시적으로 `texture.source.data.close?()`를 호출해 닫아주어야만 메모리가 새는 것을 막을 수 있습니다 [4, 7]. 또한 게임 내 탄환이나 파티클처럼 자주 생성되고 파괴되는 리소스의 경우 매번 새로 할당하지 않고 오브젝트 풀링(Object Pooling) 방식을 사용하여 메모리 할당 오버헤드를 막는 것이 좋습니다 [4, 7].
-- **리소스 한계 모니터링:** WebGL 컨텍스트의 가용 메모리 한도는 디바이스 환경에 따라 약 256MB에서 1GB 수준으로 제한적입니다 [3]. 이 용량을 초과해 GPU 리소스가 할당되면 컨텍스트 손실이 발생하여 애플리케이션이 충돌하게 됩니다 [3]. 이를 방지하기 위해서는 런타임 중에 `renderer.info.memory` 상태를 꾸준히 모니터링하여 텍스처나 지오메트리 수가 지속적으로 증가하는 메모리 누수 현상이 없는지 확인해야 합니다 [1, 4].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Graphics & Performance 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[Memory Management]], [[Memory Leaks]], [[Textures]], [[VRAM]], [[Garbage Collection]]
-- **Projects/Contexts:** [[Three.js]], [[WebGL]], [[WebGPU]]
-- **Contradictions/Notes:** 소스에 관련 모순이나 충돌 정보는 없습니다.
-
----
-*Last updated: 2026-04-19*
-- Raw Source: [[00_Raw/2026-04-20/GPU Resources.md]]
----
diff --git a/Graphics & Performance/GPU for the Web Community Group.md b/Graphics & Performance/GPU for the Web Community Group.md
deleted file mode 100644
index 8bdc6bcc..00000000
--- a/Graphics & Performance/GPU for the Web Community Group.md	
+++ /dev/null
@@ -1,35 +0,0 @@
----
-id: P-REINFORCE-AUTO-518388
-category: "[[10_Wiki/💡 Topics/Graphics & Performance]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - GPU for the Web Community Group"
----
-
-# [[GPU for the Web Community Group]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> GPU for the Web Community Group은 Chrome, Firefox, Safari 등 주요 웹 브라우저의 대표자들로 구성되어 WebGPU와 같은 웹 그래픽 및 컴퓨팅 API의 표준과 새로운 기능을 논의하고 승인하는 조직입니다. 이들은 웹 플랫폼의 건전성과 상호 운용성을 위해 구현에 따라 달라지는(implementation-defined) 기능을 피하고, 결정론적이며 테스트 가능한 기능을 표준에 포함시키는 것을 원칙으로 합니다. 최근에는 개발자 도구 및 성능 측정을 위한 WebGPU 타임스탬프 쿼리(timestamp queries) 기능의 도입과 보안을 위한 양자화(quantization) 기준을 합의하는 역할을 수행했습니다.
-
-## 📖 구조화된 지식 (Synthesized Content)
-* **구성원 및 주요 역할:** 이 그룹에는 Chrome, Firefox, Safari 등 주요 브라우저 벤더의 대표자들이 참여하고 있으며, WebGPU 명세에 새로운 기능을 도입할 때 상호 운용성(interoperability)을 확보하기 위한 합의(consensus)를 도출합니다 [1].
-* **표준화 원칙:** 그룹(WebGPU standard body)은 기본적으로 구현이 명확하지 않거나 선택적인(optional) 기능을 피하고, 상호 운용이 가능하며 테스트 스위트(test suite)로 뒷받침되는 결정론적인 기능을 갖추는 것을 목표로 합니다 [2-4].
-* **타임스탬프 쿼리(Timestamp Queries) 승인 사례:**
-  * WebGPU 애플리케이션의 GPU 명령 실행 시간을 정밀하게 측정하기 위한 타임스탬프 쿼리 기능이 타이밍 공격(timing attack)에 악용될 수 있다는 보안 우려가 있었습니다 [5, 6].
-  * 그룹 내 논의를 통해, 사이트 격리(site isolation) 여부와 상관없이 hr-time(High Resolution Time)의 비격리 해상도인 100마이크로초(100us) 수준으로 양자화(coarsen)하여 타임스탬프를 허용하는 제안을 수용 및 승인했습니다 [7].
-  * 이를 통해 브라우저 간의 상호 운용성 문제를 해결하고 플랫폼 표준에 맞춘 성능 측정 기능을 제공할 수 있게 되었습니다 [8, 9].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Graphics & Performance 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[WebGPU]], [[Timestamp Queries]]
-- **Projects/Contexts:** [[WebGPU API Standardization]], [[Chrome Intent to Ship]]
-- **Contradictions/Notes:** 그룹은 일반적으로 구현에 따라 달라지거나 결정론적이지 않은 기능을 표준에서 배제하려고 노력하지만, 타임스탬프 쿼리와 같은 기능의 경우 예외적으로 보안(타이밍 공격 방지)과 성능 측정의 필요성 사이에서 양자화라는 타협점을 찾아야만 했습니다 [4].
-
----
-*Last updated: 2026-04-19*
-- Raw Source: [[00_Raw/2026-04-20/GPU for the Web Community Group.md]]
----
diff --git a/Graphics & Performance/GPU-driven Rendering.md b/Graphics & Performance/GPU-driven Rendering.md
deleted file mode 100644
index ce1b38a1..00000000
--- a/Graphics & Performance/GPU-driven Rendering.md	
+++ /dev/null
@@ -1,32 +0,0 @@
----
-id: P-REINFORCE-AUTO-C35A51
-category: "[[10_Wiki/💡 Topics/Graphics & Performance]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - GPU-driven Rendering"
----
-
-# [[GPU-driven Rendering]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> GPU-driven Rendering(GPU 주도 렌더링)은 CPU가 렌더링할 객체를 판별하고 명령하는 대신, GPU가 무엇을 렌더링할지 스스로 결정하는 현대적인 렌더링 파이프라인 기법입니다 [1, 2]. 주로 컴퓨트 셰이더(Compute Shader)를 활용해 객체의 가시성을 GPU 내부에서 직접 평가한 후, 간접 그리기(Indirect Draw) 명령을 통해 화면에 출력합니다 [1, 3]. 이 방식을 사용하면 CPU와 GPU 간의 데이터 전송 및 통신 병목이 제거되어 수백만 개의 인스턴스를 극도로 효율적으로 처리할 수 있습니다 [1, 3].
-
-## 📖 구조화된 지식 (Synthesized Content)
-- **가시성 판단의 GPU 이관 (Culling in Compute Shaders):** 기존의 렌더링 파이프라인에서는 CPU가 시야 절두체 컬링(Frustum Culling)이나 가림 현상(Occlusion)을 계산하여 병목이 발생했습니다 [2, 3]. GPU-driven Rendering에서는 이 역할을 GPU의 컴퓨트 셰이더로 넘겨, GPU가 직접 모든 객체와 인스턴스의 가시성을 판별하고 화면에 보일 객체의 렌더링 명령만 생성합니다 [2, 3].
-- **간접 그리기 (Indirect Draws) 활용:** 컴퓨트 셰이더가 가시성 평가를 마치면, 그 결과와 렌더링 명령을 GPU 내부 버퍼에 직접 기록합니다 [2, 3]. 이후 CPU의 개입 없이 `drawIndirect` 명령을 통해 GPU 내부 버퍼의 내용을 기반으로 렌더링을 수행하므로, CPU와 GPU 사이의 데이터 전송량이 거의 '0'에 수렴하게 됩니다 [1, 3].
-- **대규모 인스턴스 및 복잡한 연산 처리:** 이 기법은 매 프레임마다 GPU 수준의 컬링이 필요한 수백만 개의 인스턴스 렌더링에 필수적인 아키텍처입니다 [1]. 또한 읽기와 쓰기가 모두 허용되는 스토리지 텍스처(Storage Textures) 기술과 결합되어 유체 시뮬레이션, 이미지 처리 등 복잡한 환경에서도 핵심적인 역할을 수행합니다 [4].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Graphics & Performance 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[Compute Shader]], [[Indirect Draw]], [[Frustum Culling]], [[WebGPU]]
-- **Projects/Contexts:** [[Three.js]], [[InstancedMesh]]
-- **Contradictions/Notes:** 대규모 객체를 렌더링할 때 'CPU 개별 컬링' 방식은 자바스크립트 연산 및 시스템 버스 전송에 막대한 병목을 유발하지만, 'GPU 주도 렌더링(GPU 컴퓨트 컬링)'은 구현 난이도가 매우 높은 대신 CPU 부하를 극도로 낮추고 전체적인 성능을 극대화한다는 뚜렷한 대비를 보입니다 [3, 5].
-
----
-*Last updated: 2026-04-19*
-- Raw Source: [[00_Raw/2026-04-20/GPU-driven Rendering.md]]
----
diff --git a/Graphics & Performance/GPURenderBundles.md b/Graphics & Performance/GPURenderBundles.md
deleted file mode 100644
index 8be47836..00000000
--- a/Graphics & Performance/GPURenderBundles.md	
+++ /dev/null
@@ -1,32 +0,0 @@
----
-id: P-REINFORCE-AUTO-BC7FBB
-category: "[[10_Wiki/💡 Topics/Graphics & Performance]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - GPURenderBundles"
----
-
-# [[GPURenderBundles]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> `GPURenderBundles` (렌더 번들)는 Native WebGPU 환경에서 제공되는 강력한 렌더링 최적화 도구입니다 [1]. 초기화 과정에서 파이프라인, 바인드 그룹(bind groups), 드로우 콜(draw calls)과 같은 명령을 미리 기록(pre-record)하고, 이후 렌더 루프에서 단 한 번의 호출로 이를 다시 재생(replay)할 수 있게 해줍니다 [1]. 이 방식을 통해 렌더링 성능에 병목을 일으키는 검증 작업(validation work)을 핵심 렌더링 경로 외부로 분리하여 대규모 객체를 극도로 효율적으로 처리할 수 있습니다 [1, 2].
-
-## 📖 구조화된 지식 (Synthesized Content)
-- **사전 기록을 통한 성능 극대화:** 렌더 루프 내에서 매 프레임마다 렌더링 명령을 GPU에 지시하는 대신, 초기화 단계에서 모든 명령을 `GPURenderBundles`에 묶어 저장합니다 [1, 2]. 렌더 루프에서는 이 번들을 호출하는 것만으로 복잡한 렌더링 명령을 즉시 실행할 수 있습니다 [1].
-- **드로우 콜 오버헤드 감소:** 이 접근법은 명령 검증(validation) 작업을 렌더 루프에서 제외시켜 CPU에서 GPU로 발생하는 오버헤드를 근본적으로 제거합니다 [2]. 간접 그리기(Indirect Drawing)와 함께 사용할 경우 매우 높은 드로우 콜 효율성(Draw Call Efficiency)을 달성할 수 있습니다 [3]. 
-- **초대형 데이터셋 처리:** `GPURenderBundles`를 활용하면 한 번의 호출로 100,000개 이상의 객체를 렌더링할 수 있습니다 [1, 2]. 이는 500MB를 초과하는 병원 캠퍼스나 공항 터미널과 같은 방대하고 복잡한 건설 모델을 실시간으로 렌더링하는 데 가장 이상적인 해결책을 제공합니다 [2].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Graphics & Performance 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[Native WebGPU]], [[Indirect Drawing]], [[Draw Call Efficiency]], [[Bind Groups]]
-- **Projects/Contexts:** [[대규모 건설 플랫폼 뷰어(Large-Scale Construction Viewers)]]
-- **Contradictions/Notes:** 고수준 프레임워크인 Three.js WebGPU는 개발이 쉽지만 고유 객체 처리 시 UBO(Uniform Buffer Objects) 바인딩 오버헤드로 인해 약 1만~2만 개의 비인스턴스 객체 렌더링 시 프레임이 떨어질 수 있습니다. 반면, Native WebGPU는 초기화 및 파이프라인 구성의 복잡성(개발 속도 저하)을 감수하는 대신 `GPURenderBundles`를 통해 10만 개 이상의 고유 객체를 병목 없이 원활하게 처리할 수 있습니다 [2-4].
-
----
-*Last updated: 2026-04-19*
-- Raw Source: [[00_Raw/2026-04-20/GPURenderBundles.md]]
----
diff --git a/Graphics & Performance/GPU_WebGL 파이프라인의 미세 지연(Micro-latency) 측정 사례.md b/Graphics & Performance/GPU_WebGL 파이프라인의 미세 지연(Micro-latency) 측정 사례.md
deleted file mode 100644
index 5216f924..00000000
--- a/Graphics & Performance/GPU_WebGL 파이프라인의 미세 지연(Micro-latency) 측정 사례.md	
+++ /dev/null
@@ -1,48 +0,0 @@
----
-id: P-REINFORCE-AUTO-035B08
-category: "[[10_Wiki/💡 Topics/Graphics & Performance]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - GPU_WebGL 파이프라인의 미세 지연(Micro-latency) 측정 사례"
----
-
-# [[GPU_WebGL 파이프라인의 미세 지연(Micro-latency) 측정 사례]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> GPU/WebGL 파이프라인의 미세 지연(Micro-latency)은 CPU, GPU 및 브라우저 추상화 계층 간의 상호작용에서 발생하는 서브 프레임(Sub-frame) 수준의 시간 지연을 의미하며, 사용자 몰입도를 저하시키는 주요 원인입니다 [1]. 이를 정확히 측정하기 위해 WebGL/WebGPU의 타이머 API, 브라우저 내부의 성능 프로파일링 도구, 그리고 고속 카메라와 오실로스코프를 활용한 하드웨어 기반 측정 등 다양한 접근법이 활용되고 있습니다 [2-6]. 그러나 보안 취약점(Spectre, Meltdown 등)으로 인해 정밀한 시간 측정 기능이 브라우저 차원에서 양자화(Quantization)되거나 제한되는 등 여러 측정 상의 제약이 따르고 있습니다 [3, 7].
-
-## 📖 구조화된 지식 (Synthesized Content)
-*   **API 수준의 그래픽 타이머 측정 (API-Level Timing)**
-    *   **WebGL 타이머 쿼리:** `EXT_disjoint_timer_query` 확장은 렌더링 파이프라인을 중단하지 않고 GPU 명령어 세트의 실행 시간을 측정할 수 있도록 고안되었습니다 [2, 8]. 그러나 이 고정밀 타이머가 Spectre 및 Meltdown과 같은 캐시 부채널 공격(Side-channel attacks)에 악용될 수 있다는 보안 연구 결과에 따라, 대부분의 브라우저 벤더는 해당 확장을 비활성화하거나 해상도를 엄격하게 양자화(Quantization)하였습니다 [2, 3, 9-11].
-    *   **WebGPU 타임스탬프 쿼리:** WebGPU는 `timestamp-query` 기능을 통해 나노초 단위의 정밀한 측정을 지원하도록 설계되었습니다 [3, 12]. 하지만 역시 타이밍 공격을 방지하기 위해 사이트 격리(Site isolation) 여부에 따라 타임스탬프의 해상도가 100 마이크로초 수준으로 양자화되거나 비격리 컨텍스트에서는 아예 노출되지 않는 보안 조치가 적용됩니다 [3, 7, 13, 14]. 개발자는 로컬 환경에서 브라우저 플래그(`enable-webgpu-developer-features`)를 켜서 이러한 제한을 우회할 수 있습니다 [7, 15].
-
-*   **브라우저 내부 프로파일링 도구 (Browser-Internal Profiling)**
-    *   **Chrome DevTools (Performance 패널):** 애플리케이션의 런타임 트레이스를 캡처하여 메인 스레드 차단 및 프레임 드롭을 진단할 수 있습니다 [16]. CPU 스로틀링(Throttling) 기능을 통해 고사양 기기에서 모바일 기기의 성능을 시뮬레이션함으로써, 강력한 하드웨어 성능에 가려져 있던 미세 지연을 드러낼 수 있습니다 [4, 16].
-    *   **Chrome Tracing (`about:tracing`):** 브라우저의 다중 프로세스 아키텍처를 세밀하게 분석할 수 있습니다. "CrGpuMain"과 "CrRendererMain" 스레드의 활성 상태를 비교하여 시스템이 CPU 바운드인지 GPU 바운드인지 판별하며, 긴 가비지 컬렉션 주기나 네트워크 대기 등으로 인해 발생하는 유휴 시간(Idle-time) 미세 지연을 파악하는 데 필수적입니다 [4, 17-19].
-
-*   **하드웨어 지원 측정 방식 (Hardware-Assisted Latency Measurement)**
-    *   소프트웨어 기반의 측정은 디스플레이 컨트롤러나 물리적 모니터 자체에서 발생하는 지연을 포착할 수 없으므로, 매우 정밀한 연구를 위해서는 하드웨어 보조 기법이 요구됩니다 [5].
-    *   **고속 카메라 기법:** 1000Hz(밀리초당 1프레임)로 녹화하는 고속 카메라와 LED 입력 트리거를 사용하여, 버튼 클릭부터 디스플레이에 시각적 변화가 나타나기까지의 전체 "입력 대 디스플레이(Input-to-Display)" 지연을 측정합니다 [5]. 
-    *   **오실로스코프와 포토다이오드:** 모니터에 부착한 포토다이오드로 시각적 변화에 따른 빛의 강도 변화를 전압 스파이크로 감지하고, 이를 입력 장치의 전기 신호와 오실로스코프에서 비교하여 밀리초 미만의 정밀도로 종단 간 지연을 측정합니다 [6].
-
-*   **운영 체제 및 드라이버 수준의 미세 지연 오버헤드**
-    *   **컨텍스트 생성 지연 (Context Creation Latency):** WebGL/WebGPU 컨텍스트 생성은 브라우저가 OS 그래픽 스택과 직접 소통해야 하는 동기식 작업으로 드라이버에 따라 심각한 지연을 유발합니다. (예: Mesa 50ms, NVIDIA 120ms, FGLRX 200ms) 이는 페이지 로드 시 메인 스레드의 가시적인 프리징을 야기합니다 [20-22].
-    *   **ANGLE 변환 오버헤드:** Windows 플랫폼에서는 WebGL의 OpenGL ES 호출을 Direct3D로 변환하기 위해 ANGLE 계층을 거치며, 드로우 콜(Draw call)마다 몇 마이크로초의 미세 지연이 부가됩니다. 이 지연은 수천 번의 드로우 콜이 발생하는 씬에서 누적되어 GPU가 여유로운 상황에서도 CPU 병목(Bottleneck) 현상을 일으킵니다 [21, 23, 24].
-
-*   **JavaScript 우회 측정 방법**
-    *   일부 브라우저(예: Chrome)에서는 성능 및 구조상의 이유로 `gl.finish()`가 비정상적으로 `gl.flush()`로 작동하기 때문에 렌더링 지연을 직접 측정할 수 없습니다 [11]. 이를 우회하기 위해 `gl.readPixels()`를 사용하여 단일 픽셀을 강제로 읽어 모든 그래픽 프로세스를 지연시키고 동기화한 뒤, 그 오버헤드를 `performance.now()`로 측정 및 차감하여 실제 작업의 렌더링 시간을 추정하는 기법이 활용되기도 합니다 [25, 26].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Graphics & Performance 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[Spectre and Meltdown]], [[WebGPU Timestamp Queries]], [[EXT_disjoint_timer_query]]
-- **Projects/Contexts:** [[Chrome DevTools Performance Panel]], [[ANGLE (Almost Native Graphics Layer Engine)]]
-- **Contradictions/Notes:** 소스에 따르면 WebGL의 `gl.finish()` 함수는 본래 GPU 파이프라인의 실행 완료를 기다리는 기능이나, Chrome에서는 `gl.flush()`로 별칭(alias) 지정되어 있어, 이를 사용해 실제 렌더링 지연 시간을 측정하려는 시도는 작동하지 않습니다 [11, 27]. 또한 `EXT_disjoint_timer_query` 확장이나 `performance.now()` 등의 도구 역시 각각 보안 문제(캐시 기반 정보 유출) 및 제한적인 렌더링 조건 탓에 순수하고 완벽한 미세 지연 측정 도구로 사용하기에는 한계가 존재합니다 [3, 11, 28].
-
----
-*Last updated: 2026-04-19*
-- Raw Source: [[00_Raw/2026-04-20/GPU_WebGL 파이프라인의 미세 지연(Micro-latency) 측정 사례.md]]
----
diff --git a/Graphics & Performance/Game Studies (Academic Discipline).md b/Graphics & Performance/Game Studies (Academic Discipline).md
deleted file mode 100644
index 071ec4b6..00000000
--- a/Graphics & Performance/Game Studies (Academic Discipline).md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-EFF2C4
-category: "[[10_Wiki/💡 Topics/Graphics & Performance]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Game Studies (Academic Discipline)"
----
-
-# [[Game Studies (Academic Discipline)]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Graphics & Performance 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Game Studies (Academic Discipline).md]]
----
diff --git a/Graphics & Performance/Game Theory (Economics).md b/Graphics & Performance/Game Theory (Economics).md
deleted file mode 100644
index d593f256..00000000
--- a/Graphics & Performance/Game Theory (Economics).md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-329226
-category: "[[10_Wiki/💡 Topics/Graphics & Performance]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Game Theory (Economics)"
----
-
-# [[Game Theory (Economics)]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Graphics & Performance 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Game Theory (Economics).md]]
----
diff --git a/Graphics & Performance/Game Theory and Market Equilibrium.md b/Graphics & Performance/Game Theory and Market Equilibrium.md
deleted file mode 100644
index 5547fccf..00000000
--- a/Graphics & Performance/Game Theory and Market Equilibrium.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-C0E0BE
-category: "[[10_Wiki/💡 Topics/Graphics & Performance]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Game Theory and Market Equilibrium"
----
-
-# [[Game Theory and Market Equilibrium]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Graphics & Performance 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Game Theory and Market Equilibrium.md]]
----
diff --git a/Graphics & Performance/Game Theory.md b/Graphics & Performance/Game Theory.md
deleted file mode 100644
index 8529af61..00000000
--- a/Graphics & Performance/Game Theory.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-69600C
-category: "[[10_Wiki/💡 Topics/Graphics & Performance]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Game Theory"
----
-
-# [[Game Theory]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Graphics & Performance 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Game Theory.md]]
----
diff --git a/Graphics & Performance/Gamification-Design.md b/Graphics & Performance/Gamification-Design.md
deleted file mode 100644
index b3bb48e8..00000000
--- a/Graphics & Performance/Gamification-Design.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-8C354C
-category: "[[10_Wiki/💡 Topics/Graphics & Performance]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Gamification-Design"
----
-
-# [[Gamification-Design]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Graphics & Performance 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Gamification-Design.md]]
----
diff --git a/Graphics & Performance/Garbage Collection.md b/Graphics & Performance/Garbage Collection.md
deleted file mode 100644
index 0982250d..00000000
--- a/Graphics & Performance/Garbage Collection.md	
+++ /dev/null
@@ -1,33 +0,0 @@
----
-id: P-REINFORCE-AUTO-F5453B
-category: "[[10_Wiki/💡 Topics/Graphics & Performance]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Garbage Collection"
----
-
-# [[Garbage Collection]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 가비지 컬렉션(Garbage Collection, GC)은 사용되지 않는 구형 데이터를 메모리에서 해제하는 자바스크립트 엔진의 메모리 관리 프로세스입니다 [1]. 하지만 Three.js와 같은 실시간 3D 렌더링 환경에서는 빈번한 객체 생성이나 메모리 한계 초과로 인해 가비지 컬렉터가 작동할 경우, 프레임이 일시적으로 멈추는(Stuttering) 심각한 성능 저하가 발생할 수 있습니다 [1-3]. 또한, Three.js는 GPU 자원에 대해 자동으로 가비지 컬렉션을 수행하지 않기 때문에 개발자의 명시적인 메모리 관리가 필수적입니다 [4].
-
-## 📖 구조화된 지식 (Synthesized Content)
-* **GPU 자원의 명시적 해제 필요성:** Three.js는 지오메트리, 머티리얼, 텍스처 등의 GPU 자원을 자동으로 가비지 컬렉트하지 않습니다 [4]. 따라서 단일 4K 텍스처가 64MB 이상의 VRAM을 차지하는 등 메모리 누수를 방지하려면, 사용이 끝난 자원은 반드시 `.dispose()` 메서드를 호출하여 명시적으로 GPU 메모리에서 해제해야 합니다 [4].
-* **프레임 멈춤(GC Pauses) 현상:** `useFrame`과 같은 렌더링 루프 내부에서 객체를 계속 생성하거나, 모바일 기기의 시스템 메모리 한계를 초과하는 무거운 텍스처를 사용하면 가비지 컬렉션이 강제로 트리거되어 프레임 멈춤 현상과 스터터링이 발생합니다 [2, 3]. 
-* **동적 버퍼 할당과 TypedArray 부하:** 대규모 인스턴스 렌더링 환경에서 버퍼 용량을 초과해 동적으로 버퍼를 계속 확장할 경우, 수십 메가바이트 단위의 `TypedArray`가 빈번하게 생성되고 파괴됩니다 [1]. 자바스크립트 엔진이 이 구형 배열 데이터를 해제하는 과정에서 가비지 컬렉터가 작동하여 메인 스레드의 점유 시간을 늘리고 프레임 드랍을 유발합니다 [1, 5].
-* **객체 풀링(Object Pooling)을 통한 GC 부하 완화:** 가비지 컬렉션으로 인한 할당 오버헤드와 멈춤 현상을 방지하기 위해서는, 총알이나 파티클처럼 자주 생성되고 파괴되는 엔티티에 대해 새로운 객체를 생성하는 대신 '객체 풀(Pool)'을 미리 구성하여 재사용하는 방식이 강력히 권장됩니다 [6].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Graphics & Performance 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[Memory Management]], [[Object Pooling]], [[GPU Resources]]
-- **Projects/Contexts:** [[Three.js]], [[WebGL]]
-- **Contradictions/Notes:** 소스에 관련 정보가 부족합니다.
-
----
-*Last updated: 2026-04-19*
-- Raw Source: [[00_Raw/2026-04-20/Garbage Collection.md]]
----
diff --git a/Graphics & Performance/Geometry Merging.md b/Graphics & Performance/Geometry Merging.md
deleted file mode 100644
index 71cc14ac..00000000
--- a/Graphics & Performance/Geometry Merging.md	
+++ /dev/null
@@ -1,40 +0,0 @@
----
-id: P-REINFORCE-AUTO-4349BD
-category: "[[10_Wiki/💡 Topics/Graphics & Performance]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Geometry Merging"
----
-
-# [[Geometry Merging]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> **Geometry Merging(지오메트리 병합)**은 Three.js 등의 3D 렌더링 환경에서 정적(static)인 여러 개의 기하학적 데이터를 단일 `BufferGeometry`로 합치는 최적화 기법입니다. 이는 여러 개의 메쉬를 개별적으로 그릴 때 발생하는 **드로우 콜(Draw call)을 단 1회로 줄여주어** CPU 오버헤드를 크게 감소시킵니다. 하지만 개별 객체의 독립적인 이동이나 실시간 상호작용이 제한되며, 객체가 반복될 경우 메모리 사용량이 극심하게 증가한다는 뚜렷한 한계를 가집니다.
-
-## 📖 구조화된 지식 (Synthesized Content)
-*   **원리 및 렌더링 최적화 효과:** 
-    `BufferGeometryUtils.mergeGeometries`와 같은 유틸리티를 사용하여 로드 타임에 여러 메쉬를 하나로 병합하는 방식입니다 [1, 2]. 이 방식은 독립적인 수많은 드로우 콜을 단 하나의 드로우 콜로 결합하므로, **드로우 콜 병목 현상을 완화하는 궁극적인 해결책**을 제공합니다 [3, 4]. 움직임이 필요 없는 정적 씬이나 다수의 부품이 조립된 CAD 렌더링 모델 등에서 높은 프레임 레이트를 유지하는 데 탁월한 효과를 발휘합니다 [4]. 
-
-*   **메모리 소모 및 상호작용의 한계:** 
-    병합된 지오메트리는 병합 전 개별 객체의 기하학적 데이터를 모두 고스란히 복제하여 메모리에 저장합니다. 따라서 수천 개의 동일한 객체(예: 의자)를 렌더링할 때 단일 기하 데이터만 참조하는 인스턴싱(Instancing)과 달리, **메모리(RAM 및 VRAM) 소모가 기하급수적으로 증가**하는 치명적인 단점이 있습니다 [3, 5, 6]. 또한 모든 데이터가 하나로 합쳐져 있으므로, **개별 객체의 위치, 회전, 색상을 실시간으로 변경하거나 개별적인 피킹(Picking) 등 상호작용을 구현하기가 매우 까다롭습니다** [6-8].
-
-*   **시야 절두체 컬링(Frustum Culling) 비효율성:** 
-    모든 객체가 하나의 거대한 메쉬로 병합되면 전체가 **단일 바운딩 볼륨(Bounding volume)으로 취급**됩니다. 이로 인해 합쳐진 덩어리의 극히 일부만 카메라 시야(Frustum)에 들어오더라도 화면에 보이지 않는 나머지 전체 영역까지 모두 렌더링 연산을 수행하게 되어, 결과적으로 GPU 성능의 비효율을 초래할 수 있습니다 [4].
-
-*   **실무적 대안 및 하이브리드 전략:** 
-    절두체 컬링의 문제를 완화하기 위해 공간적 인접성에 따라 메쉬를 나누어 병합하는 **'타일형 병합(Tiled merging)'** 전략이 권장됩니다 [4]. 또한, 메모리와 유연성 문제를 해결하기 위해 동적인 장면이 아니고 모델 크기가 작을 때(< 1GB)에만 병합을 적용하거나 [9], 정적인 저폴리곤 객체는 병합(Merging)하고 동적이거나 고폴리곤인 객체는 `InstancedMesh` 혹은 `BatchedMesh`를 사용하는 **하이브리드 시스템**이 대안으로 활용되기도 합니다 [10, 11].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Graphics & Performance 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[Draw Call]], [[InstancedMesh]], [[BatchedMesh]], [[Frustum Culling]], [[BufferGeometry]]
-- **Projects/Contexts:** [[IFC.js Fragment]], [[CAD Rendering Optimization]]
-- **Contradictions/Notes:** 지오메트리 병합은 드로우 콜을 크게 줄여 렌더링 속도를 높이는 장점이 있지만, 단일 바운딩 박스로 묶이게 되어 시야 절두체 컬링 효율성이 떨어지고 메모리 사용량이 극도로 높아져 하드웨어 자원을 쉽게 고갈시킬 수 있다는 트레이드오프(Trade-off)가 존재합니다 [3, 4].
-
----
-*Last updated: 2026-04-19*
-- Raw Source: [[00_Raw/2026-04-20/Geometry Merging.md]]
----
diff --git a/Graphics & Performance/Graph Theory in Level Design.md b/Graphics & Performance/Graph Theory in Level Design.md
deleted file mode 100644
index c059d8cb..00000000
--- a/Graphics & Performance/Graph Theory in Level Design.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-7898CD
-category: "[[10_Wiki/💡 Topics/Graphics & Performance]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Graph Theory in Level Design"
----
-
-# [[Graph Theory in Level Design]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Graphics & Performance 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Graph Theory in Level Design.md]]
----
diff --git a/Graphics & Performance/HMD(Head-Mounted Display) 기반 엑서게임 환경.md b/Graphics & Performance/HMD(Head-Mounted Display) 기반 엑서게임 환경.md
deleted file mode 100644
index ab2366a0..00000000
--- a/Graphics & Performance/HMD(Head-Mounted Display) 기반 엑서게임 환경.md	
+++ /dev/null
@@ -1,33 +0,0 @@
----
-id: P-REINFORCE-AUTO-E05076
-category: "[[10_Wiki/💡 Topics/Graphics & Performance]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - HMD(Head-Mounted Display) 기반 엑서게임 환경"
----
-
-# [[HMD(Head-Mounted Display) 기반 엑서게임 환경]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> HMD(Head-Mounted Display) 기반 엑서게임 환경은 가상현실(VR) 기술을 활용하여 사용자의 신체적 운동과 게임 플레이를 결합한 몰입형 시스템입니다. 이 환경은 현실감 넘치는 3D 공간과 전방위적인 시야를 제공함으로써 사용자가 운동의 신체적 피로를 잊게 하고 지속적으로 운동에 참여할 수 있는 강력한 동기를 부여합니다 [1]. 그러나 높은 몰입감을 제공하는 대신, 신체 움직임과 시각적 자극의 불일치로 인해 화면 기반(Screen-based) 환경보다 VR 멀미(VR Sickness)나 시각적 피로를 유발할 가능성이 더 크다는 특징을 지닙니다 [2].
-
-## 📖 구조화된 지식 (Synthesized Content)
-- **몰입감과 운동 동기 부여:** HMD 기반의 VR 엑서게임은 사용자를 가상 세계의 목표와 서사에 깊이 빠져들게 하여 신체적 노력에서 오는 고통을 효과적으로 분산시킵니다 [1]. 이러한 실재감(Presence)과 몰입은 사용자의 엑서게임 동기와 지속적인 참여를 이끌어내는 가장 핵심적인 요소입니다 [1].
-- **VR 멀미(VR Sickness)의 발생:** HMD를 착용한 채로 활발한 신체 움직임이 요구되는 엑서게임을 플레이할 경우, 일반적인 대형 화면 기반 게임에 비해 메스꺼움, 방향 감각 상실 등 시뮬레이터 멀미 증상이 더 높게 나타날 수 있습니다 [2, 3]. 이러한 VR 멀미는 게임의 실재감을 깨뜨리고 즐거움과 동기를 저하시키며 인지 능력과 작업 수행 능력을 떨어뜨릴 수 있습니다 [3].
-- **시각적 부작용 및 노출 시간의 영향:** HMD 사용 시 발생하는 눈의 폭주(Vergence)와 조절(Accommodation) 간의 불일치는 깊이 지각에 혼란을 주어 두통, 눈의 피로, 시야 겹침 현상 등의 안구 운동 관련 증상을 초래할 수 있습니다 [3, 4]. 인기 VR 엑서게임인 'Beat Saber'를 활용한 연구에 따르면, 게임 노출 시간이 길어질수록(예: 10분 대비 50분) 즉각적인 멀미 증상과 시각/인지적 영향이 유의미하게 증가하는 것으로 나타났습니다 [5-7].
-- **사후 회복 및 안전 권고:** 대부분의 사용자는 장시간 HMD 엑서게임을 수행한 후 멀미 증상이나 인지 및 시각적 변화를 겪더라도, VR 기기를 벗고 약 40분의 휴식을 취하면 기준선(Baseline) 수준으로 정상 회복됩니다 [6, 7]. 따라서 HMD 엑서게임을 안전하게 활용하기 위해서는 긴 시간 플레이하기 전 짧은 세션을 통해 멀미 발생 여부를 테스트하고, 플레이 종료 후 충분한 대기 및 휴식 시간을 갖는 것이 권장됩니다 [8].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Graphics & Performance 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[VR 멀미(VR Sickness)]], [[실재감(Presence)]], [[폭주-조절 불일치(Vergence-Accommodation Conflict)]]
-- **Projects/Contexts:** [[Beat Saber]], [[가상현실(VR) 자전거 시뮬레이터]]
-- **Contradictions/Notes:** HMD 기반 엑서게임은 기존 화면 기반 게임과 비교했을 때 사용자에게 더 높은 몰입감을 제공하여 운동 효과를 극대화할 수 있지만, 반대로 신체 움직임 증가와 시각적 자극으로 인해 VR 멀미의 유발 가능성을 높인다는 양면적인 모순을 가집니다 [2]. 노출 시간에 비례해 멀미 증상이 증가하지만 대부분 40분 이내에 자연 회복되므로 적절한 휴식과 함께 병행해야 합니다 [6, 9].
-
----
-*Last updated: 2026-04-19*
-- Raw Source: [[00_Raw/2026-04-20/HMD(Head-Mounted Display) 기반 엑서게임 환경.md]]
----
diff --git a/Graphics & Performance/HTML5 Canvas.md b/Graphics & Performance/HTML5 Canvas.md
deleted file mode 100644
index 5e209e96..00000000
--- a/Graphics & Performance/HTML5 Canvas.md	
+++ /dev/null
@@ -1,30 +0,0 @@
----
-id: P-REINFORCE-AUTO-6AA980
-category: "[[10_Wiki/💡 Topics/Graphics & Performance]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - HTML5 Canvas"
----
-
-# [[HTML5 Canvas]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> HTML5 Canvas는 웹 브라우저 내에서 3D 장면이나 그래픽 등 모든 그리기 콘텐츠(drawing contents)를 담는 HTML 요소입니다 [1]. 주로 자바스크립트를 통해 WebGL 또는 WebGPU 컨텍스트를 가져와 GPU에서 하드웨어 가속을 통해 직접 렌더링을 수행하는 대상 화면으로 사용됩니다 [1, 2]. 제공된 소스에서는 독립적인 주제라기보다는 WebGL 및 WebGPU 파이프라인이 그래픽을 출력하는 기본 바탕으로서 단편적으로 언급됩니다.
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Graphics & Performance 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[WebGL]], [[WebGPU]], [[GPU Rendering]]
-- **Projects/Contexts:** [[3D Web-based HMI]], [[LearnWebGL]], [[Chrome DevTools Performance]]
-- **Contradictions/Notes:** 소스에 관련 정보가 부족합니다. 소스 데이터 내에서 HTML5 Canvas 자체의 2D API나 내부 동작 원리에 대한 깊이 있는 설명은 존재하지 않으며, WebGL 및 WebGPU 렌더링을 위한 HTML 요소로서의 역할만 제한적으로 다뤄지고 있습니다.
-
----
-*Last updated: 2026-04-19*
-- Raw Source: [[00_Raw/2026-04-20/HTML5 Canvas.md]]
----
diff --git a/Graphics & Performance/High Resolution Time.md b/Graphics & Performance/High Resolution Time.md
deleted file mode 100644
index c39e24c6..00000000
--- a/Graphics & Performance/High Resolution Time.md	
+++ /dev/null
@@ -1,33 +0,0 @@
----
-id: P-REINFORCE-AUTO-05BDE3
-category: "[[10_Wiki/💡 Topics/Graphics & Performance]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - High Resolution Time"
----
-
-# [[High Resolution Time]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> High Resolution Time(HR-time)은 웹 브라우저 환경에서 고정밀로 시간을 측정하기 위해 사용되는 사양(Spec) 및 메커니즘을 의미한다. 그러나 Spectre나 Meltdown 같은 타이밍 기반의 사이드 채널 공격을 방지하기 위해 이 사양은 `performance.now()`와 같은 측정 도구의 해상도를 의도적으로 제한(Coarsening)하고 있다. 최근 WebGPU의 타임스탬프 쿼리 기능 역시 이 HR-time 사양의 기준을 참조하여 보안과 성능 측정의 균형을 맞추고 있다.
-
-## 📖 구조화된 지식 (Synthesized Content)
-- **보안 취약점에 따른 정밀도 제한 (Coarsening):** Spectre 및 Meltdown과 같은 캐시 사이드 채널 공격은 서브 마이크로초(sub-microsecond) 수준의 미세한 타이밍 차이를 이용해 메모리 접근 패턴을 파악한다 [1]. 이를 막기 위해 브라우저 엔진들은 `performance.now()`와 같은 타이머의 정밀도를 시스템의 격리 상태(isolation status)에 따라 1ms 또는 100 마이크로초(µs) 단위로 낮추었다 [1].
-- **지터(Jitter)의 도입:** 일부 브라우저 구현에서는 반환되는 시간 값에 작고 무작위적인 변동인 '지터(Jitter)'를 추가하여, 공격자가 통계적 평균을 통해 고정밀 시계를 재구성하는 것을 방지한다 [1].
-- **컨텍스트에 따른 해상도 차이:** High Resolution Time 사양(HR-time spec)은 크로스 오리진 격리(cross-origin isolated) 컨텍스트에서는 5µs로, 격리되지 않은(non-isolated) 컨텍스트에서는 100µs(또는 구현이 선호하는 더 거친 수준)로 해상도를 제한하도록 권장한다 [2].
-- **WebGPU 타임스탬프 쿼리(Timestamp Queries) 연동:** WebGPU 환경에서 GPU 연산 소요 시간을 측정하는 타임스탬프 쿼리 기능도 타이밍 공격의 위험이 있어 정밀도 조정이 필요했다 [3-5]. 이에 따라 GPU for the Web 커뮤니티 그룹은 타임스탬프 값을 HR-time 사양을 참조하여 격리 여부와 무관하게 비격리 해상도 기준인 100µs로 제한(quantization)하기로 합의하여 일관성 있는 보안 조치를 적용하였다 [6-8].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Graphics & Performance 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[Spectre and Meltdown]], [[WebGPU Timestamp Queries]], [[performance.now()]]
-- **Projects/Contexts:** [[High Resolution Time spec (#4175)]]
-- **Contradictions/Notes:** 소스 내에 특별한 모순은 없으나, High Resolution Time의 정밀도는 적용되는 보안 격리 환경(Isolated vs Non-isolated) 및 브라우저 엔진의 방어 메커니즘에 따라 5µs, 100µs, 1ms 등 상이하게 적용된다는 점을 유의해야 한다 [1, 2].
-
----
-*Last updated: 2026-04-19*
-- Raw Source: [[00_Raw/2026-04-20/High Resolution Time.md]]
----
diff --git a/Graphics & Performance/Human-Centered Design.md b/Graphics & Performance/Human-Centered Design.md
deleted file mode 100644
index e34e93b8..00000000
--- a/Graphics & Performance/Human-Centered Design.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-AFA55D
-category: "[[10_Wiki/💡 Topics/Graphics & Performance]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Human-Centered Design"
----
-
-# [[Human-Centered Design]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Graphics & Performance 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Human-Centered Design.md]]
----
diff --git a/Graphics & Performance/Human-Computer-Interaction-HCI.md b/Graphics & Performance/Human-Computer-Interaction-HCI.md
deleted file mode 100644
index d5183dd8..00000000
--- a/Graphics & Performance/Human-Computer-Interaction-HCI.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-7D2F0C
-category: "[[10_Wiki/💡 Topics/Graphics & Performance]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Human-Computer-Interaction-HCI"
----
-
-# [[Human-Computer-Interaction-HCI]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Graphics & Performance 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Human-Computer-Interaction-HCI.md]]
----
diff --git a/Graphics & Performance/IFCjs (Fragment).md b/Graphics & Performance/IFCjs (Fragment).md
deleted file mode 100644
index 48fb7fc2..00000000
--- a/Graphics & Performance/IFCjs (Fragment).md	
+++ /dev/null
@@ -1,42 +0,0 @@
----
-id: P-REINFORCE-AUTO-8A58BF
-category: "[[10_Wiki/💡 Topics/Graphics & Performance]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - IFCjs (Fragment)"
----
-
-# [[IFCjs (Fragment)]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> Fragment는 대규모 3D 기하학적 환경을 효율적으로 렌더링하기 위해 IFC.js 개발자들이 고안한 하이브리드 최적화 시스템이다 [1, 2]. 이 시스템은 단일 인터페이스 내에서 로우 폴리(low-poly) 고유 객체를 위한 지오메트리 병합과 하이 폴리(high-poly) 반복 객체를 위한 인스턴싱의 장점을 결합한다 [2]. 이를 통해 메모리 소비와 드로우 콜(Draw call) 횟수 간의 최적의 균형을 달성하면서 개별 객체의 빠른 검색 및 조작 기능을 제공하는 것을 목표로 한다 [1, 3].
-
-## 📖 구조화된 지식 (Synthesized Content)
-* **개발 목적 및 배경:** 
-  건물 모델과 같이 수천 개에서 수백만 개의 객체로 구성된 거대한 씬(scene)을 렌더링할 때, 기존의 모든 객체를 `BufferGeometry`로 병합하는 방식은 램(RAM) 메모리를 지나치게 많이 소비하는 한계가 있었고, `InstancedMesh`를 사용하는 방식은 재질(Material) 수만큼 드로우 콜이 늘어나는 단점이 있었다 [4, 5]. Fragment는 이러한 문제를 해결하여 메모리와 FPS 측면 모두에서 효율성을 달성하고, 개별 객체를 빠르게 검색하고 하이라이트할 수 있도록 설계되었다 [1, 6].
-
-* **하이브리드 아키텍처:** 
-  Fragment는 다음과 같이 객체의 특성에 따라 두 가지 최적화 방식을 혼합하여 사용한다.
-  * **병합 (Merging):** 벽이나 바닥처럼 고유하면서 폴리곤 수가 적은(low-poly) 객체들은 하나 또는 여러 개의 `BufferGeometry`로 병합하여 드로우 콜을 최소화한다 [2, 7].
-  * **인스턴싱 (Instancing):** 문, 가구, 창문과 같이 동일한 형태가 반복되면서 폴리곤 수가 많은(high-poly) 객체들은 각각 `InstancedMesh`로 구성하여 메모리 소비를 대폭 줄인다 [2, 7].
-
-* **구조적 특징 및 저장 방식:** 
-  공통된 Fragment 인터페이스를 통해 1,000개의 동일한 의자가 하나의 인스턴스화된 Fragment가 될 수도 있고, 프로젝트의 모든 벽면이 병합된 단일 Fragment가 될 수도 있다 [6, 7]. 영속성(persistence) 수준에서는 각 Fragment당 하나의 GLB 파일을 저장하는 방식을 고려하여 설계되었다 [7]. 모든 Fragment가 비슷한 수의 정점(vertices)과 드로우 콜을 가지도록 하여 시스템 부하의 균형을 맞춘다 [3].
-
-* **성능 및 결과:** 
-  초기 프로토타입 구현 결과, 1,000개의 의자와 4개의 벽으로 구성된 씬을 단 3번의 드로우 콜(선택용 드로우 콜 제외)과 10MB 미만의 메모리만으로 렌더링하는 데 성공했다 [6]. 또한 100MB 이상의 대형 IFC 모델을 모바일 기기에서도 Autodesk Forge에 필적하는 속도로 빠르게 로드하는 훌륭한 성능을 보여주었다 [8].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Graphics & Performance 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[BufferGeometry]], [[InstancedMesh]], [[Draw Call]]
-- **Projects/Contexts:** [[IFC.js]], [[Three.js]]
-- **Contradictions/Notes:** 소스에 따르면, Fragment와 같은 자체적인 최적화 시스템 구축 외에도 대규모 환경 최적화를 위해 다중 그리기(Multidrawing), LOD(Level of Detail), 오클루전 컬링(Occlusion Culling) 등의 추가적인 방법론도 함께 검토되었다 [2].
-
----
-*Last updated: 2026-04-19*
-- Raw Source: [[00_Raw/2026-04-20/IFC.js (Fragment).md]]
----
diff --git a/Graphics & Performance/ISO 9241 Standards.md b/Graphics & Performance/ISO 9241 Standards.md
deleted file mode 100644
index 460c7c0d..00000000
--- a/Graphics & Performance/ISO 9241 Standards.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-CA7B1B
-category: "[[10_Wiki/💡 Topics/Graphics & Performance]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - ISO 9241 Standards"
----
-
-# [[ISO 9241 Standards]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Graphics & Performance 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/ISO 9241 Standards.md]]
----
diff --git a/Graphics & Performance/Immersive Educational Simulations.md b/Graphics & Performance/Immersive Educational Simulations.md
deleted file mode 100644
index 53ea8753..00000000
--- a/Graphics & Performance/Immersive Educational Simulations.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-7C1550
-category: "[[10_Wiki/💡 Topics/Graphics & Performance]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Immersive Educational Simulations"
----
-
-# [[Immersive Educational Simulations]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Graphics & Performance 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Immersive Educational Simulations.md]]
----
diff --git a/Graphics & Performance/Indirect Draw.md b/Graphics & Performance/Indirect Draw.md
deleted file mode 100644
index ea3b6438..00000000
--- a/Graphics & Performance/Indirect Draw.md	
+++ /dev/null
@@ -1,37 +0,0 @@
----
-id: P-REINFORCE-AUTO-8EEC8D
-category: "[[10_Wiki/💡 Topics/Graphics & Performance]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Indirect Draw"
----
-
-# [[Indirect Draw]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> Indirect Draw(간접 그리기)는 렌더링할 객체의 수와 정보를 CPU가 아닌 GPU가 컴퓨트 셰이더(Compute Shader)의 연산 결과를 바탕으로 직접 결정하여 화면에 그리는 GPU 주도 렌더링(GPU-driven rendering) 기법이다 [1, 2]. 이 방식을 사용하면 시야 절두체 컬링(Frustum Culling)이나 오클루전(Occlusion) 컬링의 결과를 GPU 내부 버퍼에 저장하고 `drawIndirect` 명령으로 바로 출력하므로, CPU와 GPU 간의 데이터 전송량 및 동기화 지연을 거의 0으로 줄일 수 있다 [2, 3]. 매 프레임 수백만 개의 인스턴스를 GPU에서 직접 컬링하고 렌더링해야 하는 대규모 3D 환경에서 필수적인 성능 최적화 기술로 활용된다 [1, 2].
-
-## 📖 구조화된 지식 (Synthesized Content)
-* **작동 원리 및 GPU 주도 렌더링 (GPU-Driven Rendering):** 
-  전통적인 렌더링 파이프라인과 달리, Indirect Draw는 컴퓨트 셰이더를 통해 GPU가 객체의 가시성을 직접 판별하도록 설계되었다 [2, 4]. 컬링 테스트(Cull test)를 통과하여 화면에 보여야 할 객체가 발견되면, 간접 그리기 명령(draw indirect command)의 인스턴스 카운트(instanceCount) 매개변수를 증가시키고 가시성이 확인된 객체에 대해서만 렌더링 명령을 버퍼에 추가(append)하는 방식으로 작동한다 [4, 5].
-  
-* **성능 최적화 및 CPU 병목 해소:** 
-  렌더링을 위한 데이터와 명령 버퍼가 GPU 내부에서 생성되고 직접 참조되므로(`drawIndexedIndirect` 등), CPU와 GPU 간의 무거운 메모리 전송 및 동기화 지연이 제거된다 [2, 3]. 이는 구조적으로 "CPU가 GPU에게 무엇을 할지 지시하는 방식"에서 벗어나 "GPU가 스스로 무엇을 렌더링할지 지시하는 시스템"으로의 그래픽스 패러다임 전환을 의미한다 [3].
-
-* **지원 환경 및 한계 극복:** 
-  WebGPU, Vulkan 등 최신 그래픽스 API 환경에서 주로 활용되며, Three.js에서도 WebGPU 도입과 함께 적극 활용되고 있다 [2, 6, 7]. 매우 복잡하고 방대한 객체를 다룰 때, 기존의 InstancedMesh나 BatchedMesh가 CPU 기반 데이터 업데이트 및 버퍼 패킹으로 인해 겪게 되는 성능 저하 한계를 근본적으로 극복할 수 있는 기술로 평가받는다 [2, 8, 9].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Graphics & Performance 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[GPU-Driven Rendering]], [[Compute Shader]], [[Frustum Culling]], [[WebGPU]]
-- **Projects/Contexts:** [[Three.js WebGPURenderer]], [[BatchedMesh]], [[Vulkan]]
-- **Contradictions/Notes:** 대규모 지오메트리를 처리할 때 BatchedMesh만으로는 CPU의 버퍼 업로드 병목이 발생할 수 있어 근본적인 성능 문제를 피하기 어려우며, 이를 해결하기 위해서는 WebGPU 환경의 Indirect Draw 지원이 필수적이라는 점이 소스에서 한계점(pushing the limits)으로 지적된다 [9].
-
----
-*Last updated: 2026-04-19*
-- Raw Source: [[00_Raw/2026-04-20/Indirect Draw.md]]
----
diff --git a/Graphics & Performance/InstancedMesh (드로우 콜 최적화).md b/Graphics & Performance/InstancedMesh (드로우 콜 최적화).md
deleted file mode 100644
index 9e78853c..00000000
--- a/Graphics & Performance/InstancedMesh (드로우 콜 최적화).md	
+++ /dev/null
@@ -1,33 +0,0 @@
----
-id: P-REINFORCE-AUTO-86F967
-category: "[[10_Wiki/💡 Topics/Graphics & Performance]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - InstancedMesh (드로우 콜 최적화)"
----
-
-# [[InstancedMesh (드로우 콜 최적화)]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> `InstancedMesh`는 **동일한 기하구조(Geometry)와 재질(Material)을 공유하는 수많은 객체를 단 1회의 드로우 콜(Draw Call)만으로 GPU에서 렌더링**하여, CPU의 오버헤드를 극적으로 줄이고 애플리케이션의 프레임 레이트(FPS)를 비약적으로 향상시키는 3D 그래픽스 핵심 최적화 기법입니다.
-
-## 📖 구조화된 지식 (Synthesized Content)
-**1. 드로우 콜(Draw Call)의 개념과 성능 병목** 모든 3D 장면에서 메시는 각각의 드로우 콜을 발생시키며, 이 횟수가 많아질수록 CPU가 GPU에 렌더링 명령을 내리는 오버헤드가 급증합니다. 매끄러운 60FPS를 유지하기 위한 렌더링의 골든 룰은 **프레임당 드로우 콜을 100회 미만으로 유지**하는 것이며, 폴리곤(삼각형)의 수보다 드로우 콜의 횟수가 성능에 훨씬 치명적인 영향을 미칩니다.
-
-**2. InstancedMesh의 작동 원리** 1,000개의 나무나 총알을 개별적인 메시(Mesh)로 렌더링하면 1,000번의 드로우 콜이 발생합니다. 하지만 `InstancedMesh`를 사용하면 **단 1번의 드로우 콜만으로 GPU 내부에서 해당 객체를 1,000번 복제하여 렌더링**할 수 있습니다. 한 부동산 데모 프로젝트의 경우, 수많은 의자 객체들을 인스턴싱 렌더링으로 변경하여 드로우 콜을 9,000회에서 300회로 줄인 사례가 있습니다.
-
-**3. 성능 이득과 활용 방식** 인스턴싱 최적화를 적용하면 드로우 콜 횟수가 $N$(객체 수)에서 1로 줄어들어, 내장형 GPU 환경에서 대규모 데이터셋 렌더링 시 **프레임 레이트를 10배 이상 향상**시킬 수 있습니다. 또한, 각 인스턴스는 동일한 형태를 공유하더라도 인스턴스별 속성(per-instance attributes)을 통해 **서로 다른 위치, 회전, 크기(Scale) 및 색상을 독립적으로 가질 수 있습니다**.
-
-**4. 오브젝트 풀링과의 결합** 실시간 게임 아키텍처에서는 총알이나 파티클과 같이 자주 생성되고 사라지는 객체를 개별 메시로 관리하지 않고, **하나의 `InstancedMesh`를 고정된 오브젝트 풀(Pool)로 관리하며 변환 행렬(Matrix)만 업데이트**하는 방식을 사용해 메모리 파편화 방지와 렌더링 최적화를 동시에 달성합니다.
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Graphics & Performance 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[Draw Call Optimization (드로우 콜 최적화)]], [[BatchedMesh]], [[Object Pooling (오브젝트 풀링)]], [[React Three Fiber 자산 최적화]]
-- **Projects/Contexts:** [[대규모 파티클 시스템 최적화]], [[수만 개의 데이터를 표현하는 3D 산점도(Scatter Plot) 시각화]], [[숲, 군중 등 반복 객체가 많은 3D 씬]]
-- **Contradictions/Notes:** `InstancedMesh`는 성능 개선에 탁월하지만, **모든 인스턴스가 반드시 동일한 기하구조(Geometry)와 재질(Material)을 공유해야 한다는 설계적 제약**이 따릅니다. 만약 재질은 같으나 형태(Geometry)가 서로 다른 여러 객체들을 묶어 드로우 콜을 1회로 줄이려면, R156 버전에 도입된 `BatchedMesh`를 사용하는 것이 더 적합합니다.
-- Raw Source: [[00_Raw/2026-04-20/InstancedMesh (드로우 콜 최적화).md]]
----
diff --git a/Graphics & Performance/InstancedMesh2.md b/Graphics & Performance/InstancedMesh2.md
deleted file mode 100644
index 32293ec3..00000000
--- a/Graphics & Performance/InstancedMesh2.md	
+++ /dev/null
@@ -1,40 +0,0 @@
----
-id: P-REINFORCE-AUTO-0E2591
-category: "[[10_Wiki/💡 Topics/Graphics & Performance]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - InstancedMesh2"
----
-
-# [[InstancedMesh2]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> InstancedMesh2는 Three.js의 기본 `InstancedMesh`를 확장하여 성능과 기능을 대폭 강화한 오픈 소스 라이브러리이다 [1-3]. 이 라이브러리는 개별 인스턴스에 대한 절두체 컬링(Frustum culling), 공간 인덱스(BVH)를 이용한 빠른 레이캐스팅, 정렬(Sorting), 개별 가시성 관리 및 LOD 기능을 제공한다 [2-5]. 특히 기존 인스턴싱 기술로 처리하기 까다로웠던 개별 애니메이션 상태를 가진 스킨드 메쉬(Skinned Mesh)의 인스턴싱을 지원하여 대규모 3D 환경을 효율적으로 렌더링하는 데 활용된다 [1, 3, 6].
-
-## 📖 구조화된 지식 (Synthesized Content)
-*   **핵심 기능 및 최적화 기법**
-    *   **인스턴스별 절두체 컬링 및 가시성 제어:** 개별 인스턴스 단위로 가시성을 관리하고 절두체 컬링을 수행한다 [2, 3, 5]. 이를 통해 카메라 뷰 내부에 존재하는 인스턴스의 뼈대(Bone) 계산만 수행하는 등 연산을 극도로 최적화할 수 있으며, `onFrustumEnter`를 사용해 인스턴스 렌더링 여부를 정밀하게 제어할 수 있다 [1, 7].
-    *   **BVH 기반 빠른 레이캐스팅:** `three-mesh-bvh` 라이브러리 설계에 착안한 공간 인덱스(Spatial index)를 포함하여, 수많은 인스턴스가 배치된 환경에서도 빠른 레이캐스팅과 컬링을 지원한다 [3-5, 8].
-    *   **LOD 및 애니메이션(Skinning) 최적화:** 객체의 거리(LOD)에 따라 기하학적 구조(Geometry)뿐 아니라 뼈대(Bones) 연산까지 축소하고, 거리에 비례하여 애니메이션 FPS를 0에서 60까지 조절할 수 있다 [1, 6, 9, 10]. 이를 통해 모바일 기기에서도 2만 개 이상의 스킨드 인스턴스를 무리 없이 구동할 수 있다 [1].
-    *   **정렬(Sorting):** 렌더링 시 투명도 문제를 방지하기 위해, 내부적으로 BatchedMesh에 기반한 기수 정렬(Radix sort) 기능을 제공한다 [11, 12].
-
-*   **내부 아키텍처 및 데이터 구조**
-    *   **간접 참조(Indirection) 기반 인덱싱:** 라이브러리 초기 버전과 달리, `InstancedBufferAttribute`를 활용하여 렌더링될 인스턴스 인덱스를 간접적으로 관리한다 [12]. 이는 GPU로 데이터를 보내기 전 컬링, 선택적 렌더링, 정렬 작업을 배열의 물리적 재정렬 없이 빠르게 수행할 수 있게 한다 [12].
-    *   **SquareDataTexture의 활용:** 인스턴스의 행렬(Matrix) 및 주요 데이터를 저장하는 데 `DataTexture`의 확장 버전인 `SquareDataTexture`를 사용한다 [12]. 이 방식은 부분 업데이트(Partial Updates)를 지원하여 전체 데이터를 갱신할 필요 없이 변경된 일부 인스턴스의 정보만 갱신하도록 돕는다 [8, 12].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Graphics & Performance 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[InstancedMesh]], [[Frustum culling]], [[BVH]], [[LOD]], [[SkinnedMesh]], [[BatchedMesh]]
-- **Projects/Contexts:** [[agargaro의 오픈 소스 라이브러리]], [[20k skinned instances demo]]
-- **Contradictions/Notes:** 
-  - `SquareDataTexture`를 활용한 부분 업데이트 기능이 연속되지 않은 메모리 접근과 부가적인 함수 호출로 인해 CPU 오버헤드를 유발할 수 있다는 우려가 제기되었으나, 소수의 인스턴스만 변하는 상황에서는 상당한 대역폭 절약 효과가 있다고 라이브러리 개발자(@agargaro)가 반론했습니다 [8, 13, 14].
-  - 이러한 고급 기능들이 유용함에도 불구하고, Three.js의 메인 코어에 병합하기에는 내부 셰이더 변경과 기존 코드 호환성 파괴(Breaking changes) 등 유지보수 복잡성이 너무 커서 외부 라이브러리로 분리 개발되고 있습니다 [15, 16].
-
----
-*Last updated: 2026-04-19*
-- Raw Source: [[00_Raw/2026-04-20/InstancedMesh2.md]]
----
diff --git a/Graphics & Performance/Instancing.md b/Graphics & Performance/Instancing.md
deleted file mode 100644
index bac9d6dc..00000000
--- a/Graphics & Performance/Instancing.md	
+++ /dev/null
@@ -1,37 +0,0 @@
----
-id: P-REINFORCE-AUTO-2752BF
-category: "[[10_Wiki/💡 Topics/Graphics & Performance]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Instancing"
----
-
-# [[Instancing]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 인스턴싱(Instancing)은 웹 그래픽스 렌더링 및 UI 디자인 소프트웨어에서 성능을 최적화하기 위해 동일한 객체를 효율적으로 반복 처리하는 기법입니다. WebGL이나 WebGPU 환경에서는 단일 드로우 콜(draw call)로 동일한 메쉬나 형태를 대량으로 그려내어 CPU 및 GPU 오버헤드를 줄이는 핵심 기술로 사용됩니다 [1, 2]. 반면 Figma와 같은 디자인 도구에서는 원본 컴포넌트의 복제본을 의미하며, 인스턴스 내부의 구조적 최적화 여부가 소프트웨어 성능에 직접적인 영향을 미칩니다 [3, 4].
-
-## 📖 구조화된 지식 (Synthesized Content)
-- **웹 그래픽스 렌더링 최적화 (WebGL & WebGPU):**
-  - **드로우 콜(Draw Call) 감소:** WebGL 애플리케이션에서 성능을 극대화하는 가장 중요한 비결은 드로우 콜 횟수를 최소화하는 것입니다 [5]. 동일한 메쉬를 여러 번 호출하여 그리는 대신 인스턴싱 기법을 사용하면 대량의 메쉬를 단일 함수 호출로 렌더링할 수 있어 성능 오버헤드를 크게 줄일 수 있습니다 [1].
-  - **WebGPU를 활용한 가우시안 렌더링 (WebSplatter):** WebGPU 기반의 3D Gaussian Splatting 프레임워크인 WebSplatter는 래스터화 단계에서 인스턴스화된 드로우 콜(instanced draw call)을 통해 각 가우시안을 단일 쿼드(두 개의 삼각형)로 제출하여 렌더링합니다 [2]. 렌더 패스(Render pass) 내부에서 `passEncoder.draw(vertexCount, instanceCount)` 명령을 호출하여, 지정된 정점 및 인스턴스 수만큼 버텍스 셰이더와 프래그먼트 셰이더의 실행을 트리거합니다 [6].
-  - **관련 WebGL 확장 기능:** WebGL 생태계에서는 이와 같은 인스턴싱을 지원하기 위해 `ANGLE_instanced_arrays`라는 확장(Extension) 기능을 제공합니다 [7].
-
-- **디자인 시스템 및 UI 도구(Figma)에서의 인스턴스:**
-  - **성능 저하의 원인:** 대규모 디자인 파일에서 복잡한 중첩 구조를 가진 컴포넌트를 사용할 때, 인스턴스 내부에 불필요하게 포함된 숨겨진 레이어(hidden layers)는 파일의 렌더링과 업데이트 속도를 크게 늦출 수 있습니다 [3, 8, 9].
-  - **인스턴스 최적화 방안:** 구조 컴포넌트의 사용을 줄이고, 대신 별도의 변형(variants) 개수를 늘려 인스턴스 내의 숨겨진 레이어들을 제거하면 프로토타입 동작이 눈에 띄게 부드러워지며 성능이 크게 향상됩니다 [4, 10].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Graphics & Performance 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[Draw Calls]], [[WebGL]], [[WebGPU]], [[Gaussian Splatting]]
-- **Projects/Contexts:** [[Wonderland Engine]], [[WebSplatter]], [[Figma]]
-- **Contradictions/Notes:** 주어진 소스 데이터 내에서 '인스턴스(Instancing)'라는 용어는 3D 그래픽스 하드웨어 가속을 위한 렌더링 효율화 기법(WebGL/WebGPU)과, 디자인 도구 내에서 원본 객체를 복제해 사용하는 개체 단위(Figma)라는 두 가지 상이한 맥락에서 설명되고 있습니다.
-
----
-*Last updated: 2026-04-19*
-- Raw Source: [[00_Raw/2026-04-20/Instancing.md]]
----
diff --git a/Graphics & Performance/Instructional Systems Design (ISD).md b/Graphics & Performance/Instructional Systems Design (ISD).md
deleted file mode 100644
index 3e2f5524..00000000
--- a/Graphics & Performance/Instructional Systems Design (ISD).md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-03221B
-category: "[[10_Wiki/💡 Topics/Graphics & Performance]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Instructional Systems Design (ISD)"
----
-
-# [[Instructional Systems Design (ISD)]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Graphics & Performance 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Instructional Systems Design (ISD).md]]
----
diff --git a/Graphics & Performance/Instructional-Design.md b/Graphics & Performance/Instructional-Design.md
deleted file mode 100644
index 748d8ae6..00000000
--- a/Graphics & Performance/Instructional-Design.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-FFEC9C
-category: "[[10_Wiki/💡 Topics/Graphics & Performance]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Instructional-Design"
----
-
-# [[Instructional-Design]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Graphics & Performance 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Instructional-Design.md]]
----
diff --git a/Graphics & Performance/Interactive Storytelling.md b/Graphics & Performance/Interactive Storytelling.md
deleted file mode 100644
index 97537aee..00000000
--- a/Graphics & Performance/Interactive Storytelling.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-355ABB
-category: "[[10_Wiki/💡 Topics/Graphics & Performance]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Interactive Storytelling"
----
-
-# [[Interactive Storytelling]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Graphics & Performance 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Interactive Storytelling.md]]
----
diff --git a/Graphics & Performance/Interactive-Storytelling.md b/Graphics & Performance/Interactive-Storytelling.md
deleted file mode 100644
index fc3b2718..00000000
--- a/Graphics & Performance/Interactive-Storytelling.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-6D7369
-category: "[[10_Wiki/💡 Topics/Graphics & Performance]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Interactive-Storytelling"
----
-
-# [[Interactive-Storytelling]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Graphics & Performance 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Interactive-Storytelling.md]]
----
diff --git a/Graphics & Performance/Internet of Things (IoT) Telemetry.md b/Graphics & Performance/Internet of Things (IoT) Telemetry.md
deleted file mode 100644
index c56e6eb5..00000000
--- a/Graphics & Performance/Internet of Things (IoT) Telemetry.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-D09D7C
-category: "[[10_Wiki/💡 Topics/Graphics & Performance]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Internet of Things (IoT) Telemetry"
----
-
-# [[Internet of Things (IoT) Telemetry]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Graphics & Performance 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Internet of Things (IoT) Telemetry.md]]
----
diff --git a/Graphics & Performance/Intrinsic Motivation.md b/Graphics & Performance/Intrinsic Motivation.md
deleted file mode 100644
index f55c0518..00000000
--- a/Graphics & Performance/Intrinsic Motivation.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-D1BB71
-category: "[[10_Wiki/💡 Topics/Graphics & Performance]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Intrinsic Motivation"
----
-
-# [[Intrinsic Motivation]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Graphics & Performance 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Intrinsic Motivation.md]]
----
diff --git a/Graphics & Performance/JavaScript.md b/Graphics & Performance/JavaScript.md
deleted file mode 100644
index 1bf25931..00000000
--- a/Graphics & Performance/JavaScript.md	
+++ /dev/null
@@ -1,32 +0,0 @@
----
-id: P-REINFORCE-AUTO-4A99EB
-category: "[[10_Wiki/💡 Topics/Graphics & Performance]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - JavaScript"
----
-
-# [[JavaScript]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> JavaScript는 단일 페이지 애플리케이션을 구축하고 WebGL, WebGPU와 같은 웹 브라우저 API를 제어하는 데 사용되는 핵심 스크립팅 언어입니다 [1, 2]. 애플리케이션 로직, 이벤트 처리 및 데이터 준비에 필수적이지만, 브라우저의 메인 스레드에서 무거운 JavaScript를 실행하거나 가비지 컬렉션이 발생하면 심각한 성능 병목 현상이 생길 수 있습니다 [3-5]. 따라서 최근의 웹 성능 최적화는 JavaScript 페이로드를 줄이고, 실행 시간을 분할하며, 무거운 연산을 GPU로 오프로드하는 방향으로 발전하고 있습니다 [6, 7].
-
-## 📖 구조화된 지식 (Synthesized Content)
-*   **웹 그래픽(WebGL 및 WebGPU)에서의 역할:** JavaScript는 브라우저의 WebGL 및 WebGPU API와 상호 작용하기 위한 인터페이스 언어입니다 [2, 8]. WebGL 환경에서 JavaScript 프로그램은 CPU에서 실행되며, 3D 모델 데이터 변환, 버퍼 객체 생성, 유니폼(Uniform) 변수 설정 및 드로우 콜(Draw call) 발행 등의 작업을 수행합니다 [9, 10]. 그러나 JavaScript 프로그램과 GPU 간의 빈번한 통신 및 브라우저 API 호출은 렌더링 속도를 저하시키는 큰 오버헤드를 발생시킵니다 [11, 12]. 이러한 문제를 해결하기 위해 등장한 WebGPU는 애니메이션이나 정렬과 같은 로직을 GPU의 컴퓨트 셰이더(Compute shader)로 직접 오프로드하여 JavaScript 런타임으로 인한 메인 스레드 병목 현상을 획기적으로 줄여줍니다 [6, 13, 14].
-*   **성능 영향 및 최적화:** JavaScript 실행은 INP(Interaction to Next Paint) 및 TBT(Total Blocking Time)와 같은 코어 웹 바이탈(Core Web Vitals) 성능 지표에 직접적인 영향을 미칩니다 [7, 15]. 메인 스레드를 50ms 이상 차단하는 긴 작업(Long tasks)은 사용자 상호 작용에 대한 응답을 지연시킵니다 [7]. 또한, JavaScript의 가비지 컬렉션(Garbage Collection) 프로세스는 개발자가 제어할 수 없는 시점에 일시 중지를 유발하여 렌더링 끊김(Stutter)이나 불규칙한 프레임 속도를 발생시킬 수 있습니다 [4, 8]. 이를 최적화하기 위해 개발자는 긴 작업을 더 작은 비동기 청크로 분할하고, 필수적이지 않은 JS를 지연 로드(Defer/Lazy load)하며, 가비지가 없는(garbage-free) 코드를 작성해야 합니다 [7, 16, 17].
-*   **성능 모니터링 및 디버깅:** Chrome DevTools의 성능(Performance) 패널은 JavaScript 성능을 프로파일링하는 데 필수적인 도구입니다 [3]. 이 도구를 통해 개발자는 메인 스레드 활동의 플레임 차트(Flame chart)를 분석하고, JavaScript 함수의 세부 호출 스택을 확인하며, 강제 동기식 레이아웃(Forced synchronous layouts)을 유발하거나 상호 작용 처리를 지연시키는 특정 스크립트를 식별할 수 있습니다 [3, 18, 19]. 또한, Long Animation Frames API를 기반으로 사용자 상호 작용을 지연시키는 스크립트의 레이아웃 작업 및 스크립팅 작업 비율을 확인할 수 있습니다 [20].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Graphics & Performance 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** `[[WebGL]]`, `[[WebGPU]]`, `[[Interaction to Next Paint (INP)]]`, `[[Garbage Collection]]`, `[[Chrome DevTools]]`
-- **Projects/Contexts:** `[[Three.js]]`, `[[웹 그래픽 성능 최적화(Web Graphics Performance Optimization)]]`
-- **Contradictions/Notes:** WebGL을 구동하기 위해 JavaScript는 필수적이지만, CPU 측의 JavaScript 실행 및 상태 유효성 검사 오버헤드가 오히려 렌더링 성능을 제한하는 가장 큰 병목으로 작용합니다. 이로 인해 3D 렌더링 산업은 JavaScript의 개입을 줄이고 GPU의 병렬 연산을 극대화할 수 있는 WebGPU로 빠르게 전환하는 추세입니다 [5, 6, 13].
-
----
-*Last updated: 2026-04-19*
-- Raw Source: [[00_Raw/2026-04-20/JavaScript.md]]
----
diff --git a/Graphics & Performance/Knowledge-Graphs.md b/Graphics & Performance/Knowledge-Graphs.md
deleted file mode 100644
index cca80eb8..00000000
--- a/Graphics & Performance/Knowledge-Graphs.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-9FC608
-category: "[[10_Wiki/💡 Topics/Graphics & Performance]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Knowledge-Graphs"
----
-
-# [[Knowledge-Graphs]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Graphics & Performance 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Knowledge-Graphs.md]]
----
diff --git a/Graphics & Performance/Looking-Glass-Studios.md b/Graphics & Performance/Looking-Glass-Studios.md
deleted file mode 100644
index 197310c1..00000000
--- a/Graphics & Performance/Looking-Glass-Studios.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-83E00E
-category: "[[10_Wiki/💡 Topics/Graphics & Performance]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Looking-Glass-Studios"
----
-
-# [[Looking-Glass-Studios]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Graphics & Performance 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Looking-Glass-Studios.md]]
----
diff --git a/Graphics & Performance/Loot Box Regulation (EU_China Compliance).md b/Graphics & Performance/Loot Box Regulation (EU_China Compliance).md
deleted file mode 100644
index 997abbcc..00000000
--- a/Graphics & Performance/Loot Box Regulation (EU_China Compliance).md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-4B1863
-category: "[[10_Wiki/💡 Topics/Graphics & Performance]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Loot Box Regulation (EU_China Compliance)"
----
-
-# [[Loot Box Regulation (EU_China Compliance)]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Graphics & Performance 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Loot Box Regulation (EU_China Compliance).md]]
----
diff --git a/Graphics & Performance/Ludology.md b/Graphics & Performance/Ludology.md
deleted file mode 100644
index 73e5e30f..00000000
--- a/Graphics & Performance/Ludology.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-397611
-category: "[[10_Wiki/💡 Topics/Graphics & Performance]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Ludology"
----
-
-# [[Ludology]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Graphics & Performance 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Ludology.md]]
----
diff --git a/Graphics & Performance/MDA Framework.md b/Graphics & Performance/MDA Framework.md
deleted file mode 100644
index 24558e35..00000000
--- a/Graphics & Performance/MDA Framework.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-14D7A9
-category: "[[10_Wiki/💡 Topics/Graphics & Performance]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - MDA Framework"
----
-
-# [[MDA Framework]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Graphics & Performance 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/MDA Framework.md]]
----
diff --git a/Graphics & Performance/MDA-Framework.md b/Graphics & Performance/MDA-Framework.md
deleted file mode 100644
index 9ae0b496..00000000
--- a/Graphics & Performance/MDA-Framework.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-D62F53
-category: "[[10_Wiki/💡 Topics/Graphics & Performance]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - MDA-Framework"
----
-
-# [[MDA-Framework]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Graphics & Performance 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/MDA-Framework.md]]
----
diff --git a/Graphics & Performance/Markov Decision Process (MDP).md b/Graphics & Performance/Markov Decision Process (MDP).md
deleted file mode 100644
index 236bbedf..00000000
--- a/Graphics & Performance/Markov Decision Process (MDP).md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-14D223
-category: "[[10_Wiki/💡 Topics/Graphics & Performance]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Markov Decision Process (MDP)"
----
-
-# [[Markov Decision Process (MDP)]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Graphics & Performance 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Markov Decision Process (MDP).md]]
----
diff --git a/Graphics & Performance/Markov Decision Processes.md b/Graphics & Performance/Markov Decision Processes.md
deleted file mode 100644
index 99470b95..00000000
--- a/Graphics & Performance/Markov Decision Processes.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-336A60
-category: "[[10_Wiki/💡 Topics/Graphics & Performance]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Markov Decision Processes"
----
-
-# [[Markov Decision Processes]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Graphics & Performance 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Markov Decision Processes.md]]
----
diff --git a/Graphics & Performance/Mathematical Game Theory.md b/Graphics & Performance/Mathematical Game Theory.md
deleted file mode 100644
index 349a3947..00000000
--- a/Graphics & Performance/Mathematical Game Theory.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-5BCF2D
-category: "[[10_Wiki/💡 Topics/Graphics & Performance]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Mathematical Game Theory"
----
-
-# [[Mathematical Game Theory]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Graphics & Performance 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Mathematical Game Theory.md]]
----
diff --git a/Graphics & Performance/Measure Theory.md b/Graphics & Performance/Measure Theory.md
deleted file mode 100644
index 4fd2a024..00000000
--- a/Graphics & Performance/Measure Theory.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-06771D
-category: "[[10_Wiki/💡 Topics/Graphics & Performance]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Measure Theory"
----
-
-# [[Measure Theory]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Graphics & Performance 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Measure Theory.md]]
----
diff --git a/Graphics & Performance/Memory Leak Prevention 메모리 누수 방지.md b/Graphics & Performance/Memory Leak Prevention 메모리 누수 방지.md
deleted file mode 100644
index e114c95f..00000000
--- a/Graphics & Performance/Memory Leak Prevention 메모리 누수 방지.md	
+++ /dev/null
@@ -1,49 +0,0 @@
----
-id: P-REINFORCE-AUTO-21F91F
-category: "[[10_Wiki/💡 Topics/Graphics & Performance]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Memory Leak Prevention 메모리 누수 방지"
----
-
-# [[Memory Leak Prevention 메모리 누수 방지]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> React 애플리케이션 및 WebGL/Three.js 환경에서 해제되지 않은 타이머, 이벤트 리스너, 외부 객체 참조, 또는 GPU 자원으로 인해 시간이 지날수록 메모리 점유율이 증가하여 앱이 느려지거나 크래시되는 현상을 막기 위한 필수적인 자원 관리 및 최적화 기법입니다.
-
-## 📖 구조화된 지식 (Synthesized Content)
-**1. React의 주요 메모리 누수 원인과 클린업(Cleanup)** React 앱이 시간이 지날수록 느려지는 가장 흔한 원인은 언마운트(Unmount)된 컴포넌트의 잔재가 계속 남아 메모리를 점유하는 경우입니다.
-
-- **미해제 타이머:** `setInterval`이나 `setTimeout`을 실행한 뒤 정리하지 않으면 백그라운드에서 계속 동작합니다. `useEffect`의 클린업(return) 함수에서 `clearInterval` 등을 반드시 호출해야 합니다.
-- **미해제 이벤트 리스너:** `window.addEventListener`를 통해 등록한 이벤트도 컴포넌트가 사라질 때 `window.removeEventListener`로 해제해야 합니다.
-- **열려있는 웹소켓 연결:** 연결이 열린 채로 방치되지 않도록 클린업 시점에 `ws.close()`를 호출하여 연결을 닫아주어야 합니다.
-
-**2. 거대한 객체 참조 유지 방지** `useRef` 등을 사용하여 거대한 데이터 세트나 클로저를 참조하고 있는 경우, 컴포넌트 사용이 끝난 후에도 가비지 컬렉터(GC)가 해당 메모리를 회수하지 못합니다.
-
-- 이를 방지하기 위해 작업이 완료된 거대한 객체 참조에는 명시적으로 `null`을 할당(`processedRef.current = null`)하여 메모리를 해제할 수 있도록 도와야 합니다.
-
-**3. Three.js / WebGL에서의 GPU 메모리 누수 방지** Three.js나 React Three Fiber(R3F)와 같은 3D 환경에서는 메모리 관리가 더욱 치명적입니다. 자바스크립트는 힙 메모리를 가비지 컬렉션(GC) 하지만, **Three.js는 GPU 자원(Geometry, Material, Texture 등)을 자동으로 가비지 컬렉션하지 않습니다**.
-
-- 사용이 끝난 3D 객체는 반드시 명시적으로 `.dispose()` 메서드를 호출하여 VRAM 메모리 누수를 막아야 합니다 (예: 4K 텍스처 하나가 64MB 이상의 VRAM을 낭비할 수 있습니다).
-- GLTF 모델의 텍스처(ImageBitmap 형태)는 누수를 막기 위해 `texture.source.data.close?.()`와 같이 명시적인 닫기 호출도 필요합니다.
-
-**4. 메모리 누수 탐지 및 모니터링 (Debugging & Monitoring)**
-
-- **Chrome DevTools Memory Profiler:** 특정 사용자 행동 전후의 힙 스냅샷(Heap Snapshots)을 찍어 비교하고, 할당 타임라인(Allocation Timelines)을 통해 가비지 컬렉션되어야 할 객체가 그대로 남아있는지 추적하여 누수 지점을 찾아냅니다.
-- 개발 환경에서는 `performance.memory.usedJSHeapSize`를 모니터링하여 메모리 점유율이 일정 수치(예: 200MB)를 넘어가면 경고(Alert)를 발생시키도록 감시 코드를 작성해 선제적으로 대응할 수 있습니다.
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Graphics & Performance 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[useEffect 클린업(Cleanup)]], [[Garbage Collection (GC) 최적화]], [[Three.js 자원 해제 (Dispose)]], [[Chrome DevTools Memory Profiler]]
-- **Projects/Contexts:** [[장기 실행되는 실시간 대시보드 최적화]], [[대규모 WebGL/R3F 3D 게임 환경의 메모리 관리]]
-- **Contradictions/Notes:** 최신 자바스크립트 엔진은 매우 훌륭한 가비지 컬렉터(GC)를 갖추고 있으나, DOM 이벤트, 브라우저 API(타이머, 소켓), WebGL GPU 메모리 등 '자바스크립트 엔진 외부의 자원'과 연결된 참조는 GC가 임의로 판단해 지울 수 없습니다. 따라서 외부 자원과의 연결 고리는 개발자가 직접 끊어주어야만 완벽한 메모리 관리가 가능합니다.
-
----
-
-_Last updated: 2026-04-14_
-- Raw Source: [[00_Raw/2026-04-20/Memory Leak Prevention 메모리 누수 방지.md]]
----
diff --git a/Graphics & Performance/Memory Leaks.md b/Graphics & Performance/Memory Leaks.md
deleted file mode 100644
index f539f638..00000000
--- a/Graphics & Performance/Memory Leaks.md	
+++ /dev/null
@@ -1,34 +0,0 @@
----
-id: P-REINFORCE-AUTO-5A05AF
-category: "[[10_Wiki/💡 Topics/Graphics & Performance]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Memory Leaks"
----
-
-# [[Memory Leaks]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> Three.js 및 WebGL 환경에서 메모리 누수(Memory Leaks)는 GPU 리소스가 자동으로 가비지 컬렉션(Garbage Collection)되지 않아 VRAM 등 메모리 사용량이 지속적으로 증가하는 현상을 의미합니다 [1]. 이는 주로 지오메트리, 재질, 텍스처 등의 렌더링 리소스를 코드 상에서 명시적으로 해제하지 않았을 때 발생합니다 [1, 2]. 메모리 누수를 방지하려면 렌더러 정보를 통한 지속적인 모니터링과 올바른 메모리 관리 기법의 적용이 필수적입니다 [2].
-
-## 📖 구조화된 지식 (Synthesized Content)
-*   **GPU 리소스의 수동 해제:** Three.js는 GPU 리소스를 자동으로 가비지 컬렉션하지 않기 때문에, 더 이상 사용하지 않는 자원은 반드시 개발자가 직접 **`geometry.dispose()`, `material.dispose()`, `texture.dispose()`, `renderTarget.dispose()`**를 호출하여 해제해야 합니다 [1-3].
-*   **GLTF ImageBitmap 특수 처리:** GLTF 모델에서 불러온 텍스처는 `ImageBitmap` 객체로 로드되므로 누수를 막기 위한 추가적인 처리가 필요합니다 [3]. 이러한 텍스처는 일반적인 `dispose()` 외에도 반드시 **`texture.source.data.close?.()`**를 호출하여 명시적으로 닫아주어야 ImageBitmap 객체의 메모리 누수를 막을 수 있습니다 [2, 3].
-*   **오브젝트 풀링(Object Pooling) 도입:** 런타임 중 빈번하게 생성되고 파괴되는 오브젝트(예: 총알, 파티클, 적 등)는 메모리 할당 오버헤드와 이로 인한 가비지 컬렉션 지연(GC pauses)을 유발할 수 있습니다 [3]. 이를 방지하기 위해 새로운 객체를 매번 할당하는 대신 기존 객체를 재활용하는 **객체 풀링(Object Pooling)** 패턴을 구현해야 합니다 [2, 3].
-*   **메모리 누수 모니터링:** 런타임에 메모리 누수가 발생하고 있는지 확인하려면 **`renderer.info.memory`** 지표를 주기적으로 모니터링해야 합니다 [1, 2]. 해당 지표에서 지오메트리와 텍스처의 카운트가 떨어지지 않고 계속해서 상승하기만 한다면, 명확한 메모리 누수로 판단할 수 있습니다 [1, 2].
-*   **에셋 스트리밍(Asset Streaming) 및 메모리 한계:** WebGL 컨텍스트는 제한된 메모리 용량(통상 256MB~1GB)을 지니고 있어 이를 초과하면 브라우저 크래시나 프리징이 발생할 수 있습니다 [4]. 무한한 크기의 씬이라도 카메라에서 100 유닛 이상 멀어진 자원들에 대해 `dispose()`를 호출해 메모리를 해제하는 스트리밍 방식을 적용하면, 활성화된 모델만 메모리에 유지하여 메모리 누수 및 고갈을 방지할 수 있습니다 [5].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Graphics & Performance 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[Garbage Collection]], [[Object Pooling]], [[Dispose()]], [[ImageBitmap]]
-- **Projects/Contexts:** [[Three.js Memory Management]], [[Asset Streaming in WebGL]]
-- **Contradictions/Notes:** 소스 간의 모순점은 발견되지 않았으며, 제공된 소스들은 모두 공통적으로 Three.js 엔진 환경에서 메모리 누수를 방지하기 위해 '사용이 끝난 자원의 명시적 해제(dispose)'가 절대적으로 필요함을 강조하고 있습니다.
-
----
-*Last updated: 2026-04-19*
-- Raw Source: [[00_Raw/2026-04-20/Memory Leaks.md]]
----
diff --git a/Graphics & Performance/Memory Management.md b/Graphics & Performance/Memory Management.md
deleted file mode 100644
index 7a5da45d..00000000
--- a/Graphics & Performance/Memory Management.md	
+++ /dev/null
@@ -1,34 +0,0 @@
----
-id: P-REINFORCE-AUTO-F27A16
-category: "[[10_Wiki/💡 Topics/Graphics & Performance]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Memory Management"
----
-
-# [[Memory Management]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 3D 웹 렌더링 및 그래픽스 환경에서 'Memory Management(메모리 관리)'는 시스템의 제한된 RAM과 GPU VRAM을 효율적으로 통제하여 애플리케이션의 크래시, 메모리 누수, 그리고 가비지 컬렉션(GC)으로 인한 프레임 지연을 방지하는 필수적인 최적화 과정입니다 [1, 2]. 이는 불필요한 GPU 자원의 명시적 폐기, 객체 풀링, 버퍼의 사전 할당 및 텍스처 압축 기술을 포괄합니다 [3-6].
-
-## 📖 구조화된 지식 (Synthesized Content)
-- **명시적 자원 폐기 및 누수 방지:** Three.js와 같은 엔진은 GPU 자원을 자동으로 가비지 컬렉션(GC)하지 않으므로, 사용이 끝난 Geometry, Material, Texture, Render Target은 반드시 명시적으로 폐기(`dispose()`)해야 합니다 [3, 4, 7, 8]. 특히 GLTF 모델에서 불러온 ImageBitmap 텍스처는 `close()`를 호출해야 메모리 누수를 차단할 수 있습니다 [4, 7]. 렌더러의 메모리 지표(`renderer.info.memory`)를 모니터링하여 누수 여부를 지속적으로 확인해야 합니다 [1, 3, 7].
-- **가비지 컬렉션(GC) 부하 최소화:** 런타임 중 빈번하게 생성 및 파괴되는 객체에 대해서는 매번 새로 메모리를 할당하는 대신 객체 풀링(Object Pooling)을 사용하여 할당 오버헤드와 GC로 인한 일시적인 프레임 끊김(Stuttering) 현상을 방지해야 합니다 [2, 4, 7].
-- **동적 버퍼 할당 문제 통제:** 인스턴싱 환경에서 인스턴스 수가 변경될 때 버퍼 용량을 동적으로 확장하게 두면 잦은 메모리 재할당과 가비지 컬렉션 부하를 야기합니다 [2, 5, 9]. 이를 피하기 위해 최대 예상 인스턴스 수에 맞춰 초기 버퍼를 미리 크게 할당(Preallocate)하거나 링 버퍼(Ring Buffer) 구조를 활용하는 것이 권장됩니다 [2, 5].
-- **텍스처 및 지오메트리 압축:** 4K 해상도와 같은 고해상도 텍스처는 하나당 64MB 이상의 VRAM을 소모하며, 기기의 메모리 한계를 초과할 경우 브라우저 크래시를 유발할 수 있습니다 [1, 3, 10]. KTX2나 Basis Universal 같은 GPU 압축 텍스처 포맷을 도입하면 대역폭 및 메모리 사용량을 75% 이상 절감할 수 있으며 [6, 11, 12], 지오메트리 속성 역시 정밀도를 낮춰 양자화(Quantization)함으로써 버퍼 크기를 대폭 줄일 수 있습니다 [13]. 텍스처는 한 번만 로드하여 캐시한 뒤 여러 곳에서 재사용해야 합니다 [4, 14].
-- **멀티스레딩 환경의 메모리 최적화:** Electron과 같은 환경에서 대규모 CAD 모델을 로드할 때 메인 스레드와 워커 간의 메시지 전달(Structured Cloning)은 메모리 사용량을 두 배로 폭증시킬 위험이 있습니다 [15]. 이를 방지하기 위해 `SharedArrayBuffer`를 활용하여 메모리 복사 없이(Zero-copy) 데이터를 공유하는 아키텍처를 도입해야 합니다 [15, 16].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Graphics & Performance 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[Garbage Collection]], [[Object Pooling]], [[Texture Compression]], [[GPU Resources]], [[Buffer Allocation]]
-- **Projects/Contexts:** [[Three.js]], [[WebGL]], [[Electron]], [[Needle Engine]]
-- **Contradictions/Notes:** 웹 기반 프론트엔드 개발에서는 자바스크립트의 자동 메모리 관리에 의존하기 쉬우나, 소스에 따르면 WebGL과 같은 GPU 자원은 가비지 컬렉터의 대상이 아니므로 개발자가 수동으로 자원 해제를 관리해야만 크래시와 누수를 막을 수 있다고 강력히 지적합니다 [3, 7, 17]. 또한, 드로우 콜을 줄이는 인스턴싱 기법이 성능에 유리해 보이지만, 동적으로 크기가 늘어나는 버퍼를 방치할 경우 오히려 심각한 가비지 컬렉션 병목을 초래해 전체 성능을 깎아먹을 수 있음을 경고합니다 [2, 9].
-
----
-*Last updated: 2026-04-19*
-- Raw Source: [[00_Raw/2026-04-20/Memory Management.md]]
----
diff --git a/Graphics & Performance/MeshStandardMaterial 조명 연산.md b/Graphics & Performance/MeshStandardMaterial 조명 연산.md
deleted file mode 100644
index 2b6f7c2f..00000000
--- a/Graphics & Performance/MeshStandardMaterial 조명 연산.md	
+++ /dev/null
@@ -1,35 +0,0 @@
----
-id: P-REINFORCE-AUTO-56F596
-category: "[[10_Wiki/💡 Topics/Graphics & Performance]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - MeshStandardMaterial 조명 연산"
----
-
-# [[MeshStandardMaterial 조명 연산]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> MeshStandardMaterial은 금속성-거칠기(metallic-roughness) 워크플로우를 사용하는 물리 기반 렌더링(PBR) 모델을 기반으로 한 Three.js의 재질입니다 [1]. 이 재질은 에너지 보존 법칙과 프레넬 반사(Fresnel reflections)와 같은 복잡한 조명 연산을 필요로 하므로, 세밀한 사실성을 제공하지만 Three.js 내에서 가장 연산 비용이 높은 재질 중 하나로 꼽힙니다 [1].
-
-## 📖 구조화된 지식 (Synthesized Content)
-* **조명 연산의 구조 및 복잡성:**
-  MeshStandardMaterial의 조명 연산은 알베도(albedo), 노멀(normal), 금속성(metallic), 거칠기(roughness), 앰비언트 오클루전(AO) 등의 다양한 텍스처 맵과 환경 반사를 결합하여 이루어집니다 [1, 2]. 이 과정에서 화면에 보이는 픽셀(프래그먼트) 하나당 15~20개의 텍스처 샘플을 처리해야 하며, 수십 번의 복잡한 수학적 연산이 요구됩니다 [2].
-* **성능 병목 현상 및 프래그먼트 바운드(Fragment-bound):**
-  연산이 매우 무겁기 때문에 수많은 객체가 화면에 겹쳐서 렌더링되는 오버드로우(Overdraw) 현상이 발생할 경우, 중복된 조명 연산으로 인해 씬이 프래그먼트 바운드 상태에 빠지며 심각한 성능 저하를 유발합니다 [3]. 예를 들어 내장 그래픽(iGPU) 환경에서 이 재질을 사용해 100만 개 이상의 삼각형을 렌더링할 경우, 프래그먼트 프로세서가 포화되어 프레임 레이트가 30 이하로 급락할 수 있습니다 [1].
-* **조명 연산 최적화 기법:**
-  MeshStandardMaterial을 유지하면서 수백 개 이상의 다양한 객체를 최적화하여 그리기 위해, 각 객체의 재질 속성(색상, 방출, 거칠기, 금속성 등)을 하나의 데이터 텍스처에 패킹(packing)하는 기법이 활용될 수 있습니다 [4]. 이후 `onBeforeCompile`을 통해 셰이더가 기존 유니폼(Uniform) 대신 해당 텍스처의 값을 읽도록 수정하면, 동일한 셰이더를 공유하면서 단 한 번의 드로우 콜로 다양한 물리 기반 속성을 렌더링할 수 있습니다 [4].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Graphics & Performance 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[Physically Based Rendering (PBR)]], [[오버드로우 (Overdraw)]], [[프래그먼트 바운드 (Fragment-bound)]]
-- **Projects/Contexts:** [[Three.js 대규모 씬 최적화]]
-- **Contradictions/Notes:** 극도의 사실성을 제공하는 현대적인 표준 재질이지만, 연산량이 많아 저사양 하드웨어에서는 비물리 기반의 MeshPhongMaterial 등 보다 가벼운 조명 모델을 사용하는 것이 추천될 만큼 렌더링 비용 면에서 뚜렷한 트레이드오프가 존재합니다 [1, 5].
-
----
-*Last updated: 2026-04-19*
-- Raw Source: [[00_Raw/2026-04-20/MeshStandardMaterial 조명 연산.md]]
----
diff --git a/Graphics & Performance/Meta Quest_Horizon OS.md b/Graphics & Performance/Meta Quest_Horizon OS.md
deleted file mode 100644
index a9cd0704..00000000
--- a/Graphics & Performance/Meta Quest_Horizon OS.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-65D468
-category: "[[10_Wiki/💡 Topics/Graphics & Performance]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Meta Quest_Horizon OS"
----
-
-# [[Meta Quest_Horizon OS]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Graphics & Performance 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Meta Quest_Horizon OS.md]]
----
diff --git a/Graphics & Performance/Metal.md b/Graphics & Performance/Metal.md
deleted file mode 100644
index 119efe29..00000000
--- a/Graphics & Performance/Metal.md	
+++ /dev/null
@@ -1,33 +0,0 @@
----
-id: P-REINFORCE-AUTO-939802
-category: "[[10_Wiki/💡 Topics/Graphics & Performance]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Metal"
----
-
-# [[Metal]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> Metal은 주요 제조업체의 독점적인 차세대 네이티브 GPU API 중 하나입니다 [1]. Vulkan, Direct3D 12(DX12)와 함께 노후화된 OpenGL 표준을 대체하는 웹용 차세대 그래픽 API인 WebGPU의 설계와 프로그래밍 모델에 직접적인 영감을 제공한 핵심 기술입니다 [1-3].
-
-## 📖 구조화된 지식 (Synthesized Content)
-* **WebGPU 설계의 기반:** WebGPU는 노후화된 OpenGL 표준에 의존하지 않고, Metal을 비롯한 현대적인 네이티브 API(Vulkan, DX12 등)를 수용하도록 밑바닥부터 새롭게 설계되었습니다 [1-3].
-* **명시적(Explicit) 렌더링 접근법:** WebGPU는 Metal과 같은 현대 API들이 사용하는 명시적 접근 방식을 채택했습니다. 기존의 가변적인 전역 상태(global state) 모델 대신 불변하는 파이프라인 객체, 바인드 그룹(bind groups), 커맨드 버퍼를 사용하여 렌더링을 구성함으로써 드라이버 최적화를 극대화하고 버그를 줄입니다 [4].
-* **WebGPU 백엔드(Backend) 어댑터:** Chrome 등의 브라우저에서 개발자 기능을 활성화한 후 WebGPU 어댑터 정보(`requestAdapterInfo()`)를 요청할 때, 실행을 담당하는 백엔드 중 하나로 "metal"이 식별되어 사용될 수 있습니다 [5].
-* **성능 최적화 동향:** WebGPU의 지속적인 업데이트 과정에서 Metal 백엔드 환경을 위한 최적화가 이루어지고 있으며, 일례로 Chrome 130 릴리스에서는 Metal 상에서의 셰이더 컴파일 시간이 개선된 바 있습니다 [6].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Graphics & Performance 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[WebGPU]], [[Vulkan]], [[Direct3D 12 (DX12)]], [[OpenGL]]
-- **Projects/Contexts:** [[WebGPU Backend]]
-- **Contradictions/Notes:** 소스에 관련 정보가 부족합니다.
-
----
-*Last updated: 2026-04-19*
-- Raw Source: [[00_Raw/2026-04-20/Metal.md]]
----
diff --git a/Graphics & Performance/Metaverse Architecture.md b/Graphics & Performance/Metaverse Architecture.md
deleted file mode 100644
index cbcb3a05..00000000
--- a/Graphics & Performance/Metaverse Architecture.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-7BDD7C
-category: "[[10_Wiki/💡 Topics/Graphics & Performance]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Metaverse Architecture"
----
-
-# [[Metaverse Architecture]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Graphics & Performance 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Metaverse Architecture.md]]
----
diff --git a/Graphics & Performance/Micro-latency.md b/Graphics & Performance/Micro-latency.md
deleted file mode 100644
index cf0f995a..00000000
--- a/Graphics & Performance/Micro-latency.md	
+++ /dev/null
@@ -1,30 +0,0 @@
----
-id: P-REINFORCE-AUTO-B64E78
-category: "[[10_Wiki/💡 Topics/Graphics & Performance]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Micro-latency"
----
-
-# [[Micro-latency]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 웹 그래픽 파이프라인에서 마이크로 레이턴시(Micro-latency)는 60Hz 디스플레이 기준 16.67ms와 같은 엄격한 시간 예산 내에서 하드웨어와 소프트웨어 구성 요소가 동기화할 때 발생하는 미세한 지연을 의미합니다 [1]. 이는 JavaScript 엔진의 가비지 컬렉션, WebGL 및 ANGLE과 같은 API 변환, OS의 컨텍스트 생성, 디스플레이 하드웨어 등 여러 계층에서 복합적으로 발생하며 [2-5], 이러한 미세 지연이 누적되면 프레임 누락이나 인지 가능한 끊김(Stuttering) 현상으로 이어집니다 [1, 5]. 최근에는 Spectre 및 Meltdown과 같은 보안 취약점 완화 조치로 인해 시스템의 기본 마이크로 레이턴시가 소폭 증가하기도 했습니다 [6, 7].
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Graphics & Performance 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[WebGL]], [[WebGPU]], [[Spectre and Meltdown]], [[EXT_disjoint_timer_query]], [[ANGLE (Almost Native Graphics Layer Engine)]]
-- **Projects/Contexts:** [[WebSplatter (3D Gaussian Splatting)]], [[CesiumJS]], [[Figma]]
-- **Contradictions/Notes:** 소스에 따르면, 성능 분석을 위한 정밀한 마이크로 레이턴시 측정의 필요성과 시스템 보안(Spectre/Meltdown 공격 방어) 사이에 명확한 상충(Conflict)이 존재합니다. 고정밀 타이머가 사이드 채널 공격에 악용될 수 있다는 연구 결과에 따라 브라우저 벤더들은 `EXT_disjoint_timer_query`를 비활성화하거나 타이머 해상도를 인위적으로 낮추는(Quantization) 타협안을 채택해야만 했습니다 [6, 10-12, 18].
-
----
-*Last updated: 2026-04-19*
-- Raw Source: [[00_Raw/2026-04-20/Micro-latency.md]]
----
diff --git a/Graphics & Performance/Minecraft.md b/Graphics & Performance/Minecraft.md
deleted file mode 100644
index 09338166..00000000
--- a/Graphics & Performance/Minecraft.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-A3F579
-category: "[[10_Wiki/💡 Topics/Graphics & Performance]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Minecraft"
----
-
-# [[Minecraft]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Graphics & Performance 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Minecraft.md]]
----
diff --git a/Graphics & Performance/Minecraft_ Education Edition.md b/Graphics & Performance/Minecraft_ Education Edition.md
deleted file mode 100644
index 18eb5c70..00000000
--- a/Graphics & Performance/Minecraft_ Education Edition.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-7091B6
-category: "[[10_Wiki/💡 Topics/Graphics & Performance]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Minecraft_ Education Edition"
----
-
-# [[Minecraft_ Education Edition]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Graphics & Performance 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Minecraft_ Education Edition.md]]
----
diff --git a/Graphics & Performance/Mobile Gaming Monetization Strategies.md b/Graphics & Performance/Mobile Gaming Monetization Strategies.md
deleted file mode 100644
index a36eedfe..00000000
--- a/Graphics & Performance/Mobile Gaming Monetization Strategies.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-48096A
-category: "[[10_Wiki/💡 Topics/Graphics & Performance]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Mobile Gaming Monetization Strategies"
----
-
-# [[Mobile Gaming Monetization Strategies]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Graphics & Performance 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Mobile Gaming Monetization Strategies.md]]
----
diff --git a/Graphics & Performance/Multi-threaded Architecture.md b/Graphics & Performance/Multi-threaded Architecture.md
deleted file mode 100644
index 4c927d37..00000000
--- a/Graphics & Performance/Multi-threaded Architecture.md	
+++ /dev/null
@@ -1,40 +0,0 @@
----
-id: P-REINFORCE-AUTO-4271F6
-category: "[[10_Wiki/💡 Topics/Graphics & Performance]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Multi-threaded Architecture"
----
-
-# [[Multi-threaded Architecture]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 자바스크립트의 단일 스레드(Single-thread) 제약을 극복하기 위해 웹 워커(Web Worker)와 OffscreenCanvas를 활용하여 무거운 CPU 연산이나 3D 그래픽 렌더링을 백그라운드로 분리하고, 메인 스레드와 고효율로 상태를 동기화하여 매끄러운 반응성을 보장하는 진보된 애플리케이션 설계 패턴입니다.
-
-## 📖 구조화된 지식 (Synthesized Content)
-**1. 멀티스레딩의 필요성과 Web Worker 분리** 자바스크립트는 기본적으로 단일 스레드 환경이므로 대규모 데이터 정렬, 이미지 처리, 물리 연산 등 무거운 작업을 수행하면 메인 스레드가 블로킹되어 UI가 멈추는 프리징(Freezing) 현상이 발생합니다. 이를 방지하기 위해 무거운 연산을 웹 워커(Web Worker)로 오프로딩(Offloading)하면, UI 상호작용은 메인 스레드에서 방해 없이 처리하고 연산은 백그라운드 스레드에서 병렬로 진행할 수 있습니다. React 앱에서는 `@koale/useworker`와 같은 훅 기반 라이브러리를 통해 워커 설정을 단순화하여 활용할 수 있습니다.
-
-**2. OffscreenCanvas와 WebGL/R3F 렌더링 분리** 복잡한 3D 씬을 다루는 WebGL 애플리케이션이나 Three.js/React Three Fiber(R3F) 환경의 경우 렌더링 연산 자체가 메인 스레드 자원을 크게 소모합니다. `OffscreenCanvas`를 사용하면 DOM과 Canvas API를 분리하여 캔버스의 제어권을 웹 워커로 넘길 수 있습니다. 이 구조에서는 렌더링과 DOM 조작이 물리적으로 분리되어 서로의 성능에 영향을 주지 않으며, 메인 스레드의 트래픽(과부하)과 무관하게 워커에서 부드러운 애니메이션을 독립적으로 유지할 수 있습니다.
-
-**3. 대리 인터랙션(Event Forwarding) 시스템** 웹 워커 내부에는 DOM이나 `window` 객체가 존재하지 않으므로 사용자의 마우스 클릭, 터치 등의 이벤트를 직접 수신할 수 없습니다. 따라서 메인 스레드에서 이벤트를 캡처한 뒤, 이벤트의 타입과 포인터 좌표 등 필수 데이터만 워커로 전달(`postMessage`)하여 워커 내부에서 상호작용 및 레이캐스팅(Raycasting)을 처리하도록 하는 이벤트 포워딩 파이프라인 구축이 필수적입니다.
-
-**4. 고효율 상태 동기화 (State Synchronization)** 메인 스레드(React DOM UI)와 워커(WebGL 씬 또는 연산 로직) 양쪽에서 동일한 앱 상태를 읽고 써야 하는 경우, 스레드 간 상태 동기화가 가장 큰 과제가 됩니다.
-
-- **프록시 및 델타 동기화:** Valtio와 같은 프록시 기반 상태 관리 도구를 사용하여 로컬 저장소를 구축한 뒤, 상태가 변할 때마다 변경된 작업 내용(Operations/Delta)만 `Broadcast Channel API`를 통해 상대 스레드에 전달하여 동기화합니다.
-- **SharedArrayBuffer:** 지연 시간이 극도로 낮아야 하는 환경이나 ECS 기반의 게임에서는 두 스레드가 메모리를 직접 공유하는 `SharedArrayBuffer`를 사용하여 직렬화(Serialization) 및 복사 비용 없이 원자적(Atomic) 연산을 수행합니다.
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Graphics & Performance 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[Web Worker (웹 워커)]], [[OffscreenCanvas]], [[SharedArrayBuffer]], [[상태 관리 최적화 (Zustand, Jotai, Valtio)]]
-- **Projects/Contexts:** [[고성능 실시간 상호작용 시스템을 위한 React 기반 게임 엔진 아키텍처]], [[대규모 데이터 분석 및 시각화 대시보드]]
-- **Contradictions/Notes:** 멀티스레딩이 무조건적인 성능 향상을 가져오지는 않습니다. 메인 스레드와 워커 스레드 간에 데이터를 주고받는 과정(`postMessage`)에는 직렬화로 인한 오버헤드(약 5~10ms)가 수반됩니다. 따라서 연산 시간이 50ms 미만인 비교적 가벼운 작업을 워커로 분리하면, 통신 비용이 연산 시간보다 커져 오히려 전체 성능이 하락할 수 있으므로 철저한 프로파일링을 기반으로 병목 구간에만 도입해야 합니다.
-
----
-
-_Last updated: 2026-04-15_
-- Raw Source: [[00_Raw/2026-04-20/Multi-threaded Architecture.md]]
----
diff --git a/Graphics & Performance/NASA-Jet-Propulsion-Laboratory-Software-Standards.md b/Graphics & Performance/NASA-Jet-Propulsion-Laboratory-Software-Standards.md
deleted file mode 100644
index f5130205..00000000
--- a/Graphics & Performance/NASA-Jet-Propulsion-Laboratory-Software-Standards.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-33A414
-category: "[[10_Wiki/💡 Topics/Graphics & Performance]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - NASA-Jet-Propulsion-Laboratory-Software-Standards"
----
-
-# [[NASA-Jet-Propulsion-Laboratory-Software-Standards]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Graphics & Performance 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/NASA-Jet-Propulsion-Laboratory-Software-Standards.md]]
----
diff --git a/Graphics & Performance/NVIDIA Omniverse.md b/Graphics & Performance/NVIDIA Omniverse.md
deleted file mode 100644
index 04954343..00000000
--- a/Graphics & Performance/NVIDIA Omniverse.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-068667
-category: "[[10_Wiki/💡 Topics/Graphics & Performance]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - NVIDIA Omniverse"
----
-
-# [[NVIDIA Omniverse]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Graphics & Performance 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/NVIDIA Omniverse.md]]
----
diff --git a/Graphics & Performance/Narrative-Branching-Models.md b/Graphics & Performance/Narrative-Branching-Models.md
deleted file mode 100644
index c236262d..00000000
--- a/Graphics & Performance/Narrative-Branching-Models.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-4FC48D
-category: "[[10_Wiki/💡 Topics/Graphics & Performance]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Narrative-Branching-Models"
----
-
-# [[Narrative-Branching-Models]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Graphics & Performance 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Narrative-Branching-Models.md]]
----
diff --git a/Graphics & Performance/Narratology.md b/Graphics & Performance/Narratology.md
deleted file mode 100644
index 9962f67e..00000000
--- a/Graphics & Performance/Narratology.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-BAAE58
-category: "[[10_Wiki/💡 Topics/Graphics & Performance]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Narratology"
----
-
-# [[Narratology]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Graphics & Performance 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Narratology.md]]
----
diff --git a/Graphics & Performance/Needle Engine.md b/Graphics & Performance/Needle Engine.md
deleted file mode 100644
index 48241f79..00000000
--- a/Graphics & Performance/Needle Engine.md	
+++ /dev/null
@@ -1,34 +0,0 @@
----
-id: P-REINFORCE-AUTO-8D909B
-category: "[[10_Wiki/💡 Topics/Graphics & Performance]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Needle Engine"
----
-
-# [[Needle Engine]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> Needle Engine은 3D 렌더링 및 웹 애플리케이션 개발을 지원하는 엔진이다 [1]. 동일한 객체(예: 나무)를 반복적으로 렌더링할 때 발생하는 드로우 콜 증가를 막기 위해 GPU 인스턴싱(GPU Instancing) 및 `InstancedMesh`를 활용한 최적화를 제공한다 [1, 2]. 내부적으로 인스턴싱 버퍼가 런타임에 동적으로 증가하면 성능 지연이 발생할 수 있으므로, 버퍼 사전 할당이나 프로그래밍 방식의 인스턴스 생성이 권장된다 [2, 3].
-
-## 📖 구조화된 지식 (Synthesized Content)
-- **다중 인스턴스 처리와 드로우 콜 최적화**: 수많은 반복 객체를 렌더링할 때 씬에 개별 객체로 배치하면 엔진이 이를 독립적으로 처리하여 드로우 콜이 크게 증가한다 [1]. Needle Engine에서는 이를 해결하기 위해 명시적으로 GPU 인스턴싱을 사용하여 여러 객체를 하나의 인스턴싱 배치로 통합하는 방식을 취해야 한다 [1].
-- **동적 버퍼 확장 문제 및 대안**: 인스턴싱 시스템은 초기에 낮은 버퍼 용량으로 시작하며, 런타임에 인스턴스가 추가되어 버퍼가 동적으로 늘어날 경우(`[Instancing] Growing Buffer`) 성능 지연(Stall) 및 메모리 할당 오류가 발생할 수 있다 [3]. 이를 방지하려면 `RendererInstancing.d.ts.md` 소스의 `InstancingHandler.getStartInstanceCount`를 오버라이드하여, 엔진 시작 시 예상되는 최대 인스턴스 수만큼 버퍼를 미리 할당하는 방법이 권장된다 [3].
-- **프로그래밍 방식의 InstancedMesh 활용**: 외부 툴(예: 블렌더)에서 단일 에셋을 익스포트한 후, 코드 상에서 `InstancedMesh` 객체를 생성하여 프로그래밍 방식으로 런타임에 인스턴스화하면 버퍼의 동적 확장 문제를 피할 수 있다 [2].
-- **오버드로우(Overdraw) 관리**: 인스턴싱을 적용하더라도 나뭇잎과 같은 투명한(Transparent) 재질을 겹쳐서 렌더링하면 오버드로우로 인해 렌더링 성능이 크게 저하될 수 있다 [4]. 이를 불투명(Opaque) 및 컷아웃(Cutout) 모드로 변경하면 프레임 속도를 대폭 개선할 수 있다 [5].
-- **압축 환경에서의 버그 해결**: 프로덕션 빌드나 프리뷰 압축 적용 시 텍스처 누락이나 인스턴싱 렌더링 오류가 발생할 수 있으며, 이는 임포트 설정을 점검하거나 `@needle-tools/engine` 패키지(예: `3.19.11-beta.1`) 업데이트를 통해 해결할 수 있다 [2, 6, 7].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Graphics & Performance 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[GPU Instancing]], [[InstancedMesh]], [[Draw Call]], [[Overdraw]]
-- **Projects/Contexts:** [[Needle Engine 다중 인스턴스(Multiple Instance) 렌더링 최적화 논의]]
-- **Contradictions/Notes:** Needle Engine 어시스턴트는 성능 지연 방지를 위해 `InstancingHandler.getStartInstanceCount`를 사용해 버퍼를 사전 할당할 것을 제안했지만, 실제 사용자는 이 방식이 매칭되는 모든 렌더러마다 해당 크기의 배열을 반복해서 할당하기 때문에 의도한 최적화 효과를 완전히 얻기 어렵다고 보고했다 [3, 8].
-
----
-*Last updated: 2026-04-19*
-- Raw Source: [[00_Raw/2026-04-20/Needle Engine.md]]
----
diff --git a/Graphics & Performance/Object Pooling.md b/Graphics & Performance/Object Pooling.md
deleted file mode 100644
index 8a8a1653..00000000
--- a/Graphics & Performance/Object Pooling.md	
+++ /dev/null
@@ -1,34 +0,0 @@
----
-id: P-REINFORCE-AUTO-18523F
-category: "[[10_Wiki/💡 Topics/Graphics & Performance]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Object Pooling"
----
-
-# [[Object Pooling]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> Object Pooling(오브젝트 풀링)은 총알, 파티클, 적 캐릭터와 같이 런타임 중 빈번하게 생성되고 파괴되는 개체들의 성능을 최적화하기 위해 사용되는 메모리 관리 기법입니다 [1]. 매번 새로운 객체를 메모리에 할당하는 대신, 사전에 생성해 둔 객체들의 풀(Pool)을 구축하여 이를 재사용하는 방식으로 동작합니다 [1]. 이를 통해 애플리케이션 실행 중 발생하는 메모리 할당 오버헤드와 가비지 컬렉션(Garbage Collection, GC)으로 인한 프레임 멈춤 현상을 효과적으로 방지할 수 있습니다 [1, 2]. 대규모 3D 씬과 동적인 렌더링 환경에서는 안정적인 메모리 제어와 누수 방지를 위해 객체 풀링 전략을 사전에 수립하는 것이 필수적입니다 [3, 4].
-
-## 📖 구조화된 지식 (Synthesized Content)
-- **가비지 컬렉션(GC) 부하 및 오버헤드 방지:** 객체의 지속적인 생성과 소멸은 가비지 컬렉터를 잦게 작동시켜 시스템에 부하를 줍니다. 객체 풀링을 도입하면 빈번하게 사용되는 리소스를 재사용하므로, 메모리 할당 오버헤드와 GC에 의한 일시 정지(Pauses)를 피할 수 있습니다 [1].
-- **프리워밍(Pre-warming) 전략:** 런타임에 객체를 할당할 때 생기는 갑작스러운 성능 저하(Allocation spike)를 피하기 위해, 애플리케이션 로딩 단계에서 풀을 미리 생성하고 데워두는(Pre-warm) 방식이 강력히 권장됩니다 [1].
-- **메모리 누수(Memory Leak) 관리:** Three.js와 같은 3D 그래픽스 환경에서 메모리 누수를 처리하는 핵심 지침 중 하나는, 수명이 짧고 빈번히 등장하는 리소스들에 대해 자원 풀링(Resource pooling)을 구현하여 메모리 할당을 통제하는 것입니다 [3].
-- **메쉬 재활용(Recycling Meshes)을 통한 CPU 최적화:** 한 번에 너무 많은 메쉬를 처리해야 할 때, 논리적인 데이터 맵을 사용하여 객체의 상태를 추적하고, 화면에 보이는 객체만을 '사전 빌드된 메쉬 풀(pool of pre-built meshes)'을 이용해 렌더링함으로써 CPU 부담을 크게 낮출 수 있습니다 [2].
-- **대규모 메모리 대역폭 제어:** 동적인 환경에서 인스턴스 버퍼가 한계를 초과하여 재할당되는 일이 잦아지면 치명적인 GC 부하가 발생합니다. 이를 방지하기 위해 엄격한 메모리 예산 설정과 함께 객체 풀링 전략이 사전에 철저히 수립되어야 합니다 [4].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Graphics & Performance 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[Memory Management]], [[Garbage Collection]], [[Memory Leaks]]
-- **Projects/Contexts:** [[Three.js]], [[Babylon.js]]
-- **Contradictions/Notes:** 소스에 관련 정보가 부족합니다. (주어진 소스 내에서 오브젝트 풀링의 효과나 방식에 대해 상충하는 의견은 존재하지 않으며, 모두 성능 최적화를 위해 적극적으로 권장하고 있습니다.)
-
----
-*Last updated: 2026-04-19*
-- Raw Source: [[00_Raw/2026-04-20/Object Pooling.md]]
----
diff --git a/Graphics & Performance/OffscreenCanvas Safari 제약 사항.md b/Graphics & Performance/OffscreenCanvas Safari 제약 사항.md
deleted file mode 100644
index 706d9a9c..00000000
--- a/Graphics & Performance/OffscreenCanvas Safari 제약 사항.md	
+++ /dev/null
@@ -1,35 +0,0 @@
----
-id: P-REINFORCE-AUTO-600505
-category: "[[10_Wiki/💡 Topics/Graphics & Performance]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - OffscreenCanvas Safari 제약 사항"
----
-
-# [[OffscreenCanvas Safari 제약 사항]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> Safari 브라우저에서는 `OffscreenCanvas`와 WebGL의 결합 사용이 아직 완전히 지원되지 않아, 워커 스레드와 메인 스레드용 렌더링 코드를 별도로 유지보수하거나 폴백(Fallback)을 구현해야 하는 치명적인 제약이 있습니다.
-
-## 📖 구조화된 지식 (Synthesized Content)
-**1. OffscreenCanvas와 WebGL 지원 부족** Safari 브라우저에서는 오프스크린 캔버스와 WebGL을 함께 사용하는 환경(`offscreen canvas + webgl`)이 아직 제대로 지원되지 않습니다. 이러한 한계 때문에 워커 내부에서 DOM과 통신(`postMessage`)해야 하는 복잡한 구조를 구현할 때 큰 제약이 따릅니다.
-
-**2. 코드 분기(Fork)의 강제 및 유지보수 부담** Safari의 지원 부족 문제로 인해, 개발자들은 앱을 웹 워커에서 실행되는 버전과 메인 스레드에서 실행되는 폴백(Fallback) 버전의 두 갈래(two forks)로 나누어 유지보수해야만 했습니다. 이러한 호환성 이슈와 개발의 번거로움은 Three.js 생태계에서 OffscreenCanvas 기술이 오랫동안 대중화되지 못했던 가장 큰 원인 중 하나였습니다.
-
-**3. 해결책 및 우회 전략 (Fallback & Broadcast API)** 최근에는 `@react-three/offscreen`과 같은 라이브러리를 통해 이 문제를 비교적 쉽게 해결할 수 있습니다. 해당 라이브러리는 `fallback` 프롭(Prop)을 제공하여, Safari처럼 OffscreenCanvas를 지원하지 않는 환경에서는 자동으로 기존처럼 메인 스레드에서 씬(Scene)이 렌더링되도록 우회해 줍니다. 또한, Safari 환경의 한계를 고려하여 3D 씬을 철저히 독립적으로(Self-contained) 구성하는 것이 좋으며, 부득이하게 DOM과 통신해야 할 경우 `postMessage` 대신 웹 브로드캐스트 API(Web Broadcast API)를 사용하는 것이 권장됩니다.
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Graphics & Performance 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[OffscreenCanvas]], [[Web Worker (웹 워커)]], [[React Three Fiber (R3F)]], [[Cross-browser Compatibility (크로스 브라우저 호환성)]]
-- **Projects/Contexts:** [[고성능 멀티스레드 React 앱 아키텍처]], [[실시간 3D 웹 게임 렌더링 환경]]
-- **Contradictions/Notes:** Safari 브라우저가 2025년 9월(v26)부터 WebGPU 지원을 시작하는 등 그래픽 지원 범위를 넓혀가고 있으나, `OffscreenCanvas`를 활용한 WebGL 멀티스레드 렌더링에 대해서는 여전히 제약이 보고되고 있으므로 프로덕션 환경에서는 반드시 메인 스레드용 `fallback` 컴포넌트를 제공해야 안정성을 보장할 수 있습니다.
-
----
-
-_Last updated: 2026-04-15_
-- Raw Source: [[00_Raw/2026-04-20/OffscreenCanvas Safari 제약 사항.md]]
----
diff --git a/Graphics & Performance/OffscreenCanvas 기반 멀티스레드 렌더링 구현.md b/Graphics & Performance/OffscreenCanvas 기반 멀티스레드 렌더링 구현.md
deleted file mode 100644
index 7e839d80..00000000
--- a/Graphics & Performance/OffscreenCanvas 기반 멀티스레드 렌더링 구현.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-58B572
-category: "[[10_Wiki/💡 Topics/Graphics & Performance]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - OffscreenCanvas 기반 멀티스레드 렌더링 구현"
----
-
-# [[OffscreenCanvas 기반 멀티스레드 렌더링 구현]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Graphics & Performance 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/OffscreenCanvas 기반 멀티스레드 렌더링 구현.md]]
----
diff --git a/Graphics & Performance/OffscreenCanvas.md b/Graphics & Performance/OffscreenCanvas.md
deleted file mode 100644
index e0247c6e..00000000
--- a/Graphics & Performance/OffscreenCanvas.md	
+++ /dev/null
@@ -1,39 +0,0 @@
----
-id: P-REINFORCE-AUTO-715F80
-category: "[[10_Wiki/💡 Topics/Graphics & Performance]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - OffscreenCanvas"
----
-
-# [[OffscreenCanvas]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> **OffscreenCanvas**는 DOM과 분리된 백그라운드 스레드(웹 워커)에서 그래픽 렌더링을 수행할 수 있게 해주는 웹 API로, 무거운 3D 렌더링이나 캔버스 연산 중에도 메인 스레드의 UI 반응성을 쾌적하게 유지할 수 있도록 돕는 핵심 최적화 기술입니다.
-
-## 📖 구조화된 지식 (Synthesized Content)
-**1. DOM 의존성 분리 및 Web Worker 활용** 기존의 캔버스 렌더링은 `<html>` 문서의 `<canvas>` 요소(DOM)와 직접적으로 결합되어 있어 메인 스레드에서만 실행이 가능했습니다. 하지만 OffscreenCanvas는 이름 그대로 화면 밖(Off-screen)에서 동작하여 DOM과의 동기화 과정을 생략합니다. 이 덕분에 DOM에 접근할 수 없는 웹 워커(Web Worker) 환경에서도 Canvas API와 WebGL을 사용하여 백그라운드 렌더링이 가능해집니다.
-
-**2. 메인 스레드 차단 방지 (Unblocking Main Thread)** 복잡한 Three.js 씬이나 무거운 2D/3D 연산을 메인 스레드에서 실행하면 UI가 멈추는(Freezing) 현상이 발생할 수 있습니다. `transferControlToOffscreen()` 메서드를 호출하여 캔버스의 제어권을 워커 스레드로 넘기면(Offloading), 무거운 그래픽 연산이 메인 스레드(사용자의 스크롤, 클릭 등 상호작용)와 독립적으로 실행되어 시각적인 버벅거림(Jank) 없이 부드러운 애니메이션을 보장합니다.
-
-**3. 이벤트 포워딩(Event Forwarding)과 통신 오버헤드** 웹 워커 내부에는 `window`나 `document` 객체가 존재하지 않으므로 사용자의 마우스 클릭, 터치 등의 이벤트를 직접 수신할 수 없습니다. 따라서 OffscreenCanvas를 인터랙티브하게 사용하려면 메인 스레드에서 DOM 이벤트를 캡처한 뒤, 좌표 등의 정보를 `postMessage` API를 통해 워커로 전달(Forwarding)하는 추가적인 래핑(Wrapping) 작업이 필요합니다.
-
-**4. 상태 동기화 (State Synchronization)** DOM을 제어하는 React 메인 앱과 WebGL을 렌더링하는 워커 스레드는 메모리를 공유하지 않기 때문에 애플리케이션 상태를 양쪽에서 읽고 써야 할 경우 상태 동기화가 필수적입니다. 이를 해결하기 위해 `SharedArrayBuffer`를 통해 메모리를 직접 공유하거나, `Valtio`와 같은 프록시 기반 상태 관리 도구와 `Broadcast Channel API`를 결합하여 변경된 데이터(Delta)만 메시지로 주고받는 구조를 구현해야 합니다.
-
-**5. React 생태계 통합 (React Three Fiber)** R3F 생태계에서는 `@react-three/offscreen` 패키지를 통해 손쉽게 구현할 수 있습니다. 기존의 `<Canvas>` 대신 이 패키지의 `<Canvas worker={worker}>`를 사용하면 이벤트 포워딩과 Three.js 인터페이스 패치 작업이 자동으로 처리되어, 개발자가 작성한 코드를 수정할 필요 없이 워커에서 실행되도록 만들어줍니다.
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Graphics & Performance 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[Web Worker (웹 워커)]], [[Multi-threaded Architecture (멀티스레드 아키텍처)]], [[React Three Fiber (R3F)]], [[Valtio (Proxy State 관리)]], [[SharedArrayBuffer]]
-- **Projects/Contexts:** [[고성능 멀티스레드 React 앱 아키텍처]], [[무거운 렌더링 연산을 동반하는 WebGL 데이터 시각화]]
-- **Contradictions/Notes:** OffscreenCanvas 기능은 과거 Safari 브라우저에서 오랫동안 완벽히 지원되지 않아 프로젝트를 메인 스레드용과 워커용 두 갈래(Fork)로 유지보수해야 하는 치명적인 단점이 있었습니다. 2025년 9월(Safari v26)부터 지원이 확대되었으나, 완벽한 크로스 브라우저 호환성을 위해서는 API 지원 여부를 감지하여 워커를 지원하지 않는 환경에서는 메인 스레드에서 렌더링이 이루어지도록 `fallback` 컴포넌트를 반드시 제공해야 합니다.
-
----
-
-_Last updated: 2026-04-15_
-- Raw Source: [[00_Raw/2026-04-20/OffscreenCanvas.md]]
----
diff --git a/Graphics & Performance/Open Metaverse Framework.md b/Graphics & Performance/Open Metaverse Framework.md
deleted file mode 100644
index 1367e6a1..00000000
--- a/Graphics & Performance/Open Metaverse Framework.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-4C9A2B
-category: "[[10_Wiki/💡 Topics/Graphics & Performance]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Open Metaverse Framework"
----
-
-# [[Open Metaverse Framework]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Graphics & Performance 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Open Metaverse Framework.md]]
----
diff --git a/Graphics & Performance/Open-World Design Paradigms.md b/Graphics & Performance/Open-World Design Paradigms.md
deleted file mode 100644
index fd6464a5..00000000
--- a/Graphics & Performance/Open-World Design Paradigms.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-B36DC4
-category: "[[10_Wiki/💡 Topics/Graphics & Performance]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Open-World Design Paradigms"
----
-
-# [[Open-World Design Paradigms]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Graphics & Performance 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Open-World Design Paradigms.md]]
----
diff --git a/Graphics & Performance/OpenGL ES 20.md b/Graphics & Performance/OpenGL ES 20.md
deleted file mode 100644
index b152d200..00000000
--- a/Graphics & Performance/OpenGL ES 20.md	
+++ /dev/null
@@ -1,32 +0,0 @@
----
-id: P-REINFORCE-AUTO-8560F5
-category: "[[10_Wiki/💡 Topics/Graphics & Performance]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - OpenGL ES 20"
----
-
-# [[OpenGL ES 20]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> OpenGL ES 2.0은 2011년에 도입된 크로스 플랫폼 웹 그래픽 라이브러리인 WebGL의 근간이 되는 그래픽 API입니다 [1, 2]. 이 아키텍처는 전역 그래픽 상태를 설정하고 유지하는 상태 머신(state-machine) 설계를 사용하며, 자바스크립트 코드를 GPU 명령으로 변환하는 역할을 수행합니다 [2, 3].
-
-## 📖 구조화된 지식 (Synthesized Content)
-* **WebGL의 핵심 기반:** WebGL은 OpenGL ES 2.0을 기반으로 구축되어, 웹 브라우저에서 자바스크립트를 이용해 3D 장면을 렌더링할 수 있도록 지원하는 라이브러리입니다 [1, 2].
-* **상태 머신(State-Machine) 모델:** OpenGL ES 2.0에서 상속된 상태 머신 설계를 따라 렌더링을 처리합니다. 바인딩된 텍스처, 활성 셰이더, 블렌드 모드 등의 전역 상태(global state)를 한 번 설정하면 개발자가 이를 명시적으로 변경할 때까지 해당 상태가 지속적으로 유지됩니다 [3].
-* **구조적 한계 및 병목 현상:** 이 아키텍처는 2011년 당시에는 합리적인 구조였으나, 2011년 사양에 기능이 고정되어 있어 현대 GPU의 발전된 기능을 활용할 수 없다는 근본적인 한계를 지닙니다 [3, 4]. 또한 규모가 커질수록 상태 변경을 잊어버려 발생하는 미세한 버그나, 단일 스레드 기반의 명령 제출로 인한 CPU 병목 현상 등을 유발합니다 [3].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Graphics & Performance 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[WebGL]], [[WebGPU]], [[State-machine design]]
-- **Projects/Contexts:** [[Web Graphics Rendering API]], [[3D Web-based HMI]]
-- **Contradictions/Notes:** 소스 내에 직접적인 모순은 없으나, OpenGL ES 2.0 기반의 상태 머신 모델이 개발 초기(2011년)에는 타당한 설계였음에도 불구하고 오늘날의 대규모 그래픽 처리에서는 심각한 버그와 병목 현상의 원인이 되고 있음이 지적됩니다 [3, 4].
-
----
-*Last updated: 2026-04-19*
-- Raw Source: [[00_Raw/2026-04-20/OpenGL ES 2.0.md]]
----
diff --git a/Graphics & Performance/OpenGL ES.md b/Graphics & Performance/OpenGL ES.md
deleted file mode 100644
index bb562acf..00000000
--- a/Graphics & Performance/OpenGL ES.md	
+++ /dev/null
@@ -1,33 +0,0 @@
----
-id: P-REINFORCE-AUTO-D76AA6
-category: "[[10_Wiki/💡 Topics/Graphics & Performance]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - OpenGL ES"
----
-
-# [[OpenGL ES]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> OpenGL ES(특히 OpenGL ES 2.0)는 웹 기반 3D 렌더링을 지원하는 크로스 플랫폼 그래픽 라이브러리인 WebGL의 기반이 되는 그래픽 API입니다 [1, 2]. 텍스처나 셰이더 등의 전역 상태가 한 번 설정되면 변경될 때까지 유지되는 상태 머신(State-machine) 디자인을 채택하고 있습니다 [3]. 2011년경의 사양에 고정되어 있어, 최신 GPU의 고급 기능을 활용하기에는 아키텍처상 근본적인 한계를 지니고 있습니다 [3, 4].
-
-## 📖 구조화된 지식 (Synthesized Content)
-- **WebGL의 기술적 토대:** WebGL은 OpenGL ES 2.0을 기반으로 구축되어 JavaScript 코드를 GPU 명령어로 변환하며, 지난 10년 이상 웹 3D 렌더링의 핵심 역할을 수행해 왔습니다 [1, 2].
-- **작동 방식과 호환성:** OpenGL ES 2.0에서 상속받은 상태 머신(State-machine) 모델을 사용하여 렌더링 상태를 관리합니다 [3]. Windows 환경의 브라우저(Chrome, Firefox, Opera 등)는 ANGLE이라는 기술을 사용하여 WebGL(OpenGL ES) 호출을 Direct3D로 변환하는 방식으로 구동됩니다 [5].
-- **구조적 한계:** WebGL이 OpenGL ES 2.0을 기반으로 설계된 탓에, 기능 세트가 2011년 사양에 묶여 있는 근본적인 한계가 존재합니다 [4]. 이로 인해 최신 GPU의 컴퓨트 셰이더(Compute shader)나 고급 텍스처 포맷 등을 활용할 수 없으며, 규모가 커질수록 전역 상태 관리로 인한 미묘한 버그나 CPU 병목 현상이 발생하기 쉽습니다 [3, 4].
-- **최신 브라우저 동향:** Chrome 146 등의 최신 업데이트에서는 WebGPU가 OpenGL ES 3.1 위에서 호환 모드(compatibility mode)로 동작할 수 있도록 지원하는 기능이 추가되고 있습니다 [6].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Graphics & Performance 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[WebGL]], [[WebGPU]], [[ANGLE]]
-- **Projects/Contexts:** [[3D Web-based HMI]]
-- **Contradictions/Notes:** 소스에 관련 정보가 부족합니다.
-
----
-*Last updated: 2026-04-19*
-- Raw Source: [[00_Raw/2026-04-20/OpenGL ES.md]]
----
diff --git a/Graphics & Performance/Opera.md b/Graphics & Performance/Opera.md
deleted file mode 100644
index d297a163..00000000
--- a/Graphics & Performance/Opera.md	
+++ /dev/null
@@ -1,33 +0,0 @@
----
-id: P-REINFORCE-AUTO-71E521
-category: "[[10_Wiki/💡 Topics/Graphics & Performance]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Opera"
----
-
-# [[Opera]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> Opera는 웹 환경에서 그래픽 및 렌더링 기술을 구동하기 위해 사용되는 웹 브라우저 중 하나입니다. 업로드된 소스에서는 브라우저의 독립적인 특징보다는 WebGL 및 WebGPU와 같은 웹 그래픽 API의 호환성 및 지원 여부를 설명할 때 제한적으로만 언급됩니다. 전반적으로 Opera에 초점을 맞춘 상세한 설명은 존재하지 않으므로 소스에 관련 정보가 부족합니다.
-
-## 📖 구조화된 지식 (Synthesized Content)
-* **ANGLE을 통한 WebGL 변환:** Windows 운영 체제 환경에서 Opera 브라우저는 Chrome, Firefox와 마찬가지로 WebGL(OpenGL ES) 호출을 Direct3D로 변환하기 위해 ANGLE 기술을 사용합니다 [1].
-* **WebGPU 지원 현황:** 2026년 1월 기준으로, Opera는 Chrome, Edge 브라우저와 함께 데스크톱 플랫폼 전반에서 차세대 그래픽 API인 WebGPU를 공식적으로 탑재하여(ship) 지원하고 있습니다 [2].
-* **`EXT_disjoint_timer_query` 확장 기능 호환성:** WebGL 렌더링 파이프라인을 지연시키지 않고 GL 명령의 실행 시간을 측정하는 `EXT_disjoint_timer_query` 기능에 대해, 데스크톱용 Opera(버전 57 이상)는 부분적인 지원(Partial support)을 제공합니다 [3, 4]. 그러나 모바일 환경인 Opera Android(버전 34-46)에서는 해당 기능을 지원하지 않는 것으로 확인됩니다 [4].
-* **한계:** Opera 브라우저의 전반적인 아키텍처나 기능에 대해서는 소스에 관련 정보가 부족합니다.
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Graphics & Performance 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[WebGL]], [[WebGPU]], [[ANGLE]]
-- **Projects/Contexts:** [[웹 브라우저 그래픽 API 호환성]]
-- **Contradictions/Notes:** 데스크톱 Opera는 특정 WebGL 확장 기능(`EXT_disjoint_timer_query`)을 부분적으로나마 지원하지만, 모바일(Android) 버전의 Opera에서는 해당 기능이 전혀 지원되지 않는 등 플랫폼에 따른 지원 격차가 존재합니다 [4].
-
----
-*Last updated: 2026-04-19*
-- Raw Source: [[00_Raw/2026-04-20/Opera.md]]
----
diff --git a/Graphics & Performance/Operant Conditioning.md b/Graphics & Performance/Operant Conditioning.md
deleted file mode 100644
index 4c96f36c..00000000
--- a/Graphics & Performance/Operant Conditioning.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-8BF017
-category: "[[10_Wiki/💡 Topics/Graphics & Performance]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Operant Conditioning"
----
-
-# [[Operant Conditioning]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Graphics & Performance 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Operant Conditioning.md]]
----
diff --git a/Graphics & Performance/PBR.md b/Graphics & Performance/PBR.md
deleted file mode 100644
index 7ced945b..00000000
--- a/Graphics & Performance/PBR.md	
+++ /dev/null
@@ -1,37 +0,0 @@
----
-id: P-REINFORCE-AUTO-773FEF
-category: "[[10_Wiki/💡 Topics/Graphics & Performance]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - PBR"
----
-
-# [[PBR]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> PBR(Physically-Based Rendering)은 현실 세계의 물질 물리 법칙을 적용하여 사실적인 시각 효과를 달성하는 렌더링 방법론입니다 [1]. 알베도(albedo), 노멀(normal), 메탈릭(metallic), 러프니스(roughness), 앰비언트 오클루전(ambient occlusion) 등의 다중 텍스처 맵을 조합하여 표면 속성을 세밀하게 정의합니다 [2]. 사실감을 표현하는 최신 표준 기술이지만, 에너지 보존 법칙과 프레넬(Fresnel) 반사 등의 복잡한 계산을 수반하기 때문에 그래픽 연산 비용이 매우 높다는 특징이 있습니다 [3].
-
-## 📖 구조화된 지식 (Synthesized Content)
-*   **물리 기반 속성 정의와 워크플로우:** 
-    PBR은 주로 메탈릭-러프니스 워크플로우를 기반으로 실제와 같은 재질을 표현합니다. 표면의 금속성을 정의하는 메탈릭 맵과 표면 미세 구조의 거칠기를 정의하는 러프니스 맵을 통해 물리적 정확도를 확보합니다 [1, 3]. 
-
-*   **높은 연산 비용과 성능 병목:** 
-    풀(Full) PBR 재질을 환경 반사와 함께 렌더링할 경우, 눈에 보이는 픽셀마다 15~20개의 텍스처 샘플링과 수십 번의 수학적 연산이 요구됩니다 [2]. Three.js에서 PBR을 구현한 `MeshStandardMaterial`은 가장 컴퓨팅 비용이 높은 재질로, 내장된 그래픽 하드웨어(예: Intel UHD) 환경에서 100만 개 이상의 삼각형을 처리할 때 프래그먼트 프로세서를 포화시켜 프레임 속도를 30 FPS 이하로 떨어뜨릴 수 있습니다 [3, 4].
-
-*   **PBR 최적화 기법 (텍스처 채널 패킹):** 
-    메모리 대역폭의 한계를 극복하기 위해 텍스처 채널 패킹(Texture Channel Packing) 기술이 사용됩니다 [1]. 메탈릭 값을 블루(B) 채널에, 러프니스 값을 그린(G) 채널에 저장하여 여러 장의 텍스처를 하나로 병합합니다 [1]. 이렇게 5개의 개별 텍스처를 3개(알베도-알파, 노멀, 메탈릭-러프니스 결합)로 줄인 간소화된 PBR 셰이더를 사용하면 텍스처 대역폭 요구량을 50%까지 감소시키면서도 PBR의 정확도를 온전히 유지할 수 있습니다 [1, 5].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Graphics & Performance 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[MeshStandardMaterial]], [[Texture Channel Packing]], [[Metallic Maps]], [[Roughness Maps]]
-- **Projects/Contexts:** [[Three.js 웹 렌더링 최적화]], [[Image-To-3D 모델 브라우저 배포]]
-- **Contradictions/Notes:** PBR 방식(예: MeshStandardMaterial)은 궁극적인 사실주의를 제공하지만 연산 비용이 높아 고사양 워크스테이션에 적합합니다. 저사양이나 내장 그래픽(iGPU) 환경에서 성능을 우선시해야 할 경우에는 상대적으로 연산량이 적은 비물리 기반의 Blinn-Phong 모델(예: MeshPhongMaterial)을 사용하는 것이 더 나을 수 있습니다 [3, 4].
-
----
-*Last updated: 2026-04-19*
-- Raw Source: [[00_Raw/2026-04-20/PBR.md]]
----
diff --git a/Graphics & Performance/Perlin Noise.md b/Graphics & Performance/Perlin Noise.md
deleted file mode 100644
index ef50da18..00000000
--- a/Graphics & Performance/Perlin Noise.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-0374D8
-category: "[[10_Wiki/💡 Topics/Graphics & Performance]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Perlin Noise"
----
-
-# [[Perlin Noise]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Graphics & Performance 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Perlin Noise.md]]
----
diff --git a/Graphics & Performance/Physics Engine Integration.md b/Graphics & Performance/Physics Engine Integration.md
deleted file mode 100644
index 940fc8e4..00000000
--- a/Graphics & Performance/Physics Engine Integration.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-DE2C95
-category: "[[10_Wiki/💡 Topics/Graphics & Performance]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Physics Engine Integration"
----
-
-# [[Physics Engine Integration]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Graphics & Performance 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Physics Engine Integration.md]]
----
diff --git a/Graphics & Performance/Positive Psychology.md b/Graphics & Performance/Positive Psychology.md
deleted file mode 100644
index 1853d339..00000000
--- a/Graphics & Performance/Positive Psychology.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-52AEE2
-category: "[[10_Wiki/💡 Topics/Graphics & Performance]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Positive Psychology"
----
-
-# [[Positive Psychology]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Graphics & Performance 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Positive Psychology.md]]
----
diff --git a/Graphics & Performance/Positive-Psychology.md b/Graphics & Performance/Positive-Psychology.md
deleted file mode 100644
index c6cc997d..00000000
--- a/Graphics & Performance/Positive-Psychology.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-88BB17
-category: "[[10_Wiki/💡 Topics/Graphics & Performance]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Positive-Psychology"
----
-
-# [[Positive-Psychology]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Graphics & Performance 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Positive-Psychology.md]]
----
diff --git a/Graphics & Performance/Post-Acute-Care-Models.md b/Graphics & Performance/Post-Acute-Care-Models.md
deleted file mode 100644
index ff0a04fd..00000000
--- a/Graphics & Performance/Post-Acute-Care-Models.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-D22D50
-category: "[[10_Wiki/💡 Topics/Graphics & Performance]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Post-Acute-Care-Models"
----
-
-# [[Post-Acute-Care-Models]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Graphics & Performance 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Post-Acute-Care-Models.md]]
----
diff --git a/Graphics & Performance/Post-humanism.md b/Graphics & Performance/Post-humanism.md
deleted file mode 100644
index 4e69ecb2..00000000
--- a/Graphics & Performance/Post-humanism.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-1C09D2
-category: "[[10_Wiki/💡 Topics/Graphics & Performance]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Post-humanism"
----
-
-# [[Post-humanism]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Graphics & Performance 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Post-humanism.md]]
----
diff --git a/Graphics & Performance/Probabilistic-Graphical-Models.md b/Graphics & Performance/Probabilistic-Graphical-Models.md
deleted file mode 100644
index e36341a1..00000000
--- a/Graphics & Performance/Probabilistic-Graphical-Models.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-A9AAF3
-category: "[[10_Wiki/💡 Topics/Graphics & Performance]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Probabilistic-Graphical-Models"
----
-
-# [[Probabilistic-Graphical-Models]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Graphics & Performance 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Probabilistic-Graphical-Models.md]]
----
diff --git a/Graphics & Performance/Problem-Solving-Theory.md b/Graphics & Performance/Problem-Solving-Theory.md
deleted file mode 100644
index 3572da86..00000000
--- a/Graphics & Performance/Problem-Solving-Theory.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-7E994F
-category: "[[10_Wiki/💡 Topics/Graphics & Performance]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Problem-Solving-Theory"
----
-
-# [[Problem-Solving-Theory]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Graphics & Performance 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Problem-Solving-Theory.md]]
----
diff --git a/Graphics & Performance/Procedural-Animation.md b/Graphics & Performance/Procedural-Animation.md
deleted file mode 100644
index 08e178a6..00000000
--- a/Graphics & Performance/Procedural-Animation.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-737A68
-category: "[[10_Wiki/💡 Topics/Graphics & Performance]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Procedural-Animation"
----
-
-# [[Procedural-Animation]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Graphics & Performance 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Procedural-Animation.md]]
----
diff --git a/Graphics & Performance/R3F 3D 게임 환경의 메모리 관리.md b/Graphics & Performance/R3F 3D 게임 환경의 메모리 관리.md
deleted file mode 100644
index d1dba4a3..00000000
--- a/Graphics & Performance/R3F 3D 게임 환경의 메모리 관리.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-7C6FD2
-category: "[[10_Wiki/💡 Topics/Graphics & Performance]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - R3F 3D 게임 환경의 메모리 관리"
----
-
-# [[R3F 3D 게임 환경의 메모리 관리]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Graphics & Performance 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/R3F 3D 게임 환경의 메모리 관리.md]]
----
diff --git a/Graphics & Performance/RDF와 OWL.md b/Graphics & Performance/RDF와 OWL.md
deleted file mode 100644
index 58764dba..00000000
--- a/Graphics & Performance/RDF와 OWL.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-58CF7B
-category: "[[10_Wiki/💡 Topics/Graphics & Performance]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - RDF와 OWL"
----
-
-# [[RDF와 OWL]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Graphics & Performance 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/RDF와 OWL.md]]
----
diff --git a/Graphics & Performance/Radix Sort.md b/Graphics & Performance/Radix Sort.md
deleted file mode 100644
index 65f96bde..00000000
--- a/Graphics & Performance/Radix Sort.md	
+++ /dev/null
@@ -1,33 +0,0 @@
----
-id: P-REINFORCE-AUTO-846BA8
-category: "[[10_Wiki/💡 Topics/Graphics & Performance]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Radix Sort"
----
-
-# [[Radix Sort]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> Radix Sort(기수 정렬)는 대규모 데이터 세트를 처리할 때 매우 높은 효율을 낼 수 있는 복잡한 정렬 알고리즘입니다 [1]. Three.js의 `BatchedMesh`에서 겹치는 인스턴스의 렌더링 순서(Depth sorting)를 해결하기 위해 사용된 적이 있으나 단순성을 위해 대체되었으며, 현재는 확장 라이브러리인 `InstancedMesh2`의 예제 등에서 활용되고 있습니다 [1, 2].
-
-## 📖 구조화된 지식 (Synthesized Content)
-- **성능 이점:** 대규모 데이터 세트를 정렬해야 하는 상황에서 다른 정렬 방식에 비해 최대 7배가량 빠른 성능을 제공할 수 있습니다 [1].
-- **Three.js 생태계에서의 활용 및 제외:** `BatchedMesh`는 여러 인스턴스가 겹칠 때 발생할 수 있는 시각적 오류를 방지하고자 심도 정렬(Depth sorting)을 구현하는 데 Radix Sort 알고리즘을 사용했습니다 [1, 2]. 하지만 코드 구현의 단순성을 위해 현재는 이보다 간단한 알고리즘으로 대체되었습니다 [1].
-- **InstancedMesh2에서의 제공:** 공식 `BatchedMesh`에서는 제외되었으나, 이를 기반으로 개발된 `InstancedMesh2` 라이브러리에서는 여전히 Radix Sort를 활용한 인스턴스 정렬 예제를 제공하고 있습니다 [1].
-- **한계:** Radix Sort 알고리즘 고유의 구체적인 동작 방식이나 기술적 메커니즘에 대해서는 소스에 관련 정보가 부족합니다.
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Graphics & Performance 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[BatchedMesh]], [[InstancedMesh2]]
-- **Projects/Contexts:** [[Three.js]], [[Depth Sorting]]
-- **Contradictions/Notes:** Radix Sort는 대규모 데이터에서 7배 빠른 성능을 제공하는 훌륭한 장점이 있음에도 불구하고, 공식 `BatchedMesh`에서는 라이브러리 내부 구조의 단순성(simplicity)을 유지하기 위해 제거되었다는 특징이 있습니다 [1]. 그 외 알고리즘 작동 원리에 대해서는 소스에 관련 정보가 부족합니다.
-
----
-*Last updated: 2026-04-19*
-- Raw Source: [[00_Raw/2026-04-20/Radix Sort.md]]
----
diff --git a/Graphics & Performance/Raycaster.md b/Graphics & Performance/Raycaster.md
deleted file mode 100644
index d6b0ddd9..00000000
--- a/Graphics & Performance/Raycaster.md	
+++ /dev/null
@@ -1,33 +0,0 @@
----
-id: P-REINFORCE-AUTO-D7A57A
-category: "[[10_Wiki/💡 Topics/Graphics & Performance]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Raycaster"
----
-
-# [[Raycaster]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> Raycaster(레이캐스터)는 가상의 광선(Ray)과 3D 장면 내 객체 간의 교차점을 계산하여 충돌을 감지하는 기법이자 Three.js의 핵심 클래스(`THREE.Raycaster`)입니다 [1-3]. 주로 마우스 클릭과 같은 사용자 상호작용(오브젝트 피킹)을 구현하여 카메라 시점이나 특정 위치에서 어떤 객체가 선택되었는지 판별하는 데 필수적으로 사용됩니다 [4-6].
-
-## 📖 구조화된 지식 (Synthesized Content)
-- **동작 원리 및 사용법:** Raycaster는 시작점과 방향을 명시적으로 지정하거나(`raycaster.set`), 화면의 픽셀 좌표와 카메라를 기준으로 광선을 설정(`raycaster.setFromCamera`)하여 작동합니다 [3, 5]. 이후 `intersectObjects` 메서드를 통해 광선과 교차하는 대상들을 거리가 가까운 순서대로 정렬된 배열 형태로 반환받을 수 있으며, 반환된 데이터에는 교차한 객체(`.object`)와 월드 좌표계 기준의 교차점(`.point`) 정보가 포함됩니다 [6, 7].
-- **InstancedMesh 적용 시의 한계와 병목:** 일반적인 메쉬의 레이캐스팅은 CPU 단에서 수행되는데, `InstancedMesh`의 경우 수많은 인스턴스의 변환 행렬을 CPU가 개별적으로 역산하여 교차 여부를 판별해야 하므로 인스턴스 수에 비례하여 막대한 연산 병목이 발생합니다 [8]. 특히 애니메이션이나 기하학적 변환이 GPU 셰이더 내에서만 연산된 경우, CPU 레이캐스터는 변환된 위치를 알지 못해 객체의 초기 위치만 검사하게 되며 이는 피킹 불가능 상태인 '데이터 불일치'를 유발합니다 [8, 9].
-- **인스턴스 변환 시 바운딩 볼륨 업데이트:** Three.js r151 버전 이후부터 `InstancedMesh`는 바운딩 볼륨 연산을 지원합니다 [10]. 런타임에 인스턴스의 위치나 형태를 변환한 후 레이캐스팅이 정상적으로 작동하게 하려면, `computeBoundingSphere()` 및 `computeBoundingBox()`를 반드시 호출해야 합니다 [10-12]. 레이캐스터가 연산 최적화를 위해 바운딩 볼륨을 이용한 빠른 사전 테스트(early-out testing)를 거치기 때문입니다 [12].
-- **성능 최적화 (BVH 도입):** 80,000개 이상의 다각형을 갖는 복잡한 장면이나 잦은 레이캐스팅이 필요한 환경에서는 기본 Raycaster만으로는 성능을 보장하기 어렵습니다 [13, 14]. 이를 해결하기 위해 공간 분할 트리 알고리즘을 구현한 `three-mesh-bvh` 라이브러리를 사용하면 레이캐스팅 속도를 비약적으로 향상시킬 수 있으며, 확장 라이브러리인 `InstancedMesh2`도 빠른 레이캐스팅을 위해 BVH를 적극적으로 활용합니다 [13, 15-17].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Graphics & Performance 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[Three.js]], [[InstancedMesh]], [[three-mesh-bvh]], [[Bounding Volume]]
-- **Projects/Contexts:** [[3D Object Picking]], [[Interaction in WebGL]]
-- **Contradictions/Notes:** 소스에 따르면 레이캐스팅은 CPU 기반 연산이므로, GPU 셰이더(Compute Shader 등)를 통해 동적으로 애니메이션 처리된 기하학적 구조에 대해서는 CPU가 변환을 알지 못해 기본 레이캐스터로 올바른 피킹을 수행할 수 없습니다 [8, 9].
-
----
-*Last updated: 2026-04-19*
-- Raw Source: [[00_Raw/2026-04-20/Raycaster.md]]
----
diff --git a/Graphics & Performance/Raycasting.md b/Graphics & Performance/Raycasting.md
deleted file mode 100644
index e37cff15..00000000
--- a/Graphics & Performance/Raycasting.md	
+++ /dev/null
@@ -1,43 +0,0 @@
----
-id: P-REINFORCE-AUTO-BD8B44
-category: "[[10_Wiki/💡 Topics/Graphics & Performance]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Raycasting"
----
-
-# [[Raycasting]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> Raycasting(레이캐스팅)은 가상의 광선(Ray)과 3D 환경 내 객체들 간의 교차점을 감지하는 계산 기법입니다 [1, 2]. 3D 씬 내에서 사용자가 화면을 클릭하여 특정 객체를 선택(Picking)하거나 드래그하는 등의 사용자 상호작용(Interaction)을 구현할 때 필수적으로 사용됩니다 [3-5]. Three.js 환경에서는 `THREE.Raycaster` 클래스를 통해 이 기능을 수행할 수 있습니다 [2, 3].
-
-## 📖 구조화된 지식 (Synthesized Content)
-*   **기본 작동 원리**
-    *   Raycaster는 시작점(주로 카메라)에서 특정 방향으로 무한히 뻗어가는 광선을 사용합니다 [2]. 카메라와 화면 좌표(마우스 클릭 위치 등)를 기반으로 광선을 설정할 수 있습니다 [6].
-    *   `intersectObjects` 메서드를 호출하면 광선과 교차하는 객체들의 배열을 거리순으로 반환합니다. 반환된 항목에는 교차된 대상 객체(`item.object`)와 세계 좌표계 기준의 정확한 교차 지점(`item.point`) 정보가 포함됩니다 [7-10].
-*   **성능 최적화 기법 (BVH 도입)**
-    *   복잡한 지오메트리를 상대로 반복적인 레이캐스팅을 수행하면 성능 저하가 발생할 수 있습니다. 
-    *   이를 해결하기 위해 공간 분할 구조인 `three-mesh-bvh`(Bounding Volume Hierarchy) 라이브러리를 활용하면, 80,000개 이상의 폴리곤에 대해서도 60fps로 매우 빠른 레이캐스팅(Fast Raycasting) 쿼리를 수행할 수 있습니다 [11-13].
-*   **InstancedMesh 환경에서의 제약 및 고려사항**
-    *   `InstancedMesh`는 네이티브 레이캐스터를 지원하지만, 초기에는 모든 인스턴스 멤버의 모든 삼각형을 검사해야 하여 성능상 한계가 있었습니다 [14, 15]. 
-    *   Three.js r151 버전 이후부터는 바운딩 볼륨(Bounding Volume)을 통한 빠른 조기 종료(Early-out) 테스트를 지원하여 속도가 개선되었습니다 [16, 17]. 그러나 인스턴스를 이동시키는 등 변환이 발생한 후에는 반드시 `computeBoundingSphere()`와 `computeBoundingBox()`를 수동으로 재계산해주어야 레이캐스팅이 정상 작동합니다 [16, 18].
-    *   일부 커스텀 구현(예: A-Frame용 컴포넌트)에서는 유연성과 성능 확보를 위해 `InstancedMesh` 자체에 대한 직접적인 레이캐스팅 대신, 동일한 형태의 보이지 않는 메시(Invisible Mesh)를 멤버별로 생성하여 레이캐스팅의 타겟으로 삼는 우회법을 사용하기도 합니다 [15, 19, 20].
-*   **셰이더 애니메이션과의 충돌**
-    *   애니메이션과 위치 변환이 CPU를 거치지 않고 GPU 셰이더 내부에서 독자적으로 계산되는 경우, CPU는 객체의 최종 변환 상태를 알지 못합니다. 이로 인해 CPU 기반의 레이캐스팅 연산이 불가능해지거나 오작동할 수 있습니다 [14, 21].
-*   **대안 기술 (GPU Picking)**
-    *   복잡한 연산이 필요한 레이캐스팅의 대안으로, 객체의 고유 ID를 색상으로 화면 밖(Off-screen) 픽셀 버퍼에 그린 뒤 렌더링된 픽셀 색상을 읽어 객체를 식별하는 'GPU 피킹(Color-based Picking)' 기술도 존재합니다 [22, 23].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Graphics & Performance 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[THREE.Raycaster]], [[Bounding Volume Hierarchy (BVH)]], [[InstancedMesh]], [[GPU Picking]]
-- **Projects/Contexts:** [[3D 사용자 상호작용 및 마우스 피킹 (Picking)]] 구현, [[three-mesh-bvh]] 라이브러리 연동
-- **Contradictions/Notes:** `InstancedMesh`를 사용할 때 GPU 성능 이점은 크지만, 각 인스턴스마다 CPU 기반 레이캐스팅을 처리하거나 개별 정밀도를 조작하는 데는 유연성이 떨어집니다 [15]. 또한 셰이더로 지오메트리를 변경하면 CPU 레이캐스팅과 데이터 불일치가 발생하므로 설계 시 주의가 필요합니다 [21].
-
----
-*Last updated: 2026-04-19*
-- Raw Source: [[00_Raw/2026-04-20/Raycasting.md]]
----
diff --git a/Graphics & Performance/React 19 Compiler의 Threejs 런타임 성능 개선 원리.md b/Graphics & Performance/React 19 Compiler의 Threejs 런타임 성능 개선 원리.md
deleted file mode 100644
index 63b9f7a5..00000000
--- a/Graphics & Performance/React 19 Compiler의 Threejs 런타임 성능 개선 원리.md	
+++ /dev/null
@@ -1,37 +0,0 @@
----
-id: P-REINFORCE-AUTO-777FEC
-category: "[[10_Wiki/💡 Topics/Graphics & Performance]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - React 19 Compiler의 Threejs 런타임 성능 개선 원리"
----
-
-# [[React 19 Compiler의 Threejs 런타임 성능 개선 원리]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> React 19 컴파일러는 빌드 타임에 코드의 값, 컴포넌트, 콜백 함수를 자동으로 메모이제이션하여 잦은 가비지 컬렉션(GC)과 불필요한 리렌더링을 차단함으로써, React Three Fiber(R3F) 기반 3D 게임의 프레임 레이트(FPS)를 안정화하고 런타임 성능을 획기적으로 개선합니다.
-
-## 📖 구조화된 지식 (Synthesized Content)
-**1. 자동 참조 안정성(Reference Stability) 확보를 통한 리렌더링 방지** React 환경에서는 부모 컴포넌트의 상태가 변할 때마다 하위 컴포넌트들이 기본적으로 모두 리렌더링됩니다. 특히 인라인 함수나 객체가 매 렌더링마다 새로운 참조(Reference)를 생성하면, 하위에 있는 무거운 3D 컴포넌트(Mesh, Material 등)가 불필요하게 렌더링을 반복하게 됩니다. React 19 컴파일러는 `useMemo`나 `useCallback` 없이도 안전한 모든 곳에 메모이제이션을 자동 적용하여 참조 안정성을 확보해 주므로, 무거운 3D 객체의 무의미한 재생성을 막아줍니다.
-
-**2. 가비지 컬렉션(GC) 스파이크 억제** 실시간 3D 게임에서 가장 치명적인 성능 저하 원인 중 하나는 단기간에 수많은 객체가 생성되고 버려지면서 발생하는 가비지 컬렉션 멈춤(Stop-the-world) 현상입니다. 컴파일러가 연산 결과와 콜백 함수를 자동으로 캐싱하면 렌더링마다 버려지는 객체의 생성이 크게 줄어들어, 메모리 파편화 및 GC로 인한 프레임 드랍(Lag)을 효과적으로 억제할 수 있습니다.
-
-**3. 재조정(Reconciliation) 오버헤드 감소로 메인 스레드 확보** React의 가상 DOM 트리를 비교하는 재조정(Reconciliation) 과정은 CPU 연산 비용이 높습니다. 컴파일러 적용 시 순수 컴포넌트의 90% 이상, 연산 값의 85% 이상이 자동으로 캐싱되어 렌더링 소요 시간이 단축됩니다. 덕분에 메인 스레드의 부하가 줄어들어, 게임 루프가 물리 엔진 연산이나 렌더링 로직 처리에 더 많은 자원을 온전히 사용할 수 있게 됩니다.
-
-**4. 수동 최적화의 한계 및 휴먼 에러 극복** 과거에는 복잡한 3D 씬을 구성할 때 개발자가 직접 모든 의존성 배열을 관리하며 수동으로 메모이제이션을 해야 했고, 이 과정에서 실수가 발생하기 쉬웠습니다. 컴파일러는 이러한 보일러플레이트 코드를 제거하고 빌드 타임에 최적화를 보장하므로, 개발자는 미세한 메모이제이션에 신경 쓰는 대신 Three.js 씬 그래프 최적화 등 근본적인 엔진 아키텍처에 더 집중할 수 있습니다.
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Graphics & Performance 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[React 19 Compiler]], [[React Three Fiber (R3F)]], [[가비지 컬렉션(GC) 최적화]], [[불필요한 리렌더링 방지]]
-- **Projects/Contexts:** [[고성능 실시간 상호작용 시스템을 위한 React 기반 게임 엔진 아키텍처]]
-- **Contradictions/Notes:** React 19 컴파일러가 선언적 UI의 리렌더링 성능을 비약적으로 높여주지만, 게임의 근본적인 안티 패턴까지 해결해 주지는 않습니다. 예를 들어, 매 프레임 실행되는 `useFrame` 루프 내부에서 React 상태(`setState`)를 업데이트하거나 객체를 새로 생성(`new Vector3()`)하는 것은 여전히 치명적입니다. 빈번하게 변하는 3D 객체의 위치나 회전값 등은 컴파일러에 의존할 것이 아니라, 반드시 참조(Ref)를 사용하여 직접 변형(Direct Mutation)해야 합니다.
-
----
-
-_Last updated: 2026-04-15_
-- Raw Source: [[00_Raw/2026-04-20/React 19 Compiler의 Three.js 런타임 성능 개선 원리.md]]
----
diff --git a/Graphics & Performance/React Three Fiber (R3F).md b/Graphics & Performance/React Three Fiber (R3F).md
deleted file mode 100644
index bad68b0c..00000000
--- a/Graphics & Performance/React Three Fiber (R3F).md	
+++ /dev/null
@@ -1,33 +0,0 @@
----
-id: P-REINFORCE-AUTO-979529
-category: "[[10_Wiki/💡 Topics/Graphics & Performance]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - React Three Fiber (R3F)"
----
-
-# [[React Three Fiber (R3F)]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> React Three Fiber(R3F)는 Three.js에 React의 렌더링 패러다임과 멘탈 모델을 더해주는 라이브러리입니다 [1]. WebGPU와 같은 최신 렌더링 기술을 지원하며 비동기 `gl` prop 팩토리를 통해 원활하게 통합할 수 있어 건축 대시보드와 같은 환경에서 유용하게 사용됩니다 [2]. 하지만 React 특유의 상태 기반 렌더링 방식으로 인해 고유한 성능 문제(pitfalls)가 발생할 수 있으므로 렌더링과 메모리 관리에 세심한 주의가 필요합니다 [1].
-
-## 📖 구조화된 지식 (Synthesized Content)
-- **상태 관리 및 애니메이션 루프:** R3F에서 성능을 최적화하기 위한 핵심 규칙은 Three.js의 변이(mutation)를 React의 상태 변경(`setState`)이 아닌 `useFrame` 내부에서 처리하는 것입니다 [1]. 프레임 속도에 독립적인 움직임을 구현하려면 `delta` 값을 사용해야 하며, 가비지 컬렉션(GC)을 유발하는 객체 생성 작업은 절대 `useFrame` 내부에서 수행해서는 안 됩니다 [1, 3].
-- **렌더링 횟수 제어:** 애니메이션이 없는 정적인 씬에서는 `frameloop="demand"` 옵션을 사용하여 매 프레임 렌더링되는 것을 방지함으로써 리소스(모바일의 경우 배터리)를 절약할 수 있습니다 [1]. 필요한 경우에만 렌더링을 갱신하려면 수동으로 `invalidate()` 함수를 호출해야 합니다 [1].
-- **컴포넌트 최적화 및 자원 관리:** 불필요한 리렌더링을 방지하기 위해 비용이 많이 드는 컴포넌트는 `React.memo`로 감싸는 것이 좋습니다 [3]. 또한, 컴포넌트를 완전히 언마운트했다가 다시 마운트하면 버퍼가 재생성되고 셰이더가 다시 컴파일되는 비용이 발생하므로, 대신 가시성(visibility)을 토글하는 방식이 권장됩니다 [3]. React 컴포넌트가 언마운트될 때는 클린업(cleanup) 함수를 사용하여 메모리에 남은 GPU 자원을 폐기해야 합니다 [4].
-- **에셋 로딩 및 생태계 활용:** R3F는 React Suspense와 원활하게 통합되어 렌더링 지연을 관리할 수 있으며 [5], `useGLTF.preload`를 통해 모델이 필요하기 전에 미리 로드할 수 있습니다 [3]. 복잡한 구현 없이 LOD(Level of Detail)를 적용하려면 Drei 라이브러리의 `<Detailed />` 컴포넌트를 사용하고 [3, 6], 드롭인(drop-in) 성능 모니터링을 위해서는 `r3f-perf`를 활용할 수 있습니다 [3]. 정적 씬의 런타임 라이트맵 베이킹에는 `@react-three/lightmap`을 사용할 수 있습니다 [7].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Graphics & Performance 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[Three.js]], [[WebGPU]], [[Drei]]
-- **Projects/Contexts:** [[React-based construction dashboards]]
-- **Contradictions/Notes:** 소스 내에서 상충되는 주장은 없으나, R3F가 React 기반임에도 불구하고 렌더링 루프 최적화를 위해 React의 핵심 패턴 중 하나인 상태 변경(`setState`)을 `useFrame` 안에서 피하라고 경고하는 등 [1] 패러다임 간의 조율이 필요하다는 점을 강조합니다.
-
----
-*Last updated: 2026-04-19*
-- Raw Source: [[00_Raw/2026-04-20/React Three Fiber (R3F).md]]
----
diff --git a/Graphics & Performance/React Three Fiber 자산 최적화 (Asset Optimization).md b/Graphics & Performance/React Three Fiber 자산 최적화 (Asset Optimization).md
deleted file mode 100644
index f4748777..00000000
--- a/Graphics & Performance/React Three Fiber 자산 최적화 (Asset Optimization).md	
+++ /dev/null
@@ -1,50 +0,0 @@
----
-id: P-REINFORCE-AUTO-C16818
-category: "[[10_Wiki/💡 Topics/Graphics & Performance]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - React Three Fiber 자산 최적화 (Asset Optimization)"
----
-
-# [[React Three Fiber 자산 최적화 (Asset Optimization)]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> React Three Fiber(R3F) 환경에서 3D 모델(GLTF), 텍스처 등의 자산 크기를 대폭 줄이고, GPU 메모리 점유를 최소화하며 초기 로딩 속도와 렌더링 성능을 극대화하기 위한 압축 및 파이프라인 관리 기법입니다.
-
-## 📖 구조화된 지식 (Synthesized Content)
-**1. GLTF/GLB 포맷 사용 및 JSX 변환** 웹 3D 생태계의 표준인 GLTF 혹은 바이너리 형태인 GLB 포맷을 최우선으로 사용합니다. GLB는 지오메트리, 재질, 텍스처, 애니메이션을 하나의 파일로 압축하여 로딩 속도가 빠릅니다. 또한 `@react-three/gltfjsx` 도구를 활용하면 GLTF 모델을 재사용 및 제어 가능한 React JSX 컴포넌트로 자동 변환하여 효율적으로 관리할 수 있습니다.
-
-**2. Draco 및 Meshopt를 통한 지오메트리 압축**
-
-- **Draco:** Google의 Draco 압축을 사용하면 지오메트리 파일 크기를 **90~95%까지 획기적으로 감소**시킬 수 있습니다. 압축 해제는 메인 스레드 차단을 막기 위해 웹 워커(Web Worker)에서 비동기적으로 수행됩니다.
-- **Meshopt:** Draco와 유사한 압축률을 제공하면서도 압축 해제 속도가 더 빠를 수 있는 대안이므로 프로젝트 환경에 맞춰 선택적으로 테스트해 적용할 수 있습니다.
-
-**3. KTX2 기반 텍스처 압축 (GPU 메모리 최적화)** 일반적인 PNG나 JPEG 이미지는 파일 크기가 작더라도 VRAM(GPU 메모리)에 올라갈 때 압축이 완전히 풀려 막대한 메모리(예: 200KB PNG가 20MB 이상의 VRAM 차지)를 소모합니다. 반면 **KTX2(Basis Universal) 형식은 GPU 내에서도 압축된 상태를 유지하여 VRAM 메모리 사용량을 약 10배 줄여줍니다**.
-
-- **UASTC:** 고품질이 필요한 노멀 맵(Normal Map)이나 주요 텍스처에 사용합니다.
-- **ETC1S:** 파일 크기 절감이 중요한 환경 맵이나 보조 에셋에 사용합니다.
-
-**4. LOD (Level of Detail) 구현** 카메라와의 거리에 따라 모델의 디테일을 조절하여 렌더링 부하를 줄입니다. `@react-three/drei` 라이브러리의 `<Detailed>` 컴포넌트를 사용하면, 거리에 맞춰 High-poly 모델과 Low-poly 모델이 자동으로 스왑(Swap)되어 대규모 씬에서 프레임 레이트를 30~40% 향상시킬 수 있습니다.
-
-**5. 사전 로딩(Preloading)과 점진적 로딩(Progressive Loading)**
-
-- **프리로딩:** 씬이 화면에 나타나기 전에 `useGLTF.preload('/model.glb')`를 호출하여 렌더링 지연(Pop-in)을 방지합니다.
-- **점진적 로딩 / Suspense:** 로딩 시간이 길어질 수 있는 거대한 모델의 경우, React의 `<Suspense fallback={<Loader />}>`를 활용해 우선 가벼운 플레이스홀더(스켈레톤 지오메트리나 저해상도 모델)를 즉시 띄워두고 백그라운드에서 고해상도 에셋을 불러오도록 처리합니다.
-
-**6. 텍스처 아틀라싱(Texture Atlasing) 및 메시 병합** 여러 개의 텍스처를 하나의 큰 이미지 맵(Atlas)으로 합치거나, 동일한 재질을 공유하는 여러 정적 메시(Mesh)를 하나로 병합(Merge)하여 **드로우 콜(Draw Call)과 텍스처 바인딩 횟수를 최소화**해야 모바일 기기에서도 원활한 성능을 보장할 수 있습니다.
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Graphics & Performance 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[Code Splitting & Lazy Loading]], [[Draw Call Optimization (드로우 콜 최적화)]], [[Memory Leak Prevention (메모리 누수 방지)]], [[웹 워커(Web Worker)]]
-- **Projects/Contexts:** [[대규모 WebGL/R3F 3D 쇼핑몰 제품 컨피규레이터]], [[모바일 환경을 타겟으로 하는 웹 기반 3D 게임]]
-- **Contradictions/Notes:** 지오메트리나 텍스처를 과도하게 압축(Draco, KTX2)하면 다운로드되는 파일 크기와 GPU 메모리는 대폭 줄어들지만, 클라이언트의 웹 워커에서 이를 압축 해제(Decompression)하는 과정에서 CPU 연산 비용과 디코더 로딩 지연이 발생합니다. 따라서, 복잡도가 낮고 빠른 즉각적 렌더링이 필요한 에셋의 경우 오히려 압축 없이 원본을 사용하는 것이 TTI(Time to Interactive) 면에서 더 유리할 수도 있으므로 Trade-off를 고려해야 합니다.
-
----
-
-_Last updated: 2026-04-14_
-- Raw Source: [[00_Raw/2026-04-20/React Three Fiber 자산 최적화 (Asset Optimization).md]]
----
diff --git a/Graphics & Performance/React Three Fiber에서 Rapier 물리 엔진 최적화하기.md b/Graphics & Performance/React Three Fiber에서 Rapier 물리 엔진 최적화하기.md
deleted file mode 100644
index 029580c6..00000000
--- a/Graphics & Performance/React Three Fiber에서 Rapier 물리 엔진 최적화하기.md	
+++ /dev/null
@@ -1,39 +0,0 @@
----
-id: P-REINFORCE-AUTO-95FEB9
-category: "[[10_Wiki/💡 Topics/Graphics & Performance]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - React Three Fiber에서 Rapier 물리 엔진 최적화하기"
----
-
-# [[React Three Fiber에서 Rapier 물리 엔진 최적화하기]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> React Three Fiber(R3F) 환경에서 `@react-three/rapier`를 사용할 때, 대규모 `InstancedRigidBodies` 적용, 비트마스크 기반의 충돌 필터링, Rust 메모리 에러 방지를 위한 상태 캐싱, 그리고 렌더링 루프 분리를 통해 연산 오버헤드를 극적으로 줄이는 고성능 물리 엔진 최적화 기법입니다.
-
-## 📖 구조화된 지식 (Synthesized Content)
-**1. InstancedRigidBodies를 활용한 대규모 물리 객체 처리** 수백, 수천 개의 물리 객체(총알, 파편 등)를 개별 `<RigidBody>`로 렌더링하면 물리 연산과 드로우 콜 오버헤드로 인해 프레임이 급락합니다. 이를 방지하려면 Three.js의 `InstancedMesh`를 `<InstancedRigidBodies>`로 감싸서 사용해야 합니다. 이 방식을 사용하면 수천 개의 인스턴스에 대한 위치, 회전, 물리적 상태를 배열(`InstancedRigidBodyProps[]`) 형태로 단 번에 초기화하고 단일 드로우 콜로 렌더링할 수 있어 성능이 비약적으로 향상됩니다.
-
-**2. interactionGroups를 통한 충돌 및 솔버 연산 최소화** 모든 객체가 서로 충돌 여부를 계산하게 두면 엔진에 큰 부하를 줍니다. Rapier에서는 `collisionGroups` 및 `solverGroups` 속성에 비트마스크(Bitmask)를 설정하여 상호작용할 대상을 제한할 수 있습니다. 라이브러리에서 제공하는 `interactionGroups` 헬퍼 함수를 사용해 객체가 속한 그룹과 상호작용할 그룹을 명시(예: `interactionGroups(0,)`)함으로써 불필요한 충돌 연산을 원천적으로 차단해야 합니다.
-
-**3. Physics Hooks 캐싱을 통한 Rust 메모리 에일리어싱 에러 방지** 복잡한 일방향 플랫폼(One-way platform) 등 고급 충돌 필터링을 위해 `useFilterContactPair` 훅을 사용할 때, 물리 스텝 진행 도중 `translation()`이나 `linvel()` 같은 RigidBody 속성에 직접 접근하면 WASM(Rust) 계층에서 에일리어싱 에러가 발생합니다. 이를 방지하려면 반드시 `useBeforePhysicsStep` 훅을 사용해 물리 스텝 시작 전에 필요한 객체들의 상태(위치, 속도 등)를 자바스크립트 `Map` 등 캐시(Cache) 메모리에 미리 저장해 두고, 필터링 훅에서는 이 캐시된 데이터만 읽도록 설계해야 합니다.
-
-**4. On-demand Rendering 및 물리 스텝 수동 제어** 기본적으로 `@react-three/rapier`는 프레임이 렌더링될 때마다 물리 시뮬레이션을 업데이트합니다. 하지만 화면의 시각적 업데이트가 필요 없을 때도 물리 연산이 필요하거나, 반대로 물리 연산을 일시정지하고 싶다면 `<Physics updateLoop="independent">`를 설정하여 렌더링 루프와 물리 루프를 분리할 수 있습니다. 또한 `useRapier().step()` 메서드를 통해 물리 시뮬레이션을 수동으로 진행(Manual stepping)시킬 수도 있습니다.
-
-**5. 센서(Sensor) 활용 및 충돌 이벤트 내 React 상태 업데이트 지양** 물리적 반발력이나 밀어내기 연산이 필요 없고 오직 '영역에 들어왔는지(Overlapping)' 여부만 판별해야 한다면 해당 콜라이더에 `sensor` 속성을 부여해야 불필요한 솔버(Solver) 연산을 줄일 수 있습니다. 또한, `onCollisionEnter`와 같은 빈번한 충돌 이벤트 내부에서 React의 `setState`를 호출하면 심각한 리렌더링 지연이 발생하므로, 전역 상태 변경이 아닌 이상 명령형(Imperative) 파티클 시스템에 직접 신호를 보내 처리하는 것이 바람직합니다.
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Graphics & Performance 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[InstancedMesh (드로우 콜 최적화)]], [[Web Worker (웹 워커)]], [[Garbage Collection (GC) 최적화]], [[Object Pooling (오브젝트 풀링)]]
-- **Projects/Contexts:** [[고성능 실시간 상호작용 시스템을 위한 React 기반 게임 엔진 아키텍처]]
-- **Contradictions/Notes:** Rapier의 스냅샷(Snapshot) 기능(`world.takeSnapshot()`)을 이용해 물리 세계의 상태를 저장하고 복원할 수 있지만, 복원 시점의 객체 생성 순서나 식별자가 스냅샷 캡처 시점과 정확히 일치하지 않으면 RigidBody들이 엉키는(Scramble) 버그가 발생하므로 상태 직렬화에 각별한 주의가 필요합니다.
-
----
-
-_Last updated: 2026-04-15_
-- Raw Source: [[00_Raw/2026-04-20/React Three Fiber에서 Rapier 물리 엔진 최적화하기.md]]
----
diff --git a/Graphics & Performance/React 기반 게임 엔진 아키텍처.md b/Graphics & Performance/React 기반 게임 엔진 아키텍처.md
deleted file mode 100644
index 1d41f3e4..00000000
--- a/Graphics & Performance/React 기반 게임 엔진 아키텍처.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-1B0F24
-category: "[[10_Wiki/💡 Topics/Graphics & Performance]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - React 기반 게임 엔진 아키텍처"
----
-
-# [[React 기반 게임 엔진 아키텍처]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Graphics & Performance 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/React 기반 게임 엔진 아키텍처.md]]
----
diff --git a/Graphics & Performance/React 동시성 기능 (Concurrent Features).md b/Graphics & Performance/React 동시성 기능 (Concurrent Features).md
deleted file mode 100644
index f9277c95..00000000
--- a/Graphics & Performance/React 동시성 기능 (Concurrent Features).md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-A689F7
-category: "[[10_Wiki/💡 Topics/Graphics & Performance]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - React 동시성 기능 (Concurrent Features)"
----
-
-# [[React 동시성 기능 (Concurrent Features)]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Graphics & Performance 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/React 동시성 기능 (Concurrent Features).md]]
----
diff --git a/Graphics & Performance/Redux-Reducer-Pattern.md b/Graphics & Performance/Redux-Reducer-Pattern.md
deleted file mode 100644
index 0fc07bad..00000000
--- a/Graphics & Performance/Redux-Reducer-Pattern.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-B7CB54
-category: "[[10_Wiki/💡 Topics/Graphics & Performance]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Redux-Reducer-Pattern"
----
-
-# [[Redux-Reducer-Pattern]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Graphics & Performance 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Redux-Reducer-Pattern.md]]
----
diff --git a/Graphics & Performance/Revit glTF Export.md b/Graphics & Performance/Revit glTF Export.md
deleted file mode 100644
index 5f21a562..00000000
--- a/Graphics & Performance/Revit glTF Export.md	
+++ /dev/null
@@ -1,32 +0,0 @@
----
-id: P-REINFORCE-AUTO-E2D208
-category: "[[10_Wiki/💡 Topics/Graphics & Performance]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Revit glTF Export"
----
-
-# [[Revit glTF Export]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> Revit glTF Export는 Revit에서 작성된 건축 및 건물 모델을 웹 3D 환경에서 효율적으로 렌더링하기 위해 glTF 형식으로 내보내는 과정입니다 [1, 2]. 이 과정에서는 성능 최적화를 위해 동일한 재질을 가진 메쉬를 병합하는 동시에, 병합된 모델 내에서도 개별 객체를 식별하고 제어하기 위해 특수한 glTF 확장 기능과 정점 데이터 속성을 함께 활용합니다 [3, 4].
-
-## 📖 구조화된 지식 (Synthesized Content)
-- **재질 기반의 메쉬 병합:** Revit 모델(예: 콘크리트 벽체 등)을 glTF로 내보낼 때, 드로우 콜을 줄이고 렌더링을 최적화하기 위해 동일한 재질을 공유하는 메쉬들을 그룹화합니다 [1, 3]. 건물의 벽체들은 재질은 같지만 기하학적 형태가 대부분 고유하기 때문에 일반적인 `InstancedMesh`로는 처리할 수 없어 데이터를 병합(Merge)하거나 `BatchedMesh`를 통해 관리하게 됩니다 [4].
-- **glTF 확장 기능(Extensions)의 적용:** 기하학적 데이터를 하나로 병합한 후에도, 사용자가 특정 벽체를 개별적으로 선택(Pick)하거나 가시성(Visibility) 및 색상을 동적으로 변경할 수 있어야 합니다 [4]. 이를 구현하기 위해 모델을 내보낼 때 `EXT_instance_features`, `EXT_mesh_features`, `EXT_mesh_gpu_instancing`과 같은 glTF 확장 기능을 추가하여 데이터를 구성합니다 [3].
-- **정점 식별 속성(Feature ID) 할당:** 병합된 모델 내에서 서로 다른 배치를 구분하기 위해 각 정점(Vertex)에 `_FEATURE_ID_0`과 같은 특수 속성을 할당합니다. 렌더러(Three.js 등)는 모델을 로드할 때 이 속성을 파싱하여, 단일 객체로 병합된 상태에서도 내부의 서로 다른 기하학적 파트를 식별하고 개별적인 제어를 수행할 수 있습니다 [3, 5].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Graphics & Performance 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[BatchedMesh]], [[glTF Extensions]], [[Three.js]]
-- **Projects/Contexts:** [[건축 및 BIM(Building Information Modeling) 3D 뷰어 구현]]
-- **Contradictions/Notes:** Revit에서 내보낸 1,200만 개 이상의 삼각형과 1,600만 개 이상의 정점을 포함하는 거대한 glTF 모델을 다룰 때, 개별 객체 제어를 위해 `BatchedMesh`를 사용하면 단순히 병합된 일반 `Mesh`로 렌더링할 때보다 오히려 CPU 사용량이 40~60%까지 급증하고 프레임 속도(FPS)가 급격히 떨어지는 성능 저하 현상이 보고되고 있습니다 [1, 2, 6, 7].
-
----
-*Last updated: 2026-04-19*
-- Raw Source: [[00_Raw/2026-04-20/Revit glTF Export.md]]
----
diff --git a/Graphics & Performance/Revit 모델 렌더링.md b/Graphics & Performance/Revit 모델 렌더링.md
deleted file mode 100644
index 12857f90..00000000
--- a/Graphics & Performance/Revit 모델 렌더링.md	
+++ /dev/null
@@ -1,34 +0,0 @@
----
-id: P-REINFORCE-AUTO-EC4298
-category: "[[10_Wiki/💡 Topics/Graphics & Performance]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Revit 모델 렌더링"
----
-
-# [[Revit 모델 렌더링]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 소스에 관련 정보가 부족합니다. 제공된 텍스트에서는 Revit 모델을 Three.js와 같은 웹 그래픽 환경으로 내보내어 렌더링하는 과정에서 발생한 특정 사용자의 워크플로우와 성능 병목 사례만이 제한적으로 언급되어 있습니다.
-
-## 📖 구조화된 지식 (Synthesized Content)
-소스에 관련 정보가 부족합니다. 제공된 문서 내에서 확인할 수 있는 단편적인 Revit 모델 렌더링 시도 및 사례는 다음과 같습니다.
-
-* **glTF 포맷 변환 및 데이터 구조화:** 한 사용자는 Revit에서 제작된 건물 모델을 glTF 형식으로 추출하고, Three.js 환경에서 가시성을 관리하기 위해 동일한 재질을 가진 메쉬들을 병합하는 방식을 사용했습니다 [1, 2]. 이 과정에서 객체의 배치를 구분하기 위해 `EXT_instance_features`, `EXT_mesh_features`, `EXT_mesh_gpu_instancing` 등의 확장을 추가하고, 각 정점에 `_FEATURE_ID_0` 속성을 할당하여 파싱하는 과정을 거쳤습니다 [3, 4].
-* **고유 지오메트리에 따른 렌더링 방식의 제약:** Revit 건물 모델 내의 벽체들은 콘크리트라는 동일한 재질을 공유하지만, 각기 고유한 기하학적 형태(Geometry)를 가지고 있어 단일 형태를 복제하는 `InstancedMesh`를 적용하기 어려웠습니다 [5]. 따라서 개별 벽체를 선택(Picking)하거나 가시성 및 색상을 동적으로 변경하기 위한 목적으로, 다양한 지오메트리를 하나로 묶을 수 있는 `BatchedMesh`를 채택해야만 했습니다 [5].
-* **대규모 모델에서의 성능 병목 문제:** 약 1,200만 개의 삼각형과 1,600만 개의 정점, 약 10만 개 이상의 지오메트리로 구성된 대규모 Revit 모델을 `BatchedMesh`를 활용해 렌더링할 경우 심각한 성능 저하가 보고되었습니다 [6, 7]. 일반적인 `Mesh`로 렌더링할 때는 60 FPS(CPU 15%, GPU 90%)가 유지되었으나, `BatchedMesh` 적용 시 CPU 사용량이 40% 이상으로 급증하며 프레임 레이트가 10~20 FPS 수준으로 크게 하락했습니다 [1, 8, 9].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Graphics & Performance 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[BatchedMesh]], [[glTF]], [[Three.js]]
-- **Projects/Contexts:** [[대규모 건축 모델의 웹 기반 시각화 및 최적화 테스트]]
-- **Contradictions/Notes:** 소스에 관련 정보가 부족합니다. 한편 사례를 통해, 일반적인 렌더링 횟수를 줄이기 위해 도입하는 `BatchedMesh` 최적화 기법이 거대한 규모의 Revit 파생 모델(수천만 정점 및 수십만 지오메트리)에서는 막대한 CPU 오버헤드를 유발하여 오히려 렌더링 성능을 저하시키는 모순적인 결과를 낳는다는 것을 확인할 수 있습니다 [1, 8, 10].
-
----
-*Last updated: 2026-04-19*
-- Raw Source: [[00_Raw/2026-04-20/Revit 모델 렌더링.md]]
----
diff --git a/Graphics & Performance/Robotics-Control-Systems.md b/Graphics & Performance/Robotics-Control-Systems.md
deleted file mode 100644
index 28a8bc81..00000000
--- a/Graphics & Performance/Robotics-Control-Systems.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-A9830E
-category: "[[10_Wiki/💡 Topics/Graphics & Performance]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Robotics-Control-Systems"
----
-
-# [[Robotics-Control-Systems]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Graphics & Performance 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Robotics-Control-Systems.md]]
----
diff --git a/Graphics & Performance/Role-Playing-Games (RPGs).md b/Graphics & Performance/Role-Playing-Games (RPGs).md
deleted file mode 100644
index 58522c59..00000000
--- a/Graphics & Performance/Role-Playing-Games (RPGs).md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-5C3932
-category: "[[10_Wiki/💡 Topics/Graphics & Performance]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Role-Playing-Games (RPGs)"
----
-
-# [[Role-Playing-Games (RPGs)]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Graphics & Performance 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Role-Playing-Games (RPGs).md]]
----
diff --git a/Graphics & Performance/Rowhammer attack.md b/Graphics & Performance/Rowhammer attack.md
deleted file mode 100644
index 9f413063..00000000
--- a/Graphics & Performance/Rowhammer attack.md	
+++ /dev/null
@@ -1,32 +0,0 @@
----
-id: P-REINFORCE-AUTO-80DA6E
-category: "[[10_Wiki/💡 Topics/Graphics & Performance]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Rowhammer attack"
----
-
-# [[Rowhammer attack]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> Rowhammer 공격은 WebGL을 사용하여 GPU에서 실행되었던 심각한 보안 취약점 공격입니다 [1]. 이 공격은 고정밀 타임스탬프 쿼리를 활용하여 캐시 적중 실패율(cache miss rates)을 관찰하고, 이를 통해 GPU의 물리적 메모리 레이아웃을 파악합니다 [1]. 이후 파악된 메모리에서 특정 비트를 반전(flip)시켜 페이지 테이블을 조작하고 악의적인 작업을 수행하도록 유도합니다 [1]. 과거에는 막기 어려운 공격으로 보고되었으나, 현재는 최신 RAM에 적용된 완화(mitigations) 기술을 통해 방어할 수 있습니다 [1].
-
-## 📖 구조화된 지식 (Synthesized Content)
-* **공격 원리 및 실행:** 이 공격은 WebGL 환경에서 타임스탬프 쿼리(timestamp queries)로부터 얻은 고정밀 타임스탬프(high precision timestamps)를 반드시 필요로 합니다 [1]. 공격자는 이를 통해 캐시 적중 실패율을 관찰하고 GPU 상의 물리적 메모리 배치를 알아냅니다 [1]. 
-* **페이지 테이블 조작:** 메모리 구조를 파악한 뒤에는 타겟으로 삼은 특정 비트를 Rowhammer 기법으로 반전시킵니다 [1]. 이 과정을 통해 페이지 테이블(page table)을 속여 시스템이 은밀하고 악의적인 동작(insidious action)을 실행하도록 만듭니다 [1].
-* **공격의 한계 및 최신 방어 동향:** 이 공격은 매우 명확하게 정의된 TLB(Translation Lookaside Buffer) 설계를 가진 특정 기기에만 제한적으로 적용되었습니다 [1]. 한때는 막을 수 없는(couldn't plug) 실질적이고 심각한 공격으로 평가받았으나, 이후 최신 RAM 하드웨어에 Rowhammer 방어 기술(mitigations)이 도입되면서 이러한 유형의 공격은 예방 가능해졌습니다 [1].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Graphics & Performance 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[WebGL]], [[GPU]], [[Timestamp queries]], [[TLB design]], [[Cache miss rates]]
-- **Projects/Contexts:** WebGPU의 [[High Resolution Time spec]] 이슈 논의 과정 중, 고해상도 타임스탬프가 야기할 수 있는 심각한 보안 위협(타이밍 공격)의 과거 사례로 언급되었습니다 [1].
-- **Contradictions/Notes:** 소스에 따르면 보고된 당시에는 막을 수 없는(couldn't plug) 공격이었으나, 현재는 하드웨어(최신 RAM)의 개선으로 인해 더 이상 유효하지 않은 것으로 보입니다 [1].
-
----
-*Last updated: 2026-04-19*
-- Raw Source: [[00_Raw/2026-04-20/Rowhammer attack.md]]
----
diff --git a/Graphics & Performance/Rowhammer.md b/Graphics & Performance/Rowhammer.md
deleted file mode 100644
index 8b8427f5..00000000
--- a/Graphics & Performance/Rowhammer.md	
+++ /dev/null
@@ -1,32 +0,0 @@
----
-id: P-REINFORCE-AUTO-13F9F1
-category: "[[10_Wiki/💡 Topics/Graphics & Performance]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Rowhammer"
----
-
-# [[Rowhammer]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> Rowhammer는 WebGL을 통해 GPU 상에서 실행되어 물리적 메모리의 특정 비트를 반전시키는 심각한 보안 공격 기법입니다 [1]. 이 공격은 고정밀 타임스탬프 쿼리를 이용해 캐시 미스율을 관찰하고 GPU의 물리적 메모리 레이아웃을 파악하는 방식으로 이루어집니다 [1]. 한때 막을 수 없었던 위협적인 공격이었으나, 특정 장치에만 국한되어 발생하며 최신 RAM의 방어 기술을 통해 완화되었습니다 [1].
-
-## 📖 구조화된 지식 (Synthesized Content)
-- **공격 원리:** 과거에 보고된 Rowhammer 공격은 타임스탬프 쿼리(timestamp queries)에서 얻은 고정밀 타임스탬프를 필수적으로 요구했습니다 [1]. 공격자는 이를 통해 캐시 미스율(cache miss rates)을 관찰하고 GPU의 물리적 메모리 레이아웃을 파악할 수 있었습니다 [1].
-- **시스템 조작:** 확보한 메모리 레이아웃 정보를 바탕으로 특정 비트를 목표로 삼아 반전(flip)시킴으로써, 페이지 테이블(page table)을 속이고 악의적인(insidious) 조작을 수행할 수 있습니다 [1].
-- **한계 및 방어(Mitigations):** 이 공격은 매우 명확하게 정의된 TLB(Translation Lookaside Buffer) 설계를 가진 특정 장치에만 제한적으로 적용되었습니다 [1]. 또한, 최신 RAM(newer RAM)에 도입된 Rowhammer 완화 기술을 통해 이러한 공격을 방지할 수 있습니다 [1].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Graphics & Performance 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[WebGL]], [[Timestamp Queries]], [[TLB (Translation Lookaside Buffer)]]
-- **Projects/Contexts:** [[High Resolution Time spec 논의]] (GPU 타임스탬프 해상도를 제한(coarsen)하여 보안 취약점을 방지해야 한다는 논의 중, 고정밀 타임스탬프를 악용한 실제 공격 사례로 언급됨 [1])
-- **Contradictions/Notes:** 소스에 따르면 Rowhammer는 초기에 "막을 수 없었던 최초의 실질적이고 심각한 공격(the first real, serious attack we couldn't plug)"으로 평가되었으나, 현재는 최신 RAM 하드웨어의 발전으로 회피가 가능해졌습니다 [1].
-
----
-*Last updated: 2026-04-19*
-- Raw Source: [[00_Raw/2026-04-20/Rowhammer.md]]
----
diff --git a/Graphics & Performance/SLA-Definition.md b/Graphics & Performance/SLA-Definition.md
deleted file mode 100644
index 00fafdd3..00000000
--- a/Graphics & Performance/SLA-Definition.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-37BE33
-category: "[[10_Wiki/💡 Topics/Graphics & Performance]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - SLA-Definition"
----
-
-# [[SLA-Definition]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Graphics & Performance 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/SLA-Definition.md]]
----
diff --git a/Graphics & Performance/SaaS-Retention-Strategies.md b/Graphics & Performance/SaaS-Retention-Strategies.md
deleted file mode 100644
index 0199383d..00000000
--- a/Graphics & Performance/SaaS-Retention-Strategies.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-B5B823
-category: "[[10_Wiki/💡 Topics/Graphics & Performance]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - SaaS-Retention-Strategies"
----
-
-# [[SaaS-Retention-Strategies]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Graphics & Performance 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/SaaS-Retention-Strategies.md]]
----
diff --git a/Graphics & Performance/Sandbox-Simulation.md b/Graphics & Performance/Sandbox-Simulation.md
deleted file mode 100644
index e831c294..00000000
--- a/Graphics & Performance/Sandbox-Simulation.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-D0C092
-category: "[[10_Wiki/💡 Topics/Graphics & Performance]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Sandbox-Simulation"
----
-
-# [[Sandbox-Simulation]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Graphics & Performance 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Sandbox-Simulation.md]]
----
diff --git a/Graphics & Performance/Search-Based Procedural Content Generation (SBPCG).md b/Graphics & Performance/Search-Based Procedural Content Generation (SBPCG).md
deleted file mode 100644
index 10473674..00000000
--- a/Graphics & Performance/Search-Based Procedural Content Generation (SBPCG).md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-8371CD
-category: "[[10_Wiki/💡 Topics/Graphics & Performance]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Search-Based Procedural Content Generation (SBPCG)"
----
-
-# [[Search-Based Procedural Content Generation (SBPCG)]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Graphics & Performance 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Search-Based Procedural Content Generation (SBPCG).md]]
----
diff --git a/Graphics & Performance/Semantic Versioning (SemVer) in Type Safety.md b/Graphics & Performance/Semantic Versioning (SemVer) in Type Safety.md
deleted file mode 100644
index 540d81e4..00000000
--- a/Graphics & Performance/Semantic Versioning (SemVer) in Type Safety.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-882353
-category: "[[10_Wiki/💡 Topics/Graphics & Performance]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Semantic Versioning (SemVer) in Type Safety"
----
-
-# [[Semantic Versioning (SemVer) in Type Safety]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Graphics & Performance 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Semantic Versioning (SemVer) in Type Safety.md]]
----
diff --git a/Graphics & Performance/Semantic-Web-Technologies.md b/Graphics & Performance/Semantic-Web-Technologies.md
deleted file mode 100644
index 75026bcb..00000000
--- a/Graphics & Performance/Semantic-Web-Technologies.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-BB1892
-category: "[[10_Wiki/💡 Topics/Graphics & Performance]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Semantic-Web-Technologies"
----
-
-# [[Semantic-Web-Technologies]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Graphics & Performance 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Semantic-Web-Technologies.md]]
----
diff --git a/Graphics & Performance/Semantic-Web.md b/Graphics & Performance/Semantic-Web.md
deleted file mode 100644
index 10b2f189..00000000
--- a/Graphics & Performance/Semantic-Web.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-8C1755
-category: "[[10_Wiki/💡 Topics/Graphics & Performance]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Semantic-Web"
----
-
-# [[Semantic-Web]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Graphics & Performance 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Semantic-Web.md]]
----
diff --git a/Graphics & Performance/Semiotics in Media.md b/Graphics & Performance/Semiotics in Media.md
deleted file mode 100644
index 37a6c364..00000000
--- a/Graphics & Performance/Semiotics in Media.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-A79FEB
-category: "[[10_Wiki/💡 Topics/Graphics & Performance]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Semiotics in Media"
----
-
-# [[Semiotics in Media]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Graphics & Performance 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Semiotics in Media.md]]
----
diff --git a/Graphics & Performance/Sensor Fusion.md b/Graphics & Performance/Sensor Fusion.md
deleted file mode 100644
index 0f797fa5..00000000
--- a/Graphics & Performance/Sensor Fusion.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-AA5A99
-category: "[[10_Wiki/💡 Topics/Graphics & Performance]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Sensor Fusion"
----
-
-# [[Sensor Fusion]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Graphics & Performance 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Sensor Fusion.md]]
----
diff --git a/Graphics & Performance/Service-Dominant-Logic.md b/Graphics & Performance/Service-Dominant-Logic.md
deleted file mode 100644
index 5e24b0cc..00000000
--- a/Graphics & Performance/Service-Dominant-Logic.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-625B63
-category: "[[10_Wiki/💡 Topics/Graphics & Performance]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Service-Dominant-Logic"
----
-
-# [[Service-Dominant-Logic]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Graphics & Performance 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Service-Dominant-Logic.md]]
----
diff --git a/Graphics & Performance/SharedArrayBuffer.md b/Graphics & Performance/SharedArrayBuffer.md
deleted file mode 100644
index ac1fc23d..00000000
--- a/Graphics & Performance/SharedArrayBuffer.md	
+++ /dev/null
@@ -1,30 +0,0 @@
----
-id: P-REINFORCE-AUTO-C22BDF
-category: "[[10_Wiki/💡 Topics/Graphics & Performance]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - SharedArrayBuffer"
----
-
-# [[SharedArrayBuffer]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> SharedArrayBuffer는 다중 스레드 환경에서 Web Worker와 메인 스레드 간에 데이터를 공유할 때 메모리 과부하를 방지하기 위해 사용되는 기술입니다 [1]. 전통적인 데이터 전달 방식과 달리 메모리를 복제하지 않는 제로 카피(Zero-copy) 아키텍처를 구현할 수 있게 해줍니다 [1]. 이를 통해 Electron과 같은 환경에서 대규모 3D 모델을 로드하고 파싱할 때 메모리 안정성을 획기적으로 유지할 수 있습니다 [1, 2].
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Graphics & Performance 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[Web Worker]], [[Structured Cloning]], [[BufferAttribute]], [[Zero-copy architecture]]
-- **Projects/Contexts:** [[Electron 기반 WebGL CAD 렌더링 최적화]]
-- **Contradictions/Notes:** 소스에서는 워커를 활용할 때 기존의 Structured Cloning을 사용할 경우 데이터가 전체 복사되어 OOM이 발생할 위험이 크지만, SharedArrayBuffer를 사용하면 복사 과정을 없애(Zero-copy) 이러한 메모리 오버헤드를 완벽히 방지할 수 있다고 대조하여 설명합니다 [1].
-
----
-*Last updated: 2026-04-19*
-- Raw Source: [[00_Raw/2026-04-20/SharedArrayBuffer.md]]
----
diff --git a/Graphics & Performance/Simulations of Social Systems.md b/Graphics & Performance/Simulations of Social Systems.md
deleted file mode 100644
index e1ba8ec5..00000000
--- a/Graphics & Performance/Simulations of Social Systems.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-6349BA
-category: "[[10_Wiki/💡 Topics/Graphics & Performance]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Simulations of Social Systems"
----
-
-# [[Simulations of Social Systems]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Graphics & Performance 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Simulations of Social Systems.md]]
----
diff --git a/Graphics & Performance/Simultaneous Localization and Mapping (SLAM).md b/Graphics & Performance/Simultaneous Localization and Mapping (SLAM).md
deleted file mode 100644
index c6b628ae..00000000
--- a/Graphics & Performance/Simultaneous Localization and Mapping (SLAM).md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-72B40F
-category: "[[10_Wiki/💡 Topics/Graphics & Performance]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Simultaneous Localization and Mapping (SLAM)"
----
-
-# [[Simultaneous Localization and Mapping (SLAM)]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Graphics & Performance 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Simultaneous Localization and Mapping (SLAM).md]]
----
diff --git a/Graphics & Performance/SkinnedMesh.md b/Graphics & Performance/SkinnedMesh.md
deleted file mode 100644
index 6f412f89..00000000
--- a/Graphics & Performance/SkinnedMesh.md	
+++ /dev/null
@@ -1,42 +0,0 @@
----
-id: P-REINFORCE-AUTO-1189F7
-category: "[[10_Wiki/💡 Topics/Graphics & Performance]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - SkinnedMesh"
----
-
-# [[SkinnedMesh]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> SkinnedMesh는 뼈대(Bone) 계층 구조를 기반으로 한 애니메이션(예: 캐릭터의 얼굴 뼈대나 손가락 움직임 등)을 구현할 때 사용되는 3D 객체 타입입니다 [1-3]. 단일 객체로는 원활하게 동작하지만 대량으로 렌더링할 경우 심각한 CPU 병목 현상을 유발하며 [4], 정점이 다수의 본 행렬에 영향을 받는 특성상 대규모 렌더링 최적화 기법인 InstancedMesh와 기본적으로 호환되지 않는 물리적 한계를 지닙니다 [3].
-
-## 📖 구조화된 지식 (Synthesized Content)
-- **동작 원리와 성능 병목:**
-  SkinnedMesh의 각 정점은 여러 개의 본(Bone) 변환 행렬에 의해 영향을 받아 변형됩니다 [3]. 따라서 화면에 100개에서 1,000개 이상의 많은 SkinnedMesh를 개별적으로 렌더링하려고 시도할 경우, 연산 부하로 인해 심각한 CPU 병목 현상에 직면하게 됩니다 [4].
-
-- **InstancedMesh 연동의 구조적 한계:**
-  Three.js의 기본 InstancedMesh는 본 기반의 스킨드 애니메이션을 지원하지 않습니다 [3]. 각 인스턴스마다 고유한 포즈를 취하게 하려면 개별 인스턴스별로 전체 본 행렬 세트를 GPU로 전송해야 하는데(예: 100개의 인스턴스가 각각 60개의 본을 가질 경우 매 프레임 6,000개의 행렬 데이터 전송 필요), 이는 인스턴스 속성 버퍼의 제한 용량을 쉽게 초과하게 만듭니다 [3].
-
-- **애니메이션 시스템(AnimationMixer)의 비호환성:**
-  Three.js의 표준 애니메이션 시스템인 `AnimationMixer`는 개별 객체의 시간축을 개별적으로 관리하도록 설계되어 있어, 단일 드로우 콜로 여러 객체를 처리하는 InstancedMesh의 구조와 호환되지 않습니다 [3]. 각 인스턴스마다 다른 애니메이션 재생 상태를 적용하려면 셰이더에서 직접 인스턴스 ID 기반으로 시간 오프셋을 계산하는 등 복잡한 작업이 필요합니다 [3]. 
-
-- **스킨드 메쉬 렌더링 최적화 전략:**
-  - **본 텍스처(Bone Texture) 도입:** GPU 전송 한계를 극복하기 위해 모든 애니메이션 변환 행렬 데이터를 '본 텍스처(Bone Texture)' 또는 텍스처 아틀라스에 구워 넣고, 커스텀 셰이더 단계에서 이를 샘플링해 애니메이션을 구현하는 우회 파이프라인이 사용됩니다 [1, 3, 5].
-  - **애니메이션 LOD(Level of Detail):** 거리가 먼 SkinnedMesh 인스턴스의 경우 계산해야 할 본의 개수를 줄이거나(예: 손가락이나 발의 굽힘 뼈대 연산 생략), 애니메이션 업데이트 주기를 낮추어 본 텍스처의 크기와 연산량을 줄이는 방식이 필수적입니다 [6-9].
-  - **커스텀 라이브러리 활용:** 커뮤니티에서는 기본 기능의 한계를 보완하기 위해, 개별 애니메이션 믹서 제어, LOD 시스템, 그리고 절두체 컬링(Frustum Culling) 기능을 포함하여 2만 개 이상의 스킨드 인스턴스 처리를 가능하게 하는 `InstancedMesh2`와 같은 확장 라이브러리를 활용하기도 합니다 [6, 10-13].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Graphics & Performance 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[InstancedMesh]], [[InstancedMesh2]], [[AnimationMixer]], [[Bone Texture]], [[Level of Detail (LOD)]]
-- **Projects/Contexts:** [[Three.js 엔진의 대규모 군중 렌더링 및 애니메이션 처리]]
-- **Contradictions/Notes:** 엔진의 공식 기능 상으로는 데이터 전송량의 기하급수적 증가 및 `AnimationMixer`와의 아키텍처 충돌 문제로 스킨드 메쉬의 대규모 인스턴싱이 불가능하다고 지적되지만 [3], 개발자들은 본 텍스처를 활용한 셰이더 커스터마이징이나 `InstancedMesh2` 라이브러리를 적용하여 각기 다른 애니메이션을 가진 수만 개의 SkinnedMesh를 단일 혹은 최소한의 드로우 콜로 최적화하여 렌더링하는 데 성공하고 있습니다 [3, 6, 12].
-
----
-*Last updated: 2026-04-19*
-- Raw Source: [[00_Raw/2026-04-20/SkinnedMesh.md]]
----
diff --git a/Graphics & Performance/Skybound Protocol 기술 메뉴얼 및 개발자 가이드.md b/Graphics & Performance/Skybound Protocol 기술 메뉴얼 및 개발자 가이드.md
deleted file mode 100644
index ece37881..00000000
--- a/Graphics & Performance/Skybound Protocol 기술 메뉴얼 및 개발자 가이드.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-19F4EF
-category: "[[10_Wiki/💡 Topics/Graphics & Performance]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Skybound Protocol 기술 메뉴얼 및 개발자 가이드"
----
-
-# [[Skybound Protocol 기술 메뉴얼 및 개발자 가이드]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Graphics & Performance 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Skybound Protocol 기술 메뉴얼 및 개발자 가이드.md]]
----
diff --git a/Graphics & Performance/Smart City Digital Twins.md b/Graphics & Performance/Smart City Digital Twins.md
deleted file mode 100644
index a8c92edc..00000000
--- a/Graphics & Performance/Smart City Digital Twins.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-888FC9
-category: "[[10_Wiki/💡 Topics/Graphics & Performance]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Smart City Digital Twins"
----
-
-# [[Smart City Digital Twins]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Graphics & Performance 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Smart City Digital Twins.md]]
----
diff --git a/Graphics & Performance/Smart-City-Frameworks.md b/Graphics & Performance/Smart-City-Frameworks.md
deleted file mode 100644
index 8cb59abb..00000000
--- a/Graphics & Performance/Smart-City-Frameworks.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-28F252
-category: "[[10_Wiki/💡 Topics/Graphics & Performance]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Smart-City-Frameworks"
----
-
-# [[Smart-City-Frameworks]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Graphics & Performance 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Smart-City-Frameworks.md]]
----
diff --git a/Graphics & Performance/Sorting.md b/Graphics & Performance/Sorting.md
deleted file mode 100644
index beef0248..00000000
--- a/Graphics & Performance/Sorting.md	
+++ /dev/null
@@ -1,42 +0,0 @@
----
-id: P-REINFORCE-AUTO-9C6ABB
-category: "[[10_Wiki/💡 Topics/Graphics & Performance]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Sorting"
----
-
-# [[Sorting]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 3D 렌더링 환경에서 정렬(Sorting)은 카메라와의 거리를 기준으로 객체의 렌더링 순서를 결정하는 핵심 프로세스입니다. 불투명한 객체는 앞에서 뒤로(Front-to-Back) 정렬하여 오버드로우를 최소화하고, 투명한 객체는 뒤에서 앞으로(Back-to-Front) 정렬하여 알파 블렌딩(Alpha Blending)을 올바르게 표현하기 위해 필수적입니다. 그러나 수많은 객체를 다루는 인스턴싱 환경에서는 매 프레임 정렬을 계산하고 버퍼를 재배열하는 과정이 심각한 CPU 병목 현상을 유발할 수 있습니다 [1, 2].
-
-## 📖 구조화된 지식 (Synthesized Content)
-- **정렬의 목적과 필요성**
-  불투명한 물체를 앞에서 뒤로 정렬하면 뒤에 가려진 픽셀 연산을 조기에 종료(Early-Z)할 수 있어 GPU 성능이 향상됩니다 [1]. 반면 투명도를 가진 객체의 경우, 시각적인 오류 없이 올바른 알파 블렌딩 결과를 얻기 위해 반드시 뒤에서 앞으로 렌더링해야 합니다 [2, 3].
-
-- **InstancedMesh의 정렬 한계**
-  기본적으로 Three.js의 `InstancedMesh`는 단일 드로우 콜 내에서 객체의 렌더링 순서를 동적으로 변경하거나 자동 정렬하는 기능을 제공하지 않습니다 [1, 2]. 정렬을 구현하려면 매 프레임 카메라와의 거리를 계산하고 색상, 변환 행렬 등 모든 인스턴스 속성 데이터를 재정렬해야 하므로 막대한 CPU 오버헤드가 발생합니다 [2, 4].
-
-- **정렬 알고리즘 및 처리 비용**
-  수만 개의 객체를 정렬하기 위해 기수 정렬(Radix Sort)과 같은 알고리즘을 사용할 수 있으나, 이를 메인 스레드에서 실행하면 CPU에 치명적인 부하를 주어 프레임 드랍을 유발합니다 [2, 5]. 실제로 `BatchedMesh`에서 `.sortObjects` 옵션을 활성화하면 `texSubImage2D` 함수 등의 호출로 인해 CPU 사용량이 급증하고 프레임 속도가 30FPS에서 9FPS로 떨어지는 등 성능이 크게 저하되는 사례가 확인되었습니다 [6-8].
-
-- **대안적 정렬 기법**
-  - **인디렉션(Indirection) 활용:** `InstancedMesh2`와 같은 확장 라이브러리는 렌더링할 인스턴스 인덱스를 관리하는 별도의 `InstancedBufferAttribute`를 사용하여, 실제 행렬 데이터를 직접 섞지 않고도 효율적으로 정렬 및 컬링을 수행합니다 [9].
-  - **다중 그리기(Multi-Draw) 확장:** WebGL의 `multi_draw` 기능을 사용하면 단일 드로우 콜을 유지하면서 인스턴스 그리기의 순서를 지정할 수 있어 정렬 문제를 완화할 수 있습니다 [3, 10].
-  - **인덱스 버퍼 업데이트:** 정점 버퍼(Vertex Buffer) 대신 인덱스 버퍼(Index Buffer)를 업데이트하여 객체를 정렬하거나 인스턴스화하는 것도 오버헤드를 줄이는 효과적인 저수준 최적화 기법입니다 [11].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Graphics & Performance 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[InstancedMesh]], [[BatchedMesh]], [[Overdraw]], [[Alpha Blending]], [[Frustum Culling]], [[Radix Sort]]
-- **Projects/Contexts:** [[Three.js]], [[InstancedMesh2]]
-- **Contradictions/Notes:** 투명도 및 오버드로우 해결을 위해 정렬이 필수적이지만, 정렬 연산 자체(버퍼 재배열 등)가 CPU에 큰 부하를 가하기 때문에 오히려 전체 프레임 레이트를 떨어뜨리는 역설적인 결과를 낳을 수 있습니다. 이는 GPU 압박과 CPU 병목 사이의 가혹한 절충안을 요구합니다 [1, 2, 7, 8].
-
----
-*Last updated: 2026-04-19*
-- Raw Source: [[00_Raw/2026-04-20/Sorting.md]]
----
diff --git a/Graphics & Performance/Spatial Partitioning.md b/Graphics & Performance/Spatial Partitioning.md
deleted file mode 100644
index 4665462b..00000000
--- a/Graphics & Performance/Spatial Partitioning.md	
+++ /dev/null
@@ -1,33 +0,0 @@
----
-id: P-REINFORCE-AUTO-1BF809
-category: "[[10_Wiki/💡 Topics/Graphics & Performance]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Spatial Partitioning"
----
-
-# [[Spatial Partitioning]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 공간 분할(Spatial Partitioning)은 3D 그래픽스에서 대규모 씬(Scene)의 수많은 객체나 복잡한 기하학적 구조를 효율적으로 렌더링하고 관리하기 위한 최적화 기법입니다. 3D 공간을 BVH(Bounding Volume Hierarchy)나 옥트리(Octree)와 같은 계층적 인덱스 자료구조로 분할하여 관리함으로써, 시스템이 시야 밖의 객체를 조기에 연산에서 제외(Culling)할 수 있게 합니다 [1]. 이를 통해 광선 추적(Raycasting) 상호작용의 속도를 높이고, 프러스텀 컬링의 효율성을 극대화하여 CPU 및 GPU의 과부하를 방지하는 핵심적인 역할을 수행합니다 [1-3].
-
-## 📖 구조화된 지식 (Synthesized Content)
-- **자료구조의 종류:** 주로 BVH(Bounding Volume Hierarchy) 및 옥트리(Octree)와 같은 계층적 공간 인덱스(Hierarchical spatial index)를 활용하여 전체 씬을 여러 공간 노드로 나눕니다 [1, 4]. 한편, 실내 건축(Arch domain) 환경과 같은 특수한 경우에는 방(Room)과 문(Portal)을 연결하는 공간-포털(Cell-portal) 접근법이 매우 직관적이고 효과적인 공간 분할법으로 채택되기도 합니다 [5].
-- **시야 절두체 컬링(Frustum Culling) 최적화:** 렌더러는 상위 레벨의 공간 노드를 카메라의 시야 프러스텀과 먼저 대조하여, 노드가 시야 내에 있을 때만 개별 컴포넌트 하위로 탐색해 내려갑니다 [1]. 이를 통해 보이지 않는 객체의 교차 테스트와 바운딩 스피어 계산을 과감히 생략할 수 있어 연산 자원을 대폭 절약할 수 있습니다 [1]. 대량의 `InstancedMesh` 환경에서도 전체를 하나로 관리하기보다는 공간적으로 인접한 소규모 인스턴스 그룹 단위로 분할 관리하는 전략을 취해야 컬링 정밀도가 높아져 GPU 낭비를 막을 수 있습니다 [3].
-- **레이캐스팅 가속 (Raycasting Acceleration):** 수만 개의 폴리곤 또는 대규모 인스턴스 씬에서 사용자의 피킹(Picking) 상호작용을 즉각적으로 처리하려면 정교한 공간 분할 자료구조 구축이 필수적입니다 [6]. `three-mesh-bvh`와 같은 라이브러리는 공간 인덱싱(BVH)을 구현하여 8만 개 이상의 폴리곤에 대해서도 60fps를 유지하며 매우 빠른 레이캐스팅과 공간 쿼리(Spatial queries) 성능을 제공합니다 [2, 7].
-- **대규모 환경 및 로딩 관리:** 거대한 오픈 월드 엔진이나 대형 건축물 씬에서 공간 인덱싱은 단순한 렌더링 가속을 넘어, 라이팅(Lighting), 충돌(Collisions), 에셋의 RAM 메모리 로드 및 폐기, 그리고 청크 단위의 월드 콘텐츠 스트리밍(Chunked world content streaming) 등 여러 시스템의 부하를 조율하는 핵심적인 뼈대 역할을 수행합니다 [5, 8].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Graphics & Performance 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[Frustum Culling]], [[BVH (Bounding Volume Hierarchy)]], [[Octree]], [[InstancedMesh]], [[Raycasting]]
-- **Projects/Contexts:** [[three-mesh-bvh]], [[Tesseract Engine]]
-- **Contradictions/Notes:** 대규모 환경에서 레이캐스팅 및 렌더링 최적화를 위해 공간 인덱스(Spatial index)를 활용하는 것은 명확한 성능 향상을 제공하지만, 이러한 공간 분할 자료구조를 구축하고 유지하는 데에는 상당한 복잡성(non-trivial complexity)이 수반되며 구현 난이도가 높다는 개발자들의 논의가 존재합니다 [6, 9].
-
----
-*Last updated: 2026-04-19*
-- Raw Source: [[00_Raw/2026-04-20/Spatial Partitioning.md]]
----
diff --git a/Graphics & Performance/Special Education Interventions.md b/Graphics & Performance/Special Education Interventions.md
deleted file mode 100644
index 03dc19fc..00000000
--- a/Graphics & Performance/Special Education Interventions.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-B2C5F1
-category: "[[10_Wiki/💡 Topics/Graphics & Performance]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Special Education Interventions"
----
-
-# [[Special Education Interventions]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Graphics & Performance 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Special Education Interventions.md]]
----
diff --git a/Graphics & Performance/Spectre and Meltdown.md b/Graphics & Performance/Spectre and Meltdown.md
deleted file mode 100644
index 97697a61..00000000
--- a/Graphics & Performance/Spectre and Meltdown.md	
+++ /dev/null
@@ -1,40 +0,0 @@
----
-id: P-REINFORCE-AUTO-8FCA7F
-category: "[[10_Wiki/💡 Topics/Graphics & Performance]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Spectre and Meltdown"
----
-
-# [[Spectre and Meltdown]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> Spectre와 Meltdown은 현대 프로세서의 투기적 실행(speculative execution) 과정에서 발생하는 취약점을 악용하여, 공격자가 접근 권한이 없는 메모리 영역의 비밀 데이터를 읽을 수 있게 하는 보안 결함이다 [1, 2]. 웹 브라우저 환경에서는 캐시 적중률과 메모리 접근 패턴의 미세한 시간 차이를 측정하는 타이밍 공격을 통해 이 취약점이 실행될 수 있다 [3-6]. 이를 방지하기 위해 브라우저 엔진들은 타이머의 정밀도를 낮추고 분기 없는 보안 검사를 도입하였으며, 이는 결과적으로 GPU 및 WebGL 파이프라인 연산의 미세 지연(micro-latency)을 소폭 증가시켰다 [7-9].
-
-## 📖 구조화된 지식 (Synthesized Content)
-- **투기적 실행과 메모리 접근 타이밍 악용:**
-  Spectre와 Meltdown은 CPU가 성능 향상을 위해 분기문의 결과를 예측하고 미리 코드를 실행하는 '투기적 실행'을 악용한다 [2]. CPU는 예측이 틀렸을 경우 실행 상태를 롤백하지만, 이 과정에서 메인 메모리에서 L1 캐시로 데이터를 로드한 흔적은 그대로 남게 된다 [2, 5]. 공격자는 고정밀 타이머를 사용하여 특정 메모리 배열(예: `otherArray`과 `otherArray[10]`)에 대한 접근 속도 차이를 측정함으로써 캐시에 로드된 데이터를 추론하는 타이밍 기반 정보 유출 공격을 수행할 수 있다 [5, 6]. WebKit과 같은 JavaScript 엔진에서 악의적인 스크립트가 실행될 경우, 경계 검사(bounds check)나 타입 검사를 우회하여 프로세스 주소 공간의 임의의 메모리를 읽을 위험이 있다 [11, 12].
-
-- **브라우저의 보안 완화 조치 (타이머 정밀도 감소 및 지터 도입):**
-  고해상도 타이밍 공격을 막기 위해 WebKit과 Blink 등의 브라우저 엔진은 `performance.now()`의 정밀도를 1ms 또는 100 마이크로초 수준으로 대폭 낮추고, 반환되는 시간 값에 무작위 변동성인 '지터(jitter)'를 추가하였다 [7, 9, 13]. 또한, 고해상도 타이머를 생성하는 데 악용될 수 있는 `SharedArrayBuffer`를 비활성화하였다 [9]. WebGPU의 `timestamp-query` 기능 역시 타이밍 공격 우려로 인해 양자화(quantization)를 적용하여 격리된 컨텍스트에서도 해상도를 100 마이크로초로 제한하였다 [14-16]. 과거 WebGL에서는 `EXT_disjoint_timer_query` 확장을 통해 프레임 지연을 정밀하게 측정할 수 있었으나, 이 역시 동일한 보안 이유로 인해 최신 브라우저들에서 비활성화되거나 제한되었다 [3, 4].
-
-- **분기 없는 보안 검사(Branchless Security Checks) 도입:**
-  브라우저는 타이머 조작 외에도 투기적 실행 자체의 부작용을 방어하기 위해 인덱스 마스킹(Index Masking)과 포인터 포이즈닝(Pointer Poisoning) 같은 분기 없는 보안 검사 기법을 도입했다 [17, 18]. 인덱스 마스킹은 비트 연산을 사용하여 투기적 실행 중에도 배열 인덱스가 항상 유효한 범위 내에 있도록 강제한다 [17, 19]. 포인터 포이즈닝은 포인터에 임의의 값을 XOR 연산하여, 잘못된 투기적 분기가 일어날 경우 매핑되지 않은 유효하지 않은 메모리를 가리키도록 유도한다 [17, 20].
-
-- **그래픽스 파이프라인의 미세 지연(Micro-latency)에 미치는 영향:**
-  이러한 보안 완화 조치들은 웹 타이밍 보안을 위해 필수적이지만, JavaScript 엔진과 JIT(Just-In-Time) 컴파일러가 수행하는 그래픽스 실행 중요 경로(critical path)에 추가적인 명령어를 삽입하게 만든다 [8]. 결과적으로 이는 그래픽스 파이프라인 내에서 수행되는 모든 연산의 기본 미세 지연(base micro-latency)을 약간 증가시키는 원인이 된다 [8].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Graphics & Performance 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[EXT_disjoint_timer_query]], [[Timestamp Queries Quantization]], [[Branchless Security Checks]]
-- **Projects/Contexts:** [[WebKit Security Mitigations]], [[WebGPU / WebGL Timing API Security]]
-- **Contradictions/Notes:** 소스에는 Spectre 및 Meltdown 취약점으로 인해 도입된 브라우저 엔진의 보안 조치(타이머 정밀도 하향, 분기 없는 보안 검사 추가 등)가 그래픽스 파이프라인의 전반적인 미세 지연을 증가시킨다는 사실은 설명되어 있으나 [8], 루트 주제에서 명시한 '브라우저 메모리 할당 시점별' 미세 지연의 변화를 직접적으로 측정한 구체적인 실험 사례나 수치에 대해서는 소스에 관련 정보가 부족합니다.
-
----
-*Last updated: 2026-04-19*
-- Raw Source: [[00_Raw/2026-04-20/Spectre and Meltdown.md]]
----
diff --git a/Graphics & Performance/Speculative Biology.md b/Graphics & Performance/Speculative Biology.md
deleted file mode 100644
index e1ce2dab..00000000
--- a/Graphics & Performance/Speculative Biology.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-FF5504
-category: "[[10_Wiki/💡 Topics/Graphics & Performance]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Speculative Biology"
----
-
-# [[Speculative Biology]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Graphics & Performance 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Speculative Biology.md]]
----
diff --git a/Graphics & Performance/Spring Framework.md b/Graphics & Performance/Spring Framework.md
deleted file mode 100644
index c27ab742..00000000
--- a/Graphics & Performance/Spring Framework.md	
+++ /dev/null
@@ -1,38 +0,0 @@
----
-id: P-REINFORCE-AUTO-C45BD6
-category: "[[10_Wiki/💡 Topics/Graphics & Performance]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Spring Framework"
----
-
-# [[Spring Framework]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> Spring Framework는 자바(Java) 환경에서 사용되는 프레임워크로, 주로 내장된 DI(의존성 주입) 컨테이너를 통해 컴포넌트 간의 결합도를 낮추는 역할을 합니다 [1]. 또한 런타임 시점에 적용되는 Spring AOP를 지원하여 트랜잭션 관리 및 캐시 처리와 같은 횡단 관심사의 모듈화를 돕습니다 [2, 3]. 다만 제공된 문헌에는 Spring Framework의 전반적인 아키텍처나 생태계 전반을 다루는 내용이 없어, 소스에 관련 정보가 부족합니다.
-
-## 📖 구조화된 지식 (Synthesized Content)
-* **의존성 주입(DI)과 결합도 감소**
-  Spring Framework는 내장된 의존성 주입(Dependency Injection) 컨테이너를 제공하여 SOLID 원칙 중 하나인 의존성 역전 원칙(Dependency Inversion Principle, DIP)을 훨씬 쉽게 구현할 수 있도록 지원합니다 [1]. 이를 통해 소프트웨어 컴포넌트들을 효과적으로 분리(decoupling)하고 유연한 설계를 가능하게 합니다 [1].
-
-* **Spring AOP (관점 지향 프로그래밍) 지원**
-  * **런타임 위빙(Runtime Weaving):** Spring AOP는 애플리케이션의 실제 코드와 Aspect를 결합하는 위빙 과정에 있어 프로그램 실행 시점에 적용되는 런타임 위빙 방식을 사용합니다 [2].
-  * **조인 포인트(Join Point)의 한계:** 프로그램 실행 중 Aspect를 적용할 수 있는 지점인 조인 포인트에 대해, Spring AOP는 오직 '메서드 실행 시점'만을 지원합니다 [4]. 따라서 이보다 더 세부적인 제어가 필요한 상황에서는 AspectJ를 대신 사용해야 합니다 [5].
-  * **주요 활용 사례:** 데이터베이스 트랜잭션을 관리하는 `@Transactional` 어노테이션과 성능 개선을 위해 자주 호출되는 메서드 결과를 캐싱하는 Spring Cache 라이브러리는 모두 이러한 AOP 기능을 활용하여 구현되어 있습니다 [3].
-
-*(전체적인 웹 모듈, 데이터 접근 기술, 부트스트랩 과정 등 프레임워크의 상세 아키텍처에 대해서는 소스에 관련 정보가 부족합니다.)*
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Graphics & Performance 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[Dependency Injection (DI)]], [[Aspect-Oriented Programming (AOP)]]
-- **Projects/Contexts:** [[SOLID Principles]], [[객체 지향 프로그래밍 (OOP)]]
-- **Contradictions/Notes:** 소스에 따르면 Spring AOP는 런타임에 적용되어 유용한 모듈화를 제공하지만, 오직 메서드 실행 시점의 조인 포인트만 지원하는 한계가 있어 더 정밀한 제어를 원할 경우 AspectJ 사용이 권장됩니다 [4, 5].
-
----
-*Last updated: 2026-04-18*
-- Raw Source: [[00_Raw/2026-04-20/Spring Framework.md]]
----
diff --git a/Graphics & Performance/Structuralism.md b/Graphics & Performance/Structuralism.md
deleted file mode 100644
index f2492510..00000000
--- a/Graphics & Performance/Structuralism.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-569BE2
-category: "[[10_Wiki/💡 Topics/Graphics & Performance]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Structuralism"
----
-
-# [[Structuralism]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Graphics & Performance 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Structuralism.md]]
----
diff --git a/Graphics & Performance/Surgical-Robotics.md b/Graphics & Performance/Surgical-Robotics.md
deleted file mode 100644
index 0bf6770e..00000000
--- a/Graphics & Performance/Surgical-Robotics.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-C5C20D
-category: "[[10_Wiki/💡 Topics/Graphics & Performance]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Surgical-Robotics"
----
-
-# [[Surgical-Robotics]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Graphics & Performance 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Surgical-Robotics.md]]
----
diff --git a/Graphics & Performance/Systemic-Design-Frameworks.md b/Graphics & Performance/Systemic-Design-Frameworks.md
deleted file mode 100644
index ba86633b..00000000
--- a/Graphics & Performance/Systemic-Design-Frameworks.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-3308A5
-category: "[[10_Wiki/💡 Topics/Graphics & Performance]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Systemic-Design-Frameworks"
----
-
-# [[Systemic-Design-Frameworks]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Graphics & Performance 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Systemic-Design-Frameworks.md]]
----
diff --git a/Graphics & Performance/Systems Theory.md b/Graphics & Performance/Systems Theory.md
deleted file mode 100644
index 9e83912d..00000000
--- a/Graphics & Performance/Systems Theory.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-B5E5CB
-category: "[[10_Wiki/💡 Topics/Graphics & Performance]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Systems Theory"
----
-
-# [[Systems Theory]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Graphics & Performance 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Systems Theory.md]]
----
diff --git a/Graphics & Performance/TLB design.md b/Graphics & Performance/TLB design.md
deleted file mode 100644
index 4ca8a5a8..00000000
--- a/Graphics & Performance/TLB design.md	
+++ /dev/null
@@ -1,36 +0,0 @@
----
-id: P-REINFORCE-AUTO-3CAF83
-category: "[[10_Wiki/💡 Topics/Graphics & Performance]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - TLB design"
----
-
-# [[TLB design]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 소스에 관련 정보가 부족합니다. 제공된 문헌에는 TLB design(Translation Lookaside Buffer 설계)에 대한 직접적이고 구체적인 정의나 기술적 설명이 포함되어 있지 않습니다.
-
-## 📖 구조화된 지식 (Synthesized Content)
-소스에 관련 정보가 부족합니다. 
-
-제공된 소스에서 'TLB design'과 관련하여 파악할 수 있는 유일한 단편적인 정보는 다음과 같습니다:
-
-* **GPU 보안 취약점과의 연관성:** 과거 WebGL을 통해 GPU에서 Rowhammer 공격을 실행한 심각한 보안 사례가 보고된 바 있습니다. 공격자들은 고정밀 타임스탬프 쿼리를 이용해 캐시 미스율을 확인하고 GPU의 물리적 메모리 레이아웃을 파악하여 특정 비트를 조작(flip)했습니다 [1].
-* **특정 설계에 국한된 공격:** 이 정교한 공격이 가능했던 이유는 공격 대상이 된 기기가 "매우 명확하게 정의된 TLB 설계(TLB design)"를 가지고 있었기 때문입니다. 즉, 특정 TLB 설계 구조가 해당 보안 취약점(Rowhammer)이 성립하기 위한 조건 중 하나로 작용했습니다 [1].
-* **최신 하드웨어의 방어:** 이러한 특정 TLB 설계를 타겟으로 한 공격은 최신 RAM에 적용된 Rowhammer 방어 기법(mitigations)을 통해 예방되었습니다 [1].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Graphics & Performance 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[Rowhammer]], [[WebGL]]
-- **Projects/Contexts:** [[WebGPU High Resolution Time Spec]]
-- **Contradictions/Notes:** 소스에 관련 정보가 부족합니다.
-
----
-*Last updated: 2026-04-19*
-- Raw Source: [[00_Raw/2026-04-20/TLB design.md]]
----
diff --git a/Graphics & Performance/TSL (Three Shader Language).md b/Graphics & Performance/TSL (Three Shader Language).md
deleted file mode 100644
index 7336f19b..00000000
--- a/Graphics & Performance/TSL (Three Shader Language).md	
+++ /dev/null
@@ -1,34 +0,0 @@
----
-id: P-REINFORCE-AUTO-C8966B
-category: "[[10_Wiki/💡 Topics/Graphics & Performance]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - TSL (Three Shader Language)"
----
-
-# [[TSL (Three Shader Language)]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> TSL (Three Shader Language)은 Three.js의 노드 기반 머티리얼 시스템입니다 [1]. 셰이더를 한 번 작성하면 WebGPU용 WGSL과 WebGL용 GLSL로 자동 컴파일되어 실행될 수 있게 해줍니다 [1, 2]. 로우 레벨(Raw) 셰이더를 직접 작성하는 것을 대체하며, 향후 Three.js에서 커스텀 셰이더를 구현하기 위한 권장 방식입니다 [1, 3].
-
-## 📖 구조화된 지식 (Synthesized Content)
-- **교차 컴파일 및 자동화**: TSL은 GLSL과 WGSL 두 개의 별도 코드베이스를 유지할 필요가 없도록 교차 컴파일을 지원합니다 [3]. 또한, 유니폼(Uniform)과 속성(Attribute) 데이터 처리를 자동으로 핸들링하여 개발 복잡도를 줄여줍니다 [3].
-- **동적 노드 머티리얼(Node Materials) 제어**: TSL 기반의 노드 머티리얼은 합성(Composable)이 가능하며, `positionNode`, `colorNode`, `normalNode`와 같은 속성을 통해 프로그래밍 방식으로 제어할 수 있어 기존 WebGL에서는 커스텀 셰이더가 필요했던 효과들을 동적으로 구현할 수 있습니다 [3, 4].
-- **재사용 가능한 셰이더 로직(Fn 패턴)**: `Fn` 패턴을 사용하여 재사용 가능한 셰이더 함수를 작성할 수 있습니다 [5]. 이렇게 작성된 함수는 한 번 컴파일된 후 여러 머티리얼에 걸쳐 재사용이 가능합니다 [5].
-- **내장 노이즈 함수**: TSL에는 MaterialX 노이즈 함수가 기본적으로 내장되어 있어, 외부 라이브러리에 의존하지 않고도 노이즈 효과를 구현할 수 있습니다 [5].
-- **WebGPU 네이티브 포스트 프로세싱**: WebGPU 기반의 프로젝트에서는 `pmndrs/postprocessing` 라이브러리 대신 TSL 노드를 사용하는 Three.js 내장 포스트 프로세싱을 사용하는 것이 컴퓨트 셰이더를 완벽히 지원하는 네이티브 해결책입니다 [6].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Graphics & Performance 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[WebGPU]], [[WebGL]], [[WGSL]], [[GLSL]], [[Node Material]]
-- **Projects/Contexts:** [[Three.js]]
-- **Contradictions/Notes:** 소스 간의 모순점은 없으나, 이전의 렌더링 방식과 달리 별도의 GLSL/WGSL 코드를 직접 작성하는 것보다 TSL을 사용하는 것이 코드 유지보수 및 교차 호환성 측면에서 명백히 우월하다고 강조하고 있습니다 [3].
-
----
-*Last updated: 2026-04-19*
-- Raw Source: [[00_Raw/2026-04-20/TSL (Three Shader Language).md]]
----
diff --git a/Graphics & Performance/Temporal-Logic.md b/Graphics & Performance/Temporal-Logic.md
deleted file mode 100644
index 614f1891..00000000
--- a/Graphics & Performance/Temporal-Logic.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-8C33E2
-category: "[[10_Wiki/💡 Topics/Graphics & Performance]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Temporal-Logic"
----
-
-# [[Temporal-Logic]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Graphics & Performance 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Temporal-Logic.md]]
----
diff --git a/Graphics & Performance/Texture Compression.md b/Graphics & Performance/Texture Compression.md
deleted file mode 100644
index 4383bb5d..00000000
--- a/Graphics & Performance/Texture Compression.md	
+++ /dev/null
@@ -1,39 +0,0 @@
----
-id: P-REINFORCE-AUTO-B90AAF
-category: "[[10_Wiki/💡 Topics/Graphics & Performance]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Texture Compression"
----
-
-# [[Texture Compression]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 텍스처 압축(Texture Compression)은 웹 기반 3D 애플리케이션(예: Three.js)에서 GPU 메모리(VRAM) 소비와 파일 다운로드 크기를 획기적으로 줄이기 위한 필수 최적화 기술입니다 [1-3]. PNG나 JPEG와 같은 일반적인 이미지 포맷이 GPU 메모리 내에서 압축이 완전히 풀리는 것과 달리, KTX2나 Basis Universal 같은 포맷은 GPU 상에서도 압축된 상태를 유지하여 하드웨어 가속 압축 해제를 지원합니다 [1, 3]. 이를 통해 메모리 대역폭 요구량을 줄이고 저사양 기기에서의 브라우저 크래시나 프레임 저하를 방지할 수 있습니다 [2, 3].
-
-## 📖 구조화된 지식 (Synthesized Content)
-*   **VRAM 점유율 및 메모리 효율성 향상**
-    PNG 및 JPEG 텍스처는 파일 크기가 작더라도 GPU 메모리(VRAM)에 로드될 때 압축이 완전히 해제됩니다 [1]. 예를 들어 200KB 크기의 PNG 파일이나 비압축 RGBA 포맷의 4096×4096 해상도 텍스처는 VRAM에서 각각 20MB 이상, 최대 64MB까지 공간을 차지할 수 있습니다 [1, 2]. 모바일 기기 등에서 텍스처 메모리가 500MB를 초과하면 가비지 컬렉션 지연 및 프레임 끊김 현상이 발생합니다 [2]. KTX2 및 Basis Universal과 같은 GPU 친화적 압축 포맷을 사용하면 텍스처가 GPU 상에서 압축된 상태로 유지되어 메모리 사용량을 75%에서 최대 약 10배까지 줄일 수 있습니다(예: 64MB에서 8-16MB로 감소) [1, 3, 4].
-*   **Basis Universal 및 플랫폼 호환성**
-    Basis Universal은 다양한 GPU 포맷을 지원하며, 로드 시점에 데스크톱(BC7), 모바일(ASTC), iOS(PVRTC) 등 각 플랫폼에 맞는 포맷으로 자동 트랜스코딩됩니다 [3, 4]. 블록 압축 알고리즘을 통해 시각적 품질을 보존하면서도 파일 크기를 PNG 대비 75~90% 줄여주며, 4:1에서 8:1 수준의 압축률을 제공하여 텍스처 다운로드 시간도 크게 단축합니다 [3, 4].
-*   **압축 알고리즘 선택 (UASTC vs ETC1S)**
-    에셋의 특성에 따라 적절한 압축 방식을 선택해야 합니다. 
-    *   **UASTC:** 파일 크기는 상대적으로 크지만 더 높은 품질을 제공하므로, 노멀 맵(Normal maps)이나 중요도가 높은 히어로 텍스처(Hero textures)에 적합합니다 [1, 5].
-    *   **ETC1S:** 품질은 수용 가능한 수준이면서 파일 크기를 더 작게 만들 수 있어, 디퓨즈(Diffuse) 텍스처, 환경 텍스처 및 보조 에셋에 적합합니다 [1, 5].
-*   **구현 및 툴 활용**
-    Three.js에서 Draco 및 KTX2를 사용하려면 초기 설정 시 적절한 디코더 경로를 구성해야 합니다 [6]. 또한 시각적인 품질 저하 없이 얼마나 압축할 수 있는지 확인하기 위해 Shopify의 `gltf-compressor`와 같은 도구를 사용하여 압축 전후를 대조하고 최적의 값을 찾는 것이 권장됩니다 [5].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Graphics & Performance 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[KTX2]], [[Basis Universal]], [[UASTC]], [[ETC1S]], [[VRAM]]
-- **Projects/Contexts:** [[Three.js]], [[WebGL]], [[gltf-compressor]]
-- **Contradictions/Notes:** 소스에 내용 충돌은 없으며, PNG/JPEG 포맷은 파일 크기(예: 200KB)가 작더라도 GPU 메모리에 올라갈 때 압축이 해제되어 막대한 VRAM(예: 20MB+)을 소모하므로 KTX2와 같은 전용 텍스처 압축 기술이 필수적이라고 일관되게 강조하고 있습니다 [1].
-
----
-*Last updated: 2026-04-19*
-- Raw Source: [[00_Raw/2026-04-20/Texture Compression.md]]
----
diff --git a/Graphics & Performance/The Rapture Setting.md b/Graphics & Performance/The Rapture Setting.md
deleted file mode 100644
index cd931f18..00000000
--- a/Graphics & Performance/The Rapture Setting.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-180DD3
-category: "[[10_Wiki/💡 Topics/Graphics & Performance]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - The Rapture Setting"
----
-
-# [[The Rapture Setting]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Graphics & Performance 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/The Rapture Setting.md]]
----
diff --git a/Graphics & Performance/The-Space-Syntax-Laboratory.md b/Graphics & Performance/The-Space-Syntax-Laboratory.md
deleted file mode 100644
index fea0bce1..00000000
--- a/Graphics & Performance/The-Space-Syntax-Laboratory.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-64715F
-category: "[[10_Wiki/💡 Topics/Graphics & Performance]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - The-Space-Syntax-Laboratory"
----
-
-# [[The-Space-Syntax-Laboratory]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Graphics & Performance 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/The-Space-Syntax-Laboratory.md]]
----
diff --git a/Graphics & Performance/Three Shader Language (TSL).md b/Graphics & Performance/Three Shader Language (TSL).md
deleted file mode 100644
index 377ecb42..00000000
--- a/Graphics & Performance/Three Shader Language (TSL).md	
+++ /dev/null
@@ -1,33 +0,0 @@
----
-id: P-REINFORCE-AUTO-1AF9EB
-category: "[[10_Wiki/💡 Topics/Graphics & Performance]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Three Shader Language (TSL)"
----
-
-# [[Three Shader Language (TSL)]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> TSL(Three Shader Language)은 WebGPU의 WGSL과 WebGL의 GLSL로 모두 컴파일될 수 있는 Three.js의 노드 기반 머티리얼 및 셰이더 시스템입니다 [1]. 개발자가 셰이더 코드를 한 번만 작성하면 여러 플랫폼에서 실행 가능하도록 자동 교차 컴파일을 지원하여 코드 중복을 방지합니다 [1-3]. 유니폼 및 속성 관리를 자동으로 처리해주며, 향후 Three.js에서 커스텀 셰이더를 개발하기 위한 권장 방식으로 평가받고 있습니다 [1, 2, 4].
-
-## 📖 구조화된 지식 (Synthesized Content)
-*   **단일 코드베이스와 자동 교차 컴파일:** TSL은 원시(raw) GLSL 또는 WGSL을 직접 작성하여 두 개의 셰이더 코드베이스를 유지해야 하는 수고를 덜어줍니다 [2]. 작성된 코드는 WebGPU 및 WebGL 환경 모두에 맞춰 자동으로 교차 컴파일되며, 유니폼(uniforms) 및 속성(attributes) 처리 역시 TSL이 자동으로 관리합니다 [2, 4].
-*   **노드 기반 머티리얼 제어:** TSL의 노드 머티리얼은 조합이 가능(composable)하며, `positionNode`, `colorNode`, `normalNode`와 같은 속성을 수용하여 프로그래밍 방식의 제어를 지원합니다 [2, 5]. 이를 통해 기존 WebGL 환경에서는 별도의 복잡한 커스텀 셰이더를 작성해야만 했던 동적인 렌더링 효과를 더 쉽게 구현할 수 있습니다 [5].
-*   **코드 재사용성 및 내장 함수:** 개발자는 `Fn` 패턴을 활용하여 재사용 가능한 TSL 함수를 작성할 수 있으며, 이 함수들은 한 번 컴파일된 후 여러 머티리얼에 걸쳐 자유롭게 재사용할 수 있습니다 [6]. 또한, MaterialX 노이즈 함수와 같은 유용한 기능들이 내장되어 있어 외부 라이브러리에 의존하지 않고도 노이즈 관련 셰이더 로직을 구현할 수 있습니다 [6].
-*   **WebGPU 포스트 프로세싱 지원:** WebGPU 기반 프로젝트의 경우, TSL 노드와 결합된 Three.js의 내장(native) 포스트 프로세싱 기능을 사용하는 것이 권장됩니다 [7]. 이는 전체 컴퓨트 셰이더(compute shader) 지원이 통합된 WebGPU용 네이티브 솔루션으로 작동합니다 [7].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Graphics & Performance 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[WebGPU]], [[WebGL]], [[WGSL]], [[GLSL]], [[Node Material]]
-- **Projects/Contexts:** [[Three.js 크로스 플랫폼 커스텀 셰이더 및 포스트 프로세싱 개발]]
-- **Contradictions/Notes:** 기존 WebGL 프로젝트에서는 외부 라이브러리인 `pmndrs/postprocessing`이 여전히 훌륭한 선택지로 평가되지만, WebGPU 프로젝트 환경에서는 TSL 노드 기반의 Three.js 네이티브 포스트 프로세싱을 사용하는 것으로 개발 방식이 전환될 것을 권장하고 있습니다 [7].
-
----
-*Last updated: 2026-04-19*
-- Raw Source: [[00_Raw/2026-04-20/Three Shader Language (TSL).md]]
----
diff --git a/Graphics & Performance/Three.js 렌더링 최적화.md b/Graphics & Performance/Three.js 렌더링 최적화.md
deleted file mode 100644
index 8496b87d..00000000
--- a/Graphics & Performance/Three.js 렌더링 최적화.md	
+++ /dev/null
@@ -1,29 +0,0 @@
----
-id: P-REINFORCE-AI-046
-category: "[[10_Wiki/💡 Topics/Graphics & Performance]]"
-confidence_score: 0.97
-tags: [three.js, webgl, rendering, optimization]
-last_reinforced: 2026-06-XX
-github_commit: "[P-Reinforce] Processed Three.js WebGL 렌더링 최적화."
----
-
-# [[Three.js 렌더링 최적화]] (이전 배치와 동일한 내용)
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 대규모 웹 환경에서 WebGL 기반 3D 씬을 구현할 때, 단순한 모델 로딩 이상의 관점에서 드로우 콜 감소, 자원 재활용, 그리고 GPU/CPU 부하 분산을 통해 성능 병목을 해결하는 것이 핵심이다.
-
-## 📖 구조화된 지식 (Synthesized Content)
-- **성능 최적화의 목표:** 웹 브라우저 환경에서 높은 프레임률(60FPS 이상)을 유지하면서 복잡한 3D 시각화를 구현하는 것이다. 주요 병목 구간은 CPU/GPU 자원 관리와 데이터 전송량에 있다.
-- **핵심 기술 및 전략:** (생략 - 핵심 내용은 이미 위키화 되어있음)
-    1. **드로우 콜 최적화 (Draw Call Optimization):** Instancing, Batching을 통해 GPU 부하를 줄인다.
-    2. **자원 관리 (Resource Management):** Dispose() 호출을 통한 메모리 누수 방지 및 효율적인 자원 재활용.
-    3. **렌더링 기법 개선:** LOD, Culling 등 하드웨어 기반 최적화 적용.
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **정책 변화:** WebGPU의 도입은 기존 WebGL의 한계를 뛰어넘는 가장 중요한 패러다임 전환점이며, 이를 활용한 컴퓨팅 기능(Compute Shader)이 핵심 트렌드로 부상 중이다.
-
-## 🔗 지식 연결 (Graph)
-- Parent: [[WebGL Optimization]]
-- Related: [[InstancedMesh]] , [[Draw Call Optimization]] , [[WebGPU]]
-- Raw Source: [[00_Raw/Three.js WebGL 렌더링 최적화.md]]
----
\ No newline at end of file
diff --git a/Graphics & Performance/Threejs WebGL Rendering Optimization.md b/Graphics & Performance/Threejs WebGL Rendering Optimization.md
deleted file mode 100644
index a5099969..00000000
--- a/Graphics & Performance/Threejs WebGL Rendering Optimization.md	
+++ /dev/null
@@ -1,51 +0,0 @@
----
-id: P-REINFORCE-AUTO-46187E
-category: "[[10_Wiki/💡 Topics/Graphics & Performance]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Threejs WebGL Rendering Optimization"
----
-
-# [[Threejs WebGL Rendering Optimization]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> Three.js WebGL 렌더링 최적화는 3D 웹 애플리케이션의 프레임 속도를 향상시키고 메모리 사용량을 줄이기 위한 기술적 접근 방식을 의미합니다 [1, 2]. 이 최적화의 핵심은 CPU와 GPU 간의 병목 현상을 유발하는 드로우 콜(Draw Call) 횟수를 최소화하고, 메모리 대역폭을 효율적으로 관리하는 것입니다 [3, 4]. 이를 위해 `InstancedMesh`, `BatchedMesh`, 기하학 병합(Geometry Merging), 텍스처 압축, 그리고 시야 절두체 컬링(Frustum Culling)과 같은 다양한 기법이 활용되며, 2026년 도입된 WebGPU 기술은 컴퓨트 셰이더를 통해 렌더링 한계를 더욱 확장시켰습니다 [3, 5-8].
-
-## 📖 구조화된 지식 (Synthesized Content)
-**드로우 콜 최적화 (Draw Call Optimization)**
-*   CPU가 GPU에 렌더링 명령을 내리는 드로우 콜은 상태 변경 및 준비 과정에서 막대한 오버헤드를 발생시킵니다 [4, 9, 10]. 매끄러운 60fps 성능을 유지하기 위해 프레임당 드로우 콜을 100회 미만으로 유지하는 것이 권장됩니다 [11-13].
-*   동일한 기하학적 구조와 재질을 가진 객체가 수백, 수천 개 반복될 때는 단일 드로우 콜로 렌더링을 처리할 수 있는 `InstancedMesh`를 사용하는 것이 가장 효율적입니다 [11, 14, 15].
-*   반면 재질은 공유하지만 각기 다른 기하학적 구조를 가진 객체들을 렌더링할 때는 `BatchedMesh`를 사용하여 하나의 드로우 콜로 묶을 수 있습니다 [5, 16, 17].
-*   정적인 환경 객체(건물, 지형 등)는 `BufferGeometryUtils`를 사용하여 로드 시점에 하나의 기하학으로 병합(Merge)하는 것이 유리합니다 [6, 16, 18]. 단, 병합된 객체는 개별적으로 애니메이션을 주거나 독립적인 컬링(Culling)을 적용할 수 없는 단점이 있습니다 [6, 18].
-
-**메모리 및 에셋 관리 (Memory and Asset Management)**
-*   Three.js는 GPU 리소스를 자동으로 가비지 컬렉션(Garbage Collect)하지 않으므로, 사용이 끝난 기하학, 재질, 텍스처, 렌더 타겟은 반드시 `.dispose()`를 호출하여 GPU 메모리에서 명시적으로 삭제해야 메모리 누수를 막을 수 있습니다 [19-21]. 
-*   3D 모델의 기하학적 데이터를 Draco로 압축하면 파일 크기를 90~95%까지 줄일 수 있으며, KTX2 (Basis Universal) 텍스처 압축을 사용하면 일반 PNG 대비 GPU 메모리(VRAM) 사용량을 대폭 절감할 수 있습니다 [12, 22-24].
-*   수많은 작은 텍스처들은 텍스처 아틀라스(Texture Atlas)나 배열 텍스처(Data Array Texture)로 결합하여 텍스처 바인딩 횟수를 줄여야 합니다 [25-27].
-
-**InstancedMesh의 구조적 한계와 성능 병목**
-*   **비효율적인 절두체 컬링(Frustum Culling):** `InstancedMesh`는 내부의 개별 인스턴스가 아닌, 전체 인스턴스를 포함하는 거대한 바운딩 볼륨을 기준으로 컬링을 수행합니다 [28]. 즉, 단 하나의 인스턴스만 시야에 있어도 화면 밖의 모든 인스턴스에 대해 강제적인 정점 연산이 발생하여 GPU 자원이 낭비될 수 있습니다 [28, 29].
-*   **오버드로우(Overdraw) 발생:** `InstancedMesh` 내의 인스턴스들은 렌더링 순서가 자동 정렬되지 않으므로 앞뒤 객체 간 오버드로우(동일 픽셀 영역에 중복 계산)가 발생합니다 [30, 31]. 이는 불투명 객체의 프래그먼트 병목을 유발하고 투명한 객체에서는 심각한 시각적 오류를 발생시킵니다 [31, 32].
-*   **레이캐스팅(Raycasting) 제약:** 움직이는 인스턴스들에 대해 레이캐스팅이 정상 작동하려면 인스턴스 행렬이 변경된 후 반드시 `computeBoundingSphere()`와 `computeBoundingBox()`를 호출하여 바운딩 볼륨을 다시 계산해야 합니다 [33, 34].
-
-**셰이더, LOD 및 WebGPU 렌더링 파이프라인**
-*   카메라 거리에 따라 고해상도 메쉬를 저해상도 메쉬나 단순한 임포스터(빌보드)로 교체하는 LOD (Level of Detail) 시스템을 구현하면 프레임 속도를 크게 방어할 수 있습니다 [13, 35-37].
-*   저사양 통합 GPU 환경에서는 오버드로우로 인한 픽셀 처리 부하를 줄이기 위해 먼저 깊이(Depth)만 렌더링한 후(색상 쓰기 비활성화), 실제 렌더링에서 깊이 테스트를 EQUAL로 설정하여 가려진 픽셀 연산을 생략하는 'Depth Pre-Pass' 기법이 효과적입니다 [38, 39]. 또한 물리 기반 렌더링인 `MeshStandardMaterial` 대신 계산 비용이 저렴한 `MeshPhongMaterial`을 활용하면 성능 향상에 도움이 됩니다 [40, 41].
-*   2026년 기준, WebGL에서 WebGPU(`WebGPURenderer`)로 전환하면 컴퓨트 셰이더(Compute Shaders)를 활용하여 CPU가 처리하던 대규모 파티클 시스템 업데이트, 물리 시뮬레이션 연산 등을 GPU 병렬 처리로 넘겨 비약적인 성능 향상(최대 100배)을 이룰 수 있습니다 [7, 42-45].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Graphics & Performance 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[Draw Call]], [[InstancedMesh]], [[BatchedMesh]], [[Level of Detail (LOD)]], [[Frustum Culling]], [[WebGPU]]
-- **Projects/Contexts:** [[Segments.ai WebGPU Migration]], [[InstancedMesh2 Library]], [[Three.js WebGPURenderer (r171+)]]
-- **Contradictions/Notes:** 
-  - `BatchedMesh`는 다수의 고유 기하학 객체를 단일 드로우 콜로 묶어주는 훌륭한 최적화 도구이지만 [5, 16], 20만 개가 넘는 수준의 과도하게 많은 지오메트리에 적용할 경우 버퍼의 draw "starts" 및 "counts" 데이터를 매 프레임 업데이트해야 하는 오버헤드로 인해 오히려 CPU 사용률이 폭증하고 기존의 Merged Mesh 방식보다 성능이 크게 저하되는 현상이 발생할 수 있습니다 [46-49].
-  - `InstancedMesh`는 드로우 콜을 혁신적으로 줄여주지만, 인스턴스들이 정렬되지 않아 막대한 오버드로우를 유발하므로, 객체가 겹치는 씬의 경우 여러 개의 개별 Mesh를 공유 속성으로 렌더링하는 것보다 오히려 프레임 속도가 더 떨어지는 역설적인 상황이 발생할 수 있습니다 [30, 31, 50].
-
----
-*Last updated: 2026-04-19*
-- Raw Source: [[00_Raw/2026-04-20/Three.js WebGL Rendering Optimization.md]]
----
diff --git a/Graphics & Performance/Threejs WebGPU 파티클 예제.md b/Graphics & Performance/Threejs WebGPU 파티클 예제.md
deleted file mode 100644
index 42b4651d..00000000
--- a/Graphics & Performance/Threejs WebGPU 파티클 예제.md	
+++ /dev/null
@@ -1,33 +0,0 @@
----
-id: P-REINFORCE-AUTO-A9D3D4
-category: "[[10_Wiki/💡 Topics/Graphics & Performance]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Threejs WebGPU 파티클 예제"
----
-
-# [[Threejs WebGPU 파티클 예제]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> Three.js에서 전통적인 CPU 기반의 파티클 업데이트는 약 5만 개 수준에서 병목 현상이 발생하지만, WebGPU 컴퓨트 셰이더를 활용하면 이를 수백만 개 단위로 확장할 수 있습니다 [1]. WebGPU 파티클 예제들은 `instancedArray`와 같은 GPU 영구 버퍼를 사용하여 CPU와 GPU 간의 데이터 전송 부하를 제거하는 방식을 보여줍니다 [1]. 이러한 최적화 기술은 Expo 2025 Osaka와 같은 실제 프로젝트에서 100만 개의 파티클을 지연 없이 실시간으로 렌더링하는 데 성공적으로 적용되었습니다 [2, 3].
-
-## 📖 구조화된 지식 (Synthesized Content)
-* **성능 한계 돌파:** 일반적인 하드웨어 환경에서 CPU를 이용해 파티클을 업데이트할 경우 보통 50,000개 정도에서 성능 병목이 발생합니다 [1]. 하지만 파티클 시스템을 WebGPU의 컴퓨트 셰이더(Compute Shaders)로 이동시키면 한계를 수백만 개 수준으로 끌어올릴 수 있습니다 [1].
-* **영구적인 GPU 버퍼 사용 (`instancedArray`):** Three.js WebGPU 파티클 예제에서는 `instancedArray`를 사용하여 프레임 간 데이터가 유지되는 영구적인 GPU 버퍼를 생성합니다 [1]. 이 방식은 전통적인 파티클 시스템에서 성능 저하의 주원인이었던 CPU와 GPU 간의 데이터 전송 과정을 완전히 제거하여 성능을 극대화합니다 [1].
-* **대규모 실제 적용 사례:** 고성능 WebGPU 파티클 시스템의 강력함을 보여주는 대표적인 실제 사례로 2025년 오사카 엑스포(Expo 2025 Osaka)의 "Waves of Connection" (Hokusai 인스톨레이션)이 있습니다 [2, 3]. 이 프로젝트에서는 98인치 4K 디스플레이 환경에서 100만 개의 파티클을 이용한 유체 시뮬레이션을 지연 현상 없이 실시간으로 렌더링했으며, 다인원 바디 트래킹까지 원활하게 처리했습니다 [2, 3].
-* **컴퓨트 셰이더의 연산 확장성:** 파티클 렌더링 외에도 물리 연산, 충돌 감지, 실시간 데이터 필터링 등 연산 집약적인 작업들은 WebGPU 컴퓨트 셰이더를 통해 수천 개의 GPU 코어에서 병렬로 처리될 수 있습니다 [4, 5].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Graphics & Performance 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[WebGPU Compute Shaders]], [[instancedArray]]
-- **Projects/Contexts:** [[Expo 2025 Osaka]], [[Waves of Connection]]
-- **Contradictions/Notes:** 소스 내용에 따르면, WebGPU 파티클 예제는 WebGL 기반의 단일 스레드 CPU 처리 한계(약 5만 개)를 극복하기 위해 컴퓨트 셰이더 연산과 영구적인 GPU 데이터 할당 구조를 결합하여 수십 배 이상의 파티클을 렌더링할 수 있는 방향으로 발전하고 있습니다 [1, 5, 6].
-
----
-*Last updated: 2026-04-19*
-- Raw Source: [[00_Raw/2026-04-20/Three.js WebGPU 파티클 예제.md]]
----
diff --git a/Graphics & Performance/Threejs 대규모 렌더링 최적화 파이프라인.md b/Graphics & Performance/Threejs 대규모 렌더링 최적화 파이프라인.md
deleted file mode 100644
index 2c1c069a..00000000
--- a/Graphics & Performance/Threejs 대규모 렌더링 최적화 파이프라인.md	
+++ /dev/null
@@ -1,35 +0,0 @@
----
-id: P-REINFORCE-AUTO-8E841B
-category: "[[10_Wiki/💡 Topics/Graphics & Performance]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Threejs 대규모 렌더링 최적화 파이프라인"
----
-
-# [[Threejs 대규모 렌더링 최적화 파이프라인]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> Three.js 대규모 렌더링 최적화 파이프라인은 수많은 3D 객체를 브라우저 환경에서 매끄럽게 렌더링하기 위해 CPU와 GPU 간의 통신 오버헤드, 즉 드로우 콜(Draw Call)과 메모리 병목 현상을 극복하는 일련의 기술적 아키텍처입니다 [1, 2]. 주로 InstancedMesh와 BatchedMesh를 통한 드로우 콜 최소화, Draco 및 KTX2 등을 이용한 에셋 압축, 절두체 컬링(Frustum Culling) 및 LOD 시스템을 활용하여 그래픽 자원의 낭비를 줄입니다 [3-6]. 최근에는 WebGPU와 컴퓨트 셰이더(Compute Shader)가 도입되어 렌더링 제어 및 가시성 판단 연산을 GPU로 대거 이관함으로써, 더욱 막대한 규모의 씬을 유연하게 처리할 수 있는 차세대 파이프라인으로 진화하고 있습니다 [7-9].
-
-## 📖 구조화된 지식 (Synthesized Content)
-- **드로우 콜(Draw Call) 최소화 전략:** 실시간 렌더링 성능을 저하시키는 가장 결정적인 요인은 CPU가 렌더링 상태를 변경하고 GPU에 명령을 내리는 드로우 콜의 오버헤드입니다 [2, 10]. 원활한 60fps를 유지하려면 프레임당 드로우 콜을 100회 미만으로 타겟팅해야 합니다 [4, 11]. 이를 위해 동일한 기하학적 구조와 재질을 공유하는 객체는 `InstancedMesh`를 활용하여 수천 개를 단일 드로우 콜로 처리하며 [4, 5, 12], 재질은 같으나 지오메트리가 다양한 객체들은 `BatchedMesh`를 통해 최적화합니다 [13-15]. 정적인 배경이나 환경 모델은 `BufferGeometryUtils`를 사용해 하나의 지오메트리로 병합(Merging)하는 방법이 사용됩니다 [13, 16].
-- **가시성 판단(Culling) 및 정렬 한계 극복:** `InstancedMesh`는 엔진 내부에서 단일 객체로 취급되기 때문에, 기본 절두체 컬링이 개별 인스턴스에는 작동하지 않는 '전부 아니면 전무' 방식의 한계를 가집니다 [17]. 이로 인해 화면 밖의 객체까지 정점 연산이 강제되고, 거리 기반 자동 정렬의 부재로 인해 막대한 오버드로우(Overdraw) 현상을 일으킬 수 있습니다 [18, 19]. 이에 대응하기 위해 BVH(Bounding Volume Hierarchy)를 결합하여 인스턴스 단위의 개별 컬링과 정렬을 지원하는 확장 라이브러리(예: `InstancedMesh2`)를 사용하거나 [20-22], 거리에 따라 모델 해상도를 낮추는 LOD(Level of Detail) 기법을 함께 적용하여 연산량을 제한합니다 [6, 11, 23].
-- **메모리 대역폭 및 에셋 최적화:** 대형 어셈블리 모델이나 포인트 클라우드의 VRAM 고갈과 대역폭 한계를 막는 것은 파이프라인의 핵심입니다. Draco 압축을 통해 지오메트리 파일 크기를 최대 95%까지 축소시키고 [3, 24], KTX2나 Basis Universal 포맷을 적용하여 텍스처가 압축된 상태로 GPU 메모리에 상주하도록 만들어 메모리 소비를 약 10배 절감합니다 [3, 25]. 또한 다양한 재질의 텍스처를 하나의 텍스처 아틀라스(Texture Atlas)나 배열 텍스처(Data Array Textures)로 결합하면 텍스처 바인딩으로 인한 상태 변경 비용을 크게 줄일 수 있습니다 [26-29].
-- **WebGPU 기반 차세대 렌더링 파이프라인:** 2026년 기준, Three.js(r171 이상)의 `WebGPURenderer` 및 TSL(Three Shader Language) 도입으로 대규모 렌더링 구조가 혁신적으로 변화했습니다 [7, 30]. 일반적인 CPU 한계를 초과하던 100만 개 이상의 파티클 연산, 물리 시뮬레이션, 복잡한 군중 애니메이션 등을 컴퓨트 셰이더(Compute Shader)를 통한 GPU-driven Rendering으로 병렬 처리할 수 있게 되었습니다 [31-34]. Native WebGPU 수준에서는 `GPURenderBundles` 및 Indirect Drawing 기술을 통해 500MB 이상의 초대형 건설/BIM 데이터셋에서도 강력한 성능 향상을 이끌어냅니다 [35, 36].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Graphics & Performance 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** `[[InstancedMesh]]`, `[[BatchedMesh]]`, `[[WebGPU]]`, `[[Draw Call (드로우 콜)]]`, `[[Frustum Culling (절두체 컬링)]]`, `[[LOD (Level of Detail)]]`, `[[Overdraw (오버드로우)]]`, `[[Compute Shader (컴퓨트 셰이더)]]`
-- **Projects/Contexts:** `[[InstancedMesh2 (agargaro)]]`, `[[Three.js r171 WebGPURenderer]]`, `[[Segments.ai]]`, `[[Fragment (IFC.js)]]`
-- **Contradictions/Notes:** 
-  - `InstancedMesh`는 드로우 콜을 줄여 성능을 크게 향상시키도록 설계되었으나, 불투명도 및 복잡한 셰이더 환경에서는 인스턴스 정렬 부재로 인한 심각한 오버드로우(Overdraw)를 유발해 일반 개별 Mesh(Shared attributes)를 사용할 때보다 프레임 레이트(FPS)가 오히려 낮아지는 역설적인 사례가 보고되고 있습니다 [18, 19].
-  - `BatchedMesh` 역시 다수의 기하학적 구조를 통합하는 유용한 기술이지만, 약 20만 개 수준의 대량 지오메트리에 적용할 시 버퍼 데이터 업로드 등의 이유로 CPU 사용량이 30~50% 급증하며 병합된 기하학(Merged Geometry)보다 현저히 성능이 하락하는 구조적 병목이 제기되고 있습니다 [37-39].
-
----
-*Last updated: 2026-04-19*
-- Raw Source: [[00_Raw/2026-04-20/Three.js 대규모 렌더링 최적화 파이프라인.md]]
----
diff --git a/Graphics & Performance/Threejs 렌더링 성능 최적화.md b/Graphics & Performance/Threejs 렌더링 성능 최적화.md
deleted file mode 100644
index 47bc9add..00000000
--- a/Graphics & Performance/Threejs 렌더링 성능 최적화.md	
+++ /dev/null
@@ -1,46 +0,0 @@
----
-id: P-REINFORCE-AUTO-4EE7A9
-category: "[[10_Wiki/💡 Topics/Graphics & Performance]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Threejs 렌더링 성능 최적화"
----
-
-# [[Threejs 렌더링 성능 최적화]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> Three.js 렌더링 성능 최적화는 브라우저 환경에서 3D 씬을 부드럽게 렌더링하기 위해 CPU와 GPU 간의 병목 현상을 줄이고 하드웨어 자원의 효율성을 극대화하는 일련의 기법을 의미합니다. 가장 핵심적인 목표는 CPU 오버헤드를 유발하는 드로우 콜(Draw Call) 횟수를 프레임당 100회 미만으로 유지하는 것이며, 이를 위해 인스턴싱(Instancing)과 배칭(Batching) 같은 기술이 필수적으로 사용됩니다 [1-5]. 또한, 에셋 압축, 메모리 관리, 셰이더 및 시야 절두체 컬링(Frustum Culling) 조정, WebGPU와 컴퓨트 셰이더의 도입 등을 통해 전반적인 연산 부하를 다각도로 최적화합니다 [1, 6-8].
-
-## 📖 구조화된 지식 (Synthesized Content)
-* **드로우 콜(Draw Call) 최적화**
-  * **InstancedMesh:** 동일한 기하학적 구조(Geometry)와 재질(Material)을 가진 수천 개의 객체를 단 한 번의 드로우 콜로 렌더링하여 CPU-GPU 간 명령 발행 오버헤드를 대폭 감소시킵니다 [2, 9-11]. 하지만 기본적으로 전체 인스턴스를 하나로 묶어 단일 시야 절두체 컬링을 수행하므로 화면 밖의 객체까지 연산할 수 있으며, 깊이 정렬이 자동 지원되지 않아 오버드로우(Overdraw)로 인한 프래그먼트 셰이더 병목을 유발할 수 있습니다 [12-15].
-  * **BatchedMesh:** 재질은 동일하지만 기하학적 구조가 다른 여러 객체를 하나의 드로우 콜로 묶어 렌더링할 수 있는 객체입니다 [16-19]. 복잡하고 이질적인 부품이 많은 모델에 유용하지만, 정렬(Sorting) 및 개별 객체 컬링을 수행하는 과정과 멀티 드로우(`multiDrawElementsWEBGL`) API의 오버헤드로 인해 정점 수가 매우 많은 상황에서는 CPU 점유율이 40~60%까지 치솟고 프레임률이 급락하는 성능 저하가 발생할 수 있습니다 [19-22].
-  * **지오메트리 병합 (Geometry Merging):** 움직이지 않는 정적인 객체들은 로딩 시점에 `BufferGeometryUtils`를 사용하여 하나의 메쉬로 병합함으로써 드로우 콜을 1회로 줄일 수 있습니다 [16, 23-25]. 하지만 이는 메모리 사용량을 크게 증가시키고 개별 객체의 제어나 컬링이 불가능해지는 단점이 있습니다 [23-25].
-
-* **에셋 압축 및 메모리 관리**
-  * 모델의 기하학적 용량을 90-95% 줄여주는 Draco 압축과, VRAM 내에서 압축 상태를 유지해 텍스처 메모리 사용량을 대폭 줄여주는 KTX2 또는 Basis Universal 텍스처 포맷 사용이 강력히 권장됩니다 [3, 26-29].
-  * Three.js는 GPU 리소스를 자동으로 가비지 컬렉트하지 않으므로, 사용이 끝난 `geometry`, `material`, `texture` 및 렌더 타겟에 대해 반드시 `.dispose()`를 호출하여 메모리 누수를 방지해야 합니다 [30-33].
-
-* **시각적 최적화 및 셰이더 기법**
-  * **LOD (Level of Detail):** 카메라와의 거리에 따라 객체를 단순한 폴리곤 버전을 사용하거나 임포스터(Billboard Impostor)로 교체하여 프래그먼트 연산 비용과 삼각형 수를 극적으로 줄일 수 있습니다 [7, 34-37]. 단, LOD는 드로우 콜 자체를 줄여주지는 않으므로 병목의 원인에 맞춰 사용해야 합니다 [38].
-  * 다수의 텍스처 바인딩 비용을 줄이기 위해 여러 텍스처를 한 이미지에 담는 텍스처 아틀라스(Texture Atlas)나 최신의 데이터 배열 텍스처(Data Array Textures)를 활용하여 상태 변경(State Change)을 최소화합니다 [39-42].
-  * 연산량이 많은 조명과 그림자는 정적 씬의 경우 라이트맵이나 주변 차폐 맵(AO Maps)으로 사전에 구워(Baking) 연산을 완전히 대체해야 합니다 [43-45]. 모바일 환경에서는 셰이더 변수 정밀도를 `mediump`로 낮춰 성능을 2배가량 향상시킬 수 있습니다 [46].
-
-* **WebGPU 시대의 도래 (2026년 기준)**
-  * Three.js r171부터 도입된 WebGPURenderer는 무거운 드로우 콜 환경이나 수백만 개의 파티클 연산에 컴퓨트 셰이더(Compute Shaders)를 적용하여 CPU의 단일 스레드 한계를 극복하고 100배 이상의 성능 향상을 가능하게 합니다 [8, 47-49].
-  * TSL (Three Shader Language)을 사용하면 WGSL(WebGPU)과 GLSL(WebGL) 양쪽 모두에서 호환되는 크로스 플랫폼 커스텀 셰이더를 구축할 수 있습니다 [50, 51].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Graphics & Performance 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[드로우 콜 (Draw Call)]], [[InstancedMesh]], [[BatchedMesh]], [[LOD (Level of Detail)]], [[WebGPU]]
-- **Projects/Contexts:** [[Three.js r171 WebGPU 도입]], [[IFC.js Fragment 아키텍처]], [[InstancedMesh2 라이브러리]]
-- **Contradictions/Notes:** 다양한 지오메트리를 한 번에 렌더링하기 위해 제안된 `BatchedMesh`는 드로우 콜 최적화의 훌륭한 대안으로 소개되지만[18], 다른 소스에서는 1,000만 개가 넘는 트라이앵글 환경에서 인스턴싱 또는 일반 `Merged Mesh`보다 CPU 점유율을 비정상적으로 높이고 프레임률을 크게 떨어뜨리는 심각한 구조적 오버헤드가 있음을 상반되게 지적하고 있습니다[19-22]. 또한 `InstancedMesh` 역시 만능이 아니며 정렬의 부재로 인해 발생하는 심각한 오버드로우(Overdraw) 때문에 일반 메쉬 렌더링보다 느려지는 병목 사례가 보고되고 있습니다[13, 14].
-
----
-*Last updated: 2026-04-19*
-- Raw Source: [[00_Raw/2026-04-20/Three.js 렌더링 성능 최적화.md]]
----
diff --git a/Graphics & Performance/Threejs 렌더링 최적화.md b/Graphics & Performance/Threejs 렌더링 최적화.md
deleted file mode 100644
index 445a6b75..00000000
--- a/Graphics & Performance/Threejs 렌더링 최적화.md	
+++ /dev/null
@@ -1,34 +0,0 @@
----
-id: P-REINFORCE-AUTO-13670A
-category: "[[10_Wiki/💡 Topics/Graphics & Performance]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Threejs 렌더링 최적화"
----
-
-# [[Threejs 렌더링 최적화]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> Three.js 렌더링 최적화는 웹 환경에서 3D 그래픽을 부드럽고 효율적으로 구동하기 위해 CPU와 GPU 간의 병목 현상을 해소하는 일련의 기술적 과정입니다 [1-3]. 핵심 목표는 초당 프레임 수(FPS)를 안정적으로 유지하기 위해 드로우 콜(Draw Call) 횟수를 최소화하고, 메모리 대역폭을 효율적으로 관리하는 것입니다 [4-7]. 이를 위해 인스턴싱(Instancing), 배칭(Batching), 에셋 압축, 디테일 수준(LOD) 조절 및 최신 WebGPU API의 도입이 필수적으로 요구됩니다 [4, 8-10].
-
-## 📖 구조화된 지식 (Synthesized Content)
-- **드로우 콜(Draw Call)의 최소화:** 드로우 콜은 CPU가 GPU에게 렌더링을 지시하는 명령으로, 과도한 호출에 따른 오버헤드는 성능을 저하시키는 가장 큰 원인입니다 [3, 11, 12]. 원활한 60fps를 유지하기 위해서는 프레임당 드로우 콜을 100회 미만으로 유지하는 것이 권장됩니다 [5, 8, 13].
-- **InstancedMesh와 BatchedMesh 활용:** 동일한 기하학적 구조와 재질을 가진 반복적인 객체(예: 나무, 군중)를 렌더링할 때는 `InstancedMesh`를 사용하여 단일 드로우 콜로 수많은 객체를 렌더링해야 합니다 [5, 14-16]. 반면, 재질은 동일하지만 지오메트리가 서로 다른 객체들을 그룹화하여 렌더링할 때는 `BatchedMesh`를 사용하는 것이 효율적입니다 [17-20].
-- **에셋 및 메모리 최적화:** 지오메트리 파일 크기를 최대 95%까지 줄여주는 Draco 압축을 사용하고, VRAM 사용량을 대폭 감소시키며 GPU에서 직접 압축이 해제되는 KTX2 및 Basis Universal 텍스처 형식을 적용해야 합니다 [8, 21-23]. 또한 사용이 끝난 지오메트리, 재질, 텍스처, 렌더 타겟 등은 반드시 `.dispose()`를 호출하여 명시적으로 GPU 메모리를 해제해야 누수를 방지할 수 있습니다 [24-27].
-- **LOD(Level of Detail) 및 컬링:** 카메라와의 거리에 따라 폴리곤 수가 적은 모델이나 임포스터(Impostor)로 교체하여 렌더링 연산을 줄이는 LOD 시스템을 구현해야 합니다 [13, 28-31]. 더불어 보이지 않는 객체를 렌더링에서 제외하는 절두체 컬링(Frustum Culling)이 올바르게 동작하도록 바운딩 박스를 관리해야 합니다 [32, 33].
-- **WebGPU 및 TSL 전환:** Three.js r171 버전부터 정식 지원되는 `WebGPURenderer`는 대규모 데이터셋 처리와 컴퓨트 집약적인 효과(파티클, 물리 연산 등)에서 기존 대비 수 배에서 100배 이상의 성능 향상을 제공합니다 [34-37]. 새로운 TSL(Three Shader Language)을 사용하면 단일 코드로 작성된 셰이더를 WebGPU와 WebGL 모두에 호환되게 배포할 수 있습니다 [38-40].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Graphics & Performance 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[Draw Call]], [[InstancedMesh]], [[BatchedMesh]], [[WebGPU]], [[Level of Detail (LOD)]], [[Texture Compression]]
-- **Projects/Contexts:** [[Utsubo]], [[Segments.ai]], [[InstancedMesh2 library]]
-- **Contradictions/Notes:** `InstancedMesh`는 드로우 콜을 획기적으로 줄여주지만, 엔진 수준에서 개별 인스턴스에 대한 절두체 컬링과 깊이 정렬(Sorting)이 불가능하여 오버드로우(Overdraw)가 유발됩니다. 이로 인해 픽셀 연산이 무거운 씬에서는 오히려 일반 메쉬 방식보다 프레임 레이트가 하락할 수 있다는 한계가 지적됩니다 [41-44]. 대안으로 꼽히는 `BatchedMesh` 역시 수십만 개 단위의 복잡한 기하학적 데이터와 인스턴스를 처리할 때는 심각한 CPU 병목 현상 및 성능 저하를 야기할 수 있습니다 [20, 45-48].
-
----
-*Last updated: 2026-04-19*
-- Raw Source: [[00_Raw/2026-04-20/Three.js 렌더링 최적화.md]]
----
diff --git a/Graphics & Performance/Threejs 모바일 렌더링 최적화.md b/Graphics & Performance/Threejs 모바일 렌더링 최적화.md
deleted file mode 100644
index bdefe553..00000000
--- a/Graphics & Performance/Threejs 모바일 렌더링 최적화.md	
+++ /dev/null
@@ -1,49 +0,0 @@
----
-id: P-REINFORCE-AUTO-E3AAE4
-category: "[[10_Wiki/💡 Topics/Graphics & Performance]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Threejs 모바일 렌더링 최적화"
----
-
-# [[Threejs 모바일 렌더링 최적화]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> Three.js 모바일 렌더링 최적화는 제한된 컴퓨팅 파워, 메모리 대역폭 및 배터리 용량을 가진 모바일 기기 환경에서 3D 장면을 원활하게 구동하기 위한 일련의 기술적 접근이다. 이 최적화는 셰이더 정밀도 조절, 텍스처 및 폴리곤 수 제한, 드로우 콜(Draw Call) 감소, 배터리 절약을 위한 렌더링 루프 제어 등을 포함한다 [1-4]. 이를 통해 모바일 브라우저에서도 60fps의 안정적인 프레임 속도를 유지하고 메모리 한계로 인한 애플리케이션 크래시를 방지할 수 있다 [5, 6].
-
-## 📖 구조화된 지식 (Synthesized Content)
-*   **셰이더 및 정밀도 최적화**
-    *   모바일 GPU는 `mediump` 정밀도를 처리할 때 `highp`보다 대략 2배 빠른 속도를 내므로, 깊이 계산이나 위치 등 필수적인 경우를 제외하고는 기본적으로 `mediump`를 사용해야 한다 [1].
-    *   버텍스 셰이더와 프래그먼트 셰이더 사이에서 데이터를 전달하는 varying 변수의 개수를 모바일 GPU에 맞춰 3개 이하로 최소화해야 한다 [1].
-
-*   **메모리 및 텍스처 관리**
-    *   모바일 기기는 보통 2~4GB의 제한된 시스템 메모리를 가지며, 텍스처 메모리가 500MB를 초과하면 가비지 컬렉션(GC)으로 인한 일시 중지와 심각한 프레임 끊김이 발생한다 [5].
-    *   이를 해결하기 위해 Basis Universal이나 KTX2와 같은 GPU 친화적인 압축 텍스처를 사용해야 한다. 이러한 포맷은 모바일 플랫폼에 따라 ASTC(Android)나 PVRTC(iOS)로 로드 시 변환되어 메모리 사용량을 대폭 줄여준다 [7].
-    *   다수의 텍스처를 사용하는 대신, 텍스처 아틀라스(Texture Atlas)로 결합하여 텍스처 바인딩 횟수를 줄이는 것이 모바일 GPU의 렌더링 오버헤드를 크게 감소시키는 방법이다 [8, 9].
-
-*   **드로우 콜 및 지오메트리 제한**
-    *   프로세서 성능이 상대적으로 낮은 모바일 브라우저에서는 1,000~2,000회의 드로우 콜 한계치에 도달하면 CPU 병목으로 인한 성능 저하가 눈에 띄게 나타난다 [4].
-    *   모바일 브라우저(iOS Safari, Chrome Mobile 등) 환경에서는 화면당 폴리곤 개수를 50,000~100,000개 수준으로 제한해야 매끄러운 렌더링이 보장된다 [3].
-
-*   **그림자 및 안티앨리어싱 설정 타협**
-    *   섀도우 맵 렌더링은 리소스 소모가 크므로, 모바일의 경우 섀도우 맵 크기를 512에서 1024 사이로 작게 설정하는 것이 바람직하다 [10].
-    *   렌더링 파이프라인 구성 시 고비용의 네이티브 안티앨리어싱(MSAA)을 비활성화하고, 그 대신 포스트 프로세싱인 FXAA를 사용하면 모바일 기기에서도 성능 부하를 5~10% 수준으로 낮추면서 60fps를 유지할 수 있다 [6].
-
-*   **배터리 절약 및 오류 복구(Context Management)**
-    *   정적인 씬(Static scenes)의 경우 리액트 기반 환경(R3F 등)에서 `frameloop="demand"` 옵션을 사용하여 불필요한 프레임 렌더링을 방지함으로써 모바일 기기의 배터리를 아껴야 한다 [2].
-    *   모바일 환경에서는 WebGL 컨텍스트 손실(Context lost)이 발생할 수 있으므로, 리스너(`webglcontextlost`)를 등록하여 이를 감지하고 우아하게 복구하는(gracefully recover) 예외 처리가 필수적이다 [11].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Graphics & Performance 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[드로우 콜 최적화 (Draw Call Optimization)]], [[텍스처 압축 (Texture Compression)]], [[셰이더 정밀도 (Shader Precision)]], [[가비지 컬렉션 (Garbage Collection)]]
-- **Projects/Contexts:** [[React Three Fiber (R3F)]], [[Basis Universal / KTX2]]
-- **Contradictions/Notes:** 소스에서는 모바일 환경 구현 시 시각적 품질과 성능 간의 직접적인 타협(trade-off)을 강조한다. 데스크톱 환경에서는 다중 텍스처 파일과 MSAA, 4096 크기의 섀도우 맵 활용이 가능하지만, 모바일 기기에서는 동일한 구성을 유지할 경우 프레임 속도 저하와 발열, 메모리 부족으로 인한 강제 종료를 유발할 수 있으므로 극단적인 간소화(FXAA, 아틀라스 텍스처, 512~1024 섀도우 등)를 필수적으로 도입해야 함을 명시한다 [5, 6, 10].
-
----
-*Last updated: 2026-04-19*
-- Raw Source: [[00_Raw/2026-04-20/Three.js 모바일 렌더링 최적화.md]]
----
diff --git a/Graphics & Performance/Threejs 자원 해제 (Dispose).md b/Graphics & Performance/Threejs 자원 해제 (Dispose).md
deleted file mode 100644
index a3707f54..00000000
--- a/Graphics & Performance/Threejs 자원 해제 (Dispose).md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-5ED3CA
-category: "[[10_Wiki/💡 Topics/Graphics & Performance]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Threejs 자원 해제 (Dispose)"
----
-
-# [[Threejs 자원 해제 (Dispose)]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Graphics & Performance 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Three.js 자원 해제 (Dispose).md]]
----
diff --git a/Graphics & Performance/Threejs.md b/Graphics & Performance/Threejs.md
deleted file mode 100644
index 50f1b223..00000000
--- a/Graphics & Performance/Threejs.md	
+++ /dev/null
@@ -1,39 +0,0 @@
----
-id: P-REINFORCE-AUTO-A5498B
-category: "[[10_Wiki/💡 Topics/Graphics & Performance]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Threejs"
----
-
-# [[Threejs]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> Three.js는 WebGL 및 WebGPU를 사용하여 웹 브라우저에서 애니메이션 3D 컴퓨터 그래픽스를 생성하고 표시할 수 있도록 지원하는 크로스 브라우저 자바스크립트 라이브러리이자 API이다 [1, 2]. 브라우저, GPU, 자바스크립트 간의 복잡한 상호작용을 추상화하여 개발자가 고성능의 3D 환경을 쉽게 구축할 수 있도록 돕는다 [3]. 2026년을 기점으로 프로덕션 수준의 WebGPU 렌더러와 TSL(Three Shader Language)이 도입되면서, 단순한 시각화를 넘어 수백만 개의 파티클 연산이나 대규모 CAD 모델 처리까지 가능한 고성능 플랫폼으로 진화했다 [4-7].
-
-## 📖 구조화된 지식 (Synthesized Content)
-*   **렌더링 파이프라인 및 드로우 콜(Draw Call) 최적화:** 
-    실시간 3D 렌더링에서 CPU가 GPU에 렌더링을 명령하는 '드로우 콜'은 시스템 오버헤드의 주된 원인으로 꼽힌다 [8-10]. Three.js는 이를 최소화하기 위해 단일 기하학(Geometry)과 재질(Material)을 공유하는 객체들을 한 번에 렌더링하는 `InstancedMesh`, 다양한 기하학적 구조를 동일한 재질 하에 하나로 묶어 처리하는 `BatchedMesh`, 그리고 정적 객체들을 로드 시점에 병합해버리는 `BufferGeometryUtils.mergeBufferGeometries` 기법을 지원한다 [11-15].
-*   **WebGPU와 TSL(Three Shader Language)의 도입:** 
-    릴리즈 r171부터 도입된 WebGPURenderer는 `forceWebGL`이 필요한 상황을 제외하면 WebGL 2 자동 폴백 기능을 지원하는 "제로 설정(zero-config)" 방식으로 쉽게 적용할 수 있다 [4, 5, 16]. 새롭게 도입된 TSL은 단일 코드로 WGSL과 GLSL 양쪽 모두에 컴파일되는 노드 기반의 재질 시스템이며, 컴퓨트 셰이더(Compute Shaders)를 통해 물리 연산, 충돌 감지, 수백만 단위의 대규모 파티클 시스템 렌더링 등 병렬 처리를 GPU로 오프로딩할 수 있게 해준다 [5, 17-20].
-*   **메모리 및 애셋 관리의 중요성:** 
-    Three.js는 GPU 리소스를 자동으로 가비지 컬렉션(Garbage Collection)하지 않으므로, 사용이 끝난 지오메트리, 재질, 텍스처는 반드시 `.dispose()` 메서드를 호출해 명시적으로 해제해야만 VRAM 누수를 막을 수 있다 [21, 22]. 모델 로드 시 대역폭과 메모리를 아끼기 위해 Draco 지오메트리 압축, KTX2 및 Basis Universal과 같은 GPU 네이티브 텍스처 압축 기술이 필수적이며 [23-25], 카메라 거리에 따라 다각형 수를 조절하는 LOD(Level of Detail) 기능으로 렌더링 부하를 동적으로 줄일 수 있다 [26-28].
-*   **인스턴싱(Instancing)의 구조적 한계:**
-    `InstancedMesh`는 성능 향상에 필수적인 도구지만 몇 가지 한계가 있다. 엔진 수준에서 전체 인스턴스를 아우르는 하나의 경계 볼륨(Bounding Volume)을 기준으로 시야 절두체 컬링(Frustum Culling)을 처리하기 때문에, 시야 밖에 있는 인스턴스에 대해서도 GPU 정점 연산을 수행하는 비효율이 발생한다 [29, 30]. 또한, 객체들의 심도에 따른 자동 정렬(Depth Sorting)을 제공하지 않아, 투명한 객체가 겹쳐 있거나 복잡한 셰이더를 사용할 경우 심각한 오버드로우(Overdraw)를 유발하여 GPU 프래그먼트 처리 병목을 초래할 수 있다 [31-34].
-*   **사용자 입력과 레이캐스팅(Raycasting):**
-    사용자의 마우스나 터치 입력을 통한 화면 상의 3D 객체 선택(피킹)은 `Raycaster` 객체를 통해 수행된다 [35, 36]. 하지만 `InstancedMesh`에서 개별 인스턴스의 행렬(위치/회전/축척)을 동적으로 변경할 경우, 레이캐스팅이 정상 작동하려면 변경 직후 반드시 `.computeBoundingSphere()` 및 `.computeBoundingBox()`를 호출하여 바운딩 볼륨을 갱신해야 한다 [37, 38]. 다량의 인스턴스가 존재하는 환경에서 충돌 및 선택의 속도를 높이려면 `three-mesh-bvh` 같은 공간 분할(Spatial Indexing) 라이브러리를 활용하는 것이 권장된다 [39, 40].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Graphics & Performance 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[WebGPU]], [[InstancedMesh]], [[BatchedMesh]], [[TSL (Three Shader Language)]], [[Raycaster]], [[LOD (Level of Detail)]]
-- **Projects/Contexts:** [[React Three Fiber (R3F)]], [[IFC.js]], [[InstancedMesh2]]
-- **Contradictions/Notes:** 일반적으로 `InstancedMesh`는 드로우 콜을 1회로 줄여 렌더링 성능을 획기적으로 높인다고 알려져 있으나, 인스턴스의 자동 정렬 기능이 없어 오버드로우(Overdraw)가 빈번하게 발생할 경우 단일 메쉬를 분할하여 그릴 때보다 오히려 프레임 속도(FPS)가 급락할 수 있습니다 [4, 31-33]. 또한 여러 다른 지오메트리를 하나의 렌더 호출로 묶어주는 `BatchedMesh` 역시, 지나치게 많은 수의 정점과 데이터를 렌더링할 경우 패킹 및 컬링 연산 때문에 극심한 CPU 과부하와 성능 저하를 야기할 수 있다는 한계가 보고되고 있습니다 [41, 42].
-
----
-*Last updated: 2026-04-19*
-- Raw Source: [[00_Raw/2026-04-20/Three.js.md]]
----
diff --git a/Graphics & Performance/Timestamp Quantization.md b/Graphics & Performance/Timestamp Quantization.md
deleted file mode 100644
index fe097b1c..00000000
--- a/Graphics & Performance/Timestamp Quantization.md	
+++ /dev/null
@@ -1,32 +0,0 @@
----
-id: P-REINFORCE-AUTO-B27B31
-category: "[[10_Wiki/💡 Topics/Graphics & Performance]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Timestamp Quantization"
----
-
-# [[Timestamp Quantization]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 타임스탬프 양자화(Timestamp Quantization)는 WebGPU 등 웹 그래픽 API에서 발생할 수 있는 타이밍 공격(Timing Attack) 및 기기 핑거프린팅을 방지하기 위해, 타이머 쿼리의 해상도를 의도적으로 조대화(coarsening)하여 낮추는 보안 메커니즘입니다 [1-3]. 고정밀 타이밍 정보가 캐시 사이드 채널 공격이나 Rowhammer 공격 등에 악용되는 것을 막기 위해 브라우저 엔진은 타임스탬프의 측정 해상도를 100 마이크로초(µs)와 같은 표준 단위로 제한합니다 [1, 4-6].
-
-## 📖 구조화된 지식 (Synthesized Content)
-* **도입 배경 및 보안 위협:** WebGPU의 타임스탬프 쿼리는 GPU 명령어의 실행 시간을 나노초(nanosecond) 단위로 정밀하게 측정할 수 있도록 지원합니다 [6, 7]. 그러나 이러한 고해상도 타이밍 정보는 캐시 적중률과 메모리 접근 패턴을 관찰 가능하게 만들어 Spectre, Meltdown과 같은 사이드 채널 공격이나 GPU 물리적 메모리 구조를 파악해 조작하는 Rowhammer 공격에 악용될 수 있습니다 [1, 5, 8-10].
-* **양자화 및 조대화(Coarsening) 적용:** 이러한 보안 위협을 완화하기 위해 Chrome의 WebGPU 백엔드인 Dawn 및 Blink 엔진 등은 타임스탬프 양자화를 구현합니다 [1, 2]. WebGPU 표준 기구 및 브라우저 벤더들은 High Resolution Time(hr-time) 사양과 일치하도록 GPU 타임스탬프를 비격리 컨텍스트와 동일하게 100 마이크로초(100µs) 해상도로 조대화하는 방식을 채택했습니다 [4-6, 11].
-* **개발자 도구를 통한 예외 처리:** 성능 프로파일링을 위해 고정밀 측정이 필요한 개발자를 위해, Chrome에서는 로컬 환경에서 `chrome://flags/#enable-webgpu-developer-features` 플래그를 활성화하여 이 양자화(제한)를 우회하고 본래의 나노초 단위 정밀도를 사용할 수 있는 예외를 제공합니다 [2, 12].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Graphics & Performance 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[WebGPU]], [[Timing Attack]], [[Side-channel Attack]], [[Spectre]], [[Rowhammer]], [[High Resolution Time]]
-- **Projects/Contexts:** [[Chrome (Blink/Dawn)]], [[GPU for the Web Community Group]]
-- **Contradictions/Notes:** Chrome의 초기 제안에서는 교차 출처 격리(cross-origin isolated) 상태에 따라 격리된 컨텍스트에서는 100µs 해상도를 제공하고 비격리 컨텍스트에서는 타임스탬프를 아예 노출하지 않으려 했습니다 [3, 13]. 그러나 상호운용성(interoperability) 문제와 모호한 사양에 대한 지적이 제기되었고, 최종적으로는 사이트 격리 상태와 무관하게 항상 100µs 해상도로 타임스탬프를 허용하는 방안이 합의되었습니다 [5, 11, 14].
-
----
-*Last updated: 2026-04-19*
-- Raw Source: [[00_Raw/2026-04-20/Timestamp Quantization.md]]
----
diff --git a/Graphics & Performance/Timestamp Queries Quantization.md b/Graphics & Performance/Timestamp Queries Quantization.md
deleted file mode 100644
index abf01f46..00000000
--- a/Graphics & Performance/Timestamp Queries Quantization.md	
+++ /dev/null
@@ -1,32 +0,0 @@
----
-id: P-REINFORCE-AUTO-788E1E
-category: "[[10_Wiki/💡 Topics/Graphics & Performance]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Timestamp Queries Quantization"
----
-
-# [[Timestamp Queries Quantization]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 타임스탬프 쿼리 양자화(Timestamp Queries Quantization)는 WebGPU 애플리케이션에서 GPU 명령의 실행 시간을 측정할 때 그 정밀도를 의도적으로 낮추는 보안 메커니즘입니다 [1], [2], [3], [4]. 개발자는 타임스탬프 쿼리를 통해 나노초 단위의 정밀한 데이터를 얻을 수 있지만, 이는 Spectre나 Rowhammer와 같은 캐시 기반 타이밍 공격(Timing attack)에 악용될 수 있습니다 [5], [1], [2], [6]. 이를 방지하기 위해 브라우저 엔진은 반환되는 타이머의 해상도를 100 마이크로초(µs) 수준으로 낮추어 보안과 성능 분석의 균형을 맞춥니다 [1], [7], [3], [4].
-
-## 📖 구조화된 지식 (Synthesized Content)
-- **도입 배경 및 보안 위협:** WebGPU의 타임스탬프 쿼리는 패스(pass)의 시작과 끝 등 GPU 워크로드의 실행 시간을 나노초 단위까지 정밀하게 측정할 수 있도록 지원합니다 [2], [4]. 하지만 고정밀 타이머는 악의적인 공격자가 캐시 적중률과 물리적 메모리 구조를 파악하여 Spectre, Meltdown, Rowhammer 같은 사이드 채널 공격을 수행하거나 기기 지문을 수집(Fingerprinting)하는 데 사용될 수 있습니다 [5], [1], [8], [6]. 과거 WebGL의 `EXT_disjoint_timer_query` 확장 역시 동일한 보안 문제로 인해 브라우저에서 비활성화되거나 제한된 바 있습니다 [5], [1], [9].
-- **양자화(Quantization/Coarsening)의 동작 방식:** 타이밍 공격을 방어하기 위해 Chrome의 Blink 및 Dawn과 같은 엔진은 타임스탬프 쿼리의 해상도를 인위적으로 낮추는 '양자화(또는 조대화, Coarsening)'를 구현했습니다 [7], [3]. 본래 격리된 컨텍스트(Isolated context)에서만 100 마이크로초 해상도를 제공하고 비격리 환경에서는 노출하지 않으려 했으나 [7], [3], 이후 브라우저 간 상호 운용성을 확보하고 High Resolution Time 사양과 일치시키기 위해 사이트 격리 여부와 무관하게 100 마이크로초(100µs)의 해상도를 제공하는 것으로 최종 합의되었습니다 [10], [11].
-- **개발자 환경에서의 우회:** 100 마이크로초 단위의 해상도는 단일 프레임 내의 정밀한 GPU 마이크로 지연 시간(Micro-latency)을 분석하기에는 지나치게 거칠 수 있습니다 [7], [12]. 따라서 정밀한 로컬 프로파일링이 필요한 개발자는 Chrome 브라우저에서 `chrome://flags/#enable-webgpu-developer-features` 플래그를 활성화하여 양자화 제한을 해제하고, 나노초 단위의 원본 타임스탬프 데이터를 획득할 수 있습니다 [7], [13], [14], [4].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Graphics & Performance 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[WebGPU]], [[Timing Attack]], [[Spectre]], [[EXT_disjoint_timer_query]]
-- **Projects/Contexts:** [[High Resolution Time Spec]], [[Chrome DevTools]]
-- **Contradictions/Notes:** 초기 WebGPU 사양 제안에서는 사이트 격리(Site isolation) 여부에 따라 타임스탬프 쿼리 제공 여부를 차등 적용(비격리 시 완전히 미노출)하려 했으나 [3], 이후 표준화 논의 과정에서 상호 운용성을 위해 모든 컨텍스트에 대해 100 마이크로초의 해상도를 일괄 제공하도록 정책이 변경되었습니다 [10], [11].
-
----
-*Last updated: 2026-04-19*
-- Raw Source: [[00_Raw/2026-04-20/Timestamp Queries Quantization.md]]
----
diff --git a/Graphics & Performance/Timestamp Queries.md b/Graphics & Performance/Timestamp Queries.md
deleted file mode 100644
index 6d351fd3..00000000
--- a/Graphics & Performance/Timestamp Queries.md	
+++ /dev/null
@@ -1,39 +0,0 @@
----
-id: P-REINFORCE-AUTO-77D993
-category: "[[10_Wiki/💡 Topics/Graphics & Performance]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Timestamp Queries"
----
-
-# [[Timestamp Queries]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> Timestamp Queries(타임스탬프 쿼리)는 WebGL 및 WebGPU와 같은 웹 그래픽 파이프라인에서 GPU 명령 세트의 경과 시간을 나노초 단위까지 정밀하게 측정할 수 있게 해주는 기능입니다 [1-3]. 렌더링 파이프라인을 지연시키지 않으면서 GPU 작업 부하의 성능과 동작에 대한 깊은 통찰력을 제공하는 데 필수적입니다 [3, 4]. 그러나 고정밀 타이머가 사이드 채널 공격(예: Spectre 및 Meltdown)에 악용될 수 있다는 보안 취약점 때문에, 최신 브라우저 환경에서는 타이머의 정밀도를 의도적으로 낮추는 양자화(Quantization) 기법이 적용됩니다 [2, 5, 6].
-
-## 📖 구조화된 지식 (Synthesized Content)
-*   **WebGL에서의 타이머 쿼리 한계:**
-    기존 WebGL은 `EXT_disjoint_timer_query` 확장을 통해 렌더링 파이프라인의 중단 없이 GL 명령의 지속 시간을 측정할 수 있었습니다 [1, 4]. 하지만 이 고정밀 타이밍 기능이 캐시 적중률을 관찰하여 Spectre 및 Meltdown과 같은 사이드 채널 공격에 악용될 수 있음이 밝혀지면서, 대부분의 브라우저 공급업체는 이 확장을 비활성화하거나 타이머 값에 엄격한 양자화 및 클램핑을 적용했습니다 [2].
-*   **WebGPU 타임스탬프 쿼리 도입:** 
-    WebGPU는 `timestamp-query` 기능과 `GPUQuerySet`을 통해 렌더링 및 컴퓨트 패스의 시작과 끝에서 매우 정밀한(나노초 단위) 측정을 지원합니다 [2, 3]. 이 기능은 텐서플로우(Tensorflow.js)와 같은 복잡한 GPU 작업 부하의 동작을 파악하고 최적화하는 데 널리 활용됩니다 [7].
-*   **보안을 위한 양자화(Quantization) 및 거칠기(Coarsening) 적용:** 
-    고정밀 타이머를 통한 지문 수집(Fingerprinting) 및 타이밍 공격을 방지하기 위해 WebGPU는 타임스탬프 값을 양자화합니다 [2, 5]. WebGPU 제안 초기에는 사이트 격리(Site isolation) 여부에 따라 격리된 컨텍스트에서는 100 마이크로초(µs) 해상도로, 격리되지 않은 컨텍스트에서는 쿼리 자체를 노출하지 않는 방식을 고려했습니다 [5, 8]. 
-*   **교차 출처(Cross-origin) 및 하드웨어 특성을 반영한 정책 변경:**
-    이후 논의 과정에서 GPU 타임스탬프는 고립된 컨텍스트 간에도 공유될 수 있으며 GPU 캐시를 통한 타이밍 공격 위험이 여전히 존재함이 확인되었습니다 [6]. 상호 운용성(Interop)을 높이고 보안을 유지하기 위해, 사이트의 교차 출처 격리(cross-origin isolated) 상태와 무관하게 항상 고해상도 시간 사양(HR-time)에 맞추어 100 마이크로초(µs)로 해상도를 거칠게 만드는(coarsening) 것으로 최종 정책이 합의되었습니다 [6, 9].
-*   **개발자를 위한 예외 처리:** 
-    성능 프로파일링을 위해 실제 나노초 단위의 정밀한 측정값이 필요한 개발자는 로컬 환경에서 "WebGPU Developer Features" 또는 "Unsafe WebGPU Support" 같은 특정 브라우저 플래그를 활성화하여 이러한 양자화 제한을 일시적으로 우회할 수 있습니다 [8, 10].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Graphics & Performance 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[WebGL Timer Queries]], [[Spectre and Meltdown]], [[WebGPU]], [[Timestamp Quantization]]
-- **Projects/Contexts:** [[EXT_disjoint_timer_query]], [[High Resolution Time Spec]]
-- **Contradictions/Notes:** 초기 WebGPU 구현 제안에서는 사이트 격리 상태에 따라 타임스탬프 쿼리의 노출 여부와 해상도를 다르게 적용하려고 했으나(격리 시 100µs, 비격리 시 미노출) [5], 브라우저 간의 상호 운용성 부족 및 GPU의 격리 한계를 이유로 격리 상태와 관계없이 모든 GPU 작업에 대해 일괄적으로 100µs 해상도를 적용하도록 사양이 수정되었습니다 [6, 9].
-
----
-*Last updated: 2026-04-19*
-- Raw Source: [[00_Raw/2026-04-20/Timestamp Queries.md]]
----
diff --git a/Graphics & Performance/Turtle-Graphics.md b/Graphics & Performance/Turtle-Graphics.md
deleted file mode 100644
index ddc4a9dc..00000000
--- a/Graphics & Performance/Turtle-Graphics.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-51C40D
-category: "[[10_Wiki/💡 Topics/Graphics & Performance]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Turtle-Graphics"
----
-
-# [[Turtle-Graphics]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Graphics & Performance 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Turtle-Graphics.md]]
----
diff --git a/Graphics & Performance/TypedArray.md b/Graphics & Performance/TypedArray.md
deleted file mode 100644
index 1cf82548..00000000
--- a/Graphics & Performance/TypedArray.md	
+++ /dev/null
@@ -1,32 +0,0 @@
----
-id: P-REINFORCE-AUTO-DEE006
-category: "[[10_Wiki/💡 Topics/Graphics & Performance]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - TypedArray"
----
-
-# [[TypedArray]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> TypedArray는 Three.js 등의 WebGL 렌더링 환경에서 정점 데이터나 인스턴스의 속성값(예: `Float32Array`를 통한 UV 오프셋 등)을 저장하고 GPU로 전달하기 위해 사용되는 자바스크립트의 데이터 구조입니다 [1, 2]. 대규모 그래픽 데이터를 처리하는 데 사용되지만, 동적 환경에서 잦은 할당 및 해제는 성능 저하를 일으킬 수 있습니다 [3]. 다만 본 문서의 전반적인 작동 원리나 세부 명세에 대해서는 **소스에 관련 정보가 부족합니다.**
-
-## 📖 구조화된 지식 (Synthesized Content)
-* **소스에 관련 정보가 부족합니다.** TypedArray에 대한 포괄적이고 전문적인 원리는 소스 데이터에 명시되어 있지 않으며, 주로 Three.js의 메모리 관리 및 성능 최적화 문맥에서 제한적으로 언급됩니다.
-* **데이터 버퍼 할당 및 활용:** Three.js에서 `InstancedMesh` 등을 사용하여 개별 인스턴스에 고유한 텍스처 UV 오프셋이나 기타 속성을 부여할 때, `Float32Array`와 같은 TypedArray를 기반으로 `InstancedBufferAttribute`를 생성하여 GPU에 데이터를 전달합니다 [1, 2]. 
-* **가비지 컬렉션(GC) 부하 및 성능 병목:** 객체의 수가 동적으로 변하여 `InstancedMesh`의 초기 할당 용량(Capacity)을 초과하게 되면, 엔진은 더 큰 버퍼를 할당하고 기존 데이터를 복사해야 합니다 [3]. 이 과정에서 수십 메가바이트 단위의 TypedArray가 빈번하게 생성되고 파괴될 경우 자바스크립트 엔진의 가비지 컬렉터가 작동하게 되며, 이는 렌더링 프레임이 일시적으로 멈추는 스터터링(Stuttering) 현상의 직접적인 원인이 됩니다 [3].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Graphics & Performance 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[InstancedMesh]], [[InstancedBufferAttribute]], [[Garbage Collection]]
-- **Projects/Contexts:** [[Three.js 메모리 관리 및 렌더링 최적화]]
-- **Contradictions/Notes:** 제공된 소스는 TypedArray 자체의 기능적 설명보다는, 이를 활용한 대규모 인스턴스 환경에서 동적 버퍼 확장이 유발하는 메모리 해제와 생성의 위험성(프레임 드랍)을 경고하는 데 초점을 맞추고 있습니다 [3].
-
----
-*Last updated: 2026-04-19*
-- Raw Source: [[00_Raw/2026-04-20/TypedArray.md]]
----
diff --git a/Graphics & Performance/USD - Universal Scene Description.md b/Graphics & Performance/USD - Universal Scene Description.md
deleted file mode 100644
index 75f47a9f..00000000
--- a/Graphics & Performance/USD - Universal Scene Description.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-B0E0B6
-category: "[[10_Wiki/💡 Topics/Graphics & Performance]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - USD - Universal Scene Description"
----
-
-# [[USD - Universal Scene Description]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Graphics & Performance 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/USD - Universal Scene Description.md]]
----
diff --git a/Graphics & Performance/UV Offset.md b/Graphics & Performance/UV Offset.md
deleted file mode 100644
index 73780076..00000000
--- a/Graphics & Performance/UV Offset.md	
+++ /dev/null
@@ -1,32 +0,0 @@
----
-id: P-REINFORCE-AUTO-FF2C8C
-category: "[[10_Wiki/💡 Topics/Graphics & Performance]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - UV Offset"
----
-
-# [[UV Offset]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> UV Offset(UV 오프셋)은 3D 모델에 텍스처의 특정 영역을 매핑하기 위해 UV 좌표를 조정하거나 계산하는 기법입니다 [1, 2]. 실시간 렌더링 최적화 환경에서는 여러 텍스처를 하나로 합친 텍스처 아틀라스(Texture Atlas)와 함께 주로 사용됩니다 [3, 4]. 특히 수많은 인스턴스를 렌더링할 때 각 인스턴스의 속성으로 UV 오프셋을 전달함으로써, 단일 드로우 콜(Draw Call) 내에서 개별 인스턴스마다 다른 텍스처 이미지를 적용할 수 있게 해줍니다 [5, 6].
-
-## 📖 구조화된 지식 (Synthesized Content)
-* **텍스처 아틀라스 매핑 (Texture Atlas Mapping):** 텍스처 바인딩 횟수와 드로우 콜을 줄이기 위해 여러 텍스처를 단일 텍스처 아틀라스로 병합할 때, 개발자는 메쉬 영역이 아틀라스의 올바른 위치를 참조하도록 UV 좌표를 조정(UV Offset 계산)해야 합니다 [1-4].
-* **InstancedMesh에서의 구현 방식:** `InstancedMesh`를 통해 수천 개의 개별 인스턴스에 각기 다른 텍스처를 부여하기 위해서는 단일 재질(Material)의 확산 맵(Diffuse map)으로 텍스처 아틀라스를 지정해야 합니다 [5, 7]. 이후 각 인스턴스마다 텍스처 오프셋을 정의하는 추가적인 인스턴스 버퍼 속성(예: `uvOffsets`)을 기하구조(Geometry)에 주입합니다 [5, 6, 8]. 구체적으로는 `Float32Array`를 사용해 각 인스턴스의 x/y 오프셋 좌표 배열을 생성한 뒤, 셰이더를 수정하여 이 `uvOffsets` 속성을 기반으로 각 인스턴스의 텍스처 위치를 이동(Offset)시키도록 렌더링합니다 [8-10].
-* **한계 및 현대적 대안:** 텍스처 아틀라스를 위한 복잡한 UV 오프셋 계산 알고리즘은 까다로울 뿐만 아니라, 인접한 텍스처 간에 픽셀이 섞이는 경계선 블리딩(Edge Bleeding) 현상을 유발할 수 있습니다 [2, 6]. 이러한 단점을 극복하기 위해 WebGL2부터 지원되는 데이터 배열 텍스처(Data Array Textures)를 활용하면, 복잡한 UV 오프셋 연산이나 패킹 없이 인덱스 접근만으로 다중 텍스처를 처리할 수 있습니다 [2, 11].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Graphics & Performance 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[Texture Atlas]], [[InstancedMesh]], [[BufferAttribute]]
-- **Projects/Contexts:** [[Three.js]], [[WebGL Optimization]]
-- **Contradictions/Notes:** 텍스처 아틀라스와 UV 오프셋의 조합은 인스턴싱 최적화를 위해 필수적이지만 UV 연산의 복잡성과 경계선 블리딩(Edge Bleeding)이라는 한계를 가지며, 소스에 따르면 이를 완전히 회피하기 위한 대안으로 데이터 배열 텍스처(Data Array Textures)의 사용이 제안됩니다 [2, 11].
-
----
-*Last updated: 2026-04-19*
-- Raw Source: [[00_Raw/2026-04-20/UV Offset.md]]
----
diff --git a/Graphics & Performance/UX Design  Gamification.md b/Graphics & Performance/UX Design  Gamification.md
deleted file mode 100644
index f8bfd08d..00000000
--- a/Graphics & Performance/UX Design  Gamification.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-C3544E
-category: "[[10_Wiki/💡 Topics/Graphics & Performance]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - UX Design  Gamification"
----
-
-# [[UX Design  Gamification]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Graphics & Performance 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/UX Design & Gamification.md]]
----
diff --git a/Graphics & Performance/UX-Design-Architecture.md b/Graphics & Performance/UX-Design-Architecture.md
deleted file mode 100644
index 0dc5a16b..00000000
--- a/Graphics & Performance/UX-Design-Architecture.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-6A1026
-category: "[[10_Wiki/💡 Topics/Graphics & Performance]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - UX-Design-Architecture"
----
-
-# [[UX-Design-Architecture]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Graphics & Performance 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/UX-Design-Architecture.md]]
----
diff --git a/Graphics & Performance/Unity.md b/Graphics & Performance/Unity.md
deleted file mode 100644
index 93df94a9..00000000
--- a/Graphics & Performance/Unity.md	
+++ /dev/null
@@ -1,44 +0,0 @@
----
-id: P-REINFORCE-AUTO-6033D2
-category: "[[10_Wiki/💡 Topics/Graphics & Performance]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Unity"
----
-
-# [[Unity]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> Unity는 2D 및 3D 프로젝트를 개발할 수 있는 소프트웨어 엔진 및 플랫폼입니다 [1]. 그래픽 렌더링 파이프라인, 물리 시스템, 씬(Scene) 및 게임 오브젝트(GameObject) 구성을 지원하며, 높은 그래픽 성능을 달성하기 위한 다양한 도구를 제공합니다 [1, 2]. 특히 화면에 기하학적 구조를 그리기 위해 그래픽 API에 명령을 내리는 드로우 콜(Draw call)과 렌더 상태 변경(Render-state changes)을 최적화하는 아키텍처가 핵심적으로 다뤄집니다 [3, 4].
-
-## 📖 구조화된 지식 (Synthesized Content)
-- **드로우 콜(Draw Calls) 및 성능 최적화**
-  Unity는 기하학적 구조, 텍스처, 셰이더 등의 정보를 그래픽 API에 전달하여 화면을 그리기 위해 드로우 콜을 발생시킵니다 [3]. 재질을 변경하는 등의 렌더 상태(Render state) 변경 과정은 CPU 자원을 매우 많이 소모하므로, 드로우 콜의 총 횟수를 줄이고 렌더 상태 변경이 적게 일어나도록 호출을 구성하는 것이 성능 최적화의 핵심입니다 [4, 5].
-
-- **드로우 콜 최적화 기법**
-  Unity는 드로우 콜과 렌더 상태 변경을 최적화하기 위해 다음과 같은 내장 방법들을 제공합니다 [2].
-  - **GPU 인스턴싱(GPU Instancing):** 나무나 덤불처럼 씬에 반복적으로 나타나는 동일한 메쉬의 여러 복사본을 동시에 렌더링합니다 [2].
-  - **드로우 콜 배칭(Draw Call Batching):** 움직이지 않는 정적 게임 오브젝트들의 메쉬를 사전에 결합하는 '정적 배칭(Static batching)'과, CPU에서 동일한 속성을 가진 정점들을 그룹화하여 한 번의 드로우 콜로 렌더링하는 '동적 배칭(Dynamic batching)'이 있습니다 [2].
-  - **수동 메쉬 결합:** `Mesh.CombineMeshes` 함수를 사용하여 다수의 메쉬를 수동으로 단일 메쉬로 병합해 한 번의 호출로 렌더링합니다 [2].
-  - **SRP 배처(SRP Batcher):** 스크립터블 렌더 파이프라인(SRP) 환경에서, 동일한 셰이더 변형(Shader variant)을 사용하는 재질에 대해 드로우 콜을 준비하는 CPU 소요 시간을 줄여줍니다 [2].
-
-- **최적화 적용 우선순위**
-  여러 최적화 기법이 중복으로 설정될 경우, Unity는 가장 높은 우선순위의 방법을 적용합니다. 우선순위는 1. SRP 배처 및 정적 배칭, 2. GPU 인스턴싱, 3. 동적 배칭 순입니다 [6, 7]. 예를 들어, 객체에 정적 배칭이 성공적으로 적용되면 해당 객체의 GPU 인스턴싱은 비활성화됩니다 [7].
-
-- **외부 도구와의 연동**
-  Needle Engine과 같은 도구와 함께 사용될 때, 성능 문제나 텍스처 누락 등을 해결하기 위해 Unity 환경 내에서 "Copy Project Info Into Clipboard" 기능을 사용하여 특정 설정 상태를 외부로 복사하고 디버깅할 수 있습니다 [8].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Graphics & Performance 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[GPU Instancing]], [[Draw Call Batching]], [[Scriptable Render Pipeline (SRP)]], [[GameObject]]
-- **Projects/Contexts:** [[Needle Engine]], [[Optimizing draw calls]]
-- **Contradictions/Notes:** Unity는 여러 드로우 콜 최적화 옵션을 지원하지만 기법 간에 충돌이 발생할 수 있습니다. 렌더러가 인스턴싱 셰이더를 사용하더라도 정적 배칭(Static batching)이 적용되는 경우 Unity는 자동으로 GPU 인스턴싱을 비활성화하며, 인스펙터(Inspector) 창에 정적 배칭을 끄라는 경고 메시지를 표시합니다 [7].
-
----
-*Last updated: 2026-04-19*
-- Raw Source: [[00_Raw/2026-04-20/Unity.md]]
----
diff --git a/Graphics & Performance/Urban-Resilience-Planning.md b/Graphics & Performance/Urban-Resilience-Planning.md
deleted file mode 100644
index e34c8b3e..00000000
--- a/Graphics & Performance/Urban-Resilience-Planning.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-D2E4D4
-category: "[[10_Wiki/💡 Topics/Graphics & Performance]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Urban-Resilience-Planning"
----
-
-# [[Urban-Resilience-Planning]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Graphics & Performance 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Urban-Resilience-Planning.md]]
----
diff --git a/Graphics & Performance/User-Story-Mapping.md b/Graphics & Performance/User-Story-Mapping.md
deleted file mode 100644
index 90b68f1f..00000000
--- a/Graphics & Performance/User-Story-Mapping.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-1AFDC8
-category: "[[10_Wiki/💡 Topics/Graphics & Performance]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - User-Story-Mapping"
----
-
-# [[User-Story-Mapping]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Graphics & Performance 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/User-Story-Mapping.md]]
----
diff --git a/Graphics & Performance/Utsubo.md b/Graphics & Performance/Utsubo.md
deleted file mode 100644
index aa2b1dd8..00000000
--- a/Graphics & Performance/Utsubo.md	
+++ /dev/null
@@ -1,37 +0,0 @@
----
-id: P-REINFORCE-AUTO-468135
-category: "[[10_Wiki/💡 Topics/Graphics & Performance]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Utsubo"
----
-
-# [[Utsubo]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> Utsubo는 브랜드 웹사이트부터 물리적 설치물에 이르기까지 Three.js 개발을 전문으로 하는 기술 중심의 인터랙티브 크리에이티브 스튜디오이다 [1, 2]. 이들은 2024년 초에 최초의 프로덕션 WebGPU Three.js 환경 중 하나를 구축하여 출시했으며, WebGPU 성능 모니터링을 위한 `stats-gl`과 같은 도구를 개발하는 등 Three.js 생태계 발전에 적극적으로 기여하고 있다 [1].
-
-## 📖 구조화된 지식 (Synthesized Content)
-* **스튜디오 개요 및 전문 분야:** 
-  Utsubo는 브랜드 웹사이트 제작부터 박물관 및 호텔을 위한 인터랙티브 설치물에 이르기까지 폭넓은 영역에서 Three.js 개발을 전문으로 하는 기술 우선(Technology-First) 크리에이티브 스튜디오이다 [1-3]. 이들은 테크 기업 및 브랜드 등과 협력하여 차세대 3D 웹 경험을 구축하고 있다 [3].
-* **WebGPU 및 생태계 기여:** 
-  Utsubo는 2024년 초 2024.utsubo.com을 통해 업계 최초 수준의 프로덕션 WebGPU Three.js 경험을 출시했다 [1]. 또한 WebGL 및 WebGPU 성능 모니터링을 위해 설계된 `stats-gl`과 같은 핵심 도구를 포함하여 Three.js 생태계에 활발하게 기여하고 있다 [1, 4]. Utsubo의 CEO이자 공동 창립자인 조슬린 르카뮈(Jocelyn Lecamus)는 Three.js가 단순한 웹사이트를 넘어 수백만 개의 데이터 포인트를 실시간으로 처리하는 애플리케이션으로 진화하고 있다고 강조한 바 있다 [5, 6].
-* **주요 프로젝트 및 포트폴리오:**
-  * **utsubo.com:** 수상 경력에 빛나는 고사양 3D 웹 경험(Award-winning 3D heavy experience)을 제공한다 [1].
-  * **호쿠사이(Hokusai) 설치물:** 2025 오사카 엑스포(Expo 2025 Osaka)에서 100만 개의 파티클을 활용한 유체 시뮬레이션을 구현하여 선보였다 [1].
-  * **Segments.ai:** WebGPU로의 마이그레이션을 지원하여 기존 대비 100배의 성능 향상을 이끌어냈다 [1].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Graphics & Performance 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[Three.js]], [[WebGPU]], [[stats-gl]]
-- **Projects/Contexts:** [[Expo 2025 Osaka]], [[Segments.ai]]
-- **Contradictions/Notes:** 소스에 관련된 모순 정보나 반대 주장이 부족합니다. (제공된 소스는 모두 Utsubo의 성과와 기술적 기여를 일관되게 긍정적으로 설명하고 있습니다.)
-
----
-*Last updated: 2026-04-19*
-- Raw Source: [[00_Raw/2026-04-20/Utsubo.md]]
----
diff --git a/Graphics & Performance/VIA-Classification.md b/Graphics & Performance/VIA-Classification.md
deleted file mode 100644
index 30808914..00000000
--- a/Graphics & Performance/VIA-Classification.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-19F48C
-category: "[[10_Wiki/💡 Topics/Graphics & Performance]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - VIA-Classification"
----
-
-# [[VIA-Classification]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Graphics & Performance 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/VIA-Classification.md]]
----
diff --git a/Graphics & Performance/VR 엑서게임 (VR Exergaming).md b/Graphics & Performance/VR 엑서게임 (VR Exergaming).md
deleted file mode 100644
index 2840eb88..00000000
--- a/Graphics & Performance/VR 엑서게임 (VR Exergaming).md	
+++ /dev/null
@@ -1,33 +0,0 @@
----
-id: P-REINFORCE-AUTO-E1E503
-category: "[[10_Wiki/💡 Topics/Graphics & Performance]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - VR 엑서게임 (VR Exergaming)"
----
-
-# [[VR 엑서게임 (VR Exergaming)]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> VR 엑서게임(VR Exergaming)은 운동(Exercise)과 게임 플레이(Gameplay)를 3D 가상 환경에 결합하여 신체 활동을 촉진하고 사람들의 좌식 생활 습관을 개선하는 활동을 말합니다 [1, 2]. 사용자에게 360도 공간과 신체 추적 기능을 제공하여 높은 몰입감을 유도하며, 이를 통해 운동에 수반되는 육체적 피로를 잊게 만들고 지속적인 참여 동기를 부여합니다 [2]. 대표적인 예시로 '비트 세이버(Beat Saber)'가 있으며, 실제 테니스와 맞먹는 에너지를 소모할 정도로 신체적, 심리적 이점을 모두 제공하는 도구로 주목받고 있습니다 [3].
-
-## 📖 구조화된 지식 (Synthesized Content)
-- **육체적 및 심리적 이점**: VR 엑서게임은 달리기나 에어로빅과 비견될 만한 생리학적 건강 증진 효과를 제공합니다 [1]. 특히 가상현실이 제공하는 강력한 몰입감과 존재감(Presence)은 사용자가 게임 목표에 깊이 빠져드는 '몰입(Flow)' 상태를 촉진하여, 전통적인 형태의 운동보다 훨씬 큰 즐거움과 운동 지속성을 이끌어냅니다 [1, 2]. 
-- **VR 멀미(VR Sickness)와 부작용**: VR 엑서게임 보급의 주요 장애물 중 하나는 메스꺼움, 눈의 피로(안구 운동 이상), 방향 감각 상실 등을 유발하는 VR 멀미입니다 [4, 5]. 엑서게임의 특성상 높은 수준의 사용자 움직임과 시각적 자극이 동시에 요구되기 때문에 멀미 발생 가능성이 크며, 이는 사용자의 몰입을 깨뜨리고 과제 수행 능력 및 즐거움을 저하시킬 수 있습니다 [4, 6].
-- **노출 시간과 잔여 효과(Aftereffects)**: 10분과 50분의 VR 노출을 비교한 연구에 따르면, 노출 시간이 길어질수록 VR 종료 직후 더 심각한 멀미 증상이 보고되었습니다 [7]. HMD 기기 사용으로 인해 눈의 조절(Accommodation) 및 수렴(Convergence)에 시각적 변화가 일어날 수 있으나 [8], 전반적인 그룹 평균을 보았을 때 VR 종료 후 40분이 지나면 시각, 인지, 주관적 멀미 증상이 대부분 기준치로 회복되는 것으로 나타났습니다 [7, 9].
-- **인지적 영향**: VR 엑서게임은 단기적인 인지 및 결정 시간에 심각한 악영향을 주지 않습니다 [10, 11]. 오히려 10분간의 게임 플레이 직후에는 게임 내에서 요구되는 빠른 운동 동작의 결과로 사용자의 움직임 속도(Movement speed)가 소폭 빨라지는 긍정적인 현상도 관찰되었습니다 [11].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Graphics & Performance 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[Flow State]], [[VR 멀미 (VR Sickness)]]
-- **Projects/Contexts:** [[Beat Saber]]
-- **Contradictions/Notes:** 평균적인 그룹 데이터로는 VR 엑서게임 종료 40분 후 멀미 증상이 모두 회복되는 것으로 나타나지만, 개별 데이터에 따르면 50분 플레이 후 약 14%의 사용자는 40분 뒤에도 여전히 높은 수준의 멀미를 겪고 있어 심각한 개인차가 존재함을 알 수 있습니다 [12]. 또한, 문헌에 따라 VR 노출이 사용자의 반응 시간(Reaction time)에 미치는 영향이 긍정적이라는 연구와 부정적이라는 연구가 혼재되어 있습니다 [13].
-
----
-*Last updated: 2026-04-19*
-- Raw Source: [[00_Raw/2026-04-20/VR 엑서게임 (VR Exergaming).md]]
----
diff --git a/Graphics & Performance/Varying Variables.md b/Graphics & Performance/Varying Variables.md
deleted file mode 100644
index 2d525a55..00000000
--- a/Graphics & Performance/Varying Variables.md	
+++ /dev/null
@@ -1,33 +0,0 @@
----
-id: P-REINFORCE-AUTO-9ED1C2
-category: "[[10_Wiki/💡 Topics/Graphics & Performance]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Varying Variables"
----
-
-# [[Varying Variables]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> Varying Variables(베어링 변수)는 3D 그래픽 파이프라인에서 버텍스 셰이더(vertex shaders)와 프래그먼트 셰이더(fragment shaders) 간에 데이터를 전송하는 역할을 하는 변수입니다 [1]. 모바일 기기에서의 렌더링 성능을 위해 사용량을 최소화해야 하는 셰이더 최적화 대상 중 하나입니다 [1].
-
-## 📖 구조화된 지식 (Synthesized Content)
-소스에 관련 정보가 부족합니다. 제공된 소스에서는 이 주제에 대한 깊이 있는 기술적 설명은 포함되어 있지 않으며, Three.js 셰이더 성능 최적화 관점에서의 단편적인 지침만 다음과 같이 제공됩니다.
-
-*   **데이터 전송**: Varying 변수는 버텍스 셰이더에서 프래그먼트 셰이더로 데이터를 넘겨주는 역할을 수행합니다 [1].
-*   **모바일 GPU 최적화**: 모바일 GPU 환경에서 셰이더 성능을 높이기 위해서는 Varying 변수의 개수를 3개 미만으로 유지하여 사용을 최소화하는 것이 권장됩니다 [1].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Graphics & Performance 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[Vertex Shader]], [[Fragment Shader]], [[Mobile GPU]]
-- **Projects/Contexts:** [[Three.js Performance Optimization]] (Shaders & Materials 최적화 팁)
-- **Contradictions/Notes:** 소스에 관련 정보가 부족합니다.
-
----
-*Last updated: 2026-04-19*
-- Raw Source: [[00_Raw/2026-04-20/Varying Variables.md]]
----
diff --git a/Graphics & Performance/Vertex Shader.md b/Graphics & Performance/Vertex Shader.md
deleted file mode 100644
index 91a294b6..00000000
--- a/Graphics & Performance/Vertex Shader.md	
+++ /dev/null
@@ -1,32 +0,0 @@
----
-id: P-REINFORCE-AUTO-E201D0
-category: "[[10_Wiki/💡 Topics/Graphics & Performance]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Vertex Shader"
----
-
-# [[Vertex Shader]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 버텍스 셰이더(Vertex Shader)는 렌더링 파이프라인에서 정점(Vertex)의 연산을 처리하는 셰이더 단계입니다 [1, 2]. 주로 인스턴스화된 메쉬(Instanced Mesh) 기반의 애니메이션을 처리하거나, 메쉬 데이터의 복제 없이 무작위 축척 및 회전 등을 절차적으로 변형하는 데 사용됩니다 [3, 4]. 계산된 데이터는 Varying 변수를 통해 프래그먼트 셰이더(Fragment Shader)로 전달됩니다 [1].
-
-## 📖 구조화된 지식 (Synthesized Content)
-- **인스턴싱 및 절차적 기하학 변형:** 버텍스 셰이더는 인스턴스 메쉬에 적용되어 다수의 이미지를 월드 공간에서 움직이도록 하는 애니메이션 로직을 수행할 수 있습니다 [3]. 또한, 커스텀 버텍스 셰이더를 통해 메쉬 데이터를 복제하지 않고도 인스턴스별로 무작위 축척(Scale), 회전 오프셋, 정점 변위(Vertex Displacement) 등의 절차적 변형을 가하여 다양성을 만들어낼 수 있습니다 [4].
-- **프래그먼트 셰이더와의 데이터 전송:** 버텍스 셰이더에서 처리된 데이터는 Varying 변수를 통해 프래그먼트 셰이더로 전달됩니다 [1]. 모바일 GPU 환경에서 성능을 최적화하기 위해서는 이 Varying 변수의 사용을 3개 미만으로 최소화하는 것이 권장됩니다 [1].
-- **성능 병목과 연산 부하:** 버텍스 셰이더 단계에서 수행되는 행렬 곱셈 등의 연산은 렌더링되는 인스턴스의 수가 늘어날수록 선형적으로 증가합니다 [2]. 시야 절두체 컬링(Frustum Culling)이 제대로 이루어지지 않을 경우, 화면에 실제로 그려지는 영역이 적더라도 보이지 않는 객체에 대해 강제로 버텍스 셰이더 연산이 수행되어 GPU 점유율을 100%까지 상승시키고 프레임 드랍을 유발할 수 있습니다 [2].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Graphics & Performance 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[Fragment Shader]], [[Instancing]], [[Varying Variables]]
-- **Projects/Contexts:** [[대규모 인스턴스 렌더링 최적화]], [[모바일 GPU 셰이더 성능 관리]]
-- **Contradictions/Notes:** 소스에 관련 정보가 부족합니다. (버텍스 셰이더 자체의 구체적인 내부 문법이나 근본적인 그래픽스 파이프라인 원리에 대한 상세한 설명은 제공된 소스에 포함되어 있지 않습니다.)
-
----
-*Last updated: 2026-04-19*
-- Raw Source: [[00_Raw/2026-04-20/Vertex Shader.md]]
----
diff --git a/Graphics & Performance/Virtual Reality (VR) Storytelling.md b/Graphics & Performance/Virtual Reality (VR) Storytelling.md
deleted file mode 100644
index 2daa3111..00000000
--- a/Graphics & Performance/Virtual Reality (VR) Storytelling.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-C15945
-category: "[[10_Wiki/💡 Topics/Graphics & Performance]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Virtual Reality (VR) Storytelling"
----
-
-# [[Virtual Reality (VR) Storytelling]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Graphics & Performance 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Virtual Reality (VR) Storytelling.md]]
----
diff --git a/Graphics & Performance/Voxel-based Rendering.md b/Graphics & Performance/Voxel-based Rendering.md
deleted file mode 100644
index ed841921..00000000
--- a/Graphics & Performance/Voxel-based Rendering.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-89D12F
-category: "[[10_Wiki/💡 Topics/Graphics & Performance]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Voxel-based Rendering"
----
-
-# [[Voxel-based Rendering]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Graphics & Performance 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Voxel-based Rendering.md]]
----
diff --git a/Graphics & Performance/Vulkan.md b/Graphics & Performance/Vulkan.md
deleted file mode 100644
index 13014750..00000000
--- a/Graphics & Performance/Vulkan.md	
+++ /dev/null
@@ -1,35 +0,0 @@
----
-id: P-REINFORCE-AUTO-DDC386
-category: "[[10_Wiki/💡 Topics/Graphics & Performance]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Vulkan"
----
-
-# [[Vulkan]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> Vulkan은 Metal, Direct3D 12와 함께 WebGPU 설계의 기반이 된 현대적인 그래픽스 API입니다 [1]. 단일 스레드와 상태 저장(Stateful)에 의존하는 WebGL이나 d3d9 같은 구형 API와 달리, 드로우 콜(Draw call) 오버헤드 처리에 훨씬 효율적인 아키텍처를 가집니다 [1, 2]. 조건부 렌더링(Conditional Rendering)이나 간접 그리기(Indirect drawing) 등 최신 렌더링 파이프라인을 구현하는 데 강력한 성능을 제공합니다 [3, 4].
-
-## 📖 구조화된 지식 (Synthesized Content)
-루트 주제인 Vulkan에 대한 전반적이고 상세한 아키텍처 설명은 소스에 관련 정보가 부족합니다. 제공된 데이터에서 확인 가능한 핵심적인 특징과 활용 사례는 다음과 같습니다.
-
-* **최신 그래픽스 API로의 기준점**: WebGPU는 구형 WebGL의 단일 스레드 및 상태 저장 한계를 극복하기 위해 만들어졌으며, 이때 Vulkan, Metal, Direct3D 12와 같은 최신 그래픽스 API의 구동 방식을 벤치마킹했습니다 [1]. 
-* **드로우 콜(Draw Call) 비용 완화**: 수많은 객체를 그릴 때 발생하는 드로우 콜 횟수는 성능에 직결되지만, d3d9과 같은 과거 API에 비해 Vulkan 환경에서는 드로우 콜 증가로 인한 성능 저하(오버헤드)가 상대적으로 적습니다 [2].
-* **조건부 렌더링(Conditional Rendering) 확장**: Vulkan은 조건부 렌더링이라는 확장 기능을 통해, GPU상에서 객체들을 자체적으로 평가하고 컬링(Culling) 테스트를 통과한(즉, 화면에 보여야 하는) 드로우 콜만 자동으로 실행하도록 처리할 수 있습니다 [3, 5].
-* **그래픽스 프로그래밍 활용 사례**: 커뮤니티 내에서 Vulkan은 간접 그리기 및 빛 컬링(Light Culling) 기능이 들어간 Forward+ 렌더러 구축이나 [4], 스펙트럴 렌더링(Spectral Rendering)을 지원하는 패스트레이서(Pathtracer) 개발 등 고성능 사용자 정의 렌더러 제작에 활발히 쓰이고 있습니다 [6]. 또한 OpenGL에서 활용하는 GPU 기반 인스턴싱 및 컬링 제어 로직을 Vulkan에도 동일하게 적용할 수 있습니다 [7].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Graphics & Performance 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[WebGPU]], [[Direct3D 12]], [[Metal]], [[Conditional Rendering]]
-- **Projects/Contexts:** [[Vulkan Forward+ Renderer]], [[Vulkan Pathtracer]]
-- **Contradictions/Notes:** 소스에 관련 정보가 부족합니다. Vulkan 기술 자체를 깊이 있게 다루는 문헌은 없으며, 대부분 WebGPU의 성능을 설명하기 위한 비교 대상이나 그래픽스 개발자들의 프로젝트 제목 및 질의응답 속에서 단편적으로만 등장합니다.
-
----
-*Last updated: 2026-04-19*
-- Raw Source: [[00_Raw/2026-04-20/Vulkan.md]]
----
diff --git a/Graphics & Performance/WEBGL_multi_draw.md b/Graphics & Performance/WEBGL_multi_draw.md
deleted file mode 100644
index cef37257..00000000
--- a/Graphics & Performance/WEBGL_multi_draw.md	
+++ /dev/null
@@ -1,39 +0,0 @@
----
-id: P-REINFORCE-AUTO-C71621
-category: "[[10_Wiki/💡 Topics/Graphics & Performance]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - WEBGL_multi_draw"
----
-
-# [[WEBGL_multi_draw]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> `WEBGL_multi_draw`는 한 번의 드로우 콜(Draw Call)로 정렬된 다수의 드로우 요청을 한꺼번에 제출할 수 있게 해주는 WebGL 확장 기능(Extension)입니다 [1, 2]. Three.js에서는 `BatchedMesh`가 이 API를 활용하여 동일한 재질을 공유하지만 각기 다른 기하학적 구조(Geometry)를 가진 여러 객체들을 묶어 렌더링하는 데 사용됩니다 [3-5]. 다양한 고유 객체들을 처리할 때 기존의 개별 호출 방식에 비해 엄청난 성능 향상을 제공하지만, 브라우저 호환성 문제와 대규모 씬에서의 오버헤드 한계를 동시에 안고 있습니다 [6, 7].
-
-## 📖 구조화된 지식 (Synthesized Content)
-* **BatchedMesh에서의 활용과 최적화 기능**
-  Three.js의 `BatchedMesh` 클래스는 `WEBGL_multi_draw` (구체적으로 `multiDraw` API)를 내부적으로 활용합니다 [1, 2]. 이를 통해 메모리에서 지오메트리를 중복시키지 않으면서도 지오메트리별 정렬(Sorting), 시야 절두체 컬링(Frustum Culling), 가시성 전환(Visibility Toggling), 인스턴싱 등의 기능을 단일 드로우 콜 내에서 수행할 수 있습니다 [2].
-* **InstancedDraw와의 성능 비교**
-  수십만 개(예: 10만 개 이상)의 동일한 인스턴스를 그릴 때는 `InstancedMesh`가 사용하는 `instancedDraw`가 더 우수한 성능을 발휘합니다 [3]. 반면, 1,000개 이상의 각기 다른 '고유한(unique)' 지오메트리 객체들을 그려야 할 때는 `multiDrawElementsWEBGL`이 매우 유용합니다 [8]. 10만 개의 고유 지오메트리를 기존의 바인딩 및 렌더링 호출(`bindVertexArray` + `drawElements`)로 처리하는 것과 비교하면, `multiDraw` 방식이 수천 배 더 빠른 속도를 제공합니다 [9].
-* **인스턴싱 지원 변형 (Instanced Variants)**
-  이 확장 기능에는 `multiDrawArraysInstancedWEBGL` 및 `multiDrawElementsInstancedWEBGL`과 같은 인스턴싱 지원 변형 함수도 포함되어 있습니다 [10]. 이들은 수천 개의 고유 객체와 다수의 인스턴스가 혼합된 복잡한 환경에서 객체들을 하나의 드로우 콜로 묶어 렌더링할 수 있게 해줍니다 [8].
-* **브라우저 호환성 제약**
-  Firefox 브라우저에서는 현재 `WEBGL_multi_draw` 확장을 지원하지 않습니다 [6, 11]. 이로 인해 Three.js 환경에서는 Firefox 지원을 위해 `gl_DrawID`를 에뮬레이트하는 속성을 추가하고, 지원되지 않을 경우 각 메쉬마다 새로운 드로우 콜을 생성하도록 하는 대체 수단(Fallback)이 필요합니다 [12].
-* **성능 병목 현상 및 기술적 한계**
-  지오메트리 수가 20만 개에 달할 정도로 규모가 커지면 `BatchedMesh` 사용 시 오히려 CPU 점유율이 치솟고 프레임이 심각하게 떨어지는 문제가 보고되었습니다 [13, 14]. 이는 매 프레임마다 드로우 "시작점(starts)"과 "카운트(counts)" 정보를 담은 약 1.6MB 규모의 버퍼 데이터를 GPU로 업로드해야 하는 통신 오버헤드나, 인디렉트 텍스처 업데이트 지연과 관련이 있을 것으로 추정됩니다 [7, 15]. 또한 인스턴스 렌더링을 적용할 때 `multiDrawArraysInstancedWEBGL` 방식으로는 셰이더 내에서 특정 행렬이나 색상에 접근하기 위한 인스턴스 ID를 직접 검색할 방법이 없어 부가적인 텍스처 우회 처리가 요구되는 한계도 있습니다 [16].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Graphics & Performance 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[BatchedMesh]], [[InstancedMesh]], [[Draw Call]]
-- **Projects/Contexts:** [[Three.js]], [[WebGL]]
-- **Contradictions/Notes:** `WEBGL_multi_draw`는 다수의 고유 객체를 그릴 때 CPU의 드로우 콜 병목을 해소하기 위해 설계되었으나 [1, 9], 역설적으로 특정 임계치(예: 수십만 단위)를 넘어서면 관련 버퍼 업로드 및 GPU 텍스처 업데이트 비용 때문에 오히려 병합된 지오메트리(Merged Geometry) 방식보다 성능이 30~50% 더 악화되는 실증적 모순이 관찰되었습니다 [7, 17, 18].
-
----
-*Last updated: 2026-04-19*
-- Raw Source: [[00_Raw/2026-04-20/WEBGL_multi_draw.md]]
----
diff --git a/Graphics & Performance/Waves of Connection.md b/Graphics & Performance/Waves of Connection.md
deleted file mode 100644
index 1fcc67b8..00000000
--- a/Graphics & Performance/Waves of Connection.md	
+++ /dev/null
@@ -1,30 +0,0 @@
----
-id: P-REINFORCE-AUTO-74AA0F
-category: "[[10_Wiki/💡 Topics/Graphics & Performance]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Waves of Connection"
----
-
-# [[Waves of Connection]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 'Waves of Connection'은 2025년 오사카 엑스포(Expo 2025 Osaka)에서 전시된 설치 작품입니다 [1]. 이 프로젝트는 Three.js WebGPU를 활용하여 98인치 4K 디스플레이 상에 100만 개의 파티클을 실시간으로 렌더링했습니다 [1]. 특히 눈에 띄는 지연(lag) 없이 다수의 사람의 움직임을 추적하는 다인원 바디 트래킹(multi-person body tracking) 기술을 구현하여 WebGPU의 뛰어난 성능을 입증한 사례로 꼽힙니다 [1].
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Graphics & Performance 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[Three.js WebGPU]], [[Particle System]]
-- **Projects/Contexts:** [[Expo 2025 Osaka]]
-- **Contradictions/Notes:** 소스 내에서 'Waves of Connection'에 대한 정보는 Three.js WebGPU와 Native WebGPU의 성능을 비교하며 WebGPU의 압도적인 렌더링 성능 향상(100만 개 파티클 실시간 처리)을 보여주기 위한 단편적인 사례로만 언급되었습니다. 그 외의 배경지식이나 세부 내용은 소스에 관련 정보가 부족합니다.
-
----
-*Last updated: 2026-04-19*
-- Raw Source: [[00_Raw/2026-04-20/Waves of Connection.md]]
----
diff --git a/Graphics & Performance/WebAssembly.md b/Graphics & Performance/WebAssembly.md
deleted file mode 100644
index 09de59d0..00000000
--- a/Graphics & Performance/WebAssembly.md	
+++ /dev/null
@@ -1,34 +0,0 @@
----
-id: P-REINFORCE-AUTO-E798C0
-category: "[[10_Wiki/💡 Topics/Graphics & Performance]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - WebAssembly"
----
-
-# [[WebAssembly]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 소스에 관련 정보가 부족합니다. 제공된 소스에서 WebAssembly(Wasm)에 대한 근본적인 정의나 포괄적인 설명은 찾을 수 없습니다. 다만, 웹 브라우저 환경에서 JavaScript와 함께 실행되어 CPU 기반의 복잡한 연산을 보조하거나, C/C++ 등의 언어로 작성된 코드를 웹에서 디버깅 및 구동할 수 있게 해주는 기술로 단편적으로 확인됩니다 [1-3].
-
-## 📖 구조화된 지식 (Synthesized Content)
-소스에 관련 정보가 부족합니다. 하지만 문서 내에서 제한적으로 확인 가능한 WebAssembly의 주요 특징과 활용 맥락은 다음과 같습니다:
-
-* **WebGL의 한계 보완 및 CPU 오프로딩:** WebGL API는 범용 GPU 연산(Compute Shader)을 기본적으로 지원하지 않습니다. 따라서 3D Gaussian Splatting과 같이 대규모 데이터 정렬(Sorting)이 필요한 복잡한 작업은 GPU에서 수행되지 못하고, JavaScript나 WebAssembly를 통해 CPU로 오프로드(Offloaded)되어 실행됩니다 [2, 4, 5].
-* **메모리 자원 및 디버깅:** WebAssembly 메모리는 디바이스의 제한된 시스템 자원을 소모합니다. 특히 iOS 기기에서는 통합 메모리(Unified memory) 구조로 인해 WebAssembly 메모리가 텍스처 등 다른 자원과 RAM 제한을 공유하므로, 한도를 초과할 경우 브라우저 탭이 정지되거나 새로고침될 수 있습니다 [6]. 개발자는 Chrome DevTools의 메모리 검사기 패널(Memory Inspector)을 통해 Wasm 메모리를 분석할 수 있으며, C/C++ WebAssembly 코드의 디버깅도 수행할 수 있습니다 [1, 7]. 또한, Rust 기반의 Naga 프로젝트를 활용해 WebAssembly 트랜스파일러(Transpiler)를 구축하는 방법도 언급됩니다 [8].
-* **하드웨어 보안 취약점 (Spectre):** WebKit과 같은 브라우저 엔진은 웹 사이트를 렌더링하기 위해 신뢰할 수 없는(Untrusted) JavaScript 및 WebAssembly 코드가 사용자의 프로세서에서 직접 실행되는 것을 허용해야 합니다 [3]. 이러한 구조적 특징 때문에, 공격자가 제어하는 WebAssembly 코드는 Spectre 및 Meltdown과 같은 하드웨어 취약점을 악용하는 데 사용될 수 있으며, 결과적으로 호스트 프로세스의 전체 주소 공간을 불법적으로 읽어낼 수 있는 이론적인 보안 위험을 야기합니다 [3, 9].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Graphics & Performance 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[WebGL]], [[JavaScript]], [[Spectre]]
-- **Projects/Contexts:** [[3D Gaussian Splatting]], [[Chrome DevTools]], [[WebKit]]
-- **Contradictions/Notes:** 소스에 WebAssembly의 구체적인 설계 구조나 동작 원리에 대한 포괄적인 정보가 부족합니다. 제공된 문헌들은 주로 WebGL의 연산 한계를 설명할 때의 대안(CPU 오프로딩 수단)이나 브라우저 보안 및 디버깅 툴을 설명하는 맥락에서만 WebAssembly를 부가적으로 언급하고 있습니다.
-
----
-*Last updated: 2026-04-19*
-- Raw Source: [[00_Raw/2026-04-20/WebAssembly.md]]
----
diff --git a/Graphics & Performance/WebGL 20.md b/Graphics & Performance/WebGL 20.md
deleted file mode 100644
index 746f54b9..00000000
--- a/Graphics & Performance/WebGL 20.md	
+++ /dev/null
@@ -1,33 +0,0 @@
----
-id: P-REINFORCE-AUTO-DDA796
-category: "[[10_Wiki/💡 Topics/Graphics & Performance]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - WebGL 20"
----
-
-# [[WebGL 20]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> WebGL 2.0은 웹 브라우저 환경에서 3D 그래픽을 렌더링하기 위한 API로, 브라우저가 WebGPU를 지원하지 않는 환경에서 WebGPURenderer가 자동으로 사용하는 대체(Fallback) 렌더러 역할을 합니다 [1, 2]. 최신 Three.js 개발 환경에서는 TSL(Three Shader Language)을 통해 WebGPU와 WebGL에서 모두 작동하는 크로스 플랫폼 셰이더를 작성할 수 있습니다 [1-3]. WebGL 2.0은 텍스처 배열(Data Array Textures)과 BatchedMesh 같은 기능을 지원하여 전통적인 WebGL 1.0의 한계를 극복하고 렌더링 성능을 높일 수 있는 강력한 기반을 제공합니다 [4, 5].
-
-## 📖 구조화된 지식 (Synthesized Content)
-* **Three.js에서의 WebGL 2.0 자동 폴백(Fallback):** 브라우저가 WebGPU를 지원하지 않을 경우 WebGPURenderer는 별도의 코드 분기 없이 자동으로 WebGL 2.0 렌더러로 동작합니다 [1, 2]. 개발자는 WebGPU 지원 환경에서 WebGL 폴백 동작을 테스트하거나 WebGPU에 없는 특정 WebGL 확장 기능을 사용해야 할 때 `forceWebGL: true` 옵션을 사용하여 강제로 WebGL 모드를 활성화할 수 있습니다 [6, 7]. 단, 프로덕션 환경이 WebGL 전용일 경우에는 번들 크기 축소를 위해 WebGLRenderer를 직접 사용하는 것이 권장됩니다 [7].
-* **고급 텍스처 및 배칭(Batching) 지원:** WebGL 2.0은 데이터 텍스처 배열(Data Array Textures) 기능을 지원하여, 기존 텍스처 아틀라스(Texture Atlas)의 치명적 단점인 가장자리 번짐(edge bleeding) 문제를 해결합니다 [4, 8, 9]. 이 기능은 2025년 기준 최신 브라우저 환경에서 우수한 호환성을 자랑하며, BatchedMesh와 결합하면 단일 드로우 콜(Draw call)만으로 여러 개의 다양한 텍스처를 가진 객체들을 매우 효율적으로 렌더링할 수 있습니다 [4, 5, 8].
-* **성능 및 메모리 관리의 한계:** WebGL 파이프라인에서는 렌더링 명령마다 CPU 오버헤드가 발생하여 실질적으로 1,000~2,000개의 드로우 콜(Draw call) 한계에 도달할 때 성능이 눈에 띄게 저하됩니다 [10]. 더불어 WebGL 컨텍스트는 브라우저와 기기에 따라 보통 256MB에서 1GB 수준의 유한한 메모리를 가지며, 이를 초과할 경우 컨텍스트 손실(Context Lost) 현상과 함께 뷰어가 멈추게 됩니다 [11, 12]. 따라서 메모리 누수를 방지하기 위해서는 폐기된 지오메트리나 머티리얼을 명시적으로 해제해야 하며, 모바일 등에서 컨텍스트가 손실될 경우에 대비해 우아하게(gracefully) 복구하는 로직이 필수적입니다 [12-14].
-* **셰이더 파이프라인의 통합:** TSL(Three Shader Language) 시스템의 도입으로, 개발자는 기존처럼 GLSL(WebGL)과 WGSL(WebGPU)의 두 가지 셰이더 코드베이스를 이중으로 유지할 필요가 없어졌습니다 [3, 15]. 하나의 TSL 코드가 각 백엔드에 맞게 자동 컴파일을 지원합니다 [3]. 포스트 프로세싱(Post-processing)의 경우, WebGL 프로젝트에서는 여전히 `pmndrs/postprocessing` 라이브러리가 가장 우수한 성능을 발휘하지만, TSL 기반 포스트 프로세싱도 혼용이 가능해졌습니다 [16].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Graphics & Performance 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[WebGPU]], [[Three.js]], [[Draw Calls]], [[BatchedMesh]], [[TSL (Three Shader Language)]]
-- **Projects/Contexts:** [[WebGPURenderer Fallback]]
-- **Contradictions/Notes:** 소스에 따르면 WebGPU는 멀티스레드 명령 생성과 Compute Shader 연산을 통해 복잡한 시뮬레이션 및 데이터 처리가 가능하지만, WebGL은 싱글 스레드 및 상태 기반 접근 방식을 취하고 있어 1,000~2,000회 이상의 빈번한 드로우 콜 발생 시 CPU에서 극심한 렌더링 성능 병목(Bottleneck) 현상이 발생한다는 뚜렷한 대비가 관찰됩니다 [10, 17, 18].
-
----
-*Last updated: 2026-04-19*
-- Raw Source: [[00_Raw/2026-04-20/WebGL 2.0.md]]
----
diff --git a/Graphics & Performance/WebGL API.md b/Graphics & Performance/WebGL API.md
deleted file mode 100644
index 635240b9..00000000
--- a/Graphics & Performance/WebGL API.md	
+++ /dev/null
@@ -1,37 +0,0 @@
----
-id: P-REINFORCE-AUTO-32752F
-category: "[[10_Wiki/💡 Topics/Graphics & Performance]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - WebGL API"
----
-
-# [[WebGL API]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> WebGL(Web Graphics Library)은 웹 브라우저의 HTML5 `<canvas>` 요소 내에서 하드웨어 가속을 통해 실시간 3D 및 2D 그래픽을 렌더링하기 위한 저수준(low-level) 크로스 플랫폼 애플리케이션 프로그래밍 인터페이스(API)입니다 [1-3]. OpenGL ES 2.0을 기반으로 구축되었으며, 자바스크립트(JavaScript) 코드를 GPU 명령어로 변환하여 그래픽 처리 장치(GPU)에서 직접 실행되도록 설계되었습니다 [2, 4]. 2011년에 도입된 이후 웹 기반 3D 그래픽의 핵심 기반으로 사용되어 왔으나, 단일 스레드 실행 및 전역 상태 머신 모델과 같은 아키텍처의 한계로 인해 CPU 병목 현상이 발생하는 등 최신 하드웨어 성능을 온전히 끌어내기에는 제약이 존재합니다 [4-7].
-
-## 📖 구조화된 지식 (Synthesized Content)
-* **작동 방식 및 렌더링 파이프라인:** 
-WebGL은 프로그래머 친화적이라기보다는 빠른 하드웨어 렌더링을 위해 최적화된 저수준 API로, 하드웨어 회로의 스위치를 직접 조작하는 것과 같은 역할을 수행합니다 [3]. 렌더링을 위해서는 HTML 캔버스 요소에서 WebGL 컨텍스트(`gl`)를 가져오고, 정점 셰이더(vertex shader)와 단편 셰이더(fragment shader)를 컴파일하여 렌더링 프로그램으로 링크해야 합니다 [8]. 이후 GPU 메모리에 버퍼 객체를 생성하여 모델 데이터를 복사하고, 자바스크립트 코드에서 `drawArrays()` 등과 같은 명령을 호출하여 화면에 그래픽을 그립니다 [8-10].
-
-* **성능 최적화 및 브라우저 오버헤드:** 
-WebGL은 브라우저 환경에서 실행되므로 보안을 위한 유효성 검사와 자바스크립트 호출을 변환하는 마샬링(marshalling) 과정에서 네이티브 환경 대비 오버헤드가 발생합니다 [11]. 컨텍스트 스위칭과 CPU-자바스크립트 프로그램 및 GPU 간의 데이터 통신은 렌더링 속도를 저하시키는 주된 원인입니다 [12, 13]. 따라서 고성능을 얻으려면 `getError()`, `getParameter()` 같이 비용이 큰 호출을 피하고, 배치(batching)나 인스턴싱(instancing) 기술을 활용해 드로우 콜(Draw Call) 횟수를 최소화해야 합니다 [10, 14]. 더불어 예측할 수 없는 가비지 컬렉션(Garbage Collection)으로 인한 렌더링 끊김을 막기 위해 가비지를 생성하지 않는 엄격한 자바스크립트 작성 방식이 요구됩니다 [15, 16].
-
-* **아키텍처의 구조적 한계:** 
-WebGL의 핵심적인 문제는 기반이 되는 아키텍처가 2011년 GPU 설계(OpenGL ES 2.0)에 머물러 있어 최신 그래픽 하드웨어의 기능을 충분히 활용할 수 없다는 점입니다 [4, 17]. 첫째, 단일 스레드 실행 모델로 인해 모든 드로우 콜과 상태 변경이 순차적으로 처리되어, GPU가 작업을 기다리는 동안 CPU에 과부하(병목 현상)가 발생합니다 [5, 7]. 둘째, 전역 상태 머신(global state machine)에 의존하므로 드로우 콜마다 매개변수를 개별적으로 설정해야 하며, 이 과정에서 CPU 측의 반복적인 상태 유효성 검사가 수반됩니다 [6, 18]. 셋째, 컴퓨트 셰이더(Compute Shader)를 지원하지 않아 입자 시스템이나 물리 시뮬레이션 같은 대규모 병렬 연산 작업조차 렌더링 오버헤드로 병목을 겪고 있는 CPU에서 수행해야 합니다 [19]. 이러한 한계들로 인해 오늘날 웹 산업에서는 멀티 스레드 명령 생성 및 컴퓨트 셰이더를 지원하는 차세대 API인 WebGPU로의 전환이 활발히 진행 중입니다 [20-23].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Graphics & Performance 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[OpenGL ES 2.0]], [[GPU]], [[HTML5 Canvas]], [[WebGPU]], [[JavaScript]]
-- **Projects/Contexts:** [[Three.js]], [[WebGLRenderingContext]]
-- **Contradictions/Notes:** 소스에 따르면 WebGL은 단일 스레드 실행과 컴퓨트 셰이더 미지원 등의 구조적 단점 때문에 성능에 민감하고 대규모 연산이 필요한 최신 3D 경험에서는 한계가 명확하여 WebGPU로 대체되고 있습니다 [7, 19, 23]. 하지만 보편적이고 폭넓은 브라우저 호환성이 필요한 프로덕션 환경(모든 기기에서 동작해야 하는 경우)에서는 WebGPU의 지원이 아직 완벽하지 않기 때문에 여전히 WebGL이 가장 안전하고 적절한 선택(또는 폴백)으로 간주됩니다 [24-26].
-
----
-*Last updated: 2026-04-19*
-- Raw Source: [[00_Raw/2026-04-20/WebGL API.md]]
----
diff --git a/Graphics & Performance/WebGL Optimization.md b/Graphics & Performance/WebGL Optimization.md
deleted file mode 100644
index f5eacea4..00000000
--- a/Graphics & Performance/WebGL Optimization.md	
+++ /dev/null
@@ -1,35 +0,0 @@
----
-id: P-REINFORCE-AUTO-655682
-category: "[[10_Wiki/💡 Topics/Graphics & Performance]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - WebGL Optimization"
----
-
-# [[WebGL Optimization]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> WebGL 최적화는 웹 브라우저 환경에서 3D 그래픽스의 렌더링 속도와 메모리 효율성을 향상시키기 위한 체계적인 기술과 방법론을 의미합니다 [1, 2]. 주된 목적은 CPU와 GPU 간의 통신 오버헤드를 유발하는 드로우 콜(Draw Call)을 최소화하여 안정적인 60 FPS 프레임 레이트를 유지하는 것입니다 [2, 3]. 이를 위해 기하학적 구조 인스턴싱(Instancing), 텍스처 압축, 디테일 수준(LOD) 제어, 그리고 브라우저 메모리 한계를 고려한 자원 해제 등의 최적화 기법이 복합적으로 적용됩니다 [4-6].
-
-## 📖 구조화된 지식 (Synthesized Content)
-* **드로우 콜 최적화 (Draw Call Optimization):** CPU가 GPU에게 렌더링을 명령하는 '드로우 콜'은 WebGL 렌더링 성능을 떨어뜨리는 가장 큰 병목 현상입니다 [7, 8]. WebGL 환경에서는 CPU-GPU 통신 오버헤드를 막기 위해 프레임당 드로우 콜을 100회 미만으로 타겟팅하는 것이 좋으며, 1,000~2,000회에 도달하면 심각한 성능 저하가 발생합니다 [9, 10]. 이를 해결하기 위해 동일한 기하학적 구조를 반복 렌더링하는 `InstancedMesh`, 다양한 구조라도 동일한 재질이면 병합 처리하는 `BatchedMesh`, 그리고 정적 객체의 지오메트리 병합(Geometry Merging) 기술을 필수적으로 활용해야 합니다 [9, 11-13].
-* **에셋 및 텍스처 압축 (Asset & Texture Optimization):** 웹 환경의 메모리 대역폭을 고려하여, 폴리곤 수는 모바일 및 웹 뷰어 기준 10,000개에서 100,000개 사이로 유지(Decimation/Retopology)하는 것이 권장됩니다 [14, 15]. 또한 일반 PNG 텍스처는 GPU 메모리를 과도하게 점유하므로 KTX2나 Basis Universal과 같이 GPU 친화적인 압축 형식을 사용하여 메모리 사용량을 75~90%가량 줄이고, 텍스처 아틀라스(Texture Atlas)로 여러 텍스처를 하나로 병합해 바인딩 횟수를 감소시켜야 합니다 [16-18].
-* **메모리 파이프라인 관리 (Memory Pipeline Management):** WebGL 컨텍스트는 브라우저 환경에서 대개 256MB~1GB의 메모리 한계를 지니고 있어 한계를 초과하면 브라우저가 충돌합니다 [6]. 따라서 사용하지 않는 지오메트리, 재질, 텍스처는 가비지 컬렉터에 의존하지 않고 명시적으로 `.dispose()`를 호출해 GPU 메모리에서 해제해야 합니다 [19, 20]. 또한 카메라 시야 범위 밖의 연산을 건너뛰게 하는 시야 절두체 컬링(Frustum Culling), 거리에 따라 객체 디테일을 동적으로 줄이거나 빌보드 임포스터로 대체하는 LOD(Level of Detail) 시스템 적용도 필수입니다 [21-24].
-* **셰이더 연산 간소화 (Shader & Overdraw Optimization):** 모바일 GPU에서는 연산 속도를 2배 이상 높일 수 있도록 `mediump` 정밀도를 사용하는 것이 유리합니다 [25]. 프래그먼트 셰이더 내에서 분기문(Conditionals)은 GPU 병렬 처리를 방해하므로 `mix()` 및 `step()` 함수로 대체하고, 다중 텍스처 조회를 줄이기 위해 여러 PBR 데이터를 RGBA 채널에 압축(Packing)해야 대역폭을 절약할 수 있습니다 [26, 27]. 또한 보이지 않는 투명한 기하학적 구조가 겹쳐 불필요하게 렌더링 연산을 반복하는 오버드로우(Overdraw)를 최소화해야 합니다 [28].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Graphics & Performance 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[Draw Call]], [[InstancedMesh]], [[BatchedMesh]], [[Frustum Culling]], [[Level of Detail (LOD)]]
-- **Projects/Contexts:** [[Three.js]]
-- **Contradictions/Notes:** 
-  - `InstancedMesh`는 드로우 콜을 1회로 줄여주어 강력하지만, 단일 엔진 객체로 취급되기 때문에 인스턴스 각각에 대한 시야 절두체 컬링(Frustum Culling)이 개별 적용되지 않는 한계가 있습니다 [29]. 따라서 화면에 하나의 인스턴스만 걸쳐 있어도 보이지 않는 나머지 인스턴스의 정점 연산까지 수행해야 하는 GPU 낭비가 발생할 수 있습니다 [29].
-  - 오버드로우(Overdraw) 관점에서도 `InstancedMesh`는 자동 정렬(Sorting) 기능을 지원하지 않아 뒤에 있는 객체가 덮어 씌워지면서 픽셀 처리에 병목을 일으킬 수 있으므로, 상황에 따라서는 오히려 개별 메쉬나 정적 지오메트리 병합(Merging)을 활용하는 것이 더 높은 FPS를 제공할 수 있다고 지적합니다 [30-32]. 
-
----
-*Last updated: 2026-04-19*
-- Raw Source: [[00_Raw/2026-04-20/WebGL Optimization.md]]
----
diff --git a/Graphics & Performance/WebGL 모바일 GPU 성능 관리.md b/Graphics & Performance/WebGL 모바일 GPU 성능 관리.md
deleted file mode 100644
index efe2a670..00000000
--- a/Graphics & Performance/WebGL 모바일 GPU 성능 관리.md	
+++ /dev/null
@@ -1,39 +0,0 @@
----
-id: P-REINFORCE-AUTO-3EE85A
-category: "[[10_Wiki/💡 Topics/Graphics & Performance]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - WebGL 모바일 GPU 성능 관리"
----
-
-# [[WebGL 모바일 GPU 성능 관리]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> WebGL 모바일 GPU 성능 관리는 처리 능력과 메모리 용량이 제한적인 모바일 디바이스 환경에서 3D 애플리케이션이 부드럽게 구동될 수 있도록 렌더링 부하를 줄이는 기술적 과정입니다. 모바일 브라우저는 처리 가능한 폴리곤 수와 드로우 콜(Draw Call)에 뚜렷한 한계가 있으며, 이를 극복하기 위해 셰이더 정밀도 조절, 텍스처 압축, 배터리 소모 관리 등의 다각적인 최적화가 요구됩니다 [1-4].
-
-## 📖 구조화된 지식 (Synthesized Content)
-* **모바일 하드웨어의 렌더링 및 메모리 한계:** 
-  모바일 브라우저(iOS Safari, Chrome Mobile 등)는 장면당 5만에서 10만 개의 폴리곤을 처리하는 것이 권장되며, 드로우 콜이 1,000~2,000회를 넘어가면 CPU 병목 현상으로 인한 성능 저하가 눈에 띄게 나타납니다 [2, 3]. 특히 2~4GB의 시스템 메모리를 가진 기기에서는 텍스처 메모리가 500MB를 초과할 경우 가비지 컬렉션(GC)으로 인한 멈춤 및 프레임 끊김 현상이 심각하게 발생할 수 있습니다 [4].
-* **셰이더 및 데이터 정밀도 최적화:** 
-  모바일 GPU는 `mediump` 정밀도 처리 속도가 `highp`보다 약 2배 빠르므로, 깊이 계산이나 위치 정보 등 필수적인 경우를 제외하고는 기본적으로 `mediump` 정밀도를 사용하는 것이 유리합니다 [1]. 또한, 버텍스 셰이더와 프래그먼트 셰이더 간에 데이터를 전달하는 Varying 변수의 개수도 모바일 기기의 한계를 고려하여 3개 이하로 최소화해야 합니다 [1].
-* **텍스처 및 렌더링 옵션 조율:** 
-  여러 텍스처를 하나로 결합하는 텍스처 아틀라스(Texture Atlas)를 활용하면 모바일 GPU에서 큰 부담이 되는 텍스처 바인딩 오버헤드를 획기적으로 줄일 수 있습니다 [5]. 추가적으로 Basis Universal과 같은 툴을 이용해 모바일 특화 포맷(iOS의 PVRTC, 안드로이드의 ASTC 등)으로 트랜스코딩하여 메모리 사용량을 줄여야 하며 [6], 섀도우 맵의 크기는 모바일에 맞게 512에서 1024 사이로 설정해야 합니다 [7]. 모바일 기기에서 60fps를 유지하기 위해서는 기본 네이티브 안티앨리어싱(MSAA)을 비활성화하고, 그 대신 FXAA와 같은 포스트 프로세싱 기반의 안티앨리어싱을 적용하는 것이 좋습니다 [8].
-* **전력 보존 및 상태 관리:** 
-  씬(Scene)이 정적일 때 매 프레임 렌더링을 하지 않는 온디맨드(`frameloop="demand"`) 렌더링 방식을 사용해 모바일 디바이스의 배터리 소모를 줄여야 합니다 [9]. 이와 함께 모바일 환경 특성상 WebGL 컨텍스트 유실(Context lost) 현상이 발생할 수 있으므로, 이를 감지하고 자연스럽게 복구할 수 있는 이벤트 리스너 처리가 필수적입니다 [10].
-* **컬링 부재 시 모바일 성능 치명타:** 
-  개별적인 인스턴스에 대해 시야 절두체 컬링(Frustum culling)이 이루어지지 않을 경우, 보이지 않는 객체에 대한 정점 셰이더의 행렬 연산이 인스턴스 수에 비례해 선형적으로 증가하므로, 저사양 모바일 기기나 통합 GPU 환경에서는 치명적인 성능 저하를 일으킬 수 있습니다 [11].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Graphics & Performance 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[Draw Calls]], [[Texture Atlas]], [[셰이더 정밀도 (Mediump/Highp)]], [[Varying Variables]], [[FXAA]]
-- **Projects/Contexts:** [[Three.js 모바일 렌더링 최적화]], [[모바일 기반 WebGL 애플리케이션 개발]]
-- **Contradictions/Notes:** 모바일 환경 최적화를 위해 다양한 기법을 동원하더라도, 텍스처 메모리를 500MB 이하로 통제하지 않으면 가비지 컬렉션(GC) 멈춤 현상으로 최적화 효과가 상쇄될 수 있으므로 메모리 사용량에 대한 엄격한 제한이 우선되어야 합니다 [4].
-
----
-*Last updated: 2026-04-19*
-- Raw Source: [[00_Raw/2026-04-20/WebGL 모바일 GPU 성능 관리.md]]
----
diff --git a/Graphics & Performance/WebGL.md b/Graphics & Performance/WebGL.md
deleted file mode 100644
index 6cf38599..00000000
--- a/Graphics & Performance/WebGL.md	
+++ /dev/null
@@ -1,35 +0,0 @@
----
-id: P-REINFORCE-AUTO-7B2955
-category: "[[10_Wiki/💡 Topics/Graphics & Performance]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - WebGL"
----
-
-# [[WebGL]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> **WebGL**은 플러그인 없이 웹 브라우저에서 2D 및 3D 그래픽을 렌더링하기 위한 저수준(Low-level) JavaScript API입니다. 원시 WebGL은 직접 다루기 매우 복잡하고 장황하지만, **Three.js**나 **React Three Fiber(R3F)** 같은 라이브러리를 통해 추상화되어 현대 웹의 고성능 3D 인터랙티브 그래픽과 게임 엔진을 구현하는 핵심 기반 기술로 사용됩니다.
-
-## 📖 구조화된 지식 (Synthesized Content)
-**1. WebGL의 복잡성과 Three.js의 역할** WebGL 자체는 셰이더 코드와 버퍼를 직접 다루어야 하는 매우 저수준(Low-level)의 시스템입니다. 이러한 복잡성을 줄이고자 개발된 것이 Three.js 라이브러리이며, 개발자에게 씬(Scene), 카메라, 기하구조(Geometry), 재질(Material), 렌더러 등의 추상화된 객체를 제공하여 WebGL 렌더링 파이프라인을 훨씬 쉽게 구축할 수 있도록 지원합니다.
-
-**2. WebGL의 메모리 및 자원 관리 (가비지 컬렉션 한계)** JavaScript의 일반적인 힙 메모리와 달리, WebGL이 사용하는 GPU 자원(VRAM에 올라간 텍스처, 기하구조, 재질, 렌더 타겟 등)은 브라우저의 가비지 컬렉터(GC)에 의해 자동으로 회수되지 않습니다. 따라서 심각한 메모리 누수와 GPU 크래시를 방지하려면, 사용이 끝난 자원에 대해 반드시 명시적으로 `.dispose()` 메서드를 호출하여 직접 메모리를 해제해야 합니다. GLTF 모델에서 로드된 `ImageBitmap` 텍스처의 경우 `.close()` 호출도 필요합니다.
-
-**3. 성능 최적화와 드로우 콜(Draw Call)** WebGL 렌더링의 주된 성능 병목은 CPU가 GPU에게 그리기 명령을 내리는 **'드로우 콜(Draw Call)'**에서 발생합니다. 부드러운 60FPS를 유지하기 위한 황금률은 프레임당 드로우 콜을 100회 미만으로 유지하는 것입니다. 수백, 수천 개의 동일한 객체를 그릴 때는 개별 메시(Mesh)를 생성하지 않고, 단 1회의 드로우 콜만으로 GPU 내부에서 객체를 복제하는 `InstancedMesh` 최적화 기법을 사용해야 합니다. 모바일 WebGL 환경의 셰이더에서는 `mediump` 정밀도를 사용하여 연산 성능을 2배가량 향상시킬 수 있습니다.
-
-**4. OffscreenCanvas를 통한 메인 스레드 분리** 복잡한 WebGL 3D 씬 연산은 메인 스레드를 블로킹하여 사용자 UI의 반응성을 크게 떨어뜨릴 수 있습니다. 이를 해결하기 위해 `OffscreenCanvas` API를 사용하여 WebGL 렌더링 컨텍스트를 DOM에서 완전히 분리하고, **웹 워커(Web Worker)**라는 백그라운드 스레드에서 WebGL을 실행할 수 있습니다. 이 멀티스레드 아키텍처는 무거운 그래픽 연산 중에도 UI가 매끄럽게 동작하도록 보장합니다.
-
-**5. 차세대 WebGPU와의 공존과 TSL** 현재 WebGL 2는 브라우저의 97% 이상을 커버하는 가장 안정적이고 널리 쓰이는 표준입니다. 하지만 수십만 개의 입자를 제어하거나 고성능 물리 연산을 처리하는 컴퓨트 셰이더(Compute Shaders) 기능의 부재로 인해, 차세대 그래픽스 API인 **WebGPU**로 전환되는 추세입니다. 이에 대응하여 최신 Three.js는 **TSL (Three Shader Language)**이라는 노드 기반 셰이더 시스템을 도입했습니다. TSL로 작성된 코드는 WebGPU용 WGSL과 WebGL용 GLSL로 동시 컴파일되며, WebGPU를 지원하지 않는 브라우저에서는 **자동으로 WebGL 2로 폴백(Fallback)**되도록 설계되어 호환성과 성능을 모두 잡고 있습니다.
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Graphics & Performance 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[Three.js]], [[React Three Fiber (R3F)]], [[WebGPU Compute Shaders]], [[OffscreenCanvas]], [[InstancedMesh (드로우 콜 최적화)]], [[Memory Leak Prevention (메모리 누수 방지)]]
-- **Projects/Contexts:** [[브라우저 기반 3D 데이터 시각화 및 디지털 트윈]], [[멀티스레드 기반 고성능 웹 게임 엔진]]
-- **Contradictions/Notes:** WebGL 파이프라인에서 `EffectComposer` 등을 활용해 커스텀 후처리(Post-processing)를 적용할 경우, WebGL의 내장 안티앨리어싱(AA) 기능이 무효화되는 제약이 있습니다. 이를 해결하려면 파이프라인 마지막 단계에 SMAA나 FXAA 효과 패스를 수동으로 추가해 주어야 시각적 품질을 유지할 수 있습니다.
-- Raw Source: [[00_Raw/2026-04-20/WebGL.md]]
----
diff --git a/Graphics & Performance/WebGL2.md b/Graphics & Performance/WebGL2.md
deleted file mode 100644
index 28be87ba..00000000
--- a/Graphics & Performance/WebGL2.md	
+++ /dev/null
@@ -1,35 +0,0 @@
----
-id: P-REINFORCE-AUTO-208D23
-category: "[[10_Wiki/💡 Topics/Graphics & Performance]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - WebGL2"
----
-
-# [[WebGL2]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> WebGL2는 웹 브라우저 환경에서 3D 그래픽스를 렌더링하기 위해 사용되는 그래픽 API입니다 [1, 2]. 최신 Three.js 생태계에서는 차세대 API인 WebGPU로의 전환이 이루어지고 있으나, WebGPU를 지원하지 않는 브라우저에서는 WebGL 2가 자동 대체(Fallback) 수단으로서 핵심적인 역할을 수행합니다 [3, 4]. WebGL1과 비교했을 때 데이터 배열 텍스처(Data Array Textures)를 지원하고 텍스처 아틀라스의 블리딩(Bleeding) 현상을 더 쉽게 제어할 수 있는 등 진보된 기능을 제공하지만, WebGPU와 달리 컴퓨트 셰이더(Compute Shaders)를 지원하지 않는 한계가 있습니다 [1, 5, 6].
-
-## 📖 구조화된 지식 (Synthesized Content)
-- **WebGPU의 자동 대체(Fallback) 시스템:** 
-  Three.js(r171 버전 이후)에서 제공하는 `WebGPURenderer`는 사용자의 브라우저가 WebGPU를 지원하지 않을 경우, 별도의 코드 분기 없이 자동으로 WebGL 2 환경으로 전환하여 호환성을 유지합니다 [3, 7]. 개발자는 디버깅이나 아직 WebGPU에서 지원하지 않는 특정 WebGL 확장 기능을 사용하기 위해 `forceWebGL: true` 옵션으로 강제 WebGL 렌더링 모드를 활성화할 수 있습니다 [8, 9].
-- **데이터 배열 텍스처(Data Array Textures) 및 렌더링 최적화:** 
-  WebGL2는 데이터 배열 텍스처 기술을 지원하여 여러 텍스처를 셰이더 내에서 인덱스로 접근할 수 있는 스택 형태로 제공합니다 [1, 10]. 이 방식은 텍스처 아틀라싱의 주요 단점인 인접 텍스처 간의 경계선 블리딩(Edge Bleeding) 문제를 해결하고 네이티브 래핑(Wrapping)을 지원합니다 [1, 10]. 또한 WebGL2 환경에서는 WebGL1에 비해 아틀라스 블리딩 처리가 훨씬 수월합니다 [6].
-- **성능 및 기능적 한계:** 
-  WebGL2는 현대 렌더링의 필수 기술로 자리 잡은 컴퓨트 셰이더(Compute Shaders)를 지원하지 않습니다 [5]. 따라서 GPU 병렬 처리를 통한 복잡한 물리 연산, 대규모 파티클 시스템 업데이트, GPU 주도의 정밀한 컬링(GPU-driven Culling) 등은 불가능하며, 이러한 한계를 극복하기 위해 대규모 프로젝트에서는 WebGPU로의 아키텍처 전환이 권장되고 있습니다 [2, 5, 11].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Graphics & Performance 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[WebGPU]], [[Three.js]], [[Data Array Textures]], [[Compute Shaders]]
-- **Projects/Contexts:** [[Three.js WebGPURenderer 자동 폴백 지원]], [[BatchedMesh 및 드로우 콜 최적화 파이프라인]]
-- **Contradictions/Notes:** 소스에 따르면 WebGL 2는 현재 널리 지원되는 강력한 그래픽 API이지만, 컴퓨트 셰이더를 통한 GPU 기반의 병렬 가시성 연산(Compute Culling)이나 대규모 간접 드로우(Indirect Draw) 부재로 인해 렌더링 성능 최적화의 기술적 한계점에 도달해 있습니다 [2, 5, 11].
-
----
-*Last updated: 2026-04-19*
-- Raw Source: [[00_Raw/2026-04-20/WebGL2.md]]
----
diff --git a/Graphics & Performance/WebGLRenderingContext.md b/Graphics & Performance/WebGLRenderingContext.md
deleted file mode 100644
index 181904e3..00000000
--- a/Graphics & Performance/WebGLRenderingContext.md	
+++ /dev/null
@@ -1,32 +0,0 @@
----
-id: P-REINFORCE-AUTO-47CDF1
-category: "[[10_Wiki/💡 Topics/Graphics & Performance]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - WebGLRenderingContext"
----
-
-# [[WebGLRenderingContext]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> WebGLRenderingContext는 HTML 캔버스(canvas) 요소에 대한 WebGL 컨텍스트를 보유하는 자바스크립트 객체입니다 [1, 2]. 개발자들 사이에서 일반적으로 `gl`이라고 명명되며, 애플리케이션은 이 객체를 통해 하드웨어 그래픽 파이프라인의 모든 WebGL 기능(API)에 접근하고 제어합니다 [1, 2]. 이 컨텍스트를 생성하는 작업은 브라우저가 동기적으로 OpenGL 컨텍스트를 생성하도록 강제하므로 운영 체제나 시스템 환경에 따라 속도가 느려질 수 있습니다 [3].
-
-## 📖 구조화된 지식 (Synthesized Content)
-- **컨텍스트의 획득 및 역할:** 모델 데이터를 렌더링하기 위한 전처리 과정 중 하나로, 먼저 HTML 캔버스 요소를 가져온 뒤 해당 요소의 WebGL 컨텍스트(WebGLRenderingContext)를 얻어야 합니다 [1]. 모든 WebGL 기능은 이 객체를 통해서만 접근할 수 있으며 [2], 필요에 따라 `getExtension()` 메서드를 호출하여 `EXT_disjoint_timer_query`와 같은 추가적인 WebGL 확장(Extension) 기능들을 사용할 수도 있습니다 [4].
-- **초기화에 따른 성능 비용:** WebGLRenderingContext의 생성은 비용이 많이 드는 작업입니다. 리눅스(Linux) 환경의 경우 드라이버에 따라 50ms에서 200ms까지 소요될 수 있습니다 [3]. 특히 듀얼 GPU를 탑재한 Mac 시스템에서는 컨텍스트 생성 시 외장 그래픽 모드로의 전환을 유발하여 약 1초가량의 심각한 지연을 발생시키기도 합니다 [5, 6]. 이로 인해 실제 WebGL 호출이 필요한 시점까지 컨텍스트 생성을 지연시키지 않으면 페이지 로드 속도가 크게 저하될 수 있습니다 [3, 7, 8].
-- **브라우저 가용성:** 파이어폭스(Firefox) 브라우저의 공식 빌드에서는 하드웨어 GPU가 블랙리스트에 등록되어 있더라도 WebGLRenderingContext가 항상 존재합니다 (빌드 시 완전히 비활성화된 경우 제외) [9].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Graphics & Performance 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[WebGL]], [[OpenGL]], [[GPU]]
-- **Projects/Contexts:** [[Modernizr]], [[LearnWebGL]]
-- **Contradictions/Notes:** 소스 간의 모순된 내용은 없으나, WebGLRenderingContext 생성에 따른 성능 지연 문제와 관련해 페이지 로드 시 불필요하게 컨텍스트를 생성하지 않아야 한다는 점이 강조됩니다 [3, 7].
-
----
-*Last updated: 2026-04-19*
-- Raw Source: [[00_Raw/2026-04-20/WebGLRenderingContext.md]]
----
diff --git a/Graphics & Performance/WebGPU Compute Shader.md b/Graphics & Performance/WebGPU Compute Shader.md
deleted file mode 100644
index 2b633cf9..00000000
--- a/Graphics & Performance/WebGPU Compute Shader.md	
+++ /dev/null
@@ -1,33 +0,0 @@
----
-id: P-REINFORCE-AUTO-B03C61
-category: "[[10_Wiki/💡 Topics/Graphics & Performance]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - WebGPU Compute Shader"
----
-
-# [[WebGPU Compute Shader]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> WebGPU Compute Shader는 범용 GPU 연산을 수행하여 메인 스레드(CPU)의 과중한 작업을 GPU 코어로 분산시키는 렌더링 기술이다 [1, 2]. InstancedMesh를 사용할 때 발생하는 가시성 판단(컬링) 및 데이터 전송 병목 현상을 극복하기 위해 GPU 주도 렌더링(GPU-driven Rendering)을 구현하는 데 핵심적인 역할을 한다 [2]. 이를 통해 수백만 개의 파티클이나 대규모 인스턴스의 물리 연산 및 컬링을 CPU 개입 없이 GPU 내부에서 병렬로 직접 처리할 수 있다 [1-3].
-
-## 📖 구조화된 지식 (Synthesized Content)
-* **GPU 주도 컬링 및 간접 그리기(Indirect Draw):** InstancedMesh의 근본적인 문제인 'CPU 기반 가시성 판단 오버헤드'를 해결하기 위해 활용된다 [2]. 컴퓨트 셰이더가 모든 인스턴스의 시야 포함 여부(Frustum Culling)와 가림 현상(Occlusion)을 직접 판별하고, 시야에 존재하는 인스턴스 정보만 GPU 내부 버퍼에 담아 간접 그리기(`drawIndirect` 또는 간접 버퍼) 명령으로 출력한다 [2, 4, 5]. 이로 인해 CPU와 GPU 간의 데이터 전송량이 거의 0에 수렴하게 되며, 수백만 개의 인스턴스 렌더링에 필수적인 최적화를 제공한다 [2, 6].
-* **대규모 연산의 병렬 처리:** 기존 CPU 기반의 시스템은 약 50,000개 수준의 파티클 업데이트에서 성능 병목을 겪지만, WebGPU 컴퓨트 셰이더를 활용하면 수백만 개 단위의 연산으로 한계를 확장할 수 있다 [3]. 파티클뿐만 아니라 물리 시뮬레이션이나 대규모 지형의 실시간 절차적 생성(Procedural generation) 등 연산 집약적인 작업을 GPU에서 실시간으로 처리할 수 있다 [1, 7].
-* **작업 그룹 공유 메모리와 렌더링 동기화:** 컴퓨트 셰이더 내에서 스레드 간 데이터 공유가 필요한 경우, 전역 메모리보다 10~100배 빠른 작업 그룹 공유 메모리(workgroup shared memory)를 활용하여 성능을 높일 수 있다 [1, 6]. 또한, 씬에 컴퓨트 셰이더 작업이 포함된 경우, 종속된 렌더 패스가 시작되기 전에 컴퓨트 패스가 완전히 끝나도록 보장하기 위해 비동기 렌더링(`renderAsync`)을 사용하여 GPU 작업을 동기화해야 한다 [8].
-* **스토리지 텍스처(Storage Textures) 활용:** 일반 텍스처와 달리 컴퓨트 셰이더 내에서 읽기와 쓰기가 모두 가능한 스토리지 텍스처를 지원한다 [9]. 이는 유체 시뮬레이션, 이미지 처리, 그리고 GPU 주도 렌더링 등 복잡한 효과를 구현하는 데 필수적인 요소로 작용한다 [9].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Graphics & Performance 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[GPU-driven Rendering]], [[Indirect Draw]], [[Frustum Culling]], [[Draw Call]]
-- **Projects/Contexts:** [[대규모 건축물 및 지형 뷰어(BIM)]], [[Three.js WebGPU 파티클 예제]], [[실시간 물리 및 유체 시뮬레이션]]
-- **Contradictions/Notes:** 컴퓨트 셰이더를 통해 GPU 단에서 컬링 및 피킹 처리를 최적화할 수 있으나, 다른 인스턴스에 의해 가려진 객체들을 포함하여 올가미(Lasso) 그룹 선택을 하는 것과 같은 복잡한 상호작용은 컴퓨트 셰이더만으로는 간단히 해결되지 않으며, 깊이 벗기기(depth-peeling)와 같은 추가적인 셰이더 작업이나 웹 워커가 필요할 수 있다 [10].
-
----
-*Last updated: 2026-04-19*
-- Raw Source: [[00_Raw/2026-04-20/WebGPU Compute Shader.md]]
----
diff --git a/Graphics & Performance/WebGPU Compute Shaders.md b/Graphics & Performance/WebGPU Compute Shaders.md
deleted file mode 100644
index 1a789a27..00000000
--- a/Graphics & Performance/WebGPU Compute Shaders.md	
+++ /dev/null
@@ -1,34 +0,0 @@
----
-id: P-REINFORCE-AUTO-1903E0
-category: "[[10_Wiki/💡 Topics/Graphics & Performance]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - WebGPU Compute Shaders"
----
-
-# [[WebGPU Compute Shaders]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> WebGPU Compute Shader는 JavaScript의 메인 스레드에서 수행되던 무거운 범용 연산을 수많은 GPU 코어를 활용해 병렬로 처리할 수 있게 해주는 기능입니다 [1]. CPU 기반 연산의 병목 현상을 해소하여 수백만 개의 파티클이나 대규모 복잡한 시뮬레이션을 실시간으로 처리할 수 있도록 돕습니다 [2, 3]. Three.js와 같은 라이브러리를 통해 접근성이 크게 향상되었으며, 대규모 데이터 필터링, 물리 시뮬레이션, GPU 주도 렌더링 등 고성능이 요구되는 작업에 필수적으로 사용됩니다 [1, 4].
-
-## 📖 구조화된 지식 (Synthesized Content)
-* **성능 향상 및 병목 해소:** 기존 CPU 기반의 업데이트는 약 50,000개의 파티클에서 병목 현상이 발생했으나, WebGPU 컴퓨트 셰이더를 사용하면 이를 수백만 개 단위로 확장할 수 있습니다 [2]. 실제로 CPU에서 프레임당 30ms가 걸리던 10,000개의 파티클 업데이트 작업을 컴퓨트 셰이더를 통해 100,000개의 파티클을 2ms 이내에 처리하는 수준(약 150배 향상)으로 대폭 개선할 수 있습니다 [3].
-* **주요 활용 사례:** 컴퓨트 셰이더는 충돌 감지, 대규모 데이터 필터링, 실시간 조명, 물리 연산 등 병렬 처리가 필요한 작업에 매우 적합합니다 [1, 4-6]. 또한 실시간 편집과 거대한 규모를 지원하는 절차적 지형 생성(Procedural terrain generation)에도 사용됩니다 [6]. 애니메이션 시퀀스를 위한 '컴퓨트 스키닝(Compute skinning)' 기법에도 활용되어, 컴퓨트 단계에서 메쉬 정점 변환을 계산해 버퍼에 저장하고 렌더링 패스에서 재사용함으로써 중복 계산을 없앨 수 있습니다 [3].
-* **스토리지 텍스처(Storage Textures) 활용:** 일반 텍스처와 달리 컴퓨트 셰이더에서 읽기와 쓰기가 모두 가능하며, 유체 시뮬레이션, 이미지 처리, GPU 주도 렌더링과 같은 효과를 구현하는 데 필수적입니다 [5, 7].
-* **메모리 및 동기화 관리:** 스레드 간 데이터 공유가 필요한 컴퓨트 셰이더의 경우, 전역 메모리보다 10~100배 빠른 작업 그룹 공유 메모리(Workgroup shared memory)를 활용할 수 있습니다 [6, 8]. 연산이 포함된 씬을 렌더링할 때는 `renderAsync`(또는 `renderer.computeAsync`)를 사용하여 GPU 작업을 동기화하고, 종속된 렌더 패스가 시작되기 전에 컴퓨트 패스가 완료되도록 보장해야 합니다 [9, 10].
-* **간접 그리기(Indirect Draws)와의 결합:** 컴퓨트 셰이더의 연산 결과를 바탕으로 GPU가 스스로 무엇을 렌더링할지 결정하게 하는 간접 그리기 기능을 활용할 수 있습니다 [8]. 이를 통해 CPU-GPU 간의 동기화 지연을 제거하고 초당 프레임 수준의 GPU 기반 컬링(Culling)을 효율적으로 수행할 수 있습니다 [8, 11, 12].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Graphics & Performance 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[Storage Textures]], [[Indirect Draws]], [[TSL (Three Shader Language)]], [[Compute Skinning]]
-- **Projects/Contexts:** [[Three.js r171+]] (WebGPURenderer 도입 및 TSL 통합으로 컴퓨트 셰이더 지원 [13-17]), [[BIM Datasets]] (대규모 데이터 필터링 및 병렬 처리 적용 맥락 [3]), [[Expo 2025 Osaka]] (100만 개 파티클 유체 시뮬레이션 적용 사례 [18, 19])
-- **Contradictions/Notes:** WebGL이나 WebGL2 환경에서는 컴퓨트 셰이더가 지원되지 않으며 WebGPU 환경에서만 동작합니다 [20]. Three.js의 TSL과 렌더러를 사용하면 비교적 쉽게 컴퓨트 셰이더를 구현할 수 있지만, 네이티브 WebGPU를 사용할 경우 더 세밀한 직접 제어 및 다중 패스 물리 연산 등이 가능한 대신 그래픽스 파이프라인에 대한 매우 높은 기술적 숙련도가 요구된다는 트레이드오프가 존재합니다 [1, 4, 10].
-
----
-*Last updated: 2026-04-19*
-- Raw Source: [[00_Raw/2026-04-20/WebGPU Compute Shaders.md]]
----
diff --git a/Graphics & Performance/WebGPU Performance Profiling.md b/Graphics & Performance/WebGPU Performance Profiling.md
deleted file mode 100644
index 1180e184..00000000
--- a/Graphics & Performance/WebGPU Performance Profiling.md	
+++ /dev/null
@@ -1,40 +0,0 @@
----
-id: P-REINFORCE-AUTO-A8AA46
-category: "[[10_Wiki/💡 Topics/Graphics & Performance]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - WebGPU Performance Profiling"
----
-
-# [[WebGPU Performance Profiling]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> WebGPU Performance Profiling은 WebGPU API를 활용하는 웹 애플리케이션에서 컴퓨트 및 렌더 패스 경계에서의 GPU 명령 실행 시간을 정밀하게 측정하고 분석하는 과정입니다 [1, 2]. 개발자는 이를 통해 성능 병목 현상을 식별하고 최적화할 수 있으나, 타이밍 기반의 보안 공격을 방지하기 위해 타임스탬프의 정밀도가 의도적으로 낮춰져(Quantization) 제공됩니다 [1, 3, 4]. 하드웨어 수준의 타이머 접근이 제한될 경우, 개발자는 브라우저 내부의 트레이싱 도구를 활용하여 시스템 수준의 프로파일링을 수행할 수 있습니다 [5, 6].
-
-## 📖 구조화된 지식 (Synthesized Content)
-* **타임스탬프 쿼리(Timestamp Queries):**
-  WebGPU는 `timestamp-query` 기능과 `GPUQuerySet`을 도입하여 컴퓨트 패스와 렌더 패스의 시작 및 종료 지점에서 나노초 단위의 정밀한 실행 시간 측정을 지원합니다 [1, 2]. 이는 개발자가 GPU 작업 부하의 성능과 동작에 대한 심층적인 통찰력을 얻을 수 있도록 돕는 핵심 프로파일링 수단입니다 [2].
-
-* **보안을 위한 양자화(Quantization) 및 정밀도 저하:**
-  고해상도 타이머는 Spectre나 Rowhammer와 같은 캐시 사이드 채널 공격(타이밍 공격)에 악용될 수 있습니다 [1, 7, 8]. 이러한 보안 취약점을 완화하기 위해, 브라우저 벤더들은 타임스탬프 쿼리의 해상도를 100 마이크로초 단위로 제한하는 양자화(Coarsening/Quantization)를 적용합니다 [3, 4, 9]. 교차 출처 격리(Cross-origin isolated) 상태와 무관하게 고해상도 시간(High Resolution Time) 사양에 맞춰 100 마이크로초의 해상도를 제공하는 방향으로 합의가 이루어졌습니다 [10, 11].
-
-* **로컬 개발 환경에서의 정밀도 제어:**
-  Chrome 브라우저에서는 디버깅 및 성능 최적화를 위해 개발자가 정밀도 제한을 직접 해제할 수 있습니다. `chrome://flags/#enable-webgpu-developer-features` 플래그를 활성화하면 타임스탬프 양자화를 비활성화할 수 있습니다 [3, 12]. 단, `timestamp-query` 기능 자체는 실험적이므로 `chrome://flags/#enable-unsafe-webgpu` 지원 플래그가 함께 필요할 수 있습니다 [12].
-
-* **브라우저 내부 트레이싱 및 프로파일링 도구:**
-  하드웨어 타이머를 사용할 수 없거나 불충분한 경우, Chrome DevTools의 Performance 패널이나 `chrome://tracing`(`about:tracing`)과 같은 시스템 수준의 브라우저 프로파일링 도구를 사용할 수 있습니다 [5, 13]. 이 도구들을 통해 `CrGpuMain`(GPU 프로세스)과 `CrRendererMain`(렌더러 프로세스) 스레드의 활동을 추적하여, 현재 애플리케이션의 성능 병목이 GPU 바운드인지 CPU 바운드인지 시각적으로 파악할 수 있습니다 [6, 14, 15].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Graphics & Performance 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[Timestamp Queries]], [[Timing Attacks]], [[Chrome DevTools]]
-- **Projects/Contexts:** [[High Resolution Time Spec]], [[Chromium WebGPU Implementation]]
-- **Contradictions/Notes:** WebGPU 사양 원문에서는 타이밍 공격에 대한 우려로 인해 타임스탬프 쿼리를 선택적(optional) 기능으로 명시하고 신뢰할 수 있는 환경으로 노출을 제한할 수 있다고 규정했습니다 [4, 16]. 하지만, GPU for the Web 커뮤니티 그룹은 개발자의 성능 프로파일링 요구를 충족하면서도 보안을 유지하기 위해, 해상도를 100 마이크로초로 낮추는 조건 하에 사이트 격리(site isolation) 여부와 상관없이 타임스탬프 쿼리를 허용하기로 합의했습니다 [9, 10].
-
----
-*Last updated: 2026-04-19*
-- Raw Source: [[00_Raw/2026-04-20/WebGPU Performance Profiling.md]]
----
diff --git a/Graphics & Performance/WebGPU Timestamp Queries.md b/Graphics & Performance/WebGPU Timestamp Queries.md
deleted file mode 100644
index fd1cbb57..00000000
--- a/Graphics & Performance/WebGPU Timestamp Queries.md	
+++ /dev/null
@@ -1,30 +0,0 @@
----
-id: P-REINFORCE-AUTO-1F8BE6
-category: "[[10_Wiki/💡 Topics/Graphics & Performance]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - WebGPU Timestamp Queries"
----
-
-# [[WebGPU Timestamp Queries]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> WebGPU Timestamp Queries는 WebGPU 애플리케이션이 컴퓨트(Compute) 및 렌더(Render) 패스의 경계 등에서 GPU 명령이 실행되는 데 걸리는 시간을 나노초 단위까지 정밀하게 측정할 수 있도록 지원하는 API 기능입니다 [1, 2]. 고해상도 타이머를 악용한 캐시 사이드 채널 공격(예: Spectre)을 방지하기 위해 브라우저 환경에서는 일반적으로 해상도를 100마이크로초로 제한하는 타임스탬프 양자화(Timestamp Quantization)가 적용됩니다 [3, 4]. 한편, 루트 주제인 '브라우저 메모리 할당 시점별 미세 지연 측정 사례'와 관련하여, 타임스탬프 쿼리를 직접적으로 메모리 할당 시점과 연계하여 측정한 구체적인 사례는 소스에 관련 정보가 부족합니다.
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Graphics & Performance 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[Micro-latency]], [[Timestamp Quantization]], [[Timing Attacks (Spectre/Meltdown)]]
-- **Projects/Contexts:** [[WebGPU Performance Profiling]], [[Browser Security Mitigations]]
-- **Contradictions/Notes:** 소스 [5]에서는 보안을 위해 비격리 컨텍스트(Non-isolated contexts)에서 타임스탬프 쿼리 기능을 아예 노출하지 않는 방향을 주장하지만, 소스 [6]에서는 GPU for the Web Community Group의 추후 합의를 통해 사이트 격리 여부와 무관하게 100마이크로초 해상도로 기능을 항상 허용하는 것으로 변경되었음을 보여줍니다. 또한 루트 주제에서 요구한 '브라우저 메모리 할당 시점별' 구체적 지연 측정 사례에 대해서는 소스에 관련 정보가 부족합니다.
-
----
-*Last updated: 2026-04-19*
-- Raw Source: [[00_Raw/2026-04-20/WebGPU Timestamp Queries.md]]
----
diff --git a/Graphics & Performance/WebGPU _ WebGL Timing API Security.md b/Graphics & Performance/WebGPU _ WebGL Timing API Security.md
deleted file mode 100644
index 96883ddb..00000000
--- a/Graphics & Performance/WebGPU _ WebGL Timing API Security.md	
+++ /dev/null
@@ -1,33 +0,0 @@
----
-id: P-REINFORCE-AUTO-B3C1E7
-category: "[[10_Wiki/💡 Topics/Graphics & Performance]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - WebGPU _ WebGL Timing API Security"
----
-
-# [[WebGPU _ WebGL Timing API Security]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> WebGPU와 WebGL의 타이밍 API는 GPU 명령어의 실행 시간을 측정하는 도구이지만, 높은 정밀도의 타이밍 데이터가 보안 취약점으로 악용될 수 있어 엄격한 보안 모델이 적용됩니다 [1-3]. 과거 WebGL의 `EXT_disjoint_timer_query`와 같은 확장 기능은 캐시 적중률 및 메모리 접근 패턴을 노출시켜 Spectre, Meltdown, Rowhammer 등의 부채널 공격(Side-channel attack)에 악용되었습니다 [2, 4, 5]. 이에 대응하여 브라우저 벤더들은 고정밀 타이머를 비활성화하거나, 시간의 정밀도를 의도적으로 낮추는 '양자화(Quantization)' 기법을 도입하여 보안과 성능 분석 간의 균형을 맞추고 있습니다 [2, 6, 7].
-
-## 📖 구조화된 지식 (Synthesized Content)
-* **보안 위협의 배경:** WebGL에서 제공하던 `EXT_disjoint_timer_query` 등의 고정밀 타이머는 밀리초 미만의 정밀도로 GPU 실행 시간을 측정할 수 있었습니다 [1]. 하지만 보안 연구자들은 이러한 높은 해상도의 타이밍 데이터가 L1 캐시와 메인 메모리 간의 지연 시간 차이를 관찰하게 해준다는 사실을 발견했습니다 [8]. 이를 통해 캐시 부채널 공격을 수행하거나 물리적 메모리 구조를 파악하여 Rowhammer 공격 및 기기 지문 수집(Device Fingerprinting)에 악용될 수 있음이 밝혀졌습니다 [2, 4, 5].
-* **브라우저의 완화 조치 (Mitigations):** Spectre 및 Meltdown과 같은 보안 위협을 완화하기 위해 브라우저 엔진은 `performance.now()`의 타이머 정밀도를 1ms 또는 100 마이크로초 단위로 낮추고 측정값에 무작위 변동성(Jitter)을 도입했습니다 [9, 10]. 또한, 공격에 악용될 여지가 있는 `EXT_disjoint_timer_query` 확장을 브라우저 전반에서 비활성화하거나 사이트 격리(Site Isolation)가 적용된 특정 환경에서만 제한적으로 노출했습니다 [4, 11, 12]. 부가적으로 분기 처리를 통한 정보 유출을 막기 위해 인덱스 마스킹(Index Masking)과 포인터 포이즈닝(Pointer Poisoning)과 같은 분기 없는 보안 검사(Branchless security checks) 기법이 적용되었습니다 [13-16].
-* **WebGPU 타이밍 API 보안 모델:** WebGPU는 나노초 단위의 정밀도를 제공하는 `timestamp-query` 기능을 도입했지만, 타이밍 공격 우려로 인해 명세에서는 이를 신뢰할 수 있는 환경에만 노출할 수 있는 선택적(optional) 기능으로 정의했습니다 [2, 3]. 크롬(Chrome)을 비롯한 브라우저 엔진 및 GPU for the Web 커뮤니티 그룹은 보안과 상호 운용성을 확보하기 위해 '타임스탬프 양자화(Timestamp Quantization)'를 표준 방어 기법으로 채택했습니다 [3, 7, 17].
-* **타임스탬프 양자화(Timestamp Quantization) 적용:** 일반적인 웹 환경에서는 타이머 해상도를 100 마이크로초 단위로 낮추어(Coarsening) 타이밍 공격을 방지합니다 [6, 17]. 성능 프로파일링이 필수적인 개발자의 경우, 로컬 환경에서 전용 브라우저 플래그("WebGPU Developer Features" 및 "Unsafe WebGPU Support")를 명시적으로 활성화해야만 양자화가 해제된 나노초 단위의 정밀한 측정값을 얻을 수 있습니다 [6, 18].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Graphics & Performance 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[Spectre and Meltdown]], [[Cache Side-Channel Attack]], [[Timestamp Quantization]], [[Rowhammer Attack]]
-- **Projects/Contexts:** [[Chrome / Blink WebGPU Implementation]], [[WebKit Security Mitigations]]
-- **Contradictions/Notes:** 초기 WebGPU 보안 모델의 제안에서는 사이트 격리(Site Isolation) 여부에 따라 타임스탬프 노출 및 정밀도를 다르게 적용할 계획이었습니다(격리 컨텍스트에서는 100µs 해상도를 제공하고, 비격리 컨텍스트에서는 노출하지 않음) [3]. 그러나 브라우저 간 상호 운용성(Interop) 문제를 해결하기 위해, GPU for the Web 커뮤니티 그룹은 사이트 격리 여부와 무관하게 모든 상황에서 100 마이크로초(100µs) 해상도로 통일하여 허용하는 것으로 최종 합의를 변경했습니다 [17].
-
----
-*Last updated: 2026-04-19*
-- Raw Source: [[00_Raw/2026-04-20/WebGPU _ WebGL Timing API Security.md]]
----
diff --git a/Graphics & Performance/WebGPU 대규모 건설 뷰어.md b/Graphics & Performance/WebGPU 대규모 건설 뷰어.md
deleted file mode 100644
index 5cea4648..00000000
--- a/Graphics & Performance/WebGPU 대규모 건설 뷰어.md	
+++ /dev/null
@@ -1,35 +0,0 @@
----
-id: P-REINFORCE-AUTO-BF6C28
-category: "[[10_Wiki/💡 Topics/Graphics & Performance]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - WebGPU 대규모 건설 뷰어"
----
-
-# [[WebGPU 대규모 건설 뷰어]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> WebGPU 대규모 건설 뷰어는 WebGPU 기술을 활용하여 거대한 건축, 엔지니어링 및 건설 데이터(BIM 모델, LiDAR 포인트 클라우드 등)를 브라우저에서 실시간으로 렌더링하는 플랫폼입니다. 2026년 기준 500MB 미만의 모델이나 빠른 프로토타이핑에는 접근성이 높은 Three.js의 WebGPU가 주로 사용되며, 500MB를 초과하는 초대형 병원 캠퍼스, 공항 터미널 또는 복잡한 구조 시뮬레이션에는 강력한 제어력과 렌더 번들 기능을 갖춘 네이티브 WebGPU가 권장됩니다. 이 기술은 컴퓨트 셰이더 등을 통해 기존 WebGL 대비 드로우 콜 오버헤드를 획기적으로 줄이고 최대 100배 이상의 성능 향상을 제공합니다.
-
-## 📖 구조화된 지식 (Synthesized Content)
-* **Three.js 기반 WebGPU 뷰어 (500MB 이하 모델):**
-  Three.js(r171 이상)의 `WebGPURenderer`는 대규모 건설 플랫폼 개발을 간소화합니다. TSL(Three Shader Language)을 통해 콘크리트, 반사 유리, 강철 마감 등 건축용 맞춤형 재질을 단일 코드베이스로 구현할 수 있습니다. 반복적인 요소(빔, 기둥, 볼트 등)가 많은 건축 모델의 경우 `InstancedMesh` 또는 `BatchedMesh`를 활용하여 드로우 콜을 90% 이상 줄일 수 있어 성능 확보에 유리합니다.
-* **네이티브 WebGPU (500MB 초과 대규모 워크로드):**
-  500MB가 넘는 거대한 BIM 모델이나 실시간 구조 응력 시뮬레이션을 다루는 경우, 네이티브 WebGPU의 저수준 제어가 필수적입니다. 스토리지 버퍼를 사용하여 수십만 개의 개별 객체 변환 행렬을 단일 버퍼로 압축하고, `GPURenderBundles` 및 간접 그리기(`drawIndexedIndirect`)를 통해 최대 100,000개 이상의 객체를 CPU-GPU 동기화 지연 없이 단일 호출로 효율적으로 렌더링합니다.
-* **컴퓨트 셰이더를 활용한 대규모 데이터 처리:**
-  충돌 감지, 현장 분석, 대규모 BIM 데이터의 실시간 필터링 등 연산 집약적인 작업을 자바스크립트 메인 스레드에서 GPU로 오프로드합니다. 컴퓨트 셰이더를 통해 수백만 개의 점으로 이루어진 LiDAR 포인트 클라우드나 파티클 시스템을 렌더링할 때 CPU 연산 대비 100배~150배의 획기적인 속도 향상을 달성할 수 있습니다.
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Graphics & Performance 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[Three.js WebGPU]], [[Native WebGPU]], [[BIM (Building Information Modeling)]], [[LiDAR Point Cloud]], [[Compute Shaders]], [[GPURenderBundles]]
-- **Projects/Contexts:** [[Segments.ai]] (LiDAR 포인트 클라우드 레이블링 도구를 WebGPU로 전환하여 100배 성능 향상), [[Expo 2025 Osaka]] ("Waves of Connection" 설치물에서 4K 디스플레이에 100만 개 파티클을 지연 없이 실시간 렌더링)
-- **Contradictions/Notes:** Three.js의 WebGPU는 추상화 레이어를 통해 빠르고 쉬운 뷰어 개발을 가능하게 하지만, 고유한 객체가 10,000~20,000개를 초과할 경우 UBO(Uniform Buffer Object) 바인딩 오버헤드로 인해 프레임 저하(예: 15 FPS)가 발생할 수 있습니다. 반면 네이티브 WebGPU는 막대한 데이터도 원활하게 처리할 수 있으나, 파이프라인 및 셰이더에 대한 깊은 지식이 요구되어 개발 속도가 상대적으로 느립니다.
-
----
-*Last updated: 2026-04-19*
-- Raw Source: [[00_Raw/2026-04-20/WebGPU 대규모 건설 뷰어.md]]
----
diff --git a/Graphics & Performance/WebGPU.md b/Graphics & Performance/WebGPU.md
deleted file mode 100644
index bddae76f..00000000
--- a/Graphics & Performance/WebGPU.md	
+++ /dev/null
@@ -1,37 +0,0 @@
----
-id: P-REINFORCE-AUTO-C06372
-category: "[[10_Wiki/💡 Topics/Graphics & Performance]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - WebGPU"
----
-
-# [[WebGPU]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> WebGPU는 웹 브라우저 환경에서 고성능 3D 그래픽 및 연산을 처리하기 위해 설계된 차세대 그래픽 API이다 [1]. 기존 WebGL의 한계를 극복하고 컴퓨트 셰이더(Compute Shaders), 직접적인 메모리 관리, 멀티스레딩 등 최신 하드웨어 기능을 웹에서 사용할 수 있게 해준다 [2, 3]. Three.js와 같은 라이브러리를 통해 쉽게 도입할 수 있으며, 특히 드로우 콜(Draw Call)이 집중된 씬이나 대규모 물리 연산에서 기존 WebGL 대비 비약적인 성능 향상을 제공한다 [4-6].
-
-## 📖 구조화된 지식 (Synthesized Content)
-*   **브라우저 지원 및 Three.js 도입:** 
-    WebGPU는 Chrome, Edge, Firefox, Safari(v26, 2025년 9월 이후) 등 모든 주요 브라우저에서 지원되어 상용화 준비를 마쳤다 [7]. Three.js 환경에서는 r171 버전부터 별도의 복잡한 설정 없이 `WebGPURenderer`를 비동기로 초기화하여 손쉽게 사용할 수 있으며, WebGPU를 지원하지 않는 기기에서는 자동으로 WebGL 2로 대체(Fallback)되는 기능을 제공한다 [2, 8, 9].
-*   **성능 향상과 컴퓨트 셰이더(Compute Shaders):** 
-    WebGPU는 드로우 콜이 많은 환경과 입자(Particle) 및 물리 시뮬레이션 같은 연산 집약적인 작업에서 2~10배의 성능 향상을 보여준다 [4]. 기존 CPU 기반 시스템에서는 약 5만 개의 파티클에서 병목 현상이 발생했으나, WebGPU의 컴퓨트 셰이더를 활용하면 수백만 개의 파티클을 오프스레드로 처리할 수 있다 [10, 11]. 연산 스레드 간 데이터 공유를 위한 작업 그룹 공유 메모리를 제공하며, 절차적 지형 생성 및 실시간 유체 시뮬레이션에 탁월하다 [12, 13].
-*   **바인딩 모델 및 데이터 전송 최적화:** 
-    WebGL의 개별 바인딩 방식과 달리, WebGPU는 리소스를 '바인드 그룹(Bind Groups)' 단위로 일괄 처리하여 드로우 콜 간의 상태 전환 오버헤드를 최소화한다 [14]. 또한 `instancedArray`를 사용하여 프레임 간 유지되는 GPU 버퍼를 생성함으로써 CPU-GPU 간 데이터 전송 병목을 제거하고, 읽기 및 쓰기가 동시에 가능한 스토리지 텍스처(Storage Textures)를 지원한다 [10, 14, 15].
-*   **Native WebGPU vs Three.js WebGPU:** 
-    500MB 이상의 대형 건설 뷰어나 BIM 모델 같은 방대한 데이터셋을 다룰 때는 Three.js의 추상화 계층을 거치지 않는 Native WebGPU가 필수적일 수 있다 [16]. Native WebGPU는 `GPURenderBundles`를 통해 10만 개 이상의 객체를 효율적으로 단일 호출로 재생할 수 있으며, 간접 그리기(`drawIndexedIndirect`)를 사용하여 CPU-GPU 동기화 지연을 완전히 제거하는 등 훨씬 정밀한 메모리 관리와 파이프라인 제어를 가능하게 한다 [3, 17, 18].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Graphics & Performance 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[WebGL]], [[Compute Shaders]], [[Three Shader Language (TSL)]], [[GPURenderBundles]], [[Draw Call]]
-- **Projects/Contexts:** [[Three.js]], [[Segments.ai]], [[Expo 2025 Osaka]]
-- **Contradictions/Notes:** Three.js의 WebGPU 렌더러는 개발 속도를 비약적으로 높여주고 사용이 쉽지만, 수만 개의 고유 객체를 처리할 때 발생하는 UBO(Uniform Buffer Object) 바인딩 오버헤드와 메타데이터 메모리 소비로 인해 초대규모 데이터셋(500MB 이상)에서는 Native WebGPU 성능에 미치지 못한다는 벤치마크 결과가 있다 [18-21].
-
----
-*Last updated: 2026-04-19*
-- Raw Source: [[00_Raw/2026-04-20/WebGPU.md]]
----
diff --git a/Graphics & Performance/Winning Ways for your Mathematical Plays.md b/Graphics & Performance/Winning Ways for your Mathematical Plays.md
deleted file mode 100644
index c33aa248..00000000
--- a/Graphics & Performance/Winning Ways for your Mathematical Plays.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-A3A3FC
-category: "[[10_Wiki/💡 Topics/Graphics & Performance]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Winning Ways for your Mathematical Plays"
----
-
-# [[Winning Ways for your Mathematical Plays]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Graphics & Performance 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Winning Ways for your Mathematical Plays.md]]
----
diff --git a/Graphics & Performance/Wonderland Engine.md b/Graphics & Performance/Wonderland Engine.md
deleted file mode 100644
index 5eb9c9d4..00000000
--- a/Graphics & Performance/Wonderland Engine.md	
+++ /dev/null
@@ -1,33 +0,0 @@
----
-id: P-REINFORCE-AUTO-F85BEF
-category: "[[10_Wiki/💡 Topics/Graphics & Performance]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Wonderland Engine"
----
-
-# [[Wonderland Engine]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> Wonderland Engine(원더랜드 엔진)은 웹 환경을 위한 차세대 고성능 3D 엔진입니다 [1]. 이 엔진은 프로덕션 수준의 성능으로 제품 구성기, 시각화 및 대화형 3D 경험을 구축할 수 있도록 설계되었습니다 [1]. WebGL 성능 최적화 원칙을 극한으로 적용하여, 개발자가 성능 병목 현상을 고민하지 않고 프로젝트 자체에만 집중할 수 있는 환경을 제공합니다 [2].
-
-## 📖 구조화된 지식 (Synthesized Content)
-- **극단적인 배칭(Batching)을 통한 드로우 콜 최적화:** WebGL 성능 저하의 주된 원인 중 하나인 드로우 콜(Draw call)을 줄이기 위해 Wonderland Engine은 여러 호출을 하나로 병합하는 배칭 기능을 극단적인 수준으로 활용합니다 [3, 4]. 이를 통해 수만 개의 동적 객체가 포함된 씬(Scene)도 자동으로 10번 미만의 드로우 콜만 사용하여 렌더링할 수 있습니다 [4].
-- **포괄적인 WebXR 지원:** WebXR 기술을 기반으로 AR(증강현실, Zappar 지원), VR(가상현실) 및 혼합 현실(Mixed Reality) 애플리케이션 개발을 강력하게 지원합니다 [5].
-- **개발 도구 및 기능:** 자체적인 Wonderland Editor와 CLI, 컴포넌트 레지스트리 등을 제공하며, Prefab, GLTF/GLB 모델 로딩, 커스텀 셰이더 작성 등 3D 그래픽 작업에 필요한 다양한 리소스를 다룰 수 있습니다 [5, 6]. JavaScript 및 TypeScript를 활용하여 컴포넌트를 작성할 수 있으며, Unity 환경에서 Wonderland로 작업물을 가져올 수 있는 기능(Unity to Wonderland)도 지원합니다 [5, 6].
-- **안정적인 렌더링 환경 제공:** 가비지 컬렉션(Garbage Collection)으로 인한 예기치 않은 렌더링 끊김 현상을 방지하고, 안정적인 프레임률(Framerate)을 보장하기 위해 브라우저 오버헤드를 피하는 최적화 기술이 엔진 내부에 엄격하게 적용되어 있습니다 [2, 7, 8].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Graphics & Performance 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[WebGL]], [[WebXR]], [[Draw Calls]], [[Batching]]
-- **Projects/Contexts:** [[Interactive 3D Experiences]]
-- **Contradictions/Notes:** 소스에 모순되는 내용은 없으나, WebGL이 복잡한 3D 그래픽을 렌더링하기에 느리다는 개발자들의 일반적인 오해와 달리, Wonderland Engine은 극한의 엔진 최적화(드로우 콜 최소화 등)를 통해 웹에서도 압도적인 3D 렌더링 성능을 낼 수 있음을 보여줍니다 [4, 9].
-
----
-*Last updated: 2026-04-19*
-- Raw Source: [[00_Raw/2026-04-20/Wonderland Engine.md]]
----
diff --git a/Graphics & Performance/XState-Library.md b/Graphics & Performance/XState-Library.md
deleted file mode 100644
index 620aa913..00000000
--- a/Graphics & Performance/XState-Library.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-7C6A30
-category: "[[10_Wiki/💡 Topics/Graphics & Performance]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - XState-Library"
----
-
-# [[XState-Library]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Graphics & Performance 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/XState-Library.md]]
----
diff --git a/Graphics & Performance/instancedArray.md b/Graphics & Performance/instancedArray.md
deleted file mode 100644
index 3e697e68..00000000
--- a/Graphics & Performance/instancedArray.md	
+++ /dev/null
@@ -1,33 +0,0 @@
----
-id: P-REINFORCE-AUTO-FF8159
-category: "[[10_Wiki/💡 Topics/Graphics & Performance]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - instancedArray"
----
-
-# [[instancedArray]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> `instancedArray`는 렌더링 프레임 간에도 유지되는 영구적인 GPU 버퍼(GPU-persistent buffers)를 생성하는 기능입니다 [1]. 이 기능을 활용하면 기존 파티클 시스템 등에서 성능 저하의 주원인으로 꼽히는 CPU와 GPU 간의 데이터 전송을 제거할 수 있습니다 [1]. 특히 매 프레임마다 업데이트되는 파티클 데이터에 적용하여, 비용이 많이 드는 WebGPU 버퍼 쓰기 작업을 최소화하는 데 핵심적인 역할을 합니다 [2].
-
-## 📖 구조화된 지식 (Synthesized Content)
-- **GPU 영구 버퍼의 생성:** `instancedArray`는 프레임이 넘어가더라도 데이터가 유지되는 영구적인 GPU 버퍼를 만듭니다 [1].
-- **CPU-GPU 데이터 전송 병목 해소:** 전통적인 파티클 시스템에서는 상태 변화를 매 프레임 CPU에서 계산하여 GPU로 넘겨주어야 했으며, 이는 심각한 성능 저하를 일으킵니다. `instancedArray`는 이러한 반복적인 데이터 전송(CPU-GPU data transfer) 과정을 완전히 제거하여 성능을 대폭 향상시킵니다 [1].
-- **WebGPU 버퍼 업데이트 최소화:** WebGPU 환경에서는 버퍼 쓰기(buffer writes) 비용이 매우 높습니다. 따라서 프레임마다 다수의 작은 버퍼를 지속적으로 업데이트하는 대신, 매 프레임 변경이 필요한 파티클 데이터 관리에 `instancedArray`를 사용하는 것이 권장됩니다 [2].
-- **TSL(Three Shader Language) 지원:** `instancedArray`는 Three.js의 새로운 노드 기반 셰이더 시스템인 TSL(Three Shader Language)에서 지원하는 주요 기능 중 하나로 활용됩니다 [3].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Graphics & Performance 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[WebGPU]], [[TSL]], [[Particle Systems]]
-- **Projects/Contexts:** [[Three.js 성능 최적화 (Utsubo의 2026 가이드)]]
-- **Contradictions/Notes:** 소스 내에 이 주제와 관련하여 상충하는 주장이나 반대 의견은 존재하지 않습니다.
-
----
-*Last updated: 2026-04-19*
-- Raw Source: [[00_Raw/2026-04-20/instancedArray.md]]
----
diff --git a/Graphics & Performance/three-mesh-bvh.md b/Graphics & Performance/three-mesh-bvh.md
deleted file mode 100644
index 03f0e467..00000000
--- a/Graphics & Performance/three-mesh-bvh.md	
+++ /dev/null
@@ -1,33 +0,0 @@
----
-id: P-REINFORCE-AUTO-150C10
-category: "[[10_Wiki/💡 Topics/Graphics & Performance]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - three-mesh-bvh"
----
-
-# [[three-mesh-bvh]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> three-mesh-bvh는 Three.js 메시에 대한 광선 투사(Raycasting) 속도를 높이고 공간 쿼리를 가능하게 하는 BVH(Bounding Volume Hierarchy) 구현 라이브러리입니다 [1]. 초당 60프레임(60fps) 환경에서 8만 개 이상의 다각형(polygon)에 대한 빠른 광선 투사를 지원합니다 [2]. 복잡한 기하학적 구조를 가진 대화형 3D 씬(scene)의 상호작용 성능을 최적화하는 데 필수적인 도구로 활용됩니다 [2].
-
-## 📖 구조화된 지식 (Synthesized Content)
-- **핵심 성능 및 역할:** three-mesh-bvh는 Three.js 애플리케이션에서 광선 투사 연산을 효과적으로 가속화합니다 [1]. 수많은 폴리곤이 있는 복잡한 씬에서도 60fps를 유지하면서 정밀한 인터랙션 및 충돌 감지를 수행할 수 있도록 돕습니다 [2].
-- **InstancedMesh와의 호환성:** 이 라이브러리는 `InstancedMesh` 환경에서도 활용될 수 있습니다 [3]. 기하학적 구조(geometry)에 대한 경계 트리(bounds tree)를 생성하면, 인스턴스화된 메시에 속한 개별 지오메트리 단위로 BVH 기반 광선 투사를 수행할 수 있습니다 [3], [4]. 다만, 인스턴스화된 객체 세트(set of instanced objects) 전체를 대상으로 기본 작동하는 것은 아닙니다 [3].
-- **API 변경 사항:** 라이브러리의 버전이 업데이트됨에 따라 기존에 사용되던 시각화 도구인 `MeshBVHVisualizer`는 더 이상 사용되지 않습니다(deprecated) [4]. 따라서 최신 버전에서는 `MeshBVHHelper` 문서를 참조하여 사용해야 합니다 [4].
-- **생태계 내 영향력:** Three.js 기반 애플리케이션의 성능 병목을 해결하고 디버깅을 돕는 주요 도구 중 하나로 평가받고 있습니다 [5]. 또한, 널리 쓰이는 외부 확장 라이브러리인 InstancedMesh2가 자체적인 BVH 기반 빠른 광선 투사 기능을 구현하는 데 핵심적인 영감을 제공하기도 했습니다 [6].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Graphics & Performance 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[Raycasting]], [[InstancedMesh]], [[Bounding Volume Hierarchy (BVH)]]
-- **Projects/Contexts:** [[Three.js Performance Optimization]], [[InstancedMesh2]]
-- **Contradictions/Notes:** 소스에 따르면 구버전에서 사용되던 시각화 클래스인 `MeshBVHVisualizer`는 현재 지원이 중단(deprecated)되었으므로, 사용자는 `MeshBVHHelper`로 교체하여 사용해야 합니다 [4].
-
----
-*Last updated: 2026-04-19*
-- Raw Source: [[00_Raw/2026-04-20/three-mesh-bvh.md]]
----
diff --git a/Graphics & Performance/threejs Issue _30352.md b/Graphics & Performance/threejs Issue _30352.md
deleted file mode 100644
index d1c6088e..00000000
--- a/Graphics & Performance/threejs Issue _30352.md	
+++ /dev/null
@@ -1,30 +0,0 @@
----
-id: P-REINFORCE-AUTO-AE68EC
-category: "[[10_Wiki/💡 Topics/Graphics & Performance]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - threejs Issue _30352"
----
-
-# [[threejs Issue _30352]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> three.js Issue #30352는 공유 속성을 가진 여러 개의 일반 `Mesh` 객체를 렌더링할 때보다 `InstancedMesh`를 사용할 때 성능이 오히려 크게 저하되는 현상을 보고한 이슈입니다 [1, 2]. 이 현상의 주요 원인은 `InstancedMesh`가 내부 인스턴스들을 렌더링할 때 앞뒤로 자동 정렬(Sorting)하지 않아 발생하는 막대한 오버드로우(Overdraw) 비용 때문입니다 [3, 4]. 즉, 단일 드로우 콜로 인한 CPU 연산 감소 이득보다 불필요한 픽셀 처리 부하가 더 커지면서 씬이 프래그먼트 바운드(Fragment-bound) 상태에 빠지는 구조적 한계를 보여주는 사례입니다 [5].
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Graphics & Performance 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[InstancedMesh]], [[Overdraw]], [[BatchedMesh]], [[Fragment-bound]]
-- **Projects/Contexts:** [[three.js]]
-- **Contradictions/Notes:** 이론적으로 `InstancedMesh`는 드로우 콜 횟수를 1회로 줄여주어 렌더링 성능을 향상시켜야 하지만, 이슈 #30352의 사례에서는 개별 정렬 부재로 인한 오버드로우 비용 때문에 오히려 개별 드로우 콜(5,000회)을 수행하는 일반 `Mesh` 방식보다 성능이 떨어지는 모순적인 결과를 보여줍니다 [1, 2, 5]. 
-
----
-*Last updated: 2026-04-19*
-- Raw Source: [[00_Raw/2026-04-20/three.js Issue _30352.md]]
----
diff --git a/Graphics & Performance/가상현실(VR).md b/Graphics & Performance/가상현실(VR).md
deleted file mode 100644
index 72d10585..00000000
--- a/Graphics & Performance/가상현실(VR).md	
+++ /dev/null
@@ -1,33 +0,0 @@
----
-id: P-REINFORCE-AUTO-13DD7A
-category: "[[10_Wiki/💡 Topics/Graphics & Performance]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - 가상현실(VR)"
----
-
-# [[가상현실(VR)]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 가상현실(VR)은 헤드마운트 디스플레이(HMD)와 신체 추적 기술 등을 통해 사용자가 가상 세계에 실제로 존재하는 것처럼 느끼게 하는 컴퓨터 생성 3D 환경입니다 [1-3]. 이 기술은 교육, 의료, 게임, 군사 훈련 등 다양한 분야에서 몰입형 상호작용과 시뮬레이션을 제공하는 데 활용됩니다 [3, 4]. 하지만 감각 정보의 불일치로 인한 VR 멀미(VR Sickness)와 복잡한 인터페이스로 인한 높은 인지 부하(Cognitive Load) 등의 부작용이 사용자 경험을 저해하는 주요 과제로 남아 있습니다 [5-7].
-
-## 📖 구조화된 지식 (Synthesized Content)
-- **가상현실의 정의 및 현존감(Presence):** VR은 사실적인 3D 환경, 360도 공간, 그리고 신체 추적 기술을 결합하여 사용자가 물리적 현실이 아닌 가상 세계에 있다는 심리적 상태인 '현존감'을 유도합니다 [1, 2]. 이를 통해 기존 평면 미디어로는 불가능했던 깊은 수준의 디지털 상호작용을 가능하게 합니다 [4].
-- **교육 및 정서적 활용 효과:** 교육 환경에서 VR은 가상 교실, 실험실, 역할극 등을 제공하여 추상적인 개념의 이해를 돕고 학습 참여도를 높입니다 [3]. 또한 긍정적인 감정을 유발하여 불안과 스트레스를 감소시키며, 학습자의 심리적 회복탄력성(Resilience)과 몰입(Flow) 상태를 강화하는 데 효과적인 도구로 활용됩니다 [8-10]. 신체 활동을 동반하는 엑서게임(Exergame) 환경에서는 VR이 육체적 피로에 대한 주의를 분산시키고 지속적인 운동 동기를 부여합니다 [2].
-- **인지 부하(Cognitive Load)와 충실도 패러독스(Fidelity Paradox):** VR 환경에서의 상호작용은 시각, 청각, 촉각 등 다량의 감각 정보를 동시에 처리해야 하므로 사용자의 작업 기억에 높은 인지 부하를 발생시킬 수 있습니다 [11, 12]. 특히, 현실감을 극대화하기 위해 설계된 고충실도 햅틱 장갑(Haptic Glove)과 같은 인터페이스는 기기의 무게, 트래킹 오류, 물리적 저항 등으로 인해 오히려 기기 조작에 주의를 빼앗기게 만들어 인지적 마찰을 증가시키고 사용성을 떨어뜨리는 '충실도 패러독스(Fidelity Paradox)'를 유발합니다 [13-15].
-- **VR 멀미(VR Sickness) 및 감각적 충돌:** HMD를 사용하는 많은 VR 사용자는 메스꺼움, 방향 감각 상실, 시각적 피로 등의 멀미 증상을 겪습니다 [6]. 이는 사용자가 보는 시각적 움직임과 신체의 전정 감각 간의 불일치, 그리고 디스플레이 내에서의 폭주-조절 불일치(Vergence-accommodation conflict)에 의해 발생합니다 [7]. 노출 시간이 길어질수록 멀미 증상이 심해지는 경향이 있으며, VR 사용을 종료한 후에도 증상이 사라지기까지 일정 시간의 회복기가 필요합니다 [16-18].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Graphics & Performance 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[현존감(Presence)]], [[인지 부하(Cognitive Load)]], [[VR 멀미(VR Sickness)]], [[몰입(Flow State)]]
-- **Projects/Contexts:** [[교육용 몰입형 시뮬레이션(Educational Immersive Simulations)]], [[기능성 게임(Serious Games)]], [[엑서게임(Exergaming)]]
-- **Contradictions/Notes:** 일반적으로 가상현실 인터페이스가 실제 현실의 감각(Fidelity)을 완벽하게 재현할수록 사용자 몰입과 성과가 향상될 것이라 가정하지만, 연구 결과에 따르면 장비의 기술적 복잡성과 물리적 제약이 오히려 사용자의 주의를 분산시켜 인지적 과부하를 초래하는 '충실도 패러독스(Fidelity Paradox)'가 존재함이 확인되었습니다 [13, 14, 19, 20].
-
----
-*Last updated: 2026-04-19*
-- Raw Source: [[00_Raw/2026-04-20/가상현실(VR).md]]
----
diff --git a/Graphics & Performance/고성능 3D WebGL 게임 렌더링 엔진.md b/Graphics & Performance/고성능 3D WebGL 게임 렌더링 엔진.md
deleted file mode 100644
index fd85a31e..00000000
--- a/Graphics & Performance/고성능 3D WebGL 게임 렌더링 엔진.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-BD05D2
-category: "[[10_Wiki/💡 Topics/Graphics & Performance]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - 고성능 3D WebGL 게임 렌더링 엔진"
----
-
-# [[고성능 3D WebGL 게임 렌더링 엔진]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Graphics & Performance 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/고성능 3D WebGL 게임 렌더링 엔진.md]]
----
diff --git a/Graphics & Performance/고성능 멀티스레드 React 앱 아키텍처.md b/Graphics & Performance/고성능 멀티스레드 React 앱 아키텍처.md
deleted file mode 100644
index cf926c8d..00000000
--- a/Graphics & Performance/고성능 멀티스레드 React 앱 아키텍처.md	
+++ /dev/null
@@ -1,42 +0,0 @@
----
-id: P-REINFORCE-AUTO-87DB97
-category: "[[10_Wiki/💡 Topics/Graphics & Performance]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - 고성능 멀티스레드 React 앱 아키텍처"
----
-
-# [[고성능 멀티스레드 React 앱 아키텍처]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 자바스크립트의 단일 스레드(Single-thread) 제약을 극복하기 위해 웹 워커(Web Worker)와 OffscreenCanvas를 활용하여 무거운 CPU 연산이나 3D 그래픽 렌더링을 백그라운드로 분리하고, 메인 스레드와 고효율로 상태를 동기화하여 초당 60프레임(FPS)의 매끄러운 반응성을 보장하는 진보된 애플리케이션 설계 패턴입니다.
-
-## 📖 구조화된 지식 (Synthesized Content)
-**1. 멀티스레딩의 필요성과 Web Worker 분리** 자바스크립트는 기본적으로 단일 스레드 환경이므로 대규모 데이터 정렬, 이미지/비디오 처리, 물리 연산 등 무거운 작업을 수행하면 메인 스레드가 블로킹되어 UI가 멈추는 현상(Freezing)이 발생합니다. 이를 방지하기 위해 무거운 연산을 웹 워커(Web Worker)로 오프로딩(Offloading)하면, UI 상호작용은 메인 스레드에서 방해 없이 60FPS로 처리하고 연산은 백그라운드 스레드에서 병렬로 진행할 수 있습니다. React 앱에서는 `@koale/useworker`와 같은 훅 기반 라이브러리를 통해 워커 설정을 단순화하여 활용할 수 있습니다.
-
-**2. OffscreenCanvas와 WebGL/R3F 렌더링 분리** 복잡한 3D 씬을 다루는 WebGL 애플리케이션의 경우 렌더링 자체가 메인 스레드를 크게 소모합니다. `@react-three/offscreen` 라이브러리나 네이티브 API를 사용하면 캔버스의 제어권을 `OffscreenCanvas`로 넘겨 웹 워커 환경에서 React Three Fiber(R3F) 혹은 Three.js를 실행할 수 있습니다. 이 구조에서는 렌더링과 DOM 조작이 물리적으로 분리되어 서로의 성능에 영향을 주지 않습니다.
-
-**3. 대리 인터랙션(Event Forwarding) 시스템** 웹 워커 내부에는 DOM이나 `window` 객체가 존재하지 않으므로 사용자의 마우스 클릭, 터치 등의 이벤트를 직접 수신할 수 없습니다. 따라서 메인 스레드에서 이벤트를 캡처한 뒤, 포인터 좌표 등의 필수 데이터만 워커로 전달(postMessage)하여 워커 내부에서 상호작용을 처리하도록 하는 이벤트 포워딩 파이프라인 구축이 필수적입니다.
-
-**4. 고효율 상태 동기화 (State Synchronization)** 메인 스레드(React DOM UI)와 워커(WebGL 씬 또는 연산 로직) 양쪽에서 동일한 앱 상태를 읽고 써야 하는 경우, 스레드 간 상태 동기화가 가장 큰 과제가 됩니다.
-
-- **프록시 및 델타 동기화:** Valtio와 같은 프록시 기반 상태 관리 도구를 사용하여 로컬 저장소를 구축한 뒤, 상태가 변할 때마다 변경된 작업 내용(Operations/Delta)만 Broadcast Channel API를 통해 상대 스레드에 전달하여 동기화합니다.
-- **SharedArrayBuffer:** 엔티티 컴포넌트 시스템(ECS) 기반의 게임이나 지연 시간이 극도로 낮아야 하는 환경에서는 스레드 간 메모리를 직접 공유하는 `SharedArrayBuffer`를 사용하여 직렬화(Serialization)/복사 비용 없이 원자적(Atomic) 연산을 수행합니다.
-
-**5. 서드파티 스크립트 오프로딩 (Partytown)** 애널리틱스, 광고, 챗봇 등 외부 서드파티 스크립트는 통제할 수 없는 메인 스레드 블로킹의 주요 원인입니다. `Partytown`과 같은 도구를 도입하면 이러한 서드파티 스크립트의 실행을 웹 워커로 옮겨 메인 스레드 부하를 원천적으로 차단할 수 있습니다.
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Graphics & Performance 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[Web Worker (웹 워커)]], [[OffscreenCanvas]], [[SharedArrayBuffer]], [[Valtio (Proxy State 관리)]], [[Event Forwarding (이벤트 포워딩)]]
-- **Projects/Contexts:** [[대규모 데이터 분석 및 시각화 대시보드]], [[고성능 실시간 WebGL 게임 엔진]], [[서드파티 스크립트가 많은 엔터프라이즈 앱 성능 개선]]
-- **Contradictions/Notes:** 멀티스레딩이 무조건적인 성능 향상을 가져오지는 않습니다. 스레드 간에 메시지를 주고받는 과정(Message passing)에는 직렬화로 인한 오버헤드(약 5~10ms)가 수반됩니다. 연산 시간이 50ms 미만인 비교적 가벼운 작업을 워커로 분리하면 오히려 통신 비용이 연산 시간보다 커져 성능이 하락할 수 있으므로 철저한 프로파일링을 기반으로 병목 구간에만 선택적으로 적용해야 합니다.
-
----
-
-_Last updated: 2026-04-15_
-- Raw Source: [[00_Raw/2026-04-20/고성능 멀티스레드 React 앱 아키텍처.md]]
----
diff --git a/Graphics & Performance/교육 심리학 및 교수법 설계.md b/Graphics & Performance/교육 심리학 및 교수법 설계.md
deleted file mode 100644
index 724f12b2..00000000
--- a/Graphics & Performance/교육 심리학 및 교수법 설계.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-5D01FE
-category: "[[10_Wiki/💡 Topics/Graphics & Performance]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - 교육 심리학 및 교수법 설계"
----
-
-# [[교육 심리학 및 교수법 설계]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Graphics & Performance 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/교육 심리학 및 교수법 설계.md]]
----
diff --git a/Graphics & Performance/기업 문화 진단 및 개선.md b/Graphics & Performance/기업 문화 진단 및 개선.md
deleted file mode 100644
index eb764fd7..00000000
--- a/Graphics & Performance/기업 문화 진단 및 개선.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-7FF20D
-category: "[[10_Wiki/💡 Topics/Graphics & Performance]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - 기업 문화 진단 및 개선"
----
-
-# [[기업 문화 진단 및 개선]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Graphics & Performance 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/기업 문화 진단 및 개선.md]]
----
diff --git a/Graphics & Performance/대규모 3D 건축 모델(BIM) 시각화.md b/Graphics & Performance/대규모 3D 건축 모델(BIM) 시각화.md
deleted file mode 100644
index d88b07f7..00000000
--- a/Graphics & Performance/대규모 3D 건축 모델(BIM) 시각화.md	
+++ /dev/null
@@ -1,33 +0,0 @@
----
-id: P-REINFORCE-AUTO-750154
-category: "[[10_Wiki/💡 Topics/Graphics & Performance]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - 대규모 3D 건축 모델(BIM) 시각화"
----
-
-# [[대규모 3D 건축 모델(BIM) 시각화]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 대규모 3D 건축 모델(BIM) 시각화는 수십만에서 수백만 개의 개별 컴포넌트로 구성된 복잡한 건축 및 산업 환경을 웹 브라우저 등에서 실시간으로 렌더링하는 기술을 의미합니다 [1-3]. 이를 원활하게 처리하기 위해서는 드로우 콜(Draw Call) 병목 현상과 메모리 한계를 극복해야 하며, 객체의 고유성 여부에 따라 형상 병합(Batching)과 인스턴싱(Instancing)을 혼합하는 하이브리드 최적화 및 WebGPU의 컴퓨트 셰이더와 같은 최신 그래픽 API 기술이 필수적으로 요구됩니다 [4-7].
-
-## 📖 구조화된 지식 (Synthesized Content)
-- **드로우 콜 병목과 기하학적 데이터의 한계:** BIM 및 CAD 모델은 벽, 바닥, 배관, 창문 등 수많은 개별 부품으로 구성되며, 이를 개별 메쉬(Mesh)로 렌더링할 경우 막대한 드로우 콜 오버헤드가 발생하여 CPU가 GPU의 처리 속도를 따라가지 못하는 병목 현상이 발생합니다 [2, 8, 9]. 또한, CAD 데이터는 매우 큰 좌표계를 사용하는 경우가 많아 32비트 부동소수점 환경에서 렌더링 시 정점 스내핑(Vertex snapping)이나 떨림(Jitter) 현상이 발생할 수 있으므로, GPU 업로드 전 기하학적 경계 상자의 중심을 기준으로 좌표계를 재조정(Origin-shifting)하는 정밀도 관리가 필요합니다 [10, 11].
-- **BatchedMesh와 InstancedMesh를 활용한 최적화:** 방대한 환경을 시각화할 때는 객체의 특성에 맞춰 렌더링을 최적화해야 합니다. 문이나 가구, 패스너(Fastener)처럼 동일한 형상과 재질이 반복되는 고폴리곤 객체에는 `InstancedMesh`를 사용하여 드로우 콜과 메모리 사용량을 최소화하는 것이 적합합니다 [1, 4, 6]. 반면, 콘크리트 벽이나 배관처럼 동일한 재질을 공유하지만 기하학적 형태가 모두 다른 고유 객체들의 경우 `InstancedMesh` 적용이 불가능하므로, 여러 지오메트리를 하나의 드로우 콜로 묶으면서도 개별 객체의 가시성과 변환을 제어할 수 있는 `BatchedMesh`나 `BufferGeometry` 병합 방식이 효과적입니다 [4, 6-8]. IFC.js의 'Fragment' 아키텍처는 이러한 두 방식을 혼합하여 저폴리곤 고유 객체는 병합하고 고폴리곤 반복 객체는 인스턴싱하는 하이브리드 접근법을 사용합니다 [4, 12, 13].
-- **WebGPU 및 컴퓨트 셰이더(Compute Shader)의 도입:** 차세대 그래픽 API인 WebGPU는 대규모 BIM 데이터세트를 다루는 데 있어 획기적인 성능 향상을 제공합니다 [5, 14]. 컴퓨트 셰이더를 활용하면 충돌 감지, 실시간 필터링, 물리 시뮬레이션 등 CPU에서 병목을 일으키는 무거운 작업들을 수천 개의 GPU 코어에서 병렬로 처리할 수 있습니다 [5, 14, 15]. 또한, 네이티브 WebGPU의 렌더 번들(`GPURenderBundles`) 및 간접 그리기(`drawIndexedIndirect`) 기능을 통해 수십만 개의 객체를 효율적으로 렌더링하여 CPU-GPU 동기화 지연을 제거할 수 있습니다 [16, 17].
-- **가시성 판별 및 메모리 관리:** 방대한 환경에서는 화면에 보이지 않는 객체를 렌더링에서 제외하기 위해 CPU 단에서 BVH(Bounding Volume Hierarchy)나 옥트리(Octree)와 같은 공간 분할 자료구조를 적용하여 절두체 컬링(Frustum Culling)을 수행해야 합니다 [18, 19]. 더불어, Z-버퍼만을 먼저 계산하여 가려진 파편(Fragment) 연산을 사전에 폐기하는 뎁스 프리패스(Depth Pre-Pass) 기법은 오버드로우를 줄이는 데 유효합니다 [11, 20]. 메모리 관리 측면에서는 웹 워커(Web Worker)와 `SharedArrayBuffer`를 사용하여 메인 스레드 차단 및 메모리의 중복 복사 없이 기하학적 데이터를 디코딩해야 하며, 씬에 변경 사항이 있을 때만 렌더링을 갱신하는 'Render-on-Demand' 방식을 통해 통합 GPU의 과부하 및 발열을 방지해야 합니다 [11, 21, 22].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Graphics & Performance 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[InstancedMesh]], [[BatchedMesh]], [[WebGPU]], [[Compute Shader]], [[Draw Call]], [[Occlusion Culling]], [[Level of Detail (LOD)]]
-- **Projects/Contexts:** [[IFC.js (Fragment)]], [[Revit glTF Export]]
-- **Contradictions/Notes:** 성능 최적화 기법으로 흔히 권장되는 `THREE.LOD` (Level of Detail)는 방대하고 동적으로 생성/변경되는 산업용 플랜트나 BIM 씬에서는 적합하지 않을 수 있습니다. 모든 LOD 단계의 메쉬를 GPU 메모리에 유지해야 하고, 런타임에 동적으로 지오메트리 단순화 버전을 생성하는 오버헤드가 커서 오히려 성능을 저하시킬 수 있기 때문입니다. 이러한 환경에서는 드로우 콜을 줄이는 배칭(Batching)이나 인스턴싱이 우선적으로 고려되어야 합니다 [3, 23-26].
-
----
-*Last updated: 2026-04-19*
-- Raw Source: [[00_Raw/2026-04-20/대규모 3D 건축 모델(BIM) 시각화.md]]
----
diff --git a/Graphics & Performance/대규모 건설 뷰어(Construction Viewers).md b/Graphics & Performance/대규모 건설 뷰어(Construction Viewers).md
deleted file mode 100644
index 12441a2d..00000000
--- a/Graphics & Performance/대규모 건설 뷰어(Construction Viewers).md	
+++ /dev/null
@@ -1,32 +0,0 @@
----
-id: P-REINFORCE-AUTO-9E35B0
-category: "[[10_Wiki/💡 Topics/Graphics & Performance]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - 대규모 건설 뷰어(Construction Viewers)"
----
-
-# [[대규모 건설 뷰어(Construction Viewers)]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 대규모 건설 뷰어(Construction Viewers)는 수천에서 수백만 개의 객체로 구성된 거대한 BIM(Building Information Modeling) 및 CAD 데이터를 웹 브라우저 환경 등에서 실시간으로 렌더링하고 시각화하는 플랫폼이다 [1-3]. 복잡한 기하학적 구조, 고유한 형태의 벽체나 배관, 반복되는 가구 등을 효율적으로 처리하고 사용자와의 상호작용을 지원하기 위해 Three.js, WebGPU, 그리고 다양한 렌더링 최적화 기법이 필수적으로 요구된다 [4-6].
-
-## 📖 구조화된 지식 (Synthesized Content)
-- **렌더링 방식 및 최적화 전략:** 대규모 건설 뷰어에서는 성능 병목인 드로우 콜(Draw call)을 줄이는 것이 핵심이다 [1]. 콘크리트 벽이나 바닥처럼 폴리곤 수가 적지만 형태가 고유한 객체는 기하학적 구조를 하나로 병합(Geometry Merging)하거나 `BatchedMesh`를 사용하여 렌더링한다 [4, 7]. 반면, 문, 창문, 가구 등 폴리곤 수가 많고 반복되는 객체는 메모리 소비를 최소화하기 위해 `InstancedMesh`를 활용한다 [7, 8]. IFC.js 프로젝트 등에서는 이러한 특성을 혼합하여 저폴리곤 고유 객체는 병합하고 고폴리곤 반복 객체는 인스턴싱하는 하이브리드(Fragment) 시스템을 설계하여 활용하기도 한다 [7, 9].
-- **Three.js와 WebGPU의 역할:** 2026년 기준, 500MB 이하의 일반적인 BIM 뷰어나 구성기(Configurator) 모델은 Three.js의 `WebGPURenderer` 등을 통해 빠르고 효율적으로 개발할 수 있다 [10, 11]. 그러나 병원 캠퍼스나 공항 터미널과 같이 500MB를 초과하는 거대한 건설 모델, 수백만 개의 LiDAR 포인트 클라우드, 또는 실시간 구조 시뮬레이션을 다루는 플랫폼의 경우, 메모리를 직접 제어할 수 있는 Native WebGPU의 도입이 필수적이다 [10, 12, 13]. WebGPU의 컴퓨트 셰이더(Compute Shader)는 충돌 감지, 현장 분석, 구조 시뮬레이션 등의 무거운 데이터 처리를 병렬로 수행하여 압도적인 성능 향상을 제공한다 [14, 15].
-- **상호작용 및 가시성 관리:** 건설 뷰어는 사용자가 개별 객체(벽, 배관 등)를 클릭하여 선택(Picking)하고 가시성, 색상, 치수 등을 동적으로 수정할 수 있어야 한다 [4, 6, 16]. 이를 위해 모델 로드 시 Vertex 속성(예: `_FEATURE_ID_0`)을 부여해 배치를 구분하거나 [17], 공간 분할(Spatial Indexing), 오클루전 컬링(Occlusion Culling), 룸-포털(Cell-portal) 기반의 가시성 제어 기법을 적용하여 거대한 씬의 상호작용 속도를 유지한다 [18, 19].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Graphics & Performance 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[BIM(Building Information Modeling)]], [[WebGPU]], [[BatchedMesh]], [[InstancedMesh]]
-- **Projects/Contexts:** [[IFC.js]], [[Revit]], [[Segments.ai]]
-- **Contradictions/Notes:** 동일한 재질의 객체를 묶어 가시성을 개별 관리하기 위해 `BatchedMesh`가 유용하게 쓰일 수 있지만, 수백만 개의 삼각형과 수십만 개의 고유 형상이 포함된 복잡한 Revit 추출 모델 등에서는 `BatchedMesh`를 사용했을 때 CPU 사용량이 급증하고 프레임률(FPS)이 오히려 크게 하락하는 심각한 성능 병목 현상이 보고되기도 한다 [20-23].
-
----
-*Last updated: 2026-04-19*
-- Raw Source: [[00_Raw/2026-04-20/대규모 건설 뷰어(Construction Viewers).md]]
----
diff --git a/Graphics & Performance/대규모 건축물 및 지형 뷰어(BIM).md b/Graphics & Performance/대규모 건축물 및 지형 뷰어(BIM).md
deleted file mode 100644
index d29aa004..00000000
--- a/Graphics & Performance/대규모 건축물 및 지형 뷰어(BIM).md	
+++ /dev/null
@@ -1,33 +0,0 @@
----
-id: P-REINFORCE-AUTO-73ED53
-category: "[[10_Wiki/💡 Topics/Graphics & Performance]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - 대규모 건축물 및 지형 뷰어(BIM)"
----
-
-# [[대규모 건축물 및 지형 뷰어(BIM)]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 대규모 건축물 및 지형 뷰어(BIM)는 병원 캠퍼스, 공항 터미널, 도시 규모의 디지털 트윈 등 500MB를 초과하는 방대한 규모의 3D 모델을 실시간으로 시각화하는 시스템이다 [1, 2]. 이러한 모델은 보, 기둥, HVAC 시스템과 같이 수십만 개의 개별 구성 요소로 이루어져 있어 막대한 렌더링 부하를 유발한다 [3]. 이를 원활하게 렌더링하고 시각적 상호작용을 지원하기 위해서는 WebGPU, BatchedMesh, 공간 분할 알고리즘 등 드로우 콜(Draw Call)을 최소화하고 메모리를 관리하는 고도의 최적화 기술이 필수적으로 요구된다 [3-5].
-
-## 📖 구조화된 지식 (Synthesized Content)
-- **BIM 모델의 렌더링 병목 현상:** BIM 및 CAD 데이터 모델은 벽, 바닥, 파이프 등 수많은 고유 부품과 객체로 구성되어 있어 이를 개별적으로 렌더링할 경우 드로우 콜 오버헤드로 인해 심각한 CPU 및 GPU 병목이 발생한다 [3, 6, 7]. 특히 콘크리트 벽체처럼 동일한 재질을 공유하되 각기 다른 기하학적 형태를 지닌 객체들은 단일 기하학적 구조만 지원하는 `InstancedMesh`를 그대로 적용하기 어렵다는 구조적 한계가 있다 [4, 8].
-- **BatchedMesh와 InstancedMesh의 하이브리드 활용:** 고유한 형태를 가진 저폴리곤 객체(벽, 바닥 등)는 `BatchedMesh`나 기하학 병합(Geometry Merging)을 통해 드로우 콜을 줄이고, 반복되는 고폴리곤 객체(문, 가구, 창문 등)는 `InstancedMesh`로 처리하는 하이브리드 최적화(예: Fragment 시스템) 방식이 대안으로 사용된다 [4, 9, 10]. `BatchedMesh`는 단일 드로우 콜로 여러 다른 기하학적 구조를 렌더링하면서도 개별 객체의 가시성과 색상을 독립적으로 제어할 수 있어 BIM 시각화 요구사항에 부합한다 [4, 11].
-- **WebGPU 및 컴퓨트 셰이더 도입:** 500MB 이상의 거대한 건축 모델이나 실시간 구조 시뮬레이션을 다룰 때는 자바스크립트의 단일 스레드 한계를 극복할 수 있는 Native WebGPU의 도입이 권장된다 [12-14]. 컴퓨트 셰이더(Compute Shader)를 활용하면 대규모 BIM 데이터셋의 실시간 필터링이나 충돌 감지 연산을 수천 개의 GPU 코어에서 병렬로 처리할 수 있어, 기존 CPU 처리 방식 대비 압도적인 성능 향상을 달성할 수 있다 [15, 16].
-- **가시성 판별(Culling) 및 메모리 최적화:** 뷰어의 성능을 안정적으로 유지하기 위해 화면에 보이지 않는 객체를 렌더링 파이프라인에서 제외하는 최적화가 필수적이다. CPU 기반의 공간 분할(Octree/BVH) 기술이나, GPU 컴퓨트 셰이더를 활용해 시야 포함 여부와 가림 현상(Occlusion)을 판별하는 GPU 주도 렌더링(GPU-driven Rendering) 기법이 적용된다 [5, 17, 18]. 더불어, 메모리 대역폭 한계와 크래시 현상을 극복하기 위해 텍스처 아틀라스를 사용하거나 Web Worker와 `SharedArrayBuffer`를 연계한 제로 카피(Zero-copy) 데이터 디코딩 구조가 활용된다 [19, 20].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Graphics & Performance 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[WebGPU]], [[BatchedMesh]], [[InstancedMesh]], [[Compute Shader]], [[Draw Call]], [[Frustum Culling]]
-- **Projects/Contexts:** [[Three.js]], [[IFC.js]], [[Cesium]]
-- **Contradictions/Notes:** 소스에 따르면 `BatchedMesh`는 BIM 모델처럼 다양한 기하학적 객체를 통합하는 데 필수적이라고 평가받지만 [4], 1,000만 개 이상의 정점과 다수의 고유 기하학을 포함하는 환경에서 정렬(Sort) 및 개별 절두체 컬링(perObjectFrustumCulled) 기능을 활성화할 경우, 도리어 단순 병합 메쉬(Merged Mesh)보다 30~50% 더 심각한 CPU 성능 저하를 일으킬 수 있다는 실증적 한계가 보고되고 있습니다 [21-26].
-
----
-*Last updated: 2026-04-19*
-- Raw Source: [[00_Raw/2026-04-20/대규모 건축물 및 지형 뷰어(BIM).md]]
----
diff --git a/Graphics & Performance/대규모 파티클 시스템 최적화.md b/Graphics & Performance/대규모 파티클 시스템 최적화.md
deleted file mode 100644
index cd91254c..00000000
--- a/Graphics & Performance/대규모 파티클 시스템 최적화.md	
+++ /dev/null
@@ -1,39 +0,0 @@
----
-id: P-REINFORCE-AUTO-A0A931
-category: "[[10_Wiki/💡 Topics/Graphics & Performance]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - 대규모 파티클 시스템 최적화"
----
-
-# [[대규모 파티클 시스템 최적화]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 대규모 파티클 시스템을 최적화하려면 CPU 연산 병목과 메모리 할당으로 인한 가비지 컬렉션(GC) 스파이크를 방지하는 것이 핵심입니다. 이를 위해 **WebGPU 연산 셰이더(Compute Shaders)**, **InstancedMesh**, **오브젝트 풀링(Object Pooling)**, 그리고 **데이터 지향 설계(ECS/SoA)**를 종합적으로 활용해야 합니다.
-
-## 📖 구조화된 지식 (Synthesized Content)
-**1. WebGPU 연산 셰이더(Compute Shaders) 및 GPU 영구 버퍼 도입** 전통적인 CPU 기반의 파티클 업데이트 방식은 일반적인 하드웨어 환경에서 파티클이 약 50,000개에 도달하면 심각한 성능 병목 현상을 일으킵니다. 처리량을 수백만 개 수준으로 끌어올리려면 연산 작업을 WebGPU의 연산 셰이더로 이전해야 합니다. 이때 `instancedArray`를 사용하여 프레임 간에 유지되는 GPU 영구 버퍼(Persistent GPU buffers)를 생성하면, 파티클 시스템의 성능을 저하시키는 주된 원인인 CPU-GPU 간의 데이터 전송 오버헤드를 원천적으로 제거할 수 있습니다.
-
-**2. 버퍼 업데이트의 일괄 처리 (Batching)** CPU 측에서 부득이하게 파티클 버퍼를 업데이트해야 할 경우, 수많은 작은 버퍼를 개별적으로 업데이트하는 것은 매우 높은 처리 비용을 유발합니다. 따라서 파티클 데이터를 크기가 큰 하나의 `Float32Array`에 모은 뒤, 단 한 번의 일괄 업데이트(Single batched update)로 처리하여 프레임당 버퍼 쓰기 횟수를 최소화해야 합니다.
-
-**3. InstancedMesh를 통한 드로우 콜(Draw Call) 최적화** 수만 개의 파티클을 개별적인 Three.js 메시(Mesh)로 렌더링하면 엄청난 수의 드로우 콜이 발생하여 프레임 레이트가 급락합니다. 시각적 렌더링 성능을 극대화하려면 **동일한 기하구조와 재질을 공유하는 `InstancedMesh`**를 사용해야 합니다. 이를 활용하면 수천, 수만 개의 파티클 인스턴스를 단 1회의 드로우 콜만으로 GPU에서 복제하여 렌더링할 수 있습니다.
-
-**4. 오브젝트 풀링(Object Pooling)을 통한 GC 스파이크 방지** 파티클처럼 아주 짧은 시간 동안 생성되고 사라지는 객체를 매번 새로 생성(`new Object()`)하고 삭제하면, 힙 메모리가 급격히 파편화되며 가비지 컬렉터(GC)에 엄청난 부하를 줍니다. 이는 화면이 뚝뚝 끊기는 'Stop-the-world' 프리징 현상의 주범입니다. 이를 해결하려면 **미리 고정된 크기의 오브젝트 풀(Fixed Pool)을 생성해 두고, 파티클을 새로 할당하는 대신 풀 안의 비활성 파티클 상태를 갱신하여 재사용**해야 런타임 메모리 할당 오버헤드를 피할 수 있습니다.
-
-**5. ECS 기반의 데이터 지향 설계 (Structure of Arrays, SoA)** 자바스크립트 스레드에서 대규모 파티클 상태를 시뮬레이션해야 한다면, 객체 지향 방식 대신 이전 대화에서 다룬 `bitECS`와 같은 데이터 지향 설계(ECS) 라이브러리를 적극 활용하는 것이 좋습니다. 파티클 속성 데이터를 무거운 JS 객체가 아닌 **연속된 메모리 블록(`TypedArray`) 기반의 SoA 구조로 저장**하면, CPU 캐시 적중률이 극대화되어 수천 개의 파티클 엔티티를 1ms 이내의 짧은 시간 안에 초고속으로 일괄 연산할 수 있습니다.
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Graphics & Performance 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[WebGPU Compute Shaders]], [[InstancedMesh (드로우 콜 최적화)]], [[Object Pooling (오브젝트 풀링)]], [[Garbage Collection (GC) 최적화]], [[Data-Oriented Design (bitECS)]]
-- **Projects/Contexts:** [[초대규모 파티클 및 엔티티 시뮬레이션 (React Three Fiber)]], [[고성능 실시간 상호작용 웹 게임 아키텍처]]
-- **Contradictions/Notes:** 연산 셰이더와 영구 GPU 버퍼를 사용해 수백만 개의 파티클을 제어하는 방식이 압도적으로 빠르지만, 이는 WebGPU 환경에서만 온전히 동작하며 WebGL 환경으로 폴백(Fallback)될 경우 이 수준의 동시성을 기대하기 어렵다는 제약이 있습니다.
-
----
-
-_Last updated: 2026-04-14_
-- Raw Source: [[00_Raw/2026-04-20/대규모 파티클 시스템 최적화.md]]
----
diff --git a/Graphics & Performance/마이크로 프론트엔드.md b/Graphics & Performance/마이크로 프론트엔드.md
deleted file mode 100644
index f54332c3..00000000
--- a/Graphics & Performance/마이크로 프론트엔드.md	
+++ /dev/null
@@ -1,34 +0,0 @@
----
-id: P-REINFORCE-AUTO-E74AFF
-category: "[[10_Wiki/💡 Topics/Graphics & Performance]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - 마이크로 프론트엔드"
----
-
-# [[마이크로 프론트엔드]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 마이크로 프론트엔드는 거대하고 복잡한 프론트엔드 애플리케이션을 백엔드의 마이크로서비스처럼 작고 독립적인 여러 조각으로 나누어 개발하는 아키텍처 접근 방식입니다 [1]. 이 방식을 통해 각 비즈니스 기능별로 전담 팀이 구성되어 선호하는 기술 스택을 활용해 독립적으로 모듈을 개발, 테스트 및 배포할 수 있습니다 [1-3]. 전통적인 모놀리식 프론트엔드 구조의 한계를 극복하고 팀의 자율성, 애플리케이션의 확장성 및 유지보수성을 향상시키는 데 목적이 있습니다 [2, 4].
-
-## 📖 구조화된 지식 (Synthesized Content)
-- **동작 원리 및 아키텍처 패턴:** 호스트 애플리케이션이 런타임 통합(웹 컴포넌트, iframe 등), 동적 로딩, 모듈 페더레이션, 서버 사이드 합성 등을 활용하여 개별 마이크로 프론트엔드들을 로드하고 결합합니다 [5]. 아키텍처 구현 시에는 각 모듈이 특정 라우트를 담당하는 라우트 기반 합성이나, 단일 페이지 내에 위젯처럼 임베딩되는 컴포넌트 기반 합성 등을 적용할 수 있습니다 [6].
-- **독립성과 통신 방식:** 각 팀의 코드와 스타일은 충돌하지 않도록 철저히 격리되어야 합니다 [7]. 모듈 간의 통신은 독립성을 해치지 않도록 커스텀 이벤트, 공유 상태 스토어, URL 매개변수 등을 활용하는 가벼운 통신 규약(Contract)을 통해 이루어져야 하며, 전역 변수 사용은 피해야 합니다 [7-9].
-- **도입의 이점:** 대규모 웹 애플리케이션에서 기능 중심의 모듈화를 통해 팀 간의 기술적 간섭을 차단하고 개발 속도를 높일 수 있습니다 [3, 10]. 또한, 시스템 전체를 중단시키지 않고도 레거시 코드의 점진적인 업그레이드가 가능합니다 [4].
-- **도전 과제 및 한계점:** 분산된 코드베이스와 빌드 파이프라인 관리로 인해 시스템 복잡성이 크게 증가합니다 [8]. 여러 모듈과 자바스크립트 번들이 로드되면서 초기 로딩 성능에 오버헤드가 발생할 수 있으며, 공유 의존성의 버전 불일치나 CSS 스타일 누수와 같은 문제도 흔히 발생합니다 [3, 8].
-- **적용 시 주의사항:** 이 아키텍처는 데브옵스(DevOps) 기반의 자동화 파이프라인과 모니터링 체계가 필수적입니다 [9]. 프로젝트의 규모가 작거나, 기능들이 서로 강하게 결합되어 있거나, 적절한 데브옵스 지원이 없는 환경에서는 오버헤드가 커지므로 도입을 피해야 합니다 [11].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Graphics & Performance 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (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]]
----
diff --git a/Graphics & Performance/만성 질환 행동 수정 개입.md b/Graphics & Performance/만성 질환 행동 수정 개입.md
deleted file mode 100644
index b6e1c5eb..00000000
--- a/Graphics & Performance/만성 질환 행동 수정 개입.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-2F0833
-category: "[[10_Wiki/💡 Topics/Graphics & Performance]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - 만성 질환 행동 수정 개입"
----
-
-# [[만성 질환 행동 수정 개입]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Graphics & Performance 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/만성 질환 행동 수정 개입.md]]
----
diff --git a/Graphics & Performance/명령형 직접 조작 (Imperative Manipulation).md b/Graphics & Performance/명령형 직접 조작 (Imperative Manipulation).md
deleted file mode 100644
index 3196719b..00000000
--- a/Graphics & Performance/명령형 직접 조작 (Imperative Manipulation).md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-2E3155
-category: "[[10_Wiki/💡 Topics/Graphics & Performance]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - 명령형 직접 조작 (Imperative Manipulation)"
----
-
-# [[명령형 직접 조작 (Imperative Manipulation)]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Graphics & Performance 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/명령형 직접 조작 (Imperative Manipulation).md]]
----
diff --git a/Graphics & Performance/모바일 기반 WebGL 애플리케이션 개발.md b/Graphics & Performance/모바일 기반 WebGL 애플리케이션 개발.md
deleted file mode 100644
index 97afdd1f..00000000
--- a/Graphics & Performance/모바일 기반 WebGL 애플리케이션 개발.md	
+++ /dev/null
@@ -1,47 +0,0 @@
----
-id: P-REINFORCE-AUTO-18A5BC
-category: "[[10_Wiki/💡 Topics/Graphics & Performance]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - 모바일 기반 WebGL 애플리케이션 개발"
----
-
-# [[모바일 기반 WebGL 애플리케이션 개발]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 모바일 기반 WebGL 애플리케이션 개발은 상대적으로 부족한 시스템 메모리와 프로세서 성능을 지닌 모바일 브라우저 환경에서 매끄러운 3D 렌더링(60fps)을 구현하고 배터리 소모를 최소화하는 데 중점을 두는 기술적 접근입니다. 제한된 하드웨어 리소스를 극복하기 위해 엄격한 폴리곤 수 및 드로우 콜(Draw Call) 제한, 텍스처 메모리 압축, 셰이더 정밀도 하향, 그리고 디바이스 특성을 고려한 전원 및 컨텍스트 관리 기법이 복합적으로 동원됩니다.
-
-## 📖 구조화된 지식 (Synthesized Content)
-*   **지오메트리 및 드로우 콜 한계 관리**
-    *   모바일 브라우저(iOS Safari, Chrome Mobile, Firefox Mobile 등)는 씬 당 50,000에서 100,000 폴리곤을 처리하는 것이 가장 적합합니다 [1].
-    *   드로우 콜이 1,000에서 2,000회를 초과할 경우 모바일 프로세서에서 병목 현상이 발생하여 심각한 성능 저하로 이어집니다 [2].
-
-*   **메모리 및 텍스처 최적화**
-    *   시스템 메모리가 2~4GB에 불과한 모바일 기기에서는 텍스처 메모리 사용량이 500MB를 초과할 때 가비지 컬렉션(GC)으로 인한 일시 정지와 심각한 프레임 끊김이 발생합니다 [3].
-    *   모바일 GPU의 오버헤드를 크게 줄이려면 여러 텍스처를 하나의 아틀라스(Atlas) 텍스처로 결합하여 다중 텍스처 바인딩을 피해야 합니다 [4].
-    *   Basis Universal 포맷을 사용하면 텍스처를 모바일 환경에 맞는 GPU 압축 포맷(iOS의 PVRTC, 모바일의 ASTC 등)으로 로드 시점에 맞게 트랜스코딩하여 메모리 점유율을 크게 낮출 수 있습니다 [5].
-
-*   **셰이더 및 렌더링 파이프라인 튜닝**
-    *   모바일 GPU는 `mediump` 정밀도를 `highp`보다 약 2배 빠른 속도로 처리하므로, 깊이(depth) 계산이나 위치 좌표 등 꼭 필요한 경우를 제외하고는 `mediump`를 사용해야 합니다 [6].
-    *   버텍스 셰이더와 프래그먼트 셰이더 간 데이터를 전달하는 varying 변수는 모바일 GPU 환경에서 3개 이하로 최소화해야 합니다 [6].
-    *   퍼포먼스를 확보하기 위해 네이티브 멀티샘플링 안티앨리어싱(MSAA)을 비활성화하고, 그 대신 FXAA를 마지막 패스에 적용해야 모바일에서 60fps를 안정적으로 유지할 수 있습니다 [7]. 
-    *   그림자 맵(Shadow map)의 크기는 모바일 기기에 맞게 512에서 1024 해상도로 설정하는 것이 적절합니다 [8].
-
-*   **배터리 절약 및 모바일 예외 상황 처리**
-    *   React Three Fiber 등에서 정적인 씬을 구현할 때 `frameloop="demand"` 옵션을 설정하여 불필요한 프레임 렌더링을 멈춤으로써 모바일 기기의 배터리를 아낄 수 있습니다 [9].
-    *   모바일 환경에서는 WebGL 컨텍스트가 유실(context lost)되는 현상이 발생할 수 있으므로, 해당 이벤트를 수신하여 자연스럽게 복구되도록 처리해야 합니다 [10].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Graphics & Performance 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[드로우 콜 최적화(Draw Call Optimization)]], [[텍스처 압축 및 아틀라스(Texture Compression & Atlas)]], [[셰이더 정밀도 최적화(Shader Precision Optimization)]], [[가비지 컬렉션 관리(Garbage Collection Management)]]
-- **Projects/Contexts:** [[Three.js WebGL 렌더링]], [[모바일 환경의 메모리 병목]]
-- **Contradictions/Notes:** 뼈대 텍스처의 부분 업데이트(partial texture updates)와 같은 특정 세부 렌더링 최적화 기법은 일부 모바일 기기와 Firefox 브라우저 환경에서는 오히려 속도를 느리게 만드는 부작용(역효과)이 보고되었습니다 [11, 12]. 
-
----
-*Last updated: 2026-04-19*
-- Raw Source: [[00_Raw/2026-04-20/모바일 기반 WebGL 애플리케이션 개발.md]]
----
diff --git a/Graphics & Performance/브라우저 그래픽 렌더링 백엔드.md b/Graphics & Performance/브라우저 그래픽 렌더링 백엔드.md
deleted file mode 100644
index 455b55b5..00000000
--- a/Graphics & Performance/브라우저 그래픽 렌더링 백엔드.md	
+++ /dev/null
@@ -1,30 +0,0 @@
----
-id: P-REINFORCE-AUTO-102878
-category: "[[10_Wiki/💡 Topics/Graphics & Performance]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - 브라우저 그래픽 렌더링 백엔드"
----
-
-# [[브라우저 그래픽 렌더링 백엔드]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 브라우저 그래픽 렌더링 백엔드는 WebGL이나 WebGPU와 같은 웹 그래픽 API의 명령을 물리적 GPU가 실행할 수 있는 명령어로 변환하고 전달하는 기반 시스템입니다 [1, 2]. Windows 환경에서는 ANGLE과 같은 브라우저 추상화 계층을 사용하여 OpenGL ES 호출을 Direct3D로 변환하는 역할을 수행합니다 [1, 3]. 최근의 WebGPU 환경에서는 Dawn과 같은 백엔드를 통해 Vulkan, Metal, Direct3D 12 등 차세대 네이티브 GPU API와 직접적으로 상호작용하여 렌더링 성능을 극대화합니다 [2, 4, 5].
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Graphics & Performance 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[WebGL]], [[WebGPU]], [[ANGLE]], [[Dawn]], [[마이크로 레이턴시(Micro-latency)]]
-- **Projects/Contexts:** [[Google Chrome]], [[Mozilla Firefox]]
-- **Contradictions/Notes:** Windows 환경의 ANGLE 백엔드는 WebGL 호환성을 훌륭하게 제공하지만, OpenGL ES를 Direct3D로 변환하는 과정에서 본질적인 오버헤드를 동반합니다. 수천 개의 드로우 콜이 발생하는 복잡한 씬에서는 GPU가 유휴 상태임에도 불구하고 CPU 병목 현상과 마이크로 레이턴시가 누적되어 성능 저하를 일으킬 수 있습니다 [6]. 이를 우회하여 네이티브 OpenGL 구현을 테스트하기 위해 Chrome에서 `--use-gl=desktop` 플래그를 사용하기도 합니다 [3].
-
----
-*Last updated: 2026-04-19*
-- Raw Source: [[00_Raw/2026-04-20/브라우저 그래픽 렌더링 백엔드.md]]
----
diff --git a/Graphics & Performance/서비스 디자인 (Service Design).md b/Graphics & Performance/서비스 디자인 (Service Design).md
deleted file mode 100644
index c0cf9fdc..00000000
--- a/Graphics & Performance/서비스 디자인 (Service Design).md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-DB809B
-category: "[[10_Wiki/💡 Topics/Graphics & Performance]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - 서비스 디자인 (Service Design)"
----
-
-# [[서비스 디자인 (Service Design)]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Graphics & Performance 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/서비스 디자인 (Service Design).md]]
----
diff --git a/Graphics & Performance/셰이더 정밀도 (Mediump_Highp).md b/Graphics & Performance/셰이더 정밀도 (Mediump_Highp).md
deleted file mode 100644
index 72c354cc..00000000
--- a/Graphics & Performance/셰이더 정밀도 (Mediump_Highp).md	
+++ /dev/null
@@ -1,32 +0,0 @@
----
-id: P-REINFORCE-AUTO-B2C911
-category: "[[10_Wiki/💡 Topics/Graphics & Performance]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - 셰이더 정밀도 (Mediump_Highp)"
----
-
-# [[셰이더 정밀도 (Mediump_Highp)]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 셰이더 정밀도(Mediump/Highp)는 3D 그래픽스의 셰이더 연산에서 변수의 데이터 정확도를 결정하는 설정입니다. 모바일 GPU 환경에서 `mediump`(중간 정밀도)는 `highp`(고정밀도)보다 약 2배 빠른 속도로 처리됩니다 [1]. 따라서 깊이 계산이나 위치 연산과 같이 높은 정밀도가 반드시 필요한 경우에만 `highp`를 사용하고, 그 외에는 `mediump`를 사용하는 것이 모바일 성능 최적화의 핵심입니다 [1].
-
-## 📖 구조화된 지식 (Synthesized Content)
-* **모바일 환경에서의 성능 최적화:** 셰이더 최적화는 전문가와 초보자를 구분 짓는 중요한 요소입니다 [1]. 특히 모바일 기기에서는 셰이더의 작은 변화만으로도 2배의 성능 향상을 얻을 수 있습니다 [1].
-* **처리 속도 차이:** 모바일 GPU는 `mediump` 정밀도를 연산할 때 `highp` 정밀도에 비해 대략 2배 빠른 속도를 보여줍니다 [1]. 
-* **Highp의 선별적 사용:** 모든 변수에 고정밀도를 사용하는 것은 모바일 성능에 악영향을 미칩니다. `highp`는 깊이 계산(depth calculations)이나 객체의 위치(positions) 파악과 같이 고도의 정확도가 필수적으로 요구되는 작업에만 제한적으로 사용해야 합니다 [1].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Graphics & Performance 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[셰이더 최적화]], [[깊이 계산 (Depth Calculations)]]
-- **Projects/Contexts:** [[Three.js 모바일 성능 최적화]]
-- **Contradictions/Notes:** 소스에 관련 정보가 제한적이며, 주어진 자료 내에서 셰이더 정밀도에 대한 이견이나 추가적인 구체적 작동 원리에 대한 소스에 관련 정보가 부족합니다 [1].
-
----
-*Last updated: 2026-04-19*
-- Raw Source: [[00_Raw/2026-04-20/셰이더 정밀도 (Mediump_Highp).md]]
----
diff --git a/Graphics & Performance/스토리지 텍스처(Storage Textures).md b/Graphics & Performance/스토리지 텍스처(Storage Textures).md
deleted file mode 100644
index a33dcbc6..00000000
--- a/Graphics & Performance/스토리지 텍스처(Storage Textures).md	
+++ /dev/null
@@ -1,31 +0,0 @@
----
-id: P-REINFORCE-AUTO-F28DA7
-category: "[[10_Wiki/💡 Topics/Graphics & Performance]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - 스토리지 텍스처(Storage Textures)"
----
-
-# [[스토리지 텍스처(Storage Textures)]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 스토리지 텍스처(Storage Textures)는 일반적인 텍스처와 달리 컴퓨트 셰이더(Compute Shaders) 내에서 데이터의 읽기와 쓰기 작업이 모두 가능한 특수한 텍스처입니다 [1]. 복잡한 그래픽 처리 및 시뮬레이션을 GPU 상에서 직접 수행하기 위한 핵심적인 역할을 담당합니다 [1, 2].
-
-## 📖 구조화된 지식 (Synthesized Content)
-* **읽기 및 쓰기 동시 지원:** 기존의 일반 텍스처들은 셰이더 내에서 일반적으로 읽기 전용으로 작동하지만, 스토리지 텍스처는 컴퓨트 셰이더에서 양방향(읽기 및 쓰기) 접근을 허용합니다 [1].
-* **주요 활용 분야:** 이러한 읽기/쓰기 특성 덕분에 높은 컴퓨팅 연산이 필요한 그래픽 작업에 필수적입니다. 소스에서 명시된 대표적인 적용 사례로는 유체 시뮬레이션(fluid simulation), 이미지 처리(image processing), 그리고 GPU 기반 렌더링(GPU-driven rendering)이 있습니다 [1, 2].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Graphics & Performance 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[컴퓨트 셰이더(Compute Shaders)]], [[웹GPU(WebGPU)]]
-- **Projects/Contexts:** [[유체 시뮬레이션(Fluid simulation)]], [[이미지 처리(Image processing)]], [[GPU 기반 렌더링(GPU-driven rendering)]]
-- **Contradictions/Notes:** 소스에서는 스토리지 텍스처의 특징을 설명하기 위해 일반 텍스처(regular textures)와 대조하고 있으며, 일반 텍스처는 컴퓨트 셰이더에서 읽고 쓰기를 동시에 할 수 없다는 점을 강조합니다 [1].
-
----
-*Last updated: 2026-04-19*
-- Raw Source: [[00_Raw/2026-04-20/스토리지 텍스처(Storage Textures).md]]
----
diff --git a/Graphics & Performance/실시간 렌더링 파이프라인.md b/Graphics & Performance/실시간 렌더링 파이프라인.md
deleted file mode 100644
index 8ebfe365..00000000
--- a/Graphics & Performance/실시간 렌더링 파이프라인.md	
+++ /dev/null
@@ -1,30 +0,0 @@
----
-id: P-REINFORCE-AUTO-8DF18B
-category: "[[10_Wiki/💡 Topics/Graphics & Performance]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - 실시간 렌더링 파이프라인"
----
-
-# [[실시간 렌더링 파이프라인]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 실시간 렌더링 파이프라인은 CPU와 GPU 간의 통신을 통해 3D 객체를 화면에 실시간으로 그려내는 일련의 과정이다 [1]. 이 과정은 CPU가 렌더링 상태를 설정하고 명령을 전달하는 드로우 콜(Draw Call) 단계로 시작하여, GPU가 정점을 변환하고 픽셀을 계산하여 화면에 출력하는 단계로 구성된다 [1, 2]. 파이프라인의 성능은 주로 이 두 장치 간의 통신 오버헤드와 데이터 전송 효율성, 그리고 GPU의 병목 현상을 어떻게 최적화하느냐에 따라 결정된다 [1, 3].
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Graphics & Performance 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[드로우 콜 (Draw Call)]], [[하드웨어 인스턴싱 (Hardware Instancing)]], [[프래그먼트 셰이딩 (Fragment Shading)]], [[오버드로우 (Overdraw)]]
-- **Projects/Contexts:** [[Three.js]], [[WebGPU]], [[Unity]], [[BatchedMesh]]
-- **Contradictions/Notes:** 실시간 렌더링 파이프라인에서 드로우 콜을 줄이기 위해 도입하는 InstancedMesh 기법은 CPU 오버헤드는 획기적으로 낮추지만, 가시성 판단 로직(시야 절두체 컬링) 부재와 객체 자동 정렬 기능의 한계로 인해 오히려 GPU 측(프래그먼트 처리 등)에 새로운 병목과 막대한 오버드로우 비용을 유발할 수 있다는 기술적 딜레마가 존재한다 [7-9, 15].
-
----
-*Last updated: 2026-04-19*
-- Raw Source: [[00_Raw/2026-04-20/실시간 렌더링 파이프라인.md]]
----
diff --git a/Graphics & Performance/실시간 물리 및 유체 시뮬레이션.md b/Graphics & Performance/실시간 물리 및 유체 시뮬레이션.md
deleted file mode 100644
index 10c84a97..00000000
--- a/Graphics & Performance/실시간 물리 및 유체 시뮬레이션.md	
+++ /dev/null
@@ -1,33 +0,0 @@
----
-id: P-REINFORCE-AUTO-4173D4
-category: "[[10_Wiki/💡 Topics/Graphics & Performance]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - 실시간 물리 및 유체 시뮬레이션"
----
-
-# [[실시간 물리 및 유체 시뮬레이션]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 실시간 물리 및 유체 시뮬레이션은 입자의 움직임과 복잡한 물리적 상호작용을 실시간으로 계산하여 시각화하는 기술입니다. 과거에는 CPU에서 관련 계산을 수행하여 처리량에 한계가 있었으나, 최근에는 WebGPU와 컴퓨트 셰이더(Compute Shaders)를 활용해 연산을 GPU로 오프로드(Offload)하는 방식이 도입되었습니다. 이를 통해 수십만에서 수백만 개에 달하는 입자 시스템과 유체 역학을 웹 브라우저 상에서 지연 없이 부드럽게 렌더링할 수 있게 되었습니다.
-
-## 📖 구조화된 지식 (Synthesized Content)
-* **컴퓨트 셰이더를 활용한 성능 극대화:** 기존 CPU 기반의 입자 시스템 연산은 일반적인 하드웨어 환경에서 약 5만 개의 입자를 처리할 때 병목 현상에 직면합니다 [1]. 그러나 WebGPU의 컴퓨트 셰이더를 활용하면 수백만 개의 입자와 물리 시뮬레이션을 병렬로 처리할 수 있어 성능이 획기적으로 향상됩니다 [1-3]. 예를 들어, CPU에서 10,000개의 입자를 업데이트하는 데 프레임당 30ms가 소요되는 반면, WebGPU 컴퓨트 셰이더를 사용하면 100,000개의 입자를 2ms 미만으로 업데이트할 수 있어 최대 150배의 성능 향상을 이룰 수 있습니다 [4].
-* **유체 시뮬레이션과 스토리지 텍스처(Storage Textures):** 유체 시뮬레이션과 같이 실시간으로 읽기와 쓰기가 모두 필요한 복잡한 연산에는 스토리지 텍스처가 필수적으로 사용됩니다 [5, 6]. 일반 텍스처와 달리 스토리지 텍스처는 컴퓨트 셰이더 내에서 데이터를 동시에 읽고 쓸 수 있게 지원하므로, 유체 역학 시뮬레이션 및 GPU 기반 렌더링을 효율적으로 구현할 수 있도록 돕습니다 [5, 6].
-* **대규모 물리 연산의 GPU 오프로딩:** 네이티브 WebGPU 환경에서는 충돌 감지나 구조 시뮬레이션과 같이 리소스가 많이 드는 물리 연산을 수천 개의 GPU 코어에서 병렬로 실행할 수 있습니다 [4, 7]. 이는 자바스크립트 메인 스레드의 부하를 크게 줄여주며, 성능이 매우 중요한 실시간 시뮬레이션에서 강력한 이점을 제공합니다 [8].
-* **물리 엔진 통합 지원:** Three.js 생태계 내에서는 AmmoPhysics, JoltPhysics, RapierPhysics 등 다양한 서드파티 물리 엔진과의 통합을 지원하여 보다 쉽게 물리 시뮬레이션을 구현할 수 있는 환경을 제공하고 있습니다 [9, 10].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Graphics & Performance 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[WebGPU]], [[컴퓨트 셰이더(Compute Shaders)]], [[스토리지 텍스처(Storage Textures)]], [[입자 시스템(Particle Systems)]]
-- **Projects/Contexts:** [[오사카 엑스포 2025 호쿠사이 인스톨레이션(Hokusai installation)]] (Utsubo 스튜디오가 개발하여 98인치 4K 디스플레이에서 100만 개의 입자로 구성된 유체 시뮬레이션을 다중 인물 신체 추적과 함께 지연 없이 실시간으로 구현한 프로젝트 [11, 12])
-- **Contradictions/Notes:** 소스에 관련 정보가 부족합니다. (소스 내에서 물리 및 유체 시뮬레이션에 대한 상충되는 주장은 발견되지 않으며, 단순히 CPU 기반 처리와 GPU 컴퓨트 셰이더 기반 처리 간의 극적인 성능 차이와 이점만이 일관되게 강조되고 있습니다 [1, 4].)
-
----
-*Last updated: 2026-04-19*
-- Raw Source: [[00_Raw/2026-04-20/실시간 물리 및 유체 시뮬레이션.md]]
----
diff --git a/Graphics & Performance/실시간 물리 시뮬레이션 동기화.md b/Graphics & Performance/실시간 물리 시뮬레이션 동기화.md
deleted file mode 100644
index 4deb289a..00000000
--- a/Graphics & Performance/실시간 물리 시뮬레이션 동기화.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-6A6001
-category: "[[10_Wiki/💡 Topics/Graphics & Performance]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - 실시간 물리 시뮬레이션 동기화"
----
-
-# [[실시간 물리 시뮬레이션 동기화]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Graphics & Performance 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/실시간 물리 시뮬레이션 동기화.md]]
----
diff --git a/Graphics & Performance/웹 브라우저 그래픽 API 호환성.md b/Graphics & Performance/웹 브라우저 그래픽 API 호환성.md
deleted file mode 100644
index c930a1d3..00000000
--- a/Graphics & Performance/웹 브라우저 그래픽 API 호환성.md	
+++ /dev/null
@@ -1,33 +0,0 @@
----
-id: P-REINFORCE-AUTO-7B4FF5
-category: "[[10_Wiki/💡 Topics/Graphics & Performance]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - 웹 브라우저 그래픽 API 호환성"
----
-
-# [[웹 브라우저 그래픽 API 호환성]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 웹 브라우저 그래픽 API 호환성은 WebGL 및 WebGPU와 같은 웹 기반 3D 그래픽 기술이 다양한 웹 브라우저, 운영 체제, 하드웨어 환경에서 일관되게 작동하고 최적화되는 정도를 의미합니다 [1-3]. WebGL은 폭넓게 지원되지만 OS별 그래픽 계층 변환 오버헤드와 브라우저 보안 제약의 영향을 크게 받으며, 차세대 표준인 WebGPU는 최신 하드웨어 기술을 활용하나 브라우저별 파편화가 존재하고 WebGL과 하위 호환되지 않습니다 [4-6]. 따라서 성능 최적화를 위해서는 대상 하드웨어 아키텍처와 브라우저별 API 지원 범위를 고려한 플랫폼 교차적 설계가 필수적입니다 [7, 8].
-
-## 📖 구조화된 지식 (Synthesized Content)
-- **플랫폼별 WebGL 구현 차이 및 오버헤드:** WebGL은 OpenGL ES 2.0을 기반으로 하는 크로스 플랫폼 라이브러리이지만 운영 체제마다 구현 메커니즘이 다릅니다 [1]. 예를 들어 Windows 환경에서 Chrome, Firefox, Opera는 ANGLE(Almost Native Graphics Layer Engine) 계층을 사용하여 WebGL 호출을 Direct3D 11 또는 12로 변환하는데, 이 과정에서 드로콜(Draw call)당 마이크로 지연(Micro-latency)이 발생하여 CPU 병목 현상을 유발할 수 있습니다 [4, 9, 10]. 반면 Safari(macOS 및 iOS)에서는 `bufferSubData()`와 같은 특정 WebGL 호출에서 비직관적으로 큰 오버헤드가 발생합니다 [11, 12]. 듀얼 GPU를 사용하는 Mac의 경우, WebGL 컨텍스트가 수명 주기 동안 GPU를 전환하는 것이 공식적인 보안 문제로 취급되어 외장 GPU 모드로 강제 전환해야 하므로 약 1초의 컨텍스트 생성 지연이 발생하기도 합니다 [13].
-- **보안 정책에 따른 타이머 및 확장 기능 호환성:** 브라우저 환경에서는 악성 웹사이트로부터의 보호를 위해 모든 그래픽 API 호출에 대한 안전성 검사(Marshalling)가 필요합니다 [14]. 특히 Spectre, Meltdown, Rowhammer 같은 타이밍 기반의 사이드 채널 공격을 방지하기 위해 여러 브라우저 벤더는 `EXT_disjoint_timer_query`와 같은 고정밀 GPU 타이머 쿼리 기능의 지원을 중단하거나 비활성화했습니다 [15-20]. 이후 WebGPU 환경에서도 동일한 보안 우려로 인해 교차 출처 격리(Cross-origin isolated) 상태인 컨텍스트에서만 타임스탬프 쿼리 정밀도를 100 마이크로초(µs)로 제한(Quantization)하여 노출하도록 호환성 표준을 조율했습니다 [21-23].
-- **WebGPU의 브라우저 지원 파편화 및 비호환성:** 차세대 API인 WebGPU는 Vulkan, Metal, Direct3D 12 등의 네이티브 GPU API를 공통된 구조로 브라우저에 제공하지만, 기존 WebGL과는 하위 호환성을 전혀 지원하지 않아 프레임워크 사용자들에게 "업그레이드 충격"을 유발합니다 [5, 6, 24]. 2025년 및 2026년 기준, Chrome과 Edge는 데스크톱에서 안정적으로 지원되는 반면, Safari는 macOS 26 및 iOS 26부터 기본 지원이 도입되었고, Firefox는 Windows(버전 141) 등 특정 플랫폼에서만 작동하거나 불안정한 오류가 보고되는 등 브라우저와 모바일 OS별 지원 수준에 아직 큰 차이가 존재합니다 [3, 25, 26].
-- **크로스 플랫폼 하드웨어 스케줄링의 제약:** WebGPU는 범용 컴퓨팅(Compute Shaders)을 웹에 도입했으나, 크로스 플랫폼 호환성 유지를 위해 특정 하드웨어 스케줄링 순서나 세밀한 전역 원자성(Global atomics)을 보장하지 않습니다 [7, 27]. 따라서 CUDA 등 기존 네이티브 환경에서 사용되던 동기화 방식(예: 작업 그룹 간 Spin-wait)을 WebGPU에 그대로 이식할 경우, Apple M1과 같은 특정 칩셋 환경에서 무한 대기(Busy-wait)를 유발하여 심각한 성능 저하나 실행 실패를 일으킬 수 있습니다 [7, 28].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Graphics & Performance 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[WebGL]], [[WebGPU]], [[ANGLE]], [[Spectre 및 Meltdown]], [[타이머 쿼리 제한(Timer Query Quantization)]]
-- **Projects/Contexts:** [[3D Gaussian Splatting(3DGS) 웹 렌더링]], [[크로스 플랫폼 성능 프로파일링]]
-- **Contradictions/Notes:** WebGL의 `EXT_disjoint_timer_query` 확장 기능에 대해 `caniuse.com`의 지원 정보나 일부 문서가 최신 호환성 상태(보안 문제로 인한 브라우저별 비활성화 조치 등)를 정확히 반영하지 못하고 상충되는 정보를 제공했던 혼선이 존재했습니다 [17, 29]. 또한, WebGPU는 그래픽 성능과 리소스 제어권을 크게 향상시키지만 WebGL과 하위 호환되지 않으므로, 보편적 접근성이 필요한 프로젝트의 경우 WebGPU 지원이 대중화되기 전까지 WebGL 기반의 폴백(Fallback) 렌더링 환경을 유지해야만 하는 제약이 있습니다 [6, 25, 30].
-
----
-*Last updated: 2026-04-19*
-- Raw Source: [[00_Raw/2026-04-20/웹 브라우저 그래픽 API 호환성.md]]
----
diff --git a/Graphics & Performance/입자 시스템(Particle Systems).md b/Graphics & Performance/입자 시스템(Particle Systems).md
deleted file mode 100644
index 2f3c5769..00000000
--- a/Graphics & Performance/입자 시스템(Particle Systems).md	
+++ /dev/null
@@ -1,33 +0,0 @@
----
-id: P-REINFORCE-AUTO-1C7197
-category: "[[10_Wiki/💡 Topics/Graphics & Performance]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - 입자 시스템(Particle Systems)"
----
-
-# [[입자 시스템(Particle Systems)]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 입자 시스템(Particle Systems)은 게임이나 3D 그래픽 환경에서 유체, 총알, 특수 효과 등 수많은 개체를 효율적으로 렌더링하고 관리하기 위한 기법입니다 [1, 2]. 전통적인 CPU 기반의 입자 업데이트는 연산 한계로 인해 약 5만 개 부근에서 성능 병목에 도달하지만, WebGPU의 컴퓨트 셰이더를 활용하면 처리량을 수백만 개 단위로 끌어올릴 수 있습니다 [1, 3]. 또한 프레임워크에 따라 InstancedMesh나 Solid Particle System(SPS)을 활용하여 드로우 콜(Draw call)을 줄이고 렌더링 성능을 최적화할 수 있습니다 [4-6].
-
-## 📖 구조화된 지식 (Synthesized Content)
-- **컴퓨트 셰이더(Compute Shaders) 및 WebGPU 활용:** 전통적인 방식의 입자 시스템에서 발생하는 CPU-GPU 간 데이터 전송은 심각한 성능 저하를 초래합니다 [1]. 이를 극복하기 위해 입자 시스템을 WebGPU의 컴퓨트 셰이더로 마이그레이션하면 처리 가능한 입자 수를 수백만 개 단위로 크게 늘릴 수 있습니다 [1, 3].
-- **GPU 영구 버퍼 및 객체 풀링:** `instancedArray`를 사용하여 프레임 간에도 유지되는 GPU 영구 버퍼를 생성하면, 입자 데이터를 매 프레임 업데이트할 때 발생하는 데이터 전송 병목을 제거할 수 있습니다 [1, 7]. 또한, 잦은 생성과 소멸이 일어나는 입자들은 객체 풀링(Object pooling) 기법을 사용하여 런타임 메모리 할당 오버헤드와 가비지 컬렉션(GC)으로 인한 멈춤 현상을 방지해야 합니다 [2].
-- **인스턴싱(Instancing)과 커스텀 셰이더 결합:** 반복되는 입자 객체에 `InstancedMesh`를 사용하면 드로우 콜을 단일화할 수 있습니다 [4]. 이러한 인스턴싱에 커스텀 정점 셰이더(Vertex shader)를 결합하여 절차적으로 형상을 변형하면, 메시 데이터를 추가로 복제하지 않고도 입자 효과의 다양성을 확보하는 데 매우 효과적입니다 [8].
-- **Solid Particle System (SPS)와 인스턴스 메시 비교 (Babylon.js 사례):** Babylon.js 환경에서는 Solid Particle System(SPS)를 사용하여 수많은 입자의 상태(재질 등)를 관리할 수 있습니다 [9]. SPS는 `setParticles()` 호출 시에만 가벼운 전용 월드 행렬을 계산하며 프러스텀 테스트(Frustum test)가 기본적으로 비활성화되어 있어, 50 정점 미만의 수많은 저폴리곤 입자 처리에 인스턴스 메시보다 더 유리합니다 [5, 6]. 하지만 SPS는 원본 기하학적 데이터(Geometry)를 내부적으로 복제하여 처리하므로, 메모리 소비량 측면에서는 인스턴싱 방식에 비해 훨씬 무겁다는 단점이 있습니다 [10, 11].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Graphics & Performance 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[WebGPU]], [[컴퓨트 셰이더(Compute Shaders)]], [[InstancedMesh]], [[Solid Particle System (SPS)]]
-- **Projects/Contexts:** [[Hokusai installation]] - 엑스포 2025 오사카(Expo 2025 Osaka)에서 100만 개의 입자 기반 유체 시뮬레이션을 WebGPU로 구현한 프로젝트입니다 [12].
-- **Contradictions/Notes:** Babylon.js 환경의 Solid Particle System(SPS)는 저폴리곤 입자의 CPU 연산 성능 면에서는 우수하지만, 입자별로 기하학적 데이터를 복제해야 하므로 메모리 점유율 측면에서는 인스턴스 메시(InstancedMesh) 방식에 비해 비효율적이라는 트레이드오프(Trade-off)가 존재합니다 [6, 10, 11].
-
----
-*Last updated: 2026-04-19*
-- Raw Source: [[00_Raw/2026-04-20/입자 시스템(Particle Systems).md]]
----
diff --git a/Graphics & Performance/조직 행동론의 직무 몰입 연구.md b/Graphics & Performance/조직 행동론의 직무 몰입 연구.md
deleted file mode 100644
index 5a2112d2..00000000
--- a/Graphics & Performance/조직 행동론의 직무 몰입 연구.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-6B36D0
-category: "[[10_Wiki/💡 Topics/Graphics & Performance]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - 조직 행동론의 직무 몰입 연구"
----
-
-# [[조직 행동론의 직무 몰입 연구]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Graphics & Performance 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/조직 행동론의 직무 몰입 연구.md]]
----
diff --git a/Graphics & Performance/컴퓨트 셰이더(Compute Shaders).md b/Graphics & Performance/컴퓨트 셰이더(Compute Shaders).md
deleted file mode 100644
index b4b1e303..00000000
--- a/Graphics & Performance/컴퓨트 셰이더(Compute Shaders).md	
+++ /dev/null
@@ -1,42 +0,0 @@
----
-id: P-REINFORCE-AUTO-C4EB25
-category: "[[10_Wiki/💡 Topics/Graphics & Performance]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - 컴퓨트 셰이더(Compute Shaders)"
----
-
-# [[컴퓨트 셰이더(Compute Shaders)]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 컴퓨트 셰이더(Compute Shaders)는 JavaScript 메인 스레드에서 수행되던 무거운 작업을 수천 개의 GPU 코어에서 병렬로 처리하도록 오프로드하는 범용 GPU 연산(general-purpose GPU computation) 기술입니다 [1]. 주로 WebGPU 환경에서 사용되며, 파티클 시스템, 물리 시뮬레이션, 대규모 데이터 필터링 등의 CPU 병목 현상을 획기적으로 해결하여 렌더링 성능을 극대화하는 데 필수적인 역할을 합니다 [2-4].
-
-## 📖 구조화된 지식 (Synthesized Content)
-* **파티클 및 물리 시뮬레이션 처리 한계 돌파**
-  기존 CPU 기반 파티클 업데이트는 일반적인 하드웨어에서 약 50,000개 부근에서 성능 병목에 도달하지만, WebGPU 컴퓨트 셰이더를 사용하면 이를 수백만 개 단위로 확장할 수 있습니다 [2, 3]. 예를 들어, CPU에서 프레임당 30ms가 소요되던 10,000개의 파티클 업데이트 작업을 컴퓨트 셰이더로 전환하면 100,000개의 파티클을 2ms 이내에 업데이트할 수 있어 약 150배의 성능 향상을 얻을 수 있습니다 [4]. 또한, 대규모 유체 시뮬레이션 및 물리 연산에도 탁월한 성능을 발휘합니다 [5, 6].
-
-* **고급 데이터 처리 및 GPU 주도 렌더링(GPU-driven Rendering)**
-  컴퓨트 셰이더는 충돌 감지(Collision detection), 실시간 조명, 대규모 BIM 데이터셋의 실시간 필터링 등 다수의 데이터 스트림을 병렬로 처리하는 데 유용합니다 [1, 3, 4]. 실시간 편집이 가능한 대규모 절차적 지형(Procedural terrain)을 생성하거나 [6], 컴퓨트 셰이더의 출력을 기반으로 GPU가 렌더링 대상을 직접 결정하는 간접 그리기(Indirect draws)를 수행하여 수백만 개의 인스턴스와 가시성 컬링(Culling)을 효율적으로 처리할 수 있습니다 [7, 8].
-
-* **컴퓨트 스키닝 (Compute Skinning)**
-  컴퓨트 셰이더는 컴퓨트 단계에서 메쉬 정점 변환을 처리하여 그 결과를 버퍼에 저장할 수 있게 해줍니다 [4]. 이렇게 저장된 데이터는 다수의 렌더링 패스에서 재사용할 수 있어 중복 계산을 없앨 수 있으며, 조립 과정을 보여주는 애니메이션 처리 등에 매우 효율적입니다 [4]. 
-
-* **핵심 구현 메커니즘 및 동기화 최적화**
-  * **스토리지 텍스처(Storage textures):** 일반 텍스처와 달리 읽기와 쓰기를 모두 허용하여 컴퓨트 셰이더 내에서 유체 시뮬레이션 및 이미지 처리 작업이 가능하게 합니다 [5, 9].
-  * **작업 그룹 공유 메모리(Workgroup shared memory):** 스레드 간 데이터 공유가 필요할 때 전역 메모리보다 10~100배 빠른 접근 속도를 제공합니다 [6, 7].
-  * **렌더링 동기화 및 이중 버퍼링:** 컴퓨트 셰이더가 포함된 씬은 GPU 작업이 종속된 렌더링 패스 이전에 완료되도록 `renderAsync`를 사용하여 비동기 렌더링을 수행해야 합니다 [10]. 또한 성능을 높이려면 스테이징 버퍼(Staging buffers)를 활용한 이중 버퍼링(Double-buffering) 기법을 사용해야 하며, 파이프라인 지연을 방지하기 위해 디스패치 간에 `await mapAsync()` 사용을 피해야 합니다 [11].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Graphics & Performance 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[WebGPU]], [[GPU-driven Rendering]], [[TSL (Three Shader Language)]], [[Storage Textures]]
-- **Projects/Contexts:** [[Three.js WebGPURenderer]], [[Native WebGPU]], [[대규모 건설/BIM 플랫폼 (Large-Scale Construction Viewers)]]
-- **Contradictions/Notes:** 컴퓨트 셰이더를 통한 GPU 병렬 연산은 압도적인 성능 향상을 가져오지만, 작업 디스패치 사이에 `await mapAsync()`를 무분별하게 사용하면 GPU 파이프라인이 멈추고 최대 60%의 시간 동안 GPU가 유휴 상태에 빠지는 성능 저하 역효과가 발생할 수 있으므로 주의해야 합니다 [11].
-
----
-*Last updated: 2026-04-19*
-- Raw Source: [[00_Raw/2026-04-20/컴퓨트 셰이더(Compute Shaders).md]]
----
diff --git a/Graphics & Performance/프래그먼트 바운드(Fragment-bound).md b/Graphics & Performance/프래그먼트 바운드(Fragment-bound).md
deleted file mode 100644
index a74dedb3..00000000
--- a/Graphics & Performance/프래그먼트 바운드(Fragment-bound).md	
+++ /dev/null
@@ -1,33 +0,0 @@
----
-id: P-REINFORCE-AUTO-8CAEFF
-category: "[[10_Wiki/💡 Topics/Graphics & Performance]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - 프래그먼트 바운드(Fragment-bound)"
----
-
-# [[프래그먼트 바운드(Fragment-bound)]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 프래그먼트 바운드(Fragment-bound)는 3D 렌더링 파이프라인에서 GPU의 프래그먼트(픽셀) 연산 부하가 극심해져 전체 렌더링 성능과 프레임 레이트(FPS)를 제한하는 병목 상태를 의미합니다. 주로 화면에 그려지는 객체들이 렌더링 순서대로 정렬되지 않아 동일한 픽셀 위치에 렌더링 계산이 여러 번 중첩되는 오버드로우(Overdraw) 현상으로 인해 발생합니다. 무거운 조명 연산이 포함된 재질을 사용할 때 이 상태에 더욱 쉽게 빠지게 됩니다 [1, 2].
-
-## 📖 구조화된 지식 (Synthesized Content)
-- **발생 원인과 오버드로우(Overdraw):** 프래그먼트 바운드 상태는 렌더링 파이프라인의 후반부인 프래그먼트 셰이딩(Fragment Shading) 단계의 과부하로 발생합니다. 주된 원인은 오버드로우로, 불투명한 물체를 '앞에서 뒤로(Front-to-Back)' 정렬하지 않고 렌더링하여 뒤에 가려질 픽셀에 대해서도 GPU가 불필요한 계산을 중복해서 수행할 때 일어납니다 [2].
-- **InstancedMesh의 구조적 한계:** `InstancedMesh` 기술은 드로우 콜(Draw Call)을 줄여 CPU 오버헤드를 낮추는 데 효과적이지만, 인스턴스들에 대한 자동 정렬 기능을 제공하지 않습니다 [1, 2]. 따라서 카메라에서 멀리 있는 인스턴스가 먼저 그려지고 가까운 인스턴스가 나중에 그려지는 배치가 발생하면, 오버드로우 비용이 GPU의 픽셀 처리 성능을 상회하게 되어 프래그먼트 바운드 상태를 유발합니다 [2].
-- **재질(Material) 복잡도의 영향:** 오버드로우로 인한 프래그먼트 바운드 현상은 복잡한 조명 연산이 포함된 `MeshStandardMaterial`과 같은 무거운 재질을 사용할 때 그 심각성이 극대화됩니다 [1, 2].
-- **성능 개선 대안:** 프래그먼트 바운드 병목을 해결하기 위한 대안 중 하나로 `BatchedMesh`를 사용할 수 있습니다. `InstancedMesh`와 달리 `BatchedMesh`는 인스턴스들의 정렬(sorted)을 지원하므로 오버드로우를 효과적으로 줄일 수 있습니다 [1].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Graphics & Performance 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[오버드로우(Overdraw)]], [[InstancedMesh]], [[BatchedMesh]], [[프래그먼트 셰이딩(Fragment Shading)]]
-- **Projects/Contexts:** [[Three.js 렌더링 성능 최적화]], [[MeshStandardMaterial 조명 연산]]
-- **Contradictions/Notes:** 소스에 따르면 `InstancedMesh`는 CPU의 드로우 콜 병목을 해소하기 위해 도입되지만, 내부 정렬(Sorting)의 부재로 인해 오히려 GPU 측에서 프래그먼트 바운드라는 새로운 형태의 성능 병목을 유발할 수 있는 구조적 트레이드오프를 지니고 있습니다 [1, 2].
-
----
-*Last updated: 2026-04-19*
-- Raw Source: [[00_Raw/2026-04-20/프래그먼트 바운드(Fragment-bound).md]]
----
diff --git a/Graphics & Performance/프래그먼트 셰이딩(Fragment Shading).md b/Graphics & Performance/프래그먼트 셰이딩(Fragment Shading).md
deleted file mode 100644
index 7c53d55c..00000000
--- a/Graphics & Performance/프래그먼트 셰이딩(Fragment Shading).md	
+++ /dev/null
@@ -1,39 +0,0 @@
----
-id: P-REINFORCE-AUTO-CE737D
-category: "[[10_Wiki/💡 Topics/Graphics & Performance]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - 프래그먼트 셰이딩(Fragment Shading)"
----
-
-# [[프래그먼트 셰이딩(Fragment Shading)]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 프래그먼트 셰이딩(Fragment Shading)은 그래픽 렌더링 파이프라인의 후반부 단계로, 최종 색상 값을 결정하기 위해 픽셀 단위의 연산을 실행하는 과정이다 [1, 2]. 주로 텍스처 데이터 샘플링, 픽셀 단위 조명(per-pixel lighting), 알파(투명도) 값을 계산하여 표면의 디테일을 구현하는 역할을 수행한다 [1, 3, 4]. 화면에 보이는 픽셀에 대해 계산을 수행하므로, 픽셀이 중첩되어 여러 번 렌더링되는 오버드로우(Overdraw)가 발생하거나 복잡한 셰이더를 사용할 경우 GPU 성능 저하 및 프레임 지연의 주요 원인이 된다 [1, 2].
-
-## 📖 구조화된 지식 (Synthesized Content)
-- **역할 및 데이터 처리:** 
-  프래그먼트 셰이더는 정점 셰이더(Vertex Shader)로부터 Varying 변수를 통해 데이터를 전달받아 픽셀 단위로 처리한다 [5]. 이 셰이더는 픽셀 셰이딩이라 불리는 조명 계산, 노멀 맵을 활용한 미세한 표면 디테일 모사, 그리고 텍스처에 따른 알파(Alpha) 값 연산 등을 담당한다 [3, 4]. 이 밖에도 폰트 벡터 데이터를 바탕으로 프래그먼트 셰이더 내에서 직접 텍스트를 재렌더링하는 기법도 존재한다 [6, 7].
-
-- **성능 병목과 오버드로우(Overdraw):** 
-  여러 개의 텍스처 샘플링과 복잡한 수학적 연산 및 조건문이 포함된 PBR(Physically Based Rendering) 재질 같은 복잡한 셰이더는 중간 사양 GPU의 필 레이트(Fill rate)를 50~70%까지 감소시킬 수 있다 [1]. 특히 동일한 픽셀 위치에 여러 번 쓰기 작업이 중첩되는 오버드로우(Overdraw) 현상이 발생하면 씬(Scene) 전체가 '프래그먼트 바운드(Fragment-bound)' 상태에 빠져 심각한 프레임 처리 지연이 발생한다 [2].
-
-- **프래그먼트 셰이더 최적화 기법:**
-  - **거리 기반 및 가시성 최적화:** 동적 LOD(Level of Detail) 전환을 활용하면 픽셀 레벨의 GPU 프래그먼트 처리 연산을 60~75%가량 줄일 수 있다 [8]. 또한 뎁스 프리패스(Depth Pre-Pass)를 구현하면 GPU가 값비싼 메인 셰이더 연산에 진입하기 전에 가려진 프래그먼트를 미리 폐기(Discard)하여 프래그먼트 셰이더의 부하를 최대 30%까지 감소시킨다 [9].
-  - **재질(Material) 모델 단순화:** 연산량이 많은 `MeshStandardMaterial`은 프래그먼트 프로세서를 포화 상태로 만들 수 있으므로, 하드웨어 성능이 제한적인 환경에서는 픽셀별 스펙큘러 하이라이트만 제공하는 `MeshPhongMaterial`이나 조명 연산을 배제한 플랫 셰이딩(Flat Shaded) 커스텀 셰이더를 사용하여 프래그먼트 연산 비용을 최소화해야 한다 [10, 11].
-  - **절차적 렌더링(Procedural Rendering):** 엣지(Edge)나 와이어프레임을 그릴 때 별도의 기하학적 도형을 추가로 그리지 않고, 무게중심 좌표계(Barycentric Coordinate)를 이용해 프래그먼트 셰이더 내에서 절차적으로 엣지까지의 거리를 계산하여 렌더링하는 것이 훨씬 효율적이다 [12].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Graphics & Performance 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[Overdraw]], [[Vertex Shader]], [[Level of Detail (LOD)]], [[Physically Based Rendering (PBR)]]
-- **Projects/Contexts:** [[Three.js]], [[WebGL]]
-- **Contradictions/Notes:** 시각적인 현실감을 제공하는 PBR 모델의 재질은 사실적인 빛 반사를 구현하지만 프래그먼트 셰이더에서 수많은 연산과 텍스처 샘플링을 요구한다. 따라서 내장 GPU(iGPU)와 같은 저사양 하드웨어 환경에서는 성능을 크게 저하시키며, 오히려 연산량이 적은 Phong 모델이나 플랫 셰이딩 재질을 사용하는 것이 높은 프레임 레이트 유지를 위해 필수적이라고 소스는 설명한다 [1, 10, 11].
-
----
-*Last updated: 2026-04-19*
-- Raw Source: [[00_Raw/2026-04-20/프래그먼트 셰이딩(Fragment Shading).md]]
----
diff --git a/Graphics & Performance/헤드 마운트 디스플레이(HMD).md b/Graphics & Performance/헤드 마운트 디스플레이(HMD).md
deleted file mode 100644
index 8a067ac4..00000000
--- a/Graphics & Performance/헤드 마운트 디스플레이(HMD).md	
+++ /dev/null
@@ -1,32 +0,0 @@
----
-id: P-REINFORCE-AUTO-F31E1F
-category: "[[10_Wiki/💡 Topics/Graphics & Performance]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - 헤드 마운트 디스플레이(HMD)"
----
-
-# [[헤드 마운트 디스플레이(HMD)]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 헤드 마운트 디스플레이(HMD)는 사용자가 컴퓨터로 생성된 3D 가상 현실(VR) 또는 혼합 현실(MR) 환경과 상호작용할 수 있도록 머리에 착용하는 디스플레이 기기입니다 [1]. 이 기기들은 시각, 청각, 햅틱 등 다양한 감각 정보를 제공하여 높은 몰입감을 선사하지만, 높은 인지 부하(Cognitive Load)와 VR 멀미(VR Sickness)를 유발할 수 있는 부작용도 존재합니다 [2-4]. 최근의 HMD는 무선 사용, 풀 컬러 패스스루, 향상된 해상도 및 시야각을 갖추어 교육, 시뮬레이션 훈련, 엔터테인먼트 등 다양한 분야에서 널리 활용되고 있습니다 [5-7].
-
-## 📖 구조화된 지식 (Synthesized Content)
-* **HMD의 주요 특징 및 기술 발전:** 최근 시장을 주도하는 MR 및 VR HMD(예: Meta Quest Pro, Meta Quest 3, Apple Vision Pro, HTC Vive Pro 등)는 풀 컬러 패스스루(pass-through) 기능, 케이블 없이 독립적으로 구동되는 무선 사용 환경, 팬케이크 렌즈, 향상된 시야각(예: 수평 110도) 및 4K 이상의 고해상도를 지원합니다 [5, 7-10]. 또한 HMD에 내장된 카메라를 통해 사용자의 맨손을 추적(Hand tracking)함으로써 별도의 컨트롤러 없이도 자연스러운 인터랙션이 가능해졌습니다 [11].
-* **활용 목적 및 긍정적 효과:** HMD가 만들어내는 3D 디지털 환경은 사용자가 물리적으로 그곳에 존재하는 듯한 강렬한 '현존감(Presence)'을 부여합니다 [12, 13]. 이를 바탕으로 교육 현장에서는 현실에서 재현하기 힘든 가상 교실이나 실험실을 구현하며 [1], 의료 및 군사 시뮬레이션, 복잡한 데이터 시각화 등 작업 수행 능력과 인지적 학습 결과를 개선하는 데 사용됩니다 [6, 14]. 더불어 엑서게임(Exergaming) 등에서는 플레이어가 신체적 피로를 잊고 게임과 서사에 몰입하도록 돕는 핵심 장치로 기능합니다 [13].
-* **한계점 및 사용상 주의사항:** HMD 기반의 상호작용은 시각적, 청각적, 햅틱 정보를 동시에 쏟아내어 사용자의 작업 기억 용량을 초과하는 '인지 과부하(Cognitive overload)'를 초래할 수 있으며, 이는 의사결정과 학습 효율을 떨어뜨릴 수 있습니다 [2, 3]. 이와 함께 시각적 정보와 전정 기관의 신체적 경험 간의 불일치, 그리고 폭주-조절 불일치(vergence-accommodation conflicts)는 구역질, 방향 감각 상실, 안구 피로 등 'VR 멀미(VR Sickness)'를 일으키며, 이는 몰입도를 깨고 기기의 지속적인 채택을 방해하는 가장 큰 장벽으로 작용합니다 [4, 15].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Graphics & Performance 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[가상 현실(Virtual Reality)]], [[혼합 현실(Mixed Reality)]], [[인지 부하(Cognitive Load)]], [[VR 멀미(VR Sickness)]]
-- **Projects/Contexts:** [[비트 세이버(Beat Saber) 엑서게임 연구]], [[Meta Quest 시리즈 및 HTC Vive Pro 활용 사례]]
-- **Contradictions/Notes:** 소스에 관련 정보가 부족합니다.
-
----
-*Last updated: 2026-04-19*
-- Raw Source: [[00_Raw/2026-04-20/헤드 마운트 디스플레이(HMD).md]]
----
diff --git a/Graphics & Performance/헤드마운트 디스플레이 (HMD).md b/Graphics & Performance/헤드마운트 디스플레이 (HMD).md
deleted file mode 100644
index 9fbccd28..00000000
--- a/Graphics & Performance/헤드마운트 디스플레이 (HMD).md	
+++ /dev/null
@@ -1,33 +0,0 @@
----
-id: P-REINFORCE-AUTO-3585FE
-category: "[[10_Wiki/💡 Topics/Graphics & Performance]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - 헤드마운트 디스플레이 (HMD)"
----
-
-# [[헤드마운트 디스플레이 (HMD)]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 헤드마운트 디스플레이(HMD)는 사용자가 컴퓨터로 생성된 3D 환경과 상호작용할 수 있도록 머리에 착용하는 하드웨어 장치(헤드셋)로, 주로 가상현실(VR) 및 혼합현실(MR) 경험을 제공하는 데 사용됩니다 [1, 2]. 최근의 HMD는 시야각, 디스플레이 지연 시간, 해상도가 크게 개선되었으며, 풀 컬러 패스스루 및 독립형(standalone) 무선 사용과 같은 기술적 발전을 이루었습니다 [3-6]. 그러나 향상된 몰입감을 제공하는 반면, 과도한 인지 부하, 폭주-조절 불일치(vergence-accommodation conflict)로 인한 시각적 결함, 그리고 높은 VR 멀미(VR sickness) 발생률과 같은 사용자 경험의 과제도 함께 수반합니다 [7-9].
-
-## 📖 구조화된 지식 (Synthesized Content)
-- **기술적 발전 및 주요 기기:** 최신 HMD 장치로는 메타 퀘스트(Meta Quest) 2, 3, Pro 시리즈, 애플 비전 프로(Apple Vision Pro), HTC 바이브 프로(HTC Vive Pro) 등이 있습니다 [4, 10, 11]. 이들 기기는 데스크톱 PC에 연결할 필요 없는 독립형 모드, 고해상도(예: 눈당 1832 × 1920 픽셀, 90Hz), 넓은 시야각, 낮은 지연 시간 등을 바탕으로 사용자에게 최적화된 성능을 제공합니다 [5, 6, 11].
-- **적용 분야:** HMD는 사용자가 기존 미디어로는 불가능했던 방식으로 디지털 환경에 몰입할 수 있게 해줍니다 [1]. 주로 비트 세이버(Beat Saber)와 같은 엑서게임(Exergame) 플레이와 교육 현장에서의 현실적인 3D 시나리오 학습, 그리고 인지 및 신체 반응 시뮬레이션 등에 폭넓게 활용됩니다 [2, 10, 12].
-- **시각적 및 인지적 한계:** HMD 착용 시 망막의 깊이 지각 단서인 폭주(vergence)와 조절(accommodation)이 분리되는 불일치 현상이 발생할 수 있습니다 [13]. 이로 인해 두통, 눈의 통증, 피로, 복시와 같은 안구 운동 증상 및 시각적 피로가 유발될 수 있습니다 [8, 13]. 또한, 복잡한 가상 및 혼합현실 환경은 시각, 청각, 햅틱 정보를 동시에 처리해야 하므로 사용자에게 과도한 인지 부하(Cognitive Load)를 초래할 위험이 있습니다 [14, 15].
-- **VR 멀미(VR Sickness) 및 부작용:** HMD 기반 가상현실 연구에 따르면 사용자의 약 15.6%가 VR 멀미로 인해 사용을 중단하는 것으로 나타났습니다 [16]. 이러한 멀미는 시각적 경험과 신체적(전정 기관) 경험의 불일치, 시뮬레이션 된 움직임, HMD의 착용 핏, 연령, 자세의 안정성 등 다양한 요인에 의해 발생합니다 [8, 9, 17]. 이에 따라 HMD 제조사들은 사용 설명서를 통해 30분에서 1시간 단위로 사용 시간을 제한하거나 휴식을 취하도록 하는 안전 권장 사항을 명시하고 있습니다 [18].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Graphics & Performance 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[가상현실 (VR)]], [[혼합현실 (MR)]], [[VR 멀미 (VR Sickness)]], [[폭주-조절 불일치 (Vergence-Accommodation Conflict)]], [[인지 부하 (Cognitive Load)]]
-- **Projects/Contexts:** [[비트 세이버 (Beat Saber) 등 엑서게임]], [[교육 및 훈련용 VR 시뮬레이션]]
-- **Contradictions/Notes:** HMD는 대형 화면을 사용하는 것보다 사용자에게 훨씬 더 깊은 몰입감을 제공할 수 있는 수단이지만, 역설적으로 화면 기반 환경보다 시뮬레이터 멀미 설문지(SSQ) 점수가 실질적으로 더 높게 나타나 VR 멀미를 더 많이 유발한다는 취약점이 존재합니다 [9].
-
----
-*Last updated: 2026-04-19*
-- Raw Source: [[00_Raw/2026-04-20/헤드마운트 디스플레이 (HMD).md]]
----
diff --git a/Graphics/3D_Gaussian_Splatting.md b/Graphics/3D_Gaussian_Splatting.md
deleted file mode 100644
index 7d839564..00000000
--- a/Graphics/3D_Gaussian_Splatting.md
+++ /dev/null
@@ -1,29 +0,0 @@
----
-id: P-REINFORCE-3DGS-001
-category: "[[10_Wiki/💡 Topics/Graphics]]"
-confidence_score: 0.95
-tags: [graphics, rendering, ai]
-last_reinforced: 2026-04-20
-github_commit: "initial-reinforce"
----
-
-# [[3D Gaussian Splatting (3DGS)]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 포인트 클라우드를 넘어서 공간을 가속화된 가우시안 타원체로 표현함으로써 실시간 렌더링의 새로운 지평을 열다.
-
-## 📖 구조화된 지식 (Synthesized Content)
-- **추출된 패턴:** 복잡한 메시 구조 없이도 밀도 있는 포인트 클라우드에서 가우시안 파라미터를 최적화하여 사실적인 부피감을 구현하는 비선형 최적화 패턴.
-- **세부 내용:**
-    - 타일 기반의 가시성 정렬을 통한 고속 렌더링.
-    - 미분 가능한 렌더링(Differentiable Rendering)을 통한 파라미터 학습.
-    - NeRF 대안으로서의 압도적 렌더링 속도 확보.
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 메시에 기반한 전통적인 래스터화 방식과 개념적으로 충돌하나, 성능 면에서 우위를 점함.
-- **정책 변화:** 렌더링 효율성(w1) 가중치를 높게 평가하여 그래픽스 카테고리의 최상단 지식으로 배치.
-
-## 🔗 지식 연결 (Graph)
-- **Parent:** [[10_Wiki/💡 Topics/Graphics]]
-- **Related:** [[NeRF]], [[Point-Cloud]], [[Radiance-Fields]]
-- **Raw Source:** [[00_Raw/2026-04-20/3D Gaussian Splatting (3DGS).md]]
diff --git a/Graphics/3D_Web_HMI.md b/Graphics/3D_Web_HMI.md
deleted file mode 100644
index 8bf448ac..00000000
--- a/Graphics/3D_Web_HMI.md
+++ /dev/null
@@ -1,29 +0,0 @@
----
-id: P-REINFORCE-HMI-001
-category: "[[10_Wiki/💡 Topics/Graphics]]"
-confidence_score: 0.90
-tags: [web, hmi, interface, 3d]
-last_reinforced: 2026-04-20
-github_commit: "initial-reinforce"
----
-
-# [[3D Web-based HMI]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 산업용 제어 인터페이스를 브라우저 환경에서 3D로 시각화하여 정보의 직관성과 조작성을 극대화하다.
-
-## 📖 구조화된 지식 (Synthesized Content)
-- **추출된 패턴:** 물리적 장비의 디지털 트윈을 웹 소켓 기반 실시간 데이터와 바인딩하여 3D 공간에서 인터랙션을 구현하는 추상화 패턴.
-- **세부 내용:**
-    - Three.js/React Three Fiber를 활용한 저사양 기기 최적화.
-    - 실시간 텔레메트리 데이터의 가상화 매핑.
-    - 사용자 경험(UX) 중심의 직관적 물리 인터페이스 설계.
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 2D 평면 스카다(SCADA) 시스템에서 입체적 모니터링 환경으로의 전환.
-- **정책 변화:** 구조적 연결성(w2) 관점에서 디지털 트윈 아키텍처와 통합 분석 필요성 제기.
-
-## 🔗 지식 연결 (Graph)
-- **Parent:** [[10_Wiki/💡 Topics/Graphics]]
-- **Related:** [[Three.js]], [[Digital-Twin]], [[SCADA]]
-- **Raw Source:** [[00_Raw/2026-04-20/3D Web-based HMI.md]]
diff --git a/Graphics/Digital_Twin.md b/Graphics/Digital_Twin.md
deleted file mode 100644
index a248c676..00000000
--- a/Graphics/Digital_Twin.md
+++ /dev/null
@@ -1,29 +0,0 @@
----
-id: P-REINFORCE-GRAPHICS-003
-category: "[[10_Wiki/💡 Topics/Graphics]]"
-confidence_score: 0.92
-tags: [graphics, digital-twin, hmi, iot]
-last_reinforced: 2026-04-20
-github_commit: "batch-reinforce-04"
----
-
-# [[Digital Twin Interfaces]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 물리적 실체와 디지털 가상물을 실시간 데이터 혈류로 연결하여 예측 가능한 미래를 설계하는 인터페이스 기술.
-
-## 📖 구조화된 지식 (Synthesized Content)
-- **추출된 패턴:** IoT 센서 데이터의 가상화 매핑 및 실시간 렌더링을 통한 물리-가상 동기화 패턴.
-- **세부 내용:**
-    - 고해상도 3D 모델링과 실시간 텔레메트리의 결합.
-    - 시뮬레이션을 통한 장애 예측 및 선제적 유지보수 UI.
-    - 데이터 시각화를 넘어선 가상 환경에서의 물리적 조작성 확보.
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 정적인 3D 모델에서 살아 움직이는 '데이터 기반 생명체'로의 개념 진화.
-- **정책 변화:** 구조적 연결성(w2) 관점에서 3D_Web_HMI와의 기술적 통합 시너지 분석.
-
-## 🔗 지식 연결 (Graph)
-- **Parent:** [[10_Wiki/💡 Topics/Graphics]]
-- **Related:** [[3D_Web_HMI]], [[IoT]], [[Predictive-Maintenance]]
-- **Raw Source:** [[00_Raw/2026-04-20/Digital Twin Interfaces.md]]
diff --git a/Graphics/Predictive_Maintenance.md b/Graphics/Predictive_Maintenance.md
deleted file mode 100644
index 45986235..00000000
--- a/Graphics/Predictive_Maintenance.md
+++ /dev/null
@@ -1,29 +0,0 @@
----
-id: P-REINFORCE-GRAPHICS-004
-category: "[[10_Wiki/💡 Topics/Graphics]]"
-confidence_score: 0.93
-tags: [graphics, digital-twin, maintenance, ai]
-last_reinforced: 2026-04-20
-github_commit: "batch-reinforce-05"
----
-
-# [[Predictive Maintenance (PdM)]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 과거의 고장 패턴을 학습하여 미래의 이상 징후를 사전에 포착함으로써 시스템 가동 중단을 원천 차단하는 지능형 유지보수 체계.
-
-## 📖 구조화된 지식 (Synthesized Content)
-- **추출된 패턴:** 센서 데이터의 이상 탐지(Anomaly Detection)와 잔여 수명 예측(RUL)을 통해 정비 시점을 최적화하는 패턴.
-- **세부 내용:**
-    - 진동, 온도, 전력 소모 등 시계열 데이터의 특징 추출 및 분석.
-    - 확률론적 모델(Bayesian) 및 딥러닝(RNN/LSTM) 기반의 고장 확률 산출.
-    - 디지털 트윈과 결합하여 가상 환경에서 정비 시뮬레이션 수행.
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 고장 후 수리(Reactive)나 정기 점검(Preventive)에서 데이터 기반 실시간 대응(Predictive)으로의 전환.
-- **정책 변화:** 성능 가중치(w1) 관점에서 가동 시간(Uptime) 극대화를 위한 핵심 전략으로 배치.
-
-## 🔗 지식 연결 (Graph)
-- **Parent:** [[10_Wiki/💡 Topics/Graphics]]
-- **Related:** [[Digital_Twin]], [[Anomaly-Detection]], [[IoT]]
-- **Raw Source:** [[00_Raw/2026-04-20/Predictive Maintenance (PdM).md]]
diff --git a/Graphics/VPS_NeRF.md b/Graphics/VPS_NeRF.md
deleted file mode 100644
index ac6d1276..00000000
--- a/Graphics/VPS_NeRF.md
+++ /dev/null
@@ -1,29 +0,0 @@
----
-id: P-REINFORCE-GRAPHICS-005
-category: "[[10_Wiki/💡 Topics/Graphics]]"
-confidence_score: 0.94
-tags: [graphics, nerf, vps, navigation]
-last_reinforced: 2026-04-20
-github_commit: "batch-reinforce-05"
----
-
-# [[VPS & NeRF (Visual Positioning System)]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 이미지 기반의 정밀 위치 측정 기술과 신경망 기반 공간 재구성을 결합하여 현실 세계를 완벽한 디지털 좌표계로 변환하다.
-
-## 📖 구조화된 지식 (Synthesized Content)
-- **추출된 패턴:** 대규모 이미지 데이터셋에서 특징점을 추출하고, NeRF 기법을 통해 빈 공간의 시점을 보간하여 조밀한 공간 지도를 생성하는 패턴.
-- **세부 내용:**
-    - GPS의 한계를 넘어서는 cm 단위의 정밀한 야외/실내 위치 인식.
-    - Neural Radiance Fields를 활용한 사실적 공간 지도 생성 및 업데이트.
-    - AR(Augmented Reality) 서비스의 기반 기술로서의 공간 앵커링(Anchoring).
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 단순 포인트 클라우드 매칭에서 연속적인 신경망 공간 표현체로의 진화.
-- **정책 변화:** 기술적 가중치(w1)를 높게 설정하여 메타버스 카테고리의 핵심 브리지 지식으로 배치.
-
-## 🔗 지식 연결 (Graph)
-- **Parent:** [[10_Wiki/💡 Topics/Graphics]]
-- **Related:** [[CV_Synthesis]], [[3D_Gaussian_Splatting]], [[SLAM]]
-- **Raw Source:** [[00_Raw/2026-04-20/Visual Positioning Systems (VPS).md]]
diff --git a/Health & Science/ACL-Injury-Prevention-Protocols.md b/Health & Science/ACL-Injury-Prevention-Protocols.md
deleted file mode 100644
index c76baa6f..00000000
--- a/Health & Science/ACL-Injury-Prevention-Protocols.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AI-CEA4CC
-category: "[[10_Wiki/💡 Topics/Health & Science]]"
-confidence_score: 0.95
-tags: []
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Batch 9 - Wikified ACL-Injury-Prevention-Protocols"
----
-
-# [[ACL-Injury-Prevention-Protocols]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 
-
-## 📖 구조화된 지식 (Synthesized Content)
-
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 신규 문서로, 기존 정보와의 충돌 분석 예정.
-- **정책 변화:** Health & Science 카테고리의 지식 연결망 강화를 위한 표준 위키화 적용.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/ACL-Injury-Prevention-Protocols.md]]
----
diff --git a/Health & Science/Arthrokinematics.md b/Health & Science/Arthrokinematics.md
deleted file mode 100644
index ced5ab88..00000000
--- a/Health & Science/Arthrokinematics.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-EC0439
-category: "[[10_Wiki/💡 Topics/Health & Science]]"
-confidence_score: 0.95
-tags: []
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Mega Batch 2 - Wikified Arthrokinematics"
----
-
-# [[Arthrokinematics]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 작업 중
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 지식 자산화 및 기존 네트워크 연동 단계.
-- **정책 변화:** Health & Science 카테고리의 전문성 확보 및 링크 밀도 최적화.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Arthrokinematics.md]]
----
diff --git a/Health & Science/Athletic Peak Performance.md b/Health & Science/Athletic Peak Performance.md
deleted file mode 100644
index af186aea..00000000
--- a/Health & Science/Athletic Peak Performance.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-7BA64D
-category: "[[10_Wiki/💡 Topics/Health & Science]]"
-confidence_score: 0.95
-tags: []
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Mega Batch 2 - Wikified Athletic Peak Performance"
----
-
-# [[Athletic Peak Performance]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 작업 중
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 지식 자산화 및 기존 네트워크 연동 단계.
-- **정책 변화:** Health & Science 카테고리의 전문성 확보 및 링크 밀도 최적화.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Athletic Peak Performance.md]]
----
diff --git a/Health & Science/Biomedical-Engineering.md b/Health & Science/Biomedical-Engineering.md
deleted file mode 100644
index e911c682..00000000
--- a/Health & Science/Biomedical-Engineering.md	
+++ /dev/null
@@ -1,29 +0,0 @@
----
-id: P-REINFORCE-AI-058
-category: "[[10_Wiki/💡 Topics/Health & Science]]"
-confidence_score: 0.97
-tags: [biomedical engineering, biomechanics, medical device, robotics]
-last_reinforced: 2026-06-XX
-github_commit: "[P-Reinforce] Processed Biomedical-Engineering."
----
-
-# [[Biomedical-Engineering]] (생체 의학 공학)
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 생명 과학적 지식(Biology)과 공학 기술(Engineering)을 융합하여, 인체의 문제를 진단하고 치료하며 기능을 보조하는 의료 장비 및 시스템을 설계하는 학문이다.
-
-## 📖 구조화된 지식 (Synthesized Content)
-- **핵심 분야:** 생체 신호를 측정/해석하는 것부터 시작하여, 이를 기계적으로 교정하거나 대체하는 데까지 포괄한다.
-    1. **신호 처리 및 진단:** EEG(뇌파), EMG(근전도) 등 생체 신호를 측정하고 노이즈를 제거하며 의미 있는 정보를 추출하는 과정 (Signal Processing).
-    2. **운동학/역학:** 인체의 움직임을 수학적으로 모델링하여, 부상이나 기능 저하의 원인을 분석한다 (Biomechanics).
-    3. **장치 개발 및 제어:** 보조 공학(Assistive Technology)을 개발하고, 로봇 공학에 접목하여 운동 기능을 대체/강화하는 시스템을 구축한다.
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 의료 분야는 윤리적 문제와 법규(Regulatory Affairs)가 가장 큰 제약이다. 기술의 우수성만으로는 상용화될 수 없으며, 임상 시험 및 규제 준수가 필수적임을 인지해야 한다.
-- **정책 변화:** AI 기반으로 방대한 의료 데이터를 학습하여 진단 정확도를 높이는 것이 중요해지고 있으며, 개인정보보호(HIPAA 등)와 결합된 데이터 보안 아키텍처가 핵심 트렌드이다.
-
-## 🔗 지식 연결 (Graph)
-- Parent: [[Biomedical-Engineering]]
-- Related: [[Biomechanics]] , [[Assistive Technology]] , [[Signal Processing]]
-- Raw Source: [[00_Raw/Biomedical-Engineering.md]]
----
\ No newline at end of file
diff --git a/Health/ACL_Prevention.md b/Health/ACL_Prevention.md
deleted file mode 100644
index a4921dad..00000000
--- a/Health/ACL_Prevention.md
+++ /dev/null
@@ -1,29 +0,0 @@
----
-id: P-REINFORCE-HEALTH-001
-category: "[[10_Wiki/💡 Topics/Health]]"
-confidence_score: 0.89
-tags: [health, sports, injury, prevention]
-last_reinforced: 2026-04-20
-github_commit: "batch-reinforce-01"
----
-
-# [[ACL Injury Prevention Protocols]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 전방십자인대 부상 위험을 최소화하기 위해 바이오메카닉 분석과 신경근 훈련을 결합한 과학적 예방 체계.
-
-## 📖 구조화된 지식 (Synthesized Content)
-- **추출된 패턴:** 점프 착지 및 방향 전환 시 무릎 정렬을 최적화하는 신경근 제어(Neuromuscular Control) 강화 패턴.
-- **세부 내용:**
-    - 고유수용성 감각(Proprioception) 훈련을 통한 관절 안정화.
-    - 햄스트링 강화 및 콰드-햄스트링 균형 최적화.
-    - 연령 및 성별에 따른 맞춤형 부상 방지 프로그램 설계.
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 단순 근력 강화에서 움직임의 질(Quality of Movement) 중심 예방으로 진화.
-- **정책 변화:** 지식 연결성(w2) 관점에서 바이오메카닉과 스포츠 심리학의 연계성 강화.
-
-## 🔗 지식 연결 (Graph)
-- **Parent:** [[10_Wiki/💡 Topics/Health]]
-- **Related:** [[Neuromuscular-Control]], [[Sports-Science]], [[Proprioception]]
-- **Raw Source:** [[00_Raw/2026-04-20/ACL-Injury-Prevention-Protocols.md]]
diff --git a/Infrastructure & Automation/Edge Computing.md b/Infrastructure & Automation/Edge Computing.md
deleted file mode 100644
index 02df04fb..00000000
--- a/Infrastructure & Automation/Edge Computing.md	
+++ /dev/null
@@ -1,33 +0,0 @@
----
-id: P-REINFORCE-AI-043
-category: "[[10_Wiki/💡 Topics/Infrastructure & Automation]]"
-confidence_score: 0.98
-tags: [edge, computing, iot, distributed]
-last_reinforced: 2026-06-XX
-github_commit: "[P-Reinforce] Processed Edge_Computing.md"
----
-
-# [[Edge Computing]] (엣지 컴퓨팅)
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 데이터 생성 지점(엣지 디바이스) 근처에서 데이터를 처리하고 분석하여, 네트워크 병목 현상과 낮은 지연 시간을 해결하는 분산 컴퓨팅 아키텍처이다.
-
-## 📖 구조화된 지식 (Synthesized Content)
-- **정의:** 중앙 집중형 클라우드 서버를 거치지 않고, 최종 사용자 장치(IoT 센서, 스마트 디바이스 등)와 가까운 곳에서 데이터 처리 및 분석을 수행하는 컴퓨팅 모델.
-- **필요성 및 동기:** 
-    1. **Latency Criticality (저지연):** 자율 주행, 실시간 의료 모니터링 등 지연 시간에 민감한 서비스에 필수적이다. 클라우드 전송 시간을 최소화한다.
-    2. **Bandwidth Constraint (대역폭 제한):** 대규모 IoT 센서 데이터의 폭주를 줄이고 필터링하여 중앙 서버로 보내는 양을 최적화한다.
-    3. **Privacy & Security:** 민감 데이터를 로컬에서 처리하고 익명화할 수 있어 보안과 개인정보 보호 측면에서 유리하다.
-- **아키텍처 패턴:** 
-    - **지능형 계층 구조:** 센서(Level 1) $\rightarrow$ 게이트웨이/엣지 서버(Level 2, Edge Computing 수행) $\rightarrow$ 클라우드(Level 3, 대규모 학습 및 관리).
-    - **분산 컴퓨팅 기술 활용:** 컨테이너 오케스트레이션 (K3s, AWS IoT Greengrass 등)과 분산 데이터베이스가 주로 사용된다.
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 엣지 컴퓨팅이 클라우드를 대체하는 것이 아니라, '보완'하여 시스템의 전반적인 성능을 끌어올리는 개념임을 명확히 해야 한다. 하이브리드 아키텍처가 표준이다.
-- **정책 변화:** 에너지 효율성과 장치 자원 제약(Resource Constraints)을 고려한 경량화된 AI 모델 배포(TinyML) 기술이 중요한 트렌드로 부상하고 있다.
-
-## 🔗 지식 연결 (Graph)
-- Parent: [[Internet of Things (IoT) Telemetry]]
-- Related: [[Distributed-Systems-Engineering]] , [[Real-Time-Game-Engines]] , [[Autonomous Vehicle Perception]]
-- Raw Source: [[00_Raw/Edge_Computing.md]]
----
\ No newline at end of file
diff --git a/Memory & Systems/Allocation Timeline.md b/Memory & Systems/Allocation Timeline.md
deleted file mode 100644
index ba0b6a84..00000000
--- a/Memory & Systems/Allocation Timeline.md	
+++ /dev/null
@@ -1,35 +0,0 @@
----
-id: P-REINFORCE-B75DFC
-category: "[[10_Wiki/💡 Topics/Memory & Systems]]"
-confidence_score: 0.95
-tags: []
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Mega Batch - Wikified Allocation Timeline"
----
-
-# [[Allocation Timeline]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> **Allocation Timeline**(또는 Allocation instrumentation on timeline)은 Chrome DevTools의 Memory 패널에서 제공하는 프로파일링 도구로, 시간 경과에 따른 메모리 할당을 기록하고 추적하여 애플리케이션의 메모리 누수를 진단하는 데 사용됩니다 [1-3]. 이 도구는 힙 프로파일러(Heap Profiler)의 상세한 스냅샷 정보와 타임라인 패널의 증분 업데이트 및 추적 기능을 결합하여 객체의 생성 위치와 유지 경로(retaining path)를 실시간으로 식별할 수 있게 해줍니다 [2, 4, 5].
-
-## 📖 구조화된 지식 (Synthesized Content)
-- **동작 원리와 데이터 수집:** Allocation Timeline은 레코딩이 진행되는 동안 주기적으로(최대 50ms 단위로 자주) 힙 스냅샷을 캡처하고, 레코딩이 종료될 때 마지막 스냅샷을 한 번 더 찍어 데이터를 구성합니다 [3, 6, 7]. 할당된 각 객체에는 `@` 기호 뒤에 고유한 객체 ID가 부여되는데, 이 ID는 여러 스냅샷에 걸쳐 지속되므로 메모리 주소가 변경되더라도 힙 상태를 정확하게 비교할 수 있게 해줍니다 [6, 7].
-- **타임라인 시각화 및 막대(Bar)의 의미:** 타임라인 상단의 막대는 힙에서 새 객체가 할당된 시점과 그 크기(막대의 높이)를 나타냅니다 [3, 5, 8]. 
-  - **파란색 막대 (Blue bars):** 타임라인 종료 시점까지 가비지 컬렉션(GC)되지 않고 메모리에 여전히 살아있는(live) 객체를 의미합니다 [1, 3, 8, 9].
-  - **회색 막대 (Gray bars):** 타임라인 동안 할당되었으나 이후 가비지 컬렉터에 의해 성공적으로 수거되어 해제된 객체를 나타냅니다 [1, 3, 8, 9].
-- **메모리 누수(Memory Leak) 진단 과정:** 특정 사용자 작업(예: 할당 및 해제 버튼 클릭)을 반복할 때 **파란색 막대가 지속적으로 남는다면 이는 메모리 누수가 발생했을 가능성을 나타내는 주요 지표**입니다 [9, 10]. 분석 시 마우스를 드래그하여 특정 시간대로 확대(zoom in)하면, 해당 기간 동안 할당된 후 예상 수명을 넘겨 해제되지 않은 객체만 `Constructor` 창에 필터링하여 볼 수 있습니다 [1, 10-12].
-- **원인 식별 및 스택 트레이스 추적:** `Constructor` 창에서 특정 생성자를 클릭하면 `Retainers` 창에 해당 객체를 메모리에 유지시키는 참조 경로(retaining tree)가 표시됩니다 [11, 13]. 또한 할당된 타임라인 도구는 할당 당시의 스택 트레이스(stack trace)를 제공하므로, 개발자는 메모리 누수를 유발한 객체가 코드의 정확히 어느 부분에서 생성되었는지 파악하고 불필요한 참조를 수정할 수 있습니다 [1, 14, 15].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 지식 자산화 및 기존 네트워크 연동 단계.
-- **정책 변화:** Memory & Systems 카테고리의 전문성 확보 및 링크 밀도 최적화.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[Heap Snapshot]], [[Garbage Collection]], [[Memory Leak]], [[Retaining Path]], [[V8 Heap Architecture]]
-- **Projects/Contexts:** [[Chrome DevTools]], [[V8 Engine]]
-- **Contradictions/Notes:** 소스 전반에 걸쳐 내용의 모순은 없습니다. 다양한 소스가 일관되게 Allocation Timeline의 파란색/회색 막대의 의미와 메모리 누수를 추적하기 위한 스택 트레이스 및 Retainer 분석의 유용성을 강조하고 있습니다.
-
----
-*Last updated: 2026-04-19*
-- Raw Source: [[00_Raw/2026-04-20/Allocation Timeline.md]]
----
diff --git a/Metaverse & Devices/Apple Vision Pro Ecosystem.md b/Metaverse & Devices/Apple Vision Pro Ecosystem.md
deleted file mode 100644
index 53e44b13..00000000
--- a/Metaverse & Devices/Apple Vision Pro Ecosystem.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-546548
-category: "[[10_Wiki/💡 Topics/Metaverse & Devices]]"
-confidence_score: 0.95
-tags: []
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Mega Batch - Wikified Apple Vision Pro Ecosystem"
----
-
-# [[Apple Vision Pro Ecosystem]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 핵심 요약 작업 진행 중
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 상세 구성 진행 중
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 지식 자산화 및 기존 네트워크 연동 단계.
-- **정책 변화:** Metaverse & Devices 카테고리의 전문성 확보 및 링크 밀도 최적화.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Apple Vision Pro Ecosystem.md]]
----
diff --git a/Metaverse/Architecture.md b/Metaverse/Architecture.md
deleted file mode 100644
index a6ff9f14..00000000
--- a/Metaverse/Architecture.md
+++ /dev/null
@@ -1,29 +0,0 @@
----
-id: P-REINFORCE-METAVERSE-001
-category: "[[10_Wiki/💡 Topics/Metaverse]]"
-confidence_score: 0.88
-tags: [metaverse, architecture, digital-twin, spatial]
-last_reinforced: 2026-04-20
-github_commit: "batch-reinforce-03"
----
-
-# [[Metaverse Architecture]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 가상 공간의 물리적 제약을 넘어 사용자의 사회적 상호작용과 경제 활동을 최적화하는 디지털 공간 설계의 미학.
-
-## 📖 구조화된 지식 (Synthesized Content)
-- **추출된 패턴:** 실감형 렌더링, 네트워크 레이턴시 관리, 사용자 아바타 인터랙션을 하나로 엮는 공간 컴퓨팅 아키텍처 패턴.
-- **세부 내용:**
-    - 디지털 트윈 기술을 통한 현실 세계와의 동기화.
-    - 사용자 저작 도구(UGC)를 활용한 개방형 생태계 구축.
-    - 신뢰할 수 있는 가상 경제 시스템(Blockchain/Tokenomics)과의 결합.
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 단순 3D 게임 공간에서 현실의 연장선인 '지속적인 가상 세계'로 개념 확장.
-- **정책 변화:** 지식 구조(w2) 관점에서 게임 디자인 이론과의 융합 필요성 강조.
-
-## 🔗 지식 연결 (Graph)
-- **Parent:** [[10_Wiki/💡 Topics/Metaverse]]
-- **Related:** [[Digital-Twin]], [[Spatial-Computing]], [[Avatar-Interaction]]
-- **Raw Source:** [[00_Raw/2026-04-20/Metaverse Architecture.md]]
diff --git a/Metaverse/Spatial_Computing.md b/Metaverse/Spatial_Computing.md
deleted file mode 100644
index 7ff81a59..00000000
--- a/Metaverse/Spatial_Computing.md
+++ /dev/null
@@ -1,29 +0,0 @@
----
-id: P-REINFORCE-METAVERSE-002
-category: "[[10_Wiki/💡 Topics/Metaverse]]"
-confidence_score: 0.94
-tags: [metaverse, spatial-computing, ar, vr, xr]
-last_reinforced: 2026-04-20
-github_commit: "batch-reinforce-04"
----
-
-# [[Spatial Computing]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 화면 속에 갇혀 있던 디지털 정보를 우리가 발 딛고 서 있는 물리적 공간으로 끌어내어 확장하는 계산 패러다임.
-
-## 📖 구조화된 지식 (Synthesized Content)
-- **추출된 패턴:** 사용자의 시선, 손동작, 공간의 기하학적 구조를 인식하여 디지털 콘텐츠를 현실에 고정(Anchoring)하는 공간 인식 패턴.
-- **세부 내용:**
-    - SLAM(Simultaneous Localization and Mapping)을 기반으로 한 정밀 위치 추적.
-    - 6DOF(Degree of Freedom) 인터랙션 설계 표준.
-    - 가상과 현실이 중첩되는 혼합 현실(XR) 생태계의 UI/UX 문법.
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 2D 평면 기반 인터페이스(GUI)에서 공간 기반 인터페이스(ZUI/SUI)로의 대대적 이동.
-- **정책 변화:** 사용자 만족도(w3) 피드백에 따라 공간 피로도 감소를 위한 설계 지침 비중 상향.
-
-## 🔗 지식 연결 (Graph)
-- **Parent:** [[10_Wiki/💡 Topics/Metaverse]]
-- **Related:** [[Architecture]], [[MR]], [[SLAM]]
-- **Raw Source:** [[00_Raw/2026-04-20/Spatial Computing.md]]
diff --git a/Modern_Environment_Ecosystem.md b/Modern_Environment_Ecosystem.md
deleted file mode 100644
index 464820b5..00000000
--- a/Modern_Environment_Ecosystem.md
+++ /dev/null
@@ -1,26 +0,0 @@
----
-title: 모던 개발 환경 및 프레임워크 생태계
-category: Software Architecture
-tags: [Vite, Next.js, Ecosystem, Modern Stack]
-created: 2026-04-20
----
-
-# [[Modern_Environment_Ecosystem]] (모던 개발 생태계)
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 도구는 목적이 아니라 '생산성'을 위한 수단이다. 하지만 최신 생태계의 변화를 놓치는 것은 스스로 생산성을 깎아내는 것과 같다.
-
-## 📖 구조화된 지식 (Synthesized Content)
-- **Build Tools: Vite vs Webpack**:
-    - `Vite`는 네이티브 ESM을 활용하여 개발 서버 구동 속도를 혁신적으로 줄였다. 프로젝트 규모가 커질수록 Vite의 HMR(Hot Module Replacement) 속도는 빛을 발한다.
-- **Framework: Next.js (The Fullstack Edge)**:
-    - 단순히 SEO를 위한 SSR 도구가 아니다. API Routes를 통한 서버리스 함수 구현, 데이터 캐싱 전략(ISR/SSG) 등 현대 웹이 요구하는 거의 모든 기능을 탑재한 '거버넌스' 그 자체다.
-- **패키지 매니저의 선택**:
-    - `pnpm` 또는 `npm v7+`의 워크스페이스 기능을 통해 모노레포(Monorepo) 구조를 효율적으로 관리하고, 패키지 중복 설치를 최소화하여 빌드 성능을 최적화한다.
-
-## ⚠️ 모순 및 업데이트 (RL Update)
-- 최신 기술이 항상 정답은 아니다. 안정성이 최우선인 기업 환경에서는 검증된 `CRA` 혹은 `Webpack` 기반의 설정을 유지하는 것이 보수적인 면에서 유리할 수 있다. 기술 부채(Tech Debt)와 도입 비용을 항상 저울질하라.
-
-## 🔗 지식 연결 (Graph)
-- Related: [[Deployment_Final_Gate]] , [[Project_Architecture_Guidelines]]
-- Foundation: [[TypeScript_Type_Safety]]
diff --git a/Physics & Simulation/Aerospace Flight Simulation.md b/Physics & Simulation/Aerospace Flight Simulation.md
deleted file mode 100644
index 34b3f74c..00000000
--- a/Physics & Simulation/Aerospace Flight Simulation.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-FE444C
-category: "[[10_Wiki/💡 Topics/Physics & Simulation]]"
-confidence_score: 0.95
-tags: []
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Batch 10 - Wikified Aerospace Flight Simulation"
----
-
-# [[Aerospace Flight Simulation]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 핵심 내용 요약 예정
-
-## 📖 구조화된 지식 (Synthesized Content)
-세부 본문 내용 구성 예정
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 신규 지식 유입에 따른 기존 지식과의 정합성 검증 단계.
-- **정책 변화:** Physics & Simulation 분야의 체계적 지식 자산화 진행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Aerospace Flight Simulation.md]]
----
diff --git a/Programming & Formal Methods/Type Theory.md b/Programming & Formal Methods/Type Theory.md
deleted file mode 100644
index 4d1c1b5c..00000000
--- a/Programming & Formal Methods/Type Theory.md	
+++ /dev/null
@@ -1,30 +0,0 @@
----
-id: P-REINFORCE-AI-054
-category: "[[10_Wiki/💡 Topics/Programming & Formal Methods]]"
-confidence_score: 0.96
-tags: [type theory, formal verification, type system, compiler]
-last_reinforced: 2026-06-XX
-github_commit: "[P-Reinforce] Processed Type Theory."
----
-
-# [[Type Theory]] (타입 이론)
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 프로그래밍 언어의 타입 시스템을 수학적 공리(Axiom)와 논리학에 기반하여 분석하고, 프로그램의 안전성과 정확성을 컴파일 타임에 증명하는 학문이다.
-
-## 📖 구조화된 지식 (Synthesized Content)
-- **정의:** 타입을 단순히 데이터의 분류를 넘어, 시스템이 가질 수 있는 '속성'과 '규칙'으로 바라보는 접근법이다. 프로그램의 정적 분석을 수학적 증명 과정으로 확장한다.
-- **주요 개념:** 
-    1. **타입 추론 (Type Inference):** 코드를 작성할 때 타입을 명시하지 않아도 컴파일러가 타입 규칙에 따라 자동으로 타입을 유추하는 능력.
-    2. **계산 가능성(Computability) 및 안전성:** 타입 이론의 궁극적 목표는 프로그램이 어떤 조건에서도 예측 불가능한 오류 없이 동작함을 수학적으로 증명하는 것이다 (Formal Verification).
-    3. **Advanced Features:** 고급 언어 기능인 추상 데이터 타입, 범주론적 접근 등은 컴파일러 설계 자체를 학문적으로 다룬다.
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 완벽한 타입 안전성(Type Safety)을 달성하는 것은 매우 어려우며, 실제 개발에서는 '실용적인 타협점' (예: Runtime Validation, Zod 사용)이 필요하다.
-- **정책 변화:** 타입 시스템은 언어 차원의 기능뿐만 아니라, 도메인 모델링(DDD)의 규칙을 코드로 강제하는 도구로 활용되어 그 가치가 극대화되고 있다.
-
-## 🔗 지식 연결 (Graph)
-- Parent: [[Type Safety]]
-- Related: [[Formal Methods in Software Engineering]] , [[Algebraic-Data-Types]] , [[TypeScript Type System]]
-- Raw Source: [[00_Raw/Type Theory.md]]
----
\ No newline at end of file
diff --git a/Programming & Language/API 응답 및 에러 핸들링 아키텍처.md b/Programming & Language/API 응답 및 에러 핸들링 아키텍처.md
deleted file mode 100644
index 576101e7..00000000
--- a/Programming & Language/API 응답 및 에러 핸들링 아키텍처.md	
+++ /dev/null
@@ -1,37 +0,0 @@
----
-id: P-REINFORCE-AUTO-B2F9C0
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - API 응답 및 에러 핸들링 아키텍처"
----
-
-# [[API 응답 및 에러 핸들링 아키텍처]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> API 응답 및 에러 핸들링 아키텍처는 시스템 내에서 발생하는 에러를 예상 가능한 것과 그렇지 않은 것으로 구분하고, 이를 클라이언트에게 일관되고 예측 가능한 형태로 전달하기 위한 설계 방식입니다. 주로 '예외 던지기(throw exceptions)' 대신 명시적인 결과 객체(Result 타입)나 식별 가능한 유니온(Discriminated Unions)을 활용하여 타입 안전성을 확보하고, 컨트롤러 계층에서 응답의 제어 흐름을 명확히 관리하는 것을 목표로 합니다.
-
-## 📖 구조화된 지식 (Synthesized Content)
-*   **에러의 분류와 처리 철학**
-    에러는 애플리케이션 관점에서 '예상 가능한 에러(Expected errors)'와 '예상치 못한 에러(Unexpected errors/Defects)'로 나뉩니다 [1, 2]. 400 Bad Request나 504 Gateway Timeout 같은 예상 가능한 에러는 예외(Exception)로 던지기보다는 명시적인 에러 타입으로 반환하여 시스템이 복구 가능하도록 제어해야 합니다 [1].
-*   **Result 패턴을 통한 명시적 에러 반환**
-    에러 발생 시 무분별하게 예외를 던지면 제어 흐름을 파악하기 어렵고 타입 시스템에서 반환 타입을 명확히 알 수 없습니다 [3]. 이를 해결하기 위해 함수형 프로그래밍 언어에서 영감을 받은 `Result` 타입(예: `neverthrow` 라이브러리의 `Ok`, `Err`)을 사용하여, 함수가 어떤 에러를 발생시킬 수 있는지 명시적으로 선언하는 방식이 권장됩니다 [4-6]. 이 방식을 통해 컴파일러 수준에서 모든 에러 상황을 처리하도록 강제할 수 있습니다 [7].
-*   **식별 가능한 유니온(Discriminated Unions)을 이용한 응답 모델링**
-    API 응답을 다룰 때는 식별 가능한 유니온을 활용하는 것이 이상적입니다 [8, 9]. 응답 객체에 `status: "success"`나 `status: "error"`와 같은 공통 속성(판별자)을 두어 성공 시에는 데이터(data)를, 에러 시에는 에러 메시지(error)를 포함하도록 모델링하면, TypeScript의 완전성 검사(Exhaustiveness Checking)를 통해 처리되지 않은 상태가 없도록 컴파일 시점에 검증할 수 있습니다 [8, 9].
-*   **메타데이터 활용과 컨트롤러 중심의 제어 흐름**
-    응답 객체에 `_tag`와 같은 메타데이터 속성을 포함하여 내부 로직 및 응답 객체를 구분하면, 마이크로서비스 및 클라이언트 환경 간에 일관된 제어 흐름을 제공할 수 있습니다 [10, 11]. 또한 컨트롤러는 요청과 응답의 모든 흐름을 관리해야 하며, 전역 Catch-all 미들웨어는 비즈니스 로직의 제어 흐름을 담당하는 대신 오직 예상치 못한 결함을 처리하고 개발자에게 알리는 용도로만 사용해야 합니다 [12, 13].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[Result Type]], [[Discriminated Unions]], [[Exception Handling]]
-- **Projects/Contexts:** [[TypeScript API Development]], [[Server Architecture]]
-- **Contradictions/Notes:** 전역 예외 처리기(Global Exception Handler)를 두고 컨트롤러에서 예외를 발생시키는 방식이 코드가 깔끔해진다고 선호하는 개발자들도 있지만, Result 패턴을 지지하는 개발자들은 예외를 던지는 방식이 제어 흐름을 끊고 타입 시스템으로 에러를 파악할 수 없게 하므로 예상 가능한 에러는 명시적인 타입으로 반환해야 한다고 반대합니다 [7, 14-16].
-
----
-*Last updated: 2026-04-18*
-- Raw Source: [[00_Raw/2026-04-20/API 응답 및 에러 핸들링 아키텍처.md]]
----
diff --git a/Programming & Language/AST (추상 구문 트리).md b/Programming & Language/AST (추상 구문 트리).md
deleted file mode 100644
index b0254d67..00000000
--- a/Programming & Language/AST (추상 구문 트리).md	
+++ /dev/null
@@ -1,33 +0,0 @@
----
-id: P-REINFORCE-AUTO-7DEA60
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - AST (추상 구문 트리)"
----
-
-# [[AST (추상 구문 트리)]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> AST(추상 구문 트리)는 소스 코드를 파싱하여 얻어지는 코드의 추상적인 구문 및 문법적 구조를 표현하는 트리 형태의 데이터 구조입니다 [1, 2]. 이는 코드의 구문적 특성과 어휘적 특성을 보존하지만, 띄어쓰기나 들여쓰기와 같은 레이아웃(Layout) 특성은 캡처하지 못한다는 특징을 지닙니다 [2, 3]. AST는 코드 스타일을 분석하는 코드 문체론(Code Stylometry)이나 코드를 실행하지 않고 취약점을 탐지하는 정적 애플리케이션 보안 테스트(SAST) 등 다양한 소스 코드 분석 기술의 핵심적인 기반 모델로 활용됩니다 [2, 4].
-
-## 📖 구조화된 지식 (Synthesized Content)
-* **구조적 특성 및 추상화:** AST는 소스 코드를 구문 분석(Parsing)하여 프로그램의 문법적 구조를 트리로 모델링하여 생성됩니다 [4]. 구체 구문 트리(CST)와 비교했을 때 AST는 들여쓰기, 공백 등의 코드 레이아웃 특성을 생략하고 추상화합니다 [2]. 따라서 코드를 포맷팅하여 간격을 변경하거나 철저히 재들여쓰기(re-indent)를 수행하더라도 구문 분석 후에는 구조가 동일한 AST가 도출됩니다 [3].
-* **정적 애플리케이션 보안 테스트(SAST)에서의 활용:** SAST 도구는 프로그램의 구조와 구문을 평가할 때 소스 코드를 파싱하여 AST를 구축합니다 [4]. 구축된 AST 구조 위에서 다양한 분석 기법을 적용함으로써, 코드를 실제 실행하지 않고도 코딩 실수, 보안 취약점 및 성능 병목 현상과 같은 잠재적 문제들을 찾아냅니다 [4].
-* **코드 문체론(Code Stylometry) 및 작성자 식별:** 기계 학습 기반의 코드 문체론에서 AST는 개발자가 언어의 문법 구조를 어떻게 조직화하는지 나타내는 구문적 특징(Syntactic features)을 추출하는 수단으로 사용됩니다 [2]. AST 노드의 조합이나 노드 유형 기반의 특징들은 소스 코드 및 실행 파일로부터 작성자를 식별하는 강력한 지표로 활용됩니다 [5, 6]. 
-* **린팅(Linting) 등 도구에서의 활용:** 정적 분석을 돕는 ESLint와 같은 도구에서도 AST가 활용됩니다. 예를 들어 `eslint-plugin-jsx-a11y` 플러그인은 JSX 구조 내의 접근성 문제에 대하여 즉각적인 AST 린팅 피드백을 제공하여 개발자를 돕습니다 [7]. 또한, 디컴파일된 바이너리를 `Joern`과 같은 도구를 통해 파싱하여 AST를 구성한 뒤 다양한 코드 특징을 추출할 수도 있습니다 [6].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[CST (구체 구문 트리)]], [[SAST (정적 애플리케이션 보안 테스트)]], [[Code Stylometry (코드 문체론)]]
-- **Projects/Contexts:** [[ESLint]], [[Joern]]
-- **Contradictions/Notes:** 소스에 따르면 코드 작성자 식별(Authorship Attribution) 작업 시 AST 모델만을 사용하면 들여쓰기나 공백 등 개인의 레이아웃 코딩 스타일이 캡처되지 않는 한계가 있습니다 [2]. 실제로 실험 결과, AST 기반 접근 방식보다 이러한 레이아웃 요소를 포함하는 CST(구체 구문 트리)를 사용할 때 작성자 식별 정확도가 눈에 띄게(약 17%) 향상되는 것으로 나타납니다 [8, 9]. 
-
----
-*Last updated: 2026-04-18*
-- Raw Source: [[00_Raw/2026-04-20/AST (추상 구문 트리).md]]
----
diff --git a/Programming & Language/AST(Abstract Syntax Tree).md b/Programming & Language/AST(Abstract Syntax Tree).md
deleted file mode 100644
index f55bc9c5..00000000
--- a/Programming & Language/AST(Abstract Syntax Tree).md	
+++ /dev/null
@@ -1,37 +0,0 @@
----
-id: P-REINFORCE-AUTO-C7BE0D
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - AST(Abstract Syntax Tree)"
----
-
-# [[AST(Abstract Syntax Tree)]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> AST(Abstract Syntax Tree, 추상 구문 트리)는 소스 코드를 파싱하여 프로그래밍 언어의 문법적 구조를 트리 형태로 표현한 데이터 구조입니다. 공백이나 들여쓰기 같은 표면적인 레이아웃 정보는 배제하고 본질적인 구문 특징과 알고리즘 구조만을 보존하는 것이 특징입니다 [1]. 주로 SAST(정적 애플리케이션 보안 테스트), 린팅(Linting), 그리고 코드 작성자를 식별하는 코드 스타일로메트리(Code Stylometry) 분야에서 코드를 분석하는 핵심 기반으로 사용됩니다 [1, 2].
-
-## 📖 구조화된 지식 (Synthesized Content)
-* **AST의 구조적 특징 및 CST와의 차이**
-  AST는 소스 코드를 구문 분석(Parsing)하여 만들어지며, 컴파일러나 분석 도구가 코드를 이해하는 추상적인 뼈대 역할을 합니다 [1, 2]. 코드의 들여쓰기나 줄 바꿈 등 레이아웃 속성을 철저히 보존하는 CST(Concrete Syntax Tree)와 달리, AST는 이러한 레이아웃 특징을 무시합니다 [1, 3]. 따라서 코드를 포맷팅하거나 여백을 크게 수정하더라도 구문이 동일하다면 파싱 후 생성되는 AST의 구조는 변하지 않습니다 [3].
-
-* **정적 분석(Static Analysis) 및 보안 스캐닝에서의 역할**
-  소프트웨어의 취약점을 찾는 SAST 도구들은 소스 코드를 실행하지 않고 파싱하여 AST를 구축한 뒤, 여기에 다양한 분석 기법을 적용하여 코드의 논리적 오류와 보안 문제를 탐지합니다 [2]. 또한, `eslint-plugin-jsx-a11y`와 같은 린터 플러그인들은 AST를 기반으로 정적 검사를 수행해 코드 오류에 대한 즉각적인 피드백을 제공합니다 [4]. AI를 활용한 코드 리뷰 시스템 역시 조건문, 루프, try-catch 구조 등의 AST 노드 수를 인지하는 방식으로 코드의 구조적 복잡도를 계산합니다 [5].
-
-* **코드 스타일로메트리(작성자 식별)에서의 활용**
-  기계학습을 활용해 소스 코드의 작성자를 추적하는 '코드 스타일로메트리' 연구에서 AST는 작성자 고유의 구문적(Syntactic) 특성을 추출하는 표준적인 표현 방식으로 사용됩니다 [1, 6]. 작성자가 선호하는 문법 구조, 노드의 바이그램(bigram), 트리 전체의 노드 수, 너비와 깊이 등 AST 기반의 특징들은 표면적인 타이포그래피나 변수명보다 위조하기가 훨씬 어려워 작성자의 고유한 알고리즘적 특징을 포착하는 데 매우 중요하게 활용됩니다 [7-9].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[CST(Concrete Syntax Tree)]], [[정적 애플리케이션 보안 테스트(SAST)]], [[코드 스타일로메트리(Code Stylometry)]], [[정적 분석(Static Analysis)]]
-- **Projects/Contexts:** [[기계학습 기반의 소스 코드 저자 식별 연구]], [[AI 기반 코드 복잡도 분석(카카오)]], [[정적 보안 취약점 스캐닝 파이프라인]]
-- **Contradictions/Notes:** AST 기반의 분석은 작성자의 본질적인 프로그래밍 구조를 파악하고 위조 공격에 강하다는 장점이 있지만, 공백이나 들여쓰기 등 개발자의 개성이 묻어나는 '레이아웃 특징'을 담지 못합니다. 이로 인해 소스 코드 작성자 식별 실험에서 AST 기반 모델(51.00%)은 레이아웃 정보까지 포함하는 CST 기반 모델(67.86%)에 비해 상대적으로 낮은 정확도를 보였습니다 [10, 11].
-
----
-*Last updated: 2026-04-19*
-- Raw Source: [[00_Raw/2026-04-20/AST(Abstract Syntax Tree).md]]
----
diff --git a/Programming & Language/Abstract Syntax Tree (AST).md b/Programming & Language/Abstract Syntax Tree (AST).md
deleted file mode 100644
index e4f68822..00000000
--- a/Programming & Language/Abstract Syntax Tree (AST).md	
+++ /dev/null
@@ -1,37 +0,0 @@
----
-id: P-REINFORCE-AI-696634
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.95
-tags: []
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Batch 9 - Wikified Abstract Syntax Tree (AST)"
----
-
-# [[Abstract Syntax Tree (AST)]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 추상 구문 트리(AST, Abstract Syntax Tree)는 소스 코드를 파싱(Parsing)한 후 해당 언어의 문법적 구조를 계층적으로 표현한 트리 형태의 데이터 구조입니다 [1, 2]. 구체적 구문 트리(CST)와 달리 여백, 들여쓰기, 주석 등과 같은 레이아웃 및 스타일적 요소를 추상화하여 배제하며, 주로 소스 코드의 구문(syntax) 및 일부 어휘(lexical)적 특징만을 보존합니다 [1, 3, 4]. 이러한 특성 덕분에 주로 정적 애플리케이션 보안 테스트(SAST) 도구에서 오류를 분석하거나, 기계 학습을 통한 코드 저자 식별(Code Stylometry) 모델에서 코드를 표현하는 핵심 기반으로 폭넓게 활용됩니다 [1, 2, 5].
-
-## 📖 구조화된 지식 (Synthesized Content)
-* **AST의 기본 구조와 특징:** 
-  AST는 소스 코드를 구문 분석하여 생성되며, 개발자가 언어의 문법 구조를 어떻게 조직했는지를 나타냅니다 [1]. 코드 내에서 들여쓰기를 재조정하는 등 레이아웃이나 시각적 형태를 변경하는 소스 대 소스(source-to-source) 변환이 발생하더라도, 파싱 후 생성되는 AST의 구조는 동일하게 유지됩니다 [3]. 전처리 과정을 거친 AST 표현에서는 기본적으로 주석이나 지시어(directives)가 포함되지 않으며, 매크로 역시 확장되지 않은 상태로 맵핑됩니다 [4]. 또한, Eclipse와 같은 환경에서 AST 노드는 단순한 1대1 매핑 구조가 아니라, 구문적 역할에 따라 여러 AST 인터페이스를 다중으로 구현하는 등 복잡한 클래스 계층(다형성) 구조를 띠게 됩니다 [6].
-
-* **정적 애플리케이션 보안 테스트(SAST)에서의 활용:** 
-  정적 분석 기술은 프로그램을 실행하지 않고 소스 코드 자체를 평가하는 데 사용됩니다. 이 과정에서 SAST 도구들은 소스 코드를 파싱하여 추상 구문 트리(AST)를 구축합니다 [2]. 구축된 AST를 기반으로 다양한 분석 기법을 적용하여 코딩 실수, 보안 취약점, 성능 병목 현상 등 잠재적인 문제를 탐지해 냅니다 [2].
-
-* **코드 스타일로메트리(저자 식별)에서의 역할:** 
-  코드의 저자를 자동 식별하는 기계 학습 기반의 코드 스타일로메트리(Code Stylometry) 연구에서 AST는 소스 코드를 표현하는 주요 수단으로 쓰입니다 [1, 5]. AST는 레이아웃적 특징을 포착하지는 못하지만, 개발자 특유의 추상적인 구문적 특징과 본질적인 코딩 스타일을 추출하는 데 탁월합니다 [7]. 실제 연구에 따르면, 파싱된 코드의 AST 노드 유형의 유니그램(unigram) 빈도나 가능한 모든 AST 노드 바이그램(bigram)의 tf-idf 값 등은 특정 프로그래머를 식별하는 데 매우 강력하고 핵심적인 특징(Feature)으로 작용하는 것으로 보고되었습니다 [5, 8].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 신규 문서로, 기존 정보와의 충돌 분석 예정.
-- **정책 변화:** Programming & Language 카테고리의 지식 연결망 강화를 위한 표준 위키화 적용.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[Concrete Syntax Tree (CST)]], [[Static Application Security Testing (SAST)]], [[Code Stylometry]], [[Parsing]]
-- **Projects/Contexts:** [[기계 학습 기반 저자 식별 (Machine Learning-based Code Stylometry)]], [[Eclipse C/C++ Development Tools (CDT)]], [[코드 정적 분석 도구]]
-- **Contradictions/Notes:** 소스 코드의 본질적이고 구문적인 스타일을 분석하는 데는 AST가 핵심적으로 사용되지만, 코드의 들여쓰기, 공백과 같은 시각적 레이아웃 특징을 담아내지는 못합니다. 따라서 포맷팅이나 난독화 등이 프로그래머의 식별 가능성에 미치는 영향을 분석해야 할 경우에는 AST보다는 이를 모두 포함하는 구체적 구문 트리(CST)를 사용하는 것이 더 효과적이라는 지적이 있습니다 [1, 3, 7].
-
----
-*Last updated: 2026-04-19*
-- Raw Source: [[00_Raw/2026-04-20/Abstract Syntax Tree (AST).md]]
----
diff --git a/Programming & Language/Advanced-Design-Patterns-in-TypeScript.md b/Programming & Language/Advanced-Design-Patterns-in-TypeScript.md
deleted file mode 100644
index f1814798..00000000
--- a/Programming & Language/Advanced-Design-Patterns-in-TypeScript.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-82084D
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.95
-tags: []
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Batch 10 - Wikified Advanced-Design-Patterns-in-TypeScript"
----
-
-# [[Advanced-Design-Patterns-in-TypeScript]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 핵심 내용 요약 예정
-
-## 📖 구조화된 지식 (Synthesized Content)
-세부 본문 내용 구성 예정
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 신규 지식 유입에 따른 기존 지식과의 정합성 검증 단계.
-- **정책 변화:** Programming & Language 분야의 체계적 지식 자산화 진행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Advanced-Design-Patterns-in-TypeScript.md]]
----
diff --git a/Programming & Language/Albion Online (Full Loot_Player-Driven Production).md b/Programming & Language/Albion Online (Full Loot_Player-Driven Production).md
deleted file mode 100644
index dace6460..00000000
--- a/Programming & Language/Albion Online (Full Loot_Player-Driven Production).md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-DCA70F
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Albion Online (Full Loot_Player-Driven Production)"
----
-
-# [[Albion Online (Full Loot_Player-Driven Production)]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Albion Online (Full Loot_Player-Driven Production).md]]
----
diff --git a/Programming & Language/Algebraic-Data-Types-in-TypeScript.md b/Programming & Language/Algebraic-Data-Types-in-TypeScript.md
deleted file mode 100644
index 0fe9229f..00000000
--- a/Programming & Language/Algebraic-Data-Types-in-TypeScript.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-9FC7C3
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.95
-tags: []
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Batch 11 - Wikified Algebraic-Data-Types-in-TypeScript"
----
-
-# [[Algebraic-Data-Types-in-TypeScript]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 작업 중
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 신규 지식 카테고리화 및 연결성 강화.
-- **정책 변화:** Programming & Language 분야의 지식 자산 보호 및 네트워크 확장.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Algebraic-Data-Types-in-TypeScript.md]]
----
diff --git a/Programming & Language/Allocation Timeline(할당 타임라인).md b/Programming & Language/Allocation Timeline(할당 타임라인).md
deleted file mode 100644
index 8e1bd65a..00000000
--- a/Programming & Language/Allocation Timeline(할당 타임라인).md	
+++ /dev/null
@@ -1,30 +0,0 @@
----
-id: P-REINFORCE-AUTO-891010
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Allocation Timeline(할당 타임라인)"
----
-
-# [[Allocation Timeline(할당 타임라인)]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> Allocation Timeline(할당 타임라인)은 Chrome 및 Edge DevTools에서 제공하는 프로파일링 도구로, 적절하게 가비지 컬렉션(Garbage Collection)되지 않고 메모리를 계속 점유하는 객체를 찾아 메모리 누수를 추적하는 데 사용됩니다 [1, 2]. 이 도구는 힙 프로파일러의 상세한 스냅샷 정보와 타임라인 패널의 점진적 추적 기능을 결합하여, 기록 중 발생하는 모든 메모리 할당을 스택 트레이스와 함께 기록합니다 [1-3]. 결과적으로 시각적인 막대(파란색 및 회색)를 통해 메모리에 남아있는 객체와 이미 수거된 객체를 구별하여 보여줍니다 [3-5].
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[Garbage Collection]], [[Memory Leak]], [[Heap Snapshot]]
-- **Projects/Contexts:** [[Chrome DevTools]], [[V8 Engine]]
-- **Contradictions/Notes:** 소스에 관련 정보가 부족합니다.
-
----
-*Last updated: 2026-04-19*
-- Raw Source: [[00_Raw/2026-04-20/Allocation Timeline(할당 타임라인).md]]
----
diff --git a/Programming & Language/Ambient Contexts.md b/Programming & Language/Ambient Contexts.md
deleted file mode 100644
index f3745772..00000000
--- a/Programming & Language/Ambient Contexts.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-138364
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.95
-tags: []
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Mega Batch - Wikified Ambient Contexts"
----
-
-# [[Ambient Contexts]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 핵심 요약 작업 진행 중
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 상세 구성 진행 중
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 지식 자산화 및 기존 네트워크 연동 단계.
-- **정책 변화:** Programming & Language 카테고리의 전문성 확보 및 링크 밀도 최적화.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Ambient Contexts.md]]
----
diff --git a/Programming & Language/Ambient Declarations.md b/Programming & Language/Ambient Declarations.md
deleted file mode 100644
index 244c0401..00000000
--- a/Programming & Language/Ambient Declarations.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-F31A94
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.95
-tags: []
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Mega Batch - Wikified Ambient Declarations"
----
-
-# [[Ambient Declarations]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 핵심 요약 작업 진행 중
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 상세 구성 진행 중
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 지식 자산화 및 기존 네트워크 연동 단계.
-- **정책 변화:** Programming & Language 카테고리의 전문성 확보 및 링크 밀도 최적화.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Ambient Declarations.md]]
----
diff --git a/Programming & Language/AppSec (애플리케이션 보안).md b/Programming & Language/AppSec (애플리케이션 보안).md
deleted file mode 100644
index 42db74c5..00000000
--- a/Programming & Language/AppSec (애플리케이션 보안).md	
+++ /dev/null
@@ -1,33 +0,0 @@
----
-id: P-REINFORCE-AUTO-C35C99
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - AppSec (애플리케이션 보안)"
----
-
-# [[AppSec (애플리케이션 보안)]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 애플리케이션 보안(AppSec)은 잠재적인 위협과 취약점으로부터 소프트웨어 애플리케이션을 보호하기 위한 일련의 활동과 방식을 의미합니다 [1, 2]. 소프트웨어 개발 수명 주기(SDLC)의 모든 단계에 보안을 통합하여 코드가 프로덕션 환경에 배포되기 전에 코드 수준의 결함을 조기에 발견하고 수정하는 것을 목표로 합니다 [3, 4]. 이를 위해 SAST, DAST, SCA 등 다양한 자동화된 보안 테스트 도구와 인간의 수동 코드 리뷰를 결합하여 애플리케이션의 전반적인 보안 태세를 강화합니다 [4-6].
-
-## 📖 구조화된 지식 (Synthesized Content)
-* **주요 AppSec 도구 및 방법론:** AppSec은 포괄적인 보안을 제공하기 위해 여러 종류의 도구를 조합하여 사용합니다. 소스 코드 자체를 분석하여 논리적 취약점을 찾는 정적 애플리케이션 보안 테스트(SAST), 실행 중인 애플리케이션을 외부에서 테스트하여 런타임 문제를 잡는 동적 애플리케이션 보안 테스트(DAST), 오픈소스 및 서드파티 라이브러리의 알려진 취약점과 라이선스를 분석하는 소프트웨어 구성 분석(SCA), 그리고 런타임 환경에 내장되어 정적 분석과 동적 분석의 장점을 결합하는 대화형 애플리케이션 보안 테스트(IAST)가 대표적입니다 [4, 6-9].
-* **SDLC 통합 및 시프트 레프트(Shift-Left):** 현대 AppSec의 핵심은 취약점 탐지 및 조치 과정을 개발 초기 단계로 앞당기는 '시프트 레프트' 전략입니다 [10, 11]. IDE 플러그인이나 CI/CD 파이프라인, 풀 리퀘스트(PR) 단계에 보안 검사를 내장함으로써, 개발자가 코드를 작성하는 즉시 실시간으로 문제를 인지하고 수정할 수 있어 프로덕션 이후에 결함을 수정하는 것보다 시간과 비용을 크게 절감할 수 있습니다 [3, 10, 12, 13].
-* **AppSec에서의 AI 활용:** 인공지능(AI)과 대형 언어 모델(LLM)의 도입으로 AppSec 도구들은 단순한 규칙 기반 패턴 매칭을 넘어 코드의 문맥과 의미를 이해하는 수준으로 진화하고 있습니다 [14, 15]. AI 기반 정적 분석 도구들은 데이터 흐름(Data flow) 및 오염 분석(Taint analysis)을 통해 파일 간 경계를 넘나드는 복잡한 취약점을 파악하고, 오탐지(False Positive)율을 크게 낮춥니다 [16-18]. 나아가 취약점에 대한 자동 수정 코드(Auto-fix)를 생성하여 개발자의 워크플로우 내에서 즉각적인 픽스를 제안합니다 [18-20].
-* **수동 리뷰와 자동화 도구의 하이브리드 접근:** 자동화된 AppSec 도구는 확장성과 속도 면에서 뛰어나 수천 줄의 코드를 몇 초 만에 스캔하지만, 비즈니스 로직이나 아키텍처 설계의 의도를 파악하는 데는 한계(Context Blindness)가 있습니다 [21-23]. 따라서 강력한 보안을 위해서는 자동화 도구가 일상적인 구문 오류와 알려진 취약점(예: SQL 인젝션, XSS 패턴 등)을 일차적으로 걸러내고, 인간 리뷰어가 인증 로직, 데이터 암호화, 크로스 서비스 영향 등 컨텍스트와 도메인 전문성이 중요한 고위험 영역의 리뷰에 집중하는 하이브리드 접근 방식이 필수적입니다 [5, 24, 25].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[SAST (정적 애플리케이션 보안 테스트)]], [[DAST (동적 애플리케이션 보안 테스트)]], [[SCA (소프트웨어 구성 분석)]], [[SDLC (소프트웨어 개발 수명 주기)]]
-- **Projects/Contexts:** [[시프트 레프트(Shift-Left) 전략]], [[하이브리드 코드 리뷰 프로세스]]
-- **Contradictions/Notes:** 자동화된 AppSec 도구는 코드베이스 전체를 빠르고 일관되게 스캔하여 구문적 취약점을 찾아내지만, 비즈니스 로직이나 아키텍처의 의도를 이해하지 못해 오탐지(False Positives)를 유발할 수 있습니다. 따라서 도구에만 전적으로 의존하는 것은 위험하며, 복잡한 비즈니스 로직과 컨텍스트에 민감한 보안 위협을 식별하기 위해서는 반드시 인간 전문가에 의한 수동 코드 리뷰(Manual Code Review)가 병행되어야 한다고 소스들은 강조합니다 [23, 24, 26, 27].
-
----
-*Last updated: 2026-04-18*
-- Raw Source: [[00_Raw/2026-04-20/AppSec (애플리케이션 보안).md]]
----
diff --git a/Programming & Language/Assignability-Relation.md b/Programming & Language/Assignability-Relation.md
deleted file mode 100644
index 2161547f..00000000
--- a/Programming & Language/Assignability-Relation.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-E1BF3A
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.95
-tags: []
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Mega Batch 2 - Wikified Assignability-Relation"
----
-
-# [[Assignability-Relation]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 작업 중
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 지식 자산화 및 기존 네트워크 연동 단계.
-- **정책 변화:** Programming & Language 카테고리의 전문성 확보 및 링크 밀도 최적화.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Assignability-Relation.md]]
----
diff --git a/Programming & Language/Athletic-Performance-Optimization.md b/Programming & Language/Athletic-Performance-Optimization.md
deleted file mode 100644
index e6049a79..00000000
--- a/Programming & Language/Athletic-Performance-Optimization.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-18F4BB
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Athletic-Performance-Optimization"
----
-
-# [[Athletic-Performance-Optimization]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Athletic-Performance-Optimization.md]]
----
diff --git a/Programming & Language/Authorship Attribution.md b/Programming & Language/Authorship Attribution.md
deleted file mode 100644
index 16dff010..00000000
--- a/Programming & Language/Authorship Attribution.md	
+++ /dev/null
@@ -1,39 +0,0 @@
----
-id: P-REINFORCE-AUTO-750690
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Authorship Attribution"
----
-
-# [[Authorship Attribution]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-* **발전 배경과 개념:** 
-  저자 식별은 본래 손글씨나 문서의 물리적 특성을 주관적으로 감정하던 것에서 출발하여, 글의 내용과 어휘, 문법 등 '문체(Style)'를 통계적으로 분석하는 문체론(Stylometry)으로 발전했습니다 [3, 6, 7]. 1980년대 후반부터는 이 기법론이 소프트웨어에도 적용되기 시작하여, 프로그래머가 작성한 소스 코드나 실행 파일에서 고유한 프로그래밍 스타일을 추출하는 '코드 문체론(Code Stylometry)'으로 확장되었습니다 [1, 2].
-* **주요 식별 특징 (Features):**
-  코드 문체론에서는 작성자의 스타일을 크게 세 가지 범주로 나누어 분석합니다. 첫째, 문자와 단어의 사용 패턴을 보는 '어휘적(Lexical) 특징', 둘째, 파싱된 추상 구문 트리(AST)의 구조를 분석하는 '구문적(Syntactic) 특징', 셋째, 띄어쓰기와 들여쓰기 등을 포함하는 '레이아웃(Layout) 특징'입니다 [8]. 컴파일된 실행 파일(Binary)의 경우 레이아웃과 주석이 제거되지만, 데이터 구조의 선택, 시스템/라이브러리 호출 패턴, 제어 흐름 그래프(CFG), 레지스터 흐름 등을 통해 여전히 작성자를 식별할 수 있습니다 [9-12].
-* **응용 분야와 프라이버시 위협:**
-  이 기술은 코드 클론 탐지, 저작권 분쟁 해결, 표절 탐지(Plagiarism Detection) 및 유실된 저자 정보 복원 등에 매우 효과적으로 사용됩니다 [4, 13, 14]. 그러나 사이버 범죄자 추적을 넘어, 억압적인 정권 하에서 익명으로 검열 우회 도구나 프라이버시 강화 기술을 개발하는 오픈소스 기여자들의 신원을 노출시키는 데 악용될 수 있다는 심각한 우려가 제기되고 있습니다 [4, 5, 15, 16]. 
-* **코드 포맷팅과 축소화(Minification)의 영향:**
-  개발자들이 코드의 일관성을 위해 Black과 같은 코드 포맷터(Formatter)나, 파일 크기를 줄이기 위한 축소기(Minifier)를 사용하면 작성자 고유의 레이아웃 특징 등이 훼손되어 저자 식별의 정확도가 유의미하게 하락합니다 [17-20]. 연구에 따르면, 구체 구문 트리(CST) 기반 분석에서 포맷팅과 축소화를 거친 코드는 원본에 비해 식별 정확도가 최대 18%가량(68%에서 50% 수준으로) 떨어졌습니다 [20, 21]. 하지만 이러한 하락에도 불구하고 무작위 추측 확률에 비해서는 월등히 높은 정확도를 보였으며, 단순히 포맷팅이나 축소화를 적용하는 것만으로는 저자 식별을 완전히 피할 수 없다는 것이 확인되었습니다 [21-24].
-* **적대적 코드 문체론 (Adversarial Code Stylometry):**
-  저자 식별 기술에 대응하기 위해, 기계학습 모델(예: 랜덤 포레스트)의 결정 트리를 분석하여 자신의 코딩 스타일을 난독화(Obfuscation)하거나 다른 특정 개발자의 스타일을 정교하게 모방(Mimicry)하도록 돕는 연구가 진행되었습니다 [25, 26]. 이 기술을 자동화한 'StyleCounsel'과 같은 시스템은 사용자의 코드가 다른 사람의 코드로 오분류되도록 소스 코드 수정 권장 사항을 도출해 내며, 저자 식별 기술이 의도적인 조작에 취약할 수 있음을 입증했습니다 [25, 27, 28].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[Code Stylometry]], [[Plagiarism Detection]], [[Code Formatting]], [[Adversarial Code Stylometry]]
-- **Projects/Contexts:** [[Google Code Jam]] (소스 코드 저자 식별 연구에서 광범위하게 사용되는 주요 데이터셋), [[StyleCounsel]] (적대적 저자 식별 회피를 돕기 위해 개발된 도구)
-- **Contradictions/Notes:** 소스코드가 컴파일되면 주석, 들여쓰기, 변수명 등이 파괴되므로 작성자의 흔적이 사라질 것이라 예상하기 쉽지만, 실제로는 컴파일러 최적화 수준과 관계없이 실행 파일 내 제어 흐름과 데이터 구조 선택 방식 등의 정보가 남아 있어 상당한 정확도로 저자 식별(Executable Code Attribution)이 가능합니다 [29, 30]. 또한, 포맷터와 Minifier의 사용이 코드 문체론을 교란하기는 하나 식별을 완벽히 방어해주지는 못합니다 [24, 31].
-
----
-*Last updated: 2026-04-19*
-- Raw Source: [[00_Raw/2026-04-20/Authorship Attribution.md]]
----
diff --git a/Programming & Language/Autotelic Personality.md b/Programming & Language/Autotelic Personality.md
deleted file mode 100644
index f696bfab..00000000
--- a/Programming & Language/Autotelic Personality.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-75E436
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Autotelic Personality"
----
-
-# [[Autotelic Personality]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Autotelic Personality.md]]
----
diff --git a/Programming & Language/Autotelic-Personality.md b/Programming & Language/Autotelic-Personality.md
deleted file mode 100644
index 1f3164a1..00000000
--- a/Programming & Language/Autotelic-Personality.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-13B1BE
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Autotelic-Personality"
----
-
-# [[Autotelic-Personality]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Autotelic-Personality.md]]
----
diff --git a/Programming & Language/BM25 알고리즘 (Best Match 25).md b/Programming & Language/BM25 알고리즘 (Best Match 25).md
deleted file mode 100644
index 3d0bec71..00000000
--- a/Programming & Language/BM25 알고리즘 (Best Match 25).md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-CA15D0
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - BM25 알고리즘 (Best Match 25)"
----
-
-# [[BM25 알고리즘 (Best Match 25)]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/BM25 알고리즘 (Best Match 25).md]]
----
diff --git a/Programming & Language/Beat Saber 엑서게임 연구(Beat Saber Exergaming Study).md b/Programming & Language/Beat Saber 엑서게임 연구(Beat Saber Exergaming Study).md
deleted file mode 100644
index 963c4ea3..00000000
--- a/Programming & Language/Beat Saber 엑서게임 연구(Beat Saber Exergaming Study).md	
+++ /dev/null
@@ -1,39 +0,0 @@
----
-id: P-REINFORCE-AUTO-C3E3B9
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Beat Saber 엑서게임 연구(Beat Saber Exergaming Study)"
----
-
-# [[Beat Saber 엑서게임 연구(Beat Saber Exergaming Study)]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 이 연구는 전 세계적으로 인기 있는 상업용 VR 엑서게임인 '비트 세이버(Beat Saber)'를 짧은 시간(10분)과 긴 시간(50분) 동안 플레이했을 때 사용자의 시력, 인지 능력, 그리고 주관적 VR 멀미에 미치는 사후 영향(aftereffects)을 조사한 연구이다 [1], [2], [3]. VR 엑서게임은 신체 활동을 장려하는 잠재력이 크지만, 사용자가 겪는 멀미나 시각적/인지적 후유증이 그 활용을 제한할 수 있기 때문에 이에 대한 안전성과 회복 시간을 파악하는 것을 목적으로 한다 [1], [4].
-
-## 📖 구조화된 지식 (Synthesized Content)
-* **연구 설계 및 참가자:** 
-  연구는 36명의 참가자를 대상으로 수행되었으며, 참가자들은 HTC Vive Pro HMD를 착용하고 비트 세이버를 플레이했다 [2], [5]. 참가자들은 각각 다른 날에 10분(짧은 노출)과 50분(긴 노출) 동안 게임을 수행하는 반복 측정 개체 내 설계(repeated measures within-subject design) 방식으로 실험에 참여했다 [2], [6].
-* **측정 지표 및 시점:** 
-  시력(조절 및 폭주), 인지 능력(CANTAB 5선택 반응 시간), 그리고 주관적 VR 멀미(시뮬레이터 멀미 설문지, SSQ) 지표를 VR 노출 전, 노출 직후, 그리고 노출 40분 후(지연 측정) 등 총 3번의 시점에 걸쳐 측정했다 [2], [7], [8], [9].
-* **시력 및 인지 부문 결과:** 
-  멀미로 인해 실험을 중도 포기한 참가자는 없어 게임의 내약성은 긍정적으로 평가되었다 [10], [11]. 시각의 조절(accommodation) 및 폭주(convergence) 기능은 노출 시간에 관계없이 게임 직후에 변화를 보였으나, 40분 후에는 모두 기준치로 회복되었다 [10]. 인지적 측면인 반응 시간에서는 우려할 만한 저하가 관찰되지 않았으며, 오히려 10분 노출 직후에는 참가자들의 움직임 속도가 약간 빨라진 것으로 나타났다 [10], [12].
-* **VR 멀미(SSQ) 부문 결과:** 
-  총 SSQ 점수는 VR 노출 직후 급격히 증가했으며, 10분 노출에 비해 50분 노출에서 유의미하게 더 높은 멀미 증상이 보고되었다 [10], [13]. 전반적인 그룹 평균으로 보면 40분 후에는 멀미 점수가 기준치로 떨어졌으나, 50분 노출 그룹의 약 14%(7명 중 1명 꼴)는 40분이 지난 시점에서도 여전히 높은 수준의 멀미를 호소했다 [10], [14]. 또한 짧은 노출에서 멀미를 크게 느낀 참가자는 긴 노출에서도 심한 증상을 겪을 확률이 거의 확실한 것으로 나타났다 [10], [4].
-* **안전 권고사항:** 
-  이러한 결과를 바탕으로, 연구진은 사용자가 긴 시간 VR을 플레이하기 전에 짧은 세션으로 미리 테스트해 볼 것을 권장한다 [4]. 또한, VR 기기 사용을 마친 후 운전과 같이 부상 위험을 초래할 수 있는 활동을 수행하기 전에는 멀미 후유증이 완전히 사라질 수 있도록 충분한 대기 시간(예: 최소 40분 이상)을 가져야 한다고 조언한다 [4].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[가상현실(VR)]], [[엑서게임(Exergaming)]], [[VR 멀미(VR Sickness)]], [[시뮬레이터 멀미 설문지(SSQ)]]
-- **Projects/Contexts:** [[비트 세이버(Beat Saber)]]
-- **Contradictions/Notes:** 그룹 전체의 평균 데이터를 보면 40분의 휴식 후 멀미 수치가 원래 수준으로 회복되는 것처럼 보이지만, 개인 단위의 데이터를 살펴보면 50분 플레이 후 약 14%의 사용자는 여전히 심각한 수준의 멀미를 경험하므로 평균 수치만으로 부작용이 완전히 사라졌다고 단정하기는 어렵다 [10], [14].
-
----
-*Last updated: 2026-04-19*
-- Raw Source: [[00_Raw/2026-04-20/Beat Saber 엑서게임 연구(Beat Saber Exergaming Study).md]]
----
diff --git a/Programming & Language/Beat Saber.md b/Programming & Language/Beat Saber.md
deleted file mode 100644
index e248b044..00000000
--- a/Programming & Language/Beat Saber.md	
+++ /dev/null
@@ -1,32 +0,0 @@
----
-id: P-REINFORCE-AUTO-711498
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Beat Saber"
----
-
-# [[Beat Saber]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 'Beat Saber'는 모션 트래킹 기술을 활용해 플레이어가 가상현실 속에서 광선검을 휘둘러 리듬에 맞춰 표적을 베고 장애물을 피하는 인기 VR 리듬 엑서게임(Exergame)입니다 [1]. 전 세계적으로 200만 장 이상 판매된 성공적인 상업 게임으로, 햅틱 및 시청각 피드백을 통해 높은 몰입감을 제공합니다 [1, 2]. 실제 테니스와 맞먹는 에너지 소모량을 바탕으로 신체 활동을 돕는 유용한 도구로 인정받고 있으며, VR 멀미(VR sickness) 및 몰입 상태(Flow state)를 분석하는 학술 연구에서도 널리 활용되고 있습니다 [2, 3].
-
-## 📖 구조화된 지식 (Synthesized Content)
-- **게임의 특징과 신체적 효과:** Beat Games에서 개발한 Beat Saber는 플레이어에게 햅틱, 청각, 그리고 성과 기반 피드백을 제공하여 강렬한 몰입감을 선사합니다 [1]. 가상현실 건강 및 운동 연구소(VR Health Institute)에 따르면, 이 게임을 플레이할 때 소모되는 에너지는 실제 테니스를 치는 것과 유사합니다 [2]. 사용자들은 몰입형 환경이 운동의 힘든 강도로부터 주의를 분산시켜 주며, 현실에서의 운동과 비슷한 신체 활동 효과를 얻을 수 있다고 평가합니다 [4].
-- **VR 사후 효과(Aftereffects) 및 멀미 연구 도구:** 이 게임은 단기(10분) 및 장기(50분) VR 노출이 사용자의 시각, 인지, 웰빙 및 VR 멀미에 미치는 영향을 조사하는 연구의 테스트 베드로 사용되었습니다 [2, 5]. 연구 결과, Beat Saber는 멀미로 인한 중도 포기자가 발생하지 않을 정도로 전반적으로 플레이어들에게 잘 수용되는(well tolerated) 것으로 나타났습니다 [6, 7]. 발생하는 즉각적인 사후 효과 역시 대부분 일시적이었으며 게임 종료 40분 후 기저 수준으로 회복되었으나, 장시간(50분) 플레이한 일부 참가자(약 14%)는 회복 후에도 여전히 높은 수준의 멀미를 경험한 것으로 확인되었습니다 [6, 8].
-- **몰입(Flow) 상태 유도 및 검증:** Beat Saber는 플레이어의 기술과 과제의 난이도 간의 균형을 맞추기 용이한 통제된 싱글 플레이어 게임이라는 특성이 있습니다 [3]. 이러한 장점 덕분에 e스포츠 및 게임 환경에서 플레이어의 신경 생리학적 몰입 상태(Flow state)를 안정적으로 유도하고 측정하기 위한 실험실 기반의 고충실도 검증(high-fidelity validation) 연구 모델에서도 핵심적인 과제로 제안 및 활용됩니다 [3].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[VR Exergame]], [[VR Sickness]], [[Flow State]]
-- **Projects/Contexts:** [[가상현실 노출 사후 효과(VR Aftereffects) 연구]], [[몰입 상태 예측 프레임워크(Flow State Prediction Framework)]]
-- **Contradictions/Notes:** 소스 연구에 따르면 Beat Saber 플레이 후의 사후 효과(멀미 등)는 전반적으로 일시적이며 40분 내에 기저 수준으로 회복되어 멀미로 인한 실험 탈락자가 없었지만 [6, 7], 장시간(50분) 노출될 경우 특정 사용자 집단(약 14%)에서는 게임 종료 40분 후에도 여전히 높은 수준의 멀미가 유지되는 등 개인의 민감도와 노출 시간에 따라 상이한 결과가 나타납니다 [6, 8]. 
-
----
-*Last updated: 2026-04-19*
-- Raw Source: [[00_Raw/2026-04-20/Beat Saber.md]]
----
diff --git a/Programming & Language/Beat Saber를 활용한 VR 엑서게임 후유증 연구(VR Exergaming Aftereffects).md b/Programming & Language/Beat Saber를 활용한 VR 엑서게임 후유증 연구(VR Exergaming Aftereffects).md
deleted file mode 100644
index 6a87ee3a..00000000
--- a/Programming & Language/Beat Saber를 활용한 VR 엑서게임 후유증 연구(VR Exergaming Aftereffects).md	
+++ /dev/null
@@ -1,49 +0,0 @@
----
-id: P-REINFORCE-AUTO-180522
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Beat Saber를 활용한 VR 엑서게임 후유증 연구(VR Exergaming Aftereffects)"
----
-
-# [[Beat Saber를 활용한 VR 엑서게임 후유증 연구(VR Exergaming Aftereffects)]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 이 연구는 인기 있는 가상현실(VR) 엑서게임인 'Beat Saber'를 각각 10분과 50분 동안 플레이한 후, 사용자의 시각, 인지 기능, 그리고 VR 멀미(VR Sickness)에 미치는 영향을 분석했습니다 [1], [2]. 연구 결과, 게임 직후 시각적 조절 및 폭주 능력의 변화와 멀미 증상이 증가했으나, 대부분의 경우 40분의 휴식 후 기준치로 회복되었습니다 [3]. 인지 기능 측면에서는 부정적인 후유증이 없었으며 오히려 단기 플레이 후 움직임 속도가 일시적으로 향상되었으나, 장시간(50분) 플레이한 일부 개인(약 14%)은 40분이 지나도 높은 수준의 멀미를 겪는 등 개인차가 큰 것으로 나타났습니다 [4], [5].
-
-## 📖 구조화된 지식 (Synthesized Content)
-- **연구 목적 및 설계**
-  - VR 엑서게임이 유발할 수 있는 시각, 인지, 웰빙(멀미) 측면의 후유증을 평가하기 위해 36명의 참가자를 대상으로 HTC Vive Pro HMD를 사용하여 Beat Saber 플레이 전, 직후, 그리고 40분 후(late)의 상태를 측정했습니다 [1], [6]. 
-  - 노출 시간에 따른 차이를 확인하기 위해 단기(10분) 노출과 장기(50분) 노출로 나누어 실험을 진행했습니다 [1].
-
-- **시각적 영향 (조절 및 폭주)**
-  - 10분 및 50분 노출 모두 VR 경험 직후 참가자의 안구 조절(accommodation)과 폭주(convergence) 기능에 유의미한 변화가 발생했습니다 [7], [8]. 
-  - 이러한 시각적 변화는 노출 시간에 크게 영향을 받지 않았고(처음 10분 이내에 발생), 40분이 지난 후에는 모두 기준치로 회복되는 단기적 현상이었습니다 [9]. 이는 HMD의 폭주-조절 불일치(vergence-accommodation conflicts)에 기인한 것으로 보입니다 [9].
-
-- **인지적 영향**
-  - 반응 시간(Reaction Time)을 통한 인지 테스트 결과, 결정 속도나 동작 속도에 대한 부정적인 영향은 발견되지 않았습니다 [8], [4].
-  - 오히려 10분간의 단기 게임 플레이 직후에는 참가자들의 움직임 속도(movement speed)가 기준치보다 소폭 빨라지는 긍정적인 결과가 관찰되었습니다 [4].
-
-- **VR 멀미 (SSQ 점수 분석)**
-  - 시뮬레이터 멀미 설문(SSQ) 결과, VR 노출 직후 전체 멀미 증상이 유의미하게 증가했으며, 50분 장기 노출이 10분 단기 노출보다 훨씬 높은 멀미 점수를 기록했습니다 [3], [10].
-  - 집단 평균적으로는 40분 후 멀미 증상이 기준치로 돌아왔지만, 50분 노출 참가자의 약 14%는 40분 후에도 여전히 심각한 수준의 멀미를 보고했습니다 [3], [5].
-  - 특히, 10분의 짧은 노출만으로도 높은 수준의 멀미를 경험한 사용자는 50분 노출 시에도 심각한 멀미를 경험할 가능성이 매우 높은 것으로 확인되었습니다 [3], [11].
-
-- **권고 사항**
-  - 장시간의 VR 엑서게임에 돌입하기 전, 짧은 시간 동안 미리 체험하여 개인의 멀미 민감도를 확인하는 것이 좋습니다 [12].
-  - 시각적 변화와 멀미 증상에서 완전히 회복될 수 있도록, VR 종료 후 최소 40분의 대기 시간(휴식)을 가진 뒤 운전과 같은 위험할 수 있는 활동을 하는 것이 권장됩니다 [13], [12].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[VR Sickness]], [[Vergence-Accommodation Conflicts]], [[Exergaming]], [[Simulator Sickness Questionnaire (SSQ)]]
-- **Projects/Contexts:** [[Beat Saber]], [[HTC Vive Pro HMD]]
-- **Contradictions/Notes:** 소스에 따르면 VR 엑서게임은 시각적 변화나 멀미와 같은 부작용을 동반할 수 있으나, 인지 능력 저하는 관찰되지 않았으며 짧은 시간 플레이 시에는 움직임 반응 속도 측면에서 일시적인 향상이 나타나는 상반된 결과가 있었습니다 [8], [4]. 또한, 집단의 멀미 증상은 대체로 40분 내에 회복되지만, 개인의 민감도에 따라 긴 시간 지속되는 소수의 예외(약 14%)가 존재한다는 점에 유의해야 합니다 [5].
-
----
-*Last updated: 2026-04-19*
-- Raw Source: [[00_Raw/2026-04-20/Beat Saber를 활용한 VR 엑서게임 후유증 연구(VR Exergaming Aftereffects).md]]
----
diff --git a/Programming & Language/Biomechanical-Analysis.md b/Programming & Language/Biomechanical-Analysis.md
deleted file mode 100644
index 80968c04..00000000
--- a/Programming & Language/Biomechanical-Analysis.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-C5D712
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Biomechanical-Analysis"
----
-
-# [[Biomechanical-Analysis]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Biomechanical-Analysis.md]]
----
diff --git a/Programming & Language/Biomechanics.md b/Programming & Language/Biomechanics.md
deleted file mode 100644
index b197621e..00000000
--- a/Programming & Language/Biomechanics.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-93212D
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Biomechanics"
----
-
-# [[Biomechanics]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Biomechanics.md]]
----
diff --git a/Programming & Language/Black-box Testing.md b/Programming & Language/Black-box Testing.md
deleted file mode 100644
index a928dee8..00000000
--- a/Programming & Language/Black-box Testing.md	
+++ /dev/null
@@ -1,30 +0,0 @@
----
-id: P-REINFORCE-AUTO-DC07C2
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Black-box Testing"
----
-
-# [[Black-box Testing]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 블랙박스 테스팅(Black-box Testing)은 애플리케이션의 내부 소스 코드를 보지 않고 외부에서 실행 중인 애플리케이션을 기반으로 테스트하는 방법입니다 [1], [2]. 대표적인 예로 DAST(동적 애플리케이션 보안 테스트)가 블랙박스 테스팅 방식을 취하며, 주로 CI 파이프라인의 후반부에 적용됩니다 [2].
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[DAST]], [[White-box Testing]], [[SAST]]
-- **Projects/Contexts:** [[CI Pipeline]]
-- **Contradictions/Notes:** 소스 데이터는 블랙박스 테스팅을 독립된 주제로 다루기보다는, 내부 소스 코드 기반의 정적 분석(SAST)인 화이트박스 테스팅과 대비되는 개념(DAST)으로 설명하고 있습니다 [1], [2].
-
----
-*Last updated: 2026-04-18*
-- Raw Source: [[00_Raw/2026-04-20/Black-box Testing.md]]
----
diff --git a/Programming & Language/Blink.md b/Programming & Language/Blink.md
deleted file mode 100644
index 51f88644..00000000
--- a/Programming & Language/Blink.md	
+++ /dev/null
@@ -1,34 +0,0 @@
----
-id: P-REINFORCE-AUTO-7F733B
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Blink"
----
-
-# [[Blink]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> Blink는 Chrome 브라우저에서 사용되는 렌더러(renderer) 엔진입니다 [1]. V8 엔진 외부에서 C++ 객체를 정의하고 할당하는 역할을 담당하며, 이러한 객체들은 메모리 힙 스냅샷 내에서 보통 `InternalNode` 카테고리로 표시됩니다 [2]. Blink는 'Oilpan'이라는 자체적인 가비지 컬렉터(Garbage Collector)를 보유하고 있으며, V8 엔진의 가비지 컬렉터와 상호 협력하여 동작합니다 [1].
-
-## 📖 구조화된 지식 (Synthesized Content)
-- **C++ 객체 및 힙 스냅샷(Heap Snapshot) 표현:** 
-  Blink는 V8 엔진 영역 밖에서 할당되는 C++ 객체들을 정의합니다. 크롬 개발자 도구의 힙 스냅샷을 통해 메모리를 분석할 때, Blink가 생성한 이 객체들은 기본적으로 `InternalNode`라는 이름으로 그룹화되어 표시됩니다 [2]. 만약 이 `InternalNode`가 과도한 메모리를 점유하여 메모리 누수(Leak)가 의심될 경우, 실험적 기능(Experiments) 설정을 켜서 제네릭한 `InternalNode` 대신 실제 Blink의 C++ 클래스 이름을 직접 노출시켜 디버깅할 수 있습니다 [2].
-- **자체 가비지 컬렉터 'Oilpan' 및 V8과의 협력:** 
-  크롬의 렌더러인 Blink는 메모리를 관리하기 위해 'Oilpan'이라는 독자적인 가비지 컬렉터를 가지고 있습니다 [1]. 현재 V8 엔진의 가비지 컬렉터와 Blink의 Oilpan 간의 협력을 향상시키기 위한 작업이 진행 중입니다. 특히, V8의 가비지 컬렉터 프로젝트인 Orinoco에서 도입된 새로운 기술과 기법 중 일부를 Blink의 Oilpan으로 이식(porting)하는 노력이 이루어지고 있습니다 [1].
-- **주의:** 소스에 관련 정보가 부족합니다. (제공된 소스 데이터에서는 Blink의 가비지 컬렉션(Oilpan)과 메모리 표현(`InternalNode`)에 관한 내용만 간략히 언급되어 있으며, 그 외 Blink의 세부 아키텍처나 렌더링 동작 방식에 대한 상세 정보는 포함되어 있지 않습니다.)
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[V8 Engine]], [[Oilpan]], [[Orinoco]], [[InternalNode]]
-- **Projects/Contexts:** [[Chrome]], [[Heap Snapshot]]
-- **Contradictions/Notes:** 소스 내에 Blink 자체의 전체 구조를 다루는 정보는 부족하며, V8 메모리 관리 및 힙 스냅샷 디버깅 관점에서만 제한적으로 언급되어 있습니다.
-
----
-*Last updated: 2026-04-19*
-- Raw Source: [[00_Raw/2026-04-20/Blink.md]]
----
diff --git a/Programming & Language/Branch Prediction.md b/Programming & Language/Branch Prediction.md
deleted file mode 100644
index e3db6495..00000000
--- a/Programming & Language/Branch Prediction.md	
+++ /dev/null
@@ -1,33 +0,0 @@
----
-id: P-REINFORCE-AUTO-4D7707
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Branch Prediction"
----
-
-# [[Branch Prediction]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> Branch prediction(분기 예측)은 현대 CPU가 분기 명령어의 과거 기록을 프로파일링하여(예: 분기가 항상 통과되는지 관찰) 다음 실행 경로를 미리 예측하는 성능 최적화 기술입니다 [1]. 이는 추측 실행(Speculative Execution)과 결합되어 CPU의 처리 속도를 비약적으로 높이지만, 공격자가 분기 기록을 통제할 수 있다는 점 때문에 스펙터(Spectre)와 같은 심각한 보안 취약점의 공격 경로로 악용됩니다 [1, 2].
-
-## 📖 구조화된 지식 (Synthesized Content)
-- **분기 예측과 추측 실행(Speculative Execution):** 현대 CPU는 성능 향상을 위해 분기를 프로파일링하여 실행 경로를 예측합니다 [1]. CPU는 분기 조건이 실제로 검증되기 전에 예측된 경로에 따라 메모리 로드 등의 명령을 미리 실행(추측 실행)하며, 예측이 틀린 것으로 판명되면 분기 이후에 일어난 작업을 롤백(Roll back)합니다 [1].
-- **스펙터(Spectre) 공격의 원리:** 스펙터 취약점은 분기 예측을 악용합니다. 추측 실행은 과거의 기록에 따라 분기를 실행하는데, 공격자는 이 과거 기록을 통제함으로써 CPU가 추측 실행 중에 어떤 분기를 수행할지 조작할 수 있습니다 [2]. 추측 실행이 롤백되더라도 L1 캐시에 로드된 데이터는 취소되지 않으므로, 공격자는 이를 이용해 타이밍 기반으로 메모리 정보를 유출할 수 있습니다 [2, 3].
-- **브라우저 엔진(WebKit)에 미치는 영향:** WebKit의 JavaScriptCore는 신뢰할 수 없는 JavaScript나 WebAssembly 코드의 보안(예: 배열 경계 검사, 타입 검사)을 유지하기 위해 '분기 명령어'에 의존해왔습니다 [4-6]. 그러나 분기 예측을 악용한 스펙터 공격으로 인해, 분기 명령어만으로는 더 이상 보안 속성을 강제하기에 충분하지 않게 되었습니다 [4, 5].
-- **대응 및 완화 조치:** 분기 예측을 악용하는 공격에 대응하기 위해 WebKit은 기존의 분기 기반 보안 검사 외에도, 인덱스 마스킹(Index masking)이나 포인터 포이즈닝(Pointer poisoning)과 같은 '분기 없는 보안 검사(Branchless Security Checks)' 방식으로 전환하고 있습니다 [7-9].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[Speculative Execution]], [[Spectre]], [[Branchless Security Checks]]
-- **Projects/Contexts:** [[WebKit]], [[JavaScriptCore]]
-- **Contradictions/Notes:** 소스에 관련 정보가 부족합니다. (소스 내에 상충하는 의견은 없으며, 과거에는 분기 명령어가 보안 강제에 충분하다고 여겨졌으나 스펙터의 등장으로 인해 더 이상 안전하지 않게 되었다는 맥락적 변화만 존재합니다 [4]).
-
----
-*Last updated: 2026-04-19*
-- Raw Source: [[00_Raw/2026-04-20/Branch Prediction.md]]
----
diff --git a/Programming & Language/Branchless Security Checks.md b/Programming & Language/Branchless Security Checks.md
deleted file mode 100644
index ae12163a..00000000
--- a/Programming & Language/Branchless Security Checks.md	
+++ /dev/null
@@ -1,39 +0,0 @@
----
-id: P-REINFORCE-AUTO-229D3F
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Branchless Security Checks"
----
-
-# [[Branchless Security Checks]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> Branchless Security Checks(분기 없는 보안 검사)는 Spectre 및 Meltdown과 같은 CPU 보안 취약점에 대응하기 위해 도입된 보안 메커니즘입니다 [1, 2]. 기존의 조건 분기(Branch) 명령어를 통해 보안을 확인하는 방식은 추측 실행(Speculative execution)을 악용하는 공격에 취약하기 때문에, 분기 명령어를 배제하고 비트 연산 등을 활용하는 방식이 필요해졌습니다 [3, 4]. 대표적인 구현 기법으로는 인덱스 마스킹(Index Masking)과 포인터 포이즈닝(Pointer Poisoning)이 있습니다 [4-6].
-
-## 📖 구조화된 지식 (Synthesized Content)
-* **도입 배경 (Spectre 공격의 위협):**
-  최신 CPU는 성능 향상을 위해 조건 분기의 결과를 미리 예측하고 실행하는 추측 실행(Speculative execution)을 사용합니다 [7]. Spectre 공격은 이러한 추측 실행 시 발생하는 정보 유출을 악용하여, 공격자가 분기의 실행을 제어하고 캐시 타이밍을 통해 메모리의 정보를 읽어낼 수 있게 합니다 [8]. 이로 인해 WebKit과 같은 엔진에서 신뢰할 수 없는 JavaScript나 WebAssembly 코드를 실행할 때, 기존의 분기 기반 검사로는 객체의 타입이나 배열 범위를 안전하게 보호할 수 없게 되었습니다 [3, 9, 10].
-
-* **Branchless Security Checks의 주요 기법:**
-  이를 해결하기 위해 WebKit 및 Blink 엔진은 분기 없는 보안 검사(Branchless Security Checks)를 도입했습니다 [1, 11].
-  * **인덱스 마스킹 (Index Masking):** 배열에 접근할 때 분기문을 사용하는 대신, 비트 마스킹(Bitwise operations) 연산을 사용하여 인덱스가 배열의 유효한 범위 내에 있도록 강제하는 기법입니다 [4, 5]. 최신 CPU는 비트 마스킹 연산에 대해 추측 실행을 하지 않으므로, 공격자가 배열의 범위를 벗어난 메모리를 읽어내는 것을 방지할 수 있습니다 [4].
-  * **포인터 포이즈닝 (Pointer Poisoning):** 객체 타입 검사 등에 사용되는 방법으로, 포인터에 특정 난수 값(Poison value)을 XOR 연산하여 포인터를 손상시키는 방식입니다 [5, 6]. 올바른 타입 검사를 거쳐 정상적으로 해독(Unpoison)되지 않은 포인터로 접근을 시도하면, 매핑되지 않은 유효하지 않은 메모리를 가리키게 되어 접근이 실패합니다 [5, 6]. 이 방식은 분기문 없이도 안전한 검사를 가능하게 하며 원격 코드 실행 공격을 방어하는 데도 유용합니다 [12].
-
-* **성능에 미치는 영향:**
-  이러한 분기 없는 보안 완화 기술들은 브라우저 엔진의 보안을 크게 강화하지만, JavaScript 엔진 및 JIT(Just-In-Time) 컴파일러의 실행 경로에 추가적인 명령어들을 발생시킵니다 [13]. 그 결과, 그래픽 파이프라인 및 시스템 운영에서 각 작업의 기본 마이크로 지연(Micro-latency)이 약간 증가하는 부작용이 동반됩니다 [13].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[Spectre]], [[Meltdown]], [[Speculative Execution]], [[Index Masking]], [[Pointer Poisoning]]
-- **Projects/Contexts:** [[WebKit]], [[Blink]], [[JavaScriptCore]]
-- **Contradictions/Notes:** 분기 없는 보안 검사 기법은 캐시 사이드 채널 공격을 방어하는 필수적인 수단이지만, 구조적으로 추가 연산을 요구하기 때문에 작업의 마이크로 지연(Micro-latency)을 증가시킨다는 성능적 트레이드오프가 존재합니다 [13].
-
----
-*Last updated: 2026-04-19*
-- Raw Source: [[00_Raw/2026-04-20/Branchless Security Checks.md]]
----
diff --git a/Programming & Language/Branded Types.md b/Programming & Language/Branded Types.md
deleted file mode 100644
index 9c5bb869..00000000
--- a/Programming & Language/Branded Types.md	
+++ /dev/null
@@ -1,49 +0,0 @@
----
-id: P-REINFORCE-AUTO-494E42
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Branded Types"
----
-
-# [[Branded Types]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-**Branded Types의 등장 배경과 원리**
-TypeScript는 이름이 아닌 구조를 기준으로 호환성을 판단하는 구조적 타이핑(덕 타이핑)을 사용합니다 [7, 8]. 이로 인해 사용자 ID와 주문 ID, 혹은 이메일과 일반 이름이 모두 `string` 타입일 경우, 서로 잘못 전달되더라도 컴파일러가 오류를 잡아내지 못합니다 [2, 3, 5]. 이러한 문제를 방지하기 위해 `type UserId = string & { readonly __brand: unique symbol }`과 같이 교집합(`&`)과 고유 속성을 활용하여 런타임 구조는 동일하지만 타입 시스템 상에서는 완전히 구별되는 명목적(Nominal) 타입을 에뮬레이트하는 것이 Branded Types의 핵심 원리입니다 [3-5].
-
-**타입 생성과 런타임 검증의 결합**
-개발자가 Branded Type 값을 생성하려면, 해당 값이 지정된 조건을 만족하는지 컴파일러에 알려주어야 합니다 [9].
-*   **Type Assertions (`as`)**: 가장 간단하지만 개발자의 실수로 잘못된 값을 강제할 위험이 있습니다 [10, 11].
-*   **Type Predicates**: `isPositive(value: number): value is Positive`와 같은 커스텀 타입 가드 함수를 만들어 안전하게 타입을 좁힙니다 [12].
-*   **Assertion Functions**: 조건에 맞지 않으면 런타임 에러를 던지도록 하여, 통과한 값만 해당 타입으로 취급되게 합니다 [13, 14].
-*   **유효성 검사 라이브러리 연동**: "검증하지 말고 파싱하라(Parse, Don't Validate)"는 철학과 결합하여, Zod와 같은 라이브러리의 `.brand()` 메서드를 활용하면 런타임 검증과 컴파일 타임 Branded Type 생성을 우아하게 결합할 수 있습니다 [15-18].
-
-**주요 활용 사례**
-*   **도메인 데이터 격리**: User ID와 Order ID(GUID 등)를 분리하여 서로 섞이는 것을 방지합니다 [16, 19].
-*   **안전성 강제**: XSS 공격을 방지하기 위해 일반 문자열과 '소독된(Sanitized) 문자열'을 엄격하게 구분합니다 [20].
-*   **수치 연산 통제**: 서로 다른 통화(Currency)끼리 합산되는 것을 막거나, 양수(Positive) 혹은 특정 범위 내의 숫자만 허용하도록 강제합니다 [21-23]. 
-
-**브랜드 강도에 따른 변형 (Variations)**
-필요한 엄격함의 수준에 따라 Branded Type의 구현 방식을 나눌 수 있습니다 [3, 24].
-*   **Weak Brand**: 기본 타입으로 암시적 변환이 허용되어 사용이 쉽습니다 (`type T = base & Tag`) [3, 24].
-*   **Strong Brand**: 명시적 캐스팅 없이는 기본 타입으로 호환되지 않아 높은 수준의 격리를 제공합니다 (`type T = (base & Tag) | Tag`) [3, 25].
-*   **Super Brand**: 캐스팅조차 매우 어렵게 설계하여 외부 유출을 철저히 차단하는 형태입니다 [3, 26].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[Structural Typing]], [[Primitive Obsession]], [[Type Predicates]], [[Parse, Don't Validate]]
-- **Projects/Contexts:** [[Domain-Driven Design (DDD)]], [[Zod]], [[Effect TS]], [[ts-brand]]
-- **Contradictions/Notes:** Branded Types는 강력한 안전성을 제공하지만 코드의 개념적 복잡성을 증가시키고 보일러플레이트 코드를 유발합니다 [27, 28]. 따라서 유니온(Unions), 열거형(Enums), 템플릿 리터럴 타입(Template Literal Types)과 같은 단순한 대안으로 해결 가능한 상황이라면 도입 시 이점과 유지보수 비용을 저울질해야 한다고 경고하고 있습니다 [29-31]. 또한, TypeScript 언어 자체에 명목적 타이핑(Nominal typing)을 직접 지원하자는 논의는 커뮤니티에서 오랫동안 있었으나 아직 명확한 합의에 이르지는 못했습니다 [9, 32].
-
----
-*Last updated: 2026-04-18*
-- Raw Source: [[00_Raw/2026-04-20/Branded Types.md]]
----
diff --git a/Programming & Language/Browser Security Mitigations.md b/Programming & Language/Browser Security Mitigations.md
deleted file mode 100644
index 0c48e64d..00000000
--- a/Programming & Language/Browser Security Mitigations.md	
+++ /dev/null
@@ -1,42 +0,0 @@
----
-id: P-REINFORCE-AUTO-539F01
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Browser Security Mitigations"
----
-
-# [[Browser Security Mitigations]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 브라우저 보안 완화(Browser Security Mitigations)는 스펙터(Spectre) 및 멜트다운(Meltdown)과 같은 사이드 채널 공격으로부터 사용자를 보호하기 위해 웹 브라우저가 구현하는 방어 메커니즘입니다. 이러한 완화 조치는 정보 유출을 막기 위해 타이밍 API의 정밀도를 고의로 낮추고, 자바스크립트 엔진 내에 추측 실행(Speculative Execution)을 방어하는 분기 없는(branchless) 보안 검사를 도입하여 메모리 접근을 안전하게 통제하는 데 중점을 둡니다 [1-3].
-
-## 📖 구조화된 지식 (Synthesized Content)
-*   **스펙터(Spectre) 및 멜트다운(Meltdown) 취약점 대응**
-    현대의 CPU는 성능 향상을 위해 추측 실행(Speculative execution)과 분기 예측을 사용합니다 [4]. 스펙터 공격은 이를 악용하여 고정밀 타이밍 측정을 통해 정상적인 범위를 벗어난 메모리를 읽어내는 기술입니다 [4, 5]. 브라우저에서 실행되는 신뢰할 수 없는 자바스크립트 코드가 이 취약점을 이용해 호스트 프로세스의 주소 공간이나 커널 메모리(멜트다운)에 접근하는 것을 막기 위해 브라우저 차원의 구조적 보안 완화가 필수적입니다 [2, 6, 7].
-
-*   **타이밍 정밀도 감소 및 지터(Jitter) 도입**
-    캐시 사이드 채널 공격은 캐시 적중 여부에 따른 서브 마이크로초 단위의 미세한 타이밍 차이를 관찰하여 이루어집니다 [1, 5]. 이를 방지하기 위해 브라우저 엔진은 `performance.now()`와 같은 타이머의 정밀도를 1ms 또는 100마이크로초 수준으로 낮추고, 공격자가 통계적 평균을 통해 고정밀 시계를 재구성하지 못하도록 무작위 변동(지터, Jitter)을 추가했습니다 [1, 3, 8]. 또한, 고해상도 타이머 역할을 할 수 있는 `SharedArrayBuffer`나 WebGL의 `EXT_disjoint_timer_query` 확장 기능을 비활성화하거나 사이트 격리 상태에 따라 해상도를 크게 제한(Quantization)했습니다 [1, 3, 8-10]. WebGPU의 타임스탬프 쿼리 역시 격리된 컨텍스트에서는 100마이크로초 해상도로 제한되며, 비격리 컨텍스트에서는 기본적으로 노출되지 않도록 보호됩니다 [11, 12].
-
-*   **분기 없는 보안 검사 (Branchless Security Checks)**
-    스펙터 공격은 CPU의 분기 예측을 제어하여 보안 속성을 강제하는 분기문을 우회할 수 있습니다 [5, 13]. 이에 WebKit 등의 브라우저 엔진은 분기문에 의존하지 않는 새로운 보안 검사 방식을 구현했습니다 [3].
-    *   **인덱스 마스킹(Index Masking):** 추측 실행 중에도 배열 인덱스가 유효한 범위 내에 있도록 비트 연산을 사용하여 값을 마스킹하는 기법입니다 [14, 15].
-    *   **포인터 포이즈닝(Pointer Poisoning):** 포인터 값에 컴파일 타임에 생성된 무작위 '포이즌(poison)' 값을 XOR 연산하는 기술입니다 [16]. 잘못된 타입 검사를 통과한 추측 실행 시, 포이즈닝된 포인터는 매핑되지 않은 유효하지 않은 메모리를 가리키게 되므로 데이터 유출을 방지할 수 있습니다 [14, 16, 17].
-
-*   **하드웨어 및 컨텍스트 전환 제한**
-    타이밍 공격 외에도, 듀얼 GPU를 사용하는 특정 시스템(예: 듀얼 GPU Mac)에서는 WebGL 컨텍스트의 수명 주기 동안 여러 GPU를 전환하는 행위 자체가 드라이버 수준의 보안 문제로 간주됩니다 [18]. 이에 따라 브라우저는 컨텍스트 생성 전 이산(discrete) GPU로 강제 전환하고 유지하도록 제한을 두고 있습니다 [18].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[Spectre and Meltdown]], [[Speculative Execution]], [[Timing Attacks]], [[Index Masking]], [[Pointer Poisoning]]
-- **Projects/Contexts:** [[WebKit]], [[JavaScriptCore]], [[WebGPU]], [[WebGL]]
-- **Contradictions/Notes:** WebGPU 타임스탬프 쿼리는 타이밍 공격의 우려로 인해 초기에는 비격리 컨텍스트에서 완전히 숨겨지도록 제안되었으나 [12], 개발자들의 성능 프로파일링 요구와 브라우저 간 상호 운용성(Interop) 문제를 해결하기 위해, 사이트 격리 여부와 상관없이 High-Resolution Time 스펙과 맞춘 100마이크로초 해상도를 제공하는 방향으로 스펙이 수정 및 채택되었습니다 [19-22].
-
----
-*Last updated: 2026-04-19*
-- Raw Source: [[00_Raw/2026-04-20/Browser Security Mitigations.md]]
----
diff --git a/Programming & Language/CAD 렌더링 최적화.md b/Programming & Language/CAD 렌더링 최적화.md
deleted file mode 100644
index 86b76213..00000000
--- a/Programming & Language/CAD 렌더링 최적화.md	
+++ /dev/null
@@ -1,35 +0,0 @@
----
-id: P-REINFORCE-AUTO-40FA98
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - CAD 렌더링 최적화"
----
-
-# [[CAD 렌더링 최적화]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> CAD 렌더링 최적화는 브라우저 및 통합 GPU(iGPU) 환경에서 메모리 대역폭과 CPU-GPU 간 통신 병목을 극복하여 수백만 개의 폴리곤을 가진 대규모 다중 본체 어셈블리(Multi-Body Assemblies)를 부드럽게 렌더링하는 일련의 기술적 과정입니다 [1, 2]. 이를 위해 `BatchedMesh`나 `InstancedMesh`를 통한 드로우 콜 최소화, 정밀도 붕괴 방지를 위한 원점 이동(Origin-shifting), 메모리 관리 효율화를 위한 Web Worker 및 `SharedArrayBuffer` 활용이 필수적으로 요구됩니다 [3-5]. 또한, 오버드로우를 줄이는 깊이 사전 패스(Depth Pre-Pass)와 시각적 끊김이 없는 디더링 LOD 등의 렌더링 기법을 결합하여 고성능의 시각화 경험을 제공합니다 [6-8].
-
-## 📖 구조화된 지식 (Synthesized Content)
-- **하드웨어 및 메모리 대역폭의 병목 극복:** 통합 GPU(Intel UHD, AMD Radeon Vega 등)는 UMA(Unified Memory Architecture) 환경을 사용하여 시스템 RAM을 CPU와 공유하므로 메모리 대역폭이 주된 성능 제약이 됩니다 [1, 9]. 100만 개 이상의 삼각형을 가진 CAD 모델을 파싱하고 디코딩할 때 발생하는 메인 스레드 프리징과 메모리 중복을 방지하기 위해 Web Worker와 `SharedArrayBuffer`를 연동한 제로 카피(Zero-copy) 아키텍처를 도입해야 합니다 [5].
-- **지오메트리 통합과 드로우 콜 최적화:** CAD 어셈블리를 구성하는 수많은 부품을 개별 메쉬로 렌더링하면 엄청난 드로우 콜 오버헤드가 발생합니다 [2]. 볼트나 브래킷 같은 반복 부품은 `InstancedMesh`로 처리하고, 고유한 기하학적 형태가 섞인 다양한 부품들은 `BatchedMesh`를 사용해 단일 드로우 콜로 묶어 처리해야 iGPU의 오버헤드를 크게 줄일 수 있습니다 [3, 10]. 정적인 하위 어셈블리는 지오메트리를 타일 단위로 병합(`mergeBufferGeometries`)하는 전략을 활용할 수 있습니다 [11].
-- **좌표 정밀도 붕괴(Precision Collapse) 방지:** CAD 데이터의 거대한 좌표계(예: 10^7 단위 이상)를 WebGL의 32-bit float 환경으로 가져오면 소수점 이하 정밀도가 부족해져 정점이 흔들리거나 진동하는 현상(Vertex Snapping/Jitter)이 발생합니다 [4]. 이를 막기 위해 64-bit 공간에서 전체 어셈블리의 중심(basePoint)을 계산한 뒤, 정점 좌표를 오프셋 처리(Re-centering shift)하여 GPU에 업로드해야 합니다 [4].
-- **가시성 판별(Visibility Determination) 및 오클루전 컬링:** 복잡한 내부 부품이 겹쳐 있는 CAD 모델에서 오버드로우를 줄이기 위해 색상 쓰기를 비활성화한 채 Z-버퍼만 먼저 채우는 '깊이 사전 패스(Depth Pre-Pass)'를 수행하면 프래그먼트 셰이더 부하를 최대 30%까지 줄일 수 있습니다 [6]. 또한 옥트리(Octree)나 BVH(Bounding Volume Hierarchy)를 통해 CPU 공간 분할을 적용하여 보이지 않는 노드에 대한 연산을 렌더링에서 배제합니다 [12].
-- **LOD 및 엣지(Edge) 렌더링 최적화:** 부품을 정밀 검토할 때 시각적으로 튀는 팝핑(Popping) 현상을 막기 위해, 화면 공간 디더링 패턴(Dithered LOD Blend)을 활용한 매끄러운 형태의 LOD 전환 기법을 구현합니다 [7, 13]. 또한 CAD 도면 특유의 날카로운 모서리(Wireframe/Edge)를 표현하기 위해 `EdgesGeometry`를 사용하면 정점 부하가 2배로 늘어나므로, 무게 중심 좌표(Barycentric Coordinate)를 활용하여 단일 패스의 프래그먼트 셰이더 안에서 절차적으로 엣지를 렌더링하는 기법이 권장됩니다 [14, 15].
-- **자원 및 상태 관리 (State Management):** 수백 개의 색상을 표현하기 위해 개별 재질(Material)을 번갈아 쓰지 않고 '텍스처 아틀라스(Texture Atlas)'와 파트 ID를 활용해 셰이더 전환을 최소화해야 합니다 [16]. 아울러 배터리 소모와 발열을 막기 위해 변경 사항이 있을 때만 프레임을 업데이트하는 Render-on-Demand(요청 시 렌더링) 방식을 적용하며, 값비싼 물리 기반 렌더링(MeshStandardMaterial) 대신 `MeshPhongMaterial` 또는 'Flat Shaded + Edge' 커스텀 셰이더를 사용하여 프래그먼트 연산 비용을 아낍니다 [8, 17-19].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[BatchedMesh]], [[InstancedMesh]], [[Depth Pre-Pass]], [[SharedArrayBuffer]], [[Frustum Culling]], [[Level of Detail (LOD)]]
-- **Projects/Contexts:** [[WebGPU 대규모 건설 뷰어]], [[BIM 모델 시뮬레이션]]
-- **Contradictions/Notes:** 지오메트리 병합(`BufferGeometryUtils.mergeBufferGeometries`) 기법은 드로우 콜을 가장 효과적으로 줄여주지만, 단일 바운딩 볼륨으로 묶이기 때문에 시야 절두체 컬링(Frustum Culling)의 효율성을 떨어뜨린다는 딜레마를 가집니다 [11]. 또한, `InstancedMesh`는 단일 지오메트리의 반복 렌더링에는 매우 유리하지만 서로 다른 기하학적 구조를 가진 부품이 수천 개 모인 CAD 모델에는 부적합하며, 이 경우 다중 지오메트리를 지원하는 `BatchedMesh`를 사용하는 것이 더 올바른 대안입니다 [3, 10, 20].
-
----
-*Last updated: 2026-04-19*
-- Raw Source: [[00_Raw/2026-04-20/CAD 렌더링 최적화.md]]
----
diff --git a/Programming & Language/CANTAB 5-선택 반응 시간 과제(CANTAB 5-choice RTI).md b/Programming & Language/CANTAB 5-선택 반응 시간 과제(CANTAB 5-choice RTI).md
deleted file mode 100644
index ba626180..00000000
--- a/Programming & Language/CANTAB 5-선택 반응 시간 과제(CANTAB 5-choice RTI).md	
+++ /dev/null
@@ -1,34 +0,0 @@
----
-id: P-REINFORCE-AUTO-20A493
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - CANTAB 5-선택 반응 시간 과제(CANTAB 5-choice RTI)"
----
-
-# [[CANTAB 5-선택 반응 시간 과제(CANTAB 5-choice RTI)]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> CANTAB 5-선택 반응 시간 과제(RTI)는 참가자의 반응 속도를 측정하여 인지적 요인과 신체적 움직임 요인을 분리하여 평가할 수 있도록 설계된 인지 측정 과제입니다 [1]. 이 과제는 주로 iPad의 CANTAB 앱을 통해 시행되며, 사용자가 화면의 5개 위치를 모니터링하다가 나타나는 시각적 자극에 최대한 빠르게 반응하는 능력을 평가합니다 [1]. 과제의 결과는 크게 '의사결정 속도'와 '이동 속도'라는 두 가지 구성 요소로 나뉘어 측정됩니다 [1, 2].
-
-## 📖 구조화된 지식 (Synthesized Content)
-- **과제 인터페이스 및 수행 절차:** RTI 과제는 화면 하단에 위치한 하나의 원(버튼)과 화면 상단에 위치한 5개의 원으로 구성됩니다 [1]. 참가자는 먼저 하단의 버튼을 누르고 대기하다가, 상단의 5개 원 중 무작위 위치에서 노란색 점(목표 자극)이 나타나는 것을 모니터링해야 합니다 [1]. 노란색 점이 나타나면, 참가자는 지체 없이 하단 버튼에서 손을 떼고 해당 노란색 점을 터치해야 합니다 [1].
-- **반응 시간의 측정 요소:** 과제는 참가자의 반응을 두 가지 개별 속도로 나누어 계산하며, 정확하게 수행된 응답(correct responses) 데이터만을 계산에 포함합니다 [1].
-  - **의사결정 속도(Decision speed):** 목표 자극이 화면에 나타난 순간부터 참가자가 하단 버튼에서 손을 떼기까지 걸린 시간의 중앙값(median duration)입니다 [1].
-  - **이동 속도(Movement speed):** 하단 버튼에서 손을 뗀 순간부터 목표 자극(노란색 점)을 실제로 터치하기까지 걸린 시간의 중앙값입니다 [1].
-- **활용 맥락:** 소스 자료에 따르면, 이 과제는 가상현실(VR) 엑서게임(Beat Saber 등) 이용이 인지 능력에 미치는 사후 효과(Aftereffects)를 측정하기 위한 연구에 도입되었습니다 [1, 3]. 참가자의 인지 상태 변화를 확인하기 위해 VR 노출 전, 노출 직후, 그리고 40분 후에 각각 이 과제를 수행하여 반응 시간을 비교 분석하는 데 사용되었습니다 [3, 4].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[의사결정 속도(Decision Speed)]], [[이동 속도(Movement Speed)]]
-- **Projects/Contexts:** [[가상현실 사후 효과 연구(Virtual Reality Aftereffects Study)]]
-- **Contradictions/Notes:** 소스에 관련 정보가 부족합니다. (소스 데이터 내에서 해당 과제에 대해 상충하는 주장이나 논쟁점은 확인되지 않습니다.)
-
----
-*Last updated: 2026-04-19*
-- Raw Source: [[00_Raw/2026-04-20/CANTAB 5-선택 반응 시간 과제(CANTAB 5-choice RTI).md]]
----
diff --git a/Programming & Language/CI_CD Pipeline.md b/Programming & Language/CI_CD Pipeline.md
deleted file mode 100644
index 9c00da8f..00000000
--- a/Programming & Language/CI_CD Pipeline.md	
+++ /dev/null
@@ -1,34 +0,0 @@
----
-id: P-REINFORCE-AUTO-643BD1
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - CI_CD Pipeline"
----
-
-# [[CI_CD Pipeline]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> CI/CD 파이프라인은 소프트웨어 개발 수명 주기(SDLC)에서 코드의 빌드, 테스트 및 배포를 자동화하는 워크플로우입니다. 이 파이프라인은 정적 애플리케이션 보안 테스트(SAST), 린팅, 자동화된 코드 리뷰 등의 도구를 통합하여 코드가 프로덕션 환경에 도달하기 전에 결함과 취약점을 차단하는 필수적인 안전장치 역할을 합니다. 개발 속도를 저하시키지 않으면서 코드 품질과 보안을 일관되게 유지하고 정책을 강제하는 핵심적인 경계선(Enforcement Boundary)으로 기능합니다.
-
-## 📖 구조화된 지식 (Synthesized Content)
-- **보안 및 품질의 가드레일 역할**: CI/CD 파이프라인은 코드가 배포되기 전에 품질 및 보안 검사를 우회하지 못하도록 하는 가드레일 역할을 수행합니다 [1]. 자동화된 검사를 통해 취약점, 로직 결함, 유지보수성 문제 등을 조기에 발견하고, 기준에 미달하는 코드가 프로덕션 환경에 병합되는 것을 차단합니다 [2, 3].
-- **자동화 도구 및 정적 분석(SAST) 통합**: CI/CD 파이프라인에 SonarQube, Snyk, ESLint 등과 같은 정적 코드 분석 및 린팅 도구를 통합하는 것은 널리 인정받는 모범 사례입니다 [4, 5]. 파이프라인 내에서 자동화된 스캔이 실행되어 코드의 구문 오류, 보안 취약점 등을 신속하게 식별하고 개발자에게 즉각적인 피드백을 제공합니다 [6-8].
-- **품질 게이트(Quality Gates) 및 정책 강제**: 파이프라인 내에서 정책 기반의 품질 게이트를 설정하여 일관된 코드 표준을 강제할 수 있습니다 [7, 9]. 발견된 문제의 심각도 임계값을 설정하여, 치명적이거나 위험도가 높은 결함이 검출될 경우 자동으로 빌드를 실패하게 만들거나 풀 리퀘스트(PR) 병합을 차단합니다 [10-12].
-- **순차적 게이트 아키텍처(Sequential Gates Architecture)**: 최신 CI/CD 파이프라인은 풀 리퀘스트 생성 시 린팅, 단위/통합 테스트, SAST 보안 스캔 등의 자동화된 사전 병합 검사(Pre-Merge Checks)를 먼저 병렬로 실행합니다 [13]. 자동화 검사를 통과하면 위험도나 코드 소유권에 따라 인간의 리뷰를 조건부로 요청하며, 모든 승인이 완료되어야만 병합이 활성화되는 체계를 갖춥니다 [14].
-- **로컬 개발자 도구(Git Hooks)와의 관계**: 로컬 환경에서 실행되는 Git 훅(예: Husky, lint-staged)은 빠르고 즉각적인 피드백을 제공하지만 개발자가 우회(`--no-verify`)할 수 있는 반면, CI/CD 파이프라인은 우회할 수 없는 최종 권한(Final authority)이자 강제 경계선(Enforcement boundary)입니다 [15-17]. 따라서 전체 테스트 스위트, 타입 검사 및 심층 보안 스캔과 같은 무거운 작업은 CI/CD 파이프라인에서 수행하는 것이 권장됩니다 [17, 18].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[Static Application Security Testing (SAST)]], [[Automated Code Review]], [[Quality Gates]], [[DevSecOps]], [[Git Hooks]]
-- **Projects/Contexts:** [[소프트웨어 개발 수명 주기(SDLC)]], [[풀 리퀘스트(Pull Request) 워크플로우]]
-- **Contradictions/Notes:** 개발자 환경의 로컬 훅(Husky 등)은 빠르고 편리한 피드백을 위한 도구일 뿐 완벽한 강제 수단이 아니며, 실제적인 보안 및 품질 규칙의 최종 강제는 CI/CD 파이프라인에서 이루어져야 합니다 [15, 16].
-
----
-*Last updated: 2026-04-19*
-- Raw Source: [[00_Raw/2026-04-20/CI_CD Pipeline.md]]
----
diff --git a/Programming & Language/CI_CD 파이프라인 (CI_CD Pipelines).md b/Programming & Language/CI_CD 파이프라인 (CI_CD Pipelines).md
deleted file mode 100644
index 3d4a5870..00000000
--- a/Programming & Language/CI_CD 파이프라인 (CI_CD Pipelines).md	
+++ /dev/null
@@ -1,33 +0,0 @@
----
-id: P-REINFORCE-AUTO-3D8966
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - CI_CD 파이프라인 (CI_CD Pipelines)"
----
-
-# [[CI_CD 파이프라인 (CI_CD Pipelines)]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-- **보안 및 품질 검사의 자동화 통합 (Shift-left):** CI/CD 파이프라인은 개발자가 코드를 푸시하거나 풀 리퀘스트(PR)를 생성할 때마다 백그라운드에서 자동으로 코드 스캔을 실행합니다 [3, 7-10]. 이를 통해 코드 스멜, 보안 취약점(예: SQL 인젝션, 하드코딩된 비밀번호 등), 문법 오류를 개발 초기 단계에서 식별하여 수정 비용을 최소화하는 '시프트 레프트(Shift-left)' 전략을 실현합니다 [3, 4, 11].
-- **품질 게이트(Quality Gate)와 빌드 차단:** CI/CD 파이프라인 내에 심각도 임계값이나 보안 정책을 기반으로 한 '품질 게이트'를 설정할 수 있습니다 [2, 12, 13]. SonarQube, Snyk 등과 통합되어 코드가 조직의 보안 및 품질 표준을 충족하지 못할 경우 빌드와 병합을 자동으로 실패 처리(Fail builds or block merges)하여 악성 코드나 결함 있는 코드가 릴리스되는 것을 방지합니다 [6, 11, 14, 15].
-- **로컬 검사와의 차이점 및 보완:** 로컬에서 실행되는 Git Hooks(예: Husky, lint-staged)는 변경된 파일만 빠르게 검사하고 개발자가 우회(Bypass)할 수도 있는 편의성 도구인 반면, CI/CD 파이프라인은 우회할 수 없는 최종적인 집행 경계(Enforcement boundary)입니다 [5, 16, 17]. 따라서 CI/CD에서는 전체 테스트 스위트 실행, 심층적인 타입 체크, 전체 코드베이스 린팅과 같이 로컬에서 수행하기엔 무거운 전체 검사를 수행하도록 구성됩니다 [17-19].
-- **도구 적용 시의 성능 고려:** 대규모 저장소에서 정밀한 정적 분석 도구를 CI/CD 환경에 통합하면 빌드 소요 시간이 길어질 수 있는 단점이 존재합니다 [20-22]. 이를 최적화하기 위해 파이프라인 내에서 변경된 코드만 스캔하는 증분 스캔(Incremental/differential scanning) 방식을 도입하여 빠른 피드백 루프를 유지하는 것이 권장됩니다 [11].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[SAST (Static Application Security Testing)]], [[Quality Gate]], [[Automated Code Review]], [[Shift-left]], [[Git Hooks]]
-- **Projects/Contexts:** [[GitHub Actions, GitLab CI, Jenkins (CI/CD Platforms)]], [[SonarQube / Snyk Code Integration]]
-- **Contradictions/Notes:** 개발 로컬 환경에서의 Git Hooks(Husky 등) 검사는 빠른 피드백을 제공하지만 개발자에 의해 의도적으로 무시될 수 있습니다. 반면 CI/CD 파이프라인에서의 검사는 조직의 규칙을 최종적으로 집행하므로, 로컬 검사가 CI/CD 파이프라인의 필요성을 대체할 수는 없다고 소스들은 강조합니다 [5, 16].
-
----
-*Last updated: 2026-04-19*
-- Raw Source: [[00_Raw/2026-04-20/CI_CD 파이프라인 (CI_CD Pipelines).md]]
----
diff --git a/Programming & Language/CI_CD 파이프라인 자동화.md b/Programming & Language/CI_CD 파이프라인 자동화.md
deleted file mode 100644
index 06c18a01..00000000
--- a/Programming & Language/CI_CD 파이프라인 자동화.md	
+++ /dev/null
@@ -1,33 +0,0 @@
----
-id: P-REINFORCE-AUTO-B0C6AD
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - CI_CD 파이프라인 자동화"
----
-
-# [[CI_CD 파이프라인 자동화]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> CI/CD 파이프라인 자동화는 소프트웨어 개발 수명 주기(SDLC)에서 정적 분석, 코드 포맷팅, 보안 테스트(SAST)를 워크플로우에 통합하여 자동으로 실행되게 하는 과정입니다 [1-3]. 이를 통해 코드가 병합되거나 프로덕션 환경에 배포되기 전에 구문 오류, 결함 및 보안 취약점을 조기에 발견하고 차단할 수 있습니다 [4-6]. 결과적으로 수동 코드 리뷰에 드는 시간을 절약하고, 소프트웨어의 전반적인 품질과 일관성을 효율적으로 유지할 수 있습니다 [7, 8].
-
-## 📖 구조화된 지식 (Synthesized Content)
-- **보안 및 정적 분석(SAST)의 통합:** CI/CD 파이프라인 자동화의 핵심은 SonarQube, Snyk, Qodana, Semgrep과 같은 정적 애플리케이션 보안 테스트 도구를 연결하는 것입니다 [9-12]. 파이프라인에 이러한 스캐너를 통합하면, 코드가 빌드되는 과정이나 풀 리퀘스트 단계에서 보안 취약점과 버그를 자동으로 식별하는 가드레일을 구축할 수 있습니다 [7, 13, 14]. 
-- **코드 린팅(Linting) 및 포맷팅의 강제:** 파이프라인 및 개발 환경에서 Husky와 `lint-staged`와 같은 도구를 설정하면 커밋 이전(pre-commit)에 ESLint 및 Prettier 등을 자동 실행할 수 있습니다 [15-17]. 전체 코드베이스가 아닌 변경된(staged) 파일에만 규칙을 검사하고 자동 수정(auto-fix)을 적용하여, 속도를 유지하면서도 일관된 코드 컨벤션을 강제할 수 있습니다 [18-20].
-- **품질 게이트(Quality Gates) 기반 빌드 제어:** CI/CD 환경에서는 검사 도구에 품질 게이트와 심각도 임계값(severity thresholds)을 설정할 수 있습니다 [21, 22]. 이를 통해 허용되지 않는 수준의 코드 스멜, 보안 결함 또는 스타일 위반이 발견되면 자동으로 빌드를 실패시키거나 풀 리퀘스트 병합을 차단합니다 [11, 22-24].
-- **다단계 자동화 검증 아키텍처(Sequential Gates):** 현대적인 CI/CD 파이프라인은 풀 리퀘스트가 생성될 때 린팅, 포맷팅 검증, 테스트, SAST 스캐닝 및 의존성 분석 등의 사전 검사를 병렬로 자동 실행하도록 아키텍처를 구성합니다 [25]. 자동화된 검사가 통과되어야만 인간의 리뷰와 병합 단계로 진행될 수 있도록 하여 리뷰어의 피로도를 낮춥니다 [26, 27].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[정적 애플리케이션 보안 테스트 (SAST)]], [[Git Hooks (Husky 및 lint-staged)]], [[품질 게이트 (Quality Gates)]]
-- **Projects/Contexts:** [[DevSecOps 파이프라인 통합]], [[풀 리퀘스트(PR) 검사 자동화]]
-- **Contradictions/Notes:** 소스에 따르면 정적 분석 도구를 파이프라인에 통합할 때 심층적인 스캔은 분석 시간이 오래 걸려 CI/CD 파이프라인을 지연시키는 원인이 될 수 있습니다(예: SonarQube Cloud는 일부 환경에서 파이프라인에 추가 시간을 발생시킴) [28]. 따라서 파이프라인 속도 저하를 방지하기 위해 PR 단계에서는 변경된 파일만 가볍고 빠르게 검사하는 `lint-staged`나 증분 스캔(incremental scans)을 활용하고, 전체 코드 스캔이나 무거운 분석은 CI 서버의 별도 단계나 정기 스캔으로 미루는 방식이 권장됩니다 [18, 19, 29, 30].
-
----
-*Last updated: 2026-04-19*
-- Raw Source: [[00_Raw/2026-04-20/CI_CD 파이프라인 자동화.md]]
----
diff --git a/Programming & Language/CI_CD 파이프라인 통합 및 Git 훅(Hooks).md b/Programming & Language/CI_CD 파이프라인 통합 및 Git 훅(Hooks).md
deleted file mode 100644
index eeb849a3..00000000
--- a/Programming & Language/CI_CD 파이프라인 통합 및 Git 훅(Hooks).md	
+++ /dev/null
@@ -1,40 +0,0 @@
----
-id: P-REINFORCE-AUTO-C861C6
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - CI_CD 파이프라인 통합 및 Git 훅(Hooks)"
----
-
-# [[CI_CD 파이프라인 통합 및 Git 훅(Hooks)]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> CI/CD 파이프라인 통합 및 Git 훅(Hooks)은 소프트웨어 개발 시 코드 변경 사항이 저장소에 반영되거나 배포되기 전에 코드 품질과 보안을 자동으로 검증하는 필수 프로세스입니다. 로컬 환경에서는 Husky와 lint-staged 같은 도구를 활용한 Git 훅을 통해 커밋 전 단계에서 정적 분석과 포매팅을 강제하여 1차적인 결함을 차단합니다. 이후 CI/CD 파이프라인 서버와 연동되어 우회 불가능한 자동화된 테스트, 보안 스캔(SAST), 품질 게이트를 거쳐 최종적으로 안전하고 일관된 코드만 배포되도록 보장합니다.
-
-## 📖 구조화된 지식 (Synthesized Content)
-*   **Git 훅(Hooks)의 개념 및 한계 해결:**
-    Git 훅은 `pre-commit`, `commit-msg`, `pre-push`, `post-merge` 등 Git 워크플로우의 특정 시점에 실행되는 셸 스크립트입니다 [1]. 기본적으로 Git 훅은 `.git/hooks/` 디렉토리에 위치하여 버전 관리(버전 컨트롤) 대상에서 제외되므로, 팀원 간의 공유나 CI 환경에서의 강제가 어렵다는 단점이 있습니다 [2]. 이를 해결하기 위해 **Husky**와 같은 도구를 사용해 훅 스크립트를 추적 가능한 디렉토리(예: `.husky/`)에 저장함으로써 모든 팀원과 환경에 동일한 Git 훅을 쉽게 설정하고 공유할 수 있습니다 [2-4]. 
-
-*   **lint-staged를 통한 검사 효율화:**
-    코드베이스 전체에 대해 매번 검사를 수행하면 시간이 오래 걸려 개발 속도가 저하될 수 있습니다 [2]. 이를 방지하기 위해 `pre-commit` 훅 내에서 **lint-staged** 도구를 결합하여 사용합니다 [2, 5]. lint-staged는 커밋을 위해 Git의 'staged' 상태에 올라간(즉, 변경된) 파일만을 대상으로 ESLint나 Prettier 같은 도구를 실행시킵니다 [2, 6]. 이로써 검사 시간을 수 초 내로 단축하면서도 문법 오류나 스타일 가이드 위반 파일이 커밋되는 것을 효과적으로 방지할 수 있습니다 [2, 7].
-
-*   **안전망(Safety Net)으로서의 CI/CD 파이프라인:**
-    로컬 환경에서 설정된 Git 훅은 `--no-verify` 등의 옵션을 통해 개발자가 임의로 검사를 우회(Bypass)할 수 있습니다 [8, 9]. 따라서 로컬 훅은 개발자 피드백을 위한 빠른 도구로 활용되어야 하며, 최종적인 권한과 안전망은 CI/CD 파이프라인이 담당해야 합니다 [9, 10]. CI/CD 파이프라인에서는 훅을 비활성화한 상태에서 전체 린팅, 전체 테스트 스위트 실행, 타입 검사, 빌드 검증 등을 철저하게 다시 실행하여 품질을 보장합니다 [10-12].
-
-*   **정적 애플리케이션 보안 테스트(SAST) 및 품질 게이트 연동:**
-    코드 스캔 도구(예: Snyk, SonarQube, Corgea, Veracode 등)는 CI/CD 파이프라인 및 풀 리퀘스트(PR) 워크플로우와 긴밀하게 통합되어 작동합니다 [13-15]. PR이 생성되거나 코드가 푸시되면 자동으로 스캔이 트리거되어 취약점이나 논리적 결함을 조기에 발견합니다(Shift-Left) [15, 16]. 발견된 문제의 심각도(Severity)에 따라 빌드를 실패하게 하거나 PR 병합을 차단하는 '품질 게이트(Quality Gates)'를 설정함으로써, 보안 위험과 결함이 프로덕션 환경에 도달하는 것을 파이프라인 단계에서 원천적으로 차단할 수 있습니다 [17-19].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[Git Hooks]], [[Husky]], [[lint-staged]], [[SAST (Static Application Security Testing)]], [[ESLint]], [[Prettier]]
-- **Projects/Contexts:** [[안전한 소프트웨어 개발 수명주기(SSDLC)]], [[프론트엔드 및 모노레포(Monorepo) 개발 환경 설정]], [[풀 리퀘스트(PR) 기반 보안 검토]]
-- **Contradictions/Notes:** 로컬 Git 훅(pre-commit 등)은 빠른 피드백을 제공하여 CI 실패를 줄여주는 유용한 도구이지만, 개발자가 임의로 우회할 수 있으므로 절대 CI/CD 검증을 대체해서는 안 되며 상호 보완적으로 사용해야 한다고 강조됩니다 [9, 10]. 또한, lint-staged는 변경된 특정 파일에만 국한된 작업(예: 포매팅, 린팅)에는 뛰어나지만, 프로젝트 전체를 대상으로 실행되어야 하는 도구(예: 전체 타입 체크)의 래퍼(wrapper)로 사용하는 것은 부적절합니다 [6, 20].
-
----
-*Last updated: 2026-04-18*
-- Raw Source: [[00_Raw/2026-04-20/CI_CD 파이프라인 통합 및 Git 훅(Hooks).md]]
----
diff --git a/Programming & Language/CI_CD 파이프라인.md b/Programming & Language/CI_CD 파이프라인.md
deleted file mode 100644
index fbc9510c..00000000
--- a/Programming & Language/CI_CD 파이프라인.md	
+++ /dev/null
@@ -1,33 +0,0 @@
----
-id: P-REINFORCE-AUTO-057C1E
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - CI_CD 파이프라인"
----
-
-# [[CI_CD 파이프라인]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> CI/CD 파이프라인은 소프트웨어 개발 수명 주기(SDLC)에서 코드의 통합, 테스트 및 배포를 자동화하는 워크플로우입니다 [1-3]. 이 파이프라인에는 정적 애플리케이션 보안 테스트(SAST) 및 자동화된 코드 리뷰 도구들이 통합되어, 코드가 프로덕션 환경에 도달하기 전에 보안 취약점, 버그 및 스타일 위반을 조기에 발견합니다 [3-6]. 결과적으로 조직은 개발 속도를 늦추지 않으면서도 보안을 강화하고 높은 소프트웨어 품질 기준을 일관되게 적용할 수 있습니다 [7-9].
-
-## 📖 구조화된 지식 (Synthesized Content)
-- **정적 분석 및 보안 도구의 통합:** CI/CD 파이프라인은 SonarQube, Snyk, CodeQL, Qodana, Semgrep과 같은 SAST 및 코드 리뷰 도구들을 통합하는 핵심 단계입니다 [3, 4, 7, 10, 11]. 이 도구들은 파이프라인 실행 중 저장된 소스 코드를 스캔하여 논리적 결함, 보안 취약점 및 코드 냄새(code smells)를 개발 초기 단계에서 식별합니다 [1, 2, 12].
-- **품질 게이트(Quality Gates)를 통한 통제:** CI/CD 파이프라인 내에 통합된 분석 도구들은 풀 리퀘스트(Pull Request)나 빌드 과정에서 '품질 게이트' 역할을 수행합니다 [13-16]. 심각한 보안 취약점이나 품질 기준에 미달하는 코드가 발견될 경우, 파이프라인은 자동으로 빌드를 실패 처리하거나 병합(merge)을 차단하여 프로덕션 환경을 보호합니다 [9, 17-20].
-- **시프트 레프트(Shift-Left) 보안 실현:** CI/CD 파이프라인에 코드 검사기를 구축하는 것은 개발 주기 초기에 보안을 점검하는 '시프트 레프트' 접근 방식의 대표적인 모범 사례입니다 [3, 6, 8, 9]. 취약점이 운영 환경에 도달하기 전인 파이프라인 단계에서 문제를 해결함으로써 문제 수정에 드는 비용과 시간을 크게 줄일 수 있습니다 [3, 9, 21].
-- **로컬 검증 도구와의 상호 보완:** 개발자가 로컬에서 사용하는 Git Hook(예: Husky 및 lint-staged)이 코드를 커밋하기 전 1차적인 방어선 역할을 한다면, CI/CD 파이프라인은 최종적인 권한을 가진 안전망 역할을 합니다 [22-24]. 개발자가 로컬 검사를 우회할 수 있는 가능성이 있기 때문에, 파이프라인에서 전체 린팅, 테스트 도구 실행, 타입 검사 및 빌드 검증을 엄격하게 재실행하는 것이 필수적입니다 [23, 25-27].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[자동화된 코드 리뷰(Automated Code Review)]], [[정적 애플리케이션 보안 테스트(SAST)]], [[품질 게이트(Quality Gates)]], [[시프트 레프트(Shift-Left)]]
-- **Projects/Contexts:** [[소프트웨어 개발 수명 주기(SDLC)]], [[데브섹옵스(DevSecOps)]], [[풀 리퀘스트(Pull Request) 워크플로우]]
-- **Contradictions/Notes:** CI/CD 파이프라인에 SonarQube Cloud나 대규모 SAST 도구를 통합하면 코드 품질과 보안을 강력하게 통제할 수 있지만, 일부 환경에서는 파이프라인 실행 시간이 추가로 소요될 수 있다는 단점이 존재합니다 [5, 17, 28]. 또한, 로컬 Git Hook 환경이 효율적이더라도 CI 환경에서의 전체 검증 과정을 결코 대체할 수 없으며, 반드시 CI 파이프라인의 후속 검증이 동반되어야 한다고 강조됩니다 [23, 24, 29].
-
----
-*Last updated: 2026-04-18*
-- Raw Source: [[00_Raw/2026-04-20/CI_CD 파이프라인.md]]
----
diff --git a/Programming & Language/CST (구체 구문 트리).md b/Programming & Language/CST (구체 구문 트리).md
deleted file mode 100644
index a8947ae7..00000000
--- a/Programming & Language/CST (구체 구문 트리).md	
+++ /dev/null
@@ -1,37 +0,0 @@
----
-id: P-REINFORCE-AUTO-ECB052
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - CST (구체 구문 트리)"
----
-
-# [[CST (구체 구문 트리)]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> CST(구체 구문 트리) 또는 파스 트리(parse tree)는 문맥 자유 문법(context-free grammar)의 트리 표현으로, 컴파일러가 코드를 어떻게 이해하는지 보여주는 공식적인 표현 방식입니다 [1]. AST(추상 구문 트리)와 달리 포괄적인 구문 요소뿐만 아니라 미세한 문체, 어휘 및 레이아웃(공백, 들여쓰기 등)의 세부 사항까지 코드의 모든 측면을 정밀하게 포착하여 계층적 구조로 렌더링합니다 [2]. 이러한 특징으로 인해 코드 서식 지정이나 축소 등 레이아웃의 변화를 감지할 수 있어 프로그래머의 코딩 스타일을 분석하고 작성자를 식별하는 코드 스타일로메트리(Code stylometry)에 유용하게 활용됩니다 [3, 4].
-
-## 📖 구조화된 지식 (Synthesized Content)
-* **정의 및 구조**
-  CST는 주어진 문맥 자유 문법에 기반한 순서 트리(ordered tree)로, 루트(root), 비단말(Non-terminal) 노드, 단말(Terminal) 노드로 구성되어 컴파일러가 코드를 해석하는 계층적인 구조를 시각화합니다 [1, 2, 5]. 트리의 각 노드는 클래스 정의, 함수 정의 또는 변수 할당과 같은 명확한 코드 구성 요소와 연결됩니다 [2].
-
-* **AST(추상 구문 트리)와의 차이점**
-  구문 기능과 일부 어휘적 특징만 보존하고 레이아웃의 특징을 추상화하여 무시하는 AST와 달리, CST는 코드의 레이아웃(공백, 줄 바꿈, 들여쓰기 등)과 어휘적 세부 사항을 모두 포함합니다 [3, 4]. 예를 들어, 코드를 철저하게 다시 들여쓰기(re-indent)하는 소스-대-소스 변환을 수행할 경우 파싱된 후의 AST 구조는 동일하게 유지되지만, CST는 시각적이고 구조적으로 크게 변경됩니다 [3].
-
-* **코드 스타일로메트리(저자 식별)에서의 활용**
-  레이아웃 및 어휘적 특징이 개인의 코딩 스타일을 결정하는 핵심 요소이므로, 이를 포착하기 위해 코드 작성자 분류 모델에서 CST가 중요한 입력 데이터로 사용됩니다 [4, 6]. 구체적인 단말 노드 간의 경로를 해시화하여 나타낸 '경로 컨텍스트(path context)'의 집합(bag)은 입력된 소스 코드의 문체, 레이아웃 및 구문적 특징을 훌륭하게 유지합니다 [7, 8]. 한 연구 결과에 따르면 파이썬 소스 코드 분류에 AST 대신 CST를 도입했을 때 프로그래머의 식별 정확도가 51.00%에서 67.86%로 현저히 향상되었습니다 [6, 9].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[AST (추상 구문 트리)]], [[코드 스타일로메트리 (Code Stylometry)]], [[코드 포매팅 (Code formatting)]], [[코드 축소 (Code minification)]]
-- **Projects/Contexts:** [[코드 서식 지정과 축소가 코드 스타일로메트리(작성자 인식)에 미치는 영향을 평가하는 기계 학습 모델 분류 연구]]
-- **Contradictions/Notes:** 소스에 관련된 모순된 정보는 없으며, 기존의 주류 문헌들이 코드 표상을 위해 주로 AST를 사용하는 것에서 벗어나, 서식 지정과 축소에 따른 표면적 변화를 측정하기 위해 CST의 사용이 필수적이었다는 점을 강조합니다 [4].
-
----
-*Last updated: 2026-04-18*
-- Raw Source: [[00_Raw/2026-04-20/CST (구체 구문 트리).md]]
----
diff --git a/Programming & Language/Cache Side-Channel Attack.md b/Programming & Language/Cache Side-Channel Attack.md
deleted file mode 100644
index fdcf566c..00000000
--- a/Programming & Language/Cache Side-Channel Attack.md	
+++ /dev/null
@@ -1,35 +0,0 @@
----
-id: P-REINFORCE-AUTO-55C813
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Cache Side-Channel Attack"
----
-
-# [[Cache Side-Channel Attack]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 캐시 사이드 채널 공격(Cache Side-Channel Attack)은 공격자가 고정밀 타이머를 사용하여 CPU 또는 GPU 캐시의 접근 속도(예: L1 캐시와 메인 메모리 간의 지연 시간 차이)를 측정함으로써, 보호된 비밀 메모리의 내용을 추론하고 유출하는 보안 취약점입니다 [1-3]. 현대 프로세서의 추측 실행(Speculative execution)과 분기 예측을 악용하는 스펙터(Spectre)와 멜트다운(Meltdown)이 대표적이며, 이를 방어하기 위해 웹 브라우저들은 타이머 정밀도를 의도적으로 낮추고 분기 없는 보안 검사(Branchless security checks)를 도입해야 했습니다 [4-7].
-
-## 📖 구조화된 지식 (Synthesized Content)
-*   **작동 원리 및 추측 실행 악용:** 공격자는 고해상도 타이밍 측정을 통해 캐시 적중률(Cache hit rate)과 메모리 접근 패턴을 관찰합니다 [1, 8]. 스펙터(Spectre) 공격의 경우, 현대 CPU가 성능 최적화를 위해 제공하는 '추측 실행'을 악용합니다. CPU가 조건부 분기(Branch)를 예측하여 미리 실행할 때 메인 메모리에서 가장 빠르고 작은 L1 캐시로 데이터를 로드하는데, 예측이 틀려 실행이 롤백되더라도 L1 캐시로 가져온 데이터는 그대로 남게 됩니다 [3, 9, 10]. 공격자는 타이밍 속도를 측정하여 CPU가 추측 실행 단계에서 어떤 메모리(캐시 라인)를 로드했는지 알아낼 수 있습니다 [3, 11].
-*   **GPU 환경에서의 캐시 공격:** CPU뿐만 아니라 GPU 환경에서도 캐시 사이드 채널 공격이 보고되었습니다. WebGL 환경에서 GPU에 Rowhammer 공격을 수행한 사례가 있으며, 이때 타임스탬프 쿼리(Timestamp queries)가 제공하는 고정밀 타이밍을 통해 GPU 캐시 미스율을 확인하고 물리적 메모리 구조를 파악하는 방식을 사용했습니다 [8].
-*   **웹 브라우저의 방어 메커니즘 (Mitigations):**
-    *   **타이머 정밀도 감소(Timer Quantization) 및 지터(Jitter) 도입:** 브라우저 엔진들은 `performance.now()`와 같은 타이머의 해상도를 1ms 또는 100 마이크로초 등으로 대폭 낮추었습니다 [4, 7, 12]. 또한 공격자가 통계적 평균을 내어 고해상도 클럭을 재구성하는 것을 막기 위해, 반환되는 시간에 무작위 변동 값인 '지터(Jitter)'를 추가했습니다 [4]. WebGPU 환경의 타임스탬프 쿼리 역시 보안을 위해 해상도가 제한(Quantized 및 Coarsened)됩니다 [1, 13, 14].
-    *   **위험 기능 비활성화:** 고해상도 타이머를 생성하는 데 악용될 수 있는 `SharedArrayBuffer` 기능과 정밀한 타이밍을 제공하던 `EXT_disjoint_timer_query` 확장 기능 등을 비활성화하거나 접근을 엄격히 제한했습니다 [1, 6, 7].
-    *   **분기 없는 보안 검사(Branchless Security Checks):** 공격자가 추측 실행의 분기(Branch)를 제어할 수 있게 됨에 따라, 분기 명령어에 의존하는 기존의 보안 체계는 무력화되었습니다 [5, 11, 15]. 이에 대응하기 위해 WebKit과 Blink 같은 엔진은 인덱스 마스킹(Index masking)과 포인터 포이즈닝(Pointer poisoning)과 같이 조건부 분기를 사용하지 않는 형태의 보안 검사 방식을 새롭게 도입했습니다 [4, 7, 16, 17].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[Spectre]], [[Meltdown]], [[Speculative Execution]], [[Timestamp Quantization]]
-- **Projects/Contexts:** [[WebKit]], [[WebGPU]], [[WebGL]]
-- **Contradictions/Notes:** 소스에 따르면, 그래픽 파이프라인 최적화 및 렌더링 병목 현상을 해결하려는 개발자들은 나노초 단위의 고정밀 타이머를 절대적으로 필요로 하지만, 보안 측면에서는 이러한 고해상도 타이머가 캐시 사이드 채널 공격의 주요 수단이 되기 때문에 브라우저 벤더들이 타이머의 해상도를 의도적으로 제한(Coarsening)해야만 하는 기능적 상충 관계(Trade-off)가 발생하고 있습니다 [1, 13, 14, 18].
-
----
-*Last updated: 2026-04-19*
-- Raw Source: [[00_Raw/2026-04-20/Cache Side-Channel Attack.md]]
----
diff --git a/Programming & Language/Cache miss rates.md b/Programming & Language/Cache miss rates.md
deleted file mode 100644
index b2a5066d..00000000
--- a/Programming & Language/Cache miss rates.md	
+++ /dev/null
@@ -1,33 +0,0 @@
----
-id: P-REINFORCE-AUTO-E946BD
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Cache miss rates"
----
-
-# [[Cache miss rates]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 소스에 따르면, 캐시 미스 비율(Cache miss rates) 및 캐시 적중률(Cache hit rates)은 고해상도 타이머를 통해 관찰될 수 있는 메모리 접근 패턴의 지표입니다 [1, 2]. 공격자는 이를 분석하여 CPU 및 GPU의 물리적 메모리 구조를 파악하고, 스펙터(Spectre), 멜트다운(Meltdown), 로우해머(Rowhammer)와 같은 심각한 보안 취약점을 악용할 수 있습니다 [1, 2]. 결과적으로 브라우저 벤더들은 이러한 타이밍 기반의 부채널 공격(side-channel attack)을 방지하기 위해 타임스탬프 쿼리의 정밀도를 의도적으로 제한하는 방어 기제를 채택하고 있습니다 [1, 3].
-
-## 📖 구조화된 지식 (Synthesized Content)
-- **보안 취약점 악용 매개체:** 보안 연구자들에 따르면, 고정밀 타이머(high-fidelity timing)를 사용해 캐시 미스 비율(또는 캐시 적중률)과 메모리 접근 패턴을 관찰할 수 있으며, 이는 스펙터와 멜트다운 같은 보안 취약점 악용을 용이하게 합니다 [1].
-- **로우해머(Rowhammer) 공격과 GPU 캐시 미스:** WebGL 환경에서 타임스탬프 쿼리를 이용해 고정밀 시간을 측정하면 공격자는 GPU의 캐시 미스 비율을 확인할 수 있습니다 [2]. 이를 통해 GPU 물리적 메모리의 레이아웃을 파악하고, 특정 메모리 비트를 변조(bit flip)시키는 로우해머 공격을 가하여 페이지 테이블을 속이는 등의 악의적인 행위가 가능합니다 [2].
-- **타이밍 기반 정보 유출 (Timing-based information leak):** 스펙터(Spectre) 공격의 성공은 고정밀 타이밍 측정에 의존합니다 [4]. 데이터가 CPU의 L1 캐시에 존재할 때의 접근 지연 시간과 캐시 미스로 인해 메인 메모리에 접근해야 할 때의 지연 시간 차이를 측정함으로써, 공격자는 메모리 내부의 기밀 데이터를 유추해낼 수 있습니다 [4, 5].
-- **브라우저의 방어 메커니즘 (타이머 정밀도 제한):** 캐시 미스에 따른 미세한 타이밍 차이(서브 마이크로초 단위)를 공격자가 관찰하지 못하도록, 브라우저 엔진들은 `performance.now()`의 정밀도를 1ms 단위로 낮추거나(reduce timer precision) 격리된 환경(Isolated Context)에서 WebGPU 타임스탬프 쿼리의 해상도를 100 마이크로초 등으로 제한(quantization)하는 보안 조치를 취하고 있습니다 [1, 3, 6, 7].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[Spectre]], [[Meltdown]], [[Rowhammer]], [[Timestamp Queries]]
-- **Projects/Contexts:** [[WebGPU Timestamp Queries Quantization]], [[WebKit Security Mitigations]]
-- **Contradictions/Notes:** 소스에서는 캐시 미스 비율이 일반적인 시스템 성능 최적화 지표로 다루어지기보다는, 고해상도 타이머를 악용한 사이드 채널 보안 공격(side-channel attacks)을 가능하게 하는 위험 요소의 관점으로만 집중적으로 설명되어 있습니다 [1, 2, 4].
-
----
-*Last updated: 2026-04-19*
-- Raw Source: [[00_Raw/2026-04-20/Cache miss rates.md]]
----
diff --git a/Programming & Language/Causal Tracing (인과적 추적).md b/Programming & Language/Causal Tracing (인과적 추적).md
deleted file mode 100644
index 3aa740cf..00000000
--- a/Programming & Language/Causal Tracing (인과적 추적).md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-BFC9FF
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Causal Tracing (인과적 추적)"
----
-
-# [[Causal Tracing (인과적 추적)]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Causal Tracing (인과적 추적).md]]
----
diff --git a/Programming & Language/Cellular-Automata.md b/Programming & Language/Cellular-Automata.md
deleted file mode 100644
index 6402a384..00000000
--- a/Programming & Language/Cellular-Automata.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-D84732
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Cellular-Automata"
----
-
-# [[Cellular-Automata]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Cellular-Automata.md]]
----
diff --git a/Programming & Language/Chaos Theory.md b/Programming & Language/Chaos Theory.md
deleted file mode 100644
index 102eff6e..00000000
--- a/Programming & Language/Chaos Theory.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-1F2821
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Chaos Theory"
----
-
-# [[Chaos Theory]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Chaos Theory.md]]
----
diff --git a/Programming & Language/Chaos-Theory.md b/Programming & Language/Chaos-Theory.md
deleted file mode 100644
index efb7ed05..00000000
--- a/Programming & Language/Chaos-Theory.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-639E39
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Chaos-Theory"
----
-
-# [[Chaos-Theory]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Chaos-Theory.md]]
----
diff --git a/Programming & Language/Cheneys Algorithm.md b/Programming & Language/Cheneys Algorithm.md
deleted file mode 100644
index 419a6f12..00000000
--- a/Programming & Language/Cheneys Algorithm.md	
+++ /dev/null
@@ -1,40 +0,0 @@
----
-id: P-REINFORCE-AUTO-52B523
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Cheneys Algorithm"
----
-
-# [[Cheneys Algorithm]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> Cheney's Algorithm은 V8 자바스크립트 엔진의 마이너 가비지 컬렉터인 스캐빈저(Scavenger)에서 메모리를 관리하기 위해 사용하는 가비지 컬렉션 알고리즘입니다 [1, 2]. 이 알고리즘은 메모리의 '새로운 공간(New-space)'을 동일한 크기를 가진 'from-space'와 'to-space'라는 두 개의 반공간(Semi-space)으로 나누어 작동합니다 [1, 2]. 살아있는 객체만을 from-space에서 to-space로 복사하고 압축(compact)함으로써, 빠른 메모리 할당과 캐시 지역성 향상을 달성합니다 [1].
-
-## 📖 구조화된 지식 (Synthesized Content)
-- **반공간(Semi-space) 구조 및 역할 교환**: 알고리즘은 할당 공간이 가득 찰 때 to-space와 from-space의 역할을 맞바꾸는 것으로 시작합니다 [1]. 이를 통해 모든 기존 객체는 from-space에 위치하게 되며, 이후 시스템은 살아있는 객체만을 찾아내어 to-space로 복사하거나 '오래된 공간(old-space)'으로 승격(promote)시킵니다 [1].
-- **포인터를 활용한 너비 우선 탐색(BFS)**: 알고리즘은 내부적으로 to-space를 가리키는 두 개의 포인터를 유지합니다 [3]. 
-  - `allocationPtr`: 다음 객체를 할당할 위치의 포인터입니다 [3].
-  - `scanPtr`: 살아있는 포인터를 찾기 위해 스캔할 다음 객체의 포인터입니다 [3].
-  - 이 두 포인터는 논리적으로 너비 우선 탐색(BFS) 대기열(Queue)의 맨 앞과 맨 뒤와 같은 역할을 합니다 [3].
-- **객체 스캔 및 복사 과정**:
-  1. 루트(roots)에서 도달할 수 있는 새로운 공간의 객체들을 복사하여 알고리즘을 초기화합니다 [4].
-  2. `scanPtr`를 증가시켜 대기열에서 객체를 하나씩 꺼내고, 해당 객체의 내부 포인터들을 추적합니다 [4].
-  3. 발견한 포인터가 아직 복사되지 않은 from-space의 객체를 가리킨다면, `allocationPtr`를 증가시켜 해당 객체를 to-space의 끝으로 복사하고 기존 객체의 첫 번째 워드(word)에 새 복사본을 가리키는 전달 주소(forwarding address)를 남깁니다 [4].
-  4. 만약 포인터가 이미 복사된 from-space의 객체(전달 주소가 존재하는 객체)를 가리킨다면, 해당 포인터가 to-space의 새로운 복사본을 가리키도록 업데이트합니다 [4].
-- **종료 조건 및 가비지 처리**: `scanPtr`가 `allocationPtr`에 도달하여 더 이상 처리할 객체가 남지 않게 되면 알고리즘은 종료됩니다 [5]. 이 시점에 from-space에 남아있는 모든 데이터는 가비지(쓰레기)로 간주되어 메모리가 해제되거나 다른 목적으로 재사용됩니다 [5].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[Scavenge (Minor GC)]], [[Semi-space Design]], [[Garbage Collection]]
-- **Projects/Contexts:** [[V8 JavaScript Engine]]
-- **Contradictions/Notes:** 과거의 V8 버전들은 동기식(synchronous) 구조의 기본 Cheney's algorithm을 사용했으나, V8 v6.2 이후부터는 다중 코어 환경의 이점을 활용하기 위해 Halstead semispace copying collector와 유사한 방식의 병렬 스캐빈저(Parallel Scavenger) 알고리즘으로 발전하여 사용되고 있습니다 [6].
-
----
-*Last updated: 2026-04-19*
-- Raw Source: [[00_Raw/2026-04-20/Cheney's Algorithm.md]]
----
diff --git a/Programming & Language/Chrome DevTools Memory Panel.md b/Programming & Language/Chrome DevTools Memory Panel.md
deleted file mode 100644
index de3005cc..00000000
--- a/Programming & Language/Chrome DevTools Memory Panel.md	
+++ /dev/null
@@ -1,42 +0,0 @@
----
-id: P-REINFORCE-AUTO-5AE3F9
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Chrome DevTools Memory Panel"
----
-
-# [[Chrome DevTools Memory Panel]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> Chrome DevTools Memory Panel은 자바스크립트 애플리케이션 및 Node.js 환경에서 힙(Heap) 메모리를 프로파일링하여 메모리 누수를 진단하고 메모리 분포를 분석하는 도구입니다 [1-3]. 이 패널은 주로 힙 스냅샷(Heap snapshot), 타임라인의 할당 계측(Allocation instrumentation on timeline), 할당 샘플링(Allocation sampling)이라는 세 가지 핵심 기능을 제공합니다 [2, 4]. 개발자는 이 패널을 활용해 가비지 컬렉션(GC) 이후에도 메모리에 남아 있는 객체의 참조 체인을 역추적하고 근본 원인을 파악할 수 있습니다 [1, 2, 5, 6].
-
-## 📖 구조화된 지식 (Synthesized Content)
-*   **주요 프로파일링 도구 (Profiling Tools)**
-    *   **힙 스냅샷 (Heap snapshot):** 특정 시점의 전체 객체 그래프를 캡처합니다 [2]. 객체 자체가 보유한 메모리 크기인 'Shallow size'와 해당 객체를 삭제했을 때 연쇄적으로 확보할 수 있는 메모리 크기인 'Retained size'를 제공합니다 [7]. 요약(Summary), 비교(Comparison), 포함(Containment), 통계(Statistics) 뷰를 지원하며, 두 스냅샷을 비교하여 그 사이에 할당된 객체를 필터링할 수 있습니다 [8-10].
-    *   **타임라인의 할당 계측 (Allocation instrumentation on timeline):** 힙 프로파일러의 상세 스냅샷 정보와 타임라인의 점진적 업데이트를 결합한 기능입니다 [11, 12]. 최대 50ms 간격으로 스냅샷을 기록하며, 타임라인 상에 파란색 막대(기록 종료 시점까지 살아있는 객체)와 회색 막대(이미 가비지 컬렉션된 객체)를 표시합니다 [13-15]. 특정 시간대로 마우스를 드래그하여 확대하면 해당 시점에 생성되어 누수가 의심되는 객체를 집중적으로 분석할 수 있습니다 [2, 16].
-    *   **할당 샘플링 (Allocation sampling):** 모든 할당을 추적하는 대신 통계적 샘플링 방식을 사용하여 실행 오버헤드를 낮춘 가벼운 도구로, 프로덕션 환경의 프로파일링에 적합합니다 [4].
-
-*   **보유자 패널 및 객체 식별 (Retainers and Object Identification)**
-    *   특정 생성자나 객체를 클릭하면 하단(또는 측면)의 Retainers 패널에 해당 객체를 메모리에 살아있게 만드는 참조 체인(Retaining tree)이 나타납니다 [2, 5, 16]. 개발자는 이 경로를 전역 객체(Global object)나 GC 루트까지 따라가면서 불필요한 참조를 제거할 단서를 얻습니다 [1, 2, 6, 17].
-    *   가비지 컬렉션 중에는 객체의 주소가 이동할 수 있으므로, V8 엔진은 메모리 상태를 정확히 비교하기 위해 각 객체에 `@` 기호가 붙은 영구적인 식별자 ID(예: `@12345`)를 부여합니다 [13, 18, 19].
-
-*   **내부 객체 및 필터링 고려사항 (Internal Objects & Filtering)**
-    *   원시 힙 스냅샷에는 애플리케이션 로직과 직접적인 관련이 없는 `(compiled code)`, `(array)`, `system / Context` 등 V8 내부 객체가 수천 개 이상 포함될 수 있습니다 [20-23]. 따라서 분석 시 'Constructor' 필터를 사용하여 애플리케이션 고유의 객체에 초점을 맞추는 것이 권장됩니다 [20].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[Heap Snapshot]], [[Garbage Collection]], [[Memory Leak]], [[Retaining Path]]
-- **Projects/Contexts:** [[V8 Engine]], [[Node.js]]
-- **Contradictions/Notes:** 
-  - 스냅샷 상에서 메모리 그래프가 증가한다고 해서 무조건 누수(Leak)인 것은 아닙니다. 캐시(Caches), 실행 취소 기록(Undo histories), 가상화된 리스트 버퍼 등은 의도적으로 데이터를 보존하기 때문입니다. 의도된 보존과 우발적인 메모리 누수를 구별하는 것이 중요합니다 [20].
-  - DevTools 콘솔에서 `console.log`로 출력된 객체는 콘솔에서 도달 가능하기 때문에 참조가 유지되어 메모리 누수로 나타날 수 있습니다. 누수 조사 중에는 콘솔을 지우거나 큰 객체를 로깅하지 않아야 합니다 [20].
-
----
-*Last updated: 2026-04-19*
-- Raw Source: [[00_Raw/2026-04-20/Chrome DevTools Memory Panel.md]]
----
diff --git a/Programming & Language/Chrome DevTools(크롬 개발자 도구).md b/Programming & Language/Chrome DevTools(크롬 개발자 도구).md
deleted file mode 100644
index 199cbfe0..00000000
--- a/Programming & Language/Chrome DevTools(크롬 개발자 도구).md	
+++ /dev/null
@@ -1,36 +0,0 @@
----
-id: P-REINFORCE-AUTO-663B99
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Chrome DevTools(크롬 개발자 도구)"
----
-
-# [[Chrome DevTools(크롬 개발자 도구)]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> Chrome DevTools(크롬 개발자 도구)는 JavaScript 애플리케이션 및 브라우저 환경에서 메모리 누수를 탐지하고 성능을 분석하기 위해 다양한 프로파일링 도구를 제공하는 개발자용 인터페이스입니다 [1-3]. 주로 메모리 패널(Memory panel)을 통해 힙 스냅샷을 캡처하거나 시간에 따른 메모리 할당을 추적하여, 가비지 컬렉터(GC)에 의해 해제되지 않은 객체와 그 참조 원인을 식별하는 데 사용됩니다 [1, 4, 5].
-
-## 📖 구조화된 지식 (Synthesized Content)
-* **메모리 패널(Memory Panel)의 주요 도구:** Chrome DevTools의 메모리 패널은 메모리 누수 식별을 위해 힙 스냅샷(Heap snapshot), 타임라인의 할당 계측(Allocation instrumentation on timeline), 할당 샘플링(Allocation sampling)의 세 가지 주요 도구를 제공합니다 [1, 6].
-* **힙 스냅샷(Heap Snapshot):** 특정 시점의 전체 객체 그래프를 캡처하여 JavaScript 객체 및 관련 DOM 노드에 의한 메모리 분포를 보여줍니다 [1, 7]. 요약(Summary), 비교(Comparison), 포함(Containment), 통계(Statistics) 뷰를 제공하여 메모리를 세밀하게 분석할 수 있습니다 [8]. 
-    * 요약 뷰에서는 객체의 고유한 메모리 크기인 얕은 크기(Shallow size)와, 삭제 시 확보할 수 있는 보존 크기(Retained size)를 확인할 수 있습니다 [9]. 
-    * 생성자 필터를 사용해 분리된 DOM 노드가 유지하는 객체나 중복된 문자열을 필터링함으로써 비효율적인 메모리 사용을 추적할 수 있습니다 [10].
-* **할당 타임라인(Allocation Timeline):** 힙 프로파일러의 상세한 스냅샷 정보와 타임라인 패널의 점진적 업데이트를 결합한 도구입니다 [2]. 기록하는 동안 주기적(최대 50ms 간격)으로 힙 스냅샷을 찍어 메모리 할당을 시각화합니다 [4, 11]. 타임라인에 파란색 막대로 표시된 객체는 할당 후 현재까지 살아있는 객체(누수 후보)이며, 회색 막대는 가비지 컬렉션된 객체를 의미합니다 [1, 5, 11, 12].
-* **보존자(Retainers) 및 경로 추적:** DevTools는 선택한 객체를 가리키는 다른 객체들의 참조 경로(가비지 컬렉션 루트로부터의 경로)를 보여주는 보존자 섹션을 제공합니다 [13-15]. 특정 보존자를 무시(Ignore this retainer) 처리하여 다른 어떤 객체가 해당 객체의 메모리를 유지하고 있는지 코드를 수정하지 않고도 확인할 수 있습니다 [14].
-* **Node.js 연동 분석:** `chrome://inspect`를 통해 실행 중인 Node.js 프로세스에 연결하여 프로덕션 환경의 메모리 누수 상황을 분석할 수도 있습니다 [16]. 또한 Node.js에서 네이티브 프로파일링을 통해 생성된 `.heapprofile` 파일을 DevTools에 로드하면 함수 수준의 할당 내역을 파악할 수 있습니다 [17].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[Memory Leak(메모리 누수)]], [[Garbage Collection(가비지 컬렉션)]], [[Heap Snapshot(힙 스냅샷)]], [[Allocation Timeline(할당 타임라인)]]
-- **Projects/Contexts:** [[Node.js 프로세스 모니터링 및 메모리 분석]], [[브라우저 DOM 누수 탐지 및 렌더링 최적화]]
-- **Contradictions/Notes:** 소스에 관련 정보가 부족합니다. (제공된 소스 내에서 Chrome DevTools의 기능이나 메모리 분석 방법론에 대해 상충되는 주장은 발견되지 않았습니다.)
-
----
-*Last updated: 2026-04-19*
-- Raw Source: [[00_Raw/2026-04-20/Chrome DevTools(크롬 개발자 도구).md]]
----
diff --git a/Programming & Language/Chrome V8 Heap Analysis.md b/Programming & Language/Chrome V8 Heap Analysis.md
deleted file mode 100644
index 29ee9468..00000000
--- a/Programming & Language/Chrome V8 Heap Analysis.md	
+++ /dev/null
@@ -1,45 +0,0 @@
----
-id: P-REINFORCE-AUTO-7DF5C6
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Chrome V8 Heap Analysis"
----
-
-# [[Chrome V8 Heap Analysis]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> Chrome V8 엔진의 힙(Heap)은 자바스크립트 실행 중 동적으로 생성되는 객체와 데이터를 저장하는 런타임 메모리 영역입니다 [1]. V8 힙은 객체의 수명과 특성에 따라 여러 세대 공간(New Space, Old Space 등)으로 세분화되어 세대별 가비지 컬렉션(Generational Garbage Collection) 메커니즘에 의해 관리됩니다 [2-4]. 힙 메모리 분석은 메모리 누수를 진단하거나 최적화를 수행하는 데 필수적이며, V8 샌드박스를 우회하려는 악의적인 메모리 손상 익스플로잇의 흔적을 식별하는 메모리 포렌식에도 활용됩니다 [5-10].
-
-## 📖 구조화된 지식 (Synthesized Content)
-* **힙 메모리의 세부 구조 (Heap Organization):**
-  V8은 가비지 컬렉터의 성능을 최적화하기 위해 힙을 여러 역할의 공간(Space)으로 나눕니다 [4]. 
-  * **New-space (Young Generation):** 대부분의 새 객체가 처음 할당되는 작고 수집이 빠른 공간입니다 [2, 4].
-  * **Old-space (Old Generation):** New-space에서 살아남은 객체들이 승격(Promotion)되어 저장되는 공간으로, 포인터가 포함된 'Old-pointer-space'와 원시 데이터만 있는 'Old-data-space'로 나뉩니다 [2, 4, 11].
-  * **기타 특수 공간:** 다른 공간의 크기 제한을 초과하는 객체를 위한 'Large-object-space', JIT 컴파일된 실행 코드가 저장되는 'Code-space', 그리고 크기가 균일한 내부 구조체(Map, Cell 등)를 위한 공간으로 구성됩니다 [2, 4]. 각 공간은 운영체제로부터 mmap을 통해 할당받은 연속적인 메모리 청크인 '페이지(Page)'(통상 1MB 또는 512KB)로 관리됩니다 [12-14].
-
-* **가비지 컬렉션 메커니즘 (Garbage Collection Dynamics):**
-  대대적인 성능 저하를 방지하기 위해 V8은 대부분의 객체가 짧은 시간 안에 죽는다는 '세대별 가설(Generational hypothesis)'을 기반으로 작동합니다 [3, 14, 15].
-  * **Minor GC (Scavenger):** New-space가 가득 차면 실행되며, Cheney의 알고리즘에 따라 활성 객체만 식별하여 두 개의 반공간(From-Space, To-Space) 사이에서 복사(Evacuation)하고 압축합니다 [16-26].
-  * **Major GC (Mark-Sweep-Compact):** Old-space를 관리하며, 전체 힙에서 도달 가능한 객체를 마킹(Marking)하고, 죽은 객체의 메모리를 해제(Sweeping)하며, 필요시 메모리 단편화를 제거하기 위해 압축(Compacting)을 수행합니다 [27-29]. 최신 Orinoco GC는 이 과정을 메인 스레드 중단 없이 병렬(Parallel), 동시(Concurrent), 점진적(Incremental)으로 수행합니다 [30-39].
-
-* **힙 메모리 누수 분석 (Heap Analysis & Memory Leaks):**
-  개발자는 Chrome DevTools의 'Heap snapshot' 및 'Allocation instrumentation on timeline'을 사용하여 힙에 저장된 객체, 할당 시점, 유지 경로(Retaining path)를 분석할 수 있습니다 [40-49]. 클로저(Closure)에 의한 잘못된 참조, 잊혀진 타이머나 이벤트 리스너 등이 주요 누수 원인입니다 [42, 50-54]. 또한, `--trace-gc` 플래그를 사용하여 프로세스의 GC 수행 횟수, 소요 시간, 힙 크기의 변화량(톱니바퀴 또는 래칫 패턴)을 추적할 수 있습니다 [55-62].
-
-* **보안 제한 및 익스플로잇 아티팩트 (Security & Exploitation Artifacts):**
-  V8은 포인터 압축(Pointer Compression) 기법을 사용하여 포인터 크기를 32비트로 줄이고, 전체 힙을 4GB 크기의 'V8 Memory Cage' 내에 가둡니다 [63-68]. 공격자들은 메모리 손상 취약점(OOB 등)을 활용해 V8의 힙에 개입하여 객체 주소를 유출하는 `addrof`나 위조 객체를 만드는 `fakeobj` 등의 원시 공격(Primitives)을 수행합니다 [10, 68-78]. 이러한 공격이 실패하거나 진행될 때, `JSArray`의 길이 손상(CorruptedLength)이나 `ElementsKind`와 백킹 스토어의 타입 불일치(ElementsMapMismatch)와 같은 구조적 힙 아티팩트가 메모리에 남게 되어 포렌식 탐지의 신호가 됩니다 [75, 76, 79-82].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[Garbage Collection]], [[V8 Memory Cage]], [[Pointer Compression]], [[Generational Hypothesis]], [[Mark-Sweep-Compact]]
-- **Projects/Contexts:** [[Orinoco Garbage Collector]], [[Chrome DevTools Memory Panel]], [[v8-forensics]]
-- **Contradictions/Notes:** 소스에 관련 정보가 부족합니다. (소스 간의 명백한 모순점이나 상충하는 주장은 발견되지 않았습니다.)
-
----
-*Last updated: 2026-04-19*
-- Raw Source: [[00_Raw/2026-04-20/Chrome V8 Heap Analysis.md]]
----
diff --git a/Programming & Language/Chrome 렌더러 프로세스 V8 샌드박스 보안.md b/Programming & Language/Chrome 렌더러 프로세스 V8 샌드박스 보안.md
deleted file mode 100644
index d2a15fcc..00000000
--- a/Programming & Language/Chrome 렌더러 프로세스 V8 샌드박스 보안.md	
+++ /dev/null
@@ -1,30 +0,0 @@
----
-id: P-REINFORCE-AUTO-3832A0
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Chrome 렌더러 프로세스 V8 샌드박스 보안"
----
-
-# [[Chrome 렌더러 프로세스 V8 샌드박스 보안]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> V8 샌드박스(또는 메모리 케이지)는 Chrome 103 및 이후 이를 도입한 Electron 등에서 V8 JavaScript 엔진 내 발생하는 취약점 악용을 근본적으로 방지하기 위해 설계된 보안 기술입니다 [1, 2]. 힙 내에 실제 메모리 포인터를 저장하는 대신 예약된 메모리 영역의 기준 주소로부터의 32비트 오프셋(offset)만 저장하는 포인터 압축(Pointer Compression) 기술을 사용합니다 [2-4]. 이를 통해 공격자가 메모리 손상 버그를 악용하더라도 그 피해 및 메모리 접근 범위를 4GB 크기의 샌드박스 내부로 제한하여 프로세스 전체의 탈취를 막고 보안을 강화합니다 [2, 5].
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[Pointer Compression]], [[Type Confusion]], [[ArrayBuffer]], [[Just-In-Time (JIT) Compiler]]
-- **Projects/Contexts:** [[Chrome 103]], [[Electron 21]]
-- **Contradictions/Notes:** 소스는 V8 샌드박스와 포인터 압축 기술이 보안, 성능, 메모리 사용량 측면에서 큰 이점을 제공한다고 설명하지만, 이로 인해 V8 힙의 최대 크기가 4GB로 제한되는 명확한 단점(trade-off)이 존재한다고 지적합니다 [5, 14]. 대용량 메모리가 필요한 특수한 경우, 포인터 압축을 비활성화한 사용자 지정 빌드를 사용하거나 하위 프로세스로 작업을 분리해야 할 수도 있습니다 [15].
-
----
-*Last updated: 2026-04-19*
-- Raw Source: [[00_Raw/2026-04-20/Chrome 렌더러 프로세스 V8 샌드박스 보안.md]]
----
diff --git a/Programming & Language/Chromium.md b/Programming & Language/Chromium.md
deleted file mode 100644
index 017f9da0..00000000
--- a/Programming & Language/Chromium.md	
+++ /dev/null
@@ -1,32 +0,0 @@
----
-id: P-REINFORCE-AUTO-6038C1
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Chromium"
----
-
-# [[Chromium]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> Chromium(또는 Chrome)은 V8 자바스크립트 엔진을 내장(embed)하여 실행하는 기반 웹 브라우저 프로젝트입니다 [1-3]. 제공된 소스에서 Chromium은 V8 메모리 케이지 도입과 같은 보안 정책을 선도하고 [4, 5], 브라우저 렌더링의 유휴 시간(idle time)을 활용해 가비지 컬렉션을 효율적으로 수행하며 [2], 강력한 메모리 프로파일링 및 추적(Tracing) 인프라를 제공하는 핵심 호스트 환경으로 설명됩니다 [1, 6, 7].
-
-## 📖 구조화된 지식 (Synthesized Content)
-- **보안 및 V8 메모리 케이지 적용:** Chromium은 보안 계층을 강화하기 위해 Chrome 103 버전부터 V8 샌드박스 포인터(V8 메모리 케이지)를 활성화했습니다 [4]. 이는 JIT 엔진의 타입 혼동 버그를 악용하여 공격자가 프로세스의 임의 메모리를 읽고 쓰는 치명적인 공격을 방지하기 위한 설계입니다 [5, 8]. Electron과 같은 프레임워크는 독자적인 버그나 보안 취약점을 유발하지 않고 강력한 Chromium 보안 팀의 작업 성과를 그대로 활용하기 위해, Chromium의 복잡한 V8 내부 구성과 최대한 일치하도록 아키텍처를 유지합니다 [9].
-- **렌더링 유휴 시간(Idle Time)과 GC 연동:** 브라우저 환경에서 Chromium은 초당 60프레임(FPS)을 유지하기 위해 각 프레임당 약 16.6ms의 렌더링 시간을 가집니다 [2]. 만약 애니메이션 작업이 예상보다 일찍 끝나면, Chromium은 남는 유휴 시간을 활용해 V8 가비지 컬렉터가 큐에 쌓아둔 '유휴 작업(Idle tasks)'을 사전에 실행하여 성능 저하(jank)를 방지할 수 있습니다 [2]. 또한, Chrome의 렌더러 엔진인 Blink는 'Oilpan'이라는 독자적인 가비지 컬렉터를 보유하고 있으며, V8의 메인 GC인 Orinoco와 원활하게 상호 협력하도록 기술이 공유 및 이식되고 있습니다 [10].
-- **메모리 프로파일링 및 추적(Tracing) 인프라:** Chromium은 V8의 내부 메모리 상태 및 실행 흐름을 시각적으로 분석할 수 있는 Chrome Tracing 시스템(`chrome://tracing`)을 제공합니다 [1, 7]. 개발자나 보안 연구원은 `--track-gc-object-stats` 등의 플래그를 사용하여 V8 힙 객체 통계를 수집할 수 있습니다 [6, 7, 11]. 이러한 인프라는 V8 파서와 컴파일러의 메모리 소비 최적화 작업을 가능하게 했으며 [12, 13], 실패한 Chrome 렌더러의 충돌 덤프(Crash dumps)를 분석하여 메모리 손상 익스플로잇(Exploit) 공격 시도를 사전에 탐지하는 포렌식 기술의 기반이 됩니다 [3, 14, 15].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[V8 Engine]], [[V8 Memory Cage]], [[Blink]], [[Oilpan]], [[Garbage Collection]]
-- **Projects/Contexts:** [[Electron]], [[Google Chrome]], [[Orinoco]]
-- **Contradictions/Notes:** 제공된 소스 전반에서 'Chromium'과 'Chrome'이라는 명칭은 V8을 내장하는 브라우저 런타임 환경 및 보안/추적 인프라를 설명할 때 사실상 동일한 맥락으로 상호 교환되어 사용되고 있습니다 [2-4, 16].
-
----
-*Last updated: 2026-04-19*
-- Raw Source: [[00_Raw/2026-04-20/Chromium.md]]
----
diff --git a/Programming & Language/Clean as You Code.md b/Programming & Language/Clean as You Code.md
deleted file mode 100644
index 115a0317..00000000
--- a/Programming & Language/Clean as You Code.md	
+++ /dev/null
@@ -1,30 +0,0 @@
----
-id: P-REINFORCE-AUTO-B535E8
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Clean as You Code"
----
-
-# [[Clean as You Code]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 'Clean as You Code'는 레거시 백로그(legacy backlogs)를 처리하는 것에 집중하기보다는, 새로 작성되거나 변경된 코드의 문제를 즉시 해결하는 데 중점을 두는 방법론입니다 [1]. 이 접근 방식은 개발자가 코드를 병합하거나 수정할 때마다 코드 품질과 보안을 점진적이고 지속적으로 향상시키는 것을 목표로 합니다 [1, 2]. 소스에 관련 정보가 부족하지만, 주로 SonarQube 플랫폼에서 지속적인 코드 분석과 품질 관리를 장려하기 위해 사용하는 핵심 철학으로 소개됩니다 [1, 2].
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[SonarQube]], [[Technical Debt]], [[Static Application Security Testing (SAST)]]
-- **Projects/Contexts:** [[SonarQube 플랫폼을 활용한 CI/CD 파이프라인 내 자동화된 코드 리뷰 및 품질 게이트 적용]]
-- **Contradictions/Notes:** 소스 내에서 'Clean as You Code'라는 정확한 용어는 SonarQube의 방법론을 설명하는 단 한 문장[1]에만 등장합니다. 따라서 상세한 원리 및 배경에 대해서는 소스에 관련 정보가 부족하며, SonarQube의 코드 분석 철학을 바탕으로 내용을 합성했습니다.
-
----
-*Last updated: 2026-04-19*
-- Raw Source: [[00_Raw/2026-04-20/Clean as You Code.md]]
----
diff --git a/Programming & Language/Code Minification.md b/Programming & Language/Code Minification.md
deleted file mode 100644
index 1a298443..00000000
--- a/Programming & Language/Code Minification.md	
+++ /dev/null
@@ -1,33 +0,0 @@
----
-id: P-REINFORCE-AUTO-D932E1
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Code Minification"
----
-
-# [[Code Minification]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 코드 축소(Code Minification)는 브라우저 등으로 코드를 배포할 때 소스 코드의 크기를 최소화하고 전송 및 렌더링 시간을 단축하기 위해 사용되는 소프트웨어 최적화 기법입니다 [1, 2]. 이 기법은 코드의 본래 실행 의미(semantics)를 변경하지 않은 채, 공백, 줄 바꿈, 주석 등 의미가 없는 요소를 제거하고 변수 이름을 짧게 변경하는 등의 표면적 변환을 수행합니다 [1, 2]. 가독성을 높이는 코드 포매팅(Code formatting)과 달리 코드 축소는 오히려 코드의 가독성을 저하시키며, 주로 소프트웨어 개발 완료 후 배포 직전에 자동화 도구에 의해 실행됩니다 [3].
-
-## 📖 구조화된 지식 (Synthesized Content)
-*   **목적과 주요 기법:** 코드 축소의 주요 목적은 소스 코드 형태로 배포되는 소프트웨어의 용량을 줄이는 것이며, 특히 웹 개발 환경에서 페이지 렌더링 속도를 가속화하는 데 흔히 사용됩니다 [2]. 이를 위해 컴파일러나 인터프리터의 실행에 영향을 주지 않는 공백, 줄 바꿈, 주석 등을 제거할 뿐만 아니라, 변수나 클래스 등의 식별자(identifier) 이름을 간결한 대체어로 변경하는 다소 침투적인(invasive) 수정도 포함합니다 [2].
-*   **코드 가독성과 실행 의미 보존:** 축소된 코드는 원본 코드의 실행 의미(semantics)를 완벽하게 중립적으로 보존해야만 성립될 수 있습니다 [1, 2]. 다만, 인간이 읽기 쉽도록 일정한 스타일을 강제하는 코드 포매팅과 정반대로, 축소화 과정은 불필요한 모든 문자를 제거하므로 코드의 가독성을 크게 떨어뜨리는 결과를 낳습니다 [3]. 
-*   **코드 작성자 인식(Code Stylometry)에 미치는 영향:** 변수명 지정 방식, 공백 사용, 주석 처리 등은 프로그래머 고유의 코딩 스타일을 나타내는 주요 특징입니다. 코드 축소는 이러한 불필요한 문자 및 식별자 이름을 일괄적으로 지우거나 변경하므로 작성자 고유의 흔적을 훼손하게 됩니다 [4]. 관련 연구에 따르면 코드 축소를 적용할 경우 작성자 인식 정확도가 약 17.86% 감소하여, 코드 문체 분석(Code Stylometry)을 통한 작성자 식별을 더 어렵게 만드는 것으로 나타났습니다 [4].
-*   **성능 사례:** Python 코드의 축소를 지원하는 도구인 'Python Minifier'의 실험 사례를 보면, 축소화 작업 후 소스 코드 라인 수(SLOC)는 60%, 문자 수는 37%나 감소하여 매우 큰 파일 크기 최적화 효과를 보여주었습니다 [5, 6].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[Code Formatting]], [[Code Stylometry]]
-- **Projects/Contexts:** [[Web Development]], [[Python Minifier]]
-- **Contradictions/Notes:** 소스에 관련 정보가 부족합니다.
-
----
-*Last updated: 2026-04-19*
-- Raw Source: [[00_Raw/2026-04-20/Code Minification.md]]
----
diff --git a/Programming & Language/Code Obfuscation.md b/Programming & Language/Code Obfuscation.md
deleted file mode 100644
index dbff347f..00000000
--- a/Programming & Language/Code Obfuscation.md	
+++ /dev/null
@@ -1,33 +0,0 @@
----
-id: P-REINFORCE-AUTO-B2A3F3
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Code Obfuscation"
----
-
-# [[Code Obfuscation]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 코드 난독화(Code Obfuscation)는 소스 코드의 기능을 유지하면서도 코드를 읽거나 이해하기 어렵게 변환하는 기법입니다 [1, 2]. 주로 악의적이거나 자동화된 코드 스타일로메트리(Code Stylometry, 작성자 식별 분석)로부터 오픈소스 프로그래머의 신원과 프라이버시를 보호하기 위한 방어 수단으로 활용됩니다 [3-5]. 난독화 도구의 강도에 따라 코드의 가독성과 성능이 어느 정도 희생되지만, 기계 학습 모델의 작성자 식별 정확도를 유의미하게 낮출 수 있습니다 [2, 6].
-
-## 📖 구조화된 지식 (Synthesized Content)
-- **작성자 식별(Stylometry) 방어 기법으로서의 역할:** 코드 난독화는 프로그래머의 고유한 코딩 스타일을 숨기고 익명성을 유지하기 위해 고안된 수단입니다 [1, 3, 7]. 딥러닝 등을 이용한 작성자 식별 기술이 발전함에 따라, 익명으로 활동해야 하는 개발자들이 감시나 추적을 회피하기 위한 목적으로 이를 활용할 수 있습니다 [4, 5].
-- **난독화 도구별 효과 및 한계:** 난독화를 수행하는 수준에 따라 식별을 방어하는 효과가 다르게 나타납니다. 변수 이름을 변경하거나 공백과 주석을 제거하는 등 단순한 수준의 난독화를 수행하는 상용 도구(예: Stunnix)는 식별 정확도를 크게 낮추지 못합니다(오차율 불과 1.11% 감소) [2, 6]. 반면, 코드의 가독성과 성능을 크게 포기하면서 구조적이고 근본적인 수준의 난독화를 수행하는 도구(예: Tigress)는 작성자 식별 정확도를 95.91%에서 67.22%로 대폭 감소시키는 효과를 보였습니다 [2]. 또 다른 도구인 Obfuscator-LLVM은 정확도를 약 3.6% 하락시켰습니다 [8].
-- **코드 미니파이(Minification) 및 포맷팅과의 차이점:** 소스 코드의 공백을 제거하거나 형태를 일관되게 정렬하는 코드 미니파이나 포맷팅 기법 역시 코드의 표면적인 특징을 변환하여 작성자 인식률을 어느 정도 낮추는 효과가 있습니다 [1, 9]. 하지만 이러한 기법만으로는 개발자 식별을 완전히 피할 수 없으며, 식별을 철저하게 차단하려면 코드 가독성을 거의 포기하는 수준의 전면적인 난독화(Full-blown obfuscation)가 필수적으로 요구됩니다 [10].
-- **수동 및 자동 난독화 연구:** 자동화 도구인 Opy나 PyArmor 등을 활용한 방식뿐만 아니라, 프로그래머가 직접 자신의 코딩 스타일을 바꾸거나 다른 사람의 코딩 스타일을 의도적으로 모방하는 수동 난독화(Manual obfuscation)에 대한 연구도 활발히 진행되고 있습니다 [11-13].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[Code Stylometry]], [[Authorship Attribution]], [[Code Minification]]
-- **Projects/Contexts:** [[Tigress]], [[Stunnix]], [[Opy]], [[PyArmor]]
-- **Contradictions/Notes:** 단순한 미니파이(Minification)나 포맷팅 작업, 혹은 Stunnix와 같이 기본적인 난독화만 제공하는 도구는 기계 학습 모델을 속이기에 불충분합니다. 작성자를 식별하려는 시도를 완전히 회피하려면, Tigress와 같이 시스템 성능과 코드 가독성의 저하를 감수하는 심층적인 수준의 난독화를 적용해야 한다는 점이 관찰됩니다 [2, 6, 10].
-
----
-*Last updated: 2026-04-19*
-- Raw Source: [[00_Raw/2026-04-20/Code Obfuscation.md]]
----
diff --git a/Programming & Language/Code Splitting  Lazy Loading (코드 분할 및 지연 로딩).md b/Programming & Language/Code Splitting  Lazy Loading (코드 분할 및 지연 로딩).md
deleted file mode 100644
index 4a2813bd..00000000
--- a/Programming & Language/Code Splitting  Lazy Loading (코드 분할 및 지연 로딩).md	
+++ /dev/null
@@ -1,42 +0,0 @@
----
-id: P-REINFORCE-AUTO-59CADB
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Code Splitting  Lazy Loading (코드 분할 및 지연 로딩)"
----
-
-# [[Code Splitting  Lazy Loading (코드 분할 및 지연 로딩)]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 거대한 자바스크립트 번들을 작은 단위로 나누고, 사용자가 당장 필요로 하지 않는 컴포넌트나 라이브러리의 로딩을 지연시켜 애플리케이션의 초기 로딩 속도와 핵심 웹 지표(FCP, LCP)를 비약적으로 개선하는 최적화 기법입니다.
-
-## 📖 구조화된 지식 (Synthesized Content)
-**1. 동작 원리 및 필요성** 일반적인 React 앱은 모든 코드를 하나의 큰 번들로 묶어 제공하므로 사용자가 사용하지 않을 기능까지 다운로드하느라 초기 로딩이 크게 지연됩니다. "초기 페이지 로드 시 화면에 즉시 보이지 않는 기능은 렌더링을 차단해서는 안 된다"는 원칙에 따라, 코드를 분할하면 반응성(TTI)을 높이고 데이터 전송 비용을 줄일 수 있습니다. 전체 번들 크기를 최대 20~70%까지 줄이는 것이 가능합니다.
-
-**2. 전략 1: 라우트 기반 분할 (Route-level Splitting)** 가장 적은 노력으로 가장 큰 효과(초기 번들 60~80% 감소)를 볼 수 있는 방식입니다. `React.lazy`와 React Router를 활용하여, 사용자가 현재 방문한 페이지에 필요한 컴포넌트만 로드하고 다른 페이지의 코드는 분할합니다.
-
-**3. 전략 2: 컴포넌트 기반 지연 로딩 (Component-level Lazy Loading)** 화면 하단(Below the fold)에 위치하거나 무거운 UI 요소(예: 3D 모델, 복잡한 차트, 비디오 에디터 등)를 `React.lazy`와 `<Suspense>`를 이용해 온디맨드(On-demand) 방식으로 불러옵니다. 예를 들어 React Three Fiber(R3F) 환경에서는 렌더링 비용이 큰 3D 모델을 `<Suspense fallback={<Loader />}>`로 감싸 지연 로딩하는 것이 필수적입니다.
-
-**4. 전략 3: 라이브러리 분할 (Library-level Splitting)** PDF 생성이나 엑셀 내보내기 등 특정 액션이 일어날 때만 필요한 무거운 서드파티 라이브러리를 동적 `import()`로 불러와 메인 자바스크립트 번들에서 완전히 제외시킵니다.
-
-**5. UX 최적화 및 주의사항**
-
-- **스켈레톤 UI (Skeleton UI):** 지연 로딩이 발생할 때 화면이 일시적으로 비어보이는 현상을 막고 누적 레이아웃 이동(CLS)을 방지하기 위해, `<Suspense fallback={...}>` 내부에 최종 콘텐츠와 유사한 크기의 스켈레톤 UI나 로딩 인디케이터를 반드시 제공해야 합니다.
-- **지연 로딩의 금기:** 초기 렌더링에 즉시 필요하거나 화면 최상단(Above-the-fold)에 위치한 핵심 컴포넌트는 절대 지연 로딩해서는 안 됩니다.
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[React Performance Optimization]], [[React.lazy & Suspense]], [[Core Web Vitals (FCP, LCP, CLS)]], [[React Server Components (RSC)]]
-- **Projects/Contexts:** [[대규모 SPA 초기 로딩 속도 개선]], [[Three.js / React Three Fiber 자산 최적화]]
-- **Contradictions/Notes:** 코드 분할은 초기 로드 속도를 크게 높여주지만, 모든 컴포넌트를 무분별하게 분할할 경우 사용자가 상호작용을 할 때마다 네트워크 지연과 로딩 스피너를 마주하게 되어 오히려 UX를 크게 훼손할 수 있습니다. 항상 사용자의 여정(User Flow)을 예측하고 적절한 단위로 번들을 묶는 전략적 접근이 필요합니다.
-
----
-
-_Last updated: 2026-04-14_
-- Raw Source: [[00_Raw/2026-04-20/Code Splitting & Lazy Loading (코드 분할 및 지연 로딩).md]]
----
diff --git a/Programming & Language/Code Stylometry (코드 문체론).md b/Programming & Language/Code Stylometry (코드 문체론).md
deleted file mode 100644
index 293a36c3..00000000
--- a/Programming & Language/Code Stylometry (코드 문체론).md	
+++ /dev/null
@@ -1,37 +0,0 @@
----
-id: P-REINFORCE-AUTO-17B6B7
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Code Stylometry (코드 문체론)"
----
-
-# [[Code Stylometry (코드 문체론)]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 코드 문체론(Code Stylometry)은 프로그래머가 작성한 소프트웨어 소스 코드의 프로그래밍 스타일을 분석하여 코드의 작성자를 자동으로 식별(저자 식별)하는 기술이다 [1], [2]. 이 기술은 소스 코드나 실행 파일에 남겨진 논리 구조, 데이터 유형, 주석, 명명 규칙, 레이아웃 등 프로그래머 고유의 특징들을 추출하여 머신러닝 알고리즘을 통해 저자를 추적한다 [3], [2]. 주로 코드 클론 탐지나 누락된 저작자 정보 복구 등에 유용하게 쓰일 수 있다 [4]. 그러나 동시에 검열 및 감시 우회 도구 개발자나 오픈소스 기여자의 익명성을 위협하고 신원을 노출시키는 수단으로 악용될 수 있어 심각한 프라이버시 문제를 제기하기도 한다 [4], [5], [6], [7].
-
-## 📖 구조화된 지식 (Synthesized Content)
-* **코드 문체론의 핵심 특징 및 분석 기법**
-  코드 문체론은 저자 식별을 위해 주로 세 가지 범주의 특징을 활용한다. 첫째, 어휘적 특징(Lexical features)은 단어나 문자의 사용 방식과 관련이 있다 [3]. 둘째, 구문적 특징(Syntactic features)은 언어의 문법 구조를 나타내며 주로 AST(추상 구문 트리)의 형태로 분석된다 [3]. 셋째, 레이아웃 특징(Layout features)은 띄어쓰기나 들여쓰기, 블록 길이 같은 시각적인 코드 배치 습관을 의미한다 [3]. 기존 분석에서는 구문 특징에 집중한 AST가 자주 사용되었지만, 레이아웃 및 어휘적 특징을 모두 보존하는 CST(구체 구문 트리)를 사용할 경우 저자 식별 정확도가 51%에서 68%로 크게 향상되는 것으로 나타났다 [8], [9]. 저자의 특징을 분류하기 위해 랜덤 포레스트(Random Forest), 서포트 벡터 머신(SVM), 신경망(Neural Networks) 등의 머신러닝 알고리즘이 널리 활용된다 [10], [11], [12].
-
-* **익명성 위협과 적대적 코드 문체론 (Adversarial Code Stylometry)**
-  코드 문체론 기술이 발전함에 따라 대규모 오픈소스 환경에서도 높은 정확도로 작성자를 특정할 수 있게 되었으며, 이는 프라이버시와 익명성에 대한 큰 위협으로 다가온다 [4], [5]. 이에 대항하기 위해 프로그래머가 자신의 스타일을 숨기거나(난독화, Obfuscation) 타인의 스타일을 의도적으로 모방(위장, Mimicry)하여 자동화된 식별 시스템을 속이려는 적대적 기법에 대한 연구가 활발히 진행 중이다 [13], [14], [15].
-
-* **코드 포매팅 및 축소(Minification)가 저자 식별에 미치는 영향**
-  일관된 코딩 규칙을 적용하는 '코드 포매팅(Code Formatting)'이나 불필요한 공백, 줄바꿈 등을 제거하여 코드 크기를 줄이는 '코드 축소(Code Minification)'는 소프트웨어 개발의 일반적인 관행이다 [16], [17], [18]. 이러한 소스 대 소스(source-to-source) 변환은 프로그래머의 고유한 스타일 지문 일부를 지우기 때문에 문체론의 정확도를 감소시킨다 [19], [20]. CST 기반의 실험 결과, 코드 포매팅을 적용하면 식별 정확도가 68%에서 53%로 하락하였고, 코드 축소를 적용하면 50%까지 떨어졌다 [21], [22]. 하지만 이러한 감소 폭에도 불구하고 식별 확률이 무작위 추론 수준으로 떨어지지는 않으며, 식별 대상 저자들은 여전히 상당 부분 인식 가능한 상태로 남기 때문에 이를 완벽한 익명화 방어책으로 사용할 수는 없다 [23], [22].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[Adversarial Code Stylometry]], [[Abstract Syntax Tree (AST)]], [[Concrete Syntax Tree (CST)]], [[Code Obfuscation]], [[Code Formatting]], [[Code Minification]]
-- **Projects/Contexts:** [[Google Code Jam Dataset]], [[StyleCounsel]]
-- **Contradictions/Notes:** 소스에 따르면 기계 학습 기반의 코드 문체론 모델에 대항하기 위한 적대적 기법들이 시도되고 있으나, 단순히 코드를 정렬하는 포매팅(Formatting)이나 축소(Minification) 처리만으로는 저자의 개별 스타일 특징을 완전히 제거할 수 없으며 대다수 저자가 여전히 식별 가능한 것으로 나타납니다 [23], [22].
-
----
-*Last updated: 2026-04-18*
-- Raw Source: [[00_Raw/2026-04-20/Code Stylometry (코드 문체론).md]]
----
diff --git a/Programming & Language/Codemod-Engineering.md b/Programming & Language/Codemod-Engineering.md
deleted file mode 100644
index 2c9916a9..00000000
--- a/Programming & Language/Codemod-Engineering.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-084361
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Codemod-Engineering"
----
-
-# [[Codemod-Engineering]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Codemod-Engineering.md]]
----
diff --git a/Programming & Language/Complex Adaptive Systems.md b/Programming & Language/Complex Adaptive Systems.md
deleted file mode 100644
index 9a237d70..00000000
--- a/Programming & Language/Complex Adaptive Systems.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-AB2667
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Complex Adaptive Systems"
----
-
-# [[Complex Adaptive Systems]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Complex Adaptive Systems.md]]
----
diff --git a/Programming & Language/Complex-Adaptive-Systems.md b/Programming & Language/Complex-Adaptive-Systems.md
deleted file mode 100644
index 300708c6..00000000
--- a/Programming & Language/Complex-Adaptive-Systems.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-A9DF17
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Complex-Adaptive-Systems"
----
-
-# [[Complex-Adaptive-Systems]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Complex-Adaptive-Systems.md]]
----
diff --git a/Programming & Language/Concrete Syntax Tree (CST).md b/Programming & Language/Concrete Syntax Tree (CST).md
deleted file mode 100644
index 4525aa08..00000000
--- a/Programming & Language/Concrete Syntax Tree (CST).md	
+++ /dev/null
@@ -1,33 +0,0 @@
----
-id: P-REINFORCE-AUTO-858963
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Concrete Syntax Tree (CST)"
----
-
-# [[Concrete Syntax Tree (CST)]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> Concrete Syntax Tree (CST)는 파스 트리(Parse Tree)라고도 불리며, 문맥 자유 문법(context-free grammar)의 트리 표현 형태로 컴파일러가 코드를 이해하는 방식을 보여주는 공식적인 구조이다 [1]. 추상 구문 트리(AST)와 달리 구문적 요소뿐만 아니라 미세한 문체, 어휘, 레이아웃(들여쓰기 등) 세부 사항까지 코드의 모든 측면을 정밀하게 포착한다 [2]. 이러한 구체적 특성 때문에 코드 포맷팅 등 소스 코드가 변환될 때 그 형태가 크게 변경되며, 최근 코드 작성자를 식별하는 기계 학습 기반의 코드 스타일로메트리(Code Stylometry) 모델에서 중요하게 활용되고 있다 [3, 4].
-
-## 📖 구조화된 지식 (Synthesized Content)
-- **정의 및 구조:** CST는 주어진 문법에 대해 각 노드가 특정 기호로 레이블링되는 순서 트리(ordered tree)이다 [1]. 루트 노드는 시작 기호로, 비단말(non-leaf) 노드들은 비단말 기호로 이루어지며 자식 노드들과의 관계는 문법의 생성 규칙을 정확하게 반영하여 구성된다 [5]. 
-- **AST와의 차이점:** 추상 구문 트리(AST)가 코드 파싱 후 레이아웃 특징 등을 추상화하여 배제하는 반면, CST는 코드를 포맷팅하거나 여백을 변경할 때의 레이아웃 정보까지 그대로 유지한다 [3, 6]. 따라서 코드를 다른 형태로 재정렬하는 소스-대-소스 변환 시 AST는 동일할 수 있지만, CST는 유의미하게 변경된다 [3].
-- **CST 경로(Path) 및 문맥 추출:** CST 내에서 두 단말 노드 사이를 위아래로 이동하는 시퀀스를 'CST 경로(CST path)'라고 정의한다 [7]. 이 경로와 시작 및 종료 노드의 실제 코드 토큰 값을 결합한 것을 '경로 문맥(path context)'이라 부르며, 코드의 어휘적, 구문적, 레이아웃적 특징을 유지하는 데이터 표현 수단으로 쓰인다 [8, 9].
-- **코드 분석 및 작성자 식별(Stylometry)에서의 활용:** 최신 기계 학습 모델(예: code2vec)은 코드의 의미론적 요소와 문체적 요소를 모두 보존하기 위해 AST 대신 CST를 입력값으로 사용한다 [4]. 실제 실험 결과, AST 대신 CST 기반의 코드 표현을 사용하면 레이아웃 정보가 반영되어 코드 작성자 식별(Authorship attribution)의 정확도가 크게 향상(51.00%에서 67.86%로 증가)되는 것으로 확인되었다 [10, 11].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[Abstract Syntax Tree (AST)]], [[Code Stylometry]], [[Parse Tree]]
-- **Projects/Contexts:** 프로그래머의 코드 작성 스타일을 분석하여 작성자를 식별하는 코드 스타일로메트리 연구에서, 코드 포맷팅(formatting) 및 축소(minification) 기술이 식별 정확도에 미치는 영향을 측정하기 위한 코드 표현 방식으로 사용됨 [3, 12, 13].
-- **Contradictions/Notes:** 소스에 관련 정보가 부족합니다.
-
----
-*Last updated: 2026-04-19*
-- Raw Source: [[00_Raw/2026-04-20/Concrete Syntax Tree (CST).md]]
----
diff --git a/Programming & Language/Conscientiousness.md b/Programming & Language/Conscientiousness.md
deleted file mode 100644
index 27a51e59..00000000
--- a/Programming & Language/Conscientiousness.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-04F596
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Conscientiousness"
----
-
-# [[Conscientiousness]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Conscientiousness.md]]
----
diff --git a/Programming & Language/Continuous Integration (CI).md b/Programming & Language/Continuous Integration (CI).md
deleted file mode 100644
index d167187e..00000000
--- a/Programming & Language/Continuous Integration (CI).md	
+++ /dev/null
@@ -1,33 +0,0 @@
----
-id: P-REINFORCE-AUTO-F896F7
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Continuous Integration (CI)"
----
-
-# [[Continuous Integration (CI)]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지속적 통합(Continuous Integration, CI)은 소프트웨어 개발 수명 주기에서 코드 변경 사항이 발생할 때 이를 자동으로 검사하고 빌드하는 파이프라인입니다 [1, 2]. 개발자의 로컬 환경에서 우회될 수 있는 검사들을 강제하는 '안전망(Safety net)'이자 최종 권한(Final authority) 역할을 수행합니다 [2, 3]. CI 환경에서는 정적 애플리케이션 보안 테스트(SAST), 린팅(Linting), 전체 테스트 스위트 실행 등을 통해 프로덕션 환경에 배포되기 전 코드의 품질과 보안을 엄격하게 관리합니다 [4, 5].
-
-## 📖 구조화된 지식 (Synthesized Content)
-- **최종 검증 및 안전망(Safety Net) 역할:** 개발자가 로컬 환경에서 사용하는 Git 훅(예: Husky, lint-staged)은 `--no-verify` 명령어로 우회할 수 있으므로 코드 품질 정책에 대한 완벽한 강제성을 갖지 못합니다 [3]. 따라서 CI 파이프라인은 전체 코드에 대한 린팅(자동 수정 제외), 전체 테스트 스위트 실행, 타입 검사 및 빌드 검증을 우회 불가능하게 수행하는 안전망이자 최종 권한으로 작동합니다 [2, 4, 6].
-- **보안 및 품질 게이트(Quality Gates) 통합:** CI/CD 파이프라인에 SAST 도구(예: Snyk, SonarQube, Qodana) 및 코드 품질 분석 도구를 통합하여 품질 검사를 빌드 프로세스의 자연스러운 일부로 만듭니다 [1, 7, 8]. 이를 통해 특정 심각도 임계값을 초과하는 보안 취약점이나 품질 기준에 미달하는 코드가 병합(Merge)되거나 배포되는 것을 자동으로 차단(Guardrail)할 수 있습니다 [1, 5, 9].
-- **병렬 검사 및 리뷰 파이프라인 설계:** Pull Request(PR)가 생성되면 CI 파이프라인은 린팅, 포맷팅 검증, 유닛 및 통합 테스트, 종속성 취약점 스캔 등의 사전 병합(Pre-Merge) 자동화 검사를 병렬로 실행합니다 [10]. 코드 변경 사항은 이러한 자동화 검사를 통과한 후에만 사람이 직접 수행하는 코드 리뷰로 라우팅되거나 병합이 활성화되도록 구성되어, 리뷰어의 인지적 부담을 줄이고 전체적인 소프트웨어 전송 속도를 높입니다 [8, 11, 12].
-- **CI 환경에서의 도구 실행 전략:** CI 서버에서 검사를 실행할 때는 로컬 환경을 위한 Git 훅 도구를 비활성화(`HUSKY=0` 등 설정)하고, 특정 파일만이 아닌 프로젝트에 필요한 실제 검사 명령어 전체를 직접 실행하도록 설정하는 것이 권장됩니다 [6, 13].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[Static Application Security Testing (SAST)]], [[Code Review]], [[Git Hooks]], [[Quality Gates]], [[Pull Request (PR)]]
-- **Projects/Contexts:** [[TeamCity]], [[GitHub Actions]], [[GitLab CI]], [[Jenkins]], [[Azure DevOps]]와 같이 코드 통합과 자동화 빌드를 관장하는 인프라 환경 [1, 9, 14]. 
-- **Contradictions/Notes:** 로컬 Git 훅(pre-commit 등)은 로컬 환경에서 빠른 피드백을 제공하여 시간을 절약하게 해주지만, 우회가 가능하므로 CI를 완전히 대체할 수 없으며 반드시 CI 파이프라인을 통한 최종 검증이 병행되어야 합니다 [2, 4, 15]. 
-
----
-*Last updated: 2026-04-18*
-- Raw Source: [[00_Raw/2026-04-20/Continuous Integration (CI).md]]
----
diff --git a/Programming & Language/Control-Flow-Analysis.md b/Programming & Language/Control-Flow-Analysis.md
deleted file mode 100644
index 8f082b6e..00000000
--- a/Programming & Language/Control-Flow-Analysis.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-452CC1
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Control-Flow-Analysis"
----
-
-# [[Control-Flow-Analysis]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Control-Flow-Analysis.md]]
----
diff --git a/Programming & Language/Cosmos 플랫폼 (Netflix).md b/Programming & Language/Cosmos 플랫폼 (Netflix).md
deleted file mode 100644
index 2ce4f8ca..00000000
--- a/Programming & Language/Cosmos 플랫폼 (Netflix).md	
+++ /dev/null
@@ -1,36 +0,0 @@
----
-id: P-REINFORCE-AUTO-5C7CCB
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Cosmos 플랫폼 (Netflix)"
----
-
-# [[Cosmos 플랫폼 (Netflix)]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> Cosmos는 넷플릭스(Netflix)가 마이크로서비스, 비동기 워크플로우, 서버리스 함수의 장점을 결합하여 구축한 컴퓨팅 플랫폼이다 [1]. 기존 모놀리식 아키텍처인 'Reloaded'의 한계를 극복하고 관측성, 모듈성, 생산성, 지속적 배포(Continuous Delivery)를 향상시키기 위해 개발되었다 [2, 3]. 수 분에서 수년에 걸쳐 실행되는 복잡한 계층적 워크플로우 및 리소스 집약적인 알고리즘을 조율하는 데 최적화되어 있으며, 대규모 처리량과 지연 시간에 민감한 작업 부하를 모두 지원한다 [1].
-
-## 📖 구조화된 지식 (Synthesized Content)
-* **배경 및 점진적 전환:** 넷플릭스의 기존 미디어 처리 시스템인 'Reloaded'는 개발팀 규모가 커짐에 따라 인프라와 애플리케이션 코드가 뒤섞이고 새로운 기능 배포가 지연되는 모놀리식 아키텍처의 한계를 겪었다 [2]. 이를 해결하기 위해 워크플로우 기반 미디어 특화 마이크로서비스 플랫폼인 Cosmos가 구축되었으며, 시스템을 완전히 교체할 때까지 기존 시스템 주위를 감싸며 새로운 시스템을 성장시키는 '스트랭글러 피그(Strangler fig) 패턴'을 도입하여 위험을 줄이면서 마이그레이션을 진행했다 [3, 4].
-* **다차원적 관심사의 분리 (Separation of Concerns):** Cosmos는 로직을 API, 워크플로우, 서버리스 함수로 나누는 한편, 도메인 특화 애플리케이션 로직과 분산 컴퓨팅을 처리하는 플랫폼으로 분리하는 양방향 관심사 분리 원칙을 적용했다 [5]. 분산 처리를 담당하는 플랫폼은 세 가지 주요 하위 시스템과 이를 연결하는 큐잉 시스템으로 구성된다 [6].
-    * **Optimus:** 외부 요청을 내부 비즈니스 모델로 매핑하는 API 계층이다 [6].
-    * **Plato:** 비즈니스 규칙을 모델링하는 워크플로우 계층으로, 'Emirax'라는 도메인 특화 언어(DSL)를 사용하는 포워드 체이닝(forward chaining) 규칙 엔진을 기반으로 설계되었다 [6-8].
-    * **Stratum:** 상태가 없으며 계산 집약적인 알고리즘을 실행하는 서버리스 계층이다 [6].
-    * **Timestone:** 위의 하위 시스템들이 비동기적으로 통신할 수 있도록 돕는 대규모 저지연 우선순위 큐잉 시스템이다 [6].
-* **지연 시간 관리 및 활용 사례:** Cosmos는 서비스의 분해와 계층화를 지원하여 스튜디오에서 들어오는 미디어 소스를 처리하는 대규모 처리량 중심의 고위급 서비스인 'Tapas'와, 사용자 대면 작업으로 지연 시간에 민감한 'Sagan' 등의 다양한 서비스를 효율적으로 오케스트레이션한다 [9-12]. 수요 폭증 시 발생하는 지연 문제를 해결하기 위해 Stratum은 리소스 풀(Resource pools) 설정, 사전 확보된 웜 용량(Warm capacity), 컨테이너 시작 비용을 분산하는 마이크로 배치(Micro-batches), 작업의 우선순위(Priority) 지정 등의 전략을 활용한다 [13].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[마이크로서비스 (Microservices)]], [[서버리스 컴퓨팅 (Serverless Computing)]], [[관심사의 분리 (Separation of Concerns)]]
-- **Projects/Contexts:** [[Reloaded]], [[Optimus]], [[Plato]], [[Stratum]], [[Timestone]], [[Tapas]], [[Sagan]]
-- **Contradictions/Notes:** "서버리스 함수를 조율하는 워크플로우를 트리거하는 마이크로서비스"라는 Cosmos의 프로그래밍 모델은 강력하지만, 단순한 애플리케이션에 적용하기에는 부가되는 복잡성이 이점보다 클 수 있다는 점이 지적된다 [14]. 또한, Cosmos 플랫폼 도입 당시 애플리케이션 개발자들은 일관성과 신뢰성을 획득하는 대신 일정한 유연성을 포기하는 방향으로 마인드셋을 전환해야 했다 [14].
-
----
-*Last updated: 2026-04-18*
-- Raw Source: [[00_Raw/2026-04-20/Cosmos 플랫폼 (Netflix).md]]
----
diff --git a/Programming & Language/Covariance-and-Contravariance.md b/Programming & Language/Covariance-and-Contravariance.md
deleted file mode 100644
index bd536fd3..00000000
--- a/Programming & Language/Covariance-and-Contravariance.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-1D016B
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Covariance-and-Contravariance"
----
-
-# [[Covariance-and-Contravariance]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Covariance-and-Contravariance.md]]
----
diff --git a/Programming & Language/Cumulative Layout Shift (CLS).md b/Programming & Language/Cumulative Layout Shift (CLS).md
deleted file mode 100644
index fa5d9e8d..00000000
--- a/Programming & Language/Cumulative Layout Shift (CLS).md	
+++ /dev/null
@@ -1,42 +0,0 @@
----
-id: P-REINFORCE-AUTO-C15CB2
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Cumulative Layout Shift (CLS)"
----
-
-# [[Cumulative Layout Shift (CLS)]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> Cumulative Layout Shift (CLS)는 웹 페이지가 로드되는 동안 레이아웃과 콘텐츠가 얼마나 예기치 않게 이동하는지를 측정하는 시각적 안정성(Visual Stability) 지표입니다 [1, 2]. 구글의 코어 웹 바이탈(Core Web Vitals)을 구성하는 핵심 지표 중 하나로, 나중에 렌더링된 콘텐츠가 중요한 콘텐츠를 밀어내면서 발생하는 사용자 경험의 저하를 방지하기 위해 사용됩니다 [1, 2]. CLS 점수는 0.1 미만을 유지하는 것이 권장됩니다 [3].
-
-## 📖 구조화된 지식 (Synthesized Content)
-* **측정 기준 및 중요성:** 
-  CLS는 시각적 안정성을 측정하는 지표로, 페이지 로드 중 요소들의 위치가 변경되는 레이아웃 이동 현상을 수치화합니다 [1, 2]. 이상적이고 쾌적한 사용자 경험을 위해 CLS 점수는 0.1 미만이어야 하며, 0.25를 초과할 경우 상태가 매우 나쁜 것으로 간주되어 성능 개선이 필요합니다 [3]. LCP, INP와 함께 최적화되어야 하는 코어 웹 바이탈의 중요 요소입니다 [4].
-
-* **주요 발생 원인 및 최적화 방법:** 
-  주로 앱 배너, 이미지, 광고, 임베드 요소 등이 화면에 나타나면서 기존에 렌더링된 콘텐츠를 아래로 밀어낼 때 발생합니다 [2, 5, 6]. 이를 방지하기 위해서는 이미지나 광고, 임베드 요소가 로드될 공간을 미리 확보(reserve space)해 두어야 하며, 기존에 있는 콘텐츠 위로 새로운 콘텐츠를 동적으로 삽입하는 것을 피해야 합니다 [6].
-
-* **분석 및 디버깅:** 
-  Chrome DevTools의 성능(Performance) 패널을 사용해 CLS의 원인을 파악하고 디버깅할 수 있습니다 [7]. 
-  * 'Layout shifts' 트랙에서 레이아웃 이동은 보라색 다이아몬드로 표시되며, 시간상 근접성에 따라 클러스터 형태(보라색 선)로 그룹화됩니다 [7]. 
-  * 이 다이아몬드나 'Worst cluster 1 shift' 항목을 클릭하면 어떤 DOM 요소가 이동에 영향을 받았는지 식별할 수 있으며, 마우스를 올리면 뷰포트 내에서 해당 요소가 하이라이트됩니다 [7, 8].
-
-* **브라우저 지원 동향:** 
-  현재 구글을 중심으로 측정되고 있으나, 파이어폭스(Firefox)와 사파리(Safari)의 브라우저 호환성을 위한 Interop 2025 프로젝트에는 CLS 지원이 계획되어 있지 않습니다 [9]. 다만, 차기 프로젝트인 Interop 2026에 CLS를 포함하려는 제안이 존재합니다 [9].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[Core Web Vitals]], [[Largest Contentful Paint (LCP)]], [[Interaction to Next Paint (INP)]]
-- **Projects/Contexts:** [[Chrome DevTools]], [[Interop 2026]]
-- **Contradictions/Notes:** CLS 수치는 기기의 해상도에 크게 의존하기 때문에 실제 방문자 데이터를 나타내는 현장(Field) 데이터와 개발자의 로컬(Local) 데이터 간에 차이가 발생하기 쉽습니다. 이러한 이유로 코어 웹 바이탈 지표 중에서도 에뮬레이션하여 측정하기 가장 까다로운 지표로 평가받습니다 [8].
-
----
-*Last updated: 2026-04-19*
-- Raw Source: [[00_Raw/2026-04-20/Cumulative Layout Shift (CLS).md]]
----
diff --git a/Programming & Language/Cybertext.md b/Programming & Language/Cybertext.md
deleted file mode 100644
index 5cf77b2f..00000000
--- a/Programming & Language/Cybertext.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-52E635
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Cybertext"
----
-
-# [[Cybertext]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Cybertext.md]]
----
diff --git a/Programming & Language/Cypher 질의 언어 (Neo4j).md b/Programming & Language/Cypher 질의 언어 (Neo4j).md
deleted file mode 100644
index 85c5b087..00000000
--- a/Programming & Language/Cypher 질의 언어 (Neo4j).md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-C101DD
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Cypher 질의 언어 (Neo4j)"
----
-
-# [[Cypher 질의 언어 (Neo4j)]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Cypher 질의 언어 (Neo4j).md]]
----
diff --git a/Programming & Language/DAST (동적 애플리케이션 보안 테스트).md b/Programming & Language/DAST (동적 애플리케이션 보안 테스트).md
deleted file mode 100644
index 9aae9826..00000000
--- a/Programming & Language/DAST (동적 애플리케이션 보안 테스트).md	
+++ /dev/null
@@ -1,33 +0,0 @@
----
-id: P-REINFORCE-AUTO-09DD84
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - DAST (동적 애플리케이션 보안 테스트)"
----
-
-# [[DAST (동적 애플리케이션 보안 테스트)]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> DAST(동적 애플리케이션 보안 테스트)는 애플리케이션이 실행되는 런타임 환경에서 외부로부터 취약점을 테스트하는 블랙박스(Black-box) 테스트 기법입니다 [1, 2]. 소스 코드를 직접 분석하는 SAST와 달리 특정 프로그래밍 언어에 종속되지 않으며, 주로 소프트웨어 개발 수명 주기(SDLC)의 후반부인 스테이징이나 프로덕션 단계에 적용됩니다 [2, 3]. 이를 통해 실행 중인 애플리케이션의 실제 동작, 구성(Configuration) 문제 및 노출된 공격 표면을 관찰하여 런타임 취약점을 찾아내는 데 효과적입니다 [1, 3].
-
-## 📖 구조화된 지식 (Synthesized Content)
-* **테스트 방식 및 시기:** DAST는 소스 코드를 실행하지 않고 검사하는 SAST(화이트박스 테스트)와 반대로, 실행 중인 애플리케이션을 외부에서 테스트하는 블랙박스 테스트입니다 [1, 3]. CI 파이프라인의 후반부인 스테이징, 사전 프로덕션(pre-prod) 또는 프로덕션 환경에 주로 적용되어 외부 환경과 상호작용하는 애플리케이션을 테스트합니다 [2-4].
-* **탐지 범위 및 특징:** 코드의 내부 로직이나 데이터 흐름을 보는 대신, 애플리케이션의 런타임 동작, 구성 문제, 외부에 노출된 인터페이스를 중점적으로 관찰하여 런타임 환경에서 안전한지를 검증합니다 [3, 4]. 분석 시 특정 프로그래밍 언어에 얽매이지 않는다는 것도 주요 특징입니다 [2].
-* **퍼징(Fuzzing) 기법 활용:** DAST 방법론 중 하나인 퍼징(Fuzzing)은 애플리케이션에 의도적으로 스트레스 및 예상치 못한 입력을 가해 예기치 않은 동작, 시스템 충돌, 리소스 누수 등을 유발함으로써 런타임 애플리케이션의 취약점을 심층적으로 파악하는 데 사용됩니다 [2].
-* **SAST와의 상호 보완적(Layered Coverage) 활용:** 효율적인 애플리케이션 보안을 위해 DAST는 단독으로 쓰이기보다 SAST와 결합하여 사용됩니다 [1, 4]. 개발 초기 단계에서는 SAST가 코드 결함을 찾고, 후반 배포 단계에서는 DAST가 런타임/구성 취약점 및 회귀(Regression) 버그를 방지함으로써 계층화된 완벽한 보안 커버리지를 제공할 수 있습니다 [1, 2, 4, 5].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[SAST (정적 애플리케이션 보안 테스트)]], [[Black-box Testing]], [[Fuzzing]]
-- **Projects/Contexts:** [[AppSec (애플리케이션 보안)]], [[CI/CD 파이프라인]], [[SDLC (소프트웨어 개발 수명 주기)]]
-- **Contradictions/Notes:** 소스 내용 간의 모순은 존재하지 않으며, DAST는 코드를 직접 분석하는 SAST와 접근 방식(블랙박스 vs 화이트박스)에서 명확히 대비되지만 상호 배타적인 것이 아니라 강력한 보안 태세를 위해 함께 구축해야 하는 보완재로 설명됩니다 [4, 5].
-
----
-*Last updated: 2026-04-18*
-- Raw Source: [[00_Raw/2026-04-20/DAST (동적 애플리케이션 보안 테스트).md]]
----
diff --git a/Programming & Language/DOM 요소 조작 및 타입 좁히기.md b/Programming & Language/DOM 요소 조작 및 타입 좁히기.md
deleted file mode 100644
index bbb1b1a8..00000000
--- a/Programming & Language/DOM 요소 조작 및 타입 좁히기.md	
+++ /dev/null
@@ -1,43 +0,0 @@
----
-id: P-REINFORCE-AUTO-3A0CD0
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - DOM 요소 조작 및 타입 좁히기"
----
-
-# [[DOM 요소 조작 및 타입 좁히기]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> DOM 요소 조작 시에는 타입스크립트의 타입 좁히기(Type Narrowing) 기술을 통해 타입 안정성을 확보하는 것이 중요합니다. 타입 좁히기란 코드 흐름 분석을 사용하여 포괄적인 타입(유니온 타입 등)을 구체적인 단일 타입으로 줄여나가는 과정입니다 [1-3]. DOM 요소를 다루거나 구조가 명확하지 않은 데이터를 처리할 때, 타입 단언(`as`), 사용자 정의 타입 가드, `typeof` 및 `instanceof` 연산자 등을 활용하여 안전하게 타입을 좁혀 조작할 수 있습니다 [4-6].
-
-## 📖 구조화된 지식 (Synthesized Content)
-**DOM 요소 조작 시 타입 단언(`as`)의 활용**
-* DOM 요소로 작업하며 타입을 좁혀야 할 때, 타입 단언(`as`) 연산자가 주로 활용됩니다 [5]. 
-* 타입 단언은 런타임 검증을 마쳤거나 DOM 조작과 같이 불가피한 상황에서 컴파일러에게 특정 타입임을 강제할 때 사용합니다 [5, 7]. 하지만 개발자가 잘못 판단할 경우 컴파일러가 에러를 잡지 못해 런타임 오류로 이어질 수 있으므로 사용에 매우 주의해야 합니다 [7, 8].
-
-**DOM 요소 삽입과 브랜디드 타입(Branded Types)을 통한 보안**
-* 사용자의 입력값을 DOM의 `innerHTML` 등에 직접 추가하는 것은 XSS 공격에 노출될 수 있는 위험한 방식입니다 [9]. 
-* 이를 방어하기 위해 브랜디드 문자열 타입(Branded String Types)을 사용하여, 데이터가 DOM에 추가되기 전에 반드시 정제(Sanitized) 과정을 거쳤음을 타입 시스템 차원에서 강제할 수 있습니다 [9]. 
-* 또한, 유효하지 않은 잉여 속성(예: 'hello')을 DOM 객체로 전달할 경우 React와 같은 라이브러리에서는 경고를 발생시킬 수 있으므로 정확한 타입 지정이 중요합니다 [10].
-
-**타입 좁히기(Type Narrowing)의 주요 기법**
-* **`typeof` 및 `instanceof` 연산자:** `typeof`를 사용해 "string", "number", "boolean" 등의 원시 타입을 확인하거나, `instanceof`를 사용해 생성자 프로토타입의 인스턴스인지를 확인하여 타입을 좁힙니다 [4, 6].
-* **`in` 연산자 및 판별 속성(Discriminant Property):** 객체 내에 특정 속성이 존재하는지 `in` 키워드로 확인하거나, 식별 가능한 유니온(Discriminated Unions) 패턴에서 공통 리터럴 타입 필드(예: `kind` 또는 `type`)를 `switch` 문으로 비교하여 해당 블록 내의 타입을 안전하게 좁힙니다 [1, 3, 4, 11].
-* **타입 서술어(Type Predicates):** 반환 타입에 `is` 키워드를 사용하여(예: `value is Positive`), 함수가 `true`를 반환할 때 조건문 내부에서 매개변수가 특정 타입으로 좁혀지도록 타입 시스템에 알립니다 [6, 12].
-* **단언 함수(Assertion Functions):** 입력된 값이 기대한 타입이 아닐 경우 에러를 던지도록 작성된 함수입니다. 이 함수를 통과한 이후의 코드는 해당 값이 특정 타입이 확실함을 타입 시스템이 인지하여 타입을 좁히게 됩니다 [13, 14].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[Type Narrowing]], [[Type Assertions]], [[Discriminated Unions]], [[Branded Types]]
-- **Projects/Contexts:** [[안전한 DOM 조작 및 데이터 정제]], [[React 컴포넌트 Props 처리]]
-- **Contradictions/Notes:** 타입 단언(`as`)은 DOM 요소를 다루며 타입을 좁힐 때 유용하고 흔하게 사용되지만 [5], 런타임 동작에는 영향을 주지 않으므로 타입 에러를 우회하여 잘못된 코드를 통과시킬 위험이 있습니다. 따라서 가능한 한 `satisfies`나 사용자 정의 타입 가드 등 더 안전한 방식을 우선적으로 고려하는 것이 좋습니다 [7, 8, 15].
-
----
-*Last updated: 2026-04-18*
-- Raw Source: [[00_Raw/2026-04-20/DOM 요소 조작 및 타입 좁히기.md]]
----
diff --git a/Programming & Language/DOM 요소 조작.md b/Programming & Language/DOM 요소 조작.md
deleted file mode 100644
index 7bb8d717..00000000
--- a/Programming & Language/DOM 요소 조작.md	
+++ /dev/null
@@ -1,35 +0,0 @@
----
-id: P-REINFORCE-AUTO-15DA1E
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - DOM 요소 조작"
----
-
-# [[DOM 요소 조작]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 주어진 소스에는 DOM 요소 조작의 구체적인 방법론이나 원리에 대한 내용이 포함되어 있지 않아 소스에 관련 정보가 부족합니다. 제공된 문서들에서는 DOM 요소를 다룰 때 TypeScript의 타입 단언(`as`)을 사용하는 상황이나, 사용자 입력을 DOM에 추가하기 전 XSS 공격을 방어하기 위해 텍스트를 소독(sanitize)해야 한다는 보안 및 타입 안정성 측면에서의 단편적인 예시만 확인됩니다 [1-3].
-
-## 📖 구조화된 지식 (Synthesized Content)
-소스에 관련 정보가 부족합니다. 
-
-제공된 소스에서 DOM 조작과 관련해 부분적으로 도출할 수 있는 내용은 다음과 같습니다:
-
-*   **DOM 조작과 타입 단언(`as`):** TypeScript 환경에서 DOM 요소를 조작하거나 타입 추론이 어려운 외부 데이터를 다룰 때, 개발자가 런타임 유효성을 확인하여 타입에 대해 확신이 있다면 `as` 키워드를 사용하여 타입을 단언할 수 있습니다 [2]. 주로 DOM 요소의 타입을 구체적으로 좁혀야(narrow) 할 때(예: 특정 HTML 요소로 단언할 때) 제한적으로 `as`의 사용이 고려됩니다 [3].
-*   **DOM 추가 시 보안(XSS) 유의사항:** 사용자의 입력값을 검증 없이 DOM(예: `innerHTML`)에 직접 쓰는 것은 보안상 매우 위험한 방식입니다 [1]. 악의적인 코드가 주입되는 XSS(크로스 사이트 스크립팅) 공격을 막기 위해, DOM에 데이터를 추가하기 전에 반드시 텍스트를 소독(sanitize)해야 합니다 [1]. TypeScript의 브랜디드 타입(Branded Types)을 활용하면 소독된 문자열과 소독되지 않은 문자열의 타입을 구분할 수 있어, 안전하게 처리된 문자열만 DOM에 삽입되도록 타입 시스템 수준에서 강제할 수 있습니다 [1, 4].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[타입 단언(Type Assertions)]], [[브랜디드 타입(Branded Types)]]
-- **Projects/Contexts:** [[안전한 TypeScript 프론트엔드 개발 및 XSS 방어]]
-- **Contradictions/Notes:** 소스에 DOM 요소 조작의 본질적인 원리나 구체적인 API(예: 순수 자바스크립트 DOM API)에 대한 정보가 절대적으로 부족하므로 "소스에 관련 정보가 부족합니다."
-
----
-*Last updated: 2026-04-18*
-- Raw Source: [[00_Raw/2026-04-20/DOM 요소 조작.md]]
----
diff --git a/Programming & Language/DeepReadonly.md b/Programming & Language/DeepReadonly.md
deleted file mode 100644
index 4a292bd6..00000000
--- a/Programming & Language/DeepReadonly.md	
+++ /dev/null
@@ -1,32 +0,0 @@
----
-id: P-REINFORCE-AUTO-5FB09F
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - DeepReadonly"
----
-
-# [[DeepReadonly]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> DeepReadonly는 TypeScript에서 객체의 모든 중첩된 프로퍼티에 재귀적으로 `readonly`를 적용하여 데이터 구조 전체를 완전한 불변(immutable) 상태로 만드는 사용자 정의 유틸리티 타입이다 [1, 2]. 기본 내장된 `Readonly<T>` 유틸리티가 객체의 최상위 속성만 보호하는 얕은(shallow) 불변성만을 제공한다는 한계를 극복하기 위해 고안되었다 [1-3]. 상태 관리나 설정 객체와 같이, 객체 생성 이후 내부의 단 하나의 속성도 수정되지 않아야 함을 엄격하게 보장해야 할 때 주로 사용된다 [1, 4].
-
-## 📖 구조화된 지식 (Synthesized Content)
-- **얕은 불변성의 한계 극복:** TypeScript가 기본으로 제공하는 `Readonly<T>` 타입은 객체의 최상위 수준(top-level) 프로퍼티만 읽기 전용으로 제어한다 [1, 2]. 따라서 내부의 중첩된 객체는 여전히 수정 가능한 상태로 남게 되어 데이터 오염의 위험이 존재하는데, 깊은 수준의 불변성을 강제하기 위해서는 `DeepReadonly` 타입이 필요하다 [1-3].
-- **재귀적 구현 방식:** `DeepReadonly`는 매핑 타입(Mapped Types)과 조건부 타입(Conditional Types)을 결합하여 재귀적으로 정의된다 [4]. 일반적으로 `type DeepReadonly<T> = { readonly [P in keyof T]: DeepReadonly<T[P]> };`와 같은 형태로 작성되어, 중첩된 데이터 트리 구조의 모든 하위 속성에 `readonly` 수식어가 빠짐없이 적용되도록 만든다 [1, 2, 4].
-- **적용 및 가용성:** 이 타입은 데이터 무결성을 최우선으로 하는 프론트엔드 아키텍처나 복잡한 시스템에서 예기치 않은 데이터 변경을 차단하는 강력한 방패 역할을 수행한다 [4]. 하지만 `DeepReadonly`는 현재 TypeScript 언어 자체에 내장되어 있지 않다 [5]. 따라서 개발자가 프로젝트 내에서 직접 재귀적 유틸리티 타입을 선언하거나, `ts-essentials`와 같이 이를 제공하는 서드파티 라이브러리를 가져와 사용해야 한다 [5].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[readonly]], [[Readonly<T>]], [[Mapped Types]], [[Conditional Types]]
-- **Projects/Contexts:** [[상태 관리(State Management)]], [[설정 객체(Configuration Objects)]], [[ts-essentials]]
-- **Contradictions/Notes:** 깊은 수준의 불변성을 보장하는 기능이 실무적으로 널리 요구되었음에도 불구하고 `DeepReadonly`는 TypeScript에 공식적으로 기본 내장되어 있지 않다는 점이 특징적이다 [5]. 이로 인해 추가적인 구현이나 외부 라이브러리 의존성이 요구된다 [5].
-
----
-*Last updated: 2026-04-18*
-- Raw Source: [[00_Raw/2026-04-20/DeepReadonly.md]]
----
diff --git a/Programming & Language/DefinitelyTyped and Ambient Declarations.md b/Programming & Language/DefinitelyTyped and Ambient Declarations.md
deleted file mode 100644
index 4183ca71..00000000
--- a/Programming & Language/DefinitelyTyped and Ambient Declarations.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-8435E3
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - DefinitelyTyped and Ambient Declarations"
----
-
-# [[DefinitelyTyped and Ambient Declarations]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/DefinitelyTyped and Ambient Declarations.md]]
----
diff --git a/Programming & Language/Depth Pre-Pass.md b/Programming & Language/Depth Pre-Pass.md
deleted file mode 100644
index 63a999f8..00000000
--- a/Programming & Language/Depth Pre-Pass.md	
+++ /dev/null
@@ -1,35 +0,0 @@
----
-id: P-REINFORCE-AUTO-B5A436
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Depth Pre-Pass"
----
-
-# [[Depth Pre-Pass]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> Depth Pre-Pass는 복잡한 기하학적 구조를 가진 씬에서 가려진 객체를 제거하는 오클루전 컬링(Occlusion culling)을 수행하기 위해 사용되는 효과적인 렌더링 전략입니다 [1]. 특히 필 레이트(fill-rate)와 프래그먼트 처리 성능이 제한된 내장 GPU(iGPU) 환경에서 유용한 해결책으로 활용됩니다 [1]. 렌더링을 두 단계로 나누어 불필요한 프래그먼트 셰이더 연산을 방지함으로써 오버드로우(overdraw)가 심한 모델의 렌더링 성능을 크게 향상시킵니다 [1, 2].
-
-## 📖 구조화된 지식 (Synthesized Content)
-* **작동 원리 (두 단계의 렌더링 프로세스):** Depth Pre-Pass는 다음과 같은 두 가지 렌더링 단계로 구성됩니다 [1].
-  1. **Stage 1 (Depth-Only):** 씬 전체를 `MeshBasicMaterial`과 같이 매우 단순한 재질을 사용하여 렌더링하며, 이때 색상 쓰기 기능은 비활성화(`colorWrite: false`)합니다 [1]. 이 첫 번째 패스는 가장 가까운 프래그먼트의 깊이(depth) 값으로 Z-버퍼(Z-buffer)를 채우는 역할만을 수행합니다 [1].
-  2. **Stage 2 (Main Render):** 깊이 테스트(depth test) 함수를 `EQUAL`로 설정한 후, 전체 셰이딩을 적용하여 씬을 다시 렌더링합니다 [1]. Z-버퍼에는 이미 화면에 보이는 표면의 깊이 값만 저장되어 있으므로, GPU는 다른 물체에 가려진(occluded) 프래그먼트들이 연산 비용이 높은 메인 셰이더 로직에 진입하기 전에 이를 자동으로 폐기(discard)합니다 [1].
-
-* **성능 향상 및 적용 효과:** 
-  이러한 수동 Z-prepass 로직을 구현하면 프래그먼트 셰이더에 가해지는 부하를 최대 30%까지 줄일 수 있습니다 [2]. 이는 숨겨진 내부 기하구조 레이어가 많아 픽셀이 여러 번 덧그려지는 '오버드로우(overdraw)'가 심하게 발생하는 CAD 모델을 렌더링할 때 특히 귀중한 최적화 기법입니다 [2]. 개발자들은 이러한 깊이 기반의 가시성 판별(Depth Pre-Pass) 기술을 구조적 최적화 및 Render-on-Demand 실행 모델과 결합하여, 표준 모바일 하드웨어에서도 워크스테이션 수준의 시각화 경험을 제공할 수 있습니다 [3].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[Occlusion Culling]], [[Z-buffer]], [[Overdraw]], [[Fragment Shader]]
-- **Projects/Contexts:** [[WebGL/Three.js CAD Rendering Optimization]]
-- **Contradictions/Notes:** 소스에 상충되는 내용은 없으며, 오클루전 컬링을 CPU에서 처리하기 어렵거나 GPU 레이턴시로 인해 비용이 높을 때 이를 해결하는 가장 효과적인 우회(workaround) 기법으로 설명됩니다 [1].
-
----
-*Last updated: 2026-04-19*
-- Raw Source: [[00_Raw/2026-04-20/Depth Pre-Pass.md]]
----
diff --git a/Programming & Language/Description Logic (기술 논리).md b/Programming & Language/Description Logic (기술 논리).md
deleted file mode 100644
index 78e4be28..00000000
--- a/Programming & Language/Description Logic (기술 논리).md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-442F1D
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Description Logic (기술 논리)"
----
-
-# [[Description Logic (기술 논리)]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Description Logic (기술 논리).md]]
----
diff --git a/Programming & Language/Deterministic Algorithms.md b/Programming & Language/Deterministic Algorithms.md
deleted file mode 100644
index 7cbd5b1c..00000000
--- a/Programming & Language/Deterministic Algorithms.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-FB6D64
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Deterministic Algorithms"
----
-
-# [[Deterministic Algorithms]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Deterministic Algorithms.md]]
----
diff --git a/Programming & Language/Discriminated Unions.md b/Programming & Language/Discriminated Unions.md
deleted file mode 100644
index a27d8719..00000000
--- a/Programming & Language/Discriminated Unions.md	
+++ /dev/null
@@ -1,40 +0,0 @@
----
-id: P-REINFORCE-AUTO-DEC013
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Discriminated Unions"
----
-
-# [[Discriminated Unions]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> Discriminated Unions(또는 식별 가능한 유니온, 태그된 유니온)은 서로 다른 데이터 형태를 구분하기 위해 공통된 리터럴 속성(판별자, Discriminant)을 사용하는 TypeScript의 패턴입니다 [1-3]. 일반적인 유니온 타입과 달리, 컴파일러가 판별자 속성을 확인하여 타입을 자동으로 안전하게 좁힐 수(Narrowing) 있게 해줍니다 [4-6]. 이를 통해 유효하지 않은 상태의 표현을 원천적으로 차단하고, 모든 가능한 경우를 처리하도록 강제하는 완전성 검사(Exhaustiveness checking)를 구현할 수 있습니다 [3, 7, 8].
-
-## 📖 구조화된 지식 (Synthesized Content)
-* **작동 원리 및 특징**
-  Discriminated Union은 객체들이 공통으로 가지는 식별자 필드(주로 `kind`, `type`, `status` 같은 문자열 리터럴)를 활용하여 구성됩니다 [2-4]. 이 공통 속성을 기반으로 TypeScript의 코드 흐름 분석이 진행되며, 특정 브랜치에서 타입을 명확하게 좁혀줍니다 [3, 4, 9]. 이는 런타임 오버헤드가 전혀 추가되지 않는 컴파일 타임 전용 구조입니다 [10].
-
-* **주요 장점**
-  가장 큰 장점은 올바르지 않은 조합의 상태(Invalid states)를 코드로 표현할 수 없게 만들어 구조적으로 버그를 방지한다는 것입니다 [1, 7, 11]. 또한 `switch` 문과 `never` 타입을 결합하면 모든 유니온 케이스가 처리되었는지 컴파일러가 확인하는 '완전성 검사(Exhaustive checking)'가 가능합니다 [3, 12-14]. 유니온에 새로운 타입 멤버가 추가되었을 때 이를 누락한 코드를 즉각적인 컴파일 에러로 포착해 내므로 유지보수성이 크게 향상됩니다 [3, 8].
-
-* **사용 사례 (Use Cases)**
-  API 응답 데이터 처리, 폼(Form) 핸들링, Redux 스타일의 리듀서(Reducer), 라우터 상태 관리, 그리고 상태 머신(State Machine) 패턴을 모델링하는 데 매우 적합합니다 [7, 15-17]. 복잡한 상태를 표현해야 할 때는 다중 판별자(Multiple Discriminants)를 두거나 유니온을 중첩(Nested)하는 방식으로도 활용할 수 있습니다 [15, 16].
-
-* **주의사항 및 베스트 프랙티스**
-  판별자로는 항상 문자열 리터럴 타입을 사용하는 것이 권장되며, 모든 브랜치에 걸쳐 일관된 판별자 속성을 포함해야 합니다 [12, 16, 18]. 타입을 좁힐 때는 `instanceof` 연산자를 사용하는 대신 반드시 판별자 속성을 확인해야 합니다 [18]. 단, 아주 거대한 코드베이스에서 과도하게 복잡한 유니온 타입을 사용하면 TypeScript의 컴파일 속도가 느려질 수 있으며, 깊게 중첩될 경우 에러 메시지를 파악하기 어려워질 수 있으므로 주의해야 합니다 [10].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[Union Types]], [[Type Narrowing]], [[Exhaustiveness Checking]], [[Literal Types]], [[never type]]
-- **Projects/Contexts:** [[React State Management]], [[State Machine Pattern]], [[API Response Handling]], [[Redux Reducers]]
-- **Contradictions/Notes:** Discriminated Union 패턴은 타입 안정성과 예측 가능성을 크게 높여주지만, 유니온 타입이 지나치게 복잡해지거나 깊은 중첩 구조를 가지게 되면 오히려 TypeScript의 컴파일 성능을 저하시키고 에러 메시지의 가독성을 떨어뜨리는 부작용(단점)을 유발할 수 있습니다 [10].
-
----
-*Last updated: 2026-04-18*
-- Raw Source: [[00_Raw/2026-04-20/Discriminated Unions.md]]
----
diff --git a/Programming & Language/Disentanglement (개념 분리).md b/Programming & Language/Disentanglement (개념 분리).md
deleted file mode 100644
index cb6f6591..00000000
--- a/Programming & Language/Disentanglement (개념 분리).md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-3C9639
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Disentanglement (개념 분리)"
----
-
-# [[Disentanglement (개념 분리)]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Disentanglement (개념 분리).md]]
----
diff --git a/Programming & Language/Draw Call Optimization.md b/Programming & Language/Draw Call Optimization.md
deleted file mode 100644
index ccc40ba1..00000000
--- a/Programming & Language/Draw Call Optimization.md	
+++ /dev/null
@@ -1,36 +0,0 @@
----
-id: P-REINFORCE-AUTO-0B8FFC
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Draw Call Optimization"
----
-
-# [[Draw Call Optimization]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 드로우 콜(Draw Call)은 CPU가 GPU에게 기하학적 구조, 재질, 렌더링 지침 등을 전달하여 화면에 객체를 그리도록 내리는 명령입니다 [1-3]. 각 드로우 콜을 준비하고 상태를 변경하는 과정에서 막대한 CPU 오버헤드가 발생하기 때문에, 드로우 콜 횟수를 줄이는 것은 애플리케이션의 프레임 속도와 전반적인 렌더링 성능을 개선하고 병목 현상을 방지하는 핵심 최적화 기법입니다 [4-6].
-
-## 📖 구조화된 지식 (Synthesized Content)
-* **드로우 콜의 성능 병목 (Bottlenecks):** 그래픽 API가 GPU에 렌더링 상태를 설정하고 명령을 내리는 준비 과정은 실제 GPU가 픽셀을 렌더링하는 것보다 더 많은 CPU 자원을 소모합니다 [2, 4, 6]. 이로 인해 개별 객체를 수천 번 분리하여 그리면 GPU의 폴리곤 처리 한계에 도달하기도 전에 CPU 병목이 발생하여 시스템 프레임 레이트가 급감합니다 [5, 7]. 최신 기기에서 부드러운 60fps를 유지하려면 프레임당 드로우 콜을 100개 이하로 타겟팅하는 것이 권장되며 [8-10], WebGL 환경에서의 실질적인 한계는 1,000~2,000회 수준입니다 [11].
-* **주요 최적화 기법 (Optimization Techniques):**
-  * **인스턴싱 (Instancing):** `InstancedMesh` 등을 사용하여 동일한 기하학적 구조와 재질을 가진 객체의 수많은 복제본을 단 한 번의 드로우 콜로 렌더링합니다 [8, 12-14]. 나무, 풀, 파티클 시스템과 같이 반복되는 요소에 효율적입니다 [12, 15].
-  * **배칭 및 병합 (Batching & Merging):** `BatchedMesh`는 동일한 재질을 공유하지만 서로 다른 기하학적 구조를 가진 객체들을 하나의 드로우 콜로 묶어 처리할 수 있게 합니다 [16, 17]. 정적인 환경 요소는 `BufferGeometryUtils`와 같은 도구를 사용해 하나의 지오메트리로 병합(Merging)하면 여러 드로우 콜을 한 번으로 줄일 수 있습니다 [16, 18-21].
-  * **재질 및 텍스처 공유 (Material & Texture Sharing):** 객체마다 새로운 재질을 생성하는 것은 최적화를 저해합니다 [16, 19]. 텍스처 아틀라스(Texture Atlas)나 배열 텍스처(Array Textures)를 활용하여 재질을 공유함으로써 텍스처 바인딩 및 상태 변경에 따른 추가적인 드로우 콜을 방지합니다 [20, 22-24].
-  * **가시성 제어 (Visibility & LOD):** 카메라 시야 밖의 객체에 대한 렌더링 명령을 제외하는 절두체 컬링(Frustum Culling)을 수행하고 [18, 25], 카메라와의 거리에 따라 기하학적 복잡도를 낮추는 LOD(Level of Detail) 기법을 적용하여 멀리 있는 객체에서 발생하는 불필요한 드로우 콜과 연산을 최소화합니다 [9, 26-28].
-* **구조적 한계 및 고려사항 (Limitations & Trade-offs):** `InstancedMesh`를 통한 드로우 콜 단일화가 항상 최선은 아닙니다. 단일 객체로 취급되어 가시성 판정이 '전부 아니면 전무(All-or-Nothing)'로 이루어져 절두체 컬링이 비효율적으로 작동할 수 있습니다 [29, 30]. 또한, 인스턴스 간 자동 정렬 부재로 인한 심각한 오버드로우(Overdraw) 현상과 매 프레임 수많은 변환 행렬 데이터를 갱신할 때 발생하는 메모리 대역폭 한계로 인해 또 다른 성능 병목이 유발될 수 있습니다 [29, 31, 32]. Unity 같은 게임 엔진에서는 이와 같은 드로우 콜 최적화 방식들이 겹칠 때 SRP Batcher, 정적 배칭(Static batching), GPU 인스턴싱 순으로 우선순위를 두어 충돌을 제어합니다 [33, 34].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[InstancedMesh]], [[BatchedMesh]], [[Frustum Culling]], [[Texture Atlas]], [[Level of Detail (LOD)]]
-- **Projects/Contexts:** [[Three.js]], [[WebGL]], [[Unity]]
-- **Contradictions/Notes:** 일반적으로 드로우 콜을 줄이는 것은 렌더링 성능을 향상시킨다고 알려져 있지만, `InstancedMesh`를 통해 드로우 콜을 1회로 줄였음에도 불구하고 정렬되지 않은 인스턴스들이 유발하는 막대한 오버드로우(Overdraw) 비용이나 비효율적인 컬링으로 인해, 개별 메쉬를 렌더링할 때보다 오히려 프레임 속도(FPS)가 낮아지는 역설적인 상황이 실증적 연구와 버그 리포트 등에서 보고되고 있습니다 [29, 31, 35].
-
----
-*Last updated: 2026-04-19*
-- Raw Source: [[00_Raw/2026-04-20/Draw Call Optimization.md]]
----
diff --git a/Programming & Language/Dublin Core Metadata Initiative.md b/Programming & Language/Dublin Core Metadata Initiative.md
deleted file mode 100644
index 2327d14d..00000000
--- a/Programming & Language/Dublin Core Metadata Initiative.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-4C7308
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Dublin Core Metadata Initiative"
----
-
-# [[Dublin Core Metadata Initiative]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Dublin Core Metadata Initiative.md]]
----
diff --git a/Programming & Language/Dwarf Fortress (Simulation-heavy PCG).md b/Programming & Language/Dwarf Fortress (Simulation-heavy PCG).md
deleted file mode 100644
index 2a2744f9..00000000
--- a/Programming & Language/Dwarf Fortress (Simulation-heavy PCG).md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-D6FB1C
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Dwarf Fortress (Simulation-heavy PCG)"
----
-
-# [[Dwarf Fortress (Simulation-heavy PCG)]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Dwarf Fortress (Simulation-heavy PCG).md]]
----
diff --git a/Programming & Language/Dwarf-Fortress.md b/Programming & Language/Dwarf-Fortress.md
deleted file mode 100644
index 96fc827d..00000000
--- a/Programming & Language/Dwarf-Fortress.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-1E23B6
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Dwarf-Fortress"
----
-
-# [[Dwarf-Fortress]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Dwarf-Fortress.md]]
----
diff --git a/Programming & Language/ESLint.md b/Programming & Language/ESLint.md
deleted file mode 100644
index 2ea9e997..00000000
--- a/Programming & Language/ESLint.md	
+++ /dev/null
@@ -1,40 +0,0 @@
----
-id: P-REINFORCE-AUTO-BDDA30
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - ESLint"
----
-
-# [[ESLint]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> ESLint는 자바스크립트 및 타입스크립트 코드에서 문법적 오류와 잠재적 버그를 식별하고 코딩 컨벤션을 강제하는 정적 분석 도구(Linter)입니다 [1, 2]. 소스 코드를 실행하지 않고 추상 구문 트리(AST)로 변환하여 사전에 정의된 논리 및 스타일 규칙을 적용함으로써 런타임 에러를 방지합니다 [3, 4]. 주로 코드 품질을 보장하고 팀 내 일관된 스타일을 유지하기 위해 사용되며, 코드 포매팅 도구인 Prettier와 함께 모던 웹 개발 환경의 필수적인 도구로 활용됩니다 [1, 5].
-
-## 📖 구조화된 지식 (Synthesized Content)
-* **정적 분석 및 코드 품질 관리**
-  ESLint는 런타임 환경 이전에 소스 코드의 문제 패턴을 식별하는 정적 분석 도구입니다 [1, 6]. 사용되지 않는 변수, 글로벌 스코프 오염, 잘못된 API 사용 등 잠재적인 버그를 검출하고 코드 퀄리티 규칙을 강제하여 일관된 코드 작성을 돕습니다 [2, 7, 8]. 발견된 문제 중 특정 문법이나 스타일 위반은 `--fix` 옵션을 통해 자동으로 수정(Auto-fixing)할 수 있습니다 [9-11].
-
-* **설정 및 규칙 커스터마이징**
-  ESLint의 규칙은 `off`(0), `warn`(1), `error`(2) 등 세 가지 수준으로 커스터마이징하여 적용할 수 있습니다 [12, 13]. 프로젝트별로 `.eslintrc` 파일이나 ESLint 9부터 도입된 Flat Config(예: `eslint.config.mjs`) 포맷을 통해 설정을 중앙화하고 관리할 수 있습니다 [14-16]. 주로 Airbnb나 Google 스타일 가이드처럼 널리 쓰이는 규칙을 확장(extends)하여 사용하며, TypeScript(`@typescript-eslint`), React(`eslint-plugin-react`) 등을 지원하는 다양한 서드파티 플러그인(plugins)을 장착할 수 있습니다 [17-19].
-
-* **Prettier와의 역할 분담 및 충돌 해결**
-  ESLint는 코드 품질(버그 탐지)에 초점을 맞추는 반면, Prettier는 코드 포매팅(시각적 통일성)에 중점을 둡니다 [2, 5, 20]. ESLint에도 일부 포매팅 규칙이 포함되어 있어 두 도구를 함께 사용할 경우 충돌이 발생할 수 있습니다 [21, 22]. 이를 해결하기 위해 `eslint-config-prettier` 패키지를 사용하여 Prettier와 충돌하는 ESLint의 스타일 규칙을 비활성화(off)하는 방법이 가장 널리 권장됩니다 [21, 23-25].
-
-* **워크플로우 및 자동화 연동**
-  코드 변경 사항이 Git 저장소에 반영되기 전, 나쁜 코드가 커밋되는 것을 방지하기 위해 자동화 파이프라인과 결합하여 사용됩니다 [26, 27]. 주로 `Husky`와 `lint-staged` 도구를 활용하여, Git의 `pre-commit` 훅(hook) 단계에서 변경된(staged) 파일에 대해서만 ESLint 검사 및 자동 수정을 실행하도록 구성합니다 [11, 28-30]. 대규모 모노레포(Monorepo) 환경에서는 중복 구성을 피하기 위해 중앙집중식 ESLint 설정 패키지를 만들어 각 하위 패키지가 이를 공유하도록 구성하여 효율성을 극대화합니다 [15, 31, 32].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[Prettier]], [[Husky]], [[lint-staged]], [[정적 분석(Static Analysis)]], [[AST(Abstract Syntax Tree)]]
-- **Projects/Contexts:** [[모노레포(Monorepo) 기반 구성 중앙화]], [[Git Hook을 이용한 CI/CD 자동화 파이프라인]]
-- **Contradictions/Notes:** 소스 [33]에서는 `eslint-plugin-prettier` 사용 시 에디터에 밑줄이 너무 많이 생기고 느려져 문서에서도 추천하지 않는다며 설정을 삭제했다고 언급하지만, 소스 [25]에서는 Prettier의 포매팅 이슈를 ESLint의 린터 오류로 띄워 통합적으로 관리할 수 있는 효과적인 방식이라고 설명하는 등 개발자 또는 조직 간의 `eslint-plugin-prettier` 활용에 대해 엇갈린 평가 및 설정 선호도 차이가 존재합니다.
-
----
-*Last updated: 2026-04-18*
-- Raw Source: [[00_Raw/2026-04-20/ESLint.md]]
----
diff --git a/Programming & Language/Early-Z.md b/Programming & Language/Early-Z.md
deleted file mode 100644
index 1ab5cba2..00000000
--- a/Programming & Language/Early-Z.md	
+++ /dev/null
@@ -1,32 +0,0 @@
----
-id: P-REINFORCE-AUTO-D03C5F
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Early-Z"
----
-
-# [[Early-Z]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> Early-Z(초기 깊이 테스트)는 렌더링 파이프라인의 프래그먼트 셰이딩(Fragment Shading) 단계에서 오버드로우(Overdraw)를 최소화하기 위해 사용되는 GPU 최적화 기법입니다 [1, 2]. 불투명한 물체를 카메라 기준 '앞에서 뒤로(Front-to-Back)' 정렬하여 렌더링함으로써, 다른 물체에 의해 가려져 화면에 보이지 않을 픽셀의 연산을 사전에 종료시킵니다 [2]. 하지만 투명한 재질을 렌더링할 때는 이 최적화 기능이 비활성화되는 특성이 있습니다 [1].
-
-## 📖 구조화된 지식 (Synthesized Content)
-- **Early-Z의 원리와 목적:** 렌더링 과정에서 동일한 픽셀 위치에 여러 번의 쓰기 작업이 중첩되어 발생하는 현상을 오버드로우라고 부르며, 이는 보이지 않는 계산에 GPU 자원을 낭비하게 만듭니다 [1, 2]. 불투명한 물체들을 '앞에서 뒤로(Front-to-Back)' 정렬하여 그릴 경우, GPU는 이미 렌더링된 앞쪽 표면에 의해 가려지는 뒤쪽 픽셀 연산을 조기에 종료(Early-Z)시켜 렌더링 효율을 크게 높입니다 [1, 2].
-- **투명 재질 렌더링 시의 비활성화:** 겹쳐 있는 투명한 기하학적 구조(예: 옷, 머리카락 레이어 등)를 렌더링할 때는 올바른 알파 블렌딩 결과를 얻기 위해 '뒤에서 앞으로(Back-to-Front)' 렌더링을 강제해야 합니다 [1, 3]. 이 과정에서 숨겨진 픽셀을 건너뛰게 해주는 초기 깊이 테스트(Early-Z) 최적화가 비활성화되며, 결과적으로 하나의 픽셀을 여러 번 렌더링하는 심각한 오버드로우가 발생하게 됩니다 [1].
-- **InstancedMesh 환경에서의 한계:** 드로우 콜을 줄여주는 `InstancedMesh` 기술은 내부 인스턴스들에 대한 자동 정렬 기능을 제공하지 않고 버퍼에 저장된 순서대로만 렌더링합니다 [2]. 만약 먼 곳에 있는 인스턴스가 먼저 그려지고 가까운 인스턴스가 나중에 그려진다면, Early-Z를 통한 조기 종료 이점을 얻지 못합니다 [2]. 이는 드로우 콜 감소로 얻은 이점보다 막대한 오버드로우 비용을 초래하여, GPU를 프래그먼트 바운드(Fragment-bound) 상태에 빠뜨려 전체 성능을 오히려 저하시킬 수 있습니다 [2].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[Overdraw]], [[InstancedMesh]], [[Alpha Blending]]
-- **Projects/Contexts:** [[Three.js WebGL 렌더링 최적화]]
-- **Contradictions/Notes:** 소스에 관련 정보가 부족합니다.
-
----
-*Last updated: 2026-04-19*
-- Raw Source: [[00_Raw/2026-04-20/Early-Z.md]]
----
diff --git a/Programming & Language/Edge Bleeding.md b/Programming & Language/Edge Bleeding.md
deleted file mode 100644
index b0af8b8b..00000000
--- a/Programming & Language/Edge Bleeding.md	
+++ /dev/null
@@ -1,32 +0,0 @@
----
-id: P-REINFORCE-AUTO-2BC744
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Edge Bleeding"
----
-
-# [[Edge Bleeding]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> Edge Bleeding(경계선 블리딩)은 여러 이미지를 하나로 합친 텍스처 아틀라스(Texture Atlas)를 사용할 때 주로 발생하는 시각적 결함입니다 [1]. 특히 낮은 밉맵(Mipmap) 레벨에서 텍스처 필터링이 일어날 때, 아틀라스 내에 인접해 있는 텍스처들의 색상이 서로 섞이거나 번지는 현상을 의미합니다 [1, 2]. 이를 방지하기 위해서는 텍스처 간에 여백을 두어 메모리를 희생하거나, 최신 텍스처 배열(Data Array Textures) 기술을 활용해야 합니다 [2, 3].
-
-## 📖 구조화된 지식 (Synthesized Content)
-- **발생 원인:** 동일한 재질을 공유하여 드로우 콜(Draw call)을 최적화하기 위해 여러 텍스처를 하나의 큰 이미지로 병합하는 텍스처 아틀라스 방식을 사용할 때 발생합니다 [1, 2]. GPU가 거리에 따라 해상도를 낮춘 밉맵을 생성하고 필터링하는 과정에서 인접한 텍스처 영역의 픽셀이 침범하여 색상이 섞이게 됩니다 [1, 2].
-- **기존의 해결 방식과 한계:** 이 현상을 방지하기 위해 텍스처 아틀라스 내부의 개별 텍스처들 사이에 물리적인 여백(Padding)을 추가하는 우회 기법이 사용됩니다 [2]. 하지만 이 방식은 텍스처 공간을 낭비하게 만들어 메모리 비효율성을 초래합니다 [2].
-- **현대적인 해결책 (Data Array Textures):** WebGL 2.0에서 지원하는 데이터 배열 텍스처(Data Array Textures)를 사용하면 Edge Bleeding을 완벽히 제거할 수 있습니다 [3, 4]. 이 방식은 텍스처를 평면에 병합하는 대신 레이어(Layer) 구조의 스택으로 쌓아 인덱스로 접근하므로, 밉맵 생성 시 인접 텍스처 간의 교차 오염(Cross-contamination)이 발생하지 않습니다 [1, 3].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[Texture Atlas]], [[Mipmap]], [[Data Array Textures]]
-- **Projects/Contexts:** [[InstancedMesh 최적화]], [[WebGL 2.0]]
-- **Contradictions/Notes:** 소스에 관련 정보가 부족합니다. (소스 내에서 명시적인 의견 대립은 발견되지 않으며, Edge Bleeding은 텍스처 아틀라스의 명확한 단점[1, 2]이자 WebGL 2.0의 텍스처 배열 도입으로 쉽게 극복 가능한 문제[3, 4]로 일관되게 설명됩니다.)
-
----
-*Last updated: 2026-04-19*
-- Raw Source: [[00_Raw/2026-04-20/Edge Bleeding.md]]
----
diff --git a/Programming & Language/Effect TS 및 ts-brand 라이브러리 활용.md b/Programming & Language/Effect TS 및 ts-brand 라이브러리 활용.md
deleted file mode 100644
index 873cb1b0..00000000
--- a/Programming & Language/Effect TS 및 ts-brand 라이브러리 활용.md	
+++ /dev/null
@@ -1,38 +0,0 @@
----
-id: P-REINFORCE-AUTO-C0B018
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Effect TS 및 ts-brand 라이브러리 활용"
----
-
-# [[Effect TS 및 ts-brand 라이브러리 활용]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> Effect TS와 ts-brand는 TypeScript에서 구조적으로 동일해 보이는 타입들을 서로 구별하기 위해 고안된 '브랜드 타입(Branded Types)' 패턴의 적용을 돕는 인기 있는 커뮤니티 라이브러리입니다 [1, 2]. TypeScript는 기본적으로 구조적 타이핑(Structural Typing)을 따르지만, 이 라이브러리들을 활용하면 명목적(Nominal) 타이핑과 유사한 안전장치를 마련할 수 있습니다 [2, 3]. 이를 통해 개발자는 단순한 원시 타입(Primitive Type)을 넘어, 비즈니스 규칙이 검증된 안전하고 정교한 타입을 코드 전반에 강제할 수 있습니다 [1, 2].
-
-## 📖 구조화된 지식 (Synthesized Content)
-- **ts-brand 라이브러리의 기능과 활용**
-  - `ts-brand`는 타입 브랜드(Type Brands)를 위한 사전 작성된 코드를 제공하여 개발자가 쉽게 브랜디드 타입을 사용할 수 있게 해주는 커뮤니티 패키지입니다 [2].
-  - 브랜딩을 위한 고급 기능을 제공하며 [4], 제네릭 `Brand` 타입을 내보내어 고유한 브랜드 타입들을 생성하는 데 활용됩니다 [2].
-
-- **Effect TS 프레임워크의 브랜디드 타입 지원**
-  - Effect는 타입이 풍부한 TypeScript 애플리케이션을 구축하기 위한 범용 프레임워크로, 타입 브랜드를 다루기 위한 전용 `Brand` 유틸리티를 제공합니다 [5].
-  - 주요 유틸리티로 타입 내에서 브랜드 역할을 하는 제네릭 타입인 `Brand.Brand`와, 타입 브랜드 식별 함수를 반환하는 제네릭 함수인 `Brand.nominal`이 있으며, 이 둘을 결합하여 `ts-brand`와 유사한 브랜드 타입을 생성할 수 있습니다 [5].
-  - **단언(Assertion) 함수의 차별화**: `ts-brand`의 `make`와 달리, Effect는 타입 브랜드 단언 함수를 만들기 위해 `Brand.refined`라는 별도의 함수를 제공합니다 [5]. 이 함수는 값이 제약 조건을 충족하는지 판별하는 함수와, 충족하지 않을 경우 에러를 던지는 함수 등 두 가지 매개변수를 받아 작동합니다 [5, 6].
-  - **메타데이터 활용**: Effect TS는 에러 처리나 내부 제어 흐름을 명확히 구분하기 위해 `_tag`와 같은 메타데이터 속성을 활용하는 패턴을 제공하며, 이는 복잡한 로직에서 일관된 에러 처리와 내부 로직 판별을 돕습니다 [7, 8].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[Branded Types]], [[Opaque Types]], [[Nominal Typing]], [[Structural Typing]]
-- **Projects/Contexts:** [[TypeScript Type Safety]]
-- **Contradictions/Notes:** 두 라이브러리는 모두 타입 안정성을 높이는 데 기여하지만, 타입 브랜드 단언 함수를 다루는 방식에서 차이를 보입니다. `ts-brand`는 `make`를 활용하는 반면, `Effect TS`는 유효성 검사 함수와 에러 처리 함수를 분리하여 입력받는 `Brand.refined`를 사용하도록 설계되었습니다 [5, 6].
-
----
-*Last updated: 2026-04-18*
-- Raw Source: [[00_Raw/2026-04-20/Effect TS 및 ts-brand 라이브러리 활용.md]]
----
diff --git a/Programming & Language/Effect TS.md b/Programming & Language/Effect TS.md
deleted file mode 100644
index 97b5e245..00000000
--- a/Programming & Language/Effect TS.md	
+++ /dev/null
@@ -1,32 +0,0 @@
----
-id: P-REINFORCE-AUTO-C7A07F
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Effect TS"
----
-
-# [[Effect TS]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> Effect TS는 타입이 풍부한(type-rich) TypeScript 애플리케이션을 구축하기 위해 널리 사용되는 인기 있는 프레임워크입니다 [1]. 이 프레임워크는 주로 구조적으로 동일해 보이는 타입들을 명확히 구분하기 위한 브랜디드 타입(Branded Types) 유틸리티를 제공합니다 [1, 2]. 또한, 예상되는 에러와 예상치 못한 에러를 구분하거나 `_tag` 속성을 통해 메타데이터를 관리하는 등 타입 시스템을 활용한 다양한 패턴의 기반을 제공합니다 [3, 4].
-
-## 📖 구조화된 지식 (Synthesized Content)
-* **브랜디드 타입(Branded Types) 도구 제공**: Effect TS는 TypeScript 커뮤니티에서 널리 쓰이는 대표적인 브랜디드 타입 라이브러리 중 하나입니다 [2]. 타입 내에서 브랜드 역할을 하는 제네릭 타입인 `Brand.Brand`와 타입 브랜드 식별 함수를 반환하는 제네릭 함수 `Brand.nominal`을 제공하여 사용자가 브랜디드 타입을 쉽게 생성할 수 있도록 지원합니다 [1].
-* **정교한 타입 브랜드 단언 함수(`Brand.refined`)**: Effect TS는 제약 조건을 검증하기 위해 `Brand.refined`라는 함수를 별도로 제공합니다 [1, 5]. 이 함수는 값이 제약 조건을 충족하는지 확인하는 함수와, 제약 조건과 일치하지 않을 경우 에러를 던지는 함수라는 두 가지 매개변수를 활용하여 안전한 타입 단언(assertion)을 수행합니다 [5].
-* **에러 처리 및 메타데이터 컨벤션 모델링**: Effect TS는 시스템의 '예상되는 에러(Expected Errors)'와 '예상치 못한 에러(Defects)'를 명확히 구분하는 아키텍처적 접근법을 제시합니다 [3]. 이와 더불어 내부 로직이나 디버깅, 관측 도구에서 사용되는 데이터를 다른 응답 객체와 시각적으로 구분하기 위해 `_tag`와 같은 속성(메타데이터)을 사용하는 훌륭한 컨벤션을 제공합니다 [4, 6].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[Branded Types]], [[TypeScript]]
-- **Projects/Contexts:** [[Type-rich TypeScript Applications]]
-- **Contradictions/Notes:** 소스에 관련 정보가 부족합니다.
-
----
-*Last updated: 2026-04-18*
-- Raw Source: [[00_Raw/2026-04-20/Effect TS.md]]
----
diff --git a/Programming & Language/Electron V8 Memory Cage.md b/Programming & Language/Electron V8 Memory Cage.md
deleted file mode 100644
index ae0a3e20..00000000
--- a/Programming & Language/Electron V8 Memory Cage.md	
+++ /dev/null
@@ -1,34 +0,0 @@
----
-id: P-REINFORCE-AUTO-2DCEFC
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Electron V8 Memory Cage"
----
-
-# [[Electron V8 Memory Cage]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> Electron 21 이상 버전(Chrome 103을 따름)에 도입된 V8 메모리 케이지(Memory Cage)는 포인터 압축(Pointer Compression) 기술과 연계되어 V8 힙 내의 메모리 참조를 베이스 주소의 오프셋으로만 저장하도록 강제하는 보안 및 최적화 메커니즘입니다 [1-3]. 이를 통해 JIT 컴파일러의 타입 혼동(Type Confusion) 취약점을 악용한 임의 메모리 읽기/쓰기 공격을 케이지 내부 영역으로만 격리할 수 있습니다 [2, 4]. 결과적으로 애플리케이션의 보안성, 성능, 메모리 효율은 크게 향상되지만, V8 힙 크기가 최대 4GB로 제한되며 외부(Off-heap) 메모리를 가리키는 ArrayBuffer 사용이 금지된다는 제약이 발생합니다 [5, 6].
-
-## 📖 구조화된 지식 (Synthesized Content)
-*   **도입 배경과 이점**: Electron 21부터 활성화된 이 기능은 Chromium과의 내부 세부 사항 격차를 줄이고, 보안과 성능을 높이기 위해 도입되었습니다 [1, 6]. 64비트 플랫폼에서 포인터를 64비트 전체 주소가 아닌 32비트 오프셋으로 압축하여 저장하므로, V8 힙 크기를 최대 40% 줄이고 CPU 및 가비지 컬렉션(GC) 성능을 5%~10% 향상시킵니다 [3, 6]. 또한, 공격자가 V8 JIT 엔진의 타입 혼동 버그를 악용해 ArrayBuffer 베이스 주소를 변조하여 프로세스의 모든 메모리에 접근하려는 심각한 취약점 공격으로부터 앱을 보호합니다 [2, 4, 6].
-
-*   **제한 사항 및 부작용**: 메모리 케이지 및 포인터 압축이 활성화됨에 따라, 단일 V8 격리 인스턴스(Isolate)의 힙 메모리 크기는 최대 4GB의 연속된 "케이지" 영역으로 엄격하게 제한됩니다 [3, 5, 7]. 가장 주요한 단점은 V8 힙 외부(Off-heap)의 메모리를 가리키는 `ArrayBuffer`가 더 이상 허용되지 않는다는 것입니다 [5, 7]. 외부에서 메모리를 할당(`malloc` 등)하고 이를 `ArrayBuffer`로 래핑하던 기존 Node.js 네이티브 모듈들은 Electron 20 이상 버전에서 런타임 충돌(Crash)을 일으키게 됩니다 [5, 8].
-
-*   **네이티브 모듈 리팩토링 및 대안**: 외부 메모리를 사용하는 네이티브 모듈을 호환되도록 수정하려면 두 가지 주요 접근법이 있습니다 [9]. 첫째는 외부에서 생성된 버퍼 데이터를 JavaScript에 전달하기 전에 V8 메모리 케이지 내부 영역으로 "복사(Copy)"하는 방법입니다 [9, 10]. 둘째는 데이터를 복사하는 오버헤드를 피하기 위해, 처음부터 V8의 메모리 할당자(예: `napi_create_buffer`)를 사용하여 케이지 내부에 메모리를 할당하는 방법입니다 [9, 10]. 또한 4GB 힙 한계를 극복해야 하는 앱의 경우, 포인터 압축이 해제된 Node.js를 하위 프로세스로 실행하거나 커스텀 Electron 버전을 빌드하는 우회 방법을 사용할 수 있습니다 [11].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[Pointer Compression]], [[ArrayBuffer]], [[Type Confusion]], [[JIT Compiler]]
-- **Projects/Contexts:** [[Electron 21]], [[Chromium]], [[Node.js Native Modules]]
-- **Contradictions/Notes:** 소스에 따르면 V8 Memory Cage 및 Pointer Compression은 힙 크기를 최대 40% 줄이고 성능을 5-10% 향상시키는 등 긍정적 효과가 크지만 [6], 그 대가로 네이티브 모듈의 오프힙(Off-heap) 메모리 래핑을 금지시키고 힙을 4GB로 엄격히 제한하는 뚜렷한 트레이드오프를 가지고 있습니다 [3, 5, 7].
-
----
-*Last updated: 2026-04-19*
-- Raw Source: [[00_Raw/2026-04-20/Electron V8 Memory Cage.md]]
----
diff --git a/Programming & Language/Electron.md b/Programming & Language/Electron.md
deleted file mode 100644
index 16648290..00000000
--- a/Programming & Language/Electron.md	
+++ /dev/null
@@ -1,32 +0,0 @@
----
-id: P-REINFORCE-AUTO-687305
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Electron"
----
-
-# [[Electron]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> Electron은 대규모 CAD 애플리케이션 등에서 사용되는 런타임 환경으로, 전체 시스템 메모리에 접근할 수 있지만 격리된 프로세스 간에 메모리를 관리해야 하는 특징이 있습니다 [1, 2]. Chromium GPU 프로세스와 렌더러 프로세스가 분리되어 있어 GPU 메모리 누수나 OOM(Out of Memory) 오류가 발생하기 쉬운 구조적 위험성을 내포하고 있습니다 [3, 4].
-
-## 📖 구조화된 지식 (Synthesized Content)
-- **메모리 관리의 양날의 검**: 대규모 CAD 애플리케이션을 Electron에서 구동할 때, 전체 시스템 메모리에 접근할 수 있다는 장점이 있지만 프로세스가 격리되어 있어 메모리 관리에 세심한 주의가 필요합니다 [2]. 예를 들어 메인 스레드와 Web Worker 간에 'Structured Cloning' 방식으로 메시지를 전달할 경우, 데이터가 전체 복사되어 메모리 사용량이 두 배로 증가할 수 있으며 이로 인해 Electron의 OOM(Out of Memory) 킬러가 작동할 수 있습니다 [3].
-- **GPU 메모리 누수 취약성**: Electron 앱은 Chromium GPU 프로세스가 렌더러 프로세스와 완전히 분리되어 있기 때문에 GPU 메모리 누수로 악명이 높습니다 [4]. 3D 씬에서 객체를 삭제하더라도 단순히 씬 그래프에서 제거하는 것만으로는 연관된 GPU 버퍼가 자동으로 해제되지 않습니다 [4].
-- **최적화 및 안정성 확보 전략**: Electron 런타임 환경 내에서 메모리 안정성을 유지하기 위해서는 `SharedArrayBuffer`를 활용하여 데이터 복제 오버헤드 없이 다중 스레딩을 처리해야 합니다 [1, 3]. 더불어 메모리 누수를 막기 위해, 삭제 시 씬을 순회하며 모든 기하학적 구조와 재질에 대해 명시적으로 `.dispose()`를 호출하는 엄격한 리소스 폐기(Disposal) 패턴을 강제해야 합니다 [4].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[SharedArrayBuffer]], [[OOM (Out of Memory)]], [[Chromium GPU process]]
-- **Projects/Contexts:** [[Large-scale CAD applications]], [[WebGL/Three.js Rendering Optimization]]
-- **Contradictions/Notes:** 소스에 Electron 프레임워크 자체의 전반적인 동작 원리나 일반적인 데스크톱 앱 개발과 관련된 정보가 부족합니다. 제공된 문서는 대규모 3D/CAD 렌더링 최적화 환경에서의 메모리 관리 및 누수 문제에 국한하여 Electron을 설명하고 있습니다.
-
----
-*Last updated: 2026-04-19*
-- Raw Source: [[00_Raw/2026-04-20/Electron.md]]
----
diff --git a/Programming & Language/Emergent Gameplay Theory.md b/Programming & Language/Emergent Gameplay Theory.md
deleted file mode 100644
index 6ce545e5..00000000
--- a/Programming & Language/Emergent Gameplay Theory.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-7320C9
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Emergent Gameplay Theory"
----
-
-# [[Emergent Gameplay Theory]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Emergent Gameplay Theory.md]]
----
diff --git a/Programming & Language/Emergent Gameplay.md b/Programming & Language/Emergent Gameplay.md
deleted file mode 100644
index b2a644d7..00000000
--- a/Programming & Language/Emergent Gameplay.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-30AB3F
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Emergent Gameplay"
----
-
-# [[Emergent Gameplay]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Emergent Gameplay.md]]
----
diff --git a/Programming & Language/Emergent Systems.md b/Programming & Language/Emergent Systems.md
deleted file mode 100644
index 8c2087b3..00000000
--- a/Programming & Language/Emergent Systems.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-98C9F1
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Emergent Systems"
----
-
-# [[Emergent Systems]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Emergent Systems.md]]
----
diff --git a/Programming & Language/Emergent-Gameplay.md b/Programming & Language/Emergent-Gameplay.md
deleted file mode 100644
index d8e8bdf9..00000000
--- a/Programming & Language/Emergent-Gameplay.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-B15A5A
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Emergent-Gameplay"
----
-
-# [[Emergent-Gameplay]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Emergent-Gameplay.md]]
----
diff --git a/Programming & Language/Entity Component System (ECS).md b/Programming & Language/Entity Component System (ECS).md
deleted file mode 100644
index e28a40bc..00000000
--- a/Programming & Language/Entity Component System (ECS).md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-523650
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Entity Component System (ECS)"
----
-
-# [[Entity Component System (ECS)]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Entity Component System (ECS).md]]
----
diff --git a/Programming & Language/Epigenetics of Neuroplasticity.md b/Programming & Language/Epigenetics of Neuroplasticity.md
deleted file mode 100644
index a351948a..00000000
--- a/Programming & Language/Epigenetics of Neuroplasticity.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-0EB0EC
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Epigenetics of Neuroplasticity"
----
-
-# [[Epigenetics of Neuroplasticity]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Epigenetics of Neuroplasticity.md]]
----
diff --git a/Programming & Language/Escape Hatch (탈출구).md b/Programming & Language/Escape Hatch (탈출구).md
deleted file mode 100644
index 0f6db77d..00000000
--- a/Programming & Language/Escape Hatch (탈출구).md	
+++ /dev/null
@@ -1,32 +0,0 @@
----
-id: P-REINFORCE-AUTO-71F155
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Escape Hatch (탈출구)"
----
-
-# [[Escape Hatch (탈출구)]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> Escape Hatch(탈출구)는 SDK나 시스템 설계 시, 고수준의 추상화된 인터페이스(Facade)가 가지는 제약을 넘어 사용자가 세밀한 제어를 원할 때 활용할 수 있도록 제공하는 저수준(Low-level) API를 의미합니다 [1, 2]. 전체 사용 사례의 약 80%는 직관적인 고수준 인터페이스로 처리하고, 나머지 20%의 특수한 경우를 처리하기 위해 마련된 구조적 수단입니다 [1]. 이를 통해 편의성에만 안주하지 않고 세밀한 조작까지 가능한 설계적 균형을 유지할 수 있습니다 [2, 3].
-
-## 📖 구조화된 지식 (Synthesized Content)
-- **도입 목적 및 필요성:** SDK에 Facade 패턴을 적용해 복잡한 내부 로직을 숨기고 고수준의 인터페이스를 제공하면 사용자의 인지 부하를 줄일 수 있습니다 [4]. 그러나 추상화 수준이 높아질수록 특정 연결만 유지하거나 세부적인 제어가 필요한 특수 상황에서는 높은 추상화가 오히려 제약으로 다가올 수 있습니다 [1, 3]. 이러한 편의성의 단점을 보완하기 위해 언제든 저수준 인터페이스로 내려가 조작할 수 있도록 의도적으로 마련하는 것이 탈출구(Escape Hatch)입니다 [2].
-- **고수준과 저수준 인터페이스의 공존:** 좋은 SDK일수록 고수준과 저수준 인터페이스가 공존하도록 설계됩니다 [1]. 흔한 유즈케이스를 한 번에 끝내는 워크플로우(예: `start` 메서드)를 제공하는 동시에, 앱 브릿지(서버) 호출에 가까운 원자적인 저수준 호출(예: `open`, `send`, `listen`, `close` 등)을 탈출구로써 함께 제공해야 합니다 [1, 2].
-- **확장성 및 호환성 확보:** 저수준의 탈출구를 명확하게 제공하면, 편의성을 위해 고수준 메서드를 지속적으로 개선하더라도 저수준 메서드를 안정적으로 유지할 수 있어 하위 호환성 유지에 큰 도움이 됩니다 [2]. 이는 단기적인 개발자 경험(DX)을 개선할 뿐만 아니라, SDK의 장기적인 확장성과 호환성을 지켜주는 핵심적인 역할을 수행합니다 [1].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[Facade 패턴]], [[Low-level 인터페이스]], [[추상화(Abstraction)]]
-- **Projects/Contexts:** [[Toss Front SDK]], [[AWS CDK]]
-- **Contradictions/Notes:** 소스에 따르면 추상화 수준이 높아질수록 세밀한 제어가 어려워진다는 필연적인 트레이드오프가 존재하지만, 20%의 특수 케이스를 위한 탈출구(Escape Hatch)를 제공함으로써 편의성과 유연성 사이의 이상적인 균형을 잡을 수 있다고 강조합니다 [1-3].
-
----
-*Last updated: 2026-04-18*
-- Raw Source: [[00_Raw/2026-04-20/Escape Hatch (탈출구).md]]
----
diff --git a/Programming & Language/Excess Property Checking.md b/Programming & Language/Excess Property Checking.md
deleted file mode 100644
index 7a5291cd..00000000
--- a/Programming & Language/Excess Property Checking.md	
+++ /dev/null
@@ -1,37 +0,0 @@
----
-id: P-REINFORCE-AUTO-648FC3
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Excess Property Checking"
----
-
-# [[Excess Property Checking]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> TypeScript의 Excess Property Checking(과잉 속성 체크)은 객체 리터럴이 다른 변수에 할당되거나 함수의 인수로 전달될 때 예상치 못한 초과 속성을 감지하고 타입 에러를 표출하는 기능이다 [1-3]. 이는 TypeScript의 기본 동작인 구조적 타이핑(Structural Typing) 규칙을 더 엄격하게 적용하는 예외적인 사례로 볼 수 있다 [1]. 개발자가 속성 이름에 오타를 내는 등의 실수로 인해 발생할 수 있는 의도치 않은 런타임 오류를 방지하기 위해 존재한다 [4-6].
-
-## 📖 구조화된 지식 (Synthesized Content)
-* **동작 원리와 목적**
-  TypeScript의 타입 시스템은 기본적으로 객체가 요구되는 최소한의 속성만 가지고 있다면 호환성을 허용하는 구조적 타이핑(Structural Typing, 일명 덕 타이핑)을 따른다 [7-9]. 그러나 대상 타입에 직접 객체 리터럴을 할당하거나 함수의 인자로 객체 리터럴을 넘길 때는 특별히 Excess Property Checking이 발동하여 선언되지 않은 잉여 속성이 있는지 엄격하게 검사한다 [1, 3, 6, 10-12]. 이는 개발자가 초과 속성을 전달하려는 의도가 없을 것이라고 가정하여 오타(예: `color` 대신 `colour`) 등의 실수를 컴파일 시점에 포착하기 위함이다 [4-6, 9].
-
-* **한계점 및 우회 문제**
-  Excess Property Checking은 객체 리터럴을 중간 변수(intermediate variable)에 먼저 할당한 뒤 다른 변수나 인수로 전달할 경우에는 작동하지 않는다는 맹점이 있다 [1, 3, 4, 12, 13]. 중간 변수를 사용할 때 대상 타입과 최소 하나의 속성이라도 일치한다면, TypeScript는 초과 속성이 있더라도 에러를 발생시키지 않는다 [14]. (만약 공통 속성이 하나도 없다면 '약한 타입 검사(Weak Type Detection)' 규칙에 의해 에러가 발생한다 [3, 15]). 또한 명시적인 반환 타입 어노테이션이 없는 문맥적인 할당에서도 에러를 제대로 잡아내지 못하는 한계가 보고된 바 있다 [16]. 
-
-* **보완 전략 (`satisfies` 및 커스텀 타입)**
-  객체 리터럴을 중간 변수를 통해 전달하면서 발생하는 우회 문제를 극복하기 위해 TypeScript 4.9에서 도입된 `satisfies` 연산자를 활용할 수 있다 [17, 18]. `satisfies` 연산자는 객체의 구체적인 값 형태를 유지하면서도 대상 타입에 정의되지 않은 초과 속성을 엄격히 걸러내어 타입 안전성을 보장한다 [18-21]. 또한, 제네릭과 `never` 타입을 결합하여 대상 인터페이스와 실제 입력을 비교하고 잉여 속성을 잡아내는 재귀적 유틸리티 타입을 만들어 수동으로 초과 속성을 찾아낼 수도 있지만, 이는 타입 검사 성능에 부정적인 영향을 미칠 수 있어 주의해서 사용해야 한다 [22-24].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[Structural Typing]], [[satisfies Operator]], [[Weak Type Detection]]
-- **Projects/Contexts:** [[TypeScript Type System]], [[ESLint Rule Proposals (no-excess-properties)]]
-- **Contradictions/Notes:** 소스 [25]에 따르면, Facebook의 Flow처럼 초과 속성을 허용하지 않는 정확한 객체 타입(`Exact<T>`) 구문을 TypeScript에도 도입하자는 오랜 제안이 있었으나, TypeScript 팀은 Excess Property Checking 자체를 더 똑똑하게 개선하는 방향을 선호한다. 한편, ESLint의 린트 룰을 통해 초과 속성 검사를 강제하려는 시도에 대해서는, TypeScript의 모든 객체가 본질적으로 구조적 타이핑에 의해 "inexact"한 특성을 갖기 때문에 린트 룰 적용 시 노이즈(False Positive)가 과도하게 발생할 수 있다는 반론이 제기된다 [26, 27].
-
----
-*Last updated: 2026-04-18*
-- Raw Source: [[00_Raw/2026-04-20/Excess Property Checking.md]]
----
diff --git a/Programming & Language/Exergaming.md b/Programming & Language/Exergaming.md
deleted file mode 100644
index ffe1b56f..00000000
--- a/Programming & Language/Exergaming.md	
+++ /dev/null
@@ -1,33 +0,0 @@
----
-id: P-REINFORCE-AUTO-44E45F
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Exergaming"
----
-
-# [[Exergaming]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 엑서게이밍(Exergaming)은 운동(exercise)과 게임 플레이(gameplay)를 결합하여 사용자의 신체 활동을 촉진하는 방식입니다 [1]. 어린이, 청소년, 성인의 앉아 있는 습관(sedentary behaviors)을 개선하는 데 유효한 방법으로 인정받고 있으며, 달리기나 에어로빅 댄스 등과 유사한 수준의 생리학적 건강 이점을 제공합니다 [1]. 최근에는 가상현실(VR)과 결합하여 사용자가 운동의 육체적 피로를 잊고 게임에 더 깊이 몰입하게 하여 지속적인 신체 활동을 유도하는 'VR 엑서게이밍'이 각광받고 있습니다 [2].
-
-## 📖 구조화된 지식 (Synthesized Content)
-* **신체적 및 심리적 이점:** 엑서게이밍은 전통적인 신체 운동 형태보다 사용자에게 더 큰 즐거움과 긍정적인 감정을 제공합니다 [1]. 사용자는 게임의 목표와 도전 과제에 쉽게 빠져드는 '몰입(flow)' 상태를 경험하게 되며, 이는 운동에 대한 즐거움과 지속적인 참여(adherence)를 높이는 데 기여합니다 [1]. 
-* **VR 엑서게이밍의 부상:** 가상현실(VR) 기술은 엑서게이밍의 효과를 더욱 극대화합니다 [2]. 3D 환경, 360도 공간 및 신체 트래킹 기능을 통해 사용자는 육체적 피로감을 잊고 가상 세계의 몰입감(presence)을 강하게 느끼며 게임에 집중할 수 있습니다 [2]. 인기 있는 VR 엑서게임인 '비트 세이버(Beat Saber)'의 경우, 게임을 플레이하며 소비되는 에너지가 실제 테니스를 치는 것과 맞먹는 수준으로 평가됩니다 [3].
-* **잠재적 부작용 및 한계:** VR 엑서게이밍의 가장 큰 장애물 중 하나는 두부 장착형 디스플레이(HMD) 사용으로 인해 발생하는 VR 멀미(VR sickness)입니다 [4]. 사용자는 메스꺼움, 안구 운동 장애, 방향 감각 상실 등의 증상을 겪을 수 있으며, 이는 게임 내 성과와 즐거움을 저해하는 요인이 됩니다 [4, 5].
-* **안전 권고사항:** VR 엑서게이밍이 신체와 인지에 미치는 후유증을 조사한 연구에 따르면, 짧거나 긴 시간 동안 HMD를 착용하고 엑서게임을 즐긴 후에는 사용자의 웰빙을 위해 대기 시간이 필요합니다 [6]. 사용자가 가상현실에서 벗어난 뒤, 후유증이 완전히 사라질 때까지(예: 약 40분) 운전과 같이 부상 위험이 있는 활동을 피하는 것이 권장됩니다 [6].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[Virtual Reality (VR)]], [[Flow]], [[VR Sickness]]
-- **Projects/Contexts:** [[Beat Saber]]
-- **Contradictions/Notes:** VR 기술은 사용자의 몰입도(presence)를 극대화하여 엑서게임의 동기를 부여하고 신체적 피로를 잊게 하는 긍정적인 역할을 하지만, 동시에 VR 멀미(motion sickness)를 유발하여 오히려 사용자의 게임 플레이 성과와 체감하는 즐거움을 떨어뜨릴 수 있는 양면성을 지니고 있습니다 [2, 4].
-
----
-*Last updated: 2026-04-19*
-- Raw Source: [[00_Raw/2026-04-20/Exergaming.md]]
----
diff --git a/Programming & Language/Facade Pattern (퍼사드 패턴).md b/Programming & Language/Facade Pattern (퍼사드 패턴).md
deleted file mode 100644
index addd4d8c..00000000
--- a/Programming & Language/Facade Pattern (퍼사드 패턴).md	
+++ /dev/null
@@ -1,40 +0,0 @@
----
-id: P-REINFORCE-AUTO-7C58EE
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Facade Pattern (퍼사드 패턴)"
----
-
-# [[Facade Pattern (퍼사드 패턴)]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 퍼사드 패턴(Facade Pattern)은 복잡한 내부 서브시스템을 단순한 인터페이스로 감싸서 사용자에게 제공하는 설계 패턴이다 [1]. 이 패턴의 진정한 본질은 단순히 기능을 숨기는 것을 넘어, 복잡한 내부 구현을 사용자의 '의도(Intent)'를 기준으로 재구성하는 데 있다 [1]. 결과적으로 개발자의 인지 부하를 줄이고 시스템 간의 결합도를 낮추어 안정적이고 유지보수하기 쉬운 구조를 만드는 핵심 아키텍처 전략으로 활용된다 [2, 3].
-
-## 📖 구조화된 지식 (Synthesized Content)
-- **퍼사드 패턴의 본질과 목적**
-  퍼사드 패턴은 시스템 내부에 존재하는 인증, 실패 시 재시도 로직, 상태 관리, 클린업(Cleanup) 로직 등 복잡한 오케스트레이션 요소들을 은닉한다 [1]. 사용자는 이러한 복잡한 내부 절차나 책임을 알 필요 없이 "서버를 시작한다", "파일을 업로드한다"와 같이 자연스러운 목적과 의도만을 표현하여 시스템을 조작할 수 있다 [1]. 이는 인지 부하를 크게 줄이고 코드 결합도를 낮추는 데 목적이 있다 [2].
-
-- **고수준과 저수준 인터페이스의 공존 (탈출구, Escape Hatch)**
-  단순히 고수준(High-level) API만 제공하는 것은 완벽한 퍼사드 설계가 아니다 [2]. 파레토 법칙에 기반하여, 전체 사용 사례의 80%를 차지하는 흔하고 반복적인 워크플로우는 고수준의 퍼사드 인터페이스로 간단하게 끝낼 수 있도록 제공한다 [2, 4]. 하지만 세밀한 제어가 필요한 나머지 20%의 특수한 경우를 위해 저수준(Low-level) 인터페이스를 '탈출구(Escape Hatch)' 형태로 반드시 남겨두어야 한다 [2, 4]. 이를 통해 설계의 균형을 맞추고 장기적인 호환성과 확장성을 지킬 수 있다 [4].
-
-- **도입 시의 트레이드오프(Trade-off)**
-  추상화 수준이 높아지면 사용자는 편리함을 얻지만, 의도적으로 세밀한 제어가 방지되기 때문에 특수한 요구사항을 처리할 때 제약이 발생할 수 있다 [4, 5]. 또한 기능을 제공하는 플랫폼(예: SDK) 내부에서는 복잡한 로직을 정교하게 관리해야 하므로, 개발자가 떠안게 되는 시스템 내부의 유지보수 비용과 복잡도는 증가하게 된다 [4]. 
-
-- **실제 활용 사례**
-  대표적으로 AWS CDK(Cloud Development Kit)의 L2 구문이 퍼사드 개념을 잘 보여주는 예시이다 [1]. 직관적인 '의도 기반 API'로써 상위 추상화를 제공하여 사용자가 속성, 권한 등을 더 빠르고 간단히 정의하게 돕는다 [1]. 토스(Toss) Front SDK 역시 단일 책임 원칙(SRP)과 퍼사드 패턴을 적용해 개발자의 실수를 구조적으로 방지하고 시스템 간 결합도를 낮추는 설계를 채택했다 [3, 6].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[단일 책임 원칙(SRP)]], [[인터페이스 분리 원칙(ISP)]]
-- **Projects/Contexts:** [[Toss Front SDK]], [[AWS CDK]]
-- **Contradictions/Notes:** 퍼사드 패턴은 사용자에게 높은 편의성을 제공하지만 필연적으로 세밀한 제어에 제약을 초래한다 [4]. 따라서 퍼사드의 편리함에만 안주하지 않고, 필요 시 세밀한 조작이 가능한 저수준 API(Escape Hatch)를 동시에 제공해 설계적 균형을 잡아야 한다고 소스들은 강조한다 [4, 5].
-
----
-*Last updated: 2026-04-18*
-- Raw Source: [[00_Raw/2026-04-20/Facade Pattern (퍼사드 패턴).md]]
----
diff --git a/Programming & Language/Feature Ablation (피처 제거).md b/Programming & Language/Feature Ablation (피처 제거).md
deleted file mode 100644
index 1512c707..00000000
--- a/Programming & Language/Feature Ablation (피처 제거).md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-41CA87
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Feature Ablation (피처 제거)"
----
-
-# [[Feature Ablation (피처 제거)]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Feature Ablation (피처 제거).md]]
----
diff --git a/Programming & Language/Federated SPARQL (연합 질의).md b/Programming & Language/Federated SPARQL (연합 질의).md
deleted file mode 100644
index 69575f41..00000000
--- a/Programming & Language/Federated SPARQL (연합 질의).md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-04F8F3
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Federated SPARQL (연합 질의)"
----
-
-# [[Federated SPARQL (연합 질의)]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Federated SPARQL (연합 질의).md]]
----
diff --git a/Programming & Language/Figma.md b/Programming & Language/Figma.md
deleted file mode 100644
index 0dab85d9..00000000
--- a/Programming & Language/Figma.md	
+++ /dev/null
@@ -1,34 +0,0 @@
----
-id: P-REINFORCE-AUTO-524A98
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Figma"
----
-
-# [[Figma]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> Figma는 다수의 페이지, 대용량 이미지 및 복잡한 컴포넌트를 사용하여 디자인 및 프로토타이핑을 수행하는 디자인 툴입니다 [1, 2]. 대규모 디자인 파일에서는 스크롤 및 편집 시 지연(Lag) 현상이 발생하거나 프로토타이핑 중 마이크로 지연(Micro-latency)이 발생할 수 있으며, 원활한 사용을 위해 메모리 및 컴포넌트 구조 최적화가 중요하게 요구됩니다 [1, 2].
-
-## 📖 구조화된 지식 (Synthesized Content)
-- **성능 저하의 주요 원인**: 복잡한 컴포넌트와 다수의 페이지가 포함된 프로젝트는 스크롤과 편집 시 래그(Lag)를 유발합니다 [2]. 특히 프로토타입 기능 중 "Smart Animate"는 매 프레임마다 수천 개의 레이어에 대한 복잡한 보간(interpolation)과 레이아웃 계산을 수행해야 하므로, 대형 파일에서는 심각한 성능 저하를 일으키는 원인으로 지목됩니다 [1].
-- **메모리 및 문제 진단**: Figma는 성능 문제를 겪는 페이지를 식별할 수 있도록 "Memory Usage(메모리 사용량)" 도구와 "Show memory usage in layers panel(레이어 패널에 메모리 사용량 표시)" 옵션을 제공합니다 [1]. 
-- **레이어 및 구조적 컴포넌트 최적화**: 레이어 수, 그중에서도 특히 인스턴스 내의 '숨겨진 레이어(hidden layers)'를 줄이는 것이 성능 향상의 핵심입니다 [1, 3, 4]. 구조적 컴포넌트(structure components)는 종종 여러 컴포넌트에 숨겨진 레이어를 대량으로 추가하여 성능을 악화시킵니다 [5]. 상호작용에 필수적인 요소만 남기고 구조적 컴포넌트와 불필요한 숨겨진 레이어를 제거하면 프로토타입의 성능이 눈에 띄게 부드러워집니다 [6, 7].
-- **베리언트(Variants) 관리**: 포함된 베리언트의 수는 컴포넌트의 업데이트 속도에 직접적인 영향을 미칩니다 [4]. 250여 개의 베리언트를 가진 아이콘 컴포넌트를 여러 개의 개별 컴포넌트로 분리하고 내부의 숨겨진 레이어를 제거한 결과, 업데이트 속도와 전반적인 성능이 대폭 향상된 사례가 있습니다 [7].
-- **프로토타이핑 권장 사항**: 성능이 매우 중요한 프로토타입의 경우 "Smart Animate"를 사용하는 대신 단순한 화면 전환(simple transitions)이나 베리언트를 활용하는 것이 마이크로 지연을 줄이고 더 부드러운 상호작용을 보장하는 방법입니다 [1].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[Smart Animate]], [[Hidden Layers]], [[Variants]]
-- **Projects/Contexts:** [[Figma Performance Optimization]]
-- **Contradictions/Notes:** 베리언트의 수를 최소화하기 위해 중첩된 구조적 컴포넌트(nested structure components)를 사용하는 것은 직관과 달리 성능에 최악의 영향을 미칠 수 있습니다 [8]. 소스에 따르면, 구조적 컴포넌트로 인해 발생하는 숨겨진 레이어를 제거하고 대신 베리언트의 수를 늘리거나 개별 컴포넌트로 쪼개는 것이 오히려 성능 향상에 훨씬 유리합니다 [6, 7].
-
----
-*Last updated: 2026-04-19*
-- Raw Source: [[00_Raw/2026-04-20/Figma.md]]
----
diff --git a/Programming & Language/Finite-State-Machines-in-TypeScript.md b/Programming & Language/Finite-State-Machines-in-TypeScript.md
deleted file mode 100644
index 6ce2228b..00000000
--- a/Programming & Language/Finite-State-Machines-in-TypeScript.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-A0FC70
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Finite-State-Machines-in-TypeScript"
----
-
-# [[Finite-State-Machines-in-TypeScript]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Finite-State-Machines-in-TypeScript.md]]
----
diff --git a/Programming & Language/Flame Chart.md b/Programming & Language/Flame Chart.md
deleted file mode 100644
index ea7095f5..00000000
--- a/Programming & Language/Flame Chart.md	
+++ /dev/null
@@ -1,32 +0,0 @@
----
-id: P-REINFORCE-AUTO-41DF27
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Flame Chart"
----
-
-# [[Flame Chart]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 플레임 차트(Flame Chart)는 Chrome DevTools의 Performance 패널에서 메인 스레드의 활동을 시간에 따라 시각적으로 보여주는 도구입니다 [1, 2]. X축은 기록된 시간을 나타내며 막대가 넓을수록 이벤트 실행에 긴 시간이 소요되었음을 의미하고, Y축은 콜 스택(Call stack)을 나타냅니다 [1, 2]. 이를 통해 개발자는 성능 병목 현상을 파악하고 자바스크립트 함수 호출의 인과 관계 및 장기 실행 작업(Long tasks)을 분석할 수 있습니다 [1-3].
-
-## 📖 구조화된 지식 (Synthesized Content)
-- **차트의 구조:** 플레임 차트에서 상단에 위치한 이벤트는 하단에 있는 이벤트를 발생시킨 원인(호출자)을 의미합니다 [1, 2]. 브라우저가 작업을 수행하도록 원인을 제공하는 '루트 활동(Root activities)'은 플레임 차트의 가장 맨 위에 표시됩니다 [4].
-- **시각적 구분:** 차트의 가독성을 높이기 위해 스크립트마다 무작위로 색상이 지정됩니다 [2]. 일반적으로 어두운 노란색은 스크립팅 활동을, 보라색은 렌더링 활동을 나타냅니다 [2]. 특히 작업 시간이 긴 작업(Long tasks)은 빨간색 삼각형으로 강조 표시되며, 50밀리초를 넘긴 구간은 차트에서 빨간색으로 음영 처리되어 성능 저하의 원인을 직관적으로 식별할 수 있습니다 [1, 3].
-- **차트 제어 및 디버깅:** 사용자는 플레임 차트를 깔끔하게 정리하기 위해 특정 함수나 그 하위 항목을 숨길 수 있으며, 관련 없는 스크립트를 무시 목록(Ignore list)에 추가하여 차트에서 제외할 수 있습니다 [5-7]. 또한 자바스크립트 샘플링(JavaScript samples)을 비활성화하면 상세한 자바스크립트 콜 스택 정보가 생략되고, 대신 `Event (click)`나 `Function Call`과 같은 상위 수준의 이벤트만 플레임 차트에 짧게 표시됩니다 [3, 8].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[Chrome DevTools]], [[Call Stack]], [[Main Thread]], [[Long Tasks]]
-- **Projects/Contexts:** [[Performance Panel]], [[Analyze runtime performance]]
-- **Contradictions/Notes:** 소스 내에서 플레임 차트의 기능이나 정의와 관련하여 상충되는 정보는 없습니다.
-
----
-*Last updated: 2026-04-19*
-- Raw Source: [[00_Raw/2026-04-20/Flame Chart.md]]
----
diff --git a/Programming & Language/Flow Theory.md b/Programming & Language/Flow Theory.md
deleted file mode 100644
index f4137dc0..00000000
--- a/Programming & Language/Flow Theory.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-B216EA
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Flow Theory"
----
-
-# [[Flow Theory]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Flow Theory.md]]
----
diff --git a/Programming & Language/Flow-Theory.md b/Programming & Language/Flow-Theory.md
deleted file mode 100644
index 584a2615..00000000
--- a/Programming & Language/Flow-Theory.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-7C8E03
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Flow-Theory"
----
-
-# [[Flow-Theory]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Flow-Theory.md]]
----
diff --git a/Programming & Language/Fractal-Geometry.md b/Programming & Language/Fractal-Geometry.md
deleted file mode 100644
index a764e683..00000000
--- a/Programming & Language/Fractal-Geometry.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-FCAC5E
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Fractal-Geometry"
----
-
-# [[Fractal-Geometry]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Fractal-Geometry.md]]
----
diff --git a/Programming & Language/Function-Overloading.md b/Programming & Language/Function-Overloading.md
deleted file mode 100644
index e2f632e6..00000000
--- a/Programming & Language/Function-Overloading.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-9ABCD8
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Function-Overloading"
----
-
-# [[Function-Overloading]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Function-Overloading.md]]
----
diff --git a/Programming & Language/Function-Signature-Compatibility.md b/Programming & Language/Function-Signature-Compatibility.md
deleted file mode 100644
index 35ef4ed8..00000000
--- a/Programming & Language/Function-Signature-Compatibility.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-D7BC47
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Function-Signature-Compatibility"
----
-
-# [[Function-Signature-Compatibility]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Function-Signature-Compatibility.md]]
----
diff --git a/Programming & Language/Fuzzing.md b/Programming & Language/Fuzzing.md
deleted file mode 100644
index 28661593..00000000
--- a/Programming & Language/Fuzzing.md	
+++ /dev/null
@@ -1,33 +0,0 @@
----
-id: P-REINFORCE-AUTO-CE0886
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Fuzzing"
----
-
-# [[Fuzzing]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 퍼징(Fuzzing)은 애플리케이션에 스트레스를 가해 예상치 못한 동작, 프로그램 충돌(크래시) 또는 리소스 누수를 유발함으로써 소프트웨어의 취약점을 찾아내는 동적 애플리케이션 보안 테스트(DAST) 기법입니다 [1]. 소스에 관련 정보가 부족합니다.
-
-## 📖 구조화된 지식 (Synthesized Content)
-- **DAST의 일환:** 퍼징은 실행 중인 애플리케이션을 테스트하는 동적 애플리케이션 보안 테스트(DAST) 방법 중 하나로 분류됩니다 [1].
-- **스트레스 테스트:** 애플리케이션에 의도적으로 스트레스를 주어 예상치 못한 동작이나 시스템 크래시, 그리고 리소스 누수(resource leaks) 등을 유발하도록 작동합니다 [1].
-- **취약점 이해 도모:** 이러한 과정을 통해 개발자는 애플리케이션의 런타임 동작 방식과 내재된 취약점들을 보다 포괄적이고 종합적으로 이해할 수 있게 됩니다 [1].
-- 소스에 관련 정보가 부족합니다.
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[DAST]], [[Vulnerabilities]]
-- **Projects/Contexts:** 애플리케이션의 동작 및 취약점을 포괄적으로 이해하기 위한 소프트웨어 보안 테스트 컨텍스트에서 활용됩니다 [1].
-- **Contradictions/Notes:** 소스에 관련 정보가 부족합니다.
-
----
-*Last updated: 2026-04-18*
-- Raw Source: [[00_Raw/2026-04-20/Fuzzing.md]]
----
diff --git a/Programming & Language/GC Root.md b/Programming & Language/GC Root.md
deleted file mode 100644
index 078c2eb7..00000000
--- a/Programming & Language/GC Root.md	
+++ /dev/null
@@ -1,32 +0,0 @@
----
-id: P-REINFORCE-AUTO-31335C
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - GC Root"
----
-
-# [[GC Root]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> GC Root(가비지 컬렉션 루트)는 가비지 컬렉터가 메모리 내에서 사용 중인 살아있는(live) 객체를 식별하기 위해 참조 추적을 시작하는 기준점 역할을 하는 객체입니다 [1-3]. 힙(heap) 외부에서 접근할 수 있는 객체로서 기본적으로 살아있는 것으로 정의되며, 힙 내부의 다른 객체들이 메모리 회수 대상에서 제외되려면 반드시 이 루트 객체로부터 시작되는 포인터 체인을 통해 도달 가능(reachable)하게 연결되어 있어야 합니다 [1, 2, 4].
-
-## 📖 구조화된 지식 (Synthesized Content)
-- **GC 루트의 정의와 주요 종류:** GC 루트는 V8 자바스크립트 엔진이나 웹 브라우저, 자바 가상 머신(VM) 외부에서 직접 가리키는 객체들을 의미합니다 [1]. 주요 종류로는 호출 스택(stack)에 존재하는 로컬 변수, 항상 접근이 가능한 전역 객체(Global objects), 클래스 정적 필드(class static field), JNI 참조, 그리고 브라우저의 DOM 요소 등이 있습니다 [1, 2]. 웹 브라우저 환경의 메모리 누수와 관련하여 창(window), 활성 클로저(active closures), 이벤트 리스너, 타이머 등도 루트 역할을 하여 연관된 객체들이 메모리에서 해제되는 것을 방지합니다 [5].
-- **마킹 및 추적 과정(Marking and Tracing):** Mark-Sweep 알고리즘 등에서 살아있는 객체를 찾는 과정은 루트 세트(root set)에서 출발합니다 [3]. 가비지 컬렉터의 초기 단계에서 루트 스캔을 실행하여 모든 루트 객체를 식별하고, 이를 처리를 위한 작업 스택(work stack)에 푸시합니다 [2]. 그런 다음 GC는 루트 객체에서 시작해 다른 객체를 가리키는 모든 포인터를 재귀적으로 추적하여 도달 가능한 객체들을 마킹(Mark)합니다 [2, 3]. 루트로부터 도달할 수 없는 나머지 모든 것들은 가비지로 간주됩니다 [4, 6].
-- **마이너 GC를 위한 특수 루트(V8 Scavenger):** V8 엔진의 젊은 세대(young generation)를 수집하는 마이너 GC(Scavenger)의 경우, GC가 실행될 때마다 전체 구세대(old generation) 힙을 모두 스캔하는 비효율을 피하기 위해 쓰기 장벽(write barriers)을 활용합니다 [7]. 이를 통해 구세대에서 젊은 세대로 향하는 참조(old-to-new references) 목록을 유지하며, 이를 스택 및 전역 변수 등과 결합하여 젊은 세대 가비지 컬렉션을 위한 추가적인 루트 세트로 사용합니다 [7].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[Garbage Collection]], [[Mark-Sweep Algorithm]], [[Memory Leak]], [[Reachability]]
-- **Projects/Contexts:** [[V8 Engine]], [[IBM SDK Java Technology]]
-- **Contradictions/Notes:** 소스에 따르면 V8 엔진(JavaScript)과 IBM Java 구현 모두 GC 루트를 통한 참조 추적이라는 핵심 원리를 공유하고 있습니다. 다만 실행 환경의 차이에 따라 V8은 DOM 요소나 클로저 등을 주로 다루고 [1, 5], Java는 JNI 참조나 클래스 정적 필드 등을 다룬다는 세부적인 특성의 차이를 보입니다 [2].
-
----
-*Last updated: 2026-04-19*
-- Raw Source: [[00_Raw/2026-04-20/GC Root.md]]
----
diff --git a/Programming & Language/GQL (Graph Query Language ISO 표준).md b/Programming & Language/GQL (Graph Query Language ISO 표준).md
deleted file mode 100644
index 46140775..00000000
--- a/Programming & Language/GQL (Graph Query Language ISO 표준).md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-F13C1F
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - GQL (Graph Query Language ISO 표준)"
----
-
-# [[GQL (Graph Query Language ISO 표준)]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/GQL (Graph Query Language, ISO 표준).md]]
----
diff --git a/Programming & Language/Game Studies (Digital Media Theory).md b/Programming & Language/Game Studies (Digital Media Theory).md
deleted file mode 100644
index 6dacef14..00000000
--- a/Programming & Language/Game Studies (Digital Media Theory).md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-46EF56
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Game Studies (Digital Media Theory)"
----
-
-# [[Game Studies (Digital Media Theory)]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Game Studies (Digital Media Theory).md]]
----
diff --git a/Programming & Language/Game Studies (Ludology vs Narratology).md b/Programming & Language/Game Studies (Ludology vs Narratology).md
deleted file mode 100644
index 0a5c0681..00000000
--- a/Programming & Language/Game Studies (Ludology vs Narratology).md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-A1A637
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Game Studies (Ludology vs Narratology)"
----
-
-# [[Game Studies (Ludology vs Narratology)]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Game Studies (Ludology vs. Narratology).md]]
----
diff --git a/Programming & Language/Game Studies.md b/Programming & Language/Game Studies.md
deleted file mode 100644
index f1bc9457..00000000
--- a/Programming & Language/Game Studies.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-21CD99
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Game Studies"
----
-
-# [[Game Studies]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Game Studies.md]]
----
diff --git a/Programming & Language/Garbage Collection (GC) 최적화.md b/Programming & Language/Garbage Collection (GC) 최적화.md
deleted file mode 100644
index 817641f4..00000000
--- a/Programming & Language/Garbage Collection (GC) 최적화.md	
+++ /dev/null
@@ -1,33 +0,0 @@
----
-id: P-REINFORCE-AUTO-6C336D
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Garbage Collection (GC) 최적화"
----
-
-# [[Garbage Collection (GC) 최적화]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-**1. GC 스파이크와 프레임 드랍(Stop-the-world) 원인** 자바스크립트 엔진의 가비지 컬렉터(GC)는 자동 메모리 관리를 제공하지만, 실시간 상호작용이 필요한 게임이나 고성능 렌더링 환경에서는 불규칙한 'Stop-the-world(일시 정지)' 현상을 유발하는 주범이 됩니다. 짧은 시간 안에 수많은 객체를 무분별하게 생성하고 삭제하면, 힙 메모리가 파편화되고 가비지 컬렉터가 메모리를 정리하느라 시스템 자원을 소모하게 되어 화면이 뚝뚝 끊기는 지연(Lag)이나 프리징 현상이 발생합니다.
-
-**2. 렌더링 루프(Render Loop) 내부의 객체 생성 금지** 애니메이션을 제어하는 `requestAnimationFrame`이나 React Three Fiber의 `useFrame` 같은 핵심 게임 루프 내부에서 새로운 객체(예: `new Vector3()`)를 반복적으로 생성하면 끊임없는 가비지 컬렉션이 트리거됩니다. 이를 방지하려면 루프 외부에서 미리 객체를 할당해 두거나(`useMemo` 등 활용), 객체의 속성값만 덮어씌워 갱신(Direct mutation)하는 방식으로 재사용해야 합니다.
-
-**3. 오브젝트 풀링(Object Pooling)의 적극 도입** 탄환, 파티클, 적 캐릭터 등 생성과 파괴가 매우 빈번한 객체는 **오브젝트 풀(Object Pool)**이라는 고정된 크기의 배열을 만들어 최적화합니다. 로딩 시점에 필요한 객체를 미리 생성해 두고, 게임 중에는 삭제(Free)하지 않은 채 활성/비활성 상태만 변경하여 돌려 사용합니다. 이 방식을 사용하면 런타임 중의 메모리 할당 및 해제 횟수가 '0'에 가까워져 GC로 인한 성능 저하를 극적으로 막을 수 있습니다.
-
-**4. 세대별 GC(Generational GC) 특성을 고려한 주의사항** 최신 브라우저(V8 엔진 등)는 **세대별 가비지 컬렉션(Generational GC)**을 사용하므로, 생성 후 금방 버려지는 단기 생존 객체(Short-lived garbage)는 사실상 거의 비용 없이 회수됩니다. 따라서 무분별하게 모든 객체를 풀링할 경우, 오히려 객체들이 메모리에 계속 상주하는 '장기 생존 객체'로 취급되어 구세대(Old generation) 메모리를 압박하고 GC 성능을 악화시킬 수 있습니다. 오브젝트 풀링은 반드시 프로파일링을 통해 객체 생성 비용이 진짜 병목으로 판명된 경우에만 선별적으로 도입해야 합니다.
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[Object Pooling (오브젝트 풀링)]], [[Memory Leak Prevention (메모리 누수 방지)]], [[Generational GC (세대별 가비지 컬렉션)]], [[React Three Fiber (R3F) 자산 최적화]]
-- **Projects/Contexts:** [[수만 개의 엔티티가 존재하는 실시간 물리 시뮬레이션]], [[대규모 파티클 시스템 최적화]]
-- **Contradictions/Notes:** 가비지 컬렉션의 멈춤 현상을 극도로 피해야 하는 환경(예: AAA급 웹 게임)에서는 ECS(엔티티 컴포넌트 시스템)와 같이 자바스크립트 기본 객체가 아닌, 연속된 `TypedArray` 형태의 메모리 버퍼(SoA)를 직접 다루는 데이터 지향 설계(Data-Oriented Design)를 통해 GC 자체를 원천 우회하는 설계가 활용되기도 합니다.
-- Raw Source: [[00_Raw/2026-04-20/Garbage Collection (GC) 최적화.md]]
----
diff --git a/Programming & Language/Garbage Collection (GC).md b/Programming & Language/Garbage Collection (GC).md
deleted file mode 100644
index fe7dad02..00000000
--- a/Programming & Language/Garbage Collection (GC).md	
+++ /dev/null
@@ -1,30 +0,0 @@
----
-id: P-REINFORCE-AUTO-99978B
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Garbage Collection (GC)"
----
-
-# [[Garbage Collection (GC)]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 가비지 컬렉션(GC)은 프로그램에서 더 이상 사용되지 않는 객체(가비지)를 식별하고 그들이 차지하던 메모리를 자동으로 회수하여 재사용할 수 있도록 하는 메모리 관리 프로세스입니다 [1, 2]. 이 방식은 개발자가 명시적으로 메모리를 관리할 필요성을 줄여 애플리케이션의 메모리 누수와 오류를 방지하는 이점이 있습니다 [3]. 하지만 GC가 실행되는 동안에는 프로그램 실행이 멈추는 'Stop-the-world' 현상이 발생할 수 있으므로, 응답성과 성능을 유지하기 위해 엔진 수준에서 다양한 최적화 기법이 함께 적용됩니다 [2, 4].
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[Mark-Sweep-Compact]], [[Scavenger (Minor GC)]], [[Generational GC]], [[Orinoco]]
-- **Projects/Contexts:** [[V8 JavaScript Engine]], [[Eclipse OpenJ9 VM]], [[Node.js Memory Management]]
-- **Contradictions/Notes:** 가비지 컬렉션은 개발자에게서 메모리 관리의 부담을 없애주는 매우 강력한 기능이지만 제어 권한을 완전히 잃게 된다는 양날의 검과 같은 특성을 가집니다 [3, 4]. 관리되지 않는(Unmanaged) 언어와 비교해 무조건적으로 성능이 더 좋거나 나쁜 것은 아니며, 적절히 최적화되지 않은 GC 시스템은 길고 예측 불가능한 멈춤 현상을 발생시킬 수 있습니다 [4].
-
----
-*Last updated: 2026-04-19*
-- Raw Source: [[00_Raw/2026-04-20/Garbage Collection (GC).md]]
----
diff --git a/Programming & Language/Garbage Collection(가비지 컬렉션).md b/Programming & Language/Garbage Collection(가비지 컬렉션).md
deleted file mode 100644
index 882f2717..00000000
--- a/Programming & Language/Garbage Collection(가비지 컬렉션).md	
+++ /dev/null
@@ -1,51 +0,0 @@
----
-id: P-REINFORCE-AUTO-CA2F39
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Garbage Collection(가비지 컬렉션)"
----
-
-# [[Garbage Collection(가비지 컬렉션)]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 가비지 컬렉션(Garbage Collection)은 애플리케이션의 메모리 고갈을 방지하기 위해 더 이상 필요하지 않거나 도달할 수 없는 객체가 차지한 메모리를 자동으로 식별하여 회수하는 프로세스입니다 [1-3]. 이 기술은 프로그래머가 직접 메모리를 관리하는 부담을 덜어주고 메모리 누수와 같은 오류를 줄여주지만, 메모리 정리 작업 중 애플리케이션 실행이 멈추는 'Stop-the-world' 지연을 발생시킬 수 있습니다 [2, 4, 5]. 현대의 가비지 컬렉터들은 이러한 지연 시간을 최소화하기 위해 세대별 힙 구조(Generational Layout)와 병렬 및 동시 처리 알고리즘을 도입하여 성능을 최적화하고 있습니다 [6-8].
-
-## 📖 구조화된 지식 (Synthesized Content)
-- **생존 객체 식별 원리 (Discovering Reachability)**
-  가비지 컬렉터가 해결해야 할 핵심 문제는 죽은 메모리 영역을 식별하는 것입니다 [1]. 객체의 미래 접근 여부를 완벽히 예측하는 것은 정지 문제(Halting Problem)와 같아 불가능하므로, GC는 스택의 로컬 변수나 글로벌 객체와 같은 '루트(Root) 객체'부터 시작하여 포인터 체인을 통해 도달할 수 있는 객체만을 '생존(Live)' 상태로 근사하여 판단하고, 도달 불가능한 모든 객체를 '가비지(Garbage)'로 간주합니다 [1, 9, 10].
-
-- **세대별 가설과 힙 메모리 구조 (Generational Collection & Heap Organization)**
-  대부분의 객체는 생성 후 얼마 지나지 않아 죽는다는 '세대별 가설(Generational Hypothesis)'을 기반으로, V8과 같은 엔진은 힙 메모리를 세대별로 나누어 관리합니다 [6, 11, 12].
-  *   **New Space (Young Generation):** 대부분의 새 객체가 할당되는 작고 빠른 공간입니다 [6, 13]. 주기적으로 마이너 가비지 컬렉션이 빠르게 수행됩니다 [6].
-  *   **Old Space (Old Generation):** New Space에서 수행된 가비지 컬렉션을 두 번 살아남은 객체들이 승격(Promotion)되어 이동하는 공간입니다 [6, 14, 15]. 
-
-- **마이너 가비지 컬렉션 (Scavenger)**
-  Young Generation을 관리하는 고속 알고리즘입니다 [16, 17]. New Space를 'To-Space'와 'From-Space'라는 동일한 크기의 두 반공간(Semi-space)으로 분할하는 Cheney의 알고리즘(Scavenge)을 사용합니다 [16, 18]. 할당 공간이 가득 차면, 활성 객체를 추적하여 빈 공간(To-Space)이나 Old Space로 대피(Evacuate)시키면서 메모리를 압축합니다 [18, 19]. 이후 남은 From-Space의 쓰레기 데이터를 한 번에 비우고 두 공간의 역할을 바꿉니다 [18, 19].
-
-- **메이저 가비지 컬렉션 (Mark-Sweep-Compact)**
-  수백 메가바이트의 데이터를 포함할 수 있는 Old Space를 관리하기 위해 메이저 GC는 주로 세 가지 단계를 거칩니다 [20, 21].
-  *   **Marking (표시):** 깊이 우선 탐색(DFS)을 통해 힙 내의 활성 객체를 발견합니다 [22]. 객체를 흰색(미발견), 회색(발견되었으나 이웃 객체 미처리), 검은색(발견 및 이웃 처리 완료)의 3색 마킹 상태로 분류하여 추적합니다 [23, 24].
-  *   **Sweeping (쓸기):** 마킹되지 않은 죽은 객체의 연속된 메모리 범위를 스캔하여 Free list(여유 공간)로 변환하여 후속 할당에 대비합니다 [24-26].
-  *   **Compacting (압축):** 메모리 단편화(Fragmentation)를 줄이기 위해 생존 객체들을 빈 공간으로 마이그레이션합니다 [24, 27, 28]. 이는 비용이 많이 드는 작업이지만 실제 메모리 사용량을 대폭 줄여줍니다 [27, 29].
-
-- **현대 GC의 성능 최적화 (Orinoco 등)**
-  수백 밀리초에 달하던 과거의 'Stop-the-world' 일시 정지 현상을 줄이기 위해 현대적인 GC는 다양한 기법을 동원합니다 [30, 31].
-  *   **Parallel (병렬 처리):** 메인 스레드와 여러 보조 스레드가 GC 작업을 동시에 분담하여 총 정지 시간을 줄입니다 [32, 33].
-  *   **Incremental (점진적 처리):** 자바스크립트 실행 중간중간에 작은 단위로 GC 작업을 번갈아 수행(Interleaving)하여 응답성을 유지합니다 [30, 32, 34].
-  *   **Concurrent (동시 처리):** 메인 스레드가 자바스크립트를 계속 실행하는 동안 보조 스레드들이 백그라운드에서 전적으로 Marking 및 Sweeping 작업을 수행합니다 [7, 32, 35].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[Mark-Sweep]], [[Scavenger]], [[Stop-the-world]], [[Generational Hypothesis]], [[Memory Leak]]
-- **Projects/Contexts:** [[V8 JavaScript Engine]], [[IBM Eclipse OpenJ9]], [[Orinoco Garbage Collector]]
-- **Contradictions/Notes:** 가비지 컬렉션은 메모리 누수를 대폭 줄여주지만, 프로그래머가 메모리 관리에 대한 전적인 통제권을 잃는다는 단점이 존재합니다(모바일 앱 등에서는 큰 문제점) [4, 5]. 또한 대안으로 거론되는 레퍼런스 카운팅(Reference Counting) 방식 역시 대규모 객체 그래프의 마지막 참조가 제거될 때 가비지 컬렉션과 유사한 예측 불가능한 정지 현상을 유발할 수 있어 완벽한 대체재는 아닙니다 [5].
-
----
-*Last updated: 2026-04-19*
-- Raw Source: [[00_Raw/2026-04-20/Garbage Collection(가비지 컬렉션).md]]
----
diff --git a/Programming & Language/Generational Hypothesis.md b/Programming & Language/Generational Hypothesis.md
deleted file mode 100644
index 7c2746e9..00000000
--- a/Programming & Language/Generational Hypothesis.md	
+++ /dev/null
@@ -1,34 +0,0 @@
----
-id: P-REINFORCE-AUTO-D9833D
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Generational Hypothesis"
----
-
-# [[Generational Hypothesis]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 세대 가설(Generational Hypothesis)은 대부분의 객체가 생성된 직후에 도달할 수 없는 상태가 되어 소멸한다는(die young) 프로그래밍의 경험적 관찰을 의미합니다 [1, 2]. 이 원리는 V8이나 JavaScript뿐만 아니라 대부분의 동적 프로그래밍 언어에 적용되는 가비지 컬렉션의 핵심 전제입니다 [2]. V8 엔진은 이 가설을 적극적으로 활용하여 메모리 힙을 '젊은 세대(Young Generation)'와 '오래된 세대(Old Generation)'로 분할함으로써 가비지 컬렉션의 효율성과 성능을 최적화합니다 [1, 3, 4].
-
-## 📖 구조화된 지식 (Synthesized Content)
-- **가설의 개념적 기반**: 프로그램에서 대다수의 객체는 수명이 매우 짧은 반면, 극소수의 객체만이 훨씬 오래 살아남는다는 사실에 기초합니다 [3]. 가비지 컬렉터의 관점에서 보면, 객체가 할당된 후 거의 즉시 참조되지 않는 '도달 불가능(unreachable)' 상태가 됨을 의미합니다 [2].
-- **세대별 힙 공간 분할 (Generational Heap Layout)**: V8은 객체 수명 주기의 이러한 특성을 이용하기 위해 메모리 힙을 두 세대의 공간으로 나눕니다 [1, 2, 4].
-    - **New Space (젊은 세대)**: 새롭게 생성된 짧은 수명의 객체들이 할당되는 비교적 작은 공간입니다 [3, 4]. 이곳의 객체들은 일찍 소멸할 것으로 예상되므로, V8은 빈번하고 빠른 마이너 가비지 컬렉션(Scavenge)을 실행하여 신속하게 메모리를 회수합니다 [1, 4].
-    - **Old Space (오래된 세대)**: New Space에서 두 번의 가비지 컬렉션 주기(Minor GC)를 견디고 살아남은 객체들은 Old Space로 승격(promoted)됩니다 [1, 3, 4]. 사용자 세션과 같이 지속될 것으로 예상되는 데이터들이 모이며, 비용이 더 많이 드는 Major GC를 통해 덜 빈번하게 관리됩니다 [1, 4].
-- **가비지 컬렉션 성능 최적화 효과**: V8의 가비지 컬렉터는 살아남은 객체를 복사하여 이동시키는 방식을 사용합니다 [2]. 복사 작업 자체는 비용이 많이 들지만, 세대 가설에 따라 실제로 살아남는 객체의 비율은 매우 적습니다 [2]. 결국 살아남은 소수의 객체만 이동시키면 나머지 대다수의 객체는 '암묵적인 가비지(implicit garbage)'로 자연스럽게 정리되므로, 전체 할당 횟수가 아닌 생존한 객체의 수에 비례하는 최소한의 비용만 지불하게 됩니다 [2].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[Garbage Collection]], [[V8 JavaScript Engine]], [[Young Generation (New Space)]], [[Old Generation (Old Space)]], [[Scavenger (Minor GC)]]
-- **Projects/Contexts:** [[V8 Memory Management]]
-- **Contradictions/Notes:** 제공된 소스들은 모두 일관되게 세대 가설의 원리와 V8 엔진 내 적용 방식을 지지하며, 이에 반대되는 모순된 주장이나 기록은 확인되지 않습니다.
-
----
-*Last updated: 2026-04-19*
-- Raw Source: [[00_Raw/2026-04-20/Generational Hypothesis.md]]
----
diff --git a/Programming & Language/Git Hooks.md b/Programming & Language/Git Hooks.md
deleted file mode 100644
index 6f46d788..00000000
--- a/Programming & Language/Git Hooks.md	
+++ /dev/null
@@ -1,45 +0,0 @@
----
-id: P-REINFORCE-AUTO-F69A27
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Git Hooks"
----
-
-# [[Git Hooks]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> Git Hooks는 Git 워크플로의 특정 이벤트(commit, push, merge 등)가 발생할 때 자동으로 실행되도록 설정할 수 있는 셸 스크립트 또는 실행 가능한 프로그램입니다 [1-3]. 주로 개발자가 코드를 커밋하거나 푸시하기 직전에 린트(Lint), 코드 포맷팅, 테스트 등을 실행하여 오류가 있는 코드가 리포지토리에 저장되는 것을 방지하고 코드 퀄리티를 일관되게 유지하는 역할을 합니다 [4, 5].
-
-## 📖 구조화된 지식 (Synthesized Content)
-*   **위치 및 구동 방식**
-    기본적으로 Git Hook 스크립트들은 프로젝트의 `.git/hooks/` 폴더에 위치합니다 [3, 6]. Git은 `core.hooksPath`가 가리키는 경로의 스크립트들을 확인하여 특정 Git 명령이 실행되기 전후에 이를 호출하며, 실행 권한이 부여되지 않은 Hook은 무시됩니다 [3].
-
-*   **버전 관리의 한계와 해결책**
-    `.git/hooks/` 디렉터리는 버전 관리(Version Control) 시스템에 의해 추적되지 않기 때문에, 새로운 팀원에게 설정이 자동으로 공유되지 않으며 리포지토리를 다시 클론할 때마다 설정이 유실되는 단점이 있습니다 [6]. 이를 해결하기 위해 개발 생태계에서는 `Husky`와 같은 도구를 도입하여 Hook 스크립트를 `.husky/`와 같이 추적 가능한 폴더에서 관리하도록 `core.hooksPath` 설정을 자동화합니다 [6, 7].
-
-*   **주요 Client-side Hooks 종류**
-    *   **`pre-commit`**: 커밋이 생성되기 직전에 실행되며 스테이징된 파일의 포맷팅이나 린트 검사를 수행하는 데 주로 쓰입니다 [1, 2, 8]. 매우 빠르게 실행되어야 하며, `git commit --no-verify` 명령을 통해 우회할 수 있습니다 [8, 9].
-    *   **`prepare-commit-msg`**: 커밋 메시지 편집기가 열리기 전에 실행되어 메시지 템플릿 삽입 등을 처리하며, 우회할 수 없는 특수한 Hook입니다 [1, 8].
-    *   **`commit-msg`**: 작성된 커밋 메시지 형식을 유효성 검사하는 데 쓰입니다 [1, 2, 8].
-    *   **`post-commit`**: 커밋이 완료된 후 호출됩니다 [1].
-    *   **`pre-push`**: 원격 저장소에 푸시(push)되기 직전에 실행됩니다 [2, 8, 10]. 상대적으로 실행 시간이 오래 걸리는 전체 테스트 스위트 실행이나 빌드 검증 작업이 이곳에 배치됩니다 [9, 11].
-    *   **`post-merge`**: 병합(merge) 작업이 완료된 후 실행됩니다 [2].
-
-*   **최적화 방법론 (Lint-staged 결합)**
-    `pre-commit` Hook에서 전체 프로젝트를 대상으로 ESLint나 Prettier를 실행하면 시간이 오래 걸려 개발자들의 불만을 초래할 수 있습니다 [6, 9]. 따라서 변경사항이 발생하여 커밋 대기 상태가 된 파일(Staged files)에 대해서만 린트 및 포맷팅 검사를 수행하도록 `lint-staged`를 결합하는 것이 일반적이며 이를 통해 검사 시간을 크게 단축할 수 있습니다 [5, 6, 12, 13].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** `[[Husky]]`, `[[lint-staged]]`, `[[ESLint]]`, `[[Prettier]]`
-- **Projects/Contexts:** `[[CI/CD 파이프라인 (CI/CD Pipelines)]]`, `[[코드 품질 관리 및 자동화 (Code Quality Management and Automation)]]`
-- **Contradictions/Notes:** 소스에 따르면 Git Hook은 개발자가 강제로 우회(`--no-verify` 등)할 수 있으므로 절대적이고 완벽한 강제 수단이 될 수는 없습니다. 따라서 Hook은 로컬 환경에서 빠른 피드백을 제공하기 위한 도구로 취급되어야 하며, 최종적인 보안 및 품질 검증의 권한은 항상 CI(지속적 통합) 서버가 담당해야 한다고 강조합니다 [8, 14, 15].
-
----
-*Last updated: 2026-04-18*
-- Raw Source: [[00_Raw/2026-04-20/Git Hooks.md]]
----
diff --git a/Programming & Language/Git Hook을 이용한 CI_CD 자동화 파이프라인.md b/Programming & Language/Git Hook을 이용한 CI_CD 자동화 파이프라인.md
deleted file mode 100644
index 74add408..00000000
--- a/Programming & Language/Git Hook을 이용한 CI_CD 자동화 파이프라인.md	
+++ /dev/null
@@ -1,41 +0,0 @@
----
-id: P-REINFORCE-AUTO-E60BE3
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Git Hook을 이용한 CI_CD 자동화 파이프라인"
----
-
-# [[Git Hook을 이용한 CI_CD 자동화 파이프라인]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> Git 훅(Git Hooks)은 소스 코드 버전 관리 시스템인 Git의 특정 작업(commit, push 등) 전후에 자동으로 실행되도록 설정된 쉘 스크립트이다 [1]. 프론트엔드 및 Node.js 생태계에서는 주로 Husky와 lint-staged라는 도구를 활용하여 Git 훅을 설정하고 관리한다 [2], [3]. 이를 통해 코드가 원격 저장소나 CI 파이프라인으로 넘어가기 전인 로컬 단계에서 코드 스타일, 포맷팅(Prettier), 문법적 오류(ESLint) 등을 자동으로 검사하고 수정함으로써 일관된 품질을 강제하는 '최전선 방어선' 역할을 수행한다 [1], [4], [3].
-
-## 📖 구조화된 지식 (Synthesized Content)
-* **Git 훅(Git Hooks)의 종류와 한계**
-  Git 훅은 `.git/hooks/` 경로에 존재하는 스크립트로 `pre-commit`, `commit-msg`, `pre-push` 등으로 나뉜다 [1], [5]. 특히 `pre-commit`은 커밋이 생성되기 직전에 실행되어 포맷팅이나 린팅을 수행하며, `pre-push`는 푸시 전에 테스트 스위트를 실행하는 등 다소 무거운 작업에 적합하다 [1], [6], [7]. 하지만 로컬의 `.git/hooks/` 디렉토리는 버전 관리가 되지 않아 팀원 간 공유가 어렵고, 개발자가 `--no-verify` 옵션을 통해 훅을 우회할 수 있다는 태생적 한계가 존재한다 [2], [8].
-
-* **Husky를 통한 Git 훅 공유 및 관리**
-  Husky는 Git의 기본 훅 경로(`core.hooksPath`)를 `.husky/` 디렉토리로 변경하여 훅 스크립트를 Git 버전 관리에 포함시킬 수 있게 해주는 도구이다 [2], [9]. `package.json`의 `prepare` 스크립트와 연동하면, 프로젝트를 클론한 팀원이 `npm install`을 실행할 때 자동으로 Husky 훅이 로컬 환경에 셋업되므로 모든 개발자에게 동일한 검사 규칙을 쉽게 강제할 수 있다 [10], [11], [12].
-
-* **lint-staged를 활용한 검사 최적화 및 자동화**
-  프로젝트 규모가 커질수록 전체 코드베이스를 대상으로 ESLint나 Prettier를 실행하는 것은 수십 초 이상이 소요되어 개발 생산성을 떨어뜨린다 [2]. `lint-staged`는 현재 Git의 staged 상태인(커밋을 위해 추가된) 파일들에만 글로브(glob) 패턴을 매칭하여 명령어를 실행해 주는 오케스트레이션 도구(router)이다 [13], [14], [15]. 
-  보통 `pre-commit` 훅 내부에서 `lint-staged`를 호출하도록 구성하여, 변경된 파일들만을 대상으로 1~2초 만에 검사 및 자동 수정(`eslint --fix`, `prettier --write` 등)을 마칠 수 있다 [2], [7], [16]. 또한 `lint-staged`는 작업이 성공하면 변경된 내용을 자동으로 다시 스테이징(auto-staging) 처리해 주므로, 설정이 간편하다 [10], [17].
-
-* **CI 파이프라인과의 역할 분담 (Hybrid Approach)**
-  Husky와 lint-staged 기반의 자동화는 개발자 경험(DX) 향상과 피드백 루프 단축을 위한 로컬 도구이다 [8], [18]. 개발자가 훅을 우회할 가능성이 상존하므로, 로컬 Git 훅이 CI(Continuous Integration)를 완전히 대체할 수는 없다 [19]. 따라서 로컬 훅을 통해 명백한 문제(불량 커밋 등)가 원격지에 올라가는 것을 사전에 방지하고, 최종적인 코드 품질 강제(enforcement boundary)와 전체 테스트 수행 등은 CI 파이프라인의 몫으로 남겨두는 형태가 이상적이다 [19], [18], [20].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[Husky]], [[lint-staged]], [[ESLint]], [[Prettier]]
-- **Projects/Contexts:** [[자동화된 코드 품질 및 스타일 검사 워크플로우]]
-- **Contradictions/Notes:** lint-staged는 버전 10부터 성공적으로 파일이 수정되면 자동으로 `git add`를 수행하므로, 설정 파일의 커맨드 목록에 수동으로 `git add`를 넣는 것은 중복 작업 및 레이스 컨디션(race condition)을 유발할 수 있어 더 이상 권장되지 않는다 [17], [21]. 또한, 로컬 Git 훅은 우회(`--no-verify`)가 가능하므로 완벽한 정책 집행 경계가 될 수 없으며, CI 서버를 보완하는 성격으로 사용해야 한다 [19], [8], [21].
-
----
-*Last updated: 2026-04-19*
-- Raw Source: [[00_Raw/2026-04-20/Git Hook을 이용한 CI_CD 자동화 파이프라인.md]]
----
diff --git a/Programming & Language/Git Pre-commit 훅을 활용한 개발 워크플로우 자동화.md b/Programming & Language/Git Pre-commit 훅을 활용한 개발 워크플로우 자동화.md
deleted file mode 100644
index 3fe28a81..00000000
--- a/Programming & Language/Git Pre-commit 훅을 활용한 개발 워크플로우 자동화.md	
+++ /dev/null
@@ -1,34 +0,0 @@
----
-id: P-REINFORCE-AUTO-26C070
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Git Pre-commit 훅을 활용한 개발 워크플로우 자동화"
----
-
-# [[Git Pre-commit 훅을 활용한 개발 워크플로우 자동화]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> Git Pre-commit 훅은 커밋이 코드 저장소에 기록되기 직전에 자동으로 실행되는 스크립트이다 [1]. 개발 팀은 주로 Husky와 lint-staged 같은 도구를 결합하여 사용하여, 커밋 대상 파일(staged files)에 대해서만 린트(Lint) 검사와 코드 포맷팅을 자동으로 수행한다 [2, 3]. 이를 통해 문법적 결함이 있거나 팀의 컨벤션에 맞지 않는 코드가 저장소에 유입되는 것을 사전에 차단하고, 일관된 코드 품질을 빠르고 효율적으로 유지할 수 있다 [3, 4].
-
-## 📖 구조화된 지식 (Synthesized Content)
-* **Git 훅과 Pre-commit의 역할:** Git 훅은 커밋 생성 전(`pre-commit`), 푸시 전(`pre-push`) 등 Git 워크플로우의 특정 이벤트 시점에 실행되는 쉘 스크립트이다 [1]. 그중에서도 `pre-commit` 훅은 코드가 코드 저장소에 들어가기 전의 최후의 방어선 역할을 수행하며, 빠른 포맷팅이나 린팅을 자동화하는 데 가장 적합하다 [1, 5].
-* **Husky를 통한 훅 관리:** 기본적으로 Git 훅은 `.git/hooks/` 폴더에 로컬로 존재하고 버전 관리가 되지 않기 때문에 새로운 팀원이나 CI 환경에 자동으로 공유되지 않는 한계가 있다 [2]. Husky는 훅 스크립트를 `.husky/`와 같이 버전 관리 시스템이 추적할 수 있는 디렉토리에 저장하고, Git의 `core.hooksPath`를 변경하여 이 문제를 해결하는 도구이다 [2, 6]. `package.json`의 `prepare` 스크립트 설정을 통해 팀원이 `npm install`을 실행할 때 자동으로 훅이 연동되도록 구성할 수 있다 [7, 8].
-* **lint-staged를 통한 성능 및 시간 최적화:** 커밋을 할 때마다 수많은 파일로 구성된 전체 코드베이스에 대해 ESLint나 Prettier를 실행하면 시간이 오래 걸려 개발 생산성을 크게 저하시킨다 [2, 5]. `lint-staged`는 오직 변경되어 Git의 스테이징 영역(staged files)에 올라간 파일들만 필터링하여 명령어를 실행하는 라우터 역할을 하므로, 검사 시간을 단 몇 초 이내로 대폭 줄여준다 [2, 9, 10].
-* **자동화 워크플로우 통합 동작 방식:** `pre-commit` 훅에서 `lint-staged`를 호출하도록 구성하면, 커밋을 시도할 때마다 자동으로 ESLint를 통한 오류 검출(및 `--fix`를 통한 자동 수정)과 Prettier를 통한 코드 정렬이 이루어진다 [7, 11]. `lint-staged`는 포맷팅으로 인해 수정된 파일들을 수동으로 추가할 필요 없이 알아서 다시 스테이징 처리한다 [7, 10]. 만약 해결할 수 없는 구문 오류나 규칙 위반이 발견되면 스크립트가 실패하며 커밋 프로세스가 즉시 중단된다 [12].
-* **로컬 자동화와 CI(지속적 통합)의 관계:** 개발자는 급하거나 훅이 고장 난 경우 `--no-verify` 플래그를 사용하거나 `HUSKY=0` 환경 변수를 설정하여 로컬 훅 실행을 우회(Bypass)할 수 있다 [13-15]. 따라서 Git 훅은 개발자에게 빠른 피드백을 제공하는 도구일 뿐이며, 최종적인 코드 강제 집행과 완벽한 보장을 위해서는 CI 서버에서 전체 테스트 및 검사가 반드시 병행되어야 한다 [14, 16, 17].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[Husky]], [[lint-staged]], [[ESLint]], [[Prettier]], [[Continuous Integration (CI)]]
-- **Projects/Contexts:** [[팀 단위 코드 품질 및 컨벤션 유지]], [[대규모 모노레포(Turborepo) 환경에서의 린트 오케스트레이션]]
-- **Contradictions/Notes:** `lint-staged`는 전체 프로젝트를 검사하도록 설계된 도구(예: 전체 구조를 파악해야 하는 `ng lint`나 TypeScript의 `tsc --noEmit` 등)를 래핑하는 용도로는 적합하지 않으며, 단일 파일 단위로 처리 가능한 작업에만 사용해야 한다 [18-20]. 또한, 설정 시 여러 명령어가 동일한 파일을 동시에 수정하도록 구성하면 경쟁 조건(Race condition)이 발생하여 코드가 망가질 수 있으므로, 명령어 배열(Array)을 사용하여 순차적으로 실행되게 설정해야 한다 [21].
-
----
-*Last updated: 2026-04-18*
-- Raw Source: [[00_Raw/2026-04-20/Git Pre-commit 훅을 활용한 개발 워크플로우 자동화.md]]
----
diff --git a/Programming & Language/Global Network Positioning (GNP).md b/Programming & Language/Global Network Positioning (GNP).md
deleted file mode 100644
index 51f1104c..00000000
--- a/Programming & Language/Global Network Positioning (GNP).md	
+++ /dev/null
@@ -1,34 +0,0 @@
----
-id: P-REINFORCE-AUTO-D96374
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Global Network Positioning (GNP)"
----
-
-# [[Global Network Positioning (GNP)]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> Global Network Positioning (GNP)은 인터넷 지연 시간(latency)을 다차원 기하학적 공간으로 모델링하여 확장 가능한 지연 시간 추정을 가능하게 하는 접근 방식입니다 [1]. 소수의 전용 '랜드마크(landmark)' 노드에 대한 측정값을 바탕으로 각 인터넷 노드에 해당 공간의 좌표를 부여합니다 [1]. 이를 통해 임의의 두 노드 간의 통신 지연 시간을 실제 측정 없이도 두 좌표 간의 유클리드 거리(Euclidean distance)로 효율적으로 근사할 수 있습니다 [1, 2].
-
-## 📖 구조화된 지식 (Synthesized Content)
-* **동작 원리 및 좌표 계산 체계:** GNP는 $k$개의 랜드마크 호스트 좌표를 사용하여 N차원 기하학적 공간을 결정합니다 [2]. 먼저 랜드마크 간의 지연 시간을 측정한 뒤, 거리와 측정된 지연 시간 사이의 오차를 최소화하는 'Simplex-downhill' 알고리즘을 사용하여 랜드마크들의 좌표를 계산합니다 [3, 4]. 랜드마크의 좌표가 설정되면, 일반 호스트와 각 랜드마크 간의 지연 시간을 바탕으로 해당 호스트의 좌표를 삼각측량 방식으로 계산합니다 [2-4].
-* **확장성 및 성능 최적화:** GNP의 가장 큰 장점은 개별 호스트의 위치를 파악하는 데 일정하고 적은 횟수의 측정만 필요하다는 점입니다 [1]. 이 확장성 덕분에 대규모 머신 간의 모든 지연 시간을 낮은 비용으로 빠르게 추정할 수 있습니다 [1].
-* **기존 구현의 한계:** 과거의 GNP 구현들은 위치를 파악할 대상 노드의 능동적인 참여(active participation)를 요구했습니다 [5]. 이는 악의적인 노드가 잘못된 지연 시간을 보고할 위험, 랜드마크의 과부하, 그리고 웹 클라이언트와 같은 제3자 환경에 특수 소프트웨어를 배포하기 어렵다는 근본적인 문제를 안고 있었습니다 [5].
-* **구글(Google)의 대규모 구현 방식:** 구글은 자사의 콘텐츠 전송 네트워크(CDN)에 GNP를 통합하여 수백만 명의 클라이언트를 포지셔닝하는 대규모 지연 시간 추정 시스템을 구현했습니다 [6, 7]. 이 시스템은 대상 노드의 능동적 참여에 의존하지 않고 랜드마크 측에서 수동적으로(passively) 지연 시간을 측정하며, 확장 가능한 중앙 집중식 스케줄러를 사용하여 네트워크 오버헤드와 랜드마크의 과부하를 정밀하게 제어합니다 [6, 7].
-* **좌표의 시간에 따른 안정성 (Coordinate Stability):** 네트워크 라우팅 변경이나 일시적인 혼잡 등으로 인해 GNP 좌표는 시간이 지나면서 초기 값에서 서서히 벗어나는(drift) 경향이 있습니다 [8]. 구글의 분석에 따르면 1주일 후 전체 노드의 25%가 초기값에서 33밀리초(ms) 이상 벗어났지만, 매일 좌표를 재계산(daily recomputation)할 경우 75%의 좌표를 초기값의 6ms 이내로 안정하게 유지할 수 있습니다 [8].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[Latency Estimation]], [[Landmark Nodes]], [[Simplex-downhill Algorithm]]
-- **Projects/Contexts:** [[Google Content Delivery Network (CDN)]]
-- **Contradictions/Notes:** 기존의 수많은 GNP 모델과 구현체들은 시스템 확장을 위해 호스트들의 능동적인 측정 참여를 필수적으로 요구했으나, 구글의 대규모 CDN 구현 사례는 랜드마크 측에서의 수동적 측정과 스케줄러 조합만으로도 능동적 참여의 단점(보안 및 과부하 위험)을 극복하고 시스템을 구축할 수 있음을 증명했습니다.
-
----
-*Last updated: 2026-04-19*
-- Raw Source: [[00_Raw/2026-04-20/Global Network Positioning (GNP).md]]
----
diff --git a/Programming & Language/Google Chrome.md b/Programming & Language/Google Chrome.md
deleted file mode 100644
index b893695a..00000000
--- a/Programming & Language/Google Chrome.md	
+++ /dev/null
@@ -1,40 +0,0 @@
----
-id: P-REINFORCE-AUTO-A2356F
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Google Chrome"
----
-
-# [[Google Chrome]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> Google Chrome은 V8 JavaScript 엔진을 내장하여 웹 애플리케이션 및 JavaScript 코드를 실행하는 웹 브라우저입니다 [1, 2]. 메인 렌더러로 Blink를 사용하며, V8의 가비지 컬렉터(Orinoco)와 Blink의 내부 가비지 컬렉터(Oilpan)가 상호 협력하여 메모리를 관리합니다 [2]. 또한, Chrome DevTools와 같은 강력한 메모리 프로파일링 및 디버깅 도구를 내장하여 개발자가 메모리 누수를 진단하고 성능을 최적화할 수 있도록 지원하며 [3-5], 보안 측면에서는 V8 힙(Heap) 객체를 제한된 공간에 가두는 'V8 Memory Cage' 기술을 적용하고 있습니다 [6, 7].
-
-## 📖 구조화된 지식 (Synthesized Content)
-- **V8 엔진 최적화 및 렌더링 성능 관리**
-  Google Chrome은 메모리 최적화를 위해 V8 엔진의 개선 사항을 지속적으로 적용해 왔습니다. Chrome 53에서는 저사양 기기를 위한 메모리 축소 모드를 도입하여 평균 V8 힙 크기를 약 50% 줄였고, Chrome 55에서는 백그라운드 파싱(Background parsing) 중 메모리 소비를 최적화하여 존(Zone) 메모리 피크를 크게 감소시켰습니다 [8-11]. 또한 초당 60프레임(약 16.6ms)으로 렌더링을 수행할 때, 애니메이션 작업이 일찍 완료되어 여유 시간이 생기면 V8의 유휴 시간(Idle-time) 가비지 컬렉션을 선제적으로 실행하여 메인 스레드의 끊김(Jank) 현상을 방지합니다 [12].
-
-- **Chrome DevTools를 활용한 메모리 프로파일링**
-  Chrome은 개발자가 메모리 누수나 성능 저하 원인을 추적할 수 있도록 `Memory` 패널을 제공합니다. 여기서 힙 스냅샷(Heap snapshot)을 캡처하거나, 시간 흐름에 따른 메모리 할당(Allocation instrumentation on timeline)을 기록하여 객체의 생성 및 소멸 과정을 시각적으로 분석할 수 있습니다 [3-5, 13, 14]. 더 심층적인 엔진 내부 분석이 필요할 때는 `chrome://tracing` 인프라를 활용하여 가비지 컬렉션(GC) 객체 통계 데이터를 수집하고 시각화할 수 있습니다 [15-17].
-
-- **V8 Memory Cage와 보안 아키텍처**
-  64비트 Chrome 환경에서는 보안 강화를 위해 '포인터 압축(Pointer Compression)'과 'V8 Memory Cage' 아키텍처를 적용합니다 [6, 7, 18]. 이 기술은 V8 내부의 모든 힙 객체를 4GB 크기의 연속된 샌드박스 영역 내에 가두고, 포인터를 64비트 전체 주소가 아닌 32비트 오프셋으로 저장합니다 [7, 19]. 이를 통해 메모리 효율을 높이는 동시에, OOB(Out-of-Bounds)나 타입 혼동(Type Confusion) 등 악의적인 메모리 손상 공격이 발생하더라도 공격자가 이 샌드박스 범위를 벗어나 브라우저 프로세스 전체 메모리를 임의로 읽거나 쓰는 것을 차단합니다 [19-21].
-
-- **렌더러 충돌(Crash)과 포렌식 활용**
-  Chrome 브라우저에서 복잡한 익스플로잇 시도가 실패할 경우 렌더러 프로세스 충돌(Crash)이 발생하게 됩니다 [22]. 이러한 충돌 덤프 데이터에는 공격자가 V8 힙에 남긴 가짜 객체(fakeobj), 손상된 배열 길이, 원시 데이터 메모리 흔적 등이 포함되며, 이를 통해 아직 알려지지 않은 제로데이 공격 시도 등을 포렌식 관점에서 사전에 감지하고 식별할 수 있습니다 [23, 24].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** `[[V8 JavaScript Engine]]`, `[[Chrome DevTools]]`, `[[Garbage Collection]]`, `[[Pointer Compression]]`, `[[Blink]]`
-- **Projects/Contexts:** `[[Orinoco]]`, `[[Oilpan]]`, `[[V8 Memory Cage]]`
-- **Contradictions/Notes:** 가비지 컬렉션은 개발자가 명시적으로 메모리를 관리하지 않도록 편의를 제공하지만, 처리 과정에서 예측할 수 없는 중단(Pause)을 발생시킬 위험이 있습니다. 이를 극복하기 위해 Chrome과 V8은 메인 스레드를 멈추는 대신 점진적(Incremental), 동시성(Concurrent), 병렬(Parallel) 기법 및 유휴 시간(Idle-time) 활용 모델을 도입하여 성능 저하를 방지하고 있습니다 [25-28].
-
----
-*Last updated: 2026-04-19*
-- Raw Source: [[00_Raw/2026-04-20/Google Chrome.md]]
----
diff --git a/Programming & Language/Google Code Jam Dataset.md b/Programming & Language/Google Code Jam Dataset.md
deleted file mode 100644
index 06c9f518..00000000
--- a/Programming & Language/Google Code Jam Dataset.md	
+++ /dev/null
@@ -1,39 +0,0 @@
----
-id: P-REINFORCE-AUTO-A3BFE1
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Google Code Jam Dataset"
----
-
-# [[Google Code Jam Dataset]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> Google Code Jam Dataset은 구글의 코딩 대회인 Google Code Jam 참가자들이 작성한 소스 코드 해결책들을 모아놓은 데이터셋입니다 [1]. 대회 특성상 코딩 스타일, 가이드라인, 포맷팅에 대한 제약이 없기 때문에 개발자 각자의 고유한 프로그래밍 스타일이 그대로 반영되어 있습니다 [1]. 이러한 특성과 높은 정답(Ground Truth) 순도 덕분에 기계학습을 활용한 코드 스타일로미트리(Code Stylometry, 작성자 식별) 및 소프트웨어 포렌식 연구에서 가장 인기 있고 널리 사용되는 벤치마크 데이터셋 중 하나입니다 [1], [2], [3].
-
-## 📖 구조화된 지식 (Synthesized Content)
-* **데이터셋의 구조적 특성**
-  Google Code Jam Dataset의 가장 큰 장점은 여러 작성자가 **동일한 문제에 대한 해결책(Semantic uniformity)**을 제공한다는 점입니다 [4]. 이는 머신러닝 분류기가 코드의 의미적(Semantic) 내용이 아닌 작성자 간의 '스타일적 차이'만을 온전히 학습하도록 강제할 수 있게 합니다 [4], [5]. 또한 양적으로도 균형 잡힌 구성을 제공하여 데이터의 불균형 문제 없이 일관된 분석이 가능합니다 [4]. 다만 실제 소프트웨어 개발과는 달리, 코딩 대회 특성상 입출력 처리 등에서 재사용되는 보일러플레이트 코드가 다수 포함될 수 있다는 한계도 존재합니다 [6].
-
-* **코드 스타일로미트리(작성자 식별) 연구에서의 활용**
-  이 데이터셋은 소스 코드뿐만 아니라 컴파일된 실행 파일의 작성자를 식별하는 연구에도 폭넓게 활용되었습니다 [7], [5].
-  * **소스 코드 분석:** Caliskan-Islam 등은 2008-2014년 대회의 C/C++ 제출물을 활용해 최대 1,600명의 프로그래머를 90% 이상의 정확도로 식별하는 연구를 수행했습니다 [2], [8]. 파이썬 코드를 모은 부분 집합인 *gcjpy* 데이터셋(70명의 작성자, 총 700개 파일)은 AST(추상 구문 트리) 및 CST(구체 구문 트리) 기반의 분류기를 통한 연구나 코드 포맷팅 및 축소(Minification)가 작성자 식별에 미치는 영향을 분석하는 데 사용되었습니다 [1], [4], [9].
-  * **실행 바이너리 분석:** Rosenblum 등과 Caliskan-Islam 등은 C/C++ 데이터셋을 사용하여 프로그래머의 코딩 스타일이 컴파일 과정을 거친 후에도 바이너리(실행 파일)에 보존된다는 것을 입증하는 데 활용했습니다 [7], [10], [5].
-
-* **적대적 환경(Adversarial) 연구**
-  Simko 등은 인간 프로그래머가 다른 사람의 코딩 스타일을 의도적으로 모방하거나 자신의 스타일을 숨기려 할 때 기존의 기계학습 기반 작성자 식별 모델이 얼마나 취약한지를 평가하는 사용자 연구에서 이 데이터셋을 활용했습니다 [11], [12].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[Code Stylometry]], [[Authorship Attribution]], [[Abstract Syntax Tree (AST)]], [[Concrete Syntax Tree (CST)]]
-- **Projects/Contexts:** [[Google Code Jam]], [[Machine Learning for Source Code]]
-- **Contradictions/Notes:** 소스에 따르면 Google Code Jam 데이터셋은 높은 순도와 통제된 환경을 제공하여 식별 모델 학습에 매우 적합하지만 [3], 실제 프로덕션 환경의 코드와는 달리 대회 특유의 반복적인 보일러플레이트 코드가 다수 포함되어 있어 실제 현실의 소프트웨어(In the wild)를 대상으로 할 때와는 차이가 발생할 수 있다는 점이 지적됩니다 [6].
-
----
-*Last updated: 2026-04-19*
-- Raw Source: [[00_Raw/2026-04-20/Google Code Jam Dataset.md]]
----
diff --git a/Programming & Language/Google Lighthouse.md b/Programming & Language/Google Lighthouse.md
deleted file mode 100644
index e103b535..00000000
--- a/Programming & Language/Google Lighthouse.md	
+++ /dev/null
@@ -1,32 +0,0 @@
----
-id: P-REINFORCE-AUTO-88077C
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Google Lighthouse"
----
-
-# [[Google Lighthouse]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> Google Lighthouse는 웹사이트의 페이지 속도를 측정하고 성능 개선을 위한 권장 사항을 제공하는 구글의 무료 오픈 소스 도구입니다 [1], [2]. 주로 개발 단계에서 브라우저의 성능을 시뮬레이션하여 Synthetic Lab Data(합성 랩 데이터)를 수집하며, Chrome DevTools, 명령줄, 그리고 PageSpeed Insights를 통해 사용할 수 있습니다 [2], [3].
-
-## 📖 구조화된 지식 (Synthesized Content)
-* **주요 목적 및 기능:** Lighthouse는 웹 페이지의 로드 성능을 분석하고 최적화할 수 있는 진단 정보를 제공합니다 [1], [2]. 로컬 컴퓨터의 하드웨어와 네트워크 환경을 기반으로 성능을 시뮬레이션하는 'Synthetic Lab Data(합성 랩 데이터)' 수집 도구로 분류되며, 특히 개발 단계의 테스트나 직접 접근할 수 없는 웹사이트의 감사(audit) 목적에 가장 유용합니다 [2], [3]. Lighthouse가 측정하는 대표적인 성능 지표 중 하나로는 페이지가 완전히 상호 작용할 수 있게 되는 시간을 측정하는 'Time to Interactive(TTI)'가 있습니다 [4].
-* **도구 통합 및 엔진 재사용:** Lighthouse는 Google의 PageSpeed Insights 진단을 구동하는 핵심 엔진입니다 [1], [2]. 또한 Google은 Chrome DevTools의 성능 탭과 Lighthouse 보고서 양쪽 모두에서 사용할 수 있는 새로운 '인사이트 감사(Insights audits)' 기능을 도입하여, 성능 권장 사항을 식별하기 위해 별도의 엔진을 유지하는 대신 동일한 코드를 재사용하도록 개선했습니다 [1].
-* **스로틀링(Throttling) 시뮬레이션의 한계 및 개선:** Lighthouse는 점수를 결정하기 위해 스로틀링 시뮬레이션을 사용하는데, 이로 인해 때때로 부정확한 데이터가 생성되기도 합니다 [5]. 예를 들어, 페이지 콘텐츠가 미리 로드된(preloaded) 리소스에 의존하지 않음에도 불구하고 해당 리소스가 렌더링을 차단한다고 잘못 가정하는 경우가 있습니다 [5]. 이러한 부정확성을 해결하고 Lighthouse 지표를 더욱 신뢰할 수 있도록 실제 브라우저 동작과 더 잘 일치하게 스로틀링 시뮬레이션을 업데이트하는 작업이 진행 중입니다 [5], [6].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[Chrome DevTools]], [[PageSpeed Insights]], [[Time to Interactive (TTI)]], [[Synthetic Lab Data]]
-- **Projects/Contexts:** [[Web Performance Optimization]]
-- **Contradictions/Notes:** 소스에 따르면 Lighthouse 점수의 단순 평균값은 일부 특이값(outlier)에 의해 왜곡될 수 있으므로 해석 시 주의가 필요합니다 [7]. 또한, Lighthouse의 스로틀링 시뮬레이션은 때때로 실제 브라우저 동작과 다르게 자원 로딩 영향을 평가하는 한계가 지적되어 최적화 작업이 요구되고 있습니다 [5].
-
----
-*Last updated: 2026-04-19*
-- Raw Source: [[00_Raw/2026-04-20/Google Lighthouse.md]]
----
diff --git a/Programming & Language/Graph-Grammars.md b/Programming & Language/Graph-Grammars.md
deleted file mode 100644
index b24f5988..00000000
--- a/Programming & Language/Graph-Grammars.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-492313
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Graph-Grammars"
----
-
-# [[Graph-Grammars]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Graph-Grammars.md]]
----
diff --git a/Programming & Language/Grokking (그로킹 지연 일반화).md b/Programming & Language/Grokking (그로킹 지연 일반화).md
deleted file mode 100644
index 271e4e31..00000000
--- a/Programming & Language/Grokking (그로킹 지연 일반화).md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-D1916C
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Grokking (그로킹 지연 일반화)"
----
-
-# [[Grokking (그로킹 지연 일반화)]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Grokking (그로킹, 지연 일반화).md]]
----
diff --git a/Programming & Language/HNSW 알고리즘 (Hierarchical Navigable Small World).md b/Programming & Language/HNSW 알고리즘 (Hierarchical Navigable Small World).md
deleted file mode 100644
index a12751dd..00000000
--- a/Programming & Language/HNSW 알고리즘 (Hierarchical Navigable Small World).md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-E7A769
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - HNSW 알고리즘 (Hierarchical Navigable Small World)"
----
-
-# [[HNSW 알고리즘 (Hierarchical Navigable Small World)]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/HNSW 알고리즘 (Hierarchical Navigable Small World).md]]
----
diff --git a/Programming & Language/HTC Vive Pro HMD.md b/Programming & Language/HTC Vive Pro HMD.md
deleted file mode 100644
index 5ffa90e7..00000000
--- a/Programming & Language/HTC Vive Pro HMD.md	
+++ /dev/null
@@ -1,32 +0,0 @@
----
-id: P-REINFORCE-AUTO-7B2D1B
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - HTC Vive Pro HMD"
----
-
-# [[HTC Vive Pro HMD]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-* **실험 도구로서의 활용:** 한 연구에서 HTC Vive Pro HMD는 사용자가 가상현실 엑서게임(비트 세이버)을 10분 및 50분 동안 플레이하도록 한 뒤, 시각, 인지, 웰빙에 미치는 사후 효과(VR 멀미 등)를 측정하기 위한 실험 장치로 채택되었습니다 [3], [1], [2]. 
-* **안전 가이드라인 및 부작용:** HTC Vive Pro를 포함한 VR 기기 제조사들은 기기 사용 설명서 및 안전 규정 가이드를 통해 VR 사용 시간에 대한 권장 사항(예: 30분에서 1시간)을 제공하고 잠재적인 부작용을 경고합니다 [4]. 그러나 사용자가 게임의 몰입감으로 인해 시간을 잊고 장시간 기기를 착용할 경우 심각한 VR 멀미(VR sickness) 증상을 겪을 수 있습니다 [4].
-* 소스에 관련 정보가 부족합니다. 기기 구동 원리, 해상도, 부가 기능 등 HTC Vive Pro HMD 자체의 핵심 기능에 대한 상세한 설명은 소스 내에 존재하지 않습니다.
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[Head-Mounted Display (HMD)]], [[Virtual Reality (VR)]], [[VR Sickness]]
-- **Projects/Contexts:** [[Exergaming With Beat Saber 연구 (VR 엑서게임 사후 효과 연구)]]
-- **Contradictions/Notes:** 기기 자체의 특성이나 스펙에 대한 세부 내용은 없고, 특정 연구의 실험 세팅용 장비로만 등장하므로 전체적인 맥락을 파악하기에는 소스에 관련 정보가 부족합니다.
-
----
-*Last updated: 2026-04-19*
-- Raw Source: [[00_Raw/2026-04-20/HTC Vive Pro HMD.md]]
----
diff --git a/Programming & Language/Heap Snapshot.md b/Programming & Language/Heap Snapshot.md
deleted file mode 100644
index 08d0abc2..00000000
--- a/Programming & Language/Heap Snapshot.md	
+++ /dev/null
@@ -1,42 +0,0 @@
----
-id: P-REINFORCE-AUTO-E3AFF4
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Heap Snapshot"
----
-
-# [[Heap Snapshot]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> Heap Snapshot은 특정 시점에 V8 엔진 및 JavaScript 애플리케이션의 전체 메모리 상태(객체 그래프)를 캡처하는 도구 및 기법입니다 [1, 2]. 주로 JavaScript 객체와 관련된 DOM 노드의 메모리 분포를 보여주며, 가비지 컬렉션(GC) 루트에서 도달할 수 있는 객체들만 캡처합니다 [3, 4]. 개발자는 여러 스냅샷을 비교하고 참조 유지 체인을 추적하여 프로그램 내에서 발생하는 메모리 누수를 찾아내고 원인을 분석하는 데 이 도구를 필수적으로 사용합니다 [1, 3, 5].
-
-## 📖 구조화된 지식 (Synthesized Content)
-- **작동 원리 및 객체 고유 식별:** 
-  스냅샷 캡처는 메모리에 남은 실제 객체만 분석하기 위해 항상 가비지 컬렉션(GC) 수행으로 시작됩니다 [4]. 수집된 각 객체에는 `@` 기호가 붙은 고유 ID가 부여되는데, 이 ID는 여러 번의 스냅샷 생성 간에도 계속 유지되므로 개발자가 힙 상태와 객체의 변화를 정밀하게 추적하고 비교할 수 있습니다 [6-8].
-- **핵심 메모리 평가 지표:** 
-  스냅샷은 객체가 차지하는 메모리 크기를 주로 두 가지 기준으로 나누어 보여줍니다.
-  - *Shallow Size (얕은 크기):* 객체 자체가 직접적으로 점유하는 메모리 크기입니다. 일반적으로 배열과 문자열이 큰 Shallow Size를 가집니다 [9].
-  - *Retained Size (유지된 크기):* 해당 객체를 삭제하여 이에 종속된 다른 객체들이 더 이상 GC 루트에서 접근할 수 없게 되었을 때, GC를 통해 최종적으로 확보할 수 있는 전체 메모리 크기입니다 [9].
-- **데이터 분석 뷰 (Chrome DevTools 기준):**
-  - *Summary View (요약 뷰):* 객체를 생성자(Constructor) 이름과 소스별로 그룹화하여 보여줍니다 [10, 11]. Detached DOM 노드 등 비효율적인 메모리 사용 패턴을 식별하고 필터링하는 데 유용합니다 [12].
-  - *Comparison View (비교 뷰):* 특정 작업의 수행 전후 등 두 개 이상의 스냅샷 간 차이를 비교합니다 [10, 13]. 해제된 메모리와 참조 횟수(Reference count)의 델타값을 조사하여 누수를 찾아내며, 보통 신뢰성을 높이기 위해 3번의 스냅샷을 찍어 비교하는 기법(Three-snapshot technique)이 권장됩니다 [5, 13].
-  - *Containment View (포함 뷰):* 애플리케이션 객체 구조에 대한 '조감도' 역할을 합니다 [14]. 클로저(Closure) 내부를 들여다보거나, 전역 네임스페이스(Window 등)에서 참조되는 VM 내부 객체의 세부적인 메모리 사용을 분석할 수 있습니다 [10, 14].
-  - *Statistics View (통계 뷰):* 코드, 문자열, JS 배열, 시스템 객체 등에 할당된 메모리의 상대적 크기를 파이 차트로 나타냅니다 [10].
-- **Retainers (유지자) 추적:** 
-  스냅샷에서 특정 객체를 선택하면 하단의 Retainers 패널에 해당 객체를 메모리에 살려두고 있는 참조 체인(GC 루트로부터의 경로)이 표시됩니다 [1, 15]. 개발자는 이 체인을 역추적하여 제거되지 않은 이벤트 리스너나 타이머 등 메모리 누수의 근본적인 원인을 정확히 짚어낼 수 있습니다 [1, 16].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[Garbage Collection (GC)]], [[Memory Leak]], [[Shallow Size]], [[Retained Size]], [[Retainer Tree]]
-- **Projects/Contexts:** [[Chrome DevTools]], [[Node.js]], [[V8 Engine]]
-- **Contradictions/Notes:** 모든 데이터가 JavaScript 힙 스냅샷에 기록되는 것은 아닙니다. 네이티브 코드를 실행하는 Getter를 통해 구현된 속성이나 숫자와 같은 비문자열(non-string) 값은 스냅샷에 캡처되지 않습니다 [11]. 또한, 원시 힙 데이터에는 수천 개의 V8 내부 객체가 포함되므로, 실제 애플리케이션의 메모리 누수를 찾으려면 "Constructor(생성자)" 필터를 사용하여 분석 대상을 좁혀야 합니다 [17].
-
----
-*Last updated: 2026-04-19*
-- Raw Source: [[00_Raw/2026-04-20/Heap Snapshot.md]]
----
diff --git a/Programming & Language/Husky  lint-staged.md b/Programming & Language/Husky  lint-staged.md
deleted file mode 100644
index e09350fe..00000000
--- a/Programming & Language/Husky  lint-staged.md	
+++ /dev/null
@@ -1,30 +0,0 @@
----
-id: P-REINFORCE-AUTO-6F1BCF
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Husky  lint-staged"
----
-
-# [[Husky  lint-staged]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> Husky와 lint-staged는 개발자가 코드를 Git 저장소에 커밋하기 전에 코드의 품질과 스타일을 자동으로 검사하고 수정할 수 있도록 돕는 도구입니다 [1, 2]. Husky는 Git 훅(Git hooks)을 버전 관리 시스템에 포함시켜 팀원 전체가 쉽게 공유하고 관리할 수 있도록 해주는 훅 관리 레이어입니다 [3, 4]. lint-staged는 전체 코드베이스가 아닌 커밋을 위해 스테이징된(staged) 파일에 대해서만 특정 명령어(Linter, Formatter 등)를 실행하도록 오케스트레이션하여 검사 속도와 효율성을 높여줍니다 [3, 4]. 이 두 도구를 결합하여 사용하면 잘못된 코드가 저장소에 병합되는 것을 사전에 방지하고 일관된 코드 퀄리티를 효율적으로 유지할 수 있습니다 [5].
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[Git Hooks]], [[ESLint]], [[Prettier]], [[Continuous Integration (CI)]]
-- **Projects/Contexts:** [[Monorepo(Turborepo 등) 환경의 린트 관리]], [[프론트엔드 및 Node.js 개발 워크플로우]]
-- **Contradictions/Notes:** 소스에 따르면 lint-staged의 자체적인 기능을 사용할 때 스크립트 명령어 내에서 수동으로 `git add`를 추가해서는 안 됩니다. lint-staged가 충돌(race condition)을 방지하기 위해 파일의 자동 스테이징을 내부적으로 직접 처리하기 때문입니다 [13, 16]. 또한 lint-staged는 파일 필터링 역할을 하므로, `tsc`와 같이 전체 프로젝트 문맥이 필요한 도구를 적용할 때는 단순히 명령어를 추가하는 것이 아니라 파일 인자가 무시되도록 별도의 함수 설정을 사용해야 하는 등 도구의 성격에 맞게 분리 적용할 필요가 있습니다 [16, 20, 21].
-
----
-*Last updated: 2026-04-18*
-- Raw Source: [[00_Raw/2026-04-20/Husky & lint-staged.md]]
----
diff --git a/Programming & Language/Husky.md b/Programming & Language/Husky.md
deleted file mode 100644
index de6b7009..00000000
--- a/Programming & Language/Husky.md	
+++ /dev/null
@@ -1,36 +0,0 @@
----
-id: P-REINFORCE-AUTO-9068BA
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Husky"
----
-
-# [[Husky]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> Husky는 개발 프로젝트에서 Git 훅(Git hooks)을 쉽게 설정, 관리 및 팀원들과 공유할 수 있도록 지원하는 소프트웨어 도구입니다 [1]. 기본적으로 버전 관리 대상이 아닌 Git 훅의 한계를 극복하여 `.husky/`와 같은 추적 가능한 디렉토리를 통해 훅 스크립트를 관리하게 해줍니다 [1, 2]. 주로 `lint-staged`와 결합하여 커밋이나 푸시 전에 자동으로 코드 린팅(linting) 및 포맷팅을 수행하여 코드 품질을 강제하는 데 사용됩니다 [3, 4].
-
-## 📖 구조화된 지식 (Synthesized Content)
-*   **Git 훅의 한계 극복 및 구동 원리:** Git의 기본 훅은 `.git/hooks/` 디렉토리에 저장되어 버전 관리 도구에 의해 추적되지 않습니다. 이로 인해 새로운 팀원이 프로젝트를 클론할 때 훅이 자동으로 설정되지 않는 문제가 발생합니다 [1]. Husky는 Git의 `core.hooksPath` 속성을 사용하여 추적 가능한 디렉토리(예: `.husky/`)에 실제 훅 파일(셸 스크립트)을 생성하고 관리함으로써 이 문제를 해결합니다 [1, 2].
-*   **설치 및 자동화 설정:** `npx husky init` (또는 `husky-init`) 명령어를 실행하면 프로젝트 루트에 `.husky` 폴더가 생성되고 `package.json`에 `prepare` 스크립트가 추가됩니다 [5-7]. 이 `prepare` 스크립트는 팀원들이 로컬에서 `npm install`을 실행할 때 Husky 훅이 자동으로 설치되도록 보장하여 모든 팀원이 동일한 검사 환경을 갖추게 합니다 [5-7].
-*   **lint-staged와의 결합:** 전체 프로젝트 코드를 매번 검사하는 것은 많은 시간이 소요되므로, Husky의 `pre-commit` 훅 내부에서 `lint-staged`를 호출하는 방식이 현대적인 표준 설정으로 사용됩니다 [1, 8, 9]. 이 조합을 통해 커밋을 위해 스테이징된(staged) 파일에 대해서만 ESLint나 Prettier를 실행함으로써 1~2초 내에 검사를 완료할 수 있습니다 [1, 9].
-*   **검사 우회(Bypass) 및 환경 설정:** 개발 과정에서 미완성 코드를 커밋해야 하는 등 훅 실행을 건너뛰어야 할 때는 Git의 기본 기능인 `--no-verify` 플래그(예: `git commit --no-verify`)를 사용할 수 있습니다 [10, 11]. 또한 CI 서버나 프로덕션 환경 등 훅 설치 및 실행이 필요 없는 경우, `HUSKY=0` 환경 변수를 설정하여 Husky를 완전히 비활성화할 수 있습니다 [12].
-*   **예외 상황 및 트러블슈팅:** 
-    *   **GUI 및 버전 관리자 이슈:** SourceTree나 VS Code 같은 Git GUI 도구나 Node 버전 관리자(nvm, fnm 등)를 사용할 때 `PATH`가 제대로 초기화되지 않아 훅에서 명령어를 찾을 수 없는 오류(`command not found`)가 발생할 수 있습니다. Husky는 각 훅을 실행하기 전에 `~/.config/husky/init.sh`를 소싱(source)하여 이 문제를 우회할 수 있도록 지원합니다 [13, 14].
-    *   **서브모듈 및 중첩 패키지:** 모노레포나 서브모듈(Submodules) 구조에서는 최상위 루트가 아닌 하위 디렉토리에 패키지가 위치할 수 있습니다. Git은 기본적으로 리포지토리 루트에서 훅을 실행하므로, 이런 경우 `prepare` 스크립트 내에서 경로를 이동하거나(cd) 서브모듈의 컨텍스트 내에 Husky를 개별적으로 설치하여 동작하도록 구성해야 합니다 [14, 15].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[Git Hooks]], [[lint-staged]], [[ESLint]], [[Prettier]]
-- **Projects/Contexts:** [[CI/CD Pipeline]], [[Monorepo]], [[Submodules]]
-- **Contradictions/Notes:** 소스에 따르면, 많은 개발자가 Husky와 `lint-staged`를 혼동하여 하나의 덩어리로 생각하곤 합니다. 하지만 두 도구는 명확히 구분되어야 합니다. Husky는 단순히 Git의 기본 훅을 관리하고 연결하는 '배선(hook wiring)' 역할을 할 뿐 작업 실행기(task runner)가 아니며, 실제 변경된 파일 단위로 작업을 오케스트레이션 하는 것은 `lint-staged`의 역할입니다 [2, 4, 16].
-
----
-*Last updated: 2026-04-18*
-- Raw Source: [[00_Raw/2026-04-20/Husky.md]]
----
diff --git a/Programming & Language/IBM 가비지 컬렉션.md b/Programming & Language/IBM 가비지 컬렉션.md
deleted file mode 100644
index ab62f3a1..00000000
--- a/Programming & Language/IBM 가비지 컬렉션.md	
+++ /dev/null
@@ -1,42 +0,0 @@
----
-id: P-REINFORCE-AUTO-A6562D
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - IBM 가비지 컬렉션"
----
-
-# [[IBM 가비지 컬렉션]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> IBM의 가비지 컬렉션(GC)은 애플리케이션의 메모리 부족을 방지하기 위해 더 이상 필요하지 않은 Java 힙의 객체를 회수하는 자동화된 프로세스입니다 [1]. 전체 GC 과정은 일반적으로 도달 가능한 객체를 식별하는 마크(Mark), 도달할 수 없는 객체를 정리하는 스위프(Sweep), 힙의 단편화를 해결하는 압축(Compact)의 세 단계로 나뉩니다 [1]. GC 작업 중에는 애플리케이션 실행이 일시 중지되는 'stop-the-world (STW)' 현상이 발생할 수 있으며, 시스템은 애플리케이션 중단을 최소화하기 위해 동시(Concurrent) 또는 점진적(Incremental) 처리 기법 및 다양한 정책을 활용합니다 [1-3].
-
-## 📖 구조화된 지식 (Synthesized Content)
-- **가비지 컬렉션 주기 (GC Cycles)**
-  - **글로벌 GC 주기 (Global GC cycle):** 전체 Java 힙에서 작동하며 할당 실패나 메모리 임계값 도달과 같은 내부 메커니즘에 의해 암시적으로 트리거되거나, `System.gc()` 호출 등을 통해 명시적으로 트리거됩니다 [4].
-  - **부분 GC 주기 (Partial GC cycle):** 힙의 특정 부분에서만 작동하며, 선택된 GC 정책에 따라 암시적으로만 발생합니다 [4, 5].
-
-- **주요 GC 작업 (GC Operations)**
-  - **마크 작업 (Mark):** 루트 객체에서 시작하여 힙 내 도달 가능한 객체를 추적하고 식별합니다 [6, 7]. 비트 배열인 '마크 맵(Mark map)'을 사용해 객체 위치를 기록하며, 초기(Initial), 메인(Main), 최종(Final) 세 단계로 진행됩니다 [6, 7]. 성능 향상을 위해 보조 스레드를 통한 병렬 처리나 애플리케이션 스레드와 함께 작동하는 동시 마크(Concurrent mark) 처리를 수행할 수 있습니다 [2, 8].
-  - **스위프 작업 (Sweep):** 여유 메모리를 분석하고 해당 공간을 중앙 기록인 프리리스트(Freelist)에 연결하여 새로운 객체 할당이 가능하도록 메모리를 회수합니다 [9].
-  - **스캐빈지 작업 (Scavenge):** 'Nursery' 영역의 할당 실패 시 트리거되며 도달 가능한 객체를 새 공간이나 'Tenure' 영역으로 복사하여 유지합니다(`gencon` 정책에서 주로 사용) [10, 11].
-  - **복사 전달 작업 (Copy Forward):** 힙의 단편화된 영역을 비우기 위해 라이브 객체를 새로운 영역으로 이동시킵니다(`balanced` 정책에서 주로 사용) [11, 12].
-  - **압축 작업 (Compact):** 메모리 단편화를 제거하기 위해 객체를 이동시킵니다. 객체의 모든 참조를 업데이트해야 하는 비용이 매우 큰 작업이므로 기본적으로는 실행되지 않고 여유 공간이 극도로 부족하거나 특정 조건(-Xcompactgc 옵션 등)이 충족될 때만 발생합니다 [13, 14].
-
-- **약한 참조 처리 (Weak Reference Processing)**
-  - GC 주기 동안 소프트(Soft), 약한(Weak), 팬텀(Phantom) 참조를 처리하여 특정 참조가 유지되거나 삭제되도록 관리합니다 [14]. 소프트 참조는 메모리 부족 오류가 발생할 가능성이 있을 때만 지워지며, 약한 참조와 팬텀 참조는 참조 객체가 마크되지 않을 때 즉시 혹은 자동으로 지워집니다 [15].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[GC Policies (gencon, optavgpause, balanced)]], [[Stop-the-world (STW) Pause]], [[Mark, Sweep, and Compact Operations]]
-- **Projects/Contexts:** [[Eclipse OpenJ9™]], [[Java Object Heap]]
-- **Contradictions/Notes:** 애플리케이션 성능 최적화를 위해 동시 마크(Concurrent mark) 방식을 사용하면 STW 일시 중지 시간은 줄일 수 있지만, 쓰기 장벽(Write barrier) 작동으로 인한 추가 CPU 소비와 힙 락 할당 중 객체 추적에 따른 부하가 발생하는 트레이드오프(단점)가 존재합니다 [3]. 또한, 개발자가 `System.gc()`를 직접 호출하거나 finalizer를 이용해 GC를 통제하려 하면 오히려 애플리케이션 성능을 크게 저하시킬 수 있습니다 [5].
-
----
-*Last updated: 2026-04-19*
-- Raw Source: [[00_Raw/2026-04-20/IBM 가비지 컬렉션.md]]
----
diff --git a/Programming & Language/IFCjs.md b/Programming & Language/IFCjs.md
deleted file mode 100644
index cc581924..00000000
--- a/Programming & Language/IFCjs.md	
+++ /dev/null
@@ -1,36 +0,0 @@
----
-id: P-REINFORCE-AUTO-659684
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - IFCjs"
----
-
-# [[IFCjs]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> IFC.js는 대규모 기하학적 환경이나 건물 모델을 효율적으로 시각화하기 위해 개발되고 있는 프로젝트입니다 [1]. 메모리 소비를 줄이고 렌더링 속도(FPS)를 높이면서도 수많은 객체 중 개별 객체를 빠르게 검색하고 구성할 수 있는 렌더링 최적화를 목표로 합니다 [2]. 최근 최적화 아키텍처를 통해 100MB 이상의 대형 모델을 모바일에서도 원활하게 로드하는 성능을 달성했습니다 [3].
-
-## 📖 구조화된 지식 (Synthesized Content)
-- **대규모 렌더링 최적화의 과제:** 대규모 건물 모델 시각화에는 수천에서 수백만 개의 객체가 포함되기 때문에 메모리와 속도(Draw call)의 최적화가 필수적입니다 [2]. 
-- **기존 방식의 한계:** 
-  - 모든 객체를 `BufferGeometry`로 병합하는 방식은 드로우 콜을 최소화하지만, 의자 2개를 렌더링할 때 의자 1개보다 두 배의 RAM을 차지할 만큼 메모리 소모가 심하다는 문제가 있습니다 [2, 4].
-  - 반대로 `InstancedMesh`를 사용하는 방식은 메모리를 적게 쓰지만, 고유 객체와 재질의 수만큼 드로우 콜이 급증하여 대형 건물 모델에 적용하기 어렵습니다 [4, 5].
-- **하이브리드 시스템 'Fragment' 도입:** 이러한 한계를 극복하기 위해 IFC.js 개발진은 두 가지 방식의 장점을 동일한 인터페이스 뒤에 결합한 'Fragment'라는 시스템을 설계했습니다 [5]. 
-- **객체별 렌더링 전략:** 벽이나 바닥과 같이 고유하면서도 폴리곤 수가 적은(Low-poly) 객체들은 `BufferGeometry`로 병합하여 처리하고, 가구나 문, 창문과 같이 폴리곤 수가 많고(High-poly) 반복되는 객체들은 `InstancedMesh`를 생성하여 처리합니다 [6]. 
-- **결과 및 성과:** 이 시스템은 모든 파편(Fragment)이 비슷한 수의 정점과 드로우 콜을 가지도록 균형을 맞춰 효율성을 극대화하며, Autodesk Forge의 로딩 속도에 근접하는 수준의 성능을 입증했습니다 [3, 6].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[BufferGeometry]], [[InstancedMesh]], [[Fragment]], [[Draw call]]
-- **Projects/Contexts:** [[대규모 기하학적 환경 시각화]], [[Autodesk Forge]]
-- **Contradictions/Notes:** 소스에 명시적인 모순은 없으나, 모델 렌더링에 있어 `BufferGeometry` 병합 방식(메모리 소모 큼)과 `InstancedMesh` 방식(드로우 콜 증가) 간의 근본적인 트레이드오프(Trade-off)가 존재하며, IFC.js는 이를 해결하기 위해 두 방식을 혼합한 하이브리드 솔루션을 제안합니다 [2, 4, 5].
-
----
-*Last updated: 2026-04-19*
-- Raw Source: [[00_Raw/2026-04-20/IFC.js.md]]
----
diff --git a/Programming & Language/Immersive Sim Genre.md b/Programming & Language/Immersive Sim Genre.md
deleted file mode 100644
index d5d876e6..00000000
--- a/Programming & Language/Immersive Sim Genre.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-33177A
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Immersive Sim Genre"
----
-
-# [[Immersive Sim Genre]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Immersive Sim Genre.md]]
----
diff --git a/Programming & Language/Incremental Marking.md b/Programming & Language/Incremental Marking.md
deleted file mode 100644
index 9599e725..00000000
--- a/Programming & Language/Incremental Marking.md	
+++ /dev/null
@@ -1,40 +0,0 @@
----
-id: P-REINFORCE-AUTO-A29470
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Incremental Marking"
----
-
-# [[Incremental Marking]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> Incremental Marking은 가비지 컬렉션의 마킹 단계를 한 번의 긴 일시 정지(stop-the-world)로 처리하지 않고, 애플리케이션 실행과 교차하여 여러 개의 짧은 작업 단위로 나누어 수행하는 메모리 관리 기법입니다 [1, 2]. 이 방식은 가비지 컬렉션에 소요되는 전체 시간을 줄이지는 않지만, 작업을 시간에 따라 분산시킴으로써 메인 스레드의 응답성을 크게 향상시킵니다 [2]. 결과적으로 모바일 기기 등에서 발생할 수 있는 긴 지연을 방지하고 애플리케이션이 사용자 입력 및 애니메이션에 원활하게 반응할 수 있도록 돕습니다 [2, 3].
-
-## 📖 구조화된 지식 (Synthesized Content)
-- **트리거 및 기본 작동 원리:** 
-  Incremental Marking은 힙(heap)의 크기가 특정 임계값에 도달할 때 활성화됩니다 [3, 4]. 활성화된 이후에는 애플리케이션이 메모리를 할당할 때마다 짧은 마킹 단계(step)가 실행되어, 객체의 생성 속도에 맞춰 마킹 프로세스가 보조를 맞추게 됩니다 [1, 4]. 일반적인 마킹과 마찬가지로 깊이 우선 탐색(Depth-First-Search) 기반이며, 객체의 상태를 흰색(미발견), 회색(발견되었으나 이웃 객체 미처리), 검은색(완전 처리됨)으로 분류하는 시스템을 사용합니다 [3]. 이 방식을 통해 과거 500~1000ms에 달하던 긴 가비지 컬렉션 지연 시간이 5~10ms 수준의 매우 짧은 일시 정지로 쪼개집니다 [3, 4].
-
-- **객체 그래프의 동적 변화 및 Write Barrier 방어:** 
-  점진적 마킹의 가장 큰 난제는 마킹 작업 사이사이에 자바스크립트가 실행되므로 힙 내의 객체 그래프 구조가 계속 변할 수 있다는 점입니다 [2, 5]. 특히 완전히 검사가 끝난 '검은색' 객체에서 아직 발견되지 않은 '흰색' 객체로의 새로운 포인터가 생성될 경우, 살아있는 흰색 객체가 가비지로 잘못 분류될 위험이 있습니다 [5]. V8 엔진은 이를 방지하기 위해 '쓰기 장벽(Write Barrier)'을 사용하여 검은색에서 흰색으로 향하는 포인터 생성을 감지합니다 [5]. 이러한 포인터가 감지되면 해당 검은색 객체를 다시 회색으로 변경하고 마킹 덱(deque)에 밀어넣어 재검색되도록 보장합니다 [5].
-
-- **Lazy Sweeping으로의 전환:** 
-  모든 객체의 생존 여부가 식별되어 Incremental Marking 작업이 완료되면, V8은 한꺼번에 메모리를 지우지 않고 필요에 따라 페이지 단위로 메모리를 해제하는 'Lazy Sweeping' 단계를 시작하여 남은 오버헤드를 분산시킵니다 [6, 7].
-
-- **IBM JVM에서의 적용 사례:** 
-  자바스크립트 엔진 외에도 IBM JVM의 균형(balanced) GC 정책에서 '점진적 동시 마킹(Incremental concurrent mark processing)'이 활용됩니다 [8, 9]. 이는 글로벌 마킹 작업을 전체 힙에 걸쳐 점진적으로 수행하며, 부분적인 GC 사이클과 교차되어 긴 정지 시간을 방지합니다 [8].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[Garbage Collection]], [[Write Barrier]], [[Lazy Sweeping]], [[Mark-Sweep]], [[Orinoco]]
-- **Projects/Contexts:** [[V8 JavaScript Engine]], [[IBM OpenJ9]]
-- **Contradictions/Notes:** V8 엔진의 Incremental Marking은 메인 스레드가 자바스크립트 실행 중간에 간헐적으로 마킹 작업을 나누어 수행하는 구조이지만 [2], IBM JVM의 Incremental concurrent mark 작업에서는 애플리케이션 스레드가 객체 추적에 관여하지 않으며 오직 백그라운드 스레드만이 사용된다는 기술적 차이가 존재합니다 [8].
-
----
-*Last updated: 2026-04-19*
-- Raw Source: [[00_Raw/2026-04-20/Incremental Marking.md]]
----
diff --git a/Programming & Language/Index Masking.md b/Programming & Language/Index Masking.md
deleted file mode 100644
index 4d388bd0..00000000
--- a/Programming & Language/Index Masking.md	
+++ /dev/null
@@ -1,32 +0,0 @@
----
-id: P-REINFORCE-AUTO-42C840
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Index Masking"
----
-
-# [[Index Masking]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> Index Masking은 Spectre 및 Meltdown과 같은 캐시 사이드 채널 공격을 방어하기 위해 브라우저 엔진에 도입된 보안 완화(security mitigation) 기법 중 하나이다 [1, 2]. 이 기법은 길이(length)를 다음 2의 거듭제곱으로 올림한 후 1을 빼는 방식으로 마스크(mask)를 계산하여 적용하는 분기 없는(branchless) 보안 검사 방식이다 [3, 4]. 비록 경계를 벗어난(out-of-bounds) 읽기를 완전히 막지는 못하지만, 공격자가 임의의 메모리에 접근하는 것을 방지하는 역할을 한다 [4].
-
-## 📖 구조화된 지식 (Synthesized Content)
-- **동작 원리 및 한계:** Index Masking은 데이터의 길이를 다음 2의 거듭제곱으로 올림하고 1을 빼는 방식으로 마스크를 계산하여 사용한다 [4]. 이 방법은 OOB(Out-of-Bounds) 접근에 대한 완벽한 해결책은 아니며 여전히 범위를 벗어난 읽기를 허용할 수 있지만, 임의의 메모리 영역(arbitrary memory)에 대한 접근은 확실하게 차단한다 [4].
-- **보안을 위한 아키텍처 도입:** Spectre 및 Meltdown 공격을 방어하기 위해 WebKit을 비롯한 웹 브라우저 엔진들은 기존의 분기(branch) 기반 보안 검사의 한계를 보완하고자 Index Masking과 Pointer Poisoning 같은 분기 없는(branchless) 보안 검사 방식을 도입하였다 [1, 3, 4].
-- **성능에 미치는 영향:** 이 보안 완화 기법은 자바스크립트 엔진 및 JIT(Just-In-Time) 컴파일러가 수행하는 그래픽 실행의 크리티컬 패스에 추가 명령어를 도입하므로, 기본 마이크로 지연 시간(base micro-latency)을 약간 증가시킨다 [5]. 그러나 WebKit의 테스트에 따르면 Speedometer 및 ARES-6 벤치마크에서는 측정 가능한 성능 영향이 없었으며, JetStream 벤치마크에서는 성능에 미치는 영향이 2.5% 미만인 것으로 확인되었다 [4].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[Spectre and Meltdown]], [[Pointer Poisoning]], [[Branchless Security Checks]]
-- **Projects/Contexts:** [[WebKit]], [[Micro-latency Measurement in Web Graphics Pipelines]]
-- **Contradictions/Notes:** 소스 [5]에서는 Index Masking 기술이 그래픽 실행의 크리티컬 패스에 명령어를 추가하여 마이크로 지연 시간을 증가시킨다고 설명하지만, 소스 [4]의 벤치마크 결과에 따르면 실제 환경의 주요 성능 테스트(Speedometer 등)에서는 그 영향이 측정되지 않거나 2.5% 미만으로 매우 미미하다고 보고합니다.
-
----
-*Last updated: 2026-04-19*
-- Raw Source: [[00_Raw/2026-04-20/Index Masking.md]]
----
diff --git a/Programming & Language/Industry 40_Smart Manufacturing.md b/Programming & Language/Industry 40_Smart Manufacturing.md
deleted file mode 100644
index b98cc7a7..00000000
--- a/Programming & Language/Industry 40_Smart Manufacturing.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-84B460
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Industry 40_Smart Manufacturing"
----
-
-# [[Industry 40_Smart Manufacturing]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Industry 4.0_Smart Manufacturing.md]]
----
diff --git a/Programming & Language/InstancedMesh Performance Bottlenecks.md b/Programming & Language/InstancedMesh Performance Bottlenecks.md
deleted file mode 100644
index e33ecf6e..00000000
--- a/Programming & Language/InstancedMesh Performance Bottlenecks.md	
+++ /dev/null
@@ -1,46 +0,0 @@
----
-id: P-REINFORCE-AUTO-F035BF
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - InstancedMesh Performance Bottlenecks"
----
-
-# [[InstancedMesh Performance Bottlenecks]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-* **시야 절두체 컬링(Frustum Culling)의 비효율성**
-  `InstancedMesh`는 단일 바운딩 볼륨(Bounding Volume)을 기준으로 렌더링 여부를 결정하므로, **화면에 단 하나의 인스턴스만 보여도 GPU는 보이지 않는 나머지 수만 개 인스턴스의 정점 변환 연산을 강제로 수행**해야 합니다 [1, 2]. 이를 해결하기 위해 CPU(자바스크립트)에서 매 프레임 개별 인스턴스의 가시성을 수학적으로 판별하여 버퍼를 재구성할 수 있지만, 이 경우 막대한 CPU 연산 비용과 병목이 발생하여 본래의 최적화 취지를 훼손합니다 [3, 4].
-
-* **자동 깊이 정렬(Sorting) 부재 및 오버드로우(Overdraw)**
-  인스턴스들은 인스턴스 버퍼에 기록된 순서대로만 그려지며, 거리에 따른 자동 정렬을 지원하지 않습니다 [5, 6]. 이로 인해 불투명 객체의 경우 뒤에 가려진 픽셀을 반복해서 계산하는 **오버드로우가 발생하여 프래그먼트 셰이더(Fragment Shader) 성능을 심각하게 저하시킵니다** [5-7]. 특히 투명 객체는 알파 블렌딩 오류를 막기 위해 '뒤에서 앞으로(Back-to-Front)' 정렬해야 하는데, 동적 씬에서 이를 위해 CPU 기반의 재정렬(예: Radix Sort)을 매 프레임 수행하면 메인 스레드에 치명적인 부하가 걸립니다 [8].
-
-* **메모리 대역폭 및 동적 업데이트 한계**
-  매 프레임 위치나 색상이 바뀌는 동적 씬에서는 수많은 인스턴스의 $4 \times 4$ 변환 행렬 데이터를 매번 CPU에서 GPU로 전송해야 합니다. 예컨대 200만 개의 인스턴스 변환 시 초당 약 7.68GB/s의 대역폭을 점유하여 시스템 버스에 과부하를 일으킵니다 [9, 10]. 또한, 생성 및 삭제가 빈번해 버퍼 크기를 동적으로 재할당해야 할 경우, 가비지 컬렉터(GC)가 작동하면서 프레임이 일시적으로 멈추는 지연 현상(Stuttering)을 유발합니다 [11].
-
-* **지오메트리 및 텍스처 다양성 확보의 어려움**
-  하나의 `InstancedMesh`는 오직 하나의 `BufferGeometry`와 `Material`만 사용할 수 있으므로, 모델 종류가 많아지면 결국 드로우 콜이 기하급수적으로 증가합니다 [12-14]. 여러 인스턴스에 각기 다른 텍스처를 입히기 위해 텍스처 아틀라스(Texture Atlas)를 사용할 경우, 밉맵(Mipmap) 생성 시 인접 텍스처 간에 색이 섞이는 경계선 블리딩(Edge Bleeding) 문제가 발생하며 셰이더 구성이 매우 복잡해집니다 [15-17].
-
-* **피킹(Picking) 및 상호작용(Raycasting) 지연**
-  `InstancedMesh`에 대한 CPU 레이캐스팅은 광선(Ray)이 각 인스턴스의 변환 행렬을 개별적으로 역산해야 하므로 상호작용 시 즉각적인 반응을 어렵게 합니다 [18, 19]. 셰이더에서 애니메이션(예: 바람, 물리 연산)을 적용했다면 CPU는 실제 위치를 추적할 수 없어 피킹이 어긋나며, 대안으로 GPU 픽셀 피킹을 사용하더라도 `readPixels` 함수 호출 시 GPU 파이프라인 동기화 지연(Sync stall)으로 인해 프레임 저하가 일어납니다 [18, 20].
-
-* **스킨드 애니메이션(Skinned Mesh) 연동 불가**
-  기본적으로 본(Bone) 기반의 스킨드 애니메이션을 지원하지 않습니다 [21, 22]. 수많은 인스턴스에 개별적인 포즈를 적용하려면 각 인스턴스별 본 행렬 데이터를 텍스처 등을 통해 전부 GPU로 전송해야 하며, 데이터의 폭발적 증가로 인해 일반적인 버퍼 제한을 초과하게 되는 물리적 한계에 부딪힙니다 [21].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[Frustum Culling]], [[Overdraw]], [[Draw Call]], [[BatchedMesh]], [[Texture Atlas]]
-- **Projects/Contexts:** [[InstancedMesh2 library]], [[Three.js WebGPU Renderer]], [[WebGL multi_draw extension]]
-- **Contradictions/Notes:** 많은 렌더링 상황에서 `InstancedMesh`가 만능 최적화 기법으로 여겨지지만, 실제 벤치마크 사례에서는 드로우 콜을 1회로 줄였음에도 불구하고 오버드로우 및 GPU 프래그먼트 병목 때문에 개별 메쉬나 `BatchedMesh` 방식보다 오히려 렌더링 시간(Frame Time)이 느려지거나 성능이 저하되는 모순적인 결과가 발생하기도 합니다 [5, 6, 23].
-
----
-*Last updated: 2026-04-19*
-- Raw Source: [[00_Raw/2026-04-20/InstancedMesh Performance Bottlenecks.md]]
----
diff --git a/Programming & Language/InstancedMesh 동적 버퍼 확장.md b/Programming & Language/InstancedMesh 동적 버퍼 확장.md
deleted file mode 100644
index 0f612aa5..00000000
--- a/Programming & Language/InstancedMesh 동적 버퍼 확장.md	
+++ /dev/null
@@ -1,37 +0,0 @@
----
-id: P-REINFORCE-AUTO-D6CCE0
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - InstancedMesh 동적 버퍼 확장"
----
-
-# [[InstancedMesh 동적 버퍼 확장]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> InstancedMesh 동적 버퍼 확장은 렌더링 중 인스턴스 수가 초기 할당된 용량(Capacity)을 초과할 때, 시스템이 새로운 더 큰 버퍼를 할당하고 기존 데이터를 복사하는 과정을 의미한다 [1]. 이 과정에서 수십 메가바이트 크기의 배열이 빈번하게 생성되고 파괴되어 가비지 컬렉션(GC)을 유발하며, 이는 프레임 지연(스터터링)이나 메모리 할당 오류로 이어진다 [1, 2]. 결과적으로 이러한 성능 병목을 피하기 위해 개발자들은 런타임 확장을 피하고, 최대 예상 인스턴스 수에 맞춘 버퍼 사전 할당이나 객체 풀링 전략을 권장하고 있다 [1, 3].
-
-## 📖 구조화된 지식 (Synthesized Content)
-- **동적 버퍼 확장의 발생 원리**
-  InstancedMesh는 객체 수가 동적으로 변하는 환경(예: 적들이 수시로 생성되거나 파괴되는 상황)에서 초기 용량을 넘어서면 새로운 버퍼를 동적으로 확장해야 한다 [1]. 이때 기존 데이터를 새롭고 더 큰 버퍼로 복사하는 작업이 필연적으로 수반된다 [1].
-
-- **성능 저하 및 메모리 문제**
-  동적 버퍼 확장은 메모리 할당 빈도가 매우 잦아 CPU 부하를 극도로 높이며, 데이터 전송 효율을 떨어뜨린다 [1]. 구형 `TypedArray` 데이터가 메모리에서 빈번하게 해제되는 과정에서 자바스크립트 가비지 컬렉터(GC)가 작동하여 프레임이 일시적으로 멈추는 현상(Stuttering)이 발생한다 [1]. A-Frame 기반 구현 등 일부 환경에서는 용량 증가 시 이전 InstancedMesh를 깔끔하게 해제(dispose)하지 못해 작은 메모리 누수(Memory Leak)가 발생할 우려도 존재한다 [4]. Needle Engine 환경에서도 버퍼가 동적으로 확장될 때 "[Instancing] Growing Buffer"라는 로그와 함께 렌더링이 일시적으로 수 초간 멈추는 성능 병목이 관찰되었다 [2].
-
-- **최적화 및 대안 전략**
-  이러한 성능 하락을 방지하려면 런타임에 동적으로 버퍼를 확장하는 대신, 앱 시작 시점이나 로드 시 최대 예상 인스턴스 수에 맞춰 충분한 크기의 버퍼를 미리 할당(Preallocate)하는 방식이 권장된다 [3, 5]. 또한, 대규모 프로젝트에서는 예측 불가능한 버퍼 확장을 막기 위해 사전에 엄격한 메모리 예산을 수립해야 한다 [1]. 메모리 할당 및 해제의 오버헤드를 최소화하기 위해 한 번 생성된 인스턴스 데이터를 재사용하는 객체 풀링(Object Pooling)이나 링 버퍼(Ring Buffer) 구조를 채택하는 것이 효율적이다 [1].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[InstancedMesh]], [[가비지 컬렉션 (Garbage Collection)]], [[객체 풀링 (Object Pooling)]], [[버퍼 사전 할당 (Buffer Preallocation)]]
-- **Projects/Contexts:** [[Needle Engine]], [[A-Frame (instanced-mesh 컴포넌트)]], [[실시간 웹 그래픽스 최적화]]
-- **Contradictions/Notes:** 예측 불가능한 다량의 객체를 렌더링하려면 동적 확장이 필수적인 기능처럼 보이나, 실제 렌더링 환경에서는 이 과정이 프레임 드랍과 메모리 누수 위험 등 높은 리스크를 수반하므로 오히려 고정 용량 할당이나 풀링을 통해 원천적으로 확장을 회피하는 것이 강력히 권장된다 [1, 3, 4].
-
----
-*Last updated: 2026-04-19*
-- Raw Source: [[00_Raw/2026-04-20/InstancedMesh 동적 버퍼 확장.md]]
----
diff --git a/Programming & Language/InstancedMesh 사용 시 드로우 콜 최적화의 한계점 사례 연구.md b/Programming & Language/InstancedMesh 사용 시 드로우 콜 최적화의 한계점 사례 연구.md
deleted file mode 100644
index c8d36b10..00000000
--- a/Programming & Language/InstancedMesh 사용 시 드로우 콜 최적화의 한계점 사례 연구.md	
+++ /dev/null
@@ -1,46 +0,0 @@
----
-id: P-REINFORCE-AUTO-88CEC2
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - InstancedMesh 사용 시 드로우 콜 최적화의 한계점 사례 연구"
----
-
-# [[InstancedMesh 사용 시 드로우 콜 최적화의 한계점 사례 연구]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> InstancedMesh는 단일 드로우 콜(Draw Call)로 동일한 기하학적 구조와 재질을 가진 수많은 객체를 렌더링하여 CPU 오버헤드를 획기적으로 줄이는 최적화 기술입니다 [1, 2]. 그러나 실무 환경에서는 지오메트리 단일성 제약, 시야 절두체 컬링(Frustum Culling)의 비효율성, 오버드로우(Overdraw), 동적 데이터 갱신 시의 메모리 대역폭 포화 등 여러 구조적 한계를 드러냅니다 [3-7]. 본 사례 연구는 이러한 한계들로 인해 드로우 콜 횟수의 감소가 반드시 전반적인 렌더링 프레임 레이트(FPS) 상승으로 이어지지는 않음을 실증적으로 분석합니다 [3].
-
-## 📖 구조화된 지식 (Synthesized Content)
-*   **드로우 콜 최적화 원리와 맹점**
-    InstancedMesh는 GPU 메모리에 단일 정점 버퍼를 업로드하고 개별 인스턴스의 변환 행렬만을 속성으로 관리하여 한 번의 명령으로 수천 개의 객체를 병렬 복제합니다 [1, 2]. 하지만 **모든 인스턴스가 반드시 동일한 기하학적 데이터(BufferGeometry)와 재질(Material)을 공유해야 하므로 자산의 다양성을 확보하기 어렵습니다** [4]. 개별 인스턴스에 다른 텍스처를 적용하기 위해 텍스처 아틀라스(Texture Atlas)를 사용하면 경계선 블리딩(Edge Bleeding)이 발생할 수 있으며, 텍스처 배열(Texture Array)은 해상도 제약을 수반해 셰이더 복잡도를 높입니다 [8].
-
-*   **시야 절두체 컬링(Frustum Culling)의 비효율성**
-    InstancedMesh의 컬링은 전체 인스턴스를 포함하는 거대한 바운딩 볼륨을 기준으로 단 한 번만 수행되는 '전부 아니면 전무' 방식으로 작동합니다 [5]. 이로 인해 **단 하나의 객체만 시야에 있어도 화면 밖의 수많은 객체에 대한 정점 변환 연산이 강제되어 GPU를 크게 낭비합니다** [5]. 이를 피하고자 자바스크립트 수준에서 CPU 기반의 수동 개별 컬링을 구현하면 대규모 배열 조작으로 인해 메인 스레드에 극심한 병목이 유발됩니다 [9].
-
-*   **오버드로우(Overdraw)와 렌더링 정렬의 부재**
-    InstancedMesh는 버퍼에 저장된 순서대로만 렌더링되며, 불투명 객체의 조기 깊이 판정(Early-Z)을 위한 '앞에서 뒤로' 자동 정렬 기능이 없습니다 [6]. **드로우 콜이 1회로 최적화되었음에도 불구하고, 무작위 정렬로 인한 막대한 오버드로우 비용 때문에 GPU 프래그먼트 병목이 발생하여 오히려 일반 메쉬 방식보다 FPS가 떨어질 수 있습니다** [6]. 투명/반투명 객체는 '뒤에서 앞으로' 렌더링되어야 시각적 오류가 없으나 동적인 순서 변경이 지원되지 않으며, 강제로 재정렬(Radix Sort 등)을 수행하면 CPU에 치명적인 부하를 줍니다 [10].
-
-*   **메모리 대역폭 임계점과 데이터 전송 병목**
-    각 인스턴스의 위치 및 회전 정보는 64바이트의 부동 소수점 행렬로 구성됩니다 [7]. **대규모 씬(예: 200만 개 인스턴스)에서 매 프레임 객체들이 동적으로 움직여 버퍼를 갱신해야 할 경우, 수 GB/s 단위의 막대한 데이터가 CPU에서 GPU로 이동해야 하므로 PCIe 대역폭을 포화시킵니다** [7]. 또한 할당된 버퍼 용량을 초과해 새 버퍼를 동적 할당할 때는 가비지 컬렉션(GC)이 작동해 순간적인 프레임 스터터링(Stuttering)을 유발합니다 [11].
-
-*   **상호작용(Picking) 및 애니메이션 연동의 한계**
-    대규모 인스턴스에 대해 사용자가 객체를 선택하는 **CPU 기반 피킹(Raycasting)을 시도하면 수만 번의 행렬 역산이 발생하여 즉각적인 반응성이 저해됩니다** [12]. GPU 픽셀 기반 피킹은 파이프라인 동기화 지연(Sync stall)과 오클루전(Occlusion) 한계가 있습니다 [13]. 또한 본(Bone) 행렬 기반의 **스킨드 메쉬(Skinned Mesh) 애니메이션을 기본 지원하지 않아**, 인스턴스마다 고유한 본 행렬을 전달하려 하면 버퍼 크기 제한을 초과하게 됩니다 [14].
-
-*   **대안 기술 및 최적화 전략**
-    InstancedMesh의 한계를 보완하기 위해 서로 다른 기하학적 구조를 수용하고 개별 컬링/가시성 제어가 가능한 **`BatchedMesh`**가 활용되고 있으나, 이 역시 지나치게 많은 삼각형을 처리할 때는 버퍼 패킹 오버헤드가 발생합니다 [15]. 궁극적으로는 **WebGPU의 컴퓨트 셰이더(Compute Shader)를 도입하여 가시성 판별과 오클루전 처리를 GPU 내부에서 해결하는 GPU 주도 렌더링(Indirect Draw) 방식**이 강력한 대안으로 부상하고 있습니다 [16, 17].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[Frustum Culling]], [[Overdraw]], [[BatchedMesh]], [[WebGPU Compute Shader]], [[Texture Atlas]], [[Garbage Collection (GC)]]
-- **Projects/Contexts:** [[대규모 웹 그래픽스 프로젝트]], [[CAD 렌더링 최적화]], [[BIM 모델 렌더링]]
-- **Contradictions/Notes:** 소스에 따르면 InstancedMesh 기술은 드로우 콜을 획기적으로 줄여 CPU 부담을 최소화하지만, 자체적인 정렬 부재와 컬링의 한계로 인해 조명 연산이 복잡한 환경에서는 오버드로우를 유발하여 결과적으로 GPU 픽셀 처리 성능을 상회하게 만들어 전체 FPS를 하락시킬 수 있다는 모순된 현상이 발생함을 강력히 지적합니다 [6]. 또한 대안으로 제시되는 BatchedMesh 역시 드로우 콜을 줄일 수는 있으나, 극한의 대규모 삼각형 렌더링 시에는 버퍼 패킹 비용이 오히려 일반 메쉬 렌더링보다 낮은 성능을 보이는 병목 사례가 보고됩니다 [15].
-
----
-*Last updated: 2026-04-19*
-- Raw Source: [[00_Raw/2026-04-20/InstancedMesh 사용 시 드로우 콜 최적화의 한계점 사례 연구.md]]
----
diff --git a/Programming & Language/InstancedMesh 최적화.md b/Programming & Language/InstancedMesh 최적화.md
deleted file mode 100644
index 4801fb47..00000000
--- a/Programming & Language/InstancedMesh 최적화.md	
+++ /dev/null
@@ -1,46 +0,0 @@
----
-id: P-REINFORCE-AUTO-7D070F
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - InstancedMesh 최적화"
----
-
-# [[InstancedMesh 최적화]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> [[InstancedMesh 최적화]]는 동일한 기하학적 구조(Geometry)와 재질(Material)을 가진 수많은 객체를 단 한 번의 드로우 콜(Draw Call)로 GPU에 전달하여 렌더링 성능을 극대화하는 기법입니다 [1], [2]. 수천, 수만 개의 반복적인 객체(나무, 풀, 파티클 등)를 렌더링할 때 CPU의 명령 발행 오버헤드를 대폭 줄이고 메모리 사용량을 최소화할 수 있습니다 [3], [4], [5]. 그러나 전체 인스턴스에 대한 전역적 시야 절두체 컬링, 개별 객체의 깊이 정렬 부재로 인한 오버드로우 등 구조적 한계가 존재하므로, 프로젝트의 특성과 병목 구간에 맞춘 전략적인 도입이 필요합니다 [6], [7].
-
-## 📖 구조화된 지식 (Synthesized Content)
-*   **드로우 콜 및 메모리 최적화 원리**
-    *   InstancedMesh는 GPU 메모리에 단 하나의 정점 버퍼만 업로드하고, 각 인스턴스에 고유하게 적용될 변환 행렬(위치, 회전, 축척) 및 색상 정보를 별도의 인스턴스 속성(Instance Attribute)으로 관리합니다 [2].
-    *   이 기술을 사용하면 일반 메쉬로 수천 번 호출해야 할 드로우 콜을 1회로 줄일 수 있어, CPU 병목 현상을 해소하고 시스템 메모리 및 VRAM을 획기적으로 절약할 수 있습니다 [8], [1], [9].
-    *   개별 인스턴스의 변환 행렬이나 색상을 변경(`setMatrixAt`, `setColorAt`)한 후에는 반드시 `needsUpdate` 속성을 `true`로 설정해야 렌더링 파이프라인에 반영됩니다 [10], [11]. 동적으로 인스턴스가 이동한 경우, 정확한 레이캐스팅(Picking) 및 컬링을 위해 `computeBoundingSphere()`와 `computeBoundingBox()`를 호출하여 바운딩 볼륨을 갱신해야 합니다 [12], [13], [14].
-
-*   **구조적 한계 및 성능 병목 요인**
-    *   **컬링(Culling)의 비효율성:** InstancedMesh는 엔진 수준에서 단일 객체로 취급되므로, 개별 인스턴스 단위가 아닌 전체를 아우르는 거대한 바운딩 볼륨을 기준으로 단 한 번의 시야 절두체 컬링(Frustum Culling)을 수행합니다 [15]. 이로 인해 시야 밖의 수많은 객체에 대해서도 불필요한 GPU 정점 연산이 강제될 수 있습니다 [15], [16].
-    *   **정렬 부재와 오버드로우(Overdraw):** 카메라 거리에 따른 자동 정렬 기능을 제공하지 않기 때문에, 뒤에 가려진 픽셀 연산을 조기에 종료(Early-Z)하지 못해 오버드로우가 발생합니다 [17], [18]. 특히 투명/반투명 객체 렌더링 시에는 깊이 정렬이 뒤섞여 시각적 오류를 초래합니다 [19].
-    *   **메모리 대역폭 한계:** 애니메이션 등으로 매 프레임 수백만 개의 인스턴스 변환 행렬(인스턴스당 64바이트)을 갱신해야 할 경우, 데이터 전송량이 시스템 버스 대역폭을 포화시켜 프레임 지연(Stuttering)을 유발할 수 있습니다 [20], [21].
-    *   **다양성 표현의 제약:** 단일 지오메트리와 단일 재질만 참조할 수 있어 다양한 에셋을 표현하기 어렵습니다 [22]. 개별 인스턴스에 서로 다른 텍스처를 적용하려면 [[Texture Atlas]]나 [[데이터 배열 텍스처(Data Array Textures)]]를 활용하고 UV 오프셋을 조정하는 추가적인 셰이더 조작이 강제됩니다 [23], [24], [25].
-
-*   **한계 극복을 위한 개선 및 대안 전략**
-    *   **공간 분할 기반 그룹화:** 모든 객체를 하나의 거대한 InstancedMesh로 묶기보다는, 공간적으로 인접한 객체끼리 소규모(100~500개)로 분할하여 관리하면 절두체 컬링의 정밀도를 높여 GPU 연산 낭비를 줄일 수 있습니다 [7].
-    *   **InstancedMesh2 및 BatchedMesh 활용:** 단일 지오메트리 제약이 문제가 된다면, 서로 다른 지오메트리를 하나의 드로우 콜로 묶어주는 [[BatchedMesh]] 사용이 권장됩니다 [26], [27]. 또한, 커뮤니티 생태계의 `InstancedMesh2` 라이브러리를 활용하면 개별 인스턴스의 프러스텀 컬링, 정렬, [[Level of Detail (LOD)]], BVH 기반의 빠른 레이캐스팅, 스킨드 애니메이션 최적화 등의 기능을 확장 적용할 수 있습니다 [28], [29], [30].
-    *   **WebGPU 컴퓨트 셰이더 도입:** WebGPU 환경에서는 GPU가 직접 가시성 판단과 컬링을 처리하여 CPU와 GPU 간의 통신 비용을 "0"에 수렴하게 하는 간접 그리기(Indirect Draw) 방식이 차세대 대안으로 떠오르고 있습니다 [31].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[Draw Call]], [[Frustum Culling]], [[BatchedMesh]], [[Texture Atlas]], [[Level of Detail (LOD)]], [[Overdraw]]
-- **Projects/Contexts:** [[Three.js]], [[WebGL/WebGPU Rendering]], [[Babylon.js]], [[Unity GPU Instancing]]
-- **Contradictions/Notes:** 
-  * "InstancedMesh를 사용하면 항상 성능이 향상된다고 가정하기 쉽지만, 소스는 매우 단순한 기하학(예: 단일 삼각형)의 경우 인스턴싱 변환 행렬 데이터를 처리하는 오버헤드가 더 커서 단순히 지오메트리를 병합(Merging)하는 방식이 오히려 프레임 레이트 측면에서 유리할 수 있다고 주장합니다 [32], [33]."
-  * "드로우 콜 수가 극적으로 감소함에도 불구하고, 5,000개 수준의 객체 환경에서는 인스턴스 정렬 부재로 인한 오버드로우 비용이 CPU 이득을 상회하여 일반 메쉬 렌더링보다 낮은 FPS를 기록할 수 있다고 경고합니다 [18]."
-
----
-*Last updated: 2026-04-19*
-- Raw Source: [[00_Raw/2026-04-20/InstancedMesh 최적화.md]]
----
diff --git a/Programming & Language/InstancedMesh.md b/Programming & Language/InstancedMesh.md
deleted file mode 100644
index 72802184..00000000
--- a/Programming & Language/InstancedMesh.md	
+++ /dev/null
@@ -1,38 +0,0 @@
----
-id: P-REINFORCE-AUTO-354B99
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - InstancedMesh"
----
-
-# [[InstancedMesh]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> InstancedMesh는 동일한 기하학적 구조(Geometry)와 재질(Material)을 공유하는 수많은 객체를 단 한 번의 드로우 콜(Draw call)로 렌더링할 수 있게 해주는 특수 메쉬이다 [1, 2]. 각 인스턴스는 고유한 변환 행렬(위치, 회전, 축척)과 색상을 가질 수 있으며, 이를 통해 CPU 오버헤드를 획기적으로 줄이고 렌더링 성능을 향상시킨다 [2-4]. 나무, 풀, 바위와 같이 형태가 동일한 대규모 객체 군집을 렌더링할 때 주로 사용되며, 메모리 소비도 최소화할 수 있는 강력한 최적화 도구이다 [5-7].
-
-## 📖 구조화된 지식 (Synthesized Content)
-* **작동 원리 및 성능 이점:** 
-  InstancedMesh는 GPU 메모리에 단 하나의 정점 버퍼(Vertex Buffer)를 업로드하고, 각 인스턴스마다 적용될 변환 행렬(Transformation Matrix)을 `instanceMatrix` 속성으로 전달하여 렌더링을 수행한다 [3, 8]. 이 방식을 사용하면 수많은 객체를 개별적으로 그릴 때 발생하는 엄청난 횟수의 드로우 콜을 단 1회로 묶을 수 있어, CPU 병목 현상과 CPU-GPU 간 통신 오버헤드를 크게 해소한다 [1, 5, 9]. 기하학적 데이터를 복제하지 않고 공유하므로 메모리 효율성 역시 매우 뛰어나다 [6, 9].
-* **구조적 한계 및 병목 현상:**
-  * **지오메트리 및 재질의 단일성 제약:** 모든 인스턴스가 반드시 동일한 BufferGeometry와 Material을 공유해야 한다 [10, 11]. 여러 종류의 지오메트리를 렌더링해야 한다면 다수의 InstancedMesh를 생성하거나, 서로 다른 지오메트리를 묶을 수 있는 BatchedMesh를 사용해야 한다 [11-13].
-  * **시야 절두체 컬링(Frustum Culling) 비효율성:** 기본적으로 엔진 수준에서 InstancedMesh 전체를 하나의 거대한 단일 객체(바운딩 볼륨)로 취급하기 때문에, 인스턴스 개별 단위의 시야 절두체 컬링이 작동하지 않는다 [14, 15]. 따라서 단 하나의 인스턴스만 시야에 있어도 화면 밖의 모든 인스턴스에 대한 정점 연산을 GPU가 강제로 수행해야 하는 낭비가 발생한다 [15, 16].
-  * **오버드로우(Overdraw) 및 정렬 부재:** 인스턴스들은 버퍼에 저장된 순서대로 렌더링되며 카메라와의 거리에 따른 자동 깊이 정렬을 지원하지 않는다 [17, 18]. 이로 인해 투명한 객체 렌더링 시 알파 블렌딩 오류가 발생하거나, 불투명 객체의 심각한 오버드로우를 유발해 프래그먼트 셰이더 연산 부하가 급증할 수 있다 [17, 19-21].
-  * **상호작용 및 애니메이션 난제:** 개별 객체에 대한 레이캐스팅(Raycasting) 시 CPU가 각 인스턴스의 변환 행렬을 개별 계산해야 하므로 대규모 씬에서는 동기화 병목이 발생할 수 있다 [22]. 또한 본(Bone) 기반의 스킨드 애니메이션(Skinned Mesh)을 기본적으로 지원하지 않아 군중 애니메이션 등을 구현하려면 복잡한 커스텀 파이프라인이 요구된다 [23].
-* **활용 및 제어:**
-  개별 인스턴스의 속성은 `setMatrixAt`, `setColorAt` 등의 메서드를 통해 제어하며, 값을 변경한 후에는 반드시 해당 속성(`instanceMatrix`, `instanceColor` 등)의 `needsUpdate` 플래그를 `true`로 설정해야 렌더링에 반영된다 [24]. 위에서 언급한 개별 컬링이나 정렬 문제를 극복하기 위해 `InstancedMesh2` 같은 확장 라이브러리를 사용하거나 BVH(Bounding Volume Hierarchy)를 통한 공간 분할 기법을 도입하기도 한다 [25-27].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[Draw Call]], [[BatchedMesh]], [[Frustum Culling]], [[BufferGeometry]], [[Overdraw]]
-- **Projects/Contexts:** [[Three.js]], [[WebGL]], [[InstancedMesh2]]
-- **Contradictions/Notes:** InstancedMesh는 드로우 콜 횟수를 줄여 전반적인 성능을 높이기 위해 사용되지만, 자동 정렬의 부재 및 개별 인스턴스 컬링 불가 문제로 인해 극심한 오버드로우가 발생할 경우, 일반적인 Mesh(공유 속성 활용)를 사용할 때보다 오히려 프레임 레이트(FPS)가 급격히 저하되는 역설적인 병목 현상이 발생할 수 있다고 여러 소스에서 경고한다 [15, 17, 28, 29].
-
----
-*Last updated: 2026-04-19*
-- Raw Source: [[00_Raw/2026-04-20/InstancedMesh.md]]
----
diff --git a/Programming & Language/Integrated Gradients (통합 그래디언트).md b/Programming & Language/Integrated Gradients (통합 그래디언트).md
deleted file mode 100644
index e05bc8ae..00000000
--- a/Programming & Language/Integrated Gradients (통합 그래디언트).md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-904FDF
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Integrated Gradients (통합 그래디언트)"
----
-
-# [[Integrated Gradients (통합 그래디언트)]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Integrated Gradients (통합 그래디언트).md]]
----
diff --git a/Programming & Language/Interactive Fiction (IF).md b/Programming & Language/Interactive Fiction (IF).md
deleted file mode 100644
index 4bc23701..00000000
--- a/Programming & Language/Interactive Fiction (IF).md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-F4E42B
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Interactive Fiction (IF)"
----
-
-# [[Interactive Fiction (IF)]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Interactive Fiction (IF).md]]
----
diff --git a/Programming & Language/Interactive Narrative.md b/Programming & Language/Interactive Narrative.md
deleted file mode 100644
index edf66d25..00000000
--- a/Programming & Language/Interactive Narrative.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-270B9D
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Interactive Narrative"
----
-
-# [[Interactive Narrative]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Interactive Narrative.md]]
----
diff --git a/Programming & Language/Interactive-Fiction-Tradition.md b/Programming & Language/Interactive-Fiction-Tradition.md
deleted file mode 100644
index 229e1743..00000000
--- a/Programming & Language/Interactive-Fiction-Tradition.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-FEC397
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Interactive-Fiction-Tradition"
----
-
-# [[Interactive-Fiction-Tradition]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Interactive-Fiction-Tradition.md]]
----
diff --git a/Programming & Language/Interop 2025.md b/Programming & Language/Interop 2025.md
deleted file mode 100644
index c51f586d..00000000
--- a/Programming & Language/Interop 2025.md	
+++ /dev/null
@@ -1,32 +0,0 @@
----
-id: P-REINFORCE-AUTO-48DB08
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Interop 2025"
----
-
-# [[Interop 2025]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> Interop 2025는 주로 Chrome에 국한되어 있던 핵심 웹 지표(Core Web Vitals)를 다른 주요 웹 브라우저로 확대 지원하여 호환성을 높이기 위해 시작된 프로젝트입니다[1]. 이 프로젝트를 통해 Firefox와 Safari 같은 브라우저들이 특정 웹 성능 지표에 대한 지원 및 구현 작업을 본격적으로 시작하게 되었습니다[1]. 이를 통해 다양한 브라우저 환경에서 웹 성능을 일관되게 측정할 수 있는 기반이 마련되기 시작했습니다.
-
-## 📖 구조화된 지식 (Synthesized Content)
-- **핵심 웹 지표(Core Web Vitals)의 크로스 브라우저 확장**: 기존의 핵심 웹 지표들은 대부분 Chrome 전용 측정 항목(Chrome-only metrics)으로 사용되고 있었으나, Interop 2025 프로젝트를 기점으로 이러한 한계가 변화하기 시작했습니다[1].
-- **주요 브라우저의 참여 및 지표 구현**: Interop 2025 프로젝트의 일환으로 Firefox와 Safari는 핵심 웹 지표 중 '최대 콘텐츠 풀 페인트(Largest Contentful Paint, LCP)'와 '다음 페인트에 대한 상호작용(Interaction to Next Paint, INP)'을 지원하기 위한 작업을 시작했습니다[1]. 
-- **누적 레이아웃 이동(CLS) 지원 보류**: 또 다른 주요 지표인 '누적 레이아웃 이동(Cumulative Layout Shift, CLS)'에 대한 지원은 Interop 2025 계획에 현재 포함되어 있지 않습니다[1]. 다만, 이를 후속 프로젝트인 Interop 2026에 포함하려는 제안이 존재합니다[1].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[Core Web Vitals]], [[Largest Contentful Paint]], [[Interaction to Next Paint]], [[Cumulative Layout Shift]]
-- **Projects/Contexts:** [[Interop 2026]]
-- **Contradictions/Notes:** 소스에 관련 정보가 부족합니다. (특별한 모순이나 상충하는 의견은 발견되지 않음)
-
----
-*Last updated: 2026-04-19*
-- Raw Source: [[00_Raw/2026-04-20/Interop 2025.md]]
----
diff --git a/Programming & Language/Intrinsic-Motivation.md b/Programming & Language/Intrinsic-Motivation.md
deleted file mode 100644
index 5b33f6c7..00000000
--- a/Programming & Language/Intrinsic-Motivation.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-8559CD
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Intrinsic-Motivation"
----
-
-# [[Intrinsic-Motivation]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Intrinsic-Motivation.md]]
----
diff --git a/Programming & Language/Inventory Management Example.md b/Programming & Language/Inventory Management Example.md
deleted file mode 100644
index 62ab4e05..00000000
--- a/Programming & Language/Inventory Management Example.md	
+++ /dev/null
@@ -1,32 +0,0 @@
----
-id: P-REINFORCE-AUTO-9C355C
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Inventory Management Example"
----
-
-# [[Inventory Management Example]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 이 주제는 프론트엔드 모델과 백엔드 응답 간의 데이터 변환 시 발생할 수 있는 타입 불일치 문제를 보여주는 실제 사례입니다. 인벤토리 관리 시스템에서 백엔드의 데이터 형식과 프론트엔드의 정의된 타입 구조가 다를 때 발생할 수 있는 매핑 오류의 위험성을 다룹니다. TypeScript의 `satisfies` 키워드를 사용하여 엄격한 속성 검사를 강제함으로써 오타나 원치 않는 초과 필드의 포함을 방지하는 방법을 설명합니다.
-
-## 📖 구조화된 지식 (Synthesized Content)
-- **데이터 구조의 차이**: 인벤토리 관리 시스템에서 프론트엔드는 `id`, `name`, `quantity` 속성을 가진 `InventoryItem` 타입을 정의하여 사용합니다 [1, 2]. 그러나 외부 백엔드에서 전달되는 데이터는 `qty`나 `lastUpdated`와 같이 프론트엔드 타입과 다른 형식으로 도착할 수 있습니다 [2].
-- **매핑 오류와 조용한 실패**: 백엔드 데이터를 프론트엔드 타입으로 매핑할 때, 속성 이름을 잘못 입력하거나(`quantity` 대신 `qty` 사용 등) 불필요한 필드를 포함하는 등의 오류가 쉽게 발생할 수 있습니다 [2]. 엄격한 검사가 없다면 TypeScript는 이러한 오타를 잡아내지 못할 수 있으며, 조용히 오류를 통과시킬 위험이 있습니다 [2].
-- **`satisfies` 키워드를 통한 엄격성 강제**: 데이터 매핑 함수 내에서 `satisfies` 키워드를 사용하면 엄격한 타입 계약을 강제할 수 있습니다 [3]. 이를 통해 대상 타입에 정의된 유효한 속성만 포함되도록 보장하며, 그렇지 않을 경우 발생할 수 있는 초과 속성 문제나 오타를 컴파일 단계에서 포착하여 방지할 수 있습니다 [3, 4].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[satisfies Keyword]], [[Excess Property Checking]], [[Type Casting]]
-- **Projects/Contexts:** [[Frontend-Backend Data Transformation]]
-- **Contradictions/Notes:** 소스는 데이터 변환 시 `as` 키워드를 사용한 타입 캐스팅에 의존하는 것을 경고합니다. 타입 캐스팅은 초과 속성 검사를 우회하여 조용한 오류(silent errors)와 의도치 않은 동작을 유발할 수 있으므로, 엄격한 계약을 강제하기 위해서는 `satisfies`를 사용하는 것이 더 안전합니다 [3, 4].
-
----
-*Last updated: 2026-04-18*
-- Raw Source: [[00_Raw/2026-04-20/Inventory Management Example.md]]
----
diff --git a/Programming & Language/Isovist-Analysis.md b/Programming & Language/Isovist-Analysis.md
deleted file mode 100644
index f39d7da2..00000000
--- a/Programming & Language/Isovist-Analysis.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-4BC607
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Isovist-Analysis"
----
-
-# [[Isovist-Analysis]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Isovist-Analysis.md]]
----
diff --git a/Programming & Language/JPEG XL.md b/Programming & Language/JPEG XL.md
deleted file mode 100644
index f5361b72..00000000
--- a/Programming & Language/JPEG XL.md	
+++ /dev/null
@@ -1,41 +0,0 @@
----
-id: P-REINFORCE-AUTO-EC8C7D
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - JPEG XL"
----
-
-# [[JPEG XL]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> JPEG XL은 웹 페이지의 전체 용량을 줄이고 사용자 경험에 부정적인 영향 없이 웹사이트 속도를 높이기 위해 설계된 최신 이미지 포맷이다 [1, 2]. Apple이 2023년에 지원을 시작했고, Mozilla와 Google 등 주요 브라우저 벤더들도 도입에 긍정적인 방향으로 입장을 선회하면서 점차 지원이 확대될 가능성을 보이고 있다 [2, 3]. 기존 이미지 포맷에 비해 동일 품질 대비 더 작은 파일 크기, 빠른 인코딩, 점진적 디코딩 등의 우수한 기술적 이점을 제공한다 [4].
-
-## 📖 구조화된 지식 (Synthesized Content)
-* **주요 장점:** 
-  클라우디너리(Cloudinary)의 존 스나이어스(Jon Sneyers)에 따르면, JPEG XL은 기존 이미지 포맷과 비교하여 다음과 같은 뚜렷한 장점들을 제공한다 [4].
-  * 동일한 품질에서 더 작은 파일 크기를 달성할 수 있다 [4].
-  * 인코딩 속도가 빨라서 서버가 사전에 파일을 미리 생성해둘 필요가 없다 [4].
-  * 점진적 이미지 디코딩(Progressive image decoding) 기능을 지원하여, 데이터가 일부만 다운로드된 상태에서도 이미지 미리보기가 가능하다 [4].
-  * 시각적인 변화 없이 재압축이 가능하여 이미지 아티팩트(artifacts)가 점진적으로 축적되는 현상을 방지할 수 있다 [4].
-  이러한 이점 덕분에, 이미지 화질이 매우 중요한 패션 전자상거래(eCommerce) 웹사이트 등에서 기존의 WebP 대신 AVIF와 함께 최적화 포맷으로 사용하도록 권장되기도 한다 [5].
-
-* **브라우저 지원 역사 및 현황:**
-  * **Google Chrome:** 구글은 2021년에 크롬에서 JPEG XL을 지원하기 위한 작업을 시작했으나, 2022년 10월에 생태계의 관심 부족과 유지보수의 부담을 이유로 관련 코드를 제거했다 [2]. 하지만 개발자들의 지속적인 관심이 이어지자, 2025년 11월에 크롬 지원에 반대하지 않는다고 발표했다 (다만, 실제 구현 및 유지보수에 투자할 구체적인 계획은 명시하지 않았다) [3].
-  * **Apple Safari:** 다른 브라우저들이 도입을 미루는 동안, 애플은 2023년 9월에 JPEG XL 지원을 도입하며 선도적인 움직임을 보였다 [2].
-  * **Mozilla Firefox:** 모질라는 초기에 저수준(low-level) 언어로 작성된 복잡한 새 코드가 가져올 수 있는 보안 위험성 때문에 지원을 꺼렸으나, 구글과 Rust 기반 디코더에 대해 논의한 후 2024년 9월에 긍정적인 방향으로 입장을 변경했다 [3].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[AVIF]], [[WebP]]
-- **Projects/Contexts:** [[Web Performance]], [[Google Chrome Browser Support]]
-- **Contradictions/Notes:** 구글은 2022년 10월에 "생태계의 관심 부족"을 이유로 JPEG XL 지원 코드를 제거했으나, 3년 뒤인 2025년 11월에는 "개발자들의 지속적인 관심"을 이유로 크롬 지원에 반대하지 않는다고 입장을 전환했다 [2, 3].
-
----
-*Last updated: 2026-04-19*
-- Raw Source: [[00_Raw/2026-04-20/JPEG XL.md]]
----
diff --git a/Programming & Language/Jacobian-Matrix-Analysis.md b/Programming & Language/Jacobian-Matrix-Analysis.md
deleted file mode 100644
index f8586d57..00000000
--- a/Programming & Language/Jacobian-Matrix-Analysis.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-BC322B
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Jacobian-Matrix-Analysis"
----
-
-# [[Jacobian-Matrix-Analysis]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Jacobian-Matrix-Analysis.md]]
----
diff --git a/Programming & Language/JavaScript 메모리 관리(JavaScript Memory Management).md b/Programming & Language/JavaScript 메모리 관리(JavaScript Memory Management).md
deleted file mode 100644
index c645897b..00000000
--- a/Programming & Language/JavaScript 메모리 관리(JavaScript Memory Management).md	
+++ /dev/null
@@ -1,48 +0,0 @@
----
-id: P-REINFORCE-AUTO-AABE4C
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - JavaScript 메모리 관리(JavaScript Memory Management)"
----
-
-# [[JavaScript 메모리 관리(JavaScript Memory Management)]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-**스택(Stack)과 힙(Heap) 메모리 구조**
-*   **스택(Stack):** 실행 중인 프로세스의 정적 데이터(메서드/함수 프레임, 원시 값, 힙 객체에 대한 포인터 등)를 저장하는 영역으로 LIFO 방식으로 관리됩니다 [2-4].
-*   **힙(Heap):** 크기를 컴파일 타임에 결정할 수 없는 동적 데이터 및 객체가 저장되는 공간으로 가비지 컬렉터에 의해 직접 관리됩니다 [3, 10]. V8은 힙을 여러 공간(Space)으로 나눕니다.
-
-**힙의 세대별 구성 (Generational Layout)**
-V8은 객체의 수명을 기준으로 힙을 효율적으로 관리합니다 [6, 7].
-*   **New Space (Young Generation):** 작고 수명이 짧은 대부분의 새 객체가 할당되는 공간입니다 [6, 11-13]. 내부적으로 두 개의 반공간(To-Space와 From-Space)으로 나뉘어 관리됩니다 [14-16].
-*   **Old Space (Old Generation):** New Space에서 일정한 가비지 컬렉션 주기(통상 2회)를 살아남은 객체들이 승격(Promote)되어 이동하는 큰 공간으로, 포인터 영역과 데이터 영역으로 더 나뉩니다 [6, 11, 13, 17, 18].
-*   **기타 영역:** 크기가 제한을 초과하는 객체를 위한 Large Object Space, 실행 가능한 머신 코드가 저장되는 Code Space 등이 존재합니다 [11, 19].
-
-**가비지 컬렉션(Garbage Collection) 메커니즘**
-V8 엔진은 주로 두 가지 가비지 컬렉터를 사용하여 메모리를 회수합니다 [20].
-*   **마이너 GC (Scavenger):** New Space에서 빈번하고 빠르게 동작합니다 [6, 14, 20]. Cheney의 알고리즘에 기반하여 활성 객체를 추적한 뒤 To-Space로 대피(Copy/Evacuate)시키고 기존 From-Space의 쓰레기를 일괄 비워 단편화를 해결합니다 [14, 15, 17].
-*   **메이저 GC (Mark-Sweep-Compact):** Old Space 전체를 관리합니다 [6, 20, 21]. 스택과 전역 객체 같은 루트(Root)에서 출발해 포인터를 따라가며 살아있는 객체를 식별(Mark)하고, 도달할 수 없는 객체의 메모리를 회수(Sweep)한 뒤, 파편화를 줄이기 위해 필요시 객체들을 압축(Compact)합니다 [5, 8, 21-24].
-*   **오리노코(Orinoco):** 최신 V8의 GC 프로젝트로 메인 스레드의 정지 시간(Stop-the-world)을 줄이기 위해 병렬(Parallel), 점진적(Incremental), 동시(Concurrent) 스레딩 방식을 도입하여 JS 실행과 GC 작업을 효율적으로 교차 수행합니다 [25-31].
-
-**메모리 누수(Memory Leaks)와 최적화**
-*   메모리 누수는 객체가 더 이상 프로그램에서 쓰이지 않음에도 GC 루트(전역 변수, 클로저, 이벤트 리스너, 잊혀진 타이머 등)에서 참조를 계속 유지하여 GC가 수거하지 못할 때 발생합니다 [32-37].
-*   해결 및 탐지 방법으로는 Chrome DevTools의 Heap Snapshot을 사용해 세 번의 스냅샷을 비교하는 기법, Allocation Timeline을 통한 힙 할당 추적, Node.js의 `--trace-gc` 플래그 및 `process.memoryUsage()`를 통한 메모리 상태 모니터링 등이 있습니다 [38-42].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[Garbage Collection (가비지 컬렉션)]], [[V8 Engine (V8 엔진)]], [[Generational Hypothesis (세대 가설)]], [[Memory Leak (메모리 누수)]]
-- **Projects/Contexts:** [[Chrome DevTools 메모리 분석]], [[Node.js 메모리 튜닝]]
-- **Contradictions/Notes:** 가비지 컬렉션을 사용하는 언어는 메모리 관리의 복잡성을 크게 줄여주지만, 프로그래머가 메모리 제어권을 완전히 상실하게 된다는 단점이 있습니다 [1, 43]. 또한 GC 실행 시 불규칙한 일시 정지 현상이 발생해 대화형 시스템에 영향을 줄 수 있으며 [43], 64비트 플랫폼에서 V8 힙은 포인터 압축(Pointer Compression) 보안 기술로 인해 4GB의 크기 제한(V8 Memory Cage)을 갖는 특징이 있습니다 [44-46].
-
----
-*Last updated: 2026-04-19*
-- Raw Source: [[00_Raw/2026-04-20/JavaScript 메모리 관리(JavaScript Memory Management).md]]
----
diff --git a/Programming & Language/JavaScriptCore.md b/Programming & Language/JavaScriptCore.md
deleted file mode 100644
index 924655f3..00000000
--- a/Programming & Language/JavaScriptCore.md	
+++ /dev/null
@@ -1,33 +0,0 @@
----
-id: P-REINFORCE-AUTO-1AF373
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - JavaScriptCore"
----
-
-# [[JavaScriptCore]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> JavaScriptCore는 WebKit의 JavaScript 엔진으로, 신뢰할 수 없는 JavaScript나 WebAssembly 코드를 실행할 때 호스트 프로세스의 메모리 유출을 방지하도록 설계된 안전한 언어 가상 머신(secure language virtual machine)입니다 [1, 2]. 최근 Spectre 공격으로 인해 기존의 분기(branch) 기반 보안 속성이 무력화되는 위협을 받았으며, 이를 방어하기 위한 구조적 보안 개선이 이루어지고 있습니다 [1, 3].
-
-## 📖 구조화된 지식 (Synthesized Content)
-- **보안 목적과 구조:** JavaScriptCore는 기본적으로 사용자의 프로세스에 신뢰할 수 없는 코드를 로드하더라도, C나 Objective-C 바인딩 API를 통해 명시적으로 내보낸 데이터가 아닌 이상 프로세스의 메모리가 JavaScript 코드에 유출되지 않도록 보장해야 합니다 [2].
-- **Spectre 취약점으로 인한 영향:** Spectre 공격은 JavaScriptCore의 경계 검사(bounds checks)와 유형 검사(type checks)에 사용되는 분기(branches)를 제어하고 우회할 수 있게 만들었습니다 [1, 4]. 이로 인해 신뢰할 수 없는 JavaScript나 WebAssembly가 호스트 프로세스의 전체 주소 공간을 읽을 수 있는 이론적인 경로가 발생하여 JavaScriptCore의 보안 속성이 깨지게 되었습니다 [2].
-- **실행 및 취약점 노출 원리:** JavaScriptCore가 JavaScript의 속성 접근(property access) 등 보안에 민감한 언어 작업을 처리할 때, 코드는 최신 CPU의 분기 예측(branch prediction)과 추측 실행(speculative execution)을 통해 병렬로 실행됩니다 [5, 6]. 공격자는 이 추측 실행 과정에서 L1 캐시와 메인 메모리 간의 지연 시간(latency) 차이를 악용하여 데이터를 유출할 수 있습니다 [4, 7].
-- **보안 완화(Mitigation) 전략:** Spectre 위협에 대응하기 위해 JavaScriptCore는 기존의 분기 기반 보안 검사에서 벗어나 '분기 없는 보안 검사(branchless security checks)'를 도입하여 전환하고 있습니다 [3]. 대표적으로 객체 필드 접근 시 무작위 독성 값을 활용하는 '포인터 중독(Pointer poisoning)' 기법을 JavaScriptCore의 수많은 데이터 구조에 적용함으로써, 임의의 포인터 생성을 막고 원격 코드 실행에 악용되는 유형 혼동(type confusion)을 방어하고 있습니다 [8, 9].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[WebKit]], [[Spectre]], [[WebAssembly]], [[Speculative execution]], [[Pointer poisoning]]
-- **Projects/Contexts:** [[WebKit's Spectre and Meltdown Mitigations]]
-- **Contradictions/Notes:** 소스에 관련 정보가 부족합니다.
-
----
-*Last updated: 2026-04-19*
-- Raw Source: [[00_Raw/2026-04-20/JavaScriptCore.md]]
----
diff --git a/Programming & Language/Joern.md b/Programming & Language/Joern.md
deleted file mode 100644
index fdce5bd7..00000000
--- a/Programming & Language/Joern.md	
+++ /dev/null
@@ -1,33 +0,0 @@
----
-id: P-REINFORCE-AUTO-A0754B
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Joern"
----
-
-# [[Joern]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> Joern은 디컴파일된 소스 코드를 파싱(parse)하는 데 사용되는 도구입니다 [1]. 프로그램 바이너리의 작성자를 식별(Authorship Attribution)하기 위한 연구 과정에서 분석에 필요한 AST(추상 구문 트리) 기반의 특징을 추출하는 목적으로 활용되었습니다 [1]. 제공된 소스에는 이 외의 목적이나 기능 등 Joern에 대한 구체적인 관련 정보가 부족합니다.
-
-## 📖 구조화된 지식 (Synthesized Content)
-소스에 관련 정보가 부족합니다. 제공된 문헌에서 제한적으로 확인 가능한 내용은 다음과 같습니다:
-
-*   **바이너리 코드 분석을 위한 파싱**: 실행 파일(바이너리)의 작성자를 식별하기 위해 하이브리드 접근법을 사용한 Caliskan-Islam 등의 연구에서, 디컴파일된 소스 코드를 구문 분석하기 위해 Joern이 사용되었습니다 [1]. 
-*   **AST 기반 특징 추출 지원**: 연구팀은 Joern을 통해 코드를 파싱한 뒤, 식별 모델 학습에 필요한 AST 기반의 특징(Feature)들(예: 노드 타입 유니그램 등)을 추출할 수 있었습니다 [1].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[AST(Abstract Syntax Tree)]], [[Authorship Attribution]]
-- **Projects/Contexts:** [[Caliskan-Islam 등의 프로그램 바이너리 작성자 식별 연구]]
-- **Contradictions/Notes:** 소스에 관련 정보가 부족합니다. Joern 자체의 상세한 구조나 추가적인 기능에 대해서는 소스 내에 언급된 바가 없으며, 디컴파일된 코드를 파싱하는 도구로서 단 1회 언급되었습니다.
-
----
-*Last updated: 2026-04-18*
-- Raw Source: [[00_Raw/2026-04-20/Joern.md]]
----
diff --git a/Programming & Language/Kinematics.md b/Programming & Language/Kinematics.md
deleted file mode 100644
index 48a676db..00000000
--- a/Programming & Language/Kinematics.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-CC099B
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Kinematics"
----
-
-# [[Kinematics]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Kinematics.md]]
----
diff --git a/Programming & Language/L-Systems.md b/Programming & Language/L-Systems.md
deleted file mode 100644
index b36bfa16..00000000
--- a/Programming & Language/L-Systems.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-EBE0D0
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - L-Systems"
----
-
-# [[L-Systems]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/L-Systems.md]]
----
diff --git a/Programming & Language/L-systems in Biology.md b/Programming & Language/L-systems in Biology.md
deleted file mode 100644
index db08aed1..00000000
--- a/Programming & Language/L-systems in Biology.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-5DB108
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - L-systems in Biology"
----
-
-# [[L-systems in Biology]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/L-systems in Biology.md]]
----
diff --git a/Programming & Language/Labeled Property Graph (LPG 속성 그래프).md b/Programming & Language/Labeled Property Graph (LPG 속성 그래프).md
deleted file mode 100644
index 09da7ab3..00000000
--- a/Programming & Language/Labeled Property Graph (LPG 속성 그래프).md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-84C8D8
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Labeled Property Graph (LPG 속성 그래프)"
----
-
-# [[Labeled Property Graph (LPG 속성 그래프)]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Labeled Property Graph (LPG, 속성 그래프).md]]
----
diff --git a/Programming & Language/Latiotech Report.md b/Programming & Language/Latiotech Report.md
deleted file mode 100644
index f4dd4589..00000000
--- a/Programming & Language/Latiotech Report.md	
+++ /dev/null
@@ -1,35 +0,0 @@
----
-id: P-REINFORCE-AUTO-B2FE12
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Latiotech Report"
----
-
-# [[Latiotech Report]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-소스 데이터에는 'Latio.tech Report'의 전체 내용이 아닌 특정 솔루션과 관련된 단편적인 평가 결과만 포함되어 있습니다. 소스에서 확인 가능한 주요 내용은 다음과 같습니다:
-
-* **Corgea에 대한 평가:** Latio.tech Report는 Corgea를 시중에 나와 있는 자동 수정(auto-fixing) 도구 중 가장 뛰어난(best) 도구로 평가했습니다 [1].
-* **Snyk에 대한 평가:** Snyk의 자동 수정 기능에 대해서는 IDE 확장 프로그램 내에서 재검사(rescan)를 수행할 때만 수정 사항을 생성할 수 있다는 한계점을 지적했습니다 [2]. 보고서는 이러한 특징이 특정 워크플로우에서는 자동 수정 기능의 실용성을 제한한다고 분석했습니다 [2].
-
-*소스에 관련 정보가 부족합니다.*
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[Corgea]], [[Snyk Code]], [[Auto-fixing Tool]]
-- **Projects/Contexts:** [[SAST Tools Evaluation]]
-- **Contradictions/Notes:** 제공된 소스에는 'Latio.tech Report'가 Corgea와 Snyk를 평가한 내용 중 극히 일부만 언급되어 있으며, 평가 기준이나 다른 벤더에 대한 정보 등 전체적인 맥락을 파악하기에는 소스에 관련 정보가 부족합니다.
-
----
-*Last updated: 2026-04-19*
-- Raw Source: [[00_Raw/2026-04-20/Latio.tech Report.md]]
----
diff --git a/Programming & Language/Lighthouse.md b/Programming & Language/Lighthouse.md
deleted file mode 100644
index 956567a5..00000000
--- a/Programming & Language/Lighthouse.md	
+++ /dev/null
@@ -1,30 +0,0 @@
----
-id: P-REINFORCE-AUTO-B44166
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Lighthouse"
----
-
-# [[Lighthouse]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> Lighthouse는 페이지 속도를 측정하고 성능 개선을 위한 권장 사항을 제공하는 구글의 무료 오픈소스 도구입니다 [1, 2]. 주로 Chrome DevTools 패널이나 명령줄에서 실행되며, PageSpeed Insights의 진단 기능을 구동하는 핵심 엔진으로 사용됩니다 [1, 2]. 또한, 이와 별개로 분산 시스템에서 네트워크 위치 지정(Network Positioning)의 확장성 문제를 해결하기 위해 고안된 동명의 연구 프로젝트인 'Lighthouses'도 존재합니다 [3, 4].
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[PageSpeed Insights]], [[Chrome DevTools]], [[Synthetic Testing]], [[Time to Interactive (TTI)]], [[Global Network Positioning (GNP)]]
-- **Projects/Contexts:** [[Web Performance Optimization]], [[Network Coordinate Systems]]
-- **Contradictions/Notes:** 구글 Lighthouse의 스로틀링 시뮬레이션은 프리로드된 리소스를 렌더링 차단 리소스로 잘못 분류하는 등 부정확한 점수를 도출하는 모순적 한계가 있으며, 현재 이를 실제 환경에 맞게 바로잡는 연구가 진행 중입니다 [8, 9].
-
----
-*Last updated: 2026-04-19*
-- Raw Source: [[00_Raw/2026-04-20/Lighthouse.md]]
----
diff --git a/Programming & Language/Linked Open Data (LOD).md b/Programming & Language/Linked Open Data (LOD).md
deleted file mode 100644
index a5357874..00000000
--- a/Programming & Language/Linked Open Data (LOD).md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-30BF26
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Linked Open Data (LOD)"
----
-
-# [[Linked Open Data (LOD)]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Linked Open Data (LOD).md]]
----
diff --git a/Programming & Language/Live Streaming Monetization.md b/Programming & Language/Live Streaming Monetization.md
deleted file mode 100644
index c4dcfb55..00000000
--- a/Programming & Language/Live Streaming Monetization.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-9CC93F
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Live Streaming Monetization"
----
-
-# [[Live Streaming Monetization]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Live Streaming Monetization.md]]
----
diff --git a/Programming & Language/Logit Lens (로짓 렌즈).md b/Programming & Language/Logit Lens (로짓 렌즈).md
deleted file mode 100644
index 2bce6260..00000000
--- a/Programming & Language/Logit Lens (로짓 렌즈).md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-8DE413
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Logit Lens (로짓 렌즈)"
----
-
-# [[Logit Lens (로짓 렌즈)]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Logit Lens (로짓 렌즈).md]]
----
diff --git a/Programming & Language/Long-Term Potentiation (LTP).md b/Programming & Language/Long-Term Potentiation (LTP).md
deleted file mode 100644
index f61c2c31..00000000
--- a/Programming & Language/Long-Term Potentiation (LTP).md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-AEAE94
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Long-Term Potentiation (LTP)"
----
-
-# [[Long-Term Potentiation (LTP)]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Long-Term Potentiation (LTP).md]]
----
diff --git a/Programming & Language/Looking Glass Studios.md b/Programming & Language/Looking Glass Studios.md
deleted file mode 100644
index 6b75ff8b..00000000
--- a/Programming & Language/Looking Glass Studios.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-FBDE4E
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Looking Glass Studios"
----
-
-# [[Looking Glass Studios]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Looking Glass Studios.md]]
----
diff --git a/Programming & Language/Ludology vs Narratology Debate.md b/Programming & Language/Ludology vs Narratology Debate.md
deleted file mode 100644
index e34f7b7f..00000000
--- a/Programming & Language/Ludology vs Narratology Debate.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-10519B
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Ludology vs Narratology Debate"
----
-
-# [[Ludology vs Narratology Debate]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Ludology vs Narratology Debate.md]]
----
diff --git a/Programming & Language/Ludology vs Narratology.md b/Programming & Language/Ludology vs Narratology.md
deleted file mode 100644
index 5ab77c30..00000000
--- a/Programming & Language/Ludology vs Narratology.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-E5E303
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Ludology vs Narratology"
----
-
-# [[Ludology vs Narratology]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Ludology vs. Narratology.md]]
----
diff --git a/Programming & Language/Ludonarrative Dissonance.md b/Programming & Language/Ludonarrative Dissonance.md
deleted file mode 100644
index 5ac19bee..00000000
--- a/Programming & Language/Ludonarrative Dissonance.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-D88E68
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Ludonarrative Dissonance"
----
-
-# [[Ludonarrative Dissonance]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Ludonarrative Dissonance.md]]
----
diff --git a/Programming & Language/Ludonarrative Resonance.md b/Programming & Language/Ludonarrative Resonance.md
deleted file mode 100644
index 172027d5..00000000
--- a/Programming & Language/Ludonarrative Resonance.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-2B4A1C
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Ludonarrative Resonance"
----
-
-# [[Ludonarrative Resonance]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Ludonarrative Resonance.md]]
----
diff --git a/Programming & Language/MMORPG Ecosystems.md b/Programming & Language/MMORPG Ecosystems.md
deleted file mode 100644
index 715f202f..00000000
--- a/Programming & Language/MMORPG Ecosystems.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-525534
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - MMORPG Ecosystems"
----
-
-# [[MMORPG Ecosystems]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/MMORPG Ecosystems.md]]
----
diff --git a/Programming & Language/MVC (Model-View-Controller).md b/Programming & Language/MVC (Model-View-Controller).md
deleted file mode 100644
index 050124f7..00000000
--- a/Programming & Language/MVC (Model-View-Controller).md	
+++ /dev/null
@@ -1,41 +0,0 @@
----
-id: P-REINFORCE-AUTO-F8BE8B
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - MVC (Model-View-Controller)"
----
-
-# [[MVC (Model-View-Controller)]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> MVC(Model-View-Controller)는 애플리케이션을 모델(Model), 뷰(View), 컨트롤러(Controller)라는 세 가지 상호 연결된 구성 요소로 분리하는 고전적인 소프트웨어 아키텍처 패턴이다 [1]. 이 패턴은 각 구성 요소에 명확한 책임을 부여하여 시스템의 복잡성을 줄이는 '관심사의 분리(Separation of Concerns)' 원칙의 대표적인 예시이다 [2, 3]. 역할 간의 명확한 경계를 설정함으로써 개발자는 데이터 로직에 영향을 주지 않고 사용자 인터페이스를 독립적으로 수정할 수 있어 시스템의 유연성과 유지보수성을 크게 향상시킬 수 있다 [2, 3].
-
-## 📖 구조화된 지식 (Synthesized Content)
-- **구성 요소별 명확한 책임 분리:**
-  - **모델 (Model):** 애플리케이션의 데이터와 비즈니스 로직을 관리한다 [1-3]. 클린 아키텍처(Clean Architecture)의 관점에서는 데이터 구조 정도의 역할을 하며, 컨트롤러에서 유스케이스로 전달된 후 다시 프레젠터와 뷰로 되돌아가는 형태로 사용되기도 한다 [4].
-  - **뷰 (View):** 사용자 인터페이스(UI)를 관리하고 데이터를 시각적으로 표시하는 프레젠테이션 역할을 전담한다 [1-3].
-  - **컨트롤러 (Controller):** 사용자의 입력을 받아 처리하며, 모델과 뷰 사이에서 중재자(Intermediary) 역할을 수행하고 이들 간의 상호작용을 조정한다 [1-3].
-
-- **엄격한 상호작용 규칙:**
-  - MVC 패턴을 비롯한 아키텍처 전략의 핵심은 뷰(View)가 모델(Model)과 직접 상호작용하는 것을 허용하지 않는다는 점이다 [3, 5]. 
-  - 뷰는 반드시 컨트롤러(Controller)를 매개체로 통해서만 모델과 상호작용해야 하며, 이러한 통제는 구성 요소 간의 불필요한 의존성을 줄여준다 [3, 5].
-
-- **관심사 분리(SoC)를 통한 시스템 이점:**
-  - MVC는 관심사의 분리(SoC) 원칙을 시스템 설계 수준에서 실현하여, 시스템의 복잡성을 줄이고 각 구성 요소가 단일 책임에 집중하도록 유도한다 [3].
-  - 이러한 분리를 통해 모듈화가 향상되며, UI 요소를 수정하더라도 기저의 데이터 처리 로직에 영향을 미치지 않는다 [2]. 결과적으로 변경이 다른 부분으로 파급되는 것을 막아 유지보수가 용이해지고, 개별 구성 요소를 유연하게 교체하거나 확장할 수 있다 [2, 3, 6].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[Separation of Concerns (SoC)]], [[Software Architecture]], [[Clean Architecture]]
-- **Projects/Contexts:** [[Web Applications]], [[GUI Development]]
-- **Contradictions/Notes:** 소스에 관련 정보가 부족합니다.
-
----
-*Last updated: 2026-04-18*
-- Raw Source: [[00_Raw/2026-04-20/MVC (Model-View-Controller).md]]
----
diff --git a/Programming & Language/Major GC.md b/Programming & Language/Major GC.md
deleted file mode 100644
index fe6f581c..00000000
--- a/Programming & Language/Major GC.md	
+++ /dev/null
@@ -1,42 +0,0 @@
----
-id: P-REINFORCE-AUTO-D3B770
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Major GC"
----
-
-# [[Major GC]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> Major GC는 V8을 비롯한 여러 가비지 컬렉션 환경에서 메모리의 'Old Space(오래된 세대)' 또는 힙(Heap) 전체의 가비지를 수집하는 주기입니다 [1-3]. 짧은 수명의 객체를 처리하는 Minor GC(Scavenge)와 달리, Mark-Sweep 및 Mark-Compact 알고리즘을 사용하여 수명이 길어 Old Space로 승격된 객체들의 메모리를 정리합니다 [1, 4, 5]. 전통적으로는 긴 정지 시간(stop-the-world)을 발생시켰으나, 최근에는 점진적(incremental), 병렬(parallel), 동시적(concurrent) 처리 기법을 도입하여 애플리케이션의 메인 스레드 지연을 최소화하는 방향으로 최적화되었습니다 [6-8].
-
-## 📖 구조화된 지식 (Synthesized Content)
-*   **작동 단계 및 알고리즘:** Major GC는 수백 메가바이트의 데이터를 포함할 수 있는 Old Space를 처리하기 위해 주로 세 가지 단계로 나뉘어 동작합니다 [5, 9, 10].
-    *   **Marking (마킹):** 활성(live) 객체를 찾아내는 과정입니다. 스택과 전역 객체 등의 루트(Root) 집합에서 시작해 포인터를 따라가며 객체를 추적합니다 [2, 11]. 객체는 마킹 상태에 따라 아직 발견되지 않은 '흰색', 발견되었으나 이웃이 처리되지 않은 '회색', 모든 이웃이 처리된 '검은색'으로 구분되어 깊이 우선 탐색(DFS) 방식으로 마킹됩니다 [11-13].
-    *   **Sweeping (스위핑):** 마킹 완료 후, GC가 도달할 수 없는 객체(죽은 객체)들이 차지했던 연속된 메모리 공간을 찾아내 여유 목록(free-list)에 추가함으로써 메모리를 재사용할 수 있도록 만듭니다 [5, 14-16].
-    *   **Compacting (압축):** 실제 메모리 사용량을 줄이기 위해 파편화가 심한 페이지에서 활성 객체들을 다른 페이지의 빈 공간으로 이주(복사)시킵니다 [5, 15, 17, 18]. 객체의 복사 비용이 비싸기 때문에 모든 페이지가 아닌 파편화가 심한 일부 페이지에 대해서만 선택적으로 압축을 수행합니다 [15, 18].
-
-*   **트리거 조건:** New Space에서 생성된 후 Minor GC 사이클을 두 번 이상 살아남아 Old Space로 승격(Promote)된 객체들이 일정량에 도달하거나, 힙이 동적으로 계산된 제한치에 근접할 때 실행됩니다 [1, 4, 8].
-
-*   **성능 최적화 기법 (Orinoco):** 과거에는 Major GC가 500-1000ms에 이르는 긴 정지 시간을 유발했으나 [6], V8의 Orinoco 프로젝트를 통해 다음과 같은 비동기 및 병렬 기법이 도입되었습니다 [7, 19, 20].
-    *   **Incremental Marking (증분 마킹) 및 Lazy Sweeping (지연 스위핑):** 마킹 작업을 5~10ms의 작은 단위로 나누어 점진적으로 수행하며, 스위핑은 필요한 시점까지 지연시켜 한 번에 긴 시간 동안 애플리케이션이 정지되는 것을 방지합니다 [6, 18, 21-23]. 이 과정에서 발생하는 객체 그래프의 변화는 '쓰기 장벽(Write barrier)'을 통해 관리됩니다 [24].
-    *   **Concurrent Marking (동시 마킹):** 자바스크립트가 메인 스레드에서 실행되는 동안 백그라운드 헬퍼 스레드에서 마킹 작업을 전적으로 동시에 수행합니다 [8, 22].
-    *   **Parallel Compaction (병렬 압축):** 메인 스레드와 여러 헬퍼 스레드가 함께 압축 및 포인터 업데이트 작업을 나누어 병렬로 처리합니다 [25, 26].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[Minor GC]], [[Mark-Sweep]], [[Mark-Compact]], [[Orinoco]], [[Old Space]]
-- **Projects/Contexts:** [[V8 JavaScript Engine]], [[Node.js Memory Management]]
-- **Contradictions/Notes:** 
-  - Minor GC(Scavenge)는 새롭게 할당된 작고 수명이 짧은 객체를 신속하게 처리하는 반면, Major GC는 크기가 크고 수명이 긴 Old Space 영역을 처리하므로 상대적으로 비용이 더 많이 들며 덜 빈번하게 발생합니다 [1, 3, 4, 10].
-  - 과거의 주요 가비지 컬렉터들은 전체 과정을 동기적으로 수행하여 'Stop-the-world' 상태를 초래했지만, 현재의 메이저 GC는 점진적이고 동시적인 기법을 통해 메인 스레드의 멈춤 시간을 사실상 사용자가 인지하지 못할 수준으로 개선했습니다 [6-8, 22].
-
----
-*Last updated: 2026-04-19*
-- Raw Source: [[00_Raw/2026-04-20/Major GC.md]]
----
diff --git a/Programming & Language/Mark-Sweep-Compact 알고리즘.md b/Programming & Language/Mark-Sweep-Compact 알고리즘.md
deleted file mode 100644
index 3fbff272..00000000
--- a/Programming & Language/Mark-Sweep-Compact 알고리즘.md	
+++ /dev/null
@@ -1,35 +0,0 @@
----
-id: P-REINFORCE-AUTO-AF3315
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Mark-Sweep-Compact 알고리즘"
----
-
-# [[Mark-Sweep-Compact 알고리즘]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> Mark-Sweep-Compact 알고리즘은 애플리케이션의 힙 메모리에서 더 이상 사용되지 않는 객체를 식별하여 메모리를 회수하고, 발생한 메모리 단편화를 해결하는 주요 가비지 컬렉션(GC) 기법입니다 [1]. 도달 가능한 객체를 식별하여 표시하는 마크(Mark) 단계, 참조되지 않는 죽은 객체의 메모리를 회수하는 스윕(Sweep) 단계, 그리고 살아남은 객체들을 모아 힙 메모리 단편화를 줄이는 컴팩트(Compact) 단계로 이루어집니다 [1]. 이 알고리즘은 주로 V8 엔진의 Old Generation이나 JVM의 전역 힙(Java heap)을 정리하는 데 활용되며, 메모리 효율성을 극대화하지만 객체 이동에 따른 비용이 크다는 특징이 있습니다 [2], [3], [4].
-
-## 📖 구조화된 지식 (Synthesized Content)
-- **마크(Mark) 단계**: 루트(Root) 객체에서 시작하여 포인터를 통해 도달할 수 있는 모든 살아있는(live) 객체를 식별하고 마크합니다 [5], [1]. 
-  - V8 엔진에서는 객체의 마크 상태를 3가지 상태(흰색: 아직 발견되지 않음, 회색: 발견되었으나 이웃 미처리, 검은색: 모든 이웃 객체 처리 완료)로 구분하며, 힙을 객체와 포인터로 연결된 방향 그래프로 간주하여 깊이 우선 탐색(DFS) 방식으로 순회합니다 [6], [5]. 
-  - JVM 환경에서는 마크 맵(mark map)이라는 비트 배열을 사용하여 각 객체가 도달 가능한 상태인지 그 위치를 기록합니다 [7].
-- **스윕(Sweep) 단계**: 마크 단계 완료 후 마크되지 않은(흰색) 죽은 객체들의 범위를 찾아 빈 공간으로 변환하여 회수합니다 [8], [9]. 이렇게 확보된 영역들은 각 크기에 따라 분리된 여유 목록(free lists)에 추가되어 이후 새로운 객체 할당이나 객체 이주를 위한 공간으로 재사용됩니다 [8]. 
-- **컴팩트(Compact) 단계**: 살아있는 객체들을 다른 페이지의 빈 공간으로 이동시켜 단편화된 메모리 페이지(작은 빈 공간이 많은 상태)의 실제 사용량을 줄이고 최적화합니다 [10], [11]. 이 단계에서는 기존 객체를 복사하고 원본의 첫 단어 자리에 포워딩 주소(forwarding address)를 남기며, 이주가 끝나면 관련된 모든 포인터를 새로운 복사본의 위치로 업데이트합니다 [10].
-- **성능과 실행 특징**: 스윕 알고리즘은 각 페이지의 마크 비트맵을 순회하며 마크되지 않은 객체의 범위를 찾기만 하므로 매우 간단합니다 [8]. 반면 컴팩트 작업은 살아있는 대량의 객체를 이동시키고 이 객체들을 가리키는 모든 참조(reference) 값을 변경해야 하므로 연산 비용이 매우 큽니다 [3], [4]. 따라서 컴팩트 작업은 매번 수행되지 않고 힙이 심하게 단편화되었거나 메모리 할당 실패가 발생하는 등 선택적이고 필수적인 상황에서만 실행되도록 제어됩니다 [3], [4].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[Garbage Collection]], [[V8 Engine]], [[Old Space]], [[Java Heap Memory]]
-- **Projects/Contexts:** [[V8 엔진의 Old Generation 메모리 관리]], [[IBM JVM의 가비지 컬렉션 메커니즘]]
-- **Contradictions/Notes:** 컴팩트(Compact) 작업은 단편화를 해결하여 캐시 지역성(cache locality)을 높이지만, 포인터 재조정과 객체 이동 비용으로 인해 애플리케이션의 'Stop-the-world(STW)' 일시 중지 시간을 증가시킬 수 있습니다 [3]. 이를 보완하기 위해 V8 엔진은 객체 그래프가 변경될 가능성을 쓰기 장벽(Write barrier)으로 제어하며 점진적 마킹(Incremental marking) 및 지연 스윕(Lazy sweeping) 기술을 도입하여 메인 스레드 멈춤 시간을 줄이고 있습니다 [12], [13], [14].
-
----
-*Last updated: 2026-04-19*
-- Raw Source: [[00_Raw/2026-04-20/Mark-Sweep-Compact 알고리즘.md]]
----
diff --git a/Programming & Language/Mark-Sweep-Compact(메이저 GC).md b/Programming & Language/Mark-Sweep-Compact(메이저 GC).md
deleted file mode 100644
index cc8b8072..00000000
--- a/Programming & Language/Mark-Sweep-Compact(메이저 GC).md	
+++ /dev/null
@@ -1,47 +0,0 @@
----
-id: P-REINFORCE-AUTO-50957B
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Mark-Sweep-Compact(메이저 GC)"
----
-
-# [[Mark-Sweep-Compact(메이저 GC)]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> Mark-Sweep-Compact(메이저 GC)는 메모리 힙의 전체 영역(주로 Old 세대 공간)에서 더 이상 사용되지 않는 객체를 식별해 메모리를 회수하고 단편화를 해소하는 가비지 컬렉션(GC) 알고리즘입니다 [1-3]. 이 알고리즘은 살아있는 객체를 식별하는 마킹(Marking), 죽은 객체의 메모리를 해제하는 스위핑(Sweeping), 그리고 살아남은 객체들을 한곳으로 모아 메모리 단편화를 줄이는 컴팩팅(Compacting)의 세 가지 핵심 단계로 구성됩니다 [2-4]. 주로 크기가 크고 수명이 긴 객체들이 저장되는 메모리 영역의 효율적인 재사용을 위해 작동합니다 [1, 5, 6].
-
-## 📖 구조화된 지식 (Synthesized Content)
-*   **마킹(Marking) 단계**
-    *   가비지 컬렉터가 메모리 상에서 도달 가능한(살아있는) 객체를 식별하는 과정입니다 [2, 3]. 
-    *   전역 객체나 실행 스택과 같은 루트 객체(Root object)에서 시작하여 참조 포인터를 따라가며 힙 내의 모든 도달 가능한 객체를 재귀적으로 찾아냅니다 [3, 7, 8]. 
-    *   V8 엔진에서는 객체의 상태를 흰색(미발견), 회색(발견되었으나 이웃 노드 미처리), 검은색(이웃 노드까지 모두 처리)으로 분류하며 깊이 우선 탐색(DFS) 알고리즘을 사용해 마킹을 수행합니다 [7, 9]. JVM 환경에서는 마크 맵(Mark map)이라는 비트 배열을 이용해 도달 가능한 객체의 위치를 기록합니다 [10].
-
-*   **스위핑(Sweeping) 단계**
-    *   마킹 단계를 통해 도달 불가능한 것으로 판별된 죽은 객체들의 메모리 공간을 회수하는 과정입니다 [2, 3, 11].
-    *   V8 엔진은 메모리 페이지를 스캔하여 연속된 죽은 객체의 범위를 찾고, 이를 여유 공간으로 변환하여 자유 목록(Free list)에 추가함으로써 새로운 객체 할당 시 재사용될 수 있도록 합니다 [11, 12]. JVM에서도 마크 맵을 분석해 확보 가능한 메모리를 식별하고 자유 목록을 업데이트합니다 [13].
-
-*   **컴팩팅(Compacting) 단계**
-    *   스위핑 이후 힙 메모리가 심하게 단편화(Fragmented)되어 있는 경우, 살아있는 객체들을 다른 여유 공간이나 빈 페이지로 마이그레이션하여 메모리 구멍을 없애는 과정입니다 [2, 11, 14, 15].
-    *   살아있는 객체를 새 위치로 복사한 뒤, 해당 객체들을 가리키던 모든 포인터(참조)를 새로운 주소로 일일이 업데이트해야 하므로 매우 비용이 큰 작업입니다 [11, 14, 16].
-    *   이러한 높은 처리 비용 때문에 매 수집 주기마다 실행되지 않으며, 특정 조건(예: -Xcompactgc 옵션 활성화, 할당할 충분한 여유 공간 부족, 공간 단편화 심화 등)에 따라 선택적이고 제한적으로 수행됩니다 [6, 16, 17].
-
-*   **성능 최적화(Optimization) 기법**
-    *   메이저 GC의 마크-스위프-컴팩트 작업은 다량의 데이터를 스캔해야 하므로 애플리케이션의 실행을 긴 시간 동안 멈추게(Stop-the-world) 할 수 있습니다 [2, 18]. 
-    *   이를 방지하고 지연 시간(Latency)을 최소화하기 위해, V8의 최신 GC(Orinoco) 및 특정 JVM 정책은 작업을 여러 번 나누어 수행하는 점진적 마킹(Incremental marking)과 힙 페이지의 청소를 지연시키는 지연 스위핑(Lazy sweeping) 기법을 사용합니다 [18-21].
-    *   더 나아가 애플리케이션의 메인 스레드와 여러 헬퍼 스레드를 동시에 활용하는 병렬(Parallel) 및 동시(Concurrent) 처리 기법을 적용하여 전체 애플리케이션의 일시 정지 시간을 획기적으로 줄이고 있습니다 [22-25].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[Garbage Collection]], [[Old Generation/Space]], [[Memory Fragmentation]], [[Incremental Marking]]
-- **Projects/Contexts:** [[V8 Engine (JavaScript)]], [[JVM (Java Virtual Machine)]], [[Orinoco Garbage Collector]]
-- **Contradictions/Notes:** 소스 자료 전반에 걸쳐 큰 모순은 존재하지 않습니다. 다만, 컴팩팅(Compacting) 작업은 메모리 파편화를 완전히 해결하는 훌륭한 방법이지만 V8과 JVM 두 환경 모두에서 매우 무겁고 값비싼(expensive) 동작으로 공통되게 취급되며, 항상 실행되지 않고 철저한 휴리스틱이나 임계조건에 의해 선택적으로 발동된다는 점이 강조됩니다 [6, 16, 17].
-
----
-*Last updated: 2026-04-19*
-- Raw Source: [[00_Raw/2026-04-20/Mark-Sweep-Compact(메이저 GC).md]]
----
diff --git a/Programming & Language/Mark-Sweep-Compact.md b/Programming & Language/Mark-Sweep-Compact.md
deleted file mode 100644
index 29bb2108..00000000
--- a/Programming & Language/Mark-Sweep-Compact.md	
+++ /dev/null
@@ -1,41 +0,0 @@
----
-id: P-REINFORCE-AUTO-1D592D
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Mark-Sweep-Compact"
----
-
-# [[Mark-Sweep-Compact]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-**동작 원리 및 주요 단계**
-*   **마킹(Marking) 단계:** 힙 상의 모든 활성(Live) 객체를 발견하고 표시하는 과정입니다 [3]. 메모리 힙을 객체들이 포인터로 연결된 방향성 그래프로 간주하여, 루트(root) 객체에서 시작해 깊이 우선 탐색(Depth-First-Search)을 수행합니다 [8, 9]. 객체는 처리 상태에 따라 흰색(미발견), 회색(발견되었으나 이웃 미처리), 검은색(발견 및 이웃 처리 완료)으로 구분됩니다 [3, 10]. 마킹이 종료되면 검은색은 활성 객체, 흰색은 죽은 객체를 의미합니다 [4, 11].
-*   **스위핑(Sweeping) 단계:** 마킹 맵을 스캔하여 마킹되지 않은(흰색) 죽은 객체들의 연속된 범위를 찾고, 이를 빈 공간(Free space)으로 변환하여 크기별 프리 리스트(Free lists)에 추가합니다 [4, 12, 13].
-*   **컴팩팅(Compacting) 단계:** 파편화가 심한 페이지에 있는 객체들을 다른 페이지의 빈 공간으로 이주(Migration)시켜 실제 메모리 사용량을 줄입니다 [5, 14]. 객체가 복사된 후 기존 객체의 첫 번째 워드에 포워딩 주소(Forwarding address)를 남기고, 대피가 완료되면 시스템은 기록된 포인터 위치를 순회하며 참조를 새 위치로 업데이트합니다 [5, 10].
-
-**V8 엔진에서의 활용 (Major GC)**
-*   V8 엔진에서는 메가바이트 단위 이상의 크기를 갖는 'Old Space(오래된 세대)'를 수집할 때 마크-스윕(Mark-sweep) 및 마크-컴팩트(Mark-compact) 알고리즘을 사용합니다 [1, 10].
-*   과거에는 전체 실행을 멈추는 "Stop-the-world" 방식으로 인해 500-1000ms의 긴 일시 정지가 발생했으나, 메인 스레드의 부담을 줄이기 위해 증분 마킹(Incremental marking)과 지연 스위핑(Lazy sweeping), 그리고 백그라운드 스레드를 활용하는 동시 마킹/스위핑(Concurrent marking/sweeping) 등의 최적화가 도입되었습니다 [15-18].
-
-**IBM Java GC에서의 활용**
-*   Java 가비지 컬렉터에서도 마크와 스윕은 메모리를 재확보하는 핵심 사이클로 함께 작동합니다 [19].
-*   그러나 컴팩트(Compact) 작업은 객체의 참조(Reference)를 모두 변경해야 하므로 매우 비용이 많이 드는(Expensive) 작업으로 간주됩니다 [7]. 따라서 컴팩트 작업은 기본적으로 매번 발생하지 않으며, `-Xcompactgc` 옵션을 명시하거나 힙을 스위핑한 후에도 할당 요청을 충족할 공간이 부족할 때 등 특정한 트리거 조건 하에서만 수행됩니다 [7, 20].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[Garbage Collection]], [[Old Generation]], [[Incremental Marking]], [[Memory Fragmentation]]
-- **Projects/Contexts:** [[V8 JavaScript Engine]], [[IBM Java GC]], [[Orinoco Garbage Collector]]
-- **Contradictions/Notes:** 컴팩트(Compact) 단계의 빈도와 관련하여, V8에서는 Old Space의 파편화를 줄이기 위해 Major GC 과정에서 컴팩팅을 통합적으로 활용하여 객체를 마이그레이션하는 반면 [5, 10], IBM Java GC 환경에서는 객체 이동에 따른 높은 오버헤드로 인해 컴팩트 단계가 기본 활성화 상태가 아니며 메모리 부족이나 명시적 설정 시에만 제한적으로 트리거된다는 차이가 있습니다 [7, 21].
-
----
-*Last updated: 2026-04-19*
-- Raw Source: [[00_Raw/2026-04-20/Mark-Sweep-Compact.md]]
----
diff --git a/Programming & Language/Mark-Sweep.md b/Programming & Language/Mark-Sweep.md
deleted file mode 100644
index f3ae17d6..00000000
--- a/Programming & Language/Mark-Sweep.md	
+++ /dev/null
@@ -1,44 +0,0 @@
----
-id: P-REINFORCE-AUTO-261A28
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Mark-Sweep"
----
-
-# [[Mark-Sweep]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> Mark-Sweep(마크-스위프)는 V8 엔진과 JVM 등에서 오래된 객체(Old Space/Generation)의 메모리를 회수하기 위해 주로 사용되는 가비지 컬렉션(GC) 알고리즘입니다 [1-4]. 이 알고리즘은 힙 메모리 내의 모든 활성 객체를 식별하여 표시하는 '마킹(Marking)' 단계와, 표시되지 않은 죽은 객체의 메모리 영역을 해제하는 '스위핑(Sweeping)' 단계로 동작합니다 [2, 5]. 기존에는 긴 애플리케이션 일시 정지(Stop-the-world)를 유발했으나, 현대의 엔진들은 점진적(Incremental), 지연(Lazy), 그리고 병행(Concurrent) 처리 기법을 결합하여 성능 오버헤드를 크게 줄였습니다 [6-9].
-
-## 📖 구조화된 지식 (Synthesized Content)
-* **마킹(Marking) 단계**
-  * 마킹 알고리즘은 본질적으로 포인터로 연결된 객체 그래프를 루트(Roots)에서부터 추적하는 깊이 우선 탐색(Depth-First-Search)입니다 [4, 10, 11].
-  * V8 엔진에서는 각 페이지에 할당 가능한 단어(word)당 하나의 비트를 갖는 마킹 비트맵(Marking bitmap)을 유지하며, 객체의 마킹 상태를 세 가지 색상(흰색, 회색, 검은색)으로 분류합니다 [4, 12]. 
-  * 흰색(White)은 아직 GC가 발견하지 못한 상태, 회색(Grey)은 발견되었으나 이웃 객체들이 모두 처리되지 않은 상태, 검은색(Black)은 발견되었고 모든 이웃 객체까지 처리가 완료된 활성 상태를 의미합니다 [12, 13].
-  * 마킹 과정 중 객체들은 '마킹 데크(Marking deque)'라는 버퍼에 저장되며, 큐가 비워지고 모든 발견된 객체가 검은색으로 표시될 때까지 탐색이 반복됩니다 [10, 13].
-
-* **스위핑(Sweeping) 단계**
-  * 마킹이 완료된 후, 스위핑 알고리즘은 힙을 스캔하여 흰색으로 남은 죽은 객체들의 연속된 범위를 찾아냅니다 [4, 14, 15].
-  * 확인된 죽은 객체의 메모리 공간을 여유 공간(Free space)으로 변환하고 이를 '자유 목록(Free list)'에 추가하여 새로운 객체 할당 시 재사용할 수 있도록 합니다 [14-16].
-  * V8에서는 페이지 수준에서 작동하며, 객체의 크기(소형, 중형, 대형 등)에 따라 별도의 자유 목록을 유지 관리합니다 [14, 16].
-
-* **최적화 및 발전 (Optimization)**
-  * 전체 힙을 대상으로 하는 마크-스위프는 시간이 오래 걸려 500-1000ms 수준의 'Stop-the-world' 일시 정지를 유발할 수 있었습니다 [6].
-  * 이를 완화하기 위해 V8은 힙 마킹을 5-10ms 단위의 작은 작업으로 나누어 실행하는 **점진적 마킹(Incremental marking)**과 메모리 해제를 즉시 전부 수행하지 않고 필요에 따라 미루는 **지연 스위핑(Lazy sweeping)**을 도입했습니다 [6, 7, 17, 18].
-  * 최근의 Orinoco 가비지 컬렉터 및 JVM 정책에서는 메인 스레드 실행에 영향을 주지 않기 위해 백그라운드 스레드에서 작업을 수행하는 **병행(Concurrent) 마킹 및 스위핑** 기술을 활용하여 대기 시간을 획기적으로 최소화했습니다 [8, 9, 19].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[Garbage Collection]], [[Old Generation]], [[Mark-Compact]], [[Incremental Marking]], [[Lazy Sweeping]]
-- **Projects/Contexts:** [[V8 JavaScript Engine]], [[JVM (Java Virtual Machine)]], [[Orinoco Garbage Collector]]
-- **Contradictions/Notes:** 마크-스위프는 빠르고 공간을 효과적으로 재활용하지만, 메모리 파편화(Fragmentation)를 유발할 수 있습니다. 따라서 V8에서는 파편화가 심한 페이지의 라이브 객체를 이동시키고 빈 공간을 병합하는 [[Mark-Compact]] 알고리즘과 밀접하게 연계되어 사용됩니다 [2, 4, 5, 20]. 또한, Node.js 환경에서 `--trace_gc` 로그 상에 'Mark-sweep'이 지나치게 자주 발생하거나 반환되는 메모리가 미미하다면 애플리케이션 내 메모리 누수(Memory Leak)나 CPU 집약적 블로킹 작업이 존재할 가능성이 높습니다 [21, 22].
-
----
-*Last updated: 2026-04-19*
-- Raw Source: [[00_Raw/2026-04-20/Mark-Sweep.md]]
----
diff --git a/Programming & Language/Mechanobiology.md b/Programming & Language/Mechanobiology.md
deleted file mode 100644
index af9c6b8d..00000000
--- a/Programming & Language/Mechanobiology.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-D8F1A7
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Mechanobiology"
----
-
-# [[Mechanobiology]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Mechanobiology.md]]
----
diff --git a/Programming & Language/Meltdown.md b/Programming & Language/Meltdown.md
deleted file mode 100644
index 8337fc0b..00000000
--- a/Programming & Language/Meltdown.md	
+++ /dev/null
@@ -1,30 +0,0 @@
----
-id: P-REINFORCE-AUTO-0BF53B
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Meltdown"
----
-
-# [[Meltdown]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> Meltdown은 현대의 프로세서에 영향을 미치는 보안 취약점으로, 공격자가 보호되어야 할 비밀 메모리 영역에 읽기 권한을 얻을 수 있게 합니다 [1]. 구체적으로는 웹 브라우저에서 실행되는 JavaScript와 같은 사용자 영역(userland)의 코드가 커널 메모리를 읽을 수 있게 만듭니다 [2]. 웹 브라우저(예: WebKit)를 통해 Meltdown 공격을 수행하려면, 먼저 Spectre 취약점을 이용해 브라우저의 보안 속성을 우회하는 과정이 선행되어야 합니다 [1, 2].
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[Spectre]], [[Side-channel attacks]], [[Web Timing Security]]
-- **Projects/Contexts:** [[WebKit]], [[Blink]]
-- **Contradictions/Notes:** 제공된 소스 내에서 모순되는 내용은 확인되지 않으며, Meltdown 방어를 위해 운영체제 수준의 완화와 브라우저(WebKit, Blink) 수준의 타이밍 정밀도 제한 및 Spectre 방어 조치가 상호 보완적으로 작용함을 강조하고 있습니다 [2, 4].
-
----
-*Last updated: 2026-04-19*
-- Raw Source: [[00_Raw/2026-04-20/Meltdown.md]]
----
diff --git a/Programming & Language/Memory Leak(메모리 누수).md b/Programming & Language/Memory Leak(메모리 누수).md
deleted file mode 100644
index 5c0faadd..00000000
--- a/Programming & Language/Memory Leak(메모리 누수).md	
+++ /dev/null
@@ -1,32 +0,0 @@
----
-id: P-REINFORCE-AUTO-D05474
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Memory Leak(메모리 누수)"
----
-
-# [[Memory Leak(메모리 누수)]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 메모리 누수(Memory Leak)는 프로그램이 더 이상 필요하지 않은 메모리를 해제하지 않아, 해당 메모리가 운영체제의 가용 메모리 풀로 반환되지 않는 현상을 의미합니다 [1]. JavaScript와 같은 가비지 컬렉션(GC) 기반 언어에서는 메모리가 단순히 유실되는 것이 아니라, 더 이상 사용되지 않아야 할 객체들이 GC 루트(window, 활성 클로저, 이벤트 리스너, 타이머 등)에서 여전히 참조 가능(reachable)한 상태로 남아 있어 가비지 컬렉터가 이를 회수하지 못할 때 발생합니다 [2, 3]. 이러한 누수가 누적되면 애플리케이션의 성능이 저하되고 잦은 가비지 컬렉션 일시 정지를 유발하며, 최종적으로는 메모리 고갈로 인한 크래시(OOM, Out-Of-Memory)로 이어지게 됩니다 [1, 4, 5].
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[Garbage Collection(가비지 컬렉션)]], [[V8 JavaScript Engine]], [[Heap Snapshot(힙 스냅샷)]], [[Closure(클로저)]]
-- **Projects/Contexts:** [[Frontend Browser Diagnostics]], [[Node.js Production Monitoring]]
-- **Contradictions/Notes:** 
-    * 메모리가 증가한다고 해서 무조건 누수인 것은 아닙니다. 캐시나 실행 취소 내역(undo histories) 등은 의도적으로 데이터를 보존하므로, 소스에서는 '의도적 보존(intentional retention)'과 '우발적 누수(accidental retention)'를 명확히 구분해야 한다고 강조합니다 [12].
-    * `WeakRef`와 `FinalizationRegistry`를 사용해 가비지 컬렉션을 방해하지 않는 참조 패턴을 만들 수 있지만, 가비지 컬렉터의 실행 일정은 비결정적(non-deterministic)이므로 이를 적절한 수명 주기 관리(lifecycle management)의 대체재로 사용해서는 안 됩니다 [11].
-
----
-*Last updated: 2026-04-19*
-- Raw Source: [[00_Raw/2026-04-20/Memory Leak(메모리 누수).md]]
----
diff --git a/Programming & Language/Memory Leak.md b/Programming & Language/Memory Leak.md
deleted file mode 100644
index 4ff6b852..00000000
--- a/Programming & Language/Memory Leak.md	
+++ /dev/null
@@ -1,30 +0,0 @@
----
-id: P-REINFORCE-AUTO-61D625
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Memory Leak"
----
-
-# [[Memory Leak]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 메모리 누수(Memory Leak)는 프로그램이 더 이상 필요하지 않은 메모리를 반환하지 않고 계속 참조를 유지하여 지속적으로 메모리를 점유하는 현상입니다[1, 2]. JavaScript 환경에서 메모리 누수는 메모리가 유실되는 것이 아니라, 객체가 가비지 컬렉터(GC) 루트(window, 클로저, 이벤트 리스너 등)에서 여전히 도달 가능(reachable)한 상태로 남아 있어 GC가 이를 회수하지 못할 때 발생합니다[3, 4]. 이러한 누수가 장기간 누적되면 가비지 컬렉션 일시 정지가 잦아지고 응답 시간이 저하되며, 결국 메모리 한계를 초과하여 OOM(Out of Memory) 크래시를 유발할 수 있습니다[1, 5, 6].
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[Garbage Collection]], [[V8 Engine]], [[Heap Snapshot]], [[Allocation Timeline]]
-- **Projects/Contexts:** [[Browser Application]], [[Node.js Server Production]]
-- **Contradictions/Notes:** 소스에 따르면 `WeakRef`나 `FinalizationRegistry`와 같은 최신 도구를 누수 방지 패턴에 활용할 수는 있으나, GC의 실행 시점이 비결정적이므로 이러한 도구들이 명시적인 생명주기 관리(정확한 타이머 및 리스너 해제)를 완전히 대체할 수는 없다고 지적합니다[12].
-
----
-*Last updated: 2026-04-19*
-- Raw Source: [[00_Raw/2026-04-20/Memory Leak.md]]
----
diff --git a/Programming & Language/Mesa-Optimization (메사 최적화).md b/Programming & Language/Mesa-Optimization (메사 최적화).md
deleted file mode 100644
index 00b806de..00000000
--- a/Programming & Language/Mesa-Optimization (메사 최적화).md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-4AF7B4
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Mesa-Optimization (메사 최적화)"
----
-
-# [[Mesa-Optimization (메사 최적화)]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Mesa-Optimization (메사 최적화).md]]
----
diff --git a/Programming & Language/Microsoft Edge DevTools.md b/Programming & Language/Microsoft Edge DevTools.md
deleted file mode 100644
index dc31bd88..00000000
--- a/Programming & Language/Microsoft Edge DevTools.md	
+++ /dev/null
@@ -1,37 +0,0 @@
----
-id: P-REINFORCE-AUTO-D3063D
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Microsoft Edge DevTools"
----
-
-# [[Microsoft Edge DevTools]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-- **DevTools 실행 및 접근 방법:** 웹페이지에서 마우스 우클릭 후 **Inspect(검사)**를 선택하거나 단축키(`Ctrl+Shift+I` 또는 macOS의 경우 `Command+Option+I`)를 눌러 DevTools를 열 수 있습니다 [1]. 이후 Activity Bar에서 **Memory** 도구를 선택하여 메모리 프로파일링 기능에 접근합니다 [1].
-- **타임라인의 할당 계측 (Allocations on timeline):** JS 힙에서 메모리 누수를 추적하기 위한 DevTools의 주요 기능 중 하나입니다 [3]. 이 기능은 힙 프로파일러의 상세한 스냅샷 정보와 Performance 도구의 점진적인 업데이트 및 추적 기능을 결합하여 작동합니다 [2]. 기록 세션 동안 주기적으로(최대 50ms마다) 힙 스냅샷을 찍고, 기록이 끝날 때 최종 스냅샷을 생성합니다 [4].
-- **메모리 누수 식별 및 분석:** 
-  - 기록 중 타임라인에 나타나는 막대의 높이는 최근 할당된 객체의 크기를 나타냅니다 [5].
-  - **파란색 막대**는 타임라인이 끝날 때까지 여전히 살아있는(가비지 컬렉션되지 않은) 객체를 나타내며, 메모리 누수의 주요 후보가 됩니다 [3, 5].
-  - **회색 막대**는 할당되었으나 이후 가비지 컬렉션으로 정리된 객체를 의미합니다 [5].
-  - 특정 막대를 확대하여 해당 기간에 할당된 객체만 표시하도록 필터링할 수 있으며, 힙 하단에서 유지 트리(retaining tree)와 경로를 검사해 객체가 수집되지 않은 원인을 분석할 수 있습니다 [3, 6].
-- **영구 객체 ID 추적:** 가비지 컬렉션 진행 중에 객체들의 메모리 주소가 이동할 수 있으므로, DevTools는 메모리 주소를 표시하는 대신 '@' 기호 뒤에 고유한 객체 ID를 부여합니다. 이 ID는 여러 스냅샷에 걸쳐 유지되어 힙 상태를 정확하게 비교할 수 있게 해줍니다 [4].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[Memory Tool]], [[Garbage Collection]], [[Heap Snapshot]], [[Memory Leak]]
-- **Projects/Contexts:** [[Allocation instrumentation on timeline]]
-- **Contradictions/Notes:** 소스에 관련 정보가 부족합니다. Microsoft Edge DevTools의 전체적인 구조나 다른 패널(네트워크, 콘솔 등)에 대한 설명은 없으며, 오직 Memory 패널 내부의 타임라인 할당 프로파일링 도구에 대해서만 설명하고 있습니다.
-
----
-*Last updated: 2026-04-19*
-- Raw Source: [[00_Raw/2026-04-20/Microsoft Edge DevTools.md]]
----
diff --git a/Programming & Language/Model-Checking.md b/Programming & Language/Model-Checking.md
deleted file mode 100644
index a4683aa6..00000000
--- a/Programming & Language/Model-Checking.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-D4D8C1
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Model-Checking"
----
-
-# [[Model-Checking]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Model-Checking.md]]
----
diff --git a/Programming & Language/Monorepo(Turborepo 등) 환경의 린트 관리.md b/Programming & Language/Monorepo(Turborepo 등) 환경의 린트 관리.md
deleted file mode 100644
index 1a1cc40e..00000000
--- a/Programming & Language/Monorepo(Turborepo 등) 환경의 린트 관리.md	
+++ /dev/null
@@ -1,40 +0,0 @@
----
-id: P-REINFORCE-AUTO-9CC04F
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Monorepo(Turborepo 등) 환경의 린트 관리"
----
-
-# [[Monorepo(Turborepo 등) 환경의 린트 관리]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> Turborepo와 같은 모노레포(Monorepo) 환경에서는 다수의 패키지와 애플리케이션으로 인해 ESLint 및 Prettier 설정이 중복되고 일관성이 떨어지는 문제가 발생할 수 있습니다 [1]. 이를 해결하기 위해 중앙 집중식 설정 패키지를 구성하고, 모노레포 루트(Root)에서 파일 패턴을 매핑하여 린트 규칙을 조율(Orchestration)하는 방식이 권장됩니다 [2], [3]. 이러한 방식을 적용하면 각 패키지의 고유한 규칙을 존중하면서도 Turborepo의 캐싱 기능과 `lint-staged`를 활용해 린트 속도를 높이고 유지보수성을 극대화할 수 있습니다 [4], [5].
-
-## 📖 구조화된 지식 (Synthesized Content)
-* **모노레포 린트 관리의 주요 문제점**
-  모노레포 환경은 보통 여러 애플리케이션(예: Next.js)과 라이브러리 패키지로 구성됩니다. 이로 인해 각 패키지마다 `.eslintrc.json`과 `.eslintignore` 파일, 그리고 관련 의존성이 흩어져 중복되는 유지보수 문제가 발생합니다 [1]. 특히 사전 커밋(pre-commit) 단계에서 루트 수준의 `lint-staged`를 실행할 때, 패키지별로 다른 린팅 규칙을 동시에 존중하면서 변경된 파일만 검사하도록 만드는 것이 가장 큰 과제입니다 [2].
-
-* **중앙 집중식 설정 패키지 구축**
-  이러한 문제를 해결하기 위해 `@repo/eslint-config`와 같은 내부 전용 설정 패키지를 생성하여 린트 규칙의 단일 진실 공급원(Single source of truth)으로 활용합니다 [2], [6]. 이 패키지 내부에는 기본(Base), Next.js용, 일반 라이브러리용과 같이 조합 가능한 사전 설정(Preset)을 구성해 둡니다 [7], [8]. ESLint 9의 Flat Config 형식(`eslint.config.mjs`)을 사용하며, 모노레포 내의 개별 패키지들은 각자의 설정 파일에서 필요한 프리셋만 가져와(import) 사용함으로써 코드 중복을 줄이고 자율성을 유지할 수 있습니다 [7], [6].
-
-* **루트 오케스트레이션 (Root Orchestration)**
-  모노레포의 루트에 오케스트레이션을 위한 `eslint.config.mjs` 파일을 생성합니다. 파일 글로브(glob) 패턴을 사용하여 전역 기본 규칙을 적용하는 동시에, 각 파일이 속한 패키지에 맞는 설정(예: Next.js 패키지 또는 라이브러리 패키지 규칙)으로 정확히 매핑합니다 [3]. 이 조율 과정을 통해 패키지 간의 경계를 침범하지 않고 알맞은 린트 규칙을 강제할 수 있습니다 [3].
-
-* **Husky, lint-staged 및 Turborepo 통합**
-  오케스트레이션이 설정되면, 루트의 `package.json`과 `.husky/pre-commit` 훅에 `lint-staged`를 연결합니다 [4]. 이를 통해 커밋 시 변경된 파일들만 린트하게 되며, 루트 설정 파일이 대상 파일을 패키지별 올바른 규칙으로 라우팅해 줍니다 [4]. 추가로 `turbo.json`의 전역 의존성에 ESLint 설정 패키지를 명시하면, 설정이 변경될 때만 캐시를 무효화하고 평상시에는 린트 결과를 캐싱하게 되어 전체적인 작업 속도가 획기적으로 개선됩니다 [4], [5].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[ESLint]], [[Prettier]], [[Husky]], [[lint-staged]]
-- **Projects/Contexts:** [[Turborepo]]
-- **Contradictions/Notes:** 소스에 관련 정보가 부족합니다. (모노레포 린트 관리 방식과 관련해 소스 내에서 서로 상충되는 주장이나 모순되는 정보는 확인되지 않습니다.)
-
----
-*Last updated: 2026-04-18*
-- Raw Source: [[00_Raw/2026-04-20/Monorepo(Turborepo 등) 환경의 린트 관리.md]]
----
diff --git a/Programming & Language/Monorepo.md b/Programming & Language/Monorepo.md
deleted file mode 100644
index 0a482a1c..00000000
--- a/Programming & Language/Monorepo.md	
+++ /dev/null
@@ -1,33 +0,0 @@
----
-id: P-REINFORCE-AUTO-D52D12
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Monorepo"
----
-
-# [[Monorepo]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 모노레포(Monorepo)는 다수의 애플리케이션과 라이브러리 패키지(공유 컴포넌트, 유틸리티 등)를 포함하는 서로 연결된 여러 패키지들을 단일 저장소(Repository)에서 관리하는 소프트웨어 아키텍처입니다 [1, 2]. 대규모 프로젝트의 코드 공유를 용이하게 하지만, 패키지마다 개별적인 설정이 중복될 경우 '설정 드리프트(Configuration Drift)' 현상과 같은 유지보수의 어려움을 초래할 수 있습니다 [2, 3]. 이를 효과적으로 관리하기 위해 설정의 중앙 집중화와 루트(Root) 레벨에서의 오케스트레이션(Orchestration) 전략이 활용됩니다 [4, 5].
-
-## 📖 구조화된 지식 (Synthesized Content)
-* **대규모 모노레포의 관리 문제점:** 전형적인 모노레포는 Next.js와 같은 사용자/관리자용 애플리케이션과 데이터 파서, 타입, API 클라이언트 등의 공유 라이브러리로 구성됩니다 [1]. 규모가 커질수록 수십 개의 패키지에 ESLint, Prettier 등의 설정 파일이 중복해서 생성되며, 이는 일관되지 않은 규칙 적용, 의존성 중복, 그리고 개별 패키지에 맞춘 `lint-staged` 실행의 어려움 등 심각한 유지보수 악몽(Maintenance Nightmare)으로 이어집니다 [1-3].
-* **중앙 집중식 설정 (Centralised Configuration):** 설정 드리프트를 방지하기 위해 단일 진실의 원천(Single Source of Truth) 역할을 하는 중앙 집중식 설정 패키지(예: `@repo/eslint-config`)를 생성하여 활용합니다 [2, 4, 6]. 베이스 규칙을 정의하고 필요한 프레임워크나 라이브러리 환경에 맞게 조합(Composable)하여 사용함으로써, 린팅 규칙 변경이나 보안 업데이트를 전체 모노레포에 동시다발적으로 쉽게 전파할 수 있습니다 [2, 4].
-* **루트 오케스트레이션 (Root Orchestration):** 모노레포 환경에서 Husky와 lint-staged 같은 도구가 각 패키지의 규칙을 준수하면서도 효율적으로 동작하게 하려면, 루트(Root) 레벨에서 파일 패턴별로 적절한 패키지 설정을 매핑하는 오케스트레이션 설정이 필요합니다 [4, 7, 8]. 이를 통해 패키지 간의 자율성을 보장하면서도 중앙에서 도구를 통제할 수 있습니다 [7, 8].
-* **빌드 도구 캐싱 활용:** 중앙 집중화된 설정 패키지를 Turborepo 등의 글로벌 의존성(Global Dependency)으로 설정하면, 규칙 변경 시 모든 패키지의 캐시를 올바르게 무효화하면서도 변경된 파일에 대해서만 빠른 린팅과 검사를 수행할 수 있습니다 [9]. (참고로 모노레포 도구 생태계에는 Turborepo 외에도 Nx, Bazel, Lerna 등이 존재합니다 [10, 11]).
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[ESLint]], [[Prettier]], [[lint-staged]], [[Husky]], [[Turborepo]]
-- **Projects/Contexts:** [[대규모 소프트웨어 엔지니어링 및 CI/CD 파이프라인]], [[자동화된 코드 거버넌스(Automated Governance)]]
-- **Contradictions/Notes:** 모노레포 내 `lint-staged` 적용과 관련하여 `lint-staged`의 공식 지침은 저장소 루트에 도구를 설치하고 각 패키지에 완전히 격리된 별도의 설정 파일을 두는 것을 권장하지만 [12, 13], Turborepo를 활용하는 모던 아키텍처 환경에서는 루트에 오케스트레이션 설정 하나를 두고 파일 패턴을 각 패키지 환경에 매핑하는 방식이 더 나은 개발자 경험(DX)을 제공하는 대안으로 제시되기도 합니다 [4, 8].
-
----
-*Last updated: 2026-04-19*
-- Raw Source: [[00_Raw/2026-04-20/Monorepo.md]]
----
diff --git a/Programming & Language/Multi-Agent-Systems.md b/Programming & Language/Multi-Agent-Systems.md
deleted file mode 100644
index 61e5f83c..00000000
--- a/Programming & Language/Multi-Agent-Systems.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-E9AAEE
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Multi-Agent-Systems"
----
-
-# [[Multi-Agent-Systems]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Multi-Agent-Systems.md]]
----
diff --git a/Programming & Language/NPM Ecosystem.md b/Programming & Language/NPM Ecosystem.md
deleted file mode 100644
index 807afd0e..00000000
--- a/Programming & Language/NPM Ecosystem.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-B38BB3
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - NPM Ecosystem"
----
-
-# [[NPM Ecosystem]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/NPM Ecosystem.md]]
----
diff --git a/Programming & Language/Netflix 마이크로서비스 전환.md b/Programming & Language/Netflix 마이크로서비스 전환.md
deleted file mode 100644
index c363150a..00000000
--- a/Programming & Language/Netflix 마이크로서비스 전환.md	
+++ /dev/null
@@ -1,41 +0,0 @@
----
-id: P-REINFORCE-AUTO-7C6103
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Netflix 마이크로서비스 전환"
----
-
-# [[Netflix 마이크로서비스 전환]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> Netflix의 마이크로서비스 전환은 혁신성, 신뢰성, 효율성을 개선하기 위해 기존의 거대한 모놀리식 아키텍처를 독립적으로 배포 및 확장이 가능한 작은 서비스 단위로 쪼갠 7년간의 대규모 마이그레이션 과정입니다 [1, 2]. 이 과정에서 무상태(Stateless) 서비스 지향, 수평적 확장, 데이터베이스의 NoSQL(Cassandra) 전환 및 자동화된 파괴 테스트(Chaos Monkey)를 원칙으로 삼아 99.999%의 높은 가용성을 확보했습니다 [2-4]. 최근에는 모놀리식화된 기존 시스템의 한계를 극복하고자 API, 워크플로우, 서버리스 함수가 결합된 차세대 마이크로서비스 플랫폼인 'Cosmos'를 도입하여 시스템을 한 단계 더 진화시키고 있습니다 [5, 6].
-
-## 📖 구조화된 지식 (Synthesized Content)
-- **초기 아키텍처와 전환 배경:** Netflix는 2008년 8월 데이터 센터와 RDBMS를 기반으로 한 모놀리식 아키텍처로 서비스를 시작했으나, 시스템의 단단한 결합(tight coupling)으로 인해 빠른 혁신과 잦은 배포가 불가능했습니다 [2, 7]. 개발 속도를 높이고 높은 가용성을 달성하기 위해 7년에 걸쳐 작은 독립적인 서비스들로 구성된 마이크로서비스 아키텍처로의 전환을 단행했습니다 [1, 2].
-- **전환의 핵심 원칙 (First Principles):** 
-  - **구축보다 구매 (Buy vs. Build):** 가능하면 오픈소스(OSS) 기술을 우선적으로 사용하고, 꼭 필요한 기능만 직접 구축합니다 [2].
-  - **무상태(Stateless) 서비스와 수평적 확장:** 지속성이나 캐싱 계층을 제외한 모든 서비스는 상태를 유지하지 않도록(Stateless) 설계하여, 수직적 확장(Scale up)의 한계를 피해 수평적 확장(Scale out)을 지향합니다 [2, 3].
-  - **이중화와 격리 (Redundancy and Isolation):** 다중 지역(Multi-Regional) 복제 구성을 채택하고, 장애 발생 시 파급 반경(Blast radius)을 격리하여 복원력을 높입니다 [3]. 
-  - **파괴 테스트 자동화:** Simian Army의 Chaos Monkey 등을 활용하여 의도적으로 결함을 주입하고 파괴 테스트를 자동화함으로써 시스템의 신뢰성을 지속적으로 검증합니다 [3].
-  - **데이터베이스 마이그레이션:** 대규모 확장에 불리한 기존의 RDBMS 대신 확장성, 파티션 내구성, 가용성이 뛰어난 NoSQL인 Cassandra로 전환했습니다 [3].
-- **운영 효과 및 한계:** 마이크로서비스 구조는 클린 아키텍처의 높은 응집도와 낮은 결합도 개념을 적용하여, 컨테이너 및 Kubernetes를 통해 수백만 명의 사용자를 위한 탄력적인 확장을 제공합니다 [8, 9]. Netflix는 이를 통해 연간 단 52분의 다운타임만 허용하는 99.999%(4 9's)의 가용성을 목표로 합니다 [4]. 그러나 분산 시스템으로 변모하면서 서비스 간 통신 메커니즘 처리, 여러 팀의 조율, JVM/VM 추가 구동에 따른 메모리 소비 급증과 같은 복잡성 및 비용의 증가라는 단점도 수반되었습니다 [10-12].
-- **차세대 마이크로서비스 플랫폼 'Cosmos' 도입:**
-  - 시간이 지나면서 기존의 3세대 미디어 처리 시스템('Reloaded') 또한 비대해져 모놀리스와 같이 인프라와 애플리케이션 코드가 뒤섞이는 운영상 병목을 일으켰습니다 [13-15].
-  - 이를 해결하기 위해 워크플로우 기반 미디어 중심 마이크로서비스 플랫폼인 'Cosmos'를 구축했습니다 [5]. Cosmos는 외부 요청을 처리하는 API 계층(Optimus), 비즈니스 규칙을 모델링하는 워크플로우 계층(Plato), 계산 집약적이고 상태가 없는 작업을 실행하는 서버리스 함수 계층(Stratum)으로 관심사를 횡단 및 논리적으로 철저히 분리했습니다 [15, 16].
-  - 레거시 시스템에서 Cosmos로의 이전은 점진적으로 기존 시스템을 둘러싸며 대체하는 교살자 무화과(Strangler fig) 패턴을 적용하여 리스크를 최소화하고 있습니다 [17].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[모놀리식 아키텍처]], [[수평적 확장 (Scale out)]], [[Cassandra]], [[오픈소스 (OSS)]], [[서버리스 함수]]
-- **Projects/Contexts:** [[Reloaded 시스템]], [[Cosmos 플랫폼]], [[Chaos Monkey (Simian Army)]]
-- **Contradictions/Notes:** 마이크로서비스 아키텍처는 혁신과 배포 속도 향상이라는 큰 장점을 가져다주었지만, 반대로 구현 시 분산 시스템의 복잡성을 관리해야 하고 다수의 서비스 인스턴스를 실행하는 데 따른 심각한 메모리 사용량(오버헤드) 증가를 초래한다는 구조적 한계점이 소스에서 분명히 지적되고 있습니다 [10, 11].
-
----
-*Last updated: 2026-04-18*
-- Raw Source: [[00_Raw/2026-04-20/Netflix 마이크로서비스 전환.md]]
----
diff --git a/Programming & Language/Network Coordinate Systems.md b/Programming & Language/Network Coordinate Systems.md
deleted file mode 100644
index c1f0b6e7..00000000
--- a/Programming & Language/Network Coordinate Systems.md	
+++ /dev/null
@@ -1,45 +0,0 @@
----
-id: P-REINFORCE-AUTO-BF761A
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Network Coordinate Systems"
----
-
-# [[Network Coordinate Systems]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 네트워크 좌표 시스템(Network Coordinate Systems)은 대규모 분산 시스템에서 인터넷 지연 시간(latency)을 다차원 기하학적 공간으로 모델링하는 확장 가능한 지연 시간 추정 시스템입니다 [1]. 소수의 전용 '랜드마크(landmark)' 노드를 기준으로 측정된 기본 지연 시간을 통해 각 호스트 노드에 해당 공간 내의 특정 좌표를 부여합니다 [1]. 이를 통해 개별적인 통신 프로빙을 일일이 수행하지 않더라도, 두 노드 간의 지연 시간을 각 좌표 간의 유클리드 거리(Euclidean distance)로 쉽게 근사할 수 있습니다 [1].
-
-## 📖 구조화된 지식 (Synthesized Content)
-- **기본 작동 원리 및 공간 모델링:**
-  - 대표적인 접근 방식인 GNP(Global Network Positioning)는 인터넷 노드들을 N차원 기하학적 공간에 배치합니다 [2]. 
-  - 이를 위해 전역적으로 분산된 최소 N+1개의 랜드마크 노드가 서로 간의 지연 시간을 측정하여 초기 공간을 형성하며, 랜드마크 좌표 간의 거리가 실제 측정된 지연 시간과 최대한 일치하도록 Simplex-downhill과 같은 오차 최소화 알고리즘을 사용합니다 [2, 3].
-  - 랜드마크 좌표가 설정되면, 각 인터넷 호스트 노드는 랜드마크들과 측정한 지연 시간(base latencies)을 바탕으로 삼각측량(triangulation) 방식으로 자신의 좌표를 계산합니다 [2, 4].
-
-- **측정 방식의 한계 극복 및 구현 기법:**
-  - 기존 시스템들은 위치 측정을 위해 각 노드들의 적극적인 참여(active participation)를 요구했으나, 이는 악의적 노드의 정보 조작이나 랜드마크 서버의 과부하 위험성을 수반했습니다 [5].
-  - 대규모 배포(예: 구글 CDN)에서는 이를 해결하기 위해 중앙 집중식 스케줄러를 도입하여 랜드마크의 과부하를 방지합니다 [6, 7]. 또한, 클라이언트의 직접적인 참여나 별도 소프트웨어 설치 없이, TCP 핸드셰이크 단계에서 동작하는 SYNACK/ACK 기법을 활용한 수동적 지연 시간 측정(passive latency discovery)과 웹 프리페칭(prefetching) 지시어를 사용하여 안전하게 측정 데이터를 수집합니다 [8-10].
-
-- **좌표의 안정성과 시간 경과에 따른 변화 (Coordinate Stability):**
-  - 라우팅 경로의 변경이나 네트워크 혼잡 등으로 인해 한 번 생성된 좌표는 시간이 지날수록 실제 지연 시간과 오차가 발생합니다(drift). 연구에 따르면 일주일이 경과하면 전체 좌표의 25%가 33밀리초(ms) 이상 어긋나게 됩니다 [11, 12].
-  - 이러한 불안정성은 슬라이딩 퍼센타일(sliding percentiles) 같은 통계적 필터링을 통해 일시적 변동을 배제함으로써 개선할 수 있습니다 [13, 14]. 또한, 매일 좌표를 재계산하면(특히 UTC 오후 10시경) 좌표의 75%를 초기 값의 6ms 이내로 안정적으로 유지할 수 있습니다 [11, 12, 15].
-
-- **시스템 활용 및 성능:**
-  - 이렇게 산출된 좌표는 웹 클라이언트의 요청을 가장 가까운 데이터 센터로 리디렉션(Client Redirection)하거나 P2P 오버레이 및 CDN 레플리카의 효율적 배치를 지원하는 데 사용됩니다 [16-18].
-  - 구글의 시스템 적용 결과, GNP 기반 리디렉션을 사용했을 때 86%의 확률로 측정된 지연 시간이 가장 짧은 최적의 레플리카로 클라이언트를 연결하는 성과를 보였습니다 [19-21].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[Global Network Positioning (GNP)]], [[Latency Estimation]], [[Passive Latency Discovery]]
-- **Projects/Contexts:** [[Google Content Delivery Network (CDN)]], [[Test Traffic Measurements (TTM)]]
-- **Contradictions/Notes:** Lighthouses나 NPS와 같은 분산형 네트워크 좌표 시스템들은 기존 호스트들을 로컬 랜드마크로 활용하여 확장성을 높일 수 있다고 주장합니다 [22, 23]. 하지만 구글 CDN 연구에서는 이러한 분산형 구조가 오히려 악의적 호스트 관리, 측정 스케줄링 동기화, 전역적 일관성 유지 등의 복잡한 문제를 유발하므로, 고정된 랜드마크 인프라와 중앙 집중식 스케줄러를 사용하는 것이 확장성 제한 없이 훨씬 효율적이고 단순한 해결책이라고 반대 의견을 제시합니다 [24].
-
----
-*Last updated: 2026-04-19*
-- Raw Source: [[00_Raw/2026-04-20/Network Coordinate Systems.md]]
----
diff --git a/Programming & Language/Network Science.md b/Programming & Language/Network Science.md
deleted file mode 100644
index 89a964a8..00000000
--- a/Programming & Language/Network Science.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-7C08A1
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Network Science"
----
-
-# [[Network Science]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Network Science.md]]
----
diff --git a/Programming & Language/New Media Theory.md b/Programming & Language/New Media Theory.md
deleted file mode 100644
index b83c8e55..00000000
--- a/Programming & Language/New Media Theory.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-30D01C
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - New Media Theory"
----
-
-# [[New Media Theory]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/New Media Theory.md]]
----
diff --git a/Programming & Language/New Space(Young Generation).md b/Programming & Language/New Space(Young Generation).md
deleted file mode 100644
index c6a93469..00000000
--- a/Programming & Language/New Space(Young Generation).md	
+++ /dev/null
@@ -1,40 +0,0 @@
----
-id: P-REINFORCE-AUTO-9FB32F
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - New Space(Young Generation)"
----
-
-# [[New Space(Young Generation)]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> V8 엔진의 메모리 힙(Heap) 구조 내에서 새롭게 생성된 객체들이 처음으로 할당되는 공간으로, 'Young Generation(젊은 세대)'이라고도 불린다 [1-3]. 대부분의 객체가 생성 직후 곧바로 접근 불가능해진다는 '세대 가설(Generational Hypothesis)'에 기반하여 설계되었기 때문에, 공간의 크기가 작고 가비지 컬렉션(GC)이 매우 빠르고 빈번하게 일어나는 것이 특징이다 [4-6]. 스캐빈저(Scavenger)라 불리는 마이너 GC(Minor GC)에 의해 공간이 관리되며, 특정 횟수 이상 살아남은 객체들은 Old Space(구세대)로 승격(Promotion)된다 [2, 4].
-
-## 📖 구조화된 지식 (Synthesized Content)
-* **할당 메커니즘과 메모리 구조:** 
-  New Space에서의 객체 할당은 할당 포인터(Allocation pointer)를 증가시키기만 하면 되므로 매우 빠른 속도를 자랑한다 [4, 7]. 이 공간은 매우 빠른 가비지 컬렉션을 위해 설계되어 일반적으로 1MB~64MB(행동 휴리스틱에 따라 1MB~8MB로도 언급됨)의 비교적 작은 크기로 유지된다 [4, 7]. New Space 내부의 객체는 세부적으로 새로 할당되는 'Nursery'와 한 번의 GC에서 살아남은 'Intermediate' 하위 세대로 나뉘며, 메모리 구조상 동일한 크기의 'From-Space'와 'To-Space'라는 두 개의 반공간(Semi-space)으로 분할된다 [8-10].
-
-* **마이너 GC (Scavenge) 작동 방식:** 
-  객체 할당 포인터가 New Space의 끝에 도달하여 공간이 가득 차게 되면 마이너 GC 주기인 '스캐빈지(Scavenge)'가 트리거된다 [4, 7]. 스캐빈저는 체니의 알고리즘(Cheney's algorithm)을 기반으로 작동하며, From-Space에서 여전히 참조되고 있는 살아있는(live) 객체만을 식별하여 빈 공간인 To-Space로 복사(대피)시킨다 [7, 8, 10, 11]. 복사가 완료되면 From-Space의 나머지 데이터는 가비지로 간주되어 전부 비워지며, 이후 From-Space와 To-Space의 역할이 서로 뒤바뀐다 [11, 12]. 이 과정에서 객체들이 연속된 메모리 블록으로 압축(Compaction)되므로 메모리 단편화가 완전히 해소된다 [8, 11].
-
-* **객체의 승격 (Promotion):** 
-  Nursery에 할당된 객체가 첫 번째 마이너 GC에서 살아남으면 Intermediate 상태가 되어 새로운 페이지(To-Space)로 이동한다 [9, 13]. 스캐빈지 과정을 두 번 거치고도 살아남은 객체들은 수명이 긴 객체로 판단되어 New Space를 떠나 Old Generation(Old Space)으로 승격된다 [4, 9, 11].
-
-* **튜닝 및 크기 제어:** 
-  Node.js 환경에서는 V8 플래그를 통해 New Space의 크기를 조절할 수 있다. `--min_semi_space_size` 및 `--max_semi_space_size` (또는 `--max-semi-space-size`) 옵션을 사용하면 이 공간의 크기를 명시적으로 제어할 수 있다 [3, 14]. 트래픽이 많거나 생성 후 곧바로 소멸하는 소규모 객체가 매우 자주 생성되는 애플리케이션의 경우, New Space 크기를 늘려 마이너 GC의 발생 빈도를 줄이고 전반적인 성능 저하를 방지할 수 있다 [14].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[Minor GC(Scavenger)]], [[Old Space(Old Generation)]], [[Generational Hypothesis]], [[Semi-space Design]]
-- **Projects/Contexts:** [[V8 JavaScript Engine]], [[Node.js Memory Management]]
-- **Contradictions/Notes:** 소스 간에 New Space의 일반적인 크기 범위에 대한 서술에 약간의 차이가 존재합니다. 소스 [4]은 행동 휴리스틱에 따라 "1MB에서 8MB 사이"라고 명시하지만, 소스 [7]은 "일반적으로 1MB에서 64MB 사이"로 다소 더 큰 범위를 제시합니다. 
-
----
-*Last updated: 2026-04-19*
-- Raw Source: [[00_Raw/2026-04-20/New Space(Young Generation).md]]
----
diff --git a/Programming & Language/New Space.md b/Programming & Language/New Space.md
deleted file mode 100644
index 24995f27..00000000
--- a/Programming & Language/New Space.md	
+++ /dev/null
@@ -1,30 +0,0 @@
----
-id: P-REINFORCE-AUTO-BAE893
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - New Space"
----
-
-# [[New Space]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> New Space(뉴 스페이스)는 V8 JavaScript 엔진의 힙(Heap) 메모리 영역 중 하나로, '젊은 세대(Young Generation)'라고도 불리며 대부분의 새로운 객체가 처음 할당되는 작고 빠른 공간입니다 [1-3]. 이 공간은 대부분의 객체가 생성된 직후 접근 불가능해진다는 '세대별 가설(Generational Hypothesis)'에 기반하여 설계되어, 수명이 짧은 객체들을 매우 빈번하고 빠르게 가비지 컬렉션(GC) 하도록 최적화되어 있습니다 [4-6]. 효율적인 메모리 관리를 위해 내부적으로 크기가 동일한 두 개의 반공간(To-Space와 From-Space)으로 나뉘어 운영됩니다 [7-9].
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[Old Space]], [[Scavenger]], [[Garbage Collection]], [[Generational Hypothesis]], [[To-Space]], [[From-Space]]
-- **Projects/Contexts:** [[V8 JavaScript Engine]], [[Node.js Memory Management]]
-- **Contradictions/Notes:** 소스 [4] 및 [15]에서는 New Space의 크기가 일반적으로 1~8MB라고 설명하지만, 소스 [8]에서는 전형적으로 1MB~64MB 사이의 크기를 가진다고 주장하여 문헌 간 구체적인 기본 용량 범위에 수치상 차이가 있습니다.
-
----
-*Last updated: 2026-04-19*
-- Raw Source: [[00_Raw/2026-04-20/New Space.md]]
----
diff --git a/Programming & Language/Nodejs Memory Management.md b/Programming & Language/Nodejs Memory Management.md
deleted file mode 100644
index 27aa3785..00000000
--- a/Programming & Language/Nodejs Memory Management.md	
+++ /dev/null
@@ -1,49 +0,0 @@
----
-id: P-REINFORCE-AUTO-3D2466
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Nodejs Memory Management"
----
-
-# [[Nodejs Memory Management]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-**V8 메모리 아키텍처 (Stack & Heap)**
-* Node.js를 실행하는 V8 엔진은 메모리를 스택(Stack)과 힙(Heap)으로 나누어 관리합니다 [1, 2]. 
-* 스택은 정적 데이터, 메서드/함수 프레임, 원시 값, 힙에 있는 객체를 가리키는 포인터를 LIFO(Last In, First Out) 방식으로 저장하며, 운영체제에 의해 매우 빠르게 자동 관리됩니다 [1, 10-12].
-* 힙은 실행 시간에 크기가 결정되는 동적 객체가 저장되는 곳으로 가비지 컬렉터(GC)의 주요 관리 대상이 됩니다 [10, 13, 14]. 힙 내부는 객체의 수명과 목적에 따라 New-space(Young generation), Old-space(Old generation), Large-object-space, Code-space, Map-space 등으로 세분화됩니다 [14-16].
-
-**세대별 가비지 컬렉션 (Generational Garbage Collection)**
-* **Minor GC (Scavenger):** New-space를 관리하는 빠르고 빈번한 컬렉터입니다 [17, 18]. New-space는 절반씩 To-space와 From-space로 나뉘며(Cheney's algorithm), 할당 포인터가 공간 끝에 도달하면 살아있는 객체만 To-space로 복사하고 죽은 객체를 버립니다 [18-20]. 이 과정을 두 번 생존한 객체는 Old-space로 승격(Promotion)됩니다 [17, 19, 20].
-* **Major GC (Mark-Sweep-Compact):** Old-space가 일정 한도에 도달하면 실행되며, Mark-Sweep-Compact 알고리즘을 사용합니다 [17, 21-23]. 루트(스택, 전역 객체 등)에서 시작해 도달 가능한 객체를 탐색하여 마킹(Marking)하고, 도달할 수 없는 영역을 회수(Sweeping)하며, 필요 시 살아남은 객체를 모아 단편화를 줄이는 압축(Compacting)을 수행합니다 [21, 24-27].
-* **Orinoco 프로젝트:** 전통적인 GC의 단점인 긴 일시 정지(Stop-the-world) 문제를 해결하기 위해 도입된 V8의 GC 아키텍처입니다 [28-30]. 작업 스레드를 활용하여 GC 작업을 병렬(Parallel), 점진적(Incremental), 동시적(Concurrent)으로 수행하여 메인 스레드의 부하와 지연을 최소화합니다 [31-37].
-
-**메모리 누수 (Memory Leaks) 발생 패턴 및 분석**
-* Node.js에서 메모리 누수는 객체가 유실된 것이 아니라 개발자가 의도치 않게 참조(Reference)를 유지하여 가비지 컬렉터가 이를 살아있는 것으로 간주할 때 발생합니다 [8, 38, 39].
-* 정상적인 GC 사이클을 거치는 애플리케이션은 톱니바퀴(Sawtooth) 형태의 메모리 사용 패턴을 보이지만, 누수가 있는 경우 해제되지 않고 계속 증가만 하는 라쳇(Ratchet) 패턴을 보입니다 [40-42].
-* 주요 누수 원인으로는 이벤트 리스너 누적(예: `EventEmitter` 경고), 해제되지 않은 타이머/인터벌(Timer Drift), 클로저 변수 보존(Closure Retention), 한도 없는 인메모리 캐시, 종료되지 않은 스트림(Streams) 등이 있습니다 [39, 43-46].
-
-**모니터링 및 메모리 튜닝 (Monitoring and Tuning)**
-* 코드 상에서 `process.memoryUsage()`를 통해 rss, heapTotal, heapUsed 등의 메모리 지표를 추적할 수 있으며 [47, 48], `--trace-gc` 플래그나 V8 모듈, 퍼포먼스 훅(Performance Hooks)을 통해 GC 활동 로그를 분석할 수 있습니다 [49-51].
-* 발견하기 힘든 누수 분석 시에는 Chrome DevTools의 Memory 패널을 이용하여 힙 스냅샷(Heap Snapshots)을 비교하거나 Allocation Timeline을 기록하여 누수 대상을 추적합니다 [40, 52-57].
-* Node.js 실행 시 플래그를 통해 메모리를 제어할 수 있습니다. `--max-old-space-size`로 Old-space 한도를 늘리거나, `--max-semi-space-size`로 New-space 크기를 키울 수 있으며, `--expose-gc`를 설정하면 애플리케이션에서 `global.gc()`를 통해 수동으로 GC를 유발할 수 있습니다 [58-62].
-* 포인터 압축(Pointer Compression) 기술로 인해 64비트 시스템에서도 V8 힙은 최대 4GB로 제한될 수 있으며, 이를 초과할 경우 빈번한 GC 발생 및 OOM이 일어날 수 있습니다 [63-66].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[V8 JavaScript Engine]], [[Garbage Collection]], [[Orinoco GC]], [[Memory Leaks]], [[Pointer Compression]]
-- **Projects/Contexts:** [[Node.js Production Monitoring]], [[Chrome DevTools Memory Profiling]]
-- **Contradictions/Notes:** `--expose-gc` 옵션을 사용해 코드 내에서 수동으로 GC(`global.gc()`)를 호출하여 메모리를 회수할 수는 있으나, 과도하게 사용하면 프로그램 성능 저하(Performance degradation)를 초래할 수 있으므로 주의해서 사용해야 한다고 경고합니다 [62, 67].
-
----
-*Last updated: 2026-04-19*
-- Raw Source: [[00_Raw/2026-04-20/Node.js Memory Management.md]]
----
diff --git a/Programming & Language/Nodejs Memory Tuning.md b/Programming & Language/Nodejs Memory Tuning.md
deleted file mode 100644
index 50114e63..00000000
--- a/Programming & Language/Nodejs Memory Tuning.md	
+++ /dev/null
@@ -1,45 +0,0 @@
----
-id: P-REINFORCE-AUTO-254A8B
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Nodejs Memory Tuning"
----
-
-# [[Nodejs Memory Tuning]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> Node.js 메모리 튜닝은 V8 자바스크립트 엔진에서 실행되는 Node.js 애플리케이션의 메모리 사용량을 모니터링, 관리 및 최적화하는 과정입니다 [1]. 이 튜닝의 핵심은 V8이 메모리를 힙(New Space 및 Old Space)과 스택으로 구성하는 방식과 가비지 컬렉션(GC)을 통해 메모리를 회수하는 방식을 이해하는 것입니다 [1, 2]. 개발자는 특정 명령줄 플래그를 사용하여 힙 크기와 GC 주기를 조정함으로써 애플리케이션의 성능을 향상시키고 메모리 부족(Out-of-memory)으로 인한 충돌을 방지할 수 있습니다 [1, 3-5].
-
-## 📖 구조화된 지식 (Synthesized Content)
-**V8 메모리 아키텍처의 이해**
-*   V8은 메모리를 주로 **힙(Heap)**과 **스택(Stack)**으로 나누어 관리합니다 [2, 6]. 
-*   **스택(Stack):** 정적 데이터, 지역 변수, 함수 호출 정보가 LIFO(Last In, First Out) 방식으로 저장되는 작고 빠른 영역입니다 [6].
-*   **힙(Heap):** 객체, 배열, 함수와 같은 동적 데이터가 할당되는 큰 영역이며, 가비지 컬렉터에 의해 관리됩니다 [6, 7]. 힙은 다시 단기 생존 객체가 생성되는 **New Space**(Young Generation)와 여러 번의 GC 주기를 버텨낸 장기 생존 객체가 보관되는 **Old Space** 등으로 세분화됩니다 [2, 7].
-
-**메모리 모니터링 및 누수 탐지**
-*   메모리를 튜닝하기 전에 `process.memoryUsage()` 메서드를 사용하여 애플리케이션의 메모리 소비량을 모니터링해야 합니다 [8, 9]. 이 메서드는 RSS(Resident Set Size), `heapTotal`, `heapUsed`, `external`, `arrayBuffers` 등의 메모리 지표를 반환합니다 [9].
-*   시간이 지나도 `heapUsed`가 반환되지 않고 지속적으로 증가한다면 메모리 누수를 나타내는 신호일 수 있습니다 [3].
-*   `--trace-gc` 플래그를 사용하면 Scavenge(New Space GC)와 Mark-sweep(Old Space GC) 등의 가비지 컬렉션 이벤트를 콘솔에서 추적하여 메모리가 해제되는 상태와 GC 소요 시간을 분석할 수 있습니다 [10-12].
-
-**명령줄 플래그를 활용한 메모리 튜닝**
-Node.js는 메모리 최적화를 위해 V8 엔진의 메모리 관련 설정을 미세 조정할 수 있는 여러 명령줄 플래그(Command-Line Flags)를 제공합니다 [3].
-*   `--max-old-space-size`: V8 힙에서 수명이 긴 객체들이 저장되는 Old Space의 최대 크기를 제한합니다 [4]. 지속적인 데이터를 많이 처리하는 애플리케이션의 경우, 이 값을 늘려주어(예: `--max-old-space-size=4096`) 잦은 GC로 인한 응답 속도 저하나 충돌을 방지할 수 있습니다 [4, 13].
-*   `--max-semi-space-size`: 객체가 처음 할당되는 New Space의 크기를 조절합니다 [13]. 초당 요청 수가 많아 작은 객체가 수없이 생성되는 환경에서 이 값을 늘리면(예: `--max-semi-space-size=64`), 마이너 가비지 컬렉션의 빈도를 줄여 전반적인 성능 저하를 막을 수 있습니다 [5, 13].
-*   `--gc-interval`: 가비지 컬렉션이 시도되는 주기를 조정합니다 [5]. 실시간 처리 등 특정 조건에서 GC의 주기를 명시적으로 제어할 필요가 있을 때 사용합니다(예: `--gc-interval=100`) [5, 14].
-*   `--expose-gc`: 코드 내부에서 `global.gc()`를 호출하여 개발자가 수동으로 가비지 컬렉션을 실행할 수 있도록 허용하는 플래그입니다 [14, 15].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[V8 JavaScript Engine]], [[Garbage Collection]], [[Heap Memory]], [[Memory Leaks]]
-- **Projects/Contexts:** [[Node.js Production Profiling]], [[Performance Optimization]]
-- **Contradictions/Notes:** `--expose-gc` 플래그를 통해 수동으로 가비지 컬렉션을 실행하더라도, V8의 일반적인 자동 GC 알고리즘이 비활성화되는 것은 아닙니다. 수동 호출을 과도하게 사용하면 오히려 성능에 부정적인 영향을 미칠 수 있으므로 주의가 필요합니다 [15]. 또한, `--gc-interval`의 간격을 너무 짧게 설정할 경우 잦은 GC 수행으로 인해 애플리케이션의 성능 저하를 유발할 수 있습니다 [14].
-
----
-*Last updated: 2026-04-19*
-- Raw Source: [[00_Raw/2026-04-20/Node.js Memory Tuning.md]]
----
diff --git a/Programming & Language/Nodejs Production Monitoring.md b/Programming & Language/Nodejs Production Monitoring.md
deleted file mode 100644
index 55b46459..00000000
--- a/Programming & Language/Nodejs Production Monitoring.md	
+++ /dev/null
@@ -1,38 +0,0 @@
----
-id: P-REINFORCE-AUTO-D6D630
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Nodejs Production Monitoring"
----
-
-# [[Nodejs Production Monitoring]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> Node.js 프로덕션 모니터링은 단일 프로세스로 장기 실행되는 Node.js 애플리케이션 환경에서 메모리 누수나 성능 저하를 감지하고 해결하기 위한 필수적인 과정입니다 [1, 2]. 정상적인 가비지 컬렉션(GC) 이후 메모리가 기준치로 돌아오는지(톱니바퀴 패턴) 혹은 계속 증가하는지(래칫 패턴)를 관찰하여 이상 징후를 파악합니다 [2]. 이를 위해 `process.memoryUsage()`, 힙 스냅샷(Heap Snapshot), GC 이벤트 추적, 그리고 Prometheus와 같은 외부 알림 도구를 종합적으로 활용하여 애플리케이션의 OOM(Out of Memory) 충돌을 방지하고 안정성을 유지합니다 [3-5].
-
-## 📖 구조화된 지식 (Synthesized Content)
-* **기본 지표 및 패턴 모니터링:** 정상적인 Node.js 프로세스는 요청이 몰릴 때 힙 메모리가 증가했다가 GC 이후 기준치로 떨어지는 '톱니바퀴(Sawtooth)' 패턴을 보입니다 [2]. 반면 누수가 있는 프로세스는 메모리가 계속해서 누적되는 '래칫(Ratchet)' 패턴을 나타냅니다 [2]. 프로덕션 환경에서는 Prometheus의 `prom-client`를 활용해 메모리 지표를 내보내고, Grafana 알림 규칙을 설정하여 OOM 충돌 전에 누수를 포착할 수 있습니다 [4]. 또한 코드 내에서 `process.memoryUsage()`를 호출하여 RSS(Resident Set Size), heapTotal, heapUsed, external, arrayBuffers 등의 상태를 지속적으로 확인할 수 있습니다 [5].
-* **힙 프로파일링 및 스냅샷 도구:**
-  * V8 내장 프로파일링을 위해 외부 패키지 없이 `--heap-prof` 플래그를 사용하거나, `chrome://inspect`를 통해 Chrome DevTools에 연결하여 메모리 할당 타임라인을 기록할 수 있습니다 [2, 4].
-  * Chrome 개발자 도구 접근이 불가능한 프로덕션 환경의 경우, `heapdump` 패키지를 사용하여 프로그래밍 방식으로 스냅샷을 캡처한 뒤 파일로 저장하여 로컬에서 분석할 수 있습니다 [3, 6].
-  * `clinic.js` 도구를 사용하면 어떤 함수가 가장 많은 메모리를 유지하고 있는지 시각화하여 누수 원인을 빠르게 파악할 수 있습니다 [6].
-* **가비지 컬렉션(GC) 추적:**
-  * 애플리케이션 실행 시 `--trace-gc` 플래그를 사용하면 Scavenge 및 Mark-sweep과 같은 GC 이벤트의 세부 정보를 콘솔에 출력하여 메모리 소모량을 분석할 수 있습니다 [7-9].
-  * 전체 수명 주기 동안의 추적이 부담스럽다면, `v8` 모듈을 사용해 런타임에 플래그를 동적으로 설정하거나, Node.js의 `perf_hooks` (PerformanceObserver)를 사용하여 프로그래밍 방식으로 GC 통계를 수집할 수 있습니다 [10, 11].
-* **일반적인 경고 및 누수 지표:** 모니터링 중 RSS는 증가하지만 힙 메모리가 안정적이라면 Native Buffer 또는 C++ 바인딩의 누수를 의심해야 하며, 이는 `process.memoryUsage().external`을 통해 확인할 수 있습니다 [12]. 또한, 단일 이벤트 방출기에 리스너가 누적될 때 발생하는 `MaxListenersExceededWarning` 경고는 프로덕션 환경에서 이벤트 리스너 누수의 확실한 신호로 간주됩니다 [6, 12].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[V8 Garbage Collection]], [[Heap Snapshot]], [[Memory Leak]], [[Performance Hooks]], [[Prometheus]]
-- **Projects/Contexts:** [[Node.js Production Server]]
-- **Contradictions/Notes:** Node.js는 단일 프로세스로 수명이 길기 때문에 요청 컨텍스트가 프로세스와 함께 소멸하는 전통적인 다중 프로세스 서버와 다르게 메모리 참조가 지속적으로 누적된다는 구조적 차이점이 있습니다 [1]. 한편, 모니터링이나 특정 엣지 케이스에서 `--expose-gc`를 통해 수동으로 GC(`global.gc()`)를 트리거할 수 있지만, 이는 정상적인 자동 GC 알고리즘을 비활성화하는 것은 아니며 남용할 경우 심각한 성능 저하를 유발할 수 있으므로 주의가 필요합니다 [13, 14].
-
----
-*Last updated: 2026-04-19*
-- Raw Source: [[00_Raw/2026-04-20/Node.js Production Monitoring.md]]
----
diff --git a/Programming & Language/Nodejs 메모리 최적화.md b/Programming & Language/Nodejs 메모리 최적화.md
deleted file mode 100644
index 60c816c2..00000000
--- a/Programming & Language/Nodejs 메모리 최적화.md	
+++ /dev/null
@@ -1,49 +0,0 @@
----
-id: P-REINFORCE-AUTO-4670EE
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Nodejs 메모리 최적화"
----
-
-# [[Nodejs 메모리 최적화]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> Node.js는 V8 엔진을 기반으로 실행되는 단일 프로세스이므로, 시간이 지남에 따라 메모리 누수가 지속적으로 누적될 수 있어 효율적인 메모리 관리가 필수적입니다 [1]. 정상적인 상태의 힙 메모리 사용량은 가비지 컬렉션(GC) 이후 원래 수준으로 돌아가는 톱니바퀴(sawtooth) 패턴을 보이지만, 메모리 누수가 발생하면 반환되지 않고 지속적으로 상승하는 래칫(ratchet) 패턴을 그립니다 [2]. 메모리 최적화는 각종 힙 프로파일링 도구와 명령줄 플래그를 활용하여 애플리케이션의 누수 패턴을 찾아 해결하고, GC 설정 및 힙 공간 크기를 튜닝하여 시스템의 안정성과 성능을 극대화하는 과정입니다 [2-4].
-
-## 📖 구조화된 지식 (Synthesized Content)
-**V8 메모리 구조 및 가비지 컬렉션(GC)**
-* Node.js의 V8 엔진은 메모리를 힙(Heap)과 스택(Stack)으로 나누어 관리합니다 [5]. 스택은 지역 변수 및 함수 호출 프레임을 후입선출(LIFO) 원칙에 따라 관리하며, 힙은 동적으로 생성된 자바스크립트 객체와 데이터가 저장되는 곳으로 가비지 컬렉터의 주요 관리 대상이 됩니다 [6, 7].
-* 세대별 가설(Generational hypothesis)에 기반하여 힙은 '새로운 공간(New Space)'과 '오래된 공간(Old Space)'으로 나뉩니다 [5]. New Space에서는 단기 객체가 할당되며, 가볍고 빠른 마이너 GC(Scavenger)가 자주 실행되어 사용되지 않는 메모리를 회수합니다 [5, 8].
-* New Space에서 여러 번의 GC 주기를 생존한 객체들은 장기 보존 데이터로 간주되어 Old Space로 승격(Promotion)되며, 이 영역은 무겁지만 덜 빈번하게 실행되는 메이저 GC(Mark-Sweep-Compact 알고리즘)를 통해 관리됩니다 [5, 9, 10].
-
-**메모리 누수 감지 및 모니터링**
-* `process.memoryUsage()`를 사용하면 RSS(Resident Set Size), `heapTotal`, `heapUsed` 등의 수치를 통해 실행 중인 프로세스의 메모리 상태를 파악할 수 있습니다 [11].
-* 상용 환경에서는 `prom-client`를 통해 메모리 메트릭을 추출하고 Grafana와 같은 도구로 경고 규칙(Alert rule)을 설정하여, 메모리 부족(OOM) 크래시가 발생하기 전 누수를 조기 감지하는 것이 좋습니다 [12].
-* 누수가 의심될 때는 `--inspect` 플래그를 통해 Chrome DevTools에 연결하여 객체 할당 타임라인을 기록하거나, `heapdump` 라이브러리 및 `--heap-prof` 플래그를 활용해 힙 스냅샷을 캡처하여 추적할 수 있습니다 [2, 12, 13]. 트래픽 발생 전후의 두 가지 힙 스냅샷을 비교하면 반환되지 않고 남아 있는 메모리 할당 객체들을 정확히 찾아낼 수 있습니다 [13].
-
-**자주 발생하는 메모리 누수 원인과 해결 패턴**
-* **이벤트 리스너 누적:** `on('event', fn)` 호출 후 리스너를 명시적으로 제거하지 않아 발생하며, 단일 이벤트 발생기에 리스너가 10개를 초과하면 `MaxListenersExceededWarning`이 발생하여 누수를 강력히 암시합니다 [14, 15].
-* **클로저(Closure) 변수 유지:** 요청 및 응답 객체 전체와 같은 커다란 변수가 클로저에 캡처된 상태로 콜백이나 비동기 체인 내에 남겨지면 가비지 컬렉터가 이를 수집하지 못합니다 [15].
-* **무제한 캐시 및 잊혀진 타이머:** 인메모리 캐시를 사용할 때 한도를 설정하지 않거나, `setInterval`로 생성된 타이머를 `clearInterval`로 정리하지 않으면 연관된 클로저 전체가 메모리에 영구적으로 보존됩니다 [15, 16].
-* **종료되지 않은 스트림과 소켓:** 스트림이나 네트워크 핸들의 응답 본문을 다 소비하지 않은 경우, 내부 버퍼가 유지되므로 반드시 `cancel()`이나 `destroy()`를 호출해 정리해야 합니다 [16].
-
-**메모리 튜닝용 명령줄 플래그(CLI Flags)**
-* `--max-old-space-size`: Old Space의 한계를 메가바이트(MB) 단위로 설정하며, 대량의 데이터 배치 처리나 많은 사용자 세션 등 메모리 소모가 큰 애플리케이션의 성능 저하 및 OOM 방지에 사용됩니다 [4].
-* `--max-semi-space-size`: New Space의 크기를 조절하며, 단기 객체(예: API 요청마다 생성되는 임시 객체)가 대량으로 생성되는 환경에서 늘려주면 잦은 마이너 GC 실행을 줄여 전반적인 성능을 높일 수 있습니다 [17].
-* `--gc-interval` 및 `--expose-gc`: 가비지 컬렉션의 빈도를 강제로 조정하거나, 프로그램 내부에서 `global.gc()`를 호출해 수동으로 가비지 컬렉션을 실행할 수 있도록 하는 옵션입니다 [18-20].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[V8 JavaScript Engine]], [[Garbage Collection (GC)]], [[Heap Snapshot]]
-- **Projects/Contexts:** [[Chrome DevTools Memory Profiling]], [[Node.js Production Environments]]
-- **Contradictions/Notes:** `--expose-gc` 플래그를 통한 수동 가비지 컬렉션 호출(`global.gc()`)은 대량의 데이터 처리 후 즉시 메모리를 회수해야 하는 특수 상황에서 유용할 수 있지만, 일반적인 V8의 자동 GC 메커니즘을 대체하는 것은 아니며 남용 시 과도한 GC 사이클 실행으로 인해 애플리케이션 성능을 크게 저하시킬 위험이 있습니다 [20].
-
----
-*Last updated: 2026-04-19*
-- Raw Source: [[00_Raw/2026-04-20/Node.js 메모리 최적화.md]]
----
diff --git a/Programming & Language/Nodejs 메모리 튜닝.md b/Programming & Language/Nodejs 메모리 튜닝.md
deleted file mode 100644
index 279e2ba9..00000000
--- a/Programming & Language/Nodejs 메모리 튜닝.md	
+++ /dev/null
@@ -1,52 +0,0 @@
----
-id: P-REINFORCE-AUTO-EA5D5E
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Nodejs 메모리 튜닝"
----
-
-# [[Nodejs 메모리 튜닝]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> Node.js 메모리 튜닝은 V8 자바스크립트 엔진의 메모리 구조와 가비지 컬렉션(GC) 메커니즘을 이해하고, 이를 최적화하여 애플리케이션의 성능 저하 및 메모리 누수를 방지하는 과정을 의미합니다 [1, 2]. 개발자는 `--max-old-space-size`와 같은 커맨드라인 플래그를 활용해 힙(Heap) 공간을 조절하거나, `process.memoryUsage()`, 힙 스냅샷 등의 도구를 사용하여 비효율적인 메모리 할당 및 해제되지 않은 참조를 추적할 수 있습니다 [3-5]. 결과적으로 주기적인 메모리 모니터링과 올바른 튜닝은 Out-Of-Memory(OOM) 충돌을 예방하고 애플리케이션의 응답 속도를 일정하게 유지하는 데 핵심적인 역할을 합니다 [6, 7].
-
-## 📖 구조화된 지식 (Synthesized Content)
-*   **V8 엔진의 메모리 구조와 세대별 가비지 컬렉션**
-    *   V8은 메모리를 스택(Stack)과 힙(Heap)으로 분리하여 관리합니다 [8-10]. 스택은 원시 값과 함수 호출 프레임을 저장하며, 힙은 동적 데이터(객체)를 보관합니다 [10-12].
-    *   힙 영역은 객체의 수명에 따라 'New Space(Young Generation)'와 'Old Space(Old Generation)'로 나뉩니다 [9, 13].
-    *   **Minor GC (Scavenger):** 짧은 수명의 객체가 할당되는 New Space를 관리하며, 도달할 수 없는 객체를 자주, 그리고 매우 빠르게 정리합니다 [9, 13, 14].
-    *   **Major GC (Mark-Sweep-Compact):** Minor GC를 여러 번 생존한 객체들은 Old Space로 이동(Promotion)하며, 메모리가 부족해질 때 Mark-Sweep 및 Mark-Compact 알고리즘을 통해 사용되지 않는 메모리를 확보하고 단편화를 제거합니다 [13, 15-18].
-
-*   **메모리 튜닝을 위한 커맨드라인 플래그**
-    *   `--max-old-space-size`: 수명이 긴 객체들이 저장되는 Old Space의 최대 한도를 설정합니다. 캐시나 대규모 세션 데이터를 유지하는 애플리케이션에서 OOM 에러를 방지하기 위해 이 값을 증가시킬 수 있습니다 [5, 19].
-    *   `--max-semi-space-size`: New Space의 크기를 조절합니다. 고트래픽 API 서버처럼 수명이 짧은 임시 객체가 대량으로 생성되는 환경에서 이 값을 늘리면 Minor GC 발생 빈도를 줄여 성능을 향상할 수 있습니다 [19, 20].
-    *   `--gc-interval`: GC 주기를 강제로 조정할 수 있으나, 과도하게 낮추면 GC가 빈번하게 발생하여 성능 저하를 유발할 수 있습니다 [20, 21].
-    *   `--expose-gc`: 코드 내에서 `global.gc()`를 통해 수동으로 GC를 트리거할 수 있게 해 주지만, 잦은 호출은 성능에 악영향을 미치므로 주의해서 사용해야 합니다 [21, 22].
-
-*   **메모리 누수 감지 및 모니터링 도구**
-    *   **`process.memoryUsage()`:** rss(Resident Set Size), heapTotal, heapUsed 등의 수치를 제공하여 현재 Node.js 프로세스의 메모리 상태를 지속적으로 모니터링할 수 있습니다 [4, 23].
-    *   **`--trace-gc` 로그 추적:** 애플리케이션 시작 시 해당 플래그를 제공하면, Scavenge나 Mark-sweep 같은 GC 이벤트가 발생할 때마다 메모리 변화량, 소요 시간, 발생 원인(예: allocation failure) 등의 상세 로그를 콘솔에 출력합니다 [24-27].
-    *   **힙 스냅샷(Heap Snapshots):** Chrome DevTools나 `heapdump` 라이브러리를 사용하여 메모리 상태를 캡처할 수 있습니다. 로드 테스트 전후의 스냅샷을 비교(Comparison view)하여 GC 이후에도 회수되지 않고 남아 있는 객체(메모리 누수 후보)를 식별할 수 있습니다 [3, 28-30].
-    *   **Performance Hooks:** Node.js의 `perf_hooks` 모듈에서 `PerformanceObserver`를 사용하면 프로그래밍 방식으로 GC 통계를 추적하여 성능 오버헤드를 정밀하게 모니터링할 수 있습니다 [31].
-
-*   **주요 메모리 누수 패턴 (Memory Leak Patterns)**
-    *   Node.js에서의 누수는 메모리가 유실된 것이 아니라 GC 루트로부터의 참조가 끈질기게 남아있어 V8이 이를 회수하지 못하는 상태를 뜻합니다 [32].
-    *   주요 누수 패턴으로는 해제되지 않은 이벤트 리스너(`EventEmitter`), 변수 참조를 잃지 않는 클로저(Closures), 크기 제한이 없는 인메모리 캐시, 정리되지 않은 타이머(`setInterval`), 제대로 닫히지 않은 스트림과 소켓 등이 있습니다 [33-35].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[V8 자바스크립트 엔진]], [[가비지 컬렉션(GC)]], [[힙 스냅샷(Heap Snapshot)]], [[메모리 누수(Memory Leak)]]
-- **Projects/Contexts:** [[Orinoco GC 프로젝트]], [[Chrome DevTools 메모리 분석]]
-- **Contradictions/Notes:** 
-  - V8 엔진의 포인터 압축(Pointer Compression) 기능 활성화 시, 64비트 시스템에 128GB의 RAM이 있더라도 단일 V8 프로세스(Isolate)의 관리 힙 크기는 4GB의 연속된 메모리 케이지(Cage)로 엄격하게 제한됩니다 [36-38]. 이 제한에 도달하면 메모리를 확보하기 위해 Major GC의 빈도가 극적으로 증가하며, 결과적으로 OOM 충돌을 유발할 수 있습니다 [38]. 
-  - 메모리 최적화를 위해 애플리케이션 코드 내에서 `global.gc()`를 수동으로 지속 호출하는 것은 V8의 자동화된 GC 알고리즘을 방해하고 성능을 떨어뜨릴 수 있으므로 권장되지 않습니다 [22, 39].
-
----
-*Last updated: 2026-04-19*
-- Raw Source: [[00_Raw/2026-04-20/Node.js 메모리 튜닝.md]]
----
diff --git a/Programming & Language/Nodejs 성능 디버깅.md b/Programming & Language/Nodejs 성능 디버깅.md
deleted file mode 100644
index 8f020da0..00000000
--- a/Programming & Language/Nodejs 성능 디버깅.md	
+++ /dev/null
@@ -1,48 +0,0 @@
----
-id: P-REINFORCE-AUTO-7A23E5
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Nodejs 성능 디버깅"
----
-
-# [[Nodejs 성능 디버깅]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> Node.js 성능 디버깅은 주로 V8 엔진의 힙(Heap) 메모리 사용량을 추적하고 가비지 컬렉션(GC) 동작을 분석하여 애플리케이션의 성능 저하 및 메모리 누수(Memory Leak)를 해결하는 과정이다 [1, 2]. 힙 스냅샷(Heap Snapshot), 할당 타임라인, GC 트레이싱 등의 진단 도구를 활용하여 메모리 내에서 불필요하게 유지되는 참조 객체를 식별한다 [3-5]. 이와 더불어, 실시간 모니터링 API 및 V8 명령줄 플래그 튜닝을 통해 메모리 한계를 조정하여 서버 안정성과 처리량을 최적화할 수 있다 [6-8].
-
-## 📖 구조화된 지식 (Synthesized Content)
-*   **메모리 누수의 정의와 주요 패턴**
-    Node.js에서 메모리 누수는 가비지 컬렉터(GC)에 의해 수거되어야 할 객체가 클로저(Closure), 전역 변수 등에 의해 여전히 참조를 유지하고 있을 때 발생한다 [3, 9]. 이로 인해 시간이 지남에 따라 메모리가 지속적으로 증가하며, 결과적으로 프로세스가 Out-Of-Memory(OOM) 오류로 인해 중단될 수 있다 [10, 11]. Node.js 환경에서 가장 흔하게 발생하는 누수 패턴은 다음과 같다:
-    *   **이벤트 리스너 누적**: `on('event', fn)`을 지속적으로 추가하고 제거하지 않으면 해당 콜백 함수와 관련된 메모리가 누수된다 [12].
-    *   **클로저(Closure) 변수 보존**: 비동기 체인이나 스코프를 공유하는 클로저 내부에 큰 객체를 캡처해 두면 해당 클로저의 수명 주기 동안 메모리가 유지된다 [13, 14].
-    *   **무제한 캐시(Unbounded Cache)**: 인메모리 캐시의 크기나 만료를 제한하지 않으면 데이터가 끝없이 축적된다 [14].
-    *   **정리되지 않은 타이머**: `clearInterval`이 호출되지 않은 `setInterval`은 콜백 클로저에 있는 모든 항목의 GC를 방지한다 [15, 16].
-    *   **닫히지 않은 스트림 및 소켓**: 올바르게 종료되지 않은 스트림은 내부 버퍼와 네트워크 핸들을 점유한다 [16].
-
-*   **메모리 디버깅 및 프로파일링 도구**
-    *   **힙 스냅샷(Heap Snapshots)**: 특정 시점의 전체 메모리 상태를 캡처하는 기능으로, Chrome DevTools에서 스냅샷들을 비교('Comparison' 뷰)하여 메모리 누수를 검사할 수 있다 [4, 17-19]. `--inspect` 플래그로 연결하거나 `heapdump` 패키지를 사용해 캡처한 뒤 '할당된 후 해제되지 않은 객체(Objects allocated between snapshots)'를 찾아낸다 [4, 5, 18].
-    *   **할당 타임라인(Allocation Timeline)**: 특정 시간 동안의 메모리 할당을 시각적으로 추적한다 [17, 20]. 가비지 컬렉션 후에도 살아있는 객체는 파란색 막대로 표시되며, 이를 통해 메모리 누수 후보를 특정할 수 있다 [5, 17, 20].
-    *   **GC 트레이싱(--trace-gc)**: `--trace-gc` 플래그를 사용해 실행하면 가비지 컬렉션의 세부 발생 시간, 소요 시간, GC 전후의 힙 용량 변화를 콘솔에서 확인할 수 있다 [5, 21, 22]. 만약 Mark-sweep(오래된 세대 GC) 작업이 지나치게 빈번하거나 GC 이후에도 힙이 원래 수준으로 줄어들지 않으면 메모리 누수의 강력한 신호이다 [23].
-    *   **메모리 모니터링 API**: 코드 내에서 `process.memoryUsage()`를 호출하여 프로세스에 할당된 전체 메모리(`rss`)와 힙의 총량(`heapTotal`), 현재 사용 중인 힙(`heapUsed`) 등을 실시간으로 파악할 수 있다 [6, 7].
-
-*   **메모리 튜닝 및 최적화**
-    Node.js는 V8 엔진의 메모리 제한 및 GC 빈도를 직접 제어할 수 있는 명령줄 플래그를 제공한다 [7].
-    *   `--max-old-space-size`: 수명이 긴 객체들이 저장되는 Old Space의 크기 한도를 설정하여, 지속적인 데이터를 다룰 때 OOM을 지연시키거나 예방할 수 있다 [8, 24].
-    *   `--max-semi-space-size`: 빈번하게 생성 및 소멸되는 객체가 저장되는 New Space의 크기를 조절한다. 처리량이 많은 상황에서 이 크기를 늘리면 잦은 Scavenge(마이너 GC) 사이클을 줄여 성능을 향상할 수 있다 [24, 25].
-    *   `--expose-gc`: 이를 설정하면 애플리케이션 코드 내에서 `global.gc()`를 수동으로 호출하여 대량의 데이터 처리 후 명시적으로 메모리를 회수할 수 있다 [26, 27].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[V8 JavaScript Engine]], [[Garbage Collection]], [[Heap Snapshot]], [[Memory Leak]]
-- **Projects/Contexts:** [[Chrome DevTools Memory Panel]], [[Node.js Production Environment]]
-- **Contradictions/Notes:** 애플리케이션 개발자가 `System.gc()` 또는 `global.gc()`를 사용하여 수동으로 가비지 컬렉션을 트리거할 수는 있으나, GC 동작을 임의로 예측 및 강제 실행하는 행위는 오히려 애플리케이션의 성능을 저하시킬 수 있으므로 주의해서 사용해야 한다 [27, 28].
-
----
-*Last updated: 2026-04-19*
-- Raw Source: [[00_Raw/2026-04-20/Node.js 성능 디버깅.md]]
----
diff --git a/Programming & Language/Nodejs 성능 최적화 및 디버깅.md b/Programming & Language/Nodejs 성능 최적화 및 디버깅.md
deleted file mode 100644
index 76ec0290..00000000
--- a/Programming & Language/Nodejs 성능 최적화 및 디버깅.md	
+++ /dev/null
@@ -1,42 +0,0 @@
----
-id: P-REINFORCE-AUTO-C8E2E0
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Nodejs 성능 최적화 및 디버깅"
----
-
-# [[Nodejs 성능 최적화 및 디버깅]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> '할당 타임라인(Allocation Timeline)' 도구는 힙 프로파일러의 세부적인 스냅샷 정보와 타임라인 패널의 점진적인 추적 기능을 결합하여 브라우저와 Node.js 환경에서 메모리 할당을 모니터링하는 기능이다 [1, 2]. 이 도구는 기록 세션 동안 최대 50ms마다 주기적으로 힙 스냅샷을 캡처하여 객체의 생명주기를 시각화한다 [3, 4]. 이를 통해 가비지 컬렉션(GC) 이후에도 메모리에 남아있는 객체와 그 참조 경로를 파악함으로써 애플리케이션의 메모리 누수를 감지하고 디버깅하는 데 필수적으로 활용된다 [5-8].
-
-## 📖 구조화된 지식 (Synthesized Content)
-- **할당 타임라인의 동작 및 추적 원리:**
-  할당 타임라인 도구는 타임라인 기록을 시작하고 작업을 수행한 뒤 기록을 중지하는 과정 동안 주기적으로 힙 스냅샷을 캡처하며, 기록 종료 시 최종 스냅샷을 한 번 더 찍는다 [1-4]. V8 엔진의 가비지 컬렉션 과정에서 객체의 물리적 메모리 주소는 변경될 수 있으므로, 해당 도구는 여러 스냅샷에 걸쳐 일관되게 유지되는 객체 ID(`@` 뒤에 붙는 숫자)를 부여하여 힙 상태의 변화를 정밀하게 추적하고 비교할 수 있게 한다 [3, 4].
-
-- **메모리 할당 시점별 로그 시각화:**
-  타임라인 도구의 상단 막대는 특정 시점에 힙에서 발견된 새로운 객체의 크기와 발생 시점을 나타낸다 [5, 8]. 이 막대의 색상은 객체의 생존 여부를 시각적으로 보여준다.
-  - **파란색 막대 (Blue bars):** 타임라인 기록이 끝날 때까지 가비지 컬렉션에 수거되지 않고 살아남은 객체를 의미하며, 이 객체들은 메모리 누수(Memory Leak)의 주요 후보군이 된다 [5, 8-10].
-  - **회색 막대 (Gray bars):** 특정 시점에 할당되었으나 이후 가비지 컬렉터에 의해 정상적으로 수거(해제)된 객체를 의미한다 [5, 8-10].
-
-- **보존 트리(Retaining Tree)를 통한 힙 동작 상세 분석:**
-  할당 타임라인에서 파란색 막대 범위를 좁혀 힙 내의 특정 객체를 클릭하면, 하단 패널(Retainers pane)에 보존 트리가 표시된다 [6, 11, 12]. 이 트리는 가비지 컬렉션의 루트(예: 전역 객체나 활성 스택)로부터 해당 객체를 살아있게 유지시키는 참조 체인을 역추적하여 보여준다 [6, 11]. 개발자는 이 보존 경로를 조사하여 객체가 수거되지 않은 원인을 이해하고, 불필요한 참조 코드를 수정하여 메모리를 해제할 수 있다 [6, 12].
-
-- **Node.js 운영 환경에서의 적용 및 로그(Log) 수집:**
-  Node.js 환경에서도 `--inspect` 플래그를 사용하여 크롬 개발자 도구에 연결한 뒤 'Memory > Allocation instrumentation on timeline'을 활용할 수 있다 [7]. 부하 테스트(예: 100~1,000건의 요청)를 진행하면서 타임라인을 기록하고 수거되지 않는 파란색 막대를 확인하여 메모리 누수 위치를 신속하게 특정할 수 있다 [7, 13]. 또한 터미널 레벨에서 `--trace-gc` 플래그를 지정하면 V8 엔진은 메모리 할당 실패(allocation failure) 시 발생하는 GC 이벤트마다 타임스탬프(ms), GC 유형(예: Scavenge, Mark-sweep), GC 전후의 힙 사용량(MB) 및 소요 시간 등을 상세한 텍스트 로그 형태로 출력하여 메모리 포화 상태를 디버깅할 수 있게 해준다 [14-16].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[할당 타임라인(Allocation Timeline)]], [[힙 스냅샷(Heap Snapshot)]], [[V8 힙(Heap)]], [[가비지 컬렉션(Garbage Collection)]]
-- **Projects/Contexts:** [[Chrome DevTools(크롬 개발자 도구)]], [[Node.js 메모리 누수 분석]]
-- **Contradictions/Notes:** 그래프에서 메모리 사용량이 증가한다고 해서 그것이 모두 메모리 누수를 의미하는 것은 아니다. 캐시(Caches), 실행 취소 기록(Undo histories) 등은 의도적으로 데이터를 메모리에 유지하므로, 정상적인 데이터 보존과 우발적인 메모리 누수를 명확히 구분하여 분석해야 한다 [17].
-
----
-*Last updated: 2026-04-19*
-- Raw Source: [[00_Raw/2026-04-20/Node.js 성능 최적화 및 디버깅.md]]
----
diff --git a/Programming & Language/Nodejs 프로세스 모니터링 및 메모리 분석.md b/Programming & Language/Nodejs 프로세스 모니터링 및 메모리 분석.md
deleted file mode 100644
index 73ed416c..00000000
--- a/Programming & Language/Nodejs 프로세스 모니터링 및 메모리 분석.md	
+++ /dev/null
@@ -1,52 +0,0 @@
----
-id: P-REINFORCE-AUTO-56A451
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Nodejs 프로세스 모니터링 및 메모리 분석"
----
-
-# [[Nodejs 프로세스 모니터링 및 메모리 분석]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> Node.js는 V8 엔진 위에서 실행되며, 메모리는 주로 힙(Heap)과 스택(Stack)으로 나뉘어 관리됩니다 [1, 2]. 단일 프로세스로 오랫동안 실행되는 환경 특성상, 코드 상의 실수로 해제되지 않은 메모리 참조가 누적되면 가비지 컬렉터(GC)가 이를 회수하지 못해 Out-Of-Memory(OOM) 크래시로 이어질 수 있습니다 [2, 3]. 따라서 지속적인 메모리 사용량 모니터링과 함께, 힙 스냅샷(Heap Snapshot)과 할당 타임라인(Allocation Timeline) 등의 도구를 활용하여 누수(Leak)의 근본 원인이 되는 객체 참조를 찾아내는 분석 과정이 필수적입니다 [4-6].
-
-## 📖 구조화된 지식 (Synthesized Content)
-- **메모리 구조 및 작동 원리**
-  - V8 엔진의 메모리는 크게 힙(Heap)과 스택(Stack)으로 구분됩니다 [1, 2]. 스택은 원시 값(Primitive values)과 힙 객체에 대한 포인터, 그리고 함수 실행 프레임과 같은 정적 데이터를 저장하며 운영 체제에 의해 빠르게 자동으로 관리됩니다 [7-11].
-  - 힙은 객체와 동적 데이터가 저장되는 가장 큰 메모리 영역이며 가비지 컬렉션의 주 대상이 됩니다 [12]. 힙은 생성 주기에 따라 짧은 수명의 객체가 머무는 New Space(젊은 세대)와 오래 살아남은 객체가 승격되는 Old Space(오래된 세대) 등으로 나뉘며, 각각 Scavenge(마이너 GC)와 Mark-Sweep-Compact(메이저 GC) 알고리즘으로 관리됩니다 [12-14].
-
-- **프로세스 메모리 모니터링 방법**
-  - **코드 기반 모니터링**: `process.memoryUsage()`를 호출하면 프로세스의 메모리 사용량을 RSS(Resident Set Size), heapTotal(할당된 힙 총량), heapUsed(사용 중인 힙), external(C++ 바인딩 등 외부 메모리) 등으로 상세히 확인할 수 있습니다 [15].
-  - **프로덕션 환경 모니터링**: `prom-client`를 이용해 메모리 메트릭을 Prometheus에 내보내고, Grafana 알림을 설정하여 프로세스가 OOM으로 종료되기 전에 선제적으로 누수를 포착할 수 있습니다 [16].
-  - **GC 활동 추적**: `--trace-gc` 플래그를 사용하거나 `perf_hooks`의 PerformanceObserver를 사용하여 가비지 컬렉션 로그를 확인할 수 있습니다 [17, 18]. 정상적인 프로세스는 트래픽이 몰릴 때 힙이 증가했다가 GC 이후 다시 기준선으로 돌아오는 '톱니바퀴(sawtooth)' 패턴을 보이지만, 메모리 누수가 발생하면 기준선이 계속 상승하는 '래칫(ratchet)' 패턴이 관찰됩니다 [4, 19].
-
-- **메모리 분석 및 누수 탐지 도구**
-  - **할당 타임라인 (Allocation Timeline)**: Chrome DevTools에서 일정 시간 동안의 할당을 기록할 수 있습니다 [20, 21]. 분석 화면에서 해제되지 않고 메모리에 여전히 남아있는 객체는 파란색 막대로 표시되며, 이 파란색 막대를 조사하여 누수 후보를 찾아낼 수 있습니다 [22-24].
-  - **힙 스냅샷 (Heap Snapshot)**: 프로세스의 메모리 상태를 포착하며, 두 개 이상의 스냅샷을 찍고 "비교(Comparison)" 뷰를 이용해 두 시점 사이에 생성되었으나 삭제되지 않은 객체들을 필터링할 수 있습니다 [25, 26]. 이 뷰를 통해 해당 객체 자체가 차지하는 얕은 크기(Shallow size)와, 객체 삭제 시 회수 가능한 보존 크기(Retained size)를 파악하고, Retainers 트리를 추적해 메모리를 붙잡고 있는 루트 원인을 찾아냅니다 [27, 28].
-  - 프로덕션 서버와 같이 UI가 없는 환경에서는 `heapdump` 패키지를 통해 스냅샷을 생성하거나, V8 네이티브 프로파일링 기능인 `--heap-prof` 플래그를 사용하여 npm 패키지 의존성 없이 할당 내역을 파일로 저장하여 분석할 수 있습니다 [16, 29].
-
-- **주요 메모리 누수 패턴 (Memory Leak Patterns)**
-  - **이벤트 리스너 누적**: 요청 핸들러 내에서 `on('event', fn)`과 같은 리스너를 지속적으로 추가하고 제거하지 않는 경우 발생합니다. (Node.js에서 단일 에미터에 10개 이상의 리스너가 등록될 때 발생하는 `MaxListenersExceededWarning`은 프로덕션 누수를 확정하는 주요 신호입니다) [29].
-  - **클로저 변수 유지 (Closure Variable Retention)**: 여러 클로저가 스코프를 공유할 때, 의도치 않게 대용량 데이터(예: 전체 요청/응답 객체)가 캡처된 채 요청 수명주기를 초과해 유지되면서 발생합니다 [30, 31].
-  - 그 외 무제한 캐시(Unbounded Cache) 증가, `clearInterval`이 누락된 타이머 인터벌, 복잡한 순환 참조(Circular References), `destroy()`나 `cancel()` 호출 없이 방치된 스트림(Stream)과 소켓 등이 대표적인 원인입니다 [31, 32].
-
-- **명령줄 플래그를 활용한 메모리 튜닝 (Memory Tuning)**
-  - `--max-old-space-size`: 장기 생존 객체가 저장되는 Old Space의 최대 크기를 메가바이트 단위로 설정하여 무거운 작업이나 세션 데이터 저장을 최적화합니다 [33].
-  - `--max-semi-space-size`: New Space의 크기를 조절하여 단기 객체의 잦은 생성으로 인한 마이너 GC 발생 빈도를 늦출 수 있습니다 [34].
-  - `--expose-gc`: 애플리케이션 코드 내에서 `global.gc()`를 호출해 개발자가 수동으로 가비지 컬렉션을 트리거할 수 있게 합니다 [35, 36].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[V8 Garbage Collection]], [[Heap Snapshot]], [[Memory Leak Patterns]]
-- **Projects/Contexts:** [[Node.js Production Environment]], [[Chrome DevTools Memory Panel]]
-- **Contradictions/Notes:** `--expose-gc` 플래그를 사용하여 수동으로 GC를 실행(`global.gc()`)할 수 있지만, 이것이 V8의 일반적인 자동 GC 알고리즘을 비활성화하는 것은 아닙니다. 수동 호출은 보조적인 역할일 뿐이며, 과도하게 사용할 경우 오히려 애플리케이션 성능에 심각한 악영향을 미칠 수 있습니다 [36].
-
----
-*Last updated: 2026-04-19*
-- Raw Source: [[00_Raw/2026-04-20/Node.js 프로세스 모니터링 및 메모리 분석.md]]
----
diff --git a/Programming & Language/Nodejs.md b/Programming & Language/Nodejs.md
deleted file mode 100644
index cb4c3a38..00000000
--- a/Programming & Language/Nodejs.md	
+++ /dev/null
@@ -1,34 +0,0 @@
----
-id: P-REINFORCE-AUTO-09A043
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Nodejs"
----
-
-# [[Nodejs]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> Node.js는 구글의 V8 자바스크립트 엔진을 기반으로 구축되어 서버 측에서 자바스크립트를 실행할 수 있게 해주는 런타임 환경입니다 [1]. 전통적인 다중 프로세스 서버와 달리 단일 프로세스로 장시간 실행되는 특징을 가지며, 이로 인해 누수된 참조가 프로세스 수명 동안 지속적으로 누적될 수 있습니다 [2, 3]. Node.js의 메모리 할당 및 가비지 컬렉션(GC)은 전적으로 내장된 V8 엔진의 자동 메모리 관리 메커니즘에 의존합니다 [1, 4].
-
-## 📖 구조화된 지식 (Synthesized Content)
-* **메모리 구조 (Memory Structure):** Node.js 프로세스의 메모리는 크게 스택(Stack)과 힙(Heap)으로 나뉩니다 [1, 5]. 스택은 로컬 변수, 함수 호출 정보 등을 저장하며 후입선출(LIFO) 방식으로 빠르게 작동합니다 [5]. 반면 힙은 자바스크립트 객체, 배열, 함수 등 동적 데이터가 할당되는 곳으로, 가비지 컬렉터에 의해 관리되며 크기가 고정되어 있지 않습니다 [5, 6].
-* **가비지 컬렉션 (Garbage Collection):** Node.js를 구동하는 V8 엔진은 "대부분의 객체는 일찍 죽는다"는 세대별 가설(Generational hypothesis)을 바탕으로 힙을 관리합니다 [7, 8]. 수명이 짧은 객체는 'New Space(젊은 세대)'에 할당되어 'Scavenger(Minor GC)'에 의해 자주 수집되며, 여러 번의 GC 주기를 살아남은 장기 체류 객체는 'Old Space(오래된 세대)'로 이동하여 'Mark-Sweep-Compact(Major GC)' 알고리즘을 통해 덜 빈번하게 수집됩니다 [7, 9, 10].
-* **프로덕션 환경의 메모리 누수 패턴:** Node.js는 단일 프로세스로 오래 실행되기 때문에 도달 불가능해야 할 객체가 코드상의 참조로 인해 메모리에 계속 남아있는 경우 심각한 누수가 발생합니다 [2, 11]. 주요 누수 원인으로는 누적된 `EventEmitter` 리스너, 클로저 변수 유지, 무제한으로 커지는 인메모리 캐시, 해제되지 않은 타이머(`setInterval`), 닫히지 않은 스트림이나 소켓, 그리고 `AsyncLocalStorage` 컨텍스트 누수 등이 있습니다 [12-14].
-* **메모리 튜닝 및 모니터링:** 개발자는 `process.memoryUsage()` 메서드를 통해 RSS(상주 집합 크기), heapTotal, heapUsed, external 등의 메모리 사용량을 모니터링할 수 있습니다 [15]. 또한 `--max-old-space-size`(Old Space 제한), `--max-semi-space-size`(New Space 제한), `--gc-interval`, `--expose-gc`와 같은 명령줄 플래그를 사용하여 힙 크기를 튜닝하거나 수동으로 GC를 제어할 수 있습니다 [16-19].
-* **진단 및 추적:** GC 활동은 `--trace-gc` 플래그나 `v8` 모듈, 성능 훅(performance hooks)을 통해 프로그램적으로 추적할 수 있습니다 [20-22]. 메모리 누수가 의심될 때는 Chrome DevTools의 Memory 탭과 `--inspect` 플래그, 또는 `heapdump` 패키지를 이용해 힙 스냅샷을 캡처하고 객체의 유지 경로(Retaining path)를 분석하여 원인을 식별합니다 [23-25].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[V8 JavaScript Engine]], [[Garbage Collection]], [[Memory Management]]
-- **Projects/Contexts:** [[Node.js Memory Tuning and Diagnostics]], [[Electron and the V8 Memory Cage]]
-- **Contradictions/Notes:** 수동으로 가비지 컬렉션을 트리거하기 위해 `--expose-gc` 플래그를 사용하여 `global.gc()`를 호출할 수 있지만, 이는 V8의 자동 GC 알고리즘을 비활성화하는 것이 아니며 남용할 경우 성능 저하를 일으킬 수 있으므로 주의해서 사용해야 합니다 [19, 26]. 또한, 전통적인 가비지 컬렉터는 애플리케이션을 완전히 멈추는(stop-the-world) 문제를 유발했으나, V8의 최신 Orinoco GC는 메인 스레드의 멈춤을 최소화하기 위해 병렬(Parallel), 증분(Incremental), 동시(Concurrent) 기법을 도입하여 백그라운드에서 메모리를 회수합니다 [27-30].
-
----
-*Last updated: 2026-04-19*
-- Raw Source: [[00_Raw/2026-04-20/Node.js.md]]
----
diff --git a/Programming & Language/Nominal-Subtyping.md b/Programming & Language/Nominal-Subtyping.md
deleted file mode 100644
index d6c2157c..00000000
--- a/Programming & Language/Nominal-Subtyping.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-60CC9F
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Nominal-Subtyping"
----
-
-# [[Nominal-Subtyping]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Nominal-Subtyping.md]]
----
diff --git a/Programming & Language/Nominal-Typing.md b/Programming & Language/Nominal-Typing.md
deleted file mode 100644
index 2ea09d9c..00000000
--- a/Programming & Language/Nominal-Typing.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-F87246
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Nominal-Typing"
----
-
-# [[Nominal-Typing]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Nominal-Typing.md]]
----
diff --git a/Programming & Language/Non-null Assertion Operator.md b/Programming & Language/Non-null Assertion Operator.md
deleted file mode 100644
index 5dee75d7..00000000
--- a/Programming & Language/Non-null Assertion Operator.md	
+++ /dev/null
@@ -1,32 +0,0 @@
----
-id: P-REINFORCE-AUTO-D4BCC2
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Non-null Assertion Operator"
----
-
-# [[Non-null Assertion Operator]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-- **기능 및 정의**: Non-null Assertion Operator는 `!` 기호를 통해 표현되며, 해당 변수나 표현식의 값이 `null` 또는 `undefined`가 아님을 컴파일러에게 명시적으로 단언(assert)합니다 [1].
-- **사용 목적**: 코드의 문맥상 특정 값이 반드시 존재한다는 것을 개발자는 인지하고 있으나, TypeScript의 타입 시스템이 이를 입증하지 못할 때 사용합니다 [1].
-- **주의점**: 이 연산자는 TypeScript가 제공하는 타입 안전성 검사(safety checks)를 인위적으로 우회하는 기능이므로, 가급적 제한적으로(sparingly) 사용해야 합니다 [1].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[null]], [[undefined]], [[Type Assertions]]
-- **Projects/Contexts:** TypeScript 타입 검사 시스템 및 안전성 검사 우회 [1]
-- **Contradictions/Notes:** 소스에 관련 정보가 부족합니다. (Non-null Assertion Operator에 대해 제공된 소스의 정보가 매우 제한적이며, 상충되는 의견이나 추가적인 맥락은 포함되어 있지 않습니다.)
-
----
-*Last updated: 2026-04-18*
-- Raw Source: [[00_Raw/2026-04-20/Non-null Assertion Operator.md]]
----
diff --git a/Programming & Language/NotebookLM-Automated-Authentication-CLI.md b/Programming & Language/NotebookLM-Automated-Authentication-CLI.md
deleted file mode 100644
index 3005fc7d..00000000
--- a/Programming & Language/NotebookLM-Automated-Authentication-CLI.md	
+++ /dev/null
@@ -1,34 +0,0 @@
----
-id: P-REINFORCE-AUTO-BDE5EC
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - NotebookLM-Automated-Authentication-CLI"
----
-
-# [[NotebookLM-Automated-Authentication-CLI]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 기존의 수동 브라우저 쿠키 추출 방식에서 벗어나, `notebooklm-mcp-cli` 패키지를 활용한 CLI 기반의 표준화된 인증 체계입니다. 구글 계정 로그인을 통해 획득한 토큰을 시스템 전역에서 공유함으로써, 사용자의 개입 없이도 안정적인 NotebookLM 서버 접근 권한을 유지합니다.
-
-## 📖 구조화된 지식 (Synthesized Content)
-이전 시스템의 최대 약점은 브라우저에서 `__Secure-3PSID` 등의 쿠키를 매번 수동으로 복사하여 `.env`에 붙여넣어야 하는 번거로움과 쿠키 만료로 인한 잦은 실패였습니다.
-
-이번 개혁을 통해 도입된 CLI 인증 체계는 다음과 같은 구조를 가집니다:
-1. **nlm login**: 터미널 명령어를 통해 브라우저 로그인 창을 띄우고, 구글 OAuth 기반의 인증을 수행합니다.
-2. **Token Persistence**: 획득된 인증 정보는 로컬 세션 파일에 보안 저장되며, MCP 서버(`notebooklm-mcp`)가 이를 자동으로 감지하여 활용합니다.
-3. **Optional Fallback**: 애플리케이션 UI에서는 여전히 수동 쿠키 입력을 지원하지만, 이는 CLI 인증이 불가능한 환경을 위한 보조 수단으로 격하되었습니다.
-
-이 방식의 도입으로 '인증 만료'로 인한 엔진 중단 사태가 90% 이상 감소하였으며, 개발자는 더 이상 브라우저 개발자 도구를 열 필요가 없게 되었습니다.
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[Autonomous-Polling-Wait-Automation]], [[Zustand-Based-Mission-Persistence]]
-- **Projects/Contexts:** [[P-Reinforce-Agent-v2.6]]
-- **Contradictions/Notes:** CLI 인증은 로컬 환경에 의존하므로, Headless 서버 환경에서는 별도의 토큰 전달 방식이 필요할 수 있습니다.
-- Raw Source: [[00_Raw/2026-04-20/NotebookLM-Automated-Authentication-CLI.md]]
----
diff --git a/Programming & Language/Object Pooling (오브젝트 풀링).md b/Programming & Language/Object Pooling (오브젝트 풀링).md
deleted file mode 100644
index c94117a1..00000000
--- a/Programming & Language/Object Pooling (오브젝트 풀링).md	
+++ /dev/null
@@ -1,46 +0,0 @@
----
-id: P-REINFORCE-AUTO-1F94B3
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Object Pooling (오브젝트 풀링)"
----
-
-# [[Object Pooling (오브젝트 풀링)]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 오브젝트 풀링은 객체의 빈번한 생성과 파괴로 인해 발생하는 메모리 할당 비용과 가비지 컬렉션(GC) 스파이크를 방지하기 위해, 미리 고정된 개수의 객체 풀(Pool)을 할당해 두고 필요할 때 꺼내어 재사용한 뒤 다시 반환하는 소프트웨어 성능 최적화 디자인 패턴입니다.
-
-## 📖 구조화된 지식 (Synthesized Content)
-**1. 도입 목적과 메모리 파편화 방지** 실시간 상호작용이 중요한 게임(예: 슈팅 게임의 탄환, 파티클 시스템)에서 매 프레임마다 수백 개의 객체를 생성하고 삭제하면 시스템 자원을 소모하여 화면이 끊기는 지연(Lag) 현상이 발생합니다. 이는 가비지 컬렉터가 메모리를 정리하는 데 시간이 걸리기 때문입니다. 또한, 잦은 할당과 해제는 힙 메모리의 가용 공간을 작은 조각으로 나누어버리는 '메모리 파편화(Memory Fragmentation)'를 유발하여 결국 메모리 할당 실패와 크래시를 초래할 수 있습니다. 오브젝트 풀은 로딩 시점 등 초기에 큰 메모리를 한 번에 할당하고 이를 유지함으로써 이러한 문제를 원천 차단합니다.
-
-**2. 작동 원리** 오브젝트 풀은 카드의 내용을 지우고 다시 덱에 넣는 것과 같습니다.
-
-- **사전 할당 (Pre-warming):** 초기 크기만큼 객체를 생성하여 비활성 상태로 보관합니다.
-- **활성화 및 재사용:** 객체가 필요할 때 풀에서 가용한 객체를 가져와 상태를 초기화한 뒤 활성화(In-use)합니다.
-- **반환:** 사용이 끝난 객체는 메모리에서 삭제하는 대신 비활성 상태로 변경하여 풀에 반환합니다.
-
-**3. 한계점 및 부작용 관리**
-
-- **메모리 낭비와 크기 고정:** 풀의 크기가 너무 크면 사용되지 않는 객체들이 메모리를 계속 점유하여 자원을 낭비하게 되며, 반대로 너무 작으면 필요한 순간에 객체를 가져오지 못할 수 있습니다.
-- **객체 크기 고정:** 서로 다른 타입이나 크기의 객체를 하나의 풀에서 관리할 경우, 가장 큰 객체의 크기에 맞춰 슬롯 메모리를 할당해야 하므로 메모리 낭비가 발생합니다.
-- **불완전한 초기화 위험:** 재사용되는 객체는 이전 생애(Past life)의 데이터 흔적이 남아있을 수 있습니다. 객체를 풀에서 꺼낼 때 새로운 상태로 완벽하게 덮어쓰기(초기화)하지 않으면 심각한 버그가 발생할 수 있습니다.
-- **참조 유지 버그:** 풀에 반환된 객체를 다른 클래스에서 여전히 참조하고 조작할 경우, 엉뚱한 곳에서 객체가 변경되는 추적하기 힘든 버그(Use-after-free)가 발생할 수 있습니다.
-
-**4. 고속화를 위한 Free List (프리 리스트) 기법** 가장 단순한 오브젝트 풀은 가용한 객체를 찾기 위해 풀 전체를 순회하므로 $O(n)$의 시간이 걸립니다. 이를 최적화하기 위해 비활성 상태인 객체들의 사용하지 않는 메모리 공간(예: C++의 `union`)을 활용하여 다음 빈 객체를 가리키는 포인터를 저장하는 **프리 리스트(Free List)**를 구축하면, 추가적인 메모리 낭비 없이 $O(1)$의 속도로 즉시 객체를 할당할 수 있습니다.
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[Garbage Collection (GC) 최적화]], [[Generational GC (세대별 가비지 컬렉션)]], [[Memory Fragmentation (메모리 파편화)]], [[InstancedMesh (드로우 콜 최적화)]]
-- **Projects/Contexts:** [[대규모 파티클 시스템 최적화]], [[슈팅 게임의 대규모 탄환(Bullet) 제어 시스템]], [[React Three Fiber 엔진 아키텍처]]
-- **Contradictions/Notes:** 오브젝트 풀링이 모든 상황에서 정답은 아닙니다. V8과 같은 최신 자바스크립트 엔진의 세대별 가비지 컬렉터(Generational GC)는 단기 생존 객체(Short-lived objects)를 수거하는 비용이 사실상 0에 가깝습니다. 이 환경에서 객체 풀링을 잘못 적용하면, 객체들이 강제로 오래 살아남게 되어 구세대(Old Generation) 메모리를 압박하고 오히려 GC 성능을 악화시키며 메모리 사용량만 늘릴 위험이 있습니다. 반드시 프로파일러를 통한 성능 병목 확인 후 선별적으로 도입해야 합니다.
-
----
-
-_Last updated: 2026-04-15_
-- Raw Source: [[00_Raw/2026-04-20/Object Pooling (오브젝트 풀링).md]]
----
diff --git a/Programming & Language/Objective Distillation (목표 증류).md b/Programming & Language/Objective Distillation (목표 증류).md
deleted file mode 100644
index 29094978..00000000
--- a/Programming & Language/Objective Distillation (목표 증류).md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-C021D6
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Objective Distillation (목표 증류)"
----
-
-# [[Objective Distillation (목표 증류)]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Objective Distillation (목표 증류).md]]
----
diff --git a/Programming & Language/Occlusion Culling.md b/Programming & Language/Occlusion Culling.md
deleted file mode 100644
index 6e096708..00000000
--- a/Programming & Language/Occlusion Culling.md	
+++ /dev/null
@@ -1,30 +0,0 @@
----
-id: P-REINFORCE-AUTO-3A1034
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Occlusion Culling"
----
-
-# [[Occlusion Culling]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 오클루전 컬링(Occlusion Culling)은 시야(Frustum) 내에 있더라도 다른 물체에 의해 완전히 가려져 보이지 않는 객체들을 식별하고 렌더링 파이프라인에서 제외하는 그래픽스 최적화 기법입니다 [1, 2]. CPU 기반으로 복잡한 기하학적 구조를 계산하기에는 난이도가 높고, GPU에서 수행하더라도 지연(Latency) 문제로 비용이 발생할 수 있어, 최신 렌더링 환경에서는 컴퓨트 셰이더나 깊이 사전 패스(Depth Pre-Pass) 등의 우회 및 발전된 기법과 함께 사용됩니다 [2, 3].
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[Frustum Culling]], [[Compute Shader]], [[Depth Pre-Pass]], [[InstancedMesh]], [[Early-Z]], [[Draw Call]]
-- **Projects/Contexts:** [[WebGPU]], [[Three.js]], [[WebGL/Three.js CAD Rendering Optimization]]
-- **Contradictions/Notes:** 소스에 따르면 오클루전 컬링은 그래픽스 성능 최적화의 핵심적인 개념이지만, 복잡성으로 인해 고유의 연산 비용이 따릅니다. 따라서 상황에 따라 오클루전 컬링을 직접 구현하기보다는 Depth Pre-Pass로 우회하거나, WebGPU의 컴퓨트 셰이더를 통해 CPU를 거치지 않고 가시성을 판별하는 방식으로 기술이 발전하고 있음이 관찰됩니다 [1, 2, 4]. 
-
----
-*Last updated: 2026-04-19*
-- Raw Source: [[00_Raw/2026-04-20/Occlusion Culling.md]]
----
diff --git a/Programming & Language/OffscreenCanvas와 Web Worker를 활용한 메인 스레드 병목 해결.md b/Programming & Language/OffscreenCanvas와 Web Worker를 활용한 메인 스레드 병목 해결.md
deleted file mode 100644
index 1c2972c5..00000000
--- a/Programming & Language/OffscreenCanvas와 Web Worker를 활용한 메인 스레드 병목 해결.md	
+++ /dev/null
@@ -1,42 +0,0 @@
----
-id: P-REINFORCE-AUTO-217E9B
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - OffscreenCanvas와 Web Worker를 활용한 메인 스레드 병목 해결"
----
-
-# [[OffscreenCanvas와 Web Worker를 활용한 메인 스레드 병목 해결]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 자바스크립트의 단일 스레드 한계를 극복하기 위해, 무거운 그래픽 렌더링이나 연산 작업을 메인 스레드(DOM)에서 분리하여 백그라운드의 웹 워커(Web Worker) 스레드에서 병렬 처리하는 성능 최적화 기술입니다.
-
-## 📖 구조화된 지식 (Synthesized Content)
-**1. DOM과 렌더링의 분리 (Decoupling)** 기존의 캔버스 그래픽 작업은 DOM 트리에 존재하는 `<canvas>` 요소에 직접 의존했기 때문에 반드시 메인 스레드에서만 동작해야 했습니다. 하지만 `OffscreenCanvas` API를 활용하면 캔버스를 DOM 화면 밖으로 분리할 수 있으며, DOM이 없는 웹 워커 내부에서도 렌더링 컨텍스트를 사용할 수 있게 됩니다.
-
-**2. 제어권 이전 (Transfer Control) 및 실행** 메인 스레드의 원래 캔버스 요소에서 `transferControlToOffscreen()` 메서드를 호출하여 제어권을 분리합니다. 생성된 `OffscreenCanvas` 객체를 `postMessage`를 통해 웹 워커로 전달하면, 워커 스레드가 렌더링 작업을 전담하게 되며 그 결과는 메인 스레드의 원본 캔버스에 자동으로 반영됩니다.
-
-**3. 메인 스레드 차단 해제 (Unblocking the Main Thread)** Three.js나 복잡한 WebGL 애니메이션, 물리 연산 등은 많은 CPU/GPU 자원을 소모합니다. 이를 워커 스레드로 옮기면 메인 스레드의 과부하를 막을 수 있습니다. 결과적으로 메인 스레드는 렌더링 계산에 블로킹되지 않고 클릭, 스크롤 같은 사용자 상호작용과 React의 UI 업데이트를 즉각적으로 처리할 수 있어 지연 없는 부드러운 앱 경험을 제공합니다.
-
-**4. 이벤트 포워딩 (Event Forwarding)** 웹 워커는 DOM에 접근할 권한이 없으므로 마우스 클릭이나 터치 같은 사용자 이벤트를 직접 감지할 수 없습니다. 이를 해결하기 위해 메인 스레드에서 이벤트를 캡처한 뒤 `postMessage`를 통해 필요한 데이터(좌표 등)만 워커로 전달하여 상호작용을 처리하는 '대리 인터랙션' 방식을 구축해야 합니다.
-
-**5. 상태 동기화 (State Synchronization)** 메인 스레드(React UI)와 워커 스레드(WebGL 씬) 간에 동일한 상태를 공유해야 할 때 동기화가 필요합니다.
-
-- **메시지 기반 동기화:** `BroadcastChannel`이나 Valtio 같은 프록시 기반 상태 관리 도구를 사용하여, 상태가 변경될 때 해당 변경점(Delta)만 직렬화하여 스레드 간에 메시지로 주고받습니다.
-- **SharedArrayBuffer:** 복사 오버헤드를 완전히 없애야 하는 극단적인 최적화가 필요할 때 사용되며, 두 스레드가 동일한 메모리 영역을 공유하여 원자적으로 데이터를 읽고 씁니다.
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[Web Worker]], [[Three.js / WebGL]], [[상태 관리 동기화 (Valtio, SharedArrayBuffer)]], [[이벤트 포워딩(Event Forwarding)]], [[React 게임 엔진 아키텍처]]
-- **Projects/Contexts:** [[멀티스레드 React WebGL 애플리케이션]], [[고성능 실시간 상호작용 시스템]]
-- **Contradictions/Notes:** 상태 동기화를 구현할 때 `SharedArrayBuffer`는 가장 빠르고 메모리 복사 비용이 없지만 원시 이진 데이터(Raw Binary)를 다루어야 해서 구현이 어렵습니다. 반면, Valtio 등 Proxy를 사용한 메시징 방식은 개발이 훨씬 쉽고 직관적이지만 직렬화 과정에서 약간의 오버헤드와 메모리를 희생하게 됩니다.
-
----
-
-_Last updated: 2026-04-14_
-- Raw Source: [[00_Raw/2026-04-20/OffscreenCanvas와 Web Worker를 활용한 메인 스레드 병목 해결.md]]
----
diff --git a/Programming & Language/Oilpan.md b/Programming & Language/Oilpan.md
deleted file mode 100644
index 16cf8eba..00000000
--- a/Programming & Language/Oilpan.md	
+++ /dev/null
@@ -1,33 +0,0 @@
----
-id: P-REINFORCE-AUTO-68FCF1
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Oilpan"
----
-
-# [[Oilpan]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> Oilpan은 Chrome의 렌더링 엔진인 Blink에서 사용하는 가비지 컬렉터(Garbage Collector)입니다 [1]. V8 엔진의 주요 가비지 컬렉터인 Orinoco와 Oilpan 간의 협력을 개선하고, Orinoco의 새로운 기술을 Oilpan에 이식하려는 작업이 진행 중입니다 [1].
-
-## 📖 구조화된 지식 (Synthesized Content)
-- **Blink 렌더러 소속**: Oilpan은 Chrome 내장 렌더러인 Blink를 위해 특별히 설계되고 사용되는 가비지 컬렉터입니다 [1].
-- **Orinoco와의 연계 및 기술 이식**: V8 팀은 두 가비지 컬렉터 간의 협업 및 통합을 향상시키기 위해 노력하고 있으며, V8의 최신 가비지 컬렉터 프로젝트인 Orinoco에 적용된 새로운 기술들을 Oilpan으로 이식(porting)하는 작업을 수행하고 있습니다 [1].
-
-소스에 관련 정보가 부족합니다. (제공된 소스에는 Oilpan의 구체적인 작동 원리, 아키텍처 또는 내부 구현 방식에 대한 추가적인 세부 사항이 포함되어 있지 않습니다.)
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[Garbage Collection]], [[Blink]], [[Orinoco]]
-- **Projects/Contexts:** [[Chrome]]
-- **Contradictions/Notes:** 소스에 관련 정보가 부족합니다. (Oilpan과 관련된 내용은 소스 [1]에서 단 한 차례 간략하게만 언급되며, 구체적인 기술적 논의나 모순점은 제시되어 있지 않습니다.)
-
----
-*Last updated: 2026-04-19*
-- Raw Source: [[00_Raw/2026-04-20/Oilpan.md]]
----
diff --git a/Programming & Language/Old Space (구 세대 공간).md b/Programming & Language/Old Space (구 세대 공간).md
deleted file mode 100644
index c7530fa0..00000000
--- a/Programming & Language/Old Space (구 세대 공간).md	
+++ /dev/null
@@ -1,40 +0,0 @@
----
-id: P-REINFORCE-AUTO-9214B8
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Old Space (구 세대 공간)"
----
-
-# [[Old Space (구 세대 공간)]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> Old Space(구 세대 공간)는 V8 자바스크립트 엔진의 힙(Heap) 메모리 영역 중, New Space(신규 공간)에서 발생하는 가비지 컬렉션(GC)을 두 번 이상 생존한 객체들이 승격(Promotion)되어 이동하는 공간입니다 [1-3]. 주로 사용자 세션이나 캐시 데이터 등 수명이 길고 지속적인 상태를 유지하는 객체들을 장기간 저장하는 데 사용됩니다 [4, 5]. 이 공간의 메모리 회수는 빈도가 낮지만 리소스 소모가 큰 Major GC(Mark-Sweep 및 Mark-Compact 알고리즘)에 의해 관리됩니다 [1, 3, 5].
-
-## 📖 구조화된 지식 (Synthesized Content)
-- **공간의 세분화 및 역할:** 
-  Old Space는 효율적인 가비지 컬렉션을 위해 두 개의 하위 영역으로 나뉩니다. 첫째는 다른 객체를 가리키는 포인터를 포함하는 객체들이 저장되는 **Old-pointer-space**입니다 [3, 6, 7]. 둘째는 문자열, 박싱된 숫자 등 포인터가 없는 원시 데이터만 포함하는 객체들이 저장되는 **Old-data-space**입니다 [3, 6, 7]. GC가 Old-data-space를 처리할 때는 내부 포인터 추적 단계를 건너뛸 수 있어 마킹(Marking) 단계에 소요되는 시간을 단축할 수 있습니다 [4].
-
-- **가비지 컬렉션 (Major GC):** 
-  크기가 작고 수집이 빠른 New Space(Minor GC)와 달리, Old Space는 수백 메가바이트의 데이터를 포함할 수 있으므로 **마크-스윕(Mark-Sweep)** 및 **마크-컴팩트(Mark-Compact)** 알고리즘을 통해 관리됩니다 [8]. Major GC는 객체의 참조를 따라가며 살아있는 객체(Black)와 죽은 객체(White)를 식별(Mark)하고, 죽은 객체가 차지한 메모리를 회수(Sweep)합니다 [9, 10]. 
-
-- **메모리 단편화 및 압축(Compaction):** 
-  Old Space에서는 죽은 메모리가 페이지에 남기는 "구멍(holes)"으로 인해 메모리 단편화(Fragmentation) 문제가 크게 발생합니다 [11]. 큰 공간에서 객체를 이동시키는 것은 계산 비용이 매우 높고 모든 참조 포인터를 업데이트해야 하므로, V8은 매 주기마다 객체를 압축하지 않고 필요할 때만 단편화된 페이지에서 라이브 객체를 다른 페이지의 빈 공간으로 마이그레이션(Compaction)하는 방식을 사용합니다 [12, 13].
-
-- **메모리 튜닝 및 누수 탐지:** 
-  Node.js 애플리케이션에서 대규모 데이터를 처리할 때 `--max-old-space-size` 커맨드라인 플래그를 사용하면 Old Space의 최대 크기(예: 4096MB)를 명시적으로 늘릴 수 있어 잦은 가비지 컬렉션으로 인한 성능 저하를 방지할 수 있습니다 [14, 15]. 또한 `--trace-gc-verbose` 로깅 분석 시, Major GC가 발생한 이후에도 "Old space, used" 크기가 지속적으로 증가한다면 강력한 메모리 누수(Memory Leak)의 징후로 판단할 수 있습니다 [16].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[New Space (신규 공간)]], [[Major GC (주요 가비지 컬렉션)]], [[Mark-Sweep-Compact]], [[Memory Leak (메모리 누수)]]
-- **Projects/Contexts:** [[V8 JavaScript Engine]], [[Node.js Memory Management]]
-- **Contradictions/Notes:** 소스에 따르면 Old Space 내의 객체를 옮기는 압축(Compaction) 작업은 비용이 매우 많이 들기 때문에, Minor GC처럼 모든 라이브 객체를 복사하는 방식(Scavenger)을 쓰지 않고 단편화가 심한 특정 페이지에 대해서만 제한적으로 압축을 수행합니다 [12, 13]. 
-
----
-*Last updated: 2026-04-19*
-- Raw Source: [[00_Raw/2026-04-20/Old Space (구 세대 공간).md]]
----
diff --git a/Programming & Language/Old Space(Old Generation).md b/Programming & Language/Old Space(Old Generation).md
deleted file mode 100644
index a98c200e..00000000
--- a/Programming & Language/Old Space(Old Generation).md	
+++ /dev/null
@@ -1,39 +0,0 @@
----
-id: P-REINFORCE-AUTO-3FD05B
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Old Space(Old Generation)"
----
-
-# [[Old Space(Old Generation)]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> Old Space(또는 Old Generation)는 V8 엔진의 힙(Heap) 메모리 영역 중 하나로, New Space(Young Generation)에서 두 번의 마이너 가비지 컬렉션(Scavenge) 주기 동안 살아남은 수명이 긴 객체들이 이동(승격)하여 저장되는 공간이다 [1-3]. 이 공간은 주로 사용자 세션, 캐시 데이터 등 영구적인 상태를 유지하는 데이터 저장에 사용되며, New Space에 비해 크기가 훨씬 크고 가비지 컬렉션(Major GC)이 덜 빈번하게 발생하지만 더 많은 컴퓨팅 리소스를 소모한다 [4, 5].
-
-## 📖 구조화된 지식 (Synthesized Content)
-*   **객체의 승격(Promotion) 및 수명:** 
-    V8의 메모리 관리는 대부분의 객체가 짧은 수명을 가진다는 '세대적 가설(Generational hypothesis)'에 기반한다 [6]. 초기에 New Space에 할당된 객체가 두 번의 스캐빈지(Scavenge) 주기를 거친 후에도 살아남으면, 장기 보관을 위해 설계된 Old Space로 승격(Promoted)된다 [1, 3, 4]. 전체 객체 중 약 20%만이 Old Generation 영역으로 살아남게 된다 [7].
-*   **Old Space의 세부 구조:**
-    가비지 컬렉션의 효율을 높이기 위해 Old Space는 내부적으로 크게 두 가지 공간으로 세분화된다 [3, 8].
-    *   **Old-pointer-space:** 다른 객체를 가리키는 포인터를 포함할 가능성이 있는 대부분의 객체가 저장된다 [3, 9].
-    *   **Old-data-space:** 문자열(Strings), 박싱된 숫자, 포인터가 없는 원시 데이터 배열 등 외부 객체에 대한 포인터를 포함하지 않는 객체들이 저장된다 [3, 9]. 가비지 컬렉터는 이 영역에서 포인터 추적(tracing) 단계를 건너뛸 수 있으므로 마킹 단계의 소요 시간을 효과적으로 단축한다 [4].
-*   **가비지 컬렉션(Major GC) 관리:** 
-    Old Space는 수백 메가바이트 이상의 데이터를 포함할 수 있으므로, Scavenge 알고리즘 대신 **Mark-Sweep** 및 **Mark-Compact** 알고리즘을 사용하는 Major GC에 의해 관리된다 [10-12]. Major GC는 힙을 순회하며 살아있는 객체를 표시(Mark)하고, 참조되지 않는 객체의 메모리 주소를 빈 공간(Free list)으로 기록(Sweep)하며, 필요한 경우 메모리 파편화(Fragmentation)를 줄이기 위해 객체들을 한곳으로 모으는 압축(Compact) 작업을 수행한다 [13-16]. 
-*   **메모리 제어 및 튜닝:** 
-    Old Space의 크기는 `--initial_old_space_size`와 `--max-old-space-size`라는 V8 커맨드라인 플래그를 통해 제어할 수 있다 [3, 17]. 대량의 영구 데이터나 사용자 세션 정보를 처리하는 애플리케이션의 경우, 장기 생존 객체가 Old Space에 가득 차면 빈번하고 비용이 큰 가비지 컬렉션이 발생해 응답 속도 저하 또는 OOM(Out of Memory) 충돌이 일어날 수 있으므로 해당 플래그를 통해 Old Space의 제한 크기를 늘리는 튜닝이 권장된다 [5, 17].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[New Space(Young Generation)]], [[Major GC]], [[Mark-Sweep-Compact]], [[Garbage Collection]]
-- **Projects/Contexts:** [[V8 Engine Memory Management]], [[Node.js Performance Tuning]]
-- **Contradictions/Notes:** 소스에 관련 정보가 부족합니다.
-
----
-*Last updated: 2026-04-19*
-- Raw Source: [[00_Raw/2026-04-20/Old Space(Old Generation).md]]
----
diff --git a/Programming & Language/Old Space.md b/Programming & Language/Old Space.md
deleted file mode 100644
index 995b531c..00000000
--- a/Programming & Language/Old Space.md	
+++ /dev/null
@@ -1,36 +0,0 @@
----
-id: P-REINFORCE-AUTO-C312D4
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Old Space"
----
-
-# [[Old Space]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> Old Space(또는 Old generation)는 V8 엔진의 메모리 힙 구조에서 단기 생존 영역인 New Space에서 여러 차례의 가비지 컬렉션(GC)을 견뎌낸 장기 생존 객체들이 저장되는 공간입니다 [1-3]. 주로 사용자 세션, 캐시 데이터, 영구 상태와 같은 장기 보존 데이터가 이곳에 보관됩니다 [4]. 이 공간은 수백 메가바이트 이상의 데이터를 담을 수 있도록 훨씬 크게 설계되었으며, Mark-Sweep 및 Mark-Compact 알고리즘을 사용하는 Major GC에 의해 덜 빈번하지만 더 많은 리소스를 소모하여 관리됩니다 [4-7].
-
-## 📖 구조화된 지식 (Synthesized Content)
-* **객체 승격(Promotion) 메커니즘:** 객체는 처음에 New Space에 할당된 후, 두 번의 마이너 가비지 컬렉션(Minor GC 또는 Scavenge)에서 살아남으면 Old Space로 승격(promotion)됩니다 [1, 3, 8]. Old Space는 단기 객체를 빈번하게 수집하는 New Space와 달리 장기적인 저장 목적으로 설계되었습니다 [6].
-* **공간의 세분화:** Old Space는 가비지 컬렉션 처리를 최적화하기 위해 두 가지 하위 공간으로 분리되어 관리됩니다 [2, 3, 6].
-  * **Old-pointer-space:** 다른 객체들을 가리키는 내부 포인터를 가질 수 있는 대부분의 장기 생존 객체들이 보관됩니다 [2, 3, 9].
-  * **Old-data-space:** 다른 객체에 대한 포인터 없이 순수하게 로우 데이터(문자열, unboxed double 배열 등)만 포함하는 객체들이 저장됩니다 [2, 3, 9]. 이 데이터 공간은 GC의 마킹 단계에서 포인터 추적(tracing)을 건너뛸 수 있어 가비지 컬렉션 소요 시간을 줄여줍니다 [6].
-* **Major GC (가비지 컬렉션):** Old Space의 메모리 관리는 Mark-Sweep 및 Mark-Compact 알고리즘을 수행하는 Major GC(전체 가비지 컬렉션) 사이클을 통해 이루어집니다 [1, 3, 5]. 일정량의 메모리가 Old Space로 승격되면 Major GC가 트리거되어 사용되지 않는 메모리(Garbage)를 해제하고 라이브 객체들을 압축하여 파편화를 줄입니다 [1, 7, 10]. 
-* **Write Barriers 및 저장 버퍼(Store Buffer):** Old Space의 객체가 New Space의 객체를 참조하는 경우, V8 엔진은 이 참조를 추적하기 위해 'Write Barrier' 코드와 'Store Buffer'를 활용합니다 [11-13]. 이는 스캐빈저(Scavenger)가 New Space를 수집할 때 Old Space 전체를 스캔하지 않고도 해당 참조를 파악할 수 있게 해줍니다 [11, 13].
-* **메모리 튜닝 및 누수 감지:** `--trace-gc-verbose` 플래그를 사용하여 로그를 확인할 때, Major GC 이벤트 이후에도 Old space의 사용량이 지속적으로 증가한다면 메모리 누수(Memory Leak)가 발생하고 있다는 강력한 지표가 됩니다 [14]. 개발자는 애플리케이션의 메모리 사용량에 맞게 `--initial_old_space_size` 및 `--max-old-space-size` 커맨드라인 플래그를 사용하여 Old Space의 크기를 직접 제어할 수 있습니다 [3, 15].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[New Space]], [[Major GC]], [[Mark-Sweep-Compact]], [[Write Barrier]], [[Garbage Collection]]
-- **Projects/Contexts:** [[V8 Engine]], [[Node.js Memory Management]]
-- **Contradictions/Notes:** 소스에 따르면 V8은 필요할 경우 운영체제에 더 많은 공간을 요청하여 Old Space 크기를 확장할 수 있으나, V8 Memory Cage(보안 샌드박스 및 포인터 압축) 기능이 활성화된 64비트 시스템에서는 물리적 RAM 용량에 관계없이 V8 힙 전체 크기가 최대 4GB의 연속적인 영역으로 엄격히 제한됩니다 [16-18]. 따라서 Old Space 역시 이 4GB 제한의 영향을 받습니다.
-
----
-*Last updated: 2026-04-19*
-- Raw Source: [[00_Raw/2026-04-20/Old Space.md]]
----
diff --git a/Programming & Language/Opaque Types.md b/Programming & Language/Opaque Types.md
deleted file mode 100644
index 92f3f29e..00000000
--- a/Programming & Language/Opaque Types.md	
+++ /dev/null
@@ -1,30 +0,0 @@
----
-id: P-REINFORCE-AUTO-AB1B53
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Opaque Types"
----
-
-# [[Opaque Types]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> Opaque Types(또는 Branded Types, Nominal Types)는 타입스크립트의 구조적 타이핑(Structural Typing)이 갖는 한계를 극복하기 위해, 구조가 동일한 기본 타입(primitive type)이라도 의미적으로 다른 값을 구별할 수 있도록 고유한 식별자(브랜드)를 부여하는 디자인 패턴입니다 [1-4]. 런타임에는 존재하지 않는 가상의 속성이나 유니크 심볼(unique symbol)을 타입 시스템에만 추가하여 타입 간의 혼용을 컴파일 시점에 차단합니다 [2, 5, 6]. 이를 통해 화폐 단위, 사용자 ID와 주문 ID의 혼동 등 논리적 오류를 방지하고 코드의 안정성과 예측 가능성을 크게 높일 수 있습니다 [7-9].
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[Branded Types]], [[Structural Typing]], [[Nominal Typing]], [[Type Assertions]], [[Type Predicates]]
-- **Projects/Contexts:** [[Domain-Driven Design (DDD)]], [[Zod Validation]], [[Effect TS]], [[ts-brand]]
-- **Contradictions/Notes:** Opaque Types는 타입 안정성을 크게 높여주지만, 코드의 구조적 복잡성을 증가시키고 검증 함수나 타입 래퍼(Wrapper) 등 부가적인 코드를 요구한다는 단점이 있습니다 [30, 31]. 따라서 값의 범위가 명확히 정해져 있는 경우에는 Opaque Type 대신 [[Unions]], [[Enums]], 혹은 [[Template Literal Types]]와 같은 다른 타입스크립트 내장 전략을 활용하는 것이 더 단순하고 나은 해결책이 될 수 있습니다 [30, 32-34]. 추가로 Flow 같은 타입 시스템에서는 Opaque Type을 네이티브로 지원하지만, 타입스크립트 진영에서는 아직 이러한 네이티브 지원에 대한 완전한 합의에 이르지 못했습니다 [35].
-
----
-*Last updated: 2026-04-18*
-- Raw Source: [[00_Raw/2026-04-20/Opaque Types.md]]
----
diff --git a/Programming & Language/Operations-Management.md b/Programming & Language/Operations-Management.md
deleted file mode 100644
index aadbb506..00000000
--- a/Programming & Language/Operations-Management.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-5F96BE
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Operations-Management"
----
-
-# [[Operations-Management]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Operations-Management.md]]
----
diff --git a/Programming & Language/Organizational Behavior.md b/Programming & Language/Organizational Behavior.md
deleted file mode 100644
index 4ef7f381..00000000
--- a/Programming & Language/Organizational Behavior.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-189D31
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Organizational Behavior"
----
-
-# [[Organizational Behavior]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Organizational Behavior.md]]
----
diff --git a/Programming & Language/Organizational-Behavior.md b/Programming & Language/Organizational-Behavior.md
deleted file mode 100644
index d716439d..00000000
--- a/Programming & Language/Organizational-Behavior.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-0FF44B
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Organizational-Behavior"
----
-
-# [[Organizational-Behavior]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Organizational-Behavior.md]]
----
diff --git a/Programming & Language/Organizational-Psychology.md b/Programming & Language/Organizational-Psychology.md
deleted file mode 100644
index dcc7260f..00000000
--- a/Programming & Language/Organizational-Psychology.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-CB4F42
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Organizational-Psychology"
----
-
-# [[Organizational-Psychology]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Organizational-Psychology.md]]
----
diff --git a/Programming & Language/Orinoco GC.md b/Programming & Language/Orinoco GC.md
deleted file mode 100644
index 152c705a..00000000
--- a/Programming & Language/Orinoco GC.md	
+++ /dev/null
@@ -1,30 +0,0 @@
----
-id: P-REINFORCE-AUTO-4DDD3E
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Orinoco GC"
----
-
-# [[Orinoco GC]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> Orinoco는 V8 JavaScript 엔진에 적용된 최신 가비지 컬렉터(GC) 프로젝트의 코드명이다 [1, 2]. 기존의 순차적이고 애플리케이션 실행을 완전히 멈추는 'stop-the-world' 방식의 가비지 컬렉터를 병렬(parallel), 점진적(incremental), 동시적(concurrent) 기술을 활용하는 형태로 변환하여 메인 스레드의 부하를 줄이도록 설계되었다 [1, 3]. 이를 통해 애플리케이션의 일시 정지(pause) 시간을 대폭 단축하고, 애니메이션 및 사용자 입력에 대한 응답성을 크게 향상시키는 역할을 한다 [4-6].
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[V8 Engine]], [[Garbage Collection]], [[Generational Hypothesis]], [[Scavenger]], [[Mark-Sweep-Compact]]
-- **Projects/Contexts:** [[Chrome]], [[Node.js]]
-- **Contradictions/Notes:** 소스 간에 모순되는 정보는 발견되지 않았습니다. 문서 전반에 걸쳐 Orinoco GC 도입으로 인한 병렬성(Parallel) 및 동시성(Concurrent) 최적화의 이점이 일관되게 강조되어 있습니다.
-
----
-*Last updated: 2026-04-19*
-- Raw Source: [[00_Raw/2026-04-20/Orinoco GC.md]]
----
diff --git a/Programming & Language/Orinoco 가비지 컬렉터.md b/Programming & Language/Orinoco 가비지 컬렉터.md
deleted file mode 100644
index 15c3deb5..00000000
--- a/Programming & Language/Orinoco 가비지 컬렉터.md	
+++ /dev/null
@@ -1,42 +0,0 @@
----
-id: P-REINFORCE-AUTO-3353DC
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Orinoco 가비지 컬렉터"
----
-
-# [[Orinoco 가비지 컬렉터]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> Orinoco는 V8 JavaScript 엔진의 가비지 컬렉션(GC) 성능을 최적화하기 위해 도입된 프로젝트의 코드명입니다 [1, 2]. 기존의 순차적이고 프로그램 실행을 멈추게 하는 'stop-the-world' 방식의 수집기를 점진적(Incremental) 폴백(Fallback)을 갖춘 병렬(Parallel) 및 동시성(Concurrent) 수집기로 탈바꿈시켰습니다 [1, 3]. 이를 통해 메인 스레드의 GC 작업 부담을 최소화하여 애플리케이션의 지연 시간(Latency)을 줄이고 스크롤 및 애니메이션 렌더링을 훨씬 부드럽게 만들었습니다 [4, 5].
-
-## 📖 구조화된 지식 (Synthesized Content)
-**핵심 가비지 컬렉션 기술**
-Orinoco는 메인 스레드를 해방시키기 위해 다음 세 가지 주요 최적화 기법을 혼합하여 사용합니다 [2].
-*   **병렬(Parallel) 처리**: 메인 스레드와 헬퍼 스레드가 동시에 대략 같은 양의 GC 작업을 수행합니다 [2]. 애플리케이션 실행을 멈추는 'stop-the-world' 접근법이긴 하지만, 총 중단 시간을 참여하는 스레드 수만큼 나누어 대기 시간을 단축시킵니다 [2].
-*   **점진적(Incremental) 처리**: 전체 GC를 한 번에 하는 대신, 메인 스레드가 간헐적으로 소량의 GC 작업만 수행합니다 [6]. JavaScript 실행과 GC 작업이 번갈아 발생하도록 분산시켜 애플리케이션이 사용자 입력과 애니메이션 처리에 지속적으로 응답할 수 있게 합니다 [6, 7].
-*   **동시성(Concurrent) 처리**: 메인 스레드가 JavaScript를 계속 실행하는 동안, 헬퍼 스레드들이 백그라운드에서 GC 작업을 전적으로 수행합니다 [8]. 이는 메인 스레드를 자유롭게 하지만, 객체의 변경 사항을 관리하기 위해 스레드 간 동기화와 읽기/쓰기 충돌을 제어해야 하는 가장 고난도의 기술입니다 [8].
-
-**주요 GC 단계별 Orinoco의 적용**
-*   **Minor GC (Scavenger)**: V8의 Young 세대 가비지 컬렉터는 병렬 스캐빈징(Parallel scavenging)을 사용하여 여러 헬퍼 스레드에 작업을 분산시킵니다 [9, 10]. 각 헬퍼 스레드는 포인터를 따라가며 살아있는 객체를 새로운 메모리 공간(To-Space)으로 대피시키고 포인터를 병렬로 업데이트합니다 [9]. 
-*   **Major GC (Mark-Compact)**: Old 세대의 수집은 주로 동시 마킹(Concurrent marking)으로 시작됩니다 [11]. 백그라운드의 헬퍼 스레드들이 살아있는 객체를 찾아 마킹하는 동안 메인 스레드는 JavaScript를 실행하며, 새로 생성된 참조는 '쓰기 장벽(Write barriers)'을 통해 추적됩니다 [11, 12]. 이후 메인 스레드는 잠시 멈춰 빠른 마킹 완료 처리를 한 뒤, 헬퍼 스레드들과 함께 병렬 압축(Parallel compaction)을 수행하고 백그라운드에서는 동시 스윕(Concurrent sweeping)을 진행합니다 [13, 14].
-
-**기타 최적화 기법**
-*   **Idle-time GC (유휴 시간 GC)**: Chrome과 같은 환경에서 애니메이션 프레임(예: 초당 60프레임, 약 16.6ms)을 렌더링한 후 여유 시간이 남을 경우, GC가 해당 유휴 시간을 활용하여 선제적으로 가비지 컬렉션 작업을 수행합니다 [5, 15].
-*   기타 V8의 블랙 할당(Black allocation) 기능과 포인터 추적(Tracking Pointers) 기법을 개선하여 On-heap 및 Off-heap 메모리의 피크 사용량을 큰 폭으로 줄였습니다 [3, 16, 17].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[가비지 컬렉션(Garbage Collection)]], [[V8 JavaScript 엔진]], [[Minor GC (Scavenger)]], [[Major GC (Mark-Compact)]], [[세대별 가비지 컬렉션(Generational Garbage Collection)]]
-- **Projects/Contexts:** [[V8 메모리 관리 및 최적화]], [[Node.js 및 Chrome 브라우저 렌더링 성능 최적화]]
-- **Contradictions/Notes:** 과거 V8 버전은 Cheney의 동기식 세미스페이스 복사 알고리즘을 사용했으나, V8 v6.2부터 Orinoco 프로젝트의 일환으로 동적 작업 훔치기(Work stealing) 기법을 사용하는 Halstead 방식의 병렬 스캐빈저로 대체되었습니다 [10, 18].
-
----
-*Last updated: 2026-04-19*
-- Raw Source: [[00_Raw/2026-04-20/Orinoco 가비지 컬렉터.md]]
----
diff --git a/Programming & Language/Orinoco 프로젝트.md b/Programming & Language/Orinoco 프로젝트.md
deleted file mode 100644
index aeb8e3de..00000000
--- a/Programming & Language/Orinoco 프로젝트.md	
+++ /dev/null
@@ -1,34 +0,0 @@
----
-id: P-REINFORCE-AUTO-6EB2FE
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Orinoco 프로젝트"
----
-
-# [[Orinoco 프로젝트]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> Orinoco 프로젝트는 V8 JavaScript 엔진의 가비지 컬렉터(GC)를 최신 기술로 개선하기 위해 진행된 프로젝트의 코드명입니다 [1-3]. 이 프로젝트는 기존의 순차적이고 모든 실행을 멈추는 'stop-the-world' 방식의 가비지 컬렉터를 병렬(parallel), 동시(concurrent), 점진적(incremental) 기술을 활용하는 형태로 진화시켰습니다 [1, 2, 4]. 주된 목적은 메인 스레드의 부하를 덜어주어 가비지 컬렉션으로 인한 프로그램 중지 시간(pause time)을 최소화하고 사용자 경험을 향상시키는 것입니다 [2, 5].
-
-## 📖 구조화된 지식 (Synthesized Content)
-- **GC 모델의 현대화:** Orinoco는 기존의 'stop-the-world' 중지 방식을 벗어나, 동시적이고 병렬적이며 점진적인 GC 모델로의 전환을 의미합니다 [1, 4]. 이를 위해 스마트 페이징과 동시성 친화적 알고리즘을 도입하여 '구 세대(Old Generation)'와 '신 세대(Young Generation)' 가비지 컬렉터를 병렬화했습니다 [5].
-- **병렬(Parallel) 기법 도입:** 메인 스레드와 다수의 헬퍼 스레드가 동시에 거의 동일한 양의 작업을 수행하도록 처리합니다 [2]. 이 역시 실행을 일시 중지하는 방식이지만, 동기화에 필요한 약간의 오버헤드를 제외하면 전체 중지 시간을 참여하는 스레드의 수만큼 나누어 크게 줄일 수 있습니다 [2].
-- **점진적(Incremental) 마킹:** 마킹 작업을 아주 작은 덩어리로 나누어 JavaScript 실행 중간중간에 교차로 배치(interleave)하는 방식입니다 [6, 7]. 이 방식은 총 GC 시간을 줄이지는 못하지만 긴 중지 시간을 잘게 분산시킴으로써, 애플리케이션이 끊김 없이 사용자 입력이나 애니메이션에 반응할 수 있도록 돕습니다 [6, 7].
-- **동시(Concurrent) 처리:** 메인 스레드가 멈추지 않고 JavaScript를 실행하는 동안, 백그라운드의 헬퍼 스레드들이 GC 작업을 전담하여 처리합니다 [8]. 객체의 상태가 언제든 변할 수 있어 읽기/쓰기 경합(read/write races)을 처리해야 하는 가장 복잡한 기술이지만, 메인 스레드를 온전히 자유롭게 해방시킬 수 있습니다 [8].
-- **프로젝트의 성과 및 확장:** Orinoco 프로젝트를 통해 많은 GC 작업이 백그라운드로 이동하면서 지연 시간과 페이지 로딩 성능이 비약적으로 향상되었으며, 스크롤이나 애니메이션이 훨씬 부드러워졌습니다 [9]. 더 나아가, 여기서 개발된 새로운 기술의 일부는 Chrome의 렌더러(Blink)에 내장된 가비지 컬렉터인 'Oilpan'으로 이식하여 협력을 개선하는 작업도 진행 중입니다 [10].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[V8 Engine]], [[Garbage Collection (GC)]], [[Stop-the-world]], [[Incremental Marking]]
-- **Projects/Contexts:** [[Oilpan]], [[Blink]]
-- **Contradictions/Notes:** 소스에 관련 정보가 부족합니다. (소스 내에서 Orinoco 프로젝트에 대한 상충되는 주장은 발견되지 않습니다.)
-
----
-*Last updated: 2026-04-19*
-- Raw Source: [[00_Raw/2026-04-20/Orinoco 프로젝트.md]]
----
diff --git a/Programming & Language/Orinoco(V8 GC 프로젝트).md b/Programming & Language/Orinoco(V8 GC 프로젝트).md
deleted file mode 100644
index e099f023..00000000
--- a/Programming & Language/Orinoco(V8 GC 프로젝트).md	
+++ /dev/null
@@ -1,30 +0,0 @@
----
-id: P-REINFORCE-AUTO-6C6E51
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Orinoco(V8 GC 프로젝트)"
----
-
-# [[Orinoco(V8 GC 프로젝트)]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> Orinoco는 V8 JavaScript 엔진의 가비지 컬렉터(GC)를 혁신적으로 개선하기 위해 진행된 프로젝트의 코드명이다 [1, 2]. 이 프로젝트의 핵심 목표는 기존의 순차적이고 메인 스레드를 멈추게 하던(stop-the-world) 가비지 컬렉터를 병렬(Parallel), 점진적(Incremental), 동시적(Concurrent) 수집 방식으로 변환하는 것이다 [1]. 이를 통해 메인 스레드의 부하를 해방시키고 가비지 컬렉션으로 인한 애플리케이션 지연(jank)과 대기 시간을 대폭 줄여 원활한 사용자 경험을 제공한다 [3, 4].
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[V8 Engine]], [[Garbage Collection]], [[Scavenger (Minor GC)]], [[Mark-Compact (Major GC)]]
-- **Projects/Contexts:** [[V8 JavaScript Engine Memory Management]]
-- **Contradictions/Notes:** 점진적(Incremental) 가비지 컬렉션 기법의 경우, 메인 스레드의 일시 정지(Pause) 기간을 여러 개의 짧은 시간으로 분산시켜 체감 대기 시간을 줄이지만, 메인 스레드에서 수행하는 GC의 총시간 자체는 오히려 약간 증가한다는 특징이 있다 [8].
-
----
-*Last updated: 2026-04-19*
-- Raw Source: [[00_Raw/2026-04-20/Orinoco(V8 GC 프로젝트).md]]
----
diff --git a/Programming & Language/Orinoco.md b/Programming & Language/Orinoco.md
deleted file mode 100644
index 68f548ce..00000000
--- a/Programming & Language/Orinoco.md	
+++ /dev/null
@@ -1,33 +0,0 @@
----
-id: P-REINFORCE-AUTO-E147D0
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Orinoco"
----
-
-# [[Orinoco]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> Orinoco는 V8 JavaScript 엔진의 가비지 컬렉터(GC) 성능을 최적화하기 위해 진행된 프로젝트의 코드명입니다 [1, 2]. 이 프로젝트는 기존의 순차적이고 애플리케이션 실행을 완전히 멈추는(stop-the-world) 방식의 가비지 컬렉터를 병렬(parallel), 동시(concurrent), 점진적(incremental) 기법을 활용하는 형태로 변환했습니다 [1, 2]. 결과적으로 메인 스레드의 부담을 해방시켜 지연(latency) 및 멈춤(jank) 현상을 줄이고, 애니메이션과 사용자 상호작용을 훨씬 부드럽게 만들어 줍니다 [3-6].
-
-## 📖 구조화된 지식 (Synthesized Content)
-* **병렬(Parallel) 처리**: 메인 스레드와 여러 헬퍼 스레드들이 동시에 동일한 가비지 컬렉션 작업을 나누어 수행하는 기법입니다 [5]. 애플리케이션 실행이 일시 정지되는 'stop-the-world' 접근법이기는 하지만, 다수의 스레드가 작업을 분담하므로 총 정지 시간이 스레드 수에 비례해 크게 단축됩니다 [5]. Orinoco의 병렬 스캐빈저(Parallel Scavenger)는 이 방식을 사용하여 Young Generation의 GC 작업 시간을 워크로드에 따라 20%~50%가량 감소시켰습니다 [6-8].
-* **점진적(Incremental) 처리**: 메인 스레드가 한 번에 전체 GC를 수행하는 대신, 소량의 GC 작업만 간헐적으로 수행하도록 쪼개는 방식입니다 [9]. 이를 통해 가비지 컬렉션 중간에 JavaScript 실행이 틈틈이 이루어지므로 프로그램이 멈추지 않고 사용자 입력이나 애니메이션에 계속 반응할 수 있습니다 [9].
-* **동시(Concurrent) 처리**: 메인 스레드가 JavaScript를 멈춤 없이 계속 실행하는 동안, 헬퍼 스레드들이 백그라운드에서 완전히 GC 작업을 전담하여 수행합니다 [10, 11]. 힙의 상태가 언제든 변할 수 있어 읽기/쓰기 경합(race)을 관리해야 하므로 구현이 가장 까다롭지만, 메인 스레드가 자유로워진다는 큰 장점이 있습니다 [10]. Orinoco는 동시 마킹 및 스위핑을 도입하여 무거운 WebGL 게임 등에서 일시 정지 시간을 최대 50%까지 줄였습니다 [6, 12].
-* **메모리 및 효율성 최적화**: Orinoco 프로젝트는 세대 간(generational) 엄격한 경계 없이 통합된 힙에서 작동하며, 스마트 페이징 기법과 블랙 할당(Black Allocation) 최적화 등을 통해 저사양 메모리 기기에서 온힙(on-heap) 최고 메모리 소비량을 최대 40%, 오프힙(off-heap) 소비량을 20%까지 줄이는 성과를 내었습니다 [13].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[V8 Engine]], [[Garbage Collection]], [[Scavenger]], [[Mark-Compact]]
-- **Projects/Contexts:** [[JavaScript Memory Management]]
-- **Contradictions/Notes:** 소스 간 Orinoco의 목적과 기술적 효과에 대해 상충되는 정보는 발견되지 않으며, 모든 소스가 공통적으로 메인 스레드의 지연을 없애고 메모리 관리 효율성을 높이기 위한 최적화 프로젝트로 일관되게 설명하고 있습니다.
-
----
-*Last updated: 2026-04-19*
-- Raw Source: [[00_Raw/2026-04-20/Orinoco.md]]
----
diff --git a/Programming & Language/Overdraw.md b/Programming & Language/Overdraw.md
deleted file mode 100644
index 1d22d6ed..00000000
--- a/Programming & Language/Overdraw.md	
+++ /dev/null
@@ -1,37 +0,0 @@
----
-id: P-REINFORCE-AUTO-421E43
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Overdraw"
----
-
-# [[Overdraw]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 오버드로우(Overdraw)는 렌더링 파이프라인의 프래그먼트 셰이딩(Fragment Shading) 단계에서 동일한 픽셀 위치에 렌더링 연산 및 쓰기 작업이 여러 번 중첩되어 GPU 자원이 낭비되는 현상입니다. InstancedMesh를 사용할 때 개별 인스턴스에 대한 자동 정렬(Sorting) 기능이 부재하여 깊이 테스트(Early-Z)를 통한 최적화가 무력화되면서 막대한 오버드로우가 발생할 수 있으며, 이는 심각한 렌더링 프레임 지연의 핵심 원인이 됩니다[1, 2].
-
-## 📖 구조화된 지식 (Synthesized Content)
-*   **오버드로우의 발생 원리:** 
-    투명한 지오메트리가 겹쳐 있거나 객체들이 비효율적으로 정렬되어 있을 때, 가려져서 최종 화면에 보이지 않을 픽셀에 대해서까지 GPU가 계산을 수행하면서 발생합니다[1].
-*   **InstancedMesh의 구조적 정렬 부재:** 
-    일반적인 불투명 객체는 '앞에서 뒤로(Front-to-Back)' 정렬하여 렌더링함으로써 뒤에 가려진 픽셀 연산을 조기에 종료하는 'Early-Z' 기법을 활용할 수 있습니다. 그러나 InstancedMesh는 이러한 자동 정렬 기능을 제공하지 않으며, 오직 버퍼에 저장된 순서대로만 인스턴스를 렌더링합니다. 카메라와 멀리 있는 인스턴스가 먼저 그려지고 가까운 인스턴스가 나중에 그려질 경우, GPU는 동일한 픽셀 영역에 대해 중복된 계산을 강제로 수행하게 됩니다[2].
-*   **드로우 콜 최적화의 역설 (성능 저하 사례):** 
-    실제 벤치마크 사례 연구에 따르면, 5,000개의 구체를 렌더링할 때 드로우 콜이 1회인 InstancedMesh 방식의 FPS가 드로우 콜이 5,000회인 일반 개별 메쉬 방식보다 오히려 더 낮게 측정되는 현상이 보고되었습니다. 이는 드로우 콜 감소를 통해 얻은 CPU 연산 이득보다, 정렬되지 않은 인스턴스들이 유발한 막대한 오버드로우 비용이 GPU의 픽셀 처리 성능 한계를 상회했기 때문입니다[2].
-*   **병목을 가중시키는 요인:** 
-    오버드로우로 인한 렌더링 병목 현상은 복잡한 조명 연산이 포함된 `MeshStandardMaterial`과 같은 재질을 사용할 때 씬(Scene)을 프래그먼트 바운드(Fragment-bound) 상태로 빠뜨리며 더욱 심화됩니다[2, 3]. 또한 나뭇잎(Foliage)처럼 투명도(Transparency)를 지닌 지오메트리의 경우, 조기 깊이 테스트가 비활성화되고 동일한 픽셀을 5~10번씩 반복하여 렌더링해야 하므로 픽셀 채우기 비율(Fill rate)이 급감하는 치명적인 원인이 됩니다[1, 4].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[InstancedMesh]], [[Fragment Shading]], [[Early-Z]], [[프래그먼트 바운드(Fragment-bound)]], [[Draw Call]], [[Sorting]]
-- **Projects/Contexts:** [[three.js Issue #30352]], [[대규모 인스턴스 렌더링 및 투명도 처리]]
-- **Contradictions/Notes:** CPU 부하를 유발하는 드로우 콜을 줄이기 위해 InstancedMesh를 도입하더라도, 내부 인스턴스들의 정렬 부재가 유발하는 오버드로우 비용이 더 크다면 오히려 드로우 콜이 많은 개별 메쉬 렌더링 방식보다 FPS가 떨어질 수 있다는 역설적인 결과를 보여줍니다[2, 5].
-
----
-*Last updated: 2026-04-19*
-- Raw Source: [[00_Raw/2026-04-20/Overdraw.md]]
----
diff --git a/Programming & Language/Page Experience Algorithm.md b/Programming & Language/Page Experience Algorithm.md
deleted file mode 100644
index 6dc70818..00000000
--- a/Programming & Language/Page Experience Algorithm.md	
+++ /dev/null
@@ -1,33 +0,0 @@
----
-id: P-REINFORCE-AUTO-6A1F2E
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Page Experience Algorithm"
----
-
-# [[Page Experience Algorithm]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> Page Experience Algorithm(페이지 경험 알고리즘)은 구글(Google)이 검색 순위를 결정할 때 사용하는 알고리즘입니다 [1]. 이 알고리즘은 실제 사용자의 웹페이지 경험을 측정하는 표준화된 지표인 코어 웹 바이탈(Core Web Vitals)을 주요 랭킹 신호(Ranking signals)로 사용합니다 [1, 2]. 이 알고리즘의 기준을 충족하는 것은 검색 순위를 방어하거나 향상시키고 사용자 유지율을 높이는 데 필수적입니다 [1, 3].
-
-## 📖 구조화된 지식 (Synthesized Content)
-- **핵심 평가 지표 (Core Web Vitals):** 페이지 경험 알고리즘은 실제 사용자 경험의 핵심 측면을 측정하며, 주로 세 가지 차원에 집중합니다. 첫째는 콘텐츠가 나타나는 속도를 측정하는 로딩 성능(LCP), 둘째는 사용자 작업에 페이지가 얼마나 빨리 반응하는지를 나타내는 상호작용성(INP, 기존 FID에서 대체됨), 셋째는 요소가 로드되는 동안 레이아웃이 얼마나 안정적으로 유지되는지를 나타내는 시각적 안정성(CLS)입니다 [2, 4]. 
-- **검색 순위 및 사용자 경험과의 상관관계:** 이 알고리즘에서 요구하는 '우수(Good)' 임계값을 충족하는 페이지는 검색 결과에서 더 나은 순위를 기록하고 사용자를 더 효과적으로 유지하는 경향이 있습니다 [1]. 반대로 이 알고리즘이 평가하는 지표가 나쁘면 높은 이탈률과 사용자 불만으로 이어지는 상관관계를 보입니다 [1].
-- **데이터 수집 방식:** 구글은 이 알고리즘의 평가를 위해 크롬 사용자 경험 보고서(CrUX)를 통해 수집된 실제 사용자의 현장 데이터(Field data)를 활용하여 사용자가 페이지를 실제로 어떻게 경험하는지 평가합니다 [1].
-- **한계:** 제공된 소스에는 페이지 경험 알고리즘이 코어 웹 바이탈을 랭킹 신호로 취급한다는 점은 명시되어 있으나, 그 외에 알고리즘의 구체적인 가중치, 내부 구조 및 기타 평가 요소에 대한 세부적인 관련 정보가 부족합니다.
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[Core Web Vitals]], [[INP (Interaction to Next Paint)]], [[LCP (Largest Contentful Paint)]], [[CLS (Cumulative Layout Shift)]]
-- **Projects/Contexts:** [[Google Search Ranking]], [[Chrome User Experience Report (CrUX)]]
-- **Contradictions/Notes:** 소스에 코어 웹 바이탈 지표들 외에 페이지 경험 알고리즘의 내부적인 작동 원리나 코어 웹 바이탈 이외의 추가적인 구성 요소에 대한 관련 정보가 부족합니다.
-
----
-*Last updated: 2026-04-19*
-- Raw Source: [[00_Raw/2026-04-20/Page Experience Algorithm.md]]
----
diff --git a/Programming & Language/PageRank (페이지랭크 알고리즘).md b/Programming & Language/PageRank (페이지랭크 알고리즘).md
deleted file mode 100644
index dd374dbd..00000000
--- a/Programming & Language/PageRank (페이지랭크 알고리즘).md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-ECBEB7
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - PageRank (페이지랭크 알고리즘)"
----
-
-# [[PageRank (페이지랭크 알고리즘)]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/PageRank (페이지랭크 알고리즘).md]]
----
diff --git a/Programming & Language/Papers Please (Mechanics as Moral Argument).md b/Programming & Language/Papers Please (Mechanics as Moral Argument).md
deleted file mode 100644
index 3ea993a7..00000000
--- a/Programming & Language/Papers Please (Mechanics as Moral Argument).md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-126062
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Papers Please (Mechanics as Moral Argument)"
----
-
-# [[Papers Please (Mechanics as Moral Argument)]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Papers, Please (Mechanics as Moral Argument).md]]
----
diff --git a/Programming & Language/Parse dont validate.md b/Programming & Language/Parse dont validate.md
deleted file mode 100644
index 4bf733c6..00000000
--- a/Programming & Language/Parse dont validate.md	
+++ /dev/null
@@ -1,33 +0,0 @@
----
-id: P-REINFORCE-AUTO-D95ED1
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Parse dont validate"
----
-
-# [[Parse dont validate]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 'Parse, don't validate(검증하지 말고 파싱하라)'는 프로그램의 경계에서 타입이 없거나 느슨한 데이터를 잘 정의된 타입의 데이터로 변환하는 소프트웨어 설계 철학입니다[1]. 코드 전반에 걸쳐 데이터의 유효성을 반복적으로 검사하는 대신, 시스템 진입점에서 단 한 번 파싱하여 안전한 타입으로 만듭니다[1]. 이를 통해 유효성 검사 로직의 파편화를 막고 타입 검사기의 정적 분석 능력을 극대화하여 코드의 예측 가능성과 안정성을 높입니다[2, 3].
-
-## 📖 구조화된 지식 (Synthesized Content)
-- **기본 원칙 및 파싱 흐름**: Alexis King의 동명 아티클을 통해 널리 알려진 이 개념은 시스템의 경계(입구 및 출구)에서 입력 데이터를 한 번 파싱하는 것을 핵심으로 합니다[1, 2]. 이 파싱 단계에서 데이터의 유효성 검사와 변환이 동시에 이루어지며, 이후의 애플리케이션 흐름에서는 완전히 타입이 지정되고 검증된 데이터만을 사용하게 됩니다[1].
-- **수비적 프로그래밍(Defensive Programming)의 정점**: 단순히 데이터의 유효성 여부만 확인(Validate)하고 끝내는 것이 아니라, 데이터를 더 구체적이고 신뢰할 수 있는 타입의 객체로 변환(Parse)하여 시스템 내부로 전달합니다[3]. 이는 의도하지 않은 불확실한 데이터의 유입을 원천적으로 차단하는 견고한 아키텍처적 방어막 역할을 합니다[3].
-- **제어 흐름(Control flow)과 개발자 경험 향상**: 유효성 검사 로직을 시스템 경계에만 배치함으로써, 비즈니스 로직 곳곳에 검증 코드가 어지럽게 흩어지는 것을 방지할 수 있습니다[2]. 결과적으로 타입 시스템의 정적 분석에 무거운 작업을 위임하여 개발자의 신뢰를 높이고, 관리해야 할 코드의 양(Code volume)과 복잡도를 줄이는 데 크게 기여합니다[2, 4].
-- **구현 방법 및 생태계 도구**: 이 철학을 실현하기 위해 Zod와 같은 런타임 유효성 검사/파싱 라이브러리가 자주 활용됩니다[3, 5]. 구체적으로는 Zod 등을 통해 알 수 없는(Unknown) 데이터를 잘 알려진 타입으로 변환하며, 런타임 데이터에 [[Branded Types]]를 부여하여 시스템 내부로 전달하는 것이 이 철학을 완벽히 실현하는 구체적 방법론입니다[3, 5].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[Branded Types]], [[Zod]], [[Defensive Programming]], [[Static Analysis]], [[Structural Typing]]
-- **Projects/Contexts:** [[API Boundary Handling]], [[State Management]]
-- **Contradictions/Notes:** 소스 내에서 이 철학에 대한 상반된 주장이나 모순은 발견되지 않습니다. 오히려 상태 관리(State management) 문제나 복잡성 증가를 완화하는 TypeScript의 핵심 모범 사례 중 하나로 강력히 권장됩니다[1, 6].
-
----
-*Last updated: 2026-04-18*
-- Raw Source: [[00_Raw/2026-04-20/Parse, don't validate.md]]
----
diff --git a/Programming & Language/Performance Panel.md b/Programming & Language/Performance Panel.md
deleted file mode 100644
index 1889102c..00000000
--- a/Programming & Language/Performance Panel.md	
+++ /dev/null
@@ -1,46 +0,0 @@
----
-id: P-REINFORCE-AUTO-91C413
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Performance Panel"
----
-
-# [[Performance Panel]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> Performance Panel(성능 패널)은 웹 페이지의 런타임 및 로드 성능을 분석하고 디버깅하기 위해 사용되는 Chrome DevTools의 핵심 진단 도구입니다 [1, 2]. 이 패널은 페이지의 렌더링, 자바스크립트 실행, 네트워크 활동 및 프레임 속도(FPS) 등을 기록하여 플레임 차트 등의 형태로 시각화합니다 [3-6]. 개발자는 이를 통해 메인 스레드를 차단하는 긴 작업(Long tasks)이나 상호작용 지연 등 성능 병목 현상의 원인을 파악하고 웹 성능을 최적화할 수 있습니다 [2, 4, 7].
-
-## 📖 구조화된 지식 (Synthesized Content)
-* **성능 기록 및 환경 시뮬레이션**
-  * Performance 패널은 페이지가 로드되는 동안이나 사용자가 상호작용하는 런타임 동안의 모든 활동을 기록할 수 있습니다 [8, 9].
-  * 모바일 기기 등 다양한 사용자 환경에서의 성능을 파악하기 위해 CPU 스로틀링(예: 4x 또는 20x 느리게 설정) 및 네트워크 스로틀링 기능을 제공하여, 저사양 기기 환경에서의 성능 병목을 에뮬레이션할 수 있습니다 [2, 10-12].
-
-* **메인 스레드 활동 및 플레임 차트(Flame Chart) 분석**
-  * 기록된 성능 트레이스 중 'Main' 트랙은 메인 스레드에서 실행된 자바스크립트 함수 호출과 렌더링 활동을 플레임 차트 형식으로 보여줍니다 [4, 6].
-  * X축은 시간의 흐름을, Y축은 콜 스택(Call stack)을 나타내며, 50밀리초를 초과하여 브라우저의 반응성을 떨어뜨리는 긴 작업(Long tasks)은 빨간색 삼각형과 빨간색 음영으로 강조 표시됩니다 [4, 6, 7].
-  * 개발자는 이 차트를 통해 특정 레이아웃 이벤트나 스크립트가 실행되는 데 걸린 시간을 추적하고 원인이 되는 소스 코드의 특정 라인으로 이동할 수 있습니다 [4].
-
-* **Core Web Vitals 및 상호작용 모니터링**
-  * 패널 진입 시 제공되는 '라이브 메트릭(Live metrics)' 화면을 통해 현재 페이지의 LCP, CLS, INP와 같은 Core Web Vitals 데이터를 실시간으로 모니터링할 수 있습니다 [13].
-  * 'Interactions' 트랙은 사용자의 포인터 입력 등 상호작용과 관련된 입력 지연, 처리 시간, 프레젠테이션 지연을 시각화하며, 200밀리초 이상의 긴 지연이 발생할 경우 INP 경고를 표시하여 반응성 문제를 추적하도록 돕습니다 [2, 14, 15].
-
-* **다양한 분석 도구와 AI 기반 인사이트**
-  * **리소스 및 하드웨어 지표:** 초당 프레임 수(FPS) 차트, 네트워크 요청의 폭포수(Waterfall) 흐름, GPU 활동, 그리고 가비지 컬렉션(GC) 빈도를 파악할 수 있는 메모리 측정 항목 등을 제공합니다 [3, 16-18].
-  * **Insights 패널:** 기록된 데이터를 바탕으로 LCP 요청 문제나 렌더링을 차단하는 요청 등 성능 개선 기회를 자동으로 식별하고 제안합니다 [19-22].
-  * **AI 디버깅 기능:** LLM을 활용하여 Performance 패널 내부의 특정 느린 작업을 분석하거나 여러 작업에 대한 주석을 자동 생성하는 기능이 도입되었습니다 [23].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[Chrome DevTools]], [[Core Web Vitals]], [[Interaction to Next Paint (INP)]], [[Flame Chart]], [[Main Thread]]
-- **Projects/Contexts:** [[Web Performance Debugging]], [[Performance Profiling]]
-- **Contradictions/Notes:** Performance 패널의 로컬 측정값은 측정 시점의 로컬 디바이스 및 네트워크 환경의 영향을 크게 받으므로, 실제 전 세계 사용자의 경험을 정확히 파악하려면 CrUX(Chrome User Experience Report) 필드 데이터의 환경 설정에 맞춰 DevTools 환경을 구성하고 비교 분석하는 것이 중요합니다 [24, 25].
-
----
-*Last updated: 2026-04-19*
-- Raw Source: [[00_Raw/2026-04-20/Performance Panel.md]]
----
diff --git a/Programming & Language/Pointer Compression.md b/Programming & Language/Pointer Compression.md
deleted file mode 100644
index 98d05682..00000000
--- a/Programming & Language/Pointer Compression.md	
+++ /dev/null
@@ -1,40 +0,0 @@
----
-id: P-REINFORCE-AUTO-DEB938
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Pointer Compression"
----
-
-# [[Pointer Compression]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> Pointer Compression(포인터 압축)은 64비트 플랫폼에서 V8 엔진의 메모리 오버헤드를 줄이기 위해 포인터를 베이스 주소로부터의 32비트 오프셋(offset)으로 저장하는 기술입니다 [1]. 이 기술은 V8 힙 크기를 최대 40%까지 줄이고 CPU 및 가비지 컬렉션(GC) 성능을 5~10% 향상시키는 장점이 있습니다 [2]. 하지만 포인터 압축을 활성화하면 V8 힙의 최대 크기가 4GB로 제한된다는 주요한 단점이 수반됩니다 [1, 3].
-
-## 📖 구조화된 지식 (Synthesized Content)
-- **작동 원리 및 메모리 구조:**
-  64비트 플랫폼에서 V8 엔진은 객체 참조에 따른 메모리 오버헤드를 절반으로 줄이기 위해 전체 64비트 주소 대신 베이스 주소(base address)로부터의 32비트 오프셋을 포인터로 저장합니다 [1]. 이러한 구조적 변경으로 인해 V8의 모든 힙(Heap) 객체는 4GB의 연속된 '케이지(cage)' 영역 내에 강제로 상주해야만 합니다 [1]. 
-
-- **성능 이점 (Performance Benefits):**
-  포인터 압축은 메모리 및 성능 최적화에 크게 기여합니다. 이를 통해 V8 힙 크기를 최대 40%까지 감소시킬 수 있으며, CPU 및 가비지 컬렉션(GC)의 성능을 5%에서 10%가량 향상시킵니다 [2]. 대다수의 애플리케이션에서는 이러한 이점이 매우 유의미한 성능 향상으로 이어집니다 [2].
-
-- **메모리 한계 및 영향 (Limitations):**
-  포인터 압축의 가장 큰 부작용은 V8 힙 크기가 4GB를 초과할 수 없다는 것입니다 [3]. 시스템이 128GB의 RAM을 보유하고 있더라도 단일 V8 isolate의 관리되는 힙 공간은 엄격하게 4GB로 제한됩니다 [4]. 애플리케이션이 이 메모리 한계에 도달하게 되면, V8 엔진은 치명적인 OOM(Out of Memory) 충돌을 피하기 위해 가용 공간을 확보하려고 시도하며 이 과정에서 Major GC의 빈도가 극적으로 증가하게 됩니다 [4].
-
-- **해결 및 우회 방안 (Workarounds):**
-  4GB 이상의 더 큰 힙 공간이 필수적인 애플리케이션의 경우 몇 가지 우회 방법이 존재합니다. 포인터 압축이 비활성화된 Node.js의 복사본을 앱에 포함하여 메모리 집약적인 작업을 자식 프로세스(child process)로 분리시키거나, 포인터 압축 기능 자체를 비활성화한 사용자 정의(custom) 버전의 Electron을 빌드하여 사용할 수 있습니다 [5].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[V8 Memory Cage]], [[Garbage Collection (GC)]], [[Out of Memory (OOM)]], [[V8 Heap]]
-- **Projects/Contexts:** [[V8 Engine]], [[Electron]], [[Node.js]], [[Chromium]]
-- **Contradictions/Notes:** 소스에 따르면 포인터 압축은 메모리 사용량을 대폭 줄이고 CPU 효율을 높이지만, 그 대가로 힙 크기를 4GB로 강제 제한하여 메모리 집약적인 작업에는 불리할 수 있다는 명확한 트레이드오프(trade-off)를 갖습니다 [2-4].
-
----
-*Last updated: 2026-04-19*
-- Raw Source: [[00_Raw/2026-04-20/Pointer Compression.md]]
----
diff --git a/Programming & Language/Pointer Poisoning.md b/Programming & Language/Pointer Poisoning.md
deleted file mode 100644
index fdf3d3d2..00000000
--- a/Programming & Language/Pointer Poisoning.md	
+++ /dev/null
@@ -1,33 +0,0 @@
----
-id: P-REINFORCE-AUTO-F1EA31
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Pointer Poisoning"
----
-
-# [[Pointer Poisoning]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 포인터 포이즈닝(Pointer Poisoning)은 스펙터(Spectre) 및 멜트다운(Meltdown) 취약점 공격을 방어하기 위해 웹킷(WebKit)과 같은 브라우저 엔진에 도입된 브랜치리스(Branchless) 보안 검사 기법입니다 [1-3]. 컴파일 타임에 포인터 필드에 무작위의 고유한 포이즌 값을 할당하며, 잘못된 값으로 포이즌을 해제(unpoisoning)할 경우 매핑되지 않은 포인터가 되도록 유도하여 보안을 유지합니다 [3, 4]. 이를 통해 타입 혼동(Type Confusion)을 막고 임의의 메모리 읽기나 원격 코드 실행 공격을 방지합니다 [4].
-
-## 📖 구조화된 지식 (Synthesized Content)
-* **도입 배경 및 목적:** 최신 프로세서의 추측 실행(Speculative Execution)을 악용하는 스펙터 취약점은 기존의 브랜치(분기) 기반 보안 검사인 타입 검사나 경계 검사를 무력화할 수 있습니다 [5, 6]. 이에 대응하여 WebKit의 JavaScriptCore 엔진 등은 타이머 정밀도 감소와 함께, 브랜치에 의존하지 않는 '포인터 포이즈닝'을 도입하여 웹 타이밍 보안을 근본적으로 재설계했습니다 [1, 2].
-* **동작 원리:** 포인터 필드의 각 정적 선언에 고유한 포이즌(poison) 값을 부여하는 방식으로 작동합니다 [3]. 특정 클래스나 타입에 고유한 키(예: `FooDataKey`)를 바탕으로 컴파일 타임에 무작위 포이즌 값을 계산하여 할당하게 됩니다 [4].
-* **보안 효과:** 할당된 포이즌 값들은 상위 비트(high bits)가 서로 다르기 때문에, 악의적인 공격자가 타입 검사를 우회하여 잘못된 포이즌 값으로 해제를 시도하면 매핑되지 않은 포인터(unmapped pointer)를 반환하게 됩니다 [3]. 이는 스펙터 공격을 방어하는 핵심 수단일 뿐만 아니라, 타입 혼동을 이용한 원격 코드 실행(Remote Code Execution) 공격을 어렵게 만들어 시스템을 보호합니다 [4].
-* **성능과의 트레이드오프:** 포인터 포이즈닝은 때때로 추가적인 메모리 간접 참조(indirections) 없이도 데이터 구조에 적용될 수 있습니다 [4]. 그러나 필수적인 보안 완화 기술임에도 불구하고, 자바스크립트 엔진과 JIT(Just-In-Time) 컴파일러가 수행하는 그래픽 실행 등의 중요 경로에 추가적인 명령어를 삽입하게 되므로 모든 작업의 기본 마이크로 레이턴시(micro-latency)를 약간 증가시키는 원인이 됩니다 [7].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[Spectre]], [[Meltdown]], [[Branchless Security Checks]], [[Speculative Execution]], [[Type Confusion]]
-- **Projects/Contexts:** [[WebKit]], [[JavaScriptCore]]
-- **Contradictions/Notes:** 소스 내에서 명시적인 모순은 발견되지 않으나, 포인터 포이즈닝 기술이 보안성을 크게 향상시키는 대신 자바스크립트 엔진의 마이크로 레이턴시를 소폭 증가시킨다는 성능상의 트레이드오프가 존재함이 지적됩니다 [4, 7].
-
----
-*Last updated: 2026-04-19*
-- Raw Source: [[00_Raw/2026-04-20/Pointer Poisoning.md]]
----
diff --git a/Programming & Language/Post-Apocalyptic Fiction.md b/Programming & Language/Post-Apocalyptic Fiction.md
deleted file mode 100644
index 744780a8..00000000
--- a/Programming & Language/Post-Apocalyptic Fiction.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-593061
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Post-Apocalyptic Fiction"
----
-
-# [[Post-Apocalyptic Fiction]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Post-Apocalyptic Fiction.md]]
----
diff --git a/Programming & Language/Post-Surgical-Orthopedic-Recovery.md b/Programming & Language/Post-Surgical-Orthopedic-Recovery.md
deleted file mode 100644
index 6ca21e76..00000000
--- a/Programming & Language/Post-Surgical-Orthopedic-Recovery.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-161900
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Post-Surgical-Orthopedic-Recovery"
----
-
-# [[Post-Surgical-Orthopedic-Recovery]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Post-Surgical-Orthopedic-Recovery.md]]
----
diff --git a/Programming & Language/Prettier.md b/Programming & Language/Prettier.md
deleted file mode 100644
index 3160a7ab..00000000
--- a/Programming & Language/Prettier.md	
+++ /dev/null
@@ -1,39 +0,0 @@
----
-id: P-REINFORCE-AUTO-560F29
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Prettier"
----
-
-# [[Prettier]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> Prettier는 개발자가 작성한 소스 코드를 일관된 스타일로 자동 변환해 주는 '의견이 반영된(opinionated)' 코드 포맷터(Formatter)입니다 [1, 2]. 코드의 로직이나 구현 방식에는 관여하지 않고, 줄 바꿈, 공백, 들여쓰기 등 시각적이고 구조적인 뷰에만 초점을 맞추어 코드를 재작성합니다 [2-4]. 이를 통해 팀원 간의 코딩 컨벤션을 통일하여 코드 리뷰 시 불필요한 스타일 논쟁을 없애고, 개발자가 코드의 핵심 로직에 더욱 집중할 수 있도록 돕습니다 [5, 6].
-
-## 📖 구조화된 지식 (Synthesized Content)
-* **주요 역할 및 특징:**
-  2016년에 등장한 Prettier는 코드가 예쁘게 보이도록 만드는 데 중점을 둔 도구로, 변경이 필요한 부분만 수정하는 것이 아니라 설정된 규칙에 따라 코드 전체의 구조적 뷰를 완전히 새로 작성합니다 [2, 4]. 
-* **팀 협업 및 생산성 향상:**
-  Prettier를 도입하면 개발자가 코드를 작성할 때 스타일에 대한 고민을 덜 수 있고, 저장 시 자동으로 일관된 포맷으로 변환됩니다 [6]. 이는 팀원 간 코드 스타일 차이로 인한 혼란을 최소화하고, 리뷰 과정의 효율성을 크게 증가시킵니다 [6].
-* **설정 및 관리 방법:**
-  일반적으로 프로젝트 루트 경로에 `.prettierrc` (또는 `.prettierrc.json`) 파일을 생성하여 규칙을 정의하며, 포맷팅에서 제외할 파일은 `.prettierignore`에 지정합니다 [5, 7, 8]. 주요 설정 옵션으로는 한 줄의 최대 길이를 정하는 `printWidth`, 탭 너비를 정하는 `tabWidth`, 세미콜론 사용 여부를 정하는 `semi`, 작은따옴표 사용을 결정하는 `singleQuote` 등이 있습니다 [9, 10].
-* **ESLint와의 통합 및 충돌 방지:**
-  코드 퀄리티를 검사하는 Linter 도구인 ESLint에도 일부 포맷팅 기능이 존재하여, Prettier와 함께 사용할 경우 규칙 충돌이 발생할 수 있습니다 [11]. 이를 해결하기 위해 `eslint-config-prettier` 패키지를 사용하여 Prettier와 겹치는 ESLint의 포맷팅 규칙을 끄는 방법이 가장 강력히 권장됩니다 [11, 12]. 추가로 `eslint-plugin-prettier`를 설치하여 Prettier의 포맷팅 오류를 ESLint의 오류로 통합 출력하게 만들 수도 있습니다 [11, 13].
-* **보안 취약점 (공급망 공격) 사례:**
-  2025년 7월, Prettier와 ESLint의 충돌을 방지하는 필수 라이브러리인 `eslint-config-prettier` 패키지가 공급망 공격(CVE-2025-54313)의 표적이 되었습니다 [14, 15]. 관리자의 탈취된 npm 토큰을 통해 악성 버전이 배포되었으며, 이는 주로 Windows 시스템의 개발자 기기나 CI 호스트에서 원격 코드 실행(RCE)을 시도하도록 설계된 악성 설치 스크립트를 포함하고 있었습니다 [16].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[ESLint]], [[Formatter]]
-- **Projects/Contexts:** [[eslint-config-prettier]], [[eslint-plugin-prettier]], [[husky]], [[lint-staged]]
-- **Contradictions/Notes:** ESLint와 Prettier를 통합할 때 사용하는 `eslint-plugin-prettier`에 대해 의견이 갈립니다. 소스 [17]는 해당 플러그인을 사용하면 하나의 설정 파일에서 관리할 수 있고 자동 수정(`--fix`)이 편리하여 선호한다고 밝히지만, 소스 [18]에서는 에디터에 불필요한 빨간 밑줄이 과도하게 생기고 단독 사용보다 속도가 느려진다는 이유로 공식 문서에서도 권장하지 않는다며 플러그인 사용을 배제하는 방식을 채택합니다.
-
----
-*Last updated: 2026-04-18*
-- Raw Source: [[00_Raw/2026-04-20/Prettier.md]]
----
diff --git a/Programming & Language/Procedural-Rhetoric.md b/Programming & Language/Procedural-Rhetoric.md
deleted file mode 100644
index dd2a419d..00000000
--- a/Programming & Language/Procedural-Rhetoric.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-4B887E
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Procedural-Rhetoric"
----
-
-# [[Procedural-Rhetoric]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Procedural-Rhetoric.md]]
----
diff --git a/Programming & Language/Proprioception.md b/Programming & Language/Proprioception.md
deleted file mode 100644
index e72c8e20..00000000
--- a/Programming & Language/Proprioception.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-B85544
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Proprioception"
----
-
-# [[Proprioception]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Proprioception.md]]
----
diff --git a/Programming & Language/RDF-star (RDF 확장 사양).md b/Programming & Language/RDF-star (RDF 확장 사양).md
deleted file mode 100644
index c67fdfcb..00000000
--- a/Programming & Language/RDF-star (RDF 확장 사양).md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-E70DB9
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - RDF-star (RDF 확장 사양)"
----
-
-# [[RDF-star (RDF 확장 사양)]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/RDF-star (RDF 확장 사양).md]]
----
diff --git a/Programming & Language/RRF (Reciprocal Rank Fusion).md b/Programming & Language/RRF (Reciprocal Rank Fusion).md
deleted file mode 100644
index a4d0492c..00000000
--- a/Programming & Language/RRF (Reciprocal Rank Fusion).md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-6A4FE8
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - RRF (Reciprocal Rank Fusion)"
----
-
-# [[RRF (Reciprocal Rank Fusion)]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/RRF (Reciprocal Rank Fusion).md]]
----
diff --git a/Programming & Language/Reachability Analysis.md b/Programming & Language/Reachability Analysis.md
deleted file mode 100644
index db3d9fdf..00000000
--- a/Programming & Language/Reachability Analysis.md	
+++ /dev/null
@@ -1,36 +0,0 @@
----
-id: P-REINFORCE-AUTO-5449D4
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Reachability Analysis"
----
-
-# [[Reachability Analysis]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 도달 가능성 분석(Reachability Analysis)은 소스 코드 및 오픈 소스 종속성 분석에 사용되는 보안 테스트 기법으로, 오염된 데이터가 민감한 싱크(sink)에 도달할 수 있는지 또는 특정 취약점이 실제 프로덕션 환경이나 실행 경로에서 호출 가능한지를 추적하는 방법입니다 [1, 2]. 콜 그래프(call graph)와 데이터 흐름 분석을 통해 취약한 함수로의 연결 고리를 식별하며, 도달할 수 없는 데드 코드(dead code)를 필터링합니다 [3, 4]. 결과적으로 노이즈와 오탐(false positives)을 줄여 개발자 및 보안팀이 실제 위협에 집중할 수 있도록 돕는 핵심 기술입니다 [4, 5].
-
-## 📖 구조화된 지식 (Synthesized Content)
-* **작동 원리:** 도달 가능성 분석은 애플리케이션의 엔드포인트를 리졸브하고 취약한 함수로 이어지는 콜 그래프를 생성하여, 해당 코드 영역이 실제로 실행 가능한지를 판별합니다 [3]. 이를 통해 퍼스트 파티(first-party) 코드뿐만 아니라 서드 파티(third-party) 코드에 존재하는 취약점이 실제 실행 경로(execution paths)와 연결되어 있는지를 함수 수준(function-level)의 세분화된 단위로 추적할 수 있습니다 [2, 5].
-* **보안 점검 및 문제 해결의 우선순위 지정:** 이 기법의 가장 큰 이점은 개발자의 알림 피로도(alert fatigue)를 줄이는 데 있습니다 [5]. 실제 런타임 조건에서 도달할 수 없는 데드 경로나 실행되지 않는 모듈에 위치한 취약점을 제외(필터링)시킴으로써, 심각성, 익스플로잇 가능성(exploitability), 비즈니스 영향도 등을 고려한 맥락 인식 기반의 우선순위 분류가 가능해집니다 [4, 6]. 
-* **주요 보안 분석 도구에서의 활용 사례:**
-  * **Endor Labs:** 퍼스트 파티 및 서드 파티 코드 전반에 걸친 함수 수준의 도달 가능성 분석을 적용하여, 취약점이 외부의 신뢰할 수 없는 입력에 노출되는지 판단하고 SCA(Software Composition Analysis)와 SAST(Static Application Security Testing) 결과를 통합합니다 [2, 5].
-  * **Veracode:** 데이터 흐름을 추적하여 오염된(tainted) 데이터가 민감한 싱크(sink)에 도달할 수 있는지를 도달 가능성 분석을 통해 확인합니다 [1].
-  * **Corgea:** SAST 스캔 과정에서 엔드포인트를 식별하고 취약한 함수에 대한 콜 그래프를 생성하여 도달 여부를 시각화합니다 [3].
-  * **Qwiet AI:** CPG(Code Property Graph) 분석과 함께 도달 가능성 기반의 필터링을 사용하여, 스캔 속도를 최적화하고 분류해야 할 보안 경고 수를 효과적으로 줄입니다 [7, 8].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[SAST (Static Application Security Testing)]], [[SCA (Software Composition Analysis)]], [[Call Graph]], [[Data Flow Analysis]], [[False Positives]], [[Vulnerability Prioritization]]
-- **Projects/Contexts:** [[Endor Labs]], [[Veracode]], [[Corgea]], [[Qwiet AI]]
-- **Contradictions/Notes:** 제공된 소스 내에서 도달 가능성 분석의 효용성에 대한 모순점은 없으며, 모든 자료가 공통적으로 SAST 및 SCA 도구에서 오탐을 줄이고 실제 위험을 식별하는 데 매우 효과적이고 필수적인 접근법이라고 동의하고 있습니다 [2, 4].
-
----
-*Last updated: 2026-04-19*
-- Raw Source: [[00_Raw/2026-04-20/Reachability Analysis.md]]
----
diff --git a/Programming & Language/React 19 Compiler.md b/Programming & Language/React 19 Compiler.md
deleted file mode 100644
index c75869ec..00000000
--- a/Programming & Language/React 19 Compiler.md	
+++ /dev/null
@@ -1,36 +0,0 @@
----
-id: P-REINFORCE-AUTO-A2E200
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - React 19 Compiler"
----
-
-# [[React 19 Compiler]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> **React 19 컴파일러(React Compiler)**는 빌드 타임에 코드를 분석하여 컴포넌트, 값, 콜백 함수에 자동으로 메모이제이션(`useMemo`, `useCallback` 등)을 적용하는 최적화 도구입니다. 수동 최적화에 필요한 보일러플레이트 코드를 대폭 줄이면서도 애플리케이션의 전반적인 렌더링 성능을 향상시킵니다.
-
-## 📖 구조화된 지식 (Synthesized Content)
-**1. 자동 메모이제이션의 작동 원리** 과거에는 불필요한 리렌더링을 막기 위해 개발자가 직접 `useMemo`나 `useCallback`으로 무거운 연산이나 함수를 감싸주어야 했습니다. 하지만 React 19 컴파일러는 안전하다고 판단되는 모든 곳에 이러한 최적화 기법을 자동으로 적용하여, 매 렌더링마다 함수나 값이 불필요하게 재생성되는 것을 막아줍니다.
-
-**2. 높은 최적화 커버리지** 이 컴파일러는 **순수 함수형 컴포넌트(Pure functional components)에서 가장 강력하게 동작**합니다.
-
-- **콜백 안정화(Callback stabilization):** 95% 이상 커버리지를 보이며 불필요한 프롭스(Props) 변경을 막아줍니다.
-- **컴포넌트 및 값 메모이제이션:** 컴포넌트의 90% 이상, 연산 값의 85% 이상을 자동으로 캐싱하여 렌더링 소요 시간과 연산 시간을 크게 단축합니다. 이 덕분에 리스트 렌더링 등에서도 획기적인 속도 향상이 일어납니다.
-
-**3. 컴파일러의 한계와 수동 최적화 필요성** 모든 코드를 완벽하게 최적화할 수는 없습니다. 비동기 작업(Async operations)은 컴파일러의 자동 최적화 대상에서 제외됩니다. 또한, **비결정론적(Non-deterministic) 동작에 의존하는 부수 효과(Side effects), 참조(Ref)의 혼용, 외부 의존성, 또는 직접적인 DOM 조작이 포함된 경우 컴파일러가 이를 최적화할 수 없으므로 개발자의 수동 개입이 필요**합니다.
-
-**4. 개발 패러다임과 아키텍처의 변화** React 19 컴파일러는 시니어와 주니어 개발자 간의 성능 최적화 전문성 격차를 줄여줍니다. 일반적인 코드만 작성해도 기본적으로 우수한 성능이 보장되기 때문에, 숙련된 개발자들은 미세한 메모이제이션(Micro-optimizations)에 시간을 쏟는 대신 애플리케이션의 전체적인 아키텍처 설계에 더욱 집중할 수 있게 됩니다. 더 나아가, 참조 안정성이 자동으로 확보됨에 따라 WebGL이나 ECS 기반의 고성능 게임 엔진 생태계 등에서도 런타임 오버헤드를 줄이는 데 크게 기여할 것으로 기대됩니다.
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[React Performance Optimization]], [[useMemo & useCallback]], [[불필요한 리렌더링 방지]], [[재조정 (Reconciliation)]]
-- **Projects/Contexts:** [[대규모 React 프론트엔드 최적화 및 리팩토링]], [[고성능 실시간 상호작용 엔진 구축]]
-- **Contradictions/Notes:** 새로운 컴파일러가 메모이제이션을 마법처럼 자동화해주지만, **비효율적인 데이터 패칭이나 잘못 설계된 거대한 컴포넌트 트리, 무분별한 전역 상태 관리와 같은 근본적인 아키텍처 결함까지 해결해 주지는 못합니다**. 올바른 성능 최적화를 위해서는 컴파일러에만 의존하지 않고 훌륭한 소프트웨어 설계 원칙을 계속 유지해야 합니다.
-- Raw Source: [[00_Raw/2026-04-20/React 19 Compiler.md]]
----
diff --git a/Programming & Language/React 게임 엔진 아키텍처.md b/Programming & Language/React 게임 엔진 아키텍처.md
deleted file mode 100644
index 6d5d172c..00000000
--- a/Programming & Language/React 게임 엔진 아키텍처.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-D1ED6C
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - React 게임 엔진 아키텍처"
----
-
-# [[React 게임 엔진 아키텍처]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/React 게임 엔진 아키텍처.md]]
----
diff --git a/Programming & Language/React 및 Nextjs 개발 환경.md b/Programming & Language/React 및 Nextjs 개발 환경.md
deleted file mode 100644
index b7193459..00000000
--- a/Programming & Language/React 및 Nextjs 개발 환경.md	
+++ /dev/null
@@ -1,39 +0,0 @@
----
-id: P-REINFORCE-AUTO-2C5A84
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - React 및 Nextjs 개발 환경"
----
-
-# [[React 및 Nextjs 개발 환경]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> React 및 Next.js 개발 환경은 코드의 일관성과 품질을 유지하기 위해 정적 분석 도구와 포맷터를 적극적으로 활용하는 생태계이다 [1, 2]. 주로 ESLint를 통해 React 및 Next.js 특화 문법과 구조적 오류를 검사하고, Prettier를 통해 코드 스타일을 통일한다 [3, 4]. 대규모 프로젝트에서는 Turborepo와 같은 모노레포 도구와 Husky, lint-staged를 결합하여 개발 생산성을 높이고 효율적인 린팅 파이프라인을 구축한다 [5-7].
-
-## 📖 구조화된 지식 (Synthesized Content)
-* **React 및 Next.js 특화 ESLint 설정:** 
-  React 컴포넌트 개발을 위해서는 컴포넌트 생명주기와 훅(Hooks) 규칙, JSX 접근성 검사를 지원하는 `eslint-plugin-react`, `eslint-plugin-react-hooks`, `eslint-plugin-jsx-a11y` 등의 전용 플러그인 설치가 필요하다 [8-10]. Next.js 프로젝트의 경우 `eslint-config-next` 플러그인을 사용하여 코어 웹 바이탈(core web vitals) 및 서버 컴포넌트 패턴과 같은 프레임워크 특화 규칙을 손쉽게 적용할 수 있다 [4, 11]. 
-* **JSX 변환(Transform) 규칙 처리:** 
-  최신 JSX 변환을 지원하는 개발 환경에서는 파일 내에 React 객체를 직접 import하지 않아도 되므로, ESLint에서 발생하는 `'React' must be in scope when using JSX` 에러를 방지하기 위해 `'react/react-in-jsx-scope': 'off'` 규칙을 추가로 설정하여 불필요한 경고를 없앨 수 있다 [4, 12, 13].
-* **포맷터(Prettier)와의 충돌 제어:** 
-  ESLint의 스타일 규칙과 Prettier의 포맷팅 규칙이 충돌하는 것을 방지하기 위해 `eslint-config-prettier` 패키지를 도입하여 포맷팅과 중복되거나 충돌하는 ESLint 측의 규칙들을 비활성화해야 한다 [14-16].
-* **모노레포(Turborepo) 환경에서의 구성:** 
-  여러 개의 Next.js 애플리케이션과 공유 라이브러리가 공존하는 Turborepo 모노레포 환경에서는 구성 파일의 무분별한 중복을 막기 위해 중앙 집중식 ESLint 설정 패키지(예: `@repo/eslint-config`)를 구축하는 것이 매우 효과적이다 [5, 17]. Base, Next.js, Library용 프리셋을 모듈화하여 구성하고, 루트 레벨의 오케스트레이션(orchestration) 설정을 통해 파일 패턴별로 각 패키지에 맞는 적절한 규칙이 적용되도록 제어한다 [4, 17, 18].
-* **Git Hooks를 통한 자동화 (Husky & lint-staged):** 
-  코드 저장소에 푸시되거나 커밋되기 전에 React 및 Next.js 코드 컨벤션이 강제되도록 `Husky`를 활용하여 Git 훅(pre-commit 등)을 설정한다 [19-21]. 여기에 `lint-staged`를 결합하면 변경되어 스테이징된 파일들에만 한정하여 ESLint와 Prettier를 실행하므로, 방대한 코드베이스에서도 1~2초 만에 검사를 완료하여 개발 흐름의 지연을 막을 수 있다 [6, 22].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[ESLint]], [[Prettier]], [[Turborepo]], [[Husky 및 lint-staged]]
-- **Projects/Contexts:** [[Next.js 애플리케이션 및 모노레포 구축]], [[React 컴포넌트 개발 환경]]
-- **Contradictions/Notes:** ESLint와 Prettier를 함께 사용할 때 `eslint-plugin-prettier`를 사용하여 Prettier 규칙을 ESLint 내에서 실행하는 방식이 존재하나, 에디터상에 오류 밑줄이 과도하게 표시되거나 단독 실행보다 처리 속도가 느려지는 단점이 있어 Prettier 공식 문서 및 일부 실무 환경에서는 이를 지양하고 `eslint-config-prettier`만 적용할 것을 권장하기도 한다 [12, 23].
-
----
-*Last updated: 2026-04-19*
-- Raw Source: [[00_Raw/2026-04-20/React 및 Next.js 개발 환경.md]]
----
diff --git a/Programming & Language/React 재조정 (Reconciliation) 최적화.md b/Programming & Language/React 재조정 (Reconciliation) 최적화.md
deleted file mode 100644
index 516c711c..00000000
--- a/Programming & Language/React 재조정 (Reconciliation) 최적화.md	
+++ /dev/null
@@ -1,51 +0,0 @@
----
-id: P-REINFORCE-AUTO-E6A358
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - React 재조정 (Reconciliation) 최적화"
----
-
-# [[React 재조정 (Reconciliation) 최적화]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> React 재조정(Reconciliation) 최적화는 React가 가상 DOM 트리를 비교(Diffing)하여 실제 DOM에 적용할 최소한의 변경 사항을 계산하는 과정에서 발생하는 CPU 오버헤드와 불필요한 렌더링을 줄여 애플리케이션의 성능과 반응성을 극대화하는 아키텍처 및 코딩 기법입니다.
-
-## 📖 구조화된 지식 (Synthesized Content)
-**1. 재조정의 핵심 규칙 이해와 준수** React의 재조정 알고리즘을 최적화하려면 프레임워크가 트리를 비교하는 3가지 핵심 규칙을 이해하고 이에 맞춰 컴포넌트를 설계해야 합니다.
-
-- **요소 타입 유지:** 부모 노드의 타입이 달라지면(예: `div`에서 `span`으로 변경) React는 이전 하위 트리를 완전히 파괴하고 처음부터 다시 구축합니다. 따라서 조건부 렌더링 시 가급적 동일한 요소 타입과 위치를 유지하여 하위 컴포넌트의 인스턴스와 상태가 파괴되지 않도록 해야 합니다.
-- **안정적이고 고유한 Key 사용:** 리스트 렌더링 시 `key`를 부여하지 않거나 배열의 인덱스를 사용하면 항목의 순서가 바뀔 때 React가 전체 리스트를 불필요하게 재생성하게 됩니다. 안정적인 데이터 ID를 `key`로 사용하여 React가 동일한 항목을 식별하고 렌더링을 건너뛸 수 있게 해야 합니다.
-
-**2. 렌더링 트리 분리 및 상태의 하향 배치 (Lifting State Down)** 부모 컴포넌트의 상태가 변하면 기본적으로 모든 하위 컴포넌트가 재조정 과정을 거칩니다.
-
-- **상태 고립화:** 입력 폼의 타이핑이나 마우스 좌표 추적처럼 고빈도로 변하는 상태는 해당 상태를 직접 사용하는 가장 하위의 자식 컴포넌트로 내려보내야(Lifting State Down) 합니다.
-- **컨텍스트(Context) 분할:** 전역 Context의 값이 하나라도 변하면 이를 구독하는 모든 컴포넌트가 리렌더링됩니다. 따라서 변경 빈도가 높은 상태와 낮은 상태를 별도의 Context로 분할하여 구독 범위를 좁혀야 합니다.
-
-**3. 참조 안정성(Reference Stability) 확보를 통한 메모이제이션** `React.memo`는 컴포넌트의 프롭스(Props)가 변경되지 않았을 때 재조정을 건너뛰게 해줍니다. 하지만 다음과 같은 패턴은 이 최적화를 무력화합니다.
-
-- **인라인 객체 및 함수 지양:** 렌더링 함수 내부에서 `{ borderRadius: '50%' }`와 같은 인라인 객체를 생성하거나 `() => handleClick()`과 같은 익명 함수를 넘기면 매 렌더링마다 새로운 메모리 참조(Reference)가 생성됩니다.
-- 부모에서 자식으로 콜백이나 파생 객체를 전달할 때는 **`useCallback`과 `useMemo`를 사용하여 참조를 고정(Memoize)**해야 자식 컴포넌트의 `React.memo`가 정상적으로 작동하여 재조정을 방지할 수 있습니다.
-
-**4. 대규모 리스트 가상화 (Virtualization)** 항목이 수백 개 이상인 리스트의 경우 재조정 자체의 비용이 기하급수적으로 증가하여 브라우저가 버벅거립니다. 화면(Viewport)에 보이는 항목만 렌더링하고 스크롤 시 DOM 노드를 동적으로 교체하는 `react-window` 등의 가상화 라이브러리를 사용해 재조정할 노드의 절대적인 수 자체를 줄여야 합니다.
-
-**5. 한계 극복: 명령형 조작을 통한 재조정 우회 (Bypass)** 실시간 애니메이션이나 초당 60프레임(FPS)을 보장해야 하는 게임 환경에서 허용된 렌더링 시간은 약 16.67ms에 불과합니다.
-
-- React의 가상 DOM 디핑 알고리즘(O(n) 복잡도)은 이러한 고빈도 업데이트를 처리하기에는 구조적으로 무겁습니다.
-- 따라서 무거운 애니메이션, 파티클 시스템, 물리 엔진 등은 React의 선언적 렌더링 시스템을 통하지 않고, 참조(`useRef`)를 직접 조작하거나 React Native의 `setNativeProps`를 활용해 **명령형(Imperative)으로 DOM 및 WebGL 인스턴스를 직접 업데이트하여 재조정 오버헤드를 완전히 우회**해야 합니다.
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[가상 DOM (Virtual DOM)]], [[React 19 Compiler]], [[불필요한 리렌더링 방지]], [[명령형 직접 조작 (Imperative Manipulation)]]
-- **Projects/Contexts:** [[고성능 실시간 상호작용 시스템을 위한 React 기반 게임 엔진 아키텍처]], [[대규모 데이터 렌더링 및 가상화 최적화]]
-- **Contradictions/Notes:** React 19의 컴파일러가 도입되면서 `useMemo`나 `useCallback`과 같은 수동 참조 안정화 작업의 대부분을 빌드 타임에 자동으로 처리해 줍니다. 하지만 이는 구조적으로 순수한 컴포넌트에서만 완벽히 동작하며, 거대한 컴포넌트 트리, 불안정한 Key 배열, 과도한 Context 사용과 같은 잘못된 아키텍처 설계 자체를 고쳐주지는 못하므로 여전히 개발자의 구조 최적화 역량이 중요합니다.
-
----
-
-_Last updated: 2026-04-15_
-- Raw Source: [[00_Raw/2026-04-20/React 재조정 (Reconciliation) 최적화.md]]
----
diff --git a/Programming & Language/React 컴포넌트 Props 전달 및 상태 관리.md b/Programming & Language/React 컴포넌트 Props 전달 및 상태 관리.md
deleted file mode 100644
index 4e893e5d..00000000
--- a/Programming & Language/React 컴포넌트 Props 전달 및 상태 관리.md	
+++ /dev/null
@@ -1,43 +0,0 @@
----
-id: P-REINFORCE-AUTO-F29466
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - React 컴포넌트 Props 전달 및 상태 관리"
----
-
-# [[React 컴포넌트 Props 전달 및 상태 관리]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> React 컴포넌트의 Props 전달과 상태 관리는 애플리케이션의 동작을 제어하고 컴포넌트 간 데이터를 교환하는 핵심 메커니즘입니다 [1, 2]. 올바른 Props 설계는 초과 속성으로 인한 불필요한 리렌더링과 런타임 경고를 방지하며, 효과적인 상태 관리는 유효하지 않은 상태를 원천 차단하여 예측 불가능한 동작이나 버그를 예방합니다 [3, 4]. TypeScript의 식별 가능한 유니언(Discriminated Unions)과 초과 속성 검사(Excess Property Checking) 같은 기능을 활용하면 타입 안전성이 보장된 견고한 React 애플리케이션을 구축할 수 있습니다 [1, 4-6].
-
-## 📖 구조화된 지식 (Synthesized Content)
-*   **Props 전달과 타입 안전성 (Props Passing and Type Safety)**
-    *   React 컴포넌트의 기본적인 `props` 타입을 정의할 때는 `interface`나 `type` 중 어느 것을 사용해도 무방합니다 [7, 8].
-    *   Props로 전달되는 객체에 대한 초과 속성 검사(Excess Property Checking)는 매우 중요합니다 [4]. 만약 오타가 난 prop과 같은 유효하지 않은 초과 속성이 DOM에 전달되면 React가 경고를 발생시킬 수 있으며, 의도치 않게 컴포넌트의 Props를 무효화하여 불필요한 리렌더링을 유발할 수 있습니다 [4].
-    *   명시적인 판별자(Discriminant) 프로퍼티 없이도 `never` 타입과 유니언 타입을 조합해 상호 배타적인(Exclusive) Props를 구성할 수 있습니다 [9]. 이를 통해 텍스트 필드 컴포넌트에 `options`를 전달하거나 select 필드에 `placeholder`를 전달하는 등 호환되지 않는 Props의 혼합 사용을 컴파일 타임에 방지할 수 있습니다 [9]. 또한 버튼이 일반 버튼인지 링크인지에 따라 Props를 안전하게 분기할 수도 있습니다 [10].
-
-*   **상태 관리와 식별 가능한 유니언 (State Management and Discriminated Unions)**
-    *   식별 가능한 유니언(Discriminated Unions)은 React 상태 관리에서 유효하지 않은 상태를 표현 불가능하게 만드는 "비밀 무기"로 작용합니다 [1, 5, 6].
-    *   폼 제출 워크플로우(validating, validation-error, submitting, success, error)나 다단계 마법사(Wizard) 폼 같은 복잡한 비동기 UI 상태를 명확히 모델링하고 모든 경우의 수를 처리(Exhaustive checking)하도록 강제할 수 있습니다 [5, 11, 12].
-    *   Redux 스타일의 Reducer 기능이나 라우터 상태 관리에서도 식별 가능한 유니언을 통해 각 액션과 상태의 조합을 완벽히 매칭할 수 있으며, 복잡한 상태의 경우 식별 가능한 유니언을 중첩하여 관리하기도 합니다 [11].
-    *   외부 데이터(API 등)나 설정 파일에서 Props나 상태를 받을 때는 TypeScript가 컴파일 타임에만 작동하므로, Zod와 같은 런타임 검증 라이브러리와 식별 가능한 유니언을 결합하면 더욱 안전한 비동기 상태 관리가 가능합니다 [6, 10].
-
-*   **상태 관리 부실의 위험성 (Risks of Mismanaged State)**
-    *   명확한 패턴 없이 여러 곳에서 상태를 수정하게 되면 애플리케이션의 동작이 예측 불가능해지고, 버그의 근본 원인을 파악하기 매우 어려워집니다 [3].
-    *   잘못된 상태 관리는 중복되거나 오래된(stale) 상태를 만들고 사이드 이펙트를 유발하여 기술 부채를 축적시킵니다 [3]. 이는 결국 불필요한 리렌더링, 메모리 누수, 불필요한 네트워크 요청 등 심각한 성능 문제로 이어집니다 [3].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[Discriminated Unions]], [[Excess Property Checking]], [[Runtime Validation (Zod)]]
-- **Projects/Contexts:** [[Redux-style Reducers]], [[React Component Library]]
-- **Contradictions/Notes:** React props 타입 정의 시 기본적인 사용에 있어 `interface`와 `type` 간의 실질적 큰 차이는 없으나, TypeScript는 캐싱과 성능 최적화 측면에서 교집합(&)보다는 `interface extends`의 사용을 권장합니다 [7, 8, 13].
-
----
-*Last updated: 2026-04-18*
-- Raw Source: [[00_Raw/2026-04-20/React 컴포넌트 Props 전달 및 상태 관리.md]]
----
diff --git a/Programming & Language/Readonly Type.md b/Programming & Language/Readonly Type.md
deleted file mode 100644
index b386e75f..00000000
--- a/Programming & Language/Readonly Type.md	
+++ /dev/null
@@ -1,39 +0,0 @@
----
-id: P-REINFORCE-AUTO-EDA6A3
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Readonly Type"
----
-
-# [[Readonly Type]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> TypeScript의 `Readonly Type` (또는 `readonly` 수식어)은 객체의 속성, 배열 등이 초기화된 이후 수정되는 것을 방지하여 타입 수준에서 불변성(Immutability)을 강제하는 기능입니다[1, 2]. 이는 런타임 오버헤드 없이 컴파일 타임에 예기치 않은 데이터의 변이를 차단하며, 변수의 재할당을 막는 `const`나 런타임 동작인 `Object.freeze()`와 구별됩니다[3-5]. 주로 설정 객체, API 응답, 상태 관리 등 변경되지 않아야 하는 데이터 구조를 보호하는 데 사용됩니다[6, 7].
-
-## 📖 구조화된 지식 (Synthesized Content)
-* **작동 방식 및 컴파일 타임 보호:** 
-  `readonly`는 객체의 속성이나 클래스, 인터페이스에 적용되어 할당 후 변경(mutate) 시도를 할 때 컴파일러 수준에서 에러를 발생시킵니다[3, 8]. 이 기능은 오직 컴파일 시점에만 존재하며, 자바스크립트로 변환된 이후에는 제거되므로 성능 저하나 런타임 오버헤드를 발생시키지 않습니다[3, 5, 9].
-* **`Readonly<T>` 유틸리티 타입:** 
-  TypeScript는 기존 객체 타입의 모든 속성을 읽기 전용으로 변환해 주는 `Readonly<T>` 내장 유틸리티 타입을 제공합니다[2, 10]. 만약 `readonly` 속성을 다시 가변(mutable) 상태로 되돌리고 싶다면, 매핑된 타입(Mapped Type) 구문에서 `-readonly` 제어자를 사용하여 속성을 제거할 수 있습니다[11].
-* **배열과 튜플의 불변성:** 
-  배열이나 튜플에 `readonly` 제어자를 붙이거나 `ReadonlyArray<T>`를 사용하면, 배열을 변이시키는 `push`, `pop`과 같은 메서드가 타입 시그니처에서 제거되어 원천적으로 사용이 차단됩니다[12, 13]. 단, `map`이나 `filter` 같이 원본을 수정하지 않고 새로운 배열을 반환하는 메서드는 그대로 사용할 수 있습니다[12].
-* **얕은 불변성(Shallow Immutability)의 한계:** 
-  기본적인 `readonly` 제어자와 `Readonly<T>` 타입은 최상위 속성에만 적용되는 얕은(shallow) 수준의 보호만 제공하여 중첩된 객체 내부는 여전히 변경될 수 있습니다[4, 5, 14]. 이를 해결하기 위해 매핑 타입과 조건부 타입을 결합하여 재귀적으로 속성을 동결하는 `DeepReadonly<T>` 커스텀 타입을 직접 정의하여 사용해야 합니다[4, 14, 15].
-* **별칭(Aliasing)으로 인한 취약점:** 
-  `readonly` 타입의 데이터를 가변(mutable) 매개변수를 기대하는 함수에 전달할 경우, TypeScript는 타입 호환성 규칙에 의해 이를 허용합니다[16]. 이로 인해 `readonly`로 선언된 데이터라 하더라도 우회적인 경로(Alias)를 통해 값이 수정될 수 있는 한계(Gotcha)가 존재하므로 함수 시그니처 설계 시 주의가 필요합니다[16-18].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[Immutability]], [[Utility Types]], [[DeepReadonly]], [[Object.freeze()]], [[Mapped Types]]
-- **Projects/Contexts:** [[Functional Programming]], [[State Management]]
-- **Contradictions/Notes:** 자바스크립트의 `const`는 변수 자체의 재할당을 막고 객체 내부 속성의 변경은 허용하지만, TypeScript의 `readonly`는 객체 내부 속성의 변경을 막습니다[4, 19]. 또한 `Object.freeze()`는 런타임에 얕은 동결을 수행하지만, `readonly`는 런타임 성능 비용 없이 컴파일 타임에만 엄격하게 검사한다는 차이가 있습니다[5, 20, 21]. 
-
----
-*Last updated: 2026-04-18*
-- Raw Source: [[00_Raw/2026-04-20/Readonly Type.md]]
----
diff --git a/Programming & Language/Readonly 유틸리티 타입.md b/Programming & Language/Readonly 유틸리티 타입.md
deleted file mode 100644
index c358217b..00000000
--- a/Programming & Language/Readonly 유틸리티 타입.md	
+++ /dev/null
@@ -1,42 +0,0 @@
----
-id: P-REINFORCE-AUTO-33C0BF
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Readonly 유틸리티 타입"
----
-
-# [[Readonly 유틸리티 타입]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> Readonly 유틸리티 타입(`Readonly<T>`)은 TypeScript에서 특정 객체 타입의 모든 속성에 `readonly` 수식어를 추가하여 초기화 이후 값을 재할당할 수 없도록 변환하는 기능입니다[1, 2]. 이는 런타임 성능 저하 없이 컴파일 타임에만 엄격하게 불변성을 강제하여, 의도치 않은 데이터 변형으로 인한 버그를 사전에 차단합니다[3, 4]. 단, 최상위 속성에만 적용되는 얕은(shallow) 불변성만을 제공하므로, 중첩된 객체를 완전히 동결하려면 재귀적인 형태의 딥 리드온리(Deep Readonly) 패턴이 별도로 필요합니다[5, 6].
-
-## 📖 구조화된 지식 (Synthesized Content)
-- **기본 작동 원리와 문법:** 
-  `Readonly<T>`는 주어진 타입 `T`의 모든 프로퍼티를 읽기 전용으로 매핑합니다[1, 2]. 설정이나 API 응답, 상태 관리 리듀서 등 앱 내내 값이 유지되어야 하는 객체를 보호할 때 주로 사용됩니다[7, 8]. TypeScript 코드가 컴파일된 후에는 관련 어노테이션이 모두 사라지므로 실행 시점(Runtime)에는 어떠한 오버헤드도 발생시키지 않습니다[3, 9].
-
-- **유사 개념과의 차이점:**
-  - **`const`와의 차이:** `const`는 변수 자체의 재할당을 막지만 참조된 객체의 내부 속성 변경은 막지 못합니다. 반면 `readonly`는 변수 바인딩이 아닌 객체 속성이나 배열 요소 자체의 변경을 제한합니다[10, 11].
-  - **`Object.freeze()`와의 차이:** `Object.freeze()`는 런타임에 객체를 동결하며 실행 성능에 비용을 청구하지만, `readonly`는 컴파일 타임에 타입 시스템을 통해서만 수정을 금지합니다[4, 12].
-
-- **배열에서의 활용:**
-  객체뿐만 아니라 배열에도 `ReadonlyArray<T>` 또는 `readonly T[]` 형태로 사용할 수 있습니다[13, 14]. 이렇게 선언된 배열은 요소의 재할당이 불가능할 뿐만 아니라, `push()`, `pop()` 등 원본을 수정하는 메서드가 타입 정의에서 완전히 제거됩니다[15, 16].
-
-- **한계점 및 우회 취약점 (Gotcha):**
-  - **얕은 불변성(Shallow Immutability):** `Readonly<T>`는 1단계 깊이의 속성에만 작용합니다. 객체 내부의 중첩된 객체 속성은 여전히 수정이 가능하며, 이를 해결하기 위해서는 매핑된 타입과 조건부 타입을 결합한 커스텀 `DeepReadonly<T>` 유틸리티를 구현해야 합니다[5, 6, 17].
-  - **에일리어싱(Aliasing) 문제:** `readonly` 타입의 데이터를, 수정 가능한 타입(mutable)을 매개변수로 받는 함수에 전달할 경우 타입 호환성 규칙에 의해 통과될 수 있습니다. 이로 인해 함수 내부에서 원본 데이터가 변경되는 우회 돌연변이가 발생할 수 있습니다[18, 19].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[불변성(Immutability)]], [[매핑된 타입(Mapped Types)]], [[DeepReadonly]]
-- **Projects/Contexts:** 변경 불가한 외부 API 응답 데이터 모델링, 상태 관리 시스템(Redux 리듀서 등)의 데이터 무결성 보장, 그리고 애플리케이션의 전역 환경 설정(Configuration) 객체 보호 맥락에서 광범위하게 쓰입니다[8, 17].
-- **Contradictions/Notes:** TypeScript의 에일리어싱 한계로 인해 `readonly` 데이터가 `mutable` 타입을 요구하는 함수로 전달되어 내부에서 값이 변경될 위험이 존재하므로, 완전한 불변성을 지키려면 함수 시그니처 전반에 걸쳐 읽기 전용 파라미터를 강제하거나 데이터의 복사본을 넘기는 설계가 필요합니다[18, 19]. 또한, 모든 `readonly` 속성을 다시 수정 가능하게 되돌려야 할 때는 `Mutable`이라는 커스텀 헬퍼 타입을 만들어 매핑 수식어를 제거(`-readonly`)하는 방식으로 해결할 수 있습니다[6].
-
----
-*Last updated: 2026-04-18*
-- Raw Source: [[00_Raw/2026-04-20/Readonly 유틸리티 타입.md]]
----
diff --git a/Programming & Language/Real User Monitoring (RUM).md b/Programming & Language/Real User Monitoring (RUM).md
deleted file mode 100644
index 3acc4360..00000000
--- a/Programming & Language/Real User Monitoring (RUM).md	
+++ /dev/null
@@ -1,41 +0,0 @@
----
-id: P-REINFORCE-AUTO-AB3C97
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Real User Monitoring (RUM)"
----
-
-# [[Real User Monitoring (RUM)]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 실제 사용자 모니터링(RUM)은 웹사이트가 실행되는 동안 실제 사용자가 경험하는 성능 데이터를 직접 수집하는 방법입니다 [1]. 이는 통제된 환경에서 측정하는 실험실(Lab) 데이터와 달리, 성능 에이전트를 사용하여 사용자의 생생한 현장 데이터(Field Data)를 포착합니다 [1, 2]. RUM은 코어 웹 바이탈(Core Web Vitals)과 같은 주요 사용자 경험 지표를 측정하고 시간에 따른 성능 추이를 파악하는 데 필수적으로 활용됩니다 [3, 4].
-
-## 📖 구조화된 지식 (Synthesized Content)
-* **현장 데이터(Field Data)의 수집:** 
-  RUM은 실제 방문자가 라이브 웹사이트와 상호작용할 때 발생하는 현장 데이터를 직접 수집합니다 [1, 5]. 웹사이트의 각 사용자에 대한 데이터를 모두 포함하므로 처리해야 할 데이터 양이 매우 많으며, 이를 효과적으로 필터링하고 해석하기 위해 평균값보다는 중앙값(Median)이나 백분위수(Percentiles)와 같은 통계적 방법이 주로 사용됩니다 [1, 6].
-
-* **코어 웹 바이탈 및 성능 측정:** 
-  RUM은 INP(Interaction to Next Paint)를 비롯한 코어 웹 바이탈을 실제 사용자의 관점에서 측정하는 데 사용됩니다 [3]. 실험실 테스트로는 완벽히 알 수 없는 실제 환경에서의 로딩 지연이나 사용자 상호작용 데이터를 추적할 수 있으며, 크로스 오리진 이미지의 렌더링 시간을 정확히 알 수 없을 때 이미지가 로드된 시간을 보고하는 등 실제 사용자 환경의 제약을 극복하는 데 도움을 줍니다 [3, 7].
-
-* **주요 도구 및 플랫폼:**
-  * **CrUX (Chrome User Experience Report):** 수백만 개의 웹사이트에 대해 데이터 수집에 동의한 Chrome 사용자로부터 실제 성능 지표를 집계하여 제공하는 대표적인 RUM 데이터셋입니다 [8-10].
-  * **RUM 라이브러리 및 상용 서비스:** 사용자별 상호작용 지표를 캡처하기 위해 `web-vitals.js`와 같은 라이브러리를 사용할 수 있습니다 [3]. 또한, Request Metrics나 DebugBear와 같은 모니터링 서비스는 지연 없이 실시간으로 실제 사용자 분석 데이터와 관측 가능성(Observability)을 제공하여, 성능 개선이 실제 사용자에게 미치는 영향을 즉각적으로 모니터링할 수 있게 돕습니다 [11-13].
-
-* **RUM의 중요성:** 
-  RUM은 개발자가 웹사이트 성능이 실제 사용자에게 어떻게 느껴지는지를 파악하게 해줍니다 [1, 5]. 새로운 기능이나 스크립트가 추가되었을 때 성능 저하가 발생하는지 초기 단계에서 모니터링하고, 지속적인 성능 추이를 추적하여 사용자 경험을 최적화하는 데 매우 중요합니다 [4].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[Field Data]], [[Core Web Vitals]], [[Chrome User Experience Report (CrUX)]], [[Synthetic Testing]]
-- **Projects/Contexts:** [[Request Metrics]], [[DebugBear]]
-- **Contradictions/Notes:** 현장 데이터를 수집하는 대표적인 도구인 CrUX는 데이터가 월별로 업데이트되고 도메인 전체로 요약되어 제공되는 반면, Request Metrics와 같은 전문 RUM 서비스는 지연 없이 현재 시점(right now)의 실시간 성능 데이터를 제공한다는 차이점이 있습니다 [10, 13].
-
----
-*Last updated: 2026-04-19*
-- Raw Source: [[00_Raw/2026-04-20/Real User Monitoring (RUM).md]]
----
diff --git a/Programming & Language/Render State.md b/Programming & Language/Render State.md
deleted file mode 100644
index e38e2264..00000000
--- a/Programming & Language/Render State.md	
+++ /dev/null
@@ -1,35 +0,0 @@
----
-id: P-REINFORCE-AUTO-6A1728
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Render State"
----
-
-# [[Render State]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 렌더링 상태(Render State)란 드로우 콜을 실행하기 위해 CPU가 설정하는 GPU의 내부 설정 및 리소스 상태를 의미합니다 [1, 2]. 셰이더 프로그램 바인딩, 재질 변경, 정점 버퍼 할당 등 렌더 상태를 변경하는 작업은 그래픽 API가 수행하는 연산 중 가장 리소스를 많이 소모하는 작업입니다 [1, 2]. 따라서 드로우 콜과 렌더 상태 변경 횟수를 최소화하는 것은 전체 그래픽 렌더링 성능을 최적화하는 데 매우 중요합니다 [2, 3].
-
-## 📖 구조화된 지식 (Synthesized Content)
-- **렌더 상태의 정의 및 역할:** 화면에 기하학적 구조를 그리기 위해 CPU는 드로우 콜(Draw Call)을 발생시키는데, 이를 준비하기 위해 CPU는 리소스를 설정하고 GPU의 내부 설정을 변경하며 이를 총칭하여 렌더 상태(Render State)라고 합니다 [2]. 여기에는 현재 렌더링 상태 설정, 셰이더 프로그램 바인딩, 정점 버퍼 및 텍스처 유닛 할당과 같은 복잡한 준비 과정이 포함됩니다 [1].
-- **성능에 미치는 영향:** 재질(Material)을 변경하는 등 렌더 상태를 변경하는 것은 그래픽 API 연산 중 리소스를 가장 많이 소모하는 작업입니다 [2]. 드로우 콜을 위한 렌더 상태 설정과 같은 준비 과정(오버헤드)은 실제 GPU가 정점을 처리하고 픽셀을 그리는 시간보다 훨씬 더 많은 CPU 자원을 소모하는 경우가 많습니다 [1].
-- **최적화 전략:** 렌더 상태 변경을 최적화하는 핵심은 변경 횟수 자체를 줄이는 것입니다 [2]. 이를 위한 두 가지 주요 방법은 다음과 같습니다:
-    1. **드로우 콜 수 감소:** 전체 드로우 콜 수를 줄이면 드로우 콜 사이에 발생하는 렌더 상태 변경 횟수도 자연스럽게 감소합니다 [3].
-    2. **드로우 콜 구성 최적화:** 그래픽 API가 여러 드로우 콜을 수행할 때 동일한 렌더 상태를 유지할 수 있도록 드로우 콜을 효율적으로 구성하면, 드로우 콜을 그룹화하여 잦은 렌더 상태 변경을 방지할 수 있습니다 [3].
-- **최적화의 이점:** 렌더 상태 변경과 드로우 콜을 최적화하면 일차적으로 프레임 렌더링 시간이 향상됩니다 [4]. 또한, 애플리케이션의 전력 소비를 줄여 배터리 소모와 기기 발열을 감소시킬 수 있으며, 이후 프로젝트에 더 많은 오브젝트(GameObject)를 추가하더라도 큰 성능 저하를 방지하여 장기적인 유지보수성을 높여줍니다 [4].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[Draw Call]], [[CPU]], [[GPU]]
-- **Projects/Contexts:** [[Unity]], [[Real-time Rendering]]
-- **Contradictions/Notes:** 소스 내에서 렌더 상태에 관한 정보나 최적화 방향성에 대해 상충되는 주장은 존재하지 않습니다.
-
----
-*Last updated: 2026-04-19*
-- Raw Source: [[00_Raw/2026-04-20/Render State.md]]
----
diff --git a/Programming & Language/Result Type.md b/Programming & Language/Result Type.md
deleted file mode 100644
index 2a57e10f..00000000
--- a/Programming & Language/Result Type.md	
+++ /dev/null
@@ -1,32 +0,0 @@
----
-id: P-REINFORCE-AUTO-ED64AE
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Result Type"
----
-
-# [[Result Type]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> Result Type(결과 타입)은 함수나 메서드의 반환 값으로 성공 데이터 또는 예상되는 실패(에러)를 명시적으로 함께 표현하는 타입 구조입니다 [1-3]. 예외(Exception)를 무분별하게 던지는 대신 결괏값을 직접 반환하여 프로그램의 실행 흐름이 임의로 끊기는 것을 방지하고 성능 오버헤드를 줄입니다 [4-6]. 개발자가 함수 시그니처만으로 발생 가능한 에러를 명확히 알 수 있게 하며, 컴파일 단계에서 모든 경우의 수에 대한 에러 처리를 강제하여 런타임 안정성을 높이는 데 활용됩니다 [7-9].
-
-## 📖 구조화된 지식 (Synthesized Content)
-- **예외 처리(Exception)의 안전한 대안:** Result Type은 예상 가능한 에러(예: 데이터베이스 조회 실패, 입력값 유효성 검사 실패 등)를 처리하는 데 효과적입니다 [10-12]. 전통적인 예외 처리는 호출 스택(Call stack)을 거슬러 올라가야 하므로 비용이 크고 디버깅 추적이 어렵지만, Result Type은 단순한 객체 반환이므로 더 빠르고 효율적입니다 [5, 6, 13]. 따라서 예기치 못한 치명적 결함(Defect)에만 예외를 던지고, 예상 가능한 비즈니스 로직상의 에러에는 Result Type을 반환하는 방식이 권장됩니다 [14, 15].
-- **타입 안전성(Type Safety)과 예측 가능성 향상:** Result Type은 반환 타입 안에 성공(`Ok`)과 실패(`Err`)의 형태를 모두 담기 때문에, 개발자가 코드를 분석할 때 시그니처만 보더라도 어떤 결과와 에러가 반환될지 예측할 수 있습니다 [1, 7]. 이는 '최소 놀람의 원칙(Principle of least astonishment)'을 충족시키며, 컴파일러가 모든 반환 경우를 확인(Exhaustiveness check)하도록 강제하여 런타임 오류 가능성을 원천적으로 차단합니다 [3, 9].
-- **언어별 구현 및 활용:** 이 패턴은 본래 F#, Elixir, Erlang, Rust와 같은 함수형 프로그래밍 언어에서 기원하였으며, 주로 구별된 유니온(Discriminated Unions)이나 Either 모나드의 형태를 띠고 있습니다 [5, 16, 17]. TypeScript 생태계에서는 `neverthrow`와 같은 외부 라이브러리를 활용하여 명시적인 `Err` 및 `Ok` 객체로 에러 제어 흐름을 구현할 수 있습니다 [1, 18].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[Discriminated Unions]], [[Exception Handling]]
-- **Projects/Contexts:** [[neverthrow]], [[OneOf]], [[Railway Oriented Programming]]
-- **Contradictions/Notes:** C# 생태계에서는 Result Type 도입을 둘러싼 논쟁이 존재합니다. 도입을 지지하는 쪽은 타입 안전성과 명확한 에러 파악을 장점으로 꼽지만, 반대하는 개발자들은 C#이 기본적으로 예외(Exception) 기반의 언어이므로 두 가지 에러 처리 방식이 섞이면 혼란을 야기할 수 있으며, 결괏값을 포장(Wrapping)하고 푸는 과정에서 보일러플레이트 코드가 증가해 오히려 가독성을 해칠 수 있다고 지적합니다 [2, 6, 19, 20].
-
----
-*Last updated: 2026-04-18*
-- Raw Source: [[00_Raw/2026-04-20/Result Type.md]]
----
diff --git a/Programming & Language/Reward Shaping (보상 설계).md b/Programming & Language/Reward Shaping (보상 설계).md
deleted file mode 100644
index 4f47c588..00000000
--- a/Programming & Language/Reward Shaping (보상 설계).md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-1B82EC
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Reward Shaping (보상 설계)"
----
-
-# [[Reward Shaping (보상 설계)]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Reward Shaping (보상 설계).md]]
----
diff --git a/Programming & Language/Robotic-Manipulator-Dynamics.md b/Programming & Language/Robotic-Manipulator-Dynamics.md
deleted file mode 100644
index cbd22aec..00000000
--- a/Programming & Language/Robotic-Manipulator-Dynamics.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-CA896D
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Robotic-Manipulator-Dynamics"
----
-
-# [[Robotic-Manipulator-Dynamics]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Robotic-Manipulator-Dynamics.md]]
----
diff --git a/Programming & Language/Robust-GitHub-Sync-Pipeline.md b/Programming & Language/Robust-GitHub-Sync-Pipeline.md
deleted file mode 100644
index f32a3e5f..00000000
--- a/Programming & Language/Robust-GitHub-Sync-Pipeline.md	
+++ /dev/null
@@ -1,36 +0,0 @@
----
-id: P-REINFORCE-AUTO-CCD7BE
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Robust-GitHub-Sync-Pipeline"
----
-
-# [[Robust-GitHub-Sync-Pipeline]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 에이전트가 수집한 지식을 원격 위키 저장소에 안전하게 기록하는 최종 단계의 동기화 엔진입니다. 복잡한 저장소 URL 형식을 자동으로 파싱하고, 파일 부재(404)를 오류가 아닌 '신규 생성 기회'로 판단하는 지능형 예외 처리를 포함합니다.
-
-## 📖 구조화된 지식 (Synthesized Content)
-GitHub API를 이용한 자동 커밋은 파일 존재 여부에 따라 SHA 값을 다르게 처리해야 하는 까다로운 프로세스를 가집니다. 이번 개선을 통해 파이프라인의 완성도를 높였습니다.
-
-1. **Flexible URL Parser**: 
-    - `owner/repo` 형태뿐만 아니라 `https://github.com/...`의 풀 경로, 심지어 `.git`이 붙은 경로까지 정규표현식으로 정제하여 정확한 엔드포인트를 도출합니다.
-2. **404 Handling vs Repository Verification**: 
-    - **Expected 404**: 파일 존재 확인 시 발생하는 404는 '신규 파일 생성'의 신호로 간주하여 로직을 분기합니다.
-    - **Fatal 404**: 저장소 정보 자체를 불러오지 못할 경우에만 사용자에게 경고를 보내 설정 오류를 인지시킵니다.
-3. **Atomic Commit Workflow**: 연구 데이터 합성 완료 -> 로컬 상태 업데이트 -> GitHub 커밋 시도의 단계를 원자적으로 관리하여 데이터 유실을 방지합니다.
-
-이 동기화 엔진은 에이전트가 로컬 환경을 넘어, 전 세계에서 접근 가능한 '지식 저장소'를 실전적으로 구축할 수 있게 만드는 핵심 도구입니다.
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[Ontology-Driven-Relevancy-Filtering]], [[Zustand-Based-Mission-Persistence]]
-- **Projects/Contexts:** [[Knowledge-Base-Automation]]
-- **Contradictions/Notes:** GitHub API의 Rate Limit(시간당 요청 제한)을 고려해야 하며, 대량의 커밋 성공 시 배치(Batch) 처리 방식을 검토할 수 있습니다.
-- Raw Source: [[00_Raw/2026-04-20/Robust-GitHub-Sync-Pipeline.md]]
----
diff --git a/Programming & Language/Runtime-Type-Validation.md b/Programming & Language/Runtime-Type-Validation.md
deleted file mode 100644
index 956dbfea..00000000
--- a/Programming & Language/Runtime-Type-Validation.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-BFB695
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Runtime-Type-Validation"
----
-
-# [[Runtime-Type-Validation]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Runtime-Type-Validation.md]]
----
diff --git a/Programming & Language/SCA (소프트웨어 구성 분석).md b/Programming & Language/SCA (소프트웨어 구성 분석).md
deleted file mode 100644
index ef07c068..00000000
--- a/Programming & Language/SCA (소프트웨어 구성 분석).md	
+++ /dev/null
@@ -1,33 +0,0 @@
----
-id: P-REINFORCE-AUTO-A04F7E
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - SCA (소프트웨어 구성 분석)"
----
-
-# [[SCA (소프트웨어 구성 분석)]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> SCA(Software Composition Analysis)는 애플리케이션에 포함된 제3자(Third-party) 코드 및 오픈소스 라이브러리의 의존성(Dependencies)을 분석하는 보안 테스팅 기법입니다 [1, 2]. 주로 외부 컴포넌트에 이미 보고된 보안 취약점(CVE 등)과 라이선스 컴플라이언스 관련 리스크를 식별하는 데 사용됩니다 [1]. 오늘날 소프트웨어 개발에서 오픈소스 라이브러리 사용 비중이 매우 높기 때문에 소프트웨어 공급망 보안을 관리하는 데 있어 그 중요성이 커지고 있으며 [1, 2], 자체 코드를 검사하는 SAST와 함께 상호 보완적으로 활용됩니다 [3].
-
-## 📖 구조화된 지식 (Synthesized Content)
-- **분석 대상 및 주요 목적**: SCA는 개발자가 직접 작성한 커스텀 코드의 논리적 결함을 찾는 SAST와 달리, 애플리케이션에 포함된 오픈소스 및 제3자 의존성 컴포넌트 분석에 특화되어 있습니다 [1, 2]. 구성 요소의 라이선스 세부 정보, 버전 이력, 기존 취약점 데이터베이스(CVE 등)에 등록된 취약점을 파악하여 라이선스 규정 준수 및 리스크 관리를 지원합니다 [1, 2].
-- **의존성(Dependency) 가시성 확보**: 애플리케이션 코드에 직접 선언된 의존성뿐만 아니라 그 이면에 연결된 전이적 의존성(transitive dependencies)까지 추적합니다 [1]. 많은 오픈소스 라이브러리에 의존하여 개발이 이루어지는 현대적 환경에서, 이러한 공급망(Supply-chain) 위험 관리의 핵심 도구로 작동합니다 [1, 2].
-- **도달 가능성(Reachability) 분석의 진화**: 최신 SCA 도구들(예: Endor Labs)은 단순히 취약한 오픈소스 패키지가 포함되어 있는지를 확인하는 것을 넘어, 해당 서드파티 코드 내의 취약한 함수가 실제 퍼스트파티(First-party) 코드의 실행 경로를 통해 호출되는지 분석하는 '도달 가능성 기반 SCA(Reachability-based SCA)'로 진화하고 있습니다 [4, 5]. 이는 맥락을 고려한 필터링을 통해 알림 피로도를 줄이고, 자체 코드와 의존성 리스크의 우선순위를 효과적으로 지정할 수 있게 돕습니다 [4, 6].
-- **보안 도구 간의 결합 (SAST + SCA)**: SAST는 라이브러리 코드가 분석 범위에 포함되지 않으면 해당 라이브러리의 취약점을 놓칠 수 있습니다 [1]. 따라서 커스텀 코드를 보호하는 SAST와 서드파티 컴포넌트 취약점을 보호하는 SCA를 동시에 사용하여 전체 애플리케이션 보안 범위를 포괄적으로 방어하는 것이 권장됩니다 [1-3].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[SAST (정적 애플리케이션 보안 테스팅)]], [[서플라이 체인 보안 (Supply Chain Security)]], [[오픈소스 컴포넌트 (Open Source Components)]], [[도달 가능성 분석 (Reachability Analysis)]]
-- **Projects/Contexts:** [[데브섹옵스 (DevSecOps) 환경에서의 지속적인 보안 검사]], [[Snyk, Checkmarx, Endor Labs 등 종합 애플리케이션 보안 플랫폼]]
-- **Contradictions/Notes:** 여러 소스에서 SCA와 SAST는 서로 대체하거나 경쟁하는 관계가 아니라는 점을 분명히 합니다. SAST는 자체 작성 코드의 논리 결함을, SCA는 서드파티 코드의 버전 이력 및 라이선스 문제를 잡아내기 때문에 각 도구의 약점을 보완하려면 이 둘을 결합하여 사용하는 것이 모범 사례로 강조됩니다 [1, 2].
-
----
-*Last updated: 2026-04-18*
-- Raw Source: [[00_Raw/2026-04-20/SCA (소프트웨어 구성 분석).md]]
----
diff --git a/Programming & Language/SOLID 원칙 (SOLID Principles).md b/Programming & Language/SOLID 원칙 (SOLID Principles).md
deleted file mode 100644
index 5f4a70ee..00000000
--- a/Programming & Language/SOLID 원칙 (SOLID Principles).md	
+++ /dev/null
@@ -1,46 +0,0 @@
----
-id: P-REINFORCE-AUTO-D3B79D
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - SOLID 원칙 (SOLID Principles)"
----
-
-# [[SOLID 원칙 (SOLID Principles)]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-**SOLID의 5가지 핵심 원칙**
-소스 데이터에 따르면 SOLID는 다음 다섯 가지 원칙의 약자입니다 [1].
-*   **단일 책임 원칙 (Single Responsibility Principle, SRP):** 클래스는 단 하나의 변경 이유만 가져야 하며, 오직 하나의 작업(책임)만 수행해야 합니다 [4]. 예를 들어, 사용자 데이터를 저장하고 조회하는 클래스가 사용자 입력 검증 기능까지 담당해서는 안 됩니다 [4]. 이는 관심사의 분리(SoC) 원칙을 극단적으로 적용한 형태로 볼 수 있습니다 [5].
-*   **개방/폐쇄 원칙 (Open/Closed Principle, OCP):** 소프트웨어 엔티티는 확장을 위해서는 열려 있어야 하지만, 수정을 위해서는 닫혀 있어야 합니다 [4, 6]. 인터페이스나 추상 클래스를 사용하여, 기존 코드를 변경하지 않고도 새로운 하위 클래스를 통해 기능을 추가할 수 있게 함으로써 달성할 수 있습니다 [4].
-*   **리스코프 치환 원칙 (Liskov Substitution Principle, LSP):** 하위 타입(Subtype)은 프로그램의 정확성을 훼손하지 않으면서도 기본 타입(Base type)으로 완벽하게 대체될 수 있어야 합니다 [4].
-*   **인터페이스 분리 원칙 (Interface Segregation Principle, ISP):** 클라이언트가 자신이 사용하지 않는 인터페이스에 의존하도록 강요받아서는 안 됩니다 [4]. 하나의 크고 범용적인 인터페이스를 만들기보다는, 더 작고 구체적인 여러 개의 인터페이스를 생성해야 합니다 [4]. 
-*   **의존성 역전 원칙 (Dependency Inversion Principle, DIP):** 고수준 모듈은 저수준 모듈에 의존해서는 안 되며, 두 모듈 모두 추상화(예: 인터페이스)에 의존해야 합니다 [4, 7]. 이는 주로 의존성 주입(Dependency Injection)을 사용하여 구현됩니다 [4].
-
-**구현을 위한 실용적인 조언**
-*   **SRP부터 적용하기:** 단일 책임 원칙은 적용하기 가장 쉬우며 즉각적인 이점을 제공합니다. 클래스를 작성하기 전에 "이 클래스의 단일 책임은 무엇인가?"라고 스스로 질문해야 합니다 [3, 8].
-*   **구현 전 인터페이스 설계:** 컴포넌트가 '어떻게' 동작할지를 구현하기 전에, '무엇을' 해야 하는지(인터페이스)를 먼저 정의해야 합니다 [8]. 이 방식은 자연스럽게 OCP와 DIP 원칙을 지원합니다 [8].
-*   **의존성 주입(DI) 프레임워크 활용:** Spring(Java)이나 ASP.NET Core와 같이 내장된 DI 컨테이너를 제공하는 프레임워크를 사용하면 컴포넌트 간의 결합을 분리하고 DIP를 훨씬 쉽게 구현할 수 있습니다 [8].
-*   **점진적 도입:** 기존의 레거시 애플리케이션을 한 번에 모두 리팩토링할 필요는 없습니다. 새로운 기능을 추가하거나 기존 코드를 수정할 때 SOLID 원칙을 점진적으로 적용하여 코드베이스의 상태를 개선해 나가는 것이 좋습니다 [8].
-
-**적용 시의 복잡도 및 요구사항**
-*   SOLID 원칙을 구현하는 것은 설계 규율과 패턴을 요구하므로 중간에서 높음(Medium–High) 수준의 복잡도를 가집니다 [3].
-*   이를 원활하게 적용하기 위해서는 숙련된 개발자와 의존성 주입(DI) 프레임워크 등의 리소스가 뒷받침되어야 합니다 [3].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[객체 지향 프로그래밍 (OOP)]], [[관심사의 분리 (Separation of Concerns)]], [[의존성 주입 (Dependency Injection)]]
-- **Projects/Contexts:** [[엔터프라이즈 애플리케이션 및 점진적 리팩토링]], [[라이브러리 및 확장 가능한 코드베이스]]
-- **Contradictions/Notes:** 소스 내에서 상충하는 주장은 발견되지 않았습니다. 다만, 단일 책임 원칙(SRP)은 시스템을 고차원적인 수준에서 분리하는 '관심사의 분리(SoC)' 원칙과 종종 비교되며, SRP는 클래스나 모듈의 '책임'이라는 더 미시적인 수준을 다루는 것으로 설명됩니다 [9].
-
----
-*Last updated: 2026-04-18*
-- Raw Source: [[00_Raw/2026-04-20/SOLID 원칙 (SOLID Principles).md]]
----
diff --git a/Programming & Language/SOLID 원칙.md b/Programming & Language/SOLID 원칙.md
deleted file mode 100644
index 42aef66e..00000000
--- a/Programming & Language/SOLID 원칙.md	
+++ /dev/null
@@ -1,40 +0,0 @@
----
-id: P-REINFORCE-AUTO-FAB206
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - SOLID 원칙"
----
-
-# [[SOLID 원칙]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> SOLID 원칙은 객체 지향 프로그래밍에서 소프트웨어 설계를 더 이해하기 쉽고, 유연하며, 유지보수하기 좋게 만들기 위해 고안된 5가지 핵심 설계 원칙의 집합이다 [1]. 로버트 C. 마틴(Robert C. Martin)에 의해 대중화된 이 원칙들은 코드의 부패를 방지하고 견고한 기반을 구축하는 데 필수적인 지침으로 작용한다 [1]. 이 원칙들을 올바르게 적용하면 시스템 내 컴포넌트 간의 의존성이 줄어들어 한 부분의 변경이 다른 부분에 미치는 영향을 최소화할 수 있다 [1].
-
-## 📖 구조화된 지식 (Synthesized Content)
-**SOLID의 5가지 핵심 원칙**
-* **단일 책임 원칙 (SRP, Single Responsibility Principle):** 클래스는 단 하나의 변경 이유만 가져야 하며, 이는 오직 하나의 역할(책임)만을 수행해야 함을 의미한다 [2, 3]. 이를 통해 클래스를 더 쉽게 이해하고 평가할 수 있으며, 코드의 명확성과 유지보수성이 향상된다 [3]. SRP는 '관심사의 분리(SoC)' 개념에서 직접적으로 파생된 원칙 중 하나이다 [4].
-* **개방-폐쇄 원칙 (OCP, Open/Closed Principle):** 소프트웨어 엔티티는 확장에는 열려 있어야 하지만 수정에는 닫혀 있어야 한다 [2, 3, 5]. 이는 인터페이스나 추상 클래스와 같은 추상화 및 다형성 과정을 사용하여, 기존 코드를 변경하지 않고도 새로운 하위 클래스를 통해 새 기능을 추가할 수 있게 함으로써 달성된다 [2, 3].
-* **리스코프 치환 원칙 (LSP, Liskov Substitution Principle):** 하위 타입(서브클래스)은 프로그램의 정확성을 훼손하지 않으면서 기본 타입(부모 클래스)을 대체할 수 있어야 한다 [2, 3]. 이는 파생 클래스가 기본 클래스의 동작을 임의로 변경하지 않고 매끄럽게 호환되어 시스템의 신뢰성과 견고성을 향상시킬 수 있도록 보장한다 [2, 3].
-* **인터페이스 분리 원칙 (ISP, Interface Segregation Principle):** 클라이언트는 자신이 사용하지 않는 인터페이스에 의존하도록 강요받아서는 안 된다 [2, 3]. 이를 위해 하나의 크고 범용적인 인터페이스보다는 작고 구체적이며 전문화된 인터페이스를 여러 개 만드는 것이 권장되며, 이 역시 '관심사의 분리(SoC)' 원칙에서 파생되었다 [2-4].
-* **의존성 역전 원칙 (DIP, Dependency Inversion Principle):** 고수준 모듈은 저수준 모듈에 의존해서는 안 되며, 양쪽 모두 추상화(예: 인터페이스)에 의존해야 한다 [2, 3, 6]. 이러한 접근은 종종 의존성 주입(Dependency Injection, DI) 프레임워크를 통해 구현되며, 모듈성을 높이고 시스템이 변화에 쉽게 적응할 수 있도록 만든다 [2, 3, 7].
-
-**구현 팁 및 기대 효과**
-* SOLID 원칙을 레거시 애플리케이션 전체에 한 번에 적용하기보다는, 가장 적용하기 쉽고 즉각적인 이점을 제공하는 '단일 책임 원칙(SRP)'부터 시작하여 점진적으로 적용하는 것이 유리하다 [7].
-* 구현 방법(How)보다 컴포넌트가 해야 할 일인 인터페이스(What)를 먼저 설계하는 관행을 들이면 자연스럽게 OCP와 DIP 원칙을 뒷받침할 수 있다 [7].
-* 이 원칙들은 객체 지향 시스템, 라이브러리, 그리고 지속적으로 성장하는 대규모 코드베이스에 이상적으로 적용되며, 결합도가 낮고 테스트 가능성이 높으며 유연한 코드를 산출하는 핵심 기반이 된다 [8].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[객체 지향 프로그래밍(OOP)]], [[관심사의 분리(SoC)]], [[의존성 주입(DI)]]
-- **Projects/Contexts:** [[클린 아키텍처(Clean Architecture)]], [[소프트웨어 아키텍처 베스트 프랙티스]]
-- **Contradictions/Notes:** 소스 전반에 걸쳐 SOLID 원칙은 코드의 복잡성을 줄이고 유지보수성을 높이는 필수적인 기법으로 일관되게 강조되고 있으며, 서로 대립하거나 모순되는 주장은 존재하지 않습니다 [1, 3, 8].
-
----
-*Last updated: 2026-04-18*
-- Raw Source: [[00_Raw/2026-04-20/SOLID 원칙.md]]
----
diff --git a/Programming & Language/SPA 라우트 전환 성능 최적화.md b/Programming & Language/SPA 라우트 전환 성능 최적화.md
deleted file mode 100644
index eab233e1..00000000
--- a/Programming & Language/SPA 라우트 전환 성능 최적화.md	
+++ /dev/null
@@ -1,36 +0,0 @@
----
-id: P-REINFORCE-AUTO-A346D0
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - SPA 라우트 전환 성능 최적화"
----
-
-# [[SPA 라우트 전환 성능 최적화]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> SPA(Single Page Application) 라우트 전환은 현대 프론트엔드 애플리케이션에서 메모리 누수가 발생하는 가장 주요한 원인 중 하나입니다 [1]. 이전 라우트의 컴포넌트가 적절히 정리되지 않으면 애플리케이션의 세션 수명 동안 메모리에 지속적으로 누적되어 성능 저하를 유발합니다 [1]. 따라서 성공적인 라우트 전환 성능 최적화를 위해서는 사용되지 않는 리소스와 참조를 철저히 식별하고 해제하는 메모리 관리가 필수적입니다 [1, 2].
-
-## 📖 구조화된 지식 (Synthesized Content)
-- **라우트 전환과 메모리 누수:** SPA 라우트 전환(SPA route transitions)은 애플리케이션 내 메모리 누수의 1위 출처로 지목됩니다 [1]. 이전 라우트에서 사용되었던 컴포넌트들이 이벤트 리스너(listeners), 타이머(timers), 혹은 전역 상태 참조(global state references) 등을 제대로 정리(clean up)하지 못할 경우, 이 컴포넌트들은 가비지 컬렉터에 의해 회수되지 못하고 세션 수명 내내 메모리에 축적됩니다 [1].
-- **누수 탐지를 위한 3-스냅샷 기법(Three-snapshot technique):** 라우트 전환 시 발생하는 메모리 누수를 감지하고 최적화하기 위해 가장 신뢰할 수 있는 방법은 3-스냅샷 기법입니다 [2]. 
-  1. 기준이 되는 첫 번째 힙 스냅샷(Heap snapshot 1)을 캡처합니다 [2].
-  2. 라우트 간 이동(navigate between routes)과 같이 누수가 의심되는 작업을 수행한 후 두 번째 스냅샷을 찍습니다 [2].
-  3. 동일한 라우트 전환 작업을 다시 반복하고 세 번째 스냅샷을 캡처합니다 [2].
-  4. 두 번째와 세 번째 스냅샷을 비교하여, 첫 번째와 두 번째 사이에 할당되었으나 세 번째 스냅샷까지 여전히 메모리에 살아있는 객체들을 찾아냅니다 [2]. 이 접근법은 단순 1회성 할당으로 인한 오탐(false positives)을 걸러내고 실제 누수 후보를 식별하는 데 효과적입니다 [2].
-- **정보 한계:** 제공된 소스에서는 SPA 라우트 전환 시의 성능 최적화를 메모리 누수 발생 원인과 그 탐지(DevTools 활용 등) 관점에서만 다루고 있습니다 [1, 2]. 라우팅 시의 렌더링 최적화, 코드 스플리팅, 네트워크 지연 단축 등 다른 측면의 최적화에 대해서는 소스에 관련 정보가 부족합니다.
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[메모리 누수(Memory Leak)]], [[3-스냅샷 기법(Three-snapshot technique)]], [[가비지 컬렉션(Garbage Collection)]]
-- **Projects/Contexts:** [[Browser Memory Leak Detection]]
-- **Contradictions/Notes:** 소스에서는 SPA 라우트 전환 성능 최적화에 대한 전반적인 프론트엔드 렌더링 최적화 기술은 언급하지 않으며, 오직 컴포넌트 언마운트 시의 정리 실패로 인한 메모리 누수 문제와 그 진단법에만 집중하고 있습니다.
-
----
-*Last updated: 2026-04-19*
-- Raw Source: [[00_Raw/2026-04-20/SPA 라우트 전환 성능 최적화.md]]
----
diff --git a/Programming & Language/SPARQL (RDF 그래프 질의 언어).md b/Programming & Language/SPARQL (RDF 그래프 질의 언어).md
deleted file mode 100644
index fd1af564..00000000
--- a/Programming & Language/SPARQL (RDF 그래프 질의 언어).md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-6D75A5
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - SPARQL (RDF 그래프 질의 언어)"
----
-
-# [[SPARQL (RDF 그래프 질의 언어)]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/SPARQL (RDF 그래프 질의 언어).md]]
----
diff --git a/Programming & Language/SaaS-Product-Management.md b/Programming & Language/SaaS-Product-Management.md
deleted file mode 100644
index e2a29f00..00000000
--- a/Programming & Language/SaaS-Product-Management.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-B72D67
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - SaaS-Product-Management"
----
-
-# [[SaaS-Product-Management]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/SaaS-Product-Management.md]]
----
diff --git a/Programming & Language/Sandbox Simulations (eg Minecraft Dwarf Fortress).md b/Programming & Language/Sandbox Simulations (eg Minecraft Dwarf Fortress).md
deleted file mode 100644
index 74a6b1eb..00000000
--- a/Programming & Language/Sandbox Simulations (eg Minecraft Dwarf Fortress).md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-0DFB46
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Sandbox Simulations (eg Minecraft Dwarf Fortress)"
----
-
-# [[Sandbox Simulations (eg Minecraft Dwarf Fortress)]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Sandbox Simulations (e.g., Minecraft, Dwarf Fortress).md]]
----
diff --git a/Programming & Language/Santa Fe Institute.md b/Programming & Language/Santa Fe Institute.md
deleted file mode 100644
index 2ee81df9..00000000
--- a/Programming & Language/Santa Fe Institute.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-6E6047
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Santa Fe Institute"
----
-
-# [[Santa Fe Institute]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Santa Fe Institute.md]]
----
diff --git a/Programming & Language/Satisfiability-Problem-(SAT).md b/Programming & Language/Satisfiability-Problem-(SAT).md
deleted file mode 100644
index 30bfaff1..00000000
--- a/Programming & Language/Satisfiability-Problem-(SAT).md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-55CA55
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Satisfiability-Problem-(SAT)"
----
-
-# [[Satisfiability-Problem-(SAT)]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Satisfiability-Problem-(SAT).md]]
----
diff --git a/Programming & Language/Satisfies Operator.md b/Programming & Language/Satisfies Operator.md
deleted file mode 100644
index dbde3131..00000000
--- a/Programming & Language/Satisfies Operator.md	
+++ /dev/null
@@ -1,38 +0,0 @@
----
-id: P-REINFORCE-AUTO-B08904
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Satisfies Operator"
----
-
-# [[Satisfies Operator]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> `satisfies` 연산자는 TypeScript 4.9에 도입된 기능으로, 객체가 특정 타입의 형태를 준수하는지 검증하면서도 해당 객체의 구체적인 타입(리터럴 타입 등)을 넓히지(widening) 않고 그대로 유지하는 역할을 합니다 [1-3]. 기존의 타입 어노테이션(`:`)이 가진 타입 확장 문제와 타입 단언(`as`)이 가진 검증 누락 문제를 동시에 해결하여 엄격한 타입 검사와 정밀한 타입 추론을 모두 제공합니다 [1, 3, 4]. 이를 통해 컴파일 타임에 잉여 속성이나 오타를 잡아내어 코드의 안정성과 예측 가능성을 크게 높여줍니다 [3, 5].
-
-## 📖 구조화된 지식 (Synthesized Content)
-- **리터럴 타입 보존 및 구체성 유지 (Literal Type Preservation):** 기존의 타입 어노테이션(`:`)을 사용하면 구체적인 리터럴 값이 일반적인 타입(예: `"/about"`이 범용적인 `string`으로)으로 확장(widening)됩니다 [2, 6]. 반면 `satisfies` 연산자는 객체가 인터페이스를 충족하는지 확인하면서도 원래의 리터럴 타입을 잃지 않고 그대로 보존하여, 이후 코드에서 더 정확한 자동 완성과 정밀한 타입 추론을 가능하게 합니다 [2, 3, 6].
-- **엄격한 타입 검증과 과잉 속성 체크 (Excess Property Checking):** 변수를 간접적으로 할당할 때 발생할 수 있는 과잉 속성 체크(EPC)의 우회 문제를 해결합니다 [3, 7]. `satisfies`는 대상 타입에 정의된 요구사항을 객체가 충족하는지 즉시 검사하여 오타를 잡아내며, 원치 않는 잉여 속성(Excess Properties)이 할당되는 것을 컴파일 시점에 철저히 차단합니다 [3, 5, 8].
-- **타입 단언(`as`) 및 어노테이션(`:`)과의 비교:**
-  - **타입 어노테이션(`:`):** 변수의 수명 주기에 대한 제약을 정의하지만, 할당된 값의 타입을 명시된 타입으로 강제 확장시킵니다 [6, 9].
-  - **타입 단언(`as`):** 컴파일러의 타입 검증을 강제로 우회하여 런타임 에러를 유발할 수 있으며, 잉여 속성에 대한 검사를 수행하지 못합니다 [9, 10].
-  - **`satisfies`:** 타입을 확장하지 않으면서도 정확한 형태를 검증하므로, 객체 리터럴의 유효성 검사 및 정밀한 타입 유지가 필요할 때 가장 안전한 대안이 됩니다 [4, 11].
-- **고급 활용 패턴:**
-  - **불변성 확보:** `as const satisfies` 형태로 결합하면, 객체의 불변성을 보장하면서(런타임 불변성 및 컴파일 타임 보호) 타입 구조까지 엄격하게 강제할 수 있어 설정(Configuration) 객체나 상수 룩업 테이블 작성에 매우 유용합니다 [12].
-  - **식별 가능한 유니온(Discriminated Unions) 보존:** 유니온 타입에서 판별자(Discriminator) 속성의 리터럴 타입을 그대로 보존하여, 이후 올바른 타입 좁히기(Type Narrowing)가 정상적으로 동작하도록 지원합니다 [13].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[Excess Property Checking]], [[Structural Typing]], [[Discriminated Unions]], [[Type Narrowing]]
-- **Projects/Contexts:** [[설정 객체(Configuration Objects) 검증]], [[데이터 매핑 및 변환(Data Mapping & Transformation)]]
-- **Contradictions/Notes:** 타입 단언(`as`)은 대상 타입과 근본적으로 호환되지 않는 경우가 아니면 잉여 속성이 포함되어 있어도 타입 검사를 강제하지 않고 통과시켜 조용한 에러(silent errors)를 낳을 수 있지만, `satisfies`는 이를 허용하지 않고 컴파일 타임에 엄격히 잡아냅니다 [10]. 또한, `satisfies`는 본래 추가적인 잉여 속성을 허용하는 특성이 있으나, 만약 추가된 속성의 이름이 대상 타입의 속성 철자와 비슷하여 오타로 의심될 경우에는 잠재적 오류로 간주하고 경고를 발생시킵니다 [2, 14, 15].
-
----
-*Last updated: 2026-04-18*
-- Raw Source: [[00_Raw/2026-04-20/Satisfies Operator.md]]
----
diff --git a/Programming & Language/Scavenge.md b/Programming & Language/Scavenge.md
deleted file mode 100644
index 2f636397..00000000
--- a/Programming & Language/Scavenge.md	
+++ /dev/null
@@ -1,33 +0,0 @@
----
-id: P-REINFORCE-AUTO-E7007A
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Scavenge"
----
-
-# [[Scavenge]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> Scavenge(스캐빈지)는 V8 엔진을 비롯한 가비지 컬렉션(GC) 시스템에서 젊은 세대(Young Generation) 메모리를 정리하기 위해 수행되는 마이너 가비지 컬렉션(Minor GC) 주기입니다 [1, 2]. 주로 새로운 객체가 할당되는 '새로운 공간(New-space)'이 가득 차서 할당에 실패했을 때 트리거되며, 죽은 객체를 빠르게 제거하고 살아있는 객체를 보존합니다 [1, 2]. 애플리케이션 실행 중 매우 빈번하게 발생하기 때문에 성능에 미치는 영향을 최소화하도록 극히 빠른 속도로 동작하게 설계되었습니다 [3].
-
-## 📖 구조화된 지식 (Synthesized Content)
-- **동작 원리 (V8 엔진 및 Cheney의 알고리즘):** V8의 새 공간(New-space)은 크기가 같은 두 개의 반공간(Semi-space)인 To-space와 From-space로 나뉩니다 [3]. 객체 할당 포인터가 새 공간의 끝에 도달하여 메모리가 고갈되면 스캐빈지가 트리거됩니다 [1, 2]. 이때 To-space와 From-space의 역할을 맞바꾼 뒤, From-space를 스캔하여 살아있는 객체들을 찾아 To-space의 한쪽 끝으로 복사(대피)하며, 이 과정을 통해 메모리 파편화(Fragmentation)가 완전히 제거됩니다 [3, 4].
-- **객체의 승격 (Promotion):** 두 번의 스캐빈지(마이너 GC) 주기 동안 살아남은 객체는 수명이 긴 객체로 간주되어 새 공간에서 '오래된 공간(Old-space)'으로 승격(Promoted)됩니다 [1, 4].
-- **병렬 및 스레드 처리 (Orinoco 가비지 컬렉터):** 전통적으로 스캐빈지는 애플리케이션 실행을 멈추는 'Stop-the-world' 방식이었지만, V8의 Orinoco 프로젝트에서는 병렬 스캐빈저(Parallel Scavenger)를 도입했습니다 [5-7]. 메인 스레드와 여러 헬퍼 스레드에 작업을 분산하여 루트 스캔, 객체 복사, 오래된 공간으로의 승격, 포인터 업데이트를 병렬적으로 끼워 넣어(Interleaved) 실행합니다 [6, 8, 9]. 이를 통해 메인 스레드의 대기 시간(Pause time)을 약 20%~50%까지 대폭 단축했습니다 [10, 11].
-- **IBM J9 / Eclipse OpenJ9 환경의 스캐빈지:** IBM GC 정책(주로 gencon 정책)에서도 널서리(Nursery) 영역에서의 할당 실패 시 스캐빈지 작업이 실행됩니다 [12]. 이 작업은 루트 객체를 식별하는 루트 스캔(Initial), 도달 가능한 객체를 널서리의 생존자(Survivor) 공간이나 텐뉴어(Tenure) 공간으로 이동시키는 계층적 스캔(Main), 그리고 약한 참조 등을 처리하는 단계(Final)로 구성됩니다 [12].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[Garbage Collection]], [[New-space (Young Generation)]], [[Old-space (Old Generation)]], [[Cheney's Algorithm]], [[Mark-Sweep-Compact]]
-- **Projects/Contexts:** [[V8 JavaScript Engine]], [[Orinoco GC]], [[Eclipse OpenJ9]]
-- **Contradictions/Notes:** 소스 간의 뚜렷한 모순은 없으나, 스캐빈지가 발생하면 본래 메인 스레드가 정지하는 'Stop-the-world' 현상이 발생하지만 최신 V8 엔진(Orinoco)에서는 다수의 스레드를 동원한 병렬 처리(Parallel)를 적용하여 사용자가 느끼는 지연(Jank)을 획기적으로 줄였다고 명시하고 있습니다 [6, 10, 13].
-
----
-*Last updated: 2026-04-19*
-- Raw Source: [[00_Raw/2026-04-20/Scavenge.md]]
----
diff --git a/Programming & Language/Scavenger 알고리즘.md b/Programming & Language/Scavenger 알고리즘.md
deleted file mode 100644
index 553b8d95..00000000
--- a/Programming & Language/Scavenger 알고리즘.md	
+++ /dev/null
@@ -1,34 +0,0 @@
----
-id: P-REINFORCE-AUTO-04124F
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Scavenger 알고리즘"
----
-
-# [[Scavenger 알고리즘]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> Scavenger 알고리즘은 V8 JavaScript 엔진에서 새로운 객체가 주로 할당되는 '새로운 공간(New-space)'의 가비지를 수집하는 마이너 가비지 컬렉션(Minor GC) 알고리즘입니다 [1-3]. 이 알고리즘은 공간을 두 개의 동일한 크기(to-space와 from-space)로 나누고 살아남은 활성 객체만 새로운 공간으로 복사하여 압축하는 세미스페이스(semi-space) 방식을 통해 메모리 단편화를 방지하고 매우 빠르게 메모리를 회수합니다 [3-5]. 최근의 V8 엔진에서는 Orinoco 프로젝트를 통해 메인 스레드와 헬퍼 스레드에 작업을 분산시키는 병렬(Parallel) 방식으로 진화하여 메인 스레드의 일시 정지 시간을 획기적으로 단축시켰습니다 [6-8].
-
-## 📖 구조화된 지식 (Synthesized Content)
-*   **세미스페이스(Semi-space) 설계 및 작동 원리:** V8의 새로운 공간(New-space 혹은 Young generation)은 Cheney의 알고리즘에 기반하여 'to-space'와 'from-space'라는 두 개의 동일한 크기의 세미스페이스로 나뉩니다 [3-5, 9]. 메모리 할당은 할당 포인터를 증가시키는 방식으로 빠르게 이루어지며, 할당 포인터가 공간의 끝에 도달하여 메모리가 부족해지면 Scavenge 주기가 트리거됩니다 [1, 5, 10].
-*   **활성 객체 대피(Evacuation) 및 압축(Compaction):** 가비지 컬렉션이 시작되면 루트 객체로부터 도달 가능한 활성 객체를 식별한 뒤, 이들을 from-space에서 to-space로 복사(대피)합니다 [3-5, 11]. 이 과정에서 객체들이 연속된 메모리 블록으로 압축되므로 캐시 지역성이 향상되고 메모리 단편화(Fragmentation)가 완전히 제거됩니다 [4, 11, 12]. 복사가 완료되면 남은 from-space의 데이터는 모두 가비지로 간주되어 버려지며, 두 공간의 역할이 교체됩니다 [11-15].
-*   **세대 가설에 따른 객체 승격 (Promotion):** Scavenger 알고리즘은 대부분의 객체가 일찍 소멸한다는 '세대 가설(Generational Hypothesis)'을 바탕으로 설계되었습니다 [1, 16]. 따라서 Scavenge 주기를 두 번 생존한 객체는 더 이상 새로운 공간에 머물지 않고 장기 보관을 위해 '오래된 공간(Old-space)'으로 승격(Promoted)됩니다 [1, 11, 17, 18].
-*   **쓰기 장벽 (Write Barriers)의 활용:** 오래된 공간(Old-space)의 객체가 새로운 공간(New-space)의 객체를 참조하는 경우를 식별하기 위해, V8은 전체 오래된 공간을 스캔하는 대신 '쓰기 장벽(Write Barriers)'을 활용하여 참조 포인터의 위치를 기억 집합(Store buffer 또는 Remembered set)에 기록합니다 [12, 14, 15, 19]. 이를 통해 Scavenge 수행 시 스캔 비용을 획기적으로 낮춥니다 [12, 14].
-*   **병렬 처리 (Parallel Scavenger):** 과거에는 Cheney 알고리즘을 사용한 단일 스레드 방식으로 동작했으나, 멀티코어 환경에 맞춰 V8(Orinoco 가비지 콜렉터)은 '병렬 Scavenger(Parallel Scavenger)'를 도입했습니다 [7, 20]. 메인 스레드와 여러 헬퍼 스레드가 포인터를 나누어 추적하고 동적으로 작업 훔치기(work stealing)를 수행하여, 결과적으로 메인 스레드에서 Scavenger가 소모하는 시간을 20%~50% 감소시켰습니다 [7, 8, 20, 21].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[Minor GC]], [[Young Generation]], [[Cheney's Algorithm]], [[Write Barriers]], [[Orinoco]]
-- **Projects/Contexts:** [[V8 엔진 메모리 관리 (V8 Memory Management)]], [[가비지 컬렉션 최적화]]
-- **Contradictions/Notes:** 과거 버전의 V8에서는 Scavenger가 단일 코어 환경에 적합한 완전한 동기식 Cheney 알고리즘을 구현했으나, 현재 크롬 및 Node.js의 멀티코어 환경 요구에 맞추어 메인 스레드와 워커 스레드가 동적으로 작업을 분배하는 병렬(Parallel) 복사 가비지 컬렉터로 진화했음이 기록되어 있습니다 [10, 20]. 
-
----
-*Last updated: 2026-04-19*
-- Raw Source: [[00_Raw/2026-04-20/Scavenger 알고리즘.md]]
----
diff --git a/Programming & Language/Scavenger(Minor GC).md b/Programming & Language/Scavenger(Minor GC).md
deleted file mode 100644
index 0381b89c..00000000
--- a/Programming & Language/Scavenger(Minor GC).md	
+++ /dev/null
@@ -1,30 +0,0 @@
----
-id: P-REINFORCE-AUTO-7DB27B
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Scavenger(Minor GC)"
----
-
-# [[Scavenger(Minor GC)]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> Scavenger(Minor GC)는 V8 엔진에서 새로운 객체가 할당되는 '새로운 공간(New-space)' 또는 '젊은 세대(Young Generation)'의 메모리를 빠르고 효율적으로 정리하기 위해 사용되는 가비지 컬렉션 메커니즘입니다 [1-3]. 이 알고리즘은 **"대부분의 객체는 생성된 직후 죽는다"는 세대적 가설(Generational hypothesis)**을 바탕으로 짧은 수명의 객체들을 신속하게 제거합니다 [2, 4, 5]. 빈번하게 발생하는 만큼 실행 속도가 매우 빠르며, 객체를 복사하고 이동하는 과정을 통해 메모리 단편화를 방지하는 핵심적인 역할을 합니다 [6-8].
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[Young Generation]], [[Mark-Sweep/Mark-Compact(Major GC)]], [[Write Barriers]], [[Cheney's Algorithm]], [[Orinoco GC]]
-- **Projects/Contexts:** [[V8 JavaScript Engine Memory Management]]
-- **Contradictions/Notes:** 과거 버전의 V8에서는 스캐빈저가 동기적인 Cheney's 알고리즘을 사용하였으나, V8 v6.2 이후부터는 다중 코어 환경의 이점을 살리기 위해 Halstead 알고리즘과 유사한 동적 작업 훔치기(work stealing) 기법을 사용하는 병렬 처리 구조로 진화했다는 점이 소스에 기록되어 있습니다 [22, 25].
-
----
-*Last updated: 2026-04-19*
-- Raw Source: [[00_Raw/2026-04-20/Scavenger(Minor GC).md]]
----
diff --git a/Programming & Language/Scavenger(마이너 GC).md b/Programming & Language/Scavenger(마이너 GC).md
deleted file mode 100644
index 61f90af3..00000000
--- a/Programming & Language/Scavenger(마이너 GC).md	
+++ /dev/null
@@ -1,37 +0,0 @@
----
-id: P-REINFORCE-AUTO-735166
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Scavenger(마이너 GC)"
----
-
-# [[Scavenger(마이너 GC)]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-*   **동작 원리와 체니의 알고리즘 (Cheney's Algorithm)**
-    대부분의 Scavenge 구현은 체니의 알고리즘(Cheney's algorithm)을 기반으로 한 반공간(semi-space) 설계를 따릅니다 [2, 4]. 새로운 공간은 크기가 같은 두 개의 공간인 To-Space와 From-Space로 나뉩니다 [4, 6, 7]. 평소에는 객체가 From-Space에 할당되다가 이 공간이 가득 차면, 가비지 컬렉터는 From-Space의 살아있는 객체들을 To-Space의 연속된 메모리 블록으로 대피(evacuate)시킵니다 [4, 5, 7]. 이후 죽은 객체들이 있는 From-Space는 완전히 비워지며 두 공간의 역할이 바뀝니다 [5, 8, 9].
-*   **객체 이동, 포인터 업데이트 및 승격 (Promotion)**
-    활성 객체가 새 위치로 이동될 때, 원래 위치에는 새로운 주소를 가리키는 포워딩 주소(forwarding address)가 남겨져 이를 참조하던 다른 포인터들이 업데이트될 수 있도록 합니다 [9-11]. 두 번의 마이너 가비지 컬렉션 주기(스캐빈지)를 생존한 객체들은 장기 보관을 위해 '오래된 공간(Old Space 또는 Tenure 영역)'으로 승격(Promoted)됩니다 [1, 3, 5]. 객체들을 To-Space의 한쪽으로 모으면서 단편화가 해결되므로 캐시 지역성이 향상되고 할당 속도가 유지됩니다 [4].
-*   **루트 스캔 및 병렬 처리 (Parallel Scavenging)**
-    마이너 GC는 매우 짧은 시간 내에 수행되어야 합니다 [4]. 이를 위해 V8 엔진은 다수의 도우미 스레드(helper threads)를 활용한 병렬 스캐빈징(Parallel scavenging) 기법을 사용하여, 루트 스캔, 젊은 세대 내의 객체 복사, 오래된 세대로의 승격, 포인터 업데이트 작업을 병렬적으로 처리합니다 [12-14]. 메인 스레드와 도우미 스레드들은 원자적(atomic)인 읽기/쓰기/비교 교환(compare-and-swap) 연산을 통해 동기화하여 동일한 객체가 중복 이동되는 것을 방지합니다 [12].
-*   **IBM SDK 환경에서의 스캐빈지**
-    IBM의 gencon GC 정책 등에서도 스캐빈지 작업이 존재하며, 이는 Nursery 영역에서 할당 실패가 발생할 때 트리거됩니다 [3]. 루트 스캔을 통해 도달 가능한 객체를 찾고 스택에 담은 뒤 계층적 스캔 순서(hierarchical scan ordering)를 사용해 추적하며, 살아있는 객체를 할당 공간에서 Survivor 공간이나 Tenure 영역으로 복사하는 방식으로 처리됩니다 [3].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[New Space(Young Generation)]], [[Cheney's Algorithm]], [[Promotion(승격)]], [[Major GC(Mark-Sweep/Mark-Compact)]]
-- **Projects/Contexts:** [[V8 JavaScript Engine]], [[IBM SDK (gencon GC policy)]]
-- **Contradictions/Notes:** 소스 간의 내용 모순은 발견되지 않았습니다. V8 엔진의 마이너 GC 메커니즘과 IBM SDK(gencon 정책)의 스캐빈지 작업은 구현 환경은 다르지만, 모두 '주로 새롭게 할당되는 작은 공간을 대상으로 하여 빠른 주기로 살아있는 객체를 복사 및 승격한다'는 공통된 역할을 성공적으로 수행하고 있습니다.
-
----
-*Last updated: 2026-04-19*
-- Raw Source: [[00_Raw/2026-04-20/Scavenger(마이너 GC).md]]
----
diff --git a/Programming & Language/Scheduler API.md b/Programming & Language/Scheduler API.md
deleted file mode 100644
index 697113a4..00000000
--- a/Programming & Language/Scheduler API.md	
+++ /dev/null
@@ -1,32 +0,0 @@
----
-id: P-REINFORCE-AUTO-6B64AB
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Scheduler API"
----
-
-# [[Scheduler API]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> Scheduler API는 개발자가 브라우저 내에서 다양한 처리 작업이 실행되는 시점을 더 쉽게 제어할 수 있도록 도와주는 기능입니다 [1]. 길게 실행되는 작업은 여러 개의 짧은 작업보다 상호작용 지연을 더 많이 유발하기 때문에, 이 API를 통해 작업을 분할하여 사용자 경험을 개선할 수 있습니다 [1]. 특히 작업 중간에 제어권을 브라우저에 양보함으로써 다른 중요한 상호작용이 지연 없이 우선적으로 처리될 수 있게 합니다 [1].
-
-## 📖 구조화된 지식 (Synthesized Content)
-- **도입 배경:** 브라우저에서의 CPU 처리는 사용자 경험에 큰 영향을 미치며, 중요도가 각기 다른 작업들이 실행될 때 긴 처리 작업은 여러 개의 짧은 작업들보다 사용자 상호작용 지연을 훨씬 더 많이 발생시킵니다 [1]. Scheduler API는 개발자가 이러한 다양한 작업이 실행되는 시기를 원활하게 제어할 수 있도록 돕습니다 [1].
-- **핵심 기능 (`scheduler.yield()`):** 개발자는 `scheduler.yield()` 메서드를 사용하여 작업(job) 중간에 브라우저의 스케줄러로 제어권을 쉽게 양보(yield)할 수 있습니다 [1]. 이를 통해 브라우저는 기존에 진행 중이던 작업을 마저 처리하기 전에, 사용자 상호작용 처리와 같은 다른 긴급한 작업을 먼저 다룰 수 있게 됩니다 [1].
-- **브라우저 지원 현황:** Chrome은 2024년에 이 새로운 API를 처음 도입했으며, 2025년 8월부터는 Firefox에서도 지원을 시작했습니다 [2]. 하지만 Safari는 아직 Scheduler API를 지원하지 않는 상태입니다 [2].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[scheduler.yield()]], [[Interaction to Next Paint (INP)]]
-- **Projects/Contexts:** [[Web Performance Optimization]]
-- **Contradictions/Notes:** 소스 내에 상충하는 정보는 없습니다. 다만, Chrome(2024년)과 Firefox(2025년 8월)는 해당 API를 지원하지만 Safari는 아직 지원하지 않는다는 호환성 제약이 명시되어 있습니다 [2].
-
----
-*Last updated: 2026-04-19*
-- Raw Source: [[00_Raw/2026-04-20/Scheduler API.md]]
----
diff --git a/Programming & Language/Schema-Driven-Development.md b/Programming & Language/Schema-Driven-Development.md
deleted file mode 100644
index 69bf58c8..00000000
--- a/Programming & Language/Schema-Driven-Development.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-DE27F0
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Schema-Driven-Development"
----
-
-# [[Schema-Driven-Development]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Schema-Driven-Development.md]]
----
diff --git a/Programming & Language/Schemaorg.md b/Programming & Language/Schemaorg.md
deleted file mode 100644
index b0d8b6d1..00000000
--- a/Programming & Language/Schemaorg.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-A3B261
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Schemaorg"
----
-
-# [[Schemaorg]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Schema.org.md]]
----
diff --git a/Programming & Language/Sensorimotor-Integration.md b/Programming & Language/Sensorimotor-Integration.md
deleted file mode 100644
index b8235935..00000000
--- a/Programming & Language/Sensorimotor-Integration.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-F9E556
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Sensorimotor-Integration"
----
-
-# [[Sensorimotor-Integration]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Sensorimotor-Integration.md]]
----
diff --git a/Programming & Language/Server Architecture.md b/Programming & Language/Server Architecture.md
deleted file mode 100644
index 2d79c9cc..00000000
--- a/Programming & Language/Server Architecture.md	
+++ /dev/null
@@ -1,30 +0,0 @@
----
-id: P-REINFORCE-AUTO-F7D840
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Server Architecture"
----
-
-# [[Server Architecture]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 소스에 관련 정보가 부족합니다.
-
-## 📖 구조화된 지식 (Synthesized Content)
-소스에 관련 정보가 부족합니다.
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** 소스에 관련 정보가 부족합니다.
-- **Projects/Contexts:** 소스에 관련 정보가 부족합니다.
-- **Contradictions/Notes:** 소스에 관련 정보가 부족합니다.
-
----
-*Last updated: 2026-04-18*
-- Raw Source: [[00_Raw/2026-04-20/Server Architecture.md]]
----
diff --git a/Programming & Language/SharedArrayBuffer vs postMessage 성능 차이.md b/Programming & Language/SharedArrayBuffer vs postMessage 성능 차이.md
deleted file mode 100644
index b46e45d1..00000000
--- a/Programming & Language/SharedArrayBuffer vs postMessage 성능 차이.md	
+++ /dev/null
@@ -1,49 +0,0 @@
----
-id: P-REINFORCE-AUTO-1B42F5
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - SharedArrayBuffer vs postMessage 성능 차이"
----
-
-# [[SharedArrayBuffer vs postMessage 성능 차이]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> `postMessage`는 데이터를 직렬화 및 역직렬화하여 스레드 간에 전달하기 때문에 통신 오버헤드가 발생하는 반면, `SharedArrayBuffer`는 두 스레드가 동일한 메모리 영역을 공유하여 **데이터 복사 비용 없이 0의 오버헤드와 극도로 낮은 지연 시간**을 달성하는 기술입니다.
-
-## 📖 구조화된 지식 (Synthesized Content)
-**1. 데이터 전송 및 복사 메커니즘**
-
-- **postMessage**: 기본적으로 데이터를 다른 스레드로 보낼 때 구조화된 복제(Structured Clone) 알고리즘을 통해 **데이터를 직렬화(Serialization)하고 역직렬화하는 과정**을 거칩니다. 이 과정에서 데이터가 복사되므로, 전달하는 페이로드의 크기에 비례하여 메모리 및 CPU 비용이 증가합니다. (단, Transferable Objects를 사용하면 복사 없이 소유권을 이전할 수 있으나, 전송 후 원래 스레드에서는 해당 객체에 접근할 수 없게 됩니다).
-- **SharedArrayBuffer**: 두 스레드가 **완전히 동일한 메모리 주소 공간을 공유**합니다. 데이터를 한쪽 스레드에서 쓰면 다른 스레드에서 즉시 읽을 수 있기 때문에, **데이터 복사나 이동이 전혀 발생하지 않습니다**.
-
-**2. 성능 및 지연 시간 (Latency)**
-
-- **postMessage**: 메시지 패싱 과정에서 **약 5~10ms의 통신 오버헤드**가 발생할 수 있습니다. 특히 매 프레임마다 수천 개의 엔티티 위치 값이나 큰 JSON 객체를 주고받아야 하는 게임 환경에서는 이 오버헤드가 심각한 성능 병목(Bottleneck)으로 작용하여 프레임 드랍을 유발할 수 있습니다.
-- **SharedArrayBuffer**: 스레드 간 통신 지연 시간이 **극도로 낮습니다(가장 빠름)**. 데이터 직렬화 비용이 '0'이므로 속도와 메모리 효율성 측면에서 가장 압도적인 성능을 발휘하며, 원자적 연산(Atomic operations)을 지원하여 동시성 문제 없이 고속으로 데이터를 처리할 수 있습니다.
-
-**3. 개발 편의성 및 구현 복잡도**
-
-- **postMessage**: 구현 복잡도가 낮으며(Low), 개발자에게 익숙한 자바스크립트 일반 객체나 JSON 구조를 그대로 다룰 수 있어 **매우 직관적이고 친화적**입니다.
-- **SharedArrayBuffer**: 구현 복잡도가 매우 높습니다(High). JSON과 같은 구조화된 데이터 대신 **원시 이진 데이터(Raw Binary Data) 버퍼**를 직접 제어하고 관리해야 하므로, 아주 저수준(Low-level)의 프로그래밍이 요구됩니다.
-
-**4. 적합한 사용 사례 (Use Cases)**
-
-- **postMessage**: 크기가 작거나 가끔씩 전송되는 이벤트, 혹은 결과 도출에 시간이 걸리는 일반적인 비동기 연산의 결과를 받을 때 적합합니다.
-- **SharedArrayBuffer**: ECS(Entity-Component-System) 아키텍처 등에서 수많은 객체의 컴포넌트 데이터를 담고, 물리 엔진(워커 스레드)의 연산 결과를 렌더링 루프(메인 스레드)가 **매 프레임 즉각적으로 읽어가야 하는 고성능 게임 엔진** 구현에 필수적입니다.
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[Web Worker]], [[직렬화(Serialization) 및 병목 현상]], [[Transferable Objects]], [[Data-Oriented Design (ECS)]], [[원자적 연산(Atomic Operations)]]
-- **Projects/Contexts:** [[멀티스레드 기반 고성능 React 게임 엔진]], [[실시간 물리 시뮬레이션 동기화]]
-- **Contradictions/Notes:** `postMessage`도 `ArrayBuffer` 등을 Transferable 객체로 전달하면 직렬화 오버헤드를 거의 0으로 만들 수 있습니다. 그러나 이는 '소유권 이전' 방식이므로 두 스레드가 "동시에 데이터를 읽고 쓰는" 양방향 공유(Shared)가 불가능하다는 점에서 `SharedArrayBuffer`와 결정적인 차이를 가집니다.
-
----
-
-_Last updated: 2026-04-14_
-- Raw Source: [[00_Raw/2026-04-20/SharedArrayBuffer vs postMessage 성능 차이.md]]
----
diff --git a/Programming & Language/SharedArrayBuffer 동시성 문제 해결법.md b/Programming & Language/SharedArrayBuffer 동시성 문제 해결법.md
deleted file mode 100644
index 71059279..00000000
--- a/Programming & Language/SharedArrayBuffer 동시성 문제 해결법.md	
+++ /dev/null
@@ -1,38 +0,0 @@
----
-id: P-REINFORCE-AUTO-918534
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - SharedArrayBuffer 동시성 문제 해결법"
----
-
-# [[SharedArrayBuffer 동시성 문제 해결법]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> `SharedArrayBuffer`는 여러 스레드가 동일한 메모리 영역을 동시에 공유하기 때문에 데이터 경쟁 상태(Data Race)가 발생할 수 있으며, 이를 해결하기 위해 **원자적 연산(Atomic operations)** 지원을 활용하거나 **아키텍처 설계(ECS 등)**를 통해 스레드 간의 읽기/쓰기 역할을 명확히 분리해야 합니다.
-
-## 📖 구조화된 지식 (Synthesized Content)
-**1. 원자적 연산 (Atomic Operations) 활용** `SharedArrayBuffer`는 메인 스레드와 워커 스레드 등 서로 다른 컨텍스트에서 데이터를 복사 없이 공유할 수 있도록 지원하며, 동시 접근으로 인한 충돌을 막기 위해 원자적 연산(Atomic operations)을 지원합니다. _(※ 외부 지식 참고: 자바스크립트에서는 이를 위해 내장된 `Atomics` 전역 객체를 사용합니다. `Atomics.load()`, `Atomics.store()`, `Atomics.add()`, `Atomics.compareExchange()` 등의 API를 사용하면 특정 메모리 주소에 대한 읽기와 쓰기가 중간에 끊기지 않는 '단일 연산'으로 보장되어 안전하게 데이터를 제어할 수 있습니다.)_
-
-**2. 스레드 동기화 제어 (Lock / Wait 메커니즘)** _(※ 외부 지식 참고: 동시성 충돌을 더욱 엄격하게 제어해야 할 경우 `Atomics.wait()`와 `Atomics.notify()`를 활용해 특정 스레드를 대기 상태로 만들고 작업이 끝난 후 깨우는 방식(Lock, Mutex 패턴)을 구현하여 다중 스레드의 접근 순서를 동기화할 수 있습니다.)_
-
-**3. 아키텍처적 해결: ECS(Entity Component System)를 통한 읽기/쓰기 역할 분리** 가장 효율적인 방식은 엔진 구조 자체에서 데이터의 단방향 흐름을 강제하여 충돌을 회피하는 것입니다. 고성능 게임 엔진 아키텍처에서는 ECS의 컴포넌트 데이터를 `SharedArrayBuffer`에 할당한 후, 스레드의 역할을 엄격하게 분리합니다.
-
-- **쓰기(Write) 전담 스레드:** 웹 워커(Web Worker)는 백그라운드에서 물리 연산이나 AI 로직 등을 수행하며 버퍼의 데이터를 업데이트(Write)합니다.
-- **읽기(Read) 전담 스레드:** 메인 스레드(React 및 렌더링 루프)는 렌더링 시점에 버퍼에서 데이터를 즉시 읽어와(Read) 복사 비용 없이 WebGL/Three.js 메시의 속성에 반영합니다. 이러한 데이터 지향 설계(Data-Oriented Design)를 채택하면 여러 스레드가 동일한 데이터에 동시에 쓰기 작업을 하는 상황을 구조적으로 방지할 수 있습니다.
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[Web Worker]], [[Atomics API]], [[경쟁 상태 (Race Condition)]], [[Data-Oriented Design (ECS)]]
-- **Projects/Contexts:** [[멀티스레드 React WebGL 애플리케이션]], [[고성능 실시간 상호작용 시스템]]
-- **Contradictions/Notes:** `SharedArrayBuffer`는 지연 시간을 극도로 낮추고 복사 비용을 '0'으로 만들지만, 로우 레벨의 이진 데이터 버퍼를 직접 다뤄야 하고 `Atomics`로 동시성을 관리해야 하므로 구현 복잡도가 매우 높습니다 [264, 895, 이전 대화 내용 참조]. 따라서 충돌 제어와 개발 편의성이 더 중요한 일반적인 경우에는 Valtio 등 프록시(Proxy)를 사용해 `BroadcastChannel`이나 `postMessage`로 변경점(Delta)만 동기화하는 메시지 기반 패턴이 더 직관적일 수 있습니다.
-
----
-
-_Last updated: 2026-04-14_
-- Raw Source: [[00_Raw/2026-04-20/SharedArrayBuffer 동시성 문제 해결법.md]]
----
diff --git a/Programming & Language/SharedArrayBuffer 보안 이슈와 Cross-Origin Isolation.md b/Programming & Language/SharedArrayBuffer 보안 이슈와 Cross-Origin Isolation.md
deleted file mode 100644
index e45f235b..00000000
--- a/Programming & Language/SharedArrayBuffer 보안 이슈와 Cross-Origin Isolation.md	
+++ /dev/null
@@ -1,40 +0,0 @@
----
-id: P-REINFORCE-AUTO-C3F189
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - SharedArrayBuffer 보안 이슈와 Cross-Origin Isolation"
----
-
-# [[SharedArrayBuffer 보안 이슈와 Cross-Origin Isolation]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> `SharedArrayBuffer`는 스펙터(Spectre)와 같은 CPU 취약점을 악용한 타이밍 공격(Timing Attack)의 위험이 있어 브라우저에서 사용이 제한되며, 이를 다시 활성화하려면 웹 서버에 **Cross-Origin Isolation(교차 출처 격리) 보안 헤더**를 명시적으로 설정하여 안전한 환경을 구축해야 합니다.
-
-## 📖 구조화된 지식 (Synthesized Content)
-**1. 보안 이슈의 배경: 스펙터(Spectre) 취약점** `SharedArrayBuffer`는 두 스레드가 메모리를 공유하면서 매우 정밀한 고해상도 타이머를 만들 수 있게 해줍니다. 해커들은 이를 악용하여 최신 CPU의 예측 실행(Speculative Execution) 과정에서 발생하는 미세한 시간 차이를 측정하고, 결과적으로 같은 브라우저 프로세스 내에 로드된 다른 사이트의 비밀번호 등 **민감한 메모리 데이터를 탈취하는 스펙터(Spectre) 취약점**을 발견했습니다. 이 치명적인 보안 결함 때문에 브라우저 벤더들은 2018년경 이 기능을 일괄 비활성화했습니다.
-
-**2. Cross-Origin Isolation (교차 출처 격리) 도입** 이후 브라우저들은 멀티스레딩의 성능적 이점을 포기할 수 없었기에, 현재 실행 중인 웹 페이지가 신뢰할 수 없는 외부의 다른 사이트(Origin) 리소스와 철저히 분리된 안전한 환경에서만 `SharedArrayBuffer`를 다시 사용할 수 있도록 정책을 변경했습니다. 이 격리된 환경을 **'Cross-Origin Isolated'** 상태라고 부릅니다.
-
-**3. COOP 및 COEP HTTP 헤더 설정법** 웹 애플리케이션에서 `SharedArrayBuffer`를 활성화하려면, 서버 측(Nginx, Apache, Node.js Express, Vercel, AWS CloudFront 등)에서 HTML 문서를 응답할 때 반드시 다음 **두 가지 HTTP 보안 헤더**를 내려보내야 합니다.
-
-- **`Cross-Origin-Opener-Policy: same-origin` (COOP):** 현재 문서와 다른 출처를 가진 팝업창이나 외부 문서가 서로의 `window` 객체에 접근하지 못하도록 브라우징 실행 컨텍스트를 분리합니다.
-- **`Cross-Origin-Embedder-Policy: require-corp` (COEP):** 명시적으로 승인받지 않은 다른 출처의 리소스(외부 이미지, 스크립트, iframe 등)가 현재 페이지에 임베드되는 것을 원천적으로 차단합니다.
-
-**4. 설정 시 발생할 수 있는 사이드 이펙트 및 주의사항** 위 헤더를 적용하여 고성능 환경을 얻는 대신, 보안 격리가 너무 엄격해져서 **기존에 잘 작동하던 외부 CDN 스크립트나 외부 이미지 등이 차단되는 문제**가 발생할 수 있습니다. 이를 해결하기 위해서는 외부 리소스를 제공하는 서버 측에서 `Cross-Origin-Resource-Policy: cross-origin` (CORP) 헤더나 적절한 CORS 설정(`Access-Control-Allow-Origin`)을 제공해야 하며, 클라이언트의 HTML 태그에도 `<img src="..." crossorigin="anonymous">`와 같이 명시적인 속성을 추가해 주어야 합니다.
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[Spectre & Meltdown 취약점]], [[CORS (Cross-Origin Resource Sharing)]], [[HTTP Security Headers (COOP, COEP, CORP)]], [[Web Worker 멀티스레딩 통신]]
-- **Projects/Contexts:** [[보안 격리 환경에서의 고성능 웹 게임 개발]], [[멀티스레드 기반 렌더링 파이프라인(React Three Fiber)]]
-- **Contradictions/Notes:** 로컬 개발 환경(`localhost` 또는 `127.0.0.1`)에서는 개발 편의상 Cross-Origin Isolation 헤더 없이도 `SharedArrayBuffer`가 임시로 동작할 수 있으나, 실제 프로덕션(HTTPS 환경)에 배포할 때는 반드시 헤더 설정이 필요합니다.
-
----
-
-_Last updated: 2026-04-14_
-- Raw Source: [[00_Raw/2026-04-20/SharedArrayBuffer 보안 이슈와 Cross-Origin Isolation.md]]
----
diff --git a/Programming & Language/SharedArrayBuffer 보안을 위한 COOP COEP 헤더 설정.md b/Programming & Language/SharedArrayBuffer 보안을 위한 COOP COEP 헤더 설정.md
deleted file mode 100644
index d203abf3..00000000
--- a/Programming & Language/SharedArrayBuffer 보안을 위한 COOP COEP 헤더 설정.md	
+++ /dev/null
@@ -1,40 +0,0 @@
----
-id: P-REINFORCE-AUTO-01AE3D
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - SharedArrayBuffer 보안을 위한 COOP COEP 헤더 설정"
----
-
-# [[SharedArrayBuffer 보안을 위한 COOP COEP 헤더 설정]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> `SharedArrayBuffer`의 보안 취약점을 방지하고 스레드 간 안전한 메모리 공유를 수행하기 위해, 웹 서버에서 응답 시 브라우저의 교차 출처 격리(Cross-Origin Isolation)를 활성화하는 필수 HTTP 보안 헤더 설정 기법입니다.
-
-## 📖 구조화된 지식 (Synthesized Content)
-_(안내: 제공된 소스 자료에서는 `SharedArrayBuffer`가 복사 비용이 0이며 매우 낮은 지연 시간으로 스레드 간 메모리를 공유하는 고성능 데이터 구조라는 점만 언급되어 있습니다. 따라서 구체적인 보안 취약점 이슈 및 COOP/COEP 헤더 설정법은 **이전 대화 기록 및 외부 지식을 바탕으로 작성**되었으므로 실제 환경 적용 시 독립적인 교차 검증을 권장합니다.)_
-
-**1. 교차 출처 격리(Cross-Origin Isolation)의 필요성** `SharedArrayBuffer`는 서로 다른 스레드(컨텍스트)에서 원자적 연산을 통해 데이터를 복사 없이 공유할 수 있도록 지원합니다. 그러나 이 정밀한 메모리 공유 기능을 악용하여 다른 출처(Origin)의 민감한 데이터를 탈취하는 스펙터(Spectre) 타이밍 공격이 가능합니다. 브라우저는 이를 막기 위해 현재 페이지를 외부 출처로부터 철저히 분리(Isolation)하는 안전한 환경에서만 `SharedArrayBuffer` 생성을 허용합니다.
-
-**2. 서버의 필수 HTTP 응답 헤더 설정** 안전한 교차 출처 격리 상태를 켜려면 웹 서버(Node.js, Nginx, Vercel 등)에서 HTML을 응답할 때 다음 두 가지 헤더를 반드시 설정해야 합니다.
-
-- **COOP (Cross-Origin-Opener-Policy): `same-origin`** 이 헤더는 현재 문서가 다른 교차 출처 문서(예: 타 사이트가 연 팝업창)와 브라우징 컨텍스트 그룹을 공유하지 못하도록 차단하여 공격자의 간섭을 막습니다.
-- **COEP (Cross-Origin-Embedder-Policy): `require-corp`** (또는 `credentialless`) 이 헤더는 명시적인 보안 허락(CORS나 CORP 헤더)을 받지 않은 모든 외부 리소스(이미지, 외부 스크립트, iframe 등)가 내 페이지에 로드되는 것을 원천 차단합니다.
-
-**3. 브라우저 내 활성화 확인** 서버 측에서 위 두 헤더가 정상적으로 응답되었다면, 브라우저 자바스크립트 환경에서 `crossOriginIsolated` 전역 변수가 `true`로 평가됩니다. 이 값이 `true`일 때만 에러 없이 `new SharedArrayBuffer()`를 호출하여 고성능 메모리 버퍼를 할당할 수 있습니다.
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[Cross-Origin Isolation (COI)]], [[HTTP Security Headers (COOP/COEP)]], [[Spectre 취약점 부채널 공격]], [[CORS 및 CORP 설정]]
-- **Projects/Contexts:** [[보안이 강화된 고성능 WebGL/멀티스레드 게임 엔진 배포]]
-- **Contradictions/Notes:** COOP와 COEP 헤더를 적용하면 엔진의 성능을 최대로 끌어올릴 수 있지만, 반대급부로 기존에 제약 없이 로드되던 외부 CDN 이미지나 타사 분석 스크립트가 브라우저에 의해 렌더링 차단되는 심각한 부작용이 생길 수 있습니다. 이를 우회하려면 외부 리소스 태그에 `crossorigin="anonymous"` 속성을 달고, 리소스 제공 서버가 적절한 접근 제어 헤더를 함께 내려주어야 하는 인프라적 제약이 따릅니다.
-
----
-
-_Last updated: 2026-04-14_
-- Raw Source: [[00_Raw/2026-04-20/SharedArrayBuffer 보안을 위한 COOP, COEP 헤더 설정.md]]
----
diff --git a/Programming & Language/SharedArrayBuffer 보안을 위한 Cross-Origin Isolation 서버 헤더 설정.md b/Programming & Language/SharedArrayBuffer 보안을 위한 Cross-Origin Isolation 서버 헤더 설정.md
deleted file mode 100644
index b047cea0..00000000
--- a/Programming & Language/SharedArrayBuffer 보안을 위한 Cross-Origin Isolation 서버 헤더 설정.md	
+++ /dev/null
@@ -1,43 +0,0 @@
----
-id: P-REINFORCE-AUTO-32CC81
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - SharedArrayBuffer 보안을 위한 Cross-Origin Isolation 서버 헤더 설정"
----
-
-# [[SharedArrayBuffer 보안을 위한 Cross-Origin Isolation 서버 헤더 설정]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> `SharedArrayBuffer`의 스펙터(Spectre) 취약점을 악용한 메모리 유출 공격을 방지하기 위해, 웹 서버에서 응답 시 **COOP 및 COEP HTTP 보안 헤더**를 설정하여 브라우저의 교차 출처 격리(Cross-Origin Isolation) 상태를 활성화하는 서버 설정 방법입니다.
-
-## 📖 구조화된 지식 (Synthesized Content)
-**1. Cross-Origin Isolation(교차 출처 격리)의 필요성** `SharedArrayBuffer`는 스레드 간 원자적 연산과 메모리 공유를 지원하지만, 이를 악용하면 타이밍 공격(Spectre)을 통해 브라우저 내 다른 사이트의 민감한 데이터를 탈취할 수 있습니다. 브라우저 벤더들은 이를 막기 위해 현재 페이지가 신뢰할 수 없는 외부 출처(Origin) 리소스와 철저히 분리된 안전한 **'Cross-Origin Isolated'** 환경에서만 객체 생성을 허용하도록 보안 정책을 강화했습니다.
-
-**2. 필수 HTTP 응답 헤더 설정 (COOP / COEP)** 이 격리 환경을 활성화하려면, HTML을 제공하는 웹 서버(Node.js Express, Nginx, Vercel 등)의 응답 헤더(Response Headers)에 다음 두 가지를 반드시 추가해야 합니다.
-
-- **`Cross-Origin-Opener-Policy: same-origin` (COOP):** 현재 최상위 문서가 다른 교차 출처 문서(예: 타 사이트에서 열린 팝업창 등)와 브라우징 실행 컨텍스트를 공유하지 못하도록 차단하여 외부 간섭을 막습니다.
-- **`Cross-Origin-Embedder-Policy: require-corp` (COEP):** (경우에 따라 `credentialless` 사용 가능) 명시적인 보안 승인(CORS 또는 CORP 헤더)을 받지 않은 외부 리소스(외부 CDN 스크립트, 이미지, iframe 등)가 현재 페이지에 임베드(Embed)되는 것을 원천적으로 차단합니다.
-
-**3. 브라우저 활성화 검증** 서버 헤더가 올바르게 설정되어 페이지가 로드되면, 클라이언트의 자바스크립트 환경에서 전역 속성인 **`crossOriginIsolated`가 `true`를 반환**합니다. 이 상태에서만 오류 없이 `new SharedArrayBuffer()`를 호출할 수 있습니다.
-
-**4. 헤더 적용 시 발생하는 사이드 이펙트와 해결책** 이 보안 정책은 매우 엄격하여 **기존에 정상적으로 불러오던 외부 이미지나 서드파티 스크립트(Google Analytics 등)가 브라우저에 의해 렌더링 차단되는 심각한 부작용**이 발생할 수 있습니다. 이를 우회하고 해결하려면:
-
-- HTML 내 모든 외부 리소스 태그(예: `<img>`, `<script>`)에 `crossorigin="anonymous"` 속성을 추가해야 합니다.
-- 해당 외부 리소스를 제공하는 서버 측에서 `Access-Control-Allow-Origin` (CORS) 또는 `Cross-Origin-Resource-Policy: cross-origin` (CORP) 응답 헤더를 함께 내려주어야 합니다.
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[Spectre 부채널 공격 (Side-Channel Attack)]], [[HTTP Security Headers (COOP/COEP/CORP)]], [[CORS (Cross-Origin Resource Sharing)]], [[Web Worker Multi-threading]]
-- **Projects/Contexts:** [[보안이 강화된 고성능 WebGL/React 게임 엔진 배포 환경 구축]]
-- **Contradictions/Notes:** 로컬 개발 환경(`localhost` 또는 `127.0.0.1`)에서는 개발 편의를 위해 COOP/COEP 헤더 없이도 `SharedArrayBuffer`가 일시적으로 동작할 수 있습니다. 하지만 실제 도메인이 연결된 프로덕션(HTTPS) 환경으로 배포할 때는 서버 헤더 설정이 누락되면 즉시 앱이 중단되므로 인프라 수준에서의 꼼꼼한 설정이 필요합니다.
-
----
-
-_Last updated: 2026-04-14_
-- Raw Source: [[00_Raw/2026-04-20/SharedArrayBuffer 보안을 위한 Cross-Origin Isolation 서버 헤더 설정.md]]
----
diff --git a/Programming & Language/SharedArrayBuffer로 스레드 간 메모리 공유 효율 높이기.md b/Programming & Language/SharedArrayBuffer로 스레드 간 메모리 공유 효율 높이기.md
deleted file mode 100644
index cbf86a0a..00000000
--- a/Programming & Language/SharedArrayBuffer로 스레드 간 메모리 공유 효율 높이기.md	
+++ /dev/null
@@ -1,37 +0,0 @@
----
-id: P-REINFORCE-AUTO-4A9AE0
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - SharedArrayBuffer로 스레드 간 메모리 공유 효율 높이기"
----
-
-# [[SharedArrayBuffer로 스레드 간 메모리 공유 효율 높이기]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> **SharedArrayBuffer**는 웹 워커(Web Worker)와 메인 스레드 간의 전통적인 통신 방식인 `postMessage`의 데이터 직렬화(Serialization) 및 복사 오버헤드를 제거하고, **두 스레드가 동일한 메모리 영역을 복사 없이(Zero-copy) 직접 접근하고 공유**할 수 있게 해주는 저수준(Low-level)의 고성능 최적화 기법입니다.
-
-## 📖 구조화된 지식 (Synthesized Content)
-**1. 직렬화(Serialization) 병목 제거** 자바스크립트 환경에서 메인 스레드와 워커 스레드는 기본적으로 메모리를 공유하지 않기 때문에, 데이터를 주고받으려면 내부적으로 데이터를 복사하고 직렬화/역직렬화하는 과정을 거쳐야 합니다. 그러나 `SharedArrayBuffer`를 사용하면 이러한 복사 과정 없이 데이터가 포함된 원시 바이너리 버퍼 자체를 공유하므로, 메모리 전송에 소모되는 지연 시간(오버헤드)이 '0'에 가까워집니다.
-
-**2. ECS(Entity Component System) 기반 아키텍처와의 시너지** 이 기술은 `bitECS`와 같은 고성능 게임 아키텍처 패턴(ECS)과 결합할 때 진가를 발휘합니다. 게임 내 수만 개의 엔티티(파티클, 총알, 적 등) 정보를 무거운 자바스크립트 객체 대신 연속된 메모리 블록인 `TypedArray` 구조로 구성한 뒤, 이를 `SharedArrayBuffer`에 적재합니다.
-
-- **워커 스레드(물리 엔진/AI):** 물리 연산을 수행하여 버퍼 내의 좌표($x, y, z$) 데이터를 업데이트합니다.
-- **메인 스레드(React/Three.js):** 메시지 수신을 기다릴 필요 없이, 버퍼의 메모리 주소를 즉시 읽어와 `InstancedMesh` 등을 60FPS로 렌더링합니다.
-
-**3. Atomics API를 통한 원자적(Atomic) 동기화 보장** 여러 스레드가 동시에 동일한 메모리 공간에 읽기/쓰기를 수행하면 데이터가 꼬이는 경쟁 상태(Race Condition)가 발생할 수 있습니다. `SharedArrayBuffer`는 `Atomics` 객체에서 제공하는 원자적 연산을 지원하여, 스레드 간에 안전하게 메모리를 조작하고 동기화할 수 있도록 보장합니다.
-
-**4. 한계점 및 개발 트레이드오프 (Trade-offs)**
-
-- **매우 낮은 추상화 수준:** 일반적인 JSON 객체나 유연한 자바스크립트 데이터 구조를 사용할 수 없으며, 바이트 단위의 로우 레벨 바이너리 버퍼를 직접 계산하고 다뤄야 하므로 개발 난이도가 매우 높고 사용자 친화적이지 않습니다.
-- **보안 제약 (COOP/COEP):** 멜트다운(Meltdown) 및 스펙터(Spectre)와 같은 CPU 보안 취약점을 방지하기 위해, 웹 서버에서 보안 헤더(`Cross-Origin-Opener-Policy` 및 `Cross-Origin-Embedder-Policy`)를 엄격하게 설정해야만 브라우저에서 `SharedArrayBuffer` 기능을 활성화할 수 있습니다. (※ 이 내용은 제공된 소스 외부의 일반적인 웹 보안 지식입니다. 실제 도입 시 서버 설정 확인이 필요합니다.)
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/SharedArrayBuffer로 스레드 간 메모리 공유 효율 높이기.md]]
----
diff --git a/Programming & Language/SharedArrayBuffer와 Atomics 구체적 활용법.md b/Programming & Language/SharedArrayBuffer와 Atomics 구체적 활용법.md
deleted file mode 100644
index 8b80669c..00000000
--- a/Programming & Language/SharedArrayBuffer와 Atomics 구체적 활용법.md	
+++ /dev/null
@@ -1,72 +0,0 @@
----
-id: P-REINFORCE-AUTO-0A2C98
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - SharedArrayBuffer와 Atomics 구체적 활용법"
----
-
-# [[SharedArrayBuffer와 Atomics 구체적 활용법]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> `SharedArrayBuffer`를 통해 다중 스레드에서 공유되는 메모리에 접근할 때 데이터 경쟁(Data Race)을 막기 위해, 자바스크립트 내장 객체인 `Atomics`의 정적 메서드들을 활용하여 안전하게 데이터를 읽고 쓰고 동기화하는 기법입니다.
-
-## 📖 구조화된 지식 (Synthesized Content)
-제공된 소스 자료에서는 `SharedArrayBuffer`가 스레드 간 복사 비용 없이 데이터를 공유하고 원자적 연산(Atomic operations)을 지원하여 고성능 환경에 적합하다는 점을 설명하고 있습니다. **다만 구체적인 자바스크립트 `Atomics` API의 사용법은 소스 자료에 포함되어 있지 않아, 아래의 구현 방법 및 코드는 외부 지식을 바탕으로 설명해 드립니다.**
-
-**1. 공유 메모리와 뷰(View) 생성** `SharedArrayBuffer`는 원시 이진 데이터이므로, 값을 조작하려면 `Int32Array`와 같은 타입화된 배열(TypedArray) 뷰를 씌워야 합니다.
-
-```
-// 메인 스레드에서 생성
-const buffer = new SharedArrayBuffer(1024); // 1024 바이트 메모리 할당
-const sharedArray = new Int32Array(buffer);
-// 이후 이 buffer를 웹 워커로 postMessage를 통해 전달하여 메모리 공간을 공유합니다.
-```
-
-**2. 안전한 읽기와 쓰기 (`Atomics.store` & `Atomics.load`)** 일반적인 배열 접근 방식(`sharedArray = 5`)은 다른 스레드의 접근과 겹칠 경우 안전하지 않을 수 있습니다. 읽고 쓰는 작업이 중단 없이 한 번의 사이클 내에 완전히 끝남을 보장하려면 `Atomics`를 사용해야 합니다.
-
-```
-// 쓰기 (예: 워커 스레드에서 물리 연산 후 상태 업데이트)
-Atomics.store(sharedArray, 0, 123); // 인덱스 0에 123을 안전하게 기록
-
-// 읽기 (예: 메인 스레드에서 렌더링을 위해 최신 값 읽기)
-const value = Atomics.load(sharedArray, 0);
-```
-
-**3. 원자적 데이터 갱신 (`Atomics.add`, `Atomics.sub`, `Atomics.exchange`)** 여러 스레드가 동시에 같은 인덱스의 값을 증가시켜야 할 때, 중간에 값을 가로채어 생기는 덮어쓰기 충돌(Race Condition)을 원천적으로 방지합니다.
-
-```
-// sharedArray의 값을 안전하게 1 증가시킴 (반환값은 더하기 전의 이전 값)
-Atomics.add(sharedArray, 1, 1);
-
-// 값을 지정된 새로운 값으로 즉시 교체
-Atomics.exchange(sharedArray, 2, 99);
-```
-
-**4. 스레드 동기화와 락 메커니즘 (`Atomics.wait` & `Atomics.notify`)** 특정 스레드가 작업을 수행하기 전에 데이터가 특정 상태가 될 때까지 대기(블로킹)하도록 만들고, 다른 스레드가 작업을 완료하면 대기 중인 스레드를 깨우는 방식입니다. (주의: 브라우저 UI 멈춤을 방지하기 위해 메인 스레드에서는 `wait` 호출이 금지되어 있으며 주로 백그라운드 워커 스레드에서 사용됩니다.)
-
-```
-// 워커 스레드 A (대기)
-// sharedArray의 값이 0이면 대기 모드 진입. 다른 스레드가 깨워줄 때까지 멈춤.
-Atomics.wait(sharedArray, 3, 0);
-
-// 워커 스레드 B (실행 완료 후 깨우기)
-Atomics.store(sharedArray, 3, 1); // 값을 1로 변경하고 상태 업데이트
-Atomics.notify(sharedArray, 3, 1); // 인덱스 3에서 대기 중인 스레드 1개를 깨움
-```
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[SharedArrayBuffer]], [[Web Worker]], [[Data Race (데이터 경쟁)]], [[Lock / Mutex 동기화 패턴]]
-- **Projects/Contexts:** [[고성능 실시간 상호작용 시스템]], [[멀티스레드 React 게임 엔진 아키텍처]]
-- **Contradictions/Notes:** `SharedArrayBuffer`와 `Atomics`는 메모리 복사를 없애 지연 시간을 극도로 낮추는 최적의 수단이지만, 원시 이진 데이터를 직접 제어해야 하므로 구현 난이도가 매우 높습니다. 따라서 실무에서는 개발 편의성을 위해 직렬화 오버헤드를 어느 정도 감수하더라도 `Valtio` 같은 프록시 객체를 통한 메시지 패싱 방식을 선택하거나, 이진 데이터를 추상화해 둔 `bitECS` 같은 고성능 라이브러리를 활용하는 경우가 많습니다.
-
----
-
-_Last updated: 2026-04-14_
-- Raw Source: [[00_Raw/2026-04-20/SharedArrayBuffer와 Atomics 구체적 활용법.md]]
----
diff --git a/Programming & Language/Side-channel Attack.md b/Programming & Language/Side-channel Attack.md
deleted file mode 100644
index 86dc2309..00000000
--- a/Programming & Language/Side-channel Attack.md	
+++ /dev/null
@@ -1,33 +0,0 @@
----
-id: P-REINFORCE-AUTO-624D09
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Side-channel Attack"
----
-
-# [[Side-channel Attack]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 부채널 공격(Side-channel Attack)은 하드웨어의 투기적 실행(Speculative execution)이나 캐시 접근 시간과 같은 물리적 작동 특성에서 발생하는 정보 유출을 악용하는 보안 취약점입니다 [1-3]. 공격자는 고정밀 타이밍 측정을 통해 캐시 적중률이나 메모리 접근 패턴을 관찰하여, 본래 접근이 제한된 시스템의 비밀 메모리 영역을 유추하고 읽어낼 수 있습니다 [3-5]. 웹 브라우저 환경에서는 이러한 공격이 기존의 보안 검사(경계 및 타입 검사 등)를 우회할 수 있어, 브라우저 벤더들이 타이머 정밀도 감소 및 분기 없는 보안 검사 등의 방어책을 도입하게 되었습니다 [6-8].
-
-## 📖 구조화된 지식 (Synthesized Content)
-- **공격 원리 및 캐시 타이밍 (Cache Timing):** 웹 브라우저에서의 부채널 공격은 주로 L1 캐시와 메인 메모리 접근 시간 사이의 미세한 타이밍 차이를 관찰하는 고정밀 타이밍(High-fidelity timing)에 의존합니다 [2, 3]. 공격자는 타이밍 기반의 정보 유출(Timing-based information leak)을 통해 메모리 접근 패턴을 유추하고, 결과적으로 범위를 벗어난(out-of-bounds) 메모리의 내용을 알아낼 수 있습니다 [4, 8]. 
-- **Spectre와 Meltdown 취약점:** 대표적인 부채널 공격인 Spectre는 공격자가 분기문(branches)을 제어하고 투기적 실행(Speculative execution)을 악용하여, JavaScriptCore와 같은 언어 가상 머신의 경계 검사(bounds check) 및 타입 검사(type check)를 우회하게 만듭니다 [1, 3, 8]. 이를 통해 신뢰할 수 없는 JavaScript나 WebAssembly 코드가 호스트 프로세스의 전체 주소 공간을 읽어낼 수 있는 이론적 경로를 제공합니다 [9]. 
-- **GPU 및 그래픽 파이프라인에서의 위협:** `EXT_disjoint_timer_query`나 WebGPU 타임스탬프 쿼리(Timestamp queries)와 같이 GPU 명령어의 실행 시간을 나노초 단위로 정밀하게 측정할 수 있는 기능 역시 캐시 부채널 공격의 표적이 되었습니다 [4, 10, 11]. 과거 WebGL에서는 고정밀 타임스탬프를 이용해 캐시 미스율을 파악하고, GPU의 물리적 메모리 구조를 알아내어 Rowhammer 공격을 실행해 페이지 테이블을 조작하는 심각한 공격 사례가 보고되기도 했습니다 [12].
-- **브라우저의 방어 메커니즘 (Mitigations):** 캐시 타이밍 부채널 공격을 방어하기 위해 WebKit, Blink 등 브라우저 엔진은 다층적 방어 체계를 도입했습니다 [6, 13]. 가장 핵심적인 조치는 타이머의 정밀도를 의도적으로 낮추는 양자화(Quantization)와 조대화(Coarsening)입니다 [4, 13-15]. `performance.now()` 등의 해상도를 1ms나 100 마이크로초 단위로 제한하고, 통계적 평균화를 통해 정밀한 시간을 재구성하지 못하도록 반환 시간에 임의의 변동성인 '지터(jitter)'를 추가하기도 합니다 [13, 14, 16]. 또한, 고해상도 타이머 생성에 악용될 수 있는 `SharedArrayBuffer`를 비활성화하는 조치도 취해졌습니다 [13, 16]. 나아가, 분기문 자체가 취약점이 되는 것을 막기 위해 인덱스 마스킹(Index masking)과 포인터 포이즈닝(Pointer poisoning) 같은 '분기 없는 보안 검사(Branchless security checks)' 메커니즘으로 전환하고 있습니다 [6, 7, 16, 17].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[Spectre]], [[Meltdown]], [[Speculative Execution]], [[Timing Attack]], [[Timer Quantization]], [[Rowhammer]]
-- **Projects/Contexts:** [[WebKit]], [[JavaScriptCore]], [[Blink]], [[WebGPU timestamp queries]], [[EXT_disjoint_timer_query]]
-- **Contradictions/Notes:** 고정밀 GPU 타임스탬프 기능의 경우, 성능 프로파일링을 위해 이 기능이 필수적이라는 개발자들의 요구(WebGPU 커뮤니티 등)와 캐시 부채널 공격(Timing attack)을 막아야 한다는 보안 요구가 충돌합니다. 이에 따라 브라우저 벤더들은 사이트 격리(Site isolation) 상태에 따라 타이머 해상도를 조대화(coarsening)하거나 양자화(quantization)를 강제하는 방식을 타협점으로 사용하고 있습니다 [4, 11, 15, 18].
-
----
-*Last updated: 2026-04-19*
-- Raw Source: [[00_Raw/2026-04-20/Side-channel Attack.md]]
----
diff --git a/Programming & Language/Side-channel attacks.md b/Programming & Language/Side-channel attacks.md
deleted file mode 100644
index 3205f917..00000000
--- a/Programming & Language/Side-channel attacks.md	
+++ /dev/null
@@ -1,38 +0,0 @@
----
-id: P-REINFORCE-AUTO-9A3E86
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Side-channel attacks"
----
-
-# [[Side-channel attacks]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-- **공격 원리 및 주요 취약점 (Spectre & Meltdown)**
-  사이드 채널 공격의 대표적인 사례인 Spectre는 최신 CPU의 성능 향상 기법인 '투기적 실행(speculative execution)'을 악용합니다. CPU는 분기가 일어날 방향을 예측하여 메모리의 데이터를 L1 캐시로 미리 로드하며, 예측이 틀린 경우 실행 상태를 롤백하지만 L1 캐시에 가져온 데이터는 삭제하지 않고 남겨둡니다 [3, 7]. 공격자는 이 특성과 고해상도 타이밍(high fidelity timing)을 이용해 L1 캐시와 메인 메모리 간의 접근 지연 시간(latency) 차이를 측정하고, 스페큘레이티브하게 로드된 값을 알아내어 정보를 유출합니다 [3, 8]. 또한 Meltdown은 사용자 영역의 코드(예: JavaScript)가 커널 메모리를 읽을 수 있게 하는 취약점으로, WebKit 같은 환경에서는 Spectre를 활용하여 분기 기반의 보안 검사를 먼저 우회해야만 Meltdown 공격을 시작할 수 있습니다 [9, 10].
-
-- **웹 그래픽 API와 고정밀 타이머를 통한 공격 (WebGL & WebGPU)**
-  `EXT_disjoint_timer_query`나 WebGPU의 타임스탬프 쿼리처럼 GPU 명령어의 실행 시간을 나노초 단위로 측정할 수 있는 고해상도 타이머 역시 사이드 채널 공격의 주요 표적이 됩니다 [11, 12]. 보안 연구자들은 이러한 정밀한 타이머가 캐시 미스율과 물리적 메모리 레이아웃을 파악하는 데 사용될 수 있으며, WebGL 환경에서 GPU에 대한 Rowhammer 공격과 결합하여 보안을 뚫는 심각한 공격 사례도 존재했다고 보고했습니다 [1, 13].
-
-- **타이밍 공격 완화 및 보안 전략 (Mitigations)**
-  - **타이머 정밀도 축소 (Quantization & Coarsening):** 브라우저 엔진은 캐시 사이드 채널 공격에 필요한 서브 마이크로초 단위의 타이밍 차이를 관찰하지 못하도록 `performance.now()`나 GPU 타임스탬프 쿼리의 해상도를 1ms 또는 100 마이크로초 수준으로 낮춥니다 [4, 5, 12, 14]. 또한 통계적인 시간 측정을 방해하기 위해 무작위 지터(jitter)를 추가하기도 하며, 고해상도 타이머를 만들 수 있는 `SharedArrayBuffer` 기능을 비활성화했습니다 [4, 6].
-  - **분기 없는 보안 검사 (Branchless Security Checks):** WebKit은 공격자가 분기를 통제하여 투기적 실행을 발생시키는 것을 막기 위해, 비트 연산을 활용하여 항상 유효한 배열 범위 내를 가리키도록 하는 '인덱스 마스킹(Index Masking)'과 잘못된 타입 접근 시 메모리가 매핑되지 않은 영역을 가리키도록 유도하는 '포인터 포이즈닝(Pointer Poisoning)'을 도입했습니다 [15-17].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** `[[Spectre]]`, `[[Meltdown]]`, `[[Speculative execution]]`, `[[Timestamp quantization]]`, `[[Branchless security checks]]`
-- **Projects/Contexts:** `[[WebKit]]`, `[[JavaScriptCore]]`, `[[WebGPU]]`
-- **Contradictions/Notes:** WebGPU 스펙은 타이밍 공격의 위험성 때문에 타임스탬프 쿼리를 선택적(optional) 기능으로 명시하고 아예 노출을 제한할 수 있다고 규정합니다. 그러나 Chrome(Blink) 등의 구현체는 기능을 완전히 차단하는 대신, 사이트 격리(site isolation) 여부에 따라 타이머 해상도를 100 마이크로초로 양자화(quantization)하여 보안과 개발자 성능 측정 요구 사이의 타협점을 제공하고 있습니다 [12, 18, 19].
-
----
-*Last updated: 2026-04-19*
-- Raw Source: [[00_Raw/2026-04-20/Side-channel attacks.md]]
----
diff --git a/Programming & Language/Signal Processing.md b/Programming & Language/Signal Processing.md
deleted file mode 100644
index dc24dfaf..00000000
--- a/Programming & Language/Signal Processing.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-E8C536
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Signal Processing"
----
-
-# [[Signal Processing]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Signal Processing.md]]
----
diff --git a/Programming & Language/Simulation Theory.md b/Programming & Language/Simulation Theory.md
deleted file mode 100644
index af9fb541..00000000
--- a/Programming & Language/Simulation Theory.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-5A1ACA
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Simulation Theory"
----
-
-# [[Simulation Theory]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Simulation Theory.md]]
----
diff --git a/Programming & Language/Single Page Applications (SPA).md b/Programming & Language/Single Page Applications (SPA).md
deleted file mode 100644
index 7aa13b35..00000000
--- a/Programming & Language/Single Page Applications (SPA).md	
+++ /dev/null
@@ -1,33 +0,0 @@
----
-id: P-REINFORCE-AUTO-D50C28
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Single Page Applications (SPA)"
----
-
-# [[Single Page Applications (SPA)]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 소스에 관련 정보가 부족합니다. 제공된 소스에는 Single Page Applications (SPA)에 대한 명확한 정의나 개요가 포함되어 있지 않으며, 브라우저 메모리 누수의 문맥에서 단편적으로만 언급되어 있습니다 [1].
-
-## 📖 구조화된 지식 (Synthesized Content)
-소스에 관련 정보가 부족합니다. 제공된 소스에서 SPA와 관련하여 확인할 수 있는 유일한 세부 정보는 다음과 같습니다.
-
-* **메모리 누수의 주요 발생원:** SPA 라우트 전환(route transitions)은 애플리케이션에서 메모리 누수가 발생하는 가장 주요한 원인(#1 leak source)입니다 [1].
-* **누수 발생 메커니즘:** 이전 라우트의 컴포넌트가 이벤트 리스너(listeners), 타이머(timers) 또는 전역 상태 참조(global state references)를 제대로 정리(clean up)하지 못한 상태로 방치할 경우, 이러한 참조들이 세션 수명 기간 동안 계속 누적되어 메모리 누수를 일으키게 됩니다 [1].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[Memory Leaks]], [[Garbage Collection]]
-- **Projects/Contexts:** [[Browser Memory Leak Detection]]
-- **Contradictions/Notes:** 소스에 관련 정보가 부족합니다.
-
----
-*Last updated: 2026-04-19*
-- Raw Source: [[00_Raw/2026-04-20/Single Page Applications (SPA).md]]
----
diff --git a/Programming & Language/Skybound Protocol 개발자 확장 가이드 및 아키텍처 리뷰.md b/Programming & Language/Skybound Protocol 개발자 확장 가이드 및 아키텍처 리뷰.md
deleted file mode 100644
index 2ffe7475..00000000
--- a/Programming & Language/Skybound Protocol 개발자 확장 가이드 및 아키텍처 리뷰.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-271BCA
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Skybound Protocol 개발자 확장 가이드 및 아키텍처 리뷰"
----
-
-# [[Skybound Protocol 개발자 확장 가이드 및 아키텍처 리뷰]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Skybound Protocol 개발자 확장 가이드 및 아키텍처 리뷰.md]]
----
diff --git a/Programming & Language/Skybound Protocol 시스템 아키텍처 및 데이터 흐름 분석.md b/Programming & Language/Skybound Protocol 시스템 아키텍처 및 데이터 흐름 분석.md
deleted file mode 100644
index 547b5dff..00000000
--- a/Programming & Language/Skybound Protocol 시스템 아키텍처 및 데이터 흐름 분석.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-ADF455
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Skybound Protocol 시스템 아키텍처 및 데이터 흐름 분석"
----
-
-# [[Skybound Protocol 시스템 아키텍처 및 데이터 흐름 분석]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Skybound Protocol 시스템 아키텍처 및 데이터 흐름 분석.md]]
----
diff --git a/Programming & Language/Spatial-Syntax.md b/Programming & Language/Spatial-Syntax.md
deleted file mode 100644
index 8d5ed614..00000000
--- a/Programming & Language/Spatial-Syntax.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-9BAC11
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Spatial-Syntax"
----
-
-# [[Spatial-Syntax]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Spatial-Syntax.md]]
----
diff --git a/Programming & Language/Spectre.md b/Programming & Language/Spectre.md
deleted file mode 100644
index a77849fc..00000000
--- a/Programming & Language/Spectre.md	
+++ /dev/null
@@ -1,33 +0,0 @@
----
-id: P-REINFORCE-AUTO-6C2AC3
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Spectre"
----
-
-# [[Spectre]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> Spectre는 최신 프로세서에 공통적으로 존재하는 보안 취약점으로, CPU의 **추측 실행(Speculative Execution)과 분기 예측(Branch Prediction)을 악용하여 비밀 메모리 영역에 대한 읽기 권한을 탈취**하는 공격입니다 [1-3]. 웹 브라우저 환경에서는 신뢰할 수 없는 JavaScript 등의 코드가 고해상도 타이머를 이용해 캐시 지연 시간을 측정하는 방식(타이밍 공격)으로 시스템 메모리를 유출할 수 있는 치명적인 위험을 초래했습니다 [4-6].
-
-## 📖 구조화된 지식 (Synthesized Content)
-- **공격의 원리**: 현대의 CPU는 성능 향상을 위해 분기 예측과 추측 실행을 사용합니다. CPU는 추측 실행 과정에서 메인 메모리의 데이터를 L1 캐시로 미리 로드하는데, 예측이 틀려 실행이 롤백되더라도 캐시에 적재된 상태는 복구되지 않습니다 [2, 3, 5]. Spectre는 공격자가 분기를 조작하여 의도적으로 특정 데이터를 캐시에 로드하게 만든 뒤, **L1 캐시와 메인 메모리 간의 접근 시간 차이를 고정밀 타이머로 측정**하여 해당 데이터를 추론해 내는 타이밍 기반 정보 유출 공격입니다 [5, 6].
-- **웹 브라우저에 미치는 영향**: WebKit의 JavaScriptCore와 같은 자바스크립트 엔진은 신뢰할 수 없는 코드를 실행할 때 보안을 유지하기 위해 분기 명령어(Branch instructions)에 의존해 왔습니다 [1, 7]. 그러나 Spectre를 통해 이러한 **경계 검사(Bounds checks) 및 타입 검사(Type checks)를 우회**할 수 있게 됨에 따라, 제한된 권한의 JavaScript나 WebAssembly가 호스트 프로세스의 전체 주소 공간을 읽어낼 수 있는 취약점이 발생했습니다 [4, 8]. 이는 또 다른 취약점인 Meltdown 공격을 수행하기 위한 선행 우회 수단으로도 활용될 수 있습니다 [1, 7].
-- **타이머 정밀도 제한 및 양자화 (Mitigation 1)**: Spectre 공격은 고해상도의 타이밍 측정에 절대적으로 의존하므로, 웹 브라우저들은 `performance.now()`의 정밀도를 1ms 또는 100 마이크로초 단위로 제한하고, 고해상도 타이머 생성에 악용될 수 있는 `SharedArrayBuffer` 기능을 비활성화했습니다 [9-11]. WebGL의 `EXT_disjoint_timer_query`나 WebGPU의 타임스탬프 쿼리 같은 하드웨어 가속 타이머 역시 캐시 적중률 및 메모리 접근 패턴 노출을 막기 위해 **기능이 비활성화되거나 정밀도가 강제로 양자화(Quantization/Coarsening)** 되었습니다 [12-15].
-- **분기 없는 보안 검사 도입 (Mitigation 2)**: 브라우저 엔진들은 타이머 제한에 그치지 않고, 분기에 의존하지 않는 보안 검사 기법(Branchless security checking)으로 아키텍처를 전환했습니다 [11, 16]. 배열 접근 시 인덱스를 안전한 범위 내로 강제하는 **인덱스 마스킹(Index masking)**과, 객체 포인터에 무작위 값을 섞어 잘못된 타입 접근 시 유효하지 않은 메모리를 참조하게 만드는 **포인터 포이즈닝(Pointer poisoning)** 등의 기법이 적용되어 근본적인 공격 경로를 차단했습니다 [17, 18].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[Speculative Execution]], [[Branch Prediction]], [[Meltdown]], [[Timing Attacks]], [[Branchless Security Checks]]
-- **Projects/Contexts:** [[WebKit]], [[JavaScriptCore]], [[WebGL]], [[WebGPU]]
-- **Contradictions/Notes:** 그래픽스 및 성능 최적화 개발자들은 마이크로 레이턴시 측정을 위해 WebGPU/WebGL 환경에서 나노초 단위의 정밀한 타이머를 필요로 하지만, 브라우저 벤더들은 Spectre와 같은 사이드 채널 공격을 방지하기 위해 이 타이머의 정밀도를 의도적으로 제한해야 하는 보안과 성능 분석 기능 간의 상충 관계(Trade-off)가 발생합니다 [12-14, 19].
-
----
-*Last updated: 2026-04-19*
-- Raw Source: [[00_Raw/2026-04-20/Spectre.md]]
----
diff --git a/Programming & Language/Speculative Execution.md b/Programming & Language/Speculative Execution.md
deleted file mode 100644
index b7cf853f..00000000
--- a/Programming & Language/Speculative Execution.md	
+++ /dev/null
@@ -1,33 +0,0 @@
----
-id: P-REINFORCE-AUTO-CCED4D
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Speculative Execution"
----
-
-# [[Speculative Execution]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 추측 실행(Speculative Execution)은 현대 CPU가 성능 최적화를 위해 분기(branch)의 실제 결과가 확인되기 전에 미리 명령어를 실행하는 기법입니다 [1]. 예측이 틀린 것으로 판명될 경우 CPU는 실행을 롤백(roll back)하여 변경 사항을 취소할 수 있습니다 [1]. 하지만 이 과정에서 L1 캐시로 미리 가져온 데이터는 롤백 시 취소되지 않으며, 이러한 구조적 특성은 타이밍 기반의 정보 유출을 유발하여 **Spectre**와 같은 보안 취약점 공격에 악용될 수 있습니다 [1, 2].
-
-## 📖 구조화된 지식 (Synthesized Content)
-- **동작 원리 및 분기 예측:** 현대 CPU는 분기 기록을 프로파일링하여 결과를 예측(Branch Prediction)하며, 이를 바탕으로 코드를 추측 실행합니다 [1]. 예를 들어, 특정 분기 조건을 통과할 것으로 예측되면, CPU는 해당 분기가 실제로 검증되기 전에 그 뒤에 오는 메모리 로드(load) 명령을 병렬로 미리 실행할 수 있습니다 [1].
-- **롤백 및 L1 캐시 최적화:** 만약 CPU의 예측이 틀려 분기가 다른 방향으로 진행되어야 한다면, CPU는 분기 시점부터 검증 시점까지 발생한 모든 추측 실행 작업을 취소(undo)하고 롤백합니다 [1]. 그러나 성능 최적화를 위해, 추측 실행 중에 메인 메모리에서 **L1 캐시**(CPU에서 가장 작고 빠른 메모리 캐시)로 데이터를 가져온 작업은 롤백할 때 취소되지 않습니다 [2].
-- **보안 취약점 (Spectre 공격):** L1 캐시에 남아 있는 데이터는 **타이밍 기반 정보 유출(timing-based information leak)**을 초래합니다 [2]. 공격자는 과거의 분기 기록을 조작함으로써 추측 실행 중에 CPU가 특정 작업을 수행하도록 유도할 수 있습니다 [3]. 이후 다양한 메모리 위치에 대한 접근 속도(L1 캐시와 메인 메모리의 지연 시간 차이)를 측정하여 어떤 데이터가 추측 실행으로 로드되었는지 알아낼 수 있으며, 이것이 **Spectre** 공격의 핵심 원리입니다 [1-3].
-- **보안 검사 우회 및 영향:** 이러한 추측 실행 취약점으로 인해 경계 검사(bounds check)나 타입 검사(type check)와 같은 기존의 분기 기반 보안 검사들이 무력화될 수 있습니다 [4, 5]. 결과적으로 신뢰할 수 없는 코드(예: 웹 브라우저의 JavaScript 엔진)가 제한된 영역을 벗어나 호스트 프로세스의 임의 메모리를 읽을 수 있는 위험이 발생합니다 [4, 6].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[Spectre]], [[Meltdown]], [[Branch Prediction]], [[L1 Cache]]
-- **Projects/Contexts:** [[WebKit]], [[JavaScriptCore]]
-- **Contradictions/Notes:** 소스 내에서 상충되는 주장은 발견되지 않았습니다. 다만, 이와 관련하여 WebKit 프로젝트는 추측 실행을 악용한 공격을 방어하기 위해 타이머(performance.now 등)의 정밀도를 낮추고, 분기 명령어에 의존하지 않는 보안 검사(branchless security checks) 및 포인터 포이즈닝(pointer poisoning)을 도입하는 방식으로 대응하고 있습니다 [7-9].
-
----
-*Last updated: 2026-04-19*
-- Raw Source: [[00_Raw/2026-04-20/Speculative Execution.md]]
----
diff --git a/Programming & Language/Static-Type-Inference.md b/Programming & Language/Static-Type-Inference.md
deleted file mode 100644
index 86507eca..00000000
--- a/Programming & Language/Static-Type-Inference.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-262D9E
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Static-Type-Inference"
----
-
-# [[Static-Type-Inference]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Static-Type-Inference.md]]
----
diff --git a/Programming & Language/Statistical Mechanics.md b/Programming & Language/Statistical Mechanics.md
deleted file mode 100644
index 270071cc..00000000
--- a/Programming & Language/Statistical Mechanics.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-9E33B1
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Statistical Mechanics"
----
-
-# [[Statistical Mechanics]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Statistical Mechanics.md]]
----
diff --git a/Programming & Language/Stop-the-world.md b/Programming & Language/Stop-the-world.md
deleted file mode 100644
index 5698d1a9..00000000
--- a/Programming & Language/Stop-the-world.md	
+++ /dev/null
@@ -1,43 +0,0 @@
----
-id: P-REINFORCE-AUTO-D2D9B2
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Stop-the-world"
----
-
-# [[Stop-the-world]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 'Stop-the-world'(STW)는 가비지 컬렉션(GC)이 실행되는 동안 메모리를 정리하기 위해 애플리케이션의 실행이 일시적으로 완전히 중단되는 현상을 의미합니다 [1, 2]. 가비지 컬렉터가 힙(Heap) 메모리에 대한 배타적 접근 권한을 얻어야 하므로 애플리케이션 스레드가 멈추게 됩니다 [1, 3]. 이로 인해 발생하는 지연(Latency)과 화면 끊김(Jank)을 줄이기 위해 현대의 GC 알고리즘들은 STW 시간을 최소화하거나 회피하는 병렬 및 동시 처리 방식으로 발전하고 있습니다 [2, 4, 5].
-
-## 📖 구조화된 지식 (Synthesized Content)
-* **원인 및 메커니즘**
-  가비지 컬렉터가 더 이상 사용되지 않는 객체를 정리하고 메모리를 재사용하기 위해서는 힙 영역에 배타적으로 접근해야 하며, 이 과정에서 애플리케이션은 처리 작업이 완료될 때까지 정지(halt)해야 합니다 [1]. V8 엔진의 경우, 자바스크립트 실행을 멈추고 메인 스레드에서 순차적으로 GC 작업을 수행하는 것이 가장 직관적인 STW 방식입니다 [2, 6]. 
-
-* **성능에 미치는 영향**
-  STW 중단 시간이 길어지면 애플리케이션의 성능 저하를 초래합니다. 특히 메인 스레드에 지연과 화면 끊김(Jank) 현상을 유발하여 사용자 경험을 떨어뜨리고 전체 프로그램의 처리량(Throughput)을 감소시킵니다 [2]. GC 로그에서 긴 'Duration' 값은 긴 STW 중단을 나타냅니다 [7]. V8에서 병렬(Parallel) 기법을 사용하더라도 이는 본질적으로 'stop-the-world' 방식이며 자바스크립트 실행이 멈추게 되지만, 총 중단 시간을 스레드 수로 나누어 줄일 수 있습니다 [8].
-
-* **주요 발생 시점**
-  * 스위프(Sweep) 작업이나 마크(Mark) 단계가 배타적 접근 권한을 가지고 실행될 때 STW 중단이 발생합니다 [3, 9].
-  * IBM JVM의 'gencon' 정책에서는 'nursery' 영역을 정리하는 스캐빈지(Scavenge) 작업이나 글로벌 사이클의 초기 및 최종 마크 단계가 짧은 STW 중단 동안 실행됩니다 [10].
-  * 동시 마크(Concurrent mark) 작업을 사용하더라도 메모리가 고갈되어 스위프 작업이 시작될 때나, 루트 객체를 다시 스캔할 때는 STW 중단이 필요합니다 [9].
-
-* **STW 완화 및 회피 기법**
-  * **점진적 및 동시 처리:** 점진적 동시 마크(Incremental concurrent mark processing) 처리는 글로벌 STW 가비지 컬렉션을 피함으로써 중단 시간을 고르게 분산시킵니다 [4]. 
-  * **Orinoco 가비지 컬렉터:** V8 엔진의 최신 가비지 컬렉터인 Orinoco는 기존의 'stop-the-world' 휴식 모델에서 벗어나, 메인 스레드의 부하를 줄이기 위해 병렬(Parallel), 점진적(Incremental), 동시(Concurrent) 스위핑 및 마킹 기술을 도입했습니다 [5, 11].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[Garbage Collection]], [[Heap Memory]], [[Orinoco]], [[Mark-Sweep]]
-- **Projects/Contexts:** [[V8 JavaScript Engine]], [[IBM Java Virtual Machine (VM)]]
-- **Contradictions/Notes:** 제공된 소스들 사이에서 내용 상의 모순은 없으며, V8 엔진과 IBM JVM 환경 모두에서 가비지 컬렉션 중 발생하는 'Stop-the-world'의 기본 개념과 이를 최적화(병렬, 동시, 점진적 처리)하여 일시 정지 시간을 줄이려는 공통된 발전 방향을 보여줍니다 [3-5, 8].
-
----
-*Last updated: 2026-04-19*
-- Raw Source: [[00_Raw/2026-04-20/Stop-the-world.md]]
----
diff --git a/Programming & Language/Structural Typing.md b/Programming & Language/Structural Typing.md
deleted file mode 100644
index a7e56030..00000000
--- a/Programming & Language/Structural Typing.md	
+++ /dev/null
@@ -1,43 +0,0 @@
----
-id: P-REINFORCE-AUTO-8C150A
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Structural Typing"
----
-
-# [[Structural Typing]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 구조적 타이핑(Structural Typing)은 명시적인 타입 선언이나 이름이 아닌, 객체가 가진 실제 형태와 구조(속성 및 메서드)를 기준으로 타입 호환성을 결정하는 시스템이다[1, 2]. "오리처럼 걷고 갉갉거리면 오리다"라는 '덕 타이핑(Duck Typing)' 원리와 동일한 맥락을 가지며, 대상 타입이 요구하는 최소한의 멤버(속성)를 모두 포함하고 있다면 호환되는 것으로 간주한다[2, 3]. 이는 타입의 이름이 일치해야만 호환성을 인정하는 명목적 타이핑(Nominal Typing)과 대비되는 TypeScript의 핵심 설계 철학이다[2].
-
-## 📖 구조화된 지식 (Synthesized Content)
-* **동작 원리 및 특징**
-  * 구조적 타이핑 하에서는 두 클래스나 객체의 이름 및 출처가 다르더라도 내부 속성의 구조가 동일하다면 서로 호환 가능한 것으로 취급된다[2, 4].
-  * TypeScript에서는 변수 `y`의 타입에 정의된 모든 멤버를 객체 `x`가 최소한으로 포함하고 있다면, `x`는 `y`와 호환되어 할당이 가능하다[3]. 즉, 대상 타입의 요구사항 외에 추가적인 여분의 속성을 더 가지고 있더라도 호환이 허용된다[4].
-  * 집합론의 관점에서 볼 때, 구조적 타이핑을 통해 클래스의 명시적인 상속 선언(`class X extends Y`) 없이도 특정 구조를 만족하는 객체는 더 넓은 타입의 부분집합으로 안전하게 취급될 수 있다[5, 6].
-
-* **명목적 타이핑(Nominal Typing)과의 차이 및 한계**
-  * Java나 C#과 같은 언어는 신분증명처럼 타입의 명시적 선언이나 이름 일치를 요구하는 명목적 타이핑을 사용하지만, TypeScript의 모든 객체는 본질적으로 '비정확(inexact)'하며 구조적 타이핑의 지배를 받는다[2, 7].
-  * 이러한 유연함은 매우 편리하지만, 의미적으로 엄격히 구분되어야 하는 동일한 구조의 데이터(예: User ID와 Order ID가 모두 단순 문자열인 경우)를 컴파일러가 구분하지 못하는 '기본 타입에의 집착(Primitive Obsession)' 문제를 야기한다[8]. 
-  * 이를 방어하기 위해 개발자들은 런타임에는 존재하지 않지만 컴파일 시점에만 존재하는 고유한 가상의 식별자를 부여하는 브랜디드 타입(Branded Types / Opaque Types) 패턴을 활용하여 구조적 타이핑의 한계를 보완한다[8-10].
-
-* **초과 속성 검사(Excess Property Checking)와의 상호작용**
-  * 구조적 타이핑은 추가 속성의 존재를 근본적으로 허용하지만, 개발자의 오타나 예기치 않은 데이터 유입을 막기 위해 TypeScript는 예외적으로 객체 리터럴을 변수에 직접 할당하거나 함수의 인자로 직접 넘길 때 '초과 속성 검사(EPC)'를 발동시킨다[6, 11, 12].
-  * 그러나 객체를 중간 변수에 먼저 할당한 뒤 전달하는 식의 간접 할당 상황이 되면 EPC가 작동하지 않고, 구조적 타이핑의 "최소 요건 충족" 원칙으로 되돌아가 초과 속성을 그대로 허용하게 된다[13, 14].
-  * 이와 같은 우회 현상으로 인한 런타임 오류나 초과 속성 유입 문제를 방지하기 위해 `satisfies` 연산자를 활용하면, 구조의 구체성을 잃지 않으면서도 대상 타입과의 구조적 계약을 엄격히 준수하도록 강제할 수 있다[15, 16].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[Duck Typing]], [[Nominal Typing]], [[Excess Property Checking]], [[Branded Types]], [[satisfies Operator]]
-- **Projects/Contexts:** [[TypeScript Type System]]
-- **Contradictions/Notes:** 구조적 타이핑은 기본적으로 대상 객체가 추가적인 속성을 가지는 것을 허용하여 유연한 호환성을 부여하지만[4], 객체 리터럴을 직접 할당할 때는 이러한 유연성 대신 '초과 속성 검사(Excess Property Checking)'가 개입하여 선언되지 않은 속성의 존재를 엄격하게 에러로 처리한다는 상반된 동작 규칙이 공존한다[6, 11, 12].
-
----
-*Last updated: 2026-04-18*
-- Raw Source: [[00_Raw/2026-04-20/Structural Typing.md]]
----
diff --git a/Programming & Language/StyleCounsel.md b/Programming & Language/StyleCounsel.md
deleted file mode 100644
index e9f5f28e..00000000
--- a/Programming & Language/StyleCounsel.md	
+++ /dev/null
@@ -1,39 +0,0 @@
----
-id: P-REINFORCE-AUTO-761709
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - StyleCounsel"
----
-
-# [[StyleCounsel]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> StyleCounsel은 프로그래머가 자신의 고유한 코딩 스타일을 난독화(obfuscate)하고 다른 특정 프로그래머의 스타일을 모방(mimic)할 수 있도록 지원하여 신원을 보호하는 프라이버시 강화 도구입니다. 대중적인 오픈소스 IDE인 Eclipse의 플러그인 형태로 개발되었으며, Weka 머신러닝 시스템의 랜덤 포레스트(Random Forest) 알고리즘을 내장하고 있습니다. 이 도구는 사용자의 코드를 평가한 후, 타겟 작성자로 오분류를 유도하기 위해 어떤 부분을 수정해야 하는지 구체적인 변경 사항을 조언(counsel)하는 'Human-in-the-loop' 방식으로 동작합니다.
-
-## 📖 구조화된 지식 (Synthesized Content)
-* **개발 배경 및 목적**
-  오픈소스 기여자들의 익명성이 코드 스타일 분석(Code Stylometry)과 같은 포렌식 기법에 의해 노출되는 것을 방지하기 위해 개발되었습니다. 작성자 식별 시스템의 취약점을 이용하는 적대적 모방(adversarial imitation) 방어를 구현하여, 프로그래머가 다른 사람의 스타일을 성공적으로 위장할 수 있도록 돕는 것을 목표로 합니다.
-* **시스템 구조 및 작동 방식**
-  * **모델 학습 (Train):** 사용자가 제공한 소스 코드(훈련 데이터)에서 특징(feature)을 추출하여 특징 벡터를 생성한 후, 포함된 배경 데이터와 결합하여 Weka 기반의 랜덤 포레스트 분류기를 학습시킵니다.
-  * **평가 및 추천 (Evaluate):** 파일 평가를 실행하면 학습된 모델을 사용해 현재 코드의 분류 및 신뢰도 수준을 출력합니다. 그런 다음, 대상(타겟) 작성자로 분류될 수 있도록 랜덤 포레스트 내의 결정 트리(Decision Tree) 경로를 역산하여 분석합니다.
-  * **권장 사항 제공:** 추출된 분석 결과는 Eclipse 작업 공간의 'problems' 뷰에 경고(warnings) 형태로 표시됩니다. 타겟 클래스로 분류되기 위해 코드를 어느 정도 변경해야 하는지에 대한 구간(Interval) 및 수정 가이드를 제시합니다. 
-* **사용자 주도형 모델 (Human-in-the-loop)**
-  StyleCounsel은 코드를 자동으로 직접 수정하지 않습니다. 대신 사용자에게 변경 사항을 권장(recommend)하며, 코드를 어떻게 수정하여 제안을 충족시킬 것인지는 사용자의 재량에 맡깁니다. 
-* **사용성 평가 및 한계점**
-  파일럿 사용자 연구 결과, 참가자들은 StyleCounsel의 자동화된 코드 분석 기능과 지속적인 피드백 덕분에 타겟 스타일 모방 작업을 훨씬 효과적으로 수행할 수 있었습니다. 그러나, 도구가 제시하는 일부 권장 사항의 의미를 명확히 이해하기 어렵고, 권장 사항을 그대로 적용할 경우 코드의 동작이나 가독성에 부정적인 영향을 미칠 수 있다는 한계가 보고되었습니다.
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[Code Stylometry]], [[Authorship Attribution]], [[Random Forest]], [[Adversarial Imitation]]
-- **Projects/Contexts:** [[Eclipse IDE]], [[Weka Machine Learning]]
-- **Contradictions/Notes:** 사용자 연구에 따르면, StyleCounsel의 지속적이고 자동화된 피드백은 수동으로 코드를 분석하는 시간을 획기적으로 줄여준다는 긍정적인 평가를 받았습니다. 반면, 추천된 변경 사항 중 일부는 가독성 유지나 기능적 결함 발생을 우려하게 만들어 실제 코드에 적용하기 까다롭다는 점이 상충하는 한계로 지적되었습니다.
-
----
-*Last updated: 2026-04-19*
-- Raw Source: [[00_Raw/2026-04-20/StyleCounsel.md]]
----
diff --git a/Programming & Language/Submodules.md b/Programming & Language/Submodules.md
deleted file mode 100644
index 7763e4e6..00000000
--- a/Programming & Language/Submodules.md	
+++ /dev/null
@@ -1,34 +0,0 @@
----
-id: P-REINFORCE-AUTO-A6EDEA
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Submodules"
----
-
-# [[Submodules]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 서브모듈(Submodules)은 부모 애플리케이션 내에 존재하더라도 자체적인 컨텍스트를 가지기 때문에 Husky, lint-staged, ESLint와 같은 코드 품질 도구들과 기본적으로 원활하게 연동되지 않습니다. 따라서 이러한 도구들이 정상적으로 작동하여 코딩 표준을 강제할 수 있도록, 서브모듈 루트 내에 개별적인 패키지 설치 및 부모 설정을 확장(extend)하는 구성 작업이 필수적으로 요구됩니다 [1, 2].
-
-## 📖 구조화된 지식 (Synthesized Content)
-- **도구 실행 컨텍스트의 분리:** Husky와 lint-staged는 서브모듈 자체의 컨텍스트 내에서 실행됩니다. 이 때문에 서브모듈을 사용할 경우, 해당 서브모듈에도 Husky와 lint-staged를 설치하고 서브모듈의 `package.json`에 Husky 훅(hooks)을 명시적으로 추가해야 합니다 [1].
-- **`package.json`이 없는 서브모듈의 처리:** 서브모듈에 `package.json`이 없는 경우라도 서브모듈 내에 Husky를 초기화(init)해 주어야 합니다. 이 작업은 부모 앱의 `prepare` 스크립트에 추가하는 방식으로 간단히 처리할 수 있습니다 [2].
-- **ESLint 및 TypeScript 설정 상속:** 
-  - ESLint가 서브모듈에서 작동하려면 서브모듈의 루트에도 구성 파일(config)이 있어야 합니다. 이 경우 새로운 설정 파일을 생성하되 부모 앱의 설정을 확장(extend)하도록 작성하면 됩니다 [2].
-  - 마찬가지로 Husky와 lint-staged가 스크립트를 실행하기 위해 `tsconfig.json`을 필요로 하므로, 서브모듈 루트에 `tsconfig.json`을 추가하고 부모 앱의 설정을 상속받아 구성해야 합니다 [2].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[Husky]], [[lint-staged]], [[ESLint]], [[TypeScript]]
-- **Projects/Contexts:** [[팀 코딩 표준 강제 (Enforcing coding standards)]]
-- **Contradictions/Notes:** 서브모듈은 부모 디렉터리에 도구들이 설치 및 설정되어 있더라도 이를 자동으로 공유하지 않습니다. 따라서 부모 애플리케이션의 린트 및 포맷팅 자동화를 서브모듈에도 동일하게 적용하려면 각각 독립적인 훅과 확장 설정이 강제됩니다 [1, 2].
-
----
-*Last updated: 2026-04-19*
-- Raw Source: [[00_Raw/2026-04-20/Submodules.md]]
----
diff --git a/Programming & Language/Synthetic Testing.md b/Programming & Language/Synthetic Testing.md
deleted file mode 100644
index 95c81381..00000000
--- a/Programming & Language/Synthetic Testing.md	
+++ /dev/null
@@ -1,36 +0,0 @@
----
-id: P-REINFORCE-AUTO-DE0BE9
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Synthetic Testing"
----
-
-# [[Synthetic Testing]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> Synthetic Testing(합성 테스트)은 네트워크에 연결된 알려진 기기 및 통제된 실험실(Lab) 환경에서 웹사이트의 성능을 측정하는 방법입니다 [1, 2]. 이는 실제 사용자가 겪는 성능을 직접 측정하는 것이 아니라, 향후 성능이 어떨지 추정(estimate)하기 위해 사용됩니다 [2]. 주로 Google Lighthouse, WebPageTest, DebugBear 같은 도구를 사용하여 사용자 상호작용을 시뮬레이션하고 성능 메트릭을 평가하는 데 활용됩니다 [1, 3, 4].
-
-## 📖 구조화된 지식 (Synthesized Content)
-* **정의 및 데이터의 성격:** Synthetic Testing은 실제 사용자를 모니터링하는 대신, 네트워크상의 특정 기기에서 통제된 테스트를 실행하여 실험실 성능 데이터(Lab Data)를 수집하는 방식입니다 [2]. 이 테스트는 웹사이트의 성능을 가늠하는 훌륭한 추정치를 제공하지만, 실제 사용자의 모든 상호작용 환경을 완벽하게 복제할 수는 없다는 특징이 있습니다 [1, 2].
-* **주요 활용 도구 및 플랫폼:**
-  * **Google Lighthouse:** 개발자의 로컬 컴퓨터나 환경에서 실행되어 하드웨어 및 네트워크 성능을 측정하며, 주로 개발 시점의 테스트나 웹사이트 감사(audit)에 사용되는 대표적인 합성 테스트 도구입니다 [3].
-  * **WebPageTest:** 네트워크 위치, 네트워크 속도 등을 사용자 정의하여 공개된 웹사이트의 성능을 테스트할 수 있으며, 상세한 워터폴(waterfall) 차트를 생성하는 서비스입니다 [4].
-  * **DebugBear:** 합성 웹사이트 모니터링(Synthetic Website Monitoring)을 지원하여 사용자 상호작용을 시뮬레이션하고 느린 이벤트 핸들러나 렌더링 지연 등을 밝혀냅니다 [1, 5, 6].
-  * **Google Search Console:** Googlebot 크롤러에 의해 기록된 합성 메트릭 데이터를 기반으로 코어 웹 바이탈(Core Web Vitals) 등을 평가하며, 이는 Google 검색 순위에도 영향을 미칩니다 [7].
-* **테스트의 한계와 보완:** 합성 테스트 도구만으로는 실제 사용자 환경에서 발생하는 다양한 상호작용과 지연을 완벽하게 잡아낼 수 없습니다 [1]. 따라서 측정의 정확도를 높이고 완전한 성능을 파악하기 위해서는 실제 사용자 데이터인 필드 데이터(Field Data) 또는 실제 사용자 모니터링(Real User Monitoring)과 결합하여 분석하는 것이 중요합니다 [1, 2].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[Lab Data]], [[Field Data]], [[Real User Monitoring]], [[Core Web Vitals]]
-- **Projects/Contexts:** [[웹 성능 모니터링 및 최적화]], [[Google Lighthouse]], [[WebPageTest]]
-- **Contradictions/Notes:** Synthetic Testing(합성 테스트)은 통제된 환경에서의 성능 추정에는 매우 유용하지만, 실제 사용자의 상호작용을 완벽하게 재현할 수 없다는 한계를 가집니다. 따라서 이를 보완하기 위해 실제 환경의 성능을 반영하는 Field Data(Real User Monitoring)가 필수적으로 요구된다고 소스들은 강조합니다 [1, 2].
-
----
-*Last updated: 2026-04-19*
-- Raw Source: [[00_Raw/2026-04-20/Synthetic Testing.md]]
----
diff --git a/Programming & Language/System Dynamics.md b/Programming & Language/System Dynamics.md
deleted file mode 100644
index a2fe9262..00000000
--- a/Programming & Language/System Dynamics.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-282998
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - System Dynamics"
----
-
-# [[System Dynamics]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/System Dynamics.md]]
----
diff --git a/Programming & Language/Systems Dynamics.md b/Programming & Language/Systems Dynamics.md
deleted file mode 100644
index 95466b5a..00000000
--- a/Programming & Language/Systems Dynamics.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-A319BE
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Systems Dynamics"
----
-
-# [[Systems Dynamics]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Systems Dynamics.md]]
----
diff --git a/Programming & Language/TeamCity.md b/Programming & Language/TeamCity.md
deleted file mode 100644
index ad6a3b25..00000000
--- a/Programming & Language/TeamCity.md	
+++ /dev/null
@@ -1,33 +0,0 @@
----
-id: P-REINFORCE-AUTO-63B068
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - TeamCity"
----
-
-# [[TeamCity]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> TeamCity는 개봉 즉시 사용 가능한(out of the box) 강력한 지속적 통합(Continuous Integration) 도구입니다 [1, 2]. 이 도구는 팀을 위한 CI/CD 서버로 기능하며, 소프트웨어 빌드 프로세스 내에서 핵심적인 역할을 수행합니다 [3, 4]. 특히 정적 코드 분석 도구와 원활하게 통합되어 저품질의 코드가 프로덕션 환경에 배포되는 것을 사전에 차단할 수 있게 돕습니다 [4].
-
-## 📖 구조화된 지식 (Synthesized Content)
-- **강력한 지속적 통합 서버:** TeamCity는 팀을 위한 도구(Team Tools) 라인업에 포함된 강력한 CI(Continuous Integration) 서버입니다 [1, 3]. 
-- **분석 도구와의 매끄러운 통합:** TeamCity는 코드 품질 분석 플랫폼인 Qodana와 같은 도구와 원활하게 통합되는 CI/CD 서버입니다 [4]. 이를 통해 개발 팀은 자동화된 코드 스캔 작업을 빌드 프로세스의 자연스러운 일부로 편입시킬 수 있습니다 [4].
-- **프로덕션 배포 전 품질 관리:** 파이프라인 내에서 TeamCity를 활용하면 저품질의 코드가 프로덕션 환경에 도달하기 전에 이를 사전에 차단하는 가드레일 역할을 수행할 수 있습니다 [4].
-- **한계:** 제공된 소스에서는 TeamCity가 강력한 CI 도구이며 Qodana와 통합된다는 점 외에, TeamCity 자체의 구체적인 아키텍처나 세부 기능에 대해서는 다루고 있지 않으므로 소스에 관련 정보가 부족합니다.
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[Continuous Integration]], [[Qodana]], [[CI/CD]]
-- **Projects/Contexts:** [[정적 코드 분석 및 소프트웨어 빌드 자동화]]
-- **Contradictions/Notes:** 소스에는 TeamCity가 CI/CD 서버로서 Qodana와 통합되어 빌드 프로세스를 돕는다는 사실 외에 구체적인 기능이나 상세한 원리에 대한 설명은 없으므로, 전반적으로 소스에 관련 정보가 부족합니다.
-
----
-*Last updated: 2026-04-19*
-- Raw Source: [[00_Raw/2026-04-20/TeamCity.md]]
----
diff --git a/Programming & Language/Texture Atlas.md b/Programming & Language/Texture Atlas.md
deleted file mode 100644
index 1332da92..00000000
--- a/Programming & Language/Texture Atlas.md	
+++ /dev/null
@@ -1,40 +0,0 @@
----
-id: P-REINFORCE-AUTO-71CA1F
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Texture Atlas"
----
-
-# [[Texture Atlas]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 텍스처 아틀라스(Texture Atlas)는 여러 개의 개별 텍스처 이미지를 하나의 커다란 텍스처 시트(Texture Sheet)로 병합하여 사용하는 렌더링 최적화 기법이다. `InstancedMesh` 환경에서 모든 인스턴스가 동일한 재질을 공유해야 하는 한계를 극복하고, 개별 인스턴스마다 다른 텍스처를 적용하기 위한 필수적인 우회 기법으로 활용된다. 이를 통해 텍스처 바인딩 횟수를 줄이고 드로우 콜(Draw Call)을 최소화하여 성능을 크게 향상시킬 수 있다.
-
-## 📖 구조화된 지식 (Synthesized Content)
-- **드로우 콜 및 텍스처 바인딩 감소:**
-  각기 다른 텍스처를 사용하는 다수의 객체들을 개별적으로 렌더링하면 객체마다 새로운 드로우 콜과 텍스처 바인딩 오버헤드가 발생한다 [1, 2]. 텍스처 아틀라스를 사용하면 여러 재질의 텍스처를 하나의 큰 이미지(예: 4096x4096 해상도)로 결합하여, 단일 드로우 콜과 한 번의 텍스처 바인딩만으로 수많은 객체를 렌더링할 수 있다 [1, 3]. 이 기법은 텍스처 전환 비용을 없애 GPU 캐시 효율을 높이며 복잡한 씬에서 렌더링 속도를 30-40% 향상시킨다 [4].
-
-- **InstancedMesh와의 연동 방식:**
-  `InstancedMesh`는 단일 드로우 콜로 여러 객체를 그리지만, 구조적으로 모든 인스턴스가 동일한 셰이더 프로그램과 텍스처 유닛을 공유해야 한다는 제약이 있다 [5]. 따라서 인스턴스마다 다른 텍스처를 표현하려면 텍스처 아틀라스를 적용한 뒤, 각 인스턴스 속성(Instance Attribute)으로 UV 좌표 오프셋(UV Offset)을 전달하여 아틀라스 내의 정확한 영역을 참조하도록 셰이더를 구성해야 한다 [5-7].
-
-- **경계선 블리딩(Edge Bleeding) 및 구조적 한계점:**
-  텍스처 아틀라스의 가장 큰 단점은 밉맵(Mipmap) 생성이나 텍스처 필터링 과정에서 인접한 텍스처 이미지의 색상이 서로 섞여버리는 경계선 블리딩 현상이다 [2, 5]. 이를 방지하기 위해서는 아틀라스 내 텍스처들 사이에 패딩(Padding) 여백을 두어야 하는데, 이는 결국 GPU 메모리의 낭비로 이어진다 [2]. 더불어 셰이더 내에서 복잡한 UV 오프셋 계산 알고리즘을 유지해야 하는 부담이 수반된다 [2, 5].
-
-- **대안 기술: 텍스처 배열 (Data Array Textures):**
-  아틀라스의 단점을 해결하기 위한 현대적인 대안으로 데이터 배열 텍스처(Data Array Textures)가 사용된다 [8]. 이는 텍스처를 2D 레이어들이 쌓인 형태로 관리하여 경계선 블리딩 현상을 원천 차단하고, 네이티브 텍스처 래핑과 독립적인 밉맵 생성을 지원한다 [8]. 하지만 배열 텍스처는 포함된 모든 레이어의 텍스처 해상도가 완전히 동일해야 한다는 엄격한 제약 조건을 갖는다 [5, 9].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[InstancedMesh]], [[Draw Call]], [[UV Offset]], [[Edge Bleeding]], [[Data Array Textures]], [[BatchedMesh]]
-- **Projects/Contexts:** [[Three.js 렌더링 최적화]], [[WebGL 모바일 GPU 성능 관리]]
-- **Contradictions/Notes:** 소스 문헌들은 텍스처 아틀라스가 드로우 콜을 획기적으로 줄여주는 필수 최적화 기법임을 인정하면서도, 경계선 블리딩(Edge Bleeding) 방지를 위한 패딩으로 인한 메모리 낭비와 UV 연산 복잡성 증가라는 명확한 단점을 지적한다. 그 대안으로 배열 텍스처(Array Textures)가 추천되지만, 다양한 해상도의 텍스처를 혼합해 써야 할 경우에는 여전히 텍스처 아틀라스를 사용해야 한다는 트레이드오프가 존재한다 [2, 5, 9].
-
----
-*Last updated: 2026-04-19*
-- Raw Source: [[00_Raw/2026-04-20/Texture Atlas.md]]
----
diff --git a/Programming & Language/Throttling  Debouncing.md b/Programming & Language/Throttling  Debouncing.md
deleted file mode 100644
index 7257af8c..00000000
--- a/Programming & Language/Throttling  Debouncing.md	
+++ /dev/null
@@ -1,37 +0,0 @@
----
-id: P-REINFORCE-AUTO-92BBDE
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Throttling  Debouncing"
----
-
-# [[Throttling  Debouncing]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 스크롤, 화면 크기 조절(Resize), 타이핑 등 짧은 시간 동안 과도하게 발생하는 사용자 이벤트의 실행 빈도를 제어하여 애플리케이션의 성능 병목 현상을 방지하는 최적화 기법입니다.
-
-## 📖 구조화된 지식 (Synthesized Content)
-**1. 필요성 및 성능 영향** 사용자의 화면 크기 조절, 키보드 타이핑, 마우스 스크롤 같은 이벤트는 아주 짧은 시간에 수십~수백 번씩 연속적으로 발생합니다. 이 이벤트마다 무거운 연산이나 React의 상태 업데이트를 수행하면 매 틱(tick)마다 불필요한 리렌더링이나 재계산이 발생하여 심각한 성능 병목(Bottleneck) 현상을 초래할 수 있습니다.
-
-**2. 디바운싱 (Debouncing)** 연이어 발생하는 이벤트를 하나로 묶어, 특정 시간 동안 추가적인 이벤트가 발생하지 않을 때 마지막에 단 한 번만 이벤트 핸들러를 실행하는 기법입니다. 예를 들어 `lodash` 라이브러리의 `debounce` 함수를 사용하여 사용자가 창 크기 조절을 멈춘 뒤 200ms가 지났을 때만 리사이즈 로직이 처리되도록 제한할 수 있습니다.
-
-**3. 스로틀링 (Throttling)** 이벤트가 연속해서 발생하더라도 정해진 시간 간격 당 최대 한 번씩만 함수가 실행되도록 보장하는 기법입니다. (이전 대화 참고: Web Worker로 마우스의 위치를 지속적으로 포워딩할 때, 메시지 큐에 과부하가 걸리지 않도록 주기를 조절하는 데 유용하게 사용됩니다.)
-
-**4. 구현 시 번들 최적화 (Tree Shaking) 주의사항** 이러한 기법을 적용하기 위해 `lodash`와 같은 외부 유틸리티 라이브러리를 사용할 때는 번들 크기 최적화에 주의해야 합니다. `import _ from 'lodash';`와 같이 전체 라이브러리를 불러오면 번들 크기가 크게 증가하므로, `import { debounce } from 'lodash-es';` 또는 `import debounce from 'lodash-es/debounce';` 형태로 필요한 개별 함수만 가져와 트리 쉐이킹(Tree Shaking)이 완벽히 적용되도록 작성해야 합니다.
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[React Performance Optimization]], [[Tree Shaking (번들 크기 최적화)]], [[이벤트 포워딩 (Event Forwarding)]], [[불필요한 리렌더링 방지]]
-- **Projects/Contexts:** [[실시간 검색 입력(Typing) 지연 처리]], [[반응형 윈도우 리사이즈(Resize) 이벤트 처리]], [[웹 워커 통신 지연 최소화]]
-- **Contradictions/Notes:** 스로틀링과 디바운싱은 무거운 연산을 줄이고 프레임 드랍을 막아주지만, 설정한 대기 시간이 너무 길면 화면 업데이트가 늦어져 사용자에게 끊기는 느낌을 줄 수 있습니다. 따라서 작업의 성격(예: 즉각 반응이 필요한 드래그, 멈춘 후 반응해도 되는 윈도우 리사이즈)에 맞추어 적절한 지연 시간을 타협하는 것이 중요합니다.
-
----
-
-_Last updated: 2026-04-14_
-- Raw Source: [[00_Raw/2026-04-20/Throttling & Debouncing.md]]
----
diff --git a/Programming & Language/Timing Attack.md b/Programming & Language/Timing Attack.md
deleted file mode 100644
index e362bb5e..00000000
--- a/Programming & Language/Timing Attack.md	
+++ /dev/null
@@ -1,35 +0,0 @@
----
-id: P-REINFORCE-AUTO-392C3B
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Timing Attack"
----
-
-# [[Timing Attack]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 타이밍 공격(Timing Attack)은 캐시 적중률이나 메모리 접근 패턴 등 시스템의 작업 수행 시간을 극도로 정밀하게 측정함으로써 의도치 않은 정보를 유출하거나 보안 경계를 우회하는 부채널 공격(Side-channel Attack)의 일종입니다 [1-3]. 스펙터(Spectre)와 멜트다운(Meltdown)이 대표적인 예로, CPU의 추측 실행(Speculative Execution) 기능을 악용하여 L1 캐시와 메인 메모리 간의 접근 지연 시간 차이를 관찰함으로써 데이터를 탈취합니다 [3-5]. 웹 환경에서 이러한 공격은 신뢰할 수 없는 JavaScript나 WebAssembly 코드가 호스트 프로세스의 메모리를 읽을 수 있게 하므로, 브라우저 차원의 타이머 정밀도 저하 및 분기 없는 보안 검사(Branchless Security Checks) 등의 방어 기법이 필수적입니다 [6-8].
-
-## 📖 구조화된 지식 (Synthesized Content)
-- **공격의 원리 및 메커니즘:** 타이밍 공격은 마이크로초 미만의 미세한 시간 차이를 관찰하여 캐시 사이드 채널 공격을 가능하게 합니다 [2]. 스펙터(Spectre) 공격은 공격자가 CPU의 분기(branch)를 제어하고 추측 실행 과정에서 정보 유출을 유도하는 방식으로 작동합니다 [5]. 캐시된 데이터와 메인 메모리에 있는 데이터의 로드 속도 차이를 측정하여, 특정 데이터가 추측 실행을 통해 L1 캐시에 로드되었는지 여부를 알아냅니다 [3, 5].
-- **GPU 그래픽 API의 취약점:** WebGL의 `EXT_disjoint_timer_query`와 같은 API는 매우 높은 해상도의 타이밍 측정 기능을 제공하여 부채널 공격의 주요 표적이 되었습니다 [1, 9]. 이러한 고정밀 타임스탬프 쿼리를 이용하면 GPU 캐시 미스 비율을 관찰하거나, 물리적 메모리 레이아웃을 파악하여 로우해머(Rowhammer) 공격을 통해 페이지 테이블을 조작할 수도 있습니다 [10]. 또한 'Clock Around the Clock'과 같이 디바이스 핑거프린팅(Device Fingerprinting)에도 악용될 수 있습니다 [10].
-- **보안 완화 기술 (Mitigations):**
-  - **타이머 정밀도 감소 및 지터(Jitter) 도입:** 브라우저 엔진은 캐시 사이드 채널 공격을 막기 위해 `performance.now()`의 정밀도를 1ms 또는 100마이크로초로 낮추고, 무작위 '지터(Jitter)'를 도입하여 통계적인 고정밀 클록 재구성을 방지합니다 [2, 8]. 또한 고해상도 타이머를 만들 수 있는 `SharedArrayBuffer` 기능을 비활성화합니다 [8].
-  - **타임스탬프 양자화 (Quantization):** WebGPU와 같은 최신 API는 보안을 위해 타임스탬프 쿼리의 정밀도를 낮추는 양자화 기법을 도입했습니다 [1, 11]. 컨텍스트의 교차 출처 격리(Cross-origin isolated) 상태에 따라 타이머 분해능을 조절(예: 100마이크로초로 제한)하여 타이밍 공격과 핑거프린팅을 방지합니다 [11-14].
-  - **분기 없는 보안 검사 (Branchless Security Checks):** 스펙터 공격이 조건부 분기 명령을 악용하는 것을 막기 위해, 브라우저는 인덱스 마스킹(Index masking)과 포인터 포이즈닝(Pointer poisoning) 기법을 도입했습니다 [2, 8, 15, 16]. 이를 통해 분기 없이 타입 검사나 경계 검사(Bounds Check)를 수행하여 추측 실행으로 인한 취약점을 근본적으로 차단합니다 [8, 16].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[Side-channel Attack]], [[Spectre and Meltdown]], [[Speculative Execution]], [[Timestamp Quantization]], [[Branchless Security Checks]]
-- **Projects/Contexts:** [[WebKit]], [[WebGL]], [[WebGPU]]
-- **Contradictions/Notes:** 소스 내에서 특별한 모순점은 발견되지 않았습니다. 개발자들의 성능 분석 요구와 타이밍 공격(보안)이라는 상충하는 두 가지 목표를 해결하기 위해, WebGPU 표준에서는 타임스탬프 쿼리를 전면 차단하는 대신 '정밀도 양자화(Quantization)'를 절충안으로 도입하는 데 합의했습니다 [1, 10, 11].
-
----
-*Last updated: 2026-04-19*
-- Raw Source: [[00_Raw/2026-04-20/Timing Attack.md]]
----
diff --git a/Programming & Language/Timing Attacks (Spectre_Meltdown).md b/Programming & Language/Timing Attacks (Spectre_Meltdown).md
deleted file mode 100644
index 1edcf860..00000000
--- a/Programming & Language/Timing Attacks (Spectre_Meltdown).md	
+++ /dev/null
@@ -1,30 +0,0 @@
----
-id: P-REINFORCE-AUTO-09FCC7
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Timing Attacks (Spectre_Meltdown)"
----
-
-# [[Timing Attacks (Spectre_Meltdown)]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> Spectre와 Meltdown은 최신 프로세서의 투기적 실행(speculative execution) 기능과 캐시 지연 시간의 차이를 악용하여 보호된 메모리 영역을 무단으로 읽어내는 보안 취약점입니다 [1, 2]. 이러한 타이밍 공격(Timing Attacks)은 고해상도 타이머를 사용해 L1 캐시와 메인 메모리 간의 지연 시간 차이를 관찰함으로써 달성되며, 브라우저 환경에서 신뢰할 수 없는 JavaScript나 WebAssembly 코드가 실행될 때 악용될 수 있습니다 [1, 3]. 이를 방지하기 위해 웹 생태계에서는 타이머의 정밀도를 의도적으로 낮추고, 분기 명령어(branch)에 의존하지 않는 보안 검사를 도입하는 등의 방어 체계를 구축했습니다 [4, 5].
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[Speculative Execution]], [[EXT_disjoint_timer_query]], [[WebGPU Timestamp Queries]], [[Branchless Security Checks]]
-- **Projects/Contexts:** [[WebKit]], [[Blink]]
-- **Contradictions/Notes:** WebGPU 명세에서 타임스탬프 쿼리 기능은 타이밍 공격의 우려로 인해 선택적(optional)인 기능으로 정의되어 있으나, 성능 최적화를 위한 개발자들의 요구가 커서 해상도를 100 마이크로초로 낮추는 양자화(quantization)를 적용하는 절충안을 통해 기능을 제공하고 있습니다 [7, 13, 16].
-
----
-*Last updated: 2026-04-19*
-- Raw Source: [[00_Raw/2026-04-20/Timing Attacks (Spectre_Meltdown).md]]
----
diff --git a/Programming & Language/Timing Attacks.md b/Programming & Language/Timing Attacks.md
deleted file mode 100644
index a4798871..00000000
--- a/Programming & Language/Timing Attacks.md	
+++ /dev/null
@@ -1,33 +0,0 @@
----
-id: P-REINFORCE-AUTO-59075E
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Timing Attacks"
----
-
-# [[Timing Attacks]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 타이밍 공격(Timing Attacks)은 CPU나 GPU의 연산 처리, 캐시 적중률, 메모리 접근에 소요되는 미세한 시간 차이를 고정밀 타이머로 측정하여 시스템의 기밀 정보를 유출시키는 부채널 공격(Side-channel attacks)의 일종입니다 [1-3]. 웹 환경에서는 신뢰할 수 없는 JavaScript나 WebAssembly 코드가 실행될 때, 분기 예측과 추측 실행(Speculative execution) 과정에서 발생하는 타이밍 차이를 악용하여 스펙터(Spectre) 및 멜트다운(Meltdown) 취약점을 유발합니다 [2, 4, 5]. 이를 방지하기 위해 웹 브라우저들은 타이머의 정밀도를 고의로 낮추거나 타이밍 조작을 방지하는 다양한 완화(Mitigation) 정책을 적용하고 있습니다 [6, 7].
-
-## 📖 구조화된 지식 (Synthesized Content)
-- **스펙터(Spectre) 메커니즘과 타이밍 유출:** 스펙터 공격은 최신 CPU의 성능 최적화 기능인 **추측 실행(Speculative execution)**을 악용합니다. CPU가 메인 메모리에서 L1 캐시로 데이터를 미리 로드하는 과정에서 발생하는 지연 시간의 차이를 공격자가 고정밀 타이밍으로 측정(Timing-based information leak)하여, 접근이 허용되지 않은 메모리 영역의 값을 유추해 낼 수 있습니다 [2, 3, 5]. 
-- **WebGL 및 WebGPU 환경에서의 악용:** `EXT_disjoint_timer_query`나 WebGPU의 타임스탬프 쿼리(Timestamp queries) 같은 고정밀 GPU 타이머 도구는 본래 성능 프로파일링을 위해 만들어졌으나 타이밍 공격의 표적이 되었습니다 [1, 8]. 공격자는 이를 통해 GPU 캐시 미스율을 관찰하여 물리적 메모리의 비트를 변조하는 **로우해머(Rowhammer)** 공격을 수행하거나, **기기 핑거프린팅(Clock Around the Clock)**에 악용할 수 있습니다 [9].
-- **브라우저 벤더들의 타이머 해상도 제한 (Quantization):** 타이밍 공격에 필요한 서브 마이크로초 단위의 정밀도를 무력화하기 위해, 브라우저 엔진들은 `performance.now()` 및 GPU 타이머의 해상도를 1ms 또는 100마이크로초 수준으로 강제로 낮추었습니다 [6-8, 10]. 또한, 공격자가 통계적 평균을 통해 고정밀 시간을 역산하는 것을 막기 위해 임의의 시간 변동성인 **지터(Jitter)**를 반환값에 추가하기도 합니다 [6].
-- **추가적인 보안 완화 조치:** 타이머 자체를 통제하는 것 외에도, WebKit 등은 고해상도 타이머를 생성하는 데 악용될 수 있는 `SharedArrayBuffer`를 비활성화했습니다 [7]. 나아가 스펙터 공격의 근본 원인인 분기 제어(Branch control)를 차단하기 위해 **분기 없는 보안 검사(Branchless Security Checks)**, **인덱스 마스킹(Index masking)**, 그리고 **포인터 포이즈닝(Pointer poisoning)** 같은 구조적인 아키텍처 개선을 도입하고 있습니다 [11-13].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[Spectre]], [[Meltdown]], [[Speculative Execution]], [[Timestamp Queries]], [[Side-channel Attacks]]
-- **Projects/Contexts:** [[WebKit]], [[WebGPU]], [[WebGL]]
-- **Contradictions/Notes:** 소스에 따르면 WebGPU 및 WebGL의 고정밀 타임스탬프 쿼리 기능은 개발자의 성능 최적화(Profiling)를 위해 반드시 필요하지만, 타이밍 공격에 악용될 수 있는 치명적인 위험성을 동시에 안고 있습니다. 이 때문에 표준화 그룹과 브라우저 벤더들은 성능 분석 기능 제공과 보안 유지 사이에서 타협점(예: 사이트 격리 상태에 따른 타이머 해상도 축소 및 비활성화)을 찾아야만 했습니다 [8, 14].
-
----
-*Last updated: 2026-04-19*
-- Raw Source: [[00_Raw/2026-04-20/Timing Attacks.md]]
----
diff --git a/Programming & Language/To-Space와 From-Space.md b/Programming & Language/To-Space와 From-Space.md
deleted file mode 100644
index f84cfaf6..00000000
--- a/Programming & Language/To-Space와 From-Space.md	
+++ /dev/null
@@ -1,37 +0,0 @@
----
-id: P-REINFORCE-AUTO-3F32E9
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - To-Space와 From-Space"
----
-
-# [[To-Space와 From-Space]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> To-Space와 From-Space는 V8 자바스크립트 엔진의 가비지 컬렉션(GC) 과정에서 사용되는 'New Space(새로운 세대)' 내의 동일한 크기를 가진 두 개의 반공간(semi-space)입니다 [1-3]. 이 두 공간은 Cheney의 알고리즘을 기반으로 한 Scavenge(마이너 GC) 과정에서 메모리 단편화를 제거하고 살아남은 활성 객체를 효율적으로 복사 및 대피시키는 데 핵심적인 역할을 합니다 [1, 2, 4]. 공간이 가득 차면 활성 객체를 한 공간에서 다른 공간으로 복사한 뒤 두 공간의 역할을 맞바꾸는(swap) 방식으로 메모리를 관리합니다 [1, 4, 5].
-
-## 📖 구조화된 지식 (Synthesized Content)
-* **메모리 구조 및 할당 원리:** 
-  V8의 힙(Heap) 메모리 중 대부분의 새로운 객체가 할당되는 'New Space(Young Generation)'는 To-Space와 From-Space라는 동일한 크기의 두 공간으로 정확히 나뉩니다 [1, 2, 6]. 일반적인 마이너 GC(Scavenge) 알고리즘에서 새로운 객체 할당은 한쪽 공간에서 연속적으로 이루어지며, 나머지 절반의 공간은 가비지 컬렉션 발생 시 활성 객체의 대피(evacuation)를 위해 항상 비워둡니다 [1, 5, 7].
-* **가비지 컬렉션(Scavenge) 트리거와 역할 교환(Swap):** 
-  할당이 이루어지던 공간이 가득 차게 되면 마이너 GC가 트리거됩니다 [1, 2, 5, 6]. 이때 V8은 두 공간의 역할을 맞바꾸며(swap), 기존에 객체들이 있던 공간은 수집 대상인 From-Space가 되고, 비어 있던 공간은 활성 객체를 받을 To-Space가 됩니다 [1, 4, 8].
-* **객체 복사 및 압축(Compaction):** 
-  가비지 컬렉터는 루트(root) 객체에서 도달할 수 있는 활성 객체를 From-Space에서 찾아내어 To-Space의 연속된 메모리 블록으로 대피(복사)시킵니다 [4, 5, 9]. 복사된 객체들은 To-Space 내에 빈틈없이 압축(compact)되므로 새 공간의 메모리 단편화가 완전히 제거되며 캐시 지역성(cache locality)이 향상됩니다 [1, 4, 9].
-* **참조 업데이트 및 가비지 해제:** 
-  From-Space에 있던 객체가 To-Space로 이동할 때, 원래 객체의 첫 번째 단어(word) 위치에는 새 위치를 가리키는 포워딩 주소(forwarding address)가 남겨져 다른 참조 포인터들을 업데이트하는 데 사용됩니다 [10-12]. 모든 활성 객체의 복사가 완료되면 From-Space에 남은 나머지 데이터는 가비지(쓰레기)로 간주되어 완전히 비워집니다 [4, 5, 13]. 이후 두 번의 GC 주기를 생존한 객체는 더 이상 이 반공간들에 머물지 않고 Old Generation(Old Space)으로 승격(promotion)됩니다 [1, 4, 5].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[New Space]], [[Scavenger]], [[Cheney's Algorithm]], [[Garbage Collection]]
-- **Projects/Contexts:** [[V8 JavaScript Engine Memory Management]], [[Orinoco Garbage Collector]]
-- **Contradictions/Notes:** 소스 간에 새 객체가 최초로 할당되는 기본 공간의 명칭에 대해 설명이 엇갈립니다. 소스 [1, 14]는 새 객체가 'To-Space'에 할당되고 공간이 가득 차면 두 공간을 바꾼 후 From-Space에서 To-Space로 활성 객체를 복사한다고 설명합니다. 반면, 소스 [5, 6, 9]는 새 객체가 'From-Space'에 할당되며, 마이너 GC 발생 시 활성 객체를 비어있는 To-Space로 복사한 뒤 두 공간의 역할을 맞바꾸어 다시 비워진 From-Space에 새로운 할당을 진행한다고 상반되게 설명하고 있습니다.
-
----
-*Last updated: 2026-04-19*
-- Raw Source: [[00_Raw/2026-04-20/To-Space와 From-Space.md]]
----
diff --git a/Programming & Language/Toss Front SDK 기반 외부 연동사 플러그인 개발 생태계 구축.md b/Programming & Language/Toss Front SDK 기반 외부 연동사 플러그인 개발 생태계 구축.md
deleted file mode 100644
index 7864aa8c..00000000
--- a/Programming & Language/Toss Front SDK 기반 외부 연동사 플러그인 개발 생태계 구축.md	
+++ /dev/null
@@ -1,34 +0,0 @@
----
-id: P-REINFORCE-AUTO-C43BEF
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Toss Front SDK 기반 외부 연동사 플러그인 개발 생태계 구축"
----
-
-# [[Toss Front SDK 기반 외부 연동사 플러그인 개발 생태계 구축]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 토스플레이스는 자체 개발한 결제 단말기인 'Toss Front(프론트)'에서 동작하는 플러그인 앱을 외부 연동사가 개발할 수 있도록 돕는 SDK를 개발하고 있습니다 [1]. 이는 내부 개발에만 의존하지 않고 서드파티(3rd-party)의 참여를 통해 단말기 생태계를 무한히 확장하기 위한 구조입니다 [1]. 외부 연동사의 휴먼 에러를 방지하고 안정적인 생태계를 구축하기 위해, 토스는 퍼사드(Facade) 패턴을 활용하여 사용자의 의도(Intent)에 맞춘 직관적이고 안전한 SDK 인터페이스를 설계하는 데 집중하고 있습니다 [2, 3].
-
-## 📖 구조화된 지식 (Synthesized Content)
-- **플러그인 생태계 확장의 기반**: Toss Front SDK를 이용하면 외부 연동사는 토스 서비스의 데이터를 연동하여 자신들이 원하는 플러그인 앱을 개발하고 프론트에서 동작시킬 수 있습니다 [1]. 이러한 3rd-party 연동 구조는 프론트 생태계를 무한히 확장 가능하게 만드는 핵심적인 역할을 합니다 [1].
-- **안정성과 직결되는 SDK 사용성**: 외부 연동 생태계를 성장시키려면 훌륭한 사용 경험을 제공하는 SDK 인터페이스가 필수적입니다 [2]. SDK 사용의 복잡성이나 모호한 가이드는 핸들러 부착 누락이나 메모리 누수(Memory Leak) 같은 연동사의 휴먼 에러를 유발하며, 이는 곧 플랫폼 전체의 장애와 안정성 문제로 직결됩니다 [2, 4].
-- **퍼사드(Facade) 패턴을 통한 사용자 의도 중심 설계**: 토스는 SDK 내부의 복잡한 로직(인증, 재시도, 상태 관리 등)을 단순히 숨기는 것을 넘어, 사용자의 '의도(Intent)'를 기준으로 인터페이스를 재구성하는 퍼사드 패턴을 채택했습니다 [3]. 이를 통해 사용자는 자연스러운 목적만 표현하면 되며, 인지 부하와 결합도를 크게 낮출 수 있습니다 [3, 5].
-- **파레토 법칙에 따른 인터페이스 공존 전략**: 좋은 SDK는 퍼사드를 통한 고수준(High-level) API뿐만 아니라 저수준(Low-level) API도 함께 제공합니다 [5]. 80%의 흔한 유즈케이스는 고수준 퍼사드 인터페이스로 간단히 해결하게 하고, 20%의 세밀한 제어가 필요한 경우에는 저수준 인터페이스를 탈출구(Escape Hatch)로 제공하여 개발자 경험과 SDK의 장기적인 호환성, 유연성을 동시에 확보합니다 [5-7].
-- **단일 책임 원칙(SRP)에 기반한 리소스 관리**: 구조적 안정성을 위해 "리소스를 만든 곳에서 닫는다"는 단일 책임 원칙을 적용했습니다 [8]. 명확한 클린업(Cleanup) 책임을 SDK 인터페이스 구조에 녹여냄으로써 이벤트나 리스너가 누수되는 것을 원천적으로 방지하고 효율적인 리소스 관리를 유도합니다 [7, 8].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[Toss Front SDK]], [[Facade 패턴]], [[Single Responsibility Principle (SRP)]], [[Escape Hatch (탈출구)]]
-- **Projects/Contexts:** [[토스플레이스 결제 단말기 생태계 확장]]
-- **Contradictions/Notes:** 소스 내에 관련된 모순점이나 반대 의견은 존재하지 않습니다. 소스는 Toss Front SDK의 개발자 경험(DX)을 개선하고, 안정성을 확보하며, 휴먼 에러를 구조적으로 방지하기 위해 퍼사드 패턴과 책임 분리를 적용해야 한다는 일관된 주장을 펼치고 있습니다 [1, 3, 8].
-
----
-*Last updated: 2026-04-18*
-- Raw Source: [[00_Raw/2026-04-20/Toss Front SDK 기반 외부 연동사 플러그인 개발 생태계 구축.md]]
----
diff --git a/Programming & Language/Toss Front SDK의 Facade 패턴 적용 사례.md b/Programming & Language/Toss Front SDK의 Facade 패턴 적용 사례.md
deleted file mode 100644
index 8d9c9b36..00000000
--- a/Programming & Language/Toss Front SDK의 Facade 패턴 적용 사례.md	
+++ /dev/null
@@ -1,43 +0,0 @@
----
-id: P-REINFORCE-AUTO-E2FE05
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Toss Front SDK의 Facade 패턴 적용 사례"
----
-
-# [[Toss Front SDK의 Facade 패턴 적용 사례]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 토스플레이스(Tossplace)에서 자체 개발한 결제 단말기인 Toss Front의 외부 연동 SDK는 사용자의 개발 경험을 향상시키고 휴먼 에러를 방지하기 위해 Facade 패턴을 적용했습니다. [1, 2] 이 패턴은 단순히 내부 기능을 숨기는 것을 넘어, 인증이나 상태 관리 같은 복잡한 내부 구현을 사용자의 '의도(Intent)'를 기준으로 재구성하여 직관적인 인터페이스를 제공하는 데 목적이 있습니다. [3] 결과적으로 80%의 일반적인 사용 사례를 위한 고수준(High-level) 인터페이스와 20%의 세밀한 제어를 위한 저수준(Low-level) 탈출구를 함께 제공하여 편의성과 유연성의 균형을 맞추었습니다. [4, 5]
-
-## 📖 구조화된 지식 (Synthesized Content)
-*   **도입 배경과 휴먼 에러 방지:** 
-    Toss Front SDK는 3rd-party 연동사가 결제 단말기에서 동작하는 플러그인 앱을 개발할 수 있도록 지원합니다. [1] 초기에는 서버를 열고 닫는 단순한 기능임에도 연결 후 콜백 이벤트를 부착하거나 제거하는 책임이 사용자에게 암묵적으로 넘겨져 있었습니다. 이로 인해 핸들러 부착 해제가 누락되면 메모리 누수(Memory Leak)가 발생하고 SDK의 안정성 문제로 이어질 수 있었습니다. [2, 6] 따라서 사용자가 잘못된 방식을 사용할 수 없도록 원천적으로 방지하는 인터페이스 설계가 필요했습니다. [2]
-
-*   **의도(Intent) 기반의 Facade 패턴 재정의:**
-    토스팀은 Facade 패턴을 '복잡한 서브시스템을 단순한 인터페이스로 감싸는 것'을 넘어 '사용자의 의도 기준으로 다시 구성하는 것'으로 정의했습니다. [3] SDK 내부에 존재하는 인증, 재시도 로직, 클린업(Cleanup) 로직 등의 복잡한 오케스트레이션 로직을 숨기고, 사용자는 "서버를 시작한다"와 같이 자연스럽고 명확한 목적만 코드로 표현하도록 만들었습니다. [3, 5]
-
-*   **고수준과 저수준 인터페이스의 공존 (Escape Hatch):**
-    좋은 SDK 설계를 위해 고수준(High-level) 인터페이스와 저수준(Low-level) 인터페이스를 공존시켰습니다. [4] 
-    *   **High-level 인터페이스 (Facade):** 전체 사용 사례의 80%를 차지하는 흔한 유즈케이스를 한 번에 끝내는 워크플로우를 제공합니다. [4, 5]
-    *   **Low-level 인터페이스:** 나머지 20%의 특수한 요구사항이나 세밀한 제어가 필요할 때 사용할 수 있는 탈출구(Escape Hatch) 역할을 합니다. [4, 5]
-    *   이러한 분리를 통해 Facade 인터페이스를 지속적으로 개선하더라도 저수준 메서드는 안정적으로 유지되어 장기적인 호환성을 확보할 수 있습니다. [4, 7]
-
-*   **리소스 관리 책임의 내재화:**
-    SDK 내부에서 연결 별 동작을 Map으로 관리하고 연결 해제 시 클린업을 수행하도록 설계했습니다. [7] "리소스를 만든 곳에서 닫는다"는 단일 책임 원칙(SRP)을 SDK 내부에 적용함으로써, 사용자의 실수로 인한 이벤트 및 리스너 누수를 구조적으로 방지했습니다. [8]
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[Facade 패턴]], [[단일 책임 원칙(SRP)]], [[Escape Hatch (탈출구)]]
-- **Projects/Contexts:** [[Toss Front]], [[토스플레이스 결제 단말기 SDK]]
-- **Contradictions/Notes:** 소스에서는 Facade 패턴이 모든 문제의 정답은 아니며, 추상화 수준이 높아질수록 세밀한 제어가 제한되는 트레이드오프가 발생한다고 지적합니다. 이를 해결하기 위해 편리한 고수준 API에만 안주하지 않고, 언제든 저수준 인터페이스로 내려가 조작할 수 있는 '탈출구(Escape Hatch)'를 제공하여 설계의 균형을 잡아야 한다고 강조합니다. [5, 7]
-
----
-*Last updated: 2026-04-18*
-- Raw Source: [[00_Raw/2026-04-20/Toss Front SDK의 Facade 패턴 적용 사례.md]]
----
diff --git a/Programming & Language/Toss SDK의 퍼사드(Facade) 패턴 설계와 인터페이스 전략.md b/Programming & Language/Toss SDK의 퍼사드(Facade) 패턴 설계와 인터페이스 전략.md
deleted file mode 100644
index 3ff96ab3..00000000
--- a/Programming & Language/Toss SDK의 퍼사드(Facade) 패턴 설계와 인터페이스 전략.md	
+++ /dev/null
@@ -1,30 +0,0 @@
----
-id: P-REINFORCE-AUTO-E3649D
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Toss SDK의 퍼사드(Facade) 패턴 설계와 인터페이스 전략"
----
-
-# [[Toss SDK의 퍼사드(Facade) 패턴 설계와 인터페이스 전략]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> Toss Front SDK는 외부 연동사가 직관적으로 연동 앱을 개발할 수 있도록 퍼사드(Facade) 패턴을 적용하여 인터페이스를 설계했습니다. 이 설계의 핵심은 단순히 내부 기능을 숨기는 것이 아니라, 복잡한 로직을 사용자의 '의도(Intent)'를 기준으로 재구성하여 제공하는 것입니다. 흔하게 쓰이는 80%의 작업은 고수준 인터페이스로 제공해 편의성을 높이고, 20%의 특수한 상황을 위해 저수준 인터페이스를 탈출구(Escape Hatch)로 남겨두어 편의성과 유연성의 균형을 맞추고 개발자의 인지 부하를 크게 줄입니다.
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[Facade Pattern (퍼사드 패턴)]], [[단일 책임 원칙(SRP)]], [[Escape Hatch (탈출구)]]
-- **Projects/Contexts:** [[Toss Front SDK 기반 외부 연동사 플러그인 개발 생태계 구축]]
-- **Contradictions/Notes:** 내용 간의 상충되는 주장은 존재하지 않습니다. 다만 고수준으로 추상화된 퍼사드 패턴이 사용자 경험(DX)을 극대화하는 반면, SDK 내부적으로는 오케스트레이션 로직의 유지 비용과 복잡성을 심화시킨다는 명확한 트레이드오프가 존재함을 지적하고 있습니다 [6].
-
----
-*Last updated: 2026-04-18*
-- Raw Source: [[00_Raw/2026-04-20/Toss SDK의 퍼사드(Facade) 패턴 설계와 인터페이스 전략.md]]
----
diff --git a/Programming & Language/Turborepo 기반 모노레포 워크플로우.md b/Programming & Language/Turborepo 기반 모노레포 워크플로우.md
deleted file mode 100644
index c29737de..00000000
--- a/Programming & Language/Turborepo 기반 모노레포 워크플로우.md	
+++ /dev/null
@@ -1,34 +0,0 @@
----
-id: P-REINFORCE-AUTO-5397E2
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Turborepo 기반 모노레포 워크플로우"
----
-
-# [[Turborepo 기반 모노레포 워크플로우]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> Turborepo 기반 모노레포 워크플로우는 여러 패키지와 애플리케이션을 단일 저장소에서 효율적으로 관리하기 위해 린팅(ESLint) 및 포매팅(Prettier) 설정의 중복을 줄이고 실행 속도를 최적화하는 개발 프로세스입니다 [1], [2], [3]. 중앙 집중식 설정 패키지와 루트 오케스트레이션(Root Orchestration) 구성을 활용해 각 패키지의 자율성을 보장하면서도 변경된 파일에 대한 부분 검사와 Turborepo의 캐싱 이점을 극대화합니다 [4], [5], [6].
-
-## 📖 구조화된 지식 (Synthesized Content)
-- **기존 모노레포 환경의 한계:** 여러 Next.js 애플리케이션과 공유 라이브러리를 포함하는 대규모 모노레포에서는 패키지마다 `.eslintrc.json` 및 관련 설정 파일이 중복되는 유지보수 문제가 발생합니다 [7]. 특히 모노레포 루트(Root) 레벨에서 `lint-staged`를 실행할 때, 각 패키지에 맞는 린팅 규칙을 개별적으로 존중하도록 구성하는 것이 매우 까다롭습니다 [7].
-- **중앙 집중식 설정 패키지 도입:** 문제를 해결하기 위해 `@repo/eslint-config`와 같은 공통 내부 패키지를 생성하여 기본(Base), Next.js, 비-React 라이브러리용 프리셋(Preset) 구성을 만듭니다 [8]. 각 패키지는 이 프리셋을 임포트하여 단일 진실 공급원(Single source of truth)을 따르는 동시에, 필요시 패키지별 자율적인 오버라이드(override)를 적용할 수 있습니다 [4].
-- **루트 오케스트레이션 설정 (Root Orchestration Config):** 모노레포 루트에 위치한 `eslint.config.mjs` 파일에서 글로브(glob) 파일 패턴을 바탕으로 적절한 패키지 규칙에 매핑합니다 [5]. 이를 통해 전역 규칙을 적용하면서도 비-React 패키지와 Next.js 패키지의 경계를 명확하게 존중할 수 있습니다 [5].
-- **Husky와 Lint-staged의 효율적 연동:** 루트 오케스트레이션 구성이 마련되면 Husky의 pre-commit 훅을 통해 루트의 `lint-staged`가 실행됩니다 [6]. 이 과정에서 오직 변경된 파일만 식별되며, 루트 설정의 매핑에 따라 개별 패키지 룰에 맞게 빠르고 정확하게 린팅됩니다 [6], [9].
-- **Turborepo 캐싱 통합:** 공통 ESLint 설정 패키지를 `turbo.json`의 전역 의존성(global dependency)으로 추가함으로써 설정이 변경될 때 모든 패키지의 캐시가 적절히 무효화(invalidate) 되도록 구성합니다 [6]. 이는 결과적으로 린트 결과를 효과적으로 캐싱하여 작업 속도를 비약적으로 향상시킵니다 [6], [9].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[ESLint]], [[Prettier]], [[Husky]], [[Lint-staged]]
-- **Projects/Contexts:** [[Next.js 애플리케이션]], [[공유 라이브러리(Library) 환경]]
-- **Contradictions/Notes:** 소스에 상충하는 내용이나 관련 정보가 부족합니다. 다만 기존의 중복되고 분산된 설정 방식과, 중앙 집중화 및 루트 오케스트레이션을 도입한 현대적 방식 간의 개발자 경험(DX) 차이가 극적으로 향상됨을 강조합니다 [1], [9].
-
----
-*Last updated: 2026-04-19*
-- Raw Source: [[00_Raw/2026-04-20/Turborepo 기반 모노레포 워크플로우.md]]
----
diff --git a/Programming & Language/Turborepo 환경 구성.md b/Programming & Language/Turborepo 환경 구성.md
deleted file mode 100644
index 60512cfb..00000000
--- a/Programming & Language/Turborepo 환경 구성.md	
+++ /dev/null
@@ -1,34 +0,0 @@
----
-id: P-REINFORCE-AUTO-C5884C
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Turborepo 환경 구성"
----
-
-# [[Turborepo 환경 구성]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> Turborepo 모노레포 환경에서 ESLint, Prettier, lint-staged를 효율적으로 관리하기 위한 구성 방법입니다 [1]. 여러 패키지에 분산된 중복 설정과 규칙의 불일치 문제를 해결하기 위해 고안되었습니다 [1, 2]. 중앙 집중식 설정 패키지와 루트 오케스트레이션(Root Orchestration)을 결합하여, 각 패키지의 규칙을 존중하면서도 빠르고 확장 가능한 린팅 환경을 제공합니다 [3, 4].
-
-## 📖 구조화된 지식 (Synthesized Content)
-- **중앙 집중식 구성 패키지 구축:** 모노레포 내에 별도의 설정 패키지(예: `@repo/eslint-config`)를 생성하여 Base, Next.js, Library용으로 조합 가능한 프리셋(preset) 설정을 제공합니다 [5, 6]. 이 패키지는 ESLint 9의 평면 구성(flat config) 형식을 사용하며, 전체 모노레포의 린팅 규칙을 제어하는 단일 진실 공급원(Single source of truth) 역할을 합니다 [5, 7].
-- **패키지별 자율성 보장:** 개별 패키지에는 최소한의 `eslint.config.mjs` 파일만 남겨두고 중앙 패키지의 프리셋을 임포트하여 사용합니다 [7]. 이를 통해 전체 코어 규칙을 일관되게 관리하면서도, 필요한 경우 특정 패키지에서 개별적인 규칙 오버라이드(override)를 수행할 수 있는 자율성을 얻을 수 있습니다 [7, 8].
-- **루트 오케스트레이션 (Root Orchestration):** 모노레포 루트에 위치한 `eslint.config.mjs`에서 파일 패턴(glob 패턴)을 활용해 각 패키지를 적절한 설정에 매핑합니다 [9]. 이는 `lint-staged`와 Husky 같은 도구가 모노레포 루트에서 실행될 때 각 패키지의 경계와 고유 린팅 규칙을 정확하게 준수하도록 보장하는 핵심 설정입니다 [4, 9].
-- **Husky 및 lint-staged 통합:** 루트 `package.json` 파일과 Husky의 `pre-commit` 훅을 연동하여, 코드가 커밋될 때 루트 설정에 따라 변경된 파일만 효율적으로 린팅하도록 구성합니다 [10].
-- **Turborepo 캐시 무효화 적용:** `turbo.json` 설정 내 전역 의존성(`globalDependencies`)에 ESLint 설정 패키지를 등록합니다 [10]. 이를 통해 중앙의 린팅 설정이 변경될 때마다 Turborepo가 모든 관련 패키지의 캐시를 정확히 무효화(invalidate)하도록 처리합니다 [10].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[ESLint]], [[Prettier]], [[lint-staged]], [[Husky]], [[Monorepo]]
-- **Projects/Contexts:** [[Turborepo 기반 다중 패키지 프로젝트의 린팅 및 코드 포매팅 자동화 파이프라인 구축]]
-- **Contradictions/Notes:** 소스는 ESLint 9의 평면 구성 형식을 기준으로 최적의 환경 구성법을 제안하고 있습니다. 만약 ESLint 8 환경을 이용할 경우에는 `eslint.config.mjs` 대신 `.eslintrc.js`를 사용하고 ES 모듈 대신 CommonJS를 사용해야 하는 등 이전 형식에 맞춘 구조적 조정이 별도로 필요합니다 [11].
-
----
-*Last updated: 2026-04-19*
-- Raw Source: [[00_Raw/2026-04-20/Turborepo 환경 구성.md]]
----
diff --git a/Programming & Language/Turborepo.md b/Programming & Language/Turborepo.md
deleted file mode 100644
index 486a3bd2..00000000
--- a/Programming & Language/Turborepo.md	
+++ /dev/null
@@ -1,32 +0,0 @@
----
-id: P-REINFORCE-AUTO-9E8212
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Turborepo"
----
-
-# [[Turborepo]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> Turborepo는 여러 애플리케이션과 라이브러리 패키지를 하나의 저장소에서 관리하는 모노레포(Monorepo) 환경을 위한 빌드 도구입니다 [1, 2]. 작업 결과를 저장하고 재사용하는 캐싱(Caching) 기능을 지원하여 개발 워크플로우와 커밋 속도를 크게 향상시킵니다 [3, 4]. Nx, Bazel, Lerna 등과 함께 대표적인 모노레포 관리 솔루션 중 하나로 꼽힙니다 [5].
-
-## 📖 구조화된 지식 (Synthesized Content)
-- **복잡한 모노레포 환경 관리**: Turborepo는 다수의 Next.js 애플리케이션, 공유 컴포넌트 및 유틸리티를 포함하는 라이브러리 패키지, API 클라이언트와 같은 공유 코드를 아우르는 대규모 모노레포 구조를 효과적으로 관리할 수 있게 해줍니다 [2, 6].
-- **캐싱(Caching)을 통한 성능 최적화**: Turborepo의 가장 큰 특징 중 하나는 여러 번의 실행에 걸쳐 린트(Lint) 등의 작업 결과를 캐싱하여 재사용한다는 점입니다 [4]. `turbo.json` 설정 파일에 글로벌 의존성을 추가하면, 해당 설정이 변경될 때만 Turborepo가 전체 패키지의 캐시를 무효화(invalidate)하여 불필요한 반복 작업을 방지합니다 [7].
-- **개발 도구와의 중앙 집중식 통합**: Turborepo 환경에서 ESLint, Prettier, lint-staged, Husky 등을 설정할 때, 루트(root) 오케스트레이션과 중앙 집중식 구성 패키지를 활용하면 설정 파일의 중복을 막을 수 있습니다 [1, 8]. 이를 통해 각 패키지의 자율성을 존중하면서도 규칙의 단일 진실 공급원(Single source of truth)을 유지할 수 있으며, 캐싱 기능과 시너지를 내어 빠르고 유지보수하기 쉬운 환경을 구축할 수 있습니다 [3, 4, 9, 10].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[Monorepo]], [[ESLint]], [[Prettier]]
-- **Projects/Contexts:** [[Next.js]], [[Husky]], [[lint-staged]]
-- **Contradictions/Notes:** 소스에 관련 정보가 부족합니다.
-
----
-*Last updated: 2026-04-19*
-- Raw Source: [[00_Raw/2026-04-20/Turborepo.md]]
----
diff --git a/Programming & Language/Turborepo를 활용한 다중 애플리케이션 및 라이브러리 통합 관리.md b/Programming & Language/Turborepo를 활용한 다중 애플리케이션 및 라이브러리 통합 관리.md
deleted file mode 100644
index cf03490d..00000000
--- a/Programming & Language/Turborepo를 활용한 다중 애플리케이션 및 라이브러리 통합 관리.md	
+++ /dev/null
@@ -1,40 +0,0 @@
----
-id: P-REINFORCE-AUTO-F2D6B7
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Turborepo를 활용한 다중 애플리케이션 및 라이브러리 통합 관리"
----
-
-# [[Turborepo를 활용한 다중 애플리케이션 및 라이브러리 통합 관리]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> Turborepo를 활용한 모노레포(Monorepo) 환경에서 다중 애플리케이션(Next.js 등) 및 공유 라이브러리의 린팅(ESLint)과 포매팅(Prettier)을 효율적으로 통합 관리하는 아키텍처에 대한 내용입니다. 중앙 집중식 설정 패키지와 루트 오케스트레이션(Root Orchestration) 기법을 도입함으로써, 패키지별 설정 중복을 방지하고 각 프로젝트의 자율성을 보장하면서도 일관되고 빠른 코드 품질 관리를 달성할 수 있습니다.
-
-## 📖 구조화된 지식 (Synthesized Content)
-* **기존 모노레포 관리의 문제점**
-  여러 애플리케이션(Next.js 등)과 공유 라이브러리를 포함하는 대규모 모노레포 구조에서는 `.eslintrc.json` 및 `.eslintignore`와 같은 설정 파일이 각 패키지마다 중복 생성되는 문제가 흔히 발생합니다 [1, 2]. 이로 인해 구성의 일관성이 무너지고 전역적으로 규칙을 업데이트하기가 어려워지며, 특히 모노레포 루트(Root)에서 `lint-staged`를 실행할 때 각 패키지에 맞는 린팅 규칙을 선별적으로 적용하는 것에 한계가 생깁니다 [2, 3].
-
-* **중앙 집중식 구성과 루트 오케스트레이션 적용**
-  이러한 문제를 해결하기 위해 3단계로 이루어진 구성 아키텍처를 도입할 수 있습니다.
-  1. **중앙 집중식 ESLint 구성 패키지 생성**: 모노레포 내부에 공통으로 사용할 설정 패키지(예: `@repo/eslint-config`)를 만듭니다. 이 패키지는 Base, Next.js, 외부 라이브러리 전용 등 목적에 맞게 결합 가능한 프리셋(Preset)을 내보냅니다 [4, 5]. 이 공통 패키지에서 Prettier 통합 및 Turborepo 특화 규칙 등을 단일 진실 공급원(Single Source of Truth)으로 선언합니다 [3, 5, 6].
-  2. **패키지 레벨 설정의 최소화**: 각 애플리케이션 및 라이브러리 패키지에는 최소한의 `eslint.config.mjs` 파일만 위치시킵니다. 이 파일은 중앙 구성 패키지의 프리셋을 가져와 적용하며, 필요한 경우 특정 패키지만의 예외 규칙을 오버라이드할 수 있어 자율성을 유지합니다 [6].
-  3. **루트 오케스트레이션(Root Orchestration)**: 모노레포 최상위 디렉토리에 파일 패턴을 기반으로 각 패키지에 맞는 구성을 매핑하는 오케스트레이션 파일을 생성합니다. 이를 통해 루트에서 린트를 실행하더라도 파일 경로를 인식하여 올바른 패키지 규칙이 적용됩니다 [7, 8].
-
-* **Turborepo 캐싱과 Husky, lint-staged 통합 최적화**
-  루트 오케스트레이션이 완성되면, `Husky`의 pre-commit 훅을 통해 `lint-staged`를 실행할 때 변경된 파일에 대해서만 빠르고 정확한 린팅을 수행할 수 있습니다 [8]. 추가적으로, `turbo.json` 설정 파일에 ESLint 구성 패키지를 글로벌 의존성(global dependency)으로 명시하면, 공통 설정이 변경될 때마다 Turborepo가 모든 패키지의 린트 캐시를 지능적으로 무효화합니다 [8]. 이를 통해 불필요한 중복 검사를 줄이고 린트 캐싱 성능을 극대화하여 전체적인 개발과 커밋 속도를 크게 단축할 수 있습니다 [9-11].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[모노레포(Monorepo)]], [[ESLint 및 Prettier 통합]], [[lint-staged와 Husky]]
-- **Projects/Contexts:** [[Turborepo 기반의 확장 가능한 프론트엔드 환경 구축 및 중앙 집중형 코드 거버넌스]]
-- **Contradictions/Notes:** 모노레포 내 각 패키지마다 독립된 설정과 의존성을 중복해서 유지하는 전통적인 방식에 반대하며, 단일 진실 공급원(Single source of truth) 역할을 하는 전용 설정 패키지를 구축하여 루트에서 일괄 오케스트레이션하는 현대적이고 통합적인 관리 체계를 지향합니다 [2, 6, 10].
-
----
-*Last updated: 2026-04-19*
-- Raw Source: [[00_Raw/2026-04-20/Turborepo를 활용한 다중 애플리케이션 및 라이브러리 통합 관리.md]]
----
diff --git a/Programming & Language/Type Casting.md b/Programming & Language/Type Casting.md
deleted file mode 100644
index 5300bf9e..00000000
--- a/Programming & Language/Type Casting.md	
+++ /dev/null
@@ -1,33 +0,0 @@
----
-id: P-REINFORCE-AUTO-2B5557
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Type Casting"
----
-
-# [[Type Casting]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 타입 캐스팅(Type Casting) 또는 타입 단언(Type Assertion)은 개발자가 TypeScript 컴파일러보다 값의 타입에 대해 더 잘 알고 있을 때, 컴파일러에게 특정 값의 타입을 지정하도록 강제하는 방법입니다 [1]. 다른 언어의 타입 캐스트와 유사하지만 데이터의 구조를 재구성(restructuring)하거나 특별한 검사를 수행하지 않으며, 런타임 동작에 아무런 영향을 주지 않습니다 [1]. 이는 오로지 컴파일러에 의해서만 소비되며, 개발자가 값의 타입을 확신할 때 예외적으로 사용해야 합니다 [1, 2].
-
-## 📖 구조화된 지식 (Synthesized Content)
-- **문법 및 작동 방식:** 타입 캐스팅은 주로 `as` 키워드를 사용하여 구현됩니다(예: `value as Type`) [1]. 이 방식은 JSX/TSX 환경에서 지원되는 유일한 문법입니다 [1]. 런타임 시 객체에 프로퍼티를 추가하거나 변형하지 않고, 단지 컴파일러에게 해당 값을 지정된 타입으로 취급하도록 지시합니다 [1, 3].
-- **주요 활용 사례:** DOM 조작을 수행하거나 런타임에서 별도로 검증을 마친 외부 데이터를 처리할 때 주로 사용됩니다 [2]. 또한 Branded Types(브랜디드 타입)이나 Strong/Super Opaque Types(강한/초강력 불투명 타입)을 정의하고 사용할 때, 런타임에 브랜드 속성을 추가하지 않고도 컴파일러에게 타입 구분을 강제하기 위해 명시적인 캐스팅이 필수적으로 활용됩니다 [3-6].
-- **타입 캐스팅의 위험성:** `as` 단언은 개발자가 잘못 판단한 경우에도 타입 에러를 우회하게 만들어 예기치 않은 버그를 초래할 수 있습니다 [2, 7]. 특히, `as`를 통한 캐스팅은 초과 속성 검사(Excess Property Checks)를 무시하기 때문에, 대상 타입에 명시되지 않은 초과 속성이 객체에 존재하더라도 컴파일러가 이를 허용하는 조용한 에러(silent errors)를 유발할 수 있습니다 [8].
-- **한계 및 안전한 대안:** 객체가 대상 타입과 근본적으로 호환되지 않을 경우(필수 속성 누락 등) TypeScript는 타입 캐스트를 거부합니다 [9]. 이 경우 값을 `unknown`으로 먼저 캐스팅한 후 다시 원하는 타입으로 캐스팅하여 우회할 수 있으나, 이는 권장되지 않는 패턴입니다 [9]. 맹목적인 캐스팅보다는 런타임에 값을 검증하는 타입 가드(Type Predicates/Guards) 함수나, 구체적인 타입을 유지하면서도 초과 속성 검사를 강제할 수 있는 `satisfies` 연산자를 활용하는 것이 더 안전한 설계입니다 [9-12].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[Type Assertion]], [[Type Guards]], [[Satisfies Operator]], [[Branded Types]], [[unknown]]
-- **Projects/Contexts:** [[DOM Manipulation]], [[Type System Design]]
-- **Contradictions/Notes:** 소스에서는 `as` 키워드를 사용한 타입 캐스팅이 타입 에러를 우회하는 강력한 수단이지만, 초과 속성 검사를 건너뛰어 안전성을 훼손하므로, 구조적 엄격함을 유지해야 하는 데이터 변환 및 매핑 상황에서는 캐스팅보다 `satisfies` 키워드를 사용하는 것을 우선적으로 권장합니다 [8, 9].
-
----
-*Last updated: 2026-04-18*
-- Raw Source: [[00_Raw/2026-04-20/Type Casting.md]]
----
diff --git a/Programming & Language/Type Inference.md b/Programming & Language/Type Inference.md
deleted file mode 100644
index 341b178e..00000000
--- a/Programming & Language/Type Inference.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-75C521
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Type Inference"
----
-
-# [[Type Inference]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Type Inference.md]]
----
diff --git a/Programming & Language/Type Narrowing.md b/Programming & Language/Type Narrowing.md
deleted file mode 100644
index 08b5946d..00000000
--- a/Programming & Language/Type Narrowing.md	
+++ /dev/null
@@ -1,43 +0,0 @@
----
-id: P-REINFORCE-AUTO-325DC7
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Type Narrowing"
----
-
-# [[Type Narrowing]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-- **동작 원리와 필요성**
-  타입스크립트의 타입 좁히기는 유니온 타입이나 `unknown` 타입처럼 변수가 여러 타입을 가질 수 있을 때 필수적인 과정입니다 [3, 5]. 유니온 타입의 값에서 타입별 특화된 속성에 접근하기 위해서는 반드시 먼저 타입을 좁혀야 하며, 그렇지 않으면 타입 에러가 발생할 수 있습니다 [1]. 타입스크립트의 제어 흐름 분석기(control flow analysis)는 조건문(`if`, `switch` 등) 내부의 검증 로직을 이해하고, 해당 블록 내에서 변수를 구체화된 타입으로 자동 인식합니다 [3].
-
-- **타입 가드(Type Guards)를 통한 좁히기 기법**
-  타입스크립트는 런타임 동작을 기반으로 타입을 좁히기 위해 다양한 기법을 지원합니다 [6, 7]:
-  - **`typeof` 검사:** `typeof v === "typename"` 형식으로 사용하며, "number", "string", "boolean", "symbol" 등의 원시 타입을 좁힙니다 [7, 8].
-  - **`instanceof` 검사:** 생성자 함수의 프로토타입을 확인하여 해당 생성자의 인스턴스로 타입을 좁힙니다 [7, 8].
-  - **동등성 검사 및 `in` 연산자:** 변수의 특정 값 일치 여부나, 객체 내 특정 속성의 존재(`in` 연산자)를 확인하여 객체의 타입을 좁힐 수 있습니다 [3, 7].
-
-- **사용자 정의 타입 가드 (Type Predicates)**
-  내장된 타입 가드 외에도 반환 타입에 `is` 키워드를 활용해 커스텀 타입 가드 함수를 만들 수 있습니다 [8]. 이 함수는 특정 매개변수가 특정 타입인지 여부를 불리언 값으로 반환하며, 이 결과에 따라 타입 시스템이 타입 좁히기를 적용하게 됩니다 [9].
-
-- **식별 가능한 유니온 (Discriminated Unions)**
-  공유되는 리터럴 속성(판별자, discriminant)을 사용하여 여러 객체의 집합을 특정한 하나의 객체로 좁히는 강력한 패턴입니다 [2, 10]. `switch`나 `if` 문을 사용해 판별자 속성 값을 비교하면, 타입스크립트는 추가적인 수동 검사 없이 조건에 맞추어 타입을 좁혀줍니다 [10, 11].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[Type Guards]], [[Discriminated Unions]], [[Union Types]], [[Type Predicates]]
-- **Projects/Contexts:** 알 수 없는 외부 데이터를 수신하는 상황(`unknown` 타입 처리), API 응답 상태(loading/success/error), Redux 리듀서 액션, 또는 다단계 폼 및 라우터 상태 등 다형성 데이터를 구별하여 안전하게 처리해야 하는 구조적 맥락에서 빈번하게 사용됩니다 [3, 12, 13].
-- **Contradictions/Notes:** 컴파일러에게 개발자가 직접 타입을 가정하도록 강제하는 타입 단언(Type Assertions, `as` 키워드 사용)과 달리, 타입 좁히기(Type Narrowing)는 코드의 제어 흐름과 타입 가드를 기반으로 타입스크립트가 스스로 안전하게 타입을 추론하고 좁힌다는 점에서 안전성 면에서 큰 차이가 있습니다 [3, 9, 14, 15].
-
----
-*Last updated: 2026-04-18*
-- Raw Source: [[00_Raw/2026-04-20/Type Narrowing.md]]
----
diff --git a/Programming & Language/Type Predicates.md b/Programming & Language/Type Predicates.md
deleted file mode 100644
index 86ef9e96..00000000
--- a/Programming & Language/Type Predicates.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-1D7E99
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Type Predicates"
----
-
-# [[Type Predicates]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Type Predicates.md]]
----
diff --git a/Programming & Language/Type-Assertion.md b/Programming & Language/Type-Assertion.md
deleted file mode 100644
index 1b87f742..00000000
--- a/Programming & Language/Type-Assertion.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-1404CE
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Type-Assertion"
----
-
-# [[Type-Assertion]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Type-Assertion.md]]
----
diff --git a/Programming & Language/Type-Erasure.md b/Programming & Language/Type-Erasure.md
deleted file mode 100644
index 0497a966..00000000
--- a/Programming & Language/Type-Erasure.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-565E28
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Type-Erasure"
----
-
-# [[Type-Erasure]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Type-Erasure.md]]
----
diff --git a/Programming & Language/Type-Inference-Algorithms.md b/Programming & Language/Type-Inference-Algorithms.md
deleted file mode 100644
index e58d9840..00000000
--- a/Programming & Language/Type-Inference-Algorithms.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-0EC835
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Type-Inference-Algorithms"
----
-
-# [[Type-Inference-Algorithms]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Type-Inference-Algorithms.md]]
----
diff --git a/Programming & Language/Type-Narrowing-Mechanisms.md b/Programming & Language/Type-Narrowing-Mechanisms.md
deleted file mode 100644
index 2a096030..00000000
--- a/Programming & Language/Type-Narrowing-Mechanisms.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-8D1630
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Type-Narrowing-Mechanisms"
----
-
-# [[Type-Narrowing-Mechanisms]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Type-Narrowing-Mechanisms.md]]
----
diff --git a/Programming & Language/Type-Narrowing-and-Control-Flow-Analysis.md b/Programming & Language/Type-Narrowing-and-Control-Flow-Analysis.md
deleted file mode 100644
index d786c7fb..00000000
--- a/Programming & Language/Type-Narrowing-and-Control-Flow-Analysis.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-DD413B
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Type-Narrowing-and-Control-Flow-Analysis"
----
-
-# [[Type-Narrowing-and-Control-Flow-Analysis]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Type-Narrowing-and-Control-Flow-Analysis.md]]
----
diff --git a/Programming & Language/Type-Narrowing-and-Guards.md b/Programming & Language/Type-Narrowing-and-Guards.md
deleted file mode 100644
index ee3d32a3..00000000
--- a/Programming & Language/Type-Narrowing-and-Guards.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-D8EC83
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Type-Narrowing-and-Guards"
----
-
-# [[Type-Narrowing-and-Guards]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Type-Narrowing-and-Guards.md]]
----
diff --git a/Programming & Language/Type-Predicates.md b/Programming & Language/Type-Predicates.md
deleted file mode 100644
index 6d1f306a..00000000
--- a/Programming & Language/Type-Predicates.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-62E7D2
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Type-Predicates"
----
-
-# [[Type-Predicates]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Type-Predicates.md]]
----
diff --git a/Programming & Language/Type-safe Error Handling  Exhaustiveness Checking.md b/Programming & Language/Type-safe Error Handling  Exhaustiveness Checking.md
deleted file mode 100644
index faf59873..00000000
--- a/Programming & Language/Type-safe Error Handling  Exhaustiveness Checking.md	
+++ /dev/null
@@ -1,33 +0,0 @@
----
-id: P-REINFORCE-AUTO-E20F27
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Type-safe Error Handling  Exhaustiveness Checking"
----
-
-# [[Type-safe Error Handling  Exhaustiveness Checking]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 타입 안전한 에러 처리(Type-safe Error Handling)와 철저함 검사(Exhaustiveness Checking)는 타입 시스템을 활용하여 예상 가능한 에러와 상태 변화를 컴파일 타임에 제어하는 기법입니다. 예외(Exception)를 무분별하게 던지는 대신 반환 타입(예: Result 타입이나 식별 가능한 유니온)에 에러를 명시하여, 함수의 시그니처만으로도 발생 가능한 실패를 미리 파악하고 대응하게 만듭니다 [1, 2]. 이에 더해 철저함 검사는 제어문(switch 등)에서 에러나 유니온 타입의 모든 가능한 케이스가 누락 없이 처리되었는지를 컴파일러가 강제로 확인하게 하여 런타임 에러를 방지합니다 [3, 4].
-
-## 📖 구조화된 지식 (Synthesized Content)
-- **예외(Exception) 던지기 지양 및 Result 타입 활용:** 애플리케이션 실행 흐름을 무작위로 깨뜨리고 타입 시스템에 드러나지 않는 예외(throw error) 대신, 예상되는 에러(Expected errors)를 `Result` 타입 등으로 반환하는 것이 권장됩니다 [5-7]. `neverthrow`와 같은 라이브러리를 활용하면 반환 타입을 `Ok<Data, never> | Err<never, ExpectedError>` 형태로 정의할 수 있어, 개발자가 내부 비즈니스 로직을 보지 않고도 처리해야 할 에러를 명확히 인지할 수 있습니다 [1, 6]. 진짜 예외(예기치 않은 결함)에 대해서만 throw를 사용하는 것이 좋습니다 [1, 8-10].
-- **식별 가능한 유니온 (Discriminated Unions)을 통한 모델링:** 성공과 다양한 실패 상태를 공통된 태그(예: `kind`, `type`, `_tag` 속성)로 구분하는 식별 가능한 유니온을 사용하면 유효하지 않은 상태가 공존하는 것을 구조적으로 방지할 수 있습니다 [11-13]. 이는 복잡한 API 응답 처리, 에러 핸들링, 상태 머신 모델링에 매우 효과적입니다 [14, 15].
-- **철저함 검사 (Exhaustiveness Checking) 메커니즘:** 식별 가능한 유니온이나 에러 타입을 분기 처리(switch 문 등)할 때, TypeScript는 모든 케이스가 명시적으로 처리되었는지 검증할 수 있습니다 [4, 16]. 만약 시스템 확장으로 인해 새로운 형태의 에러나 타입이 유니온에 추가되었으나 분기 로직에 반영되지 않았다면, 컴파일러가 이를 즉각 감지하여 에러를 발생시킵니다 [3, 4, 17].
-- **`never` 타입을 활용한 검사 구현:** 가장 흔한 네이티브 철저함 검사 방식은 모든 케이스를 처리한 후 남는 `default` 블록에서 값을 `never` 타입에 할당하거나 전용 검사 함수(`assertNever`)로 전달하는 것입니다 [18, 19]. 분기에서 누락된 케이스가 있다면 해당 값은 실제 타입을 가지므로 `never` 타입에 할당될 수 없어 컴파일 타입 에러(예: `Type 'Pentagon' is not assignable to type 'never'`)를 냅니다 [4, 19, 20].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[Discriminated Unions]], [[The never Type]], [[Result Type]]
-- **Projects/Contexts:** [[neverthrow 라이브러리]], [[ts-pattern 라이브러리]]
-- **Contradictions/Notes:** 분기 처리 시 `ts-pattern` 라이브러리의 `.exhaustive()`를 사용하여 철저함 검사를 손쉽게 수행할 수 있으나, 네이티브 `if/else`나 `switch` 문에 `satisfies never`를 결합하는 방식에 비해 패턴 매칭 연산 성능이 99% 이상 떨어질 수 있어 오버엔지니어링을 경계해야 한다는 지적이 있습니다 [20-22]. 또한, 일부 언어(예: C#) 생태계에서는 예외 처리가 언어 표준 프레임워크 설계에 더 부합한다는 이유로 Result 타입을 과도한 보일러플레이트로 간주하는 비판적 의견도 존재합니다 [23, 24].
-
----
-*Last updated: 2026-04-18*
-- Raw Source: [[00_Raw/2026-04-20/Type-safe Error Handling & Exhaustiveness Checking.md]]
----
diff --git a/Programming & Language/TypeScript 49.md b/Programming & Language/TypeScript 49.md
deleted file mode 100644
index afba6201..00000000
--- a/Programming & Language/TypeScript 49.md	
+++ /dev/null
@@ -1,33 +0,0 @@
----
-id: P-REINFORCE-AUTO-33CE04
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - TypeScript 49"
----
-
-# [[TypeScript 49]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> TypeScript 4.9는 객체의 구조 검증과 구체적인 타입(literal types) 유지 사이의 딜레마를 해결하기 위해 `satisfies` 연산자를 새롭게 도입한 주요 릴리스입니다 [1, 2]. 이 버전을 통해 개발자는 타입 추론의 정확성을 잃지 않으면서도 엄격한 타입 안정성을 강제할 수 있게 되었습니다 [1, 3].
-
-## 📖 구조화된 지식 (Synthesized Content)
-- **`satisfies` 연산자 도입**: TypeScript 4.9의 핵심적인 변화는 `satisfies` 연산자의 추가입니다 [1, 2]. 기존의 타입 어노테이션(`:`)은 객체의 리터럴 타입을 일반적인 타입(예: 특정 문자열이 일반 `string`으로)으로 넓히는(widening) 문제가 있었고, 타입 단언(`as`)은 타입 검증을 건너뛰게 만드는 위험이 있었습니다 [1, 2, 4].
-- **타입 안전성과 구체성 동시 확보**: 4.9에 도입된 `satisfies`는 대상 객체가 특정 인터페이스나 타입의 요구사항을 충족하는지 검사하면서도, 개발자가 정의한 구체적인 값(리터럴 타입)을 그대로 유지시킵니다 [2, 5].
-- **과잉 속성 체크(Excess Property Checking) 문제 해결**: TypeScript의 구조적 타이핑에서는 간접 할당 시 과잉 속성 체크가 작동하지 않아 의도치 않은 데이터가 섞이는 취약점이 있습니다 [6]. `satisfies` 연산자는 이러한 간접 할당 시에도 엄격한 속성 검사를 수행할 수 있는 기반을 마련하여 과잉 속성의 유입을 차단합니다 [2].
-- **고급 패턴과의 결합**: 이 연산자는 식별 가능한 유니온(Discriminated Unions)에서 판별자의 리터럴 타입을 보존해 타입 좁히기(Type narrowing)를 가능하게 합니다 [7]. 또한 `as const`와 결합하여 검증과 불변성(Immutability)을 동시에 만족시키는 객체를 생성할 수 있도록 지원합니다 [8].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[satisfies Operator]], [[Excess Property Checking]], [[Structural Typing]], [[Type Narrowing]]
-- **Projects/Contexts:** [[Type Safety Verification]], [[Object Structure Validation]]
-- **Contradictions/Notes:** 주어진 소스 내에서 TypeScript 4.9와 관련된 설명은 전적으로 `satisfies` 연산자의 도입과 그로 인한 타입 검증 시스템의 변화에 집중되어 있으며, 그 외 TypeScript 4.9의 다른 기능 업데이트에 대해서는 소스에 관련 정보가 부족합니다.
-
----
-*Last updated: 2026-04-18*
-- Raw Source: [[00_Raw/2026-04-20/TypeScript 4.9.md]]
----
diff --git a/Programming & Language/TypeScript API Development.md b/Programming & Language/TypeScript API Development.md
deleted file mode 100644
index 32a8c179..00000000
--- a/Programming & Language/TypeScript API Development.md	
+++ /dev/null
@@ -1,43 +0,0 @@
----
-id: P-REINFORCE-AUTO-7B86BE
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - TypeScript API Development"
----
-
-# [[TypeScript API Development]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> TypeScript API 개발은 강력한 타입 시스템을 활용하여 시스템 경계에서 데이터를 안전하게 검증하고, 예측 가능한 에러 모델을 구축하며, 클라이언트와 서버 간의 견고한 인터페이스를 설계하는 과정입니다 [1-3]. 이를 통해 런타임 에러를 방지하고 안정적인 데이터 통신 계약(Contract)을 확립할 수 있습니다 [1, 4].
-
-## 📖 구조화된 지식 (Synthesized Content)
-*   **경계에서의 파싱 (Parse, don't validate)**
-    API 요청과 응답이 이루어지는 시스템의 경계(Boundary)에서는 들어오는 알 수 없는 데이터를 단 한 번 파싱하여 타입이 완벽하게 정의된 데이터로 변환해야 합니다 [1, 5]. 이 접근법을 사용하면 시스템 내부 로직 전체에 걸쳐 유효성 검사 코드를 흩뿌릴 필요 없이 정적 타입 분석의 이점을 최대한 누릴 수 있습니다 [1].
-
-*   **명시적인 에러 반환과 컨트롤러 설계**
-    API 컨트롤러는 들어오는 요청부터 반환되는 응답까지의 모든 제어 흐름을 명확하게 파악할 수 있도록 작성되어야 합니다 [6]. 특히 하위 서버 응답 지연이나 잘못된 요청(400 Bad Request)과 같은 **예측 가능한 에러의 경우, 예외(Exception)를 무분별하게 던지기보다는 명시적인 에러 타입(Result 객체 등)으로 반환**하는 것이 권장됩니다 [7, 8]. 이를 통해 개발자는 API 함수의 반환 타입만 보고도 예상되는 에러 상황을 명확하게 파악할 수 있습니다 [2, 9].
-
-*   **식별 가능한 유니온(Discriminated Unions)을 활용한 응답 모델링**
-    API의 응답은 종종 로딩, 성공, 실패 등 다양한 형태로 반환됩니다 [3, 10]. **식별 가능한 유니온을 사용하면 이러한 API 응답 상태를 매우 효과적으로 모델링**할 수 있으며, 컴파일러의 철저한 검사(Exhaustiveness Checking)를 통해 특정 응답 상태에 대한 처리가 누락되는 것을 컴파일 시점에 방지할 수 있습니다 [3, 11].
-
-*   **브랜디드 타입(Branded Types)과 런타임 검증 결합**
-    API를 통해 전달되는 `UserId`나 `OrderId` 같은 데이터는 구조적으로 동일한 문자열(String) 타입일지라도 의미적으로 철저히 구분되어야 합니다 [12, 13]. 이들을 혼용하는 실수를 막기 위해 **브랜디드 타입(Branded Types)을 적용**할 수 있으며, 외부 데이터가 유입될 때 Zod와 같은 런타임 검증 라이브러리를 함께 사용하면 더욱 안전하고 견고한 API를 구축할 수 있습니다 [13, 14].
-
-*   **퍼사드(Facade) 패턴 기반의 인터페이스 설계**
-    API나 외부 연동 SDK를 제공할 때 가장 중요한 것은 **내부의 복잡한 로직을 감추고 사용자의 의도(Intent)에 초점을 맞춘 고수준(High-level) 인터페이스를 제공**하는 퍼사드(Facade) 패턴을 적용하는 것입니다 [15, 16]. 다만, 모든 상황을 고수준 API로만 덮기보다는 세밀한 제어를 원하는 사용자를 위한 저수준(Low-level) API를 탈출구(Escape Hatch)로 함께 공존시키는 것이 훌륭한 인터페이스 설계의 핵심입니다 [16-18].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[Parse, don't validate]], [[Discriminated Unions]], [[Branded Types]], [[Facade Pattern]]
-- **Projects/Contexts:** [[Toss Front SDK]], [[Zod Validation]]
-- **Contradictions/Notes:** API의 에러 처리에 관하여, 모든 에러를 글로벌 예외 처리기(Global Exception Handler)로 넘기고 컨트롤러 로직을 짧게 가져가는 것이 더 깔끔하다는 전통적인 객체 지향 및 웹 프레임워크의 관점과, 예측 가능한 에러는 예외(Exception)가 아닌 명시적인 유니온 타입이나 Result 객체로 반환해야 제어 흐름이 투명해진다는 함수형 타입 시스템 관점이 서로 팽팽하게 대립하기도 합니다 [8, 19-21].
-
----
-*Last updated: 2026-04-18*
-- Raw Source: [[00_Raw/2026-04-20/TypeScript API Development.md]]
----
diff --git a/Programming & Language/TypeScript Advanced Type System.md b/Programming & Language/TypeScript Advanced Type System.md
deleted file mode 100644
index 614e9409..00000000
--- a/Programming & Language/TypeScript Advanced Type System.md	
+++ /dev/null
@@ -1,35 +0,0 @@
----
-id: P-REINFORCE-AUTO-A211EA
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - TypeScript Advanced Type System"
----
-
-# [[TypeScript Advanced Type System]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> TypeScript의 고급 타입 시스템은 구조적 타이핑(Structural Typing)을 기반으로 하면서도, 개발자가 코드의 예측 가능성과 안정성을 극대화할 수 있도록 돕는 강력한 도구 모음입니다 [1-3]. 이 시스템은 집합론에 기반하여 타입을 값들의 집합으로 다루며, 컴파일 시점에 런타임 에러를 방지합니다 [3-5]. 식별 가능한 유니온, 브랜디드 타입, `readonly` 수식어, 그리고 `satisfies` 연산자 등의 고급 기능을 통해 복잡한 비즈니스 로직을 안전하게 모델링할 수 있습니다 [6-10].
-
-## 📖 구조화된 지식 (Synthesized Content)
-- **집합론 기반의 타입 체계 (Set Theory Basis):** TypeScript의 타입은 가능한 값들의 집합으로 취급됩니다 [3-5]. 유니온(`|`)과 인터섹션(`&`)은 각각 집합의 합집합과 교집합을 의미하며, `extends` 키워드는 한 타입이 다른 타입의 부분집합(subset)임을 나타냅니다 [5, 11-14]. `never`는 어떠한 값도 가질 수 없는 공집합을 뜻하고, `unknown`은 모든 JavaScript 값을 포함하는 전체 집합(Universe)을 의미합니다 [5, 14, 15].
-- **구조적 타이핑과 과잉 속성 체크 (Structural Typing & EPC):** 객체의 형태가 일치하면 호환성을 인정하는 '덕 타이핑(Duck Typing)' 방식을 사용합니다 [1-3]. 단, 객체 리터럴이 변수에 직접 할당되거나 함수의 인수로 전달될 때는 '과잉 속성 체크(Excess Property Checking)'가 발동하여 선언되지 않은 잉여 속성의 유입을 엄격하게 차단합니다 [3, 16-20].
-- **식별 가능한 유니온과 완전성 검사 (Discriminated Unions & Exhaustiveness):** 객체가 가질 수 있는 여러 형태를 공통된 리터럴 속성(태그)을 기준으로 안전하게 좁혀내는(Narrowing) 패턴입니다 [6, 21-23]. `switch` 문과 공집합인 `never` 타입을 함께 활용하면, 유니온에 새로운 타입이 추가될 때 컴파일러가 누락된 처리 로직을 잡아내는 완전성 검사(Exhaustiveness Checking)가 가능해져 런타임 에러를 원천 차단합니다 [11, 23-26].
-- **브랜디드/오패크 타입 (Branded/Opaque Types):** 구조적으로 동일한 원시 타입(예: `UserId`용 문자열과 `OrderId`용 문자열)을 구별하기 위해, 런타임에는 존재하지 않는 가상의 속성(예: `__brand`)이나 고유 심볼(unique symbol)을 교집합으로 묶어 명목적 타이핑(Nominal Typing)을 흉내 냅니다 [7, 27-31]. 이를 통해 의미론적으로 다른 데이터가 무분별하게 섞이는 것을 컴파일 수준에서 방지합니다 [7, 31].
-- **불변성 확립 (`readonly`):** 객체 속성이나 배열을 수정 불가능하게 만듭니다 [8, 32-34]. 런타임 오버헤드가 있는 `Object.freeze()`나 변수 재할당만 막는 `const`와 달리, 컴파일 타임에 철저한 제어를 수행합니다 [34-37]. 매핑된 타입과 조건부 타입을 결합하면 중첩 객체까지 보호하는 `DeepReadonly` 구현이 가능합니다 [10, 38, 39].
-- **`satisfies` 연산자:** 타입 단언(`as`)의 불안정성을 극복하기 위한 연산자입니다. 객체가 특정 타입의 요구사항을 충족하는지 검사하면서도, 타입을 넓히지(Widening) 않고 구체적인 리터럴 타입 형태를 그대로 유지하도록 돕습니다 [9, 40-43].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[Structural Typing]], [[Discriminated Unions]], [[Branded Types]], [[Readonly Modifier]], [[Satisfies Operator]]
-- **Projects/Contexts:** [[Large-scale Application Architecture]], [[Domain-Driven Design (DDD)]]
-- **Contradictions/Notes:** 인터페이스(Interface)와 타입 별칭(Type Alias)의 사용 기준에 대해 개발자 간 선호도 차이가 있습니다. 일부는 일관성을 위해 Type만을 선호하기도 하지만 [44], TypeScript 공식 성능 가이드와 주요 문헌에서는 타입 관계 캐싱 및 선언 병합(Declaration Merging)의 장점 때문에 객체 구조를 확장할 때는 인터페이스(`extends`)를 우선적으로 사용할 것을 권장합니다 [45-49]. 또한, 복잡한 타입 분기 처리를 돕는 외부 라이브러리(ts-pattern 등)의 도입을 두고 단순한 제어문(`if`, `switch`) 대비 성능 오버헤드와 가독성 측면에서 의견 대립이 존재합니다 [50-52].
-
----
-*Last updated: 2026-04-18*
-- Raw Source: [[00_Raw/2026-04-20/TypeScript Advanced Type System.md]]
----
diff --git a/Programming & Language/TypeScript Utility Types (Record Readonly).md b/Programming & Language/TypeScript Utility Types (Record Readonly).md
deleted file mode 100644
index cad24eaa..00000000
--- a/Programming & Language/TypeScript Utility Types (Record Readonly).md	
+++ /dev/null
@@ -1,40 +0,0 @@
----
-id: P-REINFORCE-AUTO-523973
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - TypeScript Utility Types (Record Readonly)"
----
-
-# [[TypeScript Utility Types (Record Readonly)]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> TypeScript의 유틸리티 타입인 `Readonly`와 `Record`는 타입 안전성을 높이고 데이터 구조를 효과적으로 모델링하는 데 사용됩니다. `Readonly<T>`는 주어진 객체 타입의 모든 속성을 읽기 전용으로 변환하여 컴파일 타임에 의도치 않은 상태 변경(돌연변이)을 방지합니다 [1, 2]. `Record<K, V>`는 키와 값의 타입을 지정하여 객체(사전) 구조를 안전하게 정의하는 데 쓰이며, 이 둘을 결합하면 불변의 키-값 맵을 구축할 수 있습니다 [3, 4].
-
-## 📖 구조화된 지식 (Synthesized Content)
-- **`Readonly<T>` 유틸리티 타입**
-  - **기능 및 목적:** `Readonly<T>`는 기존 타입 `T`를 변환하여 모든 속성을 초기화 이후 재할당할 수 없는 읽기 전용으로 만듭니다 [2, 5]. 이는 런타임 성능 오버헤드 없이 오직 컴파일 타임에 불변성을 강제하여 코드의 예측 가능성을 높이고 우발적인 변이로 인한 버그를 차단합니다 [1, 6].
-  - **얕은 불변성(Shallow Immutability)의 한계:** TypeScript의 내장 `Readonly<T>`는 최상위 수준의 속성에만 적용됩니다 [7, 8]. 중첩된 객체나 배열은 여전히 수정이 가능하므로, 데이터의 완전한 불변성이 필요한 경우 개발자가 직접 재귀적으로 동작하는 `DeepReadonly` 유틸리티 타입을 정의하여 사용해야 합니다 [7, 8].
-  - **구조적 우회(Aliasing) 취약점:** TypeScript의 구조적 타이핑 특성으로 인해 `readonly` 속성이 부여된 배열이나 객체를 가변 매개변수를 요구하는 함수에 넘길 때, 타입 호환이 성립되어 컴파일 에러 없이 전달될 수 있습니다 [9]. 이 경우 함수 내부에서 해당 객체의 값을 은연중에 수정할 위험이 있습니다 [9, 10].
-
-- **`Record<K, V>` 유틸리티 타입**
-  - `Record<K, V>`는 키 타입 `K`와 값 타입 `V`를 가진 객체 구조를 간단히 모방(analogue)하여 정의할 수 있게 해줍니다 [4, 11]. 
-  - 특정 속성 목록이나 임의의 제네릭 객체를 다룰 때 활용도가 높으며, 예를 들어 `Record<string, unknown>`의 형태로 범용적인 객체를 모델링할 때 빈번하게 사용됩니다 [12].
-
-- **`Readonly`와 `Record`의 시너지**
-  - 두 유틸리티 타입을 결합(`Readonly<Record<K, V>>`)하면 속성이 절대 변하지 않는 불변의 키-값 맵(Immutable key-value map)을 구성할 수 있습니다 [3]. 이는 애플리케이션 전반에서 변하지 않아야 하는 정적인 사전(Static dictionaries)을 선언할 때 권장되는 패턴입니다 [3].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[DeepReadonly]], [[TypeScript Structural Typing]], [[Utility Types]]
-- **Projects/Contexts:** `Readonly`는 앱의 설정(Configuration) 객체를 고정하거나 [13, 14], 상태 관리(Reducer) 시 불변성을 강제하고 [14], API로부터 받아온 응답 데이터가 로직 내에서 우발적으로 변조되는 것을 막는 컨텍스트에 널리 활용됩니다 [14].
-- **Contradictions/Notes:** TypeScript의 `Readonly`는 런타임에 데이터를 얕게 동결시키는 자바스크립트의 `Object.freeze()`나 변수 자체의 재할당을 막는 `const`와 구별됩니다. `Readonly`는 런타임 비용이 전혀 없으며 컴파일 타임에만 엄격하게 속성 재할당을 검사합니다 [1, 15, 16].
-
----
-*Last updated: 2026-04-18*
-- Raw Source: [[00_Raw/2026-04-20/TypeScript Utility Types (Record, Readonly).md]]
----
diff --git a/Programming & Language/TypeScript 타입 시스템 (TypeScript Type System).md b/Programming & Language/TypeScript 타입 시스템 (TypeScript Type System).md
deleted file mode 100644
index f2812567..00000000
--- a/Programming & Language/TypeScript 타입 시스템 (TypeScript Type System).md	
+++ /dev/null
@@ -1,34 +0,0 @@
----
-id: P-REINFORCE-AUTO-5C8A49
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - TypeScript 타입 시스템 (TypeScript Type System)"
----
-
-# [[TypeScript 타입 시스템 (TypeScript Type System)]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> TypeScript의 타입 시스템은 구조적 타이핑(Structural Typing)을 기반으로 하여, 객체의 실제 형태가 일치하면 호환성을 인정하는 유연성을 제공한다[1, 2]. 동시에 과잉 속성 체크(Excess Property Checking)나 `satisfies` 연산자와 같은 방어 기제를 통해 런타임 에러와 의도치 않은 데이터 유입을 컴파일 시점에 차단한다[3-6]. 이는 집합론(Set Theory)적 관점에서 타입을 정의하고 평가하며, 궁극적으로 복잡한 비즈니스 로직을 보호하고 견고한 인터페이스 설계를 가능하게 하는 아키텍처적 도구로 기능한다[2, 7-9].
-
-## 📖 구조화된 지식 (Synthesized Content)
-- **구조적 타이핑과 집합론 (Structural Typing & Set Theory):** TypeScript는 객체의 속성과 메서드 형태가 같으면 동일한 타입으로 간주하는 "덕 타이핑(Duck Typing)" 방식의 구조적 타이핑을 채택한다[1, 2, 5]. 이 타입 시스템은 집합론으로 해석될 수 있으며, `never`는 공집합, `unknown`은 전체 집합을 의미하고, `A extends B`는 $A \subseteq B$ (부분집합)의 관계로 동작한다[5, 7, 8].
-- **타입 간의 호환성과 수비 전략:** 유연한 구조적 타이핑으로 인한 의도치 않은 데이터 유입을 막기 위해, TypeScript는 객체 리터럴 할당 시 정의되지 않은 속성을 차단하는 과잉 속성 체크(Excess Property Checking)를 수행한다[3, 5]. 간접 할당 시 EPC가 우회되는 한계를 극복하기 위해 도입된 `satisfies` 연산자는 대상의 요구사항 충족 여부를 검사하면서도 구체적인 리터럴 타입을 유지하도록 보장한다[4, 6, 10]. 또한, 구조가 같더라도 의미가 다른 데이터(예: 이메일과 일반 문자열)를 구별하기 위해 브랜디드 타입(Branded Types) 혹은 Opaque Types를 사용하여 컴파일 시점에 고유한 표식(`__brand` 등)을 부여하는 명목적 타이핑을 구현할 수 있다[10-13].
-- **상태 보호와 불변성 (Immutability):** `readonly` 수식어를 통해 객체와 배열의 수정을 컴파일 수준에서 금지함으로써 데이터의 무결성을 보장한다[14-16]. 기본적인 `readonly`는 얕은(shallow) 수준의 보호만 제공하므로, 중첩된 객체를 완벽히 보호하기 위해서는 재귀적 불변성을 보장하는 `DeepReadonly` 유틸리티 타입을 활용하여 데이터를 동결할 수 있다[16-18].
-- **식별 가능한 유니온과 완전성 검사 (Discriminated Unions & Exhaustiveness Checking):** 여러 상태를 가질 수 있는 합집합 타입을 다룰 때, 공통된 리터럴 속성을 태그(Discriminant)로 사용하여 타입을 안전하게 좁혀나간다(Narrowing)[19-21]. 이에 더해 `never` 타입을 활용한 완전성 검사(Exhaustiveness Checking) 기법을 도입하면, 유니온에 새로운 분기나 상태가 추가되었을 때 처리되지 않은 로직을 컴파일 에러로 포착하여 빈틈없는 방어가 가능하다[21-23].
-- **인터페이스 설계와 타입 별칭 (Interface vs Type Alias):** TypeScript 컴파일러는 인터페이스(`interface`) 처리 시 이름을 기준으로 관계를 캐싱하기 때문에 도메인 모델이나 객체 계약 정의에 성능상 유리하며 선언 병합(Declaration Merging) 확장을 지원한다[24-27]. 반면 교집합이나 합집합 등 더 엄격하고 복잡한 조합을 제어할 필요가 있는 곳에는 타입 별칭(`type`)을 사용하는 전략적 이원화가 권장된다[26-29].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[구조적 타이핑 (Structural Typing)]], [[식별 가능한 유니온 (Discriminated Unions)]], [[브랜디드 타입 (Branded Types)]], [[과잉 속성 체크 (Excess Property Checking)]], [[satisfies 연산자]], [[불변성 (Immutability)]]
-- **Projects/Contexts:** [[대규모 애플리케이션 개발]], [[SOLID 원칙 기반 인터페이스 설계]], [[Toss Front SDK 설계]]
-- **Contradictions/Notes:** 인터페이스(`interface`)와 타입 별칭(`type`)의 선택과 관련하여, 선언 병합으로 인한 예기치 않은 구조 오버라이딩을 피하기 위해 오직 `type`만을 엄격하게 사용하는 팀 문화가 존재하는 반면[30, 31], 컴파일러 캐싱 최적화 관점에서는 객체 상속 시 `interface`를 우선할 것을 강력히 권고하는 이견이 존재한다[25, 26, 28]. 또한 `ts-pattern` 라이브러리는 철저한 타입 추론과 가독성을 주지만 네이티브 `if/switch` 구문에 비해 성능이 현저히 떨어지므로(초당 연산 횟수 기준 99% 저하 등), 간단한 분기문에 남용할 경우 불필요한 런타임 오버헤드를 유발할 수 있다는 비판적 견해가 있다[32-34].
-
----
-*Last updated: 2026-04-18*
-- Raw Source: [[00_Raw/2026-04-20/TypeScript 타입 시스템 (TypeScript Type System).md]]
----
diff --git a/Programming & Language/TypeScript 타입 시스템 (인터페이스 설계).md b/Programming & Language/TypeScript 타입 시스템 (인터페이스 설계).md
deleted file mode 100644
index 453a19b5..00000000
--- a/Programming & Language/TypeScript 타입 시스템 (인터페이스 설계).md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-411D87
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - TypeScript 타입 시스템 (인터페이스 설계)"
----
-
-# [[TypeScript 타입 시스템 (인터페이스 설계)]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/TypeScript 타입 시스템 (인터페이스 설계).md]]
----
diff --git a/Programming & Language/TypeScript 타입 시스템 및 인터페이스 설계.md b/Programming & Language/TypeScript 타입 시스템 및 인터페이스 설계.md
deleted file mode 100644
index bef3bfaa..00000000
--- a/Programming & Language/TypeScript 타입 시스템 및 인터페이스 설계.md	
+++ /dev/null
@@ -1,43 +0,0 @@
----
-id: P-REINFORCE-AUTO-9DE40A
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - TypeScript 타입 시스템 및 인터페이스 설계"
----
-
-# [[TypeScript 타입 시스템 및 인터페이스 설계]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> TypeScript의 타입 시스템은 객체의 실제 형태와 구조를 기준으로 호환성을 판단하는 구조적 타이핑(Structural Typing)을 근간으로 합니다 [1, 2]. 개발자는 시스템 설계 시 인터페이스와 타입 별칭을 전략적으로 선택하여 타입의 확장성과 컴파일러 성능을 최적화할 수 있습니다 [3-5]. 또한, 식별 가능한 유니온, 브랜디드 타입(Branded Types), `readonly` 및 `satisfies` 연산자 등의 고급 기능을 적극적으로 활용하여 런타임 에러를 방지하고 견고한 소프트웨어 아키텍처를 구축할 수 있습니다 [6-10].
-
-## 📖 구조화된 지식 (Synthesized Content)
-* **구조적 타이핑과 집합론적 접근**
-  TypeScript는 Java나 C#과 같은 명목적 타이핑(Nominal Typing)이 아닌, 객체의 구조가 일치하면 동일한 타입으로 간주하는 덕 타이핑(Duck Typing)을 채택하고 있습니다 [1, 11]. 집합론적 관점에서 타입은 '가능한 값들의 집합'으로 정의되며, `never`는 공집합, `unknown`은 모든 JS 값을 포함하는 전체집합으로 이해할 수 있습니다 [12-14]. 이러한 특성을 통해 상속이나 명시적 선언 없이도 타입 간의 호환성이 유연하게 결정됩니다 [2, 15].
-
-* **인터페이스(Interface)와 타입(Type) 설계 전략**
-  인터페이스는 확장성과 성능 면에서 유리합니다. TypeScript 컴파일러는 인터페이스를 처리할 때 이름을 기준으로 캐싱하므로, 교집합(`&`)을 활용한 타입 별칭보다 `interface extends`를 사용하는 것이 대규모 프로젝트에서 성능 최적화에 도움이 됩니다 [5, 16-18]. 그러나 교집합, 유니온, 매핑된 타입 등 복잡한 타입 구성이 필요할 때는 타입 별칭을 활용해야 하며, 외부 확장 포인트를 제한하기 위해 의도적으로 인터페이스 대신 타입을 사용하는 경우도 존재합니다 [19, 20].
-
-* **과잉 속성 체크(EPC)와 `satisfies` 연산자**
-  객체 리터럴이 타입이 지정된 변수에 직접 할당될 때, TypeScript는 초과 속성이 들어오는 것을 방어하기 위해 과잉 속성 체크를 실행합니다 [2, 21-24]. 하지만 간접 할당 과정에서는 이 수비 기제가 작동하지 않을 수 있는데, 이를 극복하기 위해 `satisfies` 연산자를 활용할 수 있습니다 [10, 21, 25]. `satisfies`는 객체가 특정 타입의 형태를 충족하는지 검사하면서도 구체적인 리터럴 타입의 정보를 잃지 않게 하여 타입 안전성을 보장합니다 [10, 26-28].
-
-* **식별 가능한 유니온(Discriminated Unions)과 완전성 검사**
-  복잡한 비즈니스 상태를 설계할 때는 식별 가능한 유니온이 핵심적인 역할을 합니다. 공통된 리터럴 속성(예: `kind`, `type`)을 태그로 사용하여 합집합 내의 타입을 좁혀(Narrowing) 안전하게 다룰 수 있습니다 [6, 29-31]. 특히 `never` 타입을 활용한 완전성 검사(Exhaustiveness Checking)를 구현하면, 처리되지 않은 누락된 상태가 있을 경우 컴파일 에러를 발생시켜 빈틈없는 수비 체계를 갖출 수 있습니다 [31, 32].
-
-* **불변성과 브랜디드 타입(Branded Types)을 통한 데이터 오염 방지**
-  `readonly` 수식어는 객체나 배열이 런타임 성능 저하 없이 컴파일 시점에 불변성을 유지하도록 보장하여 의도치 않은 상태 변경을 차단합니다 [8, 33-35]. 또한, 구조적 타이핑의 한계인 "기본 타입에의 집착(Primitive Obsession)"을 해결하기 위해 고유한 표식(`__brand`)을 부여하는 브랜디드 타입 기법을 적용할 수 있습니다 [7, 9, 36, 37]. 이는 ID와 일반 문자열이 혼용되는 것을 컴파일러 수준에서 강력히 차단합니다 [9, 37, 38].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[구조적 타이핑 (Structural Typing)]], [[식별 가능한 유니온 (Discriminated Unions)]], [[Branded Types]], [[satisfies 연산자]]
-- **Projects/Contexts:** [[도메인 기반 설계 (DDD)]], [[SOLID 원칙 및 인터페이스 분리 원칙 (ISP)]]
-- **Contradictions/Notes:** TypeScript 공식 문서와 성능 가이드는 컴파일 최적화를 위해 상속 시 `interface extends`를 권장합니다[16-18]. 하지만 일부 개발 팀들은 인터페이스 선언 병합(Declaration Merging)으로 인한 예기치 않은 부작용을 원천 차단하기 위해 모든 객체 정의에 대해 `Type` 별칭(alias)만 사용하도록 규칙을 강제하기도 합니다[19, 39, 40].
-
----
-*Last updated: 2026-04-18*
-- Raw Source: [[00_Raw/2026-04-20/TypeScript 타입 시스템 및 인터페이스 설계.md]]
----
diff --git a/Programming & Language/TypeScript 타입 시스템 아키텍처 및 도메인 기반 설계(DDD).md b/Programming & Language/TypeScript 타입 시스템 아키텍처 및 도메인 기반 설계(DDD).md
deleted file mode 100644
index 3a9a649d..00000000
--- a/Programming & Language/TypeScript 타입 시스템 아키텍처 및 도메인 기반 설계(DDD).md	
+++ /dev/null
@@ -1,46 +0,0 @@
----
-id: P-REINFORCE-AUTO-176A7F
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - TypeScript 타입 시스템 아키텍처 및 도메인 기반 설계(DDD)"
----
-
-# [[TypeScript 타입 시스템 아키텍처 및 도메인 기반 설계(DDD)]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-- **구조적 타이핑의 한계와 명목적 타이핑의 수복**
-  TypeScript는 객체의 구조(형태)가 같으면 동일한 타입으로 취급하는 구조적 타이핑을 사용합니다 [1, 2, 8]. 하지만 도메인 모델링에서는 이메일 주소와 사용자의 이름이 모두 문자열(`string`)이라고 해서 섞여 쓰이면 안 되는 '기본 타입에의 집착(Primitive Obsession)' 문제가 발생합니다 [3, 9]. 
-
-- **브랜디드 타입(Branded Types)을 통한 데이터 격리**
-  위 문제를 해결하기 위해 도메인 기반 설계에서는 브랜디드 타입(또는 Opaque Types)을 적극 활용합니다 [10, 11]. 런타임에는 존재하지 않지만 컴파일 시점에만 존재하는 고유한 속성(예: `unique symbol`)을 타입에 부여하여 `UserId`와 `OrderId`를 엄격히 분리합니다 [3, 9, 12]. 이를 통해 오직 검증된 데이터만이 시스템의 내부 로직으로 진입하도록 강제할 수 있습니다 [11, 12].
-
-- **"검증하지 말고 파싱하라 (Parse, Don't Validate)"**
-  외부에서 유입되는 언타입드(untyped) 데이터를 단순히 유효성 검사하는 것에 그치지 않고, 시스템 경계(Boundary)에서 한 번에 완벽히 타이핑된 구조로 변환(파싱)해야 한다는 설계 철학입니다 [4, 6, 13]. Zod와 같은 런타임 검증 라이브러리와 브랜디드 타입을 결합하면, 파싱을 통과한 데이터가 도메인 객체로서 안전하다는 것을 타입 시스템 레벨에서 영구적으로 보장할 수 있습니다 [6, 12, 14].
-
-- **식별 가능한 유니온(Discriminated Unions)과 완전성 검사(Exhaustiveness Checking)**
-  공통된 리터럴 속성(태그)을 사용하여 도메인의 복잡한 상태 머신을 모델링하는 기법으로, "불가능한 상태를 표현 불가능하게 만드는" 핵심 수비 기술입니다 [5, 15-18]. `switch`문과 `never` 타입을 결합한 완전성 검사(Exhaustiveness Checking) 기법을 사용하면, 도메인에 새로운 상태가 추가되었을 때 이를 처리하지 않은 모든 코드를 컴파일 에러로 즉각 찾아낼 수 있습니다 [18-22].
-
-- **불변성(Immutability) 확립**
-  상태의 무분별한 변경을 막기 위해 `readonly` 수식어를 적극적으로 사용하여 객체와 배열의 수정을 컴파일 수준에서 금지합니다 [23-25]. 단순한 얕은 보호를 넘어 매핑 타입과 조건부 타입을 결합한 재귀적 불변성(`DeepReadonly`)을 구축하면, 복잡한 도메인 엔티티의 무결성을 완벽하게 방어할 수 있습니다 [5, 25, 26].
-
-- **경계면의 방어: EPC와 `satisfies` 연산자**
-  객체 리터럴이 직접 할당될 때 작동하는 과잉 속성 체크(Excess Property Checking, EPC)를 통해 정의되지 않은 도메인 속성이 포함되는 것을 차단합니다 [8, 27, 28]. 간접 할당으로 인해 EPC가 우회되는 것을 막기 위해 `satisfies` 연산자를 활용하면, 객체의 구체적인 리터럴 타입 정보를 유지하면서도 안전하게 도메인 인터페이스 규격을 충족하는지 검증할 수 있습니다 [11, 29, 30].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[브랜디드 타입(Branded Types)]], [[식별 가능한 유니온(Discriminated Unions)]], [[구조적 타이핑(Structural Typing)]], [[Parse, Don't Validate]], [[완전성 검사(Exhaustiveness Checking)]]
-- **Projects/Contexts:** [[Zod 유효성 검사 라이브러리 연동]], [[프론트엔드 상태 머신(State Machine) 구현]]
-- **Contradictions/Notes:** TypeScript는 본래 Java나 C#과 달리 명목적 타이핑(Nominal Typing)을 네이티브로 지원하지 않고 구조적 타이핑으로 동작합니다. 따라서 엄격한 도메인 설계를 구축하려면, 컴파일러를 속이는 방식(가짜 속성 추가 등)인 브랜디드 타입과 같은 우회 전략을 인위적으로 도입해야만 명목적 타이핑의 효과를 얻을 수 있습니다.
-
----
-*Last updated: 2026-04-18*
-- Raw Source: [[00_Raw/2026-04-20/TypeScript 타입 시스템 아키텍처 및 도메인 기반 설계(DDD).md]]
----
diff --git a/Programming & Language/TypeScript 타입 시스템을 활용한 내부 로직 보호 및 데이터 검증.md b/Programming & Language/TypeScript 타입 시스템을 활용한 내부 로직 보호 및 데이터 검증.md
deleted file mode 100644
index 3366943d..00000000
--- a/Programming & Language/TypeScript 타입 시스템을 활용한 내부 로직 보호 및 데이터 검증.md	
+++ /dev/null
@@ -1,43 +0,0 @@
----
-id: P-REINFORCE-AUTO-2609F8
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - TypeScript 타입 시스템을 활용한 내부 로직 보호 및 데이터 검증"
----
-
-# [[TypeScript 타입 시스템을 활용한 내부 로직 보호 및 데이터 검증]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> TypeScript의 타입 시스템은 컴파일 시점에 내부 로직을 보호하고 데이터 무결성을 검증하는 강력한 수비 기제를 제공합니다. 구조적 타이핑의 유연성에서 오는 한계점을 과잉 속성 체크(Excess Property Checking)와 `satisfies` 연산자로 보완하며, 브랜디드 타입(Branded Types)과 식별 가능한 유니온(Discriminated Unions)을 활용하여 잘못된 상태와 데이터 오염을 원천 차단합니다. 또한, 시스템 경계에서 "검증하지 말고 파싱하라(Parse, don't validate)" 원칙을 적용함으로써 런타임 환경에서도 예측 가능하고 견고한 애플리케이션 구조를 확립할 수 있습니다.
-
-## 📖 구조화된 지식 (Synthesized Content)
-*   **구조적 타이핑과 `satisfies` 연산자를 활용한 경계 방어**
-    TypeScript는 객체의 구조가 일치하면 동일한 타입으로 취급하는 구조적 타이핑(Structural Typing)을 사용합니다 [1, 2]. 이 특성은 유연하지만 의도치 않은 잉여 속성이 포함될 수 있는 약점이 있습니다 [3-5]. 객체 리터럴 직접 할당 시에는 과잉 속성 체크(EPC)가 작동하지만 변수를 거칠 경우 이를 우회할 수 있습니다 [5-7]. 이를 막기 위해 `satisfies` 연산자를 사용하면, 객체의 리터럴 형태나 추가적인 메타데이터 구조를 잃지 않으면서도 타입 요구사항을 엄격히 검증하여 안전성을 보장합니다 [5, 8-10].
-
-*   **식별 가능한 유니온(Discriminated Unions)과 불가능한 상태의 차단**
-    식별 가능한 유니온은 공통된 리터럴 속성(예: `kind`, `type`)을 태그로 사용하여 여러 객체 타입을 구별하는 패턴입니다 [11-13]. 이 기법은 TypeScript가 타입을 안전하게 좁히도록(Narrowing) 유도하여 유효하지 않은 상태의 표현을 코드로 불가능하게 만듭니다 [13-15]. 또한, `never` 타입을 반환하는 완전성 검사(Exhaustiveness Checking) 함수를 스위치(switch) 문 등에 결합하면, 추후 새로운 상태가 추가되었을 때 누락된 분기 처리를 컴파일 에러로 포착해 로직의 빈틈을 막아줍니다 [13, 15-17].
-
-*   **브랜디드 타입(Branded Types)을 통한 명목적 타이핑 구현 및 데이터 오염 방지**
-    사용자의 식별자(ID)와 일반 문자열은 모두 `string` 타입이지만 도메인 의미는 다릅니다. 이들을 혼용하는 실수(원시 타입 집착)를 막기 위해, 컴파일 타임에만 존재하는 고유한 가상의 속성(브랜드)을 교집합(`&`)으로 결합하는 브랜디드 타입이 사용됩니다 [18-21]. 이는 고유한 신분증을 부여하는 것과 같아서, `UserId`가 필요한 곳에 `OrderId`나 일반 문자열이 유입되는 것을 컴파일러 수준에서 철저히 차단합니다 [5, 22, 23].
-
-*   **"검증하지 말고 파싱하라 (Parse, Don't Validate)" 전략**
-    비즈니스 로직 전반에 흩어진 데이터 유효성 검사 코드는 관리를 어렵게 만듭니다. 대신 시스템의 경계(API 통신 등)에서 알 수 없는(`unknown`) 데이터를 안전한 타입의 구조로 한 번에 "파싱"해야 합니다 [24-26]. Zod와 같은 검증 라이브러리와 브랜디드 타입을 함께 결합하면, 경계를 통과한 데이터는 시스템 내부에서 항상 유효하고 안전한 데이터(`SanitizedString` 등)로 취급받을 수 있습니다 [26-28].
-
-*   **`readonly`를 통한 불변성(Immutability) 확립**
-    데이터 무결성을 보호하기 위해 `readonly` 수식어를 사용하여 컴파일 타임에 속성값의 변경을 원천적으로 막을 수 있습니다 [29-31]. 얕은 수준(Shallow)의 보호를 넘어서기 위해 재귀적 유틸리티 타입인 `DeepReadonly`를 적용하면, 복잡하게 중첩된 객체 트리 구조 내부의 모든 상태가 예기치 않게 오염되는 것을 완벽히 차단할 수 있습니다 [31-33].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[구조적 타이핑 (Structural Typing)]], [[식별 가능한 유니온 (Discriminated Unions)]], [[브랜디드 타입 (Branded Types)]], [[satisfies 연산자]], [[Parse, Don't Validate]]
-- **Projects/Contexts:** [[Zod를 활용한 런타임 데이터 파싱 및 검증]], [[Toss Front SDK의 Facade 패턴 설계 및 안전성 확보]]
-- **Contradictions/Notes:** TypeScript의 구조적 타이핑은 매우 유연하여 덕 타이핑의 이점을 제공하지만, "의도하지 않은 초과 데이터의 유입"이라는 치명적인 보안적 허점을 만듭니다 [4, 21]. 이를 방어하기 위해 개발자들은 오히려 구조적 타이핑의 반대 개념인 명목적 타이핑(Nominal Typing) 특성을 강제로 모방한 브랜디드 타입을 사용하여 데이터를 격리해야 하는 역설적이지만 필수적인 설계 패턴을 따르게 됩니다 [21, 34, 35]. 또한, `any` 타입의 사용은 이러한 모든 타입 시스템의 보호막을 무력화시키므로 지양해야 하며, 출처를 알 수 없는 외부 데이터는 반드시 `unknown` 타입으로 선언 후 타입 가드를 거치도록 강제해야 합니다 [36-38].
-
----
-*Last updated: 2026-04-18*
-- Raw Source: [[00_Raw/2026-04-20/TypeScript 타입 시스템을 활용한 내부 로직 보호 및 데이터 검증.md]]
----
diff --git a/Programming & Language/TypeScript-Language-Service.md b/Programming & Language/TypeScript-Language-Service.md
deleted file mode 100644
index e2a9398c..00000000
--- a/Programming & Language/TypeScript-Language-Service.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-90F4A8
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - TypeScript-Language-Service"
----
-
-# [[TypeScript-Language-Service]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/TypeScript-Language-Service.md]]
----
diff --git a/Programming & Language/TypeScript의 제어 흐름 분석 및 상태 관리 패턴.md b/Programming & Language/TypeScript의 제어 흐름 분석 및 상태 관리 패턴.md
deleted file mode 100644
index cadb5fa7..00000000
--- a/Programming & Language/TypeScript의 제어 흐름 분석 및 상태 관리 패턴.md	
+++ /dev/null
@@ -1,43 +0,0 @@
----
-id: P-REINFORCE-AUTO-348B57
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - TypeScript의 제어 흐름 분석 및 상태 관리 패턴"
----
-
-# [[TypeScript의 제어 흐름 분석 및 상태 관리 패턴]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> TypeScript의 제어 흐름 분석과 상태 관리 패턴은 컴파일러가 런타임의 코드 흐름을 추론하여 타입을 안전하고 구체적으로 좁혀나가는(Narrowing) 메커니즘을 핵심으로 합니다 [1, 2]. 특히 '식별 가능한 유니온(Discriminated Unions)' 패턴을 활용하면 복잡한 조건부 분기를 간결하게 처리하고, 유효하지 않은 상태(Invalid state)가 발생하는 것을 원천적으로 방지할 수 있습니다 [3-5]. 이 패턴은 완전성 검사(Exhaustiveness Checking)와 결합되어 복잡한 상태 머신 모델링이나 React 애플리케이션 등에서 시스템의 아키텍처적 안정성을 크게 높이는 데 기여합니다 [4, 6, 7].
-
-## 📖 구조화된 지식 (Synthesized Content)
-*   **제어 흐름 분석과 타입 좁히기 (Type Narrowing)**
-    TypeScript는 런타임의 코드 흐름과 조건문을 분석하여 변수의 타입을 보다 구체적으로 추론합니다 [8]. `typeof`, `instanceof`, `in` 연산자 및 커스텀 타입 가드(Type Predicates)와 같은 기법을 통해 유니온 타입의 값을 안전하게 특정 타입으로 좁힐 수 있습니다 [1, 9]. TypeScript의 제어 흐름 분석은 조건문 블록 내부에서 이렇게 좁혀진 타입을 자동으로 인식하여 타입 안전성을 보장합니다 [1, 2].
-
-*   **식별 가능한 유니온 (Discriminated Unions/Tagged Unions)**
-    상태 관리에서 가장 강력한 무기 중 하나로, 유니온 타입의 각 멤버에 공통된 리터럴 속성(예: `kind`, `type`, `status`)을 식별자(Discriminant)로 두어 타입을 구별하는 패턴입니다 [2, 10-12]. TypeScript는 `switch`나 `if` 제어문에서 이 식별자의 값을 확인하여, 개발자가 다루고 있는 현재 분기의 타입을 자동으로 좁혀줍니다 [2, 10].
-
-*   **유효하지 않은 상태 방지 및 상태 머신 모델링**
-    이 패턴의 가장 큰 장점은 개발자가 잘못된 조합의 상태를 표현하는 것을 타입 시스템 차원에서 불가능하게 만든다는 것입니다 [3-5]. 이는 명확한 상태 전이가 필요한 '상태 머신(State Machine)'을 모델링할 때 매우 효과적이며, 비동기 데이터 로딩(`FETCH_START`, `FETCH_SUCCESS`, `FETCH_FAILURE` 등)이나 여러 단계로 이루어진 폼(Wizard/Multi-Step Forms)의 상태 등을 관리할 때 필수적입니다 [4, 7, 13].
-
-*   **완전성 검사 (Exhaustiveness Checking)**
-    개발자가 유니온 타입의 모든 가능한 상태를 분기문에서 처리했는지 컴파일 타임에 검증하는 기법입니다 [2, 6, 14]. `switch` 문의 `default` 블록 등에서 `never` 타입을 활용하면, 추후 새로운 상태가 유니온에 추가되었을 때 이를 처리하는 로직이 누락되었다면 컴파일 에러를 발생시켜 런타임 버그를 미연에 차단합니다 [2, 15, 16]. 
-
-*   **ts-pattern과 분기 처리 최적화**
-    외부 라이브러리인 `ts-pattern`을 사용하면 패턴 매칭을 통해 복잡한 조건부 분기를 선언적으로 작성하고 `.exhaustive()` 메서드를 통해 처리되지 않은 케이스를 안전하게 감지할 수 있습니다 [17]. 하지만 `ts-pattern`은 내부적으로 복잡한 타입 추론과 객체 생성을 수반하므로 자바스크립트의 기본 제어 구조(`if/else`, `switch`)에 비해 연산 성능이 저하될 수 있으며, 지나치게 단순한 로직에 사용할 경우 오버엔지니어링이 될 수 있어 상황에 맞는 유연한 도입이 필요합니다 [17-19].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[Type Narrowing]], [[Discriminated Unions]], [[Exhaustiveness Checking]], [[State Machine Pattern]], [[ts-pattern]]
-- **Projects/Contexts:** [[React State Management]], [[API Response Handling]], [[Form Handling]]
-- **Contradictions/Notes:** 복잡한 조건부 분기를 처리할 때 `ts-pattern` 라이브러리는 훌륭한 타입 안전성과 완전성 검사를 제공하지만, 기존의 `if/else`나 `switch` 제어문에 비해 성능 오버헤드가 발생할 수 있으므로, 성능이 중요한 상황이거나 복잡도가 낮은 분기에서는 기본 제어 구조나 Early return을 활용하는 것이 더 효율적일 수 있습니다 [17-19].
-
----
-*Last updated: 2026-04-18*
-- Raw Source: [[00_Raw/2026-04-20/TypeScript의 제어 흐름 분석 및 상태 관리 패턴.md]]
----
diff --git a/Programming & Language/UNESCO-Memory-of-the-World.md b/Programming & Language/UNESCO-Memory-of-the-World.md
deleted file mode 100644
index c0129d5e..00000000
--- a/Programming & Language/UNESCO-Memory-of-the-World.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-8CC54C
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - UNESCO-Memory-of-the-World"
----
-
-# [[UNESCO-Memory-of-the-World]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/UNESCO-Memory-of-the-World.md]]
----
diff --git a/Programming & Language/Union Types.md b/Programming & Language/Union Types.md
deleted file mode 100644
index 1d6fae3f..00000000
--- a/Programming & Language/Union Types.md	
+++ /dev/null
@@ -1,34 +0,0 @@
----
-id: P-REINFORCE-AUTO-696914
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Union Types"
----
-
-# [[Union Types]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> Union Types는 TypeScript에서 하나의 값이 여러 타입 중 하나를 가질 수 있음을 나타내는 기능입니다 [1, 2]. 수직선(`|`) 기호를 사용하여 타입들을 연결하며(예: `string | number`), `any` 타입을 사용하는 것보다 타입 안전성을 유지하면서도 유연한 코드를 작성할 수 있게 해줍니다 [1-3]. 집합론적 관점에서는 두 개 이상의 타입 집합을 합친 합집합(Union)으로 기능합니다 [4, 5].
-
-## 📖 구조화된 지식 (Synthesized Content)
-- **기본 동작과 공통 필드 제약**: Union Types로 정의된 변수는 지정된 타입들(`A | B`) 중 하나의 값을 가질 수 있습니다 [6, 7]. 그러나 이 변수의 속성에 접근할 때, TypeScript는 타입 안전성을 위해 유니온에 속한 **모든 타입에 공통으로 존재하는 멤버에만 접근을 허용합니다** [2]. 예를 들어 `Bird | Fish` 타입의 변수라면, 런타임에 어떤 타입이 들어올지 확실하지 않으므로 두 인터페이스에 모두 정의된 메서드만 호출할 수 있습니다 [2].
-- **타입 좁히기 (Type Narrowing)**: 특정 타입에만 속한 속성을 읽거나 쓰려면 먼저 변수의 타입을 좁혀야 합니다 [8]. 이를 위해 `typeof`, `instanceof`, `in` 연산자를 사용하거나, 사용자 정의 타입 가드(Custom Type Guards)를 활용하여 코드가 실행되는 분기(흐름) 내에서 정확한 타입을 추론하도록 해야 합니다 [8-10].
-- **식별 가능한 유니온 (Discriminated Unions)**: Union Types를 더욱 강력하게 만드는 핵심 패턴입니다 [7, 11]. 유니온을 구성하는 각 객체 타입에 리터럴 타입의 공통 식별자 속성(예: `kind: 'circle' | 'rectangle'`)을 선언하여, 이 속성을 비교하는 것만으로 TypeScript가 올바른 타입으로 좁힐 수 있게 돕습니다 [12-14]. 이 패턴은 상태 머신을 모델링하거나 잘못된 상태의 조합을 원천적으로 막을 때 매우 효과적입니다 [15, 16].
-- **완전성 검사 (Exhaustiveness Checking)**: 식별 가능한 유니온을 `switch` 문으로 분기 처리할 때, `never` 타입을 활용해 모든 분기를 안전하게 처리했는지 컴파일러에게 검사받을 수 있습니다 [17-19]. 만약 유니온 타입에 새로운 변형(Variant)이 추가되었는데 `switch` 문에서 처리하지 않았다면, `never` 타입 검사에 걸려 컴파일 에러가 발생하므로 누락을 방지할 수 있습니다 [18-20].
-- **Type Brands의 대안**: 값의 종류가 미리 정해져 있는 상황이라면, 복잡한 Branded Types를 사용하는 것보다 알려진 값들을 Union Types로 구성하는 것이 값의 종류를 정확히 설명하는 데 유리할 수 있습니다 [21, 22].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[Intersection Types]], [[Discriminated Unions]], [[Type Narrowing]], [[Set Theory]]
-- **Projects/Contexts:** [[TypeScript Type System]], [[State Management]]
-- **Contradictions/Notes:** Union Types는 값의 유연성을 보장(`A` 혹은 `B` 중 하나 허용)하지만, 객체 속성에 접근할 때는 유니온의 모든 타입에 공통으로 존재하는 속성(교집합 형태)만 접근할 수 있는 엄격함이 있으므로 이를 다룰 때는 항상 타입 좁히기(Type Narrowing)가 선행되어야 합니다 [2, 8].
-
----
-*Last updated: 2026-04-18*
-- Raw Source: [[00_Raw/2026-04-20/Union Types.md]]
----
diff --git a/Programming & Language/Urban Planning Simulation.md b/Programming & Language/Urban Planning Simulation.md
deleted file mode 100644
index 3f9a678f..00000000
--- a/Programming & Language/Urban Planning Simulation.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-E9E18A
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Urban Planning Simulation"
----
-
-# [[Urban Planning Simulation]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Urban Planning Simulation.md]]
----
diff --git a/Programming & Language/V8 Engine Heap Management.md b/Programming & Language/V8 Engine Heap Management.md
deleted file mode 100644
index f5b905e8..00000000
--- a/Programming & Language/V8 Engine Heap Management.md	
+++ /dev/null
@@ -1,44 +0,0 @@
----
-id: P-REINFORCE-AUTO-27C7BF
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - V8 Engine Heap Management"
----
-
-# [[V8 Engine Heap Management]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> V8 엔진의 힙 관리는 자바스크립트 애플리케이션의 동적 데이터를 효율적으로 할당하고 회수하기 위한 자동 메모리 관리 시스템이다 [1, 2]. 이 시스템은 대부분의 객체가 생성 직후 쓸모없어진다는 세대 가설(Generational Hypothesis)을 바탕으로 메모리를 여러 세대와 공간으로 분할하여 관리한다 [3-6]. 최신 V8 엔진은 오리노코(Orinoco) 프로젝트를 통해 병렬(Parallel), 점진적(Incremental), 동시(Concurrent) 가비지 컬렉션 기술을 적용하여 애플리케이션의 멈춤 현상(Stop-the-world)을 크게 줄였다 [7-9].
-
-## 📖 구조화된 지식 (Synthesized Content)
-**힙 메모리의 구조 및 분할 (Heap Organization)**
-*   V8의 프로세스 메모리(Resident Set)는 크게 정적 데이터를 저장하는 스택(Stack)과 동적 객체를 저장하는 힙(Heap)으로 나뉜다 [2, 10, 11]. 
-*   가비지 컬렉터(GC)의 효율성을 위해 힙은 세대에 따라 여러 공간으로 나뉜다. 대표적으로 새롭게 생성된 객체가 위치하며 크기가 작고 GC가 매우 빠르게 일어나는 '새로운 공간(New Space)', 2번 이상의 GC 주기를 버틴 객체가 이동하는 '오래된 공간(Old Space)', 1MB 이상의 큰 객체가 개별적으로 매핑되는 '큰 객체 공간(Large Object Space)', 그리고 JIT 컴파일된 명령어를 담는 '코드 공간(Code Space)' 등이 존재한다 [12-14].
-
-**세대별 가비지 컬렉션 작동 방식 (Generational Garbage Collection)**
-*   **Minor GC (Scavenger):** 새로운 공간(New Space / Young Generation)을 관리한다 [3, 15, 16]. 이 공간은 반으로 나뉜 세미 스페이스(To-Space와 From-Space) 구조를 가지며, 메모리가 가득 차면 살아있는 객체만 새로운 영역으로 복사(Evacuate)하여 단편화를 완전히 없애고 남은 가비지를 비운다 [15-18].
-*   **Major GC (Mark-Sweep-Compact):** 오래된 공간(Old Generation)의 메모리를 회수한다 [3, 16, 19]. 스택과 전역 객체 같은 루트(Root)에서부터 참조 가능한 객체를 추적하여 표시(Mark)하고, 참조되지 않는 객체의 메모리 영역을 해제(Sweep)하며, 필요한 경우 살아있는 객체를 한곳으로 모아 단편화를 해결(Compact)한다 [19-24].
-
-**오리노코 가비지 컬렉터 (Orinoco Garbage Collector)**
-*   기존의 순차적 처리로 인한 성능 저하를 극복하기 위해 V8은 오리노코(Orinoco)라는 최신 GC를 도입했다 [8]. 
-*   가비지 컬렉션 작업을 메인 스레드와 헬퍼 스레드가 함께 수행하는 병렬(Parallel) 처리, GC 작업을 잘게 쪼개어 자바스크립트 실행과 교차로 진행하는 점진적(Incremental) 처리, 메인 스레드가 자바스크립트를 실행하는 동안 백그라운드에서 GC를 수행하는 동시(Concurrent) 처리 기법이 혼합되어 사용된다 [7, 9, 25-28].
-
-**메모리 튜닝 및 한계점 (Memory Tuning and Constraints)**
-*   Node.js 환경에서는 `--max-old-space-size` 및 `--max-semi-space-size`와 같은 명령줄 플래그를 통해 힙의 특정 공간 크기를 직접 튜닝하여 메모리 누수 방지 및 성능 향상을 도모할 수 있다 [29, 30].
-*   보안성과 메모리 절약을 위해 적용된 포인터 압축(Pointer Compression) 기술로 인해, 64비트 시스템에서도 V8의 관리되는 힙 크기는 최대 4GB의 '메모리 케이지(V8 Memory Cage)' 내부로 엄격히 제한된다 [31-33].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[Garbage Collection]], [[Generational Hypothesis]], [[Mark-Sweep-Compact]], [[Scavenge]], [[Orinoco]], [[Pointer Compression]]
-- **Projects/Contexts:** [[Node.js Memory Tuning]], [[Chrome DevTools Memory Profiling]], [[V8 Memory Cage]]
-- **Contradictions/Notes:** 자바스크립트는 언어 스펙상 프로그래머가 가비지 컬렉터의 메모리 관리에 직접적으로 개입하거나 제어할 수 없는 것이 원칙이다 [34]. 하지만 Node.js 구동 환경에서는 예외적으로 `--expose-gc` 플래그를 사용하여 프로그램 코드 내부에서 `global.gc()`를 호출해 수동으로 가비지 컬렉션을 강제 실행할 수 있는 우회 방법을 제공한다 [35, 36]. 또한, 전통적으로 힙의 각 페이지(Page) 크기는 1MB로 할당된다고 알려져 있으나 [37], 최근 저사양 기기 최적화 및 단편화 개선을 위해 페이지 크기가 512KB로 축소 적용되는 등 구조적 변화가 일어나고 있다 [38, 39].
-
----
-*Last updated: 2026-04-19*
-- Raw Source: [[00_Raw/2026-04-20/V8 Engine Heap Management.md]]
----
diff --git a/Programming & Language/V8 Engine.md b/Programming & Language/V8 Engine.md
deleted file mode 100644
index 283d85d5..00000000
--- a/Programming & Language/V8 Engine.md	
+++ /dev/null
@@ -1,45 +0,0 @@
----
-id: P-REINFORCE-AUTO-7D181E
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - V8 Engine"
----
-
-# [[V8 Engine]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> V8 Engine은 구글이 C++로 개발한 고성능 자바스크립트 및 웹어셈블리 엔진이다 [1]. 이 엔진은 대부분의 객체가 생성 후 곧바로 소멸한다는 '세대 가설(Generational Hypothesis)'에 기반한 정교한 가비지 컬렉션(GC) 시스템을 통해 메모리를 자동으로 관리한다 [2, 3]. 최신 GC 아키텍처인 오리노코(Orinoco)와 V8 메모리 케이지(Memory Cage) 같은 최적화 및 보안 기법을 적극적으로 도입하여, 메모리 효율성과 애플리케이션의 실행 성능, 안전성을 동시에 보장한다 [4, 5].
-
-## 📖 구조화된 지식 (Synthesized Content)
-**메모리 구조 (Heap & Stack)**
-* V8 프로세스는 'Resident Set'이라 불리는 메모리 영역을 할당받으며, 이는 크게 정적 데이터와 실행 프레임 포인터를 저장하는 스택(Stack)과 동적 객체를 저장하는 힙(Heap)으로 나뉜다 [6-8]. 
-* 힙 메모리는 객체의 생명 주기와 종류에 따라 여러 공간(Space)으로 분할 관리된다 [2, 9]. 새롭게 생성된 객체가 저장되는 'New Space', 오래 살아남은 객체가 승격되어 저장되는 'Old Space(Pointer/Data)', 크기가 큰 객체를 위한 'Large Object Space', JIT 컴파일된 코드가 저장되는 'Code Space' 등이 존재한다 [9, 10].
-* 각 힙 공간은 운영체제로부터 연속적으로 할당받은 '페이지(Page)'라는 단위로 구성되며, 전통적인 페이지 크기는 1MB였으나 저사양 기기에서의 메모리 파편화를 줄이기 위해 512KB로 최적화되기도 했다 [3, 11, 12].
-
-**가비지 컬렉션 (Garbage Collection)**
-* **Minor GC (Scavenger):** 크기가 작고 할당이 빈번한 New Space를 관리하는 고속 수집 방식이다 [3, 13]. 이 공간은 'From-Space'와 'To-Space' 두 개의 반공간(Semi-space)으로 나뉘며, 체니(Cheney) 알고리즘을 활용해 살아있는 객체만을 To-Space로 복사하고 식별되지 않은 가비지를 비우는 작업을 수행한다 [14-16]. 두 번의 Scavenge 주기를 버텨낸 객체는 Old Space로 승격된다 [16, 17].
-* **Major GC (Mark-Sweep-Compact):** 크기가 크고 오래 유지되는 Old Space를 관리한다 [18, 19]. GC 루트에서 도달 가능한 객체를 식별하는 마킹(Marking) 단계, 죽은 객체가 차지한 메모리를 자유 목록(Free list)으로 반환하는 스위핑(Sweeping) 단계, 남은 객체들을 모아 메모리 단편화를 제거하는 압축(Compacting) 단계를 거친다 [19-23]. 
-
-**오리노코(Orinoco) 프로젝트**
-* 전통적인 가비지 컬렉션의 메인 스레드 지연(Stop-the-world) 문제를 해결하기 위해 도입된 최신 GC 아키텍처이다 [5, 24]. 
-* 병렬(Parallel), 동시(Concurrent), 점진적(Incremental) 처리 기법을 결합하여, 메인 스레드가 자바스크립트를 실행하는 동안 백그라운드 헬퍼 스레드에서 마킹과 스위핑 작업을 동시에 수행할 수 있도록 개선되었다 [25-33].
-
-**보안 및 메모리 최적화**
-* **V8 Memory Cage 및 포인터 압축:** 64비트 플랫폼에서 메모리를 절약하기 위해 객체 포인터를 64비트 주소 대신 32비트 오프셋으로 저장하는 'Pointer Compression' 기법을 사용하며, 이로 인해 V8 힙은 4GB 크기의 케이지(Cage) 영역 안에 격리된다 [34-36]. 이는 JIT 컴파일러의 타입 혼동 취약점 등을 이용한 공격자가 임의의 메모리를 덮어쓰거나 읽는 것(Arbitrary Read/Write)을 방지하는 강력한 샌드박스 역할을 한다 [4, 37].
-* **태그된 포인터 (Tagged Pointers):** V8은 메모리 내의 각 단어(word)의 마지막 비트를 예약해 해당 값이 포인터인지 단순 데이터(정수 등)인지 구분함으로써, GC가 객체 그래프를 빠르게 스캔할 수 있도록 지원한다 [38-40].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[Garbage Collection]], [[Orinoco]], [[Pointer Compression]], [[V8 Memory Cage]]
-- **Projects/Contexts:** [[Node.js]], [[Chrome]], [[Electron]]
-- **Contradictions/Notes:** 컴팩션(Compaction)은 단편화를 해결하는 데 매우 유용하지만, 살아있는 큰 객체들을 다른 위치로 복사하고 포인터를 모두 업데이트해야 하므로 비용이 매우 비쌉니다. 따라서 Major GC는 Old Space의 모든 페이지를 매번 압축하지 않고 단편화 정도가 심한 페이지에 대해서만 선택적으로 압축을 수행합니다 [18, 41, 42].
-
----
-*Last updated: 2026-04-19*
-- Raw Source: [[00_Raw/2026-04-20/V8 Engine.md]]
----
diff --git a/Programming & Language/V8 Heap Architecture.md b/Programming & Language/V8 Heap Architecture.md
deleted file mode 100644
index 3f76d54f..00000000
--- a/Programming & Language/V8 Heap Architecture.md	
+++ /dev/null
@@ -1,47 +0,0 @@
----
-id: P-REINFORCE-AUTO-0C14B5
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - V8 Heap Architecture"
----
-
-# [[V8 Heap Architecture]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> V8 엔진의 힙(Heap) 아키텍처는 자바스크립트 런타임에 동적으로 할당되는 데이터와 객체를 저장하기 위해 구조화된 메모리 영역이다 [1]. V8은 메모리 할당 속도를 높이고 가비지 컬렉션(GC)의 오버헤드를 줄이기 위해, 객체의 수명 주기에 기반한 '세대별 가설(Generational Hypothesis)'을 적용하여 힙을 여러 특수 공간(Space)으로 분할한다 [2, 3]. 이를 통해 각기 다른 메모리 영역의 특성에 맞는 최적화된 메모리 회수 알고리즘을 적용할 수 있다 [2].
-
-## 📖 구조화된 지식 (Synthesized Content)
-**힙의 주요 공간(Spaces)**
-V8의 힙은 객체의 특성과 수명에 따라 여러 개의 고유한 공간으로 나뉘어 관리된다.
-*   **New Space (Young Generation)**: 대부분의 새로운 객체가 최초로 할당되는 공간으로, 1MB에서 8MB(또는 64MB) 사이의 작은 크기로 유지된다 [4-6]. 이 공간은 가비지 컬렉션을 매우 빠르게 수행하도록 설계되었으며, 내부적으로 'To-Space'와 'From-Space'라는 두 개의 동일한 반공간(semi-space)으로 나뉜다 [6, 7]. 이 영역은 Scavenger라 불리는 Minor GC 알고리즘(Cheney's algorithm 기반)에 의해 관리되며, 여기서 두 번의 GC 주기를 살아남은 객체는 Old Space로 이동(승격, Promotion)된다 [5-7].
-*   **Old Space (Old Generation)**: New Space에서 살아남은 수명이 긴 객체들이 저장되는 공간으로 훨씬 더 큰 크기를 갖는다 [4, 5, 8]. 가비지 컬렉터의 마킹 속도를 최적화하기 위해, 다른 객체에 대한 포인터를 포함하는 **Old-pointer-space**와 문자열이나 박싱된 숫자처럼 원시 데이터만 포함하여 포인터 추적이 필요 없는 **Old-data-space**로 세분화된다 [2, 4, 8]. 이 공간은 Mark-Sweep-Compact 방식의 Major GC에 의해 관리된다 [9].
-*   **Large Object Space**: 다른 공간의 크기 제한(일반적으로 1MB)을 초과하는 거대한 객체들이 저장된다 [2, 4]. 각 객체는 운영체제로부터 `mmap`을 통해 직접 할당받은 전용 메모리 영역을 가지며, 가비지 컬렉터에 의해 결코 메모리 위치가 이동되지 않는다 [2, 4].
-*   **Code Space**: JIT(Just-In-Time) 컴파일러가 생성한 실행 가능한 기계어 코드(Code objects)가 할당되는 곳이다 [2, 4]. 힙 내에서 유일하게 실행 권한(Executable)이 부여된 메모리 공간이다 [2, 4].
-*   **특수 및 불변 공간**: 모든 객체의 크기가 동일하여 수집을 단순화할 수 있는 **Cell-space**, **Property-cell-space**, **Map-space**가 있으며 [4, 10], 변하지 않고 이동하지 않는 불변 객체를 저장하는 **Read Only Space**도 존재한다 [11].
-
-**페이지(Pages) 구조**
-힙의 각 공간은 '페이지(Pages)'라는 여러 개의 연속된 메모리 청크의 집합으로 구성된다 [3, 12]. 
-*   일반적으로 페이지의 크기는 1MB이며 1MB 단위로 정렬되지만, Large Object Space의 페이지는 더 클 수 있다 [12]. 최근에는 저메모리 환경 최적화를 위해 페이지 크기를 512KB로 줄여 메모리 단편화를 감소시키고 압축 효율을 높인 사례도 있다 [3, 13, 14].
-*   각 페이지에는 메모리 객체 외에도 다양한 플래그와 메타데이터가 담긴 헤더(Header), 라이브 객체를 나타내는 마킹 비트맵(Marking bitmap)이 포함된다 [3, 12]. 
-*   또한 별도의 메모리에 할당된 슬롯 버퍼(Slots buffer)를 가져, 해당 페이지에 있는 객체를 가리키는 다른 객체들의 포인터 목록인 '기억 집합(Remembered set)'을 형성한다 [3, 12].
-
-**포인터 압축과 메모리 케이지(V8 Memory Cage)**
-보안 및 성능 최적화를 위해 V8은 64비트 플랫폼에서 '포인터 압축(Pointer Compression)' 기술을 사용한다 [15, 16].
-*   객체의 참조를 64비트 전체 주소 대신, 기준 주소(Base address)로부터의 32비트 오프셋(Offset)으로 저장하여 객체 포인터의 메모리 오버헤드를 절반으로 줄인다 [16].
-*   이 방식은 구조적으로 모든 V8 힙 객체가 4GB 크기의 연속된 메모리 영역인 "케이지(Cage)" 내부에 갇혀 있도록 강제한다 [16, 17]. 따라서 전체 시스템의 메모리가 아무리 많아도, 단일 V8 인스턴스의 관리되는 힙 크기는 4GB를 초과할 수 없다 [17, 18].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[Garbage Collection]], [[Generational Hypothesis]], [[V8 Memory Cage]], [[Pointer Compression]]
-- **Projects/Contexts:** [[Google Chrome]], [[Node.js]], [[Electron]]
-- **Contradictions/Notes:** 일반적으로 V8 페이지의 크기는 1MB로 알려져 있으나 [12], 모바일 장치나 데스크탑 환경에서의 메모리 단편화 개선 및 사용량 최적화를 위해 512KB로 축소 적용되기도 하였다 [13, 14].
-
----
-*Last updated: 2026-04-19*
-- Raw Source: [[00_Raw/2026-04-20/V8 Heap Architecture.md]]
----
diff --git a/Programming & Language/V8 JavaScript Engine 메모리 관리 및 가비지 컬렉션.md b/Programming & Language/V8 JavaScript Engine 메모리 관리 및 가비지 컬렉션.md
deleted file mode 100644
index ede2f90b..00000000
--- a/Programming & Language/V8 JavaScript Engine 메모리 관리 및 가비지 컬렉션.md	
+++ /dev/null
@@ -1,30 +0,0 @@
----
-id: P-REINFORCE-AUTO-44DD69
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - V8 JavaScript Engine 메모리 관리 및 가비지 컬렉션"
----
-
-# [[V8 JavaScript Engine 메모리 관리 및 가비지 컬렉션]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> V8 엔진은 동적인 데이터를 관리하기 위해 메모리를 힙(Heap)과 스택(Stack)으로 구분하며, 가비지 컬렉션(GC)을 통해 더 이상 참조되지 않는 메모리를 자동으로 회수한다 [1-3]. V8은 대다수 객체의 수명이 짧다는 '세대적 가설(Generational Hypothesis)'을 기반으로 힙 영역을 여러 세대 공간으로 나누어 관리하고, 각기 다른 GC 알고리즘(Scavenge, Mark-Sweep-Compact 등)을 적용해 성능을 최적화한다 [4-7]. 근래에는 'Orinoco' 프로젝트를 통해 메인 스레드의 실행을 멈추는 'Stop-the-world' 현상을 최소화하기 위해 병렬(Parallel), 점진적(Incremental), 동시(Concurrent) 방식의 GC 기법을 도입하여 애플리케이션의 지연 시간(Latency)을 크게 개선했다 [6, 8, 9].
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** `[[Garbage Collection]]`, `[[Cheney's Algorithm]]`, `[[Mark-Sweep-Compact]]`, `[[Orinoco GC]]`, `[[Pointer Compression]]`, `[[Generational Hypothesis]]`
-- **Projects/Contexts:** `[[Node.js Memory Management]]`, `[[Chrome V8 Heap Analysis]]`, `[[Electron V8 Memory Cage]]`
-- **Contradictions/Notes:** Minor GC(Scavenger)에서 살아남은 객체를 지속적으로 다른 메모리 공간으로 복사(Evacuate/Copy)하는 방식은 얼핏 보기에 비용이 매우 큰 작업처럼 보인다. 그러나 '대다수의 객체가 곧바로 죽는다'는 세대적 가설(Generational Hypothesis) 덕분에 실제로 복사되는 객체는 아주 소수에 불과하며, 오히려 살아남은 것들만 모아주어 나머지 공간 전체를 즉시 재사용할 수 있게 하므로 전체적인 할당 속도와 단편화 관리에 훨씬 유리하다 [5, 14, 50].
-
----
-*Last updated: 2026-04-19*
-- Raw Source: [[00_Raw/2026-04-20/V8 JavaScript Engine 메모리 관리 및 가비지 컬렉션.md]]
----
diff --git a/Programming & Language/V8 JavaScript Engine.md b/Programming & Language/V8 JavaScript Engine.md
deleted file mode 100644
index 74ebf2e0..00000000
--- a/Programming & Language/V8 JavaScript Engine.md	
+++ /dev/null
@@ -1,38 +0,0 @@
----
-id: P-REINFORCE-AUTO-E8BF09
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - V8 JavaScript Engine"
----
-
-# [[V8 JavaScript Engine]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> V8 JavaScript Engine은 자바스크립트를 해석하고 네이티브 기계어로 컴파일하는 고성능 자바스크립트 및 WebAssembly 엔진이다 [1]. 애플리케이션 실행 시 스택(Stack)과 힙(Heap)으로 구분되는 '레지던트 세트(Resident Set)' 메모리 구조를 기반으로 작동한다 [2, 3]. 특히 세대별 가설(Generational Hypothesis)을 적용한 고급 가비지 컬렉션(GC) 시스템과 최신 동시성 처리 기법을 활용하여 성능 저하 없이 효율적이고 안전하게 메모리를 관리하는 것이 특징이다 [4-6].
-
-## 📖 구조화된 지식 (Synthesized Content)
-V8 JavaScript Engine은 성능과 메모리 효율을 극대화하기 위해 복잡한 내부 아키텍처와 최적화 기법을 사용한다. 소스에서 확인된 핵심 내용은 다음과 같다:
-
-*   **메모리 구조 (Resident Set)**: V8은 각 자바스크립트 컨텍스트당 단일 프로세스를 사용하며, 메모리를 스택(Stack)과 힙(Heap)으로 구분한다 [2, 7]. 스택은 함수 프레임과 정적 데이터를, 힙은 런타임에 할당되는 동적 데이터를 저장한다 [8, 9]. 힙 메모리는 객체의 수명에 따라 '새로운 공간(New Space)'과 '오래된 공간(Old Space)'을 비롯해 대형 객체 공간(Large Object Space), 코드 공간(Code Space) 등으로 나뉜다 [10-12].
-*   **세대별 가비지 컬렉션 (Generational GC)**: 대부분의 객체가 생성 직후 소멸한다는 '세대별 가설'을 기반으로 힙 메모리의 쓰레기를 수집한다 [4, 13, 14].
-    *   **Scavenger (Minor GC)**: '새로운 공간'에서 동작하며, 공간을 To-Space와 From-Space로 절반씩 나누어 살아남은 객체만을 연속된 메모리로 복사(Evacuation)하는 Cheney 알고리즘을 사용해 파편화 없이 빠르게 정리한다 [15-17].
-    *   **Mark-Sweep-Compact (Major GC)**: '오래된 공간'에서 동작하며, 살아있는 객체를 탐색하여 마킹(Mark)하고 죽은 객체를 쓸어버려(Sweep) 빈 공간(Free-list)을 확보한 뒤, 필요한 경우 메모리를 압축(Compact)하여 파편화를 줄인다 [18-21].
-*   **Orinoco 프로젝트**: 기존의 가비지 컬렉션이 유발하는 긴 멈춤 현상(Stop-the-world)을 줄이기 위해 도입된 프로젝트이다 [5, 22]. 메인 스레드와 보조 스레드가 함께 작업하는 병렬(Parallel), 자바스크립트 실행 중간중간에 작업을 나누어 하는 점진적(Incremental), 백그라운드에서 완전히 독립적으로 수행되는 동시성(Concurrent) 기법을 활용하여 지연(Latency)을 대폭 감소시켰다 [22-26].
-*   **보안과 메모리 최적화 (Memory Cage & Pointer Compression)**: 64비트 시스템에서 메모리 오버헤드를 줄이기 위해 포인터를 32비트로 저장하는 '포인터 압축(Pointer Compression)'을 도입하여 V8 힙의 최대 크기를 4GB로 제한한다 [27, 28]. 이러한 구조는 힙 내부의 포인터만 허용하는 '메모리 케이지(Memory Cage)' 역할을 하여, 공격자가 타입 혼란(Type Confusion) 등을 이용해 외부 메모리를 임의로 읽고 쓰는 악의적 익스플로잇(`addrof`, `fakeobj` 등)을 방지하는 강력한 보안 경계를 제공한다 [29-33].
-*   **디버깅 및 메모리 누수 분석**: V8은 `--trace-gc` 와 같은 런타임 플래그를 통해 GC 과정과 메모리 상태를 상세하게 로깅하며 [34-36], Chrome DevTools의 힙 스냅샷(Heap Snapshot)과 할당 타임라인(Allocation Timeline) 도구를 통해 가비지 컬렉션에서 수거되지 못한 채 남아있는 객체의 참조 경로(Retaining Path)를 추적하여 메모리 누수를 해결할 수 있도록 돕는다 [37-40].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[Garbage Collection]], [[Resident Set]], [[Orinoco Project]], [[Memory Cage]], [[Pointer Compression]]
-- **Projects/Contexts:** [[Node.js]], [[Google Chrome]], [[Electron]]
-- **Contradictions/Notes:** 가비지 컬렉터를 통해 V8 엔진이 메모리를 자동으로 관리하여 편리함을 제공하지만, 자바스크립트(ECMAScript) 사양 자체는 개발자가 가비지 컬렉터를 직접 측정하거나 제어할 수 있는 공식적인 인터페이스를 제공하지 않는다는 한계가 존재한다 [41]. 또한 수명이 짧은 객체를 다루는 Minor GC는 객체를 새 공간으로 '복사(Copy)'하여 할당 속도를 높이는 방식을 취하지만, 수명이 긴 객체가 모인 Major GC 영역에서는 복사 비용이 비효율적이므로 주로 'Mark-Sweep'을 수행하고 예외적인 상황에서만 압축(Compact)을 진행하는 전략적 차이를 보인다 [14, 20, 21].
-
----
-*Last updated: 2026-04-19*
-- Raw Source: [[00_Raw/2026-04-20/V8 JavaScript Engine.md]]
----
diff --git a/Programming & Language/V8 JavaScript 엔진.md b/Programming & Language/V8 JavaScript 엔진.md
deleted file mode 100644
index ffe91caf..00000000
--- a/Programming & Language/V8 JavaScript 엔진.md	
+++ /dev/null
@@ -1,46 +0,0 @@
----
-id: P-REINFORCE-AUTO-383B09
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - V8 JavaScript 엔진"
----
-
-# [[V8 JavaScript 엔진]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-**1. 메모리 구조와 힙(Heap) 공간 분할**
-V8 프로세스는 운영체제로부터 할당받은 'Resident Set' 메모리를 스택과 힙으로 나누어 사용합니다 [4, 10]. 스택은 정적 데이터(메서드 프레임, 원시 값, 포인터)를 저장하고, 힙은 동적으로 생성되는 객체 데이터를 저장합니다 [11, 12]. 대부분의 객체는 생성 후 금방 버려진다는 '세대 가설(Generational Hypothesis)'에 따라 힙은 여러 공간(Space)으로 나뉩니다 [5, 13].
-* **New Space (Young Generation):** 새로운 객체가 할당되는 작고 빠른 공간입니다. From-Space와 To-Space로 나뉘며, 'Scavenger(Minor GC)'에 의해 관리됩니다 [14-16].
-* **Old Space (Old Generation):** New Space에서 두 번의 GC를 버틴 살아남은 객체들이 이동하는 큰 공간입니다. 포인터가 있는 객체와 데이터만 있는 객체 공간으로 나뉘며, Major GC가 관리합니다 [2, 12, 15].
-* **Large Object Space:** 다른 공간의 크기 제한을 초과하는 큰 객체가 저장되며, 이 객체들은 GC에 의해 이동되지 않습니다 [2, 15].
-* **Code Space:** JIT 컴파일러에 의해 생성된 실행 가능한 머신 코드가 저장되는 유일한 공간입니다 [2, 12, 15].
-
-**2. Orinoco 가비지 컬렉터 (Garbage Collection)**
-V8은 애플리케이션의 멈춤 현상(Stop-the-world)을 최소화하기 위해 병렬(Parallel), 점진적(Incremental), 동시적(Concurrent) 방식을 결합한 Orinoco 가비지 컬렉터를 사용합니다 [8, 17, 18].
-* **Minor GC (Scavenger):** New Space의 여유 공간이 부족할 때 발생합니다. 살아있는 객체만 새로운 공간으로 복사(Evacuate)하고 나머지는 버리는 방식을 사용하여 메모리 단편화를 제거합니다 [14, 19, 20].
-* **Major GC (Mark-Sweep-Compact):** Old Space를 관리하며 마킹(Marking), 스위핑(Sweeping), 압축(Compacting)의 3단계를 거칩니다 [21]. 메인 스레드의 JavaScript 실행과 동시에 백그라운드에서 마킹과 스위핑을 진행하여 지연 시간을 대폭 줄입니다 [22-24].
-
-**3. V8 메모리 케이지와 포인터 압축 (Security & Pointer Compression)**
-64비트 플랫폼에서 V8은 메모리 사용량을 줄이기 위해 '포인터 압축(Pointer Compression)'을 사용합니다. 포인터를 64비트 전체 주소가 아닌 32비트 오프셋으로 저장하여 객체 참조에 필요한 메모리를 절반으로 줄입니다 [25, 26]. 이로 인해 V8의 관리되는 힙 메모리는 최대 4GB의 연속된 '메모리 케이지(Memory Cage)' 영역 안에 갇히게 됩니다 [25, 27, 28]. 메모리 케이지는 V8 엔진의 JIT 버그를 악용한 임의 메모리 읽기/쓰기 공격을 방어하는 보안 기술이기도 합니다 [29, 30].
-
-**4. 데이터 최적화 구조**
-V8은 객체와 포인터를 빠르게 식별하기 위해 단어의 마지막 비트를 태그로 사용하는 '태그된 포인터(Tagged Pointers)' 기법을 사용합니다 [31, 32]. 또한 문자열 최적화를 위해 문자열을 단순히 복사하지 않고 기존 문자열을 참조하는 'ConsString(Ropes)'이나 'SlicedString' 구조를 활용하여 메모리 할당 시간과 공간을 절약합니다 [33-36]. 메모리 단편화를 줄이기 위해 최근에는 페이지(Page) 크기를 1MB에서 512KB로 줄여 저사양 기기에서의 메모리 효율을 향상시켰습니다 [37, 38].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[Garbage Collection]], [[Orinoco]], [[Pointer Compression]], [[V8 Memory Cage]], [[Scavenger]], [[Generational Hypothesis]]
-- **Projects/Contexts:** [[Node.js]], [[Chrome]], [[Electron]]
-- **Contradictions/Notes:** 모바일 같은 저메모리 디바이스에서는 V8이 가비지 컬렉션의 지연 시간이나 처리량보다는 메모리 소비를 줄이기 위해 GC를 더 자주 실행하도록 휴리스틱을 엄격하게 조정합니다. 이로 인해 메모리는 절약되지만 GC 비용(빈도)이 증가하는 트레이드오프가 존재합니다 [39, 40].
-
----
-*Last updated: 2026-04-19*
-- Raw Source: [[00_Raw/2026-04-20/V8 JavaScript 엔진.md]]
----
diff --git a/Programming & Language/V8 Memory Cage.md b/Programming & Language/V8 Memory Cage.md
deleted file mode 100644
index ddf70d8d..00000000
--- a/Programming & Language/V8 Memory Cage.md	
+++ /dev/null
@@ -1,30 +0,0 @@
----
-id: P-REINFORCE-AUTO-BEAD76
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - V8 Memory Cage"
----
-
-# [[V8 Memory Cage]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> V8 Memory Cage(또는 V8 Sandbox)는 V8 JavaScript 엔진의 힙 객체들을 제한된 연속 메모리 영역(일반적으로 4GB) 내에 격리하는 보안 및 최적화 아키텍처입니다 [1, 2]. 이 구조는 메모리 내에 실제 포인터 대신 기준 주소로부터의 오프셋(offset)을 저장하여, 공격자가 취약점을 이용해 프로세스의 임의 메모리를 읽고 쓰는 것을 방지합니다 [3]. 포인터 압축을 통해 메모리 사용량을 줄이고 성능을 향상시키지만, 힙 외부(off-heap) 메모리를 직접 참조하는 ArrayBuffer 생성이 제한된다는 단점이 있습니다 [4, 5].
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[Pointer Compression]], [[ArrayBuffer]], [[Type Confusion]], [[V8 Heap]]
-- **Projects/Contexts:** [[Electron 21+]], [[Chromium 103+]], [[Node.js Native Modules]]
-- **Contradictions/Notes:** V8 메모리 케이지는 보안과 전반적인 성능 측면에서 이점이 크지만, V8 힙 용량이 4GB로 제한된다는 분명한 단점이 있습니다 [4, 5]. 대용량 메모리가 필수적인 앱의 경우 자식 프로세스로 워크로드를 분리하거나 포인터 압축이 비활성화된 사용자 지정 빌드를 사용해야 하는 워크어라운드가 필요합니다 [11].
-
----
-*Last updated: 2026-04-19*
-- Raw Source: [[00_Raw/2026-04-20/V8 Memory Cage.md]]
----
diff --git a/Programming & Language/V8 가비지 컬렉션(Garbage Collection).md b/Programming & Language/V8 가비지 컬렉션(Garbage Collection).md
deleted file mode 100644
index eb765eda..00000000
--- a/Programming & Language/V8 가비지 컬렉션(Garbage Collection).md	
+++ /dev/null
@@ -1,49 +0,0 @@
----
-id: P-REINFORCE-AUTO-488812
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - V8 가비지 컬렉션(Garbage Collection)"
----
-
-# [[V8 가비지 컬렉션(Garbage Collection)]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> V8 가비지 컬렉션은 애플리케이션의 메모리를 자동으로 관리하기 위해 더 이상 사용되지 않는 죽은 메모리 영역을 식별하고 운영체제로 반환하거나 재사용하는 프로세스입니다 [1]. 가비지 컬렉터는 루트(Root) 객체에서 시작하는 포인터 체인을 통해 도달할 수 없는 객체를 죽은 객체(가비지)로 간주하여 처리합니다 [1, 2]. V8은 대다수의 객체가 일찍 죽는다는 특성을 활용하여 힙 메모리를 세대별로 분할하고, 각 공간에 최적화된 마이너 GC(Minor GC)와 메이저 GC(Major GC)를 수행합니다 [3, 4].
-
-## 📖 구조화된 지식 (Synthesized Content)
-**힙 메모리 구조 (Heap Organization)**
-V8은 힙을 객체의 생존 기간 및 용도에 따라 여러 공간으로 분할합니다 [5]. 
-- **New-space**: 대부분의 새로운 객체가 할당되는 작고 빠른 영역입니다 [5].
-- **Old-space**: New-space에서 일정 시간 살아남은 객체들이 이동하는 영역으로, 다른 객체를 가리키는 포인터가 포함된 'Old-pointer-space'와 원시 데이터만 포함된 'Old-data-space'로 세분화됩니다 [5]. 
-- **그 외 공간**: 이 외에도 대용량 객체를 위한 'Large-object-space', 실행 가능한 코드를 저장하는 'Code-space', 그리고 크기가 일정한 내부 객체 관리를 위한 'Cell/Map-space' 등이 존재합니다 [5]. 
-각 공간은 연속된 메모리 청크인 여러 개의 페이지(Page)로 구성되며, 각 페이지는 일반적으로 1MB 또는 512KB의 크기로 관리됩니다 [6, 7].
-
-**포인터 식별 (Tagged Pointers)**
-가비지 컬렉터가 힙 내에서 살아있는 객체를 탐색하려면 포인터와 일반 데이터를 구분해야 합니다 [8]. V8은 컴파일러의 제한적인 지원만으로도 효율적으로 식별이 가능한 '태그된 포인터(Tagged pointers)' 방식을 사용합니다 [9]. 각 워드의 마지막 비트를 예약하여 데이터와 포인터를 구분하므로 가비지 컬렉터가 객체 스캔 시 정수를 무시하고 포인터만 빠르게 따라갈 수 있습니다 [9, 10].
-
-**세대별 가비지 컬렉션 (Generational Collection)**
-- **마이너 GC (Scavenge)**: New-space를 관리하는 가비지 컬렉터로, 할당 포인터가 New-space의 끝에 도달하면 시작됩니다 [3, 11]. 체니(Cheney)의 알고리즘을 기반으로 New-space를 크기가 같은 두 개의 반공간(To-space와 From-space)으로 나누어 작동합니다 [11, 12]. 가비지 컬렉션이 트리거되면 살아있는 객체만 To-space로 대피시키며(복사 및 압축), 두 번의 사이클에서 살아남은 객체는 Old-space로 승격(Promote)시킵니다 [11, 13].
-- **메이저 GC (Mark-Sweep-Compact)**: 크기가 큰 Old-space의 가비지를 수집하기 위해 마킹(Marking), 스위핑(Sweeping), 압축(Compacting) 단계를 거칩니다 [14]. 마킹 단계에서는 힙을 방향성 그래프로 간주하여 깊이 우선 탐색(DFS)을 수행하고 객체 상태를 흰색, 회색, 검은색 비트로 표시합니다 [15, 16]. 이후 마킹되지 않은 죽은 객체의 영역을 찾아 여유 공간으로 반환하는 스위핑 작업이나, 살아있는 객체를 모아 메모리 단편화를 줄이는 압축 작업을 수행합니다 [17, 18].
-
-**Orinoco와 최신 GC 최적화**
-과거의 가비지 컬렉터는 메인 스레드를 멈추는 'Stop-the-world' 방식으로 인해 지연 시간이 발생했습니다 [19]. V8은 Orinoco 프로젝트를 통해 이 한계를 극복하고 다양한 최적화 기법을 도입했습니다 [20, 21].
-- **Parallel (병렬)**: 메인 스레드와 헬퍼 스레드가 동시에 가비지 컬렉션 작업을 분담하여 총 일시 중지 시간을 줄입니다 [22].
-- **Incremental (점진적)**: 메인 스레드가 JS 실행 중간중간에 작은 조각 단위로 마킹 작업을 수행하여 긴 멈춤을 방지합니다 [19, 23].
-- **Concurrent (동시)**: 메인 스레드가 JS를 계속 실행하는 동안 백그라운드의 헬퍼 스레드가 완전히 독립적으로 마킹 및 스위핑을 수행합니다 [24, 25].
-메인 스레드 실행 중 객체 그래프가 변경되는 문제는 쓰기 장벽(Write barriers)을 통해 지속적으로 변경사항을 추적하여 해결합니다 [26, 27].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[세대별 가설(Generational Hypothesis)]], [[마크-스위프-컴팩트(Mark-Sweep-Compact)]], [[마이너 GC(Scavenge)]], [[Orinoco 가비지 컬렉터]]
-- **Projects/Contexts:** [[Node.js]], [[Chrome V8 엔진]], [[Orinoco 프로젝트]]
-- **Contradictions/Notes:** 소스에 따르면 과거의 Scavenge 알고리즘은 동기식(Synchronous)인 체니(Cheney) 알고리즘을 구현하였으나, Chrome과 Node.js가 구동되는 현대의 멀티코어 환경에 발맞추어 현재의 V8은 다중 스레드를 활용해 동적으로 작업을 분배하는 병렬(Parallel) Scavenger로 진화했습니다 [28, 29].
-
----
-*Last updated: 2026-04-19*
-- Raw Source: [[00_Raw/2026-04-20/V8 가비지 컬렉션(Garbage Collection).md]]
----
diff --git a/Programming & Language/V8 메모리 케이지(V8 Memory Cage).md b/Programming & Language/V8 메모리 케이지(V8 Memory Cage).md
deleted file mode 100644
index fad6c869..00000000
--- a/Programming & Language/V8 메모리 케이지(V8 Memory Cage).md	
+++ /dev/null
@@ -1,36 +0,0 @@
----
-id: P-REINFORCE-AUTO-F23E51
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - V8 메모리 케이지(V8 Memory Cage)"
----
-
-# [[V8 메모리 케이지(V8 Memory Cage)]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> V8 메모리 케이지(V8 Memory Cage)는 V8 힙 내부에 메모리 포인터를 직접 저장하지 않고, 예약된 특정 영역의 시작점을 기준으로 한 오프셋(Offset)만을 저장하여 메모리를 격리하는 보안 기술입니다 [1]. 이 기술은 JIT 엔진의 타입 혼동 버그 등을 악용하여 공격자가 V8 힙 영역을 벗어난 프로세스 메모리를 임의로 읽고 쓰는 것을 원천적으로 차단하기 위해 고안되었습니다 [1, 2]. 64비트 플랫폼에서 포인터 압축(Pointer Compression) 기술과 결합하여 작동하며, 모든 V8 힙 객체를 4GB 크기의 연속된 '케이지(Cage)' 영역 내에 강제로 제한합니다 [3].
-
-## 📖 구조화된 지식 (Synthesized Content)
-* **작동 원리 및 포인터 압축 결합:** 
-  V8 메모리 케이지는 64비트 플랫폼에서 포인터 압축(Pointer compression) 기술을 기반으로 작동합니다 [3, 4]. V8 힙 내의 다른 메모리에 대한 참조는 전체 64비트 주소로 저장되지 않고 케이지 베이스(Base) 주소로부터의 32비트 오프셋으로 저장됩니다 [1, 3]. 이로 인해 객체 참조를 위한 메모리 오버헤드가 절반으로 줄어들며, 동시에 모든 힙 객체가 4GB의 공간에 갇히게 됩니다 [3].
-* **보안 상의 이점:**
-  V8의 JIT 엔진에서 논리적 오류(예: 객체의 타입을 잘못 유추하는 타입 혼동)가 발생할 경우, 공격자가 `ArrayBuffer`의 시작 주소 등을 덮어써서 전체 프로세스 메모리를 임의로 조작하는 취약점이 존재할 수 있습니다 [2]. 메모리 케이지는 포인터 오프셋 방식을 사용하여 공격자가 베이스 주소를 손상시키더라도 오직 케이지 내부의 메모리에만 접근할 수 있도록 제한함으로써 이러한 부류의 취약점 공격을 방지합니다 [1].
-* **개발 상의 제한 사항 및 호환성 문제:**
-  * **외부 버퍼(External Buffer) 참조 금지:** 케이지 기능이 활성화되면 V8 힙 외부("off-heap") 메모리를 가리키는 `ArrayBuffer`를 생성할 수 없습니다 [5, 6]. 메모리를 외부에서 할당(`malloc` 등)한 뒤 `ArrayBuffer`로 래핑하던 기존의 네이티브 모듈(Native Module)들은 런타임 크래시를 발생시킵니다 [7, 8]. 이를 해결하기 위해서는 외부 데이터를 케이지 내부로 복사하거나 처음부터 V8의 메모리 할당자를 사용하도록 리팩터링해야 합니다 [9].
-  * **최대 4GB 힙 메모리 한계:** 포인터 압축 및 케이지 구조의 특성상 단일 V8 인스턴스(Isolate)가 가질 수 있는 V8 힙의 최대 크기는 4GB로 제한됩니다 [3, 5]. 메모리 한계에 근접하게 되면 Out of Memory (OOM) 충돌을 막기 위해 엔진이 필사적으로 공간을 확보하려 하므로 Major GC(가비지 컬렉션) 빈도가 급격히 증가합니다 [6].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[포인터 압축(Pointer Compression)]], [[ArrayBuffer]], [[가비지 컬렉션(Garbage Collection)]]
-- **Projects/Contexts:** [[Electron]], [[Chromium]], [[Node.js Native Modules]]
-- **Contradictions/Notes:** 소스 문헌들은 메모리 케이지 및 포인터 압축이 성능(CPU 및 GC)을 5%~10% 향상시키고 보안을 강화한다고 설명하지만, 이로 인해 외부 메모리 버퍼를 지원하지 않아 네이티브 모듈에서 호환성 문제가 생기고 힙 크기가 4GB로 제한되는 명확한 트레이드오프(Trade-off)가 있음을 함께 강조합니다 [5, 10].
-
----
-*Last updated: 2026-04-19*
-- Raw Source: [[00_Raw/2026-04-20/V8 메모리 케이지(V8 Memory Cage).md]]
----
diff --git a/Programming & Language/V8 엔진 (V8 Engine).md b/Programming & Language/V8 엔진 (V8 Engine).md
deleted file mode 100644
index ba37598d..00000000
--- a/Programming & Language/V8 엔진 (V8 Engine).md	
+++ /dev/null
@@ -1,45 +0,0 @@
----
-id: P-REINFORCE-AUTO-D6DB20
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - V8 엔진 (V8 Engine)"
----
-
-# [[V8 엔진 (V8 Engine)]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-**메모리 아키텍처 및 레지던트 세트 (Memory Architecture and Resident Set)**
-V8은 운영체제로부터 프로세스 레벨의 물리적 메모리인 '레지던트 세트(Resident Set)'를 할당받아 실행하며, 이를 크게 스택(Stack)과 힙(Heap) 두 영역으로 나눕니다 [5, 6]. 스택은 메서드 프레임, 원시 값(Primitive values), 그리고 힙의 객체를 참조하는 포인터 등 정적 데이터를 저장하는 데 사용됩니다 [5, 7]. 힙은 동적 데이터와 객체가 저장되는 공간으로 가장 크며, 관리 방식에 따라 다시 여러 세그먼트로 나뉩니다 [8, 9]. 주요 세그먼트로는 대부분의 새 객체가 할당되는 'New Space', 오래 생존한 객체가 이동하는 'Old Space', 크기가 매우 큰 객체를 저장하는 'Large Object Space', JIT 컴파일된 머신 코드가 저장되는 'Code Space' 등이 있습니다 [9-11].
-
-**가비지 컬렉션 (Garbage Collection)**
-V8의 메모리 관리는 "대부분의 객체는 생성된 직후 금방 죽는다"는 세대적 가설(Generational Hypothesis)에 크게 의존합니다 [12-14]. 이 가설에 따라 V8은 두 개의 주요 가비지 컬렉터를 운영합니다.
-*   **Minor GC (Scavenger)**: New Space(Young Generation)의 메모리를 관리합니다 [12, 15]. 이곳의 메모리는 매우 작고 할당이 빠르며, 메모리 포인터가 한계에 도달하면 Scavenger가 작동합니다 [12, 16]. V8은 Cheney의 알고리즘에 기반한 세미 스페이스(Semi-space) 설계를 통해 New Space를 'From-Space'와 'To-Space'로 나누고, 살아있는 객체만을 복사하여 이동시킨 뒤 두 공간을 교환(Swap)하여 단편화를 방지합니다 [15, 17, 18]. Minor GC를 2회 이상 생존한 객체는 Old Space로 승격(Promotion)됩니다 [12, 19, 20].
-*   **Major GC (Mark-Sweep-Compact)**: 수백 메가바이트의 데이터를 포함할 수 있는 Old Space의 관리를 담당합니다 [21-23]. 이 알고리즘은 GC 루트(전역 객체, 스택 등)로부터 접근 가능한 객체를 식별하여 '살아있음(Black)'으로 표시(Marking)하고, 닿지 않는 객체의 메모리를 해제(Sweeping)합니다 [24-26]. 그런 다음, 메모리의 단편화를 줄이기 위해 살아남은 객체들을 모으는 압축(Compacting) 과정을 수행합니다 [26, 27].
-
-**Orinoco 가비지 컬렉터와 최적화 기법**
-가비지 컬렉션이 일어나는 동안 자바스크립트 실행이 멈추는 'Stop-the-world' 현상을 완화하기 위해, V8은 Orinoco라는 프로젝트를 통해 GC 기술을 대폭 발전시켰습니다 [4, 16, 28].
-*   **Parallel(병렬)**: 메인 스레드와 헬퍼 스레드가 동시에 가비지 컬렉션 작업을 나누어 처리합니다 [28].
-*   **Concurrent(동시성)**: 메인 스레드가 자바스크립트를 계속 실행하는 동안, 헬퍼 스레드들이 백그라운드에서 마킹(Marking)이나 스위핑(Sweeping) 등의 GC 작업을 전적으로 수행합니다 [29]. V8은 쓰기 장벽(Write Barriers)을 통해 자바스크립트 실행 도중 변하는 객체 간의 참조 상태를 추적합니다 [30-32].
-*   **Incremental(점진적)**: 한 번의 긴 GC 멈춤 대신, 마킹 작업을 작은 단위로 쪼개어 자바스크립트 실행 사이사이에 짧게 여러 번 수행하도록 합니다 [33, 34].
-
-**메모리 샌드박스와 포인터 압축 (Memory Cage & Pointer Compression)**
-64비트 시스템에서 V8은 메모리 오버헤드를 줄이기 위해 포인터를 32비트 오프셋으로 저장하는 '포인터 압축(Pointer Compression)' 기법을 사용합니다 [35-37]. 이로 인해 V8의 관리되는 힙 공간은 최대 4GB의 크기를 갖는 인접한 메모리 영역(V8 Memory Cage 또는 Sandbox)으로 제한됩니다 [36, 38, 39]. 메모리 케이지는 JIT 엔진 버그 등으로부터 V8 내부의 임의의 메모리 읽기/쓰기가 발생하더라도 공격자가 샌드박스 외부 시스템을 통제할 수 없게 막는 보안 효과를 가집니다 [40, 41]. 한편, V8은 `ElementsKind`를 통해 배열 내부 데이터(Raw double vs Tagged pointer)를 최적화하여 저장하는데, 공격자가 Out-of-bounds 등의 취약점을 이용해 배열의 길이나 Map 구조를 손상시킬 경우(`addrof`, `fakeobj` 프리미티브 등) 타입 혼돈(Type Confusion)을 유발하여 힙 아키텍처를 공격할 수도 있습니다 [42-44].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** `[[Orinoco GC]]`, `[[Generational Hypothesis]]`, `[[Mark-Sweep-Compact]]`, `[[V8 Memory Cage]]`
-- **Projects/Contexts:** `[[Node.js]]`, `[[Google Chrome]]`, `[[Electron]]`, `[[WebAssembly]]`
-- **Contradictions/Notes:** V8에 도입된 포인터 압축 기술(Pointer Compression)은 V8 힙 메모리 크기를 최대 40% 감소시키고 CPU 및 GC 성능을 5~10% 향상시키는 장점이 있지만, 그로 인해 V8 힙 크기가 최대 4GB로 제한된다는 단점 또한 명확히 존재합니다 [38, 45]. 추가로, V8 환경에서 프로그래머가 직접 가비지 컬렉션(GC)을 통제하거나 개입하는 것은 불가능하게 설계되어 있으나(`ECMAScript` 사양에 GC 제어 인터페이스가 없음), `--expose-gc`와 같은 특수 커맨드라인 플래그나 크롬 브라우저의 'Idle-time GC' 메커니즘을 이용하면 외부(Embedder)에서 유휴 시간을 이용해 수동으로 GC를 유도하는 것은 가능합니다 [46-48].
-
----
-*Last updated: 2026-04-19*
-- Raw Source: [[00_Raw/2026-04-20/V8 엔진 (V8 Engine).md]]
----
diff --git a/Programming & Language/V8 엔진 메모리 구조.md b/Programming & Language/V8 엔진 메모리 구조.md
deleted file mode 100644
index bd6193cc..00000000
--- a/Programming & Language/V8 엔진 메모리 구조.md	
+++ /dev/null
@@ -1,30 +0,0 @@
----
-id: P-REINFORCE-AUTO-3C3331
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - V8 엔진 메모리 구조"
----
-
-# [[V8 엔진 메모리 구조]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> V8 엔진의 메모리 구조는 실행 중인 프로그램에 할당되는 상주 집합(Resident Set)을 기반으로 하며, 크게 정적 데이터를 다루는 스택(Stack) 영역과 동적 데이터를 관리하는 힙(Heap) 영역으로 나뉜다 [1, 2]. 힙 메모리는 가비지 컬렉터(GC)가 객체의 생명주기와 특성에 맞춰 효율적으로 메모리를 회수할 수 있도록 세대별 가설(Generational hypothesis)에 기반하여 여러 공간(Space)으로 세분화된다 [3-5]. 최신 아키텍처에서는 메모리 단편화 방지와 보안 강화를 위해 오프힙 존(Zone) 메모리 활용, 512KB로 축소된 페이지(Page) 단위 관리, 그리고 4GB 제한을 가지는 포인터 압축(Pointer Compression) 및 메모리 케이지(Memory Cage) 기술이 적용되어 있다 [4, 6-8].
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[가비지 컬렉터(Garbage Collection)]], [[포인터 압축(Pointer Compression)]], [[세대별 가설(Generational Hypothesis)]]
-- **Projects/Contexts:** [[Node.js 및 웹 브라우저 런타임 최적화]], [[V8 보안 및 샌드박싱 모델(Memory Cage)]]
-- **Contradictions/Notes:** 소스에 관련 정보가 부족합니다. (특별한 모순점은 없으나, V8의 힙 페이지 크기가 기기와 버전에 따라 1MB에서 512KB로 유동적으로 최적화되었다는 변화 기록만 존재합니다 [4, 24, 25].)
-
----
-*Last updated: 2026-04-19*
-- Raw Source: [[00_Raw/2026-04-20/V8 엔진 메모리 구조.md]]
----
diff --git a/Programming & Language/V8 엔진 힙 아키텍처 및 로그 분석.md b/Programming & Language/V8 엔진 힙 아키텍처 및 로그 분석.md
deleted file mode 100644
index b7b86736..00000000
--- a/Programming & Language/V8 엔진 힙 아키텍처 및 로그 분석.md	
+++ /dev/null
@@ -1,45 +0,0 @@
----
-id: P-REINFORCE-AUTO-18F9C4
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - V8 엔진 힙 아키텍처 및 로그 분석"
----
-
-# [[V8 엔진 힙 아키텍처 및 로그 분석]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> V8 엔진 힙 아키텍처는 효율적인 메모리 할당과 빠른 가비지 컬렉션(GC)을 위해 물리적 메모리를 세대와 용도별 여러 공간으로 세분화하여 관리하는 구조입니다. 이 시스템은 대부분의 객체가 짧은 시간 안에 소멸한다는 '세대 가설(Generational hypothesis)'을 바탕으로 설계되어 젊은 세대와 오래된 세대에 각각 다른 알고리즘을 적용합니다. 런타임 로그 분석은 `--trace-gc` 등의 플래그를 활용해 메모리 할당 실패 원인, 수집에 소요된 시간, 힙의 생존 객체 크기 변화를 추적함으로써 메모리 누수와 성능 병목을 진단하는 핵심 기술입니다.
-
-## 📖 구조화된 지식 (Synthesized Content)
-**V8 힙 메모리 구조 (Heap Organization)**
-* **Resident Set 분할:** V8 프로세스가 할당받은 메모리는 주로 정적 데이터와 실행 프레임을 담는 스택(Stack) 공간과, 동적 객체가 저장되며 가비지 컬렉션의 대상이 되는 힙(Heap) 공간으로 나뉩니다 [1-3].
-* **New Space (Young Generation):** 새로 생성된 객체들이 할당되는 작고 빠른 공간입니다. 이 공간은 크기가 1~64MB 정도로 작으며, 내부적으로 'From-Space'와 'To-Space'라는 두 개의 동일한 크기의 반공간(semi-space)으로 나뉘어 Scavenger 알고리즘에 의해 관리됩니다 [4-7].
-* **Old Space (Old Generation):** New Space에서 두 번의 GC를 거치고도 살아남은 객체들이 승격(Promotion)되어 이동하는 공간입니다. 이 공간은 다른 객체를 참조하는 포인터를 가진 'Old Pointer Space'와 문자열 등 순수 데이터만 가진 'Old Data Space'로 세분화되어 마크-스윕-컴팩트(Mark-Sweep-Compact) 알고리즘으로 관리됩니다 [4, 7-9].
-* **특수 공간:** 여타 공간의 한계를 초과하는 큰 객체를 위해 메모리를 직접 mmap하는 'Large Object Space', JIT 컴파일된 머신 코드를 저장하는 'Code Space', 그리고 크기가 일정한 내부 구조체(Map, Cell)를 담는 전용 공간들이 존재합니다 [4, 7, 8].
-* **페이지와 샌드박싱:** 각 공간은 연속된 메모리 청크인 페이지(Page)로 구성됩니다. 기본 1MB 단위였으나 저메모리 기기 최적화를 위해 512KB로 축소되기도 하였습니다 [10-13]. 최신 64비트 V8은 포인터 압축(Pointer Compression) 기법을 적용하여 힙 전체를 4GB로 제한된 연속된 '케이지(Cage)' 영역 안에 가두어 관리합니다 [14-16].
-
-**가비지 컬렉션(GC) 메커니즘**
-* **마이너 GC (Scavenge):** New Space의 할당 포인터가 한계에 달하면(Allocation failure) 트리거됩니다. Cheney 알고리즘을 사용해 활성 객체만 'To-Space' 또는 Old Space로 복사하고, 이전 공간을 통째로 비움으로써 파편화를 없앱니다 [5, 17-19].
-* **메이저 GC:** Old Space의 객체를 수집합니다. 힙 전체에서 활성 객체를 식별(Mark)하고, 접근 불가 객체를 해제(Sweep)하며, 남은 메모리의 파편화를 줄이기 위해 활성 객체들을 한 곳으로 모읍니다(Compact) [20-23].
-* **오리노코(Orinoco) 프로젝트:** 메인 스레드가 정지되는 'Stop-the-world' 시간을 최소화하기 위해 병렬(Parallel), 점진적(Incremental), 동시(Concurrent) 스레드 기법을 결합하여 GC 작업을 백그라운드로 분산시킵니다 [24-27].
-
-**로그 분석 (Log Analysis)**
-* **--trace-gc 로깅 분석:** `PID, Isolate, Timestamp ms: Type Used (Total) -> Used (Total) MB, Duration ms, Reason` 형식으로 로그가 출력됩니다. 여기서 Reason 항목이 'allocation failure'인 경우 새로운 객체를 담을 메모리 공간이 부족하여 GC가 강제 실행되었음을 의미하며, 소요 시간(Duration) 지표를 통해 메인 스레드 멈춤 길이를 파악할 수 있습니다 [28-31].
-* **세부 로그 (--trace-gc-verbose / --trace-gc-nvp):** 각 힙 공간(New, Old, Large Object 등)의 사용량과 시스템에 커밋된 양을 분리하여 상세히 보여줍니다. 만약 메이저 GC 이후에도 Old space의 Used 영역이 점진적으로 계속 증가한다면 전형적인 메모리 누수 증상으로 판단합니다 [30, 32].
-* **프로파일링 도구 연계:** `--heap-prof` 플래그나 크롬 DevTools의 Allocation Timeline을 활용해 주기적인 힙 스냅샷을 찍고 분석할 수 있습니다. 할당 후 수집되지 않아 파란색으로 남은 타임라인 막대나, DevTools의 'Retainers' 패널을 역추적함으로써 어떤 루트 객체가 해제되어야 할 메모리를 쥐고 있는지(Retaining Paths) 정확히 파악 가능합니다 [33-36].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[세대 가설(Generational Hypothesis)]], [[Scavenger(마이너 GC)]], [[Mark-Sweep-Compact(메이저 GC)]], [[오리노코(Orinoco) 프로젝트]], [[포인터 압축(Pointer Compression)]]
-- **Projects/Contexts:** [[Node.js 프로덕션 메모리 누수 진단]], [[Chrome 렌더러 프로세스 V8 샌드박스 보안]]
-- **Contradictions/Notes:** 소스 [37-56]에서는 gencon, balanced 등 IBM Eclipse OpenJ9의 GC 정책에 대한 내용을 깊이 다루고 있으나, 이는 V8 엔진 고유의 구조가 아니므로 본 V8 아키텍처 중심 분석에서는 배제하였습니다.
-
----
-*Last updated: 2026-04-19*
-- Raw Source: [[00_Raw/2026-04-20/V8 엔진 힙 아키텍처 및 로그 분석.md]]
----
diff --git a/Programming & Language/V8 엔진 힙 아키텍처(V8 Engine Heap Architecture).md b/Programming & Language/V8 엔진 힙 아키텍처(V8 Engine Heap Architecture).md
deleted file mode 100644
index 85712998..00000000
--- a/Programming & Language/V8 엔진 힙 아키텍처(V8 Engine Heap Architecture).md	
+++ /dev/null
@@ -1,30 +0,0 @@
----
-id: P-REINFORCE-AUTO-FEC38C
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - V8 엔진 힙 아키텍처(V8 Engine Heap Architecture)"
----
-
-# [[V8 엔진 힙 아키텍처(V8 Engine Heap Architecture)]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> V8 엔진의 힙 아키텍처는 동적 데이터와 런타임에 크기 및 수명이 결정되는 객체들을 저장하고 관리하는 메모리 영역입니다 [1, 2]. V8은 대부분의 객체가 일찍 죽는다는 '세대적 가설(Generational Hypothesis)'을 바탕으로 힙을 여러 세대와 특수한 목적의 공간(Space)으로 분할하여 관리합니다 [3-5]. 이를 통해 할당 속도를 극대화하고 가비지 컬렉션(GC)의 오버헤드 및 지연 시간을 줄여 효율적인 메모리 회수와 프로그램 실행 성능을 보장합니다 [4, 6].
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[Generational Hypothesis]], [[Garbage Collection (Minor GC / Major GC)]], [[V8 Memory Cage]], [[Pointer Compression]]
-- **Projects/Contexts:** [[Node.js]], [[Chrome Browser]], [[Electron]], [[Deno]]
-- **Contradictions/Notes:** V8 힙의 페이지 크기는 전통적으로 1MB로 설명되지만, 소스에 따르면 저메모리 기기의 메모리 최적화와 메모리 파편화를 줄이기 위해 512KB로 크기가 축소되는 최적화가 적용되었습니다 [4, 17, 19, 20].
-
----
-*Last updated: 2026-04-19*
-- Raw Source: [[00_Raw/2026-04-20/V8 엔진 힙 아키텍처(V8 Engine Heap Architecture).md]]
----
diff --git a/Programming & Language/V8 엔진 힙 아키텍처.md b/Programming & Language/V8 엔진 힙 아키텍처.md
deleted file mode 100644
index 3ac524dc..00000000
--- a/Programming & Language/V8 엔진 힙 아키텍처.md	
+++ /dev/null
@@ -1,47 +0,0 @@
----
-id: P-REINFORCE-AUTO-221751
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - V8 엔진 힙 아키텍처"
----
-
-# [[V8 엔진 힙 아키텍처]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> V8 엔진의 힙 아키텍처는 런타임 시 크기나 수명을 미리 알 수 없는 동적 데이터와 자바스크립트 객체들을 저장하고 관리하기 위해 구성된 메모리 구조입니다 [1-3]. 효율적인 가비지 컬렉션을 위해 대부분의 객체가 생성 직후 죽는다는 '세대적 가설(Generational Hypothesis)'을 기반으로 설계되었습니다 [4-6]. 이를 위해 힙은 객체의 수명과 특성에 따라 여러 개의 특수 공간(Space)으로 나뉘며, 각 공간은 페이지(Pages) 단위로 나뉘어 메모리 할당 및 회수에 최적화된 고유의 방식으로 관리됩니다 [7-10].
-
-## 📖 구조화된 지식 (Synthesized Content)
-*   **세대적 힙 분할 (Generational Heap Layout):**
-    *   **New-space (Young Generation):** 대부분의 새로운 객체가 처음 할당되는 작고 빠른 공간입니다 [4, 7, 9]. 내부적으로 크기가 동일한 두 개의 반공간(To-Space, From-Space)으로 나뉘며, 스캐빈저(Scavenger)라 불리는 마이너 가비지 컬렉터(Minor GC)에 의해 관리됩니다 [11-14].
-    *   **Old-space (Old Generation):** New-space에서 두 번의 가비지 컬렉션 주기 동안 살아남은 객체들이 승격(Promote)되어 이동하는 공간입니다 [4, 12, 15]. 가비지 컬렉션 시 포인터 추적(Tracing) 단계를 최적화하기 위해, 다른 객체에 대한 포인터를 포함하는 **Old-pointer-space**와 문자열이나 박싱된 숫자처럼 포인터가 없는 순수 데이터만 포함하는 **Old-data-space**로 세분화됩니다 [7, 9, 15]. 이곳은 메이저 가비지 컬렉터(Mark-Sweep-Compact)가 관리합니다 [4, 9, 16].
-
-*   **특수 목적 공간 (Specialized Spaces):**
-    *   **Large-object-space:** 다른 공간의 크기 제한(일반적으로 1MB 이상)을 초과하는 큰 객체가 저장되는 공간입니다 [7, 9]. 각 객체는 운영체제로부터 별도의 mmap 영역을 할당받으며, 가비지 컬렉터에 의해 위치가 이동되지 않습니다 [7, 9].
-    *   **Code-space:** JIT 컴파일러에 의해 생성된 실행 가능한 기계어 명령어 코드가 저장되는 유일한 실행 가능 메모리 영역입니다 [7, 9].
-    *   **Map, Cell, Property-cell Space:** 모두 같은 크기를 가지며 가리키는 객체 종류에 제약이 있는 특정 내부 객체들을 저장하여 메모리 수집을 단순화하는 공간입니다 [7, 9].
-    *   **Read Only Space:** 영구적이며 절대 이동하거나 변하지 않는 불변(immutable) 객체들을 저장합니다 [17].
-
-*   **페이지 및 물리적 메모리 관리 (Pages & Memory Management):**
-    *   각 힙 공간은 '페이지(Pages)'라는 연속된 메모리 청크의 집합으로 구성됩니다 [5, 8, 10].
-    *   페이지는 전통적으로 1MB 크기에 1MB로 정렬되어 있었으나, 저메모리 기기 최적화 및 파편화 감소를 위해 512KB 크기로 축소되는 최적화가 적용되었습니다 [5, 8, 10, 18].
-    *   각 페이지에는 메타데이터와 마킹 비트맵이 있는 헤더가 포함되며, 다른 페이지의 객체를 가리키는 포인터 위치를 추적하기 위한 슬롯 버퍼(기억 집합, Remembered Set)가 존재합니다 [8, 10, 19].
-
-*   **포인터 압축과 메모리 케이지 (Pointer Compression & V8 Memory Cage):**
-    *   64비트 시스템에서 메모리 사용량을 줄이고 보안을 강화하기 위해, V8은 모든 힙 객체를 4GB 크기의 연속적인 '메모리 케이지(Memory Cage)' 구역 내에 가둡니다 [20-22].
-    *   객체의 포인터는 완전한 64비트 주소가 아닌 케이지의 기본 주소(Base Address)로부터의 32비트 오프셋으로 압축되어 저장됩니다 [21, 22]. 이로 인해 힙 메모리는 물리적 RAM의 크기와 무관하게 4GB의 엄격한 상한선을 가집니다 [20, 21].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[가비지 컬렉션(Garbage Collection)]], [[세대적 가설(Generational Hypothesis)]], [[스캐빈저(Scavenger)]], [[Mark-Sweep-Compact]], [[포인터 압축(Pointer Compression)]]
-- **Projects/Contexts:** [[Node.js 성능 최적화]], [[Google Chrome 브라우저 메모리 관리]], [[Orinoco 가비지 컬렉터]]
-- **Contradictions/Notes:** V8은 일반적으로 1MB 단위의 페이지 크기를 사용해 왔으나, 최신 최적화 동향에 따라 메모리 단편화를 줄이고 병렬 압축(Compaction) 효율을 높이기 위해 페이지 크기를 512KB로 축소 조정하는 방식을 병행하여 사용합니다 [5, 8, 18].
-
----
-*Last updated: 2026-04-19*
-- Raw Source: [[00_Raw/2026-04-20/V8 엔진 힙 아키텍처.md]]
----
diff --git a/Programming & Language/V8 엔진(V8 Engine).md b/Programming & Language/V8 엔진(V8 Engine).md
deleted file mode 100644
index 9143aca6..00000000
--- a/Programming & Language/V8 엔진(V8 Engine).md	
+++ /dev/null
@@ -1,35 +0,0 @@
----
-id: P-REINFORCE-AUTO-F107AC
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - V8 엔진(V8 Engine)"
----
-
-# [[V8 엔진(V8 Engine)]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-- **메모리 구조 (Memory Structure)**: V8의 프로세스 메모리(Resident Set)는 주로 정적 데이터(메서드 프레임, 원시 값, 객체 포인터)를 저장하는 스택(Stack)과 동적 데이터를 저장하는 힙(Heap)으로 나뉩니다 [2, 5, 6]. 힙 메모리는 객체의 생존 기간과 데이터 특성에 따라 '새로운 공간(New Space)', '오래된 공간(Old Pointer/Data Space)', '대형 객체 공간(Large Object Space)', '코드 공간(Code Space)' 등 다양한 세부 영역(Space)으로 나뉘어 독립적으로 관리됩니다 [7-9].
-- **오리노코(Orinoco) 가비지 컬렉션**: V8은 '오리노코(Orinoco)'라는 프로젝트를 통해 병렬(Parallel), 증분(Incremental), 동시성(Concurrent) 기법을 GC에 도입하여 애플리케이션의 메인 스레드 중단 시간(Stop-the-world)을 대폭 줄였습니다 [10-13].
-  - *Minor GC (Scavenger)*: '새로운 공간'에서 단명하는 객체들을 빠르게 수집합니다 [14, 15]. 두 개의 반공간(To-Space, From-Space)을 분리하여 사용하는 방식을 통해, 살아남은 객체만을 새 공간으로 복사 및 압축하고 2번의 사이클을 버틴 객체는 '오래된 공간'으로 승격(Promote)시킵니다 [15-17].
-  - *Major GC (Mark-Sweep-Compact)*: '오래된 공간'을 관리하며, 루트에서 도달 가능한 객체를 탐색하여 색칠하는 마킹(Marking), 죽은 객체의 메모리를 해제하여 빈 공간(Free-list)에 추가하는 스위핑(Sweeping), 파편화를 줄이기 위해 살아있는 객체를 모으는 압축(Compacting) 단계를 수행합니다 [18-23].
-- **포인터 식별 및 압축 (Tagged Pointers & Pointer Compression)**: V8은 하위 비트를 이용해 메모리 내에서 데이터(예: Smi라 불리는 작은 정수)와 포인터를 빠르게 구분하는 '태그된 포인터' 방식을 사용합니다 [24-26]. 또한, 64비트 플랫폼에서 메모리를 절약하기 위해 포인터를 32비트 오프셋으로 압축 저장하며, 이 정책으로 인해 V8 힙은 최대 4GB의 제한된 "메모리 케이지(Memory Cage)" 영역 내에 위치하게 됩니다 [27-30].
-- **성능 프로파일링 및 누수 탐지**: 개발자는 `--trace-gc` 플래그, 힙 스냅샷(Heap Snapshots), 크롬 개발자 도구의 할당 타임라인(Allocation Timeline) 등을 활용해 엔진 내부의 메모리 증감 추이를 확인하고, 메모리 누수 및 퍼포먼스 저하의 근본 원인을 추적할 수 있습니다 [31-34].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[Garbage Collection (GC)]], [[Orinoco]], [[Generational Hypothesis]], [[Pointer Compression]], [[Heap Space]]
-- **Projects/Contexts:** [[Google Chrome]], [[Node.js]], [[Electron]], [[Deno]]
-- **Contradictions/Notes:** 과거의 V8 스캐빈저(Scavenger)는 단일 스레드 기반의 Cheney 알고리즘을 사용했으나, 최신 버전에서는 멀티코어 환경에 맞춰 Halstead 방식과 유사한 동적 작업 훔치기(Work stealing) 기반의 병렬 스캐빈저를 도입하여 성능을 개선한 변화가 존재합니다 [35, 36].
-
----
-*Last updated: 2026-04-19*
-- Raw Source: [[00_Raw/2026-04-20/V8 엔진(V8 Engine).md]]
----
diff --git a/Programming & Language/V8 엔진의 메모리 관리 아키텍처 및 Orinoco 프로젝트.md b/Programming & Language/V8 엔진의 메모리 관리 아키텍처 및 Orinoco 프로젝트.md
deleted file mode 100644
index bc3973c3..00000000
--- a/Programming & Language/V8 엔진의 메모리 관리 아키텍처 및 Orinoco 프로젝트.md	
+++ /dev/null
@@ -1,47 +0,0 @@
----
-id: P-REINFORCE-AUTO-C4468D
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - V8 엔진의 메모리 관리 아키텍처 및 Orinoco 프로젝트"
----
-
-# [[V8 엔진의 메모리 관리 아키텍처 및 Orinoco 프로젝트]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> V8 엔진의 메모리 관리 아키텍처는 객체의 예상 수명에 따라 메모리 공간을 분할하는 세대별 힙(Generational Heap) 모델을 기반으로 설계되었습니다. 이를 통해 수명이 짧은 객체와 긴 객체에 각각 다른 알고리즘을 적용하여 가비지 컬렉션(GC)의 효율성을 극대화합니다. Orinoco 프로젝트는 V8의 가비지 컬렉터를 혁신하기 위한 이니셔티브로, 기존의 순차적이고 메인 스레드를 멈추게 하던(Stop-the-world) 방식에서 벗어나 병렬(Parallel), 동시성(Concurrent), 점진적(Incremental) 기법을 도입함으로써 애플리케이션의 응답성과 처리량을 크게 향상시켰습니다.
-
-## 📖 구조화된 지식 (Synthesized Content)
-**V8 엔진의 메모리 구조 (힙 아키텍처)**
-*   **메모리 분할:** V8은 동적 데이터를 저장하기 위해 힙(Heap) 메모리를 역할에 따라 여러 공간(Space)으로 엄격하게 나눕니다 [1-3].
-*   **New Space (초기 세대):** 대부분의 새로운 객체가 처음 할당되는 작고 빠른 공간입니다. 이 공간은 'To-Space'와 'From-Space'라는 크기가 같은 두 개의 반공간(Semi-space)으로 구성됩니다 [4-7].
-*   **Old Space (구 세대):** New Space에서 수행된 GC(Scavenge)에서 두 번 살아남은 수명이 긴 객체들이 승격(Promotion)되어 이동하는 공간입니다. 내부 포인터 유무에 따라 'Old Pointer Space'와 'Old Data Space'로 다시 세분화됩니다 [1, 3, 4, 8].
-*   **Large Object Space:** 다른 공간의 크기 제한(일반적으로 1MB 이상)을 초과하는 대형 객체가 저장되는 공간으로, 이곳의 객체들은 가비지 컬렉터에 의해 위치가 이동되지 않으며 운영체제로부터 직접 메모리가 매핑됩니다 [1, 3, 8].
-*   **기타 특수 공간:** JIT 컴파일된 머신 코드가 위치하는 실행 가능한 'Code Space' 및 균일한 크기의 내부 구조체를 저장하는 'Cell Space', 'PropertyCell Space', 'Map Space' 등이 있습니다 [1, 3, 8].
-*   **페이지 및 포인터 압축:** 힙 공간들은 연속된 메모리 청크인 '페이지(Page)' 집합으로 구성되며, 일반적으로 1MB 또는 메모리 최적화를 위해 512KB 크기로 정렬됩니다 [9-11]. 64비트 플랫폼에서 V8은 메모리를 절약하기 위해 포인터 압축(Pointer Compression) 기술을 사용하여 포인터를 32비트 오프셋으로 저장하며, 이로 인해 전체 힙 메모리는 4GB 크기의 'V8 Memory Cage(메모리 케이지)' 내에 국한됩니다 [12-14].
-
-**세대별 가비지 컬렉션 (Generational GC)**
-*   **Minor GC (Scavenger):** 생성된 대부분의 객체가 일찍 죽는다는 '세대별 가설(Generational Hypothesis)'을 기반으로 New Space를 관리합니다 [4, 10, 15]. 스캐빈저(Scavenger) 알고리즘을 사용하여 살아있는 객체만 From-Space에서 To-Space로 복사(Evacuation)하며, 이 과정을 통해 자연스럽게 메모리 단편화를 제거합니다 [5, 6, 16].
-*   **Major GC (Mark-Sweep-Compact):** 수십에서 수백 메가바이트에 달할 수 있는 Old Space를 관리합니다 [17-19]. 도달 가능한 객체를 식별하는 마킹(Mark), 죽은 객체의 메모리 영역을 해제하여 사용 가능한 빈 공간(Free-list)으로 등록하는 스위핑(Sweep), 그리고 메모리 파편화를 줄이기 위해 살아남은 객체들을 모으는 압축(Compact) 단계로 작동합니다 [17, 20-23].
-
-**Orinoco 프로젝트와 최신 가비지 컬렉션 최적화**
-Orinoco는 메인 스레드의 멈춤 시간(Pause time)을 줄이기 위해 최신 병렬 및 동시성 기술을 가비지 컬렉터에 통합한 V8의 프로젝트입니다 [24-26].
-*   **병렬 처리(Parallel):** 메인 스레드와 여러 헬퍼 스레드가 작업을 나누어 동시에 수행합니다. 젊은 세대의 스캐빈징(Scavenging)과 구 세대의 압축(Compaction) 작업 등에 병렬 처리가 적용되어 메인 스레드의 GC 소요 시간을 크게 줄였습니다 [27-30].
-*   **동시성 처리(Concurrent):** 메인 스레드가 JavaScript 코드를 중단 없이 실행하는 동안, 백그라운드의 헬퍼 스레드들이 Major GC의 마킹 및 스위핑 작업을 완전히 독립적으로 수행합니다 [27, 31-33].
-*   **점진적 마킹(Incremental Marking):** 한 번에 전체 힙을 마킹하는 대신, JavaScript 실행 중간중간에 짧은 시간(5-10ms) 단위로 쪼개어 마킹 작업을 수행함으로써 응용 프로그램의 응답성 저하를 방지합니다 [34-37].
-*   **지연 스위핑(Lazy Sweeping):** 마킹이 완료되어 확보할 수 있는 빈 메모리 크기를 파악한 후, 모든 페이지를 즉시 정리하지 않고 애플리케이션에서 메모리 할당이 필요해지는 시점까지 스위핑 작업을 지연시킵니다 [27, 38, 39].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[가비지 컬렉션(Garbage Collection)]], [[세대별 가설(Generational Hypothesis)]], [[포인터 압축(Pointer Compression)]], [[Mark-Sweep-Compact 알고리즘]], [[Scavenger 알고리즘]]
-- **Projects/Contexts:** [[V8 JavaScript 엔진]], [[Node.js 메모리 최적화]], [[Chrome 브라우저 렌더링 성능]]
-- **Contradictions/Notes:** 과거 버전의 V8에서는 단일 스레드 기반의 동기식 Cheney 알고리즘을 Scavenger에 사용했으나, 멀티 코어 환경이 보편화됨에 따라 Orinoco 프로젝트를 기점으로 동적 작업 훔치기(Dynamic work stealing) 방식을 활용하는 병렬 스캐빈저(Parallel Scavenger)로 진화했습니다 [30, 40].
-
----
-*Last updated: 2026-04-19*
-- Raw Source: [[00_Raw/2026-04-20/V8 엔진의 메모리 관리 아키텍처 및 Orinoco 프로젝트.md]]
----
diff --git a/Programming & Language/V8 자바스크립트 엔진.md b/Programming & Language/V8 자바스크립트 엔진.md
deleted file mode 100644
index 68af32cf..00000000
--- a/Programming & Language/V8 자바스크립트 엔진.md	
+++ /dev/null
@@ -1,46 +0,0 @@
----
-id: P-REINFORCE-AUTO-4AC7A0
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - V8 자바스크립트 엔진"
----
-
-# [[V8 자바스크립트 엔진]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-**메모리 구조 (Heap & Stack)**
-*   **스택(Stack):** 함수 호출 정보, 로컬 변수, 힙에 있는 객체를 가리키는 포인터, 원시 값(Primitive values) 등 정적 데이터를 저장하는 영역입니다 [3, 10, 11].
-*   **힙(Heap):** 크기나 수명을 런타임 이전에는 알 수 없는 동적 객체 데이터가 저장되는 가장 큰 메모리 영역입니다 [4, 12]. 가비지 컬렉션의 효율을 높이기 위해 여러 공간(Space)으로 나뉘어 관리됩니다 [13, 14].
-    *   **New Space (Young Generation):** 새롭게 생성된 짧은 수명의 객체가 할당되는 작은 공간입니다 [13, 14].
-    *   **Old Space (Old Generation):** New Space에서 특정 횟수 이상 살아남은 객체가 승격(Promoted)되어 저장되는 큰 공간입니다 [14, 15]. 내부적으로 다른 객체를 가리키는 포인터를 가진 'Old Pointer Space'와 데이터만 가진 'Old Data Space'로 나뉩니다 [13, 14].
-    *   **Large Object Space:** 다른 공간의 크기 제한(일반적으로 1MB 혹은 512KB 페이지 사이즈)을 초과하는 큰 객체가 저장되며, 가비지 컬렉터에 의해 위치가 이동되지 않습니다 [5, 13, 14].
-    *   **Code Space:** JIT 컴파일러가 생성한 실행 가능한 기계어 명령어 코드가 할당되는 공간입니다 [13, 14].
-
-**가비지 컬렉션 (Garbage Collection)**
-V8은 객체 대부분이 일찍 죽는다는 '세대별 가설(Generational hypothesis)'을 바탕으로 두 가지 가비지 컬렉션 알고리즘을 사용합니다 [5, 15, 16]. 
-*   **Scavenge (Minor GC):** New Space를 관리합니다 [14]. 공간을 To-Space와 From-Space로 나누어, 살아있는 객체만 새로운 공간으로 대피(Evacuation)시켜 단편화를 제거하고 나머지는 비우는 빠르고 빈번한 방식으로 동작합니다 [17-19].
-*   **Mark-Sweep-Compact (Major GC):** Old Space를 관리합니다 [20, 21]. 애플리케이션의 루트(전역 객체, 로컬 변수 등)에서부터 도달할 수 있는 객체를 식별(Mark)하고, 접근할 수 없는 객체의 메모리를 회수(Sweep)하며, 필요할 경우 메모리 단편화를 줄이기 위해 살아있는 객체들을 한곳으로 모으는 압축(Compact)을 수행합니다 [21-27].
-*   **Orinoco 프로젝트:** V8의 최신 가비지 컬렉터 구조로, 메인 스레드 실행이 멈추는 'Stop-the-world' 시간을 줄이기 위해 병렬(Parallel), 점진적(Incremental), 동시적(Concurrent) 처리 기법을 도입했습니다 [7, 9]. 이를 통해 자바스크립트 실행과 백그라운드 스레드에서의 메모리 회수 작업이 교차적으로 수행될 수 있습니다 [28-30].
-
-**메모리 최적화 및 보안 구조 (V8 Memory Cage)**
-*   **포인터 압축 (Pointer Compression):** 64비트 시스템에서 포인터를 64비트 전체 주소가 아닌, 예약된 공간(Cage) 시작점을 기준으로 한 32비트 오프셋으로 저장하여 메모리 사용량을 줄입니다 [6, 8, 31]. 이로 인해 V8 힙의 최대 크기는 4GB로 제한됩니다 [32, 33].
-*   **메모리 케이지 (Memory Cage / V8 Sandbox):** 모든 힙 내부의 포인터는 V8 힙 영역을 벗어날 수 없도록 설계되었습니다 [6, 33]. 이 아키텍처는 타입 혼란(Type confusion) 같은 엔진 내 JIT 버그를 악용해 힙 내의 포인터를 덮어씌워도, 공격자가 프로세스 내의 임의의 메모리를 읽거나 쓰는 것을 방지하는 강력한 보안 계층을 제공합니다 [6, 34, 35].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[가비지 컬렉션(Garbage Collection)]], [[Orinoco 가비지 컬렉터]], [[세대별 가설(Generational Hypothesis)]], [[포인터 압축(Pointer Compression)]], [[V8 메모리 케이지(Memory Cage)]]
-- **Projects/Contexts:** Node.js, Deno, Electron, Chrome 브라우저 등에서 핵심 자바스크립트 및 WebAssembly 실행 환경으로 채택되어 사용됩니다 [31, 36-39]. 애플리케이션의 메모리 누수 분석 및 성능 모니터링 시 V8의 `--trace-gc`, `--heap-prof` 등 다양한 런타임 플래그와 크롬 개발자 도구의 힙 스냅샷 기능을 주로 활용합니다 [40-43].
-- **Contradictions/Notes:** 자바스크립트는 언어 스펙상 가비지 컬렉터에 대해 프로그래머가 직접 제어할 수 있는 인터페이스를 제공하지 않는 것이 원칙이나 [44], Node.js 환경에서 구동되는 V8은 예외적으로 `--max-old-space-size` 및 `--expose-gc` (코드 내에서 `global.gc()` 호출 지원) 등의 커맨드라인 플래그를 통해 개발자가 직접 힙 크기를 튜닝하고 수동으로 컬렉션을 유도할 수 있도록 허용합니다 [45-47].
-
----
-*Last updated: 2026-04-19*
-- Raw Source: [[00_Raw/2026-04-20/V8 자바스크립트 엔진.md]]
----
diff --git a/Programming & Language/V8 힙 공간(V8 Heap Spaces).md b/Programming & Language/V8 힙 공간(V8 Heap Spaces).md
deleted file mode 100644
index 0a1a0b00..00000000
--- a/Programming & Language/V8 힙 공간(V8 Heap Spaces).md	
+++ /dev/null
@@ -1,54 +0,0 @@
----
-id: P-REINFORCE-AUTO-438240
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - V8 힙 공간(V8 Heap Spaces)"
----
-
-# [[V8 힙 공간(V8 Heap Spaces)]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> V8 엔진은 동적으로 할당되는 데이터와 객체를 저장하기 위해 힙(Heap) 메모리를 사용하며, 효율적인 메모리 관리를 위해 이를 여러 개의 특화된 공간(Space)으로 나눕니다 [1, 2]. 객체의 예상 수명과 크기, 내부 포인터의 유무에 따라 신규 공간(New Space), 올드 공간(Old Space), 대형 객체 공간(Large Object Space) 등으로 분리됩니다 [2-4]. 이러한 공간 분할은 가비지 컬렉터(GC)가 각 메모리 영역의 특성에 맞는 최적화된 수집 알고리즘을 적용할 수 있게 하여 애플리케이션의 성능을 향상시킵니다 [2]. 또한 최신 V8에서는 보안과 성능을 위해 포인터 압축 기술을 사용하여 전체 힙 공간을 4GB 크기의 메모리 케이지(Memory Cage) 내에 제한합니다 [5, 6].
-
-## 📖 구조화된 지식 (Synthesized Content)
-V8 힙은 각기 다른 생명주기를 가진 객체를 관리하기 위해 여러 하위 공간으로 논리적으로 분할되며, 각 공간은 운영체제로부터 할당받은 '페이지(Page)'라는 연속된 메모리 청크의 집합으로 구성됩니다 [7-9]. V8 힙 공간의 주요 구성 요소는 다음과 같습니다:
-
-*   **신규 공간 (New Space / Young Generation)**
-    *   대부분의 새로운 객체가 최초로 할당되는 곳입니다 [2-4].
-    *   수명이 짧은 객체를 신속하게 수집하기 위해 설계되었으며, 크기가 작습니다(휴리스틱에 따라 일반적으로 1~8MB 또는 최대 64MB) [4, 10-12].
-    *   할당 및 가비지 컬렉션을 위해 내부적으로 크기가 동일한 `to-space`와 `from-space`라는 두 개의 반공간(semi-space)으로 나뉩니다 [4, 11, 13, 14].
-    *   이 공간은 스캐빈저(Scavenger)를 통한 마이너 가비지 컬렉션(Minor GC)에 의해 독립적으로 매우 빠르게 관리됩니다 [2-4, 10].
-
-*   **올드 공간 (Old Space / Old Generation)**
-    *   신규 공간에서 두 번의 마이너 GC를 거치고 생존한 장기 생존 객체들이 승격(Promote)되어 이동하는 공간입니다 [4, 10, 15].
-    *   메이저 가비지 컬렉션(Mark-Sweep-Compact) 알고리즘의 대상이 되며, 효율적인 관리를 위해 다시 두 가지로 세분화됩니다 [4, 10, 16].
-        1.  **올드 포인터 공간 (Old Pointer Space):** 다른 객체를 가리키는 내부 포인터를 포함하는 객체들이 저장됩니다 [2-4].
-        2.  **올드 데이터 공간 (Old Data Space):** 문자열, 박싱된 숫자(boxed numbers), 포인터가 없는 배열 등 원시 데이터만 포함하는 객체들이 저장됩니다 [2-4]. GC가 이 공간을 처리할 때는 포인터 추적(tracing) 단계를 건너뛸 수 있어 작업 속도를 최적화할 수 있습니다 [2, 17].
-
-*   **대형 객체 공간 (Large Object Space)**
-    *   다른 공간들의 크기 제한을 초과하는 거대한 객체들이 저장되는 공간입니다 [2-4].
-    *   대형 객체는 복사 비용이 매우 높기 때문에 가비지 컬렉터에 의해 위치가 이동(moved)되지 않으며, 각 객체는 운영체제로부터 직접 `mmap`된 고유의 메모리 영역을 할당받습니다 [2-4, 18].
-
-*   **코드 공간 (Code Space)**
-    *   JIT(Just-In-Time) 컴파일러에 의해 생성된 실행 가능한 머신 코드 명령어들이 저장되는 공간입니다 [2-4].
-    *   힙 내에서 실행 가능한 메모리 권한을 가지는 유일한 영역입니다 (다만 대형 객체 공간에 할당된 코드 역시 실행 가능할 수 있습니다) [2-4].
-
-*   **특수 및 기타 공간**
-    *   **셀, 속성 셀, 맵 공간 (Cell, Property-cell, Map Spaces):** 내부 구조체인 Cell, PropertyCell, Map 객체들을 저장하며, 이 공간의 객체들은 크기가 모두 동일하고 포인터 유형에 제약이 있어 컬렉션을 단순화합니다 [2-4].
-    *   **읽기 전용 공간 (Read Only Space):** 영구적이고 이동 불가능하며 변경되지 않는(immortal, immovable, immutable) 객체들을 저장합니다 [18].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[가비지 컬렉션(Garbage Collection)]], [[스캐빈저(Scavenger)]], [[마크-스위프-컴팩트(Mark-Sweep-Compact)]]
-- **Projects/Contexts:** [[Orinoco 프로젝트]], [[V8 메모리 케이지(V8 Memory Cage)]]
-- **Contradictions/Notes:** 전통적으로 V8 힙을 구성하는 단위인 각 '페이지(Page)'의 크기는 1MB였으나, 최근 저사양 모바일 기기를 위한 메모리 절감 및 파편화 감소 최적화의 일환으로 512KB 크기의 페이지로 축소 변경되기도 하였습니다 [7, 8, 19, 20]. 
-
----
-*Last updated: 2026-04-19*
-- Raw Source: [[00_Raw/2026-04-20/V8 힙 공간(V8 Heap Spaces).md]]
----
diff --git a/Programming & Language/V8 힙(Heap).md b/Programming & Language/V8 힙(Heap).md
deleted file mode 100644
index e5b30dba..00000000
--- a/Programming & Language/V8 힙(Heap).md	
+++ /dev/null
@@ -1,45 +0,0 @@
----
-id: P-REINFORCE-AUTO-326FC1
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - V8 힙(Heap)"
----
-
-# [[V8 힙(Heap)]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> V8 힙(Heap)은 자바스크립트 프로그램 실행 시 동적 데이터와 컴파일 타임에 크기나 수명 등을 결정할 수 없는 객체들이 저장되는 메모리 영역입니다 [1, 2]. 이 메모리 공간은 수동으로 관리할 필요 없이 V8 엔진의 가비지 컬렉터(Garbage Collector)에 의해 자동으로 재활용됩니다 [3, 4]. 효율적인 메모리 관리를 위해 V8은 객체의 예상 수명에 따라 힙을 '새로운 세대(Young Generation)'와 '오래된 세대(Old Generation)' 등 여러 특수한 공간(Space)으로 나누어 구성합니다 [5-7].
-
-## 📖 구조화된 지식 (Synthesized Content)
-**힙 메모리의 분할 구조 (Heap Organization)**
-V8 엔진은 "대부분의 객체는 일찍 죽는다"는 세대 가설(Generational Hypothesis)을 기반으로, 효율적인 가비지 컬렉션을 수행하기 위해 힙을 여러 특수한 공간으로 분할합니다 [5, 6, 8].
-*   **New Space (Young Generation):** 새로운 객체가 할당되는 매우 작고 빠른 영역입니다 [9, 10]. 크기는 보통 1~8MB 혹은 최대 64MB 정도이며, Scavenger(Minor GC) 알고리즘에 의해 매우 빠르게 청소됩니다 [2, 5, 11]. 내부적으로는 메모리를 절반으로 나눈 'To-Space'와 'From-Space' 반공간(semi-space)으로 구성되어 생존한 객체를 대피(evacuate)시키는 방식으로 단편화를 없앱니다 [11-14].
-*   **Old Space (Old Generation):** New Space에서 여러 번의 가비지 컬렉션 주기(주로 2회)를 살아남은 객체들이 승격(Promotion)되어 이동하는 공간입니다 [5, 7, 10, 15]. 공간이 매우 크기 때문에 Major GC(Mark-Sweep-Compact 알고리즘)에 의해 덜 빈번하게 관리됩니다 [5, 10, 16, 17]. 최적화를 위해 다른 객체를 참조하는 포인터를 가진 'Old-pointer-space'와 순수 데이터만 있는 'Old-data-space'로 세분화됩니다 [2, 9, 18].
-*   **Large Object Space:** 다른 공간의 크기 제한을 초과하는 대용량 객체가 저장되며, 각각 운영체제로부터 별도의 mmap 영역을 할당받습니다 [2, 9, 18]. 이곳의 객체는 가비지 컬렉터에 의해 절대 이동되지 않습니다 [2, 9].
-*   **Code Space:** JIT 컴파일러가 생성한 실행 가능한 머신 코드 명령이 저장되는 유일한 공간입니다 [2, 9, 18].
-*   **기타 공간 (Map, Cell, Property-cell Space):** 크기가 동일하고 가리키는 객체의 제약이 있는 V8 내부 구조체(Map, Cell 등)들을 저장하여 가비지 컬렉션을 단순화하는 공간입니다 [2, 9, 18].
-
-**페이지(Pages)와 메모리 샌드박싱**
-*   각 힙 공간은 운영체제로부터 할당받은 연속된 메모리 청크인 '페이지(Pages)'의 집합으로 구성됩니다 [18-20]. 각 페이지는 전통적으로 1MB 크기였으나, 최근 저메모리 기기에서 메모리 단편화를 줄이고 컴팩션(Compaction) 효율을 높이기 위해 512KB로 줄어드는 최적화가 도입되었습니다 [18, 19, 21, 22].
-*   64비트 플랫폼에서 V8은 포인터 압축(Pointer Compression) 기술과 'V8 메모리 케이지(Memory Cage)'를 도입했습니다 [23-25]. 이로 인해 힙 내의 포인터는 32비트 오프셋으로 저장되어 메모리 사용량이 절감되지만, V8 힙 전체 크기가 최대 4GB로 제한됩니다 [25, 26].
-
-**힙 메모리 측정 및 성능 튜닝**
-*   Node.js 환경에서는 `process.memoryUsage()`를 통해 `heapTotal`(할당된 총 힙 크기)과 `heapUsed`(사용 중인 힙 크기)를 실시간으로 모니터링할 수 있습니다 [27].
-*   힙에 불필요한 참조가 남아 객체가 수거되지 않는 메모리 누수(Memory Leak) 문제는 Chrome DevTools의 Heap Snapshot이나 Allocation Timeline 기능을 사용해 객체 유지 경로(Retaining Path)를 추적함으로써 진단하고 해결할 수 있습니다 [28-32].
-*   사용자는 애플리케이션 특성에 맞게 `--max-old-space-size` 및 `--max-semi-space-size`와 같은 명령줄 플래그를 사용하여 힙의 주요 공간 크기를 수동으로 튜닝할 수 있습니다 [33, 34].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[가비지 컬렉션(Garbage Collection)]], [[세대 가설(Generational Hypothesis)]], [[포인터 압축(Pointer Compression)]], [[Scavenger(Minor GC)]], [[Mark-Sweep-Compact(Major GC)]]
-- **Projects/Contexts:** [[Node.js]], [[Google Chrome]], [[Orinoco(V8 GC 프로젝트)]]
-- **Contradictions/Notes:** 소스 간의 본질적 모순은 없으나, V8 엔진의 지속적인 진화로 인해 페이지 크기가 1MB에서 512KB로 변경되는 등 시간의 흐름과 메모리 한계에 따른 구조 최적화 변화가 소스에 혼재되어 나타납니다.
-
----
-*Last updated: 2026-04-19*
-- Raw Source: [[00_Raw/2026-04-20/V8 힙(Heap).md]]
----
diff --git a/Programming & Language/VR Sickness.md b/Programming & Language/VR Sickness.md
deleted file mode 100644
index 69aecec8..00000000
--- a/Programming & Language/VR Sickness.md	
+++ /dev/null
@@ -1,33 +0,0 @@
----
-id: P-REINFORCE-AUTO-7B9E16
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - VR Sickness"
----
-
-# [[VR Sickness]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> VR 멀미(VR Sickness, 또는 모션 병, 사이버 멀미)는 헤드마운트 디스플레이(HMD)를 비롯한 가상현실 기기를 사용할 때 발생하는 메스꺼움, 방향 감각 상실, 시각적 장애 등의 부작용을 의미합니다 [1], [2]. 이는 주로 시각적 경험과 신체적 전정 감각 간의 충돌로 인해 발생하며 [3], 사용자의 실재감(Presence)을 저해하고 작업 수행 능력과 즐거움을 크게 감소시키는 주요 요인입니다 [2].
-
-## 📖 구조화된 지식 (Synthesized Content)
-- **발생 원인:** VR 멀미의 가장 유력한 원인으로는 가상 세계와 현실 세계의 불일치에서 오는 **시각-전정 충돌(visual-vestibular conflict)**이 꼽힙니다 [3]. 시각적으로 인지되는 환경과 실제 신체적 감각이 일치하지 않을 때 감각 통합에 교란이 일어나며 발생합니다 [3]. 또한, HMD의 특성상 화면의 초점과 안구의 움직임이 어긋나는 **폭주-조절 불일치(vergence-accommodation conflicts)** 역시 안구 운동 증상 및 피로를 유발하는 핵심 원인입니다 [3].
-- **주요 증상 및 파급 효과:** 사용자는 메스꺼움, 방향 감각 상실, 시각적 장애 외에도 피로, 발한, 두통, 눈의 통증 및 복시 등을 겪을 수 있습니다 [2], [4], [5]. 이러한 증상들은 사용자가 가상 세계에 몰입하는 **실재감을 깨뜨리고**, 동기 부여와 즐거움을 떨어뜨리며 작업 수행 능력을 저하시킵니다 [2]. VR 멀미로 인한 실험 중단율(dropout rate)은 평균 약 15.6%에 달하며 [2], [6], 어떤 사용자는 VR을 종료한 후 최대 24시간 이후에 나타나는 지연된 증상(latent symptoms)을 경험하기도 합니다 [7].
-- **영향 요인:** **콘텐츠의 특성**(카메라 이동, 사용자 움직임, 시각적 복잡성 등)과 **기기의 특성**이 멀미 발생과 심각도에 중요한 역할을 합니다 [8], [9]. 특히 노출 시간은 증상 발생의 핵심 요소로, 장시간 노출될수록 심각한 증상을 보고할 확률이 높아집니다 [10]. 이와 함께 연령, HMD의 착용감, 자세 안정성, 개인의 멀미 감수성 등 **개인차(Individual differences)**도 중요한 영향을 미칩니다 [11].
-- **완화 전략:** 멀미 증상을 피하기 위해 자주 휴식을 취하거나, 짧고 반복적인 노출을 통해 VR 환경에 적응(습관화)하는 전략이 도움이 될 수 있습니다 [11]. 장시간 노출 전에 짧게 체험해 보는 것이 권장되며, 증상이 나타나면 즉시 사용을 중단하고 회복될 때까지 기다려야 합니다 [11], [12].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[Visual-Vestibular Conflict]], [[Vergence-Accommodation Conflict]], [[Presence]], [[Head-Mounted Displays (HMD)]]
-- **Projects/Contexts:** [[VR Exergaming]] (예: Beat Saber를 활용한 VR 노출 시간 및 후유증 연구 [13], [14])
-- **Contradictions/Notes:** 일반적으로 VR 노출 시간이 길어질수록 증상이 심해진다고 알려져 있으나, 한 연구 검토에서는 10~20분 노출된 경우보다 20분 이상 노출된 연구에서 평균적으로 덜 심각한 증상이 보고되기도 했습니다. 이는 노출 시간 자체의 문제라기보다는 각 연구에 사용된 VR 콘텐츠의 유형(예: 360도 비디오, 게임, 정적 풍경 등) 분포 차이로 인한 결과일 수 있습니다 [10].
-
----
-*Last updated: 2026-04-19*
-- Raw Source: [[00_Raw/2026-04-20/VR Sickness.md]]
----
diff --git a/Programming & Language/VR 멀미 (VR Sickness).md b/Programming & Language/VR 멀미 (VR Sickness).md
deleted file mode 100644
index a828899e..00000000
--- a/Programming & Language/VR 멀미 (VR Sickness).md	
+++ /dev/null
@@ -1,35 +0,0 @@
----
-id: P-REINFORCE-AUTO-BD2336
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - VR 멀미 (VR Sickness)"
----
-
-# [[VR 멀미 (VR Sickness)]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> VR 멀미(VR Sickness 또는 Cybersickness)는 헤드마운트 디스플레이(HMD)를 사용하는 가상현실(VR) 경험 중 다수의 사용자가 겪는 부정적인 상태로, 메스꺼움, 방향 감각 상실, 시각적 장애 등의 증상을 동반합니다 [1, 2]. 이러한 멀미 증상은 가상현실에서의 몰입감(presence), 동기 부여, 즐거움 및 과제 수행 능력을 저하시키며, 결과적으로 평균 15.6%의 높은 중도 포기율(dropout rate)을 초래하는 주요 원인이 됩니다 [2].
-
-## 📖 구조화된 지식 (Synthesized Content)
-- **발생 원인 및 이론:** VR 멀미의 정확한 병인에 대해서는 아직 학계의 완전한 합의가 이루어지지 않았으나, 가장 유력한 이론은 가상 세계와 현실 세계 간의 '감각 불일치(mismatch)' 현상입니다 [3, 4]. 특히 사용자의 시각적 경험과 신체적/전정 기관의 경험이 일치하지 않을 때 발생하는 시각-전정 갈등(visual-vestibular conflict)이 주요 원인으로 꼽힙니다 [3]. 또한, HMD 사용 시 발생하는 폭주-조절 갈등(vergence-accommodation conflicts)으로 인해 시각적 피로와 같은 안구 운동 관련 증상이 유발될 수 있습니다 [3].
-- **주요 증상:** VR 멀미의 증상은 크게 메스꺼움(nausea), 안구 운동 이상(oculomotor symptoms: 눈의 피로, 초점 맞추기 어려움 등), 방향 감각 상실(disorientation: 현기증, 어지러움) 등 3가지 범주로 나뉩니다 [5]. 신체 활동이 수반되는 VR 엑서게임(Exergame)을 플레이할 경우, 피로, 땀, 방향 감각 상실 등 고강도 유산소 운동에서 나타나는 증상과 VR 멀미 증상이 겹쳐 이 둘을 구별하기 어려울 수 있습니다 [6].
-- **영향을 미치는 요인:**
-  - **콘텐츠 및 기기:** 화면의 높은 시각적 움직임(visual motion), 장면의 복잡성, 이동 방식(locomotion) 및 몰입감 등은 멀미를 악화시키는 주요 요소이며, 기기와 콘텐츠 특성이 멀미의 발현 및 진행에 핵심적인 역할을 합니다 [7, 8].
-  - **개인차:** 사용자의 연령, HMD 착용 상태(fit), 자세 안정성, 그리고 사용자가 평소 가지고 있는 멀미에 대한 감수성(susceptibility) 등 개인의 특성도 멀미 발생 가능성에 상당한 영향을 미칩니다 [9].
-- **노출 시간 및 회복:** VR 노출 시간이 길어질수록 사용자는 더 심각한 멀미 증상을 보고하는 경향이 있습니다 [7, 10]. 사용 후 나타나는 후유증의 지속 시간은 짧게는 10분에서 길게는 4시간 이상까지 다양하며, 증상을 경험하는 사용자는 즉각 VR 사용을 중단하고 완전히 회복될 때까지 휴식을 취해야 합니다 [11]. 또한, 짧은 노출 시간만으로도 심한 멀미를 겪는 사용자는 긴 시간 노출될 경우 유사하거나 더 심각한 증상을 경험할 가능성이 매우 높습니다 [9, 12].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[시각-전정 갈등 (Visual-Vestibular Conflict)]], [[폭주-조절 갈등 (Vergence-Accommodation Conflict)]], [[몰입감 (Presence)]], [[헤드마운트 디스플레이 (HMD)]]
-- **Projects/Contexts:** [[VR 엑서게임 (VR Exergaming)]]
-- **Contradictions/Notes:** VR 멀미의 정확한 발병 원인(etiology)에 대해서는 학계 내에서 여전히 일치된 합의가 없습니다 [3, 4]. 덧붙여, VR 엑서게임 환경에서는 멀미 증상이 격렬한 신체 운동으로 인해 유발되는 자연스러운 신체 반응과 중복되기 때문에 정확한 멀미를 식별해 내는 것이 까다로울 수 있습니다 [6].
-
----
-*Last updated: 2026-04-19*
-- Raw Source: [[00_Raw/2026-04-20/VR 멀미 (VR Sickness).md]]
----
diff --git a/Programming & Language/VR 멀미(VR sickness).md b/Programming & Language/VR 멀미(VR sickness).md
deleted file mode 100644
index 1064d43f..00000000
--- a/Programming & Language/VR 멀미(VR sickness).md	
+++ /dev/null
@@ -1,42 +0,0 @@
----
-id: P-REINFORCE-AUTO-926D42
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - VR 멀미(VR sickness)"
----
-
-# [[VR 멀미(VR sickness)]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> VR 멀미(VR sickness)는 헤드 마운트 디스플레이(HMD) 사용 시 발생하는 부정적인 부작용으로, 주로 메스꺼움, 방향 감각 상실, 안구 피로 및 시각적 장애와 같은 증상으로 나타납니다 [1, 2]. 가상 세계의 시각적 경험과 실제 신체의 감각이 일치하지 않을 때 발생하는 시각-전정 감각의 충돌(visual-vestibular conflict)이 주요 원인으로 지목됩니다 [3]. 이러한 멀미 증상은 사용자의 몰입감(presence)을 떨어뜨리고, 게임이나 작업의 동기 부여와 즐거움을 감소시키며, 종국에는 수행 능력을 저하시키는 원인이 됩니다 [2].
-
-## 📖 구조화된 지식 (Synthesized Content)
-* **발생 원인 및 메커니즘:** 
-  VR 멀미의 명확한 발병 원인에 대한 완전한 합의는 없지만, 가상과 현실 간의 감각 불일치 이론이 가장 유력합니다 [3]. 뇌로 전달되는 시각적 감각과 신체적(전정) 감각이 충돌하면 감각 통합에 교란이 생겨 메스꺼움이나 방향 감각 상실을 유발합니다 [3]. 또한, HMD 환경에서 제공되는 깊이 단서의 충돌로 인해 발생하는 '폭주-조절 불일치(vergence-accommodation conflicts)' 역시 안구 운동 관련 증상(oculomotor symptoms)을 증가시킵니다 [3, 4].
-
-* **증상 및 측정:** 
-  멀미 증상은 크게 세 가지 범주, 즉 메스꺼움(위장 자극, 트림, 타액 분비 증가), 안구 운동 이상(눈의 피로, 초점 문제), 방향 감각 상실(현기증, 어지러움)로 나뉩니다 [5]. 이러한 증상들은 주로 시뮬레이터 멀미 설문지(SSQ)를 통해 측정되며, 증상이 심할 경우 약 15.6%의 평균 사용자 이탈률을 초래합니다 [2, 5]. 멀미 증상은 VR 종료 직후뿐만 아니라 최대 24시간 이후에 심각한 잠복 증상(latent symptoms)으로 나타날 수도 있습니다 [6].
-
-* **주요 영향 요인:**
-  * **노출 시간:** VR 노출 지속 시간은 후유증의 발생과 심각도에 결정적인 역할을 합니다 [7]. 연구에 따르면 10분의 짧은 노출보다 50분의 긴 노출 직후에 메스꺼움 등의 증상이 유의미하게 더 많이 보고되었습니다 [8].
-  * **콘텐츠 및 기기 특성:** 시각적 움직임의 강도, 장면의 복잡성, 이동 방식(locomotion) 등이 VR 멀미 발생에 직접적인 영향을 미칩니다 [9]. 모니터 기반 게임보다 HMD 착용 환경에서 더 높은 수준의 멀미가 유발되는 경향이 있습니다 [10].
-  * **개인차:** 연령, HMD의 착용 상태, 사용자의 자세 안정성, 멀미에 대한 개인적 민감성 등이 복합적으로 작용합니다 [11]. 특히, 짧은 시간의 노출에도 심한 증상을 겪는 사람은 긴 노출 시 훨씬 더 심각한 증상을 겪을 가능성이 높습니다 [11].
-
-* **완화 및 회복 전략:** 
-  VR 사용 후 후유증이 기저 수준으로 회복되는 데 걸리는 시간은 증상의 초기 심각도에 따라 다릅니다 [12]. 일반적인 경우, VR 노출 후 약 40분의 대기 시간을 가지면 증상이 정상 수준으로 돌아옵니다 [8, 13]. 멀미를 완화하기 위해서는 가상 세계의 시각적 움직임과 사용자의 실제 신체 움직임을 일치시키고, 장시간 사용 전 짧은 세션으로 테스트하거나 자주 휴식을 취하여 적응(habituation)을 유도하는 전략이 권장됩니다 [10, 11, 13].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[시각-전정 감각 충돌(Visual-Vestibular Conflict)]], [[폭주-조절 불일치(Vergence-Accommodation Conflict)]], [[시뮬레이터 멀미 설문지(SSQ)]], [[몰입감(Presence)]]
-- **Projects/Contexts:** [[비트 세이버(Beat Saber) 엑서게이밍 연구]] (10분 및 50분의 VR 노출이 사용자의 시각, 인지 및 자기 보고된 멀미 후유증에 미치는 영향을 조사한 연구 [14, 15]).
-- **Contradictions/Notes:** 고강도 신체 활동을 동반하는 VR 엑서게임(Exergame)을 수행할 경우, 피로, 방향 감각 상실, 땀 흘림, 메스꺼움 등 격렬한 유산소 운동으로 인한 생리적 증상과 VR 멀미 증상이 겹치게 됩니다. 이로 인해 운동 중 순수한 VR 멀미 증상만을 명확히 구분해 내는 데에는 어려움이 따릅니다 [16].
-
----
-*Last updated: 2026-04-19*
-- Raw Source: [[00_Raw/2026-04-20/VR 멀미(VR sickness).md]]
----
diff --git a/Programming & Language/Variable Ratio Reinforcement.md b/Programming & Language/Variable Ratio Reinforcement.md
deleted file mode 100644
index bfbc6e82..00000000
--- a/Programming & Language/Variable Ratio Reinforcement.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-1B19EF
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Variable Ratio Reinforcement"
----
-
-# [[Variable Ratio Reinforcement]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Variable Ratio Reinforcement.md]]
----
diff --git a/Programming & Language/Variance-Covariance-and-Contravariance.md b/Programming & Language/Variance-Covariance-and-Contravariance.md
deleted file mode 100644
index ceda6bf8..00000000
--- a/Programming & Language/Variance-Covariance-and-Contravariance.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-B7957E
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Variance-Covariance-and-Contravariance"
----
-
-# [[Variance-Covariance-and-Contravariance]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Variance-Covariance-and-Contravariance.md]]
----
diff --git a/Programming & Language/Variance-in-TypeScript.md b/Programming & Language/Variance-in-TypeScript.md
deleted file mode 100644
index e788c008..00000000
--- a/Programming & Language/Variance-in-TypeScript.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-E0D3BE
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Variance-in-TypeScript"
----
-
-# [[Variance-in-TypeScript]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Variance-in-TypeScript.md]]
----
diff --git a/Programming & Language/Vergence-Accommodation Conflicts.md b/Programming & Language/Vergence-Accommodation Conflicts.md
deleted file mode 100644
index bd4b19f1..00000000
--- a/Programming & Language/Vergence-Accommodation Conflicts.md	
+++ /dev/null
@@ -1,33 +0,0 @@
----
-id: P-REINFORCE-AUTO-122E42
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Vergence-Accommodation Conflicts"
----
-
-# [[Vergence-Accommodation Conflicts]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> Vergence-Accommodation Conflicts(양안 폭주-초점 조절 불일치)는 주로 헤드마운트 디스플레이(HMD) 사용 시 발생하는 현상으로, 자연스러운 시각 환경에서 피드백 루프를 통해 함께 작동하는 안구 운동 기능인 '양안 폭주(Vergence)'와 '초점 조절(Accommodation)'이 서로 분리될 때 발생합니다 [1, 2]. 이 충돌은 깊이 지각을 위한 망막 단서에 불확실성을 초래하여 두통, 눈의 통증, 피로, 복시 등의 안구 운동 증상을 유발할 수 있습니다 [1, 2]. 이러한 불일치가 가상현실(VR) 멀미를 유발하는 직접적인 원인인지, 아니면 단순히 멀미 증상을 악화시키는 요인인지는 아직 명확하게 밝혀지지 않았습니다 [3].
-
-## 📖 구조화된 지식 (Synthesized Content)
-- **자연스러운 시각 처리 메커니즘:** 양안 폭주(Vergence)와 초점 조절(Accommodation)은 인간이 깊이 단서를 정확하게 인지하고 사용하는 데 필수적인 안구 운동 기능입니다 [3]. 자연스러운 시청 환경에서 이 두 가지 기능은 피드백 루프 안에서 함께 작동하므로, 하나의 메커니즘이 변화하면 다른 메커니즘도 동시에 변화하게 됩니다 [2].
-- **HMD 환경에서의 불일치(Decoupling) 발생:** 가상현실(VR) 경험을 제공하는 헤드마운트 디스플레이(HMD)를 착용할 경우, 정상적으로 함께 작동해야 할 양안 폭주와 초점 조절 기능이 서로 분리(decoupled)되는 현상이 발생하며, 이를 Vergence-Accommodation Conflicts라고 부릅니다 [2].
-- **신체적 부작용 및 안구 운동 증상:** 이러한 시각적 불일치는 사용자의 깊이 지각(depth perception)과 관련된 망막 단서에 불확실성을 유발합니다 [2]. 결과적으로 사용자는 두통, 눈의 통증, 피로감, 그리고 사물이 두 개로 보이는 복시(double vision)와 같은 동반 증상을 겪게 되며, 전반적인 안구 운동 증상(oculomotor symptoms)이 증가하게 됩니다 [1, 2].
-- **VR 멀미(VR Sickness)와의 관계:** Vergence-Accommodation Conflicts가 심각한 시각적 불편함을 초래함에도 불구하고, 이것이 특정 개인에게 발생하는 VR 멀미의 직접적인 원인인지, 아니면 이미 발생한 멀미 증상의 심각성을 가중시키는(compounds) 역할만 하는 것인지는 아직 불분명합니다 [3].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[Oculomotor Functions]], [[Head-Mounted Displays (HMDs)]], [[VR Sickness]], [[Depth Perception]]
-- **Projects/Contexts:** [[Virtual Reality (VR) Exergaming]]
-- **Contradictions/Notes:** 소스에 따르면 Vergence-Accommodation Conflicts가 특정 사용자에게서 나타나는 VR 멀미(VR sickness)의 직접적인 발병 원인인지, 혹은 멀미 증상을 악화시키는 보조 요인인지에 대한 인과관계는 아직 명확하지 않다고 언급되어 있습니다 [3].
-
----
-*Last updated: 2026-04-19*
-- Raw Source: [[00_Raw/2026-04-20/Vergence-Accommodation Conflicts.md]]
----
diff --git a/Programming & Language/Web Worker와 SharedArrayBuffer를 이용한 실제 고부하 병렬 처리 구현체 (실패_성공 포함).md b/Programming & Language/Web Worker와 SharedArrayBuffer를 이용한 실제 고부하 병렬 처리 구현체 (실패_성공 포함).md
deleted file mode 100644
index dc41d369..00000000
--- a/Programming & Language/Web Worker와 SharedArrayBuffer를 이용한 실제 고부하 병렬 처리 구현체 (실패_성공 포함).md	
+++ /dev/null
@@ -1,30 +0,0 @@
----
-id: P-REINFORCE-AUTO-EBB42F
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Web Worker와 SharedArrayBuffer를 이용한 실제 고부하 병렬 처리 구현체 (실패_성공 포함)"
----
-
-# [[Web Worker와 SharedArrayBuffer를 이용한 실제 고부하 병렬 처리 구현체 (실패_성공 포함)]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 소스에 관련 정보가 부족합니다.
-
-## 📖 구조화된 지식 (Synthesized Content)
-소스에 관련 정보가 부족합니다.
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** 소스에 관련 정보가 부족합니다.
-- **Projects/Contexts:** 소스에 관련 정보가 부족합니다.
-- **Contradictions/Notes:** 소스에 관련 정보가 부족합니다.
-
----
-*Last updated: 2026-04-19*
-- Raw Source: [[00_Raw/2026-04-20/Web Worker와 SharedArrayBuffer를 이용한 실제 고부하 병렬 처리 구현체 (실패_성공 포함).md]]
----
diff --git a/Programming & Language/Web3 Infrastructure.md b/Programming & Language/Web3 Infrastructure.md
deleted file mode 100644
index 80a99d1c..00000000
--- a/Programming & Language/Web3 Infrastructure.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-7551CC
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Web3 Infrastructure"
----
-
-# [[Web3 Infrastructure]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Web3 Infrastructure.md]]
----
diff --git a/Programming & Language/WebKit Security Mitigations.md b/Programming & Language/WebKit Security Mitigations.md
deleted file mode 100644
index 2226442b..00000000
--- a/Programming & Language/WebKit Security Mitigations.md	
+++ /dev/null
@@ -1,37 +0,0 @@
----
-id: P-REINFORCE-AUTO-78AFAF
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - WebKit Security Mitigations"
----
-
-# [[WebKit Security Mitigations]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> WebKit Security Mitigations는 Spectre 및 Meltdown과 같은 CPU 추측 실행(Speculative Execution) 취약점으로부터 사용자를 보호하기 위해 WebKit 엔진에 도입된 보안 방어 전략입니다 [1], [2]. WebKit은 신뢰할 수 없는 JavaScript 코드를 실행해야 하므로 이러한 공격에 노출될 수 있으며, 이를 방지하기 위해 WebKit은 타이머 정밀도를 낮추고 분기 없는(Branchless) 보안 검사를 도입하는 두 가지 주요 방어 계층을 구축했습니다 [1], [3].
-
-## 📖 구조화된 지식 (Synthesized Content)
-*   **Spectre 및 Meltdown의 위협과 영향:** 
-    최신 CPU는 성능 향상을 위해 분기 예측(Branch Prediction) 및 추측 실행(Speculative Execution)을 사용합니다 [4], [2]. Spectre 공격은 이러한 추측 실행을 조작하여 공격자가 의도한 분기를 강제로 실행하게 만들고, CPU 캐시(L1)와 메인 메모리 간의 타이밍 차이를 이용해 민감한 메모리 정보를 유출합니다 [5], [6]. WebKit은 기존에 분기(Branch) 명령에 의존하여 JavaScript 및 WebAssembly의 보안을 적용해왔기 때문에, Spectre 취약점 하에서는 기존 보안 검사가 무력화됩니다 [7]. 또한, 브라우저를 통해 커널 메모리를 읽는 Meltdown 공격을 실행하려면 먼저 Spectre를 이용해 WebKit의 보안 속성을 우회해야 하므로, Spectre를 완화하는 것이 WebKit을 통한 Meltdown 공격을 차단하는 핵심이 됩니다 [7], [8].
-*   **타이머 정밀도 감소 (Reducing Timer Precision):** 
-    Spectre 공격이 성공하려면 메모리 접근 속도 차이를 미세하게 관찰할 수 있는 고정밀 타이밍 기술이 필수적입니다 [6]. 이를 방지하기 위해 WebKit은 `performance.now`를 비롯한 다양한 소스에서 제공하는 타이머의 정밀도를 1ms로 대폭 낮추었습니다 [9]. 추가로, 고해상도 타이머를 우회적으로 생성하는 데 악용될 수 있는 `SharedArrayBuffer` 기능 자체를 비활성화하여 타이밍 기반 정보 유출을 차단했습니다 [9].
-*   **분기 없는 보안 검사 (Branchless Security Checks):** 
-    공격자가 추측 실행 단계에서 분기를 제어할 수 있게 됨에 따라, WebKit은 분기 명령에 의존하지 않는 새로운 보안 검사 방식을 도입하기 시작했습니다 [9].
-    *   **인덱스 마스킹 (Index Masking):** 배열의 길이에 맞춘 비트 마스크를 사용하여 배열 인덱스를 안전한 범위 내로 강제하는 기법입니다 [10]. 최신 CPU는 비트 마스킹 작업에 대해서는 추측 실행을 수행하지 않기 때문에, Spectre 상황에서도 임의의 범위를 벗어난 아웃오브바운드(Out-of-Bounds) 메모리 읽기를 효과적으로 방지할 수 있습니다 [10]. 이 기법은 Typed 배열, WebAssembly 메모리, 문자열, 그리고 일반 JavaScript 배열 등에 폭넓게 적용되었습니다 [10].
-    *   **포인터 포이즈닝 (Pointer Poisoning):** 포인터 값에 복원 가능한 수학적 연산(XOR)을 수행하여 포인터를 '오염(Poisoning)'시키는 기법입니다 [11]. 올바른 타입 검사를 통과하여 정확한 값으로 포이즈닝을 해제(Unpoison)하지 않으면 매핑되지 않은 메모리 영역을 가리키게 되어 접근이 실패합니다 [11]. 이 방식은 분기 없는 타입 검사(Type Check)로 작동할 뿐만 아니라, 타입 혼동(Type Confusion)을 통한 원격 코드 실행(RCE) 공격을 방어하는 데도 유용한 방어 수단으로 활용됩니다 [12], [13].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[Spectre]], [[Meltdown]], [[Speculative Execution]], [[Branch Prediction]]
-- **Projects/Contexts:** [[JavaScriptCore]], [[WebAssembly]]
-- **Contradictions/Notes:** 제공된 소스 내에서 상충하는 주장이나 모순되는 정보는 발견되지 않았습니다.
-
----
-*Last updated: 2026-04-19*
-- Raw Source: [[00_Raw/2026-04-20/WebKit Security Mitigations.md]]
----
diff --git a/Programming & Language/WebKit.md b/Programming & Language/WebKit.md
deleted file mode 100644
index c025ac2a..00000000
--- a/Programming & Language/WebKit.md	
+++ /dev/null
@@ -1,36 +0,0 @@
----
-id: P-REINFORCE-AUTO-84FEA9
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - WebKit"
----
-
-# [[WebKit]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> WebKit은 최신 웹사이트를 렌더링하기 위해 사용자의 프로세서에서 신뢰할 수 없는 JavaScript 및 WebAssembly 코드를 실행하도록 설계된 웹 브라우저 엔진입니다 [1]. 기존에는 신뢰할 수 없는 코드의 작업을 제어하고 보안 속성을 강제하기 위해 분기(branch) 명령에 크게 의존했습니다 [2]. 그러나 Spectre와 Meltdown 같은 프로세서 취약점이 발견되면서 기존의 분기 기반 보안 검사가 무력화되었고, 이에 대응하기 위해 방어 체계의 대대적인 개편을 진행하게 되었습니다 [1, 2].
-
-## 📖 구조화된 지식 (Synthesized Content)
-- **보안 취약점 노출 (Spectre 및 Meltdown):** 
-  WebKit의 JavaScript 엔진인 JavaScriptCore는 본래 안전한 언어 가상 머신(VM)으로 기능해야 합니다 [3]. 하지만 Spectre 취약점은 CPU의 추측 실행(speculative execution)과 캐시 타이밍 차이를 악용해 공격자가 분기를 제어하게 만듭니다 [4, 5]. 이로 인해 WebKit의 경계 검사 및 유형 검사를 우회하여, 신뢰할 수 없는 JavaScript나 WebAssembly 코드가 호스트 프로세스의 주소 공간 전체를 읽을 수 있는 위험이 발생했습니다 [3, 6]. 또한 WebKit의 보안 속성이 Spectre를 통해 먼저 우회될 경우, 이를 시작점으로 삼아 커널 메모리를 읽는 Meltdown 공격까지 이어질 수 있습니다 [1, 2].
-
-- **2단계 방어(Two-Tiered Defense) 완화 전략:**
-  WebKit과 Blink는 이 문제에 대응하기 위해 두 가지 주요 단계로 구성된 보안 완화책을 전환 및 배포했습니다 [7, 8].
-  1. **타이머 정밀도 축소:** Spectre 공격은 L1 캐시와 메인 메모리 간의 지연 시간 차이를 관찰하기 위해 고정밀 타이밍을 필요로 합니다 [5]. 이를 방지하기 위해 WebKit은 `performance.now` 등의 타이머 정밀도를 1ms 단위로 축소(quantization/coarsening)하고, 고해상도 타이머를 생성하는 데 악용될 수 있는 `SharedArrayBuffer` 기능을 비활성화했습니다 [8-10].
-  2. **분기 없는 보안 검사(Branchless Security Checks) 도입:** 분기에 의존하는 보안 검사 방식에서 벗어나 인덱스 마스킹(Index masking)과 포인터 포이즈닝(Pointer poisoning) 기법을 새롭게 추가했습니다 [8-10]. 인덱스 마스킹은 임의 메모리에 대한 범위 외(out-of-bounds) 읽기를 제한하며, 포인터 포이즈닝은 정적 선언된 포인터 필드마다 고유한 포이즌 값을 할당하여 타입 혼동을 방지하는 분기 없는 유형 검사 역할을 합니다 [11, 12].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[Spectre]], [[Meltdown]], [[JavaScriptCore]], [[Speculative execution]]
-- **Projects/Contexts:** [[WebKit 취약점 완화(Security Mitigations)]]
-- **Contradictions/Notes:** 초기 도입된 인덱스 마스킹 기법은 길이를 다음 2의 거듭제곱으로 반올림해 마스크를 계산하는 방식을 사용하므로, 임의의 메모리 접근은 막지만 여전히 제한적인 범위 외(out-of-bounds) 읽기를 허용하는 한계가 존재합니다 [11].
-
----
-*Last updated: 2026-04-19*
-- Raw Source: [[00_Raw/2026-04-20/WebKit.md]]
----
diff --git a/Programming & Language/Write Barrier.md b/Programming & Language/Write Barrier.md
deleted file mode 100644
index c87ace90..00000000
--- a/Programming & Language/Write Barrier.md	
+++ /dev/null
@@ -1,32 +0,0 @@
----
-id: P-REINFORCE-AUTO-2240C5
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Write Barrier"
----
-
-# [[Write Barrier]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> Write Barrier(쓰기 장벽)는 가비지 컬렉션(GC) 시스템에서 객체에 새로운 포인터(참조)가 저장될 때마다 이를 감지하고 기록하기 위해 실행되는 짧은 코드 조각입니다 [1]. 주로 구 세대(Old-space) 객체가 신규 세대(New-space) 객체를 참조하는 것을 추적하거나, 점진적/동시성 마킹(Incremental/Concurrent marking) 중에 변경된 객체 그래프를 추적하는 데 필수적으로 사용됩니다 [1-3]. 이를 통해 가비지 컬렉터가 메모리 힙 전체를 무거운 비용으로 스캔하지 않고도 살아있는 객체를 정확하고 빠르게 식별할 수 있도록 돕습니다 [4, 5].
-
-## 📖 구조화된 지식 (Synthesized Content)
-* **세대 간 참조 추적 (Old-to-New Pointers):** V8 엔진이 신규 공간(New-space)을 스캐빈지(Scavenge) 방식으로 수집할 때, 구 공간(Old-space)의 객체가 신규 공간 객체를 가리키는 포인터를 추적해야 합니다 [4]. 전체 구 공간을 탐색하는 것은 매우 큰 비용을 수반하므로, 객체의 참조가 저장될 때 쓰기 장벽(Write barrier) 코드가 실행되어 구 공간에서 신규 공간으로 향하는 포인터를 찾아내어 '스토어 버퍼(Store buffer)' 등에 그 위치를 기록해 둡니다 [1, 5].
-* **점진적 및 동시성 마킹(Marking) 중의 참조 무결성 유지:** 점진적(Incremental) 또는 동시성(Concurrent) 마킹 과정에서는 마킹이 진행되는 동안 자바스크립트 실행 등에 의해 객체 그래프가 변경될 수 있습니다 [2]. 이미 GC에 의해 스캔이 완전히 끝난 객체(Black object)가 새롭게 생성되거나 아직 스캔되지 않은 객체(White object)를 참조하게 될 경우, 살아있는 객체가 죽은 것으로 오인될 위험이 있습니다 [2]. 쓰기 장벽은 이러한 'Black→White' 포인터 생성을 감지하여, Black 객체를 다시 재탐색 상태(Grey object)로 변경하고 마킹 데크(Deque)로 돌려보내 정상적인 추적이 완료되게 만듭니다 [2, 3, 6].
-* **성능 오버헤드와 런타임 최적화:** 포인터가 변경될 때마다 추가 명령(Instruction)을 실행해야 하므로 시스템에 어느 정도의 비용(오버헤드)이 발생하지만, 일반적으로 메모리 쓰기 작업이 읽기 작업보다 훨씬 적게 발생하므로 관리 가능한 수준입니다 [1]. V8 엔진에서는 크랭크샤프트(Crankshaft)와 같은 컴파일러가 최적화를 통해 객체가 스택에 할당되거나 신규 공간에만 존재함을 확명할 수 있는 경우, 해당 저장 작업에서 쓰기 장벽을 생략하여 성능을 개선합니다 [7].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[Garbage Collection]], [[Store Buffer]], [[Incremental Marking]], [[Concurrent Marking]], [[Scavenge]]
-- **Projects/Contexts:** [[V8 JavaScript Engine]], [[IBM Eclipse OpenJ9]]
-- **Contradictions/Notes:** 소스에 관련 정보가 부족합니다.
-
----
-*Last updated: 2026-04-19*
-- Raw Source: [[00_Raw/2026-04-20/Write Barrier.md]]
----
diff --git a/Programming & Language/Zod 런타임 유효성 검사 통합.md b/Programming & Language/Zod 런타임 유효성 검사 통합.md
deleted file mode 100644
index 1abd9c70..00000000
--- a/Programming & Language/Zod 런타임 유효성 검사 통합.md	
+++ /dev/null
@@ -1,37 +0,0 @@
----
-id: P-REINFORCE-AUTO-FD8703
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Zod 런타임 유효성 검사 통합"
----
-
-# [[Zod 런타임 유효성 검사 통합]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> Zod는 TypeScript 환경에서 런타임 유효성 검사를 수행하여 시스템의 데이터 무결성을 보장하는 데 사용되는 검증 라이브러리입니다. 컴파일 타임에만 동작하는 TypeScript의 한계를 보완하여, API 응답이나 외부 설정 파일과 같이 타입을 강제할 수 없는 외부 데이터를 안전하게 처리합니다. 주로 '검증하지 말고 파싱하라(Parse, don't validate)'는 철학을 바탕으로, 알 수 없는(unknown) 데이터를 시스템 경계에서 신뢰할 수 있는 타입으로 파싱하는 역할을 합니다.
-
-## 📖 구조화된 지식 (Synthesized Content)
-* **외부 데이터의 런타임 안전성 확보**
-  TypeScript 자체는 런타임에 외부에서 주입되는 데이터(API 응답, 외부 설정 파일 등)를 통제하거나 보호할 수 없습니다[1]. 이러한 상황에서 식별 가능한 유니온(Discriminated Unions)과 Zod의 런타임 유효성 검사를 결합하면, 외부 데이터로 인해 발생할 수 있는 오류를 차단하고 안전성을 크게 높일 수 있습니다[1].
-* **'Parse, don't validate(검증하지 말고 파싱하라)' 철학의 구현**
-  시스템의 경계(Boundary)에서 타입이 없거나 불확실한 데이터를 받았을 때, 코드 곳곳에서 유효성을 확인하는 대신 진입점에서 한 번 파싱하여 완벽하게 타입이 지정된 데이터로 변환하는 것이 핵심입니다[2-4]. Zod는 데이터를 확인하는 것에 그치지 않고, 런타임 데이터를 더 구체적이고 신뢰할 수 있는 타입의 객체로 안전하게 파싱하여 내부 로직으로 전달하는 구체적인 방법론을 제공합니다[4, 5].
-* **브랜디드 타입(Branded Types)과의 완벽한 통합**
-  Zod는 브랜디드 타입 패턴을 훌륭하게 지원합니다[6]. Zod의 `.brand()` 메서드를 사용하면, 단순히 런타임 타입이 올바른지뿐만 아니라 비즈니스 규칙을 충족하는지 검증된 데이터에만 고유한 표식(브랜드)을 부여할 수 있습니다[6, 7]. 이를 통해 컴파일러 수준에서 의미적으로 다른 데이터가 섞이는 것을 엄격하게 차단합니다[6, 8].
-* **예외가 없는 안전한 결과 처리**
-  Zod는 데이터를 파싱할 때 런타임 에러(Exception)를 직접 던지는 대신, `.safeParse()` 메서드를 사용하여 성공 및 에러 여부가 담긴 결과(Result) 객체를 반환합니다[4, 6]. 이는 예상치 못한 예외 발생을 방지하고, 에러를 예측 가능하고 일관된 흐름으로 제어할 수 있도록 돕습니다[4, 6].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[Parse, don't validate]], [[브랜디드 타입(Branded Types)]], [[식별 가능한 유니온(Discriminated Unions)]]
-- **Projects/Contexts:** [[외부 API 응답 및 설정 파일 처리]], [[런타임 상태 및 데이터 무결성 검증]]
-- **Contradictions/Notes:** Zod 유효성 검사 도입 시 발생할 수 있는 구체적인 성능 저하 수치나 이와 대립되는 다른 라이브러리(예: Joi, Yup 등)와의 직접적인 비교에 대해서는 소스에 관련 정보가 부족합니다.
-
----
-*Last updated: 2026-04-18*
-- Raw Source: [[00_Raw/2026-04-20/Zod 런타임 유효성 검사 통합.md]]
----
diff --git a/Programming & Language/Zod 파싱과 브랜디드 타입을 결합한 런타임 데이터 검증.md b/Programming & Language/Zod 파싱과 브랜디드 타입을 결합한 런타임 데이터 검증.md
deleted file mode 100644
index 30802a10..00000000
--- a/Programming & Language/Zod 파싱과 브랜디드 타입을 결합한 런타임 데이터 검증.md	
+++ /dev/null
@@ -1,34 +0,0 @@
----
-id: P-REINFORCE-AUTO-725C86
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Zod 파싱과 브랜디드 타입을 결합한 런타임 데이터 검증"
----
-
-# [[Zod 파싱과 브랜디드 타입을 결합한 런타임 데이터 검증]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> Zod 파싱과 브랜디드 타입을 결합한 런타임 데이터 검증은 시스템 경계에서 신뢰할 수 없는 데이터를 안전하고 구체적인 타입으로 변환하는 강력한 설계 기법입니다 [1-3]. 이 기법은 "검증하지 말고 파싱하라(Parse, Don't Validate)"는 철학을 바탕으로, Zod를 통해 런타임에 데이터를 검증함과 동시에 컴파일 타임의 고유한 브랜디드 타입을 부여합니다 [4]. 이를 통해 런타임 환경의 구조적 무결성과 컴파일 타임의 엄격한 타입 안전성을 한 번에 확보할 수 있습니다 [3-5].
-
-## 📖 구조화된 지식 (Synthesized Content)
-- **Parse, Don't Validate 철학**: 이 원칙은 프로그램의 여러 곳에 검증 로직을 흩뿌리는 대신, 시스템의 진입점(경계)에서 타입이 없는 데이터를 한 번에 파싱하여 잘 정의된(well-typed) 데이터로 변환하는 것에 초점을 둡니다 [1, 2]. 즉, 단순한 유효성 체크를 넘어서서 데이터를 더 구체적이고 신뢰할 수 있는 타입의 객체로 변환하여 내부로 전달합니다 [1, 4].
-- **Zod를 활용한 런타임 검증**: Zod 라이브러리는 알 수 없는(unknown) 데이터를 파싱하여 이미 알고 있는 안전한 타입으로 변환해 줍니다 [2, 6]. 특히 Zod의 `.safeParse()` 메서드를 사용하면 실패 시 에러를 던지지(throw) 않고 결과 객체를 반환하므로 더욱 안전하고 예측 가능한 런타임 처리가 가능합니다 [5].
-- **브랜디드 타입(Branded Types)의 필요성**: TypeScript의 구조적 타이핑(Structural Typing)으로 인해 서로 의미가 다른 문자열(예: 사용자 ID와 주문 ID)이 동일한 타입으로 취급되는 문제가 발생할 수 있습니다 [7, 8]. 이를 해결하기 위해 런타임에는 존재하지 않지만 컴파일 시점에만 식별되는 고유한 표식(unique symbol 등)을 타입에 결합하여 다른 원시 타입과 섞이는 것을 원천 차단하는 브랜디드 타입을 사용합니다 [3, 8, 9].
-- **Zod 통합 구현 (Zod Integration)**: Zod는 자체적으로 `.brand()` 메서드를 지원하여 런타임 파싱과 브랜디드 타입 부여를 우아하게 결합합니다 [5]. 예를 들어, `z.string().uuid().brand<"UserId">()`와 같이 스키마를 구성하면, 파싱을 통과한 데이터는 런타임에서 유효한 문자열이자 UUID 포맷임을 입증받게 되며, TypeScript 컴파일러 상에서는 구별되는 고유한 `UserId` 타입으로 취급됩니다 [4, 5].
-- **데이터 오염 방지 효과**: 이렇게 브랜디드 타입과 런타임 파서가 결합된 데이터만이 시스템 핵심 로직으로 진입하도록 강제함으로써, 검증되지 않은 데이터가 섞이는 것을 방지하고 애플리케이션의 안정성을 극대화합니다 [3, 8, 10].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[Parse, don't validate]], [[Branded Types]], [[Opaque Types]], [[Zod]]
-- **Projects/Contexts:** 도메인 기반 설계(DDD)에서의 데이터 오염 방지(예: UserId와 OrderId의 엄격한 분리), 외부 API 응답 및 사용자 입력 등 시스템 경계면에서의 런타임 검증 [3, 4, 8, 10]
-- **Contradictions/Notes:** Zod와의 결합을 반대하는 내용은 없으나, 브랜디드 타입과 같은 타입 시스템 기능은 코드 작업에 개념적 복잡성을 추가하므로, 개발자가 애플리케이션에서 직면한 실제 문제에 실질적인 이점을 제공하는지 먼저 신중히 평가한 뒤 도입해야 합니다 [11, 12].
-
----
-*Last updated: 2026-04-18*
-- Raw Source: [[00_Raw/2026-04-20/Zod 파싱과 브랜디드 타입을 결합한 런타임 데이터 검증.md]]
----
diff --git a/Programming & Language/Zod.md b/Programming & Language/Zod.md
deleted file mode 100644
index 607eda95..00000000
--- a/Programming & Language/Zod.md	
+++ /dev/null
@@ -1,33 +0,0 @@
----
-id: P-REINFORCE-AUTO-DB4331
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Zod"
----
-
-# [[Zod]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> Zod는 TypeScript 및 JavaScript 환경에서 런타임 검증(Runtime validation)을 수행하기 위해 널리 사용되는 인기 있는 유효성 검사 라이브러리입니다 [1, 2]. API 응답이나 외부 구성 파일처럼 TypeScript의 정적 타입 시스템이 런타임에 도움을 줄 수 없는 외부 데이터를 다룰 때, 타입 안정성을 확보하는 데 핵심적인 역할을 합니다 [1]. 단순히 유효성을 검사하는 것에 그치지 않고, 알 수 없는 데이터를 잘 정의된 타입으로 '파싱(Parsing)'하여 시스템 내부를 안전하게 보호하는 도구로 활용됩니다 [3, 4].
-
-## 📖 구조화된 지식 (Synthesized Content)
-- **런타임 유효성 검사와 외부 데이터 보호:** TypeScript는 컴파일 타임 언어이므로, 외부 환경(API, 설정 파일 등)에서 유입되는 잘못된 데이터에 대해서는 런타임 오류를 막아주지 못합니다. Zod는 이러한 한계를 극복하기 위해 식별 가능한 유니온(Discriminated unions) 등과 결합하여 런타임 단계에서 데이터의 무결성을 엄격하게 검사합니다 [1].
-- **'검증하지 말고 파싱하라(Parse, don't validate)' 원칙의 실현:** Zod는 이 철학을 구현하는 구체적이고 대표적인 방법론입니다 [4]. 시스템의 경계에서 Zod를 통해 입력 데이터를 한 번 파싱하면 유효성 검증과 타입 변환이 동시에 이루어지며, 이후의 애플리케이션 코드는 완전히 타입이 지정된 안전한 데이터를 신뢰하고 사용할 수 있게 됩니다 [3, 5, 6].
-- **브랜디드 타입(Branded Types)과의 매끄러운 통합:** Zod는 런타임 검증과 컴파일 타임의 타입 구분을 결합할 수 있도록 `.brand()` 메서드를 지원합니다 [2]. 이를 통해 런타임 비즈니스 규칙(예: 유효한 이메일 형식 등)을 통과한 데이터에만 고유한 브랜디드 타입을 부여할 수 있으며, 이는 타입이 우연히 섞이는 것을 방지하는 강력하고 견고한 API 구축을 가능하게 합니다 [2, 4, 7].
-- **안전하고 예측 가능한 에러 처리:** 예외(Exception)를 던지는 대신, Zod의 `.safeParse()` 메서드를 사용하면 유효성 검증 결과를 성공 또는 실패 상태를 담은 결과 객체(Result object)로 반환합니다 [2]. 이는 에러를 더 안전하고 제어 가능한 방식으로 처리하도록 돕습니다 [2].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[Runtime Validation]], [[Branded Types]], [[Discriminated Unions]], [[Parse, don't validate]]
-- **Projects/Contexts:** [[External Data Handling]], [[TypeScript Type Safety]]
-- **Contradictions/Notes:** 소스 내에서 Zod에 대한 모순된 주장은 발견되지 않습니다. 대신, 정적 타입 언어인 TypeScript가 갖는 런타임 데이터 검증의 사각지대를 보완하는 매우 효과적이고 권장되는 라이브러리로 일관되게 소개됩니다 [1-4].
-
----
-*Last updated: 2026-04-18*
-- Raw Source: [[00_Raw/2026-04-20/Zod.md]]
----
diff --git a/Programming & Language/Zod를 활용한 런타임 데이터 파싱.md b/Programming & Language/Zod를 활용한 런타임 데이터 파싱.md
deleted file mode 100644
index bae479da..00000000
--- a/Programming & Language/Zod를 활용한 런타임 데이터 파싱.md	
+++ /dev/null
@@ -1,40 +0,0 @@
----
-id: P-REINFORCE-AUTO-4215D8
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Zod를 활용한 런타임 데이터 파싱"
----
-
-# [[Zod를 활용한 런타임 데이터 파싱]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-- **"Parse, Don't Validate" 철학의 실현**
-  Zod는 시스템 경계(진입점 및 반환점)에서 타입이 없거나 느슨한 데이터를 정형화된 타입으로 변환하는 파싱 역할을 수행합니다 [1, 4]. 파서를 통해 미지의 데이터(unknown data)를 알려진 데이터(known data)로 변환하면, 애플리케이션의 나머지 코드는 TypeScript의 정적 타입 체커에 온전히 의존할 수 있어 코드의 신뢰성이 크게 향상됩니다 [4, 7].
-
-- **외부 데이터의 런타임 검증**
-  컴파일 시점의 TypeScript는 외부 API 응답이나 설정 파일에서 유입되는 데이터의 형태를 강제할 수 없습니다 [3]. 이러한 상황에서 Zod를 활용하여 런타임 검증을 추가하면 예기치 않은 데이터 구조로 인한 런타임 에러를 방지할 수 있습니다 [3]. 특히 식별 가능한 유니온(Discriminated Unions)과 결합하면 런타임 비동기 UI 상태 등을 더욱 안전하게 검증할 수 있습니다 [3].
-
-- **안전한 에러 처리 (Safe Parsing)**
-  Zod는 파싱 중 에러가 발생할 때 예외를 직접 던지지(throwing) 않고 결과 객체(result object)를 반환하는 `.safeParse()` 메서드를 제공합니다 [6]. 이를 통해 개발자는 예상치 못한 런타임 예외로 인한 프로그램 종료를 막고, 에러 상태를 안전하고 예측 가능하게 제어할 수 있습니다 [6].
-
-- **브랜디드 타입(Branded Types)과의 완벽한 통합**
-  Zod는 `.brand()` 메서드를 통해 브랜디드 타입과 자연스럽게 통합됩니다 [6]. 단순한 구조적 타입 검사를 넘어, 데이터가 구체적인 비즈니스 규칙까지 충족하도록 보장하는 검증된 브랜디드 타입을 런타임에 생성할 수 있습니다 [5, 6]. 이 과정은 검증되지 않은 데이터의 시스템 내부 진입을 철저히 차단하는 수비적 프로그래밍의 구체적인 방법론으로 작용합니다 [7].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[Parse, don't validate]], [[브랜디드 타입(Branded Types)]], [[식별 가능한 유니온(Discriminated Unions)]]
-- **Projects/Contexts:** [[외부 API 데이터 및 설정 파일 처리]], [[런타임 상태 검증(Runtime Validation)]]
-- **Contradictions/Notes:** 소스에 관련 정보가 부족합니다. (제공된 소스 내에서 Zod 활용에 대한 상충되는 의견이나 모순점은 발견되지 않았습니다.)
-
----
-*Last updated: 2026-04-18*
-- Raw Source: [[00_Raw/2026-04-20/Zod를 활용한 런타임 데이터 파싱.md]]
----
diff --git a/Programming & Language/Zustand-Based-Mission-Persistence.md b/Programming & Language/Zustand-Based-Mission-Persistence.md
deleted file mode 100644
index 097ef8fd..00000000
--- a/Programming & Language/Zustand-Based-Mission-Persistence.md	
+++ /dev/null
@@ -1,37 +0,0 @@
----
-id: P-REINFORCE-AUTO-E45B33
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Zustand-Based-Mission-Persistence"
----
-
-# [[Zustand-Based-Mission-Persistence]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 장시간 지속되는 지식 탐사 미션의 안정성을 보장하기 위해 도입된 상태 유지 로직입니다. Zustand 라이브러리와 로컬 스토리지를 활용하여, 브라우저 종료나 네트워크 장애 시에도 현재의 작업 큐, 완료 목록, 그리고 진행 중인 NotebookLM 태스크 정보를 즉시 복구합니다.
-
-## 📖 구조화된 지식 (Synthesized Content)
-자율 연구 엔진은 며칠씩 돌아가는 작업이 될 수 있습니다. 메모리 기반의 상태 관리는 브라우저 새로고침 한 번에 모든 노력이 물거품이 될 위험이 컸습니다.
-
-보완된 지속성 레이어는 다음과 같이 작동합니다:
-1. **Partial Persist**: 
-    - `agentStore.ts`의 상태 중 설정(Token, Repo URL)뿐만 아니라 작업의 '실시간 현황'(Queue, ProcessedCount)을 로컬 스토리지에 동기화합니다.
-2. **Resume Mechanism**: 
-    - 앱 재시작 시 `activeResearchTasks`를 대조하여, 이전에 생성된 NotebookLM의 `notebookId`와 `taskId`를 그대로 불러옵니다.
-    - 이는 중복 결제(API 호출)나 중복 프로젝트 생성을 막아주는 경제적 효과도 가집니다.
-3. **Ghost State Prevention**: `handleStart` 호출 시 `clearState()`를 강제하여, 새로운 미션을 시작할 때는 이전 미션의 잔상이 남지 않도록 설계상의 'Clean Slate' 원칙을 준수합니다.
-
-이 아키텍처는 에이전트가 단순한 '스크립트'가 아닌, 실제 워크스테이션에서 구동되는 '전문 소프트웨어'로서의 안정성을 갖추게 했습니다.
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[Autonomous-Loop-State-Machine]], [[NotebookLM-Automated-Authentication-CLI]]
-- **Projects/Contexts:** [[P-Reinforce-Agent-v2.6]]
-- **Contradictions/Notes:** 로컬 스토리지의 용량 제한(약 5MB)에 유의해야 하며, 큐가 수만 개로 늘어날 경우 별도의 DB 연동을 고려해야 합니다.
-- Raw Source: [[00_Raw/2026-04-20/Zustand-Based-Mission-Persistence.md]]
----
diff --git a/Programming & Language/as const Assertion.md b/Programming & Language/as const Assertion.md
deleted file mode 100644
index 1007a180..00000000
--- a/Programming & Language/as const Assertion.md	
+++ /dev/null
@@ -1,32 +0,0 @@
----
-id: P-REINFORCE-CAF879
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.95
-tags: []
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Mega Batch 2 - Wikified as const Assertion"
----
-
-# [[as const Assertion]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> `as const` Assertion은 TypeScript에서 값을 깊은 읽기 전용(deeply readonly) 상태로 만들고 타입을 해당 리터럴 값으로 좁히는(narrow) 기능입니다 [1]. 이를 통해 객체나 배열이 변경되지 않도록 컴파일 타임에 보장하며, 더 정확한 타입 추론을 가능하게 합니다 [1, 2]. 주로 절대 변경되어서는 안 되는 구성(configuration) 객체나 조회 테이블(lookup tables)을 정의할 때 유용하게 사용됩니다 [2].
-
-## 📖 구조화된 지식 (Synthesized Content)
-- **깊은 읽기 전용 및 리터럴 타입 추론:** `as const` 단언은 변수의 타입을 넓은 범위의 원시 타입(예: `string`) 대신 가장 구체적인 리터럴 타입(예: 구체적인 문자열 값)으로 좁혀줍니다 [1]. 또한 객체나 배열의 모든 속성을 깊은 읽기 전용(`readonly`)으로 만들어, 값이 변경되는 것을 방지합니다 [1]. 
-- **불변성과 안전성 확보:** 이 기능을 사용하면 의도치 않은 값의 변경을 막아 컴파일 타임의 타입 검증과 런타임의 불변성(immutability)을 모두 확보할 수 있습니다 [2].
-- **`satisfies` 연산자와의 결합 패턴:** TypeScript에서 `as const`는 `satisfies` 연산자와 결합하여 자주 사용됩니다 [2]. 이 조합은 타입 검증(type validation)과 불변성을 동시에 제공하므로, 변경되어서는 안 되는 설정 객체나 룩업 테이블을 안전하게 생성하는 데 매우 이상적인 패턴으로 평가받습니다 [2, 3].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 지식 자산화 및 기존 네트워크 연동 단계.
-- **정책 변화:** Programming & Language 카테고리의 전문성 확보 및 링크 밀도 최적화.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[Readonly]], [[Literal Types]], [[Satisfies Operator]]
-- **Projects/Contexts:** [[Configuration Objects]], [[Lookup Tables]]
-- **Contradictions/Notes:** 제공된 소스에서 `as const`에 대한 단독 설명은 다소 간략하며 정보가 부족한 편이지만, `satisfies` 연산자와 결합할 때 불변의 타입 안전 객체(immutable, type-safe objects)를 생성하는 핵심적인 역할을 한다는 점이 뚜렷하게 강조됩니다 [1-3].
-
----
-*Last updated: 2026-04-18*
-- Raw Source: [[00_Raw/2026-04-20/as const Assertion.md]]
----
diff --git a/Programming & Language/as const.md b/Programming & Language/as const.md
deleted file mode 100644
index a858cb9e..00000000
--- a/Programming & Language/as const.md	
+++ /dev/null
@@ -1,40 +0,0 @@
----
-id: P-REINFORCE-AUTO-701C2F
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - as const"
----
-
-# [[as const]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> `as const`는 TypeScript에서 값을 깊은 수준의 읽기 전용(deeply readonly)으로 만들고, 해당 타입을 구체적인 리터럴 값으로 좁히는(narrows types to their literal values) 데 사용되는 단언(assertion) 문법입니다 [1]. 객체나 배열 등이 변경되지 않도록 컴파일 타임 검증과 런타임 불변성을 동시에 확보할 때 유용하게 쓰입니다 [2]. 특히 구성(configuration) 객체나 룩업 테이블을 정의할 때 다른 연산자와 결합하여 매우 강력하고 안전한 타입 패턴을 형성합니다 [2, 3].
-
-## 📖 구조화된 지식 (Synthesized Content)
-* **깊은 읽기 전용 및 리터럴 타입 축소 (Deeply Readonly & Literal Type Narrowing)**
-  `as const` 단언(assertion)을 사용하면 값은 깊게 읽기 전용(deeply readonly) 상태가 됩니다 [1]. 이와 더불어 TypeScript는 값을 포괄적인 기본 타입(예: `string`이나 `number`)으로 넓히지 않고, 작성된 리터럴 값 자체로 타입을 좁혀서(narrow) 추론합니다 [1].
-
-* **`satisfies` 연산자와의 결합 패턴**
-  `as const`는 `satisfies` 연산자와 결합하여 사용할 때 불변성(immutability)과 타입 검증(type validation)을 동시에 얻을 수 있는 강력한 패턴이 됩니다 [2]. 이 조합은 절대로 변경되어서는 안 되는 설정(configuration) 객체나 룩업 테이블(lookup tables)을 작성할 때 이상적입니다 [2, 4].
-
-* **컴파일 타임과 런타임의 안정성 보장**
-  이러한 단언 패턴을 도입하면 의도치 않은 값의 변경을 방지하는 동시에, 객체가 필수적인 타입 구조와 정확히 일치하도록 유지할 수 있습니다 [2]. 결과적으로 개발자는 컴파일 타임의 철저한 검증과 타입 안전성이 보장된 불변 객체를 얻게 됩니다 [2, 3]. 
-
-* **기타 사용 맥락**
-  일반적으로 프론트엔드 환경에서 타입 추론이나 타입 가드를 목적으로 `as const`를 흔히 붙여서 사용해 왔으나, 최신 문법 구조나 패턴 매칭 라이브러리 적용 등을 통해 이러한 `as const` 사용을 제거(대체)할 수 있다는 의견도 존재합니다 [5].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[satisfies]], [[readonly]], [[Literal Types]], [[Type Narrowing]]
-- **Projects/Contexts:** [[TypeScript 구성(configuration) 객체 및 룩업 테이블 모델링]], [[불변성(Immutability) 보장 패턴]]
-- **Contradictions/Notes:** 소스 상에 명시적인 모순은 없으나, 타입 추론과 타입 가드를 위해 관행적으로 `as const`를 붙여 쓰던 것을 특정 패턴 도입을 통해 생략할 수도 있다는 개발자 커뮤니티의 코멘트가 존재합니다 [5].
-
----
-*Last updated: 2026-04-18*
-- Raw Source: [[00_Raw/2026-04-20/as const.md]]
----
diff --git a/Programming & Language/bitECS와 SharedArrayBuffer를 결합한 멀티스레드 고성능 아키텍처.md b/Programming & Language/bitECS와 SharedArrayBuffer를 결합한 멀티스레드 고성능 아키텍처.md
deleted file mode 100644
index e8312863..00000000
--- a/Programming & Language/bitECS와 SharedArrayBuffer를 결합한 멀티스레드 고성능 아키텍처.md	
+++ /dev/null
@@ -1,40 +0,0 @@
----
-id: P-REINFORCE-AUTO-33DDD3
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - bitECS와 SharedArrayBuffer를 결합한 멀티스레드 고성능 아키텍처"
----
-
-# [[bitECS와 SharedArrayBuffer를 결합한 멀티스레드 고성능 아키텍처]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> `bitECS`의 데이터 지향 설계(SoA) 구조와 `SharedArrayBuffer`의 무복사(Zero-Copy) 메모리 공유 기능을 결합하여, 메인 스레드의 렌더링 블로킹 없이 웹 워커에서 수만 개의 엔티티를 병렬 연산하고 실시간으로 동기화하는 초고성능 웹 게임 엔진 아키텍처입니다.
-
-## 📖 구조화된 지식 (Synthesized Content)
-**1. bitECS의 데이터 지향 설계 (Structure of Arrays, SoA)** `bitECS`는 기존의 객체 지향(AoS) 방식 대신, 컴포넌트 데이터를 `Float32Array`와 같은 `TypedArray` 기반의 연속된 배열 구조(SoA)로 저장하는 ECS(Entity Component System) 라이브러리입니다. 이 구조는 CPU 캐시 적중률을 극대화하여 수천, 수만 개의 엔티티 상태(예: 위치, 속도)를 밀리초 단위로 연산할 수 있게 합니다.
-
-**2. SharedArrayBuffer를 통한 Zero-Copy 메모리 공유** `bitECS`가 내부적으로 사용하는 `TypedArray`의 기반 메모리를 `SharedArrayBuffer`로 할당할 수 있습니다. 생성된 버퍼를 웹 워커(Web Worker)로 전달하면 메인 스레드와 워커 스레드가 완전히 동일한 메모리 주소를 공유하게 됩니다. 이를 통해 매 프레임마다 직렬화 및 역직렬화(`postMessage`) 오버헤드 없이 스레드 간 데이터 통신이 가능해집니다.
-
-**3. 스레드 역할의 엄격한 분리 (단방향 데이터 흐름)** 동시성 문제(Data Race)를 해결하기 위해 스레드 간의 읽기/쓰기 역할을 아키텍처 수준에서 분리합니다.
-
-- **워커 스레드 (Write 전담):** 물리 엔진 연산, 충돌 처리, AI 이동 로직 등의 `bitECS` 시스템(System)이 독립적인 백그라운드 루프(예: 60Hz)에서 실행되며, 공유 버퍼의 데이터를 업데이트합니다.
-- **메인 스레드 (Read 전담):** `React Three Fiber(R3F)`의 `useFrame` 렌더링 루프 내에서, 공유 메모리의 `bitECS` 컴포넌트 값(예: `Position.x[eid]`)을 그대로 읽어와 Three.js 메시(Mesh) 인스턴스 참조(ref)에 반영하여 화면에 렌더링합니다.
-
-**4. 렌더링과 시뮬레이션의 디커플링 이점** 이 아키텍처를 적용하면 무거운 물리 연산이 React의 가상 DOM 재조정(Reconciliation)이나 메인 스레드를 블로킹하지 않습니다. 또한 매 프레임 객체를 새로 생성하지 않고 배열의 값만 변경하므로, 가비지 컬렉션(GC) 스파이크로 인한 프레임 드랍을 원천적으로 방지할 수 있습니다.
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[Data-Oriented Design (DOD)]], [[Structure of Arrays (SoA)]], [[Web Worker 멀티스레딩]], [[React Three Fiber (R3F) 최적화]], [[메모리 파편화 방지 및 객체 풀링]]
-- **Projects/Contexts:** [[브라우저 기반 AAA급 멀티스레드 3D 게임]], [[수만 개의 엔티티가 존재하는 실시간 물리 시뮬레이션]]
-- **Contradictions/Notes:** 원시 이진 데이터인 `SharedArrayBuffer`를 직접 다루는 것은 로우 레벨 개발 지식이 필요해 매우 까다롭습니다. 하지만 `bitECS`를 프록시 구조로 활용하면, 개발자는 익숙한 자바스크립트 배열이나 객체를 다루는 듯한 편의성을 누리면서도 내부적으로는 C++ 엔진에 필적하는 메모리 공유 성능을 얻을 수 있다는 강력한 장점이 있습니다.
-
----
-
-_Last updated: 2026-04-14_
-- Raw Source: [[00_Raw/2026-04-20/bitECS와 SharedArrayBuffer를 결합한 멀티스레드 고성능 아키텍처.md]]
----
diff --git a/Programming & Language/bitECS와 SharedArrayBuffer의 실제 코드 통합.md b/Programming & Language/bitECS와 SharedArrayBuffer의 실제 코드 통합.md
deleted file mode 100644
index b8d3e10f..00000000
--- a/Programming & Language/bitECS와 SharedArrayBuffer의 실제 코드 통합.md	
+++ /dev/null
@@ -1,73 +0,0 @@
----
-id: P-REINFORCE-AUTO-6AB6C6
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - bitECS와 SharedArrayBuffer의 실제 코드 통합"
----
-
-# [[bitECS와 SharedArrayBuffer의 실제 코드 통합]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> `bitECS`의 데이터 지향 컴포넌트(SoA) 구조에 기본 자바스크립트 배열 대신 `SharedArrayBuffer` 기반의 `TypedArray(Float32Array 등)`를 매핑하여, 멀티스레드 환경에서 복사 오버헤드 없이 실시간으로 데이터를 읽고 쓰는 구현 방식입니다.
-
-## 📖 구조화된 지식 (Synthesized Content)
-**1. 데이터 구조의 기반: TypedArray와 SoA(Structure of Arrays)** `bitECS`는 엔티티의 컴포넌트 데이터를 메모리 상에 연속적으로 배치하기 위해 내부적으로 `Float32Array`와 같은 타입화된 배열(TypedArray)을 사용합니다. 이러한 SoA 방식은 CPU 캐시 효율을 극대화하여 고성능 연산을 가능하게 합니다.
-
-**2. SharedArrayBuffer를 이용한 메모리 공유 연결** 일반적인 `TypedArray`는 단일 스레드 메모리에 종속되지만, 그 기반 메모리를 `SharedArrayBuffer`로 할당하면 스레드 간 공유가 가능해집니다. `bitECS` 컴포넌트 객체를 선언할 때, 이 공유 버퍼를 참조하는 뷰(View) 배열을 할당하는 방식으로 두 기술을 연결할 수 있습니다.
-
-**3. 실제 통합 코드 예시** 제공된 `bitECS` API 구조에 `SharedArrayBuffer` 개념을 결합한 실제 연결 예시입니다.
-
-```
-import { createWorld, addEntity, addComponent } from 'bitecs';
-
-// 1. SharedArrayBuffer로 공유 메모리 할당 (예: 10만 개 엔티티용, Float32는 4바이트)
-const MAX_ENTITIES = 100000;
-const bufferX = new SharedArrayBuffer(MAX_ENTITIES * 4);
-const bufferY = new SharedArrayBuffer(MAX_ENTITIES * 4);
-
-// 2. 공유 메모리를 바라보는 TypedArray 뷰 생성
-const sharedVelocityX = new Float32Array(bufferX);
-const sharedVelocityY = new Float32Array(bufferY);
-
-// 3. bitECS 월드 생성 시 공유 배열을 컴포넌트 데이터로 매핑
-const world = createWorld({
-  components: {
-    Velocity: {
-      x: sharedVelocityX,
-      y: sharedVelocityY
-    }
-  },
-  time: { delta: 0, elapsed: 0, then: performance.now() }
-});
-
-const { Velocity } = world.components;
-
-// 4. 엔티티 생성 및 데이터 쓰기 (이 데이터는 공유 메모리에 직접 기록됨)
-const eid = addEntity(world);
-addComponent(world, eid, Velocity);
-
-Velocity.x[eid] = 1.23; // 공유 메모리의 0번 인덱스에 데이터 쓰기
-Velocity.y[eid] = 1.23;
-
-// 5. 웹 워커로 공유 버퍼 전송 (직렬화 오버헤드 없이 메모리 주소만 공유)
-// worker.postMessage({ bufferX, bufferY });
-```
-
-**4. 스레드 간 데이터 동기화 원리** 위와 같이 구성한 후 `bufferX`, `bufferY`를 웹 워커로 전달하면 메인 스레드와 워커 스레드는 완벽하게 동일한 메모리를 공유하게 됩니다. 워커 스레드에서 물리 연산을 통해 배열의 `x, y` 인덱스 값을 업데이트하면, 메인 스레드는 `postMessage`로 매번 데이터를 넘겨받을 필요 없이 `bitECS`의 `Velocity.x[eid]`를 통해 즉시 렌더링에 반영할 수 있습니다.
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[Structure of Arrays (SoA)]], [[TypedArray (Float32Array)]], [[Web Worker postMessage 통신]], [[메모리 제로 복사 (Zero-Copy)]]
-- **Projects/Contexts:** [[멀티스레드 기반 웹 게임 물리 엔진 구현]], [[초대규모 파티클 및 엔티티 시뮬레이션 (React Three Fiber)]]
-- **Contradictions/Notes:** `bitECS`와 같은 프록시 객체를 사용하면 원시 메모리를 다루는 로우 레벨 프로그래밍을 자바스크립트 객체 배열(JS objects) 다루듯 쉽게 접근할 수 있게 해줍니다. 하지만 이렇게 최적화를 하더라도, 개발자가 일반적으로 즐겨 사용하는 유연한 JSON 구조의 객체 데이터 포맷과는 여전히 거리가 멀고 데이터의 형태가 고정되어야 한다는 설계적 제약이 따릅니다.
-
----
-
-_Last updated: 2026-04-14_
-- Raw Source: [[00_Raw/2026-04-20/bitECS와 SharedArrayBuffer의 실제 코드 통합.md]]
----
diff --git a/Programming & Language/eslint-config-prettier.md b/Programming & Language/eslint-config-prettier.md
deleted file mode 100644
index 0a9261e5..00000000
--- a/Programming & Language/eslint-config-prettier.md	
+++ /dev/null
@@ -1,43 +0,0 @@
----
-id: P-REINFORCE-AUTO-7BFB20
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - eslint-config-prettier"
----
-
-# [[eslint-config-prettier]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> `eslint-config-prettier`는 코드 스타일을 포맷팅하는 도구인 Prettier와 코드 품질을 검사하는 정적 분석 도구인 ESLint를 함께 사용할 때 발생하는 규칙 충돌을 해결하기 위해 사용하는 npm 패키지입니다 [1, 2]. 이 설정은 ESLint의 규칙 중 Prettier의 포맷팅과 겹치거나 충돌할 수 있는 스타일 관련 규칙들을 모두 꺼주는(off) 역할을 합니다 [1, 3]. 주로 로컬 IDE 및 CI 파이프라인 환경에서 개발 전용(dev-only) 의존성으로 설치되어 사용됩니다 [4, 5].
-
-## 📖 구조화된 지식 (Synthesized Content)
-**주요 역할 및 작동 방식**
-*   ESLint의 규칙은 크게 코드 스타일 규칙과 코드 퀄리티 규칙으로 나뉩니다 [1]. ESLint를 코드 포맷터인 Prettier와 함께 사용할 경우, 이 '코드 스타일 규칙' 부분에서 두 도구 간의 역할이 겹치고 에러가 충돌하는 문제가 발생할 수 있습니다 [1, 6].
-*   Prettier 측에서는 이러한 충돌을 해결하기 위해 세 가지 통합 방법을 제시하는데, 그중 여러 단점이 있는 다른 도구들을 제치고 `eslint-config-prettier`를 사용하는 방식을 가장 적극적으로 추천하고 있습니다 [7, 8].
-*   이 패키지는 ESLint 내에서 Prettier와 충돌하는 규칙들만 선택적으로 비활성화하여, 문법 오류 검출은 ESLint가 전담하고 코드 스타일 정렬은 Prettier가 전담하도록 역할을 명확히 분리해줍니다 [9, 10].
-
-**설정 및 적용 방법**
-*   패키지 매니저(npm, yarn 등)를 통해 `devDependencies`로 `eslint-config-prettier`를 설치합니다 [5, 11].
-*   ESLint 설정 파일(예: `.eslintrc.js` 또는 `.eslintrc.json`)의 `extends` 속성 배열에 `"prettier"`를 추가하여 적용합니다 [5, 12].
-*   가장 주의할 점은, `eslint-config-prettier`가 앞서 정의된 ESLint의 스타일 설정들을 덮어쓰고 무효화할 수 있도록 반드시 `extends` 배열의 가장 마지막에 작성해야 한다는 것입니다 [5, 11, 13].
-
-**공급망 공격 보안 이슈 (CVE-2025-54313)**
-*   2025년 7월, 해당 패키지 관리자의 npm 토큰이 가짜 npmjs.com 로그인 페이지를 통해 피싱(phishing) 당하면서 대규모 공급망 공격에 노출되었습니다 [4, 14].
-*   공격자는 Windows 시스템을 표적으로 삼는 악성 DLL 페이로드(원격 코드 실행, RCE)를 설치 스크립트(`install.js`)에 포함시킨 4개의 악성 버전(8.10.1, 9.1.1, 10.1.6, 10.1.7)을 소스 코드 수정 없이 npm에 직접 게시했습니다 [4, 15].
-*   다행히 공격 대상이 Windows 환경에 한정되어 있었고 대다수의 CI 런너가 Linux를 사용하기 때문에 실제 피해 반경은 제한적이었습니다 [16, 17]. 관리자는 즉시 도난당한 토큰을 해지하고 악성 버전을 사용 중단(deprecated) 처리했으며, 안전한 새 버전(8.10.2+, 9.1.2+, 10.1.8+)을 배포하여 문제를 조치했습니다 [16, 18].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[ESLint]], [[Prettier]], [[Supply Chain Attack]]
-- **Projects/Contexts:** [[JavaScript Development Environment]], [[CVE-2025-54313]]
-- **Contradictions/Notes:** 소스들에 따르면 `eslint-plugin-prettier`나 `prettier-eslint`와 같은 대안 패키지도 존재하지만, 이들은 속도가 느려지거나 에디터에서 불필요한 빨간 밑줄을 너무 많이 발생시키는 단점이 있어 공식적으로 `eslint-config-prettier`의 단독 사용이 가장 권장됩니다 [7, 19].
-
----
-*Last updated: 2026-04-19*
-- Raw Source: [[00_Raw/2026-04-20/eslint-config-prettier.md]]
----
diff --git a/Programming & Language/eslint-plugin-prettier.md b/Programming & Language/eslint-plugin-prettier.md
deleted file mode 100644
index 7f7c87f9..00000000
--- a/Programming & Language/eslint-plugin-prettier.md	
+++ /dev/null
@@ -1,38 +0,0 @@
----
-id: P-REINFORCE-AUTO-4555A7
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - eslint-plugin-prettier"
----
-
-# [[eslint-plugin-prettier]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> `eslint-plugin-prettier`는 코드 포맷터인 Prettier를 정적 분석 도구인 ESLint의 규칙으로 실행시켜주는 플러그인 패키지입니다 [1, 2]. 이 도구를 사용하면 Prettier가 인식하는 코드 스타일 및 포맷 오류를 ESLint의 에러나 경고로 출력하게 됩니다 [2, 3]. 결과적으로 개발자는 두 도구의 기능을 통합하여 코드 문법과 포맷팅을 한 번에 관리할 수 있습니다 [4, 5].
-
-## 📖 구조화된 지식 (Synthesized Content)
-* **주요 역할 및 동작 방식:** 
-  `eslint-plugin-prettier`는 Prettier의 포맷팅 규칙을 ESLint의 린팅 규칙 안으로 가져와 동작하게 만듭니다 [4-6]. 이를 통해 개발자는 코드 내에서 Prettier의 규칙에 어긋나는 요소들을 ESLint의 에러(빨간 줄)나 경고(노란 줄)로 확인할 수 있습니다 [3, 4]. 또한 `eslint --fix` 명령어 하나만 실행해도 `prettier --write`를 별도로 사용할 필요 없이 코드 포맷팅까지 자동으로 적용되게 해줍니다 [4, 5].
-
-* **사용의 장단점:**
-  * **장점:** Prettier를 따로 설치하거나 실행할 필요 없이, `.eslintrc`와 같은 하나의 설정 파일에서 ESLint와 Prettier 설정을 통합하여 관리할 수 있습니다 [4].
-  * **단점:** 포맷팅 오류가 ESLint 에러로 간주되기 때문에 에디터 상에서 붉은 밑줄이 너무 많이 생겨 시각적으로 거슬릴 수 있습니다 [4, 6]. 또한, Prettier를 단독으로 사용하는 것보다 실행 속도가 느려질 수 있으며, 불필요한 플러그인 레이어가 하나 더 추가된다는 단점이 존재합니다 [4, 6].
-
-* **보안 취약점 (CVE-2025-54313):**
-  2025년 7월 발생한 npm 공급망 공격의 영향을 받은 패키지 중 하나입니다 [7]. 피싱 이메일 공격으로 메인테이너의 토큰이 탈취되어 윈도우 환경을 타깃으로 하는 악성 코드가 삽입된 버전이 npm 레지스트리에 배포되었으며, 해당 플러그인의 4.2.2 및 4.2.3 버전이 이 공격에 영향을 받은 것으로 보고되었습니다 [7].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[ESLint]], [[Prettier]], [[eslint-config-prettier]]
-- **Projects/Contexts:** [[CVE-2025-54313 (공급망 공격)]], [[웹 프론트엔드 개발 환경 설정]]
-- **Contradictions/Notes:** Prettier 공식 문서 및 여러 개발자들은 `eslint-plugin-prettier`를 사용할 때 발생하는 속도 저하와 과도한 에러 표시 문제 때문에 이 방법보다는 포맷팅 충돌 규칙만 꺼주는 `eslint-config-prettier`의 단독 사용을 가장 추천하고 있습니다 [1, 6, 8]. 그러나 설정의 중앙화와 단일 수정 명령어(`eslint --fix`)의 편리함을 이유로 이를 선호하는 실무자들도 존재합니다 [4].
-
----
-*Last updated: 2026-04-19*
-- Raw Source: [[00_Raw/2026-04-20/eslint-plugin-prettier.md]]
----
diff --git a/Programming & Language/lint-staged.md b/Programming & Language/lint-staged.md
deleted file mode 100644
index 23c3bcc7..00000000
--- a/Programming & Language/lint-staged.md	
+++ /dev/null
@@ -1,43 +0,0 @@
----
-id: P-REINFORCE-AUTO-D0626D
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - lint-staged"
----
-
-# [[lint-staged]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> `lint-staged`는 Git의 커밋 전 단계(pre-commit)에서 스테이징된(staged) 파일들에 대해서만 린터(Linter)나 포매터(Formatter) 등의 특정 명령어를 실행하도록 도와주는 도구입니다 [1, 2]. 전체 코드베이스 대신 변경된 파일만 검사하므로 실행 시간을 대폭 단축시켜 줍니다 [2, 3]. 주로 Husky와 같은 Git 훅(Hook) 관리 도구와 함께 사용되어, 커밋 전에 코드의 품질을 검사하고 문제를 자동으로 수정하여 오류 없는 깔끔한 코드만 저장소에 반영되도록 보장합니다 [4, 5].
-
-## 📖 구조화된 지식 (Synthesized Content)
-* **핵심 기능 및 작동 방식:**
-  * `lint-staged`의 주요 역할은 스테이징된 파일 집합을 가져와 지정된 glob 패턴과 대조한 후, 일치하는 파일에 대해서만 명령어를 실행하는 것입니다 [6].
-  * 기본적으로 수정된 파일의 절대 경로를 작업(task)에 전달하며, 작업을 병렬(concurrently)로 실행합니다 [7, 8].
-  * 코드를 보호하기 위해 작업을 실행하기 전 백업 스태시(stash)를 생성합니다 [9]. 작업(예: 자동 수정)이 성공적으로 완료되면 수정된 내용을 자동으로 다시 스테이징(re-stages) 처리하므로, 명령어에 `git add`를 수동으로 추가할 필요가 없습니다 [9, 10].
-
-* **설정 및 파일 매칭:**
-  * `package.json`, `.lintstagedrc`, 또는 전용 자바스크립트 설정 파일(`.js`, `.mjs`, `.cjs` 등)을 통해 설정할 수 있습니다 [11].
-  * glob 매칭에는 `micromatch`를 사용하며, 슬래시가 없는 패턴은 위치에 상관없이 파일명과 매칭되고 슬래시가 포함된 패턴은 경로 매칭이 적용됩니다 [7].
-  * 단일 파일 세트에 대해 여러 명령어(예: `eslint --fix` 실행 후 `prettier --write` 실행)를 순차적으로 실행하려면 설정에서 배열(array) 구문을 사용하여, 여러 명령어가 동시에 동일한 파일을 수정하여 발생하는 경쟁 상태(Race condition)를 방지할 수 있습니다 [8, 12].
-
-* **고급 설정 및 모노레포(Monorepo) 적용:**
-  * 기본 glob-to-command 매핑이 충분하지 않은 경우, 동적으로 명령어를 구성하거나 파일 목록을 필터링할 수 있는 함수 기반(Function-based) 설정을 사용할 수 있습니다 [13].
-  * 모노레포 환경에 대한 공식적인 권장 사항은 저장소 루트에 `lint-staged`를 설치하고, 규칙이 다르게 적용되어야 하는 패키지마다 별도의 설정 파일을 두는 것입니다 [14]. `lint-staged`는 스테이징된 파일과 가장 가까운 설정 파일을 사용하여 독립적으로 격리된 규칙을 적용합니다 [14].
-  * Turborepo와 같은 환경에서는 루트의 오케스트레이션(orchestration) 설정을 통해, 특정 파일 패턴을 각 패키지의 린팅 규칙과 매핑하여 작업 효율을 높이고 캐싱 기능을 극대화할 수 있습니다 [15-17].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[Husky]], [[ESLint]], [[Prettier]], [[Git Hooks]]
-- **Projects/Contexts:** [[CI/CD 파이프라인 자동화]], [[모노레포(Monorepo) 아키텍처 설정]], [[Turborepo 환경 구성]]
-- **Contradictions/Notes:** 소스에 따르면 `lint-staged`의 명령어 목록에 `git add`를 수동으로 포함하는 것은 피해야 합니다. v10 이후부터는 여러 작업이 동일한 파일을 편집할 때 발생하는 경쟁 상태를 방지하기 위해 도구 자체가 수정 사항을 자동으로 스테이징 처리하기 때문입니다 [9, 18]. 또한, 전체 프로젝트를 검사하도록 설계된 도구(예: `ng lint` 또는 `tsc --noEmit`)를 `lint-staged`를 통해 실행하는 것은 구조적으로 맞지 않으며 지양해야 한다고 명시되어 있습니다 [13, 18].
-
----
-*Last updated: 2026-04-18*
-- Raw Source: [[00_Raw/2026-04-20/lint-staged.md]]
----
diff --git a/Programming & Language/never 타입(never type).md b/Programming & Language/never 타입(never type).md
deleted file mode 100644
index e86ee437..00000000
--- a/Programming & Language/never 타입(never type).md	
+++ /dev/null
@@ -1,34 +0,0 @@
----
-id: P-REINFORCE-AUTO-F56CC2
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - never 타입(never type)"
----
-
-# [[never 타입(never type)]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> `never` 타입은 타입스크립트에서 절대 발생하지 않는 값의 타입을 의미하며, 집합론적으로는 어떠한 값도 포함하지 않는 '공집합(empty set)'으로 기능한다 [1, 2]. 주로 모든 케이스가 처리되었는지 확인하는 철저함 검사(exhaustiveness checking), 오류를 발생시키거나 절대 반환하지 않는 함수의 반환 타입, 그리고 양립할 수 없는 타입들을 교차했을 때 발생하는 타입으로 활용된다 [3-6]. 다른 모든 타입에 할당될 수는 있지만, `never` 자신 외에는 어떤 타입도 `never`에 할당할 수 없는 특성을 지닌다 [7, 8].
-
-## 📖 구조화된 지식 (Synthesized Content)
-- **집합론적 관점(Set Theory):** `never` 타입은 집합론의 공집합(∅)에 해당한다 [2, 9]. 따라서 임의의 타입 `A`에 대해 `A & never = never`, `A | never = A`가 항상 성립한다 [2, 10]. 공집합은 모든 집합의 부분집합이므로 `never extends T`는 언제나 참(true)이지만, `T extends never`는 `T`가 `never`일 때만 참이 된다 [8].
-- **완전성 검사(Exhaustiveness Checking):** 식별 가능한 유니온(Discriminated Unions)을 `switch` 문 등에서 처리할 때, 모든 케이스를 다루었는지 확인하는 데 `never`를 사용한다 [3, 11, 12]. 개발자가 의도한 분기를 제외하고 남은 값을 `never` 타입 변수에 할당하도록 하면, 추후 처리되지 않은 새로운 타입이 유니온에 추가되었을 때 컴파일 타입 에러를 발생시켜 실수를 방지할 수 있다 [12, 13].
-- **초과 속성 검출 및 상호 배타적 속성 모델링:** `never` 타입이 다른 어떤 타입과도 호환되지 않는 특성을 이용해, 특정 속성이 입력되는 것을 원천 차단할 수 있다 [7]. 초과 속성에 `never`를 할당하도록 만들면 런타임 이전의 타입 검사에서 에러를 유발하며 [7, 14], 이를 응용하면 한쪽 타입이 활성화될 때 다른 속성은 `never`로 만들어 혼용을 방지하는 상호 배타적(Exclusive Props) 관계를 구현할 수 있다 [15].
-- **함수 반환 타입(Function Return Type):** 예외(error)를 던지거나 멈추지 않는 무한 루프에 빠져 영원히 완료되지 않는 함수의 반환 타입으로 사용된다 [5, 6]. 이는 단순히 기능 수행 후 아무것도 반환하지 않고 종료되는 함수의 `void` 타입(실제로는 `undefined`를 반환함)과는 뚜렷이 구별된다 [5].
-- **타입 교집합의 결과:** 구조적 타이핑 내에서 교집합(`&`)을 통해 속성을 재귀적으로 병합할 때 충돌이 나거나, `false & true` 및 `null & boolean`과 같이 동시에 만족할 수 없는 양립 불가능한 타입을 교차할 경우 결과적으로 `never` 타입이 생성된다 [4, 9, 16].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[식별 가능한 유니온(Discriminated Unions)]], [[초과 속성 검사(Excess Property Checking)]], [[구조적 타이핑(Structural Typing)]]
-- **Projects/Contexts:** [[switch문 완전성 검사(Exhaustiveness checking)]], [[에러 핸들링 및 무한 루프 함수 설계]], [[상호 배타적 속성(Exclusive Props) 패턴]]
-- **Contradictions/Notes:** 종료 후 반환값이 없는 함수는 `undefined`를 반환하는 것이므로 `void` 타입을 지정해야 하며, `never` 타입은 절대 정상 종료되지 않는 함수에만 사용해야 한다 [5]. 또한 모든 타입의 상위 집합인 `any` 타입과 비교 시, `any extends never`는 `0 | 1`로 평가되어 `any` 타입이 공집합일 가능성도 내포하고 있는 패러독스(역설)적인 성질을 보인다 [17].
-
----
-*Last updated: 2026-04-18*
-- Raw Source: [[00_Raw/2026-04-20/never 타입(never type).md]]
----
diff --git a/Programming & Language/never 타입.md b/Programming & Language/never 타입.md
deleted file mode 100644
index e718901d..00000000
--- a/Programming & Language/never 타입.md	
+++ /dev/null
@@ -1,33 +0,0 @@
----
-id: P-REINFORCE-AUTO-5297D4
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - never 타입"
----
-
-# [[never 타입]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> `never` 타입은 TypeScript에서 결코 발생할 수 없는 값이나 완료되지 않는 상태를 의미하는 타입이다 [1, 2]. 주로 무한 루프나 예외를 던지는 함수의 반환 타입으로 쓰이며, 집합론적으로 '빈 집합'을 나타내어 컴파일러의 완전성 검사(Exhaustiveness checking) 및 엄격한 타입 통제를 구현하는 데 핵심적으로 사용된다 [3, 4].
-
-## 📖 구조화된 지식 (Synthesized Content)
-- **집합론적 의미와 동작 원리:** TypeScript 타입 시스템을 집합으로 접근할 때, `never`는 어떠한 요소도 가지지 않는 '빈 집합(∅)'을 의미한다 [3, 5]. 빈 집합은 모든 집합의 부분집합이므로 `never` 타입은 모든 타입에 할당될 수 있다(즉, `never extends T`는 항상 참이다) [6]. 하지만 반대로 `never` 자신을 제외한 어떤 타입도 `never`에 할당될 수 없다 [6]. 유니온 타입 및 교집합 연산에서는 `A & never = never`, `A | never = A`의 결과를 산출한다 [3, 7].
-- **완전성 검사 (Exhaustiveness Checking):** 식별 가능한 유니온(Discriminated Unions)을 활용할 때, switch문 등에서 모든 분기를 처리했는지 컴파일 타임에 강제하기 위해 사용된다 [4, 8]. 모든 유효한 케이스를 걸러내고 남은 기본(default) 상태를 `never` 타입 변수에 할당하도록 구성하면, 추후 유니온에 새로운 타입이 추가되었을 때 처리하지 않은 케이스가 있다면 컴파일 에러를 발생시켜 안전성을 보장한다 [4, 9].
-- **초과 속성 차단 및 배타적 속성 관리:** 객체 할당 시 예기치 않은 잉여 속성을 잡아내기 위해 특정 속성을 `never`로 선언하는 기법이 쓰인다 [10, 11]. `never`는 어떠한 값과도 호환되지 않으므로, 들어오면 안 되는 속성을 `never`로 매핑하면 값이 전달될 때 타입 에러를 유발하여 잘못된 사용을 막는다 [10, 12]. 이와 유사하게 판별자(discriminant) 없이 상호 배타적인 속성을 설계할 때, 한쪽이 활성화되면 다른 쪽의 속성을 `never` 타입으로 처리하여 섞임 현상을 방지할 수 있다 [13].
-- **함수 반환 타입에서의 활용:** 예외(Error)를 던져 프로그램의 정상 흐름을 중단하거나 무한 루프를 도는 등, 결코 정상적으로 완료되지 않는 함수의 반환 타입으로 명시한다 [2, 14].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[유니온 타입 (Union Types)]], [[식별 가능한 유니온 (Discriminated Unions)]], [[집합론 (Set Theory)]], [[초과 속성 검사 (Excess Property Checking)]]
-- **Projects/Contexts:** [[TypeScript 상태 관리 및 에러 처리 방어 (State Management and Defensive Error Handling)]]
-- **Contradictions/Notes:** `never`와 `void`는 기능적으로 다르다. 함수가 정상적으로 실행을 마치고 아무 값도 반환하지 않는 경우(실제로는 `undefined`를 반환)에는 `void`를 써야 하며, 예외를 던지거나 영원히 종료되지 않아 실행 흐름이 끝에 도달하지 못하는 경우에만 `never`를 사용해야 한다 [2, 14].
-
----
-*Last updated: 2026-04-18*
-- Raw Source: [[00_Raw/2026-04-20/never 타입.md]]
----
diff --git a/Programming & Language/readonly 수식어.md b/Programming & Language/readonly 수식어.md
deleted file mode 100644
index 8f0c010f..00000000
--- a/Programming & Language/readonly 수식어.md	
+++ /dev/null
@@ -1,44 +0,0 @@
----
-id: P-REINFORCE-AUTO-E98170
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - readonly 수식어"
----
-
-# [[readonly 수식어]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-* **컴파일 타임의 불변성 강제**
-  `readonly` 수식어는 속성이 초기화된 후 재할당되거나 수정되는 것을 방지한다 [3]. 구조적 타입 검사 시 해당 속성의 변이(Mutation) 연산을 시그니처에서 배제함으로써, 컴파일러가 값의 수정을 미리 포착해 에러를 발생시킨다 [8]. 
-
-* **`const` 및 `Object.freeze()`와의 차별점**
-  * **대상과 범위:** `const`는 변수 자체의 재할당을 막을 뿐 객체 내부 속성의 변이는 막지 못하지만, `readonly`는 변수가 아닌 객체의 속성(Property)에 직접 적용되어 내용물의 할당을 막는다 [9-11].
-  * **동작 시점과 성능:** `Object.freeze()`는 런타임에 작동하며 성능 비용을 수반하는 반면, `readonly`는 컴파일 타임에만 작동하여 런타임 성능 오버헤드가 전혀 발생하지 않는다 [5, 11, 12].
-
-* **배열과 튜플의 보호**
-  배열이나 튜플의 경우 `readonly T[]` 또는 `ReadonlyArray<T>` 구문을 사용하여 불변으로 만들 수 있다 [13-15]. 이렇게 선언된 배열은 `push()`, `pop()` 등 배열의 내용을 변이시키는 메서드들이 타입 정의에서 완전히 제거되어 안전한 데이터 전달을 보장한다 [15, 16]. 
-
-* **얕은 불변성과 깊은 불변성(Deep Readonly)**
-  `readonly` 키워드나 내장된 `Readonly<T>` 유틸리티 타입은 객체의 최상위 속성만 보호하는 얕은(Shallow) 불변성만 제공하며 중첩된 객체의 변경은 막지 못한다 [17-19]. 완전히 중첩된 구조까지 불변하게 만들려면, 매핑된 타입과 조건부 타입을 결합한 재귀적 유틸리티 타입인 `DeepReadonly<T>`를 별도로 정의하여 사용해야 한다 [18-20].
-
-* **별칭(Aliasing)으로 인한 한계 및 주의점**
-  `readonly` 데이터는 자신을 가리키는 직접적인 참조에 대해서만 불변을 보장한다. 만약 `readonly`가 적용된 데이터를 가변 파라미터를 받는 함수에 전달할 경우 타입 호환성 규칙에 의해 허용될 수 있으며, 이로 인해 별칭(Alias)을 통한 우회적인 객체 변이가 발생할 수 있다 [21, 22]. 이러한 문제를 방지하려면 함수 시그니처 설계 시 파라미터에도 `readonly`를 일관되게 명시해야 한다 [23].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** `[[불변성(Immutability)]]`, `[[ReadonlyArray]]`, `[[Utility Types]]`, `[[구조적 타이핑(Structural Typing)]]`
-- **Projects/Contexts:** `[[상태 관리(State Management) 및 리듀서(Reducers)]]`, `[[API 응답 및 환경 설정 모델링]]`
-- **Contradictions/Notes:** `readonly`는 타입 레벨에서 완벽한 불변성을 보장하는 것처럼 보이지만, TypeScript의 타입 호환성(별칭 문제)으로 인해 파라미터로 넘겨진 곳에서 의도치 않게 값이 변경되는 구멍이 발생할 수 있다 [21]. 또한 중첩된 객체를 기본적으로 보호하지 않으므로 구조가 복잡할 때는 사용자 정의 `DeepReadonly`가 필수적으로 요구된다 [18].
-
----
-*Last updated: 2026-04-18*
-- Raw Source: [[00_Raw/2026-04-20/readonly 수식어.md]]
----
diff --git a/Programming & Language/readonly.md b/Programming & Language/readonly.md
deleted file mode 100644
index 0037113a..00000000
--- a/Programming & Language/readonly.md	
+++ /dev/null
@@ -1,45 +0,0 @@
----
-id: P-REINFORCE-AUTO-92E2DD
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - readonly"
----
-
-# [[readonly]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> `readonly`는 TypeScript에서 객체의 속성이나 배열, 튜플이 초기화된 이후에 수정되지 않도록 방지하는 수식어이자 유틸리티 타입입니다 [1-3]. 변수의 재할당을 막는 `const`와 달리 객체 내부 구조의 불변성을 제어하며, 런타임 오버헤드 없이 컴파일 타임에 오류를 잡아내어 코드의 안정성과 예측 가능성을 높입니다 [2, 4, 5].
-
-## 📖 구조화된 지식 (Synthesized Content)
-* **작동 방식 및 성능:** 
-  `readonly`는 전적으로 컴파일 타임에만 동작하는 기능으로, 컴파일 후 생성된 JavaScript 코드에서는 흔적이 사라집니다 [2, 6]. 따라서 성능에 어떠한 런타임 오버헤드도 주지 않으면서 속성의 불변성을 강제할 수 있습니다 [2, 5, 6]. 
-
-* **객체 및 클래스에서의 활용:** 
-  인터페이스나 타입 별칭, 클래스의 속성에 `readonly`를 지정할 수 있습니다. 클래스에서는 선언 시점이나 생성자(constructor) 내부에서만 초기화가 가능하며, 그 이후에 값을 수정하려고 시도하면 컴파일러가 에러를 발생시킵니다 [7, 8]. 이는 시스템의 고유 식별자(ID)나 환경 설정 값처럼 생명 주기 동안 변하지 않아야 하는 데이터를 보호할 때 유용합니다 [7, 9].
-
-* **배열과 튜플의 보호:** 
-  배열을 `readonly T[]` 또는 `ReadonlyArray<T>`로 선언하면 `push`, `pop`, 요소 직접 재할당 등 배열을 변이시키는 모든 메서드와 작업이 타입 시스템에서 제거되어 안전하게 보호됩니다 [10-12]. 튜플 역시 각 위치의 값을 고정하기 위해 `readonly`를 적용할 수 있습니다 [10].
-
-* **const 및 Object.freeze()와의 비교:**
-  * `const`: 런타임에 변수 자체의 재할당을 방지하지만, 참조된 객체 내부 속성의 변경은 막지 못합니다 [4, 13, 14].
-  * `Object.freeze()`: 런타임에 객체의 얕은 수정을 차단하며 성능 비용이 발생합니다 [5, 14, 15].
-  * `readonly`: 컴파일 타임에 객체/배열 내부 속성의 변경을 타입 레벨에서 차단하여, 실행 전 코드 작성 단계에서 안전을 보장합니다 [4, 5, 14].
-
-* **얕은 불변성(Shallow Immutability)의 한계:** 
-  기본적인 `readonly` 수식어나 `Readonly<T>` 유틸리티 타입은 최상위 레벨의 속성에만 얕게 적용됩니다 [16-18]. 즉, 중첩된 내부 객체는 여전히 수정될 수 있습니다 [17, 18]. 완벽한 깊은 불변성을 원한다면 재귀적으로 속성을 잠그는 커스텀 `DeepReadonly` 유틸리티 타입을 별도로 구현해야 합니다 [17-19].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[const]], [[Object.freeze()]], [[ReadonlyArray]], [[DeepReadonly]], [[Utility Types]]
-- **Projects/Contexts:** [[State Management]], [[Configuration Objects]], [[API Responses]]
-- **Contradictions/Notes:** `readonly`는 데이터 변경을 막는 훌륭한 타입 제어 장치지만, 컴파일러는 `readonly` 데이터를 변경 가능(mutable)한 매개변수를 받는 함수에 전달하는 것(Aliasing)을 허용하므로 이로 인한 우회적 변이(mutation)가 발생할 수 있다는 구조적 맹점을 주의해야 합니다 [20, 21].
-
----
-*Last updated: 2026-04-18*
-- Raw Source: [[00_Raw/2026-04-20/readonly.md]]
----
diff --git a/Programming & Language/satisfies Keyword.md b/Programming & Language/satisfies Keyword.md
deleted file mode 100644
index 9f90132f..00000000
--- a/Programming & Language/satisfies Keyword.md	
+++ /dev/null
@@ -1,35 +0,0 @@
----
-id: P-REINFORCE-AUTO-5B3851
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - satisfies Keyword"
----
-
-# [[satisfies Keyword]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> `satisfies` 키워드는 TypeScript 4.9에 도입된 기능으로, 객체가 특정 타입의 구조적 요구 사항을 준수하는지 검증하면서도 해당 객체 속성들의 구체적인 리터럴 타입(Literal Type)을 그대로 보존하는 역할을 합니다[1-3]. 기존의 타입 어노테이션(`:`)이 구체적인 타입을 일반적인 타입으로 넓혀(Widening) 정밀도를 떨어뜨리거나, 타입 단언(`as`)이 컴파일러의 검증을 우회하여 런타임 에러를 유발할 수 있는 단점들을 모두 해결합니다[4-6]. 이를 통해 개발자는 엄격한 타입 검사와 정밀한 타입 추론의 이점을 동시에 누릴 수 있습니다[1, 7].
-
-## 📖 구조화된 지식 (Synthesized Content)
-* **도입 배경 및 핵심 기능:** 기존 TypeScript에서는 변수에 타입 어노테이션(`:`)을 지정하면 특정한 문자열 리터럴 값이 포괄적인 `string` 타입 등으로 넓혀지는 문제(Widening)가 발생했습니다[4, 8]. 반면 타입 단언(`as`)은 "내가 컴파일러보다 더 잘 안다"는 전제로 작동하여 속성 누락이나 초과를 제대로 검증하지 않습니다[5, 9]. `satisfies` 연산자는 대상 객체가 지정된 인터페이스나 타입에 부합하는지 엄격히 검사하면서도, 컴파일러가 유추한 속성의 구체적인 값을 잃지 않게 보존합니다[1-3, 6].
-* **과잉 속성 검사(Excess Property Checking)와 엄격성 강제:** TypeScript의 구조적 타이핑(Structural Typing) 환경에서는 요구되는 속성만 존재하면 추가적인 속성이 있어도 타입이 호환되는 것으로 간주됩니다[10, 11]. 하지만 백엔드 데이터를 프론트엔드 모델로 매핑하는 등의 상황에서 `satisfies`를 사용하면, 대상 타입에 정의된 속성만이 안전하게 매핑되도록 강제하여 오타나 의도치 않은 잉여 속성을 컴파일 타임에 효과적으로 잡아냅니다[12-14].
-* **주요 활용 패턴:**
-  * **`as const`와의 결합:** `as const satisfies Type` 형태로 사용하면 컴파일 타임의 타입 검증과 런타임의 불변성(Immutability)을 동시에 확보할 수 있습니다[15]. 이는 절대 변경되어서는 안 되는 설정(Configuration) 객체나 룩업(Lookup) 테이블을 정의할 때 완벽한 패턴입니다[7, 15, 16].
-  * **식별 가능한 유니온(Discriminated Unions) 보존:** 식별 가능한 유니온 타입과 함께 사용할 때 판별자(Discriminator)의 리터럴 타입을 유지해주어, 이후 조건문이나 `switch` 문 등에서 정확한 타입 좁히기(Type Narrowing) 및 완전성 검사(Exhaustiveness Checking)가 가능해집니다[8, 16, 17].
-  * **유연성과 안전성의 결합:** `satisfies`는 객체의 필수 속성들을 올바른 타입으로 가지고 있는지 검증하면서도, 타입에 명시되지 않은 추가 속성을 포함하는 것을 차단하지 않아 확장성 있는 객체 구조를 유지할 수 있게 해줍니다(단, 기본 타입 속성명과 비슷한 오타가 발생하면 에러로 포착합니다)[2, 7, 18, 19].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[Type Annotation]], [[Type Assertion]], [[Excess Property Checking]], [[Discriminated Unions]], [[Literal Type]], [[Structural Typing]]
-- **Projects/Contexts:** [[TypeScript 4.9]], [[Data Mapping and Transformation]]
-- **Contradictions/Notes:** TypeScript의 타입 단언(`as`)은 초과 속성이나 잘못된 매핑에 대한 검사를 수행하지 않아 조용한 런타임 에러를 유발할 수 있지만, `satisfies` 키워드는 구조적 타이핑의 유연성을 허용하면서도 지정된 타입에 대해 엄격한 검증(Excess property checks 등)을 수행하므로 타입 캐스팅의 훌륭한 대안이 됩니다[3, 9, 14].
-
----
-*Last updated: 2026-04-18*
-- Raw Source: [[00_Raw/2026-04-20/satisfies Keyword.md]]
----
diff --git a/Programming & Language/satisfies 연산자.md b/Programming & Language/satisfies 연산자.md
deleted file mode 100644
index 1e3ccd74..00000000
--- a/Programming & Language/satisfies 연산자.md	
+++ /dev/null
@@ -1,35 +0,0 @@
----
-id: P-REINFORCE-AUTO-9EE666
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - satisfies 연산자"
----
-
-# [[satisfies 연산자]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> `satisfies` 연산자는 TypeScript 4.9에 도입된 기능으로, 값의 구체적인 타입(예: 리터럴 타입)을 더 넓은 타입으로 잃지 않으면서(widening 방지) 특정 대상 타입의 요구사항을 충족하는지 검증하는 도구이다 [1-3]. 기존의 타입 어노테이션(`:`)과 타입 단언(`as`) 사이의 딜레마를 해결하여, 엄격한 구조적 유효성 검사와 정밀한 타입 추론이라는 두 가지 이점을 동시에 제공한다 [1, 3]. 이를 통해 런타임 에러를 사전에 방지하고 인터페이스 계약을 안전하게 보호하는 '철벽 수비대'의 핵심 기제로 작동한다 [3, 4].
-
-## 📖 구조화된 지식 (Synthesized Content)
-- **타입 안전성과 구체성(Specificity)의 동시 유지:** `satisfies`는 객체가 특정 대상 인터페이스의 필수 요구사항을 충족하는지 확인하면서도, 해당 객체의 구체적인 값(리터럴 타입 등)을 일반적인 타입(예: `string`)으로 확장(Widening)시키지 않고 보존한다 [3, 5, 6]. 이 덕분에 객체를 참조할 때 속성에 대한 정확한 자동 완성 기능을 유지하고 이후 로직에서 더욱 정밀한 타입 추론이 가능해진다 [3, 5, 7].
-- **과잉 속성 체크(Excess Property Checking, EPC)의 한계 극복:** 객체 리터럴을 직접 할당할 때만 과잉 속성 체크가 작동하고 간접 할당 과정에서는 검사가 우회될 수 있는 기존 TypeScript의 취약점을 보완한다 [8]. `satisfies`를 활용하면 간접 할당이나 데이터 매핑 과정에서도 대상 타입에 정의되지 않은 초과 속성이나 오타를 엄격하게 검사하여, 컴파일 시점에 의도치 않은 데이터 유입을 즉시 차단한다 [3, 9, 10].
-- **타입 단언(`as`)의 위험성 배제:** 타입 단언은 컴파일러에게 검사를 강제로 무시하게 만들어 초과 속성이 포함되어도 이를 허용하므로, 예기치 않은 조용한 에러(silent errors)를 유발할 위험이 높다 [11, 12]. 하지만 `satisfies`는 구조가 타겟 타입과 호환되지 않으면 즉각적으로 컴파일 에러를 발생시키므로 훨씬 더 신뢰할 수 있는 타입 방어를 제공한다 [3, 13].
-- **견고한 인터페이스 설계를 위한 활용 패턴:**
-  - **불변성과 검증의 결합:** `as const satisfies` 형태로 결합하여 사용하면, 런타임의 불변성(Immutability)을 보장하면서도 컴파일 타임의 엄격한 유효성 검사까지 모두 통과하는 안전한 설정 객체(Configuration objects)를 설계할 수 있다 [7, 14].
-  - **식별 가능한 유니온(Discriminated Unions) 지원:** 판별자(Discriminator)가 되는 리터럴 타입의 구체성을 보존함으로써, 조건문이나 `switch` 문에서 안전하게 타입을 추론하는 타입 좁히기(Type Narrowing)가 완벽하게 작동하도록 지원한다 [7, 15].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** `[[구조적 타이핑(Structural Typing)]]`, `[[과잉 속성 체크(Excess Property Checking)]]`, `[[타입 단언(Type Assertions)]]`, `[[식별 가능한 유니온(Discriminated Unions)]]`, `[[타입 좁히기(Type Narrowing)]]`
-- **Projects/Contexts:** `[[설정 객체 및 룩업 테이블 설계(Configuration Objects and Lookup Tables)]]`, `[[백엔드-프론트엔드 데이터 변환(Data Transformation between Backend and Frontend)]]`
-- **Contradictions/Notes:** 타입 단언(`as`) 기법은 컴파일러의 과잉 속성 검사를 우회해버리므로 초과 속성이 포함되는 것을 방어하지 못하는 반면, `satisfies` 연산자는 객체 구조에 일치하지 않는 속성이나 오타가 발생한 경우 이를 놓치지 않고 컴파일 에러로 차단한다는 점에서 수비적 안정성의 차이가 극명히 대비된다 [3, 12].
-
----
-*Last updated: 2026-04-18*
-- Raw Source: [[00_Raw/2026-04-20/satisfies 연산자.md]]
----
diff --git a/Programming & Language/ts-brand.md b/Programming & Language/ts-brand.md
deleted file mode 100644
index fecb5e84..00000000
--- a/Programming & Language/ts-brand.md	
+++ /dev/null
@@ -1,32 +0,0 @@
----
-id: P-REINFORCE-AUTO-7A0150
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - ts-brand"
----
-
-# [[ts-brand]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> `ts-brand`는 타입스크립트(TypeScript)에서 브랜디드 타입(Branded Types, 불투명 타입)을 보다 쉽게 생성하고 사용할 수 있도록 돕는 커뮤니티 기반의 유틸리티 패키지입니다 [1, 2]. 이 라이브러리는 타입 브랜드 구성을 위해 미리 작성된 코드를 제공하여, 개발자들이 구조적으로 동일하지만 의미가 다른 타입들을 안전하게 구분할 수 있도록 지원합니다 [2]. 제네릭 `Brand` 타입을 내보내어 브랜딩을 위한 보다 고급화된 기능을 제공하는 것이 특징입니다 [1, 2].
-
-## 📖 구조화된 지식 (Synthesized Content)
-* **브랜디드 타입 생성 지원:** 타입스크립트의 기본 구조적 타이핑(Structural Typing) 환경에서는 구조가 같은 타입(예: 일반 `string`과 `string` 기반의 ID)을 구분하기 어렵습니다. `ts-brand`는 `Brand`라는 제네릭 타입을 내보내어 개발자가 이러한 한계를 극복하고 명명된(nominal) 브랜디드 타입을 쉽게 생성할 수 있도록 해줍니다 [2].
-* **고급 브랜딩 기능 및 유틸리티:** 다른 타입스크립트 유틸리티 라이브러리(예: `utility-types`, `ts-toolbelt`, `ts-essentials`)들도 헬퍼 제네릭을 제공하지만, `ts-brand`는 브랜딩을 위한 더욱 진보된 기능을 구체적으로 제공합니다 [1]. 예를 들어, `make`와 같은 함수를 통해 타입 브랜드 어서션(assertion) 등을 수행할 수 있는 기능을 포함하고 있습니다 [3].
-* **생태계 내의 위치:** 타입스크립트는 기본적으로 브랜디드 타입을 내장 지원하지 않으므로, 이 패턴을 도입하고자 하는 개발자들은 `ts-brand`나 `Effect TS`와 같은 커뮤니티 라이브러리를 주로 활용하게 됩니다 [2, 4]. 이 라이브러리들은 복잡한 타입 설정 코드를 공유 패키지 형태로 단순화해 줍니다 [2].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[Branded Types]], [[Opaque Types]], [[Structural Typing]], [[Effect TS]]
-- **Projects/Contexts:** [[TypeScript Community Libraries]], [[Type Safety Optimization]]
-- **Contradictions/Notes:** `ts-brand`를 활용한 브랜디드 타입 패턴은 프로그램의 타입 안정성을 높여주지만, 동시에 코드의 개념적 복잡성을 증가시키는 단점이 있습니다 [5, 6]. 따라서 단순한 유니언(Union), 열거형(Enum) 등 덜 복잡한 대안으로도 요구사항을 충족할 수 있는지 도입 전 트레이드오프(trade-off)를 신중히 고려해야 합니다 [5-7].
-
----
-*Last updated: 2026-04-18*
-- Raw Source: [[00_Raw/2026-04-20/ts-brand.md]]
----
diff --git a/Programming & Language/ts-pattern.md b/Programming & Language/ts-pattern.md
deleted file mode 100644
index acedd5a1..00000000
--- a/Programming & Language/ts-pattern.md	
+++ /dev/null
@@ -1,32 +0,0 @@
----
-id: P-REINFORCE-AUTO-ED6DC8
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - ts-pattern"
----
-
-# [[ts-pattern]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-- **도입 배경 및 주요 이점:** TypeScript 환경에서 조건이 겹치거나 새로운 타입이 추가될 때, 기존 분기문에서 이를 고려하지 않으면 버그가 발생하기 쉽습니다 [1]. `ts-pattern`은 이를 해결하기 위해 하나의 간결한 표현식으로 복잡한 분기를 처리하게 해줍니다 [1]. 특히 `.exhaustive()`와 같은 메서드를 사용하면 조건에서 처리되지 않은 예외 케이스를 컴파일러가 사전에 감지하고 타입 에러를 띄워주기 때문에, 코드를 매우 안전하게 유지할 수 있습니다 [3].
-- **성능적 한계와 원인:** 벤치마크 지표에 따르면 `ts-pattern`의 주요 메서드들(`.exhaustive()`, `.otherwise()`, `.run()`)은 자바스크립트의 기본 `if/else`, `switch`, 삼항 연산자에 비해 초당 연산 속도가 약 99% 더 느리다는 결과가 있습니다 [2]. 이는 입력 타입의 가능한 모든 경우를 사전에 계산하고, 내부적으로 클래스 기반의 패턴 매칭과 `this`를 활용한 함수 체이닝으로 상태를 공유하기 때문에, 자바스크립트 엔진에 최적화된 기본 분기문보다 성능이 떨어지게 됩니다 [3]. 
-- **대안 및 적용 전략:** 성능 문제와 오버엔지니어링을 피하기 위해서는 `ts-pattern`을 무조건적으로 사용하기보다는 상황에 맞게 적용해야 합니다 [3]. 단순한 분기 로직에서는 `early return` 패턴을 쓰거나, `switch` 문에 `satisfies` 키워드를 결합하여 처리되지 않은 케이스를 타입 시스템으로 방어하는 것이 더 효율적입니다 [4]. JSX 영역 내에서도 라이브러리 의존 없이 즉시 실행 함수 표현(IIFE)이나 `SwitchCase` 같은 추상화 컴포넌트를 활용해 선언적이고 안전한 분기 처리를 구현할 수 있습니다 [5].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[Pattern Matching]], [[Type Inference]], [[TC39]], [[Discriminated Unions]]
-- **Projects/Contexts:** [[TypeScript 조건부 분기 처리 및 상태 관리]]
-- **Contradictions/Notes:** 일부 벤치마크는 `ts-pattern`이 `if/else`보다 약 99% 느리다고 주장하지만 [2], 개발자 커뮤니티(댓글)에서는 이 벤치마크가 순수한 `ts-pattern` 성능이 아닌 외부의 객체 생성 시간(Object Creation Time)을 포함했거나, 벤치마크 툴 자체의 메모리 간섭 문제로 인해 차이가 크게 과장되었다는 반론을 제기합니다. 실제로는 1~2배 수준의 차이에 불과하여, 납득할 수 있는 성능 차이이므로 가독성과 타입 안정성을 위해 충분히 사용할 만하다는 상반된 의견이 존재합니다 [6, 7].
-
----
-*Last updated: 2026-04-18*
-- Raw Source: [[00_Raw/2026-04-20/ts-pattern.md]]
----
diff --git a/Programming & Language/useEffect 클린업(Cleanup).md b/Programming & Language/useEffect 클린업(Cleanup).md
deleted file mode 100644
index 70c2852e..00000000
--- a/Programming & Language/useEffect 클린업(Cleanup).md	
+++ /dev/null
@@ -1,35 +0,0 @@
----
-id: P-REINFORCE-AUTO-55865D
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - useEffect 클린업(Cleanup)"
----
-
-# [[useEffect 클린업(Cleanup)]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> `useEffect` 훅 내부에서 반환(return)하는 클린업 함수는 컴포넌트가 화면에서 사라질 때(Unmount) 또는 다음 이펙트가 실행되기 전에 호출되어, 불필요하게 남아있는 백그라운드 작업이나 자원 점유를 해제함으로써 **애플리케이션의 메모리 누수(Memory Leak)를 방지하는 핵심 메커니즘**입니다.
-
-## 📖 구조화된 지식 (Synthesized Content)
-**1. 클린업의 필요성과 메모리 누수 방지** React 컴포넌트가 언마운트되더라도, `useEffect` 내에서 실행된 타이머, 이벤트 리스너, 외부 네트워크 연결 등은 자동으로 종료되지 않습니다. 클린업 작업을 누락하면 컴포넌트가 파괴된 후에도 숨겨진 백그라운드에서 이벤트가 계속 수신되거나 연산이 실행되어, **시간이 지날수록 메모리 점유율이 증가하고 결국 앱을 느려지게 하거나 크래시를 유발**합니다.
-
-**2. 주요 클린업 대상 및 적용 사례** 성능 저하를 막기 위해 다음과 같은 상황에서 반드시 클린업 함수를 작성해야 합니다.
-
-- **타이머 및 애니메이션 프레임 해제:** `setInterval`을 호출했다면 클린업에서 `clearInterval`을 실행하고, 게임 루프 등을 위해 `requestAnimationFrame`을 사용했다면 `cancelAnimationFrame`을 호출하여 백그라운드 동작을 멈춰야 합니다.
-- **이벤트 리스너 제거:** `window.addEventListener('resize', handleResize)`나 `mousemove` 이벤트를 등록했다면, 반드시 `window.removeEventListener`로 구독을 해제해야 렌더링되지 않는 컴포넌트에서 이벤트 핸들러가 실행되는 것을 막을 수 있습니다.
-- **외부 네트워크 및 워커 종료:** 웹소켓(WebSocket)이나 웹 워커(Web Worker) 인스턴스를 생성했다면, 연결이 열린 채로 메모리를 낭비하지 않도록 클린업 시점에 `ws.close()`나 `worker.terminate()`를 호출해야 합니다.
-- **거대한 객체 참조 해제 (GC 지원):** `useRef` 등을 사용해 거대한 데이터 세트 등 큰 객체를 참조하고 있다면, 언마운트 시 명시적으로 참조에 `null`을 할당(`processedRef.current = null`)하여 자바스크립트 가비지 컬렉터(GC)가 해당 메모리를 정상적으로 회수할 수 있도록 처리해야 합니다.
-- **WebGL 및 GPU 자원 해제 (Three.js/R3F):** 일반적인 힙 메모리와 달리 GPU 메모리에 올라간 자원들은 자동으로 가비지 컬렉션되지 않습니다. 따라서 React Three Fiber 등에서 생성한 3D 모델의 컴포넌트가 사라질 때는, 클린업 함수에서 명시적으로 지오메트리, 재질, 텍스처 등에 대해 `.dispose()` 메서드를 호출하여 VRAM 누수를 방지해야 합니다.
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[Memory Leak Prevention (메모리 누수 방지)]], [[반응형 윈도우 리사이즈(Resize) 이벤트 처리]], [[웹 워커(Web Worker)]], [[Three.js 자원 해제 (Dispose)]]
-- **Projects/Contexts:** [[고성능 실시간 상호작용 시스템]], [[멀티스레드 기반 웹 애플리케이션]]
-- **Contradictions/Notes:** React 18의 Strict Mode(개발 환경)에서는 컴포넌트가 의도적으로 한 번 더 마운트/언마운트되는 과정을 거칩니다. 이 과정에서 클린업 함수가 제대로 구현되어 있지 않으면 예기치 않은 이중 실행(예: 두 번 연결되는 웹소켓 등) 버그를 조기에 발견할 수 있으므로, 정확한 클린업 작성은 안정적인 React 앱 설계의 필수 조건입니다.
-- Raw Source: [[00_Raw/2026-04-20/useEffect 클린업(Cleanup).md]]
----
diff --git a/Programming & Language/가비지 컬렉션 (Garbage Collection).md b/Programming & Language/가비지 컬렉션 (Garbage Collection).md
deleted file mode 100644
index db85d805..00000000
--- a/Programming & Language/가비지 컬렉션 (Garbage Collection).md	
+++ /dev/null
@@ -1,46 +0,0 @@
----
-id: P-REINFORCE-AUTO-51196C
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - 가비지 컬렉션 (Garbage Collection)"
----
-
-# [[가비지 컬렉션 (Garbage Collection)]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 가비지 컬렉션(GC)은 애플리케이션에서 더 이상 필요하지 않거나 도달할 수 없는 객체가 차지한 메모리 영역을 식별하고 자동으로 회수하여 재사용할 수 있도록 하는 메모리 관리 프로세스입니다 [1, 2]. 프로그래머가 직접 메모리를 할당하고 해제해야 하는 복잡성을 줄여주고 메모리 누수와 같은 오류를 방지하는 데 도움을 줍니다 [3]. 하지만 메모리 관리에 대한 통제권을 잃게 되며, 시스템 실행을 멈추게 하는 예측 불가능한 일시 정지(Stop-The-World)를 유발할 수 있는 양날의 검과 같은 특성을 가집니다 [2-4].
-
-## 📖 구조화된 지식 (Synthesized Content)
-- **도달 가능성(Reachability)과 생존 객체 식별**
-  가비지 컬렉터는 '도달 가능성'을 객체 생존의 지표로 사용합니다 [5]. 전역 객체, 로컬 변수(스택), 웹 브라우저의 DOM 요소 등과 같은 루트(Root) 객체이거나, 다른 생존 객체로부터 참조(Pointer) 체인을 통해 도달할 수 있는 객체는 '생존(live)' 상태로 간주됩니다 [1, 6, 7]. 반면 루트에서 도달할 수 없는 모든 객체는 '죽은(dead)' 객체, 즉 가비지로 분류되어 메모리가 회수됩니다 [1, 6, 8, 9].
-
-- **세대별 가설과 힙(Heap) 메모리 구조**
-  대부분의 객체는 생성된 직후 금방 죽는다는 '세대별 가설(Generational Hypothesis)'에 기반하여, V8과 같은 최신 엔진은 힙 메모리를 여러 세대로 분할합니다 [10-12]. 객체는 처음 매우 작고 할당이 빠른 '젊은 세대(Young Generation/New-space)'에 할당되며, 이곳에서 여러 번의 가비지 컬렉션 주기를 살아남은 객체만이 크기가 큰 '오래된 세대(Old Generation/Old-space)'로 승격(Promotion)됩니다 [10, 11, 13, 14].
-
-- **마이너 GC (Minor GC / Scavenge 연산)**
-  젊은 세대의 메모리를 관리하기 위해 Scavenge(또는 Copy forward) 알고리즘이 자주 그리고 빠르게 실행됩니다 [15-18]. 이 알고리즘은 공간을 두 개의 동일한 반공간(From-space와 To-space)으로 나누어, 생존한 객체를 To-space로 복사하거나 오래된 세대로 승격시킨 후, From-space 전체를 비워버립니다 [15, 19-22]. 이 과정에서 객체들이 연속된 공간에 압축되므로 메모리 파편화가 방지됩니다 [15, 20, 21].
-
-- **메이저 GC (Major GC / Mark-Sweep-Compact)**
-  오래된 세대를 수집할 때는 Mark-Sweep 및 Mark-Compact 알고리즘이 사용됩니다 [5, 23, 24]. 
-  * **마킹(Marking):** GC가 루트부터 객체 그래프를 깊이 우선 탐색(DFS)으로 추적하여 생존 객체를 식별합니다. 이때 객체는 발견 상태에 따라 흰색(미발견), 회색(발견되었으나 이웃 미처리), 검은색(완전 처리됨)으로 표시됩니다 [7, 25-27].
-  * **스윕(Sweeping):** 마킹되지 않은 죽은 객체의 범위를 스캔하여 빈 공간(Free list)으로 변환하고 회수합니다 [27-29].
-  * **압축(Compacting):** 메모리 파편화를 줄이기 위해 살아남은 객체들을 조각난 페이지에서 다른 페이지의 빈 공간으로 이주(Migration)시켜 모아줍니다 [2, 27, 30, 31].
-
-- **성능 최적화 기법 (지연 최소화)**
-  과거 전통적인 GC 방식은 전체 애플리케이션 실행을 멈추는 'Stop-The-World' 일시 정지가 길어지는 문제가 있었습니다 [2, 32]. 이를 개선하기 위해 V8의 Orinoco 가비지 컬렉터 등은 메인 스레드와 헬퍼 스레드가 동시에 작업을 나누어 수행하는 **병렬(Parallel)** 처리, 메인 스레드의 JavaScript 실행 사이사이에 GC 작업을 작은 단위로 쪼개서 수행하는 **점진적(Incremental)** 처리, 그리고 메인 스레드 실행을 방해하지 않고 백그라운드에서 GC를 동시에 수행하는 **동시(Concurrent)** 기법을 도입하여 지연(Latency)과 버벅거림을 획기적으로 줄였습니다 [33-38].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[메모리 누수 (Memory Leak)]], [[힙 메모리 (Heap Memory)]], [[V8 엔진 (V8 Engine)]], [[Stop-The-World]]
-- **Projects/Contexts:** [[V8 Orinoco 프로젝트]], [[Node.js]], [[IBM Eclipse OpenJ9]]
-- **Contradictions/Notes:** 가비지 컬렉션은 프로그래머에게서 수동 메모리 관리에 대한 부담을 덜어주어 대규모 애플리케이션의 메모리 누수나 오류를 획기적으로 줄여주는 장점이 있지만, 메모리 관리 시점에 대한 제어권을 잃게 되며 C/C++ 같은 언어와 비교할 때 포인터를 식별하고 마킹하는 등 런타임 오버헤드를 발생시킨다는 단점도 공존합니다 [3, 4].
-
----
-*Last updated: 2026-04-19*
-- Raw Source: [[00_Raw/2026-04-20/가비지 컬렉션 (Garbage Collection).md]]
----
diff --git a/Programming & Language/가비지 컬렉션(Garbage Collection).md b/Programming & Language/가비지 컬렉션(Garbage Collection).md
deleted file mode 100644
index dcbf7b56..00000000
--- a/Programming & Language/가비지 컬렉션(Garbage Collection).md	
+++ /dev/null
@@ -1,30 +0,0 @@
----
-id: P-REINFORCE-AUTO-F0509C
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - 가비지 컬렉션(Garbage Collection)"
----
-
-# [[가비지 컬렉션(Garbage Collection)]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 가비지 컬렉션(GC)은 프로그램에서 더 이상 참조되거나 도달할 수 없는 객체가 차지하는 메모리 영역을 식별하고 이를 자동으로 회수하는 메모리 관리 프로세스입니다 [1-3]. V8과 같은 모던 자바스크립트 엔진에서 GC는 스택 변수나 글로벌 객체와 같은 루트 노드로부터 도달 가능성(reachability)을 기준으로 살아있는 객체를 판별합니다 [1, 4]. 프로그래머의 명시적인 메모리 관리 부담을 덜어주지만, 메모리 할당 실패 시점과 힙의 상태 변화가 GC 로그를 통해 기록되므로 이를 분석하는 것은 애플리케이션의 메모리 누수 방지 및 성능 최적화에 필수적입니다 [5-7].
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[새로운 공간(New Space)]], [[오래된 공간(Old Space)]], [[스캐빈저(Scavenger)]], [[마크-스위프(Mark-Sweep)]], [[메모리 누수(Memory Leak)]], [[할당 타임라인(Allocation Timeline)]], [[오리노코(Orinoco GC)]]
-- **Projects/Contexts:** [[V8 엔진의 메모리 관리 아키텍처 및 Orinoco 프로젝트]], [[Chrome DevTools 메모리 프로파일링 및 힙 스냅샷 분석]]
-- **Contradictions/Notes:** 과거 전통적인 가비지 컬렉터는 'Stop-the-world' 방식의 순차적 처리를 사용하여 메인 스레드를 멈추고 지연을 발생시켰으나, 최신 V8의 Orinoco 가비지 컬렉터는 동시적(Concurrent), 병렬적(Parallel) 작업을 도입하여 애플리케이션(자바스크립트) 실행을 차단하지 않고 백그라운드에서 마킹과 스위핑을 수행하도록 개선되었습니다 [18, 33-35].
-
----
-*Last updated: 2026-04-19*
-- Raw Source: [[00_Raw/2026-04-20/가비지 컬렉션(Garbage Collection).md]]
----
diff --git a/Programming & Language/가비지 컬렉터(Garbage Collector).md b/Programming & Language/가비지 컬렉터(Garbage Collector).md
deleted file mode 100644
index 386bf51d..00000000
--- a/Programming & Language/가비지 컬렉터(Garbage Collector).md	
+++ /dev/null
@@ -1,42 +0,0 @@
----
-id: P-REINFORCE-AUTO-A11817
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - 가비지 컬렉터(Garbage Collector)"
----
-
-# [[가비지 컬렉터(Garbage Collector)]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 가비지 컬렉터(Garbage Collector, GC)는 프로그램에서 더 이상 사용되지 않는 메모리(Dead regions)를 자동으로 식별하여 운영체제나 새로운 객체 할당을 위해 재사용하도록 수거하는 메모리 관리 메커니즘입니다 [1, 2]. 스택 변수나 전역 객체와 같은 '루트(Root) 객체'에서부터 포인터 체인을 통해 도달할 수 있는 객체는 '활성(Live)' 상태로 간주하고, 도달할 수 없는 모든 객체는 가비지로 판단합니다 [1, 3, 4]. 개발자가 메모리를 명시적으로 관리할 필요성을 덜어주는 장점이 있지만, 메모리 관리에 대한 제어권을 잃게 되고 실행을 멈추게 하는 예측 불가능한 지연(Pause)을 유발할 수 있는 양날의 검과 같습니다 [5, 6].
-
-## 📖 구조화된 지식 (Synthesized Content)
-- **가비지 컬렉션의 기본 원리와 객체 탐색**
-  가비지 컬렉션의 핵심 과제는 메모리의 죽은 영역을 식별하는 것입니다 [1]. GC는 루트 객체에서 시작하여 객체 간의 참조(Pointer)를 추적(Trace)하는 방식을 사용합니다 [3, 7]. V8 엔진의 경우, 힙 내의 데이터와 포인터를 빠르게 식별하기 위해 단어(Word)의 마지막 비트를 플래그로 활용하는 'Tagged pointers(태그된 포인터)' 기법을 사용합니다 [8, 9].
-
-- **세대적 가설에 기반한 가비지 컬렉션 (Generational Garbage Collection)**
-  대부분의 언어 환경에서는 "대부분의 객체는 생성 직후 빠르게 죽는다"는 세대적 가설(Generational Hypothesis)이 성립합니다 [10, 11]. 이를 활용하여 힙 메모리를 'Young Generation(신규 세대)'과 'Old Generation(구세대)'으로 분리하여 관리합니다 [12, 13].
-  - **Minor GC (Scavenger):** V8 엔진의 신규 공간(New Space)에서 자주 발생하며 매우 빠르게 실행됩니다 [12, 14, 15]. 신규 공간을 두 개의 반공간(To-Space, From-Space)으로 나누고, 살아있는 객체만 새로운 공간으로 대피(Evacuation)시켜 파편화를 제거하는 알고리즘(Cheney's algorithm 등)을 사용합니다 [14-16]. 이 과정을 두 번 이상 살아남은 객체는 구세대 공간으로 승격(Promote)됩니다 [12, 17].
-  - **Major GC (Mark-Sweep-Compact):** 구세대 공간에 쌓인 대규모 데이터를 수집할 때 사용됩니다 [18]. 전체 힙에서 살아있는 객체를 깊이 우선 탐색(DFS)으로 탐색하여 표시(Mark)하고, 죽은 객체가 차지한 공간을 청소(Sweep)하여 빈 목록(Free list)으로 반환합니다 [18-21]. 파편화가 심한 페이지의 경우 살아있는 객체를 모아 메모리를 압축(Compact)하기도 합니다 [21, 22].
-
-- **성능 최적화 및 최신 GC 기법**
-  가비지 컬렉션 작업은 기본적으로 애플리케이션 실행을 완전히 멈추는 "Stop-the-world" 지연을 유발합니다 [2, 23]. 응답성 저하를 방지하기 위해 V8 엔진(Orinoco GC)이나 IBM JVM 등은 다음과 같은 발전된 기법을 사용합니다.
-  - **병렬 처리(Parallel):** 메인 스레드와 여러 헬퍼 스레드가 GC 작업을 분담하여 동시에 수행하여 전체 지연 시간을 단축합니다 [24, 25].
-  - **점진적 처리(Incremental):** 긴 GC 작업을 여러 개의 짧은 단계(Step)로 쪼개어, 메인 스레드에서 JavaScript 실행과 교차(Interleave)로 수행합니다 [24, 26, 27].
-  - **동시 처리(Concurrent):** 메인 스레드가 JavaScript를 계속 실행하는 동안, 백그라운드의 헬퍼 스레드가 마킹 및 스위핑 작업을 온전히 수행합니다 [24, 26, 28].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[Generational Hypothesis]], [[Mark-Sweep-Compact]], [[Scavenge]], [[Stop-the-world]]
-- **Projects/Contexts:** [[V8 Engine]], [[Orinoco Garbage Collector]], [[IBM Eclipse OpenJ9]]
-- **Contradictions/Notes:** 소스에 따르면 V8 엔진은 메모리 효율을 높이기 위해 포인터 압축(Pointer compression) 기술을 도입했는데, 이는 메모리와 성능 최적화에는 크게 기여하지만 64비트 시스템 환경에서도 V8의 최대 힙 크기를 4GB로 제한하게 만드는 부작용(Downside)을 초래합니다 [29, 30].
-
----
-*Last updated: 2026-04-19*
-- Raw Source: [[00_Raw/2026-04-20/가비지 컬렉터(Garbage Collector).md]]
----
diff --git a/Programming & Language/가상현실 멀미 (VR Sickness).md b/Programming & Language/가상현실 멀미 (VR Sickness).md
deleted file mode 100644
index c7289924..00000000
--- a/Programming & Language/가상현실 멀미 (VR Sickness).md	
+++ /dev/null
@@ -1,36 +0,0 @@
----
-id: P-REINFORCE-AUTO-9DED54
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - 가상현실 멀미 (VR Sickness)"
----
-
-# [[가상현실 멀미 (VR Sickness)]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 가상현실 멀미(VR Sickness)는 헤드마운트 디스플레이(HMD)와 같은 가상현실 기기를 사용할 때 다수의 사용자가 경험하는 메스꺼움, 방향 감각 상실, 시각적 장애 등의 부작용을 의미합니다 [1, 2]. 이 현상의 정확한 발병 원인에 대해서는 학계의 완전한 합의가 이루어지지 않았으나, 가상 환경과 실제 신체 경험 간의 시각-전정 감각 충돌(visual-vestibular conflict)이 주요 원인으로 지목되고 있습니다 [3]. 가상현실 멀미는 사용자의 몰입감과 즐거움을 저하시키고 과제 수행 능력에 부정적인 영향을 미칩니다 [2].
-
-## 📖 구조화된 지식 (Synthesized Content)
-* **발병 원인 및 메커니즘:** 가상현실 멀미의 가장 유력한 발생 이론은 시각적 경험과 물리적 신체 경험이 일치하지 않을 때 발생하는 시각-전정 감각의 충돌입니다 [3]. 이와 같은 감각 통합의 교란은 사용자에게 메스꺼움이나 방향 감각 상실을 초래할 수 있습니다 [3]. 또한 HMD 기기 사용 시 흔히 나타나는 양안 수렴-조절 불일치(vergence-accommodation conflicts) 역시 눈의 피로를 유발하며 안구 운동과 관련된 멀미 증상의 주된 원인으로 작용합니다 [3].
-* **주요 증상 및 파급 효과:** 멀미의 증상은 크게 메스꺼움 계열, 안구 운동 장애 계열, 방향 감각 상실 계열로 분류됩니다 [4]. 이러한 증상들은 사용자가 가상현실 내에서 느끼는 존재감(presence)을 깨뜨리고 동기를 저하시켜 결과적으로 평균 15.6%에 이르는 높은 사용자 이탈률(dropout rate)을 유발하는 것으로 나타납니다 [2].
-* **멀미 발생 및 악화 요인:**
-  * **콘텐츠 및 기기 특성:** 카메라의 움직임, 사용자의 물리적 모션, 그리고 방향 감각을 상실하게 만드는 콘텐츠 요소가 멀미를 유발할 수 있습니다 [5]. 특히 엑서게임(exergames)과 같이 신체 활동과 고도의 시각적 자극이 요구되는 콘텐츠는 멀미 발생과 밀접한 연관이 있습니다 [6, 7].
-  * **가상현실 노출 시간:** 가상현실 환경에 머무는 시간은 멀미 증상의 발달과 심각도에 결정적인 역할을 합니다 [8].
-  * **개인차:** 사용자의 연령, HMD 착용 상태의 적합성, 자세 안정성, 그리고 개인의 멀미 민감도 등은 증상 발현에 영향을 미칩니다 [9]. 특히 짧은 노출 시간에도 심각한 멀미 증상을 겪은 사용자는 더 긴 노출 환경에서 유사하거나 더 악화된 증상을 경험할 가능성이 높습니다 [9].
-* **사후 효과(Aftereffects) 및 회복:** 기기 사용을 종료하더라도 증상은 즉시 사라지지 않고 서서히 감소하며, 초기 증상이 심각했던 사용자일수록 회복에 더 오랜 시간이 소요됩니다 [10]. 또한 사용 후 최대 24시간이 지난 뒤에 잠복성 증상(두통, 피로 등)이 발생할 수도 있기 때문에, 증상이 나타나면 완전히 회복될 때까지 기기 사용을 중단하고 대기하는 것이 권장됩니다 [10-12].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[시각-전정 감각 충돌 (Visual-Vestibular Conflict)]], [[양안 수렴-조절 불일치 (Vergence-Accommodation Conflict)]]
-- **Projects/Contexts:** [[엑서게임 (Exergaming)]], [[헤드마운트 디스플레이 (HMD)]]
-- **Contradictions/Notes:** 가상현실 멀미의 발병 원인(etiology)에 대해 아직 학계의 완전한 합의(consensus)는 존재하지 않습니다 [3]. 또한, 노출 시간과 멀미 심각도의 관계가 항상 선형적이지는 않다는 점도 관찰됩니다. 10분 미만 노출보다 10~20분 노출에서 증상이 더 심하게 나타나지만, 20분 이상 노출된 연구에서는 오히려 10~20분 노출보다 증상이 덜 심각하게 보고되는 상반된 양상이 발견되기도 합니다(이는 360도 비디오, 게임, 정적 풍경 등 연구에 사용된 콘텐츠 유형의 분포 차이에 기인한 것으로 추정됩니다) [8].
-
----
-*Last updated: 2026-04-19*
-- Raw Source: [[00_Raw/2026-04-20/가상현실 멀미 (VR Sickness).md]]
----
diff --git a/Programming & Language/가상현실 멀미(VR Sickness).md b/Programming & Language/가상현실 멀미(VR Sickness).md
deleted file mode 100644
index 7f60062f..00000000
--- a/Programming & Language/가상현실 멀미(VR Sickness).md	
+++ /dev/null
@@ -1,40 +0,0 @@
----
-id: P-REINFORCE-AUTO-DE69FA
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - 가상현실 멀미(VR Sickness)"
----
-
-# [[가상현실 멀미(VR Sickness)]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-**원인 및 증상의 발현**
-가상현실 멀미는 기본적으로 현실 세계와 가상 세계의 불일치로 인한 시각 및 전정 기관의 통합 장애 현상으로 인해 발생합니다 [3]. 주요 증상인 메스꺼움이나 방향 감각 상실은 사용자의 몰입도와 즐거움을 떨어뜨리고, 가상현실 내에서의 작업 수행 능력(task performance)을 저하시키는 핵심적인 원인으로 작용합니다 [2]. 또한, 노출 시간이 길어질수록, 특히 단시간 노출 후 심한 증상을 경험했던 사용자의 경우 장시간 노출 시 더 높거나 심각한 수준의 멀미 증상을 겪을 가능성이 큽니다 [4, 5].
-
-**시각적 후유증 (Visual Aftereffects)**
-HMD 기기의 특성상 발생하는 폭주-조절 불일치(vergence-accommodation conflict)는 안구 운동(oculomotor) 증상 및 시각적 피로의 주된 원인이 됩니다 [3]. VR 사용 직후 사용자의 시야 조절(accommodation)과 폭주(convergence) 기능에 상당한 변화가 발생하며, 이로 인해 두통, 눈의 뻐근함, 복시(double vision)와 같은 시각적 불확실성이 유발될 수 있습니다 [6]. 이러한 시각적, 안구운동 변화의 대부분은 VR 환경에서 빠져나온 후 40분이 지나면 기준치 수준으로 회복되는 단기적 성향을 보이지만, 일부 사용자에게 나타나는 큰 폭의 변화는 현실 세계에서의 깊이 지각에 일시적인 지장을 초래할 위험이 있습니다 [4, 6].
-
-**인지적 후유증 (Cognitive Aftereffects)**
-가상현실 멀미를 경험한 사용자는 상황 자극에 대처하는 의사결정 속도(decision speed)와 운동 이동 속도(movement speed) 등 반응 시간(reaction time)에 영향을 받을 수 있습니다 [7]. 실험 관찰 결과, VR 노출 직후 의사결정 시간이나 움직임 개시 소요 시간에 미세한 변동이 확인되기도 하지만, 이는 일시적이며 40분 이내에 본래의 상태로 회복됩니다 [8, 9]. 
-
-**지속 시간 및 사용자 안전 고려사항**
-일반적인 그룹 통계상으로는 10분 또는 50분 등 VR 노출 시간과 관계없이 가상현실 종료 후 40분(Late test period)이 경과하면 시각적, 인지적, 주관적 멀미 증상이 대부분 기준치로 돌아옵니다 [4, 10]. 그러나 약 14%의 사용자는 50분간의 VR 사용 후 40분이 지난 시점에서도 여전히 높은 수준의 멀미를 보고하였으며, 사람에 따라 최대 24시간 이후에 나타나는 지연성 증상(latent symptoms)을 경험하기도 합니다 [4, 10, 11]. 따라서 가상현실 사용자는 안전을 위해 VR 기기 사용을 종료한 후 즉시 운전과 같이 부상 위험이 수반되는 활동을 피하고, 후유증이 완전히 사라질 때까지 대기 시간을 가져야 합니다 [12].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[시각-전정 충돌(Visual-vestibular conflict)]], [[폭주-조절 불일치(Vergence-accommodation conflict)]], [[깊이 지각(Depth perception)]], [[반응 시간(Reaction time)]]
-- **Projects/Contexts:** [[Beat Saber를 활용한 VR 엑서게임 후유증 연구(VR Exergaming Aftereffects)]]
-- **Contradictions/Notes:** VR 노출이 사용자의 '반응 시간(Reaction time)'에 미치는 직접적인 영향에 대해 기존 문헌들은 매우 일관되지 않은(highly inconsistent) 결과를 보이고 있습니다. 일부 연구에서는 가상현실 멀미로 인해 반응 시간이 부정적으로 지연된다고 보고하는 반면, 다른 연구에서는 긍정적으로 반응 속도가 빨라진다고 주장합니다 [13].
-
----
-*Last updated: 2026-04-19*
-- Raw Source: [[00_Raw/2026-04-20/가상현실 멀미(VR Sickness).md]]
----
diff --git a/Programming & Language/가상현실 사후 효과 연구(Virtual Reality Aftereffects Study).md b/Programming & Language/가상현실 사후 효과 연구(Virtual Reality Aftereffects Study).md
deleted file mode 100644
index 139366a5..00000000
--- a/Programming & Language/가상현실 사후 효과 연구(Virtual Reality Aftereffects Study).md	
+++ /dev/null
@@ -1,33 +0,0 @@
----
-id: P-REINFORCE-AUTO-52C04C
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - 가상현실 사후 효과 연구(Virtual Reality Aftereffects Study)"
----
-
-# [[가상현실 사후 효과 연구(Virtual Reality Aftereffects Study)]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 가상현실 사후 효과 연구는 사용자가 가상현실(VR) 환경, 특히 엑서게임(Exergame) 등을 체험한 후 겪게 되는 시각적, 인지적 변화와 VR 멀미(VR sickness) 증상을 분석하는 연구입니다 [1]. 노출 시간(예: 10분 대 50분)에 따른 눈의 조절(accommodation) 및 폭주(convergence), 인지 반응 속도, 주관적 멀미 증상의 발생과 회복 양상을 측정합니다 [1]. 연구 결과, 대부분의 사후 효과는 VR 종료 후 40분 이내에 기저 수준으로 회복되지만, 노출 시간의 길이와 개인의 민감도에 따라 증상의 강도와 지속 시간이 크게 달라질 수 있음이 확인되었습니다 [2, 3].
-
-## 📖 구조화된 지식 (Synthesized Content)
-- **시각 및 인지적 사후 효과:** 헤드마운트 디스플레이(HMD)의 사용은 폭주-조절 불일치(vergence-accommodation conflicts)를 유발하여 VR 노출 직후 눈의 초점 조절 및 폭주 기능에 변화를 일으킵니다 [4, 5]. 그러나 이러한 시각적 변화는 10분이나 50분이라는 노출 시간의 길이에 관계없이 VR 종료 40분 후에는 기저 수준으로 완전히 회복되었습니다 [5]. 또한, 의사 결정 속도와 운동 반응 속도를 포함하는 인지적 측면은 VR 노출 직후나 40분 후 모두 유의미한 부정적 영향을 받지 않았습니다 [2, 6].
-- **주관적 VR 멀미(VR Sickness)와 노출 시간의 관계:** 시뮬레이터 멀미 설문지(SSQ)를 통해 측정한 결과, VR 체험 직후 메스꺼움, 안구 운동 장애, 방향 상실 등의 증상이 유의미하게 증가했습니다 [7, 8]. 특히 50분의 장기 노출은 10분의 단기 노출과 비교하여 메스꺼움 증상을 비롯한 전체적인 멀미 수치를 훨씬 더 높게 유발하는 것으로 나타났습니다 [8, 9].
-- **회복 시간 및 개인별 민감도:** 그룹 평균 데이터를 보면 VR 노출 후 40분이 지나면 멀미 증상과 시각적 변화가 모두 기저 수준으로 돌아왔습니다 [8]. 그러나 50분 동안 VR에 노출된 참가자 중 약 14%는 40분이 지난 후에도 여전히 높은 수준의 멀미를 호소하여 사후 효과의 회복에 큰 개인차가 있음이 밝혀졌습니다 [10]. 더 나아가, 짧은 노출(10분)에서 심한 증상을 겪은 사용자는 긴 노출(50분)에서도 심한 증상을 겪을 확률이 매우 높았습니다 [11].
-- **안전 권고 및 실무적 시사점:** 심각한 사후 효과를 예방하기 위해 사용자는 장시간 VR을 사용하기 전 짧은 세션으로 자신의 민감도를 테스트해 보는 것이 권장됩니다 [3]. 또한, VR 기기 사용을 종료한 후 운전과 같이 부상 위험이 따르는 활동을 재개하기 전에는 사후 효과가 완전히 소멸할 수 있도록 최소 40분 이상의 대기 시간을 가져야 합니다 [3].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[VR Sickness (가상현실 멀미)]], [[Vergence-Accommodation Conflict (폭주-조절 불일치)]], [[Exergaming (엑서게이밍)]]
-- **Projects/Contexts:** [[Beat Saber (비트 세이버)를 활용한 가상현실 사후 효과 분석]]
-- **Contradictions/Notes:** 연구 결과에서 그룹 평균적으로는 VR 노출 40분 후 모든 시각적 및 멀미 증상이 기저 수준으로 회복되었다고 나타나지만, 50분 노출군 중 약 14%의 사용자는 40분 후에도 여전히 높은 수준의 멀미를 경험하여 '평균적 회복 양상'과 '개인별 실제 회복' 사이에 모순적인 괴리가 존재합니다 [8, 10]. 또한, 인지적 반응 시간에 대한 기존 문헌들은 VR이 부정적인 영향을 미친다는 결과와 오히려 긍정적인 영향을 미친다는 결과가 혼재되어 일관성이 부족하나, 본 연구에서는 인지 능력에 유의미한 영향이 없는 것으로 나타났습니다 [6, 12].
-
----
-*Last updated: 2026-04-19*
-- Raw Source: [[00_Raw/2026-04-20/가상현실 사후 효과 연구(Virtual Reality Aftereffects Study).md]]
----
diff --git a/Programming & Language/가상현실 엑서게임 후유증 연구(VR Exergaming Aftereffects Study).md b/Programming & Language/가상현실 엑서게임 후유증 연구(VR Exergaming Aftereffects Study).md
deleted file mode 100644
index 2888fdd3..00000000
--- a/Programming & Language/가상현실 엑서게임 후유증 연구(VR Exergaming Aftereffects Study).md	
+++ /dev/null
@@ -1,38 +0,0 @@
----
-id: P-REINFORCE-AUTO-DE15F3
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - 가상현실 엑서게임 후유증 연구(VR Exergaming Aftereffects Study)"
----
-
-# [[가상현실 엑서게임 후유증 연구(VR Exergaming Aftereffects Study)]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 가상현실(VR) 엑서게임 후유증 연구는 인기 VR 게임인 '비트 세이버(Beat Saber)'를 활용하여 단기 및 장기 VR 노출이 사용자의 시각, 인지, 주관적 웰빙에 미치는 영향을 분석한 연구입니다 [1], [2]. 연구 결과, VR 직후에 시각적 변화와 멀미 증상이 발생하지만 그룹 평균적으로는 40분 후에 기저 수준으로 회복됨을 확인했습니다 [3]. 그러나 멀미 회복에 있어 개인 편차가 뚜렷하게 나타남을 입증하여, 향후 안전한 VR 엑서게임 사용을 위해 노출 전후의 관리 가이드라인을 제시하고 있습니다 [3], [4].
-
-## 📖 구조화된 지식 (Synthesized Content)
-* **연구의 배경 및 목적:** VR 엑서게임은 몰입형 환경을 통해 운동의 육체적 피로를 분산시키고 신체 활동을 장려하는 잠재력이 있습니다 [5], [6]. 하지만 헤드마운트 디스플레이(HMD) 사용으로 인한 가상현실 멀미(VR sickness)는 사용자의 성과, 즐거움, 몰입감을 저해하는 주요 장애물입니다 [5], [7]. 본 연구는 36명의 참가자를 대상으로 10분(단기) 및 50분(장기) 노출이 시각적(조절 및 폭주), 인지적(의사결정 및 움직임 속도), 그리고 주관적 웰빙에 어떤 후유증(aftereffects)을 남기는지 평가했습니다 [1], [2].
-* **시각 및 인지적 후유증 (Visual & Cognitive Aftereffects):** 
-  * 시각의 경우, 노출 시간(10분 또는 50분)에 관계없이 VR 직후 조절(accommodation)과 폭주(convergence) 기능에 유의미한 변화가 발생했습니다 [3], [8]. 이는 HMD 기기의 폭주-조절 불일치(vergence-accommodation conflicts)에서 기인한 것으로 분석됩니다 [9], [8]. 그러나 이 변화는 VR 종료 40분 후(후기 테스트)에는 모두 기저 수준으로 회복되었습니다 [3], [8].
-  * 인지 기능과 관련해서는 우려할 만한 부정적인 영향이 나타나지 않았으며, 오히려 10분 노출 직후에는 움직임 속도가 미세하게 빨라지는 긍정적 양상이 관찰되었습니다 [3], [10], [11].
-* **멀미 증상의 발현과 지속성 (VR Sickness Dynamics):** 
-  * 시뮬레이터 멀미 설문(SSQ) 점수는 VR 노출 직후 유의미하게 상승했으며, 10분 노출보다 50분 장기 노출에서 멀미 수치가 훨씬 더 높게 나타났습니다 [3], [12].
-  * 증상은 종료 후 40분이 지나면 그룹 전체 평균적으로는 기저 수준으로 회복되었습니다 [3], [13]. 
-  * 하지만 50분 노출 40분 후에도 참가자의 약 14%는 여전히 높은 수준의 멀미를 호소하는 등 개인차가 컸습니다 [3], [14]. 
-* **안전 권고사항:** 10분의 짧은 노출에서 심한 멀미를 느낀 사용자는 장기 노출 시에도 심한 증상을 겪을 확률이 매우 높은 것으로 나타났습니다 [3], [15]. 따라서 본격적인 장기 플레이 전 짧은 사전 체험(trial)을 실시하는 것이 권장되며, 잠재적인 후유증의 위험을 고려하여 VR 종료 후 운전과 같은 위험한 활동을 재개하기 전 약 40분가량의 대기 시간을 가질 것을 제안합니다 [4].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[가상현실 멀미(VR Sickness)]], [[폭주-조절 불일치(Vergence-accommodation conflict)]], [[시뮬레이터 멀미 설문(SSQ)]]
-- **Projects/Contexts:** [[비트 세이버(Beat Saber)를 활용한 엑서게임 실험]]
-- **Contradictions/Notes:** 통계적으로 그룹의 평균적인 시각적 변화 및 멀미 증상은 VR 종료 40분 후 기저 수준으로 회복된다고 나타나지만, 개별 데이터에 따르면 참가자의 약 14%는 40분 후에도 여전히 심각한 수준의 멀미 증상을 경험하는 모순적(개인 편차) 결과가 존재합니다 [3], [14].
-
----
-*Last updated: 2026-04-19*
-- Raw Source: [[00_Raw/2026-04-20/가상현실 엑서게임 후유증 연구(VR Exergaming Aftereffects Study).md]]
----
diff --git a/Programming & Language/가상현실 엑서게임 후유증 연구(Virtual reality exergaming aftereffects research).md b/Programming & Language/가상현실 엑서게임 후유증 연구(Virtual reality exergaming aftereffects research).md
deleted file mode 100644
index 83030509..00000000
--- a/Programming & Language/가상현실 엑서게임 후유증 연구(Virtual reality exergaming aftereffects research).md	
+++ /dev/null
@@ -1,34 +0,0 @@
----
-id: P-REINFORCE-AUTO-EE39A3
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - 가상현실 엑서게임 후유증 연구(Virtual reality exergaming aftereffects research)"
----
-
-# [[가상현실 엑서게임 후유증 연구(Virtual reality exergaming aftereffects research)]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 가상현실(VR) 엑서게임 후유증 연구는 사용자가 헤드마운트 디스플레이(HMD)를 착용하고 신체 활동을 동반하는 게임(예: 비트 세이버)을 수행한 후 경험하는 시각적, 인지적 변화와 주관적인 사이버 멀미(VR sickness) 증상을 조사하는 분야입니다 [1, 2]. 이 연구는 짧은 노출(10분)과 긴 노출(50분) 등 게임 시간에 따른 후유증의 발생 정도 및 회복 시간을 분석하여, VR 엑서게임의 안전성과 지속적인 활용 가능성을 평가하는 것을 목적으로 합니다 [1, 3]. 연구 결과에 따르면 대부분의 시각적 변화 및 멀미 증상은 게임 직후 악화되지만, 일정 시간의 휴식 후에는 대체로 기저 수준(baseline)으로 회복되는 것으로 나타났습니다 [4-6].
-
-## 📖 구조화된 지식 (Synthesized Content)
-* **시각적 후유증 (Visual Aftereffects):** VR 노출 직후 사용자의 눈 조절(Accommodation)과 수렴(Convergence)에 유의미한 변화가 발생하며, 이는 HMD 기기 특유의 수렴-조절 불일치(vergence-accommodation conflicts)로 인해 유발될 가능성이 큽니다 [5, 7, 8]. 그러나 노출 시간(10분 vs 50분)이 시각적 지표에 미치는 영향은 유의미하지 않았으며, 게임 종료 후 40분이 지나면 두 가지 시각적 지표 모두 기저 수준으로 회복되었습니다 [5].
-* **인지적 후유증 (Cognitive Aftereffects):** VR 엑서게임은 사용자의 인지적 속도나 반응 시간에 부정적인 영향을 미치지 않았습니다 [9]. 오히려 10분간의 짧은 VR 노출 직후 측정한 인지 반응 테스트에서는 사용자의 움직임 속도(movement speed)가 베이스라인보다 부분적으로 더 빨라지는 현상이 관찰되었습니다 [9].
-* **주관적 멀미 증상 (Self-Reported VR Sickness):** 시뮬레이터 멀미 설문지(SSQ) 측정 결과, 메스꺼움(nausea), 안구 운동 장애(oculomotor), 방향 감각 상실(disorientation) 등의 증상이 VR 노출 직후 크게 증가했습니다 [6, 10]. 특히 10분 노출에 비해 50분의 긴 노출에서 주관적인 멀미 증상의 심각도가 훨씬 높았습니다 [6, 10]. 
-* **회복 양상 및 개인차 (Recovery and Individual Differences):** 그룹 평균적으로는 게임 종료 40분 후에 모든 증상이 기저 수준으로 돌아왔습니다 [6]. 하지만 개인차를 살펴보면 50분간 게임을 한 참가자 중 약 14%는 40분이 지난 후에도 여전히 높은 수준의 멀미 증상을 겪고 있었습니다 [11]. 또한, 10분의 짧은 노출만으로도 심한 멀미를 경험한 사람은 긴 시간 노출될 경우 거의 확실하게 심각한 증상을 겪는 것으로 예측되었습니다 [12].
-* **권고사항 (Recommendations):** VR 후유증으로 인한 부상 및 사고 위험(예: 운전 등)을 방지하기 위해 사용자는 VR 환경에서 나온 후 충분한 대기 및 회복 시간을 가져야 합니다 [13]. 아울러 긴 시간 노출되기 전, 짧은 세션을 통해 본인의 사이버 멀미 민감도를 미리 시험해볼 것이 권장됩니다 [13].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[사이버 멀미(VR sickness)]], [[수렴-조절 불일치(Vergence-accommodation conflicts)]], [[시뮬레이터 멀미 설문지(Simulator Sickness Questionnaire, SSQ)]], [[헤드마운트 디스플레이(HMD)]]
-- **Projects/Contexts:** [[비트 세이버 엑서게임 연구(Beat Saber exergame study)]]
-- **Contradictions/Notes:** 그룹 전체의 평균 데이터를 보면 VR 노출 후 40분이 지나면 증상이 완전히 기저 수준으로 회복됨을 시사하지만, 개별 데이터를 심층적으로 보면 일부 사용자(약 14%)가 50분 노출 후 40분이 지나도 여전히 높은 수준의 멀미를 보고한다는 점에서 평균값과 개인차 간의 상반된 양상을 주의해야 합니다 [11]. 또한 멀미나 피로로 인해 인지 속도가 저하될 것이라는 일반적 우려와 달리, 실제 엑서게임 직후에는 오히려 운동 반응 속도가 일시적으로 향상되는 모순된/긍정적인 결과가 관찰되기도 했습니다 [9].
-
----
-*Last updated: 2026-04-19*
-- Raw Source: [[00_Raw/2026-04-20/가상현실 엑서게임 후유증 연구(Virtual reality exergaming aftereffects research).md]]
----
diff --git a/Programming & Language/가상현실 엑서게임(Exergaming) 후유증 연구.md b/Programming & Language/가상현실 엑서게임(Exergaming) 후유증 연구.md
deleted file mode 100644
index b95371ba..00000000
--- a/Programming & Language/가상현실 엑서게임(Exergaming) 후유증 연구.md	
+++ /dev/null
@@ -1,30 +0,0 @@
----
-id: P-REINFORCE-AUTO-9CAC35
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - 가상현실 엑서게임(Exergaming) 후유증 연구"
----
-
-# [[가상현실 엑서게임(Exergaming) 후유증 연구]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 가상현실(VR) 엑서게임은 몰입감을 통해 신체적 노력에 대한 부담을 잊게 하고 좌식 행동을 개선할 수 있는 유망한 도구이지만, 헤드 마운트 디스플레이(HMD) 사용은 시각적 불일치나 VR 멀미(VR Sickness) 등의 후유증을 유발할 수 있습니다 [1]. 인기 VR 엑서게임인 '비트 세이버(Beat Saber)'를 활용한 실험 결과에 따르면, 노출 직후 사용자의 안구 조절 및 폭주 기능의 변화와 주관적인 멀미 증상이 나타나며, 특히 긴 시간(50분) 노출 시 그 증상이 더욱 심해지는 것으로 나타났습니다 [2, 3]. 대다수의 사용자는 VR 종료 40분 후 기저 수준으로 회복되지만 일부는 장기적인 멀미를 겪을 수 있어, VR 엑서게임 후에는 운전 등의 위험한 활동을 피하고 충분한 휴식 시간을 갖는 것이 필수적입니다 [4, 5].
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[가상현실 멀미(VR Sickness)]], [[폭주-조절 불일치(Vergence-Accommodation Conflicts)]], [[시뮬레이터 멀미 설문지(SSQ)]]
-- **Projects/Contexts:** [[비트 세이버(Beat Saber) 실험]]
-- **Contradictions/Notes:** 연구 결과에서 그룹 전체 평균으로는 VR 엑서게임 종료 40분 후 모든 시각적 변화와 멀미가 기저 수준으로 회복된다고 나타났지만, 개별 데이터 확인 시 50분 플레이어의 약 14%는 회복되지 않고 여전히 심각한 멀미를 앓고 있어 평균이 개인의 완전한 회복을 담보하지 않는다는 점에 주의해야 합니다 [4].
-
----
-*Last updated: 2026-04-19*
-- Raw Source: [[00_Raw/2026-04-20/가상현실 엑서게임(Exergaming) 후유증 연구.md]]
----
diff --git a/Programming & Language/가상현실 후유증 (Virtual Reality Aftereffects).md b/Programming & Language/가상현실 후유증 (Virtual Reality Aftereffects).md
deleted file mode 100644
index c9a90961..00000000
--- a/Programming & Language/가상현실 후유증 (Virtual Reality Aftereffects).md	
+++ /dev/null
@@ -1,40 +0,0 @@
----
-id: P-REINFORCE-AUTO-167F08
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - 가상현실 후유증 (Virtual Reality Aftereffects)"
----
-
-# [[가상현실 후유증 (Virtual Reality Aftereffects)]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 가상현실(VR) 후유증은 사용자가 헤드 마운트 디스플레이(HMD)를 사용하여 VR 환경(예: 엑서게임 등)을 체험할 때 겪는 메스꺼움, 방향 감각 상실, 시각적 장애 등의 멀미(VR sickness) 증상과 그로 인한 신체적·인지적 영향을 의미합니다 [1, 2]. 이는 가상 환경에서의 시각적 경험과 실제 신체적 경험 간의 감각적 불일치로 인해 발생하며, 깊이 지각(depth perception)과 인지 능력에도 부정적인 영향을 미칠 수 있습니다 [1-3]. 대다수의 즉각적인 시각 및 인지적 후유증은 기기 사용 종료 후 일정 시간(약 40분)이 지나면 기준선으로 회복되지만, 개인의 민감도나 초기 증상의 심각성에 따라 회복 시간에 큰 편차가 존재합니다 [4-6].
-
-## 📖 구조화된 지식 (Synthesized Content)
-- **주요 증상 및 인지적 영향**
-  VR 후유증은 일반적으로 메스꺼움, 방향 감각 상실, 시각적 피로 등의 멀미 증상을 동반하며, 이는 사용자의 몰입감(presence)을 깨뜨리고 게임의 즐거움과 동기를 크게 저하시킵니다 [2]. 주관적으로 느끼는 증상 외에도, 후유증이 발생하면 사용자의 깊이 지각과 인지 능력 또한 함께 저하되어 전반적인 작업 수행 능력에 부정적인 영향을 미치게 됩니다 [1, 2].
-
-- **후유증의 발생 원인**
-  VR 멀미 및 후유증의 정확한 병인에 대한 완전한 합의는 없으나, 가상 세계와 현실 세계 사이의 감각적 불일치(mismatch)가 가장 주요한 원인으로 꼽힙니다 [3]. 특히 시각적으로 인지되는 움직임과 실제 신체가 느끼는 움직임이 일치하지 않을 때 생기는 **시각-전정 감각 충돌(visual-vestibular conflict)**이 핵심적인 역할을 합니다 [3]. 또한, HMD의 특성상 발생하는 **폭주-조절 불일치(vergence-accommodation conflict)** 현상은 시각적 불편함이나 피로감을 가중시켜 안구 운동 관련 증상을 악화시킬 수 있습니다 [3].
-
-- **시간 경과에 따른 증상 회복 및 쇠퇴**
-  '비트 세이버(Beat Saber)'를 활용한 실험 연구에 따르면, 10분 노출과 50분 노출 모두에서 VR 사용 직후 눈의 조절(accommodation) 및 폭주(convergence) 기능에 유의미한 변화가 관찰되었습니다 [4, 6, 7]. 그러나 이러한 변화는 대체로 단기적이었으며, 그룹 전체를 기준으로 볼 때 VR을 종료한 지 40분이 지나면 증상들이 사전 노출(baseline) 수준으로 회복되는 점진적인 쇠퇴(degradation) 현상을 보였습니다 [5, 6]. 
-
-- **개인차 및 안전을 위한 권장 사항**
-  후유증의 강도 및 회복 시간은 사용자의 초기 증상 심각성 및 VR 노출 시간에 크게 좌우됩니다 [5, 8]. 짧은 노출(10분)만으로도 높은 수준의 후유증을 겪은 사용자는 더 긴 노출(50분) 후에도 비슷하거나 더 심각한 증상을 겪을 가능성이 매우 높습니다 [4, 8, 9]. 따라서 긴 시간의 VR 체험 전 짧은 세션을 통해 스스로의 민감도를 테스트하는 것이 좋으며, VR 사용 후 운전 등 부상 위험이 있는 활동을 하기 전에는 증상이 기준선으로 완전히 회복될 때까지 충분한 대기 시간을 가져야 합니다 [9].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[가상현실 멀미 (VR Sickness / Cybersickness)]], [[시각-전정 감각 충돌 (Visual-Vestibular Conflict)]], [[폭주-조절 불일치 (Vergence-Accommodation Conflict)]]
-- **Projects/Contexts:** [[비트 세이버(Beat Saber)를 활용한 엑서게임 후유증 연구]]
-- **Contradictions/Notes:** 소스에 따르면 그룹 평균적으로는 VR 노출 후 40분 이내에 증상이 기준선으로 회복되는 것으로 나타났으나, 이는 모든 개인에게 일괄 적용되는 것은 아닙니다. 실제로 50분간 게임을 플레이한 참가자 중 약 14%는 40분이 지난 후에도 여전히 심각한 수준의 VR 멀미를 보고하여, 후유증의 회복에는 큰 개인차가 존재함이 강조됩니다 [4, 10]. 또한, 잦은 휴식이나 짧은 반복 노출을 통한 습관화(habituation)가 일부 사용자의 증상을 완화할 수 있다는 증거가 있지만, 이 역시 모든 사람에게 효과가 있는 전략은 아니라고 지적합니다 [8].
-
----
-*Last updated: 2026-04-19*
-- Raw Source: [[00_Raw/2026-04-20/가상현실 후유증 (Virtual Reality Aftereffects).md]]
----
diff --git a/Programming & Language/가상현실 후유증(VR Aftereffects).md b/Programming & Language/가상현실 후유증(VR Aftereffects).md
deleted file mode 100644
index 3c64d6a3..00000000
--- a/Programming & Language/가상현실 후유증(VR Aftereffects).md	
+++ /dev/null
@@ -1,40 +0,0 @@
----
-id: P-REINFORCE-AUTO-4280D4
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - 가상현실 후유증(VR Aftereffects)"
----
-
-# [[가상현실 후유증(VR Aftereffects)]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 가상현실 후유증(VR Aftereffects)은 사용자가 헤드마운트 디스플레이(HMD) 등을 통해 가상현실 환경을 경험한 후 겪게 되는 멀미, 방향 감각 상실, 시각적 장애 등의 부정적인 신체적, 인지적 증상을 의미합니다 [1, 2]. 이러한 현상은 가상 세계의 시각적 정보와 실제 신체의 전정 감각 간의 충돌이나, HMD 기기가 유발하는 눈의 폭주-조절 불일치 등으로 인해 발생합니다 [3, 4]. 후유증은 사용자의 가상현실에 대한 몰입감을 떨어뜨리고, 즐거움을 저하시키며, 작업 수행 능력에 악영향을 미칠 수 있기 때문에 VR 기술의 지속적인 활용을 제한하는 주요 요인으로 꼽힙니다 [2].
-
-## 📖 구조화된 지식 (Synthesized Content)
-- **주요 증상 및 인지적 영향**
-  가상현실 후유증은 메스꺼움, 방향 감각 상실, 현기증 등의 멀미 증상과 눈의 피로, 초점 문제 등 시각 및 안구 운동 장애를 포괄합니다 [2, 5]. 후유증은 단순히 신체적 불쾌감을 넘어 사용자의 인지 능력과 깊이 지각(Depth Perception)에도 영향을 미칩니다 [2]. HMD 내에서 발생하는 눈의 조절(Accommodation) 및 폭주(Vergence)의 불일치로 인해 현실 세계에서의 깊이 지각이 교란될 수 있으며, 이는 두통과 겹보임(Double vision)을 유발할 수 있습니다 [4].
-
-- **발생 원인 및 이론**
-  가상현실 후유증의 정확한 원인에 대해서는 여전히 논의가 진행 중이나, 가장 유력한 이론은 시각-전정 감각의 충돌(Visual-vestibular conflict)입니다 [3]. 사용자의 시각적 경험이 실제 신체적 움직임과 일치하지 않을 때 뇌의 다감각 통합에 교란이 일어나 멀미 증상이 유발됩니다 [3]. 또한 기기적 특성상 3D 환경에서 망막에 주어지는 단서와 실제 디스플레이 거리의 차이에서 오는 폭주-조절 불일치가 안구 증상을 가중시킵니다 [3, 4].
-
-- **노출 시간 및 회복 양상 (Recovery)**
-  VR 노출 시간이 길어질수록 심각한 후유증을 호소할 확률이 높아집니다 [6, 7]. 연구에 따르면, 10분의 짧은 노출 후 심각한 후유증을 겪은 사용자는 50분 등 더 긴 시간 노출되었을 때 동일하거나 더 악화된 증상을 겪을 가능성이 매우 높습니다 [8]. 대부분의 사용자는 VR 종료 후 약 40분 정도의 휴식기를 거치면 시각적, 인지적, 주관적 후유증 증상이 기준선(Baseline)으로 회복됩니다 [9, 10]. 그러나 일부(약 14%)의 사용자는 긴 시간(50분) 노출 후 40분이 지나서도 여전히 높은 수준의 후유증을 호소하는 것으로 나타나, 개인마다 회복에 필요한 시간이 다를 수 있습니다 [11].
-
-- **개인차 및 콘텐츠의 영향**
-  가상현실 콘텐츠의 시각적 복잡성, 사용자 이동량, 움직임의 디테일 등 콘텐츠 요소가 후유증 발생에 큰 역할을 합니다 [12]. 높은 수준의 시각적 자극과 신체 움직임을 요구하는 엑서게임(Exergame) 등은 증상을 악화시킬 수 있습니다 [13]. 또한 연령, 성별, 자세 안정성(Postural stability), 멀미에 대한 민감도 등 개인차 역시 HMD 내에서 후유증을 경험할 가능성에 기여하는 주요 요인입니다 [8, 14].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[가상현실 멀미(VR Sickness)]], [[시각-전정 감각 충돌(Visual-Vestibular Conflict)]], [[폭주-조절 불일치(Vergence-Accommodation Conflict)]]
-- **Projects/Contexts:** [[비트 세이버(Beat Saber) 엑서게임 연구]]
-- **Contradictions/Notes:** 일반적으로 VR 노출 시간이 길어질수록 후유증 증상이 증가하지만, 일부 문헌에서는 10~20분 노출된 연구보다 20분 이상 노출된 연구에서 오히려 평균 증상이 더 낮게 나타나는 등 비선형적인 양상을 보고하기도 합니다. 이는 포함된 VR 콘텐츠의 유형(360도 비디오, 게임 등) 차이에서 기인했을 가능성이 큽니다 [7]. 
-
----
-*Last updated: 2026-04-19*
-- Raw Source: [[00_Raw/2026-04-20/가상현실 후유증(VR Aftereffects).md]]
----
diff --git a/Programming & Language/가상현실(VR) 엑서게임 인지 사후 효과 분석(CANTAB 5-choice RTI).md b/Programming & Language/가상현실(VR) 엑서게임 인지 사후 효과 분석(CANTAB 5-choice RTI).md
deleted file mode 100644
index 2aa05fca..00000000
--- a/Programming & Language/가상현실(VR) 엑서게임 인지 사후 효과 분석(CANTAB 5-choice RTI).md	
+++ /dev/null
@@ -1,34 +0,0 @@
----
-id: P-REINFORCE-AUTO-2EC87D
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - 가상현실(VR) 엑서게임 인지 사후 효과 분석(CANTAB 5-choice RTI)"
----
-
-# [[가상현실(VR) 엑서게임 인지 사후 효과 분석(CANTAB 5-choice RTI)]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 본 주제는 가상현실(VR) 엑서게임(예: Beat Saber) 플레이가 사용자의 인지 능력과 반응 속도에 미치는 사후 효과를 분석한 내용입니다 [1-3]. 인지적 요인과 운동적 요인을 분리하여 측정하기 위해 CANTAB 5-choice 반응 시간(RTI) 과제가 활용되었습니다 [3]. 평가 결과, VR 엑서게임 노출 후 의사 결정 속도와 운동 속도에서 우려할 만한 부정적인 인지 사후 효과는 나타나지 않았으며, 단기적으로 운동 속도가 약간 향상되는 등 안전한 수준으로 확인되었습니다 [4].
-
-## 📖 구조화된 지식 (Synthesized Content)
-- **CANTAB 5-choice RTI 테스트 방식:** 이 과제는 참가자의 인지 및 운동 속도를 측정하기 위해 iPad 환경에서 수행되었습니다 [3]. 참가자는 화면 하단의 버튼을 누르고 있다가 상단의 5개 원 중 하나에 목표 자극(노란 점)이 나타나면 최대한 빨리 버튼을 놓고 목표를 터치해야 합니다 [3].
-- **반응 속도 측정 지표:** 반응 시간은 인지적 요인과 운동적 요인을 분리하기 위해 두 가지 구성요소로 분석되었습니다 [3]. 첫째는 목표 자극 출현부터 버튼을 놓을 때까지 걸리는 '의사 결정 속도(Decision speed)'이며, 둘째는 버튼을 놓은 시점부터 목표 자극을 터치할 때까지 걸리는 '운동 속도(Movement speed)'입니다 [3, 5].
-- **의사 결정 속도에 미친 영향:** VR 노출 전과 비교했을 때, VR 노출(10분 및 50분) 직후나 40분 후 모두 의사 결정 시간에는 통계적으로 유의미한 차이가 발견되지 않았습니다 [4, 6]. 이는 사용자가 자극을 인지하고 운동을 개시하는 데 필요한 판단 능력이 게임 후에도 저하되지 않았음을 의미합니다.
-- **운동 속도에 미친 영향:** 모터 움직임 시간 분석 결과에서도 우려할 만한 부정적 영향은 발견되지 않았습니다 [4]. 오히려 10분 동안 엑서게임을 플레이한 직후 참가자들의 운동 속도는 VR 노출 전보다 약간 더 빨라진 것으로 관찰되었습니다 [4]. 
-- **효과의 지속성:** 반응 및 운동 속도가 빨라진 긍정적인 효과는 단기적이었으며, 이는 유산소 운동 후 나타나는 반응 시간 향상 효과가 운동 중단 후 빠르게 사라진다는 기존의 유산소 운동 연구 결과와 일치하는 양상입니다 [7].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[엑서게임(Exergaming)]], [[반응 시간(Reaction Time)]], [[가상현실 멀미(VR Sickness)]]
-- **Projects/Contexts:** [[Beat Saber VR 엑서게임 실험]]
-- **Contradictions/Notes:** 소스에 따르면, 가상현실 노출이 반응 속도에 미치는 즉각적인 영향에 대해 기존 문헌들은 매우 일관되지 않은 결과를 보입니다. 일부 연구는 부정적인 사후 효과(반응 속도 지연 등)를 보고한 반면, 본 연구 결과를 포함한 다른 연구들은 반응 시간이 오히려 빨라지는 긍정적인 효과를 발견하기도 했습니다 [8].
-
----
-*Last updated: 2026-04-19*
-- Raw Source: [[00_Raw/2026-04-20/가상현실(VR) 엑서게임 인지 사후 효과 분석(CANTAB 5-choice RTI).md]]
----
diff --git a/Programming & Language/가상현실(VR) 자전거 시뮬레이터.md b/Programming & Language/가상현실(VR) 자전거 시뮬레이터.md
deleted file mode 100644
index a7658c51..00000000
--- a/Programming & Language/가상현실(VR) 자전거 시뮬레이터.md	
+++ /dev/null
@@ -1,36 +0,0 @@
----
-id: P-REINFORCE-AUTO-807F75
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - 가상현실(VR) 자전거 시뮬레이터"
----
-
-# [[가상현실(VR) 자전거 시뮬레이터]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 가상현실(VR) 자전거 시뮬레이터는 사용자의 신체적 활동과 가상 환경을 결합한 엑스어게임(Exergame) 연구에서 활용되는 시뮬레이션 시스템 중 하나입니다 [1]. 이 시스템은 헤드마운트 디스플레이(HMD)나 대형 스크린과 결합되어 가상현실 멀미(Cybersickness)와 같은 부작용이나 몰입도를 평가하는 데 주로 쓰입니다 [1]. 소스 데이터 내에서는 주로 가상현실 환경에서의 시뮬레이션된 움직임과 디스플레이 유형이 사용자에게 미치는 영향을 분석하는 단일 연구 사례의 맥락으로만 간략히 등장합니다 [1].
-
-## 📖 구조화된 지식 (Synthesized Content)
-**소스에 관련 정보가 부족합니다.** 
-
-제공된 소스 데이터 내에서 가상현실(VR) 자전거 시뮬레이터와 관련하여 확인 가능한 핵심 내용은 멀미 증상에 관한 특정 연구 결과로 국한되며, 구체적인 작동 원리나 시스템 구조에 대한 설명은 존재하지 않습니다. 확인된 제한적인 내용은 다음과 같습니다.
-
-*   **디스플레이 매체와 사이버 멀미의 관계:** 가상현실 자전거 시뮬레이터를 활용한 연구에 따르면, HMD를 착용한 참가자들이 대형 스크린을 사용한 참가자들보다 시뮬레이터 멀미 설문(SSQ)에서 현저히 높은 점수를 기록했습니다 [1].
-*   **멀미의 주요 증폭 요인:** 시뮬레이터 멀미(SSQ) 점수는 사용자가 시뮬레이터에 노출된 시간과 가상으로 구현된 움직임(Simulated motion)이 증가할수록 함께 높아지는 것으로 나타났습니다 [1].
-*   **몰입도와 부작용의 상충(Trade-off):** HMD는 엑스어게임(Exergames)을 수행할 때 스크린 기반 환경보다 더 높은 몰입감을 제공하는 선택지일 수 있습니다 [1]. 하지만 이와 동시에 화면 기반 엑스어게임에 비해 더 높은 수준의 멀미를 유발할 수 있다는 한계도 동반합니다 [1].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[엑스어게임(Exergames)]], [[사이버 멀미(Cybersickness)]], [[헤드마운트 디스플레이(HMD)]]
-- **Projects/Contexts:** [[디스플레이 유형과 모션 제어가 가상 자전거 시뮬레이터 멀미에 미치는 영향 연구]]
-- **Contradictions/Notes:** 소스에 가상현실(VR) 자전거 시뮬레이터에 대한 전반적이고 상세한 정보가 부족합니다. 다만 HMD 기반의 시뮬레이터가 몰입도를 높이는 장점이 있음에도 불구하고, 스크린 기반 게임에 비해 멀미를 더 많이 유발할 수 있다는 점이 지적됩니다 [1].
-
----
-*Last updated: 2026-04-19*
-- Raw Source: [[00_Raw/2026-04-20/가상현실(VR) 자전거 시뮬레이터.md]]
----
diff --git a/Programming & Language/감각 통합(Sensory integration).md b/Programming & Language/감각 통합(Sensory integration).md
deleted file mode 100644
index 375410c7..00000000
--- a/Programming & Language/감각 통합(Sensory integration).md	
+++ /dev/null
@@ -1,33 +0,0 @@
----
-id: P-REINFORCE-AUTO-22B9B4
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - 감각 통합(Sensory integration)"
----
-
-# [[감각 통합(Sensory integration)]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 감각 통합(Sensory integration)은 개인이 환경 내에서 이동하고 상호작용하는 능력에 근본적인 역할을 하는 감각 처리 과정이다 [1]. 특히 시각적 감각과 전정(신체적) 감각의 통합을 포함하며, 이들 감각 사이에 불일치가 발생할 경우 감각 통합에 교란이 일어난다 [1]. 이러한 감각 통합의 교란은 주로 가상현실(VR) 환경 등에서 메스꺼움이나 방향 상실과 같은 멀미 증상을 유발하는 원인으로 작용한다 [1]. 이 외에 감각 통합의 일반적인 의학적/신경학적 정의에 대해서는 소스에 관련 정보가 부족합니다.
-
-## 📖 구조화된 지식 (Synthesized Content)
-* **시각 및 전정 감각의 통합**: 시각적 감각과 전정적(신체적) 감각의 통합은 개인이 주변 환경을 돌아다니고 효과적으로 상호작용하는 능력을 발휘하는 데 있어 필수적인 기반이 된다 [1].
-* **시각-전정 충돌(Visual-vestibular conflict)**: 가상현실(VR)과 같은 환경에서 사용자가 시각적으로 경험하는 것과 실제 신체적으로 경험하는 것이 일치하지 않을 때 감각 간의 충돌이 발생한다 [1]. 
-* **감각 통합 교란 및 멀미 유발**: 뇌로 전달되는 시각 감각과 전정 감각 사이에 충돌이 존재하면, 개인의 감각 통합 과정에 교란(disturbance)이 발생하게 된다 [1]. 결과적으로 이러한 감각 통합의 교란은 메스꺼움(nausea)이나 방향 감각 상실(disorientation) 등과 같은 멀미(Motion sickness) 증상을 유발하게 된다 [1]. 
-* **참고사항**: 위 내용을 제외한 감각 통합 장애나 임상적 치료 등 더 넓은 범위의 내용에 대해서는 소스에 관련 정보가 부족합니다.
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[가상현실 멀미(VR Sickness)]], [[시각-전정 충돌(Visual-vestibular conflict)]]
-- **Projects/Contexts:** [[가상현실 엑서게임(Beat Saber) 시각 및 인지적 후유증 연구]]
-- **Contradictions/Notes:** 제공된 소스에서는 감각 통합을 주로 VR 환경에서의 멀미 유발 원인(시각과 전정 감각의 충돌)이라는 매우 제한적인 맥락에서만 다루고 있으며, 그 외의 정보에 대해서는 소스에 관련 정보가 부족합니다.
-
----
-*Last updated: 2026-04-19*
-- Raw Source: [[00_Raw/2026-04-20/감각 통합(Sensory integration).md]]
----
diff --git a/Programming & Language/강화 계획.md b/Programming & Language/강화 계획.md
deleted file mode 100644
index 6840d2cf..00000000
--- a/Programming & Language/강화 계획.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-6EDEB4
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - 강화 계획"
----
-
-# [[강화 계획]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/강화 계획.md]]
----
diff --git a/Programming & Language/강화 학습(Reinforcement Learning) 알고리즘.md b/Programming & Language/강화 학습(Reinforcement Learning) 알고리즘.md
deleted file mode 100644
index 2c4c29ba..00000000
--- a/Programming & Language/강화 학습(Reinforcement Learning) 알고리즘.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-B4CA68
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - 강화 학습(Reinforcement Learning) 알고리즘"
----
-
-# [[강화 학습(Reinforcement Learning) 알고리즘]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/강화 학습(Reinforcement Learning) 알고리즘.md]]
----
diff --git a/Programming & Language/개발자 경험(DX).md b/Programming & Language/개발자 경험(DX).md
deleted file mode 100644
index 6c6a49aa..00000000
--- a/Programming & Language/개발자 경험(DX).md	
+++ /dev/null
@@ -1,34 +0,0 @@
----
-id: P-REINFORCE-AUTO-C2C2F8
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - 개발자 경험(DX)"
----
-
-# [[개발자 경험(DX)]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 개발자 경험(DX, Developer Experience)은 개발자가 소프트웨어 도구, API, 또는 SDK 등을 사용할 때 겪는 전반적인 사용 편의성과 만족도를 의미합니다 [1, 2]. 훌륭한 DX는 복잡한 내부 로직을 숨기고 직관적인 인터페이스를 제공하여 개발자의 인지 부하를 줄이며, 휴먼 에러를 구조적으로 방지합니다 [2-4]. 이는 단기적인 개발 편의성을 넘어 시스템의 성능, 안정성, 그리고 장기적인 확장성을 지켜내는 핵심 요소입니다 [5, 6].
-
-## 📖 구조화된 지식 (Synthesized Content)
-- **직관적인 인터페이스와 안전성:** 외부 연동 SDK 등에서 개발자 경험은 '쓰기 쉽다' 또는 '어렵다'는 첫인상으로 결정되며, 이는 향후 도입 여부 및 장기적 사용에 직접적인 영향을 미칩니다 [2]. 좋은 DX를 제공하려면 인터페이스 자체가 하나의 안전 장치가 되어야 하며, 잘못된 사용 패턴이나 이벤트 누수와 같은 휴먼 에러를 원천적으로 방지하도록 설계되어야 합니다 [2, 3, 6].
-- **의도(Intent) 기반의 추상화:** 복잡한 내부 구현을 감추고 사용자의 자연스러운 목적(예: "서버를 시작한다")에 맞게 인터페이스를 재구성하는 Facade 패턴의 적용은 DX를 크게 향상시킵니다 [4]. 이는 단순한 기능 은닉이 아니라, 결합도를 낮추고 인지 부하를 줄이는 것이 주된 목적입니다 [5].
-- **편의성과 유연성의 균형 (탈출구 제공):** 파레토 법칙에 따라 전체 사용 사례의 80%는 사용하기 쉬운 고수준(High-level) 인터페이스인 Facade로 제공하여 단기적인 DX를 극대화해야 합니다 [5]. 동시에 나머지 20%의 특수한 세밀한 제어를 요구하는 상황을 대비해 저수준(Low-level) 인터페이스인 탈출구(Escape Hatch)를 함께 제공해야만 장기적인 호환성과 확장성을 잃지 않을 수 있습니다 [5, 7, 8].
-- **타입스크립트 환경에서의 DX 향상:** 시스템의 경계(Boundary)에서 데이터를 한 번에 파싱하여 프로그램 흐름 전반에 유효성 검사 로직이 지저분하게 흩어지지 않게 하는 '검증하지 말고 파싱하라(Parse, don't validate)' 원칙 또한 개발자 경험을 크게 개선합니다 [1, 9]. 
-- **DX 개선의 궁극적 효과:** 훌륭한 개발자 경험을 고려한 설계는 단순히 사용성을 높이는 데 그치지 않고, 성능과 안정성을 확보하게 해줍니다 [6]. 나아가 내부 구현이 바뀌더라도 기존 사용자 코드를 보호하여 하위 호환성 파괴(Breaking Change)를 막고, 플랫폼의 지속적인 발전을 가능하게 합니다 [6].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[Facade 패턴]], [[탈출구(Escape Hatch)]], [[파레토 법칙]], [[단일 책임 원칙(SRP)]]
-- **Projects/Contexts:** [[Toss Front SDK 개발]], [[AWS CDK]], [[Effective TypeScript Principles]]
-- **Contradictions/Notes:** 추상화 수준이 높아져 DX가 개선될수록 세밀한 제어가 어려워지고 내부 오케스트레이션 로직의 유지 비용이 증가하는 트레이드오프가 발생합니다 [7]. 따라서 고수준의 편의성에만 안주하지 않고 저수준 API와의 공존을 통해 균형을 잡는 것이 필수적입니다 [8]. 또한, 개발자 경험을 핑계로 AI 도구에 전적으로 의존하고 제어권을 넘기는 것은 오히려 복잡성을 키울 수 있으므로 지양해야 합니다 [10].
-
----
-*Last updated: 2026-04-18*
-- Raw Source: [[00_Raw/2026-04-20/개발자 경험(DX).md]]
----
diff --git a/Programming & Language/객체 지향 소프트웨어 아키텍처 설계.md b/Programming & Language/객체 지향 소프트웨어 아키텍처 설계.md
deleted file mode 100644
index cd512397..00000000
--- a/Programming & Language/객체 지향 소프트웨어 아키텍처 설계.md	
+++ /dev/null
@@ -1,33 +0,0 @@
----
-id: P-REINFORCE-AUTO-B40B56
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - 객체 지향 소프트웨어 아키텍처 설계"
----
-
-# [[객체 지향 소프트웨어 아키텍처 설계]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> **객체 지향 소프트웨어 아키텍처 설계**는 데이터와 행동을 객체(Object) 내에 캡슐화하여 복잡한 시스템을 더 작고 관리하기 쉬운 단위로 구성하는 패러다임입니다 [1, 2]. 이는 코드의 의존성을 줄이고 재사용성을 높여 소프트웨어를 더 이해하기 쉽고, 유연하며, 유지보수가 가능하도록 만드는 것을 핵심 목표로 합니다 [3, 4].
-
-## 📖 구조화된 지식 (Synthesized Content)
-*   **객체 캡슐화와 관심사의 분리(SoC):** 1980년대에 대두된 객체 지향 프로그래밍(OOP) 패러다임은 데이터와 행위를 객체 내에 캡슐화함으로써 서로 다른 객체 간의 자연스러운 **관심사 분리(Separation of Concerns)**를 이끌어냈습니다 [1, 2]. 각 객체가 특정한 측면의 기능이나 책임에 집중하게 함으로써 모듈화, 유지보수성, 확장성을 향상시킵니다 [2, 5].
-*   **SOLID 원칙 기반의 설계:** 객체 지향 아키텍처의 견고한 기반은 **SOLID 원칙**(단일 책임, 개방/폐쇄, 리스코프 치환, 인터페이스 분리, 의존성 역전)에 의해 주도됩니다 [3]. 이 원칙들은 서로 협력하여 컴포넌트 간의 결합도를 낮추고 코드의 부패를 방지합니다 [3]. 특히 '단일 책임 원칙(SRP)'과 '인터페이스 분리 원칙(ISP)'은 관심사의 분리 개념에서 직접적으로 파생된 중요한 요소입니다 [6, 7].
-*   **객체 지향적인 횡단 관심사(Cross-Cutting Concerns) 처리:** 시스템의 여러 영역에 걸쳐 발생하는 횡단 관심사 문제 역시 SOLID 설계 원칙을 활용해 객체 지향적으로 해결할 수 있습니다 [8]. 다형성(Polymorphism)을 기반으로 확장 가능한 클래스 집합을 생성하고, 추상 기반 클래스를 **템플릿 메서드(Template Method)**나 **전략(Strategy) 패턴**을 이용해 오버라이드하는 방식으로 기능을 구현하여 개방-폐쇄 원칙을 준수할 수 있습니다 [8, 9].
-*   **AOP(관점 지향 프로그래밍)를 통한 아키텍처 보완:** 전통적인 객체 지향 프로그래밍은 모듈을 기능 단위로 수직적 분리하는 데는 효과적이지만, 로깅이나 보안과 같이 시스템 전체에 흩어진 공통 기능들을 완벽히 분리하는 데는 한계가 있습니다 [10]. 이를 보완하기 위해 AOP 접근 방식을 더하여 횡단 관심사를 수평적으로 분리하고 모듈화하면, **OOP 코드를 더욱 단순화하고 역할을 명확하게 분리**할 수 있습니다 [10, 11].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[SOLID 원칙]], [[관심사의 분리(SoC)]], [[AOP(관점 지향 프로그래밍)]]
-- **Projects/Contexts:** [[소프트웨어 모듈화 및 컴포넌트 설계]], [[의존성 관리와 횡단 관심사 처리]]
-- **Contradictions/Notes:** 소스에서는 횡단 관심사를 처리할 때 객체 지향 프로그래밍의 다형성과 디자인 패턴(전략 패턴 등)을 통해 확장 가능하도록 설계할 수 있다고 설명하지만 [8], 동시에 OOP가 갖는 수직적 분리의 한계 때문에 코드의 복잡성을 낮추고 중복을 제거하려면 AOP(관점 지향 프로그래밍)를 통한 수평적 분리로 시스템을 보완해야 한다는 점을 함께 지적합니다 [10, 11].
-
----
-*Last updated: 2026-04-18*
-- Raw Source: [[00_Raw/2026-04-20/객체 지향 소프트웨어 아키텍처 설계.md]]
----
diff --git a/Programming & Language/객체 지향 프로그래밍 (OOP).md b/Programming & Language/객체 지향 프로그래밍 (OOP).md
deleted file mode 100644
index f417ea41..00000000
--- a/Programming & Language/객체 지향 프로그래밍 (OOP).md	
+++ /dev/null
@@ -1,33 +0,0 @@
----
-id: P-REINFORCE-AUTO-4772F3
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - 객체 지향 프로그래밍 (OOP)"
----
-
-# [[객체 지향 프로그래밍 (OOP)]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 객체 지향 프로그래밍(OOP)은 데이터와 그 데이터를 다루는 동작(behavior)을 객체(object)라는 단위 안에 캡슐화하여 소프트웨어의 복잡성을 관리하는 프로그래밍 패러다임입니다 [1, 2]. 클래스와 상속 구조를 통해 코드 중복을 방지하고 재사용성을 높일 수 있습니다 [3]. 주로 단일 책임 원칙(SRP)을 포함한 SOLID 설계 원칙과 함께 적용되어 유지보수가 용이하고 유연한 소프트웨어 아키텍처를 구축하는 데 핵심적인 역할을 합니다 [1, 4].
-
-## 📖 구조화된 지식 (Synthesized Content)
-- **캡슐화와 관심사의 분리 (Encapsulation & SoC):** 1980년대에 본격적으로 부상한 OOP 패러다임은 데이터와 행동을 객체 내에 캡슐화하는 아이디어를 도입했습니다 [1]. 각 객체에 특정한 기능이나 관심사에 대한 책임을 부여함으로써, 시스템 구조 내에서 자연스럽게 '관심사의 분리(Separation of Concerns)'를 이끌어냈습니다 [2].
-- **클래스 상속(Inheritance)과 코드 재사용:** OOP에서는 여러 클래스가 공통으로 공유하는 속성이나 동작을 하나의 기본 클래스(base class)에 배치할 수 있습니다 [3]. 다른 클래스들은 이 기본 클래스를 상속받아 기능을 이어받으므로, 코드를 중복해서 다시 정의할 필요 없이 DRY(Don't Repeat Yourself) 원칙을 효과적으로 달성할 수 있습니다 [3].
-- **SOLID 설계 원칙 기반:** 소프트웨어 설계를 더 이해하기 쉽고, 유연하며, 유지보수 가능하게 만들기 위해 고안된 5가지 기본 원칙인 SOLID 원칙의 토대가 됩니다 [4]. 특히 객체와 클래스가 단 하나의 책임만 가져야 한다는 단일 책임 원칙(SRP)은 OOP의 핵심 철학을 뒷받침합니다 [1, 5].
-- **구조적 한계 및 AOP를 통한 보완:** OOP 접근 방식을 따르면 기능 단위의 수직적 분리와 객체 간 책임 분리가 원활하게 이루어집니다 [6, 7]. 하지만 로깅이나 보안과 같이 시스템 전체에 흩어져 공통으로 사용되는 '횡단 관심사(Cross-Cutting Concerns)'를 모듈화하는 데에는 한계가 존재합니다 [6]. 이러한 OOP의 단점은 횡단 관심사를 수평적으로 분리해 모듈화하는 관점 지향 프로그래밍(AOP) 기술을 결합함으로써 보완할 수 있습니다 [6, 7].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[관심사의 분리 (SoC)]], [[SOLID 원칙]], [[관점 지향 프로그래밍 (AOP)]]
-- **Projects/Contexts:** [[소프트웨어 시스템 설계 및 아키텍처 구축]]
-- **Contradictions/Notes:** 소스에 따르면 OOP는 객체 간 책임을 분리하고 기능 단위의 수직적 분리를 달성하는 데 탁월하지만, 시스템 전반에 걸친 공통 기능(횡단 관심사)을 분리하는 데는 단점이 존재하며 이는 AOP 방식을 통해 반대/보완적으로 해결될 수 있다고 설명합니다 [6, 7].
-
----
-*Last updated: 2026-04-18*
-- Raw Source: [[00_Raw/2026-04-20/객체 지향 프로그래밍 (OOP).md]]
----
diff --git a/Programming & Language/객체 지향 프로그래밍 (Object-Oriented Programming).md b/Programming & Language/객체 지향 프로그래밍 (Object-Oriented Programming).md
deleted file mode 100644
index dd0120ba..00000000
--- a/Programming & Language/객체 지향 프로그래밍 (Object-Oriented Programming).md	
+++ /dev/null
@@ -1,33 +0,0 @@
----
-id: P-REINFORCE-AUTO-D7D274
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - 객체 지향 프로그래밍 (Object-Oriented Programming)"
----
-
-# [[객체 지향 프로그래밍 (Object-Oriented Programming)]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 객체 지향 프로그래밍(OOP)은 1980년대에 부상하여 데이터와 행위를 객체(Object) 내에 캡슐화하는 개념을 도입한 프로그래밍 패러다임입니다 [1, 2]. 이 방식은 시스템을 기능 단위로 수직적 분리를 이루게 하며, 객체 간의 책임을 나누어 클래스를 설계합니다 [3]. 캡슐화, 상속, 다형성 등의 원칙을 활용하여 소프트웨어의 복잡성을 관리하고 '관심사의 분리(SoC)'를 촉진하는 데 중점을 둡니다 [2].
-
-## 📖 구조화된 지식 (Synthesized Content)
-- **핵심 메커니즘과 복잡성 관리:** OOP는 시스템의 데이터와 동작(behavior)을 객체 단위로 묶어(캡슐화) 코드를 구성합니다 [1, 2]. 여러 클래스가 공유하는 공통적인 행동이나 속성이 있다면, 이를 베이스 클래스(기본 클래스)에 배치하고 다른 클래스들이 이를 상속(Inheritance)받아 기능을 재사용하게 함으로써 논리적 중복을 방지합니다 [4]. 이 외에도 다형성(Polymorphism) 등의 원칙을 활용해 복잡한 시스템을 효과적으로 제어합니다 [2].
-- **설계 원칙 (SOLID):** OOP 기반의 소프트웨어 설계를 더욱 유연하고 이해하기 쉬우며 유지보수가 용이하게 만들기 위해 고안된 것이 5가지 기반 설계 원칙인 SOLID입니다 [5]. 이 원칙은 단일 책임 원칙(SRP)을 통해 각 클래스가 하나의 책임만을 담당하도록 유도하고 [1], 의존성 역전 원칙(DIP)을 통해 세부 사항이 추상화에 의존하도록 설계합니다 [6]. 이러한 객체 지향 설계 원칙들은 점차 규모가 커지는 코드베이스나 라이브러리를 구축할 때 이상적입니다 [7].
-- **관심사의 분리(SoC) 실현:** OOP는 개별 객체가 특정 기능 측면이나 관심사에 대해 고유의 책임을 가지도록 구조화함으로써, 자연스럽게 명확한 관심사의 분리가 이루어지도록 장려합니다 [2]. 
-- **AOP를 통한 한계 보완:** OOP는 객체 간의 책임을 분리해 수직적인 모듈화를 달성하는 데에는 매우 효과적이지만, 로깅이나 보안과 같이 시스템 전반에 걸쳐 공통으로 사용되는 '횡단 관심사(Cross-Cutting Concerns)'를 분리하는 데에는 한계가 존재합니다 [3]. 따라서 이러한 OOP의 단점을 보완하고 코드를 더욱 단순화하기 위해 관점 지향 프로그래밍(AOP)과 같은 기법이 함께 활용됩니다 [3, 8].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[SOLID Principles]], [[Separation of Concerns (SoC)]], [[Aspect-Oriented Programming (AOP)]], [[Encapsulation]], [[Inheritance]], [[Polymorphism]]
-- **Projects/Contexts:** [[소프트웨어 아키텍처 및 시스템 설계]], [[유지보수 및 확장성 관리를 위한 엔터프라이즈 애플리케이션]]
-- **Contradictions/Notes:** 소스에 따르면 OOP는 객체 간 책임 분리와 기능 단위의 모듈화에 뛰어난 강점을 보이지만 모든 관심사 분리에 완벽한 것은 아닙니다. 시스템 전체에 퍼져 있는 공통 로직(횡단 관심사)을 효율적으로 분리하기 위해서는 AOP(관점 지향 프로그래밍)의 수평적 분리 접근 방식을 혼합하여 단점을 보완해야 합니다 [3].
-
----
-*Last updated: 2026-04-18*
-- Raw Source: [[00_Raw/2026-04-20/객체 지향 프로그래밍 (Object-Oriented Programming).md]]
----
diff --git a/Programming & Language/객체 지향 프로그래밍(OOP).md b/Programming & Language/객체 지향 프로그래밍(OOP).md
deleted file mode 100644
index c5fd52f3..00000000
--- a/Programming & Language/객체 지향 프로그래밍(OOP).md	
+++ /dev/null
@@ -1,33 +0,0 @@
----
-id: P-REINFORCE-AUTO-9FB550
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - 객체 지향 프로그래밍(OOP)"
----
-
-# [[객체 지향 프로그래밍(OOP)]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 객체 지향 프로그래밍(OOP)은 데이터와 그 동작(behavior)을 하나의 '객체(Object)' 내에 캡슐화하여 코드를 구성하는 프로그래밍 패러다임입니다 [1, 2]. 이 방식은 각 객체가 특정 기능이나 관심사에 대한 책임을 지도록 설계함으로써 관심사의 분리(Separation of Concerns)를 자연스럽게 이끌어냅니다 [1, 2]. 주로 기능 단위의 수직적 분리를 통해 객체 간의 책임을 나누며, 소프트웨어 설계를 더욱 이해하기 쉽고 유연하며 유지보수하기 좋게 만듭니다 [3-5].
-
-## 📖 구조화된 지식 (Synthesized Content)
-- **캡슐화와 관심사 분리:** OOP는 데이터와 동작을 객체 안에 캡슐화(encapsulating)하는 개념을 도입했습니다 [1]. 이를 통해 각 객체가 특정 기능적 측면이나 관심사를 온전히 책임지게 되어, 서로 다른 객체 간에 명확한 관심사 분리가 이루어집니다 [1, 2]. 구조적으로는 기능 단위의 수직적 모듈 분리가 이루어지며 객체 간의 책임을 명확히 설계할 수 있습니다 [4, 5].
-- **상속을 통한 코드 재사용:** 여러 클래스가 공유하는 공통적인 동작이나 속성을 기본 클래스(base class)에 정의할 수 있습니다 [6]. 하위 클래스들은 이러한 기능을 다시 정의할 필요 없이 상속(inherit)을 통해 기능을 재사용할 수 있어 코드의 중복을 줄입니다 [6].
-- **SOLID 설계 원칙의 근간:** OOP는 시스템을 더 쉽게 관리하고 확장하기 위해 창안된 5가지 설계 원칙인 SOLID(단일 책임, 개방/폐쇄, 리스코프 치환, 인터페이스 분리, 의존성 역전)의 토대가 됩니다 [3]. 예를 들어 단일 책임 원칙(SRP)은 클래스가 오직 하나의 책임을 갖도록 설계하는 것을 강조하며 [1], 의존성 역전 원칙(DIP)은 추상화가 세부 사항에 의존하는 것이 아니라 세부 사항이 추상화에 의존해야 함을 명시하여 시스템의 결합도를 낮춥니다 [7].
-- **AOP(관점 지향 프로그래밍)와의 관계:** OOP는 책임을 객체별로 분리하여 클래스를 설계하는 수직적 접근법을 따르지만, 이 방식만으로는 시스템 전체에 퍼져 있는 로깅이나 보안 같은 횡단 관심사(Cross-Cutting Concerns)를 깔끔하게 분리하는 데 한계가 있습니다 [4, 5]. 따라서 이러한 공통 기능을 수평적으로 분리하여 모듈화하는 AOP 방식을 더하여 OOP 코드의 단순화와 역할 분리를 상호 보완적으로 수행합니다 [4, 5].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[SOLID Principles]], [[Separation of Concerns (SoC)]], [[Aspect-Oriented Programming (AOP)]], [[캡슐화(Encapsulation)]], [[상속(Inheritance)]]
-- **Projects/Contexts:** 확장 가능하고 모듈화된 시스템 아키텍처 및 라이브러리 설계의 기본 바탕이 되며, 실무 기술 면접에서도 소프트웨어 설계 철학을 확인하기 위한 단골 질문으로 다루어집니다 [1, 8, 9].
-- **Contradictions/Notes:** 소스 간의 직접적인 의견 대립이나 모순에 대한 정보는 부족합니다. 다만 참고 사항으로, OOP 고유의 수직적 책임 분리만으로는 중복을 완벽히 제거하기 힘든 횡단 관심사가 존재하며, 소스에서는 이를 해결하기 위해 AOP 기법이 보완적으로 적용된다는 점을 강조하고 있습니다 [4, 5].
-
----
-*Last updated: 2026-04-18*
-- Raw Source: [[00_Raw/2026-04-20/객체 지향 프로그래밍(OOP).md]]
----
diff --git a/Programming & Language/건강 심리학.md b/Programming & Language/건강 심리학.md
deleted file mode 100644
index 1e85917e..00000000
--- a/Programming & Language/건강 심리학.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-801A0D
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - 건강 심리학"
----
-
-# [[건강 심리학]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/건강 심리학.md]]
----
diff --git a/Programming & Language/건강 행동 변화 모델.md b/Programming & Language/건강 행동 변화 모델.md
deleted file mode 100644
index b97b4ac0..00000000
--- a/Programming & Language/건강 행동 변화 모델.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-77EB30
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - 건강 행동 변화 모델"
----
-
-# [[건강 행동 변화 모델]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/건강 행동 변화 모델.md]]
----
diff --git a/Programming & Language/게임 디자인 이론 및 구조론.md b/Programming & Language/게임 디자인 이론 및 구조론.md
deleted file mode 100644
index a6d7f0f0..00000000
--- a/Programming & Language/게임 디자인 이론 및 구조론.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-D69C13
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - 게임 디자인 이론 및 구조론"
----
-
-# [[게임 디자인 이론 및 구조론]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/게임 디자인 이론 및 구조론.md]]
----
diff --git a/Programming & Language/게임 디자인의 보상 루프(Reward Loop) 설계.md b/Programming & Language/게임 디자인의 보상 루프(Reward Loop) 설계.md
deleted file mode 100644
index 54c178aa..00000000
--- a/Programming & Language/게임 디자인의 보상 루프(Reward Loop) 설계.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-A6178D
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - 게임 디자인의 보상 루프(Reward Loop) 설계"
----
-
-# [[게임 디자인의 보상 루프(Reward Loop) 설계]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/게임 디자인의 보상 루프(Reward Loop) 설계.md]]
----
diff --git a/Programming & Language/게임 루프 설계.md b/Programming & Language/게임 루프 설계.md
deleted file mode 100644
index ba4b8096..00000000
--- a/Programming & Language/게임 루프 설계.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-59E3A9
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - 게임 루프 설계"
----
-
-# [[게임 루프 설계]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/게임 루프 설계.md]]
----
diff --git a/Programming & Language/게임 행동 심리학.md b/Programming & Language/게임 행동 심리학.md
deleted file mode 100644
index 43257746..00000000
--- a/Programming & Language/게임 행동 심리학.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-BB80E3
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - 게임 행동 심리학"
----
-
-# [[게임 행동 심리학]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/게임 행동 심리학.md]]
----
diff --git a/Programming & Language/게임학(Ludology) vs 서사학(Narratology) 논쟁.md b/Programming & Language/게임학(Ludology) vs 서사학(Narratology) 논쟁.md
deleted file mode 100644
index 04de56e4..00000000
--- a/Programming & Language/게임학(Ludology) vs 서사학(Narratology) 논쟁.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-1A5F45
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - 게임학(Ludology) vs 서사학(Narratology) 논쟁"
----
-
-# [[게임학(Ludology) vs 서사학(Narratology) 논쟁]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/게임학(Ludology) vs 서사학(Narratology) 논쟁.md]]
----
diff --git a/Programming & Language/견고한 도메인 모델 및 API 계약 설계.md b/Programming & Language/견고한 도메인 모델 및 API 계약 설계.md
deleted file mode 100644
index 33d86227..00000000
--- a/Programming & Language/견고한 도메인 모델 및 API 계약 설계.md	
+++ /dev/null
@@ -1,35 +0,0 @@
----
-id: P-REINFORCE-AUTO-E5BF95
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - 견고한 도메인 모델 및 API 계약 설계"
----
-
-# [[견고한 도메인 모델 및 API 계약 설계]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 견고한 도메인 모델 및 API 계약 설계는 TypeScript의 정적 타입 시스템을 활용하여 유효하지 않은 상태를 원천 차단하고 예측 가능한 애플리케이션 구조를 만드는 과정입니다. 이를 위해 식별 가능한 유니온, 브랜디드 타입, 불변성 제약, 그리고 "검증하지 말고 파싱하라"와 같은 설계 철학을 결합하여, 경계면에서부터 데이터의 무결성을 보장하는 안전한 계약을 수립합니다.
-
-## 📖 구조화된 지식 (Synthesized Content)
-* **"검증하지 말고 파싱하라 (Parse, don't validate)":** 시스템 경계(API 진입점이나 출구)에서 타입이 지정되지 않은 데이터를 수동으로 검증하기만 하는 대신, 잘 정의된 타입의 데이터로 파싱하여 변환해야 합니다 [1, 2]. Zod와 같은 런타임 검증 라이브러리를 브랜디드 타입과 결합하면, 알 수 없는 데이터를 명확한 타입으로 좁히고 시스템 내부에서 정적 분석의 이점을 온전히 누릴 수 있습니다 [3, 4].
-* **식별 가능한 유니온(Discriminated Unions)과 완전성 검사:** 객체의 공통 리터럴 속성을 식별자로 사용하는 유니온 타입을 통해, 런타임에 유효하지 않은 상태가 아예 표현될 수 없도록 도메인을 모델링합니다 [5-7]. 여기에 `never` 타입을 활용한 완전성 검사(Exhaustiveness checking)를 더하면, 새로운 API 응답 상태나 도메인 로직이 추가될 때 처리되지 않은 케이스를 컴파일 에러로 즉각 잡아낼 수 있습니다 [6, 8-10].
-* **브랜디드 타입(Branded Types)을 통한 명목적 타이핑:** TypeScript의 구조적 타이핑이 갖는 한계(기본 타입에의 집착)를 극복하기 위해, 식별용 가상 속성이나 `unique symbol`을 교집합으로 추가하여 고유한 불투명 타입(Opaque Types)을 생성합니다 [11-14]. 이를 통해 사용자 ID와 주문 ID처럼 구조가 동일한 문자열이나 숫자일지라도 서로 섞여 API 계약을 위반하는 치명적인 버그를 컴파일 타임에 차단합니다 [3, 15, 16].
-* **`satisfies` 연산자를 활용한 엄격한 계약 강제:** 변수를 거친 간접 할당 과정에서는 타입스크립트의 과잉 속성 체크(Excess Property Checking)가 작동하지 않을 수 있습니다 [17, 18]. 백엔드 API 응답을 프론트엔드 모델로 매핑할 때 `satisfies` 연산자를 사용하면, 추가된 초과 속성을 엄격하게 에러로 잡아내면서도 구체적인 리터럴 타입 추론을 그대로 유지하여 계약의 엄격성과 유연성을 동시에 달성합니다 [19-22].
-* **불변성(Immutability) 확립:** 객체와 배열의 무분별한 상태 변경을 막고 데이터 무결성을 보장하기 위해 `readonly` 수식어와 `DeepReadonly` 재귀적 유틸리티 타입을 적용합니다 [23-25]. 식별자, 설정 객체, API 응답 등 절대 변경되어서는 안 되는 핵심 데이터에 컴파일 타임의 강력한 보호막을 제공합니다 [25, 26].
-* **도메인 방어 및 예외 처리 설계:** 비즈니스 로직에서 예상 가능한 실패를 처리할 때 단순히 `throw`로 예외를 발생시키는 대신, `Result` 타입을 명시적으로 반환합니다 [27-30]. 이를 통해 함수 시그니처 자체를 견고한 계약으로 만들어, API의 가능한 모든 결과(오류 포함)를 소비자가 안전하고 철저하게 처리하도록 강제합니다 [28, 29, 31].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[Parse, don't validate]], [[식별 가능한 유니온 (Discriminated Unions)]], [[브랜디드 타입 (Branded Types)]], [[Satisfies 연산자]], [[불변성 (Immutability)]], [[Result 타입]]
-- **Projects/Contexts:** [[Zod를 활용한 런타임 데이터 검증]], [[API 응답 처리 및 상태 머신 모델링]]
-- **Contradictions/Notes:** 소스에 따르면 교집합(`&`)과 타입 별칭(`type`)만으로도 객체를 조합할 수 있지만, 대규모 프로젝트의 성능과 컴파일러 캐싱 최적화를 고려할 때 핵심 도메인 객체 선언에는 인터페이스 상속(`interface extends`)을 우선시하는 것이 권장됩니다 [32-34]. 또한 비즈니스 흐름 제어를 위해 전통적인 예외(`Exception`) 투척보다는 `Result` 패턴을 활용하는 방식이 더욱 안전한 설계로 제시됩니다 [28, 30, 35].
-
----
-*Last updated: 2026-04-18*
-- Raw Source: [[00_Raw/2026-04-20/견고한 도메인 모델 및 API 계약 설계.md]]
----
diff --git a/Programming & Language/결정 속도(Decision Speed).md b/Programming & Language/결정 속도(Decision Speed).md
deleted file mode 100644
index c1bdda45..00000000
--- a/Programming & Language/결정 속도(Decision Speed).md	
+++ /dev/null
@@ -1,30 +0,0 @@
----
-id: P-REINFORCE-AUTO-527675
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - 결정 속도(Decision Speed)"
----
-
-# [[결정 속도(Decision Speed)]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 결정 속도(Decision Speed)는 목표 자극이 나타난 순간부터 사용자가 판단을 내리고 행동을 개시하기까지 걸린 시간을 나타내는 인지적 측정 지표입니다 [1]. 이는 주로 전체 반응 시간(Reaction Time)을 구성하는 핵심 요소 중 하나로, 물리적인 동작 속도(Movement Speed)와는 구별되는 개념입니다 [1]. 가상현실(VR) 엑서게임(Exergaming)의 인지적 사후 효과를 측정하거나, 고도의 인지적 통제력과 빠른 판단력이 요구되는 e스포츠에서 선수의 수행 능력을 평가하는 맥락에서 중요한 변수로 다뤄집니다 [1, 2].
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[반응 시간(Reaction Time)]], [[동작 속도(Movement Speed)]]
-- **Projects/Contexts:** [[가상현실(VR) 엑서게임 인지 사후 효과 분석(CANTAB 5-choice RTI)]], [[e스포츠 인지 상태 및 성과 위험 평가]]
-- **Contradictions/Notes:** 소스 내에서 직접적인 모순은 없으나, VR 노출이 반응 및 결정 속도에 미치는 영향에 대한 기존 학계 문헌들은 긍정적 효과(반응 속도 증가)와 부정적 효과(반응 속도 감소)가 혼재되어 있어 매우 일관되지 않은(highly inconsistent) 결과를 보인다는 점이 언급되어 있습니다 [6].
-
----
-*Last updated: 2026-04-19*
-- Raw Source: [[00_Raw/2026-04-20/결정 속도(Decision Speed).md]]
----
diff --git a/Programming & Language/결합도 (Coupling).md b/Programming & Language/결합도 (Coupling).md
deleted file mode 100644
index cc876059..00000000
--- a/Programming & Language/결합도 (Coupling).md	
+++ /dev/null
@@ -1,46 +0,0 @@
----
-id: P-REINFORCE-AUTO-1DFEC5
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - 결합도 (Coupling)"
----
-
-# [[결합도 (Coupling)]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 결합도(Coupling)는 소프트웨어 설계에서 모듈 간의 상호 의존성 정도를 나타내는 척도입니다 [1, 2]. 결합도가 낮다는 것은 모듈 간의 의존성이 적어 각 모듈이 독립적으로 동작할 수 있음을 의미하며, 반대로 결합도가 높으면 하나의 모듈을 변경할 때 다른 모듈에도 연쇄적인 영향을 미치게 됩니다 [2]. 성공적인 소프트웨어 아키텍처를 구현하기 위해서는 시스템의 복잡성을 줄이고 유지보수성을 높일 수 있도록 낮은 결합도를 지향해야 합니다 [2, 3].
-
-## 📖 구조화된 지식 (Synthesized Content)
-* **결합도의 유형** [2]
-  결합도는 의존성의 수준에 따라 다음과 같이 분류되며, 아래로 갈수록 결합도가 낮아져 이상적인 소프트웨어 설계 형태가 됩니다.
-  * **내용 결합(Content Coupling):** 한 모듈이 다른 모듈의 내부 내용을 직접 참조하거나 수정하는 가장 강하고 바람직하지 않은 형태입니다.
-  * **공통 결합(Common Coupling):** 두 개 이상의 모듈이 전역(Global) 데이터를 공유하는 상태로, 데이터의 상태 변화가 모든 관련 모듈에 영향을 미칩니다.
-  * **외부 결합(External Coupling):** 하드웨어나 운영체제와 같은 특정 외부 시스템이나 인터페이스를 통해 데이터를 공유합니다.
-  * **제어 결합(Control Coupling):** 한 모듈이 특정 플래그나 상태 값을 전달하여 다른 모듈의 동작 방식이나 제어 흐름을 변경하게 만드는 결합입니다.
-  * **스탬프 결합(Stamp Coupling):** 두 모듈이 복잡한 데이터 구조체를 공유하지만, 그중 일부의 데이터만 사용하는 형태입니다.
-  * **자료 결합(Data Coupling):** 모듈 간에 단순한 데이터 값(정수, 문자열 등)만을 전달하는 형태로, 모듈 간 의존성이 최소화되는 가장 낮은 결합도입니다.
-
-* **낮은 결합도의 장점 및 높은 결합도의 문제점**
-  결합도가 낮은 시스템은 한 모듈의 변경이 타 모듈에 미치는 영향이 적어 유지보수와 확장이 쉬워집니다 [4]. 또한 각 모듈이 독립적으로 동작할 수 있어 다른 프로젝트에서의 재사용성이 높아지며, 격리된 환경에서 독립적인 테스트가 가능해집니다 [4]. 반대로 결합도가 높으면 변경 시 예상치 못한 부작용(Side effect)이 발생할 위험이 커지고, 모듈 간의 강한 의존성 때문에 재사용이 어려우며 여러 모듈을 함께 테스트해야 하므로 복잡성이 증가합니다 [4].
-
-* **결합도를 낮추기 위한 주요 전략** [5]
-  * **인터페이스 사용:** 구체적인 구현 대신 인터페이스를 통해 상호작용을 정의하여 모듈 간의 직접적인 의존성을 제거합니다.
-  * **의존성 주입(Dependency Injection):** 모듈 내부에서 필요한 다른 모듈을 직접 생성하지 않고 외부에서 제공(주입)받도록 설계합니다.
-  * **이벤트 기반 아키텍처:** 모듈이 서로 직접 호출하는 대신 이벤트를 발행하고 구독하는 방식으로 간접적인 상호작용을 처리합니다.
-  * **캡슐화 및 데이터 구조 단순화:** 내부 구현 데이터를 외부에서 접근할 수 없도록 캡슐화하고, 전달하는 데이터 구조를 단순화하여 불필요한 결합을 줄입니다.
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[응집도 (Cohesion)]], [[관심사의 분리 (Separation of Concerns)]], [[의존성 주입 (Dependency Injection)]], [[단일 책임 원칙 (Single Responsibility Principle)]]
-- **Projects/Contexts:** [[소프트웨어 아키텍처 설계]], [[마이크로서비스 아키텍처]], [[이벤트 기반 아키텍처]]
-- **Contradictions/Notes:** 모듈 간 결합도를 낮추기 위해 관심사를 엄격하게 분리하는 것은 유지보수성을 크게 향상하지만, 추상화 레이어가 지나치게 많아지면 시스템 내 구성요소 간의 상호작용을 파악하기 힘들어지거나 통신 오버헤드가 발생하여 전체적인 시스템의 복잡성이 오히려 증가할 수 있다는 단점도 수반됩니다 [6, 7].
-
----
-*Last updated: 2026-04-18*
-- Raw Source: [[00_Raw/2026-04-20/결합도 (Coupling).md]]
----
diff --git a/Programming & Language/경고 피로 (Alert Fatigue).md b/Programming & Language/경고 피로 (Alert Fatigue).md
deleted file mode 100644
index 6add8c0e..00000000
--- a/Programming & Language/경고 피로 (Alert Fatigue).md	
+++ /dev/null
@@ -1,38 +0,0 @@
----
-id: P-REINFORCE-AUTO-642AF9
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - 경고 피로 (Alert Fatigue)"
----
-
-# [[경고 피로 (Alert Fatigue)]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 경고 피로(Alert Fatigue)는 자동화된 코드 리뷰나 보안 스캐닝 도구가 사소한 문제나 오탐지(False Positives)를 포함한 수많은 경고를 개발자에게 과도하게 쏟아낼 때 발생하는 현상입니다 [1, 2]. 개발자가 쏟아지는 알림(노이즈)에 압도되면 결국 도구의 출력 결과를 무시하게 되며, 이로 인해 실제로 중요한 보안 취약점이나 치명적인 경고조차 놓치게 됩니다 [2, 3]. 따라서 보안 도구의 효과를 유지하기 위해서는 경고 피로를 세심하게 관리하는 것이 필수적입니다 [1].
-
-## 📖 구조화된 지식 (Synthesized Content)
-- **경고 피로의 주요 원인:**
-  자동화된 정적 코드 분석(SAST)이나 코드 리뷰 도구는 비즈니스 로직이나 의도(Context)를 깊이 이해하지 못한 채 사전 정의된 패턴과 규칙에만 의존합니다 [2]. 이로 인해 특정 문제에 맞춰 기술적으로 잘 작성된 비관습적인 코드조차 문제로 인식하거나, 실제로는 버그가 아닌 사소한 문제들을 오탐지(False Positives)하여 엄청난 양의 경고를 발생시킵니다 [1, 2].
-  
-- **경고 피로가 미치는 악영향:**
-  개발자들은 실제 버그가 아닌 문제들을 분류하고 처리(Triage)하는 데 불필요한 시간을 낭비하게 됩니다 [2]. 높은 오탐률로 인한 지속적인 노이즈는 개발자들을 지치게 만들며, 결국 도구가 보내는 중요한 경고까지 무시하는 태도로 이어져 심각한 보안 위험을 초래할 수 있습니다 [2, 3].
-
-- **경고 피로 완화 및 해결 방안:**
-  - **규칙 최적화 및 우선순위 지정:** 도구가 사소한 경고로 PR(Pull Request)을 도배하지 않도록, 치명적(critical)이거나 위험도가 높은 문제에 대해서만 빌드 실패를 유발하도록 구성해야 합니다 [3]. 또한 악용 가능성, 비즈니스 영향도, 도달 가능성 등을 바탕으로 지능적인 분류(Triage) 프로세스를 거쳐야 합니다 [4].
-  - **문맥 인지(Context-aware) 및 AI 기술 활용:** Endor Labs와 같은 도구는 함수 수준의 도달 가능성(reachability)을 분석하여 문맥을 파악하고 알림 피로를 줄이는 데 강력한 초점을 맞추고 있으며 [5], AI를 활용해 노이즈를 필터링함으로써 오탐지를 크게 줄일 수 있습니다 [6, 7].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[오탐지 (False Positives)]], [[자동화된 코드 리뷰 (Automated Code Review)]], [[정적 애플리케이션 보안 테스트 (SAST)]]
-- **Projects/Contexts:** [[Endor Labs]], [[JetBrains Qodana]]
-- **Contradictions/Notes:** 소스 전반에서 자동화된 코드 분석 도구가 빠르고 일관적이라는 큰 장점을 제공한다고 주장하지만, 동시에 문맥 이해 부족에서 기인하는 과도한 오탐지가 '경고 피로'를 유발하여 도구의 효용성을 떨어뜨린다는 한계점을 공통적으로 지적하고 있습니다 [1, 2].
-
----
-*Last updated: 2026-04-18*
-- Raw Source: [[00_Raw/2026-04-20/경고 피로 (Alert Fatigue).md]]
----
diff --git a/Programming & Language/계층화 아키텍처 (Layered Architecture).md b/Programming & Language/계층화 아키텍처 (Layered Architecture).md
deleted file mode 100644
index bd25b4b7..00000000
--- a/Programming & Language/계층화 아키텍처 (Layered Architecture).md	
+++ /dev/null
@@ -1,38 +0,0 @@
----
-id: P-REINFORCE-AUTO-1EAECE
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - 계층화 아키텍처 (Layered Architecture)"
----
-
-# [[계층화 아키텍처 (Layered Architecture)]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 계층화 아키텍처(Layered Architecture)는 시스템을 특정 책임을 가진 여러 수평적 계층(Layer)으로 나누어 구성하는 전통적이고 영향력 있는 소프트웨어 설계 패턴입니다 [1]. 각 계층은 사용자 인터페이스, 비즈니스 로직, 데이터 접근 등 특정 관심사(Concern)만을 전담하여 엄격한 관심사의 분리(SoC)를 강제합니다 [1, 2]. 이를 통해 각 계층은 주로 인접한 계층과만 소통하게 되며, 결과적으로 시스템의 결합도를 낮추고 유지보수성, 확장성 및 테스트 용이성을 크게 향상시키는 것을 목표로 합니다 [1, 3].
-
-## 📖 구조화된 지식 (Synthesized Content)
-*   **개념 및 핵심 목표:** n-tier 아키텍처라고도 불리는 이 패턴은 애플리케이션의 기능적 영역을 수평적으로 격리합니다 [1]. 이를 통해 개발자는 다른 계층에 영향을 주지 않고 특정 계층의 코드를 수정하거나 테스트할 수 있으며, 이는 관심사의 분리(SoC)를 실무에 적용하는 가장 대표적인 방법론입니다 [1, 2].
-*   **'뇌와 팔다리의 분리' 관점의 적용:** 계층화 아키텍처에서 하위 계층(인프라, 데이터베이스 등 팔다리 역할)은 구체적인 기술적 세부 사항을 담당하며, 상위 계층(핵심 비즈니스 로직 등 뇌 역할)에 대해 전혀 알지 못하는 상태로 필요한 서비스를 제공합니다 [4-6]. 이 구조는 시스템의 핵심적인 '사고(비즈니스 규칙)' 영역이 외부의 잦은 기술적 변화로부터 오염되지 않고 순수성을 유지할 수 있도록 보호합니다 [7, 8].
-*   **전형적인 3계층 구조 (3-Tier Structure):** 현대 웹 애플리케이션 등에서 가장 흔히 볼 수 있는 계층 분리 방식은 다음과 같습니다.
-    *   **프레젠테이션 계층 (Presentation Layer):** 사용자 인터페이스(UI)와 사용자 경험(UX) 로직을 전담하며, 화면 렌더링 및 사용자 입력을 캡처하는 최상단 계층입니다 [2, 9].
-    *   **비즈니스 로직 계층 (Business Logic Layer / Domain Layer):** 애플리케이션의 핵심 업무 규칙과 프로세싱을 처리합니다. 프레젠테이션 계층과 독립적으로 존재하며 시스템의 동작을 제어합니다 [2, 9].
-    *   **데이터 액세스 계층 (Data Access Layer / Persistence Layer):** 데이터베이스와의 통신(CRUD 작업 등)을 전담합니다. 다른 계층이 데이터가 어떻게 저장되거나 조회되는지 그 세부 사항을 알 수 없도록 완벽하게 격리합니다 [2, 9].
-*   **성공적인 구현을 위한 공학적 원칙:**
-    *   **엄격한 통신 규칙 강제:** 시스템의 관리를 용이하게 하려면, 특정 계층은 바로 아래에 있는 인접한 계층과만 소통해야 합니다 [2, 3].
-    *   **인터페이스와 의존성 주입(DI) 활용:** 상위 계층이 하위 계층의 구체적인 구현에 의존하지 않도록 명확한 인터페이스를 정의하고 의존성 주입을 활용해야 합니다. 이를 통해 데이터베이스나 프레임워크가 변경되더라도 상위 계층의 코드는 수정할 필요가 없게 됩니다 [3, 4, 10].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[응집도와 결합도 (Cohesion and Coupling)]], [[단일 책임 원칙 (SRP)]], [[의존성 역전 원칙 (DIP)]], [[클린 아키텍처 (Clean Architecture)]]
-- **Projects/Contexts:** [[웹 애플리케이션의 3계층 구조]], [[엔터프라이즈 애플리케이션 설계]]
-- **Contradictions/Notes:** 소스는 계층화 아키텍처가 시스템의 복잡성을 줄이고 관심사를 성공적으로 격리한다고 긍정적으로 평가하지만, 동시에 지나친 관심사 분리(과도한 계층화 및 추상화)는 여러 계층을 거쳐야 하는 성능 오버헤드를 유발하거나, 오히려 코드를 추적하기 어렵게 만드는 '인디렉션의 저주(Curse of Indirection)'를 발생시킬 수 있다고 경고합니다 [11-13].
-
----
-*Last updated: 2026-04-18*
-- Raw Source: [[00_Raw/2026-04-20/계층화 아키텍처 (Layered Architecture).md]]
----
diff --git a/Programming & Language/고전적 조건 형성.md b/Programming & Language/고전적 조건 형성.md
deleted file mode 100644
index d69b1d71..00000000
--- a/Programming & Language/고전적 조건 형성.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-46AEE6
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - 고전적 조건 형성"
----
-
-# [[고전적 조건 형성]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/고전적 조건 형성.md]]
----
diff --git a/Programming & Language/공존 질환 (Comorbidity).md b/Programming & Language/공존 질환 (Comorbidity).md
deleted file mode 100644
index 93006dfa..00000000
--- a/Programming & Language/공존 질환 (Comorbidity).md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-ACDF2F
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - 공존 질환 (Comorbidity)"
----
-
-# [[공존 질환 (Comorbidity)]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/공존 질환 (Comorbidity).md]]
----
diff --git a/Programming & Language/과잉 속성 체크 (Excess Property Checking).md b/Programming & Language/과잉 속성 체크 (Excess Property Checking).md
deleted file mode 100644
index 20b1f451..00000000
--- a/Programming & Language/과잉 속성 체크 (Excess Property Checking).md	
+++ /dev/null
@@ -1,33 +0,0 @@
----
-id: P-REINFORCE-AUTO-9B5810
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - 과잉 속성 체크 (Excess Property Checking)"
----
-
-# [[과잉 속성 체크 (Excess Property Checking)]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> TypeScript의 과잉 속성 체크(Excess Property Checking, EPC)는 객체 리터럴이 다른 변수에 직접 할당되거나 함수의 인자로 전달될 때, 대상 타입에 정의되지 않은 속성이 포함되어 있는지를 엄격하게 검사하는 기능이다[1-4]. 이는 구조적 타이핑(Structural Typing)의 유연함으로 인해 속성 이름의 오타나 잘못된 데이터가 유입되어 발생하는 런타임 오류를 컴파일 시점에 방지하는TypeScript의 핵심 방어 기제로 작동한다[5-7].
-
-## 📖 구조화된 지식 (Synthesized Content)
-- **도입 배경 및 목적**: TypeScript는 기본적으로 객체의 형태(구조)가 일치하면 타입의 호환성을 인정하는 구조적 타이핑(덕 타이핑) 원칙을 따른다[7-9]. 그러나 대상 타입의 속성을 충족하더라도 오타(예: `color` 대신 `colour`를 입력)와 같은 실수로 잉여 속성이 포함되면 의도치 않은 런타임 동작이 발생할 수 있다[5, 6]. 이러한 한계를 보완하기 위해 TypeScript는 객체 리터럴에 대해 예외적으로 더 엄격한 잣대를 들이대는 '과잉 속성 체크'를 수행한다[1, 5].
-- **동작 방식과 한계 (우회 현상)**: 과잉 속성 체크는 객체 리터럴이 변수에 직접 할당되거나 인자로 전달되는 특수한 경우에만 작동한다[3, 5]. 만약 변수를 먼저 선언한 후 이를 다른 타입에 간접적으로 할당하거나 제네릭 타입 매개변수를 사용하는 경우, 두 객체 사이에 최소 하나의 공통 속성만 존재한다면 과잉 속성 체크가 작동하지 않는다[10-12]. 이는 시스템이 "최소 요건 충족"이라는 구조적 타이핑의 기본 원칙으로 되돌아가기 때문이다[12]. (단, 선택적 속성만 가진 '약한 타입(Weak Type)'의 경우에는 공통 속성이 아예 없으면 에러를 발생시키는 약한 타입 탐지가 작동한다[13, 14].)
-- **우회로 인한 부작용**: 간접 할당 등을 통해 과잉 속성 체크가 우회되면, 예상치 못한 잉여 데이터가 객체 내부에 숨어들 수 있다[12]. 이는 React 컴포넌트 등에서 유효하지 않은 속성이 DOM으로 넘어가 경고를 발생시키거나, 불필요한 리렌더링을 유발하고 런타임 시 보안 유출의 원인이 되기도 한다[12, 15]. 
-- **`satisfies` 연산자를 통한 방비**: `as` 키워드를 이용한 타입 캐스팅(Type Casting)은 과잉 속성 체크를 수행하지 않아 잠재적인 에러를 유발할 수 있다[16]. 이 같은 취약점을 보완하기 위해 TypeScript 4.9에 도입된 `satisfies` 연산자는 객체가 특정 인터페이스나 타입을 만족하는지 엄격히 검사하여 과잉 속성의 유입을 컴파일 단계에서 차단한다[17, 18]. 더불어 객체의 구체적인 값(리터럴 타입 등)을 유지해 정밀한 타입 추론과 타입 좁히기(Narrowing)를 돕는 혁신적인 수비 전략으로 활용된다[18-20].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[구조적 타이핑 (Structural Typing)]], [[satisfies 연산자]], [[타입 캐스팅 (Type Casting)]], [[약한 타입 탐지 (Weak Type Detection)]]
-- **Projects/Contexts:** [[철벽 수비대" - TypeScript 타입 시스템 (인터페이스 설계)]], [[React 컴포넌트 Props 검증]]
-- **Contradictions/Notes:** 객체 리터럴을 직접 할당할 때는 과잉 속성 체크가 발동되어 에러를 반환하지만, 중간 변수를 통해 간접 할당될 때는 구조적 타이핑 원칙이 적용되어 과잉 속성이 존재해도 에러가 발생하지 않는 모순적 동작을 보인다[1, 3, 5, 12]. 또한 `as` 연산자는 과잉 속성을 무시하고 할당을 허용하지만, `satisfies` 연산자는 초과된 속성에 대해 엄격한 검증을 강제한다[16, 21].
-
----
-*Last updated: 2026-04-18*
-- Raw Source: [[00_Raw/2026-04-20/과잉 속성 체크 (Excess Property Checking).md]]
----
diff --git a/Programming & Language/과잉 속성 체크(EPC).md b/Programming & Language/과잉 속성 체크(EPC).md
deleted file mode 100644
index 2f9979a2..00000000
--- a/Programming & Language/과잉 속성 체크(EPC).md	
+++ /dev/null
@@ -1,40 +0,0 @@
----
-id: P-REINFORCE-AUTO-13C5F5
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - 과잉 속성 체크(EPC)"
----
-
-# [[과잉 속성 체크(EPC)]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 과잉 속성 체크(EPC, Excess Property Checking)는 객체 리터럴을 변수에 직접 할당하거나 함수의 인수로 전달할 때, 예상치 못한(정의되지 않은) 속성이 포함되어 있는지 감지하여 에러를 발생시키는 TypeScript의 검사 기능입니다 [1], [2], [3]. 이는 속성명의 오타와 같은 개발자의 실수를 컴파일 시점에 방지하여 의도치 않은 런타임 버그를 예방하는 데 목적이 있습니다 [4], [5], [6].
-
-## 📖 구조화된 지식 (Synthesized Content)
-*   **작동 원리 및 발동 조건**
-    TypeScript는 기본적으로 객체의 실제 형태가 일치하면 호환성을 인정하는 구조적 타이핑(Structural Typing)을 따릅니다 [7]. 그러나 객체 리터럴의 경우에는 특별하게 취급되어, 다른 변수에 직접 할당되거나 인수로 전달될 때 과잉 속성 체크(EPC)가 활성화됩니다 [1], [3], [8]. 이때 객체 리터럴 내에 대상 타입에 정의되지 않은 초과 속성이 존재하면 TypeScript는 객체 리터럴이 알려진 속성만 지정할 수 있다며 컴파일 에러를 발생시킵니다 [9], [8].
-
-*   **설계 목적**
-    이 기능은 주로 잘못된 속성 이름을 입력하는 오류(예: `color`를 `colour`로 잘못 입력하는 경우)로부터 시스템을 보호하기 위해 존재합니다 [4], [5]. TypeScript는 개발자가 변수에 객체 리터럴을 직접 넘기는 상황에서는 잉여 속성을 전달할 의도가 없을 확률이 높다고 판단하여 보다 엄격한 잣대를 적용하는 것입니다 [5].
-
-*   **EPC의 한계와 우회(Bypass) 문제**
-    EPC는 객체 리터럴을 직접 다룰 때만 활성화된다는 취약점이 있습니다 [10]. 객체 리터럴을 먼저 중간 변수에 할당한 뒤 이를 다른 타입의 매개변수나 변수에 할당하게 되면, 최소 요건만 충족하면 통과시키는 구조적 타이핑 원칙으로 돌아가 과잉 속성 체크가 작동하지 않습니다 [1], [4], [11], [10]. 이러한 간접 할당을 통한 우회 현상은 불필요한 속성을 DOM에 전달하거나 예기치 않은 컴포넌트 리렌더링 및 보안 유출과 같은 런타임 문제를 야기할 수 있습니다 [12], [10]. 
-
-*   **보완 전략 및 `satisfies` 연산자**
-    EPC의 우회 문제를 방어하기 위해 개발자는 제네릭과 `never` 타입을 활용하여 초과 속성이 들어올 경우 컴파일이 실패하도록 수동으로 감지하는 재귀적 타입을 구축할 수 있습니다 [13], [14]. 더 근본적인 해결책으로는 TypeScript 4.9에 도입된 `satisfies` 연산자를 활용하는 것입니다 [15]. `satisfies` 연산자는 객체의 구체적인 타입(예: 리터럴 값 등)을 잃지 않으면서도 대상 인터페이스의 요구사항을 엄격히 검사하기 때문에, 간접 할당 과정에서도 과잉 속성을 차단하는 강력한 수비 전략을 제공합니다 [16], [15].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[구조적 타이핑(Structural Typing)]], [[satisfies 연산자]], [[객체 리터럴(Object Literals)]]
-- **Projects/Contexts:** [[TypeScript 타입 검사 시스템]], [[React 컴포넌트 Props 검사]]
-- **Contradictions/Notes:** 과잉 속성이 실제 버그를 유발하는 빈도에 대해서는 시각차가 존재합니다. 일부는 초과 속성이 런타임 이슈(리렌더링, 보안 문제)를 야기한다고 경고하지만 [12], [10], TypeScript-eslint 저장소의 일부 논의에서는 객체의 키나 값 세트에 대한 직접적인 연산이 없는 한 과잉 속성 자체가 실제로 버그를 유발하는 경우는 드물다고 주장합니다 [17].
-
----
-*Last updated: 2026-04-18*
-- Raw Source: [[00_Raw/2026-04-20/과잉 속성 체크(EPC).md]]
----
diff --git a/Programming & Language/과잉 속성 체크(Excess Property Checking).md b/Programming & Language/과잉 속성 체크(Excess Property Checking).md
deleted file mode 100644
index 372e70ee..00000000
--- a/Programming & Language/과잉 속성 체크(Excess Property Checking).md	
+++ /dev/null
@@ -1,32 +0,0 @@
----
-id: P-REINFORCE-AUTO-7ED2D3
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - 과잉 속성 체크(Excess Property Checking)"
----
-
-# [[과잉 속성 체크(Excess Property Checking)]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 과잉 속성 체크(Excess Property Checking)는 TypeScript에서 객체 리터럴을 다른 변수에 직접 할당하거나 함수의 인자로 전달할 때, 예상치 못한(정의되지 않은) 잉여 속성이 포함되어 있는지 엄격하게 검사하여 에러를 발생시키는 기능입니다 [1-4]. 구조적 타이핑의 유연성 속에서 발생할 수 있는 오타나 잘못된 속성 전달 실수를 컴파일 시점에 포착하여 런타임 오류를 방지하는 첫 번째 방어선 역할을 합니다 [5-7].
-
-## 📖 구조화된 지식 (Synthesized Content)
-- **구조적 타이핑의 보완 장치**: TypeScript는 기본적으로 객체가 요구되는 최소한의 속성을 가지고 있다면 타입 호환성을 인정하는 구조적 타이핑(Structural Typing, 일명 덕 타이핑)을 사용합니다 [7, 8]. 그러나 이 유연성으로 인해 `color`를 `colour`로 잘못 입력하는 등의 오타가 발생해도 호환되는 것으로 판단될 위험이 있습니다 [6]. TypeScript는 객체 리터럴을 직접 다루는 상황에서는 개발자가 잉여 속성을 전달할 의도가 없었을 것이라 간주하여 더 엄격한 과잉 속성 체크를 적용해 실수를 방지합니다 [5-7].
-- **발동 조건 및 한계 (우회로)**: 과잉 속성 체크는 "객체 리터럴"이 대상 타입에 직접 할당되거나 인수로 전달될 때만 특별하게 동작합니다 [3-5]. 만약 객체 리터럴을 먼저 중간 변수에 선언 및 할당한 뒤, 해당 변수를 대상 타입에 간접적으로 할당하면 이 기능은 작동하지 않습니다 [3, 5, 9, 10]. 변수를 거치게 되면 구조적 타이핑의 기본 원칙인 "최소 요건 충족"으로 돌아가기 때문에, 대상 타입과 최소 하나의 속성만 겹치면 초과 속성이 존재하더라도 에러를 발생시키지 않게 됩니다 [10, 11].
-- **잠재적 위험과 `satisfies`를 통한 해결**: 간접 할당을 통해 과잉 속성 체크를 우회하게 될 경우, React 컴포넌트에 유효하지 않은 속성이 전달되거나 불필요한 리렌더링이 발생하는 등 런타임 버그의 원인이 될 수 있습니다 [10, 12, 13]. 이를 해결하기 위해 TypeScript 4.9에 도입된 `satisfies` 연산자를 활용할 수 있습니다 [14]. `satisfies`는 객체의 구체적인 타입(리터럴 타입 등)을 잃지 않고 유지하면서도, 대상 인터페이스의 요구사항을 엄격하게 검사하여 간접 할당 시에도 과잉 속성을 효과적으로 차단합니다 [14, 15].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[구조적 타이핑(Structural Typing)]], [[satisfies 연산자]], [[약한 타입 검사(Weak Type Detection)]]
-- **Projects/Contexts:** [[TypeScript의 인터페이스 및 객체 타입 설계]], [[React 컴포넌트 Props 전달 및 상태 관리]]
-- **Contradictions/Notes:** TypeScript는 구조적 타이핑을 핵심 철학으로 삼지만, "객체 리터럴"에 대해서만 과잉 속성 체크라는 예외적으로 엄격한 잣대를 적용합니다. 이로 인해 값을 직접 전달할 때와 중간 변수를 거쳐 전달할 때의 타입 검사 결과가 달라지는 동작 방식의 차이가 존재합니다 [3, 5, 11].
-
----
-*Last updated: 2026-04-18*
-- Raw Source: [[00_Raw/2026-04-20/과잉 속성 체크(Excess Property Checking).md]]
----
diff --git a/Programming & Language/과잉 정당화 효과 (Overjustification Effect).md b/Programming & Language/과잉 정당화 효과 (Overjustification Effect).md
deleted file mode 100644
index 49934c37..00000000
--- a/Programming & Language/과잉 정당화 효과 (Overjustification Effect).md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-CB8555
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - 과잉 정당화 효과 (Overjustification Effect)"
----
-
-# [[과잉 정당화 효과 (Overjustification Effect)]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/과잉 정당화 효과 (Overjustification Effect).md]]
----
diff --git a/Programming & Language/관심사의 분리 (Separation of Concerns SoC).md b/Programming & Language/관심사의 분리 (Separation of Concerns SoC).md
deleted file mode 100644
index d82e962e..00000000
--- a/Programming & Language/관심사의 분리 (Separation of Concerns SoC).md	
+++ /dev/null
@@ -1,43 +0,0 @@
----
-id: P-REINFORCE-AUTO-CE39CC
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - 관심사의 분리 (Separation of Concerns SoC)"
----
-
-# [[관심사의 분리 (Separation of Concerns SoC)]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 관심사의 분리(SoC)는 복잡한 소프트웨어 시스템을 더 작고 관리하기 쉬운 부분으로 나누어, 각 모듈이 단일한 관심사(기능이나 책임)만을 다루도록 설계하는 소프트웨어 공학의 근본적인 원칙이다 [1-3]. 1974년 에츠허르 데이크스트라(Edsger W. Dijkstra)가 처음 제안한 이 개념은 한 번에 모든 측면을 다루는 대신 특정 측면에 집중하여 복잡성을 통제하는 것을 목표로 한다 [4-6]. 이 원칙을 통해 시스템의 모듈성, 유지보수성, 재사용성 및 테스트 가능성을 획기적으로 향상시킬 수 있다 [1, 7, 8].
-
-## 📖 구조화된 지식 (Synthesized Content)
-* **주요 개념 및 메커니즘**
-  * **모듈화(Modularity):** 프로그램을 기능별로 독립된 모듈로 분할하여, 각 모듈이 특정 역할만 수행하도록 구성한다 [7, 9].
-  * **응집도(Cohesion):** 모듈 내의 요소들이 하나의 명확한 목적을 위해 얼마나 밀접하게 관련되어 있는지를 나타내며, SoC는 기능적 응집도를 높여 코드 가독성과 유지보수성을 극대화하는 것을 지향한다 [9-11].
-  * **결합도(Coupling):** 모듈 간의 상호 의존성을 의미하며, 느슨한 결합(Low Coupling)을 통해 한 모듈의 변경이 다른 모듈에 미치는 영향을 최소화한다 [7, 10, 12, 13].
-
-* **적용 및 구현 사례**
-  * **웹 개발(HTML/CSS/JS):** HTML은 구조, CSS는 표현(스타일), JavaScript는 동작을 담당하도록 기술과 역할을 엄격히 분리하여 개발의 복잡성을 관리한다 [14-16].
-  * **계층화 아키텍처(Layered Architecture):** 시스템을 프레젠테이션 계층(UI), 비즈니스 로직 계층, 데이터 액세스 계층 등으로 나누어 각 층의 책임을 분리하며, MVC(Model-View-Controller) 패턴이 대표적이다 [17-20].
-  * **마이크로서비스(Microservices):** 애플리케이션을 특정 비즈니스 기능(도메인)을 처리하는 작고 독립적인 서비스 단위로 분해하여 각 팀이 자율적으로 개발, 배포할 수 있게 한다 [17, 21, 22].
-  * **로보틱스 제어 시스템:** 소프트웨어를 넘어 하드웨어 측면에서도 센서(입력 및 인지), 컨트롤러(두뇌 및 의사결정), 액추에이터(출력 및 물리적 동작)로 역할을 명확히 분리하여 복잡한 시스템의 제어를 구현한다 [23, 24].
-
-* **장점 및 한계**
-  * **장점:** 코드의 명확성이 향상되고, 기능을 수정할 때 영향을 받는 코드가 국소화되어 시스템의 확장과 유지보수가 용이해진다 [25-28]. 또한, 각 부분이 격리되어 있어 다수의 엔지니어가 병렬로 개발하기 좋고 단위 테스트가 훨씬 수월해진다 [25, 26, 28].
-  * **한계(오버헤드):** 완벽한 분리를 맹목적으로 추구하면 불필요한 레이어와 인디렉션(Indirection)이 추가되어 오히려 코드 추적과 디버깅을 어렵게 만들 수 있다 [29, 30]. 또한 분산 환경에서는 계층 간 데이터 변환 및 통신 오버헤드에 따른 성능 저하가 발생할 수 있다 [31]. 이를 방지하기 위해 코드 중복이 세 번 이상 발견될 때 비로소 추상화와 분리를 고려하는 "Rule of Three"와 같은 실무적 지침이 권장된다 [30, 32, 33].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[단일 책임 원칙 (Single Responsibility Principle, SRP)]], [[응집도 (Cohesion)]], [[결합도 (Coupling)]], [[계층화 아키텍처 (Layered Architecture)]], [[마이크로서비스 아키텍처 (Microservices Architecture)]]
-- **Projects/Contexts:** [[넷플릭스 코스모스 플랫폼 (Netflix Cosmos Platform)]] (마이크로서비스, 워크플로우, 서버리스 함수로 논리적 계층을 엄격히 분리하여 병목 현상을 해결한 사례 [34-36]), [[스포티파이 마이크로 프론트엔드 (Spotify Micro Frontends)]] (스쿼드 조직 모델과 프론트엔드의 관심사를 분리하여 독립적 개발과 배포를 가능하게 한 사례 [22]).
-- **Contradictions/Notes:** 관심사의 분리는 훌륭한 설계 지침이지만, 개발 초기 단계부터 모든 것을 선제적으로 추측하여 분리하려 하면 '오버엔지니어링'이나 '성급한 추상화(Premature Abstraction)'가 발생할 수 있다. 이는 인지적 부하를 줄이려는 SoC의 본래 목적과 정반대의 결과를 낳을 수 있으므로, 실제 중복과 복잡성이 확인되는 임계점에서 점진적으로 분리를 수행해야 한다는 실무자들의 지적이 있다 [29, 30, 33, 37].
-
----
-*Last updated: 2026-04-18*
-- Raw Source: [[00_Raw/2026-04-20/관심사의 분리 (Separation of Concerns, SoC).md]]
----
diff --git a/Programming & Language/관심사의 분리 (Separation of Concerns).md b/Programming & Language/관심사의 분리 (Separation of Concerns).md
deleted file mode 100644
index 7c10d4b0..00000000
--- a/Programming & Language/관심사의 분리 (Separation of Concerns).md	
+++ /dev/null
@@ -1,45 +0,0 @@
----
-id: P-REINFORCE-AUTO-FE2B8D
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - 관심사의 분리 (Separation of Concerns)"
----
-
-# [[관심사의 분리 (Separation of Concerns)]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 관심사의 분리(SoC)는 소프트웨어 설계에서 프로그램의 각 부분이 서로 다른 고유한 기능이나 특정 관심사에만 집중하도록 시스템을 논리적 단위로 나누는 근본적인 원칙입니다 [1-3]. 1974년 에츠허르 데이크스트라(Edsger W. Dijkstra)가 인간의 지적 한계로 인한 복잡성을 통제하기 위해 제안한 개념으로, 시스템을 관리하기 쉬운 조각으로 분해하여 모듈성, 유지보수성, 재사용성 및 확장성을 극대화하는 것을 목표로 합니다 [1, 3-6]. 시스템의 핵심 비즈니스 로직과 기술적 세부 사항을 명확히 격리함으로써, 변화에 유연하게 대응하고 진화할 수 있는 견고한 아키텍처를 구축하는 데 필수적인 철학입니다 [7-9].
-
-## 📖 구조화된 지식 (Synthesized Content)
-**기원과 철학적 패러다임**
-*   관심사 분리의 기원은 에츠허르 데이크스트라가 1974년 발표한 에세이 "과학적 사고의 역할에 관하여"로 거슬러 올라갑니다 [3]. 그는 복잡한 문제를 해결할 때 인간의 정신이 압도당하지 않도록 특정 측면에 주의를 집중하고 다른 측면을 분리해서 사고하는 것이 지적 사고의 핵심이라고 강조했습니다 [3, 6]. 이 원칙은 후대 학자들에 의해 소프트웨어 모듈성(Modularity)을 확보하는 일차적인 방법으로 정립되었으며, 객체 지향 설계의 SOLID 원칙(특히 단일 책임 원칙과 인터페이스 분리 원칙)의 모태가 되었습니다 [3, 7].
-
-**"뇌와 팔다리의 분리" 은유 (핵심 구조)**
-*   관심사 분리를 가장 직관적으로 설명하는 비유는 시스템을 '뇌(Brain)'와 '팔다리(Limbs)'로 구분하는 것입니다 [7]. 
-*   **뇌 (Core/Brain):** 아키텍처의 심장부로, 시스템이 존재하는 근본 이유인 고수준의 '비즈니스 엔티티'와 '유스케이스'를 포함합니다 [10-12]. 이 영역은 외부 시스템(데이터베이스, UI, 프레임워크 등)의 영향을 받지 않는 순수한 상태로 보존되어야 하며 가장 높은 재사용성과 독립성을 지녀야 합니다 [12, 13].
-*   **팔다리 (Peripheral/Limbs):** 핵심 로직을 감싸고 외부 세계와 물리적으로 소통하는 저수준의 세부 사항입니다. SQL 쿼리, REST API, HTML/CSS 웹 인터페이스, 서드파티 라이브러리 등이 포함되며, 핵심 로직을 변경하지 않고 언제든 교체 가능한 '플러그인' 형태로 존재해야 합니다 [12, 13].
-*   **신경계 (Wiring):** 뇌와 팔다리 사이의 상호작용을 중재하는 인터페이스나 DTO 등의 소통 경로로, 의존성 역전을 통해 느슨한 결합을 유지합니다 [14, 15].
-
-**구현을 위한 공학적 척도: 응집도와 결합도**
-*   **높은 응집도 (High Cohesion):** 모듈 내부의 요소들이 하나의 명확한 목적을 위해 얼마나 밀접하게 관련되어 있는지를 나타냅니다. 기능적 응집도가 높은 코드는 가독성이 좋고 단위 테스트가 쉬우며 수정 시 영향 범위가 한정됩니다 [2, 16-18].
-*   **낮은 결합도 (Low Coupling):** 한 모듈이 시스템의 다른 부분에 의존하는 정도를 최소화하는 것을 의미합니다. 구체적인 구현이 아닌 인터페이스를 참조하거나 의존성 주입(DI)을 통해 모듈 간의 독립성을 보장하여 예상치 못한 부작용을 방지합니다 [2, 19-21].
-
-**아키텍처 및 산업 적용 사례**
-*   **소프트웨어 아키텍처:** 프레젠테이션, 비즈니스 로직, 데이터 액세스 계층으로 나누는 3계층 구조와 도메인 주도 설계(DDD)의 바운디드 컨텍스트, 클린 아키텍처 등이 대표적인 관심사 분리의 구현체입니다 [8, 22-24]. 이때 소스 코드 의존성은 항상 외부(저수준)에서 내부(고수준 정책)를 향해야 한다는 '의존성 규칙'이 적용됩니다 [25].
-*   **다양한 산업의 관심사 분리:** HTML(구조), CSS(표현), JS(동작)의 웹 표준 기술 [26, 27], 로보틱스 제어 시스템에서의 센서(입력), 컨트롤러(뇌), 액추에이터(근육) 분리 [28], 건축 산업에서의 모듈러 통합 건설(MiC) [29] 등 물리적, 시스템적 복잡성을 다루는 광범위한 영역에 적용됩니다.
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[응집도와 결합도 (Cohesion and Coupling)]], [[클린 아키텍처 (Clean Architecture)]], [[단일 책임 원칙 (Single Responsibility Principle)]], [[의존성 규칙 (Dependency Rule)]]
-- **Projects/Contexts:** [[넷플릭스 코스모스 플랫폼 (Netflix Cosmos Platform)]], [[스포티파이 자율적 분대 모델 및 마이크로 프론트엔드 (Spotify Squads and Micro Frontends)]], [[화신산 병원 모듈러 통합 건설 (Huoshenshan Hospital Modular Construction)]]
-- **Contradictions/Notes:** 관심사의 분리는 시스템의 복잡성을 낮추지만, 맹목적으로 추구하여 과도하게 분리할 경우 함수 호출의 깊이 증가, 네트워크 지연, 데이터 변환 오버헤드 등 성능 저하를 초래할 수 있습니다 [30]. 또한 지나친 추상화는 개발자를 미궁에 빠뜨려 가독성을 저하시키는 '오버엔지니어링'의 부작용을 낳을 수 있으므로, 유사 코드가 최소 3번 이상 중복될 때 추상화를 고려하는 "Rule of Three"를 참고하여 실무적인 분리의 임계점을 찾아야 합니다 [31, 32].
-
----
-*Last updated: 2026-04-18*
-- Raw Source: [[00_Raw/2026-04-20/관심사의 분리 (Separation of Concerns).md]]
----
diff --git a/Programming & Language/관심사의 분리 (SoC).md b/Programming & Language/관심사의 분리 (SoC).md
deleted file mode 100644
index d4f4a6fd..00000000
--- a/Programming & Language/관심사의 분리 (SoC).md	
+++ /dev/null
@@ -1,45 +0,0 @@
----
-id: P-REINFORCE-AUTO-441E04
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - 관심사의 분리 (SoC)"
----
-
-# [[관심사의 분리 (SoC)]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 관심사의 분리(SoC)는 시스템을 구성하는 요소를 서로 겹치지 않는 독립적인 모듈로 나누어, 각 부분이 특정 기능이나 목적(관심사)에만 집중하도록 설계하는 소프트웨어 공학의 핵심 원칙이다 [1, 2]. 1974년 에츠허르 데이크스트라가 제안한 이 개념은 복잡한 문제를 해결할 때 인간의 인지적 한계를 고려해 한 번에 하나의 측면에만 집중할 것을 강조한다 [3, 4]. 특히 아키텍처 관점에서 "뇌와 팔다리의 분리"라는 비유로 설명되며, 시스템의 본질인 핵심 비즈니스 로직(뇌)과 이를 외부에 연결하는 기술적 인프라(팔다리)를 격리하여 유지보수성과 재사용성을 극대화하는 것을 목표로 한다 [5, 6].
-
-## 📖 구조화된 지식 (Synthesized Content)
-* **철학적 기원과 인지적 해부:** 
-관심사의 분리는 에츠허르 데이크스트라(Edsger W. Dijkstra)가 1974년에 발표한 에세이 "과학적 사고의 역할에 관하여"에서 기원하였다 [4, 7]. 그는 복잡한 시스템을 다룰 때 지적인 사고를 위해서는 한 측면에 깊이 집중하고 다른 측면을 일시적으로 무시하는 능력이 필수적이라고 역설했다 [4, 7]. 이러한 철학적 패러다임은 이후 객체 지향 설계의 단일 책임 원칙(SRP) 등으로 발전하였으며, 소프트웨어의 복잡성을 통제하기 위한 논리적 단위 격리의 기초가 되었다 [5].
-
-* **"뇌와 팔다리의 분리" 비유:** 
-아키텍처에서 관심사의 분리를 가장 직관적으로 나타내는 은유는 시스템의 고수준 정책과 저수준 세부 사항을 각각 뇌와 팔다리에 비유하여 엄격히 격리하는 것이다 [5, 6].
-  * **뇌 (고수준 도메인 및 비즈니스 엔티티):** 시스템이 존재하는 근본적인 이유인 핵심 업무 규칙을 캡슐화한 '엔티티(Entity)'와 이들의 상호작용을 제어하는 '유스케이스(Use Case)'로 구성된다 [6, 8, 9]. 뇌에 해당하는 영역은 데이터베이스나 사용자 인터페이스(UI) 등 외부 환경의 영향을 받지 않는 가장 순수하고 독립적인 형태로 유지되어야 한다 [6, 10].
-  * **팔다리 (저수준 세부 사항 및 플러그인):** 핵심 로직을 감싸고 외부 세계와 소통하는 웹 인터페이스, 데이터베이스, 서드파티 프레임워크 등을 의미한다 [6]. 이들 외부 시스템은 언제든 교체가 가능하도록 '플러그인'의 형태를 취해야 하며, 코드의 의존성 방향은 항상 저수준의 팔다리에서 고수준의 뇌를 향해야만 한다 [6, 11, 12].
-
-* **공학적 구현 척도 (응집도와 결합도):** 
-관심사의 분리가 올바르게 구현되었는지 판단하는 공학적 척도는 '높은 응집도(High Cohesion)'와 '낮은 결합도(Low Coupling)'이다 [13, 14]. 동일한 목적을 수행하는 밀접한 기능들은 한 모듈에 묶어 내부 결속력인 응집도를 극대화해야 한다 [13, 15, 16]. 반대로 모듈 간의 외부 상호작용은 인터페이스 사용이나 의존성 주입(DI) 등을 통해 최소화하여 낮은 결합도를 유지함으로써, 한 부품의 변경이나 고장이 전체 시스템으로 전파되는 것을 차단해야 한다 [13, 17-19].
-
-* **다양한 분야로의 물리적/산업적 확장:** 
-이러한 설계 원칙은 소프트웨어 코드를 넘어 다양한 기술 및 산업 분야에서도 근간이 된다.
-  * **웹 표준:** 초창기 혼재되어 있던 웹 문서는 HTML(구조), CSS(표현), JavaScript(동작)로 각각의 역할에 맞게 엄격히 분리되어 관심사 분리의 정수를 보여준다 [20, 21].
-  * **로보틱스:** 로봇 시스템 또한 센서(입력 및 오감), 컨트롤러(알고리즘 및 뇌), 액추에이터(물리적 출력 및 근육)라는 명확히 분리된 하드웨어 및 소프트웨어 구성 요소들의 협업 구조로 작동한다 [22, 23].
-  * **건설 산업 (MiC):** 건축물의 기능을 하위 시스템으로 분해해 공장에서 사전 제작한 후 현장에서 조립하는 '모듈러 통합 건설(MiC)' 역시 복잡한 건축 구조 관리를 단순화하는 물리적 차원의 SoC 적용 사례이다 [24].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[단일 책임 원칙 (SRP)]], [[응집도와 결합도]], [[클린 아키텍처 (Clean Architecture)]]
-- **Projects/Contexts:** [[넷플릭스 코스모스 플랫폼 (Netflix Cosmos)]], [[스포티파이 자율적 분대 모델 (Spotify Squad)]], [[모듈러 통합 건설 (MiC)]]
-- **Contradictions/Notes:** 관심사의 분리는 시스템의 가독성, 테스트 가능성, 재사용성을 비약적으로 향상시키지만 [25-27], 이를 맹목적으로 추구하여 과도하게 분리할 경우 함수 호출의 뎁스를 깊게 만들거나 간접 참조가 늘어나 오히려 인지적 부하와 성능 오버헤드(Overengineering)를 유발할 수 있다 [28-30]. 따라서 실무에서는 성급한 추상화를 피하고, 동일한 패턴이 세 번 반복될 때 비로소 분리를 고려하는 "Rule of Three"와 같이 실용적인 임계점을 찾아 균형을 맞추어야 한다 [30].
-
----
-*Last updated: 2026-04-18*
-- Raw Source: [[00_Raw/2026-04-20/관심사의 분리 (SoC).md]]
----
diff --git a/Programming & Language/관심사의 분리(Separation of Concerns).md b/Programming & Language/관심사의 분리(Separation of Concerns).md
deleted file mode 100644
index 520cd923..00000000
--- a/Programming & Language/관심사의 분리(Separation of Concerns).md	
+++ /dev/null
@@ -1,43 +0,0 @@
----
-id: P-REINFORCE-AUTO-55088F
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - 관심사의 분리(Separation of Concerns)"
----
-
-# [[관심사의 분리(Separation of Concerns)]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 관심사의 분리(Separation of Concerns, SoC)는 복잡한 소프트웨어 시스템을 작고 관리하기 쉬운 개별 부분으로 나누어, 각 부분이 단일한 기능적 측면이나 '관심사'만을 처리하도록 설계하는 핵심 소프트웨어 공학 원칙입니다 [1-3]. 1974년 에츠허르 데이크스트라(Edsger W. Dijkstra)가 인간의 인지적 한계를 극복하고 복잡성을 제어하기 위해 처음 제안한 철학에 기원을 두고 있습니다 [4-6]. 이 원칙은 모듈 내의 응집도(Cohesion)를 높이고 모듈 간의 결합도(Coupling)를 낮추어 시스템의 유지보수성, 재사용성, 테스트 가능성 및 확장성을 극대화하는 것을 목표로 합니다 [7-10].
-
-## 📖 구조화된 지식 (Synthesized Content)
-*   **주요 개념 및 철학**:
-    *   **관심사(Concern)의 정의**: 시스템 내의 특정한 기능적 측면, 동작 또는 책임을 의미합니다(예: 사용자 인터페이스 렌더링, 비즈니스 로직 처리, 데이터베이스 접근 등) [3, 11, 12].
-    *   **응집도와 결합도**: 좋은 SoC 설계는 모듈 내부의 요소들이 하나의 명확한 목적을 위해 협력하는 '높은 응집도(High Cohesion)'와, 모듈 간 상호 의존성을 최소화하는 '낮은 결합도(Low Coupling)'를 지향합니다 [7-10, 13].
-*   **관심사 분리를 통한 이점**:
-    *   **유지보수 및 확장성의 향상**: 시스템의 한 부분을 수정하더라도 다른 부분에 미치는 영향(사이드 이펙트)을 최소화할 수 있어, 변화하는 요구사항에 맞춰 안전하게 유지보수하고 유연하게 확장할 수 있습니다 [14-16].
-    *   **독립적인 테스트 가능성**: 개별 모듈이 외부 인프라(데이터베이스, UI 등)와 격리되어 있으므로, 가짜 객체(Mock)나 더미 데이터를 이용한 독립적인 단위 테스트가 수월해집니다 [16, 17].
-    *   **병렬 개발 및 협업 효율성**: 역할의 경계가 명확하게 설정되므로, 여러 개발자나 팀이 서로의 작업에 간섭하지 않고 동시에 병렬로 개발을 진행할 수 있습니다 [14, 17, 18].
-*   **실무 적용 및 아키텍처 패턴**:
-    *   **웹 표준 기술**: 웹 개발에서 구조를 담당하는 HTML, 표현을 담당하는 CSS, 동적 동작을 담당하는 JavaScript로 나누어 개발하는 것이 가장 고전적인 관심사 분리의 예시입니다 [19-21].
-    *   **계층화 아키텍처 (Layered Architecture)**: 프레젠테이션 계층, 비즈니스 로직 계층, 데이터 액세스 계층 등 논리적 층으로 나누어 역할과 책임을 엄격히 분리하는 방식입니다 [22-25]. MVC(Model-View-Controller) 패턴이 대표적입니다 [22, 26].
-    *   **마이크로서비스 아키텍처 (MSA)**: 거대한 모놀리식(Monolithic) 시스템을 작고 독립적인 비즈니스 기능(마이크로서비스)들로 쪼개어 분리하는 접근법입니다 [22, 27-29].
-*   **한계 및 주의사항**:
-    *   **과도한 분리의 부작용**: 관심사를 맹목적으로 혹은 지나치게 잘게 쪼개면 추상화 계층이 늘어나고 간접 참조가 증가해, 오히려 코드의 실행 흐름을 파악하기 어렵게 만드는 '오버엔지니어링'이 발생할 수 있습니다 [30, 31].
-    *   **조정 및 성능 오버헤드**: 분리된 모듈이나 서비스 간에 통신해야 할 일이 늘어나며, 특히 분산 시스템에서는 네트워크 지연 및 직렬화 비용 등 성능 오버헤드가 동반될 수 있습니다 [30, 32, 33].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[단일 책임 원칙(SRP)]], [[응집도(Cohesion)와 결합도(Coupling)]], [[계층화 아키텍처(Layered Architecture)]]
-- **Projects/Contexts:** [[넷플릭스(Netflix)의 코스모스(Cosmos) 플랫폼과 마이크로서비스 전환]], [[스포티파이(Spotify)의 마이크로 프론트엔드 및 스쿼드 모델]], [[HTML, CSS, JavaScript의 웹 표준 3요소 분리]]
-- **Contradictions/Notes:** 많은 개발 가이드라인은 관심사의 분리를 선제적으로 엄격히 설계할 것을 권장하지만, 일부 전문가들은 코드 작성 초기부터 완벽하게 관심사를 예측하여 분리하는 것은 불가능하다고 주장합니다 [34, 35]. 대신, 유사한 코드가 3번 이상 반복될 때 추출하는 'Rule of Three'처럼, 반복되는 패턴을 확인한 뒤에 경험적으로 사후에 분리하는 실용적이고 점진적인 접근(DRY 원칙과 병행)을 강조합니다 [31, 35, 36].
-
----
-*Last updated: 2026-04-18*
-- Raw Source: [[00_Raw/2026-04-20/관심사의 분리(Separation of Concerns).md]]
----
diff --git a/Programming & Language/관심사의 분리(SoC).md b/Programming & Language/관심사의 분리(SoC).md
deleted file mode 100644
index c3a1a288..00000000
--- a/Programming & Language/관심사의 분리(SoC).md	
+++ /dev/null
@@ -1,44 +0,0 @@
----
-id: P-REINFORCE-AUTO-1BA61A
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - 관심사의 분리(SoC)"
----
-
-# [[관심사의 분리(SoC)]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 관심사의 분리(SoC, Separation of Concerns)는 소프트웨어 시스템을 각기 다른 기능이나 책임(관심사)에만 집중하는 작고 관리하기 쉬운 독립적인 모듈로 나누는 소프트웨어 엔지니어링의 핵심 설계 원칙이다 [1-5]. 1974년 에츠허르 데이크스트라(Edsger W. Dijkstra)가 처음 제안한 개념으로, 복잡성을 통제하고 코드의 모듈성, 가독성, 유지보수성, 확장성 및 재사용성을 크게 향상시키는 것을 목표로 한다 [3, 4, 6, 7]. 이 철학은 객체 지향 설계의 단일 책임 원칙(SRP)과 인터페이스 분리 원칙(ISP) 등 현대 아키텍처 패턴이 탄생하는 직접적인 근간이 되었다 [5, 8-10].
-
-## 📖 구조화된 지식 (Synthesized Content)
-*   **원칙의 기원과 진화:** 
-    관심사의 분리라는 용어는 에츠허르 데이크스트라가 1974년 논문 "과학적 사고의 역할에 관하여"에서 '단일 트랙적이면서 동시에 멀티 트랙적인 사고방식'을 통해 복잡한 문제를 고립시켜 집중해야 한다고 주장하면서 등장했다 [11, 12]. 이후 1960~70년대의 구조적 프로그래밍부터 객체 지향 프로그래밍(OOP) 시대를 거쳐 MVC 패러다임, 마이크로서비스 아키텍처(MSA) 등 대규모 시스템을 설계하는 필수 원칙으로 진화해왔다 [8, 10, 13, 14].
-*   **핵심 메커니즘 (응집도와 결합도):** 
-    SoC를 성공적으로 구현했는지 판단하는 주요 척도는 높은 응집도(High Cohesion)와 낮은 결합도(Low/Loose Coupling)이다 [3, 15-17]. 응집도는 모듈 내부의 요소들이 하나의 명확한 목적을 위해 얼마나 밀접하게 관련되어 있는지를 나타내며, 결합도는 모듈 간의 상호 의존성 정도를 뜻한다 [3, 18, 19]. 좋은 설계는 내부 결속력인 응집도를 극대화하고 외부 간섭에 해당하는 결합도를 최소화하는 최적화를 지향한다 [20, 21].
-*   **적용 수준과 다양한 사례:**
-    *   **함수 및 모듈 수준:** 각 함수나 모듈은 단일 작업에 집중하도록 분리되어야 한다. 이를 통해 코드가 스파게티처럼 얽히는 것을 방지하고 가독성과 테스트 가능성을 향상시킨다 [22-24].
-    *   **소프트웨어 아키텍처 수준:** 핵심 비즈니스 로직(뇌)과 외부 인프라(팔다리)를 분리하는 것이 핵심이다 [25]. 웹 기반 시스템에서는 프레젠테이션 계층, 비즈니스 로직 계층, 데이터 액세스 계층으로 관심사를 분리하여 의존성이 단방향(주로 내부 핵심 도메인을 향해)으로 흐르도록 설계한다 [21, 26, 27].
-    *   **웹 프론트엔드:** 전통적인 HTML(구조), CSS(표현), JavaScript(동작)의 역할별 분리가 가장 직관적인 SoC 사례이다 [28-30]. 최근에는 프로젝트의 규모가 커짐에 따라 기능(Feature) 단위로 관심사를 묶어 관리하는 FSD(Feature-Sliced Design) 방식 등으로 진화하고 있다 [31, 32].
-    *   **로보틱스 제어 시스템:** 로봇 또한 인지적 해부와 동일하게 외부 자극을 감지하는 센서(눈/귀), 의사결정을 내리는 컨트롤러(뇌), 물리적 운동을 수행하는 액추에이터(근육)로 하드웨어적 관심사를 명확히 분리하여 구동된다 [33, 34].
-*   **주요 이점:** 
-    시스템을 모듈화하면 특정 기능을 수정하거나 확장할 때 다른 코드에 미치는 부작용을 최소화할 수 있어 유지보수성이 크게 향상된다 [35-37]. 여러 명의 개발자가 각기 다른 모듈을 맡아 서로 방해받지 않고 병렬(동시) 개발을 수행할 수 있으며 [35, 38, 39], 비즈니스 로직을 데이터베이스나 UI 등 외부 시스템으로부터 격리시켜 독립적이고 신속한 단위 테스트 환경을 조성할 수 있다 [27, 40, 41].
-*   **한계 및 실무적 고려사항:** 
-    관심사를 맹목적이고 과도하게 분리(Over-engineering)하면 오히려 계층 간 통신 및 데이터 변환 오버헤드가 증가하여 시스템 성능을 떨어뜨릴 수 있다 [42, 43]. 층을 너무 얇게 나누거나 과도한 추상화를 도입할 경우, 실제 구현을 파악하기 위해 수많은 계층을 넘나들어야 하므로 개발자의 인지적 부하가 오히려 가중될 위험(인디렉션의 저주)이 존재한다 [42, 44, 45].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[단일 책임 원칙(SRP)]], [[응집도(Cohesion)와 결합도(Coupling)]], [[계층화 아키텍처(Layered Architecture)]], [[모델-뷰-컨트롤러(MVC)]], [[관점 지향 프로그래밍(AOP)]]
-- **Projects/Contexts:** [[넷플릭스 코스모스(Cosmos) 플랫폼]], [[스포티파이 스쿼드(Squad) 및 마이크로 프론트엔드]], [[화신산(Huoshen Mountain) 병원 모듈러 통합 건설(MiC)]]
-- **Contradictions/Notes:** 
-    * "SoC를 도입하면 유지보수와 모듈성이 향상된다"는 원칙이 일반적이나, "지나친 관심사 분리와 추상화는 간접 참조를 늘리고 런타임 성능 저하 및 코드 추적의 어려움을 유발하여 실무적 복잡성을 오히려 가중시킨다"는 경고와 상충하는 지점이 있다 [42-45].
-    * 관심사의 선제적인 도출이 필수적이라는 견해가 있는 반면, 다른 실무자들은 초기에 관심사를 미리 예측해 분리하는 것은 불가능에 가까우며, 코드가 중복되어 나타날 때(Rule of Three) 사후적으로 리팩토링을 통해 분리하는 것(DRY 관점)이 현실적이라는 상반된 주장을 한다 [45, 46].
-
----
-*Last updated: 2026-04-18*
-- Raw Source: [[00_Raw/2026-04-20/관심사의 분리(SoC).md]]
----
diff --git a/Programming & Language/관점 지향 프로그래밍 (AOP).md b/Programming & Language/관점 지향 프로그래밍 (AOP).md
deleted file mode 100644
index b2310600..00000000
--- a/Programming & Language/관점 지향 프로그래밍 (AOP).md	
+++ /dev/null
@@ -1,39 +0,0 @@
----
-id: P-REINFORCE-AUTO-A9FD39
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - 관점 지향 프로그래밍 (AOP)"
----
-
-# [[관점 지향 프로그래밍 (AOP)]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 관점 지향 프로그래밍(Aspect-Oriented Programming, AOP)은 소프트웨어 개발에서 시스템 전체에 흩어져 있는 횡단 관심사(Cross-Cutting Concerns)를 주요 비즈니스 로직과 분리하여 모듈화하는 프로그래밍 기법입니다 [1]. 이는 객체 지향 프로그래밍(OOP)의 단점을 보완하여 코드 중복을 최소화하고 가독성 및 유지보수성을 향상시키는 역할을 합니다 [1, 2]. 로깅, 보안, 트랜잭션 관리 등 여러 모듈에 공통으로 쓰이는 기능들을 중앙에서 효과적으로 관리할 때 주로 도입됩니다 [3, 4].
-
-## 📖 구조화된 지식 (Synthesized Content)
-- **핵심 개념 및 구성 요소**
-  - **횡단 관심사 (Cross-Cutting Concerns):** 시스템의 여러 모듈에 공통적으로 적용되는 로깅, 보안, 캐싱 등의 기능을 의미하며, AOP는 이를 수평적으로 분리하여 캡슐화합니다 [1, 2]. 
-  - **애스펙트 (Aspect):** 횡단 관심사를 정의하고 구현한 모듈 자체를 뜻합니다 [2].
-  - **조인 포인트 (Join Point):** 메서드 호출, 객체 생성, 예외 처리 등 프로그램 실행 중 Aspect를 적용할 수 있는 특정 지점들을 의미합니다 [2]. 
-  - **포인트컷 (Pointcut):** 다양한 Join Point 중에서 실제로 Aspect를 적용할 지점(특정 메서드나 클래스 등)을 선언적으로 지정하는 조건입니다 [5].
-  - **어드바이스 (Advice):** Pointcut으로 선택된 Join Point에서 실제로 수행되는 작업(코드 블록)으로, 실행 타이밍(@Before, @After, @Around 등)을 정의합니다 [5].
-  - **위빙 (Weaving):** Aspect와 애플리케이션의 실제 코드를 결합하는 과정이며, 컴파일 시점(Compile time), 로드 시점(Load time), 또는 실행 시점(Runtime)에 이루어집니다 [5].
-
-- **주요 활용 사례**
-  - **로깅 및 모니터링:** 시스템 성능을 추적하거나 빈번하게 호출되는 메서드를 파악하기 위해 실행 시간을 측정하고 로그를 남기는 데 사용됩니다 [3].
-  - **트랜잭션 및 보안:** 애플리케이션의 컨트롤러나 서비스 전반에 걸친 사용자의 인증 상태/권한 확인 로직이나, 트랜잭션(예: `@Transactional` 어노테이션) 처리를 횡단 관심사로 분리하여 적용합니다 [3].
-
-- **장단점 및 고려사항**
-  - **장점:** 공통 관심사를 중앙에서 관리하여 코드의 중복을 제거하고, 런타임에 새로운 기능을 손쉽게 추가할 수 있어 유지보수성이 크게 향상됩니다 [2, 4].
-  - **단점:** Aspect가 런타임에 적용될 경우 코드의 실행 흐름을 직관적으로 추적하기 어렵고 디버깅이 복잡해질 수 있습니다 [4, 6]. 또한, 런타임 처리에 따른 성능 오버헤드가 발생할 수 있어 실시간 처리 시스템과 같이 성능에 민감한 환경에서는 도입에 주의가 필요합니다 [4].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/관점 지향 프로그래밍 (AOP).md]]
----
diff --git a/Programming & Language/관점 지향 프로그래밍(AOP).md b/Programming & Language/관점 지향 프로그래밍(AOP).md
deleted file mode 100644
index f6c1853d..00000000
--- a/Programming & Language/관점 지향 프로그래밍(AOP).md	
+++ /dev/null
@@ -1,45 +0,0 @@
----
-id: P-REINFORCE-AUTO-B943FA
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - 관점 지향 프로그래밍(AOP)"
----
-
-# [[관점 지향 프로그래밍(AOP)]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 관점 지향 프로그래밍(AOP, Aspect-Oriented Programming)은 소프트웨어 개발 시 로깅, 보안 등 시스템 전체에 공통으로 사용되는 횡단 관심사(Cross-Cutting Concerns)를 주요 비즈니스 로직으로부터 분리하여 모듈화하는 프로그래밍 기법이다 [1-3]. 이는 객체 지향 프로그래밍(OOP)의 단점을 보완하며, 공통된 기능을 수평적으로 분리해 코드의 단순화와 명확한 역할 분리를 돕는다 [1, 2]. 결과적으로 AOP를 도입하면 코드의 중복을 제거할 수 있고, 가독성과 유지보수성이 크게 향상되는 이점을 얻을 수 있다 [2].
-
-## 📖 구조화된 지식 (Synthesized Content)
-**AOP의 주요 구성 요소**
-* **Aspect (관점):** 횡단 관심사(Cross-Cutting Concerns)를 정의하고 구체적으로 구현한 모듈 자체를 의미한다 [2, 4].
-* **Join Point (조인 포인트):** 애플리케이션 실행 중 Aspect가 적용될 수 있는 지점이다. 주로 메서드 호출, 객체 생성, 예외 처리 시점 등에 발생하며, Spring AOP의 경우 메서드 실행 시점만 지원한다 [2, 4].
-* **Advice (어드바이스):** Pointcut으로 선택된 Join Point에서 실제로 실행될 구체적인 코드 블록 및 동작이다. 실행 타이밍에 따라 `@Before`, `@After`, `@AfterReturning`, `@AfterThrowing`, `@Around` 등으로 정의할 수 있다 [4, 5].
-* **Pointcut (포인트컷):** 다수의 Join Point 중에서 Aspect를 실제로 적용할 지점을 선언적으로 지정(특정 메서드, 클래스, 패키지 등)하는 역할을 한다 [4, 5].
-* **Weaving (위빙):** 정의된 Aspect를 애플리케이션의 실제 코드와 결합하는 과정이다. 적용 시점에 따라 컴파일 시점(Compile time), 클래스 로드 시점(Load time), 런타임 시점(Runtime) 위빙으로 나뉜다 [4, 5].
-
-**AOP의 주요 활용 사례**
-* **로깅(Logging) 및 보안 검사:** 특정 API 호출이나 예외가 발생할 때 이를 일관되게 로깅하거나, 여러 컨트롤러에 중복으로 작성해야 하는 인증 및 권한 확인 코드를 중앙에서 처리하도록 분리한다 [3, 4].
-* **트랜잭션 및 캐싱:** `@Transactional` 어노테이션과 같이 트랜잭션 관리 로직을 분리하거나, 자주 호출되는 메서드 결과를 캐싱하여 성능을 개선하는 데 활용된다 [4].
-* **성능 모니터링:** 특정 메서드의 실행 시간을 측정하여 애플리케이션 성능을 추적하고 서비스 수준 협약(SLA)을 준수하는 데 사용된다 [4].
-
-**AOP의 장단점 및 도입 기준**
-* **장점:** 공통 관심사를 중앙화하여 코드 중복을 최소화하고, 다양한 모듈에서 횡단 관심사를 캡슐화하여 런타임에 새로운 기능을 손쉽게 추가할 수 있다 [6]. 또한, 보안과 같은 횡단 관심사를 부차적인 것이 아닌 주요 관심사로 다룰 수 있게 하여 안전한 설계를 돕는다 [3].
-* **단점:** 런타임에 Aspect가 적용되는 경우 코드의 실행 흐름을 직관적으로 추적하기 어려울 수 있으며, 처리 과정에서 약간의 성능 오버헤드가 발생한다 [6]. 오용하거나 과용하면 시스템의 복잡도가 오히려 증가한다 [6].
-* **도입 기준:** 반복적인 작업이 많은 대규모 애플리케이션에서는 도입이 매우 효과적이지만, 단순한 작업만 수행하는 소규모 프로젝트에서는 과도한 설계(Over-engineering)가 될 수 있다 [6]. 또한, 성능 오버헤드에 민감한 실시간 처리 시스템의 경우 사용에 신중해야 한다 [6].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[객체 지향 프로그래밍(OOP)]], [[횡단 관심사(Cross-Cutting Concerns)]], [[관심사의 분리(SoC)]]
-- **Projects/Contexts:** [[Spring AOP]], [[AspectJ]]
-- **Contradictions/Notes:** 소스들 간에 직접적인 모순은 없으나, AOP 도입에 대한 명확한 트레이드오프(Trade-off)가 강조된다. AOP는 횡단 관심사를 분리하여 코드 품질과 유지보수성을 높이는 훌륭한 해결책이지만, 과도하게 사용할 경우 런타임 코드 추적을 어렵게 만들고 오히려 복잡도를 증가시킬 수 있다는 점을 주의해야 한다 [6].
-
----
-*Last updated: 2026-04-18*
-- Raw Source: [[00_Raw/2026-04-20/관점 지향 프로그래밍(AOP).md]]
----
diff --git a/Programming & Language/광범위한 신경과학적 연합 기제.md b/Programming & Language/광범위한 신경과학적 연합 기제.md
deleted file mode 100644
index 981b894e..00000000
--- a/Programming & Language/광범위한 신경과학적 연합 기제.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-2AE4FF
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - 광범위한 신경과학적 연합 기제"
----
-
-# [[광범위한 신경과학적 연합 기제]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/광범위한 신경과학적 연합 기제.md]]
----
diff --git a/Programming & Language/교육 심리학에서의 학습 동기 유도.md b/Programming & Language/교육 심리학에서의 학습 동기 유도.md
deleted file mode 100644
index 1baebe32..00000000
--- a/Programming & Language/교육 심리학에서의 학습 동기 유도.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-C63490
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - 교육 심리학에서의 학습 동기 유도"
----
-
-# [[교육 심리학에서의 학습 동기 유도]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/교육 심리학에서의 학습 동기 유도.md]]
----
diff --git a/Programming & Language/교육 심리학에서의 학습 동기 유발.md b/Programming & Language/교육 심리학에서의 학습 동기 유발.md
deleted file mode 100644
index 1475fcdb..00000000
--- a/Programming & Language/교육 심리학에서의 학습 동기 유발.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-A6A206
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - 교육 심리학에서의 학습 동기 유발"
----
-
-# [[교육 심리학에서의 학습 동기 유발]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/교육 심리학에서의 학습 동기 유발.md]]
----
diff --git a/Programming & Language/교집합 타입 (Intersection Types).md b/Programming & Language/교집합 타입 (Intersection Types).md
deleted file mode 100644
index 76041f1e..00000000
--- a/Programming & Language/교집합 타입 (Intersection Types).md	
+++ /dev/null
@@ -1,33 +0,0 @@
----
-id: P-REINFORCE-AUTO-795BA0
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - 교집합 타입 (Intersection Types)"
----
-
-# [[교집합 타입 (Intersection Types)]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-- **기본 개념 및 동작 원리:** 교집합 타입은 다수의 타입을 결합하여 하나의 타입으로 만듭니다. 예를 들어, `Person & Serializable & Loggable` 타입의 객체는 이 세 가지 타입이 가진 모든 멤버를 포함하게 됩니다 [1]. 집합론적 관점에서 `&` 연산자는 단순한 객체 형태의 결합이 아니라 '값 집합(value sets)'의 교집합을 의미하며, 결합된 모든 제약 조건을 동시에 만족하는 대상들의 집합을 나타냅니다 [4].
-- **인터페이스 확장(Interface Extends)과의 비교 및 성능:** TypeScript는 객체 타입을 결합하거나 확장할 때 교집합 타입보다 인터페이스의 `extends` 기능을 사용하는 것을 권장합니다 [6, 7]. 인터페이스는 단일한 평면 객체 타입을 생성하고 그 이름을 기반으로 관계를 캐싱하여 컴파일 성능을 최적화합니다 [6, 8-10]. 반면, 교집합 타입은 사용될 때마다 매번 구조를 재귀적으로 병합하고 평가해야 하므로 대규모 프로젝트에서는 컴파일 속도 저하의 원인이 될 수 있습니다 [6, 10].
-- **타입 충돌 처리의 차이점:** 두 타입을 결합할 때 호환되지 않는 속성이 존재하는 경우, 인터페이스 상속은 개발자에게 명시적인 에러를 발생시켜 실수를 방지합니다 [9, 11]. 반면 교집합 타입은 충돌하는 속성을 조용히 처리하여, 그 결과로 절대 존재할 수 없는 `never` 타입을 생성해버리는 특징이 있습니다 [9, 11].
-- **실용적 활용:** 교집합 타입은 여러 출처에서 기능을 모아와야 할 때 유용합니다. 예를 들어 일관된 에러 처리 타입을 기존의 특정 네트워크 응답 타입에 결합하거나, `User` 타입에 `AdminPermissions` 속성을 더해 `AdminUser`를 생성하는 식의 모델링에 사용됩니다 [3, 12].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[유니언 타입 (Union Types)]], [[인터페이스 (Interfaces)]], [[구조적 타이핑 (Structural Typing)]]
-- **Projects/Contexts:** [[TypeScript 컴파일러 성능 최적화]], [[객체 타입 조합 및 확장]]
-- **Contradictions/Notes:** 교집합 타입(`&`)은 유연하게 여러 객체를 결합할 수 있는 수단이지만, 성능 최적화와 명시적 충돌 에러 감지의 이점 때문에 TypeScript 공식 가이드나 성능 가이드라인에서는 가능한 경우 인터페이스 확장(`extends`)을 더 우선적으로 사용할 것을 권장합니다 [6, 7, 9].
-
----
-*Last updated: 2026-04-18*
-- Raw Source: [[00_Raw/2026-04-20/교집합 타입 (Intersection Types).md]]
----
diff --git a/Programming & Language/교집합 타입(Intersection Type).md b/Programming & Language/교집합 타입(Intersection Type).md
deleted file mode 100644
index 1efecc69..00000000
--- a/Programming & Language/교집합 타입(Intersection Type).md	
+++ /dev/null
@@ -1,44 +0,0 @@
----
-id: P-REINFORCE-AUTO-4ECB5E
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - 교집합 타입(Intersection Type)"
----
-
-# [[교집합 타입(Intersection Type)]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 교집합 타입(Intersection Type)은 여러 개의 타입을 결합하여 필요한 모든 기능을 갖춘 단일 타입을 생성하는 TypeScript의 타입 구성 문법입니다 [1]. `&` 연산자를 사용하여 정의하며, 결합된 모든 구성 타입의 제약 조건과 속성을 동시에 만족(A AND B)해야 합니다 [2, 3]. 이를 통해 기존에 정의된 여러 객체의 구조나 기능을 재사용하여 복잡하고 확장된 타입을 유연하게 만들 수 있습니다 [1, 4].
-
-## 📖 구조화된 지식 (Synthesized Content)
-*   **기본 개념과 활용**
-    *   교집합 타입은 다수의 타입을 하나로 묶어, 해당 타입들의 모든 멤버를 포함하는 단일 타입을 생성합니다 [1]. 
-    *   예를 들어, `Person & Serializable & Loggable` 타입으로 선언된 객체는 이 세 가지 타입에 정의된 모든 속성과 메서드를 반드시 포함해야 합니다 [1]. 
-    *   이러한 패턴은 기존 타입들의 기능을 더해 확장하거나 여러 능력을 결합할 때 매우 유용하게 사용됩니다 [4].
-    *   집합론적 관점에서 `A & B` 연산은 A와 B의 제약 조건을 모두 충족하는 값들의 교집합을 의미하며, `A & never`와 같은 연산의 결과는 항상 빈 집합인 `never`가 됩니다 [5-8].
-
-*   **유니언 타입(Union Type)과의 차이**
-    *   유니언 타입(`|`)이 주어진 타입들 중 하나만 만족(A OR B)해도 되는 유연성을 제공한다면, 교집합 타입(`&`)은 결합된 모든 타입을 엄격하게 충족(A AND B)해야 한다는 근본적인 차이가 있습니다 [2, 3].
-    *   두 가지 타입 시스템은 상호보완적이며, 함께 조합하면 더욱 유연하고 타입에 안전한 데이터 구조를 모델링할 수 있습니다 [9, 10].
-
-*   **인터페이스 확장(Interface Extends)과의 비교 및 성능 고려사항**
-    *   TypeScript에서 객체 타입을 확장할 때는 교집합 타입보다는 인터페이스의 `extends` 기능을 사용하는 것이 더 권장됩니다 [11-13].
-    *   인터페이스 확장은 단일한 평탄화(flattened) 객체 타입을 생성하고 속성 충돌을 명확하게 감지하며, 타입 검사 결과를 이름 기준으로 캐싱하여 컴파일 성능을 향상시킵니다 [12-14].
-    *   반면, 교집합 타입은 사용할 때마다 내부적으로 속성을 재귀적으로 병합하는 복잡한 계산 과정을 거쳐야 하므로 대규모 프로젝트에서 컴파일 속도를 저하시킬 수 있습니다 [12, 13, 15].
-    *   더욱이 교집합은 호환되지 않는 필드를 병합할 때 명시적으로 경고하기보다 조용히 `never` 타입을 생산하거나 필드를 무시할 수 있어, 타입 안전성 측면에서도 인터페이스 확장이 더 안전한 선택으로 평가받습니다 [13, 16].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[유니언 타입(Union Type)]], [[인터페이스(Interface)]], [[집합론(Set Theory)]]
-- **Projects/Contexts:** [[API 도메인 모델 구조화 및 설정 객체(Configuration Objects) 관리]], [[TypeScript 컴파일 성능 최적화]]
-- **Contradictions/Notes:** 여러 타입을 합칠 때 교집합 타입(`&`)이 흔히 사용되지만, TypeScript 공식 성능 가이드와 개발 커뮤니티에서는 객체를 확장할 경우 컴파일 캐싱 및 성능 이점, 에러 방지를 위해 교집합 타입보다 `interface extends`의 사용을 적극적으로 권장합니다 [12, 13, 17].
-
----
-*Last updated: 2026-04-18*
-- Raw Source: [[00_Raw/2026-04-20/교집합 타입(Intersection Type).md]]
----
diff --git a/Programming & Language/구조적 타이핑 (Structural Typing).md b/Programming & Language/구조적 타이핑 (Structural Typing).md
deleted file mode 100644
index 73673ee0..00000000
--- a/Programming & Language/구조적 타이핑 (Structural Typing).md	
+++ /dev/null
@@ -1,41 +0,0 @@
----
-id: P-REINFORCE-AUTO-66BE32
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - 구조적 타이핑 (Structural Typing)"
----
-
-# [[구조적 타이핑 (Structural Typing)]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-*   **구조적 타이핑의 작동 원리와 집합론적 접근**
-    TypeScript의 구조적 타이핑은 자바(Java)나 C#과 같은 언어에서 사용하는 명목적 타이핑(Nominal Typing)과 궤를 달리한다 [2]. 명목적 타이핑이 특정한 신분증(타입 이름)을 요구한다면, 구조적 타이핑은 열쇠의 모양(객체의 구조)만 맞으면 자물쇠를 열 수 있게 해준다 [5]. 할당하고자 하는 값이 타겟 타입이 가진 프로퍼티를 최소한으로 모두 포함하고 있다면, 구조적으로 호환되는 것으로 판단하여 할당을 허용한다 [3]. 이는 집합론의 관점에서, 더 구체적인 구조를 가진 타입이 더 일반적인 타입의 부분집합으로 취급되어 할당 가능한 관계로 평가되는 것과 같다 [5].
-
-*   **클래스와의 호환성 규칙**
-    이러한 구조적 특성은 클래스에도 동일하게 적용된다. 두 개의 다른 타입이 어디서 유래했든 상관없이 모든 멤버의 타입이 호환된다면, 해당 타입들은 호환되는 것으로 취급된다 [7]. 다만 예외적으로 `private`이나 `protected` 멤버가 포함된 경우, 두 타입이 호환되려면 해당 접근 제어자 멤버들이 반드시 동일한 선언에서 기원한 것이어야 한다 [7].
-
-*   **구조적 타이핑의 취약점과 한계**
-    1.  **의도하지 않은 데이터 유입:** 구조적 타이핑은 요구되는 속성만 있으면 그 외의 초과 속성(Excess Properties)이 존재하더라도 이를 구조적으로 호환된다고 판단한다 [4, 5]. 이로 인해 개발자가 오타를 내거나 잘못된 속성 이름을 전달했을 때 런타임의 예기치 않은 동작이나 버그가 발생할 수 있다 [4]. 
-    2.  **기본 타입에의 집착(Primitive Obsession):** 이메일 주소와 사용자의 이름은 의미론적으로 완전히 다르지만, TypeScript의 구조적 타이핑 하에서는 둘 다 동일한 `string` 구조를 가지므로 이를 구분해 내지 못한다 [6, 8].
-
-*   **취약점을 극복하기 위한 수비적 장치**
-    구조적 타이핑이 야기할 수 있는 보안적 허점을 방어하기 위해 TypeScript는 추가적인 메커니즘을 제공한다. 객체 리터럴이 직접 할당되거나 인수로 전달될 때는 구조적 호환성을 넘어 '과잉 속성 체크(Excess Property Checking)'를 수행하여 정의되지 않은 속성을 엄격하게 차단한다 [1, 5]. 또한, 의미론적으로 다른 동일 구조의 데이터를 구별하기 위해 고유한 표식을 부여하는 '브랜디드 타입(Branded Types)' 패턴을 도입하여 데이터 오염을 원천적으로 막을 수 있다 [6, 9].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[명목적 타이핑 (Nominal Typing)]], [[덕 타이핑 (Duck Typing)]], [[과잉 속성 체크 (Excess Property Checking)]], [[브랜디드 타입 (Branded Types)]]
-- **Projects/Contexts:** [[TypeScript 인터페이스 및 시스템 보호 아키텍처 설계]]
-- **Contradictions/Notes:** TypeScript는 기본적으로 구조적 타이핑을 따르지만, 객체 리터럴을 직접 할당할 때에 한해서는 잉여 속성을 허용하지 않는 엄격한 "과잉 속성 체크(Excess Property Checking)"를 수행하여 유연성과 안전성의 균형을 맞춘다 [1, 5, 10].
-
----
-*Last updated: 2026-04-18*
-- Raw Source: [[00_Raw/2026-04-20/구조적 타이핑 (Structural Typing).md]]
----
diff --git a/Programming & Language/구조적 타이핑(Structural Typing).md b/Programming & Language/구조적 타이핑(Structural Typing).md
deleted file mode 100644
index 5a7900ad..00000000
--- a/Programming & Language/구조적 타이핑(Structural Typing).md	
+++ /dev/null
@@ -1,43 +0,0 @@
----
-id: P-REINFORCE-AUTO-25EFF5
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - 구조적 타이핑(Structural Typing)"
----
-
-# [[구조적 타이핑(Structural Typing)]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 구조적 타이핑은 TypeScript 타입 시스템의 근본적인 원칙으로, 타입의 이름이나 명시적 선언이 아닌 객체의 실제 형태(구조)에 기반하여 타입 호환성을 결정하는 방식입니다 [1, 2]. 이는 "만약 어떤 것이 오리처럼 걷고 갉갉거리면 그것은 오리다"라는 '덕 타이핑(Duck Typing)' 개념으로도 불리며, 대상 타입이 요구하는 최소한의 속성과 메서드를 갖추고 있다면 잉여 속성이 있더라도 호환되는 것으로 간주합니다 [1-3]. 이 시스템은 유연성을 제공하지만, 의미론적 구분이 필요한 상황에서는 한계를 보일 수 있어 이를 보완하는 다양한 기법들이 함께 사용됩니다 [4-6].
-
-## 📖 구조화된 지식 (Synthesized Content)
-* **타입 호환성의 기본 규칙:**
-  구조적 타이핑 하에서 한 타입(`y`)이 다른 타입(`x`)과 호환되려면 `y`가 최소한 `x`가 가진 모든 멤버를 포함하고 있어야 합니다 [1]. 변수 할당 시, 우변의 값이 타겟 타입의 속성을 모두 충족하기만 한다면 다른 잉여 속성을 가지고 있더라도 구조적으로 호환되는 것으로 간주되어 할당이 허용됩니다 [1].
-
-* **명목적 타이핑(Nominal Typing)과의 차이:**
-  Java나 C#과 같은 전통적인 객체 지향 언어에서 사용하는 명목적 타이핑은 타입의 이름이나 명시적 상속/구현 선언이 일치해야만 호환성이 인정됩니다 [2, 7]. 반면, TypeScript는 객체의 구조(속성과 메서드의 형태)만 일치하면 동일한 타입 혹은 호환 가능한 타입으로 처리하는 유연성을 갖습니다 [2].
-
-* **과잉 속성 체크(Excess Property Checking)를 통한 방어:**
-  구조적 타이핑의 유연함은 오타(예: `color` 대신 `colour` 입력)를 내거나 의도치 않은 데이터를 전달하는 실수를 유발할 수 있습니다 [8, 9]. 이를 방지하기 위해 TypeScript는 객체 리터럴이 변수에 직접 할당되거나 함수의 인자로 전달될 때 예외적으로 엄격하게 동작하는 '과잉 속성 체크'를 발동시킵니다 [3, 10, 11]. 이를 통해 타겟 인터페이스에 정의되지 않은 잉여 속성이 포함되는 것을 컴파일 시점에 차단합니다 [3, 10].
-
-* **구조적 타이핑의 한계와 브랜디드 타입(Branded Types):**
-  구조적 타이핑은 속성 구조가 동일하면 타입이 같다고 간주하기 때문에, 동일한 구조를 가졌지만 의미가 전혀 다른 데이터(예: IP와 URL, 일반 문자열과 보안 처리된 문자열, 각기 다른 통화 등)를 구별하지 못하는 문제를 야기합니다 [4-6, 12-14]. 이를 극복하기 위해, 런타임에는 존재하지 않지만 컴파일 시점에만 존재하는 고유한 가상의 속성(브랜드)을 타입에 부여하여 명목적 타이핑과 유사한 강력한 격리를 제공하는 브랜디드 타입(또는 Opaque Types) 기법이 사용됩니다 [6, 14-16].
-
-* **`satisfies` 연산자의 활용:**
-  할당 시 중간 변수를 거치면 과잉 속성 체크가 우회되는 구조적 타이핑의 취약점을 보완하기 위해 `satisfies` 연산자를 활용할 수 있습니다 [17-19]. 이 연산자는 객체가 특정 구조를 만족하는지 엄격하게 검사(과잉 속성 방지)하면서도, 할당된 객체 속성의 구체적인 리터럴 타입과 잉여 속성 정보를 그대로 유지하게 해줍니다 [19-21].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[덕 타이핑(Duck Typing)]], [[명목적 타이핑(Nominal Typing)]], [[과잉 속성 체크(Excess Property Checking)]], [[브랜디드 타입(Branded Types)]], [[satisfies 연산자]]
-- **Projects/Contexts:** [[TypeScript 타입 시스템 아키텍처 및 도메인 기반 설계(DDD)]]
-- **Contradictions/Notes:** 객체 리터럴을 직접 할당하거나 인자로 넘길 때는 예기치 않은 잉여 속성에 대해 엄격한 에러를 발생시키는 반면, 값을 미리 변수에 선언한 뒤 간접적으로 할당할 때는 최소 요건만 충족하면 잉여 속성을 무시하고 할당을 허용하는 동작 방식의 차이가 존재합니다 [8, 10, 17, 18].
-
----
-*Last updated: 2026-04-18*
-- Raw Source: [[00_Raw/2026-04-20/구조적 타이핑(Structural Typing).md]]
----
diff --git a/Programming & Language/구조적 타이핑.md b/Programming & Language/구조적 타이핑.md
deleted file mode 100644
index f7d87c16..00000000
--- a/Programming & Language/구조적 타이핑.md	
+++ /dev/null
@@ -1,32 +0,0 @@
----
-id: P-REINFORCE-AUTO-E8243F
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - 구조적 타이핑"
----
-
-# [[구조적 타이핑]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 구조적 타이핑(Structural Typing)은 객체의 명시적인 이름이나 선언 대신, 객체가 가진 실제 형태와 구조(속성과 메서드)가 일치하면 타입 간의 호환성을 인정하는 타입 시스템입니다[1-3]. 이는 "어떤 것이 오리처럼 걷고 소리를 낸다면 오리다"라는 이른바 '덕 타이핑(Duck typing)' 원칙에 기반하며 TypeScript 타입 검사의 핵심 철학입니다[2, 4, 5]. 타입의 이름이 일치해야만 호환되는 Java나 C#의 명목적 타이핑(Nominal Typing)과는 대비되는 유연한 접근 방식입니다[2].
-
-## 📖 구조화된 지식 (Synthesized Content)
-- **동작 원리 및 호환성 판단:** 구조적 타이핑 하에서는 대상 타입 `y`가 요구하는 최소한의 멤버를 할당하려는 객체 `x`가 모두 포함하고 있다면, 두 타입을 호환 가능한 것으로 취급합니다[4]. 즉, 객체의 기원이나 명시적 선언 여부에 상관없이 요구되는 속성 구조만 일치하면 동일한 타입으로 계약을 만족하는 것으로 간주되며, 이는 집합론의 부분집합 관계로 설명할 수 있습니다[3, 6, 7].
-- **유연성과 한계:** 구조적 타이핑은 소프트웨어 개발에 큰 유연성을 제공하지만, 역설적으로 '구조가 동일한 서로 다른 데이터'를 시스템이 구분하지 못하는 문제(예: 이메일과 이름이 모두 문자열 구조인 경우)인 '기본 타입에의 집착(Primitive Obsession)'을 야기할 수 있습니다[8, 9]. 또한, 최소 요건만 충족하면 호환성을 인정하는 특성 탓에 의도치 않은 추가 속성을 가진 잉여 데이터가 유입될 수 있는 보안적 허점이 발생할 수 있습니다[3, 10].
-- **타입 안정성을 위한 보완 기제:** TypeScript는 이러한 구조적 타이핑의 잠재적 위험성을 방어하기 위해 객체 리터럴이 직접 할당될 때 대상 타입에 없는 속성이 포함되었는지를 컴파일 시점에 튕겨내는 '과잉 속성 체크(Excess Property Checking)' 메커니즘을 지원합니다[1, 3, 11]. 더불어 구조가 같으나 의미론적으로 다른 데이터를 엄격히 분리하기 위해서는 고유한 표식을 부여하는 '브랜디드 타입(Branded Types)'과 같은 명목적 타이핑 기법을 차용해 수비력을 높입니다[9, 12].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[명목적 타이핑]], [[덕 타이핑]], [[과잉 속성 체크]], [[브랜디드 타입]]
-- **Projects/Contexts:** [[TypeScript 타입 시스템 설계]], [[도메인 기반 설계(DDD)]]
-- **Contradictions/Notes:** 소스에 따르면 구조적 타이핑은 TypeScript에 강력한 유연성을 부여하는 근간이지만, 동시에 의미론적으로 다른 데이터를 구별하지 못하거나 불필요한 속성이 섞여 들어오는 구조적 취약점을 지니기 때문에 과잉 속성 체크나 브랜디드 타입과 같은 추가적인 방어 전략이 반드시 동반되어야 합니다[1, 3, 9].
-
----
-*Last updated: 2026-04-18*
-- Raw Source: [[00_Raw/2026-04-20/구조적 타이핑.md]]
----
diff --git a/Programming & Language/기본 타입에의 집착 (Primitive Obsession).md b/Programming & Language/기본 타입에의 집착 (Primitive Obsession).md
deleted file mode 100644
index baa0b954..00000000
--- a/Programming & Language/기본 타입에의 집착 (Primitive Obsession).md	
+++ /dev/null
@@ -1,41 +0,0 @@
----
-id: P-REINFORCE-AUTO-29E29A
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - 기본 타입에의 집착 (Primitive Obsession)"
----
-
-# [[기본 타입에의 집착 (Primitive Obsession)]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> '기본 타입에의 집착(Primitive Obsession)'은 서로 다른 의미와 맥락을 지닌 데이터를 구별하지 않고 범용적인 원시 기본 타입(예: `string`, `number`)만 사용하여 코드를 작성하려는 안티 패턴을 의미합니다 [1, 2]. TypeScript와 같은 구조적 타이핑 환경에서는 이메일 주소와 이름이 모두 `string`으로 취급되어, 의도치 않은 잘못된 값이 전달되더라도 컴파일러가 오류를 잡아내지 못하는 취약점을 발생시킵니다 [2]. 이를 방지하고 타입의 의미적 경계를 명확히 하기 위해, 런타임에는 동일한 원시 값이지만 컴파일 단계에서는 서로 다르게 구별되도록 강제하는 브랜디드 타입(Branded Types)이나 오패크 타입(Opaque Types) 기법이 해결책으로 활용됩니다 [2, 3].
-
-## 📖 구조화된 지식 (Synthesized Content)
-* **개념 및 원인**
-  * 현대 애플리케이션에서는 토큰, 리소스 식별자, 이벤트 이름 등을 모두 `string`으로 타이핑하고 통화, 타임스탬프, 내부 카운터 등을 모두 `number`로 뭉뚱그려 처리하는 경향이 있습니다 [1].
-  * TypeScript의 구조적 타이핑(Structural Typing)은 객체의 형태가 일치하면 같은 타입으로 간주하므로 유연성이 높지만, 이로 인해 의미적으로 전혀 다른 데이터를 구분하지 못하는 '기본 타입에의 집착' 문제를 본질적으로 야기하게 됩니다 [2].
-
-* **발생할 수 있는 위험성**
-  * **식별 불가능성**: 함수 매개변수로 사용자 ID와 계정 ID를 전달할 때 둘 다 `string`으로 타이핑되어 있다면, 매개변수의 순서를 실수로 바꿔서 전달해도 TypeScript 컴파일러가 에러를 발생시키지 않아 런타임 버그로 이어집니다 [2, 3].
-  * **역사적 실패 사례**: 마스 클라이메이트 오비터(Mars Climate Orbiter) 프로젝트는 단위계(파운드-힘 초 vs 뉴턴-초)가 다른 숫자를 단순 원시 타입으로 혼용하여 연산하다가 탐사선이 파괴되는 치명적인 시스템 실패를 겪기도 했습니다 [4]. 
-
-* **해결 방법론**
-  * **명목적 구분의 부여**: TypeScript는 기본적으로 명목적 타이핑(Nominal Typing)을 지원하지 않으나, '오패크 타입(Opaque Types)' 또는 '브랜디드 타입(Branded Types)'을 도입하여 이 한계를 극복할 수 있습니다 [5, 6]. 
-  * **브랜딩(Branding) 기법**: `unique symbol`이나 고유 속성(`__brand`)을 기존 원시 타입과 교집합(`&`)으로 엮어 런타임 데이터 표현에는 영향을 주지 않으면서 컴파일 시점에만 존재하는 엄격한 고유 표식을 부여합니다 [2, 6, 7].
-  * **데이터 오염 차단**: 도메인 기반 설계(DDD) 관점에서는 이 기법을 이용해 `UserId`와 `OrderId`를 엄격히 분리하고, 런타임 검증을 통과한 데이터(예: `SanitizedString`)만이 시스템의 내부 비즈니스 로직으로 진입하도록 강제함으로써 데이터가 오염되는 것을 원천 차단합니다 [2, 8].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[구조적 타이핑 (Structural Typing)]], [[명목적 타이핑 (Nominal Typing)]], [[브랜디드 타입 (Branded Types)]], [[오패크 타입 (Opaque Types)]]
-- **Projects/Contexts:** [[도메인 기반 설계 (DDD)]], [[마스 클라이메이트 오비터 (Mars Climate Orbiter)]]
-- **Contradictions/Notes:** 브랜디드 타입과 같은 해결책은 프로그램의 안전성을 높이고 '기본 타입에의 집착'을 해소해 주지만, 추가적인 타입 작성 및 개념적 복잡성이 증가하는 단점(비용)이 수반됩니다. 따라서 개발팀은 애플리케이션에서 실제로 직면할 가능성이 높은 문제인지 득실을 판단하여 도입해야 한다고 조언합니다 [9, 10].
-
----
-*Last updated: 2026-04-18*
-- Raw Source: [[00_Raw/2026-04-20/기본 타입에의 집착 (Primitive Obsession).md]]
----
diff --git a/Programming & Language/기본 타입에의 집착(Primitive Obsession).md b/Programming & Language/기본 타입에의 집착(Primitive Obsession).md
deleted file mode 100644
index afb3bbfe..00000000
--- a/Programming & Language/기본 타입에의 집착(Primitive Obsession).md	
+++ /dev/null
@@ -1,37 +0,0 @@
----
-id: P-REINFORCE-AUTO-5462C7
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - 기본 타입에의 집착(Primitive Obsession)"
----
-
-# [[기본 타입에의 집착(Primitive Obsession)]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> '기본 타입에의 집착(Primitive Obsession)'은 이메일 주소, 이름, 식별자, 통화 등 의미적으로 서로 다른 데이터를 `string`이나 `number` 같은 단일한 기본(원시) 타입으로만 취급하여 표현하려는 문제를 뜻한다[1, 2]. TypeScript와 같이 구조적 타이핑(Structural Typing)을 사용하는 언어에서는 컴파일러가 이러한 데이터들의 의미적 차이를 구분하지 못해 의도치 않은 데이터 혼용 실수를 방지할 수 없다[2, 3]. 이 문제를 해결하기 위해 고유한 표식을 부여하는 브랜디드 타입(Branded Types)이나 불투명 타입(Opaque Types) 같은 기법이 해결책으로 사용된다[2-4].
-
-## 📖 구조화된 지식 (Synthesized Content)
-* **기본 타입 집착의 원인 및 한계**
-  현대 애플리케이션에서 `string`은 토큰, 리소스 식별자, 이벤트 이름 등 아주 다양한 역할을 하며, `number` 역시 통화, 가상 포인트, 타임스탬프 등을 나타낸다[1]. 하지만 TypeScript의 구조적 타이핑 특성상, 이메일 주소가 필요한 매개변수에 사용자의 이름을 전달해도 둘 다 `string`이라는 이유로 컴파일러가 호환성을 인정해버리며 오류를 잡아내지 못한다[2]. 즉, 외견상 구조가 같아 보이는 기본 타입들을 의미론적으로 차별화할 수 있는 내장된 방법이 부족한 것이 근본적인 원인이다[5].
-
-* **실제 발생할 수 있는 위험성**
-  이러한 기본 타입에의 집착은 런타임 오류와 심각한 논리적 결함을 유발한다. 가장 널리 알려진 비극적 사례는 미국 단위계(파운드힘 초)와 SI 단위계(뉴턴 초)를 동일한 숫자 타입으로 혼용하여 3억 2,760만 달러 규모의 궤도선이 소실된 Mars Climate Orbiter 사건이다[4]. 이 외에도 서로 다른 통화(예: EUR와 GBP)의 상품 가격을 의미 구분 없이 `number` 타입으로 묶어 연산할 경우 시스템의 불일치나 수익 손실을 초래할 수 있으며[6], 인증 서버 토큰과 API 토큰을 혼동하여 잘못된 인자로 전달하는 버그가 발생할 수 있다[7].
-
-* **해결 방안: 명목적 타이핑의 수복**
-  기본 타입에의 집착을 해결하기 위해 도메인 기반 설계(DDD) 등에서 '브랜디드 타입(Branded Types)' 또는 '불투명 타입(Opaque Types)'이 널리 사용된다[2, 8]. 이는 런타임에는 존재하지 않지만 컴파일 시점에만 존재하는 고유한 속성(브랜드)을 원시 타입에 강제로 덧붙여(예: `string & { __brand: 'UserId' }`) 의미가 다른 타입 간의 호환과 섞임을 차단하는 기법이다[2, 9]. 이를 통해 사용자 ID와 주문 ID를 엄격히 분리하거나[10], 철저히 검증된 데이터(Sanitized String 등)만이 시스템 내부 로직으로 진입하도록 강제하여 데이터 오염을 예방할 수 있다[2, 11].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[구조적 타이핑(Structural Typing)]], [[브랜디드 타입(Branded Types)]], [[불투명 타입(Opaque Types)]], [[도메인 기반 설계(DDD)]]
-- **Projects/Contexts:** [[TypeScript 타입 시스템]], [[Mars Climate Orbiter 사례]]
-- **Contradictions/Notes:** 소스에 따르면 타입 브랜딩은 프로그램의 안전성을 극대화하지만, 코드의 개념적 복잡성을 증가시키고 작성해야 할 타이핑 량이 많아진다는 단점이 있다. 따라서 일부 소스에서는 값이 0이 아님이 개발자에 의해 명확히 인지되는 등의 특정 상황에서는 브랜디드 타입의 강박적 사용을 피하고 단순한 원시 타입과 단일 예외 처리(어설션)를 사용하는 것이 코드를 더 간결하고 읽기 쉽게 만들 수 있다고 조언한다[12-14].
-
----
-*Last updated: 2026-04-18*
-- Raw Source: [[00_Raw/2026-04-20/기본 타입에의 집착(Primitive Obsession).md]]
----
diff --git a/Programming & Language/깊이 지각 (Depth Perception).md b/Programming & Language/깊이 지각 (Depth Perception).md
deleted file mode 100644
index 4bd80e54..00000000
--- a/Programming & Language/깊이 지각 (Depth Perception).md	
+++ /dev/null
@@ -1,32 +0,0 @@
----
-id: P-REINFORCE-AUTO-F049E9
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - 깊이 지각 (Depth Perception)"
----
-
-# [[깊이 지각 (Depth Perception)]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 깊이 지각(Depth Perception)은 가까운 물체에 대해 단일하고 명확한 초점을 맞추기 위해 망막의 단서들을 활용하는 시각적 기능이다 [1]. 자연스러운 환경에서는 흐림(blur)과 양안 부등(disparity) 같은 단서를 바탕으로 눈모음(vergence)과 조절(accommodation) 메커니즘이 상호작용하여 깊이를 지각한다 [1]. 그러나 가상현실(VR)과 같은 머리 착용 디스플레이(HMD) 환경에서는 이러한 안구 운동 기능 간의 충돌이나 분리가 발생하여 깊이 지각에 불확실성과 악영향을 초래할 수 있다 [1, 2].
-
-## 📖 구조화된 지식 (Synthesized Content)
-- **깊이 지각의 작동 메커니즘:** 가까운 물체에 더 정확하게 초점을 고정하기 위해서는 눈모음(convergence/vergence)과 조절(accommodation)이라는 필수적인 안구 운동 기능이 요구된다 [1, 3]. 이때 흐림(blur)과 부등(disparity)은 이 두 가지 기능을 돕는 필수적인 망막 지형적 단서(retinotopic cues)로 작용한다 [1]. 자연스러운 시각 조건에서 눈모음과 조절은 피드백 루프 속에서 함께 작동하여, 한 기능이 변화하면 다른 기능도 동시에 변화하는 특징을 갖는다 [1].
-- **가상현실(VR) 환경에서의 깊이 지각 저하:** HMD를 사용하는 가상현실 환경에서는 눈모음과 조절 기능이 서로 분리(decoupled)되는 현상이 발생할 수 있다 [1]. 이러한 눈모음-조절 충돌(vergence-accommodation conflicts)은 깊이 지각을 위한 단서 처리에 불확실성을 초래하며, 결과적으로 두통, 안구 통증, 피로, 복시(double vision) 등 다양한 안구 운동 관련 증상을 유발하게 된다 [1, 3].
-- **VR 후유증과 현실 세계로의 영향:** 사용자가 VR 멀미(VR sickness)를 경험할 때 주관적인 증상 외에도 깊이 지각과 인지 능력이 영향을 받을 수 있다 [2]. 더 나아가 VR 사용 후 발생하는 큰 폭의 안구 운동 변화는 현실 세계에서의 깊이 지각에도 영향을 미칠 수 있으나, 이와 관련된 구체적인 위험성은 아직 연구를 통해 명확히 규명되지 않은 상태이다 [1].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[눈모음-조절 충돌(Vergence-Accommodation Conflict)]], [[VR 멀미(VR Sickness)]]
-- **Projects/Contexts:** [[가상현실(VR) 환경에서의 안구 운동 및 시각 후유증 연구]]
-- **Contradictions/Notes:** 소스에 관련 정보가 부족합니다.
-
----
-*Last updated: 2026-04-19*
-- Raw Source: [[00_Raw/2026-04-20/깊이 지각 (Depth Perception).md]]
----
diff --git a/Programming & Language/깊이 지각(Depth perception).md b/Programming & Language/깊이 지각(Depth perception).md
deleted file mode 100644
index cb97bb3c..00000000
--- a/Programming & Language/깊이 지각(Depth perception).md	
+++ /dev/null
@@ -1,34 +0,0 @@
----
-id: P-REINFORCE-AUTO-889755
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - 깊이 지각(Depth perception)"
----
-
-# [[깊이 지각(Depth perception)]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 깊이 지각은 인간이 흐림(blur)과 양안 시차(disparity) 같은 망막의 단서를 활용하여 가까운 물체에 정확하게 시선을 고정할 수 있도록 돕는 시각적 기능입니다 [1]. 특히 머리 장착형 디스플레이(HMD) 기반의 가상현실(VR) 환경에서는 사용자가 VR 멀미를 겪을 때 깊이 지각 능력과 인지 능력이 부정적인 영향을 받을 수 있습니다 [2]. VR 사용 후 발생하는 안구 운동의 변화는 현실 세계에서의 깊이 지각 능력에도 영향을 미칠 수 있습니다 [1].
-
-## 📖 구조화된 지식 (Synthesized Content)
-소스에 깊이 지각의 일반적인 생물학적/심리학적 이론에 대한 관련 정보가 부족합니다. 제공된 소스에서는 주로 가상현실(VR) 기기 사용과 관련된 맥락에서 깊이 지각을 다루고 있으며, 그 내용은 다음과 같습니다.
-
-* **깊이 지각의 안구 운동 메커니즘:** 깊이 단서(depth cues)의 정확한 활용을 촉진하는 핵심적인 안구 운동 기능은 눈모음(vergence)과 조절(accommodation)입니다 [2]. 자연스러운 시야 환경에서 이 두 기능은 피드백 루프 안에서 함께 작용하며, 흐림(blur)과 시차(disparity)라는 필수적인 망막 단서의 도움을 받아 가까운 물체에 정확히 초점을 맺게 합니다 [1].
-* **가상현실(VR)에서의 깊이 지각 충돌:** HMD를 착용한 상태에서는 사용자의 눈모음과 조절 기능이 분리(decoupled)될 수 있으며, 이는 깊이 지각을 위한 망막 단서에 불확실성을 초래합니다 [1]. 이로 인해 발생하는 눈모음-조절 충돌(vergence-accommodation conflicts)은 깊이 지각의 혼란을 야기하여 두통, 눈의 통증, 피로, 복시(double vision)와 같은 부정적인 증상을 유발합니다 [1, 2].
-* **현실 세계로의 후유증(Aftereffects):** VR 멀미의 증상으로 인해 깊이 지각이 저하될 수 있으며, 긴 시간 VR에 노출된 후 관찰되는 이러한 안구 운동의 큰 변화는 기기 사용 종료 후 현실 세계에서의 실제 깊이 지각 방식에도 영향을 미칠 위험이 있습니다 [1, 2].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[VR 멀미(VR Sickness)]], [[눈모음-조절 충돌(Vergence-accommodation conflicts)]]
-- **Projects/Contexts:** [[머리 장착형 디스플레이(HMD) 환경의 시각적 후유증 연구]]
-- **Contradictions/Notes:** 소스에 깊이 지각의 기초적인 원리 등에 대한 관련 정보가 부족합니다. 현재 소스는 깊이 지각을 온전히 설명하기보다는, VR 게임(예: Beat Saber) 및 HMD 노출이 안구의 눈모음·조절 기능에 미치는 부작용 측면에 집중하여 서술하고 있습니다.
-
----
-*Last updated: 2026-04-19*
-- Raw Source: [[00_Raw/2026-04-20/깊이 지각(Depth perception).md]]
----
diff --git a/Programming & Language/내재적 동기 (Intrinsic Motivation).md b/Programming & Language/내재적 동기 (Intrinsic Motivation).md
deleted file mode 100644
index 6c1f45c6..00000000
--- a/Programming & Language/내재적 동기 (Intrinsic Motivation).md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-88E0B9
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - 내재적 동기 (Intrinsic Motivation)"
----
-
-# [[내재적 동기 (Intrinsic Motivation)]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/내재적 동기 (Intrinsic Motivation).md]]
----
diff --git a/Programming & Language/내재적 동기 vs 외재적 동기.md b/Programming & Language/내재적 동기 vs 외재적 동기.md
deleted file mode 100644
index 2923fb9a..00000000
--- a/Programming & Language/내재적 동기 vs 외재적 동기.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-AA8345
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - 내재적 동기 vs 외재적 동기"
----
-
-# [[내재적 동기 vs 외재적 동기]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/내재적 동기 vs 외재적 동기.md]]
----
diff --git a/Programming & Language/네버 타입 (never type).md b/Programming & Language/네버 타입 (never type).md
deleted file mode 100644
index 9868f029..00000000
--- a/Programming & Language/네버 타입 (never type).md	
+++ /dev/null
@@ -1,43 +0,0 @@
----
-id: P-REINFORCE-AUTO-90D699
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - 네버 타입 (never type)"
----
-
-# [[네버 타입 (never type)]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-*   **집합론적 특성 (Set Theory Perspective):**
-    `never`는 집합론의 관점에서 '빈 집합(empty set, ∅)'으로 정의됩니다 [2]. 어떤 타입 `A`와 유니온(`|`) 연산을 해도 `never`는 영향을 주지 않으며(`A | never = A`), 교집합(`&`) 연산을 하면 항상 `never`가 됩니다(`A & never = never`) [2, 6]. 빈 집합은 모든 집합의 부분집합이므로 `never extends T`는 항상 참(true)이지만, `T extends never`는 `T`가 오직 `never` 타입일 때만 참이 됩니다 [3].
-
-*   **함수의 반환 타입 (Function Return Type):**
-    무한 루프에 빠져 절대 완료되지 않거나, 항상 에러(Exception)를 던지기만 하는 함수의 반환 타입으로 사용해야 합니다 [1, 5]. 함수가 실행을 마치고 아무것도 반환하지 않는(실질적으로는 `undefined`를 반환하는) 경우에 쓰이는 `void` 타입과는 명확히 다릅니다 [5].
-
-*   **타입 좁히기와 완전성 검사 (Type Narrowing & Exhaustiveness Checking):**
-    식별 가능한 유니온(Discriminated Unions)을 `switch` 문 등으로 분기 처리할 때 안전장치 역할을 합니다 [4, 7]. 개발자가 모든 가능한 케이스를 정상적으로 처리했다면, 분기문을 다 거치고 남은 변수의 타입은 `never`로 좁혀집니다(narrowed) [1, 7]. 만약 처리되지 않은 케이스가 하나라도 남아있다면 해당 변수는 실제 타입을 갖게 되며, 이를 `never` 타입으로 검사(예: `assertNever` 함수 사용)하려 할 때 타입 에러가 발생하여 런타임 버그를 사전에 방지할 수 있습니다 [7, 8]. 
-
-*   **타입 충돌 및 초과 속성 방어 (Type Conflicts & Excess Properties):**
-    서로 호환되지 않는 속성을 가진 두 타입을 교집합(`&`)으로 묶을 때, TypeScript는 이를 계산하여 `never` 타입으로 만들 수 있습니다 [9]. 또한, 객체에서 예상치 못한 초과 속성을 감지하기 위한 고급 타입 기법에서도 활용됩니다. 입력된 객체에 허용되지 않은 초과 속성이 있을 경우 그 속성을 `never` 타입으로 매핑하면, (예를 들어 `string`은 `never`에 할당할 수 없으므로) 컴파일러가 강력한 할당 에러를 뱉게 하여 초과 속성 검사(Excess Property Checking)를 우회하는 것을 막을 수 있습니다 [10, 11].
-
-*   **상호 배타적 속성 구현 (Exclusive Props):**
-    특정 조건이나 속성이 활성화되었을 때, 다른 속성들이 함께 사용되는 것을 막기 위해 상호 배타적인 속성들을 `never`로 처리하는 패턴에 사용됩니다. 이 방식을 통해 식별자(discriminant) 없이도 "이것 아니면 저것"의 구조를 안전하게 강제할 수 있습니다 [12].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[식별 가능한 유니온 (Discriminated Unions)]], [[집합론 (Set Theory)]], [[초과 속성 검사 (Excess Property Checking)]], [[구조적 타이핑 (Structural Typing)]]
-- **Projects/Contexts:** [[Type-safe Error Handling & Exhaustiveness Checking]], [[TypeScript Advanced Type System]]
-- **Contradictions/Notes:** 소스에서는 `never`와 `void`, `any`, `unknown`을 엄격하게 구분합니다. `void`는 정상적으로 완료되나 반환값이 없는 경우인 반면, `never`는 결코 도달할 수 없거나 완료되지 않는 값이라는 차이를 지적합니다 [5]. 또한 `any`는 타입 시스템을 우회하지만, `never`는 빈 집합으로서 타입 시스템 내에서 엄격한 논리적 제어를 돕는다는 상반된 특성을 지닙니다 [13, 14].
-
----
-*Last updated: 2026-04-18*
-- Raw Source: [[00_Raw/2026-04-20/네버 타입 (never type).md]]
----
diff --git a/Programming & Language/넷플릭스 (Netflix) 마이크로서비스 도입 사례.md b/Programming & Language/넷플릭스 (Netflix) 마이크로서비스 도입 사례.md
deleted file mode 100644
index cc45d305..00000000
--- a/Programming & Language/넷플릭스 (Netflix) 마이크로서비스 도입 사례.md	
+++ /dev/null
@@ -1,30 +0,0 @@
----
-id: P-REINFORCE-AUTO-E41C28
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - 넷플릭스 (Netflix) 마이크로서비스 도입 사례"
----
-
-# [[넷플릭스 (Netflix) 마이크로서비스 도입 사례]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 넷플릭스는 초기 데이터 센터의 모놀리식(Monolithic) 아키텍처가 가진 확장 및 혁신의 한계를 극복하기 위해 약 7년에 걸쳐 마이크로서비스 아키텍처로의 대대적인 전환을 단행했습니다. 느슨한 결합(Loose coupling)을 통해 각 개발 팀이 개발, 테스트, 배포에 대한 엔드투엔드(End-to-End) 소유권을 가지게 됨으로써 시스템 복원력과 배포 속도가 극대화되었습니다. 이후 미디어 처리 분야에서도 마이크로서비스에 비동기 워크플로와 서버리스 컴퓨팅을 결합한 'Cosmos' 플랫폼을 개발하는 등, 비즈니스 성장에 맞춰 아키텍처를 지속적으로 고도화하고 있습니다.
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[Microservices Architecture]], [[Separation of Concerns]], [[Serverless Computing]], [[Chaos Engineering]], [[Micro Frontends]]
-- **Projects/Contexts:** [[Simian Army]], [[Apache Cassandra]], [[Cosmos Platform]], [[Reloaded]]
-- **Contradictions/Notes:** 넷플릭스의 마이크로서비스 도입은 개발 속도, 혁신, 가용성 측면에서 엄청난 이점을 가져다주었지만, 소스에 따르면 분산 시스템 관리에 따른 운영의 복잡성 증가와 개별 VM/JVM 운영으로 인한 막대한 메모리 소모라는 명확한 기술적 트레이드오프(단점)도 수반했습니다.
-
----
-*Last updated: 2026-04-18*
-- Raw Source: [[00_Raw/2026-04-20/넷플릭스 (Netflix) 마이크로서비스 도입 사례.md]]
----
diff --git a/Programming & Language/넷플릭스 비디오 인코딩 파이프라인 (Netflix Video Encoding Pipeline).md b/Programming & Language/넷플릭스 비디오 인코딩 파이프라인 (Netflix Video Encoding Pipeline).md
deleted file mode 100644
index 322d1b8a..00000000
--- a/Programming & Language/넷플릭스 비디오 인코딩 파이프라인 (Netflix Video Encoding Pipeline).md	
+++ /dev/null
@@ -1,41 +0,0 @@
----
-id: P-REINFORCE-AUTO-9616B9
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - 넷플릭스 비디오 인코딩 파이프라인 (Netflix Video Encoding Pipeline)"
----
-
-# [[넷플릭스 비디오 인코딩 파이프라인 (Netflix Video Encoding Pipeline)]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 넷플릭스의 비디오 인코딩 파이프라인은 파트너와 스튜디오로부터 유입되는 미디어 파일을 처리하여 모든 기기에서 재생할 수 있도록 변환하는 핵심 시스템입니다 [1]. 초기 모놀리식 아키텍처였던 'Reloaded' 시스템의 한계를 극복하기 위해, 현재는 마이크로서비스, 비동기 워크플로우, 서버리스 함수를 결합한 '코스모스(Cosmos)' 플랫폼을 기반으로 운영됩니다 [1-3]. 이 파이프라인은 대규모의 컴퓨팅 리소스를 활용하여 비디오를 여러 청크로 분할한 뒤 병렬로 인코딩하고 조립하는 고도의 오케스트레이션 과정을 거칩니다 [4-6].
-
-## 📖 구조화된 지식 (Synthesized Content)
-*   **인코딩 파이프라인의 진화:** 
-    넷플릭스의 영상/음성 처리 파이프라인은 2007년 스트리밍 런칭과 함께 1세대가 도입되었으며, 2세대를 거쳐 약 7년 이상 운영된 3세대 시스템 'Reloaded'로 이어졌습니다 [1]. 'Reloaded'는 대규모 확장이 가능하고 안정적이었으나, 개발 인력이 늘어나고 유스케이스가 확장되면서 모놀리식 아키텍처의 한계에 부딪혔습니다 [1, 7]. 인프라 코드와 애플리케이션 코드가 섞여 있어 새로운 기능의 배포가 지연되고 운영상의 병목 현상이 발생했습니다 [7, 8].
-*   **코스모스(Cosmos) 플랫폼 도입:**
-    모놀리식 구조의 문제를 해결하기 위해 넷플릭스는 워크플로우 중심의 미디어 특화 플랫폼인 코스모스를 구축했습니다 [3, 8]. 코스모스는 로직을 분리하고, 도메인 특화 애플리케이션과 분산 컴퓨팅 인프라 플랫폼 간의 '관심사의 분리(Separation of Concerns)'를 명확히 했습니다 [8, 9].
-*   **파이프라인을 구동하는 핵심 하위 시스템:**
-    비디오 인코딩과 같은 복잡한 작업은 코스모스의 세 가지 주요 규모 인식(scale-aware) 하위 시스템에 의해 분산 처리됩니다 [9].
-    *   **Optimus:** 외부의 API 요청을 내부 비즈니스 모델로 매핑하는 API 계층입니다 [8, 10].
-    *   **Plato:** 비즈니스 규칙을 모델링하는 워크플로우 계층입니다 [8, 10]. 계산 집약적이고 비동기적인 알고리즘 처리에 적합한 순방향 연쇄(forward chaining) 규칙 엔진을 사용합니다 [11].
-    *   **Stratum:** 상태가 없고 연산 집약적인 알고리즘을 병렬로 실행하는 서버리스 함수 계층입니다 [8, 10].
-    *   **Timestone:** 위 시스템들은 대규모, 저지연 우선순위 큐 시스템인 Timestone을 통해 비동기적으로 통신하며 결합도를 극도로 낮춥니다 [8, 10].
-*   **비디오 인코딩 처리 과정 (Tapas 서비스):**
-    Tapas는 스튜디오로부터 원본 미디어를 받아 넷플릭스에서 재생 가능하게 만드는 고위 수준의 오케스트레이션 서비스입니다 [5]. 비디오 소스와 레시피가 포함된 인코딩 API 호출이 이루어지면, 비디오는 여러 청크(chunk)로 분할되고 병렬로 여러 인코딩 함수(Stratum)가 실행됩니다 [4]. 인코딩이 끝나면 어셈블(assemble) 함수와 인덱스(index) 함수가 순차적으로 호출되어 작업을 마무리합니다 [4]. 하나의 Tapas 요청은 해상도, 품질, 코덱에 따른 다양한 비디오/오디오 인코딩과 자막 생성 등을 수행하기 위해 수백 개의 다른 서비스 요청과 수천 번의 서버리스 함수 호출을 발생시킵니다 [6].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[마이크로서비스 아키텍처 (Microservices Architecture)]], [[관심사의 분리 (Separation of Concerns)]], [[서버리스 컴퓨팅 (Serverless Computing)]]
-- **Projects/Contexts:** [[코스모스 플랫폼 (Cosmos Platform)]], [[Reloaded 시스템]], [[Tapas 서비스]]
-- **Contradictions/Notes:** 넷플릭스의 기존 'Reloaded' 시스템은 7년간 안정적이고 대규모 스케일링이 가능했지만, 단일 모놀리식 데이터 모델과 강한 결합도로 인해 기술적 부채와 배포 지연의 원인이 되었습니다 [1, 7]. 또한 코스모스 서비스에 구현된 모델은 상태가 없는 비즈니스 로직을 API로 제공하는 전형적인 마이크로서비스와는 달리, 다단계 워크플로우와 연산 집약적인 비동기 서버리스 함수가 결합된 형태라는 점에서 구별됩니다 [12].
-
----
-*Last updated: 2026-04-18*
-- Raw Source: [[00_Raw/2026-04-20/넷플릭스 비디오 인코딩 파이프라인 (Netflix Video Encoding Pipeline).md]]
----
diff --git a/Programming & Language/넷플릭스 코스모스 플랫폼 (Netflix Cosmos Platform).md b/Programming & Language/넷플릭스 코스모스 플랫폼 (Netflix Cosmos Platform).md
deleted file mode 100644
index 6a83a406..00000000
--- a/Programming & Language/넷플릭스 코스모스 플랫폼 (Netflix Cosmos Platform).md	
+++ /dev/null
@@ -1,40 +0,0 @@
----
-id: P-REINFORCE-AUTO-E3ABA1
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - 넷플릭스 코스모스 플랫폼 (Netflix Cosmos Platform)"
----
-
-# [[넷플릭스 코스모스 플랫폼 (Netflix Cosmos Platform)]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-넷플릭스의 코스모스 플랫폼은 고도의 관심사 분리(SoC)를 통해 기존 모놀리식 아키텍처의 한계를 극복하고 시스템의 혁신과 신뢰성, 효율성을 달성했습니다 [6], [7]. 코스모스 플랫폼은 크게 두 가지 축을 기준으로 관심사를 분리합니다 [5], [6].
-
-*   **플랫폼과 애플리케이션의 분리 (뇌와 팔다리의 분리):** 
-    코스모스는 도메인 특화 로직(애플리케이션)과 분산 컴퓨팅의 복잡한 세부 사항(플랫폼)을 분리합니다 [5]. 플랫폼 계층은 데이터 배포나 큐 관리 같은 하위 수준의 기술적 구현(팔다리)을 추상화하여 숨깁니다 [6]. 이를 통해 개발자는 시스템 규모나 인프라 환경을 신경 쓰지 않고 오직 핵심 비즈니스 로직(뇌)의 구현에만 집중할 수 있습니다 [5], [6].
-*   **논리적 계층의 분리 (3개의 하위 시스템):**
-    코스모스 서비스는 확장성에 구애받지 않는 컴포넌트들을 다시 확장성을 인지하는 3개의 특화된 하위 시스템으로 분리하여 관리합니다 [5], [8], [6].
-    *   **옵티머스(Optimus):** 외부 요청을 내부 비즈니스 모델로 매핑하는 API 계층입니다 [8], [6].
-    *   **플라토(Plato):** 비즈니스 규칙을 모델링하고 다단계 워크플로우 오케스트레이션을 담당하는 규칙 엔진 계층입니다 [8], [9], [6].
-    *   **스트라툼(Stratum):** 상태가 없고(stateless) 계산 집약적인 알고리즘을 실행하는 서버리스 함수 계층입니다 [8], [6].
-
-이러한 하위 시스템들은 **타임스톤(Timestone)**이라는 대규모, 저지연 우선순위 큐잉 시스템을 통해 비동기적으로 통신합니다 [8], [6]. 각 하위 시스템이 서로 다른 관심사를 다루고 느슨하게 결합되어 있기 때문에, 코스모스의 각 구성 요소는 독립적으로 개발, 테스트 및 배포가 가능해져 서비스 운영의 부담을 크게 덜어줍니다 [8], [6].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[관심사의 분리 (Separation of Concerns)]], [[마이크로서비스 아키텍처 (Microservices Architecture)]], [[응집도와 결합도 (Cohesion and Coupling)]]
-- **Projects/Contexts:** [[넷플릭스 비디오 인코딩 파이프라인 (Netflix Video Encoding Pipeline)]]
-- **Contradictions/Notes:** 넷플릭스는 코스모스 플랫폼 도입과 마이크로서비스로의 분리를 통해 혁신과 독립적 배포의 유연성을 얻었으나, 관심사를 고도로 분리하는 분산 시스템을 구축하는 과정에서 서비스 간 통신 메커니즘을 직접 구현해야 하고 독립적인 서버 공간 유지로 인해 관리 복잡성과 비용 상승이라는 대가가 뒤따랐음을 지적하고 있습니다 [10], [7].
-
----
-*Last updated: 2026-04-18*
-- Raw Source: [[00_Raw/2026-04-20/넷플릭스 코스모스 플랫폼 (Netflix Cosmos Platform).md]]
----
diff --git a/Programming & Language/넷플릭스 코스모스 플랫폼 (Netflix Cosmos).md b/Programming & Language/넷플릭스 코스모스 플랫폼 (Netflix Cosmos).md
deleted file mode 100644
index 1281ef23..00000000
--- a/Programming & Language/넷플릭스 코스모스 플랫폼 (Netflix Cosmos).md	
+++ /dev/null
@@ -1,39 +0,0 @@
----
-id: P-REINFORCE-AUTO-F16810
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - 넷플릭스 코스모스 플랫폼 (Netflix Cosmos)"
----
-
-# [[넷플릭스 코스모스 플랫폼 (Netflix Cosmos)]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 넷플릭스 코스모스 플랫폼(Netflix Cosmos)은 마이크로서비스의 장점과 비동기 워크플로우 및 서버리스 함수를 결합한 컴퓨팅 플랫폼이다 [1]. 이 플랫폼은 주로 수 분에서 수 년까지 지속될 수 있는 복잡하고 계층적인 워크플로우를 통해 조정되는 자원 집약적 알고리즘을 처리하는 데 사용된다 [1]. 기존의 모놀리식 아키텍처인 '리로디드(Reloaded)'의 한계를 극복하고 관찰성, 모듈성, 생산성, 자동화된 전송 능력을 향상시키기 위해 개발되었다 [2-4].
-
-## 📖 구조화된 지식 (Synthesized Content)
-*   **배경 및 개발 목적:** 넷플릭스는 기존의 모놀리식 미디어 처리 시스템인 '리로디드(Reloaded)'가 규모의 확장과 개발자 수의 증가로 인해 새로운 기능 배포를 지연시키고 운영 부담을 가중시키는 문제에 직면했다 [2, 3]. 이에 대응하여 관찰성(Observability), 모듈성(Modularity), 생산성(Productivity), 지속적 배포(Delivery)를 제공하는 워크플로우 중심의 미디어 특화 마이크로서비스 플랫폼인 코스모스를 구축하게 되었다 [4]. 기존 시스템을 점진적으로 안전하게 대체하기 위해 '스트랭글러 피그(strangler fig)' 패턴을 채택하였다 [5].
-
-*   **아키텍처 및 관심사의 분리 (Separation of Concerns):** 코스모스는 애플리케이션과 플랫폼의 로직을 분리하여, 개발자가 분산 컴퓨팅의 세부 사항을 알 필요 없이 미디어 특화 추상화에 집중할 수 있게 한다 [6, 7]. 비즈니스 로직은 다음과 같은 세 가지 스케일 인식(scale-aware) 하위 시스템으로 나뉘어 관리된다 [6-8].
-    *   **옵티머스(Optimus):** 외부 요청을 내부 비즈니스 모델로 매핑하는 API 계층이다 [7, 8].
-    *   **플라토(Plato):** 비즈니스 규칙 모델링을 위한 워크플로우 계층으로, 'Emirax'라는 도메인 특화 언어를 사용하는 전방 추론(forward chaining) 규칙 엔진이다 [7-10].
-    *   **스트라툼(Stratum):** 무상태(stateless) 및 컴퓨팅 집약적인 함수를 실행하기 위한 서버리스 계층이다. 유연한 리소스 스케줄링을 지원하며 타이투스(Titus) 컨테이너 플랫폼 위에 구축되었다 [7, 8, 11].
-
-*   **비동기 통신 시스템:** 코스모스의 하위 시스템들은 대규모, 저지연 우선순위 대기열 시스템인 **타임스톤(Timestone)** 을 통해 서로 비동기적으로 통신한다 [7, 8].
-
-*   **지연 시간 및 처리량 관리:** 사용자 대면 서비스와 같은 지연 시간 민감(Latency-sensitive) 애플리케이션을 위해 스트라툼은 리소스 풀, 웜 커패시티(Warm capacity), 마이크로 배치(Micro-batches), 우선순위 설정을 통해 함수 실행 지연 시간을 관리한다 [12, 13]. 반면 리소스를 대량으로 소비하는 처리량 민감(Throughput-sensitive) 워크로드의 경우, 더 저렴한 '기회주의적(opportunistic)' 컴퓨팅 리소스를 활용할 수 있도록 유연하게 스케줄링한다 [11].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[마이크로서비스 (Microservices)]], [[관심사의 분리 (Separation of Concerns)]], [[서버리스 컴퓨팅 (Serverless Computing)]]
-- **Projects/Contexts:** [[리로디드 (Reloaded)]], [[타파스 (Tapas)]], [[사간 (Sagan)]], [[스트랭글러 피그 패턴 (Strangler fig pattern)]]
-- **Contradictions/Notes:** 소스에 따르면, 코스모스 서비스는 전형적인 마이크로서비스와 유사한 점이 있으나 완전히 같지는 않다. 일반적인 마이크로서비스가 무상태 비즈니스 로직을 가진 API로 요청 부하에 따라 자동 확장되는 반면, 코스모스는 다단계 워크플로우와 컴퓨팅 집약적인 비동기 서버리스 함수를 결합하고 있으며 큐(queue)의 크기에 따라 확장된다는 차이가 존재한다 [14]. 
-
----
-*Last updated: 2026-04-18*
-- Raw Source: [[00_Raw/2026-04-20/넷플릭스 코스모스 플랫폼 (Netflix Cosmos).md]]
----
diff --git a/Programming & Language/넷플릭스(Netflix)의 마이크로서비스 및 코스모스 플랫폼 전환.md b/Programming & Language/넷플릭스(Netflix)의 마이크로서비스 및 코스모스 플랫폼 전환.md
deleted file mode 100644
index 174020ba..00000000
--- a/Programming & Language/넷플릭스(Netflix)의 마이크로서비스 및 코스모스 플랫폼 전환.md	
+++ /dev/null
@@ -1,46 +0,0 @@
----
-id: P-REINFORCE-AUTO-AC1C1C
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - 넷플릭스(Netflix)의 마이크로서비스 및 코스모스 플랫폼 전환"
----
-
-# [[넷플릭스(Netflix)의 마이크로서비스 및 코스모스 플랫폼 전환]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 넷플릭스(Netflix)는 비즈니스 혁신과 안정성을 위해 기존의 RDBMS 기반 모놀리식 아키텍처를 독립적인 마이크로서비스로 전환하여 뛰어난 확장성과 가용성을 확보했습니다 [1, 2]. 이후 비디오 및 오디오 처리와 같은 미디어 중심의 비동기식 대규모 워크플로우에서 발생하는 병목 현상을 해결하기 위해 마이크로서비스, 워크플로우, 서버리스 함수를 결합한 '코스모스(Cosmos)' 플랫폼을 새롭게 도입했습니다 [3, 4]. 코스모스 플랫폼은 다차원적인 관심사 분리를 통해 인프라와 애플리케이션 코드를 격리하고 시스템의 모듈성 및 생산성을 비약적으로 향상시켰습니다 [4, 5].
-
-## 📖 구조화된 지식 (Synthesized Content)
-**마이크로서비스 아키텍처로의 전환 및 운영**
-* 넷플릭스는 2008년부터 확장성의 한계를 극복하기 위해 기존 모놀리식 아키텍처에서 마이크로서비스 기반으로 인프라를 이전하기 시작했습니다 [1, 2].
-* 이 전환은 서비스의 무상태성(Stateless) 유지와 수평적 확장을 원칙으로 하였으며, 카오스 몽키(Chaos Monkey)를 포함한 Simian Army를 통해 파괴적 테스트를 자동화하여 장애 복원력을 높였습니다 [2, 6].
-* 데이터베이스 계층 또한 다중 리전 복제와 파티션 허용 오차가 뛰어난 NoSQL인 카산드라(Cassandra)로 교체했습니다 [6]. 
-* 이러한 마이크로서비스로의 전환은 넷플릭스 내 개별 팀의 개발 및 배포 독립성을 보장하여 혁신 속도를 높였으며, 연간 52분의 다운타임만 허용하는 99.999%의 가용성을 달성하는 데 기여했습니다 [7, 8].
-
-**코스모스(Cosmos) 플랫폼의 도입 배경**
-* 넷플릭스의 미디어 클라우드 엔지니어링 및 인코딩 기술 팀은 미디어 파일의 처리를 위해 3세대 시스템인 'Reloaded(리로디드)'를 수년간 성공적으로 운영해 왔습니다 [9]. 
-* 그러나 시스템 규모가 커지고 개발 인력과 유스케이스가 확장되면서, 기존 모놀리식 구조에서는 인프라 코드와 애플리케이션 코드가 뒤섞여 신규 기능의 배포가 지연되는 심각한 병목 현상이 발생했습니다 [4, 9, 10]. 
-* 이를 해결하기 위해 비동기 워크플로우와 서버리스 기능을 결합한 미디어 중심의 마이크로서비스 플랫폼 '코스모스(Cosmos)'가 구축되었으며, 기존 Reloaded 시스템을 대체하기 위해 스트랭글러 피그(Strangler fig) 패턴을 채택하여 점진적인 전환을 시도했습니다 [4, 5, 11].
-
-**코스모스 플랫폼의 다차원적 관심사 분리(Separation of Concerns)**
-코스모스는 플랫폼과 애플리케이션 사이의 분리뿐만 아니라, 논리적 계층을 3개로 분리함으로써 고도의 관심사 분리를 구현했습니다 [4, 12]. 
-* **Optimus(옵티머스)**: 외부의 요청을 내부 비즈니스 모델로 매핑해 주는 API 계층입니다 [4, 13].
-* **Plato(플라톤)**: 비즈니스 규칙을 모델링하고 무상태 함수들을 오케스트레이션하는 워크플로우 계층입니다 [4, 13, 14].
-* **Stratum(스트라툼)**: 무상태이면서 고도의 계산 집약적인 함수들을 실행하는 서버리스 계층입니다 [4, 13].
-* **Timestone(타임스톤)**: 위의 각 하위 시스템들이 비동기적으로 통신할 수 있도록 지원하는 대규모 우선순위 큐잉 시스템으로, 각 컴포넌트 간의 결합도를 극도로 낮추는 핵심적인 역할을 합니다 [4, 13].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[Microservices Architecture]], [[Separation of Concerns]], [[Serverless Functions]], [[Asynchronous Workflows]], [[Chaos Monkey]]
-- **Projects/Contexts:** [[Reloaded]], [[Tapas]], [[Sagan]], [[Strangler Fig Pattern]]
-- **Contradictions/Notes:** 마이크로서비스 전환과 코스모스와 같은 분산 플랫폼의 구축은 혁신과 확장성 측면에서 큰 이점을 제공하지만, 그 대가로 분산 시스템의 통신 메커니즘을 직접 구현해야 하는 설계적 복잡성을 증가시킵니다 [15, 16]. 또한 여러 서비스 인스턴스를 독립적으로 실행하고 배포해야 하므로, 메모리 소비가 증가하고 운영 비용이 상승하는 단점이 존재합니다 [16-18].
-
----
-*Last updated: 2026-04-18*
-- Raw Source: [[00_Raw/2026-04-20/넷플릭스(Netflix)의 마이크로서비스 및 코스모스 플랫폼 전환.md]]
----
diff --git a/Programming & Language/넷플릭스의 코스모스 플랫폼 및 마이크로서비스 전환.md b/Programming & Language/넷플릭스의 코스모스 플랫폼 및 마이크로서비스 전환.md
deleted file mode 100644
index d371ab0c..00000000
--- a/Programming & Language/넷플릭스의 코스모스 플랫폼 및 마이크로서비스 전환.md	
+++ /dev/null
@@ -1,44 +0,0 @@
----
-id: P-REINFORCE-AUTO-6271CF
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - 넷플릭스의 코스모스 플랫폼 및 마이크로서비스 전환"
----
-
-# [[넷플릭스의 코스모스 플랫폼 및 마이크로서비스 전환]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 넷플릭스는 시스템 확장성과 혁신 속도를 높이기 위해 7년에 걸쳐 기존 모놀리식 데이터센터 환경을 마이크로서비스 아키텍처로 성공적으로 전환했습니다 [1, 2]. 이어 미디어 파일 처리 파이프라인인 '리로디드(Reloaded)' 시스템의 운영 복잡성 한계를 극복하기 위해, '코스모스(Cosmos)' 플랫폼을 도입했습니다 [3-5]. 코스모스는 마이크로서비스에 비동기 워크플로우와 서버리스 함수를 결합한 혁신적인 플랫폼으로, API, 워크플로우, 서버리스 계층을 명확히 분할하는 '관심사의 분리(Separation of Concerns)'를 구현하여 개발 생산성과 시스템 안정성을 대폭 향상시켰습니다 [6-8].
-
-## 📖 구조화된 지식 (Synthesized Content)
-* **마이크로서비스 아키텍처로의 기반 전환:**
-  넷플릭스의 초기 모놀리식 아키텍처는 긴밀한 결합으로 인해 유연한 확장과 혁신에 걸림돌이 되었습니다 [2]. 넷플릭스는 7년이라는 기간 동안 이를 무상태(Stateless) 서비스 기반의 마이크로서비스 아키텍처로 전환하며 수평적 확장(Scale out)을 이뤄냈습니다 [1, 2]. 또한, 관계형 데이터베이스(RDBMS)를 탈피해 다중 지역 복제가 가능하고 가용성이 높은 카산드라(Cassandra)로 전환했으며, 카오스 몽키(Chaos Monkey)를 통한 파괴 테스트를 자동화하여 99.999%의 가용성을 목표로 하는 높은 신뢰성을 확보했습니다 [9, 10].
-
-* **레거시 시스템 '리로디드(Reloaded)'의 한계와 코스모스(Cosmos)의 탄생:**
-  넷플릭스의 미디어 클라우드 엔지니어링 팀은 미디어 처리를 위해 3세대 시스템인 '리로디드'를 약 7년간 운영했습니다 [3]. 그러나 시스템의 규모가 10배 이상 커지고 기능이 복잡해짐에 따라, 기존의 모놀리식 구조와 중앙 집중식 데이터 모델은 기능 배포를 지연시키는 부채로 작용했습니다 [3, 4]. 인프라와 애플리케이션 코드가 혼재된 복잡성을 해결하기 위해, 넷플릭스는 스트랭글러 피그(Strangler Fig) 패턴을 적용하여 레거시 시스템을 점진적으로 대체하는 워크플로우 기반 마이크로서비스 플랫폼 '코스모스'를 개발했습니다 [5, 11].
-
-* **다차원적 관심사 분리(SoC)를 적용한 코스모스 아키텍처:**
-  코스모스는 단순한 마이크로서비스를 넘어 복잡한 비동기 워크플로우와 컴퓨팅 집약적인 서버리스 함수를 융합했습니다 [6, 12]. 애플리케이션의 비즈니스 로직과 플랫폼의 인프라 세부 사항을 격리하고, 논리를 세 가지 주요 하위 시스템으로 분리하는 고도의 관심사 분리를 적용했습니다 [7, 8].
-  * **옵티머스(Optimus):** 외부의 요청을 내부 비즈니스 모델로 매핑하는 API 계층입니다 [13].
-  * **플라토(Plato):** 비즈니스 규칙을 모델링하는 워크플로우 계층으로, 포워드 체이닝(Forward Chaining) 규칙 엔진을 사용하여 항상 켜져 있는 비동기 워크플로우 생성을 지원합니다 [13, 14].
-  * **스트라툼(Stratum):** 무상태(Stateless) 및 컴퓨팅 집약적 알고리즘을 수행하는 서버리스 함수 계층입니다 [13].
-  이 세 가지 하위 시스템은 대규모 저지연 우선순위 대기열 시스템인 타임스톤(Timestone)을 통해 비동기적으로 상호 통신하여 결합도를 극도로 낮추었습니다 [8, 13].
-
-* **워크로드 특성에 따른 성능 최적화:**
-  코스모스 플랫폼은 다수의 서비스를 오케스트레이션하여 워크로드를 관리합니다. 수백만 CPU 시간을 소비하며 장시간 미디어를 처리하는 타파스(Tapas)와 같은 처리량 민감형 서비스와, 사용자의 즉각적인 반응을 처리해야 하는 세이건(Sagan) 같은 지연 시간 민감형 서비스를 모두 지원합니다 [15-18]. 서버리스 계층인 스트라툼은 지연 시간을 단축하기 위해 리소스 풀 활용, 웜(Warm) 용량 사전 대기, 함수 시작 비용을 분산하는 마이크로 배치(Micro-batches) 적용, 그리고 중요도에 따른 우선순위 스케줄링 방식을 도입했습니다 [19].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[마이크로서비스 아키텍처(Microservices Architecture)]], [[관심사의 분리(Separation of Concerns)]], [[서버리스 컴퓨팅(Serverless Computing)]], [[카오스 몽키(Chaos Monkey)]], [[카산드라(Cassandra)]]
-- **Projects/Contexts:** [[리로디드(Reloaded)]], [[코스모스(Cosmos)]], [[타파스(Tapas)]], [[스트랭글러 피그 패턴(Strangler Fig Pattern)]]
-- **Contradictions/Notes:** 마이크로서비스 전환은 넷플릭스에 조직적 민첩성과 신뢰성을 가져다주었지만, 개발자가 분산 시스템 내 서비스 통신을 직접 구현해야 하는 복잡성이 증가하고 N개의 모놀리식 앱이 N*M개의 서비스로 확장되면서 막대한 메모리 및 JVM 오버헤드가 발생한다는 단점도 보고되었습니다 [20-23]. 이러한 한계를 극복하고자 넷플릭스는 단순한 API 호출 방식을 넘어, "마이크로서비스가 워크플로우를 트리거하고, 서버리스 함수를 오케스트레이션하는" 방식으로 플랫폼 아키텍처(코스모스)를 진화시켰습니다 [24].
-
----
-*Last updated: 2026-04-18*
-- Raw Source: [[00_Raw/2026-04-20/넷플릭스의 코스모스 플랫폼 및 마이크로서비스 전환.md]]
----
diff --git a/Programming & Language/뇌 가소성 (Neuroplasticity).md b/Programming & Language/뇌 가소성 (Neuroplasticity).md
deleted file mode 100644
index 233a6ea2..00000000
--- a/Programming & Language/뇌 가소성 (Neuroplasticity).md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-63C048
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - 뇌 가소성 (Neuroplasticity)"
----
-
-# [[뇌 가소성 (Neuroplasticity)]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/뇌 가소성 (Neuroplasticity).md]]
----
diff --git a/Programming & Language/눈모음-조절 충돌(Vergence-accommodation conflicts).md b/Programming & Language/눈모음-조절 충돌(Vergence-accommodation conflicts).md
deleted file mode 100644
index 30ae02bd..00000000
--- a/Programming & Language/눈모음-조절 충돌(Vergence-accommodation conflicts).md	
+++ /dev/null
@@ -1,33 +0,0 @@
----
-id: P-REINFORCE-AUTO-93D7DA
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - 눈모음-조절 충돌(Vergence-accommodation conflicts)"
----
-
-# [[눈모음-조절 충돌(Vergence-accommodation conflicts)]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 눈모음-조절 충돌(Vergence-accommodation conflicts)은 주로 헤드마운트 디스플레이(HMD)와 같은 가상현실(VR) 환경에서 상충되는 깊이 단서로 인해 눈모음(vergence)과 조절(accommodation) 기능이 분리되면서 발생하는 현상입니다 [1]. 자연스러운 시각 환경에서는 이 두 기능이 피드백 루프를 통해 함께 작동하지만, VR 기기에서는 이 연결이 끊어져 깊이 지각의 불확실성을 초래합니다 [1]. 이 충돌은 시각적 성능을 저하시키고 피로를 유발하며, 다양한 안구 운동 관련 증상과 가상현실 멀미(VR sickness)를 동반할 수 있습니다 [1, 2].
-
-## 📖 구조화된 지식 (Synthesized Content)
-* **자연 상태에서의 기능 메커니즘:** 눈모음(수렴)과 조절은 가까운 물체에 대해 단일하고 선명한 초점을 맞추고 정확한 깊이 단서를 활용하는 데 필수적인 안구 운동 기능입니다 [1, 2]. 일반적인 시청 환경에서 이 두 기능은 피드백 루프 안에서 함께 작동하여, 한 메커니즘이 변화하면 다른 메커니즘도 동반하여 변화합니다 [1]. 이때 망막의 흐림(blur)과 양안 시차(disparity)가 더 정밀한 시선 고정을 돕는 필수적인 단서로 작용합니다 [1].
-* **HMD 환경에서의 기능 분리(Decoupling):** 헤드마운트 디스플레이(HMD)를 사용할 때 발생하는 상충되는 깊이 단서의 인지는 눈모음과 조절 기능을 서로 분리(decouple)시킵니다 [1]. 이러한 분리는 사용자의 깊이 지각을 위한 망막 단서에 불확실성을 초래하게 됩니다 [1].
-* **시각적 증상 및 후유증:** 눈모음-조절 충돌은 시각적 성능을 저하시키고 시각적 피로를 유발합니다 [2]. 그 결과 사용자는 두통, 눈의 통증, 피로감, 복시(double vision)와 같은 다양한 안구 운동 증상(oculomotor symptoms)을 겪을 수 있습니다 [1, 2]. 또한, VR 사용 이후 현실 세계에서의 깊이 지각에도 영향을 미칠 수 있으나 관련된 구체적인 위험성은 아직 완전히 이해되지 않았습니다 [1].
-* **시각적 변화의 지속 시간:** 비트 세이버(Beat Saber)와 같은 VR 게임 노출 시간(10분 및 50분)에 따른 후유증을 연구한 결과, 노출 기간에 상관없이 VR 직후에는 조절과 눈모음 기능에서 유의미한 변화가 관찰되었습니다 [1]. 하지만 VR 종료 후 40분이 지나면 측정값들이 다시 기준치(baseline) 수준으로 회복되어, 눈모음과 조절 기능의 변화는 비교적 단기적으로 나타남을 알 수 있습니다 [1].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[가상현실 멀미(VR sickness)]], [[헤드마운트 디스플레이(HMD)]], [[안구 운동 기능(Oculomotor functions)]], [[깊이 지각(Depth perception)]]
-- **Projects/Contexts:** [[VR 엑서게임(비트 세이버) 후유증 조사 연구(Investigation of Virtual Reality Aftereffects)]]
-- **Contradictions/Notes:** 눈모음-조절 충돌이 특정 개인들에게 가상현실 멀미(VR sickness)를 발생시키는 직접적인 원인인지, 아니면 멀미 증상의 심각성을 가중시키는 요인인지는 소스 상에서 아직 명확히 밝혀지지 않았습니다 [2].
-
----
-*Last updated: 2026-04-19*
-- Raw Source: [[00_Raw/2026-04-20/눈모음-조절 충돌(Vergence-accommodation conflicts).md]]
----
diff --git a/Programming & Language/느슨한 결합 (Loose Coupling).md b/Programming & Language/느슨한 결합 (Loose Coupling).md
deleted file mode 100644
index 6d17cfb8..00000000
--- a/Programming & Language/느슨한 결합 (Loose Coupling).md	
+++ /dev/null
@@ -1,42 +0,0 @@
----
-id: P-REINFORCE-AUTO-50EE48
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - 느슨한 결합 (Loose Coupling)"
----
-
-# [[느슨한 결합 (Loose Coupling)]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 느슨한 결합(Loose Coupling)은 소프트웨어 시스템에서 모듈이나 컴포넌트 간의 상호 의존성을 최소화하여 각 부분이 독립적으로 동작할 수 있도록 설계하는 원칙입니다 [1-3]. 이를 통해 한 모듈의 변경이 다른 모듈에 미치는 영향을 최소화하고, 시스템의 유지보수성과 확장성을 크게 향상시킬 수 있습니다 [4-6]. 종종 '높은 응집도(High Cohesion)'와 함께 언급되며, 소프트웨어 품질을 높이는 가장 핵심적인 척도 중 하나로 작용합니다 [5, 7].
-
-## 📖 구조화된 지식 (Synthesized Content)
-* **개념과 목적**
-  결합도(Coupling)는 시스템의 나머지 부분에 대한 특정 부품의 의존도를 의미하며, 이 의존성이 낮은 상태를 '느슨한 결합'이라고 합니다 [2, 3, 8, 9]. 주된 목적은 컴포넌트들을 격리함으로써 한 부분의 수정이나 업그레이드가 시스템 전체의 연쇄적인 실패(Domino effect)나 부작용으로 이어지지 않도록 방지하는 것입니다 [10, 11].
-
-* **주요 이점**
-  * **유지보수 및 변경의 용이성**: 컴포넌트가 독립적이므로 요구사항 변화에 맞춰 특정 기능만 수정하면 되어 유지관리 비용과 기술적 부채가 감소합니다 [6, 10, 12].
-  * **재사용성(Reusability) 증가**: 외부 의존성이 적기 때문에 잘 격리된 모듈은 다른 프로젝트나 환경에서도 쉽게 분리하여 재사용될 수 있습니다 [2, 6, 13].
-  * **테스트 용이성(Testability)**: 시스템 전체를 구동할 필요 없이, 실제 의존성 대신 가짜 객체(Mock)나 더미 데이터를 주입하여 개별 모듈을 독립적으로 단위 테스트할 수 있습니다 [6, 14-16].
-  * **병렬 개발 지원**: 여러 개발자나 팀이 서로의 작업에 간섭하지 않고 명확한 경계 내에서 독자적인 컴포넌트를 개발 및 배포할 수 있도록 돕습니다 [14, 17].
-
-* **느슨한 결합을 달성하기 위한 전략**
-  * **인터페이스 및 추상화**: 구체적인 구현에 직접 의존하지 않고 명확한 인터페이스(계약)를 정의하여 상호작용함으로써 구현 세부 사항을 캡슐화합니다 [2, 12, 18, 19].
-  * **의존성 주입(Dependency Injection, DI)**: 의존성 역전 원칙(DIP)을 활용하여 내부 모듈이 필요한 객체를 직접 생성하지 않고 외부로부터 주입받게 함으로써 컴포넌트 간 결합을 끊어냅니다 [2, 11, 18, 19].
-  * **이벤트 기반 아키텍처(Event-Driven Architecture)**: 컴포넌트 간 직접적인 API 호출을 피하고, 메시지 브로커나 이벤트를 통해 비동기적, 간접적으로 통신하게 만들어 시스템을 분리합니다 [2, 19, 20].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[관심사의 분리 (Separation of Concerns)]], [[응집도 (Cohesion)]], [[의존성 주입 (Dependency Injection)]], [[이벤트 기반 아키텍처 (Event-Driven Architecture)]], [[단일 책임 원칙 (SRP)]]
-- **Projects/Contexts:** [[마이크로서비스 아키텍처 (Microservices Architecture)]], [[클린 아키텍처 (Clean Architecture)]], [[계층화 아키텍처 (Layered Architecture)]]
-- **Contradictions/Notes:** 단순히 시스템을 마이크로서비스로 나눈다고 해서 결합이 완벽히 분리되는 것은 아니며, 네트워크상의 공유 자원이나 공통 데이터 구조에 의해 간접적으로 강하게 결합되는 '결합 분리의 오류'가 발생할 수 있습니다 [21]. 또한, 과도하게 세분화된 분리는 오히려 성능 오버헤드, 네트워크 통신 비용 증가 및 코드 추적의 복잡성을 초래할 수 있으므로 상황에 맞는 적절한 균형이 필요합니다 [22, 23].
-
----
-*Last updated: 2026-04-18*
-- Raw Source: [[00_Raw/2026-04-20/느슨한 결합 (Loose Coupling).md]]
----
diff --git a/Programming & Language/단일 책임 원칙 (SRP).md b/Programming & Language/단일 책임 원칙 (SRP).md
deleted file mode 100644
index 9a35723c..00000000
--- a/Programming & Language/단일 책임 원칙 (SRP).md	
+++ /dev/null
@@ -1,34 +0,0 @@
----
-id: P-REINFORCE-AUTO-B343BD
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - 단일 책임 원칙 (SRP)"
----
-
-# [[단일 책임 원칙 (SRP)]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 단일 책임 원칙(Single Responsibility Principle, SRP)은 클래스, 모듈 또는 함수가 오직 하나의 역할(책임)만을 수행해야 하며, 코드의 변경을 요구하는 이유 또한 단 하나여야 한다는 소프트웨어 설계 원칙입니다 [1, 2]. 이는 객체 지향 프로그래밍의 핵심인 SOLID 원칙 중 하나로, 더 높은 추상화 수준의 개념인 '관심사의 분리(SoC)'를 개별 클래스나 모듈 단위에서 구체화한 것입니다 [3-6]. SRP를 준수하면 코드의 응집도를 높이고 복잡성을 줄여, 가독성과 유지보수성이 뛰어난 시스템을 구축할 수 있습니다 [2, 7].
-
-## 📖 구조화된 지식 (Synthesized Content)
-* **정의와 핵심 목표:** SRP는 소프트웨어 구성 요소(클래스, 함수 등)가 단 하나의 관심사나 기능에만 온전히 집중해야 함을 명시합니다 [2, 8]. 예를 들어, 사용자 데이터를 저장하고 검색하는 역할을 하는 클래스가 사용자 입력 유효성 검사까지 함께 수행해서는 안 됩니다 [1]. 이 원칙의 주된 목적은 클래스를 더 이해하기 쉽고 구축하기 쉽게 만들어, 코드를 수정할 때 관련 없는 기능에 영향을 미쳐 시스템이 버그에 노출될 위험을 최소화하는 데 있습니다 [2].
-
-* **루트 주제 '관심사의 분리(SoC)'와의 관계:** SRP는 관심사의 분리(SoC) 철학을 실현하는 데 있어 가장 핵심이 되는 원칙입니다 [6]. SoC가 시스템을 구성하는 높은 추상화 수준에서 코드를 논리적인 모듈과 계층으로 뚜렷하게 격리하는 것에 초점을 맞춘다면, SRP는 그보다 낮은 개별 클래스나 모듈 수준에서 '책임'을 하나로 제한하는 데 집중합니다 [4, 7]. 모든 객체와 함수가 단 하나의 작업만 하도록 설계(SRP)하여 애플리케이션을 구축한다면, 해당 모듈들은 자연스럽게 철저히 분리된 관심사(SoC)를 형성하게 됩니다 [9]. 오늘날 SoC 철학은 이러한 SRP의 직접적인 모태로 평가받습니다 [5].
-
-* **실무 적용 및 위반 시의 문제점:** 새로운 클래스나 함수를 설계할 때는 항상 "이 클래스의 단일 책임은 무엇인가?"를 먼저 질문하는 것이 가장 적용하기 쉽고 즉각적인 이점을 줍니다 [10]. 프론트엔드 환경의 컴포넌트 개발을 예로 들면, 화면을 그리는 역할뿐만 아니라 데이터 관리, 표현 로직, 비즈니스 로직 등 너무 많은 책임을 하나의 컴포넌트에 집중시키는 것은 전형적인 SRP 위반에 해당합니다 [11]. 이를 개선하기 위해 컴포넌트는 오직 화면을 그리는 책임만 지게 하고, 비즈니스 로직이나 상태 처리는 별도의 모듈에 위임하는 방식이 SRP를 실무에 올바르게 적용하는 방법입니다 [6].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[관심사의 분리 (SoC)]], [[SOLID 원칙]], [[객체 지향 프로그래밍 (OOP)]], [[응집도 (Cohesion)]]
-- **Projects/Contexts:** [[프론트엔드 컴포넌트 구조화]], [[소프트웨어 아키텍처 설계]]
-- **Contradictions/Notes:** 소스에 따르면 SoC와 SRP는 서로 대립하는 개념이 아닙니다. 두 원칙 모두 소프트웨어의 모듈성을 높이는 데 기여하지만, SoC는 기능적 측면에서 코드를 구성하는 큰 그림(높은 추상화)을 다루고, SRP는 변경의 이유라는 관점에서 개별 클래스나 모듈의 단일 책임에 집중한다는 범위(Scope)와 초점의 차이가 있습니다 [4, 7].
-
----
-*Last updated: 2026-04-18*
-- Raw Source: [[00_Raw/2026-04-20/단일 책임 원칙 (SRP).md]]
----
diff --git a/Programming & Language/단일 책임 원칙 (Single Responsibility Principle).md b/Programming & Language/단일 책임 원칙 (Single Responsibility Principle).md
deleted file mode 100644
index 60f6debf..00000000
--- a/Programming & Language/단일 책임 원칙 (Single Responsibility Principle).md	
+++ /dev/null
@@ -1,42 +0,0 @@
----
-id: P-REINFORCE-AUTO-B860D8
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - 단일 책임 원칙 (Single Responsibility Principle)"
----
-
-# [[단일 책임 원칙 (Single Responsibility Principle)]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 단일 책임 원칙(SRP)은 클래스, 모듈 또는 함수가 단 하나의 작업이나 책임만을 가져야 하며, 그 코드가 변경되어야 할 이유도 단 하나여야 한다는 객체 지향 설계의 핵심 원칙입니다 [1-3]. 이 원칙은 복잡한 시스템을 모듈화하고 유지보수성을 높이기 위한 '관심사의 분리(SoC)' 개념을 개별 클래스나 함수 수준에서 극대화한 것으로 볼 수 있습니다 [3-5]. 이를 적용하면 코드의 목적이 명확해지고, 하나의 변경 사항이 시스템의 다른 부분에 미치는 영향을 최소화하여 버그 발생 가능성을 줄일 수 있습니다 [6].
-
-## 📖 구조화된 지식 (Synthesized Content)
-- **정의 및 핵심 개념**
-  단일 책임 원칙은 특정 소프트웨어 개체(클래스, 함수 등)가 변경되어야 할 이유가 단 하나뿐이어야 함을 규정합니다 [1, 3]. 이는 각 모듈이나 클래스가 하나의 역할에만 집중해야 함을 의미합니다 [5]. 예를 들어, 장바구니의 총가격을 계산하는 함수는 결과를 화면에 출력하기 위해 포맷을 맞추는 작업을 동시에 처리해서는 안 되며 [7], 사용자 데이터를 저장하고 조회하는 클래스는 사용자 입력을 검증하는 역할을 함께 맡아서는 안 됩니다 [1].
-
-- **관심사의 분리(SoC)와의 관계**
-  단일 책임 원칙은 소프트웨어 공학의 '관심사의 분리(SoC)' 철학에서 파생된 객체 지향 설계의 SOLID 원칙 중 하나입니다 [8-10]. SoC가 전반적인 시스템 아키텍처나 대규모 모듈 단위에서 논리적 관심사를 분리하여 복잡성을 관리하는 데 중점을 둔다면, SRP는 이를 개별 클래스나 모듈 수준의 "책임"으로 세분화하여 적용합니다 [3, 11]. 본질적으로 SRP는 관심사의 분리 원칙을 가장 극단적인 수준까지 가져간 형태라고 할 수 있습니다 [4].
-
-- **설계 상의 이점**
-  - **가독성 및 유지보수성 향상:** 클래스와 함수가 오직 하나의 목적만 가지게 되어 다른 프로그래밍 구조에 비해 코드를 이해하고 평가하며 구축하기가 훨씬 쉽습니다 [6, 11].
-  - **버그 노출 감소:** 시스템의 기능이 변경될 때 영향을 받는 클래스의 수가 줄어들기 때문에, 의도치 않은 부작용이나 버그가 다른 영역으로 전파될 위험이 감소합니다 [6].
-  - **응집도 강화:** 모듈 내의 코드가 단일 책임을 달성하기 위해 뭉치게 되므로 시스템의 전반적인 응집도(Cohesion)를 높이는 데 기여합니다 [11].
-
-- **실무적 적용**
-  단일 책임 원칙은 객체 지향 설계에서 가장 먼저, 그리고 쉽게 적용할 수 있는 원칙입니다 [12]. 개발자는 새로운 클래스나 함수를 작성하기 전에 "이 요소의 단일 책임은 무엇인가?"를 스스로에게 질문해야 합니다 [2, 12]. 프론트엔드 개발에서도 이 원칙이 적용되는데, 예를 들어 컴포넌트는 화면을 그리는 역할만 담당하게 하고 비즈니스 로직이나 상태 관리는 별도의 모듈에서 처리하도록 분리하는 방식이 이에 해당합니다 [5].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[객체 지향 프로그래밍(OOP)]], [[SOLID 원칙]], [[응집도(Cohesion)]]
-- **Projects/Contexts:** [[프론트엔드 컴포넌트 설계]], [[객체 지향 소프트웨어 아키텍처 설계]]
-- **Contradictions/Notes:** 단일 책임 원칙(SRP)과 관심사의 분리(SoC)는 종종 같은 의미로 혼용되거나 비교되지만, 적용되는 추상화 수준에서 차이가 있습니다. SoC는 더 넓은 의미의 기능적 관심사를 모듈이나 아키텍처 계층 수준에서 분리하는 것에 초점을 맞추는 반면, SRP는 가장 작은 단위인 개별 클래스나 함수가 가지는 책임과 변경의 이유를 하나로 제한하는 데 집중합니다 [3].
-
----
-*Last updated: 2026-04-18*
-- Raw Source: [[00_Raw/2026-04-20/단일 책임 원칙 (Single Responsibility Principle).md]]
----
diff --git a/Programming & Language/단일 책임 원칙(SRP).md b/Programming & Language/단일 책임 원칙(SRP).md
deleted file mode 100644
index 5a81a2ef..00000000
--- a/Programming & Language/단일 책임 원칙(SRP).md	
+++ /dev/null
@@ -1,36 +0,0 @@
----
-id: P-REINFORCE-AUTO-F57735
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - 단일 책임 원칙(SRP)"
----
-
-# [[단일 책임 원칙(SRP)]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 단일 책임 원칙(SRP, Single Responsibility Principle)은 클래스나 모듈이 단 하나의 변경 이유만 가져야 한다는 소프트웨어 설계 원칙입니다 [1, 2]. 하나의 모듈에 영속성, 데이터 처리, 알림 등 여러 책임이 섞이면 코드가 불안정해지고 조그만 수정에도 예기치 않은 문제가 발생할 위험이 커집니다 [2]. 이 원칙을 준수하면 각 모듈이 한 가지 명확한 역할만 수행하게 되어, 한 영역의 코드를 수정할 때 다른 무관한 로직에 영향을 미치지 않고 안전하게 변경할 수 있습니다 [2, 3].
-
-## 📖 구조화된 지식 (Synthesized Content)
-- **개념의 정의**: 모듈이 변경되어야 하는 '이유'는 단 하나여야 하며, 이는 특정 이해관계자, 비즈니스 규칙 또는 외부 시스템의 요구사항을 의미합니다 [2]. 클래스나 인터페이스가 너무 많은 책임을 지게 되면 잦은 변경에 노출되고 취약해집니다 [4].
-- **위반의 징후 (Red Flags)**: HTTP 핸들러, 비즈니스 로직, 데이터 접근 로직이 한 파일에 뒤섞여 있는 경우, 비대한 "god" 클래스로 인해 코드 병합 충돌(merge conflict)이 빈번한 경우, 그리고 코드 주석에 "~도 수행함(also does...)" 같은 설명이 붙는 메서드 등은 SRP 위반을 시사합니다 [3].
-- **리팩토링 전략**: 실용적인 해결책은 "비명을 지를 때까지 추출하라(extract till you scream)"는 것입니다. 가장 두드러지는 부차적인 책임을 독립된 별도의 클래스로 빼내고, 테스트를 작성하는 과정을 반복합니다 [3]. 이렇게 역할을 분리하면, 결제 로직을 건드리지 않고 이메일 제공자를 교체하거나 스키마를 안전하게 변경할 수 있습니다 [3].
-- **실무 적용 사례**:
-  - **Toss Front SDK**: "리소스를 만든 곳에서 닫는다"는 접근은 단일 책임 원칙을 잘 보여줍니다. 이를 통해 사용자 실수로 인한 리소스 및 리스너 누수를 방지하여 SDK 전반의 안정성을 굳건하게 지켜냅니다 [5].
-  - **Strapi 개발**: 커스텀 컨트롤러의 로직을 가볍게 유지해야 합니다. 파일 업로드, 유효성 검사, 분석 등의 작업은 하나의 컨트롤러 파일에 몰아넣지 않고 개별 서비스로 분리하여 호출하도록 설계해야 합니다 [3].
-  - **아키텍처 패턴의 활용**: 단일 책임 원칙은 인터페이스 분리 원칙(ISP)과 궤를 같이합니다. 복잡한 시스템을 퍼사드(Facade) 패턴으로 감싸 책임을 단순화하면, 개발자의 인지 부하를 줄이고 시스템 간 결합도를 낮추는 강력한 수비 전략이 됩니다 [4].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[SOLID]], [[인터페이스 분리 원칙(ISP)]], [[퍼사드(Facade) 패턴]]
-- **Projects/Contexts:** [[Toss Front SDK]], [[Strapi]]
-- **Contradictions/Notes:** 소스 내에서 단일 책임 원칙에 대한 모순점은 없으며, 제공된 모든 소스에서 모듈의 결합도를 낮추고 예측 가능성을 높이는 핵심 아키텍처 원칙으로 일관되게 강조하고 있습니다.
-
----
-*Last updated: 2026-04-18*
-- Raw Source: [[00_Raw/2026-04-20/단일 책임 원칙(SRP).md]]
----
diff --git a/Programming & Language/대규모 TypeScript 애플리케이션 아키텍처 설계.md b/Programming & Language/대규모 TypeScript 애플리케이션 아키텍처 설계.md
deleted file mode 100644
index 6f0b443a..00000000
--- a/Programming & Language/대규모 TypeScript 애플리케이션 아키텍처 설계.md	
+++ /dev/null
@@ -1,41 +0,0 @@
----
-id: P-REINFORCE-AUTO-00FB6C
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - 대규모 TypeScript 애플리케이션 아키텍처 설계"
----
-
-# [[대규모 TypeScript 애플리케이션 아키텍처 설계]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 대규모 TypeScript 애플리케이션 아키텍처 설계는 언어의 강력한 정적 타입 시스템과 객체 지향 및 함수형 설계 원칙(SOLID 등)을 결합하여 예측 가능하고 유지보수 가능한 시스템을 구축하는 과정입니다 [1, 2]. 불변성 강제, 식별 가능한 유니온, 도메인 에러의 타입화 등을 통해 런타임 에러를 방지하고 논리적으로 잘못된 상태를 표현할 수 없도록 원천 차단합니다 [3-5]. 또한 무분별한 추상화를 피하고 퍼사드 패턴이나 객체 합성을 통해 모듈 간 결합도를 낮추는 것을 핵심 목표로 삼습니다 [6, 7].
-
-## 📖 구조화된 지식 (Synthesized Content)
-대규모 애플리케이션을 안정적으로 설계하고 확장하기 위해 소스에서 권장하는 핵심 아키텍처 전략은 다음과 같습니다.
-
-*   **SOLID 원칙 기반의 모듈화와 인터페이스 설계 전략**
-    대규모 아키텍처는 단일 책임 원칙(SRP) 및 의존성 역전 원칙(DIP)에 기초하여 코드 결합도를 낮추어야 합니다 [2, 8]. 이때 타입 시스템 성능 최적화를 위해 핵심 도메인 모델과 API 계약에는 캐싱에 유리한 `interface` 확장을 우선 적용하고, 복잡한 타입 조합이 필요할 때만 `type` 교집합을 사용하는 것이 컴파일러 성능 향상에 유리합니다 [9-11]. 또한 무분별한 클래스 상속보다는 **합성(Composition over inheritance)**을 우선시하여 유연성을 확보해야 합니다 [6, 12, 13].
-*   **안전한 데이터 경계와 검증 (Parse, don't validate)**
-    외부 시스템과의 경계에서 알 수 없는 데이터를 수신할 때는 단순히 유효성 검사만 하는 것에 그치지 않고, 시스템이 신뢰할 수 있는 구체적인 타입으로 **'파싱(Parsing)'**하여 넘겨야 합니다 [4, 14]. 이 과정에서 TypeScript 4.9에 도입된 `satisfies` 연산자를 활용하면, 객체의 구체적인 리터럴 정보를 유지하면서도 인터페이스 구조를 엄격하게 충족하는지 정밀하게 검증할 수 있어 과잉 속성 체크(Excess Property Checking)의 한계를 우아하게 극복할 수 있습니다 [15-19].
-*   **에러 처리와 제어 흐름 설계 (Result & Discriminated Unions)**
-    대규모 시스템에서는 무분별하게 예외(Exception)를 발생시키기보다, `Result` 객체 패턴이나 **'식별 가능한 유니온(Discriminated Unions)'**을 활용하여 예상 가능한 오류를 타입으로 명시해야 합니다 [20-22]. 이를 통해 에러를 제어 흐름의 일부로 가져오고, 컴파일러의 완전성 검사(Exhaustiveness checking)를 유도하여 누락된 분기를 사전에 포착합니다 [23-26]. 예외 던지기(throw)는 시스템 차원의 예상치 못한 치명적 결함(Defect)에만 제한적으로 사용해야 합니다 [27, 28].
-*   **타입 안전성과 불변성(Immutability) 강제**
-    객체나 배열이 예기치 않게 변경되는 상태 오염을 막기 위해 `readonly` 수식어와 깊은 불변성(`DeepReadonly`)을 적극적으로 도입하여 데이터 무결성을 보장해야 합니다 [5, 29, 30]. 구조적 타이핑이 야기할 수 있는 원시 타입 집착(Primitive Obsession) 문제를 방어하기 위해 **브랜디드 타입(Branded Types)**을 도입하면, 런타임 구조는 동일하더라도 의미가 전혀 다른 데이터(예: `UserId`와 `OrderId`)가 잘못 섞이는 것을 컴파일 시점에 완벽히 차단할 수 있습니다 [31-33].
-*   **인지 부하 감소를 위한 퍼사드(Facade) 패턴 적용**
-    시스템이 거대해질수록 내부의 오케스트레이션 로직, 상태 관리, 클린업 등을 직접 다루게 하면 휴먼 에러가 발생합니다. 이를 저수준(low-level)으로 감추고, 사용자 의도(Intent)에 맞춘 고수준(high-level) 인터페이스만 노출시키는 **퍼사드 패턴**을 기반으로 구조를 설계해야 합니다 [7, 34]. 다만 특수한 유즈케이스의 제어를 위해 세밀한 조작이 가능한 탈출구(Escape Hatch)를 함께 제공하여 편의성과 유연성의 균형을 맞추는 것이 중요합니다 [35, 36].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[SOLID 원칙]], [[식별 가능한 유니온 (Discriminated Unions)]], [[브랜디드 타입 (Branded Types)]], [[퍼사드 패턴 (Facade Pattern)]], [[Parse, don't validate]], [[구조적 타이핑 (Structural Typing)]]
-- **Projects/Contexts:** [[토스(Toss) Front SDK 개발 환경]], [[엔터프라이즈급 대규모 상태 관리 시스템]]
-- **Contradictions/Notes:** TypeScript 커뮤니티 내에서는 객체 구조 정의 시 `type`과 `interface`의 선택 기준에 대한 논쟁이 존재합니다. 캐싱을 통한 컴파일 성능 향상과 선언 병합(Declaration Merging)의 이점 때문에 `interface`를 선호하는 관점이 있는 반면 [9-11], 의도치 않은 선언 병합을 방지하고 보다 엄격한 관리를 위해 애플리케이션 내부에서는 `type`만을 일관되게 사용해야 한다는 개발팀의 실무적 주장도 강하게 대립합니다 [13, 37, 38]. 또한, 함수형 프로그래밍에서 유래한 `Result` 타입 반환 패턴 역시 명확한 에러 흐름 제어로 호평받지만, 코드의 보일러플레이트를 증가시켜 가독성을 해칠 수 있다는 비판적 시각도 존재합니다 [39-41].
-
----
-*Last updated: 2026-04-18*
-- Raw Source: [[00_Raw/2026-04-20/대규모 TypeScript 애플리케이션 아키텍처 설계.md]]
----
diff --git a/Programming & Language/대규모 TypeScript 프로젝트의 컴파일 성능 최적화.md b/Programming & Language/대규모 TypeScript 프로젝트의 컴파일 성능 최적화.md
deleted file mode 100644
index 16aa235e..00000000
--- a/Programming & Language/대규모 TypeScript 프로젝트의 컴파일 성능 최적화.md	
+++ /dev/null
@@ -1,32 +0,0 @@
----
-id: P-REINFORCE-AUTO-C4763A
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - 대규모 TypeScript 프로젝트의 컴파일 성능 최적화"
----
-
-# [[대규모 TypeScript 프로젝트의 컴파일 성능 최적화]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 대규모 TypeScript 프로젝트의 컴파일 성능을 최적화하려면 복잡한 타입 연산을 줄이고 컴파일러의 캐싱 능력을 극대화해야 합니다 [1-3]. 특히 구조를 매번 재평가해야 하는 교집합(`&`) 타입 대신 인터페이스 확장(`extends`)을 우선적으로 사용하여 평탄화(flattening) 오버헤드를 방지하는 것이 가장 핵심적인 성능 향상 전략입니다 [3, 4]. 더불어 과도하게 복잡한 유니온 타입이나, 호출 시점마다 부가 정보를 추적하는 제네릭 타입의 사용을 최소화하여 컴파일 속도 저하를 막아야 합니다 [5, 6].
-
-## 📖 구조화된 지식 (Synthesized Content)
-- **인터페이스 확장을 통한 캐싱 최적화:** `type` 선언과 교집합 연산자(`&`)를 사용한 타입 병합은 대규모 프로젝트에서 컴파일 성능을 저하시킬 수 있습니다 [4]. 교집합 타입은 사용할 때마다 재귀적으로 속성을 병합하고 계산해야 하지만, 인터페이스는 단일 평탄화된 객체 타입을 생성하며 해당 이름(캐시)을 참조하여 타입 관계를 파악합니다 [2, 3, 7]. 따라서 핵심 도메인 모델이나 API 계약 등에서는 인터페이스의 `extends`를 사용하는 것이 타입 검사 성능 향상 및 IDE 업데이트 속도 최적화에 유리합니다 [4, 8, 9].
-- **유니온(Union) 타입의 복잡성 관리:** 판별 가능한 유니온(Discriminated Unions)과 같은 패턴은 훌륭한 타입 안전성을 제공합니다. 그러나 대규모 코드베이스에서 유니온 타입의 형태가 너무 복잡하게 구성되면 TypeScript 컴파일 속도를 느리게 만드는 주요 원인이 될 수 있습니다 [5].
-- **무거운 제네릭 및 추가 타입 검사 도구의 신중한 사용:** 잉여 속성(Excess property)을 엄격하게 감지하기 위해 제네릭 매개변수를 활용하여 모든 호출 위치(call site)에서 추가적인 타입 정보를 추적하는 기법이 있습니다 [6]. 이 기법은 강력하지만 타입 검사 성능에 부정적인 영향을 미칠 수 있으므로 신중히 사용해야 하며, 의심스러울 경우 TypeScript 프로젝트에 대한 성능 프로파일링(profiling)을 거쳐야 합니다 [6].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[인터페이스 확장 (Interface Extends)]], [[교집합 타입 (Intersection Types)]], [[타입 캐싱 (Type Caching)]], [[판별 가능한 유니온 (Discriminated Unions)]]
-- **Projects/Contexts:** [[대규모 코드베이스 (Large Codebases)]], [[타입 검사 및 IDE 성능 최적화 (Type Checking and IDE Performance)]]
-- **Contradictions/Notes:** 의도치 않은 선언 병합(Declaration Merging)의 위험성 때문에 많은 실무 팀들이 인터페이스 대신 `type`만을 사용하는 컨벤션을 선호하기도 하지만 [10], TypeScript의 컴파일 및 성능 가이드라인 측면에서는 교집합(`&`) 대신 인터페이스 확장(`extends`)을 사용하는 것이 권장되고 있습니다 [3, 4].
-
----
-*Last updated: 2026-04-18*
-- Raw Source: [[00_Raw/2026-04-20/대규모 TypeScript 프로젝트의 컴파일 성능 최적화.md]]
----
diff --git a/Programming & Language/대규모 데이터 렌더링 및 가상화 최적화.md b/Programming & Language/대규모 데이터 렌더링 및 가상화 최적화.md
deleted file mode 100644
index 40edc607..00000000
--- a/Programming & Language/대규모 데이터 렌더링 및 가상화 최적화.md	
+++ /dev/null
@@ -1,49 +0,0 @@
----
-id: P-REINFORCE-AUTO-BB908E
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - 대규모 데이터 렌더링 및 가상화 최적화"
----
-
-# [[대규모 데이터 렌더링 및 가상화 최적화]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 대규모 리스트나 테이블을 렌더링할 때 발생하는 DOM 노드 폭증과 메모리 부족, 프레임 저하 현상을 방지하기 위해, 전체 데이터 중 현재 화면(Viewport)에 보이는 항목과 약간의 여분(Buffer)만을 동적으로 마운트하여 렌더링하는 성능 최적화 기법입니다.
-
-## 📖 구조화된 지식 (Synthesized Content)
-**1. 대규모 렌더링의 성능 병목 원인** 수천, 수만 개의 항목(예: 10,000개 이상의 리스트)을 한 번에 렌더링하면 DOM 노드가 기하급수적으로 늘어나 브라우저가 멈추거나(Freezing), 레이아웃 계산 및 페인팅 작업이 매우 느려집니다. 또한 React의 재조정(Reconciliation) 알고리즘이 모든 항목을 비교하려 하므로 CPU 오버헤드와 심각한 프레임 드랍이 발생하게 됩니다.
-
-**2. 가상화(Windowing/Virtualization)의 작동 원리 및 효과** 가상화는 전체 배열 중 현재 화면에 노출되는 항목만을 DOM에 마운트(렌더링)하고, 스크롤할 때마다 새롭게 보이는 항목을 생성하며 화면을 벗어난 항목은 언마운트하는 방식입니다. 이를 적용하면 10,000개의 항목이 있어도 실제 DOM에는 수십 개만 존재하게 되어 렌더링 소요 시간을 약 1,200ms에서 50ms 수준으로 단축하고 메모리 사용량을 최대 97%까지 절감할 수 있습니다.
-
-**3. 안정적인 식별자(Key)의 중요성** 대규모 리스트를 최적화할 때는 항목의 추가, 삭제, 재정렬 시 불필요한 재생성을 막는 것이 핵심입니다. 배열의 인덱스(index)를 `key`로 사용하면 항목 순서가 바뀔 때 React가 항목을 잘못 식별하여 대규모 리렌더링이나 미세한 버그가 발생할 수 있으므로, 반드시 고유하고 안정적인 `key`를 부여해야 합니다.
-
-**4. 주요 가상화 라이브러리 도입** 이러한 복잡한 로직을 직접 구현하기보다는 검증된 라이브러리를 사용하는 것이 권장됩니다.
-
-- **`react-window`**: 가볍고 성능이 뛰어난 가장 보편적인 가상화 라이브러리입니다.
-- **`react-virtualized`**: 테이블이나 그리드 등 보다 고급 기능이 포함되어 있으나 상대적으로 무겁습니다.
-- **`TanStack Virtual`**: 프레임워크에 구애받지 않는 최신 API 구조를 제공합니다.
-
-**5. 적용 시 주의사항 및 한계점** 가상화는 만능이 아니며 피해야 할 상황이 존재합니다.
-
-- 리스트 항목이 20개 미만인 소규모 리스트에서는 가상화 연산 오버헤드가 더 클 수 있으므로 도입하지 않는 것이 좋습니다.
-- 브라우저의 기본 검색(Ctrl+F) 기능으로 모든 콘텐츠를 찾아야 하거나, SEO가 중요한 정적 콘텐츠, 인쇄용 페이지에는 가상화된 항목이 DOM에 존재하지 않아 작동하지 않으므로 적용을 피해야 합니다.
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[React Performance Optimization]], [[재조정 (Reconciliation)]], [[불필요한 리렌더링 방지]]
-    
-- **Projects/Contexts:** [[장기 실행되는 실시간 데이터 대시보드 최적화]], [[대규모 로그 뷰어 및 데이터 테이블 구현]], [[이커머스 무한 스크롤 상품 리스트]]
-    
-- **Contradictions/Notes:** 50~100개 이상의 대규모 리스트나 무한 스크롤 환경에서는 가상화가 필수적이지만, 항목의 높이가 제각각인 가변 높이 항목(Variable height items)을 렌더링할 때는 렌더링 전 각 항목의 크기를 측정(Measurement)하는 단계가 필요하여 구현이 훨씬 복잡해집니다. 따라서 가급적 리스트 항목의 높이를 일정하게 설계하는 것이 성능과 구현 측면에서 훨씬 유리합니다.
-    
-
----
-
-_Last updated: 2026-04-15_
-- Raw Source: [[00_Raw/2026-04-20/대규모 데이터 렌더링 및 가상화 최적화.md]]
----
diff --git a/Programming & Language/대규모 로그 뷰어 및 데이터 테이블 구현.md b/Programming & Language/대규모 로그 뷰어 및 데이터 테이블 구현.md
deleted file mode 100644
index 0a8b2dff..00000000
--- a/Programming & Language/대규모 로그 뷰어 및 데이터 테이블 구현.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-7D1621
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - 대규모 로그 뷰어 및 데이터 테이블 구현"
----
-
-# [[대규모 로그 뷰어 및 데이터 테이블 구현]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/대규모 로그 뷰어 및 데이터 테이블 구현.md]]
----
diff --git a/Programming & Language/대규모 모노레포(Turborepo) 환경에서의 린트 오케스트레이션.md b/Programming & Language/대규모 모노레포(Turborepo) 환경에서의 린트 오케스트레이션.md
deleted file mode 100644
index 1f97a1ab..00000000
--- a/Programming & Language/대규모 모노레포(Turborepo) 환경에서의 린트 오케스트레이션.md	
+++ /dev/null
@@ -1,34 +0,0 @@
----
-id: P-REINFORCE-AUTO-873405
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - 대규모 모노레포(Turborepo) 환경에서의 린트 오케스트레이션"
----
-
-# [[대규모 모노레포(Turborepo) 환경에서의 린트 오케스트레이션]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 대규모 모노레포(Turborepo) 환경에서는 여러 패키지가 혼재하여 린트(ESLint, Prettier) 설정이 중복되고 일관성이 떨어지며 모노레포 루트에서 `lint-staged`를 실행하기 까다로운 문제가 발생합니다 [1-3]. 이를 해결하기 위해 중앙 집중식 설정 패키지를 구성하고, 모노레포 루트에서 파일 패턴을 기반으로 적절한 프리셋을 매핑하는 오케스트레이션 구성을 도입합니다 [3, 4]. 이 아키텍처는 패키지별 자율성을 유지하면서도 Husky 및 lint-staged와 결합하여 변경된 파일만 효율적으로 검사할 수 있도록 지원합니다 [5, 6].
-
-## 📖 구조화된 지식 (Synthesized Content)
-*   **기존 모노레포 린트 관리의 한계:** 대규모 모노레포에는 Next.js 애플리케이션, 라이브러리 패키지, 공유 코드 등이 함께 존재합니다 [2]. 기존에는 패키지마다 `.eslintrc.json` 및 `.eslintignore` 파일이 중복으로 생성되어 유지보수가 어렵고 패키지 간 규칙의 일관성이 떨어지는 문제가 있었습니다 [1, 2]. 특히, 커밋 시 변경된 파일만 검사하기 위해 모노레포 루트에서 `lint-staged`를 실행할 때, 각 패키지의 고유한 린트 규칙을 존중하게 만드는 것이 매우 어려운 과제였습니다 [3].
-*   **중앙 집중식 설정 패키지 도입:** 이 문제를 해결하기 위해 모노레포 내에 전용 설정 패키지(예: `@repo/eslint-config`)를 생성하여 기본(Base), Next.js, 라이브러리용 프리셋 등 조합 가능한 구성(composable preset configurations)을 만듭니다 [3, 7]. 이 중앙 집중식 패키지는 핵심 규칙에 대한 단일 진실 공급원(Single source of truth) 역할을 하며, 개별 패키지는 이를 가져와 자율적으로 특정 규칙을 덮어쓸 수 있습니다 [5].
-*   **루트 오케스트레이션 구성(Root Orchestration Config):** 핵심 해결책은 모노레포 루트에 `eslint.config.mjs`를 생성하여 파일 글로브(glob) 패턴을 적절한 린트 구성에 매핑하는 것입니다 [4]. 이 오케스트레이션 파일은 전역적으로 기본 규칙을 적용하면서, 파일 경로에 따라 Next.js 구성이나 라이브러리 구성을 적절히 지휘하여 패키지 경계(package boundaries)를 존중합니다 [4].
-*   **Husky 및 lint-staged와의 통합:** 커밋을 수행할 때 Husky가 `pre-commit` 훅을 트리거하고 `lint-staged`가 변경된 파일을 식별합니다 [6]. 이때 ESLint는 루트 구성을 기반으로 실행되며, 매핑된 파일 패턴에 따라 각 패키지별 규칙에 맞게 변경된 파일만 린트 검사를 수행합니다 [6].
-*   **Turborepo를 통한 캐싱 최적화:** `turbo.json`에 ESLint 설정 패키지를 전역 종속성으로 추가하여 관리합니다 [6]. 이 설정을 통해 Turborepo는 린트 결과를 실행 간에 캐시하며, 중앙 설정이 변경될 때만 전체 패키지의 캐시를 무효화하므로 검사 속도가 획기적으로 향상됩니다 [6, 8].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[ESLint]], [[Prettier]], [[Husky]], [[lint-staged]]
-- **Projects/Contexts:** [[Turborepo를 활용한 다중 애플리케이션 및 라이브러리 통합 관리]]
-- **Contradictions/Notes:** 분산된 린트 구성 방식은 개별 패키지의 제어력을 높여줄 것 같지만 실제로는 심각한 중복과 유지보수 문제를 야기합니다. 소스는 오히려 중앙 집중식 설정과 루트 오케스트레이션을 결합하는 방식이 종속성 중복을 줄이고(package-lock.json 축소), 전체적인 코드 라인 수를 감소시키면서도 패키지별 자율성을 보장할 수 있다고 강조합니다 [5, 8, 9].
-
----
-*Last updated: 2026-04-18*
-- Raw Source: [[00_Raw/2026-04-20/대규모 모노레포(Turborepo) 환경에서의 린트 오케스트레이션.md]]
----
diff --git a/Programming & Language/대규모 애플리케이션 개발.md b/Programming & Language/대규모 애플리케이션 개발.md
deleted file mode 100644
index 11cdd114..00000000
--- a/Programming & Language/대규모 애플리케이션 개발.md	
+++ /dev/null
@@ -1,46 +0,0 @@
----
-id: P-REINFORCE-AUTO-0D36D4
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - 대규모 애플리케이션 개발"
----
-
-# [[대규모 애플리케이션 개발]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-* **구조적 타이핑(Structural Typing)과 방어 메커니즘**
-  TypeScript는 객체의 구조가 일치하면 호환성을 인정하는 '구조적 타이핑' 메커니즘을 근간으로 한다 [1, 3]. 이로 인해 발생할 수 있는 의도치 않은 데이터의 유입을 막기 위해 객체 리터럴 직접 할당 시 '과잉 속성 체크(Excess Property Checking)'가 작동한다 [3]. 할당 과정을 우회하여 발생하는 EPC의 한계는 TypeScript 4.9에 도입된 `satisfies` 연산자로 해결할 수 있으며, 이를 통해 객체의 구체적인 타입을 유지하면서 대상 인터페이스를 엄격하게 검증한다 [5, 6].
-
-* **인터페이스(Interface)와 타입 별칭(Type Alias)의 전략적 이원화**
-  대규모 프로젝트의 컴파일 성능을 최적화하기 위해서는 도메인 모델과 같이 여러 곳에서 참조되는 핵심 정의에 타입 관계 캐싱이 용이한 '인터페이스'를 우선 사용해야 한다 [7]. 외부와의 소통이 필요한 계약 지점에는 선언 병합(Declaration Merging)이 가능한 인터페이스를 활용하고, 핵심 비즈니스 로직에는 엄격한 관리를 위해 타입 별칭을 사용하는 전략적 이원화가 필요하다 [7, 8]. 또한, 클래스 상속보다는 얕은 단위의 인터페이스를 조립하는 합성(Composition)을 활용해 결합도를 낮추어야 한다 [8].
-
-* **불변성(Immutability) 확립과 데이터 오염 방지**
-  데이터 무결성을 보호하기 위해 런타임 성능 오버헤드가 없는 `readonly` 수식어를 적극적으로 활용하여 컴파일 수준에서 객체 변경을 금지한다 [4]. 얕은 수준의 보호를 넘어서기 위해 매핑 타입(Mapped Types)과 조건부 타입(Conditional Types)을 엮은 `DeepReadonly`와 같은 재귀적 불변성 패턴을 적용해 복잡한 중첩 데이터의 상태 변화를 원천 차단한다 [4, 9].
-
-* **식별 가능한 유니온(Discriminated Unions)과 완전성 검사(Exhaustiveness Checking)**
-  공통된 리터럴 속성을 태그로 사용하여 합집합 내의 특정 가지를 구별하고 안전하게 타입을 좁힌다(Narrowing) [10]. 특히, `never` 타입을 활용한 완전성 검사는 유니온 타입에 새로운 상태가 추가되었을 때 처리되지 않은 분기를 컴파일 에러로 포착하여, 시스템 확장에 따른 빈틈을 철저히 방어한다 [10].
-
-* **브랜디드 타입(Branded Types)을 통한 명목적 타이핑 수복**
-  구조적 타이핑이 의미적으로 다른 데이터(예: 이메일과 이름)를 구분하지 못하는 '기본 타입에의 집착(Primitive Obsession)' 문제를 해결하기 위해, 컴파일 시점에만 존재하는 고유 속성을 부여하는 브랜디드 타입을 활용한다 [6, 11]. 이를 통해 검증된 데이터만 시스템 내부 로직으로 진입하도록 강제한다 [6].
-
-* **SOLID 원칙과 아키텍처적 인터페이스 설계**
-  단일 책임 원칙(SRP)과 인터페이스 분리 원칙(ISP)을 준수해 최소 단위로 쪼갠 인터페이스를 조합하는 것이 중요하다 [12]. 복잡한 서브시스템을 단순화된 인터페이스로 감싸는 퍼사드(Facade) 패턴을 통해 인지 부하와 결합도를 낮추며, "검증하지 말고 파싱하라"는 원칙을 적용하여 신뢰할 수 있는 타입의 객체만을 시스템 내부로 전달해야 한다 [12].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[구조적 타이핑(Structural Typing)]], [[식별 가능한 유니온(Discriminated Unions)]], [[브랜디드 타입(Branded Types)]], [[불변성(Immutability)]], [[satisfies 연산자]]
-- **Projects/Contexts:** [[토스(Toss) Front SDK 퍼사드 패턴 적용]], [[Zod 파싱과 브랜디드 타입을 결합한 런타임 데이터 검증]]
-- **Contradictions/Notes:** 소스에 따르면 "상속(Inheritance)"보다 "합성(Composition)"을 선호하는 것이 TypeScript 인터페이스 설계의 핵심 원칙 중 하나라고 주장합니다. 클래스 기반 상속은 구조를 경직시키고 결합도를 높이므로, 작은 인터페이스들의 조합을 통해 유연한 수비력을 제공해야 한다고 강조합니다 [8, 12]. 또한 구조적 타이핑의 유연성은 개발의 편의를 주지만, 이로 인한 '기본 타입에의 집착'과 같은 취약점은 브랜디드 타입이라는 인위적인 명목적 타이핑 우회로를 통해 보완해야 한다고 지적합니다 [6, 11].
-
----
-*Last updated: 2026-04-18*
-- Raw Source: [[00_Raw/2026-04-20/대규모 애플리케이션 개발.md]]
----
diff --git a/Programming & Language/대규모 웹 그래픽스 프로젝트.md b/Programming & Language/대규모 웹 그래픽스 프로젝트.md
deleted file mode 100644
index e5f570b4..00000000
--- a/Programming & Language/대규모 웹 그래픽스 프로젝트.md	
+++ /dev/null
@@ -1,44 +0,0 @@
----
-id: P-REINFORCE-AUTO-F01D3F
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - 대규모 웹 그래픽스 프로젝트"
----
-
-# [[대규모 웹 그래픽스 프로젝트]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> InstancedMesh는 동일한 기하학적 구조와 재질을 가진 수많은 객체를 단 한 번의 드로우 콜(Draw Call)로 처리하여 CPU 병목을 획기적으로 줄여주는 실시간 웹 그래픽스 렌더링 최적화 기술입니다[1-4]. 그러나 이러한 드로우 콜 최적화는 시야 절두체 컬링(Frustum Culling)의 비효율성, 개별 객체 정렬 부재로 인한 오버드로우(Overdraw), 메모리 대역폭 한계, 그리고 애니메이션 및 상호작용 구현의 어려움 등 다양한 구조적 한계와 새로운 성능 병목 현상을 유발하는 것으로 나타났습니다[5, 6].
-
-## 📖 구조화된 지식 (Synthesized Content)
-*   **기하학적 구조 및 재질의 단일성 제약**
-    InstancedMesh의 가장 근본적인 한계는 모든 인스턴스가 단 하나의 `BufferGeometry`와 `Material`을 공유해야 한다는 점입니다[3, 7]. 장면 내 오브젝트 종류가 늘어날수록 개별적인 InstancedMesh를 생성해야 하므로 최적화 효과가 희석됩니다[7]. 또한, 인스턴스마다 다른 텍스처를 적용하려면 텍스처 아틀라스(Texture Atlas)나 해상도 제약이 있는 텍스처 배열(Texture Array) 등의 우회 기법이 강제되어 셰이더 코드의 복잡성이 증가합니다[8].
-
-*   **시야 절두체 컬링(Frustum Culling)의 비효율성**
-    InstancedMesh는 엔진 수준에서 단일 객체로 취급되므로, 전체 인스턴스를 포함하는 거대한 바운딩 볼륨을 기준으로 단 한 번의 컬링 판정만 수행됩니다[9]. 결과적으로 시야에 단 하나의 인스턴스만 보이더라도 GPU는 보이지 않는 나머지 모든 인스턴스의 정점 변환 연산을 수행해야 하므로 GPU 점유율이 낭비됩니다[9, 10]. 이를 피하고자 CPU에서 직접 개별 인스턴스의 가시성을 판단하고 버퍼를 재구성할 수 있으나, 이는 자바스크립트 메인 스레드에 막대한 부하를 일으킵니다[11].
-
-*   **정렬(Sorting) 부재로 인한 오버드로우(Overdraw)**
-    InstancedMesh 내부의 인스턴스들은 버퍼에 저장된 순서대로만 렌더링되며, 엔진 차원의 자동 정렬 기능을 제공하지 않습니다[6, 12]. 불투명한 객체의 경우 앞에서 뒤로(Front-to-Back) 렌더링하여 가려진 픽셀 연산을 일찍 종료해야 하지만, 정렬되지 않은 인스턴스들은 동일한 픽셀에 여러 번 쓰기 작업을 수행하는 막대한 오버드로우를 유발합니다[6, 13]. 반투명 객체의 경우 뒤에서 앞으로(Back-to-Front) 렌더링하지 않으면 시각적 결함이 발생하며, 이를 해결하기 위해 매 프레임마다 거리를 계산해 버퍼를 정렬하는 것은 CPU에 치명적인 부하를 줍니다[14, 15]. 
-
-*   **메모리 대역폭 임계점과 데이터 전송 병목**
-    각 인스턴스의 변환 정보는 64바이트의 부동 소수점 행렬로 구성되는데, 수백만 개의 인스턴스 위치가 매 프레임 변할 경우 기가바이트(GB/s) 단위의 데이터가 시스템 메모리에서 GPU로 전송되어야 하므로 대역폭 병목이 발생합니다[16]. 또한 인스턴스 수가 동적으로 초과되어 버퍼를 새로 할당하고 데이터를 복사해야 할 경우, 빈번한 가비지 컬렉션(GC) 부하로 인해 프레임 스터터링(Stuttering)이 유발됩니다[17].
-
-*   **피킹(Picking) 및 스킨드 애니메이션(Skinned Animation)의 한계**
-    사용자가 특정 객체를 선택하는 레이캐스팅(Raycasting) 작업 시, CPU는 수만 개의 인스턴스 행렬을 모두 역산해야 하므로 극심한 반응 지연이 발생합니다[18]. GPU 피킹 방식을 대안으로 사용하더라도 파이프라인 동기화 지연(Sync stall)과 오클루전 한계가 존재합니다[19]. 또한 스킨드 애니메이션의 경우, 인스턴스별로 수십 개의 본(Bone) 행렬 세트를 전달해야 하므로 인스턴스 속성 버퍼 한계를 초과하며 엔진의 기본 `AnimationMixer`와도 구조적으로 호환되지 않습니다[20].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[InstancedMesh]], [[BatchedMesh]], [[Frustum Culling]], [[Overdraw]], [[Draw Call]]
-- **Projects/Contexts:** [[WebGPU]], [[InstancedMesh2]]
-- **Contradictions/Notes:** 
-  드로우 콜을 1회로 극적으로 줄이는 InstancedMesh가 무조건적인 성능 향상을 보장하지는 않습니다. 개별 인스턴스에 대한 시야 절두체 컬링과 깊이 정렬(Depth Sorting)이 지원되지 않기 때문에, 조명 연산이 복잡한 `MeshStandardMaterial` 등을 사용할 경우 발생하는 심각한 오버드로우로 인해 드로우 콜이 5,000회인 일반 Mesh 방식보다 InstancedMesh 방식의 FPS가 오히려 더 낮게 측정되는 모순적인 병목 현상이 실증적으로 보고되었습니다[6, 12, 13].
-
----
-*Last updated: 2026-04-19*
-- Raw Source: [[00_Raw/2026-04-20/대규모 웹 그래픽스 프로젝트.md]]
----
diff --git a/Programming & Language/대규모 웹 애플리케이션의 조직 및 기술적 확장성 확보.md b/Programming & Language/대규모 웹 애플리케이션의 조직 및 기술적 확장성 확보.md
deleted file mode 100644
index b9d955c6..00000000
--- a/Programming & Language/대규모 웹 애플리케이션의 조직 및 기술적 확장성 확보.md	
+++ /dev/null
@@ -1,42 +0,0 @@
----
-id: P-REINFORCE-AUTO-714552
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - 대규모 웹 애플리케이션의 조직 및 기술적 확장성 확보"
----
-
-# [[대규모 웹 애플리케이션의 조직 및 기술적 확장성 확보]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 대규모 웹 애플리케이션에서 기술적, 조직적 확장성을 동시에 확보하기 위해서는 모놀리식 구조를 탈피하고 시스템을 독립적으로 관리 가능한 작은 단위로 분할해야 합니다 [1, 2]. 이를 위해 마이크로서비스 아키텍처(MSA) 및 마이크로 프론트엔드와 같은 기술적 접근 방식이 사용되며, 이는 기술적 결합도를 낮추고 유연한 시스템 확장을 가능하게 합니다 [1, 3]. 동시에 이렇게 분리된 모듈들을 소규모 전담 팀이 독립적으로 책임지고 개발, 테스트, 배포하게 함으로써, 병렬적 업무 수행을 통한 조직적 확장성과 혁신 속도를 높일 수 있습니다 [4, 5].
-
-## 📖 구조화된 지식 (Synthesized Content)
-* **기술적 확장성 (Technical Scalability) 확보**
-  * **마이크로서비스 아키텍처(MSA):** 대규모 시스템을 비즈니스 기능(도메인)을 중심으로 하는 작고 자율적인 서비스들의 집합으로 분해합니다 [1]. 각 서비스는 자체 코드베이스와 데이터베이스를 가지며 독립적으로 배포 및 확장이 가능하므로 애플리케이션의 유연성과 확장성이 극대화됩니다 [1, 6]. 확장성(Scaling)은 X축(수평 확장), Y축(리소스 또는 기능별 분할), Z축(데이터 파티셔닝) 등의 방법론으로 세분화될 수 있습니다 [7, 8].
-  * **마이크로 프론트엔드 (Micro Frontends):** 프론트엔드 영역에서도 단일의 거대한 모놀리식 구조에서 벗어나, 비즈니스 기능에 따라 여러 개의 작고 독립적인 조각으로 UI를 분할하여 확장성을 확보합니다 [2, 9]. 이는 라우트 기반, 컴포넌트 기반 조합 등 다양한 아키텍처 패턴을 통해 구현되며, 런타임 통합 또는 동적 로딩을 통해 최종 애플리케이션으로 조립됩니다 [10, 11].
-  * **클라우드 네이티브 및 이벤트 기반 아키텍처:** 컨테이너(예: Docker) 및 오케스트레이션 플랫폼(예: Kubernetes)을 활용해 애플리케이션을 자동으로 배포하고 탄력적으로 수평 확장합니다 [12, 13]. 또한, 이벤트 기반 아키텍처(EDA)를 통해 시스템 컴포넌트 간의 결합도를 낮추고 비동기적으로 이벤트를 처리하여 높은 부하를 유연하게 견딜 수 있게 합니다 [14, 15].
-
-* **조직적 확장성 (Organizational Scalability) 확보**
-  * **관심사의 분리(SoC)를 통한 병렬 개발:** 시스템을 명확한 경계로 나누는 관심사의 분리 원칙은 기술적 영역뿐만 아니라 조직 운영에도 직접적으로 적용됩니다 [5, 16]. 시스템이 분리되면 여러 개발자나 팀이 서로의 작업에 간섭하지 않고 병렬로 개발을 진행할 수 있어 조직 전체의 생산성이 높아집니다 [16, 17].
-  * **팀의 자율성과 엔드투엔드(End-to-End) 소유권:** 각 마이크로서비스 및 마이크로 프론트엔드는 소규모의 전담 팀에 의해 온전히 소유되며, 개발, 테스트, 배포, 유지보수에 이르는 전체 생명주기를 해당 팀이 독자적으로 관리합니다 [2, 4, 18]. 이는 기술 스택 선택의 자율성을 보장하고 다른 팀의 일정에 얽매이지 않는 빠른 릴리스를 가능하게 합니다 [3, 6].
-  * **API 우선 아키텍처 (API-First Architecture):** 프론트엔드와 백엔드 팀 간의 원활한 통합을 위해 API 명세를 단일 진실 공급원(Single source of truth)으로 먼저 정의합니다 [19, 20]. 이를 통해 두 팀이 서로의 작업 완료를 기다리지 않고 병렬로 독립적인 개발을 진행할 수 있어 대규모 조직의 협업 효율성을 높입니다 [20, 21].
-
-* **성공적인 적용 사례 (Case Studies)**
-  * **넷플릭스 (Netflix):** 기존의 거대한 모놀리식 아키텍처를 독립적인 마이크로서비스로 분해하여 느슨한 결합(Loose coupling)을 달성했으며, 이를 통해 개발팀의 속도를 높이고 혁신, 신뢰성, 효율성을 대폭 개선했습니다 [22-24].
-  * **스포티파이 (Spotify):** 엔지니어링 조직을 특정 기능에 대해 완전한 책임을 지는 '스쿼드(Squad)'라는 단위로 나누고, 프론트엔드 역시 마이크로 프론트엔드를 도입하여 각 팀이 독립적으로 특정 화면을 개발하고 배포할 수 있는 조직적·기술적 확장성을 실현했습니다 [5, 25].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[Microservices Architecture]], [[Micro Frontends]], [[Separation of Concerns]], [[API-First Architecture]], [[Cloud-Native Architecture]]
-- **Projects/Contexts:** [[Netflix Cosmos Platform]], [[Spotify Squad Model]]
-- **Contradictions/Notes:** 조직 및 기술적 확장성을 위해 마이크로서비스 등을 도입하면 높은 유연성과 병렬성을 얻지만, 반대로 분산 시스템 구축으로 인한 컴포넌트 간 통신 메커니즘 구현의 어려움, 다중 서비스 배포 및 운영 관리의 복잡성 증가, 메모리 및 서버 인프라 유지 비용 상승 등의 새로운 문제와 트레이드오프가 필연적으로 발생합니다 [26-29].
-
----
-*Last updated: 2026-04-18*
-- Raw Source: [[00_Raw/2026-04-20/대규모 웹 애플리케이션의 조직 및 기술적 확장성 확보.md]]
----
diff --git a/Programming & Language/대규모 인스턴스 렌더링 및 투명도 처리.md b/Programming & Language/대규모 인스턴스 렌더링 및 투명도 처리.md
deleted file mode 100644
index 6a6cf1a6..00000000
--- a/Programming & Language/대규모 인스턴스 렌더링 및 투명도 처리.md	
+++ /dev/null
@@ -1,30 +0,0 @@
----
-id: P-REINFORCE-AUTO-3EBBAF
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - 대규모 인스턴스 렌더링 및 투명도 처리"
----
-
-# [[대규모 인스턴스 렌더링 및 투명도 처리]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 대규모 인스턴스 렌더링(InstancedMesh)은 동일한 기하학적 구조와 재질을 가진 수많은 객체를 단일 드로우 콜로 처리하여 CPU 병목을 줄이는 렌더링 최적화 기술이다[1, 2]. 하지만 인스턴스 간의 자동 정렬 기능이 없어 투명도 처리를 위한 알파 블렌딩(Alpha Blending) 시 치명적인 시각적 오류를 유발할 수 있다[3]. 이를 해결하기 위해 매 프레임 수동으로 객체를 정렬하면 막대한 CPU 오버헤드가 발생하므로, 대규모 투명 객체 렌더링 시에는 성능과 품질 사이의 철저한 타협이 요구된다[3].
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[InstancedMesh]], [[Alpha Blending]], [[Overdraw]], [[Draw Call]], [[Frustum Culling]]
-- **Projects/Contexts:** [[Three.js 대규모 렌더링 최적화 파이프라인]], [[BatchedMesh 및 InstancedMesh 성능 벤치마크]]
-- **Contradictions/Notes:** CPU의 드로우 콜 오버헤드를 줄이기 위해 InstancedMesh를 도입하지만, 투명도 오류를 해결하기 위해 수동으로 카메라 거리 계산 및 인스턴스 정렬을 시도할 경우 도리어 막대한 CPU 병목을 유발하는 구조적 모순이 발생한다[3].
-
----
-*Last updated: 2026-04-19*
-- Raw Source: [[00_Raw/2026-04-20/대규모 인스턴스 렌더링 및 투명도 처리.md]]
----
diff --git a/Programming & Language/덕 타이핑 (Duck Typing).md b/Programming & Language/덕 타이핑 (Duck Typing).md
deleted file mode 100644
index c41eb495..00000000
--- a/Programming & Language/덕 타이핑 (Duck Typing).md	
+++ /dev/null
@@ -1,30 +0,0 @@
----
-id: P-REINFORCE-AUTO-EFC438
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - 덕 타이핑 (Duck Typing)"
----
-
-# [[덕 타이핑 (Duck Typing)]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 덕 타이핑(Duck Typing)은 TypeScript의 근본적인 타입 시스템인 '구조적 타이핑(Structural Typing)'을 일컫는 또 다른 용어로, "만약 어떤 것이 오리처럼 걷고 오리처럼 꽥꽥거리면 그것은 오리다"라는 격언에서 유래했습니다 [1, 2]. 이 시스템에서는 명시적인 타입의 이름이나 선언이 일치할 필요 없이, 객체의 실제 형태나 요구되는 속성(구조)을 최소한으로 포함하고 있다면 동일한 타입 혹은 호환되는 타입으로 간주합니다 [1, 3]. 이는 자바스크립트의 유연성을 살려주지만, 의도하지 않은 잉여 속성의 유입이나 의미적으로 다른 데이터를 구별하지 못하는 보안적 허점을 유발할 수 있어 TypeScript 내의 다양한 보완적 방어 기제와 함께 사용됩니다 [4, 5].
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[구조적 타이핑 (Structural Typing)]], [[명목적 타이핑 (Nominal Typing)]], [[과잉 속성 체크 (Excess Property Checking)]], [[satisfies 연산자]], [[브랜디드 타입 (Branded Types)]]
-- **Projects/Contexts:** [[철벽 수비대: TypeScript 타입 시스템과 견고한 인터페이스 설계의 정수]]
-- **Contradictions/Notes:** 덕 타이핑은 자바스크립트 고유의 동적인 유연성을 잘 살려주지만, 구조만 같으면 모든 호환을 허용하므로 시스템 경계에서 오염된 데이터를 완벽히 걸러내지 못합니다. 따라서 견고한 인터페이스 설계를 위해서는 과잉 속성 체크나 satisfies 연산자, 브랜디드 타입 같은 "엄격한 수비 장치"들과의 결합이 필수적으로 요구됩니다 [4, 5, 8, 11].
-
----
-*Last updated: 2026-04-18*
-- Raw Source: [[00_Raw/2026-04-20/덕 타이핑 (Duck Typing).md]]
----
diff --git a/Programming & Language/덕 타이핑(Duck Typing).md b/Programming & Language/덕 타이핑(Duck Typing).md
deleted file mode 100644
index 26028569..00000000
--- a/Programming & Language/덕 타이핑(Duck Typing).md	
+++ /dev/null
@@ -1,32 +0,0 @@
----
-id: P-REINFORCE-AUTO-5164C3
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - 덕 타이핑(Duck Typing)"
----
-
-# [[덕 타이핑(Duck Typing)]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 덕 타이핑(Duck Typing)은 객체의 실제 형태나 구조에 기반하여 타입을 결정하는 방식을 의미합니다 [1-3]. "만약 어떤 것이 오리처럼 걷고 오리처럼 갉갉거리면 그것은 오리다"라는 개념에 바탕을 둡니다 [1, 3]. 타입스크립트와 자바스크립트의 핵심적인 타입 시스템 특징으로, 명시적인 타입 이름의 선언 없이도 멤버(속성과 메서드)의 형태가 일치하면 호환성을 인정하는 구조적 타이핑(Structural Typing)과 동일한 의미로 불립니다 [1-3].
-
-## 📖 구조화된 지식 (Synthesized Content)
-* **기본 원리 및 호환성:** 덕 타이핑(또는 구조적 서브타이핑) 체계에서는 값이나 객체가 가진 형태(Shape)에 초점을 맞추어 타입을 검사합니다 [2]. 기본 규칙에 따르면, 객체 `x`가 타겟 타입 `y`가 가진 멤버를 최소한 동일하게 모두 포함하고 있다면 `x`는 `y`와 호환되는 것으로 간주됩니다 [1]. 즉, 할당되는 값이 타겟 타입의 요구 속성을 모두 갖추고 있기만 하면 정상적인 타입으로 취급됩니다 [1].
-* **자바스크립트 생태계의 특성과 한계:** 자바스크립트는 기본적으로 덕 타이핑 메커니즘을 따르기 때문에, 단순히 객체의 속성 세트를 복제하는 것만으로도 거의 모든 객체를 흉내 낼 수 있습니다 [4]. 이러한 유연한 특성으로 인해, 자바스크립트와 타입스크립트는 구별 가능한 타입 별칭(비구조적 또는 명목적 타이핑, Nominal Typing)을 네이티브하게 생성할 수 있는 방법을 제공하지 않는다는 한계가 존재합니다 [4].
-* **한계 극복을 위한 패턴:** 덕 타이핑 환경에서는 속성 구조가 같지만 논리적/의미적으로 다른 데이터(예: 구조가 동일한 두 개의 다른 토큰 또는 식별자)를 타입 시스템 상에서 원천적으로 구별하기 어렵습니다 [4]. 이를 극복하여 안정성을 확보하기 위해, 개발자들은 '오파크 타입(Opaque Types)'이나 '브랜디드 타입(Branded Types)'과 같은 기법을 활용하여 타입 시스템 내에서만 동작하는 구별자를 만들어 사용하게 됩니다 [4].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[구조적 타이핑(Structural Typing)]], [[명목적 타이핑(Nominal Typing)]], [[오파크 타입(Opaque Types)]]
-- **Projects/Contexts:** [[타입스크립트(TypeScript) 타입 시스템 및 호환성 평가]]
-- **Contradictions/Notes:** 덕 타이핑은 높은 코드 유연성을 제공하지만, 그로 인해 구조가 같은 다른 의미의 데이터를 원천적으로 구별하기 어렵다는 단점이 있습니다. 따라서 이 문제를 해결하기 위해 오파크 타입(Opaque Types) 등의 별도 기법이 요구됩니다 [4].
-
----
-*Last updated: 2026-04-18*
-- Raw Source: [[00_Raw/2026-04-20/덕 타이핑(Duck Typing).md]]
----
diff --git a/Programming & Language/데브섹옵스 (DevSecOps) 환경에서의 지속적인 보안 검사.md b/Programming & Language/데브섹옵스 (DevSecOps) 환경에서의 지속적인 보안 검사.md
deleted file mode 100644
index 9296bb9e..00000000
--- a/Programming & Language/데브섹옵스 (DevSecOps) 환경에서의 지속적인 보안 검사.md	
+++ /dev/null
@@ -1,43 +0,0 @@
----
-id: P-REINFORCE-AUTO-DF816E
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - 데브섹옵스 (DevSecOps) 환경에서의 지속적인 보안 검사"
----
-
-# [[데브섹옵스 (DevSecOps) 환경에서의 지속적인 보안 검사]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 데브섹옵스(DevSecOps) 환경에서의 지속적인 보안 검사는 소프트웨어 개발 수명 주기(SDLC)의 모든 단계에 보안을 내재화하여 실시간으로 취약점을 식별하고 해결하는 과정을 의미합니다 [1, 2]. 이는 CI/CD 파이프라인이나 IDE에 정적 애플리케이션 보안 테스트(SAST), 소프트웨어 구성 분석(SCA) 등 자동화된 도구를 통합함으로써 코드가 작성되거나 풀 리퀘스트(PR)가 생성될 때 즉각적인 피드백을 제공합니다 [3-5]. 결과적으로 개발 초기 단계부터 보안 문제를 차단하는 '시프트 레프트(Shift-Left)' 전략을 통해 개발 속도를 늦추지 않으면서도 높은 보안 품질을 유지하게 합니다 [5, 6].
-
-## 📖 구조화된 지식 (Synthesized Content)
-- **시프트 레프트(Shift-Left) 전략과 조기 탐지:** 
-  지속적인 보안 검사의 핵심은 취약점 발견 및 조치 시점을 개발 초기 단계로 앞당기는 '시프트 레프트'에 있습니다 [3, 5]. 개발자의 통합 개발 환경(IDE)이나 커밋 전 훅(pre-commit hooks) 수준에 보안 스캐닝을 내장함으로써, 보안 문제를 코드 작성 단계에서 가장 빠르고 저렴하게 수정할 수 있습니다 [2, 6, 7].
-
-- **CI/CD 파이프라인 통합과 품질 게이트 자동화:**
-  SonarQube, Snyk, Semgrep 등의 스캐닝 도구들은 CI/CD 파이프라인 내에 직접 연동되어 코드 리뷰 프로세스의 일부로 자동 실행됩니다 [4, 8, 9]. 조직은 코드에 심각한 보안 결함이 발견될 경우 빌드를 실패하게 하거나 풀 리퀘스트 병합을 차단하는 '품질 게이트(Quality Gate)'를 설정하여 일관된 보안 기준을 강제할 수 있습니다 [5, 10, 11].
-
-- **자동화 검사와 수동 검토의 하이브리드 접근:**
-  자동화된 보안 리뷰는 수천 줄의 코드를 순식간에 분석해 SQL 인젝션, XSS 등 널리 알려진 패턴 및 구문 오류를 찾아내는 데 탁월합니다 [12]. 하지만 비즈니스 로직이나 시스템 아키텍처의 의도를 파악하는 데는 '문맥 맹점(Context Blindness)'을 지니며 오탐(False Positives)을 유발할 수 있습니다 [13]. 따라서 자동화 스캔 도구로 일상적이고 반복적인 검사를 먼저 수행하여 문제를 조기에 필터링한 후, 인력(보안 전문가/개발자)이 아키텍처 결정이나 복잡한 비즈니스 로직 등 중요한 영역의 수동 리뷰에 집중하는 하이브리드 리뷰 파이프라인 구축이 권장됩니다 [4, 14-16].
-
-- **AI 기반 탐지 및 자동 수정(Auto-Fix) 기능의 도입:**
-  최근의 지속적인 보안 검사에는 기계 학습과 LLM을 활용한 AI-Native 정적 분석 기능이 결합되고 있습니다 [17]. Snyk의 DeepCode AI, GitHub의 Copilot Autofix 등은 기존 룰 기반 엔진이 놓치기 쉬운 파일 간 복잡한 데이터 흐름(Interfile analysis)을 파악하고 오탐지율을 낮춥니다 [18-20]. 나아가 보안 취약점을 발견하는 데 그치지 않고 풀 리퀘스트 워크플로우 내에서 실행 가능한 수정 코드(Patch)를 자동으로 제안하여 개발팀의 취약점 해결 속도를 크게 단축시킵니다 [21, 22].
-
-- **다양한 보안 도구의 융합 운영:**
-  효과적인 데브섹옵스 환경 구축을 위해서는 단일 도구에 의존하지 않고 각기 다른 검사 방식들을 상호 보완적으로 운용해야 합니다 [23, 24]. 작성된 코드를 스캔하는 SAST, 실행 중인 앱을 동적으로 테스트하는 DAST, 써드파티 라이브러리 및 오픈소스 취약점을 확인하는 SCA, 그리고 이들을 결합한 IAST 도구들을 함께 사용하여, 자체 코드와 오픈소스 의존성, 런타임 구성 등 애플리케이션의 모든 영역에 걸쳐 방어 체계를 확립합니다 [25-27].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[SAST (Static Application Security Testing)]], [[시프트 레프트 (Shift-Left)]], [[CI/CD 파이프라인]], [[하이브리드 코드 리뷰]], [[오픈소스 컴포지션 분석 (SCA)]]
-- **Projects/Contexts:** [[GitHub Code Security 워크플로우]], [[Snyk의 개발자 우선(Developer-First) 보안 통합]], [[SonarQube의 파이프라인 품질 게이트]]
-- **Contradictions/Notes:** 자동화된 정적 애플리케이션 보안 테스트(SAST)는 코드베이스 전체에 걸쳐 알려진 보안 결함을 빠르고 일관되게 감지하는 데 탁월하지만 [12], 코드의 기저에 깔린 비즈니스 로직을 이해하지 못하는 한계(Context Blindness)가 있습니다 [13]. 여러 연구들은 특정 자동화 도구 단일로는 실제 취약점의 약 22%를 놓치거나 높은 오탐지율(False Positives)을 기록할 수 있음을 지적하며, 효과적인 보안 보장을 위해 인간 리뷰어의 맥락 판단을 결합하는 '하이브리드 리뷰'의 당위성을 주장합니다 [28, 29].
-
----
-*Last updated: 2026-04-18*
-- Raw Source: [[00_Raw/2026-04-20/데브섹옵스 (DevSecOps) 환경에서의 지속적인 보안 검사.md]]
----
diff --git a/Programming & Language/데이터 거버넌스 (Data Governance).md b/Programming & Language/데이터 거버넌스 (Data Governance).md
deleted file mode 100644
index 21bb228f..00000000
--- a/Programming & Language/데이터 거버넌스 (Data Governance).md	
+++ /dev/null
@@ -1,37 +0,0 @@
----
-id: P-REINFORCE-AUTO-1F9ACB
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - 데이터 거버넌스 (Data Governance)"
----
-
-# [[데이터 거버넌스 (Data Governance)]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 데이터 거버넌스(Data Governance)는 확장 가능한 데이터 아키텍처 내에서 데이터 자산을 관리하기 위한 정책 및 프로세스의 프레임워크입니다 [1]. 이 관행은 데이터를 하나의 제품으로 취급하여 규칙, 소유권, 그리고 명확한 카탈로그를 요구합니다 [1]. 강력한 데이터 거버넌스를 구축하지 않으면 조직은 규정 준수 위반, 신뢰할 수 없는 데이터에 기반한 잘못된 의사 결정, 엔지니어링 노력의 중복과 같은 중대한 위험에 직면하게 됩니다 [1].
-
-## 📖 구조화된 지식 (Synthesized Content)
-- **개념과 가치:** 데이터 거버넌스는 혼란스러운 데이터 환경(데이터 늪)을 신뢰할 수 있고 안전하며 문서화가 잘 된 데이터 웨어하우스로 변환하는 데 필수적인 역할을 합니다 [1]. 특히 규제가 심한 산업, 대규모 기업 및 다중 소스 환경에서 이상적인 유스케이스를 가지며, 규제 준수(예: 금융 기관)를 가능하게 합니다 [1, 2]. 
-- **메타데이터 관리와의 결합:** 데이터 거버넌스가 관리 프레임워크를 제공한다면, 메타데이터 관리는 데이터를 발견하고, 이해하며, 신뢰할 수 있도록 돕는 기술적 기반을 제공합니다 [1]. Apache Atlas나 Collibra 같은 도구를 사용하여 메타데이터 수집을 자동화하고, 데이터 소스부터 대시보드까지의 데이터 계보를 추적하여 모든 이해관계자를 위한 중앙 카탈로그를 제공할 수 있습니다 [1].
-- **구현 복잡도:** 정책 설계와 조직적인 도입이 필요하기 때문에 거버넌스 솔루션의 구현 복잡성은 높은 편에 속합니다 [2]. 이를 위해서는 카탈로그 도구, 데이터 리니지(lineage) 통합 기술, 그리고 데이터 관리 리소스가 요구됩니다 [2].
-- **실행 가능한 구현 팁:**
-  - **중요 데이터 자산부터 시작:** 고객, 재무, 제품 등 가장 중요한 데이터 도메인을 식별하여 거버넌스 프레임워크를 먼저 구축한 후 점진적으로 확장해야 합니다 [3].
-  - **메타데이터 수집 자동화:** 데이터의 수동 문서화는 지속 불가능하므로, 데이터 소스, 웨어하우스 및 BI 플랫폼에서 메타데이터를 자동으로 스캔하고 수집하도록 도구를 구성해야 합니다 [3].
-  - **명확한 소유권 및 정책 확립:** 각 핵심 데이터 자산에 대해 명확한 데이터 소유자(owner)와 관리자(steward)를 할당하고, 이들과 협력하여 접근 제어 정책, 품질 규칙, 사용 지침을 정의해야 합니다 [3].
-  - **데이터 리니지(Lineage) 추적 구현:** 데이터 생태계 전반의 데이터 흐름을 시각화하여 영향 분석, 근본 원인 분석 및 데이터 소비자 간의 신뢰 구축에 활용해야 합니다 [3].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[메타데이터 관리 (Metadata Management)]], [[데이터 리니지 (Data Lineage)]], [[데이터 수명 주기 관리 (Data Lifecycle Management)]]
-- **Projects/Contexts:** [[확장 가능한 데이터 시스템을 구축하기 위한 데이터 엔지니어링 모범 사례]]
-- **Contradictions/Notes:** 소스 X는 이를 주장하지만, 소스 Y는 반대합니다와 같은 의견 대립이나 모순점은 소스에 관련 정보가 부족합니다.
-
----
-*Last updated: 2026-04-18*
-- Raw Source: [[00_Raw/2026-04-20/데이터 거버넌스 (Data Governance).md]]
----
diff --git a/Programming & Language/도달 가능성 분석 (Reachability Analysis).md b/Programming & Language/도달 가능성 분석 (Reachability Analysis).md
deleted file mode 100644
index e1ea3479..00000000
--- a/Programming & Language/도달 가능성 분석 (Reachability Analysis).md	
+++ /dev/null
@@ -1,36 +0,0 @@
----
-id: P-REINFORCE-AUTO-03E8DE
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - 도달 가능성 분석 (Reachability Analysis)"
----
-
-# [[도달 가능성 분석 (Reachability Analysis)]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 도달 가능성 분석(Reachability Analysis)은 소스 코드 내의 데이터 흐름이나 호출 그래프(Call Graph)를 추적하여 특정 취약점이 실제 프로덕션 환경이나 실행 경로에서 도달 가능한지를 판별하는 보안 분석 기법입니다 [1, 2]. 이를 통해 신뢰할 수 없는 오염된 데이터가 민감한 싱크(sink)나 취약한 함수에 도달할 수 있는지 검증합니다 [3]. 결과적으로 실제 실행되지 않는 경로의 취약점을 필터링하여 경고 피로(alert fatigue)를 줄이고 보안 취약점 해결의 우선순위를 명확히 지정하는 데 핵심적인 역할을 합니다 [2, 4].
-
-## 📖 구조화된 지식 (Synthesized Content)
-- **작동 원리**: 도달 가능성 분석은 소스 코드의 엔드포인트를 분석하고 취약한 함수로 향하는 호출 그래프를 생성하여 취약점의 실제 도달 여부를 보여줍니다 [1]. 특히 데이터 흐름을 추적하여 오염된 데이터(tainted data)가 민감한 영역(sensitive sinks)으로 흘러 들어갈 수 있는지 파악하는 데 중점을 둡니다 [3].
-- **오탐 및 알림 피로 감소**: 해당 분석 기법은 취약한 함수가 실제로 호출되는지, 또는 신뢰할 수 없는 사용자 입력에 노출되는지와 같은 문맥(context)을 기반으로 스캔 결과를 필터링합니다 [2]. 이를 통해 무의미한 오탐(False Positive)으로 인한 알림 피로도를 줄이고, 개발자가 실제 위험이 존재하는 취약점을 기반으로 리스크 우선순위를 지정할 수 있도록 돕습니다 [4].
-- **주요 보안 도구(SAST/SCA)에서의 활용**:
-  - **Endor Labs**: 서드파티(third-party)와 퍼스트파티(first-party) 코드 전반에 걸쳐 매우 세밀한 함수 수준(function-level)의 도달 가능성을 분석하여, 코드의 취약점이 실제 실행 경로와 어떻게 연결되는지 파악합니다 [2, 4].
-  - **Veracode**: 오염된 데이터가 민감한 영역에 접근하는지 확인하기 위해 데이터 흐름 추적 및 도달 가능성 분석을 수행합니다 [3].
-  - **Corgea**: 엔드포인트를 해석하고 호출 그래프를 구축하여 실질적인 도달 가능성을 증명합니다 [1].
-  - **Qwiet AI (Harness)**: 스캔 속도 향상 및 도달 가능성을 기반으로 한 취약점 필터링에 중점을 두어 결과를 도출합니다 [5, 6].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[정적 애플리케이션 보안 테스트 (SAST)]], [[소프트웨어 구성 분석 (SCA)]], [[데이터 흐름 분석 (Data Flow Analysis)]], [[호출 그래프 (Call Graph)]]
-- **Projects/Contexts:** [[Endor Labs]], [[Veracode]], [[Corgea]], [[Qwiet AI]]
-- **Contradictions/Notes:** 단순 규칙이나 패턴 기반의 전통적인 정적 분석 도구는 문맥 파악의 한계로 인해 오탐을 다수 발생시킬 수 있으나, 도달 가능성 분석이 결합된 최신 분석 도구들은 도달 불가능한 경로의 노이즈를 필터링하여 실제 문제 해결 효율을 크게 높여줍니다 [4, 7].
-
----
-*Last updated: 2026-04-18*
-- Raw Source: [[00_Raw/2026-04-20/도달 가능성 분석 (Reachability Analysis).md]]
----
diff --git a/Programming & Language/도메인 기반 설계 (DDD) 및 데이터 오염 방지.md b/Programming & Language/도메인 기반 설계 (DDD) 및 데이터 오염 방지.md
deleted file mode 100644
index 6488795f..00000000
--- a/Programming & Language/도메인 기반 설계 (DDD) 및 데이터 오염 방지.md	
+++ /dev/null
@@ -1,40 +0,0 @@
----
-id: P-REINFORCE-AUTO-9B5D9F
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - 도메인 기반 설계 (DDD) 및 데이터 오염 방지"
----
-
-# [[도메인 기반 설계 (DDD) 및 데이터 오염 방지]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 도메인 기반 설계(DDD)에서 데이터 오염 방지는 TypeScript의 구조적 타이핑 한계로 인해 발생하는 '기본 타입에의 집착(Primitive Obsession)' 문제를 해결하기 위한 필수적인 방어 기제입니다 [1]. 브랜디드 타입(Branded Types) 또는 불투명 타입(Opaque Types)을 활용해 구조가 동일한 기본 타입 데이터에 고유한 가상의 식별자를 부여하여 의미가 다른 데이터를 엄격하게 분리합니다 [1]. 이를 통해 오직 사전에 검증된 안전한 데이터만이 시스템의 핵심 비즈니스 로직으로 진입하도록 강제하여 데이터가 섞이거나 오염되는 것을 원천 차단합니다 [2].
-
-## 📖 구조화된 지식 (Synthesized Content)
-* **구조적 타이핑의 한계와 데이터 오염의 위험성:**
-  TypeScript의 구조적 타이핑은 매우 유연하지만, 이메일 주소와 사용자 이름이 모두 `string` 타입으로 처리되는 것처럼 의미적으로 다른 데이터를 구별하지 못하는 "기본 타입에의 집착(Primitive Obsession)" 문제를 야기합니다 [1]. 컴파일러가 이를 막지 못하기 때문에 잘못된 식별자나 데이터가 전달되는 실수가 발생할 수 있으며, 이는 시스템의 데이터 오염으로 이어집니다 [1].
-
-* **브랜디드 타입(Branded Types)을 통한 방어막 구축:**
-  데이터 오염을 막기 위해 런타임에는 존재하지 않지만 컴파일 시점에만 존재하는 고유한 속성(예: `__brand`)을 교집합 타입으로 부여하는 브랜디드 타입을 사용합니다 [1]. 이는 명목적 타이핑을 모방하는 기법으로, 외부 침입이나 잘못된 데이터 유입으로부터 성채를 보호하는 일종의 "신분증 시스템" 역할을 수행합니다 [1, 2].
-
-* **도메인 엔티티 식별자의 엄격한 분리:**
-  도메인 기반 설계(DDD)에서는 `UserId`와 `OrderId`처럼 본질적으로 구조가 같은 타입들을 브랜디드 타입으로 엄격히 분리합니다 [2]. 이렇게 하면 두 식별자 간에 데이터가 실수로 섞이는 것을 방지할 수 있으며, 악의적이거나 잘못된 입력으로부터 안전하다고 확인된 데이터(예: `SanitizedString`)만이 시스템 내부로 들어가도록 통제할 수 있습니다 [2].
-
-* **'Parse, Don't Validate' 원칙의 적용:**
-  단순히 데이터의 유효성을 체크하는 것을 넘어, "검증하지 말고 파싱하라"는 철학을 적용해야 합니다 [3]. Zod와 같은 파싱 라이브러리를 사용하여 불안정한 런타임 외부 데이터를 신뢰할 수 있는 브랜디드 타입으로 변환(파싱)한 뒤 시스템 내부로 전달함으로써 데이터 무결성을 완벽에 가깝게 보호할 수 있습니다 [3].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[브랜디드 타입 (Branded Types)]], [[기본 타입에의 집착 (Primitive Obsession)]], [[구조적 타이핑 (Structural Typing)]], [[Parse, Don't Validate]]
-- **Projects/Contexts:** [[UserId와 OrderId의 엄격한 분리 모델링]], [[Zod 라이브러리를 활용한 런타임 데이터 파싱]]
-- **Contradictions/Notes:** TypeScript 자체는 형태를 기준으로 하는 구조적 타이핑 언어이지만, 도메인 주도 설계에서 데이터 오염을 완벽히 차단하기 위해서는 오히려 명목적 타이핑(Nominal Typing)의 특성을 브랜디드 타입이라는 우회적 방법론으로 모방하여 사용해야 합니다 [1, 4].
-
----
-*Last updated: 2026-04-18*
-- Raw Source: [[00_Raw/2026-04-20/도메인 기반 설계 (DDD) 및 데이터 오염 방지.md]]
----
diff --git a/Programming & Language/도메인 기반 설계 (DDD).md b/Programming & Language/도메인 기반 설계 (DDD).md
deleted file mode 100644
index 364f8090..00000000
--- a/Programming & Language/도메인 기반 설계 (DDD).md	
+++ /dev/null
@@ -1,33 +0,0 @@
----
-id: P-REINFORCE-AUTO-F2DA4C
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - 도메인 기반 설계 (DDD)"
----
-
-# [[도메인 기반 설계 (DDD)]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 도메인 기반 설계(DDD)는 비즈니스 도메인에 맞춰 소프트웨어를 모델링하는 설계 접근법으로, TypeScript의 타입 시스템에서는 의미적으로 다른 데이터를 엄격하게 분리하여 시스템의 무결성을 보호하는 데 활용됩니다 [1]. 특히 브랜디드 타입(Branded Types)과 불변성(Immutability)을 통해 도메인 모델 내에서 데이터가 무분별하게 섞이거나 오염되는 것을 방지하여 예측 가능성을 극대화합니다 [1-3].
-
-## 📖 구조화된 지식 (Synthesized Content)
-* **브랜디드 타입(Branded Types)의 활용:** 도메인 기반 설계에서는 기본 타입(Primitive Type)에만 의존하는 문제를 해결하기 위해 브랜디드 타입을 적극 활용합니다. 예를 들어, 구조적으로 동일한 `string` 타입이더라도 `UserId`와 `OrderId`를 엄격히 분리함으로써 도메인 데이터가 서로 섞이는 것을 방지할 수 있습니다 [1, 2, 4, 5].
-* **데이터 오염 방지와 신분증 시스템:** DDD 구조에서 타입 시스템은 외부의 불안정한 데이터로부터 내부 로직을 보호하는 역할을 합니다. 검증된 데이터(예: `SanitizedString`)만이 시스템의 내부 로직으로 진입하도록 강제할 수 있으며, 이는 마치 외부 침입으로부터 성채를 보호하는 "신분증 시스템"과 같이 작동합니다 [1, 2].
-* **도메인 모델의 불변성(Immutability) 확립:** 도메인 모델이나 엔티티 클래스를 구현할 때 데이터의 무결성을 유지하는 것은 매우 중요합니다. `readonly` 수식어를 사용하여 불변적인 식별자 속성(Identity properties)과 변경 가능한 상태(Mutable state)를 명확하게 구분함으로써 데이터의 신뢰성을 보장할 수 있습니다 [3].
-* **도메인 에러(Domain Error) 처리:** 도메인 로직 내에서 예기치 않은 상태나 유효하지 않은 데이터가 발생할 경우, 도메인 예외(DomainException)를 던지고 미들웨어가 이를 전역적으로 처리하게 함으로써 비즈니스 흐름을 제어하는 복잡한 에러 체크 로직을 줄일 수 있습니다 [6, 7]. 다만, 도메인의 관심사 분리(Separation of Concerns)를 지키지 않은 섣부른 추상화는 시스템 코드를 비대하게 만들고 관리를 어렵게 할 수 있으므로 주의해야 합니다 [8].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[브랜디드 타입 (Branded Types)]], [[불변성 (Immutability)]], [[구조적 타이핑 (Structural Typing)]]
-- **Projects/Contexts:** [[TypeScript 타입 시스템을 활용한 내부 로직 보호 및 데이터 검증]]
-- **Contradictions/Notes:** 예외(Exception) 처리에 대해, 도메인 비즈니스 흐름을 단순히 제어할 목적(if-else를 대체하는 용도)으로 예외를 남용하는 것은 지양해야 하지만, 예기치 않은 상황이나 검증 실패 시 도메인 에러를 발생시키고 이를 전역 미들웨어에서 처리하도록 위임하는 방어적 프로그래밍 패턴은 적절한 수비 전략으로 권장됩니다 [6, 7].
-
----
-*Last updated: 2026-04-18*
-- Raw Source: [[00_Raw/2026-04-20/도메인 기반 설계 (DDD).md]]
----
diff --git a/Programming & Language/도메인 기반 설계(DDD).md b/Programming & Language/도메인 기반 설계(DDD).md
deleted file mode 100644
index 38c04728..00000000
--- a/Programming & Language/도메인 기반 설계(DDD).md	
+++ /dev/null
@@ -1,34 +0,0 @@
----
-id: P-REINFORCE-AUTO-9C55A9
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - 도메인 기반 설계(DDD)"
----
-
-# [[도메인 기반 설계(DDD)]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 도메인 기반 설계(DDD)에 대한 전반적인 정의는 소스에 관련 정보가 부족합니다. 제공된 자료에 따르면, 도메인 기반 설계(DDD)는 브랜디드 타입(Branded Types)과 결합하여 의미적으로 다른 데이터를 엄격히 분리하고 검증된 데이터만 시스템 내부로 진입하도록 강제하는 데 유용하게 쓰이는 설계 접근법입니다 [1].
-
-## 📖 구조화된 지식 (Synthesized Content)
-소스에 관련 정보가 부족합니다. 제공된 소스는 도메인 기반 설계(DDD)의 전체적인 개념이나 구체적인 원칙을 깊이 있게 설명하지 않으며, 오직 브랜디드 타입(Branded Types)의 활용 맥락에서만 단편적으로 다루고 있습니다. 
-
-* **의미적 데이터 분리:** 도메인 기반 설계에서는 `UserId`와 `OrderId`처럼 프로그래밍 언어 상의 기본 타입(예: 문자열)은 같을 수 있으나 도메인 맥락에서 의미적으로 다른 데이터를 엄격하게 분리하여 데이터가 실수로 섞이는 것을 방지합니다 [1].
-* **검증된 데이터 진입 강제:** 오직 검증된 데이터(예: `SanitizedString`)만이 시스템의 내부 비즈니스 로직으로 진입할 수 있도록 강제할 수 있습니다 [1].
-* **시스템 보호 역할:** 이러한 설계는 타입 시스템의 엄격함과 결합하여 외부 침입으로부터 성채를 보호하는 "신분증 시스템"과 같은 방어 역할을 수행합니다 [1].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[브랜디드 타입(Branded Types)]]
-- **Projects/Contexts:** 소스에 관련 정보가 부족합니다.
-- **Contradictions/Notes:** 소스에 관련 정보가 부족합니다.
-
----
-*Last updated: 2026-04-18*
-- Raw Source: [[00_Raw/2026-04-20/도메인 기반 설계(DDD).md]]
----
diff --git a/Programming & Language/도메인 기반 설계(DDD)의 데이터 검증.md b/Programming & Language/도메인 기반 설계(DDD)의 데이터 검증.md
deleted file mode 100644
index 8e4754bf..00000000
--- a/Programming & Language/도메인 기반 설계(DDD)의 데이터 검증.md	
+++ /dev/null
@@ -1,32 +0,0 @@
----
-id: P-REINFORCE-AUTO-DDDB06
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - 도메인 기반 설계(DDD)의 데이터 검증"
----
-
-# [[도메인 기반 설계(DDD)의 데이터 검증]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 도메인 기반 설계(DDD)에서 데이터 검증은 단순한 유효성 확인을 넘어, 신뢰할 수 있는 데이터를 도메인 객체로 변환하여 시스템 내부를 보호하는 아키텍처적 과정입니다 [1, 2]. 주로 브랜디드 타입(Branded Types)과 "검증하지 말고 파싱하라(Parse, Don't Validate)"라는 철학을 결합하여, 시스템 경계에서 불확실한 데이터를 명확하게 타입화된 구체적 객체로 변환합니다 [1-4]. 이를 통해 잘못된 데이터의 유입을 원천 차단하고 예측 가능한 비즈니스 로직을 구현합니다 [4, 5].
-
-## 📖 구조화된 지식 (Synthesized Content)
-* **브랜디드 타입(Branded Types)을 통한 도메인 데이터 보호:** TypeScript와 같은 구조적 타이핑 시스템에서는 이메일과 사용자 이름처럼 동일한 문자열(string) 기반의 데이터가 잘못 섞여 사용되는 '기본 타입에의 집착(Primitive Obsession)' 문제가 발생할 수 있습니다 [6]. 도메인 기반 설계(DDD)에서는 이를 방지하기 위해 런타임에는 존재하지 않으나 컴파일 시점에 존재하는 고유한 식별자를 부여하는 '브랜디드 타입'을 사용합니다 [6]. 이를 통해 `UserId`와 `OrderId`를 엄격히 분리하여 데이터 혼용을 방지하며, 검증된 데이터(예: `SanitizedString`)만이 시스템 내부 로직으로 진입하도록 강제하는 신분증 역할을 합니다 [4].
-* **"검증하지 말고 파싱하라(Parse, Don't Validate)" 철학:** 데이터 검증은 단순히 참/거짓 유효성을 체크하는 것에 머물러서는 안 됩니다 [2]. 시스템의 경계(Boundary)에서 타입이 불확실한 데이터를 입력받아, 단 1회의 파싱을 통해 신뢰할 수 있는 잘 정의된 타입의 객체로 변환해야 합니다 [1-3]. 파싱 과정 자체가 유효성 검증과 변환을 동시에 수행하며, 이 관문을 통과한 데이터는 이후의 비즈니스 로직에서 완전히 검증된 타입의 형태로 안전하게 다루어집니다 [1].
-* **경계면 제어 흐름 최적화 및 런타임 검증 도구의 결합:** 데이터를 경계면에서 단번에 파싱 및 검증하면, 유효성 검사 로직이 시스템 내부의 제어 흐름(Control flow) 곳곳에 지저분하게 산재하는 것을 막아줍니다 [3]. 특히 Zod와 같은 런타임 검증 라이브러리와 브랜디드 타입을 결합하면, 유효성 검사를 통과한 런타임 데이터에 브랜디드 타입을 안전하게 부여하여 이 철학을 구체적으로 실현하고 시스템의 데이터 무결성을 달성할 수 있습니다 [2, 7, 8].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[브랜디드 타입(Branded Types)]], [[Parse, Don't Validate]]
-- **Projects/Contexts:** [[Zod를 활용한 런타임 데이터 유효성 검사]], [[TypeScript 구조적 타이핑의 한계 극복]]
-- **Contradictions/Notes:** 도메인 기반 설계(DDD)의 데이터 검증 방식에 대한 상반된 주장이나 모순점에 대해서는 소스에 관련 정보가 부족합니다.
-
----
-*Last updated: 2026-04-18*
-- Raw Source: [[00_Raw/2026-04-20/도메인 기반 설계(DDD)의 데이터 검증.md]]
----
diff --git a/Programming & Language/도메인 기반 설계(DDD)의 식별자 분리.md b/Programming & Language/도메인 기반 설계(DDD)의 식별자 분리.md
deleted file mode 100644
index 7d9a6870..00000000
--- a/Programming & Language/도메인 기반 설계(DDD)의 식별자 분리.md	
+++ /dev/null
@@ -1,37 +0,0 @@
----
-id: P-REINFORCE-AUTO-5D91AB
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - 도메인 기반 설계(DDD)의 식별자 분리"
----
-
-# [[도메인 기반 설계(DDD)의 식별자 분리]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-- **'기본 타입에의 집착(Primitive Obsession)' 문제 극복**
-  TypeScript와 같은 구조적 타이핑(Structural Typing) 시스템에서는 구조가 동일할 경우 타입 호환이 허용됩니다 [1]. 이로 인해 사용자 ID(UserId)와 주문 ID(OrderId)가 모두 `string` 타입으로 표현될 경우, 서로 다른 의미의 데이터임에도 불구하고 컴파일러가 이를 구분하지 못하여 데이터가 섞이는 치명적인 실수를 방지할 수 없는 문제가 발생합니다 [1, 4]. 도메인 기반 설계에서는 이러한 '기본 타입에의 집착'을 해결하고 명확한 경계를 세우기 위해 식별자를 타입 레벨에서 분리해야 합니다 [1].
-
-- **브랜디드 타입(Branded Types)을 통한 식별자 분리 구현**
-  식별자의 구분을 위해 **브랜디드 타입**이나 **오파크 타입** 패턴을 사용하여, 기반이 되는 타입(예: 문자열이나 숫자)에 고유한 심볼(Unique Symbol)이나 가상의 브랜드 속성을 부여합니다 [1, 4]. 이를 통해 컴파일러는 런타임 구조가 동일한 원시 타입이라 하더라도, 서로 다른 브랜드를 가진 식별자를 별개의 타입으로 취급하게 됩니다 [4, 5]. 예를 들어, `UserId`와 `OrderId`를 이 패턴으로 정의하면 두 식별자를 실수로 교차하여 할당하는 것을 방지할 수 있습니다 [3]. 
-
-- **도메인 내 무결성을 보호하는 '신분증 시스템' 역할**
-  도메인 기반 설계(DDD)에서 브랜디드 타입의 활용은 특히 빛을 발합니다 [2]. `UserId`, `OrderId`, 혹은 댓글 ID와 게시글 ID(`CommentId`, `PostId`) 등 다양한 데이터 타입의 GUID(Globally Unique ID)를 엄격히 분리함으로써, 데이터베이스의 여러 데이터 유형이 실수로 뒤바뀌는 것을 막아줍니다 [2, 6, 7]. 이는 검증되고 올바른 맥락의 식별자 데이터만이 시스템의 핵심 비즈니스 로직으로 진입하도록 강제하는 **"신분증 시스템"**과 같은 수비적 역할을 수행합니다 [2].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[브랜디드 타입(Branded Types)]], [[오파크 타입(Opaque Types)]], [[기본 타입에의 집착(Primitive Obsession)]], [[구조적 타이핑(Structural Typing)]]
-- **Projects/Contexts:** [[TypeScript의 안전한 도메인 모델링]], [[데이터 오염 방지 및 무결성 보호 체계]]
-- **Contradictions/Notes:** 소스에 따르면 TypeScript의 구조적 타이핑은 매우 편리하지만 식별자처럼 고유성이 필요한 데이터를 구별하지 못하는 허점이 존재합니다. 이를 명목적 타이핑(Nominal Typing)과 유사한 효과를 내는 브랜디드 타입으로 보완해야만 도메인 식별자를 엄격히 분리할 수 있다는 점이 일관되게 강조되고 있습니다 [1, 5, 8]. 
-
----
-*Last updated: 2026-04-18*
-- Raw Source: [[00_Raw/2026-04-20/도메인 기반 설계(DDD)의 식별자 분리.md]]
----
diff --git a/Programming & Language/동기강화 상담(Motivational Interviewing).md b/Programming & Language/동기강화 상담(Motivational Interviewing).md
deleted file mode 100644
index 6d2df2d7..00000000
--- a/Programming & Language/동기강화 상담(Motivational Interviewing).md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-981A52
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - 동기강화 상담(Motivational Interviewing)"
----
-
-# [[동기강화 상담(Motivational Interviewing)]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/동기강화 상담(Motivational Interviewing).md]]
----
diff --git a/Programming & Language/동시성 및 점진적 마킹(Concurrent  Incremental Marking).md b/Programming & Language/동시성 및 점진적 마킹(Concurrent  Incremental Marking).md
deleted file mode 100644
index 92809210..00000000
--- a/Programming & Language/동시성 및 점진적 마킹(Concurrent  Incremental Marking).md	
+++ /dev/null
@@ -1,40 +0,0 @@
----
-id: P-REINFORCE-AUTO-BDF67C
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - 동시성 및 점진적 마킹(Concurrent  Incremental Marking)"
----
-
-# [[동시성 및 점진적 마킹(Concurrent  Incremental Marking)]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 동시성 및 점진적 마킹은 가비지 컬렉션(GC) 수행 시 애플리케이션의 'Stop-The-World' 일시 정지 시간을 최소화하기 위해 고안된 고도화된 메모리 관리 기법이다 [1-3]. 동시성 마킹(Concurrent Marking)은 메인 스레드가 애플리케이션 코드를 실행하는 동안 백그라운드 도우미 스레드를 활용해 객체의 도달 가능성을 추적하는 방식이다 [4, 5]. 반면 점진적 마킹(Incremental Marking)은 전체 마킹 작업을 짧은 단위(예: 5~10ms)로 쪼개어 메인 스레드의 애플리케이션 실행과 교차로 수행하는 방식이다 [6, 7].
-
-## 📖 구조화된 지식 (Synthesized Content)
-- **점진적 마킹 (Incremental Marking):** 
-  무거운 객체 그래프를 한 번에 스캔하는 대신, 작업을 매우 짧은 여러 번의 일시 정지 상태로 나누어 메인 스레드의 애플리케이션 실행과 번갈아 가며 수행한다 [3, 6, 7]. 마킹이 쪼개져 실행되는 동안 객체 그래프가 변경될 수 있으므로, 처리가 끝난 '검은색(Black)' 객체에서 아직 스캔되지 않은 '흰색(White)' 객체로 새로운 참조가 생성되는 것을 감시해야 한다 [8]. V8 엔진은 쓰기 장벽(Write Barrier)을 이용해 이를 감지하고, 해당 검은색 객체를 다시 '회색(Grey)'으로 되돌려 마킹 대기열에 밀어 넣음으로써 객체 누락을 방지한다 [8]. 이 방식은 한 번의 긴 일시 정지를 없애 반응성을 높이지만, 메인 스레드가 수행하는 전체 GC 작업 시간 자체는 약간 늘어날 수 있다 [3].
-
-- **동시성 마킹 (Concurrent Marking):** 
-  메인 스레드가 자바스크립트 등 애플리케이션 코드를 중단 없이 실행하는 동안, 도우미 스레드들이 백그라운드에서 객체를 탐색하고 마킹하는 작업을 전담한다 [5, 7]. 힙의 메모리가 특정 임계값에 도달하면 여러 스레드에 추적할 포인터들이 할당되며, 백그라운드에서 살아있는 객체들을 식별한다 [9]. 애플리케이션과 가비지 컬렉터가 동시에 객체를 읽거나 수정할 수 있기 때문에 데이터 경쟁(Read/Write race)을 방지하기 위한 동기화 오버헤드가 수반되며, 동시 작업 중 생성된 새로운 참조를 추적하기 위해 쓰기 장벽이 사용된다 [4, 5, 9].
-
-- **상태 추적 기술 (State Tracking):**
-  동시성 및 점진적 마킹 도중 애플리케이션이 힙의 객체를 수정하는 사항을 추적하기 위해 GC는 특별한 메커니즘을 쓴다. V8의 경우 쓰기 장벽(Write Barrier)이 포인터의 생성과 수정을 기록하여 변경 사항을 감지한다 [8, 9]. IBM Eclipse OpenJ9과 같은 JVM 환경에서는 힙을 512바이트 크기의 카드로 나눈 '카드 테이블(Card Table)' 구조를 사용하여 객체가 업데이트될 때마다 해당 카드를 마킹해 둔 뒤, 나중에 다시 추적할 수 있도록 관리한다 [10, 11].
-
-- **도입을 통한 성능적 이점:** 
-  이 두 기법은 모바일 기기나 대규모 데이터 처리 환경에서 500~1000ms에 달하던 극단적인 가비지 컬렉션 일시 정지를 획기적으로 줄이는 데 기여한다 [6, 12]. 특히 사용자의 입력에 응답하거나 애니메이션을 부드럽게 렌더링해야 하는 인터랙티브 환경에서 버벅거림(Jank)과 지연율을 줄이는 핵심 역할을 한다 [3, 6, 13].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[가비지 컬렉션(Garbage Collection)]], [[마크-스윕(Mark-Sweep)]], [[쓰기 장벽(Write Barrier)]], [[삼색 마킹(Tri-color Marking)]]
-- **Projects/Contexts:** [[V8 자바스크립트 엔진(V8 JavaScript Engine)]], [[Orinoco 가비지 컬렉터]], [[IBM Eclipse OpenJ9]]
-- **Contradictions/Notes:** 점진적 마킹은 개별 일시 정지 시간은 짧게 분산시키지만 메인 스레드가 마킹에 소요하는 총합 시간은 오히려 약간 증가시킬 수 있는 반면, 동시성 마킹은 메인 스레드를 온전히 해방시키는 대신 백그라운드 스레드와의 동기화 비용(Overhead)이 추가로 발생한다는 차이점이 있다 [3, 5].
-
----
-*Last updated: 2026-04-19*
-- Raw Source: [[00_Raw/2026-04-20/동시성 및 점진적 마킹(Concurrent & Incremental Marking).md]]
----
diff --git a/Programming & Language/동작 속도(Movement Speed).md b/Programming & Language/동작 속도(Movement Speed).md
deleted file mode 100644
index 7b27cc55..00000000
--- a/Programming & Language/동작 속도(Movement Speed).md	
+++ /dev/null
@@ -1,32 +0,0 @@
----
-id: P-REINFORCE-AUTO-8D64FF
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - 동작 속도(Movement Speed)"
----
-
-# [[동작 속도(Movement Speed)]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 동작 속도(Movement Speed)는 사용자가 특정 자극에 반응하여 물리적인 움직임을 수행하는 데 소요되는 시간이나 속도를 의미합니다 [1]. 반응 시간 측정 시 인지적 요인인 결정 속도와 분리되어 순수한 운동적 요소로 평가되며, 버튼에서 손을 떼어 목표물을 터치할 때까지의 시간 등으로 계산됩니다 [1]. 가상현실(VR) 엑서게임(Exergame) 플레이 전후의 단기적 신체 능력 변화를 측정하거나, 비디오 게임 내 플레이어의 이동 속도를 분석하는 지표로 활용되지만, 동작 속도의 생리학적 메커니즘 전반에 대해서는 소스에 관련 정보가 부족합니다 [2], [3].
-
-## 📖 구조화된 지식 (Synthesized Content)
-- **인지 및 운동 요소의 분리 측정:** 사용자의 속도 반응을 측정하는 CANTAB 5-선택 반응 시간(RTI) 과제에서 전체 반응 시간은 '결정 속도(Decision speed)'와 '동작 속도(Movement speed)' 두 가지 구성 요소로 나뉩니다 [1]. 이 중 동작 속도는 사용자가 출발 버튼에서 손을 뗀 순간부터 목표 자극을 터치할 때까지 소요된 시간의 중앙값(Median duration)으로 측정되어, 인지적 판단 시간과 실제 운동 시간을 명확히 분리합니다 [1].
-- **가상현실(VR) 엑서게임이 동작 속도에 미치는 영향:** VR 리듬 게임인 '비트 세이버(Beat Saber)'를 활용한 실험에 따르면, 10분간 짧게 VR 엑서게임에 노출된 직후 참가자들의 동작 속도는 노출 이전(기준선)보다 오히려 약간 더 빨라지는 것으로 나타났습니다 [2]. 이는 게임 중 요구되는 빠른 속도의 운동을 연습한 효과일 수 있으나, 일반적인 유산소 운동 후의 반응 시간 향상과 마찬가지로 신체 활동 중단 후 빠르게 사라지는 단기적인 현상이었습니다 [2]. 이러한 단기적 변화 외에 지속적인 VR 게임이 동작 속도에 미치는 장기적 효과에 대해서는 소스에 관련 정보가 부족합니다 [2].
-- **게임 내 행동 지표로서의 활용:** 1인칭 슈팅 게임(FPS) 환경(예: 팀 포트리스 2)에서 플레이어의 동작 속도(초당 이동 거리) 및 아바타 회전 강도는 심박수, 음성 데이터 등과 결합하여 팀의 성과나 스트레스 수준을 파악하기 위한 기계 학습(Machine Learning)의 주요 특성(Feature) 데이터로 추출 및 활용되기도 합니다 [3].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[반응 시간(Reaction Time)]], [[결정 속도(Decision Speed)]]
-- **Projects/Contexts:** [[CANTAB 5-choice RTI task]], [[가상현실 엑서게임(VR Exergaming)]]
-- **Contradictions/Notes:** 소스에 따르면 단기간의 VR 엑서게임 플레이 직후 동작 속도의 일시적 향상이 확인되었으나, 반복적이고 장기적인 플레이가 동작 속도에 미치는 인지적/신체적 영향에 대해서는 소스에 관련 정보가 부족합니다 [2]. 
-
----
-*Last updated: 2026-04-19*
-- Raw Source: [[00_Raw/2026-04-20/동작 속도(Movement Speed).md]]
----
diff --git a/Programming & Language/동적 애플리케이션 보안 테스트(DAST).md b/Programming & Language/동적 애플리케이션 보안 테스트(DAST).md
deleted file mode 100644
index 75681e8e..00000000
--- a/Programming & Language/동적 애플리케이션 보안 테스트(DAST).md	
+++ /dev/null
@@ -1,33 +0,0 @@
----
-id: P-REINFORCE-AUTO-93CA9B
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - 동적 애플리케이션 보안 테스트(DAST)"
----
-
-# [[동적 애플리케이션 보안 테스트(DAST)]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 동적 애플리케이션 보안 테스트(DAST)는 실행 중인 애플리케이션을 외부에서 테스트하여 취약점을 찾는 블랙박스(Black-box) 보안 테스트 기법입니다 [1, 2]. 소스 코드를 정적으로 분석하는 SAST와 달리, DAST는 런타임 동작, 구성 오류(configuration issues) 및 노출된 공격 표면을 관찰합니다 [1, 2]. 주로 스테이징이나 프로덕션과 같은 소프트웨어 개발 수명 주기(SDLC)의 후반부에 적용되어 실제 배포 환경에서의 런타임 보안을 검증하는 데 사용됩니다 [2].
-
-## 📖 구조화된 지식 (Synthesized Content)
-* **테스트 방식 및 적용 시기**: DAST는 애플리케이션이 실행되는 런타임 환경에서 수행되는 블랙박스 테스트입니다 [3]. 코드 작성 중이나 개발 초기 단계에 적용되는 SAST와 달리, DAST는 CI 파이프라인의 후반부인 스테이징, 사전 프로덕션(pre-prod) 또는 프로덕션 환경에 주로 배치되어 런타임 및 배포 시 발생할 수 있는 문제를 포착합니다 [2, 3].
-* **주요 식별 대상 및 특징**: 외부로 노출되는 애플리케이션(external-facing applications)에 적합하며, 런타임 동작이 안전한지 검증하는 데 중점을 둡니다 [2]. 또한 특정 프로그래밍 언어에 종속되지 않는다는 장점이 있으며, 소프트웨어의 회귀(regression)를 방지하는 훌륭한 수단으로 활용됩니다 [3].
-* **퍼징(Fuzzing) 기법**: DAST의 한 방법으로 '퍼징' 기술이 있습니다. 이는 애플리케이션에 의도적으로 스트레스를 가해 예상치 못한 동작, 크래시(crashes), 또는 리소스 누수를 유발함으로써 개발자가 애플리케이션의 동작과 취약점을 포괄적으로 이해할 수 있도록 돕습니다 [3].
-* **SAST와의 상호보완적 활용**: 성숙한 애플리케이션 보안 프로그램들은 포괄적인 보안 커버리지를 확보하기 위해 SAST와 DAST를 결합하여 사용합니다 [1, 2]. SAST가 개발 초기 단계에서 코드 내부 로직과 데이터 흐름 결함을 잡아낸다면, DAST는 런타임 환경에서의 실제 보안 위험을 확인하여 계층화된 방어(layered coverage)를 제공합니다 [1, 2].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[정적 애플리케이션 보안 테스트(SAST)]], [[블랙박스 테스트]], [[퍼징(Fuzzing)]]
-- **Projects/Contexts:** [[소프트웨어 개발 수명 주기(SDLC)]], [[CI/CD 파이프라인]]
-- **Contradictions/Notes:** 소스에 명시적인 모순점은 없으나, 주의할 점으로 DAST와 SAST의 명확한 역할 차이가 강조됩니다. SAST는 소스 코드를 볼 수 있는 화이트박스 테스트인 반면 DAST는 코드를 보지 않고 외부에서 공격을 시도하는 블랙박스 테스트이므로, 두 방법은 경쟁 관계가 아닌 상호보완적으로 사용해야 가장 효과적이라고 설명됩니다 [1-3].
-
----
-*Last updated: 2026-04-19*
-- Raw Source: [[00_Raw/2026-04-20/동적 애플리케이션 보안 테스트(DAST).md]]
----
diff --git a/Programming & Language/디지털 미학(Digital Aesthetics).md b/Programming & Language/디지털 미학(Digital Aesthetics).md
deleted file mode 100644
index 945d6e50..00000000
--- a/Programming & Language/디지털 미학(Digital Aesthetics).md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-276C6F
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - 디지털 미학(Digital Aesthetics)"
----
-
-# [[디지털 미학(Digital Aesthetics)]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/디지털 미학(Digital Aesthetics).md]]
----
diff --git a/Programming & Language/라이브러리 및 확장 가능한 코드베이스.md b/Programming & Language/라이브러리 및 확장 가능한 코드베이스.md
deleted file mode 100644
index aabf45cf..00000000
--- a/Programming & Language/라이브러리 및 확장 가능한 코드베이스.md	
+++ /dev/null
@@ -1,34 +0,0 @@
----
-id: P-REINFORCE-AUTO-BBBC83
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - 라이브러리 및 확장 가능한 코드베이스"
----
-
-# [[라이브러리 및 확장 가능한 코드베이스]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 라이브러리 및 확장 가능한 코드베이스는 중복되는 로직이나 공통 기능을 추상화하여 재사용 가능한 모듈과 공유 라이브러리로 구축함으로써, 시스템이 커지더라도 유연하고 유지보수 가능하게 만드는 소프트웨어 설계 방식을 의미합니다. DRY(Don't Repeat Yourself)와 관심사의 분리(SoC) 같은 소프트웨어 공학 원칙을 바탕으로 코드를 조직화하여, 기능이 추가되거나 다수의 팀이 병렬로 개발하더라도 안정적으로 시스템을 확장할 수 있는 토대를 제공합니다.
-
-## 📖 구조화된 지식 (Synthesized Content)
-- **DRY 원칙과 공유 라이브러리 활용:** 확장 가능한 코드베이스를 유지하기 위한 핵심은 정보와 논리의 중복을 피하는 DRY 원칙을 준수하는 것입니다. 데이터 검증이나 포맷팅 로직 등을 여러 곳에 복사하는 대신, 이를 중앙 집중화된 유틸리티 함수나 공유 라이브러리로 추상화해야 합니다 [1, 2]. 라우팅이나 데이터 접근 같은 공통 작업에 대해 확립된 프레임워크와 라이브러리를 활용하면 불필요한 재구현을 방지하고 코드베이스의 복잡성을 낮출 수 있습니다 [3].
-- **관심사 분리(SoC)를 통한 확장성(Scalability) 확보:** 복잡한 시스템을 단일한 목적을 가진 기능들로 나누는 SoC 원칙을 적용하면 자연스럽게 재사용 가능한 컴포넌트나 라이브러리가 도출됩니다 [4, 5]. 이렇게 격리된 모듈들은 다른 프로젝트나 코드의 다른 부분에서 재사용될 수 있으며, 시스템의 요구사항이 커지더라도 전체 시스템에 영향을 주지 않고 개별 모듈을 확장할 수 있어 확장성을 크게 향상시킵니다 [5].
-- **마이크로 프론트엔드의 컴포넌트 라이브러리:** 프론트엔드 환경에서 확장성을 달성하기 위해 마이크로 프론트엔드 아키텍처가 사용됩니다. 이때 여러 팀이 일관된 화면을 개발할 수 있도록 컴포넌트 라이브러리(Component Libraries)와 디자인 시스템을 구축합니다 [6, 7]. Bit.dev나 웹팩 모듈 페더레이션(Webpack Module Federation) 등의 도구를 통해 코드를 동적으로 공유하며 확장 가능한 프론트엔드 구조를 구성합니다 [6, 8].
-- **데이터 시스템의 모듈화된 코드베이스:** 확장 가능한 데이터 시스템을 구축할 때에도 코드의 모듈화가 필수적입니다. dbt(data build tool)와 같은 프레임워크를 활용하면 데이터 변환 로직을 모듈화하고 버전 관리할 수 있는 투명하고 유지보수 가능한 코드베이스로 만들 수 있어 시스템 확장에 유리합니다 [9].
-- **클린 아키텍처와 서드파티 라이브러리의 격리:** 확장 가능하고 수명이 긴 코드베이스를 만들기 위해서는 서드파티 라이브러리가 비즈니스 핵심 로직과 강하게 결합되는 것을 피해야 합니다. 클린 아키텍처에서는 서드파티 라이브러리, 프레임워크, 데이터베이스 드라이버 등을 가장 바깥쪽 계층(Outer Layer)에 배치하여, 핵심 비즈니스 로직이 외부 라이브러리의 변화나 교체에 영향받지 않도록 설계합니다 [10, 11].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[DRY 원칙 (Don't Repeat Yourself)]], [[관심사의 분리 (Separation of Concerns)]], [[마이크로 프론트엔드 (Micro Frontends)]], [[클린 아키텍처 (Clean Architecture)]]
-- **Projects/Contexts:** [[대규모 프론트엔드 웹 개발 프로젝트]], [[모던 데이터 아키텍처 파이프라인]], [[복잡한 확장성(Scalability)을 요구하는 엔터프라이즈 시스템]]
-- **Contradictions/Notes:** 소스에 따르면, 코드를 공유 라이브러리로 추상화하는 것은 유용하지만 너무 이른 추상화(Premature abstraction)는 불필요한 복잡성을 추가할 수 있으므로 동일한 코드가 최소 두 번 이상 복제된 후에 추상화해야 한다고 권장합니다 [3]. 또한, 마이크로 프론트엔드 아키텍처 등에서 서로 다른 모듈 간에 공유 라이브러리의 버전 불일치(Version Mismatch)가 발생하면 런타임 충돌로 이어질 수 있다는 문제점이 있습니다 [12].
-
----
-*Last updated: 2026-04-18*
-- Raw Source: [[00_Raw/2026-04-20/라이브러리 및 확장 가능한 코드베이스.md]]
----
diff --git a/Programming & Language/런타임 상태 검증(Runtime Validation).md b/Programming & Language/런타임 상태 검증(Runtime Validation).md
deleted file mode 100644
index c06eaae6..00000000
--- a/Programming & Language/런타임 상태 검증(Runtime Validation).md	
+++ /dev/null
@@ -1,33 +0,0 @@
----
-id: P-REINFORCE-AUTO-1A43C0
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - 런타임 상태 검증(Runtime Validation)"
----
-
-# [[런타임 상태 검증(Runtime Validation)]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 런타임 상태 검증(Runtime Validation)은 애플리케이션 실행 중 외부에서 유입되는 데이터가 예상된 타입과 비즈니스 규칙을 충족하는지 확인하는 기법입니다. TypeScript의 정적 타입 시스템은 컴파일 시점에만 존재하여 런타임 시 외부 데이터의 무결성을 보장할 수 없기 때문에, 이 간극을 메우기 위해 사용됩니다[1, 2]. 주로 Zod와 같은 라이브러리를 활용하여 시스템 경계에서 데이터를 파싱하고 검증함으로써 코드베이스 전반의 타입 안전성을 극대화합니다[3, 4].
-
-## 📖 구조화된 지식 (Synthesized Content)
-* **런타임 검증의 필요성:** TypeScript의 컴파일 타임 구조(예: 식별 가능한 유니온 등)는 런타임 오버헤드가 발생하지 않는다는 장점이 있지만, API나 설정 파일과 같은 외부 소스로부터 들어오는 데이터에 대해서는 타입 안전성을 보장할 수 없습니다[1, 2]. 따라서 데이터 무결성이 보안이나 비즈니스 로직에 핵심적인 경우 런타임 검증을 결합하여 런타임 에러를 방지해야 합니다[1, 5].
-* **"검증하지 말고 파싱하라(Parse, Don't Validate)" 철학:** 시스템 전반에 검증 로직을 흩뿌리는 대신, 시스템의 진입점 및 종료점(Boundary)에서 단 한 번 데이터를 파싱하여 유효성을 검사하는 설계 방식입니다[3, 6]. 이를 통해 타입이 불명확한 데이터를 완전히 타이핑된 검증된 데이터로 변환할 수 있으며, 시스템 내부 로직을 단순하고 안전하게 유지할 수 있습니다[3, 6, 7].
-* **Zod 라이브러리와의 통합:** 런타임 검증을 위해 Zod와 같은 런타임 스키마 검증 라이브러리가 자주 사용됩니다[1, 8]. 데이터가 비즈니스 규칙을 충족하는지 확인하고, Zod의 `.safeParse()` 메서드를 사용해 예외를 던지는 대신 안전하게 결과 객체를 반환받을 수 있습니다[4, 9]. 특히 `.brand()` 메서드를 활용하면 유효성 검사를 통과한 데이터에만 브랜디드 타입(Branded Types)을 부여하여 컴파일러와 런타임 모두에서 안전성을 확보할 수 있습니다[4].
-* **성능적 고려사항 (Performance Considerations):** 런타임 검증은 오버헤드가 없는 타입스크립트의 컴파일 타임 검사와 달리 런타임 실행 비용(Cost)을 수반합니다[2]. 따라서 애플리케이션 성능에 민감한 경로(performance-critical paths)에서는 남용을 피하고 신중하게 사용해야 합니다[2].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[Parse, don't validate]], [[Zod]], [[Branded Types]], [[Discriminated Unions]]
-- **Projects/Contexts:** 외부 API 응답 데이터 처리 및 파싱[1, 5], 외부 설정 파일 유효성 검사[1, 5], 외부에서 소비되는 컴포넌트 라이브러리 구축[5].
-- **Contradictions/Notes:** TypeScript의 순수 타입 검사는 런타임 오버헤드를 전혀 추가하지 않지만, 런타임 검증(Runtime Validation)은 실제 실행 비용이 발생하므로 강력한 안전성을 제공하는 대신 성능과의 트레이드오프(Trade-off)를 고려하여 적절히 배치해야 합니다[2].
-
----
-*Last updated: 2026-04-18*
-- Raw Source: [[00_Raw/2026-04-20/런타임 상태 검증(Runtime Validation).md]]
----
diff --git a/Programming & Language/루도-내러티브 부조화(Ludonarrative Dissonance).md b/Programming & Language/루도-내러티브 부조화(Ludonarrative Dissonance).md
deleted file mode 100644
index a6b18036..00000000
--- a/Programming & Language/루도-내러티브 부조화(Ludonarrative Dissonance).md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-CBF7DE
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - 루도-내러티브 부조화(Ludonarrative Dissonance)"
----
-
-# [[루도-내러티브 부조화(Ludonarrative Dissonance)]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/루도-내러티브 부조화(Ludonarrative Dissonance).md]]
----
diff --git a/Programming & Language/리로디드(Reloaded).md b/Programming & Language/리로디드(Reloaded).md
deleted file mode 100644
index 2100bab3..00000000
--- a/Programming & Language/리로디드(Reloaded).md	
+++ /dev/null
@@ -1,32 +0,0 @@
----
-id: P-REINFORCE-AUTO-CF4C61
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - 리로디드(Reloaded)"
----
-
-# [[리로디드(Reloaded)]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 리로디드(Reloaded)는 파트너와 스튜디오로부터 유입되는 미디어 파일을 처리하여 모든 기기에서 재생할 수 있도록 변환하는 넷플릭스(Netflix)의 3세대 비디오/오디오 처리 파이프라인 시스템입니다 [1]. 약 7년 동안 운영되며 안정성과 대규모 확장성을 입증했으나, 비즈니스 성장과 함께 모놀리틱 아키텍처의 한계가 명확히 드러나게 되었습니다 [1]. 결과적으로 이 크고 복잡한 레거시 시스템은 마이크로서비스 기반의 새로운 '코스모스(Cosmos)' 플랫폼으로 점진적으로 대체되고 있습니다 [2-4].
-
-## 📖 구조화된 지식 (Synthesized Content)
-* **시스템의 기원과 역할:** 리로디드는 2007년 넷플릭스 스트리밍 서비스 출시에 맞춰 가동된 1세대 시스템과 이후 확장을 거친 2세대 시스템의 뒤를 잇는 3세대 미디어 처리 시스템입니다 [1]. 도입 당시에는 제한된 컴퓨팅 클러스터를 운영하는 소규모 개발 팀이 '비디오 및 오디오 처리 파이프라인'이라는 단일 사용 사례에 집중하여 설계했습니다 [1]. 
-* **모놀리틱 아키텍처의 한계 노출:** 시간이 흐름에 따라 넷플릭스의 처리 규모가 10배 이상 커지고, 개발자 수가 3배 이상 증가했으며, 시스템의 사용 사례 또한 방대해졌습니다 [1]. 이 과정에서 리로디드가 가진 모놀리틱(Monolithic) 아키텍처는 새로운 기능의 배포 속도를 크게 저하시키는 원인이 되었습니다 [1]. 애플리케이션 코드와 인프라 코드가 뒤섞여 있어 프로덕션 문제를 해결하는 것이 모든 개발자에게 큰 부담으로 작용했으며, 과거 소규모 팀 시절에 유용했던 중앙 집중식 데이터 모델은 오히려 시스템의 취약점(liability)으로 전락하고 말았습니다 [1].
-* **코스모스(Cosmos) 플랫폼으로의 진화:** 넷플릭스는 리로디드의 한계를 극복하고 시스템의 관측성, 모듈성, 생산성을 높이기 위해 '코스모스(Cosmos)'라는 새로운 플랫폼을 구축했습니다 [2]. 리로디드와 같이 거대하고 복잡한 레거시 시스템을 한 번에 전환하는 것은 매우 위험한 도약이기 때문에, 넷플릭스는 기존 시스템을 감싸며 점진적으로 성장해 결국 완전히 대체하는 '스트랭글러 피그(strangler fig)' 패턴을 도입하여 리스크를 줄였습니다 [3]. 이를 통해 기존 리로디드에서 처리되던 대량의 작업과 부하들이 안전하게 코스모스로 이전되고 있습니다 [4].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[모놀리틱 아키텍처(Monolithic Architecture)]], [[코스모스(Cosmos)]], [[스트랭글러 피그 패턴(Strangler Fig Pattern)]]
-- **Projects/Contexts:** [[넷플릭스 미디어 클라우드 엔지니어링(Netflix Media Cloud Engineering)]]
-- **Contradictions/Notes:** 리로디드는 구축 후 약 7년 동안 매우 안정적이고 대규모 확장이 가능한(stable and massively scalable) 시스템으로 기능했지만, 조직 규모와 요구사항의 폭발적 성장에 직면하면서 유용했던 중앙 집중식 모델이 역으로 큰 한계를 드러내는 모순적인 기술 생명주기를 보여줍니다 [1].
-
----
-*Last updated: 2026-04-18*
-- Raw Source: [[00_Raw/2026-04-20/리로디드(Reloaded).md]]
----
diff --git a/Programming & Language/리터럴 타입 (Literal Types).md b/Programming & Language/리터럴 타입 (Literal Types).md
deleted file mode 100644
index 81066f7e..00000000
--- a/Programming & Language/리터럴 타입 (Literal Types).md	
+++ /dev/null
@@ -1,38 +0,0 @@
----
-id: P-REINFORCE-AUTO-B0B7AB
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - 리터럴 타입 (Literal Types)"
----
-
-# [[리터럴 타입 (Literal Types)]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 리터럴 타입(Literal Types)은 `string`이나 `number`와 같은 범용적인 원시 타입 대신, 개발자가 미리 정의한 정확하고 구체적인 값(예: 특정 문자열, 특정 숫자 등)만을 허용하는 타입입니다. 단일 값으로 구성되는 이 타입은 주로 유니온 타입(Union Types)과 결합되어 허용되는 값의 범위를 엄격하게 제한하는 데 사용됩니다. 특히 식별 가능한 유니온(Discriminated Unions) 패턴의 핵심 요소로 작용하여, 컴파일러가 타입의 범위를 안전하게 좁히고(Narrowing) 예측 가능한 코드를 작성할 수 있도록 돕습니다.
-
-## 📖 구조화된 지식 (Synthesized Content)
-* **정의와 기본 특징:** 리터럴 타입은 변수나 매개변수가 가질 수 있는 값을 사전에 정의된 정확한 상수로 제한합니다. 예를 들어, 불리언 값 `true`와 `false`는 각각 단일 값으로 이루어진 리터럴 타입이며, `const str: 'hi' = 'hi';`와 같이 특정 문자열 역시 고유한 리터럴 타입으로 취급됩니다 [1-3]. 
-
-* **유니온 타입(Union Types)과의 결합:** 리터럴 타입은 단독으로 쓰일 때는 단일 값만을 허용하지만, 유니온 타입과 결합할 때 그 강력함이 드러납니다. 예를 들어 `"loading" | "failed" | "success"`처럼 여러 리터럴 타입을 파이프(`|`)로 연결하여, 오직 정의된 목록에 속하는 값만을 안전하게 허용하도록 설계할 수 있습니다 [3-5].
-
-* **식별 가능한 유니온(Discriminated Unions)의 핵심 역할:** 리터럴 타입은 서로 다른 구조를 가진 여러 타입들을 안전하게 구분하는 데 필수적으로 사용됩니다. 여러 타입이 공유하는 공통 속성(예: `kind: "circle" | "square"`)을 리터럴 타입으로 정의하면, 이 속성이 '식별자(Discriminator)' 역할을 합니다. 런타임에서 `switch` 문 등을 통해 이 리터럴 값을 비교함으로써, TypeScript는 현재 처리 중인 객체가 정확히 어떤 타입인지 자동으로 좁혀(Narrowing) 안전한 접근을 보장합니다 [4-6].
-
-* **리터럴 타입 보존 및 확장(Widening) 방지:** TypeScript는 구체적인 리터럴 값을 더 넓은 범주의 원시 타입으로 확장(Widening)하여 추론하는 경향이 있습니다(예: 특정 문자열을 단순 `string` 타입으로 추론). 
-  * 객체를 정의할 때 이러한 확장을 막고 본래의 정밀한 리터럴 타입을 보존하기 위해 `satisfies` 연산자를 활용할 수 있습니다. 이를 통해 객체의 구조가 조건을 만족하는지 검증하면서도 속성들의 구체적인 리터럴 타입을 그대로 유지할 수 있습니다 [7-9].
-  * 또한, `as const` 단언(Assertion)을 사용하면 값을 깊은 읽기 전용(deeply readonly) 상태로 만들면서, 컴파일러가 해당 값을 원시 타입이 아닌 정확한 리터럴 값으로 좁히도록 강제할 수 있습니다 [10].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[유니온 타입 (Union Types)]], [[식별 가능한 유니온 (Discriminated Unions)]], [[타입 좁히기 (Type Narrowing)]], [[satisfies 연산자]], [[as const 단언]]
-- **Projects/Contexts:** [[네트워크 응답 상태 모델링 (loading, success, failed 상태 구분)]], [[Redux 액션 및 API 응답 처리 패턴]]
-- **Contradictions/Notes:** 리터럴 타입 자체는 단일한 값만을 허용하기에 그 자체로만 쓰이면 제한적이지만, 유니온 타입 및 `satisfies`, `as const` 와 같은 TypeScript의 고급 기능들과 결합할 때 비로소 예측 불가능한 런타임 오류를 막아주고 자동 완성(IntelliSense)을 극대화하는 컴파일 타임의 핵심 안전장치로 작동합니다.
-
----
-*Last updated: 2026-04-18*
-- Raw Source: [[00_Raw/2026-04-20/리터럴 타입 (Literal Types).md]]
----
diff --git a/Programming & Language/린터 (Linter).md b/Programming & Language/린터 (Linter).md
deleted file mode 100644
index 51f1e5b2..00000000
--- a/Programming & Language/린터 (Linter).md	
+++ /dev/null
@@ -1,37 +0,0 @@
----
-id: P-REINFORCE-AUTO-D02DB7
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - 린터 (Linter)"
----
-
-# [[린터 (Linter)]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-- **정적 코드 분석 (Static Code Analysis):** 
-  린터는 런타임 환경에서 프로그램을 실행하지 않고 코드 자체를 정적으로 분석하는 도구이다 [1]. 단순한 구문 검사를 넘어 선언되지 않은 변수, 코드 냄새(Code smells), 안티 패턴 등 잠재적인 프로그래밍 오류를 자동으로 검출한다 [1, 6].
-- **규칙 기반 검사 및 스타일 강제 (Rule-based Checks & Consistency):** 
-  린터는 사전에 정의된 코딩 표준(규칙)을 적용하여, 이 규칙이 위반될 경우 경고를 띄우거나 빌드를 실패하게 만든다 [7]. 이를 통해 들여쓰기, 변수 명명 규칙, 띄어쓰기 등 개발자 간의 코딩 스타일 차이를 줄이고, 여러 기여자가 참여하더라도 일관되고 관용적인 코드 기반을 유지할 수 있도록 강제한다 [8, 9].
-- **보안 및 오류 예방 (Security & Error Prevention):** 
-  린터는 SQL 인젝션, 크로스 사이트 스크립팅(XSS), 하드코딩된 비밀번호 등 일반적인 보안 취약점과 관련된 위험한 코드 패턴이나 사용이 권장되지 않는 라이브러리를 조기에 감지하여 보안을 강화한다 [10-12]. 또한, 문제를 런타임이나 프로덕션 이전에 파악함으로써 실제 버그로 이어질 확률을 현저히 낮춘다 [13].
-- **생산성 증대 (Developer Productivity):** 
-  IDE 플러그인이나 CI/CD 파이프라인의 사전 커밋(pre-commit) 훅 등으로 통합되어 코드를 작성하는 즉시 실시간 피드백을 제공한다 [14]. 설정에 따라 린터가 감지된 문제를 자동으로 수정해주는 '빠른 수정(Quick fix)' 기능을 제공하기도 하며, 이는 개발자가 디버깅에 쏟는 시간을 줄이고 창의적인 로직 구현에 더 집중할 수 있게 만든다 [15, 16].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[정적 분석 (Static Analysis)]], [[포매터 (Formatter)]], [[ESLint]]
-- **Projects/Contexts:** [[통합 개발 환경 (IDE)]], [[CI/CD 파이프라인]], [[코드 리뷰 (Code Review)]]
-- **Contradictions/Notes:** 린터(Linter)는 코드 품질 보장과 오류 검출에 중점을 두는 반면, 포매터(Formatter)는 코드를 깔끔하게 정렬하는 데 특화되어 있다 [17]. 그러나 린터(예: ESLint)에도 코드 포매팅 기능이 포함되어 있어 Prettier와 같은 전용 포매터와 함께 사용할 경우 스타일 규칙 충돌이 발생할 수 있으므로, 린터의 포매팅 기능을 끄고 문법 검사 기능만 사용하도록 설정(예: `eslint-config-prettier` 사용)하는 것이 권장된다 [18, 19].
-
----
-*Last updated: 2026-04-19*
-- Raw Source: [[00_Raw/2026-04-20/린터 (Linter).md]]
----
diff --git a/Programming & Language/마이너 가비지 컬렉션(Minor GC).md b/Programming & Language/마이너 가비지 컬렉션(Minor GC).md
deleted file mode 100644
index b78bd12f..00000000
--- a/Programming & Language/마이너 가비지 컬렉션(Minor GC).md	
+++ /dev/null
@@ -1,41 +0,0 @@
----
-id: P-REINFORCE-AUTO-4E47A6
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - 마이너 가비지 컬렉션(Minor GC)"
----
-
-# [[마이너 가비지 컬렉션(Minor GC)]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-**발생 조건 및 메모리 공간**
-마이너 가비지 컬렉션은 V8 엔진의 '새로운 공간(New Space)' 혹은 '젊은 세대(Young Generation)'에 객체를 할당할 때, 할당 포인터가 공간의 끝에 도달하여 여유 메모리가 고갈되면 트리거됩니다 [1, 2, 7]. 이 공간은 빠르게 가비지 컬렉션이 이루어지도록 보통 1MB에서 64MB 사이의 비교적 작은 크기로 유지됩니다 [1, 2, 8]. 
-
-**Scavenge 알고리즘 동작 방식**
-마이너 GC는 '스캐빈저(Scavenger)' 알고리즘을 통해 수행되며, V8은 새로운 공간을 정확히 반으로 나누어 'From-Space'와 'To-Space'라는 두 개의 세미 스페이스(Semi-space)로 운영합니다 [2, 5]. 
-- **식별(Marking):** GC는 루트 객체(스택, 전역 변수 등) 및 구세대에서 신세대를 참조하는 포인터들(쓰기 장벽(Write barrier)을 통해 기억 집합(Remembered set)으로 추적됨)에서 출발하여 살아있는(Live) 객체를 식별합니다 [6, 9, 10].
-- **대피 및 복사(Evacuation):** 살아남은 객체들은 From-Space에서 To-Space의 연속적인 메모리 청크로 복사되며, 이 과정을 통해 메모리 단편화(Fragmentation)가 제거됩니다 [5, 6, 11].
-- **승격(Promotion):** 두 번의 마이너 GC 사이클을 거치면서도 살아남은 객체는 수명이 긴 객체로 간주되어 구세대(Old Space)로 승격됩니다 [1, 4, 6].
-- **스왑(Swap):** 복사가 완료되면 From-Space에 남은 내용은 모두 가비지로 간주되어 완전히 비워지고, 두 스페이스의 역할이 서로 바뀝니다 [6, 9, 12]. 이후 새로운 객체 할당은 비워진 From-Space에서 재개됩니다 [9].
-
-**병렬 처리 및 최적화**
-과거의 마이너 GC는 체니 알고리즘(Cheney's algorithm)에 기반하여 동기식(Synchronous)으로 동작하며 메인 스레드를 멈추게(Stop-the-world) 했습니다 [7, 13]. 하지만 최신 V8 엔진(예: Orinoco 프로젝트)은 병렬 스캐빈저(Parallel Scavenger)를 도입하였습니다 [13, 14]. 이 방식은 메인 스레드와 여러 헬퍼 스레드에 걸쳐 작업을 분산시키며, 각 스레드가 객체를 동시에 식별, 복사, 대피시키고 포인터를 업데이트합니다 [10, 14, 15]. 이러한 병렬화를 통해 가비지 컬렉터가 메인 스레드에서 차지하는 시간을 20%~50%까지 크게 단축하여 애플리케이션의 일시 정지(Pause) 현상을 줄였습니다 [16, 17].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[새로운 공간(New Space)]], [[구세대(Old Space)]], [[세대별 가설(Generational Hypothesis)]], [[스캐빈저(Scavenger)]], [[쓰기 장벽(Write Barrier)]]
-- **Projects/Contexts:** [[V8 JavaScript Engine]], [[Orinoco Garbage Collector]]
-- **Contradictions/Notes:** 초기 V8 버전에서는 마이너 GC를 위해 단일 스레드로 동작하는 동기식 체니 알고리즘(Cheney's algorithm)을 사용했지만, 최신 버전에서는 멀티코어 환경에 맞춰 작업 훔치기(work stealing) 기법을 활용하는 병렬 스캐빈저(Parallel Scavenger)로 발전했습니다 [7, 13]. 
-
----
-*Last updated: 2026-04-19*
-- Raw Source: [[00_Raw/2026-04-20/마이너 가비지 컬렉션(Minor GC).md]]
----
diff --git a/Programming & Language/마이크로서비스 아키텍처 (MSA).md b/Programming & Language/마이크로서비스 아키텍처 (MSA).md
deleted file mode 100644
index e74a379f..00000000
--- a/Programming & Language/마이크로서비스 아키텍처 (MSA).md	
+++ /dev/null
@@ -1,53 +0,0 @@
----
-id: P-REINFORCE-AUTO-6DFA0C
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - 마이크로서비스 아키텍처 (MSA)"
----
-
-# [[마이크로서비스 아키텍처 (MSA)]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 마이크로서비스 아키텍처(MSA)는 단일 애플리케이션을 비즈니스 도메인을 중심으로 모델링된 작고 자율적이며 독립적으로 배포 가능한 서비스들의 모음으로 구성하는 소프트웨어 설계 접근 방식입니다 [1-3]. 이는 기존의 모놀리식(Monolithic) 아키텍처와 대비되며, 각 서비스는 자체 프로세스에서 실행되고 HTTP REST나 비동기 메시징 큐와 같은 가벼운 메커니즘을 통해 통신합니다 [1, 2, 4]. 이 아키텍처는 조직의 민첩성을 높이고 기술적 이질성을 수용하며 복잡한 시스템의 확장성을 향상시킵니다 [1, 4-6].
-
-## 📖 구조화된 지식 (Synthesized Content)
-**핵심 개념 및 특징 (Core Concepts & Characteristics)**
-*   **관심사의 분리 (Separation of Concerns):** MSA는 애플리케이션을 "사용자 관리"나 "결제 처리"와 같은 특정 비즈니스 기능을 처리하는 작고 세분화된 서비스로 나눔으로써, 관심사의 분리(SoC)를 매우 세밀한 수준까지 적용합니다 [4, 7, 8].
-*   **독립성과 자율성:** 각 서비스는 고유한 코드베이스, CI/CD 파이프라인, 자체 데이터 저장소를 가지며 단일 비즈니스 요구사항에 집중합니다 [4, 8]. 중앙 집중식 거버넌스에서 벗어나 서비스별로 가장 적합한 도구와 기술 스택을 선택할 수 있는 자율성을 부여합니다 [4].
-
-**마이크로서비스 아키텍처의 장점 (Advantages)**
-*   **민첩성 및 병렬 개발:** 대규모 시스템을 관리 가능한 조각으로 나누어 여러 팀이 병렬로 작업할 수 있습니다 [1]. 전체 애플리케이션을 재배포할 필요 없이 업데이트를 더 자주, 개별적으로 릴리스할 수 있습니다 [1].
-*   **기술의 이질성 (Technology Heterogeneity):** 단일 비즈니스 유닛 내에서 각기 다른 기술을 지원하므로, 개발팀은 상황에 맞는 가장 적합한 프로그래밍 언어와 폴리글랏(Polyglot) 영속성 환경을 도입할 수 있습니다 [4, 6].
-*   **회복성 (Resilience & Fault Isolation):** 결함 격리 수준이 높아 한 서비스 단위에 장애가 발생하더라도 시스템 전체 비즈니스에 미치는 영향을 최소화할 수 있습니다 [6].
-
-**단점 및 과제 (Disadvantages & Challenges)**
-*   **분산 시스템의 복잡성:** 네트워크를 통한 통신 메커니즘 구현, 부분적 장애(Partial failure) 처리, 여러 서비스에 걸쳐 일어나는 요청의 추적 및 상호 작용 테스트가 훨씬 어렵습니다 [9-11].
-*   **비용 및 리소스 소모 증가:** 수많은 서비스를 배포하고 관리하는 데 있어 DevOps 및 오케스트레이션 도구에 대한 높은 리소스 요구사항이 발생합니다 [11, 12]. 또한, 각 서비스 인스턴스가 독립된 JVM 런타임이나 개별 가상 머신(VM)에서 실행되어야 하므로 메모리 소비와 인프라 유지 비용이 크게 증가합니다 [9, 13].
-
-**서비스 구성 패턴 (Composition Patterns)**
-*   **Aggregator Pattern:** 여러 다른 서비스를 차례대로 호출하여 결과를 수집합니다 [14].
-*   **Proxy Pattern:** 개별 서비스를 호출할 때 프록시 계층을 두어 보안이나 라우팅을 제공합니다 [14].
-*   **Branch Pattern:** 한 서비스가 동시에 두 개 이상의 다른 서비스와 통신합니다 [14].
-*   **Chained Pattern:** 서비스들을 사슬처럼 연결하여 한 서비스의 출력이 다음 서비스의 입력이 되도록 합니다 [14].
-*   **Shared Resource Pattern:** 클라이언트나 로드 밸런서가 필요에 따라 각 서비스와 직접 통신합니다 [15].
-
-**넷플릭스(Netflix)의 전환 사례**
-*   넷플릭스는 7년에 걸쳐 기존의 모놀리식 RDBMS 아키텍처를 마이크로서비스로 전환했습니다 [16, 17].
-*   주요 우선순위는 효율성, 혁신, 그리고 99.999%에 달하는 고가용성(안정성) 확보였습니다 [3, 18].
-*   무상태(Stateless) 서비스 원칙, 수직적 확장(Scale up) 대신 수평적 확장(Scale out) 선택, 다중 리전(Multi-Regional) 복제, 그리고 'Chaos Monkey'를 통한 자동화된 파괴 테스트 등을 적용하여 시스템 회복성을 갖추었습니다 [17, 19].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[관심사의 분리 (Separation of Concerns)]], [[모놀리식 아키텍처 (Monolithic Architecture)]], [[단일 책임 원칙 (SRP)]], [[클린 아키텍처 (Clean Architecture)]]
-- **Projects/Contexts:** [[넷플릭스 (Netflix) 마이크로서비스 도입 사례]], [[Cosmos 플랫폼 (Netflix)]]
-- **Contradictions/Notes:** 소스에 따르면 MSA는 배포 독립성, 빠른 릴리스, 확장성이라는 분명한 장점을 지니지만 [1, 3, 12], 분산 시스템으로 인한 복잡성(네트워크 지연, 부분적 실패, 테스트의 어려움) 및 많은 수의 가상 머신(VM)/JVM 런타임 운영에 따른 메모리 오버헤드와 비용 폭증이라는 상충 관계(Trade-off)를 명확히 가집니다 [9-11, 13]. 따라서 단순한 소규모 프로젝트보다는 빠르고 복잡하게 확장하는 대규모 시스템에 적합한 아키텍처입니다 [12].
-
----
-*Last updated: 2026-04-18*
-- Raw Source: [[00_Raw/2026-04-20/마이크로서비스 아키텍처 (MSA).md]]
----
diff --git a/Programming & Language/마이크로서비스 아키텍처.md b/Programming & Language/마이크로서비스 아키텍처.md
deleted file mode 100644
index 5f4639c3..00000000
--- a/Programming & Language/마이크로서비스 아키텍처.md	
+++ /dev/null
@@ -1,44 +0,0 @@
----
-id: P-REINFORCE-AUTO-6067F4
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - 마이크로서비스 아키텍처"
----
-
-# [[마이크로서비스 아키텍처]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-**주요 개념 및 특징**
-*   **서비스 분해와 자율성:** 비즈니스 역량(Business Capability)을 기준으로 시스템을 세분화하며, 각 서비스는 고유한 코드베이스와 독립적인 데이터 저장소를 가질 수 있습니다 [1], [4]. 이를 통해 각기 다른 서비스에 가장 적합한 기술 스택을 도입할 수 있는 기술적 이질성(Technology Heterogeneity)을 폭넓게 지원합니다 [4], [5].
-*   **독립적 배포와 유연성:** 전체 애플리케이션 시스템을 재배포할 필요 없이, 개별 서비스 단위로 업데이트와 배포를 독립적으로 진행할 수 있습니다 [1], [4]. 이는 개발 주기를 단축시키고 팀 간의 병렬 작업을 수월하게 만듭니다 [1].
-*   **클라우드 네이티브 및 자동화 도입:** 성공적인 마이크로서비스 아키텍처 구현을 위해서는 도커(Docker)와 같은 컨테이너 기술 및 쿠버네티스(Kubernetes) 같은 오케스트레이션 플랫폼과 결합하여 배포, 확장, 관리를 자동화하는 것이 중요합니다 [6], [7], [8].
-
-**주요 장점**
-*   **장애 격리(Fault Isolation) 및 복원력:** 하나의 마이크로서비스에 장애가 발생하더라도 전체 비즈니스 시스템의 붕괴로 이어지지 않도록 장애의 영향 반경(Blast radius)을 격리할 수 있습니다 [5], [9]. 분산 환경에서는 네트워크 실패가 불가피하므로 회로 차단기(Circuit breaker)나 재시도(Retries), 폴백(Fallbacks) 패턴을 구현하여 복원력을 향상시킵니다 [6].
-*   **유연한 확장성:** 시스템 전체를 확장할 필요 없이, 특정 기능이나 트래픽이 집중되는 서비스만을 선별적으로 수평 확장할 수 있어 자원 관리가 매우 효율적입니다 [10], [11], [12].
-
-**단점 및 운영 과제**
-*   **분산 시스템의 복잡성:** 서비스 간 통신 구조를 직접 구현해야 하며, 부분적 장애 처리나 여러 서비스에 걸친 트랜잭션 관리와 같은 분산 시스템 특유의 복잡성을 다뤄야 합니다 [13], [14].
-*   **비용 및 리소스 오버헤드 증가:** 각 서비스마다 자체적인 런타임 환경(JVM, VM 등)을 실행하고 분산된 데이터베이스를 관리해야 하므로 메모리 등 인프라 리소스 소비와 비용이 크게 증가합니다 [13], [15]. 수많은 서비스를 안정적으로 모니터링하고 배포하기 위해서는 높은 수준의 운영 인력과 기술력이 요구됩니다 [13], [15].
-
-**마이크로서비스 컴포지션 패턴(Composition Patterns)**
-*   단일 요청 처리를 위해 개별 서비스들을 조합하고 호출하는 구조적 패턴이 존재합니다 [16], [17]. 대표적으로 순차적으로 서비스를 호출하는 체인(Chained) 패턴, 다수의 서비스를 묶어 호출하는 어그리게이터(Aggregator) 패턴, 브랜치(Branch) 패턴, 프록시(Proxy) 패턴, 공유 리소스(Shared Resource) 패턴 등이 활용됩니다 [16], [17].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[모놀리식 아키텍처]], [[서비스 지향 아키텍처(SOA)]], [[도메인 주도 설계(DDD)]], [[컨테이너 및 클라우드 네이티브 아키텍처]]
-- **Projects/Contexts:** [[넷플릭스(Netflix) 마이크로서비스 도입 사례]], [[넷플릭스 코스모스(Cosmos) 플랫폼]], [[스포티파이(Spotify)의 컨테이너화된 마이크로서비스]]
-- **Contradictions/Notes:** 소스에 명시적인 모순은 없으나, 마이크로서비스 아키텍처는 극대화된 유지보수성과 유연성을 가져다주는 반면, 개발 초기의 분산 시스템 복잡성 및 배포 운영 난이도가 급격히 상승한다는 명확한 '트레이드오프(Trade-off)'를 갖는다고 강조합니다. 따라서 규모가 작고 단순한 환경에서는 모놀리식 구조에 비해 과도한 설계(Over-engineering)가 될 수 있습니다.
-
----
-*Last updated: 2026-04-18*
-- Raw Source: [[00_Raw/2026-04-20/마이크로서비스 아키텍처.md]]
----
diff --git a/Programming & Language/마크-스위프(Mark-Sweep).md b/Programming & Language/마크-스위프(Mark-Sweep).md
deleted file mode 100644
index edd8945f..00000000
--- a/Programming & Language/마크-스위프(Mark-Sweep).md	
+++ /dev/null
@@ -1,30 +0,0 @@
----
-id: P-REINFORCE-AUTO-C80E5C
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - 마크-스위프(Mark-Sweep)"
----
-
-# [[마크-스위프(Mark-Sweep)]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 마크-스위프(Mark-Sweep)는 가비지 컬렉터(GC)가 더 이상 사용되지 않는 메모리 영역을 식별하고 회수하여 재사용할 수 있도록 하는 가비지 컬렉션 알고리즘입니다 [1]. 루트(Root) 객체부터 도달 가능한 라이브(Live) 객체를 식별하여 표시하는 '마킹(Mark)' 단계와, 마킹되지 않은 데드(Dead) 객체를 메모리에서 지워 빈 공간(Free space)으로 전환하는 '스위핑(Sweep)' 단계로 구성됩니다 [2, 3]. 주로 자바스크립트 V8 엔진이나 IBM 가비지 컬렉터에서 비교적 오래 살아남은 객체가 모인 구 세대(Old Generation/Space)의 메모리를 정리하는 데 사용됩니다 [4, 5].
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[가비지 컬렉션(Garbage Collection)]], [[마크-컴팩트(Mark-Compact)]], [[Old Space (구 세대 공간)]], [[점진적 마킹(Incremental marking)]]
-- **Projects/Contexts:** [[V8 자바스크립트 엔진]], [[Orinoco 프로젝트]], [[IBM 가비지 컬렉션]]
-- **Contradictions/Notes:** 마크-컴팩트는 단편화를 제거해주지만, 모든 생존 객체를 복사하고 메모리 포인터를 업데이트해야 하므로 비용이 매우 비쌉니다. 따라서 V8 엔진은 모든 페이지를 컴팩트하지 않고, 일부는 스위핑(Sweep)만 수행하며 필요한 파편화 페이지에 한해서만 압축(Compact)을 진행하는 전략을 취합니다 [17, 24].
-
----
-*Last updated: 2026-04-19*
-- Raw Source: [[00_Raw/2026-04-20/마크-스위프(Mark-Sweep).md]]
----
diff --git a/Programming & Language/마크-스윕(Mark-Sweep).md b/Programming & Language/마크-스윕(Mark-Sweep).md
deleted file mode 100644
index 38c5a4e0..00000000
--- a/Programming & Language/마크-스윕(Mark-Sweep).md	
+++ /dev/null
@@ -1,36 +0,0 @@
----
-id: P-REINFORCE-AUTO-A62B31
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - 마크-스윕(Mark-Sweep)"
----
-
-# [[마크-스윕(Mark-Sweep)]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 마크-스윕(Mark-Sweep)은 V8 엔진 및 자바 가상 머신(JVM) 등에서 더 이상 필요하지 않은 객체의 메모리를 회수하기 위해 사용하는 주요 가비지 컬렉션(Major GC) 알고리즘입니다 [1-3]. 이 알고리즘은 힙을 순회하며 활성 상태인 객체를 식별하는 '마크(Mark)' 단계와, 표시되지 않은 객체를 제거하여 메모리를 확보하는 '스윕(Sweep)' 단계로 나뉘어 동작합니다 [2, 4, 5]. 주로 수십에서 수백 메가바이트의 데이터를 포함할 수 있는 대용량 메모리 영역인 구공간(Old Space)을 관리하는 데 필수적으로 사용됩니다 [4, 6].
-
-## 📖 구조화된 지식 (Synthesized Content)
-**알고리즘의 주요 동작 단계**
-* **마크(Mark) 단계:** 가비지 컬렉터가 스택 포인터와 같은 GC 루트(Root)에서 시작하여 포인터로 연결된 객체 그래프를 깊이 우선 탐색(DFS) 방식으로 재귀적으로 순회합니다 [6, 7]. 이 과정을 통해 도달 가능한(Reachable) 객체, 즉 현재 사용 중인 객체는 활성 상태로 식별되어 마크됩니다 [2, 5, 6, 8]. V8의 마크 단계는 객체의 상태를 미발견 상태인 '백색(White)', 발견되었으나 이웃 객체가 아직 처리되지 않은 '회색(Grey)', 그리고 이웃까지 완전히 처리된 '흑색(Black)'으로 분류하는 삼색(Tri-color) 마킹 시스템을 사용합니다 [6, 9].
-* **스윕(Sweep) 단계:** 마크 단계가 완료된 후, 가비지 컬렉터는 힙의 마킹 비트맵을 스캔하여 활성 상태로 흑색 표시가 되지 않은(즉, 백색으로 남은) 객체들의 연속된 범위를 찾습니다 [5, 6, 10, 11]. 이렇게 발견된 사용 불가능한 객체들의 메모리 주소는 여유 공간(Free space)으로 변환되어 빈 목록(Free list)에 추가되며, 이후 새로운 객체를 할당할 때 재사용됩니다 [6, 10, 11].
-
-**V8 엔진에서의 활용 및 성능 최적화**
-* **구공간(Old Space) 관리:** 신공간(New Space)을 관리하는 스캐빈지(Scavenge) 알고리즘은 소규모 메모리 수집에는 빠르지만 전체 메모리의 두 배 공간을 필요로 하는 오버헤드가 있어 대용량 힙에는 부적합합니다 [4, 6]. 따라서 V8은 수명이 긴 객체들이 모여 있는 구공간을 수집할 때 마크-스윕 또는 객체를 한곳으로 모으는 과정이 추가된 마크-컴팩트(Mark-Compact) 알고리즘을 사용합니다 [4, 6, 12].
-* **동시성 및 점진적 처리 기법:** 전통적인 마크-스윕 방식은 실행 중인 애플리케이션의 메인 스레드를 장시간 멈추게 하는(Stop-the-world) 문제가 있습니다 [13, 14]. V8은 이러한 지연 현상을 줄이기 위해 마킹 작업을 여러 번의 짧은 멈춤으로 나누어 수행하는 점진적 마킹(Incremental marking), 백그라운드 헬퍼 스레드를 활용하여 메인 스레드에 영향을 주지 않는 동시적(Concurrent) 마킹 및 스윕, 그리고 필요할 때까지 메모리 해제를 미루는 지연 스윕(Lazy sweeping) 기법을 도입해 성능을 최적화했습니다 [13-16].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[가비지 컬렉션(Garbage Collection)]], [[구공간(Old Space)]], [[마크-컴팩트(Mark-Compact)]], [[점진적 마킹(Incremental Marking)]], [[스캐빈지(Scavenge)]]
-- **Projects/Contexts:** [[V8 엔진(V8 Engine)]], [[오리노코(Orinoco)]], [[자바 가상 머신(JVM)]]
-- **Contradictions/Notes:** 소스의 설명에 따르면, 스캐빈지(Scavenge) 알고리즘은 투-스페이스(to-space)와 프롬-스페이스(from-space)를 사용하는 물리적 메모리 오버헤드가 크기 때문에 신공간(New Space)에서만 유용하게 쓰이며, 반면 마크-스윕은 메모리 오버헤드는 적지만 실행 시간이 오래 걸릴 수 있어 구공간(Old Space) 관리에 사용된다는 명확한 역할 분담이 존재합니다 [4, 6].
-
----
-*Last updated: 2026-04-19*
-- Raw Source: [[00_Raw/2026-04-20/마크-스윕(Mark-Sweep).md]]
----
diff --git a/Programming & Language/마크-컴팩트(Mark-Compact).md b/Programming & Language/마크-컴팩트(Mark-Compact).md
deleted file mode 100644
index f2126713..00000000
--- a/Programming & Language/마크-컴팩트(Mark-Compact).md	
+++ /dev/null
@@ -1,40 +0,0 @@
----
-id: P-REINFORCE-AUTO-5617F2
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - 마크-컴팩트(Mark-Compact)"
----
-
-# [[마크-컴팩트(Mark-Compact)]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-*   **작동 원리 (마킹 및 컴팩팅 단계):** 
-    마크-컴팩트 알고리즘은 마크-스윕(Mark-Sweep)과 매우 밀접하게 관련되어 있으며, **마킹(Marking)과 컴팩팅(Compacting)이라는 두 가지 주요 단계**로 작동합니다 [2]. 마킹 단계에서는 루트(root)로부터 도달할 수 있는 힙 내의 모든 라이브 객체를 깊이 우선 탐색(DFS) 방식으로 추적하며 발견된 객체들을 회색(grey)이나 흑색(black) 상태로 마킹합니다 [3, 8-10]. 마킹 알고리즘이 종료되면 모든 라이브 객체는 흑색으로, 죽은(dead) 객체는 백색(white)으로 남게 되며 이 정보가 컴팩팅 단계에서 활용됩니다 [11].
-
-*   **컴팩팅 프로세스 (단편화 해소):** 
-    컴팩팅 단계는 힙 메모리가 심하게 단편화되어 있을 때 실행되며, 수많은 작은 빈 공간을 포함하고 있는 **단편화된 페이지의 객체들을 다른 페이지의 빈 공간(Free list)으로 이주시킴으로써 실제 메모리 사용량을 줄이려 시도**합니다 [4-6]. 각 라이브 객체는 새로 할당된 공간으로 복사되며, 원래 객체의 첫 번째 단어에는 새로운 위치를 가리키는 포워딩 주소(forwarding address)가 남겨집니다 [4]. 만약 기존 페이지가 모두 비워지면(evacuated) 운영 체제(OS)에 다시 반환될 수 있으며, 필요에 따라 새로운 페이지가 할당되기도 합니다 [4, 6].
-
-*   **포인터 업데이트와 성능 비용:** 
-    객체가 메모리 내에서 이동함에 따라, 해당 객체들을 가리키고 있던 다른 객체들의 모든 참조(reference) 또한 새로운 주소로 변경되어야 합니다 [4, 7]. V8 엔진의 경우, 대피(evacuation)가 진행되는 동안 포인터의 위치들이 기록되며, 대피가 완료된 후 리스트를 순회하며 **복사된 새로운 위치를 가리키도록 포인터를 업데이트**합니다 [4]. 이러한 대규모 이동 및 참조 수정 작업으로 인해 힙을 컴팩팅하는 과정은 **비용이 매우 많이 드는 오퍼레이션(expensive operation)**으로 간주됩니다 [7]. 만약 특정 페이지를 가리키는 외부 포인터가 너무 많은 '인기 있는(popular)' 페이지라면, 기록을 중단하고 다음 GC 사이클 때까지 대피를 연기하기도 합니다 [4].
-
-*   **트리거(Trigger) 조건:** 
-    수백 메가바이트의 데이터를 포함할 수 있는 Old Space를 수집하기 위해 실행되지만 [2, 3], 항상 수행되는 것은 아닙니다. 예를 들어 IBM GC 정책의 경우, 기본적으로 컴팩트 작업을 피하지만 `-Xcompactgc` 커맨드 라인 옵션을 강제 지정했을 때, 스윕(sweep) 후에도 할당 요청을 충족할 여유 공간이 부족할 때, 명시적 `System.gc()` 호출 시 특정 조건을 만족할 때 등의 상황에서 발생합니다 [7, 12].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[가비지 컬렉션(Garbage Collection)]], [[마크-스윕(Mark-Sweep)]], [[단편화(Fragmentation)]]
-- **Projects/Contexts:** [[V8 JavaScript Engine]], [[IBM SDK/Eclipse OpenJ9]]
-- **Contradictions/Notes:** 소스 상에서 마크-컴팩트 알고리즘의 개념에 대한 모순은 없습니다. 다만 V8(자바스크립트)에서는 주로 'Old Space'를 정리하기 위해 설계된 메이저 가비지 컬렉션의 핵심 메커니즘으로 소개되며 [1, 2], IBM OpenJ9(자바) 환경에서는 고비용 오퍼레이션이라는 이유로 기본적으로는 발생하지 않되, 공간 고갈이나 명시적 옵션 적용 시 발생하는 조건부 동작으로 자세히 묘사됩니다 [7, 12].
-
----
-*Last updated: 2026-04-19*
-- Raw Source: [[00_Raw/2026-04-20/마크-컴팩트(Mark-Compact).md]]
----
diff --git a/Programming & Language/머리 장착형 디스플레이(HMD) 환경의 시각적 후유증 연구.md b/Programming & Language/머리 장착형 디스플레이(HMD) 환경의 시각적 후유증 연구.md
deleted file mode 100644
index 210b8c13..00000000
--- a/Programming & Language/머리 장착형 디스플레이(HMD) 환경의 시각적 후유증 연구.md	
+++ /dev/null
@@ -1,32 +0,0 @@
----
-id: P-REINFORCE-AUTO-439852
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - 머리 장착형 디스플레이(HMD) 환경의 시각적 후유증 연구"
----
-
-# [[머리 장착형 디스플레이(HMD) 환경의 시각적 후유증 연구]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 머리 장착형 디스플레이(HMD)를 사용하는 가상현실(VR) 환경은 사용자에게 메스꺼움이나 방향 감각 상실뿐만 아니라 깊이 인지와 관련된 시각적 후유증을 유발할 수 있습니다 [1, 2]. 특히 HMD 환경에서는 가까운 물체에 명확한 초점을 맞추는 데 필수적인 안구 운동인 폭주(convergence)와 조절(accommodation) 간의 충돌이 발생하여 시각적 불편함이 초래됩니다 [3, 4]. 관련 연구에 따르면 HMD 사용 직후 이러한 조절 및 폭주의 유의미한 변화가 나타나지만, 이는 VR 노출 시간(10분 및 50분)과는 무관하며 기기 사용 종료 후 40분이 지나면 기준치로 회복되는 비교적 단기적인 현상으로 확인되었습니다 [4-6].
-
-## 📖 구조화된 지식 (Synthesized Content)
-- **시각적 후유증의 원인과 증상:** HMD를 사용할 때 발생하는 시각적 후유증은 주로 폭주(vergence)와 조절(accommodation) 기능의 분리(decoupling) 및 충돌에서 기인합니다 [3, 4]. 정상적인 시각 환경에서는 두 기능이 피드백 루프를 통해 함께 작용하여 가까운 물체에 정확한 초점을 맞추도록 돕지만, HMD에서는 이 둘이 분리되어 깊이 지각에 필요한 망막 단서에 불확실성을 초래합니다 [4]. 이로 인해 두통, 눈의 통증, 피로, 복시 등의 안구 운동 관련 증상이 나타날 수 있으며, 이러한 증상은 깊이 인지 및 인지 능력에까지 영향을 미칠 수 있습니다 [2-4].
-- **폭주 및 조절의 변화와 회복:** 10분 및 50분 동안의 VR 게임(Beat Saber) 노출을 비교한 연구에 따르면, HMD 사용 직후 사용자의 조절 및 폭주 기능에서 유의미한 변화(baseline 대비)가 관찰되었습니다 [4-7]. 그러나 이러한 시각적 변화는 VR 노출 기간(시간)에 영향을 받지 않았으며, 사용자가 VR 환경에서 벗어나 40분이 경과한 지연 측정(late measurement) 시점에서는 두 안구 측정치 모두 사용 전의 기준 수준으로 회복되었습니다 [4-6]. 이는 HMD로 인한 시각적 후유증(조절 및 폭주의 변화)이 비교적 짧은 시간 안에 사라지는 일시적인 현상임을 시사합니다 [4].
-- **현실 세계 깊이 지각에 미치는 잠재적 영향:** 망막의 흐림(blur)과 양안 시차(disparity)는 폭주와 조절을 도와 물체를 명확하게 고정하는 핵심 단서입니다 [4]. 하지만 HMD 환경이 유발하는 폭주-조절 충돌은 시각적 성능을 저하시키고 시각적 피로도를 가중시킵니다 [3]. 연구 참가자들은 임상적인 시각 장애를 보고하지는 않았지만, 노출 직후와 지연된 테스트 기간 모두에서 큰 안구 운동 변화를 보인 경우가 있었으며, 이처럼 큰 안구 운동의 변화는 현실 세계에서 사용자의 깊이 지각에도 영향을 미칠 위험이 존재합니다 [4].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[폭주-조절 충돌(Vergence-Accommodation Conflict)]], [[VR 멀미(VR Sickness)]], [[깊이 지각(Depth Perception)]]
-- **Projects/Contexts:** [[Beat Saber를 활용한 VR 엑서게임의 시각적 및 인지적 후유증 조사 연구]]
-- **Contradictions/Notes:** 소스에 따르면 HMD 사용 직후 사용자의 조절과 폭주 등 안구 운동 기능에 큰 변화가 발생하여 피로와 복시 등을 유발할 수 있지만, 이러한 시각적 후유증의 크기는 VR 노출 시간(10분 노출과 50분 노출)에 영향을 받지 않았으며 기기 사용 종료 후 40분 이내에 사용 전 상태로 회복되는 것으로 나타났습니다 [4-6].
-
----
-*Last updated: 2026-04-19*
-- Raw Source: [[00_Raw/2026-04-20/머리 장착형 디스플레이(HMD) 환경의 시각적 후유증 연구.md]]
----
diff --git a/Programming & Language/머리 착용 디스플레이(HMD) 시각 연구.md b/Programming & Language/머리 착용 디스플레이(HMD) 시각 연구.md
deleted file mode 100644
index 806dac25..00000000
--- a/Programming & Language/머리 착용 디스플레이(HMD) 시각 연구.md	
+++ /dev/null
@@ -1,34 +0,0 @@
----
-id: P-REINFORCE-AUTO-C33D02
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - 머리 착용 디스플레이(HMD) 시각 연구"
----
-
-# [[머리 착용 디스플레이(HMD) 시각 연구]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-- **가상현실(VR) 멀미 및 시각 증상:** HMD 사용자는 종종 메스꺼움, 방향 감각 상실, 시각적 장애와 같은 VR 멀미 증상을 경험하며, 이는 사용자의 인지 능력과 깊이 지각에 악영향을 미칠 수 있습니다 [1]. 
-- **수렴-조절 불일치(Vergence-Accommodation Conflict):** 자연스러운 시각 환경에서는 수렴(Vergence)과 조절(Accommodation) 기능이 피드백 루프 안에서 함께 작용하여 정확한 깊이 지각을 돕습니다 [2, 3]. 그러나 HMD 환경에서는 이 두 가지 핵심 안구 운동 기능이 분리(decoupled)되어 깊이 지각을 위한 망막 단서에 불확실성이 발생합니다 [3].
-- **동반되는 시각적 부작용:** 수렴과 조절 기능의 분리 현상은 두통, 눈의 통증, 시각적 피로, 복시(Double vision)와 같은 여러 동반 증상을 유발할 가능성이 높습니다 [3].
-- **시각 척도 측정 방법론:** HMD 사용이 시각에 미치는 영향을 평가하기 위해 연구자들은 영국 공군(RAF) 근점 자(near-point rule)와 같은 도구를 사용하여 HMD 노출 전후의 근접 수렴점(Near point of convergence)과 근접 조절점(Near point of accommodation)의 변화를 밀리미터 단위로 측정합니다 [4].
-- **단기적 시각 후유증 및 노출 시간의 영향:** '비트 세이버(Beat Saber)'를 활용한 실험에서 HMD 노출 직후 조절 및 수렴의 유의미한 변화가 관찰되었으나, 이는 40분 휴식 후 기준치(Baseline) 수준으로 회복되었습니다 [3, 5, 6]. 흥미롭게도 10분 노출과 50분 노출 간에 시각적 변화의 차이가 없었으며, 이는 눈에 띄는 안구 운동의 변화가 HMD 사용 첫 10분 이내에 이미 발생함을 시사합니다 [3].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[수렴-조절 불일치(Vergence-Accommodation Conflict)]], [[VR 멀미(VR Sickness)]], [[깊이 지각(Depth Perception)]], [[안구 운동 기능(Oculomotor Functions)]]
-- **Projects/Contexts:** [[비트 세이버(Beat Saber) VR 엑서게임 연구]]
-- **Contradictions/Notes:** 소스에 따르면 HMD 사용 시간에 비례하여 시각적 후유증이 계속 증가할 것이라는 직관적 예상과 달리, 노출 시간(10분 vs 50분)은 조절 및 수렴 척도 변화 크기에 유의미한 영향을 미치지 않았으며 변화는 초기 10분 내에 이루어짐을 보여줍니다 [3].
-
----
-*Last updated: 2026-04-19*
-- Raw Source: [[00_Raw/2026-04-20/머리 착용 디스플레이(HMD) 시각 연구.md]]
----
diff --git a/Programming & Language/메모리 누수(Memory Leak).md b/Programming & Language/메모리 누수(Memory Leak).md
deleted file mode 100644
index 3f5f4c92..00000000
--- a/Programming & Language/메모리 누수(Memory Leak).md	
+++ /dev/null
@@ -1,30 +0,0 @@
----
-id: P-REINFORCE-AUTO-80BFE5
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - 메모리 누수(Memory Leak)"
----
-
-# [[메모리 누수(Memory Leak)]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 메모리 누수(Memory Leak)는 더 이상 필요하지 않은 객체가 가비지 컬렉션(GC) 루트(예: 전역 객체, 클로저, 이벤트 리스너 등)로부터 지속적으로 참조되어 시스템이 메모리를 회수할 수 없는 상태를 의미합니다 [1-3]. 애플리케이션이 장시간 실행되면서 가용 메모리가 점진적으로 고갈되며 성능 저하, 긴 GC 일시 정지(Pause), 그리고 결국 OOM(Out of Memory) 충돌을 일으키게 됩니다 [2, 4, 5]. V8과 같은 엔진은 자동으로 메모리를 관리하지만, 개발자가 의도치 않게 남겨둔 참조로 인해 메모리 누수가 발생하므로 힙 스냅샷이나 할당 타임라인(Allocation Timeline) 등의 프로파일링 도구를 통해 세밀하게 추적해야 합니다 [1, 3, 6, 7].
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[가비지 컬렉션(Garbage Collection)]], [[할당 타임라인(Allocation Timeline)]], [[힙 스냅샷(Heap Snapshot)]], [[Old Space]]
-- **Projects/Contexts:** [[Chrome DevTools 메모리 분석 및 성능 최적화]], [[V8 엔진 힙 아키텍처 및 로그 분석]]
-- **Contradictions/Notes:** `WeakRef` 및 `FinalizationRegistry`는 누수 방지를 위한 모던 도구이지만, GC의 실행 시점이 비결정적이므로 적절한 생명주기 관리를 완전히 대체할 수는 없습니다 [11]. 또한, 크기가 계속 커지는 모든 메모리 그래프가 누수인 것은 아니며, 캐시나 가상화된 리스트 버퍼 등 의도적인 데이터 보존(Intentional retention)과 구별해야 합니다 [26].
-
----
-*Last updated: 2026-04-19*
-- Raw Source: [[00_Raw/2026-04-20/메모리 누수(Memory Leak).md]]
----
diff --git a/Programming & Language/메모리 누수(Memory Leaks).md b/Programming & Language/메모리 누수(Memory Leaks).md
deleted file mode 100644
index 886234be..00000000
--- a/Programming & Language/메모리 누수(Memory Leaks).md	
+++ /dev/null
@@ -1,41 +0,0 @@
----
-id: P-REINFORCE-AUTO-2F9E62
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - 메모리 누수(Memory Leaks)"
----
-
-# [[메모리 누수(Memory Leaks)]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 가비지 컬렉션 환경에서의 메모리 누수는 개발자가 더 이상 필요로 하지 않는 객체들이 가비지 컬렉션(GC) 루트로부터 여전히 참조되고 있어 메모리가 해제되지 않는 현상을 의미한다 [1-4]. 이러한 현상은 애플리케이션의 메모리 사용량을 점진적으로 증가시키며, 결과적으로 잦은 GC 실행에 따른 성능 저하와 메모리 부족(OOM) 크래시를 유발한다 [5, 6]. 일반적인 메모리 유실과 달리, 자바스크립트에서의 메모리 누수는 기본적으로 코드 어딘가에 남아있는 원치 않는 참조 때문에 발생한다 [1, 4].
-
-## 📖 구조화된 지식 (Synthesized Content)
-*   **발생 메커니즘:** V8 엔진과 같은 런타임 환경에서 객체는 글로벌 객체, 활성 클로저, 이벤트 리스너, 타이머 등으로부터 도달 가능(reachable)한 상태일 때 메모리에 유지된다 [1, 4]. 이 연결 고리를 끊지 않으면 프로그램 실행 시간이 길어질수록 힙(Heap) 메모리가 해제되지 않고 계단식(Ratchet)으로 상승하는 패턴을 보인다 [7, 8]. 특히 수명이 긴 객체들이 모이는 V8의 'Old space' 영역 사용량이 Major GC 이후에도 지속적으로 증가한다면 메모리 누수일 확률이 매우 높다 [9, 10].
-*   **주요 누수 패턴:** 소스에 따르면 다음과 같은 상황에서 메모리 누수가 빈번하게 발생한다.
-    *   **이벤트 리스너 및 타이머 축적:** 렌더링 주기나 인터벌 콜백에서 추가된 리스너 및 타이머(setInterval 등)를 적절히 제거하지 않으면, 해당 콜백의 클로저와 참조된 객체들이 무기한 메모리에 남게 된다 [11-14]. Node.js 환경에서 단일 이벤트에 10개 이상의 리스너가 추가될 때 발생하는 `MaxListenersExceededWarning` 경고는 누수 발생을 확인하는 명확한 지표이다 [15].
-    *   **클로저 스코프 보존:** 여러 클로저가 하나의 스코프를 공유하는 경우, 단 하나의 클로저라도 변수를 참조하여 활성 상태를 유지하면 동일 스코프 내에서 캡처된 다른 대용량 객체들도 메모리에서 해제되지 못한다 [11, 15].
-    *   **분리된 DOM 노드:** DOM 트리에서는 제거되었으나 JavaScript 변수나 Map/Set 등에 의해 참조를 유지하고 있는 DOM 요소는 해당 요소가 포함된 전체 서브트리의 메모리를 지속적으로 점유한다 [16, 17].
-    *   **무제한 캐시 및 라우트 전환:** 크기 제한이 없는 캐시 데이터, 혹은 SPA(Single Page Application)에서 이전 라우트의 컴포넌트가 전역 상태 참조나 리스너를 정리하지 못하는 것도 주요 누수 원인이다 [15, 18].
-    *   **잘라낸 문자열(Sliced String):** 거대한 문자열의 일부분을 `substring()` 등으로 잘라 전역 변수에 보관할 경우, 잘라낸 문자열이 원본 문자열의 포인터를 유지하므로 사용하지 않는 원본 문자열 전체가 메모리에서 해제되지 못할 수 있다 [19].
-*   **진단 및 프로파일링 도구:** 
-    *   Chrome DevTools의 '힙 스냅샷(Heap Snapshots)'과 '할당 타임라인(Allocation Timeline)'을 활용하여 누수를 진단한다 [20-23]. 
-    *   특정 동작을 수행하기 전후로 여러 번 스냅샷을 찍어 비교하는 '3-스냅샷 기법'을 통해, 의도치 않게 남아있는 객체를 효과적으로 식별할 수 있다 [20, 24]. 타임라인에 나타나는 파란색 막대는 할당 후 해제되지 않은 살아있는 메모리를 의미하며, 이를 통해 잠재적인 누수 지점을 파악한다 [23, 25, 26].
-    *   의심되는 객체를 찾았다면 DevTools의 'Retainers' 패널을 통해 해당 객체가 어떤 참조 경로(Retaining Path)를 거쳐 GC 루트에 연결되어 있는지 역추적하여 원인을 파악할 수 있다 [27-29].
-    *   또한 `--trace-gc` 플래그, `heapdump`, `clinic.js` 같은 도구를 사용하여 가비지 컬렉션 동작과 메모리 증가 추세를 모니터링할 수 있다 [7, 13, 30, 31].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[가비지 컬렉션(Garbage Collection)]], [[V8 Heap Architecture]], [[힙 스냅샷(Heap Snapshot)]], [[클로저(Closure)]]
-- **Projects/Contexts:** [[Node.js Memory Leaks in Production]], [[Browser Memory Leak Detection]]
-- **Contradictions/Notes:** C/C++ 프로그램 등에 사용되는 컴파일러 지원이 없는 보수적(Conservative) 가비지 컬렉터의 경우, 포인터처럼 보이는 일반 정수 데이터로 인해 거대한 객체 서브그래프가 유지되는 독특한 형태의 메모리 누수를 유발할 가능성이 존재한다고 소스에서 지적한다 [32]. 또한 프론트엔드 최신 도구인 `WeakRef`와 `FinalizationRegistry`를 사용해 누수에 강한 패턴을 작성할 수 있으나, 가비지 컬렉터는 자체 일정에 따라 실행되어 결정론적이지 않으므로 적절한 객체 수명 주기 관리를 완벽히 대체할 수는 없음에 유의해야 한다 [12].
-
----
-*Last updated: 2026-04-19*
-- Raw Source: [[00_Raw/2026-04-20/메모리 누수(Memory Leaks).md]]
----
diff --git a/Programming & Language/메모리 단편화(Fragmentation).md b/Programming & Language/메모리 단편화(Fragmentation).md
deleted file mode 100644
index 9aeb9512..00000000
--- a/Programming & Language/메모리 단편화(Fragmentation).md	
+++ /dev/null
@@ -1,35 +0,0 @@
----
-id: P-REINFORCE-AUTO-4BA757
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - 메모리 단편화(Fragmentation)"
----
-
-# [[메모리 단편화(Fragmentation)]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-* **단편화의 발생 원인과 문제점**: 힙(Heap) 메모리, 특히 수명이 긴 객체가 저장되는 공간(예: V8 엔진의 Old Space)에서는 매 주기마다 객체들이 자동으로 압축되지 않기 때문에 메모리 단편화가 중대한 문제로 발생합니다[2]. 수명을 다한 메모리들이 페이지 내에 사용할 수 없는 작은 빈 공간들을 남기게 되면, 총 여유 공간이 충분하더라도 연속적인 공간을 찾을 수 없어 V8 엔진은 운영체제로부터 더 많은 메모리를 요구받게 됩니다[2].
-* **압축(Compaction)을 통한 단편화 제거**: 단편화를 완화하고 실제 메모리 사용량을 줄이기 위해 가비지 컬렉터는 심하게 조각난 페이지에서 다른 페이지의 빈 공간으로 활성 객체들을 이주시키는 '압축' 알고리즘(예: Mark-Compact)을 사용합니다[1, 5]. 하지만 객체를 이동시켜 힙의 단편화를 제거하는 작업은 힙 전역에서 해당 객체들을 가리키는 모든 참조(포인터)를 찾아 업데이트해야 하므로 계산 비용이 매우 비싼(expensive) 작업입니다[3, 6]. 따라서 대규모의 Old Space에서는 압축이 매번 일어나지 않고 필요한 경우에만 선택적이고 공격적으로 수행됩니다[3].
-* **V8 엔진의 단편화 최적화 기법**:
-  * **새로운 공간(New Space)의 대피(Evacuation)**: 짧은 수명의 객체를 처리하는 V8의 마이너 GC(Scavenge) 과정에서는 살아남은 모든 객체를 다음 공간(To-Space)의 시작 부분에 빈틈없이 붙여서 복사합니다. 이 대피 과정은 부수적으로 해당 공간의 파편화를 완전히 제거하는 이점을 제공합니다[7, 8].
-  * **페이지 크기 축소**: 메모리가 적은 기기 환경에서 V8은 힙 페이지 크기를 1MB에서 512KB로 줄여 전체 메모리 단편화를 최대 2배까지 감소시켰습니다[9, 10]. 페이지 크기가 작아지면 압축 작업을 더 작은 단위로 수행할 수 있고 페이지 끝부분에 남는 미사용 공간(slack space) 또한 줄일 수 있습니다[5].
-  * **메모리 축소 모드**: V8은 메모리 사용량이 중요해질 때 메모리 축소 모드를 통해 더 적극적인 메모리 압축을 수행하여 메모리 단편화를 한층 더 줄입니다[11].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[가비지 컬렉션(Garbage Collection)]], [[메모리 압축(Compaction)]]
-- **Projects/Contexts:** [[V8 자바스크립트 엔진(V8 JavaScript Engine)]], [[Eclipse OpenJ9]]
-- **Contradictions/Notes:** 소스 전반에서 압축(Compaction)은 메모리 단편화를 해결하는 가장 확실한 방법으로 묘사되나, 그에 수반되는 참조 포인터 업데이트 연산 때문에 성능 오버헤드가 큰 비싼 작업(expensive operation)임이 일관되게 강조되고 있습니다[3, 6]. 
-
----
-*Last updated: 2026-04-19*
-- Raw Source: [[00_Raw/2026-04-20/메모리 단편화(Fragmentation).md]]
----
diff --git a/Programming & Language/메모리 파편화 방지 및 객체 풀링 (Object Pooling).md b/Programming & Language/메모리 파편화 방지 및 객체 풀링 (Object Pooling).md
deleted file mode 100644
index 652eb423..00000000
--- a/Programming & Language/메모리 파편화 방지 및 객체 풀링 (Object Pooling).md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-4FD94E
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - 메모리 파편화 방지 및 객체 풀링 (Object Pooling)"
----
-
-# [[메모리 파편화 방지 및 객체 풀링 (Object Pooling)]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/메모리 파편화 방지 및 객체 풀링 (Object Pooling).md]]
----
diff --git a/Programming & Language/명목적 타이핑 (Nominal Typing).md b/Programming & Language/명목적 타이핑 (Nominal Typing).md
deleted file mode 100644
index 7c5b6ebb..00000000
--- a/Programming & Language/명목적 타이핑 (Nominal Typing).md	
+++ /dev/null
@@ -1,37 +0,0 @@
----
-id: P-REINFORCE-AUTO-129F01
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - 명목적 타이핑 (Nominal Typing)"
----
-
-# [[명목적 타이핑 (Nominal Typing)]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 명목적 타이핑(Nominal Typing)은 객체의 실제 형태나 구조와 상관없이 타입의 이름이나 명시적 선언이 일치해야만 호환성을 인정하는 타입 시스템 방식이다 [1, 2]. TypeScript는 기본적으로 구조적 타이핑을 사용하기 때문에 명목적 타이핑을 내장 기능으로 지원하지 않지만, Java나 C# 같은 전통적인 객체 지향 언어에서는 기본 방식으로 사용된다 [1-3]. TypeScript 환경에서는 의미적으로 다른 데이터를 안전하게 구분하기 위해 '브랜디드 타입(Branded Types)' 패턴을 사용하여 명목적 타이핑의 효과를 흉내 낸다 [3-5].
-
-## 📖 구조화된 지식 (Synthesized Content)
-* **명목적 타이핑의 정의와 동작 방식**
-  명목적 타이핑 체계에서는 타입의 이름이 일치해야만 데이터의 호환성이 성립한다 [1]. 이는 "특정 신분증이 있어야만 문을 통과할 수 있는" 방식에 비유될 수 있으며, 실제 속성이나 메서드의 형태(구조)가 같더라도 이름이 다르면 호환되지 않는 것으로 간주한다 [2]. 
-
-* **TypeScript에서의 부재와 필요성**
-  TypeScript와 JavaScript는 구별 가능한 타입 별칭(distinguishable type aliases)을 생성하는 등 명목적 타이핑 매칭을 직접적으로 지원하는 내장 메커니즘을 제공하지 않는다 [3, 6]. 그러나 시스템의 복잡도가 커질수록 의미적으로 다른 데이터를 구분하지 못하는 '기본 타입에의 집착(Primitive Obsession)' 문제가 발생하므로, 런타임 구조가 동일한 값들을 타입 시스템 내에서 다르게 취급해야 할 강력한 필요성이 대두된다 [3, 5]. 
-
-* **브랜디드 타입(Branded Types)을 통한 구현**
-  명목적 타이핑을 지원하지 않는 TypeScript에서 이를 구현하기 위해 개발자들은 '브랜디드 타입' 또는 '오패크 타입(Opaque Types)'이라는 패턴을 사용한다 [4]. 이 패턴은 런타임에는 존재하지 않고 컴파일 시점에만 존재하는 고유한 속성(브랜드)을 타입에 인위적으로 부여하는 방식이다 [4, 5]. 이를 통해 같은 원시 타입(예: `string`)이라도 이메일이나 사용자 ID처럼 서로 다른 의미를 지닌 값들이 서로 혼용되거나 잘못 할당되는 것을 막고, 엄격한 명목적 구분을 생성할 수 있다 [4, 5].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[구조적 타이핑 (Structural Typing)]], [[브랜디드 타입 (Branded Types)]], [[기본 타입에의 집착 (Primitive Obsession)]]
-- **Projects/Contexts:** [[도메인 기반 설계 (DDD) 및 데이터 오염 방지]], [[TypeScript의 안전한 인터페이스 설계]]
-- **Contradictions/Notes:** Java나 C#과 같은 언어는 명목적 타이핑을 기본 언어 차원에서 제공하지만, TypeScript는 이를 내장하고 있지 않으므로 [1-3], 명목적 타이핑의 이점을 누리기 위해서는 개발자가 교집합 타입(`&`)이나 `unique symbol` 등을 활용하여 인위적인 패턴(브랜디드 타입)을 구현해야만 한다 [7, 8].
-
----
-*Last updated: 2026-04-18*
-- Raw Source: [[00_Raw/2026-04-20/명목적 타이핑 (Nominal Typing).md]]
----
diff --git a/Programming & Language/명목적 타이핑(Nominal Typing).md b/Programming & Language/명목적 타이핑(Nominal Typing).md
deleted file mode 100644
index ca6812fb..00000000
--- a/Programming & Language/명목적 타이핑(Nominal Typing).md	
+++ /dev/null
@@ -1,33 +0,0 @@
----
-id: P-REINFORCE-AUTO-DCF544
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - 명목적 타이핑(Nominal Typing)"
----
-
-# [[명목적 타이핑(Nominal Typing)]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 명목적 타이핑(Nominal Typing)은 타입의 이름이나 명시적 선언이 일치해야만 호환성을 인정하는 타입 시스템 방식입니다 [1, 2]. 이는 객체의 실제 형태나 구조를 기준으로 타입을 결정하는 구조적 타이핑(Structural Typing)과 대비되는 개념으로, Java나 C#과 같은 전통적인 객체 지향 언어에서 주로 사용됩니다 [1, 2]. TypeScript는 구조적 타이핑을 따르지만, 명목적 타이핑의 엄격한 데이터 구분 효과를 얻기 위해 '브랜디드 타입(Branded Types)' 또는 '불투명 타입(Opaque Types)'과 같은 패턴을 활용합니다 [3-5].
-
-## 📖 구조화된 지식 (Synthesized Content)
-- **명목적 타이핑의 정의와 비유:** 명목적 타이핑은 런타임 구조가 유사하더라도 타입의 이름이나 명시적 선언이 다르면 타입 시스템에서 서로 다른 것으로 취급하는 엄격한 방식입니다 [2, 3]. 구조적 타이핑이 열쇠의 모양만 맞으면 자물쇠를 여는 방식이라면, 명목적 타이핑은 특정 신분증이 있어야만 문을 통과할 수 있는 방식에 비유할 수 있습니다 [2].
-- **TypeScript에서의 한계:** JavaScript와 TypeScript는 본질적으로 덕 타이핑(Duck Typing) 및 구조적 타이핑에 의존하며, 명목적 타이핑이나 구별 가능한 타입 별칭을 직접적으로 생성하는 내장 메커니즘을 지원하지 않습니다 [3, 6]. 이로 인해 이메일 주소와 이름이 모두 구조적으로는 `string`일 때 이들을 구분하지 못하는 '기본 타입에의 집착(Primitive Obsession)'이라는 잠재적 문제가 야기될 수 있습니다 [5].
-- **대안적 구현 방식 (Branded / Opaque Types):** TypeScript에서 명목적 타이핑과 같은 비구조적 타입 매칭을 구현하기 위해 브랜디드 타입(Branded Types) 또는 불투명 타입(Opaque Types)이라는 패턴을 사용합니다 [3, 4, 7]. 이는 런타임에는 실제로 존재하지 않지만 컴파일 시점에만 존재하는 고유한 속성(예: `__brand`, `__type` 또는 `unique symbol`)을 추가하여 동일한 기본 타입을 갖는 값들이 실수로 섞이는 것을 차단합니다 [5, 8-10].
-- **실무 활용 맥락:** 이러한 명목적 타이핑 패턴은 도메인 기반 설계(DDD)에서 `UserId`와 `OrderId`를 엄격히 분리하거나, 소독된(sanitized) 텍스트와 그렇지 않은 텍스트를 구분하는 등 의미적으로 다른 데이터를 안전하게 격리하는 데 사용됩니다 [5, 11, 12].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[구조적 타이핑(Structural Typing)]], [[브랜디드 타입(Branded Types)]], [[불투명 타입(Opaque Types)]]
-- **Projects/Contexts:** [[도메인 기반 설계(DDD)]], [[Effect TS]]
-- **Contradictions/Notes:** TypeScript 커뮤니티에서 명목적(비구조적) 타입 매칭을 네이티브로 지원하는 것에 대한 논의가 2014년부터 꾸준히 있었으나 아직 완전한 합의나 내장 기능이 추가되지는 않았으며, 대신 개발자들은 고유 심볼(unique symbol)이나 런타임 유효성 검사(Zod 등)를 결합하여 이를 우회적으로 달성하고 있습니다 [3, 13, 14].
-
----
-*Last updated: 2026-04-18*
-- Raw Source: [[00_Raw/2026-04-20/명목적 타이핑(Nominal Typing).md]]
----
diff --git a/Programming & Language/모노레포(Monorepo) 기반 구성 중앙화.md b/Programming & Language/모노레포(Monorepo) 기반 구성 중앙화.md
deleted file mode 100644
index 9bb0035f..00000000
--- a/Programming & Language/모노레포(Monorepo) 기반 구성 중앙화.md	
+++ /dev/null
@@ -1,38 +0,0 @@
----
-id: P-REINFORCE-AUTO-796BD7
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - 모노레포(Monorepo) 기반 구성 중앙화"
----
-
-# [[모노레포(Monorepo) 기반 구성 중앙화]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 모노레포(Monorepo) 기반 구성 중앙화란 다수의 애플리케이션과 라이브러리가 존재하는 대규모 저장소에서 ESLint나 Prettier와 같은 도구의 설정 파일 중복을 제거하고 단일 진실 공급원(Single source of truth)을 마련하는 아키텍처 패턴입니다 [1], [2]. 중앙화된 설정 패키지를 구축하고 이를 루트 레벨에서 오케스트레이션하여 공통 규칙을 전역적으로 관리함과 동시에 패키지 고유의 자율성을 유지합니다 [3]. 이를 통해 코드의 유지보수성을 극대화하고 개발 환경의 일관성 및 검사 속도를 크게 향상시킵니다 [4].
-
-## 📖 구조화된 지식 (Synthesized Content)
-- **문제점 (설정 관리의 악몽):** 대규모 모노레포 환경에서는 Next.js 앱, 라이브러리 패키지, 공유 코드 등 각 패키지마다 `.eslintrc.json`과 `.eslintignore` 같은 설정 파일이 중복되어 존재하기 쉽습니다 [1], [5]. 이러한 설정의 파편화와 복제는 패키지 간 규칙의 불일치를 초래하고 일괄적인 업데이트를 어렵게 만들며, 특히 모노레포 루트에서 `lint-staged`를 실행해 변경된 파일만 검사하고자 할 때 개별 패키지의 규칙을 존중하기 어렵게 만드는 큰 단점이 있습니다 [1], [5].
-- **해결을 위한 3단계 아키텍처:**
-  1. **중앙화된 설정 패키지 (Centralised Config Package):** 모노레포 내부에 별도의 패키지(예: `@repo/eslint-config`)를 생성하여 기본(Base), Next.js, 라이브러리 용도의 조합 가능한 사전 설정(Preset)을 구성합니다 [3], [6], [7]. 이를 통해 핵심 규칙에 대한 단일 진실 공급원을 제공하며, 이 패키지의 규칙을 변경하면 모든 패키지가 일관되게 혜택을 받습니다 [2].
-  2. **패키지 레벨 설정의 자율성:** 각 패키지는 최소한의 설정 파일(`eslint.config.mjs`)만을 가져 중앙 패키지의 사전 설정을 임포트해 사용합니다 [2]. 동시에 패키지 특정 오버라이드(override) 규칙을 추가할 수 있어 각 패키지의 자율성을 보장합니다 [2], [4].
-  3. **루트 오케스트레이션 설정 (Root Orchestration Config):** 모노레포 루트에 파일 글로브 패턴을 기반으로 적절한 사전 설정에 매핑하는 최상위(root) 오케스트레이션 설정을 생성합니다 [8]. 이 계층은 패키지의 경계를 존중하여 개별 패키지에 올바른 규칙이 할당되도록 제어하는 핵심 비결(Secret Sauce)입니다 [8].
-- **도구 통합 및 기대 효과:**
-  - **빠르고 정교한 검사:** 루트 설정이 도입된 상태에서 Husky와 `lint-staged`를 연동하면, 커밋 시 변경된 파일만을 식별해 루트 설정이 해당 파일을 적절한 패키지 특정 규칙에 매핑하여 검사(Linting)를 수행합니다 [9].
-  - **캐싱을 통한 성능 최적화:** Turborepo 전역 의존성으로 중앙 ESLint 구성 패키지를 설정하면 설정이 변경될 때마다 캐시를 무효화하고 린트 결과를 효과적으로 캐싱하여 속도를 높일 수 있습니다 [9], [4].
-  - **코드베이스 정화 효과:** 중복 설정 파일 및 종속성을 삭제함으로써 `package.json` 라인 수와 락(lock) 파일 크기가 현저히 줄어들고, 전체 모노레포에서 코드 라인이 크게 감소하는 순효과를 얻을 수 있습니다 [10].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[ESLint]], [[Prettier]], [[lint-staged]], [[Turborepo]]
-- **Projects/Contexts:** [[대규모 모노레포 환경의 린팅 및 포매팅 설정 현대화 프로젝트]]
-- **Contradictions/Notes:** 공식적인 `lint-staged` 모노레포 가이드에서는 최상위에 `lint-staged`를 설치하고 각 패키지마다 별도의 구성 파일을 두어 고립되게 처리하라고 안내하며 루트 설정이 하위 설정을 자동으로 채워주지 않는다고 명시하지만 [11], 루트 오케스트레이션 구성을 도입하면 최상위에서 실행하면서도 패턴 매핑을 통해 각 패키지의 규칙을 성공적으로 병합·제어할 수 있습니다 [8], [12].
-
----
-*Last updated: 2026-04-19*
-- Raw Source: [[00_Raw/2026-04-20/모노레포(Monorepo) 기반 구성 중앙화.md]]
----
diff --git a/Programming & Language/모노레포(Monorepo) 설정 중앙화.md b/Programming & Language/모노레포(Monorepo) 설정 중앙화.md
deleted file mode 100644
index bc8273d4..00000000
--- a/Programming & Language/모노레포(Monorepo) 설정 중앙화.md	
+++ /dev/null
@@ -1,46 +0,0 @@
----
-id: P-REINFORCE-AUTO-19D53A
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - 모노레포(Monorepo) 설정 중앙화"
----
-
-# [[모노레포(Monorepo) 설정 중앙화]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 모노레포(Monorepo) 설정 중앙화는 대규모 프로젝트 내 여러 패키지에 분산되어 있는 코드 컨벤션(ESLint, Prettier 등) 설정을 단일 핵심 패키지로 통합하고 관리하는 아키텍처입니다 [1-3]. 이를 통해 조직 내 코드 품질 규칙의 단일 진실 공급원(Single Source of Truth)을 구축하여 설정 파편화를 방지합니다 [3, 4]. 결과적으로 전역적인 규칙 업데이트를 용이하게 하고, 중복을 제거하여 린팅 검사 및 유지보수 효율을 극대화합니다 [3, 5].
-
-## 📖 구조화된 지식 (Synthesized Content)
-* **발생하는 문제점 (설정 파편화)**
-  대규모 모노레포(예: Turborepo 기반) 환경에는 다수의 Next.js 애플리케이션, 라이브러리, 공유 코드 패키지가 혼재되어 있습니다 [2]. 패키지마다 중복된 `.eslintrc.json`과 `.eslintignore` 파일 및 의존성이 흩어져 있으면, 규칙을 전역적으로 업데이트하기 어렵고 설정이 일관되지 않게 어긋나는 '설정 드리프트(Configuration Drift)'가 발생하여 유지보수에 큰 악영향을 미칩니다 [1-3].
-
-* **중앙화 아키텍처 설계**
-  이러한 문제를 해결하기 위한 구조는 크게 세 가지 요소로 나뉩니다 [6].
-  1. **중앙 설정 패키지 생성**: 내부적으로 공통 사용할 패키지(예: `@repo/eslint-config`)를 생성하고, Base, Next.js, Library용 등 목적에 맞는 조합 가능한(composable) 프리셋을 내보냅니다 [6-8].
-  2. **개별 패키지 적용**: 개별 패키지들은 불필요한 중복 설정 대신, 중앙 패키지에서 제공하는 프리셋을 가져와(import) 사용하되 필요한 패키지별 오버라이드(override)만 최소한으로 선언합니다 [4, 5, 9].
-  3. **루트 오케스트레이션(Root Orchestration)**: 모노레포 최상단에 전역 설정 파일(`eslint.config.mjs`)을 만들고 파일 패턴(glob pattern)을 이용해 특정 패키지 경로에 적절한 프리셋을 매핑합니다 [10]. 이는 각 패키지의 경계를 존중하면서도 하나의 위치에서 통제할 수 있게 해줍니다 [10].
-
-* **자동화 도구와의 결합 및 이점**
-  * 루트 레벨에서 `Husky`와 `lint-staged`를 오케스트레이션 설정과 결합하면, 커밋 전(pre-commit)에 변경된 파일만 효율적으로 검사하면서도 각 패키지에 맞는 린트 규칙을 정확히 적용할 수 있습니다 [11].
-  * 중앙화된 설정을 적용하면 패키지 전반에 걸친 중복 의존성을 제거해 `package-lock.json` 크기가 축소되고, 전반적인 코드 라인 수가 대폭 감소합니다 [12].
-  * 또한 `Turborepo`의 캐싱 기능과 맞물려 캐시 무효화를 최소화하고 빠른 린팅과 신속한 커밋이 가능해집니다 [5, 11].
-
-* **기술적 유의사항**
-  * 해당 중앙화 구성 방식은 플랫 구성(Flat Config) 형식을 지원하는 ESLint 9 버전 이상에 최적화되어 있습니다 [3, 7]. 
-  * ESLint 8 환경에서 이 패턴을 적용하려면 `.eslintrc.js` 파일 확장자와 CommonJS 모듈 내보내기를 사용하는 등의 추가적인 조정이 필요합니다 [13].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[ESLint]], [[Prettier]], [[Turborepo]], [[Husky]], [[lint-staged]]
-- **Projects/Contexts:** [[대규모 모노레포(Monorepo) 프로젝트]], [[다중 패키지 관리 환경]]
-- **Contradictions/Notes:** 모노레포 환경에서 `lint-staged`를 적용하는 구조와 관련하여 다른 관점이 존재합니다. 일반적인 가이드에서는 패키지 간의 격리성 확보를 위해 각 패키지별로 독립된 설정 파일을 둘 것을 권장하지만 [14, 15], Turborepo를 활용하는 모노레포 환경에서는 최상위에서 '루트 오케스트레이션(Root Orchestration)'을 통해 파일 패턴으로 린팅을 중앙 제어하는 것이 중복 제거와 일관성 면에서 더 효과적인 해결책으로 제시되고 있습니다 [6, 9, 16].
-
----
-*Last updated: 2026-04-19*
-- Raw Source: [[00_Raw/2026-04-20/모노레포(Monorepo) 설정 중앙화.md]]
----
diff --git a/Programming & Language/모노레포(Monorepo) 아키텍처 설정.md b/Programming & Language/모노레포(Monorepo) 아키텍처 설정.md
deleted file mode 100644
index 841baa1a..00000000
--- a/Programming & Language/모노레포(Monorepo) 아키텍처 설정.md	
+++ /dev/null
@@ -1,42 +0,0 @@
----
-id: P-REINFORCE-AUTO-671D24
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - 모노레포(Monorepo) 아키텍처 설정"
----
-
-# [[모노레포(Monorepo) 아키텍처 설정]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 모노레포(Monorepo) 아키텍처 설정은 여러 애플리케이션과 라이브러리가 공존하는 대규모 프로젝트 환경에서 ESLint, Prettier, Husky, lint-staged 등의 도구들을 효율적으로 구성하고 관리하는 방법론입니다 [1-3]. 중복된 설정 파일로 인한 관리의 어려움을 피하기 위해 중앙 집중식 설정 패키지와 루트 오케스트레이션(Root Orchestration)을 도입하여 단일 진실 공급원(Single source of truth)을 형성합니다 [2-4]. 이를 통해 패키지별 자율성을 유지하면서도 전역적인 코드 품질 규칙을 일관되고 빠르게 강제할 수 있습니다 [4, 5].
-
-## 📖 구조화된 지식 (Synthesized Content)
-- **기존 모노레포 설정의 문제점**
-  일반적인 모노레포에는 Next.js 애플리케이션, 라이브러리 패키지, 공유 코드 등이 함께 존재합니다 [2]. 패키지마다 개별적으로 `.eslintrc.json`과 `.eslintignore` 파일을 작성하고 ESLint와 Prettier 종속성을 중복으로 설치하게 되면, 린팅 규칙이 파편화되고 관리가 매우 어려워집니다 [2]. 특히 모노레포 루트 단위에서 `lint-staged`를 실행하여 변경된 파일만 검사하려 할 때, 각 패키지의 고유한 규칙을 준수하면서 실행하는 것이 큰 장애물로 작용합니다 [3].
-
-- **루트 오케스트레이션 및 중앙 집중식 아키텍처**
-  현대적인 모노레포 환경에서는 구성 중복을 줄이기 위해 다음과 같은 3단계 아키텍처를 도입합니다 [3].
-  1. **중앙 집중식 설정 패키지 생성:** `@repo/eslint-config`와 같은 내부 패키지를 만들어 TypeScript 지원 및 Prettier 통합 등을 포함하는 기본(base) 설정과 Next.js, 일반 라이브러리에 맞춘 사전 설정(Preset)을 모듈로 구성합니다 [3, 6, 7].
-  2. **패키지 레벨 설정 적용:** 각 애플리케이션 및 라이브러리 패키지는 독자적인 설정 파일을 중복 생성하는 대신, 중앙에서 만든 설정을 최소한의 코드로 가져와(import) 사용합니다 [4]. 
-  3. **루트 오케스트레이션(Root Orchestration) 구성:** 모노레포 루트의 설정 파일에서 특정 파일 패턴(Glob pattern)에 따라 알맞은 패키지 설정이 적용되도록 매핑합니다 [8]. 이를 통해 각 패키지의 경계를 존중하면서 전역 기본 규칙을 적용할 수 있습니다 [8].
-
-- **작업 파이프라인 연동과 성능 최적화**
-  - **Husky와 lint-staged 연동:** 루트 `package.json`에 `lint-staged`를 구성하고 Husky의 `pre-commit` 훅을 설정하여, 루트 설정(Root config) 기준으로 변경된 파일만 효율적으로 린트할 수 있습니다 [9]. 이 과정에서 루트 설정의 파일 패턴 매핑을 통해 개별 패키지 규칙이 안전하게 보장됩니다 [9].
-  - **Turborepo 캐싱 통합:** 중앙 ESLint 설정 패키지를 `turbo.json`의 전역 종속성(global dependency)으로 추가함으로써, 린트 규칙이 변경될 때 모든 패키지의 Turborepo 캐시를 자동으로 무효화하여 항상 최신 규칙이 적용되도록 합니다 [9].
-  - **공식 지침의 대안:** `lint-staged`의 공식 가이드는 루트에 도구를 설치하고 각 패키지별 개별 설정 파일을 두어 '가장 가까운(closest) 구성'을 격리하여 사용하도록 권장합니다 [10]. 하지만 루트 오케스트레이션을 활용하면 여러 설정을 조율하여 더욱 유지보수가 편하고 빠르며 유연한 중앙 집중식 환경을 갖출 수 있습니다 [11].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[Turborepo]], [[ESLint]], [[Prettier]], [[Husky]], [[lint-staged]]
-- **Projects/Contexts:** [[Next.js 애플리케이션 및 라이브러리 관리]], [[모노레포 린트 자동화]]
-- **Contradictions/Notes:** 소스 [10]에 따르면 `lint-staged`의 공식 지침은 여러 하위 패키지의 구성 파일을 상호 격리된 상태로 취급하여 가장 가까운 파일을 적용하라고 설명하지만, 소스 [3, 8, 12]에서는 단일 진실 공급원을 기반으로 루트에서 파일 패턴을 매핑해주는 루트 오케스트레이션(Root Orchestration) 방식이 유지보수와 실행 속도 면에서 모노레포에 더 뛰어난 해결책이라고 주장합니다.
-
----
-*Last updated: 2026-04-19*
-- Raw Source: [[00_Raw/2026-04-20/모노레포(Monorepo) 아키텍처 설정.md]]
----
diff --git a/Programming & Language/모놀리식 아키텍처 (Monolithic Architecture).md b/Programming & Language/모놀리식 아키텍처 (Monolithic Architecture).md
deleted file mode 100644
index e8d0bd3b..00000000
--- a/Programming & Language/모놀리식 아키텍처 (Monolithic Architecture).md	
+++ /dev/null
@@ -1,33 +0,0 @@
----
-id: P-REINFORCE-AUTO-C46007
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - 모놀리식 아키텍처 (Monolithic Architecture)"
----
-
-# [[모놀리식 아키텍처 (Monolithic Architecture)]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 모놀리식 아키텍처는 애플리케이션의 모든 기능이 단일하고 강하게 결합된 단위로 구축되는 전통적인 소프트웨어 설계 방식입니다 [1]. 개발자 팀이 소규모일 경우 협의를 통해 채택하기 적합한 구조이며, 대규모 엔터프라이즈 시스템을 구축하는 데에도 역사적으로 널리 사용되어 왔습니다 [2, 3]. 그러나 시스템 규모가 커짐에 따라 새로운 기능의 배포가 지연되고 유지보수가 어려워지는 한계가 있어, 현대에는 마이크로서비스 아키텍처 등으로 전환되는 추세입니다 [1, 4, 5].
-
-## 📖 구조화된 지식 (Synthesized Content)
-* **구조 및 특징:** 모놀리식 아키텍처는 모든 기능이 하나의 단일 단위에 통합되어 동작합니다 [1]. 애플리케이션의 규모를 확장(Scaling)할 때는 주로 전체 시스템을 수평적으로 복제 및 분할하는 X축 스케일링(X-Axis Scaling) 방식을 따릅니다 [6]. 또한, 대다수의 기존 개발 도구(IDE)들은 분산형 애플리케이션보다는 이러한 모놀리식 애플리케이션을 구축하는 데 명시적인 지원을 맞추고 있습니다 [7].
-* **장점 및 활용:** 신규 프로젝트를 시작하는 소규모 팀(예: 5명 규모)의 경우, 복잡한 분산 환경보다는 팀 내 협의하에 모놀리식 구조로 시스템을 개발하는 것이 효율적일 수 있습니다 [2]. 뿐만 아니라, 대규모 엔터프라이즈 시스템 역시 모놀리식 시스템으로 구축할 수 있음이 역사적인 사례들을 통해 증명되었습니다 [3].
-* **한계 및 복잡성 증가:** 시스템과 조직의 규모가 확장되면 모놀리식 아키텍처는 뚜렷한 한계를 보입니다. 코드가 강하게 결합된 거대한 모놀리식 웹 앱이나 취약한 스크립트는 새로운 기능의 개발과 전달을 크게 지연시킵니다 [5, 8, 9]. 또한, 수정 사항이 발생할 때마다 전체 애플리케이션 인스턴스를 다루어야 하므로, 독립적인 단위로 나뉜 마이크로서비스에 비해 유지보수와 배포가 까다롭습니다 [10-12].
-* **현대 아키텍처로의 전환 사례:** 이러한 단일 구조의 단점을 극복하기 위해 많은 기업이 분산형 구조로 전환하고 있습니다. 대표적으로 넷플릭스(Netflix)는 혁신, 신뢰성, 효율성을 향상시키기 위해 기존의 모놀리식 아키텍처를 독립적인 마이크로서비스로 분리했습니다 [4]. 스포티파이(Spotify) 역시 프론트엔드 측면에서 거대한 모놀리식 웹 앱을 쪼개어 독립적으로 개발된 작은 모듈들로 결합하는 방식을 채택하여 개발 병목을 해결했습니다 [9].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[마이크로서비스 아키텍처 (Microservices Architecture)]], [[X축 스케일링 (X-Axis Scaling)]]
-- **Projects/Contexts:** [[넷플릭스 (Netflix)]], [[스포티파이 (Spotify)]]
-- **Contradictions/Notes:** 소스에 따르면 대규모 엔터프라이즈 시스템을 모놀리식 구조로 구축하는 것이 가능하다고 증명되어 있지만 [3], 실제 급격히 성장하는 기업(넷플릭스 등)의 사례에서는 규모 확장에 따른 기능 전달 지연 및 유지보수 문제를 해결하기 위해 모놀리식 아키텍처를 포기하고 마이크로서비스 아키텍처로 전환(Migration)하는 한계를 보입니다 [4, 5].
-
----
-*Last updated: 2026-04-18*
-- Raw Source: [[00_Raw/2026-04-20/모놀리식 아키텍처 (Monolithic Architecture).md]]
----
diff --git a/Programming & Language/모듈러 통합 건설 (MiC).md b/Programming & Language/모듈러 통합 건설 (MiC).md
deleted file mode 100644
index 9567de14..00000000
--- a/Programming & Language/모듈러 통합 건설 (MiC).md	
+++ /dev/null
@@ -1,34 +0,0 @@
----
-id: P-REINFORCE-AUTO-FE2B8A
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - 모듈러 통합 건설 (MiC)"
----
-
-# [[모듈러 통합 건설 (MiC)]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 모듈러 통합 건설(MiC)은 전통적인 현장 시공 방식에서 벗어나, 건축물을 독립적인 모듈로 나누어 공장에서 사전 제작한 뒤 현장에서 조립하는 혁신적인 건설 기술입니다[1]. 이 방식은 통제된 공장 환경에서 제작이 이루어지므로 기존 건설 방식에 비해 더 안전하고 환경에 미치는 영향이 적으며, 품질 제어 및 공기 단축에 매우 유리합니다[1, 2]. 건설 산업 내 숙련된 노동력 부족 문제를 해결하고 지속 가능한 발전을 지원하는 게임 체인저로 평가받고 있습니다[1, 2].
-
-## 📖 구조화된 지식 (Synthesized Content)
-- **개념 및 시공 과정:** 건축물의 기능을 구조체, 전기, 배관, 인테리어 등 하위 시스템으로 분해하여 모듈화합니다[1]. 이후 공장과 같은 철저히 통제된 환경에서 내장재와 설비가 완료된 입체 모듈(volumetric modules)을 사전 제작한 뒤, 이를 현장으로 운송하여 조립하는 방식으로 크고 영구적인 구조물을 완성합니다[1, 2]. 
-- **표준화된 인터페이스의 중요성:** 소프트웨어 아키텍처의 관심사의 분리(SoC) 원칙에서 API가 모듈 간의 소통을 규정하듯, 모듈러 통합 건설에서는 모듈 간의 '표준화된 접합부 상세(인터페이스)'가 핵심입니다[1]. 이 표준화된 인터페이스가 모듈 간의 결합을 보장하여 복잡한 관리를 단순화합니다[1].
-- **주요 장점:**
-  - **공기 단축 및 품질 향상:** 공장에서 모듈의 모든 구성 요소를 한 번에 제작하므로 밀리미터(mm) 수준까지 설치 오차를 제어할 수 있어, 방수 노드의 기밀성을 확보하고 누수를 방지하는 등 월등한 품질을 보장합니다[1, 3].
-  - **안전성 및 친환경성:** 전통적인 현장 시공 방식 대비 훨씬 안전한 제작 환경을 제공하며, 현장 작업의 최소화로 인해 환경에 미치는 부정적인 영향을 크게 줄일 수 있습니다[2].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[관심사의 분리 (SoC)]], [[모듈러 철골 건물 (MSB)]]
-- **Projects/Contexts:** [[화신산 병원 (Huoshen Mountain Hospital)]] (코로나19 팬데믹 당시 모듈러 설계 및 조립 기술을 활용하여 단기간에 고품질로 구축된 응급 병원 프로젝트[1, 4])
-- **Contradictions/Notes:** 소스에 관련 정보가 부족합니다. (제공된 소스 내에서 모듈러 통합 건설에 대한 상반된 주장이나 모순점은 발견되지 않습니다.)
-
----
-*Last updated: 2026-04-18*
-- Raw Source: [[00_Raw/2026-04-20/모듈러 통합 건설 (MiC).md]]
----
diff --git a/Programming & Language/모듈화 및 아키텍처 경계 설정.md b/Programming & Language/모듈화 및 아키텍처 경계 설정.md
deleted file mode 100644
index 2e68fb0d..00000000
--- a/Programming & Language/모듈화 및 아키텍처 경계 설정.md	
+++ /dev/null
@@ -1,40 +0,0 @@
----
-id: P-REINFORCE-AUTO-1ED3D4
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - 모듈화 및 아키텍처 경계 설정"
----
-
-# [[모듈화 및 아키텍처 경계 설정]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 모듈화는 복잡한 소프트웨어 시스템을 작고 독립적이며 관리가 용이한 부분(모듈)으로 나누는 설계 기법이다 [1]. 아키텍처 경계 설정은 이러한 모듈 간의 책임과 상호작용을 통제하기 위해 명확한 선을 긋는 과정으로, 핵심 비즈니스 로직과 외부 세부 사항을 격리하는 역할을 한다 [2, 3]. 이를 통해 시스템은 높은 응집도와 낮은 결합도를 유지하게 되며, 특정 요소의 변경이 다른 부분에 미치는 영향을 최소화하여 유지보수성, 재사용성 및 테스트 용이성을 크게 향상시킬 수 있다 [1, 4, 5].
-
-## 📖 구조화된 지식 (Synthesized Content)
-- **관심사의 분리(SoC)와 모듈화**
-  모듈화의 핵심은 프로그램의 각 부분이 서로 다른 기능이나 관심사에만 집중하도록 설계하는 '관심사의 분리(Separation of Concerns)' 원칙에 있다 [4]. 인간은 한 번에 여러 관점을 동시에 처리하기 어려워하므로, 비슷비슷한 것들을 명확한 기준으로 선명하게 분리하여 인지적 부하를 최소화해야 한다 [6-8]. 공학적으로 좋은 설계는 내부 요소들이 하나의 목적을 위해 뭉치는 '응집도(Cohesion)'를 높이고, 모듈 간의 상호 의존성을 나타내는 '결합도(Coupling)'를 낮추는 것을 지향한다 [4, 5, 9].
-
-- **아키텍처 경계와 의존성 규칙(Dependency Rule)**
-  시스템의 아키텍처는 시스템 내부에 그어진 경계와 그 경계를 넘나드는 의존성에 의해 정의된다 [10]. 클린 아키텍처(Clean Architecture)에서는 이를 엔티티, 유스케이스, 인터페이스 어댑터, 프레임워크와 드라이버 등의 동심원으로 표현한다 [2]. 여기서 가장 중요한 규칙은 "소스 코드 의존성은 반드시 안쪽으로, 고수준의 정책을 향해야 한다"는 '의존성 규칙'이다 [2, 11]. 외부 원에 위치한 UI, 데이터베이스, 프레임워크 등은 저수준의 세부 사항이며, 내부 원에 위치한 핵심 업무 규칙(비즈니스 로직)에 영향을 주어서는 안 된다 [12-14].
-
-- **경계 횡단과 데이터 전달**
-  아키텍처 경계를 가로지를 때, 제어 흐름과 의존성 방향이 반대가 되는 상황이 발생할 수 있다 [15]. 이 경우 의존성 역전 원칙(DIP)과 동적 다형성을 활용하여 내부 원에 인터페이스를 두고 외부 원에서 이를 구현하게 함으로써 의존성 규칙을 준수할 수 있다 [15-17]. 또한 경계를 넘나드는 통신은 해시맵, 기본 구조체, 데이터 전송 객체(DTO)와 같이 간단하고 독립적인 데이터 구조를 사용해야 하며, 데이터베이스의 행(Row)이나 엔티티 객체를 그대로 전달하여 의존성 규칙을 위배해서는 안 된다 [17-19].
-
-- **부분적 경계(Partial Boundaries)의 활용**
-  완벽한 아키텍처 경계를 구축하고 유지하는 것은 다형적 인터페이스 작성, 독립적 컴파일 및 배포 등 높은 비용을 수반한다 [19]. 이에 대한 대안으로 추후 확장을 대비한 '부분적 경계'를 사용할 수 있다 [19]. 독립적으로 배포할 수 있는 컴포넌트를 만들되 단일 컴포넌트로 모아 배포하여 관리 부담을 줄이거나 [20], 전략 패턴(Strategy Pattern)을 활용해 일차원 경계를 설정하거나 [21], 또는 퍼사드 패턴(Facade Pattern)을 사용하여 클라이언트와 서비스 클래스들을 단순하게 분리하는 방법 등이 있다 [22].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[관심사의 분리(SoC)]], [[클린 아키텍처(Clean Architecture)]], [[응집도와 결합도]], [[의존성 역전 원칙(DIP)]], [[단일 책임 원칙(SRP)]]
-- **Projects/Contexts:** [[넷플릭스 코스모스(Netflix Cosmos) 플랫폼]], [[마이크로 프론트엔드(Micro Frontends)]], [[스포티파이 스쿼드(Spotify Squad) 모델]], [[모듈러 통합 건설(MiC)]]
-- **Contradictions/Notes:** 완벽한 아키텍처 경계를 선행적으로 구축하는 것은 상당한 노력과 비용이 들기 때문에, 당장 필요하지 않은 오버 엔지니어링(YAGNI 원칙 위배)으로 간주되어 일부 개발자들의 거부감을 일으킬 수 있다. 하지만 경계가 없는 상태에서 나중에 횡단 관심사 문제를 겪고 나서야 뒤늦게 경계를 추가하려고 하면, 훨씬 더 높은 비용과 위험을 감수해야 한다는 딜레마가 존재한다 [19, 23].
-
----
-*Last updated: 2026-04-18*
-- Raw Source: [[00_Raw/2026-04-20/모듈화 및 아키텍처 경계 설정.md]]
----
diff --git a/Programming & Language/몰입 (Flow Theory).md b/Programming & Language/몰입 (Flow Theory).md
deleted file mode 100644
index 5c4d58c0..00000000
--- a/Programming & Language/몰입 (Flow Theory).md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-7D7420
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - 몰입 (Flow Theory)"
----
-
-# [[몰입 (Flow Theory)]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/몰입 (Flow Theory).md]]
----
diff --git a/Programming & Language/미디어 폭력과 공격성 연구.md b/Programming & Language/미디어 폭력과 공격성 연구.md
deleted file mode 100644
index fab8f9a0..00000000
--- a/Programming & Language/미디어 폭력과 공격성 연구.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-7FB7BB
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - 미디어 폭력과 공격성 연구"
----
-
-# [[미디어 폭력과 공격성 연구]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/미디어 폭력과 공격성 연구.md]]
----
diff --git a/Programming & Language/반응 시간(Reaction Time).md b/Programming & Language/반응 시간(Reaction Time).md
deleted file mode 100644
index 7891a112..00000000
--- a/Programming & Language/반응 시간(Reaction Time).md	
+++ /dev/null
@@ -1,32 +0,0 @@
----
-id: P-REINFORCE-AUTO-9738CF
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - 반응 시간(Reaction Time)"
----
-
-# [[반응 시간(Reaction Time)]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 반응 시간(Reaction Time)은 특정 자극이 나타난 후 사용자가 이에 반응하여 움직임을 개시하고 목표를 터치하기까지 소요되는 시간을 의미합니다 [1]. 시각 및 인지적 후유증 연구에서 가상현실(VR) 노출이 사용자의 자극에 대한 빠른 반응 능력에 미치는 영향을 평가하는 핵심 지표로 활용됩니다 [2]. 일반적으로 인지적 요인인 결정 속도와 운동 요인인 이동 속도로 구분되어 분석되며, VR 경험이 반응 시간에 미치는 변화는 통상 50ms 미만으로 나타납니다 [1, 3].
-
-## 📖 구조화된 지식 (Synthesized Content)
-- **측정 방식 및 구성 요소:** 반응 시간은 운동 요인과 인지 요인을 분리하여 분석하기 위해 주로 두 가지 하위 요소로 나뉘어 측정됩니다 [1]. 첫 번째는 '결정 속도(Decision speed)'로, 목표 자극이 화면에 나타난 시점부터 사용자가 누르고 있던 버튼을 놓을 때까지의 시간을 의미합니다 [1]. 두 번째는 '이동 속도(Movement speed)'로, 버튼을 놓은 순간부터 목표 자극을 터치할 때까지 걸린 시간을 뜻합니다 [1]. 시각 및 인지적 후유증 연구에서는 CANTAB 5-선택 반응 시간 과제(RTI) 앱 등을 사용하여 이러한 속도 기반 반응을 정밀하게 평가합니다 [1].
-- **가상현실(VR) 후유증으로서의 반응 시간 변화:** VR 엑서게임(예: Beat Saber)을 통한 연구 결과, VR 노출 전후로 사용자의 결정 시간(운동을 시작하는 데 필요한 시간)에는 통계적으로 유의미한 차이가 나타나지 않았습니다 [2]. 반면 이동 속도의 경우, 10분 동안의 짧은 VR 경험 직후에 사용자의 반응이 VR 노출 전 기준선보다 약간 더 빨라지는 긍정적인 효과가 관찰되기도 하였습니다 [4].
-- **문헌의 불일치성 및 실질적 한계:** VR 노출이 자극 반응 속도에 미치는 즉각적인 영향에 대한 기존 문헌들은 일관성이 매우 부족합니다 [3]. 일부 연구는 반응 시간에 부정적인 후유증을 보고하는 반면, 다른 연구들은 더 빨라지는 긍정적인 효과를 보여줍니다 [3]. 이러한 결과의 차이는 주로 VR 콘텐츠의 유형, VR 노출 지속 시간, 그리고 반응 시간 측정 방식의 차이에서 기인합니다 [3]. 주목할 만한 점은 문헌에서 보고된 반응 시간의 긍정적 또는 부정적 변화가 대부분 50ms 미만이라는 것이며, 이 정도의 미세한 변화가 운전과 같은 실제 일상 활동에서 어떠한 실질적인 결과를 초래하는지는 아직 명확하게 밝혀지지 않았습니다 [3].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[결정 속도(Decision Speed)]], [[가상현실 후유증(VR Aftereffects)]]
-- **Projects/Contexts:** [[Beat Saber 엑서게임 연구(Beat Saber Exergaming Study)]], [[CANTAB 5-선택 반응 시간 과제(CANTAB 5-choice RTI)]]
-- **Contradictions/Notes:** 가상현실 노출이 반응 시간에 미치는 즉각적인 영향에 대해 연구자마다 부정적인 후유증이 발생한다고 주장하는 연구와 오히려 긍정적인(빠른) 효과를 가져온다고 주장하는 연구가 혼재되어 문헌 간 일관성이 부족합니다 [3].
-
----
-*Last updated: 2026-04-19*
-- Raw Source: [[00_Raw/2026-04-20/반응 시간(Reaction Time).md]]
----
diff --git a/Programming & Language/백엔드-프론트엔드 데이터 변환(Data Transformation between Backend and Frontend).md b/Programming & Language/백엔드-프론트엔드 데이터 변환(Data Transformation between Backend and Frontend).md
deleted file mode 100644
index 4d168ab1..00000000
--- a/Programming & Language/백엔드-프론트엔드 데이터 변환(Data Transformation between Backend and Frontend).md	
+++ /dev/null
@@ -1,34 +0,0 @@
----
-id: P-REINFORCE-AUTO-6AC944
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - 백엔드-프론트엔드 데이터 변환(Data Transformation between Backend and Frontend)"
----
-
-# [[백엔드-프론트엔드 데이터 변환(Data Transformation between Backend and Frontend)]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 백엔드-프론트엔드 데이터 변환은 외부 서버(백엔드)에서 수신한 데이터를 프론트엔드 애플리케이션의 모델 구조에 맞게 매핑하고 파싱하는 과정입니다 [1-3]. 이 과정에서 타입스크립트의 `satisfies` 키워드나 파싱(Parsing) 패턴을 활용하면 오타, 초과 속성 할당 등의 구조적 불일치를 사전에 방지하고 견고한 타입 안전성을 확보할 수 있습니다 [3-5].
-
-## 📖 구조화된 지식 (Synthesized Content)
-- **데이터 매핑 과정의 취약성:** 외부 백엔드 시스템에서 응답으로 도착하는 데이터는 프론트엔드가 요구하는 형식과 다를 수 있습니다 [3]. 이 외부 데이터를 프론트엔드 타입에 맞춰 매핑할 때, 개발자가 속성 이름을 잘못 입력하거나 원치 않는 잉여 필드를 포함하는 등의 오류를 도입하기 쉽습니다 [3].
-- **`satisfies` 키워드를 활용한 엄격한 타입 강제:** 백엔드 데이터를 프론트엔드 모델로 변환하는 매핑 함수 내부에서 `satisfies` 키워드를 사용하면, 오직 대상 타입에 정의된 유효한 속성만 포함되도록 엄격하게 강제할 수 있습니다 [5]. 이를 통해 초과 속성이나 오타 등의 오류가 매핑 과정에서 발생하는 것을 컴파일 타임에 효과적으로 포착할 수 있습니다 [2, 5].
-- **타입 캐스팅(`as`)의 한계:** 데이터 변환 시 단순한 타입 캐스팅(`as`)을 사용하는 것은 지양해야 합니다. 타입 캐스팅은 잉여 속성 검사(Excess Property Checking)를 강제하지 않으므로 추가적인 속성이 존재하더라도 에러를 발생시키지 않아, 예측하지 못한 조용한 오류(silent error)를 유발할 수 있습니다 [5].
-- **'검증하지 말고 파싱하라(Parse, don't validate)' 원칙:** 서버의 응답을 받는 것과 같은 시스템의 경계(Boundary) 지점에서, 타입이 없거나 덜 엄격한 데이터를 잘 정의된 타입의 데이터로 초기 단계에서부터 파싱해야 합니다 [1, 4]. 단순히 데이터 유효성만 체크하는 데 그치지 않고, Zod와 같은 라이브러리를 통해 신뢰할 수 있는 구체적인 객체로 파싱한 후 시스템 내부에 전달해야 견고함을 유지할 수 있습니다 [1, 6].
-- **원격 소스 타입에 대한 의존성 주의:** 백엔드와 같은 원격 소스에서 가져오는 데이터의 형태를 기반으로 타입스크립트의 타입이나 인터페이스를 정의하고, 이를 유일한 '진실의 원천(Source of Truth)'으로 삼는 것은 피해야 합니다 [7]. 원격 소스의 형태는 프론트엔드의 정의와 언제든지 동기화가 어긋날 위험이 있기 때문입니다 [7].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[satisfies Keyword]], [[Parse, don't validate]], [[Excess Property Checking]], [[Structural Typing]]
-- **Projects/Contexts:** [[Inventory Management Example]] (외부 백엔드 응답을 프론트엔드의 `InventoryItem` 타입으로 매핑할 때 오류를 방지하는 실제 사용 시나리오 [2, 3])
-- **Contradictions/Notes:** 소스 데이터에 따르면 데이터 변환 과정에서 강제 타입 단언(type casting, `as`)을 사용하여 타입을 덮어씌우는 것은 잉여 속성을 걸러내지 못하므로 안전하지 않으며, 이를 보완하기 위해 런타임 오류 가능성을 원천 차단하는 `satisfies` 연산자의 사용이 권장됩니다 [5, 8].
-
----
-*Last updated: 2026-04-18*
-- Raw Source: [[00_Raw/2026-04-20/백엔드-프론트엔드 데이터 변환(Data Transformation between Backend and Frontend).md]]
----
diff --git a/Programming & Language/번아웃 및 직무 스트레스.md b/Programming & Language/번아웃 및 직무 스트레스.md
deleted file mode 100644
index 12477ae8..00000000
--- a/Programming & Language/번아웃 및 직무 스트레스.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-4FD551
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - 번아웃 및 직무 스트레스"
----
-
-# [[번아웃 및 직무 스트레스]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/번아웃 및 직무 스트레스.md]]
----
diff --git a/Programming & Language/범이론적 모델(Transtheoretical Model).md b/Programming & Language/범이론적 모델(Transtheoretical Model).md
deleted file mode 100644
index 5825213d..00000000
--- a/Programming & Language/범이론적 모델(Transtheoretical Model).md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-8B5019
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - 범이론적 모델(Transtheoretical Model)"
----
-
-# [[범이론적 모델(Transtheoretical Model)]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/범이론적 모델(Transtheoretical Model).md]]
----
diff --git a/Programming & Language/보상 예측 오류 (Reward Prediction Error).md b/Programming & Language/보상 예측 오류 (Reward Prediction Error).md
deleted file mode 100644
index 15513f2c..00000000
--- a/Programming & Language/보상 예측 오류 (Reward Prediction Error).md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-F58C26
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - 보상 예측 오류 (Reward Prediction Error)"
----
-
-# [[보상 예측 오류 (Reward Prediction Error)]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/보상 예측 오류 (Reward Prediction Error).md]]
----
diff --git a/Programming & Language/보조 공학 (Assistive Technology).md b/Programming & Language/보조 공학 (Assistive Technology).md
deleted file mode 100644
index dfe5a273..00000000
--- a/Programming & Language/보조 공학 (Assistive Technology).md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-34AA37
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - 보조 공학 (Assistive Technology)"
----
-
-# [[보조 공학 (Assistive Technology)]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/보조 공학 (Assistive Technology).md]]
----
diff --git a/Programming & Language/복잡한 비즈니스 도메인 (금융 헬스케어 이커머스 등).md b/Programming & Language/복잡한 비즈니스 도메인 (금융 헬스케어 이커머스 등).md
deleted file mode 100644
index 411161e8..00000000
--- a/Programming & Language/복잡한 비즈니스 도메인 (금융 헬스케어 이커머스 등).md	
+++ /dev/null
@@ -1,40 +0,0 @@
----
-id: P-REINFORCE-AUTO-AD3BC6
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - 복잡한 비즈니스 도메인 (금융 헬스케어 이커머스 등)"
----
-
-# [[복잡한 비즈니스 도메인 (금융 헬스케어 이커머스 등)]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 복잡한 비즈니스 도메인(금융, 헬스케어, 이커머스 등)은 방대하고 민감한 데이터 처리, 고도의 보안 및 엄격한 규제 준수, 그리고 복잡한 비즈니스 로직을 특징으로 하는 산업 분야입니다 [1-4]. 이러한 도메인의 내재된 복잡성을 통제하고 현실의 비즈니스 프로세스를 소프트웨어로 정확히 반영하기 위해 도메인 주도 설계(DDD)와 같은 아키텍처 원칙이 필수적으로 활용됩니다 [4-6]. 이를 통해 조직은 기술적 부채를 최소화하고 변화하는 비즈니스 요구에 맞춰 확장 가능하며 유지보수가 용이한 시스템을 구축할 수 있습니다 [5, 7].
-
-## 📖 구조화된 지식 (Synthesized Content)
-* **핵심 요구사항 및 도메인 특성:** 
-  금융(핀테크), 헬스케어, 이커머스와 같은 복잡한 도메인은 개인식별정보(PII) 및 결제카드산업(PCI) 정보 등 매우 민감한 데이터를 다루므로 설계 단계부터 강력한 데이터 보안, 프라이버시 유지 및 다층적인 암호화 전략이 필수적입니다 [2, 3, 8]. 또한 핀테크의 실시간 사기 탐지나 이커머스의 실시간 재고 관리와 같이 즉각적인 비즈니스 결정과 조치가 필요한 경우, 배치 처리보다 지연 시간이 짧은 실시간 데이터 스트리밍 및 이벤트 기반 아키텍처(EDA)가 강하게 요구됩니다 [1, 8].
-
-* **도메인 주도 설계(DDD)를 통한 복잡성 관리:** 
-  금융, 헬스케어, 이커머스처럼 비즈니스 로직이 방대하고 복잡한 도메인에서는 도메인 주도 설계(DDD)가 가장 이상적인 아키텍처 베스트 프랙티스로 꼽힙니다 [5]. 거대하고 복잡한 도메인을 '주문 관리(Order Management)', '사용자 관리'와 같이 작고 관리하기 쉬운 '바운디드 컨텍스트(Bounded Context)'로 분할하여 복잡성을 통제합니다 [6, 9]. 이를 통해 기술팀과 도메인 전문가가 공통의 '유비쿼터스 언어(Ubiquitous Language)'를 사용하여 의사소통 격차를 줄이고 소프트웨어가 실제 비즈니스를 정확히 반영하도록 모델링합니다 [4].
-
-* **데이터 거버넌스 및 품질 관리:**
-  규제가 엄격한 금융 및 헬스케어 산업에서는 규정 준수를 위해 강력한 데이터 거버넌스와 메타데이터 관리가 필수적입니다 [8, 10]. 잘못된 데이터로 인한 치명적인 의사결정 오류나 머신러닝 모델의 붕괴를 방지하기 위해 파이프라인의 모든 단계에서 자동화된 데이터 품질 및 유효성 검사 프레임워크(예: Data Contracts)를 적용해야 합니다 [11].
-
-* **아키텍처의 논리적 격리와 마이크로서비스 확장:** 
-  복잡한 비즈니스 도메인의 핵심 규칙은 클린 아키텍처(Clean Architecture) 원칙에 따라 데이터베이스나 웹 프레임워크와 같은 외부 인프라의 변동으로부터 완벽히 보호(격리)되어야 합니다 [12, 13]. 나아가 마이크로서비스 아키텍처를 도입하여 거대한 시스템을 특정 비즈니스 도메인 기능에 맞춰 세분화된 독립 서비스로 나누면, 각 팀이 자율적으로 배포 및 확장을 수행할 수 있어 복잡한 시스템 환경에서도 비즈니스 민첩성을 확보할 수 있습니다 [6, 14].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[도메인 주도 설계 (DDD)]], [[바운디드 컨텍스트 (Bounded Context)]], [[마이크로서비스 아키텍처 (Microservices Architecture)]], [[이벤트 기반 아키텍처 (Event-Driven Architecture)]], [[데이터 거버넌스 (Data Governance)]]
-- **Projects/Contexts:** [[핀테크의 실시간 사기 탐지]], [[이커머스의 실시간 재고 관리]], [[헬스케어의 민감 데이터(PII/PCI) 보안 규제 준수]]
-- **Contradictions/Notes:** 소스 문헌들은 복잡한 비즈니스 도메인 구축 시 기술적인 관점으로만 시스템을 나누는 것(예: 단순 계층형 아키텍처)보다, 비즈니스 현실을 중심에 두고 비즈니스 역량과 도메인 모델을 기준으로 시스템을 세분화하는 도메인 주도 설계(DDD)나 마이크로서비스 아키텍처가 훨씬 더 높은 확장성과 유지보수성을 제공한다고 강조합니다 [5, 6, 15].
-
----
-*Last updated: 2026-04-18*
-- Raw Source: [[00_Raw/2026-04-20/복잡한 비즈니스 도메인 (금융, 헬스케어, 이커머스 등).md]]
----
diff --git a/Programming & Language/불변성 (Immutability).md b/Programming & Language/불변성 (Immutability).md
deleted file mode 100644
index 40498a25..00000000
--- a/Programming & Language/불변성 (Immutability).md	
+++ /dev/null
@@ -1,43 +0,0 @@
----
-id: P-REINFORCE-AUTO-07CB26
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - 불변성 (Immutability)"
----
-
-# [[불변성 (Immutability)]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> TypeScript에서 불변성(Immutability)은 주로 `readonly` 수식어와 `Readonly<T>` 유틸리티 타입을 통해 컴파일 타임에 데이터가 의도치 않게 변경되는 것을 방지하는 핵심 개념입니다 [1-3]. 이를 통해 객체의 속성이나 배열 요소가 초기화된 이후에 수정되는 것을 엄격히 차단하여 부작용을 줄이고 함수형 프로그래밍 패턴을 지원합니다 [1, 4]. 런타임에 성능 오버헤드를 유발하는 `Object.freeze()`와 달리 컴파일 시점에만 작동하므로, 제로 런타임 비용으로 데이터의 무결성을 보장하는 것이 특징입니다 [1, 3, 5].
-
-## 📖 구조화된 지식 (Synthesized Content)
-*   **불변성 구현 메커니즘 (`readonly`와 `Readonly<T>`)**
-    TypeScript에서는 객체나 클래스의 속성, 배열 정의 시 `readonly` 수식어를 추가하여 초기화 후 값을 변경하는 것을 금지할 수 있습니다 [1, 6, 7]. 또한, 기존 타입의 모든 속성을 읽기 전용으로 변환하는 `Readonly<T>` 유틸리티 타입을 제공하여 설정 객체, API 응답 데이터, 상태 관리(리듀서) 등을 안전하게 보호할 수 있습니다 [2, 7, 8].
-
-*   **`const` 및 `Object.freeze()`와의 차이점**
-    불변성을 강제하는 방식에 있어서 `const`, `Object.freeze()`, 그리고 `readonly`는 명확한 차이를 보입니다.
-    *   **`const`**: 런타임에 변수 자체의 재할당을 막지만, 객체 내부 속성의 변경(Mutation)은 막지 못합니다 [3, 5, 9].
-    *   **`Object.freeze()`**: 런타임에 객체 속성 수정을 차단하지만, 얕은(shallow) 동결만 지원하며 런타임 성능 오버헤드가 발생합니다 [3, 10].
-    *   **`readonly`**: 컴파일 타임에 속성 접근 및 수정을 차단하며, 생성된 JavaScript에는 흔적이 남지 않아 런타임 성능 비용이 전혀 없습니다 [1, 3, 5].
-
-*   **얕은 불변성(Shallow Immutability)과 에일리어싱(Aliasing)의 한계**
-    TypeScript의 기본 불변성 기능인 `readonly`나 `Readonly<T>`는 객체의 최상위 속성만 보호하는 얕은 수준의 불변성만 제공합니다 [11-13]. 더 큰 문제점은 '에일리어싱(Aliasing)'입니다. `readonly` 타입으로 보호된 데이터가 변경 가능한(mutable) 매개변수를 기대하는 함수에 전달될 경우, TypeScript는 이를 호환되는 것으로 간주하여 에러를 띄우지 않고, 해당 함수 내부에서 원본 데이터가 변이될 수 있는 취약점이 존재합니다 [14, 15]. 
-
-*   **재귀적 불변성(Deep Readonly)의 구축**
-    중첩된 객체나 배열 내부 깊숙한 곳까지 완벽하게 불변성을 유지하기 위해서는 기본 기능만으로는 부족합니다 [12]. 이를 극복하기 위해 매핑 타입(Mapped Types)과 조건부 타입(Conditional Types)을 결합하여 내부 속성까지 재귀적으로 `readonly`를 적용하는 커스텀 `DeepReadonly<T>` 유틸리티 타입을 구축해 사용해야 합니다 [12, 13, 16]. 이는 트리 구조나 복잡한 상태 관리 시스템에서 데이터 무결성을 보장하는 강력한 방패 역할을 합니다 [13].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[readonly 수식어]], [[Readonly 유틸리티 타입]], [[DeepReadonly (재귀적 불변성)]], [[에일리어싱 (Aliasing)]], [[구조적 타이핑 (Structural Typing)]]
-- **Projects/Contexts:** [[Redux 등 상태 관리 (State Management)]], [[API 응답 데이터 모델링]], [[글로벌 설정 객체 (Configuration Objects) 보호]]
-- **Contradictions/Notes:** TypeScript의 `readonly`는 완벽한 런타임 불변성을 제공하지 않습니다. 컴파일 타임에만 유효하며 컴파일 후 자바스크립트 코드에서는 해당 제약이 사라집니다 [1]. 또한, 에일리어싱을 통해 `readonly` 배열이 일반 배열 타입으로 취급될 경우 타입 시스템을 우회하여 변이가 일어날 수 있으므로 함수 시그니처 설계 시 주의해야 합니다 [14, 15].
-
----
-*Last updated: 2026-04-18*
-- Raw Source: [[00_Raw/2026-04-20/불변성 (Immutability).md]]
----
diff --git a/Programming & Language/불변성(Immutability).md b/Programming & Language/불변성(Immutability).md
deleted file mode 100644
index 5d30f261..00000000
--- a/Programming & Language/불변성(Immutability).md	
+++ /dev/null
@@ -1,39 +0,0 @@
----
-id: P-REINFORCE-AUTO-647D86
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - 불변성(Immutability)"
----
-
-# [[불변성(Immutability)]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 불변성(Immutability)은 초기화 이후 객체의 속성이나 배열 요소와 같은 데이터가 예기치 않게 수정되는 것을 방지하는 개념이다 [1, 2]. TypeScript에서는 주로 `readonly` 수식어를 사용하여 런타임 오버헤드 없이 컴파일 타임에 선언적으로 불변성을 강제한다 [2-4]. 이는 의도치 않은 상태 변경이나 데이터 오염을 사전에 방지하여 코드의 예측 가능성을 높이고 버그를 줄이는 데 필수적인 역할을 한다 [4, 5].
-
-## 📖 구조화된 지식 (Synthesized Content)
-* **불변성의 원리와 장점**
-  런타임에 동작하는 자바스크립트의 `Object.freeze()`와 달리, TypeScript의 `readonly`를 활용한 불변성 구현은 런타임 성능 비용 없이 컴파일 시점의 구조적 타입 체크를 통해 오류를 찾아낸다 [4, 6]. 이는 방어적 코딩을 줄여주며, 예측 가능한 애플리케이션 상태 관리와 함수형 프로그래밍 패턴을 효과적으로 지원한다 [1, 4, 7]. 또한, `const`가 변수의 재할당만을 막는 것에 반해 `readonly`는 참조된 객체 내부의 콘텐츠 자체를 동결시킨다는 점에서 명확히 구별된다 [6, 8].
-
-* **TypeScript에서의 구현 방법**
-  * **객체 및 배열 보호:** 클래스나 인터페이스 내 속성에 `readonly` 키워드를 선언하거나, 배열에 `readonly T[]` 또는 `ReadonlyArray<T>`를 지정하면 값을 변경하는 메서드(`push`, `pop` 등)의 사용이 타입 시스템에서 완전히 제거된다 [9, 10].
-  * **얕은(Shallow) 불변성과 깊은(Deep) 불변성:** 내장된 `Readonly<T>` 유틸리티나 기본 `readonly` 키워드는 객체의 최상위 속성만 보호하는 얕은 수준의 불변성을 제공하므로, 중첩된 하위 객체의 변경은 막지 못한다 [1, 11, 12]. 중첩 데이터 트리의 완벽한 무결성을 보장하기 위해서는 매핑 타입(Mapped Types)과 조건부 타입(Conditional Types)을 결합하여 재귀적으로 동작하는 `DeepReadonly` 유틸리티 타입을 구축해야 한다 [11, 12].
-  * **`as const` 단언:** 객체나 배열 선언 시 `as const`를 함께 사용하면 변수를 리터럴 타입으로 좁히는 동시에 깊은(deep) 읽기 전용 상태를 부여할 수 있다 [13, 14].
-
-* **주의점 및 한계점 (Aliasing 취약성)**
-  `readonly`는 컴파일러가 해당 참조를 통한 직접적인 수정을 막아줄 뿐, 변이가 허용된 다른 변수나 매개변수(별칭, Alias)로 값이 전달될 경우에는 `readonly` 보장이 상실되어 원본 데이터가 변경될 수 있는 취약점이 있다 [15, 16]. 따라서 엄격한 불변성을 유지하려면 함수 서명 단계에서부터 일관되게 `readonly` 매개변수를 강제하도록 설계해야 한다 [16, 17].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[readonly]], [[DeepReadonly]], [[as const]], [[구조적 타이핑(Structural Typing)]]
-- **Projects/Contexts:** [[상태 관리(State Management)]], [[TypeScript 타입 시스템 및 인터페이스 설계]]
-- **Contradictions/Notes:** 자바스크립트의 `Object.freeze()`는 런타임에 직접 객체를 동결하여 보호하지만 성능 저하가 동반되는 반면, TypeScript의 `readonly`는 런타임 성능 저하는 없으나 타입 호환성을 악용한 우회(Aliasing) 변형까지는 완벽히 차단하지 못한다는 한계를 지닌다 [4, 6, 15, 18].
-
----
-*Last updated: 2026-04-18*
-- Raw Source: [[00_Raw/2026-04-20/불변성(Immutability).md]]
----
diff --git a/Programming & Language/불필요한 리렌더링 방지.md b/Programming & Language/불필요한 리렌더링 방지.md
deleted file mode 100644
index 5dca1d0a..00000000
--- a/Programming & Language/불필요한 리렌더링 방지.md	
+++ /dev/null
@@ -1,46 +0,0 @@
----
-id: P-REINFORCE-AUTO-B13B4D
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - 불필요한 리렌더링 방지"
----
-
-# [[불필요한 리렌더링 방지]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> React 애플리케이션에서 성능 저하를 막기 위해 컴포넌트의 프롭스(Props), 상태(State), 컨텍스트(Context) 변경으로 인한 연쇄적인 렌더링을 제어하고 최적화하는 기법입니다.
-
-## 📖 구조화된 지식 (Synthesized Content)
-**1. 리렌더링의 원리 파악** React에서 컴포넌트는 자신의 상태나 프롭스가 변경되거나, 의존하고 있는 컨텍스트 값이 바뀌거나, 부모 컴포넌트가 리렌더링될 때 업데이트됩니다. 부모가 렌더링되면 자식 컴포넌트도 프롭스 변경 여부와 상관없이 렌더링되는 폭포수(Cascading) 현상이 발생합니다.
-
-**2. 메모이제이션(Memoization) 활용**
-
-- **`React.memo()`**: 컴포넌트의 프롭스를 얕은 비교(Shallow compare)하여 변경되지 않았으면 이전 렌더링 결과를 재사용합니다.
-- **`useMemo` 및 `useCallback`**: 무거운 계산 결과나 함수의 참조(Reference) 안정성을 유지하여, 메모이제이션된 자식 컴포넌트에 새로운 참조가 전달되어 리렌더링이 발생하는 것을 막습니다.
-- 다만, 메모이제이션 자체에도 비용(오버헤드)이 발생하므로 성능 문제가 프로파일링된 경우에만 의도적으로 사용하는 것이 좋습니다.
-
-**3. React 19 컴파일러의 자동 최적화** React 19에 도입된 컴파일러는 빌드 타임에 코드를 분석하여 컴포넌트, 값, 콜백 함수에 자동으로 메모이제이션을 적용합니다. 이를 통해 수동으로 `useMemo`나 `useCallback`을 작성해야 했던 보일러플레이트를 줄여줍니다.
-
-**4. 상태 지역화(State Colocation)와 익명 함수 분리**
-
-- 상태를 부모로 과도하게 끌어올리는(State Lifting) 것은 불필요한 컴포넌트 트리의 렌더링을 유발하므로, 상태는 최대한 사용하는 곳과 가까운 위치(Local)에 두어야 합니다. (예: 빈번하게 변하는 마우스 좌표 등)
-- JSX 내부에 익명 함수나 인라인 객체를 직접 선언하면 매 렌더링마다 새로운 참조가 생성되므로, 렌더링 성능에 악영향을 줍니다.
-
-**5. Context API 최적화 및 상태 관리 라이브러리 사용** React 기본 Context는 내부 값이 하나라도 변경되면 이를 구독하는 모든 컴포넌트를 리렌더링시킵니다. 이를 방지하기 위해 컨텍스트를 업데이트 빈도별로 잘게 쪼개거나, Zustand, Jotai, Valtio와 같이 선택적 구독(Selective Subscription)과 미세 조정(Fine-grained) 업데이트를 지원하는 상태 관리 도구를 도입해야 합니다.
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[React Performance Optimization]], [[React 19 Compiler]], [[상태 관리 최적화 (Zustand, Jotai, Valtio)]], [[재조정 (Reconciliation)]], [[Virtualization (리스트 가상화)]]
-- **Projects/Contexts:** [[대규모 프론트엔드 아키텍처 설계]], [[고빈도 업데이트를 처리하는 실시간 대시보드]]
-- **Contradictions/Notes:** 많은 개발자들이 컴포넌트가 느려지면 습관적으로 조기 메모이제이션(Premature Memoization)을 적용하려 하지만, 비교 연산 자체의 오버헤드로 인해 컴포넌트가 작고 빠르다면 오히려 성능이 하락할 수 있습니다. 항상 React DevTools Profiler 등으로 측정(Measure)한 후 최적화를 적용해야 합니다.
-
----
-
-_Last updated: 2026-04-14_
-- Raw Source: [[00_Raw/2026-04-20/불필요한 리렌더링 방지.md]]
----
diff --git a/Programming & Language/브라우저 DOM 누수 탐지 및 렌더링 최적화.md b/Programming & Language/브라우저 DOM 누수 탐지 및 렌더링 최적화.md
deleted file mode 100644
index 9bd34c20..00000000
--- a/Programming & Language/브라우저 DOM 누수 탐지 및 렌더링 최적화.md	
+++ /dev/null
@@ -1,44 +0,0 @@
----
-id: P-REINFORCE-AUTO-590D6E
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - 브라우저 DOM 누수 탐지 및 렌더링 최적화"
----
-
-# [[브라우저 DOM 누수 탐지 및 렌더링 최적화]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-**DOM 누수의 원리 및 주요 발생 패턴**
-*   브라우저 자바스크립트의 메모리 누수는 메모리가 '사라지는' 것이 아니라, GC 루트(window, 활성 클로저, 이벤트 리스너 등)에서 계속 접근 가능한 상태로 남아있어 가비지 컬렉터가 회수하지 못할 때 발생합니다 [1].
-*   가장 대표적인 패턴은 '분리된 DOM 노드(Detached DOM nodes)'입니다. 이는 문서(Document)에서는 제거되었으나 자바스크립트 변수나 Map/Set 엔트리에 의해 참조가 유지되어, 해당 요소와 그 하위 트리 전체가 메모리에 남아있는 현상입니다 [2, 7].
-*   이 외에도 해제되지 않은 이벤트 리스너, 여러 클로저가 동일한 스코프를 공유할 때 발생하는 클로저 스코프 보존(Closure scope retention), 그리고 제거된 타겟을 가리키는 잊혀진 타이머(setInterval)와 옵저버(MutationObserver 등)가 주요 누수 원인입니다 [8, 9]. 
-*   단일 페이지 애플리케이션(SPA)의 라우트 전환 시 이전 라우트의 컴포넌트가 리스너나 전역 상태 참조를 제대로 정리하지 못하는 것이 가장 큰 누수 발생 출처입니다 [10].
-
-**브라우저 DOM 누수 탐지 기법**
-*   **3단계 스냅샷 기법 (Three-snapshot technique):** 누수를 탐지하는 가장 신뢰할 수 있는 방법입니다. 베이스라인 스냅샷을 찍고, 누수가 의심되는 액션을 수행한 뒤 두 번째 스냅샷을 찍으며, 동일한 액션을 반복한 뒤 세 번째 스냅샷을 찍어 두 번째와 세 번째 스냅샷을 비교하는 방식입니다 [11].
-*   **Chrome DevTools의 힙 스냅샷 (Heap snapshot):** 특정 시점의 전체 객체 그래프를 캡처합니다. 'Comparison(비교)' 뷰를 통해 스냅샷 간의 차이를 확인하거나, 'Retained Size' 기준으로 정렬하여 가장 큰 누수 객체를 찾을 수 있습니다 [3, 12, 13]. 필터 기능 중 "Objects retained by detached nodes(분리된 노드에 의해 보존된 객체)"를 사용하면 DOM 누수를 쉽게 식별할 수 있습니다 [14].
-*   **할당 타임라인 (Allocation instrumentation on timeline):** 일정 기간 동안의 모든 메모리 할당과 스택 트레이스를 기록합니다 [3, 15]. 파란색 막대는 타임라인이 끝날 때까지 여전히 살아있는 객체를 나타내며, 이를 분석하여 예상 수명을 초과하여 남겨진 객체와 해당 객체가 생성된 정확한 코드 위치를 찾을 수 있습니다 [3, 16, 17].
-*   누수 조사 시에는 `console.log`가 객체 참조를 유지할 수 있다는 점과, 미니파이(Minify)된 코드는 분석이 어려우므로 소스 맵(Source maps)을 사용해야 한다는 주의사항이 있습니다 [10].
-
-**가비지 컬렉션(GC)과 렌더링 성능의 상관관계**
-*   가비지 컬렉터가 메모리를 회수할 때는 메인 스레드의 실행을 일시적으로 멈추는 'Stop-the-world' 현상이 발생할 수 있습니다 [6, 18]. 메모리가 부족해지거나 누수가 누적되면 GC가 자주, 길게 실행되는데, 이는 인터랙티브 시스템이나 애니메이션 실행 시 사용자에게 불쾌한 끊김 현상(Jank)과 렌더링 지연을 유발합니다 [5, 6].
-*   V8 엔진은 이러한 메인 스레드의 렌더링 및 실행 지연을 최소화하기 위해 'Orinoco' 가비지 컬렉터를 도입하였습니다 [19]. 이는 병렬(Parallel), 점진적(Incremental), 동시(Concurrent) 기법을 활용하여 대부분의 GC 작업을 백그라운드 스레드에서 처리함으로써 메인 스레드가 자바스크립트를 실행하고 화면을 원활히 렌더링할 수 있도록 돕습니다 [20-23].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[Garbage Collection (GC)]], [[Chrome DevTools]], [[Detached DOM nodes]], [[Heap Snapshot]], [[Orinoco GC]]
-- **Projects/Contexts:** [[V8 JavaScript Engine]], [[Single Page Applications (SPA)]]
-- **Contradictions/Notes:** 소스에는 브라우저 메모리 누수 탐지 방법과 V8 엔진의 가비지 컬렉터 동작 원리에 대한 정보는 매우 상세하게 설명되어 있으나, 레이아웃 연산, 페인팅 규칙, CSS 최적화 등 브라우저의 순수 '렌더링 파이프라인 최적화'와 관련된 직접적인 소스에 관련 정보가 부족합니다. 따라서 렌더링 최적화는 주로 '메모리 누수 방지를 통한 GC Pause(Jank) 최소화'의 관점에서만 다루어졌습니다.
-
----
-*Last updated: 2026-04-19*
-- Raw Source: [[00_Raw/2026-04-20/브라우저 DOM 누수 탐지 및 렌더링 최적화.md]]
----
diff --git a/Programming & Language/브라우저 메모리 관리 및 최적화.md b/Programming & Language/브라우저 메모리 관리 및 최적화.md
deleted file mode 100644
index 8c363995..00000000
--- a/Programming & Language/브라우저 메모리 관리 및 최적화.md	
+++ /dev/null
@@ -1,40 +0,0 @@
----
-id: P-REINFORCE-AUTO-F4D557
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - 브라우저 메모리 관리 및 최적화"
----
-
-# [[브라우저 메모리 관리 및 최적화]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 브라우저 메모리 관리는 더 이상 필요하지 않은 객체의 메모리를 자동으로 회수하여 애플리케이션의 성능 저하나 충돌을 방지하는 핵심 과정이다 [1-3]. V8 자바스크립트 엔진은 힙(Heap) 공간을 여러 세대로 나누고 가비지 컬렉션(GC)을 통해 동적으로 메모리를 관리한다 [4-6]. 브라우저에서 발생하는 주요 메모리 누수는 개발자가 실수로 남겨둔 참조(DOM 노드, 이벤트 리스너, 클로저 등) 때문에 발생하며, 이를 최적화하기 위해 Chrome DevTools의 힙 스냅샷 및 할당 타임라인 도구를 사용하여 누수 원인을 식별하고 해결해야 한다 [2, 7-9].
-
-## 📖 구조화된 지식 (Synthesized Content)
-- **V8 엔진의 메모리 구조와 가비지 컬렉션(GC):**
-  V8은 힙을 'New-space(Young Generation)'와 'Old-space(Old Generation)' 등으로 나누어 세대별 가비지 컬렉션을 수행한다 [4-6, 10, 11]. New-space에서는 주로 짧은 수명주기를 가진 객체들이 할당되며, Scavenger(Minor GC) 알고리즘을 통해 사용되지 않는 메모리를 빠르게 회수하고 살아남은 객체는 Old-space로 승격(promote)시킨다 [4, 12-14]. Old-space에서는 Mark-Sweep 및 Mark-Compact(Major GC) 알고리즘을 사용하여 도달할 수 없는(unreachable) 객체의 메모리를 회수하고 파편화를 줄인다 [15-18]. 최신 V8의 Orinoco 가비지 컬렉터는 메인 스레드의 멈춤(Stop-the-world) 현상을 최소화하기 위해 병렬(Parallel), 동시(Concurrent), 점진적(Incremental) 마킹 및 지연 스위핑(Lazy sweeping) 기법을 도입했다 [19-24].
-
-- **주요 메모리 누수(Memory Leak) 패턴:**
-  메모리 누수는 가비지 컬렉터가 회수해야 할 객체가 전역 객체나 클로저 등에 의해 계속 참조되어 메모리에 도달 가능한 상태(reachable)로 남아있을 때 발생한다 [2]. 브라우저 환경의 대표적인 누수 패턴으로는 문서에서 제거되었으나 자바스크립트 변수에 의해 참조가 남아있는 '분리된 DOM 노드(Detached DOM nodes)' [8, 25], 해제되지 않은 채 누적된 '이벤트 리스너(Event listener)' 및 '타이머/옵저버(Timers and observers)' [9, 26-28], 그리고 여러 클로저가 스코프를 공유할 때 발생하는 '클로저 스코프 유지(Closure scope retention)' 등이 있다 [9, 29].
-
-- **메모리 프로파일링 및 최적화 도구:**
-  Chrome DevTools의 **Heap Snapshot(힙 스냅샷)**을 사용하면 특정 시점의 전체 객체 그래프와 메모리 크기(Shallow/Retained size)를 파악할 수 있다 [7, 30]. 특히 의심되는 작업을 반복하며 세 번의 스냅샷을 찍어 비교하는 기법(Three-snapshot technique)을 사용하거나 'Comparison' 뷰를 활용하면 삭제되지 않고 남은 누수 객체를 효과적으로 필터링할 수 있다 [31, 32]. 또한, **Allocation Timeline(할당 타임라인)** 도구를 통해 시간에 따른 메모리 할당을 추적하여, 가비지 컬렉션되지 않고 파란색 막대로 남아있는 객체와 해당 객체의 생성 위치(Stack trace)를 식별할 수 있다 [7, 33-37].
-
-- **메모리 최적화 기법:**
-  브라우저 메모리 소비를 줄이기 위해 V8은 저사양 기기에서 가비지 컬렉션 빈도를 높여 힙 여유 공간을 덜 남기도록 하는 '메모리 감소 모드(Memory reduction mode)'를 도입하여 메모리 풋프린트를 대폭 줄였다 [38, 39]. 또한, 백그라운드 파싱 중 할당되는 메모리 존(Zone)의 수명을 단축하고 AST 노드의 필드 패킹을 수동으로 개선하여 파서와 컴파일러의 오프힙(off-heap) 메모리 소비를 최적화했다 [40, 41]. V8은 포인터 압축(Pointer compression) 기술을 통해 메모리 오버헤드를 크게 줄이기도 했으나, 이로 인해 전체 V8 힙을 4GB의 연속된 메모리 케이지(Memory Cage) 내로 제한하는 구조적 변화를 가져왔다 [42, 43].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[가비지 컬렉션 (Garbage Collection)]], [[V8 JavaScript Engine]], [[Chrome DevTools]], [[메모리 누수 (Memory Leak)]]
-- **Projects/Contexts:** [[Orinoco 프로젝트]], [[Chrome Allocation Timeline]], [[Three-snapshot technique]], [[V8 Memory Cage]]
-- **Contradictions/Notes:** 가비지 컬렉션 시스템의 성능이 관리되지 않는(unmanaged) 언어(예: C/C++)에 비해 절대적으로 우수하거나 나쁜 것은 아니다. 관리되는 언어는 메모리 할당이 단순 포인터 증가만으로 이루어져 매우 빠르지만, 메모리가 부족하여 가비지 컬렉터가 실행될 때는 예기치 않은 성능 비용(지연 및 멈춤)을 필연적으로 지불해야 한다 [44]. 또한 포인터 압축(Pointer compression)은 V8 힙 크기를 최대 40%까지 줄이고 성능을 5~10% 향상시키지만, 힙의 최대 크기를 4GB로 엄격히 제한한다는 트레이드오프가 존재한다 [42, 45].
-
----
-*Last updated: 2026-04-19*
-- Raw Source: [[00_Raw/2026-04-20/브라우저 메모리 관리 및 최적화.md]]
----
diff --git a/Programming & Language/브라우저 메모리 할당 시점별 힙(Heap) 동작 상세 로그.md b/Programming & Language/브라우저 메모리 할당 시점별 힙(Heap) 동작 상세 로그.md
deleted file mode 100644
index e342c2e2..00000000
--- a/Programming & Language/브라우저 메모리 할당 시점별 힙(Heap) 동작 상세 로그.md	
+++ /dev/null
@@ -1,40 +0,0 @@
----
-id: P-REINFORCE-AUTO-CAF78B
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - 브라우저 메모리 할당 시점별 힙(Heap) 동작 상세 로그"
----
-
-# [[브라우저 메모리 할당 시점별 힙(Heap) 동작 상세 로그]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-* **가비지 컬렉션(GC) 추적 로그의 구조와 해석:**
-  V8 엔진은 `--trace-gc` 플래그를 통해 메모리 할당 실패나 임계치 도달에 따른 힙 상태 변화를 연대기적으로 기록합니다 [1, 6]. 표준 추적 로그의 형식은 `Timestamp ms: Type Used (Total) -> Used (Total) MB, Duration ms, Reason`으로 구성됩니다 [7]. 여기서 'Type'은 Scavenge 또는 Mark-sweep과 같은 GC 알고리즘을 뜻하고, 'Used'와 'Total'은 GC 전후의 활성 객체 크기 및 운영체제로부터 예약된 총 힙 메모리를 나타냅니다 [7, 8]. 'Reason' 필드는 "allocation failure(할당 실패)" 등 GC 이벤트를 촉발한 원인을 명시하여 할당 타이밍을 분석할 수 있게 합니다 [6, 8].
-
-* **상세 로그 및 힙 공간별 분석 (`--trace-gc-verbose`):**
-  더 깊은 분석을 위해 `--trace-gc-verbose` 플래그를 사용하면 New space, Old space, Large object space 등 V8의 각 힙 공간(Space)별 사용량(used), 가용량(available), 커밋된 메모리(committed)의 상세 내역을 제공합니다 [6, 9]. 특히 Old space의 사용 크기가 Major GC 이후에도 지속적으로 증가한다면 이는 메모리 누수를 강력히 시사하는 지표가 됩니다 [6]. `--trace-gc-nvp` 플래그는 이러한 로그를 "name=value" 쌍으로 포맷하여 프로그램 기반의 자동화된 지표 산출(예: Mutator Utilization 계산)을 돕습니다 [10].
-
-* **할당 타임라인 계측 (Allocation Instrumentation on Timeline):**
-  Chrome DevTools의 'Allocations on timeline' 도구는 최대 50ms의 주기로 힙 스냅샷을 찍어 시간 경과에 따른 객체 할당을 시각화합니다 [2, 11, 12]. 타임라인에서 막대의 높이는 새로 할당된 객체의 크기를 나타내며, 색상은 객체의 현재 생존 여부를 보여줍니다 [2, 13, 14]. **파란색 막대(Blue bars)**는 특정 시간대에 할당된 후 기록이 끝날 때까지 여전히 살아있는(수집되지 않은) 메모리를 의미하며, **회색 막대(Gray bars)**는 할당되었으나 이후 가비지 컬렉션된 객체를 나타냅니다 [2, 13, 15, 16]. 특정 작업을 반복하는 동안 파란색 막대가 지속적으로 축적된다면 이는 메모리 누수의 유력한 후보가 됩니다 [2, 16].
-
-* **영구 객체 식별자 및 보유 경로(Retaining Path) 추적:**
-  V8은 힙의 모든 객체에 `@` 기호가 접두사로 붙은 영구적인 고유 식별자(ID)를 부여합니다 [12, 17, 18]. 이 ID는 객체가 세대 간에 승격되거나 압축(Compaction) 중 페이지 간에 이동하더라도 일정하게 유지되므로 여러 스냅샷에 걸쳐 동일 객체의 상태를 정확히 비교할 수 있습니다 [12, 18]. 할당 타임라인 로그에서 누수 객체를 식별한 후에는 DevTools의 'Retainers' 패널이나 `%DebugTrackRetainingPath(object)` 내부 함수를 사용하여 GC 루트(Root)로 거슬러 올라가는 참조 체인(Retaining Path)을 추적함으로써 메모리가 해제되지 않는 근본 원인을 파악할 수 있습니다 [19-22].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[가비지 컬렉션(Garbage Collection)]], [[V8 힙 공간(V8 Heap Spaces)]], [[메모리 누수(Memory Leak)]], [[힙 스냅샷(Heap Snapshot)]]
-- **Projects/Contexts:** [[Chrome DevTools 메모리 프로파일링]], [[Node.js 성능 최적화 및 디버깅]]
-- **Contradictions/Notes:** 소스에 관련 정보가 부족합니다. (본 주제에 관하여 제공된 소스들 내에서 명시적인 주장 대립이나 모순점은 발견되지 않았습니다.)
-
----
-*Last updated: 2026-04-19*
-- Raw Source: [[00_Raw/2026-04-20/브라우저 메모리 할당 시점별 힙(Heap) 동작 상세 로그.md]]
----
diff --git a/Programming & Language/브라우저 및 Nodejs 메모리 튜닝.md b/Programming & Language/브라우저 및 Nodejs 메모리 튜닝.md
deleted file mode 100644
index 1aa44e8e..00000000
--- a/Programming & Language/브라우저 및 Nodejs 메모리 튜닝.md	
+++ /dev/null
@@ -1,40 +0,0 @@
----
-id: P-REINFORCE-AUTO-D511AE
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - 브라우저 및 Nodejs 메모리 튜닝"
----
-
-# [[브라우저 및 Nodejs 메모리 튜닝]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 브라우저와 Node.js의 메모리 튜닝은 V8 엔진의 메모리 사용량을 모니터링하고 가비지 컬렉션(GC)을 최적화하며, 메모리 누수를 해결하는 과정이다 [1, 2]. 애플리케이션의 메모리가 해제되지 않고 누적되는 현상을 탐지하기 위해 힙 스냅샷(Heap snapshot)과 타임라인 할당 추적(Allocation timeline) 등의 도구를 활용하여 원인을 분석한다 [3-6]. 또한 커맨드라인 플래그를 통한 힙 메모리 크기 조정과 V8의 세대별(Generational) 메모리 관리 구조를 깊이 이해함으로써 Out-Of-Memory (OOM) 크래시를 방지하고 성능을 극대화할 수 있다 [2, 7, 8].
-
-## 📖 구조화된 지식 (Synthesized Content)
-- **V8 엔진의 메모리 구조 및 가비지 컬렉션(GC):** 
-  V8 메모리는 정적 데이터와 실행 프레임을 저장하는 스택(Stack)과 동적 객체를 저장하는 힙(Heap)으로 나뉜다 [2, 9, 10]. 힙은 다시 생성된 지 얼마 안 된 객체들이 할당되는 'New Space'(Young Generation)와 이곳에서 여러 번의 GC를 거쳐 살아남은 객체들이 이동하는 'Old Space' 등으로 구성된다 [11-13]. 가비지 컬렉션은 Minor GC(Scavenger)와 Major GC(Mark-Sweep-Compact) 두 가지로 작동한다 [12, 14-17]. 최근 도입된 Orinoco 가비지 컬렉터는 메인 스레드 멈춤(Stop-the-world) 현상을 최소화하기 위해 병렬(Parallel), 점진적(Incremental), 동시(Concurrent) 스위핑 및 마킹 기법을 결합하여 처리한다 [18-20].
-
-- **Node.js 메모리 모니터링 및 튜닝 플래그:** 
-  코드 내에서 `process.memoryUsage()`를 호출하면 rss, heapTotal, heapUsed, external 등의 세부 메모리 점유 상태를 파악할 수 있다 [21]. Node.js 실행 시 여러 커맨드라인 플래그를 통해 메모리 한계를 직접 튜닝할 수 있는데, `--max-old-space-size`를 사용하면 오래 지속되는 객체가 저장되는 Old Space의 최대 크기를 늘려 대용량 데이터 처리 시 OOM을 방지할 수 있으며, `--max-semi-space-size`를 이용해 New Space 크기를 조절하여 GC 발생 빈도를 늦출 수 있다 [7, 22, 23]. `--trace-gc` 플래그를 설정하면 GC 발생 원인, 소요 시간, GC 수행 전후의 상세한 메모리 증감 상태를 콘솔에서 확인할 수 있다 [24-26].
-
-- **메모리 누수 탐지 도구 및 기법:** 
-  메모리 누수는 가비지 컬렉트되어야 할 대상이 클로저나 전역 객체, 타이머 등에 의해 참조(Reference)를 계속 유지할 때 발생한다 [3]. 이를 탐지하는 가장 신뢰할 수 있는 방법은 '3-스냅샷 기법(Three-snapshot technique)'으로, 누수 의심 동작 전후의 스냅샷들을 서로 비교하여 임시 할당된 객체를 필터링하고 지속적으로 해제되지 않는 객체만을 찾아내는 것이다 [27]. Chrome DevTools의 Memory 패널을 이용하면 힙 스냅샷(Heap snapshot)과 타임라인상 메모리 할당(Allocation instrumentation on timeline) 도구를 통해 누수 객체의 생성 위치 및 참조를 쥐고 있는 경로(Retainer tree)를 추적할 수 있다 [4-6, 28-30]. Node.js 프로덕션 환경의 경우 `--inspect` 플래그나 `heapdump`, `clinic.js` 등의 도구와 결합해 힙 프로파일을 추출하여 디버깅한다 [31-34].
-
-- **일반적인 메모리 누수 패턴:** 
-  최신 프론트엔드 및 Node.js 애플리케이션의 7대 주요 누수 패턴으로는 화면에서 제거된 후에도 JavaScript 변수에 묶여있는 DOM 노드(Detached DOM nodes) [35, 36], 무한정 커지는 인메모리 캐시 [37], 삭제되지 않은 이벤트 리스너(Event Listener Accumulation) [34, 38], 정리되지 않은 setInterval 등의 타이머 및 옵저버 [37, 39, 40], 클로저(Closure) 내부 변수의 과도한 수명 연장 현상 등이 있다 [37, 38].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** `[[V8 Engine Heap Architecture]]`, `[[Orinoco Garbage Collector]]`, `[[Heap Snapshot & Allocation Timeline]]`, `[[Generational GC Hypothesis]]`
-- **Projects/Contexts:** `[[Node.js Production Monitoring]]`, `[[Chrome DevTools Profiling]]`, `[[Electron Memory Cage]]`
-- **Contradictions/Notes:** 가비지 컬렉션 시 살아남은 객체를 새로운 메모리 페이지로 복사(Copy)하는 방식은 비용이 크게 느껴질 수 있으나, 소스에 따르면 '대부분의 객체는 매우 짧은 시간 안에 버려진다(Generational Hypothesis)'는 통계적 근거 덕분에, 적은 수의 생존 객체만 복사하는 것이 전체 메모리 스캔 비용보다 훨씬 저렴하여 성능 상 이점이 크다고 설명한다 [41]. 또한, 포인터 압축(Pointer Compression) 기술은 메모리 사용량을 대폭 절감하지만, V8 힙을 최대 4GB로 제한하는 구조적 한계를 낳아 Electron과 같은 특수 환경에서 큰 ArrayBuffer를 다루는 네이티브 모듈에 리팩토링 부담을 주는 트레이드오프가 있다 [42-45].
-
----
-*Last updated: 2026-04-19*
-- Raw Source: [[00_Raw/2026-04-20/브라우저 및 Node.js 메모리 튜닝.md]]
----
diff --git a/Programming & Language/브랜디드 타입 (Branded Types).md b/Programming & Language/브랜디드 타입 (Branded Types).md
deleted file mode 100644
index c5252055..00000000
--- a/Programming & Language/브랜디드 타입 (Branded Types).md	
+++ /dev/null
@@ -1,46 +0,0 @@
----
-id: P-REINFORCE-AUTO-2095A1
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - 브랜디드 타입 (Branded Types)"
----
-
-# [[브랜디드 타입 (Branded Types)]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 브랜디드 타입(Branded Types) 또는 오파크 타입(Opaque Types)은 TypeScript의 구조적 타이핑(Structural Typing) 시스템 내에서 발생할 수 있는 의미론적 오류를 방지하기 위해 사용되는 디자인 패턴이다 [1, 2]. 컴파일 시점에만 존재하는 고유한 가상 속성이나 심볼을 타입에 부여하여, 런타임 구조가 동일한 타입이라도 명목적 타이핑(Nominal Typing) 효과를 내며 엄격히 구분되도록 강제한다 [2-4]. 이를 통해 사용자 ID와 주문 ID처럼 형태는 같지만 의미가 전혀 다른 데이터의 혼용을 막고, 시스템 내 데이터의 무결성을 안전하게 보호한다 [4-6].
-
-## 📖 구조화된 지식 (Synthesized Content)
-* **구조적 타이핑의 한계와 '기본 타입 집착(Primitive Obsession)'**
-  TypeScript는 구조(형태)가 동일하면 서로 호환되는 것으로 간주하는 구조적 타이핑을 채택하고 있다 [1, 7]. 이로 인해 문자열(string)이나 숫자(number)와 같은 기본 타입을 사용할 때, 이메일 주소, ID, 다른 통화 단위 등 완전히 별개의 용도를 가진 데이터들이 서로 오류 없이 교체 할당될 수 있는 '기본 타입에의 집착(Primitive Obsession)' 문제를 유발하며 컴파일러가 이를 잡아내지 못한다 [3, 4, 8, 9].
-
-* **브랜디드 타입의 구현 원리**
-  이러한 한계를 극복하기 위해, 런타임에는 존재하지 않는 특수한 가상 속성(예: `__brand` 또는 `__type`)을 타입에 교집합(`&`)으로 묶어 선언한다 [2, 10]. 특히 `unique symbol`을 활용하여 브랜드 속성을 정의하면, 타입의 브랜드가 전역적으로 고유해지므로 다른 모듈 간에도 우연한 타입 혼용을 철저히 차단할 수 있다 [4, 6]. 
-
-* **브랜드의 강도 (Brand Strength)**
-  설계 목적에 따라 브랜디드 타입은 격리 수준을 조정할 수 있다 [4].
-  * **Weak Brand**: `type T = string & { __brand: 'T' }` 형태로 정의되며, 기본 타입으로의 암시적 변환은 허용하지만 엄격함은 상대적으로 떨어진다 [4, 11].
-  * **Strong Brand**: `type T = (string & { __brand: 'T' }) | { __brand: 'T' }` 형태로 구성되며, 명시적인 캐스팅 없이는 기본 타입과 호환되지 않아 높은 격리 수준을 보장한다 [4, 11, 12].
-  * **Super Brand**: 기본 타입을 포함하지 않고 오직 가상의 속성만으로 구성하여 외부 기본 타입으로의 유출이나 호환성을 매우 엄격하게 차단한다 [4, 12, 13].
-
-* **값의 할당과 런타임 검증**
-  브랜디드 타입으로 지정된 변수에 값을 할당하기 위해서는 `as` 키워드를 사용한 타입 단언(Type Assertions)을 통해 타입 시스템에 의도를 알려야 한다 [14]. 그러나 단순 단언은 부정확한 값 주입에 취약하므로, 타입 가드(Type Predicates)나 단언 함수(Assertion Functions)를 작성해 런타임 로직으로 데이터를 검증한 후 브랜디드 타입으로 확정하는 방식이 더 안전하다 [15-17]. Zod와 같은 런타임 검증 라이브러리의 `.brand()` 메서드와 결합하면 "검증하지 말고 파싱하라(Parse, Don't Validate)" 철학을 구현하여 검증된 데이터만 시스템 경계 내부로 진입하게 할 수 있다 [18, 19].
-
-* **대안 및 트레이드오프**
-  브랜디드 타입은 프로그램의 안전성을 극대화하지만 동시에 코드베이스의 개념적 복잡성을 증가시키는 비용을 수반한다 [20, 21]. 따라서 단순하게 한정된 값의 집합을 나타내는 데이터라면 유니온(Unions), 열거형(Enums), 또는 템플릿 리터럴 타입(Template Literal Types) 등 언어에 이미 내장된 간단한 대체제를 사용하는 것이 유지 보수에 더 유리할 수 있다 [22-25].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[구조적 타이핑 (Structural Typing)]], [[타입 단언 (Type Assertions)]], [[타입 가드 (Type Predicates)]]
-- **Projects/Contexts:** [[도메인 주도 설계 (DDD)]], [[Zod를 활용한 런타임 데이터 파싱]]
-- **Contradictions/Notes:** 별도의 래퍼(Wrapper) 클래스를 만들어 기본 타입을 객체지향적으로 감싸는 방식도 무결성을 챙길 수 있는 대안으로 언급되나, 이는 브랜디드 타입(런타임 오버헤드가 없음)과 달리 매 생성마다 런타임 메모리와 성능 오버헤드를 유발하므로 극도의 안정성이 필요한 경우에만 제한적으로 사용해야 함을 소스는 경고하고 있습니다 [3, 26, 27].
-
----
-*Last updated: 2026-04-18*
-- Raw Source: [[00_Raw/2026-04-20/브랜디드 타입 (Branded Types).md]]
----
diff --git a/Programming & Language/브랜디드 타입(Branded Types).md b/Programming & Language/브랜디드 타입(Branded Types).md
deleted file mode 100644
index 05afc7bb..00000000
--- a/Programming & Language/브랜디드 타입(Branded Types).md	
+++ /dev/null
@@ -1,48 +0,0 @@
----
-id: P-REINFORCE-AUTO-D05100
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - 브랜디드 타입(Branded Types)"
----
-
-# [[브랜디드 타입(Branded Types)]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-* **등장 배경 및 원리**
-  타입스크립트는 객체나 값의 형태(구조)에 기반하여 호환성을 판단하는 구조적 타이핑을 사용합니다. 이는 매우 유연하지만, `string`이나 `number`와 같은 기본 타입으로 모든 것을 표현하려는 '기본 타입에의 집착(Primitive Obsession)' 문제를 야기할 수 있습니다. 브랜디드 타입은 컴파일 타임에만 존재하는 `__brand` 속성이나 `unique symbol`을 타입에 교집합으로 엮어 고유한 표식을 부여함으로써 이 문제를 해결합니다.
-
-* **주요 활용 사례**
-  * **브랜디드 문자열(Branded Strings)**: XSS 공격을 방지하기 위해 사용자 입력 문자열과 검증된(Sanitized) 문자열을 구분하거나, URL과 IP 주소를 구별할 때 사용됩니다. 특히 도메인 기반 설계(DDD)에서 데이터베이스의 서로 다른 엔티티 ID(예: `UserId`와 `OrderId`)를 엄격히 분리하여 엉뚱한 식별자가 전달되는 실수를 방지합니다.
-  * **브랜디드 숫자(Branded Numbers)**: 양수(Positive), 음수, 0이 아닌 수(NonZero)와 같이 특정한 특성을 가진 숫자를 표현하거나, USD와 EUR 같은 각기 다른 통화(Currency) 단위를 구분해 잘못된 연산을 방지하는 데 쓰입니다.
-
-* **브랜디드 값의 생성 및 검증**
-  브랜디드 타입의 가상 속성은 런타임에는 존재하지 않으므로, 값을 생성할 때 타입스크립트에게 해당 값이 브랜디드 타입임을 단언해주어야 합니다.
-  * **`as` 단언(Type Assertions)**: 빠르고 간단하지만, 잘못된 값(예: `-1 as Positive`)을 단언할 위험이 있습니다.
-  * **타입 조건자(Type Predicates) 및 타입 단언 함수(Assertion Functions)**: 런타임 유효성 검사 로직을 거친 후 올바른 경우에만 브랜디드 타입으로 취급되도록 안전하게 반환합니다.
-
-* **브랜드의 강도(Variations)**
-  * **Weak Brand** (`type T = string & { __brand: 'T' }`): 기본 타입으로의 암시적 변환은 허용되어 사용이 쉽지만, 엄격함은 상대적으로 떨어집니다.
-  * **Strong Brand** (`type T = (string & { __brand: 'T' }) | { __brand: 'T' }`): 명시적인 캐스팅 없이는 기본 타입과 호환되지 않아 더 높은 수준의 격리를 보장합니다.
-  * **Super Brand**: 외부 유출을 철저히 차단하기 위해 기본 타입과의 연관성을 끊어내고 가상의 속성만으로 구성된 가장 엄격한 타입입니다.
-
-* **생태계 및 라이브러리 지원**
-  브랜디드 패턴의 활용을 돕기 위해 `ts-brand`, `Effect TS`, `utility-types`, `taghiro` 등의 다양한 커뮤니티 라이브러리가 존재합니다. 또한 런타임 유효성 검사 라이브러리인 `Zod`의 `.brand()` 메서드와 결합하여 사용할 경우, 런타임 검증과 컴파일 타임의 브랜디드 타입을 완벽하게 연동할 수 있습니다.
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[구조적 타이핑(Structural Typing)]], [[명목적 타이핑(Nominal Typing)]], [[기본 타입에의 집착(Primitive Obsession)]], [[타입 조건자(Type Predicates)]]
-- **Projects/Contexts:** [[도메인 기반 설계(DDD)의 식별자 분리]], [[Zod 런타임 유효성 검사 통합]], [[Effect TS 및 ts-brand 라이브러리 활용]]
-- **Contradictions/Notes:** 브랜디드 타입은 훌륭한 타입 안정성을 제공하지만, 코드의 개념적 복잡성을 증가시킨다는 단점이 있습니다. 소스 자료에서는 브랜디드 타입을 무분별하게 도입하기 전에 유니온(Unions) 타입, 열거형(Enums), 템플릿 리터럴 타입(Template Literal Types)과 같은 더 단순한 대안으로 문제를 해결할 수 있는지 먼저 고려할 것을 권장합니다. 또한, 서로 다른 브랜디드 숫자 타입 간의 이항 연산(더하기 등)을 수행할 때는 타입 에러가 발생하지 않으므로 사용 시 주의가 필요합니다.
-
----
-*Last updated: 2026-04-18*
-- Raw Source: [[00_Raw/2026-04-20/브랜디드 타입(Branded Types).md]]
----
diff --git a/Programming & Language/브랜디드 타입.md b/Programming & Language/브랜디드 타입.md
deleted file mode 100644
index efceb0cd..00000000
--- a/Programming & Language/브랜디드 타입.md	
+++ /dev/null
@@ -1,39 +0,0 @@
----
-id: P-REINFORCE-AUTO-94A8AB
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - 브랜디드 타입"
----
-
-# [[브랜디드 타입]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-* **등장 배경 및 동작 원리**: TypeScript의 타입 시스템은 객체의 형태가 같으면 호환을 허용하는 구조적 타이핑(덕 타이핑)을 따르기 때문에, 완전히 다른 맥락의 원시 데이터(예: 이메일과 이름)가 혼용되는 실수를 잡기 어렵습니다 [5, 6]. 이를 막기 위해 컴파일 타임에만 존재하는 고유 속성(`__brand`, `unique symbol` 등)을 원래의 타입과 교집합(`&`)으로 묶어 비구조적(명목적) 타입 매칭과 유사한 효과를 얻습니다 [3, 7, 8].
-* **주요 활용 사례**:
-    * **수치 데이터 보호**: 일반 `number` 타입 대신, 양수만 허용하거나 특정 통화(EUR, GBP 등), 0에서 1 사이의 퍼센트 값만을 허용하는 브랜디드 타입을 선언하여 논리적 오류를 방지합니다 [9-11].
-    * **문자열 제약 및 식별자**: XSS 공격을 방지하기 위해 검증이 완료된 문자열(Sanitized String)을 명시하거나, 데이터베이스의 여러 식별자(UserId, OrderId, CommentId 등)가 서로 잘못 할당되는 것을 막을 때 사용됩니다 [5, 12-14].
-* **생성과 브랜드 강도**:
-    * 타입 단언(`as`), 타입 가드(Type Predicates), 단언 함수(Assertion Functions) 등을 통해 런타임 검증 로직을 거친 후 일반 값을 브랜디드 타입으로 변환할 수 있습니다 [8, 15, 16].
-    * `unique symbol`을 사용해 브랜드를 정의하면 모듈 간에도 고유성이 보장됩니다 [3]. 구현 방식에 따라 약한 브랜드(기본 타입으로 암시적 변환 허용), 강한 브랜드(명시적 캐스팅 필수), 슈퍼 브랜드(외부로의 변환 철저히 차단)로 분류하여 적용할 수 있습니다 [5, 17, 18].
-* **라이브러리와의 통합 및 대안**:
-    * `ts-brand`, `Effect TS` 같은 커뮤니티 라이브러리를 통해 브랜디드 타입 생성을 자동화하거나 유틸리티 함수를 사용할 수 있습니다 [19, 20]. 또한, 런타임 유효성 검사 라이브러리인 `Zod`는 `.brand()` 메서드를 지원하여 런타임 검증과 컴파일 타임의 브랜디드 타입을 통합할 수 있게 돕습니다 [21].
-    * 브랜디드 타입은 시스템 복잡성을 증가시킬 수 있으므로, 제한된 값의 목록을 다룰 때는 유니온(Union) 타입, 열거형(Enum), 또는 템플릿 리터럴 타입 같은 대안이 더 적절할 수 있습니다 [22-25].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[구조적 타이핑]], [[명목적 타이핑]], [[Opaque Types]]
-- **Projects/Contexts:** [[도메인 기반 설계(DDD)]], [[런타임 유효성 검사(Zod)]]
-- **Contradictions/Notes:** TypeScript에서 공식적으로 브랜디드 타입(명목적 타이핑)을 내장 기능으로 지원하지는 않으며, 개발자가 `&` 연산자와 가상 속성을 이용해 우회적으로 구현하는 방식입니다 [6, 8]. 또한, 이 기법은 코드의 정밀성을 높여주지만 복잡성 역시 증가시키므로, 실제 이점이 단점을 상회하는지 신중히 판단하고 대안(예: 단순 Union이나 Enum)을 사용하는 방법도 함께 고려해야 합니다 [22, 26].
-
----
-*Last updated: 2026-04-18*
-- Raw Source: [[00_Raw/2026-04-20/브랜디드 타입.md]]
----
diff --git a/Programming & Language/비트 세이버 엑서게임 후유증 평가(Beat Saber Exergaming Aftereffects).md b/Programming & Language/비트 세이버 엑서게임 후유증 평가(Beat Saber Exergaming Aftereffects).md
deleted file mode 100644
index 1ef4bc01..00000000
--- a/Programming & Language/비트 세이버 엑서게임 후유증 평가(Beat Saber Exergaming Aftereffects).md	
+++ /dev/null
@@ -1,33 +0,0 @@
----
-id: P-REINFORCE-AUTO-B4568F
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - 비트 세이버 엑서게임 후유증 평가(Beat Saber Exergaming Aftereffects)"
----
-
-# [[비트 세이버 엑서게임 후유증 평가(Beat Saber Exergaming Aftereffects)]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 비트 세이버 엑서게임 후유증 평가는 인기 있는 VR 엑서게임인 '비트 세이버(Beat Saber)'를 단기(10분) 및 장기(50분) 동안 플레이한 후 시각, 인지, 그리고 자가 보고된 VR 멀미에 미치는 후유증을 조사한 연구입니다 [1]. 전반적으로 대부분의 시각 및 인지적 후유증과 멀미 증상은 VR 종료 40분 후에 기준선으로 회복되었으나, 노출 시간과 개인의 민감도에 따라 회복 정도에 개인차가 존재하는 것으로 나타났습니다 [2].
-
-## 📖 구조화된 지식 (Synthesized Content)
-- **시각적 후유증 (Visual Aftereffects):** 10분 및 50분의 VR 노출 직후 안구의 조절(accommodation) 및 폭주(convergence) 기능에 유의미한 변화가 발생했습니다 [2]. 이는 HMD 환경에서 흔히 발생하는 조절-폭주 불일치(vergence-accommodation conflict)와 관련된 현상으로 보이나, VR 종료 40분 후에는 두 측정치 모두 기준선 수준으로 회복되어 시각적 후유증이 단기적임을 시사합니다 [3].
-- **인지적 후유증 (Cognitive Aftereffects):** 의사 결정 속도와 이동 속도를 측정한 반응 시간 인지 평가(CANTAB 5-choice RTI) 결과, 우려할 만한 인지적 저하 요소는 발견되지 않았습니다 [4, 5]. 오히려 10분간 게임을 플레이한 직후에는 참가자들의 이동 속도가 기준선 측정치보다 약간 더 빨라지는 긍정적인 현상이 관찰되기도 했습니다 [5].
-- **VR 멀미 및 주관적 웰빙 (VR Sickness):** 시뮬레이터 멀미 설문지(SSQ) 총점은 VR 노출 직후 확연히 증가했으며, 10분 노출보다 50분 노출 시 유의미하게 더 높았습니다 [2, 6]. 
-- **회복의 개인차와 안전 지침:** 그룹 평균 통계로는 40분 후 멀미 증상이 기준선으로 돌아왔으나, 개별 수준에서는 50분 플레이 참가자의 약 14%가 40분 후에도 여전히 높은 수준의 멀미 상태를 보고했습니다 [2, 7]. 단기 노출에서 심한 멀미를 겪은 사용자는 장기 노출에서도 심한 증상을 겪을 가능성이 높으므로, 장기 노출 전 짧은 세션으로 테스트를 거치고 VR 종료 후 부상 위험이 있는 활동(예: 운전)을 하기 전 40분 이상의 충분한 대기 시간을 가질 것이 권장됩니다 [2, 8, 9].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[VR 멀미 (VR Sickness)]], [[조절-폭주 불일치 (Vergence-Accommodation Conflict)]]
-- **Projects/Contexts:** [[HMD(Head-Mounted Display) 기반 엑서게임 환경]]
-- **Contradictions/Notes:** 소스에 따르면 그룹 전체의 평균을 냈을 때는 VR 종료 40분 후 멀미 증상이 기준선으로 회복된 것으로 나타나 문제없어 보이지만, 개별 데이터를 살펴보면 50분 플레이어의 약 14%는 여전히 높은 수준의 멀미를 경험하고 있어 그룹 평균이 개인의 후유증 지속성을 완벽히 대변하지는 못한다는 한계를 지적합니다 [7].
-
----
-*Last updated: 2026-04-19*
-- Raw Source: [[00_Raw/2026-04-20/비트 세이버 엑서게임 후유증 평가(Beat Saber Exergaming Aftereffects).md]]
----
diff --git a/Programming & Language/비트 세이버(Beat Saber) VR 엑서게임 연구.md b/Programming & Language/비트 세이버(Beat Saber) VR 엑서게임 연구.md
deleted file mode 100644
index 2569fac8..00000000
--- a/Programming & Language/비트 세이버(Beat Saber) VR 엑서게임 연구.md	
+++ /dev/null
@@ -1,43 +0,0 @@
----
-id: P-REINFORCE-AUTO-6BEB16
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - 비트 세이버(Beat Saber) VR 엑서게임 연구"
----
-
-# [[비트 세이버(Beat Saber) VR 엑서게임 연구]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-- **VR 엑서게임과 비트 세이버의 이점:**
-  엑서게임은 아동과 성인 모두의 좌식 행동을 줄이고 신체 활동을 장려하는 유효한 수단입니다 [2]. 특히 '비트 세이버'와 같은 VR 엑서게임은 사실적인 3D 환경과 신체 추적 기능을 제공하여 사용자가 게임의 목표와 서사에 깊이 몰입하게 하고, 운동으로 인한 신체적 피로를 분산시키는 장점이 있습니다 [3]. 가상 현실 연구소(VR Health Institute)의 평가에 따르면, 비트 세이버 플레이 시 소모되는 에너지는 현실 세계에서 테니스를 치는 것과 유사한 수준입니다 [1].
-
-- **시각적 및 인지적 후유증 (Vision & Cognition):**
-  36명의 참가자를 대상으로 HTC Vive Pro HMD를 사용하여 연구를 진행한 결과, 시각의 조절(Accommodation)과 수렴(Convergence) 지표는 VR 플레이 직후에 변화를 보였습니다 [5, 8, 9]. 하지만 노출 시간(10분 또는 50분)에 관계없이 40분의 휴식 후에는 기준치로 회복되었습니다 [5]. 인지적인 측면에서는 의사 결정 속도 등 반응 시간에 부정적인 영향이나 우려 사항이 나타나지 않았으며, 오히려 10분 노출 직후에는 운동 속도(Movement speed)가 약간 빨라지기도 했습니다 [10]. 
-
-- **노출 시간에 따른 VR 멀미 발생 (VR Sickness):**
-  시뮬레이터 멀미 설문지(SSQ)로 측정한 결과, 참가자들의 VR 멀미 증상(메스꺼움, 안구 운동 장애, 방향 감각 상실 등)은 게임 플레이 직후 유의미하게 상승했습니다 [11]. 특히 50분(긴 시간) 동안 노출된 경우, 10분(짧은 시간) 노출에 비해 플레이 직후 더 심각한 멀미 증상을 겪었습니다 [11]. 
-
-- **증상 회복과 멀미 예측:**
-  집단 평균적으로는 40분 후에 모든 증상이 기준치로 돌아왔으나, 개별적으로 보면 50분 플레이 후 40분이 지난 늦은 시점(Late test period)에서도 약 14%(7명 중 1명 꼴)의 참가자는 여전히 심각한 멀미 수준을 보고했습니다 [6]. 또한 짧은 노출(10분) 후에 높은 수준의 멀미를 경험한 참가자는 긴 노출(50분)을 할 경우에도 비슷한 수준이거나 더 나쁜 증상을 경험할 가능성이 높았습니다 [12].
-
-- **안전한 사용을 위한 권고:**
-  본 연구는 VR로 인해 유발된 멀미 증상이 심각할 경우 사용자의 일상 활동에 지장을 줄 수 있음을 시사합니다 [6]. 따라서 장시간 VR 노출에 앞서 짧은 세션을 미리 시도하여 멀미 민감도를 확인할 것이 권장됩니다 [7]. 또한, VR 종료 후 운전과 같이 부상 위험이 있는 활동을 재개하기 전에는 멀미 증상이 가라앉을 수 있도록 통상 40분 이상의 충분한 대기 시간을 갖는 것이 필요합니다 [7].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[VR 멀미(VR sickness)]], [[엑서게임(Exergaming)]], [[시뮬레이터 멀미 설문지(SSQ)]], [[몰입(Flow)]], [[수렴-조절 불일치(Vergence-accommodation conflict)]]
-- **Projects/Contexts:** [[비트 세이버 VR 엑서게임 후유증 실험]]
-- **Contradictions/Notes:** 소스는 집단 평균적으로 볼 때 VR 종료 40분 후 멀미 증상이 기저치로 돌아온다고 밝히고 있지만, 개별 데이터에서는 50분 노출자 중 약 14%가 40분 후에도 여전히 심각한 수준의 멀미(High SSQ score)를 겪었다고 모순된 양상을 지적합니다. 따라서 그룹 평균 회복력이 모든 개인의 안전을 보장하는 지표로 쓰일 수는 없음에 주의해야 합니다 [6].
-
----
-*Last updated: 2026-04-19*
-- Raw Source: [[00_Raw/2026-04-20/비트 세이버(Beat Saber) VR 엑서게임 연구.md]]
----
diff --git a/Programming & Language/비트 세이버(Beat Saber) 실험.md b/Programming & Language/비트 세이버(Beat Saber) 실험.md
deleted file mode 100644
index 27608f70..00000000
--- a/Programming & Language/비트 세이버(Beat Saber) 실험.md	
+++ /dev/null
@@ -1,34 +0,0 @@
----
-id: P-REINFORCE-AUTO-A4020A
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - 비트 세이버(Beat Saber) 실험"
----
-
-# [[비트 세이버(Beat Saber) 실험]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 비트 세이버(Beat Saber) 실험은 널리 알려진 가상현실(VR) 엑서게임(exergame)인 '비트 세이버'를 활용하여 VR 노출 시간이 사용자의 시각, 인지 및 사이버스멀미(VR sickness)에 미치는 후유증을 조사한 연구입니다 [1]. 36명의 참가자를 대상으로 10분(단기) 및 50분(장기) 동안 게임을 플레이하게 한 후, VR 사용 전, 직후, 그리고 40분 후의 상태 변화를 측정했습니다 [1]. 이 실험은 VR 엑서게임의 잠재적 이점을 고려할 때 지속적인 사용을 제한하는 부작용을 식별하고 안전한 사용 환경을 이해하는 데 중점을 두었습니다 [1].
-
-## 📖 구조화된 지식 (Synthesized Content)
-- **실험 목적 및 배경:** 실세계의 테니스와 맞먹는 신체적 활동량을 요구하는 인기 VR 엑서게임 '비트 세이버'를 10분 및 50분 동안 플레이했을 때 사용자의 웰빙, 시각, 인지 측면에 미치는 후유증(aftereffects)을 평가하기 위해 설계되었습니다 [1], [2].
-- **연구 방법:** HTC Vive Pro HMD를 사용하여 36명의 참가자(남성 21명, 여성 15명)를 대상으로 반복 측정 개체 내 설계(repeated measures within-subject design)를 적용했습니다 [1], [3], [4]. VR 노출 전, 노출 직후, 그리고 노출 종료 40분 후의 세 시점에서 시각적 요인(조절 및 폭주), 인지적 요인(결정 속도, 이동 속도), 시뮬레이터 멀미 설문지(SSQ)를 통한 주관적 멀미 증상을 측정했습니다 [1], [2].
-- **시각 및 인지 기능 변화:** 단기(10분) 및 장기(50분) 노출 직후 시각의 조절(accommodation) 및 폭주(convergence) 능력에 변화가 관찰되었으나, 40분 후의 후기 검사에서는 모두 기준치(baseline)로 회복되었습니다 [5], [6], [7]. 인지 측정(결정 및 이동 속도)에서는 우려할 만한 저하가 나타나지 않았으며, 오히려 10분 노출 직후에는 이동 속도가 약간 향상되는 양상을 보였습니다 [5], [8].
-- **사이버스멀미 증상 및 회복:** 멀미로 인한 중도 포기자가 발생하지 않아 비트 세이버는 전반적으로 잘 수용된 것으로 나타났습니다 [5], [9]. SSQ(시뮬레이터 멀미 설문지) 점수는 VR 체험 직후에 상승했고 50분 노출이 10분 노출보다 유의미하게 더 높은 증상을 유발했으나, 그룹 평균적으로는 40분 후에 기준치로 회복되었습니다 [5], [10].
-- **개인별 멀미 지속 차이:** 그룹의 평균적인 회복세와는 달리, 50분 플레이 후 40분이 지난 시점에서도 참가자의 약 14%는 여전히 높은 수준의 멀미 증상을 보고했습니다 [5], [11]. 또한, 짧은 노출(10분)에서 심한 멀미를 경험한 참가자는 긴 노출(50분)에서도 높은 증상을 겪을 가능성이 매우 큰 것으로 확인되었습니다 [5].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[사이버스멀미(VR Sickness)]], [[엑서게임(Exergaming)]], [[시뮬레이터 멀미 설문지(SSQ)]]
-- **Projects/Contexts:** [[가상현실 엑서게임 후유증 조사(Investigation of Virtual Reality Aftereffects)]]
-- **Contradictions/Notes:** 연구 결과에서 그룹 평균적으로는 50분간의 VR 노출 후 40분이 지나면 멀미 증상이 기준치로 돌아온다고 보고하지만, 개별 참가자 데이터를 분석하면 약 14%의 인원은 40분 후에도 여전히 높은 수준의 멀미를 경험한다는 점에서 그룹 평균과 개인별 회복 양상 간에 뚜렷한 차이가 존재함을 지적합니다 [5], [10], [11].
-
----
-*Last updated: 2026-04-19*
-- Raw Source: [[00_Raw/2026-04-20/비트 세이버(Beat Saber) 실험.md]]
----
diff --git a/Programming & Language/비트 세이버(Beat Saber) 엑서게임 연구.md b/Programming & Language/비트 세이버(Beat Saber) 엑서게임 연구.md
deleted file mode 100644
index 1edc0908..00000000
--- a/Programming & Language/비트 세이버(Beat Saber) 엑서게임 연구.md	
+++ /dev/null
@@ -1,34 +0,0 @@
----
-id: P-REINFORCE-AUTO-1C6F5C
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - 비트 세이버(Beat Saber) 엑서게임 연구"
----
-
-# [[비트 세이버(Beat Saber) 엑서게임 연구]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 이 연구는 전 세계적으로 인기 있는 가상현실(VR) 엑서게임인 '비트 세이버(Beat Saber)'를 플레이한 후 사용자에게 나타나는 시각적, 인지적, 신체적 사후 영향(Aftereffects)을 조사한 결과입니다 [1, 2]. 참가자들이 10분(단기) 및 50분(장기) 동안 게임을 플레이한 후 조절력, 수렴력, 인지 반응 속도, VR 멀미 수준이 어떻게 변화하는지 측정했습니다 [3]. 연구 결과 게임 플레이로 인한 대부분의 부작용은 일시적이었으나, 장시간 플레이할 경우 VR 멀미 증상이 유의미하게 증가하며 일부 사용자는 회복에 긴 시간이 필요한 것으로 나타났습니다 [4].
-
-## 📖 구조화된 지식 (Synthesized Content)
-- **연구 배경 및 목적:** VR 엑서게임은 사용자가 신체적 노력보다 게임의 몰입형 환경에 주의를 돌리게 하여 좌식 행동(sedentary behavior)을 개선하고 운동 동기를 부여하는 강력한 도구입니다 [5, 6]. 비트 세이버의 경우 실제 테니스를 치는 것과 맞먹는 에너지를 소비하는 것으로 알려져 있습니다 [2]. 이 연구는 비트 세이버 플레이가 시력, 인지 기능 및 자기 보고식 VR 멀미(VR sickness)에 미치는 장단기적 영향을 파악하기 위해 진행되었습니다 [2].
-- **실험 방법론:** 36명의 참가자를 대상으로 HTC Vive Pro 헤드마운트 디스플레이(HMD)를 사용하여 비트 세이버를 플레이하도록 하였습니다 [7, 8]. 시각적 조절(accommodation) 및 수렴(convergence), 인지적 결정 속도와 이동 속도(CANTAB 반응 시간 테스트), 그리고 시뮬레이터 멀미 설문지(SSQ)를 활용하여 VR 노출 전, 노출 직후, 그리고 노출 40분 후(지연 테스트)의 세 시점에서 데이터를 측정했습니다 [3, 9-12].
-- **시각 및 인지 기능에 미치는 영향:** VR 노출 직후 안구의 조절력과 수렴력에 뚜렷한 변화가 관찰되었으나, 40분이 지난 후에는 모두 기준치(baseline) 수준으로 회복되었습니다 [4]. 인지 기능인 반응 시간 측정에서는 우려할 만한 저하가 관찰되지 않았으며, 10분 플레이 직후에는 오히려 이동 속도가 소폭 향상되는 현상도 확인되었습니다 [4, 13]. 
-- **VR 멀미(VR Sickness) 발생 및 회복:** SSQ를 통해 측정한 멀미 점수는 게임 직후 급격히 상승했으며, 특히 10분 노출보다 50분 노출에서 그 수치가 통계적으로 유의하게 더 높았습니다 [4, 14]. 집단 평균적으로는 40분 대기 후 멀미 수치가 원래대로 돌아왔으나, 50분을 플레이한 참가자의 약 14%는 40분이 지나서도 여전히 높은 수준의 멀미 증상을 호소했습니다 [4, 15]. 
-- **안전 권고 사항:** 연구진은 긴 시간 엑서게임에 노출되기 전에 사용자가 짧은 세션을 먼저 시도하여 멀미 민감도를 확인할 것을 권장합니다 [16]. 또한, VR 노출 후에는 자동차 운전과 같이 부상 위험이 따르는 활동을 재개하기 전 최소 40분 이상의 휴식 및 대기 시간을 가져야 한다고 조언합니다 [16].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[VR 멀미(VR Sickness)]], [[엑서게임(Exergaming)]], [[시뮬레이터 멀미 설문지(SSQ)]]
-- **Projects/Contexts:** [[비트 세이버(Beat Saber) VR 사후 영향 조사 연구]]
-- **Contradictions/Notes:** 연구 결과에서 엑서게임 직후의 멀미 증상은 그룹 평균치로 보았을 때 40분 이내에 완전히 회복되는 것으로 나타났으나, 개인차를 고려할 때 50분 장기 플레이를 한 참가자의 약 14%는 40분 후에도 회복되지 않은 높은 수준의 증상을 보인다는 점을 유의해야 합니다 [15].
-
----
-*Last updated: 2026-04-19*
-- Raw Source: [[00_Raw/2026-04-20/비트 세이버(Beat Saber) 엑서게임 연구.md]]
----
diff --git a/Programming & Language/비트 세이버(Beat Saber).md b/Programming & Language/비트 세이버(Beat Saber).md
deleted file mode 100644
index 15e180d6..00000000
--- a/Programming & Language/비트 세이버(Beat Saber).md	
+++ /dev/null
@@ -1,32 +0,0 @@
----
-id: P-REINFORCE-AUTO-4E9962
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - 비트 세이버(Beat Saber)"
----
-
-# [[비트 세이버(Beat Saber)]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 비트 세이버(Beat Saber)는 비트 게임즈(Beat Games)에서 개발한 상업용 가상 현실(VR) 리듬 운동 게임(exergame)으로, 전 세계적으로 200만 장 이상 판매된 가장 성공적인 게임 중 하나입니다 [1, 2]. 이 게임은 모션 트래킹 기술을 활용하여 핸드헬드 컨트롤러를 광선검처럼 시뮬레이션하며, 사용자는 음악의 비트에 맞춰 날아오는 목표물을 베고 장애물을 적극적으로 피해야 합니다 [2]. 또한 햅틱, 청각 및 성과 피드백을 결합하여 높은 몰입감을 선사하며, 실제 테니스를 치는 것과 비슷한 수준의 에너지를 소모하게 하는 특징이 있습니다 [1, 2].
-
-## 📖 구조화된 지식 (Synthesized Content)
-- **가상 현실 후유증(VR Aftereffects) 및 멀미 연구**: 비트 세이버는 방대한 사용자 기반을 갖추고 있으며 역동적이고 즐거운 경험을 제공하기 때문에, 장단기 VR 노출이 사용자에게 미치는 후유증을 연구하는 데 강력한 테스트 사례로 사용됩니다 [1, 2]. 실제로 10분 및 50분 동안 비트 세이버를 플레이한 후 시각, 인지, 멀미에 미치는 영향을 분석한 연구에서 멀미로 인한 실험 중도 포기자가 발생하지 않아, 이 게임이 사용자들에게 신체적으로 무리 없이 잘 수용되는(well tolerated) 것으로 나타났습니다 [1, 3, 4].
-- **신체적 운동 효과 및 상호작용**: 사용자는 자신의 게임 플레이를 주도하여 원하는 곡과 난이도를 자유롭게 선택할 수 있으며, 난이도가 높아질수록 시각적 자극과 요구되는 움직임의 양도 크게 증가합니다 [5]. 가상 현실 건강 및 운동 연구소(VR Health Institute)는 비트 세이버의 에너지 소모량이 실제 테니스와 맞먹는다고 평가하였으며, 이는 주로 앉아서 생활하는 습관(sedentary behavior)을 개선할 수 있는 매력적인 운동 전략으로 간주됩니다 [1, 3].
-- **몰입 상태(Flow State)의 안정적 유도**: 비트 세이버는 사용자의 기술 수준에 맞춘 난이도 조절과 명확하고 즉각적인 피드백을 통해 몰입(Flow) 상태를 효과적으로 이끌어냅니다 [2, 6]. 이러한 특성 덕분에 신경생리학적 정밀도를 추구하는 고충실도(high-fidelity) 실험실 연구에서, 과업을 표준화하고 몰입 상태의 신경 및 자율신경계 신호를 안정적으로 유도하기 위한 통제된 단일 플레이어 게임으로 널리 활용되고 있습니다 [6].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[운동 게임(Exergame)]], [[몰입 상태(Flow State)]], [[가상 현실 멀미(VR Sickness)]]
-- **Projects/Contexts:** [[가상 현실 후유증 조사(Investigation of Virtual Reality Aftereffects)]]
-- **Contradictions/Notes:** 소스에 관련 정보가 부족합니다.
-
----
-*Last updated: 2026-04-19*
-- Raw Source: [[00_Raw/2026-04-20/비트 세이버(Beat Saber).md]]
----
diff --git a/Programming & Language/비트 세이버를 활용한 가상현실 엑서게임 후유증 연구(Exergaming With Beat Saber_ An Investigation of Virtual Reality Aftereffects).md b/Programming & Language/비트 세이버를 활용한 가상현실 엑서게임 후유증 연구(Exergaming With Beat Saber_ An Investigation of Virtual Reality Aftereffects).md
deleted file mode 100644
index da46aa80..00000000
--- a/Programming & Language/비트 세이버를 활용한 가상현실 엑서게임 후유증 연구(Exergaming With Beat Saber_ An Investigation of Virtual Reality Aftereffects).md	
+++ /dev/null
@@ -1,33 +0,0 @@
----
-id: P-REINFORCE-AUTO-F5F82B
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - 비트 세이버를 활용한 가상현실 엑서게임 후유증 연구(Exergaming With Beat Saber_ An Investigation of Virtual Reality Aftereffects)"
----
-
-# [[비트 세이버를 활용한 가상현실 엑서게임 후유증 연구(Exergaming With Beat Saber_ An Investigation of Virtual Reality Aftereffects)]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 본 연구는 인기 있는 가상현실(VR) 엑서게임인 '비트 세이버(Beat Saber)'를 단기(10분) 및 장기(50분) 동안 플레이한 후 시각, 인지 및 주관적 VR 멀미(VR sickness)에 미치는 후유증을 조사한 것입니다 [1]. 36명의 참가자를 대상으로 VR 노출 전, 노출 직후, 그리고 노출 40분 후(지연 측정)의 상태를 반복적으로 평가했습니다 [1]. 연구 결과 게임은 전반적으로 잘 수용되었으며 대부분의 후유증은 단기적이었으나, 일부 참가자들에게서는 40분 이후에도 멀미 증상이 지속되는 등 개인차가 존재함이 확인되었습니다 [2].
-
-## 📖 구조화된 지식 (Synthesized Content)
-- **시각적 영향 (Visual Measures):** VR 노출 직후 안구의 조절(Accommodation) 및 수렴(Convergence) 기능에서 유의미한 변화가 나타났으나, 10분 노출과 50분 노출 간에 그 변화의 차이는 없었습니다 [3], [4]. 이러한 시각적 변화는 VR 종료 후 40분이 지난 시점에서 기준치로 회복되어 비교적 단기적인 후유증임을 나타냈습니다 [2].
-- **인지적 영향 (Cognitive Measures):** 5선택 반응 시간 과제(CANTAB 5-choice RTI)를 사용해 의사 결정 속도와 이동 속도를 측정한 결과 우려할 만한 인지적 저하는 발견되지 않았습니다 [5], [4], [6]. 오히려 10분간 짧게 플레이한 직후에는 기준치보다 참가자들의 이동 속도가 약간 더 빨라지는 현상이 관찰되었습니다 [6].
-- **VR 멀미 (VR Sickness) 발생 및 회복:** 시뮬레이터 멀미 설문지(SSQ)로 평가한 멀미 증상은 VR 노출 직후 유의미하게 증가했으며, 특히 50분 장기 노출 시 10분 단기 노출보다 증상이 현저히 높게 나타났습니다 [2], [7]. 노출 40분 후 그룹 평균 멀미 수치는 기준치로 회복되었으나, 50분 플레이어의 약 14%(7명 중 1명 꼴)는 이 시점에서도 여전히 심한 멀미 증상을 보고했습니다 [2], [8].
-- **결론 및 안전 권장 사항:** 비트 세이버 플레이 중 멀미로 인한 중도 포기자는 없었습니다 [2], [9]. 그러나 짧은 노출(10분) 후 심한 멀미를 경험한 사람은 긴 노출(50분) 후에도 높은 확률로 심한 증상을 겪으므로, 긴 시간 플레이하기 전에 짧은 세션으로 미리 테스트해 보는 것이 권장됩니다 [2], [10]. 또한 사용자는 VR 종료 후 남아있을 수 있는 후유증이 완전히 사라질 때까지 활동(예: 운전 등)을 자제하고 충분한 대기 시간을 가져야 합니다 [10].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[가상현실 멀미(VR sickness)]], [[엑서게임(Exergaming)]], [[시뮬레이터 멀미 설문지(Simulator Sickness Questionnaire, SSQ)]], [[조절과 수렴(Accommodation and Convergence)]]
-- **Projects/Contexts:** [[Journal of Medical Internet Research (JMIR) 게재 연구]], [[비트 세이버(Beat Saber) 사용자 실험]]
-- **Contradictions/Notes:** 소스에 따르면, 그룹 전체의 통계적 평균을 기준으로 보았을 때는 VR 종료 40분 후 참가자들의 멀미 증상이 기준치 수준으로 회복된 것으로 나타납니다. 하지만 개별 데이터를 확인했을 때 50분 플레이한 참가자의 약 14%는 40분이 지난 후에도 여전히 '높은 수준'의 멀미를 경험하고 있어, 통계적 평균과 개인의 실제 회복 경험 사이에는 차이와 예외가 존재합니다 [2], [8].
-
----
-*Last updated: 2026-04-19*
-- Raw Source: [[00_Raw/2026-04-20/비트 세이버를 활용한 가상현실 엑서게임 후유증 연구(Exergaming With Beat Saber_ An Investigation of Virtual Reality Aftereffects).md]]
----
diff --git a/Programming & Language/사회 학습 이론.md b/Programming & Language/사회 학습 이론.md
deleted file mode 100644
index e8dcb4ba..00000000
--- a/Programming & Language/사회 학습 이론.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-D860B8
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - 사회 학습 이론"
----
-
-# [[사회 학습 이론]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/사회 학습 이론.md]]
----
diff --git a/Programming & Language/사회학습이론.md b/Programming & Language/사회학습이론.md
deleted file mode 100644
index a1fa5607..00000000
--- a/Programming & Language/사회학습이론.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-4EE4B7
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - 사회학습이론"
----
-
-# [[사회학습이론]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/사회학습이론.md]]
----
diff --git a/Programming & Language/상태 관리 및 API 응답 모델링(State Management and API Response Modeling).md b/Programming & Language/상태 관리 및 API 응답 모델링(State Management and API Response Modeling).md
deleted file mode 100644
index 48523436..00000000
--- a/Programming & Language/상태 관리 및 API 응답 모델링(State Management and API Response Modeling).md	
+++ /dev/null
@@ -1,34 +0,0 @@
----
-id: P-REINFORCE-AUTO-397C6D
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - 상태 관리 및 API 응답 모델링(State Management and API Response Modeling)"
----
-
-# [[상태 관리 및 API 응답 모델링(State Management and API Response Modeling)]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 상태 관리 및 API 응답 모델링은 애플리케이션의 데이터 변화 및 네트워크 통신 결과를 타입 안전하게 구조화하는 기법입니다. 주로 식별 가능한 유니온(Discriminated Unions)을 활용하여 잘못된 상태 조합을 원천 차단하고, 완전성 검사(Exhaustiveness checking)를 통해 모든 가능한 응답 및 상태 케이스를 안전하게 처리하도록 강제합니다. 이를 통해 예측 불가능한 동작을 방지하고 코드의 유지보수성을 극대화할 수 있습니다.
-
-## 📖 구조화된 지식 (Synthesized Content)
-- **식별 가능한 유니온을 활용한 상태 머신 패턴:** 애플리케이션의 상태(예: 폼의 검증 중, 제출 중, 성공, 에러 등)나 비동기 작업 패턴을 모델링할 때 식별 가능한 유니온이 핵심 도구로 사용됩니다 [1-3]. 공통된 리터럴 속성(예: `kind`, `state`, `status`)을 판별자로 사용하여 `idle`, `fetching`, `success`, `failure`와 같은 뚜렷한 상태들을 구별하며, 이는 무효한 상태(Invalid states)가 표현되는 것을 불가능하게 만듭니다 [1, 3-5].
-- **API 응답 및 예상된 에러(Expected Error) 모델링:** API 응답 또한 로딩 중(`NetworkLoadingState`), 성공(`NetworkSuccessState`), 실패(`NetworkFailedState`)로 나누어 모델링하는 것이 이상적입니다 [5]. API 통신 등에서 발생하는 '예상 가능한 에러'를 처리할 때 단순히 예외(Exception)를 던지기(throw)보다는, `Ok`와 `Err` 같은 결과(Result) 객체에 `_tag` 속성 등의 메타데이터를 포함시켜 명시적인 반환 타입으로 다루는 것이 시스템 결함 허용력(fault tolerance)과 제어 흐름 관리에 훨씬 유리합니다 [6-9].
-- **안전한 데이터 매핑과 `satisfies` 키워드:** 외부 백엔드 API에서 수신한 데이터를 프론트엔드 모델로 매핑할 때, TypeScript의 `satisfies` 키워드를 사용하면 객체 리터럴 구조에 잉여 속성이 포함되거나 오타가 발생하는 것을 엄격하게 잡아낼 수 있습니다 [10-12]. 이는 타입 캐스팅(`as`)이 놓칠 수 있는 속성 불일치 오류를 컴파일 타임에 안전하게 차단합니다 [12, 13].
-- **상태 관리 부실의 위험성:** 명확한 패턴 없이 여러 위치에서 상태가 변경되도록 방치하면, 시스템의 동작을 예측하기 어려워지고 디버깅이 극도로 힘들어집니다 [14]. 잘못된 상태 관리는 기술 부채를 가중시키고 불필요한 리렌더링이나 네트워크 요청의 중복과 같은 성능 문제까지 유발합니다 [14].
-- **완전성 검사(Exhaustiveness Checking)의 적용:** 상태나 API 응답의 유니온 타입을 `switch` 문으로 처리할 때, `never` 타입으로 도달하는 `default` 분기를 활용하면 새로운 응답 형태나 상태가 추가되었을 때 개발자가 이를 누락하지 않았는지 컴파일러가 자동으로 검사해 줍니다 [15-19].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[식별 가능한 유니온(Discriminated Unions)]], [[완전성 검사(Exhaustiveness Checking)]], [[Satisfies 연산자]]
-- **Projects/Contexts:** [[React의 상태 관리 및 비동기 UI 처리]], [[네트워크 요청 상태 머신(NetworkState)]]
-- **Contradictions/Notes:** 상태나 로직의 실패를 다룰 때 C# 등의 전통적인 환경에서는 예외(Exception)를 발생시키고 글로벌 핸들러로 잡아내는 방식이 흔히 사용되나, 상태 모델링의 명확성 관점에서는 반환형 자체에 실패 상태(Result 객체 등)를 명시하여 제어 흐름과 예상 결과를 호출자가 즉시 파악할 수 있도록 설계하는 방식(Railway oriented programming)이 더 우수하다는 주장이 존재합니다 [20-26].
-
----
-*Last updated: 2026-04-18*
-- Raw Source: [[00_Raw/2026-04-20/상태 관리 및 API 응답 모델링(State Management and API Response Modeling).md]]
----
diff --git a/Programming & Language/상태 머신(State Machine) 설계.md b/Programming & Language/상태 머신(State Machine) 설계.md
deleted file mode 100644
index b8347314..00000000
--- a/Programming & Language/상태 머신(State Machine) 설계.md	
+++ /dev/null
@@ -1,33 +0,0 @@
----
-id: P-REINFORCE-AUTO-C8AC26
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - 상태 머신(State Machine) 설계"
----
-
-# [[상태 머신(State Machine) 설계]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 상태 머신(State Machine) 설계는 시스템이 가질 수 있는 다양한 상태와 그 상태 간의 전환을 명확히 정의하는 모델링 기법입니다 [1]. TypeScript에서는 구분된 유니언(Discriminated Unions)을 활용하여 상태 머신을 완벽하게 구현하고 타입 안전성을 보장할 수 있습니다 [1, 2]. 다만, 제공된 소스에는 TypeScript 패턴으로서의 간략한 적용 사례 외에 상태 머신 설계 자체에 대한 심층적인 정보는 부족합니다.
-
-## 📖 구조화된 지식 (Synthesized Content)
-- **구분된 유니언(Discriminated Unions)의 활용**: TypeScript 환경에서 상태 머신을 구축하고 모델링하는 데 있어 구분된 유니언은 완벽하게 들어맞는 패턴입니다 [1, 2].
-- **상태(State)와 전환(Transition)의 명확한 정의**: 상태 머신은 `Idle`(유휴 상태), `Fetching`(가져오는 중), `Success`(성공), `Failure`(실패)와 같은 명확한 상태들을 모델링합니다 [1]. 또한, `FETCH_START`, `FETCH_SUCCESS`, `FETCH_FAILURE`, `RETRY`(재시도 횟수 조건 포함), `REFRESH`와 같은 특정 액션들을 통해 상태 간의 전환을 표현할 수 있습니다 [1].
-- **유효하지 않은 상태 방지**: 상태 머신 패턴을 구분된 유니언과 결합하면, 불가능하거나 유효하지 않은 상태(Invalid States)가 시스템에 나타나는 것을 구조적으로 방지할 수 있습니다 [3, 4].
-- **정보 부족 명시**: 소스에 관련 정보가 부족합니다. 상태 머신에 대한 범용적인 소프트웨어 공학적 설계 이론보다는, TypeScript의 특정 타입 패턴을 설명하기 위한 예시로만 단편적으로 등장합니다 [1, 2].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[Discriminated Unions]], [[Exhaustiveness Checking]]
-- **Projects/Contexts:** [[API Response Handling]]
-- **Contradictions/Notes:** 소스에 관련 정보가 부족합니다. 상태 머신의 일반적인 아키텍처나 다양한 설계 패턴에 대한 상세한 이론적 배경은 제공되지 않으며, 오직 TypeScript의 구분된 유니언을 이용한 상태 모델링의 맥락에서만 짧게 언급됩니다 [1, 2].
-
----
-*Last updated: 2026-04-18*
-- Raw Source: [[00_Raw/2026-04-20/상태 머신(State Machine) 설계.md]]
----
diff --git a/Programming & Language/새로운 공간(New Space).md b/Programming & Language/새로운 공간(New Space).md
deleted file mode 100644
index ca9d103d..00000000
--- a/Programming & Language/새로운 공간(New Space).md	
+++ /dev/null
@@ -1,30 +0,0 @@
----
-id: P-REINFORCE-AUTO-B1F49A
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - 새로운 공간(New Space)"
----
-
-# [[새로운 공간(New Space)]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 새로운 공간(New Space)은 V8 엔진의 힙(Heap) 메모리 구조에서 대부분의 새로운 객체가 최초로 할당되는 작고 빠른 영역입니다 [1, 2]. '젊은 세대(Young Generation)'라고도 불리며, 대부분의 객체가 생성 후 곧바로 소멸한다는 '세대 가설(Generational Hypothesis)'을 바탕으로 설계되었습니다 [3-5]. 이 공간은 다른 힙 공간들과 독립적으로 매우 빠르고 빈번하게 가비지 컬렉션(Garbage Collection)이 수행되도록 최적화되어 있습니다 [1, 6].
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[스캐빈저(Scavenger) / 마이너 GC]], [[오래된 공간(Old Space)]], [[To-Space와 From-Space]], [[쓰기 장벽(Write Barrier)]]
-- **Projects/Contexts:** [[V8 가비지 컬렉션(Garbage Collection)]], [[브라우저 메모리 관리 및 최적화]]
-- **Contradictions/Notes:** 소스 [2]에서는 새로운 공간의 크기를 휴리스틱에 따라 1~8MB로 설명하지만, 소스 [7]에서는 1~64MB로 언급합니다. 이는 V8 엔진의 버전이나 실행 환경, 동적 메모리 할당 정책에 따라 새로운 공간의 최대 한도가 다르게 적용될 수 있음을 보여줍니다.
-
----
-*Last updated: 2026-04-19*
-- Raw Source: [[00_Raw/2026-04-20/새로운 공간(New Space).md]]
----
diff --git a/Programming & Language/생물학적 학습 이론.md b/Programming & Language/생물학적 학습 이론.md
deleted file mode 100644
index 8a05acc4..00000000
--- a/Programming & Language/생물학적 학습 이론.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-A4487C
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - 생물학적 학습 이론"
----
-
-# [[생물학적 학습 이론]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/생물학적 학습 이론.md]]
----
diff --git a/Programming & Language/서드파티 라이브러리 및 API 연동.md b/Programming & Language/서드파티 라이브러리 및 API 연동.md
deleted file mode 100644
index 3d023bfe..00000000
--- a/Programming & Language/서드파티 라이브러리 및 API 연동.md	
+++ /dev/null
@@ -1,40 +0,0 @@
----
-id: P-REINFORCE-AUTO-ACB5DA
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - 서드파티 라이브러리 및 API 연동"
----
-
-# [[서드파티 라이브러리 및 API 연동]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 서드파티 라이브러리 및 API 연동은 애플리케이션이 외부 시스템, 패키지, 또는 외부 연동사의 앱과 안전하고 효율적으로 데이터를 교환하고 상호작용하도록 설계하는 과정입니다. TypeScript 생태계에서는 외부에서 유입되는 알 수 없는 데이터를 런타임 및 컴파일 타임에 검증하여 시스템 내부를 보호하는 방어적 설계가 매우 중요합니다. 또한 외부 연동사를 위해 SDK를 제공할 때는 내부의 복잡한 로직을 은닉하고 사용자의 의도에 맞춘 직관적인 인터페이스를 제공하여 구조적으로 휴먼 에러를 방지해야 합니다.
-
-## 📖 구조화된 지식 (Synthesized Content)
-* **데이터 파싱 및 런타임 검증 (Parse, Don't Validate):**
-  외부 API나 서드파티에서 들어오는 데이터는 시스템의 경계(Boundary) 지점에서 `Zod`와 같은 런타임 검증 라이브러리를 통해 잘 정의된 타입으로 파싱되어야 합니다 [1-4]. 단순한 유효성 검사를 넘어, 알 수 없는 데이터를 완전히 타입이 지정된 데이터(예: 브랜디드 타입)로 변환함으로써 시스템 내부 로직으로 신뢰할 수 있는 데이터만 유입되도록 강제해야 합니다 [4, 5].
-
-* **안전한 API 응답 처리 패턴:**
-  API 응답을 처리할 때 식별 가능한 유니온(Discriminated Unions)을 활용하면 성공, 실패, 로딩 등 다양한 응답 상태를 안전하고 빈틈없이 모델링할 수 있습니다 [6, 7]. 또한 외부 백엔드 API 데이터를 프론트엔드 모델로 매핑할 때는 `satisfies` 연산자를 활용하는 것이 좋습니다. 이를 통해 초과 속성 검사(Excess Property Checking)를 강제하여 오타나 원치 않는 잉여 데이터가 유입되는 것을 방지하면서도 구체적인 타입을 유지할 수 있습니다 [8-10].
-
-* **서드파티 연동 SDK 설계 (Facade 패턴):**
-  외부 연동사가 사용하는 SDK를 설계할 때는 퍼사드(Facade) 패턴을 적용하여 사용자의 인지 부하를 줄이고 암묵적인 의존성을 제거해야 합니다 [5, 11, 12]. 복잡한 인증, 재시도, 리소스 정리(Cleanup) 로직을 내부로 숨기고 사용자의 자연스러운 목적을 나타내는 고수준(High-level) 인터페이스를 제공하는 것이 핵심입니다 [12]. 동시에 세밀한 제어가 필요한 20%의 특수 케이스를 위해 저수준(Low-level) API를 탈출구(Escape Hatch)로 함께 제공하여 유연성을 확보해야 합니다 [13, 14].
-
-* **자동화 및 모니터링 도구 연동:**
-  OpenAPI 스펙이 정의된 API와 연동할 때는 스크립트를 통한 코드 생성(Code Generation)을 활용하여 SDK 및 스키마 타입을 자동화하는 것이 유지보수와 코드 볼륨 관리에 유리합니다 [15]. 또한 `Sentry`나 `ErrorBoundary`와 같은 서드파티 모니터링 도구를 연동하여 예외 상황이나 처리되지 않은 케이스에서 발생하는 런타임 에러를 추적 가능하게 만들어야 합니다 [16].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[Parse, Don't Validate]], [[Facade 패턴]], [[식별 가능한 유니온 (Discriminated Unions)]], [[Zod]], [[satisfies 연산자]]
-- **Projects/Contexts:** [[Toss Front SDK 연동 설계]], [[OpenAPI 스펙 기반 SDK 자동 생성]], [[Zod를 활용한 런타임 API 데이터 검증]]
-- **Contradictions/Notes:** 소스에 따르면 `ts-pattern`과 같은 패턴 매칭 및 복잡한 분기 처리용 서드파티 라이브러리는 타입 안전성에는 도움을 주지만, 내부적인 클래스 및 함수 체이닝 구현 방식으로 인해 자바스크립트의 기본 제어 구조(`if/else`, `switch`)보다 성능이 현저히 떨어질 수 있으므로 무조건적인 도입보다는 상황과 성능 요구치를 고려해 사용해야 합니다 [17-19].
-
----
-*Last updated: 2026-04-18*
-- Raw Source: [[00_Raw/2026-04-20/서드파티 라이브러리 및 API 연동.md]]
----
diff --git a/Programming & Language/서버리스 컴퓨팅(Serverless Computing).md b/Programming & Language/서버리스 컴퓨팅(Serverless Computing).md
deleted file mode 100644
index 241f9e76..00000000
--- a/Programming & Language/서버리스 컴퓨팅(Serverless Computing).md	
+++ /dev/null
@@ -1,33 +0,0 @@
----
-id: P-REINFORCE-AUTO-DE9274
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - 서버리스 컴퓨팅(Serverless Computing)"
----
-
-# [[서버리스 컴퓨팅(Serverless Computing)]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-* **서버리스 플랫폼의 작동 방식:** Google Cloud Run과 같은 서버리스 플랫폼은 개발자가 상태가 없는(Stateless) 컨테이너를 실행할 수 있게 하며, 트래픽에 기반하여 자동으로 리소스를 스케일업 하거나 0으로 스케일다운합니다 [1]. 또한, 최신 데이터 웨어하우스와 레이크하우스 아키텍처(예: Snowflake, Google BigQuery 등) 역시 서버리스 기반의 대규모 병렬 처리를 제공하여 컴퓨팅과 스토리지를 분리하고 독립적인 자원 확장을 지원합니다 [3].
-* **마이크로서비스 및 워크플로우와의 결합:** 넷플릭스의 코스모스(Cosmos) 플랫폼과 같은 시스템은 마이크로서비스의 장점을 비동기 워크플로우 및 서버리스 함수와 결합하여 사용합니다 [4]. 이 아키텍처에서 서버리스 함수(예: Stratum 계층)는 도메인별 알고리즘을 구동하며, 워크플로우 규칙에 따라 오케스트레이션되어 연산 집약적이고 상태가 없는 작업들을 수행합니다 [2, 5].
-* **확장성 및 지연 시간(Latency) 관리:** 서버리스 함수는 자체적인 바이너리 종속성을 포함한 도커(Docker) 이미지로 패키징되며, 큐의 크기에 따라 수만 개의 컨테이너에서 병렬로 실행될 수 있습니다 [2]. 서버리스 환경에서 발생하는 초기 구동 지연 시간을 줄이기 위해, 자원을 미리 요청하는 '웜 캐퍼시티(Warm capacity)', 시작 비용을 여러 번의 호출에 분산시키는 '마이크로 배치(Micro-batches)', 그리고 자원이 부족할 때 중요한 작업을 먼저 처리하는 '우선순위(Priority)' 할당 등의 전략이 활용됩니다 [6].
-* **비용 및 자원 스케줄링 최적화:** 서버리스 계층은 유연한 자원 스케줄링을 통해 처리량(Throughput)에 민감한 워크로드에 대해 "기회주의적(opportunistic)" 컴퓨팅 자원을 활용합니다. 만약 서버리스 함수가 즉각적인 처리 대신 최대 1시간 정도 대기하여 실행되어도 괜찮다면, 호출 비용을 크게 낮추는 방식으로 자원을 최적화할 수 있습니다 [7].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[클라우드 네이티브 아키텍처(Cloud-Native Architecture)]], [[마이크로서비스 아키텍처(Microservices Architecture)]], [[비동기 워크플로우(Asynchronous Workflows)]]
-- **Projects/Contexts:** [[구글 클라우드 런(Google Cloud Run)]], [[넷플릭스 코스모스(Netflix Cosmos)]]
-- **Contradictions/Notes:** 소스에 관련 정보가 부족합니다.
-
----
-*Last updated: 2026-04-18*
-- Raw Source: [[00_Raw/2026-04-20/서버리스 컴퓨팅(Serverless Computing).md]]
----
diff --git a/Programming & Language/선언 병합 (Declaration Merging).md b/Programming & Language/선언 병합 (Declaration Merging).md
deleted file mode 100644
index 24a49fe2..00000000
--- a/Programming & Language/선언 병합 (Declaration Merging).md	
+++ /dev/null
@@ -1,30 +0,0 @@
----
-id: P-REINFORCE-AUTO-6C2D93
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - 선언 병합 (Declaration Merging)"
----
-
-# [[선언 병합 (Declaration Merging)]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 선언 병합(Declaration Merging)은 TypeScript에서 동일한 이름을 가진 인터페이스를 여러 번 선언할 경우, 컴파일러가 이를 자동으로 합쳐서 하나의 인터페이스로 정의해 주는 고유한 기능입니다 [1, 2]. 이 기능은 타입 별칭(Type Alias)에는 존재하지 않으며, 주로 라이브러리 제작자가 사용자에게 타입 확장 지점을 제공하기 위해 사용됩니다 [2-4]. 그러나 의도치 않은 타입 병합으로 인한 오류 발생 가능성 때문에 프로젝트 성격에 따라 사용을 지양하는 경우도 존재합니다 [5-7].
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[인터페이스 (Interface)]], [[타입 별칭 (Type Alias)]]
-- **Projects/Contexts:** [[TypeScript 라이브러리 타입 확장]], [[철벽 수비대 인터페이스 설계 전략]]
-- **Contradictions/Notes:** 소스 [2-4]는 라이브러리 작성 시 소비자에게 타입 확장 지점을 제공한다는 측면에서 선언 병합의 강력한 유용성을 주장하지만, 소스 [5-7]은 개발자의 실수로 인한 의도치 않은 병합의 위험성을 지적하며 선언 병합 기능을 피하고 엄격한 에러를 뱉는 타입 별칭(Type Alias)을 사용하는 것이 바람직하다고 반대합니다.
-
----
-*Last updated: 2026-04-18*
-- Raw Source: [[00_Raw/2026-04-20/선언 병합 (Declaration Merging).md]]
----
diff --git a/Programming & Language/선언 파일(dts).md b/Programming & Language/선언 파일(dts).md
deleted file mode 100644
index 7e8f35e8..00000000
--- a/Programming & Language/선언 파일(dts).md	
+++ /dev/null
@@ -1,35 +0,0 @@
----
-id: P-REINFORCE-AUTO-239012
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - 선언 파일(dts)"
----
-
-# [[선언 파일(dts)]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 선언 파일(.d.ts)은 타입스크립트(TypeScript) 환경에서 자바스크립트(JavaScript) 라이브러리를 사용할 때 필요한 타입 정의를 제공하는 파일입니다 [1]. 이 파일은 실제 코드가 구현되어 있지 않으며, 순수하게 타입 정보만을 제공하는 데 목적이 있습니다 [1]. 주어진 소스에는 선언 파일의 구체적인 문법이나 심도 있는 활용법 등에 대한 정보가 전반적으로 부족합니다.
-
-## 📖 구조화된 지식 (Synthesized Content)
-소스에 관련 정보가 부족합니다. 제공된 소스에서 제한적으로 확인할 수 있는 선언 파일(.d.ts)의 핵심 내용은 다음과 같습니다:
-
-- **타입 정보의 제공:** 자바스크립트로 작성된 라이브러리를 타입스크립트 프로젝트에서 사용할 때, 해당 라이브러리가 어떤 타입을 갖는지 알려주기 위해 `.d.ts` 형태의 타입 정의가 필요합니다 [1].
-- **구현부 부재:** 선언 파일은 실제 동작하는 로직이나 구현(implementation)을 전혀 포함하지 않고, 오직 타입 정보만을 제공합니다 [1].
-- **타입 획득 및 설치:** 많은 인기 자바스크립트 라이브러리들은 자체적인 타입 파일을 함께 배포합니다 [1]. 자체 타입이 없는 라이브러리의 경우, 'DefinitelyTyped'라는 외부 저장소에서 타입을 설치하여 사용할 수 있습니다 [1].
-- **에러 억제 기능:** 라이브러리에 대한 타입이 전혀 존재하지 않는 특수한 상황에서는, 임의로 모듈을 선언(declare)하여 타입스크립트 컴파일러가 뱉어내는 에러를 억제할 수 있습니다 [2].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[JavaScript Libraries]], [[DefinitelyTyped]], [[Type Definitions]]
-- **Projects/Contexts:** 타입스크립트 환경에서 순수 자바스크립트로 작성된 외부 라이브러리를 가져와 사용할 때 발생할 수 있는 타입 에러를 방지하고, IDE의 자동 완성 등 타입 안정성을 확보하기 위한 맥락에서 사용됩니다 [1, 2].
-- **Contradictions/Notes:** 제공된 여러 소스의 목차(Table of Contents)에서 선언 파일이 간략히 언급되기는 하나[3, 4], 실제 작동 원리나 세부 작성법을 설명한 본문 내용은 소스에 포함되어 있지 않아 정보를 깊이 있게 확장하는 데 한계가 있습니다.
-
----
-*Last updated: 2026-04-18*
-- Raw Source: [[00_Raw/2026-04-20/선언 파일(.d.ts).md]]
----
diff --git a/Programming & Language/설정 객체 및 룩업 테이블 설계(Configuration Objects and Lookup Tables).md b/Programming & Language/설정 객체 및 룩업 테이블 설계(Configuration Objects and Lookup Tables).md
deleted file mode 100644
index a96924e6..00000000
--- a/Programming & Language/설정 객체 및 룩업 테이블 설계(Configuration Objects and Lookup Tables).md	
+++ /dev/null
@@ -1,42 +0,0 @@
----
-id: P-REINFORCE-AUTO-53A6E9
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - 설정 객체 및 룩업 테이블 설계(Configuration Objects and Lookup Tables)"
----
-
-# [[설정 객체 및 룩업 테이블 설계(Configuration Objects and Lookup Tables)]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 설정 객체(Configuration Objects)와 룩업 테이블(Lookup Tables)은 애플리케이션 내에서 변경되지 않아야 하는 고정된 상태 데이터, 매핑 정보 또는 환경 설정을 정의하기 위한 구조입니다. TypeScript에서는 이러한 객체가 런타임에 의도치 않게 수정되는 것을 방지하고 타입의 정밀도를 유지하기 위해 `readonly`, `Record`, `as const`, `satisfies`와 같은 타입 시스템의 기능들을 조합하여 설계합니다. 이를 통해 개발자는 런타임의 불변성(Immutability)과 컴파일 타임의 강력한 타입 유효성 검사를 동시에 확보할 수 있습니다.
-
-## 📖 구조화된 지식 (Synthesized Content)
-*   **설정 객체의 불변성(Immutability) 보장**
-    애플리케이션의 설정 객체(Configuration objects)나 상수적 데이터는 초기화 이후 변경되어서는 안 되므로 `readonly` 수식어를 사용하여 의도치 않은 변형(mutation)을 방지해야 합니다 [1-3]. `Readonly<T>` 유틸리티 타입을 활용하여 설정 객체를 고정시키면, 설정이 런타임에 실수로 수정됨으로써 발생할 수 있는 버그의 위험을 크게 줄일 수 있습니다 [4-6].
-*   **중첩된 설정 구조를 위한 재귀적 보호**
-    기본 제공되는 `Readonly<T>`는 최상위 속성에만 얕은(shallow) 불변성을 제공합니다 [7, 8]. 따라서 설정 데이터가 깊이 중첩된 객체 형태를 가질 경우, 데이터의 어느 부분도 수정할 수 없도록 강제하기 위해 재귀적으로 동작하는 커스텀 `DeepReadonly` 타입을 정의하여 사용하는 것이 필수적입니다 [7, 8].
-*   **정적 딕셔너리 및 룩업 테이블 설계**
-    룩업 테이블이나 정적 딕셔너리를 구축할 때는 `Readonly`와 `Record` 유틸리티 타입을 결합하여 앱 전반에 걸쳐 일정하게 유지되는 불변의 키-값 맵(Key-Value Maps)을 만들 수 있습니다 [9]. 
-*   **`as const`와 `satisfies`를 결합한 무결성 패턴**
-    설정 객체와 룩업 테이블을 설계할 때 가장 강력하고 완벽한 패턴은 `as const`와 `satisfies` 연산자를 함께 사용하는 것입니다 [10]. 
-    *   `satisfies` 연산자는 객체가 정의된 타입 구조(요구되는 속성 및 타입)에 부합하는지 엄격히 검증하면서도, 타입 추론이 더 넓은 타입(widening)으로 희석되는 것을 막아 객체의 구체적인 리터럴 타입과 추가 속성을 그대로 보존합니다 [11, 12].
-    *   이 패턴을 사용하면 정확한 키와 값을 가진 룩업 테이블을 구현하고 더 나은 자동 완성(autocomplete)의 이점을 누릴 수 있습니다 [13, 14].
-    *   여기에 `as const` 단언(Assertion)을 추가하면 컴파일 타임의 구조적 유효성 검사뿐만 아니라 런타임 불변성까지 보장되어, 절대 변경되어서는 안 되는 안정적인 설정 객체와 룩업 테이블을 생성할 수 있습니다 [10, 14].
-*   **선택적(Optional) 속성과의 조합**
-    API 설계 및 설정 관리 등에서는 '읽기 전용(`readonly`)'과 '선택적(`?`)' 속성을 결합하는 패턴이 빈번하게 사용됩니다 [15]. 이는 설정 객체 내에 해당 속성이 제공되지 않을 수도 있지만, 만약 존재한다면 절대로 변경되어서는 안 되는 계약 구조를 나타낼 때 유용합니다 [16].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[Readonly Type]], [[Satisfies 연산자]], [[as const Assertion]], [[TypeScript Utility Types (Record, Readonly)]]
-- **Projects/Contexts:** [[안전한 TypeScript 데이터 모델링 및 설정 관리 구축]]
-- **Contradictions/Notes:** TypeScript에 내장된 `Readonly<T>` 유틸리티 타입은 객체의 깊은 불변성까지는 강제하지 못하므로, 복잡한 설정 객체의 완벽한 런타임 무결성을 보장하기 위해서는 개발자가 직접 재귀형 `DeepReadonly` 유틸리티 타입을 구현하거나 외부 라이브러리에 의존해야 합니다 [7, 17].
-
----
-*Last updated: 2026-04-18*
-- Raw Source: [[00_Raw/2026-04-20/설정 객체 및 룩업 테이블 설계(Configuration Objects and Lookup Tables).md]]
----
diff --git a/Programming & Language/성장 마인드셋 (Growth Mindset).md b/Programming & Language/성장 마인드셋 (Growth Mindset).md
deleted file mode 100644
index 794e0855..00000000
--- a/Programming & Language/성장 마인드셋 (Growth Mindset).md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-56F98F
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - 성장 마인드셋 (Growth Mindset)"
----
-
-# [[성장 마인드셋 (Growth Mindset)]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/성장 마인드셋 (Growth Mindset).md]]
----
diff --git a/Programming & Language/성장 마인드셋(Growth Mindset).md b/Programming & Language/성장 마인드셋(Growth Mindset).md
deleted file mode 100644
index b7ce76f9..00000000
--- a/Programming & Language/성장 마인드셋(Growth Mindset).md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-A73E81
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - 성장 마인드셋(Growth Mindset)"
----
-
-# [[성장 마인드셋(Growth Mindset)]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/성장 마인드셋(Growth Mindset).md]]
----
diff --git a/Programming & Language/세대 가설(Generational Hypothesis).md b/Programming & Language/세대 가설(Generational Hypothesis).md
deleted file mode 100644
index 0474d103..00000000
--- a/Programming & Language/세대 가설(Generational Hypothesis).md	
+++ /dev/null
@@ -1,41 +0,0 @@
----
-id: P-REINFORCE-AUTO-3D4CF3
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - 세대 가설(Generational Hypothesis)"
----
-
-# [[세대 가설(Generational Hypothesis)]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 세대 가설(Generational Hypothesis)은 프로그램에서 생성된 대부분의 객체가 생성 직후 곧바로 도달할 수 없는 상태(죽은 상태)가 된다는 경험적 관찰을 의미합니다 [1-3]. 이 가설은 자바스크립트(JavaScript)뿐만 아니라 대부분의 동적 언어에 적용되는 중요한 가비지 컬렉션(Garbage Collection) 개념입니다 [2]. V8 엔진은 이 특성을 적극적으로 활용하여 힙(Heap) 메모리를 '젊은 세대(young generation)'와 '오래된 세대(old generation)'로 분리하고, 이를 통해 메모리 정리 작업을 최적화합니다 [1-4].
-
-## 📖 구조화된 지식 (Synthesized Content)
-* **가설의 핵심 원리:** 
-  대부분의 프로그램에서 객체들은 매우 짧은 수명을 가지는 반면, 극소수의 객체만이 훨씬 더 오래 살아남는 경향을 보입니다 [4]. 즉, 새로 메모리에 할당된 객체는 가비지 컬렉터의 관점에서 볼 때 할당 직후 거의 즉시 도달할 수 없는 가비지(unreachable) 상태가 될 가능성이 높다는 것이 세대 가설의 핵심입니다 [2, 5].
-
-* **V8 엔진의 힙(Heap) 분할 적용:** 
-  V8 엔진은 객체의 수명 주기에 관한 이 가설을 구조적으로 활용하기 위해 힙 메모리를 여러 세대(generations)로 분할합니다 [2, 6]. 구체적으로는 대부분의 새로운 객체가 할당되는 '젊은 세대(New Space)'와 일정 시간 살아남은 객체들이 보관되는 '오래된 세대(Old Space)'로 메모리를 나눕니다 [1, 4].
-
-* **가비지 컬렉션(GC) 최적화 전략:**
-  * **젊은 세대(Young Generation):** 대부분의 객체가 이곳에서 일찍 죽을 것으로 예상되므로, V8은 이 비교적 작은 영역에 대해 매우 빈번하고 가벼운 가비지 컬렉션(Minor GC 또는 Scavenger)을 수행하여 메모리를 신속하게 회수합니다 [1, 3, 4].
-  * **오래된 세대(Old Generation):** 젊은 세대에서 여러 번의 가비지 컬렉션 주기를 거치고도 살아남은 객체는 장기 보관을 위해 오래된 세대로 승격(promoted)됩니다 [3, 4, 6]. 이 객체들은 앞으로도 계속 유지될 것으로 간주되어, 비용이 훨씬 많이 들고 무거운 전역 컬렉션(Major GC)은 이 공간을 대상으로 덜 빈번하게 수행됩니다 [1, 3].
-
-* **성능 및 비용 효율성:** 
-  가비지 컬렉션 중 살아남은 객체를 다른 메모리 공간으로 복사(copying)하는 작업은 보통 비용이 많이 듭니다 [2]. 하지만 세대 가설에 따르면 실제로 가비지 컬렉션에서 살아남는 객체의 비율은 매우 작습니다 [2]. 따라서 V8 엔진은 살아남은 소수의 객체만을 복사함으로써 할당된 횟수가 아닌 살아남은 객체 수에 비례하는 비용만 지불하며, 도달할 수 없게 된 나머지 수많은 객체들은 '암묵적인(implicit)' 가비지로 매우 효율적으로 처리합니다 [2].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[Garbage Collection (GC)]], [[V8 Engine]], [[Young Generation (New Space)]], [[Old Generation (Old Space)]], [[Scavenger (Minor GC)]]
-- **Projects/Contexts:** [[V8 Memory Management]], [[Node.js Performance Optimization]]
-- **Contradictions/Notes:** 소스에 관련 정보가 부족합니다.
-
----
-*Last updated: 2026-04-19*
-- Raw Source: [[00_Raw/2026-04-20/세대 가설(Generational Hypothesis).md]]
----
diff --git a/Programming & Language/세대별 가설(Generational Hypothesis).md b/Programming & Language/세대별 가설(Generational Hypothesis).md
deleted file mode 100644
index a37d86e4..00000000
--- a/Programming & Language/세대별 가설(Generational Hypothesis).md	
+++ /dev/null
@@ -1,35 +0,0 @@
----
-id: P-REINFORCE-AUTO-A34D6C
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - 세대별 가설(Generational Hypothesis)"
----
-
-# [[세대별 가설(Generational Hypothesis)]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-- **핵심 개념**: 프로그램 내에서 대다수의 객체는 수명이 매우 짧고, 오직 극소수의 객체만이 오래 살아남는다는 것을 의미합니다 [2, 3]. 즉, 새롭게 할당된 객체는 GC의 관점에서 곧바로 가비지(쓰레기)가 될 확률이 높습니다 [2].
-- **V8 메모리 구조에의 적용**: V8은 세대별 가설을 이용하여 힙 메모리를 '새로운 공간(New Space / Young Generation)'과 '오래된 공간(Old Space / Old Generation)' 두 세대로 분리합니다 [1-3].
-- **세대별 가비지 컬렉터 최적화**:
-  - **젊은 세대 (New Space)**: 단기 생존 객체는 새로운 객체가 할당되는 젊은 세대 공간에 배치됩니다 [4]. 객체들이 '일찍 죽을 것'으로 예상되므로, V8 엔진은 이 영역에 대해 가볍고 빈번한 가비지 컬렉션(Scavenge 또는 Minor GC)을 수행하여 메모리를 신속하게 회수합니다 [1, 4].
-  - **늙은 세대 (Old Space)**: 여러 번의 마이너 가비지 컬렉션(Minor GC) 주기를 견뎌내고 살아남은 소수의 객체만 늙은 세대 공간으로 승격(promotion)됩니다 [3, 4]. 이 영역은 객체가 오래 지속될 것으로 예상되므로, 비용이 더 많이 드는 전역 가비지 컬렉션(Major GC)을 더 드물게 실행하도록 설계되었습니다 [1, 4].
-- **효율성 개선**: GC 과정에서 살아남은 객체만을 이동(copy)시키는 방식을 사용함으로써, 가비지 컬렉션에 드는 비용은 전체 메모리 할당량이 아닌 '생존 객체 수'에 비례하게 됩니다 [2]. 이는 대다수의 할당된 객체가 암묵적으로 가비지로 처리됨을 의미하며, 결과적으로 메모리 관리 효율성이 크게 향상됩니다 [2].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[가비지 컬렉션(Garbage Collection)]], [[V8 엔진(V8 Engine)]], [[젊은 세대(Young Generation/New Space)]], [[늙은 세대(Old Generation/Old Space)]], [[스캐빈저(Scavenger/Minor GC)]]
-- **Projects/Contexts:** [[V8 자바스크립트 엔진 메모리 관리(V8 JavaScript Engine Memory Management)]], [[오리노코 가비지 컬렉터(Orinoco Garbage Collector)]]
-- **Contradictions/Notes:** 소스에 제공된 정보들 사이에서 모순은 발견되지 않으며, 모든 소스가 공통으로 세대별 가설이 V8의 메모리 공간 분할 및 가비지 컬렉션 효율화의 핵심 이론적 기반이라고 설명하고 있습니다.
-
----
-*Last updated: 2026-04-19*
-- Raw Source: [[00_Raw/2026-04-20/세대별 가설(Generational Hypothesis).md]]
----
diff --git a/Programming & Language/소프트웨어 구성 분석(SCA).md b/Programming & Language/소프트웨어 구성 분석(SCA).md
deleted file mode 100644
index 997f6b25..00000000
--- a/Programming & Language/소프트웨어 구성 분석(SCA).md	
+++ /dev/null
@@ -1,33 +0,0 @@
----
-id: P-REINFORCE-AUTO-C55C87
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - 소프트웨어 구성 분석(SCA)"
----
-
-# [[소프트웨어 구성 분석(SCA)]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 소프트웨어 구성 분석(SCA, Software Composition Analysis)은 애플리케이션에 포함된 오픈소스 및 서드파티 코드 종속성을 분석하는 보안 테스트 방법론입니다 [1, 2]. 이 기술은 컴포넌트 취약점 데이터베이스(CVE 등)에 이미 보고된 알려진 취약점, 라이선스 규정 준수 위험, 버전 기록 등을 식별하는 데 중점을 둡니다 [1, 2]. 오픈소스 라이브러리를 많이 사용하는 최신 개발 환경에서 소프트웨어 공급망 위험을 관리하고 외부 코드를 안전하게 보호하는 데 필수적인 역할을 수행합니다 [2, 3].
-
-## 📖 구조화된 지식 (Synthesized Content)
-- **분석 대상 및 범위:** SCA는 애플리케이션 내의 오픈소스 및 서드파티 컴포넌트는 물론, 이들이 의존하는 전이적 종속성(transitive dependencies)까지 검사합니다 [1, 3]. 이를 통해 라이선싱 문제와 알려진 취약점을 찾아내며, 제3자 의존성을 파악하고 보호하는 데 가장 적합한 방법입니다 [1, 2].
-- **SAST와의 보완적 관계:** SAST(정적 애플리케이션 보안 테스트)가 자체적으로 작성한 커스텀 코드의 결함을 찾는 데 집중하는 반면, SCA는 외부에서 도입된 컴포넌트를 분석하므로 두 분석 도구를 결합해야 자체 코드와 서드파티 취약점을 포괄적으로 방어할 수 있습니다 [1, 3].
-- **지속적 모니터링과 공급망 보안:** SCA는 코드 병합 후에도 저장소를 지속적으로 모니터링하여 새로운 CVE와 같은 취약점이 발생할 경우 향후 풀 리퀘스트 시 경고를 생성할 수 있어 소프트웨어 공급망 보안에 핵심적인 역할을 합니다 [3, 4]. 단, SCA 도구의 특성상 프로그래밍 언어에 종속적(language-dependent)으로 동작하는 한계가 있습니다 [2].
-- **심층적 분석 기술 결합(도달 가능성 분석):** Endor Labs와 같은 최신 보안 플랫폼은 종속성 분석에 도달 가능성 분석(reachability analysis)을 도입하여, 서드파티 코드에 존재하는 취약점이 실제 프로덕션 환경의 함수 단위 실행 경로에서 도달 가능한지 여부를 파악해 위험 대응의 우선순위를 높이도록 돕고 있습니다 [5-7].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[SAST(정적 애플리케이션 보안 테스트)]], [[소프트웨어 공급망 보안]], [[오픈소스 의존성]], [[CVE(공통 취약점 및 노출)]]
-- **Projects/Contexts:** [[Snyk Open Source]], [[Endor Labs]]
-- **Contradictions/Notes:** 소스 간의 모순된 주장은 발견되지 않았으나, 애플리케이션 전체의 보안 강화를 위해서는 SCA 단독 활용보다는 SAST와 결합하여 사용해야 가장 이상적이고 완전한 테스트가 이루어진다는 점이 전반적으로 강조됩니다 [3].
-
----
-*Last updated: 2026-04-19*
-- Raw Source: [[00_Raw/2026-04-20/소프트웨어 구성 분석(SCA).md]]
----
diff --git a/Programming & Language/소프트웨어 아키텍처 베스트 프랙티스.md b/Programming & Language/소프트웨어 아키텍처 베스트 프랙티스.md
deleted file mode 100644
index cd744cbd..00000000
--- a/Programming & Language/소프트웨어 아키텍처 베스트 프랙티스.md	
+++ /dev/null
@@ -1,43 +0,0 @@
----
-id: P-REINFORCE-AUTO-FDDA7F
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - 소프트웨어 아키텍처 베스트 프랙티스"
----
-
-# [[소프트웨어 아키텍처 베스트 프랙티스]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 소프트웨어 아키텍처 베스트 프랙티스는 회복성, 확장성, 그리고 유지보수성이 뛰어난 시스템을 구축하기 위한 핵심 원칙과 설계 청사진입니다 [1]. 이는 단순한 이론적 지침을 넘어, 기능의 추가 및 수정을 용이하게 하고 기술 부채를 최소화하여 애플리케이션의 장기적인 비즈니스 가치를 보존하는 근본적인 철학입니다 [1, 2]. 관심사의 분리(SoC), 클린 아키텍처, 도메인 주도 설계(DDD) 등의 원칙을 통해 시스템의 결합도를 낮추고 응집도를 높여 복잡성을 통제하는 것을 궁극적인 목표로 합니다 [3-5].
-
-## 📖 구조화된 지식 (Synthesized Content)
-성공적인 소프트웨어 아키텍처를 구현하기 위한 핵심 프랙티스들은 다음과 같습니다.
-
-*   **관심사의 분리 (Separation of Concerns, SoC)**
-    소프트웨어 설계에서 가장 중요한 원칙 중 하나로, 프로그램을 서로 겹치지 않는 뚜렷한 기능(관심사)별로 나누는 것을 의미합니다 [6, 7]. 비즈니스 로직(뇌)과 인프라/프레임워크(팔다리)를 엄격히 분리함으로써 높은 응집도(High Cohesion)와 낮은 결합도(Low Coupling)를 달성할 수 있습니다 [8-10]. 이를 통해 하나의 모듈을 변경할 때 다른 모듈이 받는 영향을 최소화하여 유지보수성과 재사용성을 극대화합니다 [11].
-*   **클린 아키텍처 및 의존성 규칙**
-    비즈니스 규칙과 애플리케이션 로직을 시스템의 중심에 두고, 프레임워크, UI, 데이터베이스 등의 외부 세부 사항을 바깥 계층으로 밀어내는 철학입니다 [12, 13]. 핵심은 '의존성 규칙(Dependency Rule)'으로, 소스 코드의 의존성은 항상 외부에서 내부(고수준의 비즈니스 정책)를 향해야 합니다 [14]. 이로 인해 인프라가 변경되더라도 핵심 업무 로직은 영향을 받지 않습니다 [15].
-*   **객체 지향 및 모듈화 원칙 (SOLID & DRY)**
-    클래스는 단 하나의 변경 이유만 가져야 한다는 단일 책임 원칙(SRP)을 비롯한 SOLID 원칙은 낮은 결합도와 높은 테스트 가능성을 제공합니다 [16, 17]. 또한, 동일한 로직이나 지식을 여러 곳에 중복하지 않는 DRY(Don't Repeat Yourself) 원칙을 통해 시스템 내 단일 진실 공급원(Single Source of Truth)을 유지해야 합니다 [18].
-*   **도메인 주도 설계 (Domain-Driven Design, DDD)**
-    복잡한 시스템을 다루기 위해 비즈니스 도메인 전문가와 개발자가 '보편적 언어(Ubiquitous Language)'를 공유하며 모델링하는 기법입니다 [19]. 거대한 도메인을 '바운디드 컨텍스트(Bounded Context)'로 나누어 각 영역이 독립적인 모델을 가지게 함으로써 복잡성을 관리합니다 [20, 21].
-*   **마이크로서비스 (Microservices) 및 이벤트 기반 아키텍처**
-    거대한 모놀리식 구조를 탈피하여, 단일 비즈니스 역량을 수행하며 독립적으로 배포 및 확장이 가능한 작은 서비스들의 집합으로 시스템을 구성합니다 [22]. 서비스 간의 느슨한 결합을 위해 메시지 브로커를 활용한 비동기식 이벤트 기반 아키텍처(Event-Driven Architecture)를 함께 적용하는 것이 권장됩니다 [23]. 프론트엔드 영역에서도 이를 적용한 '마이크로 프론트엔드' 기술이 사용됩니다 [24, 25].
-*   **테스트 주도 개발(TDD) 및 테스트 경계**
-    아키텍처는 초기부터 테스트 가능성을 고려하여 설계되어야 합니다. TDD는 모듈화와 명확한 인터페이스 생성을 강제하므로 결합도를 낮추는 데 기여합니다 [26, 27]. 테스트 또한 시스템의 일부로 간주되며, 변동성이 큰 GUI 등을 거치지 않고 업무 규칙을 직접 검증할 수 있는 테스트 API를 구축하는 것이 중요합니다 [27, 28].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[관심사의 분리(SoC)]], [[클린 아키텍처]], [[마이크로서비스 아키텍처]], [[도메인 주도 설계(DDD)]], [[SOLID 원칙]]
-- **Projects/Contexts:** [[넷플릭스(Netflix)의 코스모스 플랫폼 및 마이크로서비스 전환]], [[스포티파이(Spotify)의 마이크로 프론트엔드 및 스쿼드 모델]]
-- **Contradictions/Notes:** 소스에 따르면 완벽한 형태의 아키텍처 경계(예: 완벽한 관심사 분리와 다형성 인터페이스의 전면적 도입)는 유지보수성과 독립성을 극대화하지만, 초기 구현 비용과 성능 오버헤드, 인지적 부하(Over-engineering)를 초래할 수 있습니다. 따라서 아키텍트는 YAGNI(You Aren't Gonna Need It) 철학을 기반으로 "Rule of Three(세 번 이상 중복 시 추상화)" 등을 활용해 부분적 경계만을 도입하는 등 실무적인 타협을 지속적으로 판단해야 한다고 지적합니다 [29-32].
-
----
-*Last updated: 2026-04-18*
-- Raw Source: [[00_Raw/2026-04-20/소프트웨어 아키텍처 베스트 프랙티스.md]]
----
diff --git a/Programming & Language/소프트웨어 아키텍처 설계.md b/Programming & Language/소프트웨어 아키텍처 설계.md
deleted file mode 100644
index c94563c5..00000000
--- a/Programming & Language/소프트웨어 아키텍처 설계.md	
+++ /dev/null
@@ -1,41 +0,0 @@
----
-id: P-REINFORCE-AUTO-6B7DB7
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - 소프트웨어 아키텍처 설계"
----
-
-# [[소프트웨어 아키텍처 설계]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 소프트웨어 아키텍처 설계는 소프트웨어 시스템이 쉽게 개발, 배포, 운영 및 유지보수될 수 있도록 시스템의 형태와 컴포넌트 간의 관계를 구성하는 작업입니다 [1, 2]. 좋은 아키텍처는 시스템의 복잡성을 관리하여 기술 부채를 최소화하며, 핵심 비즈니스 규칙과 유스케이스를 중심에 두어 외부 프레임워크나 도구에 대한 결정을 지연시킬 수 있도록 돕습니다 [3, 4]. 이를 위해 관심사의 분리(SoC) 및 SOLID 원칙 등 다양한 설계 철학이 적용되어 시스템의 유연성과 확장성을 보장합니다 [5-7].
-
-## 📖 구조화된 지식 (Synthesized Content)
-* **핵심 목적 및 원칙:**
-  * **유지보수성과 확장성 확보:** 복잡한 시스템을 모듈화하여 개발 속도를 높이고, 코드의 가독성과 테스트 용이성을 극대화하는 것이 아키텍처 설계의 핵심입니다 [3, 8].
-  * **관심사의 분리 (Separation of Concerns, SoC):** 시스템을 여러 개의 독립적인 모듈로 나누어 각 부분이 하나의 기능이나 책임에 집중하게 만듭니다 [9, 10]. 이를 통해 모듈 내부의 응집도(Cohesion)를 높이고 외부 요소와의 결합도(Coupling)를 낮추어 독립적인 유지보수 및 재사용성을 크게 향상시킵니다 [11-13].
-  * **의존성 규칙 (Dependency Rule) 및 클린 아키텍처:** 소스 코드의 의존성은 항상 고수준의 정책(핵심 비즈니스 로직)을 향해 안쪽으로 지향해야 합니다 [14]. 시스템의 심장부인 엔티티(Entity)와 유스케이스(Use Case)를 UI나 데이터베이스 같은 저수준의 외부 세부 사항으로부터 철저히 격리합니다 [15, 16].
-  * **SOLID 및 DRY 원칙:** 클래스가 단일 책임을 갖게 하고(SRP), 확장에 열려 있고 수정에 닫혀 있게 하며(OCP), 코드 내 중복을 방지(DRY)하여 시스템이 견고하고 유연하게 진화할 수 있는 기반을 다집니다 [6, 17, 18].
-
-* **주요 아키텍처 패턴:**
-  * **계층화 아키텍처 (Layered Architecture):** 시스템을 프레젠테이션(UI), 비즈니스 로직, 데이터 액세스 등의 수평적 계층으로 나누어 인접한 계층 간에만 통신하도록 역할을 엄격히 분리합니다 [19, 20].
-  * **마이크로서비스 아키텍처 (Microservices Architecture):** 거대한 애플리케이션을 비즈니스 도메인 단위의 작고 독립적인 서비스들로 분할하여 개별 팀의 병렬 개발, 독립 배포, 유연한 서비스 확장을 가능하게 합니다 [21, 22].
-  * **이벤트 기반 아키텍처 (Event-Driven Architecture):** 시스템 컴포넌트들이 이벤트를 생산하고 소비함으로써 비동기적으로 통신하게 구성하여, 서비스 간 결합도를 낮추고 실시간 데이터 처리와 확장에 유리하게 만듭니다 [23, 24].
-  * **도메인 주도 설계 (DDD):** 기술적인 계층화뿐만 아니라 비즈니스 영역을 '바운디드 컨텍스트(Bounded Context)'라는 단위로 나누고 '유비쿼터스 언어'를 공유하여 복잡한 비즈니스 현실을 아키텍처에 정확히 반영합니다 [25-27].
-  * **마이크로 프론트엔드 및 FSD 아키텍처:** 프론트엔드 영역에서도 기능(Feature) 단위로 코드를 슬라이싱하는 FSD(Feature-Sliced Design)나 마이크로 프론트엔드 아키텍처를 도입하여 대규모 웹 애플리케이션의 복잡성을 줄이고 각 팀의 자율성을 확보합니다 [28-30].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[관심사의 분리(SoC)]], [[클린 아키텍처]], [[마이크로서비스 아키텍처]], [[도메인 주도 설계(DDD)]], [[SOLID 원칙]]
-- **Projects/Contexts:** [[Netflix 마이크로서비스 전환]], [[스포티파이 자율적 분대 모델]], [[FSD (Feature-Sliced Design)]]
-- **Contradictions/Notes:** 관심사의 분리 원칙은 코드 유지보수성과 확장성을 크게 높이지만, 과도한 분리나 추상화(오버엔지니어링)는 잦은 계층 간 데이터 변환과 네트워크 통신 증가를 유발하여 성능 오버헤드와 디버깅의 어려움을 초래할 수 있으므로 적절한 임계점을 찾는 것이 중요합니다 [31-33]. 또한 최근 도입되는 인공지능(AI) 시스템의 아키텍처에서는 모델의 결과가 확률적이라는 특성상, 전통적인 결정론적 단위 테스트(TDD) 방식 대신 허용 오차 범위 내의 통계적 속성을 검증하는 AI 특화 TDD 접근 방식이 요구됩니다 [34, 35].
-
----
-*Last updated: 2026-04-18*
-- Raw Source: [[00_Raw/2026-04-20/소프트웨어 아키텍처 설계.md]]
----
diff --git a/Programming & Language/수동 코드 리뷰 (Manual Code Review).md b/Programming & Language/수동 코드 리뷰 (Manual Code Review).md
deleted file mode 100644
index 7b77cf60..00000000
--- a/Programming & Language/수동 코드 리뷰 (Manual Code Review).md	
+++ /dev/null
@@ -1,55 +0,0 @@
----
-id: P-REINFORCE-AUTO-30780C
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - 수동 코드 리뷰 (Manual Code Review)"
----
-
-# [[수동 코드 리뷰 (Manual Code Review)]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 수동 코드 리뷰(Manual Code Review)는 한 명 이상의 개발자가 코드 변경 사항을 줄 단위로 직접 읽고 논의하여 논리적 오류, 아키텍처 결함, 명명 규칙 위반 등을 식별하는 인간 주도의 검토 프로세스입니다 [1, 2]. 이 방식은 자동화 도구가 파악하기 힘든 비즈니스 로직의 의도, 설계 패턴의 적합성, 프로젝트의 문맥을 깊이 이해하는 데 탁월한 장점을 제공합니다 [3, 4]. 또한, 동료 간의 피드백을 통해 코드 가독성을 높이고 시니어 개발자가 주니어 개발자를 멘토링하는 강력한 지식 공유의 수단으로 활용됩니다 [5-7]. 하지만 검토에 많은 시간과 숙련된 개발자의 인건비가 소모되며, 피로도나 편향으로 인한 인간의 실수 및 일관성 부족에 취약하다는 한계가 있습니다 [8, 9].
-
-## 📖 구조화된 지식 (Synthesized Content)
-**주요 장점 및 특징**
-* **문맥과 의도 파악 (Context & Insight):** 수동 리뷰는 단순히 코드의 구문적 올바름을 검사하는 것을 넘어 '해당 로직이 왜 존재하는지'에 대한 비즈니스 의도와 문맥을 이해합니다 [3, 4]. 복잡한 비즈니스 규칙 검증, 아키텍처의 트레이드오프 평가, 패턴 매칭을 넘어서는 보안 문맥 파악 등에서 자동화 도구보다 훨씬 우수합니다 [10-13].
-* **가독성 및 설계 개선 (Readability & Design):** 리뷰어는 명명 규칙의 일관성을 맞추고, API 설계를 평가하며, 향후 유지보수를 위한 리팩토링이나 구조 개선을 제안함으로써 전반적인 코드 가독성을 높입니다 [4, 6, 14].
-* **지식 공유와 멘토링 (Knowledge Sharing):** 코드 리뷰 세션은 시니어 개발자가 주니어 개발자에게 코딩 표준, 프로젝트의 미묘한 차이, 언어나 프레임워크에 대한 새로운 지식을 가르치는 훌륭한 교육 및 멘토링 기회를 제공합니다 [4, 6, 7, 15].
-
-**주요 단점 및 한계**
-* **시간 및 비용 소모 (Time Intensive & High Cost):** 코드를 줄 단위로 직접 읽어야 하므로 대규모 변경 사항의 경우 검토에 몇 시간 혹은 며칠이 소요될 수 있으며, 이는 배포 지연과 높은 인건비 부담으로 이어집니다 [5, 9].
-* **인간의 오류 및 일관성 부족 (Human Error & Bias):** 리뷰어의 피로도, 주의 산만, 혹은 개인의 관심사 차이 등에 따라 미세한 엣지 케이스를 놓칠 수 있으며, 코드 품질 기준이 사람마다 달라 일관성을 유지하기 어렵습니다 [5, 9, 16].
-
-**수동 리뷰가 필수적인 12가지 시나리오**
-자동화 도구가 해결할 수 없는 판단력과 도메인 전문성이 요구되는 영역에서는 수동 리뷰가 대체 불가능합니다 [17, 18].
-1. 아키텍처 트레이드오프 평가 [11]
-2. 설계 패턴의 적합성 판단 [11]
-3. 서비스 간 영향도 및 배포 조정 평가 [19]
-4. 기존 학습 데이터에 없는 새로운 아키텍처 접근법 평가 [19]
-5. 도메인 특화 비즈니스 규칙 검증 (예: 법적/규제 제약) [12]
-6. 비즈니스 로직과 제품 요구사항의 일치 확인 [20]
-7. 암시적 부작용 및 시스템 전반의 결과 파악 [20]
-8. 교차 팀 소유권 경계 확인 및 조율 [21]
-9. 패턴 매칭 도구가 파악하지 못하는 보안 문맥 평가 [13]
-10. 성능 최적화와 가독성 간의 트레이드오프 결정 [22]
-11. 리팩토링 전략 및 기술 부채 관리 시기 결정 [22]
-12. 의도 검증 및 코드 명확성 확인 [23]
-
-**현대적 코드 리뷰 접근법 (하이브리드 모델)**
-현대 개발 환경(2025년 기준)에서는 수동 리뷰와 자동화된 리뷰를 결합하는 하이브리드 모델이 가장 이상적입니다 [8, 10, 24]. CI/CD 파이프라인의 정적 분석 및 린팅(Linting) 도구를 통해 구문 오류, 코드 스타일, 널리 알려진 보안 취약점 등 반복적이고 기계적인 문제를 먼저 빠르게 해결합니다 [10, 15, 25]. 그 후, 인간 리뷰어는 복잡한 비즈니스 로직, 아키텍처 변경, 중요 보안 경로 등 고부가가치 및 고위험 영역의 평가에만 집중하여 품질과 개발 속도를 동시에 높이는 방식이 권장됩니다 [8, 10, 15, 26].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[자동화된 코드 리뷰 (Automated Code Review)]], [[정적 애플리케이션 보안 테스트 (SAST)]], [[하이브리드 코드 리뷰 (Hybrid Code Review)]], [[코드 품질 (Code Quality)]]
-- **Projects/Contexts:** [[GitHub/GitLab Pull Request]], [[CI/CD 파이프라인]], [[소프트웨어 개발 수명 주기 (SDLC)]]
-- **Contradictions/Notes:** 수동 리뷰가 코드의 모든 문제를 잡아낼 수 있다는 것은 잘못된 속설(Myth)입니다. 인간은 시간적 압박과 피로도에 의해 단순한 실수를 놓칠 수 있기 때문에 대규모 코드베이스에서 수동 리뷰에만 의존하는 것은 비실용적입니다 [16]. 마찬가지로 자동화 도구 역시 완벽하지 않아 복잡한 비즈니스 로직 결함이나 새로운 형태의 공격을 놓치는 컨텍스트 사각지대(Context Blindness)를 가지므로, 두 방식을 상호 보완적으로 사용해야 합니다 [16, 27].
-
----
-*Last updated: 2026-04-18*
-- Raw Source: [[00_Raw/2026-04-20/수동 코드 리뷰 (Manual Code Review).md]]
----
diff --git a/Programming & Language/수동 코드 리뷰.md b/Programming & Language/수동 코드 리뷰.md
deleted file mode 100644
index 758c6b85..00000000
--- a/Programming & Language/수동 코드 리뷰.md	
+++ /dev/null
@@ -1,43 +0,0 @@
----
-id: P-REINFORCE-AUTO-AA36FB
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - 수동 코드 리뷰"
----
-
-# [[수동 코드 리뷰]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 수동 코드 리뷰는 개발자가 직접 코드 변경 사항을 한 줄씩 검토하여 논리적 오류, 아키텍처 문제, 설계상의 결함 등을 찾아내는 사람 주도의 프로세스입니다 [1, 2]. 자동화 도구가 파악하기 힘든 비즈니스 로직의 의도, 아키텍처의 트레이드오프를 평가하고 팀원 간의 지식을 공유하는 데 탁월한 효과를 발휘합니다 [3-5]. 하지만 많은 시간과 숙련된 개발자의 인건비가 소모되며, 리뷰어의 피로도에 따라 일관성이 떨어질 수 있다는 한계도 지닙니다 [6, 7]. 따라서 최신 개발 환경에서는 단순 검사는 자동화 도구에 맡기고, 수동 리뷰는 복잡한 로직과 보안 컨텍스트 등 고위험 영역에 집중하는 하이브리드 방식이 권장됩니다 [3, 8].
-
-## 📖 구조화된 지식 (Synthesized Content)
-- **컨텍스트 이해와 심층적 결함 발견**
-  수동 코드 리뷰의 가장 큰 장점은 **비즈니스 로직과 개발자의 의도(Context)를 이해**할 수 있다는 것입니다 [9, 10]. 자동화된 정적 분석 도구가 단순한 패턴 매칭에 그치는 반면, 수동 리뷰어는 애플리케이션의 흐름을 이해하고 있기 때문에 자동화 도구가 놓치기 쉬운 도메인 종속적인 비즈니스 규칙 오류나 암시적 부작용(사이드 이펙트)을 정확히 식별해낼 수 있습니다 [11-13]. 
-
-- **아키텍처 및 설계 평가**
-  인간 리뷰어는 개별 코드 라인을 넘어 시스템 전체의 유지보수성을 고려한 설계 결정을 내립니다. 마이크로서비스 도입과 같은 **아키텍처 수준의 트레이드오프 평가, 디자인 패턴의 적절성 판단, 교차 서비스(Cross-Service) 영향도 분석, 기술 부채 관리 및 리팩토링 전략** 등은 오직 수동 리뷰를 통해서만 적절히 검증될 수 있는 대표적인 시나리오입니다 [14-17].
-
-- **지식 공유와 멘토링**
-  수동 리뷰 세션은 개발 팀 내에서 모범 사례를 전파하고 서로의 기술적 격차를 줄이는 **강력한 지식 공유 및 멘토링 채널** 역할을 합니다 [4, 6, 10]. 주니어 개발자는 시니어 개발자의 리뷰를 통해 코드 스타일, 명명 규칙, 아키텍처 원칙 등을 배울 수 있으며 이를 통해 팀 전체의 품질 기준을 일치시킬 수 있습니다 [1, 4].
-
-- **수동 코드 리뷰의 주요 한계**
-  수동 검토는 **시간과 비용이 많이 소모되는 작업**입니다 [7]. 대규모 프로젝트의 풀 리퀘스트를 꼼꼼히 검토하려면 수 시간에서 며칠이 걸릴 수 있으며, 이는 배포 주기를 지연시키는 병목 현상이 될 수 있습니다 [6, 7, 18]. 또한, 리뷰어의 피로도나 집중력 저하로 인해 치명적인 문제를 놓치거나(Human Error), 리뷰어 성향에 따라 검토 기준이 달라지는 **일관성 부족 문제**도 존재합니다 [7, 19].
-
-- **효율적인 활용 전략 (하이브리드 모델)**
-  효율성과 품질을 극대화하기 위해, 최신 개발 조직은 수동 리뷰와 자동화 리뷰를 결합한 **하이브리드 접근법**을 사용합니다 [3, 20]. 구문 오류, 스타일 일관성, 알려진 취약점 스캔 등은 자동화 도구에 전담시켜 빠르게 처리하고, 인간 리뷰어는 **결제 처리, 인증 로직 등 보안상 민감한 경로, 시스템 간의 소유권 경계 조율, 그리고 맥락 기반의 보안 위험 우선순위 판별** 등 고부가가치 작업에 집중하도록 라우팅해야 합니다 [8, 21, 22].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[자동화된 코드 리뷰]], [[정적 애플리케이션 보안 테스트]]
-- **Projects/Contexts:** [[풀 리퀘스트(Pull Request) 워크플로우]], [[하이브리드 코드 리뷰 프로세스]]
-- **Contradictions/Notes:** 소스 문헌들은 수동 리뷰가 자동화 도구의 맹점(비즈니스 로직 파악 불가, 신규 패턴 탐지 한계 등)을 메우기 위해 필수적이지만 [3, 23], 반대로 자동화 도구 없이는 검토 속도와 일관성의 한계로 인해 대규모 코드베이스를 감당하기 어려우므로 두 가지 방식이 상호 보완적으로 작동해야 한다고 공통적으로 강조합니다 [9, 20, 24].
-
----
-*Last updated: 2026-04-19*
-- Raw Source: [[00_Raw/2026-04-20/수동 코드 리뷰.md]]
----
diff --git a/Programming & Language/수렴-조절 불일치(Vergence-Accommodation Conflict).md b/Programming & Language/수렴-조절 불일치(Vergence-Accommodation Conflict).md
deleted file mode 100644
index cf105d8d..00000000
--- a/Programming & Language/수렴-조절 불일치(Vergence-Accommodation Conflict).md	
+++ /dev/null
@@ -1,33 +0,0 @@
----
-id: P-REINFORCE-AUTO-B697B6
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - 수렴-조절 불일치(Vergence-Accommodation Conflict)"
----
-
-# [[수렴-조절 불일치(Vergence-Accommodation Conflict)]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 수렴-조절 불일치(Vergence-Accommodation Conflict)는 헤드마운트 디스플레이(HMD)와 같은 가상현실(VR) 환경에서 자연스러운 안구 운동인 '수렴'과 '조절' 기능이 서로 분리(decoupled)될 때 발생하는 시각적 불일치 현상입니다 [1]. 자연적인 시각 조건에서는 이 두 기능이 피드백 루프를 통해 함께 작동하지만, HMD 환경에서는 이러한 상호 연동이 깨지게 됩니다 [1]. 이로 인해 깊이 지각에 대한 망막 단서에 불확실성이 발생하며, 가상현실 멀미(VR Sickness)를 비롯해 피로, 두통 등의 다양한 안구 운동 관련 증상을 유발할 수 있습니다 [1, 2].
-
-## 📖 구조화된 지식 (Synthesized Content)
-- **정상적인 시각 기능 체계:** 수렴(Vergence 또는 Convergence)과 조절(Accommodation)은 가까운 물체에 대해 단일하고 선명한 초점을 맞추는 데 필수적인 안구 운동 기능입니다 [1]. 자연스러운 시청 환경에서 이 두 메커니즘은 피드백 루프 속에서 함께 작동하여, 하나의 메커니즘에 변화가 생기면 다른 하나에도 동시적인 변화가 일어납니다 [1]. 이때 흐림(blur)과 양안 시차(disparity)는 조절과 수렴을 도와 정확한 시선 고정을 가능하게 하는 필수적인 망막 단서로 작용합니다 [1].
-- **HMD 환경에서의 분리 현상:** 가상현실 헤드마운트 디스플레이(HMD)를 사용할 경우, 자연스럽게 연동되어야 할 수렴과 조절 기능이 분리되는 현상이 발생하게 됩니다 [1].
-- **신체적 부작용 및 증상:** 수렴과 조절의 분리는 깊이 지각(depth perception)을 위한 망막 단서에 불확실성을 초래합니다 [1]. 결과적으로 사용자는 두통, 눈의 통증(sore eyes), 피로감, 복시(double vision)와 같은 동반 증상을 겪을 수 있습니다 [1].
-- **VR 멀미와의 연관성:** 수렴-조절 불일치는 HMD 사용 시 나타나는 안구 운동 증상의 원인으로 지목됩니다 [2]. 다만, 이 불일치 현상이 특정 개인에게 VR 멀미를 발생시키는 직접적인 원인인지, 아니면 기존의 멀미 증상의 심각성을 더욱 악화시키는 복합적 요인인지에 대해서는 명확히 규명되지 않았습니다 [2].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[가상현실 멀미(VR Sickness)]], [[안구 운동(Oculomotor Functions)]], [[깊이 지각(Depth Perception)]], [[헤드마운트 디스플레이(HMD)]]
-- **Projects/Contexts:** [[가상현실(VR) 시뮬레이션 및 엑서게임(Exergaming) 사용 환경]]
-- **Contradictions/Notes:** 소스에 따르면 수렴-조절 불일치가 가상현실 멀미를 유발하는 직접적 원인인지, 혹은 멀미 증상을 가중시키는 요인인지에 대한 명확한 인과관계는 아직 불분명한 것으로 나타납니다 [2].
-
----
-*Last updated: 2026-04-19*
-- Raw Source: [[00_Raw/2026-04-20/수렴-조절 불일치(Vergence-Accommodation Conflict).md]]
----
diff --git a/Programming & Language/순차적 게이트 아키텍처.md b/Programming & Language/순차적 게이트 아키텍처.md
deleted file mode 100644
index 1a842a82..00000000
--- a/Programming & Language/순차적 게이트 아키텍처.md	
+++ /dev/null
@@ -1,30 +0,0 @@
----
-id: P-REINFORCE-AUTO-048BB2
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - 순차적 게이트 아키텍처"
----
-
-# [[순차적 게이트 아키텍처]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 소스에 관련 정보가 부족합니다.
-
-## 📖 구조화된 지식 (Synthesized Content)
-소스에 관련 정보가 부족합니다.
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** 소스에 관련 정보가 부족합니다.
-- **Projects/Contexts:** 소스에 관련 정보가 부족합니다.
-- **Contradictions/Notes:** 소스에 관련 정보가 부족합니다.
-
----
-*Last updated: 2026-04-19*
-- Raw Source: [[00_Raw/2026-04-20/순차적 게이트 아키텍처.md]]
----
diff --git a/Programming & Language/스캐빈저(Scavenger) _ 마이너 GC.md b/Programming & Language/스캐빈저(Scavenger) _ 마이너 GC.md
deleted file mode 100644
index 901bca29..00000000
--- a/Programming & Language/스캐빈저(Scavenger) _ 마이너 GC.md	
+++ /dev/null
@@ -1,34 +0,0 @@
----
-id: P-REINFORCE-AUTO-8AD1F6
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - 스캐빈저(Scavenger) _ 마이너 GC"
----
-
-# [[스캐빈저(Scavenger) _ 마이너 GC]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 스캐빈저(Scavenger) 또는 마이너 GC(Minor GC)는 V8 엔진 및 IBM JVM 등에서 새롭게 생성된 객체들이 할당되는 '젊은 세대(Young Generation, New-space, Nursery)' 영역을 대상으로 빠르고 빈번하게 수행되는 가비지 컬렉션 주기입니다 [1-3]. 대부분의 객체가 금방 소멸한다는 '세대 가설(Generational Hypothesis)'에 기반하여 작동하며, 살아남은 객체만을 새로운 공간으로 복사하고 나머지는 폐기하여 메모리를 효율적으로 관리하고 단편화를 방지합니다 [1, 4, 5].
-
-## 📖 구조화된 지식 (Synthesized Content)
-- **공간 분할 및 체니 알고리즘(Cheney's algorithm):** V8 엔진에서 스캐빈저는 젊은 세대 공간을 두 개의 동일한 크기인 반공간(to-space와 from-space)으로 나눕니다 [3, 6, 7]. 할당 포인터가 새 공간의 끝에 도달하여 공간이 채워지면 마이너 GC가 트리거되어 두 공간의 역할을 바꿉니다 [5, 6, 8].
-- **객체 대피(Evacuation)와 단편화 해결:** 루트 객체 및 구세대에서 신세대로 향하는 참조(쓰기 장벽을 통해 추적됨)에서 시작하여 모든 활성(Live) 객체를 식별합니다 [8-10]. 이 활성 객체들은 새로운 공간으로 복사(대피)되며, 이 과정에서 객체들이 연속적으로 배치되므로 메모리 단편화가 완전히 제거됩니다 [6, 8, 10].
-- **객체의 승급(Promotion):** 마이너 GC 과정 중 두 번의 가비지 컬렉션 주기에서 생존한 객체는 수명이 긴 객체로 간주되어 올드 스페이스(Old-space)로 승급됩니다 [1, 8, 11, 12]. 객체가 이동할 때 기존 위치에 전달 주소(Forwarding address)를 남겨, 해당 객체를 참조하던 다른 포인터들이 새로운 위치를 가리키도록 업데이트합니다 [9, 11].
-- **병렬 스캐빈저(Parallel Scavenger) 최적화:** 최신 V8의 Orinoco 프로젝트는 스캐빈저 작업에 헬퍼 스레드를 도입하여 메인 스레드와 병렬로 작업을 분산시킵니다 [13, 14]. 복수의 스레드가 동일한 객체 대피를 시도할 때 원자적(atomic) 읽기/쓰기/비교 교환 연산으로 동기화하며, 이 최적화를 통해 메인 스레드에서 젊은 세대 GC에 소요되는 총 시간을 약 20~50% 감소시켰습니다 [13, 15, 16].
-- **IBM JVM(OpenJ9)의 Scavenge 연산:** IBM의 `gencon` 정책에서도 `nursery` 영역의 메모리 할당 실패 시 스캐빈지 작업이 트리거됩니다 [2, 17]. 활성 객체를 식별하기 위한 루트 스캔(Initial 단계), `allocate` 공간에서 `survivor` 공간 또는 일정 나이에 도달 시 `tenure` 공간으로 객체를 복사하는 재귀적 추적(Main 단계), 그리고 약한 참조(Weak reference)를 처리하는 단계(Final 단계)로 구성됩니다 [2].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[세대 가설(Generational Hypothesis)]], [[메이저 GC(Major GC) / Mark-Compact]], [[쓰기 장벽(Write Barriers)]], [[뉴 스페이스(New Space) / 젊은 세대]], [[올드 스페이스(Old Space)]]
-- **Projects/Contexts:** [[V8 엔진(V8 Engine)]], [[Orinoco 프로젝트]], [[IBM OpenJ9 (gencon 정책)]]
-- **Contradictions/Notes:** 소스 전반에 걸쳐 V8 엔진과 IBM JVM의 세부 구현 용어(예: New-space와 Nursery)에는 차이가 있으나, 새롭게 할당된 객체 영역을 정기적으로 비우고 살아남은 객체를 다른 영역이나 구세대로 이동시킨다는 스캐빈저의 기본 동작 원리와 목적은 동일합니다 [2, 3, 6].
-
----
-*Last updated: 2026-04-19*
-- Raw Source: [[00_Raw/2026-04-20/스캐빈저(Scavenger) _ 마이너 GC.md]]
----
diff --git a/Programming & Language/스택 트레이스(Stack trace).md b/Programming & Language/스택 트레이스(Stack trace).md
deleted file mode 100644
index 6bbb844d..00000000
--- a/Programming & Language/스택 트레이스(Stack trace).md	
+++ /dev/null
@@ -1,33 +0,0 @@
----
-id: P-REINFORCE-AUTO-8FAFC5
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - 스택 트레이스(Stack trace)"
----
-
-# [[스택 트레이스(Stack trace)]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 스택 트레이스(Stack trace) 자체에 대한 기술적이고 포괄적인 정의는 소스에 관련 정보가 부족합니다. 제공된 소스에 따르면, 스택 트레이스는 코드 내에서 특정 객체가 할당되거나 생성된 정확한 위치를 보여주는 기록을 의미합니다 [1, 2]. 주로 브라우저의 개발자 도구나 IDE의 프로파일링 과정에서 메모리 누수(Memory leak) 원인을 찾거나 예외(Exception)를 분석하는 목적으로 활용됩니다 [3, 4].
-
-## 📖 구조화된 지식 (Synthesized Content)
-- **메모리 할당 위치 식별**: Chrome의 할당 타임라인(Allocation Timeline) 도구는 특정 시간 동안 발생한 모든 메모리 할당 내역을 스택 트레이스와 함께 기록합니다 [1]. 개발자는 '힙 할당 스택 트레이스 기록(Record heap allocation stack traces)' 설정을 활성화하여 특정 객체를 할당하는 데 책임이 있는 코드 영역을 파악할 수 있습니다 [3].
-- **메모리 누수 디버깅 효율화**: 프로파일링 도구에서 '할당 스택(Allocation stack)' 탭을 확인하면 해당 객체(예: 문자열 등)가 정확히 어디서 생성되었는지 알려주는 스택 트레이스를 볼 수 있습니다 [2]. 이러한 스택 트레이스는 코드를 일일이 읽어가며 누수 지점을 찾는 것보다 훨씬 빠르게 수정이 필요한 코드 위치를 짚어줍니다 [5].
-- **예외(Exception) 분석**: IntelliJ IDEA와 같은 개발 환경(IDE)에서 V8 CPU 프로파일링을 분석할 때, 특정 함수 호출에 대한 스택 트레이스로 이동하여 발생한 예외를 확인하고 분석할 수 있습니다 [4].
-- *(주의: 스택 트레이스가 메모리 구조 내에서 어떻게 생성되고 유지되는지에 대한 근본적인 메커니즘 등은 소스에 관련 정보가 부족합니다.)*
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[Memory Leak]], [[Allocation Timeline]], [[V8 JavaScript Engine]]
-- **Projects/Contexts:** [[Chrome DevTools]], [[IntelliJ IDEA V8 CPU Profiling]]
-- **Contradictions/Notes:** 제공된 소스는 스택 트레이스를 주로 메모리 누수 및 성능 프로파일링을 위한 '도구적 관점'에서만 다루고 있으며, 스택 트레이스의 근본적인 동작 원리에 대해서는 소스에 관련 정보가 부족합니다.
-
----
-*Last updated: 2026-04-19*
-- Raw Source: [[00_Raw/2026-04-20/스택 트레이스(Stack trace).md]]
----
diff --git a/Programming & Language/스트랭글러 피그 패턴(Strangler Fig Pattern).md b/Programming & Language/스트랭글러 피그 패턴(Strangler Fig Pattern).md
deleted file mode 100644
index ec532032..00000000
--- a/Programming & Language/스트랭글러 피그 패턴(Strangler Fig Pattern).md	
+++ /dev/null
@@ -1,34 +0,0 @@
----
-id: P-REINFORCE-AUTO-739808
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - 스트랭글러 피그 패턴(Strangler Fig Pattern)"
----
-
-# [[스트랭글러 피그 패턴(Strangler Fig Pattern)]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 스트랭글러 피그 패턴(Strangler Fig Pattern)은 크고 복잡한 레거시 시스템을 새로운 시스템으로 마이그레이션할 때 수반되는 위험을 줄이기 위해 도입하는 아키텍처 패턴입니다 [1]. 이 패턴은 새로운 시스템이 기존의 오래된 시스템을 둘러싸며 점진적으로 자라나도록(grow around) 유도하는 방식을 취합니다 [1]. 최종적으로는 새롭게 구축된 시스템이 구형 시스템을 완전히 대체하게 됩니다 [1].
-
-## 📖 구조화된 지식 (Synthesized Content)
-- **도입 목적과 위험 완화:** 대규모의 복잡한 레거시 시스템을 한 번에 전면적으로 새로운 시스템으로 이전하는 것은 수많은 재설계(re-engineering) 프로젝트의 실패 사례에서 보듯 매우 위험하고 거대한 도약입니다 [1]. 스트랭글러 피그 패턴은 시스템 마이그레이션 과정에서 발생할 수 있는 이러한 치명적인 위험을 줄이기 위한 목적으로 채택됩니다 [1].
-- **작동 방식:** 새로운 시스템이 기존 시스템 주변에서 점진적으로 성장하게 하여, 구형 시스템의 기능들을 서서히 대체하는 방식으로 작동하며 마침내 기존 시스템을 완전히 밀어내고 대체하게 됩니다 [1].
-- **적용 사례 (Netflix):** 넷플릭스(Netflix)는 7년 이상 운영되어 거대하고 복잡해진 3세대 미디어 처리 파이프라인인 기존의 'Reloaded' 시스템을 마이크로서비스 및 서버리스 기반의 새로운 플랫폼인 'Cosmos'로 전환하기 위해 스트랭글러 피그 패턴을 사용했습니다 [2], [1].
-
-(※ 스트랭글러 피그 패턴의 구체적인 기술적 구현 절차나 상세 아키텍처 구조에 대해서는 소스에 관련 정보가 부족합니다.)
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[마이크로서비스(Microservices)]], [[레거시 시스템 마이그레이션]]
-- **Projects/Contexts:** [[넷플릭스 Cosmos 플랫폼(Netflix Cosmos Platform)]], [[Reloaded 시스템]]
-- **Contradictions/Notes:** 소스 내에서 스트랭글러 피그 패턴에 대한 상반된 주장이나 모순점은 발견되지 않습니다. 다만 개념의 기본 정의와 넷플릭스의 도입 사례만 간략히 언급되어 있으며, 그 외의 상세한 설계 방법론에 대해서는 소스에 관련 정보가 부족합니다.
-
----
-*Last updated: 2026-04-18*
-- Raw Source: [[00_Raw/2026-04-20/스트랭글러 피그 패턴(Strangler Fig Pattern).md]]
----
diff --git a/Programming & Language/스파게티 코드 (Spaghetti Code).md b/Programming & Language/스파게티 코드 (Spaghetti Code).md
deleted file mode 100644
index 4ba48ef8..00000000
--- a/Programming & Language/스파게티 코드 (Spaghetti Code).md	
+++ /dev/null
@@ -1,32 +0,0 @@
----
-id: P-REINFORCE-AUTO-9FBF28
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - 스파게티 코드 (Spaghetti Code)"
----
-
-# [[스파게티 코드 (Spaghetti Code)]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 스파게티 코드는 알고리즘의 논리를 작성하거나 파악할 때 여러 기능이나 모듈 사이를 빈번하게 뛰어다녀야 하는 복잡하게 얽힌 상태의 코드를 의미합니다. 이는 시스템 내 코드의 응집도(Cohesion)가 낮다는 것을 보여주는 대표적인 신호입니다. 이러한 코드는 실행 흐름을 추적하기 어렵게 만들어 유지보수성과 가독성을 크게 떨어뜨립니다.
-
-## 📖 구조화된 지식 (Synthesized Content)
-- **응집도 저하의 결과물:** 로직의 흐름을 따라가기 위해 이곳저곳의 함수나 모듈 사이를 계속해서 점프해야 한다면, 이는 해당 코드의 응집도가 낮다는 것을 의미하며 소프트웨어 공학에서는 이를 종종 '스파게티 코드'라고 부릅니다 [1-3]. 
-- **설계 원칙의 부재:** 스파게티 코드는 프로그램의 각 부분이 서로 다른 기능이나 특정 관심사에만 집중하도록 설계하는 '관심사의 분리(Separation of Concerns, SoC)' 원칙이 제대로 지켜지지 않았을 때 나타납니다 [4, 5]. 
-- **해결 및 개선 방향:** 스파게티 코드를 방지하고 해결하기 위해서는 밀접하게 관련되지 않은 기능들을 분리하고, 동일하고 고유한 목적을 제공하는 기능들끼리 논리적으로 그룹화하여 높은 응집도(High Cohesion)를 확보해야 합니다 [6, 7].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[응집도 (Cohesion)]], [[관심사의 분리 (Separation of Concerns)]]
-- **Projects/Contexts:** 소스에 관련 정보가 부족합니다.
-- **Contradictions/Notes:** 소스에 관련 정보가 부족합니다.
-
----
-*Last updated: 2026-04-18*
-- Raw Source: [[00_Raw/2026-04-20/스파게티 코드 (Spaghetti Code).md]]
----
diff --git a/Programming & Language/스포티파이 자율적 분대 모델 (Spotify Squad).md b/Programming & Language/스포티파이 자율적 분대 모델 (Spotify Squad).md
deleted file mode 100644
index 61edd362..00000000
--- a/Programming & Language/스포티파이 자율적 분대 모델 (Spotify Squad).md	
+++ /dev/null
@@ -1,33 +0,0 @@
----
-id: P-REINFORCE-AUTO-376368
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - 스포티파이 자율적 분대 모델 (Spotify Squad)"
----
-
-# [[스포티파이 자율적 분대 모델 (Spotify Squad)]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 스포티파이(Spotify) 자율적 분대 모델은 조직 구조와 개발 방식에 관심사의 분리(SoC) 원칙을 적용하여 팀 간 의존성을 최소화하고 독립성을 극대화한 조직 운영 모델입니다 [1]. 엔지니어링 조직을 '스쿼드(Squad)'라는 소규모 독립 단위로 나누어 운영하는 것이 핵심입니다 [1]. 이를 통해 조직의 확장성과 유지보수성을 개선하고 병목 현상을 방지합니다 [1].
-
-## 📖 구조화된 지식 (Synthesized Content)
-- **스쿼드(Squad) 모델을 통한 조직적 관심사 분리:** 스포티파이는 엔지니어링 조직을 '스쿼드'라는 작은 단위로 분할하여 비즈니스 관심사에 따른 조직 분리를 실현했습니다 [1].
-- **독립적인 권한과 책임:** 각 스쿼드는 플레이리스트 생성, 검색, 결제 등 특정 기능 영역에 대해 완전한 책임을 지며, 디자인, 개발, 테스트, 배포에 이르는 전 과정을 독자적으로 수행합니다 [1]. 이러한 구조는 한 팀의 작업 지연이 다른 팀의 병목 현상으로 이어지는 문제를 혁신적으로 줄여줍니다 [1].
-- **마이크로 프론트엔드(Micro Frontends) 기술의 적용:** 프론트엔드 측면에서도 거대한 모놀리식 웹 앱을 쪼개어 스쿼드별로 독립적인 개발이 가능한 작은 모듈로 결합하는 방식을 사용합니다 [1]. 각 스쿼드는 추천 섹션이나 라이브 채팅창과 같이 자신이 맡은 화면의 일부분을 각자 선호하는 기술 스택으로 구축하고 배포할 수 있어 팀 간의 기술적 간섭을 차단합니다 [1].
-- **백엔드 마이크로서비스 지원:** 스포티파이는 컨테이너와 쿠버네티스(Kubernetes)를 활용하여 수천 개의 백엔드 마이크로서비스를 오케스트레이션합니다 [2]. 이러한 아키텍처는 개발 팀(스쿼드)이 새로운 기능을 더욱 독립적이고 빈번하게 배포할 수 있는 기술적 기반을 제공합니다 [2, 3].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[관심사의 분리 (Separation of Concerns)]], [[마이크로 프론트엔드 (Micro Frontends)]], [[마이크로서비스 아키텍처 (Microservices Architecture)]]
-- **Projects/Contexts:** 대규모 개발 환경에서 팀 간 기술적 간섭을 차단하고, 복잡한 애플리케이션의 확장성과 유지보수성을 획기적으로 개선하기 위한 맥락에서 적용되었습니다 [1].
-- **Contradictions/Notes:** 독립적인 스쿼드 운영을 위한 마이크로 프론트엔드 방식을 사용할 경우, 여러 모듈이 동시에 로드되면서 번들 크기가 커지고 초기 로딩 성능에 오버헤드가 발생할 수 있다는 기술적 과제가 공존합니다 [1].
-
----
-*Last updated: 2026-04-18*
-- Raw Source: [[00_Raw/2026-04-20/스포티파이 자율적 분대 모델 (Spotify Squad).md]]
----
diff --git a/Programming & Language/스포티파이 자율적 분대 모델 및 마이크로 프론트엔드 (Spotify Squads and Micro Frontends).md b/Programming & Language/스포티파이 자율적 분대 모델 및 마이크로 프론트엔드 (Spotify Squads and Micro Frontends).md
deleted file mode 100644
index 56cf97a3..00000000
--- a/Programming & Language/스포티파이 자율적 분대 모델 및 마이크로 프론트엔드 (Spotify Squads and Micro Frontends).md	
+++ /dev/null
@@ -1,42 +0,0 @@
----
-id: P-REINFORCE-AUTO-4B797C
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - 스포티파이 자율적 분대 모델 및 마이크로 프론트엔드 (Spotify Squads and Micro Frontends)"
----
-
-# [[스포티파이 자율적 분대 모델 및 마이크로 프론트엔드 (Spotify Squads and Micro Frontends)]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 스포티파이는 조직 구조와 프론트엔드 개발 방식 모두에 '관심사의 분리(SoC)' 원칙을 적용하여 팀 간의 의존성을 최소화하고 독립성을 극대화한 대표적인 사례입니다 [1]. 조직적으로는 '스쿼드(Squad)'라는 소규모 자율 조직 모델을 도입하여 특정 비즈니스 기능의 디자인부터 배포까지의 모든 과정을 전담하도록 구성했습니다 [1]. 기술적으로는 단일한 거대 웹 애플리케이션을 쪼개어 각 스쿼드가 자신만의 기술 스택으로 웹 플레이어의 특정 부분을 독립적으로 구축하는 마이크로 프론트엔드 아키텍처를 채택했습니다 [1, 2]. 이를 통해 스포티파이는 대규모 시스템 환경에서도 확장성을 확보하고, 한 팀의 작업이 다른 팀의 병목이 되는 현상을 혁신적으로 줄여 더 빠른 릴리스와 유연성을 달성했습니다 [1, 2].
-
-## 📖 구조화된 지식 (Synthesized Content)
-**조직적 관심사 분리: 스쿼드(Squad) 모델**
-- 스포티파이의 스쿼드는 엔지니어링 조직을 나눈 작은 자율적 단위로, 플레이리스트 생성, 검색, 결제 등과 같은 '특정 기능'에 대해 완전한 책임을 집니다 [1].
-- 각 스쿼드는 디자인, 개발, 테스트, 배포에 이르는 전체 생명주기를 독자적으로 수행할 수 있는 권한과 책임을 가집니다 [1].
-- 이는 단순히 기술적 계층을 분리하는 것을 넘어 '비즈니스 관심사에 따른 조직의 분리'를 의미하며, 한 팀의 작업 지연이나 간섭이 다른 팀의 병목 현상을 초래하는 것을 원천적으로 차단합니다 [1].
-
-**기술적 관심사 분리: 마이크로 프론트엔드 및 컨테이너화된 마이크로서비스**
-- 프론트엔드 개발에 있어 거대한 모놀리식(Monolithic) 웹 앱을 잘게 쪼개어 독립적으로 개발된 소규모 모듈들을 결합하는 마이크로 프론트엔드 방식을 사용합니다 [1].
-- 스쿼드마다 추천 섹션, 라이브 채팅창 등 웹 플레이어 화면의 각기 다른 일부분을 소유하며, 사용자 인터페이스부터 백엔드까지 독립적으로 책임집니다 [1, 2].
-- 각 팀은 자신이 선호하는 기술 스택을 자유롭게 선택하여 구축 및 배포를 진행할 수 있으므로, 대규모의 복잡한 웹 애플리케이션에서 확장성과 유지보수성이 획기적으로 개선됩니다 [1].
-- 백엔드 시스템 측면에서도 스포티파이는 컨테이너와 쿠버네티스(Kubernetes)를 활용해 수천 개의 마이크로서비스를 오케스트레이션하여 새로운 기능을 독립적이고 빈번하게 배포하고 있습니다 [3].
-
-**한계점 및 과제**
-- 마이크로 프론트엔드 구조 하에서는 여러 개의 마이크로 프론트엔드 모듈이 동시에 로드되기 때문에, 번들 크기가 커지고 초기 로딩 성능에 오버헤드가 발생할 수 있다는 기술적 과제가 공존합니다 [1].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[관심사의 분리 (Separation of Concerns)]], [[마이크로 프론트엔드 (Micro Frontends)]], [[마이크로서비스 아키텍처 (Microservices Architecture)]]
-- **Projects/Contexts:** [[대규모 웹 애플리케이션의 조직 및 기술적 확장성 확보]]
-- **Contradictions/Notes:** 모놀리식(Monolithic) 구조를 탈피한 스포티파이의 방식은 확장성과 팀의 자율성을 크게 향상시키지만, 여러 마이크로 프론트엔드의 동시 로드로 인한 번들 크기 증가 및 초기 로딩 성능 저하라는 기술적 오버헤드와 트레이드오프(Trade-off) 관계에 있습니다 [1].
-
----
-*Last updated: 2026-04-18*
-- Raw Source: [[00_Raw/2026-04-20/스포티파이 자율적 분대 모델 및 마이크로 프론트엔드 (Spotify Squads and Micro Frontends).md]]
----
diff --git a/Programming & Language/스포티파이 자율적 분대 모델.md b/Programming & Language/스포티파이 자율적 분대 모델.md
deleted file mode 100644
index 12a29382..00000000
--- a/Programming & Language/스포티파이 자율적 분대 모델.md	
+++ /dev/null
@@ -1,32 +0,0 @@
----
-id: P-REINFORCE-AUTO-14D145
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - 스포티파이 자율적 분대 모델"
----
-
-# [[스포티파이 자율적 분대 모델]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 스포티파이의 자율적 분대(Squad) 모델은 조직 구조와 개발 방식에 '관심사의 분리(SoC)' 철학을 적용하여 팀 간의 의존성을 최소화한 조직 운영 방식입니다 [1]. 엔지니어링 조직을 '스쿼드'라는 소규모 단위로 나누어 각 팀이 독립적으로 움직일 수 있도록 지원합니다 [1]. 이를 통해 한 팀의 작업이 다른 팀의 병목을 초래하는 현상을 혁신적으로 줄이고 확장성을 획기적으로 개선했습니다 [1].
-
-## 📖 구조화된 지식 (Synthesized Content)
-* **조직적 관심사 분리(SoC) 적용:** 스포티파이는 비즈니스 관심사에 따라 엔지니어링 조직을 '스쿼드(Squad)'라는 작은 단위로 분할했습니다 [1]. 각 스쿼드는 플레이리스트 생성, 검색, 결제 등 특정 기능에 대해 완전한 책임을 지며 독자적으로 운영됩니다 [1].
-* **자율적인 개발 사이클 수행:** 각 스쿼드는 기능의 디자인부터 개발, 테스트, 배포에 이르는 소프트웨어 개발의 전 과정을 팀 내부에서 독자적으로 처리합니다 [1]. 이러한 자율적 모델은 팀 간 의존성을 최소화하여 한 팀의 작업이 다른 팀의 병목을 유발하는 현상을 획기적으로 방지합니다 [1]. 
-* **마이크로 프론트엔드 기술과의 결합:** 스포티파이는 조직 구조의 분리뿐만 아니라 기술 스택에도 동일한 철학을 적용했습니다 [1]. 거대한 모놀리식 웹 앱을 쪼개어 독립된 작은 모듈로 결합하는 마이크로 프론트엔드 방식을 채택하였으며, 이를 통해 각 스쿼드(팀)는 사용자 인터페이스부터 백엔드까지 자신들이 맡은 화면의 일부분을 각자가 선호하는 기술 스택으로 구축하고 배포할 수 있어 타 팀과의 기술적 간섭을 강력하게 차단합니다 [1, 2].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[관심사의 분리 (SoC)]], [[마이크로 프론트엔드 (Micro Frontends)]]
-- **Projects/Contexts:** [[스포티파이 (Spotify) 웹 애플리케이션 개발]]
-- **Contradictions/Notes:** 스포티파이의 자율적 분대 모델과 결합된 마이크로 프론트엔드 방식은 대규모 웹 애플리케이션에서 팀 간 독립성과 유지보수성을 크게 높여주지만, 여러 개의 마이크로 프론트엔드가 로드되면서 번들 크기가 커지고 초기 로딩 성능에 오버헤드가 발생할 수 있다는 기술적 과제가 공존합니다 [1].
-
----
-*Last updated: 2026-04-18*
-- Raw Source: [[00_Raw/2026-04-20/스포티파이 자율적 분대 모델.md]]
----
diff --git a/Programming & Language/스포티파이(Spotify)의 스쿼드 모델 및 마이크로 프론트엔드 도입.md b/Programming & Language/스포티파이(Spotify)의 스쿼드 모델 및 마이크로 프론트엔드 도입.md
deleted file mode 100644
index 3623a8e7..00000000
--- a/Programming & Language/스포티파이(Spotify)의 스쿼드 모델 및 마이크로 프론트엔드 도입.md	
+++ /dev/null
@@ -1,44 +0,0 @@
----
-id: P-REINFORCE-AUTO-5B6582
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - 스포티파이(Spotify)의 스쿼드 모델 및 마이크로 프론트엔드 도입"
----
-
-# [[스포티파이(Spotify)의 스쿼드 모델 및 마이크로 프론트엔드 도입]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 스포티파이(Spotify)는 팀 간의 의존성을 최소화하고 독립성을 극대화하기 위해 조직 구조와 프론트엔드 개발 방식 모두에 관심사의 분리(SoC) 원칙을 적용했습니다. 조직을 특정 기능에 대해 완전한 책임을 지는 '스쿼드(Squad)'라는 소규모 단위로 나누고, 거대한 모놀리식 웹 앱을 쪼개어 독립적인 모듈로 결합하는 '마이크로 프론트엔드(Micro Frontends)' 방식을 채택했습니다. 이를 통해 스포티파이는 팀 간의 기술적 간섭을 차단하고 확장성 및 유지보수성을 획기적으로 개선하며 전 세계적인 벤치마킹 대상이 되었습니다.
-
-## 📖 구조화된 지식 (Synthesized Content)
-* **도입 철학 및 배경:**
-  스포티파이는 '팀 간의 의존성을 최소화하여 독립적으로 움직이게 한다'는 철학을 바탕으로 조직 구조와 기술 스택 전반에 관심사의 분리(SoC)를 적용했습니다 [1]. 이는 기능 개발 시 다른 팀으로 인해 발생하는 병목 현상을 방지하고, 대규모 복잡한 웹 애플리케이션의 유연성을 확보하기 위함입니다 [1, 2].
-
-* **조직적 SoC: 스쿼드(Squad) 모델:**
-  스포티파이는 엔지니어링 조직을 '스쿼드'라는 작은 단위로 분할했습니다 [1]. 
-  * 각 스쿼드는 플레이리스트 생성, 검색, 결제 등 특정 비즈니스 기능에 대해 완전한 책임을 집니다 [1].
-  * 디자인, 개발, 테스트, 배포를 독자적으로 수행할 수 있도록 구성되어 비즈니스 관심사에 따른 조직의 분리를 이뤄냈습니다 [1].
-
-* **기술적 SoC: 마이크로 프론트엔드(Micro Frontends)의 도입:**
-  조직 구조에 맞춰 프론트엔드 기술 측면에서도 거대한 모놀리식 웹 앱을 쪼개어 독립적으로 개발된 작은 모듈(Micro Frontends)로 결합하는 방식을 채택했습니다 [1].
-  * 각 분리된 팀은 사용자 인터페이스(UI)부터 백엔드에 이르는 웹 플레이어의 일부분(예: 추천 섹션, 라이브 채팅창 등)을 온전히 소유합니다 [1, 2].
-  * 팀마다 각자가 선호하는 기술 스택을 선택하여 독립적으로 구축하고 배포할 수 있어, 팀 간 기술적 간섭을 차단하고 더 빠른 릴리스와 유연성을 보장합니다 [1, 2].
-
-* **추가적인 기술 환경(백엔드 및 데이터):**
-  프론트엔드뿐만 아니라 백엔드 측면에서도 컨테이너와 Kubernetes를 활용하여 수천 개의 백엔드 마이크로서비스를 오케스트레이션하여 새 기능을 독립적이고 빈번하게 배포합니다 [3]. 또한, 분석 및 데이터 변환 과정에서도 dbt 프레임워크를 도입해 CI/CD 파이프라인을 통한 효과적인 협업 및 배포 환경을 갖추고 있습니다 [4].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[관심사의 분리(SoC)]], [[마이크로 프론트엔드(Micro Frontends)]], [[마이크로서비스 아키텍처(MSA)]]
-- **Projects/Contexts:** [[스포티파이 웹 플레이어(Spotify Web Player)]]
-- **Contradictions/Notes:** 마이크로 프론트엔드 구조는 확장성과 유지보수성을 비약적으로 개선하지만, 동시에 여러 마이크로 프론트엔드가 로드되면서 번들 크기가 커지고 초기 로딩 성능에 오버헤드가 발생할 수 있다는 단점 및 과제가 공존한다고 소스는 지적합니다 [1].
-
----
-*Last updated: 2026-04-18*
-- Raw Source: [[00_Raw/2026-04-20/스포티파이(Spotify)의 스쿼드 모델 및 마이크로 프론트엔드 도입.md]]
----
diff --git a/Programming & Language/습관 교정 프로그램.md b/Programming & Language/습관 교정 프로그램.md
deleted file mode 100644
index db2c2082..00000000
--- a/Programming & Language/습관 교정 프로그램.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-240BA8
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - 습관 교정 프로그램"
----
-
-# [[습관 교정 프로그램]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/습관 교정 프로그램.md]]
----
diff --git a/Programming & Language/시각 및 인지적 후유증 연구.md b/Programming & Language/시각 및 인지적 후유증 연구.md
deleted file mode 100644
index 307c1660..00000000
--- a/Programming & Language/시각 및 인지적 후유증 연구.md	
+++ /dev/null
@@ -1,40 +0,0 @@
----
-id: P-REINFORCE-AUTO-F81826
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - 시각 및 인지적 후유증 연구"
----
-
-# [[시각 및 인지적 후유증 연구]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 가상현실(VR) 환경, 특히 헤드마운트 디스플레이(HMD)를 사용하는 엑서게임(Exergaming) 후 발생하는 시각 및 인지적 후유증(aftereffects)을 정량적으로 측정하고 분석하는 연구입니다 [1, 2]. 이 연구는 짧은 시간(10분)과 긴 시간(50분)의 VR 노출 전, 노출 직후, 그리고 40분 후로 나누어 사용자의 시력 조절(accommodation), 폭주(convergence), 반응 시간, 주관적 멀미 증상을 평가합니다 [2]. 사용자가 겪는 VR 멀미가 심도 지각과 인지에 미치는 영향을 파악하여, VR의 안전한 사용 및 잠재적 부상 위험을 줄이기 위한 권장 사항을 제공하는 데 목적이 있습니다 [1, 3].
-
-## 📖 구조화된 지식 (Synthesized Content)
-* **시각적 후유증 (Visual Aftereffects):**
-  VR 노출 시간에 관계없이 노출 직후 **안구의 조절(accommodation)과 폭주(convergence) 기능에 유의미한 변화가 발생**합니다 [4]. 이는 HMD에서 제공되는 깊이 단서가 충돌(vergence-accommodation conflict)함으로써 조절과 폭주 작용이 분리(decoupled)되기 때문으로 분석됩니다 [4, 5]. 이러한 안구 운동의 변화는 현실 세계에서의 심도 지각(depth perception)에 일시적인 영향을 미칠 수 있습니다 [4]. 하지만 이러한 시각적 후유증은 **VR 종료 40분 후에는 대부분 기준치(baseline) 수준으로 회복**되어 단기적인 특성을 보였습니다 [4, 6].
-
-* **인지적 후유증 (Cognitive Aftereffects):**
-  인지 능력의 변화를 측정하기 위해 CANTAB 5-선택 반응 시간 과제(RTI)를 수행한 결과, **VR 노출 직후 의사결정 속도(decision speed)가 유의미하게 느려지는 등 반응 시간에 변화가 관찰**되었습니다 [7]. 하지만 움직임 속도(movement speed)나 노출 시간에 따른 인지적 후유증의 차이는 유의미하지 않았으며, 전반적인 인지 능력 저하에 대한 심각한 우려는 없는 것으로 나타났습니다 [6, 7].
-
-* **주관적 멀미 증상 및 회복 양상 (VR Sickness & Recovery):**
-  시뮬레이터 멀미 설문(SSQ) 점수는 VR 노출 직후 크게 상승하며, **10분 노출보다 50분 노출 시 훨씬 더 심한 증상**을 유발합니다 [6, 8]. 대체로 40분의 대기 시간 후에는 멀미 수준이 기준치로 회복되지만, 소수의 참가자(약 14%)는 50분 노출 후 40분이 지난 시점에서도 여전히 높은 수준의 멀미를 보고했습니다 [6]. 특히 짧은 노출 후 높은 수준의 증상을 보인 사용자는 긴 노출 시에도 심각한 증상을 겪을 확률이 매우 높습니다 [6].
-
-* **안전 권장 사항:**
-  이러한 후유증의 회복을 고려할 때, VR 사용자들은 긴 노출 전에 짧은 세션을 먼저 시도해 보아야 하며, **VR 종료 후에는 자동차 운전과 같이 부상 위험이 있는 활동을 수행하기 전에 증상이 기준치로 회복될 때까지 충분한 대기 시간(약 40분 이상)을 가져야** 합니다 [3].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[가상현실 멀미(VR Sickness)]], [[조절-폭주 불일치(Vergence-Accommodation Conflict)]], [[반응 시간(Reaction Time)]]
-- **Projects/Contexts:** [[비트 세이버 엑서게임 후유증 평가(Beat Saber Exergaming Aftereffects)]]
-- **Contradictions/Notes:** VR 노출이 자극에 빠르게 반응하는 인지 능력(반응 시간)에 미치는 직각적인 영향에 대해서 문헌상으로 반응 속도가 느려진다는 연구와 빨라진다는 연구가 혼재되어 일관성이 다소 부족하다는 점이 지적됩니다 [9].
-
----
-*Last updated: 2026-04-19*
-- Raw Source: [[00_Raw/2026-04-20/시각 및 인지적 후유증 연구.md]]
----
diff --git a/Programming & Language/시각-전정 갈등 (Visual-Vestibular Conflict).md b/Programming & Language/시각-전정 갈등 (Visual-Vestibular Conflict).md
deleted file mode 100644
index 705447ff..00000000
--- a/Programming & Language/시각-전정 갈등 (Visual-Vestibular Conflict).md	
+++ /dev/null
@@ -1,31 +0,0 @@
----
-id: P-REINFORCE-AUTO-495C24
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - 시각-전정 갈등 (Visual-Vestibular Conflict)"
----
-
-# [[시각-전정 갈등 (Visual-Vestibular Conflict)]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 시각-전정 갈등(Visual-Vestibular Conflict)은 가상 현실(VR) 환경 등에서 시각적으로 주어지는 경험과 사용자의 실제 신체적·육체적(전정) 감각이 일치하지 않을 때 발생하는 현상입니다 [1]. 인간이 환경과 상호작용하는 데 필수적인 감각 통합 과정에 교란을 일으키는 것이 특징입니다 [1]. 이 현상은 VR 환경에서 메스꺼움이나 방향 감각 상실과 같은 멀미 증상을 유발하는 주요 이론적 원인으로 설명됩니다 [1].
-
-## 📖 구조화된 지식 (Synthesized Content)
-- **발생 메커니즘:** 인간이 주변 환경 속에서 이동하고 상호작용하는 능력은 시각적 감각과 전정(육체적) 감각을 통합하는 과정에 근본적으로 의존합니다 [1]. 그러나 가상 세계와 현실 세계 사이에 불일치가 존재하여 시각 경험이 물리적 경험과 다르게 뇌로 전달될 경우, 이 두 감각 사이에 갈등이 생기면서 감각 통합(Sensory Integration)에 장애가 발생하게 됩니다 [1].
-- **VR 멀미(VR Sickness)와의 연관성:** 시각-전정 갈등은 가상 현실 멀미의 병인을 설명하는 가장 유력한 이론 중 하나입니다 [1]. 감각 통합의 교란은 결과적으로 사용자에게 메스꺼움(nausea)이나 방향 감각 상실(disorientation)과 같은 전형적인 멀미 증상을 유발하게 됩니다 [1].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[가상 현실 멀미 (VR Sickness)]], [[감각 통합 (Sensory Integration)]], [[양안 시차-조절 갈등 (Vergence-Accommodation Conflict)]]
-- **Projects/Contexts:** [[비트 세이버를 활용한 가상 현실 엑서게임 후유증 연구 (VR Exergaming Aftereffects Investigation)]]
-- **Contradictions/Notes:** 소스에서는 시각-전정 갈등 이론과 더불어, 헤드마운트 디스플레이(HMD) 사용 시 발생하는 '양안 시차-조절 갈등(vergence-accommodation conflict)' 역시 안구 운동 증상 및 시각적 피로를 유발하여 멀미의 심각성을 가중시킬 수 있는 또 다른 주요 요인으로 함께 언급하고 있습니다 [1].
-
----
-*Last updated: 2026-04-19*
-- Raw Source: [[00_Raw/2026-04-20/시각-전정 갈등 (Visual-Vestibular Conflict).md]]
----
diff --git a/Programming & Language/시각-전정 감각 충돌(Visual-Vestibular Conflict).md b/Programming & Language/시각-전정 감각 충돌(Visual-Vestibular Conflict).md
deleted file mode 100644
index 41887b7b..00000000
--- a/Programming & Language/시각-전정 감각 충돌(Visual-Vestibular Conflict).md	
+++ /dev/null
@@ -1,32 +0,0 @@
----
-id: P-REINFORCE-AUTO-1CF133
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - 시각-전정 감각 충돌(Visual-Vestibular Conflict)"
----
-
-# [[시각-전정 감각 충돌(Visual-Vestibular Conflict)]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 시각-전정 감각 충돌은 가상 현실(VR)과 같은 환경에서 사용자의 시각적 경험이 실제 물리적, 신체적 경험과 일치하지 않을 때 발생하는 감각 불일치 현상입니다 [1]. 인간이 환경과 상호작용하기 위해 필수적인 시각과 전정(신체) 감각의 정보가 뇌로 전달될 때 서로 충돌하게 되면 감각 통합에 교란이 발생하게 됩니다 [1]. 이 현상은 메스꺼움이나 방향 감각 상실 등 멀미(VR 멀미) 증상을 유발하는 주요 원인으로 작용합니다 [1].
-
-## 📖 구조화된 지식 (Synthesized Content)
-- **감각 통합의 역할**: 시각 및 전정(신체) 감각의 통합은 개인이 주변 환경을 탐색하고 상호작용하는 능력을 발휘하는 데 필수적이고 근본적인 역할을 합니다 [1]. 
-- **충돌의 발생 및 증상**: 가상 현실 기기 등을 사용할 때 눈으로 보는 시각적 경험과 실제 신체의 움직임 사이에 차이가 생기면, 뇌로 전달되는 감각들 사이에 충돌이 일어납니다 [1]. 이러한 감각 통합의 방해는 메스꺼움(nausea)이나 방향 감각 상실(disorientation)과 같은 멀미 증상을 야기하게 됩니다 [1].
-- **정보의 한계**: 제공된 소스에서는 시각-전정 감각 충돌을 가상 현실 멀미의 주된 발생 원인으로 간략히 소개하고 있으나, 이를 극복하기 위한 심층적인 해결책이나 생리학적 세부 기전에 대해서는 소스에 관련 정보가 부족합니다.
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[가상 현실 멀미(VR Sickness)]], [[감각 통합(Sensory Integration)]]
-- **Projects/Contexts:** [[VR 엑서게임(VR Exergaming)]] (예: '비트 세이버(Beat Saber)'와 같이 사용자의 적극적인 신체 움직임과 3D 시각 환경이 결합되어 감각 충돌의 위험이 내재된 가상 현실 게임 연구 환경 [2], [1])
-- **Contradictions/Notes:** 소스에 따르면 VR 멀미의 발병 원인에 대해서는 학계의 완전한 합의(consensus)가 아직 없으며, 시각-전정 감각 충돌은 이를 설명하는 여러 유력한 이론(prominent theory) 중 하나로 제시되고 있습니다 [1]. 그 외에 본 주제와 상충하는 이론에 대해서는 소스에 관련 정보가 부족합니다.
-
----
-*Last updated: 2026-04-19*
-- Raw Source: [[00_Raw/2026-04-20/시각-전정 감각 충돌(Visual-Vestibular Conflict).md]]
----
diff --git a/Programming & Language/시각-전정 충돌(Visual-vestibular conflict).md b/Programming & Language/시각-전정 충돌(Visual-vestibular conflict).md
deleted file mode 100644
index 9e8e670c..00000000
--- a/Programming & Language/시각-전정 충돌(Visual-vestibular conflict).md	
+++ /dev/null
@@ -1,33 +0,0 @@
----
-id: P-REINFORCE-AUTO-F2748B
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - 시각-전정 충돌(Visual-vestibular conflict)"
----
-
-# [[시각-전정 충돌(Visual-vestibular conflict)]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 시각-전정 충돌(Visual-vestibular conflict)은 가상 세계에서의 시각적 경험이 실제 사용자의 신체적(육체적) 경험과 일치하지 않을 때 발생하는 감각의 불일치 현상입니다 [1]. 이로 인해 뇌로 전달되는 시각 및 전정 감각 간에 충돌이 일어나 감각 통합에 교란이 발생하며, 이는 메스꺼움이나 방향 상실과 같은 멀미(VR sickness) 증상을 유발하는 주요 원인이 됩니다 [1].
-
-## 📖 구조화된 지식 (Synthesized Content)
-- **이론적 배경:** 가상현실(VR) 멀미의 발생 원인에 대해서는 학계의 완전한 합의가 이루어지지 않았으나, 가장 유력한 이론 중 하나가 가상 환경과 실제 세계 간의 불일치로 인한 시각-전정 충돌입니다 [1]. 
-- **감각 통합의 교란:** 인간이 환경 내에서 이동하고 상호작용하는 능력은 시각과 전정(신체) 감각의 적절한 통합에 기반합니다 [1]. VR 환경에서 이 두 감각 사이의 충돌된 정보가 뇌로 전달되면 감각 통합 체계에 장애가 발생합니다 [1].
-- **관련 후유증 및 증상:** 이러한 감각의 충돌은 사용자에게 메스꺼움(nausea)과 방향 상실(disorientation)과 같은 전형적인 멀미(motion sickness) 증상을 일으키며 시각 및 인지적 후유증을 발생시킵니다 [1]. 
-- **복합적 시각 요인:** 시각-전정 충돌 외에도 헤드마운트 디스플레이(HMD)를 사용할 때 깊이 단서(depth cues) 인식에 필수적인 폭주 및 조절 기능의 불일치인 '폭주-조절 충돌(vergence-accommodation conflict)'이 발생할 수 있으며, 이는 사용자의 안구 운동 증상(oculomotor symptoms)을 가중시키는 또 다른 요인이 됩니다 [1].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[VR 멀미(VR sickness)]], [[감각 통합(Sensory integration)]], [[폭주-조절 충돌(Vergence-accommodation conflict)]]
-- **Projects/Contexts:** [[가상현실 엑서게임 후유증 연구(Virtual reality exergaming aftereffects research)]]
-- **Contradictions/Notes:** 소스에 따르면 VR 멀미의 정확한 병인에 대해 학계의 완전한 합의(consensus)는 존재하지 않으며, 시각-전정 충돌은 이를 설명하기 위해 널리 받아들여지는 유력한 이론 중 하나로 제시됩니다 [1].
-
----
-*Last updated: 2026-04-19*
-- Raw Source: [[00_Raw/2026-04-20/시각-전정 충돌(Visual-vestibular conflict).md]]
----
diff --git a/Programming & Language/시맨틱 웹 (Semantic Web).md b/Programming & Language/시맨틱 웹 (Semantic Web).md
deleted file mode 100644
index d5b3e5ab..00000000
--- a/Programming & Language/시맨틱 웹 (Semantic Web).md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-A9C2AC
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - 시맨틱 웹 (Semantic Web)"
----
-
-# [[시맨틱 웹 (Semantic Web)]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/시맨틱 웹 (Semantic Web).md]]
----
diff --git a/Programming & Language/시스템 다이내믹스 (System Dynamics).md b/Programming & Language/시스템 다이내믹스 (System Dynamics).md
deleted file mode 100644
index a21dadbd..00000000
--- a/Programming & Language/시스템 다이내믹스 (System Dynamics).md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-6FAAF2
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - 시스템 다이내믹스 (System Dynamics)"
----
-
-# [[시스템 다이내믹스 (System Dynamics)]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/시스템 다이내믹스 (System Dynamics).md]]
----
diff --git a/Programming & Language/시프트 레프트 (Shift-Left).md b/Programming & Language/시프트 레프트 (Shift-Left).md
deleted file mode 100644
index 1e6a2e7d..00000000
--- a/Programming & Language/시프트 레프트 (Shift-Left).md	
+++ /dev/null
@@ -1,32 +0,0 @@
----
-id: P-REINFORCE-AUTO-78B318
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - 시프트 레프트 (Shift-Left)"
----
-
-# [[시프트 레프트 (Shift-Left)]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 시프트 레프트(Shift-Left)는 소프트웨어 개발 수명 주기(SDLC)에서 품질 검사 및 보안 취약점 탐지를 개발 초기 단계로 앞당기는 접근 방식을 의미합니다 [1, 2]. 코드를 실행하기 전인 IDE 작업, 커밋 전(pre-commit) 훅, 풀 리퀘스트(PR) 및 CI 파이프라인 단계에 정적 분석 도구를 통합하여 문제를 선제적으로 해결하는 것을 목표로 합니다 [3, 4]. 이를 통해 취약점이 프로덕션 환경에 도달하기 전에 발견함으로써, 복구에 드는 시간과 비용을 크게 절감할 수 있습니다 [3, 5].
-
-## 📖 구조화된 지식 (Synthesized Content)
-* **핵심 원리 및 DevSecOps:** 시프트 레프트는 개발 프로세스 초기에 취약점을 감지하고 치료(remediation)하는 DevSecOps의 핵심 부분입니다 [1]. 소프트웨어를 실행하지 않고 코드를 분석하는 SAST(정적 애플리케이션 보안 테스트) 도구는 이러한 시프트 레프트 보안 워크플로우에 자연스럽게 부합하여 널리 사용됩니다 [2].
-* **구현 전략:** 성공적인 시프트 레프트를 위해서는 IDE, 커밋 전 훅(pre-commit hooks), PR 단계에 SAST와 같은 보안 도구를 통합하여 '초기부터 자주(early & often)' 스캔하는 전략을 취해야 합니다 [4, 6]. 이를 통해 개발자는 코드를 작성하는 즉시 실시간으로 피드백을 받을 수 있습니다 [6]. 
-* **비용 및 효율성 이점:** 개발 후반부나 프로덕션(Production) 배포 이후에 보안 문제를 발견하여 수정하는 것보다, IDE에서 코드를 작성하는 중에 취약점을 포착하여 수정하는 것이 비용 측면에서 훨씬 저렴하고 효과적입니다 [5]. 또한, QA(품질 보증) 과정을 시프트 레프트하고 기능을 더 작은 사용자 스토리로 분할하여 검증함으로써 소프트웨어 배포(Delivery) 속도를 획기적으로 최적화할 수 있습니다 [7].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[DevSecOps]], [[SAST (Static Application Security Testing)]], [[CI/CD]]
-- **Projects/Contexts:** [[Snyk Code]], [[Corgea]], [[Axify]]
-- **Contradictions/Notes:** 제공된 소스 전반에 걸쳐 시프트 레프트 접근법에 대한 반대 의견은 존재하지 않으며, 모든 문서가 조기 발견을 통한 수정 비용 절감 및 개발 속도 향상 효과를 긍정적으로 평가하고 있습니다.
-
----
-*Last updated: 2026-04-18*
-- Raw Source: [[00_Raw/2026-04-20/시프트 레프트 (Shift-Left).md]]
----
diff --git a/Programming & Language/시프트 레프트(Shift-Left).md b/Programming & Language/시프트 레프트(Shift-Left).md
deleted file mode 100644
index e160b3aa..00000000
--- a/Programming & Language/시프트 레프트(Shift-Left).md	
+++ /dev/null
@@ -1,33 +0,0 @@
----
-id: P-REINFORCE-AUTO-BC9D48
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - 시프트 레프트(Shift-Left)"
----
-
-# [[시프트 레프트(Shift-Left)]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 시프트 레프트(Shift-Left)는 소프트웨어 개발 수명 주기(SDLC)의 초기 단계에서 취약점이나 버그를 탐지하고 수정하는 DevSecOps의 핵심 전략입니다 [1, 2]. 개발자가 코드를 작성하는 IDE나 CI/CD 파이프라인에 보안 검사를 통합하여, 코드가 프로덕션 환경에 도달하기 전에 문제를 미리 파악합니다 [3, 4]. 이를 통해 개발 후반부나 배포 이후에 문제를 수정하는 것보다 훨씬 적은 비용으로 신속하게 결함을 해결할 수 있게 합니다 [5].
-
-## 📖 구조화된 지식 (Synthesized Content)
-- **초기 탐지 및 수정:** 시프트 레프트는 보안 및 품질 검사를 개발 프로세스의 앞단으로 이동시키는 전략입니다. 이는 배포 후가 아니라 소스 코드 작성 단계에서부터 실시간으로 문제의 근원을 찾아 조기에 해결하는 것을 목표로 합니다 [1, 3, 4].
-- **개발 워크플로우와의 자연스러운 통합:** 시프트 레프트 전략을 실현하기 위해서는 정적 애플리케이션 보안 테스트(SAST)와 같은 검사 도구를 통합 개발 환경(IDE), pre-commit 훅, 풀 리퀘스트(PR), 그리고 CI/CD 파이프라인 등 기존 개발 워크플로우에 긴밀하게 통합해야 합니다 [3, 4, 6].
-- **비용 절감 및 효율성 증대:** 코드를 작성하는 시점(예: 쿼리를 작성하는 중)에 SQL 인젝션과 같은 취약점을 즉각 포착하여 수정하는 것은, 향후 풀 리퀘스트 리뷰나 프로덕션 단계에서 결함을 발견하고 고치는 것보다 비용이 훨씬 저렴하고 처리 속도도 빠릅니다 [5].
-- **SAST 및 인프라 보안 적용:** 애플리케이션을 실행하지 않고 소스 코드를 그대로 분석하는 SAST 도구는 시프트 레프트 보안 워크플로우에 매우 적합하게 기능합니다 [2]. 또한, 이 접근 방식은 코드 기반 인프라(IaC)에 대한 클라우드 보안 정책 검사를 개발 초기로 앞당기는 데에도 적용됩니다 [7].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[DevSecOps]], [[SAST (Static Application Security Testing)]], [[SDLC (소프트웨어 개발 수명 주기)]], [[CI/CD]]
-- **Projects/Contexts:** 코드가 작성되는 IDE, 풀 리퀘스트, CI 파이프라인 단계에 직접 통합하여 소프트웨어가 출시되기 전에 취약점과 버그를 수정하는 컨텍스트에서 주로 사용됩니다 [3, 5]. 구체적인 사례로 BDC 회사는 QA 단계의 시프트 레프트를 통해 소프트웨어 딜리버리를 최적화한 바 있습니다 [8].
-- **Contradictions/Notes:** 주어진 소스 내에서 시프트 레프트 개념과 관련하여 상충하는 의견은 확인되지 않습니다.
-
----
-*Last updated: 2026-04-18*
-- Raw Source: [[00_Raw/2026-04-20/시프트 레프트(Shift-Left).md]]
----
diff --git a/Programming & Language/식별 가능한 유니온 (Discriminated Unions).md b/Programming & Language/식별 가능한 유니온 (Discriminated Unions).md
deleted file mode 100644
index f50e5a0a..00000000
--- a/Programming & Language/식별 가능한 유니온 (Discriminated Unions).md	
+++ /dev/null
@@ -1,33 +0,0 @@
----
-id: P-REINFORCE-AUTO-EE02DB
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - 식별 가능한 유니온 (Discriminated Unions)"
----
-
-# [[식별 가능한 유니온 (Discriminated Unions)]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-* **작동 원리와 타입 좁히기 (Type Narrowing):** 태그된 유니온(Tagged Union)이라고도 불리는 식별 가능한 유니온은 여러 데이터 형태 중 하나를 리터럴 타입의 공통 속성(예: `kind`, `type`, `status` 등)으로 구분한다 [1, 3, 4, 7]. 컴파일러는 `switch`나 `if` 조건문 등에서 이 식별자 속성을 확인하여 해당 블록 안에서 객체의 타입을 안전하고 자동적으로 좁혀주며, 개발자는 별도의 런타임 체크 제약 없이도 자동 완성과 타입 안전성을 극대화할 수 있다 [3, 4, 8, 9].
-* **완전성 검사 (Exhaustiveness Checking)를 통한 철벽 방어:** 이 패턴의 가장 강력한 이점 중 하나는 컴파일러가 모든 가능한 케이스의 처리 여부를 검증하는 완전성 검사 기능이다 [3, 4, 9, 10]. `never` 타입을 활용해 기본(default) 분기 처리를 구성하면, 유니온에 새로운 상태 멤버가 추가되었으나 이를 처리하는 로직을 누락했을 때 즉각적인 컴파일 에러를 발생시킨다 [4, 9-11]. 이는 시스템 확장에 따른 사이드 이펙트를 차단하는 엄격한 규율로 작용한다 [4].
-* **잘못된 상태 표현의 방지 (Making Invalid States Impossible):** 독립적이고 호환 불가능한 프로퍼티들을 무분별하게 섞어 쓰는 것을 방지하고, 특정 상태에만 유효한 속성 조합만을 허용한다 [1, 5, 12]. 이러한 특성 덕분에 API 응답 처리, 복잡한 폼(Form) 핸들링, Redux 스타일의 리듀서, 라우터 상태 관리 등 명확한 상태 전이(State Machine)가 필요한 다양한 실제 환경에서 유효하지 않은 상태가 아예 생성될 수 없도록 막아준다 [5, 6, 13, 14].
-* **모범 사례와 활용시 주의점:** 식별 가능한 유니온을 구축할 때는 항상 식별자를 포함하고 식별자 속성을 일관되게 리터럴 타입으로 유지해야 한다 [14, 15]. 식별자를 빼먹거나 선택적(Optional)으로 만드는 것은 흔한 실수이므로 피해야 한다 [16, 17]. 또한 외부 데이터나 설정 파일에서 들어오는 값에 대응할 때는 컴파일 타임 검사에만 의존할 수 없으므로 Zod 등과 같은 런타임 검증 라이브러리와 결합해 방어력을 높이는 것이 좋다 [8, 18, 19].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[유니온 타입 (Union Types)]], [[타입 좁히기 (Type Narrowing)]], [[완전성 검사 (Exhaustiveness Checking)]], [[네버 타입 (never type)]]
-- **Projects/Contexts:** [[상태 머신 (State Machine) 모델링 및 Redux 액션/리듀서 설계]], [[API 응답 및 에러 핸들링 아키텍처]]
-- **Contradictions/Notes:** 소스에 따르면 식별 가능한 유니온은 런타임 오버헤드가 전혀 없는 강력한 컴파일 타임 기능이지만, 너무 깊게 중첩된(Deep nesting) 식별 가능한 유니온을 남용할 경우 에러 메시지를 읽기 어렵게 만들고 거대한 유니온 타입으로 인해 TypeScript 컴파일 속도가 저하될 수 있다는 단점이 있다 [20].
-
----
-*Last updated: 2026-04-18*
-- Raw Source: [[00_Raw/2026-04-20/식별 가능한 유니온 (Discriminated Unions).md]]
----
diff --git a/Programming & Language/식별 가능한 유니온(Discriminated Unions).md b/Programming & Language/식별 가능한 유니온(Discriminated Unions).md
deleted file mode 100644
index 95acd38e..00000000
--- a/Programming & Language/식별 가능한 유니온(Discriminated Unions).md	
+++ /dev/null
@@ -1,30 +0,0 @@
----
-id: P-REINFORCE-AUTO-0228C6
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - 식별 가능한 유니온(Discriminated Unions)"
----
-
-# [[식별 가능한 유니온(Discriminated Unions)]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 식별 가능한 유니온(Discriminated Unions, 태그된 유니온)은 여러 다른 형태의 데이터를 구별하기 위해 공통된 리터럴 타입 속성(판별자)을 사용하는 TypeScript 패턴이다 [1-3]. 이 패턴은 컴파일러가 각 조건 블록에서 타입을 자동으로 좁혀(Narrowing) 유효하지 않은 상태의 생성을 원천적으로 방지하고 타입 안정성을 보장할 수 있게 한다 [4, 5].
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[유니온 타입(Union Types)]], [[타입 좁히기(Type Narrowing)]], [[완전성 검사(Exhaustiveness Checking)]], [[never 타입]]
-- **Projects/Contexts:** [[상태 머신(State Machine) 설계]], [[React 상태 관리 및 API 응답 처리]]
-- **Contradictions/Notes:** 컴파일 시점의 정적 타이핑만 제공하므로 외부에서 유입되는 API 데이터나 설정 파일의 정합성을 보장하려면 런타임 검증 라이브러리(예: Zod)와 함께 사용하는 것이 권장된다 [18, 19]. 또한, 복잡한 분기 처리를 돕기 위해 `ts-pattern`과 같은 외부 라이브러리를 도입할 수 있으나, 이는 기존의 switch나 if/else 문에 기반한 식별 가능한 유니온보다 연산 성능이 떨어질 수 있으므로 성능과 가독성 사이의 트레이드오프를 고려해야 한다 [11, 20, 21].
-
----
-*Last updated: 2026-04-18*
-- Raw Source: [[00_Raw/2026-04-20/식별 가능한 유니온(Discriminated Unions).md]]
----
diff --git a/Programming & Language/식별 가능한 유니온.md b/Programming & Language/식별 가능한 유니온.md
deleted file mode 100644
index 26a77a64..00000000
--- a/Programming & Language/식별 가능한 유니온.md	
+++ /dev/null
@@ -1,33 +0,0 @@
----
-id: P-REINFORCE-AUTO-AB1669
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - 식별 가능한 유니온"
----
-
-# [[식별 가능한 유니온]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 식별 가능한 유니온(Discriminated Union 또는 Tagged Union)은 여러 형태의 데이터 구조를 공통 리터럴 속성(판별자)을 통해 구별하는 TypeScript의 강력한 타입 패턴이다 [1, 2]. 이 패턴을 사용하면 TypeScript 컴파일러가 공통 속성의 값을 바탕으로 타입을 자동으로 좁혀(Narrowing) 타입 안전성을 보장한다 [2, 3]. 결과적으로 유효하지 않은 상태 표현을 원천적으로 방지하며, 완전성 검사(Exhaustiveness Checking)를 통해 누락된 코드 케이스를 컴파일 타임에 효과적으로 찾아낼 수 있다 [4-6].
-
-## 📖 구조화된 지식 (Synthesized Content)
-- **작동 원리 및 특징:** 식별 가능한 유니온은 각 유니온 멤버에 공통으로 존재하는 리터럴 타입의 판별자 속성(예: `kind`, `type`, `state` 등)을 갖는다 [3, 6, 7]. 이 판별자 속성을 `switch`나 `if` 조건문으로 검사함으로써, TypeScript는 런타임 값에 따라 여러 가능한 객체 중 특정한 하나의 객체 타입으로 범위를 안전하게 좁힐 수 있다 [3, 6, 8].
-- **불가능한 상태 방지:** 이 패턴은 "불가능한 상태를 표현 불가능하게 만드는" 데 탁월한 효과를 발휘한다 [1, 4, 9]. 유효하지 않은 속성의 조합 자체를 타입 시스템에서 차단하므로 API 응답 처리, 복잡한 폼 핸들링, 라우터 상태 관리, 상태 머신 모델링 등에서 필수적으로 사용된다 [4, 7, 10, 11].
-- **완전성 검사 (Exhaustiveness Checking):** 식별 가능한 유니온의 가장 큰 장점 중 하나는 `switch` 문 등과 결합하여 모든 분기 경우의 수를 안전하게 처리했는지 컴파일러가 강제로 확인하게 하는 것이다 [5, 6, 12, 13]. 만약 유니온 타입에 새로운 멤버가 추가되었으나 분기 처리에서 누락되었다면, `default` 케이스에서 남은 값을 `never` 타입에 할당하게 하는 기법을 통해 컴파일 에러를 발생시켜 안전한 코드 확장을 돕는다 [6, 13-15].
-- **성능과 런타임 한계 극복:** 식별 가능한 유니온은 컴파일 타임에만 존재하는 구조이므로 추가적인 런타임 오버헤드를 발생시키지 않는다 [16]. 다만, 지나치게 거대한 유니온 타입은 컴파일 속도 저하를 유발할 수 있으며 깊은 중첩 구조는 에러 메시지를 읽기 어렵게 만들 수 있다 [16]. 또한, API나 설정 파일처럼 외부에서 유입되는 데이터를 다룰 때는 TypeScript 컴파일러의 한계를 보완하기 위해 Zod와 같은 런타임 검증 라이브러리와 결합하여 사용하는 것이 권장된다 [17, 18].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[타입 좁히기(Type Narrowing)]], [[완전성 검사(Exhaustiveness Checking)]], [[never 타입]]
-- **Projects/Contexts:** [[상태 머신(State Machine)]], [[API 응답 처리(API Response Handling)]]
-- **Contradictions/Notes:** 소스 간의 직접적인 모순은 없으나, 주의 사항이 존재한다. 식별 가능한 유니온 분기 처리를 더 선언적이고 안전하게 작성하기 위해 `ts-pattern`과 같은 패턴 매칭 라이브러리를 활용할 수 있지만, 자바스크립트의 기본 제어 구조인 `if/else`나 `switch` 문에 비해 심각한 성능 저하(약 99% 연산 감소)를 일으킬 수 있으므로 무분별한 사용은 지양하고 상황에 맞는 도구를 선택해야 한다 [19, 20].
-
----
-*Last updated: 2026-04-18*
-- Raw Source: [[00_Raw/2026-04-20/식별 가능한 유니온.md]]
----
diff --git a/Programming & Language/신경 가소성 (Neuroplasticity).md b/Programming & Language/신경 가소성 (Neuroplasticity).md
deleted file mode 100644
index 6db0592c..00000000
--- a/Programming & Language/신경 가소성 (Neuroplasticity).md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-871BD5
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - 신경 가소성 (Neuroplasticity)"
----
-
-# [[신경 가소성 (Neuroplasticity)]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/신경 가소성 (Neuroplasticity).md]]
----
diff --git a/Programming & Language/실재감(Presence).md b/Programming & Language/실재감(Presence).md
deleted file mode 100644
index 1103530e..00000000
--- a/Programming & Language/실재감(Presence).md	
+++ /dev/null
@@ -1,33 +0,0 @@
----
-id: P-REINFORCE-AUTO-D49B89
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - 실재감(Presence)"
----
-
-# [[실재감(Presence)]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 실재감(Presence)은 사용자가 가상 공간, 혼합 현실 또는 게임 환경을 현실 세계 대신 일시적으로 수용하여 실제로 그곳에 "존재한다(being there)"고 느끼는 심리적 상태 및 주관적 인식을 의미합니다 [1, 2]. 이는 성공적인 가상 현실 경험을 위한 핵심 기반이며, 몰입(Immersion) 및 참여(Engagement) 개념과 밀접하게 연관되어 사용자의 동기 부여와 성과에 영향을 미칩니다 [1, 3].
-
-## 📖 구조화된 지식 (Synthesized Content)
-* **개념 및 주요 구성 요소**: 실재감은 게임이나 가상 환경의 현실을 주관적으로 수용하는 것을 의미하며, 합성 환경에서는 '원격 현전(telepresence)'이라는 용어로도 설명됩니다 [1]. VR 환경에서의 실재감은 크게 세 가지 환상(illusions)으로 구성됩니다. 첫째는 묘사된 공간에 실제로 있는 것처럼 느끼는 장소 환상(place illusion), 둘째는 가상 시뮬레이션 내의 사건이 진짜로 일어나고 있다고 믿는 그럴듯함의 환상(plausibility illusion), 셋째는 가상 신체에 대한 소유권 환상(illusion of ownership)입니다 [2].
-* **혼합 현실(MR)에서의 실재감**: 혼합 현실(MR) 환경에서의 실재감은 현실 세계의 물리적 객체가 개입하기 때문에 순수 VR보다 구현하기가 더 복잡합니다 [4]. MR에서 실재감을 훼손하지 않고 보존하려면 객체 폐색(object occlusion), 빛 반사, 가상 조명 및 그림자 등과 같은 정교한 시각적 소프트웨어 효과가 필요합니다 [4].
-* **학습 및 수행 능력에 미치는 긍정적 영향**: 높은 수준의 실재감은 가상 현실이나 엑서게임(Exergame) 등에서 사용자의 몰입도와 참여도를 높이고, 궁극적으로 더 나은 작업 수행과 강력한 생리적 반응, 긍정적인 학습 성과를 이끌어냅니다 [3, 4]. 또한 타인과 함께 있다는 느낌을 주는 '사회적 실재감(social presence)'은 고립감을 완화하고 커뮤니티 감각을 재건하는 데 귀중한 역할을 합니다 [5].
-* **인지 부하 및 멀미(Sickness)와의 관계**: 가상 환경에 깊이 실재할수록 콘텐츠를 처리하고 상호작용하는 데 더 많은 정신적 노력이 요구되므로 인지 부하(Cognitive Load)가 함께 증가하는 경향이 있습니다 [6]. 한편, 가상 현실 멀미(VR Sickness)는 사용자의 실재감을 감소시키거나 완전히 깨뜨릴 수 있는 주요 부정적 요인으로 작용합니다 [7].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[몰입(Immersion)]], [[참여(Engagement)]], [[인지 부하(Cognitive Load)]], [[가상 현실(Virtual Reality)]], [[혼합 현실(Mixed Reality)]], [[사회적 실재감(Social Presence)]]
-- **Projects/Contexts:** [[게임 기반 학습(Game-based Learning)]], [[가상 현실 엑서게임(VR Exergaming)]]
-- **Contradictions/Notes:** 가상 실재감이 높아지면 참여도와 학습 성과가 향상된다는 긍정적인 측면이 있지만, 동시에 사용자의 인지 부하를 증가시킨다는 모순된 성격이 있습니다 [4, 6]. 따라서 가상 환경 설계 시 실재감을 떨어뜨리지 않으면서도 과도한 인지 부하를 줄이는 전략을 찾는 것이 주요한 연구 과제입니다 [8].
-
----
-*Last updated: 2026-04-19*
-- Raw Source: [[00_Raw/2026-04-20/실재감(Presence).md]]
----
diff --git a/Programming & Language/심리적 계약 (Psychological Contract).md b/Programming & Language/심리적 계약 (Psychological Contract).md
deleted file mode 100644
index 5dc8183a..00000000
--- a/Programming & Language/심리적 계약 (Psychological Contract).md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-53F659
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - 심리적 계약 (Psychological Contract)"
----
-
-# [[심리적 계약 (Psychological Contract)]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/심리적 계약 (Psychological Contract).md]]
----
diff --git a/Programming & Language/심리적 안전감 (Psychological Safety).md b/Programming & Language/심리적 안전감 (Psychological Safety).md
deleted file mode 100644
index 05b208b6..00000000
--- a/Programming & Language/심리적 안전감 (Psychological Safety).md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-6A93C9
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - 심리적 안전감 (Psychological Safety)"
----
-
-# [[심리적 안전감 (Psychological Safety)]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/심리적 안전감 (Psychological Safety).md]]
----
diff --git a/Programming & Language/쓰기 장벽(Write Barrier).md b/Programming & Language/쓰기 장벽(Write Barrier).md
deleted file mode 100644
index a78536c2..00000000
--- a/Programming & Language/쓰기 장벽(Write Barrier).md	
+++ /dev/null
@@ -1,37 +0,0 @@
----
-id: P-REINFORCE-AUTO-30E929
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - 쓰기 장벽(Write Barrier)"
----
-
-# [[쓰기 장벽(Write Barrier)]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 쓰기 장벽(Write Barrier)은 가비지 컬렉션(GC) 환경에서 메모리 저장 작업 직후에 실행되어 특정한 포인터의 변경을 감지하고 기록하는 짧은 코드 조각입니다 [1, 2]. 주로 구세대(Old-space) 객체가 신세대(New-space) 객체를 참조하거나, 이미 스캔을 마친 객체가 스캔되지 않은 객체를 새롭게 참조할 때 이를 추적하는 데 사용됩니다 [1, 3]. 이를 통해 가비지 컬렉터가 힙 전체를 무의미하게 다시 스캔하는 비용을 줄이고, 스캐빈지(Scavenge) 및 점진적/동시성 마킹 과정을 효율적이고 안전하게 수행하도록 돕습니다 [3-5].
-
-## 📖 구조화된 지식 (Synthesized Content)
-* **세대별 수집(Generational GC)에서의 포인터 추적:**
-  마이너 GC(스캐빈지)를 수행할 때 신세대에 있는 객체가 여전히 살아있는지 확인하기 위해 구세대 전체의 포인터를 스캔하는 것은 매우 많은 비용을 소모합니다 [4]. 이 문제를 피하고자 쓰기 장벽은 구세대 객체의 필드에 신세대 객체를 가리키는 포인터가 작성될 때 해당 위치를 '저장 버퍼(Store Buffer)'에 기록합니다 [1, 6]. 이렇게 확보된 구세대-신세대 참조 목록(old-to-new references)을 통해 스캐빈지를 빠르고 효율적으로 진행할 수 있습니다 [1, 5].
-
-* **점진적 및 동시성 마킹(Incremental/Concurrent Marking)에서의 객체 그래프 동기화:**
-  점진적 마킹이나 동시성 마킹이 진행되는 동안에는 메인 스레드에서 자바스크립트가 계속 실행되므로 객체 그래프가 언제든 변경될 수 있습니다 [3, 7, 8]. 쓰기 장벽은 이미 완전히 스캔된 객체(Black)가 스캔되지 않은 라이브 객체(White)를 새롭게 가리키게 되는 'Black-to-White' 포인터를 감지합니다 [3]. 이러한 포인터가 감지되면 쓰기 장벽은 해당 Black 객체를 다시 Grey 상태로 변경하고 마킹 데크(Marking Deque)로 되돌려 보내, 순서를 보존하고 White 객체가 잘못하여 가비지로 분류되지 않도록 보장합니다 [2, 3].
-
-* **성능 오버헤드와 최적화 전략:**
-  포인터를 쓸 때마다 쓰기 장벽 코드를 실행해야 하므로 추가적인 CPU 오버헤드가 발생하며, 이는 관리형 메모리(Managed Memory)의 편리함을 얻는 대가 중 하나입니다 [1, 9]. 그러나 쓰기 작업은 읽기 작업보다 훨씬 드물게 발생하기 때문에 별도의 하드웨어 지원이 필요한 읽기 장벽(Read Barrier)에 비해 비용이 저렴합니다 [1]. V8 엔진은 컴파일러(Crankshaft) 분석을 통해 신세대에 속하거나 스택에 할당된 객체임이 정적으로 증명되면 쓰기 장벽 코드를 생략합니다 [10]. 또한, 페이지 헤더의 공간 플래그를 확인하여 일반적인 new-to-new 또는 old-to-old 포인터를 몇 개의 명령어만으로 빠르게 무시하고, 저장 버퍼를 주기적으로 정렬 및 중복 제거하여 성능 영향을 최소화합니다 [10].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[Garbage Collection]], [[Generational Collection]], [[Incremental Marking]], [[Concurrent Marking]], [[Store Buffer]]
-- **Projects/Contexts:** [[V8 JavaScript Engine]], [[IBM OpenJ9 GC]]
-- **Contradictions/Notes:** 소스에 따르면 쓰기 장벽은 객체 갱신마다 추가 연산을 수행하여 불가피한 CPU 오버헤드를 유발하지만 [9], 이는 무거운 읽기 장벽(Read Barrier)을 피하고 효율적인 가비지 컬렉션을 유지하기 위한 필수적이고 합리적인 트레이드오프입니다 [1]. 
-
----
-*Last updated: 2026-04-19*
-- Raw Source: [[00_Raw/2026-04-20/쓰기 장벽(Write Barrier).md]]
----
diff --git a/Programming & Language/안구 운동 기능 (Oculomotor Functions).md b/Programming & Language/안구 운동 기능 (Oculomotor Functions).md
deleted file mode 100644
index 80b88623..00000000
--- a/Programming & Language/안구 운동 기능 (Oculomotor Functions).md	
+++ /dev/null
@@ -1,33 +0,0 @@
----
-id: P-REINFORCE-AUTO-9C8C53
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - 안구 운동 기능 (Oculomotor Functions)"
----
-
-# [[안구 운동 기능 (Oculomotor Functions)]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 안구 운동 기능(Oculomotor functions)은 수렴(vergence)과 조절(accommodation) 등을 포함하며, 인간이 깊이 단서(depth cues)를 정확하게 사용하고 대상에 명확한 초점을 맞추도록 돕는 필수적인 감각 메커니즘이다 [1, 2]. 가상현실(VR) 환경에서는 이러한 기능들이 자연스러운 피드백 루프에서 벗어나 분리(decoupled)될 수 있다 [2]. 이로 인해 발생하는 수렴-조절 불일치(vergence-accommodation conflicts)는 눈의 피로, 두통, 복시 등 가상현실 멀미와 관련된 안구 운동 증상을 유발하는 주요 원인이 된다 [1, 2].
-
-## 📖 구조화된 지식 (Synthesized Content)
-- **깊이 지각을 위한 필수 역할:** 수렴(Convergence/Vergence)과 조절(Accommodation)은 가까운 대상에 단일하고 명확한 초점을 맞추기 위해 필수적인 안구 운동 기능이다 [2]. 흐림(blur)과 양안 시차(disparity)와 같은 망막의 단서들이 이 두 가지 안구 운동 기능이 물체에 더 정확하게 고정되도록 돕는다 [2].
-- **자연적 환경과 VR 환경의 작동 방식 차이:** 일반적인 자연 시야 환경에서 수렴과 조절 기능은 피드백 루프 안에서 함께 작동하므로, 한 메커니즘이 변화하면 다른 메커니즘도 동시에 변화한다 [2]. 그러나 HMD를 착용한 가상현실 환경에서는 수렴과 조절 기능이 서로 분리될 수 있으며, 이는 깊이 지각을 위한 망막 단서 처리에 불확실성을 초래한다 [2]. 
-- **수렴-조절 불일치로 인한 부작용:** HMD 기기 사용 시 발생하는 수렴-조절 불일치는 사용자에게 두통, 안구 통증(sore eyes), 피로, 복시(double vision)를 포함한 다양한 동반 증상을 유발할 수 있다 [2]. 이를 측정하기 위해 시뮬레이터 멀미 설문지(SSQ)의 '안구 운동(Oculomotor)' 하위 클러스터는 눈의 피로(eyestrain), 전반적 피로감, 초점 저하 등과 관련된 7가지 증상 척도를 포함한다 [3].
-- **단기적 후유증으로서의 안구 운동 변화:** 가상현실 노출 직후에는 수렴과 조절 같은 안구 운동 기능에 유의미한 수치 변화가 발생하지만, VR 종료 후 40분이 지난 지연 평가 시점에서는 다시 기준치(baseline) 수준으로 회복되는 경향을 보인다 [2, 4, 5]. 이는 VR 환경에서의 깊이 지각 불일치로 인한 안구 운동의 변화가 비교적 단기적인 후유증임을 시사한다 [2].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[수렴과 조절(Vergence and Accommodation)]], [[수렴-조절 불일치(Vergence-Accommodation Conflicts)]], [[VR 멀미(VR Sickness)]], [[시뮬레이터 멀미 설문지(SSQ)]]
-- **Projects/Contexts:** [[가상현실(VR) 엑서게임 후유증(Aftereffects) 연구]]
-- **Contradictions/Notes:** 소스는 가상현실 노출이 즉각적으로 안구 운동 기능에 상당한 부하와 변화를 일으킨다는 점을 지적하지만, 이러한 안구 운동 변화는 노출 시간(10분 또는 50분)의 길이에 의해 통계적으로 유의미한 차이가 발생하지 않았으며 노출 후 40분이 지나면 정상으로 돌아온다고 설명합니다 [2, 4, 5]. 
-
----
-*Last updated: 2026-04-19*
-- Raw Source: [[00_Raw/2026-04-20/안구 운동 기능 (Oculomotor Functions).md]]
----
diff --git a/Programming & Language/안구 운동 기능(Oculomotor functions).md b/Programming & Language/안구 운동 기능(Oculomotor functions).md
deleted file mode 100644
index bc5359bc..00000000
--- a/Programming & Language/안구 운동 기능(Oculomotor functions).md	
+++ /dev/null
@@ -1,41 +0,0 @@
----
-id: P-REINFORCE-AUTO-91A2A0
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - 안구 운동 기능(Oculomotor functions)"
----
-
-# [[안구 운동 기능(Oculomotor functions)]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 안구 운동 기능(Oculomotor functions)은 깊이 단서를 정확하게 사용하도록 돕는 이향운동(vergence) 및 조절(accommodation)과 같은 시각적 핵심 메커니즘을 포함한다 [1]. 또한, 사용자의 인지적 노력을 비침습적으로 평가하기 위해 측정되는 동공 반응, 시선 고정, 사카드(saccade) 등의 다양한 안구 움직임(oculometry)을 포괄하는 개념이다 [2-5].
-
-## 📖 구조화된 지식 (Synthesized Content)
-- **이향운동과 조절 (Vergence and Accommodation)**
-  이향운동과 조절은 깊이 단서를 정확하게 파악하고 사용하도록 촉진하는 필수적인 안구 운동 기능이다 [1]. 가상현실(VR) 기기인 헤드마운트 디스플레이(HMD)를 사용할 때 이 두 기능 간의 불일치(vergence-accommodation conflicts)가 발생할 수 있으며, 이로 인해 눈의 피로, 집중력 저하, 시각적 장애 등 안구 운동 관련 증상(oculomotor symptoms)이 유발될 수 있다 [1, 6, 7].
-
-- **안구 운동 행동 지표 (Eye Movement Behavior)**
-  사용자의 인지 부하 및 시각적 처리 과정을 파악하기 위해 시선 고정(Fixations), 사카드(Saccades), 미세 사카드(Microsaccades), 스캔 경로 엔트로피 등이 측정된다 [5, 8]. 
-  * **시선 고정 시간(Fixation Duration):** 시각 정보 처리의 복잡성이 높아지거나 요구되는 작업량이 증가할 때 길어지는 경향을 보인다 [5, 8].
-  * **사카드 비율(Saccade Rate):** 시각적 탐색이 비효율적이거나 사용자에게 혼란과 무질서 상태가 유발되었을 때 증가한다 [5, 8].
-
-- **동공 측정 지표 (Pupillometry)**
-  동공 확장은 뇌의 청반-노르에피네프린(locus coeruleus-norepinephrine) 시스템 활성화와 밀접하게 연결되어 있어 사용자의 인지적 노력(cognitive effort)을 신뢰성 있게 반영한다 [2].
-  * 작업 요구 발생 후 1~2초 이내에 동공이 확장되며, 메모리 부하와 실시간 인지적 노력이 증가함에 따라 동공 크기도 커진다 [2, 5].
-  * 그러나 단기적인 인지 부하가 아닌 장시간의 게임 플레이나 작업 등으로 인해 인지적 피로(Cognitive fatigue)가 누적될 경우에는 오히려 동공 크기가 감소(수축)하는 현상이 나타난다 [4, 9].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[가상현실 멀미(VR Sickness)]], [[인지 부하(Cognitive Load)]], [[시뮬레이터 멀미 설문지(SSQ)]]
-- **Projects/Contexts:** [[UX 리서치에서의 생체 신호 정량화]], [[e스포츠 선수의 인지 상태 및 피로도 모니터링]]
-- **Contradictions/Notes:** 급성 인지 부하나 정신적 노력(Mental workload)이 가해지는 상황에서는 동공이 확장되지만, 작업이 2시간 이상 지속되는 등 인지적 피로(Cognitive fatigue)가 발생하면 반대로 동공이 수축(Pupil constriction)하여 인지 성과 저하와 상관관계를 보인다 [2, 4, 9]. 
-
----
-*Last updated: 2026-04-19*
-- Raw Source: [[00_Raw/2026-04-20/안구 운동 기능(Oculomotor functions).md]]
----
diff --git a/Programming & Language/안구 운동 증상(Oculomotor Symptoms).md b/Programming & Language/안구 운동 증상(Oculomotor Symptoms).md
deleted file mode 100644
index 4cf7f42b..00000000
--- a/Programming & Language/안구 운동 증상(Oculomotor Symptoms).md	
+++ /dev/null
@@ -1,33 +0,0 @@
----
-id: P-REINFORCE-AUTO-064759
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - 안구 운동 증상(Oculomotor Symptoms)"
----
-
-# [[안구 운동 증상(Oculomotor Symptoms)]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 안구 운동 증상(Oculomotor Symptoms)은 주로 머리 착용 디스플레이(HMD)를 사용하는 가상현실(VR)에 노출될 때 경험할 수 있는 멀미 부작용 중 하나입니다 [1]. 시뮬레이터 멀미 설문지(SSQ)의 3대 하위 항목 중 하나로, 눈의 긴장, 시각적 피로, 초점의 어려움과 관련된 증상을 포함합니다 [2]. HMD 사용 시 발생하는 폭주-조절 불일치(vergence-accommodation conflict)가 이러한 증상을 유발하는 주된 원인으로 작용합니다 [1].
-
-## 📖 구조화된 지식 (Synthesized Content)
-- **증상의 정의와 평가:** 안구 운동 증상은 가상현실 멀미를 측정하는 가장 보편적인 도구인 '시뮬레이터 멀미 설문지(SSQ)'를 통해 정량적으로 평가됩니다 [2]. 안구 운동 증상군(Oculomotor cluster)은 메스꺼움(Nausea), 방향 상실(Disorientation)과 함께 다루어지며, 시력 긴장(eyestrain), 피로(fatigue), 초점(focus) 등에 관련된 7가지 구체적인 증상으로 구성되어 있습니다 [2].
-- **주요 발생 원인:** HMD 기기 사용 시 흔히 발생하는 '폭주-조절 불일치(Vergence-accommodation conflicts)'가 안구 운동 증상의 핵심 원인입니다 [1]. 폭주(Vergence)와 조절(Accommodation)은 깊이 단서를 정확히 파악하게 돕는 필수적인 안구 운동 기능이므로, 가상 환경에서 이 두 기능이 상충할 경우 시각적 수행이 방해받고 피로가 누적됩니다 [1]. 또한, 콘텐츠 내 모션(motion) 수준이 높을수록 안구 운동 장애가 증가하는 것으로 나타납니다 [3].
-- **노출 시간의 영향 및 회복:** VR 엑서게임(Beat Saber)을 활용한 연구에 따르면, 안구 운동 증상은 VR 노출 직후에 사전 수준 대비 유의미하게 크게 나타납니다 [4, 5]. 10분 노출보다 50분을 노출했을 때 직후의 증상 악화가 통계적으로 더 컸습니다 [4]. 그러나 이러한 증상은 일시적이며, VR 노출을 마치고 40분가량 휴식하면 안구 운동 증상이 다시 기준선(baseline) 수준으로 완전히 회복되었습니다 [4-6].
-- **현실 세계에 미치는 여파:** 가상현실 경험을 마친 후 남아있는 큰 안구 운동의 변화는 현실 세계에서의 깊이 지각(depth perception)에 일시적인 영향을 미칠 가능성이 있습니다 [7].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[가상현실 멀미(VR Sickness)]], [[폭주-조절 불일치(Vergence-Accommodation Conflict)]], [[시뮬레이터 멀미 설문지(Simulator Sickness Questionnaire)]]
-- **Projects/Contexts:** [[가상현실 엑서게임 후유증 연구(VR Exergaming Aftereffects Study)]]
-- **Contradictions/Notes:** 소스에 관련 정보가 부족합니다.
-
----
-*Last updated: 2026-04-19*
-- Raw Source: [[00_Raw/2026-04-20/안구 운동 증상(Oculomotor Symptoms).md]]
----
diff --git a/Programming & Language/안전한 TypeScript 데이터 모델링 및 설정 관리 구축.md b/Programming & Language/안전한 TypeScript 데이터 모델링 및 설정 관리 구축.md
deleted file mode 100644
index 211a7b49..00000000
--- a/Programming & Language/안전한 TypeScript 데이터 모델링 및 설정 관리 구축.md	
+++ /dev/null
@@ -1,40 +0,0 @@
----
-id: P-REINFORCE-AUTO-9DB95B
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - 안전한 TypeScript 데이터 모델링 및 설정 관리 구축"
----
-
-# [[안전한 TypeScript 데이터 모델링 및 설정 관리 구축]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 이 주제는 TypeScript의 강력한 정적 타입 시스템을 활용하여 런타임 오류를 예방하고 애플리케이션의 데이터 무결성을 보장하는 데이터 모델링 및 설정(Configuration) 객체 관리 방법론입니다. 브랜디드 타입과 식별 가능한 유니온을 통해 비즈니스 로직에 필요한 명확한 도메인 모델을 구축하고, `readonly` 수식어 및 `satisfies` 연산자를 활용하여 불변하고 구조적으로 정확한 설정 상태를 안전하게 관리하는 설계 패턴을 포함합니다.
-
-## 📖 구조화된 지식 (Synthesized Content)
-**데이터 모델링의 안전성 확보**
-* **식별 가능한 유니온(Discriminated Unions)과 완전성 검사:** 다양한 상태(예: API 응답, 상태 머신)를 모델링할 때 공통 리터럴 속성(discriminant)을 사용하여 타입스크립트가 안전하게 타입을 좁히도록(Narrowing) 만드는 기법입니다 [1-3]. 이를 통해 유효하지 않은 상태가 공존하는 것을 방지할 수 있으며, `never` 타입을 활용한 완전성 검사(Exhaustiveness checking)를 구현하여 새로운 상태가 추가되었을 때 처리되지 않은 분기 로직을 컴파일 에러로 잡아낼 수 있습니다 [3-5].
-* **브랜디드 타입(Branded Types / Opaque Types) 도입:** TypeScript의 구조적 타이핑(Structural Typing) 특성으로 인해 발생하는 '기본 타입에의 집착(Primitive Obsession)' 문제를 해결합니다 [6]. 동일한 `string`이나 `number`라도 의미가 다른 데이터(`UserId`, `OrderId`, 통화 단위 등)를 구분하기 위해 컴파일 시점에만 존재하는 고유한 브랜드(가상의 속성이나 `unique symbol`)를 부여하여 의도치 않은 데이터 혼용과 오염을 차단합니다 [6-9].
-* **Parse, Don't Validate 원칙:** 외부 시스템과의 경계면에서 들어오는 안전하지 않은 데이터(`unknown`)를 단순히 유효성 검사하는 것에 그치지 않고, 시스템 내부에서 신뢰할 수 있는 구체적인 타입으로 변환(Parsing)하여 전달해야 합니다 [10-12].
-
-**안전한 설정 관리 및 불변성 유지**
-* **불변성(Immutability) 강제:** 설정(Configuration) 객체나 배열은 애플리케이션 전반에서 무단으로 수정(Mutation)되지 않도록 `readonly` 수식어, `Readonly<T>`, `ReadonlyArray` 등을 사용하여 컴파일 타임에 쓰기 작업을 차단해야 합니다 [13-15]. 중첩된 설정 객체의 깊은 수준까지 보호가 필요한 경우 재귀적 유틸리티 타입인 `DeepReadonly`를 적용하여 원천적으로 수정 가능성을 차단할 수 있습니다 [16, 17].
-* **`satisfies` 연산자를 활용한 설정 검증:** 설정 객체를 구성할 때 TypeScript 4.9에 도입된 `satisfies` 연산자를 사용하면 객체가 요구하는 인터페이스 구조를 만족하는지 검사하면서도, 동시에 속성의 구체적인 리터럴 타입과 추가적인 속성들을 넓히기(Widening) 없이 그대로 유지할 수 있습니다 [18-20]. 이는 일반적인 타입 어노테이션(`:`)의 넓히기 문제나, 오류를 은폐하는 타입 단언(`as`)의 단점을 보완하는 이상적인 설정 객체 관리 패턴입니다 [20-22].
-* **초과 속성 검사(Excess Property Checking, EPC) 방어:** 객체 리터럴을 직접 할당할 때 의도치 않은 추가 속성이나 오타를 걸러내는 메커니즘입니다 [23, 24]. 하지만 간접 할당 과정에서 이 검사가 우회될 수 있는 취약점이 존재하므로 [25, 26], `satisfies` 연산자나 엄격한 객체 타입 제어를 병행하여 설정 객체의 무결성을 방어해야 합니다 [20, 27].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[구조적 타이핑 (Structural Typing)]], [[식별 가능한 유니온 (Discriminated Unions)]], [[브랜디드 타입 (Branded Types)]], [[불변성 (Immutability)]], [[satisfies 연산자]]
-- **Projects/Contexts:** [[API 응답 및 상태 머신 모델링]], [[불변 설정 객체(Configuration Object) 관리 및 타입 검증]]
-- **Contradictions/Notes:** 
-  - `any` 타입을 사용하면 타입 시스템의 이점을 잃고 런타임 에러에 취약해지므로 금지해야 하며, 대신 데이터가 불확실할 때는 `unknown` 타입을 사용하고 타입 가드(Type Guard)를 거쳐 안전하게 사용해야 합니다 [28, 29].
-  - 객체 확장에 있어서 교집합 타입(Intersection, `&`)보다는 `Interface extends`를 사용하는 것이 TypeScript 컴파일러의 캐싱을 활용해 성능상 유리하고 더 직관적인 오류 메시지를 제공합니다 [30-32].
-
----
-*Last updated: 2026-04-18*
-- Raw Source: [[00_Raw/2026-04-20/안전한 TypeScript 데이터 모델링 및 설정 관리 구축.md]]
----
diff --git a/Programming & Language/안전한 소프트웨어 개발 수명주기(SSDLC).md b/Programming & Language/안전한 소프트웨어 개발 수명주기(SSDLC).md
deleted file mode 100644
index 7c00ebb9..00000000
--- a/Programming & Language/안전한 소프트웨어 개발 수명주기(SSDLC).md	
+++ /dev/null
@@ -1,33 +0,0 @@
----
-id: P-REINFORCE-AUTO-8F44F9
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - 안전한 소프트웨어 개발 수명주기(SSDLC)"
----
-
-# [[안전한 소프트웨어 개발 수명주기(SSDLC)]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 안전한 소프트웨어 개발 수명주기(SSDLC)는 개발 초기 단계부터 보안을 통합하여 취약점을 방지하고 소프트웨어의 전반적인 품질을 향상시키는 프로세스입니다 [1, 2]. 이 접근 방식은 정적 분석(SAST)과 실시간 코드 검사 도구를 개발 워크플로우에 내장하여 결함을 조기에 발견하고 수정하는 '시프트 레프트(Shift-Left)' 전략을 기반으로 합니다 [1, 3]. 결과적으로 조직은 대규모 개발 환경에서도 안전하고 고품질의 코드를 지속적으로 제공하고 거버넌스를 유지할 수 있습니다 [2, 4].
-
-## 📖 구조화된 지식 (Synthesized Content)
-- **초기 보안 통합 (시프트 레프트 전략):** SSDLC의 핵심 목적은 보안 취약점, 유지보수성 문제 및 논리적 결함을 개발 프로세스 초기에 감지하는 것입니다 [1]. 이처럼 보안 검사를 앞당기는 "시프트 레프트" 접근 방식을 통해, 개발자는 코드가 프로덕션 환경에 배포되기 전에 복잡한 코드 문제를 식별하고 신속하게 수정할 수 있습니다 [2, 3].
-- **보안 도구의 워크플로우 통합:** 성공적인 SSDLC 구현을 위해서는 보안 점검이 개발자의 방해 요소가 되지 않도록 통합 개발 환경(IDE), CI/CD 파이프라인, 풀 리퀘스트(Pull Request) 등에 매끄럽게 통합되어야 합니다 [1, 4, 5]. AI 기반 코드 검사기 및 SAST(정적 애플리케이션 보안 테스트) 도구는 코드가 작성되는 즉시 실시간으로 분석을 수행하여 OWASP 상위 취약점 등과 같은 위험 요소를 찾아냅니다 [2, 3, 6].
-- **지속적인 검사 및 SDLC 거버넌스:** 베이스라인을 설정하고 개발 주기 내내 여러 단계에서 코드를 빈번하게 스캔하여 새롭게 발생하거나 발전하는 보안 문제를 지속적으로 포착해야 합니다 [5]. 더불어 SDLC 거버넌스를 확립하여, AI가 생성한 코드와 인간이 작성한 코드 모두 엄격한 품질 게이트(Quality Gates)와 보안 표준을 통과하도록 통제합니다 [4, 7].
-- **규정 준수 및 보안 프레임워크 활용:** SSDLC 체계 내에서는 NIST의 안전한 소프트웨어 개발 프레임워크(SSDF)와 같은 산업 보안 표준을 준수하는 것이 매우 중요합니다 [6]. 이러한 보안 프레임워크는 조직의 안전한 코딩 표준을 기반으로 자동 및 수동 코드 리뷰와 코드 분석을 수행할 것을 의무화하고 있습니다 [6].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[SAST(정적 애플리케이션 보안 테스트)]], [[시프트 레프트(Shift-Left)]], [[DevSecOps]], [[코드 리뷰(Code Review)]]
-- **Projects/Contexts:** [[CI/CD 파이프라인 통합]], [[NIST SSDF(안전한 소프트웨어 개발 프레임워크)]]
-- **Contradictions/Notes:** 소스에 따르면 안전한 개발 수명주기를 위해 SAST 같은 자동화 보안 스캔 도구의 통합이 필수적이지만, 자동화 도구는 비즈니스 로직이나 맥락(Context)을 이해하지 못해 한계가 존재합니다 [8, 9]. 따라서 자동화된 도구로 기본적인 취약점을 빠르게 잡고, 인간의 통찰력이 필요한 아키텍처 및 논리 결함은 수동 코드 리뷰로 해결하는 하이브리드 접근 방식이 필수적이라고 권장합니다 [6, 8, 10].
-
----
-*Last updated: 2026-04-19*
-- Raw Source: [[00_Raw/2026-04-20/안전한 소프트웨어 개발 수명주기(SSDLC).md]]
----
diff --git a/Programming & Language/알 수 없는 외부 데이터 검증 (unknown types).md b/Programming & Language/알 수 없는 외부 데이터 검증 (unknown types).md
deleted file mode 100644
index faf0ed4d..00000000
--- a/Programming & Language/알 수 없는 외부 데이터 검증 (unknown types).md	
+++ /dev/null
@@ -1,37 +0,0 @@
----
-id: P-REINFORCE-AUTO-629DFB
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - 알 수 없는 외부 데이터 검증 (unknown types)"
----
-
-# [[알 수 없는 외부 데이터 검증 (unknown types)]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> TypeScript에서 알 수 없는 외부 데이터는 모든 JavaScript 값을 포함하는 `unknown` 타입으로 다루어집니다 [1, 2]. API 응답이나 JSON 파싱, 에러 핸들링처럼 데이터의 형태가 런타임에 불분명할 때 `any` 타입을 대신해 사용하는 안전한 대안입니다 [2]. 시스템 경계에서 타입 가드(Type Guard)나 파서를 통해 이 데이터를 명확한 타입으로 검증하고 좁혀야만 안전하게 사용할 수 있습니다 [2-4].
-
-## 📖 구조화된 지식 (Synthesized Content)
-- **`unknown` 타입의 개념과 안전성:**
-  TypeScript에서 `unknown` 타입은 가능한 모든 JavaScript 값의 집합을 의미합니다 [1]. `any` 타입과 달리, `unknown`으로 선언된 변수는 그 타입을 안전하게 확인하고 좁히기(narrowing) 전까지는 임의의 속성에 접근하거나 메서드를 호출할 수 없습니다 [2, 5]. 이는 알 수 없는 성분을 확인하지 않고 마시면 부작용이 발생할 수 있는 것처럼, 런타임의 예측할 수 없는 오류로부터 코드를 보호하는 역할을 합니다 [5, 6].
-
-- **"검증하지 말고 파싱하라 (Parse, don't validate)":**
-  외부에서 유입되는 알 수 없는 데이터는 시스템의 경계(진입점이나 응답 처리부 등)에서 즉시 파싱되어 잘 정의된(well-typed) 데이터로 변환되어야 합니다 [3, 7]. Zod와 같은 라이브러리를 활용해 알 수 없는 데이터를 미리 알고 있는 타입으로 변환시키면, 나머지 로직에서는 TypeScript의 정적 분석 시스템에 의존해 안정적인 처리가 가능해집니다 [3, 8].
-
-- **타입 가드(Type Guard)를 통한 타입 좁히기:**
-  `unknown` 타입의 데이터를 실제 로직에서 다루려면 반드시 타입 가드를 거쳐야 합니다 [2]. `typeof`나 `instanceof`와 같은 기본 검사를 활용하거나, 반환 타입에 `is` 키워드를 사용하는 커스텀 타입 가드 함수를 구현할 수 있습니다 [9]. 예를 들어 알 수 없는 객체가 `undefined`나 `null`이 아닌지 확인하고 내부 필수 속성들의 존재 여부를 검증한 뒤에야, 해당 데이터를 특정 타입으로 확신하고 조작할 수 있습니다 [4, 10].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[Type Guard]], [[Parse, don't validate]], [[any 타입]], [[Zod]]
-- **Projects/Contexts:** 외부 API 응답 처리, JSON 데이터 파싱, 에러 처리 등 런타임에 데이터 타입이 확정되지 않은 상황 [2], Zod 등의 런타임 검증 라이브러리를 이용한 데이터 스키마 검사 [8, 11].
-- **Contradictions/Notes:** `any` 타입은 타입 검사를 회피하게 해 주어 TypeScript의 이점을 상실하게 만드는 반면, `unknown` 타입은 어떤 값이든 받을 수 있으면서도 사용 전 타입 확인을 엄격하게 강제하므로 외부 데이터 처리에 훨씬 더 권장되는 방식입니다 [2, 5, 6].
-
----
-*Last updated: 2026-04-18*
-- Raw Source: [[00_Raw/2026-04-20/알 수 없는 외부 데이터 검증 (unknown types).md]]
----
diff --git a/Programming & Language/애자일 방법론 (Agile Methodology).md b/Programming & Language/애자일 방법론 (Agile Methodology).md
deleted file mode 100644
index 5012acdd..00000000
--- a/Programming & Language/애자일 방법론 (Agile Methodology).md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-3E4349
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - 애자일 방법론 (Agile Methodology)"
----
-
-# [[애자일 방법론 (Agile Methodology)]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/애자일 방법론 (Agile Methodology).md]]
----
diff --git a/Programming & Language/약한 타입 검사(Weak Type Detection).md b/Programming & Language/약한 타입 검사(Weak Type Detection).md
deleted file mode 100644
index 0a34bfbf..00000000
--- a/Programming & Language/약한 타입 검사(Weak Type Detection).md	
+++ /dev/null
@@ -1,32 +0,0 @@
----
-id: P-REINFORCE-AUTO-487E76
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - 약한 타입 검사(Weak Type Detection)"
----
-
-# [[약한 타입 검사(Weak Type Detection)]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 약한 타입 검사(Weak Type Detection)는 TypeScript에서 모든 속성이 선택적(optional)으로 구성된 '약한 타입(weak type)'에 대해 적용되는 특수한 타입 검사 메커니즘입니다 [1]. 이 검사는 할당하려는 객체가 대상이 되는 약한 타입과 공통된 속성을 단 하나도 가지고 있지 않을 때 타입 오류를 발생시킵니다 [1, 2]. 이는 약한 타입이 가진 구조적인 지나친 유연성을 보완하고, 개발자의 의도치 않은 객체 할당 실수를 방지하는 역할을 합니다 [1, 2].
-
-## 📖 구조화된 지식 (Synthesized Content)
-* **약한 타입(Weak Type)의 정의:** 약한 타입은 객체의 모든 속성이 선택적(optional)이며 비어 있지 않은 타입을 의미합니다 [1, 2]. TypeScript의 유틸리티 타입인 `Partial`을 통해 생성된 타입들 역시 모든 속성을 선택적으로 만들므로 이 약한 타입의 범주에 포함됩니다 [1].
-* **검사의 작동 원리:** 약한 타입은 구조적으로 매우 유연하기 때문에 타입 검사가 매우 느슨하게(weakly typechecked) 이루어지며, 일치하지 않는 속성을 가진 객체를 제외한 거의 모든 것을 할당받을 수 있습니다 [2]. 이러한 과도한 유연성으로 인한 오류를 막기 위해, TypeScript는 할당되는 객체가 대상 약한 타입과 완전히 분리(completely disjoint)되어 있는지 확인합니다 [2]. 즉, 두 타입 간에 "공통 속성이 하나도 없는지(No properties in common)"를 검사하고, 만약 하나도 없다면 특수한 타입 에러를 발생시킵니다 [1-3].
-* **잉여 속성 검사(Excess Property Checking)와의 한계점 교차:** 객체 리터럴을 직접 할당할 때 엄격하게 작동하는 잉여 속성 검사와 달리, 변수를 통해 객체를 간접적으로 전달할 때는 잉여 속성 검사가 우회될 수 있습니다 [3]. 변수를 통한 우회 할당 상황에서도 대상이 약한 타입이라면 공통 속성이 없을 때 약한 타입 검사 에러가 작동합니다 [1, 3]. 하지만 대상 객체와 할당 객체 간에 공통 속성이 **단 하나라도 존재한다면**, TypeScript는 나머지 잉여 속성이 존재하더라도 어떠한 에러도 발생시키지 않습니다 [2, 4].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[잉여 속성 검사(Excess Property Checking)]], [[선택적 속성(Optional Properties)]], [[Partial 유틸리티 타입]]
-- **Projects/Contexts:** [[TypeScript의 구조적 타이핑(Structural Typing)]]
-- **Contradictions/Notes:** 잉여 속성이 존재하더라도 우회 할당 시 대상 타입이 약한 타입이고 공통 속성이 최소 한 개 이상 존재한다면, TypeScript는 이를 유효한 것으로 간주하여 에러를 발생시키지 않는다는 점에 주의해야 합니다 [2, 4]. 
-
----
-*Last updated: 2026-04-18*
-- Raw Source: [[00_Raw/2026-04-20/약한 타입 검사(Weak Type Detection).md]]
----
diff --git a/Programming & Language/약한 타입 탐지 (Weak Type Detection).md b/Programming & Language/약한 타입 탐지 (Weak Type Detection).md
deleted file mode 100644
index 125b4632..00000000
--- a/Programming & Language/약한 타입 탐지 (Weak Type Detection).md	
+++ /dev/null
@@ -1,32 +0,0 @@
----
-id: P-REINFORCE-AUTO-3F076E
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - 약한 타입 탐지 (Weak Type Detection)"
----
-
-# [[약한 타입 탐지 (Weak Type Detection)]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 약한 타입 탐지(Weak Type Detection)는 TypeScript에서 오직 선택적(optional) 속성만으로 구성된 '약한 타입'에 객체를 할당할 때 발생하는 특별한 타입 검사 과정입니다 [1, 2]. 할당하려는 객체가 대상 약한 타입과 겹치는 공통 속성을 단 하나도 가지고 있지 않을 경우 컴파일 에러를 발생시킵니다 [1, 3]. 이를 통해 지나치게 유연한 타입 구조에서 발생할 수 있는 잠재적인 의도치 않은 할당 오류를 방지합니다 [2].
-
-## 📖 구조화된 지식 (Synthesized Content)
-- **약한 타입(Weak Type)의 정의:** TypeScript에서 '약한 타입'이란 속성이 비어있지 않으면서 오직 선택적(optional) 속성만 가지고 있는 객체 타입을 의미합니다 [2]. 대표적으로 `Partial` 유틸리티 타입을 사용하여 생성된 타입들이 이 약한 타입에 해당합니다 [1].
-- **탐지 및 에러 발생 조건:** 객체 리터럴이 아닌 변수로 추출된 간접적인 값을 약한 타입에 할당하려 할 때, 할당되는 객체와 대상이 되는 약한 타입 간에 공유하는 속성이 전혀 없다면(completely disjoint) TypeScript는 "공통 속성이 없음(No properties in common)"이라는 에러를 발생시킵니다 [1, 3]. 즉, 두 객체가 최소한 하나의 속성이라도 겹쳐야만 할당 및 함수 인자 전달이 허용됩니다 [2, 4].
-- **도입 목적:** 약한 타입은 그 구조적 특성상 매칭되지 않는 속성을 가진 일부 타입을 제외하고는 사실상 거의 모든 것을 할당할 수 있을 만큼 타입 검사가 매우 느슨하게 이루어집니다 [2]. 이러한 지나친 유연성으로 인해 무관한 객체가 잘못 할당되는 것을 막기 위한 최소한의 안전장치로서 작동하는 것이 바로 약한 타입 탐지입니다 [2].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[초과 속성 검사 (Excess Property Checking)]], [[선택적 속성 (Optional Properties)]], [[Partial 유틸리티 타입 (Partial Utility Type)]]
-- **Projects/Contexts:** [[TypeScript의 객체 할당 및 타입 검사 (TypeScript Object Assignment and Type Checking)]]
-- **Contradictions/Notes:** 객체 리터럴을 직접 할당할 때 동작하는 초과 속성 검사(Excess Property Checking)와 달리, 약한 타입 탐지는 변수를 통해 간접적으로 할당할 때 두 객체 간에 공통 속성이 아예 없을 때 예외적으로 발생하는 방어 기제입니다 [1, 3, 4].
-
----
-*Last updated: 2026-04-18*
-- Raw Source: [[00_Raw/2026-04-20/약한 타입 탐지 (Weak Type Detection).md]]
----
diff --git a/Programming & Language/양가감정(Ambivalence).md b/Programming & Language/양가감정(Ambivalence).md
deleted file mode 100644
index 7838c22e..00000000
--- a/Programming & Language/양가감정(Ambivalence).md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-0A598A
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - 양가감정(Ambivalence)"
----
-
-# [[양가감정(Ambivalence)]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/양가감정(Ambivalence).md]]
----
diff --git a/Programming & Language/에르고딕 문학(Ergodic Literature).md b/Programming & Language/에르고딕 문학(Ergodic Literature).md
deleted file mode 100644
index 1243cfb4..00000000
--- a/Programming & Language/에르고딕 문학(Ergodic Literature).md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-A5FDD2
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - 에르고딕 문학(Ergodic Literature)"
----
-
-# [[에르고딕 문학(Ergodic Literature)]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/에르고딕 문학(Ergodic Literature).md]]
----
diff --git a/Programming & Language/에일리어싱 (Aliasing).md b/Programming & Language/에일리어싱 (Aliasing).md
deleted file mode 100644
index 0719b9ae..00000000
--- a/Programming & Language/에일리어싱 (Aliasing).md	
+++ /dev/null
@@ -1,37 +0,0 @@
----
-id: P-REINFORCE-AUTO-E5B908
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - 에일리어싱 (Aliasing)"
----
-
-# [[에일리어싱 (Aliasing)]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 에일리어싱(Aliasing)은 프로그래밍에서 기존 데이터 타입에 새로운 이름을 부여하거나(타입 에일리어싱), 동일한 데이터를 여러 참조 변수가 가리키게 되는 현상(참조 에일리어싱)을 의미합니다 [1, 2]. TypeScript에서 타입 에일리어싱은 기존 타입과 상호 호환되는 서술적인 이름표 역할을 하며, 참조 에일리어싱은 `readonly` 데이터가 가변(mutable) 참조로 전달될 때 의도치 않은 데이터 변형(Mutation)을 일으키는 주요 원인이 되기도 합니다 [1-3].
-
-## 📖 구조화된 지식 (Synthesized Content)
-- **타입 에일리어싱 (Type Aliasing):**
-  TypeScript에서 `type` 키워드를 사용하여 기존 타입에 새로운 이름을 부여하는 것을 타입 에일리어스라고 부릅니다 [4]. 예를 들어 `type Percentage = number`와 같이 선언할 수 있으나, 이는 단순히 기존 타입에 새로운 이름을 부여하는 서술적인(descriptive) 역할만 할 뿐, 기능적으로 완전히 독립된 새로운 타입을 생성하는 것은 아닙니다(기존 타입과 상호 교환 가능) [1]. 주로 원시 타입(primitives), 유니언(unions), 튜플(tuples) 등 인터페이스로 표현하기 힘든 복잡한 타입 구성을 명명할 때 사용됩니다 [4, 5].
-
-- **데이터 참조 에일리어싱과 `readonly`의 함정:**
-  TypeScript에서 `readonly` 수식어를 사용할 때 개발자들이 가장 자주 겪는 함정은 에일리어싱(Aliasing)을 통한 데이터 변형입니다 [2]. `readonly`는 오직 해당 `readonly` 참조를 통한 직접적인 접근 및 수정만을 방지합니다 [6].
-
-- **타입 호환성으로 인한 변형 위험:**
-  만약 `readonly`로 선언된 배열이나 객체를 가변(mutable) 매개변수를 기대하는 함수에 전달할 경우, TypeScript는 타입 호환성(type compatibility)의 이유로 이를 허용하게 됩니다 [2]. 이렇게 에일리어싱이 발생하면 해당 함수 내부에서 가변 참조를 통해 원본 "readonly" 데이터를 수정할 수 있는 취약점이 발생합니다 [2, 3]. 이를 방지하기 위해서는 함수 시그니처를 신중하게 설계하여 `readonly` 매개변수를 받도록 강제하거나, 데이터를 복사하여 전달해야 합니다 [3].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[Type Alias (타입 별칭)]], [[Readonly]], [[Opaque Types (불투명 타입)]]
-- **Projects/Contexts:** [[TypeScript의 불변성(Immutability) 관리]], [[인터페이스와 타입 별칭 비교(Interface vs Type)]]
-- **Contradictions/Notes:** TypeScript의 `readonly`는 컴파일 타임에 불변성을 제공하는 강력한 도구이지만, 에일리어싱을 통해 데이터가 가변 매개변수로 전달될 경우에는 컴파일러가 이를 잡아내지 못하여 데이터가 수정될 수 있다는(얕은 불변성) 근본적인 한계를 지닙니다 [2, 6].
-
----
-*Last updated: 2026-04-18*
-- Raw Source: [[00_Raw/2026-04-20/에일리어싱 (Aliasing).md]]
----
diff --git a/Programming & Language/엑서게임(Exergaming).md b/Programming & Language/엑서게임(Exergaming).md
deleted file mode 100644
index dd3e2dba..00000000
--- a/Programming & Language/엑서게임(Exergaming).md	
+++ /dev/null
@@ -1,35 +0,0 @@
----
-id: P-REINFORCE-AUTO-F5CD6C
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - 엑서게임(Exergaming)"
----
-
-# [[엑서게임(Exergaming)]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 엑서게임(Exergaming)은 **운동(Exercise)과 게임 플레이(Gameplay)를 가상 환경에 결합하여 사용자의 신체 활동을 촉진하는 게임**이다 [1]. 이는 아동, 청소년, 성인 모두의 좌식 생활 습관(sedentary behavior)을 개선하기 위해 활용되며 달리기나 에어로빅과 비견되는 건강상의 이점을 제공한다 [1]. 특히 게임에 대한 몰입감을 통해 **사용자가 육체적 피로를 잊게 만들고 지속적인 운동 동기를 부여**하는 것이 가장 큰 특징이다 [2].
-
-## 📖 구조화된 지식 (Synthesized Content)
-* **신체적·심리적 이점 및 몰입(Flow)**: 
-  엑서게임은 전통적인 신체 운동보다 더 큰 즐거움과 긍정적인 감정을 유발한다 [1]. 사용자는 게임의 목표와 도전에 깊이 빠져드는 **몰입(flow state)을 경험하며, 이는 육체적 피로를 분산시키고 운동에 대한 높은 순응도를 이끌어낸다** [1, 2]. 대표적으로 상업적 성공을 거둔 가상현실(VR) 엑서게임인 '비트 세이버(Beat Saber)'를 플레이할 때 소모되는 에너지는 실제 환경에서 테니스를 치는 것과 맞먹는 것으로 평가된다 [3].
-* **가상현실(VR) 엑서게임과 부작용(VR Aftereffects)**: 
-  HMD(Head-Mounted Display)를 활용한 VR 엑서게임은 사용자의 몰입도(immersion)와 실재감(presence)을 극대화하여 엑서게임의 효과를 높인다 [2, 4]. 하지만 시각적 자극과 신체 움직임이 많은 엑서게임의 특성상 **가상현실 멀미(VR Sickness/Motion Sickness)를 유발**할 수 있으며, 이는 게임의 성과와 즐거움을 크게 저해하는 부정적 요인이 된다 [4-6].
-* **안전한 이용 가이드라인**:
-  연구에 따르면 엑서게임으로 인한 신체적/인지적 후유증을 최소화하기 위해 사용자는 장시간 노출 전 짧은 시간 동안 미리 테스트를 해보는 것이 권장된다 [7]. 또한 10분이나 50분 등 플레이 시간에 상관없이 VR 엑서게임을 종료한 후에는, 멀미 증상과 시력 및 인지적 후유증이 완전히 사라질 때까지 **운전 등 부상 위험이 있는 활동을 피하고 약 40분의 대기/휴식 시간**을 가져야 한다 [7, 8].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[Flow State]], [[Virtual Reality (VR) Sickness]], [[Sedentary Behavior]]
-- **Projects/Contexts:** [[비트 세이버(Beat Saber) 시각 및 인지 후유증 연구]]
-- **Contradictions/Notes:** 소스에 따르면, HMD를 사용하는 VR 엑서게임은 대형 스크린 기반의 엑서게임보다 몰입도가 높지만, 동시에 더 높은 수준의 멀미(VR Sickness)를 유발할 위험이 있다는 양면성(trade-off)을 지니고 있습니다 [4].
-
----
-*Last updated: 2026-04-19*
-- Raw Source: [[00_Raw/2026-04-20/엑서게임(Exergaming).md]]
----
diff --git a/Programming & Language/엔터프라이즈 소프트웨어 개발.md b/Programming & Language/엔터프라이즈 소프트웨어 개발.md
deleted file mode 100644
index a63b58d0..00000000
--- a/Programming & Language/엔터프라이즈 소프트웨어 개발.md	
+++ /dev/null
@@ -1,43 +0,0 @@
----
-id: P-REINFORCE-AUTO-117851
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - 엔터프라이즈 소프트웨어 개발"
----
-
-# [[엔터프라이즈 소프트웨어 개발]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 엔터프라이즈 소프트웨어 개발은 기업의 복잡한 비즈니스 요구사항을 충족시키기 위해 확장 가능하고, 유지보수가 쉬우며, 복원력 있는 대규모 시스템을 구축하는 과정입니다 [1, 2]. 이를 위해 관심사의 분리, 계층형 구조, 마이크로서비스 아키텍처와 같은 소프트웨어 아키텍처 모범 사례를 적용하여 기술 부채를 최소화하고 민첩성을 극대화합니다 [1, 3, 4]. 현대의 엔터프라이즈 시스템은 모놀리식 구조의 한계를 극복하고, 독립적인 개발과 배포가 가능한 모듈형 및 클라우드 네이티브 생태계로 진화하고 있습니다 [4, 5].
-
-## 📖 구조화된 지식 (Synthesized Content)
-* **핵심 아키텍처 설계 원칙:**
-  엔터프라이즈 소프트웨어의 견고한 기반은 '관심사의 분리(SoC)', DRY(Don't Repeat Yourself), SOLID 등 코드의 결합도를 낮추고 응집도를 높이는 설계 원칙에서 출발합니다 [6-8]. 시스템의 각 부분이 단일 책임을 갖도록 논리적 단위를 철저히 격리하면 여러 개발팀이 동시에 작업할 수 있는 모듈성이 확보되고, 변경에 유연하게 대응할 수 있는 유지보수성과 확장성이 보장됩니다 [9, 10].
-
-* **주요 아키텍처 패턴의 활용:**
-  * **계층형 아키텍처 (Layered Architecture):** 시스템을 프레젠테이션, 비즈니스 로직(도메인), 데이터 액세스 등의 수평적 계층으로 분리하여 인접한 계층과만 통신하도록 제한하는 전통적이고 필수적인 엔터프라이즈 패턴입니다 [3, 11].
-  * **마이크로서비스 아키텍처 (Microservices Architecture):** 복잡한 단일 시스템을 특정 비즈니스 기능을 담당하는 작고 자율적인 서비스들로 분해합니다 [4, 12]. 이를 통해 팀 단위로 독립적인 기술 스택 선택과 지속적 배포가 가능해져 엔터프라이즈의 혁신 속도를 높입니다 [4, 13].
-  * **이벤트 기반 아키텍처 (Event-Driven Architecture):** 컴포넌트 간에 비동기적으로 이벤트를 생산 및 소비하며 통신하게 하여, 고부하 환경이나 실시간 데이터 처리에서 시스템의 응답성과 결함 허용 능력을 크게 향상시킵니다 [14, 15].
-  * **클린 아키텍처 (Clean Architecture) 및 도메인 주도 설계 (DDD):** 가장 핵심이 되는 비즈니스 로직과 규칙을 시스템의 중심에 두고 UI, 데이터베이스, 프레임워크와 같은 기술적 세부 사항으로부터 완전히 분리합니다 [16, 17]. 비즈니스 전문가와 개발자가 공유하는 '보편적 언어(Ubiquitous Language)'를 바탕으로 복잡한 도메인 모델을 구축합니다 [16, 18].
-
-* **데이터 인프라 및 거버넌스:**
-  성공적인 엔터프라이즈 시스템은 비즈니스 가치를 창출하기 위해 안정적인 데이터 파이프라인과 인프라를 코드로서 관리(IaC)하는 방식을 도입합니다 [19, 20]. 또한 엄격한 데이터 품질 검증, 메타데이터 관리, 데이터 거버넌스 프레임워크를 수립하여 규정 준수를 보장하고 데이터 자산에 대한 신뢰를 구축해야 합니다 [21-23].
-
-* **소프트웨어의 테스트 용이성과 진화 가능성:**
-  테스트 주도 개발(TDD)과 같은 방법론을 통해 아키텍처 구성 요소들의 경계를 명확히 하고 독립적으로 검증 가능한 구조를 만들어야 합니다 [24, 25]. 철저하게 격리된 모듈과 명확한 인터페이스 계약은 병렬 개발을 돕고, 기존 시스템을 훼손하지 않으면서 새로운 기술과 기능을 유연하게 수용할 수 있는 '진화 가능한 아키텍처'를 구성합니다 [26, 27].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[소프트웨어 아키텍처 모범 사례]], [[마이크로서비스 아키텍처]], [[클린 아키텍처]], [[도메인 주도 설계 (DDD)]], [[관심사의 분리 (Separation of Concerns)]]
-- **Projects/Contexts:** [[넷플릭스(Netflix)의 마이크로서비스 및 Cosmos 플랫폼 전환 사례]], [[스포티파이(Spotify)의 스쿼드 모델 및 마이크로 프론트엔드 아키텍처 도입]]
-- **Contradictions/Notes:** 복잡성을 완벽하게 제어하기 위한 고도의 아키텍처 경계 구축이나 마이크로서비스로의 분할이 항상 정답은 아닙니다. 초기 팀 규모가 작거나 단순한 요구사항일 경우 모놀리식 구조가 효율적일 수 있으며, 미래를 위해 과도하게 완벽한 경계를 만드는 것은 YAGNI(You Aren't Gonna Need It) 원칙에 어긋나는 오버 엔지니어링이 될 수 있으므로 비용과 이점을 신중하게 따져 부분적 경계를 활용하는 것이 권장됩니다 [28-31].
-
----
-*Last updated: 2026-04-18*
-- Raw Source: [[00_Raw/2026-04-20/엔터프라이즈 소프트웨어 개발.md]]
----
diff --git a/Programming & Language/엔터프라이즈 소프트웨어 시스템 설계.md b/Programming & Language/엔터프라이즈 소프트웨어 시스템 설계.md
deleted file mode 100644
index bc860094..00000000
--- a/Programming & Language/엔터프라이즈 소프트웨어 시스템 설계.md	
+++ /dev/null
@@ -1,48 +0,0 @@
----
-id: P-REINFORCE-AUTO-CB60AE
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - 엔터프라이즈 소프트웨어 시스템 설계"
----
-
-# [[엔터프라이즈 소프트웨어 시스템 설계]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 엔터프라이즈 소프트웨어 시스템 설계는 비즈니스 요구사항을 충족하고 시간이 지남에 따라 시스템이 확장 및 유지보수될 수 있도록 돕는 견고하고 탄력적인 소프트웨어 기반의 청사진입니다 [1, 2]. 이는 관심사의 분리(SoC), 모듈화, 클린 아키텍처 등의 핵심 원칙을 통해 복잡한 시스템을 관리 가능한 단위로 분할하여 기술 부채를 최소화합니다 [1, 3, 4]. 결과적으로 잘 설계된 아키텍처는 개발 속도를 높이고, 독립적인 테스트를 가능하게 하며, 급변하는 비즈니스 환경에 시스템이 유연하게 적응할 수 있도록 지원합니다 [1, 5, 6].
-
-## 📖 구조화된 지식 (Synthesized Content)
-**엔터프라이즈 설계의 핵심 원칙**
-*   **관심사의 분리 (Separation of Concerns, SoC):** 복잡한 시스템을 작고 관리하기 쉬운 모듈로 분해하여, 각 부분이 단일 관심사나 기능에만 집중하도록 조직하는 소프트웨어 공학의 가장 기본적인 원칙입니다 [4, 7]. 이를 통해 모듈 간의 결합도(Coupling)는 낮추고 응집도(Cohesion)는 높여 코드의 가독성, 유지보수성, 그리고 독립적인 테스트 가능성을 획기적으로 향상시킵니다 [8-10].
-*   **SOLID 원칙:** 객체 지향 프로그래밍에서 시스템을 유연하고 이해하기 쉽게 만드는 5가지 핵심 설계 원칙(단일 책임, 개방/폐쇄, 리스코프 치환, 인터페이스 분리, 의존성 역전)입니다 [11, 12]. 이 중 단일 책임 원칙과 인터페이스 분리 원칙은 관심사의 분리 개념에서 직접적으로 파생되었습니다 [13, 14].
-*   **DRY (Don't Repeat Yourself) 원칙:** 시스템 내에서 동일한 비즈니스 규칙이나 논리의 중복을 추상화하여 한 곳에서만 관리하도록 함으로써 유지보수의 효율성을 높입니다 [15, 16].
-
-**주요 아키텍처 패턴**
-*   **클린 아키텍처 (Clean Architecture):** 비즈니스 로직과 애플리케이션 규칙을 시스템의 중심에 두고, 데이터베이스, 웹 프레임워크, UI 등 외부 기술적 세부사항으로부터 완전히 격리하는 철학입니다 [2, 17-19]. 소스 코드의 의존성이 항상 안쪽(고수준의 정책)으로만 향하도록 강제하는 '의존성 규칙(Dependency Rule)'을 준수하여 외부 에이전시의 변경이 핵심 업무 규칙에 영향을 주지 않도록 보호합니다 [20-22].
-*   **계층형 아키텍처 (Layered Architecture):** 애플리케이션을 프레젠테이션, 비즈니스 로직, 데이터 액세스 등의 수평적 계층으로 나누어 관심사를 분리하는 전통적인 엔터프라이즈 패턴입니다 [23, 24].
-*   **마이크로서비스 아키텍처 (Microservices Architecture):** 거대한 모놀리식(Monolithic) 시스템을 특정 비즈니스 역량에 집중하는 작고 자율적인 서비스들의 집합으로 분할합니다 [25-27]. 각 서비스는 독립적인 배포, 확장, 기술 스택 선택이 가능하여 개발의 민첩성을 제공합니다 [25, 28].
-*   **도메인 주도 설계 (Domain-Driven Design, DDD):** 복잡한 비즈니스 로직을 구현하기 위해 도메인 전문가와 개발자가 공유하는 '보편적 언어(Ubiquitous Language)'를 구축하고, 대규모 도메인을 '바운디드 컨텍스트(Bounded Context)'로 나누어 시스템을 모델링하는 접근법입니다 [29, 30].
-*   **이벤트 기반 아키텍처 (Event-Driven Architecture):** 시스템 컴포넌트들이 이벤트를 비동기적으로 생성하고 소비하며 통신하는 구조로, 구성 요소 간의 결합도를 낮추고 실시간 데이터 처리와 높은 확장성을 지원합니다 [31, 32].
-
-**확장성 및 품질 관리를 위한 실무 접근법**
-*   **관점 지향 프로그래밍 (AOP):** 로깅, 보안, 트랜잭션 등 시스템 전체에 흩어진 횡단 관심사(Cross-Cutting Concerns)를 별도의 모듈(Aspect)로 분리하여 코드 중복을 제거하고 유지보수성을 높입니다 [33-35].
-*   **테스트 주도 개발(TDD) 기반의 설계:** TDD는 AI 시스템처럼 복잡하고 비결정적인 시스템에서도 모듈성과 명확한 인터페이스를 강제하여, 설계 초기부터 독립적으로 테스트하고 유지보수할 수 있는 아키텍처를 구축하도록 유도합니다 [6, 36, 37].
-*   **마이크로 프론트엔드 (Micro Frontends):** 백엔드의 마이크로서비스 개념을 프론트엔드에 적용하여, 거대한 웹 UI를 여러 팀이 독립적으로 개발, 테스트, 배포할 수 있는 작은 모듈로 분할함으로써 프론트엔드의 복잡성을 관리합니다 [38-40].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[관심사의 분리 (Separation of Concerns)]], [[클린 아키텍처 (Clean Architecture)]], [[마이크로서비스 아키텍처]], [[도메인 주도 설계 (DDD)]], [[SOLID 원칙]]
-- **Projects/Contexts:** [[넷플릭스 코스모스 플랫폼 (Netflix Cosmos Platform)]], [[넷플릭스 마이크로서비스 마이그레이션]], [[스포티파이 마이크로 프론트엔드 (Spotify Micro Frontends)]]
-- **Contradictions/Notes:** 
-  - **아키텍처 도입의 트레이드오프:** 마이크로서비스는 독립적인 배포와 혁신을 돕지만, 서비스 간 분산 통신 구현, 여러 서비스에 걸친 요청 처리의 어려움, 메모리 사용량 증가 등 새로운 운영 및 개발 복잡성을 수반합니다 [41-43]. 
-  - **관심사 분리의 부작용:** 시스템의 결합도를 낮추고 모듈성을 높이기 위한 관심사의 분리도 지나치게 미세하게 적용할 경우, 성능 오버헤드, 함수 호출 깊이 증가, 조율을 위한 과도한 인디렉션(indirection) 발생 등 오버엔지니어링으로 이어져 오히려 가독성과 디버깅을 어렵게 만들 수 있습니다 [44-46]. 
-  - **TDD에 대한 오해:** AI 프로젝트 등에서 TDD가 실험 및 개발 주기를 늦춘다는 일반적인 오해가 있으나, 실제 사례(예: Spotify, Netflix)에 따르면 TDD를 통한 올바른 아키텍처 설계는 조기에 오류를 포착하여 오히려 개발 속도를 가속화합니다 [47].
-
----
-*Last updated: 2026-04-18*
-- Raw Source: [[00_Raw/2026-04-20/엔터프라이즈 소프트웨어 시스템 설계.md]]
----
diff --git a/Programming & Language/엔터프라이즈 애플리케이션 및 점진적 리팩토링.md b/Programming & Language/엔터프라이즈 애플리케이션 및 점진적 리팩토링.md
deleted file mode 100644
index 39dcf413..00000000
--- a/Programming & Language/엔터프라이즈 애플리케이션 및 점진적 리팩토링.md	
+++ /dev/null
@@ -1,33 +0,0 @@
----
-id: P-REINFORCE-AUTO-D8EB32
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - 엔터프라이즈 애플리케이션 및 점진적 리팩토링"
----
-
-# [[엔터프라이즈 애플리케이션 및 점진적 리팩토링]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 엔터프라이즈 애플리케이션은 종종 거대한 레거시 코드로 이루어져 있어 전체를 한 번에 재작성하는 것이 위험하고 비효율적입니다 [1, 2]. 따라서 전체 시스템을 한 번에 리팩토링하는 대신 새로운 기능이나 모듈 개발 시 설계 원칙을 서서히 적용하는 점진적 리팩토링(Incremental Refactoring)이 필수적입니다 [1, 3]. 이를 통해 기업은 기존 시스템의 안정성을 유지하면서 복잡한 기술 부채를 관리하고 시스템을 현대화할 수 있습니다 [2, 4].
-
-## 📖 구조화된 지식 (Synthesized Content)
-* **레거시 코드의 점진적 개선 전략:** 거대한 레거시 애플리케이션 전체를 한 번에 리팩토링할 필요는 없습니다 [1]. 새로운 기능을 추가하거나 기존 코드를 수정할 때 SOLID 원칙 등을 점진적으로 적용하여 코드베이스의 상태를 서서히 개선해 나가는 것이 올바른 접근법입니다 [1]. 
-* **클린 아키텍처의 단계적 도입:** 복잡한 의존성을 가진 기존 레거시 코드에 클린 아키텍처(Clean Architecture)를 통합하는 것은 쉽지 않습니다 [3]. 따라서 새로운 개발이나 신규 모듈에 클린 아키텍처를 점진적으로 도입하면서 기존 레거시 코드를 점차적으로 리팩토링하고, 시간이 지남에 따라 기존 구성 요소들을 풀고 계층을 명확히 구분해야 합니다 [3].
-* **스트랭글러 피그 패턴(Strangler Fig Pattern):** 크고 복잡한 레거시 엔터프라이즈 시스템을 마이그레이션할 때는 시스템 개편 프로젝트가 실패하는 위험을 줄이기 위해 '스트랭글러 피그 패턴'을 도입할 수 있습니다 [2]. 이는 넷플릭스(Netflix)가 기존 레거시 시스템(Reloaded)을 마이그레이션할 때 활용한 방식으로, 구형 시스템 주변에서 새로운 시스템을 서서히 성장시켜 궁극적으로 구형 시스템을 완전히 대체하게 만드는 기법입니다 [2].
-* **마이크로 프론트엔드를 통한 현대화:** 프론트엔드 단에서도 점진적 리팩토링이 적용됩니다 [4]. 시스템 전체를 재작성(rewriting)하지 않고도 새로운 기능을 추가할 수 있도록 해주는 마이크로 프론트엔드(Micro Frontends) 아키텍처는 레거시 시스템의 현대화를 훌륭하게 지원합니다 [4].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[SOLID Principles]], [[Clean Architecture]], [[Strangler Fig Pattern]], [[Micro Frontends]]
-- **Projects/Contexts:** [[넷플릭스의 레거시 시스템(Reloaded) 마이그레이션 프로젝트]], [[넷플릭스 대시보드 레거시 현대화]]
-- **Contradictions/Notes:** 소스에 관련 정보가 부족합니다.
-
----
-*Last updated: 2026-04-18*
-- Raw Source: [[00_Raw/2026-04-20/엔터프라이즈 애플리케이션 및 점진적 리팩토링.md]]
----
diff --git a/Programming & Language/엔터프라이즈 애플리케이션 설계.md b/Programming & Language/엔터프라이즈 애플리케이션 설계.md
deleted file mode 100644
index a2a21616..00000000
--- a/Programming & Language/엔터프라이즈 애플리케이션 설계.md	
+++ /dev/null
@@ -1,45 +0,0 @@
----
-id: P-REINFORCE-AUTO-98C87D
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - 엔터프라이즈 애플리케이션 설계"
----
-
-# [[엔터프라이즈 애플리케이션 설계]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 엔터프라이즈 애플리케이션 설계는 기술적 부채와 느린 성능, 엉성한 사용자 경험을 방지하고 복잡한 비즈니스 요구사항을 견딜 수 있는 확장 가능하고 유지보수가 용이한 시스템의 청사진을 구축하는 과정입니다 [1]. 이를 위해 관심사의 분리(SoC), 모듈화, 도메인 주도 설계 등의 철학과 아키텍처 패턴이 적용되며, 대규모 개발 환경에서 각 기능이 상호 간섭 없이 유연하게 확장 및 배포될 수 있도록 하는 것을 핵심 목표로 삼습니다 [1-3].
-
-## 📖 구조화된 지식 (Synthesized Content)
-엔터프라이즈 애플리케이션을 성공적으로 설계하기 위해서는 핵심 설계 원칙의 적용과 비즈니스 규모에 맞는 아키텍처 패턴의 선택이 필수적입니다. 
-
-**핵심 설계 원칙**
-*   **관심사의 분리 (Separation of Concerns, SoC)**: 가장 기초적인 소프트웨어 공학 원칙으로, 시스템을 뚜렷한 기능과 책임 단위로 나누어 코드의 가독성, 재사용성, 테스트 가능성을 높이는 것을 의미합니다 [2, 4, 5]. 이 원칙의 궁극적인 공학적 지향점은 모듈 내부의 관련성을 뜻하는 **응집도(Cohesion)**를 극대화하고, 모듈 간의 상호 의존성을 나타내는 **결합도(Coupling)**를 최소화하는 것입니다 [6-8].
-*   **SOLID와 DRY 원칙**: 각 클래스가 하나의 책임만을 갖게 하는 단일 책임 원칙(SRP)을 비롯한 SOLID 원칙과, 비즈니스 로직의 중복을 방지하는 DRY(Don't Repeat Yourself) 원칙은 기술적 부채를 최소화하는 견고한 기반이 됩니다 [9-11].
-*   **관점 지향 프로그래밍 (AOP)**: 로깅, 보안, 트랜잭션 관리와 같이 시스템 전반에 흩어진 횡단 관심사(Cross-Cutting Concerns)를 수평적으로 분리해 핵심 비즈니스 로직의 순수성을 보존합니다 [12-14].
-
-**주요 아키텍처 패턴**
-*   **계층형 및 클린 아키텍처 (Layered & Clean Architecture)**: 시스템을 논리적인 수평 계층(예: UI, 비즈니스 로직, 데이터 액세스)으로 나누고 인접한 계층 간에만 통신하도록 제한합니다 [15, 16]. 클린 아키텍처는 이를 심화하여, 외부 세계(DB, 프레임워크, UI)의 변경이 가장 순수한 핵심 비즈니스 규칙(엔티티, 유스케이스)에 영향을 주지 않도록 소스 코드 의존성을 항상 안쪽을 향하게 강제합니다 [17-19].
-*   **마이크로서비스 아키텍처 (Microservices Architecture, MSA)**: 단일 시스템으로 모든 기능이 묶여 있는 모놀리식 구조에서 탈피해, 비즈니스 역량을 중심으로 작고 독립적인 서비스 단위로 시스템을 분해합니다 [20]. 이를 통해 다수의 팀이 병렬로 개발과 배포를 수행할 수 있어 기민성과 복원력이 향상됩니다 [3, 20, 21].
-*   **도메인 주도 설계 (Domain-Driven Design, DDD)**: 단순한 기술적 계층이 아닌, 비즈니스 현실을 반영한 '바운디드 컨텍스트(Bounded Context)'를 중심으로 복잡한 도메인을 나누어 설계합니다 [22-24].
-*   **이벤트 기반 (Event-Driven) 및 API 우선 (API-First) 아키텍처**: 상태 변화를 비동기 이벤트로 발행하여 서비스 간 결합을 느슨하게 만들거나(EDA), 명확한 API 계약을 우선 정의하여 프론트엔드와 백엔드의 완벽한 병렬 개발을 지원합니다 [25, 26].
-
-**프론트엔드 및 인프라 설계 패러다임**
-*   **마이크로 프론트엔드 (Micro Frontends)**: 백엔드의 마이크로서비스처럼 프론트엔드 역시 거대한 하나의 코드베이스가 아니라 기능(Feature) 단위의 작고 독립적인 모듈들로 쪼개어 구성합니다 [27, 28].
-*   **클라우드 네이티브와 코드형 인프라 (IaC)**: 컨테이너와 오케스트레이션(Kubernetes 등)을 활용해 일관된 환경을 유지하고, 데이터베이스 및 클라우드 리소스를 코드로 관리(Terraform 등)하여 재현성을 보장합니다 [29, 30].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[관심사의 분리(SoC)]], [[클린 아키텍처]], [[마이크로서비스 아키텍처]], [[도메인 주도 설계(DDD)]], [[관점 지향 프로그래밍(AOP)]], [[마이크로 프론트엔드]]
-- **Projects/Contexts:** [[넷플릭스(Netflix)의 마이크로서비스 및 코스모스 플랫폼 전환]], [[스포티파이(Spotify)의 스쿼드 모델 및 마이크로 프론트엔드 도입]]
-- **Contradictions/Notes:** 분리와 추상화가 무조건적인 장점만을 갖는 것은 아닙니다. 다수의 소스에서는 완벽한 아키텍처 경계를 만드는 데는 초기 비용이 상당히 크고, 과도한 분리(오버 엔지니어링)는 불필요한 인지적 부하 증대 및 네트워크 통신 성능 저하(오버헤드)를 유발할 수 있다고 경고합니다 [14, 31, 32]. 따라서 "Rule of Three(중복이 세 번 발생하면 추상화하라)"와 같은 실용적 접근을 통해 응집도와 결합도의 적절한 균형을 찾는 것이 엔지니어의 핵심 과제입니다 [14, 33].
-
----
-*Last updated: 2026-04-18*
-- Raw Source: [[00_Raw/2026-04-20/엔터프라이즈 애플리케이션 설계.md]]
----
diff --git a/Programming & Language/오래된 공간(Old Space).md b/Programming & Language/오래된 공간(Old Space).md
deleted file mode 100644
index e74deddb..00000000
--- a/Programming & Language/오래된 공간(Old Space).md	
+++ /dev/null
@@ -1,34 +0,0 @@
----
-id: P-REINFORCE-AUTO-0AE506
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - 오래된 공간(Old Space)"
----
-
-# [[오래된 공간(Old Space)]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 오래된 공간(Old Space)은 V8 자바스크립트 엔진의 힙(Heap) 메모리에서 새로운 공간(New Space)에 생성된 후 두 번의 마이너 가비지 컬렉션(Minor GC) 주기 동안 살아남은 장기 생존 객체들이 이동(승격)하여 저장되는 메모리 영역입니다 [1-3]. 이 공간은 비교적 크기가 크고 장기 데이터 보존을 위해 설계되었으며, 마크-스윕(Mark-Sweep) 및 마크-컴팩트(Mark-Compact) 알고리즘을 사용하는 메이저 가비지 컬렉션(Major GC)에 의해 관리됩니다 [3-5].
-
-## 📖 구조화된 지식 (Synthesized Content)
-* **구조와 분류**: V8 엔진은 '세대 가설(Generational Hypothesis)'에 기반하여 힙을 조직하며, 오래된 공간은 이 중 '구세대(Old Generation)'에 해당합니다 [3, 6, 7]. 가비지 컬렉션 시 효율적인 메모리 스캔을 위해, 이 공간은 다른 객체를 가리키는 포인터를 포함하는 'Old-pointer-space'와 문자열이나 박싱된 숫자처럼 원시 데이터만 포함하는 'Old-data-space'로 세분화됩니다 [3, 8, 9]. 데이터 공간을 별도로 분리함으로써 가비지 컬렉터는 불필요한 포인터 추적 단계를 건너뛰어 성능을 최적화할 수 있습니다 [9].
-* **객체의 승격(Promotion)**: 대부분의 객체는 처음에 할당이 빠르고 크기가 작은 새로운 공간(New Space)에 배치됩니다 [3, 8]. 이 영역에서 발생하는 스캐빈지(Scavenge)라는 마이너 가비지 컬렉션을 두 번 겪고도 살아남은 객체는 수명이 긴 객체로 간주되어 오래된 공간으로 복사되는데, 이 과정을 '승격(Promotion)'이라고 합니다 [1, 2, 10].
-* **메이저 가비지 컬렉션(Major GC)**: 새로운 공간과 달리 오래된 공간은 수백 메가바이트의 방대한 데이터를 포함할 수 있어 물리적으로 메모리를 복사하는 스캐빈지 방식은 비효율적입니다 [4, 5]. 따라서 V8은 마크-스윕(Mark-Sweep) 및 마크-컴팩트(Mark-Compact) 알고리즘을 적용합니다 [4, 5]. 루트(Root) 객체로부터 도달 가능한 객체들을 마킹(Mark)한 뒤, 도달할 수 없는 메모리 영역을 해제(Sweep)하여 여유 리스트(Free list)로 반환합니다 [5, 11, 12]. 단편화(Fragmentation)가 심한 경우에는 객체들을 이동시켜 여유 공간을 압축(Compact)하는 작업도 함께 수행합니다 [5, 13, 14].
-* **쓰기 장벽(Write Barriers)의 활용**: 오래된 공간의 객체가 새로운 공간의 객체를 가리키는 경우, V8은 '쓰기 장벽(Write barrier)' 메커니즘을 이용해 해당 포인터의 위치를 스토어 버퍼(Store buffer)에 기록합니다 [15]. 덕분에 마이너 GC를 수행할 때마다 수백 메가바이트에 달하는 오래된 공간 전체를 스캔할 필요 없이, 새로운 객체의 생존 여부를 신속하게 파악할 수 있습니다 [15, 16].
-* **메모리 분석 및 튜닝 시사점**: 브라우저나 Node.js의 타임라인을 통해 힙 할당 시점을 분석할 때, 객체들이 계속해서 가비지 컬렉트되지 않고 오래된 공간에 축적되어 베이스라인 메모리가 지속적으로 상승하는 현상(래칫 패턴, Ratchet pattern)이 발생한다면 이는 메모리 누수의 명확한 징후입니다 [17, 18]. 캐시나 사용자 세션 등 영구적인 데이터가 많은 애플리케이션의 경우 `--max-old-space-size` 플래그를 설정하여 오래된 공간의 최대 허용 크기를 늘려 충돌이나 성능 저하를 방지할 수 있습니다 [19, 20].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[새로운 공간(New Space)]], [[가비지 컬렉션(Garbage Collection)]], [[세대 가설(Generational Hypothesis)]], [[마크-스윕(Mark-Sweep)]], [[마크-컴팩트(Mark-Compact)]]
-- **Projects/Contexts:** [[V8 엔진 힙 아키텍처(V8 Engine Heap Architecture)]], [[할당 타임라인(Allocation Timeline)]], [[Node.js 메모리 튜닝]]
-- **Contradictions/Notes:** 소스에 내용 상의 모순은 없으며, V8 메모리 관리의 핵심인 세대 가설에 기반하여 새롭게 생성된 단기 생존 객체 공간(New Space)과 명확하게 분리 관리되어 엔진의 전체적인 가비지 컬렉션 효율을 높인다는 점이 일관되게 강조되고 있습니다.
-
----
-*Last updated: 2026-04-19*
-- Raw Source: [[00_Raw/2026-04-20/오래된 공간(Old Space).md]]
----
diff --git a/Programming & Language/오리노코(Orinoco GC).md b/Programming & Language/오리노코(Orinoco GC).md
deleted file mode 100644
index 5f2b233f..00000000
--- a/Programming & Language/오리노코(Orinoco GC).md	
+++ /dev/null
@@ -1,35 +0,0 @@
----
-id: P-REINFORCE-AUTO-6488F2
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - 오리노코(Orinoco GC)"
----
-
-# [[오리노코(Orinoco GC)]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 오리노코(Orinoco)는 V8 엔진의 가비지 컬렉터(GC)를 개선하기 위한 프로젝트의 코드명으로, 기존의 순차적인 'Stop-the-world' 방식의 가비지 컬렉터를 병렬(Parallel), 동시(Concurrent), 점진적(Incremental) 처리 기법을 적용하여 새롭게 탈바꿈시켰습니다 [1, 2]. 이 프로젝트의 주요 목적은 메인 스레드의 부하를 줄이고 GC로 인한 일시 정지(Pause) 시간을 최소화하는 것입니다 [2]. 이를 통해 애니메이션, 스크롤, 사용자 상호작용의 지연 시간을 줄이고 전반적인 프로그램 처리량과 성능을 향상시킵니다 [3, 4].
-
-## 📖 구조화된 지식 (Synthesized Content)
-오리노코 가비지 컬렉터는 메인 스레드를 해방시키고 일시 정지 시간을 줄이기 위해 다음과 같은 세 가지 핵심 기법과 다양한 최적화를 도입했습니다 [2].
-
-*   **병렬(Parallel) 처리:** 메인 스레드와 여러 헬퍼 스레드가 동시에 같은 양의 GC 작업을 나누어 수행하는 방식입니다 [2]. 이 방식은 여전히 'Stop-the-world' 형태를 띠지만, 참여하는 스레드 수만큼 총 일시 정지 시간을 분할하여 단축시킵니다 [2]. 특히 동적 작업 훔치기(Dynamic work stealing) 알고리즘을 사용하는 새로운 '병렬 스캐빈저(Parallel Scavenger)'를 도입하여, 메인 스레드의 젊은 세대(Young generation) GC 소요 시간을 작업 부하에 따라 20%~50%까지 감소시켰습니다 [4-6].
-*   **점진적(Incremental) 처리:** 메인 스레드가 전체 GC 작업을 한 번에 처리하지 않고, 작은 조각으로 나누어 JavaScript 실행 사이사이에 간헐적으로 수행하는 방식입니다 [7]. 이 방식은 GC에 소요되는 총 시간을 줄이지는 못하지만 작업을 시간 단위로 분산시켜 애플리케이션이 사용자 입력이나 애니메이션 렌더링에 계속 반응할 수 있게 해줍니다 [7].
-*   **동시(Concurrent) 처리:** 메인 스레드가 JavaScript를 지속적으로 실행하는 동안, 헬퍼 스레드들이 백그라운드에서 완전히 독립적으로 GC 작업을 수행하는 기술입니다 [8]. 힙(Heap)의 상태가 언제든 변할 수 있어 동기화 및 읽기/쓰기 충돌(Race condition) 문제를 해결해야 하는 가장 어려운 기술이지만, 메인 스레드를 완전히 자유롭게 해준다는 큰 장점이 있습니다 [8]. V8의 메이저 GC(Major GC)는 이 기법을 활용하여 백그라운드에서 동시 마킹(Concurrent marking)과 동시 스위핑(Concurrent sweeping)을 수행합니다 [9, 10].
-*   **추가 최적화 구조:** 오리노코는 힙 메모리를 고정 크기의 '페이지(Pages)'로 분할하고, 페이지 수준에서 복사 및 압축(Compaction) 작업을 병렬화하여 압축 시간을 75% 감소시켰습니다 [6]. 또한, 가비지 컬렉션 중 객체 이동에 따른 포인터 업데이트 속도를 높이기 위해 특정 페이지에서 발생하는 '관심 포인터(Interesting pointers)'를 추적하는 기억 집합(Remembered set)을 활용합니다 [11]. 오래된 세대(Old generation)에 최근 할당된 객체는 다음 GC에서 생존할 가능성이 높다고 가정하여 블랙 페이지에 할당하고 스위핑을 생략하는 '블랙 할당(Black allocation)' 기법도 도입했습니다 [12].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[가비지 컬렉터(Garbage Collector)]], [[V8 엔진(V8 Engine)]], [[마크-스위프(Mark-Sweep)]], [[스캐빈저(Scavenger)]], [[Stop-the-world]]
-- **Projects/Contexts:** [[JavaScript 메모리 관리(JavaScript Memory Management)]]
-- **Contradictions/Notes:** 점진적(Incremental) GC 기법은 메인 스레드의 응답성을 높이고 지연(Latency) 문제를 해결하는 데에는 효과적이지만, 메인 스레드에서 소비되는 총 시간 자체를 줄여주지는 않으며 오히려 작업 분산으로 인해 약간 증가시킬 수 있다고 소스는 지적합니다 [7].
-
----
-*Last updated: 2026-04-19*
-- Raw Source: [[00_Raw/2026-04-20/오리노코(Orinoco GC).md]]
----
diff --git a/Programming & Language/오리노코(Orinoco) 프로젝트.md b/Programming & Language/오리노코(Orinoco) 프로젝트.md
deleted file mode 100644
index bfa708ff..00000000
--- a/Programming & Language/오리노코(Orinoco) 프로젝트.md	
+++ /dev/null
@@ -1,35 +0,0 @@
----
-id: P-REINFORCE-AUTO-C362F7
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - 오리노코(Orinoco) 프로젝트"
----
-
-# [[오리노코(Orinoco) 프로젝트]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 오리노코(Orinoco) 프로젝트는 구글의 V8 자바스크립트 엔진에 탑재된 최신 가비지 컬렉터(GC)를 개선하기 위한 프로젝트의 코드명입니다 [1, 2]. 기존의 순차적이고 메인 스레드를 완전히 멈추게 하는 "stop-the-world" 방식의 한계를 극복하기 위해 시작되었습니다 [2, 3]. 이를 위해 병렬(parallel), 점진적(incremental), 동시(concurrent) 처리 기법을 도입하여 메인 스레드의 부담을 해방시키고 애플리케이션의 일시 정지 시간(Pause time)을 최소화하는 것을 목표로 합니다 [4, 5].
-
-## 📖 구조화된 지식 (Synthesized Content)
-* **오리노코의 주요 목표:** 전통적인 가비지 컬렉터는 메인 스레드의 자바스크립트 실행을 완전히 멈추고 작업을 수행해야 하므로 화면 끊김(Jank)과 지연(Latency) 문제를 유발하여 프로그램 처리량을 감소시켰습니다 [6]. 오리노코는 가비지 컬렉션 작업을 백그라운드 태스크로 분산시키고 메인 스레드를 해방시켜, 사용자 상호작용과 애니메이션 렌더링을 훨씬 부드럽게 만드는 데 집중했습니다 [4, 7].
-* **3가지 핵심 GC 고도화 기법:**
-  * **병렬 처리(Parallel):** 메인 스레드와 여러 헬퍼 스레드가 동시에 가비지 컬렉션 작업을 나누어 수행합니다 [8]. 자바스크립트 실행이 멈추는 "stop-the-world" 접근 방식이긴 하지만, 전체 정지 시간을 참여하는 스레드의 수만큼 나누어 대폭 단축시킵니다 [8]. V8은 젊은 세대(Young Generation)를 처리하는 Scavenger GC에 병렬 스캐빈징을 도입하였습니다 [9].
-  * **점진적 처리(Incremental):** 메인 스레드가 한 번에 전체 가비지 컬렉션을 수행하지 않고, 자바스크립트를 실행하는 중간중간 간헐적으로 아주 작은 조각 단위의 GC 작업을 수행합니다 [10].
-  * **동시 처리(Concurrent):** 메인 스레드가 자바스크립트를 끊임없이 실행하는 동안, 헬퍼 스레드들이 완전히 백그라운드에서 GC 작업을 처리하는 가장 고도화된 방식입니다 [11]. 메이저 GC(Major GC)의 마킹(Marking)과 스위핑(Sweeping) 단계에 동시 처리 기법이 사용됩니다 [12, 13].
-* **도입 효과 및 성과:** 오리노코 프로젝트를 통해 메인 스레드에서 수행되던 가비지 컬렉션 작업이 약 56% 감소했습니다 [3]. 병렬 Scavenger는 워크로드에 따라 메인 스레드의 젊은 세대 GC 시간을 20%~50% 줄였으며, 동시 마킹 및 스위핑 기술은 무거운 WebGL 게임 등에서 일시 정지 시간을 최대 50%까지 감소시켰습니다 [7].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[가비지 컬렉션(Garbage Collection)]], [[V8 엔진(V8 Engine)]], [[스캐빈저(Scavenger)]], [[메이저 GC(Major GC)]]
-- **Projects/Contexts:** [[자바스크립트(JavaScript)]], [[크롬 브라우저(Chrome Browser)]]
-- **Contradictions/Notes:** 점진적(Incremental) GC 기법은 메인 스레드에서 소요되는 전체 총시간을 줄여주지는 않으며 오히려 약간 늘릴 수도 있습니다. 하지만 GC 작업을 여러 시간에 걸쳐 분산시킴으로써 애플리케이션의 애니메이션이나 사용자 입력에 대한 응답성을 유지할 수 있도록 돕습니다 [10].
-
----
-*Last updated: 2026-04-19*
-- Raw Source: [[00_Raw/2026-04-20/오리노코(Orinoco) 프로젝트.md]]
----
diff --git a/Programming & Language/오버드로우(Overdraw).md b/Programming & Language/오버드로우(Overdraw).md
deleted file mode 100644
index f358d127..00000000
--- a/Programming & Language/오버드로우(Overdraw).md	
+++ /dev/null
@@ -1,32 +0,0 @@
----
-id: P-REINFORCE-AUTO-8CE1CE
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - 오버드로우(Overdraw)"
----
-
-# [[오버드로우(Overdraw)]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 오버드로우(Overdraw)는 렌더링 파이프라인의 프래그먼트 셰이딩(Fragment Shading) 단계에서 동일한 픽셀 위치에 대해 여러 번의 쓰기 작업이 중첩되어 발생하는 현상이다 [1]. 주로 겹쳐진 투명한 기하구조나 비효율적인 깊이 정렬(Depth Sorting)로 인해 보이지 않는 픽셀 연산에 GPU 자원을 낭비하게 만든다 [2]. 이는 결과적으로 불필요한 GPU 픽셀 처리 비용을 유발하여 심각한 프레임 속도 저하 및 성능 병목을 초래한다 [1, 3].
-
-## 📖 구조화된 지식 (Synthesized Content)
-- **오버드로우의 발생 원리:** 오버드로우는 GPU가 한 프레임 내에서 겹쳐진 기하구조로 인해 동일한 픽셀을 여러 번 렌더링할 때 발생한다 [2]. 불투명한 물체의 경우, 일반적으로 '앞에서 뒤로(Front-to-Back)' 정렬하여 렌더링함으로써 뒤에 가려진 픽셀 연산을 조기에 종료(Early-Z)할 수 있으나, 정렬되지 않은 상태로 카메라와 가장 멀리 있는 객체가 먼저 그려질 경우 GPU는 동일한 픽셀 영역에 중복된 계산을 수행하게 된다 [1]. 투명한 재질의 경우에는 올바른 알파 블렌딩을 위해 '뒤에서 앞으로(Back-to-Front)' 렌더링을 강제받으므로, 숨겨진 픽셀을 건너뛰는 초기 깊이 테스트(Early-Z) 최적화가 비활성화되어 오버드로우가 더욱 심화된다 [2, 4].
-- **InstancedMesh와 오버드로우:** Three.js의 `InstancedMesh`는 단일 드로우 콜로 다수의 객체를 렌더링하지만 자동 정렬(Sorting) 기능을 제공하지 않아 내부 인스턴스들이 버퍼에 저장된 순서대로 렌더링된다 [1, 5, 6]. 이로 인해 드로우 콜 감소로 얻은 CPU 이득보다, 정렬되지 않은 인스턴스들이 유발하는 막대한 오버드로우 비용이 GPU의 픽셀 처리 성능을 상회하는 역전 현상이 일어날 수 있다 [1]. 특히 복잡한 조명 연산이 포함된 `MeshStandardMaterial` 등을 사용할 경우 씬(Scene)이 프래그먼트 바운드(Fragment-bound) 상태에 빠져 치명적인 프레임 드랍을 유발한다 [1, 6].
-- **오버드로우 최적화 및 해결 방안:** 투명도로 인한 오버드로우를 최소화하려면 알파 테스트 투명도(Alpha-tested transparency)를 가능한 한 불투명한 기하구조로 변환하거나, 가장자리 스무딩에 Alpha-to-coverage를 사용해야 한다 [2, 7]. 또한 투명한 객체 간의 겹침이 줄어들도록 렌더링 순서를 신중하게 정렬해야 한다 [7]. `InstancedMesh`의 정렬 부재 문제를 극복하기 위해서는 각 인스턴스들이 렌더링되는 방식을 카메라 기준으로 개별 정렬(Sorting)할 수 있는 대안적 기술(`BatchedMesh` 등)을 고려할 수 있다 [6, 8].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[프래그먼트 셰이딩(Fragment Shading)]], [[깊이 정렬(Depth Sorting)]], [[Early-Z (초기 깊이 테스트)]], [[프래그먼트 바운드(Fragment-bound)]]
-- **Projects/Contexts:** [[Three.js InstancedMesh 최적화]], [[투명도(Transparency) 렌더링 관리]]
-- **Contradictions/Notes:** `InstancedMesh`는 드로우 콜(Draw Call)을 획기적으로 줄여 CPU 오버헤드를 감소시키는 최적화 기법으로 알려져 있으나, 자동 정렬 기능이 없어 오히려 막대한 오버드로우를 유발하고 GPU 픽셀 처리 성능을 크게 저하시킬 수 있다는 구조적인 모순(트레이드오프)을 지니고 있다 [1].
-
----
-*Last updated: 2026-04-19*
-- Raw Source: [[00_Raw/2026-04-20/오버드로우(Overdraw).md]]
----
diff --git a/Programming & Language/오탐 (False Positive).md b/Programming & Language/오탐 (False Positive).md
deleted file mode 100644
index c056b2ac..00000000
--- a/Programming & Language/오탐 (False Positive).md	
+++ /dev/null
@@ -1,37 +0,0 @@
----
-id: P-REINFORCE-AUTO-86DCBE
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - 오탐 (False Positive)"
----
-
-# [[오탐 (False Positive)]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-*   **오탐의 발생 원인:** 
-    자동화된 도구는 소스 코드를 해석할 때 사전에 정의된 특정 패턴과 가정에 의존합니다 [4, 5]. 기술적으로 파격적이지만 특정 문제에 가장 적합한 코드이거나, 사용자 입력 검증이 다른 파일이나 프론트엔드/백엔드 계층에서 이미 안전하게 처리된 경우에도 도구가 이러한 문맥을 이해하지 못하면 이를 보안 문제로 잘못 식별하여 오탐을 발생시킵니다 [1, 5].
-*   **오탐이 미치는 악영향 (오탐의 역설):** 
-    자동화된 정적 분석 도구들은 상황에 따라 30~60%, 레거시 도구의 경우 최대 50~80%에 달하는 높은 오탐률을 보이기도 합니다 [3, 5]. 이처럼 끊임없이 발생하는 오탐은 개발자들이 실제로는 버그가 아닌 문제를 분류하는 데 소중한 시간을 낭비하게 만들고 심각한 '경고 피로(Alert Fatigue)'를 유발합니다 [1-3]. 결과적으로 알림이 오탐으로 오염되면 개발자들은 점차 도구의 출력을 무시하거나 일괄 해제(batch-dismiss)하게 되며, 이로 인해 실제로 존재하는 치명적인 취약점마저 놓치게 되는 '오탐의 역설(False Positive Paradox)'에 빠질 위험이 큽니다 [6].
-*   **오탐 해결 및 완화 전략:**
-    *   **AI 및 머신러닝의 활용:** 최근의 AI 네이티브 SAST 도구들은 대규모 언어 모델(LLM)과 의미론적 분석을 결합하여 코드의 문맥을 깊이 이해함으로써 노이즈를 필터링하고 오탐을 대폭 줄이고 있습니다 [7-10].
-    *   **지속적인 피드백 루프와 튜닝:** 오탐이 자주 나타나는 패턴이 있다면, 도구의 임계값을 조정하고 조직의 환경에 맞게 규칙을 튜닝(tuning)하는 지속적인 관리가 필수적입니다 [6, 11].
-    *   **하이브리드 코드 리뷰 도입:** 자동화 도구를 일차적 방어선으로 사용하여 명백한 문법 오류나 알려진 취약점을 빠르게 잡아내고, 사람이 개입하는 수동 리뷰를 통해 문맥과 비즈니스 로직을 면밀히 판단하여 오탐을 걷어내는 방식이 현대적인 모범 사례로 권장됩니다 [11, 12].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[정적 애플리케이션 보안 테스트 (SAST)]], [[경고 피로 (Alert Fatigue)]], [[하이브리드 코드 리뷰]]
-- **Projects/Contexts:** [[Snyk Code]], [[Corgea]], [[Semgrep Assistant]]
-- **Contradictions/Notes:** 소스에서는 일반적인 자동화 정적 분석 도구가 30~60% 혹은 최대 80%에 이르는 높은 오탐률을 보이며 치명적인 경고 피로를 유발한다고 지적하지만 [3, 5], 동시에 벤더사의 보고에 따르면 특정 최신 AI 네이티브 SAST 도구(예: Veracode, Corgea)는 오탐률을 1.1% 미만 또는 5% 미만 수준으로 극적으로 낮출 수 있다고 주장하여 AI 기술 발전에 따른 상반된 오탐 관리 성능을 보여줍니다 [13]. 
-
----
-*Last updated: 2026-04-18*
-- Raw Source: [[00_Raw/2026-04-20/오탐 (False Positive).md]]
----
diff --git a/Programming & Language/오픈소스 컴포넌트 (Open Source Components).md b/Programming & Language/오픈소스 컴포넌트 (Open Source Components).md
deleted file mode 100644
index d692e84c..00000000
--- a/Programming & Language/오픈소스 컴포넌트 (Open Source Components).md	
+++ /dev/null
@@ -1,34 +0,0 @@
----
-id: P-REINFORCE-AUTO-AAE756
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - 오픈소스 컴포넌트 (Open Source Components)"
----
-
-# [[오픈소스 컴포넌트 (Open Source Components)]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 오픈소스 컴포넌트(또는 오픈소스 종속성)는 현대 애플리케이션의 80~90%를 구성하는 제3자(Third-party) 제공 라이브러리 및 코드 패키지입니다 [1, 2]. 이는 소프트웨어 개발 속도를 높여주지만, 알려진 취약점이나 라이선스 위반 문제를 포함할 수 있어 소프트웨어 공급망 보안의 핵심 관리 대상이 됩니다 [2, 3]. 이를 안전하게 유지하기 위해 기업들은 소프트웨어 구성 분석(SCA) 도구를 통해 오픈소스 컴포넌트를 스캔하고 관리합니다 [1, 4].
-
-## 📖 구조화된 지식 (Synthesized Content)
-* **애플리케이션 내 막대한 비중:** 오늘날 개발되는 애플리케이션 코드의 80~90%는 오픈소스 종속성(Dependencies)으로 이루어져 있습니다 [1]. 개발자들은 오픈소스 커뮤니티의 코드를 활용하여 개발을 효율화하며, 많은 수의 오픈소스 라이브러리를 프로젝트에 포함시키는 것이 일반적인 관행입니다 [1, 2].
-* **소프트웨어 공급망 보안 위협 (Supply Chain Security):** 오픈소스 파이프라인은 본질적으로 '신뢰'를 기반으로 운영됩니다 [5]. 만약 합법적인 패키지의 메인테이너(유지보수자) 계정이 피싱 등을 통해 해킹당하면, 악성 코드가 포함된 패키지 업데이트가 수천만 건의 다운스트림 설치로 퍼져나가는 공급망 공격으로 이어질 수 있습니다 [5-7].
-* **취약점 및 라이선스 위험 식별:** 오픈소스 컴포넌트는 개발자가 직접 작성한 커스텀 코드와 달리 제3자가 작성했으므로, 이미 보고된 알려진 취약점(CVE)이나 라이선스 규정 준수 위험(License issues)을 수반할 수 있습니다 [3, 4].
-* **SCA(소프트웨어 구성 분석) 도구를 통한 관리:** 오픈소스 컴포넌트의 안전한 사용을 위해 SCA 도구(예: Snyk Open Source, Endor Labs 등)가 사용됩니다 [4, 8]. 이 도구들은 `package.json`, `pom.xml` 등의 매니페스트 파일을 분석하여 어떤 오픈소스 컴포넌트가 사용되었는지 인벤토리(SBOM)를 파악하고, 취약점이 있는 패키지를 안전한 버전으로 업그레이드하도록 돕습니다 [4, 9].
-* **심층 도달 가능성(Reachability) 분석:** 최근의 오픈소스 보안 관리는 단순한 취약점 패키지 존재 유무를 넘어서, 애플리케이션의 코드가 실제로 오픈소스 내의 취약한 함수를 호출하는지(Function-level reachability)를 분석하여 실제 위험 우선순위를 결정하는 수준으로 발전하고 있습니다 [8, 10, 11].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[Software Composition Analysis (SCA)]], [[Supply Chain Security]], [[SAST (Static Application Security Testing)]]
-- **Projects/Contexts:** [[Snyk Open Source]], [[Endor Labs]]
-- **Contradictions/Notes:** 자체적으로 작성한 커스텀 코드의 논리적 결함과 새로운 취약점을 찾는 데는 SAST가 적합하지만, 오픈소스 및 제3자 컴포넌트에 포함된 기존 취약점과 라이선스 문제를 탐지하는 데에는 SCA가 특화되어 있으므로 보안을 위해 이 두 가지를 함께 사용하는 것이 권장됩니다 [2, 3].
-
----
-*Last updated: 2026-04-18*
-- Raw Source: [[00_Raw/2026-04-20/오픈소스 컴포넌트 (Open Source Components).md]]
----
diff --git a/Programming & Language/완전성 검사 (Exhaustiveness Checking).md b/Programming & Language/완전성 검사 (Exhaustiveness Checking).md
deleted file mode 100644
index d5aec6bb..00000000
--- a/Programming & Language/완전성 검사 (Exhaustiveness Checking).md	
+++ /dev/null
@@ -1,33 +0,0 @@
----
-id: P-REINFORCE-AUTO-98C2AC
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - 완전성 검사 (Exhaustiveness Checking)"
----
-
-# [[완전성 검사 (Exhaustiveness Checking)]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-- **개념 및 필요성:** 완전성 검사는 시스템이 확장되거나 타입이 변경될 때 발생하는 부작용을 원천 차단하는 방어 기제입니다 [3]. 예를 들어, 특정 유니온 타입에 새로운 형태(예: 새로운 도형 타입, 네트워크 상태, API 응답 등)가 추가되었을 때, 기존의 분기문(`switch` 등)에서 이를 다루지 않으면 컴파일 타임 에러를 발생시켜 누락 사실을 즉각적으로 알려줍니다 [1, 2, 4]. 
-- **`never` 타입을 활용한 검증 기법:** 가장 강력하고 명시적인 완전성 검사 방법은 타입스크립트의 `never` 타입을 활용하는 것입니다. 분기문에서 유니온의 모든 가능한 케이스를 처리한 후, 남은 값을 `default` 블록이나 `assertNever`와 같은 검증 함수로 전달하여 `never` 타입에 할당하도록 작성합니다 [3, 5]. 만약 개발자가 처리하지 않은 케이스가 남아있다면, 해당 변수는 `never`가 아닌 실제 할당 가능한 타입을 가지게 되므로 "Type 'X' is not assignable to type 'never'"와 같은 컴파일 에러를 즉시 발생시킵니다 [2, 3, 5].
-- **반환 타입 지정을 통한 검증:** `strictNullChecks` 옵션을 활성화하고 함수의 반환 타입을 명시적으로 지정하는 방법도 있습니다 [6]. 모든 `switch` 케이스를 처리하지 않고 빠져나오는 경로가 생긴다면, 컴파일러는 해당 함수가 `undefined`를 반환할 수 있다고 인지하여 명시된 반환 타입과의 불일치 에러를 보고합니다 [6].
-- **라이브러리 및 고급 문법 활용 (`ts-pattern`, `satisfies`):** `ts-pattern`과 같은 패턴 매칭 라이브러리가 제공하는 `.exhaustive()` 메서드를 사용하면, 처리되지 않은 모든 경우를 타입스크립트 컴파일러가 감지하고 강제하도록 구현할 수 있습니다 [7, 8]. 또한, 분기문의 마지막에 `satisfies never` 키워드를 사용하여 처리되지 않은 다른 케이스가 없음을 보장할 수 있습니다 [9]. 이러한 패턴들은 '불가능한 상태'를 코드상에서 표현하지 못하게 만듭니다 [3].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[식별 가능한 유니온 (Discriminated Unions)]], [[never 타입]], [[ts-pattern]], [[satisfies 연산자]]
-- **Projects/Contexts:** [[타입스크립트 상태 관리 및 분기 처리 설계]]
-- **Contradictions/Notes:** 소스에서는 완전성 검사의 효과를 긍정적으로 평가하지만, `ts-pattern` 라이브러리의 `.exhaustive()` 등을 활용한 고도의 추상화는 기본 제어 구조(`if/else`, `switch`)보다 성능이 현저히 떨어지고 오버엔지니어링이 될 수 있음을 경계합니다. 따라서 단순한 조건의 경우, 기존 방식과 `satisfies never` 등을 조합하여 가독성을 높이고 안전하게 분기를 처리하는 것이 더 나을 수 있다고 조언합니다 [7-10].
-
----
-*Last updated: 2026-04-18*
-- Raw Source: [[00_Raw/2026-04-20/완전성 검사 (Exhaustiveness Checking).md]]
----
diff --git a/Programming & Language/완전성 검사(Exhaustiveness Checking).md b/Programming & Language/완전성 검사(Exhaustiveness Checking).md
deleted file mode 100644
index dd75f927..00000000
--- a/Programming & Language/완전성 검사(Exhaustiveness Checking).md	
+++ /dev/null
@@ -1,33 +0,0 @@
----
-id: P-REINFORCE-AUTO-0C762B
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - 완전성 검사(Exhaustiveness Checking)"
----
-
-# [[완전성 검사(Exhaustiveness Checking)]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 완전성 검사(Exhaustiveness Checking)는 타입 시스템 내에서 특정 유니온 타입의 모든 가능한 케이스(변형)가 코드상에서 빠짐없이 처리되었는지를 컴파일 시점에 검증하는 기법입니다[1-3]. 식별 가능한 유니온(Discriminated Unions)과 함께 결합하여 주로 사용되며, 새로운 상태가 추가되었을 때 이를 처리하지 않은 분기문이 존재하면 즉시 컴파일 에러를 발생시킵니다[2, 3]. 이를 통해 개발자는 런타임 버그를 사전에 예방하고 잘못된 상태가 시스템을 통과하는 것을 원천적으로 차단할 수 있습니다[4, 5].
-
-## 📖 구조화된 지식 (Synthesized Content)
-- **기본 작동 원리:** 완전성 검사는 데이터의 모든 가능한 형태가 `switch` 문 등의 분기 구조에서 명시적으로 다루어졌는지 확인합니다[1, 2]. 특정 유니온 타입에 새로운 형태(Shape)나 상태를 추가했지만, 이를 제어문에서 처리하는 코드를 작성하는 것을 잊었다면, 컴파일러는 누락된 부분에 대해 에러를 던집니다[2, 3]. 이는 런타임에 발생할 수 있는 잠재적 결함을 컴파일 시점의 에러로 전환해 줍니다[3-5].
-- **`never` 타입을 활용한 검사 기법:** TypeScript에서 완전성 검사를 구현하는 가장 확실한 방법 중 하나는 `never` 타입을 사용하는 것입니다[3, 6, 7]. 모든 유효한 케이스를 걸러낸 후 남은 값을 `never` 타입(예: `assertNever` 함수 등)으로 할당하도록 작성합니다[7]. 만약 개발자가 실수로 특정 케이스를 누락했다면, 남은 값은 `never`가 아닌 실제 타입(누락된 타입)을 가지게 되어 컴파일 에러가 발생하며, 에러 메시지를 통해 어떤 타입이 누락되었는지 명확히 알 수 있습니다[3, 7].
-- **`strictNullChecks`를 활용한 반환 타입 검사:** 또 다른 방법으로는 TypeScript의 `strictNullChecks` 기능을 켜고 함수에 명시적인 반환 타입을 지정하는 방식이 있습니다[6]. 모든 케이스를 철저히 처리하지 않은 분기문은 암묵적으로 `undefined`를 반환할 가능성을 내포하게 되므로, 반환 타입 규칙 위반으로 에러를 발생시켜 완전성을 강제할 수 있습니다[6].
-- **다양한 환경에서의 활용 패턴:** TypeScript의 기본 제어 구조뿐만 아니라, `ts-pattern`과 같은 패턴 매칭 라이브러리에서도 `.exhaustive()` 문법을 활용하여 처리되지 않은 케이스를 타입스크립트 컴파일러가 감지하도록 돕습니다[8]. 또한 C#과 같은 다른 언어 환경에서도, 결과를 철저히 소진(exhausting)하지 않으면 컴파일이 되지 않게 구조화하여 오류를 안전하게 처리하는 동일한 목적의 설계 방식이 사용됩니다[9].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[식별 가능한 유니온(Discriminated Unions)]], [[never 타입]], [[타입 좁히기(Type Narrowing)]]
-- **Projects/Contexts:** [[TypeScript 컴파일러의 정적 타입 시스템]], [[패턴 매칭 라이브러리(ts-pattern 등)]]
-- **Contradictions/Notes:** TypeScript에서 `strictNullChecks`를 활용한 반환 타입 검사 방식은 구형 코드베이스에서 항상 원활하게 작동하지 않을 수 있으며 다소 미묘한 방식인 반면, `never` 타입을 활용한 검사 방식은 오류 메시지에 누락된 타입 이름이 포함되어 더 명확하게 문제를 파악할 수 있다는 장점이 있습니다[6, 7].
-
----
-*Last updated: 2026-04-18*
-- Raw Source: [[00_Raw/2026-04-20/완전성 검사(Exhaustiveness Checking).md]]
----
diff --git a/Programming & Language/외부 API 데이터 및 설정 파일 처리.md b/Programming & Language/외부 API 데이터 및 설정 파일 처리.md
deleted file mode 100644
index 5568c573..00000000
--- a/Programming & Language/외부 API 데이터 및 설정 파일 처리.md	
+++ /dev/null
@@ -1,35 +0,0 @@
----
-id: P-REINFORCE-AUTO-90144B
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - 외부 API 데이터 및 설정 파일 처리"
----
-
-# [[외부 API 데이터 및 설정 파일 처리]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 외부 API 데이터 및 설정 파일 처리는 애플리케이션의 경계에서 유입되는 불확실한 외부 데이터를 안전하게 타입 시스템으로 통합하고, 설정값의 불변성과 정확한 구조를 강제하는 과정입니다 [1-3]. TypeScript에서는 원격 소스의 데이터를 단순히 타입으로 단언하기보다 런타임 스키마를 통해 파싱하는 원칙을 따릅니다 [4]. 또한, API 응답과 설정 객체를 안전하게 다루기 위해 식별 가능한 유니온, readonly 수식어, satisfies 연산자 등의 언어적 도구를 적극적으로 활용합니다 [5-7].
-
-## 📖 구조화된 지식 (Synthesized Content)
-*   **외부 데이터의 파싱 (Parse, Don't Validate):** 
-    원격 소스나 API에서 유입되는 데이터에 대해 TypeScript의 타입이나 인터페이스를 진실의 원천(Source of truth)으로 삼아서는 안 됩니다 [4]. 외부 API의 구조가 변경되면 타입 동기화가 어긋날 위험이 있기 때문입니다 [4]. 따라서 Zod와 같은 라이브러리를 사용해 시스템 경계에서 알 수 없는 데이터를 한 번 파싱 및 검증하여, 애플리케이션 내부 로직에서는 완벽히 타입이 지정된 안전한 데이터만 다루도록 하는 것이 권장됩니다 [1, 8-10].
-*   **API 응답 모델링 및 데이터 매핑:** 
-    복잡한 API 응답 상태(예: 성공, 실패, 로딩 등)를 모델링할 때는 '식별 가능한 유니온(Discriminated Unions)'이 매우 효과적입니다 [5, 11]. 한편, 백엔드 데이터를 프론트엔드 모델로 매핑할 때 구조적 타이핑의 특성으로 인해 의도치 않은 초과 속성이나 오타가 유입될 수 있습니다 [12, 13]. 이 경우 `satisfies` 연산자를 활용하면 값의 구체적인 타입 추론을 유지하면서도 의도한 타입 계약을 엄격히 강제하여 잘못된 데이터 유입을 컴파일 타임에 차단할 수 있습니다 [7, 14, 15]. 만약 OpenAPI 스펙이 정의되어 있다면, 이를 파싱해 SDK를 자동 생성하는 코드를 구축하는 것도 훌륭한 접근법입니다 [16].
-*   **설정 파일(Configuration)의 불변성과 유효성 검증:** 
-    설정 객체는 애플리케이션 수명 주기 동안 변경되어서는 안 되므로, `readonly` 수식어를 통해 컴파일 타임에 불변성을 보장해야 합니다 [2, 6, 17, 18]. 중첩된 설정 객체의 모든 속성을 보호하려면 자체적인 `DeepReadonly` 유틸리티 타입을 구현하여 사용할 수 있습니다 [19]. 특히 설정 파일에 `as const` 단언과 `satisfies` 연산자를 결합하여 사용하면, 런타임의 불변성을 확보하는 동시에 객체의 구조가 요구사항에 맞는지 강력하게 검증할 수 있어 자동 완성과 안전성이라는 두 마리 토끼를 모두 잡을 수 있습니다 [3, 20-22].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[Parse, Don't Validate]], [[Discriminated Unions]], [[satisfies 연산자]], [[readonly 수식어]], [[Zod 스키마 파싱]]
-- **Projects/Contexts:** [[OpenAPI 스펙 기반 SDK 자동 생성]], [[프론트엔드와 백엔드 간 데이터 매핑]]
-- **Contradictions/Notes:** 외부에서 유입되는 데이터를 처리할 때 단순히 `as` 연산자를 통한 타입 단언(Type Casting)을 사용하는 것은 초과 속성 검사(Excess Property Checking)를 우회하여 런타임 버그를 초래할 수 있으므로, 검증 로직이나 `satisfies` 연산자를 사용하는 것이 훨씬 안전합니다 [14, 15].
-
----
-*Last updated: 2026-04-18*
-- Raw Source: [[00_Raw/2026-04-20/외부 API 데이터 및 설정 파일 처리.md]]
----
diff --git a/Programming & Language/외부 API 데이터의 런타임 검증 후 처리.md b/Programming & Language/외부 API 데이터의 런타임 검증 후 처리.md
deleted file mode 100644
index d08e3bde..00000000
--- a/Programming & Language/외부 API 데이터의 런타임 검증 후 처리.md	
+++ /dev/null
@@ -1,33 +0,0 @@
----
-id: P-REINFORCE-AUTO-99B08D
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - 외부 API 데이터의 런타임 검증 후 처리"
----
-
-# [[외부 API 데이터의 런타임 검증 후 처리]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 외부 API 데이터의 런타임 검증 후 처리는 시스템 경계에서 알 수 없거나 느슨한 타입의 외부 데이터를 검증 및 변환하여, 시스템 내부로 신뢰할 수 있는 구체적인 타입의 데이터를 전달하는 과정을 의미합니다 [1], [2]. 이는 "검증하지 말고 파싱하라(Parse, don't validate)" 철학에 기반을 두며, Zod와 같은 라이브러리를 활용해 런타임에 데이터를 검증한 뒤 브랜디드 타입(Branded Types)이나 식별 가능한 유니온(Discriminated Unions)으로 안전하게 변환하여 처리하는 것을 핵심으로 합니다 [3], [4], [5], [6].
-
-## 📖 구조화된 지식 (Synthesized Content)
-- **"Parse, Don't Validate" 철학의 적용:** 외부 API로부터 들어오는 데이터는 시스템의 진입점(Boundary)에서 단 한 번만 파싱(검증 및 변환)되어야 합니다 [1], [4]. 단순히 데이터의 유효성을 체크하는 것에 그치지 않고, 데이터를 더 구체적이고 신뢰할 수 있는 타입의 객체로 변환하여 내부로 전달해야 합니다 [1], [2]. 이를 통해 검증 로직이 시스템 전체에 흩어지는 것을 방지하고, 나머지 코드에서 정적 분석과 타입 체커를 온전히 신뢰할 수 있게 됩니다 [4].
-- **런타임 검증과 브랜디드 타입(Branded Types)의 결합:** 런타임 검증은 브랜디드 타입과 결합될 때 최고의 효과를 냅니다 [5]. Zod와 같은 검증 라이브러리의 `.brand()` 메서드를 활용하면, 외부 데이터를 검증함과 동시에 고유한 브랜드 속성을 부여할 수 있습니다 [6]. 이렇게 검증을 마친 데이터(예: `SanitizedString`)만이 시스템 내부 비즈니스 로직으로 진입하도록 강제함으로써, 잘못된 데이터의 유입을 철저히 차단하는 수비대 역할을 합니다 [7], [8], [2].
-- **API 응답을 위한 식별 가능한 유니온(Discriminated Unions) 모델링:** 외부 API 응답이 성공, 실패, 로딩 등 다양한 형태를 가질 수 있을 때 런타임 검증과 함께 식별 가능한 유니온을 사용합니다 [9], [3], [10]. 이는 백엔드 응답 데이터를 프론트엔드 모델로 매핑할 때, 잘못된 속성 이름(오타)이나 원치 않는 필드가 슬쩍 포함되는 오류를 컴파일 타임 및 런타임에 안전하게 방지해 줍니다 [3], [10], [11].
-- **안전한 에러 처리 수단 (Zod `.safeParse()` 등):** 타입스크립트의 타입 검사가 닿지 않는 외부 소스(API, 설정 파일 등)의 데이터에 대해서는 Zod 같은 런타임 유효성 검사 도구가 필수적입니다 [3], [12]. 특히 검증 실패 시 예외(Exception)를 바로 던지기보다, `.safeParse()`와 같은 메서드를 사용해 결과 객체(Result Object)를 반환하도록 처리함으로써 예측 가능한 에러 처리를 가능하게 하고 애플리케이션의 결함 허용성을 높일 수 있습니다 [13], [14], [6].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[Parse, Don't Validate]], [[Branded Types]], [[Discriminated Unions]], [[Zod 런타임 검증]]
-- **Projects/Contexts:** [[API Response Handling]], [[시스템 경계 데이터 파싱(System Boundary Data Parsing)]]
-- **Contradictions/Notes:** 외부 데이터 무결성을 위해 런타임 검증이 필수적이지만, 런타임 검증에는 성능 비용(Runtime cost)이 수반되므로 성능에 매우 민감한 경로(performance-critical paths)에서는 사용 시 주의가 필요합니다 [15].
-
----
-*Last updated: 2026-04-18*
-- Raw Source: [[00_Raw/2026-04-20/외부 API 데이터의 런타임 검증 후 처리.md]]
----
diff --git a/Programming & Language/외부 라이브러리 API 설계.md b/Programming & Language/외부 라이브러리 API 설계.md
deleted file mode 100644
index 06628316..00000000
--- a/Programming & Language/외부 라이브러리 API 설계.md	
+++ /dev/null
@@ -1,40 +0,0 @@
----
-id: P-REINFORCE-AUTO-44799B
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - 외부 라이브러리 API 설계"
----
-
-# [[외부 라이브러리 API 설계]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 외부 라이브러리(SDK) API 설계는 사용자가 내부의 복잡한 구현을 알 필요 없이 명확한 의도에 따라 기능을 쉽게 사용할 수 있도록 인터페이스를 구축하는 과정입니다 [1]. 이를 위해 퍼사드(Facade) 패턴을 활용하여 일반적인 유스케이스를 고수준 API로 제공하고, 특수 케이스를 위해 세밀한 제어가 가능한 저수준 API를 탈출구(Escape Hatch)로 함께 제공하는 것이 핵심입니다 [2, 3]. 잘 설계된 API 인터페이스는 사용자의 휴먼 에러를 구조적으로 방지하며, 장기적인 호환성과 플랫폼의 안정성을 보장합니다 [3-5].
-
-## 📖 구조화된 지식 (Synthesized Content)
-* **퍼사드(Facade) 패턴을 통한 사용자 의도 중심 설계:**
-  외부 라이브러리 API 설계에서 퍼사드 패턴의 본질은 단순히 기능을 숨기는 것이 아닙니다. 인증, 재시도, 클린업(Cleanup)과 같은 내부의 복잡한 오케스트레이션 로직을 '사용자의 의도(Intent)' 기준으로 재구성하는 것입니다 [1]. 이를 통해 사용자의 인지 부하를 줄이고 내부 시스템과의 결합도를 낮출 수 있습니다 [1, 6].
-
-* **고수준(High-level)과 저수준(Low-level) 인터페이스의 공존 균형:**
-  훌륭한 SDK는 파레토 법칙에 기반하여 두 가지 계층의 인터페이스를 모두 제공해야 합니다. 전체 사용 사례의 80%에 해당하는 반복적인 공통 유스케이스는 고수준의 퍼사드 인터페이스로 간단하게 제공해야 합니다 [2, 3]. 동시에 나머지 20%의 특수한 세밀한 제어가 필요한 경우를 위해 원자적 호출이 가능한 저수준 인터페이스를 탈출구(Escape Hatch)로 열어두어야 합니다 [2, 3]. 이러한 공존은 단기적인 개발자 경험(DX) 향상뿐 아니라 장기적인 하위 호환성 유지에도 큰 도움이 됩니다 [3, 7].
-
-* **단일 책임 원칙(SRP)과 구조적 리소스 관리:**
-  라이브러리 사용자가 감당해야 하는 절차적 책임이나 정리(Cleanup) 책임을 암묵적으로 남겨두면 메모리 누수와 같은 장애로 이어지기 쉽습니다 [4, 5]. 설계 시 "리소스를 만든 곳에서 닫는다"는 단일 책임 원칙을 적용하여, 사용자의 실수로 발생할 수 있는 이벤트 및 리스너 누수를 방지하는 안전장치를 SDK 내부에 구조화해야 합니다 [8].
-
-* **인터페이스 분리 원칙(ISP)을 통한 확장성 확보:**
-  하나의 인터페이스가 너무 많은 책임을 가지게 되면 변경에 취약해집니다 [6]. 내부 복잡성을 단순한 인터페이스로 감싸되, 인터페이스를 최소 단위로 분리하여 필요한 시점에 조합해 사용하게 함으로써 "수정에는 닫혀 있고 확장에는 열려 있는" 안정적인 설계 구조를 가져갈 수 있습니다 [6].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[퍼사드 패턴(Facade Pattern)]], [[단일 책임 원칙(SRP)]], [[인터페이스 분리 원칙(ISP)]], [[탈출구(Escape Hatch)]]
-- **Projects/Contexts:** [[Toss Front 외부 연동 SDK]], [[AWS CDK]]
-- **Contradictions/Notes:** 퍼사드 패턴을 통해 추상화 수준을 높이면 사용성이 크게 개선되지만, 동시에 사용자의 세밀한 제어를 제한하고 라이브러리 내부의 유지보수 비용과 복잡도를 증가시키는 트레이드오프가 필연적으로 발생합니다. 따라서 저수준 API를 탈출구로 제공하여 설계의 균형을 잡는 것이 매우 중요합니다 [3, 7].
-
----
-*Last updated: 2026-04-18*
-- Raw Source: [[00_Raw/2026-04-20/외부 라이브러리 API 설계.md]]
----
diff --git a/Programming & Language/웹 애플리케이션의 3계층 구조.md b/Programming & Language/웹 애플리케이션의 3계층 구조.md
deleted file mode 100644
index a8efffcb..00000000
--- a/Programming & Language/웹 애플리케이션의 3계층 구조.md	
+++ /dev/null
@@ -1,50 +0,0 @@
----
-id: P-REINFORCE-AUTO-073A5E
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - 웹 애플리케이션의 3계층 구조"
----
-
-# [[웹 애플리케이션의 3계층 구조]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 웹 애플리케이션의 3계층 구조(3-Tier Architecture)는 관심사의 분리(SoC) 원칙에 따라 시스템을 수평적인 층으로 나누어 각각 특정 책임을 부여하는 전통적이고 영향력 있는 소프트웨어 아키텍처 패턴입니다 [1, 2]. 이 구조는 애플리케이션을 사용자 인터페이스를 담당하는 프레젠테이션 계층, 핵심 비즈니스 규칙을 처리하는 비즈니스 로직 계층, 데이터베이스 통신을 관리하는 데이터 액세스 계층으로 엄격히 분리합니다 [2, 3]. 이러한 분리를 통해 개발자는 한 계층의 변경 사항이 다른 계층에 미치는 영향을 최소화하면서 시스템을 보다 모듈화하고 테스트 및 유지보수하기 쉽게 만들 수 있습니다 [1, 4].
-
-## 📖 구조화된 지식 (Synthesized Content)
-웹 애플리케이션을 구성하는 3계층의 구체적인 역할과 성공적인 구축을 위한 구현 원칙은 다음과 같습니다 [2, 3, 5, 6].
-
-*   **프레젠테이션 계층 (Presentation Layer):**
-    *   시스템의 최상단에 위치하며, 사용자 인터페이스(UI)와 렌더링, 사용자 경험(UX)과 관련된 모든 로직을 처리합니다 [2, 3].
-    *   사용자에게 데이터를 표시하고 입력을 캡처하는 역할을 수행하며, 주로 HTML, CSS 및 JavaScript 프레임워크로 구성됩니다 [2, 3].
-    *   이 계층의 구조용 마크업 및 시각적 표현 로직은 데이터 조작이나 비즈니스 규칙과 엄격히 분리되어야 합니다 [6].
-
-*   **비즈니스 로직 계층 (Business Logic Layer / Domain Layer):**
-    *   애플리케이션의 작동 방식을 정의하는 핵심 비즈니스 규칙, 로직 및 워크플로우를 포함하는 중심 계층입니다 [3, 6].
-    *   프레젠테이션 계층으로부터 들어온 명령을 처리하고, 데이터 액세스 계층과의 작업을 오케스트레이션합니다 [3].
-    *   주로 Node.js, Django, Spring과 같은 서버 사이드 스크립트나 백엔드 서비스를 통해 구현되며, 프레젠테이션 계층 및 하위 인프라와는 독립적으로 존재해야 합니다 [2, 6].
-
-*   **데이터 액세스 계층 (Data Access Layer / Persistence Layer):**
-    *   시스템의 최하단에 위치하며, 데이터베이스와 같은 데이터 소스와의 모든 통신 및 CRUD(생성, 읽기, 업데이트, 삭제) 작업을 전담합니다 [2, 3].
-    *   비즈니스 로직을 데이터 스토리지의 세부 구현 사항으로부터 격리하는 역할을 합니다 [3].
-    *   일반적으로 ORM(객체 관계 매핑) 프레임워크 등을 사용하여 저수준의 데이터베이스 상호 작용을 추상화합니다 [6].
-
-*   **구현을 위한 모범 사례 (Actionable Tips):**
-    *   **엄격한 계층 간 통신 제어:** 각 계층은 바로 아래에 있는 계층과만 통신해야 합니다. 예를 들어 프레젠테이션 계층이 데이터 액세스 계층을 직접 호출하지 않게 하여 시스템의 결합도를 낮춰야 합니다 [5].
-    *   **의존성 주입 (Dependency Injection, DI) 활용:** 상위 계층이 하위 계층의 인스턴스를 직접 생성하지 않고 외부에서 의존성을 주입받도록 구현하여, 느슨한 결합을 촉진하고 테스트 가능성을 향상시켜야 합니다 [5].
-    *   **명확한 인터페이스 정의:** 각 계층 간에 명확히 정의된 인터페이스를 생성해야 합니다. 이를 통해 데이터베이스를 변경하더라도 상위 계층의 로직에 영향을 주지 않고 새로운 구현체로 교체할 수 있습니다 [5].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[관심사의 분리 (Separation of Concerns)]], [[의존성 주입 (Dependency Injection)]], [[MVC (Model-View-Controller)]], [[클린 아키텍처 (Clean Architecture)]]
-- **Projects/Contexts:** [[현대 웹 애플리케이션 설계]], [[엔터프라이즈 소프트웨어 개발]]
-- **Contradictions/Notes:** 3계층 구조와 같은 계층화 아키텍처는 명확한 분리를 통해 유지보수성과 확장성을 높여주지만, 초기 개발 시 계층과 추상화를 정의하고 구현해야 하므로 개발 시간이 증가할 수 있으며, 자칫 과도한 엔지니어링(Over-Engineering)으로 인해 시스템 구조가 불필요하게 비대해질 위험도 존재합니다 [7].
-
----
-*Last updated: 2026-04-18*
-- Raw Source: [[00_Raw/2026-04-20/웹 애플리케이션의 3계층 구조.md]]
----
diff --git a/Programming & Language/웹 워커 이벤트 포워딩 Event Forwarding.md b/Programming & Language/웹 워커 이벤트 포워딩 Event Forwarding.md
deleted file mode 100644
index 5ca78e8d..00000000
--- a/Programming & Language/웹 워커 이벤트 포워딩 Event Forwarding.md	
+++ /dev/null
@@ -1,69 +0,0 @@
----
-id: P-REINFORCE-AUTO-7669FA
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - 웹 워커 이벤트 포워딩 Event Forwarding"
----
-
-# [[웹 워커 이벤트 포워딩 Event Forwarding]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 웹 워커(Web Worker)는 DOM API에 직접 접근할 수 없기 때문에, 메인 스레드의 캔버스에서 발생한 마우스 및 터치 이벤트를 캡처하여 필요한 좌표와 상태 데이터만 추출한 뒤 `postMessage`를 통해 워커 스레드로 전달(Forwarding)하여 상호작용을 대리 처리하는 기법입니다.
-
-## 📖 구조화된 지식 (Synthesized Content)
-**1. 이벤트 포워딩의 필요성** OffscreenCanvas 등을 활용해 무거운 렌더링이나 연산을 웹 워커로 분리하면, 워커 내부에서는 DOM이 존재하지 않아 사용자의 이벤트(`mousedown`, `mousemove` 등)를 직접 수신할 수 없습니다. 따라서 메인 스레드에서 사용자의 입력 이벤트를 캡처한 뒤 워커로 전달하는 대리 인터랙션(Proxy Interaction) 시스템을 구축해야 합니다.
-
-**2. 데이터 직렬화 및 필수 속성 추출** 브라우저의 원본 DOM 이벤트 객체 자체는 내부적으로 다양한 DOM 노드 참조 및 메서드를 포함하고 있어 `postMessage`로 전달 시 구조화된 복제(Structured Clone) 알고리즘에 의해 오류가 발생합니다. 따라서 워커에서 상호작용 계산에 필요한 필수 데이터(예: `clientX`, `clientY`, `type`, `button` 등)만 추출하여 가벼운 일반 객체 페이로드로 재구성한 뒤 전송해야 합니다.
-
-**3. 메인 스레드 구현 방식 (이벤트 캡처 및 전송)** 메인 스레드에서는 추적할 이벤트 이름들을 배열로 정의한 뒤, 캔버스 요소에 이벤트 리스너를 달아 워커로 메시지를 포워딩합니다.
-
-```
-// 메인 스레드 측
-const events = ['mousedown', 'mouseup', 'mousemove', 'touchstart', 'touchend', 'touchmove'];
-events.forEach((eventName) => {
-  canvas.addEventListener(eventName, (event) => {
-    worker.postMessage({
-      eventName,
-      event: {
-        clientX: event.clientX,
-        clientY: event.clientY,
-        type: event.type,
-        button: event.button
-      }
-    });
-  });
-});
-```
-
-또한 더 원활한 상호작용(Interop)을 보장하기 위해 클릭, 컨텍스트 메뉴 같은 비수동적(non-passive) 이벤트에 대해 `preventDefault()`를 호출하거나, 포인터 이벤트의 캡처 및 해제(`pointerdown` 시 캡처, `pointerup` 시 해제)를 관리해 스크롤 등 기본 동작과 충돌하지 않도록 처리하는 것이 좋습니다.
-
-**4. 워커 스레드 구현 방식 (수신 및 엔진 연결)** 워커 내부에서는 `onmessage` 핸들러를 통해 전달받은 이벤트를 분석하고, 3D 씬의 상호작용(예: Three.js의 Raycasting)이나 2D 캔버스 엔진의 처리 로직으로 연결합니다.
-
-```
-// 워커 스레드 측
-self.onmessage = function (evt) {
-  if (evt.data.eventName) {
-    // 전달받은 이벤트명과 좌표 데이터를 바탕으로 엔진 내부의 이벤트 시스템 호출
-    // (필요 시 mouse 이벤트를 pointer 이벤트로 치환하여 통합 처리)
-    const event = evt.data.eventName.replace('mouse', 'pointer');
-    stage['_' + event](evt.data.event);
-  }
-};
-```
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[OffscreenCanvas]], [[Web Worker postMessage 동기화]], [[대리 인터랙션 (Proxy Interaction)]], [[Raycasting을 통한 3D 객체 선택]]
-- **Projects/Contexts:** [[Konva의 Offscreen Canvas 및 이벤트 포워딩 구현]], [[react-three-offscreen 기반 DOM 이벤트 패치]]
-- **Contradictions/Notes:** 이벤트 포워딩 방식은 메인 스레드와 워커 간의 통신이므로 직렬화 및 메시지 패싱에 따른 지연(약간의 오버헤드)이 발생합니다. 마우스나 터치 이벤트 발생 빈도 정도는 일반적으로 성능 저하를 일으키지 않으나, 과도하게 많은 이벤트 데이터(예: 수천 번의 `mousemove`)가 발생할 경우 스로틀링(Throttling) 기법을 함께 적용하여 메시지 큐의 병목을 막는 것이 안전합니다.
-
----
-
-_Last updated: 2026-04-14_
-- Raw Source: [[00_Raw/2026-04-20/웹 워커 이벤트 포워딩 Event Forwarding.md]]
----
diff --git a/Programming & Language/웹 워커 이벤트 포워딩 통신 지연 최소화 방법.md b/Programming & Language/웹 워커 이벤트 포워딩 통신 지연 최소화 방법.md
deleted file mode 100644
index 3e705596..00000000
--- a/Programming & Language/웹 워커 이벤트 포워딩 통신 지연 최소화 방법.md	
+++ /dev/null
@@ -1,37 +0,0 @@
----
-id: P-REINFORCE-AUTO-A787BF
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - 웹 워커 이벤트 포워딩 통신 지연 최소화 방법"
----
-
-# [[웹 워커 이벤트 포워딩 통신 지연 최소화 방법]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 웹 워커로 이벤트를 포워딩할 때 발생하는 직렬화 및 메시지 패싱 지연을 줄이려면, 이벤트 발생 빈도를 제어(스로틀링)하고 전송하는 페이로드의 크기를 최소화하며, 극한의 성능이 필요할 경우 `SharedArrayBuffer`를 활용해야 합니다.
-
-## 📖 구조화된 지식 (Synthesized Content)
-**1. 이벤트 스로틀링(Throttling) 및 디바운싱(Debouncing) 적용** `mousemove`, `touchmove`, `scroll`과 같은 사용자 이벤트는 아주 짧은 시간 동안 수십~수백 번씩 발생합니다. 이를 매번 `postMessage`로 워커에 전달하면 메시지 큐에 병목(Bottleneck) 현상이 발생하여 성능이 저하됩니다. 따라서 핸들러에 스로틀링(Throttling)이나 디바운싱(Debouncing) 기법을 적용하여 불필요하게 잦은 이벤트 전송을 막고 연산 부하를 제어해야 합니다.
-
-**2. 전송 페이로드 최소화 (필수 데이터만 추출)** 브라우저의 원본 DOM 이벤트 객체를 그대로 워커로 전달하는 것은 구조화된 복제(Structured Clone)를 거쳐야 하므로 비용이 높고 에러를 유발합니다. 따라서 이벤트 객체 전체가 아닌, 상호작용 계산에 반드시 필요한 최소한의 원시 데이터(예: `clientX`, `clientY`, `type`, `button` 등)만 가벼운 일반 객체로 매핑하여 전송해야 직렬화 오버헤드를 크게 줄일 수 있습니다.
-
-**3. 델타(Delta) 동기화 전략** 데이터 통신 비용을 최소화하기 위해 전체 상태나 이벤트를 매번 통째로 넘기는 대신, 변경된 정보(Delta)만 추려내는 방식을 취합니다. Valtio와 같은 프록시(Proxy) 기반 상태 관리 도구나 `BroadcastChannel`을 활용하면, 값이 변한 속성만을 정밀하게 추적하여 워커 스레드로 동기화할 수 있어 통신에 소모되는 비용을 절약할 수 있습니다.
-
-**4. SharedArrayBuffer를 활용한 Zero-Copy 공유 (궁극적 해결책)** `postMessage` 방식의 가장 큰 난관인 데이터 직렬화 및 복사 비용을 완전히 없애야 하는 고성능 실시간 시스템에서는 `SharedArrayBuffer`를 사용합니다. 메인 스레드에서 캡처한 입력 상태나 마우스 좌표를 공유 메모리 영역에 직접 쓰고(Write), 워커 스레드는 이벤트를 기다릴 필요 없이 필요할 때 메모리에서 즉시 읽어옵니다(Read). 이 구조는 통신에 따른 복사 비용이 '0'이 되어 극도로 낮은 지연 시간을 달성할 수 있게 해줍니다.
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[Throttling & Debouncing]], [[postMessage 직렬화 최적화]], [[SharedArrayBuffer (Zero-Copy)]], [[Proxy 상태 동기화 (Valtio)]]
-- **Projects/Contexts:** [[OffscreenCanvas 기반 대리 인터랙션(Proxy Interaction) 구현]], [[고성능 실시간 상호작용 웹 게임 아키텍처]]
-- **Contradictions/Notes:** 스로틀링을 너무 강하게 걸면 메시지 큐의 지연은 줄어들지만, 반대로 워커 스레드에서 렌더링되는 3D 모델이나 화면 조작이 뚝뚝 끊기는(Stuttering) 느낌을 줄 수 있습니다. 따라서 화면 주사율(예: 60FPS 기준 약 16.67ms)에 맞게 적절한 전송 주기를 타협하는 것이 중요합니다.
-
----
-
-_Last updated: 2026-04-14_
-- Raw Source: [[00_Raw/2026-04-20/웹 워커 이벤트 포워딩 통신 지연 최소화 방법.md]]
----
diff --git a/Programming & Language/웹 프론트엔드 성능 최적화.md b/Programming & Language/웹 프론트엔드 성능 최적화.md
deleted file mode 100644
index 746b8fb7..00000000
--- a/Programming & Language/웹 프론트엔드 성능 최적화.md	
+++ /dev/null
@@ -1,37 +0,0 @@
----
-id: P-REINFORCE-AUTO-921FA9
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - 웹 프론트엔드 성능 최적화"
----
-
-# [[웹 프론트엔드 성능 최적화]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 웹 프론트엔드 성능 최적화는 브라우저 내 JavaScript 엔진의 메모리 관리 및 가비지 컬렉션(GC) 효율을 높여 애플리케이션의 지연(Jank)이나 충돌을 방지하는 과정입니다 [1, 2]. 개발자는 메모리 누수 원인을 식별하고 이를 해결하여 렌더링 파이프라인과 메인 스레드 성능을 원활하게 유지해야 합니다 [2, 3]. 이를 위해 Chrome DevTools와 같은 프로파일링 도구를 적극적으로 활용하여 메모리 할당과 객체 보존 상태를 추적할 수 있습니다 [4, 5].
-
-## 📖 구조화된 지식 (Synthesized Content)
-* **메모리 누수 패턴 및 원인 파악**
-  프론트엔드 애플리케이션의 주요 성능 저하 원인은 더 이상 필요 없는 객체가 가비지 컬렉터에 의해 회수되지 못하고 참조가 유지되는 메모리 누수입니다 [3, 6]. 대표적인 누수 패턴으로는 문서에서 제거되었으나 JS 변수에 의해 참조되는 분리된 DOM 노드(Detached DOM nodes), 반복적인 렌더링 주기에서 누적되는 이벤트 리스너, 공유 스코프에 의해 유지되는 클로저, 그리고 대상이 제거되었음에도 연결이 끊기지 않은 타이머(setInterval)와 옵저버 등이 있습니다 [7-9]. 특히 단일 페이지 애플리케이션(SPA)의 라우트 전환은 이전 라우트의 리스너나 전역 상태 참조를 제대로 정리하지 않을 경우 가장 빈번한 누수 원인이 됩니다 [10].
-
-* **Chrome DevTools를 이용한 진단 및 프로파일링**
-  메모리 누수와 성능 병목을 분석하기 위해 Chrome DevTools의 다양한 기능이 사용됩니다 [5]. 'Heap snapshot'을 통해 특정 시점의 전체 메모리 객체 그래프를 캡처할 수 있으며, 3개의 스냅샷을 비교하는 기법(Three-snapshot technique)을 사용하여 1회성 할당을 필터링하고 지속적으로 살아남은 누수 의심 객체를 효과적으로 찾을 수 있습니다 [4, 11]. 또한 'Allocation Timeline'을 활용하여 시간에 따른 할당을 기록하고 스택 트레이스를 분석함으로써, 메모리를 점유하고 있는 객체가 생성된 정확한 코드 위치를 추적할 수 있습니다 [4, 5, 12].
-
-* **가비지 컬렉션(GC) 최적화에 따른 성능 영향**
-  가비지 컬렉션이 과도하게 실행되거나 오래 걸리면 예측할 수 없는 멈춤 현상(Stop-the-world pause)을 일으켜 애니메이션과 같은 인터랙티브 시스템의 사용자 경험을 방해하게 됩니다 [13, 14]. V8 엔진은 대부분의 객체가 생성 직후 쓸모없어진다는 '세대별 가설(Generational hypothesis)'에 기반하여 힙 메모리를 관리합니다 [15, 16]. 최신 V8의 Orinoco 프로젝트는 병렬(Parallel), 점진적(Incremental), 동시(Concurrent) 기술 및 유휴 시간(Idle-time) GC를 도입하여 메인 스레드의 중단 시간을 최소화함으로써 브라우저가 초당 60프레임 렌더링 등의 프론트엔드 성능을 유지할 수 있도록 최적화하고 있습니다 [17-19].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** `[[메모리 누수 (Memory Leaks)]]`, `[[가비지 컬렉션 (Garbage Collection)]]`, `[[V8 엔진 (V8 Engine)]]`, `[[Chrome DevTools]]`, `[[Orinoco]]`
-- **Projects/Contexts:** `[[SPA 라우트 전환 (SPA Route Transitions)]]`, `[[Three-snapshot technique]]`, `[[Allocation Timeline]]`
-- **Contradictions/Notes:** WeakRef나 FinalizationRegistry와 같은 최신 도구들은 메모리 누수를 줄이는 데 도움을 줄 수 있지만, 가비지 컬렉터의 실행이 자체적인 일정에 따라 비결정적(Non-deterministic)으로 동작하므로 애플리케이션의 적절한 수명 주기 관리(Lifecycle management)를 완전히 대체할 수는 없습니다 [9].
-
----
-*Last updated: 2026-04-19*
-- Raw Source: [[00_Raw/2026-04-20/웹 프론트엔드 성능 최적화.md]]
----
diff --git a/Programming & Language/유기적 통합 이론 (Organismic Integration Theory).md b/Programming & Language/유기적 통합 이론 (Organismic Integration Theory).md
deleted file mode 100644
index 16373d9b..00000000
--- a/Programming & Language/유기적 통합 이론 (Organismic Integration Theory).md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-ED2A29
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - 유기적 통합 이론 (Organismic Integration Theory)"
----
-
-# [[유기적 통합 이론 (Organismic Integration Theory)]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/유기적 통합 이론 (Organismic Integration Theory).md]]
----
diff --git a/Programming & Language/유능감 및 자율성 욕구.md b/Programming & Language/유능감 및 자율성 욕구.md
deleted file mode 100644
index c8b2f593..00000000
--- a/Programming & Language/유능감 및 자율성 욕구.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-E8E212
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - 유능감 및 자율성 욕구"
----
-
-# [[유능감 및 자율성 욕구]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/유능감 및 자율성 욕구.md]]
----
diff --git a/Programming & Language/유니언 타입 식별 및 상태 분기 처리.md b/Programming & Language/유니언 타입 식별 및 상태 분기 처리.md
deleted file mode 100644
index 95322eca..00000000
--- a/Programming & Language/유니언 타입 식별 및 상태 분기 처리.md	
+++ /dev/null
@@ -1,40 +0,0 @@
----
-id: P-REINFORCE-AUTO-2547B3
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - 유니언 타입 식별 및 상태 분기 처리"
----
-
-# [[유니언 타입 식별 및 상태 분기 처리]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-- **식별 가능한 유니언의 구조:**
-  식별 가능한 유니언은 여러 타입이 단일 공유 필드(예: `kind`, `type`, `state`)를 가지며, 이 필드가 리터럴 타입으로 지정된 형태를 띱니다 [2-4, 6]. 이 공통 식별자는 TypeScript 컴파일러와 개발자에게 현재 다루고 있는 유니언의 특정 브랜치가 무엇인지 알려주는 라벨 역할을 합니다 [4, 6].
-
-- **상태 분기 처리 및 타입 좁히기 (Narrowing):**
-  공통 속성의 값을 `switch` 문 등을 통해 비교하면, TypeScript는 런타임에 어떤 타입이 사용되고 있는지 파악하고 해당 블록 내에서 객체의 타입을 안전하게 좁혀줍니다 [6, 9]. 이 패턴은 API 응답 처리, Redux 스타일의 리듀서, 다단계 폼, 라우터 상태 관리 및 상태 머신(State Machine)을 모델링할 때 매우 유용하게 쓰입니다 [10-12].
-
-- **완전성 검사 (Exhaustiveness Checking)와 `never` 타입:**
-  유니언 타입을 처리할 때 가장 큰 장점 중 하나는 컴파일러를 통한 완전성 검사입니다 [6, 8]. 만약 유니언에 새로운 타입 변형(Variant)이 추가되었으나 분기문에서 이를 처리하지 않았다면, 컴파일 에러를 발생시켜 버그를 방지합니다 [6, 8]. 이는 주로 모든 케이스가 처리된 후 남은 기본(default) 케이스의 변수를 `never` 타입에 할당하거나, `assertNever` 함수를 사용하여 강제함으로써 구현됩니다 [6, 13, 14]. 최신 문법에서는 `satisfies never` 키워드를 활용해 처리되지 않은 유니언 타입이 있는지를 타입 시스템에서 강제할 수도 있습니다 [15].
-
-- **성능과 대안적 분기 처리:**
-  복잡한 조건부 분기를 처리하기 위해 `ts-pattern`과 같은 패턴 매칭 라이브러리를 사용할 수도 있으나, 이는 내부의 복잡한 타입 추론과 객체 생성으로 인해 자바스크립트의 기본 `if/else`나 `switch` 제어 구조에 비해 연산 속도가 떨어질 수 있습니다 [16, 17]. 따라서 복잡한 분기를 피할 수 있다면 네이티브 제어문이나 IIFE(즉시 실행 함수 표현)와 함께 `satisfies never`를 결합하여 선언적이고 안전하게 코드를 작성하는 것이 성능과 가독성 측면에서 권장됩니다 [15, 18, 19].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[유니언 타입 (Union Types)]], [[타입 좁히기 (Type Narrowing)]], [[완전성 검사 (Exhaustiveness Checking)]], [[never 타입]]
-- **Projects/Contexts:** [[상태 머신 (State Machine) 모델링]], [[Redux 리듀서 패턴]], [[API 응답 데이터 타입 처리]]
-- **Contradictions/Notes:** 소스 [16, 17, 19]는 `ts-pattern` 라이브러리가 복잡한 분기와 패턴 매칭을 간결하게 작성하는 데 유용하다고 소개하지만, 동시에 기본 제어 구조인 `if/else`나 `switch`에 비해 연산 속도가 상당히 느리므로 단순한 분기에서는 과도한 최적화(오버엔지니어링)가 될 수 있으며 네이티브 제어문을 사용하는 것이 더 적합하다고 주장합니다.
-
----
-*Last updated: 2026-04-18*
-- Raw Source: [[00_Raw/2026-04-20/유니언 타입 식별 및 상태 분기 처리.md]]
----
diff --git a/Programming & Language/유니온 타입 (Union Types).md b/Programming & Language/유니온 타입 (Union Types).md
deleted file mode 100644
index cd5b2351..00000000
--- a/Programming & Language/유니온 타입 (Union Types).md	
+++ /dev/null
@@ -1,30 +0,0 @@
----
-id: P-REINFORCE-AUTO-E0FAE7
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - 유니온 타입 (Union Types)"
----
-
-# [[유니온 타입 (Union Types)]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 유니온 타입(Union Types)은 TypeScript에서 값(Value)이 지정된 여러 타입 중 하나일 수 있음을 나타내는 타입 선언 방식이다 [1, 2]. 수직선 기호(`|`)를 사용하여 구성하며, 타입들을 집합(Set)으로 보았을 때 여러 집합의 합집합(Union)에 해당한다 [2, 3]. 변수나 함수의 매개변수가 하나 이상의 유연한 타입을 허용해야 할 때 주로 사용되며, 런타임에 특정한 타입으로 구별하기 위해서는 '타입 좁히기(Type Narrowing)' 과정이 동반되어야 한다 [4-6].
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[식별 가능한 유니온 (Discriminated Unions)]], [[교집합 타입 (Intersection Types)]], [[타입 좁히기 (Type Narrowing)]], [[리터럴 타입 (Literal Types)]]
-- **Projects/Contexts:** [[TypeScript 타입 시스템 (TypeScript Type System)]], [[상태 모델링 (State Modeling)]]
-- **Contradictions/Notes:** TypeScript에서 유니온 타입은 값의 유연성을 제공하지만, 조합된 타입들의 공통 프로퍼티가 아닌 고유 프로퍼티를 타입 좁히기 검증 없이 직접 접근하려고 하면 컴파일 에러가 발생하므로 주의해야 한다 [2, 5].
-
----
-*Last updated: 2026-04-18*
-- Raw Source: [[00_Raw/2026-04-20/유니온 타입 (Union Types).md]]
----
diff --git a/Programming & Language/유니온 타입(Union Types).md b/Programming & Language/유니온 타입(Union Types).md
deleted file mode 100644
index 982b9a39..00000000
--- a/Programming & Language/유니온 타입(Union Types).md	
+++ /dev/null
@@ -1,39 +0,0 @@
----
-id: P-REINFORCE-AUTO-981211
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - 유니온 타입(Union Types)"
----
-
-# [[유니온 타입(Union Types)]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 유니온 타입(Union Types)은 값이 여러 가지 지정된 타입 중 하나일 수 있음을 나타내는 TypeScript의 핵심 타입 기능입니다 [1, 2]. 수직선 기호(`|`)를 사용하여 각 타입을 구분하며(예: `number | string`), 함수 매개변수나 변수가 다양한 형태의 데이터를 수용해야 할 때 유용하게 쓰입니다 [1, 3]. 유니온 타입은 여러 데이터 타입의 가능성을 열어두면서도, `any` 타입을 사용하는 것보다 훨씬 더 엄격한 타입 안정성을 제공합니다 [1].
-
-## 📖 구조화된 지식 (Synthesized Content)
-- **유니온 타입의 기본 동작과 한계**: 
-  유니온 타입으로 선언된 변수는 조합된 타입 중 어느 하나의 값을 가질 수 있는 유연성을 제공합니다 [2]. 그러나 유니온 타입 값의 멤버(속성이나 메서드)에 접근할 때는, 조합된 모든 타입에 공통으로 존재하는 멤버에만 접근할 수 있다는 제약이 있습니다 [1]. 예를 들어 `Bird | Fish` 타입의 경우, 두 타입 모두에 존재하는 공통 멤버만 호출 시 컴파일러에서 에러를 뱉지 않습니다 [1].
-- **타입 좁히기(Type Narrowing)**:
-  공통되지 않은 특정 타입 전용 속성을 안전하게 사용하려면 타입을 좁혀야 합니다 [4, 5]. `typeof`, `instanceof` 연산자, `in` 연산자, 혹은 사용자 정의 타입 가드(Type Guards) 등을 활용하여 런타임 전에 유니온 타입을 특정한 단일 타입으로 좁혀 데이터에 접근할 수 있습니다 [4, 6, 7].
-- **식별 가능한 유니온(Discriminated Unions / Tagged Unions)**:
-  객체 형태의 유니온에서 가장 강력하게 쓰이는 패턴입니다 [8, 9]. 조합된 객체 타입들에 공통된 리터럴 속성(예: `kind`, `type`, `status`)을 식별자(Discriminant)로 추가하여, 서로 다른 데이터 구조를 구분합니다 [10-13]. 이를 통해 `switch`나 `if` 구문에서 제어 흐름 분석을 적용해 타입을 자동으로 좁힐 수 있으며, 불가능하거나 유효하지 않은 상태를 원천적으로 차단합니다 [10, 12, 14, 15].
-- **완전성 검사(Exhaustiveness Checking)**:
-  식별 가능한 유니온을 처리할 때 `never` 타입을 활용해 처리되지 않은 누락 케이스가 없는지 컴파일러가 확인하도록 설정할 수 있습니다 [10, 13, 16-18]. 기존 유니온에 새로운 타입 멤버가 추가되었는데 분기 처리 로직이 업데이트되지 않았다면 즉시 컴파일 에러를 발생시켜, 예기치 않은 버그와 런타임 에러를 방지합니다 [13, 14, 18].
-- **적용 사례와 장점**:
-  유니온 타입은 논리적인 "OR" 관계를 모델링하므로, 단일 데이터가 다양한 폼을 가질 수 있는 API 응답 객체 처리, 라우터 상태 모델링, Redux와 같은 복잡한 상태 관리(Action 및 Reducers) 등에 최적화되어 있습니다 [14, 19-21]. 명시적이고 문서화된 구조를 통해 뛰어난 코드 자동완성과 테스트 편의성을 제공합니다 [22].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[Intersection Types(교집합 타입)]], [[Discriminated Unions(식별 가능한 유니온)]], [[Type Narrowing(타입 좁히기)]], [[never 타입]]
-- **Projects/Contexts:** [[React State Management(리액트 상태 관리)]], [[API Response Handling(API 응답 처리)]], [[Redux Reducers(리덕스 리듀서)]]
-- **Contradictions/Notes:** TypeScript에서 값을 다형적으로 수용할 수 있게 해준다는 점에서는 `any` 타입과 비슷해 보일 수 있으나, `any`는 모든 타입 체킹 제약이 풀려버리는 반면, 유니온 타입은 오직 정의된 타입들 사이에서의 가능성만 허용하기 때문에 코드의 타입 안전성을 강력하게 유지합니다 [1, 23]. 또한 값이 명확히 정해진 세트 중 하나임을 알 수 있는 경우, 별도의 클래스 계층구조나 `any`를 사용하는 것보다 유니온 타입을 사용하는 것이 훨씬 적합합니다 [1, 23, 24].
-
----
-*Last updated: 2026-04-18*
-- Raw Source: [[00_Raw/2026-04-20/유니온 타입(Union Types).md]]
----
diff --git a/Programming & Language/유스케이스 (Use Cases).md b/Programming & Language/유스케이스 (Use Cases).md
deleted file mode 100644
index 3b342d42..00000000
--- a/Programming & Language/유스케이스 (Use Cases).md	
+++ /dev/null
@@ -1,33 +0,0 @@
----
-id: P-REINFORCE-AUTO-FFC5B7
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - 유스케이스 (Use Cases)"
----
-
-# [[유스케이스 (Use Cases)]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 유스케이스(Use Cases)는 자동화된 시스템이 사용되는 방법을 설명하고, 애플리케이션에 특화된(application-specific) 업무 규칙을 포함하는 소프트웨어 아키텍처의 핵심 계층입니다 [1, 2]. 이는 사용자의 입력과 출력 및 처리 단계를 기술하며, 엔티티(Entities)와 상호작용하여 특정 비즈니스 목표를 달성하도록 데이터 흐름을 조율(오케스트레이션)합니다 [1-3]. 또한, 사용자 인터페이스나 데이터베이스와 같은 시스템의 외부 세부 구현 사항에 의존하지 않고 철저히 독립적으로 동작하는 특징이 있습니다 [4, 5].
-
-## 📖 구조화된 지식 (Synthesized Content)
-- **역할 및 정의:** 유스케이스는 자동화된 시스템이 동작하는 방법을 정의하고 제약하는 역할을 수행합니다. 애플리케이션에 특화된 업무 규칙을 캡슐화하여 구현하며, 사용자가 시스템에 제공해야 하는 입력, 보여줄 출력, 그리고 해당 출력을 생성하기 위한 구체적인 처리 단계를 기술합니다 [2, 3].
-- **데이터 흐름 조정 (Orchestration):** 유스케이스는 엔티티(Entities)로 들어오고 나가는 데이터의 흐름을 관리합니다. 엔티티가 지닌 핵심 업무 규칙을 사용하여 유스케이스의 목적을 달성하도록 이끌며, 매크로 수준에서 사용자의 행동을 정렬하고 명령을 실행합니다 [1, 3, 4]. 이 과정에서 유스케이스는 복잡한 형식 없이 단순한 요청 데이터 구조를 입력으로 받아들이고, 단순한 응답 데이터 구조를 출력으로 반환합니다 [5].
-- **외부 요소와의 철저한 독립성:** 유스케이스는 시스템이 사용자에게 어떻게 보여지는지 설명하지 않으며, 데이터가 어떻게 저장되고 들어오는지와 무관합니다 [6]. 즉, HTML이나 SQL 같은 세부 구현 기술을 알 필요도 없고 알아서도 안 되며, 데이터베이스, UI, 프레임워크 등의 외부 요소에서 발생한 변경이 유스케이스 계층에 어떠한 영향도 주어서는 안 됩니다 [3-5].
-- **엔티티(Entities)와의 의존성 관계:** 클린 아키텍처의 의존성 규칙에 따르면, 유스케이스는 엔티티를 참조하고 제어할 수 있지만, 전사적이고 고수준인 엔티티는 자신을 제어하는 유스케이스에 대해 아무것도 알지 못합니다 [6]. 유스케이스는 단일 애플리케이션에 특화되어 입/출력에 더 가깝게 위치하므로 엔티티보다는 상대적으로 저수준의 개념으로 취급됩니다 [5].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[엔티티 (Entities)]], [[클린 아키텍처 (Clean Architecture)]], [[업무 규칙 (Business Rules)]]
-- **Projects/Contexts:** [[소프트웨어 시스템 설계]], [[계층형 아키텍처 기반 애플리케이션 개발]]
-- **Contradictions/Notes:** 제공된 여러 소스(GeeksforGeeks, 42 Coffee Cups, Catsbi's DLog 등) 간에 모순되는 내용은 없으며, 모두 유스케이스가 애플리케이션에 특화된 비즈니스 로직을 담고 있으며 외부 인프라(DB, UI 등)로부터 반드시 격리되어야 한다는 점을 동일하게 주장하고 있습니다 [1, 3, 4].
-
----
-*Last updated: 2026-04-18*
-- Raw Source: [[00_Raw/2026-04-20/유스케이스 (Use Cases).md]]
----
diff --git a/Programming & Language/응집도 (Cohesion).md b/Programming & Language/응집도 (Cohesion).md
deleted file mode 100644
index b7dedead..00000000
--- a/Programming & Language/응집도 (Cohesion).md	
+++ /dev/null
@@ -1,43 +0,0 @@
----
-id: P-REINFORCE-AUTO-2C194C
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - 응집도 (Cohesion)"
----
-
-# [[응집도 (Cohesion)]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 응집도(Cohesion)는 소프트웨어 설계에서 모듈이나 클래스 내의 요소들이 얼마나 밀접하게 관련되어 있고 단일한 목적이나 기능에 집중하고 있는지를 나타내는 척도입니다 [1-3]. 직무의 집합, 세부사항의 수준, 그리고 지역적 유사성의 척도로도 정의됩니다 [4, 5]. 응집도가 높을수록 코드의 가독성과 유지보수성이 향상되며, 반대로 낮을 경우 시스템을 이해하거나 재사용하기 어려워집니다 [3, 6]. 따라서 효과적인 소프트웨어 설계에서는 '**응집도는 높게, 결합도는 낮게**' 유지하는 것이 핵심 원칙입니다 [7, 8].
-
-## 📖 구조화된 지식 (Synthesized Content)
-**응집도의 정의와 중요성**
-응집도는 한 클래스나 모듈 내의 모든 요소들이 얼마나 잘 속해 있는지를 보여주는 척도입니다 [2]. 높은 응집도는 해당 모듈이 단일한 기능이나 역할에 집중하고 있음을 뜻하며, 이는 코드의 명확성, 유지보수성, 재사용성, 테스트 용이성을 크게 향상시킵니다 [3, 6]. 반면, 낮은 응집도를 가진 모듈은 여러 역할을 동시에 수행하게 되어 맥락 없이 코드를 오가야 하는 '스파게티 코드'를 유발하며, 기능 수정 시 예상치 못한 부작용(Side Effect)을 발생시켜 유지보수를 어렵게 만듭니다 [6, 9].
-
-**응집도의 유형**
-응집도는 요소들 간의 관련성 성격과 수준에 따라 6가지 주요 형태로 분류할 수 있습니다 [10].
-*   **기능적 응집 (Functional Cohesion):** 모듈 내 모든 요소가 하나의 명확한 일을 성취하기 위해 완벽히 협력하는 경우로, 가장 이상적인 최고 수준의 응집도입니다 [2, 10].
-*   **순차적 응집 (Sequential Cohesion):** 모듈 내 한 요소의 출력이 곧바로 다른 요소의 입력으로 사용되는 밀접한 구조입니다 [2, 10].
-*   **논리적 응집 (Logical Cohesion):** 입력 검증 작업과 같이 유사한 성격을 가진 여러 작업들을 묶어 한 모듈에서 처리하는 형태입니다 [10].
-*   **시간적 응집 (Temporal Cohesion):** 시스템 시작 시 필요한 여러 초기화 작업들처럼, 특정 시간에 동시에 발생하는 작업들을 한 곳에 모아둔 경우입니다 [10].
-*   **절차적 응집 (Procedural Cohesion):** 특정 순서에 따라 순차적으로 실행되어야 하는 작업들을 한 모듈에 모아둔 상태입니다 [10].
-*   **우발적 응집 (Coincidental Cohesion):** 모듈 내 요소들이 논리적 연관성 없이 우연히 한 곳에 모여 있는 형태로, 가장 낮은 수준의 응집도이며 유지보수가 매우 어렵습니다 [10].
-
-**응집도와 결합도의 관계**
-관심사의 분리(Separation of Concerns)를 성공적으로 적용하기 위해서는 응집력 증가와 결합도 감소라는 두 가지 과정이 반드시 병행되어야 합니다 [3, 5]. 결합도가 다른 모듈에 대한 시스템의 상호 의존도를 의미한다면, 응집도는 모듈 내부의 결속력을 의미합니다 [1, 5]. 공학적으로 우수한 소프트웨어 아키텍처는 같은 역할을 하는 요소들을 가까이 배치하여 **내부 결속력은 극대화(높은 응집도)**하고, **외부 시스템과의 간섭은 최소화(낮은 결합도)**하는 방향을 지향합니다 [5, 7, 11].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[관심사의 분리 (Separation of Concerns)]], [[결합도 (Coupling)]], [[단일 책임 원칙 (Single Responsibility Principle)]]
-- **Projects/Contexts:** [[클린 아키텍처 (Clean Architecture)]], [[마이크로서비스 아키텍처 (MSA)]]
-- **Contradictions/Notes:** 소스 전반에 걸쳐 응집도에 대한 상반된 의견은 존재하지 않으며, 모든 소프트웨어 공학 문헌에서 "응집도는 높이고 결합도는 낮춰야 한다"는 일관된 설계 방향을 옹호하고 있습니다.
-
----
-*Last updated: 2026-04-18*
-- Raw Source: [[00_Raw/2026-04-20/응집도 (Cohesion).md]]
----
diff --git a/Programming & Language/응집도와 결합도 (Cohesion and Coupling).md b/Programming & Language/응집도와 결합도 (Cohesion and Coupling).md
deleted file mode 100644
index 54e3e8c7..00000000
--- a/Programming & Language/응집도와 결합도 (Cohesion and Coupling).md	
+++ /dev/null
@@ -1,46 +0,0 @@
----
-id: P-REINFORCE-AUTO-AECECF
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - 응집도와 결합도 (Cohesion and Coupling)"
----
-
-# [[응집도와 결합도 (Cohesion and Coupling)]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> **응집도(Cohesion)**는 모듈 내부의 요소들이 하나의 명확한 목적을 위해 얼마나 밀접하게 관련되어 있는지를 측정하는 척도이며, **결합도(Coupling)**는 모듈 간의 상호 의존성 정도를 나타내는 척도이다 [1], [2], [3]. "관심사의 분리(SoC)" 원칙을 소프트웨어에 적용하는 핵심 과정은 **결합도를 낮추고(Loose Coupling) 응집도를 높이는(High Cohesion)** 것이다 [4], [5]. 이를 달성함으로써 시스템의 복잡성을 줄이고 가독성, 유지보수성, 테스트 가능성을 비약적으로 향상시킬 수 있다 [6], [7], [8].
-
-## 📖 구조화된 지식 (Synthesized Content)
-**1. 응집도와 결합도의 개념**
-*   **응집도(Cohesion):** 모듈이나 클래스 내의 요소들이 직무의 집합이나 세부사항 측면에서 얼마나 유사하고 단일한 기능에 집중하고 있는지를 의미한다 [4], [2]. 이상적인 형태인 '기능적 응집'부터 순차적, 논리적, 시간적, 절차적, 그리고 가장 낮은 수준인 '우발적 응집'으로 분류할 수 있다 [2].
-*   **결합도(Coupling):** 한 모듈이 시스템의 나머지 부분이나 다른 모듈에 얼마나 의존하는지를 나타낸다 [9], [3]. 가장 강한 형태인 '내용 결합'부터 공통, 외부, 제어, 스탬프, 그리고 가장 이상적이고 약한 형태인 '자료 결합' 순으로 나뉜다 [3].
-
-**2. 관심사의 분리(SoC)와의 관계**
-*   관심사의 분리가 성공적으로 이루어졌는지를 판단하는 **정량적, 정성적 핵심 척도**가 바로 응집도와 결합도이다 [1].
-*   내부의 결속력(상호작용)은 극대화하고 외부의 간섭은 최소화하는 것이 관심사 분리의 공학적 지향점이다 [10]. 이를 수학적 비유로 표현하면, 설계 품질은 모듈 내부의 상호작용 총합을 모듈 외부와의 상호작용 총합으로 나눈 값에 비례한다 [10].
-*   만약 코드의 알고리즘 논리를 파악할 때 여러 기능이나 모듈 사이를 빈번하게 뛰어다니며 확인해야 한다면, 이는 응집도가 낮다는 신호이며 흔히 **'스파게티 코드(Spaghetti code)'**라 불리는 관리 불능 상태를 낳게 된다 [11], [12], [1].
-
-**3. 높은 응집도와 낮은 결합도의 주요 이점**
-*   **가독성 및 유지보수성 향상:** 각 모듈이 명확한 API와 단일 책임을 갖게 되어 프로그램의 동작을 파악하기 쉬워진다 [6], [7]. 또한 특정 기능을 수정할 때 다른 모듈에 미치는 영향이 국소화되어 부작용 발생을 막을 수 있다 [12], [7], [8].
-*   **재사용성 극대화(DRY 원칙):** 특정 역할에 대해 타 모듈과 독립된 코드는 현재 시스템뿐만 아니라 다른 프로젝트에서도 쉽게 재사용할 수 있어 전체적인 개발 비용을 절감한다 [6], [7], [8].
-*   **테스트 용이성 확보:** 모듈이 다른 모듈에 거의 의존하지 않으므로, 전체 애플리케이션 환경을 구동할 필요 없이 가짜 데이터(Mock, 페이크 등)로 외부 환경을 대체하여 격리된 독립 테스트(단위 테스트)가 가능해진다 [6], [12], [7], [8].
-*   **동시 개발의 효율성 향상:** 역할과 경계가 명확하게 분리되면, 여러 엔지니어가 서로의 코드에 간섭하지 않고 독립적으로 병렬 개발을 진행할 수 있다 [6], [12].
-
-**4. 결합도를 낮추기 위한 전략**
-*   모듈 간 상호작용을 추상화된 **인터페이스**를 통해 정의하거나, 필요한 객체를 외부에서 주입받는 **의존성 주입(Dependency Injection)**, 직접 호출 대신 간접적으로 통신하는 **이벤트 기반 아키텍처**를 활용하면 결합도를 효과적으로 줄일 수 있다 [10], [13]. 또한 내부 구현을 캡슐화하고 데이터 구조를 단순화하는 것 역시 의존성을 낮추는 주요 전략이다 [13].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[단일 책임 원칙 (SRP)]], [[의존성 주입 (Dependency Injection)]], [[스파게티 코드 (Spaghetti Code)]]
-- **Projects/Contexts:** [[계층화 아키텍처 (Layered Architecture)]], [[마이크로서비스 아키텍처 (MSA)]]
-- **Contradictions/Notes:** 세밀한 관심사 분리를 통한 결합도 감소와 응집도 증가가 항상 긍정적인 결과만을 가져오는 것은 아닙니다. 과도하게 세밀한 수준으로 모듈을 쪼개고 분리하면, 복잡한 인디렉션(Indirection)이나 잦은 계층 간 데이터 변환 및 통신 비용 증가 등으로 인해 성능 오버헤드가 발생하거나 오히려 전체 시스템의 추적 가능성을 떨어뜨릴 수 있습니다 [14], [15], [16].
-
----
-*Last updated: 2026-04-18*
-- Raw Source: [[00_Raw/2026-04-20/응집도와 결합도 (Cohesion and Coupling).md]]
----
diff --git a/Programming & Language/응집도와 결합도.md b/Programming & Language/응집도와 결합도.md
deleted file mode 100644
index 9e65493e..00000000
--- a/Programming & Language/응집도와 결합도.md	
+++ /dev/null
@@ -1,42 +0,0 @@
----
-id: P-REINFORCE-AUTO-6D470D
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - 응집도와 결합도"
----
-
-# [[응집도와 결합도]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> **응집도(Cohesion)**와 **결합도(Coupling)**는 소프트웨어 모듈과 컴포넌트가 얼마나 잘 설계되었는지를 평가하는 핵심적인 척도입니다 [1]. 응집도는 모듈 내부의 요소들이 하나의 명확한 목적을 위해 얼마나 밀접하게 관련되어 있는지를 나타내며, 결합도는 모듈 간의 상호 의존성 정도를 의미합니다 [2-4]. 성공적인 소프트웨어 설계와 관심사의 분리(SoC)를 효과적으로 적용하기 위해서는 **'높은 응집도'**와 **'낮은 결합도'**를 지향해야 합니다 [1, 2].
-
-## 📖 구조화된 지식 (Synthesized Content)
-**1. 응집도 (Cohesion)**
-*   **개념:** 모듈이나 클래스 내의 요소들이 얼마나 밀접하게 관련되어 있는지를 보여주는 척도입니다 [3]. 응집도가 높다는 것은 해당 모듈이 단일한 기능이나 역할에 집중하고 있음을 의미합니다 [3].
-*   **유형:** 응집도는 수준에 따라 **기능적 응집**(가장 이상적인 형태), 순차적 응집, 논리적 응집, 시간적 응집, 절차적 응집, 그리고 전혀 관련 없는 요소들이 모인 **우발적 응집**(가장 낮은 수준)으로 분류됩니다 [3].
-*   **높은 응집도의 장점:** 모듈 내의 코드가 같은 목표를 위해 존재하므로 **가독성이 향상**되고, 특정 기능을 수정할 때 코드의 다른 부분에 영향을 주지 않아 **유지보수성과 재사용성이 증가**합니다 [5]. 또한, 명확한 책임 덕분에 **독립적인 테스트가 용이**해집니다 [5]. 
-
-**2. 결합도 (Coupling)**
-*   **개념:** 모듈 간의 의존성 정도를 나타냅니다 [4]. 결합도가 낮으면 각 모듈이 독립적으로 동작할 수 있지만, 높을 경우 한 모듈의 변경이 다른 모듈에 영향을 미치게 됩니다 [4].
-*   **유형:** 결합도는 단순한 데이터 값만 전달하는 **자료 결합**(가장 낮음)부터 스탬프 결합, 제어 결합, 외부 결합, 공통 결합, 그리고 내부 내용을 직접 참조하거나 수정하는 **내용 결합**(가장 강하고 바람직하지 않음)으로 나뉩니다 [4].
-*   **결합도를 낮추기 위한 전략:** 모듈 간 결합도를 줄이려면 **인터페이스 사용**, 외부에서 의존성을 주입받는 **의존성 주입(Dependency Injection)**, 간접적으로 상호작용하는 **이벤트 기반 아키텍처**, **데이터 구조의 단순화** 및 **캡슐화** 기법을 적용할 수 있습니다 [6].
-
-**3. 설계 원칙과의 상호작용**
-*   소프트웨어 개발의 근본 원칙인 **관심사의 분리(SoC)**를 적용하는 과정은 결국 **결합을 감소시키고 응집력을 증가시키는 것**을 목표로 합니다 [7, 8]. 
-*   느슨한 결합과 높은 응집도를 유지하면 코드의 명확성과 재사용성이 높아지고, 여러 명의 엔지니어가 서로 방해받지 않고 작업할 수 있어 **동시(병렬) 개발의 효율성이 크게 향상**됩니다 [9-12].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[관심사의 분리(Separation of Concerns)]], [[단일 책임 원칙(SRP)]], [[의존성 주입(Dependency Injection)]], [[객체 지향 설계]]
-- **Projects/Contexts:** [[모듈화 및 컴포넌트 기반 소프트웨어 개발]], [[마이크로서비스 아키텍처(MSA)]]
-- **Contradictions/Notes:** 높은 응집도와 낮은 결합도를 달성하기 위해 관심사를 분리하는 것은 유지보수성을 높이는 훌륭한 접근이지만, 지나치게 세분화된 관심사 분리(미세한 결합도 낮추기 시도)는 종종 불필요한 계층과 함수 호출, 복잡성을 증가시켜 성능 저하나 인지적 오버헤드를 유발할 수 있으므로 상황에 맞는 적절한 균형이 필요합니다 [13-15].
-
----
-*Last updated: 2026-04-18*
-- Raw Source: [[00_Raw/2026-04-20/응집도와 결합도.md]]
----
diff --git a/Programming & Language/의사결정 속도(Decision Speed).md b/Programming & Language/의사결정 속도(Decision Speed).md
deleted file mode 100644
index f1805a71..00000000
--- a/Programming & Language/의사결정 속도(Decision Speed).md	
+++ /dev/null
@@ -1,35 +0,0 @@
----
-id: P-REINFORCE-AUTO-D12B88
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - 의사결정 속도(Decision Speed)"
----
-
-# [[의사결정 속도(Decision Speed)]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-- **의사결정 속도의 정의와 측정 방식:** 
-  인지 기능 평가에 사용되는 5선택 반응 시간 과제(CANTAB 5-choice RTI) 등에서 의사결정 속도는 목표 자극(target stimulus)이 나타난 순간부터 참가자가 초기 대기 버튼에서 손을 떼기까지 걸린 시간의 중앙값(median duration)으로 정의됩니다 [1]. 이는 실제 동작을 수행하는 데 걸리는 시간과 분리하여, 순수하게 어떤 반응을 할지 결정하는 인지적 판단 시간(decision time)을 측정합니다 [1, 3].
-- **VR 환경 노출이 의사결정 속도에 미치는 영향:** 
-  가상현실 엑서게임(예: Beat Saber)이 인지 능력에 미치는 사후 영향(aftereffects)을 분석한 연구에 따르면, VR 게임 직후나 일정 시간이 지난 후 측정한 의사결정 속도는 게임 전의 기준선(baseline) 측정치와 통계적으로 유의미한 차이를 보이지 않았습니다 [3, 4]. 일부 측정에서 약간 더 느려진 반응이 나타나기도 했으나, 결과적으로 VR 몰입이 자극에 빠르게 반응하고 의사결정을 내리는 능력에 뚜렷한 저하를 일으키지는 않는 것으로 확인되었습니다 [3, 4].
-- **고압(High-stakes) 및 다중 작업 환경에서의 중요성:** 
-  경쟁적인 e스포츠 환경에서 성공하기 위해서는 고도의 집중력과 함께 빠르고 정확한 의사결정 능력이 필수적입니다 [2]. 이처럼 빠른 의사결정이 요구되는 e스포츠 선수를 대상으로 개발된 인지 피로도(Cognitive Fatigue) 및 작업 부하 모델은, 항공 교통 관제나 로봇 수술과 같이 신속한 의사결정과 지속적인 주의력이 결정적인 다른 산업 분야로도 응용될 수 있습니다 [5].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[반응 시간(Reaction Time)]], [[인지 부하(Cognitive Load)]]
-- **Projects/Contexts:** [[가상현실 엑서게임 사후 영향 연구(VR Exergaming Aftereffects)]], [[e스포츠 인지 상태 평가(eSports Cognitive State Assessment)]]
-- **Contradictions/Notes:** 주어진 소스 내에서 의사결정 속도(Decision Speed)는 주로 VR 엑서게임 실험의 하위 측정 지표 및 e스포츠의 요구 역량으로만 다뤄지고 있어, 개념의 이론적 배경이나 심층적인 작동 원리에 대한 소스에 관련 정보가 부족합니다.
-
----
-*Last updated: 2026-04-19*
-- Raw Source: [[00_Raw/2026-04-20/의사결정 속도(Decision Speed).md]]
----
diff --git a/Programming & Language/의존성 역전 (Dependency Inversion).md b/Programming & Language/의존성 역전 (Dependency Inversion).md
deleted file mode 100644
index 465bdde8..00000000
--- a/Programming & Language/의존성 역전 (Dependency Inversion).md	
+++ /dev/null
@@ -1,33 +0,0 @@
----
-id: P-REINFORCE-AUTO-E2B9C7
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - 의존성 역전 (Dependency Inversion)"
----
-
-# [[의존성 역전 (Dependency Inversion)]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 의존성 역전(Dependency Inversion)은 고수준 모듈이 저수준 모듈에 의존하지 않도록 두 모듈 모두 추상화(인터페이스 등)에 의존하게 만드는 소프트웨어 설계 원칙이다 [1, 2]. 이는 세부 사항이 추상화에 의존하게 만듦으로써 시스템 구성 요소 간의 결합도를 낮추고 모듈성과 유연성을 극대화한다 [2].
-
-## 📖 구조화된 지식 (Synthesized Content)
-* **핵심 개념 및 목적:** 의존성 역전 원칙(DIP)은 고수준 모듈(예: 핵심 비즈니스 로직, 뇌)과 저수준 모듈(예: 외부 프레임워크, 데이터베이스, 팔다리) 간의 의존성을 분리하기 위해 추상화를 도입하는 원칙이다 [1, 2]. 추상화가 세부 사항에 의존하는 것이 아니라, 세부 사항이 추상화에 의존하도록 만들어 두 주체 혹은 상하위 모듈 간의 종속성을 제한하고 시스템 변화에 유연하게 대응할 수 있도록 한다 [2].
-* **구현 방식 (인터페이스와 다형성):** 시스템을 구현할 때 구현체보다 컴포넌트가 수행해야 할 인터페이스(포트)를 먼저 정의하고, 외부 계층에서 구체적인 구현(어댑터)을 제공하도록 설계한다 [3, 4]. 특히 객체 지향 언어에서는 인터페이스와 상속 관계를 적절히 배치하여, 제어 흐름이 아키텍처 경계를 횡단하는 지점에서 소스 코드 의존성의 방향을 제어 흐름과 반대로 역전시킬 수 있다 [5]. 이러한 동적 다형성을 활용하면 제어 흐름의 방향과 무관하게 아키텍처의 의존성 규칙을 준수할 수 있다 [5].
-* **"뇌와 팔다리의 분리"와의 관계:** 고수준의 순수한 도메인(뇌)을 저수준의 인프라(팔다리)로부터 분리하고 보호하기 위해, 인터페이스나 추상 클래스와 같은 '신경계' 요소들이 의존성 역전의 도구로써 활용된다 [6]. 예를 들어, 고수준 개념인 엔티티(Entity)가 자신을 제어하는 저수준 개념인 유스케이스(Use Case)에 대해 아무것도 알지 못하도록 설계하는 것이 의존성 역전 원칙을 준수하는 명확한 예시이다 [7].
-* **의존성 주입(DI)과의 연계:** 의존성 역전을 실무에 적용하기 위해 런타임에 구성 요소를 연결해주는 의존성 주입(Dependency Injection, DI) 기법과 프레임워크(예: Spring, ASP.NET Core)가 흔히 활용된다 [1, 3, 4]. 이를 통해 핵심 비즈니스 로직을 특정 도구나 프레임워크로부터 완전히 분리된 상태로 유지할 수 있다 [4].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[SOLID 원칙 (SOLID Principles)]], [[관심사의 분리 (Separation of Concerns)]], [[의존성 주입 (Dependency Injection)]], [[인터페이스 (Interfaces)]]
-- **Projects/Contexts:** [[클린 아키텍처 (Clean Architecture)]], [[객체 지향 프로그래밍 (OOP)]]
-- **Contradictions/Notes:** 의존성 역전은 시스템의 분리와 모듈성을 극대화하지만, 아키텍처 경계를 더 단순하게 구현하기 위해 퍼사드(Facade) 패턴과 같은 부분적 경계를 채택할 경우에는 의존성 역전의 이점이 일부 희생될 수 있다 [8]. 
-
----
-*Last updated: 2026-04-18*
-- Raw Source: [[00_Raw/2026-04-20/의존성 역전 (Dependency Inversion).md]]
----
diff --git a/Programming & Language/의존성 역전 원칙 (DIP).md b/Programming & Language/의존성 역전 원칙 (DIP).md
deleted file mode 100644
index 3665659e..00000000
--- a/Programming & Language/의존성 역전 원칙 (DIP).md	
+++ /dev/null
@@ -1,37 +0,0 @@
----
-id: P-REINFORCE-AUTO-8D5E45
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - 의존성 역전 원칙 (DIP)"
----
-
-# [[의존성 역전 원칙 (DIP)]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 의존성 역전 원칙(DIP, Dependency Inversion Principle)은 객체 지향 프로그래밍의 SOLID 설계 원칙 중 하나로, 상위 수준의 모듈이 하위 수준의 모듈에 의존해서는 안 되며 양쪽 모두 추상화(예: 인터페이스)에 의존해야 한다는 원칙이다 [1, 2]. 이 원칙은 추상화가 세부 사항에 의존하는 것이 아니라, 세부 사항이 추상화에 의존해야 함을 강조한다 [2]. 이를 통해 시스템 구성 요소 간의 결합도를 낮추고 모듈성을 증가시켜, 유연성과 테스트 가능성을 크게 향상시킨다 [2, 3].
-
-## 📖 구조화된 지식 (Synthesized Content)
-* **원칙의 핵심 개념 및 목적**
-  의존성 역전 원칙(DIP)은 상위 모듈과 하위 모듈 간의 직접적인 의존성을 제한하기 위해 추상화를 제시하는 역할을 한다 [2]. 상위 수준의 모듈은 시스템의 핵심 비즈니스 로직이나 정책을 담고 있으므로, 쉽게 변할 수 있는 하위 수준의 구체적인 세부 사항이나 도구에 의존해서는 안 된다 [1, 2]. 이 원칙을 준수하면 시스템이 유연성을 확보하여 향후 변경 사항에 맞춰 쉽게 수정될 수 있다 [2].
-
-* **구현 방법 및 의존성 주입(DI)**
-  DIP를 실무에 구현하기 위해 가장 흔히 사용되는 방법은 '의존성 주입(Dependency Injection, DI)'이다 [1]. Java의 Spring 프레임워크나 ASP.NET Core와 같은 내장 DI 컨테이너를 활용하면 컴포넌트를 쉽게 분리(Decoupling)하고 의존성 역전을 구현할 수 있다 [4]. 또한 구현 코드를 작성하기 전에 컴포넌트가 수행해야 할 역할(인터페이스)을 먼저 설계하는 접근법은 DIP와 개방-폐쇄 원칙(OCP)을 자연스럽게 지원한다 [4]. 
-
-* **아키텍처 경계와 제어 흐름의 제어**
-  시스템 아키텍처에서 제어 흐름과 소스 코드의 의존성 방향이 반대인 경우, DIP를 사용하여 이를 해결할 수 있다 [5]. 예를 들어, 전략 패턴(Strategy Pattern)은 클라이언트를 구현체로부터 격리시키는 데 필요한 의존성 역전을 성공적으로 적용하는 구조다 [6]. 반면, 단순히 진입점만 제공하는 퍼사드(Facade) 패턴으로 경계를 만들 경우 이러한 의존성 역전의 이점을 희생하게 될 수 있다 [7]. 객체 지향 언어인 자바에서는 인터페이스와 상속 관계를 적절히 배치함으로써, 제어 흐름이 시스템 경계를 가로지르는 지점에서 소스 코드의 의존성을 제어 흐름의 반대 방향으로 역전시킬 수 있다 [5].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[SOLID 원칙]], [[의존성 주입 (DI)]], [[추상화]], [[객체 지향 프로그래밍 (OOP)]]
-- **Projects/Contexts:** [[클린 아키텍처]], [[소프트웨어 아키텍처 설계]]
-- **Contradictions/Notes:** 관심사 분리(SoC) 원칙은 기능을 기반으로 코드를 어떻게 구성하고 나눌 것인지에 초점을 맞추는 반면, 의존성 역전 원칙(DIP)은 상위 모듈과 하위 모듈 간의 결합을 분리(decoupling)하여 시스템의 유연성과 테스트 가능성을 향상시키는 데 목적을 둔다는 점에서 두 원칙의 초점이 구분된다 [3].
-
----
-*Last updated: 2026-04-18*
-- Raw Source: [[00_Raw/2026-04-20/의존성 역전 원칙 (DIP).md]]
----
diff --git a/Programming & Language/의존성 역전 원칙 (Dependency Inversion Principle DIP).md b/Programming & Language/의존성 역전 원칙 (Dependency Inversion Principle DIP).md
deleted file mode 100644
index 9c77f96d..00000000
--- a/Programming & Language/의존성 역전 원칙 (Dependency Inversion Principle DIP).md	
+++ /dev/null
@@ -1,35 +0,0 @@
----
-id: P-REINFORCE-AUTO-9D4394
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - 의존성 역전 원칙 (Dependency Inversion Principle DIP)"
----
-
-# [[의존성 역전 원칙 (Dependency Inversion Principle DIP)]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 의존성 역전 원칙(DIP)은 객체 지향 프로그래밍 및 소프트웨어 설계의 핵심인 SOLID 원칙 중 하나입니다 [1, 2]. 이 원칙은 상위 수준의 모듈이 하위 수준의 모듈에 의존해서는 안 되며, 양쪽 모두 추상화(예: 인터페이스)에 의존해야 한다고 규정합니다 [3, 4]. 즉, 세부 사항이 추상화에 의존해야 한다는 원칙으로, 이를 통해 모듈 간의 결합도를 낮추고 시스템의 유연성과 테스트 가능성을 크게 향상시킵니다 [4, 5].
-
-## 📖 구조화된 지식 (Synthesized Content)
-- **핵심 개념 및 목적:** DIP는 로버트 C. 마틴(Robert C. Martin, Uncle Bob)에 의해 도입된 원칙으로, 구체적인 구현(concrete implementations) 대신 추상화에 의존하게 함으로써 컴포넌트 간의 느슨한 결합(loose coupling)을 촉진합니다 [2, 4, 5]. 상하위 모듈 간의 의존성을 추상화로 제한하여 시스템 모듈성을 높이고 변화에 쉽게 적응할 수 있도록 돕습니다 [4].
-- **의존성과 제어 흐름의 역전:** 시스템 설계 시 제어 흐름과 소스 코드 의존성의 방향이 반대일 때 DIP를 통해 이를 해결할 수 있습니다 [6]. 예를 들어, Java에서는 인터페이스와 상속 관계를 적절히 배치함으로써, 제어 흐름이 아키텍처 경계를 가로지르는 지점에서 소스 코드 의존성을 제어 흐름과 정반대의 방향으로 역전시킬 수 있습니다 [6, 7]. 
-- **구현 방법:** 
-  - **의존성 주입(Dependency Injection, DI):** DIP는 종종 의존성 주입을 통해 구현됩니다 [3]. Spring(Java)이나 ASP.NET Core와 같은 프레임워크에 내장된 DI 컨테이너를 사용하면 컴포넌트 간 결합을 분리하고 DIP를 더 쉽게 적용할 수 있습니다 [8].
-  - **인터페이스 우선 설계:** 구현 코드(어떻게 수행할 것인가)를 작성하기 전에 컴포넌트의 역할(인터페이스)을 먼저 정의하는 방식은 DIP의 철학을 자연스럽게 지원합니다 [8].
-- **관심사 분리(SoC)와의 비교:** 관심사 분리(SoC)가 기능을 기반으로 코드를 구성하는 데 초점을 맞추는 반면, DIP는 유연성과 테스트 가능성을 향상시키기 위해 상위 모듈과 하위 모듈 간의 결합을 끊어내는(decoupling) 데 초점을 맞춘다는 명확한 차이가 있습니다 [5, 9].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[SOLID 원칙]], [[의존성 주입(Dependency Injection)]], [[인터페이스(Interfaces)]], [[관심사 분리(Separation of Concerns, SoC)]]
-- **Projects/Contexts:** [[객체 지향 프로그래밍(OOP)]], [[소프트웨어 아키텍처(Software Architecture)]], [[클린 아키텍처(Clean Architecture)]]
-- **Contradictions/Notes:** 관심사 분리(SoC)와 의존성 역전 원칙(DIP)은 서로를 보완하는 설계 원칙이나 초점이 다릅니다. SoC는 관심사에 따른 코드의 구성과 격리에 집중하는 반면, DIP는 계층 간(상하위 모듈 간)의 디커플링에 목적을 둡니다 [9]. 또한, 퍼사드 패턴(Facade Pattern)과 같이 단순화된 경계를 구축하는 상황에서는 때에 따라 의존성 역전(DIP)의 이점이 희생될 수도 있습니다 [10].
-
----
-*Last updated: 2026-04-18*
-- Raw Source: [[00_Raw/2026-04-20/의존성 역전 원칙 (Dependency Inversion Principle, DIP).md]]
----
diff --git a/Programming & Language/의존성 역전 원칙 (Dependency Inversion Principle).md b/Programming & Language/의존성 역전 원칙 (Dependency Inversion Principle).md
deleted file mode 100644
index 0e279d2a..00000000
--- a/Programming & Language/의존성 역전 원칙 (Dependency Inversion Principle).md	
+++ /dev/null
@@ -1,39 +0,0 @@
----
-id: P-REINFORCE-AUTO-577066
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - 의존성 역전 원칙 (Dependency Inversion Principle)"
----
-
-# [[의존성 역전 원칙 (Dependency Inversion Principle)]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 의존성 역전 원칙(Dependency Inversion Principle, DIP)은 객체 지향 프로그래밍을 위한 SOLID 설계 원칙 중 하나로, 상위 수준의 모듈이 하위 수준의 모듈에 의존해서는 안 되며 둘 다 추상화에 의존해야 한다는 소프트웨어 설계 원칙이다 [1-3]. 또한 추상화는 세부 구현에 의존해서는 안 되며, 반대로 세부 구현이 추상화에 의존해야 함을 명시한다 [3]. 이 원칙은 구체적인 구현 대신 인터페이스와 같은 추상화에 의존함으로써 시스템 컴포넌트 간의 느슨한 결합을 유도하고 유연성 및 테스트 가능성을 향상시킨다 [4, 5].
-
-## 📖 구조화된 지식 (Synthesized Content)
-*   **핵심 원리와 목적:** 
-    *   고수준 모듈과 저수준 모듈 간의 직접적인 종속성을 제한하기 위해 인터페이스와 같은 추상화 계층을 도입한다 [3].
-    *   상위 모듈과 하위 모듈을 분리(decoupling)하는 데 초점을 맞추어 시스템을 유연하고 테스트하기 쉽게 만든다 [4, 5].
-*   **시스템에 미치는 장점:** 
-    *   추상화에 의존함으로써 컴포넌트 간의 느슨한 결합(loose coupling)을 촉진한다 [5]. 
-    *   시스템의 모듈성을 크게 증가시켜 요구사항 변화에 맞춰 쉽게 코드를 수정하고 확장할 수 있는 유연성을 제공한다 [3, 5].
-*   **구현 및 실천 방안:** 
-    *   이 원칙은 주로 의존성 주입(Dependency Injection, DI) 기법을 통해 구현된다 [2]. 
-    *   Java의 Spring이나 ASP.NET Core에 내장된 DI 컨테이너와 같은 프레임워크를 활용하면 컴포넌트 간의 결합을 분리하여 DIP를 훨씬 쉽게 적용할 수 있다 [6].
-    *   컴포넌트가 어떻게 동작할지(구현)를 코딩하기 전에 무엇을 해야 하는지(인터페이스)를 먼저 정의하는 설계 관행이 DIP(및 OCP)를 자연스럽게 지원한다 [6].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[SOLID 원칙]], [[의존성 주입 (Dependency Injection)]], [[관심사의 분리 (Separation of Concerns)]]
-- **Projects/Contexts:** [[객체 지향 프로그래밍 (Object-Oriented Programming)]], [[클린 아키텍처 (Clean Architecture)]]
-- **Contradictions/Notes:** 소스 내에서 의존성 역전 원칙 자체에 대한 직접적인 반대 의견이나 모순은 발견되지 않는다. 다만, 소프트웨어 설계 원칙 중 [[관심사의 분리 (Separation of Concerns)]]와 비교할 때, SoC는 기능에 따라 코드를 구성하는 것에 초점을 맞추는 반면, DIP는 유연성과 테스트 가능성을 높이기 위해 상위-하위 모듈 간의 결합을 분리하는 데 집중한다는 목적의 차이가 명시되어 있다 [4, 5].
-
----
-*Last updated: 2026-04-18*
-- Raw Source: [[00_Raw/2026-04-20/의존성 역전 원칙 (Dependency Inversion Principle).md]]
----
diff --git a/Programming & Language/의존성 주입 (DI).md b/Programming & Language/의존성 주입 (DI).md
deleted file mode 100644
index ab91006d..00000000
--- a/Programming & Language/의존성 주입 (DI).md	
+++ /dev/null
@@ -1,40 +0,0 @@
----
-id: P-REINFORCE-AUTO-0538AE
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - 의존성 주입 (DI)"
----
-
-# [[의존성 주입 (DI)]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 의존성 주입(DI, Dependency Injection)은 모듈이나 클래스가 필요로 하는 의존성을 내부에서 직접 생성하지 않고 외부에서 제공(주입)받도록 하는 소프트웨어 설계 기법입니다 [1, 2]. 이는 객체 지향 프로그래밍의 주요 원칙인 의존성 역전 원칙(DIP)을 구현하는 대표적인 방법으로 사용됩니다 [3]. 컴포넌트 간의 결합도를 낮추고 모듈성을 높여 시스템의 유지보수성과 테스트 용이성을 크게 향상시키는 것이 주된 목적입니다 [4, 5].
-
-## 📖 구조화된 지식 (Synthesized Content)
-* **작동 원리 및 목적:** 
-의존성 주입은 상위 계층이 하위 계층의 인스턴스를 직접 생성하는 대신, 외부 소스로부터 의존성을 주입받도록 하여 느슨한 결합(Loose Coupling)을 촉진합니다 [1, 2]. 이를 통해 핵심 로직을 변경하지 않고도 종속성을 관리하거나 특정 구현체를 쉽게 교체할 수 있게 해줍니다 [4].
-
-* **설계 원칙과의 관계:** 
-DI는 주로 의존성 역전 원칙(DIP)을 실현하는 수단으로 활용되며, 모듈들이 구체적인 도구가 아닌 추상화(인터페이스)에 의존하도록 구성 요소들을 런타임에 연결합니다 [3, 6]. 또한, 관심사의 분리(SoC)를 달성하여 시스템의 여러 기능이 서로 얽히지 않고 독립적으로 동작하도록 돕는 핵심 전략이기도 합니다 [5, 7, 8].
-
-* **주요 이점:** 
-의존성 주입을 활용하면 모듈 간의 결합도가 낮아져 시스템 부품 간 독립성이 보장되고 재사용률이 높아집니다 [5]. 특히 테스트 용이성이 크게 향상되는데, 모듈이 외부 구현에 얽매이지 않기 때문에 테스트 시 실제 의존성 대신 목(Mock) 객체나 가짜 데이터 소스로 교체하여 다양한 시나리오를 쉽게 시뮬레이션하고 검증할 수 있습니다 [1, 4, 9].
-
-* **아키텍처 및 프레임워크에서의 활용:** 
-계층형 아키텍처나 클린 아키텍처 등에서 계층 간 결합을 끊기 위해 적극적으로 사용됩니다 [1, 6, 7]. Java의 Spring이나 ASP.NET Core와 같은 프레임워크는 내장된 DI 컨테이너를 제공하여 컴포넌트 분리를 수월하게 돕습니다 [10]. 다만 클린 아키텍처의 관점에서는 의존성 주입 프레임워크를 사용하더라도 시스템 전반이 프레임워크에 종속되는 것을 막기 위해, 실제 의존성 주입 작업은 가장 낮은 수준의 정책인 '메인(Main) 컴포넌트'에서 이루어져야 한다고 권장합니다 [11]. 이후에는 DI 프레임워크 없이도 일반적인 방식으로 의존성이 분배되어야 합니다 [11].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[의존성 역전 원칙 (DIP)]], [[관심사의 분리 (SoC)]], [[느슨한 결합 (Loose Coupling)]], [[모듈성 (Modularity)]]
-- **Projects/Contexts:** [[Spring Framework]], [[ASP.NET Core]], [[클린 아키텍처 (Clean Architecture)]], [[계층형 아키텍처 (Layered Architecture)]]
-- **Contradictions/Notes:** 소스에 따르면, 의존성 주입 프레임워크의 편리함에도 불구하고, 시스템이 프레임워크 자체에 강하게 결합되는 것을 피하기 위해 메인(Main) 컴포넌트 내부로 주입 책임을 철저히 제한해야 한다고 지적합니다 [11].
-
----
-*Last updated: 2026-04-18*
-- Raw Source: [[00_Raw/2026-04-20/의존성 주입 (DI).md]]
----
diff --git a/Programming & Language/의존성 주입 (Dependency Injection).md b/Programming & Language/의존성 주입 (Dependency Injection).md
deleted file mode 100644
index 36e59dd3..00000000
--- a/Programming & Language/의존성 주입 (Dependency Injection).md	
+++ /dev/null
@@ -1,38 +0,0 @@
----
-id: P-REINFORCE-AUTO-A38513
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - 의존성 주입 (Dependency Injection)"
----
-
-# [[의존성 주입 (Dependency Injection)]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 의존성 주입(Dependency Injection, DI)은 모듈이 필요로 하는 의존성 객체를 내부에서 직접 생성하지 않고 외부로부터 제공(주입)받도록 설계하는 소프트웨어 패턴입니다 [1, 2]. 이 기법은 시스템 컴포넌트 간의 결합도를 낮추어 코드의 모듈화를 촉진하며 [2, 3], 궁극적으로 애플리케이션의 유지보수성과 테스트 용이성을 크게 향상시키는 데 목적이 있습니다 [3, 4].
-
-## 📖 구조화된 지식 (Synthesized Content)
-- **결합도 감소 및 모듈화 촉진**
-  의존성 주입은 모듈 간 상호작용 시 한 모듈이 다른 모듈의 인스턴스를 직접 생성하지 않고 외부에서 제공받는 방식을 취합니다 [1, 2]. 이러한 방식은 컴포넌트들을 디커플링(decoupling)하여 핵심 로직을 변경하지 않고도 구현체를 교체하거나 의존성을 쉽게 관리할 수 있게 해줍니다 [3].
-- **의존성 역전 원칙(DIP) 구현의 핵심**
-  객체 지향 프로그래밍의 핵심 설계 원칙 중 하나인 '의존성 역전 원칙(Dependency Inversion Principle)'은 상위 모듈이 하위 모듈에 직접 의존하지 않고 둘 다 추상화에 의존해야 함을 명시합니다 [5]. 의존성 주입은 이 원칙을 실제로 구현하는 주된 수단으로 사용되며, Java의 Spring이나 ASP.NET Core와 같은 프레임워크들은 내장된 DI 컨테이너를 통해 의존성 주입을 훨씬 쉽게 구현할 수 있도록 지원합니다 [6].
-- **소프트웨어 아키텍처에서의 활용**
-  - **계층형 아키텍처(Layered Architecture):** 상위 계층이 하위 계층을 직접 인스턴스화하는 대신 외부에서 의존성을 주입받게 하여, 계층 간의 느슨한 결합(loose coupling)을 이끌어냅니다 [1].
-  - **클린 아키텍처(Clean Architecture):** 내부 계층에 정의된 인터페이스(포트)에 대해 외부 계층이 구체적인 구현(어댑터)을 제공합니다. 이때 런타임에 의존성 주입을 사용하여 컴포넌트들을 연결함으로써, 핵심 비즈니스 로직이 특정 프레임워크나 도구에 결합되지 않도록 방지합니다 [7]. 또한 의존성 주입기를 활용해 모든 의존성이 내부를 향하도록 의존성 규칙을 관리할 수 있습니다 [8].
-- **테스트 용이성(Testability) 확보**
-  하드 코딩된 의존성은 구현 세부 사항과 강하게 결합하여 코드를 외부 환경으로부터 고립시켜 단위 테스트를 불가능하게 만들거나 어렵게 합니다 [4, 9]. 따라서 외부 시스템 없이 모듈을 독립적으로 테스트하고, 필요에 따라 목(Mock)과 같은 테스트 더블(Test Double)로 의존성을 대체하기 위해서는 의존성 주입의 사용이 필수적으로 권장됩니다 [4, 10].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[의존성 역전 원칙 (Dependency Inversion Principle)]], [[느슨한 결합 (Loose Coupling)]], [[관심사의 분리 (Separation of Concerns)]], [[테스트 용이성 (Testability)]]
-- **Projects/Contexts:** [[클린 아키텍처 (Clean Architecture)]], [[계층형 아키텍처 (Layered Architecture)]], [[Spring Framework]], [[ASP.NET Core]]
-- **Contradictions/Notes:** 제공된 모든 소스는 의존성 주입이 모듈 간의 결합도를 낮추고 테스트 용이성을 극대화한다는 점에서 일치된 견해를 보이고 있으며, 코드의 설계 단계부터 하드 코딩을 지양하고 의존성 주입을 염두에 둘 것을 공통적으로 강조하고 있습니다 [2, 9].
-
----
-*Last updated: 2026-04-18*
-- Raw Source: [[00_Raw/2026-04-20/의존성 주입 (Dependency Injection).md]]
----
diff --git a/Programming & Language/의존성 주입(DI).md b/Programming & Language/의존성 주입(DI).md
deleted file mode 100644
index 3491abdc..00000000
--- a/Programming & Language/의존성 주입(DI).md	
+++ /dev/null
@@ -1,37 +0,0 @@
----
-id: P-REINFORCE-AUTO-BE99B2
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - 의존성 주입(DI)"
----
-
-# [[의존성 주입(DI)]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 의존성 주입(DI)은 모듈이 필요한 의존 객체를 직접 생성하지 않고 외부로부터 주입(공급)받도록 하는 소프트웨어 설계 기법입니다 [1-3]. 이는 고수준 모듈과 저수준 모듈의 직접적인 결합을 끊어내고 추상화에 의존하게 만드는 '의존성 역전 원칙(DIP)'을 구현하는 데 자주 사용됩니다 [4]. 이를 통해 컴포넌트 간의 결합도를 낮추고 시스템의 테스트 용이성과 유지보수성을 크게 향상시킬 수 있습니다 [3, 5].
-
-## 📖 구조화된 지식 (Synthesized Content)
-- **개념과 동작 방식:** 의존성 주입은 상위 모듈이나 계층이 하위 계층의 인스턴스를 직접 생성하는 대신, 외부 소스(또는 의존성 주입기)로부터 해당 의존성을 전달받는 방식입니다 [1, 6]. 이 방식을 통해 내부의 코어 로직을 특정 도구나 구체적인 구현체로부터 분리(Decouple)하고, 런타임 환경에서 컴포넌트들을 유연하게 연결할 수 있습니다 [7].
-- **주요 이점:**
-  - **결합도 감소(Loose Coupling):** 컴포넌트 간의 디커플링을 유도하여 느슨한 결합을 촉진합니다 [1, 5]. 한 모듈이 다른 모듈을 직접 생성하지 않고 외부에서 제공받기 때문에, 의존성이 최소화되고 시스템 변경이 용이해집니다 [3].
-  - **테스트 용이성 향상:** 의존성을 주입받는 구조는 테스트 시 실제 구현체 대신 모의 객체(Mock dependencies)로 쉽게 대체할 수 있게 해줍니다 [8]. 예를 들어, Google의 기계학습(ML) 시스템은 데이터 소스나 모델 백엔드 등을 외부에서 주입하도록 하여, 다양한 시나리오를 시뮬레이션하고 독립적으로 테스트할 수 있도록 설계되었습니다 [8].
-  - **유지보수성 강화:** 핵심 로직을 변경하지 않고도 구현체를 손쉽게 교체하거나 종속성을 관리할 수 있어 전반적인 코드의 유지보수성이 크게 높아집니다 [5].
-- **구현 및 아키텍처 적용:**
-  - Java의 Spring이나 ASP.NET Core와 같이 내장된 DI 컨테이너를 제공하는 프레임워크를 사용하면 컴포넌트 분리 및 의존성 역전 원칙을 훨씬 수월하게 구현할 수 있습니다 [9].
-  - 아키텍처 관점에서, DI 프레임워크를 이용한 실제 의존성 주입 작업은 시스템의 초기 진입점이자 가장 낮은 수준의 정책을 담당하는 '메인(Main) 컴포넌트'에서 일어나는 것이 바람직합니다 [10]. 일단 메인에서 주입이 완료되면, 메인은 DI 프레임워크에 의존하지 않고도 일반적인 방식으로 의존성을 분배할 수 있어야 합니다 [10].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[의존성 역전 원칙(DIP)]], [[결합도(Coupling)]], [[테스트 용이성(Testability)]], [[단일 책임 원칙(SRP)]]
-- **Projects/Contexts:** [[Spring Framework]], [[ASP.NET Core]], [[Google ML 시스템]], [[계층형 아키텍처]], [[클린 아키텍처]]
-- **Contradictions/Notes:** 소스 전반에 걸쳐 의존성 주입은 시스템의 복잡도를 낮추고 모듈성을 높이는 긍정적인 기법으로 일관되게 권장되고 있으며, 상충하는 주장은 존재하지 않습니다. 다만 클린 아키텍처와 같은 구조에서는 의존성이 외부에서 내부로(저수준에서 고수준으로) 향하도록 의존성 규칙을 철저히 관리해야 한다고 강조합니다 [6, 10].
-
----
-*Last updated: 2026-04-18*
-- Raw Source: [[00_Raw/2026-04-20/의존성 주입(DI).md]]
----
diff --git a/Programming & Language/이동 속도(Movement Speed).md b/Programming & Language/이동 속도(Movement Speed).md
deleted file mode 100644
index 25fe6e44..00000000
--- a/Programming & Language/이동 속도(Movement Speed).md	
+++ /dev/null
@@ -1,34 +0,0 @@
----
-id: P-REINFORCE-AUTO-482CBE
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - 이동 속도(Movement Speed)"
----
-
-# [[이동 속도(Movement Speed)]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 이동 속도(Movement Speed)는 사용자의 반응 시간(Reaction time)을 구성하는 두 가지 주요 요소 중 하나로, 의사결정 속도(Decision speed)와 구분되는 개념입니다 [1]. 구체적으로 인지 및 반응 과제에서 시작 버튼에서 손을 뗀 순간부터 목표 자극(Target stimulus)을 터치할 때까지 소요되는 시간의 중간값(Median duration)으로 정의됩니다 [1]. 제공된 소스에서는 가상현실(VR) 엑서게임(Exergame) 플레이 전후에 나타나는 인지적, 운동적 변화를 평가하는 세부 지표로 활용되었습니다 [1, 2].
-
-## 📖 구조화된 지식 (Synthesized Content)
-소스에 관련 정보가 부족합니다. 주어진 문서에서 확인 가능한 이동 속도에 대한 제한적인 내용은 다음과 같습니다.
-
-- **측정 방법 및 목적:** CANTAB 5-선택 반응 시간 과제(5-choice RTI)를 통해 사용자의 반응 속도를 평가할 때, 신체적 움직임 요인과 인지적 요인을 분리하기 위해 이동 속도가 측정됩니다 [1]. 사용자가 하단 버튼을 누르고 있다가 상단에 나타난 목표 자극을 향해 손을 이동시켜 터치하기까지의 시간을 측정하여 이동 속도를 도출합니다 [1].
-- **가상현실(VR) 노출에 따른 이동 속도 변화:** '비트 세이버(Beat Saber)'를 활용한 실험에서 10분 동안 짧게 VR 엑서게임을 플레이한 참가자들은 플레이 직후 측정한 이동 속도가 노출 이전보다 약간 더 빨라진 것으로 나타났습니다 [2].
-- **통계적 유의성 및 단기적 효과:** 전반적인 이동 시간(Movement times) 분석 결과, 측정 시기(Test period)나 VR 노출 시간(Exposure duration)에 따른 주효과(Main effects)나 변수 간의 상호작용은 유의미하지 않았습니다 [3]. 연구진은 10분 플레이 후 관찰된 이동 속도 향상이 유산소 운동 직후 일시적으로 반응 처리 속도가 빨라졌다가 곧 사라지는 기존의 연구 결과와 유사한 단기적 현상일 수 있다고 지적했습니다 [2].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[Reaction Time]], [[Decision Speed]]
-- **Projects/Contexts:** [[VR Exergaming(가상현실 엑서게임) 평가]], [[CANTAB 5-choice RTI(5-선택 반응 시간 과제)]]
-- **Contradictions/Notes:** 소스에 관련 정보가 부족합니다. (짧은 VR 게임(10분) 직후 이동 속도가 일시적으로 향상되는 현상이 관찰되었으나, 통계적으로 측정 시기나 노출 시간에 따른 뚜렷한 주효과는 입증되지 않아 지속적인 효과로 보기는 어렵다는 점이 언급되었습니다 [2, 3].)
-
----
-*Last updated: 2026-04-19*
-- Raw Source: [[00_Raw/2026-04-20/이동 속도(Movement Speed).md]]
----
diff --git a/Programming & Language/이벤트 기반 아키텍처 (Event-Driven Architecture).md b/Programming & Language/이벤트 기반 아키텍처 (Event-Driven Architecture).md
deleted file mode 100644
index ae7f7f58..00000000
--- a/Programming & Language/이벤트 기반 아키텍처 (Event-Driven Architecture).md	
+++ /dev/null
@@ -1,40 +0,0 @@
----
-id: P-REINFORCE-AUTO-980240
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - 이벤트 기반 아키텍처 (Event-Driven Architecture)"
----
-
-# [[이벤트 기반 아키텍처 (Event-Driven Architecture)]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 이벤트 기반 아키텍처(EDA)는 사용자의 클릭, 금융 트랜잭션, 센서 판독과 같은 '이벤트'의 생성과 소비를 통해 시스템 구성 요소들이 비동기적으로 통신하는 강력한 소프트웨어 설계 패러다임입니다 [1, 2]. 전통적인 배치 처리나 직접적인 API 호출 방식과 달리, 데이터가 생성되는 즉시 반응하고 처리하여 시스템 간의 느슨한 결합(Loose coupling)을 촉진합니다 [1-3]. 이를 통해 컴포넌트를 독립적으로 개발, 배포 및 확장할 수 있으며, 예측 불가능한 높은 부하와 실시간 데이터 처리가 요구되는 현대의 분산 시스템에 필수적인 아키텍처로 평가받고 있습니다 [2].
-
-## 📖 구조화된 지식 (Synthesized Content)
-- **작동 원리 및 통신 방식:** 시스템의 한 컴포넌트가 다른 컴포넌트를 직접 호출하는 대신, 이벤트 생산자가 이벤트를 생성하여 메시지 브로커(Message Broker)로 발행(publish)하면 이를 관심 있는 소비자(consumer)에게 비동기적으로 라우팅하는 방식으로 작동합니다 [2, 3].
-- **핵심 이점:**
-  - **느슨한 결합 및 독립성:** 컴포넌트들이 서로 직접적인 지식을 가질 필요 없이 자신이 생성하거나 소비하는 이벤트만 알면 되므로 결합도가 낮아집니다. 이를 통해 각 서비스를 완전히 독립적으로 개발, 배포 및 확장할 수 있습니다 [2].
-  - **실시간 통찰력 및 반응성:** 데이터가 생성되는 즉시 처리(Real-time Data Streaming)하여 저지연(Low-latency)으로 즉각적인 통찰력을 제공하며, 비즈니스가 구식 정보에 의존하여 경쟁력을 잃는 것을 방지합니다 [1, 4, 5].
-- **효과적인 구현을 위한 최상위 관행 (Actionable Implementation Tips):**
-  - **메시지 브로커 사용:** Apache Kafka, RabbitMQ, AWS Kinesis/SNS/SQS 등 전용 메시지 브로커를 활용하여 이벤트 라우팅, 지속성 및 전달을 보장해야 합니다 [1, 3, 6].
-  - **멱등성(Idempotency) 소비자의 설계:** 분산 시스템에서 동일한 이벤트가 여러 번 처리되더라도 오류나 데이터 중복을 일으키지 않도록 이벤트 소비자(핸들러)를 멱등성을 가지게 구축해야 합니다 [5-7].
-  - **DLQs (Dead-Letter Queues) 구현:** 여러 번의 재시도 후에도 처리되지 못한 실패 메시지를 별도의 큐(DLQ)로 격리함으로써, 단일 실패 메시지가 전체 시스템을 차단하는 것을 막고 나중에 원인 분석을 할 수 있도록 해야 합니다 [6, 7].
-  - **스키마 레지스트리 (Schema Registry) 도입:** 생산자와 소비자 간의 데이터 계약을 강제하여 시스템 전반에 구조 불일치나 품질 문제가 발생하는 것을 사전에 방지해야 합니다 [7].
-  - **소비자 지연 (Consumer Lag) 모니터링:** 소비자가 생산된 데이터 볼륨을 따라가지 못해 발생하는 지연 현상을 지속적으로 모니터링하여 병목과 데이터의 진부화를 방지합니다 [7].
-- **주요 활용 사례:** 핀테크의 사기 탐지(Fraud detection) 및 실시간 주식 거래, 이커머스의 실시간 재고 관리 및 마이크로서비스 오케스트레이션(결제 프로세스 등), IoT 기기 모니터링 등 즉각적인 반응이 필요한 고부하 시스템 전반에 폭넓게 적용됩니다 [1, 3-5].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[Microservices Architecture]], [[Real-time Data Streaming]], [[Message Broker]], [[Apache Kafka]]
-- **Projects/Contexts:** [[Real-Time Stock Trading]], [[IoT Data Processing]], [[Microservices Orchestration]]
-- **Contradictions/Notes:** 소스에 따르면 이벤트 기반 아키텍처는 고도의 반응성과 확장성을 제공하지만, 분산 시스템 및 스트림 의미론과 관련된 비동기적 복잡성과 실행 순서 관리의 난이도가 높으며 브로커 등 인프라를 구축하고 운영하기 위한 높은 전문 지식이 요구된다는 단점(Implementation Complexity: High)이 존재합니다 [4, 5].
-
----
-*Last updated: 2026-04-18*
-- Raw Source: [[00_Raw/2026-04-20/이벤트 기반 아키텍처 (Event-Driven Architecture).md]]
----
diff --git a/Programming & Language/이전 세대(Old Generation_Space).md b/Programming & Language/이전 세대(Old Generation_Space).md
deleted file mode 100644
index bc22b2b2..00000000
--- a/Programming & Language/이전 세대(Old Generation_Space).md	
+++ /dev/null
@@ -1,45 +0,0 @@
----
-id: P-REINFORCE-AUTO-7BED1F
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - 이전 세대(Old Generation_Space)"
----
-
-# [[이전 세대(Old Generation_Space)]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> V8 엔진의 힙(Heap) 메모리 구조에서 '이전 세대(Old Generation 또는 Old Space)'는 신세대(New Space)에서 발생하는 여러 번의 마이너 가비지 컬렉션(스캐빈지)을 거치고 살아남은, 수명이 긴 객체들이 승격(Promote)되어 저장되는 메모리 공간입니다 [1-4]. 이 공간은 데이터의 특성에 따라 포인터가 있는 공간(Old-pointer-space)과 순수 데이터만 있는 공간(Old-data-space)으로 나뉘며, 메이저 가비지 컬렉터(Major GC)에 의해 관리됩니다 [4-6].
-
-## 📖 구조화된 지식 (Synthesized Content)
-* **이전 세대 메모리의 구조 및 세분화**
-  이전 세대는 수백 메가바이트의 데이터를 포함할 수 있는 매우 큰 공간으로, 내부적으로 두 개의 주요 공간으로 나뉩니다 [7].
-  * **Old-pointer-space:** 다른 객체를 가리키는 포인터를 포함할 수 있는 대부분의 살아남은 객체들이 보관되는 곳입니다 [4-6].
-  * **Old-data-space:** 포인터 없이 순수하게 원시 데이터만 포함하는 객체(예: 문자열, 박스화된 숫자, 언박싱된 더블 배열 등)가 위치합니다 [4-6]. 이 공간에서는 객체가 다른 객체로의 포인터를 가지지 않는다는 것을 GC가 알고 있기 때문에, 마킹(Marking) 시 포인터 추적 단계를 건너뛰어 성능을 최적화할 수 있습니다 [2].
-
-* **메이저 가비지 컬렉션(Major GC)**
-  이전 세대는 공간이 크기 때문에 신세대에서 사용하는 스캐빈지(Scavenge) 알고리즘(To-Space와 From-Space를 이용한 복사 방식)을 적용하는 것이 물리적 메모리 오버헤드 측면에서 비실용적입니다 [7, 8]. 따라서 마크-스윕(Mark-Sweep)과 마크-컴팩트(Mark-Compact)라는 두 가지 주요 알고리즘을 사용합니다 [7, 9, 10].
-  * **Mark (마킹):** 깊이 우선 탐색(DFS) 알고리즘을 사용하여 루트(Root)에서 접근 가능한 활성 객체(Live objects)를 찾아 검은색(Black)으로 표시합니다 [11-13].
-  * **Sweep (스윕):** 마킹되지 않은 연속된 데드 객체들을 스캔하여 이를 여유 공간(Free lists)으로 변환함으로써 메모리를 재사용할 수 있게 합니다 [14, 15].
-  * **Compact (컴팩트):** 메모리 단편화(Fragmentation)가 심한 페이지의 활성 객체를 다른 페이지의 빈 공간으로 복사(이주)시키고 원래 공간을 해제하여 메모리 효율을 높입니다 [9, 16, 17]. 이동 비용이 높기 때문에 모든 경우에 수행되지는 않고 필요에 따라 선별적으로 공격적인 압축을 수행합니다 [9, 18].
-
-* **최적화: 점진적 마킹 및 지연 스윕(Incremental Marking & Lazy Sweeping)**
-  대규모 이전 세대 메모리를 한 번에 수집하려고 하면 수백 밀리초에 달하는 긴 애플리케이션 지연(Stop-the-world pause)이 발생할 수 있습니다 [17, 19]. 이를 방지하기 위해 가비지 컬렉션을 작은 단계로 나누어 메인 스레드의 JavaScript 실행과 교차 수행하는 '점진적 마킹(Incremental marking)'과, 모든 페이지를 한 번에 스윕하지 않고 메모리가 필요한 시점까지 스윕을 미루는 '지연 스윕(Lazy sweeping)' 기법을 사용합니다 [17, 19-22].
-
-* **쓰기 장벽(Write Barriers)과 포인터 추적**
-  이전 세대의 객체가 신세대(New Space)의 객체를 가리키는 포인터를 가지게 될 경우, 마이너 GC가 이를 인식하지 못해 활성 객체를 지우는 것을 방지하기 위해 '쓰기 장벽(Write barriers)'을 사용합니다 [23-25]. 이 장벽은 구세대에서 신세대로 향하는 포인터(Old-to-new references)가 기록될 때 이를 스토어 버퍼(Store buffer)에 저장하여, 이후 마이너 GC 시 이전 세대 전체를 스캔하지 않고도 효율적으로 객체를 수집할 수 있게 합니다 [23, 24].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[New Space (Young Generation)]], [[Major GC (Mark-Sweep / Mark-Compact)]], [[Write Barriers]], [[Generational Hypothesis]]
-- **Projects/Contexts:** [[V8 JavaScript Engine]], [[Orinoco Garbage Collector]]
-- **Contradictions/Notes:** 소스에 관련 정보가 부족합니다. (소스 전반에서 이전 세대 관리에 대한 설명은 일관되며 명시적인 모순점은 존재하지 않습니다.)
-
----
-*Last updated: 2026-04-19*
-- Raw Source: [[00_Raw/2026-04-20/이전 세대(Old Generation_Space).md]]
----
diff --git a/Programming & Language/이커머스의 실시간 재고 관리.md b/Programming & Language/이커머스의 실시간 재고 관리.md
deleted file mode 100644
index 7cd98df8..00000000
--- a/Programming & Language/이커머스의 실시간 재고 관리.md	
+++ /dev/null
@@ -1,34 +0,0 @@
----
-id: P-REINFORCE-AUTO-E72D2E
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - 이커머스의 실시간 재고 관리"
----
-
-# [[이커머스의 실시간 재고 관리]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 이커머스의 실시간 재고 관리는 기존의 일괄 처리(batch processing) 방식에서 벗어나, 데이터가 생성되는 즉시 처리하는 실시간 데이터 스트리밍을 활용하는 시스템입니다 [1]. 사용자의 클릭이나 주문 접수와 같은 시스템상의 '이벤트'에 즉각적으로 반응하는 이벤트 기반 아키텍처(Event-Driven Architecture)를 통해 작동합니다 [1]. 이를 통해 구식 정보에 의존하지 않고 즉각적인 통찰력을 얻어 신속한 의사결정과 대응을 가능하게 합니다 [1].
-
-## 📖 구조화된 지식 (Synthesized Content)
-* **실시간 데이터 스트리밍의 활용:** 이커머스의 실시간 재고 관리는 현대 데이터 엔지니어링 모범 사례 중 하나인 실시간 데이터 스트리밍 패러다임에 의존합니다. 데이터를 생성되는 즉시 처리함으로써 즉각적인 재고 파악과 조치를 가능하게 합니다 [1].
-* **이벤트 기반 아키텍처(EDA) 적용:** 시스템이 데이터베이스를 직접 호출하여 조작하는 대신 사용자 클릭, 금융 거래 등의 '이벤트'에 반응하도록 설계됩니다 [1]. 이커머스에서 체크아웃과 같은 다단계 프로세스가 진행될 때 직접적인 API 호출을 사용하지 않고, '주문 접수'나 '결제 처리됨'과 같은 개별 이벤트를 생성합니다 [2].
-* **마이크로서비스를 통한 재고 업데이트:** 발생한 이벤트를 후속 마이크로서비스들이 수신(listen)하여, 실시간으로 재고를 업데이트하거나 배송 알림을 보내는 방식으로 작업을 수행하게 됩니다 [2].
-* **핵심 인프라 기술:** 이러한 실시간 재고 관리 및 이벤트 기반 아키텍처를 구현하기 위한 핵심 기술로 Apache Kafka와 AWS Kinesis 같은 메시지 브로커 및 스트리밍 플랫폼이 활용됩니다 [1].
-* *(참고: 업로드된 소스에서 이커머스의 실시간 재고 관리는 소프트웨어 아키텍처 및 데이터 엔지니어링의 예시로만 간략히 언급되어 있으며, 재고 관리 비즈니스 로직 등의 구체적인 세부 내용에 대해서는 소스에 관련 정보가 부족합니다.)*
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[실시간 데이터 스트리밍]], [[이벤트 기반 아키텍처]], [[마이크로서비스 아키텍처]]
-- **Projects/Contexts:** 이커머스 결제 및 체크아웃 파이프라인 (Apache Kafka 및 AWS Kinesis 활용 사례) [1, 2]
-- **Contradictions/Notes:** 주어진 소스 내에서 이커머스의 실시간 재고 관리는 현대 데이터 아키텍처(이벤트 스트리밍 등)가 어떻게 사용되는지 보여주는 단편적인 예시로만 다뤄지고 있으므로, 재고 관리 시스템의 전반적인 운영 프로세스에 대해서는 소스에 관련 정보가 부족합니다.
-
----
-*Last updated: 2026-04-18*
-- Raw Source: [[00_Raw/2026-04-20/이커머스의 실시간 재고 관리.md]]
----
diff --git a/Programming & Language/인문학적 게임 비평 및 서사학12.md b/Programming & Language/인문학적 게임 비평 및 서사학12.md
deleted file mode 100644
index 7fe75c06..00000000
--- a/Programming & Language/인문학적 게임 비평 및 서사학12.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-F20E50
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - 인문학적 게임 비평 및 서사학12"
----
-
-# [[인문학적 게임 비평 및 서사학12]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/인문학적 게임 비평 및 서사학12.md]]
----
diff --git a/Programming & Language/임베딩 (Embedding).md b/Programming & Language/임베딩 (Embedding).md
deleted file mode 100644
index a015ad28..00000000
--- a/Programming & Language/임베딩 (Embedding).md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-6E92CC
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - 임베딩 (Embedding)"
----
-
-# [[임베딩 (Embedding)]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/임베딩 (Embedding).md]]
----
diff --git a/Programming & Language/임상 심리학의 변화 동기 치료.md b/Programming & Language/임상 심리학의 변화 동기 치료.md
deleted file mode 100644
index 6bb60c15..00000000
--- a/Programming & Language/임상 심리학의 변화 동기 치료.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-EE54A5
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - 임상 심리학의 변화 동기 치료"
----
-
-# [[임상 심리학의 변화 동기 치료]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/임상 심리학의 변화 동기 치료.md]]
----
diff --git a/Programming & Language/자기결정성 이론 (SDT).md b/Programming & Language/자기결정성 이론 (SDT).md
deleted file mode 100644
index c95968cc..00000000
--- a/Programming & Language/자기결정성 이론 (SDT).md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-AB9DD3
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - 자기결정성 이론 (SDT)"
----
-
-# [[자기결정성 이론 (SDT)]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/자기결정성 이론 (SDT).md]]
----
diff --git a/Programming & Language/자기결정성 이론 (Self-Determination Theory).md b/Programming & Language/자기결정성 이론 (Self-Determination Theory).md
deleted file mode 100644
index e4252458..00000000
--- a/Programming & Language/자기결정성 이론 (Self-Determination Theory).md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-5A0AD3
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - 자기결정성 이론 (Self-Determination Theory)"
----
-
-# [[자기결정성 이론 (Self-Determination Theory)]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/자기결정성 이론 (Self-Determination Theory).md]]
----
diff --git a/Programming & Language/자동화된 코드 리뷰.md b/Programming & Language/자동화된 코드 리뷰.md
deleted file mode 100644
index 372760f7..00000000
--- a/Programming & Language/자동화된 코드 리뷰.md	
+++ /dev/null
@@ -1,47 +0,0 @@
----
-id: P-REINFORCE-AUTO-AAE0A7
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - 자동화된 코드 리뷰"
----
-
-# [[자동화된 코드 리뷰]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 자동화된 코드 리뷰는 린터(Linter), 포매터(Formatter), 정적 애플리케이션 보안 테스트(SAST) 등의 소프트웨어 도구를 사용하여 프로그램을 실행하지 않고 소스 코드를 자동으로 분석하는 프로세스입니다 [1-3]. 이 방법은 소프트웨어 개발 수명 주기(SDLC) 초기에 구문 오류, 코드 스타일 위반, 알려진 보안 취약점을 일관되고 빠르게 탐지하는 데 중점을 둡니다 [4-6]. 하지만 비즈니스 로직이나 아키텍처 등 문맥을 파악하는 데는 한계가 있으므로 인간이 직접 수행하는 수동 코드 리뷰와 결합된 하이브리드 모델로 활용하는 것이 현대 개발의 모범 사례로 평가받고 있습니다 [7, 8].
-
-## 📖 구조화된 지식 (Synthesized Content)
-- **개념 및 분석 방식:**
-  자동화된 코드 리뷰는 주로 프로그램을 직접 실행하지 않은 상태에서 소스 코드나 바이트코드를 분석하는 정적 코드 분석 기술을 기반으로 작동합니다 [1, 9]. ESLint와 같은 린터(Linter)는 코드의 품질과 문법적 오류를 정적으로 검사하여 결함을 찾아내며, Prettier와 같은 포매터(Formatter)는 소스 코드를 일관된 스타일로 작성할 수 있게 변환해 주는 역할을 수행합니다 [2, 10].
-  
-- **자동화된 코드 리뷰의 주요 이점:**
-  - **속도와 확장성:** 기계적인 분석을 통해 수천 줄의 코드를 몇 초에서 몇 분 안에 스캔하여 코드 리뷰의 지연 시간을 대폭 줄이고 피드백 루프를 가속화합니다 [5, 6].
-  - **일관성 및 객관성:** 도구는 사전에 정의된 규칙을 코드베이스 전체에 예외 없이 동일하게 적용하므로 리뷰어의 피로도나 개인적 편향을 제거하고 표준을 강제할 수 있습니다 [5, 6].
-  - **초기 결함 탐지(Shift-Left):** PR(Pull Request) 단계나 CI/CD 파이프라인, 심지어 IDE 내에서 코드를 작성하는 실시간으로 스캔하여, 메모리 누수, SQL 인젝션, 사용하지 않는 변수 등의 치명적 오류가 배포되기 전에 조기 차단합니다 [11-13].
-
-- **자동화의 한계점:**
-  - **컨텍스트 이해 부족 (Context Blindness):** 자동화 도구는 아키텍처의 트레이드오프나 도메인 특화된 비즈니스 로직, 개발자의 근본적인 설계 의도를 이해하지 못합니다 [14, 15].
-  - **오탐(False Positives)과 피로도:** 도구에 따라 30~60%에 달하는 오탐률을 보일 수 있으며, 이로 인해 쏟아지는 경고 메시지는 개발자의 '경고 피로도(Alert Fatigue)'를 유발하여 진짜 중요한 이슈를 무시하게 만들 수 있습니다 [14, 16].
-  - **취약점 누락:** 경험적 연구에 따르면 단일 SAST 도구는 실제 존재하는 취약점의 약 22%를 탐지하지 못하고 놓치는 맹점을 가지고 있습니다 [17].
-
-- **파이프라인 및 CI/CD 통합:**
-  코드 품질 관리를 개발 워크플로우에 자동화하기 위해 Git Hooks를 관리하는 `husky`와 변경된(staged) 파일만 스캔하여 속도를 높이는 `lint-staged`를 널리 조합하여 사용합니다 [18, 19]. 이를 통해 `pre-commit` 단계에서 자동으로 린터와 포매터를 실행하여 잘못된 코드가 커밋되는 것을 원천적으로 차단하거나, CI 파이프라인의 품질 게이트(Quality Gates)로 활용하여 병합을 제어합니다 [20, 21].
-
-- **하이브리드 코드 리뷰의 필요성:**
-  기계적인 구문 오류, 스타일 강제, 알려진 보안 패턴 검증은 자동화 도구에 전적으로 위임하고, 사람(리뷰어)은 아키텍처 결정, 여러 서비스에 미치는 연쇄적 영향 평가, 비즈니스 로직 검증 등 인간의 전문성이 필요한 복잡한 판단에 집중하는 '하이브리드 코드 리뷰' 방식이 권장됩니다 [7, 22, 23].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[정적 애플리케이션 보안 테스트(SAST)]], [[수동 코드 리뷰]], [[린터(Linter)]]
-- **Projects/Contexts:** [[CI/CD 파이프라인]], [[Husky와 lint-staged를 활용한 Git Hooks 연동]]
-- **Contradictions/Notes:** 소스 [6]는 자동화된 코드 리뷰가 빠른 속도로 방대한 코드베이스의 취약점과 오류를 일관성 있게 잡아낸다는 이점을 강조하지만, 소스 [16, 17]은 자동화 도구가 실제 취약점의 22%를 놓치고 30~60%에 달하는 오탐(False Positives)을 발생시킬 수 있는 한계를 지적하며, 비즈니스 로직과 아키텍처를 이해하기 위해서는 반드시 수동 리뷰가 결합된 하이브리드 접근법을 채택해야 한다고 주장합니다.
-
----
-*Last updated: 2026-04-19*
-- Raw Source: [[00_Raw/2026-04-20/자동화된 코드 리뷰.md]]
----
diff --git a/Programming & Language/자바 가상 머신(JVM).md b/Programming & Language/자바 가상 머신(JVM).md
deleted file mode 100644
index 4e6dd44a..00000000
--- a/Programming & Language/자바 가상 머신(JVM).md	
+++ /dev/null
@@ -1,33 +0,0 @@
----
-id: P-REINFORCE-AUTO-2F0FAA
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - 자바 가상 머신(JVM)"
----
-
-# [[자바 가상 머신(JVM)]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 자바 가상 머신(JVM)은 자바(Java)와 같은 정적 타입 언어의 애플리케이션 실행을 위한 환경으로, 주로 자바 힙(Java heap)의 메모리 할당 및 가비지 컬렉션(GC)을 전담하는 엔진입니다 [1, 2]. 애플리케이션의 메모리 고갈을 방지하기 위해 더 이상 사용되지 않는 객체를 회수하며, 표시(mark), 청소(sweep), 압축(compact) 등의 과정을 거칩니다 [2]. 시중에는 3개의 주요 프로덕션 JVM이 존재하며, 이들은 각기 다른 가비지 컬렉션 알고리즘을 구현하여 사용하고 있습니다 [3].
-
-## 📖 구조화된 지식 (Synthesized Content)
-* **포인터 식별과 컴파일러 힌트 (Compiler Hints):** JVM은 정적 타입 언어인 자바에서 작동하므로 메모리 내의 포인터를 식별할 때 컴파일러가 제공하는 힌트를 사용합니다 [1]. 컴파일러는 각 클래스 내 포인터의 오프셋을 알려주며, 객체의 클래스만 식별하면 해당 객체의 모든 포인터를 찾을 수 있습니다 [1]. 이는 자바스크립트와 같은 동적 타입 언어의 엔진(예: V8)이 채택한 방식과는 다릅니다 [1].
-* **자바 힙(Java Heap)과 가비지 컬렉션(GC):** JVM은 힙 영역에서 도달 가능한(reachable) 객체를 식별(Mark)하고, 도달 불가능한 객체를 지워(Sweep) 메모리를 확보하며, 파편화가 심할 경우 힙을 압축(Compact)하여 메모리를 관리합니다 [2]. GC 작업은 전체 힙을 대상으로 하는 전역(Global) GC 사이클과 힙의 일부만 처리하는 부분(Partial) GC 사이클로 나뉘어 실행됩니다 [4].
-* **GC 정책과 동작 원리:** `System.gc()` 호출이나 메모리 할당 실패 시 GC가 명시적 혹은 암시적으로 트리거됩니다 [4]. IBM SDK 및 Eclipse OpenJ9 환경의 JVM은 `gencon`, `optavgpause`, `balanced` 등 다양한 GC 정책을 사용하며, 애플리케이션 스레드와 동시에(Concurrent) 또는 증분(Incremental) 방식으로 마킹 및 스윕 작업을 수행하여 애플리케이션의 멈춤(Stop-the-world) 시간을 줄이도록 설계되었습니다 [5-8].
-* **참조 처리 (Reference Processing):** JVM의 가비지 컬렉터는 소프트 참조(Soft Reference), 약한 참조(Weak Reference), 팬텀 참조(Phantom Reference)를 각각의 메모리 부족 상태 및 참조 주기에 맞게 수집하며, JNI(Java Native Interface) 상의 약한 객체 참조도 함께 처리합니다 [9-11].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[가비지 컬렉션(Garbage Collection)]], [[자바 힙(Java Heap)]], [[컴파일러 힌트(Compiler hints)]]
-- **Projects/Contexts:** [[Eclipse OpenJ9]], [[IBM SDK]]
-- **Contradictions/Notes:** JVM의 컴파일러 힌트 방식은 정적 타입 언어의 메모리 관리에 최적화되어 있으나, 자바스크립트처럼 객체의 속성이 포인터인지 데이터인지 미리 알 수 없는 동적 타입 언어에는 적합하지 않아 V8 엔진은 이를 채택하지 않고 태그된 포인터(Tagged pointers) 방식을 사용합니다 [1].
-
----
-*Last updated: 2026-04-19*
-- Raw Source: [[00_Raw/2026-04-20/자바 가상 머신(JVM).md]]
----
diff --git a/Programming & Language/자율성 지지 (Autonomy Support).md b/Programming & Language/자율성 지지 (Autonomy Support).md
deleted file mode 100644
index b1ff6e72..00000000
--- a/Programming & Language/자율성 지지 (Autonomy Support).md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-EB1B7E
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - 자율성 지지 (Autonomy Support)"
----
-
-# [[자율성 지지 (Autonomy Support)]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/자율성 지지 (Autonomy Support).md]]
----
diff --git a/Programming & Language/자폐 스펙트럼 장애(ASD) 중재.md b/Programming & Language/자폐 스펙트럼 장애(ASD) 중재.md
deleted file mode 100644
index 04f3ae68..00000000
--- a/Programming & Language/자폐 스펙트럼 장애(ASD) 중재.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-DD3080
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - 자폐 스펙트럼 장애(ASD) 중재"
----
-
-# [[자폐 스펙트럼 장애(ASD) 중재]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/자폐 스펙트럼 장애(ASD) 중재.md]]
----
diff --git a/Programming & Language/장기 실행되는 실시간 데이터 대시보드 최적화.md b/Programming & Language/장기 실행되는 실시간 데이터 대시보드 최적화.md
deleted file mode 100644
index 04a384ee..00000000
--- a/Programming & Language/장기 실행되는 실시간 데이터 대시보드 최적화.md	
+++ /dev/null
@@ -1,48 +0,0 @@
----
-id: P-REINFORCE-AUTO-D81993
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - 장기 실행되는 실시간 데이터 대시보드 최적화"
----
-
-# [[장기 실행되는 실시간 데이터 대시보드 최적화]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 장시간 켜져 있으면서 대량의 데이터를 실시간으로 처리해야 하는 대시보드 애플리케이션은 **메모리 누수(Memory Leak) 방지**와 **리렌더링 병목 제어**가 핵심입니다. 이를 위해 상태 관리의 미세 조정, 철저한 클린업, 대규모 리스트 가상화, 그리고 무거운 연산의 웹 워커 오프로딩 기법을 종합적으로 적용해야 합니다.
-
-## 📖 구조화된 지식 (Synthesized Content)
-**1. 철저한 클린업을 통한 메모리 누수(Memory Leak) 방지** 대시보드가 장시간 실행될 때 가장 주의해야 할 점은 백그라운드에 쌓이는 메모리 누수입니다. 시간이 지날수록 앱이 느려지고 결국 크래시되는 현상을 막으려면 다음을 반드시 처리해야 합니다.
-
-- **실시간 연결 및 타이머 해제:** `useEffect` 내에서 설정한 실시간 데이터용 웹소켓(WebSocket) 연결이나 `setInterval` 타이머는 컴포넌트가 화면에서 사라질 때(Unmount) 반드시 `ws.close()`나 `clearInterval`을 호출하여 명시적으로 종료해야 합니다.
-- **이벤트 리스너 제거:** 창 크기 조절(Resize) 등의 이벤트를 등록했다면 클린업 함수에서 `window.removeEventListener`를 호출해 해제해야 합니다.
-- **거대 객체 참조 해제:** 무거운 데이터 세트를 `useRef` 등으로 참조하고 있다면, 사용이 끝난 후 참조 변수에 `null`을 할당하여 가비지 컬렉터(GC)가 메모리를 회수할 수 있도록 명시적으로 도와야 합니다.
-
-**2. 고빈도 업데이트를 위한 상태 관리 최적화** 실시간 대시보드에서는 데이터가 초당 수십 번씩 업데이트될 수 있습니다. 이때 React의 기본 Context API를 사용하면 내부 값이 하나만 변해도 이를 구독하는 모든 컴포넌트가 리렌더링되는 폭포수 현상(Cascading)이 발생합니다.
-
-- 이러한 병목을 막기 위해 **Zustand, Jotai, Valtio**와 같이 미세 조정(Fine-grained) 업데이트를 지원하는 상태 관리 라이브러리를 도입해야 합니다.
-- Zustand의 선택적 구독(Selector)을 활용하거나 Jotai의 원자적(Atomic) 상태 모델을 사용하여 **실제 데이터가 변경된 UI 컴포넌트만 정밀하게 리렌더링되도록 설계**하는 것이 필수적입니다.
-
-**3. 대규모 데이터 가상화 (Virtualization)** 실시간으로 쌓이는 수천 개의 로그나 대규모 데이터 테이블을 한 번에 렌더링하면 DOM 노드가 폭증하여 브라우저가 멈추게 됩니다.
-
-- `react-window`나 `react-virtualized`와 같은 가상화 라이브러리를 사용하여 **현재 화면(Viewport)에 보이는 항목만 렌더링**하고 나머지는 스크롤 시 동적으로 마운트해야 합니다. 이를 통해 렌더링 소요 시간을 수 초 단위에서 수 밀리초(ms) 단위로 극적으로 줄일 수 있습니다.
-- 또한 잦은 이벤트(스크롤, 리사이즈 등)에는 **스로틀링(Throttling) 및 디바운싱(Debouncing)**을 적용하여 불필요한 연산 부하를 제어해야 합니다.
-
-**4. 무거운 데이터 연산의 Web Worker 오프로딩** 대용량 JSON 파싱, 복잡한 데이터 정렬이나 필터링 등 CPU 집약적인 작업은 자바스크립트의 메인 스레드를 차단하여 대시보드의 UI를 먹통(Freezing)으로 만듭니다.
-
-- 이러한 작업은 **웹 워커(Web Worker)나 `useWorker` 훅을 활용하여 백그라운드 스레드로 오프로딩(Offloading)** 해야 합니다. 이렇게 하면 복잡한 데이터 처리가 진행되는 동안에도 사용자는 대시보드와 끊김 없이 상호작용(60 FPS 유지)할 수 있습니다.
-
-**5. React 동시성(Concurrent) 기능 활용** 실시간으로 쏟아지는 대규모 데이터 렌더링 때문에 사용자의 입력(검색어 타이핑, 필터 클릭 등)이 버벅거리는 것을 막아야 합니다.
-
-- React 18의 **`useTransition`**을 사용하여 무거운 차트나 목록의 업데이트를 비긴급(Non-urgent) 작업으로 미루고, 사용자의 타이핑 같은 긴급한 인터랙션을 즉각적으로 처리할 수 있습니다.
-- **`useDeferredValue`**를 활용하면 값의 계산을 지연시켜 메인 스레드의 과부하 시에도 UI가 부드럽게 유지되도록 제어할 수 있습니다.
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/장기 실행되는 실시간 데이터 대시보드 최적화.md]]
----
diff --git a/Programming & Language/재귀적 불변성 (DeepReadonly).md b/Programming & Language/재귀적 불변성 (DeepReadonly).md
deleted file mode 100644
index 97e45815..00000000
--- a/Programming & Language/재귀적 불변성 (DeepReadonly).md	
+++ /dev/null
@@ -1,33 +0,0 @@
----
-id: P-REINFORCE-AUTO-1F695C
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - 재귀적 불변성 (DeepReadonly)"
----
-
-# [[재귀적 불변성 (DeepReadonly)]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 재귀적 불변성(DeepReadonly)은 TypeScript에서 최상위 속성뿐만 아니라 중첩된 내부 객체까지 모두 불변(immutable) 상태로 만드는 커스텀 유틸리티 타입 기법입니다 [1-3]. 내장 `Readonly<T>` 타입이나 `readonly` 수식어가 제공하는 얕은(shallow) 수준의 보호 한계를 극복하기 위해 매핑 타입과 조건부 타입을 결합하여 구현합니다 [1, 3-5]. 전체 데이터 구조의 변경을 방지하여 트리 구조나 복잡한 중첩 데이터를 다루는 상태 관리 및 설정 객체 등에서 데이터 무결성을 보장하는 강력한 방어책 역할을 합니다 [1, 3].
-
-## 📖 구조화된 지식 (Synthesized Content)
-- **얕은 불변성의 한계:** TypeScript의 내장 `Readonly<T>` 유틸리티 타입이나 기본적인 `readonly` 수식어는 객체의 최상위(top-level) 속성만 읽기 전용으로 만든다 [1, 2, 5]. 이로 인해 중첩된 객체(nested objects)나 배열의 깊은 내부 속성들은 여전히 변경 가능한(mutable) 상태로 남아 예기치 않은 데이터 오염에 취약해진다 [1, 2, 5].
-- **DeepReadonly의 동작 원리:** 이러한 한계를 극복하기 위해 모든 내부 계층을 보호할 수 있는 `DeepReadonly` 재귀적 타입(Recursive Type)을 정의한다 [1, 2]. 이 타입은 매핑 타입(Mapped Types)과 조건부 타입(Conditional Types)을 결합하여 구성하며, 객체의 프로퍼티를 순회하며 중첩된 모든 속성에 재귀적으로 `readonly`를 강제하여 전체 구조를 동결시킨다 [1, 3].
-- **구현 및 라이브러리 의존성:** `DeepReadonly`는 현재 TypeScript 언어에 기본적으로 내장된 유틸리티 타입이 아니다 [6]. 따라서 시스템 무결성을 위해 개발자가 직접 재귀적 헬퍼 타입을 정의하거나, `ts-essentials`와 같이 이를 제공하는 외부 라이브러리에 의존해야 한다 [6]. 반대로 불변성을 해제해야 하는 경우에는 `Mutable` 헬퍼 타입을 만들어 모든 속성의 `readonly`를 제거할 수도 있다 [2, 7].
-- **핵심 활용 사례:** 트리 구조나 복잡한 중첩 데이터를 다룰 때 단 하나의 속성도 변경되지 않도록 보장한다 [1, 3]. 생성 후 구조가 수정되어서는 안 되는 설정 객체(Configuration objects), 상태 관리 아키텍처, 그리고 데이터 무결성이 치명적으로 중요한 금융 시스템 등에서 필수적인 보호 요소로 자리 잡고 있다 [1, 3, 8].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[Readonly]], [[매핑 타입 (Mapped Types)]], [[조건부 타입 (Conditional Types)]], [[유틸리티 타입 (Utility Types)]]
-- **Projects/Contexts:** [[ts-essentials]], [[프론트엔드 상태 관리 (State Management)]], [[설정 객체 (Configuration objects)]]
-- **Contradictions/Notes:** `Readonly<T>`는 기본 제공되나 `DeepReadonly`는 TypeScript에 내장되어 있지 않다는 점이 특징입니다 [6]. 또한 런타임에 성능 오버헤드를 일으키는 `Object.freeze()`의 얕은 동결과 달리, 이 방식은 컴파일 타임에 타입 레벨에서만 불변성을 검사하고 강제하므로 훨씬 효율적입니다 [5].
-
----
-*Last updated: 2026-04-18*
-- Raw Source: [[00_Raw/2026-04-20/재귀적 불변성 (DeepReadonly).md]]
----
diff --git a/Programming & Language/전두엽 기능 저하 (Hypofrontality).md b/Programming & Language/전두엽 기능 저하 (Hypofrontality).md
deleted file mode 100644
index 6583f30f..00000000
--- a/Programming & Language/전두엽 기능 저하 (Hypofrontality).md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-B8940A
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - 전두엽 기능 저하 (Hypofrontality)"
----
-
-# [[전두엽 기능 저하 (Hypofrontality)]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/전두엽 기능 저하 (Hypofrontality).md]]
----
diff --git a/Programming & Language/절차적 수사학(Procedural Rhetoric).md b/Programming & Language/절차적 수사학(Procedural Rhetoric).md
deleted file mode 100644
index 86a3c10a..00000000
--- a/Programming & Language/절차적 수사학(Procedural Rhetoric).md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-274581
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - 절차적 수사학(Procedural Rhetoric)"
----
-
-# [[절차적 수사학(Procedural Rhetoric)]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/절차적 수사학(Procedural Rhetoric).md]]
----
diff --git a/Programming & Language/점진적 마킹(Incremental marking).md b/Programming & Language/점진적 마킹(Incremental marking).md
deleted file mode 100644
index 98e1bcb1..00000000
--- a/Programming & Language/점진적 마킹(Incremental marking).md	
+++ /dev/null
@@ -1,40 +0,0 @@
----
-id: P-REINFORCE-AUTO-EED588
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - 점진적 마킹(Incremental marking)"
----
-
-# [[점진적 마킹(Incremental marking)]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 점진적 마킹(Incremental marking)은 가비지 컬렉션(GC) 과정에서 발생하는 긴 중단 시간(Stop-the-world)을 줄이기 위해 전체 마킹 작업을 여러 개의 작은 일시 정지 구간으로 나누어 실행하는 기법입니다 [1-3]. 애플리케이션의 메인 스레드 실행과 마킹 작업이 교차로 진행되므로 힙 탐색 중에도 사용자 입력 처리나 애니메이션 렌더링을 계속할 수 있습니다 [2, 4]. 비록 가비지 컬렉션에 소비되는 총시간을 줄여주지는 못하지만, 작업 시간을 분산시킴으로써 애플리케이션의 지연 시간(Latency)과 반응성을 크게 개선합니다 [2].
-
-## 📖 구조화된 지식 (Synthesized Content)
-* **작동 메커니즘 및 활성화 조건:** 
-  점진적 마킹은 힙 크기가 특정 임계값에 도달하면 활성화되며, 이후 일정량의 메모리가 할당될 때마다 실행이 잠시 중단되고 점진적 마킹 '단계(step)'가 수행됩니다 [1, 3]. V8 엔진에서는 모바일 기기 기준으로 각 일시 정지 시간이 5~10ms 수준으로 매우 짧게 유지됩니다 [1, 3]. 기본적으로 깊이 우선 탐색(Depth-First-Search) 알고리즘을 사용하며, 객체의 상태를 식별하기 위해 흰색(미발견), 회색(발견되었으나 이웃 미처리), 검은색(완전 처리됨)의 3색 분류 시스템을 사용합니다 [1].
-
-* **객체 그래프 변경과 쓰기 장벽(Write Barriers)의 역할:** 
-  점진적 마킹의 가장 큰 특징이자 과제는 마킹이 진행되는 동안 자바스크립트가 실행되어 힙 메모리의 객체 그래프가 지속적으로 변경될 수 있다는 점입니다 [2, 5]. 만약 가비지 컬렉터가 이미 탐색을 마친 '검은색' 객체에서 아직 탐색되지 않은 '흰색' 객체로 새로운 참조가 생성된다면, 살아있는 흰색 객체가 가비지로 잘못 분류될 위험이 있습니다 [5]. V8 엔진은 이를 해결하기 위해 쓰기 장벽(Write barrier)을 활용합니다 [5]. 쓰기 장벽은 검은색 객체에서 흰색 객체로의 포인터 생성을 감지하며, 해당 포인터가 감지되면 검은색 객체를 다시 회색으로 변경하고 마킹 데크(Deque)로 되돌려 보내 흰색 객체가 정상적으로 발견되도록 순서를 보존합니다 [5]. 
-
-* **다른 엔진에서의 구현 (IBM OpenJ9):**
-  IBM의 OpenJ9 VM에서는 'Balanced GC 정책'을 통해 점진적 동시 마킹(Incremental concurrent mark)을 지원합니다 [6]. 이 방식은 전역적인 STW(Stop-The-World)를 피하며 전체 힙에 걸쳐 마킹 작업을 점진적으로 수행합니다 [7]. 다른 정책의 동시 마킹과는 달리 애플리케이션 스레드가 객체 추적에 참여하지 않고 오직 백그라운드 스레드만이 객체를 추적하고 카드 테이블 내의 마크 맵(Mark map)을 업데이트하여 객체 변경을 관리합니다 [7].
-
-* **후속 단계 (지연 스위핑):**
-  점진적 마킹이 완료되어 힙 내 모든 객체의 생존 여부가 결정되면, 가비지 컬렉터는 지연 스위핑(Lazy sweeping)을 시작합니다 [8, 9]. 메모리를 즉시 한 번에 모두 비우는 대신, 필요할 때마다 필요한 만큼의 페이지를 정리함으로써 GC 주기를 완료하고 다음 점진적 마킹을 준비하게 됩니다 [8, 9].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[가비지 컬렉션(Garbage Collection)]], [[쓰기 장벽(Write barriers)]], [[지연 스위핑(Lazy sweeping)]]
-- **Projects/Contexts:** [[V8 JavaScript Engine]], [[Orinoco Garbage Collector]], [[IBM OpenJ9 (Balanced GC)]]
-- **Contradictions/Notes:** 점진적 마킹은 메인 스레드의 긴 일시 정지를 방지하고 응답성을 높이는 데에는 훌륭한 기법이지만, 메인 스레드에서 가비지 컬렉션에 소모되는 전체 시간을 줄여주지는 않으며 오히려 미세하게 증가시키는 경향이 있습니다 [2].
-
----
-*Last updated: 2026-04-19*
-- Raw Source: [[00_Raw/2026-04-20/점진적 마킹(Incremental marking).md]]
----
diff --git a/Programming & Language/정서적 고전적 조건 형성 (Emotional Classical Conditioning).md b/Programming & Language/정서적 고전적 조건 형성 (Emotional Classical Conditioning).md
deleted file mode 100644
index 513d9be6..00000000
--- a/Programming & Language/정서적 고전적 조건 형성 (Emotional Classical Conditioning).md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-BB4E76
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - 정서적 고전적 조건 형성 (Emotional Classical Conditioning)"
----
-
-# [[정서적 고전적 조건 형성 (Emotional Classical Conditioning)]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/정서적 고전적 조건 형성 (Emotional Classical Conditioning).md]]
----
diff --git a/Programming & Language/정신 의학적 진단 체계 (DSM-5_ICD-11).md b/Programming & Language/정신 의학적 진단 체계 (DSM-5_ICD-11).md
deleted file mode 100644
index 7122fece..00000000
--- a/Programming & Language/정신 의학적 진단 체계 (DSM-5_ICD-11).md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-4BDF5C
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - 정신 의학적 진단 체계 (DSM-5_ICD-11)"
----
-
-# [[정신 의학적 진단 체계 (DSM-5_ICD-11)]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/정신 의학적 진단 체계 (DSM-5_ICD-11).md]]
----
diff --git a/Programming & Language/정적 분석(Static Analysis).md b/Programming & Language/정적 분석(Static Analysis).md
deleted file mode 100644
index d2fb3c8d..00000000
--- a/Programming & Language/정적 분석(Static Analysis).md	
+++ /dev/null
@@ -1,46 +0,0 @@
----
-id: P-REINFORCE-AUTO-9D9335
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - 정적 분석(Static Analysis)"
----
-
-# [[정적 분석(Static Analysis)]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 정적 분석(Static Analysis) 또는 정적 애플리케이션 보안 테스트(SAST)는 프로그램을 직접 실행하지 않고 소스 코드나 바이트코드를 분석하여 오류나 취약점을 찾아내는 소프트웨어 검사 기술입니다 [1-3]. 소프트웨어 개발 수명 주기(SDLC)의 초기 단계에 적용되어 보안 취약점, 로직 결함, 코드 스타일 문제 등을 실행 전에 예방할 수 있는 '화이트 박스 테스트'의 일환으로 쓰입니다 [2, 4, 5]. 자동화된 도구를 통해 코딩 규칙을 강제하고 일관성을 확보함으로써 개발 팀의 협업 효율성을 높이고 유지보수성을 향상시키는 데 핵심적인 역할을 합니다 [6-8].
-
-## 📖 구조화된 지식 (Synthesized Content)
-*   **작동 방식 및 주요 분석 기법**
-    정적 분석 도구는 소스 코드를 파싱하여 추상 구문 트리(AST)를 생성한 뒤, 프로그램의 구조와 구문을 검사합니다 [9, 10]. 분석 과정에서 데이터 흐름(Data Flow) 추적, 외부의 신뢰할 수 없는 데이터가 민감한 함수에 도달하는지 확인하는 오염 분석(Taint Analysis), 의미론적 분석(Semantic Analysis) 및 구조적 분석 기법 등을 활용하여 SQL 주입, 크로스 사이트 스크립팅(XSS), 하드코딩된 비밀번호 등 다양한 논리적 결함과 보안 취약점을 탐지해 냅니다 [11-14].
-
-*   **정적 분석의 주요 장점**
-    *   **조기 발견 및 수정 (Shift-Left)**: IDE, 커밋 전(Pre-commit) 훅, 또는 CI/CD 파이프라인에 통합되어 실시간으로 코드를 스캔하므로, 결함이 프로덕션 환경에 도달하기 전인 초기 단계에서 빠르고 저렴하게 수정할 수 있습니다 [4, 15-17].
-    *   **빠른 속도와 일관성 유지**: 애플리케이션을 런타임으로 실행하거나 테스트 케이스를 별도로 작성할 필요 없이 작동하므로 스캔 속도가 매우 빠릅니다 [17]. 또한 피로도나 편견 없이 동일한 규칙을 전체 코드에 일관되게 적용할 수 있습니다 [18, 19].
-    *   **문제 발생 위치 특정**: 취약점이나 코드 냄새(Code Smell)가 발생한 소스 코드의 정확한 위치와 데이터 흐름을 짚어주어 문제의 원인 파악과 조치를 용이하게 합니다 [17, 20].
-
-*   **전통적 정적 분석의 한계**
-    *   **높은 오탐지율 (False Positives)**: 기존의 규칙 및 패턴 기반 정적 분석 도구는 코드의 문맥과 런타임 환경을 완벽히 이해하지 못해 최대 50~80%에 달하는 오탐지를 발생시킬 수 있으며, 이는 개발자에게 경고 피로(Alert Fatigue)를 유발합니다 [21-23].
-    *   **비즈니스 로직 이해 불가 (Context Blindness)**: 자동화된 정적 분석은 비즈니스 로직의 의도나 복잡한 아키텍처적 설계 맥락을 파악할 수 없기 때문에, 애플리케이션 흐름과 관련된 미묘한 논리적 오류를 놓치기 쉽습니다 [24, 25].
-    *   **언어 종속성**: 코드를 파싱하고 해석해야 하므로, 사용되는 프로그래밍 언어와 프레임워크마다 각각 전용 파서 및 탐지 규칙을 구비해야만 동작합니다 [22, 26].
-
-*   **AI 기반 정적 분석으로의 진화**
-    *   최근의 정적 분석은 대규모 오픈소스 데이터를 학습한 머신러닝(ML) 및 대형 언어 모델(LLM)과 결합되어, 단순한 구문 규칙을 넘어 의미론적 인지 능력(Semantic Understanding)을 갖춘 도구로 진화하고 있습니다 [12, 27, 28].
-    *   파일 및 모듈 경계를 넘나드는 파일 간 분석(Interfile Analysis)과 실제로 코드가 실행 경로에 포함되는지 확인하는 도달 가능성(Reachability) 분석을 통해 오탐지를 획기적으로 낮추었습니다 [28-30].
-    *   취약점을 탐지하는 데 그치지 않고, 개발자가 검토 및 적용할 수 있는 구체적인 **자동 수정(Auto-remediation / Autofix) 코드**를 제안함으로써 취약점 해결 시간(MTTR)을 크게 단축시키는 방향으로 발전하고 있습니다 [31-34].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[수동 코드 리뷰(Manual Code Review)]], [[DAST(Dynamic Application Security Testing)]], [[SCA(Software Composition Analysis)]], [[Linting / Formatter]]
-- **Projects/Contexts:** [[Snyk Code]], [[SonarQube]], [[Checkmarx]], [[ESLint / Prettier]]
-- **Contradictions/Notes:** 소스 [35], [24], [36] 등은 자동화된 정적 분석 도구가 코드를 빠르고 일관되게 스캔하지만 비즈니스 로직이나 의도를 파악하는 데는 맹점이 있다고 지적합니다. 따라서 자동화 도구에만 의존해서는 안 되며, 보안 맥락과 아키텍처 트레이드오프를 평가하기 위해 반드시 인간의 통찰력이 개입되는 '수동 코드 리뷰(Manual Code Review)'를 결합한 하이브리드 접근법을 취해야 한다고 권장합니다.
-
----
-*Last updated: 2026-04-19*
-- Raw Source: [[00_Raw/2026-04-20/정적 분석(Static Analysis).md]]
----
diff --git a/Programming & Language/제어 흐름 분석 (Control Flow Analysis).md b/Programming & Language/제어 흐름 분석 (Control Flow Analysis).md
deleted file mode 100644
index e9529183..00000000
--- a/Programming & Language/제어 흐름 분석 (Control Flow Analysis).md	
+++ /dev/null
@@ -1,32 +0,0 @@
----
-id: P-REINFORCE-AUTO-9FF9A4
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - 제어 흐름 분석 (Control Flow Analysis)"
----
-
-# [[제어 흐름 분석 (Control Flow Analysis)]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 제어 흐름 분석(Control Flow Analysis)은 TypeScript가 코드의 실행 흐름을 파악하여 변수의 타입을 더 구체적으로 좁혀나가는(Narrowing) 메커니즘입니다 [1]. 주로 `if`나 `switch` 문과 같은 조건 블록 내에서 타입 가드(Type Guard)를 이해하고 적용하는 데 핵심적인 역할을 합니다 [1]. 이 분석을 통해 컴파일러는 여러 가능성이 있는 객체 집합을 단일한 특정 객체 타입으로 좁혀서(Code flow analysis) 안전하게 취급할 수 있도록 만듭니다 [2].
-
-## 📖 구조화된 지식 (Synthesized Content)
-* **타입 좁히기(Type Narrowing)의 메커니즘:** TypeScript의 제어 흐름 분석은 코드 내에서 사용된 타입 가드를 인식하고 이를 기반으로 제어 흐름 내부의 타입을 추론합니다 [1]. `typeof` 검사, `instanceof`, 동등성 검사(equality checks), `in` 연산자 등이 제어 흐름 분석이 이해할 수 있는 타입 가드에 해당합니다 [1]. 예를 들어, `if (typeof x === 'string')`이라는 조건문 블록 내부에서 제어 흐름 분석은 변수 `x`를 안전하게 `string` 타입으로 취급하게 해줍니다 [1].
-* **식별 가능한 유니온(Discriminated Unions)에서의 활용:** 제어 흐름 분석은 애플리케이션의 상태를 모델링할 때 자주 쓰이는 식별 가능한 유니온 패턴과 결합하여 강력한 효과를 발휘합니다 [2, 3]. 객체 타입들이 공유하는 공통 리터럴 속성(판별자)을 `switch`나 `if` 문으로 검사하면, TypeScript는 해당 제어 흐름을 분석하여 각 분기(branch)마다 안전하게 특정 타입으로 범위를 축소하여 타입별 속성에 접근할 수 있도록 돕습니다 [2, 3]. 
-* *참고: 소스 내에 제어 흐름 분석이 작동하는 컴파일러 수준의 심층적인 내부 원리나 추가적인 기술 명세에 대한 관련 정보는 부족합니다.*
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[타입 좁히기 (Type Narrowing)]], [[타입 가드 (Type Guards)]], [[식별 가능한 유니온 (Discriminated Unions)]]
-- **Projects/Contexts:** [[TypeScript 상태 모델링 및 에러 처리 맥락]] (로딩, 성공, 에러와 같은 상태나 유사한 객체들의 집합을 `switch`문 등을 통해 구체적인 타입으로 좁혀서 런타임 오류 없이 안전하게 다뤄야 하는 프로젝트 환경 [2, 3])
-- **Contradictions/Notes:** 주어진 소스 내에서 제어 흐름 분석에 대한 개념들 간의 모순점은 발견되지 않았으나, 해당 주제를 더 깊게 이해하기 위한 구체적인 동작 구조 정보는 부족합니다.
-
----
-*Last updated: 2026-04-18*
-- Raw Source: [[00_Raw/2026-04-20/제어 흐름 분석 (Control Flow Analysis).md]]
----
diff --git a/Programming & Language/조작적 조건 형성 (Operant Conditioning).md b/Programming & Language/조작적 조건 형성 (Operant Conditioning).md
deleted file mode 100644
index 374937e9..00000000
--- a/Programming & Language/조작적 조건 형성 (Operant Conditioning).md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-901DFC
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - 조작적 조건 형성 (Operant Conditioning)"
----
-
-# [[조작적 조건 형성 (Operant Conditioning)]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/조작적 조건 형성 (Operant Conditioning).md]]
----
diff --git a/Programming & Language/조작적 조건 형성.md b/Programming & Language/조작적 조건 형성.md
deleted file mode 100644
index 4a5a7c52..00000000
--- a/Programming & Language/조작적 조건 형성.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-05C66E
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - 조작적 조건 형성"
----
-
-# [[조작적 조건 형성]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/조작적 조건 형성.md]]
----
diff --git a/Programming & Language/조작적 조건형성.md b/Programming & Language/조작적 조건형성.md
deleted file mode 100644
index a10f877d..00000000
--- a/Programming & Language/조작적 조건형성.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-C7CA1A
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - 조작적 조건형성"
----
-
-# [[조작적 조건형성]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/조작적 조건형성.md]]
----
diff --git a/Programming & Language/조절-폭주 불일치 (Vergence-Accommodation Conflict).md b/Programming & Language/조절-폭주 불일치 (Vergence-Accommodation Conflict).md
deleted file mode 100644
index 71ef0d81..00000000
--- a/Programming & Language/조절-폭주 불일치 (Vergence-Accommodation Conflict).md	
+++ /dev/null
@@ -1,32 +0,0 @@
----
-id: P-REINFORCE-AUTO-747672
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - 조절-폭주 불일치 (Vergence-Accommodation Conflict)"
----
-
-# [[조절-폭주 불일치 (Vergence-Accommodation Conflict)]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 조절-폭주 불일치(Vergence-Accommodation Conflict)는 가상현실(VR) 헤드마운트 디스플레이(HMD) 환경에서 주로 관찰되는 시각적 문제로, 자연스러운 상태에서 함께 작용하는 폭주와 조절이라는 안구 운동 기능이 상호 분리되면서 발생하는 현상입니다 [1, 2]. 자연적인 시각 조건에서는 이 두 기능이 피드백 루프를 통해 동반 변화하여 가까운 대상에 선명한 초점을 맺도록 돕지만, HMD 기기 내에서는 이 연결이 끊어지게 됩니다 [2]. 이러한 시각적 불일치는 깊이 지각을 위한 망막 단서의 불확실성을 초래하며, 눈의 피로, 두통, VR 멀미 등의 원인으로 지목되고 있습니다 [1, 2].
-
-## 📖 구조화된 지식 (Synthesized Content)
-- **폭주와 조절의 자연적 메커니즘:** 폭주(Vergence)와 조절(Accommodation)은 가까운 대상에 단일하고 명확한 초점을 달성하기 위해 필수적인 안구 운동 기능입니다 [2]. 자연스러운 시야 환경에서는 흐림(blur)과 양안 시차(disparity) 같은 망막 단서의 도움을 받아 피드백 루프 속에서 두 기능이 함께 작동하므로, 하나의 기능 변화가 다른 기능의 동시 변화를 이끌어냅니다 [2].
-- **가상현실(HMD) 환경에서의 분리:** 헤드마운트 디스플레이(HMD)에서는 앞서 언급된 자연적인 폭주와 조절의 결합이 분리(decoupled)되는 현상이 발생합니다 [2]. 이러한 분리 현상은 결과적으로 깊이 지각을 위한 망막 단서 활용에 있어 불확실성을 야기하는 조절-폭주 불일치로 이어집니다 [2].
-- **신체적 증상 및 부작용:** 이 불일치는 두통, 눈의 통증(sore eyes), 피로, 복시(double vision) 등 여러 안구 운동 관련 동반 증상들을 유발할 수 있습니다 [1, 2]. 또한, 일반적으로 자기 보고되는 멀미 증상 외에도 사용자의 깊이 지각 능력과 인지 기능까지 악화시킬 수 있습니다 [1].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[가상현실 멀미 (VR Sickness)]], [[헤드마운트 디스플레이 (HMD)]], [[깊이 지각 (Depth Perception)]], [[안구 운동 기능 (Oculomotor Functions)]]
-- **Projects/Contexts:** [[가상현실 후유증 (Virtual Reality Aftereffects)]]
-- **Contradictions/Notes:** 소스에 따르면 조절-폭주 불일치가 특정 개인의 가상현실 멀미(VR sickness)를 유발하는 직접적 원인인지, 아니면 멀미 증상의 심각성을 가중시키는 요인인지에 대해서는 아직 명확히 밝혀지지 않았습니다 [1].
-
----
-*Last updated: 2026-04-19*
-- Raw Source: [[00_Raw/2026-04-20/조절-폭주 불일치 (Vergence-Accommodation Conflict).md]]
----
diff --git a/Programming & Language/조절-폭주 불일치(Vergence-Accommodation Conflict).md b/Programming & Language/조절-폭주 불일치(Vergence-Accommodation Conflict).md
deleted file mode 100644
index ac746fc9..00000000
--- a/Programming & Language/조절-폭주 불일치(Vergence-Accommodation Conflict).md	
+++ /dev/null
@@ -1,33 +0,0 @@
----
-id: P-REINFORCE-AUTO-4FA83F
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - 조절-폭주 불일치(Vergence-Accommodation Conflict)"
----
-
-# [[조절-폭주 불일치(Vergence-Accommodation Conflict)]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 조절-폭주 불일치(Vergence-Accommodation Conflict)는 가상현실의 머리 착용 디스플레이(HMD)를 사용할 때 발생하는 시각적 깊이 단서의 충돌 현상이다 [1, 2]. 자연스러운 시각 환경에서 함께 작동하는 안구의 조절(accommodation)과 폭주(vergence) 기능이 HMD 환경에서는 분리(decoupled)되면서 발생한다 [2]. 이로 인해 깊이 지각에 대한 불확실성이 커지며, 두통, 안구 통증, 시각적 피로, 복시 및 가상현실 멀미와 같은 다양한 시각적·인지적 후유증이 유발될 수 있다 [1, 2].
-
-## 📖 구조화된 지식 (Synthesized Content)
-* **발생 원인 및 메커니즘:** 가까운 물체에 정확하게 단일 초점을 맞추기 위해 조절(Accommodation)과 폭주(Vergence)는 필수적인 안구 운동 기능이다 [2]. 일반적으로 자연스러운 시각 환경에서는 두 기능이 피드백 루프 안에서 함께 작용하여 한쪽의 변화가 다른 쪽의 변화를 동시에 이끌어낸다 [2]. 그러나 HMD 환경에서는 시각적인 깊이 단서들이 충돌하면서 조절과 폭주 기능이 서로 분리(decoupled)되는 현상이 발생한다 [1, 2].
-* **시각적 깊이 지각의 불확실성 증가:** 망막의 흐림(blur)과 양안 시차(disparity)는 조절과 폭주가 목표물에 정확하게 시선을 고정하도록 돕는 핵심적인 망막 단서(retinotopic cues)이다 [2]. 조절-폭주 불일치는 이러한 깊이 지각 단서에 대한 불확실성을 초래하여 시각 체계에 혼란을 준다 [2].
-* **시각적 및 인지적 후유증 유발:** 조절-폭주 불일치는 시각적 성능을 저해하고 시각적 피로를 유발한다 [1, 3]. 이로 인해 두통, 안구 통증, 피로감, 복시(double vision)와 같은 동반 증상이 나타날 가능성이 높으며, 결과적으로 HMD 사용 시 나타나는 안구 운동 증상(oculomotor symptoms)을 증가시킨다 [1, 2].
-* **가상현실 멀미(VR Sickness)와의 관계:** 이 불일치 현상이 특정 개인들에게 가상현실 멀미를 유발하는 직접적 원인으로 작용하는지, 아니면 단순히 멀미 증상의 심각성을 가중시키는 요인인지는 명확히 규명되지 않았다 [1].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[가상현실 멀미(VR Sickness)]], [[안구 운동 증상(Oculomotor Symptoms)]], [[깊이 지각(Depth Perception)]]
-- **Projects/Contexts:** [[머리 착용 디스플레이(HMD) 시각 연구]], [[가상현실 엑서게임(Exergaming) 후유증 연구]]
-- **Contradictions/Notes:** 소스에 따르면 조절-폭주 불일치가 사람들에게 VR 멀미를 유발하는 직접적인 원인인지, 아니면 기존의 멀미 증상을 심화시키는 역할을 하는지에 대해서는 아직 분명하지 않다(unclear)고 지적하고 있다 [1].
-
----
-*Last updated: 2026-04-19*
-- Raw Source: [[00_Raw/2026-04-20/조절-폭주 불일치(Vergence-Accommodation Conflict).md]]
----
diff --git a/Programming & Language/조직 개발(OD) 프로그램 설계.md b/Programming & Language/조직 개발(OD) 프로그램 설계.md
deleted file mode 100644
index d6eb7cff..00000000
--- a/Programming & Language/조직 개발(OD) 프로그램 설계.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-E12DC4
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - 조직 개발(OD) 프로그램 설계"
----
-
-# [[조직 개발(OD) 프로그램 설계]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/조직 개발(OD) 프로그램 설계.md]]
----
diff --git a/Programming & Language/조직 행동 관리(OBM).md b/Programming & Language/조직 행동 관리(OBM).md
deleted file mode 100644
index 633d2d27..00000000
--- a/Programming & Language/조직 행동 관리(OBM).md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-532605
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - 조직 행동 관리(OBM)"
----
-
-# [[조직 행동 관리(OBM)]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/조직 행동 관리(OBM).md]]
----
diff --git a/Programming & Language/조직 행동론 및 직무 만족도 연구.md b/Programming & Language/조직 행동론 및 직무 만족도 연구.md
deleted file mode 100644
index 8462dc3e..00000000
--- a/Programming & Language/조직 행동론 및 직무 만족도 연구.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-2FE438
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - 조직 행동론 및 직무 만족도 연구"
----
-
-# [[조직 행동론 및 직무 만족도 연구]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/조직 행동론 및 직무 만족도 연구.md]]
----
diff --git a/Programming & Language/중뇌-변연계 경로 (Mesolimbic Pathway).md b/Programming & Language/중뇌-변연계 경로 (Mesolimbic Pathway).md
deleted file mode 100644
index 5802f770..00000000
--- a/Programming & Language/중뇌-변연계 경로 (Mesolimbic Pathway).md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-D5E4BD
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - 중뇌-변연계 경로 (Mesolimbic Pathway)"
----
-
-# [[중뇌-변연계 경로 (Mesolimbic Pathway)]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/중뇌-변연계 경로 (Mesolimbic Pathway).md]]
----
diff --git a/Programming & Language/지식 그래프 (Knowledge Graph).md b/Programming & Language/지식 그래프 (Knowledge Graph).md
deleted file mode 100644
index 520a1117..00000000
--- a/Programming & Language/지식 그래프 (Knowledge Graph).md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-276A1A
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - 지식 그래프 (Knowledge Graph)"
----
-
-# [[지식 그래프 (Knowledge Graph)]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/지식 그래프 (Knowledge Graph).md]]
----
diff --git a/Programming & Language/직무 특성 모델 (Job Characteristics Model).md b/Programming & Language/직무 특성 모델 (Job Characteristics Model).md
deleted file mode 100644
index 50acb412..00000000
--- a/Programming & Language/직무 특성 모델 (Job Characteristics Model).md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-599CE0
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - 직무 특성 모델 (Job Characteristics Model)"
----
-
-# [[직무 특성 모델 (Job Characteristics Model)]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/직무 특성 모델 (Job Characteristics Model).md]]
----
diff --git a/Programming & Language/집합론 (Set Theory).md b/Programming & Language/집합론 (Set Theory).md
deleted file mode 100644
index bf4e5911..00000000
--- a/Programming & Language/집합론 (Set Theory).md	
+++ /dev/null
@@ -1,45 +0,0 @@
----
-id: P-REINFORCE-AUTO-20C803
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - 집합론 (Set Theory)"
----
-
-# [[집합론 (Set Theory)]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 집합론(Set Theory)은 객체들의 순서 없는 모임(unordered collections of objects)을 다루는 수학적 이론입니다 [1]. TypeScript의 맥락에서 집합론은 '타입(Type)'을 JavaScript 값들의 집합으로 이해하고 해석하는 모델로 사용됩니다 [2, 3]. 이를 통해 서브타입(subtype), 유니언(union), 인터섹션(intersection) 등의 복잡한 타입 시스템 동작 원리를 부분집합, 합집합, 교집합과 같은 수학적 집합 개념으로 명확하게 설명할 수 있습니다 [2, 4, 5].
-
-## 📖 구조화된 지식 (Synthesized Content)
-*   **집합의 기본 개념 및 관계**
-    *   **집합과 우주(Universe):** 집합은 중괄호(`{}`)로 표현되는 항목들의 모임이며, 요소가 하나도 없는 빈 집합(empty set)은 `∅`로 표기합니다 [1]. 존재하는 모든 가능한 값들을 포함하는 세계를 우주(universe)라고 부릅니다 [1].
-    *   **부분집합(Subset):** 집합 A의 모든 요소가 집합 B에도 포함되어 있다면, A는 B의 부분집합이 됩니다 [6]. 빈 집합은 자기 자신을 포함한 모든 집합의 부분집합으로 간주됩니다 [6, 7].
-
-*   **집합의 핵심 연산**
-    *   **합집합(Union, $\cup$):** 두 집합 A와 B 중 하나라도 속하는 모든 요소를 포함하는 집합입니다 [4].
-    *   **교집합(Intersection, $\cap$):** 두 집합 A와 B 모두에 공통으로 속하는 요소들만의 집합입니다 [4].
-    *   **차집합(Difference, $\setminus$):** 집합 A에는 속하지만 집합 B에는 속하지 않는 요소들의 집합입니다 [4].
-
-*   **TypeScript 타입 시스템과의 매핑 (Set Theory in TypeScript)**
-    *   **타입과 값의 집합:** TypeScript의 타입은 프로그램이 생성할 수 있는 모든 JavaScript 값들의 집합으로 치환하여 생각할 수 있습니다 [2, 3]. `unknown` 타입은 모든 JS 값들의 집합(우주)이며, `never` 타입은 빈 집합(empty set, ∅)에 해당합니다 [2, 5].
-    *   **부분집합과 할당(extends):** TypeScript에서 타입 A가 타입 B의 부분집합일 때(`A extends B`), A는 B에 할당 가능합니다 [2, 3]. 즉, 서브타입(subtype, 좁혀진 타입)은 부분집합(subset)에 해당하고, 슈퍼타입(supertype, 넓혀진 타입)은 상위집합(superset)에 해당합니다 [5, 8].
-    *   **타입 연산자와 집합 연산의 일치:** 
-        *   유니언 타입(`|`)은 집합의 합집합 연산자로 작동합니다 [2].
-        *   인터섹션 타입(`&`)은 집합의 교집합 연산자로 작동합니다 [2].
-        *   `Exclude<A, B>` 유틸리티 타입은 유니언 타입에 한해 집합의 차집합 기능과 유사하게 동작합니다 [2, 5].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[TypeScript Type System]], [[Structural Typing]], [[Union and Intersection Types]]
-- **Projects/Contexts:** [[TypeScript의 타입 연산과 조건부 타입(Conditional Types)의 동작 원리 이해 및 인터페이스 설계]]
-- **Contradictions/Notes:** 객체(Object) 타입에 대한 `&`(인터섹션) 연산이나 `|`(유니언) 연산은 객체의 형태(Shape)를 단순히 결합하는 것이 아니라, 해당 객체 형태를 만족하는 '값들의 집합'에 대한 교집합 및 합집합 연산으로 작동합니다. 따라서 `{ name: string } & { age: number }`는 두 속성을 모두 가진 객체들의 교집합을 의미하게 됩니다 [9, 10].
-
----
-*Last updated: 2026-04-18*
-- Raw Source: [[00_Raw/2026-04-20/집합론 (Set Theory).md]]
----
diff --git a/Programming & Language/집합론(Set Theory).md b/Programming & Language/집합론(Set Theory).md
deleted file mode 100644
index 677e5a40..00000000
--- a/Programming & Language/집합론(Set Theory).md	
+++ /dev/null
@@ -1,35 +0,0 @@
----
-id: P-REINFORCE-AUTO-1B9760
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - 집합론(Set Theory)"
----
-
-# [[집합론(Set Theory)]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 집합론(Set Theory)은 TypeScript의 타입 시스템을 이해하는 핵심적인 철학이자 접근 방식으로, 타입을 가능한 자바스크립트 값들의 '집합'으로 간주하는 개념입니다 [1, 2]. 이 관점을 통해 타입 간의 호환성, 합집합과 교집합 연산, 그리고 타입의 서브타입(Subtype) 및 슈퍼타입(Supertype) 관계를 수학적 집합의 원리로 명확하게 설명할 수 있습니다 [2-5].
-
-## 📖 구조화된 지식 (Synthesized Content)
-- **타입과 집합의 매핑 (Mapping Types to Sets)**: TypeScript에서 모든 타입은 자바스크립트 값들의 집합으로 이해될 수 있습니다 [1, 2]. 예를 들어, `string` 타입은 가능한 모든 문자열의 집합을 뜻하며, 특정 인터페이스 타입은 해당 구조를 만족하는 모든 객체의 집합입니다 [2]. 또한 `boolean`은 `true`와 `false` 단 두 개의 값만 포함하는 집합입니다 [5]. 세상의 모든 자바스크립트 값을 포함하는 전체 집합(Universe)은 `unknown` 타입에 해당하며, 아무런 값도 포함하지 않는 공집합(Empty Set, ∅)은 `never` 타입으로 대응됩니다 [1, 6, 7].
-- **부분집합과 타입 호환성 (Subsets and Compatibility)**: 집합론에서 집합 A의 모든 요소가 집합 B에 포함될 때 A를 B의 부분집합이라고 정의합니다 [4]. 이를 TypeScript에 적용하면, 타입 A가 타입 B의 부분집합($A \subseteq B$)일 때 A는 B에 할당 가능한(assignable) 호환성을 가집니다 [2]. 즉, 서브타입(Subtype)은 부분집합(subset)으로, 슈퍼타입(Supertype)은 상위집합(superset)으로 이해할 수 있습니다 [5, 7]. 제네릭이나 조건부 타입에서 자주 사용되는 `A extends B` 문법 역시 "A가 B의 부분집합이다"라는 수학적 의미로 정확히 해석할 수 있습니다 [1, 7, 8].
-- **집합 연산자 (Set Operators)**: TypeScript의 타입 조합 연산은 집합의 수학적 연산과 일치하게 동작합니다 [1, 7].
-  - **합집합(Union, ∪)**: `|` 연산자로 표현되며, A 또는 B에 속한 모든 요소를 포함하는 집합을 만듭니다 [1, 4].
-  - **교집합(Intersection, ∩)**: `&` 연산자로 표현되며, A와 B 모두에 존재하는 요소를 포함하는 집합을 만듭니다 [1, 4].
-  - **차집합(Difference, \)**: TypeScript의 `Exclude<A, B>` 유틸리티 타입이 차집합과 근사하게 동작하여, A에는 있지만 B에는 없는 요소를 추출합니다 (단, 유니온 타입에서만 작동) [1, 4, 7].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[TypeScript Type System]], [[Structural Typing]], [[Union and Intersection Types]]
-- **Projects/Contexts:** [[TypeScript Interface Design]], [[Type Narrowing and Widening]]
-- **Contradictions/Notes:** TypeScript의 `any` 타입은 집합론으로 완벽히 설명되지 않는 예외적인 존재입니다. 모든 세트를 부분집합으로 허용하면서도 동시에 스스로가 비어있을 수(`never`) 있는 '역설적인(paradoxical)' 집합으로 동작하기 때문에 일반적인 집합론의 논리를 따르지 않습니다 [7, 9].
-
----
-*Last updated: 2026-04-18*
-- Raw Source: [[00_Raw/2026-04-20/집합론(Set Theory).md]]
----
diff --git a/Programming & Language/철벽 수비대 인터페이스 설계 전략.md b/Programming & Language/철벽 수비대 인터페이스 설계 전략.md
deleted file mode 100644
index ea52c8e1..00000000
--- a/Programming & Language/철벽 수비대 인터페이스 설계 전략.md	
+++ /dev/null
@@ -1,35 +0,0 @@
----
-id: P-REINFORCE-AUTO-CE3C8E
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - 철벽 수비대 인터페이스 설계 전략"
----
-
-# [[철벽 수비대 인터페이스 설계 전략]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 철벽 수비대 인터페이스 설계 전략은 대규모 애플리케이션 개발 시 발생하는 런타임 에러와 무분별한 상태 변경의 불확실성을 방어하기 위한 TypeScript 아키텍처 방법론입니다 [1]. 이 전략은 구조적 타이핑의 유연함을 살리면서도 과잉 속성 체크, 불변성, 식별 가능한 유니온 등의 강력한 수비 기제를 통해 의도치 않은 데이터 유입과 예기치 않은 상태 변경을 차단합니다 [1-4]. 또한, 인터페이스와 타입 별칭의 전략적 분리, 브랜디드 타입을 적극적으로 활용하여 비즈니스 로직을 엄격하게 보호합니다 [5, 6]. 궁극적으로 이 설계 전략은 개발자에게 심리적 안전감을 제공하고, 확장에 열려 있으면서도 변화에 따른 부작용을 최소화하는 견고한 시스템 구축을 목표로 합니다 [7, 8].
-
-## 📖 구조화된 지식 (Synthesized Content)
-* **정적 타입 시스템과 구조적 타이핑의 방어 기제:** TypeScript는 객체의 실제 형태가 일치하면 호환성을 인정하는 구조적 타이핑(Structural Typing)을 기반으로 작동합니다 [1]. 이로 인해 발생할 수 있는 의도하지 않은 데이터 유입은 과잉 속성 체크(Excess Property Checking, EPC)를 통해 객체 리터럴 할당 시 인터페이스에 없는 속성을 차단함으로써 1차적으로 방어합니다 [2].
-* **인터페이스(Interface)와 타입 별칭(Type Alias)의 전략적 분리:** 도메인 모델이나 API 계약처럼 외부와의 소통이 잦은 지점에는 컴파일 성능 캐싱과 선언 병합(Declaration Merging)에 유리한 인터페이스를 사용합니다 [5, 9]. 반면, 예기치 않은 병합을 방지하고 더 엄격한 관리가 필요한 핵심 비즈니스 로직에는 타입 별칭을 사용하는 이원화 전략을 취합니다 [9]. 깊은 상속 계층 구조보다는 작은 단위의 인터페이스를 합성(Composition)하는 방식이 변화에 더 견고합니다 [9].
-* **불변성(Immutability) 확립:** 데이터 오염을 막기 위해 `readonly` 수식어를 적극적으로 사용하여 컴파일 수준에서 객체와 배열의 수정을 금지합니다 [3]. 단순한 얕은 보호를 넘어, 복잡한 중첩 객체의 모든 속성이 변경되지 않도록 매핑 타입 등을 활용한 `DeepReadonly` 재귀적 불변성을 구축해야 합니다 [4].
-* **식별 가능한 유니온과 완전성 검사(Exhaustiveness Checking):** 공통된 리터럴 속성을 태그로 활용하여 타입 좁히기(Narrowing)를 수행하고 불가능한 상태를 코드에서 원천적으로 배제합니다 [4, 10]. 특히 `never` 타입을 활용해 처리되지 않은 새로운 상태가 추가될 경우 컴파일 에러를 발생시켜 빈틈없는 방어 체계를 유지합니다 [10].
-* **브랜디드 타입(Branded Types)을 통한 명목적 타이핑 수복:** 구조적 타이핑의 약점인 '기본 타입에의 집착' 문제를 해결하기 위해, 컴파일 시점에만 존재하는 고유한 표식(브랜드)을 타입에 부여합니다 [6]. 이를 통해 사용자 ID나 이메일처럼 구조는 같지만 의미가 다른 데이터를 엄격하게 분리하고 오염을 방지합니다 [6, 11].
-* **satisfies 연산자 및 아키텍처 원칙:** 변수의 간접 할당으로 인해 과잉 속성 체크가 우회되는 취약점은 `satisfies` 연산자를 활용하여 해결합니다 [11, 12]. 이를 통해 객체의 구체적인 리터럴 타입 정보를 유지하면서도 타입 안전성을 검증합니다 [12]. 궁극적으로 단일 책임 원칙(SRP)과 인터페이스 분리 원칙(ISP)에 따라 시스템을 설계하며, 데이터를 단순히 검증하는 것을 넘어 안전한 타입으로 파싱하여 전달하는 원칙을 고수합니다 [7].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[구조적 타이핑]], [[과잉 속성 체크(EPC)]], [[식별 가능한 유니온]], [[브랜디드 타입]], [[불변성(Immutability)]], [[satisfies 연산자]], [[SOLID 원칙]]
-- **Projects/Contexts:** [[대규모 애플리케이션 개발]], [[도메인 기반 설계(DDD)]], [[토스(Toss) SDK 설계]]
-- **Contradictions/Notes:** 과잉 속성 체크(EPC)는 객체 리터럴을 직접 할당할 때만 작동하고 변수 간접 할당 시 우회되는 약점이 존재하나, 이는 `satisfies` 연산자를 도입하여 우아하게 해결할 수 있습니다 [11, 12]. 또한 TypeScript는 인터페이스의 선언 병합을 허용하여 확장에 용이하지만 이로 인한 의도치 않은 병합의 위험이 존재하므로, 핵심 로직에서는 재선언이 불가한 타입 별칭(Type Alias)을 혼용하는 전략이 필수적입니다 [5, 9].
-
----
-*Last updated: 2026-04-18*
-- Raw Source: [[00_Raw/2026-04-20/철벽 수비대 인터페이스 설계 전략.md]]
----
diff --git a/Programming & Language/철벽 수비대_ TypeScript 타입 시스템과 견고한 인터페이스 설계의 정수.md b/Programming & Language/철벽 수비대_ TypeScript 타입 시스템과 견고한 인터페이스 설계의 정수.md
deleted file mode 100644
index 29b37799..00000000
--- a/Programming & Language/철벽 수비대_ TypeScript 타입 시스템과 견고한 인터페이스 설계의 정수.md	
+++ /dev/null
@@ -1,43 +0,0 @@
----
-id: P-REINFORCE-AUTO-31F1D8
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - 철벽 수비대_ TypeScript 타입 시스템과 견고한 인터페이스 설계의 정수"
----
-
-# [[철벽 수비대_ TypeScript 타입 시스템과 견고한 인터페이스 설계의 정수]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> TypeScript는 자바스크립트의 유연함이 초래하는 런타임 에러의 불확실성을 극복하기 위해 도입된 정적 타입 시스템으로, 복잡한 비즈니스 로직을 보호하는 철벽 수비대와 같은 역할을 수행한다 [1]. 이 시스템은 구조적 타이핑(Structural Typing)을 기반으로 객체의 형태에 따라 타입을 결정하며, 개발자의 의도를 명확히 규정하는 아키텍처 도구로 작용한다 [1, 2]. 효과적인 방어 체계 구축을 위해 개발자는 인터페이스와 타입 별칭의 전략적 분리, 불변성(readonly)의 확립, 식별 가능한 유니온 및 브랜디드 타입과 같은 고급 기법을 활용하여 외부의 오염된 데이터와 예기치 않은 상태 변경으로부터 시스템을 안전하게 지켜낼 수 있다 [1, 3-5].
-
-## 📖 구조화된 지식 (Synthesized Content)
-*   **구조적 타이핑과 방어선의 구축 (Structural Typing & EPC):**
-    TypeScript는 명목적 타이핑(Nominal Typing)을 사용하는 Java 등과 달리, 객체의 구조가 일치하면 호환성을 인정하는 구조적 타이핑(일명 덕 타이핑)을 채택하여 유연성을 제공한다 [1, 2, 6, 7]. 이 유연성이 야기할 수 있는 의도치 않은 데이터 유입을 막기 위해 '과잉 속성 체크(Excess Property Checking, EPC)'를 수행하지만, 이는 변수에 간접 할당될 때 우회될 수 있는 한계가 있다 [2, 7-9]. 이를 해결하기 위해 `satisfies` 연산자를 활용하면, 객체가 특정 인터페이스를 만족하는지 검사하면서도 리터럴 타입 등의 구체적인 정보를 유지해 런타임 오류를 차단하는 엄격한 속성 검사가 가능하다 [9-13].
-
-*   **Interface와 Type Alias의 전략적 활용:**
-    타입의 형태를 정의하는 인터페이스(Interface)와 타입 별칭(Type Alias)은 성능과 확장성 면에서 구분하여 사용해야 한다 [14, 15]. 컴파일러는 인터페이스를 처리할 때 이름을 기준으로 관계를 캐싱하므로, 도메인 모델이나 API 계약 등 핵심 객체 정의에는 성능 최적화를 위해 인터페이스를 사용하는 것이 좋다 [15-18]. 반면, 인터페이스의 선언 병합(Declaration Merging) 기능으로 인한 예기치 않은 구조 변경을 피해야 하는 닫힌 비즈니스 로직이나 복잡한 교집합 타입에는 타입 별칭을 사용하는 이원화 전략이 요구된다 [14, 15, 19-21]. 또한, 깊은 상속보다는 작은 인터페이스를 조합하는 '합성(Composition)'이 설계에 있어 더 유연한 수비력을 제공한다 [21, 22].
-
-*   **불변성(Immutability) 확립을 통한 상태 보호:**
-    예기치 않은 상태 변경은 시스템의 예측 가능성을 해친다. TypeScript는 `readonly` 수식어를 통해 컴파일 타임에 객체와 배열의 수정을 원천적으로 차단하여 데이터의 무결성을 보장한다 [3, 23-26]. 기본 `readonly`는 얕은(shallow) 보호만 제공하므로, 객체 내부의 중첩된 구조까지 철저히 보호하기 위해서는 매핑 타입과 조건부 타입을 결합한 재귀적 `DeepReadonly<T>` 패턴을 구축하여 사용해야 한다 [3, 4, 27-29].
-
-*   **식별 가능한 유니온과 브랜디드 타입을 활용한 철벽 검증:**
-    식별 가능한 유니온(Discriminated Unions)은 공통된 태그 속성(예: `kind`, `status`)을 통해 런타임 타입 체크의 수고를 덜고 컴파일러가 타입을 좁히도록(Narrowing) 돕는다 [4, 30-34]. 여기에 `never` 타입을 활용한 완전성 검사(Exhaustiveness Checking)를 적용하면 처리되지 않은 상태를 컴파일 에러로 포착해 "불가능한 상태를 표현 불가능하게" 만들 수 있다 [4, 34-38]. 아울러, 구조적 타이핑의 맹점인 '기본 타입에의 집착'을 극복하기 위해 브랜디드 타입(Branded Types)을 적용, 컴파일 시점에만 존재하는 고유한 브랜드 표식을 부여함으로써 이메일, ID 등의 데이터를 명확히 격리하고 오염을 방지한다 [5, 9, 39-43].
-
-*   **SOLID 원칙 기반의 아키텍처적 완성:**
-    견고한 타입 시스템은 단일 책임 원칙(SRP)과 인터페이스 분리 원칙(ISP)을 지키는 퍼사드(Facade) 패턴 등의 소프트웨어 설계 원칙과 융합될 때 진가를 발휘한다 [13, 44-49]. 데이터를 단순히 검증하는 것을 넘어 신뢰할 수 있는 타입으로 파싱하여 전달하는 "Parse, Don't Validate" 철학을 실천함으로써 예측 가능성을 극대화하고 변화에 유연한 지속 가능한 시스템 구축이 가능해진다 [49-52].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[구조적 타이핑 (Structural Typing)]], [[과잉 속성 체크 (Excess Property Checking) 및 satisfies 연산자]], [[식별 가능한 유니온 (Discriminated Unions)]], [[브랜디드 타입 (Branded Types)]], [[불변성 (Immutability) 및 DeepReadonly]], [[SOLID 원칙 및 Facade 패턴]]
-- **Projects/Contexts:** [[대규모 프론트엔드 및 백엔드 애플리케이션 개발]], [[도메인 기반 설계 (DDD)]], [[안전한 API 응답 데이터 파싱 및 매핑]], [[토스(Toss) Front 외부 연동 SDK 인터페이스 설계 사례]]
-- **Contradictions/Notes:** `Interface`와 `Type Alias`의 사용에 관해 일부 개발자 팀(예: Reddit 커뮤니티의 여러 팀)은 선언 병합의 부작용을 피하고 문법의 일관성을 위해 전역적으로 `Type`만을 강제하여 사용하기도 한다. 그러나 TypeScript 공식 문서 및 컴파일러 성능 가이드에서는 객체 구조 확장이 필요하고 캐싱 성능이 중요한 경우 `Interface`를 우선하여 사용할 것을 권장하는 등 실무적인 논쟁과 트레이드오프가 존재한다 [15, 19-21, 53-55].
-
----
-*Last updated: 2026-04-18*
-- Raw Source: [[00_Raw/2026-04-20/철벽 수비대_ TypeScript 타입 시스템과 견고한 인터페이스 설계의 정수.md]]
----
diff --git a/Programming & Language/초과 속성 검사 (Excess Property Checking).md b/Programming & Language/초과 속성 검사 (Excess Property Checking).md
deleted file mode 100644
index d156dd37..00000000
--- a/Programming & Language/초과 속성 검사 (Excess Property Checking).md	
+++ /dev/null
@@ -1,41 +0,0 @@
----
-id: P-REINFORCE-AUTO-BD62E2
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - 초과 속성 검사 (Excess Property Checking)"
----
-
-# [[초과 속성 검사 (Excess Property Checking)]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 초과 속성 검사(Excess Property Checking)는 TypeScript에서 객체 리터럴을 다른 변수에 직접 할당하거나 함수의 인수로 전달할 때, 예상치 못한(정의되지 않은) 속성이 객체에 포함되어 있는지 감지하여 에러를 발생시키는 기능입니다 [1-5]. 이는 개발자가 속성 이름에 오타를 내거나 잘못된 속성을 전달하는 실수를 방지하여 의도치 않은 런타임 동작을 막기 위해 존재합니다 [6-8]. 하지만 객체를 중간 변수에 먼저 할당한 후 전달하면 구조적 타이핑의 원칙에 따라 이 검사를 우회하게 되는 특징이 있습니다 [6, 9, 10].
-
-## 📖 구조화된 지식 (Synthesized Content)
-* **발동 조건 및 목적**
-  TypeScript는 기본적으로 속성의 구조만 맞으면 타입이 호환된다고 보는 구조적 타이핑(Structural Typing) 시스템을 따릅니다 [11]. 그러나 객체 리터럴이 변수에 직접 할당되거나 인수로 전달되는 특수한 상황에서는 TypeScript가 더 엄격하게 동작하여 초과 속성 검사를 실행합니다 [1, 4, 6]. 이 기능은 `color`를 `colour`로 입력하는 것과 같은 오타를 잡아내며, 해당 상황에서 개발자가 초과 속성을 의도적으로 전달할 확률이 극히 낮다고 가정하여 런타임 에러를 사전에 차단합니다 [6-8].
-
-* **검사의 한계 (우회 메커니즘)**
-  객체 리터럴을 중간 변수에 먼저 할당한 뒤 이를 다른 변수나 함수에 전달하면, 초과 속성 검사가 작동하지 않습니다 [6, 9]. 두 객체가 최소 하나 이상의 공통 속성만 가지고 있다면 "최소 요건 충족"이라는 구조적 타이핑 원칙이 적용되기 때문입니다 [6, 9, 10]. 이러한 방식은 JavaScript의 유연한 패턴을 지원하지만, 동시에 불필요하거나 잘못된 속성이 런타임에 유입되어 부작용(예: React 컴포넌트의 의도치 않은 리렌더링, 잘못된 DOM 속성 전달)을 일으키는 원인이 될 수 있습니다 [10, 12].
-
-* **완화 및 방어 전략**
-  * **`satisfies` 연산자의 활용:** TypeScript 4.9에서 도입된 `satisfies` 연산자를 사용하면 간접 할당 과정에서도 엄격한 속성 검사를 수행할 수 있습니다. 이를 통해 구체적인 값(리터럴 타입 등)을 유지하면서 대상 타입에 정의되지 않은 초과 속성이 들어오는 것을 원천 차단합니다 [13, 14].
-  * **커스텀 제네릭 타입 활용:** 더 엄격한 수동 검사가 필요한 경우, 제네릭 매개변수(`T`)와 예상 타입(`Shape`)을 비교하여 예상 타입에 없는 속성을 `never` 타입으로 강제 할당하는 방식을 사용할 수 있습니다 [15, 16]. 중첩된 깊은 객체 구조에 대해서는 재귀적 타입을 활용해 초과 속성을 감지해냅니다 [17, 18].
-
-* **관련 린트(Lint) 규칙 제안**
-  변수 할당 시에도 초과 속성 검사가 누락되는 것을 막기 위해 `eslint-plugin`에 `no-excess-properties`라는 규칙이 제안된 바 있습니다 [19]. 그러나 TypeScript에서는 모든 객체가 본질적으로 "부정확성(inexact)"을 허용하는 구조적 타이핑에 의존하며, 과잉 속성이 실제 버그로 이어지는 경우가 드물다는 점, 그리고 커뮤니티의 수요가 부족하다는 점 때문에 해당 제안은 채택되지 않고 닫혔습니다 [20-22].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[구조적 타이핑 (Structural Typing)]], [[satisfies 연산자]]
-- **Projects/Contexts:** [[typescript-eslint]]
-- **Contradictions/Notes:** TypeScript는 근본적으로 속성 집합의 포함 관계만 확인하는 '구조적 타이핑' 원칙을 따르지만, 객체 리터럴을 직접 다루는 맥락에서는 이러한 유연성을 예외적으로 차단하고 '초과 속성 검사'라는 더 엄격한 잣대를 적용한다는 점에서 뚜렷한 동작의 대비를 보입니다 [1, 6, 11].
-
----
-*Last updated: 2026-04-18*
-- Raw Source: [[00_Raw/2026-04-20/초과 속성 검사 (Excess Property Checking).md]]
----
diff --git a/Programming & Language/초과 속성 검사 (Excess Property Checks).md b/Programming & Language/초과 속성 검사 (Excess Property Checks).md
deleted file mode 100644
index 3fc18e9d..00000000
--- a/Programming & Language/초과 속성 검사 (Excess Property Checks).md	
+++ /dev/null
@@ -1,39 +0,0 @@
----
-id: P-REINFORCE-AUTO-920865
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - 초과 속성 검사 (Excess Property Checks)"
----
-
-# [[초과 속성 검사 (Excess Property Checks)]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 초과 속성 검사(Excess Property Checks)는 TypeScript에서 객체 리터럴을 다른 변수에 직접 할당하거나 함수의 인자로 전달할 때, 대상 타입에 정의되지 않은 예상치 못한 속성이 포함되어 있는지 확인하여 에러를 발생시키는 엄격한 타입 검사 기능입니다 [1-3]. 이는 속성 이름의 오타나 잘못된 데이터가 유입되는 실수를 컴파일 시점에 포착하여, 의도하지 않은 런타임 동작을 방어하는 핵심적인 수비 기제 역할을 합니다 [4-6].
-
-## 📖 구조화된 지식 (Synthesized Content)
-- **작동 원리 및 목적**
-  TypeScript의 기본 타입 시스템인 구조적 타이핑(Structural Typing)은 객체가 대상 타입의 '최소한의 속성'만 갖추면 할당을 허용합니다 [3, 6, 7]. 그러나 객체 리터럴(Object Literals)에 대해서는 특별 대우를 하여 예외적으로 더 엄격하게 검사합니다 [3, 4]. TypeScript는 객체 리터럴을 직접 넘길 때 사용자가 불필요한 초과 속성을 의도적으로 전달할 확률이 극히 낮다고 판단하므로, 속성명 오타(예: `color` 대신 `colour` 입력)로 인한 런타임 오류를 사전에 차단합니다 [4, 5].
-
-- **한계점 (우회 취약성)**
-  초과 속성 검사는 '객체 리터럴을 직접 다룰 때만' 활성화된다는 뚜렷한 한계를 가집니다 [8, 9]. 객체 리터럴을 먼저 중간 변수에 할당한 뒤, 그 변수를 다른 타입의 변수에 할당하거나 함수 인자로 전달하는 '간접 할당'의 경우, 구조적 타이핑의 기본 원칙으로 돌아가 검사가 우회(작동하지 않음)됩니다 [1, 4, 9, 10]. 이로 인해 무효한 속성이 React DOM에 그대로 전달되어 경고를 발생시키거나 컴포넌트의 의도치 않은 리렌더링을 유발하는 등, 오타로 인한 미묘한 버그가 방치될 수 있습니다 [11, 12].
-
-- **해결 및 보완 전략**
-  - **인덱스 서명(Index Signature):** 의도적으로 알 수 없는 추가 속성들을 허용해야 하는 경우, 인터페이스에 인덱스 서명을 추가하여 에러를 방지할 수 있습니다 [3].
-  - **제네릭과 never 타입 활용:** 제네릭(Generic) 매개변수와 `never` 타입을 조합하여 실제 입력값과 예상 타입을 비교함으로써, 간접 할당 시에도 초과 속성을 컴파일 에러로 잡아내는 고도화된 재귀적 타입을 직접 구현할 수 있습니다 [13, 14].
-  - **satisfies 연산자 도입:** TypeScript 4.9부터 도입된 `satisfies` 연산자를 활용하면, 객체의 구체적인 리터럴 타입 등은 그대로 유지하면서도 간접 할당 전에 대상 인터페이스 요구사항에 맞는지 엄격한 과잉 속성 검사를 강제할 수 있습니다 [4, 15, 16].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[구조적 타이핑 (Structural Typing)]], [[객체 리터럴 (Object Literals)]], [[satisfies 연산자]]
-- **Projects/Contexts:** [[typescript-eslint]] (초과 속성 검사가 변수 할당 시 우회되는 문제를 해결하기 위해 `no-excess-properties`라는 새로운 린트 규칙이 제안되었으나, 유연성 및 복잡도 문제로 반영되지 않음 [12, 17, 18]), [[React 컴포넌트 프로퍼티 검증]] (우회된 초과 속성이 예기치 못한 리렌더링을 일으키는 대표적 맥락 [11])
-- **Contradictions/Notes:** TypeScript의 기본 철학인 '구조적 타이핑'은 최소 요건만 맞으면 추가 속성을 허용한다는 입장이지만, '초과 속성 검사'는 추가 속성을 에러로 처리한다는 점에서 타입 시스템 내에서 서로 상반되는 규칙처럼 보일 수 있습니다. 이는 TypeScript가 개발자의 '실수 방지'를 위해 객체 리터럴에만 부여한 의도적 예외 동작입니다 [1, 7].
-
----
-*Last updated: 2026-04-18*
-- Raw Source: [[00_Raw/2026-04-20/초과 속성 검사 (Excess Property Checks).md]]
----
diff --git a/Programming & Language/추론 엔진 (Semantic Reasoner).md b/Programming & Language/추론 엔진 (Semantic Reasoner).md
deleted file mode 100644
index 7a94df9b..00000000
--- a/Programming & Language/추론 엔진 (Semantic Reasoner).md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-A3E15F
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - 추론 엔진 (Semantic Reasoner)"
----
-
-# [[추론 엔진 (Semantic Reasoner)]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/추론 엔진 (Semantic Reasoner).md]]
----
diff --git a/Programming & Language/추상 구문 트리(AST).md b/Programming & Language/추상 구문 트리(AST).md
deleted file mode 100644
index a6319039..00000000
--- a/Programming & Language/추상 구문 트리(AST).md	
+++ /dev/null
@@ -1,32 +0,0 @@
----
-id: P-REINFORCE-AUTO-0C0765
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - 추상 구문 트리(AST)"
----
-
-# [[추상 구문 트리(AST)]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 추상 구문 트리(AST, Abstract Syntax Tree)는 소스 코드를 파싱하여 언어의 문법적 구조와 형태를 표현한 트리 형태의 데이터 구조입니다 [1, 2]. 콘크리트 구문 트리(CST)와 달리 코드의 레이아웃이나 주석, 매크로 등은 기본적으로 포함하지 않고 핵심적인 구문(Syntax) 및 어휘(Lexical) 기능만을 보존하는 것이 특징입니다 [1, 3]. 정적 애플리케이션 보안 테스트(SAST), 린터(Linter) 도구, 그리고 개발자의 코딩 스타일을 분석하는 코드 스타일로메트리(Code Stylometry) 등에서 소스 코드를 구조적으로 분석하고 특징을 추출하는 핵심 기반 기술로 사용됩니다 [2, 4, 5].
-
-## 📖 구조화된 지식 (Synthesized Content)
-- **개념 및 구조적 특징:** AST는 소스 코드를 파싱하는 과정을 통해 생성되며, 개발자가 구성한 문법적 구조를 계층적으로 나타냅니다 [1, 2]. 전처리 과정 후의 코드를 트리 구조로 매핑하기 때문에 주석(Comments), 매크로(Macros), 들여쓰기나 공백과 같은 코드의 레이아웃 속성은 추상화되어 포함되지 않습니다 [1, 3, 6]. 따라서 코드의 띄어쓰기나 들여쓰기 방식 등 시각적 포맷을 전면적으로 수정하더라도 파싱 결과로 얻어지는 AST는 동일하게 유지됩니다 [6].
-- **코드 스타일로메트리(저자 식별)에서의 활용:** 머신러닝 기반의 소스 코드 저자 식별 연구(예: code2vec 모델 적용)에서 AST는 소스 코드 파일로부터 저자의 구문적 특징(Syntactic features)을 추출하는 입력 데이터로 사용됩니다 [4, 7]. 특정 연구에서는 AST 노드의 바이그램(bigram)에 대한 빈도를 계산하여 저자를 식별하는 데 가장 유의미한 특징으로 활용하기도 했습니다 [7]. 하지만 AST는 저자 스타일의 본질적 구문적 측면만을 포착할 뿐, 레이아웃 특징을 배제하기 때문에 콘크리트 구문 트리(CST)를 사용할 때와 비교하여 식별 정확도가 상대적으로 낮아진다는 한계가 존재합니다 [8, 9].
-- **정적 코드 분석(SAST 및 Linter)에서의 역할:** 프로그램을 실행하지 않고 코드의 구조와 구문을 검사하여 코딩 실수, 보안 취약점, 성능 병목 현상 등을 찾아내는 SAST 도구들은 소스 코드를 파싱해 AST를 빌드한 후 다양한 분석 기법을 적용하여 문제를 탐지합니다 [2]. 또한, 프론트엔드 개발 생태계에서도 ESLint와 같은 린팅 도구(`eslint-plugin-jsx-a11y` 등)가 AST 분석을 통해 코드의 접근성 문제 및 문법 오류에 대한 즉각적인 피드백을 제공합니다 [5].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[콘크리트 구문 트리(CST)]], [[코드 스타일로메트리(Code Stylometry)]], [[정적 애플리케이션 보안 테스트(SAST)]]
-- **Projects/Contexts:** [[ESLint]], [[code2vec]], [[Google Code Jam 데이터셋]]
-- **Contradictions/Notes:** 소스 코드의 저자 식별 시 AST를 활용하면 저자 고유의 구문적 특성을 성공적으로 추출할 수 있지만, 레이아웃 정보가 누락되기 때문에 CST를 활용한 분석에 비해 정확도가 떨어진다는 점이 연구 결과로 입증되었습니다(AST 기반 51%에서 CST 기반 68%로 정확도 상승) [8].
-
----
-*Last updated: 2026-04-19*
-- Raw Source: [[00_Raw/2026-04-20/추상 구문 트리(AST).md]]
----
diff --git a/Programming & Language/추상화(Abstraction).md b/Programming & Language/추상화(Abstraction).md
deleted file mode 100644
index 39a28a05..00000000
--- a/Programming & Language/추상화(Abstraction).md	
+++ /dev/null
@@ -1,39 +0,0 @@
----
-id: P-REINFORCE-AUTO-766E2E
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - 추상화(Abstraction)"
----
-
-# [[추상화(Abstraction)]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 추상화(Abstraction)는 복잡한 내부 구현을 숨기고 사용자의 '의도(Intent)'나 이상적인 형태(인터페이스)를 기준으로 코드를 단순하게 재구성하는 소프트웨어 설계 기법입니다 [1, 2]. 의존성 역전 원칙(DIP)의 핵심 개념으로, 상위 모듈과 하위 모듈이 구체적인 세부 사항이 아닌 추상화에 의존하도록 만들어 시스템의 결합도를 낮추고 인지 부하를 줄입니다 [2, 3]. 그러나 도메인을 충분히 이해하지 못한 상태에서의 과도한 추상화는 오히려 시스템의 복잡성을 폭발시키고 개발 속도를 늦출 수 있으므로 주의가 필요합니다 [4, 5].
-
-## 📖 구조화된 지식 (Synthesized Content)
-- **추상화의 목적과 의존성 역전(DIP)**
-  소프트웨어 설계에서 추상화는 하위 수준의 구체적인 구현(세부 사항) 대신 인터페이스와 같은 이상적인 계약에 의존하도록 만드는 것을 의미합니다 [1]. 예를 들어, 서버 통신이나 파일 업로드 시 인증, 재시도, 상태 관리 등의 복잡한 내부 로직을 은닉하고, "서버를 시작한다"와 같이 사용자의 목적을 직관적으로 표현하는 상위 추상화(퍼사드, Facade)를 제공합니다 [2]. 이를 통해 기능의 결합도를 낮추고 유연한 확장이 가능해집니다 [1, 2].
-
-- **이른 추상화(Premature Abstraction)와 오버엔지니어링의 함정**
-  문맥 없이 추상화를 남용하거나 단일 기능에 대해 불필요한 인터페이스 및 기본 클래스 계층을 생성하면, 시스템의 복잡성이 기하급수적으로 증가하고 유지보수성이 사라집니다 [4]. 특히, 도메인을 완벽히 이해하기 전에 단순한 호출을 복잡한 인터페이스 뒤로 숨기는 행위는 불필요한 우회(indirection) 계층을 만들어 오히려 배포 및 개발 속도를 늦추게 됩니다 [5, 6].
-
-- **올바른 추상화 적용 가이드라인**
-  - **자연스러운 패턴 도출 시점에 적용**: 초기에는 가장 단순하고 구체적인 구현(YAGNI)으로 시작해야 합니다 [5]. 이후 코드베이스에서 최소 3개의 유사한 구현 패턴이 등장할 때(Rule of Three) 비로소 공통 추상화를 추출하는 것이 바람직합니다 [4, 5].
-  - **제한적인 상속 및 계층화**: 복잡성을 관리하기 위해 추상 클래스와 상속 계층의 사용을 가급적 줄이고, 합성을 우선시하는 것이 권장됩니다 [6].
-  - **고수준과 저수준 API의 공존**: 추상화 수준이 높아지면 필연적으로 세밀한 제어가 어려워지는 트레이드오프가 발생합니다 [7]. 이를 보완하기 위해 일반적인 유즈케이스의 80%를 처리하는 고수준 인터페이스와 함께, 특수한 20%의 케이스를 직접 제어할 수 있는 저수준 인터페이스(탈출구, Escape Hatch)를 병행하여 제공해야 합니다 [8, 9].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[의존성 역전 원칙(Dependency Inversion Principle)]], [[퍼사드 패턴(Facade Pattern)]], [[이른 추상화(Premature Abstraction)]], [[오버엔지니어링(Over-Engineering)]]
-- **Projects/Contexts:** [[Toss Front SDK 설계]], [[SOLID Design Principles]], [[TypeScript 아키텍처 설계]]
-- **Contradictions/Notes:** 소스에서는 추상화가 시스템을 모듈화하고 결합도를 낮추는 강력한 도구임을 강조하지만, 동시에 "모든 컴퓨터 과학의 문제는 또 다른 추상화 계층으로 해결할 수 있지만, 그 추상화 계층 자체가 문제가 된다"는 모순적 특성을 지적하며 무분별한 추상화의 위험성을 경고합니다 [4, 6, 7].
-
----
-*Last updated: 2026-04-18*
-- Raw Source: [[00_Raw/2026-04-20/추상화(Abstraction).md]]
----
diff --git a/Programming & Language/추상화.md b/Programming & Language/추상화.md
deleted file mode 100644
index 122ade5c..00000000
--- a/Programming & Language/추상화.md	
+++ /dev/null
@@ -1,37 +0,0 @@
----
-id: P-REINFORCE-AUTO-0EA2E7
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - 추상화"
----
-
-# [[추상화]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 추상화는 소프트웨어 설계에서 공통된 기능이나 비즈니스 로직을 추출하여 재사용 가능한 컴포넌트, 인터페이스 또는 기반 클래스로 분리하는 기법입니다 [1, 2]. 이를 통해 시스템의 결합도를 낮추고 유연성을 높이며 코드의 중복을 방지할 수 있습니다 [2, 3]. 하지만 지나치고 성급한 추상화는 오히려 시스템의 복잡성을 증가시키고 인지적 부하를 높일 수 있으므로, 실제 중복이 발생했을 때 실용적으로 적용하는 절제력이 필요합니다 [4-6].
-
-## 📖 구조화된 지식 (Synthesized Content)
-* **중복 제거와 재사용성 향상 (DRY 원칙)**
-  추상화는 시스템 내의 여러 곳에서 공통으로 사용되는 기능을 유틸리티 함수, 공유 라이브러리 또는 기본 클래스로 분리하는 과정에 사용됩니다 [1]. 하지만 중복이 최소 두 번(또는 세 번) 이상 발견될 때까지 기다렸다가 추상화를 진행하는 "Rule of Three"를 따르는 것이 좋으며, 이는 불필요한 복잡성을 유발하는 성급한 추상화를 방지합니다 [4, 5]. 
-
-* **의존성 역전 및 유연성 확보 (SOLID 원칙)**
-  추상화는 객체 지향 프로그래밍의 핵심 원칙을 구현하는 데 필수적입니다. 개방-폐쇄 원칙(OCP)을 달성하기 위해 인터페이스나 추상 클래스를 사용하여 기존 코드를 수정하지 않고도 새로운 기능을 확장할 수 있게 합니다 [2, 3]. 또한, 의존성 역전 원칙(DIP)에 따라 고수준 모듈과 저수준 모듈이 세부 구현에 의존하는 대신 모두 추상화(인터페이스 등)에 의존하도록 함으로써 결합도를 낮추고 유연한 시스템을 구축할 수 있습니다 [2, 3].
-
-* **과도한 추상화의 위험성과 실용적 접근 (YAGNI)**
-  추상화가 유용함에도 불구하고, 무분별하게 적용할 경우 오버엔지니어링과 '인디렉션의 저주'를 낳을 수 있습니다 [5, 7]. 너무 높은 수준의 추상화나 너무 많은 레이어는 구체적인 구현을 찾기 위해 수많은 인터페이스를 파헤쳐야 하게 만들며, 결국 코드를 읽는 개발자를 미궁에 빠뜨리고 인지적 부하를 가중시킵니다 [5]. 따라서 미래에 필요할 것이라고 미리 예측하여 추상화를 도입(YAGNI 철학 위배)하기보다는, 실제적인 중복이 발생할 때 비로소 경계를 긋고 추상화를 적용하는 절제력과 실용적인 태도가 요구됩니다 [6-8].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[DRY 원칙]], [[의존성 역전 원칙(DIP)]], [[개방-폐쇄 원칙(OCP)]], [[관심사의 분리(SoC)]], [[Rule of Three]], [[YAGNI]]
-- **Projects/Contexts:** [[소프트웨어 아키텍처 설계]], [[객체 지향 프로그래밍(OOP)]]
-- **Contradictions/Notes:** 소스 문헌들은 추상화가 시스템을 유연하게 하고 결합도를 낮추는 핵심 도구라고 강조하면서도 동시에, 지나치거나 성급한 추상화는 오히려 개발자의 인지적 부하를 높이고 코드를 복잡하게 만드는 부작용(오버엔지니어링)을 낳을 수 있다고 양면성을 경고합니다 [2, 5, 7].
-
----
-*Last updated: 2026-04-18*
-- Raw Source: [[00_Raw/2026-04-20/추상화.md]]
----
diff --git a/Programming & Language/카오스 몽키(Chaos Monkey).md b/Programming & Language/카오스 몽키(Chaos Monkey).md
deleted file mode 100644
index decdc493..00000000
--- a/Programming & Language/카오스 몽키(Chaos Monkey).md	
+++ /dev/null
@@ -1,33 +0,0 @@
----
-id: P-REINFORCE-AUTO-E9B14A
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - 카오스 몽키(Chaos Monkey)"
----
-
-# [[카오스 몽키(Chaos Monkey)]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 카오스 몽키(Chaos Monkey)는 넷플릭스(Netflix)가 마이크로서비스 아키텍처(MSA)를 도입하는 과정에서 시스템의 회복 탄력성(Resiliency)을 검증하기 위해 사용한 자동화된 파괴 테스트(Automate destructive testing) 도구입니다 [1, 2]. 이 도구의 도입은 넷플릭스의 '시미안 아미(Simian Army)' 프로젝트가 시작되는 계기가 되었습니다 [2]. (소스에 관련 정보가 부족하여 더 이상의 자세한 정의는 제공하기 어렵습니다.)
-
-## 📖 구조화된 지식 (Synthesized Content)
-* **회복 탄력성을 위한 파괴 테스트 자동화:** 넷플릭스는 시스템의 복원력을 높이기 위해 다중화(Redundancy)를 구축하고 특정 장애의 피해 반경(blast radius)을 격리하는 원칙을 세웠습니다 [2]. 이러한 원칙이 실제 환경에서 잘 작동하는지 확인하기 위해 파괴 테스트를 자동화하였으며, 그 첫 출발점이 카오스 몽키(Chaos Monkey)였습니다 [2].
-* **시미안 아미(Simian Army)의 시작:** 카오스 몽키는 넷플릭스 인프라의 복원력을 테스트하는 더 큰 도구군인 '시미안 아미(Simian Army)'가 구축되는 기반이 되었습니다 [2]. 
-
-**소스에 관련 정보가 부족합니다.** (제공된 소스에서는 카오스 몽키의 구체적인 작동 방식, 테스트 대상, 세부 기술 구조 등에 대한 내용을 다루고 있지 않습니다.)
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[자동화된 파괴 테스트(Automate destructive testing)]], [[시미안 아미(Simian Army)]], [[마이크로서비스 아키텍처(Microservice Architecture)]]
-- **Projects/Contexts:** [[넷플릭스의 마이크로서비스 도입(Netflix journey to microservices)]]
-- **Contradictions/Notes:** 주어진 소스 문서(Netflix's Microservices Adoption Case Study)에는 카오스 몽키에 대한 발표 슬라이드 수준의 단편적인 언급만 존재하며, 그 이상의 구체적인 정보는 포함되어 있지 않습니다 [2].
-
----
-*Last updated: 2026-04-18*
-- Raw Source: [[00_Raw/2026-04-20/카오스 몽키(Chaos Monkey).md]]
----
diff --git a/Programming & Language/커뮤니티 탐지 (Community Detection).md b/Programming & Language/커뮤니티 탐지 (Community Detection).md
deleted file mode 100644
index 7e2b9380..00000000
--- a/Programming & Language/커뮤니티 탐지 (Community Detection).md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-D5C627
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - 커뮤니티 탐지 (Community Detection)"
----
-
-# [[커뮤니티 탐지 (Community Detection)]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/커뮤니티 탐지 (Community Detection).md]]
----
diff --git a/Programming & Language/코드 리뷰 (Code Review).md b/Programming & Language/코드 리뷰 (Code Review).md
deleted file mode 100644
index f3b70753..00000000
--- a/Programming & Language/코드 리뷰 (Code Review).md	
+++ /dev/null
@@ -1,34 +0,0 @@
----
-id: P-REINFORCE-AUTO-A3AFCE
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - 코드 리뷰 (Code Review)"
----
-
-# [[코드 리뷰 (Code Review)]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 코드 리뷰(Code Review)는 소스 코드의 품질, 보안 및 유지보수성을 보장하기 위해 코드를 검사하고 논의하는 프로세스입니다 [1-3]. 완벽함보다는 시간이 지남에 따라 코드베이스의 전반적인 건강 상태(Code health)를 지속적으로 개선하는 것을 목표로 하며, 개발 속도와 품질 간의 균형을 맞추는 것이 핵심입니다 [2, 4, 5]. 현대의 소프트웨어 개발에서는 아키텍처와 비즈니스 로직을 파악하는 인간의 '수동 코드 리뷰'와 문법 및 취약점을 빠르게 찾아내는 '자동화된 코드 리뷰'를 결합한 하이브리드 접근 방식이 최적의 표준으로 평가받고 있습니다 [1, 6, 7].
-
-## 📖 구조화된 지식 (Synthesized Content)
-* **목적과 기본 원칙:** 코드 리뷰의 주된 목적은 시스템의 코드 건강을 지속적으로 향상시키는 것입니다 [2]. 리뷰어는 절대적으로 완벽한 코드를 요구하여 개발 속도를 늦추기보다는, 전반적인 개선을 추구해야 합니다 [4, 5]. 코드 설계 문제에 있어서 개인적 취향이 아닌 기술적 사실과 정해진 스타일 가이드에 근거하여 판단해야 합니다 [8]. 또한, 코드 리뷰는 개발자에게 언어나 소프트웨어 설계 원칙을 가르치고 지식을 공유하는 중요한 멘토링 역할을 수행합니다 [9-12].
-* **수동 코드 리뷰 (Manual Code Review):** 개발자가 직접 코드를 읽고 논의하여 도구가 놓치는 문제를 발견하는 방식입니다 [1]. 인간 리뷰어는 프로젝트의 아키텍처, 비즈니스 로직, 특정 보안 환경 등을 깊이 이해하고 있어 복잡한 설계 결함이나 미묘한 논리 오류를 포착하는 데 탁월합니다 [1, 10, 13, 14]. 그러나 사람이 코드를 일일이 읽는 것은 시간이 많이 소요되어 배포를 지연시킬 수 있으며, 리뷰어의 피로나 편향에 의해 중요한 버그를 놓치는 실수가 발생할 수 있다는 단점이 있습니다 [9, 15].
-* **자동화된 코드 리뷰 (Automated Code Review):** 정적 분석(SAST), 린터(Linter), 포매터(Formatter), AI 도구 등을 사용하여 소스 코드를 자동으로 스캔하는 방식입니다 [16-18]. 이 방식은 수천 줄의 코드를 몇 초 만에 스캔할 수 있어 매우 빠르고 일관되며, 구문 오류나 알려진 보안 취약점을 발견하는 데 유리합니다 [19]. 그러나 코드의 작성 의도나 비즈니스 로직을 이해하지 못하는 문맥적 한계(Context Blindness)가 있으며, 일부 연구에 따르면 실제 취약점의 약 22%를 놓치고 30-60% 수준의 오탐지(False Positive)를 발생시켜 개발자에게 알림 피로도를 줄 수 있습니다 [20-23].
-* **하이브리드 리뷰 모델 (Hybrid Review Model):** 2025년의 모범 사례는 수동과 자동화를 결합한 워크플로우입니다 [7]. 자동화 도구가 일상적인 구문 검사, 기본 보안 스캔, 코드 스타일 검사를 CI/CD 파이프라인에서 1차적으로 처리하여 검토해야 할 노이즈를 줄입니다 [24-26]. 이후 인간 리뷰어는 아키텍처의 트레이드오프, 서비스 간의 상호 작용, 도메인에 특화된 비즈니스 로직 검증 등 인간의 판단이 필수적인 고위험 영역에만 집중함으로써 리뷰의 효율과 보안을 동시에 극대화합니다 [24, 25, 27-29].
-* **관련 도구 및 자동화 연동:** 개발팀은 Husky나 lint-staged와 같은 Git 훅(Git hooks) 도구를 사용하여 코드가 저장소에 커밋되거나 푸시되기 전에 ESLint, Prettier와 같은 도구가 자동으로 실행되도록 설정할 수 있습니다 [30-35]. 이를 통해 룰에 맞지 않는 코드의 커밋을 방지하고 일관된 코드 스타일을 강제하여, 불필요한 스타일 교정에 소모되는 인지적 부담을 줄이고 인간 리뷰어가 핵심 논리에 집중할 수 있게 돕습니다 [33, 36].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[수동 코드 리뷰 (Manual Code Review)]], [[정적 애플리케이션 보안 테스트 (SAST)]], [[하이브리드 코드 리뷰 (Hybrid Code Review)]], [[린터 (Linter)]]
-- **Projects/Contexts:** [[CI/CD 파이프라인 (CI/CD Pipelines)]], [[Pull Request (PR) 워크플로우]]
-- **Contradictions/Notes:** 자동화된 코드 리뷰 도구는 매우 빠르고 일관성 있게 코드를 검사하지만, 비즈니스 로직과 아키텍처의 의도를 이해하지 못하므로 인간 리뷰어를 완전히 대체할 수 없습니다. 따라서 양쪽의 단점을 상쇄하고 장점을 취하기 위해, 자동화가 일차적인 방어선을 구축하고 인간이 고차원적인 검토를 수행하는 상호 보완적(Hybrid) 접근이 필수적입니다 [7, 20, 37-39].
-
----
-*Last updated: 2026-04-18*
-- Raw Source: [[00_Raw/2026-04-20/코드 리뷰 (Code Review).md]]
----
diff --git a/Programming & Language/코드 서식 지정과 축소가 코드 스타일로메트리(작성자 인식)에 미치는 영향을 평가하는 기계 학습 모델 분류 연구.md b/Programming & Language/코드 서식 지정과 축소가 코드 스타일로메트리(작성자 인식)에 미치는 영향을 평가하는 기계 학습 모델 분류 연구.md
deleted file mode 100644
index 7fc0aa53..00000000
--- a/Programming & Language/코드 서식 지정과 축소가 코드 스타일로메트리(작성자 인식)에 미치는 영향을 평가하는 기계 학습 모델 분류 연구.md	
+++ /dev/null
@@ -1,43 +0,0 @@
----
-id: P-REINFORCE-AUTO-952EE7
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - 코드 서식 지정과 축소가 코드 스타일로메트리(작성자 인식)에 미치는 영향을 평가하는 기계 학습 모델 분류 연구"
----
-
-# [[코드 서식 지정과 축소가 코드 스타일로메트리(작성자 인식)에 미치는 영향을 평가하는 기계 학습 모델 분류 연구]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 이 연구는 소프트웨어 개발에서 흔히 쓰이는 코드 서식 지정(formatting)과 코드 축소(minification)가 코드 스타일로메트리(작성자 자동 인식) 시스템의 정확도에 어떠한 영향을 미치는지 정량적으로 평가한 논문입니다 [1], [2]. 연구진은 Python 코드를 구체적 구문 트리(CST)로 표현하고 code2vec 기반의 기계 학습 분류 모델을 사용하여 작성자 식별 실험을 수행했습니다 [1]. 실험 결과, 서식 지정과 축소 과정은 작성자 인식 정확도를 유의미하게 감소시켰으나, 여전히 작성자를 식별할 수 있는 수준의 정보는 남아있는 것으로 나타났습니다 [1], [3].
-
-## 📖 구조화된 지식 (Synthesized Content)
-- **연구 방법 및 데이터셋 구성**
-  연구는 Google Code Jam 데이터셋에 포함된 59명의 Python 소스 코드(각 10개 파일)를 기반으로 진행되었습니다 [4], [5]. 코드의 의미와 스타일을 모두 보존하기 위해 소스 코드를 구체적 구문 트리(CST) 기반의 벡터로 변환하는 code2vec 아키텍처를 작성자 분류 모델로 활용했습니다 [6], [7]. 실험은 (1) 원본 데이터셋, (2) 'Black' 도구로 서식이 지정된 데이터셋, (3) 'Python Minifier' 도구로 축소된 데이터셋에 대해 각각 수행하여 정확도를 비교했습니다 [4].
-
-- **AST와 CST 코드 표현 방식의 차이**
-  대부분의 기존 연구가 사용하는 추상 구문 트리(AST)는 코드의 레이아웃이나 어휘적 특징을 온전히 담지 못하는 반면, 구체적 구문 트리(CST)는 이를 모두 포착합니다 [6], [8]. 실험 결과 AST 기반 분류의 정확도는 51.00%였으나, CST 기반 분류의 정확도는 67.86%로 확연히 높게 나타나 구체적 구문 특징을 포함하는 것이 작성자 인식률을 크게 향상시킨다는 점을 입증했습니다 [9], [10].
-
-- **코드 서식 지정(Formatting)의 영향**
-  코드를 일관된 스타일로 강제하는 서식 지정 도구(Black)를 적용했을 때, 코드 스타일로메트리의 정확도는 67.86%에서 52.68%로 약 15.18%p 감소했습니다 [11]. 이는 자동화된 서식 지정이 개발자 개인의 고유한 스타일 특성을 부분적으로 지워버려 작성자 식별을 더 어렵게 만든다는 것을 의미합니다 [11].
-
-- **코드 축소(Minification)의 영향**
-  공백 및 주석 제거, 변수명 변경 등을 통해 코드 크기를 최소화하는 축소 도구(Python Minifier)를 적용한 경우, 정확도는 원본 대비 17.86%p 감소한 50.00%를 기록했습니다 [12]. 그러나 서식 지정 후의 정확도(52.68%)와 축소 후의 정확도(50.00%) 간의 차이는 2.68%p에 불과했습니다 [3]. 이는 CST 기반 분류 모델에서 서식 지정만으로도 축소 기술과 유사한 수준으로 작성자의 구체적 구문 특징이 무력화됨을 시사합니다 [3].
-
-- **결론 및 시사점**
-  서식 지정과 축소 기술이 코드 스타일로메트리 모델의 인식률을 유의미하게 떨어뜨리지만, 식별 정확도를 무작위 분류 기준선(약 1.69%)보다 훨씬 높은 50% 수준으로 유지하므로 작성자를 완전히 익명화하지는 못합니다 [13], [3]. 완벽한 작성자 비식별화를 달성하려면 코드의 가독성을 거의 포기하는 수준의 난독화(obfuscation)나 컴파일 방식과 같이 훨씬 침습적인 기술이 고려되어야 합니다 [14].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[코드 스타일로메트리]], [[작성자 인식(Authorship Attribution)]], [[구체적 구문 트리(CST)]], [[추상 구문 트리(AST)]], [[code2vec]], [[기계 학습 분류기(Machine Learning Classifier)]]
-- **Projects/Contexts:** [[Google Code Jam 데이터셋]], [[Black (Python 코드 포매터)]], [[Python Minifier]]
-- **Contradictions/Notes:** 소스에 따르면 서식 지정된 코드(52.68%)와 축소된 코드(50.00%)의 작성자 인식 정확도는 원본 AST 기반 모델의 정확도(51.00%)와 매우 유사한 수치를 보입니다. 이는 서식 지정과 축소라는 과정이 CST가 제공하는 구체적 구문 특징의 이점을 대부분 상쇄시키지만, AST로도 포착 가능한 더 깊은 수준의 추상적 구문 내재 스타일까지는 파괴하지 못한다는 점을 의미합니다 [15].
-
----
-*Last updated: 2026-04-19*
-- Raw Source: [[00_Raw/2026-04-20/코드 서식 지정과 축소가 코드 스타일로메트리(작성자 인식)에 미치는 영향을 평가하는 기계 학습 모델 분류 연구.md]]
----
diff --git a/Programming & Language/코드 스타일로메트리 (Code Stylometry).md b/Programming & Language/코드 스타일로메트리 (Code Stylometry).md
deleted file mode 100644
index 354231e2..00000000
--- a/Programming & Language/코드 스타일로메트리 (Code Stylometry).md	
+++ /dev/null
@@ -1,34 +0,0 @@
----
-id: P-REINFORCE-AUTO-325355
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - 코드 스타일로메트리 (Code Stylometry)"
----
-
-# [[코드 스타일로메트리 (Code Stylometry)]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-* **주요 분석 특징 (Features):** 코드 스타일로메트리는 주로 세 가지 범주의 특징을 기반으로 저자를 식별합니다. 문자나 단어의 사용 방식을 보는 **'어휘적 특징(Lexical features)'**, 추상 구문 트리(AST)의 형태 및 문법적 구조를 분석하는 **'구문적 특징(Syntactic features)'**, 들여쓰기, 공백, 줄 길이 등 시각적인 배치를 평가하는 **'레이아웃 특징(Layout features)'**이 포함됩니다 [7], [8].
-* **분석 기법의 진화:** 초기의 연구는 명시적인 형식 규칙에 의존했으나, 점차 SVM, 랜덤 포레스트(Random Forests), 신경망(Neural Networks)과 같은 **기계 학습(Machine Learning)** 모델과 code2vec 같은 분산 임베딩(Embeddings) 기반의 정교한 접근법으로 발전하여 식별 정확도가 크게 향상되었습니다 [9], [10], [11], [12].
-* **코드 표현 방식의 영향 (AST vs CST):** 소스 코드를 구문 분석할 때, 코드의 구문적 구조만 보존하는 추상 구문 트리(AST)를 사용하는 것보다, 레이아웃과 어휘적 세부 사항까지 온전히 포함하는 **구체적 구문 트리(CST)**를 사용할 때 저자 식별 정확도가 훨씬 높아집니다. 한 연구 실험에서는 AST 기반 51.00%에서 CST 기반 67.86%로 정확도가 향상되었습니다 [8], [13].
-* **포맷팅(Formatting) 및 축소(Minification)의 영향:** 코드를 특정 스타일 가이드에 맞게 일괄 정리하는 포맷팅 도구(예: Black)나 불필요한 공백/변수명을 줄이는 축소 도구(예: Python Minifier)를 사용하면 프로그래머 고유의 레이아웃 특징이 소실됩니다 [14], [15]. 실험 결과, 자동 포맷팅은 식별 정확도를 약 15% (68% → 53%) 낮추었고, 코드 축소는 추가로 3% (68% → 50%)를 떨어뜨려 저자 식별을 어렵게 만들었으나 완전히 식별 불가능하게 만들지는 못했습니다 [1], [16], [17], [18].
-* **적대적 코드 스타일로메트리 (Adversarial Code Stylometry):** 분석을 회피하고 프라이버시를 지키기 위해 고의로 다른 프로그래머의 스타일을 모방(Mimicry)하거나 자신의 스타일을 난독화(Obfuscation)하는 기법도 연구되고 있습니다 [19], [20], [21]. 예를 들어, `StyleCounsel`과 같은 도구는 랜덤 포레스트 분류기의 의사결정 트리를 분석하여, 타겟 프로그래머로 시스템이 오인하도록 만드는 구체적인 코드 변경안을 제시합니다 [19], [22].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[기계 학습 (Machine Learning)]], [[추상 구문 트리 (AST)]], [[구체적 구문 트리 (CST)]], [[코드 포맷팅 (Code Formatting)]], [[적대적 스타일로메트리 (Adversarial Stylometry)]]
-- **Projects/Contexts:** [[Google Code Jam 데이터셋]], [[StyleCounsel 도구]], [[모리스 웜 (Morris Worm) 사건]]
-- **Contradictions/Notes:** 소스 코드를 자동 포맷팅하거나 축소(Minification)하면 분석기의 저자 식별 정확도가 감소하여 프라이버시 보호 효과가 발생하지만, 그것만으로는 스타일적 특징을 완전히 지울 수 없어 저자를 익명으로 유지하는 데에는 불충분합니다 [23], [18].
-
----
-*Last updated: 2026-04-19*
-- Raw Source: [[00_Raw/2026-04-20/코드 스타일로메트리 (Code Stylometry).md]]
----
diff --git a/Programming & Language/코드 축소 (Code minification).md b/Programming & Language/코드 축소 (Code minification).md
deleted file mode 100644
index 05c7cf72..00000000
--- a/Programming & Language/코드 축소 (Code minification).md	
+++ /dev/null
@@ -1,33 +0,0 @@
----
-id: P-REINFORCE-AUTO-AE4852
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - 코드 축소 (Code minification)"
----
-
-# [[코드 축소 (Code minification)]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 코드 축소(Code minification)는 공백, 줄 바꿈, 주석 등 소스 코드에서 의미적으로 불필요한 요소를 제거하고 식별자 이름을 짧게 변경하여 파일의 크기를 최소화하는 최적화 기법입니다 [1, 2]. 이 과정은 코드의 실행 의미(semantics)를 훼손하지 않으면서도, 웹 브라우저의 다운로드 및 페이지 렌더링 속도를 크게 향상시키기 위해 소프트웨어 배포 시점에 자동화되어 수행됩니다 [2, 3]. 코드를 사람이 읽기 어렵게 만들고 프로그래머의 코딩 스타일 특징을 모호하게 만들지만, 작성자의 익명성을 완벽하게 보장하는 수단이 될 수는 없습니다 [3, 4].
-
-## 📖 구조화된 지식 (Synthesized Content)
-* **작동 방식 및 목적:** 코드 축소는 코드 크기를 최적화하기 위해 고안되었습니다. 주로 웹 개발에 빈번히 사용되며, 소스 코드가 브라우저에 배포되는 시간을 최소화해 렌더링 속도를 높이는 것이 목적입니다 [2]. 구체적으로는 공백, 줄 바꿈, 실행과 관련 없는 문자열(예: 주석, docstring) 등 의미 없는 요소를 완전히 삭제하며, 변수 및 클래스 이름 같은 식별자(identifier)를 더 짧고 간결한 이름으로 바꾸는 침투적(invasive) 변환 작업 등을 포함합니다 [2, 5].
-* **가독성 저하와 시맨틱 유지:** 코드 축소는 또 다른 변환 기법인 코드 포맷팅(Code formatting)과 마찬가지로 프로그램의 구동 의미(semantics)를 전혀 변형시키지 않는 소스 대 소스(source-to-source) 변환 기법입니다 [3, 6]. 하지만 코드를 깔끔하게 만드는 포맷팅과는 반대로, 코드의 가독성(legibility)을 의도적으로 크게 떨어뜨립니다 [3, 7]. 이 때문에 축소 과정은 주로 개발이 완료된 후 코드를 배포(deployment)하는 단계에서 기계적으로 수행됩니다 [3].
-* **코드 문체 분석(Code Stylometry)에 미치는 영향:** 코드 축소는 코드의 레이아웃과 어휘적 특성 같은 표면적인 코딩 스타일을 대폭 훼손시킵니다 [3, 6]. 공백을 없애는 등 코드를 획일화(uniformization)하는 과정을 거치기 때문에, 프로그래머 개인의 코딩 스타일을 분석하여 작성자를 식별해 내는 코드 문체 분석의 정확도를 유의미하게 하락(실험 기준 17.86% 감소)시킵니다 [7, 8].
-* **익명성 보호의 한계:** 코드가 시각적으로 매우 읽기 복잡해짐에도 불구하고, 코드 축소는 작성자의 정체를 완벽히 숨기는 데에는 실패합니다 [4, 7]. 연구 결과에 따르면 코드 포맷팅을 거친 코드와 비교했을 때 코드 축소로 인한 추가적인 작성자 식별률 하락은 2.68% 수준에 불과했습니다 [7]. 이는 추상 구문 트리(AST) 수준에서 파악되는 프로그래머 본연의 구조적 작성 스타일은 여전히 남아 있기 때문이며, 따라서 축소 기법만으로는 작성자의 비식별성(non-recognizability)을 보장할 수 없습니다 [4, 9].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[코드 문체 분석 (Code stylometry)]], [[코드 포맷팅 (Code formatting)]], [[구체적 구문 트리 (CST)]], [[추상 구문 트리 (AST)]]
-- **Projects/Contexts:** [[웹 개발 최적화]], [[Python Minifier]]
-- **Contradictions/Notes:** 일반적으로 코드 축소는 코드를 사람이 읽기 훨씬 더 어렵게 만들기 때문에 작성자 식별도 매우 어려울 것으로 예상되지만, 연구 결과 자동화된 코드 포맷팅을 적용한 상태와 비교했을 때 시스템의 작성자 식별 방해 효과(인식률 저하)는 매우 미미한 차이(2.68%)밖에 나지 않았습니다 [7]. 
-
----
-*Last updated: 2026-04-19*
-- Raw Source: [[00_Raw/2026-04-20/코드 축소 (Code minification).md]]
----
diff --git a/Programming & Language/코드 포매팅 (Code formatting).md b/Programming & Language/코드 포매팅 (Code formatting).md
deleted file mode 100644
index 4effb11f..00000000
--- a/Programming & Language/코드 포매팅 (Code formatting).md	
+++ /dev/null
@@ -1,39 +0,0 @@
----
-id: P-REINFORCE-AUTO-C0F871
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - 코드 포매팅 (Code formatting)"
----
-
-# [[코드 포매팅 (Code formatting)]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 코드 포매팅(Code formatting)은 소스 코드를 정해진 코딩 스타일 가이드나 컨벤션에 맞게 일관된 형태로 변환하는 과정입니다 [1, 2]. 들여쓰기, 공백, 줄 바꿈, 괄호 위치 등의 시각적 요소를 조정하며 코드의 실행 의미(Semantics)나 기능은 변경하지 않습니다 [1, 3, 4]. 전용 도구를 통해 자동화되어 개발자의 생산성을 높이고, 코드의 가독성 향상 및 유지보수를 용이하게 만들어 협업 시 발생하는 혼란을 최소화하는 역할을 합니다 [5, 6].
-
-## 📖 구조화된 지식 (Synthesized Content)
-* **정의 및 주요 역할:**
-  코드 포매팅은 소스 코드의 텍스트가 일관되게 작성되도록 구조화하는 작업입니다 [4]. 변수 명명 규칙 등 코드의 기능적 측면에 영향을 주지 않으면서 줄의 최대 길이 설정, 작은따옴표와 큰따옴표의 통일, 세미콜론 작성 등 코드가 시각적으로 깔끔하게 보이도록 정리하는 데 중점을 둡니다 [7].
-* **가독성 및 유지보수성 향상:**
-  일관되고 잘 포매팅된 코드는 코드의 구조, 논리적 흐름 및 구성 요소 간의 관계를 개발자가 빠르게 파악할 수 있도록 돕습니다 [5]. 이는 인지적 부하를 줄여주며, 개발자들이 스타일의 차이에서 오는 방해 요소 없이 코드 로직 자체에 집중할 수 있게 하여 효율적인 코드 리뷰와 원활한 협업을 가능하게 합니다 [6, 8, 9]. 
-* **자동화 도구 및 파이프라인 연동:**
-  현대의 개발 환경에서는 JavaScript/TypeScript를 위한 Prettier, Python을 위한 Black, Go를 위한 gofmt 등과 같은 의견이 강한(Opinionated) 전용 포매터 도구를 사용합니다 [2, 8, 10, 11]. 이러한 도구들은 Git Hook을 관리하는 Husky 및 `lint-staged` 등과 결합되어, 코드가 버전 관리 시스템에 커밋되기 전(pre-commit) 변경된 파일에 대해서만 자동으로 포매팅 규칙을 강제하도록 설정할 수 있습니다 [11-13].
-* **Linter와의 차이점 및 충돌 해결:**
-  ESLint와 같은 린터(Linter)는 문법적 오류나 잠재적 버그를 찾는 코드 품질 보장에 목적을 두는 반면, 포매터(Formatter)는 시각적인 코드 스타일에 집중합니다 [4, 7]. 린터 내부에도 코드 스타일 규칙이 존재하기 때문에 두 도구를 병행 사용할 경우 충돌이 발생할 수 있습니다 [14, 15]. 이를 해결하기 위해 `eslint-config-prettier`와 같은 패키지를 사용해 포매터와 충돌하는 린터의 스타일 규칙을 비활성화하고 포매팅 역할을 완전히 위임하는 방식이 권장됩니다 [14-16].
-* **코드 스타일로메트리(Code Stylometry)에 미치는 영향:**
-  코드 포매팅은 들여쓰기와 공백 사용 등 개발자 고유의 코딩 스타일 특징을 정규화시켜버리기 때문에, 소스 코드를 분석하여 작성자를 식별하는 기술인 '코드 스타일로메트리'의 식별 정확도를 유의미하게 감소시킵니다(연구에 따르면 정확도가 68%에서 53%로 하락) [17, 18].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[Prettier]], [[Linter (린터)]], [[정적 분석 (Static Analysis)]], [[코드 스타일로메트리 (Code Stylometry)]]
-- **Projects/Contexts:** 팀 단위 개발 환경에서 [[Git Hook (Husky)]]과 [[lint-staged]]를 CI/CD 파이프라인에 연동하여 커밋 시점에 자동으로 포매팅이 적용되도록 강제하는 업무 맥락 [11-13].
-- **Contradictions/Notes:** Linter와 Formatter를 동시에 사용할 때 두 도구 모두 코드 스타일을 검사할 수 있어 규칙 충돌 현상이 발생할 수 있으므로, 코드 포매팅은 전적으로 Prettier 등의 포매터에 맡기고 Linter의 포매팅 기능은 끄도록 설정하는 것이 바람직합니다 [6, 14, 19].
-
----
-*Last updated: 2026-04-19*
-- Raw Source: [[00_Raw/2026-04-20/코드 포매팅 (Code formatting).md]]
----
diff --git a/Programming & Language/코드 품질 관리 및 자동화 (Code Quality Management and Automation).md b/Programming & Language/코드 품질 관리 및 자동화 (Code Quality Management and Automation).md
deleted file mode 100644
index a1920d4b..00000000
--- a/Programming & Language/코드 품질 관리 및 자동화 (Code Quality Management and Automation).md	
+++ /dev/null
@@ -1,33 +0,0 @@
----
-id: P-REINFORCE-AUTO-A84338
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - 코드 품질 관리 및 자동화 (Code Quality Management and Automation)"
----
-
-# [[코드 품질 관리 및 자동화 (Code Quality Management and Automation)]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 코드 품질 관리 및 자동화는 린터(Linter), 포매터(Formatter), SAST(정적 애플리케이션 보안 테스트) 등의 도구를 활용하여 소스 코드의 문법적 오류, 스타일 일관성, 보안 취약점을 식별하고 수정하는 프로세스이다 [1-3]. 이를 Husky, lint-staged와 같은 도구와 결합하여 CI/CD 파이프라인 또는 Git 훅에 통합함으로써 개발 초기 단계에서 결함을 예방하는 '시프트 레프트(Shift-Left)' 보안 및 품질 검증을 수행한다 [4-6]. 최근에는 이러한 자동화 검사와 인간의 문맥적 이해가 필요한 수동 리뷰를 결합한 하이브리드 접근법이 표준적인 개발 문화로 자리 잡고 있다 [7, 8].
-
-## 📖 구조화된 지식 (Synthesized Content)
-* **코드 품질 검사 및 포매팅 자동화:** ESLint와 같은 린터는 코드의 논리적 오류와 문법을 정적으로 분석하여 품질을 보장하고, Prettier와 같은 포매터는 코드의 들여쓰기와 줄 바꿈 등 시각적 스타일을 일관되게 강제한다 [1, 9-11]. 이 두 도구가 충돌하지 않도록 `eslint-config-prettier` 등을 통해 조율하며, Husky와 `lint-staged`를 활용해 Git의 커밋 전(pre-commit) 단계에서 변경된 파일만 빠르고 자동으로 검사하도록 구성하여 개발자의 인지 부하를 줄인다 [12-16]. 모노레포 환경에서는 중앙 집중식 규칙 패키지를 구성해 설정 중복을 피하고 유지 보수성을 높인다 [17, 18].
-* **SAST(정적 애플리케이션 보안 테스트)의 통합:** SAST는 애플리케이션 실행 전 소스 코드 단계에서 보안 취약점(예: SQL 인젝션, 하드코딩된 비밀번호 등)을 검출하는 화이트박스 테스트 방식이다 [19, 20]. Snyk Code, SonarQube, Checkmarx와 같은 SAST 도구들을 CI/CD 파이프라인이나 IDE 플러그인 형태로 통합하여 개발 사이클 초기에 보안 문제를 식별하고 수정하도록 한다 [21-23]. 최근에는 대규모 언어 모델(LLM)과 기계 학습을 결합해 복잡한 데이터 흐름 및 오탐(False Positive)을 줄이고 자동 수정(Auto-fix)을 제안하는 AI 기반 SAST 도구로 진화하고 있다 [24-26].
-* **자동화와 수동 코드 리뷰의 하이브리드 모델:** 자동화된 코드 리뷰는 대규모 코드베이스에 대해 일관되고 빠른 스캔을 제공하지만, 비즈니스 로직, 아키텍처적 절충안, 복잡한 시스템 간 종속성을 이해하는 데는 맹점이 있다 [27, 28]. 반면 수동 리뷰는 코드의 가독성을 높이고 컨텍스트를 고려할 수 있지만 시간과 비용이 많이 소요된다 [29, 30]. 따라서 구문 오류, 코드 스타일, 패턴화된 보안 취약점 식별 등 기계적 검증은 자동화 도구에 일임하고, 인간 리뷰어는 아키텍처 설계와 비즈니스 로직 검증에 집중하는 '하이브리드 코드 리뷰'가 고품질 소프트웨어 개발을 위한 핵심 전략이다 [7, 31-33].
-* **AI 도입에 따른 코드 거버넌스 및 위험 관리:** AI 기반 코드 생성기 및 리뷰 도구의 사용이 급증함에 따라, 무분별한 코드 생성으로 인한 보안 취약점 및 품질 저하를 방지하기 위해 'AI 사용 정책(Usage Policy)' 수립이 필수적이다 [34, 35]. 여기에는 민감 데이터의 퍼블릭 모델 입력 금지, 승인된 도구 사용, 인간의 최종 책임(Human-in-the-loop) 원칙이 포함된다 [35-38]. 또한 자동화 파이프라인 구축 시 도구 자체에 대한 공급망 공격(예: `eslint-config-prettier` 악성 코드 주입 공격인 CVE-2025-54313 사례) 위협을 인지하고 개발 도구 체인의 보안도 철저히 관리해야 한다 [39, 40].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[정적 애플리케이션 보안 테스트 (SAST)]], [[수동 코드 리뷰 (Manual Code Review)]], [[지속적 통합 및 지속적 배포 (CI/CD)]], [[린터와 포매터 (Linters and Formatters)]]
-- **Projects/Contexts:** Git pre-commit 훅 환경에서 Husky와 lint-staged를 활용한 검증 파이프라인 자동화 구성, Turborepo 등 모노레포에서의 중앙 집중식 린트 환경 구축, Snyk 및 SonarQube를 통한 DevSecOps 도입 사례.
-- **Contradictions/Notes:** 자동화 도구는 빠르고 일관된 스캔을 보장하지만, 코드의 비즈니스 의도나 아키텍처적 맥락(Context Blindness)을 파악하지 못해 최대 30~60%의 높은 오탐률(False Positives)을 낼 수 있으며 실제 취약점의 약 22%가량을 놓칠 수 있으므로 아키텍처 및 고위험 영역에 대한 인간의 검토가 반드시 병행되어야 한다 [27, 41].
-
----
-*Last updated: 2026-04-19*
-- Raw Source: [[00_Raw/2026-04-20/코드 품질 관리 및 자동화 (Code Quality Management and Automation).md]]
----
diff --git a/Programming & Language/코스모스(Cosmos).md b/Programming & Language/코스모스(Cosmos).md
deleted file mode 100644
index bb5fef99..00000000
--- a/Programming & Language/코스모스(Cosmos).md	
+++ /dev/null
@@ -1,44 +0,0 @@
----
-id: P-REINFORCE-AUTO-2F7488
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - 코스모스(Cosmos)"
----
-
-# [[코스모스(Cosmos)]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-* **플랫폼 도입 배경 및 목적:** 
-넷플릭스는 이전에 파트너와 스튜디오에서 들어오는 미디어 파일을 처리하기 위해 'Reloaded'라는 모놀리식 아키텍처를 사용했습니다 [4]. 하지만 개발자 규모가 늘어나고 처리 규모가 10배 이상 커지면서, 기존 아키텍처는 기능 배포를 지연시키고 운영에 큰 부담을 주는 부채가 되었습니다 [2]. 이에 대응하기 위해 인프라와 애플리케이션 코드가 뒤섞이는 문제를 해결하고, 워크플로우 중심의 미디어 특화 마이크로서비스를 위한 새로운 플랫폼인 코스모스를 개발하게 되었습니다 [2, 3, 5].
-
-* **관심사의 분리(Separation of Concerns) 구조:** 
-코스모스는 두 가지 축으로 관심사를 분리합니다. 첫째, 로직을 API, 워크플로우, 서버리스 함수로 분할합니다 [6]. 둘째, 플랫폼과 애플리케이션을 분리하여 애플리케이션 개발자가 분산 컴퓨팅의 복잡한 세부 사항(데이터 배포 등)을 몰라도 미디어 특화 추상화를 통해 비즈니스 로직에만 집중할 수 있게 합니다 [6].
-
-* **주요 하위 시스템(Subsystems):** 
-도메인 특화 및 확장 독립적(scale-agnostic)인 컴포넌트들은 다음의 세 가지 확장 인지(scale-aware) 하위 시스템 위에서 동작합니다 [6, 7].
-  * **옵티머스(Optimus):** 외부 요청을 내부 비즈니스 모델로 매핑하는 API 계층입니다 [7].
-  * **플라토(Plato):** 비즈니스 규칙 모델링을 위한 워크플로우 계층으로, 'Emirax'(Groovy 기반 도메인 특화 언어)를 사용하는 전진 추론(forward chaining) 규칙 엔진입니다 [7-9].
-  * **스트라툼(Stratum):** 상태가 없고 계산 집약적인 알고리즘을 실행하기 위해 호출되는 서버리스 계층입니다 [7]. 
-  * 이 하위 시스템들은 대규모, 저지연의 우선순위 큐 시스템인 **타임스톤(Timestone)**을 통해 비동기적으로 서로 통신합니다 [7].
-
-* **워크로드 처리 전략:** 
-코스모스는 사용자 대기 시간이 중요한 '지연 시간에 민감한(Latency-sensitive)' 워크로드와 자원을 대량 소비하며 하루당 처리량이 중요한 '처리량에 민감한(Throughput-sensitive)' 워크로드를 모두 지원합니다 [1, 10, 11]. 특히 지연 시간을 관리하기 위해 자원 풀(Resource pools), 사전 컴퓨팅 자원 확보(Warm capacity), 마이크로 배치(Micro-batches), 작업 우선순위(Priority) 지정 등의 메커니즘을 사용합니다 [12].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[Microservices]], [[Serverless Computing]], [[Separation of Concerns]], [[Workflow]]
-- **Projects/Contexts:** [[Netflix Media Cloud Engineering]], [[Reloaded (Netflix Legacy System)]], [[Tapas (Netflix Service)]]
-- **Contradictions/Notes:** 넷플릭스는 기존의 거대하고 복잡한 레거시 시스템(Reloaded)에서 코스모스로 전환하는 데 따른 위험을 줄이기 위해, 새로운 시스템이 기존 시스템을 둘러싸면서 점진적으로 완전히 대체하는 스트랭글러 피그(strangler fig) 패턴을 채택했습니다 [13]. 한편 "마이크로서비스가 워크플로우를 트리거하고 서버리스 함수를 오케스트레이션한다"는 코스모스의 프로그래밍 모델은 대부분의 사용 사례에 효과적이지만, 너무 단순한 애플리케이션의 경우에는 오히려 추가되는 복잡성이 이점보다 클 수 있다고 지적됩니다 [14].
-
----
-*Last updated: 2026-04-18*
-- Raw Source: [[00_Raw/2026-04-20/코스모스(Cosmos).md]]
----
diff --git a/Programming & Language/클로저(Closures).md b/Programming & Language/클로저(Closures).md
deleted file mode 100644
index d930e2ba..00000000
--- a/Programming & Language/클로저(Closures).md	
+++ /dev/null
@@ -1,33 +0,0 @@
----
-id: P-REINFORCE-AUTO-7F81A9
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - 클로저(Closures)"
----
-
-# [[클로저(Closures)]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 클로저(Closures)는 중첩된 함수가 접근할 수 있는 로컬 변수를 포함하는 자바스크립트 스코프를 의미합니다 [1]. 클로저는 가비지 컬렉션(GC)의 루트(Root) 역할을 수행하므로, 활성화된 클로저가 참조하는 객체나 변수는 메모리에서 해제되지 않고 유지됩니다 [2, 3]. 다수의 클로저가 스코프를 공유하거나 비동기 처리 과정에서 불필요하게 큰 객체를 캡처할 경우 심각한 메모리 누수를 발생시키는 주요 원인이 됩니다 [4, 5].
-
-## 📖 구조화된 지식 (Synthesized Content)
-* **내부 구조 및 GC 루트 역할:** V8 엔진 내부에서 클로저의 로컬 변수들은 `system / Context` 유형의 내부 객체에 저장됩니다 [1]. 클로저는 전역 객체(window), 활성화된 이벤트 리스너, 타이머 등과 함께 가비지 컬렉션의 루트(GC roots)로 기능합니다 [2, 3]. 즉, 활성화된 클로저가 참조하고 있는 데이터는 가비지 컬렉터에 의해 회수될 수 없습니다 [2].
-* **스코프 유지로 인한 메모리 누수 (Closure Scope Retention):** 여러 클로저가 동일한 스코프를 공유할 때, V8은 이들을 위해 단일 스코프 객체를 생성합니다 [4]. 만약 하나의 클로저가 특정 변수를 참조하면, 해당 변수는 공유 스코프 객체 내에 남아 다른 클로저의 수명 동안에도 계속 유지됩니다 [4]. 예를 들어, 하나의 타이머 콜백이 변수를 참조하고 형제 클로저가 거대한 배열을 캡처한 경우, 타이머 콜백이 살아있는 동안 그 큰 배열 역시 메모리에 계속 남아 누수를 유발하게 됩니다 [4].
-* **비동기 체인 및 타이머 콜백의 위험성:** 비동기 체인 환경에서 전체 요청(request)이나 응답(response) 객체를 클로저에 캡처하게 되면, 클로저가 요청 수명 주기(request lifecycle)를 초과하여 유지될 때 불필요한 메모리를 점유하게 됩니다 [5]. 또한, 대상을 삭제한 후에도 연결을 끊지 않은 `setInterval`이나 Observer의 콜백 클로저들은 참조하는 모든 데이터와 함께 무기한 살아남아 메모리 누수를 일으킵니다 [6].
-* **클로저의 디버깅 및 프로파일링 방법:** Chrome DevTools 등의 힙 스냅샷(Heap snapshot) 도구에서 'Containment view'를 사용하면 함수 클로저 내부를 들여다보고 객체가 메모리에 남게 된 원인을 저수준에서 분석할 수 있습니다 [7, 8]. 또한, 스냅샷에서 여러 클로저를 쉽게 구별하고 추적하려면 익명 함수 대신 이름을 지정해 주는 방식(Named functions)이 매우 효과적입니다 [9].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[Garbage Collection]], [[Memory Leaks]], [[GC Roots]], [[system / Context]]
-- **Projects/Contexts:** [[Heap Snapshots]]를 활용한 메모리 프로파일링 및 브라우저/Node.js 환경의 누수 디버깅
-- **Contradictions/Notes:** 소스에 관련 정보가 부족합니다.
-
----
-*Last updated: 2026-04-19*
-- Raw Source: [[00_Raw/2026-04-20/클로저(Closures).md]]
----
diff --git a/Programming & Language/타임라인 할당 계측(Allocation instrumentation on timeline).md b/Programming & Language/타임라인 할당 계측(Allocation instrumentation on timeline).md
deleted file mode 100644
index 02c74036..00000000
--- a/Programming & Language/타임라인 할당 계측(Allocation instrumentation on timeline).md	
+++ /dev/null
@@ -1,35 +0,0 @@
----
-id: P-REINFORCE-AUTO-733CA6
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - 타임라인 할당 계측(Allocation instrumentation on timeline)"
----
-
-# [[타임라인 할당 계측(Allocation instrumentation on timeline)]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 타임라인 할당 계측(Allocation instrumentation on timeline)은 Chrome 및 Microsoft Edge DevTools의 메모리(Memory) 패널에서 제공하는 성능 프로파일링 도구로, 특정 기간 동안 발생하는 모든 메모리 할당을 스택 트레이스와 함께 기록합니다 [1-3]. 힙 프로파일러의 상세한 스냅샷 정보와 타임라인 패널의 점진적 업데이트 및 추적 기능을 결합한 것이 특징입니다 [2, 3]. 이 도구는 정상적으로 가비지 컬렉션(GC)되지 않고 메모리에 남아 메모리 누수를 일으키는 객체와 해당 객체의 생성 위치를 시각적으로 추적하고 식별하는 데 주로 사용됩니다 [1, 2, 4, 5].
-
-## 📖 구조화된 지식 (Synthesized Content)
-* **기록 방식 및 고유 식별자:** 이 도구는 기록이 진행되는 동안 주기적으로(최대 50ms마다 한 번씩) 힙 스냅샷을 캡처하며, 기록이 끝날 때 마지막으로 하나의 최종 스냅샷을 캡처합니다 [6-8]. 캡처된 각 객체에는 `@` 기호 뒤에 영구적인 객체 ID가 부여되어 여러 스냅샷 간에 힙 상태를 정밀하게 비교할 수 있도록 지원합니다 [6, 8, 9]. 객체는 가비지 컬렉션 중에 이동할 수 있으므로, 메모리 주소 대신 이 고유 ID를 사용하는 것이 추적에 유리합니다 [6, 8].
-* **타임라인 막대(Bar)의 시각적 의미:** 타임라인 상단에는 힙에서 새로운 객체가 할당된 시점을 나타내는 막대들이 표시됩니다 [7, 10, 11].
-  * **막대의 높이:** 특정 시점에 할당된 객체들의 전체 크기(size)를 나타냅니다 [7, 10, 11].
-  * **파란색 막대(Blue bars):** 할당된 객체가 타임라인 기록 종료 시점까지 메모리에 살아있음(live)을 의미하며, 이는 메모리가 해제되지 않고 남아 있는 메모리 누수 후보를 나타냅니다 [1, 7, 10-13].
-  * **회색 막대(Gray bars):** 할당되었으나 이후 가비지 컬렉터에 의해 성공적으로 수거(GC)된 객체를 의미합니다 [1, 7, 10-12].
-* **분석 및 누수 원인 추적:** 타임라인에서 파란색 막대가 나타나는 특정 시간대를 마우스로 드래그하여 확대(Zoom in)하면, 해당 시간 창(time window) 내에 할당된 객체들만 '생성자(Constructor)' 창에 필터링됩니다 [1, 12, 14, 15]. 특정 생성자나 객체를 클릭하면 해당 객체가 생성된 정확한 코드 위치를 나타내는 스택 트레이스(Allocation stack)를 확인할 수 있습니다 [1, 15-17]. 또한 '유지 경로(Retainers)' 패널을 통해 해당 객체를 메모리에 살아있게 만드는 참조 체인(Retaining tree)을 파악하여, 불필요하게 객체를 참조하고 있는 코드의 근본적인 원인을 파악하고 수정할 수 있습니다 [1, 13, 14, 18, 19].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[메모리 누수(Memory leak)]], [[가비지 컬렉션(Garbage Collection)]], [[힙 스냅샷(Heap snapshot)]], [[스택 트레이스(Stack trace)]]
-- **Projects/Contexts:** [[Chrome DevTools]], [[Microsoft Edge DevTools]], [[Node.js 성능 디버깅]]
-- **Contradictions/Notes:** 소스에 관련 정보가 부족합니다.
-
----
-*Last updated: 2026-04-19*
-- Raw Source: [[00_Raw/2026-04-20/타임라인 할당 계측(Allocation instrumentation on timeline).md]]
----
diff --git a/Programming & Language/타입 가드 (Type Predicates).md b/Programming & Language/타입 가드 (Type Predicates).md
deleted file mode 100644
index 56fa09ff..00000000
--- a/Programming & Language/타입 가드 (Type Predicates).md	
+++ /dev/null
@@ -1,33 +0,0 @@
----
-id: P-REINFORCE-AUTO-328E4F
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - 타입 가드 (Type Predicates)"
----
-
-# [[타입 가드 (Type Predicates)]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 타입 가드(Type Predicates)는 런타임에 반환되는 불리언(boolean) 값을 기반으로 TypeScript의 타입 시스템이 매개변수의 타입을 더 구체적으로 좁힐 수(Narrowing) 있도록 돕는 함수입니다 [1]. 주로 유니언 타입이나 알 수 없는 데이터를 다룰 때 변수가 특정 타입 구조를 만족하는지 검증하기 위해 사용됩니다 [2, 3]. 다만 TypeScript 컴파일러는 타입 가드 내부의 검증 로직이 정확한지까지는 확인하지 않으므로, 개발자 스스로 로직의 정확성을 보장해야 합니다 [1].
-
-## 📖 구조화된 지식 (Synthesized Content)
-- **기본 개념과 역할:** 타입 가드 함수는 런타임에는 불리언 값을 반환하지만, 타입 시스템에게는 반환 결과를 바탕으로 타입 좁히기(Type narrowing)를 적용해야 함을 알려주는 역할을 합니다 [1]. `unknown` 변수를 분석하거나 유니언 타입 중에서 특정 타입을 구별할 때, 데이터의 타입을 확신할 수 있게 해주는 안전한 도구로 활용됩니다 [2, 3].
-- **사용 문법과 동작:** 커스텀 타입 가드 함수를 정의할 때는 반환 타입 위치에 `is` 키워드(예: `value is Positive`)를 사용하는 특수한 문법을 적용합니다 [1-3]. `if` 조건문 내에서 이 함수를 호출하여 `true`가 반환되면, TypeScript는 해당 조건 블록 내에서 값이 타입 가드가 보장하는 구체적인 타입임을 인지하게 됩니다 [1]. 커스텀 함수 외에도 `typeof`나 `instanceof`, `in` 연산자 역시 타입 가드로 동작하여 자동으로 타입을 좁혀줍니다 [3, 4].
-- **Branded Types 생성 및 단언 함수와의 결합:** 브랜디드 타입(Branded Types)처럼 구조적으로 동일하지만 의미가 다른 타입을 명시할 때, 불안전한 `as` 단언(assertion) 대신 타입 가드 함수를 사용하여 유효성을 검증하는 것이 더 안전한 접근법입니다 [1, 5]. 또한 `if` 래퍼(wrapper)를 작성해야 하는 단점을 보완하기 위해, 값이 일치하지 않으면 에러를 던지는 타입 단언 함수(Assertion Functions)와 결합하여 사용하기도 합니다 [6].
-- **한계점 및 주의사항:** 타입 가드는 코드 상에서 조건문 래퍼(`if` 구문 등)를 요구하기 때문에 `as` 단언에 비해 작성 공간을 더 차지하고 런타임 로직이 추가된다는 단점이 있습니다 [6]. 무엇보다 TypeScript는 타입 가드의 내부 로직이 실제로 해당 타입의 의도와 정확히 일치하는지를 검사하지 않고 전적으로 코드 작성자에게 책임을 맡기기 때문에, 논리적 오류가 있을 경우 타입 안전성을 위협할 수 있습니다 [1].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[Type Narrowing]], [[Branded Types]], [[Union Types]]
-- **Projects/Contexts:** [[알 수 없는 외부 데이터 검증 (unknown types)]], [[유니언 타입 식별 및 상태 분기 처리]]
-- **Contradictions/Notes:** 브랜디드 타입 등의 값을 강제할 때 타입 가드가 `as` 단언에 비해 "종종 더 안전한 방법"으로 소개되기도 하나 [5], 정작 컴파일러가 타입 가드의 내부 구현 로직을 검증해 주지 않기 때문에 본질적으로는 `as` 단언보다 훨씬 더 타입에 안전하다고 볼 수는 없다는 주의 사항이 함께 언급됩니다 [1].
-
----
-*Last updated: 2026-04-18*
-- Raw Source: [[00_Raw/2026-04-20/타입 가드 (Type Predicates).md]]
----
diff --git a/Programming & Language/타입 가드(Type Guards).md b/Programming & Language/타입 가드(Type Guards).md
deleted file mode 100644
index 66561613..00000000
--- a/Programming & Language/타입 가드(Type Guards).md	
+++ /dev/null
@@ -1,33 +0,0 @@
----
-id: P-REINFORCE-AUTO-05AFCC
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - 타입 가드(Type Guards)"
----
-
-# [[타입 가드(Type Guards)]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 타입 가드(Type Guards)는 TypeScript에서 유니언(Union) 타입이나 `unknown` 타입의 변수를 다룰 때 특정 타입을 구별해 내기 위해 사용되는 메커니즘입니다 [1, 2]. 런타임에 실행되는 검사를 바탕으로 TypeScript의 타입 시스템이 자동으로 타입을 좁히도록(Narrowing) 유도합니다 [1, 3]. 이를 통해 개발자는 알 수 없는 변수를 분석할 때 해당 변수의 타입을 확신을 가지고 안전하게 식별할 수 있습니다 [4].
-
-## 📖 구조화된 지식 (Synthesized Content)
-- **커스텀 타입 가드 (타입 서술어, Type Predicates):** 커스텀 타입 가드는 일반 함수와 유사하게 동작하지만, 반환 값에 `is` 키워드를 활용하는 특수한 구문을 가집니다 [1, 5]. 이 함수는 런타임에 불리언(boolean) 값을 반환하며, 타입 시스템은 이 반환 값을 근거로 매개변수가 특정 타입인지 판단하여 타입을 좁힙니다 [3].
-- **내장 타입 가드 (`typeof` 및 `instanceof`):** 커스텀 함수 외에도 TypeScript는 `typeof` 및 `instanceof` 연산자를 활용한 검사를 타입 가드로 자동 인식합니다 [1]. `typeof`를 통해 `"number"`, `"string"` 등의 원시 타입을 좁힐 수 있으며, `instanceof`를 사용할 경우 우변의 생성자 함수 프로토타입을 기준으로 타입을 좁혀줍니다 [1].
-- **`unknown` 및 유니언(Union) 타입 제어:** 유니언 타입을 다룰 때 반복적이고 이상적이지 않은 타입 단언(Type assertions)을 피하기 위해 타입 가드가 필요합니다 [1]. 특히 `unknown` 타입의 변수는 `typeof`, `instanceof` 또는 커스텀 타입 가드를 통해 먼저 타입을 좁히지 않으면 사용할 수 없으므로, 안전한 코드 작성을 위해 필수적으로 사용됩니다 [2].
-- **식별 가능한 유니언(Discriminated Unions)과의 활용:** 식별 가능한 유니언 패턴을 처리할 때도 재사용이 가능한 전용 타입 가드를 생성하여 더욱 안전하게 타입을 검증할 수 있습니다 [6].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[Type Narrowing]], [[Type Predicates]], [[Unknown Type]], [[Discriminated Unions]]
-- **Projects/Contexts:** [[API 응답 등 외부의 불확실한 데이터 구조 검증 및 처리]]
-- **Contradictions/Notes:** 타입 서술어(Type predicates) 형태의 커스텀 타입 가드는 타입 단언(as assertions)보다 훨씬 타입에 안전한 편은 아니며, TypeScript는 타입 가드 내부의 논리가 해당 브랜드 타입의 의도와 완벽히 일치하는지까지 검증하지 않으므로 전적으로 코드 작성자에게 책임이 위임됩니다 [3].
-
----
-*Last updated: 2026-04-18*
-- Raw Source: [[00_Raw/2026-04-20/타입 가드(Type Guards).md]]
----
diff --git a/Programming & Language/타입 단언 (Type Assertions).md b/Programming & Language/타입 단언 (Type Assertions).md
deleted file mode 100644
index af126cbf..00000000
--- a/Programming & Language/타입 단언 (Type Assertions).md	
+++ /dev/null
@@ -1,40 +0,0 @@
----
-id: P-REINFORCE-AUTO-FE3FC7
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - 타입 단언 (Type Assertions)"
----
-
-# [[타입 단언 (Type Assertions)]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 타입 단언(Type Assertions)은 개발자가 TypeScript 컴파일러보다 특정 값의 타입 정보를 더 잘 알고 있을 때, 컴파일러에게 해당 값을 특정 타입으로 간주하도록 지시하는 기능이다 [1, 2]. 런타임에는 데이터에 어떠한 영향도 주지 않고 오직 컴파일 과정에서만 작용하며 주로 `as` 키워드가 사용된다 [2]. 그러나 컴파일러의 타입 검증을 우회하므로 잘못 사용될 경우 런타임 오류의 원인이 될 수 있어 주의가 필요하다 [3, 4].
-
-## 📖 구조화된 지식 (Synthesized Content)
-*   **개념과 동작 방식:** 
-    타입 단언은 다른 프로그래밍 언어의 타입 캐스팅(Type Casting)과 비슷한 역할을 수행하지만, 런타임에 데이터의 구조를 변경하거나 특별한 검사를 수행하지 않는다 [2]. TypeScript가 코드 문맥만으로는 유추할 수 없는 타입 정보를 개발자가 강제로 부여할 때 사용되며, JSX/TSX 환경에서는 `as` 문법만이 지원된다 [1, 2]. 또한, 변수나 속성 뒤에 붙여 해당 값이 절대로 `null`이나 `undefined`가 아님을 컴파일러에게 확신시킬 때 사용하는 Non-null 단언 연산자(`!`) 역시 타입 단언의 일종이다 [5].
-
-*   **주요 활용 맥락:** 
-    타입 단언은 런타임 유효성 검사를 이미 마쳐 개발자가 타입 안전성을 확신할 수 있는 경우, DOM 요소를 조작하며 타입을 좁혀야 하는 경우, 또는 타입 정의가 불완전한 서드파티 라이브러리와 통신할 때 주로 사용된다 [4, 6]. 이 외에도 구조적으로 동일한 기본 타입을 구분하여 사용하는 브랜디드 타입(Branded Types) 패턴에서, 일반 값을 브랜디드 타입의 인스턴스로 취급할 때 컴파일러에 의도를 전달하는 목적으로 활용된다 [1, 7, 8].
-
-*   **위험성과 한계점:** 
-    `as` 키워드를 활용한 타입 단언은 개발자가 실수하더라도 타입 에러를 내지 않게 만들어 심각한 런타임 버그로 이어질 수 있다 [3, 4]. 대표적으로 객체 리터럴을 단언할 때에는 초과 속성 검사(Excess Property Checks)가 작동하지 않으므로, 정의되지 않은 잉여 속성이 포함되어 있어도 에러가 발생하지 않는다 [9]. 또한 완전히 호환되지 않는 타입(예: 필수 속성 누락) 간의 단언은 컴파일러가 막아주지만, 이를 억지로 피하기 위해 값을 `unknown`으로 먼저 캐스팅한 후 원하는 타입으로 단언하는 방식은 타입 안전성을 완전히 무너뜨리므로 권장되지 않는다 [10].
-
-*   **안전한 대안적 접근:** 
-    이러한 타입 단언의 한계를 피하기 위해 여러 대안이 활용된다. 변수나 객체를 정의할 때 무분별한 `as` 대신 명시적인 타입 선언(Type Declaration)을 사용하는 것이 좋으며, 구체적인 리터럴 타입의 형태를 잃지 않으면서도 객체의 구조와 초과 속성을 엄격히 검사하는 `satisfies` 연산자를 활용하는 것이 권장된다 [11-13]. 브랜디드 타입을 사용할 때도 단순히 타입 단언을 쓰기보다는, 조건에 맞지 않을 때 오류를 던져주는 타입 검증 함수(Assertion Functions)를 구현하여 사용하는 것이 더 안전한 방식이다 [14, 15].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[satisfies 연산자]], [[브랜디드 타입 (Branded Types)]], [[타입 캐스팅 (Type Casting)]], [[초과 속성 검사 (Excess Property Checks)]]
-- **Projects/Contexts:** [[DOM 요소 조작]], [[서드파티 라이브러리 및 API 연동]]
-- **Contradictions/Notes:** 타입 단언(`as`)은 코딩 시 편리함을 제공하지만, 컴파일러의 엄격한 타입 유효성 및 초과 속성 검사를 우회해버리는 치명적인 단점이 있다. 따라서 최근 TypeScript 생태계에서는 이 단점을 극복하고 구체적인 추론과 검사를 동시에 수행하는 `satisfies` 연산자가 더 나은 대안으로 평가된다 [9, 13].
-
----
-*Last updated: 2026-04-18*
-- Raw Source: [[00_Raw/2026-04-20/타입 단언 (Type Assertions).md]]
----
diff --git a/Programming & Language/타입 단언(Type Assertion).md b/Programming & Language/타입 단언(Type Assertion).md
deleted file mode 100644
index c233d253..00000000
--- a/Programming & Language/타입 단언(Type Assertion).md	
+++ /dev/null
@@ -1,37 +0,0 @@
----
-id: P-REINFORCE-AUTO-742CFD
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - 타입 단언(Type Assertion)"
----
-
-# [[타입 단언(Type Assertion)]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 타입 단언(Type Assertion)은 개발자가 TypeScript 컴파일러보다 값의 타입에 대해 더 잘 알고 있을 때, 컴파일러에게 특정 값의 타입을 명시적으로 지정하여 이를 신뢰하도록 지시하는 기능입니다 [1, 2]. 런타임 동작이나 데이터 구조를 실제로 변경하지 않으며, 오직 컴파일 타임의 타입 검사에만 사용됩니다 [2]. 그러나 컴파일러의 안전성 검사를 우회하게 만들어 런타임 에러를 유발할 수 있으므로, 사용에 각별한 주의가 요구됩니다 [1, 3].
-
-## 📖 구조화된 지식 (Synthesized Content)
-- **기본 메커니즘 및 문법:** 타입 단언은 다른 프로그래밍 언어의 타입 캐스트(Type Cast)와 유사하지만, 데이터에 대한 특별한 런타임 검사나 구조적 재구성을 수행하지 않습니다 [2]. 일반적으로 `as` 키워드를 사용하여 표현하며(예: `value as Type`), 이 문법은 JSX 및 TSX 환경에서 유일하게 지원되는 타입 단언 방식입니다 [2].
-- **주요 사용 사례:** 컴파일러가 스스로 코드의 타입을 정확히 추론할 수 없는 상황에서 활용됩니다 [4]. 외부 데이터(API 응답 등)에 대해 런타임 검증을 마친 후 타입을 확신할 수 있을 때, 혹은 DOM 조작 시 제한적으로 사용하는 것이 권장됩니다 [1]. 또한, 런타임에는 존재하지 않는 고유 속성을 부여하는 브랜디드 타입(Branded Types)의 인스턴스를 간단하게 단언할 때도 유용하게 쓰입니다 [4]. 
-- **위험성 및 한계:** 타입 단언은 개발자의 판단이 틀렸을 경우에도 컴파일러가 에러를 발생시키지 않고 넘어가게 만들어, 런타임 시 치명적인 에러로 직결될 수 있습니다 [1, 3]. 특히 `as` 키워드를 사용하면 객체가 대상 타입과 근본적으로 호환되지 않는 경우가 아니라면 '잉여 속성 검사(Excess Property Checking)'가 작동하지 않아, 의도치 않은 잉여 속성이 포함되더라도 이를 잡아내지 못하는 문제가 발생합니다 [5, 6].
-- **대안 및 안전한 접근법:** 타입 단언의 남용을 막기 위해서는 다음과 같은 대안을 고려해야 합니다.
-  1. 객체 생성 시 타입 단언 대신 명시적인 **타입 선언(Type Declaration)**을 사용하여 구조와 타입을 강제해야 합니다 [7, 8].
-  2. 구체적인 타입 리터럴을 보존하면서도 검사를 우회하지 않는 **`satisfies` 연산자**를 활용하여 `as`의 단점을 극복할 수 있습니다 [1, 9].
-  3. 안전한 런타임 검사를 위해, 조건에 맞지 않으면 에러를 던지도록 설계된 **타입 단언 함수(Type Assertion Functions)**나 **타입 가드(Type Predicates)**를 사용할 수 있습니다 [10, 11].
-- **Non-null 단언 연산자 (!):** 값이 `null`이나 `undefined`가 아님을 컴파일러에게 강제하는 연산자입니다 [12]. 값이 존재한다고 개발자가 확신할 때 사용하지만, 이 역시 안전망을 우회하는 것이므로 가급적 적게 사용해야 합니다 [12].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[Branded Types]], [[satisfies 연산자]], [[타입 선언(Type Declaration)]], [[잉여 속성 검사(Excess Property Checking)]], [[타입 가드(Type Predicates)]]
-- **Projects/Contexts:** [[외부 데이터 처리 및 DOM 조작]], [[타입 안전성이 요구되는 대규모 애플리케이션]]
-- **Contradictions/Notes:** 소스에서는 `as`를 이용한 타입 단언이 코드를 빠르게 작성하고 컴파일 에러를 넘길 수 있는 편리한 기능임을 인정하면서도, 타입스크립트의 강력한 타입 검증 혜택을 무력화하여 버그를 숨길 수 있으므로(타입 캐스팅에만 의존하지 말 것) 사용을 최소한으로 제한해야 한다고 강력히 경고하고 있습니다 [1, 3, 6, 8].
-
----
-*Last updated: 2026-04-18*
-- Raw Source: [[00_Raw/2026-04-20/타입 단언(Type Assertion).md]]
----
diff --git a/Programming & Language/타입 단언(Type Assertions).md b/Programming & Language/타입 단언(Type Assertions).md
deleted file mode 100644
index 6a8440c6..00000000
--- a/Programming & Language/타입 단언(Type Assertions).md	
+++ /dev/null
@@ -1,33 +0,0 @@
----
-id: P-REINFORCE-AUTO-113099
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - 타입 단언(Type Assertions)"
----
-
-# [[타입 단언(Type Assertions)]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 타입 단언(Type Assertions)은 개발자가 TypeScript 컴파일러에게 특정 값의 타입을 자신이 더 확실히 파악하고 있음을 명시적으로 알려주는 기능입니다. 런타임 단계에서 데이터를 검사하거나 재구성하지 않고 순수하게 컴파일러 수준의 타입 검사에만 영향을 미칩니다. 주로 `as` 키워드를 사용하여 유용하게 쓰일 수 있으나, 컴파일러의 안전성 검사를 우회하게 되므로 잘못 사용하면 조용한 런타임 에러를 유발할 수 있어 주의가 필요합니다.
-
-## 📖 구조화된 지식 (Synthesized Content)
-- **개념 및 작동 방식**: 타입 단언은 개발자가 컴파일러에게 "내가 무엇을 하고 있는지 알고 있으니 나를 믿어라"라고 지시하는 방법입니다 [1, 2]. 다른 프로그래밍 언어의 타입 캐스팅(Type Casting)과 유사하지만, 런타임 성능에 영향을 주거나 데이터를 실제로 재구성하지 않으며 오로지 컴파일러의 타입 검사 목적으로만 사용됩니다 [2]. JSX/TSX 환경에서는 `<Type>` 문법이 아닌 `as` 문법만을 지원합니다 [2].
-- **위험성 및 잠재적 문제점**: 타입 단언을 사용하면 TypeScript의 엄격한 유효성 검사를 건너뛰게 됩니다 [1, 3]. 예를 들어, `as` 키워드를 사용하면 잉여 속성 검사(Excess Property Checks)가 강제되지 않으며 특정 필수 요구사항이 누락되더라도 컴파일러가 에러를 발생시키지 않을 수 있어, 조용한 런타임 에러나 의도치 않은 동작을 유발할 수 있습니다 [4-7]. 완전히 호환되지 않는 타입으로 억지 단언을 하려 할 때만 컴파일러가 이를 거부하며, 이럴 때는 `unknown`으로 먼저 단언한 뒤 캐스팅을 해야 합니다 [8].
-- **적절한 사용 사례**: `as` 단언은 가급적 최후의 수단으로 제한적으로 사용해야 합니다 [9]. 정당하고 적절한 사용처로는 런타임 유효성 검사를 이미 마친 외부 데이터를 다룰 때, DOM 요소를 조작하며 타입을 구체적으로 좁혀야 할 때, 타입 지정이 부실한 서드파티 라이브러리와 통신할 때 등이 있습니다 [10, 11]. 또한 런타임에는 존재하지 않는 속성을 타입 시스템에만 추가하는 '브랜디드 타입(Branded Types)' 인스턴스로 값을 강제 지정할 때도 편리하게 사용됩니다 [12, 13].
-- **대안 및 연관 연산자**: 타입 단언의 남용을 막기 위해 일반적인 변수나 객체 생성 시에는 '타입 선언(Type Declaration/Annotation)'을 사용하거나, 정확한 타입 추론과 유효성 검증이 모두 필요할 때는 `satisfies` 연산자를 활용하는 것이 권장됩니다 [7, 9, 14]. 한편, 값이 절대 `null`이나 `undefined`가 아님을 단언할 때는 'Non-null 단언 연산자(`!`)'를 사용할 수 있으나, 이 역시 안전성 검사를 우회하므로 해당 값이 확실히 존재할 때만 드물게 써야 합니다 [15].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[Type Casting]], [[Satisfies Operator]], [[Branded Types]], [[Non-null Assertion Operator]], [[Type Declaration]]
-- **Projects/Contexts:** [[DOM 요소 조작 및 타입 좁히기]], [[외부 API 데이터의 런타임 검증 후 처리]], [[타입 정의가 부족한 서드파티 라이브러리 연동]]
-- **Contradictions/Notes:** 개발자는 타입 단언을 통해 손쉽게 컴파일 에러를 통과할 수 있지만, 이는 잉여 속성 검사 등을 무력화하여 시스템의 타입 안전성을 크게 훼손할 수 있습니다. 따라서 대부분의 상황에서는 타입 단언을 지양하고 '타입 선언'이나 `satisfies`를 통해 안전한 구조적 타이핑을 유지하는 것이 강하게 권장됩니다 [1, 5-7, 14].
-
----
-*Last updated: 2026-04-18*
-- Raw Source: [[00_Raw/2026-04-20/타입 단언(Type Assertions).md]]
----
diff --git a/Programming & Language/타입 서술어 (Type Predicates).md b/Programming & Language/타입 서술어 (Type Predicates).md
deleted file mode 100644
index 7e891ffd..00000000
--- a/Programming & Language/타입 서술어 (Type Predicates).md	
+++ /dev/null
@@ -1,40 +0,0 @@
----
-id: P-REINFORCE-AUTO-E4DAF5
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - 타입 서술어 (Type Predicates)"
----
-
-# [[타입 서술어 (Type Predicates)]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 타입 서술어(Type Predicates)는 매개변수가 특정 타입에 해당하는지 여부를 반환 타입을 통해 명시하는 커스텀 타입 가드 함수입니다 [1]. 런타임에는 불리언(boolean) 값을 반환하지만, 타입스크립트 컴파일러는 이 반환 값을 바탕으로 타입 좁히기(Type Narrowing)를 적용합니다 [1]. 주로 반환 타입에 `is` 키워드를 사용하여 정의되며, 런타임 검증 로직과 타입 시스템을 연결하여 변수의 타입을 안전하게 특정하는 데 유용합니다 [1-3].
-
-## 📖 구조화된 지식 (Synthesized Content)
-* **작동 방식과 문법 구성:**
-  타입 서술어는 함수 반환 타입에 `매개변수명 is 타입명` 형태의 문법을 사용합니다(예: `test is string`, `value is Percentage`) [2, 3]. 코드 내에서 이 함수가 참(`true`)을 반환하는 조건문(`if` 블록 등) 내부로 진입하면, 타입스크립트는 해당 매개변수의 타입을 지정된 구체적인 타입으로 좁혀서(narrowing) 인식하게 됩니다 [1, 3]. 
-
-* **주요 활용 사례 (브랜디드 타입 검증):**
-  구조적 타이핑 시스템의 한계를 극복하기 위해 고안된 브랜디드 타입(Branded Types)이나 불투명 타입(Opaque Types)을 다룰 때 핵심적인 역할을 합니다 [1, 2]. 예를 들어, 일반 숫자 타입(`number`) 중에서 '양수(`Positive`)'나 '백분율(`Percentage`)'과 같이 특별한 제약이 부여된 타입인지 확인할 때, 이 조건들을 검사하는 로직을 타입 서술어로 만들어 안전한 논리적 게이트를 구축할 수 있습니다 [1, 2].
-
-* **설계상의 한계와 위험성:**
-  타입 서술어는 `as` 타입 단언(Type Assertions)보다 본질적으로 더 안전하다고 볼 수는 없습니다. 타입스크립트 컴파일러는 타입 서술어 함수 내부의 검증 로직이 주장하는 타입의 의도와 실제로 일치하는지 검사하지 않으며, 전적으로 코드를 작성한 개발자의 논리에 의존하기 때문입니다 [1]. 
-
-* **가독성과 코드 공간 문제:**
-  타입 서술어 함수를 사용하려면 필연적으로 `if (isPositive(value)) { ... }`와 같이 조건부 래퍼(conditional wrappers) 코드를 작성해야 합니다 [4]. 이는 단순한 `as` 단언보다 더 많은 코드 공간을 차지하고 런타임 로직을 추가하게 만듭니다 [4]. 이러한 단점을 피하고 가독성을 높이기 위해, 조건 불일치 시 에러를 던지는 '타입 단언 함수(Assertion Functions)'를 추출하여 함께 활용하기도 합니다 [4, 5].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[Type Guards (타입 가드)]], [[Type Narrowing (타입 좁히기)]], [[Branded Types (브랜디드 타입)]], [[Type Assertion Functions (타입 단언 함수)]]
-- **Projects/Contexts:** 복잡한 유니온 타입 사이에서 특정 타입을 구별해 내거나, 숫자 및 문자열 같은 원시 타입에 제약을 부여한 브랜디드 타입의 런타임 값 유효성을 검증하고 타입스크립트 시스템에 이를 인지시킬 때 활용됩니다 [1-3].
-- **Contradictions/Notes:** 타입 서술어는 컴파일러가 알아서 타입을 안전하게 보장해 줄 것이라는 착각을 일으키기 쉽지만, 실제로는 함수 내부의 구현 로직을 타입스크립트가 검증하지 않으므로 개발자의 실수(잘못된 논리 작성)에 취약하다는 점을 주의해야 합니다 [1].
-
----
-*Last updated: 2026-04-18*
-- Raw Source: [[00_Raw/2026-04-20/타입 서술어 (Type Predicates).md]]
----
diff --git a/Programming & Language/타입 서술어(Type Predicates).md b/Programming & Language/타입 서술어(Type Predicates).md
deleted file mode 100644
index d6686fe0..00000000
--- a/Programming & Language/타입 서술어(Type Predicates).md	
+++ /dev/null
@@ -1,37 +0,0 @@
----
-id: P-REINFORCE-AUTO-4A5E0E
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - 타입 서술어(Type Predicates)"
----
-
-# [[타입 서술어(Type Predicates)]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 타입 서술어(Type Predicates)는 함수의 반환 타입을 통해 특정 매개변수가 특정 타입에 해당하는지 여부를 타입스크립트 컴파일러에 알려주는 함수입니다 [1]. 런타임에는 불리언(boolean) 값을 반환하지만, 타입 시스템은 이 반환 값을 바탕으로 타입 좁히기(Type Narrowing)를 적용합니다 [1]. 개발자는 `is` 키워드를 활용해 커스텀 타입 가드(Type Guard)를 정의할 때 이 기능을 핵심적으로 사용합니다 [2].
-
-## 📖 구조화된 지식 (Synthesized Content)
-*   **구문 및 동작 원리**: 
-    타입 서술어는 함수의 반환 타입 자리에 `매개변수명 is 특정타입`의 구문을 사용하여 정의합니다 [1, 2]. 예를 들어 `function isPercentage(x: number): x is Percentage`와 같이 작성하면, 이 함수가 `true`를 반환할 때 타입스크립트는 매개변수 `x`를 명시된 `Percentage` 타입으로 좁혀서 인식합니다 [3]. 이를 통해 `if` 문과 같은 조건부 블록 내부에서 해당 타입임이 보장된 상태로 코드를 작성할 수 있습니다 [1].
-*   **주요 활용 시나리오**: 
-    유니언 타입(Union Types)으로 묶인 여러 타입 중 특정 타입을 안전하게 구분해내야 할 때 유용하게 쓰입니다 [2]. 또한, 런타임 검사 함수에 적용되어 특정 값이 브랜디드 타입(Branded Types) 또는 불투명 타입(Opaque Types)의 인스턴스로 취급될 수 있는지 검증하고 타입 시스템과 연결하는 다리 역할을 합니다 [1, 3, 4].
-*   **안정성의 한계**: 
-    타입 서술어는 마법처럼 모든 타입 오류를 막아주지는 않습니다. 타입스크립트 컴파일러는 타입 서술어 내부의 실제 로직이 해당 타입의 의도와 정확히 일치하는지까지는 검사하지 않습니다 [1]. 따라서 이는 근본적으로 `as` 타입 단언(Type Assertion)과 유사한 수준의 타입 안정성을 가지며, 로직의 정확성은 전적으로 코드를 작성하는 개발자에게 달려 있습니다 [1].
-*   **사용 시의 단점 및 보완**: 
-    `as` 단언문에 비해 `if` 조건문 래퍼(wrapper)를 의무적으로 작성해야 하므로 코드가 차지하는 공간이 늘어나고 런타임 로직이 추가된다는 단점이 있습니다 [5]. 이러한 가독성 저하를 해결하기 위해, 조건이 맞지 않으면 에러를 던져버리는 타입 단언 함수(Type Assertion Functions)를 타입 서술어와 결합하여 코드를 간결하게 구성하기도 합니다 [5, 6].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[타입 좁히기(Type Narrowing)]], [[타입 가드(Type Guards)]], [[브랜디드 타입(Branded Types)]], [[타입 단언(Type Assertions)]]
-- **Projects/Contexts:** [[타입스크립트 애플리케이션의 런타임 값 검증 및 커스텀 타입 보장 구조 설계]]
-- **Contradictions/Notes:** 타입 서술어는 타입을 좁혀주는 훌륭한 도구이지만, 그 자체로 내부 로직의 무결성을 타입스크립트가 검증해 주지 않기 때문에 개발자가 검증 로직을 잘못 작성하면 `as` 단언처럼 타입 시스템에 치명적인 거짓 정보(타입 오류)를 제공할 위험이 있습니다 [1].
-
----
-*Last updated: 2026-04-18*
-- Raw Source: [[00_Raw/2026-04-20/타입 서술어(Type Predicates).md]]
----
diff --git a/Programming & Language/타입 안전성 (Type Safety).md b/Programming & Language/타입 안전성 (Type Safety).md
deleted file mode 100644
index d1806c72..00000000
--- a/Programming & Language/타입 안전성 (Type Safety).md	
+++ /dev/null
@@ -1,33 +0,0 @@
----
-id: P-REINFORCE-AUTO-4B2CBD
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - 타입 안전성 (Type Safety)"
----
-
-# [[타입 안전성 (Type Safety)]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 타입 안전성은 소프트웨어 개발에서 예기치 않은 런타임 오류를 방지하고 컴파일 시점에 타입을 엄격하게 검사하여 코드의 예측 가능성을 높이는 원칙이다 [1-3]. TypeScript와 같은 정적 타입 시스템에서는 구조적 타이핑, 과잉 속성 검사, 식별 가능한 유니온 등의 메커니즘을 통해 유효하지 않은 데이터나 잘못된 상태가 코드상에 표현되는 것을 원천적으로 차단한다 [4-6]. 이를 통해 개발자는 런타임 디버깅에 의존하는 대신 정적 분석을 활용하여 버그를 조기에 발견하고 견고한 아키텍처를 구축할 수 있다 [3, 7, 8].
-
-## 📖 구조화된 지식 (Synthesized Content)
-* **런타임 오류 방지와 컴파일 타임 검사:** 타입 안전성의 핵심은 런타임에 발생할 수 있는 에러를 컴파일 시점의 에러로 전환하여 미리 방지하는 것이다 [3, 7]. TypeScript의 엄격한 타입 시스템은 오타, 잘못된 인수, 누락된 속성, 안전하지 않은 null 사용 등을 코드를 작성하는 즉시 감지하여 런타임 버그를 대폭 줄여준다 [3, 9]. 또한, 제어 흐름 분석과 `never` 타입을 활용한 완전성 검사(Exhaustiveness Checking)를 통해 처리되지 않은 분기가 있을 경우 컴파일 오류를 발생시켜 빈틈없는 방어를 제공한다 [10-13].
-* **유효하지 않은 상태의 원천 차단:** 식별 가능한 유니온(Discriminated Unions) 패턴은 타입 안전성을 획기적으로 향상시킨다 [5]. 데이터가 여러 가지 형태를 가질 때 공통 판별자(Discriminant) 속성을 사용해 타입을 좁히면, 올바르지 않은 상태 조합을 구조적으로 표현 불가능하게 만들 수 있다 [14-16]. 이를 통해 개발자는 가능한 모든 경우의 수를 처리하도록 강제되어 코드의 결함을 방지할 수 있다 [6, 12].
-* **불변성을 통한 데이터 무결성 보호:** `readonly` 수식어와 유틸리티 타입을 통해 객체 및 배열의 수정을 컴파일 수준에서 금지함으로써 데이터의 불변성을 확보하는 것도 타입 안전성의 중요한 축이다 [1, 17]. 이를 통해 예상치 못한 데이터 오염을 차단하여 애플리케이션의 동작을 더 안전하고 예측 가능하게 만든다 [1, 18].
-* **구조적 타이핑과 한계 극복:** TypeScript는 구조적 타이핑(Structural Typing)을 기반으로 유연성을 제공하지만, 이로 인해 의미적으로는 다르나 구조가 같은 데이터를 구별하지 못하는 한계(Primitive Obsession 등)가 발생할 수 있다 [19, 20]. 이를 극복하기 위해 브랜디드 타입(Branded Types)을 도입하여 컴파일 타임에 고유한 브랜드 속성을 부여하고 원시 타입 간의 혼용을 막아 안전성을 높인다 [20-22]. 더 나아가 `satisfies` 연산자를 사용해 허용되지 않은 과잉 속성을 잡아내면서도 구체적인 리터럴 타입을 잃지 않게 하여, 유연함과 엄격한 타입 계약을 동시에 강제할 수 있다 [23-25].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[구조적 타이핑 (Structural Typing)]], [[식별 가능한 유니온 (Discriminated Unions)]], [[과잉 속성 검사 (Excess Property Checking)]], [[브랜디드 타입 (Branded Types)]], [[불변성 (Immutability)]]
-- **Projects/Contexts:** [[TypeScript의 컴파일 타임 에러 검증]], [[API 응답 및 데이터 변환 처리]], [[React 컴포넌트 상태 관리]]
-- **Contradictions/Notes:** 소스에 따르면, 구조적 타이핑은 속성 구조가 일치하면 호환을 허용하는 유연성을 제공하지만, 의도치 않은 추가 속성을 허용할 수 있는 맹점이 존재한다 [19, 26, 27]. 이를 보완하기 위해 TypeScript는 객체 리터럴이 직접 할당될 때 '과잉 속성 검사(Excess Property Checking)'를 수행하지만, 중간 변수를 거칠 경우 이 검사가 무력화되는 한계가 있으며, 이 경우 `satisfies` 연산자가 효과적인 대안이 된다 [4, 24, 28, 29].
-
----
-*Last updated: 2026-04-18*
-- Raw Source: [[00_Raw/2026-04-20/타입 안전성 (Type Safety).md]]
----
diff --git a/Programming & Language/타입 정의가 부족한 서드파티 라이브러리 연동.md b/Programming & Language/타입 정의가 부족한 서드파티 라이브러리 연동.md
deleted file mode 100644
index 994057b0..00000000
--- a/Programming & Language/타입 정의가 부족한 서드파티 라이브러리 연동.md	
+++ /dev/null
@@ -1,40 +0,0 @@
----
-id: P-REINFORCE-AUTO-471F26
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - 타입 정의가 부족한 서드파티 라이브러리 연동"
----
-
-# [[타입 정의가 부족한 서드파티 라이브러리 연동]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 타입 정의가 부족한 서드파티 라이브러리 연동은 정적 타입 시스템(예: 타입스크립트, 파이썬 등)을 사용하는 프로젝트에서 타입 정보가 없거나 부정확한 외부 패키지를 통합하는 과정을 의미합니다 [1, 2]. 신중하게 작성된 코드일지라도 타입이 불완전한 외부 라이브러리를 거치면 타입 정보가 손실되거나 훼손될 위험이 있습니다 [1]. 이를 해결하기 위해 개발자는 선언 파일(`.d.ts`)을 추가하거나, 모듈 선언, 타입 단언(`as`), `any` 타입 등을 활용하여 에러를 억제하고 타입 안정성을 보완해야 합니다 [2-4].
-
-## 📖 구조화된 지식 (Synthesized Content)
-* **외부 라이브러리 연동 시의 한계와 문제점**
-  타입 시스템이 적용된 프로젝트에서 타입이 없거나 잘못 지정된 외부 라이브러리를 사용하면, 정교하게 작성된 코드의 타입 정보가 소실되거나 잘못된 결과물로 반환되는 문제가 발생할 수 있습니다 [1]. 또한, 외부 라이브러리 생태계에서 적절한 타입 스텁(Type stubs)을 찾는 것 자체가 큰 고충이 되기도 합니다 [5].
-
-* **선언 파일(`.d.ts`) 및 DefinitelyTyped 생태계 활용**
-  타입스크립트 환경에서 자바스크립트 기반 라이브러리를 사용하려면, 실제 구현부 없이 타입 정보만을 제공하는 선언 파일(`.d.ts`)이 필수적입니다 [2]. 대다수의 인기 라이브러리는 자체 타입을 제공하지만, 그렇지 않은 경우 'DefinitelyTyped'를 통해 제공되는 커뮤니티 주도 타입(예: `@types/패키지명`)을 설치하여 해결할 수 있습니다 [2].
-
-* **모듈 직접 선언(Module Declaration)**
-  사용하려는 서드파티 모듈에 대한 타입 정의 파일이 어느 곳에도 존재하지 않는다면, 개발자는 컴파일러의 에러를 억제하기 위해 `declare module 'some-untyped-module';`과 같은 방식으로 모듈을 직접 선언하여 사용할 수 있습니다 [2].
-
-* **타입 단언(`as`) 및 `any` 타입의 전략적 사용**
-  타입 지원이 형편없는(poorly-typed) 서드파티 라이브러리와 연동해야 할 때, 개발자가 런타임 상황을 인지하고 있으며 마땅한 대안이 없는 경우 최후의 수단으로 타입 단언(`as`)을 사용할 수 있습니다 [3, 6]. 더불어, 엄격한 컴파일 타임 검사를 의도적으로 우회하게 해주는 `any` 타입을 활용하는 것도 외부 라이브러리나 알 수 없는 소스와 데이터를 주고받을 때 유용한 우회책이 될 수 있습니다 [4].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[선언 파일(.d.ts)]], [[타입 단언(Type Assertions)]], [[any 타입]]
-- **Projects/Contexts:** [[타입스크립트 프로젝트의 외부 자바스크립트 라이브러리 마이그레이션 및 연동]]
-- **Contradictions/Notes:** 소스에 관련 정보가 부족합니다. (타입 정의가 부족한 서드파티 라이브러리 연동에 관하여 소스들 간의 명시적인 상충 의견은 제공된 자료에 포함되어 있지 않습니다.)
-
----
-*Last updated: 2026-04-18*
-- Raw Source: [[00_Raw/2026-04-20/타입 정의가 부족한 서드파티 라이브러리 연동.md]]
----
diff --git a/Programming & Language/타입 조건자(Type Predicates).md b/Programming & Language/타입 조건자(Type Predicates).md
deleted file mode 100644
index 5b31f344..00000000
--- a/Programming & Language/타입 조건자(Type Predicates).md	
+++ /dev/null
@@ -1,33 +0,0 @@
----
-id: P-REINFORCE-AUTO-F5B64F
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - 타입 조건자(Type Predicates)"
----
-
-# [[타입 조건자(Type Predicates)]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 타입 조건자(Type Predicates)는 특정 매개변수가 지정된 타입인지 여부를 나타내는 함수입니다 [1]. 런타임 시점에는 불리언(boolean) 값을 반환하지만, TypeScript의 타입 시스템은 이 반환 값을 인식하여 자동으로 타입 좁히기(Type Narrowing)를 적용합니다 [1]. 일반적으로 커스텀 타입 가드 함수 내에서 `is` 키워드를 사용하여 정의됩니다 [2].
-
-## 📖 구조화된 지식 (Synthesized Content)
-- **작동 원리 및 문법:** 타입 조건자는 `is` 키워드를 사용하는 커스텀 타입 가드 함수를 통해 정의할 수 있습니다 [2]. 함수가 불리언 값을 반환할 때, 조건문 내부에서 TypeScript 컴파일러가 해당 변수의 타입을 더 구체적인 타입으로 좁히게(narrowing) 만듭니다 [1, 2].
-- **주요 활용 (브랜디드 타입 검증):** 구조적으로 동일해 보이는 타입들을 의도에 따라 구분해야 할 때(예: 브랜디드 타입 인스턴스 검증) 타입 조건자를 활용하면 유용합니다 [1]. 예를 들어, `isPositive(value)`라는 타입 조건자 함수를 사용하여 값이 양수인지 확인하면, `if (isPositive(value))` 블록 내부에서 TypeScript는 해당 값을 `Positive` 타입으로 안전하게 취급합니다 [1]. 
-- **한계 및 타입 안전성(Type Safety) 주의:** 타입 조건자는 무조건적으로 타입 안정성을 보장하지 않으며, 내부적으로는 `as` 타입 단언(Type Assertion)과 크게 다르지 않은 수준의 안정성을 가집니다 [1]. TypeScript는 타입 조건자 함수 내부의 논리가 실제 타입의 의도와 정확히 일치하는지 검증하지 않으며, 전적으로 코드를 작성한 개발자의 논리에 의존합니다 [1].
-- **사용상의 단점:** 타입 조건자 함수를 사용하려면 `if`문과 같은 조건부 래퍼(Conditional Wrappers)를 작성해야 하므로, `as` 단언문에 비해 코드가 차지하는 공간이 늘어나고 런타임 로직이 추가되는 단점이 있습니다 [3]. 다만, 이를 개선하기 위해 타입 단언 함수(Type Assertion Function)와 함께 사용하여 유효성을 검증하고 에러를 발생시키는 패턴으로 발전시킬 수 있습니다 [3].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[타입 좁히기(Type Narrowing)]], [[브랜디드 타입(Branded Types)]], [[타입 단언(Type Assertions)]], [[타입 가드(Type Guards)]]
-- **Projects/Contexts:** [[TypeScript의 안전한 타입 검증 및 커스텀 타입 가드 설계]]
-- **Contradictions/Notes:** 타입 조건자는 타입을 안전하게 좁히기 위한 유용한 도구로 사용되지만, 실제로는 TypeScript 컴파일러가 내부 로직의 정확성을 검증해주지 않으므로 `as` 단언문(Type Assertion)보다 본질적으로 더 타입-안전(type-safe)하다고 볼 수는 없습니다 [1].
-
----
-*Last updated: 2026-04-18*
-- Raw Source: [[00_Raw/2026-04-20/타입 조건자(Type Predicates).md]]
----
diff --git a/Programming & Language/타입 좁히기 (Type Narrowing).md b/Programming & Language/타입 좁히기 (Type Narrowing).md
deleted file mode 100644
index c8a6daeb..00000000
--- a/Programming & Language/타입 좁히기 (Type Narrowing).md	
+++ /dev/null
@@ -1,42 +0,0 @@
----
-id: P-REINFORCE-AUTO-4245C8
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - 타입 좁히기 (Type Narrowing)"
----
-
-# [[타입 좁히기 (Type Narrowing)]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 타입 좁히기(Type Narrowing)는 TypeScript에서 유니온 타입과 같이 여러 타입의 가능성을 내포하는 변수를 다룰 때, 코드 흐름 분석(Code Flow Analysis)을 통해 더 구체적이고 한정된 타입으로 줄여나가는 과정입니다 [1, 2]. 이를 통해 컴파일러는 특정 코드 블록 내에서 값의 형태를 확신할 수 있게 되며, 개발자는 특정 타입에만 존재하는 속성에 안전하게 접근할 수 있습니다 [2-4]. 주로 `typeof`, `instanceof`, `in` 연산자 또는 사용자 정의 타입 가드 및 판별자(Discriminant)를 활용하여 수행됩니다 [5, 6].
-
-## 📖 구조화된 지식 (Synthesized Content)
-**타입 좁히기의 목적 및 작동 원리**
-TypeScript의 타입 검사는 값의 런타임 형태(구조)에 기반하며, 코드 제어 흐름 분석을 통해 타입을 추론합니다 [2, 7]. 값이 여러 타입 중 하나일 수 있을 때(예: `string | number`), 해당 타입에 고유한 메서드나 속성을 사용하기 위해서는 사전에 타입 좁히기를 수행해야 합니다 [2, 8]. 
-
-**타입을 좁히는 주요 기법**
-* **내장 타입 가드 (Built-in Type Guards):** 
-  `typeof`, `instanceof`, 동등성 검사(equality checks), `in` 연산자 등을 사용하여 제어문에서 조건을 검사하면, TypeScript는 내부적으로 이를 인식하고 블록 내부의 변수 타입을 자동으로 좁혀줍니다 [2, 5, 6]. 예를 들어 `typeof x === 'string'` 조건문 블록 내부에서 `x`는 `string` 타입으로 취급됩니다 [2].
-* **사용자 정의 타입 서술어 (Type Predicates / Custom Type Guards):**
-  특정 타입인지 검사하는 로직이 복잡할 경우, 반환 타입에 `is` 키워드를 사용하는 함수를 정의할 수 있습니다 [6, 9]. 함수가 `true` 혹은 `false`를 반환하는 결과에 따라 TypeScript의 타입 시스템이 매개변수의 타입을 좁히게 됩니다 [6, 9].
-* **식별 가능한 유니온 (Discriminated Unions / Tagged Unions):**
-  유니온을 구성하는 각 객체 타입이 공유하는 공통 리터럴 속성(판별자)을 두는 기법입니다 [3, 10, 11]. `switch`문이나 `if`문으로 이 판별자를 검사하여 타입을 좁히면, 타입 시스템은 해당 블록 안에서 객체의 타입을 안전하게 한 가지로 확정해줍니다 [12-14]. 이는 런타임 타입 검사의 부담을 줄이고 에러 처리와 상태 관리에 매우 효과적입니다 [14].
-
-**보조 연산자의 활용**
-TypeScript의 `satisfies` 연산자를 식별 가능한 유니온과 함께 사용하면, 객체가 특정 타입 구조를 만족하는지 검사하면서도 판별자의 리터럴 타입(Literal Type)을 보존해 주어 올바른 타입 좁히기가 원활하게 이루어지도록 돕습니다 [15].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[유니온 타입 (Union Types)]], [[식별 가능한 유니온 (Discriminated Unions)]], [[타입 가드 (Type Guards)]], [[타입 서술어 (Type Predicates)]]
-- **Projects/Contexts:** [[제어 흐름 분석 (Control Flow Analysis)]], [[API 응답 및 상태 모델링 (State Modeling and API Responses)]]
-- **Contradictions/Notes:** 타입 서술어(Type Predicates)를 사용하여 타입을 좁힐 때, TypeScript 컴파일러는 함수 내부의 로직이 개발자가 의도한 브랜드 타입이나 좁히기 조건과 실제로 일치하는지까지는 검사하지 않고 전적으로 코드 작성자의 논리에 의존하므로 주의가 필요합니다 [9].
-
----
-*Last updated: 2026-04-18*
-- Raw Source: [[00_Raw/2026-04-20/타입 좁히기 (Type Narrowing).md]]
----
diff --git a/Programming & Language/타입 좁히기(Type Narrowing).md b/Programming & Language/타입 좁히기(Type Narrowing).md
deleted file mode 100644
index f3defd7a..00000000
--- a/Programming & Language/타입 좁히기(Type Narrowing).md	
+++ /dev/null
@@ -1,37 +0,0 @@
----
-id: P-REINFORCE-AUTO-C17DEE
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - 타입 좁히기(Type Narrowing)"
----
-
-# [[타입 좁히기(Type Narrowing)]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 타입 좁히기(Type Narrowing)는 TypeScript에서 변수가 가질 수 있는 여러 넓은 타입(예: 유니온 타입)을 특정 코드 블록 내에서 더 구체적인 타입으로 범위를 좁혀나가는 과정입니다 [1, 2]. 조건문과 같은 런타임 동작을 기반으로 제어 흐름 분석(Control flow analysis)을 수행하여 컴파일러가 타입을 안전하게 추론하게 만듭니다 [2]. 이를 통해 개발자는 런타임 에러를 방지하고, IDE의 자동 완성과 타입 안전성을 극대화할 수 있습니다 [3].
-
-## 📖 구조화된 지식 (Synthesized Content)
-- **제어 흐름 분석(Control Flow Analysis):** TypeScript는 런타임 타입 검사 코드를 이해하여 제어 흐름에 따라 변수의 타입을 좁힙니다. 예를 들어, `if (typeof x === 'string')` 조건문이 있는 블록 내부에서는 `x`가 자동으로 `string` 타입으로 취급됩니다 [2].
-- **기본 타입 가드(Type Guards):** 
-  - `typeof` 연산자: `number`, `string`, `boolean`, `symbol`과 같은 원시 타입의 범위를 좁힐 때 사용합니다 [2, 4].
-  - `instanceof` 연산자: 우측에 생성자 함수를 두어 해당 객체의 프로토타입 타입을 좁힙니다 [2, 4].
-  - 기타 방식: 동등성 검사(equality checks)나 `in` 연산자를 사용하여 객체가 특정 속성을 가지고 있는지 확인함으로써 타입을 좁힐 수도 있습니다 [2, 5].
-- **식별 가능한 유니온(Discriminated Unions) 기반 좁히기:** 유니온 타입의 각 멤버들이 공유하는 특정 리터럴 속성(판별자, Discriminator)을 기준으로 타입을 좁히는 강력한 패턴입니다 [6, 7]. `switch`문 등을 사용하여 판별자 속성의 값을 검사하면, TypeScript는 유니온을 구성하는 여러 타입 중 해당하는 특정 타입만 남기고 나머지를 배제합니다 [3, 8, 9].
-- **사용자 정의 타입 가드(Type Predicates):** 매개변수가 특정 타입인지 확인하는 로직을 별도의 함수로 분리할 때 사용합니다 [10]. 런타임에는 불리언(boolean) 값을 반환하지만, 반환 타입에 명시적인 타입 조건(예: `value is Positive`)을 작성해두면 타입 시스템이 이를 인지하고 타입 좁히기를 적용합니다 [10].
-- **타입 좁히기의 중요성 및 `satisfies` 연산자:** 유니온 타입의 값에서 특정 타입만의 고유 속성에 접근하려면 반드시 좁히기 과정을 먼저 거쳐야 안전합니다 [1]. 추가적으로, `satisfies` 연산자를 활용하면 유니온 타입 객체를 할당할 때 판별자의 리터럴 타입을 일반화(widening)시키지 않고 보존할 수 있어 안전한 타입 좁히기를 유지할 수 있습니다 [11].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[식별 가능한 유니온(Discriminated Unions)]], [[타입 가드(Type Guards)]], [[유니온 타입(Union Types)]]
-- **Projects/Contexts:** [[상태 관리 및 API 응답 모델링(State Management and API Response Modeling)]]
-- **Contradictions/Notes:** 소스 상에서 타입 좁히기 자체에 대한 모순된 주장은 존재하지 않습니다. 다만, 타입 좁히기를 통한 검증 과정을 생략하고 타입 단언(`as`)을 사용하여 강제로 타입을 캐스팅하는 방식은 런타임 타입 안전성을 보장하지 못하며 초과 속성 검사(Excess Property Checking)를 무력화할 수 있어 지양해야 한다는 점이 강조됩니다 [2, 12, 13].
-
----
-*Last updated: 2026-04-18*
-- Raw Source: [[00_Raw/2026-04-20/타입 좁히기(Type Narrowing).md]]
----
diff --git a/Programming & Language/타입 캐스팅 (Type Casting).md b/Programming & Language/타입 캐스팅 (Type Casting).md
deleted file mode 100644
index 9fe6ff0c..00000000
--- a/Programming & Language/타입 캐스팅 (Type Casting).md	
+++ /dev/null
@@ -1,40 +0,0 @@
----
-id: P-REINFORCE-AUTO-A91EB7
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - 타입 캐스팅 (Type Casting)"
----
-
-# [[타입 캐스팅 (Type Casting)]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 타입 캐스팅(Type Casting) 또는 타입 단언(Type Assertion)은 개발자가 TypeScript 컴파일러에게 특정 값의 타입 정보를 강제로 지정하여 "내가 이 타입을 더 잘 알고 있다"고 알려주는 기능입니다 [1, 2]. 다른 프로그래밍 언어의 타입 캐스팅과 유사해 보이지만, 런타임에 데이터 구조를 바꾸거나 특별한 검사를 수행하지 않으며 순전히 컴파일 타임에만 작용합니다 [2]. 그러나 잘못 사용하면 컴파일러의 안전장치를 우회하게 되어 런타임 에러를 유발할 수 있으므로 극히 주의해서 사용해야 합니다 [1, 3].
-
-## 📖 구조화된 지식 (Synthesized Content)
-* **개념 및 동작 원리:** 
-  타입 캐스팅은 주로 `as` 키워드를 사용하여 TypeScript가 스스로 추론할 수 없는 타입 정보를 개발자가 직접 주입하는 방식입니다 [4]. 이는 컴파일러에게 특정 값의 타입을 지정된 타입으로 취급하도록 지시하는 역할을 하지만, 실제 런타임 환경에서는 아무런 영향을 미치지 않으며 데이터의 재구성도 일어나지 않습니다 [2]. (JSX/TSX 환경에서는 오직 `as` 구문을 활용한 캐스팅만 지원됩니다 [2].)
-
-* **위험성과 초과 속성 검사 회피:** 
-  `as` 단언문을 사용한 타입 캐스팅은 컴파일러가 제공하는 검증을 건너뛰게 만들 수 있다는 치명적인 위험을 내포하고 있습니다 [1, 3]. 만약 개발자의 캐스팅이 실제 데이터와 다르더라도 TypeScript는 이를 유효성 검사 없이 수용하므로, 런타임 시에 애플리케이션 충돌이나 조용한 버그를 유발할 수 있습니다 [1, 3]. 특히, 객체 할당 시 잉여 속성을 잡아내는 '초과 속성 검사(excess property checking)'를 무력화하기 때문에, 의도치 않은 추가 속성이 섞여 있어도 경고 없이 통과시키는 부작용이 있습니다 [5].
-
-* **이중 캐스팅 (Double Casting):** 
-  TypeScript는 캐스팅 대상이 목표 타입과 근본적으로 호환되지 않을 때(예: 필수 속성이 누락된 경우)에만 타입 캐스팅을 거부합니다 [6]. 이렇게 완전히 호환되지 않는 상황에서조차 강제로 타입을 지정해야 한다면, 먼저 `unknown` 타입으로 캐스팅한 뒤 원하는 타입으로 다시 캐스팅하는 방식(이중 캐스팅)을 사용할 수 있습니다 [6]. 단, 이 방법은 안전성을 크게 훼손하므로 일반적으로 권장되지 않습니다 [6].
-
-* **올바른 활용 맥락 및 대안:**
-  타입 캐스팅은 런타임 검증을 확실히 마친 외부 데이터 처리, DOM 조작, 타입이 모호한 서드파티 라이브러리와 통신할 때처럼 뾰족한 대안이 없는 상황에서 최후의 수단으로 사용해야 합니다 [1, 7]. 또는 Branded Type(Opaque Type)을 설계할 때 컴파일러가 일반 원시 타입과 브랜디드 타입을 구분하도록 명시적으로 값을 캐스팅하는 데 유용하게 쓰일 수 있습니다 [4, 8]. 타입 안전성을 유지하기 위해서는 단순 캐스팅보다 `satisfies` 연산자, 타입 가드(Type Predicates), 혹은 런타임 유효성 검증 도구를 병행하는 것이 모범 사례로 권장됩니다 [3, 6, 9].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[타입 단언 (Type Assertions)]], [[satisfies 연산자 (Satisfies Operator)]], [[브랜디드 타입 (Branded Types)]], [[타입 가드 (Type Guards)]]
-- **Projects/Contexts:** TypeScript가 타입을 정밀하게 추론하지 못하는 DOM 요소 조작이나 런타임 검증이 완료된 외부 API 응답 처리 맥락 [1, 7], 구조적 타이핑 우회 및 Opaque Type 강제 할당 시스템 설계 시 [4, 5, 8]
-- **Contradictions/Notes:** 타입 캐스팅(`as`)은 강력한 강제성을 지니지만 데이터 유효성을 담보하지는 않습니다. 따라서 잉여 속성을 체크하거나 타입 안정성을 잃지 않으려면 캐스팅을 남용하지 말고 `satisfies` 키워드를 활용해 구조와 값을 동시에 엄격하게 검증하는 편이 낫다는 것이 소스의 주요한 조언입니다 [1, 5, 9].
-
----
-*Last updated: 2026-04-18*
-- Raw Source: [[00_Raw/2026-04-20/타입 캐스팅 (Type Casting).md]]
----
diff --git a/Programming & Language/타입스크립트 상태 관리 및 분기 처리 설계.md b/Programming & Language/타입스크립트 상태 관리 및 분기 처리 설계.md
deleted file mode 100644
index 16f9d31f..00000000
--- a/Programming & Language/타입스크립트 상태 관리 및 분기 처리 설계.md	
+++ /dev/null
@@ -1,43 +0,0 @@
----
-id: P-REINFORCE-AUTO-8F7FE7
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - 타입스크립트 상태 관리 및 분기 처리 설계"
----
-
-# [[타입스크립트 상태 관리 및 분기 처리 설계]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 타입스크립트의 상태 관리 및 분기 처리 설계는 강력한 타입 시스템을 활용하여 유효하지 않은 상태를 원천적으로 차단하고 조건 분기의 안전성을 보장하는 아키텍처 기법입니다. 핵심적으로 '식별 가능한 유니온(Discriminated Unions)' 패턴을 통해 다양한 상태를 구조화하고, `switch`나 `if` 문에서 공통 속성을 판별자로 사용하여 타입을 안전하게 좁힙니다. 여기에 `never` 타입을 활용한 완전성 검사(Exhaustiveness Checking)와 `readonly`를 통한 상태의 불변성을 결합하여, 런타임 에러를 컴파일 타임에 방지하는 견고한 애플리케이션 논리를 구축합니다.
-
-## 📖 구조화된 지식 (Synthesized Content)
-*   **식별 가능한 유니온(Discriminated Unions)을 활용한 상태 모델링**
-    식별 가능한 유니온(또는 태그된 유니온)은 타입스크립트 상태 관리의 핵심 패턴으로, `kind`, `type`, `status`와 같은 공통 리터럴 속성을 사용하여 다양한 형태의 데이터를 구별합니다 [1-4]. 애플리케이션의 상태(예: 로딩, 성공, 실패)를 이 패턴으로 모델링하면, 존재할 수 없는 상태의 조합을 타입 시스템 수준에서 불가능하게 만들 수 있습니다 [5, 6]. 이는 Redux 스타일의 리듀서, 비동기 작업 처리, 라우터 상태, 그리고 폼 핸들링 등에서 명확하고 안전한 상태 전이를 구현하는 데 매우 효과적입니다 [5, 7].
-
-*   **타입 좁히기(Type Narrowing)와 안전한 분기 처리**
-    런타임 환경에서 제어문(`switch` 또는 `if`)을 통해 상태 객체의 판별자 속성값을 검사하면, 컴파일러는 해당 블록 내에서 객체의 타입을 구체적인 분기로 안전하게 좁혀줍니다 [4, 5, 8]. 이 과정은 타입스크립트가 각 분기 내에서 접근할 수 있는 고유 속성들을 정확히 인지하게 만들어 자동 완성과 타입 안전성을 극대화하며, 별도의 타입 단언(`as`) 없이도 코드를 직관적으로 유지할 수 있게 돕습니다 [2, 4, 6].
-
-*   **완전성 검사(Exhaustiveness Checking)를 통한 누락 방지**
-    상태 분기 처리 시 발생할 수 있는 가장 큰 위험 중 하나는 특정 케이스를 누락하는 것입니다. 이를 방지하기 위해 `never` 타입을 활용한 완전성 검사 기법이 사용됩니다 [4, 9, 10]. 모든 분기를 처리한 후 남은 기본(default) 케이스에 도달하는 값을 `never` 타입 변수에 할당하도록 구성하면, 나중에 새로운 상태가 유니온 타입에 추가되었을 때 해당 상태를 처리하지 않은 모든 코드 라인에서 컴파일 에러가 발생합니다 [4, 5, 8, 10]. 이는 확장에 따른 분기 누락 버그를 원천 차단합니다 [4, 11].
-
-*   **Readonly를 통한 불변성(Immutability) 확립**
-    상태 관리의 예측 가능성을 높이기 위해서는 상태 데이터의 무분별한 변경을 막는 불변성이 중요합니다. 타입스크립트는 `readonly` 수식어와 `ReadonlyArray` 등을 통해 객체나 배열의 속성이 초기화된 후 수정되는 것을 컴파일 수준에서 금지합니다 [12-14]. `Object.freeze()`와 달리 런타임 오버헤드가 없으며, 트리 구조나 복잡한 중첩 상태 데이터를 다룰 때는 재귀적 불변성(`DeepReadonly`)을 적용하여 깊은 계층까지 상태 오염을 철저히 방어할 수 있습니다 [14-16].
-
-*   **복잡한 분기 처리 설계의 대안과 성능 최적화**
-    복잡한 분기를 선언적으로 처리하기 위해 `ts-pattern`과 같은 패턴 매칭 라이브러리를 사용할 수 있습니다 [17, 18]. 하지만 벤치마크에 따르면 `ts-pattern`의 메서드들은 자바스크립트의 기본 제어 구조(`if/else`, `switch`)에 비해 연산 속도가 현저히 느릴 수 있습니다 [19]. 따라서 성능이 중요하거나 상대적으로 간단한 분기에서는 Early Return, 즉시 실행 함수(IIFE), 또는 기본 `switch` 문과 `satisfies` 키워드를 결합해 선언적이면서도 안전하게 분기 처리를 구현하는 것이 더 권장되기도 합니다 [20-22].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[식별 가능한 유니온(Discriminated Unions)]], [[타입 좁히기(Type Narrowing)]], [[완전성 검사(Exhaustiveness Checking)]], [[불변성과 Readonly]], [[구조적 타이핑(Structural Typing)]]
-- **Projects/Contexts:** [[React 상태 관리 및 리듀서 패턴 구현]], [[ts-pattern 라이브러리를 활용한 패턴 매칭]]
-- **Contradictions/Notes:** 분기 처리를 간결하게 만들기 위해 고안된 `ts-pattern` 라이브러리는 유용하지만, 내부적으로 복잡한 타입 추론과 객체 생성을 수반하므로 기본 `if/else` 구문에 비해 성능이 99%가량 느리다는 벤치마크 결과가 있습니다 [19, 23]. 따라서 무조건적인 라이브러리 의존보다는 기존 분기문과 IIFE를 적절히 활용하는 유연한 접근이 필요하다는 주장이 존재합니다 [20, 22]. 
-
----
-*Last updated: 2026-04-18*
-- Raw Source: [[00_Raw/2026-04-20/타입스크립트 상태 관리 및 분기 처리 설계.md]]
----
diff --git a/Programming & Language/타파스(Tapas).md b/Programming & Language/타파스(Tapas).md
deleted file mode 100644
index cef6430f..00000000
--- a/Programming & Language/타파스(Tapas).md	
+++ /dev/null
@@ -1,32 +0,0 @@
----
-id: P-REINFORCE-AUTO-610FD5
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - 타파스(Tapas)"
----
-
-# [[타파스(Tapas)]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 타파스(Tapas)는 넷플릭스(Netflix)의 코스모스(Cosmos) 플랫폼 내에서 작동하는 가장 크고 복잡한 상위 계층의 서비스입니다 [1]. 이 서비스의 주된 목적은 제작 스튜디오로부터 원본 미디어를 수신하여 넷플릭스 서비스에서 재생할 수 있는 최종 형태로 처리하는 것입니다 [1]. 짧은 대기 시간보다는 하루 단위의 대규모 작업 완료와 비용 효율성에 중점을 두는 처리량 민감형(throughput-sensitive) 애플리케이션입니다 [2].
-
-## 📖 구조화된 지식 (Synthesized Content)
-- **주요 역할 및 워크플로우:** 스튜디오에서 새로운 타이틀이 도착하면 타파스 워크플로우가 자동으로 시작됩니다 [3]. 이 워크플로우는 소스 검사, 다양한 해상도 및 코덱을 적용한 비디오/오디오 인코딩, 다국어 자막 생성, 그리고 최종 결과물 패키징과 같은 일련의 작업을 수행합니다 [3].
-- **대규모 오케스트레이션:** 타파스에 대한 단일 요청은 하위 코스모스 서비스들에 대한 수백 개의 요청과 수천 개의 스트라툼(Stratum) 서버리스 함수 호출로 이어지며, 타파스는 이러한 복잡한 프로세스들을 조율(Orchestrate)합니다 [3].
-- **처리량 민감형(Throughput-sensitive) 특성:** 타파스는 하루에 수백만 CPU 시간을 소비할 정도로 막대한 컴퓨팅 리소스를 사용합니다 [2]. 개별 작업의 완료 시간(초당 작업 수)보다는 몇 시간 혹은 며칠에 걸쳐 대규모 작업을 완료하는 것에 집중합니다 [2]. 따라서 타파스의 서비스 수준 목표(SLO)는 '하루당 작업 수(tasks per day)'와 '작업당 비용(cost per task)'으로 측정됩니다 [2].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[넷플릭스 코스모스 플랫폼(Netflix Cosmos Platform)]], [[스트라툼(Stratum)]]
-- **Projects/Contexts:** [[넷플릭스의 미디어 처리 및 인코딩 파이프라인]]
-- **Contradictions/Notes:** 소스에 타파스와 상반되는 주장이나 모순되는 정보는 포함되어 있지 않습니다.
-
----
-*Last updated: 2026-04-18*
-- Raw Source: [[00_Raw/2026-04-20/타파스(Tapas).md]]
----
diff --git a/Programming & Language/토스(Toss) Front SDK 퍼사드 패턴 적용.md b/Programming & Language/토스(Toss) Front SDK 퍼사드 패턴 적용.md
deleted file mode 100644
index e34d819d..00000000
--- a/Programming & Language/토스(Toss) Front SDK 퍼사드 패턴 적용.md	
+++ /dev/null
@@ -1,40 +0,0 @@
----
-id: P-REINFORCE-AUTO-1CFB9E
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - 토스(Toss) Front SDK 퍼사드 패턴 적용"
----
-
-# [[토스(Toss) Front SDK 퍼사드 패턴 적용]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 토스플레이스는 자체 개발한 결제 단말기인 Toss Front의 외부 연동 SDK를 개발하며, 사용성을 높이기 위해 퍼사드(Facade) 패턴을 적용했습니다 [1, 2]. 이 패턴은 단순히 복잡한 내부 로직을 숨기는 데 그치지 않고, 복잡한 내부 구현을 '사용자의 의도(Intent)'를 기준으로 재구성하는 데 본질적인 목적이 있습니다 [3]. 이를 통해 연동사 측의 휴먼 에러를 구조적으로 방지함과 동시에 SDK의 장기적인 호환성과 개발자 경험(DX)을 크게 향상시킬 수 있습니다 [4-6].
-
-## 📖 구조화된 지식 (Synthesized Content)
-* **SDK 설계에서 퍼사드 패턴의 재정의**
-  일반적인 퍼사드 패턴은 복잡한 서브시스템을 단순한 인터페이스로 감싸는 구조이지만, 토스의 관점에서 SDK 퍼사드 패턴의 본질은 "사용자의 의도(Intent) 기준으로 내부 구현을 다시 구성하는 것"입니다 [3]. 인증, 실패 시 재시도, 상태 관리, 클린업(Cleanup) 등과 같이 복잡한 암묵적 의존성들을 SDK 내부로 은닉하고, 사용자는 "서버를 시작한다", "파일을 업로드한다"와 같이 자연스러운 목적만 코드로 표현하도록 만듭니다 [2, 3]. 이를 통해 개발자의 인지 부하를 줄이고 시스템 간의 결합도를 낮출 수 있습니다 [5, 7].
-
-* **고수준(High-level)과 저수준(Low-level) 인터페이스의 공존**
-  효과적인 SDK 설계를 위해서는 고수준 인터페이스(Facade)와 저수준 인터페이스가 함께 존재해야 합니다 [5]. 파레토 법칙에 따라 80%의 흔한 유즈케이스는 고수준의 퍼사드 계층을 통해 워크플로우를 한 번에 끝낼 수 있도록 제공합니다 [5, 8]. 반면, 세밀한 제어가 필요한 나머지 20%의 특수 케이스를 위해 원자적 호출이 가능한 저수준 API를 탈출구(Escape Hatch)로 제공하여 SDK의 확장성과 호환성을 유지합니다 [5, 8, 9]. 
-
-* **단일 책임 원칙(SRP)과 구조적 안정성 확보**
-  퍼사드 패턴 적용 시 리소스 관리의 책임을 SDK가 가져가며 "리소스를 만든 곳에서 닫는다"는 단일 책임 원칙(SRP)을 따릅니다 [6]. 인터페이스 내에 클린업 책임을 명확히 구현함으로써 사용자가 핸들러 부착 해제를 누락하여 발생하는 메모리 누수(Memory Leak)나 이벤트 누수 등의 장애 상황과 비효율적 리소스 관리를 원천적으로 차단합니다 [4, 6].
-
-* **추상화의 트레이드오프 관리**
-  추상화 수준이 높아지면 특수한 상황에서의 세밀한 제어가 제한되고, SDK 내부의 오케스트레이션 로직 관리 복잡도가 증가하여 유지 보수 비용이 높아지는 트레이드오프가 발생합니다 [8]. 이를 극복하기 위해 편의성에만 안주하지 않고 저수준 API를 적절히 열어두어 설계의 균형을 맞춥니다 [9].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[단일 책임 원칙(SRP)]], [[추상화(Abstraction)]], [[개발자 경험(DX)]]
-- **Projects/Contexts:** [[토스플레이스 결제 단말기 외부 연동 SDK 개발]]
-- **Contradictions/Notes:** 퍼사드 패턴을 통한 높은 추상화는 사용자에게 큰 편의성을 제공하지만, 필연적으로 세밀한 제어를 불가능하게 만들고 SDK 내부 구현의 복잡성을 가중시키는 단점이 존재하므로, 탈출구(Escape Hatch) 역할을 할 수 있는 저수준(Low-level) 인터페이스의 병행 제공이 필수적입니다 [8, 9].
-
----
-*Last updated: 2026-04-18*
-- Raw Source: [[00_Raw/2026-04-20/토스(Toss) Front SDK 퍼사드 패턴 적용.md]]
----
diff --git a/Programming & Language/토스(Toss) SDK 설계.md b/Programming & Language/토스(Toss) SDK 설계.md
deleted file mode 100644
index 96c8fed1..00000000
--- a/Programming & Language/토스(Toss) SDK 설계.md	
+++ /dev/null
@@ -1,36 +0,0 @@
----
-id: P-REINFORCE-AUTO-D59267
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - 토스(Toss) SDK 설계"
----
-
-# [[토스(Toss) SDK 설계]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 토스플레이스의 자체 결제 단말기인 Toss Front를 위한 외부 연동 SDK 설계 방식입니다 [1]. 이 SDK는 퍼사드(Facade) 패턴을 활용하여 복잡한 내부 로직을 사용자의 의도(Intent) 중심으로 추상화하여 사용 편의성과 안정성을 극대화했습니다 [2]. 결과적으로 개발자 경험(DX)을 향상시키면서도 휴먼 에러를 구조적으로 방지하고, 고수준과 저수준 인터페이스를 함께 제공하여 유연성까지 확보한 것이 특징입니다 [3, 4].
-
-## 📖 구조화된 지식 (Synthesized Content)
-* **설계 목적 및 문제 해결:** 외부 연동사가 사용하는 SDK의 첫인상을 결정하는 것은 사용의 '간편성'입니다 [5]. 초기의 추상적인 인터페이스는 사용자가 콜백 해제 등을 누락할 경우 메모리 누수와 같은 장애로 이어지는 암묵적 의존성 문제를 안고 있었습니다 [5, 6]. 이러한 휴먼 에러를 원천적으로 방지하고 시스템 안정성을 지키기 위해, SDK 사용 코드의 간편성을 높이고 불필요한 과정은 내부로 은닉하는 설계가 도입되었습니다 [6].
-* **퍼사드(Facade) 패턴의 재정의:** 토스의 SDK 설계에서 퍼사드 패턴의 본질은 단순한 기능 은닉이 아니라 "복잡한 내부 구현을 사용자의 의도(Intent) 기준으로 다시 구성하는 것"입니다 [2, 7]. 인증, 재시도, 상태 관리 등 복잡한 오케스트레이션 로직을 감추고, 사용자가 직관적인 목적만 코드로 표현하게 하여 결합도를 낮추고 인지 부하를 줄였습니다 [2].
-* **High-level과 Low-level 인터페이스의 공존:**
-  * **High-level 인터페이스 (Facade):** 전체 사용 사례의 80%를 차지하는 보편적이고 반복적인 유즈케이스를 간단히 끝낼 수 있는 워크플로우를 제공합니다 [3, 8].
-  * **Low-level 인터페이스 (탈출구/Escape Hatch):** 세밀한 제어가 필요한 나머지 20%의 특수한 요구사항을 위해 제공됩니다 [3, 8]. 두 인터페이스의 공존을 통해 편의성에 갇히지 않고 확장성과 세밀한 조작 가능성이라는 설계의 균형을 잡습니다 [8, 9].
-* **자원 관리와 단일 책임 원칙(SRP):** 이벤트 및 리스너 누수를 방지하기 위해 "리소스를 만든 곳에서 닫는다"는 단일 책임 원칙을 적용했습니다 [4]. 연결(Connection)에 따른 동작을 내부적으로 관리하고, 종료 시 자동으로 클린업(Cleanup)을 수행하도록 관리 책임을 SDK 내부로 가져왔습니다 [4, 9].
-* **플랫폼의 장기적 성장 보장:** 의도 기반의 쓰기 쉬운 인터페이스 설계는 단기적인 개발자 경험(DX)을 개선하는 것을 넘어 성능과 안정성을 확보해 줍니다 [4]. 나아가 내부 구현이 변경되더라도 사용자 코드를 보호하여 하위 호환성을 지키고 Breaking Change를 방지하는 역할을 수행합니다 [4, 9].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[퍼사드(Facade) 패턴]], [[단일 책임 원칙(SRP)]], [[개발자 경험(DX)]]
-- **Projects/Contexts:** [[Toss Front]], [[토스플레이스]]
-- **Contradictions/Notes:** 퍼사드 패턴을 통해 추상화 수준이 높아질수록 사용자에게 편의성을 제공하지만, 세밀한 제어가 제한되고 SDK 내부의 유지 비용 및 복잡도가 증가하는 트레이드오프(Trade-off)가 발생합니다. 소스에서는 이를 해결하기 위해 저수준 인터페이스를 '탈출구(Escape Hatch)'로 함께 제공해야 한다고 설명합니다 [8, 9].
-
----
-*Last updated: 2026-04-18*
-- Raw Source: [[00_Raw/2026-04-20/토스(Toss) SDK 설계.md]]
----
diff --git a/Programming & Language/토스플레이스 결제 단말기 외부 연동 SDK 개발.md b/Programming & Language/토스플레이스 결제 단말기 외부 연동 SDK 개발.md
deleted file mode 100644
index b22f1dae..00000000
--- a/Programming & Language/토스플레이스 결제 단말기 외부 연동 SDK 개발.md	
+++ /dev/null
@@ -1,35 +0,0 @@
----
-id: P-REINFORCE-AUTO-53C817
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - 토스플레이스 결제 단말기 외부 연동 SDK 개발"
----
-
-# [[토스플레이스 결제 단말기 외부 연동 SDK 개발]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 토스플레이스 결제 단말기 외부 연동 SDK는 자체 개발한 결제 단말기인 'Toss Front'에서 외부 연동사가 원하는 플러그인 앱을 개발하고 동작시킬 수 있도록 지원하는 도구입니다 [1]. 이 SDK는 단순한 기능 노출을 넘어, 사용자의 의도(Intent)에 맞춰 복잡한 내부 구현을 재구성하는 퍼사드(Facade) 패턴을 적용하여 설계되었습니다 [2, 3]. 이를 통해 연동 과정에서 발생할 수 있는 휴먼 에러를 구조적으로 방지하고, 단말기 생태계의 안정적인 확장을 도모하는 것을 핵심 목표로 합니다 [2, 4].
-
-## 📖 구조화된 지식 (Synthesized Content)
-- **개발 목적 및 생태계 확장:** 토스 서비스의 데이터를 연동하여 3rd-party 개발자가 외부 연동 플러그인 앱을 무한히 확장할 수 있도록 설계되었습니다 [1]. SDK의 첫인상인 '사용성'이 향후 확장성과 장기적인 유지 사용에 직접적인 영향을 미치기 때문에 쓰기 쉬운 인터페이스 제공이 필수적입니다 [4].
-- **사용자 의도 중심의 퍼사드(Facade) 패턴:** 복잡한 서브시스템(인증, 재시도 로직, 상태 관리, 클린업 등)을 단순히 은닉하는 것이 아니라, **'사용자의 의도'를 기준으로 인터페이스를 재구성**했습니다 [3]. 이를 통해 사용자는 인지 부하 없이 "서버를 시작한다" 또는 "결제를 요청한다"와 같은 자연스러운 목적만 표현할 수 있습니다 [3].
-- **고수준(High-level)과 저수준(Low-level) 인터페이스의 공존:**
-  - **파레토 법칙 적용:** 전체 사용 사례의 80%를 차지하는 일반적인 공통 유즈케이스는 고수준 인터페이스(Facade)를 통해 간단하게 제공합니다 [5, 6].
-  - **탈출구(Escape Hatch) 제공:** 세밀한 제어가 필요한 나머지 20%의 특수한 요구사항을 위해 저수준 인터페이스(예: open, send, listen, close)를 함께 제공하여 **편의성과 유연성의 균형**을 맞춥니다 [5-7].
-- **구조적 안정성과 리소스 관리:** **"리소스를 만든 곳에서 닫는다"는 단일 책임 원칙(SRP)**을 명확히 하여 이벤트나 리스너의 누수(Memory Leak)를 방지합니다 [2, 8]. 체계적인 클린업 수행 책임을 SDK 구조 내에 포함시켜 연동사의 실수로 인한 장애를 원천적으로 차단합니다 [7, 8].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[Facade 패턴]], [[단일 책임 원칙(SRP)]], [[Escape Hatch]]
-- **Projects/Contexts:** [[Toss Front]]
-- **Contradictions/Notes:** 소스에서는 Facade 패턴이 모든 문제의 정답은 아니며, 추상화가 높아질수록 세밀한 제어가 어려워지고 유지 비용이 증가하는 단점이 있다고 지적합니다 [6]. 따라서 Facade의 편리함에만 안주하지 않고, 언제든 저수준 인터페이스로 내려갈 수 있는 탈출구(Escape Hatch)를 제공하여 설계의 균형을 잡는 것이 중요하다고 주장합니다 [6, 7].
-
----
-*Last updated: 2026-04-18*
-- Raw Source: [[00_Raw/2026-04-20/토스플레이스 결제 단말기 외부 연동 SDK 개발.md]]
----
diff --git a/Programming & Language/팀 단위 코드 품질 및 컨벤션 유지.md b/Programming & Language/팀 단위 코드 품질 및 컨벤션 유지.md
deleted file mode 100644
index f4ed0b71..00000000
--- a/Programming & Language/팀 단위 코드 품질 및 컨벤션 유지.md	
+++ /dev/null
@@ -1,43 +0,0 @@
----
-id: P-REINFORCE-AUTO-9B19C8
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - 팀 단위 코드 품질 및 컨벤션 유지"
----
-
-# [[팀 단위 코드 품질 및 컨벤션 유지]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 팀 단위 코드 품질 및 컨벤션 유지는 다수의 개발자가 협업하는 환경에서 일관된 코드 스타일을 적용하고 결함을 사전에 방지하여 소프트웨어의 전반적인 품질을 향상시키는 과정입니다. 이를 위해 ESLint와 Prettier 같은 정적 분석 및 포매팅 도구를 활용하며, Husky와 lint-staged를 통해 Git 훅(Hook) 단계에서 규칙 준수를 강제합니다. 더불어 기계적인 검사와 사람의 아키텍처 판단이 결합된 하이브리드 코드 리뷰와 명확한 거버넌스 정책을 통해 코드베이스의 건전성을 지속적으로 개선합니다.
-
-## 📖 구조화된 지식 (Synthesized Content)
-* **정적 분석 및 포매팅 도구 활용 (ESLint & Prettier)**
-  팀원 간의 코딩 스타일 차이를 줄이고 문법적 오류를 방지하기 위해 정적 분석 도구인 ESLint(Linter)와 스타일 교정 도구인 Prettier(Formatter)를 함께 사용합니다 [1-4]. 두 도구 사용 시 포매팅 역할이 겹쳐 규칙 충돌이 발생할 수 있으므로, `eslint-config-prettier` 패키지를 사용하여 Prettier와 충돌하는 ESLint의 포매팅 규칙을 비활성화하는 방식이 가장 권장됩니다 [5-9].
-
-* **모노레포(Monorepo) 환경의 설정 중앙화**
-  Turborepo 등 여러 패키지가 존재하는 대규모 모노레포 환경에서는 각 패키지마다 설정 파일이 중복되는 것을 막기 위해 중앙 집중식 설정 패키지(예: `@repo/eslint-config`)를 구성합니다 [10-13]. 이를 통해 팀 전체의 린팅 규칙을 단일 소스(Single Source of Truth)로 관리하고, 개별 패키지에서는 이를 확장(extend)하여 패키지별 자율성을 유지하면서 일관성을 지킬 수 있습니다 [14, 15].
-
-* **Git 훅(Hook)을 통한 컨벤션 자동 강제 (Husky & lint-staged)**
-  작성된 코드가 원격 저장소로 푸시되기 전에 규칙 위반 코드가 커밋되는 것을 막기 위해 Husky와 lint-staged를 활용합니다 [16-22]. `pre-commit` 단계에서 전체 코드가 아닌 변경된(staged) 파일에 대해서만 ESLint 및 Prettier를 실행함으로써 검사 속도를 높이고, 규칙에 어긋난 커밋을 자동으로 차단하여 생산성 저하 없이 코드 품질을 강제할 수 있습니다 [21-26].
-
-* **자동화와 수동 코드 리뷰의 결합 (하이브리드 리뷰 체계)**
-  코드 리뷰의 주된 목적은 시간 경과에 따른 코드베이스의 전반적인 상태(Code Health)를 지속적으로 개선하는 것입니다 [27]. 스타일 준수, 구문 오류, 알려진 보안 취약점 등은 자동화 도구에 맡겨 기계적인 속도와 일관성을 확보해야 합니다 [28-30]. 반면 개발자(사람)는 비즈니스 로직, 아키텍처 설계, 조직적 맥락 등 기계가 파악하기 어려운 복잡한 문제를 리뷰하는 하이브리드 방식을 적용해야 가장 효과적입니다 [31-39].
-
-* **AI 도구 도입에 따른 거버넌스 및 정책 수립**
-  팀 내에서 AI 코드 생성 도구를 무분별하게 사용할 경우 코드 품질이 일관되지 않고 지적 재산(IP) 유출 및 보안 취약점이 발생할 수 있습니다 [40-44]. 따라서 AI가 생성한 코드 역시 기존의 품질 표준과 동일한 린팅, 포매팅 적용 및 사람(개발자)의 리뷰와 책임을 요구하는 명확한 정책(AI Usage Policy)을 수립하여 통제해야 합니다 [45, 46].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[ESLint]], [[Prettier]], [[Husky]], [[lint-staged]], [[코드 리뷰(Code Review)]], [[정적 애플리케이션 보안 테스트(SAST)]]
-- **Projects/Contexts:** [[모노레포(Monorepo) 설정 중앙화]], [[CI/CD 파이프라인 자동화]], [[AI 거버넌스 정책(AI Usage Policy)]]
-- **Contradictions/Notes:** 소스에 따르면 ESLint와 Prettier는 함께 사용할 때 포매팅 규칙에서 충돌이 발생할 수 있으며, 이를 해결하기 위해 `eslint-config-prettier`를 사용하여 ESLint의 관련 기능을 끄는 것이 공식 권장 사항입니다 [5, 9]. 또한, 자동화된 코드 리뷰 도구가 매우 빠르고 일관적이지만 비즈니스 로직의 의도나 아키텍처의 문맥을 이해할 수는 없으므로(Context Blindness), 자동화가 수동 리뷰를 완전히 대체해서는 안 되며 상호 보완적으로 사용해야 한다고 강조합니다 [47, 48].
-
----
-*Last updated: 2026-04-18*
-- Raw Source: [[00_Raw/2026-04-20/팀 단위 코드 품질 및 컨벤션 유지.md]]
----
diff --git a/Programming & Language/포인터 압축(Pointer Compression).md b/Programming & Language/포인터 압축(Pointer Compression).md
deleted file mode 100644
index a5490a34..00000000
--- a/Programming & Language/포인터 압축(Pointer Compression).md	
+++ /dev/null
@@ -1,33 +0,0 @@
----
-id: P-REINFORCE-AUTO-E763EA
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - 포인터 압축(Pointer Compression)"
----
-
-# [[포인터 압축(Pointer Compression)]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 포인터 압축(Pointer Compression)은 64비트 플랫폼에서 V8 엔진이 객체 참조에 따른 메모리 오버헤드를 줄이기 위해 포인터를 전체 주소 대신 기본 주소로부터의 32비트 오프셋(offset)으로 저장하는 기술입니다 [1]. 이 기술을 활성화하면 메모리 사용량이 감소하고 전반적인 성능이 향상되지만, 모든 힙 객체가 4GB 크기의 연속된 메모리 영역 내에 상주해야 한다는 제약이 생깁니다 [1-3].
-
-## 📖 구조화된 지식 (Synthesized Content)
-- **포인터 압축의 작동 원리**: 64비트 플랫폼 환경에서 V8 엔진은 메모리를 절약하기 위해 객체 참조 포인터를 64비트가 아닌 기본 주소(base address) 기준의 32비트 오프셋으로 저장합니다 [1]. 이 방식을 통해 객체 참조 시 발생하는 메모리 오버헤드를 절반으로 줄일 수 있습니다 [1].
-- **성능 및 메모리 이점**: 포인터 압축이 활성화되면 V8 힙(heap)의 크기를 최대 40%까지 줄일 수 있으며, CPU 및 가비지 컬렉션(GC) 성능을 5%에서 10%가량 향상시키는 상당한 이점을 제공합니다 [3].
-- **최대 4GB 힙 크기 제한**: 포인터 압축의 가장 큰 단점은 모든 V8 힙 객체가 4GB로 제한된 연속적인 '케이지(cage)' 영역 내에 강제로 상주해야 한다는 점입니다 [1]. 시스템의 전체 RAM 크기가 128GB와 같이 매우 크더라도 단일 V8 isolate가 사용하는 관리 힙 크기는 엄격하게 4GB로 제한됩니다 [2, 4]. 애플리케이션이 이 제한에 도달하면, 엔진은 치명적인 메모리 부족(OOM) 충돌을 피하기 위해 Major GC를 매우 높은 빈도로 실행하게 됩니다 [4].
-- **한계 극복을 위한 우회 방법**: 4GB를 초과하는 더 큰 힙 메모리가 반드시 필요한 애플리케이션의 경우, 포인터 압축이 비활성화된 상태로 빌드된 Node.js 복사본을 앱에 포함시켜 메모리 집약적인 작업을 자식 프로세스로 넘기거나, 포인터 압축을 끈 상태의 사용자 지정 Electron 버전을 빌드하여 사용하는 우회 방안이 존재합니다 [5].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[V8 Memory Cage]], [[V8 Heap]], [[Garbage Collection (GC)]]
-- **Projects/Contexts:** [[Electron]], [[V8 Engine]], [[Node.js]]
-- **Contradictions/Notes:** 포인터 압축은 애플리케이션의 성능 향상 및 메모리 최적화를 제공하지만, 그 대가로 단일 V8 프로세스의 힙 크기를 4GB로 엄격히 제한하는 명확한 트레이드오프(Trade-off)를 갖습니다 [2, 3].
-
----
-*Last updated: 2026-04-19*
-- Raw Source: [[00_Raw/2026-04-20/포인터 압축(Pointer Compression).md]]
----
diff --git a/Programming & Language/폭주-조절 갈등 (Vergence-Accommodation Conflict).md b/Programming & Language/폭주-조절 갈등 (Vergence-Accommodation Conflict).md
deleted file mode 100644
index f075271c..00000000
--- a/Programming & Language/폭주-조절 갈등 (Vergence-Accommodation Conflict).md	
+++ /dev/null
@@ -1,32 +0,0 @@
----
-id: P-REINFORCE-AUTO-6F67B5
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - 폭주-조절 갈등 (Vergence-Accommodation Conflict)"
----
-
-# [[폭주-조절 갈등 (Vergence-Accommodation Conflict)]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 폭주-조절 갈등(Vergence-Accommodation Conflict)은 자연스러운 시야 환경에서 함께 피드백 루프를 형성하여 정확한 깊이 단서를 제공하는 필수 안구 운동 기능인 폭주(Vergence)와 조절(Accommodation)이 서로 분리되거나 불일치하는 현상입니다 [1, 2]. 가상현실용 헤드마운트 디스플레이(HMD)와 같은 환경에서 시각적 깊이 단서가 상충할 때 발생하며, 깊이 지각의 불확실성과 여러 시각적 부작용을 초래합니다 [1, 2].
-
-## 📖 구조화된 지식 (Synthesized Content)
-- **정상적인 시야에서의 폭주와 조절 작동 방식:** 자연스러운 시각 조건에서 폭주와 조절 기능은 피드백 루프 안에서 함께 작용하며, 한 메커니즘의 변화가 다른 메커니즘의 동시 변화를 이끌어냅니다 [1, 2]. 이를 통해 가까운 물체에 대해 단일하고 명확한 초점을 맞출 수 있으며, 흐림(blur)과 양안 시차(disparity)는 폭주와 조절이 더 정확하게 시선을 고정할 수 있도록 돕는 필수적인 망막(retinotopic) 단서로 작용합니다 [2].
-- **HMD 환경에서의 갈등 발생:** 헤드마운트 디스플레이(HMD)를 사용할 경우, 시각적으로 주어지는 깊이 단서들이 상충하게 되면서 폭주와 조절 기능이 서로 분리(decoupled)되는 현상이 발생합니다 [1, 2].
-- **결과 및 수반되는 증상:** 두 기능의 분리는 깊이 지각을 위한 망막 단서에 대한 불확실성을 유발합니다 [1, 2]. 이로 인해 사용자는 두통, 눈의 통증, 시각적 피로, 복시(double vision) 등과 같은 다양한 안구 운동 관련 증상(oculomotor symptoms)을 겪게 될 가능성이 커집니다 [1, 2].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[안구 운동 기능 (Oculomotor Functions)]], [[헤드마운트 디스플레이 (HMD)]], [[깊이 지각 (Depth Perception)]]
-- **Projects/Contexts:** [[가상현실 엑서게임 (VR Exergaming)]]
-- **Contradictions/Notes:** 소스에 폭주-조절 갈등과 관련된 상반된 정보나 모순점은 나타나지 않습니다.
-
----
-*Last updated: 2026-04-19*
-- Raw Source: [[00_Raw/2026-04-20/폭주-조절 갈등 (Vergence-Accommodation Conflict).md]]
----
diff --git a/Programming & Language/폭주-조절 불일치(Vergence-Accommodation Conflicts).md b/Programming & Language/폭주-조절 불일치(Vergence-Accommodation Conflicts).md
deleted file mode 100644
index 3391f9cf..00000000
--- a/Programming & Language/폭주-조절 불일치(Vergence-Accommodation Conflicts).md	
+++ /dev/null
@@ -1,32 +0,0 @@
----
-id: P-REINFORCE-AUTO-254684
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - 폭주-조절 불일치(Vergence-Accommodation Conflicts)"
----
-
-# [[폭주-조절 불일치(Vergence-Accommodation Conflicts)]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 폭주-조절 불일치(Vergence-Accommodation Conflicts)는 머리 착용 디스플레이(HMD)와 같은 가상현실 환경에서 정상적인 안구 운동 기능인 폭주와 조절이 서로 분리(decoupled)되는 현상을 뜻합니다 [1, 2]. 자연스러운 환경에서는 두 기능이 피드백 루프를 통해 함께 작동하여 정확한 깊이 지각을 돕지만, HMD에서는 이 과정이 어긋나게 됩니다 [2]. 이로 인해 깊이 지각의 불확실성이 발생하며, 두통, 눈의 피로, 복시 및 VR 멀미와 같은 다양한 시각적, 신체적 부작용이 유발될 수 있습니다 [1, 2].
-
-## 📖 구조화된 지식 (Synthesized Content)
-* **안구 운동의 정상적 메커니즘**: 폭주(Vergence)와 조절(Accommodation)은 깊이 단서(depth cues)를 정확하게 활용하도록 돕는 필수적인 안구 운동 기능입니다 [1]. 일반적인 시청 조건에서 이 두 메커니즘은 피드백 루프 내에서 함께 작동하므로, 하나의 기제에 변화가 생기면 다른 하나에도 동시적인 변화가 일어납니다 [2].
-* **HMD 환경에서의 불일치 발생**: HMD를 사용할 때 폭주와 조절 기능이 서로 분리(decoupled)되는 현상이 발생할 수 있습니다 [2]. 이러한 분리는 깊이 지각을 위한 망막 단서(retinotopic cues)와 관련된 불확실성을 초래합니다 [2].
-* **시각 및 신체적 증상 유발**: 이 불일치 현상은 두통, 눈의 통증(sore eyes), 피로, 복시(double vision)와 같은 여러 수반되는 증상을 유발할 가능성이 있습니다 [2]. 또한 HMD에서 발생하는 폭주-조절 불일치는 안구 운동 증상을 증가시키며, 가상현실 멀미(VR sickness)를 겪게 만드는 요인이 될 수 있습니다 [1].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[안구 운동 기능(Oculomotor functions)]], [[가상현실 멀미(VR Sickness)]], [[깊이 지각(Depth perception)]], [[헤드 마운트 디스플레이(HMD)]]
-- **Projects/Contexts:** [[가상현실(VR) 시뮬레이션 및 HMD 사용 환경]]
-- **Contradictions/Notes:** 소스에 따르면 폭주-조절 불일치가 특정 개인에게 VR 멀미를 일으키는 직접적인 원인인지, 아니면 단순히 멀미 증상의 심각성을 가중시키는 역할만 하는 것인지에 대해서는 아직 명확하게 밝혀지지 않았습니다 [1].
-
----
-*Last updated: 2026-04-19*
-- Raw Source: [[00_Raw/2026-04-20/폭주-조절 불일치(Vergence-Accommodation Conflicts).md]]
----
diff --git a/Programming & Language/폭주-조절 불일치(Vergence-accommodation conflict).md b/Programming & Language/폭주-조절 불일치(Vergence-accommodation conflict).md
deleted file mode 100644
index 0f196556..00000000
--- a/Programming & Language/폭주-조절 불일치(Vergence-accommodation conflict).md	
+++ /dev/null
@@ -1,33 +0,0 @@
----
-id: P-REINFORCE-AUTO-FC54F0
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - 폭주-조절 불일치(Vergence-accommodation conflict)"
----
-
-# [[폭주-조절 불일치(Vergence-accommodation conflict)]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 폭주-조절 불일치(Vergence-accommodation conflict)는 헤드 마운트 디스플레이(HMD)와 같은 가상현실(VR) 기기를 사용할 때 자연스러운 시각의 폭주(vergence)와 초점 조절(accommodation) 기능이 서로 분리되면서 발생하는 현상입니다 [1, 2]. 이는 상충되는 깊이 단서로 인해 망막의 깊이 지각에 불확실성을 초래하며, 결과적으로 눈의 피로, 두통, 복시 및 VR 멀미와 같은 시각적·인지적 후유증을 유발합니다 [1, 2].
-
-## 📖 구조화된 지식 (Synthesized Content)
-- **자연스러운 시각 피드백의 붕괴:** 일상적인 시야 환경에서 폭주(vergence)와 조절(accommodation)은 근거리 객체에 대해 단일하고 선명한 초점을 맞추기 위해 상호 피드백 루프 안에서 함께 작용합니다 [2]. 즉, 흐림(blur)과 양안 시차(disparity)라는 망막 단서를 바탕으로 한 메커니즘이 변하면 다른 메커니즘도 동시에 반응하게 됩니다 [2].
-- **HMD 환경에서의 기능 분리:** 가상현실 HMD 환경에서는 상충되는 깊이 단서를 지각하게 되면서, 함께 움직여야 할 이 두 가지 필수적인 안구 운동 기능이 분리(decoupled)되는 현상이 발생합니다 [2].
-- **시각 및 인지적 후유증 발생:** 이러한 폭주와 조절의 분리는 망막의 깊이 지각 단서에 대한 불확실성을 유발합니다 [2]. 그 결과 사용자는 두통, 눈의 통증(sore eyes), 시각적 피로(fatigue), 복시(double vision)와 같은 여러 동반 증상을 겪게 됩니다 [2]. 
-- **VR 멀미와의 연관성:** 폭주-조절 불일치는 사용자가 HMD를 통해 경험하는 안구 운동 증상 및 VR 멀미의 주요 요인입니다 [1]. 다만 이 불일치 현상이 특정 개인에게 VR 멀미를 발생시키는 직접적 원인인지, 아니면 멀미 증상의 심각성을 가중시키는 역할만 하는 것인지는 아직 명확하게 규명되지 않았습니다 [1].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[가상현실 멀미(VR sickness)]], [[헤드 마운트 디스플레이(HMD)]], [[깊이 지각(Depth perception)]], [[안구 운동 기능(Oculomotor functions)]]
-- **Projects/Contexts:** [[비트 세이버를 활용한 가상현실 엑서게임 후유증 연구(Exergaming With Beat Saber: An Investigation of Virtual Reality Aftereffects)]]
-- **Contradictions/Notes:** 소스에 따르면 폭주-조절 불일치가 개인의 VR 멀미를 유발하는 근본 원인인지, 혹은 단순히 멀미 증상을 더 악화시키는 복합적 요인인지는 불분명한 상태입니다 [1].
-
----
-*Last updated: 2026-04-19*
-- Raw Source: [[00_Raw/2026-04-20/폭주-조절 불일치(Vergence-accommodation conflict).md]]
----
diff --git a/Programming & Language/폭주-조절 충돌(Vergence-accommodation conflict).md b/Programming & Language/폭주-조절 충돌(Vergence-accommodation conflict).md
deleted file mode 100644
index 5d4528da..00000000
--- a/Programming & Language/폭주-조절 충돌(Vergence-accommodation conflict).md	
+++ /dev/null
@@ -1,30 +0,0 @@
----
-id: P-REINFORCE-AUTO-12CE66
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - 폭주-조절 충돌(Vergence-accommodation conflict)"
----
-
-# [[폭주-조절 충돌(Vergence-accommodation conflict)]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 폭주-조절 충돌(Vergence-accommodation conflict)은 가상현실(VR)의 헤드 마운트 디스플레이(HMD) 사용 시 발생하는 상충되는 깊이 단서로 인해 나타나는 시각적 현상입니다 [1]. 자연스러운 시각 환경에서는 가까운 물체에 초점을 맞추기 위해 폭주(Vergence)와 조절(Accommodation) 기능이 상호 피드백 루프를 통해 함께 작용하지만, HMD에서는 이 두 메커니즘이 분리(decoupled)되면서 충돌을 일으킵니다 [1]. 이 현상은 깊이 지각에 대한 불확실성을 초래하며, 가상현실 멀미나 눈의 피로와 같은 다양한 안구 운동 증상을 유발하는 요인으로 지목되고 있습니다 [1, 2].
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[가상현실 멀미(VR sickness)]], [[안구 운동 기능(Oculomotor functions)]], [[깊이 지각(Depth perception)]], [[헤드 마운트 디스플레이(HMD)]]
-- **Projects/Contexts:** [[가상현실(VR) 경험 및 엑서게이밍(Exergaming)]]
-- **Contradictions/Notes:** 소스에 따르면 폭주-조절 충돌이 VR 멀미의 근본적인 원인인지, 혹은 기존의 멀미 증상을 심화시키는 역할만 하는 것인지에 대해서는 인과관계가 아직 불분명합니다 [2].
-
----
-*Last updated: 2026-04-19*
-- Raw Source: [[00_Raw/2026-04-20/폭주-조절 충돌(Vergence-accommodation conflict).md]]
----
diff --git a/Programming & Language/프론트엔드 및 모노레포(Monorepo) 개발 환경 설정.md b/Programming & Language/프론트엔드 및 모노레포(Monorepo) 개발 환경 설정.md
deleted file mode 100644
index 935c1934..00000000
--- a/Programming & Language/프론트엔드 및 모노레포(Monorepo) 개발 환경 설정.md	
+++ /dev/null
@@ -1,48 +0,0 @@
----
-id: P-REINFORCE-AUTO-F3FA69
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - 프론트엔드 및 모노레포(Monorepo) 개발 환경 설정"
----
-
-# [[프론트엔드 및 모노레포(Monorepo) 개발 환경 설정]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 프론트엔드 및 모노레포(Monorepo) 개발 환경 설정은 대규모 프로젝트에서 코드 품질과 스타일의 일관성을 유지하고 중복된 설정을 줄이기 위한 핵심 과정입니다. Turborepo와 같은 모노레포 환경에서는 여러 애플리케이션과 패키지가 혼재하므로 중앙 집중식 ESLint 및 Prettier 설정 패키지를 구축하는 것이 권장됩니다 [1, 2]. 여기에 Husky와 lint-staged를 결합하여 변경된 파일에 대해서만 린팅(linting)과 포맷팅(formatting)을 수행하도록 오케스트레이션(orchestration)함으로써 개발자의 생산성과 커밋 속도를 크게 향상시킬 수 있습니다 [3, 4].
-
-## 📖 구조화된 지식 (Synthesized Content)
-* **모노레포 환경의 문제점**
-  여러 개의 Next.js 애플리케이션과 라이브러리 패키지가 포함된 대규모 모노레포에서는 각 패키지마다 `.eslintrc.json` 및 `.eslintignore` 파일이 중복 생성되고 린트 규칙이 일관성 없이 적용되는 유지보수 문제가 발생하기 쉽습니다 [5, 6]. 특히 모노레포 루트에서 `lint-staged`를 실행하여 변경된 파일만 검사하려 할 때, 각 패키지의 독립적인 린팅 규칙을 존중하게 만드는 것이 주요한 해결 과제입니다 [2].
-
-* **중앙 집중식 구성(Centralised Config) 패키지 구축**
-  * 이러한 구성 중복 문제를 해결하기 위해 `@repo/eslint-config`와 같은 내부 공유 패키지를 생성하여, 상황에 맞게 조합할 수 있는 프리셋(base, next.js, library)을 구성합니다 [2, 7].
-  * **Base Config**: ESLint 9의 평면 구성(flat config) 포맷을 기반으로 하며, TypeScript 지원, Prettier 통합(충돌 규칙 비활성화)을 기본으로 포함합니다 [7].
-  * **Next.js Config / Library Config**: Next.js 앱을 위한 React 전용 린팅 규칙과 비 React 패키지를 위한 가벼운 TypeScript 규칙을 각각 분리하여 작성합니다 [8].
-
-* **루트 오케스트레이션(Root Orchestration) 구성**
-  * 모노레포 루트에 `eslint.config.mjs`를 생성하여 파일 패턴(glob pattern)에 따라 각 패키지에 적절한 구성을 매핑합니다 [9].
-  * 이 방식은 `lint-staged`가 모노레포 루트에서 실행되더라도 패키지 경계를 존중하여 각 패키지가 자신에게 맞는 올바른 규칙(예: Next.js용 또는 라이브러리용)을 부여받도록 해줍니다 [9, 10].
-
-* **Husky 및 lint-staged 연동**
-  * 루트의 `package.json`과 `.husky/pre-commit` 파일에 `lint-staged`와 Husky를 연동하여 커밋 시 변경된 파일에 대해서만 ESLint와 Prettier가 실행되도록 설정합니다 [3].
-  * 이를 통해 코드 전체를 린트하는 시간을 절약하고, 개발자가 코드를 커밋할 때 자동으로 포맷팅과 린트 수정을 적용할 수 있습니다 [3, 4].
-
-* **Turborepo와의 캐싱 통합 및 도입 효과**
-  * `turbo.json`에 ESLint 구성 패키지를 전역 종속성으로 추가하여 린트 결과를 캐싱하고 설정 변경 시 전체 캐시를 무효화할 수 있습니다 [3].
-  * 이를 통해 패키지 수준의 중복 설정이 크게 줄어들고(Single source of truth 확보), `lint-staged` 및 캐싱을 통한 빠른 커밋이 가능해지며, 새로운 패키지 추가 시 확장성과 개발자 경험(DX)이 크게 향상됩니다 [4, 11].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[Turborepo]], [[ESLint]], [[Prettier]], [[Husky]], [[lint-staged]]
-- **Projects/Contexts:** [[Next.js 애플리케이션 및 내부 라이브러리 패키지 관리]]
-- **Contradictions/Notes:** 모노레포에서 `lint-staged`의 공식 권장 사항은 각 패키지별로 별도의 설정 파일을 두고 가장 가까운 구성 파일이 적용되도록 하는 것이지만 [12, 13], Turborepo를 활용하는 현대적인 접근 방식에서는 루트 오케스트레이션 구성 파일(`eslint.config.mjs`)을 통해 파일 패턴을 각 프리셋에 중앙에서 매핑하는 방식이 더 효율적인 해결책으로 제시됩니다 [9, 10]. 또한, ESLint와 Prettier를 함께 사용할 경우 포맷팅 충돌을 방지하기 위해 반드시 `eslint-config-prettier`를 설정 배열의 마지막에 위치시켜야 합니다 [14].
-
----
-*Last updated: 2026-04-19*
-- Raw Source: [[00_Raw/2026-04-20/프론트엔드 및 모노레포(Monorepo) 개발 환경 설정.md]]
----
diff --git a/Programming & Language/핀테크의 실시간 사기 탐지.md b/Programming & Language/핀테크의 실시간 사기 탐지.md
deleted file mode 100644
index ab8da5c7..00000000
--- a/Programming & Language/핀테크의 실시간 사기 탐지.md	
+++ /dev/null
@@ -1,32 +0,0 @@
----
-id: P-REINFORCE-AUTO-7428BF
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - 핀테크의 실시간 사기 탐지"
----
-
-# [[핀테크의 실시간 사기 탐지]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 핀테크의 실시간 사기 탐지는 금융 거래와 같은 데이터가 발생한 즉시 이를 처리하여 실각적인 통찰력과 조치를 취할 수 있게 하는 필수적인 기능입니다 [1]. 이 시스템은 전통적인 일괄 처리(batch processing)가 아닌 실시간 데이터 스트리밍과 이벤트 중심 아키텍처(Event-driven Architecture)를 기반으로 작동합니다 [1, 2]. 이를 통해 핀테크 기업은 오래된 정보에 의존하여 발생하는 경쟁력 손실을 방지하고 즉각적으로 사기 행위에 대응할 수 있습니다 [1].
-
-## 📖 구조화된 지식 (Synthesized Content)
-- **작동 원리 및 아키텍처:** 핀테크의 실시간 사기 탐지는 금융 트랜잭션과 같은 '이벤트'에 시스템이 즉각적으로 반응하도록 설계된 '이벤트 중심 아키텍처(Event-Driven Architecture)'를 활용합니다 [1]. 이는 데이터가 생성됨과 동시에 이를 처리하는 실시간 데이터 스트리밍 방식을 채택하여 현대 데이터 엔지니어링의 모범 사례로 꼽힙니다 [1].
-- **핵심 기술 및 인프라 요구사항:** 이 아키텍처를 구현하는 데 초석이 되는 핵심 기술로는 Apache Kafka와 AWS Kinesis가 있습니다 [1]. 실시간 데이터 스트리밍 환경을 구축하기 위해서는 분산 시스템과 스트림 의미론(stream semantics)에 대한 이해 등 구현 복잡성이 높으며, 브로커(Brokers) 및 스트림 프로세서 관리와 관련된 높은 수준의 운영 전문 지식(ops expertise)이 필요합니다 [2].
-- **비즈니스적 기대 효과:** 실시간 사기 탐지 시스템의 도입을 통해 시스템 간의 분리(system decoupling), 저지연(Low-latency) 데이터 처리, 그리고 발생한 이벤트에 대한 즉각적인 대응(immediate reaction)이라는 결과물을 얻을 수 있습니다 [2].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[실시간 데이터 스트리밍(Real-time Data Streaming)]], [[이벤트 중심 아키텍처(Event-Driven Architecture)]], [[Apache Kafka]], [[AWS Kinesis]]
-- **Projects/Contexts:** [[현대적 데이터 엔지니어링 파이프라인 구축 맥락(Modern Data Engineering)]]
-- **Contradictions/Notes:** 특정 사기 탐지 알고리즘이나 모델의 구체적인 구현 방법에 대해서는 소스에 관련 정보가 부족합니다.
-
----
-*Last updated: 2026-04-18*
-- Raw Source: [[00_Raw/2026-04-20/핀테크의 실시간 사기 탐지.md]]
----
diff --git a/Programming & Language/하이브리드 검색 (Hybrid Search).md b/Programming & Language/하이브리드 검색 (Hybrid Search).md
deleted file mode 100644
index 65cb2b30..00000000
--- a/Programming & Language/하이브리드 검색 (Hybrid Search).md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-F7F96B
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - 하이브리드 검색 (Hybrid Search)"
----
-
-# [[하이브리드 검색 (Hybrid Search)]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/하이브리드 검색 (Hybrid Search).md]]
----
diff --git a/Programming & Language/할당 타임라인(Allocation Timeline).md b/Programming & Language/할당 타임라인(Allocation Timeline).md
deleted file mode 100644
index 14b4c278..00000000
--- a/Programming & Language/할당 타임라인(Allocation Timeline).md	
+++ /dev/null
@@ -1,43 +0,0 @@
----
-id: P-REINFORCE-AUTO-1A08DE
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - 할당 타임라인(Allocation Timeline)"
----
-
-# [[할당 타임라인(Allocation Timeline)]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 할당 타임라인(Allocation Timeline)은 힙 프로파일러의 상세한 스냅샷 정보와 타임라인 패널의 추적 기능을 결합한 메모리 프로파일링 도구입니다 [1, 2]. 이 도구는 녹화 기간 동안 주기적으로 힙 스냅샷을 캡처하여 객체 할당과 가비지 컬렉션(GC) 이후의 생존 여부를 시각적으로 보여줍니다 [3, 4]. 주로 메모리에 계속 남아 누수를 일으키는 객체를 찾고, 해당 객체가 할당된 정확한 스택 트레이스를 식별하는 데 사용됩니다 [1, 2, 5].
-
-## 📖 구조화된 지식 (Synthesized Content)
-* **작동 방식 및 캡처 주기:** 
-  할당 타임라인은 도구가 실행되는 동안 주기적으로(최대 50ms 간격) 힙 스냅샷을 찍고, 녹화가 끝날 때 최종 스냅샷을 하나 더 캡처하여 시간 경과에 따른 메모리 할당을 시각화합니다 [3, 4, 6]. 타임라인 상단에 나타나는 막대그래프는 힙에서 새로운 객체가 발견된 시점을 나타내며, 막대의 높이는 할당된 객체의 전체 크기를 의미합니다 [6-8].
-
-* **막대 색상을 통한 생존(Liveness) 판별:** 
-  할당 타임라인에서 막대의 색상은 객체의 현재 상태를 구분하는 핵심 지표입니다.
-  * **파란색 막대:** 해당 시간대에 할당된 후 최종 스냅샷 지점까지 메모리에 살아남아 있는 객체를 의미합니다 [5-8].
-  * **회색 막대:** 해당 시간대에 할당되었으나, 이후 가비지 컬렉터(GC)에 의해 정상적으로 수거(Free)된 객체를 의미합니다 [5-9].
-  * 가비지 컬렉션 이후에도 사라지지 않고 남아있는 파란색 막대들은 잠재적인 메모리 누수(Memory Leak) 후보가 됩니다 [9, 10].
-
-* **스택 트레이스 및 원인 분석:**
-  개발자는 타임라인에서 특정 시간대를 마우스로 드래그하여 확대(Zoom in)함으로써, 해당 시간 프레임에 할당된 객체만 표시되도록 생성자(Constructor) 목록을 필터링할 수 있습니다 [5, 9, 11, 12]. 특정 객체를 선택하면 유지 경로(Retaining path)와 할당 스택(Allocation stack) 탭을 통해 해당 객체가 코드의 어느 부분에서 생성되었고, 왜 GC에 의해 수거되지 못했는지 그 원인을 정확히 추적할 수 있습니다 [5, 11, 13, 14].
-
-* **고유 객체 식별자 유지:**
-  가비지 컬렉션이 발생하면 객체의 물리적 메모리 주소가 이동할 수 있기 때문에, 도구는 주소 대신 영구적인 객체 ID(예: `@` 뒤의 숫자)를 부여합니다 [3, 4]. 이 ID는 녹화 세션 중 캡처된 여러 스냅샷 간에 유지되므로 특정 객체의 힙 상태를 정확하게 비교할 수 있게 해줍니다 [3, 4, 15].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[힙 스냅샷(Heap Snapshot)]], [[가비지 컬렉션(Garbage Collection)]], [[메모리 누수(Memory Leak)]]
-- **Projects/Contexts:** [[Chrome DevTools]], [[Microsoft Edge DevTools]]
-- **Contradictions/Notes:** 소스 간의 모순된 내용은 없으며, Chrome DevTools와 Microsoft Edge DevTools 등 Chromium 기반 브라우저 문서들에서 파란색/회색 막대의 의미와 도구의 작동 방식(50ms 주기의 스냅샷 등)을 모두 동일하게 설명하고 있습니다 [3, 4, 7, 8].
-
----
-*Last updated: 2026-04-19*
-- Raw Source: [[00_Raw/2026-04-20/할당 타임라인(Allocation Timeline).md]]
----
diff --git a/Programming & Language/행동 경제학의 인센티브 구조 설계.md b/Programming & Language/행동 경제학의 인센티브 구조 설계.md
deleted file mode 100644
index a56cd724..00000000
--- a/Programming & Language/행동 경제학의 인센티브 구조 설계.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-8FE0F9
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - 행동 경제학의 인센티브 구조 설계"
----
-
-# [[행동 경제학의 인센티브 구조 설계]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/행동 경제학의 인센티브 구조 설계.md]]
----
diff --git a/Programming & Language/행동 경제학의 학습 이론.md b/Programming & Language/행동 경제학의 학습 이론.md
deleted file mode 100644
index 9491fd8e..00000000
--- a/Programming & Language/행동 경제학의 학습 이론.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-151F07
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - 행동 경제학의 학습 이론"
----
-
-# [[행동 경제학의 학습 이론]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/행동 경제학의 학습 이론.md]]
----
diff --git a/Programming & Language/행동 수정 기법.md b/Programming & Language/행동 수정 기법.md
deleted file mode 100644
index f53e7354..00000000
--- a/Programming & Language/행동 수정 기법.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-C66F3C
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - 행동 수정 기법"
----
-
-# [[행동 수정 기법]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/행동 수정 기법.md]]
----
diff --git a/Programming & Language/행동주의 심리학 (Behaviorism).md b/Programming & Language/행동주의 심리학 (Behaviorism).md
deleted file mode 100644
index 6fb7ac13..00000000
--- a/Programming & Language/행동주의 심리학 (Behaviorism).md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-EA760E
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - 행동주의 심리학 (Behaviorism)"
----
-
-# [[행동주의 심리학 (Behaviorism)]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/행동주의 심리학 (Behaviorism).md]]
----
diff --git a/Programming & Language/행동주의 심리학.md b/Programming & Language/행동주의 심리학.md
deleted file mode 100644
index dd67f4f1..00000000
--- a/Programming & Language/행동주의 심리학.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-CC1A7B
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - 행동주의 심리학"
----
-
-# [[행동주의 심리학]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/행동주의 심리학.md]]
----
diff --git a/Programming & Language/헬스케어의 민감 데이터(PII_PCI) 보안 규제 준수.md b/Programming & Language/헬스케어의 민감 데이터(PII_PCI) 보안 규제 준수.md
deleted file mode 100644
index 826f1a12..00000000
--- a/Programming & Language/헬스케어의 민감 데이터(PII_PCI) 보안 규제 준수.md	
+++ /dev/null
@@ -1,30 +0,0 @@
----
-id: P-REINFORCE-AUTO-C45097
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - 헬스케어의 민감 데이터(PII_PCI) 보안 규제 준수"
----
-
-# [[헬스케어의 민감 데이터(PII_PCI) 보안 규제 준수]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 헬스케어 분야와 같이 개인식별정보(PII) 및 지불카드산업(PCI) 데이터를 다루는 시스템에서는 민감한 정보를 보호하고 GDPR, CCPA와 같은 엄격한 규제 요구사항을 충족하기 위해 강력한 보안 조치가 필수적입니다 [1, 2]. 이는 단순한 사후 조치가 아니라, 암호화, 세분화된 접근 제어 및 데이터 익명화를 포함하는 다층적 방어 전략(Multi-layered defense strategy)을 데이터 파이프라인의 모든 단계에 통합하는 것을 의미합니다 [1].
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[데이터 보안 및 암호화(Data Security, Privacy, and Encryption)]], [[역할 기반 접근 제어(RBAC)]], [[데이터 거버넌스(Data Governance)]]
-- **Projects/Contexts:** [[확장 가능한 시스템을 위한 데이터 엔지니어링 모범 사례(Data Engineering Best Practices)]], [[다층적 방어 전략(Multi-layered Defense Strategy)]]
-- **Contradictions/Notes:** 소스에서는 헬스케어 시스템 및 PII/PCI 처리 시스템이 GDPR 및 CCPA 등의 규제를 준수하기 위해 다층적 보안 및 암호화를 도입해야 한다고 설명하고 있으나, 헬스케어 산업에만 특화된 고유 규제(예: HIPAA 등)에 대한 구체적인 세부 지침에 대해서는 소스에 관련 정보가 부족합니다.
-
----
-*Last updated: 2026-04-18*
-- Raw Source: [[00_Raw/2026-04-20/헬스케어의 민감 데이터(PII_PCI) 보안 규제 준수.md]]
----
diff --git a/Programming & Language/회복탄력성 (Resilience).md b/Programming & Language/회복탄력성 (Resilience).md
deleted file mode 100644
index 71218b14..00000000
--- a/Programming & Language/회복탄력성 (Resilience).md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-848690
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - 회복탄력성 (Resilience)"
----
-
-# [[회복탄력성 (Resilience)]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/회복탄력성 (Resilience).md]]
----
diff --git a/Programming & Language/힙 메모리(Heap Memory).md b/Programming & Language/힙 메모리(Heap Memory).md
deleted file mode 100644
index 764fda02..00000000
--- a/Programming & Language/힙 메모리(Heap Memory).md	
+++ /dev/null
@@ -1,44 +0,0 @@
----
-id: P-REINFORCE-AUTO-109DBE
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - 힙 메모리(Heap Memory)"
----
-
-# [[힙 메모리(Heap Memory)]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 힙 메모리(Heap Memory)는 프로그램이 실행되는 동안 크기나 수량을 컴파일 타임에 결정할 수 없는 동적 데이터와 객체를 저장하는 데 사용되는 메모리 영역입니다 [1-3]. 운영 체제가 자동으로 구조를 관리하는 스택(Stack)과 달리, 힙 메모리는 가비지 컬렉터(Garbage Collector)를 통해 더 이상 참조되지 않는 객체의 메모리를 식별하고 주기적으로 회수하는 방식으로 관리됩니다 [4-6]. 특히 V8 엔진은 메모리 할당 및 가비지 컬렉션의 효율성을 극대화하기 위해 객체의 예상 수명(Generational hypothesis)에 따라 힙을 여러 세대별 공간으로 나누어 구조화합니다 [7-9].
-
-## 📖 구조화된 지식 (Synthesized Content)
-*   **힙 메모리의 역할과 구조**
-    *   힙 메모리는 자바스크립트의 객체, 배열, 함수와 같이 동적으로 생성되는 데이터를 저장하는 주요 영역입니다 [2, 3].
-    *   단일 프로세스 레벨 메모리인 레지던트 세트(Resident Set) 내에 존재하며, 힙의 전체 크기는 고정되어 있지 않아 할당 가능한 메모리를 초과하면 "Out of Memory(OOM)" 오류를 일으켜 프로그램이 충돌할 수 있습니다 [2, 10].
-
-*   **V8 엔진의 힙 공간 분할 (Heap Organization)**
-    *   가비지 컬렉터가 최적화된 알고리즘을 적용할 수 있도록, V8 엔진은 힙을 객체의 생존 주기와 특성에 맞게 여러 공간(Space)으로 분할합니다 [8].
-    *   **새로운 공간 (New Space / Young Generation):** 대부분의 새로운 객체가 처음 할당되는 영역입니다 [8, 11]. 작고 빠른 처리를 위해 설계되었으며, 대부분의 객체가 일찍 소멸한다는 가설에 따라 짧은 주기로 빈번하게 마이너 가비지 컬렉션(Scavenger)이 발생합니다 [7, 11-13].
-    *   **오래된 공간 (Old Space / Old Generation):** 새로운 공간에서 최소 두 번의 가비지 컬렉션 주기를 거치고 살아남은 객체들이 승격(Promoted)되어 이동하는 공간입니다 [7, 14]. 내부적으로 다른 객체를 참조하는 포인터 객체 영역(Old-pointer-space)과 문자열이나 숫자 같은 원시 데이터만 가지는 객체 영역(Old-data-space)으로 세분화됩니다 [8, 11].
-    *   **대형 객체 공간 (Large Object Space):** 다른 공간의 크기 제한을 초과하는 대형 객체가 저장되며, 가비지 컬렉터에 의해 절대 이동되지 않고 운영체제로부터 자체적인 메모리 영역(mmap)을 할당받습니다 [3, 8, 11].
-    *   **기타 특수 공간:** JIT 컴파일러가 생성한 실행 가능한 코드를 저장하는 코드 공간(Code Space) 및 균일한 크기를 갖는 객체(Map, Cell, PropertyCell)들만을 저장하여 관리를 단순화하는 특수 공간들이 있습니다 [3, 8, 11].
-
-*   **메모리 관리 및 누수 분석 (Memory Management & Leaks)**
-    *   힙 메모리는 루트 객체(스택 변수나 전역 창 객체 등)로부터 포인터 참조 체인을 따라 도달할 수 있는지를 기준으로 '활성(live)' 객체와 '가비지(dead)' 객체를 식별하여 불필요해진 메모리를 반환합니다 [14-17].
-    *   프로그램에서 더 이상 필요하지 않은 객체가 여전히 루트로부터 참조를 유지하고 있어 가비지 컬렉터가 이를 회수하지 못하고 힙에 누적될 때, 이를 메모리 누수(Memory Leak)라고 합니다 [18-20].
-    *   개발자들은 크롬 개발자 도구의 힙 스냅샷(Heap Snapshot)이나 할당 타임라인(Allocation Timeline) 등의 도구를 사용하여, 힙 메모리에 존재하는 객체 고유의 크기(Shallow size)와 해당 객체 삭제 시 확보 가능한 유지 크기(Retained size)를 확인하고, 참조를 유지하는 경로(Retaining Path)를 추적함으로써 누수 원인을 식별할 수 있습니다 [21-23].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[가비지 컬렉션(Garbage Collection)]], [[스택 메모리(Stack Memory)]], [[메모리 누수(Memory Leak)]], [[V8 엔진(V8 Engine)]]
-- **Projects/Contexts:** [[Node.js 메모리 관리(Node.js Memory Management)]], [[크롬 개발자 도구 힙 프로파일링(Chrome DevTools Heap Profiling)]]
-- **Contradictions/Notes:** 소스에 따르면 V8 메모리 케이지(V8 Memory Cage)와 포인터 압축(Pointer Compression) 기술이 활성화된 환경(예: Chrome 103 및 Electron 21 이상)에서는 시스템에 RAM이 풍부한 64비트 플랫폼에서 실행되더라도 V8 힙의 최대 크기가 4GB로 엄격하게 제한된다는 특이점이 있습니다 [24-27].
-
----
-*Last updated: 2026-04-19*
-- Raw Source: [[00_Raw/2026-04-20/힙 메모리(Heap Memory).md]]
----
diff --git a/Programming & Language/힙 스냅샷 (Heap Snapshots).md b/Programming & Language/힙 스냅샷 (Heap Snapshots).md
deleted file mode 100644
index 3c0f9293..00000000
--- a/Programming & Language/힙 스냅샷 (Heap Snapshots).md	
+++ /dev/null
@@ -1,43 +0,0 @@
----
-id: P-REINFORCE-AUTO-1E11F0
-category: "[[10_Wiki/💡 Topics/Programming & Language]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - 힙 스냅샷 (Heap Snapshots)"
----
-
-# [[힙 스냅샷 (Heap Snapshots)]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 힙 스냅샷(Heap Snapshots)은 특정 시점에 애플리케이션의 자바스크립트 객체와 관련된 DOM 노드가 차지하는 메모리 분포 및 전체 객체 그래프를 캡처하여 보여주는 분석 도구입니다 [1, 2]. 이 도구는 메모리 그래프를 분석하거나 여러 스냅샷을 비교하여 메모리 누수를 찾아내고 객체 참조 트리를 확인하는 데 주로 사용됩니다 [2]. 힙 스냅샷을 생성하는 작업은 항상 가비지 컬렉션(Garbage Collection)과 함께 시작되며, 전역 객체(global object)에서 도달 가능한 객체들만을 화면에 표시합니다 [3].
-
-## 📖 구조화된 지식 (Synthesized Content)
-*   **메모리 누수 탐지 기법 (3-스냅샷 기법):**
-    가장 신뢰할 수 있는 메모리 누수 탐지 방법은 3개의 스냅샷을 사용하는 것입니다 [4]. 먼저 기준점이 되는 스냅샷 1을 찍은 후, 누수가 의심되는 작업(예: 모달 열기/닫기, 라우트 이동 등)을 수행하고 스냅샷 2를 찍습니다 [4]. 이후 동일한 작업을 반복한 뒤 스냅샷 3을 캡처합니다 [4]. 스냅샷 2와 3을 비교하여, 스냅샷 1과 2 사이에 할당되었으나 스냅샷 3에서도 여전히 가비지 컬렉션되지 않고 살아있는 객체들을 누수 후보로 특정할 수 있습니다 [4]. 
-
-*   **객체 식별 및 추적 메커니즘:**
-    스냅샷 내의 객체들에는 `@` 기호 뒤에 고유한 ID 번호가 부여됩니다 [5-7]. 가비지 컬렉션이 발생하면 메모리 상에서 객체의 주소가 이동할 수 있으므로 주소를 표시하는 것은 의미가 없으며, 대신 이 고유 ID를 통해 여러 스냅샷 간에 동일한 객체의 상태를 정밀하게 비교하고 추적할 수 있습니다 [5, 7].
-
-*   **주요 분석 뷰(Views):**
-    힙 스냅샷은 분석 목적에 따라 다양한 시점을 제공합니다 [8].
-    *   **Summary (요약):** 객체들을 생성자(Constructor) 이름과 소스별로 그룹화하여 보여줍니다 [8]. 각 객체에 대해 루트로부터의 거리(`Distance`), 객체 자체가 차지하는 메모리 크기(`Shallow size`), 그리고 해당 객체를 삭제할 경우 확보할 수 있는 메모리 크기(`Retained size`)를 확인할 수 있습니다 [9].
-    *   **Comparison (비교):** 두 개 이상의 스냅샷 간의 차이를 분석하며, 작업 전후의 메모리 델타(추가 및 삭제된 객체 인스턴스)를 검사하여 메모리 누수를 확인합니다 [8, 10].
-    *   **Containment (포함):** `DOMWindow` 객체, 가비지 컬렉터가 사용하는 `GC roots`, 브라우저의 `Native objects`를 진입점으로 삼아 애플리케이션의 메모리 사용 구조를 거시적으로 보여주며 클로저 등을 로우 레벨에서 분석하게 돕습니다 [8, 11, 12].
-
-*   **Retainers (유지자) 분석:**
-    힙 스냅샷 인터페이스 하단의 Retainers 패널은 선택된 특정 객체를 메모리에 유지시키고 있는 다른 객체들의 참조 체인을 가비지 컬렉션 루트에서부터 역순으로 보여줍니다 [1, 12, 13]. 이 참조 체인을 추적하면 객체가 왜 수집되지 않았는지 근본 원인을 찾아 코드를 수정할 수 있습니다 [1, 14].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[가비지 컬렉션 (Garbage Collection)]], [[메모리 누수 (Memory Leaks)]], [[Shallow Size]], [[Retained Size]], [[할당 타임라인 (Allocation Timeline)]]
-- **Projects/Contexts:** [[Chrome DevTools 메모리 패널]], [[V8 자바스크립트 엔진]]
-- **Contradictions/Notes:** 원시 힙 스냅샷에는 사용자의 애플리케이션 객체뿐만 아니라 `(compiled code)`, `(concatenated string)`, `InternalNode` 등 수천 개의 V8 내부 항목들이 포함되어 있으므로, 생성자 필터를 통해 애플리케이션 객체에 초점을 맞춰야 합니다 [15-19]. 또한 메모리 그래프가 커진다고 해서 모두 누수인 것은 아니며(캐시 보존 등 의도적 보존일 수 있음), 네이티브 코드로 실행되는 getter가 구현된 프로퍼티나 숫자 같은 비문자열 값은 자바스크립트 힙에 저장되지 않아 스냅샷에 캡처되지 않는다는 점을 유의해야 합니다 [15, 20].
-
----
-*Last updated: 2026-04-19*
-- Raw Source: [[00_Raw/2026-04-20/힙 스냅샷 (Heap Snapshots).md]]
----
diff --git a/Programming & Memory/ArrayBuffer.md b/Programming & Memory/ArrayBuffer.md
deleted file mode 100644
index c61ad075..00000000
--- a/Programming & Memory/ArrayBuffer.md	
+++ /dev/null
@@ -1,30 +0,0 @@
----
-id: P-REINFORCE-E57886
-category: "[[10_Wiki/💡 Topics/Programming & Memory]]"
-confidence_score: 0.95
-tags: []
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Mega Batch 2 - Wikified ArrayBuffer"
----
-
-# [[ArrayBuffer]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> ArrayBuffer는 V8 엔진과 같은 JavaScript 런타임 환경에서 데이터를 보관하기 위해 사용되는 메모리 객체 구조입니다 [1, 2]. 과거에는 외부의 오프힙(off-heap) 메모리를 가리키도록 허용되어 V8 힙 외부의 데이터를 JavaScript로 전달하는 데 유용하게 쓰였으나, 최근에는 보안 상의 이유로 V8 메모리 케이지(Memory Cage)가 도입되면서 외부 메모리를 직접 참조하는 방식이 차단되었습니다 [1, 3]. 또한, V8 힙 메모리와는 별도로 계산되지만 자체적인 메모리 크기 제한을 가지고 있습니다 [1].
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 지식 자산화 및 기존 네트워크 연동 단계.
-- **정책 변화:** Programming & Memory 카테고리의 전문성 확보 및 링크 밀도 최적화.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[V8 Memory Cage]], [[Type Confusion]], [[Off-heap memory]]
-- **Projects/Contexts:** [[Electron]], [[Chromium/Chrome DevTools]]
-- **Contradictions/Notes:** 소스에 따르면, 과거에는 ArrayBuffer를 활용해 외부에서 생성한 리소스 버퍼를 복사 없이 효율적으로 JavaScript 환경에 래핑할 수 있었으나, 메모리 케이지가 도입된 이후 보안상의 이유로 이 기능이 동작하지 않게 되어 성능 복사 비용이 발생하더라도 V8 내부로 데이터를 복사해야 하는 제약이 생겼습니다 [1, 6, 7].
-
----
-*Last updated: 2026-04-19*
-- Raw Source: [[00_Raw/2026-04-20/ArrayBuffer.md]]
----
diff --git a/Programming & Tools/AST-based-Static-Analysis.md b/Programming & Tools/AST-based-Static-Analysis.md
deleted file mode 100644
index 91b1e795..00000000
--- a/Programming & Tools/AST-based-Static-Analysis.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-8D040C
-category: "[[10_Wiki/💡 Topics/Programming & Tools]]"
-confidence_score: 0.95
-tags: []
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Mega Batch 2 - Wikified AST-based-Static-Analysis"
----
-
-# [[AST-based-Static-Analysis]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 작업 중
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 지식 자산화 및 기존 네트워크 연동 단계.
-- **정책 변화:** Programming & Tools 카테고리의 전문성 확보 및 링크 밀도 최적화.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/AST-based-Static-Analysis.md]]
----
diff --git a/Programming & Web/ASPNET Core.md b/Programming & Web/ASPNET Core.md
deleted file mode 100644
index ab399355..00000000
--- a/Programming & Web/ASPNET Core.md	
+++ /dev/null
@@ -1,32 +0,0 @@
----
-id: P-REINFORCE-761015
-category: "[[10_Wiki/💡 Topics/Programming & Web]]"
-confidence_score: 0.95
-tags: []
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Mega Batch 2 - Wikified ASP.NET Core"
----
-
-# [[ASP.NET Core]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> ASP.NET Core는 내장된 의존성 주입(DI) 컨테이너를 제공하여 소프트웨어의 의존성 역전 원칙 구현을 돕는 프레임워크입니다 [1]. 웹 애플리케이션 개발 시 클린 아키텍처를 적용하여 비즈니스 로직을 프레임워크나 데이터베이스로부터 분리된 구조로 개발할 수 있게 해줍니다 [2]. 다만, 주제를 깊이 있게 다루기에는 소스에 관련 정보가 부족합니다.
-
-## 📖 구조화된 지식 (Synthesized Content)
-- **의존성 역전 원칙(DIP)의 구현 지원**: ASP.NET Core는 내장된 의존성 주입(Dependency Injection) 컨테이너를 포함하고 있습니다 [1]. 이를 통해 소프트웨어 컴포넌트 간의 결합을 분리(decoupling)하고, 객체 지향 설계의 핵심인 의존성 역전 원칙(Dependency Inversion Principle)을 훨씬 수월하게 구현할 수 있도록 지원합니다 [1].
-- **클린 아키텍처(Clean Architecture) 기반의 웹 애플리케이션**: ASP.NET Core 앱을 통해 견고하고 구조화된 코딩 패턴을 가진 웹 애플리케이션을 구축할 수 있습니다 [2]. Controller, Service(또는 Use case), Domain model, Infrastructure와 같은 명확한 계층(Layer)을 사용하여 비즈니스 연산이 특정 웹 프레임워크나 데이터베이스 기술에 강하게 종속되는 것을 방지합니다 [2].
-- **소스 정보의 한계**: ASP.NET Core 프레임워크 자체의 전반적인 기능이나 구동 방식 등에 대해서는 소스에 관련 정보가 부족합니다.
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 지식 자산화 및 기존 네트워크 연동 단계.
-- **정책 변화:** Programming & Web 카테고리의 전문성 확보 및 링크 밀도 최적화.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[Dependency Inversion Principle]], [[Clean Architecture]], [[Dependency Injection]]
-- **Projects/Contexts:** [[Web Applications]]
-- **Contradictions/Notes:** 소스 간의 모순은 없으나, ASP.NET Core라는 루트 주제를 포괄적으로 설명하기에는 제공된 소스에 관련 정보가 부족합니다. 소스에서는 주로 소프트웨어 아키텍처 패턴의 유용한 적용 사례 중 하나로만 짧게 언급하고 있습니다.
-
----
-*Last updated: 2026-04-18*
-- Raw Source: [[00_Raw/2026-04-20/ASP.NET Core.md]]
----
diff --git a/Psychology & Behavior/ABA(Applied Behavior Analysis).md b/Psychology & Behavior/ABA(Applied Behavior Analysis).md
deleted file mode 100644
index db282d35..00000000
--- a/Psychology & Behavior/ABA(Applied Behavior Analysis).md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AI-91A92D
-category: "[[10_Wiki/💡 Topics/Psychology & Behavior]]"
-confidence_score: 0.95
-tags: []
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Batch 9 - Wikified ABA(Applied Behavior Analysis)"
----
-
-# [[ABA(Applied Behavior Analysis)]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 
-
-## 📖 구조화된 지식 (Synthesized Content)
-
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 신규 문서로, 기존 정보와의 충돌 분석 예정.
-- **정책 변화:** Psychology & Behavior 카테고리의 지식 연결망 강화를 위한 표준 위키화 적용.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/ABA(Applied Behavior Analysis).md]]
----
diff --git a/Psychology & Behavior/Addiction Neuroscience.md b/Psychology & Behavior/Addiction Neuroscience.md
deleted file mode 100644
index 08b4c197..00000000
--- a/Psychology & Behavior/Addiction Neuroscience.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AI-60E30A
-category: "[[10_Wiki/💡 Topics/Psychology & Behavior]]"
-confidence_score: 0.95
-tags: []
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Batch 9 - Wikified Addiction Neuroscience"
----
-
-# [[Addiction Neuroscience]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 
-
-## 📖 구조화된 지식 (Synthesized Content)
-
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 신규 문서로, 기존 정보와의 충돌 분석 예정.
-- **정책 변화:** Psychology & Behavior 카테고리의 지식 연결망 강화를 위한 표준 위키화 적용.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Addiction Neuroscience.md]]
----
diff --git a/Psychology & Behavior/Agent-Based Modeling.md b/Psychology & Behavior/Agent-Based Modeling.md
deleted file mode 100644
index 04a45582..00000000
--- a/Psychology & Behavior/Agent-Based Modeling.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-64B5F2
-category: "[[10_Wiki/💡 Topics/Psychology & Behavior]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Agent-Based Modeling"
----
-
-# [[Agent-Based Modeling]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Psychology & Behavior 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Agent-Based Modeling.md]]
----
diff --git a/Psychology & Behavior/Agent-Based-Modeling.md b/Psychology & Behavior/Agent-Based-Modeling.md
deleted file mode 100644
index 08dbd016..00000000
--- a/Psychology & Behavior/Agent-Based-Modeling.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-419E37
-category: "[[10_Wiki/💡 Topics/Psychology & Behavior]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Agent-Based-Modeling"
----
-
-# [[Agent-Based-Modeling]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Psychology & Behavior 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Agent-Based-Modeling.md]]
----
diff --git a/Psychology & Behavior/Amygdala Hyperactivity.md b/Psychology & Behavior/Amygdala Hyperactivity.md
deleted file mode 100644
index 181a9f8a..00000000
--- a/Psychology & Behavior/Amygdala Hyperactivity.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-CE31D3
-category: "[[10_Wiki/💡 Topics/Psychology & Behavior]]"
-confidence_score: 0.95
-tags: []
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Mega Batch - Wikified Amygdala Hyperactivity"
----
-
-# [[Amygdala Hyperactivity]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 핵심 요약 작업 진행 중
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 상세 구성 진행 중
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 지식 자산화 및 기존 네트워크 연동 단계.
-- **정책 변화:** Psychology & Behavior 카테고리의 전문성 확보 및 링크 밀도 최적화.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Amygdala Hyperactivity.md]]
----
diff --git a/Psychology & Behavior/보상의 역효과 (Overjustification Effect).md b/Psychology & Behavior/보상의 역효과 (Overjustification Effect).md
deleted file mode 100644
index 23a9acc8..00000000
--- a/Psychology & Behavior/보상의 역효과 (Overjustification Effect).md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-0B61E9
-category: "[[10_Wiki/💡 Topics/Psychology & Behavior]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - 보상의 역효과 (Overjustification Effect)"
----
-
-# [[보상의 역효과 (Overjustification Effect)]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Psychology & Behavior 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/보상의 역효과 (Overjustification Effect).md]]
----
diff --git a/Psychology & Education/Functional Behavior Analysis (FBA).md b/Psychology & Education/Functional Behavior Analysis (FBA).md
deleted file mode 100644
index 069a5337..00000000
--- a/Psychology & Education/Functional Behavior Analysis (FBA).md	
+++ /dev/null
@@ -1,31 +0,0 @@
----
-id: P-REINFORCE-AI-044
-category: "[[10_Wiki/💡 Topics/Psychology & Education]]"
-confidence_score: 0.97
-tags: [aba, behavior analysis, education, intervention]
-last_reinforced: 2026-06-XX
-github_commit: "[P-Reinforce] Processed FBA.md"
----
-
-# [[Functional Behavior Analysis (FBA)]] (기능적 행동 분석)
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 관찰되는 문제 행동의 '결과'가 아닌, 그 행동이 발생하게 만든 기능(Function)을 과학적으로 파악하여 교육적 개입의 목표를 설정하는 행동주의 심리 평가 방법론이다.
-
-## 📖 구조화된 지식 (Synthesized Content)
-- **정의:** ABA (Applied Behavior Analysis)의 핵심 도구로, 특정 문제 행동이 어떤 환경적 기능을 수행하고 있는지를 체계적으로 분석한다. 단순한 '문제'가 아닌, 기능적 결함으로 접근하는 것이 특징이다.
-- **분석 과정 및 단계:**
-    1. **ABC 기록:** (Antecedent $\rightarrow$ Behavior $\rightarrow$ Consequence) 선행 사건(A), 행동(B), 결과(C)를 시간 순서대로 정밀하게 관찰하고 기록한다.
-    2. **가설 설정:** A와 C 사이의 관계를 분석하여, 이 행동이 충족시키려는 기능적 가설을 세운다 (예: 관심 끌기, 감각 자극 추구, 회피 등).
-    3. **검증 및 개입 계획:** 가장 가능성이 높은 기능을 중심으로 목표를 재설정하고, 해당 기능은 다른 방식으로 충족시킬 수 있는 대안 행동(Replacement Behavior)을 가르치고 강화한다.
-- **임상적 중요성:** 훈련의 초점을 '행동 자체'가 아닌 '기능'에 맞추어, 장기적이고 근본적인 변화를 유도할 수 있게 한다.
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 단순히 행동을 억제(Suppression)하는 것이 목표가 되어서는 안 되며, 기능적 대체(Functional Replacement)를 통해 바람직한 방향으로 에너지를 전환시키는 접근이 필수이다.
-- **정책 변화:** 최근에는 인지 이론(Cognitive Theory)의 관점을 통합하여, 행동 변화 과정에서 사용자의 자기 인식 및 메타인지 개입을 포함하는 다차원적 FBA 모델 개발이 중요해지고 있다.
-
-## 🔗 지식 연결 (Graph)
-- Parent: [[Applied Behavior Analysis (ABA)]]
-- Related: [[Behavioral Economics]] , [[Cognitive Psychology]] , [[Functional-Behavior-Analysis]]
-- Raw Source: [[00_Raw/FBA.md]]
----
\ No newline at end of file
diff --git a/Psychology/ABA.md b/Psychology/ABA.md
deleted file mode 100644
index 9bf286ef..00000000
--- a/Psychology/ABA.md
+++ /dev/null
@@ -1,29 +0,0 @@
----
-id: P-REINFORCE-ABA-001
-category: "[[10_Wiki/💡 Topics/Psychology]]"
-confidence_score: 0.88
-tags: [psychology, behavior, intervention]
-last_reinforced: 2026-04-20
-github_commit: "initial-reinforce"
----
-
-# [[ABA (Applied Behavior Analysis)]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 행동의 원인을 환경과의 상호작용에서 찾아내고 이를 체계적으로 수정하여 삶의 질을 높이는 과학적 접근법.
-
-## 📖 구조화된 지식 (Synthesized Content)
-- **추출된 패턴:** 행동 전후의 맥락(ABC: Antecedent-Behavior-Consequence)을 분석하여 강화와 벌의 기제를 적용하는 행동 분석 패턴.
-- **세부 내용:**
-    - 기능적 행동 평가(FBA)를 통한 근본 원인 파악.
-    - 긍정적 행동 지원을 통한 자율성 존중 중심의 변화.
-    - 신경다양성을 고려한 맞춤형 중재 전략으로의 진화.
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 초기 순응 중심 모델에서 현재는 자율성 지지(Assent-Based Care) 모델로 패러다임 전환 진행 중.
-- **정책 변화:** 사용자 만족도(w3) 피드백에 따라 윤리적 고려 사항 링크 비중 강화.
-
-## 🔗 지식 연결 (Graph)
-- **Parent:** [[10_Wiki/💡 Topics/Psychology]]
-- **Related:** [[Operant-Conditioning]], [[Neurodiversity-Affirming]], [[FBA]]
-- **Raw Source:** [[00_Raw/2026-04-20/ABA(Applied Behavior Analysis).md]]
diff --git a/Psychology/Addiction_Neuroscience.md b/Psychology/Addiction_Neuroscience.md
deleted file mode 100644
index ac270a9e..00000000
--- a/Psychology/Addiction_Neuroscience.md
+++ /dev/null
@@ -1,29 +0,0 @@
----
-id: P-REINFORCE-PSYCH-002
-category: "[[10_Wiki/💡 Topics/Psychology]]"
-confidence_score: 0.93
-tags: [psychology, neuroscience, addiction, brain]
-last_reinforced: 2026-04-20
-github_commit: "batch-reinforce-01"
----
-
-# [[Addiction Neuroscience]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 보상 중추와 전두엽의 균형 파괴를 통해 행동 통제력을 상실하게 만드는 뇌 회로의 만성적 변화 과정.
-
-## 📖 구조화된 지식 (Synthesized Content)
-- **추출된 패턴:** 도파민 분비 과잉으로 인한 중뇌변연계 경로(Mesolimbic Pathway)의 오작동 및 전전두엽 기능 저하 패턴.
-- **세부 내용:**
-    - 갈망(Craving)과 내성(Tolerance)의 생물학적 기제 규명.
-    - 뇌 가소성(Neuroplasticity)을 활용한 재활 가능성 제시.
-    - 유전적 소인과 환경적 요인의 복합적 상호작용 분석.
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 의지력의 결핍으로 보던 시각에서 '뇌 질환(Brain Disease)' 모델로의 완전한 패러다임 전환.
-- **정책 변화:** 지식 구조(w2) 관점에서 행동 심리학과 연계하여 중독 치료 경로 제안.
-
-## 🔗 지식 연결 (Graph)
-- **Parent:** [[10_Wiki/💡 Topics/Psychology]]
-- **Related:** [[Dopamine]], [[Prefrontal-Cortex]], [[Neuroplasticity]]
-- **Raw Source:** [[00_Raw/2026-04-20/Addiction Neuroscience.md]]
diff --git a/Psychology/Behavioral_Economics.md b/Psychology/Behavioral_Economics.md
deleted file mode 100644
index b2e34750..00000000
--- a/Psychology/Behavioral_Economics.md
+++ /dev/null
@@ -1,29 +0,0 @@
----
-id: P-REINFORCE-PSYCH-005
-category: "[[10_Wiki/💡 Topics/Psychology]]"
-confidence_score: 0.90
-tags: [psychology, economics, behavior, nudge]
-last_reinforced: 2026-04-20
-github_commit: "batch-reinforce-04"
----
-
-# [[Behavioral Economics in Digital Ecosystems]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 인간의 비합리적 선택 패턴을 이해하고, 이를 디지털 환경에서 더 나은(혹은 의도된) 의사결정으로 유도하는 디자인 과학.
-
-## 📖 구조화된 지식 (Synthesized Content)
-- **추출된 패턴:** 선택 설계(Choice Architecture)와 넛지(Nudge) 이론을 활용하여 사용자의 인지적 편향을 비즈니스 가치로 전환하는 행동 유도 패턴.
-- **세부 내용:**
-    - 손실 회피(Loss Aversion) 및 사회적 증거(Social Proof) 기제의 디지털 적용.
-    - 다크 패턴(Dark Patterns)의 윤리적 경계와 규제 동향.
-    - 추천 알고리즘 내에서의 기본 옵션(Default) 설정의 힘.
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 합리적 경제인(Homo Economics) 모델을 폐기하고, 감정과 편향에 휘둘리는 실제 인간 모델로의 대체.
-- **정책 변화:** 지식 구조(w2) 관점에서 서비스 기획 가이드와 보건 심리학의 교집합 탐색.
-
-## 🔗 지식 연결 (Graph)
-- **Parent:** [[10_Wiki/💡 Topics/Psychology]]
-- **Related:** [[Operant_Conditioning]], [[Nudge-Theory]], [[Dark-Patterns]]
-- **Raw Source:** [[00_Raw/2026-04-20/Behavioral Economics in Digital Ecosystems.md]]
diff --git a/Psychology/Dopamine.md b/Psychology/Dopamine.md
deleted file mode 100644
index 19567d9a..00000000
--- a/Psychology/Dopamine.md
+++ /dev/null
@@ -1,29 +0,0 @@
----
-id: P-REINFORCE-PSYCH-003
-category: "[[10_Wiki/💡 Topics/Psychology]]"
-confidence_score: 0.96
-tags: [psychology, neuroscience, dopamine, reward]
-last_reinforced: 2026-04-20
-github_commit: "batch-reinforce-03"
----
-
-# [[Dopamine Signaling]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 보상 그 자체보다 '보상에 대한 기대'와 '학습의 신호'로서 작동하며 행동의 동기를 부여하는 뇌의 화학적 메신저.
-
-## 📖 구조화된 지식 (Synthesized Content)
-- **추출된 패턴:** 실제 보상과 예상 보상의 차이(Reward Prediction Error)를 계산하여 행동을 강화하거나 약화시키는 강화학습 패턴.
-- **세부 내용:**
-    - 니그로스트리아탈(Nigrostriatal) 경로를 통한 운동 제어.
-    - 메조림빅(Mesolimbic) 경로를 통한 쾌락과 동기 부여.
-    - 정교한 보상 체계 설계를 위한 게임화(Gamification)의 생물학적 기초.
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 단순 '쾌락 호르몬'이라는 오해를 바로잡고, 학습과 선택의 '가치 평가' 기제로 재정의.
-- **정책 변화:** 중독(w1) 분석 시 도파민 수용체 하향 조절(Downregulation) 가중치 반영.
-
-## 🔗 지식 연결 (Graph)
-- **Parent:** [[10_Wiki/💡 Topics/Psychology]]
-- **Related:** [[Addiction_Neuroscience]], [[Reward-System]], [[Neurotransmitter]]
-- **Raw Source:** [[00_Raw/2026-04-20/Dopamine Signaling.md]]
diff --git a/Psychology/Neuroplasticity.md b/Psychology/Neuroplasticity.md
deleted file mode 100644
index 5df8e85a..00000000
--- a/Psychology/Neuroplasticity.md
+++ /dev/null
@@ -1,29 +0,0 @@
----
-id: P-REINFORCE-PSYCH-007
-category: "[[10_Wiki/💡 Topics/Psychology]]"
-confidence_score: 0.96
-tags: [psychology, neuroscience, plasticity, brain]
-last_reinforced: 2026-04-20
-github_commit: "batch-reinforce-05"
----
-
-# [[Neuroplasticity (뇌 가소성)]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 경험과 학습에 반응하여 뇌의 신경망이 끊임없이 재구성되고 최적화되는 '지성의 유연성'에 대한 생물학적 증명.
-
-## 📖 구조화된 지식 (Synthesized Content)
-- **추출된 패턴:** 시냅스 가소성(Synaptic Plasticity)을 통해 자주 쓰이는 회로는 강화하고, 쓰지 않는 회로는 약화시키는 신경계의 학습 패턴.
-- **세부 내용:**
-    - 후성유전학적(Epigenetics) 변화가 신경 발달과 재활에 미치는 영향.
-    - 성인기에도 지속되는 신경 발생(Neurogenesis)의 가능성.
-    - 환경적 풍요로움(Environmental Enrichment)이 뇌 구조에 주는 긍정적 자극.
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 어린 시절에 뇌 구조가 고정된다는 '결정결정론'을 타파하고, 평생 학습 모델의 근거 마련.
-- **정책 변화:** 지식 구조(w2) 관점에서 강화학습의 '가중치 업데이트'를 뇌 가소성의 디지털 추상화로 정의.
-
-## 🔗 지식 연결 (Graph)
-- **Parent:** [[10_Wiki/💡 Topics/Psychology]]
-- **Related:** [[Dopamine]], [[Addiction_Neuroscience]], [[Learning-Theory]]
-- **Raw Source:** [[00_Raw/2026-04-20/Epigenetics of Neuroplasticity.md]]
diff --git a/Psychology/Nudge_Theory.md b/Psychology/Nudge_Theory.md
deleted file mode 100644
index 5211b16b..00000000
--- a/Psychology/Nudge_Theory.md
+++ /dev/null
@@ -1,29 +0,0 @@
----
-id: P-REINFORCE-PSYCH-006
-category: "[[10_Wiki/💡 Topics/Psychology]]"
-confidence_score: 0.95
-tags: [psychology, nudge, choice-architecture, behavior]
-last_reinforced: 2026-04-20
-github_commit: "batch-reinforce-05"
----
-
-# [[Nudge Theory]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 강요나 금지 없이, 선택의 구조를 미묘하게 설계함으로써 사람들의 행동을 더 나은 방향으로 이끄는 '자유주의적 개입'.
-
-## 📖 구조화된 지식 (Synthesized Content)
-- **추출된 패턴:** 기본 설정(Default) 변경, 가시성 증대, 사회적 규범 활용 등을 통해 특정 선택을 유도하는 디자인 패턴.
-- **세부 내용:**
-    - 리처드 탈러와 캐스 선스타인의 행동 경제학적 프레임워크.
-    - 공공 정책 및 디지털 서비스 설계에서의 넛지 적용 사례.
-    - 인지적 노력을 최소화하면서도 긍정적 결과를 도출하는 '넛지'의 마법.
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 합리적인 정보 제공만으로 충분하다는 고전적 계몽 모델의 한계를 극복.
-- **정책 변화:** 사용자 만족도(w3) 피드백에 따라 다크 패턴과 구분되는 '윤리적 넛지' 가이드라인 강화.
-
-## 🔗 지식 연결 (Graph)
-- **Parent:** [[10_Wiki/💡 Topics/Psychology]]
-- **Related:** [[Behavioral_Economics]], [[Choice-Architecture]], [[Ethical-Design]]
-- **Raw Source:** [[00_Raw/2026-04-20/Nudge Theory.md]]
diff --git a/Psychology/Operant_Conditioning.md b/Psychology/Operant_Conditioning.md
deleted file mode 100644
index 92d9cccb..00000000
--- a/Psychology/Operant_Conditioning.md
+++ /dev/null
@@ -1,29 +0,0 @@
----
-id: P-REINFORCE-PSYCH-004
-category: "[[10_Wiki/💡 Topics/Psychology]]"
-confidence_score: 0.94
-tags: [psychology, behavior, conditioning, skinner]
-last_reinforced: 2026-04-20
-github_commit: "batch-reinforce-03"
----
-
-# [[Operant Conditioning]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 행동의 결과가 미래의 행동 빈도를 결정한다는 원리를 통해 생명체의 적응적 행동 변화를 설명하는 고전적 메카니즘.
-
-## 📖 구조화된 지식 (Synthesized Content)
-- **추출된 패턴:** 정적/부적 강화(Reinforcement)와 처벌(Punishment)의 조합을 통해 행동을 조형(Shaping)하는 환경 통제 패턴.
-- **세부 내용:**
-    - 스키너 박스 실험을 통한 행동 분석의 기초 확립.
-    - 간헐적 강화 스케줄이 행동의 유지와 소거에 미치는 영향.
-    - 현대 지능형 에이전트의 강화학습(RL) 알고리즘의 심리학적 기원.
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 행동의 외적 결과에만 집중하던 행동주의에서, 내적 인지 과정을 포함한 인지 행동 모델로 확장.
-- **정책 변화:** 사용자 경험(UX) 설계(w3) 시 '보상 스케줄'의 윤리적 적용 가이던스 강화.
-
-## 🔗 지식 연결 (Graph)
-- **Parent:** [[10_Wiki/💡 Topics/Psychology]]
-- **Related:** [[ABA]], [[Behavioral-Economics]], [[Reinforcement-Learning]]
-- **Raw Source:** [[00_Raw/2026-04-20/Operant Conditioning.md]]
diff --git a/React_Clean_Code_Best_Practices.md b/React_Clean_Code_Best_Practices.md
deleted file mode 100644
index 713b506e..00000000
--- a/React_Clean_Code_Best_Practices.md
+++ /dev/null
@@ -1,28 +0,0 @@
----
-title: 리액트 클린 코드 및 개발 에티켓
-category: Software Architecture
-tags: [Clean Code, Etiquette, Best Practice, Readable Code]
-created: 2026-04-20
----
-
-# [[React_Clean_Code_Best_Practices]] (리액트 클린 코드)
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 가독성 좋은 코드는 '컴퓨터'가 이해하는 코드가 아니라, '나중에 이 코드를 고칠 동료(혹은 미래의 나)'가 숨 쉬듯 읽어내려갈 수 있는 코드다.
-
-## 📖 구조화된 지식 (Synthesized Content)
-- **Early Return 패턴**: 
-    - 중첩된 `if-else`는 지옥이다. 예외 상황(Loading, Error)을 먼저 `return`으로 쳐내면, 함수의 본체는 항상 가장 중요한 로직만 남게 된다.
-- **Props Destructuring (구조 분해 할당)**:
-    - `props.user.name` 처럼 경로를 길게 쓰는 대신, 함수의 인자 단계에서 `{ user: { name } }` 처럼 분해하라. 코드가 숨을 쉬기 시작한다.
-- **Explicit Naming (명시적 네이밍)**:
-    - 핸들러 함수는 `handle[Action]` (예: `handleSearch`), 비즈니스 함수는 `on[Action]` (예: `onSearchSubmit`)으로 구분하여 책임 소재를 명확히 한다.
-- **조건부 렌더링 에티켓**:
-    - `&&` 연산자 대신 삼항 연산자(`? :`)를 권장한다. 특히 `0 && <Component />` 시 화면에 숫자 0이 출력되는 대참사를 방지하기 위함이다.
-
-## ⚠️ 모순 및 업데이트 (RL Update)
-- 과도한 추상화는 오히려 독이다. 코드가 3줄인데 함수 5개로 쪼개는 것은 가독성을 해친다. '직관성'이 '분리'보다 우선할 때가 있음을 명심하라.
-
-## 🔗 지식 연결 (Graph)
-- Related: [[Collaboration_Governance]] , [[System_Debugging_Protocol]]
-- Foundation: [[React_Mental_Model]]
diff --git a/React_Hooks_Deep_Dive.md b/React_Hooks_Deep_Dive.md
deleted file mode 100644
index cce5236e..00000000
--- a/React_Hooks_Deep_Dive.md
+++ /dev/null
@@ -1,26 +0,0 @@
----
-title: 리액트 훅(Hooks) 심층 분석 및 활용
-category: Software Architecture
-tags: [React, Hooks, useEffect, Custom Hooks]
-created: 2026-04-20
----
-
-# [[React_Hooks_Deep_Dive]] (리액트 훅 심화)
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 훅은 단순히 함수를 재사용하는 것이 아니라, 컴포넌트의 생애 주기와 논리를 '선언적'으로 결합하는 고도의 동기화 기제다.
-
-## 📖 구조화된 지식 (Synthesized Content)
-- **useEffect의 올바른 관점**:
-    - "마운트될 때 실행"이라는 라이프사이클 사고방식에서 벗어나라. `useEffect`는 **의존성 배열의 값과 컴포넌트 외부 시스템(API, DOM 등)을 동기화**하는 작업이다.
-- **Custom Hooks (추상화의 꽃)**:
-    - 복잡한 비즈니스 로직(예: 데이터 페칭, 타이머 관리)을 `useMyLogic` 처럼 따로 빼내어 컴포넌트는 오직 UI 선언에만 집중하게 만든다. 이것이 컴포넌트의 가독성을 폭발시키는 비결이다.
-- **Rules of Hooks**:
-    - 반드시 함수의 최상위에서만 호출되어야 한다. 그래야 리액트가 훅의 상태를 유한 상태 머신처럼 정확한 순서로 관리할 수 있다.
-
-## ⚠️ 모순 및 업데이트 (RL Update)
-- `useEffect` 내에서 무분별하게 상태를 업데이트하면 무한 루프나 성능 저하가 발생한다. 가능하면 `useMemo`나 `useCallback`으로 계산 결과를 캐싱하거나, 상태 업데이트 로직을 `useReducer`로 위임하라.
-
-## 🔗 지식 연결 (Graph)
-- Related: [[React_Performance_Optimization]] , [[React_State_Management_Strategy]]
-- Context: [[WebWorker_Performance]]
diff --git a/React_Mental_Model.md b/React_Mental_Model.md
deleted file mode 100644
index 02838468..00000000
--- a/React_Mental_Model.md
+++ /dev/null
@@ -1,26 +0,0 @@
----
-title: 리액트 핵심 멘탈 모델 (UI as a Function of State)
-category: Software Architecture
-tags: [React, State, Mental Model, Immutability]
-created: 2026-04-20
----
-
-# [[React_Mental_Model]] (리액트 멘탈 모델)
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 리액트 개발은 DOM을 '조작(Manipulate)'하는 것이 아니라, 데이터의 흐름인 '상태(State)'를 정의하고 그 결과물을 화면에 '선언(Declare)'하는 과정이다.
-
-## 📖 구조화된 지식 (Synthesized Content)
-- **UI = f(State)**:
-    - 화면은 상태의 결과값이어야 한다. 명령형(Imperative)으로 "이 버튼의 글자를 바꿔라"라고 하는 순간 리액트의 질서는 무너진다. 오직 상태를 바꾸고 리액트가 알아서 그리게 하라.
-- **Immutability (불변성)**:
-    - 리액트는 객체의 주소값이 변할 때만 렌더링을 시도한다. `arr.push(1)`이 아니라 `setArr([...arr, 1])`처럼 **새로운 원본**을 복제하여 가상 DOM(Virtual DOM)이 효율적으로 동작하게 돕는다.
-- **Virtual DOM Diffing**:
-    - 리액트는 실제 DOM을 직접 건드리기 전에 메모리상의 가상 DOM에서 이전 상태와 비교(Diffing)하여, 꼭 필요한 부분만 실제 화면에 반영(Commit)한다. 이것이 고성능 웹의 비결이다.
-
-## ⚠️ 모순 및 업데이트 (RL Update)
-- 불변성 유지를 위해 매번 거대한 객체를 복사하는 것은 때로 손해다. `Immer` 같은 라이브러리를 쓰거나, 상태의 크기를 작게 쪼개어(Normalization) 업데이트 비용을 최소화하는 전략이 중급 개발자의 역량이다.
-
-## 🔗 지식 연결 (Graph)
-- Related: [[React_Hooks_Deep_Dive]] , [[Component_Design_Patterns]]
-- Foundation: [[System_Protocol_Standard]]
diff --git a/React_Performance_Optimization.md b/React_Performance_Optimization.md
deleted file mode 100644
index 6cc4a0b4..00000000
--- a/React_Performance_Optimization.md
+++ /dev/null
@@ -1,28 +0,0 @@
----
-title: 리액트 렌더링 최적화 전략
-category: Software Architecture
-tags: [Performance, Memoization, React.memo, Optimization]
-created: 2026-04-20
----
-
-# [[React_Performance_Optimization]] (리액트 성능 최적화)
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 가장 빠른 렌더링은 '하지 않는 렌더링'이다. 필요 없는 업데이트를 차단하고 데이터가 흐를 때만 화면이 출렁이게 하라.
-
-## 📖 구조화된 지식 (Synthesized Content)
-- **Memoization (메모이제이션)**:
-    - **React.memo**: 상위 컴포넌트가 변해도 내 Props가 같다면 그리기를 거부한다.
-    - **useMemo**: 비용이 큰 연산 결과(예: 복잡한 필터링)를 저장해두고 재사용한다.
-    - **useCallback**: 함수 객체의 변동을 막아 자식 컴포넌트의 불필요한 리렌더링을 방지한다.
-- **Windowing (가상 리스트)**:
-    - 수천 개의 리스트 아이템이 있어도 사용자의 눈에 보이는 수십 개만 실제 DOM에 렌더링한다. (예: `react-window`, `react-virtualized`).
-- **상태의 위치 선정 (State Colocation)**:
-    - 전역 상태가 바뀔 때마다 앱 전체가 들썩이지 않게 하라. 상태는 그것을 사용하는 가장 하위 컴포넌트 근처로 내려라.
-
-## ⚠️ 모순 및 업데이트 (RL Update)
-- 모든 곳에 `memo`를 쓰는 것은 메모리 낭비다. 리액트의 기본 렌더링 성능은 이미 매우 뛰어나다. 병목 현상이 '실제로 관측'될 때만 최적화를 적용하는 것이 원칙이다.
-
-## 🔗 지식 연결 (Graph)
-- Related: [[WebWorker_Performance]] , [[System_Debugging_Protocol]]
-- Foundation: [[React_Mental_Model]]
diff --git a/React_State_Management_Strategy.md b/React_State_Management_Strategy.md
deleted file mode 100644
index ce445ce1..00000000
--- a/React_State_Management_Strategy.md
+++ /dev/null
@@ -1,28 +0,0 @@
----
-title: 전략적 상태 관리 가이드 (Global & Server State)
-category: Software Architecture
-tags: [State Management, React Query, SSOT, Architecture]
-created: 2026-04-20
----
-
-# [[React_State_Management_Strategy]] (상태 관리 전략)
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 상태는 '어디든' 있을 수 있지만, '아무데나' 있어서는 안 된다. 상태의 생명주기와 전파 범위에 따라 명확한 거주지를 결정하라.
-
-## 📖 구조화된 지식 (Synthesized Content)
-- **상태의 3대 거주지**:
-    1. **Local State (거주형)**: `useState`. 특정 컴포넌트 내부에서만 알고 있는 '사생활' (예: 드롭다운 열림 여부).
-    2. **Global State (공용)**: `Zustand`, `Redux`. 온 동네가 알아야 하는 '공공 정보' (예: 로그인 유저, 다크모드).
-    3. **Server State (빌려온 것)**: `React Query`. 서버에서 잠시 빌려와서 화면에 보여주는 '외부 데이터'.
-- **Server State의 독립**:
-    - 과거엔 Redux에 서버 데이터를 담으려 했으나, 이제는 캐싱, 재시도, 로딩 관리를 전담하는 **React Query/SWR**로 분리하는 것이 세계적인 추세다.
-- **상태의 최소화 원칙**:
-    - 다른 상태로부터 계산될 수 있는 값(예: `firstName`+`lastName` = `fullName`)은 절대 '상태'로 만들지 마라. 렌더링 시점에 계산하는 것이 정합성 유지의 핵심이다.
-
-## ⚠️ 모순 및 업데이트 (RL Update)
-- 무조건적인 전역 상태 지상주의는 'Prop Drilling'보다 위험할 수 있다. 컴포넌트 간의 의존성이 암시적으로 얽히기 때문이다. 상태는 되도록 사용하는 곳에서 가장 가깝게 위치시켜라.
-
-## 🔗 지식 연결 (Graph)
-- Related: [[Single_Source_of_Truth]] , [[API_Communication_Patterns]]
-- Foundation: [[React_Hooks_Deep_Dive]]
diff --git a/React_Testing_Strategy.md b/React_Testing_Strategy.md
deleted file mode 100644
index ca840dd3..00000000
--- a/React_Testing_Strategy.md
+++ /dev/null
@@ -1,26 +0,0 @@
----
-title: 리액트 애플리케이션 테스트 전략
-category: Software Architecture
-tags: [Testing, Vitest, RTL, Unit Test, QA]
-created: 2026-04-20
----
-
-# [[React_Testing_Strategy]] (리액트 테스트 전략)
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 테스트는 '내가 짠 코드'를 검사하는 것이 아니라, '사용자가 경험할 가치'가 유지되고 있는지 수학적으로 증명하는 보험이다.
-
-## 📖 구조화된 지식 (Synthesized Content)
-- **Unit Testing (단위 테스트)**:
-    - `Vitest` 사용. 순수 함수, 비즈니스 로직, 유틸리티 함수가 주어진 입력에 정확한 출력을 내는지 검증한다.
-- **Integration Testing (통합 테스트)**:
-    - `React Testing Library (RTL)`의 철학: "사용자가 보듯 테스트하라." 버튼을 클릭했을 때 화면이 변하는지, 유저의 인터랙션을 시뮬레이션한다.
-- **Mocking (모킹)**:
-    - 서버 API 호출(`msw`)이나 무거운 라이브러리를 가짜(Mock)로 대체하여 환경에 구애받지 않는 안정적인 테스트 환경을 구축한다.
-
-## ⚠️ 모순 및 업데이트 (RL Update)
-- 테스트 커버리지 100% 집착은 생산성을 갉아먹는다. 비즈니스 핵심 로직과 사용자가 가장 많이 쓰는 '메인 시나리오'부터 견고하게 보호하는 지혜가 필요하다.
-
-## 🔗 지식 연결 (Graph)
-- Related: [[System_Debugging_Protocol]] , [[Reliability_Safety_First]]
-- Tool: [[Modern_Environment_Ecosystem]]
diff --git a/Reliability_Safety_First.md b/Reliability_Safety_First.md
deleted file mode 100644
index f764ec90..00000000
--- a/Reliability_Safety_First.md
+++ /dev/null
@@ -1,28 +0,0 @@
----
-title: 애플리케이션 안정성 및 로깅 (Error Boundary)
-category: Software Architecture
-tags: [Reliability, Error Boundary, Sentry, Logging, Stability]
-created: 2026-04-20
----
-
-# [[Reliability_Safety_First]] (애플리케이션 안정성)
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 에러는 막는 것이 아니라 '우아하게 격리'하는 것이다. 컴포넌트 하나가 무너져도 전체 시스템은 안전하게 순항해야 한다.
-
-## 📖 구조화된 지식 (Synthesized Content)
-- **Error Boundary (에러 바운더리)**:
-    - 리액트의 `componentDidCatch` 생명 주기를 활용하여, 특정 하위 컴포넌트 트리의 런타임 에러를 포착하고 '대체 UI'를 보여주는 최후의 방어선이다.
-    - **적용 전략**: 전체 앱을 감싸는 전역 바운더리 외에도, 독립적으로 동작하는 위젯(예: 사이드바, 게시글 목록) 단위로 세밀하게 감싸는 것이 유리하다.
-- **Observability (로깅 및 관측 가능성)**:
-    - **Sentry 연동**: 클라이언트 사이드에서 발생하는 에러를 스택 트레이스와 함께 실시간 수집하여, 사용자가 제보하기 전에 개발자가 먼저 인지하게 한다.
-    - **Contextual Logging**: 에러 발생 시 사용자의 브라우저 버전, 마지막 행동(Breadcrumbs)을 함께 기록하여 재현 가능성을 높인다.
-- **Graceful Fallback**:
-    - 에러 발생 시 단순한 "에러 발생" 문구보다는 "일시적인 오류입니다. [다시 시도하기]" 버튼을 제공하여 사용자 경험 단절을 최소화한다.
-
-## ⚠️ 모순 및 업데이트 (RL Update)
-- 모든 곳에 에러 바운더리를 칠 필요는 없다. 데이터와 UI가 1:1로 매칭되는 구조라면 차라리 상위에서 에러를 처리하는 것이 논리적으로 명확할 수 있다.
-
-## 🔗 지식 연결 (Graph)
-- Related: [[System_Debugging_Protocol]] , [[React_Testing_Strategy]]
-- Foundation: [[System_Protocol_Standard]]
diff --git a/Security & AI/Adversarial Attack (적대적 공격).md b/Security & AI/Adversarial Attack (적대적 공격).md
deleted file mode 100644
index 942824de..00000000
--- a/Security & AI/Adversarial Attack (적대적 공격).md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AI-AFC0C0
-category: "[[10_Wiki/💡 Topics/Security & AI]]"
-confidence_score: 0.95
-tags: []
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Batch 9 - Wikified Adversarial Attack (적대적 공격)"
----
-
-# [[Adversarial Attack (적대적 공격)]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 
-
-## 📖 구조화된 지식 (Synthesized Content)
-
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 신규 문서로, 기존 정보와의 충돌 분석 예정.
-- **정책 변화:** Security & AI 카테고리의 지식 연결망 강화를 위한 표준 위키화 적용.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Adversarial Attack (적대적 공격).md]]
----
diff --git a/Security & Reliability/OWASP Top 10.md b/Security & Reliability/OWASP Top 10.md
deleted file mode 100644
index efe5bfff..00000000
--- a/Security & Reliability/OWASP Top 10.md	
+++ /dev/null
@@ -1,31 +0,0 @@
----
-id: P-REINFORCE-AI-050
-category: "[[10_Wiki/💡 Topics/Security & Reliability]]"
-confidence_score: 0.99
-tags: [security, owasp, vulnerability, secure coding]
-last_reinforced: 2026-06-XX
-github_commit: "[P-Reinforce] Processed OWASP Top 10."
----
-
-# [[OWASP Top 10]] (웹 애플리케이션 보안 취약점)
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 웹 애플리케이션 개발 시 가장 빈번하고 치명적인 상위 10가지 보안 위험 목록으로, 개발 초기 단계부터 'Shift-Left' 원칙에 따라 코딩과 테스트 전반에 걸쳐 방어 로직을 적용하는 것이 필수적이다.
-
-## 📖 구조화된 지식 (Synthesized Content)
-- **개념:** OWASP(Open Web Application Security Project)가 매년 발표하는 웹 보안 취약점 목록이며, 모든 개발 팀이 반드시 숙지해야 할 기본적인 '최소한의 방어선'을 정의한다.
-- **주요 위험 요소 및 대응 원칙 (예시):**
-    1. **Injection (주입 공격):** 가장 흔하며 치명적이다. 사용자 입력을 신뢰하지 않고, 모든 입력에 대해 반드시 파라미터화된 쿼리(Prepared Statement)를 사용해야 한다.
-    2. **Broken Authentication:** 인증 메커니즘을 강력하게 관리해야 한다. 비밀번호 암호화는 최신 알고리즘(Argon2 등)과 복잡한 정책을 따라야 하며, 세션 관리에 주의한다.
-    3. **Cross-Site Scripting (XSS):** 사용자 생성 콘텐츠 출력 시 반드시 컨텍스트 기반 이스케이프(Contextual Escaping) 처리를 거쳐 악성 스크립트 실행을 막아야 한다.
-    4. **Security Misconfiguration:** 기본 설정값을 변경하지 않고 사용하는 실수를 최소화하며, 모든 컴포넌트는 최소 권한 원칙에 따라 운영되어야 한다.
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 보안은 단순히 패치를 적용하는 문제가 아니라, 개발 프로세스(SDLC) 전체에 걸쳐 '보안을 기본으로 생각하는' 문화적 접근이 필요하다.
-- **정책 변화:** SAST/DAST 같은 자동화된 테스트 도구 활용 외에도, 설계 단계에서부터 보안 취약점 분석(Threat Modeling)을 의무화하고, 코드를 검토할 때마다 (Pull Request 기반의) 보안 체크리스트를 도입하는 것이 현대적 표준이다.
-
-## 🔗 지식 연결 (Graph)
-- Parent: [[DevSecOps]]
-- Related: [[SAST (Static Application Security Testing)]] , [[DAST (동적 애플리케이션 보안 테스트)]] , [[Security by Design]]
-- Raw Source: [[00_Raw/OWASP Top 10.md]]
----
\ No newline at end of file
diff --git a/Security/Formal-Methods-in-Software-Engineering.md b/Security/Formal-Methods-in-Software-Engineering.md
deleted file mode 100644
index ceb7ec11..00000000
--- a/Security/Formal-Methods-in-Software-Engineering.md
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-1A7827
-category: "[[10_Wiki/💡 Topics/Security]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Formal-Methods-in-Software-Engineering"
----
-
-# [[Formal-Methods-in-Software-Engineering]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Security 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Formal-Methods-in-Software-Engineering.md]]
----
diff --git a/Separation_of_Concerns.md b/Separation_of_Concerns.md
deleted file mode 100644
index e57cf8eb..00000000
--- a/Separation_of_Concerns.md
+++ /dev/null
@@ -1,25 +0,0 @@
----
-title: 시스템 아키텍처와 관심사 분리 (Separation of Concerns)
-category: Software Architecture
-tags: [Architecture, SoC, Modular Design, Design Pattern]
-created: 2026-04-20
----
-
-# 시스템 아키텍처와 관심사 분리 (SoC)
-
-## 🎯 개요 (Overview)
-복잡한 소프트웨어 시스템을 역할별로 구분된 독립적인 모듈로 나누어, 유지보수성과 확장성을 극대화하는 설계 철학입니다.
-
-## 🚀 계층구조 예시 (Layering Example)
-1.  **Logic Engine**: 순수 비즈니스 로직 및 규칙 수행 (예: `gameWorker.js`)
-2.  **State Manager**: 데이터의 중앙 집중 처리 (예: `TetrisGame.jsx`)
-3.  **View Layer**: 사용자 인터페이스 표현 및 렌더링 (예: React Components)
-
-## 💡 레슨 런 (Lesson Learned)
-> [!IMPORTANT]
-> **"코드의 경계가 명확할 때 시스템은 비로소 건강해진다."**
-> 기능을 추가할 때 기존 코드를 수정하기보다 새로운 모듈을 덧붙일 수 있는 구조를 고민해야 합니다.
-
-## 🔗 연결된 지식
-- [[WebWorker_Performance]]
-- [[Single_Source_of_Truth]]
diff --git a/Simulation & Math/Agent-Based Modeling (ABM).md b/Simulation & Math/Agent-Based Modeling (ABM).md
deleted file mode 100644
index 9ce7b74b..00000000
--- a/Simulation & Math/Agent-Based Modeling (ABM).md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-50111B
-category: "[[10_Wiki/💡 Topics/Simulation & Math]]"
-confidence_score: 0.95
-tags: []
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Batch 10 - Wikified Agent-Based Modeling (ABM)"
----
-
-# [[Agent-Based Modeling (ABM)]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 핵심 내용 요약 예정
-
-## 📖 구조화된 지식 (Synthesized Content)
-세부 본문 내용 구성 예정
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 신규 지식 유입에 따른 기존 지식과의 정합성 검증 단계.
-- **정책 변화:** Simulation & Math 분야의 체계적 지식 자산화 진행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Agent-Based Modeling (ABM).md]]
----
diff --git a/Single_Source_of_Truth.md b/Single_Source_of_Truth.md
deleted file mode 100644
index d62c92be..00000000
--- a/Single_Source_of_Truth.md
+++ /dev/null
@@ -1,24 +0,0 @@
----
-title: 상태 관리의 단일 진실 공급원 (Single Source of Truth)
-category: Software Architecture
-tags: [State Management, Data Consistency, Redux, Architecture]
-created: 2026-04-20
----
-
-# 상태 관리의 단일 진실 공급원 (Single Source of Truth)
-
-## 🎯 개요 (Overview)
-시스템의 핵심 데이터를 중앙 집중식으로 관리하여, 데이터 불일치(Inconsistency) 현상을 원천 차단하고 예측 가능한 데이터 흐름을 확보하는 설계 원칙입니다.
-
-## 🚀 주요 원칙 (Key Principles)
-- **단일 지점 정의 (Defined at Single Point)**: 상태는 오직 한 곳에서만 정의되고 관리되어야 합니다.
-- **예측 가능성 (Predictability)**: 상태 변경은 정해진 규칙(Action/Setter)을 통해서만 발생하여 디버깅을 용이하게 합니다.
-
-## 💡 레슨 런 (Lesson Learned)
-> [!TIP]
-> **"상태는 오직 한 곳에서만 정의하고, 모든 로직은 그 상태를 읽고 쓰는 방식으로 동작해야 한다."**
-> 코드의 파편화를 막기 위해 데이터의 책임 범위(Responsibility)를 명확히 하는 것이 대규모 프로젝트 성공의 열쇠입니다.
-
-## 🔗 연결된 지식
-- [[Separation_of_Concerns]]
-- [[Domain-Driven Design (DDD)]]
diff --git a/Sociology & Tech/Algorithmic Governance.md b/Sociology & Tech/Algorithmic Governance.md
deleted file mode 100644
index 7514c6cc..00000000
--- a/Sociology & Tech/Algorithmic Governance.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-243848
-category: "[[10_Wiki/💡 Topics/Sociology & Tech]]"
-confidence_score: 0.95
-tags: []
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Batch 11 - Wikified Algorithmic Governance"
----
-
-# [[Algorithmic Governance]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 작업 중
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 신규 지식 카테고리화 및 연결성 강화.
-- **정책 변화:** Sociology & Tech 분야의 지식 자산 보호 및 네트워크 확장.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Algorithmic Governance.md]]
----
diff --git a/Sociology & Tech/Algorithmic-Governance.md b/Sociology & Tech/Algorithmic-Governance.md
deleted file mode 100644
index 7071be05..00000000
--- a/Sociology & Tech/Algorithmic-Governance.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-DC50FE
-category: "[[10_Wiki/💡 Topics/Sociology & Tech]]"
-confidence_score: 0.95
-tags: []
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Mega Batch - Wikified Algorithmic-Governance"
----
-
-# [[Algorithmic-Governance]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 핵심 요약 작업 진행 중
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 상세 구성 진행 중
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 지식 자산화 및 기존 네트워크 연동 단계.
-- **정책 변화:** Sociology & Tech 카테고리의 전문성 확보 및 링크 밀도 최적화.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Algorithmic-Governance.md]]
----
diff --git a/Software Architecture/API-Contract-Definition.md b/Software Architecture/API-Contract-Definition.md
deleted file mode 100644
index a25353a5..00000000
--- a/Software Architecture/API-Contract-Definition.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-662214
-category: "[[10_Wiki/💡 Topics/Software Architecture]]"
-confidence_score: 0.95
-tags: []
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Mega Batch - Wikified API-Contract-Definition"
----
-
-# [[API-Contract-Definition]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 핵심 요약 작업 진행 중
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 상세 구성 진행 중
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 지식 자산화 및 기존 네트워크 연동 단계.
-- **정책 변화:** Software Architecture 카테고리의 전문성 확보 및 링크 밀도 최적화.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/API-Contract-Definition.md]]
----
diff --git a/Software Architecture/API-First Architecture.md b/Software Architecture/API-First Architecture.md
deleted file mode 100644
index cf453f5c..00000000
--- a/Software Architecture/API-First Architecture.md	
+++ /dev/null
@@ -1,42 +0,0 @@
----
-id: P-REINFORCE-E43C2B
-category: "[[10_Wiki/💡 Topics/Software Architecture]]"
-confidence_score: 0.95
-tags: []
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Mega Batch - Wikified API-First Architecture"
----
-
-# [[API-First Architecture]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> **API-First Architecture**는 애플리케이션 프로그래밍 인터페이스(API)를 시스템의 최우선 제품으로 취급하는 소프트웨어 설계 방식입니다 [1]. 제품을 먼저 구축하고 나중에 API를 덧붙이는 대신, API의 설계와 문서화부터 개발을 시작합니다 [1]. 이러한 계약 우선(contract-first) 방법론을 통해 API의 일관성과 재사용성을 보장하며, 프론트엔드와 백엔드 개발 팀이 분리되어 병렬로 효율적인 작업을 진행할 수 있도록 지원합니다 [1, 2].
-
-## 📖 구조화된 지식 (Synthesized Content)
-* **작동 방식 및 주요 원칙**
-  * **계약 주도 개발 (Contract-Driven Development):** 개발 팀들은 OpenAPI나 AsyncAPI와 같은 사양을 사용하여 엔드포인트, 데이터 모델, 인증 방법 등을 명시한 API 계약(contract)에 동의합니다 [3]. 이렇게 정의된 사양은 이후의 모든 개발 및 통합 작업의 명확한 지침이 됩니다 [3].
-  * **독립적인 개발 주기:** API 계약이 정의되면, 프론트엔드 팀은 모의(Mocked) 버전의 API를 기반으로 즉시 UI 개발과 테스트를 진행할 수 있고, 동시에 백엔드 팀은 실제 비즈니스 로직을 구현할 수 있어 개발 주기가 효과적으로 분리됩니다 [2, 3].
-  * **일관된 클라이언트 경험 제공:** 웹 프론트엔드, 모바일 앱, 서드파티 서비스 등 모든 클라이언트를 위한 중앙 통합 지점 역할을 수행하여, API 소비주체들에게 일관되고 예측 가능한 경험을 보장합니다 [1, 3].
-
-* **실행 가능한 구현 팁 (Actionable Implementation Tips)**
-  * **API 사양 언어 사용:** REST 아키텍처의 경우 OpenAPI, 이벤트 주도 아키텍처의 경우 AsyncAPI와 같은 표준화된 사양을 사용하여 명확하고 기계가 읽을 수 있는 계약을 생성해야 합니다 [4].
-  * **코드 및 문서 자동 생성:** API 사양 파일에서 직접 서버 스텁(stubs), 클라이언트 SDK 및 대화형 문서를 자동으로 생성하는 도구를 활용하면 수동 작업을 줄이고 문서가 구식이 되는 것을 방지할 수 있습니다 [4].
-  * **병렬 개발을 위한 API 모킹(Mocking):** Postman이나 Stoplight 같은 도구를 사용하여 사양에 기반한 기능적인 모의 서버(Mock server)를 생성해야 합니다 [4]. 이는 프론트엔드 개발자의 작업 병목을 해소하고 조기 테스트와 피드백을 가능하게 합니다 [4].
-
-* **이상적인 활용 사례 및 기대 효과**
-  * 공개 API(Public APIs) 환경, 다중 팀의 통합이 필요한 프로젝트, 프론트엔드와 백엔드의 병렬 작업이 요구되는 현대적인 분산 시스템에 가장 이상적인 아키텍처입니다 [2, 5].
-  * 명확한 계약의 확립, 병렬 개발을 통한 속도 향상, 더 나은 문서화를 도출할 수 있습니다 [5].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 지식 자산화 및 기존 네트워크 연동 단계.
-- **정책 변화:** Software Architecture 카테고리의 전문성 확보 및 링크 밀도 최적화.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[Contract-Driven Development]], [[OpenAPI]], [[AsyncAPI]]
-- **Projects/Contexts:** [[Stripe]], [[Twilio]] (이 철학으로 잘 문서화된 API를 구축하여 비즈니스를 성장시킨 대표적인 기업 사례 [3])
-- **Contradictions/Notes:** 소스 내에 상충되는 주장은 존재하지 않습니다. 다만, 이 구조의 구현 복잡성은 '중간(Medium)' 수준이며, 성공적인 도입과 유지를 위해서는 스펙 우선(spec-first)의 규율과 명확한 거버넌스가 요구된다고 명시하고 있습니다 [5].
-
----
-*Last updated: 2026-04-18*
-- Raw Source: [[00_Raw/2026-04-20/API-First Architecture.md]]
----
diff --git a/Software Architecture/API-First-Design.md b/Software Architecture/API-First-Design.md
deleted file mode 100644
index 5308dfd8..00000000
--- a/Software Architecture/API-First-Design.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-7482EF
-category: "[[10_Wiki/💡 Topics/Software Architecture]]"
-confidence_score: 0.95
-tags: []
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Mega Batch - Wikified API-First-Design"
----
-
-# [[API-First-Design]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 핵심 요약 작업 진행 중
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 상세 구성 진행 중
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 지식 자산화 및 기존 네트워크 연동 단계.
-- **정책 변화:** Software Architecture 카테고리의 전문성 확보 및 링크 밀도 최적화.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/API-First-Design.md]]
----
diff --git a/Software Architecture/AlphaGo (Monte Carlo Tree Search  RL)] [Autonomous Driving Simulation] [Robotic Manipulation.md b/Software Architecture/AlphaGo (Monte Carlo Tree Search  RL)] [Autonomous Driving Simulation] [Robotic Manipulation.md
deleted file mode 100644
index 61b33e82..00000000
--- a/Software Architecture/AlphaGo (Monte Carlo Tree Search  RL)] [Autonomous Driving Simulation] [Robotic Manipulation.md	
+++ /dev/null
@@ -1,29 +0,0 @@
----
-id: P-REINFORCE-AUTO-4BB54E
-category: "[[10_Wiki/💡 Topics/Software Architecture]]"
-confidence_score: 0.98
-tags: [AlphaGo, MCTS, Reinforcement Learning, Simulation, Robotics]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Substantial content added to AI Simulation Bundle."
----
-
-# [[AlphaGo (Monte Carlo Tree Search + RL)], [Autonomous Driving Simulation], [Robotic Manipulation]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 복잡한 의사결정 문제는 '모든 경우의 수'를 계산하는 것이 아니라, '승리(성공) 가능성이 높은 경로'를 시뮬레이션으로 탐색하고 그 경험을 신경망(RL)에 내재화하는 과정이다.
-
-## 📖 구조화된 지식 (Synthesized Content)
-- **AlphaGo (MCTS + RL)의 정수**:
-    - **Monte Carlo Tree Search (MCTS)**: 무작위 시뮬레이션을 통해 유망한 수(Node)를 확장하고 통계적으로 최적의 수를 찾는다.
-    - **Reinforcement Learning (강화 학습)**: 자가 대국(Self-play)을 통해 정책망(Policy Network)과 가치망(Value Network)을 고도화하여, 인간의 기보를 뛰어넘는 직관을 형성한다.
-- **자율주행 시뮬레이션 (Autonomous Driving Simulation)**:
-    - 현실에서의 사고는 치명적이다. 디지털 트윈 환경에서 수백만 마일의 가상 주행을 통해 코너 케이스(Edge Cases)를 학습시키고, 이를 현실 세계의 제어 알고리즘으로 이식(Sim-to-Real)한다.
-- **로봇 조작 (Robotic Manipulation)**:
-    - 물체의 마찰력, 중력, 촉감을 물리 엔진 내에서 물리 법칙으로 구현하고, 강화 학습을 통해 로봇 팔이 정교한 동작을 수행하도록 훈련시킨다.
-
-## ⚠️ 모순 및 업데이트 (RL Update)
-- 시뮬레이션은 정교할수록 좋지만, 현실과의 괴리인 'Reality Gap'이 항상 존재한다. 이를 해결하기 위해 Domain Randomization(시뮬레이션 환경에 무작위 변동을 주어 강건함을 확보) 기법이 필수적으로 동반되어야 한다.
-
-## 🔗 지식 연결 (Graph)
-- Related: [[Digital Twins]] , [[Reinforcement Learning]] , [[Systemic_Simulation_Principles]]
-- Foundation: [[Information Theory]]
diff --git a/Software Architecture/Architectural-Constraint-Enforcement.md b/Software Architecture/Architectural-Constraint-Enforcement.md
deleted file mode 100644
index 5579cd1a..00000000
--- a/Software Architecture/Architectural-Constraint-Enforcement.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-4F930E
-category: "[[10_Wiki/💡 Topics/Software Architecture]]"
-confidence_score: 0.95
-tags: []
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Mega Batch - Wikified Architectural-Constraint-Enforcement"
----
-
-# [[Architectural-Constraint-Enforcement]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 핵심 요약 작업 진행 중
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 상세 구성 진행 중
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 지식 자산화 및 기존 네트워크 연동 단계.
-- **정책 변화:** Software Architecture 카테고리의 전문성 확보 및 링크 밀도 최적화.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Architectural-Constraint-Enforcement.md]]
----
diff --git a/Software Architecture/Deterministic Lockstep Architecture.md b/Software Architecture/Deterministic Lockstep Architecture.md
deleted file mode 100644
index df07ddb6..00000000
--- a/Software Architecture/Deterministic Lockstep Architecture.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-1D4EC0
-category: "[[10_Wiki/💡 Topics/Software Architecture]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Deterministic Lockstep Architecture"
----
-
-# [[Deterministic Lockstep Architecture]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Software Architecture 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Deterministic Lockstep Architecture.md]]
----
diff --git a/Software Architecture/Domain-Driven Design (DDD).md b/Software Architecture/Domain-Driven Design (DDD).md
deleted file mode 100644
index 316c8458..00000000
--- a/Software Architecture/Domain-Driven Design (DDD).md	
+++ /dev/null
@@ -1,30 +0,0 @@
----
-id: P-REINFORCE-AI-048
-category: "[[10_Wiki/💡 Topics/Software Architecture]]"
-confidence_score: 0.99
-tags: [ddd, bounded context, domain modeling, software architecture]
-last_reinforced: 2026-06-XX
-github_commit: "[P-Reinforce] Processed Domain-Driven Design (DDD)."
----
-
-# [[Domain-Driven Design (DDD)]] (도메인 주도 설계)
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 소프트웨어의 복잡성을 관리하기 위해, 비즈니스 도메인의 핵심 개념(Ubiquitous Language)을 중심으로 시스템 경계(Bounded Context)를 설정하고 모델링하는 접근 방식이다.
-
-## 📖 구조화된 지식 (Synthesized Content)
-- **핵심 목표:** 기술적 구현에 앞서 '도메인 전문가의 언어'가 소프트웨어의 설계 원칙이 되도록 강제함으로써, 개발자가 도메인의 본질을 놓치지 않게 하는 것이 목적이다.
-- **주요 개념:**
-    1. **유비쿼터스 언어 (Ubiquitous Language):** 비즈니스 사용자와 개발자 모두가 같은 단어를 사용하며 오해의 소지를 없애는 공통 언어. 이는 코딩과 문서화에 일관되게 반영되어야 한다.
-    2. **바운디드 컨텍스트 (Bounded Context, BC):** 하나의 개념(예: '사용자')이 시스템 내에서 다르게 정의될 수 있음을 인지하고, 각 비즈니스 영역별로 경계를 설정한다. (Context-Mapping).
-    3. **애그리게이트 (Aggregate):** 트랜잭션의 일관성을 보장하는 데이터 단위. 애그리게이트 루트(Aggregate Root)를 통해 내부 객체들의 변경을 제어하며, 데이터베이스 레벨에서 무결성을 유지한다.
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** DDD가 모든 문제에 대한 해결책은 아니며, 도메인이 명확하지 않은 초기 단계에서는 오히려 오버 엔지니어링(Over-engineering)을 초래할 수 있다. 우선적으로 가장 복잡하고 중요한 핵심 영역부터 적용하는 전략이 필요하다.
-- **정책 변화:** 마이크로서비스 아키텍처와 매우 높은 시너지를 내며, 각 서비스가 하나의 Bounded Context를 담당하도록 경계를 설정하는 것이 일반적이다.
-
-## 🔗 지식 연결 (Graph)
-- Parent: [[Microservices-Architecture]]
-- Related: [[Bounded Contexts]] , [[Ubiquitous Language]] , [[Aggregate Root]]
-- Raw Source: [[00_Raw/Domain-Driven Design (DDD).md]]
----
\ No newline at end of file
diff --git a/Software Architecture/Hello Games Development Lifecycle.md b/Software Architecture/Hello Games Development Lifecycle.md
deleted file mode 100644
index 6af4ebc9..00000000
--- a/Software Architecture/Hello Games Development Lifecycle.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-1D420B
-category: "[[10_Wiki/💡 Topics/Software Architecture]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Hello Games Development Lifecycle"
----
-
-# [[Hello Games Development Lifecycle]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Software Architecture 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Hello Games Development Lifecycle.md]]
----
diff --git a/Software Architecture/Microservices-Architecture.md b/Software Architecture/Microservices-Architecture.md
deleted file mode 100644
index ff17e97e..00000000
--- a/Software Architecture/Microservices-Architecture.md	
+++ /dev/null
@@ -1,33 +0,0 @@
----
-id: P-REINFORCE-AI-048
-category: "[[10_Wiki/💡 Topics/Software Architecture]]"
-confidence_score: 0.99
-tags: [microservice, architecture, distributed system, scalability]
-last_reinforced: 2026-06-XX
-github_commit: "[P-Reinforce] Processed Microservices-Architecture.md"
----
-
-# [[Microservices-Architecture]] (마이크로서비스 아키텍처)
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 하나의 거대한 애플리케이션을 작고 독립적인 서비스들의 집합으로 나누어, 각 서비스를 독립적으로 개발, 배포, 확장할 수 있게 하는 분산 시스템 설계 방식이다.
-
-## 📖 구조화된 지식 (Synthesized Content)
-- **정의:** 단일 책임 원칙(SRP)을 아키텍처 수준까지 끌어올린 개념이다. 비즈니스 도메인별로 독립적인 서비스 경계(Bounded Context)를 설정하고, 각 서비스를 자체 데이터베이스와 통신 메커니즘으로 운영한다.
-- **장점 (Scalability & Resilience):** 
-    1. **독립적 배포:** 특정 기능의 장애가 전체 시스템에 영향을 미치지 않는다 (Fault Isolation).
-    2. **기술 스택 자유도:** 각 서비스는 가장 적합한 언어와 데이터베이스를 선택할 수 있다 (Polyglot Persistence/Programming).
-    3. **확장성:** 트래픽이 몰리는 특정 서비스만 독립적으로 자원을 증설할 수 있다.
-- **주요 과제 및 해결책:**
-    1. **분산 트랜잭션 관리:** 여러 서비스에 걸친 데이터 일관성 유지가 어렵다. (해결책: Saga 패턴, 이벤트 기반 아키텍처).
-    2. **서비스 간 통신 오버헤드:** 네트워크 호출이 빈번하여 지연 시간이 발생할 수 있다. (해결책: API Gateway 도입, 메시지 큐 활용).
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 마이크로서비스가 모든 문제의 해결책은 아니다. 서비스 경계 설정 실패(Poor Bounded Context Identification)는 오히려 복잡성만 높이는 '분산 트랜잭션 지옥'을 만들 수 있다.
-- **정책 변화:** MSA 도입 시, 서비스 간 통신 규약 (API Contract) 정의가 가장 중요한 첫 번째 단계이며, 이를 위한 API 게이트웨이 및 서비스 메시(Service Mesh)의 활용이 표준으로 자리 잡고 있다.
-
-## 🔗 지식 연결 (Graph)
-- Parent: [[Microservices-Architecture]]
-- Related: [[Bounded Contexts]] , [[Event Storming]] , [[API-First Architecture]]
-- Raw Source: [[00_Raw/Microservices-Architecture.md]]
----
\ No newline at end of file
diff --git a/Software Architecture/Nudge Theory.md b/Software Architecture/Nudge Theory.md
deleted file mode 100644
index 228dedb4..00000000
--- a/Software Architecture/Nudge Theory.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-A26B83
-category: "[[10_Wiki/💡 Topics/Software Architecture]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Nudge Theory"
----
-
-# [[Nudge Theory]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Software Architecture 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Nudge Theory.md]]
----
diff --git a/Software Architecture/Sports Management Theory.md b/Software Architecture/Sports Management Theory.md
deleted file mode 100644
index 8548cc68..00000000
--- a/Software Architecture/Sports Management Theory.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-B81B6E
-category: "[[10_Wiki/💡 Topics/Software Architecture]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Sports Management Theory"
----
-
-# [[Sports Management Theory]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Software Architecture 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Sports Management Theory.md]]
----
diff --git a/Software Architecture/Throttling  Debouncing (스로틀링과 디바운싱).md b/Software Architecture/Throttling  Debouncing (스로틀링과 디바운싱).md
deleted file mode 100644
index 667e12b3..00000000
--- a/Software Architecture/Throttling  Debouncing (스로틀링과 디바운싱).md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-AUTO-A0A08A
-category: "[[10_Wiki/💡 Topics/Software Architecture]]"
-confidence_score: 0.90
-tags: [auto-reinforced]
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Continuous Worker - Throttling  Debouncing (스로틀링과 디바운싱)"
----
-
-# [[Throttling  Debouncing (스로틀링과 디바운싱)]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
-- **정책 변화:** Software Architecture 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Throttling & Debouncing (스로틀링과 디바운싱).md]]
----
diff --git a/Software Reliability/Amazon-AWS-Formal-Verification.md b/Software Reliability/Amazon-AWS-Formal-Verification.md
deleted file mode 100644
index 8a465f34..00000000
--- a/Software Reliability/Amazon-AWS-Formal-Verification.md	
+++ /dev/null
@@ -1,25 +0,0 @@
----
-id: P-REINFORCE-F8937D
-category: "[[10_Wiki/💡 Topics/Software Reliability]]"
-confidence_score: 0.95
-tags: []
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Mega Batch - Wikified Amazon-AWS-Formal-Verification"
----
-
-# [[Amazon-AWS-Formal-Verification]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 핵심 요약 작업 진행 중
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 상세 구성 진행 중
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 지식 자산화 및 기존 네트워크 연동 단계.
-- **정책 변화:** Software Reliability 카테고리의 전문성 확보 및 링크 밀도 최적화.
-
-## 🔗 지식 연결 (Graph)
-
-- Raw Source: [[00_Raw/2026-04-20/Amazon-AWS-Formal-Verification.md]]
----
diff --git a/Styling_Governance.md b/Styling_Governance.md
deleted file mode 100644
index 4d7e38ec..00000000
--- a/Styling_Governance.md
+++ /dev/null
@@ -1,27 +0,0 @@
----
-title: 스타일 거버넌스 및 디자인 시스템
-category: Software Architecture
-tags: [Styling, Tailwind, CSS-in-JS, Design System, Responsive]
-created: 2026-04-20
----
-
-# [[Styling_Governance]] (스타일 매니지먼트)
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 디자인은 '예쁜 픽셀'이 아니라 '일관된 약속'이다. 단 하나의 변수가 바뀌었을 때 전체 앱의 조화가 유지되는 구조가 진짜 디자인 시스템이다.
-
-## 📖 구조화된 지식 (Synthesized Content)
-- **Design Tokens (디자인 토큰)**:
-    - 색상(#FF0000 -> `brand-primary`), 여백(16px -> `spacing-md`)을 추상화된 이름으로 정의하라. 그래야 브랜드 리뉴얼 시 코드 한 줄로 대응 가능하다.
-- **Utility-First vs Runtime Style**:
-    - **Tailwind CSS**: 클래스명으로 스타일을 정의하여 런타임 오버헤드가 없고 개발 속도가 압도적이다.
-    - **Styled-components**: 컴포넌트 중심의 의미론적 스타일링과 동적 Props 처리에 강점이 있다.
-- **Mobile First Responsive**:
-    - 작은 화면부터 디자인을 시작하여 넓은 화면으로 확장하라. 이것이 CSS 코드를 30% 이상 줄이는 지름길이다.
-
-## ⚠️ 모순 및 업데이트 (RL Update)
-- 과도한 '공통 컴포넌트'화는 오히려 독이 될 수 있다. 버튼 하나에 옵션이 20개가 달리는 순간, 그 버튼은 유지보수의 재앙이 된다. 적절한 '복제'와 '분리'의 균형을 유지하라.
-
-## 🔗 지식 연결 (Graph)
-- Related: [[Component_Design_Patterns]] , [[Accessibility_Inclusivity]]
-- Best Practice: [[React_Clean_Code_Best_Practices]]
diff --git a/System Architecture & Reliability/Distributed-Systems-Engineering.md b/System Architecture & Reliability/Distributed-Systems-Engineering.md
deleted file mode 100644
index bf90c3bf..00000000
--- a/System Architecture & Reliability/Distributed-Systems-Engineering.md	
+++ /dev/null
@@ -1,30 +0,0 @@
----
-id: P-REINFORCE-AI-051
-category: "[[10_Wiki/💡 Topics/System Architecture & Reliability]]"
-confidence_score: 0.98
-tags: [distributed system, distributed computing, consistency, fault tolerance]
-last_reinforced: 2026-06-XX
-github_commit: "[P-Reinforce] Processed Distributed-Systems-Engineering."
----
-
-# [[Distributed-Systems-Engineering]] (분산 시스템 공학)
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 여러 독립적인 컴퓨터가 네트워크를 통해 협력하여 하나의 거대한 작업을 수행할 때 발생하는 복잡성(지연, 일관성, 장애 처리)을 체계적으로 관리하고 안정성을 확보하는 학문이다.
-
-## 📖 구조화된 지식 (Synthesized Content)
-- **핵심 난제:** 분산 시스템의 가장 큰 어려움은 '시간'과 '상태(State)'를 다루는 것이다. 중앙 서버가 없으므로, 통신 순서의 보장이나 완벽한 동기화가 불가능하다.
-- **주요 원칙 및 이론:**
-    1. **CAP Theorem (일관성/가용성/분할 내성):** 세 가지 속성 중 두 가지만 선택할 수 있다는 근본적인 제약을 이해하고, 시스템 설계 목표에 맞춰 트레이드오프를 결정해야 한다. (대부분의 실무는 AP 또는 CP 전략을 사용).
-    2. **결과적 일관성 (Eventual Consistency):** 모든 노드가 즉시 같은 값을 갖지 못하더라도, 시간이 지나면 결국 동일한 상태로 수렴한다는 원칙을 이해하고 비즈니스 프로세스에 적용해야 한다.
-    3. **장애 허용 설계:** 네트워크 지연이나 일부 서비스의 다운을 가정하고, 리트라이(Retry), 서킷 브레이커(Circuit Breaker), 폴백(Fallback) 등의 패턴을 적용하여 시스템 전체가 무너지지 않도록 방어하는 것이 필수적이다.
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 완벽한 동기화는 불가능함을 인정하고, 비즈니스 요구사항에 따라 '충분히 일관된(Good Enough)' 상태를 목표로 하는 실용적 접근이 중요하다.
-- **정책 변화:** 서비스 메쉬 (Service Mesh) 기술의 도입으로, 로드 밸런싱, 트래픽 제어, 인증/인가 등의 기능을 애플리케이션 코드 외부에서 네트워크 레벨로 분리하여 관리하는 것이 표준화되었다.
-
-## 🔗 지식 연결 (Graph)
-- Parent: [[Microservices-Architecture]]
-- Related: [[CAP Theorem]] , [[Saga Pattern]] , [[Circuit Breaker]]
-- Raw Source: [[00_Raw/Distributed-Systems-Engineering.md]]
----
\ No newline at end of file
diff --git a/System Architecture & Simulation/Digital Twins.md b/System Architecture & Simulation/Digital Twins.md
deleted file mode 100644
index 2893c1bd..00000000
--- a/System Architecture & Simulation/Digital Twins.md	
+++ /dev/null
@@ -1,30 +0,0 @@
----
-id: P-REINFORCE-AI-056
-category: "[[10_Wiki/💡 Topics/System Architecture & Simulation]]"
-confidence_score: 0.98
-tags: [digital twin, simulation, iot, cyber-physical]
-last_reinforced: 2026-06-XX
-github_commit: "[P-Reinforce] Processed Digital Twins."
----
-
-# [[Digital Twins]] (디지털 트윈)
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 현실 세계의 물리적 자산(Asset)을 가상 공간에 실시간으로 복제하여, 시뮬레이션과 예측을 통해 실제 시스템 운영 최적화 및 문제 해결 방안을 사전에 검증하는 기술이다.
-
-## 📖 구조화된 지식 (Synthesized Content)
-- **정의:** 물리적인 객체(Physical Asset)와 그 디지털 모델(Digital Model)이 실시간으로 양방향 통신하며 동기화되는 시스템. 단순히 시뮬레이션 모델을 만드는 것을 넘어, '실제 운영 환경'과의 연결성이 핵심이다.
-- **구현 요소 및 필요 지식:**
-    1. **데이터 수집 (IoT Telemetry):** 센서 데이터(Edge Computing)를 통해 물리적 상태를 끊임없이 측정하고 전송해야 한다.
-    2. **모델링/시뮬레이션:** 대상 시스템의 동역학, 열역학 등 복잡한 물리 법칙을 수학적으로 모델링한다. (Computational Geometry + Physics-Based Simulation).
-    3. **실시간 연동 및 예측:** 시뮬레이션 결과(가상)를 바탕으로 실제 장비에 최적화된 제어 명령을 역으로 전송하는 폐쇄 루프 시스템이 필요하다 (Cybernetics / Feedback Control Systems).
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 디지털 트윈의 가치는 '데이터를 모으는 것' 자체가 아니라, 수집된 데이터를 통해 **미래를 예측하고(Prediction)** 시스템을 개선하는 데서 나온다. 즉, 목적이 중요하며, 이는 시뮬레이션 이론으로 뒷받침되어야 한다.
-- **정책 변화:** 산업의 특성상 높은 수준의 실시간 데이터 무결성과 보안(Cybersecurity) 요구사항이 따르므로, 아키텍처 레벨에서 신뢰성을 확보하는 것이 최우선 과제이다.
-
-## 🔗 지식 연결 (Graph)
-- Parent: [[Internet of Things (IoT) Telemetry]]
-- Related: [[Computational Geometry]] , [[Feedback-Control-Systems]] , [[Real-Time-Game-Engines]]
-- Raw Source: [[00_Raw/Digital Twins.md]]
----
\ No newline at end of file
diff --git a/System Design & Modeling/Event Storming.md b/System Design & Modeling/Event Storming.md
deleted file mode 100644
index 3a78b902..00000000
--- a/System Design & Modeling/Event Storming.md	
+++ /dev/null
@@ -1,32 +0,0 @@
----
-id: P-REINFORCE-AI-049
-category: "[[10_Wiki/💡 Topics/System Design & Modeling]]"
-confidence_score: 0.98
-tags: [event, event storming, domain modeling, saga]
-last_reinforced: 2026-06-XX
-github_commit: "[P-Reinforce] Processed Event Storming."
----
-
-# [[Event Storming]] (이벤트 폭풍 분석)
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 비즈니스 워크플로우를 구성하는 '사건(Event)'을 중심으로 시스템의 경계, 행위자, 흐름을 시각적으로 모델링하여, 분산 시스템 및 메시징 기반 아키텍처 설계의 초석을 다지는 기법이다.
-
-## 📖 구조화된 지식 (Synthesized Content)
-- **정의:** 비즈니스 도메인의 활동을 '사건(Event)'이라는 관찰 가능한 사실들의 집합으로 바라보고, 이를 시각적 워크숍 형태로 모델링하는 방법론. 시스템 설계에 필요한 모든 상호작용을 이벤트 중심으로 재구성한다.
-- **주요 구성 요소 (The Grid):**
-    1. **Events (사건):** 과거에 *일어난* 사실의 기록 (가장 중요). 예: `OrderPlaced`, `UserRegistered`.
-    2. **Commands (명령):** 시스템에게 *무엇을 해야 하는지* 지시하는 행위. 예: `PlaceOrder`, `RegisterUser`.
-    3. **Aggregates/Services:** 비즈니스 로직이 묶여서 수행되는 주체.
-    4. **Participants:** 이벤트를 발생시키거나 명령을 내리는 사람 또는 시스템 액터.
-- **아키텍처적 의의:** 이벤트 스트리밍(Event Streaming) 기반 아키텍처 (EDA) 설계에 최적화되어 있으며, 이는 마이크로서비스 간의 비동기 통신 패턴을 정의하는 데 결정적인 역할을 한다.
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 이벤트 중심 설계(Event-Driven Architecture, EDA)가 곧 모든 것을 해결한다는 오해를 경계해야 한다. 이벤트를 중심으로 시스템을 모델링하는 것이지, 실제로 모든 통신이 메시징 큐로 이루어져야 하는 것은 아니다.
-- **정책 변화:** Event Sourcing 패턴과 결합될 때 가장 강력하며, 시간의 흐름에 따른 상태 변화 기록(Audit Log)을 시스템의 핵심 데이터로 활용할 수 있게 된다.
-
-## 🔗 지식 연결 (Graph)
-- Parent: [[Event Storming]]
-- Related: [[Microservices-Architecture]] , [[System Dynamics]] , [[Saga Pattern]]
-- Raw Source: [[00_Raw/Event Storming.md]]
----
\ No newline at end of file
diff --git a/System_Debugging_Protocol.md b/System_Debugging_Protocol.md
deleted file mode 100644
index 22e46087..00000000
--- a/System_Debugging_Protocol.md
+++ /dev/null
@@ -1,27 +0,0 @@
----
-title: 단계별 시스템 디버깅 체크리스트 (L1~L3)
-category: Software Architecture
-tags: [Debugging, Troubleshooting, Checklist, Process]
-created: 2026-04-20
----
-
-# 단계별 시스템 디버깅 체크리스트 (The Diagnostic Flowchart)
-
-## 🔍 L1: 환경 및 무결성 검증 (Low Level)
-- **대상**: 404 Error, Syntax Error, 파일 경로.
-- **목표**: **'실행 가능한 물리적 토대'**가 마련되어 있는가?
-- **필수 조치**: 강제 새로고침(Ctrl + F5), 서버 재시작(Restart Ritual).
-
-## 🔍 L2: 통신 및 데이터 흐름 검증 (Communication)
-- **대상**: `onmessage`, `postMessage`, 비동기 처리.
-- **목표**: 메시지가 의도한 대로 흐르고 있는가?
-- **필수 조치**: 데이터 흐름 추적(`console.log`), 핸들러 동작 유무 확인.
-
-## 🔍 L3: 논리 엔진 및 비즈니스 검증 (High Level)
-- **대상**: 비즈니스 로직, 수학적 공식, 물리 엔진.
-- **목표**: 코드가 논리적으로 무결한가?
-- **필수 조치**: 최소 실행 예제(MRE)를 통한 격리 테스트.
-
-## 🔗 연결된 지식
-- [[Tetris_Project_Retrospective]]
-- [[DevOps_Environment_Setup]]
diff --git a/System_Protocol_Standard.md b/System_Protocol_Standard.md
deleted file mode 100644
index ad3808c9..00000000
--- a/System_Protocol_Standard.md
+++ /dev/null
@@ -1,26 +0,0 @@
----
-title: 표준 시스템 통신 프로토콜 및 상태 제어
-category: Software Architecture
-tags: [Protocol, State Machine, Data Exchange, Lifecycle]
-created: 2026-04-20
----
-
-# 표준 시스템 통신 프로토콜 및 상태 제어
-
-## 📡 데이터 교환 규약 (Standard Protocol)
-모든 컴포넌트 간 통신은 예측 가능한 형태를 유지해야 합니다.
-- **포맷**: `{ type: 'ACTION_TYPE', payload: { data: value } }`
-- **주요 액션 타입**:
-    - `INIT`: 시스템 초기화 및 동기화 시작.
-    - `KEY_INPUT`: 사용자 인터랙션 데이터 전송.
-    - `UPDATE`: 엔진 계산 결과의 브로드캐스트.
-
-## 🔄 시스템 생명 주기 (Life Cycle)
-시스템은 [초기화 $\rightarrow$ 활성 루프 $\rightarrow$ 종료/정리]의 명확한 단계를 거쳐야 리소스 누수(Memory Leak)를 방지할 수 있습니다.
-
-## 🚨 상태 머신 (State Machine) 도입
-시스템 복잡도가 임계치를 넘을 경우, `READY`, `RUNNING`, `PAUSED` 등 상태를 명시적으로 제어하는 **State Machine** 적용을 원칙으로 삼습니다.
-
-## 🔗 연결된 지식
-- [[Project_Architecture_Guidelines]]
-- [[Single_Source_of_Truth]]
diff --git a/Systemic Modeling & Fun/Game Design Theory.md b/Systemic Modeling & Fun/Game Design Theory.md
deleted file mode 100644
index 8bbe7672..00000000
--- a/Systemic Modeling & Fun/Game Design Theory.md	
+++ /dev/null
@@ -1,32 +0,0 @@
----
-id: P-REINFORCE-AI-059
-category: "[[10_Wiki/💡 Topics/Systemic Modeling & Fun]]"
-confidence_score: 0.98
-tags: [game design, system theory, ludology, emergent behavior]
-last_reinforced: 2026-06-XX
-github_commit: "[P-Reinforce] Processed Game Design Theory."
----
-
-# [[Game Design Theory]] (게임 디자인 이론)
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 게임의 재미와 깊이를 수학적, 심리학적, 시스템 공학적 관점에서 체계적으로 분석하고 설계하는 원칙과 방법론을 다룬다. 단순히 '재미있게'가 아닌, 예측 가능한 규칙(Ruleset) 위에서 발생하는 복잡한 상호작용에 집중한다.
-
-## 📖 구조화된 지식 (Synthesized Content)
-- **핵심 관점의 분리:** 게임 디자인은 크게 세 가지 학문적 접근으로 분석된다.
-    1. **루도로그(Ludology):** 시스템과 규칙 자체를 가장 중요하게 본다. (규칙 기반의 수학적, 공학적 측면).
-    2. **서사학(Narratology):** 이야기와 캐릭터의 감성적 몰입을 최우선으로 한다. (감정, 플롯 구조).
-    3. **플레이어 경험(Player Experience):** 위 두 가지를 아우르며, 사용자가 게임 속에서 느끼는 총체적인 만족도와 의미 부여에 초점을 둔다.
-- **시스템 설계 원리:**
-    *   **Emergence (창발성):** 단순한 규칙들의 상호작용을 통해 예측할 수 없는 거대한 패턴이 나타나는 현상(가장 중요한 재미의 근원). 시스템적 사고를 요구한다.
-    *   **밸런싱 이론:** 게임 내의 요소들 간의 힘의 균형을 유지하여, 특정 전략에 대한 독주를 막고 플레이어에게 지속적인 선택지를 제공하는 과정 (Game Balance Theory).
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 게임 디자인은 '완성된 결과물'이 아니라 끊임없는 '반복적 실험(Iteration)'의 산물임을 인지해야 한다. 개발 초기부터 테스트 가능한 가설을 세우고 검증하는 과정이 핵심이다.
-- **정책 변화:** 최근에는 AI 에이전트들이 게임 세계 내에서 자율적으로 상호작용하며 발생하는 예측 불가능한 시나리오(AI Agent Simulation)를 설계의 중요한 축으로 다루고 있다.
-
-## 🔗 지식 연결 (Graph)
-- Parent: [[Game Design Theory]]
-- Related: [[Systemic Game Design]] , [[Emergent Gameplay]] , [[Behavioral Economics in Digital Ecosystems]]
-- Raw Source: [[00_Raw/Game Design Theory.md]]
----
\ No newline at end of file
diff --git a/Systemic_Simulation_Principles.md b/Systemic_Simulation_Principles.md
deleted file mode 100644
index 3cf8eceb..00000000
--- a/Systemic_Simulation_Principles.md
+++ /dev/null
@@ -1,24 +0,0 @@
----
-title: 시스템 시뮬레이션 설계 원리
-category: Systemic Modeling & Fun
-tags: [Simulation, Physics Engine, Systemic Modeling, Ruleset]
-created: 2026-04-20
----
-
-# 시스템 시뮬레이션 설계 원리
-
-## 🎯 개요 (Overview)
-현실 세계의 물리 법칙이나 비즈니스 규칙을 수학적으로 정의하고, 이를 절대적으로 우회할 수 없는 시스템 내의 법(Law)으로 구축하는 설계 기법입니다.
-
-## 🚀 핵심 메커니즘 (Mechanisms)
-- **규칙 강제 (Ruleset Enforcement)**: 모든 상태 변화는 사전에 정의된 물리 엔진 함수(`checkCollision` 등)를 거쳐야만 합니다.
-- **수학적 모델링**: 변화를 시각적 묘사가 아닌 데이터와 수식으로 먼저 증명합니다.
-
-## 💡 레슨 런 (Lesson Learned)
-> [!TIP]
-> **"모든 시뮬레이션은 수학적 규칙을 절대 우회할 수 없도록 강제해야 한다."**
-> 이를 통해 단순한 게임을 넘어 자율주행, 물리 엔진 등 고도의 결정론적 시스템 모델링이 가능해집니다.
-
-## 🔗 연결된 지식
-- [[WebWorker_Performance]]
-- [[Separation_of_Concerns]]
diff --git a/Tetris_Project_Retrospective.md b/Tetris_Project_Retrospective.md
deleted file mode 100644
index 44c54f1d..00000000
--- a/Tetris_Project_Retrospective.md
+++ /dev/null
@@ -1,30 +0,0 @@
----
-title: 프로젝트 회고: 고성능 테트리스 아키텍처
-category: Projects
-tags: [Retrospective, Tetris, Architecture, Performance]
-created: 2026-04-20
----
-
-# 프로젝트 회고: 고성능 테트리스 아키텍처 (P-Reinforce)
-
-## 🌊 프로젝트 아키텍처 요약
-본 프로젝트는 **Web Worker**를 활용한 완전한 연산-렌더링 분리를 실현하여, 실시간 게임 환경에서 극강의 부드러움을 확보하는 데 성공했습니다.
-
-### 🧩 컴포넌트별 기술적 역할
-- **Game Engine**: 물리 계산 및 상태 전이 (`public/gameWorker.js`).
-- **State Manager**: UI의 유일한 진실 공급원 (`src/App.js`).
-- **Renderer**: Props 기반의 순수 매핑 렌더러 (`src/components/GameBoard.jsx`).
-
-## ⚠️ 핵심 교훈 (Lessons Learned)
-> [!IMPORTANT]
-> **"논리가 완벽해도 실행 환경이 무너지면 아무 의미가 없다."**
-> 아키텍처 설계만큼이나 '파일 무결성 검증'과 '환경 재설정 루틴'이 개발 생산성에 지대한 영향을 미친다는 것을 확인했습니다.
-
-## 🏆 성과
-- [x] Web Worker 기반 비동기 엔진 구축 완료.
-- [x] 표준 통신 프로토콜 기반의 Decoupling 성공.
-- [x] 체계적인 디버깅 프로토콜 수립.
-
-## 🔗 연결된 지식
-- [[System_Debugging_Protocol]]
-- [[Project_Architecture_Guidelines]]
diff --git a/TypeScript 컴파일러의 정적 타입 시스템.md b/TypeScript 컴파일러의 정적 타입 시스템.md
deleted file mode 100644
index e69de29b..00000000
diff --git a/TypeScript_Type_Safety.md b/TypeScript_Type_Safety.md
deleted file mode 100644
index 6fc052aa..00000000
--- a/TypeScript_Type_Safety.md
+++ /dev/null
@@ -1,26 +0,0 @@
----
-title: 타입스크립트 기반의 안정적 개발 (Type Safety)
-category: Software Architecture
-tags: [TypeScript, Interface, Type Safety, Generic]
-created: 2026-04-20
----
-
-# [[TypeScript_Type_Safety]] (타입스크립트 정석)
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 타입스크립트는 당신을 귀찮게 하는 '잔소리꾼'이 아니라, 런타임 에러라는 '낭떠러지' 앞에서 당신을 붙잡아주는 '생명줄'이다.
-
-## 📖 구조화된 지식 (Synthesized Content)
-- **Non-Nullable & Narrowing**:
-    - 데이터가 `null`이거나 `undefined`일 수 있음을 코드 수준에서 강제로 인지시켜, 런타임에서 발생하는 'TypeError'를 90% 이상 사전 차단한다.
-- **Generics (추상화의 끝판왕)**:
-    - 데이터의 구체적인 타입은 나중에 정하지만, 그 구조의 일관성은 유지하고 싶을 때 사용한다. 재사용 가능한 고기능 컴포넌트 제작의 필수 요건이다.
-- **Interface & Alias**:
-    - 시스템 전체에 흐르는 데이터의 '형태(Shape)'를 정의하라. 타입 정의만 잘 되어 있어도 코드는 스스로를 설명하는 훌륭한 문서가 된다.
-
-## ⚠️ 모순 및 업데이트 (RL Update)
-- `any`를 남발하는 순간 타입스크립트의 모든 이점은 사라진다. 차라리 `unknown`을 쓰고 타입을 좁히는(Narrowing) 방식을 택하라. 타입 정의에 너무 많은 시간을 뺏기는 '타입 헬(Type Hell)'을 경계하고 적절한 타협점을 찾아라.
-
-## 🔗 지식 연결 (Graph)
-- Related: [[React_Clean_Code_Best_Practices]] , [[React_Hooks_Deep_Dive]]
-- Foundation: [[System_Protocol_Standard]]
diff --git a/Web & Performance/Analyze runtime performance.md b/Web & Performance/Analyze runtime performance.md
deleted file mode 100644
index 9685c00f..00000000
--- a/Web & Performance/Analyze runtime performance.md	
+++ /dev/null
@@ -1,51 +0,0 @@
----
-id: P-REINFORCE-C8C70C
-category: "[[10_Wiki/💡 Topics/Web & Performance]]"
-confidence_score: 0.95
-tags: []
-last_reinforced: 2026-04-20
-github_commit: "[P-Reinforce] Mega Batch - Wikified Analyze runtime performance"
----
-
-# [[Analyze runtime performance]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 런타임 성능(Runtime performance) 분석은 페이지가 로드되는 시점이 아니라, 페이지가 실제로 실행되는 동안 어떻게 작동하는지 측정하고 평가하는 과정입니다 [1]. 개발자는 주로 Chrome DevTools의 성능(Performance) 패널을 활용하여 페이지와 상호 작용하는 동안의 활동을 기록합니다 [1, 2]. 이를 통해 애니메이션 프레임 속도(FPS), CPU 과부하, 메인 스레드 병목 현상 등을 식별하여 전반적인 사용자 경험을 최적화할 수 있습니다 [3, 4].
-
-## 📖 구조화된 지식 (Synthesized Content)
-* **측정 및 시뮬레이션 환경 설정:** 
-  * 런타임 성능은 Chrome DevTools의 성능(Performance) 패널에서 기록(Record) 버튼을 눌러 캡처할 수 있습니다 [2, 5]. 
-  * 데스크톱이나 랩톱에 비해 컴퓨팅 성능이 떨어지는 모바일 기기에서의 실행 환경을 모방하기 위해, 캡처 설정(Capture settings)에서 'CPU Throttling(CPU 스로틀링)'을 사용하여 CPU 속도를 4배(4x) 또는 20배(20x) 느리게 시뮬레이션할 수 있습니다 [6, 7].
-  * 네트워크 조건 역시 스로틀링을 통해 느린 모바일 연결 상태로 테스트할 수 있습니다 [7].
-
-* **FPS 및 CPU 활동 분석:**
-  * 애니메이션 성능을 측정하는 주요 지표는 초당 프레임 수(FPS)이며, 60 FPS 달성을 목표로 합니다 [3]. FPS 차트 위에 빨간색 막대가 나타나면 사용자 경험을 해칠 만큼 프레임 속도가 떨어졌음을 의미합니다 [3].
-  * CPU 차트가 여러 색상으로 꽉 차 있는 것은 녹화 시간 동안 CPU가 최대 용량으로 작업했음을 나타내며, 이는 성능 개선을 위해 수행하는 작업을 줄여야 한다는 신호입니다 [3].
-
-* **메인 스레드 플레임 차트(Flame Chart) 해석:**
-  * 메인(Main) 섹션은 메인 스레드에서 시간에 따라 발생한 활동을 플레임 차트 형태로 시각화합니다. x축은 시간을, y축은 호출 스택(Call stack)을 나타내며, 상단에 위치한 이벤트가 하단의 이벤트를 호출한 원인입니다 [4, 8].
-  * 50 밀리초(ms)를 초과하는 긴 작업(Long Task)에는 빨간색 삼각형 경고가 표시되며, 초과된 시간 부분은 빨간색으로 음영 처리되어 성능 저하를 일으키는 항목을 쉽게 파악할 수 있습니다 [4, 9].
-
-* **병목 현상(Bottleneck) 식별:**
-  * 하단의 요약(Summary) 탭은 선택된 구간의 활동 분류(렌더링, 스크립팅 등)를 보여주며, 가장 많은 시간을 소비한 작업 영역을 찾도록 돕습니다 [4, 10].
-  * 예를 들어, 애니메이션 프레임 이벤트 내부에서 요소의 스타일을 변경한 후 즉시 위치를 쿼리할 경우 브라우저가 강제로 레이아웃을 다시 계산해야 하는 '강제 동기식 레이아웃(Forced synchronous layouts)'과 같은 문제를 식별할 수 있습니다 [4].
-  * 특정 활동이나 이벤트를 클릭하면 연결된 소스 코드의 해당 줄로 직접 이동할 수 있어 디버깅에 유리합니다 [4, 11].
-
-* **상세 탭을 통한 활동 분석:**
-  * **Call tree 탭:** 가장 많은 작업을 유발한 루트 활동(root activities)을 확인할 수 있습니다 [12, 13].
-  * **Bottom-up 탭:** 직접적으로 가장 많은 시간이 소요된 특정 활동들을 집계하여 보여줍니다 [12, 14, 15].
-  * **Event log 탭:** 기록되는 동안 활동이 발생한 순서대로 정렬하여 분석할 수 있습니다 [12, 16].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 지식 자산화 및 기존 네트워크 연동 단계.
-- **정책 변화:** Web & Performance 카테고리의 전문성 확보 및 링크 밀도 최적화.
-
-## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[Chrome DevTools]], [[Frames Per Second (FPS)]], [[Forced Synchronous Layouts]], [[Long Task]], [[Interaction to Next Paint (INP)]]
-- **Projects/Contexts:** [[RAIL model]], [[Chrome User Experience Report (CrUX)]]
-- **Contradictions/Notes:** DevTools의 CPU 스로틀링 기능은 데스크톱의 CPU 속도를 늦추어 시뮬레이션하는 방식이므로, 데스크톱과 모바일 기기의 근본적인 아키텍처 차이 때문에 실제 모바일 기기의 CPU 동작을 완벽하게 모방할 수는 없습니다 [17].
-
----
-*Last updated: 2026-04-19*
-- Raw Source: [[00_Raw/2026-04-20/Analyze runtime performance.md]]
----
diff --git a/WebWorker_Performance.md b/WebWorker_Performance.md
deleted file mode 100644
index 0dae6511..00000000
--- a/WebWorker_Performance.md
+++ /dev/null
@@ -1,24 +0,0 @@
----
-title: WebWorker를 이용한 고성능 아키텍처 설계
-category: Web & Performance
-tags: [Web Worker, Concurrency, Performance, UI responsiveness]
-created: 2026-04-20
----
-
-# WebWorker를 이용한 고성능 아키텍처 설계
-
-## 🎯 개요 (Overview)
-실시간 상태 변화가 매우 빈번한 애플리케이션(예: 게임, 시뮬레이션)에서 UI 스레드와 복잡한 연산 로직을 분리하여 **프레임 드롭(Jank)**을 방지하는 아키텍처 설계 기법입니다.
-
-## 🚀 주요 원칙 (Key Principles)
-- **스레드 분리 (Thread Isolation)**: 무거운 계산은 백그라운드 스레드(Web Worker)에서 수행하고, 메인 스레드는 렌더링에만 집중합니다.
-- **메시징 기반 통신 (Messaging Architecture)**: `postMessage`와 `onmessage`를 통해 비동기적으로 데이터를 주고받아 결합도를 낮춥니다.
-
-## 💡 레슨 런 (Lesson Learned)
-> [!IMPORTANT]
-> **"성능 병목 현상은 종종 '스레딩(Threading)'의 문제이다."**
-> 복잡한 물리 계산이나 루프가 UI 응답성을 해치지 않도록, 연산 엔진을 완전히 별도의 스레드로 격리하는 것이 부드러운 UX의 핵심입니다.
-
-## 🔗 연결된 지식
-- [[Separation_of_Concerns]]
-- [[Systemic_Simulation_Principles]]
diff --git a/pending_topics_list.txt b/pending_topics_list.txt
deleted file mode 100644
index a5ab3d63..00000000
--- a/pending_topics_list.txt
+++ /dev/null
@@ -1,1128 +0,0 @@
-E:\Wiki\2nd\10_Wiki\Topics\AI\Best-of-N Sampling (최적 샘플링).md
-E:\Wiki\2nd\10_Wiki\Topics\AI\Caliskan-Islam 등의 프로그램 바이너리 작성자 식별 연구.md
-E:\Wiki\2nd\10_Wiki\Topics\AI\Chrome 브라우저 렌더링 성능.md
-E:\Wiki\2nd\10_Wiki\Topics\AI\Circular Economy Transitions.md
-E:\Wiki\2nd\10_Wiki\Topics\AI\CompCert-C-Compiler.md
-E:\Wiki\2nd\10_Wiki\Topics\AI\Complexity Theory.md
-E:\Wiki\2nd\10_Wiki\Topics\AI\Computational Creativity.md
-E:\Wiki\2nd\10_Wiki\Topics\AI\Computational Neuroscience of Reinforcement Learning.md
-E:\Wiki\2nd\10_Wiki\Topics\AI\Computational-Creativity.md
-E:\Wiki\2nd\10_Wiki\Topics\AI\Computer-Aided-Design (CAD).md
-E:\Wiki\2nd\10_Wiki\Topics\AI\Connect AI 기술 문서 및 사용 설명서.md
-E:\Wiki\2nd\10_Wiki\Topics\AI\Connect AI 시스템 아키텍처 및 데이터 흐름 분석.md
-E:\Wiki\2nd\10_Wiki\Topics\AI\Constraint-Satisfaction-Problems.md
-E:\Wiki\2nd\10_Wiki\Topics\AI\Continuous-Discovery.md
-E:\Wiki\2nd\10_Wiki\Topics\AI\Control Systems Engineering.md
-E:\Wiki\2nd\10_Wiki\Topics\AI\Conways On Numbers and Games.md
-E:\Wiki\2nd\10_Wiki\Topics\AI\Corporate-LMS-Training.md
-E:\Wiki\2nd\10_Wiki\Topics\AI\CPTED.md
-E:\Wiki\2nd\10_Wiki\Topics\AI\Custom-ESLint-Rules-Development.md
-E:\Wiki\2nd\10_Wiki\Topics\AI\Customer-Journey-Mapping.md
-E:\Wiki\2nd\10_Wiki\Topics\AI\Data-Augmentation-for-Medical-Imaging.md
-E:\Wiki\2nd\10_Wiki\Topics\AI\Data-Science-in-UX.md
-E:\Wiki\2nd\10_Wiki\Topics\AI\Dead Space (Series).md
-E:\Wiki\2nd\10_Wiki\Topics\AI\Declaration Files (dts).md
-E:\Wiki\2nd\10_Wiki\Topics\AI\Deep-Convolutional-GANs.md
-E:\Wiki\2nd\10_Wiki\Topics\AI\Deepfake-Detection-Research.md
-E:\Wiki\2nd\10_Wiki\Topics\AI\Directed-Acyclic-Graph-Dependency-Management.md
-E:\Wiki\2nd\10_Wiki\Topics\AI\Discriminated-Unions-for-Error-Handling.md
-E:\Wiki\2nd\10_Wiki\Topics\AI\Dissipative Structures.md
-E:\Wiki\2nd\10_Wiki\Topics\AI\Distributed-System-Type-Safety.md
-E:\Wiki\2nd\10_Wiki\Topics\AI\Domain-Driven Design (DDD) in TypeScript.md
-E:\Wiki\2nd\10_Wiki\Topics\AI\Domain-Driven Design (DDD) Type Safety.md
-E:\Wiki\2nd\10_Wiki\Topics\AI\Domain-Driven-Design (DDD) in TypeScript.md
-E:\Wiki\2nd\10_Wiki\Topics\AI\Domain-Driven-Design-(DDD)-in-TypeScript.md
-E:\Wiki\2nd\10_Wiki\Topics\AI\Domain-Driven-Design-(DDD).md
-E:\Wiki\2nd\10_Wiki\Topics\AI\Domain-Driven-Design-Bounded-Context.md
-E:\Wiki\2nd\10_Wiki\Topics\AI\Domain-Driven-Design-in-TypeScript.md
-E:\Wiki\2nd\10_Wiki\Topics\AI\Domain-Driven-Design-Interface-Modeling.md
-E:\Wiki\2nd\10_Wiki\Topics\AI\Domain-Driven-Design-with-TypeScript.md
-E:\Wiki\2nd\10_Wiki\Topics\AI\Dopaminergic Reward Systems.md
-E:\Wiki\2nd\10_Wiki\Topics\AI\Dynamic Few-Shot (동적 퓨샷 선택 전략).md
-E:\Wiki\2nd\10_Wiki\Topics\AI\Europeana.md
-E:\Wiki\2nd\10_Wiki\Topics\AI\EVE Online (Spreadsheet Economy).md
-E:\Wiki\2nd\10_Wiki\Topics\AI\Evolutionary-Biology.md
-E:\Wiki\2nd\10_Wiki\Topics\AI\Evolutionary-Computation.md
-E:\Wiki\2nd\10_Wiki\Topics\AI\Exercise-Physiology.md
-E:\Wiki\2nd\10_Wiki\Topics\AI\Expected Utility Theory.md
-E:\Wiki\2nd\10_Wiki\Topics\AI\e스포츠 인지 상태 및 성과 위험 평가.md
-E:\Wiki\2nd\10_Wiki\Topics\AI\Feature Clamping (피처 고정).md
-E:\Wiki\2nd\10_Wiki\Topics\AI\Feedback-Control-Systems.md
-E:\Wiki\2nd\10_Wiki\Topics\AI\Finite-Element-Analysis.md
-E:\Wiki\2nd\10_Wiki\Topics\AI\Firefox.md
-E:\Wiki\2nd\10_Wiki\Topics\AI\Fixed Time Step vs Variable Time Step.md
-E:\Wiki\2nd\10_Wiki\Topics\AI\Flow State.md
-E:\Wiki\2nd\10_Wiki\Topics\AI\Functional-Programming-in-TypeScript.md
-E:\Wiki\2nd\10_Wiki\Topics\AI\Gacha Mechanics Analysis.md
-E:\Wiki\2nd\10_Wiki\Topics\AI\Gait-Analysis-Laboratory.md
-E:\Wiki\2nd\10_Wiki\Topics\AI\Gait-Analysis-Methodologies.md
-E:\Wiki\2nd\10_Wiki\Topics\AI\Game Balance Theory.md
-E:\Wiki\2nd\10_Wiki\Topics\AI\Game Economy Modeling.md
-E:\Wiki\2nd\10_Wiki\Topics\AI\Game Engine Architecture (Jason Gregory).md
-E:\Wiki\2nd\10_Wiki\Topics\AI\Game Engine Architecture.md
-E:\Wiki\2nd\10_Wiki\Topics\AI\Game-Design-Ontology.md
-E:\Wiki\2nd\10_Wiki\Topics\AI\Game-Design-Theory.md
-E:\Wiki\2nd\10_Wiki\Topics\AI\Game-Ontology-for-PCG.md
-E:\Wiki\2nd\10_Wiki\Topics\AI\Gamification Theory.md
-E:\Wiki\2nd\10_Wiki\Topics\AI\Generics-and-Polymorphism.md
-E:\Wiki\2nd\10_Wiki\Topics\AI\Geographic-Information-Systems (GIS).md
-E:\Wiki\2nd\10_Wiki\Topics\AI\Geriatric-Medicine.md
-E:\Wiki\2nd\10_Wiki\Topics\AI\Goal Misgeneralization (목표 오일반화).md
-E:\Wiki\2nd\10_Wiki\Topics\AI\Graph-Coloring-Problem.md
-E:\Wiki\2nd\10_Wiki\Topics\AI\Graph-Theory.md
-E:\Wiki\2nd\10_Wiki\Topics\AI\GraphQL-Code-Generator.md
-E:\Wiki\2nd\10_Wiki\Topics\AI\Grit.md
-E:\Wiki\2nd\10_Wiki\Topics\AI\Growth Mindset Intervention in Education.md
-E:\Wiki\2nd\10_Wiki\Topics\AI\Growth-Mindset.md
-E:\Wiki\2nd\10_Wiki\Topics\AI\GRPO (Group Relative Policy Optimization).md
-E:\Wiki\2nd\10_Wiki\Topics\AI\Guilty-Gear-Xrd-Rendering-Pipeline.md
-E:\Wiki\2nd\10_Wiki\Topics\AI\HANDOVER.md
-E:\Wiki\2nd\10_Wiki\Topics\AI\Hardware-Verification.md
-E:\Wiki\2nd\10_Wiki\Topics\AI\HBO Prestige Television.md
-E:\Wiki\2nd\10_Wiki\Topics\AI\Health Informatics (mHealth).md
-E:\Wiki\2nd\10_Wiki\Topics\AI\Hebbian Theory.md
-E:\Wiki\2nd\10_Wiki\Topics\AI\HHH (Helpful Harmless Honest).md
-E:\Wiki\2nd\10_Wiki\Topics\AI\High-Cohesion-Low-Coupling.md
-E:\Wiki\2nd\10_Wiki\Topics\AI\High-Frequency Trading Models.md
-E:\Wiki\2nd\10_Wiki\Topics\AI\High-Performance Training Programs (Tier 1 Orgs).md
-E:\Wiki\2nd\10_Wiki\Topics\AI\High-Performance-Coaching.md
-E:\Wiki\2nd\10_Wiki\Topics\AI\High-Performance-Sports-Science.md
-E:\Wiki\2nd\10_Wiki\Topics\AI\Homeostasis.md
-E:\Wiki\2nd\10_Wiki\Topics\AI\Human-Computer-Interaction.md
-E:\Wiki\2nd\10_Wiki\Topics\AI\Hyperinflation in Closed-Loop Systems.md
-E:\Wiki\2nd\10_Wiki\Topics\AI\IEEE P36521.md
-E:\Wiki\2nd\10_Wiki\Topics\AI\Immersive Sim Design.md
-E:\Wiki\2nd\10_Wiki\Topics\AI\Immersive Sims (eg Deus Ex Dishonored).md
-E:\Wiki\2nd\10_Wiki\Topics\AI\Immersive Sims (eg Deus Ex Thief).md
-E:\Wiki\2nd\10_Wiki\Topics\AI\Immersive-Sim-Genre.md
-E:\Wiki\2nd\10_Wiki\Topics\AI\Immutability-Patterns.md
-E:\Wiki\2nd\10_Wiki\Topics\AI\In-Context Learning (ICL 문맥 내 학습).md
-E:\Wiki\2nd\10_Wiki\Topics\AI\Incremental-Computation.md
-E:\Wiki\2nd\10_Wiki\Topics\AI\Indoor Wayfinding for Smart Cities.md
-E:\Wiki\2nd\10_Wiki\Topics\AI\Industrial Metaverse.md
-E:\Wiki\2nd\10_Wiki\Topics\AI\Industrial-Automation.md
-E:\Wiki\2nd\10_Wiki\Topics\AI\Injury-Prevention-Protocols.md
-E:\Wiki\2nd\10_Wiki\Topics\AI\Interface Segregation Principle.md
-E:\Wiki\2nd\10_Wiki\Topics\AI\Interface-Segregation-Principle-in-TS.md
-E:\Wiki\2nd\10_Wiki\Topics\AI\Interpolation and Extrapolation.md
-E:\Wiki\2nd\10_Wiki\Topics\AI\InversifyJS.md
-E:\Wiki\2nd\10_Wiki\Topics\AI\Irrational Games.md
-E:\Wiki\2nd\10_Wiki\Topics\AI\Itô Calculus.md
-E:\Wiki\2nd\10_Wiki\Topics\AI\J-curve  S-curve (AI 발전의 동학).md
-E:\Wiki\2nd\10_Wiki\Topics\AI\Jailbreaking (탈옥).md
-E:\Wiki\2nd\10_Wiki\Topics\AI\Jenkins.md
-E:\Wiki\2nd\10_Wiki\Topics\AI\JSON-Schema.md
-E:\Wiki\2nd\10_Wiki\Topics\AI\Ken Levine-Design-Philosophy.md
-E:\Wiki\2nd\10_Wiki\Topics\AI\Keyof-Operator.md
-E:\Wiki\2nd\10_Wiki\Topics\AI\Kinematic-Modeling.md
-E:\Wiki\2nd\10_Wiki\Topics\AI\KTO (Kahneman-Tversky Optimization).md
-E:\Wiki\2nd\10_Wiki\Topics\AI\Language-Acquisition-Apps.md
-E:\Wiki\2nd\10_Wiki\Topics\AI\Large-Scale-Enterprise-Frontend-Architectures.md
-E:\Wiki\2nd\10_Wiki\Topics\AI\Large-scale-Frontend-Architecture.md
-E:\Wiki\2nd\10_Wiki\Topics\AI\Large-Scale-Knowledge-Integration.md
-E:\Wiki\2nd\10_Wiki\Topics\AI\Large-scale-TypeScript-Monorepos.md
-E:\Wiki\2nd\10_Wiki\Topics\AI\Lerna-Legacy-Management.md
-E:\Wiki\2nd\10_Wiki\Topics\AI\Level Design Architecture.md
-E:\Wiki\2nd\10_Wiki\Topics\AI\Level Design Automation.md
-E:\Wiki\2nd\10_Wiki\Topics\AI\Level-Design-Automation.md
-E:\Wiki\2nd\10_Wiki\Topics\AI\Linear Representation Hypothesis (선형 표현 가설).md
-E:\Wiki\2nd\10_Wiki\Topics\AI\Live Service Game Design.md
-E:\Wiki\2nd\10_Wiki\Topics\AI\LiveOps Management.md
-E:\Wiki\2nd\10_Wiki\Topics\AI\LLM Alignment (LLM 정렬).md
-E:\Wiki\2nd\10_Wiki\Topics\AI\LLM Hallucination (언어 모델 환각).md
-E:\Wiki\2nd\10_Wiki\Topics\AI\Locus of Control.md
-E:\Wiki\2nd\10_Wiki\Topics\AI\Locus-of-Control.md
-E:\Wiki\2nd\10_Wiki\Topics\AI\Ludology-vs-Narratology.md
-E:\Wiki\2nd\10_Wiki\Topics\AI\Machine Learning in Game Design.md
-E:\Wiki\2nd\10_Wiki\Topics\AI\Machine-Learning-Animation.md
-E:\Wiki\2nd\10_Wiki\Topics\AI\Market Regulation.md
-E:\Wiki\2nd\10_Wiki\Topics\AI\MDA-P-Framework.md
-E:\Wiki\2nd\10_Wiki\Topics\AI\Mesocortical Pathway.md
-E:\Wiki\2nd\10_Wiki\Topics\AI\Metabolic Efficiency.md
-E:\Wiki\2nd\10_Wiki\Topics\AI\Metabolic-Flexibility.md
-E:\Wiki\2nd\10_Wiki\Topics\AI\Metabolic-Resource-Allocation.md
-E:\Wiki\2nd\10_Wiki\Topics\AI\Metro Exodus.md
-E:\Wiki\2nd\10_Wiki\Topics\AI\Microservices-Architecture-Bounded-Contexts.md
-E:\Wiki\2nd\10_Wiki\Topics\AI\Microservices-Architecture-Type-Safety.md
-E:\Wiki\2nd\10_Wiki\Topics\AI\Microservices-Communication-Patterns.md
-E:\Wiki\2nd\10_Wiki\Topics\AI\MMORPG Economic Management.md
-E:\Wiki\2nd\10_Wiki\Topics\AI\Mobile-App-Development.md
-E:\Wiki\2nd\10_Wiki\Topics\AI\Model Collapse (모델 붕괴 현상).md
-E:\Wiki\2nd\10_Wiki\Topics\AI\Model Predictive Control (MPC).md
-E:\Wiki\2nd\10_Wiki\Topics\AI\Model Spec (모델 스펙 AI 행동 명세서).md
-E:\Wiki\2nd\10_Wiki\Topics\AI\Module Augmentation.md
-E:\Wiki\2nd\10_Wiki\Topics\AI\Module-Augmentation.md
-E:\Wiki\2nd\10_Wiki\Topics\AI\Module-Boundary-Enforcement.md
-E:\Wiki\2nd\10_Wiki\Topics\AI\Monetary Policy in Virtual Worlds.md
-E:\Wiki\2nd\10_Wiki\Topics\AI\Monetary Policy.md
-E:\Wiki\2nd\10_Wiki\Topics\AI\Monosemanticity (일의성).md
-E:\Wiki\2nd\10_Wiki\Topics\AI\Multi-Agent Debate (에이전트 간 토론 전략).md
-E:\Wiki\2nd\10_Wiki\Topics\AI\Multi-Agent System (다중 에이전트 시스템).md
-E:\Wiki\2nd\10_Wiki\Topics\AI\Multi-Hop Reasoning (다중 홉 추론).md
-E:\Wiki\2nd\10_Wiki\Topics\AI\Multimodal Sentiment Analysis.md
-E:\Wiki\2nd\10_Wiki\Topics\AI\Natural Language Processing (NLP) in Narrative.md
-E:\Wiki\2nd\10_Wiki\Topics\AI\Natural-Language-Processing.md
-E:\Wiki\2nd\10_Wiki\Topics\AI\Naughty Dog Development.md
-E:\Wiki\2nd\10_Wiki\Topics\AI\NestJS-Architecture.md
-E:\Wiki\2nd\10_Wiki\Topics\AI\Network Synchronization in Multiplayer Games.md
-E:\Wiki\2nd\10_Wiki\Topics\AI\Neural-Symbolic-Integration.md
-E:\Wiki\2nd\10_Wiki\Topics\AI\Neuro-Symbolic-AI.md
-E:\Wiki\2nd\10_Wiki\Topics\AI\Neurobiology-of-Reward.md
-E:\Wiki\2nd\10_Wiki\Topics\AI\Neurodevelopmental Disorders.md
-E:\Wiki\2nd\10_Wiki\Topics\AI\Neuroeconomics.md
-E:\Wiki\2nd\10_Wiki\Topics\AI\Neuroergonomics.md
-E:\Wiki\2nd\10_Wiki\Topics\AI\Neuromuscular-Adaptation.md
-E:\Wiki\2nd\10_Wiki\Topics\AI\Neuromuscular-Control.md
-E:\Wiki\2nd\10_Wiki\Topics\AI\Neuropharmacology of Substance Use Disorders.md
-E:\Wiki\2nd\10_Wiki\Topics\AI\Neuroplasticity in Addiction.md
-E:\Wiki\2nd\10_Wiki\Topics\AI\Neuroplasticity in Motor Learning.md
-E:\Wiki\2nd\10_Wiki\Topics\AI\Neuroplasticity-in-Motor-Learning.md
-E:\Wiki\2nd\10_Wiki\Topics\AI\Neuroprosthetics-Development.md
-E:\Wiki\2nd\10_Wiki\Topics\AI\Neuropsychiatric Disorders.md
-E:\Wiki\2nd\10_Wiki\Topics\AI\Neuropsychology.md
-E:\Wiki\2nd\10_Wiki\Topics\AI\Neurorehabilitation after Stroke.md
-E:\Wiki\2nd\10_Wiki\Topics\AI\Neurorehabilitation-Post-Stroke.md
-E:\Wiki\2nd\10_Wiki\Topics\AI\No Mans Sky (Large-scale planetary generation).md
-E:\Wiki\2nd\10_Wiki\Topics\AI\No Mans Sky.md
-E:\Wiki\2nd\10_Wiki\Topics\AI\Nodejs-Global-Namespace-Augmentation.md
-E:\Wiki\2nd\10_Wiki\Topics\AI\Nominal-Typing-in-TypeScript.md
-E:\Wiki\2nd\10_Wiki\Topics\AI\Non-Photorealistic-Rendering-in-Level-Design.md
-E:\Wiki\2nd\10_Wiki\Topics\AI\Nuclear Deterrence Models.md
-E:\Wiki\2nd\10_Wiki\Topics\AI\Nutritional-Biochemistry.md
-E:\Wiki\2nd\10_Wiki\Topics\AI\Object Pooling (가비지 컬렉션 최적화).md
-E:\Wiki\2nd\10_Wiki\Topics\AI\Object-Oriented-Design-Patterns.md
-E:\Wiki\2nd\10_Wiki\Topics\AI\Objectivism.md
-E:\Wiki\2nd\10_Wiki\Topics\AI\Occupational-Therapy.md
-E:\Wiki\2nd\10_Wiki\Topics\AI\Okami-Ink-Wash-Aesthetics.md
-E:\Wiki\2nd\10_Wiki\Topics\AI\Olympic-Training-Cycles.md
-E:\Wiki\2nd\10_Wiki\Topics\AI\Olympic-Training-Models.md
-E:\Wiki\2nd\10_Wiki\Topics\AI\Olympic-Training-Protocols.md
-E:\Wiki\2nd\10_Wiki\Topics\AI\Ontology-Engineering.md
-E:\Wiki\2nd\10_Wiki\Topics\AI\Ontology-Guided Knowledge Extraction.md
-E:\Wiki\2nd\10_Wiki\Topics\AI\Opaque-Types.md
-E:\Wiki\2nd\10_Wiki\Topics\AI\Open-Access-Movement.md
-E:\Wiki\2nd\10_Wiki\Topics\AI\Operations-Research.md
-E:\Wiki\2nd\10_Wiki\Topics\AI\Organizational Psychology.md
-E:\Wiki\2nd\10_Wiki\Topics\AI\Outer Alignment vs Inner Alignment.md
-E:\Wiki\2nd\10_Wiki\Topics\AI\OWA vs CWA (개방 세계 vs 폐쇄 세계 가정).md
-E:\Wiki\2nd\10_Wiki\Topics\AI\Papers Please (Bureaucratic Simulation).md
-E:\Wiki\2nd\10_Wiki\Topics\AI\Papers-Please.md
-E:\Wiki\2nd\10_Wiki\Topics\AI\PCGML-Frameworks.md
-E:\Wiki\2nd\10_Wiki\Topics\AI\Pedestrian-Modeling.md
-E:\Wiki\2nd\10_Wiki\Topics\AI\PEFT (Parameter-Efficient Fine-Tuning).md
-E:\Wiki\2nd\10_Wiki\Topics\AI\Perceptual-Motor-Skills.md
-E:\Wiki\2nd\10_Wiki\Topics\AI\Performance Management Systems.md
-E:\Wiki\2nd\10_Wiki\Topics\AI\Performance Psychology.md
-E:\Wiki\2nd\10_Wiki\Topics\AI\Periodization-Theory.md
-E:\Wiki\2nd\10_Wiki\Topics\AI\Personalization-Engines.md
-E:\Wiki\2nd\10_Wiki\Topics\AI\Persuasive Games.md
-E:\Wiki\2nd\10_Wiki\Topics\AI\Phase Transition (위상 변이).md
-E:\Wiki\2nd\10_Wiki\Topics\AI\Phyllotaxis-Modeling.md
-E:\Wiki\2nd\10_Wiki\Topics\AI\Physics-Based-Simulation.md
-E:\Wiki\2nd\10_Wiki\Topics\AI\Platform Economics.md
-E:\Wiki\2nd\10_Wiki\Topics\AI\Play-to-Earn (P2E) Economies.md
-E:\Wiki\2nd\10_Wiki\Topics\AI\Player-Agency.md
-E:\Wiki\2nd\10_Wiki\Topics\AI\Positive-Education.md
-E:\Wiki\2nd\10_Wiki\Topics\AI\Post-structuralism.md
-E:\Wiki\2nd\10_Wiki\Topics\AI\Precision Medicine Training.md
-E:\Wiki\2nd\10_Wiki\Topics\AI\Predictive Maintenance (PdM).md
-E:\Wiki\2nd\10_Wiki\Topics\AI\Predictive-Modeling.md
-E:\Wiki\2nd\10_Wiki\Topics\AI\Predictive-Urban-Modeling.md
-E:\Wiki\2nd\10_Wiki\Topics\AI\Prefrontal Cortex Dysfunction.md
-E:\Wiki\2nd\10_Wiki\Topics\AI\Prefrontal-Cortex-Dysfunction.md
-E:\Wiki\2nd\10_Wiki\Topics\AI\PRM (Process Reward Model).md
-E:\Wiki\2nd\10_Wiki\Topics\AI\Probability Theory (Stochastic Processes).md
-E:\Wiki\2nd\10_Wiki\Topics\AI\Probability Theory.md
-E:\Wiki\2nd\10_Wiki\Topics\AI\Procedural Content Generation (PCG) Balancing.md
-E:\Wiki\2nd\10_Wiki\Topics\AI\Procedural Content Generation (PCG).md
-E:\Wiki\2nd\10_Wiki\Topics\AI\Procedural Content Generation via Machine Learning (PCGML).md
-E:\Wiki\2nd\10_Wiki\Topics\AI\Procedural Content Generation.md
-E:\Wiki\2nd\10_Wiki\Topics\AI\Procedural Rhetoric.md
-E:\Wiki\2nd\10_Wiki\Topics\AI\Procedural-Content-Generation (PCG).md
-E:\Wiki\2nd\10_Wiki\Topics\AI\Procedural-Content-Generation-via-Machine-Learning.md
-E:\Wiki\2nd\10_Wiki\Topics\AI\Procedural-Content-Generation.md
-E:\Wiki\2nd\10_Wiki\Topics\AI\Procedural-Texture-Generation.md
-E:\Wiki\2nd\10_Wiki\Topics\AI\Process Supervision (과정 감독).md
-E:\Wiki\2nd\10_Wiki\Topics\AI\Product-Types.md
-E:\Wiki\2nd\10_Wiki\Topics\AI\Prompt Injection (프롬프트 주입 공격).md
-E:\Wiki\2nd\10_Wiki\Topics\AI\Prospect Theory.md
-E:\Wiki\2nd\10_Wiki\Topics\AI\Prosthetic-Design-Optimization.md
-E:\Wiki\2nd\10_Wiki\Topics\AI\Psychophysiology.md
-E:\Wiki\2nd\10_Wiki\Topics\AI\Quantitative-Usability-Testing.md
-E:\Wiki\2nd\10_Wiki\Topics\AI\RAG (검색 증강 생성).md
-E:\Wiki\2nd\10_Wiki\Topics\AI\ReAct (Reasoning  Acting).md
-E:\Wiki\2nd\10_Wiki\Topics\AI\Real-Time-Game-Engines.md
-E:\Wiki\2nd\10_Wiki\Topics\AI\Redux-Reducers-Design.md
-E:\Wiki\2nd\10_Wiki\Topics\AI\Redux-State-Management.md
-E:\Wiki\2nd\10_Wiki\Topics\AI\Regenerative Design.md
-E:\Wiki\2nd\10_Wiki\Topics\AI\Regenerative-Design.md
-E:\Wiki\2nd\10_Wiki\Topics\AI\Rehabilitative-Medicine.md
-E:\Wiki\2nd\10_Wiki\Topics\AI\Reinforcement Learning (RL).md
-E:\Wiki\2nd\10_Wiki\Topics\AI\Reinforcement Learning for Automated Playtesting.md
-E:\Wiki\2nd\10_Wiki\Topics\AI\Reinforcement Learning in Economics.md
-E:\Wiki\2nd\10_Wiki\Topics\AI\Reinforcement Learning.md
-E:\Wiki\2nd\10_Wiki\Topics\AI\Reinforcement Schedules.md
-E:\Wiki\2nd\10_Wiki\Topics\AI\Resilience Science.md
-E:\Wiki\2nd\10_Wiki\Topics\AI\Resilience-Engineering.md
-E:\Wiki\2nd\10_Wiki\Topics\AI\Retrograde-Games.md
-E:\Wiki\2nd\10_Wiki\Topics\AI\Reward Prediction Error.md
-E:\Wiki\2nd\10_Wiki\Topics\AI\Risk Management in Finance.md
-E:\Wiki\2nd\10_Wiki\Topics\AI\RLHF (인간 피드백 기반 강화학습).md
-E:\Wiki\2nd\10_Wiki\Topics\AI\Robotic Manipulation Control.md
-E:\Wiki\2nd\10_Wiki\Topics\AI\Robotic-Prosthetics-Control-Systems.md
-E:\Wiki\2nd\10_Wiki\Topics\AI\Robustness (강건성).md
-E:\Wiki\2nd\10_Wiki\Topics\AI\Scaffolding (Instructional Technique).md
-E:\Wiki\2nd\10_Wiki\Topics\AI\Scheduling-and-Timetabling.md
-E:\Wiki\2nd\10_Wiki\Topics\AI\Section-508-Compliance.md
-E:\Wiki\2nd\10_Wiki\Topics\AI\Self-Consistency (자기 일관성 디코딩).md
-E:\Wiki\2nd\10_Wiki\Topics\AI\Self-Organized Criticality.md
-E:\Wiki\2nd\10_Wiki\Topics\AI\Self-Regulation.md
-E:\Wiki\2nd\10_Wiki\Topics\AI\Semantic Grounding  Provenance.md
-E:\Wiki\2nd\10_Wiki\Topics\AI\Serious Games.md
-E:\Wiki\2nd\10_Wiki\Topics\AI\Service-Design-Blueprinting.md
-E:\Wiki\2nd\10_Wiki\Topics\AI\SFT (Supervised Fine-Tuning).md
-E:\Wiki\2nd\10_Wiki\Topics\AI\SHACL (Shapes Constraint Language).md
-E:\Wiki\2nd\10_Wiki\Topics\AI\Shannon-Entropy.md
-E:\Wiki\2nd\10_Wiki\Topics\AI\SimCity (as a model of systemic interaction).md
-E:\Wiki\2nd\10_Wiki\Topics\AI\Simulated History.md
-E:\Wiki\2nd\10_Wiki\Topics\AI\Single-Source-of-Truth.md
-E:\Wiki\2nd\10_Wiki\Topics\AI\Singularity (기술적 특이점).md
-E:\Wiki\2nd\10_Wiki\Topics\AI\Skybound Protocol 구조 및 의존성 분석 (Dependency Mapping).md
-E:\Wiki\2nd\10_Wiki\Topics\AI\Skybound Protocol 데이터 및 제어 흐름 (Control Flow).md
-E:\Wiki\2nd\10_Wiki\Topics\AI\Social Constructivism.md
-E:\Wiki\2nd\10_Wiki\Topics\AI\Social Systems Theory.md
-E:\Wiki\2nd\10_Wiki\Topics\AI\Sparse Autoencoder (SAE).md
-E:\Wiki\2nd\10_Wiki\Topics\AI\Spatial UI.md
-E:\Wiki\2nd\10_Wiki\Topics\AI\Specification Gaming (명세 우회).md
-E:\Wiki\2nd\10_Wiki\Topics\AI\Sports Neuroscience.md
-E:\Wiki\2nd\10_Wiki\Topics\AI\Sports-Medicine-Rehabilitation.md
-E:\Wiki\2nd\10_Wiki\Topics\AI\Sports-Performance-Optimization.md
-E:\Wiki\2nd\10_Wiki\Topics\AI\Sports-Psychology.md
-E:\Wiki\2nd\10_Wiki\Topics\AI\Sports-Science-Training.md
-E:\Wiki\2nd\10_Wiki\Topics\AI\Sprague-Grundy Theorem.md
-E:\Wiki\2nd\10_Wiki\Topics\AI\Static-Analysis-in-JavaScript-Ecosystem.md
-E:\Wiki\2nd\10_Wiki\Topics\AI\Static-Analysis-in-JavaScript.md
-E:\Wiki\2nd\10_Wiki\Topics\AI\Static-Analysis-in-Software-Engineering.md
-E:\Wiki\2nd\10_Wiki\Topics\AI\Static-Analysis-of-Interfaces.md
-E:\Wiki\2nd\10_Wiki\Topics\AI\STEM Laboratory Virtualization.md
-E:\Wiki\2nd\10_Wiki\Topics\AI\Stochastic Processes.md
-E:\Wiki\2nd\10_Wiki\Topics\AI\Stochastic-Games.md
-E:\Wiki\2nd\10_Wiki\Topics\AI\Sum-Types.md
-E:\Wiki\2nd\10_Wiki\Topics\AI\Superposition (중첩).md
-E:\Wiki\2nd\10_Wiki\Topics\AI\Supply-Chain-Management.md
-E:\Wiki\2nd\10_Wiki\Topics\AI\Surreal Numbers.md
-E:\Wiki\2nd\10_Wiki\Topics\AI\Survival Horror Genre.md
-E:\Wiki\2nd\10_Wiki\Topics\AI\Sustainable Development Goals (SDGs).md
-E:\Wiki\2nd\10_Wiki\Topics\AI\Sustainable-Development-Goals (SDGs).md
-E:\Wiki\2nd\10_Wiki\Topics\AI\Sycophancy (LLM 아첨 문제).md
-E:\Wiki\2nd\10_Wiki\Topics\AI\Symbolic-Logic.md
-E:\Wiki\2nd\10_Wiki\Topics\AI\Synaptic Plasticity.md
-E:\Wiki\2nd\10_Wiki\Topics\AI\Synthetic Data (합성 데이터).md
-E:\Wiki\2nd\10_Wiki\Topics\AI\SynthID (구글 AI 식별 기술).md
-E:\Wiki\2nd\10_Wiki\Topics\AI\Systemic-Cohesion.md
-E:\Wiki\2nd\10_Wiki\Topics\AI\Systems Thinking in Management.md
-E:\Wiki\2nd\10_Wiki\Topics\AI\Systems Thinking.md
-E:\Wiki\2nd\10_Wiki\Topics\AI\Taxonomy-and-Ontology.md
-E:\Wiki\2nd\10_Wiki\Topics\AI\Temporal Difference Learning.md
-E:\Wiki\2nd\10_Wiki\Topics\AI\Texture-Synthesis.md
-E:\Wiki\2nd\10_Wiki\Topics\AI\The Immersive Sim Taxonomy Debate.md
-E:\Wiki\2nd\10_Wiki\Topics\AI\The Last of Us Series.md
-E:\Wiki\2nd\10_Wiki\Topics\AI\The Overwatch League Case Study.md
-E:\Wiki\2nd\10_Wiki\Topics\AI\The Science of Well-Being (Yale).md
-E:\Wiki\2nd\10_Wiki\Topics\AI\The-Collapse-of-Utopian-Ideologies.md
-E:\Wiki\2nd\10_Wiki\Topics\AI\Themework-Integration.md
-E:\Wiki\2nd\10_Wiki\Topics\AI\Time Series Analysis.md
-E:\Wiki\2nd\10_Wiki\Topics\AI\Tokenomics.md
-E:\Wiki\2nd\10_Wiki\Topics\AI\Topology-of-Strategy-Spaces.md
-E:\Wiki\2nd\10_Wiki\Topics\AI\Trajectory-Planning.md
-E:\Wiki\2nd\10_Wiki\Topics\AI\Transhumanism.md
-E:\Wiki\2nd\10_Wiki\Topics\AI\Transient Hypofrontality.md
-E:\Wiki\2nd\10_Wiki\Topics\AI\Transient-Hypofrontality.md
-E:\Wiki\2nd\10_Wiki\Topics\AI\Transit-Oriented-Development (TOD).md
-E:\Wiki\2nd\10_Wiki\Topics\AI\Tree-of-Thought (ToT 사고 트리).md
-E:\Wiki\2nd\10_Wiki\Topics\AI\Type Definition Files (DefinitelyTyped).md
-E:\Wiki\2nd\10_Wiki\Topics\AI\Type-Composition-via-Intersection-Types.md
-E:\Wiki\2nd\10_Wiki\Topics\AI\Type-Guards.md
-E:\Wiki\2nd\10_Wiki\Topics\AI\Type-Inference.md
-E:\Wiki\2nd\10_Wiki\Topics\AI\Type-Intersection.md
-E:\Wiki\2nd\10_Wiki\Topics\AI\Type-Safety-in-Distributed-Systems.md
-E:\Wiki\2nd\10_Wiki\Topics\AI\Type-Safety-in-Domain-Driven-Design.md
-E:\Wiki\2nd\10_Wiki\Topics\AI\Type-Safety-in-Generics.md
-E:\Wiki\2nd\10_Wiki\Topics\AI\Type-Soundness.md
-E:\Wiki\2nd\10_Wiki\Topics\AI\Type-Theory.md
-E:\Wiki\2nd\10_Wiki\Topics\AI\Type-Unification.md
-E:\Wiki\2nd\10_Wiki\Topics\AI\TypeScript Compiler (tsc).md
-E:\Wiki\2nd\10_Wiki\Topics\AI\TypeScript Declaration Files (dts) Design.md
-E:\Wiki\2nd\10_Wiki\Topics\AI\TypeScript Interface Design.md
-E:\Wiki\2nd\10_Wiki\Topics\AI\TypeScript Type System Design.md
-E:\Wiki\2nd\10_Wiki\Topics\AI\TypeScript-Advanced-Type-System-Design.md
-E:\Wiki\2nd\10_Wiki\Topics\AI\TypeScript-Compiler-API-Integration.md
-E:\Wiki\2nd\10_Wiki\Topics\AI\TypeScript-Domain-Driven-Design.md
-E:\Wiki\2nd\10_Wiki\Topics\AI\TypeScript-Interface-Design.md
-E:\Wiki\2nd\10_Wiki\Topics\AI\TypeScript-Type-System-Architecture.md
-E:\Wiki\2nd\10_Wiki\Topics\AI\TypeScript-Type-System-Design.md
-E:\Wiki\2nd\10_Wiki\Topics\AI\TypeScript-Type-System-Interface-Design.md
-E:\Wiki\2nd\10_Wiki\Topics\AI\TypeScript-Type-System.md
-E:\Wiki\2nd\10_Wiki\Topics\AI\Ubiquitous Computing Paradigm.md
-E:\Wiki\2nd\10_Wiki\Topics\AI\Ubiquitous Computing.md
-E:\Wiki\2nd\10_Wiki\Topics\AI\Ubiquitous-Computing.md
-E:\Wiki\2nd\10_Wiki\Topics\AI\Ubiquitous-Language-Encoding.md
-E:\Wiki\2nd\10_Wiki\Topics\AI\Union-Types-vs-Overloading.md
-E:\Wiki\2nd\10_Wiki\Topics\AI\Universal-Design-Principles.md
-E:\Wiki\2nd\10_Wiki\Topics\AI\Urban Resilience Strategies.md
-E:\Wiki\2nd\10_Wiki\Topics\AI\Urban-Planning.md
-E:\Wiki\2nd\10_Wiki\Topics\AI\Utility Theory.md
-E:\Wiki\2nd\10_Wiki\Topics\AI\UX-Design-and-Engagement.md
-E:\Wiki\2nd\10_Wiki\Topics\AI\UX-Research-Methodologies.md
-E:\Wiki\2nd\10_Wiki\Topics\AI\Value Object Pattern.md
-E:\Wiki\2nd\10_Wiki\Topics\AI\Value-Objects.md
-E:\Wiki\2nd\10_Wiki\Topics\AI\Variational-Autoencoders.md
-E:\Wiki\2nd\10_Wiki\Topics\AI\VIA Institute on Character.md
-E:\Wiki\2nd\10_Wiki\Topics\AI\Visual Positioning Systems (VPS).md
-E:\Wiki\2nd\10_Wiki\Topics\AI\WAI-ARIA-Accessible-Rich-Internet-Applications.md
-E:\Wiki\2nd\10_Wiki\Topics\AI\Wang-Tiles.md
-E:\Wiki\2nd\10_Wiki\Topics\AI\Watermarking (AI 워터마킹).md
-E:\Wiki\2nd\10_Wiki\Topics\AI\Wavefunction-Collapse-Algorithm.md
-E:\Wiki\2nd\10_Wiki\Topics\AI\Web-Content-Accessibility-Guidelines-WCAG.md
-E:\Wiki\2nd\10_Wiki\Topics\AI\Wellbeing-Science.md
-E:\Wiki\2nd\10_Wiki\Topics\AI\Width-Subtyping.md
-E:\Wiki\2nd\10_Wiki\Topics\AI\Wikidata.md
-E:\Wiki\2nd\10_Wiki\Topics\AI\Work-Engagement-Models.md
-E:\Wiki\2nd\10_Wiki\Topics\AI\World of Warcraft (Gold Sink Mechanics).md
-E:\Wiki\2nd\10_Wiki\Topics\AI\_뇌와 팔다리의 분리_ - 관심사의 분리 (Separation of Concerns).md
-E:\Wiki\2nd\10_Wiki\Topics\AI\가상화 (Virtualization).md
-E:\Wiki\2nd\10_Wiki\Topics\AI\강화학습 (Reinforcement Learning).md
-E:\Wiki\2nd\10_Wiki\Topics\AI\대규모 React 프론트엔드 최적화.md
-E:\Wiki\2nd\10_Wiki\Topics\AI\도파민 보상 체계 (Dopaminergic Reward System).md
-E:\Wiki\2nd\10_Wiki\Topics\AI\디자인 시스템 (Design Systems).md
-E:\Wiki\2nd\10_Wiki\Topics\AI\양자화 (Quantization).md
-E:\Wiki\2nd\10_Wiki\Topics\AI\에듀테크 기반 게이미피케이션 전략.md
-E:\Wiki\2nd\10_Wiki\Topics\AI\연합 학습 (Associative Learning).md
-E:\Wiki\2nd\10_Wiki\Topics\AI\온톨로지 (Ontology).md
-E:\Wiki\2nd\10_Wiki\Topics\AI\온톨로지 지식 베이스.md
-E:\Wiki\2nd\10_Wiki\Topics\AI\인간-컴퓨터 상호작용 (HCI).md
-E:\Wiki\2nd\10_Wiki\Topics\AI\인공지능 상호작용 (HAI).md
-E:\Wiki\2nd\10_Wiki\Topics\AI\인적 자원 관리(HRM) 전략 수립.md
-E:\Wiki\2nd\10_Wiki\Topics\AI\인지행동치료(CBT).md
-E:\Wiki\2nd\10_Wiki\Topics\AI\인터랙티브 스토리텔링 연구.md
-E:\Wiki\2nd\10_Wiki\Topics\AI\지식 베이스 (Knowledge Base).md
-E:\Wiki\2nd\10_Wiki\Topics\AI\직렬화(Serialization) 및 병목 현상.md
-E:\Wiki\2nd\10_Wiki\Topics\AI\창발 능력 (Emergent Abilities).md
-E:\Wiki\2nd\10_Wiki\Topics\AI\힙 스냅샷(Heap Snapshot).md
-E:\Wiki\2nd\10_Wiki\Topics\Design & Experience\Arkane-Studios.md
-E:\Wiki\2nd\10_Wiki\Topics\Design & Experience\Assignability-Rules.md
-E:\Wiki\2nd\10_Wiki\Topics\Design & Experience\Assistive-Technology-Interoperability.md
-E:\Wiki\2nd\10_Wiki\Topics\Design & Experience\AST-Manipulation-Techniques.md
-E:\Wiki\2nd\10_Wiki\Topics\Design & Experience\Auction-Theory.md
-E:\Wiki\2nd\10_Wiki\Topics\Design & Experience\Automated-Client-Generation.md
-E:\Wiki\2nd\10_Wiki\Topics\Design & Experience\Bay 12 Games.md
-E:\Wiki\2nd\10_Wiki\Topics\Design & Experience\Bazel.md
-E:\Wiki\2nd\10_Wiki\Topics\Design & Experience\BioShock (Rapture)] [Dark Souls (Environmental Lore)] [Gone Home (Domestic Narrative Architecture).md
-E:\Wiki\2nd\10_Wiki\Topics\Design & Experience\Borderlands-Art-Direction.md
-E:\Wiki\2nd\10_Wiki\Topics\Design & Experience\Boundary-Layer-Validation.md
-E:\Wiki\2nd\10_Wiki\Topics\Design & Experience\Branded Types in TypeScript.md
-E:\Wiki\2nd\10_Wiki\Topics\Design & Experience\Buck2.md
-E:\Wiki\2nd\10_Wiki\Topics\Design & Experience\Causal Loop Diagramming.md
-E:\Wiki\2nd\10_Wiki\Topics\Design & Experience\Choice Architecture in Digital UX.md
-E:\Wiki\2nd\10_Wiki\Topics\Design & Experience\Chrome User Experience Report (CrUX).md
-E:\Wiki\2nd\10_Wiki\Topics\Design & Experience\Cognitive Aging Research.md
-E:\Wiki\2nd\10_Wiki\Topics\Design & Experience\Cognitive Dissonance.md
-E:\Wiki\2nd\10_Wiki\Topics\Design & Experience\Cognitive-Flexibility.md
-E:\Wiki\2nd\10_Wiki\Topics\Design & Experience\Cognitive-Psychology.md
-E:\Wiki\2nd\10_Wiki\Topics\Design & Experience\Complexity Science in Economics.md
-E:\Wiki\2nd\10_Wiki\Topics\Design & Experience\Computation-Caching-Strategies.md
-E:\Wiki\2nd\10_Wiki\Topics\Design & Experience\Computational Thinking.md
-E:\Wiki\2nd\10_Wiki\Topics\Design & Experience\Computational-Fluid-Dynamics.md
-E:\Wiki\2nd\10_Wiki\Topics\Design & Experience\Conditional-Types.md
-E:\Wiki\2nd\10_Wiki\Topics\Design & Experience\Content-Strategy.md
-E:\Wiki\2nd\10_Wiki\Topics\Design & Experience\Contract-Driven-Development.md
-E:\Wiki\2nd\10_Wiki\Topics\Design & Experience\Contract-First-Development.md
-E:\Wiki\2nd\10_Wiki\Topics\Design & Experience\Contract-Testing.md
-E:\Wiki\2nd\10_Wiki\Topics\Design & Experience\Contravariance-and-Covariance.md
-E:\Wiki\2nd\10_Wiki\Topics\Design & Experience\Creativity-and-Cognitive-Complexity.md
-E:\Wiki\2nd\10_Wiki\Topics\Design & Experience\Critical Design.md
-E:\Wiki\2nd\10_Wiki\Topics\Design & Experience\Cryptoeconomics.md
-E:\Wiki\2nd\10_Wiki\Topics\Design & Experience\Dark Souls (Environmental Storytelling).md
-E:\Wiki\2nd\10_Wiki\Topics\Design & Experience\Data-Sanitization.md
-E:\Wiki\2nd\10_Wiki\Topics\Design & Experience\Declaration Merging.md
-E:\Wiki\2nd\10_Wiki\Topics\Design & Experience\Declaration-Merging.md
-E:\Wiki\2nd\10_Wiki\Topics\Design & Experience\Depth-Subtyping.md
-E:\Wiki\2nd\10_Wiki\Topics\Design & Experience\Design-Thinking.md
-E:\Wiki\2nd\10_Wiki\Topics\Design & Experience\Design-Tokens.md
-E:\Wiki\2nd\10_Wiki\Topics\Design & Experience\Diegetic UI.md
-E:\Wiki\2nd\10_Wiki\Topics\Design & Experience\Diegetic-Interface.md
-E:\Wiki\2nd\10_Wiki\Topics\Design & Experience\Digital Humanities.md
-E:\Wiki\2nd\10_Wiki\Topics\Design & Experience\Digital Twin Interfaces.md
-E:\Wiki\2nd\10_Wiki\Topics\Design & Experience\Digital-Heritage-Preservation.md
-E:\Wiki\2nd\10_Wiki\Topics\Design & Experience\Digital-Humanities.md
-E:\Wiki\2nd\10_Wiki\Topics\Design & Experience\Digital-Transformation-Strategy.md
-E:\Wiki\2nd\10_Wiki\Topics\Design & Experience\Divergent-Thinking.md
-E:\Wiki\2nd\10_Wiki\Topics\Design & Experience\Duck-Typing.md
-E:\Wiki\2nd\10_Wiki\Topics\Design & Experience\Dwarf Fortress.md
-E:\Wiki\2nd\10_Wiki\Topics\Design & Experience\E-commerce-Conversion-Optimization.md
-E:\Wiki\2nd\10_Wiki\Topics\Design & Experience\Edge-Detection-Algorithms.md
-E:\Wiki\2nd\10_Wiki\Topics\Design & Experience\Educational Pedagogy (Zone of Proximal Development).md
-E:\Wiki\2nd\10_Wiki\Topics\Design & Experience\Educational-Psychology.md
-E:\Wiki\2nd\10_Wiki\Topics\Design & Experience\Electromyography.md
-E:\Wiki\2nd\10_Wiki\Topics\Design & Experience\Environmental Storyability.md
-E:\Wiki\2nd\10_Wiki\Topics\Design & Experience\Environmental Storytelling.md
-E:\Wiki\2nd\10_Wiki\Topics\Design & Experience\Environmental-Storytelling.md
-E:\Wiki\2nd\10_Wiki\Topics\Design & Experience\Ergodic Literature.md
-E:\Wiki\2nd\10_Wiki\Topics\Design & Experience\Ergodic-Literature.md
-E:\Wiki\2nd\10_Wiki\Topics\Design & Experience\ESL Pro Tour.md
-E:\Wiki\2nd\10_Wiki\Topics\Design & Experience\ESLint-Plugin-TypeScript.md
-E:\Wiki\2nd\10_Wiki\Topics\Design & Experience\eSports Performance Psychology.md
-E:\Wiki\2nd\10_Wiki\Topics\Design & Experience\Executive Function.md
-E:\Wiki\2nd\10_Wiki\Topics\Design & Experience\Exhaustiveness-Checking-with-Never.md
-E:\Wiki\2nd\10_Wiki\Topics\Design & Experience\Fallout (Pip-Boy Mechanic).md
-E:\Wiki\2nd\10_Wiki\Topics\Design & Experience\Flow-Sensitive-Typing.md
-E:\Wiki\2nd\10_Wiki\Topics\Design & Experience\Formalism vs Structuralism.md
-E:\Wiki\2nd\10_Wiki\Topics\Design & Experience\Formalist Criticism.md
-E:\Wiki\2nd\10_Wiki\Topics\Design & Experience\Game Studies (Game Studies Journal).md
-E:\Wiki\2nd\10_Wiki\Topics\Design & Experience\Game Systems Design.md
-E:\Wiki\2nd\10_Wiki\Topics\Design & Experience\Game-Level-Design.md
-E:\Wiki\2nd\10_Wiki\Topics\Design & Experience\Game-Studies-Academic-Discourse.md
-E:\Wiki\2nd\10_Wiki\Topics\Design & Experience\Game-Studies-Journal.md
-E:\Wiki\2nd\10_Wiki\Topics\Design & Experience\Gamification in Pedagogy.md
-E:\Wiki\2nd\10_Wiki\Topics\Design & Experience\Gamification-Mechanics.md
-E:\Wiki\2nd\10_Wiki\Topics\Design & Experience\Global Augmentation.md
-E:\Wiki\2nd\10_Wiki\Topics\Design & Experience\Grammar-based-Synthesis.md
-E:\Wiki\2nd\10_Wiki\Topics\Design & Experience\Haptic Feedback Technology.md
-E:\Wiki\2nd\10_Wiki\Topics\Design & Experience\Hierarchical Reinforcement Learning (HRL).md
-E:\Wiki\2nd\10_Wiki\Topics\Design & Experience\High-Performance-Human-Factors.md
-E:\Wiki\2nd\10_Wiki\Topics\Design & Experience\HUD-less Design Paradigms.md
-E:\Wiki\2nd\10_Wiki\Topics\Design & Experience\Human-Computer Interaction (HCI).md
-E:\Wiki\2nd\10_Wiki\Topics\Design & Experience\Human-Computer-Interaction (HCI).md
-E:\Wiki\2nd\10_Wiki\Topics\Design & Experience\Human-Machine Interface (HMI) Design.md
-E:\Wiki\2nd\10_Wiki\Topics\Design & Experience\Human-Robot Interaction (HRI).md
-E:\Wiki\2nd\10_Wiki\Topics\Design & Experience\Human-Robot-Interaction.md
-E:\Wiki\2nd\10_Wiki\Topics\Design & Experience\Hypertextuality.md
-E:\Wiki\2nd\10_Wiki\Topics\Design & Experience\Immersive Analytics.md
-E:\Wiki\2nd\10_Wiki\Topics\Design & Experience\Incremental-Compilation.md
-E:\Wiki\2nd\10_Wiki\Topics\Design & Experience\Information-Architecture.md
-E:\Wiki\2nd\10_Wiki\Topics\Design & Experience\Inquiry-Based Learning.md
-E:\Wiki\2nd\10_Wiki\Topics\Design & Experience\Interface-Extension-vs-Augmentation.md
-E:\Wiki\2nd\10_Wiki\Topics\Design & Experience\Interface-Extension.md
-E:\Wiki\2nd\10_Wiki\Topics\Design & Experience\Interface-Merging.md
-E:\Wiki\2nd\10_Wiki\Topics\Design & Experience\Interface-Segregation-Principle-in-TypeScript.md
-E:\Wiki\2nd\10_Wiki\Topics\Design & Experience\Interface-Segregation-Principle.md
-E:\Wiki\2nd\10_Wiki\Topics\Design & Experience\Interoperability Standards.md
-E:\Wiki\2nd\10_Wiki\Topics\Design & Experience\Intersection-Types-vs-Interface-Extension.md
-E:\Wiki\2nd\10_Wiki\Topics\Design & Experience\Inverse-Kinematics.md
-E:\Wiki\2nd\10_Wiki\Topics\Design & Experience\ISO 9241 표준.md
-E:\Wiki\2nd\10_Wiki\Topics\Design & Experience\JSON-Schema-Validation.md
-E:\Wiki\2nd\10_Wiki\Topics\Design & Experience\K-12-EdTech.md
-E:\Wiki\2nd\10_Wiki\Topics\Design & Experience\Kinetics.md
-E:\Wiki\2nd\10_Wiki\Topics\Design & Experience\Knowledge-Graph-Construction.md
-E:\Wiki\2nd\10_Wiki\Topics\Design & Experience\LCS (League of Legends Championship Series).md
-E:\Wiki\2nd\10_Wiki\Topics\Design & Experience\Lean-UX.md
-E:\Wiki\2nd\10_Wiki\Topics\Design & Experience\Level Design Theory.md
-E:\Wiki\2nd\10_Wiki\Topics\Design & Experience\Level-Design-Theory.md
-E:\Wiki\2nd\10_Wiki\Topics\Design & Experience\Linguistics.md
-E:\Wiki\2nd\10_Wiki\Topics\Design & Experience\Linked-Data-Principles.md
-E:\Wiki\2nd\10_Wiki\Topics\Design & Experience\Liskov-Substitution-Principle.md
-E:\Wiki\2nd\10_Wiki\Topics\Design & Experience\Ludo-narrative Dissonance.md
-E:\Wiki\2nd\10_Wiki\Topics\Design & Experience\Ludo-Narrative-Dissonance.md
-E:\Wiki\2nd\10_Wiki\Topics\Design & Experience\Ludonarrative-Dissonance.md
-E:\Wiki\2nd\10_Wiki\Topics\Design & Experience\Mapped-Types.md
-E:\Wiki\2nd\10_Wiki\Topics\Design & Experience\Material Design System.md
-E:\Wiki\2nd\10_Wiki\Topics\Design & Experience\Material Design.md
-E:\Wiki\2nd\10_Wiki\Topics\Design & Experience\Material-Design.md
-E:\Wiki\2nd\10_Wiki\Topics\Design & Experience\Mechanism Design in Auctions.md
-E:\Wiki\2nd\10_Wiki\Topics\Design & Experience\Mechanism Design.md
-E:\Wiki\2nd\10_Wiki\Topics\Design & Experience\Mechanism-Design.md
-E:\Wiki\2nd\10_Wiki\Topics\Design & Experience\Micro-Frontend-Architecture.md
-E:\Wiki\2nd\10_Wiki\Topics\Design & Experience\Mobile-App-Onboarding.md
-E:\Wiki\2nd\10_Wiki\Topics\Design & Experience\Module Resolution Algorithm.md
-E:\Wiki\2nd\10_Wiki\Topics\Design & Experience\Module-Augmentation-Patterns.md
-E:\Wiki\2nd\10_Wiki\Topics\Design & Experience\Module-Resolution-Strategy.md
-E:\Wiki\2nd\10_Wiki\Topics\Design & Experience\Monorepo-Architecture-Design.md
-E:\Wiki\2nd\10_Wiki\Topics\Design & Experience\Monorepo-Architecture.md
-E:\Wiki\2nd\10_Wiki\Topics\Design & Experience\Monorepo-Dependency-Graph-Analysis.md
-E:\Wiki\2nd\10_Wiki\Topics\Design & Experience\Monte Carlo Tree Search (MCTS).md
-E:\Wiki\2nd\10_Wiki\Topics\Design & Experience\Motor-Learning-Theory.md
-E:\Wiki\2nd\10_Wiki\Topics\Design & Experience\Motor-Learning.md
-E:\Wiki\2nd\10_Wiki\Topics\Design & Experience\Narrative Design.md
-E:\Wiki\2nd\10_Wiki\Topics\Design & Experience\Narrative Intelligence.md
-E:\Wiki\2nd\10_Wiki\Topics\Design & Experience\Nash Equilibrium.md
-E:\Wiki\2nd\10_Wiki\Topics\Design & Experience\Nash-Equilibrium.md
-E:\Wiki\2nd\10_Wiki\Topics\Design & Experience\Ninja-Build-System.md
-E:\Wiki\2nd\10_Wiki\Topics\Design & Experience\Nodejs-Backend-Architecture.md
-E:\Wiki\2nd\10_Wiki\Topics\Design & Experience\Nominal Typing.md
-E:\Wiki\2nd\10_Wiki\Topics\Design & Experience\Nominal-Typing-via-Branded-Types.md
-E:\Wiki\2nd\10_Wiki\Topics\Design & Experience\Nominal-Typing-vs-Structural-Typing.md
-E:\Wiki\2nd\10_Wiki\Topics\Design & Experience\Nominal-vs-Structural-Typing.md
-E:\Wiki\2nd\10_Wiki\Topics\Design & Experience\Non-Diegetic UI.md
-E:\Wiki\2nd\10_Wiki\Topics\Design & Experience\Nx-Build-System.md
-E:\Wiki\2nd\10_Wiki\Topics\Design & Experience\Object-Literal-Assignment.md
-E:\Wiki\2nd\10_Wiki\Topics\Design & Experience\Object-Oriented-Interface-Design.md
-E:\Wiki\2nd\10_Wiki\Topics\Design & Experience\Occupational-Ergonomics.md
-E:\Wiki\2nd\10_Wiki\Topics\Design & Experience\OpenAPI-Specification.md
-E:\Wiki\2nd\10_Wiki\Topics\Design & Experience\Optimal-Experience-Research.md
-E:\Wiki\2nd\10_Wiki\Topics\Design & Experience\Organizational Learning Culture.md
-E:\Wiki\2nd\10_Wiki\Topics\Design & Experience\Organizational-Innovation-Management.md
-E:\Wiki\2nd\10_Wiki\Topics\Design & Experience\Orthopedic-Implant-Validation.md
-E:\Wiki\2nd\10_Wiki\Topics\Design & Experience\Player Agency.md
-E:\Wiki\2nd\10_Wiki\Topics\Design & Experience\Player-Autonomy.md
-E:\Wiki\2nd\10_Wiki\Topics\Design & Experience\Political-Philosophy-in-Games.md
-E:\Wiki\2nd\10_Wiki\Topics\Design & Experience\Product-Analytics-Infrastructure.md
-E:\Wiki\2nd\10_Wiki\Topics\Design & Experience\Protocol-Buffers-TypeScript.md
-E:\Wiki\2nd\10_Wiki\Topics\Design & Experience\Public Policy Design.md
-E:\Wiki\2nd\10_Wiki\Topics\Design & Experience\Quantum-Computing-Simulations.md
-E:\Wiki\2nd\10_Wiki\Topics\Design & Experience\Rapier 물리 엔진 스냅샷(Snapshot) 기반 상태 복원.md
-E:\Wiki\2nd\10_Wiki\Topics\Design & Experience\React Native 게임 최적화 (JSI Hermes).md
-E:\Wiki\2nd\10_Wiki\Topics\Design & Experience\Redstone Engineering.md
-E:\Wiki\2nd\10_Wiki\Topics\Design & Experience\Redux-Reducers.md
-E:\Wiki\2nd\10_Wiki\Topics\Design & Experience\Redux-Toolkit-Architecture.md
-E:\Wiki\2nd\10_Wiki\Topics\Design & Experience\Reinforcement Learning Reward Shaping.md
-E:\Wiki\2nd\10_Wiki\Topics\Design & Experience\Roguelike Subgenre.md
-E:\Wiki\2nd\10_Wiki\Topics\Design & Experience\SeL4-Microkernel.md
-E:\Wiki\2nd\10_Wiki\Topics\Design & Experience\Self-Determination Theory.md
-E:\Wiki\2nd\10_Wiki\Topics\Design & Experience\Self-Determination-Theory.md
-E:\Wiki\2nd\10_Wiki\Topics\Design & Experience\Service-Design.md
-E:\Wiki\2nd\10_Wiki\Topics\Design & Experience\SimCity-Series.md
-E:\Wiki\2nd\10_Wiki\Topics\Design & Experience\Single-Responsibility-Principle.md
-E:\Wiki\2nd\10_Wiki\Topics\Design & Experience\Single-Source-of-Truth-Principle.md
-E:\Wiki\2nd\10_Wiki\Topics\Design & Experience\Smithsonian-Digital-Repository.md
-E:\Wiki\2nd\10_Wiki\Topics\Design & Experience\Social Learning Theory.md
-E:\Wiki\2nd\10_Wiki\Topics\Design & Experience\Socially Assistive Robotics (SAR).md
-E:\Wiki\2nd\10_Wiki\Topics\Design & Experience\Software Architecture  API Contract Design.md
-E:\Wiki\2nd\10_Wiki\Topics\Design & Experience\Software-Contract-Enforcement.md
-E:\Wiki\2nd\10_Wiki\Topics\Design & Experience\Software-Product-Management.md
-E:\Wiki\2nd\10_Wiki\Topics\Design & Experience\Spatial Cognition.md
-E:\Wiki\2nd\10_Wiki\Topics\Design & Experience\Spatial Computing.md
-E:\Wiki\2nd\10_Wiki\Topics\Design & Experience\State-Machine-Implementation.md
-E:\Wiki\2nd\10_Wiki\Topics\Design & Experience\Static Type Checking Systems.md
-E:\Wiki\2nd\10_Wiki\Topics\Design & Experience\Static-Program-Analysis.md
-E:\Wiki\2nd\10_Wiki\Topics\Design & Experience\Structural Type System.md
-E:\Wiki\2nd\10_Wiki\Topics\Design & Experience\Structural-Subtyping.md
-E:\Wiki\2nd\10_Wiki\Topics\Design & Experience\Structural-Type-System.md
-E:\Wiki\2nd\10_Wiki\Topics\Design & Experience\Structural-Typing-Analysis.md
-E:\Wiki\2nd\10_Wiki\Topics\Design & Experience\Structural-Typing-and-Compatibility.md
-E:\Wiki\2nd\10_Wiki\Topics\Design & Experience\Structural-Typing-Compatibility.md
-E:\Wiki\2nd\10_Wiki\Topics\Design & Experience\Structural-Typing-Mechanics.md
-E:\Wiki\2nd\10_Wiki\Topics\Design & Experience\Structural-Typing-Mechanisms.md
-E:\Wiki\2nd\10_Wiki\Topics\Design & Experience\Structural-Typing-System.md
-E:\Wiki\2nd\10_Wiki\Topics\Design & Experience\Structural-Typing-vs-Nominal-Typing.md
-E:\Wiki\2nd\10_Wiki\Topics\Design & Experience\Structural-Typing.md
-E:\Wiki\2nd\10_Wiki\Topics\Design & Experience\Structural-vs-Nominal-Typing-in-TS.md
-E:\Wiki\2nd\10_Wiki\Topics\Design & Experience\Structural-vs-Nominal-Typing.md
-E:\Wiki\2nd\10_Wiki\Topics\Design & Experience\Subtyping-and-Variance.md
-E:\Wiki\2nd\10_Wiki\Topics\Design & Experience\Subtyping-Relations.md
-E:\Wiki\2nd\10_Wiki\Topics\Design & Experience\Subtyping-Rules.md
-E:\Wiki\2nd\10_Wiki\Topics\Design & Experience\Systemic Design.md
-E:\Wiki\2nd\10_Wiki\Topics\Design & Experience\Systemic Game Design.md
-E:\Wiki\2nd\10_Wiki\Topics\Design & Experience\Systemic-Design.md
-E:\Wiki\2nd\10_Wiki\Topics\Design & Experience\Systems-Thinking.md
-E:\Wiki\2nd\10_Wiki\Topics\Design & Experience\Template-Literal-Types.md
-E:\Wiki\2nd\10_Wiki\Topics\Design & Experience\The Emergence Theory in Game Design.md
-E:\Wiki\2nd\10_Wiki\Topics\Design & Experience\The Last of Us (Resource Scarcity and Character Bond).md
-E:\Wiki\2nd\10_Wiki\Topics\Design & Experience\Topological-Sorting.md
-E:\Wiki\2nd\10_Wiki\Topics\Design & Experience\Touchpoint-Analysis.md
-E:\Wiki\2nd\10_Wiki\Topics\Design & Experience\Turborepo-Orchestration.md
-E:\Wiki\2nd\10_Wiki\Topics\Design & Experience\Type Branding.md
-E:\Wiki\2nd\10_Wiki\Topics\Design & Experience\Type-Aware-Linting.md
-E:\Wiki\2nd\10_Wiki\Topics\Design & Experience\Type-Compatibility-and-Subtyping.md
-E:\Wiki\2nd\10_Wiki\Topics\Design & Experience\Type-Compatibility-Rules.md
-E:\Wiki\2nd\10_Wiki\Topics\Design & Experience\Type-Compatibility.md
-E:\Wiki\2nd\10_Wiki\Topics\Design & Experience\Type-Composition-via-Intersections.md
-E:\Wiki\2nd\10_Wiki\Topics\Design & Experience\Type-Driven-Development.md
-E:\Wiki\2nd\10_Wiki\Topics\Design & Experience\Type-Erasure-and-Runtime-Behavior.md
-E:\Wiki\2nd\10_Wiki\Topics\Design & Experience\Type-Guards-and-Narrowing.md
-E:\Wiki\2nd\10_Wiki\Topics\Design & Experience\Type-Narrowing.md
-E:\Wiki\2nd\10_Wiki\Topics\Design & Experience\Type-Safe-API-Design.md
-E:\Wiki\2nd\10_Wiki\Topics\Design & Experience\Type-Safety-and-Exhaustiveness-Checking.md
-E:\Wiki\2nd\10_Wiki\Topics\Design & Experience\Type-Safety.md
-E:\Wiki\2nd\10_Wiki\Topics\Design & Experience\Type-Variance-in-TypeScript.md
-E:\Wiki\2nd\10_Wiki\Topics\Design & Experience\TypeScript Compiler API.md
-E:\Wiki\2nd\10_Wiki\Topics\Design & Experience\TypeScript Type System (Interface Design).md
-E:\Wiki\2nd\10_Wiki\Topics\Design & Experience\TypeScript 라이브러리 타입 확장.md
-E:\Wiki\2nd\10_Wiki\Topics\Design & Experience\TypeScript-Compiler-API-Design.md
-E:\Wiki\2nd\10_Wiki\Topics\Design & Experience\TypeScript-Compiler-API.md
-E:\Wiki\2nd\10_Wiki\Topics\Design & Experience\TypeScript-Compiler-Architecture.md
-E:\Wiki\2nd\10_Wiki\Topics\Design & Experience\TypeScript-Language-Service-API.md
-E:\Wiki\2nd\10_Wiki\Topics\Design & Experience\TypeScript-Project-References.md
-E:\Wiki\2nd\10_Wiki\Topics\Design & Experience\Unified-User-Experience.md
-E:\Wiki\2nd\10_Wiki\Topics\Design & Experience\Union-Types.md
-E:\Wiki\2nd\10_Wiki\Topics\Design & Experience\Urban-Morphology.md
-E:\Wiki\2nd\10_Wiki\Topics\Design & Experience\Urban-Planning-Simulations.md
-E:\Wiki\2nd\10_Wiki\Topics\Design & Experience\User Experience (UX) Design.md
-E:\Wiki\2nd\10_Wiki\Topics\Design & Experience\User Experience (UX) in Game Design.md
-E:\Wiki\2nd\10_Wiki\Topics\Design & Experience\User-Experience-Design.md
-E:\Wiki\2nd\10_Wiki\Topics\Design & Experience\UX_UI in Interactive Media.md
-E:\Wiki\2nd\10_Wiki\Topics\Design & Experience\Variance (Covariance Contravariance Invariance).md
-E:\Wiki\2nd\10_Wiki\Topics\Design & Experience\Variance-(Covariance-Contravariance-Invariance).md
-E:\Wiki\2nd\10_Wiki\Topics\Design & Experience\Variance-Covariance-Contravariance.md
-E:\Wiki\2nd\10_Wiki\Topics\Design & Experience\Video Game Design.md
-E:\Wiki\2nd\10_Wiki\Topics\Design & Experience\Visual-Hierarchy-in-Game-Design.md
-E:\Wiki\2nd\10_Wiki\Topics\Design & Experience\Von Neumann-Morgenstern Axioms.md
-E:\Wiki\2nd\10_Wiki\Topics\Design & Experience\W3C-Semantic-Web-Standards.md
-E:\Wiki\2nd\10_Wiki\Topics\Design & Experience\Wayfinding-Design.md
-E:\Wiki\2nd\10_Wiki\Topics\Design & Experience\Wicked-Problems.md
-E:\Wiki\2nd\10_Wiki\Topics\Design & Experience\Width-and-Depth-Subtyping.md
-E:\Wiki\2nd\10_Wiki\Topics\Design & Experience\Zod-Runtime-Validation.md
-E:\Wiki\2nd\10_Wiki\Topics\Design & Experience\Zod-Schema-Validation.md
-E:\Wiki\2nd\10_Wiki\Topics\Design & Experience\고성능 실시간 상호작용 시스템을 위한 React 기반 게임 엔진 아키텍처.md
-E:\Wiki\2nd\10_Wiki\Topics\Design & Experience\교육 심리학에서의 보상 설계.md
-E:\Wiki\2nd\10_Wiki\Topics\Design & Experience\교육학의 모델링 전략.md
-E:\Wiki\2nd\10_Wiki\Topics\Design & Experience\뇌과학 기반 중독 재활 프로그램.md
-E:\Wiki\2nd\10_Wiki\Topics\Design & Experience\데이터 지향 설계 (Data-Oriented Design).md
-E:\Wiki\2nd\10_Wiki\Topics\Design & Experience\도파민 보상 체계.md
-E:\Wiki\2nd\10_Wiki\Topics\Design & Experience\맞춤형 개별화 학습 설계.md
-E:\Wiki\2nd\10_Wiki\Topics\Design & Experience\모바일 앱 및 웹 인터페이스 설계.md
-E:\Wiki\2nd\10_Wiki\Topics\Design & Experience\사용성 공학 (Usability Engineering).md
-E:\Wiki\2nd\10_Wiki\Topics\Design & Experience\사용자 경험 (UX) 디자인.md
-E:\Wiki\2nd\10_Wiki\Topics\Design & Experience\사용자 경험 (UX).md
-E:\Wiki\2nd\10_Wiki\Topics\Design & Experience\사용자 경험 디자인 (UX Design).md
-E:\Wiki\2nd\10_Wiki\Topics\Design & Experience\사회 인지 이론(Social Cognitive Theory).md
-E:\Wiki\2nd\10_Wiki\Topics\Design & Experience\상태 관리 최적화 (Zustand Valtio).md
-E:\Wiki\2nd\10_Wiki\Topics\Design & Experience\아보(Bobo) 인형 실험.md
-E:\Wiki\2nd\10_Wiki\Topics\Design & Experience\응용 행동 분석(ABA)] [행동 경제학] [교육 심리학의 행동주의 모델.md
-E:\Wiki\2nd\10_Wiki\Topics\Design & Experience\인간 요인 공학 (Human Factors Engineering).md
-E:\Wiki\2nd\10_Wiki\Topics\Design & Experience\인지 부조화 이론.md
-E:\Wiki\2nd\10_Wiki\Topics\Design & Experience\인지 부하 이론(Cognitive Load Theory).md
-E:\Wiki\2nd\10_Wiki\Topics\Design & Experience\인지 심리학 (Cognitive Psychology).md
-E:\Wiki\2nd\10_Wiki\Topics\Design & Experience\인지 평가 이론 (Cognitive Evaluation Theory).md
-E:\Wiki\2nd\10_Wiki\Topics\Design & Experience\자기 효능감 (Self-Efficacy).md
-E:\Wiki\2nd\10_Wiki\Topics\Design & Experience\자기 효능감(Self-Efficacy).md
-E:\Wiki\2nd\10_Wiki\Topics\Design & Experience\자기조절학습(Self-Regulated Learning).md
-E:\Wiki\2nd\10_Wiki\Topics\Design & Experience\조직 시민 행동 (OCB).md
-E:\Wiki\2nd\10_Wiki\Topics\Design & Experience\조직 행동론의 성과급 체계 분석.md
-E:\Wiki\2nd\10_Wiki\Topics\Design & Experience\중독 의학 및 정신 병리학.md
-E:\Wiki\2nd\10_Wiki\Topics\Design & Experience\중독 재활 프로그램.md
-E:\Wiki\2nd\10_Wiki\Topics\Design & Experience\플레이어 경험 디자인 (Player Experience Design).md
-E:\Wiki\2nd\10_Wiki\Topics\Design & Experience\행동 치료 및 인지 행동 치료 (CBT).md
-E:\Wiki\2nd\10_Wiki\Topics\Game Design\Cyber-Physical Systems (CPS).md
-E:\Wiki\2nd\10_Wiki\Topics\Game Design\Elite-Athletic-Development.md
-E:\Wiki\2nd\10_Wiki\Topics\Game Design\Post-Modernist Literature in Gaming.md
-E:\Wiki\2nd\10_Wiki\Topics\Game Design\Quantum-Game-Theory.md
-E:\Wiki\2nd\10_Wiki\Topics\Game Design\Roguelike Procedural Generation.md
-E:\Wiki\2nd\10_Wiki\Topics\Game Design\Systems Biology.md
-E:\Wiki\2nd\10_Wiki\Topics\Game Design\인문학적 게임 비평 및 서사학.md
-E:\Wiki\2nd\10_Wiki\Topics\General Knowledge\2026-04-15.md
-E:\Wiki\2nd\10_Wiki\Topics\General Knowledge\Blog_Content_Rules.md
-E:\Wiki\2nd\10_Wiki\Topics\General Knowledge\Blog_Title_Rules.md
-E:\Wiki\2nd\10_Wiki\Topics\General Knowledge\Brand-Identity-Management.md
-E:\Wiki\2nd\10_Wiki\Topics\General Knowledge\Code Splitting  Lazy Loading.md
-E:\Wiki\2nd\10_Wiki\Topics\General Knowledge\Description-Logics.md
-E:\Wiki\2nd\10_Wiki\Topics\General Knowledge\Dopamine Signaling.md
-E:\Wiki\2nd\10_Wiki\Topics\General Knowledge\Markov-Random-Fields.md
-E:\Wiki\2nd\10_Wiki\Topics\General Knowledge\Metaverse Aesthetics.md
-E:\Wiki\2nd\10_Wiki\Topics\General Knowledge\Model-Free RL vs Model-Based RL.md
-E:\Wiki\2nd\10_Wiki\Topics\General Knowledge\Motion-Capture-Retargeting.md
-E:\Wiki\2nd\10_Wiki\Topics\General Knowledge\Mycological Horror.md
-E:\Wiki\2nd\10_Wiki\Topics\General Knowledge\OffscreenCanvas (멀티스레딩).md
-E:\Wiki\2nd\10_Wiki\Topics\General Knowledge\README.md
-E:\Wiki\2nd\10_Wiki\Topics\General Knowledge\Variance-Rules.md
-E:\Wiki\2nd\10_Wiki\Topics\General Knowledge\마크-스위프-컴팩트(Mark-Sweep-Compact).md
-E:\Wiki\2nd\10_Wiki\Topics\General Knowledge\무제.md
-E:\Wiki\2nd\10_Wiki\Topics\General Knowledge\이벤트 포워딩(Event Forwarding).md
-E:\Wiki\2nd\10_Wiki\Topics\General Knowledge\환영합니다.md
-E:\Wiki\2nd\10_Wiki\Topics\Graphics & Performance\Agency-Narrative Integration.md
-E:\Wiki\2nd\10_Wiki\Topics\Graphics & Performance\Apple-Human-Interface-Guidelines.md
-E:\Wiki\2nd\10_Wiki\Topics\Graphics & Performance\Augmented Reality (AR).md
-E:\Wiki\2nd\10_Wiki\Topics\Graphics & Performance\Augmented Reality Navigation Systems.md
-E:\Wiki\2nd\10_Wiki\Topics\Graphics & Performance\Autonomous Vehicle Perception.md
-E:\Wiki\2nd\10_Wiki\Topics\Graphics & Performance\BatchedMesh.md
-E:\Wiki\2nd\10_Wiki\Topics\Graphics & Performance\Behavioral Economics in Digital Ecosystems.md
-E:\Wiki\2nd\10_Wiki\Topics\Graphics & Performance\Behavioral Economics.md
-E:\Wiki\2nd\10_Wiki\Topics\Graphics & Performance\Bio-mechanical-Modeling.md
-E:\Wiki\2nd\10_Wiki\Topics\Graphics & Performance\Bioregionalism.md
-E:\Wiki\2nd\10_Wiki\Topics\Graphics & Performance\Bounding Volume Hierarchy (BVH).md
-E:\Wiki\2nd\10_Wiki\Topics\Graphics & Performance\Cel-Shading-Techniques.md
-E:\Wiki\2nd\10_Wiki\Topics\Graphics & Performance\Cellular Automata.md
-E:\Wiki\2nd\10_Wiki\Topics\Graphics & Performance\Cognitive Load Theory.md
-E:\Wiki\2nd\10_Wiki\Topics\Graphics & Performance\Cognitive-Load-Theory.md
-E:\Wiki\2nd\10_Wiki\Topics\Graphics & Performance\Collaborative Learning Environments.md
-E:\Wiki\2nd\10_Wiki\Topics\Graphics & Performance\Competitive Esports Ecosystems.md
-E:\Wiki\2nd\10_Wiki\Topics\Graphics & Performance\Complexity-Theory.md
-E:\Wiki\2nd\10_Wiki\Topics\Graphics & Performance\Computational Ecology.md
-E:\Wiki\2nd\10_Wiki\Topics\Graphics & Performance\Computer-Vision-Synthesis.md
-E:\Wiki\2nd\10_Wiki\Topics\Graphics & Performance\Creative Process.md
-E:\Wiki\2nd\10_Wiki\Topics\Graphics & Performance\Critical-Play.md
-E:\Wiki\2nd\10_Wiki\Topics\Graphics & Performance\Cultural-Heritage-Informatics.md
-E:\Wiki\2nd\10_Wiki\Topics\Graphics & Performance\CyArk.md
-E:\Wiki\2nd\10_Wiki\Topics\Graphics & Performance\Cybertext Theory.md
-E:\Wiki\2nd\10_Wiki\Topics\Graphics & Performance\DBpedia.md
-E:\Wiki\2nd\10_Wiki\Topics\Graphics & Performance\Digital Sandbox Theory.md
-E:\Wiki\2nd\10_Wiki\Topics\Graphics & Performance\Digital Twin Visualization.md
-E:\Wiki\2nd\10_Wiki\Topics\Graphics & Performance\Drama-Management-Systems.md
-E:\Wiki\2nd\10_Wiki\Topics\Graphics & Performance\Dual-Track-Agile.md
-E:\Wiki\2nd\10_Wiki\Topics\Graphics & Performance\Duolingo (Language Learning)] [Fitness Tracking Apps (Strava_Fitbit)] [EdTech Gamification] [FinTech Engagement Strategies.md
-E:\Wiki\2nd\10_Wiki\Topics\Graphics & Performance\Dynamic Assessment.md
-E:\Wiki\2nd\10_Wiki\Topics\Graphics & Performance\Dynamical Systems Theory.md
-E:\Wiki\2nd\10_Wiki\Topics\Graphics & Performance\Ecosystem-Modeling.md
-E:\Wiki\2nd\10_Wiki\Topics\Graphics & Performance\EdTech (Gamified Learning).md
-E:\Wiki\2nd\10_Wiki\Topics\Graphics & Performance\Educational-Gamification.md
-E:\Wiki\2nd\10_Wiki\Topics\Graphics & Performance\Embodied Cognition in Virtual Reality.md
-E:\Wiki\2nd\10_Wiki\Topics\Graphics & Performance\Employee Engagement Systems.md
-E:\Wiki\2nd\10_Wiki\Topics\Graphics & Performance\Epidemiological Forecasting.md
-E:\Wiki\2nd\10_Wiki\Topics\Graphics & Performance\Epidemiological Modeling.md
-E:\Wiki\2nd\10_Wiki\Topics\Graphics & Performance\Expressjs-Type-Extensions.md
-E:\Wiki\2nd\10_Wiki\Topics\Graphics & Performance\Flow State Theory.md
-E:\Wiki\2nd\10_Wiki\Topics\Graphics & Performance\Formal-Grammar.md
-E:\Wiki\2nd\10_Wiki\Topics\Graphics & Performance\Formalism-vs-Structuralism.md
-E:\Wiki\2nd\10_Wiki\Topics\Graphics & Performance\Formalist Game Design.md
-E:\Wiki\2nd\10_Wiki\Topics\Graphics & Performance\Game Studies (Academic Discipline).md
-E:\Wiki\2nd\10_Wiki\Topics\Graphics & Performance\Game Theory (Economics).md
-E:\Wiki\2nd\10_Wiki\Topics\Graphics & Performance\Game Theory and Market Equilibrium.md
-E:\Wiki\2nd\10_Wiki\Topics\Graphics & Performance\Game Theory.md
-E:\Wiki\2nd\10_Wiki\Topics\Graphics & Performance\Gamification-Design.md
-E:\Wiki\2nd\10_Wiki\Topics\Graphics & Performance\Graph Theory in Level Design.md
-E:\Wiki\2nd\10_Wiki\Topics\Graphics & Performance\Human-Centered Design.md
-E:\Wiki\2nd\10_Wiki\Topics\Graphics & Performance\Human-Computer-Interaction-HCI.md
-E:\Wiki\2nd\10_Wiki\Topics\Graphics & Performance\Immersive Educational Simulations.md
-E:\Wiki\2nd\10_Wiki\Topics\Graphics & Performance\Instructional Systems Design (ISD).md
-E:\Wiki\2nd\10_Wiki\Topics\Graphics & Performance\Instructional-Design.md
-E:\Wiki\2nd\10_Wiki\Topics\Graphics & Performance\Interactive Storytelling.md
-E:\Wiki\2nd\10_Wiki\Topics\Graphics & Performance\Interactive-Storytelling.md
-E:\Wiki\2nd\10_Wiki\Topics\Graphics & Performance\Internet of Things (IoT) Telemetry.md
-E:\Wiki\2nd\10_Wiki\Topics\Graphics & Performance\Intrinsic Motivation.md
-E:\Wiki\2nd\10_Wiki\Topics\Graphics & Performance\ISO 9241 Standards.md
-E:\Wiki\2nd\10_Wiki\Topics\Graphics & Performance\Knowledge-Graphs.md
-E:\Wiki\2nd\10_Wiki\Topics\Graphics & Performance\Looking-Glass-Studios.md
-E:\Wiki\2nd\10_Wiki\Topics\Graphics & Performance\Loot Box Regulation (EU_China Compliance).md
-E:\Wiki\2nd\10_Wiki\Topics\Graphics & Performance\Ludology.md
-E:\Wiki\2nd\10_Wiki\Topics\Graphics & Performance\Markov Decision Process (MDP).md
-E:\Wiki\2nd\10_Wiki\Topics\Graphics & Performance\Markov Decision Processes.md
-E:\Wiki\2nd\10_Wiki\Topics\Graphics & Performance\Mathematical Game Theory.md
-E:\Wiki\2nd\10_Wiki\Topics\Graphics & Performance\MDA Framework.md
-E:\Wiki\2nd\10_Wiki\Topics\Graphics & Performance\MDA-Framework.md
-E:\Wiki\2nd\10_Wiki\Topics\Graphics & Performance\Measure Theory.md
-E:\Wiki\2nd\10_Wiki\Topics\Graphics & Performance\Meta Quest_Horizon OS.md
-E:\Wiki\2nd\10_Wiki\Topics\Graphics & Performance\Metaverse Architecture.md
-E:\Wiki\2nd\10_Wiki\Topics\Graphics & Performance\Minecraft.md
-E:\Wiki\2nd\10_Wiki\Topics\Graphics & Performance\Minecraft_ Education Edition.md
-E:\Wiki\2nd\10_Wiki\Topics\Graphics & Performance\Mobile Gaming Monetization Strategies.md
-E:\Wiki\2nd\10_Wiki\Topics\Graphics & Performance\Narrative-Branching-Models.md
-E:\Wiki\2nd\10_Wiki\Topics\Graphics & Performance\Narratology.md
-E:\Wiki\2nd\10_Wiki\Topics\Graphics & Performance\NASA-Jet-Propulsion-Laboratory-Software-Standards.md
-E:\Wiki\2nd\10_Wiki\Topics\Graphics & Performance\NVIDIA Omniverse.md
-E:\Wiki\2nd\10_Wiki\Topics\Graphics & Performance\OffscreenCanvas 기반 멀티스레드 렌더링 구현.md
-E:\Wiki\2nd\10_Wiki\Topics\Graphics & Performance\Open Metaverse Framework.md
-E:\Wiki\2nd\10_Wiki\Topics\Graphics & Performance\Open-World Design Paradigms.md
-E:\Wiki\2nd\10_Wiki\Topics\Graphics & Performance\Operant Conditioning.md
-E:\Wiki\2nd\10_Wiki\Topics\Graphics & Performance\Perlin Noise.md
-E:\Wiki\2nd\10_Wiki\Topics\Graphics & Performance\Physics Engine Integration.md
-E:\Wiki\2nd\10_Wiki\Topics\Graphics & Performance\Positive Psychology.md
-E:\Wiki\2nd\10_Wiki\Topics\Graphics & Performance\Positive-Psychology.md
-E:\Wiki\2nd\10_Wiki\Topics\Graphics & Performance\Post-Acute-Care-Models.md
-E:\Wiki\2nd\10_Wiki\Topics\Graphics & Performance\Post-humanism.md
-E:\Wiki\2nd\10_Wiki\Topics\Graphics & Performance\Probabilistic-Graphical-Models.md
-E:\Wiki\2nd\10_Wiki\Topics\Graphics & Performance\Problem-Solving-Theory.md
-E:\Wiki\2nd\10_Wiki\Topics\Graphics & Performance\Procedural-Animation.md
-E:\Wiki\2nd\10_Wiki\Topics\Graphics & Performance\R3F 3D 게임 환경의 메모리 관리.md
-E:\Wiki\2nd\10_Wiki\Topics\Graphics & Performance\RDF와 OWL.md
-E:\Wiki\2nd\10_Wiki\Topics\Graphics & Performance\React 기반 게임 엔진 아키텍처.md
-E:\Wiki\2nd\10_Wiki\Topics\Graphics & Performance\React 동시성 기능 (Concurrent Features).md
-E:\Wiki\2nd\10_Wiki\Topics\Graphics & Performance\Redux-Reducer-Pattern.md
-E:\Wiki\2nd\10_Wiki\Topics\Graphics & Performance\Robotics-Control-Systems.md
-E:\Wiki\2nd\10_Wiki\Topics\Graphics & Performance\Role-Playing-Games (RPGs).md
-E:\Wiki\2nd\10_Wiki\Topics\Graphics & Performance\SaaS-Retention-Strategies.md
-E:\Wiki\2nd\10_Wiki\Topics\Graphics & Performance\Sandbox-Simulation.md
-E:\Wiki\2nd\10_Wiki\Topics\Graphics & Performance\Search-Based Procedural Content Generation (SBPCG).md
-E:\Wiki\2nd\10_Wiki\Topics\Graphics & Performance\Semantic Versioning (SemVer) in Type Safety.md
-E:\Wiki\2nd\10_Wiki\Topics\Graphics & Performance\Semantic-Web-Technologies.md
-E:\Wiki\2nd\10_Wiki\Topics\Graphics & Performance\Semantic-Web.md
-E:\Wiki\2nd\10_Wiki\Topics\Graphics & Performance\Semiotics in Media.md
-E:\Wiki\2nd\10_Wiki\Topics\Graphics & Performance\Sensor Fusion.md
-E:\Wiki\2nd\10_Wiki\Topics\Graphics & Performance\Service-Dominant-Logic.md
-E:\Wiki\2nd\10_Wiki\Topics\Graphics & Performance\Simulations of Social Systems.md
-E:\Wiki\2nd\10_Wiki\Topics\Graphics & Performance\Simultaneous Localization and Mapping (SLAM).md
-E:\Wiki\2nd\10_Wiki\Topics\Graphics & Performance\Skybound Protocol 기술 메뉴얼 및 개발자 가이드.md
-E:\Wiki\2nd\10_Wiki\Topics\Graphics & Performance\SLA-Definition.md
-E:\Wiki\2nd\10_Wiki\Topics\Graphics & Performance\Smart City Digital Twins.md
-E:\Wiki\2nd\10_Wiki\Topics\Graphics & Performance\Smart-City-Frameworks.md
-E:\Wiki\2nd\10_Wiki\Topics\Graphics & Performance\Special Education Interventions.md
-E:\Wiki\2nd\10_Wiki\Topics\Graphics & Performance\Speculative Biology.md
-E:\Wiki\2nd\10_Wiki\Topics\Graphics & Performance\Structuralism.md
-E:\Wiki\2nd\10_Wiki\Topics\Graphics & Performance\Surgical-Robotics.md
-E:\Wiki\2nd\10_Wiki\Topics\Graphics & Performance\Systemic-Design-Frameworks.md
-E:\Wiki\2nd\10_Wiki\Topics\Graphics & Performance\Systems Theory.md
-E:\Wiki\2nd\10_Wiki\Topics\Graphics & Performance\Temporal-Logic.md
-E:\Wiki\2nd\10_Wiki\Topics\Graphics & Performance\The Rapture Setting.md
-E:\Wiki\2nd\10_Wiki\Topics\Graphics & Performance\The-Space-Syntax-Laboratory.md
-E:\Wiki\2nd\10_Wiki\Topics\Graphics & Performance\Threejs 자원 해제 (Dispose).md
-E:\Wiki\2nd\10_Wiki\Topics\Graphics & Performance\Turtle-Graphics.md
-E:\Wiki\2nd\10_Wiki\Topics\Graphics & Performance\Urban-Resilience-Planning.md
-E:\Wiki\2nd\10_Wiki\Topics\Graphics & Performance\USD - Universal Scene Description.md
-E:\Wiki\2nd\10_Wiki\Topics\Graphics & Performance\User-Story-Mapping.md
-E:\Wiki\2nd\10_Wiki\Topics\Graphics & Performance\UX Design  Gamification.md
-E:\Wiki\2nd\10_Wiki\Topics\Graphics & Performance\UX-Design-Architecture.md
-E:\Wiki\2nd\10_Wiki\Topics\Graphics & Performance\VIA-Classification.md
-E:\Wiki\2nd\10_Wiki\Topics\Graphics & Performance\Virtual Reality (VR) Storytelling.md
-E:\Wiki\2nd\10_Wiki\Topics\Graphics & Performance\Voxel-based Rendering.md
-E:\Wiki\2nd\10_Wiki\Topics\Graphics & Performance\Winning Ways for your Mathematical Plays.md
-E:\Wiki\2nd\10_Wiki\Topics\Graphics & Performance\XState-Library.md
-E:\Wiki\2nd\10_Wiki\Topics\Graphics & Performance\고성능 3D WebGL 게임 렌더링 엔진.md
-E:\Wiki\2nd\10_Wiki\Topics\Graphics & Performance\교육 심리학 및 교수법 설계.md
-E:\Wiki\2nd\10_Wiki\Topics\Graphics & Performance\기업 문화 진단 및 개선.md
-E:\Wiki\2nd\10_Wiki\Topics\Graphics & Performance\만성 질환 행동 수정 개입.md
-E:\Wiki\2nd\10_Wiki\Topics\Graphics & Performance\명령형 직접 조작 (Imperative Manipulation).md
-E:\Wiki\2nd\10_Wiki\Topics\Graphics & Performance\서비스 디자인 (Service Design).md
-E:\Wiki\2nd\10_Wiki\Topics\Graphics & Performance\실시간 물리 시뮬레이션 동기화.md
-E:\Wiki\2nd\10_Wiki\Topics\Graphics & Performance\조직 행동론의 직무 몰입 연구.md
-E:\Wiki\2nd\10_Wiki\Topics\Programming & Language\Albion Online (Full Loot_Player-Driven Production).md
-E:\Wiki\2nd\10_Wiki\Topics\Programming & Language\Athletic-Performance-Optimization.md
-E:\Wiki\2nd\10_Wiki\Topics\Programming & Language\Authorship Attribution.md
-E:\Wiki\2nd\10_Wiki\Topics\Programming & Language\Autotelic Personality.md
-E:\Wiki\2nd\10_Wiki\Topics\Programming & Language\Autotelic-Personality.md
-E:\Wiki\2nd\10_Wiki\Topics\Programming & Language\Biomechanical-Analysis.md
-E:\Wiki\2nd\10_Wiki\Topics\Programming & Language\Biomechanics.md
-E:\Wiki\2nd\10_Wiki\Topics\Programming & Language\BM25 알고리즘 (Best Match 25).md
-E:\Wiki\2nd\10_Wiki\Topics\Programming & Language\Branded Types.md
-E:\Wiki\2nd\10_Wiki\Topics\Programming & Language\Causal Tracing (인과적 추적).md
-E:\Wiki\2nd\10_Wiki\Topics\Programming & Language\Cellular-Automata.md
-E:\Wiki\2nd\10_Wiki\Topics\Programming & Language\Chaos Theory.md
-E:\Wiki\2nd\10_Wiki\Topics\Programming & Language\Chaos-Theory.md
-E:\Wiki\2nd\10_Wiki\Topics\Programming & Language\CI_CD 파이프라인 (CI_CD Pipelines).md
-E:\Wiki\2nd\10_Wiki\Topics\Programming & Language\Codemod-Engineering.md
-E:\Wiki\2nd\10_Wiki\Topics\Programming & Language\Complex Adaptive Systems.md
-E:\Wiki\2nd\10_Wiki\Topics\Programming & Language\Complex-Adaptive-Systems.md
-E:\Wiki\2nd\10_Wiki\Topics\Programming & Language\Conscientiousness.md
-E:\Wiki\2nd\10_Wiki\Topics\Programming & Language\Control-Flow-Analysis.md
-E:\Wiki\2nd\10_Wiki\Topics\Programming & Language\Covariance-and-Contravariance.md
-E:\Wiki\2nd\10_Wiki\Topics\Programming & Language\Cybertext.md
-E:\Wiki\2nd\10_Wiki\Topics\Programming & Language\Cypher 질의 언어 (Neo4j).md
-E:\Wiki\2nd\10_Wiki\Topics\Programming & Language\DefinitelyTyped and Ambient Declarations.md
-E:\Wiki\2nd\10_Wiki\Topics\Programming & Language\Description Logic (기술 논리).md
-E:\Wiki\2nd\10_Wiki\Topics\Programming & Language\Deterministic Algorithms.md
-E:\Wiki\2nd\10_Wiki\Topics\Programming & Language\Disentanglement (개념 분리).md
-E:\Wiki\2nd\10_Wiki\Topics\Programming & Language\Dublin Core Metadata Initiative.md
-E:\Wiki\2nd\10_Wiki\Topics\Programming & Language\Dwarf Fortress (Simulation-heavy PCG).md
-E:\Wiki\2nd\10_Wiki\Topics\Programming & Language\Dwarf-Fortress.md
-E:\Wiki\2nd\10_Wiki\Topics\Programming & Language\Emergent Gameplay Theory.md
-E:\Wiki\2nd\10_Wiki\Topics\Programming & Language\Emergent Gameplay.md
-E:\Wiki\2nd\10_Wiki\Topics\Programming & Language\Emergent Systems.md
-E:\Wiki\2nd\10_Wiki\Topics\Programming & Language\Emergent-Gameplay.md
-E:\Wiki\2nd\10_Wiki\Topics\Programming & Language\Entity Component System (ECS).md
-E:\Wiki\2nd\10_Wiki\Topics\Programming & Language\Epigenetics of Neuroplasticity.md
-E:\Wiki\2nd\10_Wiki\Topics\Programming & Language\Feature Ablation (피처 제거).md
-E:\Wiki\2nd\10_Wiki\Topics\Programming & Language\Federated SPARQL (연합 질의).md
-E:\Wiki\2nd\10_Wiki\Topics\Programming & Language\Finite-State-Machines-in-TypeScript.md
-E:\Wiki\2nd\10_Wiki\Topics\Programming & Language\Flow Theory.md
-E:\Wiki\2nd\10_Wiki\Topics\Programming & Language\Flow-Theory.md
-E:\Wiki\2nd\10_Wiki\Topics\Programming & Language\Fractal-Geometry.md
-E:\Wiki\2nd\10_Wiki\Topics\Programming & Language\Function-Overloading.md
-E:\Wiki\2nd\10_Wiki\Topics\Programming & Language\Function-Signature-Compatibility.md
-E:\Wiki\2nd\10_Wiki\Topics\Programming & Language\Game Studies (Digital Media Theory).md
-E:\Wiki\2nd\10_Wiki\Topics\Programming & Language\Game Studies (Ludology vs Narratology).md
-E:\Wiki\2nd\10_Wiki\Topics\Programming & Language\Game Studies.md
-E:\Wiki\2nd\10_Wiki\Topics\Programming & Language\Garbage Collection (GC) 최적화.md
-E:\Wiki\2nd\10_Wiki\Topics\Programming & Language\GQL (Graph Query Language ISO 표준).md
-E:\Wiki\2nd\10_Wiki\Topics\Programming & Language\Graph-Grammars.md
-E:\Wiki\2nd\10_Wiki\Topics\Programming & Language\Grokking (그로킹 지연 일반화).md
-E:\Wiki\2nd\10_Wiki\Topics\Programming & Language\HNSW 알고리즘 (Hierarchical Navigable Small World).md
-E:\Wiki\2nd\10_Wiki\Topics\Programming & Language\HTC Vive Pro HMD.md
-E:\Wiki\2nd\10_Wiki\Topics\Programming & Language\Immersive Sim Genre.md
-E:\Wiki\2nd\10_Wiki\Topics\Programming & Language\Industry 40_Smart Manufacturing.md
-E:\Wiki\2nd\10_Wiki\Topics\Programming & Language\InstancedMesh Performance Bottlenecks.md
-E:\Wiki\2nd\10_Wiki\Topics\Programming & Language\Integrated Gradients (통합 그래디언트).md
-E:\Wiki\2nd\10_Wiki\Topics\Programming & Language\Interactive Fiction (IF).md
-E:\Wiki\2nd\10_Wiki\Topics\Programming & Language\Interactive Narrative.md
-E:\Wiki\2nd\10_Wiki\Topics\Programming & Language\Interactive-Fiction-Tradition.md
-E:\Wiki\2nd\10_Wiki\Topics\Programming & Language\Intrinsic-Motivation.md
-E:\Wiki\2nd\10_Wiki\Topics\Programming & Language\Isovist-Analysis.md
-E:\Wiki\2nd\10_Wiki\Topics\Programming & Language\Jacobian-Matrix-Analysis.md
-E:\Wiki\2nd\10_Wiki\Topics\Programming & Language\JavaScript 메모리 관리(JavaScript Memory Management).md
-E:\Wiki\2nd\10_Wiki\Topics\Programming & Language\Kinematics.md
-E:\Wiki\2nd\10_Wiki\Topics\Programming & Language\L-systems in Biology.md
-E:\Wiki\2nd\10_Wiki\Topics\Programming & Language\L-Systems.md
-E:\Wiki\2nd\10_Wiki\Topics\Programming & Language\Labeled Property Graph (LPG 속성 그래프).md
-E:\Wiki\2nd\10_Wiki\Topics\Programming & Language\Latiotech Report.md
-E:\Wiki\2nd\10_Wiki\Topics\Programming & Language\Linked Open Data (LOD).md
-E:\Wiki\2nd\10_Wiki\Topics\Programming & Language\Live Streaming Monetization.md
-E:\Wiki\2nd\10_Wiki\Topics\Programming & Language\Logit Lens (로짓 렌즈).md
-E:\Wiki\2nd\10_Wiki\Topics\Programming & Language\Long-Term Potentiation (LTP).md
-E:\Wiki\2nd\10_Wiki\Topics\Programming & Language\Looking Glass Studios.md
-E:\Wiki\2nd\10_Wiki\Topics\Programming & Language\Ludology vs Narratology Debate.md
-E:\Wiki\2nd\10_Wiki\Topics\Programming & Language\Ludology vs Narratology.md
-E:\Wiki\2nd\10_Wiki\Topics\Programming & Language\Ludonarrative Dissonance.md
-E:\Wiki\2nd\10_Wiki\Topics\Programming & Language\Ludonarrative Resonance.md
-E:\Wiki\2nd\10_Wiki\Topics\Programming & Language\Mark-Sweep-Compact.md
-E:\Wiki\2nd\10_Wiki\Topics\Programming & Language\Mechanobiology.md
-E:\Wiki\2nd\10_Wiki\Topics\Programming & Language\Mesa-Optimization (메사 최적화).md
-E:\Wiki\2nd\10_Wiki\Topics\Programming & Language\Microsoft Edge DevTools.md
-E:\Wiki\2nd\10_Wiki\Topics\Programming & Language\MMORPG Ecosystems.md
-E:\Wiki\2nd\10_Wiki\Topics\Programming & Language\Model-Checking.md
-E:\Wiki\2nd\10_Wiki\Topics\Programming & Language\Multi-Agent-Systems.md
-E:\Wiki\2nd\10_Wiki\Topics\Programming & Language\Network Science.md
-E:\Wiki\2nd\10_Wiki\Topics\Programming & Language\New Media Theory.md
-E:\Wiki\2nd\10_Wiki\Topics\Programming & Language\Nodejs Memory Management.md
-E:\Wiki\2nd\10_Wiki\Topics\Programming & Language\Nominal-Subtyping.md
-E:\Wiki\2nd\10_Wiki\Topics\Programming & Language\Nominal-Typing.md
-E:\Wiki\2nd\10_Wiki\Topics\Programming & Language\Non-null Assertion Operator.md
-E:\Wiki\2nd\10_Wiki\Topics\Programming & Language\NPM Ecosystem.md
-E:\Wiki\2nd\10_Wiki\Topics\Programming & Language\Objective Distillation (목표 증류).md
-E:\Wiki\2nd\10_Wiki\Topics\Programming & Language\Operations-Management.md
-E:\Wiki\2nd\10_Wiki\Topics\Programming & Language\Organizational Behavior.md
-E:\Wiki\2nd\10_Wiki\Topics\Programming & Language\Organizational-Behavior.md
-E:\Wiki\2nd\10_Wiki\Topics\Programming & Language\Organizational-Psychology.md
-E:\Wiki\2nd\10_Wiki\Topics\Programming & Language\PageRank (페이지랭크 알고리즘).md
-E:\Wiki\2nd\10_Wiki\Topics\Programming & Language\Papers Please (Mechanics as Moral Argument).md
-E:\Wiki\2nd\10_Wiki\Topics\Programming & Language\Post-Apocalyptic Fiction.md
-E:\Wiki\2nd\10_Wiki\Topics\Programming & Language\Post-Surgical-Orthopedic-Recovery.md
-E:\Wiki\2nd\10_Wiki\Topics\Programming & Language\Procedural-Rhetoric.md
-E:\Wiki\2nd\10_Wiki\Topics\Programming & Language\Proprioception.md
-E:\Wiki\2nd\10_Wiki\Topics\Programming & Language\RDF-star (RDF 확장 사양).md
-E:\Wiki\2nd\10_Wiki\Topics\Programming & Language\React 게임 엔진 아키텍처.md
-E:\Wiki\2nd\10_Wiki\Topics\Programming & Language\readonly 수식어.md
-E:\Wiki\2nd\10_Wiki\Topics\Programming & Language\Reward Shaping (보상 설계).md
-E:\Wiki\2nd\10_Wiki\Topics\Programming & Language\Robotic-Manipulator-Dynamics.md
-E:\Wiki\2nd\10_Wiki\Topics\Programming & Language\RRF (Reciprocal Rank Fusion).md
-E:\Wiki\2nd\10_Wiki\Topics\Programming & Language\Runtime-Type-Validation.md
-E:\Wiki\2nd\10_Wiki\Topics\Programming & Language\SaaS-Product-Management.md
-E:\Wiki\2nd\10_Wiki\Topics\Programming & Language\Sandbox Simulations (eg Minecraft Dwarf Fortress).md
-E:\Wiki\2nd\10_Wiki\Topics\Programming & Language\Santa Fe Institute.md
-E:\Wiki\2nd\10_Wiki\Topics\Programming & Language\Satisfiability-Problem-(SAT).md
-E:\Wiki\2nd\10_Wiki\Topics\Programming & Language\Scavenger(마이너 GC).md
-E:\Wiki\2nd\10_Wiki\Topics\Programming & Language\Schema-Driven-Development.md
-E:\Wiki\2nd\10_Wiki\Topics\Programming & Language\Schemaorg.md
-E:\Wiki\2nd\10_Wiki\Topics\Programming & Language\Sensorimotor-Integration.md
-E:\Wiki\2nd\10_Wiki\Topics\Programming & Language\Side-channel attacks.md
-E:\Wiki\2nd\10_Wiki\Topics\Programming & Language\Signal Processing.md
-E:\Wiki\2nd\10_Wiki\Topics\Programming & Language\Simulation Theory.md
-E:\Wiki\2nd\10_Wiki\Topics\Programming & Language\Skybound Protocol 개발자 확장 가이드 및 아키텍처 리뷰.md
-E:\Wiki\2nd\10_Wiki\Topics\Programming & Language\Skybound Protocol 시스템 아키텍처 및 데이터 흐름 분석.md
-E:\Wiki\2nd\10_Wiki\Topics\Programming & Language\SOLID 원칙 (SOLID Principles).md
-E:\Wiki\2nd\10_Wiki\Topics\Programming & Language\SPARQL (RDF 그래프 질의 언어).md
-E:\Wiki\2nd\10_Wiki\Topics\Programming & Language\Spatial-Syntax.md
-E:\Wiki\2nd\10_Wiki\Topics\Programming & Language\Static-Type-Inference.md
-E:\Wiki\2nd\10_Wiki\Topics\Programming & Language\Statistical Mechanics.md
-E:\Wiki\2nd\10_Wiki\Topics\Programming & Language\System Dynamics.md
-E:\Wiki\2nd\10_Wiki\Topics\Programming & Language\Systems Dynamics.md
-E:\Wiki\2nd\10_Wiki\Topics\Programming & Language\ts-pattern.md
-E:\Wiki\2nd\10_Wiki\Topics\Programming & Language\Type Inference.md
-E:\Wiki\2nd\10_Wiki\Topics\Programming & Language\Type Narrowing.md
-E:\Wiki\2nd\10_Wiki\Topics\Programming & Language\Type Predicates.md
-E:\Wiki\2nd\10_Wiki\Topics\Programming & Language\Type-Assertion.md
-E:\Wiki\2nd\10_Wiki\Topics\Programming & Language\Type-Erasure.md
-E:\Wiki\2nd\10_Wiki\Topics\Programming & Language\Type-Inference-Algorithms.md
-E:\Wiki\2nd\10_Wiki\Topics\Programming & Language\Type-Narrowing-and-Control-Flow-Analysis.md
-E:\Wiki\2nd\10_Wiki\Topics\Programming & Language\Type-Narrowing-and-Guards.md
-E:\Wiki\2nd\10_Wiki\Topics\Programming & Language\Type-Narrowing-Mechanisms.md
-E:\Wiki\2nd\10_Wiki\Topics\Programming & Language\Type-Predicates.md
-E:\Wiki\2nd\10_Wiki\Topics\Programming & Language\TypeScript 타입 시스템 (인터페이스 설계).md
-E:\Wiki\2nd\10_Wiki\Topics\Programming & Language\TypeScript 타입 시스템 아키텍처 및 도메인 기반 설계(DDD).md
-E:\Wiki\2nd\10_Wiki\Topics\Programming & Language\TypeScript-Language-Service.md
-E:\Wiki\2nd\10_Wiki\Topics\Programming & Language\UNESCO-Memory-of-the-World.md
-E:\Wiki\2nd\10_Wiki\Topics\Programming & Language\Urban Planning Simulation.md
-E:\Wiki\2nd\10_Wiki\Topics\Programming & Language\V8 JavaScript 엔진.md
-E:\Wiki\2nd\10_Wiki\Topics\Programming & Language\V8 엔진 (V8 Engine).md
-E:\Wiki\2nd\10_Wiki\Topics\Programming & Language\V8 엔진(V8 Engine).md
-E:\Wiki\2nd\10_Wiki\Topics\Programming & Language\V8 자바스크립트 엔진.md
-E:\Wiki\2nd\10_Wiki\Topics\Programming & Language\Variable Ratio Reinforcement.md
-E:\Wiki\2nd\10_Wiki\Topics\Programming & Language\Variance-Covariance-and-Contravariance.md
-E:\Wiki\2nd\10_Wiki\Topics\Programming & Language\Variance-in-TypeScript.md
-E:\Wiki\2nd\10_Wiki\Topics\Programming & Language\Web3 Infrastructure.md
-E:\Wiki\2nd\10_Wiki\Topics\Programming & Language\Zod를 활용한 런타임 데이터 파싱.md
-E:\Wiki\2nd\10_Wiki\Topics\Programming & Language\가상현실 멀미(VR Sickness).md
-E:\Wiki\2nd\10_Wiki\Topics\Programming & Language\강화 계획.md
-E:\Wiki\2nd\10_Wiki\Topics\Programming & Language\강화 학습(Reinforcement Learning) 알고리즘.md
-E:\Wiki\2nd\10_Wiki\Topics\Programming & Language\건강 심리학.md
-E:\Wiki\2nd\10_Wiki\Topics\Programming & Language\건강 행동 변화 모델.md
-E:\Wiki\2nd\10_Wiki\Topics\Programming & Language\게임 디자인 이론 및 구조론.md
-E:\Wiki\2nd\10_Wiki\Topics\Programming & Language\게임 디자인의 보상 루프(Reward Loop) 설계.md
-E:\Wiki\2nd\10_Wiki\Topics\Programming & Language\게임 루프 설계.md
-E:\Wiki\2nd\10_Wiki\Topics\Programming & Language\게임 행동 심리학.md
-E:\Wiki\2nd\10_Wiki\Topics\Programming & Language\게임학(Ludology) vs 서사학(Narratology) 논쟁.md
-E:\Wiki\2nd\10_Wiki\Topics\Programming & Language\고전적 조건 형성.md
-E:\Wiki\2nd\10_Wiki\Topics\Programming & Language\공존 질환 (Comorbidity).md
-E:\Wiki\2nd\10_Wiki\Topics\Programming & Language\과잉 정당화 효과 (Overjustification Effect).md
-E:\Wiki\2nd\10_Wiki\Topics\Programming & Language\광범위한 신경과학적 연합 기제.md
-E:\Wiki\2nd\10_Wiki\Topics\Programming & Language\교육 심리학에서의 학습 동기 유도.md
-E:\Wiki\2nd\10_Wiki\Topics\Programming & Language\교육 심리학에서의 학습 동기 유발.md
-E:\Wiki\2nd\10_Wiki\Topics\Programming & Language\교집합 타입 (Intersection Types).md
-E:\Wiki\2nd\10_Wiki\Topics\Programming & Language\구조적 타이핑 (Structural Typing).md
-E:\Wiki\2nd\10_Wiki\Topics\Programming & Language\내재적 동기 (Intrinsic Motivation).md
-E:\Wiki\2nd\10_Wiki\Topics\Programming & Language\내재적 동기 vs 외재적 동기.md
-E:\Wiki\2nd\10_Wiki\Topics\Programming & Language\네버 타입 (never type).md
-E:\Wiki\2nd\10_Wiki\Topics\Programming & Language\넷플릭스 코스모스 플랫폼 (Netflix Cosmos Platform).md
-E:\Wiki\2nd\10_Wiki\Topics\Programming & Language\뇌 가소성 (Neuroplasticity).md
-E:\Wiki\2nd\10_Wiki\Topics\Programming & Language\대규모 로그 뷰어 및 데이터 테이블 구현.md
-E:\Wiki\2nd\10_Wiki\Topics\Programming & Language\대규모 애플리케이션 개발.md
-E:\Wiki\2nd\10_Wiki\Topics\Programming & Language\도메인 기반 설계(DDD)의 식별자 분리.md
-E:\Wiki\2nd\10_Wiki\Topics\Programming & Language\동기강화 상담(Motivational Interviewing).md
-E:\Wiki\2nd\10_Wiki\Topics\Programming & Language\디지털 미학(Digital Aesthetics).md
-E:\Wiki\2nd\10_Wiki\Topics\Programming & Language\루도-내러티브 부조화(Ludonarrative Dissonance).md
-E:\Wiki\2nd\10_Wiki\Topics\Programming & Language\린터 (Linter).md
-E:\Wiki\2nd\10_Wiki\Topics\Programming & Language\마이너 가비지 컬렉션(Minor GC).md
-E:\Wiki\2nd\10_Wiki\Topics\Programming & Language\마이크로서비스 아키텍처.md
-E:\Wiki\2nd\10_Wiki\Topics\Programming & Language\마크-컴팩트(Mark-Compact).md
-E:\Wiki\2nd\10_Wiki\Topics\Programming & Language\머리 착용 디스플레이(HMD) 시각 연구.md
-E:\Wiki\2nd\10_Wiki\Topics\Programming & Language\메모리 단편화(Fragmentation).md
-E:\Wiki\2nd\10_Wiki\Topics\Programming & Language\메모리 파편화 방지 및 객체 풀링 (Object Pooling).md
-E:\Wiki\2nd\10_Wiki\Topics\Programming & Language\몰입 (Flow Theory).md
-E:\Wiki\2nd\10_Wiki\Topics\Programming & Language\미디어 폭력과 공격성 연구.md
-E:\Wiki\2nd\10_Wiki\Topics\Programming & Language\번아웃 및 직무 스트레스.md
-E:\Wiki\2nd\10_Wiki\Topics\Programming & Language\범이론적 모델(Transtheoretical Model).md
-E:\Wiki\2nd\10_Wiki\Topics\Programming & Language\보상 예측 오류 (Reward Prediction Error).md
-E:\Wiki\2nd\10_Wiki\Topics\Programming & Language\보조 공학 (Assistive Technology).md
-E:\Wiki\2nd\10_Wiki\Topics\Programming & Language\브라우저 DOM 누수 탐지 및 렌더링 최적화.md
-E:\Wiki\2nd\10_Wiki\Topics\Programming & Language\브라우저 메모리 할당 시점별 힙(Heap) 동작 상세 로그.md
-E:\Wiki\2nd\10_Wiki\Topics\Programming & Language\브랜디드 타입(Branded Types).md
-E:\Wiki\2nd\10_Wiki\Topics\Programming & Language\브랜디드 타입.md
-E:\Wiki\2nd\10_Wiki\Topics\Programming & Language\비트 세이버(Beat Saber) VR 엑서게임 연구.md
-E:\Wiki\2nd\10_Wiki\Topics\Programming & Language\사회 학습 이론.md
-E:\Wiki\2nd\10_Wiki\Topics\Programming & Language\사회학습이론.md
-E:\Wiki\2nd\10_Wiki\Topics\Programming & Language\생물학적 학습 이론.md
-E:\Wiki\2nd\10_Wiki\Topics\Programming & Language\서버리스 컴퓨팅(Serverless Computing).md
-E:\Wiki\2nd\10_Wiki\Topics\Programming & Language\성장 마인드셋 (Growth Mindset).md
-E:\Wiki\2nd\10_Wiki\Topics\Programming & Language\성장 마인드셋(Growth Mindset).md
-E:\Wiki\2nd\10_Wiki\Topics\Programming & Language\세대별 가설(Generational Hypothesis).md
-E:\Wiki\2nd\10_Wiki\Topics\Programming & Language\습관 교정 프로그램.md
-E:\Wiki\2nd\10_Wiki\Topics\Programming & Language\시맨틱 웹 (Semantic Web).md
-E:\Wiki\2nd\10_Wiki\Topics\Programming & Language\시스템 다이내믹스 (System Dynamics).md
-E:\Wiki\2nd\10_Wiki\Topics\Programming & Language\식별 가능한 유니온 (Discriminated Unions).md
-E:\Wiki\2nd\10_Wiki\Topics\Programming & Language\신경 가소성 (Neuroplasticity).md
-E:\Wiki\2nd\10_Wiki\Topics\Programming & Language\심리적 계약 (Psychological Contract).md
-E:\Wiki\2nd\10_Wiki\Topics\Programming & Language\심리적 안전감 (Psychological Safety).md
-E:\Wiki\2nd\10_Wiki\Topics\Programming & Language\애자일 방법론 (Agile Methodology).md
-E:\Wiki\2nd\10_Wiki\Topics\Programming & Language\양가감정(Ambivalence).md
-E:\Wiki\2nd\10_Wiki\Topics\Programming & Language\에르고딕 문학(Ergodic Literature).md
-E:\Wiki\2nd\10_Wiki\Topics\Programming & Language\오탐 (False Positive).md
-E:\Wiki\2nd\10_Wiki\Topics\Programming & Language\완전성 검사 (Exhaustiveness Checking).md
-E:\Wiki\2nd\10_Wiki\Topics\Programming & Language\유기적 통합 이론 (Organismic Integration Theory).md
-E:\Wiki\2nd\10_Wiki\Topics\Programming & Language\유능감 및 자율성 욕구.md
-E:\Wiki\2nd\10_Wiki\Topics\Programming & Language\유니언 타입 식별 및 상태 분기 처리.md
-E:\Wiki\2nd\10_Wiki\Topics\Programming & Language\의사결정 속도(Decision Speed).md
-E:\Wiki\2nd\10_Wiki\Topics\Programming & Language\인문학적 게임 비평 및 서사학12.md
-E:\Wiki\2nd\10_Wiki\Topics\Programming & Language\임베딩 (Embedding).md
-E:\Wiki\2nd\10_Wiki\Topics\Programming & Language\임상 심리학의 변화 동기 치료.md
-E:\Wiki\2nd\10_Wiki\Topics\Programming & Language\자기결정성 이론 (SDT).md
-E:\Wiki\2nd\10_Wiki\Topics\Programming & Language\자기결정성 이론 (Self-Determination Theory).md
-E:\Wiki\2nd\10_Wiki\Topics\Programming & Language\자율성 지지 (Autonomy Support).md
-E:\Wiki\2nd\10_Wiki\Topics\Programming & Language\자폐 스펙트럼 장애(ASD) 중재.md
-E:\Wiki\2nd\10_Wiki\Topics\Programming & Language\전두엽 기능 저하 (Hypofrontality).md
-E:\Wiki\2nd\10_Wiki\Topics\Programming & Language\절차적 수사학(Procedural Rhetoric).md
-E:\Wiki\2nd\10_Wiki\Topics\Programming & Language\정서적 고전적 조건 형성 (Emotional Classical Conditioning).md
-E:\Wiki\2nd\10_Wiki\Topics\Programming & Language\정신 의학적 진단 체계 (DSM-5_ICD-11).md
-E:\Wiki\2nd\10_Wiki\Topics\Programming & Language\조작적 조건 형성 (Operant Conditioning).md
-E:\Wiki\2nd\10_Wiki\Topics\Programming & Language\조작적 조건 형성.md
-E:\Wiki\2nd\10_Wiki\Topics\Programming & Language\조작적 조건형성.md
-E:\Wiki\2nd\10_Wiki\Topics\Programming & Language\조직 개발(OD) 프로그램 설계.md
-E:\Wiki\2nd\10_Wiki\Topics\Programming & Language\조직 행동 관리(OBM).md
-E:\Wiki\2nd\10_Wiki\Topics\Programming & Language\조직 행동론 및 직무 만족도 연구.md
-E:\Wiki\2nd\10_Wiki\Topics\Programming & Language\중뇌-변연계 경로 (Mesolimbic Pathway).md
-E:\Wiki\2nd\10_Wiki\Topics\Programming & Language\지식 그래프 (Knowledge Graph).md
-E:\Wiki\2nd\10_Wiki\Topics\Programming & Language\직무 특성 모델 (Job Characteristics Model).md
-E:\Wiki\2nd\10_Wiki\Topics\Programming & Language\추론 엔진 (Semantic Reasoner).md
-E:\Wiki\2nd\10_Wiki\Topics\Programming & Language\커뮤니티 탐지 (Community Detection).md
-E:\Wiki\2nd\10_Wiki\Topics\Programming & Language\코드 스타일로메트리 (Code Stylometry).md
-E:\Wiki\2nd\10_Wiki\Topics\Programming & Language\코스모스(Cosmos).md
-E:\Wiki\2nd\10_Wiki\Topics\Programming & Language\하이브리드 검색 (Hybrid Search).md
-E:\Wiki\2nd\10_Wiki\Topics\Programming & Language\행동 경제학의 인센티브 구조 설계.md
-E:\Wiki\2nd\10_Wiki\Topics\Programming & Language\행동 경제학의 학습 이론.md
-E:\Wiki\2nd\10_Wiki\Topics\Programming & Language\행동 수정 기법.md
-E:\Wiki\2nd\10_Wiki\Topics\Programming & Language\행동주의 심리학 (Behaviorism).md
-E:\Wiki\2nd\10_Wiki\Topics\Programming & Language\행동주의 심리학.md
-E:\Wiki\2nd\10_Wiki\Topics\Programming & Language\회복탄력성 (Resilience).md
-E:\Wiki\2nd\10_Wiki\Topics\Psychology & Behavior\Agent-Based Modeling.md
-E:\Wiki\2nd\10_Wiki\Topics\Psychology & Behavior\Agent-Based-Modeling.md
-E:\Wiki\2nd\10_Wiki\Topics\Psychology & Behavior\보상의 역효과 (Overjustification Effect).md
-E:\Wiki\2nd\10_Wiki\Topics\Security\Formal-Methods-in-Software-Engineering.md
-E:\Wiki\2nd\10_Wiki\Topics\Software Architecture\Deterministic Lockstep Architecture.md
-E:\Wiki\2nd\10_Wiki\Topics\Software Architecture\Hello Games Development Lifecycle.md
-E:\Wiki\2nd\10_Wiki\Topics\Software Architecture\Nudge Theory.md
-E:\Wiki\2nd\10_Wiki\Topics\Software Architecture\Sports Management Theory.md
-E:\Wiki\2nd\10_Wiki\Topics\Software Architecture\Throttling  Debouncing (스로틀링과 디바운싱).md
diff --git a/src/TetrisGame.jsx b/src/TetrisGame.jsx
deleted file mode 100644
index e24ca092..00000000
--- a/src/TetrisGame.jsx
+++ /dev/null
@@ -1,97 +0,0 @@
-import React, { useState, useEffect, useCallback } from 'react';
-
-const TetrisGame = () => {
-    // [State Management] 전역 상태: 보드와 현재 블록 정보를 저장합니다.
-    const [gameState, setGameState] = useState({ board: [], piece: null });
-    const [workerStatus, setWorkerStatus] = useState("Initializing...");
-
-    useEffect(() => {
-        // 1. Web Worker 초기화 및 통신 설정
-        const worker = new Worker(new URL('./gameWorker.js', import.meta.url), { type: 'module' });
-        setWorkerStatus("Running...");
-
-        // 2. 워커로부터 메시지를 수신할 리스너 등록 (Web Worker의 핵심)
-        worker.onmessage = (e) => {
-            const data = e.data;
-            if (data.type === 'READY' || data.type === 'UPDATE') {
-                // 받은 데이터를 전역 상태로 업데이트합니다. (Single Source of Truth 원칙 준수)
-                setGameState({ board: data.board, piece: data.piece });
-            } else if (data.type === 'ERROR') {
-                 console.error("Game Worker Error:", data.message);
-            }
-        };
-
-        // 3. 워커에 초기화 명령 전송 (Worker 시작)
-        worker.postMessage({ type: 'INIT' });
-
-        // Cleanup 함수: 컴포넌트 언마운트 시 워커를 종료합니다.
-        return () => {
-            worker.terminate();
-        };
-    }, []); // 마운트 시 한 번만 실행 (useEffect)
-
-
-    // [Game Loop] 게임 루프 관리 (핵심 성능 최적화 부분)
-    const handleGameLoop = useCallback(() => {
-        if (!gameState.piece) return;
-
-        // 1초에 1번씩 gravity step을 요청합니다.
-        const worker = new Worker(new URL('./gameWorker.js', import.meta.url), { type: 'module' });
-        worker.postMessage({ type: 'MOVE_STEP', payload: {} });
-        
-        // 다음 프레임에서 다시 이 함수를 호출하여 지속적인 움직임을 만듭니다.
-        requestAnimationFrame(handleGameLoop); 
-    }, [gameState.piece]); // piece가 있을 때만 루프 시작
-
-    useEffect(() => {
-        if (gameState.piece) {
-            const animationFrameId = requestAnimationFrame(handleGameLoop);
-            return () => cancelAnimationFrame(animationFrameId);
-        }
-    }, [gameState.piece, handleGameLoop]);
-
-
-    // 렌더링 로직: 게임 보드와 블록을 시각화합니다.
-    const renderBoard = () => {
-        return (
-            <div style={styles.board}>
-                {/* React는 배열의 배열을 순회하며 각 셀에 CSS 클래스를 적용하여 렌더링합니다. */}
-                {gameState.board.map((row, y) => (
-                    <div key={y} style={{ display: 'flex' }}>
-                        {row.map((cell, x) => (
-                            <div 
-                                key={`${x}-${y}`} 
-                                style={cell > 0 ? styles.occupied : {}} 
-                                title={`(${x}, ${y})`}
-                            ></div>
-                        ))}
-                    </div>
-                ))}
-            </div>
-        );
-    };
-
-    return (
-        <div style={styles.container}>
-            <h1>Tetris Clone: High-Performance Engine</h1>
-            <p>Status: {workerStatus}</p>
-            {renderBoard()}
-            <button onClick={() => console.log("Game Controls Here!")} disabled={!gameState.piece}>
-                (이동/회전 버튼)
-            </button>
-        </div>
-    );
-};
-
-const styles = {
-    container: { padding: '20px', fontFamily: 'Arial, sans-serif' },
-    board: { 
-        display: 'flex', 
-        flexDirection: 'column', 
-        border: '4px solid #333', 
-        width: '250px' 
-    },
-    occupied: { backgroundColor: '#ccc', border: '1px solid #aaa' }
-};
-
-export default TetrisGame;
\ No newline at end of file
diff --git a/src/gameWorker.js b/src/gameWorker.js
deleted file mode 100644
index 9633e184..00000000
--- a/src/gameWorker.js
+++ /dev/null
@@ -1,73 +0,0 @@
-/**
- * @file Web Worker: Tetris Game Logic Engine (The Core Rulebook)
- * 이 파일은 메인 스레드와 분리되어 실행되며, 게임의 모든 물리적 규칙을 처리합니다.
- */
-
-let gameBoard = []; // 20x10 Grid representation
-const BOARD_WIDTH = 10;
-const BOARD_HEIGHT = 20;
-
-// 초기 보드 상태 설정 (빈 공간)
-function initializeBoard() {
-    gameBoard = Array(BOARD_HEIGHT).fill(null).map(() => Array(BOARD_WIDTH).fill(0));
-}
-
-// 블록 생성 로직 (랜덤 모양, 랜덤 위치)
-function generatePiece() {
-    // 실제로는 다양한 T, L, I, O 등의 형태를 정의해야 함. 여기서는 단순 예시로 대체합니다.
-    return { shape: [/* 4x4 matrix for a piece */], color: Math.random(), x: Math.floor(Math.random() * (BOARD_WIDTH - 3)), y: 0 };
-}
-
-// 충돌 감지 로직 (Collision Detection)
-function checkCollision(piece, newX, newY) {
-    for (let row = 0; row < piece.shape.length; row++) {
-        for (let col = 0; col < piece.shape[row].length; col++) {
-            if (piece.shape[row][col] !== 0) {
-                const boardX = newX + col;
-                const boardY = newY + row;
-
-                // 경계 체크 또는 이미 블록이 있는 경우 충돌 발생
-                if (boardX < 0 || boardX >= BOARD_WIDTH || boardY >= BOARD_HEIGHT || gameBoard[boardY][boardX] !== 0) {
-                    return true; // Collision detected
-                }
-            }
-        }
-    }
-    return false;
-}
-
-// 게임의 핵심 로직: 한 스텝 진행 (Gravity Step)
-function movePiece(dx, dy) {
-    let newX = piece.x + dx;
-    let newY = piece.y + dy;
-
-    if (!checkCollision(piece, newX, newY)) {
-        // 1. 상태 업데이트: 보드의 좌표와 블록을 이동시킵니다.
-        // 2. 충돌 체크 및 고정: 바닥 또는 다른 블록에 닿으면, 해당 위치를 게임 보드에 영구적으로 기록합니다.
-        // 3. 라인 제거 (Line Clearing): 가득 찬 행(Row)을 찾아 지우고 위쪽 행들을 아래로 떨어뜨립니다.
-        return { success: true, board: [...gameBoard], piece: {...piece} };
-    } else {
-        return { success: false, message: "Collision" };
-    }
-}
-
-// 메인 게임 루프 (Game Loop)
-self.onmessage = function(e) {
-    const { type, payload } = e.data;
-
-    switch (type) {
-        case 'INIT':
-            initializeBoard();
-            // 초기 블록 생성 및 상태 전송
-            self.postMessage({ type: 'READY', board: gameBoard, piece: generatePiece() });
-            break;
-        case 'MOVE_STEP':
-            // 실제 게임 루프의 핵심 로직 호출
-            const result = movePiece(payload.dx || 0, payload.dy || 1);
-            self.postMessage({ type: 'UPDATE', board: result.board, piece: result.piece });
-            break;
-        case 'ROTATE':
-             // 블록 회전 로직 구현 (Omitted for brevity)
-             break;
-    }
-};
\ No newline at end of file
diff --git a/src/hooks/useGameLogic.js b/src/hooks/useGameLogic.js
deleted file mode 100644
index daa3de09..00000000
--- a/src/hooks/useGameLogic.js
+++ /dev/null
@@ -1,110 +0,0 @@
-/**
- * Custom Hook: 웹 워커를 사용하여 고성능 게임 로직을 관리합니다.
- * 이 훅은 React의 상태(State)와 생명 주기(Lifecycle)를 이용하여 Web Worker와의 통신을 담당합니다.
- * @returns {{ grid: Array<Array<number>>, score: number, isGameRunning: boolean, moveLeft: Function, moveRight: Function, rotate: Function }}
- */
-
-import { useState, useEffect, useCallback } from 'react';
-
-// 🚨 주의: 실제 프로젝트 구조에 따라 경로를 수정해야 합니다.
-const worker = new Worker(new URL('../tetris-worker.js', import.meta.url), { type: 'module' });
-
-/**
- * Web Worker 기반의 Tetris 게임 로직을 관리하는 커스텀 훅.
- */
-export const useGameLogic = () => {
-    // 초기 상태 설정 (Worker가 INIT 메시지를 보낼 때까지 대기)
-    const [grid, setGrid] = useState([]);
-    const [score, setScore] = useState(0);
-    const [isGameRunning, setIsGameRunning] = useState(false);
-
-    /**
-     * 🌐 Worker로부터 메시지 수신 처리 핸들러
-     */
-    useEffect(() => {
-        // 워커가 로드되었을 때의 리스너 설정
-        worker.onmessage = (event) => {
-            const data = event.data;
-
-            switch (data.type) {
-                case 'READY':
-                    console.log("Worker is ready. Game initialized.");
-                    // 워커가 준비되면 게임 시작 플래그를 활성화할 수 있습니다.
-                    setIsGameRunning(true); 
-                    break;
-                case 'INIT':
-                    setGrid(data.data.grid);
-                    setScore(data.data.score);
-                    console.log("Game initialized successfully.");
-                    // 게임 시작 후 첫 번째 메시지 처리 완료
-                    break;
-                case 'UPDATE':
-                    // 핵심 상태 업데이트: Worker가 계산한 새로운 그리드와 점수
-                    setGrid(data.data.grid);
-                    setScore(data.data.score);
-                    console.log("Game state updated via worker.");
-                    break;
-                default:
-                    console.warn('Unknown message type received from worker:', data.type);
-            }
-        };
-
-        // 컴포넌트 언마운트 시 워커 종료 (메모리 누수 방지)
-        return () => {
-            worker.terminate();
-        };
-    }, []);
-
-
-    /**
-     * ⬅️ 이동 로직 호출 (좌측 이동)
-     */
-    const moveLeft = useCallback(() => {
-        if (!isGameRunning) return;
-        // Web Worker에게 명령 전송: 충돌 검사 및 상태 업데이트는 워커 내부에서 처리됨.
-        worker.postMessage({ type: 'MOVE_LEFT', command: 'left' });
-    }, [isGameRunning]);
-
-    /**
-     * ➡️ 이동 로직 호출 (우측 이동)
-     */
-    const moveRight = useCallback(() => {
-        if (!isGameRunning) return;
-        worker.postMessage({ type: 'MOVE_RIGHT', command: 'right' });
-    }, [isGameRunning]);
-
-    /**
-     * 🔄 회전 로직 호출
-     */
-    const rotate = useCallback(() => {
-        if (!isGameRunning) return;
-        worker.postMessage({ type: 'ROTATE', command: 'rotate' });
-    }, [isGameRunning]);
-    
-    /**
-     * ⬇️ 게임 틱 시작 (게임 루프 시작)
-     */
-    const startGameTick = useCallback(() => {
-        if (!isGameRunning) {
-            // 초기화 메시지 전송 (혹시 모를 재설정을 위해)
-            worker.postMessage({ type: 'INIT' });
-            // 게임 틱을 시작하는 명령 전송
-            setTimeout(() => {
-                worker.postMessage({ type: 'TICK' });
-            }, 50); // 약간의 딜레이 후 첫 틱 실행
-        }
-    }, [isGameRunning]);
-
-
-    return {
-        grid, 
-        score, 
-        isGameRunning, 
-        moveLeft, 
-        moveRight, 
-        rotate, 
-        startGameTick
-    };
-};
-
-export default useGameLogic;
\ No newline at end of file
diff --git a/src/tetris-worker.js b/src/tetris-worker.js
deleted file mode 100644
index b42edc6c..00000000
--- a/src/tetris-worker.js
+++ /dev/null
@@ -1,82 +0,0 @@
-/**
- * Web Worker 파일: Tetris의 모든 무거운 계산(Game Loop, 물리 엔진)을 전담합니다.
- */
-
-// 게임 그리드 상수 정의 (20줄 x 10칸)
-const GRID_WIDTH = 10;
-const GRID_HEIGHT = 20;
-let gridState = []; // 현재 게임 상태를 저장하는 2차원 배열
-let score = 0;
-
-/**
- * 초기화 함수: 워커가 로드될 때 호출됩니다.
- */
-function initializeGame() {
-    // 빈 그리드로 초기화
-    gridState = Array(GRID_HEIGHT).fill(null).map(() => Array(GRID_WIDTH).fill(0));
-    score = 0;
-
-    postMessage({ 
-        type: 'INIT', 
-        data: { grid: gridState, score: score } 
-    });
-}
-
-/**
- * 게임 루프 (Game Tick) 시뮬레이션 함수.
- * 이 함수가 주기적으로 호출되어 중력과 충돌을 처리합니다.
- */
-function gameTick() {
-    // TODO: 1. 현재 떨어지는 조각(Current Piece)의 위치를 파악하고,
-    // TODO: 2. 아래 칸이 막혔는지 (충돌 판정), 막혔다면 그릴 그리드 상태를 업데이트해야 합니다.
-
-    // 임시 로직: 모든 셀을 한 번씩 '낙하'시키는 시뮬레이션
-    let newGridState = JSON.parse(JSON.stringify(gridState)); // 깊은 복사
-    for (let y = GRID_HEIGHT - 2; y >= 0; y--) {
-        for (let x = 0; x < GRID_WIDTH; x++) {
-            // 예시: 현재 칸에 무언가 있다면, 한 줄 아래로 내려갑니다.
-            if (gridState[y][x] !== 0) {
-                newGridState[y + 1][x] = gridState[y][x]; // 다음 위치에 복사
-                newGridState[y][x] = 0; // 현재 위치는 비움
-            }
-        }
-    }
-
-    gridState = newGridState;
-    
-    // TODO: 라인 클리어 체크 및 점수 계산 로직 추가
-    const linesCleared = 1; // 예시 값
-    if (linesCleared > 0) {
-        score += linesCleared * 100;
-    }
-
-    postMessage({ 
-        type: 'UPDATE', 
-        data: { grid: gridState, score: score } 
-    });
-}
-
-
-// Web Worker 이벤트 리스너 설정 (메인 스레드로부터 메시지 수신)
-self.onmessage = function(event) {
-    const data = event.data;
-
-    switch (data.type) {
-        case 'INIT':
-            initializeGame();
-            break;
-        case 'MOVE_LEFT':
-        case 'MOVE_RIGHT':
-        case 'ROTATE':
-        case 'HARD_DROP':
-            // TODO: 이동/회전 로직 구현 및 충돌 검사 후 상태 업데이트
-            console.log(`Received move command: ${data.command}`);
-            break;
-        case 'TICK':
-            gameTick(); // 게임 틱 실행
-            break;
-    }
-};
-
-// 초기 메시지 전송 (워커가 로드되었음을 알림)
-self.postMessage({ type: 'READY' });
\ No newline at end of file