Files

T

Antigravity Agent f8b21af4be Wiki cleanup: error-doc removal, dedup merge, link normalization

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>

2026-05-20 23:52:15 +09:00

6.5 KiB

Raw Blame History

id, title, category, status, canonical_id, aliases, duplicate_of, source_trust_level, confidence_score, verification_status, tags, raw_sources, last_reinforced, github_commit, tech_stack

title

SARA (Software Architecture Review and Assessment)

매 한 줄

"매 architecture 를 매 quality-attribute 관점에서 systematic review 하는 프로세스". SEI (Carnegie Mellon) 의 SAAM (1996) → ATAM (2000) → ARID (2002) 계보의 generic 명칭. 매 핵심: stakeholder, scenario, tradeoff, risk 의 명시적 enumeration. 매 2026 modern variant: AWS Well-Architected Review, Architecture Decision Records (ADR), Wardley Mapping 과 결합.

매 핵심

매 SEI 계보

SAAM (Software Architecture Analysis Method, 1996): scenario-based, modifiability 위주.
ATAM (Architecture Tradeoff Analysis Method, 2000): multi-quality, tradeoff 명시.
ARID (Active Reviews for Intermediate Designs, 2002): incomplete design review.
CBAM (Cost-Benefit Analysis Method): economic angle.

매 ATAM 9-step (Kazman et al.)

Present ATAM
Present business drivers
Present architecture
Identify architectural approaches
Generate quality attribute utility tree
Analyze approaches (round 1)
Brainstorm scenarios + prioritize
Analyze approaches (round 2)
Present results

매 산출물

Utility tree: quality attribute → scenario → priority/difficulty.
Risk / non-risk / sensitivity point / tradeoff point.
Architectural decision record (ADR) update.

매 응용

Pre-launch architecture sign-off.
Major refactor / re-platforming 의사결정.
M&A due diligence.
AWS/GCP Well-Architected formal review.

💻 패턴

Utility tree (markdown)

- Performance
  - Latency
    - [H, M] p99 checkout < 300ms under 10k rps
    - [M, L] search autocomplete < 80ms
  - Throughput
    - [H, H] sustained 50k rps with 3 AZ failover
- Availability
  - [H, M] 99.95% monthly, RPO=5min, RTO=15min
- Security
  - [H, H] all PII encrypted at rest, TLS 1.3 in transit
- Modifiability
  - [M, M] new payment provider 매 < 2 sprint
# [Importance, Difficulty]: H/M/L

Scenario template

id: SCN-007
quality: availability
source: AZ outage in us-east-1a
stimulus: complete loss of one AZ for 30 min
artifact: checkout service
environment: peak traffic, Black Friday
response: traffic auto-shifts to remaining 2 AZ
response_measure: error rate < 0.5% for full 30 min
priority: H
difficulty: M

Risk / Tradeoff log

| ID | Type | Description | Affected QAs |
|----|------|-------------|--------------|
| R1 | Risk | Single Redis primary; failover untested | Availability |
| T1 | Tradeoff | Multi-region active-active raises consistency cost | Availability ↔ Consistency |
| S1 | Sensitivity | p99 latency depends on connection-pool size | Performance |
| NR1| Non-risk | Stateless API tier, autoscale verified | Scalability |

ADR (Architecture Decision Record)

# ADR-0042: Adopt event-driven checkout via Kafka

Date: 2026-05-10
Status: accepted
Context: synchronous REST chain causes p99 spikes and tight coupling.
Decision: introduce Kafka topic `orders.v1`; checkout publishes; downstream
  services (inventory, fulfilment, notify) consume independently.
Consequences:
  + Decoupling, replayability, easier multi-region.
  - New ops surface (Kafka), schema-registry overhead.
  - Eventual consistency: UI must surface "processing" state.
Alternatives considered: SQS (vendor lock), gRPC streaming (still coupled).

Wardley Map sketch (text)

Visible
  ^  User --- Checkout UI
  |              |
  |          Order API ---- Payment Gateway (Stripe, product)
  |              |
  |          Order DB (Postgres, custom-built→product)
  |              |
  |          Compute (k8s on EKS, commodity)
  v
Invisible
[Genesis] -- [Custom] -- [Product] -- [Commodity]

AWS Well-Architected lens (CLI)

# 매 AWS WA Tool — SARA-equivalent at AWS scale
aws wellarchitected create-workload \
  --workload-name checkout-2026 \
  --description "Checkout platform" \
  --environment PRODUCTION \
  --aws-regions us-east-1 us-west-2 \
  --lenses arn:aws:wellarchitected::aws:lens/wellarchitected \
            arn:aws:wellarchitected::aws:lens/serverless

Lightweight LARA (lightweight ARID, 1-day variant)

09:00 kickoff + business drivers
10:00 architect 30-min walkthrough
10:30 utility tree workshop
12:00 lunch
13:00 scenario brainstorm + dot voting
14:00 round-1 analysis (top 5 scenarios)
16:00 risk/tradeoff log finalize
17:00 readout to stakeholders

매 결정 기준

상황	Approach
Greenfield, pre-launch	Full ATAM (3-day)
Time-boxed, single team	LARA (1-day)
Cloud-native AWS	Well-Architected Review per pillar
Continuous	ADR + monthly architecture council
Incomplete design	ARID (active review)
Cost-driven	CBAM

기본값: 매 ADR + 매 quarterly LARA + 매 cloud Well-Architected annual.

🔗 Graph

부모: Software Architecture · Quality Attributes
변형: ATAM
Adjacent: Risk_Management · Threat Modeling · Tech Radar

🤖 LLM 활용

언제: 매 utility tree 초안, 매 scenario 생성, 매 ADR 작성, 매 tradeoff 분석. 언제 X: 매 final sign-off — human architect + stakeholder accountability 필수.

❌ 안티패턴

Architecture astronautics: 매 utility tree 만 만들고 매 scenario 분석 skip.
Single-quality focus: 매 performance 만 — security/modifiability 무시.
Review without authority: 매 결과를 매 누구도 implement 강제 못함.
One-shot review: 매 launch 전 한 번 — drift 후 재평가 없음.
No ADR: 매 결정의 why 가 없어 매 6개월 뒤 누구도 이유 모름.
Theatre review: 매 형식적 sign-off, 매 실제 risk 미공개.

🧪 검증 / 중복

Verified: SEI ATAM technical reports (Kazman, Klein, Clements 2000–2002); Bass et al. Software Architecture in Practice 4e (2021); AWS Well-Architected Framework (2025).
신뢰도 A.

🕓 Changelog

날짜	변경
2026-05-08	Phase 1
2026-05-10	Manual cleanup — ATAM 9-step, utility tree, ADR, Well-Architected

6.5 KiB Raw Blame History Unescape Escape