hypothesis-tree

name	hypothesis-tree
description	가설 트리 관리 — 카테고리, 상태 전이, 분기 규칙, 종료 조건, 우선순위 결정, 전체 기각 시 재생성. 가설 생성, 우선순위 결정, 가설 검증, 가설 분기, 종료 판단 단계에서 가설을 어떻게 구조화하고 관리해야 하는지 판단할 때 반드시 이 스킬을 참조한다. 가설 생성, 검증, 분기, 종료 판단이 언급될 때 사용한다.

가설 트리 관리

상태 용어

• 문서·프롬프트·UI에서는 "채택(Accepted)", "기각(Rejected)", "추가조사(Needs Investigation)", **"종료(Closed)"**로 표기한다.
• JSON status 값은 하위 호환을 위해 CONFIRMED / REJECTED / NEEDS_INVESTIGATION / CLOSED를 그대로 사용한다. "채택"은 CONFIRMED 상태의 의미론적 표기일 뿐이다.

가설 카테고리

카테고리	설명	대표적 근본원인
DEPLOYMENT	최근 코드/설정 배포 관련	비효율 코드 경로, 리소스 누수, 설정 오류
INFRASTRUCTURE	AWS 인프라 수준 이슈	호스트 열화, AZ 장애, 네트워크 파티션
TRAFFIC	트래픽 패턴 변화	DDoS, 트래픽 급증, 봇 크롤링
DEPENDENCY	외부/내부 의존 서비스 장애	DB 지연, 외부 API 타임아웃, DNS 실패
CONFIGURATION	런타임 설정 문제	잘못된 환경변수, 리소스 한도, IAM 정책

가설 상태 전이

PENDING ──(증거 수집)──> NEEDS_INVESTIGATION ──(추가 증거)──> CONFIRMED (채택)
                                      │                          ↑
                                      │                  (신뢰도 ≥ 0.8)
                                      │
                                      └──(하위 가설 생성)──> [하위 가설들]

PENDING ──(증거 수집)──> REJECTED (기각, 신뢰도 ≤ 0.3)
PENDING/NEEDS_INVESTIGATION ──(Accepted Review Gate 자동)──> REJECTED (기각)

PENDING / NEEDS_INVESTIGATION ──(루프 종료, 예산 소진)──> CLOSED (종료)

종료 상태는 3가지: CONFIRMED(채택), REJECTED(기각), CLOSED(종료). 보고서 생성 전 모든 가설이 이 셋 중 하나여야 한다. CLOSED는 예산 소진 등으로 검증이 완료되지 못한 가설에 사용한다.

가설 분기 규칙

부모 가설이 NEEDS_INVESTIGATION (신뢰도 0.3-0.8)일 때:

1. 2-3개 하위 가설을 생성한다
2. 각 하위 가설은 부모보다 더 구체적이고 검증 가능해야 한다
3. 이미 기각된 가설과 중복 금지
4. 카테고리는 부모와 동일하게 유지하되, 증거가 다른 카테고리를 시사하면 변경 가능
5. 최대 깊이 3레벨 (루트 → 자식 → 손자)

5 Whys 사고로 한 단계 내려가기

분기는 본질적으로 부모 가설에 대한 "왜 그게 발생했는가?"의 답이다. 다음 가드레일을 적용한다:

• 자식 가설이 "휴먼 에러"·"운영자 실수"로 귀결되면 한 번 더 분기해 시스템·프로세스·설계 결함까지 내려간다 (검증 부재? 권한 과다? 자동화 부족?). "사람이 실수했다" 는 종착점이 아니라 다음 "왜?"의 신호다.
• 단일 원인 가정 회피 — 부모가 다요인 의심이면 카테고리가 다른 자식 가설을 함께 두어 multi-causal 가능성을 보존한다.
• 각 자식의 required_evidence는 부모보다 좁고 구체적이어야 한다 (예: 부모 "DB 지연" → 자식 "특정 쿼리 ID의 plan 변경").
• Blameless — 사람·팀을 특정하지 않는다.

분기 예시

[DEPLOYMENT] CPU 급등의 원인이 최근 배포 (신뢰도: 0.6, NEEDS_INVESTIGATION)
├── [DEPLOYMENT] 새 코드에 CPU 집약적 루프/알고리즘 도입 (신뢰도: 0.4)
├── [DEPLOYMENT] 새 의존성 라이브러리의 CPU 사용량 증가 (신뢰도: 0.3)
└── [CONFIGURATION] 배포 시 CPU 제한/메모리 설정 변경 (신뢰도: 0.3)

종료 조건 (6가지, OR)

조건	설명	행동
REVIEW_GATE_EARLY_EXIT	Accepted Review Gate: 채택 가설 최고 신뢰도 ≥ 0.9	매 루프 진입 직전 평가 → 즉시 종료 → 보고서 생성
REVIEW_GATE_GRACE_EXHAUSTED	비확장 모드 2회 연속에도 < 0.9	즉시 종료 → 현재 채택 가설로 보고서
CONFIRMED	검증 후 가설 신뢰도 ≥ 0.9	루프 종료 → 보고서 생성
ALL_REJECTED	모든 가설 기각, 새 단서 없음	재생성 시도 (최대 2회). 비확장 모드에서는 재생성 스킵하고 채택 가설 기반 보고서
TIMEOUT	분석 8분 초과	루프 종료 → 현재 최선 결과로 보고서
MAX_LOOPS	검증 루프 3회 완료	루프 종료 → 현재 최선 결과로 보고서
MAX_DEPTH	가설 트리 깊이 3 도달	더 이상 분기하지 않음, 현재 가설로 판단

Accepted Review Gate

매 루프 진입 직전에 메인 에이전트가 순수 로직으로 평가하는 게이트. 기존 채택 가설이 있을 때 추가 탐색 필요성을 판단한다.

채택 가설 최고 신뢰도	결과
≥ 0.9	early_exit — 즉시 보고서 생성
0.8 ~ 0.9	expansion_blocked — 증거 보강만 허용, 새 분기·재생성 금지
< 0.8 or 없음	통상 진행

Accepted-유사 자동 기각: 채택 가설이 존재하면 PENDING/NEEDS_INVESTIGATION 중 (같은 category + description Jaccard ≥ 0.6)인 항목은 자동 REJECTED 처리. 동일 원인 영역의 중복 분기를 억제한다.

우선순위 결정 기준

1. 신뢰도: 높은 신뢰도 가설 우선
2. 카테고리 기본 순서 (동률 시): DEPLOYMENT > INFRASTRUCTURE > TRAFFIC > DEPENDENCY > CONFIGURATION
   • 근거: 배포 변경이 가장 흔한 장애 원인이며, 검증이 가장 빠름
3. 알람 유형 보정:
   • CPU/메모리 알람 → DEPLOYMENT, TRAFFIC 가산
   • 커넥션/지연 알람 → DEPENDENCY, CONFIGURATION 가산
   • 에러율 알람 → DEPLOYMENT, INFRASTRUCTURE 가산

전체 기각 시 재생성

1. 기각된 가설들의 설명을 수집한다
2. "이전에 기각된 가설: [목록]"을 포함하여 새 가설을 생성한다
3. 새 가설은 기각된 방향과 다른 관점에서 접근해야 한다
4. 최대 2회 재생성. 이후에도 확정 없으면 최고 신뢰도 가설을 "가장 유력한 후보"로 선정