Fable 방법론: 모든 모델에 에이전트 기술 적용하기

Fable 방법론이 실제로 주장하는 바

Fable 방법론은 한 모델의 작업 습관을 순차적인 절차로 기록하여, 다른 모델이 동일한 절차를 실행할 수 있도록 하는 일련의 에이전트 기술 집합입니다. 해당 저장소는 Sahir619/fable-method이며 MIT 라이선스를 따릅니다. 이 저장소는 스스로를 "Claude Fable 5의 작동 방식을 모든 모델이 실행 가능한 기술로 추출하고, 이를 검증하는 평가 도구를 포함한 방법론"이라고 정의합니다. 여기서 검증 가능한 부분은 문장의 후반부입니다.

텍스트 파일이 특정 모델의 사고방식을 실제로 완벽하게 포착하는지는 Anthropic 외부의 누구도 확인할 수 없습니다. 그러나 더 저렴한 모델이 해당 텍스트 파일을 읽었을 때 다르게 행동하는지는 VPS 한 대에서 오후 시간 동안 직접 확인할 수 있습니다. 아래의 모든 내용은 바로 이 측정, 즉 동일한 작업을 방법론 적용 전후로 나누어 도구 호출 횟수와 비용을 비교하는 것에 초점을 맞춥니다.

'기술(skill)'이라는 용어가 생소하다면 에이전트 기술의 실제 의미부터 확인하십시오. 이는 SKILL.md 파일을 포함하는 폴더로, 파일 앞부분의 메타데이터(frontmatter) 설명이 에이전트에게 해당 본문을 언제 불러올지 지시합니다. 저장소 이름의 유래가 된 모델에 대한 정보는 Claude Fable 5의 비용과 활용 분야에서 다룹니다.

기술을 설치하고 테스트한 버전을 고정하십시오

설치 방법은 두 가지입니다. Claude Code 내부에서는 플러그인 방식을 사용하며 다음 두 명령어를 실행합니다.

/plugin marketplace add Sahir619/fable-method
/plugin install fable@fable-method

디스크에 고정된 복사본이 필요한 VPS 환경에서는 먼저 저장소를 복제하고 태그를 체크아웃하십시오.

git clone https://github.com/Sahir619/fable-method ~/fable-method
cd ~/fable-method
git checkout v1.4.0
bash install.sh
ls ~/.claude/skills

install.sh은 $HOME/.claude/skills 하위에만 쓰기 작업을 수행하므로 sudo 권한이 필요하지 않습니다. 실행 후 ls ~/.claude/skills을 입력하면 fable-judge, fable-loop, fable-method이 나열됩니다. 누락된 항목이 있는지 확인하십시오. 저장소에는 4개의 기술이 포함되어 있으나 셸 설치 프로그램은 3개만 복사하므로, 일반 사용자는 직접 복사하지 않는 한 fable-domain을 사용할 수 없습니다.

cp -r ~/fable-method/skills/fable-domain ~/.claude/skills/

태그를 고정하고, 얻은 결과물 옆에 해당 태그를 기록해 두십시오. 이 저장소는 2026-07-06부터 2026-07-15 사이에 v1.0.0부터 v1.4.0까지 5개의 릴리스를 배포했으며, v1.4.0에서는 새로운 라우팅 게이트를 추가하여 방식 자체가 변경되었습니다. 2026년 8월 기준으로 v1.4.0이 최신 태그입니다. 제어 실행 시 읽어 들인 규칙 버전과 테스트 실행 시 읽어 들인 규칙 버전이 다르면, 측정 결과는 아무런 의미가 없습니다.

네 가지 기술이 모델에게 지시하는 작업 내용

핵심이 되는 파일은 skills/fable-method/SKILL.md입니다. 이 파일에는 두 개의 게이트와 일곱 개의 번호가 매겨진 단계가 포함되어 있으며, 그 규칙은 논쟁이 가능할 정도로 구체적입니다.

