Angular의 DI는 계층적입니다. injector는 컴포넌트/모듈 트리를 반영하는 트리를 형성합니다. 컴포넌트가 의존성을 요청하면, Angular는 provider를 찾을 때까지 injector 트리를 위로 거슬러 올라갑니다. 이것이 공유 싱글턴을 받을지, 컴포넌트마다 별도의 인스턴스를 받을지를 제어합니다.
루트 injector (앱 전체) ← providedIn: 'root'가 여기 위치 (싱글턴 하나)
└─ 모듈/라우트 injector
└─ 컴포넌트 injector ← @Component의 providers: [...]
└─ 자식 컴포넌트 injector
조회는 요청한 컴포넌트에서 시작하여 루트까지 거슬러 올라갑니다. 발견된 provider가 채택됩니다.
// 1. 앱 전체 싱글턴 — 모든 곳에서 공유되는 인스턴스 하나
@Injectable({ providedIn: "root" })
export class AuthService {}
// 2. 컴포넌트 범위 — 컴포넌트(및 자식)마다 새 인스턴스
@Component({
selector: "app-widget",
providers: [DataService], // 각 <app-widget>은 자신만의 DataService를 가진다
})
export class WidgetComponent {}
이것이 핵심 레버입니다. providedIn: 'root'는 단일 공유 인스턴스를 제공하고, 컴포넌트의 providers 배열에 provider를 나열하면 그 컴포넌트 서브트리에 한정된 새 인스턴스가 생성됩니다(컴포넌트별로 상태를 격리하는 데 유용함).
constructor(
@Optional() private logger: Logger, // 제공되지 않으면 에러 대신 null
@Self() private local: LocalService, // 오직 이 injector에서만 조회
@SkipSelf() private parent: ParentService, // 자신을 건너뛰고 부모부터 시작
@Host() private host: HostService, // 호스트 컴포넌트에서 멈춤
) {}
이 decorator들은 Angular가 injector 트리를 얼마나 멀리 탐색하는지 제어합니다. 예를 들어 @Optional은 의존성이 없을 때 에러를 피하고, @SkipSelf는 부모의 인스턴스를 강제로 사용하게 합니다.
export const API_URL = new InjectionToken<string>("apiUrl");
// provide: { provide: API_URL, useValue: "https://api.example.com" }
constructor(@Inject(API_URL) private apiUrl: string) {}
Token을 통해 클래스뿐 아니라 값/설정을 주입하고 구현을 교체할 수 있습니다(useClass, useValue, useFactory).
계층적 injector를 이해하면 서비스가 앱 전체에서 공유되는지, 컴포넌트마다 복제되는지의 이유를 설명할 수 있습니다. 이는 "왜 이 컴포넌트들이 상태를 공유/비공유하는가?"라는 빈번한 혼란의 원천입니다.
provider 범위(root 대 컴포넌트 providers)를 제어하고, 한정자(@Optional, @SkipSelf)를 사용하며, 설정/교체 가능한 구현을 위한 injection token을 사용하는 것이 Angular의 DI를 아키텍처와 테스트 양면에서 강력하게 만드는 요소입니다.