diff --git a/10_Wiki/Topics/02_Software_Engineering/Programming Foundations.md b/10_Wiki/Topics/02_Software_Engineering/Programming Foundations.md
new file mode 100644
index 00000000..e2dbae1f
--- /dev/null
+++ b/10_Wiki/Topics/02_Software_Engineering/Programming Foundations.md	
@@ -0,0 +1,38 @@
+# Programming Foundations (프로그래밍 기초 및 설계 원칙)
+
+## 📌 Brief Summary
+프로그래밍 기초(Programming Foundations)는 소프트웨어를 구성하는 물리적 구조(AST)와 논리적 설계 패러다임(OOP, Design Patterns)을 포함하는 지식의 근간입니다 [1]. 추상 구문 트리(AST)를 통해 소스 코드를 구조적으로 이해하고, 객체 지향 프로그래밍(OOP)과 SOLID 원칙을 적용하여 복잡한 시스템을 모듈화하고 재사용 가능한 형태로 설계함으로써 시스템의 유지보수성과 확장성을 확보합니다 [1-3].
+
+## 📖 Core Content
+
+### 1. 추상 구문 트리 (Abstract Syntax Tree, AST)
+*   **개념:** 소스 코드의 추상적인 구문 구조를 트리 형태로 표현한 것입니다. 정적 분석 도구가 코드를 "이해"하는 가장 기본적인 방식입니다 [1, 7].
+*   **활용:** 코드 리뷰 자동화(SAST), 리팩토링 도구, AI 기반 디버깅 엔진에서 소스 코드를 구조적으로 탐색하고 결함을 감지하는 데 사용됩니다 [2, 3].
+
+### 2. 객체 지향 프로그래밍 (Object-Oriented Programming, OOP)
+*   **핵심 기법:** 데이터 캡슐화(Encapsulation)와 데이터 은닉(Hiding)을 통해 모듈 간 독립성을 유지하고 코드 중복을 최소화합니다 [3, 4].
+*   **상향식 설계(Bottom-Up):** 작은 객체를 먼저 개발하고 이를 통합하여 큰 시스템을 구성하는 상향식 접근법과 밀접하게 연관됩니다 [2, 4].
+*   **분석 전략:** 낯선 OOP 코드베이스 파악 시 클래스 계층 구조(Class Hierarchy) 시각화와 단일 책임 원칙(Single Responsibility) 준수 여부 확인이 필수적입니다 [6, 8].
+
+### 3. 설계 원칙 및 패턴 (Design Principles & Patterns)
+*   **SOLID 원칙:** SRP(단일 책임), OCP(개방-폐쇄) 등 5대 원칙을 통해 변경에 유연한 설계를 지향합니다 [8].
+*   **디자인 패턴:** 반복되는 문제에 대한 검증된 해결책(Factory, Singleton, Observer 등)으로, 팀 내 의사소통의 '비컨(Beacon)' 역할을 수행합니다.
+
+## ⚠️ Trade-offs & Caveats
+*   **유연성 vs. 추적 가능성:** 고도로 모듈화된 OOP/클린 아키텍처는 개별 단위의 품질을 높이지만, 실행 흐름을 파악하기 위해 수십 개의 파일을 넘나들어야 하는 '추적의 어려움(Traceability Friction)'을 유발할 수 있습니다 [11, 12].
+*   **과잉 설계(Over-engineering):** 무분별한 디자인 패턴 적용은 시스템의 복잡도를 높이고 하향식(Top-Down) 방향성을 상실하게 만들 위험이 있습니다 [5, 10].
+*   **AST의 한계:** 정적 구조 분석만으로는 실제 비즈니스 의도(Intent)나 런타임의 동적 행위를 완벽히 파악하기 어렵습니다 [6].
+
+## 🔗 Knowledge Connections
+
+### Related Concepts
+- [[Security & Quality Engineering]]: AST 분석을 기반으로 보안 취약점을 탐지하는 정적 분석 기술을 다룹니다.
+- [[Software Maintenance & Evolutionary Design]]: OOP와 설계 원칙이 실제 유지보수 비용과 진화적 설계에 미치는 영향을 분석합니다.
+- [[Cognitive Load & Mental Models]]: 복잡한 클래스 계층 구조가 개발자의 인지 부하에 미치는 심리학적 영향을 연구합니다.
+
+### Practical Application Contexts
+- **Implementation:** 클래스 설계 시 SRP를 준수하여 객체를 작게 쪼개고, 인터페이스를 통해 결합도를 낮춥니다 [8].
+- **Code Review:** 자동화된 AST 분석 도구를 활용해 구문 오류와 기본 보안 결함을 일차적으로 걸러냅니다 [4, 5].
+
+---
+*Last updated: 2026-05-02*
diff --git a/10_Wiki/Topics/02_Software_Engineering/Software Maintenance & Evolutionary Design.md b/10_Wiki/Topics/02_Software_Engineering/Software Maintenance & Evolutionary Design.md
new file mode 100644
index 00000000..49efa512
--- /dev/null
+++ b/10_Wiki/Topics/02_Software_Engineering/Software Maintenance & Evolutionary Design.md	
@@ -0,0 +1,41 @@
+# Software Maintenance & Evolutionary Design (소프트웨어 유지보수 및 진화적 설계)
+
+## 📌 Brief Summary
+소프트웨어 유지보수(Software Maintenance)는 시스템 배포 이후 발생하는 결함 수정, 성능 개선, 환경 변화에 대한 적응을 포함하는 소프트웨어 생명주기의 가장 긴 단계이자 핵심 과정입니다 [1]. 현대 소프트웨어 공학에서는 이를 단순한 수리를 넘어 **진화적 설계(Evolutionary Design)**의 과정으로 보며, 개발자가 기존 시스템의 **멘탈 모델(Mental Model)**을 구축하고 가설을 검증하며 지식을 확장해 나가는 인지적 활동으로 정의합니다 [1-3]. 
+
+## 📖 Core Content
+
+### 1. 유지보수의 4대 범주 (Maintenance Categories)
+*   **교정형 (Corrective):** 발견된 결함(Bugs)을 수정하여 시스템을 정상화하는 작업입니다.
+*   **적응형 (Adaptive):** 운영 체제, 하드웨어, 라이브러리 등 환경 변화에 대응하여 시스템을 수정하는 작업입니다.
+*   **완전형 (Perfective):** 시스템의 기능을 개선하거나 성능을 최적화하여 가치를 높이는 작업입니다.
+*   **예방형 (Preventive):** 잠재적 결함을 예방하고 유지보수성을 높이기 위해 리팩토링 등을 수행하는 작업입니다.
+
+### 2. 기술 부채 (Technical Debt)
+*   **개념:** 빠른 배포를 위해 타협한 설계적 결정이 시간이 지남에 따라 복잡성과 비용을 증가시키는 현상입니다.
+*   **관리 지표 (Behavioral Analysis):** 단순한 코드 스캔을 넘어 Git 히스토리를 분석하여 자주 수정되고 복잡도가 높은 **'핫스팟(Hotspots)'**과 **'코드 건강도(Code Health)'**를 추적함으로써 부채의 우선순위를 결정합니다 [1, 2, 5].
+
+### 3. 클린 vs. 추적 가능성 (Clean vs. Traceable Code)
+*   **딜레마:** 고도의 추상화와 결합도 제거를 추구하는 '클린 아키텍처'는 개별 모듈의 이해도를 높이지만, 실행 흐름을 파악하기 위해 수많은 모듈을 넘나들어야 하므로 시스템 전체의 '추적 가능성'을 저해하고 **외부적 인지 부하(Extraneous load)**를 가중시킬 수 있습니다 [3, 4].
+
+## ⚠️ Trade-offs & Caveats
+*   **부분 이해의 효율성:** 거대 시스템에서 모든 코드를 완벽히 파악(Full Understanding)하려는 시도는 비효율적입니다. 목적에 맞는 특정 영역의 **'부분적 이해(Partial Understanding)'**를 극대화하는 기회주의적 전략이 필요합니다 [14].
+*   **부채의 임계치:** 기술 부채가 특정 임계치(코드 건강도 6점 이하)를 넘어서면 새로운 기능 개발보다 결함 수정에 더 많은 비용이 발생하는 '기술적 파산' 상태에 이를 수 있습니다.
+
+## 🔗 Knowledge Connections
+
+### Related Concepts
+- [[Program Comprehension Strategies]]: 유지보수를 위해 코드를 읽고 멘탈 모델을 구축하는 구체적인 기법입니다.
+- [[Cognitive Load & Mental Models]]: 유지보수 작업 중 발생하는 작업 기억의 한계와 복잡성 관리 전략을 다룹니다.
+- Legacy Systems: 문서화되지 않은 의존성과 부채가 누적된 시스템을 다루는 전략입니다.
+
+### Deeper Research Questions
+- 자동화된 품질 게이트(Quality Gates)가 팀의 기술 부채 인식과 상환 의지에 실질적으로 어떤 심리적/구조적 영향을 미치는가?
+- 마이크로서비스 환경에서 파편화된 기술 부채가 시스템 전체의 신뢰성(Systemic Reliability)에 미치는 파급 효과를 어떻게 측정할 것인가?
+
+### Practical Application Contexts
+- **Operation:** CodeScene 등의 도구를 도입하여 커밋 빈도와 복잡도가 결합된 핫스팟을 시각화하고 우선 리팩토링 대상을 선정합니다 [5].
+- **Implementation:** 기존 동작을 보존하기 위한 단위 테스트를 먼저 구축한 후, 기능적 훼손 없이 단계적으로 부채를 상환합니다 [4].
+
+---
+*Last updated: 2026-05-02*
diff --git a/10_Wiki/Topics/04_Governance_Reliability/Code Review Methodology & Cognitive Process.md b/10_Wiki/Topics/04_Governance_Reliability/Code Review Methodology & Cognitive Process.md
new file mode 100644
index 00000000..598e4d45
--- /dev/null
+++ b/10_Wiki/Topics/04_Governance_Reliability/Code Review Methodology & Cognitive Process.md	
@@ -0,0 +1,44 @@
+# Code Review Methodology & Cognitive Process (코드 리뷰 방법론 및 인지 과정)
+
+## 📌 Brief Summary
+코드 리뷰 방법론 및 인지 과정은 리뷰어가 작성자의 변경 사항을 검토할 때 거치는 심리학적 프로세스와 이를 체계화한 전략적 프레임워크를 다룹니다 [1-3]. 코드 리뷰는 단순히 버그를 찾는 행위가 아니라, 작성자의 멘탈 모델을 이해하고 팀의 표준과 비교하여 최종 수락 여부를 결정하는 고도의 '의사결정 과정(Decision-Making)'입니다 [2]. CRCM(이해 모델)과 CRDM(의사결정 모델) 등의 이론적 프레임워크는 리뷰어의 인지 부하를 줄이고 고품질의 피드백을 생성하는 데 기여합니다 [4, 5].
+
+## 📖 Core Content
+
+### 1. 코드 리뷰의 2단계 프로세스 (CRDM Model)
+리뷰어는 인식 기반 의사결정(RPD) 모델에 따라 두 가지 주요 단계를 거칩니다 [4, 5]:
+*   **오리엔테이션 단계 (Orientation Phase):** 변경 사항의 맥락(Context), 목적(Why), 범위를 파악하는 단계입니다. 이 단계에서는 코드 자체보다 커밋 메시지, 이슈 트래커, 작성자와의 대화 등을 통해 '기대 모델'의 기초를 형성합니다 [6, 7].
+*   **분석 단계 (Analytical Phase):** 형성된 기대 모델과 실제 구현(How)을 반복적으로 비교하며 평가하는 단계입니다. '구현 이해 $\rightarrow$ 구현 평가 $\rightarrow$ 전체 영향 평가 $\rightarrow$ 행동 선택(수락/수정 요청)'의 순환 과정을 거칩니다 [9, 10].
+
+### 2. 리뷰 이해의 지식 계층 (CRCM Model)
+리뷰어는 Letovsky 모델을 확장하여 다음 세 가지 계층을 매핑합니다 [1, 13]:
+*   **명세 계층 (Specification):** 코드가 달성해야 할 비즈니스 목표입니다.
+*   **구현 계층 (Implementation):** 실제 소스 코드의 논리와 구조입니다.
+*   **주석/매핑 계층 (Annotation):** 명세와 구현 사이의 연결 고리입니다. 이 연결이 모호할 때 리뷰어는 가장 큰 인지적 과부하를 겪습니다.
+
+### 3. 전략적 코드 리뷰 기법 (Strategic Approaches)
+*   **리뷰 청킹 (Review Chunking):** 인지 부하 관리를 위해 PR을 기능적 단위로 나누어 검토하고, 마지막에 전체 일관성을 확인하는 방식입니다 [2].
+*   **이상적 모델과의 비교:** 리뷰어는 자신의 경험을 바탕으로 '이상적인 솔루션'을 머릿속에 시뮬레이션하고, 이를 실제 PR과 대조하여 격차(Gap)를 찾아냅니다 [43-45].
+
+## ⚠️ Trade-offs & Caveats
+*   **도구의 한계 (Tool Misalignment):** 대부분의 코드 리뷰 도구(diff view)는 '구현 계층' 분석에는 유리하지만, '오리엔테이션(맥락 파악)'에 필요한 외부 정보 연결 기능을 충분히 제공하지 않아 인지적 단절을 유발합니다 [11].
+*   **경험 의존성:** CRDM은 패턴 인식에 크게 의존하므로, 새로운 도메인이나 아키텍처에 합류한 리뷰어가 효과적인 멘탈 인덱스를 구축하는 데는 상당한 시간(최대 1년)이 소요될 수 있습니다 [5].
+*   **알림 피로 vs. 정밀도:** 자동화된 리뷰 도구를 병행할 때 발생하는 과도한 경고는 리뷰어의 집중력을 분산시켜 본질적인 설계 결함을 놓치게 할 수 있습니다 [17].
+
+## 🔗 Knowledge Connections
+
+### Related Concepts
+- [[Cognitive Load & Mental Models]]: 리뷰 과정에서의 작업 기억 한계와 청킹 전략의 기반이 됩니다.
+- [[Agentic Secure Code Review (에이전트 기반 보안 코드 리뷰)]]: AI 에이전트를 활용하여 인지 부하를 경감하고 의도 기반 분석을 자동화하는 기술입니다.
+- Collaboration & Knowledge Sharing: 코드 리뷰를 통한 지식 전파 및 팀 문화 형성에 관한 주제입니다.
+
+### Deeper Research Questions
+- AI 기반 리뷰 어시스턴트가 제공하는 자동화된 피드백이 리뷰어의 비판적 사고와 상황 모델 구축 능력을 장기적으로 저하시키는가?
+- 오리엔테이션 단계를 강화하기 위해 IDE 내에 이슈 트래커와 설계 문서를 어떤 시각적 인터페이스로 통합해야 하는가?
+
+### Practical Application Contexts
+- **Implementation:** 리뷰어의 오리엔테이션 비용을 줄이기 위해 PR 설명란에 변경의 근거와 기대 결과(Specification)를 충실히 작성해야 합니다 [7, 21].
+- **System Design:** 아키텍처 원칙을 팀 내에 명시적으로 공유하여 리뷰어가 '기대하는 모델'과 실제 구현 사이의 정렬(Alignment)을 도와야 합니다 [22, 33].
+
+---
+*Last updated: 2026-05-02*
diff --git a/10_Wiki/Topics/04_Governance_Reliability/Security & Quality Engineering.md b/10_Wiki/Topics/04_Governance_Reliability/Security & Quality Engineering.md
new file mode 100644
index 00000000..35c805ad
--- /dev/null
+++ b/10_Wiki/Topics/04_Governance_Reliability/Security & Quality Engineering.md	
@@ -0,0 +1,42 @@
+# Security & Quality Engineering (보안 및 품질 공학)
+
+## 📌 Brief Summary
+보안 및 품질 공학은 소프트웨어의 신뢰성을 확보하기 위해 개발 전 과정에 걸쳐 자동화된 검증 체계와 거버넌스를 구축하는 학문적/실무적 영역입니다 [1]. 이는 코드 작성 시점부터 배포 이후까지 **SAST(정적 분석)**, **DAST(동적 분석)**, **의존성 스캐닝** 등을 통합하여 보안 취약점과 저품질 코드의 유입을 원천 차단하는 **'보안의 좌측 이동(Shift-Left)'**과 **'품질 게이트(Quality Gate)'** 전략을 핵심으로 합니다 [3, 4].
+
+## 📖 Core Content
+
+### 1. 자동화된 보안 테스트 (Security Testing)
+*   **SAST (Static Application Security Testing):** 소스 코드를 실행하지 않고 정적으로 분석하여 OWASP Top 10 취약점, 코드 스멜, 논리적 결함을 식별합니다 [1, 11].
+*   **DAST (Dynamic Application Security Testing):** 실행 중인 애플리케이션에 실제 페이로드를 주입하여 런타임 환경에서의 취약점을 탐지합니다. SAST가 찾지 못하는 환경 설정 오류나 인증 우회 등을 보완합니다 [9].
+*   **의존성 스캐닝 (Dependency Scanning):** 서드파티 라이브러리의 알려진 취약점(CVE)을 데이터베이스와 대조하여 관리합니다. 단순히 취약점 유무를 넘어 실제 코드 내에서의 **도달 가능성(Reachability)** 분석이 차세대 기술의 핵심입니다 [3].
+
+### 2. 품질 게이트 (Quality Gate)
+*   **통과/실패 기준 강제:** 새로운 코드가 병합되기 전 반드시 충족해야 하는 보안, 커버리지, 복잡도 등의 기준을 설정합니다 [2].
+*   **베이스라인 관리:** 레거시 시스템 도입 시 기존 부채는 '베이스라인'으로 설정하여 무시하고, **'새로운'** 코드에 대해서만 엄격한 기준을 적용하여 점진적 개선을 유도합니다 [2, 6].
+*   **피드백 루프 단축:** CI/CD 파이프라인 및 PR 워크플로우에 직접 통합되어 개발자가 IDE를 벗어나지 않고 즉각적인 수정을 할 수 있도록 돕습니다 [5, 7].
+
+### 3. 지속적 통합 및 배포 (CI/CD)
+*   **Pipeline as a Gatekeeper:** 품질 및 보안 스캔을 자동화된 파이프라인의 필수 단계로 설정하여, 검증되지 않은 코드가 상용 환경에 노출되는 것을 방지합니다.
+
+## ⚠️ Trade-offs & Caveats
+*   **Reachability의 한계:** 많은 의존성 스캔 도구가 취약한 라이브러리의 존재 여부만 알릴 뿐, 해당 코드가 실제 실행 경로에 포함되는지(Reachability) 판단하지 못해 과도한 오탐(False Positive)을 발생시킵니다 [3].
+*   **알림 피로 (Alert Fatigue):** 너무 많은 경고는 개발자의 집중력을 분산시키고 도구에 대한 신뢰를 떨어뜨립니다. '의도 인지' 엔진을 통한 정밀도(Precision) 향상이 필수적입니다.
+*   **인덱싱 비용:** 대규모 저장소에서 심층적인 보안 분석을 수행할 경우 리소스 소모와 빌드 시간 지연이 발생할 수 있습니다.
+
+## 🔗 Knowledge Connections
+
+### Related Concepts
+- [[Agentic Secure Code Review (에이전트 기반 보안 코드 리뷰)]]: AI 에이전트를 활용하여 보안 분석의 정밀도를 높이고 오탐을 줄이는 기술입니다.
+- [[Software Maintenance & Evolutionary Design]]: 기술 부채 관리와 품질 게이트의 전략적 연계 방안을 다룹니다.
+- [[SDLC & SSDLC (소프트웨어 개발 생명주기)]]: 보안이 통합된 개발 생명주기(Secure SDLC)의 전체 프레임워크입니다.
+
+### Deeper Research Questions
+- AI가 생성한 코드를 검증하기 위해 기존의 규칙 기반 Quality Gate는 어떤 방식으로 개선되어야 하는가?
+- 런타임 데이터(DAST)와 정적 분석 데이터(SAST)를 결합하여 보안 위협의 우선순위를 자동 결정하는 효과적인 알고리즘은 무엇인가?
+
+### Practical Application Contexts
+- **Operation:** CI/CD 파이프라인에 SonarQube나 Aikido Security를 연동하여 보안 정책 위반 시 배포를 자동 차단합니다 [1, 2].
+- **Implementation:** 개발자가 IDE 내부에서 OWASP Dependency-Check 등을 활용해 취약한 라이브러리 유입을 사전에 방어합니다 [3].
+
+---
+*Last updated: 2026-05-02*
diff --git a/10_Wiki/Topics/05_Cognitive_Engineering/Cognitive Load & Mental Models.md b/10_Wiki/Topics/05_Cognitive_Engineering/Cognitive Load & Mental Models.md
new file mode 100644
index 00000000..3579bf3a
--- /dev/null
+++ b/10_Wiki/Topics/05_Cognitive_Engineering/Cognitive Load & Mental Models.md	
@@ -0,0 +1,47 @@
+# Cognitive Load & Mental Models (인지 부하 및 멘탈 모델)
+
+## 📌 Brief Summary
+인지 부하 이론(Cognitive Load Theory, CLT)과 멘탈 모델(Mental Models)은 소프트웨어 엔지니어가 복잡한 시스템을 파악하고 유지보수할 때 발생하는 내부적 지식 표상과 인지적 제약을 설명하는 핵심 이론입니다 [1, 5]. 인간의 제한된 '작업 기억(Working Memory)' 용량 내에서 소스 코드를 읽고 시스템의 의도를 재구성하는 과정은 본질적 복잡성과 구현상의 불필요한 복잡성 사이의 투쟁입니다 [1]. 성공적인 개발자는 파편화된 코드를 고수준의 기능적 단위로 '청킹(Chunking)'하여 견고한 멘탈 모델을 구축함으로써 대규모 시스템의 복잡도를 관리합니다 [1, 2].
+
+## 📖 Core Content
+
+### 1. 인지 부하의 3대 유형 (Types of Cognitive Load)
+소프트웨어 개발 시 발생하는 인지적 노력은 다음 세 가지로 분류됩니다 [1]:
+*   **본질적 부하 (Intrinsic Load):** 도메인 로직이나 알고리즘 자체가 가진 고유의 복잡성입니다. (예: 분산 합의 알고리즘 구현)
+*   **외부적 부하 (Extraneous Load):** 조잡한 코드 명명, 파편화된 아키텍처, 문서 부재 등 구현 방식 때문에 발생하는 불필요한 인지적 소모입니다.
+*   **관련적 부하 (Germane Load):** 시스템의 동작 원리를 내재화하고 지식 스키마(Schema)를 구축하는 데 투입되는 유익한 노력입니다.
+
+### 2. 멘탈 모델의 계층 구조 (Hierarchy of Mental Models)
+개발자는 코드를 읽으며 두 가지 핵심 표상을 형성합니다 [1, 2, 5]:
+*   **프로그램 모델 (Program Model):** 코드의 구문, 제어 흐름, 데이터 흐름 등 기술적 구현에 집중한 저수준 모델입니다. (상향식 접근법의 결과물)
+*   **상황 모델 (Situation Model / Task Model):** 비즈니스 목적, 사용자 요구사항, 도메인 기능을 표현하는 고수준 모델입니다. (하향식 접근법의 결과물)
+*   **매핑 계층 (Annotation Layer):** 프로그램 모델(How)과 상황 모델(Why) 사이의 연결 고리로, 이 연결이 명확할수록 코드의 '추적 가능성(Traceability)'이 높아집니다.
+
+### 3. 복잡성 관리 도구 (Chunking & Beacons)
+*   **청킹 (Chunking):** 여러 코드 요소를 '정렬 알고리즘', '인증 미들웨어'와 같이 하나의 추상화된 레이블로 묶어 작업 기억의 부하를 줄이는 기술입니다 [1].
+*   **비컨 (Beacons):** 특정 기능을 암시하는 강력한 단서(예: `swap` 변수는 정렬을 암시)로, 개발자가 하향식 가설을 세울 때 지름길 역할을 합니다 [16, 17].
+
+## ⚠️ Trade-offs & Caveats
+*   **Clean vs. Traceable 코드의 긴장:** 고도로 모듈화된 '클린(Clean)' 코드는 개별 모듈의 본질적 부하를 줄여주지만, 실행 흐름을 파악하기 위해 수많은 파일을 넘나들어야 하므로 **외부적 인지 부하(Extraneous load)**를 급격히 높일 수 있습니다 [3, 4].
+*   **비전형적 코드(Unplan-like)의 충격:** 관례를 무시한 코드는 개발자의 기존 스키마와 충돌하여 '인지적 불일치(Cognitive Dissonance)'를 유발하고 멘탈 모델 구축을 방해합니다 [18].
+*   **리뷰 파편화:** 인지 부하 관리를 위해 PR을 작게 쪼개는 것은 개별 검토에는 유리하지만, 전체 시스템의 일관성(Big Picture)을 놓치게 만들 위험이 있습니다 [2].
+
+## 🔗 Knowledge Connections
+
+### Related Concepts
+- [[Program Comprehension Strategies]]: 멘탈 모델을 구축하기 위한 구체적인 하향식/상향식 탐색 전략을 다룹니다.
+- Information Foraging Theory (정보 탐색 이론): 최소한의 인지 노력으로 코드 내 비컨(단서)을 찾아 이동하는 인간의 행동 양식을 설명합니다.
+- Clean Architecture vs Traceable Code: 인지 부하 최적화와 아키텍처적 결합도 제거 사이의 트레이드오프를 심층 분석합니다.
+
+### Deeper Research Questions
+- AI 기반 자동 완성 도구가 제공하는 코드가 개발자의 '관련적 부하(Germane load)' 형성을 방해하여 장기적인 시스템 이해도를 떨어뜨리는가?
+- 가상현실(VR)이나 3D 시각화 도구가 텍스트 기반 코드보다 고수준 상황 모델 구축에 더 효과적인 인지 보조 수단이 될 수 있는가?
+- 마이크로서비스 환경에서 파편화된 상황 모델을 하나로 통합하기 위한 가장 효율적인 '비컨' 설계 전략은 무엇인가?
+
+### Practical Application Contexts
+- **System Design:** 아키텍처 설계 시 'Clean'함뿐만 아니라 'Traceable'함(추적 용이성)을 동시에 고려하여 외부적 부하를 통제해야 합니다 [20, 32].
+- **Code Review:** 리뷰어의 인지 부하를 줄이기 위해 PR 본문에 'Specification(목적)'을 명확히 작성하여 구현부와의 매핑(Annotation)을 도와야 합니다 [5, 10].
+- **Documentation:** 문서는 단순히 코드를 설명하는 것이 아니라, 코드에서 읽기 어려운 '상황 모델(Why)'을 집중적으로 보완하는 역할을 해야 합니다.
+
+---
+*Last updated: 2026-05-02*
diff --git a/10_Wiki/Topics/05_Cognitive_Engineering/Program Comprehension Strategies.md b/10_Wiki/Topics/05_Cognitive_Engineering/Program Comprehension Strategies.md
new file mode 100644
index 00000000..2b59c8ec
--- /dev/null
+++ b/10_Wiki/Topics/05_Cognitive_Engineering/Program Comprehension Strategies.md	
@@ -0,0 +1,42 @@
+# Program Comprehension Strategies (프로그램 이해 전략)
+
+## 📌 Brief Summary
+프로그램 이해 전략(Program Comprehension Strategies)은 개발자가 기존 소스 코드를 유지보수하거나 확장하기 위해 코드를 읽고 그 논리적 구조와 설계 의도를 파악하는 인지적 과정(Cognitive Process)을 정의한 방법론입니다 [1-3]. 이 과정은 단순히 구문을 읽는 행위를 넘어, 코드라는 외부 표현을 개발자의 내면화된 '정신 모델(Mental Model)'로 매핑하는 고도의 지적 활동입니다 [1, 4]. 개발자는 코드의 익숙함과 전문성에 따라 하향식(Top-Down), 상향식(Bottom-Up), 그리고 이들을 유연하게 혼합한 통합적/기회주의적(Opportunistic) 전략을 선택적으로 사용합니다 [6-9].
+
+## 📖 Core Content
+프로그램 이해 모델은 개발자가 코드에서 '무엇(What)', '어떻게(How)', '왜(Why)'를 추출하는 방식을 체계화한 3대 핵심 프레임워크로 구성됩니다.
+
+*   **하향식 이해 모델 (Top-Down Models - Brooks, Soloway & Ehrlich):**
+    *   **전제 조건:** 개발자가 시스템 아키텍처나 도메인 지식에 익숙할 때 주로 사용합니다 [19-21].
+    *   **메커니즘:** 시스템의 전체 목적에 대한 가설(Hypothesis)을 먼저 세우고, 코드 내에서 이를 뒷받침하는 단서인 '비컨(Beacons)'과 전형적인 구조인 '프로그래밍 계획(Programming Plans)'을 찾아 가설을 검증하며 하위 수준으로 구체화합니다 [21-23].
+*   **상향식 이해 모델 (Bottom-Up Models - Pennington, Shneiderman):**
+    *   **전제 조건:** 코드가 낯설거나 새로운 언어/프레임워크를 접할 때 사용합니다 [24, 25].
+    *   **메커니즘:** 개별 구문과 제어 흐름(마이크로 구조)을 먼저 읽어 '프로그램 모델(Program Model)'을 구축한 후, 이를 기능적 의미가 담긴 '상황 모델(Situation Model)'로 '청킹(Chunking)'하여 상향식으로 결합합니다 [25-28].
+*   **통합 및 기회주의적 전략 (Integrated/Opportunistic Models - Letovsky, Mayrhauser & Vans):**
+    *   **전제 조건:** 실제 복잡한 대규모 레거시 시스템 유지보수 환경에서 사용됩니다 [29-31].
+    *   **메커니즘:** 개발자는 고정된 방향 없이 가설 검증과 세부 구현 파악을 수시로 오가며(Cross-referencing), 필요한 정보만 발췌하여 이해를 확장합니다 [30-32]. 이는 인지 부하를 최소화하면서 당면한 과제(Task-relevant)를 해결하는 데 최적화된 방식입니다.
+
+## ⚠️ Trade-offs & Caveats
+*   **효율성 vs 정확성의 딜레마:** 하향식 전략은 아키텍처를 빠르게 파악할 수 있으나, '확증 편향'으로 인해 비전형적인(Unplan-like) 코드에서 발생하는 미세한 버그나 보안 취약점을 간과할 위험이 큽니다 [6, 11]. 반대로 상향식은 정확도가 높지만, 막대한 인지 부하를 유발하며 전체 맥락(Big Picture)을 놓칠 수 있습니다 [6].
+*   **비전형적 코드(Unplan-like)의 위험:** 코드가 관례를 벗어나거나 독창적이지만 가독성이 낮은 구조로 작성된 경우, 전문가의 하향식 가설 검증이 실패(Dangling Purpose)하게 되어 인지 비용이 기하급수적으로 증가합니다 [18, 38].
+*   **단일 진입점 부재:** 현대의 이벤트 기반 아키텍처나 마이크로서비스에서는 전통적인 `main()` 함수와 같은 명확한 이해의 출발점이 부재하여, 기회주의적 전략에 의존해야 하며 이로 인해 멘탈 모델이 파편화될 위험이 상존합니다 [6, 39].
+
+## 🔗 Knowledge Connections
+
+### Related Concepts
+- [[Cognitive Load & Mental Models]]: 프로그램 이해 과정에서 발생하는 인지적 병목과 청킹 메커니즘을 다룹니다.
+- Beacons & Programming Plans: 하향식 가설 생성을 돕는 코드 내 단서와 전형적인 패턴에 대한 상세입니다.
+- Clean Architecture vs Traceable Code: 인지 부하를 줄이기 위한 설계적 선택과 추적 가능성 사이의 균형을 논의합니다.
+
+### Deeper Research Questions
+- 대규모 분산 아키텍처 환경에서 고전적 이해 모델(Brooks, Pennington)의 한계를 보완하기 위한 현대적 인지 보조 도구는 무엇인가?
+- 비전형적 코드를 마주했을 때 발생하는 '인지적 불일치'를 정적 분석 도구와 AI 어시스턴트로 어떻게 해소할 수 있는가?
+- '상황 모델(의도)'과 '프로그램 모델(구현)' 사이의 괴리를 코드 리뷰 과정에서 시스템적으로 감지하는 방법은?
+
+### Practical Application Contexts
+- **Implementation:** 명확한 함수명과 디자인 패턴을 '비컨'으로 제공하여 동료의 가설 검증 비용을 줄여야 합니다 [18, 38].
+- **Maintenance:** 무작정 코드를 읽기보다 Git 히스토리와 PR 논의(Context)를 먼저 파악하여 하향식 가설을 먼저 세우는 것이 효율적입니다 [47, 48].
+- **Onboarding:** 신규 입사자에게 비즈니스 도메인(Situation Model)을 먼저 교육한 후, 실제 구현부(Program Model)로 안내하는 하향식 지식 전달이 효과적입니다 [25, 27].
+
+---
+*Last updated: 2026-05-02*
diff --git a/10_Wiki/Topics/AI/AI-Driven Engineering & Automation.md b/10_Wiki/Topics/AI/AI-Driven Engineering & Automation.md
new file mode 100644
index 00000000..cfa81979
--- /dev/null
+++ b/10_Wiki/Topics/AI/AI-Driven Engineering & Automation.md	
@@ -0,0 +1,37 @@
+# AI-Driven Engineering & Automation (AI 기반 엔지니어링 및 자동화)
+
+## 📌 Brief Summary
+AI 기반 엔지니어링(AI-Driven Engineering)은 생성형 AI와 자율 에이전트를 소프트웨어 개발 생명주기(SDLC) 전반에 통합하여 기획, 구현, 검증, 디버깅 과정을 지능화하는 패러다임입니다 [1]. 이는 단순히 코드를 추천하는 수준을 넘어, MCP(Model Context Protocol)를 활용한 **Git Archaeology(히스토리 분석)**, **Intent-Aware(의도 인지) 분석**, **자동화된 테스트 생성**을 통해 개발자의 인지 부하를 줄이고 시스템의 신뢰성을 극대화합니다 [2-6].
+
+## 📖 Core Content
+
+### 1. AI 디버깅 및 Git 고고학 (AI Debugging & Git Archaeology)
+*   **시간적 맥락 분석:** MCP를 통해 Git 히스토리(`git diff`, `git log`)에 접근함으로써, 코드가 "언제 정상 동작했는지"와 "왜 변경되었는지"를 분석하여 회귀 버그의 근본 원인을 파악합니다 [4, 6].
+*   **멘탈 모델 디버깅:** 프로그램의 실제 동작과 개발자의 예상 동작 사이의 불일치를 분석하여, 개발자 내면의 '오개념(Misconception)'을 교정하고 대안적 설명을 제공합니다 [5].
+
+### 2. 의도 인지 및 구조적 분석 (Intent-Aware & Structural Analysis)
+*   **의도 엔진 (Intent Engine):** 개발자의 원래 프롬프트와 채팅 기록을 기반으로, 구현된 코드가 실제 비즈니스 목표를 달성하는지 논리적 차원에서 검증합니다 [16].
+*   **AST 분석:** 추상 구문 트리(AST) 분석과 AI 추론을 결합하여, 런타임 이전 단계에서 아키텍처적 결함과 서비스 간 통합 실패를 40% 이상 더 정확하게 감지합니다 [3, 7].
+
+### 3. 품질 게이트 및 자동화된 테스트 (Fast Gates & Test Generation)
+*   **자동 테스트 생성:** 코드 변경 사항에 대해 유효한 단위 테스트와 통합 테스트를 자율적으로 생성하여 테스트 커버리지를 보완합니다 [18].
+*   **Fast Gates:** CI/CD 파이프라인 내에서 AI가 품질 게이트(Quality Gate) 역할을 수행하여, 코드 냄새(Code Smells)와 보안 취약점을 실시간으로 차단합니다.
+
+## ⚠️ Trade-offs & Caveats
+*   **AI 환각(Hallucination):** 맥락이 부족한 경우 AI가 존재하지 않는 API를 호출하거나 그럴듯한 거짓 정보를 생성할 위험이 있어, 최종적인 인간 검증은 여전히 필수적입니다 [16, 21].
+*   **인덱싱 오버헤드:** 수십만 개의 파일을 분석하는 대규모 시스템에서는 초기 스캔 및 인덱싱에 따른 성능 저하와 IDE 멈춤 현상이 발생할 수 있습니다 [10, 22].
+*   **인지 능력의 퇴화:** AI 자동화에 지나치게 의존할 경우, 개발자가 시스템의 핵심 동작 원리를 내재화(Germane Load 형성)하는 기회를 놓쳐 장기적인 이해도가 하락할 수 있습니다.
+
+## 🔗 Knowledge Connections
+
+### Related Concepts
+- Agentic Coding (에이전틱 코딩): 자율적으로 태스크를 수행하는 에이전트의 전체 워크플로우를 다룹니다.
+- [[Model Context Protocol (MCP)]]: AI가 로컬 도구 및 데이터와 안전하게 통신하기 위한 표준 프로토콜입니다.
+- [[Cognitive Load & Mental Models]]: AI 도구가 개발자의 인지 부하를 어떻게 경감시키는지 심리학적 관점에서 분석합니다.
+
+### Deeper Research Questions
+- AI 기반의 '의도 인지' 분석이 전통적인 정적 분석(SAST) 대비 오탐(False Positive)률을 실질적으로 얼마나 낮출 수 있는가?
+- 개발자의 '멘탈 모델' 오류를 교정하는 인터랙티브 디버깅 방식이 주니어 개발자의 성장 곡선에 어떤 영향을 미치는가?
+
+---
+*Last updated: 2026-05-02*
diff --git a/10_Wiki/Topics/AI/Agentic Coding.md b/10_Wiki/Topics/AI/Agentic Coding.md
index 6ceb6d8a..988eeb2e 100644
--- a/10_Wiki/Topics/AI/Agentic Coding.md	
+++ b/10_Wiki/Topics/AI/Agentic Coding.md	
@@ -1,34 +1,38 @@
+# Agentic Coding (에이전틱 코딩)
+
+## 📌 Brief Summary
+에이전틱 코딩(Agentic Coding)은 AI가 단순히 정적인 코드를 생성하는 '조수(Copilot)' 수준을 넘어, 능동적으로 환경과 상호작용하며 복잡한 소프트웨어 엔지니어링 수행 과정을 자율적으로 관리하는 '수행 주체(Engineer)'로 진화한 패러다임입니다 [1]. 이는 요구사항 분석부터 파일 설계, 구현, 터미널 실행, 테스트 기반 자가 수정(Self-Correction)까지 이어지는 순환 고리(Feedback Loop)를 스스로 제어하는 것을 핵심으로 합니다 [2, 3].
+
+## 📖 Core Content
+
+### 1. 에이전틱 워크플로우의 4단계 (The Loops)
+*   **Planning (기획):** 고수준 요구사항을 파일별, 기능별 마이크로 태스크로 분해하고 수행 순서를 결정합니다.
+*   **Action (수행):** 파일 시스템에 직접 접근하여 소스 코드를 읽고 쓰며, 필요한 경우 외부 도구나 API를 호출합니다.
+*   **Verification (검증):** 터미널에서 코드를 실행하고 테스트를 돌려 에러 메시지나 결과를 수집합니다.
+*   **Self-Correction (자가 수정):** 수집된 에러를 바탕으로 원인을 분석하고, 성공할 때까지 구현을 수정하는 반복 루프를 가동합니다.
+
+### 2. 핵심 기술 및 환경 (Tech & Tools)
+*   **도구 사용(Multi-tool use):** 브라우저 탐색, 터미널 명령 실행, 파일 에디팅 등 인간 개발자와 동일한 도구를 활용합니다.
+*   **ConnectAI의 기여:** `AgentWorkflowManager` 및 `Intent Detection` 기술을 통해 다중 에이전트 간의 역할을 분담하고, 개발자의 의도에 부합하는 최적의 코딩 경로를 탐색합니다.
+
+### 3. 패러다임의 전환
+*   **검증 책임의 이동:** 과거에는 AI 생성 코드를 인간이 검수했으나, 현대의 에이전틱 코딩은 AI가 직접 테스트 코드를 작성하고 이를 통과한 '검증된 산출물'을 인간에게 보고하는 체계로 변화했습니다.
+
+## ⚠️ Trade-offs & Caveats
+*   **자율성의 위험:** 에이전트가 보안 취약점을 만들거나 무한 루프에 빠질 위험이 있어, 모든 자율 행동에 대해 정적 분석 및 보안 샌드박스 검증이 의무화되어야 합니다.
+*   **컨텍스트 한계:** 거대 코드베이스에서 수십만 개의 파일을 동시에 고려할 때 발생하는 인덱싱 부하와 추론 지연은 실시간 협업의 걸림돌이 될 수 있습니다.
+*   **AI 환각(Hallucination):** 그럴듯하지만 존재하지 않는 API를 호출하는 등의 환각 현상을 방지하기 위해 '의도 인지(Intent-Aware)' 검증 레이어가 필수적입니다.
+
+## 🔗 Knowledge Connections
+
+### Related Concepts
+- [[Agentic Secure Code Review (에이전트 기반 보안 코드 리뷰)]]: 에이전틱 코딩의 검증 루프 내에 보안 전문 에이전트를 통합한 특화 분야입니다.
+- [[Cognitive Load & Mental Models]]: 에이전트가 인간의 인지 부하를 줄여주는 방식과 에이전트 스스로가 가지는 내부 추론 모델을 이해하는 데 도움을 줍니다.
+- [[System Architecture & Reliability]]: 자율적으로 생성된 코드가 시스템 전체의 신뢰성을 해치지 않도록 관리하는 설계 원칙입니다.
+
+### Practical Application Contexts
+- **Implementation:** Devin, OpenDevin, Antigravity Agent(ConnectAI) 등을 활용하여 반복적인 보일러플레이트 작성이나 복잡한 리팩토링 태스크를 자동화합니다.
+- **Onboarding:** 에이전트가 분석한 프로젝트 의존성 그래프와 의도 힌트를 참고하여 신규 개발자가 코드베이스에 빠르게 적응하도록 돕습니다.
+
 ---
