2nd/10_Wiki/Topics/Domain_Programming/Architecture/Utility Tree (유틸리티 트리).md

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

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
wiki-2026-0508-utility-tree-유틸리티-트리	Utility Tree (유틸리티 트리)	10_Wiki/Topics	verified	self	유틸리티 트리 ATAM Utility Tree	none	A	0.9	applied	architecture atam quality-attributes sei		2026-05-10	pending	language framework conceptual atam

Utility Tree (유틸리티 트리)

매 한 줄

"매 ATAM 의 quality attributes 의 hierarchical decomposition + prioritization tree". 매 architecture evaluation 의 핵심 artifact — 매 stakeholder 의 quality concerns 를 매 testable scenarios 로 brake down. SEI ATAM (Architecture Tradeoff Analysis Method) 의 step 5.

매 핵심

매 구조 (4 levels)

1. Root: "Utility" (overall system goodness).
2. Quality attributes: Performance / Availability / Security / Modifiability / Usability.
3. Attribute refinements: 매 sub-categories (e.g., Performance → latency, throughput).
4. Scenarios: 매 concrete, testable. 매 (H/M/L, H/M/L) — (importance, difficulty).

매 scenario format

• Stimulus: 매 trigger event.
• Source: 매 누가/무엇이.
• Environment: 매 system state.
• Artifact: 매 affected component.
• Response: 매 system 의 반응.
• Response measure: 매 measurable.

매 응용

1. ATAM evaluation workshop — 매 step 5 (utility tree generate), step 6 (scenarios analyze).
2. Architecture review checklist.
3. NFR (non-functional requirement) 의 organization.

💻 패턴

Utility tree (text form)

Utility
├── Performance
│   ├── Latency
│   │   ├── (H, M) Order placement < 200ms p99 under 1k rps
│   │   └── (M, L) Search response < 500ms p95
│   └── Throughput
│       └── (H, H) Sustain 10k orders/sec for 1 hour
├── Availability
│   ├── Hardware failure
│   │   └── (H, M) Single AZ outage → failover < 30s, 0 data loss
│   └── Software failure
│       └── (M, M) Service crash → restart < 10s, queued requests preserved
├── Security
│   ├── Authentication
│   │   └── (H, L) Compromised password → MFA blocks unauthorized access
│   └── Data confidentiality
│       └── (H, M) PII at rest encrypted (AES-256), in-transit TLS 1.3
├── Modifiability
│   ├── New payment provider
│   │   └── (M, L) Add provider in < 2 person-weeks, 0 changes to core
│   └── New region
│       └── (M, M) Deploy to new AWS region in < 1 day
└── Usability
    └── New user
        └── (M, L) First order completion < 5 min for 80% of new users

Scenario detailed (6-part)

id: PERF-001
attribute: Performance / Latency
priority: (H, M)  # importance, difficulty

stimulus: User places order
source: End user (mobile app)
environment: Normal load (1k rps), business hours
artifact: Order service + payment gateway
response: Order confirmed and persisted
response_measure: p99 latency < 200ms (excluding payment provider RTT)

Sensitivity / tradeoff points (ATAM step 7)

sensitivity_points:
  - "Cache TTL of 60s (drives both Latency and Consistency)"
  - "Replication factor of 3 (drives Availability and Cost)"

tradeoff_points:
  - point: "Synchronous payment confirmation"
    affects: ["Latency: ↑ degrades", "Consistency: ↑ improves"]

Risk themes

risks:
  R-001:
    description: "Single payment provider — no failover"
    affects: [Availability]
    severity: H

  R-002:
    description: "No automated DR drill"
    affects: [Availability]
    severity: M

non_risks:
  - "PII encryption is well-tested"

Modern (2026) lightweight version — ADR + scenarios

# ADR-0007: Order service NFRs

## Quality scenarios
| ID | Attribute | (Imp, Diff) | Scenario |
|---|---|---|---|
| P1 | Performance/Latency | (H, M) | p99 order placement < 200ms @ 1k rps |
| A1 | Availability | (H, M) | AZ outage → failover < 30s, 0 data loss |
| S1 | Security | (H, L) | All PII at rest AES-256 |
| M1 | Modifiability | (M, L) | Add new payment provider in < 2 weeks |

## Architecture decisions justified
- DynamoDB Global Tables → A1
- Lambda + provisioned concurrency → P1
- Hexagonal payment port → M1

Generation prompt for LLM

Given the system: <description>
Generate a Utility Tree with:
1. 5 quality attributes (Performance, Availability, Security, Modifiability, Usability)
2. 2-3 refinements per attribute
3. 1-2 scenarios per refinement, each with (importance, difficulty) and 6-part format
Prioritize scenarios. Mark sensitivity/tradeoff points.

매 결정 기준

상황	Approach
매 formal ATAM evaluation	Full utility tree workshop
매 startup / agile	ADR + scenario table (lightweight)
매 NFR documentation	Utility tree as living doc
매 architecture review	Walk through (H,*) scenarios

기본값: 매 startup 은 lightweight ADR + scenarios. 매 enterprise / safety-critical 은 full ATAM.

🔗 Graph

• 부모: ATAM · Architecture_Evaluation
• 변형: NFR
• 응용: ADR · Architecture_Review

🤖 LLM 활용

언제: 매 utility tree draft, 매 scenarios 생성, 매 NFR extraction from PRD. 언제 X: 매 stakeholder 의 priority 결정 — 매 human 의 책임.

❌ 안티패턴

• Vague scenarios ("system should be fast"): 매 measurable 안됨.
• All (H, H): 매 prioritization 의 회피.
• Tree without scenarios: 매 abstract 만 — 매 testable 안됨.
• One-time artifact: 매 evolution 무시 → 매 outdated.

🧪 검증 / 중복

• Verified (SEI ATAM book, Bass/Clements/Kazman "Software Architecture in Practice", 2026).
• 신뢰도 A.

🕓 Changelog

날짜	변경
2026-05-08	Phase 1
2026-05-10	Manual cleanup — ATAM utility tree with scenarios, sensitivity/tradeoff