Master Reference
전체 커리큘럼의 학습 원칙, Architecture Selection Matrix, Mental Model을 모아둔 참조 문서입니다. 개별 레슨을 학습하기 전후로 확인하세요.
0. 최종 학습 목표
"요구사항과 제약조건만 보고 시스템의 구조를 설계하고, 왜 그 구조를 선택했는지 설명하며, 트래픽 증가와 장애 상황까지 예측할 수 있는 능력"을 기르는 것이 이 커리큘럼의 목표다.
- 요청이 클라이언트에서 서버까지 어떻게 이동하는지 설명할 수 있다.
- 애플리케이션 내부에서 요청이 어떻게 처리되는지 설명할 수 있다.
- DB에서 SQL/Query가 실제로 어떻게 처리되는지 설명할 수 있다.
- 데이터 정합성, 동시성, 트랜잭션을 설명할 수 있다.
- 캐시, 메시지 브로커, 비동기 처리가 필요한 이유를 설명할 수 있다.
- 수직/수평 확장과 병목을 설명할 수 있다.
- 장애 상황에서 시스템이 어떻게 동작해야 하는지 설계할 수 있다.
- 모놀리식/모듈러 모놀리스/마이크로서비스의 장단점을 설명할 수 있다.
- 운영 환경에서 로그/메트릭/트레싱을 활용할 수 있다.
- 최종적으로 요구사항만 보고 전체 시스템을 설계할 수 있다.
1. 아키텍처를 공부하는 기본 관점
모든 기술을 다음 8개 질문으로 분석한다.
| 질문 | 설명 |
|---|---|
| Why | 왜 이 기술/구조가 필요한가? |
| What | 무엇을 해결하는가? |
| How | 내부적으로 어떻게 동작하는가? |
| Trade-off | 무엇을 얻고 무엇을 잃는가? |
| Failure | 어떤 장애가 발생할 수 있는가? |
| Scale | 트래픽/데이터가 증가하면 어디가 먼저 문제가 되는가? |
| Alternative | 다른 방법은 무엇이고 언제 사용하는가? |
| Production | 실제 운영 환경에서는 어떤 문제가 추가되는가? |
2. 가장 중요한 원칙
아키텍처를 기술 이름으로 공부하지 않는다. 항상 Problem → Requirement → Constraint → Mechanism → Architecture → Trade-off → Failure → Scale → Operations 순서를 유지한다.
Database가 느리다 → 반복 조회가 많다 → Cache 필요 → Redis 사용 → Cache Aside → Cache Miss → Thundering Herd → Invalidation → Redis 장애 → Database 부하 증가 → Failover / Degradation
3. Architecture Evolution
현대 아키텍처는 갑자기 만들어진 것이 아니다.
Single Application
↓
Layered Monolith
↓
Modular Monolith
↓
SOA
↓
Microservices
↓
Event-Driven Systems
↓
Cloud Native
↓
Kubernetes
↓
Platform Engineering
↓
AI-Native / Agentic Systems- 이전 구조가 어떤 문제를 가지고 있었는가?
- 새로운 구조는 어떤 문제를 해결했는가?
- 어떤 복잡성이 새롭게 생겼는가?
- 지금도 이전 구조를 사용하는 것이 더 좋은 경우는 무엇인가?
4. Architecture Categories
현대 시스템을 10개의 Architecture Category로 분류한다.
| Category | 영역 | 핵심 주제 |
|---|---|---|
| A — Application | 애플리케이션 구조 | Layered, MVC, Clean, Hexagonal, Onion, Modular Monolith, Microservices |
| B — Distributed | 분산 통신 | REST, gRPC, Event-Driven, Pub/Sub, CQRS, Event Sourcing |
| C — Cloud Native | 클라우드 네이티브 | Containers, Kubernetes, Service Discovery, GitOps, IaC |
| D — Platform | 플랫폼 | Platform Engineering, IDP, Golden Paths, Self-Service |
| E — Serverless | 서버리스 | FaaS, Managed Services, Event-Driven Serverless |
| F — Data | 데이터 | Relational, Document, Key-Value, Search, OLTP/OLAP, Lakehouse |
| G — Reliability | 신뢰성 | HA, Fault Tolerance, Multi-AZ/Region, DR, SLO/SLI |
| H — Edge | 엣지 | CDN, Edge Computing, Edge Functions, Edge AI |
| I — AI | AI 애플리케이션 | LLM, RAG, Vector Search, AI Gateway, Agent, Multi-Agent |
| J — AI-Native Platform | AI 인프라 | GPU Scheduling, Model Serving, AI Observability, Agent Platform |
5. Architecture Selection Matrix
아키텍처를 배울 때 이 표를 암기하지 않는다. 요구사항을 보고 직접 선택하도록 훈련한다.
| Architecture | Main Problem | Complexity | Scaling | Consistency | Typical Use |
|---|---|---|---|---|---|
| Layered Monolith | Simple application | 낮음 | 중간 | 높음 | 일반 Web |
| Modular Monolith | Domain/module separation | 낮음~중간 | 중간 | 높음 | 성장하는 Web |
| Microservices | Independent services | 높음 | 높음 | 분산 | Large organizations |
| Event-Driven | Loose coupling / async | 높음 | 높음 | Eventual | Async systems |
| Serverless | Infra abstraction | 중간 | 높음 | 상황별 | Event/API |
| Kubernetes | Container orchestration | 높음 | 높음 | 상황별 | Cloud Native |
| Platform Engineering | Infra complexity | 높음 | 조직적 | 조직적 | Large teams |
| CQRS | Read/write separation | 높음 | 높음 | 상황별 | Specialized workloads |
| Event Sourcing | Full state history | 높음 | 높음 | Eventual 가능 | Audit-heavy systems |
| RAG | Grounded AI | 중간~높음 | 높음 | 데이터 의존 | Enterprise AI |
| Agentic AI | Autonomous workflow | 높음 | 높음 | 복잡 | AI automation |
| Edge | Latency / locality | 높음 | 높음 | 지역별 | Global / IoT |
11. Mandatory Mental Models
모든 학습은 다음 Mental Model과 연결한다.
Computer → OS → Network → HTTP → Application → Database → Cache → Message → Distributed System → Container → Kubernetes → Cloud → Platform Engineering → Observability / Security → AI Application → Agentic System → AI Infrastructure
- Request Path: Client → Network → Server → Application → Database
- Data Path: Application → Cache / DB / Storage
- Control Path: Application → Queue → Worker → Event
- Failure Path: Request → Timeout → Retry → Circuit Breaker → Fallback
- Scale Path: Single Server → Multiple Server → Load Balancer → Cache → Replication → Partition → Sharding
14. Architecture Decision Making
아키텍처 의사결정은 다음 순서로 한다.
Step 1: Requirements Step 2: Constraints Step 3: Traffic / Data Estimation Step 4: High-Level Architecture Step 5: Data Model Step 6: API Design Step 7: Scaling Step 8: Failure Handling Step 9: Security Step 10: Observability Step 11: Cost Step 12: Trade-offs
17. Golden Rule
프레임워크부터 외우지 않는다. 항상 다음 순서로 사고한다.
Problem → Constraint → Mechanism → Architecture → Trade-off → Failure → Scale
- "무엇인가?"에서 끝내지 말고
- "왜 만들어졌는가?"
- "내부적으로 어떻게 동작하는가?"
- "언제 문제가 되는가?"
- "무엇으로 대체할 수 있는가?"
- "실제 시스템에서 어디에 배치되는가?"
- Modern Architecture의 핵심은 기술 이름이 아니라 복잡성을 어디에 배치하고 어떻게 통제할 것인가이다.