chore: extend specialized knowledge categories with additional mapping

2026-04-25 22:45:06 +09:00
parent e4f5a3b7bd
commit 44f1f2140b
20 changed files with 556 additions and 0 deletions
@@ -0,0 +1,60 @@
+# Datacollector - 인증 복구 후 자동 재개 상태 전환 수정
+
+- 작성 시각: 2026-04-25 22:39:30 KST
+- 프로젝트: `/Volumes/Data/project/Antigravity/Datacollector`
+- 관련 파일: `src/components/AgentDashboard.tsx`, `src/lib/engine.ts`
+
+## 상황
+
+NotebookLM 인증 복구 로직을 강화했지만, 화면에서는 여전히 `CONTINUE MISSION` 버튼을 사용자가 눌러야 다음 큐가 이어지는 것처럼 보였다.
+
+사용자 관찰:
+
+- 작업은 일부 완료됨.
+- 큐에는 아직 작업이 많이 남아 있음.
+- 헤더 상태가 `IDLE`로 보임.
+- `CONTINUE MISSION` 버튼이 사용자의 수동 클릭을 기다림.
+
+## 원인
+
+프론트엔드 상태 전환에 빈틈이 있었다.
+
+`AgentDashboard`의 `useEffect`는 `status !== 'running'`일 때 `KnowledgeEngine.stop()`을 호출한다. 그런데 기존 `stop()`은 내부 실행 플래그만 끄는 것이 아니라 항상 Zustand 상태까지 `idle`로 바꿨다.
+
+그 결과 인증 오류 등으로 `paused` 상태를 유지해야 하는 경우에도 React effect를 지나면서 `paused -> idle`로 바뀌었다. 이렇게 되면 앱은 "복구 후 자동 재개 가능한 일시정지"가 아니라 "사용자가 다시 Continue를 눌러야 하는 대기 상태"처럼 동작했다.
+
+## 조치
+
+`src/lib/engine.ts`:
+
+- `stop(updateStatus = true)` 형태로 변경했다.
+- 내부 엔진만 멈춰야 할 때는 UI 상태를 덮어쓰지 않도록 했다.
+
+`src/components/AgentDashboard.tsx`:
+
+- `status !== 'running'` effect에서는 `engine.stop(false)`를 호출하도록 변경했다.
+- `status === 'paused'`이고 큐가 남아 있으면 NotebookLM 연결 확인 후 자동으로 `running`으로 되돌리는 auto-resume effect를 추가했다.
+- 기존 버그로 이미 `idle`에 갇힌 화면도 구제하기 위해, 수동 정지나 작업 완료 로그가 없는 `idle + 남은 큐` 상태도 복구 가능한 멈춤으로 보고 자동 재개하도록 보강했다.
+- 중복 자동 재개를 막기 위해 `autoResumeRef` 잠금을 추가했다.
+
+## 검증
+
+다음 검증을 완료했다.
+
+```bash
+npm run lint
+curl -sS -I http://127.0.0.1:3000
+curl -sS -X POST http://127.0.0.1:3002/api/check-connection
+```
+
+결과:
+
+- TypeScript 검사 통과
+- 프론트엔드 서버 응답 정상
+- NotebookLM 브리지 연결 확인 `success: true`
+
+## 운영 메모
+
+앞으로 인증 복구나 연결 복구로 인해 `paused` 상태가 되면 앱이 NotebookLM 연결을 확인하고 자동으로 다음 큐를 이어서 실행한다.
+
+사용자가 직접 `STOP / PAUSE`를 누른 경우는 기존처럼 `idle`로 유지되므로, 수동 정지는 자동 재개 대상이 아니다.
@@ -0,0 +1,32 @@
+# [[브라우저 렌더링 과정 최적화 및 UI 반응성 개선]]
+
+## 📌 Brief Summary
+브라우저 렌더링 과정은 브라우저가 HTML, CSS, JavaScript를 파싱하여 DOM과 CSSOM을 구축하고, 이를 기반으로 렌더 트리를 생성한 뒤 화면에 픽셀을 그리는 일련의 경로(Critical Rendering Path)를 의미합니다 [1, 2]. 이 과정에서 발생하는 불필요한 레이아웃 재계산(Reflow)과 화면 다시 그리기(Repaint)는 성능을 저하시키는 주요 원인이 되므로 이를 최소화하는 것이 필수적입니다 [3-6]. 현대의 프론트엔드 환경에서는 이러한 비용을 줄이고 UI 반응성을 극대화하기 위해 React의 Virtual DOM, Fiber 아키텍처, 자동 배칭(Automatic Batching), 그리고 React Compiler와 같은 고도화된 최적화 기술들이 활용되고 있습니다 [7-11].
+
+## 📖 Core Content
+
+**1. 브라우저 렌더링의 핵심 경로 (Critical Rendering Path)**
+*   **파싱 및 트리 구축:** 브라우저는 서버로부터 받은 HTML을 점진적으로 파싱하여 문서의 구조를 나타내는 DOM(Document Object Model) 트리를 구축합니다 [1, 12-14]. 동시에 CSS를 파싱하여 스타일 정보를 담은 CSSOM(CSS Object Model) 트리를 생성하는데, CSSOM은 구축이 완료될 때까지 렌더링을 차단(Render-blocking)하는 특성을 가집니다 [15, 16].
+*   **렌더 트리(Render Tree) 생성:** DOM과 CSSOM이 준비되면, 브라우저는 화면에 시각적으로 표시될 노드들만 모아 렌더 트리를 합성합니다 [2, 17, 18]. (`<script>` 태그나 `display: none` 스타일이 적용된 요소는 제외됩니다 [17, 18].)
+*   **레이아웃(Layout)과 페인트(Paint):** 렌더 트리를 기반으로 기기 뷰포트에 맞춰 각 요소의 정확한 크기와 위치를 계산하는 레이아웃 과정을 거칩니다 [19-22]. 이후 변환된 기하학적 정보를 실제 화면의 픽셀로 변환하여 그리는 페인트(Paint) 단계와, 레이어들을 하나로 합치는 합성(Compositing) 단계가 수행됩니다 [23-25].
+
+**2. 리플로우(Reflow)와 리페인트(Repaint) 최소화**
+*   **성능 비용:** 요소의 너비, 높이, 마진 등을 변경하거나 DOM 구조를 조작하면, 브라우저는 레이아웃을 다시 계산하는 리플로우(Reflow)를 발생시킵니다 [5, 19, 26]. 리플로우는 트리 전체에 걸쳐 연쇄적인 재계산을 유발할 수 있어 연산 비용이 매우 높습니다 [3, 5, 27]. 배경색이나 가시성 등 시각적 요소만 변경될 때는 레이아웃 단계 없이 리페인트(Repaint)만 발생하지만, 이 역시 과도하면 프레임 저하를 초래합니다 [6, 23, 26].
+*   **최적화 방법:** 불필요한 DOM 깊이를 줄이고 [28], DOM 상태 업데이트를 일괄 처리(Batching)하며 [3, 29], 애니메이션에는 레이아웃을 유발하지 않고 GPU 가속을 활용할 수 있는 `transform` 등의 속성을 사용하는 것이 권장됩니다 [6, 23, 29].
+
+**3. React의 렌더링 최적화 아키텍처**
+*   **Virtual DOM과 재조정(Reconciliation):** DOM을 직접 조작하는 것은 느리기 때문에, React는 메모리에 가벼운 Virtual DOM을 유지합니다 [10, 30]. 상태 변경 시 새로운 Virtual DOM 트리를 만들고 이전 트리와 비교(Diffing)하는 휴리스틱 $O(n)$ 알고리즘을 통해, 실제 변경된 부분만 실제 DOM에 반영하여 리플로우와 리페인트를 최소화합니다 [10, 30-32].
+*   **Fiber 아키텍처와 동시성(Concurrent) 기능:** React 16부터 도입된 Fiber는 렌더링 작업을 'Fiber 노드' 단위로 쪼개어 중단 및 재개가 가능하게 만든 스케줄링 아키텍처입니다 [33-36]. 사용자 입력과 같은 긴급한 작업(Sync Lane)을 데이터 페칭 결과 등 덜 긴급한 작업보다 우선 처리함으로써 메인 스레드 차단을 막고 UI 반응성을 유지합니다 [37-39]. 이를 활용한 `useTransition` 훅 등은 무거운 연산 중에도 UI가 멈추지 않게 돕습니다 [7, 40, 41].
+
+**4. 최신 React(18, 19)의 자동화된 성능 개선**
+*   **자동 배칭(Automatic Batching):** React 18부터는 네이티브 이벤트뿐만 아니라 비동기 작업(Promise, `setTimeout` 등) 내에서 발생하는 여러 상태 업데이트를 단일 리렌더링으로 묶어서 처리(Batching)합니다 [8, 42-44]. 이를 통해 불필요한 리렌더링 횟수를 대폭 줄여 성능을 크게 향상시킵니다 [45, 46].
+*   **React Compiler:** 잦은 리렌더링을 막기 위해 과거에는 개발자가 수동으로 `React.memo`, `useMemo`, `useCallback` 등을 적용해야 했습니다 [9, 47]. 하지만 React 19 컴파일러는 빌드 타임에 코드(AST)를 분석하여 데이터 흐름을 추적하고, 필요한 곳에 자동으로 세밀한 메모이제이션을 삽입해 개발자의 부담을 줄이고 렌더링을 최적화합니다 [9, 48-50].
+*   **React Server Components (RSC):** 클라이언트 번들 크기와 파싱/실행 시간을 줄이기 위해, 서버에서 컴포넌트를 렌더링하고 직렬화된 UI 표현만 브라우저로 스트리밍하는 구조입니다 [51-53]. 인터랙션이 필요 없는 UI를 서버 컴포넌트로 분리함으로써, 브라우저가 처리해야 할 자바스크립트 양을 줄여 로딩 속도와 INP(Interaction to Next Paint) 지표를 개선합니다 [54-56].
+
+## 🔗 Knowledge Connections
+- **Related Topics:** [[Critical Rendering Path]], [[Reflow and Repaint]], [[Virtual DOM]], [[React Fiber Architecture]], [[Automatic Batching]], [[React Compiler]], [[React Server Components]]
+- **Projects/Contexts:** [[Core Web Vitals Optimization (INP, LCP 개선)]], [[Next.js 기반의 Hybrid Rendering (SSR/CSR/RSC 혼합 적용)]]
+- **Contradictions/Notes:** CSS 선택자의 성능 최적화와 관련해, MDN 가이드에서는 브라우저가 매우 빠르기 때문에 선택자 성능 최적화(예: 특정성을 낮추는 작업)가 가져오는 이득이 마이크로초 단위에 불과하여 최우선 최적화 대상이 아닐 수 있다고 언급하지만 [57], 다른 구글 개발자 가이드에서는 불필요하게 복잡한 하위(descendant) 선택자를 피하는 것을 리플로우/렌더링 시간 단축을 위한 주요 지침 중 하나로 제시하고 있습니다 [28, 58].
+
+---
+*Last updated: 2026-04-25*
@@ -0,0 +1,51 @@
+---
+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]]
+---
@@ -0,0 +1,34 @@
+---
+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]]
+---
@@ -0,0 +1,28 @@
+---
+id: 550e8400-e29b-41d4-a716-446655440003
+category: "[[10_Wiki/Topics/Governance & Reliability]]"
+confidence_score: 1.0
+tags: [Governance, Logging, Wiki, SOP, Agent]
+last_reinforced: 2026-04-21
+github_commit: "initial"
+---
+
+# [[Autonomous Logging]]
+
+## 📌 한 줄 통찰 (The Karpathy Summary)
+> 에이전트의 모든 유의미한 행동을 자율적으로 기록하여 지식의 인과관계와 타임라인을 완벽하게 보존하는 거버넌스 프로토콜.
+
+## 📖 구조화된 지식 (Synthesized Content)
+- **추출된 패턴:** "무조건 기록 원칙"을 통해 에이전트의 블랙박스화를 방지하고, 모든 작업 결과물을 지식 자산으로 전환함.
+- **세부 내용:**
+    - **What/Why/How/Expectation**: 작업의 내용, 목적, 설계, 기대 효과를 필수적으로 포함.
+    - **Trigger**: 코드 수정, 기획, 리서치 등 모든 유의미한 작업 완료 직후 실행.
+    - **Storage**: `00_Raw` 폴더에 날짜 기반 파일명으로 저장 후 `p_reinforce`를 통해 위키화.
+
+## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
+- **정책 변화**: 기존의 단순 작업 수행 방식에서 '수행+기록'의 일체형 워크플로우로 전환하여 작업 투명성 확보.
+
+## 🔗 지식 연결 (Graph)
+- **Parent**: [[Governance & Reliability]]
+- **Related**: [[Wiki Automation]], [[Operational Self-Improvement]]
+- **Raw Source**: [[00_Raw/2026-04-21-Autonomous_Logging_and_Wiki_Rules_Update]]
@@ -0,0 +1,27 @@
+---
+id: 550e8400-e29b-41d4-a716-446655440004
+category: "[[10_Wiki/Topics/Governance & Reliability]]"
+confidence_score: 1.0
+tags: [Governance, Git, Automation, Session Management]
+last_reinforced: 2026-04-21
+github_commit: "initial"
+---
+
+# [[Session Lifecycle]]
+
+## 📌 한 줄 통찰 (The Karpathy Summary)
+> 업무의 시작과 끝을 Git 동기화 자동화와 결합하여 데이터 무결성을 보장하고 개발 환경 세팅 시간을 제로화하는 세션 관리 프로토콜.
+
+## 📖 구조화된 지식 (Synthesized Content)
+- **추출된 패턴:** 세션의 생명주기(Start/End)를 명시적인 트리거와 연결하여 멀티 리포지토리 환경에서의 관리 복잡성을 해결함.
+- **세부 내용:**
+    - **Start Session**: "일 시작하자" 트리거 시 모든 프로젝트(Wiki, Skybound, Agent, Datacollector)의 최신 데이터를 확보(`git pull`).
+    - **End Session**: "마무리 하자" 트리거 시 모든 변경 사항을 일괄 커밋 및 푸시(`git push`)하고 미처리 원시 데이터를 점검.
+
+## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
+- **정책 변화**: 수동 Git 관리에서 세션 기반 자동 동기화로 전환하여 커밋 누락 및 컨플릭트 위험을 사전에 차단.
+
+## 🔗 지식 연결 (Graph)
+- **Parent**: [[Governance & Reliability]]
+- **Related**: [[Autonomous Logging]], [[Git Protocol]]
+- **Raw Source**: [[00_Raw/2026-04-21-Session_Lifecycle_Protocol_Update]]
@@ -0,0 +1,31 @@
+---
+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]]
+---
@@ -0,0 +1,31 @@
+---
+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]]
+---
@@ -0,0 +1,25 @@
+---
+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]]
+---
@@ -0,0 +1,25 @@
+---
+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]]
+---
@@ -0,0 +1,25 @@
+---
+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]]
+---
@@ -0,0 +1,25 @@
+---
+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]]
+---
@@ -0,0 +1,25 @@
+---
+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]]
+---
@@ -0,0 +1,25 @@
+---
+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]]
+---
@@ -0,0 +1,25 @@
+---
+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]]
+---
@@ -0,0 +1,25 @@
+---
+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]]
+---
@@ -0,0 +1,30 @@
+---
+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]]
+---
@@ -0,0 +1,32 @@
+---
+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]]
+---