Files
2nd/10_Wiki/Topics/Domain_Programming/AI_and_ML/Pros-Cons-Table.md
T
Antigravity Agent c24165b8bc 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>
2026-07-11 11:05:56 +09:00

5.3 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
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-pros-cons-table Pros Cons Table 10_Wiki/Topics verified self
Pros-Cons Analysis
Decision Matrix
Weighted Scoring
none A 0.9 applied
decision-making
frameworks
analysis
prompt-pattern
2026-05-10 pending
language framework
Markdown 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

| 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)

| 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

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)

Baseline = Postgres (current)

| Criterion       | SQLite | DuckDB | Mongo |
|-----------------|--------|--------|-------|
| Ops simplicity  | +      | +      | -     |
| Concurrency     | --     | -      | +     |
| Analytics       | -      | ++     | 0     |
| **Net**         | -2     | +2     | 0     |

ADR template (decision record)

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

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

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