---
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) |