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개의 기술이 포함되어 있으나 v1.4.0 셸 설치 프로그램은 3개만 복사하므로, 독립형 사용자는 fable-domain를 수동으로 복사하지 않는 한 해당 기술을 사용할 수 없습니다.

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

태그를 고정하고, 얻은 결과와 함께 해당 태그를 기록해 두십시오. 변경 로그에는 2026-07-06부터 2026-07-15 사이에 1.0.0부터 1.4.0까지 5개의 버전이 나열되어 있지만, 태그가 지정된 것은 4개(v1.0.0, v1.1.0, v1.2.0, v1.4.0)뿐이며 GitHub 릴리스로 배포된 것은 v1.2.0과 v1.4.0뿐입니다. v1.3.0 태그는 존재하지 않으며, v1.4.0 릴리스 노트에 따르면 미출시된 v1.3.0의 모든 변경 사항이 포함되어 있습니다. v1.4.0에서는 새로운 라우팅 게이트를 추가하여 메서드 자체가 변경되었습니다. 2026년 10월 기준으로 v1.4.0이 여전히 최신 태그이지만, main은 이미 이를 넘어섰습니다. 2026-10-03에 커밋된 변경 사항으로 Codex 설치 대상이 추가되었고 install.sh이 4개의 기술을 모두 복사하도록 수정되었으나, 해당 변경 사항이 적용된 태그는 아직 없습니다. 제어 실행에서 읽어온 규칙 버전과 테스트 실행에서 읽어온 규칙 버전이 다르면, 측정 결과는 아무런 의미가 없습니다.

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

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

첫 번째는 단순성 게이트입니다. 변경 사항이 파일 하나에 국한되고, 10줄 내외로 실행되며, 새로운 동작을 추가하지 않고, 무엇을 변경해야 할지 정확히 알고 있는 경우 별도의 절차 없이 즉시 행동합니다. 이 본능 하나만으로 구축된 별도의 기술이 있는데, 작동하는 가장 작은 변경 사항을 지향하도록 에이전트를 유도하는 Ponytail입니다. 이 기술의 핵심 규칙은 별도의 설치 없이 자신의 지침에 복사해 넣을 수 있을 만큼 짧습니다. 다음은 적합성 게이트로, 답변이 위치한 곳에 따라 요청을 분류합니다. 열어볼 수 있는 소스, 먼저 조사해야 하는 기술, 또는 자신의 추론이 여기에 해당하며, 추론의 경우 사실로 제시하기보다 신뢰도가 낮음을 표시해야 합니다. 이 중간 분기는 에이전트가 실제로 웹에 접근할 수 있을 때만 작동합니다. 보안이 강화된 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를 기반으로 진실을 확립하며, 보고서에 명시된 모든 검증을 재실행합니다. 또한 약화된 검사, 거짓 완료, 범위 확장(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 사이의 선택을 동일한 결정의 일부로 만듭니다.

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

네 가지 비판점이 존재하지만, 그렇다고 해서 이 저장소를 건너뛸 이유는 없습니다.

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

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

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

또한 v1.4.0 태그의 설치 프로그램은 저장소가 제공한다고 명시한 내용과 일치하지 않으며, 네 가지 기술 중 세 가지를 ~/.claude/skills으로 복사합니다. 2026-10-03 날짜의 main 커밋이 이를 수정했으나 거의 3개월이 지났고, 아직 태그가 지정된 릴리스에는 해당 수정 사항이 포함되지 않았습니다. 이는 사소한 문제일 수 있습니다. 하지만 패키징이 검토보다 빠르게 진행되었음을 보여주는 격차이기도 하므로, 이 도구를 어느 정도 도입할지 결정할 때 유념해야 합니다.

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

브랜딩을 제외하고도 어떤 에이전트를 사용하든 스스로 생존하는 네 가지 규칙이 있습니다.

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

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

FAQ

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

방법론 자체는 작동합니다. 이는 특정 모델에 종속된 코드가 없는 순차적 프롬프트이며, 저장소는 Codex, Cursor, aider 또는 원시 시스템 프롬프트에서 사용할 수 있는 이식 가능한 복사본으로 AGENTS.md를 제공합니다. 다만 두 가지는 호환되지 않습니다. /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년 10월 기준으로 가장 최신 태그입니다. 이전에는 세 개의 태그(v1.0.0, v1.1.0, v1.2.0, 이 중 v1.2.0만 이전 GitHub 릴리스임)가 있었고, 출시되지 않은 v1.3.0이 여기에 통합되었으며, v1.4.0에서는 라우팅 규칙 자체가 변경되었습니다. main도 계속 변화하고 있으며, 10월에 변경된 설치 프로그램은 아직 어떤 태그에도 포함되지 않았습니다. 측정 중에 main를 추적하면 대조군 실행과 테스트 실행이 서로 다른 지침을 읽게 되어 비교가 무의미해집니다. 결과와 함께 태그를 기록해 두십시오.

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

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