607. 팩토리 메서드 vs 추상 팩토리

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

1. 본질: 팩토리(Factory) 계열 디자인 패턴은 개발자가 비즈니스 로직(결제, 배송) 한가운데에 new OracleDB() 라고 징그러운 구체 클래스 이름(구현체)을 하드코딩 때려 박아 평생 오라클의 노예(강결합)가 되는 OCP 파탄의 저주를 찢어버리는, '객체 생성(Creational) 행위'만을 전담하는 전문 하청업체(공장)를 밖으로 빼내는 극한의 은폐(캡슐화) 수술이다.
2. 가치: **팩토리 메서드(Factory Method)**가 "자식 클래스야, 네가 알아서 new 해서 껍데기(Interface)로 예쁘게 포장해다 내게 바쳐라 ㅋ"라며 객체 딱 1개의 생성 권한(제어의 역전)을 짬처리하는 1:1 기법이라면, **추상 팩토리(Abstract Factory)**는 "삼성 폰 만들 땐 삼성 공장 켜서 배터리+액정 부품 주고, 애플 폰 땐 애플 공장 켜!"라며 서로 엮여있는 여러 개의 부품 덩어리(Product Family) 군단을 한 방에 찰칵 스위칭해 주는 우주적 스케일의 테마 갈아 끼우기(Theme Switching) 치트키다.
3. 융합: 이 수동 코딩 패턴들은 훗날 자바 진영을 지배한 Spring 프레임워크의 @Autowired (IoC 컨테이너 / DI 주입) 흑마법으로 영혼이 통째로 승격 흡수되며, 현대 클라우드 네이티브 개발자들은 new 키워드 자체를 머릿속에서 삭제한 채 오직 인터페이스(껍데기)만 바라보고 100만 트래픽을 견뎌내는 100% 무결점 디커플링(Decoupling) 꿀을 빨게 된다.

Ⅰ. 개요 및 필요성 (Context & Necessity)

• 개념:

  • Factory (공장): 제품(객체)을 new 키워드로 찍어내는 역할을 전담하는 놈. 나(Client)는 공장한테 "A 제품 줘!" 텍스트만 던지고, 그게 안에서 어떻게 뚝딱뚝딱 복잡하게 조립되는지 1도 모름(캡슐화).
  • Factory Method: 부모 클래스가 껍데기만 뚫어놓고, "진짜 어떤 놈을 생성할지는 내 밑에 있는 **자식 클래스(공장장)**들이 지 맘대로 결정해서 나한테 줘 ㅋ" 라며 책임을 아래로 짬때리는 마술 (상속 템플릿 기반).
  • Abstract Factory: "야 부품 1개 찍어내는 거 말고, (운전대+바퀴+엔진) 풀세트 덩어리를 1방에 일괄로 생산하는 거대 공장 단지(공장들의 껍데기)를 만들어봐!"

• 필요성 (new 무지성 남발이 낳은 끔찍한 강결합 파국): 신입 개발자가 메인 결제 로직에 new KakaoPay() 를 천만 번 복붙해놨다. 사장님이 "내일부터 카카오페이 버리고 네이버페이 써라 ㅋ" 지시했다. 주니어는 1만 줄 파일 100개를 다 열어서 new NaverPay() 로 수작업 문자열 덮어쓰기 검색 교체(Find & Replace)를 하다가 손가락이 부러지고 오타가 나서 서버가 폭파됐다(OCP 폐쇄 원칙 박살). "아 ㅆㅂ!! 왜 객체 생성 코드를 내 비즈니스 로직(결제) 뱃속에다 쳐박았지?! 생성하는 행위(new)만 딱 '공장 텐트' 1곳으로 분리해서 짱박아뒀으면, 그냥 공장 설정 1줄만 카카오 ➡ 네이버로 바꾸면 1초 컷으로 전사 시스템 싹 다 바뀌었을 거 아냐!!" 이 생성과 사용의 처절한 분리(Separation of Use from Creation) 갈망이 팩토리를 낳았다.