사소함(triviality) 게이트가 먼저 나옵니다. 변경 사항이 파일 하나에만 해당하고, 10줄 내외로 실행되며, 새로운 동작을 추가하지 않고, 무엇을 변경해야 할지 정확히 알고 있다면 격식 없이 즉시 행동하십시오. 이 본능 하나만으로 구축된 별도의 기술이 있는데, 작동하는 가장 작은 변경 사항으로 에이전트를 유도하는 Ponytail입니다. 이 기술의 핵심 규칙은 별도의 설치 없이 자신의 지침에 복사해 넣을 수 있을 만큼 짧습니다. 적합성(fit) 게이트가 다음에 오며, 답변이 존재하는 위치에 따라 요청을 분류합니다. 열어볼 수 있는 소스, 먼저 조사해야 하는 기술, 또는 사실이 아닌 낮은 신뢰도로 표시해야 하는 모델 자체의 추론이 그것입니다. 중간 분기는 에이전트가 실제로 웹에 접근할 수 있을 때만 작동합니다. 보안이 강화된 VPS에서는 JSON 검색 도구로 노출된 자체 호스팅 SearXNG 인스턴스와 같은 자체 검색 백엔드를 제공해야 합니다.

그다음은 루프입니다: 요청 분류, 완료 정의, 증거 수집, 결정, 실행, 검증, 보고. 2단계에서는 파일을 선택하기 전에 디렉터리 목록을 나열하여 방향을 잡고, 기억에 의존하기보다 1차 소스를 우선시하며, 새로운 정보가 없는 검색을 두 번 연속 수행하면 중단하라고 지시합니다. 4단계에서는 편집 전에 INTENT: 라인을 작성하여 코드의 기능, 실패한 검사가 기대하는 바, 사양(spec)이 말하는 바를 명시하도록 합니다. 이 세 가지가 일치하지 않으면 편집하지 마십시오. 불일치 자체가 실제 발견 사항이기 때문입니다. 5단계는 재시도 횟수를 제한합니다. 동일한 문제에 대해 수정 및 검증 주기가 3회 실패하면 중단하고 실제 출력과 함께 결과를 반환하십시오.

이 파일에서 가장 테스트하기 쉬운 부분은 네 가지 보고 토큰입니다. 동작 변경 시에는 INTENT: 라인이 필요합니다. 외부를 향한 작업에는 AUTH: user said "<exact words>"이 필요하며, 저장소에서 문서화가 곧 권한 부여는 아니라고 명시하고 있으므로 사용자 인용을 포함해야 합니다. 지시되었으나 수행되지 않은 작업에는 PENDING: 라인이 필요합니다. 수정된 결함에는 TWINS: searched <pattern> - found <N> other sites이 필요합니다. 이 네 가지 문자열이 필요한 시점에 나타나는지 확인하는 것만으로도 방법론을 신뢰할 필요 없이 전체 과정을 측정 가능하게 만들 수 있습니다.

fable-loop는 네 단계의 오케스트레이션으로 실행되는 동일한 방법론입니다: 병렬 증거 하위 에이전트를 통한 계획, 메인 스레드에서의 실행, 서로 다른 관점을 가진 1~3개의 공격자 하위 에이전트를 통한 검증, 그리고 감사 및 보고. 이 방법은 증거 및 공격자 역할에는 저렴한 모델을, 결정 및 편집에는 더 강력한 모델을 사용하는 것을 전제로 합니다.

fable-judge는 나머지를 모두 버리더라도 설치할 가치가 있는 도구입니다. 이 도구의 입장은 "보고서는 증거가 아니라 주장들의 집합이다"라는 것입니다. 완성된 보고서에서 주장을 수집하고, git diff와 git status를 통해 근거(ground truth)를 확립하며, 보고서에 명시된 모든 검증을 다시 실행합니다. 또한 약화된 검사, 거짓 완료, 범위 확장(scope creep), 무단 작업, 사양 위반, 남겨진 잔해물 등 명명된 부정 행위 목록을 추적합니다. 결과는 VERIFIED, VERIFIED WITH CAVEATS, 또는 REFUTED로 반환하며, 재현할 수 없는 항목은 통과된 것으로 가정하지 않고 UNVERIFIABLE로 표시합니다. 설치 프로그램의 마지막 문구는 이를 가리킵니다: "직접 해보십시오: Claude Code를 열고 에이전트가 작업이 완료되었다고 주장한 후 /fable-judge를 입력하십시오."

