Apr 16, 2026

마지막 업데이트 Apr 14, 2026

전략 패턴 가이드: 커지는 조건문 대신 바꿔 끼우는 행동으로 바꾸는 법

실제 애플리케이션에서는 “같은 종류의 작업”을 여러 방식으로 처리해야 하는 경우가 자주 생깁니다. 결제는 카드, 포인트, 계좌이체로 나뉠 수 있고, 알림은 이메일, SMS, 푸시로 나뉠 수 있으며, 할인 정책도 사용자 유형이나 캠페인에 따라 달라질 수 있습니다.

처음 구현은 보통 간단한 if 하나로 시작합니다. 그런데 규칙이 하나 더 붙고, 예외가 하나 더 붙고, 결국 서비스 하나가 분기문 벽이 되어 버립니다. 이 시점에서 전략 패턴이 꽤 현실적인 해법이 됩니다.

이 글에서는 아래 내용을 다룹니다.

전략 패턴이 실제로 무엇인지
건강한 분기와 구조를 바꿔야 하는 분기를 어떻게 구분할지
큰 조건문을 교체 가능한 전략으로 옮기는 실전 리팩터링
언제 잘 맞고 언제는 과한 추상화가 되는지

짧게 요약하면 이렇습니다. 전략 패턴은 바뀌지 않는 흐름은 그대로 두고, 자주 달라지는 행동만 별도 구현으로 빼서 깨끗하게 교체할 수 있게 해 줍니다.

전략 패턴이란 무엇인가

전략 패턴은 하나의 역할을 여러 개의 교체 가능한 구현으로 표현하는 방식입니다.

예를 들면:

결제 전략
할인 전략
배송비 계산 전략
재시도 전략

각 구현은 같은 역할을 맡지만, 실제 처리 방식은 다릅니다. 상위 로직은 구체 구현이 아니라 공통 역할에만 의존합니다.

핵심은 아래 세 가지입니다.

유스케이스의 큰 흐름은 안정적으로 두고
달라지는 행동만 인터페이스 뒤로 빼며
구현은 런타임이나 조립 단계에서 선택한다

즉 전략 패턴은 “통제된 변화”를 다루는 구조입니다.

언제 전략이 필요할까

주변 흐름은 거의 같지만, 특정 행동 하나만 계속 달라질 때 전략 패턴이 필요해집니다.

대표적인 신호는 아래와 같습니다.

서비스 하나에 if/else 또는 switch가 계속 늘어난다
새로운 행동 변형이 꾸준히 추가된다
같은 행동 계열이 코드 여러 곳에 반복된다
테스트가 한 클래스 안의 수많은 분기를 모두 커버해야 한다
설정, 사용자 유형, 환경에 따라 런타임에 행동을 골라야 한다

이 신호가 반복되면 전략 패턴이 코드를 더 읽기 좋은 모양으로 바꿔 줄 가능성이 큽니다.

문제 예시: 분기로 가득한 체크아웃 서비스

결제 흐름을 예로 들어보겠습니다.

class CheckoutService {
  checkout(amount: number, paymentMethod: string): void {
    if (paymentMethod === 'card') {
      console.log(`charge card: ${amount}`);
      return;
    }

    if (paymentMethod === 'points') {
      console.log(`deduct points: ${amount}`);
      return;
    }

    if (paymentMethod === 'bank-transfer') {
      console.log(`create transfer request: ${amount}`);
      return;
    }

    throw new Error('unsupported payment method');
  }
}

처음에는 충분히 이해 가능한 코드입니다. 문제는 실제 요구사항이 계속 붙기 시작할 때입니다.

카드는 부정 사용 검사가 필요하고
포인트는 잔액 검증이 필요하며
계좌이체는 정산 안내가 필요하고
어떤 결제수단은 특정 국가에서 막혀 있을 수 있습니다

이제 checkout 하나가 아래를 모두 떠안습니다.

결제수단 선택
결제 실행
결제수단별 검증
결제수단별 실패 처리

이 시점부터 이 메서드는 하나의 책임을 가진 흐름이 아니라, 여러 행동이 우연히 같은 자리에 모여 있는 상태가 됩니다.

리팩터링: 달라지는 행동을 전략으로 분리하기

먼저 역할을 분명하게 정의합니다.

interface PaymentStrategy {
  pay(amount: number): void;
}

class CardPayment implements PaymentStrategy {
  pay(amount: number): void {
    console.log(`charge card: ${amount}`);
  }
}

class PointsPayment implements PaymentStrategy {
  pay(amount: number): void {
    console.log(`deduct points: ${amount}`);
  }
}

class BankTransferPayment implements PaymentStrategy {
  pay(amount: number): void {
    console.log(`create transfer request: ${amount}`);
  }
}

class CheckoutService {
  constructor(private paymentStrategy: PaymentStrategy) {}

  checkout(amount: number): void {
    this.paymentStrategy.pay(amount);
  }
}

이제 책임이 훨씬 분명해집니다.

CheckoutService는 체크아웃 흐름을 맡고
각 전략은 하나의 결제 행동만 맡으며
새로운 결제수단을 추가해도 같은 메서드 안에 분기를 계속 밀어 넣지 않아도 됩니다

