의존성 주입과 IoC 컨테이너

앞의 두 글에서 결제 처리기와 장바구니는 쓸 로거나 결제 전략을 직접 만들지 않고 바깥에서 넘겨받았습니다. 이렇게 객체가 필요로 하는 다른 객체, 곧 의존성(dependency)을 스스로 만들거나 찾지 않고 바깥에서 받는 방식을 의존성 주입(dependency injection)이라고 합니다. 어떤 구현을 쓸지 정하는 일이 그 객체에서 바깥으로 옮겨 가므로, 이를 제어의 역전(inversion of control)이라고도 부릅니다.

이 글은 의존성을 넘겨받는 세 가지 방법을 비교하고, 객체를 만들고 잇는 일을 한곳에 모으는 조립 루트를 봅니다. 이어서 그 조립을 대신해 주는 작은 IoC 컨테이너를 직접 만들어 토큰과 객체의 수명이 무엇인지 확인하고, 마지막으로 데코레이터를 쓰는 컨테이너 라이브러리와 비교합니다.

의존성을 넘겨받는 세 가지 방법

다음 UserService는 기록할 때 쓸 로거를 세 가지 방법으로 받을 수 있게 만든 것입니다. 로거는 AppLogger 인터페이스만 지키면 되므로, UserService는 받은 것이 ConsoleLogger인지 FileLogger인지 모른 채 log()만 부릅니다. 맨 아래의 네 줄이 세 가지 방법을 하나씩 써 봅니다.

interface AppLogger {
  log(message: string): void;
}

class ConsoleLogger implements AppLogger {
  log(message: string): void {
    console.log(`[Console Log]: ${message}`);
  }
}

class FileLogger implements AppLogger {
  log(message: string): void {
    console.log(`[File Log]: ${message}`);
  }
}

class UserService {
  constructor(private logger: AppLogger) {}

  registerUser(username: string, logger: AppLogger = this.logger): void {
    logger.log(`Registering user: ${username}`);
  }

  setLogger(logger: AppLogger): void {
    this.logger = logger;
  }

  processUserData(data: unknown): void {
    this.logger.log(`Processing user data: ${JSON.stringify(data)}`);
  }
}

const service = new UserService(new ConsoleLogger());
service.registerUser("Alice");
service.registerUser("Charlie", new FileLogger());
service.setLogger(new FileLogger());
service.processUserData({ id: 3, name: "David" });

[Console Log]: Registering user: Alice
[File Log]: Registering user: Charlie
[File Log]: Processing user data: {"id":3,"name":"David"}

생성자 주입(constructor injection)은 객체를 만들 때 생성자로 의존성을 받는 방법이어서, 첫 줄처럼 만든 직후부터 객체가 완전한 상태입니다. 메서드 주입(method injection)은 둘째 줄처럼 특정 호출에서만 다른 의존성을 넘기는 방법이고, 세터 주입(setter injection)은 셋째 호출처럼 만든 뒤에 의존성을 바꾸는 방법입니다.

세 방법 가운데 기본으로 쓰는 것은 생성자 주입입니다. 필요한 의존성이 생성자의 매개변수로 드러나므로 빠뜨리면 컴파일러가 알려 주고, 의존성을 readonly로 두어 만든 뒤에 바뀌지 않게 할 수도 있습니다. 세터 주입은 객체가 의존성 없이 존재하는 시간이 생기고 언제 바뀌었는지 추적하기 어려우므로, 정말로 실행 중에 바꾸어야 할 때만 씁니다.

조립 루트

의존성을 바깥에서 넘긴다면, 결국 누군가는 실제 객체를 만들어 이어야 합니다. 이 일을 프로그램의 시작 지점 한곳에 모아 두는 것을 조립 루트(composition root)라고 합니다.

const logger: AppLogger = process.env.NODE_ENV === "test" ? new FileLogger() : new ConsoleLogger();
const userService = new UserService(logger);
userService.registerUser("Grace");

