빠른 시작#

원인을 모르거나 확신이 없는 상황을 반증 기반으로 파헤치는 가장 간단한 방법입니다.

이 에러 원인 파헤쳐줘

왜 이렇게 느리지 조사해줘

이 설계가 맞는지 확인해줘

이 메트릭 급등이 왜 일어난 거지?

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

활용 시나리오#

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

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

이 ImportError 원인 찾아줘

설계·주장 검증 (arch / verify)#

트레이드오프 분석이나 “이 방식이 맞는지”를 확인합니다. 불확실하면 억지로 결론 내지 않고 low로 보류합니다.

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

메트릭·현상 해석 (interpret)#

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

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

주요 옵션#

플래그	설명	사용 시점
--depth simple	경량 모드 강제 (1–3 도구 호출)	단일 파일, 명확한 스택 트레이스, 결정론적 재현
--depth full	완전 모드 강제 (5–15 도구 호출)	교차 모듈, 재현 불가, 간헐적, 복잡 도메인
--type bug | perf | arch | verify | interpret	조사 유형 강제 분류	로그가 애매하거나 키워드 자동 감지가 빗나갈 때
--save <path>	구조화 보고서를 .md 파일로 저장	장기 추적, 팀 공유, 재발 시 참조용

미지정 시 토픽 키워드로 --depth, --type을 자동 감지하고, --save 미지정 시 채팅에 인라인 출력합니다.

출력 구조#

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

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

팁#

• 사용자 주장도 가설로 취급: “배포 때문일 거야”는 검증 대상 H1이지 사실이 아닙니다. 시간적 상관관계가 인과관계라고 단정하지 않습니다.
• 신뢰도 등급별 조치 차등화: low에서 구조적 수정 금지, medium은 제한 배포 + 모니터링, high만 자신 있게 커밋. 1회 실험 후 high 주장은 금지입니다.
• 경량/완전 모드 유도: “간단히”, “빠르게”는 --depth simple, “깊게”, “철저히”는 --depth full로 매핑됩니다. 자동 감지가 빗나가면 플래그로 강제 지정하세요.
• 모든 가설 제거 시 중간 피벗: 실험 결과로 활성 가설이 전부 탈락하면 놀라움을 인정하고 Step 1 Observe로 복귀합니다. 제거된 가설에 결과를 끼워맞추지 않습니다.

제한사항#

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