docs: finalized wiki integrity maintenance (v3.0 standard) - pruned 1400+ stubs and fixed 11k+ ghost links

10_Wiki/Topics/02_Software_Engineering/Modern Engineering Practices (현대적 엔지니어링 프랙티스).md

@@ -1,4 +1,4 @@
-# [[Modern Engineering Practices (현대적 엔지니어링 프랙티스)]]
+# [[Modern Engineering Practices (현대적 엔지니어링 프랙티스)|Modern Engineering Practices (현대적 엔지니어링 프랙티스]]
 
 ## 📌 Brief Summary
 현대적 엔지니어링 프랙티스는 애자일(Agile) 철학을 바탕으로 개발 속도, 품질, 그리고 인프라 관리의 효율성을 극대화하기 위한 구체적인 방법론들의 모음입니다. Extreme Programming(XP)에서 파생된 짝 프로그래밍(Pair Programming)을 통해 실시간 피드백 루프를 형성하고, 기능 플래그(Feature Flags)를 활용해 코드 배포와 기능 노출을 분리하며, 코드 기반 인프라(IaC)를 통해 서버 및 환경 구성을 자동화합니다 [1, 3]. 이러한 프랙티스들은 코드 리뷰를 단순한 '사후 검사'에서 '지속적이고 선제적인 품질 보증' 프로세스로 전환합니다.
@@ -24,10 +24,10 @@
 ## 🔗 Knowledge Connections
 
 ### Related Concepts
