146. 팩터리 메서드 패턴 (Factory Method Pattern)

핵심 인사이트 (3줄 요약)

본질: 팩터리 메서드 패턴 (Factory Method Pattern)은 GoF 생성 패턴으로, 객체 생성을 서브클래스에 위임하여 클라이언트(Creator)가 구체적인 클래스를 지정하지 않고도 객체를 생성하는 패턴이다. "인스턴스를 만드는 것은 서브클래스가 결정한다"는 원칙이 핵심이다.

가치: 생성 로직을 중앙화하고 구체 클래스와의 결합도를 낮춰, 새로운 제품(Product) 타입을 추가할 때 기존 코드 수정 없이 새 서브클래스만 추가하면 되어 OCP(개방-폐쇄 원칙)를 달성한다.

판단 포인트: 팩터리 메서드 패턴은 '어떤 클래스의 인스턴스를 생성할지를 서브클래스가 결정'하는 것이 핵심이다. 단순 if-else 분기로 객체를 생성하는 경우는 팩터리 메서드가 아니며, 상속을 통한 다형적 객체 생성이 핵심 메커니즘이다.

Ⅰ. 개요 및 필요성

팩터리 메서드 패턴은 객체 생성의 책임을 클라이언트에서 분리하여 전문화된 생성자(Factory Method)에게 위임한다. 클라이언트는 '어떤 Product를 원하는지'만 알고, 구체적으로 어떤 클래스로 생성할지는 서브클래스(ConcreteCreator)가 결정한다.

실제 예: Java의 Iterator를 반환하는 Collection.iterator() 메서드는 팩터리 메서드 패턴의 대표 예시다. ArrayList.iterator()는 ArrayList의 내부 이터레이터를 반환하고, LinkedList.iterator()는 LinkedList의 내부 이터레이터를 반환한다. 클라이언트는 Collection 인터페이스를 통해 동일하게 사용한다.

┌─────────────────────────────────────────────────────────────┐
│           팩터리 메서드 패턴 구조                             │
├─────────────────────────────────────────────────────────────┤
│  Creator (추상 클래스 / 인터페이스)                          │
│  + createProduct(): Product  ← 팩터리 메서드(추상)          │
│  + someOperation(): void {                                  │
│      Product p = createProduct(); // 팩터리 메서드 호출      │
│      p.doSomething();                                       │
│  }                                                          │
│       ▲                                                     │
│  ┌────┴─────────────────────┐                               │
│  ConcreteCreatorA          ConcreteCreatorB                 │
│  + createProduct(): ProductA  + createProduct(): ProductB   │
│                                                             │
│  Product (인터페이스)                                        │
│  ← ProductA, ProductB가 구현                                │
└─────────────────────────────────────────────────────────────┘

📢 섹션 요약 비유: 피자 가게(Creator) 체인에서 각 지점(ConcreteCreator)이 자신의 레시피(Factory Method)로 피자(Product)를 만들지만, 손님(클라이언트)은 어느 지점이든 '피자 주문'이라는 동일한 방식으로 주문한다.

Ⅱ. 아키텍처 및 핵심 원리

팩터리 메서드 패턴의 4개 구성 요소: ① Product(제품): 팩터리 메서드가 생성하는 객체의 인터페이스, ② ConcreteProduct(구체 제품): Product를 구현하는 클래스, ③ Creator(생성자): 팩터리 메서드를 선언하는 추상 클래스, ④ ConcreteCreator(구체 생성자): 팩터리 메서드를 오버라이드하여 특정 Product를 생성.

항목	설명	포인트
Product	생성 객체 인터페이스	Iterator, Button, Logger
ConcreteProduct	Product 구현체	ArrayListIterator, WindowsButton
Creator	팩터리 메서드 선언	Collection, Dialog
ConcreteCreator	팩터리 메서드 구현	ArrayList, WindowsDialog

┌─────────────────────────────────────────────────────────────┐
│       팩터리 메서드 vs 추상 팩터리 메서드 차이              │
├─────────────────────────────────────────────────────────────┤
│  팩터리 메서드: 단일 제품 생성 메서드를 서브클래스에 위임   │
│  추상 팩터리: 관련 제품군 생성 인터페이스를 제공            │
│                                                             │
│  팩터리 메서드 → 상속(Inheritance) 활용                    │
│  추상 팩터리 → 구성(Composition) 활용                      │
└─────────────────────────────────────────────────────────────┘

📢 섹션 요약 비유: 출판사(Creator)가 책(Product) 제작 방식을 규정하지만, 각 편집팀(ConcreteCreator)이 자신의 방식으로 특정 책(ConcreteProduct)을 제작한다.

