의존성 주입과 IoC 컨테이너

1장에서는 NestJS 기본 구성 요소와 첫 애플리케이션 동작 방식을 살펴봤습니다.

이제 2장에서는 NestJS를 더 효과적으로 활용하기 위한 핵심 개념을 깊이 있게 다룹니다.

첫 번째 주제는 의존성 주입(Dependency Injection, DI)과 제어의 역전(Inversion of Control, IoC) 컨테이너입니다.

이 두 개념은 NestJS의 근간을 이루며, 견고하고 유지보수하기 쉬운 애플리케이션을 만드는 데 필수적인 역할을 합니다.

핵심 원리를 단계적으로 정리하면 실제 설계와 구현에서 왜 필요한지 명확하게 확인할 수 있습니다.

의존성 주입이란 무엇인가?

의존성 주입과 IoC 컨테이너를 다룰 때 provider 등록, 주입 범위, 생명주기, 테스트 대역 기준을 확인합니다.

의존성이라는 단어는 한 클래스가 다른 클래스의 기능이나 데이터를 사용해야 할 때 발생합니다.

예를 들어, UserController가 사용자 정보를 처리하기 위해 UserService의 메서드를 호출해야 한다면, UserController는 UserService에 의존한다고 말할 수 있습니다.

만약 UserController가 UserService를 직접 생성하여 사용한다면 어떻게 될까요?

// 직접 UserService를 생성하는 방식 (DI를 사용하지 않음)
class UserService {
  getUsers() { /* ... */ }
}

class UserController {
  private userService: UserService;

  constructor() {
    this.userService = new UserService(); // 직접 의존성을 생성
  }

  getUsers() {
    return this.userService.getUsers();
  }
}

이 방식은 간단해 보이지만 몇 가지 문제점을 야기합니다.

• 강한 결합(Tight Coupling): UserController가 UserService의 구체적인 구현에 직접적으로 묶여 있습니다. UserService의 생성 방식이 변경되거나 다른 UserService 구현으로 교체해야 할 때 UserController 코드도 함께 수정해야 합니다.
• 테스트의 어려움: UserController를 테스트할 때 UserService까지 함께 인스턴스화됩니다. 이는 UserService가 데이터베이스 연결 등 복잡한 외부 의존성을 가지고 있을 경우, UserController의 단위 테스트를 어렵게 만듭니다. 우리는 컨트롤러 자체의 로직만 테스트하고 싶을 때가 많습니다.
• 코드 재사용성 저하: UserService를 사용하는 다른 클래스들도 각각 new UserService()를 통해 인스턴스를 생성해야 합니다.

의존성 주입은 이러한 문제점을 해결하기 위한 디자인 패턴입니다.

이는 객체가 자신이 필요로 하는 의존성을 직접 생성하는 대신, 외부(NestJS의 IoC 컨테이너)에서 해당 의존성을 주입받는 방식을 의미합니다.

쉽게 말해, 필요한 부품을 직접 만드는 대신, 외부에서 조립된 부품을 받아서 사용하는 것이죠.

NestJS에서는 주로 생성자 주입(Constructor Injection) 방식을 사용합니다.

// 의존성 주입 방식
import { Injectable } from '@nestjs/common';

@Injectable() // UserService는 주입 가능한 프로바이더임을 나타냅니다.
class UserService {
  getUsers() { /* ... */ }
}

@Controller()
class UserController {
  // NestJS가 자동으로 UserService 인스턴스를 생성하여 주입해줍니다.
  constructor(private readonly userService: UserService) {}

  getUsers() {
    return this.userService.getUsers();
  }
}

위 코드에서 UserController는 생성자를 통해 UserService 타입의 userService 인스턴스를 요청합니다.

new UserService()처럼 직접 인스턴스를 생성하지 않습니다.

대신 NestJS가 이 의존성을 감지하고 적절한 UserService 인스턴스를 찾아 UserController 생성자로 주입(Inject)해 줍니다.

