itsinseong/value-for-fable

𝐕𝐚𝐥𝐮𝐞-𝐟𝐨𝐫-𝐅𝐚𝐛𝐥𝐞 (𝐕𝐅𝐅)

- 주인장 시험기간 ( 시험끝나고 더 봐볼게요! )

Opus에 근접한 품질을 Sonnet 단가에 · Near-Opus quality at Sonnet pricing

🡒 PRO 사용자들에겐 추천, OPUS 사용자 들에겐 비추천

Fable5 구조를 넣은 Sonnet이 Opus와 블라인드 테스트에서 사실상 비겼다!! 그것도 답 1건당 비용 3분의 1로!! Sonnet + Fable 5 structure virtually tied Opus in a blind test — at 1/3 the cost per response. (bench/)

왜 Sonnet+VFF인가

비용

| 모델 | 입력 ($/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 대비 70% 저렴하다. 문제는 구조 없이 쓰면 그 차이가 품질 격차로 그대로 드러난다는 것이다. VFF는 그 격차를 운영 구조로 메운다.

작업 종류별 실제 절감폭(입력형 코딩 vs 출력형 글쓰기) 계산과 라우팅 기준은 COST.md 참고.

실측 결과 (2026-06-14 재검증)

원판은 Fable 5 ultracode 환경, 2026.06.11에서 생성됐고(단판이라 재현 실패), 재검증은 Opus 4.8 ultracode 멀티에이전트 하네스로 수십 개 블라인드 심판·선수 에이전트를 병렬 실행했다. 원자료까지 bench/에 공개.

원래 2026-06-11 단판 벤치("5/6승·257점")는 원자료가 안 남아 재현 불가였고, 공정 베이스라인·중립 채점표로 다시 재니 재현되지 않았다. 재현 가능한 하네스와 원자료는 bench/, 상세는 bench/RESULTS.md에 있다.

핵심 수치(중립 채점표, 독립 심판 2명 평균, 0–100):

| 비교 | 결과 | |---|---| | 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배 (70% 저렴) → 품질당 비용효율 약 3배 |

v2는 기본 진단·분량글에선 Opus와 같거나 앞서고(분량 과제는 Opus가 글자 수 초과로 감점), 깊은 추론(아키텍처 결정·복잡 성능진단)에선 Opus가 5–7점 앞선다. 압축 규칙이 품질 부채였고 그걸 들어낸 v2가 진짜 개선이다. v3(복합진단 분해 추가)는 중립 기준 효과가 없어 폐기했다.

⚠️ 한계: 과제당 1–2회·심판 2명·Claude 단일 가족·진단/조언 중심 표본. 두 재채점이 약 5점 흔들리는 노이즈가 있어 방향(v2≫v1, v2≈Opus)은 견고하나 소수점은 단정하지 않는다.

Before / After

질문: "배포 후 API가 가끔 500을 뱉어요. 왜죠?"

맨 Sonnet (VFF 없음)

## 가능한 원인
1. DB 연결 문제
2. 메모리 부족
3. 코드 버그

각각 확인 → 해결하세요.

단서('가끔')를 쓰지 않고 동급 후보를 나열한다. 첫 문장에 결론이 없다.

Sonnet + VFF

코드를 보기 전엔 단정할 수 없지만, '가끔'이라는 패턴이 단서입니다.
항상이 아니라 간헐적이면 설정 오류보다 경합 조건이나 리소스 고갈 쪽이
유력합니다. 가장 싼 확인부터: 500이 찍힌 시각의 서버 로그 한 줄을 보면
두 갈래가 갈립니다 — 타임