모든 모델 출시에는 두 가지 평행한 이야기가 만들어집니다.

하나는 공식적인 이야기입니다. 모델 카드 (Model cards), API 문서, 릴리스 노트, 가격표, 안전 주의사항 등이 그것입니다. 지루하고 유용하며, 때로는 읽기 고통스럽기도 합니다.

다른 하나는 스크린샷 이야기입니다. 불가능해 보이는 벤치마크 하나, 미스터리한 "치명적인 버그 (fatal bug)" 하나, 그리고 프런티어 모델 (frontier model)이 이제 노트북에서도 돌아간다는 주장 같은 것들 말이죠.

왜 두 번째 이야기가 더 빠르게 퍼지는지 이해합니다. 조명이 더 화려하니까요. 하지만 실제 엔지니어링 작업을 GPT-5.6이나 Claude Fable 5로 옮길지 결정해야 한다면, 재미 위주의 버전만으로는 충분하지 않습니다.

2026년 7월 13일 기준으로, 근거가 확실한 부분은 간단합니다. OpenAI의 모델 가이드라인은 GPT-5.6 Sol, Terra, Luna를 서로 다른 목표를 가진 모델로 설명합니다. Sol은 프런티어 역량 (frontier capability)을 위해, Terra는 지능과 비용의 균형을 위해, 그리고 Luna는 효율적인 대량 사용을 위해 배치되었습니다. Anthropic은 Claude Fable 5를 가장 유능하게 널리 출시된 모델로 설명하는 반면, Claude Mythos 5는 Project Glasswing을 통해 제한적으로 제공됩니다.

따라서 그렇습니다, GPT-5.6 Sol과 Fable 5는 실제 비교 대상입니다.

근거가 부족한 부분은 모든 놀라운 모델의 동작을 "버그 (bug)"로 바꾸어 버리는 습관입니다.

만약 누군가 GPT-5.6에 중대한 버그가 있다고 말한다면, 저는 먼저 낭만 없는 구체적인 세부 사항을 원합니다. 정확한 모델 ID, 요청 페이로드 (request payload), 도구 설정 (tool settings), 추론 설정 (reasoning settings), 재시도 횟수 (retry count), 트랜스크립트 (transcript), 그리고 기대 출력값 (expected output) 말입니다. 이러한 정보가 없다면, "버그"는 적어도 네 가지 다른 의미를 가질 수 있습니다: 오답, 거부 (refusal), 타임아웃 (timeout), 설정 드리프트 (configuration drift), 또는 벤치마크 하네스 (benchmark harness)가 백그라운드에서 조용히 멍청한 짓을 하고 있는 경우입니다.

마지막 경우는 드문 일이 아닙니다. 그것은 사실상 출시 주간의 전통과도 같습니다.

리더보드가 아닌 하네스(Harness)부터 시작하라

GPT-5.6 대 Fable 5 비교를 위해서라면, 저는 하나의 거대한 공개 점수부터 시작하지 않을 것입니다. 대신 제가 실제로 관심을 두고 있는 작업을 반영하는 프라이빗 회귀 테스트 세트(private regression set)부터 시작할 것입니다.

저의 첫 번째 단계는 네 가지 범주를 포함할 것입니다:

1. 테스트가 실패하는 디버깅(Debugging) 작업.
2. 더 많은 코드가 아닌, 더 적은 코드가 최선의 답인 리팩터링(Refactors) 작업.
3. 모델이 명확한 질문을 던져야 하는 제품 요구 사항(Product requests).
4. 초기 가정이 조용히 쓸모없어질 수 있는 긴 문맥(Long-context) 작업.

import pandas as pd

