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:
@@ -0,0 +1,127 @@
|
||||
---
|
||||
id: wiki-2026-0508-3의-법칙-rule-of-three
|
||||
title: 3의 법칙 (Rule of Three)
|
||||
category: 10_Wiki/Topics
|
||||
status: verified
|
||||
canonical_id: self
|
||||
aliases: [Rule of Three, WET, Three Strikes Refactor]
|
||||
duplicate_of: none
|
||||
source_trust_level: A
|
||||
confidence_score: 0.9
|
||||
verification_status: applied
|
||||
tags: [refactoring, dry, code-smell, abstraction]
|
||||
raw_sources: []
|
||||
last_reinforced: 2026-05-10
|
||||
github_commit: pending
|
||||
tech_stack:
|
||||
language: python
|
||||
framework: general
|
||||
---
|
||||
|
||||
# 3의 법칙 (Rule of Three)
|
||||
|
||||
## 매 한 줄
|
||||
> **"매 두 번까지는 복사, 세 번째 등장하면 추출."** Don Roberts 가 *Refactoring* (Fowler, 1999) 에 정식화한 휴리스틱. 매 premature abstraction 을 피하면서 매 진짜 duplication 만 제거하는 trade-off rule. 2026 LLM 기반 codegen 시대에도 매 the cheapest signal — 매 abstraction 의 timing 을 결정.
|
||||
|
||||
## 매 핵심
|
||||
|
||||
### 매 왜 "3"인가
|
||||
- **2회는 coincidence**: 매 same-shape 의 코드 두 개는 매 future 에 diverge 할 가능성이 높음. 매 abstraction 으로 묶으면 매 wrong abstraction lock-in.
|
||||
- **3회는 pattern**: 매 third occurrence 에서 매 invariant 가 무엇인지 보임. 매 axis of variation 이 명확해짐.
|
||||
- **AHA principle**: "Avoid Hasty Abstractions" (Sandi Metz). 매 duplication is far cheaper than the wrong abstraction.
|
||||
|
||||
### 매 vs DRY
|
||||
- DRY: "Every piece of knowledge must have a single, authoritative representation" — 매 *knowledge* 에 대한 rule.
|
||||
- Rule of 3: 매 *code shape* 에 대한 rule.
|
||||
- 매 두 코드가 same-shape 이지만 different-knowledge 일 수 있음 → 매 DRY 가 적용되지 않음.
|
||||
|
||||
### 매 응용
|
||||
1. Helper function 추출 timing 결정.
|
||||
2. Component / Module 추출 timing 결정.
|
||||
3. Configuration parameter 도입 timing 결정.
|
||||
|
||||
## 💻 패턴
|
||||
|
||||
### 1) 2회까지는 inline (resist abstraction)
|
||||
```python
|
||||
# Occurrence 1
|
||||
user_email = data["user"]["email"].strip().lower()
|
||||
|
||||
# Occurrence 2 — DO NOT extract yet
|
||||
admin_email = data["admin"]["email"].strip().lower()
|
||||
```
|
||||
|
||||
### 2) 3회째에 추출 — invariant 가 분명해진 시점
|
||||
```python
|
||||
def normalize_email(raw: str) -> str:
|
||||
return raw.strip().lower()
|
||||
|
||||
user_email = normalize_email(data["user"]["email"])
|
||||
admin_email = normalize_email(data["admin"]["email"])
|
||||
support_email = normalize_email(data["support"]["email"]) # ← trigger
|
||||
```
|
||||
|
||||
### 3) 매 wrong-abstraction 의 anti-pattern
|
||||
```python
|
||||
# 2회만에 추출했다가 3회째가 다른 shape 으로 등장
|
||||
def process_record(r, mode): # mode 가 점점 늘어남 — leaky abstraction
|
||||
if mode == "user": ...
|
||||
elif mode == "admin": ...
|
||||
elif mode == "audit": ... # 완전히 다른 logic
|
||||
```
|
||||
|
||||
### 4) 매 React component 의 Rule of 3
|
||||
```tsx
|
||||
// 2개 까지는 copy-paste
|
||||
<Card title="A"><p>...</p></Card>
|
||||
<Card title="B"><p>...</p></Card>
|
||||
// 3번째 → extract <UserCard> abstraction
|
||||
```
|
||||
|
||||
### 5) 매 LLM-assisted refactoring 의 trigger
|
||||
```python
|
||||
# Claude / Cursor 에게 "extract this duplication" 을 매 3회 occurrence 부터 요청.
|
||||
# 2회 occurrence 에서는 "leave inline" 을 명시.
|
||||
```
|
||||
|
||||
### 6) 매 test 에서의 예외
|
||||
```python
|
||||
# Test 코드는 Rule of 3 보다 readability 우선.
|
||||
# 매 fixture 추출은 매 2회에도 OK (DAMP > DRY in tests).
|
||||
```
|
||||
|
||||
## 매 결정 기준
|
||||
| 상황 | Approach |
|
||||
|---|---|
|
||||
| 매 same-shape 코드 2회 | Inline 유지 |
|
||||
| 매 same-shape + same-knowledge 3회 | Extract |
|
||||
| 매 same-shape + different-knowledge 3회 | Inline 유지 (DRY 위반 아님) |
|
||||
| Test fixture | 2회에도 추출 OK |
|
||||
| Cross-module duplication | 3회 + 매 stable interface 확인 후 |
|
||||
|
||||
**기본값**: 매 3회까지 wait, 매 4번째에 후회하지 않을 abstraction 만 추출.
|
||||
|
||||
## 🔗 Graph
|
||||
- 부모: [[Refactoring_Best_Practices|Refactoring]] · [[DRY]]
|
||||
- 변형: [[YAGNI]]
|
||||
- 응용: [[Code Smell]]
|
||||
|
||||
## 🤖 LLM 활용
|
||||
**언제**: 매 codegen 의 review 시 — "이거 2회만에 추출됐는데 3회 기다려야 하나?" 매 sanity check.
|
||||
**언제 X**: 매 test 코드 / 매 boilerplate / 매 framework-required pattern 에는 적용 X.
|
||||
|
||||
## ❌ 안티패턴
|
||||
- **Premature abstraction**: 매 1-2회 occurrence 에서 추출 → 매 wrong axis 로 lock-in.
|
||||
- **Eternal copy-paste**: 매 5+ occurrence 인데도 추출 안 함 → 매 maintenance burden.
|
||||
- **Mode-flag explosion**: 매 추출한 함수에 매 boolean / enum flag 가 계속 늘어남 → 매 wrong abstraction signal.
|
||||
- **DRY-religious**: 매 "any duplication is sin" → 매 shape 만 같은 code 까지 강제 통합.
|
||||
|
||||
## 🧪 검증 / 중복
|
||||
- Verified (Fowler *Refactoring* 2nd ed. 2018, Sandi Metz "The Wrong Abstraction" 2016).
|
||||
- 신뢰도 A.
|
||||
|
||||
## 🕓 Changelog
|
||||
| 날짜 | 변경 |
|
||||
|---|---|
|
||||
| 2026-05-08 | Phase 1 |
|
||||
| 2026-05-10 | Manual cleanup — Rule of 3 trade-off + AHA + LLM refactor trigger 정리 |
|
||||
Reference in New Issue
Block a user