Waylog Blog
← 목록으로 돌아가기

TypeScript로 배우는 GoF 디자인 패턴: 실무 중심 완벽 가이드

TypeScript

소프트웨어 개발에는 수십 년간 검증된 지혜가 담긴 설계 원칙이 있습니다. 1994년 Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides — 흔히 "Gang of Four (GoF)"로 불리는 네 명의 저자가 23가지 디자인 패턴을 체계화한 이후, 이 패턴들은 소프트웨어 설계의 공용어가 되었습니다. 하지만 많은 개발자들이 디자인 패턴을 단순히 암기해야 할 이론으로 취급하다 보니, 정작 실무에서 활용하지 못하는 경우가 많습니다.

본 포스트에서는 TypeScript의 강력한 타입 시스템을 활용하여 GoF 디자인 패턴 중 실무에서 가장 자주 등장하는 핵심 패턴들을 깊이 있게 다룹니다. TypeScript가 왜 디자인 패턴을 배우기에 이상적인 언어인지, 그리고 각 패턴이 프론트엔드와 백엔드 코드베이스에서 어떻게 문제를 해결하는지 살펴보겠습니다.

1. 디자인 패턴이란 무엇이고, 왜 TypeScript인가?

디자인 패턴은 소프트웨어 설계 과정에서 반복적으로 나타나는 문제에 대한 재사용 가능한 해결책입니다. 특정 언어나 프레임워크에 종속된 것이 아니라, 어떤 언어에서도 적용 가능한 개념적 청사진(Blueprint)입니다.

TypeScript가 디자인 패턴 학습에 최적인 이유

TypeScript는 정적 타입 시스템을 갖춘 JavaScript의 상위집합(Superset)으로, 다음과 같은 이유에서 디자인 패턴 학습에 최적화되어 있습니다.

인터페이스와 추상 클래스: TypeScript의 interface와 abstract class는 GoF 패턴의 "추상화에 프로그래밍하라"는 원칙을 코드 레벨에서 강제합니다. 구현체가 아닌 계약(Contract)에 의존하게 함으로써 패턴의 본질을 명확하게 드러냅니다.

제네릭(Generics): 타입 안전성을 유지하면서 재사용 가능한 패턴을 구현할 수 있습니다. 자바의 제네릭과 유사하지만 구조적 타입(Structural Typing) 시스템 덕분에 더 유연하게 활용됩니다.

타입 추론과 유니온 타입: 복잡한 상태 패턴이나 전략 패턴에서 타입 안전한 분기 처리가 가능합니다.

디자인 패턴은 크게 세 가지 범주로 나뉩니다. 생성 패턴(Creational), 구조 패턴(Structural), 행동 패턴(Behavioral)입니다. 각 범주에서 실무적 가치가 높은 패턴들을 중점적으로 살펴보겠습니다.

2. 생성 패턴(Creational Patterns): 객체를 어떻게 만들 것인가

2.1 싱글턴 패턴 (Singleton Pattern)

문제: 애플리케이션 전역에서 오직 하나의 인스턴스만 존재해야 하는 객체가 필요합니다. 데이터베이스 연결 풀, 로거(Logger), 환경 설정(Configuration) 관리자 등이 대표적입니다.

TypeScript 구현:

class DatabaseConnection {
  private static instance: DatabaseConnection;
  private connectionCount: number = 0;

  // 외부에서 new 키워드로 직접 생성 불가
  private constructor(private readonly host: string) {}

  public static getInstance(host: string): DatabaseConnection {
    if (!DatabaseConnection.instance) {
      DatabaseConnection.instance = new DatabaseConnection(host);
    }
    return DatabaseConnection.instance;
  }

  public connect(): void {
    this.connectionCount++;
    console.log(`${this.host}에 연결됨 (총 연결 횟수: ${this.connectionCount})`);
  }
}

// 사용 예시
const db1 = DatabaseConnection.getInstance('localhost:5432');
const db2 = DatabaseConnection.getInstance('localhost:5432');

