의존성 주입 (Dependency Injection, DI)

의존성 주입(Dependency Injection)은 코드가 필요로 하는 객체나 기능을 외부에서 만들어 전달하는 설계 방식입니다. 사용하는 쪽은 전달받은 인터페이스로 일을 수행하고, 어떤 구현을 연결할지는 조립하는 쪽에서 정합니다. 운영에서는 실제 저장소를, 테스트에서는 대역을 전달하는 식으로 구현 선택과 사용 책임을 나눕니다.

객체 생성과 사용의 분리

주문 서비스가 내부에서 특정 결제 객체를 직접 만들면 결제 구현을 바꿀 때 주문 코드도 수정하게 됩니다. 생성자 인수로 결제 기능을 받도록 구성하면 조립 코드에서 구현을 선택합니다. Spring의 의존성 주입 설명은 생성자나 팩터리 메서드의 인수, 생성 뒤 설정되는 프로퍼티를 통해 의존 대상을 지정하는 방식을 설명합니다. 의존 관계 자체는 유지하면서 그 대상을 준비할 책임을 옮깁니다.

의존성 주입 컨테이너는 이 조립 작업을 관리하는 도구입니다. .NET의 의존성 주입 문서는 서비스를 등록하고 사용하는 클래스의 생성자로 전달하는 과정을 제시합니다. 작은 프로그램에서는 호출 코드가 객체를 직접 만들어 인수로 넘기는 방식으로도 같은 책임 분리를 구성할 수 있습니다. 컨테이너의 사용 여부와 의존성 주입이라는 설계 원칙은 구별해서 판단합니다.

인터페이스가 정해져 있으면 호출하는 코드는 저장 방식의 세부 구현을 덜 알아도 됩니다. 테스트에서는 같은 호출 계약을 지키는 대역을 제공해 특정 응답이나 실패를 만들 수 있습니다. 다만 객체를 밖에서 전달했다고 두 구현의 동작이 같아지는 것은 아닙니다. 같은 메서드 이름을 갖췄어도 반환값의 의미와 오류 조건이 다르면 교체 뒤 결과가 달라집니다. 전달 방식과 구현의 계약 검증은 각각 확인할 대상입니다.

서비스 로케이터와 생성자 계약

서비스 로케이터는 사용하는 코드가 등록소에 필요한 객체를 요청해 가져오는 방식입니다. 의존성 주입에서는 사용하는 객체가 필요한 대상을 전달받습니다. Spring의 비교 설명은 객체 스스로 의존 대상을 생성하거나 찾아오는 방식과 외부에서 제공받는 방식을 구분합니다. 호출 지점에서 무엇이 필요한지 드러나는 정도와 의존 관계를 추적하는 경로가 달라집니다.

컨테이너 객체를 생성자로 넘긴 뒤 클래스 내부에서 필요한 서비스를 계속 꺼내 쓰면, 실제 필요 목록이 생성자에 드러나지 않습니다. .NET의 의존성 주입 지침은 주입할 수 있는 서비스를 GetService로 찾아오는 서비스 로케이터 방식을 피하도록 권합니다. 프레임워크가 제공하는 컨테이너를 쓴다는 사실만으로 모든 사용 코드가 의존성 주입 원칙을 따르는 것은 아닙니다.

생성자에 필수 의존 대상을 명시하면 객체를 만들 때 필요한 구성 요소를 확인하기 쉽습니다. 선택적 설정을 생성 뒤에 넣는 방식은 구성이 끝나기 전의 객체 상태를 고려해야 합니다. 설정되지 않은 기능을 호출하면 어느 시점에 실패하는지, 기본값이 있는지에 따라 사용할 방식이 달라집니다. 모든 값을 인터페이스로 감싸기보다 교체가 필요하거나 외부 자원에 접근하는 경계부터 구분하면 조립 관계를 읽기 수월합니다.

객체 수명과 자원 소유권

컨테이너는 어떤 객체를 제공할지와 함께 언제 새로 만들지 관리하기도 합니다. .NET의 서비스 수명 문서는 요청할 때마다 만드는 transient, 범위별로 공유하는 scoped, 컨테이너에서 하나를 공유하는 singleton을 구분합니다. 웹 요청처럼 짧은 범위의 상태를 긴 수명의 객체가 붙잡으면 요청이 끝난 뒤에도 그 상태가 사용될 수 있습니다. 의존 관계를 연결할 때 수명도 맞춰야 하는 이유입니다.

같은 문서는 singleton에서 scoped 서비스를 직접 가져오지 않도록 설명하며, 명시적인 범위를 만들어 사용하는 경우를 별도로 다룹니다. 수명 이름만 맞춰 등록하는 것으로 모든 자원 문제가 해결되지는 않습니다. .NET의 정리 지침에서 컨테이너가 만든 객체의 정리는 컨테이너가 담당합니다. 외부에서 이미 만든 객체를 등록한 경우에는 생성 방식에 따라 정리 책임이 달라지므로 소유권을 확인합니다.

주입할 객체가 계속 늘어나면 사용하는 클래스가 너무 많은 일을 맡는지 검토할 수 있습니다. 결제·재고·배송·보고서 처리가 한 객체에 모여 있다면 생성자 인수만 줄여 문제를 숨기기보다 책임을 나누는 편이 구조를 드러냅니다. 의존성 주입을 적용한 뒤에도 순환 의존, 누락된 등록, 의도와 다른 수명 설정은 남을 수 있습니다. 애플리케이션이 실제로 조립되는 구성으로 확인해야 등록 오류와 구현 오류를 구별할 수 있습니다.