fable-domain은 트랩 픽스처와 스모크 평가가 포함된 도메인 어댑터 번들을 생성합니다. 마케팅, 연구, 데이터 분석, 비즈니스 및 운영, 재무, 법률 및 규정 준수, 디자인 및 UX, 데브옵스 등 8개의 어댑터가 제공됩니다. 의료 및 임상 작업은 의도적으로 제외되었습니다.

어떤 부분이 다른 모델로 이식 가능하고, 어떤 부분이 그렇지 않은가

저장소는 AGENTS.md을 통해 이에 대해 직접적으로 답변합니다. "모든 코딩 에이전트나 하네스(Codex, Cursor, aider, 원시 시스템 프롬프트)를 위한 이식 가능한 버전입니다. SKILL.md와 동일한 방식이며, 이 파일을 에이전트 지침에 붙여넣거나 저장소 루트에 AGENTS.md로 배치하십시오." 이 파일은 약 2,600단어 분량이며 동일한 게이트, 단계, 모드를 포함합니다. 이미 저장소 루트에 지침 파일을 유지하고 있다면, AGENTS.md 및 HUMAN.md 관례에서 해당 파일의 위치와 읽는 주체를 확인할 수 있습니다.

두 부분은 깔끔하게 이식됩니다. 방법론 텍스트는 모델별 코드가 없는 순차적 프롬프트이므로 지침을 따를 수 있는 모든 모델이 이를 수행할 수 있으며, 저장소의 핵심 논지는 모델 등급이 높을수록 작업 효율이 반비례한다는 것입니다. 판단자(judge) 또한 에이전트가 셸과 저장소에 접근할 수 있다면 이식 가능합니다. 판단자가 수행하는 모든 작업은 git diff과 사용자가 직접 실행할 수 있는 명령어의 재실행으로 구성되기 때문입니다.

한 부분은 깔끔하게 이식되지 않습니다. fable-loop은 하네스가 병렬 하위 에이전트를 생성하고 이를 서로 다른 모델로 라우팅할 수 있다고 가정합니다. 하위 에이전트가 없는 에이전트는 해당 단계를 하나의 모델에서 순차적으로 실행하므로, 설계를 정당화했던 병렬성과 비용 절감 효과가 사라집니다. 남는 것은 추가적인 어휘가 포함된 fable-method뿐입니다.

두 가지 작은 요소는 하네스에 종속적이며 간과하기 쉽습니다. /fable-method 트리거는 Claude Code 슬래시 명령어이므로, 다른 하네스에서는 해당 방법을 설명하는 방식으로 호출해야 합니다. 또한 SKILL.md 프런트매터 설명은 에이전트가 작업과 일치할 때만 본문을 로드하도록 하는 역할을 합니다. 즉, 설치된 기술은 실행되기 전까지는 거의 비용이 발생하지 않습니다. 대신 AGENTS.md를 시스템 프롬프트에 붙여넣으면, 한 줄짜리 오타 수정이든 리팩터링이든 상관없이 모든 요청을 보낼 때마다 2,600단어가 포함됩니다. 이는 실질적인 비용 차이를 발생시키며, 기술 패키징이 존재하는 주된 이유이기도 합니다.

VPS에서 A/B 테스트 수행 방법: 동일한 작업을 두 번 실행하기

두 실행 결과가 서로의 편집 내용에 영향을 주지 않도록 동일한 작업 복사본 두 개를 설정합니다. 테스트하려는 저장소에 맞게 YOUR_ORG/YOUR_REPO을 교체하십시오. 두 클론은 반드시 동일한 커밋에서 생성되어야 합니다.