Ⅲ. 비교 및 연결

팩터리 메서드 패턴과 단순 팩터리(Simple Factory)의 차이를 명확히 해야 한다. 단순 팩터리는 GoF 패턴이 아니며, 단순히 if-else로 어떤 클래스를 생성할지 결정하는 유틸리티 메서드다. 팩터리 메서드는 상속을 통해 서브클래스가 생성 결정을 내린다.

비교 축	A	B
메커니즘	if-else 분기	상속·오버라이드 / 인터페이스·구성
OCP 준수	X (새 타입마다 수정)	O (새 서브클래스 추가) / O
복잡성	낮음	중간 / 높음
적용 범위	단일 클래스 내	클래스 계층 구조 / 관련 제품군

📢 섹션 요약 비유: 단순 팩터리는 한 요리사가 메뉴판(if-else)을 보고 어떤 요리를 할지 결정한다. 팩터리 메서드는 각 지점(서브클래스)이 자신만의 특제 메뉴(제품)를 만드는 방식이다.

Ⅳ. 실무 적용 및 기술사 판단

스프링에서 팩터리 메서드 패턴의 대표 예시는 @Bean 메서드다. @Configuration 클래스의 @Bean 메서드가 팩터리 메서드 역할을 하며, 스프링 컨테이너(Creator)가 이를 호출하여 Bean(Product)을 생성한다. BeanFactory와 ApplicationContext도 팩터리 메서드 패턴의 구현이다.

판단 체크리스트

객체 생성 코드가 클라이언트에서 분리되어 팩터리 메서드에 위임되는가?
새로운 제품 타입 추가 시 기존 Creator 코드 수정 없이 새 서브클래스만 추가하는가?
팩터리 메서드가 추상 메서드로 선언되어 서브클래스가 오버라이드하는가?
클라이언트가 구체 클래스 이름을 알지 못하고 인터페이스(Product)만 사용하는가?
단순 if-else 분기를 팩터리 메서드 패턴으로 오해하지 않는가?

📢 섹션 요약 비유: 레스토랑 체인의 본사(Creator)가 메뉴 기준(팩터리 메서드 명세)을 정하고, 각 지점(ConcreteCreator)이 지역 특성에 맞게 메뉴(제품)를 구현한다.

Ⅴ. 기대효과 및 결론

팩터리 메서드 패턴을 적용하면 객체 생성과 사용 코드가 분리되어 OCP를 달성하고, 새로운 제품 타입 추가가 쉬워진다. 다형성을 통해 클라이언트 코드가 구체 클래스에 의존하지 않아 결합도가 낮아진다.

한계는 새로운 ConcreteCreator 서브클래스가 많아지면 클래스 계층이 복잡해지고, 단순한 객체 생성에 과도한 복잡성이 도입될 수 있다.

미래 방향으로는 ① 함수형 프로그래밍에서 팩터리 함수로 단순화, ② DI 컨테이너가 팩터리 메서드 패턴을 프레임워크 수준에서 구현, ③ Kotlin sealed class로 타입 안전한 팩터리 구현이 발전하고 있다.

📢 섹션 요약 비유: 팩터리 메서드는 각 도시(서브클래스)가 자신의 지역 특산물(제품)을 생산하는 방식을 자율적으로 결정하지만, 유통(클라이언트)은 동일한 방식으로 수령한다.

📌 관련 개념 맵

[GoF 생성 패턴] → [팩터리 메서드 패턴] → [추상 팩터리 패턴] → [DI 컨테이너] → [스프링 @Bean 팩터리 메서드]

개념	연결 포인트
추상 팩터리 패턴	팩터리 메서드의 확장 - 관련 제품군 생성
OCP (개방-폐쇄 원칙)	팩터리 메서드로 달성하는 핵심 원칙
다형성	팩터리 메서드의 서브클래스 오버라이드 기반
스프링 BeanFactory	팩터리 메서드 패턴의 프레임워크 구현

📈 관련 키워드 및 발전 흐름도

[GoF Factory Method(1994)] → [추상 팩터리 확장] → [스프링 BeanFactory] → [DI 컨테이너 통합] → [함수형 팩터리 함수]

👶 어린이를 위한 3줄 비유 설명

팩터리 메서드는 피자 가게 체인처럼, 본사(Creator)가 피자 만드는 방법을 규정하지만 각 지점(서브클래스)이 자신만의 레시피로 피자(제품)를 만들어요.
손님(클라이언트)은 어느 지점에서나 '피자 주문'이라는 동일한 방식을 사용해요.
새 피자 종류를 추가할 때 기존 주문 시스템을 바꾸지 않아도 돼요!