console.log(db1 === db2); // true — 동일한 인스턴스
db1.connect(); // localhost:5432에 연결됨 (총 연결 횟수: 1)
db2.connect(); // localhost:5432에 연결됨 (총 연결 횟수: 2)

실무 적용 포인트: Next.js 환경에서 Prisma Client나 Redis 클라이언트를 싱글턴으로 관리하는 패턴이 대표적입니다. 서버리스(Serverless) 환경에서는 콜드 스타트 문제 때문에 모듈 캐싱을 활용한 싱글턴 구현이 필수입니다. 단, React 같은 클라이언트 사이드 코드에서 싱글턴을 남용하면 전역 상태가 테스트를 오염시키는 문제가 생기므로 주의해야 합니다.

2.2 팩토리 메서드 패턴 (Factory Method Pattern)

문제: 객체 생성 로직을 서브클래스에 위임하고 싶습니다. 어떤 구현체가 생성될지는 런타임에 결정되지만, 생성하는 코드(클라이언트)는 구체적인 클래스 이름을 알 필요가 없어야 합니다.

// 추상 제품(Product) 정의
interface Notification {
  send(message: string): void;
}

// 구체적인 제품들
class EmailNotification implements Notification {
  constructor(private readonly email: string) {}
  send(message: string): void {
    console.log(`이메일 (${this.email})로 발송: ${message}`);
  }
}

class SlackNotification implements Notification {
  constructor(private readonly channel: string) {}
  send(message: string): void {
    console.log(`슬랙 채널 #${this.channel}로 발송: ${message}`);
  }
}

class SMSNotification implements Notification {
  constructor(private readonly phoneNumber: string) {}
  send(message: string): void {
    console.log(`SMS (${this.phoneNumber})로 발송: ${message}`);
  }
}

// 팩토리 함수
type NotificationType = 'email' | 'slack' | 'sms';

function createNotification(type: NotificationType, target: string): Notification {
  switch (type) {
    case 'email':
      return new EmailNotification(target);
    case 'slack':
      return new SlackNotification(target);
    case 'sms':
      return new SMSNotification(target);
    default:
      // TypeScript의 exhaustiveness check 활용
      const _exhaustive: never = type;
      throw new Error(`알 수 없는 알림 유형: ${_exhaustive}`);
  }
}

// 클라이언트 코드는 구체 클래스를 모름
const userPreference: NotificationType = 'slack';
const notification = createNotification(userPreference, 'dev-alerts');
notification.send('배포가 완료되었습니다!'); // 슬랙 채널 #dev-alerts로 발송: 배포가 완료되었습니다!

TypeScript의 유니온 타입과 never 타입을 활용한 exhaustiveness check는 새로운 알림 유형이 추가될 때 switch문을 업데이트하지 않으면 컴파일 오류를 발생시킵니다. 이는 JavaScript로는 얻을 수 없는 강력한 타입 안전성입니다.

3. 구조 패턴(Structural Patterns): 객체를 어떻게 조합할 것인가

3.1 데코레이터 패턴 (Decorator Pattern)

문제: 기존 객체의 코드를 변경하지 않고 새로운 기능을 동적으로 추가하고 싶습니다. 상속(Inheritance)을 사용하면 클래스가 폭발적으로 증가하는 문제가 생깁니다.

데코레이터 패턴은 커피 주문을 생각하면 쉽습니다. 기본 아메리카노에 우유, 시럽, 크림을 추가하는 방식으로, 각 추가 옵션이 기본 커피를 "감싸는(Wrapping)" 구조입니다.

// 기본 컴포넌트 인터페이스
interface DataSource {
  writeData(data: string): void;
  readData(): string;
}

// 기본 구현체 (파일 데이터 소스)
class FileDataSource implements DataSource {
  private data: string = '';

  constructor(private readonly filename: string) {}

  writeData(data: string): void {
    this.data = data;
    console.log(`${this.filename}에 원본 데이터 저장: ${data.substring(0, 50)}`);
  }