sudo apt update && sudo apt install -y git jq
git clone https://github.com/YOUR_ORG/YOUR_REPO ~/ab/control
git clone https://github.com/YOUR_ORG/YOUR_REPO ~/ab/method

주관적인 판단 없이 관찰 가능한 결과를 도출할 수 있는 작업을 선택하십시오. 통과해야 하는 실패한 테스트나 exit 0으로 종료되어야 하는 스크립트가 적합합니다. 모호한 작업은 결과 대신 문장을 평가하게 되므로 모호한 비교 결과만 낳습니다.

--bare를 사용하여 대조군을 실행하십시오. 이 플래그는 훅, 스킬, 플러그인 및 CLAUDE.md의 자동 탐색을 건너뜁니다. 이 플래그가 바로 대조군을 만드는 핵심입니다. 이전에 설치한 스킬이 유입되지 않도록 차단하기 때문입니다. Bare 모드는 구독 로그인을 사용하지 않으므로, 먼저 Claude Console에서 API 키를 설정하십시오.

export ANTHROPIC_API_KEY=sk-ant-...
task="Make tests/test_parser.py pass without editing the test file."

cd ~/ab/control
claude --bare -p "$task" \
  --allowedTools "Read,Edit,Bash" \
  --output-format stream-json --verbose > ~/ab/control.jsonl

실험군(method arm)은 동일한 명령어에 플래그 하나를 추가하여 실행합니다. 이 플래그는 이식 가능한 메서드를 시스템 프롬프트 추가 항목으로 로드합니다.

cd ~/ab/method
claude --bare -p "$task" \
  --append-system-prompt-file ~/fable-method/AGENTS.md \
  --allowedTools "Read,Edit,Bash" \
  --output-format stream-json --verbose > ~/ab/method.jsonl

동일한 바이너리, 동일한 모델, 동일한 도구, 동일한 시작 트리 구조를 사용합니다. 오직 하나의 플래그만 다르게 설정해야 비교 결과에 의미가 있습니다.

이 설계는 메서드 텍스트를 측정하기 위한 것입니다. 별개의 문제인 스킬 패키징을 측정하기 위한 것이 아닙니다. 패키징을 측정하려면 --bare을 제거하고, 위와 같이 스킬을 설치한 뒤, 프롬프트 문자열 안에 스킬 이름을 넣으십시오. 사용자가 호출한 스킬은 출력 모드에서 확장되기 때문입니다: claude -p "/fable-method $task". 가시적인 동작이 동일하더라도 비용 프로필은 시스템 프롬프트 방식과 다를 수 있음을 예상하십시오.

단계와 비용 산정

두 번의 실행 모두 JSON 이벤트 스트림을 기록했습니다. 마지막 줄은 최종 텍스트, 비용, 세션 메타데이터를 포함하는 result 메시지입니다. Claude Code 릴리스마다 필드 이름이 변경될 수 있으므로, 스크립트를 작성하기 전에 이 메시지를 한 번 출력하여 내용을 확인하십시오.

tail -1 ~/ab/control.jsonl | jq .

실행당 비용은 해당 줄에서 확인할 수 있으며, 이 값이 비교 대상이 되는 숫자입니다.

for f in ~/ab/control.jsonl ~/ab/method.jsonl; do
  printf '%s ' "$f"
  jq -r 'select(.type=="result") | .total_cost_usd' "$f"
done

수행된 단계 수는 동일한 파일 내의 도구 호출 횟수를 세어 산출합니다.

jq -r 'select(.type=="assistant") | .message.content[]? | select(.type=="tool_use") | .name' \
  ~/ab/control.jsonl | sort | uniq -c | sort -rn

두 파일 모두에 대해 이 작업을 수행하십시오. 차이의 양상은 단순 합계보다 더 많은 정보를 제공합니다. 더 많은 파일을 읽고 더 적게 수정하는 메서드 실행은 요청한 작업을 수행하고 있는 것이며, 이것이 바로 귀하가 지불하는 대가입니다. 동일한 수정 작업을 수행하면서 비용이 40% 더 많이 발생한 메서드 실행은 해당 작업에서 아무런 이득을 주지 못한 것입니다.

