| 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)일 때:
- 2-3개 하위 가설을 생성한다
- 각 하위 가설은 부모보다 더 구체적이고 검증 가능해야 한다
- 이미 기각된 가설과 중복 금지
- 카테고리는 부모와 동일하게 유지하되, 증거가 다른 카테고리를 시사하면 변경 가능
- 최대 깊이 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 처리. 동일 원인 영역의 중복 분기를 억제한다.
우선순위 결정 기준
- 신뢰도: 높은 신뢰도 가설 우선
- 카테고리 기본 순서 (동률 시): DEPLOYMENT > INFRASTRUCTURE > TRAFFIC > DEPENDENCY > CONFIGURATION
- 근거: 배포 변경이 가장 흔한 장애 원인이며, 검증이 가장 빠름
- 알람 유형 보정:
- CPU/메모리 알람 → DEPLOYMENT, TRAFFIC 가산
- 커넥션/지연 알람 → DEPENDENCY, CONFIGURATION 가산
- 에러율 알람 → DEPLOYMENT, INFRASTRUCTURE 가산
전체 기각 시 재생성
- 기각된 가설들의 설명을 수집한다
- "이전에 기각된 가설: [목록]"을 포함하여 새 가설을 생성한다
- 새 가설은 기각된 방향과 다른 관점에서 접근해야 한다
- 최대 2회 재생성. 이후에도 확정 없으면 최고 신뢰도 가설을 "가장 유력한 후보"로 선정
