지식위키

fablize — Opus를 Fable처럼 (개요)

fablize — Opus를 Fable처럼 (개요)

한 줄 요약

모델의 머리를 더 좋게 만들지는 못하지만, 그 모델이 “자기 능력 천장까지” 빠짐없이 가도록 — 완수·증거·검증을 운(運)이 아니라 절차로 강제하는 Claude Code 플러그인. (fivetaku, MIT, v2.0.0)

왜 배우나 — “더 똑똑한 모델”이 아니라 “같은 모델을 끝까지 일 시키는 법”이 필요한 순간, 무엇을 절차로 강제할 수 있고 무엇은 안 되는지를 측정 기반으로 보여주는 드문 사례이기 때문이다.

그림

FBZ_개요-diagram.svg

flowchart TD
    U[사용자 프롬프트] --> R{"router.sh<br/>신호 매칭?"}
    R -->|신호 없음| B["baseline<br/>기본 동작"]
    R -->|"debug/error"| INV["investigation 팩 주입<br/>재현→가설→인과사슬"]
    R -->|"html/svg/render"| GRD["grounding 팩 주입<br/>실제 구동·관측"]
    B --> WORK[에이전트 작업]
    INV --> WORK
    GRD --> WORK
    WORK --> G["goals.py<br/>스토리 분해·증거 게이트"]
    G --> STOP{"Stop 훅<br/>finish-the-work.sh"}
    STOP -->|약속만 하고 안 끝남| RE["재engage<br/>끝까지 다시"]
    RE --> WORK
    STOP -->|증거와 함께 완료| DONE([완료])
    G -. 영속 .-> LED["(.fablize/<br/>goals.json + ledger.jsonl)"]

[!info] 항상 떠 있는 한 겹 위 흐름과 별개로, setup.sh를 한 번 돌리면 CLAUDE.md에 운영 규범 블록이 상주 주입되어 매 세션마다 규칙이 컨텍스트에 떠 있게 만들 수 있다(always-on, 선택).

쉽게 풀기

비유: 능력 좋은 신입에게 “일머리”만 옮겨 심기

똑똑한 신입 두 명이 있다. 한 명(Fable)은 “버그를 한 단계 더 파고드는 감”이 있고, 다른 한 명(Opus)은 그 감은 약하다. 그런데 fablize를 만든 사람은 실험으로 알아냈다 — 그 “파고드는 감”은 체크리스트로 옮겨지지 않는다(타고난 능력). 반면 “만든 걸 꼭 실제로 돌려봐라”, “약속했으면 끝까지 해라”, “버그는 재현부터 해라” 같은 일하는 습관(절차) 은 옮겨진다.

그래서 fablize는 욕심내지 않는다. 옮겨지는 절차만 골라 Opus에게 강제로 입힌다.

  1. 신호를 읽고 알맞은 매뉴얼만 꺼낸다. 프롬프트에 “버그”가 보이면 조사 매뉴얼을, “svg/렌더”가 보이면 검증 매뉴얼을 컨텍스트에 끼워 넣는다. 신호가 없으면 아무것도 안 끼운다(과잉 주입 방지).
  2. 일을 스토리로 쪼개고 증거를 받는다. goals.py가 작업을 순차 스토리로 나누고, 각 단계를 “증거 없이는 완료 처리 거부”한다. 특히 마지막 스토리는 “무엇을 실행해서 어떤 결과를 봤는지”가 없으면 아예 완료가 안 된다.
  3. 도중에 도망치지 못하게 막는다. “원하시면 보고서를 작성하겠습니다”처럼 말만 하고 끝내려 하면, Stop 훅이 이를 감지해 “다시 일해라”라고 되돌린다.
  4. 안 되는 건 솔직히 인정한다. 절차로 못 옮기는 “능력” 영역(정답 없는 창작 디테일, 깊은 결함 발견)은 흉내 내지 않고 “사람/상위 모델에게 넘기라”고 권고한다.

핵심은 “검증된 것만 출하” 라는 정직함이다. 효과가 입증되지 않은 아이디어는 멋져 보여도 탑재하지 않는다.

핵심 정리

영역무엇구현 위치
컨텍스트 주입신호별 최소 매칭 팩만 lazy loadrouter.sh, packs/
완수 강제조기 종료 정규식 차단·재engagefinish-the-work.sh (Stop 훅)
증거 게이트스토리 분해 + 최종 검증 거부goals.py
영속 상태append-only 감사 원장.fablize/goals.json+ledger.jsonl

