Files
2nd/10_Wiki/Topics/Monolithic-vs-Microservices.md
T

29 lines
1.9 KiB
Markdown

---
id: [[P-Reinforce|P-Reinforce]]-AI-MONOLITHIC-MICRO
category: Dev
confidence_score: 0.99
tags: [[Architecture|[Architecture]], Microservices, Monolithic,[[_system|system]]s]
last_reinforced: 2026-04-20
---
# [[Monolithic-vs-Microservices|Monolithic-vs-Microservices]] (모놀리식 vs 마이크로서비스)
## 📌 한 줄 통찰 (The Karpathy Summary)
> "단단한 한 덩어리의 성(Castle)인가, 유기적으로 연결된 수많은 기지(Off-post)인가." 전체 서비스를 하나의 실행 단위로 묶을 것인지, 아니면 기능별로 쪼개어 네트워크로 통신하게 할 것인지에 대한 아키텍처의 거대한 양갈래 길이다.
## 📖 구조화된 지식 (Synthesized Content)
- **Monolithic (모놀리식)**:
- **Pros**: 개발이 단순하고, 통합 테스트가 쉬우며, 배포가 간편함.
- **Cons**: 하나만 고장 나도 전체 서비스 다운. 코드 베이스가 커지면 빌드 시간이 기하급수적으로 늘어남.
- **Microservices (MSA)**:
- **Pros**: 기능별 독립적인 기술 스택 사용 가능. 특정 기능만 부분적 스케일링 가능. 장애 격리 우수.
- **Cons**: 네트워크 지연 발생. 분산 데이터 무결성 보장 어려움. 인프라 구축 비용 폭증.
- **Decision Rule**: "서비스가 충분히 커서 팀 간 소통 비용이 개발 비용을 압도할 때만 MSA로 간다."
## ⚠️ 모순 및 업데이트 (RL Update)
- 최근에는 MSA의 과도한 복잡성에 실망한 기업들이 다시 모놀리식으로 돌아오는 '회귀 현상'이 있다. 하지만 단순히 과거로 가는 것이 아니라, 모놀리식의 편의성과 마이크로서비스의 명확한 경계(Bounded Context)를 결합한 **'Modular Monolith'**가 현실적인 최적 대안으로 급부상하고 있다.
## 🔗 지식 연결 (Graph)
- Related: [[Event-Driven-Architecture|Event-Driven-Architecture]] , Domain-Driven-Design
- Pattern: Saga-Pattern