🚀 디자인 패턴 vs 아키텍처 패턴은 원래 층위가 다르다
종류예시적용 범위
| 아키텍처 패턴 | Clean, Hexagonal, MSA, Modular Monolith | “애플리케이션 전체” 구조 |
| 디자인 패턴 | Strategy, Adapter, Factory, Observer | “코드 레벨” 해결책 |
🧭 아키텍처 패턴 선택 4단계 질문
⭐ 1) 프로젝트가 얼마나 커지고 복잡해지는가?
- 팀원 많다
- 기능 많다
- 도메인 복잡하다
YES → Clean Architecture, Hexagonal, DDD
NO → 간단한 MVC / Lightweight 구조
⭐ 2) 외부 의존성이 자주 바뀌는가? (API, DB, 모델, SDK…)
- GPT 바뀜
- MCP Tool 바뀜
- DB 교체될 수 있음
- 저장소/네트워크 다양함
YES → Hexagonal Architecture(Ports & Adapters)
YES → Clean Architecture (역방향 의존성)
⭐ 3) 확장성과 유지보수가 중요한가?
- 장기 운영 서비스
- 기능이 지속 증가
- 팀 별 책임 분리 필요
YES → Clean / Modular Monolith
⭐ 4) 서비스가 분산되어야 하는가?
- 각 기능을 독립 배포
- 트래픽 편차가 크다
- 장애 격리가 중요
YES → MSA
NO → Modular Monolith 유지
📌 아키텍처 패턴 선택 기준 요약
필요 조건추천 아키텍처
| 내부/외부 의존성 변화가 많음 | Hexagonal / Clean |
| 코드 유지보수 + 명확한 책임 분리가 중요 | Clean Architecture |
| 점진적 확장이 중요 | Modular Monolith |
| 엄청 큰 서비스, 수십 팀 협업 | MSA |
| 스트리밍/이벤트 중심 | Event-driven + Hexagonal |