TASKS = [
...

만약 어떤 게시물이 "63개의 어려운 문제" 벤치마크를 주장한다면, 저는 프롬프트(prompts), 채점 규칙(scoring rules), 재시도(retries), 모델 설정(model settings), 그리고 거부 처리(refusal handling)를 공유하기 전까지는 흥미롭지만 불완전한 것으로 취급할 것입니다. 트랜스크립트(transcripts)가 없는 벤치마크는 자신이 어디에 서 있었는지 말하기를 거부하는 사람의 일기예보와 같습니다.

중요한 질문은 "어떤 모델이 이겼는가?"가 아닙니다.

더 나은 질문은 이것입니다: "어떤 모델이 내 제품이 허용할 수 있는 방식으로 실패하는가?"

버그처럼 보일 수 있는 세 가지 현상

첫 번째 가능한 실패 모드(failure mode)는 설정 드리프트(configuration drift)입니다.

OpenAI의 문서에 따르면 GPT-5.6은 max를 포함한 여러 추론 노력(reasoning effort) 설정을 지원하며, API 문서에서는 프로 모드(pro mode)를 별도의 모델 슬러그(model slug)가 아닌 실행 모드로 설명합니다. 이는 유용한 제어 수단입니다. 하지만 벤치마크에서 설정을 고정(pin)하는 것을 잊는다면, 이는 아주 멋진 함정이 될 수 있습니다.

임시 해결책: 매 실행마다 모델 ID, 추론 노력(reasoning effort), 프로/스탠다드 모드, 도구 액세스(tool access), 캐시 동작(cache behavior), 그리고 재시도 정책(retry policy)을 기록하십시오. 정확한 호출을 재현할 수 없다면, 그것을 증거로 사용하지 마십시오.

두 번째 가능한 실패 모드는 안전성(safety) 및 거부 처리(refusal handling)입니다.

import pandas as pd

EVENTS = [
...

OpenAI는 GPT-5.6이 특히 사이버 및 생물학적 위험 영역 주변에서 더 강력한 안전 장치(safeguards)와 결합되었다고 밝히고 있습니다. Anthropic의 Fable 5 문서는 통합(integrations)에 대해 훨씬 더 명시적입니다: Fable 5는 안전 분류기(safety classifiers)를 포함하며, 거부/폴백(refusal/fallback) 동작은 의도적으로 처리되어야 합니다.

이는 하네스(harness)가 거부(refusals), 타임아웃(timeouts), 오답(wrong answers)을 하나의 범주로 묶어서는 안 된다는 것을 의미합니다. 이들은 서로 다른 제품 이벤트(product events)입니다. 거부는 올바른 정책 동작(policy behavior)일 수 있습니다. 타임아웃은 지연 시간 예산(latency budget)의 문제일 수 있습니다. 오답은 모델 품질(model quality)의 문제입니다. 이 모든 것을 "실패"로 간주하는 것은 사용자 경험(user experience) 측면에서는 유용할 수 있지만, 진단(diagnosis) 측면에서는 최악입니다.

임시 해결책: 결과를 correct(정답), wrong(오답), refused(거부됨), timed out(타임아웃), tool failed(도구 실패), invalid harness state(유효하지 않은 하네스 상태)로 분리하십시오. 까다로워 보일 수 있지만, 유령과 싸우는 상황을 방지해 줍니다.

세 번째 가능한 실패 모드(failure mode)는 로컬 모델 혼동(local-model confusion)입니다.

GitHub 프로젝트인 JustVugg/colibri는 진정으로 흥미롭습니다. 해당 프로젝트의 README는 디스크에서 전문가(experts)를 스트리밍함으로써, 약 25GB의 RAM을 가진 소비자용 기기에서 744B 파라미터 규모의 MoE 모델인 GLM-5.2를 실행하는 방법을 설명합니다. 또한 이 프로젝트는 매우 냉정한 수치들을 보고합니다: 디스크 용량 약 370GB, 채팅 중 피크 RSS(peak RSS) 약 20GB, 그리고 저자의 WSL2 환경에서 콜드 디코딩(cold decode) 속도는 초당 약 0.05~0.1 토큰입니다.

이는 인상적인 엔지니어링입니다.

하지만 이것이 Claude Fable 5가 노트북에서 로컬로 실행된다는 증거는 아닙니다.

만약 Fable 5를 로컬 시스템과 비교한다면, 로컬 모델의 이름을 정확히 명시하십시오. "Fable 5 vs colibri를 통한 GLM-5.2"라고 하는 것이 정직한 표현입니다. 가중치(weights), 라이선스(license), 런타임(runtime), 하드웨어(hardware), 그리고 속도가 모두 명시되지 않는 한, "내 노트북에서 실행되는 프런티어 모델(Frontier model)"이라는 표현은 정직하지 않습니다.

나의 실질적인 견해

만약 내가 오늘 선택해야 한다면, 이것을 추상적인 관점에서 GPT-5.6 대 Fable 5의 대결로 프레임화하지 않을 것입니다.

대신 이를 두 가지 통합 스타일(integration styles)로 프레임화할 것입니다.

모델 변체(model variants), 추론 노력(reasoning effort), 그리고 API 측 실행 선택 사항에 대해 명시적인 제어(explicit control)를 원한다면 GPT-5.6가 매력적으로 보입니다. Anthropic의 가장 널리 출시된 최상위 Claude 모델을 원하며, 거부(refusal) 및 폴백(fallback) 의미론(semantics)을 고려하여 설계할 의향이 있다면 Fable 5가 매력적으로 보입니다.

어느 쪽을 선택하든 지루한 작업(dull work)을 피할 수는 없습니다.

버그 수정(bug fixing)을 위한 워크플로우는 단순하게 유지됩니다: 실패하는 테스트, 관련 파일, 기대되는 동작, 재현 단계(reproduction steps), 그리고 권한 경계(permission boundaries)를 제공하십시오. 가장 작은 패치(patch)를 요청하십시오. 패치를 실행하십시오. 만약 모델이 버그를 재현하지 못한다면, 모델이 해결책을 지어내도록 내버려 두지 마십시오.

출시 초기 모델 비교(launch-window model comparisons)에서 발생하는 진짜 버그는 대개 모델 내부에 있는 것이 아닙니다.

그것은 우리가 트레이스(traces) 대신 스크린샷을 비교하는 방식에 있습니다. 우리는 하네스(harnesses) 없이 점수를 인용합니다. 우리는 안전 행동(safety behavior)을 어리석음으로 취급합니다. 우리는 로컬 추론(local inference)을 모델의 이름이 중요하지 않은 것처럼 취급합니다. 그러고 나서 설정 하나가 누락된 무게에 결론이 무너질 때 우리는 충격을 받습니다.

향후 48시간 동안 제가 지킬 지루한 규칙은 다음과 같습니다: 모델을 고정(pin)하고, 설정을 기록(log)하며, 대화 기록(transcripts)을 보존하고, 거부(refusal)와 오답(wrong answer)을 분리하며, 리포지토리(repo)가 실제 가중치(weights)를 명시할 때까지 모든 노트북의 주장을 불신하는 것입니다.

덜 극적이지만,

훨씬 더 유용합니다.