[P-Reinforce] Global knowledge consolidation, massive deduplication (5,249 files), and high-density wikification (45 nodes)

2026-05-05 15:28:22 +09:00
parent a7d1e60ccf
commit dd01e01bea
3430 changed files with 42739 additions and 52263 deletions
@@ -0,0 +1,33 @@
+---
+id: P-REINFORCE-AUTO-WIKI-ARCH-001
+category: "10_Wiki/💡 Topics/02_Architecture_Principles"
+confidence_score: 0.95
+tags: [architecture, ooad, solid-principles, maintainability, code-review, p-reinforce]
+last_reinforced: 2026-05-01
+---
+
+# [[SOLID Principles]]
+
+## 📌 한 줄 통찰 (The Karpathy Summary)
+> "소프트웨어의 유지보수성과 확장성을 보장하기 위한 5가지 핵심 설계 기둥: 인지적 부하를 낮추고, 변화에 유연하며, 결합도가 낮은 강건한 시스템을 구축하기 위한 객체지향 설계의 표준 지침."
+
+## 📖 구조화된 지식 (Synthesized Content)
+SOLID 원칙은 코드 리뷰와 시스템 설계의 무결성을 평가하는 핵심 기준입니다.
+
+1.  **[[Single Responsibility Principle (SRP)]]**: 클래스나 함수는 단 하나의 변경 이유만을 가져야 합니다. 모듈화를 통해 가독성과 테스트 용이성을 극대화합니다.
+2.  **Open-Closed Principle (OCP)**: 확장에는 열려 있고 수정에는 닫혀 있어야 합니다. 기존 코드를 건드리지 않고 새로운 기능을 추가할 수 있는 구조를 지향합니다.
+3.  **Liskov Substitution Principle (LSP)**: 하위 타입은 언제나 상위 타입으로 교체 가능해야 합니다. 상속 구조에서의 행동 일관성을 보장합니다.
+4.  **Interface Segregation Principle (ISP)**: 클라이언트가 사용하지 않는 메서드에 의존하도록 강요해서는 안 됩니다. 거대한 인터페이스보다 구체적이고 작은 인터페이스 여러 개가 낫습니다.
+5.  **[[Dependency Inversion Principle (DIP)]]**: 고수준 모듈은 저수준 모듈에 의존해서는 안 되며, 둘 다 추상화에 의존해야 합니다. 구체적인 구현이 아닌 추상화에 의존하여 결합도를 낮춥니다.
+
+## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
+- **추상화의 비용**: 확장성을 위해 인터페이스와 추상화를 과도하게 도입할 경우, 코드의 직관성이 떨어지고 오버엔지니어링(Over-engineering)으로 이어질 수 있습니다. 현재의 요구사항과 미래의 유연성 사이의 실용적 타협(Trade-off)이 필수적입니다.
+- **실행 흐름 파악의 어려움**: DI(의존성 주입)를 극한으로 활용할 경우 런타임에 의존성이 결정되므로, 코드 정적 분석만으로는 전체 실행 흐름을 파악하기 어려워질 수 있습니다. 이를 보완하기 위한 명확한 문서화와 추적 로직이 필요합니다.
+
+## 🔗 지식 연결 (Graph)
+- [[Single Responsibility Principle (SRP)]]: 첫 번째 원칙의 심화.
+- [[Dependency Injection (DI)]]: DIP를 실현하는 구체적 기법.
+- [[Clean Architecture]]: SOLID를 애플리케이션 전체로 확장한 구조.
+- [[Abstraction & Over-engineering]]: 설계 시 경계해야 할 트레이드오프.
+- [[Test-Driven Development (TDD)]]: 테스트하기 좋은 코드를 만드는 원칙으로서의 연결.
+---
@@ -0,0 +1,36 @@
+---
+id: P-REINFORCE-AUTO-WIKI-ARCH-002
+category: "10_Wiki/💡 Topics/02_Architecture_Principles"
+confidence_score: 0.95
+tags: [architecture, srp, cohesion, refactoring, code-review, p-reinforce]
+last_reinforced: 2026-05-01
+---
+
+# [[Single Responsibility Principle (SRP)]]
+
+## 📌 한 줄 통찰 (The Karpathy Summary)
+> "하나의 모듈은 오직 하나의 변경 이유(Reason to change)만을 가져야 한다: 코드의 응집도를 높이고 복잡성을 분산하여, 버그 수정과 기능 확장이 다른 영역에 미치는 부작용을 최소화하는 설계의 기초."
+
+## 📖 구조화된 지식 (Synthesized Content)
+SRP는 객체 지향 설계의 첫 번째 단추이자 가장 보편적인 리뷰 기준입니다.
+
+1.  **단일 책임의 기준**:
+    *   클래스나 함수가 수행하는 '일(Task)'이 아니라, 그 코드를 관리하고 요구사항을 변경하는 '주체(Actor)'가 누구인가에 집중합니다.
+    *   비즈니스 로직, 데이터베이스 접근, UI 렌더링 등이 하나의 파일에 섞여 있다면 이는 명백한 SRP 위반입니다.
+2.  **코드 리뷰의 핵심 필터**:
+    *   리뷰어는 거대한 함수나 클래스를 발견했을 때 이를 논리적 단위로 쪼개도록 권고합니다.
+    *   모듈이 작아질수록 테스트 코드를 작성하기 쉬워지며, 특정 기능만 떼어내어 재사용하기 용이해집니다.
+3.  **결합도와 응집도**:
+    *   책임이 명확히 분리된 코드는 낮은 결합도(Low Coupling)와 높은 응집도(High Cohesion)를 가지게 되어, 전체 시스템의 유지보수 비용을 낮춥니다.
+
+## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
+- **과도한 파편화**: SRP를 극단적으로 적용할 경우 클래스와 파일 수가 기하급수적으로 증가하여 전체 시스템의 가독성을 해칠 수 있습니다. '논리적 연관성'이 높은 코드들은 적절한 수준에서 함께 유지하는 실용적 균형이 필요합니다.
+- **아키텍처적 부채**: 초기 설계 시 SRP를 무시하면 시간이 흐를수록 '신(God) 객체'가 탄생하며, 이는 리팩토링 비용을 기하급수적으로 증가시키는 주요 원인이 됩니다.
+
+## 🔗 지식 연결 (Graph)
+- [[SOLID Principles]]: 5대 원칙의 시작점.
+- [[Testability]]: 테스트하기 좋은 코드를 만드는 직접적 원인.
+- [[Refactoring]]: SRP 위반 시 리뷰어가 내리는 핵심 처방.
+- [[Clean Architecture]]: 책임을 계층별로 격리하는 거시적 구조.
+- [[Code Readability]]: 단순해진 코드가 가져오는 가독성 향상.
+---