• 느슨한 결합(Loose Coupling): 클래스들이 서로의 구체적인 구현에 묶이지 않고, 인터페이스(TypeScript 타입)에만 의존하게 되어 코드 변경에 유연하게 대응할 수 있습니다.
• 테스트 용이성: UserController를 테스트할 때, 실제 UserService 대신 가짜(mock 또는 stub) UserService를 주입하여 컨트롤러의 로직만을 순수하게 테스트할 수 있습니다.
• 코드 재사용성 및 관리 용이성: 하나의 UserService 인스턴스를 여러 곳에 재사용할 수 있으며, 의존성 관리가 중앙집중적으로 이루어져 효율적입니다.

제어의 역전 컨테이너

이제 의존성 주입이라는 개념을 이해했다면, 이를 실제로 구현하고 관리하는 주체에 대해 알아볼 차례입니다.

그것이 바로 제어의 역전(Inversion of Control, IoC) 컨테이너입니다.

일반적인 프로그래밍 흐름에서는 개발자가 객체를 직접 생성하고, 객체 간의 관계를 직접 제어합니다.

하지만 NestJS와 같은 프레임워크에서는 이 제어의 권한이 프레임워크에게 넘어갑니다.

이것을 제어의 역전(IoC)이라고 부릅니다.

IoC 컨테이너는 이 제어의 역전을 수행하는 핵심 메커니즘입니다.

NestJS의 IoC 컨테이너는 다음과 같은 역할을 수행합니다.

• 프로바이더 관리: @Injectable() 데코레이터가 붙은 클래스(프로바이더)들을 등록하고 관리합니다.
• 의존성 해결: 어떤 클래스가 특정 프로바이더를 필요로 할 때, 컨테이너가 해당 프로바이더의 인스턴스를 찾아 주입해 줍니다. 이때 필요하다면 해당 프로바이더의 의존성까지 재귀적으로 해결합니다.
• 인스턴스 생명주기 관리: 프로바이더의 인스턴스를 언제 생성하고, 언제 파괴할지(싱글톤, 스코프 등) 결정합니다. NestJS에서 대부분의 프로바이더는 기본적으로 싱글톤(Singleton) 스코프를 가집니다. 이는 애플리케이션 전체에서 해당 프로바이더의 인스턴스가 단 하나만 생성되어 공유된다는 의미입니다.

IoC 컨테이너는 등록된 프로바이더를 보관하고, 클래스 생성 시 필요한 의존성을 찾아 주입합니다.

클래스는 직접 의존 객체를 만들지 않고 필요한 타입을 선언하며, 컨테이너가 생성 순서와 인스턴스 전달을 관리합니다.

NestJS에서 @Module()의 providers 배열에 클래스를 등록하고 @Injectable()을 붙이는 행위는, IoC 컨테이너에 이 클래스는 주입 가능한 프로바이더라고 알리는 과정으로 볼 수 있습니다.

컨테이너는 이 정보를 바탕으로 내부 의존성 그래프를 구성하고, 필요할 때 인스턴스를 생성해 주입합니다.

아래 다이어그램은 providers 등록 정보가 컨테이너 내부 의존성 그래프로 정리되고, 생성자 주입으로 이어지는 흐름을 묶어 보여줍니다.

의존성 주입과 IoC 컨테이너는 NestJS의 모듈성, 테스트 용이성, 유지보수성을 구성하는 핵심 원리입니다.

서비스, 컨트롤러, 모듈의 책임을 분리할 때 이 구조를 기준으로 삼습니다.

다음 절에서는 NestJS 애플리케이션에서 요청을 처리하고 응답을 보내는 과정에서 핵심적인 역할을 하는 요청 파이프라인에 대해 자세히 알아보겠습니다.

const service = new UsersService(repo)

constructor(private users: UsersService) {}