Antigravity Agent
f8b21af4be
10_Wiki/Topics 대규모 정리: - 오류 캡처/미완성 stub 문서 227개 제거 - 교차폴더 중복 43클러스터 병합 (63파일 → redirect) - 링크명 정규화: 깨진 링크 수정·redirect 직결·개념 매핑 ~2,400건 - 카테고리 MOC 6개 신규 생성 - Graph 섹션 미해결 related-keyword 링크 10,058건 제거 Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
194 lines
6.9 KiB
Markdown
194 lines
6.9 KiB
Markdown
---
|
|
id: wiki-2026-0508-macro-architecture
|
|
title: Macro-architecture
|
|
category: 10_Wiki/Topics
|
|
status: verified
|
|
canonical_id: self
|
|
aliases: [Macro Architecture, System-level Architecture]
|
|
duplicate_of: none
|
|
source_trust_level: A
|
|
confidence_score: 0.9
|
|
verification_status: applied
|
|
tags: [architecture, system-design, macro-vs-micro]
|
|
raw_sources: []
|
|
last_reinforced: 2026-05-10
|
|
github_commit: pending
|
|
tech_stack:
|
|
language: none
|
|
framework: none
|
|
---
|
|
|
|
# Macro-architecture
|
|
|
|
## 매 한 줄
|
|
> **"매 system-wide structural decision 의 layer"**. Macro-architecture 는 매 component boundaries, deployment topology, integration style, technology selection 등 매 cross-cutting decision. Micro-architecture (single service 내부 design) 와 대비. 2026 의 macro decisions 는 매 monolith vs microservice, sync vs event-driven, multi-region vs single-region, K8s vs serverless, mesh vs mesh-less.
|
|
|
|
## 매 핵심
|
|
|
|
### 매 Macro vs Micro
|
|
- **Macro**: matter at system level — 매 service boundary, data ownership, integration protocol, deployment unit, observability backbone.
|
|
- **Micro**: matter within a service — 매 module structure, design pattern, framework choice, internal database schema.
|
|
- **Boundary**: macro 는 매 organizational/team alignment 까지 reach (Conway's Law).
|
|
|
|
### 매 macro decision dimensions
|
|
1. **Decomposition**: monolith / modular monolith / microservices / functions.
|
|
2. **Communication**: sync REST/gRPC / async events (Kafka, NATS) / hybrid.
|
|
3. **State**: shared DB / DB-per-service / event-sourced / CRDT.
|
|
4. **Deployment**: K8s / VM / serverless / edge.
|
|
5. **Topology**: single region / multi-region active-active / cell-based.
|
|
6. **Observability**: logs/metrics/traces backbone — OTel + central platform.
|
|
7. **Security**: zero-trust mesh / perimeter / identity backbone (SPIFFE, OIDC).
|
|
8. **Data plane**: CDN / mesh / API gateway / event bus.
|
|
|
|
### 매 trade-off principle
|
|
- **Reversibility**: macro decisions are 매 expensive to reverse — invest more in initial analysis.
|
|
- **Coupling**: macro choices set the lower bound of coupling between teams.
|
|
- **Conway's Law**: 매 system architecture mirrors 매 communication structure.
|
|
|
|
### 매 응용 (typical macro patterns)
|
|
1. Modular monolith 의 service-extraction roadmap.
|
|
2. Event-driven backbone (Kafka) 의 system-wide adoption.
|
|
3. Multi-region active-active for global low-latency.
|
|
4. Cell-based architecture for blast-radius isolation.
|
|
5. Platform engineering — internal developer platform (IDP) as macro substrate.
|
|
|
|
## 💻 패턴
|
|
|
|
### 1. Modular monolith (macro starting point)
|
|
```
|
|
app/
|
|
modules/
|
|
billing/ # bounded context
|
|
api/ # public interface
|
|
domain/
|
|
infra/
|
|
inventory/
|
|
api/
|
|
domain/
|
|
infra/
|
|
shipping/
|
|
shared-kernel/ # carefully curated
|
|
build.gradle # one binary, internal module boundaries
|
|
```
|
|
|
|
### 2. Microservice extraction (incremental)
|
|
```yaml
|
|
# Step 1: Strangler Fig — new feature in new service
|
|
# Step 2: Move read paths
|
|
# Step 3: Move write paths with dual-write/CDC
|
|
# Step 4: Decommission old module
|
|
|
|
# Macro decision: service boundary = bounded context = team boundary
|
|
```
|
|
|
|
### 3. Event-driven backbone
|
|
```yaml
|
|
# Kafka cluster as system-wide event bus
|
|
topics:
|
|
- order.created
|
|
- order.paid
|
|
- shipment.dispatched
|
|
|
|
# Each service:
|
|
# - publishes its domain events
|
|
# - consumes others' events for projections
|
|
# Macro contract: event schema (Avro/Protobuf) + retention policy
|
|
```
|
|
|
|
### 4. Cell-based architecture
|
|
```
|
|
Cell-A (US-East): full stack — API + DB + cache + workers
|
|
Cell-B (US-East): full stack — independent
|
|
Cell-C (EU-West): full stack
|
|
Router: hash(tenant_id) → cell
|
|
# Blast radius = 1 cell. No cross-cell sync data path.
|
|
```
|
|
|
|
### 5. Multi-region active-active
|
|
```
|
|
Region: us-east-1
|
|
- API + DB primary (writes)
|
|
- Async replication ↔ us-west-2
|
|
|
|
Region: us-west-2
|
|
- API + DB primary (writes for local users)
|
|
- Async replication ↔ us-east-1
|
|
|
|
Conflict resolution: CRDT 또는 last-write-wins with vector clock.
|
|
DNS: GeoDNS routing.
|
|
```
|
|
|
|
### 6. Platform engineering substrate
|
|
```yaml
|
|
# Internal Developer Platform (Backstage + ArgoCD + Crossplane)
|
|
templates:
|
|
- new-service: # one command bootstraps
|
|
- K8s namespace
|
|
- CI/CD pipeline
|
|
- observability hooks
|
|
- secrets vault path
|
|
- on-call rotation
|
|
# Macro decision: paved road for 200 dev teams
|
|
```
|
|
|
|
### 7. Architecture Decision Record (ADR) — macro discipline
|
|
```markdown
|
|
# ADR-042: Adopt Kafka as system event backbone
|
|
|
|
## Context
|
|
We have 12 services with point-to-point HTTP. Coupling is rising.
|
|
|
|
## Decision
|
|
Adopt Kafka. All domain events publish to Kafka.
|
|
RPC remains for synchronous request/response.
|
|
|
|
## Consequences
|
|
+ Decoupling, replay, audit log.
|
|
- New SRE skill, schema registry overhead, eventual consistency.
|
|
|
|
## Alternatives considered
|
|
- NATS JetStream (lighter but less ecosystem)
|
|
- AWS EventBridge (vendor lock-in)
|
|
```
|
|
|
|
## 매 결정 기준
|
|
| 상황 | Macro choice |
|
|
|---|---|
|
|
| <5 dev teams, single product | Modular monolith. |
|
|
| 10+ teams, independent deploy | Microservices. |
|
|
| Bursty load, long-tail features | Serverless functions. |
|
|
| Globally distributed users | Multi-region active-active. |
|
|
| Regulated isolation (HIPAA, finance) | Cell-based per tenant tier. |
|
|
| High write throughput, audit need | Event-sourced + CQRS. |
|
|
| Heterogeneous edge (IoT) | Edge compute + central plane. |
|
|
|
|
**기본값**: 매 startup 은 modular monolith. 매 scaling org 는 selective microservice extraction. 매 platform 은 K8s + OTel + Kafka 의 well-trodden macro stack.
|
|
|
|
## 🔗 Graph
|
|
- 부모: [[Software Architecture]] · [[System Design]]
|
|
- 변형: [[Enterprise Architecture]]
|
|
- 응용: [[Cloud_Native|Modular Monolith]] · [[Microservices]] · [[Event-Driven Architecture]]
|
|
- Adjacent: [[Conway's Law]] · [[Architecture Decision Record]] · [[Platform Engineering]]
|
|
|
|
## 🤖 LLM 활용
|
|
**언제**: system-wide architecture review, decomposition strategy, technology selection at scale, ADR drafting.
|
|
**언제 X**: 매 single-module refactor, framework-internal design, 매 micro-architecture concern.
|
|
|
|
## ❌ 안티패턴
|
|
- **Microservices for 3-team org**: 매 distributed monolith 의 worst-of-both — coordination cost > decoupling benefit.
|
|
- **Macro decision without ADR**: 매 reasoning loss, 매 future team 의 reversal 시 context 부재.
|
|
- **Premature multi-region**: 매 business need 없이 매 cost + complexity 의 2-3x.
|
|
- **Conway's Law ignorance**: 매 architecture vs org chart mismatch — 매 friction permanent.
|
|
- **Tech-driven macro choice**: 매 "Kafka is cool" 의 매 problem 정의 없는 도입.
|
|
- **Frozen macro architecture**: 매 5년 unreviewed — 매 evolutionary architecture 의 부재.
|
|
|
|
## 🧪 검증 / 중복
|
|
- Verified (Fowler "Microservices" articles, Newman *Building Microservices* 2nd ed., Hohpe *Software Architect Elevator*).
|
|
- 신뢰도 A.
|
|
|
|
## 🕓 Changelog
|
|
| 날짜 | 변경 |
|
|
|---|---|
|
|
| 2026-05-08 | Phase 1 |
|
|
| 2026-05-10 | Manual cleanup — macro vs micro distinction + 2026 macro patterns (cell, multi-region, IDP) |
|