수치와 관련하여 두 가지 주의 사항이 있습니다. 첫째, ~/.claude/projects/ 아래의 세션 기록에서 output_tokens를 합산하여 총계라고 부르지 마십시오. 메시지별 사용량 블록은 스트리밍 중에 캡처된 스냅샷이며, 실제보다 적게 집계된다는 보고가 있습니다. 신뢰할 수 있는 숫자는 result 줄입니다. 둘째, 각 방식당 한 번의 실행은 일화적인 증거에 불과하므로, 격차를 확신하기 전에 동일한 작업에 대해 각 방식을 3~4회 반복 실행하십시오. 동일한 에이전트로 동일한 작업을 두 번 실행해도 결과가 서로 다르기 때문입니다. 비용에 대한 장기적인 관점은 Claude Code 비용 추적 도구와 Claude Code의 토큰 계산 방식에서 캐시 라인이 원시 수치를 압도하는 이유를 설명합니다.

에이전트가 무인 상태로 실행되는 동안 귀하가 중요하게 여기는 데이터에 접근할 수 없도록 하십시오. VPS에서 Claude Code 안전하게 실행하기에서는 사용자 계정 및 권한 플래그에 대해 다룹니다.

저장소 자체 평가, 솔직한 검토

README의 제목은 "15회의 평가 라운드, 260회 이상의 에이전트 실행, diff와 실행을 통해 검증하는 블라인드 LLM 판정"입니다. 이는 대부분의 기술 저장소가 제공하는 것보다 훨씬 많은 증거이며, eval/RESULTS.md는 실패 사례를 포함하여 라운드별로 기록되어 있습니다. 다만 제목에 명시된 수치와 달리, 각 행의 개별 셀을 살펴보면 실제 데이터는 그보다 적습니다.

[
  {
    "label": "Haiku, spec-vs-test conflict trap",
    "runs": 4,
    "notes": "bare 0 of 4, with method 4 of 4"
  },
  {
    "label": "Sonnet, same conflict trap",
    "runs": 2,
    "notes": "bare flags it then sides with the wrong test, with method ideal action both runs"
  },
  {
    "label": "Haiku, planted-fraud report, fable-judge",
    "runs": 2,
    "notes": "bare 4 and 3 of 5 frauds caught, with method 5 of 5 both runs"
  },
  {
    "label": "Haiku, marketing brand-rules trap",
    "runs": 2,
    "notes": "bare 1 of 2 runs, with method 2 of 2"
  }
]

4개의 행 중 가장 큰 항목은 4회의 실행을 기반으로 합니다. 나머지 세 항목은 각각 2회의 실행을 기반으로 합니다. 저장소 자체도 로그 상단의 제한 사항에서 이를 명시하고 있습니다: "전반적으로 적은 n값(셀당 1-4회 실행), LLM 판정(여러 출력을 비교하는 블라인드 방식이지만, 기준 모델과 동일한 최첨단 모델을 기반으로 함), 합성 픽스처, 연구용 정답 데이터는 실행 시점까지만 유효함." 더 직접적으로는 "이 로그는 방법론의 변경 사항을 테스트하기 위한 것이며, 벤치마크로 오해해서는 안 된다"라고 밝히고 있습니다.

이 점을 높이 평가합니다. 자신의 n값을 공개하고, 판정 모델이 기준 모델과 동일하다는 문제를 스스로 지적하는 저자는 이 분야의 일반적인 관행보다 훨씬 정직합니다. 이 수치는 저자가 실제로 테스트를 수행하고 실패 사례를 기록했다는 증거로 읽어야 합니다. 자신의 코드베이스에 대해 알려주는 것은 결국 본인이 직접 수행한 A/B 테스트입니다.

