원인을 모르거나 확신이 없는 상황을 경쟁 가설과 반증 실험으로 체계적으로 파헤칩니다. Claude에게 말로 부탁하면 됩니다 — “이 에러 원인이 뭐야?”, “왜 이렇게 느리지 분석해줘”처럼요.
빠른 시작
이 에러 원인 파헤쳐줘
왜 이렇게 느리지 조사해줘
이 설계가 맞는지 확인해줘
이 메트릭 급등이 왜 일어난 거지?사용자 주장(“배포 때문일 거야”)도 사실이 아닌 가설로 취급해, 경쟁 가설을 세우고 반증 실험으로 걸러냅니다.
활용 시나리오
버그·에러 근본 원인 분석
스택 트레이스·에러 메시지가 있을 때 최소 2개의 경쟁 가설을 세우고 반증 실험으로 원인을 특정합니다.
이 ImportError 원인 찾아줘성능 병목 조사
느린 구간·지연 원인을 측정 기반 가설로 좁혀갑니다.
API가 배포 후 갑자기 10배 느려졌어. 원인 분석해줘설계·주장 검증
트레이드오프 분석이나 “이 방식이 맞는지”를 확인합니다. 불확실하면 억지로 결론 내지 않고 “낮은 신뢰도”로 보류합니다.
이 모놀리스를 마이크로서비스로 분리하는 게 맞을까?메트릭·현상 해석
원인을 모르는 현상에 대해 다중 해석을 생성하고 반증으로 좁혀갑니다.
대시보드 API 요청 수가 갑자기 10배 늘었는데 뭘 의미하지?조사 깊이 조정
조사 범위를 말로 유도할 수 있습니다.
| 이렇게 말하면 | 동작 |
|---|---|
| ”간단히”, “빠르게” | 경량 모드 — 도구 호출 1~3회, 가설 최소 2개 |
| ”깊게”, “철저히” | 완전 모드 — 도구 호출 5~15회, 가설 최소 3개, 주요 가설당 반증 2회 |
단일 파일·명확한 스택 트레이스·결정론적 재현이면 자동으로 경량 모드를 선택합니다. 교차 모듈·재현 불가·간헐적 오류면 자동으로 완전 모드를 선택합니다.
조사 유형 지정
조사 유형을 말로 지정할 수 있습니다.
| 이렇게 말하면 | 조사 유형 |
|---|---|
| ”에러”, “버그”, “크래시” | 버그 근본 원인 분석 |
| ”느린”, “지연”, “병목” | 성능 측정 기반 가설 검증 |
| ”설계”, “아키텍처”, “패턴” | 트레이드오프 반증 분석 |
| ”맞는지”, “확인”, “검증” | 주장 반증 실험 |
| ”왜”, “어떻게”, “설명해줘” | 다중 해석 생성 |
조사 보고서 저장
보고서를 파일로 보관하고 싶으면 저장 경로를 함께 말하세요.
이 에러 원인 분석해서 reports/bug-analysis.md로 저장해줘출력 구조
모든 조사는 5개 섹션을 가진 구조화 보고서로 출력됩니다.
- Observations — 해석과 분리된 원시 관찰
- Hypotheses — 최소 2개(완전 모드 3개 이상) 경쟁 가설 + 반증 시도 횟수 테이블
- Experiments — 가설을 반증하려는 실험 기록 (확증이 아님)
- Conclusion — 보정된 신뢰도(
speculation/low/medium/high)와 권장 조치 - Remaining Uncertainty — 남아있는 불확실성 명시
팁
- 사용자 주장도 가설로 취급: “배포 때문일 거야”는 검증 대상 H1이지 사실이 아닙니다. 시간적 상관관계가 인과관계라고 단정하지 않습니다.
- 신뢰도별 조치 차등화: 낮은 신뢰도에서 구조적 수정을 하지 않습니다. “높은 신뢰도”는 3회 이상 반증 통과 + 모든 경쟁 가설 제거 시에만 부여됩니다.
- 모든 가설 제거 시 피벗: 실험 결과로 활성 가설이 전부 탈락하면 놀라움을 인정하고 관찰 단계로 복귀합니다. 제거된 가설에 결과를 끼워맞추지 않습니다.
제한사항
- ⚠️ “높은 신뢰도”는 3회 이상 반증 통과 + 모든 경쟁 가설 제거 시에만 부여됩니다. 1회 실험 후 높은 신뢰도라고 주장하는 결과는 잘못된 사용입니다.
- ⚠️ “낮은 신뢰도”는 실패가 아니라 정직한 판단입니다. 근거가 부족하면 억지로 결론을 만들지 않고 보류합니다.
- ⚠️ 도메인 지식·외부 맥락이 없으면 조사 범위가 제한됩니다. 법률 조항·외부 API 장애 등은 관련 문서나 공지가 있어야 결론을 낼 수 있습니다.
- ⚠️ 이 스킬이 단정하는 모든 것도 가설입니다. 최종 판단은 사용자의 추가 검증으로 보완하세요.