refactor(topics): 멀티 에이전트용 지식 재편 — _Common(공통 기본기) + Domain_* 구조

에이전트 8종(대화형/프로그래머 C·S/디자이너/설계자/기획자/QA/PD/PM)에게
[공통 기본 능력 + 롤별 Specialty] 2층으로 지식을 주입하기 위한 재분류.
문서 내용·포맷은 무수정, 폴더 이동만 (6,372개 문서 수 보존 확인).

- Topic_Programming → Domain_Programming (내부 구조 보존)
- Topic_Graphic → Domain_Design
- Topic_Business → Domain_Product
- Topic_General → Domain_General
- _Common 신설: Math(구 Topic_Math_Specialty), Reasoning(구 General/From_Thinking & Reasoning),
  Reasoning_Creativity(구 General/From_창의성), Communication(Poetic_Blog_Writing + From_writing)
- 타 도메인의 From_* 폴더는 유지 (출처 표기일 뿐, 이미 도메인에 맞게 분류된 문서)
- 빈 폴더 정리 (memory/procedures)
- 에이전트→폴더 매핑은 workspace의 .astra/agent-knowledge-map.json (9개 에이전트)

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
This commit is contained in:
Antigravity Agent
2026-07-11 11:05:56 +09:00
parent 6549ead309
commit c24165b8bc
6193 changed files with 1717 additions and 31 deletions
@@ -0,0 +1,182 @@
---
id: wiki-2026-0508-pros-cons-table
title: Pros Cons Table
category: 10_Wiki/Topics
status: verified
canonical_id: self
aliases: [Pros-Cons Analysis, Decision Matrix, Weighted Scoring]
duplicate_of: none
source_trust_level: A
confidence_score: 0.9
verification_status: applied
tags: [decision-making, frameworks, analysis, prompt-pattern]
raw_sources: []
last_reinforced: 2026-05-10
github_commit: pending
tech_stack:
language: Markdown
framework: Decision-Frameworks
---
# Pros Cons Table
## 매 한 줄
> **"매 column = option, 매 row = criterion, 매 cell = signed weight"**. 18C Benjamin Franklin 의 "Moral Algebra" 의 modern 의 weighted decision matrix. 매 LLM era 에서 매 "let's enumerate pros/cons" 의 prompt pattern 으로 popular.
## 매 핵심
### 매 형태
- **Simple 2-col**: Pros | Cons. 매 quick gut-check.
- **Weighted scoring**: Criterion × Weight × Score per option.
- **Decision matrix (Pugh)**: Baseline + relative ±.
- **WSJF (SAFe)**: Cost of Delay / Job Size — agile prioritization.
- **MoSCoW**: Must / Should / Could / Won't.
### 매 components
1. **Options**: 매 mutually-exclusive choice.
2. **Criteria**: 매 weighted dimension (cost, risk, impact).
3. **Scores**: 매 15 or -2..+2.
4. **Total**: Σ(weight × score).
5. **Tiebreaker rule**: 매 explicit, 매 not vibes.
### 매 응용
1. Tech selection (Postgres vs MySQL).
2. Hire/no-hire scorecard.
3. Architecture ADR.
4. Product feature prioritization.
5. LLM-assisted decision drafting.
## 💻 패턴
### Simple Markdown
```markdown
| Option | Pros | Cons |
|----------|-------------------------------|----------------------------|
| Postgres | Mature, JSON, extensions | Heavier ops |
| SQLite | Zero ops, file-based | No concurrency at scale |
| DuckDB | Analytical, columnar | Not OLTP |
```
### Weighted scoring (Markdown)
```markdown
| Criterion | W | Postgres | SQLite | DuckDB |
|-----------------|---|----------|--------|--------|
| Ops simplicity | 3 | 2 | 5 | 4 |
| Concurrency | 4 | 5 | 1 | 2 |
| Analytics speed | 2 | 3 | 2 | 5 |
| Ecosystem | 2 | 5 | 4 | 3 |
| **Weighted** | | **38** | **30** | **31** |
```
### Python decision matrix
```python
import pandas as pd
criteria = {
"ops": (3, {"postgres": 2, "sqlite": 5, "duckdb": 4}),
"concurrency": (4, {"postgres": 5, "sqlite": 1, "duckdb": 2}),
"analytics": (2, {"postgres": 3, "sqlite": 2, "duckdb": 5}),
}
options = ["postgres", "sqlite", "duckdb"]
scores = {opt: sum(w * s[opt] for w, s in criteria.values())
for opt in options}
print(pd.Series(scores).sort_values(ascending=False))
```
### LLM prompt template
```
Compare {{options}} for {{decision}}.
For each, list:
- 3 pros (specific, measurable)
- 3 cons (specific, measurable)
Then weighted scoring:
- Criteria: {{criteria_with_weights}}
- Score 1-5
Output Markdown table + recommendation paragraph + key tradeoff.
```
### Pugh matrix (vs baseline)
```markdown
Baseline = Postgres (current)
| Criterion | SQLite | DuckDB | Mongo |
|-----------------|--------|--------|-------|
| Ops simplicity | + | + | - |
| Concurrency | -- | - | + |
| Analytics | - | ++ | 0 |
| **Net** | -2 | +2 | 0 |
```
### ADR template (decision record)
```markdown
# ADR-007: Choose DuckDB for analytics layer
## Context
OLTP on Postgres. Analytics queries timing out.
## Options
1. Materialized views in Postgres
2. ClickHouse
3. DuckDB embedded
## Decision
DuckDB — embedded, zero ops, columnar.
## Consequences
+ 50x query speedup
- New skill, immature operator tooling
```
### Weighted MCDA (numpy)
```python
import numpy as np
weights = np.array([0.3, 0.4, 0.2, 0.1])
scores = np.array([
[2, 5, 3, 5], # postgres
[5, 1, 2, 4], # sqlite
[4, 2, 5, 3], # duckdb
])
totals = scores @ weights
ranked = np.argsort(-totals)
```
## 매 결정 기준
| 상황 | Approach |
|---|---|
| 2-3 options, gut check | **Simple pros/cons** |
| 4+ options, need defense | Weighted scoring |
| Iterating on baseline | Pugh matrix |
| Architecture / team-wide | ADR |
| Backlog ordering | WSJF / RICE |
**기본값**: Weighted scoring 5 criteria × 3 options.
## 🔗 Graph
- 부모: [[Decision-Making]]
- 변형: [[Pugh-Matrix]] · [[ADR]]
- Adjacent: [[OKR]]
## 🤖 LLM 활용
**언제**: 매 broad option 의 enumerate, 매 missing criterion 의 surface, 매 first-pass draft.
**언제 X**: 매 final weight 결정 — 매 stakeholder context 의 LLM 의 X. 매 numeric score 의 false precision 의 위험.
## ❌ 안티패턴
- **No weights**: 매 critical criterion 의 trivial criterion 과 same. 매 rigging.
- **Score after deciding**: 매 confirmation bias. 매 weight 의 score 전에 lock.
- **Too many criteria**: 매 7+ 의 noise. 매 top 3-5.
- **Symmetric scoring**: 매 모든 option 의 비슷한 total — 매 differentiator 의 부재.
- **Hidden disqualifier**: 매 "must" 가 weighted 의 안에 묻힘. 매 hard filter 의 pre-screen.
## 🧪 검증 / 중복
- Verified (Franklin's letter to Priestley 1772, Pugh 1991, MCDA literature).
- 신뢰도 A.
## 🕓 Changelog
| 날짜 | 변경 |
|---|---|
| 2026-05-08 | Phase 1 |
| 2026-05-10 | Manual cleanup — pros/cons + weighted decision frameworks. |