---
title: "investigate"
description: "경쟁 가설과 반증 실험으로 근본 원인을 체계적으로 조사하는 스킬입니다. \"왜 이렇게 느리지?\", \"이 에러 원인이 뭐야?\", \"원인 분석해줘\"처럼 말하면 됩니다. 추측 대신 증거 기반 결론을 제공합니다."
pack: itda-research
slug: investigate
status: active
tags: ["investigate", "debugging", "hypothesis", "falsification", "scientific method", "root cause analysis"]
---
원인을 모르거나 확신이 없는 상황을 경쟁 가설과 반증 실험으로 체계적으로 파헤칩니다.
**Claude에게 말로 부탁하면 됩니다** — `/investigate 이 에러 원인이 뭐야?`, `/investigate 왜 이렇게 느리지 분석해줘`처럼요.

---

## 빠른 시작

```
/investigate 이 에러 원인 파헤쳐줘
/investigate 왜 이렇게 느리지 조사해줘
/investigate 이 설계가 맞는지 확인해줘
/investigate 이 메트릭 급등이 왜 일어난 거지?
```

사용자 주장("배포 때문일 거야")도 사실이 아닌 **가설**로 취급해, 경쟁 가설을 세우고 반증 실험으로 걸러냅니다.

---

## 활용 시나리오

### 버그·에러 근본 원인 분석

스택 트레이스·에러 메시지가 있을 때 최소 2개의 경쟁 가설을 세우고 반증 실험으로 원인을 특정합니다.

```
/investigate 이 ImportError 원인 찾아줘
```

### 성능 병목 조사

느린 구간·지연 원인을 측정 기반 가설로 좁혀갑니다.

```
/investigate API가 배포 후 갑자기 10배 느려졌어. 원인 분석해줘
```

### 설계·주장 검증

트레이드오프 분석이나 "이 방식이 맞는지"를 확인합니다. 불확실하면 억지로 결론 내지 않고 "낮은 신뢰도"로 보류합니다.

```
/investigate 이 모놀리스를 마이크로서비스로 분리하는 게 맞을까?
```

### 메트릭·현상 해석

원인을 모르는 현상에 대해 다중 해석을 생성하고 반증으로 좁혀갑니다.

```
/investigate 대시보드 API 요청 수가 갑자기 10배 늘었는데 뭘 의미하지?
```

---

## 조사 깊이 조정

조사 범위를 말로 유도할 수 있습니다.

| 이렇게 말하면 | 동작 |
|--------------|------|
| "간단히", "빠르게" | 경량 모드 — 도구 호출 1~3회, 가설 최소 2개 |
| "깊게", "철저히" | 완전 모드 — 도구 호출 5~15회, 가설 최소 3개, 주요 가설당 반증 2회 |

단일 파일·명확한 스택 트레이스·결정론적 재현이면 자동으로 경량 모드를 선택합니다. 교차 모듈·재현 불가·간헐적 오류면 자동으로 완전 모드를 선택합니다.

---

## 조사 유형 지정

조사 유형을 말로 지정할 수 있습니다.

| 이렇게 말하면 | 조사 유형 |
|--------------|----------|
| "에러", "버그", "크래시" | 버그 근본 원인 분석 |
| "느린", "지연", "병목" | 성능 측정 기반 가설 검증 |
| "설계", "아키텍처", "패턴" | 트레이드오프 반증 분석 |
| "맞는지", "확인", "검증" | 주장 반증 실험 |
| "왜", "어떻게", "설명해줘" | 다중 해석 생성 |

---

## 조사 보고서 저장

보고서를 파일로 보관하고 싶으면 저장 경로를 함께 말하세요.

```
/investigate 이 에러 원인 분석해서 reports/bug-analysis.md로 저장해줘
```

---

## 출력 구조

모든 조사는 5개 섹션을 가진 구조화 보고서로 출력됩니다.

- **Observations** — 해석과 분리된 원시 관찰
- **Hypotheses** — 최소 2개(완전 모드 3개 이상) 경쟁 가설 + 반증 시도 횟수 테이블
- **Experiments** — 가설을 **반증**하려는 실험 기록 (확증이 아님)
- **Conclusion** — 보정된 신뢰도(`speculation`/`low`/`medium`/`high`)와 권장 조치
- **Remaining Uncertainty** — 남아있는 불확실성 명시

---

## 팁

- **사용자 주장도 가설로 취급**: "배포 때문일 거야"는 검증 대상 H1이지 사실이 아닙니다. 시간적 상관관계가 인과관계라고 단정하지 않습니다.
- **신뢰도별 조치 차등화**: 낮은 신뢰도에서 구조적 수정을 하지 않습니다. "높은 신뢰도"는 3회 이상 반증 통과 + 모든 경쟁 가설 제거 시에만 부여됩니다.
- **모든 가설 제거 시 피벗**: 실험 결과로 활성 가설이 전부 탈락하면 놀라움을 인정하고 관찰 단계로 복귀합니다. 제거된 가설에 결과를 끼워맞추지 않습니다.

---

## 제한사항

- ⚠️ **"높은 신뢰도"는 3회 이상 반증 통과 + 모든 경쟁 가설 제거 시에만 부여**됩니다. 1회 실험 후 높은 신뢰도라고 주장하는 결과는 잘못된 사용입니다.
- ⚠️ **"낮은 신뢰도"는 실패가 아니라 정직한 판단**입니다. 근거가 부족하면 억지로 결론을 만들지 않고 보류합니다.
- ⚠️ **도메인 지식·외부 맥락이 없으면 조사 범위가 제한**됩니다. 법률 조항·외부 API 장애 등은 관련 문서나 공지가 있어야 결론을 낼 수 있습니다.
- ⚠️ **이 스킬이 단정하는 모든 것도 가설**입니다. 최종 판단은 사용자의 추가 검증으로 보완하세요.