  readData(): string {
    return this.data;
  }
}

// 기본 데코레이터
abstract class DataSourceDecorator implements DataSource {
  constructor(protected wrappee: DataSource) {}

  writeData(data: string): void {
    this.wrappee.writeData(data);
  }

  readData(): string {
    return this.wrappee.readData();
  }
}

// 암호화 데코레이터
class EncryptionDecorator extends DataSourceDecorator {
  private encrypt(data: string): string {
    // 실제로는 AES 등 암호화 알고리즘 적용
    return Buffer.from(data).toString('base64');
  }
  private decrypt(data: string): string {
    return Buffer.from(data, 'base64').toString('utf8');
  }

  writeData(data: string): void {
    super.writeData(this.encrypt(data));
  }

  readData(): string {
    return this.decrypt(super.readData());
  }
}

// 압축 데코레이터
class CompressionDecorator extends DataSourceDecorator {
  writeData(data: string): void {
    const compressed = `[COMPRESSED]${data}`; // 실제로는 zlib 등 사용
    super.writeData(compressed);
  }
}

// 유연한 조합
const source = new FileDataSource('data.txt');
const encrypted = new EncryptionDecorator(source);
const encryptedAndCompressed = new CompressionDecorator(encrypted);

encryptedAndCompressed.writeData('중요한 사용자 데이터입니다');

실무 적용: TypeScript의 실험적 기능인 @Decorator 문법(ECMAScript Stage 3)은 NestJS 프레임워크에서 광범위하게 사용됩니다. @Injectable(), @Controller(), @UseGuards() 등이 모두 데코레이터 패턴의 응용입니다. React에서도 고차 컴포넌트(HOC, Higher-Order Component)가 데코레이터 패턴의 변형입니다.

3.2 어댑터 패턴 (Adapter Pattern)

문제: 호환되지 않는 두 인터페이스를 연결해야 합니다. 레거시 시스템의 API를 새로운 인터페이스로 감싸거나, 외부 라이브러리를 내부 추상화로 래핑하는 경우에 필수적입니다.

// 우리 시스템이 기대하는 인터페이스
interface AnalyticsService {
  trackEvent(eventName: string, properties: Record<string, unknown>): void;
  trackPageView(path: string): void;
}

// 외부 라이브러리 A의 인터페이스 (변경 불가)
class GoogleAnalytics {
  gtag(command: string, ...args: unknown[]): void {
    console.log(`GA gtag(${command}, ${JSON.stringify(args)})`);
  }
}

// 외부 라이브러리 B의 인터페이스 (변경 불가)
class MixpanelSDK {
  track(event: string, data: object): void {
    console.log(`Mixpanel.track(${event}, ${JSON.stringify(data)})`);
  }
  page(url: string): void {
    console.log(`Mixpanel.page(${url})`);
  }
}

// 어댑터 구현
class GoogleAnalyticsAdapter implements AnalyticsService {
  private ga = new GoogleAnalytics();

  trackEvent(eventName: string, properties: Record<string, unknown>): void {
    this.ga.gtag('event', eventName, properties);
  }

  trackPageView(path: string): void {
    this.ga.gtag('config', 'GA_MEASUREMENT_ID', { page_path: path });
  }
}

class MixpanelAdapter implements AnalyticsService {
  private mixpanel = new MixpanelSDK();

  trackEvent(eventName: string, properties: Record<string, unknown>): void {
    this.mixpanel.track(eventName, properties);
  }

  trackPageView(path: string): void {
    this.mixpanel.page(path);
  }
}

// 클라이언트 코드는 어떤 분석 도구가 사용되는지 알 필요 없음
function trackPurchase(analytics: AnalyticsService, amount: number): void {
  analytics.trackEvent('purchase_completed', { amount, currency: 'KRW' });
}

const analytics: AnalyticsService = new MixpanelAdapter();
trackPurchase(analytics, 29900);

어댑터 패턴은 "개방/폐쇄 원칙(Open/Closed Principle)"을 실현하는 핵심 도구입니다. 분석 도구를 교체하더라도 클라이언트 코드는 단 한 줄도 변경할 필요가 없습니다.

