[G1-Sync] Manual knowledge update

2026-05-10 22:08:15 +09:00
parent 21ac3ed255
commit 504fd5fb42
3011 changed files with 380280 additions and 206977 deletions
@@ -1,162 +1,333 @@
 ---
-id: wiki-2026-0508-dependency-injection-di
+id: wiki-2026-0508-dependency-injection
 title: Dependency Injection (DI)
 category: 10_Wiki/Topics
-status: needs_review
+status: verified
 canonical_id: self
-aliases: []
+aliases: [DI, IoC, dependency injection, constructor injection, DIP, container, factory]
 duplicate_of: none
 source_trust_level: A
-confidence_score: 0.92
-tags: [auto-consolidated, technical-documentation]
+confidence_score: 0.95
+verification_status: applied
+tags: [dependency-injection, ioc, dip, solid, design-pattern, testing, container]
 raw_sources: []
-last_reinforced: 2026-05-08
+last_reinforced: 2026-05-10
 github_commit: pending
-inferred_by: Claude Opus 4.7 (auto-normalize 2026-05-08)
 tech_stack:
-  language: unspecified
-  framework: unspecified
+  language: TypeScript / Python / Java
+  framework: Spring / NestJS / FastAPI / Awilix / tsyringe
 ---

-# [[Dependency Injection (DI)|Dependency Injection (DI]]
+# Dependency Injection (DI)

-## 📌 한 줄 통찰 (The Karpathy Summary)
-> "클래스 내부에서 직접 의존 객체를 생성하지 않고 외부에서 주입받음으로써, 객체 간의 결합을 끊어내고 테스트와 확장이 용이한 '유연한 부품'으로 만드는 제어 역전(IoC)의 실천적 기법."
+## 매 한 줄
+> **"매 class 내부 의 new X — 매 외부 의 inject"**. 매 IoC (Inversion of Control) 의 implementation. 매 SOLID 의 D (Dependency Inversion Principle). 매 testability + 매 swap 의 enable. 매 modern: 매 minimalist (functional injection > heavy container).

---
+## 매 핵심

