diff --git a/10_Wiki/Topics_Dev/Code_Review_Methodology.md b/10_Wiki/Topics_Dev/Code_Review_Methodology.md
new file mode 100644
index 00000000..e12a5e04
--- /dev/null
+++ b/10_Wiki/Topics_Dev/Code_Review_Methodology.md
@@ -0,0 +1,46 @@
+---
+id: P-REINFORCE-WIKI-DEV-CODE-REVIEW
+title: "코드 리뷰 방법론 (Code Review Methodology)"
+category: "10_Wiki/💻 Topics_Dev"
+status: verified
+canonical_id: ""
+aliases: ["코드 리뷰", "PR 리뷰", "Peer Review"]
+duplicate_of: ""
+source_trust_level: A
+confidence_score: 1.0
+tags: ["Code_Review", "Collaboration", "Quality_Assurance", "Software_Engineering", "AI_Review"]
+raw_sources: ["Datacollector_Export_2026-05-02"]
+last_reinforced: 2026-05-02
+github_commit: ""
+---
+
+# [[코드 리뷰 방법론 (Code Review Methodology)]]
+
+## 1. 개요
+코드 리뷰(Code Review)는 제안된 코드 변경 사항에 대해 협업자들이 검토하고 의견을 나누는 필수적인 개발 프로세스이다. 단순 버그 탐지를 넘어 팀 내 지식 교환, 설계 검증, 코드베이스 품질 유지를 위한 핵심적인 협업 수단이다.
+
+## 2. 효과적인 리뷰의 원칙
+- **구체성과 명확성**: 모호한 코멘트 대신 구체적인 이유와 대안 예시를 제시.
+- **차단(Blocking) 여부 명시**: 개인적 선호도와 반드시 수정해야 할 요건을 구분.
+- **긍정적 피드백**: 훌륭한 구현에 대해 찬사(Affirmation)를 보내 인지적 부담 경감.
+- **신속한 의사결정**: 치명적 결함이 없다면 배포 속도(Velocity)를 위해 승인을 지연하지 않음.
+
+## 3. 대규모 코드베이스 리뷰 전략
+- **하향식 접근 (High-to-Low)**: 상위 아키텍처부터 세부 로직 순으로 반복 리뷰.
+- **분할 정복**: 논리적 모듈(인증, DB, UI 등) 단위로 나누어 인지 부하 관리.
+- **컨텍스트 활용**: 커밋 이력, 이슈 설명 등을 통해 설계 의도(Why)를 파악.
+
+## 4. AI 기반 자동화 및 최신 트렌드
+- **AI 리뷰어 연동**: CodeRabbit, Qodo 등을 통한 보안/모듈성 자동 분석.
+- **MCP 활용**: AI 에이전트가 직접 저장소를 탐색하며 대화형으로 리뷰 수행.
+- **SAST 통합**: 정적 분석 도구를 CI에 통합하여 인간 리뷰어의 단순 작업(포맷팅, 기본 보안 체크 등) 경감.
+
+## 5. 지식 연결 (Related)
+- [[AI_Code_Review_Tools]]: 자동화된 리뷰를 돕는 전용 도구들.
+- [[Test_Driven_Development]]: 리뷰 전 코드의 신뢰성을 보장하는 방법론.
+- [[Technical_Debt]]: 리뷰 시 타협된 코드가 관리되어야 할 방향.
+
+## 🧪 검증 상태 (Validation)
+- **정보 상태**: 검증 완료 (Verified)
+- **출처 신뢰도**: A
+- **검토 이유**: 협업 효율과 소프트웨어 품질을 결정짓는 핵심 공학 프로세스 정립.
diff --git a/10_Wiki/Topics_Dev/Legacy_Modernization_Strategy.md b/10_Wiki/Topics_Dev/Legacy_Modernization_Strategy.md
new file mode 100644
index 00000000..8d99ab70
--- /dev/null
+++ b/10_Wiki/Topics_Dev/Legacy_Modernization_Strategy.md
@@ -0,0 +1,41 @@
+---
+id: P-REINFORCE-WIKI-DEV-LEGACY-MODERNIZATION
+title: "레거시 모더니제이션 전략 (Legacy Modernization Strategy)"
+category: "10_Wiki/💻 Topics_Dev"
+status: verified
+canonical_id: ""
+aliases: ["Legacy Modernization", "레거시 개선", "시스템 현대화"]
+duplicate_of: ""
+source_trust_level: A
+confidence_score: 1.0
+tags: ["Legacy_System", "Modernization", "Refactoring", "Microservices", "Technical_Debt"]
+raw_sources: ["Datacollector_Export_2026-05-02"]
+last_reinforced: 2026-05-02
+github_commit: ""
+---
+
+# [[레거시 모더니제이션 전략 (Legacy Modernization Strategy)]]
+
+## 1. 개요
+레거시 모더니제이션(Legacy Modernization)은 복잡하고 접근하기 어려운 기존 시스템(모놀리스 등)을 분석하여 유지보수성을 높이고, 마이크로서비스 등 현대적인 아키텍처로 개선하는 일련의 과정이다. 비즈니스 로직을 추출하고 시각화하여 시스템의 투명성을 확보하는 것이 핵심이다.
+
+## 2. 주요 전략 및 기술
+- **아키텍처 변환**: 모놀리스를 마이크로서비스로 분해하여 배포 속도(Velocity)를 개선.
+- **AI 기반 로직 추출**: 오래된 스택(COBOL, Oracle Forms 등)에서 비즈니스 로직을 추출하고 '살아있는 지식 기반' 구축 (예: Kodesage 활용).
+- **행위 기반 분석 (Behavioral Analysis)**: 코드 자체뿐만 아니라 수정 빈도(Churn) 등 Git 히스토리를 분석하여 리팩토링 우선순위(Hotspots) 식별 (예: CodeScene 활용).
+- **점진적 SOLID 적용**: 전체 재설계 대신 신규 기능 추가나 수정 시점에 맞춰 부분적으로 설계 원칙을 적용.
+
+## 3. 트레이드오프 및 주의사항
+- **아키텍처 드리프트 (Architectural Drift)**: 전환 과정에서 설계와 실제 구현 간의 괴리가 발생하지 않도록 실시간 모니터링 필수.
+- **데이터 부족 문제**: 행위 기반 분석 모델의 유효성을 위해서는 최소 6개월 이상의 충분한 Git 히스토리가 필요함.
+- **엣지 케이스 누락**: 자동화된 분석 도구가 레거시 시스템의 특수한 예외 케이스를 놓칠 위험 상존.
+
+## 4. 지식 연결 (Related)
+- [[Microservices_Architecture]]: 모더니제이션의 주요 지향점.
+- [[Refactoring_Best_Practices]]: 시스템을 개선하기 위한 기술적 실천 방안.
+- [[C4_Model]]: 레거시 구조 시각화 및 문서화를 위한 계층적 모델링 기법.
+
+## 🧪 검증 상태 (Validation)
+- **정보 상태**: 검증 완료 (Verified)
+- **출처 신뢰도**: A
+- **검토 이유**: 대규모 기업용 시스템의 생존과 진화를 위한 전략적 가이드라인 정립.
diff --git a/10_Wiki/Topics_Dev/Refactoring_Best_Practices.md b/10_Wiki/Topics_Dev/Refactoring_Best_Practices.md
new file mode 100644
index 00000000..f4ec7509
--- /dev/null
+++ b/10_Wiki/Topics_Dev/Refactoring_Best_Practices.md
@@ -0,0 +1,47 @@
+---
+id: P-REINFORCE-WIKI-DEV-REFACTORING
+title: "리팩토링 실전 가이드 (Refactoring Best Practices)"
+category: "10_Wiki/💻 Topics_Dev"
+status: verified
+canonical_id: ""
+aliases: ["리팩토링", "Refactoring", "코드 정제"]
+duplicate_of: ""
+source_trust_level: A
+confidence_score: 1.0
+tags: ["Refactoring", "Clean_Code", "Code_Smells", "Maintainability", "Technical_Debt"]
+raw_sources: ["Datacollector_Export_2026-05-02"]
+last_reinforced: 2026-05-02
+github_commit: ""
+---
+
+# [[리팩토링 실전 가이드 (Refactoring Best Practices)]]
+
+## 1. 개요
+리팩토링(Refactoring)은 소프트웨어의 외부 동작은 유지하면서 내부 구조를 개선하여 가독성을 높이고 복잡성을 줄이는 과정이다. 기술적 부채를 상환하고 변화하는 비즈니스 요구사항에 유연하게 대응할 수 있는 아키텍처 토대를 마련하는 데 목적이 있다.
+
+## 2. 핵심 전략
+- **코드 악취(Code Smells) 식별**: 비대해진 메서드, 데이터 뭉치, 기능 편애 등 리팩토링이 필요한 신호를 포착.
+- **점진적 접근**: 전체 시스템을 한꺼번에 바꾸기보다, 기능 추가나 수정 시점에 맞춰 '고통이 큰 영역'부터 개선.
+- **추상화 도입**: 반복되는 논리를 식별하여 적절한 추상화 계층으로 분리하되, 성급한 추상화(Premature Abstraction)는 경계.
+- **안전한 변경**: 단위 테스트를 통해 리팩토링 후에도 기존 기능이 훼손되지 않았음을 보장.
+
+## 3. 주요 리팩토링 기법
+- **Composing Methods**: 메서드 추출(Extract Method), 임시 변수 인라인화 등.
+- **객체 간 기능 이동**: 함수/필드 이동을 통해 결합도 완화.
+- **조건문 단순화**: 조건문 분해, 가드 절(Guard Clauses) 활용.
+- **추상화 강화**: 상속 구조 정리, 인터페이스 추출.
+
+## 4. 트레이드오프 및 주의사항
+- **장점**: 유지보수성 향상, 버그 발견 용이성, 개발 생산성 개선.
+- **단점**: 잘못된 추상화로 인한 복잡성 증가, 대규모 작업 시 인지적 피로 및 비용 발생.
+- **심리적 장벽**: 복잡한 레거시 코드를 건드리는 것에 대한 두려움으로 인해 리팩토링이 방치되는 '깨진 유리창 법칙' 경계.
+
+## 5. 지식 연결 (Related)
+- [[SOLID_Principles]]: 리팩토링의 궁극적인 목표 지점인 설계 원칙.
+- [[Code_Smells_Catalog]]: 리팩토링의 대상이 되는 문제 패턴 모음.
+- [[Legacy_Modernization_Strategy]]: 대규모 시스템 차원의 리팩토링 및 개선 전략.
+
+## 🧪 검증 상태 (Validation)
+- **정보 상태**: 검증 완료 (Verified)
+- **출처 신뢰도**: A
+- **검토 이유**: 소프트웨어의 건강함을 유지하기 위한 지속적 개선 방법론 확립.
diff --git a/10_Wiki/Topics_Dev/Test_Driven_Development.md b/10_Wiki/Topics_Dev/Test_Driven_Development.md
new file mode 100644
index 00000000..f5ca6643
--- /dev/null
+++ b/10_Wiki/Topics_Dev/Test_Driven_Development.md
@@ -0,0 +1,43 @@
+---
+id: P-REINFORCE-WIKI-DEV-TDD
+title: "테스트 주도 개발 (Test-Driven Development, TDD)"
+category: "10_Wiki/💻 Topics_Dev"
+status: verified
+canonical_id: ""
+aliases: ["TDD", "테스트 퍼스트", "Test-Driven Development"]
+duplicate_of: ""
+source_trust_level: A
+confidence_score: 1.0
+tags: ["TDD", "Software_Testing", "Clean_Architecture", "Mocking", "Quality_Assurance"]
+raw_sources: ["Datacollector_Export_2026-05-02"]
+last_reinforced: 2026-05-02
+github_commit: ""
+---
+
+# [[테스트 주도 개발 (Test-Driven Development, TDD)]]
+
+## 1. 개요
+Test-Driven Development(TDD)는 실제 구현 코드를 작성하기 전에 테스트 코드를 먼저 작성하여 애플리케이션의 로직을 검증하고 설계를 발전시키는 소프트웨어 개발 방법론이다. 'Red(실패하는 테스트) - Green(테스트 통과) - Refactor(리팩토링)' 사이클을 통해 시스템의 신뢰성과 유지보수성을 극대화한다.
+
+## 2. 핵심 원칙
+- **테스트 우선 (Test-First)**: 요구사항을 만족하는 최소한의 테스트 코드를 먼저 작성.
+- **도메인 격리**: 비즈니스 로직을 외부 인프라(DB, UI)로부터 분리하여 독립적으로 검증.
+- **반복적 정제**: 테스트를 통과한 후 코드를 정제(Refactoring)하여 코드 품질을 지속적으로 관리.
+
+## 3. 프레임워크별 실전 적용
+- **모바일 (Flutter)**: 클린 아키텍처와 결합하여 Domain 계층의 유스케이스를 BLoC 등과 분리해 테스트.
+- **백엔드 (Spring Boot)**: 육각형 아키텍처를 기반으로 Mockito(모킹)나 H2(인메모리 DB)를 활용해 도메인 로직 검증.
+
+## 4. 트레이드오프 및 주의사항
+- **장점**: 높은 코드 신뢰성, 설계 개선, 회귀 버그(Regression) 방지.
+- **단점 (Mocking Caveat)**: 과도한 모킹 사용 시 도메인의 기능적 결함을 은폐하거나 테스트 코드 자체가 구현에 강결합될 위험. (기능 결함에도 불구하고 테스트는 통과하는 현상 방지 필요)
+
+## 5. 지식 연결 (Related)
+- [[Clean_Architecture]]: TDD를 수행하기 위한 구조적 토대.
+- [[Hexagonal_Architecture]]: 외부 의존성을 배제하고 도메인을 테스트하기 위한 아키텍처.
+- [[Code_Review_Methodology]]: 작성된 테스트와 코드의 품질을 교차 검증하는 과정.
+
+## 🧪 검증 상태 (Validation)
+- **정보 상태**: 검증 완료 (Verified)
+- **출처 신뢰도**: A
+- **검토 이유**: 안정적인 코드베이스 유지를 위한 핵심 공학적 실천 방안 정립.
diff --git a/10_Wiki/Topics_Infra/CI_CD_Pipeline.md b/10_Wiki/Topics_Infra/CI_CD_Pipeline.md
new file mode 100644
index 00000000..e7983b56
--- /dev/null
+++ b/10_Wiki/Topics_Infra/CI_CD_Pipeline.md
@@ -0,0 +1,45 @@
+---
+id: P-REINFORCE-WIKI-INFRA-CI-CD
+title: "지속적 통합 및 배포 (CI/CD Pipeline)"
+category: "10_Wiki/☁️ Topics_Infra"
+status: verified
+canonical_id: ""
+aliases: ["CI/CD", "지속적 통합", "지속적 배포", "Deployment Pipeline"]
+duplicate_of: ""
+source_trust_level: A
+confidence_score: 1.0
+tags: ["DevOps", "CI_CD", "Automation", "Security_Scanning", "GitOps"]
+raw_sources: ["Datacollector_Export_2026-05-02"]
+last_reinforced: 2026-05-02
+github_commit: ""
+---
+
+# [[지속적 통합 및 배포 (CI/CD Pipeline)]]
+
+## 1. 개요
+CI/CD(Continuous Integration/Continuous Deployment)는 소프트웨어 개발 생명주기(SDLC) 전반에서 코드 푸시, 테스트, 분석, 빌드, 배포 과정을 자동화하는 파이프라인이다. 개발자가 작성한 코드가 안정적으로 사용자에게 전달될 수 있도록 하는 기술적 방어선이자 엔진 역할을 한다.
+
+## 2. 주요 구성 요소
+- **지속적 통합 (CI)**: 새로운 코드가 병합될 때마다 자동 테스트 및 린팅을 수행하여 메인 브랜치의 안정성을 유지.
+- **지속적 배포 (CD)**: 테스트를 통과한 코드를 실제 운영 환경에 자동으로 배포하거나 배포 준비 상태로 유지.
+- **품질 게이트 (Quality Gates)**: SAST, SCA 등의 보안/품질 분석 도구를 통합하여 기준 미달 코드의 병합을 자동 차단.
+- **GitOps**: Git 리포지토리를 인프라와 배포의 단일 진실의 원천(Source of Truth)으로 삼는 오케스트레이션 방식.
+
+## 3. 아키텍처적 가치
+- **MSA 연동**: 각 서비스별 독립 파이프라인을 구축하여 모놀리스 대비 높은 배포 민첩성 확보.
+- **클라우드 네이티브**: 컨테이너 및 서버리스 환경과 결합하여 자동 확장 및 복원력 있는 시스템 운영 지원.
+- **보안 강화 (DevSecOps)**: 코드 병합 이전에 취약점 스캔을 자동화하여 보안 위협의 Shift-Left(초기화) 실현.
+
+## 4. 트레이드오프 및 주의사항
+- **장점**: 개발 속도 향상, 회귀 버그 조기 발견, 배포 스트레스 감소.
+- **단점**: 파이프라인 구축 및 유지보수 비용, 무거운 분석 도구 도입 시 빌드 시간 증가(CI 속도 저하), 오탐(False Positive)으로 인한 개발 병목 현상.
+
+## 5. 지식 연결 (Related)
+- [[Microservices_Architecture]]: 독립적 배포를 위한 구조적 토대.
+- [[SAST_Security_Testing]]: 파이프라인 내 보안 검증 기술.
+- [[GitOps_Workflow]]: 인프라와 배포를 코드로 관리하는 방법론.
+
+## 🧪 검증 상태 (Validation)
+- **정보 상태**: 검증 완료 (Verified)
+- **출처 신뢰도**: A
+- **검토 이유**: 고가용성 및 고효율 소프트웨어 배포 체계의 핵심 인프라 원칙 정립.