• 💡 비유: 쌩 코딩(new)은 **'내가 직접 망치로 쇠를 깎고 나사를 조여서(복잡한 세팅) 자동차(객체)를 1시간 동안 낑낑대며 만들어 타는 짓'**입니다. 자동차 부품 1개 바뀌면 1시간 또 개고생이죠. 팩토리(Factory)는 **'현대자동차 대리점(공장)'**에 가는 겁니다. 딜러(Factory)한테 "그랜저 1대 줘요" 말 한마디(파라미터) 툭 던지면, 공장에서 어떻게 쇠를 깎았는지 난 1도 알 필요 없이 완벽히 세팅 완료된 차 키를 1초 만에 툭 던져줍니다. 공장 로봇(내부 조립 로직)을 지들 맘대로 100번 갈아엎어도, 나는 평생 "그랜저 줘!" 1마디로 꿀을 빠는 압도적 은폐(Hiding) 마술입니다.

• 등장 배경 및 발전 과정:

  1. 단순 Factory (Simple Factory - 구석기): if(A) new A(); else new B(); 팩토리 클래스 1개 뱃속에 if문 떡칠. 새로운 C 추가할 때마다 이 팩토리 클래스를 또 뜯어고쳐야 해서 OCP 살짝 어김.
  2. Factory Method (GoF 진화): "야 팩토리 본체도 if문 수정하지 마! 그냥 A 찍어내는 팩토리 자식, B 찍어내는 팩토리 자식 파일 10개로 찢어발겨! 확장만 치고 수정은 0으로 만들어!"
  3. Abstract Factory (거대 스케일): GUI 버튼, 스크롤, 윈도우 창 100개 세트를 맥OS 버전 ➡ 윈도우 버전으로 통째로 한 번에 찰칵 스위칭해야 하는 대규모 뷰(View) 라이브러리 엔진 개발자들의 궁극의 필요성 땜에 탄생.
  4. Spring IoC/DI (현재의 천하통일): "야 니들 팩토리 클래스 100개 파느라 파일 늘어나서 빡치지? 걍 팩토리 내가 뱃속에 하나(BeanFactory) 파둘게. 넌 걍 @Autowired 어노테이션 도장 1방 찍어. 내가 공장 돌려서 1초 만에 의존성 꽂아줌 ㅋ" 스프링 프레임워크의 압도적 대관식.

• 📢 섹션 요약 비유: 이 혁명은 **'맞춤 양복점(Factory Method)'**에서 **'대형 백화점 코디 세트(Abstract Factory)'**로의 진화입니다. 양복점(Factory Method)은 내가 상의(객체) 하나를 "여름용(A자식)으로 만들어줘, 겨울용(B자식)으로 만들어줘" 1개씩 부탁해서 완벽한 핏의 옷 하나를 뽑는 짓입니다. 백엔드 서비스 생성 1개에 딱입니다. 백화점 세트(Abstract Factory)는 마네킹에 묶인 **[모자+선글라스+신발 풀코디 세트 덩어리]**를 다루는 겁니다. "여름 테마 세트 줘!" 하면 여름용 부품 3개가 한 번에 딸려옵니다. 서로 어울리는 부품들끼리 절.대.로 삑사리 나지 않고 한 덩어리로 찰칵! 묶어주는 거대 스케일의 테마 스위칭 장비입니다.

Ⅱ. 아키텍처 및 핵심 원리 (Deep Dive)

1. 팩토리 메서드 (Factory Method) 💥 "자식아, 네가 공장장 해라"

객체를 창조하는 공장을 아예 인터페이스 뼈대로 파버리는 마술.

• 문제: PaymentService가 new CreditCard()로 결제를 한다. 카카오페이 추가하려면 코드를 갈아엎어야 한다.
• 해결 (상속 짬처리술):
  1. PaymentFactory 라는 부모 인터페이스 껍데기를 만든다. 그 안에 텅 빈 깡통 함수 createPay() 하나만 뚫어둔다.
  2. 개발자는 자식 클래스 CardFactory와 KakaoFactory 두 개를 예쁘게 만든다. 그리고 이 새끼들 뱃속에 진짜로 new CreditCard(), new KakaoPay()를 하는 더러운 조립 로직을 쑤셔 박아 가둔다 (은닉).
  3. 클라이언트(유저)는? PaymentFactory factory = new KakaoFactory(); 딱 1줄만 밖에서 세팅해 준다.
  4. 그 뒤론 평생 factory.createPay() 이 껍데기 함수만 주구장창 찌른다. 밖에서 팩토리 객체를 살짝 CardFactory로 갈아 끼워주는 순간? 메인 코드는 1바이트도 수정 0줄 치면서 카카오페이가 신용카드로 1초 컷 스위칭되는(OCP 완벽 달성) 극강의 핫스왑 쾌감이 터진다.

