---
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)|Dependency Management (DI & DIP]]

## 📌 한 줄 통찰 (The Karpathy Summary)
> "구체적인 구현이 아닌 추상화에 의존하게 하여 컴포넌트 간의 결합도를 낮추고, 코드 수정 없이 기능을 확장하거나 교체할 수 있는 유연한 시스템 구조의 핵심 기법."

## 📖 구조화된 지식 (Synthesized Content)
의존성 관리는 소프트웨어의 모듈성과 테스트 가능성을 결정짓는 가장 중요한 설계 요소입니다.

1.  **[[의존성 역전 원칙 (Dependency Inversion Principle DIP)|Dependency Inversion Principle (DIP]]**:
    *   **고수준 모듈의 보호**: 고수준 모듈(비즈니스 로직)은 저수준 모듈(데이터베이스, 외부 API)의 구체적인 구현에 의존해서는 안 됩니다. 둘 다 추상화(인터페이스)에 의존해야 합니다.
    *   **의존성 방향의 역전**: 전통적인 계층 구조에서의 의존성 방향을 뒤집어, 구현체가 인터페이스를 따르게 함으로써 핵심 로직을 외부 변화로부터 보호합니다.
2.  **[[Dependency Injection (DI)|Dependency Injection (DI]]**:
    *   **객체 생성이 아닌 주입**: 클래스 내부에서 의존 객체를 직접 생성(New)하지 않고, 외부(생성자, 메서드 등)에서 주입받습니다.
    *   **유연한 교체**: 인터페이스를 통해 종속성을 주입받으므로, 실제 구현체를 환경(Staging, Production)이나 테스트 목적(Mocking)에 따라 쉽게 교체할 수 있습니다.
3.  **코드 리뷰에서의 역할**:
    *   리뷰어는 코드가 하드코딩된 종속성을 가지고 있는지, 인터페이스를 통해 결합도가 적절히 분리(Decoupled)되었는지 검증합니다.

## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
- **추상화의 비용**: 모든 관계에 DI/DIP를 적용하면 코드 가독성이 떨어지고 추적하기 어려워질 수 있습니다. '과잉 엔지니어링(Over-engineering)'을 경계하며, 변화가 잦거나 테스트가 필수적인 영역을 중심으로 적용하는 실용성이 필요합니다.
- **의존성 그래프의 복잡성**: 주입되는 객체가 많아지면 객체 생성 로직이나 DI 컨테이너 설정이 복잡해집니다. 생성자 주입(Constructor Injection)을 권장하고 클래스의 책임을 작게 유지하여 주입되는 의존성 수를 제한해야 합니다.

## 🔗 지식 연결 (Graph)
- [[SOLID Principles|SOLID Principles]]: DIP가 포함된 설계 원칙 그룹.
- [[Clean Architecture & Patterns|Clean Architecture & Patterns]]: DIP를 통해 도메인 로직을 보호하는 상위 아키텍처.
- [[Testing Strategy|Testing Strategy]]: DI가 가능하게 하는 테스트 용이성.
- [[Single Responsibility Principle (SRP)|Single Responsibility Principle (SRP]]: 의존성이 많아지는 것을 방지하는 근거.
- Over-engineering: 무분별한 추상화의 위험.
---