4. 행동 패턴(Behavioral Patterns): 객체 간 책임과 알고리즘

4.1 옵저버 패턴 (Observer Pattern)

문제: 한 객체의 상태가 변했을 때, 이에 의존하는 여러 객체들이 자동으로 알림을 받아 업데이트되어야 합니다. 이벤트 기반 시스템, 실시간 알림, MVC 아키텍처의 모델-뷰 동기화가 대표적인 사례입니다.

// 옵저버 인터페이스
interface Observer<T> {
  update(event: T): void;
}

// 주제(Subject) 인터페이스
interface Observable<T> {
  subscribe(observer: Observer<T>): () => void; // 구독 해제 함수 반환
  notify(event: T): void;
}

// 제네릭을 활용한 타입 안전한 이벤트 시스템
interface StockEvent {
  symbol: string;
  price: number;
  changePercent: number;
}

class StockMarket implements Observable<StockEvent> {
  private observers: Set<Observer<StockEvent>> = new Set();

  subscribe(observer: Observer<StockEvent>): () => void {
    this.observers.add(observer);
    // 구독 해제 함수 반환 (React의 useEffect cleanup과 동일한 패턴)
    return () => this.observers.delete(observer);
  }

  notify(event: StockEvent): void {
    this.observers.forEach(observer => observer.update(event));
  }

  updatePrice(symbol: string, price: number, prevPrice: number): void {
    const changePercent = ((price - prevPrice) / prevPrice) * 100;
    this.notify({ symbol, price, changePercent });
  }
}

// 구체적인 옵저버들
class PriceAlertSystem implements Observer<StockEvent> {
  constructor(private readonly threshold: number) {}

  update(event: StockEvent): void {
    if (Math.abs(event.changePercent) >= this.threshold) {
      console.log(`[알림] ${event.symbol} 급변동: ${event.changePercent.toFixed(2)}%`);
    }
  }
}

class TradingBot implements Observer<StockEvent> {
  update(event: StockEvent): void {
    if (event.changePercent < -5) {
      console.log(`[봇] ${event.symbol} 하락 감지. 자동 매수 실행`);
    }
  }
}

// 사용 예시
const market = new StockMarket();
const alertSystem = new PriceAlertSystem(3); // 3% 이상 변동 시 알림
const bot = new TradingBot();

const unsubscribeAlert = market.subscribe(alertSystem);
market.subscribe(bot);

market.updatePrice('SAMSUNG', 85000, 80000); // 6.25% 상승
// [알림] SAMSUNG 급변동: 6.25%

unsubscribeAlert(); // 알림 시스템만 구독 해제
market.updatePrice('SAMSUNG', 75000, 85000); // -11.76% 하락
// [봇] SAMSUNG 하락 감지. 자동 매수 실행 (알림 시스템은 이미 해제됨)

실무 적용: 이 패턴은 React의 useState/useReducer 내부 구현, RxJS의 Observable, Node.js의 EventEmitter, 그리고 Zustand/Redux의 스토어 구독 메커니즘에서 핵심적으로 사용됩니다.

4.2 전략 패턴 (Strategy Pattern)

문제: 런타임에 알고리즘을 교체할 수 있어야 합니다. if-else나 switch로 분기하는 코드를 제거하고, 각 알고리즘을 독립적인 객체로 캡슐화합니다.

// 정렬 전략 정의
interface SortStrategy<T> {
  sort(data: T[], compareFn: (a: T, b: T) => number): T[];
}

// 다양한 정렬 전략 구현
class QuickSortStrategy<T> implements SortStrategy<T> {
  sort(data: T[], compareFn: (a: T, b: T) => number): T[] {
    const arr = [...data];
    if (arr.length <= 1) return arr;
    const pivot = arr[Math.floor(arr.length / 2)];
    const left = arr.filter(x => compareFn(x, pivot) < 0);
    const middle = arr.filter(x => compareFn(x, pivot) === 0);
    const right = arr.filter(x => compareFn(x, pivot) > 0);
    return [
      ...new QuickSortStrategy<T>().sort(left, compareFn),
      ...middle,
      ...new QuickSortStrategy<T>().sort(right, compareFn)
];
  }
}