[!note] “옮겨지는 것”만 탑재한다 — 통제 비교의 결론 Fable 5 vs Opus 4.8를 같은 과제로 통제 비교(A/B 19런 + 실작업 26세션, 도구 호출 약 1,500회)한 뒤 내린 결론이다.

  • 정답이 있는 닫힌 작업(코드·논리·빌드)에서는 두 모델이 사실상 동률.
  • 차이는 정답 없는 열린 작업에서만 났고, 그 정체는 “발견을 한 단계 더 따라가는 깊이” = 모델 능력.
  • 능력은 지시문/하네스로 못 옮긴다(주입 실험으로 반증 — Opus는 Fable이 찾은 결함을 재현 못 함).
  • 반면 일하는 절차(실제 구동·끝까지·체계적 조사)는 옮겨진다 → 이것만 탑재.

옮겨지나? 체크리스트

  • 검증 접지(산출물 실제 구동·관측) → verification-grounding-pack
  • 멀티스토리 완주 + 증거 게이트 → goals.py
  • 체계적 조사(재현→가설→인과사슬) → investigation-protocol
  • 조기 종료 방지 → finish-the-work.sh (Stop 훅)
  • 정답지 밖 결함 발견 → 능력 → 에스컬레이션 권고
  • 정답 없는 창작 디테일 → 능력 → 에스컬레이션 권고
  • 자발적 전파 깊이 → 능력 → 에스컬레이션 권고

[!warning] 탑재하지 않는 것 (검증분만 출하 원칙) 미검증/미미한 아이디어(말투 모방·넓은 추론 전파·무성 복구 가드·리뷰 리콜 스캔)는 탑재 안 함.

아키텍처 한눈에

[!abstract] 포지셔닝과 구조

  • 포지셔닝: Claude Code 호스트-플러그인(마켓플레이스 설치형 /plugin install fablize). 독립 에이전트 아님, Agent-OS도 아님.
  • 2계층 주입: ①자동(설치 시) — UserPromptSubmit 라우터 훅 + Stop 훅. ②always-on(선택, 1회 셋업) — setup.sh가 CLAUDE.md에 <!-- FABLIZE --> 운영 블록 상주 주입.
  • 자료 형태: 행동 규범은 .txt 팩(태그형 프롬프트 조각)으로 외부화 → 필요할 때만 읽힘(lazy). 상태 엔진은 stdlib-only Python(goals.py) — 의존성 0.
  • 언어/런타임: Bash(훅·셋업) + Python3(파싱·상태·멱등 주입) + Markdown(스킬·팩·블록). 외부 패키지 없음.

10축 점수표 — 합계 36/50 (좁고 깊은 하네스)

축점수한 줄 근거
1. 아키텍처/포지셔닝4플러그인 표준 구조, 단일 호스트 종속
2. 컨텍스트 엔지니어링5핵심 역량 — 최소 매칭 팩만 lazy 주입
3. 툴/확장3hooks·skill·command 표준, 의도적 미니멀
4. 오케스트레이션/멀티에이전트1서브에이전트·병렬 없음(순차 스토리)
5. 가드레일/안전3결정론적 Stop 훅, 안전보다 완수 가드
6. 검증 루프5최강축 — 3중 검증을 코드로 강제
7. 자기개선/반복2끝까지 반복은 있으나 자기코드 개선은 없음
8. 상태/영속성4.fablize/ append-only 원장, 세션 재개
9. 배포/DX42줄 설치·1회 1질문 셋업·멱등·백업
10. 철학/차별점5독보적 — 측정 기반 “검증분만 출하”

[!success] 강점 vs [!failure] 약점 강점 — 검증을 코드로 강제(goals.py의 최종 게이트는 권고가 아니라 sys.exit 실행 거부) · 결정론적 조기종료 차단(LLM 판단 아닌 정규식) · 과주입 방지 · 정직성의 제도화(에스컬레이션) · 의존성 0·멱등·백업.

약점 — 단일 호스트 종속(Claude Code 전용)·멀티에이전트/MCP 부재 · 휴리스틱 라우터(키워드 case 매칭 → 다국어/우회 표현에 취약) · 조기종료 훅 오탐(평서문 제안을 약속으로 오인 가능) · 효과 수치의 한계(작은 표본·자기측정 19런) · goals.py는 에이전트가 스스로 호출해야 작동(훅처럼 무조건 걸리진 않음).

실제 예시

1) 라우터 — 신호별 최소 매칭 팩만 주입 (hooks/router.sh)

# hooks/router.sh — UserPromptSubmit 훅: 신호가 잡힐 때만 해당 팩 규범을 컨텍스트로 주입
# 원칙: smallest matching pack only / verified packs only / 항상 exit 0
low="$(printf '%s' "$prompt" | tr '[:upper:]' '[:lower:]')"

