Fable 방법론: 모든 LLM에 Claude Fable 5 기술 적용하기

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

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

이 파일에서 가장 테스트하기 쉬운 부분은 네 가지 보고 토큰입니다. 동작 변경 시에는 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를 입력하십시오." 작업 후에 실행하기보다 작업 과정에 이 검사를 구축하고 싶다면, Old Coder 기술을 사용하십시오. 에이전트가 승인 가능한 SPEC과 직접 다시 실행할 수 있는 EVIDENCE 보고서를 생성하며, 테스트가 실제로 회귀를 잡아낼 것이라는 증거로 커버리지 대신 변이 테스트(mutation testing)를 사용합니다.

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

주관적인 판단 없이 결과를 관찰할 수 있는 작업을 선택하십시오. 통과해야 하는 실패한 테스트나 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 사이의 선택을 동일한 의사결정 과정의 일부로 만듭니다.

패키징이 맹목적인 관습에 머무는 경우

네 가지 비판을 제기할 수 있으나, 그중 어느 것도 이 저장소를 사용하지 말아야 할 이유는 되지 않습니다.

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

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

여덟 개의 도메인 어댑터는 평가 범위가 미치지 못하는 넓은 범위를 다룹니다. 로그에는 여덟 개 중 두 개만 나타납니다. 9라운드의 마케팅과 12라운드의 devops입니다. 금융, 법률, 디자인, 데이터 어댑터는 뒷받침하는 라운드 없이 포함되어 있습니다. 귀하의 분야를 위한 어댑터는 여전히 유용할 수 있습니다. 하지만 이는 검증 과정을 거친 결과물이 아니라 작성자의 초안입니다.

또한 설치 프로그램은 저장소가 제공하는 내용과 일치하지 않으며, 네 가지 기술 중 세 가지를 ~/.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 판정자입니다. 각 라운드는 실제 수행된 것이며 실패한 실험도 그대로 유지되는데, 이는 대부분의 저장소보다 투명한 방식입니다. 하지만 여전히 귀하의 코드베이스에서 어떤 결과가 나올지 보장하는 측정 지표는 아니므로, 직접 두 가지 방식을 비교 실행해 보시기 바랍니다.