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

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인가

비용

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):

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이 찍힌 시각의 서버 로그 한 줄을 보면
두 갈래가 갈립니다 — 타임아웃 계열이면 커넥션 풀 고갈을, 스택트레이스가
있으면 그 코드 경로를 봅니다. 로그를 붙여주시면 거기서 좁히겠습니다.

'가끔'을 후보