디자인 패턴 판단 흐름
문제 → 패턴 → 이유 → 적용
🧱 1단계: 프로젝트가 어떤 성질인지 먼저 파악하기
패턴을 결정하는 가장 중요한 기준 4가지.
✔ A. 변화가 많은가?
- API가 자주 바뀜?
- 모델 공급자(GPT, Anthropic 등) 계속 교체됨?
- UI/플랫폼 여러 개?
▶ 전략 패턴, 어댑터 패턴, 퍼사드, 팩토리 패턴이 강함
(변화의 파도를 흡수하는 패턴들)
✔ B. 복잡한 로직/도메인이 많은가?
프로젝트가:
- 복잡한 규칙
- 여러 엔터티 상호작용
- 추론/검증/상태관리
같이 복잡하면…
▶ DDD, 상태 패턴, 커맨드 패턴, 체인 오브 리스판서빌리티
도메인 복잡성을 나누는 패턴들.
✔ C. 성능, 확장성, 분산 처리 중요한가?
- 모델 스트리밍
- 이벤트 기반 시스템
- 고속 처리
▶ 옵저버, 이벤트 버스 패턴, 파이프라인 패턴, 싱글톤(캐시)
성능·대량 처리를 돕는 패턴들.
✔ D. 구성요소를 갈아끼우는 구조인가?
너처럼:
- 모델 제공자 바뀌고
- MCP 도구 연결되고
- GPU 노드 선택되고
이런 경우…
▶ 어댑터, 전략, 포트/어댑터(헥사고날), DI/IoC
다른 구현체를 쉽게 갈아끼우게 해줌.
🔍 요약하면 패턴을 선택하는 기준은 딱 4가지
항목내용대표 패턴
| 변화 | 외부 API, 정책, 구현체가 자주 바뀜 | 전략, 어댑터, 팩토리 |
| 복잡성 | 도메인/규칙이 많음 | DDD, 상태, 커맨드 |
| 성능 | 대량 이벤트·스트리밍 | 옵저버, 이벤트 버스 |
| 확장성 | 모듈 교체 필요 | 헥사고날, DI, 인터페이스 |
🧩 2단계: 프로젝트에서 문제가 되는 지점을 찾아라
디자인 패턴은 문제를 해결하기 위한 도구이기 때문에
항상 문제부터 출발해야 한다.
예를 들어:
- 모델 제공자(API)가 계속 추가/삭제되고 - 클라이언트/툴 종류가 많고 - 스트리밍 처리 복잡하고 - 상태 관리 필요
→ 이 문제를 보면
- 외부 의존성 변화 → 전략/어댑터
- 스트리밍 이벤트 → 옵저버/이벤트버스
- 모델/툴 교체 구조 → 포트/어댑터
- 로직 복잡 → DDD-lite
자연스럽게 매핑됨.
🧪 3단계: 디자인 패턴은 32개 → 실제로 자주 쓰는 건 8개만
현업에서 정말 '계속 쓰는' 패턴은 아래 8개야.
★ 핵심 GoF 패턴 (정말 자주 사용됨)
- Strategy (전략)
- Adapter (어댑터)
- Factory / Abstract Factory
- Observer (옵저버)
- Decorator
- Facade
- Command
- Singleton(캐시용)
솔직히 이 8개만 마스터하면 충분함.
나머지는 특별한 상황에서만 필요해.
🧭 4단계: 패턴 선택 체크리스트 (바로 적용 가능)
아래 질문 중 YES가 많을수록 그 패턴은 적합함.
✔ Strategy 패턴이 필요한 경우?
- 알고리즘(또는 선택 로직)을 교체해야 한다.
- 모델 공급자(GPT, Anthropic 등)가 자주 바뀐다.
- 정책이 자주 수정된다.
✔ Adapter 패턴이 필요한 경우?
- 기존 코드에 새로운 API/SDK 연결해야 한다.
- 동일한 인터페이스로 여러 구현체를 감싸야 한다.
✔ Factory 패턴이 필요한 경우?
- 객체 생성 로직이 복잡하거나 환경에 따라 달라진다.
- 여러 종류의 모델/도구를 동적으로 생성해야 한다.
✔ Observer / EventBus 패턴이 필요한 경우?
- 이벤트 기반 처리 (Tool → Hub → Client)
- 스트리밍
- 알림/상태 변경
✔ Command 패턴이 필요한 경우?
- "명령" 단위로 작업을 관리하고 싶다.
- Tool Execution, Model Call 등을 같은 형태로 다루고 싶다.
✔ Decorator 패턴이 필요한 경우?
- 기능을 동적으로 증/감하고 싶다.
- 예: 로깅, 인증, 모니터링, 캐싱
✔ Facade 패턴이 필요한 경우?
- 복잡한 것을 단순한 API로 감싸고 싶다.
- 외부에 “간단한 인터페이스”만 주고 싶다.
💡 실제로 패턴을 고르는 사고 흐름 예시
🧩 당신의 MCP Hub에 적용하면?
문제 → 패턴을 매핑해보면:
● 모델/API 여러 개 → Strategy + Adapter
● MCP Tool 여러 종류 → Adapter + Factory
● 스트리밍 이벤트 → Observer(EventBus)
● Tool 호출/Model 호출 모두 command 단위 → Command Pattern
● 복잡도 증가 → DDD-lite
● 외부와 내부 분리 → Hexagonal (Ports/Adapters)
이렇게 자연스럽게 답이 나오게 됨.
🎉 결론:
디자인 패턴 선택은
프로젝트 성질 → 문제 포인트 → 패턴의 목적
이 3개만 연결하면 끝