.NET 의존성 주입 관례: 라이프타임, 스코프, 그리고 captive dependency 함정

무엇인가

.NET 문서는 내장 컨테이너의 동작 방식을 설명합니다: 시작 시점에 IServiceCollection에 서비스를 등록하고(AddTransient, AddScoped, AddSingleton, 또는 키가 있는 변형), BuildServiceProvider나 제네릭 호스트가 IServiceProvider를 생성하며, 사용하는 쪽은 공개 생성자를 통해 의존성을 전달받습니다. Transient 서비스는 요청될 때마다 새로 생성됩니다. Scoped 서비스는 스코프당 한 번 생성되는데, ASP.NET Core에서 스코프는 요청 하나입니다. Singleton은 컨테이너의 수명 동안 단 한 번 생성됩니다. 컨테이너는 자신이 만든 것을 직접 정리합니다: transient와 scoped 인스턴스는 각자의 스코프가 끝날 때, singleton은 종료 시점에 정리됩니다. 한 타입에 생성자가 여럿 있으면 DI로 해결 가능한 매개변수가 가장 많은 생성자가 선택되며, 모호한 경우에는 예외가 발생합니다.

왜 중요한가

Spring(기본이 singleton) 출신이거나 컨테이너 없는 프레임워크 출신 엔지니어는 모든 것을 singleton으로 등록하거나 서비스를 수동으로 resolve하는 경향이 있습니다. 가이드라인 페이지는 그 결과로 생기는 버그를 captive dependency라고 부릅니다: 수명이 더 긴 서비스가 수명이 더 짧은 서비스를 붙잡고 있는 것으로, "요청당 하나"여야 할 DbContext가 singleton에 붙잡히면 모든 요청이 그것을 모르는 채 공유하게 됩니다. 라이프타임 페이지는 scoped 서비스를 생성자 주입으로든 IServiceProvider를 통해서든 singleton에서 resolve해서는 안 된다고 명시합니다. 문서가 제시하는 해법은 IServiceScopeFactory로 명시적인 스코프를 만드는 것입니다.

적용 방법

• 상태가 없는 서비스는 기본적으로 transient로, 요청 단위 상태(DbContext, unit of work)는 scoped로, 공유되고 스레드 안전하며 비용이 큰 상태만 singleton으로 등록합니다. 가이드라인은 singleton이 반드시 스레드 안전해야 한다고 말하며, 결합도와 메모리 문제를 경고합니다.
• 생성자에서는 인터페이스에 의존하고, 생성자 안에는 할당 이외의 작업을 두지 않습니다.
• 주입받은 서비스에서 Dispose를 직접 호출하지 않으며, 루트 프로바이더에서 resolve될 수 있는 IDisposable 타입을 transient로 등록하지 않습니다. 가이드라인에 따르면 그런 인스턴스는 컨테이너가 정리될 때까지 계속 붙잡혀 있습니다.
• 서비스를 구성하는 도중에 BuildServiceProvider를 호출하지 않으며, 서비스 로케이터처럼 GetService를 쓰지 않습니다. 둘 다 안티패턴으로 명시되어 있습니다.
• 스코프 검증은 항상 켜 둡니다: 개발용 호스트는 scoped 서비스가 루트에서 resolve되거나 singleton에 주입되지 않는지 확인하며, 다른 곳에서는 BuildServiceProvider의 validateScopes: true가 같은 역할을 합니다.
• 호스팅 서비스나 백그라운드 서비스에서는 IServiceScopeFactory를 주입받아 작업 단위마다 스코프를 새로 만듭니다.

함정

프로바이더에 대한 정적 접근(캡처해 둔 ApplicationServices)은 피해야 할 것으로 명시되어 있습니다. 가이드라인은 이를 정적 객체 접근과 섞어 쓰면 DI의 이점이 사라진다고 말합니다. 옵션 패턴 대신 설정이나 사용자 데이터를 컨테이너에 저장하는 것도 마찬가지입니다. 키가 있는 서비스는 매개변수에 [FromKeyedServices("key")]가 필요합니다. 서비스를 두 번 등록하는 것은 문법적으로는 허용되지만 놓치기 쉬운 실수입니다.