167. 추상 팩토리 팩토리 클래스 도출 (Abstract Factory Derivation)

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

1. 본질: 추상 팩토리 (Abstract Factory)는 연관된 객체들을 제품군 (Product Family) 단위로 생성하도록 책임을 묶어, 클라이언트가 구체 클래스에 의존하지 않게 만드는 생성 패턴이다.
2. 가치: 버튼·대화상자처럼 함께 바뀌어야 하는 객체를 하나의 팩토리로 묶으면, 플랫폼·테마·벤더 전환 시 일관성과 교체 용이성을 동시에 얻을 수 있다.
3. 판단 포인트: 변형 축이 "제품 종류"보다 "제품 계열"에 더 자주 생긴다면 추상 팩토리가 적합하고, 반대로 제품 종류 추가가 더 빈번하면 인터페이스 확장 비용을 먼저 고려해야 한다.

Ⅰ. 개요 및 필요성

추상 팩토리 (Abstract Factory)는 서로 관련된 여러 객체를 일관된 묶음으로 생성하기 위한 패턴이다. 단일 객체 생성을 숨기는 수준에서 끝나는 것이 아니라, 같은 계열에 속한 여러 제품을 함께 바꾸는 데 초점을 둔다. 그래서 이 패턴의 진짜 출발점은 "객체 하나를 어떻게 만들까"가 아니라 "서로 어울리는 객체 묶음을 어떻게 강제할까"라는 질문이다.

이 패턴이 필요한 이유는 생성 책임이 코드 곳곳에 흩어질수록 조합 불일치가 생기기 때문이다. 예를 들어 다크 테마 버튼은 선택했는데 대화상자는 라이트 테마 객체를 섞어 쓰면 사용자 경험과 테스트 결과가 모두 흔들린다. 추상 팩토리는 이런 혼합 조합을 구조적으로 막아 준다.

아래 그림은 추상 팩토리가 필요한 전형적 상황, 즉 "제품 종류"와 "제품 계열"이 동시에 존재하는 2차원 문제를 보여준다.

┌──────────────────────────────────────────────────────────────┐
│          제품 생성 문제가 2차원으로 커질 때 추상화 필요        │
├───────────────────────┬──────────────┬──────────────┬─────────┤
│ 제품 계열 (Family)    │ Button       │ Dialog       │ Menu    │
├───────────────────────┼──────────────┼──────────────┼─────────┤
│ Web Theme             │ WebButton    │ WebDialog    │ WebMenu │
│ Desktop Theme         │ WinButton    │ WinDialog    │ WinMenu │
└───────────────────────┴──────────────┴──────────────┴─────────┘

행(계열)은 Concrete Factory, 열(제품 종류)은 Abstract Product로 도출된다.

즉, 추상 팩토리 클래스 도출은 요구사항 분석의 결과다. 여러 객체가 항상 같은 계열로 함께 선택되어야 한다면, 생성 책임을 개별 생성자나 단일 팩토리 메서드로 흩어 두기보다 제품군 단위로 올려 묶어야 한다.

• 📢 섹션 요약 비유: 추상 팩토리는 교복 맞춤실과 같다. 자켓, 셔츠, 바지를 따로 고르게 하면 색이 섞일 수 있지만, 한 학교용 세트로 뽑으면 전체 복장이 자연스럽게 맞는다.

Ⅱ. 아키텍처 및 핵심 원리

추상 팩토리 구조는 크게 네 층으로 본다. 첫째, Button, Dialog 같은 추상 제품 (Abstract Product)이 있고, 둘째, 이를 구현한 구체 제품 (Concrete Product)이 있다. 셋째, 여러 추상 제품의 생성 메서드를 모아 놓은 추상 팩토리 인터페이스가 있으며, 넷째, 제품군별로 이를 구현한 구체 팩토리가 존재한다.

설계상 핵심은 "행은 계열, 열은 제품 종류"로 보는 것이다. 제품 계열이 Web, Desktop이라면 각 행이 구체 팩토리가 되고, 버튼·메뉴·대화상자 같은 열은 팩토리가 생성해야 할 메서드 목록이 된다. 이 도출 규칙을 잡아 두면 클래스 구조가 자연스럽게 정리된다.

