실무에서 자주 쓰는 디자인 패턴 6가지

디자인 패턴. GoF 23개를 다 외울 필요는 없다. 싱글톤·전략·템플릿 메서드·팩토리·옵저버·데코레이터 — 실무에서 자주 쓰는 여섯 가지 패턴을, 스프링 코드에 이미 어떻게 녹아 있는지와 함께 정리한다.

---

들어가며

디자인 패턴을 처음 공부하면 GoF 23개를 외우려다 지친다. 그런데 정작 실무에서는 그중 손에 꼽는 몇 개를 반복해서 쓴다. 게다가 우리가 매일 쓰는 스프링 프레임워크 자체가 디자인 패턴 덩어리다. 빈(Bean), JdbcTemplate, @EventListener 같은 것들이 전부 패턴의 구현체다.

디자인 패턴은 외우는 게 아니라, 이미 쓰고 있던 것에 이름을 붙이는 일에 가깝다.

이 글에서는 실무에서 자주 만나는 여섯 가지 패턴을 골라, 어떤 문제를 푸는지와 스프링이 이걸 어디서 쓰는지를 코드와 함께 정리한다. 예시는 Java/Spring 기준이다.

---

1. 싱글톤 (Singleton) — 인스턴스는 하나면 충분하다

클래스의 인스턴스를 딱 하나만 만들어 공유하는 패턴이다. 설정 객체, 커넥션 풀, 캐시처럼 "여러 개 있을 이유가 없는" 것에 쓴다.

직접 구현하면 보통 이렇게 한다.

public class AppConfig {

    private static final AppConfig INSTANCE = new AppConfig();

    private AppConfig() {}   // 생성자를 막아 외부 생성 차단

    public static AppConfig getInstance() {
        return INSTANCE;
    }
}

생성자를 private으로 막고, 정적 인스턴스 하나만 노출한다. 어디서 getInstance()를 부르든 같은 객체가 돌아온다.

하지만 실무에서 이렇게 직접 짜는 경우는 드물다. 멀티스레드 환경에서의 초기화 문제, 테스트의 어려움 때문이다. 직접 만든 싱글톤은 상태를 공유하기 때문에 테스트 간 격리가 깨지기 쉽고, 목(mock)으로 바꿔치기도 어렵다.

스프링 어디에 있나: 사실 우리는 이미 싱글톤을 매일 쓰고 있다. 스프링 빈의 기본 스코프가 싱글톤이다. @Service, @Repository, @Component로 등록된 빈은 컨테이너당 하나만 생성돼 공유된다. 직접 getInstance()를 짜지 않아도, 스프링이 싱글톤 관리를 대신 해주는 것이다.

그래서 스프링을 쓴다면 싱글톤을 직접 구현할 일은 거의 없다. 대신 빈은 상태를 갖지 않게(stateless) 설계하는 게 중요하다. 싱글톤 빈에 가변 필드를 두면 모든 요청이 그 필드를 공유해서 동시성 버그가 생긴다.

// 위험: 싱글톤 빈에 가변 상태
@Service
public class CounterService {
    private int count = 0;   // 모든 요청이 공유 → 동시성 버그
    public void increment() { count++; }
}

싱글톤 빈은 무상태로 두고, 상태가 필요하면 메서드 파라미터나 지역 변수로 다루는 것이 원칙이다.

---

2. 전략 패턴 (Strategy) — if-else 지옥 탈출

가장 자주 쓰고, 효과도 확실한 패턴이다. 알고리즘(전략)을 인터페이스로 추상화하고, 실행 시점에 골라 쓰는 구조다.

결제 수단이 늘어나는 상황을 떠올려보자. 처음엔 if-else로 시작한다.

// 안티패턴: 결제 수단이 늘 때마다 이 메서드를 수정해야 한다
public PaymentResult pay(PaymentRequest request) {
    if (request.type() == CARD) {
        // 카드 결제 로직
    } else if (request.type() == BANK) {
        // 계좌이체 로직
    } else if (request.type() == POINT) {
        // 포인트 결제 로직
    }
    // 결제 수단 추가 = 이 코드 수정 (OCP 위반)
}

결제 수단이 추가될 때마다 이 메서드를 건드려야 한다. 개방-폐쇄 원칙(OCP) 위반이다. 전략 패턴으로 풀면 이렇게 된다.

// 전략 인터페이스
public interface PaymentProcessor {
    boolean supports(PaymentType type);
    PaymentResult process(PaymentRequest request);
}

@Component
public class CardPaymentProcessor implements PaymentProcessor {
    public boolean supports(PaymentType type) { return type == PaymentType.CARD; }
    public PaymentResult process(PaymentRequest request) {
        // 카드 결제 로직
        return PaymentResult.success();
    }
}