-id: [[P-Reinforce|P-Reinforce]]-AUTO-AGCO-001
-category: "10_Wiki/💡 Topics/AI"
-confidence_score: 0.97
-tags: [auto-reinforced, agentic-coding, software-development, ai-coding, [[Autonomous-Agents|Autonomous-Agents]], devops]
-last_reinforced: 2026-04-20
----
-
-# [[Agentic Coding|Agentic Coding]]
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> "코딩하는 기계의 진화: 단순히 코드 조각을 추천하는 것을 넘어, 파일 구조를 이해하고, 버그를 디버깅하며, 테스트를 통과할 때까지 스스로 수정 루프를 돌리는 자율 코딩 에이전트의 시대."
-
-## 📖 구조화된 지식 (Synthesized Content)
-에이전틱 코딩(Agentic Coding)은 AI가 정적인 코드 생성을 넘어, 능동적으로 환경과 상호작용하며 복잡한 소프트웨어 엔지니어링 수행 과정을 자율적으로 관리하는 것을 의미합니다.
-
-1.  **핵심 워크플로우 (The Loops)**:
-    *   **Planning**: 요구사항을 파일별, 기능별 태스크로 쪼개기.
-    *   **Action**: 실제 소스 코드 파일을 읽고 쓰기 (FileSystem Access).
-    *   **Terminal Interaction**: 코드를 실행하고 에러 메시지 분석.
-    *   **Self-Correction**: 에러를 바탕으로 코드를 수정하고 단위 테스트를 반복해서 돌려 무결성 확보.
-2.  **도구와 환경**:
-    *   에이전트는 브라우저, 터미널, 파일 에디터와 같은 도구를 인간과 동일하게 사용함 (Multi-tool use).
-3.  **지위의 변화**:
-    *   'Copilot' (조수)에서 'Engineer' (수행 주체)로의 패러다임 전환.
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌**: 과거에는 AI가 생성한 코드를 인간이 일일이 검수하는 수동 정책이었으나, 현대의 에이전틱 코딩 정책은 AI가 직접 테스트 코드를 작성하고 검증까지 완료한 '검증된 산출물'을 인간에게 보고하는 자동화 정책으로 이동함(RL Update).
-- **정책 변화(RL Update)**: 자율 코딩 에이전트가 보안 취약점을 만들거나 악성 코드를 삽입할 위험 정책에 대응하기 위해, 모든 AI 생성 코드에 대해 정적 분석과 보안 샌드박스 검증을 의무화하는 'AI 보안 코딩 거버넌스' 정책이 수립됨.
-
-## 🔗 지식 연결 (Graph)
-- [[Agent Architecture|Agent Architecture]], Workflow-InteGrity, Self-Correction Mechanisms, Tool-Usage-Optimization, [[Software-Design-Principles|Software-Design-Principles]], [[Ps-Reinforce|Ps-Reinforce]]
-- **Modern Tech/Tools**: Devin, OpenDevin, Sweep.dev, GitHub Copilot Workspace, Antigravity Agent.
----
+*Last updated: 2026-05-02*
diff --git a/10_Wiki/Topics/AI/Agentic Secure Code Review (에이전트 기반 보안 코드 리뷰).md b/10_Wiki/Topics/AI/Agentic Secure Code Review (에이전트 기반 보안 코드 리뷰).md
new file mode 100644
index 00000000..da5891c6
--- /dev/null
+++ b/10_Wiki/Topics/AI/Agentic Secure Code Review (에이전트 기반 보안 코드 리뷰).md	
@@ -0,0 +1,41 @@
+# [[Agentic Secure Code Review (에이전트 기반 보안 코드 리뷰)]]
+
+## 📌 Brief Summary
+에이전트 기반 보안 코드 리뷰는 AI 에이전트가 단순한 정적 분석을 넘어, 개발자의 **의도(Intent)**와 프로젝트의 **전체 맥락(Context)**을 파악하여 실시간으로 보안 취약점과 논리적 오류를 식별하는 고도화된 리뷰 방식입니다 [1, 2]. 이 방식은 보안 검증을 개발 생명주기의 극초기 단계(IDE 작성 시점)로 앞당기는 **'보안의 좌측 이동(Shift-Left)'**을 실현하며, 40만 개 이상의 파일을 분석하는 교차 저장소 매핑 기술을 통해 분산 시스템의 통합 위험을 선제적으로 방어합니다 [3, 8-10].
+
+## 📖 Core Content
+
+### 1. 의도 인지 기반 분석 (Intent-Aware Analysis)
+*   **메커니즘:** 개발자의 프롬프트, 채팅 기록, 과거 커밋 메시지를 '의도 엔진(Intent Engine)'으로 분석하여, 생성된 코드가 원래 목표와 일치하는지 검증합니다 [2].
+*   **효과:** 단순한 문법 오류가 아닌, "의도와 다른 논리적 버그"나 AI가 그럴듯하게 지어내는 "환각(Hallucination)" 현상을 효과적으로 잡아냅니다.
+
+### 2. 교차 저장소 의존성 매핑 (Cross-Repository Mapping)
+*   **메커니즘:** 단일 파일을 넘어 프로젝트 전체 및 연관된 외부 저장소 간의 종속성을 실시간으로 인덱싱합니다 [9, 10].
+*   **효과:** 특정 함수 변경이 다른 서비스나 모듈에 미치는 파급 효과를 사전에 경고하여, 마이크로서비스 아키텍처에서 발생하기 쉬운 통합 장애를 방지합니다.
+
+### 3. 실시간 IDE 통합 및 거버넌스
+*   **좌측 이동 (Shift-Left):** PR 단계가 아닌 IDE(VS Code, Cursor 등) 내에서 약 5초 이내에 피드백을 제공함으로써 보안 비용을 혁신적으로 절감합니다 [3, 7].
+*   **정책 강제:** 엔터프라이즈 수준의 보안 정책과 코딩 컨벤션을 에이전트에 주입하여, 모든 팀원이 동일한 품질 기준을 실시간으로 준수하도록 강제할 수 있습니다.
+
+## ⚠️ Trade-offs & Caveats
+*   **인덱싱 오버헤드:** 수십만 개의 파일을 가진 거대 저장소의 경우 초기 인덱싱에 상당한 시간(2~4시간)과 리소스가 소요될 수 있습니다 [13-15].
+*   **알림 피로 (Alert Fatigue):** 민감도 설정이 부적절할 경우 중복되거나 낮은 우선순위의 제안이 쏟아져 개발자의 집중력을 저해할 수 있습니다 [17, 18].
+*   **일관된 Git 전략의 필요성:** 에이전트가 정확한 맥락을 파악하려면 팀의 브랜치 전략과 커밋 로그가 정형화되어 있어야 합니다.
+
+## 🔗 Knowledge Connections
+
+### Related Concepts
+- [[Agentic Coding]]: 자율 코딩 에이전트의 전반적인 워크플로우와 자가 수정 메커니즘을 다룹니다.
+- [[Code Review Methodology & Cognitive Process]]: 인간 리뷰어의 인지 과정을 에이전트가 어떻게 보조하거나 모방하는지 이해하는 데 도움을 줍니다.
+- Software Architecture & Reliability: 분산 시스템에서의 의존성 관리와 신뢰성 확보 전략에 관한 주제입니다.
+
+### Deeper Research Questions
+- 에이전트의 '의도 인지' 분석이 기존의 정적 분석(SAST) 도구와 결합될 때 오탐(False Positive)률을 실질적으로 얼마나 낮출 수 있는가?
+- 지속적 학습(Continuous Learning) 모델이 팀별로 특화된 코딩 스타일과 비즈니스 로직을 학습할 때 발생하는 보안 및 프라이버시 이슈는 무엇인가?
+
+### Practical Application Contexts
+- **Implementation:** VS Code 환경에서 ConnectAI와 같은 도구를 활용해 코드 작성 즉시 보안 결함을 수정합니다 [3, 7].
+- **Operation:** CI/CD 파이프라인의 입구(IDE)에서 1차 품질 게이트 역할을 수행하게 하여 PR 승인 속도를 가속화합니다.
+
+---
+*Last updated: 2026-05-02*
diff --git a/10_Wiki/Topics/AI/Behavioral Analysis & Cognitive AI.md b/10_Wiki/Topics/AI/Behavioral Analysis & Cognitive AI.md
new file mode 100644
index 00000000..1c6eafe2
--- /dev/null
+++ b/10_Wiki/Topics/AI/Behavioral Analysis & Cognitive AI.md	
@@ -0,0 +1,38 @@
+# Behavioral Analysis & Cognitive AI (행동 분석 및 인지 AI)
+
+## 📌 Brief Summary
+행동 분석 및 인지 AI는 개발자가 코드를 읽고, 검색하고, 수정하는 과정에서 나타나는 행동 패턴과 내면의 의도(Intent)를 분석하여 엔지니어링 효율을 극대화하는 기술 영역입니다 [1, 2]. 이는 소스 코드 자체를 분석하는 정적 분석을 넘어, Git 히스토리 기반의 **행동 코드 분석(Behavioral Code Analysis)**과 개발자의 멘탈 모델을 추론하는 **마음 이론(Theory of Mind, ToM)**을 결합하여 지능형 코딩 어시스턴트의 핵심 두뇌 역할을 수행합니다 [2, 5, 10].
+
+## 📖 Core Content
+
+### 1. 행동 코드 분석 (Behavioral Code Analysis)
+*   **핫스팟 (Hotspots):** 소스 코드의 복잡도와 Git 히스토리상의 변경 빈도를 결합하여, 유지보수 마찰이 가장 크고 결함 발생 확률이 높은 코드 영역을 시각화합니다 [1, 2].
+*   **코드 건강도 (Code Health):** 개발자가 해당 코드를 수정할 때 느끼는 인지적 저항을 정량화하여, 리팩토링의 우선순위를 결정하는 지표로 활용합니다 [5, 8].
+
+### 2. 마음 이론 및 의도 추론 (Theory of Mind in SWE)
+*   **ToM-SWE 에이전트:** 개발자의 불충분한 지시(Underspecified instructions) 뒤에 숨겨진 원래 의도와 코딩 선호도를 추론합니다 [2, 3].
+*   **3계층 지식 저장소:** 개발자와의 상호작용을 '원시 스크립트 $\rightarrow$ 세션 모델 $\rightarrow$ 상호작용 스타일'로 계층화하여 저장함으로써, 세션이 바뀌어도 개발자의 맥락을 유지합니다 [5].
+*   **기호적 검색 (Symbolic Retrieval):** 복잡한 임베딩 대신 BM25 등 텍스트 일치 방식을 사용하여 사용자의 구체적인 제약 조건을 정확하게 검색하고 의사결정에 반영합니다 [5].
+
+### 3. 정보 탐색 이론 (Information Foraging Theory)
+*   **Search-Relate-Collect:** 개발자가 코드라는 정보 그래프에서 먹이를 찾듯(Foraging) 필요한 정보 조각(Node)을 검색하고, 관계(Edge)를 추적하며, 멘탈 모델 구축에 필요한 최소한의 정보를 수집하는 인지적 메커니즘입니다 [1-3].
+*   **탐색 중단 전략:** 개발자는 당면한 태스크를 완료하기에 '충분하다'고 판단하는 즉시 탐색을 멈추며, 이로 인해 전체 시스템 구조에 대한 '부분적 이해'만 형성될 수 있습니다 [3, 14].
+
+## ⚠️ Trade-offs & Caveats
+*   **부분 이해의 위험:** 정보 탐색 이론에 따르면 개발자는 목적 지향적으로만 코드를 읽기 때문에, 전체 아키텍처의 일관성을 해치는 국소적 최적화에 빠질 위험이 있습니다 [3, 14].
+*   **기호적 검색의 한계:** 텍스트 일치 방식은 정확도는 높지만, 의미론적으로 유사한(Semantic) 의도를 파악하는 데는 밀집 임베딩(Dense Embedding)보다 취약할 수 있습니다.
+*   **알림 피로:** 행동 분석 결과가 너무 빈번하게 제공될 경우 개발자의 작업 흐름을 방해하고 도구에 대한 신뢰를 떨어뜨릴 수 있습니다.
+
+## 🔗 Knowledge Connections
+
+### Related Concepts
+- Agentic Coding (에이전틱 코딩): 행동 분석과 의도 추론을 통해 자율적으로 태스크를 수행하는 에이전트 기술입니다.
+- [[Cognitive Load & Mental Models]]: 개발자의 인지적 한계와 정보 탐색 과정에서 형성되는 멘탈 모델의 심리학적 기초입니다.
+- [[Software Maintenance & Evolutionary Design]]: 핫스팟 분석을 통해 기술 부채를 효율적으로 상환하는 유지보수 전략을 다룹니다.
+
+### Practical Application Contexts
+- **System Design:** 개발자 개개인의 컨텍스트를 기억하는 '이중 에이전트(ToM + SWE)' 아키텍처를 설계하여 협업 효율을 높입니다 [2, 5].
+- **Operation:** CodeScene 등의 도구로 프로젝트의 핫스팟을 시각화하여 기술 부채 상환 계획을 수립합니다 [1, 2].
+
+---
+*Last updated: 2026-05-02*