인터페이스를 활용한 설계

우리는 2장에서 인터페이스 기본 문법을, 4장 3절에서 클래스와 인터페이스의 구현(implements) 관계를 살펴봤습니다.

이제는 인터페이스를 타입 선언 수준에서 한 단계 더 확장해 보겠습니다.

인터페이스는 유연하고 확장 가능한 설계를 만드는 강력한 도구이기도 합니다.

특히 객체 지향 설계 원칙인 개방-폐쇄 원칙(Open/Closed Principle)과 의존성 역전 원칙(Dependency Inversion Principle)을 구현할 때 인터페이스가 핵심 역할을 합니다.

인터페이스가 제공하는 '계약'의 중요성

인터페이스의 가장 중요한 역할은 클래스가 따라야 할 '계약' 또는 '청사진'을 정의하는 것입니다.

이 계약은 필요한 속성과 메서드의 타입 형태를 정합니다. log 메서드가 실제로 메시지를 기록하는지, 언제 예외를 던지는지 같은 동작의 의미는 구현·명세·검증으로 별도 확인합니다. 타입 계약을 만족하는 빈 log 메서드도 작성할 수 있기 때문입니다.

// 서비스가 제공해야 할 '로그' 기능을 정의하는 인터페이스
interface Logger {
  log(message: string): void;
  error(message: string): void;
  warn(message: string): void;
}

// Logger 인터페이스를 구현하는 실제 로거 클래스
class ConsoleLogger implements Logger {
  log(message: string): void {
    console.log(`[INFO] ${message}`);
  }
  error(message: string): void {
    console.error(`[ERROR] ${message}`);
  }
  warn(message: string): void {
    console.warn(`[WARN] ${message}`);
  }
}

// Logger 인터페이스를 구현하는 다른 로거 클래스 (예: 파일에 기록)
class FileLogger implements Logger {
  private fileName: string;

  constructor(fileName: string) {
    this.fileName = fileName;
  }

  log(message: string): void {
    console.log(`[FILE LOG - INFO] ${this.fileName}: ${message}`);
    // 실제 파일 기록 로직 (생략)
  }
  error(message: string): void {
    console.error(`[FILE LOG - ERROR] ${this.fileName}: ${message}`);
    // 실제 파일 기록 로직 (생략)
  }
  warn(message: string): void {
    console.warn(`[FILE LOG - WARN] ${this.fileName}: ${message}`);
    // 실제 파일 기록 로직 (생략)
  }
}

// 어떤 Logger 구현체든 사용할 수 있는 모듈
class DataProcessor {
  private logger: Logger; // Logger 인터페이스 타입으로 의존성을 선언

  constructor(logger: Logger) { // 생성자 주입
    this.logger = logger;
  }

  processData(): void {
    this.logger.log("데이터 처리 시작...");
    try {
      // 데이터 처리 로직...
      this.logger.warn("임시 파일 생성됨.");
      // ...
      this.logger.log("데이터 처리 완료.");
    } catch (e: any) {
      this.logger.error(`데이터 처리 중 오류 발생: ${e.message}`);
    }
  }
}

// 애플리케이션 초기화 시점에 원하는 로거를 주입
const consoleLogger = new ConsoleLogger();
const fileLogger = new FileLogger("app.log");

const processor1 = new DataProcessor(consoleLogger);
processor1.processData();
// 출력:
// [INFO] 데이터 처리 시작...
// [WARN] 임시 파일 생성됨.
// [INFO] 데이터 처리 완료.

const processor2 = new DataProcessor(fileLogger);
processor2.processData();
// 출력:
// [FILE LOG - INFO] app.log: 데이터 처리 시작...
// [FILE LOG - WARN] app.log: 임시 파일 생성됨.
// [FILE LOG - INFO] app.log: 데이터 처리 완료.

이 예시에서 Logger 인터페이스는 log, error, warn 메서드를 가져야 한다는 계약을 정의합니다.

ConsoleLogger와 FileLogger는 이 계약을 구현하므로, DataProcessor는 구체적인 로거 클래스 대신 Logger 인터페이스에 의존합니다. 이 예제의 FileLogger도 실제 파일 쓰기는 생략하고 콘솔에 파일명을 표시합니다. 그림의 테스트 대역은 같은 계약으로 교체할 수 있는 설계 예시입니다.

다형성을 통한 유연한 설계

인터페이스를 활용한 설계의 핵심은 다형성(Polymorphism)입니다.

다형성은 하나의 인터페이스(또는 부모 클래스) 타입으로 여러 구체 구현체를 다룰 수 있게 해줍니다.

위 DataProcessor 예시에서 this.logger는 ConsoleLogger일 수도 있고 FileLogger일 수도 있지만, Logger 인터페이스가 정의한 메서드(log, error, warn)를 호출하는 방식은 동일합니다.

이는 다음과 같은 장점을 제공합니다.