2. 추상 팩토리 (Abstract Factory) 👑 "부품 덩어리 풀세트 교체술"

1개가 아니라 연관된 부품 3~4개를 묶어서 '군단' 단위로 갈아 끼우는 흑마법.

• 문제 (부품 혼종의 대참사): 자동차 게임을 짠다. "현대차 엔진" 객체를 꽂았는데, 실수로 바퀴를 "페라리 바퀴" 객체로 잘못 new 했다! 달리면 자동차가 박살 난다. (부품 간 호환성 파괴 버그).

• 해결 (테마 공장 단지 세팅):

  1. CarFactory 라는 거대한 부모 껍데기(Abstract Factory)를 깐다. 그 안에 createEngine(), createTire() 2개의 텅 빈 구멍을 뚫어놓는다.
  2. HyundaiFactory 자식 클래스를 만든다. 이 놈은 무조건 "현대 엔진"과 "현대 바퀴"만 100% 묶어서(Family) 뱉어내게 강제 락(Lock) 코딩을 쳐놓는다.
  3. 클라이언트 코드는 CarFactory factory = new HyundaiFactory(); 세팅 끝.
  4. factory.createEngine(), factory.createTire() 를 연달아 호출해 부품을 받아 조립한다. **"우주가 두 쪽 나도 절대 현대 엔진과 페라리 바퀴가 한 냄비에 섞일 수 없는 100% 무결점 테마(Theme) 동기화 방어막"**이 성립된다. 다크 모드(Dark Mode) ➡ 라이트 모드(Light Mode) 버튼 하나로 UI 100개 텍스트, 배경색 통째로 갈아치우는 근본 아키텍처다.

• 📢 섹션 요약 비유: 팩토리 메서드는 **'짜장면 전문점 사장'**입니다. 손님이 주문하면 주방(자식 클래스)에서 지가 알아서 춘장 볶아서 완제품 1그릇만 툭 내옵니다. 추상 팩토리는 **'맥도날드 햄버거 세트 메뉴(해피밀) 박스'**입니다. 불고기 세트를 시키면(HyundaiFactory), 무조건 불고기 버거(엔진) + 사이다(바퀴) + 감튀(창문)가 절대 다른 게 섞이지 않고 100% 완벽한 궁합(Family)으로 한 박스에 담겨 1초 컷으로 내 눈앞에 툭 떨어지는 우주 방어 세트 패키징 기술입니다.

Ⅲ. 융합 비교 및 다각도 분석

1. 생성 패턴 3형제 최종 비교표 (Simple vs Method vs Abstract)

아키텍처 설계 면접 1순위. 이 3개의 미묘한 가중치 차이를 논해야 100점이다.

과목 융합 관점

• 소프트웨어 공학 (DIP 의존성 역전 원칙의 최종 완성, 601장 연계): 601장에서 DIP(추상화 껍데기에만 의존해라) 헌법을 말했다. 근데 껍데기에만 의존하면, 도대체 진짜 알맹이 객체(오라클 DB)는 우주 공간 어디서 누가 낳아준단 말인가?! 그 구멍을 채워주는 톱니바퀴가 팩토리 패턴이다. 비즈니스 코드(Client)는 오직 DB_Interface 껍데기만 쳐다보고 꿀을 빤다. 객체 생성이라는 더럽고 끔찍한 구체 클래스 new OracleDB() 하드코딩 똥 치우기 십자가는 철저하게 팩토리(Factory) 공장 놈 하나한테 짬처리 쳐버린다(Separation). 팩토리가 총알받이가 되어 구체(Concrete) 클래스들의 모든 악취를 자기 뱃속에 가둬버렸기에, 나머지 99%의 비즈니스 코드가 DIP의 순백색 무결점을 평생 유지할 수 있는 기적이 성립된다.