아래 그림은 추상 팩토리의 전형적 아키텍처를 보여준다.

┌──────────────────────────────────────────────────────────────┐
│                       Client                                 │
│                 (추상 팩토리에만 의존)                       │
└───────────────────────────┬──────────────────────────────────┘
                            │
                            ▼
                ┌──────────────────────────┐
                │ AbstractFactory          │
                │ + createButton()         │
                │ + createDialog()         │
                │ + createMenu()           │
                └───────────┬──────────────┘
                            │
          ┌─────────────────┴─────────────────┐
          ▼                                   ▼
┌──────────────────────┐           ┌──────────────────────┐
│ WebFactory           │           │ DesktopFactory       │
│ → WebButton          │           │ → WinButton          │
│ → WebDialog          │           │ → WinDialog          │
│ → WebMenu            │           │ → WinMenu            │
└──────────────────────┘           └──────────────────────┘

실무에서는 여기에 의존성 주입 (Dependency Injection, DI)을 결합해 런타임에 구체 팩토리를 바꾼다. 그러면 클라이언트는 new WebButton() 같은 구체 클래스를 모르고도 전체 계열을 전환할 수 있다. 결국 추상 팩토리의 핵심 원리는 생성 책임의 묶음화와 일관성 강제다.

• 📢 섹션 요약 비유: 추상 팩토리는 같은 브랜드 부품만 공급하는 조립 라인과 같다. 어느 브랜드 라인을 선택했는지에 따라 엔진, 핸들, 계기판이 한꺼번에 그 브랜드 세트로 따라온다.

Ⅲ. 비교 및 연결

추상 팩토리는 팩토리 메서드 (Factory Method)와 함께 언급되지만, 초점이 다르다. 팩토리 메서드는 보통 하나의 제품 생성 책임을 서브클래스에 넘기는 패턴이고, 추상 팩토리는 여러 제품을 한 계열로 묶어 교체하는 데 초점을 둔다. 따라서 단일 생성 지점만 필요한 경우에는 팩토리 메서드가 충분하지만, 연관 객체 일관성이 중요해지는 순간 추상 팩토리로 확장된다.

빌더 (Builder) 패턴과도 구분해야 한다. 빌더는 복잡한 객체를 단계적으로 조립하는 데 적합하고, 추상 팩토리는 서로 다른 종류의 객체를 "같은 계열로 묶어" 생성하는 데 적합하다. 즉, 추상 팩토리는 조합의 일관성을 다루고, 빌더는 생성 절차의 복잡성을 다룬다.

결국 추상 팩토리는 생성 패턴 계열 안에서 "제품군 경계"를 가장 또렷하게 드러내는 패턴이다. 기술사 답안에서는 팩토리 메서드와의 차이, 제품군 일관성, DI 결합 포인트까지 연결해 설명해야 설득력이 생긴다.

• 📢 섹션 요약 비유: 팩토리 메서드가 한 종류 빵만 잘 굽는 제빵기라면, 추상 팩토리는 빵·음료·포장을 같은 브랜드 세트로 내보내는 세트 메뉴 주방에 가깝다.

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

실무에서 추상 팩토리를 꺼내야 하는 대표 상황은 플랫폼 전환, 테마 전환, 외부 벤더 교체다. 예를 들어 금융 시스템이 Oracle용 저장소 객체 묶음과 PostgreSQL용 저장소 객체 묶음을 모두 지원해야 한다면, Connection, Command, Transaction 계열을 한 팩토리로 묶는 설계가 유효하다. 사용자 인터페이스 (User Interface, UI) 프레임워크에서도 모바일·웹·데스크톱 위젯 세트를 분리할 때 같은 원리가 적용된다.

반대로 제품 종류가 계속 늘어나는 구조라면 신중해야 한다. createReport(), createChart(), createNotification()처럼 메서드가 계속 추가되면 모든 구체 팩토리를 함께 수정해야 하므로, 계열 추가보다 제품 추가가 잦은 시스템에서는 오히려 부담이 커진다. 즉, "무엇이 더 자주 변하는가"가 채택 판단의 핵심이다.

