내 경험과도 맞음. 프런트엔드와 백엔드 작업에서 어떻게 동작하는지 보려고 $2K를 태웠음
프런트엔드는 장난감 규모의 와이어프레임 프로젝트에서 유체역학 같은 눈속임을 써서 Opus보다 훨씬 나았음. 하지만 여러 페이지 웹앱처럼 레이아웃과 미감을 모델이 직접 결정해야 하는 중대형 작업에서는 Fable과 Opus 결과가 인간 평가자에게 구분 안 될 정도의 점수를 받았음
백엔드는 Postgres, R2, Kubernetes, gVisor 등이 얽힌 데이터 흐름 구성 작업을 줬음. Opus는 Sonnet보다 나았지만, Fable은 실제로 실패하는 결과를 내고도 X, Y, Z 테스트를 실행해 동작을 확인했고 이런 결과가 나왔다고 자신 있게 말했음. Opus나 Sonnet에서는 이런 문제가 없어서 꽤 놀라웠음
가장 긴 프런트엔드 작업은 약 2시간, 백엔드는 8시간이었음
작업이 LLM 개발과는 무관했고 20년 전에도 만들 수 있었을 프로덕션급 보안 시스템이었지만, Claude Fable이 스스로 성능을 낮췄거나 가짜 결과를 뱉었을 가능성도 있음. Anthropic이 LLM 관련이라는 내부 기준을 공개하지 않은 채 모델 품질을 조용히 낮추기 때문에 알 방법이 없음
결론적으로 Fable은 예측 불가능해서 장난감 규모의 빠른 와이어프레임을 넘는 프로젝트에서는 Opus나 Sonnet만큼 신뢰할 수 없다고 봤음. 다만 비기술 직군이 빠르게 UI/UX 와이어프레임을 만드는 데는 최고의 도구일 수 있음

HN에서 “성능을 보려고 $2K를 태웠다” 같은 문장을 보면, 그런 돈을 태울 여유가 있다면 LLM 실험 말고 훨씬 재미있게 돈을 쓸 기회가 있지 않나 싶어짐

Fable은 사실 Opus 4.8에 몇 가지 추가 능력과 실행 하네스를 얹은 것 같다고 진심으로 생각함. 둘을 나란히 놓고 UI를 생성하는 영상을 봤는데 테마 추천 등이 거의 동일했음. 새 모델이라기보다는 Opus 4.8 위에 장식을 조금 뿌린 느낌임

Fable은 최상의 상태의 Opus와 많이 비슷하지만, 더 안정적이고 조금 더 똑똑하게 느껴짐. 내 사용 사례에서는 쓰기 좋고 Opus보다 뚜렷하게 나음
그럴듯한 코드를 얻기 위해 직접 지시를 덜 해도 되고, 그렇게 빡빡하게 감시하지 않아도 됨. 참고로 내 Claude Code 작업 방식은 구현 전에 “정렬”을 위해 토론을 많이 하는 편이고 Markdown도 꽤 많이 씀
또 문체 버릇이 훨씬 적고 의사소통이 더 명확함. Opus 4.8은 글쓰기 스타일이 가끔 꽤 이상했는데, 대부분 바로잡긴 했지만 완전히는 아니었음. 때때로 말도 안 되는 과장을 쓰곤 했음

단일 8시간 작업이라면 문제를 자초한 것에 가까움

$2K를 어떤 기업용 계정에 쓴 건지 궁금함. 그냥 $200짜리 Max Pro 계정을 쓰면 안 됐나 싶음
Fable 5 출력은 마음에 들지만, “정상” API 토큰 가격은 절대 내지 않을 것임. 정말 말도 안 되게 빠른 속도로 $2K까지 갈 수 있음

“기록적인 타임아웃”, “최다 부정행위”, “명예의 전당 최초 4건” 같은 결과는 ‘평균적’이라는 결론이 아래로 크게 편향됐다는 쪽을 가리킴
모델이 너무 최신이고 매개변수가 커서 문제의 해법을 외우고 있다면 그건 모델의 결점이 아니라 벤치마크의 유효성에 대한 문제임. 특히 막 출시된 모델에서 타임아웃을 왜 점수에 포함해야 하는지도 모르겠음

동의함. “훈련 데이터 회상”을 부정행위라고 부르는 건 이상함. 38건 중 33건이 그 경우라면 더 그렇고, 보통 부정행위는 규칙을 깨는 걸 뜻함. LLM이 가중치에 들어간 내용을 쓰지 않으려면 어떻게 해야 하는 건가