• 클라우드 스프링 프레임워크 (IoC Container / @Bean 흑마법 흡수): 아키텍처의 비애. 자바 개발자들이 팩토리 패턴 짠다고 클래스 파일 10개 파대며 쌩쇼 하다가 폭동이 일어났다. "야 ㅆㅂ 이 더러운 공장 짓 걍 인프라가 1큐에 대신 쳐주면 안 돼?!" 스프링(Spring)의 BeanFactory / ApplicationContext 가 등장하며 이 23가지 디자인 패턴 생태계를 도끼로 부숴버렸다. 개발자는 더 이상 팩토리 클래스를 쌩으로 안 판다. 걍 코드 위에 @Configuration 이랑 @Bean 딱지 딱 2개 붙인다. 스프링 서버 켜지는 0.1초 찰나에! 거대 괴물 팩토리(스프링 컨테이너 봇)가 지 스스로 허공에서 객체 수만 개 쾅쾅 찍어내고(Factory Method 대행), 필요한 놈들 뱃속에 @Autowired 주사기로 푹푹! 꽂아 넣어주는(DI 주입) 100% 무인 팩토리 렌더링 시대가 천하 통일했다. 수동 코딩 패턴은 죽었고 사상(Philosophy)만 프레임워크 바닥에 화석으로 남았다.

• 📢 섹션 요약 비유: 옛날 수동 팩토리 코딩은 **'내가 직접 도면 그리고 나무 깎아서 내 방에 꼭 맞는 수제 서랍장(객체)을 1달 내내 낑낑대며 만드는 짓'**이었습니다. 팩토리를 썼으니 일단 깨끗하긴 하죠. 스프링(Spring) IoC 컨테이너는 **'이케아(IKEA) 카탈로그 자동 배송 봇'**입니다. 나는 그냥 카탈로그에 "하얀색 3단 서랍장 필요해(@Bean)" 텍스트로 체크만 띡! 해두고 꿀잠 잡니다. 아침에 눈 떠보면 내 방 구석구석에 완벽하게 조립된 100개의 가구(객체)들이 1mm 오차도 없이(주입) 착착 놓여 있는 0초 컷 무적의 오토-공장 시스템입니다.

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

실무 시나리오

1. 시나리오 — 'New 하드코딩'이 부른 100만 줄 리팩토링의 대학살 (OCP/DIP 붕괴 파국): 쇼핑몰 개발팀. new MySQL_Driver()를 컨트롤러 100개, 서비스 파일 1,000개, 유틸 파일 5,000개 도합 1만 줄에 무지성으로 쳐발라 놨다. 3년 뒤 트래픽이 터져서 사장님이 "야 당장 내일 새벽에 PostgreSQL(AWS RDS)로 DB 이사해 ㅋ" 명령했다. 개발팀 전원이 1만 개의 파일을 켜서 눈알 빠지게 MySQL 글자를 PostgreSQL로 텍스트 치환(Find & Replace) 치다가, 파일 2개를 까먹고 안 고쳤다. 새벽에 오픈하자마자 그 2개 파일에서 옛날 MySQL 서버로 쿼리 쏘다 500 타임아웃 쳐맞고 결제 서버 하얗게 셧다운! 회사 멸망 엔딩.

   • 아키텍트의 해결책: 의존성 캡슐화 팩토리(Factory Method)의 1점 타격 핫스왑 수술이다. 만약 이 회사가 3년 전에 DBFactory.getDriver() 라는 공장 껍데기 1개로 생성 코드를 뽑아냈다면? 아키텍트 한 명이 DBFactory.java 파일 딱 1개 연다. 그 안에 있던 return new MySQL_Driver() 딱 1줄을 지우고, return new PostgreSQL_Driver() 1줄 텍스트만 고치고(10초 컷) 저장 쾅! 엔터 친다. 다음날 아침, 1만 개의 전사 자바 파일들은 지들이 찌르는 DB가 MySQL에서 포스트그레로 바뀌었는지 1비트도 눈치채지 못한 채(투명성), 공장이 던져주는 새 무기만 무지성으로 받아 쓰며 100% 무결점 DB 마이그레이션이 단 1개의 버그도 없이 평화롭게 완료되는 기적의 OCP 방파제다.

