아직은 Fable 5 도 고삐 를 잡아야 한다 — *벤치 점수* 의 허점 과 *harness* 라는 답
프론티어 모델 이 벤치 에서 최고점 을 찍었다. 그래서 안심 해도 되나? 아니다 — 점수 는 주장 이지 보증 이 아니다. 이 글 은 Fable 5 같은 최상위 모델 의 점수 를 날카롭게 의심 하는 법, 그리고 그 의심 을 실제 로 검증 하는 도구 인 harness 를 얘기 한다.
“그런 것들 은 평가 에서 미포함 해도 되지 않나… 그리고 혹시 오버피팅 된 건 아닌지 한 번 볼 필요 가 있지 않을까.” 둘 다 정당한 포인트다 — ① 스코프 정의 문제(치팅 이 아니라 측정 대상 의 타당성), ② eval 행 이 튜닝 에 새어들었을 가능성. 확인 할 세 가지: (a) 스코프 재정의 시뮬, (b) 이종 데이터 교차 성능, (c) eval-행 누출 감사.
0. 점수 한 개 를 믿을 때 놓치는 세 가지
전에 모델 고르는 글 에서 “Agents’ Last Exam 점수” 를 봤다. 그런데 그 점수 를 액면 그대로 믿으면 세 개 의 함정 에 빠진다:
① 스코프 타당성 — 무엇 을 재는 벤치 인가
벤치 가 재는 것 과, 내 일 이 요구 하는 것 이 다를 수 있다. 벤치 는 “정답 이 있는 문제” 에 최적화 돼 있는데, 내 도메인 은 “정답 이 애매한 판단” 일 수 있다. 점수 가 높다 = 그 벤치 를 잘 푼다 일 뿐, 내 문제 를 잘 푼다 가 아니다. (이건 치팅 이 아니라 측정 대상 의 타당성 문제.)
② 오버피팅 / eval 누출 — 점수 가 부풀었나
벤치 데이터 가 학습·튜닝 에 새어들면(contamination) 점수 는 실력 이 아니라 암기 다. 규칙 을 “전체 행 의 오탐(FP) 을 보며” 튜닝 했다면, eval 행 이 튜닝 신호 로 새어들었을 가능성 이 있다. 이러면 벤치 점수 는 높은데 처음 보는 입력 에선 무너진다.
③ 이종 데이터 일반화 — 내 데이터 에서도 되나
공개 벤치 는 깔끔한 분포 다. 내 데이터 는 지저분 하고, 도메인 이 다르고, 엣지 케이스 투성이 다. 벤치 점수 와 내 이종 데이터 교차 성능 사이 의 간극 이 진짜 리스크 다.
1. Fable 5 의 구체적 허점 (과장 없이, 문서 기준)
최상위 모델 이라도 — 아니, 최상위 라서 — 고삐 가 필요한 지점 이 있다. 이건 안티팬 이 아니라 공식 문서 가 명시 하는 특성 이다:
- 과잉 숙고(overthinking) — thinking 이 항상 켜져 있어, 쉬운 일 에도 필요 이상 으로 파고들 수 있다. 높은 effort 에선 “요청 안 한 리팩터/정리” 까지 한다. → 효력 을 낮추고, “시킨 것만” 을 명시 해야.
- 긴 턴(latency) — 어려운 작업 은 한 요청 이 수 분 씩 돈다. 타임아웃·스트리밍·비동기 UX 를 미리 짜지 않으면 hang 처럼 보인다.
- refusal 오탐 — 안전 분류기 가 양성 인 보안/생명과학 인접 작업 을 가끔 거절 한다(HTTP 200 +
stop_reason: refusal). 보안 툴 만드는데 막히면 이거다. → 폴백 을 기본 으로 켜야. - 툴 을 덜 부른다 — 검색·서브에이전트·메모리·커스텀 툴 을 확신 없으면 안 건드린다. 벤치 는 통과 해도, 내 에이전트 에선 “부를 걸 안 불러서” 얕게 끝날 수 있다. → 언제 쓸지 를 프롬프트/툴 설명 에 명시.
- 더 많이 물어봄 — 사소한 결정 도 멈추고 물어, 자율 파이프라인 에선 병목.
즉 “제일 세다” ≠ “그냥 쓰면 제일 잘 나온다”. 점수 는 상한 을 올렸지만, 그 상한 을 뽑아내려면 오히려 더 세밀한 조종 이 필요 하다. 고삐 를 놓으면 최고 모델 도 헛돈다.
2. 그래서 — harness 가 답 이다
벤치 점수 를 의심 한 다음 에 뭘 하나. 직접 측정 한다. 그게 harness 의 존재 이유 다 — 남 이 만든 벤치 를 믿는 대신, 내 데이터·내 기준 으로 모델 을 검증 하는 골격.
이미지 가 꼽은 세 검증 이 정확히 harness 규율 이다:
| 벤치 의심 | harness 로 하는 검증 |
|---|---|
| ① 스코프 타당성 | 스코프 재정의 시뮬 — 벤치 를 내 문제 정의 로 다시 짜서 재평가. “이 점수 가 내가 원하는 걸 재나?” |
| ② eval 누출/오버피팅 | eval-행 누출 감사 — 튜닝/프롬프트 가 평가셋 을 봤는지 격리. train↔eval 분리 확인 |
| ③ 이종 데이터 | 교차 성능 — 내 지저분한 실데이터·엣지케이스 로 돌려 벤치 와의 간극 을 잰다 |
여기에 자기개선 글 의 Harness(Eval) 가 그대로 붙는다 — trace 를 기록·측정·수치화 해서, 벤치 가 아니라 내 실행 궤적 이 진실 을 말하게. (내가 이번 세션 에 auto-trading KIS 토큰 버그 를 잡은 것 도, 벤치 가 아니라 로그 trace 의 수치 였다.)
그리고 프론티어 모델 일수록 적대적 검증 이 더 중요 하다 — Fable 5 는 그럴듯 하게 틀리는 실력 이 좋다. 그래서 멀티 에이전트 글 의 “독립 검증자 로 반증 시키기” 가, 점수 높은 모델 일수록 더 필요 하다. 설득력 있는 오답 은, 설득력 없는 오답 보다 위험 하니까.
3. 역설 — 좋은 모델 일수록 harness 가 더 필요 하다
직관 과 반대다. “모델 이 좋아지면 harness 덜 필요 하지 않나?” — 아니다:
- 약한 모델 은 눈 에 띄게 틀린다. 잡기 쉽다.
- 강한 모델 은 미묘 하게 틀린다 — 그럴듯한 오답, 조용한 스코프 드리프트, 과잉 숙고, 안 부른 툴. 이건 측정 없이 는 안 보인다.
그래서 프론티어 모델 은 harness 를 덜 필요로 하는 게 아니라, 더 정교한 harness 를 요구 한다. 점수 가 올라갈수록, “이 점수 가 내 문제 에서 진짜인가” 를 캐는 규율 이 더 값지다.
맺으며
“아직은 Fable 5 도 고삐 를 잘 잡아야 한다” — 이 한 줄 이 핵심 이다. 최고 모델 이라는 벤치 점수 는 출발점 이지 결론 이 아니다. 스코프 가 타당한지, 오버피팅 은 아닌지, 내 데이터 에서도 되는지 — 이 의심 을 harness 로 측정 할 때 만, 점수 는 신뢰 로 바뀐다.
모델 은 상한 을 올린다. harness 는 그 상한 이 내 문제 에서 진짜인지 를 증명 한다. 그리고 그 증명 을 게을리 하면, 아무리 좋은 모델 도 그럴듯한 오답 을 빠르게 뱉을 뿐이다.
벤치 점수 를 믿는 건 엔지니어링 이 아니다. 내 데이터 로 측정 하는 게 엔지니어링 이다 — 모델 이 좋아질수록 더.