적용 판단 체크리스트

1. 서로 다른 객체들이 항상 같은 계열로 함께 교체되는가?
2. 클라이언트가 구체 클래스를 직접 알아서는 안 되는가?
3. 런타임 설정 또는 DI로 계열을 바꿀 필요가 있는가?
4. 제품 종류 증가보다 계열 증가 가능성이 더 큰가?

대표 안티패턴

• 제품 하나만 생성하면서 추상 팩토리를 도입해 구조만 과도하게 복잡하게 만드는 경우
• 팩토리를 써 놓고도 클라이언트 코드에서 구체 제품 타입에 다운캐스팅하는 경우
• 한 팩토리에서 생성한 제품과 다른 팩토리 제품을 뒤섞어 일관성을 깨는 경우

기술사 관점에서는 "요구사항에서 제품군 개념을 먼저 뽑아내는 능력"이 중요하다. 제품군 도출이 명확하면 추상 제품, 구체 제품, 팩토리 인터페이스, 구체 팩토리 순으로 자연스럽게 클래스 구조를 설명할 수 있다.

• 📢 섹션 요약 비유: 추상 팩토리는 호텔 객실 패키지 선택과 같다. 비즈니스형을 고르면 책상·조명·의자가 한 세트로 따라오고, 리조트형을 고르면 침대·소파·테라스 구성이 한 세트로 바뀐다.

Ⅴ. 기대효과 및 결론

추상 팩토리를 올바르게 적용하면 계열 전환 비용이 크게 줄고, 잘못된 제품 혼합을 설계 수준에서 차단할 수 있다. 테스트 코드에서는 모의 팩토리 (Mock Factory)를 주입해 UI나 저장소 계층을 손쉽게 대체할 수 있으므로 테스트 격리에도 유리하다. 또한 구체 생성 로직이 중앙화되어 변경 영향 범위를 파악하기 쉽다.

하지만 이 패턴은 공짜가 아니다. 제품 종류가 늘어날수록 팩토리 인터페이스와 구체 팩토리 구현이 함께 비대해지고, 클래스 수가 늘어 관리 복잡도가 올라간다. 그래서 추상 팩토리는 "객체 생성 추상화" 자체보다 "제품군 일관성 보장"이 정말 필요한 순간에 쓰는 것이 맞다.

결론적으로 추상 팩토리는 생성 패턴 중에서도 계열 단위 교체를 설계하는 도구로 기억하면 된다. 어떤 객체를 만들지보다, 어떤 묶음을 함께 바꿔야 하는지를 먼저 보는 관점이 핵심이다.

• 📢 섹션 요약 비유: 추상 팩토리는 옷장 하나를 통째로 계절별 세트로 바꾸는 방식이다. 여름 세트를 고르면 반팔·반바지·샌들이 함께 바뀌고, 겨울 세트를 고르면 코트·니트·부츠가 함께 따라온다.

📌 관련 개념 맵

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

생성 책임 분리 요구
    │
    ▼
정적 팩토리 · 팩토리 메서드 (Factory Method)
    │
    ▼
제품 종류 + 제품 계열의 2축 식별
    │
    ▼
추상 팩토리 (Abstract Factory)
    │
    ▼
DI (Dependency Injection) · 플러그인형 아키텍처

이 흐름도는 생성 패턴이 "단일 객체 생성 추상화"에서 출발해 "제품군 교체 가능한 구조"로 성숙하는 과정을 보여준다.

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

1. 추상 팩토리는 같은 테마 장난감을 한 상자에 넣어 주는 장난감 공장이에요.
2. 우주 테마 상자를 고르면 우주 버튼, 우주 문, 우주 메뉴가 함께 나오고, 바다 테마 상자를 고르면 바다 세트가 함께 나와요.
3. 그래서 서로 안 어울리는 장난감이 섞이지 않고, 상자만 바꾸면 분위기가 통째로 바뀌어요.