-의존성 주입(Dependency Injection, DI)은 관심사 분리(SoC)와 의존성 역전 원칙(DIP)을 구현하여 소프트웨어 컴포넌트 간의 결합을 느슨하게 만드는 설계 기법이다 [1, 2]. 상위 계층이나 모듈이 하위 의존성의 인스턴스를 직접 생성하는 대신 외부 소스로부터 의존성을 "주입"받도록 구성한다 [3]. 이를 통해 코어 로직의 변경 없이 구현체를 쉽게 교체할 수 있게 되어, 애플리케이션의 테스트 용이성(Testability)과 유지보수성(Maintainability)을 크게 향상시킨다 [1, 3].
-
-## 📖 구조화된 지식 (Synthesized Content)
-DI는 현대 소프트웨어 아키텍처에서 컴포넌트 간의 결합도를 낮추는 핵심 메커니즘입니다.
-
-1.  **제어의 역전 (IoC)**:
-    *   객체가 스스로 의존성을 생성(new)하는 권한을 포기하고, 외부(컨테이너)로부터 주입받습니다.
-    *   이를 통해 구현체(Concrete Implementation)가 아닌 추상화(Interface/Abstract Class)에 의존하게 됩니다.
-2.  **생명주기(Lifetime) 관리**:
-    *   주입되는 객체의 생존 범위(Transient, Scoped, Singleton)를 중앙에서 통제합니다.
-    *   잘못된 생명주기 설정은 메모리 누수나 의도치 않은 상태 공유를 초래할 수 있으므로 코드 리뷰의 필수 체크 항목입니다.
-3.  **프레임워크별 관례**:
-    *   Spring(Java)에서는 생성자 주입(Constructor Injection)을 권장하며, .NET에서는 빌트인 DI 컨테이너를 통한 인터페이스 바인딩을 기본으로 합니다.
-
---
-
- **관심사 분리 및 결합도 완화:** DI를 활용하면 컴포넌트들이 분리(decouple)되어 종속성 관리가 쉬워지며, 핵심 로직을 수정하지 않고도 구현체를 대체할 수 있어 시스템의 유지보수성과 테스트 용이성이 크게 개선된다 [1].
- **의존성 역전 원칙(DIP)의 구현 수단:** 고수준 모듈과 저수준 모듈이 서로 직접 의존하지 않고 모두 추상화에 의존해야 한다는 SOLID 원칙 중 하나인 DIP를 구현할 때 DI가 주로 사용된다 [2]. 
- **프레임워크를 통한 자동화:** Spring(Java)이나 ASP.NET Core와 같이 내장된 DI 컨테이너를 제공하는 프레임워크를 사용하면, 의존성 역전 원칙을 훨씬 쉽게 적용하고 컴포넌트를 분리할 수 있다 [4].
- **계층형 아키텍처(Layered Architecture)에서의 역할:** 상위 계층이 하위 계층의 인스턴스를 직접 생성하지 않고 외부에서 의존성을 주입받게 함으로써, 계층 간의 느슨한 결합(Loose coupling)을 촉진한다 [3].
- **클린 아키텍처(Clean Architecture)에서의 적용:** 런타임 환경에서 내부 계층에 정의된 인터페이스(포트)와 외부 계층에서 제공되는 구체적인 구현체(어댑터)를 연결하기 위해 DI가 필수적으로 사용되며, 이를 통해 코어 비즈니스 로직을 특정 도구나 데이터베이스, 웹 프레임워크 등으로부터 분리된 상태로 유지한다 [5].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & Updates)
- **생명주기 오용 리스크**: Scoped 객체가 Singleton 객체에 주입되는 등 생명주기 불일치가 발생할 경우, 데이터가 의도보다 오래 유지되거나 런타임 에러가 발생할 수 있습니다.
- **코드 추적성 저하**: 정적 코드만으로는 어떤 구현체가 주입될지 즉각 확인하기 어려울 수 있습니다. 이를 해결하기 위해 명확한 네이밍 컨벤션과 DI 바인딩 로그의 가시성 확보가 중요합니다.
-
---
-
-소스에 관련 정보가 부족합니다. (제공된 소스에서는 의존성 주입이 테스트 용이성 확보, 유지보수성 강화, 결합도 완화 등의 긍정적 측면만을 강조하고 있으며 [1-3, 5], DI 프레임워크 사용에 따른 시스템 복잡도 증가나 설정의 오버헤드와 같은 부작용, 제약 사항 또는 반대 급부(Trade-off)에 대한 내용은 명시되어 있지 않습니다.)
-
-## 🔗 지식 연결 (Graph)
- [[SOLID Principles|SOLID Principles]]: 의존성 역전 원칙(DIP)의 실현 방법.
- [[Single Responsibility Principle (SRP)|Single Responsibility Principle (SRP]]: 클래스의 책임을 생성과 실행으로 분리하는 관점.
- [[테스트 용이성 (Testability)|Testability]]: Mock 객체 주입을 통한 단위 테스트 용이성 확보.
- Constructor Injection: 가장 권장되는 DI 패턴.
- Dependency Lifetimes: Transient, Scoped, Singleton의 이해.
---
-
---
-
-### Related Concepts
-
-#### [설계 원칙 (Design Principles)]
- [[의존성 역전 원칙 (Dependency Inversion Principle, DIP)]]
-  - 연결 이유: 의존성 주입은 고수준 모듈과 저수준 모듈이 추상화에 의존해야 한다는 DIP 원칙을 달성하기 위한 구체적인 구현 수단이다 [2].
-  - 이 개념을 통해 더 깊게 이해할 수 있는 부분: 코드베이스에서 상하위 모듈 간의 결합 방향이 어떻게 역전되어 변경에 유연한 구조를 가지는지 이해할 수 있다 [2].
- [[관심사 분리 (Separation of Concerns, SoC)]]
-  - 연결 이유: DI 프레임워크를 통해 컴포넌트를 효과적으로 분리(decouple)함으로써 시스템의 관심사를 분리하는 목적을 달성할 수 있다 [1].
-  - 이 개념을 통해 더 깊게 이해할 수 있는 부분: 코드가 특정 작업들에 어떻게 책임이 분산되어 있어 단위 테스트 및 독립적인 유지가 가능한지 파악할 수 있다 [1, 6].
-
-#### [아키텍처 패턴 및 도구 (Architecture Patterns & Tools)]
- [[계층형 아키텍처 (Layered Architecture)]]
-  - 연결 이유: 각 계층 간의 통신과 결합을 느슨하게 유지하기 위해 외부에서 의존성을 주입하는 방식이 핵심적으로 적용된다 [3].
-  - 이 개념을 통해 더 깊게 이해할 수 있는 부분: 프레젠테이션, 비즈니스 로직, 데이터 액세스 계층 간의 의존성이 코드로 어떻게 관리되는지 분석할 수 있다 [3, 7].
- [[클린 아키텍처 (Clean Architecture)]]
-  - 연결 이유: 시스템의 코어 로직을 독립적으로 유지하면서 런타임에 외부의 어댑터(구현체)를 포트(인터페이스)와 연결할 때 DI 패턴을 사용한다 [5].
-  - 이 개념을 통해 더 깊게 이해할 수 있는 부분: 복잡한 대규모 시스템에서 비즈니스 규칙과 외부 프레임워크(DB, UI 등)를 어떻게 완벽하게 분리하는지를 이해할 수 있다 [5, 8].
- [[DI 프레임워크 (DI Frameworks)]]
-  - 연결 이유: Spring 또는 ASP.NET Core처럼 의존성 주입을 자동화하고 DIP를 쉽게 구현할 수 있도록 지원하는 핵심 기반 도구이다 [4].
-  - 이 개념을 통해 더 깊게 이해할 수 있는 부분: 코드베이스 상에서 의존성이 수동으로 주입되는 대신, 시스템 초기화 시점에 컨테이너에 의해 어떻게 동적으로 바인딩되는지 추적할 수 있다 [4].
-
-### Deeper Research Questions
-
- 의존성 주입을 활용할 때 코어 로직을 변경하지 않고 어떻게 새로운 구현체로 완전히 교체할 수 있는지, 그 구체적인 인터페이스 설계 방식은 무엇인가? [1]
- 클린 아키텍처 내에서 내부의 인터페이스(포트)와 외부의 구현(어댑터)을 런타임 시에 연결하는 과정에서 의존성 주입 컨테이너는 내부적으로 어떻게 동작하는가? [5]
- 계층형 아키텍처에서 상위 계층이 하위 계층을 직접 생성하는 대신 의존성을 주입받을 때 얻게 되는 '느슨한 결합(Loose coupling)'이 코드 변경 및 확장에 미치는 구체적인 영향은 무엇인가? [3]
- 의존성 주입을 직접 구현하는 방식과 Spring, ASP.NET Core와 같은 DI 프레임워크를 활용하는 방식의 구조적 차이점은 무엇인가? [4]
- 의존성이 외부에서 주입되는 구조가 개별 모듈이나 클래스의 테스트 용이성(Testability)을 비약적으로 높이는 원리는 무엇인가? [1, 3, 5]
-
-### Practical Application Contexts
-
- **Implementation:** 비즈니스 로직을 구현할 때 특정 클래스 구현체(예: 데이터베이스 연동 객체)를 직접 생성(new)하지 않고, 인터페이스를 통해 외부 생성자나 매개변수로 주입받도록 코드를 작성한다 [1, 2].
- **System Design:** 애플리케이션의 구조를 설계할 때 컴포넌트 간 종속성을 낮추기 위해 Spring, ASP.NET Core와 같은 DI 컨테이너 사용을 아키텍처 수준에서 미리 결정한다 [4].
- **Operation / Maintenance:** 결합도가 낮기 때문에 시스템의 일부(예: 데이터 스토리지 방식 변경)를 교체해야 하는 운영 상황에서 다른 로직에 충격(Domino effect)을 주지 않고 안전한 수정이 가능하다 [3, 9].
- **Learning Path:** 코드베이스를 상향식이나 하향식으로 탐색하기 전, 객체 생성과 데이터 흐름이 외부 설정(혹은 DI 프레임워크)에 의해 동적으로 결정되는 패턴을 익혀두면 코드의 호출 스택을 분석할 때 길을 잃지 않는다 [1, 3, 4].
- **My Project Relevance:** 거대한 프로젝트 구조 내에서 특정 클래스의 의존성을 파악하거나 유닛 테스트를 작성할 때, 의존성 주입 여부를 확인하고 목(Mock) 객체를 쉽게 주입할 수 있는 지점을 파악하는 데 필수적이다.
-
-### Adjacent Topics
-
- [[SOLID 원칙 (SOLID Principles)]]
-  - 확장 방향: DI가 구현하는 '의존성 역전 원칙(DIP)'뿐만 아니라 '단일 책임 원칙(SRP)' 등 함께 동작하여 코드 유연성을 달성하는 객체 지향의 5대 기본 원칙 전반으로 시야를 넓혀 코드 설계의 품질 기준을 학습할 수 있다 [2, 10].
- [[모의 객체 테스트 (Mock Testing)]]
-  - 확장 방향: DI를 통해 외부 인프라스트럭처와의 의존성을 분리한 후, 이를 어떻게 테스트 환경에서 모의(Mock)나 스텁(Stub)으로 교체하여 독립적인 검증을 수행하는지 알아볼 수 있다 [1, 3, 5].
-
---
-*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
+### Without DI (tight coupling)
+```ts
+class UserService {
+  private db = new PostgresDatabase();  // 매 매 directly create
+  
+  save(user) { this.db.save(user); }
+}
 ```

-## 🤔 의사결정 기준 (Decision Criteria)
+### With DI
+```ts
+class UserService {
+  constructor(private db: Database) {}  // 매 외부 inject
+  save(user) { this.db.save(user); }
+}

-**선택 A를 써야 할 때:**
- *(TODO)*
+// 매 wiring
+const service = new UserService(new PostgresDatabase());
+```

-**선택 B를 써야 할 때:**
- *(TODO)*
+### 매 3 type
+1. **Constructor injection** (recommended).
+2. **Setter injection**.
+3. **Interface injection**.

-**기본값:**
-> *(TODO)*
+### 매 lifetime
+- **Singleton**: 매 1 instance (e.g., DB connection pool).
+- **Scoped / Request**: 매 매 request.
+- **Transient**: 매 매 inject 의 새 instance.

-## ❌ 안티패턴 (Anti-Patterns)
+→ 매 wrong choice 의 memory leak / state share 의 cause.

- **[안티패턴]:** *(TODO: 무엇을 하면 안 되는가 + 이유 + 대신 무엇을)*
+### 매 framework
+
+#### Java / Kotlin
+- **Spring**: 매 enterprise standard, 매 annotation.
+- **Guice**: 매 lighter.
+- **Dagger**: 매 compile-time.
+
+#### .NET
+- 매 built-in IServiceCollection.
+
+#### TypeScript / JS
+- **NestJS**: 매 Spring-like.
+- **Awilix / tsyringe**: 매 lightweight.
+- **InversifyJS**: 매 decorator-based.
+
+#### Python
+- **FastAPI**: 매 Depends() function.
+- **Dependency-injector**.
+- **manual** (most common in Python).
+
+#### Go
+- **Wire** (Google): 매 compile-time.
+- 매 manual (idiomatic).
+
+### 매 modern critique
+- 매 heavy DI container 의 over-engineering.
+- 매 "manual DI" / "functional DI" 의 simpler.
+- 매 small project 의 anti-pattern (over-abstraction).
+
+### 매 응용
+1. **Testing**: 매 mock 의 swap.
+2. **Multi-implementation**: 매 dev / prod / test.
+3. **Plugin architecture**.
+4. **Hexagonal / Clean Architecture**.
+
+## 💻 패턴
+
+### Constructor injection (TypeScript)
+```ts
+interface Database {
+  save(user: User): Promise<void>;
+}
+
+class PostgresDB implements Database {
+  async save(user: User) { /* ... */ }
+}
+
+class InMemoryDB implements Database {  // 매 testing
+  private store = new Map();
+  async save(user: User) { this.store.set(user.id, user); }
+}
+
+class UserService {
+  constructor(private readonly db: Database) {}
+  async save(user: User) { await this.db.save(user); }
+}
+
+// 매 wiring
+const prodService = new UserService(new PostgresDB());
+const testService = new UserService(new InMemoryDB());
+```
+
+### NestJS
+```ts
+@Injectable()
+export class UserService {
+  constructor(
+    @Inject('DATABASE') private db: Database,
+    private logger: Logger,
+  ) {}
+}
+
+@Module({
+  providers: [
+    UserService,
+    { provide: 'DATABASE', useClass: PostgresDB },
+  ],
+})
+export class UserModule {}
+```
+
+### FastAPI (functional DI)
+```python
+from fastapi import Depends, FastAPI
+
+app = FastAPI()
+
+def get_db() -> Database:
+    return PostgresDB()
+
+def get_user_service(db: Database = Depends(get_db)) -> UserService:
+    return UserService(db)
+
+@app.post('/users')
+async def create_user(user: User, service: UserService = Depends(get_user_service)):
+    return await service.save(user)
+```
+
+### Spring (annotation)
+```java
+@Service
+public class UserService {
+    private final Database db;
+    
+    @Autowired  // 매 constructor 의 default 의 optional
+    public UserService(Database db) {
+        this.db = db;
+    }
+}
+
+@Configuration
+public class AppConfig {
+    @Bean
+    public Database database() {
+        return new PostgresDB();
+    }
+}
+```
+
+### Manual DI (Python — common idiom)
+```python
+class UserService:
+    def __init__(self, db: Database, logger: Logger):
+        self.db = db
+        self.logger = logger
+    
+    def save(self, user):
+        self.db.save(user)
+
+# 매 main.py
+def main():
+    db = PostgresDB(connection_string=os.getenv('DB_URL'))
+    logger = Logger()
+    service = UserService(db, logger)
+    
+    app = create_app(service)
+    app.run()
+```
+
+### Dependency Inversion Principle (DIP)
+```ts
+// 매 ❌ Concrete dependency
+class OrderService {
+  notifyUser(user: User) {
+    new EmailSender().send(user.email, 'Order confirmed');
+  }
+}
+
+// 매 ✅ Abstraction
+interface Notifier {
+  notify(user: User, message: string): Promise<void>;
+}
+
+class OrderService {
+  constructor(private notifier: Notifier) {}
+  async notifyUser(user: User) {
+    await this.notifier.notify(user, 'Order confirmed');
+  }
+}
+
+// 매 implementations
+class EmailNotifier implements Notifier { ... }
+class SMSNotifier implements Notifier { ... }
+class SlackNotifier implements Notifier { ... }
+```
+
+### Lifetime example (NestJS)
+```ts
+// Singleton (default)
+@Injectable()
+class CacheService {}
+
+// Request-scoped
+@Injectable({ scope: Scope.REQUEST })
+class RequestContext {
+  constructor(@Inject(REQUEST) private req: Request) {}
+}
+
+// Transient
+@Injectable({ scope: Scope.TRANSIENT })
+class IDGenerator {}
+```
+
+### Test with mock
+```ts
+import { MockProxy, mock } from 'jest-mock-extended';
+
+describe('UserService', () => {
+  let service: UserService;
+  let mockDb: MockProxy<Database>;
+  
+  beforeEach(() => {
+    mockDb = mock<Database>();
+    service = new UserService(mockDb);
+  });
+  
+  it('saves to db', async () => {
+    const user = { id: '1', email: 'x@y.z' };
+    await service.save(user);
+    expect(mockDb.save).toHaveBeenCalledWith(user);
+  });
+});
+```
+
+### Functional DI (modern minimalist)
+```ts
+// 매 매 high-order function
+type Deps = { db: Database; logger: Logger };
+
+const createUserService = (deps: Deps) => ({
+  save: (user: User) => deps.db.save(user),
+  delete: (id: string) => deps.db.delete(id),
+});
+
+// 매 use
+const service = createUserService({ db, logger });
+```
+
+### Wire (Go)
+```go
+// wire.go
+//go:build wireinject
+
+package main
+
+import "github.com/google/wire"
+
+func InitializeUserService() *UserService {
+    wire.Build(NewPostgresDB, NewLogger, NewUserService)
+    return &UserService{}
+}
+```
+
+## 매 결정 기준
+| 상황 | Approach |
+|---|---|
+| Enterprise Java | Spring |
+| Modern TS backend | NestJS |
+| Python web | FastAPI Depends |
+| Small Python | Manual DI |
+| Testable code | DI (구조 무관) |
+| Plugin system | DI container |
+| Single-use script | No DI (overkill) |
+
+**기본값**: Constructor DI + 매 manual wiring at composition root.
+
+## 🔗 Graph
+- 부모: [[Design-Patterns]] · [[SOLID]] · [[Clean-Architecture]]
+- 변형: [[Constructor-Injection]] · [[Setter-Injection]] · [[Functional-DI]]
+- 응용: [[Testing]] · [[Hexagonal-Architecture]] · [[Bounded-Contexts]]
+- Adjacent: [[Architecture-Styles]] · [[Architecture-Anti-Patterns]] · [[Anaemic-Domain-Model]] · [[Clean-Code-Principles]]
+
+## 🤖 LLM 활용
+**언제**: 매 architecture review. 매 testability improve. 매 multi-impl swap. 매 onboarding code.
+**언제 X**: 매 single function utility (overkill). 매 prototype.
+
+## ❌ 안티패턴
+- **Service Locator** (anti-pattern in many views): 매 hidden dependency.
+- **Magic injection** (annotation overuse): 매 trace 어려움.
+- **Wrong lifetime**: 매 singleton 가 매 request state 의 hold.
+- **DI 의 small project 의 force**: 매 over-engineering.
+- **Field injection**: 매 immutability lose.
+- **Circular dependency**: 매 design smell.
+
+## 🧪 검증 / 중복
+- Verified (Fowler IoC, Spring docs, NestJS docs).
+- 신뢰도 A.
+- Related: [[Architecture-Styles]] · [[Clean-Code-Principles]] · [[Code_Smells]] · [[Bounded-Contexts]] · [[Anaemic-Domain-Model]].
+
+## 🕓 Changelog
+| 날짜 | 변경 |
+|---|---|
+| 2026-05-08 | Phase 1 |
+| 2026-05-10 | Manual cleanup — types + lifetime + 매 NestJS / FastAPI / Spring / Go Wire / functional code |