IoC와 DI — 스프링의 심장을 코드로

🧩 IoC(원칙) vs DI(방법) IoC는 "제어권을 넘긴다"는 큰 원칙이에요.
DI는 그 원칙을 이루는 구체적 방법 중 하나예요. 한 문장 정리: "IoC를 실현하기 위해 스프링은 DI를 쓴다." 그래서 스프링의 컨테이너를 IoC 컨테이너라고도, DI 컨테이너라고도 불러요. 같은 통을 원칙 이름과 방법 이름으로 부르는 것뿐이에요.

🧱 DI가 없으면 — 직접 new (강한 결합) OrderService가 필요한 OrderRepository를 스스로 new로 생성해요. 그러면 OrderService는 특정 구현 클래스에 딱 붙어버려요. 나중에 다른 저장소로 바꾸려면 이 클래스 코드를 직접 고쳐야 해요. 이게 강한 결합(tight coupling)이에요.

public class OrderService {
    // 의존 객체를 내가 직접 생성 → 강한 결합
    private OrderRepository repo = new OrderRepository();

    public void order() {
        repo.save();
    }
}

🍃 DI가 있으면 — 외부가 주입 (느슨한 결합) OrderService는 new를 하지 않아요. 필요한 객체를 생성자로 "받기만" 하고, 실제 객체는 스프링이 만들어 넣어줘요(주입). OrderService는 어떤 구현이 들어오는지 몰라도 되니 느슨한 결합(loose coupling)이 돼요.

@Service
public class OrderService {
    private final OrderRepository repo;

    // 의존 객체를 외부(스프링)가 주입해줌
    public OrderService(OrderRepository repo) {
        this.repo = repo;
    }

    public void order() {
        repo.save();
    }
}

차이의 핵심: 아래 코드에는 new OrderRepository()가 없어요. 만드는 책임을 스프링에 넘겼기 때문이에요. 이게 바로 IoC(제어의 역전)를 DI로 실현한 모습이에요.

① 생성자 주입 (Constructor Injection) — 권장 ✅ 의존 객체를 생성자의 매개변수로 받아요. 필드를 final로 둘 수 있어 한 번 주입되면 바뀌지 않고(불변), 필수 의존성이 명확해요. 생성자로 넣으니 테스트할 때 직접 객체를 넣어 만들기도 쉬워요.

@Service
public class OrderService {
    private final OrderRepository repo;   // 불변(final) 가능

    // 생성자로 필수 의존성을 받음 → 명확 + 테스트 쉬움
    public OrderService(OrderRepository repo) {
        this.repo = repo;
    }
}

② 필드 주입 (Field Injection) 필드 위에 @Autowired를 붙여 바로 주입받아요. 코드가 짧고 간편하지만, 필드를 final로 못 만들고(불변에 불리), 스프링 없이 테스트할 때 가짜 객체를 넣기가 번거로워요.

@Service
public class OrderService {
    @Autowired
    private OrderRepository repo;   // 간편하지만 테스트·불변에 불리
}

③ 세터 주입 (Setter Injection) 세터 메서드에 @Autowired를 붙여 주입받아요. 선택적(있어도 없어도 되는) 의존성이나 나중에 바꿀 수 있어야 하는 경우에 어울려요. 다만 주입 뒤에 값이 바뀔 수 있어(불변 아님) 필수 의존성엔 덜 적합해요.

@Service
public class OrderService {
    private OrderRepository repo;

    @Autowired
    public void setRepo(OrderRepository repo) {
        this.repo = repo;
    }
}

✨ 생성자가 하나면 @Autowired 생략 가능 스프링 4.3 이후로는, 클래스에 생성자가 딱 하나면 그 생성자에 @Autowired를 붙이지 않아도 자동으로 주입돼요. 그래서 요즘 생성자 주입 코드는 어노테이션 없이 아주 깔끔해요.

@Service
public class OrderService {
    private final OrderRepository repo;

    // 생성자가 하나뿐이므로 @Autowired 생략 가능!
    public OrderService(OrderRepository repo) {
        this.repo = repo;
    }
}

참고: 롬복(Lombok)의 @RequiredArgsConstructor를 쓰면 final 필드용 생성자를 자동 생성해줘서, 생성자 코드조차 안 써도 돼요. (실무에서 자주 봐요.)

🧷 인터페이스에 의존하면 더 느슨해진다 의존을 구체 클래스가 아니라 인터페이스로 받으면, 어떤 구현이 주입돼도 상관없어져요. 실제 운영에선 진짜 구현을, 테스트에선 가짜 구현을 넣는 식으로 자유롭게 갈아끼울 수 있어요.

public interface OrderRepository {
    void save();
}

@Service
public class OrderService {
    private final OrderRepository repo;   // 인터페이스에 의존!

    public OrderService(OrderRepository repo) {  // 어떤 구현이든 주입 가능
        this.repo = repo;
    }
}

테스트에서는 new OrderService(new FakeRepository())처럼 가짜 구현을 넣어 스프링 없이도 OrderService의 로직만 검증할 수 있어요. 이게 "테스트가 쉬워진다"의 실체예요.