FBZ_40 — 조사 프로토콜 (investigation protocol)

한 줄 요약

버그를 만났을 때 “제일 그럴듯한 원인에 바로 패치”하지 않고, 재현 → 여러 가설 → 증거 → 인과사슬 → 전후 검증 → 기각 보고 라는 6단계 수사 절차를 강제하는 팩이다. 왜 배우나 — AI가 진짜 결함을 잡게 하려면, 증상을 가리는 임시방편과 근본 수리를 구분하는 “탐정의 규율”을 절차로 심어야 하기 때문이다.

그림

flowchart TD
    A["버그/에러 신호 감지<br/>(debug, error, crash...)"] --> B["1. 재현 먼저<br/>실패 케이스를 실제로 돌려본다"]
    B --> C["2. 경쟁 가설 3개 이상<br/>한 가지로 단정하지 않는다"]
    C --> D["3. 가설별 증거 수집<br/>코드를 끝에서 끝까지 정독"]
    D --> E["4. 인과사슬 끝까지 추적<br/>증상 제거 ≠ 결함 제거"]
    E --> F["5. 전후 검증<br/>수정 전 원인 확정 / 수정 후 소멸 입증"]
    F --> G["6. 기각한 가설 보고<br/>왜 버렸는지 증거와 함께"]
    G --> H["진짜 결함 제거 완료"]

쉽게 풀기

이 팩은 한마디로 “AI를 성급한 수리공이 아니라 꼼꼼한 탐정으로 만드는 매뉴얼” 이다.

성급한 수리공은 이렇게 한다. 화재경보가 울리면 “아, 시끄러우니까” 하고 경보기 배터리를 빼버린다. 소리는 멎었다. 하지만 불은 여전히 어딘가에서 타고 있다. AI도 디버깅할 때 똑같은 실수를 한다. 로그에 빨간 글씨로 제일 크게 뜬 에러를 보고 “이게 범인이군” 하며 거기만 고친다. 테스트는 통과한다. 그런데 진짜 결함은 그대로 숨어 있다.

조사 프로토콜은 이걸 막기 위해 탐정 수사 6단계를 강제한다.

1. 재현 먼저 — 추리하기 전에 현장부터 본다. 가설을 세우기 전에 실패하는 상황을 직접 돌려서 실제 출력을 눈으로 확인한다. 머릿속 상상으로 범인을 정하지 않는다.
2. 용의자 최소 3명 — 탐정은 한 명만 의심하지 않는다. 가장 눈에 띄는 단서(로그에서 제일 잘 보이는 신호)가 진범이라는 보장은 없다. 그래서 경쟁하는 가설을 최소 셋 먼저 세우고 시작한다.
3. 가설마다 증거 수집 — 각 용의자에 대해 “이게 맞다면 무엇이 보여야 하나 / 아니라면 무엇이 보여야 하나”를 정한 뒤, 관련 코드를 처음부터 끝까지 읽어 증거를 모은다. 증거가 쌓이는 동안 가설별 확신도를 계속 갱신한다.
4. 인과사슬 끝까지 — 첫 번째 그럴듯한 원인에서 멈추지 않는다. “그 원인은 또 무엇 때문에 생겼나?”, “눈에 보이는 방아쇠만 제거하면 결함이 잠복으로 남지 않나?”를 끝까지 묻는다. 테스트를 통과시키는 수정이 곧 결함을 없애는 수정은 아니다.
5. 전후 검증 — 코드를 건드리기 전에 증거로 근본원인을 확정하고, 수정 후에는 “이 환경에서 안 터지는” 정도가 아니라 “실패 모드 자체가 사라졌다”는 것을 입증한다.
6. 기각 보고 — 수사 끝에 버린 용의자들도 보고서에 적는다. “왜 그 가설을 기각했는지” 증거까지 함께 남겨서, 추론 과정 전체를 눈에 보이게 한다.

리뷰일 때의 변형

코드 리뷰에 쓸 때는 순서가 살짝 바뀐다. 확신이 낮은 발견까지 일단 전부 보고하고, 걸러내는 일은 별도 단계에서 한다 (SKILL.md §2). 수사 단계에서 미리 자기검열하지 말라는 뜻이다.

핵심 정리

#	단계	한 줄 핵심
1	재현 먼저	가설 전에 실제 출력을 관측
2	경쟁 가설 ≥3	단일 가설 금지, 최다 신호 ≠ 결론
3	가설별 증거	확증/반증 기준 정의 + 코드 정독
4	인과사슬 끝까지	증상 제거 ≠ 결함 제거
5	전후 검증	전: 원인 확정 / 후: 실패모드 소멸 입증
6	기각 보고	버린 가설 + 기각 증거 명시

두 가지 핵심 통찰

• 증상 제거 ≠ 결함 제거 — 소리를 멈추는 것과 불을 끄는 것은 다르다.
• 로그에서 제일 잘 보이는 신호가 근본원인은 아니다 — 가장 큰 단서를 “결론”이 아니라 “여러 가설 중 하나”로 다뤄야 한다.

이 팩이 README 분류에서 차지하는 위치도 알아두면 좋다.

• “강한 모델이 이미 하는 것과 동급의 절차” 등급 — 새로운 능력을 주는 게 아니다.
• 똑똑한 모델이라면 본래 할 수 있는 행동을, 누구에게나 절차로 강제해 옮겨 심는다.
• 그래서 능력이 아니라 “규율”이 핵심이다.

실제 예시

팩 전문 — AI에게 주입되는 실제 텍스트다.