2. 시나리오 — '추상 팩토리(Abstract Factory) 남용'이 부른 클래스 폭발 지옥 (Over-Engineering): 신입 아키텍트가 GoF 패턴 뽕에 취했다. 달력 앱을 짰는데, [다크 모드 / 라이트 모드] 스위칭을 추상 팩토리로 짰다. ThemeFactory 껍데기 밑에 DarkFactory, LightFactory 자식 파고, 그 밑에 DarkButton, LightButton, DarkScroll... 고작 버튼 3개 테마 바꾸겠다고 자바 클래스 파일(껍데기+구현체)을 15개나 파서 폴더를 개판 쓰레기장으로 만들었다. 내일 사장님이 "야 크리스마스 레드 모드 하나 추가해 ㅋ" 했다. 신입 개발자는 또 RedFactory, RedButton 파일 5개를 새로 만들다 파일 20개의 미로 속에서 자기가 어디 있는지 길을 잃고 눈물 흘리다 퇴사했다.

   • 아키텍트의 해결책: YAGNI 컷오프와 단순화(DI / Parameterization) 타협이다. 추상 팩토리는 테마(UI 툴킷) 전체를 갈아 끼우는 거대 스케일에서만 쓰는 극강의 무거운 도끼다! 색깔 몇 개 바꾼다고 클래스를 파는 건 정신병이다. 아키텍트는 15개 껍데기 파일을 당장 도끼로 삭제해 버린다!! 걍 Button 클래스 딱 1개만 냅둬라! 그리고 팩토리 1곳에서 new Button(Color.RED) 처럼 걍 파라미터 변수(Value) 값 하나로 주입(Inject) 쳐서 1줄 컷으로 떼워라!! 로직(알고리즘)이 아예 갈아엎어질 때만 클래스 상속(팩토리)을 치는 거지, 단순한 속성(Color) 쪼가리 바꿀 때 클래스 찍어내는 건 기술 부채 1순위 자살 똥볼이다.

도입 체크리스트

• 조직적: "이 프로젝트에 투입된 주니어 개발자들이 '추상화(Abstraction)'의 두꺼운 이불 덮기를 감당할 구조적 문해력(Literacy)이 있는가?" 팩토리 패턴 떡칠하면 OCP는 무적이지만, 주니어들 뇌는 터진다. "아 ㅆㅂ 결제 버튼 누르면 진짜 어떤 코드가 도는지 보려고 Ctrl + Click 10번 타고 들어갔는데, 계속 Interface 빈 껍데기 파일만 나오고 진짜 알맹이(Impl) 코드가 어느 폴더에 짱박혔는지 평생 못 찾겠어 ㅠㅠ!!" (추상화의 비극 미로 지옥). 아키텍트는 팩토리 패턴을 코어(Core) 도메인 딱 1곳에만 바르고, 팀원들에게 IDE 플러그인(UML 렌더러) 강제 세팅 및 사내 세미나 1주일 빡세게 안 굴리면 결국 유지보수 하다 "걍 팩토리 찢어버리고 생코딩 칠게요" 쿠데타가 일어난다.
• 기술적: "단순 팩토리(if문 떡칠)로 대충 1달 런칭 꿀 빨다 버릴 단타성(MVP) 기능인가, 3년 이상 확장(Scale)될 조짐이 보이는 메가 코어 뼈대인가?" 카카오 로그인, 구글 로그인 딱 2개만 붙이고 끝날 회사 사내 쩌리 게시판 앱이다? if(kakao) new Kakao() 치고 걍 퇴근해라. 팩토리 메서드 껍데기 파는 시간 인건비가 더 비싸다. 하지만, 이커머스 본진 결제 모듈이라 내년 안에 페이팔, 토스, 네이버페이 10개 붙을 게 1만% 확정된 시한폭탄 도메인이다? 지금 당장 팩토리 공장과 전략(Strategy) 패턴 안 발라두면, 1년 뒤 수천 줄의 if-else 거미줄이 결제 서버 스레드를 휘감아 목을 조르며 트래픽 1만 터질 때 OOM 파멸 엔딩을 맞이하게 될 절대 방어 헌법 구역이다.

안티패턴

• "정적(Static) 팩토리 메서드의 무지성 남용으로 객체 지향의 유연성(Mocking) 숨통 끊어버리기": 주니어가 팩토리 파기 귀찮으니까 걍 클래스 안에 public static User create() { return new User(); } 스태틱(Static) 함수 하나 박아놓고 전사에서 1만 번 호출하며 "나 팩토리 씀 ㅋ" 깝쳤다. 1달 뒤 젠킨스 테스트(TDD) 봇을 돌렸다. 테스트 봇이 에러 뿜으며 뻗었다!! 왜?! 자바에서 Static 은 우주가 2쪽 나도 메모리에 시멘트로 굳어버린 철근이다! 나중에 테스트할 때 저 create() 뱃속을 가짜 더미 객체(Mock)로 스위칭(갈아 끼우기) 하려 해도, 다형성(오버라이딩)이 원천 봉쇄(차단)되어 있어 죽었다 깨어나도 조작할 수가 없는 최악의 강결합 테러를 낳았다. "명심해라! 팩토리(Factory)의 본질은 다형성(Interface)을 타서 런타임에 껍데기를 휙휙 갈아 끼우는 부드러운 젤리 같은 마술에 있다. Static 으로 팩토리를 굳혀버리는 건 OCP(확장)의 심장에 대못을 박아버리는 멍청한 짓이다. 팩토리도 무조건 '객체(Bean)'로 띄워서 인터페이스로 찔러라."

