Value-for-Fable: 모델을 안 바꾸고 행동만 바꿔 만든 가성비 AI
Value-for-Fable: 모델을 안 바꾸고 행동만 바꿔 만든 가성비 AI
"비싼 모델을 쓸 돈이 없으면 싼 모델을 비싼 모델처럼 굴리면 된다" — 이게 말이 될까요? GitHub의 itsinseong/value-for-fable 프로젝트는 이 발상을 실제로 실험했어요. 그것도 꽤 특이한 방식으로: 자기 초기 주장을 스스로 재검증해서 틀린 부분을 공개적으로 폐기하면서요.
이 글은 Value-for-Fable(VFF)가 무엇인지, 비용 절감 효과가 실제로 얼마나 되는지, 그리고 벤치마크를 정직하게 읽는 방법을 정리했어요.
VFF는 정확히 무엇인가
VFF(Value-for-Fable): Claude Fable 5의 운영 패턴을 Claude Sonnet에 명시적으로 주입해 "싼 모델을 비싼 모델처럼 굴리는" Claude Code 플러그인.
핵심 발상은 간단해요. Claude Fable 5는 앤트로픽의 최상위 모델이고 꽤 비쌉니다($10/$50 per 1M 토큰). 그 모델이 실제로 구사하는 응답 패턴 — 결론을 먼저 쓰는 방식, 진단 전 가설 설정, 완료 선언 전 검증 등 — 을 관찰해서, 더 저렴한 Sonnet에 규칙으로 강제하면 어떨까? 라는 거예요.
중요한 포인트는 이게 모델 가중치를 건드리는 게 아니라는 것입니다. 같은 Sonnet인데 "행동 방식"만 바뀌는 거예요.
VFF가 Sonnet에 주입하는 4가지 핵심 패턴은 이렇습니다.
- outcome-first: 결론을 첫 문장에 쓴다. 이유 나중에.
- clue-first diagnosis: 진단 전에 단서를 먼저 제시한다. 가설 → 증거 순서.
- measure-first: 처방 전에 가장 저렴한 측정부터 한다.
- verify-before-claiming: "완료했다"고 선언하기 전에 검증한다.
플러그인 구성은 네 가지 컴포넌트로 이뤄져 있어요.
| 컴포넌트 | 역할 |
|---|---|
skills/itsvff/SKILL.md | 세션 모드 — "VFF", "패블 모드" 같은 키워드로 수동 발동 |
output-styles/vff-v2.md | 상시 모드 — Output Style로 선택하면 모든 세션에 자동 적용 (권장) |
agents/itsvff.md | 위임 전용 Sonnet 서브에이전트 |
hooks/reminder.sh | 드리프트 방지 훅 — 세션이 길어져서(transcript 400KB 초과) VFF 구조가 흐려질 때만 작동 |
Before/After: 실제로 답변이 어떻게 달라지나
VFF 없이 Sonnet에게 "코드가 느린 이유를 분석해줘"라고 하면, 일반적으로 가능한 원인을 나열하고 각각에 대한 설명을 붙이는 방식으로 응답해요. 결론이 맨 마지막에 오거나, 아예 없는 경우도 있고요.
VFF를 적용한 Sonnet은 다르게 작동합니다.
- 첫 문장에 결론 — "이 코드가 느린 주된 이유는 N+1 쿼리입니다."
- 단서 제시 — "line 47의 루프 안에서 DB 호출이 반복되고 있어요."
- 가장 저렴한 측정 먼저 — "먼저 쿼리 카운트 로그를 찍어보면 확인할 수 있습니다."
- 제안 전 검증 — "아래 수정 적용 전에 현재 응답 시간 기록해두세요."
이 차이가 실제 품질로 이어지는지는 벤치마크 섹션에서 다루겠습니다.
비용 분석: 얼마나, 그리고 어떤 작업에서 절감되나
숫자는 Anthropic 공식 가격표 기준입니다(2026-06-14 교차검증 완료).
| 모델 | 입력 ($/1M 토큰) | 출력 ($/1M 토큰) |
|---|---|---|
| Claude Fable 5 | $10.00 | $50.00 |
| Claude Opus 4.8 | $5.00 | $25.00 |
| Claude Sonnet 4.6 | $3.00 | $15.00 |
Sonnet은 Opus 대비 40% 저렴하고, Fable 5 대비 70% 저렴합니다. 이 단가 차이가 VFF의 비용 명분이에요.
단, 저장소 스스로 솔직하게 인정하는 부분이 있어요. 1년 전 Opus가 Sonnet의 5배였을 때는 비용 명분이 훨씬 강했는데, Opus 4.8이 $5/$25으로 내려오면서 격차가 1.67배로 좁혀졌다고요. "그래도 최소 40% 차이는 확정이다"라는 표현을 씁니다.
절감 효과는 작업 종류에 따라 크게 달라집니다.
입력 지배형 작업(에이전트 코딩 등): 입력 토큰이 비용을 지배해서 VFF의 출력 압축 효과가 작아요. 절감의 대부분은 단가 차이(Opus 대비 약 52% 절감)에서 나옵니다.
출력 지배형 작업(긴 글쓰기·분석 등): 출력이 비용을 지배하는 경우 VFF 효과가 큽니다. Sonnet+v2가 Opus의 약 0.30배(70% 저렴) 수준으로 나왔어요.
벤치마크와 정직성: 자기 자랑을 자기가 깠다
이 섹션이 이 프로젝트에서 가장 흥미로운 부분이에요.
VFF 저장소는 중립 채점표와 독립 심판 2명 평균 방식으로 벤치마크를 진행했어요. 결과는 이렇습니다.
| 비교 | 결과 |
|---|---|
| v1 → v2 (압축 규칙 제거) | 76.2 → 87.1점 (+10.9점) |
| Sonnet+v2 vs 맨 Opus | 87.1 vs 86.2 / 84.8 vs 89.4 → 노이즈 안 동률 (95–100% 근접) |
| 출력 비용 (v2 / Opus) | 약 0.30배 |
"Sonnet+VFF가 Opus와 동률이다"는 게 핵심 주장이에요. 그런데 저장소가 여기서 멈추지 않았어요.
자기 반증 3건
저장소는 자기 초기 주장 세 개를 스스로 반증해서 공개했어요.
1. "VFF 5/6 승·257점" 주장 → 폐기
초기 버전에서 "VFF가 6번 중 5번 이겼다"고 주장했는데, 원자료가 남아 있지 않았고 공정 베이스라인 + 중립 채점표로 재실험하니 재현이 안 됐어요. 조용히 넘어가지 않고 "반증됨"으로 공개했습니다.
2. "1/4 압축" → 평균 약 0.5로 정정
출력이 원래 대비 1/4로 줄어든다고 했는데, 사실 그건 단일 베스트케이스 값이었어요. 실제 평균은 약 절반(0.5)입니다.
3. v3 → 폐기
복합 진단 분해를 추가한 v3를 만들었는데, 알고 보니 그 채점표가 v3 프롬프트 문구를 그대로 베껴서 편향됐어요. 중립 재채점 시 v2를 이기지 못하자(83.4 < 84.8) 공개적으로 폐기했습니다.
가장 중요한 발견: 압축은 부채였다
ablation(요소 제거 실험) 결과가 흥미로워요. 4가지 조합을 비교했더니 압축 규칙을 뺀 게 1위, 압축이 강한 풀 v1이 꼴찌였어요.
토큰을 아끼려고 강제한 "짧게 써라" 규칙이 오히려 분량 미달·설명 부족으로 품질을 깎고 있었던 거예요. v2는 그 압축 규칙을 들어내고 "진단·검증 구조"만 남겼고, 그게 +10.9점 상승으로 이어졌습니다.
과제 성격별로 갈리는 부분도 솔직하게 공개돼 있어요.
- v2가 Opus와 같거나 앞서는 곳: 기본 진단, 분량 글쓰기 (Opus가 글자 수 초과로 오히려 감점)
- Opus가 5–7점 앞서는 곳: 깊은 추론 (아키텍처 결정·복잡 성능 진단·설명 완성도)
한계와 라우팅 기준: 언제 Sonnet, 언제 Opus
솔직하게 한계를 먼저 짚겠습니다.
벤치마크 한계
심판이 Claude(Opus) 단일 가족이에요. 사람 골드 심판은 수집 안 됐습니다. 다만 저장소가 지적하듯, 그 편향은 경쟁자 Opus에 유리한 방향이라 Sonnet 점수를 부풀리지는 않아요. 표본도 작습니다 — 과제당 1–2회, 심판 2명, 진단·조언·짧은 글 중심이에요. 재채점 간 노이즈가 약 5점 정도 돼서 소수점 수치는 단정하기 어렵습니다.
VFF의 근본 한계
VFF는 행동 패턴만 바꿔요. Sonnet이 모르는 도메인 지식을 채워주지는 않아요. 순수 추론 천장이 필요한 작업에서는 효과가 없습니다.
저장소 본인이 정리한 라우팅 기준을 그대로 옮기면 이렇습니다.
Sonnet+VFF를 쓸 때: 구조가 명확한 작업 — 정형 코딩, 글쓰기, 리서치. Opus 품질에 근접하면서 비용은 절반 이하예요.
그냥 Opus를 쓸 때: 낯선 도메인, 다층 진단, 아키텍처 설계. VFF가 지식 천장을 메우지 못합니다.
타협안: Sonnet 초안 + Opus 리뷰 1패스. 풀 Opus보다 싸면서 깊이 구멍을 막을 수 있어요.
저장소 자체 태그라인도 이걸 반영해요: "PRO 사용자에겐 추천, OPUS 사용자에겐 비추천."
마무리: 과장의 시대에 자기 검증이라는 태도
VFF가 기술적으로 흥미로운 프로젝트인 건 맞아요. 행동 패턴 주입으로 싼 모델을 비싼 모델 수준에 근접시킨다는 발상이 실험적으로 검증됐고요.
그런데 저는 이 프로젝트에서 기술보다 태도가 더 인상적이었어요. "5/6 승"이라는 초기 주장을 재현 실패하자 공개적으로 폐기했고, v3가 편향됐다는 걸 발견하자 조용히 유지하는 대신 버렸어요. 압축 규칙이 오히려 품질을 깎는다는 ablation 결과도 숨기지 않았습니다.
AI 벤치마크 과장이 만연한 지금, "내가 했던 주장을 내가 깬다"는 태도는 보기 드물어요.
비용 절감 실험에 관심 있다면 GitHub 저장소를 직접 살펴보는 게 좋겠어요. 특히 bench/RESULTS.md에 자기 반증 과정이 상세히 남아 있습니다.
자주 묻는 질문 (FAQ)
Q: VFF가 Sonnet을 더 똑똑하게 만드나요?
모델 자체를 바꾸는 게 아니에요. 행동 방식만 바꿉니다. "결론 먼저, 검증 후 완료 선언"처럼 Fable 5가 구사하는 패턴을 Sonnet에게 규칙으로 강제하는 거예요. Sonnet이 모르는 도메인 지식을 채워주진 않습니다.
Q: 실제 비용 절감폭은 얼마나 되나요?
작업 종류에 따라 다릅니다. 출력 지배형 작업(긴 글쓰기·분석)에서는 Sonnet+v2가 Opus 대비 약 0.30배 비용(70% 절감)으로 나왔어요. 입력 지배형 작업(코딩)에서는 단가 차이(40%)가 주된 절감 요인이고 VFF의 추가 효과는 작습니다.
Q: VFF가 Opus를 완전히 대체할 수 있나요?
벤치마크 기준으로는 정형 코딩·글쓰기에서 근접하지만, 깊은 추론·아키텍처 설계에서는 Opus가 5–7점 앞서요. 저장소 자체도 "PRO 사용자 추천, OPUS 사용자 비추천"이라고 명시하고 있습니다.
Q: 벤치마크 결과를 얼마나 신뢰해야 하나요?
방향성(v2가 v1보다 좋다, v2가 Opus와 동률권)은 견고해 보이지만, 소수점 수치는 재채점 간 약 5점 노이즈가 있어요. 심판이 Claude(Opus) 단일 모델이고 표본이 작다는 한계도 있습니다. 절대 수치보다 방향과 패턴 위주로 읽는 게 적합해요.
Q: 누구에게 추천할 수 있나요?
Claude Code에서 Sonnet 또는 Pro 플랜을 쓰고, 구조 명확한 작업(코딩·글쓰기·리서치)이 많은 분께 적합해요. Opus를 이미 쓰고 있고 깊은 추론이 자주 필요하다면, 비용 절감 효과보다 품질 손실이 더 클 수 있습니다.
참고 자료
https://github.com/itsinseong/value-for-fable
