2nd/10_Wiki/Topic_Programming/Architecture/3의 법칙 (Rule of Three).md

---
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 정리 |