UserService는 어떤 로거가 들어올지 모르고, 환경에 따라 로거를 고르는 판단은 조립 루트에만 있습니다. 테스트에서는 같은 자리에서 기록을 배열에 모으는 로거를 넘기면 되므로, 서비스의 코드를 고치지 않고 동작을 확인할 수 있습니다.

위 코드는 process를 쓰므로 9장에서 본 것처럼 "types": ["node"]가 필요합니다. 또 AppLogger와 두 로거, UserService를 import 없이 쓰는데, 이 선언들은 injection-styles.ts에 있습니다. main.ts만 컴파일하면 그 이름을 찾지 못한다는 진단이 나옵니다. "type": "commonjs"인 ts-first에서는 import와 export가 없는 두 파일이 전역 스크립트로 검사되어 함께 컴파일하면 검사는 통과하지만, Node.js는 출력된 파일을 하나씩 따로 실행하므로 node dist/main.js에서는 그 클래스를 찾지 못합니다. 그래서 따라 할 때는 injection-styles.ts의 선언과 한 파일에 둡니다.

위 그림처럼 조립 코드가 환경에 맞는 로거를 골라 만들고, 그 로거를 UserService의 생성자에 넘깁니다. 업무 정책을 담은 UserService는 로거를 만들지 않으며, 객체를 만들고 잇는 일과 업무 규칙이 서로 다른 곳에 놓입니다. 그림이 구별하는 데코레이터 기반의 예는 이 글의 뒤에서 봅니다.

작은 IoC 컨테이너 만들기

객체가 몇 개 안 된다면 조립 루트에서 직접 new를 써도 충분합니다. 객체가 많아지고 서로 얽히면, 무엇을 만들지와 몇 개를 만들지를 등록해 두고 필요할 때 대신 만들어 주는 IoC 컨테이너(IoC container)가 조립을 맡습니다. 그 원리를 보기 위해 작은 컨테이너를 직접 만들어 봅니다.

type Token<T> = symbol & { readonly __type?: T };

function createToken<T>(description: string): Token<T> {
  return Symbol(description) as Token<T>;
}

type Factory<T> = (container: Container) => T;

class Container {
  private providers = new Map<symbol, { factory: Factory<unknown>; singleton: boolean }>();
  private singletons = new Map<symbol, unknown>();

  register<T>(token: Token<T>, factory: Factory<T>, options: { singleton?: boolean } = {}): void {
    if (this.providers.has(token)) {
      throw new Error(`Already registered: ${token.description}`);
    }
    this.providers.set(token, { factory, singleton: options.singleton ?? false });
  }

  resolve<T>(token: Token<T>): T {
    const provider = this.providers.get(token);
    if (provider === undefined) {
      throw new Error(`No provider for ${token.description}`);
    }
    if (!provider.singleton) {
      return provider.factory(this) as T;
    }
    if (!this.singletons.has(token)) {
      this.singletons.set(token, provider.factory(this));
    }
    return this.singletons.get(token) as T;
  }
}

인터페이스는 실행 중에 사라지므로, 컨테이너가 "로거를 달라"는 요청을 알아보려면 실행 중에도 남는 표시가 필요합니다. 그 표시가 토큰(token)이며, 여기서는 Symbol로 만들고 타입 매개변수 T로 그 토큰이 가리키는 값의 타입을 함께 기억하게 했습니다. register는 토큰마다 객체를 만드는 함수와 수명을 기록하고, resolve는 그 함수를 불러 객체를 만들되 singleton으로 등록한 것은 처음 만든 객체를 저장해 두었다가 다시 돌려줍니다.

다음 코드도 앞의 선언들을 가져오지 않고 그대로 씁니다. 아래의 출력을 확인하려면 injection-styles.ts에서 맨 아래의 실행 코드 다섯 줄을 뺀 선언과 container.ts를 이 코드와 한 파일에 이어 붙여 실행합니다.

const LOGGER = createToken<AppLogger>("Logger");
const USER_SERVICE = createToken<UserService>("UserService");

