docs(10_Wiki): 위키 전체 재구성 — Topic_* 폴더를 4개 카테고리로 통합 + 대규모 중복 제거
Topic_Agent/Topic_Blog/Topics/Topics_Biz/Topics_Meeting/Topics_Rag의 마크다운 지식 문서를 Topic_General/Topic_Programming/Topic_Graphic/Topic_Business 4개 카테고리로 재분류. - 중복 제거: frontmatter의 status:duplicate/merged + duplicate_of/redirect_to 필드로 자기 자신을 중복으로 선언한 리다이렉트 stub 1032개 제거, 완전 동일 내용 파일 472개 제거, 동일 파일명·다른 내용 충돌 시 더 큰(완전한) 버전만 유지(162개 제거) — 총 1639개 중복 제거. - 분류: 폴더 단위로 명확한 항목(AI_and_ML/Coding/Architecture 등 → Programming, Comfyui/Visual_Effects → Graphic, Topics_Biz/Topics_Meeting/사업 등 → Business, Poetic_Blog_Writing/창의성/Game_Design 등 → General)은 폴더 우선순위로, 나머지 혼재 폴더(Topic_Agent/Topic_Blog/Topics 루트/Thinking & Reasoning/Other/UI_UX_Assets)는 title/tags 키워드 스코어링으로 파일 단위 분류(불명확한 경우 General로 폴백). 원본 폴더명은 "From_*" 서브폴더로 보존해 추적 가능성 유지. - 최종 배치: Programming 2784 / General 1608 / Graphic 285 / Business 249 = 4926개 문서. - 에이전트 운영 상태(.astra/.agent/.obsidian/sessions/memory/_company/docs/lessons/_shared/src)는 지식 콘텐츠가 아니므로 재분류 대상에서 제외하고 원위치 유지. - Topics/Topic_email(상위 보호 폴더 Topic_email과 파일명 100% 중복) 삭제 — 보호 폴더 자체는 미변경. - 완전히 비게 된 Topic_Agent/Topic_Blog/Topics_Biz/Topics_Rag 폴더 제거.
This commit is contained in:
Antigravity Agent
@@ -0,0 +1,181 @@
|
||||
---
|
||||
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]]
|
||||
- 변형: [[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 |
|
||||
Reference in New Issue
Block a user