시스템에서 모든 의사결정이 사라지는 것은 아닙니다. 단지 변화하는 부분을 별도 객체로 빼서, 분기가 비즈니스 흐름 전체로 퍼지지 않게 만드는 것입니다.

전략은 누가 선택하나

이 질문이 실전에서 정말 중요합니다.

보통 전략은 더 상위 계층이 선택합니다.

팩토리
composition root
의존성 주입 설정
요청 데이터나 설정값을 보는 선택 로직

즉 전략을 사용하는 서비스는 보통 “어떻게 골랐는지”까지 알 필요가 없습니다. 계약만 알면 충분합니다.

예를 들면:

function createPaymentStrategy(paymentMethod: string): PaymentStrategy {
  if (paymentMethod === 'card') return new CardPayment();
  if (paymentMethod === 'points') return new PointsPayment();
  if (paymentMethod === 'bank-transfer') return new BankTransferPayment();

  throw new Error('unsupported payment method');
}

여기서 중요한 변화는, 분기 자체가 완전히 사라졌다는 점이 아닙니다. 분기를 “선택 지점” 한 곳에 모아 두고, 실제 유스케이스 로직에는 퍼뜨리지 않는다는 점입니다.

왜 그냥 if/else보다 전략이 나을까

모든 조건문이 문제는 아닙니다. 전략 패턴은 “행동의 차이”가 설계의 핵심 관심사가 될 때 빛납니다.

전략이 유리한 이유는:

각 행동을 분리해서 다룰 수 있고
테스트를 전략별로 나눠서 집중할 수 있으며
새 변형이 추가되어도 안정된 코드가 덜 흔들리고
상위 흐름이 역할 언어로 더 또렷하게 읽히기 때문입니다

즉 중요한 건 패턴 이름이 아니라, 코드가 “분기문 묶음”이 아니라 “행동 계열”을 표현하기 시작한다는 점입니다.

전략이 특히 잘 맞는 상황

전략 패턴은 아래 상황에서 강하게 맞습니다.

큰 흐름은 안정적이다
바뀌는 행동에 공통 계약이 있다
변형이 앞으로 더 늘어날 가능성이 있다
런타임 교체가 유용하다
각 변형을 별도 테스트 대상으로 두는 것이 가치 있다

그래서 아래 같은 영역에서 자주 등장합니다.

결제수단
할인 규칙
직렬화 정책
정렬 방식
알림 채널
재시도 또는 백오프 정책

언제는 과할까

전략 패턴이 오히려 과해지는 경우도 있습니다.

분기가 두 개뿐이고 아주 작으며
앞으로 바뀔 가능성이 거의 없고
추상화가 명확함보다 우회만 늘리고
교체 가능성이 실제로 가치가 없을 때

패턴은 문제의 모양이 맞을 때만 가치가 있습니다. 변화가 거의 없고 단순한 경우에는 작은 조건문이 가장 읽기 쉬운 선택일 수 있습니다.

자주 하는 실수

1. 모든 `if/else`를 전략으로 바꾸기

모든 분기가 전략이 되어야 하는 것은 아닙니다. 전략은 의미 있는 행동 변형에 쓰는 구조입니다.

2. 컨텍스트가 각 전략 세부사항을 여전히 너무 많이 아는 경우

전략 인터페이스를 만들었는데도 컨텍스트가 타입 체크나 전략별 세부 규칙을 계속 안다면, 경계가 약한 것입니다.

3. 공통 역할이 없는 억지 전략 만들기

구현들이 वास्तव상 하나의 계약 아래에 놓이지 않는데 전략처럼 꾸미면 추상화가 부자연스러워집니다.

4. 전략 선택 로직의 위치를 잊는 경우

전략 패턴은 유스케이스 내부 분기를 줄여 주지만, 선택 로직은 팩토리나 조립 계층처럼 분명한 집이 필요합니다.

도입 전에 보는 체크리스트

전략 패턴을 넣기 전에 아래를 물어보면 좋습니다.

전체 흐름은 대체로 같은데 특정 행동만 계속 바뀌는가?
앞으로 변형이 더 늘어날 가능성이 큰가?
각 변형을 따로 테스트하는 게 가치 있는가?
구체 분기 대신 역할에 의존하면 상위 코드가 더 또렷해지는가?

답이 대부분 yes라면 전략 패턴은 꽤 좋은 선택입니다.

FAQ

Q. 전략 패턴과 다형성은 같은 개념인가요?

같지는 않습니다. 전략 패턴은 하나의 공유 계약 뒤에 여러 구현을 바꿔 끼우는 구조이고, 그 과정에서 다형성을 자주 활용합니다.

Q. 전략 패턴을 쓰면 조건문이 완전히 사라지나요?

아닙니다. 보통은 선택 지점으로 옮겨집니다. 핵심은 비즈니스 흐름 전체에 분기가 퍼지지 않게 하는 것입니다.

Q. 전략과 데코레이터는 어떻게 다른가요?

전략은 행동을 다른 구현으로 교체하는 데 가깝고, 데코레이터는 같은 핵심 행동 주위에 기능 레이어를 덧씌우는 데 가깝습니다.

먼저 읽어볼 가이드

검색 유입이 많은 핵심 글부터 이어서 보세요.