• 📢 섹션 요약 비유: Static 팩토리는 **'편의점 앞 천원짜리 플라스틱 뽑기 기계(고정 머신)'**와 같습니다. 동전 넣으면 무조건 그 플라스틱 캡슐 1종류만 튀어나옵니다(수정 불가 강결합). 테스트할 때 가짜 캡슐을 나오게 튜닝하고 싶어도 기계 자체가 시멘트라 불가능하죠. 인터페이스 팩토리는 **'최고급 3D 프린터(다형성 머신)'**입니다. 평소엔 컵(진짜 객체)을 찍어내다가, 테스터(개발자)가 USB 도면(Mock 설정) 하나 띡! 갈아 끼우면? 1초 만에 컵 대신 칼(가짜 객체)을 찍어내 주는 유연성 10,000%의 런타임 스위칭 예술입니다.

Ⅴ. 기대효과 및 결론

정량/정성 기대효과

미래 전망

• Spring Boot AutoConfiguration (무적의 No-Code 인프라 팩토리): 개발자가 Factory 클래스 파고 인터페이스 뚫는 짓조차 낡은 시대가 되었다. 2026년 스프링 부트(Spring Boot 3.x)의 흑마법. 개발자는 그냥 .jar 파일(라이브러리) 하나만 pom.xml에 다운받아 놓는다. 스프링 부트가 켜지는 0.1초 찰나! 뱃속의 AutoConfiguration 요원(인프라 팩토리)이 클래스 경로를 미친 듯이 스캔한다. "어? 카카오페이 라이브러리가 폴더에 툭 떨어져 있네? 야! 인간(개발자)한테 물어보지도 말고, 지가 알아서 KakaoPayFactory 메모리에 띄우고 빈(Bean)으로 주입 때려버려!!" 개발자 소스코드에 new 도 없고 Factory 단어 1글자도 없는데, 인프라 엔진 스스로 부품 유무를 감지해 허공에서 공장을 짓고 찍어내어 꽂아버리는 궁극의 제로 터치(Zero-touch Provisioning) 우주가 K8s 프레임워크 씬을 천하 통일했다.
• 의존성 주입(DI)의 클라우드 스케일 팽창 (Service Mesh 545장 연계): 객체 new를 피하는 팩토리 사상은 자바 메모리(RAM)를 뚫고 네트워크 허공으로 승격했다. A 파드(서버)가 B 파드를 부를 때, A 코드에 call("10.1.1.2") IP 주소를 생코딩으로 박으면? 이건 new 치는 거랑 100% 똑같은 네트워크 강결합 폭파 지옥이다. 이스트오(Istio Envoy)가 거대 팩토리 껍데기로 참전한다. A 코드는 무지성 껍데기 문자열 call("payment-service") 1개만 부른다. 밖에서 Envoy 프록시가 그 허공의 외침을 낚아채서 "아 V1 파드 띄워줄게, 아니 V2 파드로 꺾어서 꽂아줄게 ㅋ" 라며 네트워크 호출(Routing) 대상을 런타임에 0.1초 컷 스위칭 꽂아버리는 클라우드 레벨 메타-팩토리 패러다임이 무정지 MSA 찢기 아키텍처의 목줄을 쥐고 흔들고 있다.

참고 표준

• GoF (Gang of Four) Creational Patterns: 1994년, "객체를 낳는 더러운 고통(new)을 비즈니스 로직에 묻히지 마라!"고 외치며, 팩토리, 빌더, 싱글톤이라는 '생성 5대 족보'를 세상에 뿌려 수천만 자바 개발자의 코드를 쓰레기통에서 건져낸 성경 바이블의 심장 챕터.
• Dependency Injection (Martin Fowler): 팩토리 패턴 떡칠하다 빡친 마틴 파울러가 "야 그냥 공장(Factory) 부르는 짓조차 하지 마! 밖(Spring)에서 걍 알아서 꽂아주게(Inject) 수동적으로 멍때리고 꿀만 빨아!"라며 팩토리 패턴을 프레임워크 인프라 뱃속으로 우아하게 사장(Deprecate)시켜버린 제어 역전(IoC)의 대헌장.