<!-- packs/investigation-protocol.txt (전문) -->
<investigation_protocol>
When debugging, follow this discipline:
 
1. Reproduce first. 가설 세우기 전에 실패 케이스를 돌려 실제 출력을 읽어라.
 
2. 경쟁 가설을 여러 개 — 최소 셋 — 먼저 세운다. 알려진 실패에 패턴매칭되는 증상이
   다른 원인일 수 있다. 로그에서 가장 잘 보이는 신호가 반드시 근본원인은 아니다 —
   결론이 아니라 여러 가설 중 하나로 다뤄라.
 
3. 각 가설마다 확증/반증할 증거가 무엇인지 정하고, 관련 코드 경로를 끝에서 끝까지 읽어
   그 증거를 모은다. 증거가 쌓이는 동안 가설별 확신도를 추적하라.
 
4. 인과사슬을 끝까지 추적. 첫 그럴듯한 원인에서 멈추지 마라: 무엇이 그 원인으로 하여금
   이 증상을 만들게 했는지, 보이는 트리거만 제거하면 결함이 잠복으로 남는지 물어라.
   테스트를 통과시키는 수정이 곧 결함을 제거하는 수정은 아니다.
 
5. 전후 검증. 코드 바꾸기 전에 증거로 근본원인을 확정하고, 수정 후엔 실패 모드 자체가
   사라졌음을 — 이 환경에서 트리거 조건이 더는 안 나는 정도가 아니라 — 입증하라.
 
6. 보고서에 기각한 가설과 그 기각 증거를 적어라.
</investigation_protocol>

이 팩이 AI에 들어가는 경로(생명주기·트리거·주입)는 세 갈래다.

# 1) 자동 트리거 — hooks/router.sh (debug/bug/error/crash 등 감지)
[fablize:investigation] Debugging/root-cause signal — follow $PACKS/investigation-protocol.txt:
  reproduce first, form 3+ competing hypotheses, gather evidence per hypothesis,
  trace the full causal chain, verify before/after, and report the hypotheses you rejected.
 
# 2) always-on — setup/fablize-block.md (상주하는 한 줄)
[debugging / test failure / unknown cause / review] Follow .../investigation-protocol.txt:
  reproduce first → 3+ competing hypotheses → evidence per hypothesis → full causal chain
  → verify before/after → report rejected hypotheses.
 
# 3) 스킬 — skills/fablize/SKILL.md §2 가 이 팩을 Read해서 따르라 지시

직접 쓸 수 있는 축약 템플릿(다른 시스템에 이식할 때).

<investigation>
디버깅 시: 1) 먼저 재현해 실제 출력 관측 2) 경쟁 가설 ≥3 세우고 시작
3) 가설별 확증/반증 증거 정의 후 코드 정독, 확신도 추적
4) 인과사슬 끝까지(증상 제거 ≠ 결함 제거, 잠복 확인)
5) 수정 전 원인 확정·수정 후 실패모드 소멸 입증 6) 기각한 가설+증거 보고
</investigation>

설계 포인트: ①가설 다양화 강제(≥3) ②”최다 신호 ≠ 근본원인” 명시 ③증상/결함 분리 ④기각 가설 보고로 추론 가시화.

주입 방식과 행동 변화

• 주입 방식: lazy 로딩 — 평소엔 경로+요약만 넣고, 필요할 때 전문을 Read 한다(→ FBZ_10_훅-라우터-주입).
• 행동 변화: “첫 그럴듯한 원인에 바로 패치” → “재현·복수 가설·증거·인과사슬·전후검증·기각보고”. 가설 추적은 모델이 출력으로 가시화한다.

요약 & 셀프체크

3줄 요약

• 조사 프로토콜은 디버깅/근본원인/리뷰 때 따르는 6단계 수사 규율 팩이다.
• 핵심은 “증상 제거 ≠ 결함 제거”, “제일 잘 보이는 신호가 진범은 아니다” 두 통찰.
• 능력을 더하는 게 아니라, 강한 모델이 본래 하는 절차를 누구에게나 강제로 옮겨 심는다.

셀프체크

• 6단계 중 “테스트를 통과시키는 수정”으로는 부족하다고 말하는 단계는 몇 번이고, 그 이유는?
• 왜 가설을 “최소 3개”나 세우라고 강제할까? 한 개만 조사하면 무엇이 위험한가?
• 리뷰에 쓸 때는 일반 디버깅과 절차가 어떻게 달라지는가?

연결

FBZ_개요 · _분석축_루브릭 · FBZ_10_훅-라우터-주입 · FBZ_30_검증접지-팩 · FBZ_60_스킬-운영블록

근거 파일

• /home/seunghyeong/harness-fablize/packs/investigation-protocol.txt
• 라우팅: hooks/router.sh (22–25행) · 규범: skills/fablize/SKILL.md §2, setup/fablize-block.md

Codex 교차검증 (기존 분석 보존)

본 노트의 6단계 절차, 자동 트리거 키워드(debug/bug/error/traceback/stack trace/crash/failing/not working), always-on 상주 줄, SKILL.md §2 지시, lazy 주입 방식은 소스 파일(packs/investigation-protocol.txt, hooks/router.sh, skills/fablize/SKILL.md, setup/fablize-block.md)과 대조해 일치 확인됨. 핵심 통찰 “증상 제거 ≠ 결함 제거”, “최다 신호 ≠ 근본원인”은 팩 원문 2·4단계에 명시된 문장 그대로다.