• 코드의 유연성: DataProcessor는 어떤 Logger 구현체를 사용할지 미리 알 필요가 없습니다. 런타임에 어떤 Logger 인스턴스가 주입되든 관계없이 동일한 방식으로 log 기능을 사용할 수 있습니다.
• 쉬운 확장성: 새로운 로거 구현체(예: DatabaseLogger, CloudLogger)가 추가되어도, Logger 인터페이스만 구현하면 DataProcessor 코드를 전혀 수정할 필요 없이 새로운 로거를 사용할 수 있습니다. 이 경우 소비자 호출 코드를 유지하면서 새 구현을 추가하는 방식은 개방-폐쇄 원칙(확장에는 열려 있고, 수정에는 닫혀 있다)의 적용 예입니다. 실제 객체를 선택하고 생성자로 전달하는 초기화 코드는 바뀔 수 있으며, Logger 계약 자체가 바뀌면 소비자도 영향을 받습니다.
• 테스트 용이성: 실제 FileLogger 대신 테스트를 위한 가짜(Mock) Logger 구현체를 DataProcessor에 주입하여 단위 테스트를 훨씬 쉽게 수행할 수 있습니다.

인터페이스 관점의 의존성 역전 원칙

인터페이스를 활용한 설계는 의존성 역전 원칙(DIP)과 밀접하게 관련됩니다.

DIP는 SOLID 원칙 중 하나로, 다음과 같이 요약됩니다.

위 Logger 예시에서,

• 고수준 모듈: DataProcessor (로그 기능이라는 추상적인 아이디어를 사용).
• 저수준 모듈: ConsoleLogger, FileLogger (로그 기능을 실제로 구현하는 세부 사항).
• 추상화: Logger 인터페이스.

DataProcessor는 ConsoleLogger나 FileLogger 같은 구체 저수준 모듈에 직접 의존하지 않고, Logger라는 추상화(인터페이스)에 의존합니다.

그리고 ConsoleLogger와 FileLogger는 Logger 인터페이스라는 추상화에 의존하여 구현됩니다.

이렇게 의존성 방향을 역전시키면 각 모듈의 결합도를 낮추고 유연성을 높일 수 있습니다.

인터페이스 활용 시나리오

인터페이스는 다양한 설계 패턴과 시나리오에서 강력한 도구로 활용됩니다.

인터페이스 확장 (복습)

인터페이스는 다른 인터페이스를 확장(extends)하여 더 구체적인 계약을 만들 수 있습니다.

이는 타입 계층 구조를 형성하는 데 유용합니다.

interface Disposable {
  dispose(): void; // 자원을 해제하는 기능
}

interface RunnableProcess extends Disposable {
  run(): void;       // 프로세스를 실행하는 기능
  isRunning: boolean; // 실행 중 상태
}

class BackgroundTask implements RunnableProcess {
  isRunning: boolean = false;

  run(): void {
    console.log("백그라운드 작업 시작...");
    this.isRunning = true;
  }

  dispose(): void {
    console.log("백그라운드 작업 자원 해제.");
    this.isRunning = false;
  }
}

const task = new BackgroundTask();
task.run();
// ... 작업 수행 ...
task.dispose();

RunnableProcess는 Disposable의 dispose 메서드를 포함하면서 자신만의 run 메서드와 isRunning 속성을 추가합니다.

BackgroundTask는 이 모든 계약을 구현해야 합니다.

인터페이스를 확장할 때는 "무엇을 물려받는가"와 "구현체가 무엇을 책임지는가"를 나눠 보면 구조가 선명해집니다.

인터페이스는 타입스크립트에서 코드 구조와 객체 간 계약을 표현하는 도구입니다.

단순히 타입을 정의하는 것을 넘어 객체 지향 원칙, 협업, 테스트 용이성을 높이는 기준으로 활용할 수 있습니다.

인터페이스 기반 설계에서는 호출자가 구체 클래스 대신 필요한 계약에 의존하도록 바꾸고, 초기화 시점에 실제 구현 객체를 전달합니다.

호출자는 계약에 기대고, 구현체는 계약을 만족하도록 교체됩니다.

예시

첫 Logger/DataProcessor 코드 블록을 실행한 뒤 아래 메모리 대역을 이어 붙입니다. 파일을 만들지 않고 실제 정상 경로의 호출 순서와 메시지를 배열에 기록합니다. 인터페이스 객체를 생성하는 것이 아니라 같은 구조를 만족하는 객체를 생성자로 전달합니다.

class MemoryLogger implements Logger {
  readonly entries: string[] = [];
  log(message: string): void { this.entries.push(`INFO: ${message}`); }
  warn(message: string): void { this.entries.push(`WARN: ${message}`); }
  error(message: string): void { this.entries.push(`ERROR: ${message}`); }
}
const memoryLogger = new MemoryLogger();
new DataProcessor(memoryLogger).processData();
console.log(memoryLogger.entries.join(' | '));
// INFO: 데이터 처리 시작... | WARN: 임시 파일 생성됨. | INFO: 데이터 처리 완료.

processData는 log → warn → log를 호출하고 MemoryLogger는 순서대로 push합니다. entries의 readonly는 배열 참조의 재대입을 제한하며 내부 push를 막지 않습니다. 이 정상 경로에 오류가 없어서 error는 아직 호출되지 않습니다. 이 검사 하나로 실패 경로·파일 쓰기·영속성이 검증됐다고 판단하지 않습니다.

혼자 대역과 계약을 변경하기

① 같은 memoryLogger에 DataProcessor를 하나 더 생성해 processData를 한 번 실행하면 기록 개수와 순서는 어떻게 될까요? ② MemoryLogger.error를 삭제하면 현재 정상 경로에서는 쓰지 않아도 타입 계약은 통과할까요? ③ 원 BackgroundTask를 run() 전, run() 직후, dispose() 직후에 읽는 isRunning 값은 무엇일까요?