feat: Wiki 지식 자산 업데이트 - UX Scenarios, Frontend, Game Design, Topics 추가 [2026-05-08]

10_Wiki/Topics/Architecture/Dependency-Injection.md

@@ -1,13 +1,26 @@
 ---
-category: Unified
+id: wiki-2026-0508-dependency-injection
+title: Dependency Injection
+category: 10_Wiki/Topics
+status: needs_review
+canonical_id: self
+aliases: []
+duplicate_of: none
+source_trust_level: A
+confidence_score: 0.92
 tags: [auto-consolidated, technical-documentation]
-title: [[Dependency-Injection|Dependency-Injection]] (의존성 주입)
-last_updated: 2026-05-02
+raw_sources: []
+last_reinforced: 2026-05-08
+github_commit: pending
+inferred_by: Claude Opus 4.7 (auto-normalize 2026-05-08)
+tech_stack:
+  language: unspecified
+  framework: unspecified
 ---
 
 # [[Dependency-Injection|Dependency-Injection]] (의존성 주입)
 
-## 📌 Brief Summary
+## 📌 한 줄 통찰 (The Karpathy Summary)
 > "직접 사러 가지 말고, 배달받아 써라." 객체가 필요한 의존 객체를 스스로 생성하지 않고, 외부에서 주입받음으로써 코드 간의 결합도를 낮추고 테스트 용이성을 극대화하는 디자인 패턴이다.
 
 ---
@@ -24,7 +37,7 @@ last_updated: 2026-05-02
 
 의존성 주입(Dependency Injection, DI)은 상위 계층이 하위 계층의 인스턴스를 직접 생성하는 대신, 외부에서 의존성을 "주입"하여 구성 요소 간의 결합도를 낮추는 소프트웨어 엔지니어링 기법이다 [1]. 핵심 비즈니스 로직을 변경하지 않고도 종속성을 관리하거나 특정 구현체를 쉽게 교체할 수 있게 해준다 [2]. 의존성 역전 원칙(DIP)을 달성하기 위한 대표적인 구현 방법으로 사용되며, 애플리케이션의 테스트 용이성과 유지보수성을 크게 향상시킨다 [2, 3].
 
-## 📖 Core Content
+## 📖 구조화된 지식 (Synthesized Content)
 - **The Core Concept**:
     - 클래스 내부에서 `new Service()`를 호출하는 순간, 그 클래스는 해당 서비스에 강하게 결합(Coupled)된다.
     - DI는 생성자(Constructor)나 메서드 인자를 통해 외부에서 구현체를 전달받는다.
@@ -70,7 +83,7 @@ DI는 **제어의 역전(Inversion of Control)**을 실현하는 구체적인
 * **계층형 아키텍처(Layered Architecture) 내에서의 역할**: 계층 간의 엄격한 통신을 강제하고 종속성을 관리하기 위해 DI를 구현한다 [1]. 상위 계층이 하위 계층의 객체를 직접 생성하는 방식 대신, 외부 소스로부터 의존성이 주입되게 함으로써 결합도를 느슨하게 만든다 [1]. 
 * **클린 아키텍처(Clean Architecture)와의 결합**: 비즈니스 로직을 외부의 데이터베이스나 웹 프레임워크로부터 격리시키는 클린 아키텍처에서 DI는 필수적으로 사용된다 [5, 6]. 내부 계층에서 인터페이스(포트)를 정의하고 외부 계층이 구체적인 구현체(어댑터)를 제공하도록 설계한 뒤, 런타임 시점에 의존성 주입을 사용해 이 구성 요소들을 연결한다 [6].
 
-## ⚖️ Trade-offs & Caveats
+## ⚠️ 모순 및 업데이트 (Contradictions & Updates)
 - DI 프레임워크(Spring, NestJS 등)를 과도하게 사용하면 의존성 그래프가 너무 복잡해져 런타임 성능에 영향을 주거나 디버깅이 어려워지는 'DI 지옥'에 빠질 수 있다. 객체 간의 관계가 명확할 때는 과도한 추상화보다 직관적인 구성을 고려해야 한다.
 
 ---
@@ -101,7 +114,7 @@ DI 메커니즘 자체로 인해 발생하는 런타임 오버헤드, 디버깅
 * **선행 설계 작업의 증가**: 핵심 구현 코드를 작성하기 전에 컴포넌트가 무엇을 해야 하는지 정의하는 '인터페이스 설계'를 먼저 수행해야 하는 설계 규율(design discipline)이 강제된다 [4, 7].
 * **구현 복잡도(Implementation Complexity)**: 컴포넌트의 책임을 분리하고 추상화하는 과정은 초기 설계 및 리팩토링 단계에서 중간에서 높음(Medium-High) 수준의 작업 복잡도와 설계 훈련을 요구한다 [7].
 
-## 🔗 Knowledge Connections
+## 🔗 지식 연결 (Graph)
 - Related: [[의존성 역전 (Dependency Inversion)|Dependency-[[Inversion]]-Principle]] , Inversion-of-Control (IoC)
 - Pattern: Factory-Method-Pattern
 
@@ -180,4 +193,53 @@ DI 메커니즘 자체로 인해 발생하는 런타임 오버헤드, 디버깅
 *   [[Service_Locator_Pattern]]: DI와 유사하지만 객체가 직접 저장소를 호출하여 의존성을 찾는, 지양해야 할 안티패턴입니다.
 
 ---
-*Last updated: 2026-05-02*
+*Last updated: 2026-05-02*
+
+## 🤖 LLM 활용 힌트 (How to Use This Knowledge)
+
+**언제 이 지식을 쓰는가:**
+- *(TODO)*
+
+**언제 쓰면 안 되는가:**
+- *(TODO)*
+
+## 🧪 검증 상태 (Validation)
+
+- **정보 상태:** needs_review
+- **출처 신뢰도:** A
+- **검토 이유:** *(P-Reinforce Phase 1 자동 정규화. 본문 검증 필요.)*
+
+## 🧬 중복 검사 (Duplicate Check)
+
+- **기존 유사 문서:** *(TODO: 인덱서 클러스터 리포트 참조)*
+- **처리 방식:** UPDATE (자동 정규화)
+- **처리 이유:** Phase 1 정규화 — 옛 템플릿/누락 필드 보강.
+
+## 🕓 변경 이력 (Changelog)
+
+| 날짜 | 변경 내용 | 처리 방식 | 신뢰도 |
+|------|-----------|-----------|--------|
+| 2026-05-08 | P-Reinforce Phase 1 정규화 (frontmatter + 헤더 표준화) | UPDATE | A |
+
+## 💻 코드 패턴 (Code Patterns)
+
+**패턴 1:** *(TODO: 이 프로젝트 컨벤션 반영한 구조 스켈레톤)*
+
+```text
+# TODO
+```
+
+## 🤔 의사결정 기준 (Decision Criteria)
+
+**선택 A를 써야 할 때:**
+- *(TODO)*
+
+**선택 B를 써야 할 때:**
+- *(TODO)*
+
+**기본값:**
+> *(TODO)*
+
+## ❌ 안티패턴 (Anti-Patterns)
+
+- **[안티패턴]:** *(TODO: 무엇을 하면 안 되는가 + 이유 + 대신 무엇을)*