# 디버깅/근본원인 → investigation-protocol
case "$low" in
  *debug*|*bug*|*error*|*traceback*|*crash*|*failing*|*"not working"*)
    add "[fablize:investigation] ... reproduce first, form 3+ competing hypotheses,
         trace the full causal chain, verify before/after ..." ;;
esac
# 렌더/실행 산출물 → verification-grounding
case "$low" in
  *html*|*svg*|*game*|*canvas*|*chart*|*render*|*website*|*webpage*)
    add "[fablize:grounding] ... run it in the real renderer, observe the actual output,
         fix what the observation reveals, then re-run. A static check is not observation." ;;
esac
[ -n "$emit" ] && printf '%s\n' "$emit"
exit 0

2) 증거 게이트 — 코드로 강제되는 “done의 기준” (scripts/goals.py)

# scripts/goals.py — stdlib-only 멀티스토리 엔진. 상태: ./.fablize/
# - 작업을 순차 스토리로 분해 → ledger(.fablize/)에 영속(세션 죽어도 생존)
# - complete 체크포인트는 비어있지 않은 evidence 필요
# - 최종 스토리는 verify 커맨드 + 결과 없으면 완료 거부 (= 검증 게이트)
#
# goals.py create --brief "..." --goal "title::objective" [--goal ...]
# goals.py next                    # 다음 스토리 활성화 + 핸드오프 출력
# goals.py checkpoint --id G001 --status complete --evidence "..."
# [--verify-cmd "<실행한 명령>" --verify-evidence "<결과>"]  # 최종 스토리 필수
# goals.py status
DIR = Path(".fablize")          # goals.json + ledger.jsonl (append-only 감사로그)

요약 & 셀프체크

3줄 요약

  1. fablize는 모델 능력을 못 올리지만, 완수·증거·검증을 절차로 강제해 같은 모델을 자기 천장까지 끌고 간다.
  2. 통제 비교로 “옮겨지는 절차만” 골라 탑재했고(검증접지·멀티스토리·조사·완수가드), 못 옮기는 능력은 솔직히 에스컬레이션한다.
  3. 구현은 라우터 훅(최소 주입) + Stop 훅(조기종료 차단) + goals.py(증거 게이트·영속 원장), 의존성 0의 미니멀 키트다.

스스로 답해보기

  • “능력”과 “절차”를 가른 기준은 무엇이며, 능력이 안 옮겨진다는 걸 어떻게 반증했나?
  • goals.py의 최종 게이트가 “프롬프트 권고”가 아니라 “실행 거부”라는 점이 왜 결정적인가?
  • 라우터가 키워드 case 매칭이라는 사실에서 나오는 약점 두 가지는?

fable-ish(chrisryugj)와의 관계·차이

같은 “Fable” 키워드를 공유하지만 별개 프로젝트다. (cf. 6_fable-ish/FB_개요)

관점fablize (fivetaku)fable-ish (chrisryugj)
강제 메커니즘팩 주입 + 외부 상태엔진(goals.py) + 정규식 Stop훅이벤트 루프 훅 + 증거 원장 + additionalContext
검증 게이트goals.py 최종 스토리 --verify-cmd 거부Stop 완료 게이트(증거 추출→완료 판정)
출하 철학”검증된 절차만 출하”(능력 주입 거부, 측정 기반)행동 분류 엔진으로 작업 유형별 처리

[!note] 핵심 차이 둘 다 “Fable의 완수·증거·검증 절차”를 일반 Claude에 이식하려는 하네스로, 증거 원장·완료 게이트·컨텍스트 주입이라는 같은 3대 무기를 다른 구현으로 푼다. 다만 fablize는 “무엇을 탑재하지 않을지”를 통제 실험으로 결정한 점이 가장 특이하다 — fable-ish가 작업 분류→처리의 엔진형이라면, fablize는 “검증분만 추린 미니멀 절차 키트”에 가깝다.

연결

기능별 분해

관련 노트 _분석축_루브릭 · fablize 개요(현재) · fable-ish 개요 · HOME

[!tip] Codex 교차검증 보존 본 노트의 효과 수치(A/B 19런 + 실작업 26세션, 도구 호출 약 1,500회)는 작은 표본·Claude 단일 가족의 자기측정이라는 한계가 있다. 방향(닫힌 작업 동률, 열린 작업에서만 능력차)은 견고하나 소수점 단위는 단정하지 않는다 — 저자 본인도 README에서 이를 인정한다. 또한 조기종료 Stop 훅은 평서문 제안(“원하시면 보고서를 작성하겠습니다”)을 약속으로 오인할 수 있고, goals.py 게이트는 에이전트가 스스로 호출해야 작동하므로(훅처럼 무조건 걸리지 않음) “검증을 코드로 강제”의 범위는 호출 시점에 한정된다.