critical-think

Critical Think

주장을 "그럴듯함"에서 떼어내 반증 가능한 형태로 만들고, 검증 설계가 결론을 미리 품지 않았는지 감사한 뒤, 가능하면 직접 관찰로 확인한다. 이전 단계 산출물 없이 다음 단계 진행 금지 — 분해 안 된 주장은 검증 불가, 반증 설계 없는 "검증함" 선언은 확증편향의 다른 이름이다.

핵심 분리: 논리적으로 유효한가(추론 타당성) ≠ 실제로 유효한가(증거). 둘을 섞으면 우아한 추론이 사실로 둔갑한다.

쓰는 경우

• "이 개선/변경이 유효한가", "이 주장이 맞나", "이 결정 근거가 튼튼한가"
• AI(또는 본인)가 내놓은 결론을 그대로 채택하기 전 점검
• 그럴듯한데 근거가 불안한 합의·계획

쓰지 않는 경우

• 답을 모르는 상태의 탐구 학습 (검증할 주장이 아직 없음)
• 모호한 요구사항 구체화 → requirements-analysis
• 코드 결함 찾기 → 코드 리뷰 · 버그 디버깅 → systematic-debug

---

Phase 0 — 주장 고정 (Claim)

검증 대상을 반증 가능한 한 문장으로 압축한다. 먼저 주장(결론)과 그것을 떠받치는 근거(전제)를 분리해 식별한다 — 무엇이 입증 대상이고 무엇이 지지대인지 섞이면 이후가 전부 흐려진다. "더 좋다", "효과적이다" 같은 모호어는 측정 가능한 술어로 바꾼다. 압축이 안 되면 여기서 정지 — 검증할 대상이 정의되지 않은 것이다.

타입 분류 (검증 방법을 결정):

• 논리(연역) — 추론만으로 참/거짓. 전제 + 추론 타당성을 본다.
• 경험(귀납) — 측정·관찰이 필요. Phase 4~6에서 테스트.
• 정의/규범 — 합의·가치 선택으로 참. "테스트 대상 아님"으로 표기하고 정의를 명시해 합의 여부만 따진다.

타입 혼동이 1순위 오류다 ("추론이 우아하니 사실").

---

Phase 1 — 분해 (Decomposition)

복합 주장을 독립 검증 가능한 원자 하위주장으로 쪼갠다. 쪼개지지 않는 주장은 검증할 수 없다. 하위주장은 서로 다른 결론(하나는 참, 하나는 거짓)이 나올 수 있어야 한다.

분해는 MECE로 — 하위주장끼리 겹치지 않고(상호배타), 합치면 원주장을 빠짐없이 덮어야(전체포괄) 한다. "왜?"를 반복하는 로직 트리로 계층화하면 누락이 드러난다.

산출 고정: 이 계층화를 머릿속에만 두지 말고 트리 1장으로 명시 산출한다 — 주장이 "왜"(원인·근거 계열)로 갈리면 Why tree, "무엇으로 구성"이면 What tree.

<원주장 (반증 가능한 한 문장)>
└ 왜? / 무엇으로 구성?
  ├ 하위주장A  (MECE)
  ├ 하위주장B
  └ 하위주장C
→ 각 잎 = Phase 4에서 독립 반증 설계할 단위

---

Phase 2 — 전제·가정·맥락 (Assumptions & Context)

"이게 참이려면 무엇이 참이어야 하는가"를 나열한다. 그중 **깨지면 전체가 무너지는 가정 1개(load-bearing)**를 식별한다. 검증 자원은 거기에 먼저 쓴다. 숨은 전제를 안 캐면 결론이 옳아도 이유가 틀린다.

맥락: 누가 이 주장을 하며 무엇을 얻는가(이해관계), 어떤 프레이밍·생략·배경이 깔려 있나. 발신자가 결과의 이해당사자거나(본인 작업 방어·벤더), 비위 맞추도록 최적화된 출처(AI 포함)면 증거 기준을 높인다.

---

Phase 3 — 스틸맨 + 최강 반례 (Steelman & Counter)

먼저 주장의 가장 강한 버전을 진술한다 (허수아비 금지 — 약한 버전을 깨는 건 비판이 아니다). 그 다음 그것을 무너뜨릴 가장 강한 반증 시나리오를 세운다.

---

Phase 4 — 반증 설계 (Falsification) ★

"어떤 관찰이 이 주장을 틀렸다고 증명하는가?" 답이 하나도 없으면 그건 주장이 아니라 신념이다 → 검증불가로 표기하고 경고한다 (Popper 게이트).