Standardize: Wikified 00_Raw and consolidated 10_Wiki/Topics into P-Reinforce v3.0 clusters. Final cleanup of ghost nodes and stubs.

2026-05-02 12:54:41 +09:00
parent 6445fcc05b
commit 7749ff0e40
10 changed files with 407 additions and 33 deletions
@@ -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*
@@ -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*