디자인 패턴 개요 (GoF Design Patterns)

디자인 패턴(Design Pattern)은 소프트웨어 설계에서 반복적으로 나타나는 문제에 대해 검증된 해결 구조에 이름을 붙여 정리한 것이다. 1994년 GoF(Gang of Four)라 불리는 네 명의 저자가 23개 패턴을 생성, 구조, 행위의 세 범주로 분류해 정리했고, 이 분류는 지금까지도 객체지향 설계 논의의 공통 어휘로 쓰인다. 디자인 패턴을 익히면 설계 의도를 짧은 이름 하나로 정확하게 소통할 수 있다.

디자인 패턴이란 무엇인가

디자인 패턴은 복사해서 붙여 넣는 완성된 코드가 아니라, 특정 상황에서 객체들의 책임과 협력 관계를 어떻게 배치할지에 대한 설계 청사진이다. 같은 패턴이라도 언어와 도메인에 따라 구현은 달라진다. 패턴의 진짜 가치는 두 가지다. 첫째, 수많은 개발자가 이미 겪은 시행착오를 압축한 검증된 구조를 제공한다. 둘째, "여기는 전략 패턴으로 풀었다"처럼 긴 설명을 한 단어로 대체하는 공통 언어가 된다. 코드 리뷰와 아키텍처 논의에서 이 어휘의 힘은 생각보다 크다.

대부분의 패턴은 몇 가지 공통 원리 위에 서 있다. 구현이 아닌 인터페이스에 의존하기, 상속보다 합성을 선호하기, 변하는 부분과 변하지 않는 부분을 분리해 캡슐화하기가 그것이다. 개별 패턴을 외우는 것보다 이 원리를 이해하는 것이 먼저다.

GoF의 세 가지 분류

GoF는 패턴의 목적에 따라 23개 패턴을 세 범주로 나눈다. 생성 패턴은 객체를 만드는 과정을, 구조 패턴은 객체를 조립하는 방법을, 행위 패턴은 객체 사이의 책임 분배와 소통 방식을 다룬다.

분류	초점	소속 패턴
생성(Creational) 5개	객체 생성 과정을 캡슐화해 유연하게 만든다	싱글톤, 팩토리 메서드, 추상 팩토리, 빌더, 프로토타입
구조(Structural) 7개	클래스와 객체를 조합해 더 큰 구조를 만든다	어댑터, 브리지, 컴포지트, 데코레이터, 퍼사드, 플라이웨이트, 프록시
행위(Behavioral) 11개	객체 간 상호작용과 책임 분배를 정의한다	전략, 옵저버, 템플릿 메서드, 커맨드, 상태, 이터레이터, 중재자, 메멘토, 비지터, 책임 연쇄, 인터프리터

또 하나의 축은 적용 범위다. 상속 관계로 고정되는 클래스 패턴(템플릿 메서드, 팩토리 메서드 등)과 런타임에 합성으로 관계를 바꿀 수 있는 객체 패턴(전략, 데코레이터 등)으로도 나눌 수 있다. 객체 패턴이 더 유연하기 때문에 GoF 패턴의 다수가 합성 기반이다. 세 분류를 기억하는 요령은 질문 형태로 바꾸는 것이다. "이 객체를 어떻게 만들 것인가"가 문제면 생성, "이 객체들을 어떻게 엮을 것인가"가 문제면 구조, "이 객체들이 어떻게 협력하고 책임을 나눌 것인가"가 문제면 행위 패턴이다.

코드로 보는 패턴의 효과

분류를 외우는 것보다 패턴이 코드를 어떻게 바꾸는지 감각을 잡는 것이 중요하다. 할인 정책이 계속 늘어나는 상황을 전략 패턴(Strategy Pattern)으로 정리한 짧은 예를 보자.

// 변하는 부분(할인 계산)을 인터페이스로 분리
public interface DiscountPolicy {
    int apply(int price);
}

public class FixedDiscount implements DiscountPolicy {
    public int apply(int price) { return price - 1000; }
}

public class RateDiscount implements DiscountPolicy {
    public int apply(int price) { return (int) (price * 0.9); }
}

// 변하지 않는 부분(주문 처리)은 인터페이스에만 의존
public class Order {
    private final DiscountPolicy policy;

    public Order(DiscountPolicy policy) { this.policy = policy; }

    public int totalPrice(int price) {
        return policy.apply(price);
    }
}

새 할인 정책이 생겨도 Order는 수정되지 않고 구현 클래스만 추가된다. "변하는 것을 캡슐화하고 인터페이스에 의존한다"는 원리가 조건문 분기를 타입 확장으로 바꾼 것이다. 다른 패턴들도 결국 이 원리를 각자의 문제 상황에 맞게 변주한 것으로 볼 수 있다.