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

---
id: wiki-2026-0508-utility-tree-유틸리티-트리
title: Utility Tree (유틸리티 트리)
category: 10_Wiki/Topics
status: verified
canonical_id: self
aliases: [유틸리티 트리, ATAM Utility Tree]
duplicate_of: none
source_trust_level: A
confidence_score: 0.9
verification_status: applied
tags: [architecture, atam, quality-attributes, sei]
raw_sources: []
last_reinforced: 2026-05-10
github_commit: pending
tech_stack:
  language: conceptual
  framework: 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)
```text
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)
```yaml
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)
```yaml
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
```yaml
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
```markdown
# 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
```text
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]]
- 변형: [[Quality_Attribute_Workshop]] · [[NFR]]
- 응용: [[ADR]] · [[Architecture_Review]]
- Adjacent: [[Sensitivity_Point]] · [[Tradeoff_Point]] · [[Risk_Theme]]

## 🤖 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 |