---
name: doubt
description: 구현 완료 후 정리 단계, 또는 새 개념(컴포넌트/플래그/타입/파일/절차) 도입 전(Occam Gate)에 사용. 존재·적합·분량·효율의 4단 필터로 불필요한 것을 제거한다. "이거 다 필요해?", "정리 좀 해줘", "새로 만들어야 할까?", "불필요한 거 없나?" 등을 말할 때 사용. 코드·문서·구조·절차 모두 대상.
---

## /doubt — 빼는 것도 선택지다

> **이론적 기반**:
> - Leidy Klotz *Subtract* — 인간은 체계적으로 뺄셈을 간과한다. 의식적 트리거가 필요하다.
> - Chesterton's Fence — 왜 있는지 이해한 뒤 빼라.

### 대상

모든 것. 코드, 워크플로우, 문서, 프로젝트 구조, 기능, 절차.
호출 시 scope를 지정할 수 있다. 미지정 시 대화 맥락에서 추론한다.

### Scope 감지

호출 맥락에서 모드를 판별한다:
- **새 개념 도입** ("이거 추가해야 할까?", "새 타입이 필요한데") → **Occam Gate 우선**, 통과 시 필터 체인
- **정리 요청** ("불필요한 거 정리해줘", "코드 줄여줘") → **필터 체인 직행**

### ⛔ Occam Gate — 새 개념 도입 전 필수 통과

> **새 컴포넌트, 플래그, 브랜치, 타입, 파일을 만들기 전에** 반드시 이 3가지를 답한다.

```
1. 기존 메커니즘으로 해결 가능한가?
   → Yes → 기존 메커니즘을 수정한다. 새 개념 도입 금지.

2. 새 개념이 없으면 어떻게 되는가?
   → "그냥 안 된다" → 다음 질문으로
   → "기존 것이 조금 이상해진다" → 기존 것을 고친다.

3. 이 변경이 시스템의 개념 수를 줄이는가, 늘리는가?
   → 늘린다 → 정말 필요한지 재검토. "다른 프로젝트에서도 이 개념이 필요한가?"
```

**사례 (가상)**:
- ❌ 잘못된 진단: "특정 조작에서 기대 동작이 안 됨 → 새 컴포넌트 + 새 플래그 + 새 옵션 + 전용 테스트 세트 신설"
- ✅ 올바른 진단: 기존 상수/설정값 한 줄 수정으로 해결
- **교훈**: Occam Gate를 먼저 통과했다면 새 개념 도입 자체가 차단됐을 것.

---

### 절차

```
목록화 → 필터체인 → Fence → 실행 → 검증(변경 시) → 보고
```

#### 1. 목록화
- 대상 범위 내의 모든 항목을 나열한다.
- 각 항목의 역할을 1문장으로 설명한다.

#### 2. 필터 체인 (순서대로)

각 항목에 4단계 질문을 적용한다. 첫 번째에서 "아니오"면 나머지를 묻지 않는다.

```
① 쓸모가 있나?  (Existence)  → 아니오 → 🔴 제거 후보
② 형태가 맞나?  (Fit)        → 아니오 → 🟡 재설계 후보
③ 줄일 수 있나? (Volume)     → 예    → 🟡 축소 후보
④ 더 적게?      (Efficiency) → 예    → 🟡 병합/단순화 후보
```

판단이 모호할 때, Lean 7 Muda로 분류해본다: 과잉생산(미리 만듦), 재고(쌓여만 있음), 과잉처리(필요 이상 정교), 운반(불필요한 복사), 동작(반복 입력), 대기(결정 대기로 멈춤), 결함(현실과 불일치).

#### 3. Chesterton's Fence (안전장치)

🔴/🟡 후보 각각에 대해:
```
왜 만들었는지 아는가?
  → Yes → 그 이유가 아직 유효한가?
    → No  → ✅ 제거/축소 확정
    → Yes → 유지 (판정: 🟢)
  → No  → 이유를 조사한다 (git log, 대화 히스토리, docs)
```

#### 4. 실행

- **🔴 제거 확정** → 직접 삭제한다. 칼을 건네지 않고 든다.
- **🟡 축소/병합 확정** → 직접 수정한다.
- **🟢 유지** → 건드리지 않는다.
- 변경이 있었으면 해당 영역의 기존 검증 수단(테스트·타입체크·빌드 등)을 돌려 회귀 여부를 확인한다.

#### 5. 검증 (변경이 있을 때만)

각 변경 건에 대해 되묻는다:
- 이 제거/축소가 다른 항목의 복잡도를 높였는가?
- 보상을 위해 새로운 코드/개념이 필요해졌는가?
- 변경 전보다 시스템이 단순해졌는가?

→ "오히려 복잡해졌다" → 해당 변경만 되돌린다. 이유를 기록한다.
→ 되돌림 = 수렴 신호. 더 빼면 악화된다는 증거.

#### 6. 보고

변경 대상을 상세히, 유지 항목은 카운트+카테고리로 간결하게.

```markdown
# /doubt 결과

## 변경
| 항목 | 판정 | 이유 | 검증 |
|------|------|------|------|
| [항목] | 🔴 제거 / 🟡 축소 | [이유] | ✅ 확정 / ↩️ 되돌림([이유]) |

## 🟢 유지 (N건)
- [카테고리]: N건 — [대표 존재 이유]

## 📊 Before → After
- 항목 수: X → Y (−Z)
```