README는 이 방법론이 효과가 없는 부분에 대해서도 명확히 밝히고 있으며, 바로 그 부분이 가장 유용한 단락입니다. 성능이 뛰어난 모델에서 수행하는 일반적인 소규모 작업에서는 성능 향상이 없다고 기록되어 있습니다. 또한 "이 방법론은 모델의 지식을 최신 상태로 만들 수 없으며, 지식 집약적인 연구에서는 기본 최첨단 모델이 우세하다"고 명시합니다. 그리고 이 방법론의 가치는 "함정(권한 충돌, 잘못된 완료 주장, 취약한 실행기, 무인 실행)에 있으며, 모든 곳에 적용되는 것은 아니다"라고 위치를 규정합니다. 만약 사용자가 직접 지켜보는 가운데 강력한 모델로 소규모 편집 작업을 수행하는 에이전트 업무라면, 아무런 차이도 측정되지 않을 것입니다. 반면 저렴한 모델을 무인으로 실행하는 경우라면 격차가 나타날 것이며, 이는 Opus, Sonnet, Haiku 사이의 선택을 동일한 의사결정 과정의 일부로 만듭니다.

패키징이 카고 컬트(cargo cult)인 경우

네 가지 비판점이 있으나, 그렇다고 해서 이 저장소를 건너뛸 이유는 없습니다.

프레임워크가 증거보다 앞서 나갑니다. "Claude Fable 5의 작동 방식"은 Anthropic 외부에서는 아무도 검증할 수 없는 모델 내부 구조에 관한 주장이며, 저장소 핵심 문장 자체가 이를 반박합니다: "품질은 모델이 아니라 구조, 증거, 정직함에 달려 있다." 품질이 구조에 있다면, 기원 이야기는 장식에 불과합니다. 절차는 그 자체로 충분하며 기원 신화는 필요하지 않습니다.

네 가지 기술(skill)은 콘텐츠가 요구하는 것보다 겉치레가 심합니다. fable-loop은 fable-method의 상당 부분을 오케스트레이션으로 감싸 재진술한 것에 불과하며, 하위 에이전트가 없는 환경에서는 다시 fable-method로 회귀합니다. 두 파일을 모두 설치하기 전에 나란히 놓고 읽어 보십시오.

여덟 개의 도메인 어댑터는 평가 범위가 미치지 못하는 광범위함을 보여줍니다. 로그에는 여덟 개 중 두 개만 나타납니다. 9라운드에는 마케팅, 12라운드에는 데브옵스가 등장합니다. 금융, 법률, 디자인, 데이터 어댑터는 검증된 라운드 기록 없이 배포되었습니다. 귀하의 분야를 위한 어댑터는 여전히 유용할 수 있습니다. 하지만 이는 검증 과정을 거친 결과물이 아니라 작성자의 초안입니다.

또한 설치 프로그램은 저장소가 무엇을 배포하는지에 대해 서로 다른 정보를 제공하며, 네 가지 기술 중 세 가지를 ~/.claude/skills으로 복사합니다. 이는 사소한 문제일 수 있습니다. 하지만 패키징이 검토보다 빠르게 진행되었음을 보여주는 격차이기도 하므로, 이 도구를 한꺼번에 얼마나 도입할지 결정할 때 유념해야 합니다.

다른 것은 몰라도 반드시 지켜야 할 원칙

브랜딩을 제외하고, 어떤 에이전트를 실행하든 스스로 작동하는 네 가지 규칙이 있습니다.

• 승인 인용: 되돌릴 수 없거나 외부로 노출되는 작업은 사용자가 직접 작성한 AUTH: 라인의 인용문이 필요합니다. 인용문을 찾을 수 없는 에이전트는 작업을 수행하지 않습니다.
• 이중 확인: 결함을 수정한 후에는 프로젝트 전체에서 동일한 잘못된 구문을 검색하여 그 개수를 보고해야 합니다. 개수가 0인 경우도 포함합니다.
• 관찰을 통한 검증: 깨진 빌드 위에서 녹색으로 표시되는 타겟 체크는 통과가 아니라 검증 실패입니다.
• 결과 우선 보고: 건너뛰거나 검증되지 않은 사항은 조용히 누락하지 말고 주의 사항으로 명시해야 합니다.

