커스텀 provider와 injection token이란 무엇인가요?

Question

Accepted Answer

단순한 `@Injectable()` 클래스를 넘어, NestJS는 **injection token**을 사용하여 무엇이 주입되는지 정의하는 유연한 방법인 **커스텀 provider**를 지원합니다. 이는 값을 주입하고, 인스턴스가 생성되는 방식을 구성하고, 구현을 교체하고, 클래스가 아닌 의존성을 주입할 수 있게 합니다.

## 네 가지 커스텀 provider 타입

```ts
@Module({
  providers: [
    // 1. useClass — 표준 (또는 token 뒤의 구현을 교체)
    { provide: PaymentService, useClass: StripePaymentService },

// 2. useValue — 상수/객체/mock 주입 (구성과 테스트에 적합)
    { provide: "CONFIG", useValue: { apiKey: "abc", timeout: 5000 } },

// 3. useFactory — provider를 동적으로 계산 (다른 의존성 사용 가능)
    {
      provide: "DATABASE_CONNECTION",
      useFactory: async (config: ConfigService) => {
        return await createConnection(config.get("DB_URL"));   // 비동기 설정
      },
      inject: [ConfigService],        // factory를 위한 의존성
    },

// 4. useExisting — 기존 provider의 별칭 생성
    { provide: "ALIAS", useExisting: PaymentService },
  ],
})
export class AppModule {}
```

## injection token — 클래스가 아닌 의존성을 위한 것

```ts
// 클래스는 직접 token이 될 수 있음(타입으로). 값/인터페이스에는 문자열/Symbol token 사용:
@Injectable()
export class PaymentProcessor {
  constructor(@Inject("CONFIG") private config: AppConfig) {}   // token으로 주입
}
```

인터페이스나 일반 값을 타입으로 주입할 수 없으므로(런타임에 존재하지 않음), `@Inject(token)`과 함께 **token**(문자열 또는 `Symbol`)을 사용하여 주입합니다. 이것이 구성 객체, 서드파티 클라이언트, 인터페이스 타입 의존성을 주입하는 방법입니다.

## useFactory — 가장 강력한 것 (동적, 비동기 설정)

```ts
// 런타임 구성 / 비동기 초기화에 의존하는 값을 가진 provider 생성
{
  provide: "REDIS_CLIENT",
  useFactory: (config: ConfigService) => new Redis(config.get("REDIS_URL")),
  inject: [ConfigService],
}
```

`useFactory`는 (주입된 의존성과 함께) 함수를 실행하여 provider를 생성합니다 — 연결, 클라이언트, 또는 런타임 구성이나 비동기 설정이 필요한 모든 것에 필수적입니다.

## 구현 교체 (useClass) — 유연성 & 테스트

```ts
// 환경에 따라 다른 구현 주입
{
  provide: PaymentService,
  useClass: process.env.NODE_ENV === "test" ? MockPaymentService : StripePaymentService,
}
```

소비자가 token(`PaymentService`)에 의존하기 때문에, 소비하는 코드를 변경하지 않고 구체 클래스를 교체할 수 있습니다 — 프로덕션에서는 실제 Stripe service, 테스트에서는 mock.

## 왜 중요한가

커스텀 provider와 injection token은 NestJS의 dependency injection을 단순한 클래스를 넘어 확장하여, 실제 애플리케이션에 필요한 유연성을 제공합니다.

이를 이해하는 것은 몇 가지 일반적인 시나리오에 중요합니다: `useValue`와 문자열/Symbol token을 통한 **클래스가 아닌 값 주입**(구성 객체, 상수 — 인터페이스나 일반 값을 타입으로 주입할 수 없으므로); `useFactory`를 통한 **동적/비동기 provider 생성**(가장 강력한 형태 — 런타임 값에서 구성된 데이터베이스 연결, Redis 클라이언트, 서드파티 SDK 인스턴스를 자체 주입 의존성과 함께 생성); 그리고 token 뒤에서 `useClass`를 통한 **구현 교체**(환경 기반 구현과, 결정적으로 테스트에서의 쉬운 **mocking** — 소비자를 건드리지 않고 token에 mock 클래스 제공).

이 유연성이 NestJS의 DI를 프로덕션 아키텍처와 뛰어난 테스트 가능성에 강력하게 만드는 요소입니다.

네 가지 provider 타입(`useClass`, `useValue`, `useFactory`, `useExisting`), injection token이 클래스가 아닌 의존성에 어떻게 작동하는지, 그리고 각각을 언제 사용할지 아는 것은 기본 DI를 넘어선 중요한 단계입니다 — 데이터베이스, 외부 service, 구성, 교체/mock 가능한 의존성을 관용적인 NestJS 방식으로 연결하는 방법이며, 실제 애플리케이션에서 자주 필요하고 아키텍처적으로 중요한 주제입니다.