let createdLoggers = 0;
const container = new Container();
container.register(LOGGER, () => {
  createdLoggers += 1;
  return new ConsoleLogger();
}, { singleton: true });
container.register(USER_SERVICE, (c) => new UserService(c.resolve(LOGGER)));

const first = container.resolve(USER_SERVICE);
const second = container.resolve(USER_SERVICE);
console.log(first === second, createdLoggers);
first.registerUser("Grace");

false 1
[Console Log]: Registering user: Grace

UserService는 수명을 정하지 않았으므로 resolve할 때마다 새로 만들어져 두 서비스는 서로 다른 객체이고, 로거는 singleton으로 등록했으므로 한 번만 만들어져 두 서비스가 함께 씁니다. USER_SERVICE를 만드는 함수가 안에서 c.resolve(LOGGER)를 부르므로, 컨테이너는 요청받은 객체가 필요로 하는 의존성을 차례로 풀어 완성된 객체를 돌려줍니다.

위 그림은 이 과정을 단계별로 보여 줍니다. 시작 코드가 토큰과 만드는 규칙을 먼저 등록하고, 쓰는 쪽이 UserService를 요청하면 컨테이너가 안에서 로거의 의존성을 찾아 수명의 규칙에 따라 새로 만들거나 저장해 둔 것을 쓴 뒤, 완성된 객체를 돌려줍니다. 등록이 끝나면 컨테이너는 의존 관계를 다시 시작 코드에 묻지 않습니다.

데코레이터를 쓰는 컨테이너 라이브러리

InversifyJS나 TSyringe 같은 라이브러리와 NestJS 프레임워크는 위의 컨테이너를 더 발전시켜, 클래스에 붙인 데코레이터(decorator)로 등록과 주입을 적게 합니다. 예를 들어 InversifyJS에서는 다음과 같은 모양이 됩니다.

import { Container, inject, injectable } from "inversify";

const TYPES = { Logger: Symbol.for("Logger") };

@injectable()
class InjectedConsoleLogger implements AppLogger {
  log(message: string): void {
    console.log(`[Console Log]: ${message}`);
  }
}

@injectable()
class InjectedUserService {
  constructor(@inject(TYPES.Logger) private logger: AppLogger) {}

  registerUser(username: string): void {
    this.logger.log(`Registering user: ${username}`);
  }
}

const inversify = new Container();
inversify.bind<AppLogger>(TYPES.Logger).to(InjectedConsoleLogger);
inversify.bind(InjectedUserService).toSelf();
inversify.get(InjectedUserService).registerUser("Grace");

@inject(TYPES.Logger)가 생성자 매개변수에 어떤 토큰의 객체를 넣을지 알려 주므로, 위에서 직접 썼던 만드는 함수를 쓰지 않아도 됩니다. 대신 서비스 클래스가 컨테이너 라이브러리의 데코레이터에 의존하게 되어, 앞의 순수한 생성자 주입과 달리 업무 코드에도 조립을 위한 표시가 들어갑니다. 생성자 매개변수에 붙이는 데코레이터는 TypeScript 5.0의 표준 데코레이터에 없는 기능이어서, 이런 라이브러리는 experimentalDecorators 같은 예전 방식의 옵션과 라이브러리가 요구하는 설정을 따로 켜야 하며, Node.js의 타입 제거 실행으로는 데코레이터를 실행할 수 없습니다. 정확한 설정과 API는 사용하는 버전의 InversifyJS 공식 문서를 확인합니다.

컨테이너는 의존성 주입에 꼭 필요한 도구가 아닙니다. 객체가 많지 않다면 조립 루트에서 직접 만들어 넘기는 편이 읽기 쉽고 실행 중의 비용도 없습니다. 컨테이너는 객체의 수가 늘어 조립 코드가 복잡해지고, 수명의 규칙을 한곳에서 관리해야 할 때 도입을 검토합니다.

더 깊이: 예전 데코레이터와 표준 데코레이터