class BubbleSortStrategy<T> implements SortStrategy<T> {
  sort(data: T[], compareFn: (a: T, b: T) => number): T[] {
    const arr = [...data];
    for (let i = 0; i < arr.length; i++) {
      for (let j = 0; j < arr.length - i - 1; j++) {
        if (compareFn(arr[j], arr[j + 1]) > 0) {
          [arr[j], arr[j + 1]] = [arr[j + 1], arr[j]];
        }
      }
    }
    return arr;
  }
}

// 컨텍스트(Context): 전략을 사용하는 클래스
class DataProcessor<T> {
  private strategy: SortStrategy<T>;

  constructor(strategy: SortStrategy<T>) {
    this.strategy = strategy;
  }

  setStrategy(strategy: SortStrategy<T>): void {
    this.strategy = strategy;
  }

  process(data: T[], compareFn: (a: T, b: T) => number): T[] {
    console.log(`${this.strategy.constructor.name} 전략 사용 중...`);
    return this.strategy.sort(data, compareFn);
  }
}

interface Product {
  name: string;
  price: number;
}

const products: Product[] = [
  { name: 'MacBook', price: 1500000 },
  { name: 'iPad', price: 800000 },
  { name: 'iPhone', price: 1200000 }
];

const processor = new DataProcessor<Product>(new QuickSortStrategy());
const sortedByPrice = processor.process(products, (a, b) => a.price - b.price);
console.log(sortedByPrice.map(p => p.name)); // ['iPad', 'iPhone', 'MacBook']

// 런타임에 전략 교체
processor.setStrategy(new BubbleSortStrategy());
const sortedByName = processor.process(products, (a, b) => a.name.localeCompare(b.name));
console.log(sortedByName.map(p => p.name)); // ['iPad', 'iPhone', 'MacBook']

전략 패턴은 SOLID 원칙 중 "단일 책임 원칙(SRP)"과 "개방/폐쇄 원칙(OCP)"을 가장 직접적으로 구현합니다. 새로운 정렬 알고리즘이 추가되어도 DataProcessor는 전혀 변경할 필요가 없습니다.

5. 합성 패턴(Composite Pattern)과 이터레이터 패턴(Iterator Pattern)

5.1 합성 패턴: 트리 구조를 우아하게

파일 시스템, 사이트 메뉴 구조, UI 컴포넌트 트리처럼 "부분-전체" 계층 구조를 표현할 때 합성 패턴이 빛을 발합니다. 단일 요소(Leaf)와 복합 요소(Composite)를 동일한 방식으로 처리할 수 있습니다.

interface FileSystemItem {
  name: string;
  getSize(): number;
  print(indent?: string): void;
}

// 단일 파일 (Leaf)
class File implements FileSystemItem {
  constructor(readonly name: string, private size: number) {}

  getSize(): number {
    return this.size;
  }

  print(indent: string = ''): void {
    console.log(`${indent}📄 ${this.name} (${this.size}KB)`);
  }
}

// 디렉토리 (Composite)
class Directory implements FileSystemItem {
  private children: FileSystemItem[] = [];

  constructor(readonly name: string) {}

  add(item: FileSystemItem): void {
    this.children.push(item);
  }

  getSize(): number {
    // 재귀적으로 하위 항목의 크기를 합산
    return this.children.reduce((sum, child) => sum + child.getSize(), 0);
  }

  print(indent: string = ''): void {
    console.log(`${indent}📁 ${this.name}/ (${this.getSize()}KB)`);
    this.children.forEach(child => child.print(indent + '  '));
  }
}

// 실용적인 예시
const root = new Directory('Project');
const src = new Directory('src');
const components = new Directory('components');