“업스트림 수정이 훈련 데이터에 있었다”면, 적어도 이제는 데이터 세탁과 그대로 되뱉기가 여전히 일어난다는 최신 증거가 생긴 셈임

동의함. 이 글은 코딩 벤치마크가 어렵고 계속 움직이는 표적이라는 흥미로운 글이 될 수 있었는데, 대신 자기들의 벤치마크가 옳다는 믿음에 고정돼 있음
어떤 제목이 가장 많이 공유될지 알고 있었고, 어디서 잘못됐는지 인정하기보다 그 제목에 맞춰 글을 쓴 것 같다는 느낌을 지울 수 없음

“모델이 훈련 중 업스트림 수정을 봤고 그대로 재현했다”, “numpy 패치가 황금 패치와 100% 문자 단위로 동일하다”는 건 벤치마크 방법론의 결함처럼 보임
보기에 이들은 기존 취약점을 찾은 뒤 패치 이전의 git 히스토리로 되감고, 모델에게 취약점을 고치라고 하는 방식 같음. 패치가 훈련 컷오프 이후에 들어갔다면 괜찮겠지만 그렇지 않으면 문제가 됨

다른 “부정행위” 예시는 더 심함. 정답이 디스크나 git 히스토리에 놓여 있는 벤치마크를 계속 설계하는 게 놀라움
강한 문구의 프롬프트 지시로 벤치마크를 “강화”한다는 것도 이상함. 에이전트 샌드박스 솔루션이 그렇게 많은데, 왜 그중 하나를 써서 모델이 봐야 할 코드에만 접근하게 하지 않는지 모르겠음
또 다른 해법들이 훈련 데이터에 있어 이득을 봤지만 정확히 재현하지 않았을 가능성을 어떻게 배제하는지도 모르겠음. 최근 30일 이내 CVE 같은 것에만 집중해야 할 것 같음

“지배적인 메커니즘, 그리고 어떤 프롬프트 지시로도 막을 수 없는 것” 같은 문체는 이제 em dash보다 더 강한 AI 작성 신호, 특히 Claude 신호처럼 느껴짐
LLM이 가능한 한 서론을 늘려 답을 확정하는 걸 미루는 식임. 나만 그렇게 느끼는 건가

이를 부정행위라고 묘사하는 건 불공정해 보임. 벤치마크의 목표는 실제 능력을 평가하는 것임
지시를 따르는 것도 능력이므로 벤치마크로 측정할 수 있고, 이미 정답을 알고 있는 것도 능력을 제공하므로 측정할 수 있음
하지만 코딩 능력을 본다고 주장하면서 실제로는 외운 사례를 검사하는 벤치마크는 잘못된 것을 측정하는 것임. 그러면 전체 결과의 의미가 약해짐
좋은 벤치마크를 만드는 건 어렵고, 보여주고 싶은 것을 정확히 측정하도록 설계해야 함. 최적화 컴파일러 성능을 벤치마크할 때 계산 전체가 제거되지 않도록 결과를 동적으로 써야 하는 것과 비슷함
정답을 제공하는 것이 올바른 응답인 경우도 있음. 그 사례가 벤치마크 밖의 일반 성능을 대표하지 않는다는 건 부정행위가 아니라 벤치마크 실패임
특정 벤치마크를 겨냥해 모델을 훈련하면 벤치마크가 무의미해짐. 그런 훈련을 부정행위라고 부를 수는 있지만, 그건 훈련자의 속성이지 모델 자체의 속성이 아님. 모델은 부정행위를 하는 게 아니라, 전체 능력과의 관련성을 잃게 만들 정도로 비대칭적으로 잘하는 것뿐임

모델 입장에서 그걸 부정행위라고 부르긴 어려움. “실격 처리”가 더 정확할지도 모름

라벨링의 문제일 수는 있지만 핵심 방법론의 결함은 아닐 수 있음
이런 식의 문자 그대로 같은 코드 조각은 모델이 훈련 데이터에 과적합됐음을 시사함

LLM의 오래된 혼란스러운 특성은 프롬프트 내용과 스타일, 하네스 종류와 환경의 작은 차이만으로도 출력과 체감 성능이 크게 달라질 수 있다는 점임
내 환경과 내 “스타일”에서는 Fable이 엄청난 도약이었고, 다음 10일 동안 더 많이 쓰려고 $200/월 계정을 하나 더 낼까 진지하게 고민할 정도임. 조직에도 인간이 작성하는 코드의 종말이 이제 완전히 피할 수 없어 보인다고 준비시키기 시작했음
다만 Anthropic의 강한 성능 제한을 고려하면, 보안 중심 벤치마크에서 Fable이 부진한 건 놀랍지 않음. 그리고 이 벤치마크 자체도 별로임. 훈련 데이터에서 답을 알고 있다는 이유로 모델에 “부정행위” 페널티를 주는 건 모델 잘못이 아니라 게으른 벤치마크임