타입스크립트의 experimentalDecorators는 데코레이터 제안의 아주 오래된 판을 본뜬 기능입니다. TypeScript 5.0 릴리스 노트에 따르면 5.0부터는 이 옵션 없이도 표준 제안을 따르는 데코레이터를 쓸 수 있는데, 두 방식은 타입 검사 규칙과 출력이 크게 달라서 기존의 데코레이터 함수가 표준 방식에서 그대로 동작할 가능성은 낮습니다. 또 표준 데코레이터는 매개변수에 붙일 수 없고 emitDecoratorMetadata와도 함께 쓸 수 없습니다. 생성자 매개변수에 @inject를 붙이는 컨테이너가 여전히 예전 옵션을 요구하는 것은 이 때문입니다.

emitDecoratorMetadata는 예전 방식의 데코레이터가 붙은 선언마다, 매개변수와 반환값의 타입을 실행 중에 읽을 수 있는 값으로 남기는 옵션입니다. TSConfig 레퍼런스의 예에서는 number 매개변수를 받는 메서드에 __metadata("design:paramtypes", [Number]) 같은 코드가 출력되고, 이 정보는 reflect-metadata 모듈과 함께 읽습니다. 컨테이너는 이런 정보로 생성자가 어떤 클래스를 받는지 알아낼 수 있지만, 인터페이스는 실행 중에 남지 않으므로 인터페이스 타입의 매개변수에는 이 글의 TYPES.Logger 같은 토큰을 따로 적어야 합니다.

표준 쪽에도 TypeScript 5.2부터 데코레이터 메타데이터(decorator metadata)가 들어왔습니다. 데코레이터가 받는 문맥 객체의 metadata 속성에 값을 적어 두면, 클래스의 모든 데코레이터가 실행된 뒤 클래스[Symbol.metadata]로 그 객체를 읽을 수 있습니다. 다만 이 객체는 데코레이터가 직접 채우는 빈 사전일 뿐 컴파일러가 타입 정보를 넣어 주지는 않으며, 릴리스 노트가 나올 당시에는 대부분의 런타임이 지원하지 않아 Symbol.metadata의 폴리필과 esnext.decorators 라이브러리 설정이 필요했습니다.

정리

• 의존성 주입은 객체가 필요한 의존성을 바깥에서 받는 방식이며, 어떤 구현을 쓸지 정하는 일이 바깥으로 옮겨 갑니다.
• 생성자 주입은 만든 직후부터 객체가 완전하고 빠뜨린 의존성을 컴파일러가 알려 주므로 기본으로 쓰고, 세터 주입은 실행 중에 바꿀 때만 씁니다.
• 객체를 만들고 잇는 일은 조립 루트 한곳에 모아, 업무 코드가 구현의 선택을 모르게 합니다.
• IoC 컨테이너는 실행 중에도 남는 토큰과 만드는 규칙, 수명을 등록받아 요청된 객체의 의존성을 차례로 풀어 줍니다.
• 데코레이터를 쓰는 컨테이너 라이브러리는 등록을 줄이는 대신 업무 코드에 조립의 표시가 들어가며, 작은 프로그램은 컨테이너 없이도 충분합니다.

연습 문제

1. 같은 설명의 다른 토큰

container.resolve(createToken<AppLogger>("Logger"))를 부르면 어떻게 되나요? 설명 문자열은 등록할 때와 같은데 왜 그런가요?

2. 수명을 바꾸었을 때

USER_SERVICE도 { singleton: true }로 등록하고, 로거는 수명을 정하지 않은 채로 바꾸었습니다. first === second와 createdLoggers는 각각 무엇이 되나요?

3. 두 번 등록하기

같은 LOGGER 토큰에 ConsoleLogger를 등록한 뒤 FileLogger를 한 번 더 등록하면 이 컨테이너는 어떻게 되나요? 왜 마지막 등록을 조용히 쓰지 않도록 만들었을까요?

다음 글 테스트 주도 개발 (TDD)에서는 테스트를 먼저 쓰고 그 테스트를 통과하는 코드를 만드는 순서로, Jest를 써서 작은 문자열 함수를 개발하는 방법을 다룹니다.