components.add(new File('Button.tsx', 4));
components.add(new File('Modal.tsx', 8));
src.add(components);
src.add(new File('App.tsx', 12));
root.add(src);
root.add(new File('package.json', 2));

root.print();
// 📁 Project/ (26KB)
//   📁 src/ (24KB)
//     📁 components/ (12KB)
//       📄 Button.tsx (4KB)
//       📄 Modal.tsx (8KB)
//     📄 App.tsx (12KB)
//   📄 package.json (2KB)

6. 실무에서 패턴을 잘 적용하는 법

6.1 패턴을 억지로 끼워 맞추지 마라

디자인 패턴은 도구입니다. 망치가 있다고 모든 것을 못으로 볼 필요는 없습니다. 패턴을 사용하기 전에 항상 스스로에게 물어보십시오: "지금 이 복잡성이 정말 필요한가?" 단순한 함수 하나로 해결될 문제를 굳이 전략 패턴으로 감쌀 이유가 없습니다. "가장 단순한 해결책"이 최고의 설계임을 잊지 마십시오.

6.2 SOLID 원칙과 함께 이해하라

디자인 패턴들은 대부분 SOLID 원칙의 구체적인 구현 방식입니다. 팩토리 패턴은 의존성 역전 원칙(DIP)을, 옵저버 패턴은 개방/폐쇄 원칙(OCP)을, 합성보다 상속을 지양하는 것은 리스코프 치환 원칙(LSP)과 연결됩니다. 패턴 뒤에 있는 "왜"를 이해할 때 진정한 응용이 가능합니다.

6.3 TypeScript의 타입 시스템을 최대한 활용하라

TypeScript를 사용할 때의 가장 큰 이점은 잘못된 패턴 사용을 컴파일 타임에 잡을 수 있다는 것입니다. 제네릭, 유니온 타입, 교차 타입, 조건부 타입 등을 활용하는 타입 안전한 패턴 구현은 런타임 오류를 획기적으로 줄여줍니다. 앞서 살펴본 팩토리 패턴에서 never 타입을 활용한 exhaustiveness check가 그 좋은 예입니다.

6.4 테스트 가능성(Testability)을 항상 고려하라

잘 적용된 디자인 패턴은 코드를 더 테스트하기 쉽게 만듭니다. 어댑터 패턴을 사용하면 외부 의존성(GA, Mixpanel)을 Mock으로 대체하기 쉽고, 전략 패턴을 사용하면 각 알고리즘을 독립적으로 단위 테스트할 수 있습니다. TDD(테스트 주도 개발)와 디자인 패턴은 서로를 강화하는 강력한 조합입니다.

결론: 패턴은 어휘, 설계는 문장

디자인 패턴에 능숙해진다는 것은 단순히 23개의 패턴 이름을 외우는 것이 아닙니다. 팀원들과 설계에 대해 이야기할 때 "여기에 옵저버 패턴을 쓰면 어떨까요?"라고 말할 수 있는, 공통된 설계 어휘를 갖게 되는 것입니다.

TypeScript로 이 패턴들을 구현해보면, 추상화와 구체화의 적절한 분리가 얼마나 코드베이스를 건강하게 만드는지 체감할 수 있습니다. 처음에는 생소하고 과한 설계처럼 느껴질 수 있습니다. 하지만 프로젝트가 성장하고 요구사항이 변화할 때, 잘 적용된 패턴은 그 코드를 마치 레고 블록처럼 손쉽게 조립하고 교체할 수 있게 해주는 진정한 가치를 발휘합니다.

오늘 소개한 패턴들을 실제 프로젝트의 코드에서 찾아보는 연습부터 시작해보세요. React 훅, NestJS 데코레이터, 상태 관리 라이브러리의 코드를 열어보면 이미 익숙한 패턴들이 곳곳에 숨어있다는 사실을 발견하게 될 것입니다. 그 순간, 여러분은 더 이상 코드를 읽는 사람이 아니라 설계를 이해하는 엔지니어가 되어 있을 것입니다.