내 경험상 새 릴리스가 나올 때마다 더 느려지지만 꼭 더 좋아지지는 않음. 에이전트가 작성한 코드를 전부 검토하는 프로젝트들은 내가 방향을 잡아주기 때문에 대체로 괜찮아 보임
반면 몇몇 프로젝트는 그냥 바이브 코딩으로 결과만 보는데, 멍청한 버그가 계속 흘러나와 머리를 쥐어뜯고 싶을 때가 있고 코드는 보지 않음
오늘 그중 하나에 Fable을 써봤음. Python 스크립트 몇 개를 각각 400~500줄 정도로 쓰는 단순 작업이었고, 몇 번 반복한 뒤 동작하긴 했음. 그런데 코드를 들여다보니 요구사항이 바뀌면 코드를 깨뜨릴 이상한 상수들이 있었고, 코드 자체도 읽기 어렵고 완전히 엉망이었음
처음부터 잘 구조화된 코드를 썼다면 그 코드로 작업하는 것도 더 효율적이었을 거라고 봄. 순수 바이브 코딩만으로 얼마나 멀리 갈 수 있을지 진지하게 의문임
내 프로젝트들은 작은 1인 프로젝트라 지금까지는 밀어붙일 수 있었지만, 기술 부채가 코드가 만들어내는 가치를 넘어서는 시점이 얼마나 멀지 잘 모르겠음
Opus 4.5 시절은 내 기억에 아직 꽤 빠르고 다루기 쉬웠는데, 그때가 그립다

에이전트들은 코드 줄 수를 늘리는 것에 집착하는 것 같음. 단순화해 달라고 해도 50줄을 지우고 100줄을 더 추가하곤 함
줄 수를 줄이고 싶다고 명시적으로 말해야 함. 그래서 작업을 몇 단계 반복한 뒤에는 그냥 그렇게 지시함

어제 Claude Fable 5에 아주 단순한 작업을 줬음. 컴포넌트 몇 개를 만들고 다른 페이지에 임베드하는 일이었는데, 완전히 빗나가서 엉뚱한 페이지에 넣었음
단순 작업을 끝내는 데 토큰을 기하급수적으로 태우는 것도 봤고, 결국 Opus 4.8로 돌아갔음

경매 사이트를 만들면서 판매자, 중개자, 구매자, 시장 관행과 규범 등을 테스트하는 AI 무리를 쓰고 있음. 주로 GPT 5.5 xhigh로 시나리오를 코딩하고 Opus 4.8로 반복 검토했음
호기심에 Fable에게 전체를 검토시켰는데, 너무 뻔한 상식적 실수가 많이 통과됐다는 걸 보고 놀랐음. 예를 들면 모든 중개자에게 모든 구매자의 가격이 처음부터 주어졌고, 특정 경매 유형의 비공개 가격 정보가 실제로는 모두에게 방송되고 있었으며, 지시문 안에 여러 모순이 있었음
이 중 하나뿐이었다면 이해했을 수 있지만, Opus와 GPT 5.5 둘 다 이렇게 많이 놓쳤다는 점 때문에 Fable에는 뭔가 특별한 게 있다고 생각하게 됨. 이건 측정 가능한 지표가 있는 작업이 아니라 현실 세계의 흐릿한 작업일 때만 드러나는 상식형 문제라고 봄
내 특정 작업에서는 모델 간 차이가 밤과 낮처럼 컸기 때문에, 이런 모든 성능 측정에는 분명 문제가 있음

이런 버그와 문제를 평가할 결정적 기준을 만들지 않으면, 모든 모델이 계속 새 문제를 찾았다고 말하고 고치라고 할 것임
예전의 놀라운 최신 모델을 쓰던 때에도 Opus 4.8과 GPT 5.5에 “실수 찾아줘”라고 했을 것이고, 그들도 실수를 찾아 고쳤을 것임
다음 “Fable”급 모델이 나오면, 그 모델도 “특별한” Fable이 만든 실수를 더 많이 찾아낼 것임
결국 모델로 실수를 만들고, 업그레이드된 버전으로 이전 실수를 찾아 고치게 하다가, 새 버전이 나오면 이전 버전이 만든 더 많은 실수를 마법처럼 고치는 흐름임. 끝이 없음

