SSD Nodes Learn 🎉 VPS $4.99/월부터
가이드 Matt Connor작성자 Matt Connor · 업데이트됨 2026-08-07

Claude Fable 방법론을 모든 모델에 적용하는 방법

Sahir619/fable-method 저장소를 활용해 Claude Fable 5의 작업 습관을 에이전트 기술로 추출하는 법을 설명합니다. VPS 환경에서 버전별 A/B 테스트를 수행하고 도구 호출 횟수와 비용을 비교하여 모델 성능을 검증하는 구체적인 절차를 확인하십시오.

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줄 내외의 코드이며, 새로운 동작을 추가하지 않고, 무엇을 변경해야 할지 정확히 알고 있다면 별도의 절차 없이 즉시 수행합니다. 다음은 적합성(fit) 게이트로, 답변의 위치에 따라 요청을 분류합니다. 열람 가능한 소스, 먼저 조사해야 하는 기술, 또는 모델 자신의 추론 중 하나로 분류하며, 추론의 경우 사실로 제시하지 말고 신뢰도가 낮음을 명시해야 합니다.

그다음은 루프 단계입니다: 요청 분류, 완료 정의, 증거 수집, 결정, 실행, 검증, 보고. 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 diffgit 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

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

제어군(control arm)은 --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을 제거하고 앞서 설명한 대로 스킬을 설치한 뒤, 프롬프트 문자열 안에 스킬 이름을 넣으십시오. 사용자 호출 스킬은 print 모드에서 확장되기 때문입니다: 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 줄입니다. 둘째, 각 방식당 1회 실행은 일화적인 결과에 불과합니다. 동일한 에이전트로 동일한 작업을 두 번 실행해도 결과가 서로 다르므로, 격차를 신뢰하기 전에 각 방식을 3~4회 반복 실행하십시오. 비용에 대한 장기적인 관점은 Claude Code 비용 추적 도구Claude Code의 토큰 계산 방식에서 캐시 라인이 원시 수치를 압도하는 이유를 설명합니다.

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

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

README의 헤드라인은 "15회의 평가 라운드, 260회 이상의 에이전트 실행, diff와 실행을 통해 검증하는 블라인드 LLM 판정단"이라고 명시합니다. 이는 대부분의 기술 저장소가 제공하는 것보다 훨씬 많은 증거이며, eval/RESULTS.md는 실패 사례를 포함하여 라운드별로 기록되었습니다. 헤드라인의 수치 뒤에 있는 개별 셀을 살펴보면, 실제 내용은 헤드라인이 시사하는 것보다 더 간결합니다.

ChartRuns per cell behind the repo's headline eval rows, v1.4.0
The data behind this chart
[
  {
    "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-loopfable-method의 상당 부분을 오케스트레이션으로 감싸 재진술한 것에 불과하며, 하위 에이전트(subagent)가 없는 환경에서는 다시 fable-method로 회귀합니다. 두 파일을 모두 설치하기 전에 나란히 놓고 읽어 보십시오.

여덟 개의 도메인 어댑터는 평가(eval) 범위보다 지나치게 넓습니다. 로그에는 여덟 개 중 두 개만 나타납니다: 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를 얻게 됩니다.

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

그렇습니다. 비용은 기술을 어떻게 로드하느냐에 따라 달라집니다. 기술(skills)로 설치하면 설명이 작업과 일치할 때만 본문이 로드되므로, 관련 없는 요청에는 비용이 거의 발생하지 않습니다. 시스템 프롬프트에 붙여넣으면 약 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 판정자 사용. 실험 라운드는 실제이며 실패한 실험도 그대로 유지되는데, 이는 대부분의 저장소가 공개하는 것보다 많은 정보입니다. 그럼에도 이는 귀하의 코드베이스에서 발생할 결과를 측정하는 지표가 아니므로, 직접 두 그룹을 비교하는 테스트를 수행하십시오.