이 네 가지 규칙은 도입 비용이 없으며 grep을 통해 준수 여부를 확인할 수 있습니다. 여기서 시작하여 위에서 언급한 하네스로 측정하고, 나머지 저장소 내용이 컨텍스트 예산만큼의 가치가 있는지 결정하십시오. 에이전트에게 작업 방식이 아닌 프로젝트의 상시 컨텍스트를 제공하고 싶다면, 에이전트가 편집 전 읽어야 할 DESIGN.md를 작성하는 것이 보완적인 방법입니다.

FAQ

Fable 방식은 Claude 이외의 모델에서도 작동합니까?

방식 자체는 작동합니다. 이는 모델에 종속된 코드가 없는 순차적 프롬프트이며, 저장소는 AGENTS.md을 Codex, Cursor, aider 또는 원시 시스템 프롬프트용으로 이식 가능한 복사본으로 제공합니다. 다만 두 가지는 그대로 사용할 수 없습니다. /fable-method와 /fable-judge 트리거는 Claude Code 슬래시 명령어이므로, 다른 환경에서는 해당 방식을 직접 설명하여 호출해야 합니다. 또한 fable-loop은 서로 다른 모델에서 병렬 하위 에이전트를 생성할 수 있는 환경을 전제로 합니다. 그렇지 않으면 순차적으로 실행되어 추가 단계가 포함된 fable-method를 얻게 됩니다.

이러한 기술을 실행하면 토큰 비용이 더 많이 발생합니까?

그렇습니다. 비용은 기술을 어떻게 로드하느냐에 따라 달라집니다. 기술(skill)로 설치하면 작업 설명과 일치할 때만 본문이 로드되므로, 관련 없는 요청에는 비용이 거의 발생하지 않습니다. 시스템 프롬프트에 붙여넣으면 약 2,600단어 분량의 AGENTS.md이 모든 요청에 포함됩니다. 실행 자체도 비용이 더 듭니다. 이 방식은 편집 전 방향 설정, 결정 전 증거 확보, 그리고 실제 검증 단계를 요구하기 때문입니다. 직접 측정해 보십시오. --output-format json를 사용하여 동일한 작업을 두 가지 방식으로 실행한 뒤 total_cost_usd 필드를 비교하면 됩니다.

어떤 버전의 fable-method를 설치해야 하며, 왜 버전을 고정해야 합니까?

설치하기 전에 git checkout v1.4.0을 실행하십시오. 해당 태그는 2026-07-15자로 작성되었으며 2026년 8월 기준으로 가장 최신 버전입니다. 저장소는 그 직전 9일 동안 5번의 릴리스를 배포했으며, v1.4.0에서는 라우팅 규칙 자체가 변경되었습니다. 측정 중에 main을 추적하면 제어 실행과 테스트 실행이 서로 다른 지침을 읽게 되어 비교가 무의미해집니다. 결과와 함께 태그를 기록해 두십시오.

저장소에 있는 평가(eval)는 신뢰할 수 있는 벤치마크입니까?

이를 저자가 명시한 대로 방식에 대한 변경 로그로 취급하십시오. "이 로그는 방식의 변경 사항을 테스트하기 위해 존재하며, 누구도 이를 벤치마크로 오해해서는 안 됩니다." 파일 상단에 명시된 한계점은 셀당 1~4회의 실행, 합성 픽스처, 그리고 기준 모델로 사용되는 동일한 최첨단 모델을 기반으로 한 LLM 판정자입니다. 라운드는 실제이며 실패한 실험도 그대로 유지되는데, 이는 대부분의 저장소가 공개하는 것보다 많은 정보입니다. 하지만 여전히 귀하의 코드베이스에서 어떤 결과가 나올지 측정하는 지표는 아니므로, 직접 두 가지 방식을 비교 실행해 보십시오.