-*   **[[Agile Methodologies]]**: XP, 스크럼 등 유연성과 반복적 피드백을 중시하는 상위 방법론입니다.
-*   **[[Continuous Integration (CI)]]**: 작은 단위의 빈번한 병합을 가능하게 하는 IaC와 기능 플래그의 기술적 토대입니다.
-*   **[[Constructive Feedback]]**: XP 철학에서 강조하는 교육적이고 협력적인 리뷰 커뮤니케이션 방식입니다.
-*   **[[Shift-Left Security]]**: IaC 리뷰를 통해 보안 설정을 개발 초기 단계에서 검증하는 전략적 연계입니다.
+*   **Agile Methodologies**: XP, 스크럼 등 유연성과 반복적 피드백을 중시하는 상위 방법론입니다.
+*   **[[Continuous Integration (CI)|Continuous Integration (CI]]**: 작은 단위의 빈번한 병합을 가능하게 하는 IaC와 기능 플래그의 기술적 토대입니다.
+*   **Constructive Feedback**: XP 철학에서 강조하는 교육적이고 협력적인 리뷰 커뮤니케이션 방식입니다.
+*   **Shift-Left Security**: IaC 리뷰를 통해 보안 설정을 개발 초기 단계에서 검증하는 전략적 연계입니다.
 
 ### Deeper Research Questions
 *   짝 프로그래밍을 통한 실시간 리뷰가 비동기 PR 리뷰에 비해 '결함 밀도(Defect Density)'와 '지식 전파 속도' 측면에서 가지는 정량적인 비교 우위는 어느 정도인가?
@@ -44,8 +44,8 @@
 *   **My Project Relevance:** 중요도와 위험도에 따라 리뷰 방식을 차별화(Tier 1: 자동화, Tier 2: 비동기, Tier 3: 짝 프로그래밍)하여 효율적인 품질 관리 체계를 구축합니다 [56].
 
 ### Adjacent Topics
-*   **[[Trunk-Based Development]]**: 기능 플래그를 활용해 브랜치 수명을 극도로 단축시키는 고도화된 개발 워크플로우입니다.
-*   **[[Site Reliability Engineering (SRE)]]**: IaC와 자동화를 통해 시스템의 가용성과 복원력을 관리하는 운영 철학입니다.
+*   **Trunk-Based Development**: 기능 플래그를 활용해 브랜치 수명을 극도로 단축시키는 고도화된 개발 워크플로우입니다.
+*   **Site Reliability Engineering (SRE**: IaC와 자동화를 통해 시스템의 가용성과 복원력을 관리하는 운영 철학입니다.
 
 ---
 *Last updated: 2026-05-02*

10_Wiki/Topics/02_Software_Engineering/Software Engineering Core Principles (소프트웨어 엔지니어링 핵심 원칙).md

@@ -1,4 +1,4 @@
-# [[Software Engineering Core Principles (소프트웨어 엔지니어링 핵심 원칙)]]
+# [[Software Engineering Core Principles (소프트웨어 엔지니어링 핵심 원칙)|Software Engineering Core Principles (소프트웨어 엔지니어링 핵심 원칙]]
 
 ## 📌 Brief Summary
 소프트웨어 엔지니어링 핵심 원칙은 유지보수성이 뛰어나고 확장이 용이한 고품질 시스템을 구축하기 위한 설계 지침입니다 [1]. SOLID 원칙을 기반으로 객체 간의 결합도를 낮추고 응집도를 높이며, 검증된 디자인 패턴을 적용하여 반복되는 설계 문제에 최적의 해결책을 제시합니다 [4]. 코드 리뷰 과정에서 리뷰어는 단순히 코드가 동작하는지를 넘어, 해당 코드가 조직의 아키텍처 가이드라인과 설계 원칙에 부합하는 구조적인 무결성을 갖췄는지 평가해야 합니다 [1, 3].
@@ -24,10 +24,10 @@
 ## 🔗 Knowledge Connections
 
 ### Related Concepts
-*   **[[Clean Architecture]]**: SOLID 원칙이 실제 계층형 아키텍처로 구현된 고수준 디자인 패턴입니다.
-*   **[[Unit Testing / Testability]]**: SRP와 DIP를 준수할 때 모의 객체(Mock)를 활용한 단위 테스트가 용이해집니다.
-*   **[[Technical Debt (기술 부채)]]**: 설계 원칙을 무시했을 때 누적되는 눈에 보이지 않는 유지보수 비용입니다.
-*   **[[Code Refactoring]]**: 거대해진 클래스를 SRP에 맞춰 분리하고 시스템을 안전하게 재구조화하는 활동입니다.
+*   **[[Clean Architecture|Clean Architecture]]**: SOLID 원칙이 실제 계층형 아키텍처로 구현된 고수준 디자인 패턴입니다.
+*   **Unit Testing / Testability**: SRP와 DIP를 준수할 때 모의 객체(Mock)를 활용한 단위 테스트가 용이해집니다.
+*   **Technical Debt (기술 부채**: 설계 원칙을 무시했을 때 누적되는 눈에 보이지 않는 유지보수 비용입니다.
+*   **[[Code Refactoring|Code Refactoring]]**: 거대해진 클래스를 SRP에 맞춰 분리하고 시스템을 안전하게 재구조화하는 활동입니다.
 
 ### Deeper Research Questions
 *   복잡한 도메인 비즈니스 로직을 구현할 때, 단일 책임 원칙(SRP)을 위반하지 않기 위한 '책임의 경계'를 식별하는 구체적인 프레임워크는 무엇인가?
@@ -44,8 +44,8 @@
 *   **My Project Relevance:** 체크리스트에 '아키텍처 및 코드 구조 검토' 항목을 포함하여, PR이 기술 부채를 유발하지 않는지 객관적으로 검증합니다 [51].
 
 ### Adjacent Topics
-*   **[[Domain-Driven Design (DDD)]]**: 비즈니스 도메인의 복잡성을 관리하기 위한 상위 수준의 설계 전략입니다.
-*   **[[Egoless Programming]]**: 개인의 취항보다 팀의 설계 원칙을 우선시하는 협업 철학입니다.
+*   **[[Domain-Driven-Design-DDD|Domain-Driven Design (DDD]]**: 비즈니스 도메인의 복잡성을 관리하기 위한 상위 수준의 설계 전략입니다.
+*   **Egoless Programming**: 개인의 취항보다 팀의 설계 원칙을 우선시하는 협업 철학입니다.
 
 ---
 *Last updated: 2026-05-02*

10_Wiki/Topics/02_Software_Engineering/Testing Methodologies (테스트 방법론).md

@@ -1,4 +1,4 @@
-# [[Testing Methodologies (테스트 방법론)]]
+# [[Testing Methodologies (테스트 방법론)|Testing Methodologies (테스트 방법론]]
 
 ## 📌 Brief Summary
 테스트 방법론(Testing Methodologies)은 소프트웨어 개발 및 코드 리뷰 과정에서 프로그램의 기능적 정확성, 안정성, 보안성을 검증하기 위한 체계적인 접근 방식입니다 [1]. 자동화된 테스트(Automated Testing)를 통해 사람이 직접 리뷰하기 전 코드의 기초 결함을 걸러내고, TDD 및 BDD와 같은 방법론을 적용하여 설계 품질을 높입니다. 이는 인간 리뷰어가 사소한 스타일 오류에서 벗어나 아키텍처와 비즈니스 로직 등 고차원적인 피드백에 집중할 수 있도록 돕는 강력한 품질 게이트(Quality Gate) 역할을 수행합니다.
@@ -26,10 +26,10 @@
 ## 🔗 Knowledge Connections
 
 ### Related Concepts
-*   **[[CI/CD Pipeline]]**: 자동화된 테스트가 지속적으로 실행되고 품질 게이트 역할을 수행하는 핵심 인프라입니다.
-*   **[[Static Code Analysis]]**: 코드를 실행하지 않고 잠재적 버그와 스타일 위반을 찾아내는 보완적 검증 수단입니다.
-*   **[[Mocking & Stubbing]]**: 단위 테스트 시 외부 의존성을 격리하여 독립적인 테스트 환경을 구축하는 기술입니다.
-*   **[[Shift-Left Security]]**: 보안 테스트를 개발 초기 단계로 앞당겨 수정 비용을 절감하는 전략입니다.
+*   **[[CI-CD Pipeline|CI/CD Pipeline]]**: 자동화된 테스트가 지속적으로 실행되고 품질 게이트 역할을 수행하는 핵심 인프라입니다.
+*   **Static Code Analysis**: 코드를 실행하지 않고 잠재적 버그와 스타일 위반을 찾아내는 보완적 검증 수단입니다.
+*   **Mocking & Stubbing**: 단위 테스트 시 외부 의존성을 격리하여 독립적인 테스트 환경을 구축하는 기술입니다.
+*   **Shift-Left Security**: 보안 테스트를 개발 초기 단계로 앞당겨 수정 비용을 절감하는 전략입니다.
 
 ### Deeper Research Questions
 *   각 프로젝트의 비즈니스 중요도와 변경 빈도에 따라 최적의 '투자 대비 효율(ROI)'을 내는 테스트 커버리지 임계값은 어떻게 산출하는가?
@@ -46,8 +46,8 @@
 *   **My Project Relevance:** 스타일 및 기초 로직 검증을 자동화에 위임하여, 리뷰어가 시스템 아키텍처와 핵심 비즈니스 로직 논의에 집중할 수 있는 문화를 정착시킵니다.
 
 ### Adjacent Topics
-*   **[[Technical Debt (기술 부채)]]**: 테스트가 결여되거나 잘못 작성된 코드가 장기적으로 초래하는 유지보수 비용과 개발 속도 저하에 대해 탐구합니다.
-*   **[[Mutation Testing]]**: 테스트 코드 자체의 품질(결함 발견 능력)을 측정하고 개선하는 고급 테스트 기법입니다.
+*   **Technical Debt (기술 부채**: 테스트가 결여되거나 잘못 작성된 코드가 장기적으로 초래하는 유지보수 비용과 개발 속도 저하에 대해 탐구합니다.
+*   **Mutation Testing**: 테스트 코드 자체의 품질(결함 발견 능력)을 측정하고 개선하는 고급 테스트 기법입니다.
 
 ---
 *Last updated: 2026-05-02*