doubt

name

doubt

description

Use when the user invokes /doubt or $doubt, asks Codex to deliberately reduce unnecessary complexity before introducing a new concept, component, flag, type, file, branch, workflow, document, or procedure, or requests cleanup/review after implementation. Triggers include "이거 다 필요해?", "정리 좀 해줘", "새로 만들어야 할까?", "불필요한 거 없나?", "코드 줄여줘", "why do we need this?", or any review where existence, fit, volume, and efficiency should be challenged before adding or keeping structure.

/doubt

빼는 것도 선택지로 다룬다. 새 개념을 만들기 전에는 Occam Gate를 먼저 통과시키고, 정리/리뷰 단계에서는 항목을 목록화한 뒤 존재·적합·분량·효율 필터로 줄일 대상을 찾는다.

이론적 기반:

• Leidy Klotz, Subtract: 사람은 문제 해결에서 덧셈을 과하게 선택하므로 의식적인 뺄셈 트리거가 필요하다.
• Chesterton's Fence: 왜 있는지 이해한 뒤 제거한다.

Scope 판별

호출 맥락에서 먼저 모드를 정한다.

• 새 개념 도입: "새 컴포넌트가 필요해", "플래그 추가하자", "타입을 만들까?", "파일을 나누자" 등은 Occam Gate부터 적용한다.
• 정리/축소 요청: "불필요한 거 정리해줘", "코드 줄여줘", "이거 다 필요해?" 등은 필터 체인으로 바로 간다.
• 범위가 불명확하면 대화 맥락에서 가장 좁고 안전한 범위를 추론한다. 그래도 모호하면 범위를 묻는다.

Occam Gate

새 컴포넌트, 플래그, 브랜치, 타입, 파일, 절차를 만들기 전에 반드시 답한다.

1. 기존 메커니즘으로 해결 가능한가?
   - Yes: 기존 메커니즘을 수정한다. 새 개념을 만들지 않는다.
   - No: 2번으로 간다.

2. 새 개념이 없으면 어떻게 되는가?
   - "그냥 안 된다": 3번으로 간다.
   - "기존 것이 조금 이상해진다": 기존 것을 고친다.

3. 이 변경이 시스템의 개념 수를 줄이는가, 늘리는가?
   - 줄인다: 진행 가능.
   - 늘린다: 정말 필요한지 재검토한다. 다른 프로젝트/흐름에서도 필요한 개념인지 확인한다.

Occam Gate를 통과하지 못하면 새 개념을 만들지 말고 기존 구조 안에서 해결한다.

필터 체인

정리 대상 범위 안의 항목을 먼저 나열하고, 각 항목의 역할을 한 문장으로 설명한다. 그런 다음 아래 질문을 순서대로 적용한다. 앞 질문에서 탈락하면 뒤 질문은 묻지 않는다.

1. 쓸모가 있나?  (Existence)
   - No: 제거 후보

2. 형태가 맞나?  (Fit)
   - No: 재설계 후보

3. 줄일 수 있나? (Volume)
   - Yes: 축소 후보

4. 더 적게 할 수 있나? (Efficiency)
   - Yes: 병합/단순화 후보

판단이 모호하면 Lean 7 Muda로 분류한다:

• 과잉생산: 미리 만든 것
• 재고: 쌓여 있지만 쓰이지 않는 것
• 과잉처리: 필요 이상으로 정교한 것
• 운반: 불필요한 복사/이동
• 동작: 반복 입력/반복 조작
• 대기: 결정 대기로 멈춘 것
• 결함: 현실과 맞지 않아 보정이 필요한 것

Chesterton's Fence

제거·축소·병합 후보마다 이유를 확인한다.

왜 만들었는지 아는가?
  - Yes: 그 이유가 아직 유효한가?
    - No: 제거/축소/병합 확정
    - Yes: 유지
  - No: git log, 문서, 주변 코드, 대화 맥락을 조사한다.

이유를 알 수 없고 위험이 크면 제거하지 않는다. 대신 조사 결과와 불확실성을 보고한다.

실행 원칙

• 제거 확정: 직접 삭제한다.
• 축소/병합 확정: 직접 수정한다.
• 유지 판정: 건드리지 않는다.
• 사용자의 작업공간 규칙이 확인 게이트를 요구하면, 변경 전 계획과 검증 방법을 요약하고 승인을 기다린다.
• 변경이 있으면 해당 영역의 기존 검증 수단(테스트, 타입체크, 빌드, 문서 렌더링 등)을 돌린다.

변경 후 검증

각 변경 건마다 되묻는다.

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

오히려 복잡해졌으면 해당 변경만 되돌리고 이유를 기록한다. 되돌림은 실패가 아니라 더 빼면 악화된다는 수렴 신호다.

보고 형식

변경 대상은 구체적으로 보고하고, 유지 항목은 카운트와 카테고리 중심으로 짧게 보고한다.

# /doubt 결과

## 변경
| 항목 | 판정 | 이유 | 검증 |
|------|------|------|------|
| [항목] | 제거 / 축소 / 병합 | [이유] | 확정 / 되돌림([이유]) |

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

## Before -> After
- 항목 수: X -> Y (-Z)