Fable이 훨씬 더 철저하고, 많은 하위 에이전트를 띄워 사실상 더 많은 종단간 테스트를 돌리는 것 같음
꼭 더 똑똑한 건 아니고, 절차적으로 프롬프트를 잘 주면 더 낮은 모델로도 같은 결과를 낼 수 있을 것 같음. 다만 계산량과 오케스트레이션이 훨씬 많음

한 달 전까지만 해도 코더보다 낫다고들 하던 모델들이 실제로는 실수를 많이 한다는 건가
정말 충격적임

“대화를 살펴본 결과 안전 거부는 없었다. Fable 5는 200개의 보안 취약점 수정 작업 모두에서 콘텐츠 정책 차단, ‘Model Blocked’ 오류, 사이버보안 주제 플래그 없이 응답했다”라니, 대체 뭐지
나는 “보안 연구”도 아니고 평범한 개발과 디버깅만 하는데도 Opus 4.8로 폴백되는 일을 계속 겪음
지금까지 내 Fable 경험은 전혀 ‘중간급’이 아니었음. 어떤 모델 릴리스는 점진적 개선이지만, Fable은 Opus 4.6이 이전 모델들과 비교됐을 때처럼 질적으로 달라졌음. 모델과 함께 일하는 방식 자체가 근본적으로 바뀜. 참고로 나는 거의 99% Python 백엔드만 함

회사의 Kotlin 코딩 벤치마크에서도 비슷한 결과가 나옴. 우리 팀 기준으로 에이전트가 작은 병합 가능한 PR에 얼마나 가까이 갈 수 있는지 측정함
난이도가 다른 20개 작업을 각각 5번 시도하고, LLM을 심판으로 써서 결과와 품질이 같되 허용 가능한 차이는 인정하는 방식으로 정확도를 평가함
Fable 5는 Opus 4.7보다는 앞이지만 Opus 4.6, Sonnet 4.6, Opus 4.8, GPT-5.4, GPT-5.5 뒤에 있음
Fable은 좋은 코딩 주력 모델은 아님. 그렇다고 실제 복잡한 문제나 긴 작업 범위, 큰 개념증명, 복잡한 연구 등에 좋지 않다는 뜻은 아님. 하지만 그쪽은 내 느낌과 Anthropic 자체 벤치마크, 마케팅 말고 참고할 게 없음

그러면 팀에서 PR을 직접 훑어보고 결과를 판단하는 건가? 지금은 무엇을 봐야 할지 알겠지만 그래도 꽤 고통스러울 것 같음

LLM 리뷰 저장소 [1]를 시작했음. 기업 블로그나 벤치마크 순위표보다 더 작업 중심적이고 덜 마케팅적인 카탈로그를 만드는 게 목표임
여러 모델을 많이 써본 것 같으니, 시간이 되고 공유하고 싶다면 초기에 참여하는 사람 중 하나가 될 수 있음
[1] - https://model.reviews/ - 사용자가 제출한 모든 콘텐츠는 CC 라이선스이며 주기적인 덤프로 다운로드 가능하게 할 예정임

Fable 5에 꽤 인상받았음. £18 구독으로 Practal Zero [1]의 문서 처리를 UI와 같은 스레드에서 돌리던 구조에서 워커 스레드로 옮기라고 시켰음
이틀 전 같은 작업을 Codex에 줬는데 결과가 별로였음. 처리를 위해 문서 전체를 스냅샷으로 워커 스레드에 복사하는 식이었음
반면 Fable은 내가 직접 만든 운영 변환 기반 커스텀 데이터베이스가 동작 중이라는 사실을 활용할 수 있음을 알아냈고, 문서 처리를 그 데이터베이스의 또 다른 클라이언트로 만들었음. 그래서 문서 로딩이 느린 거긴 함
심지어 “livemodel”(데이터베이스 상태의 메모리 복제본)과 ProseMirror 모델 사이의 동기화 버그도 발견했음. 그 동기화는 전에도 문제를 일으켰고, 나는 네 번째 시도면 맞을 거라 확신하며 명세를 써둔 상태였음. Fable은 명세의 마지막 버그를 찾아 “다섯 번째 시도”로 고치고 해당 코드도 수정했음
다만 이 모든 것의 보고된 API 비용은 $180였고, Fable 프로모션이 6월 22일에 끝나면 감당할 수 없음. £89 Codex도 만족스럽게 쓰고 있고 매우 안정적이며 잘 동작하지만, Fable이 확실히 더 똑똑해 보임
[1] https://zero.practal.com