숏컷 코드
spawn 요청
-> factory가 타입 결정
-> 필요한 prefab / 설정 / 초기화 적용
-> 호출부는 "무엇을 만들지"만 안다문법과 예시
생성 규칙이 호출부마다 흩어지면 초기화 누락이 반복된다
적 생성, 투사체 생성, 보상 생성이 코드 곳곳에서 직접 일어나면 매번 Instantiate, 위치 설정, 팀 설정, 스탯 주입, 이벤트 연결을
같이 적게 됩니다. 문제는 생성 규칙이 한 곳에 모이지 않아서 새 필드가 생길 때 호출부마다 초기화를 고쳐야 한다는 점입니다.
팩토리 패턴은 "어떤 것을 만들지"와 "어떻게 초기화할지"를 분리해, 생성 규칙을 한 곳으로 끌어옵니다.
// 호출부에서 직접 생성
var enemy = Instantiate(prefab);
enemy.Team = enemyTeam;
enemy.Stats = stats;
enemy.SetPatrol(path);
// factory로 생성
var enemy = enemyFactory.Spawn("patrol-guard", spawnPoint);팩토리의 핵심은 new를 숨기는 것이 아니라 생성 정책을 고정하는 것이다
팩토리는 단순히 new나 Instantiate를 감추는 래퍼가 아닙니다. 진짜 목적은 "이 타입은 어떤 prefab과 어떤 설정으로 태어나야 하는가"를
정책으로 고정하는 데 있습니다. 같은 Enemy라도 stage, biome, difficulty에 따라 다른 초기화가 필요하다면, 그 판단을 호출부가
알 필요는 없습니다. 호출부는 생성 요청만 하고, 팩토리가 적절한 조합을 결정하는 편이 더 오래 갑니다.
factory가 정하는 것
- 어떤 prefab을 쓸지
- 어떤 ScriptableObject 설정을 넣을지
- 어떤 풀이나 spawn parent를 쓸지
- 생성 직후 어떤 초기화 루틴을 돌릴지prefab 직참조로 충분한 상황과 factory가 필요한 상황은 다르다
모든 생성에 factory가 필요한 것은 아닙니다. 씬 안에서 버튼 하나가 같은 팝업 하나만 띄우는 정도라면 direct reference가 더 단순합니다. 반대로 적 종류가 늘어나고, 생성 위치와 초기화 규칙이 상황마다 달라지며, 나중에 풀링이나 Addressables 같은 로딩 방식까지 바뀔 수 있다면 factory가 유리합니다. 판단 기준은 "호출부가 생성 규칙을 몇 가지나 알아야 하는가"입니다.
Unity에서는 factory와 pool을 함께 두는 경우가 많다
Unity에서는 생성 정책과 재사용 정책이 함께 움직입니다. 투사체를 Instantiate할지, 풀에서 재사용할지, Addressables로 로드할지는
호출부보다 factory가 알도록 두는 편이 자연스럽습니다. 이렇게 하면 나중에 생성 구현을 바꿔도 gameplay 코드는 그대로 둘 수 있습니다.
장점은 확장성과 초기화 캡슐화, 단점은 클래스 수 증가다
팩토리 패턴의 장점은 명확합니다. 새 제품 타입을 추가할 때 기존 호출부를 거의 건드리지 않아도 되고, 각 제품의 고유 초기화 로직을 제품 쪽으로 밀어 넣을 수 있어 공장 코드를 짧게 유지할 수 있습니다. 반대로 단점도 분명합니다. 인터페이스, 추상 공장, 구상 공장, 제품 클래스가 늘어나므로 "제품 종류가 많지 않은데도 구조만 무거워지는" 오버헤드가 생길 수 있습니다. 패턴이 맞는 시점은 클래스 수보다 생성 규칙 변화 비용이 더 클 때입니다.
개선 포인트는 검색 방식과 생성 소스를 늦게 고정하는 것이다
팩토리를 더 실무적으로 쓰려면 딕셔너리 기반 lookup, 정적 공장 관리자, 비-MonoBehaviour 생성, 오브젝트 풀 결합까지 함께 고려할 수 있습니다. RefDock 기준으로 정리하면 "생성 요청 키를 어떻게 식별할지"와 "반드시 새로 만들지, 기존 자원을 재사용할지"를 factory 경계에서 늦게 결정하라는 뜻입니다. 이 점을 열어 두면 prefab 생성, pool 재사용, Addressables 로드가 같은 API 뒤에 숨을 수 있습니다.
팩토리를 쓸 때 핵심
| 상황 | 적합한 선택 |
|---|---|
| 생성 규칙이 한두 군데에만 있고 단순할 때 | direct reference 또는 단순 helper |
| 적, 아이템, 보상처럼 종류와 초기화가 늘어날 때 | factory 도입 |
| prefab, 설정, spawn parent를 함께 결정해야 할 때 | factory에 생성 정책 집중 |
| 나중에 pool / Addressables로 바뀔 가능성이 클 때 | 호출부가 아니라 factory 경계에서 바꾸기 |
| 호출부가 생성 후 필드 세팅을 계속 반복할 때 | 생성 후 초기화까지 factory로 흡수 |
| 타입 추가보다 생성 규칙 변경이 더 자주 일어날 때 | enum/switch 호출부보다 factory 유지 |
| 제품 종류가 많지 않고 생성도 단순할 때 | factory보다 direct reference가 더 단순 |
특이 케이스와 주의할 점
흔한 실패는 Instantiate만 factory 안으로 옮기고, 실제 초기화 규칙은 여전히 호출부에 남기는 것입니다.
이렇게 되면 클래스 이름만 factory일 뿐 생성 경계는 정리되지 않습니다. 생성 직후 반드시 맞아야 하는 상태를 어디까지
factory 책임으로 둘지 먼저 정해 두세요. 또 제품 종류가 거의 없는데도 추상 공장과 인터페이스만 늘리면,
패턴의 이점보다 클래스 관리 비용이 더 커질 수 있습니다.
실패 예시
- EnemyFactory는 prefab만 만들고
- Team, Stats, PatrolPath, TargetLayer는 호출부마다 따로 세팅
결과
- 적 타입이 늘수록 호출부마다 초기화 누락이 생김
- 생성 규칙이 한 곳에 모이지 않음참고 링크
1 sources