팩토리 메서드 vs 추상 팩토리는 소프트웨어 공학이 도달한 **'무언가를 창조(Creation)한다는 가장 물리적이고 더러운 잉태의 고통(new)을 철저히 은폐하고 외주화(Offloading)시켜, 나의 핵심 비즈니스 뇌(Core Logic)를 티끌 하나 묻지 않은 순백의 불멸(Immutable) 상태로 영원히 박제해 낸 극단의 객체지향 결벽증'**이다. 과거 우리는 기능이 필요할 때마다 new 키워드의 칼날을 들어 직접 살과 뼈를 깎아 객체를 빚어냈다. 그 결과, 오라클 DB라는 족쇄(강결합)가 내 심장 코드에 콘크리트처럼 엉겨 붙었고, 데이터베이스를 바꾸라는 지시 한 번에 1만 줄의 심장을 칼로 찢고 수술하다 과다 출혈로 셧다운(서버 폭파)이라는 묘비를 세웠다. 아키텍트는 뼈를 깎는 결단을 내린다. 나는 아무것도 낳지 않겠다. 나는 오직 "결제를 해라"는 빈 껍데기(Interface)의 명령만을 쥘 뿐이다. 지저분한 객체 찰흙을 조물딱거려 빚어내는 피와 땀은 저기 구석에 짱박아둔 팩토리(공장) 놈 한 명에게 모든 권력과 책임을 떠넘겨(Delegation) 가둬버려라. 카카오페이를 버리고 네이버페이로 100만 유저의 트래픽을 갈아 치우는 그 피 튀기는 찰나의 순간에도, 나의 메인 로직 1만 줄은 단 1비트의 미동조차 눈치채지 못한 채(Transparency) 그저 공장이 0.1초 만에 새로 툭 던져준 따끈한 새 무기를 멍청하게 쥐고 적을 썰어댈 뿐이다. 변화(Change)라는 거대한 폭풍을 오직 팩토리 텐트 1곳에만 가두어 태워버리는 이 완벽한 방파제. 그것이야말로 세상의 모든 요구사항(Requirement) 변덕에도 흔들림 없이 100년의 유지보수(OCP)를 버텨내는 클라우드 시대 아키텍트들의 가장 이기적이고 완벽한 방패막(Shield)이다.

• 📢 섹션 요약 비유: 쌩 코딩 new 떡칠은 **'전장의 군인(비즈니스 로직)이 총 쏘다 총알 떨어지면, 자기가 쭈그려 앉아 화약 넣고 탄피 만들고(new 조립) 다시 총 쏘느라 적한테 총 맞아 죽는 멍청한 짓'**입니다. 팩토리 아키텍처는 **'탄약고 공장(Factory)'**을 완벽히 찢어 분리한 겁니다. 군인은 총알을 1도 만들지 않습니다! "총알 줘!"(파라미터 호출) 소리만 지르면, 공장에서 1초 컷으로 조립 쫙 끝낸 철갑탄이 군인 손에 툭 떨어집니다. 군인은 눈 감고 장전해서 쏘기만 하면(꿀 빨기) 적진을 박살 내는 10,000% 무적의 전투 분업(Decoupling) 콤비네이션입니다.

📌 관련 개념 맵 (Knowledge Graph)

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

1. 내가 레고 자동차(프로그램)를 조종하는데, 바퀴가 고장 났을 때마다 내가 플라스틱을 직접 녹여 바퀴를 1시간 동안 낑낑대며 다시 만들려니까(new 쌩 코딩) 손가락 아프고 게임 다 졌어요 ㅠㅠ.
2. 그래서 옆에 **'만능 뚝딱 공장 장난감 상자(팩토리 패턴)'**를 하나 놔뒀어요! 나는 아무것도 안 만들고 상자한테 "튼튼한 바퀴 하나 줘!" 말(호출)만 툭 던졌어요.
3. 상자 뱃속에서 0.1초 만에 찰칵찰칵 조립되더니 완벽한 짱 멋진 바퀴 1개가 내 손에 뚝 떨어져요! 나는 장난감 만드는 귀찮은 짓은 박스한테 다 짬처리(팩토리 공장)하고, 짱 빠르게 받아 쓰며 놀기만 하는 치트키 마법을 '팩토리 패턴'이라고 부른답니다!