[G1-Sync] Manual knowledge update

2026-05-01 20:45:18 +09:00
parent e56d8c7cf9
commit 13f58a24de
40 changed files with 1577 additions and 23 deletions
@@ -0,0 +1,36 @@
+---
+id: P-REINFORCE-AUTO-WIKI-ARC-002
+category: "10_Wiki/💡 Topics/02_Architecture_Principles"
+confidence_score: 0.95
+tags: [architecture, dependency-management, dependency-injection, di, dependency-inversion-principle, dip, decoupling, p-reinforce]
+last_reinforced: 2026-05-01
+---
+
+# [[Dependency Management (DI & DIP)]]
+
+## 📌 한 줄 통찰 (The Karpathy Summary)
+> "구체적인 구현이 아닌 추상화에 의존하게 하여 컴포넌트 간의 결합도를 낮추고, 코드 수정 없이 기능을 확장하거나 교체할 수 있는 유연한 시스템 구조의 핵심 기법."
+
+## 📖 구조화된 지식 (Synthesized Content)
+의존성 관리는 소프트웨어의 모듈성과 테스트 가능성을 결정짓는 가장 중요한 설계 요소입니다.
+
+1.  **[[Dependency Inversion Principle (DIP)]]**:
+    *   **고수준 모듈의 보호**: 고수준 모듈(비즈니스 로직)은 저수준 모듈(데이터베이스, 외부 API)의 구체적인 구현에 의존해서는 안 됩니다. 둘 다 추상화(인터페이스)에 의존해야 합니다.
+    *   **의존성 방향의 역전**: 전통적인 계층 구조에서의 의존성 방향을 뒤집어, 구현체가 인터페이스를 따르게 함으로써 핵심 로직을 외부 변화로부터 보호합니다.
+2.  **[[Dependency Injection (DI)]]**:
+    *   **객체 생성이 아닌 주입**: 클래스 내부에서 의존 객체를 직접 생성(New)하지 않고, 외부(생성자, 메서드 등)에서 주입받습니다.
+    *   **유연한 교체**: 인터페이스를 통해 종속성을 주입받으므로, 실제 구현체를 환경(Staging, Production)이나 테스트 목적(Mocking)에 따라 쉽게 교체할 수 있습니다.
+3.  **코드 리뷰에서의 역할**:
+    *   리뷰어는 코드가 하드코딩된 종속성을 가지고 있는지, 인터페이스를 통해 결합도가 적절히 분리(Decoupled)되었는지 검증합니다.
+
+## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
+- **추상화의 비용**: 모든 관계에 DI/DIP를 적용하면 코드 가독성이 떨어지고 추적하기 어려워질 수 있습니다. '과잉 엔지니어링(Over-engineering)'을 경계하며, 변화가 잦거나 테스트가 필수적인 영역을 중심으로 적용하는 실용성이 필요합니다.
+- **의존성 그래프의 복잡성**: 주입되는 객체가 많아지면 객체 생성 로직이나 DI 컨테이너 설정이 복잡해집니다. 생성자 주입(Constructor Injection)을 권장하고 클래스의 책임을 작게 유지하여 주입되는 의존성 수를 제한해야 합니다.
+
+## 🔗 지식 연결 (Graph)
+- [[SOLID Principles]]: DIP가 포함된 설계 원칙 그룹.
+- [[Clean Architecture & Patterns]]: DIP를 통해 도메인 로직을 보호하는 상위 아키텍처.
+- [[Testing Strategy]]: DI가 가능하게 하는 테스트 용이성.
+- [[Single Responsibility Principle (SRP)]]: 의존성이 많아지는 것을 방지하는 근거.
+- [[Over-engineering]]: 무분별한 추상화의 위험.
+---