20강. 의존성 주입

?1. 이번 강의에서 해결할 문제

Service가 파일·메일 객체를 직접 생성하면 테스트가 외부 세부에 묶입니다.

✓2. 학습 목표

✓이 강의를 마치면

• DI를 생성과 사용의 분리로 설명합니다.
• 참조·unique_ptr 주입의 소유 의미를 선택합니다.
• 조립 루트에서 구현을 연결합니다.

◇3. 핵심 개념

DI는 컨테이너 제품이 아니라 필요한 협력자를 외부에서 받는 방식입니다. 필수 비소유 협력자는 참조로 표현할 수 있습니다.

직접 생성 버전에서 TaskService가 FileRepository, EmailNotifier, 시스템 시계를 내부에서 만들면 저장 위치와 네트워크, 현재 시간이 서비스 코드에 숨습니다. 테스트도 실제 파일과 메일에 의존합니다. DI는 이 결정을 프로그램 시작점인 조립 루트로 옮기고 서비스는 역할 계약만 사용하게 합니다.

• 참조 주입: 필수이고 Service가 소유하지 않으며 협력자가 더 오래 살아야 함
• unique_ptr 주입: Service가 협력자의 단독 수명을 소유함
• 값 주입: 작고 복사 가능한 설정·정책

§4. 가장 작은 예제로 시작하기

main.cpp

#include <iostream>
#include <string>
#include <string_view>
#include <vector>

struct TaskRepository {
    virtual ~TaskRepository() = default;
    virtual void saveCompleted(int taskId, std::string_view at) = 0;
};

struct Notifier {
    virtual ~Notifier() = default;
    virtual void taskCompleted(int taskId) = 0;
};

struct Clock {
    virtual ~Clock() = default;
    virtual std::string now() const = 0;
};

class TaskService {
    TaskRepository& repo_;
    Notifier& notifier_;
    Clock& clock_;
public:
    TaskService(TaskRepository& repo, Notifier& notifier, Clock& clock)
        : repo_(repo), notifier_(notifier), clock_(clock) {}

    void complete(int taskId) {
        repo_.saveCompleted(taskId, clock_.now());
        notifier_.taskCompleted(taskId);
    }
};

struct FakeRepository final : TaskRepository {
    std::vector<int> savedIds;
    void saveCompleted(int taskId, std::string_view) override {
        savedIds.push_back(taskId);
    }
};

struct SpyNotifier final : Notifier {
    std::vector<int> notifiedIds;
    void taskCompleted(int taskId) override { notifiedIds.push_back(taskId); }
};

struct FixedClock final : Clock {
    std::string now() const override { return "2026-07-31T10:00:00Z"; }
};

int main() {
    FakeRepository repo;
    SpyNotifier notifier;
    FixedClock clock;
    TaskService service{repo, notifier, clock};

    service.complete(42);
    std::cout << repo.savedIds.at(0) << ' '
              << notifier.notifiedIds.at(0) << '\n';
}

예상 출력: 42 42가 표시되어 같은 작업이 저장되고 알림됐음을 확인합니다.

→5. 코드가 동작하는 이유

생성자 서명에 세 필수 협력자가 드러나므로 불완전한 TaskService를 만들 수 없습니다. 테스트는 실제 파일·메일·현재 시간 대신 Fake, Spy, FixedClock을 스택에 만들고 참조로 전달합니다. main이 더 오래 사는 협력자를 먼저 만들었으므로 Service의 참조도 유효합니다.

변경 전에는 알림 구현을 바꾸려면 Service 내부 생성을 수정합니다. 변경 후에는 조립 루트에서 SpyNotifier 대신 실제 구현을 연결하고 Service의 완료 규칙은 유지합니다. 저장 성공 뒤 알림한다는 호출 순서도 테스트할 수 있습니다.

!6. 자주 하는 실수와 해결법

!자주 하는 실수

• 모든 함수 인자로 전달: 수명 협력자는 생성자에 둡니다.
• 필수인데 nullable pointer: 참조를 검토합니다.
• 프레임워크가 설계를 해결: 역할과 방향이 먼저입니다.
• 참조 대상이 Service보다 먼저 파괴됨: 조립 루트에서 생성·파괴 순서를 보장합니다.
• 숨은 Service Locator 조회: 필요한 협력자를 생성자 계약에 명시합니다.

✎7. 직접 실습

✎직접 실습

실습 목표

직접 생성하던 저장·알림·시간 의존성을 생성자 주입으로 바꾸고 외부 부작용 없이 완료 흐름을 검증합니다.

시작 전 상태

위 C++17 예제를 실행해 42 42를 확인하고 협력자 생성 순서와 Service의 참조 수명을 표시합니다.

1단계: 따라 하기

FakeRepository, SpyNotifier, FixedClock을 주입하고 작업 7 완료 뒤 두 기록에 7이 한 번씩 있는지 확인합니다.

2단계: 구현 바꿔 보기

Notifier 구현을 ConsoleNotifier로 교체하되 TaskService는 수정하지 않습니다. 조립 지점만 달라졌는지 diff를 확인합니다.

3단계: 직접 적용

저장 실패를 던지는 FailingRepository를 만들고 실패 시 알림이 호출되지 않는지 Spy로 검증합니다. 저장·알림 순서가 서비스 규칙임을 설명합니다.

4단계: 스스로 확인

• 필수 의존성이 생성자에 모두 보이나요?
• Service가 구체 파일·메일 클래스를 직접 만들지 않나요?
• 주입한 참조가 Service보다 오래 살아 있나요?
• 실패 경로도 외부 작업 없이 검증했나요?

막혔을 때

증상	확인·해결
pure virtual 호출·크래시	주입 대상 수명과 파괴 순서를 확인합니다.
Fake인데 실제 파일 접근	Service 내부에 남은 구체 생성·전역 조회를 찾습니다.
테스트마다 현재 시간이 다름	Clock 계약과 고정 구현을 주입합니다.

?8. 이해 점검 질문 3개

?이해 점검

1. Service가 내부에서 EmailNotifier를 만들면 테스트와 구현 교체에 어떤 결합이 생기며 생성자 주입은 무엇을 바꾸나요?
2. 참조로 주입한 Repository가 Service보다 먼저 파괴되면 어떤 문제가 생기며 누가 수명을 보장해야 하나요?
3. 저장 실패 뒤 알림이 호출되지 않아야 할 때 Fake와 Spy를 각각 어떤 증거에 사용하나요?

■9. 핵심 요약

■핵심 요약

DI는 생성과 사용을 분리해 필수 협력자와 수명을 계약에 드러냅니다. 조립 루트가 구체 구현을 선택하고 Service는 역할과 업무 순서만 책임집니다.

§10. 다음 강의 연결

구체 구현 선택을 조립 루트로 옮겼습니다. 다음 강의에서는 이 의존 방향을 계층 전체로 확장합니다.