@Component
public class PointPaymentProcessor implements PaymentProcessor {
    public boolean supports(PaymentType type) { return type == PaymentType.POINT; }
    public PaymentResult process(PaymentRequest request) {
        // 포인트 결제 로직
        return PaymentResult.success();
    }
}

여기서 스프링의 강력함이 드러난다. 인터페이스 타입의 List로 주입받으면, 스프링이 모든 구현체를 자동으로 모아서 넣어준다.

@Service
public class PaymentService {

    private final List<PaymentProcessor> processors;  // 모든 구현체 자동 주입

    public PaymentService(List<PaymentProcessor> processors) {
        this.processors = processors;
    }

    public PaymentResult pay(PaymentRequest request) {
        return processors.stream()
                .filter(p -> p.supports(request.type()))
                .findFirst()
                .orElseThrow(() -> new UnsupportedPaymentException(request.type()))
                .process(request);
    }
}

이제 새 결제 수단은 PaymentProcessor를 구현한 @Component를 추가하기만 하면 된다. PaymentService는 한 줄도 고치지 않는다. 이게 전략 패턴 + 스프링 DI의 정석 조합이다.

---

3. 템플릿 메서드 (Template Method) — 흐름은 고정, 일부만 변경

전체 처리 흐름은 고정하되, 일부 단계만 하위 클래스가 바꾸도록 하는 패턴이다. "뼈대는 같고 속만 다른" 작업에 쓴다.

데이터를 가져와서 → 검증하고 → 저장하는 흐름이 있다고 하자. 흐름은 항상 같지만 데이터 소스(CSV, API, DB)마다 세부 구현이 다르다.

public abstract class DataImporter {

    // 템플릿 메서드: 흐름을 고정한다 (final로 오버라이드 방지)
    public final void importData(String source) {
        List<Row> raw = read(source);          // 단계 1
        List<Row> valid = validate(raw);       // 단계 2
        save(valid);                            // 단계 3
        log.info("{}건 임포트 완료", valid.size());
    }

    // 하위 클래스가 채우는 부분
    protected abstract List<Row> read(String source);
    protected abstract List<Row> validate(List<Row> rows);
    protected abstract void save(List<Row> rows);
}

public class CsvDataImporter extends DataImporter {
    protected List<Row> read(String source) { /* CSV 파싱 */ }
    protected List<Row> validate(List<Row> rows) { /* CSV 검증 */ }
    protected void save(List<Row> rows) { /* DB 저장 */ }
}

importData()의 순서는 누구도 못 바꾼다. 각 단계의 구현만 달라진다.

스프링 어디에 있나: JdbcTemplate이 대표적이다. 커넥션 얻기 → 쿼리 실행 → 결과 매핑 → 커넥션 반환이라는 흐름은 고정돼 있고, 개발자는 RowMapper로 "결과 매핑" 부분만 채운다. RestTemplate도 같은 구조다.

---

4. 팩토리 패턴 (Factory) — 객체 생성 책임 분리

객체 생성 로직을 한곳으로 모으는 패턴이다. new를 직접 쓰면 클라이언트 코드가 구체 클래스에 묶이는데, 팩토리가 그 결정을 대신한다.

public class NotificationFactory {

    public static Notification create(Channel channel) {
        return switch (channel) {
            case EMAIL -> new EmailNotification();
            case SMS   -> new SmsNotification();
            case PUSH  -> new PushNotification();
        };
    }
}

// 사용하는 쪽은 구체 클래스를 몰라도 된다
Notification noti = NotificationFactory.create(Channel.EMAIL);
noti.send("주문이 완료되었습니다");

호출하는 코드는 EmailNotification이라는 구체 타입을 몰라도 된다. 새 채널이 생기면 팩토리만 수정하면 된다.

스프링 어디에 있나: 스프링 컨테이너 자체가 거대한 팩토리다. BeanFactory라는 이름부터가 그렇다. @Bean 메서드도 팩토리 메서드 패턴의 구현이다. 우리가 new로 객체를 만들지 않고 컨테이너에서 꺼내 쓰는 것 자체가 팩토리 패턴 위에서 동작하는 것이다.

---

5. 옵저버 패턴 (Observer) — 느슨하게 연결하기

한 객체의 상태가 바뀌면, 그것을 구독하는 객체들에게 자동으로 통지하는 패턴이다. 발행자와 구독자를 느슨하게 분리한다.

주문이 생성되면 이메일 발송, 재고 차감, 통계 집계가 일어나야 한다고 하자. 이걸 OrderService에 다 욱여넣으면 결합도가 폭발한다.

// 안티패턴: OrderService가 모든 후속 작업을 직접 호출
public void createOrder(OrderRequest request) {
    Order order = orderRepository.save(...);
    emailService.sendConfirmation(order);    // 이메일과 결합
    inventoryService.decrease(order);         // 재고와 결합
    statisticsService.record(order);          // 통계와 결합
}

옵저버 패턴(스프링 이벤트)으로 풀면 발행과 처리가 분리된다.

// 이벤트 정의
public record OrderCreatedEvent(Long orderId) {}

// 발행자: 주문 생성 후 이벤트만 던진다
@Service
public class OrderService {

    private final ApplicationEventPublisher publisher;

    public void createOrder(OrderRequest request) {
        Order order = orderRepository.save(request.toEntity());
        publisher.publishEvent(new OrderCreatedEvent(order.getId()));
        // 이후 무슨 일이 일어나는지 OrderService는 모른다
    }
}

// 구독자(옵저버): 각자 알아서 반응한다
@Component
public class OrderEventHandler {

    @EventListener
    public void sendEmail(OrderCreatedEvent event) {
        // 주문 확인 이메일 발송
    }

    @EventListener
    public void decreaseInventory(OrderCreatedEvent event) {
        // 재고 차감
    }
}

OrderService는 이메일·재고·통계의 존재조차 모른다. 후속 작업을 추가하고 싶으면 @EventListener 메서드만 늘리면 된다.

스프링 어디에 있나: ApplicationEvent와 @EventListener가 옵저버 패턴 그 자체다. @TransactionalEventListener를 쓰면 트랜잭션 커밋 이후에만 옵저버가 동작하게 할 수도 있다.

---

6. 데코레이터 패턴 (Decorator) — 기능을 겹겹이 입히기

원래 객체를 그대로 두고, 같은 인터페이스로 감싸 기능을 덧붙이는 패턴이다. 상속 대신 조합으로 기능을 확장한다.

public interface Notifier {
    void send(String message);
}

// 기본 구현
public class SlackNotifier implements Notifier {
    public void send(String message) {
        // 슬랙으로 전송
    }
}

// 데코레이터: 같은 인터페이스를 구현하고, 원본을 감싼다
public class LoggingNotifier implements Notifier {

    private final Notifier delegate;

    public LoggingNotifier(Notifier delegate) {
        this.delegate = delegate;
    }

    public void send(String message) {
        log.info("전송 시작: {}", message);
        delegate.send(message);            // 원본 동작
        log.info("전송 완료");
    }
}

// 사용: 겹겹이 감싼다
Notifier notifier = new LoggingNotifier(new RetryNotifier(new SlackNotifier()));
notifier.send("배포 완료");   // 로깅 → 재시도 → 실제 전송

원본 SlackNotifier는 손대지 않고 로깅, 재시도 같은 기능을 바깥에서 입혔다.

스프링/자바 어디에 있나: 자바 I/O의 new BufferedReader(new FileReader(...))가 교과서적인 데코레이터다. 스프링에서는 AOP 프록시가 같은 원리로 동작한다. @Transactional이 붙은 빈은, 실제로는 트랜잭션 처리를 덧입힌 프록시 객체가 주입된다.

---

한눈에 정리

패턴	해결하는 문제	스프링/자바에서의 예
싱글톤 (Singleton)	인스턴스를 하나만 공유	스프링 빈 기본 스코프
전략 (Strategy)	조건마다 다른 알고리즘을 if-else 없이	List<Interface> 빈 주입
템플릿 메서드	흐름은 같고 일부 단계만 다를 때	JdbcTemplate, RestTemplate
팩토리 (Factory)	객체 생성 책임을 분리	BeanFactory, @Bean
옵저버 (Observer)	발행자-구독자를 느슨하게 연결	@EventListener
데코레이터	원본을 안 건드리고 기능 확장	AOP 프록시, @Transactional

---

마치며

디자인 패턴을 23개씩 외우는 건 큰 의미가 없다. 그보다 "지금 내가 겪는 문제가 어떤 패턴으로 풀리는가" 를 떠올릴 수 있는 게 중요하다. 결제 수단이 자꾸 늘면 전략 패턴, 후속 작업이 줄줄이 붙으면 옵저버 패턴 하는 식으로.

그리고 한 가지 더. 우리가 매일 쓰는 스프링은 이 패턴들의 거대한 전시장이다. @EventListener를 쓸 때 "아, 이게 옵저버구나" 하고 인식하는 순간, 프레임워크의 설계 의도가 보이기 시작한다. 패턴을 안다는 건 결국 남이 짜놓은 좋은 코드를 더 잘 읽게 되는 일이기도 하다.

패턴은 목적이 아니라 도구다. 패턴을 위한 패턴은 오히려 코드를 복잡하게 만든다. 문제가 먼저 보이고, 그다음에 패턴이 따라오는 순서가 맞다.

---

참고 출처

• GoF, 『Design Patterns: Elements of Reusable Object-Oriented Software』
• Spring Framework Docs: Application Events — https://docs.spring.io/spring-framework/reference/core/beans/context-introduction.html
• Refactoring Guru: Design Patterns — https://refactoring.guru/design-patterns