요즘 개발자 사이에 핫한 Qwen 3.8, 그리고 새로 발표된 Fable 5.1

Qwen 3.8 이야기가 몇 주째 도는데 저는 아직 안 깔았습니다. 받아서 돌려보고 쓰는 게 순서인 건 알지만, 27B 짜리 하나 받는 데 20분 가까이 걸리고 그거 돌리려고 다른 거 다 내려야 하니 손이 안 갔습니다. 그래서 깔기 전에 뭐가 어떻게 바뀐 건지부터 찾아봤습니다.

그러다 어제 Fable 5.1 이 나왔습니다. 원래는 Qwen 이야기만 하려고 했는데, 둘을 나란히 놓고 보니까 각각 볼 때는 안 보이던 게 하나 보였습니다. 두 회사가 같은 방향으로 갔습니다. 모델을 더 오래 생각하게 만들어놓고, 그 대신 같은 결과를 얻는 데 드는 값을 내렸습니다. 그래서 "싸졌다" 는 말과 "느려졌다" 는 말이 동시에 참이 되는 상황이 됐습니다.

정리하면서 든 생각까지 같이 적어둡니다. 설치나 도입을 앞두고 저처럼 먼저 알아보시는 분한테는 쓸 데가 있을 것 같습니다.

Qwen 3.8 은 하나가 아니라 세 갈래로 나왔습니다

이게 첫 번째로 헷갈렸던 부분입니다. "Qwen 3.8 써봤다" 는 글을 읽으면서 저는 계속 같은 모델 이야기인 줄 알았는데, 읽다 보면 어떤 사람은 API 를 쓰고 있고 어떤 사람은 자기 그래픽카드에 올려놨습니다. 알고 보니 이름이 세 개입니다.

Qwen 3.8-Max 가 맨 위에 있습니다. 8월 3일에 API 로 열렸습니다. 총 파라미터가 2.4T 인데 토큰마다 실제로 쓰는 건 95B 정도인 MoE 구조입니다. 컨텍스트는 1M 이고, 이미지도 받습니다. 이건 가중치를 안 주니까 그냥 API 로 쓰는 모델입니다.

Qwen 3.8-27B 가 그 아래 있고, 제 관심은 사실 여기 하나였습니다. 8월 중순에 Hugging Face 에 올라왔고 라이선스가 Apache 2.0 입니다. 네이티브 컨텍스트가 262K 이고 비전이 들어 있습니다. 4비트로 줄이면 19GB 근처라서 24GB 카드 한 장에 들어갑니다.

Qwen 3.8-2.4T-A95B 라는 게 하나 더 있습니다. Max 급 체크포인트를 가중치로 풀어놓은 건데, 이게 나중에 문제가 됩니다. 뒤에서 다시 이야기하겠습니다.

세 개 중에 개발자들이 실제로 떠드는 건 대부분 27B 쪽입니다. 이유는 간단합니다. 나머지 둘은 받아도 돌릴 데가 없습니다. 2.4T 짜리를 집에서 돌린다는 건 성립하는 문장이 아닙니다.

24GB 카드 한 장이라는 말의 실제 무게

27B 가 24GB 에 들어간다는 이야기를 처음 보고 저는 별생각 없이 넘겼습니다. 그런데 이게 생각보다 큰 이야기였습니다.

24GB 는 3090 이나 4090 입니다. 중고 3090 이면 지금 백만 원 초반대에서 구할 수 있습니다. 그러니까 "프론티어 근처 모델을 로컬에서 돌린다" 는 게 서버실 이야기가 아니라 책상 이야기가 됐다는 뜻입니다. 몇 년 전만 해도 이 문장을 쓰려면 A100 을 빌려야 했습니다. 로컬 LLM 을 회사에 들여놓으면 ROI 가 나오나 를 쓸 때 계산했던 전제가 그새 많이 바뀌었습니다.

양자화 단계별로 보면 대략 이렇습니다.

정밀도	대략 필요한 VRAM
Q4_K_M	19GB 근처
Q8	33GB 근처
FP16	61GB 근처

이 표를 보면서 제가 실제로 한 계산은 다른 겁니다. 19GB 라는 건 가중치만 그렇다는 뜻입니다. 여기에 KV 캐시가 얹힙니다. 262K 컨텍스트를 다 쓰겠다고 하면 캐시가 가중치만큼 먹을 수도 있습니다. 24GB 에 19GB 를 올리고 나면 5GB 가 남는데, 그 5GB 로 컨텍스트를 얼마나 잡을 수 있느냐가 실제 사용감을 결정합니다.

그래서 "24GB 에 들어간다" 는 말은 "들어가긴 하는데 컨텍스트를 짧게 잡으면" 이라는 조건이 생략된 문장입니다. 32GB 쯤 되면 Q5 나 Q6 를 올리면서도 컨텍스트에 여유가 생기니까, 실제로 오래 쓸 생각이면 그쪽이 편할 것 같습니다.

이 부분은 제가 아직 안 돌려봤으니 남의 말을 옮긴 겁니다. 다만 로컬로 모델 올려서 며칠 써보면 대개 성능보다 이런 데서 먼저 막힌다는 건 알고 있습니다. 컨텍스트 조금 늘렸다가 OOM 으로 죽고, 그래서 줄이고, 줄이니까 긴 파일을 못 물리고, 그러다 결국 API 로 돌아가는 흐름이요.

그런데 config.json 을 열어보니 이상했습니다

여기가 알아보다가 제일 오래 붙잡고 있던 대목입니다.

받기 전에 모델 카드를 읽다가 습관적으로 config.json 을 열어봤습니다. 그런데 첫 줄이 이랬습니다.

"architectures": ["Qwen3_5ForConditionalGeneration"],
"model_type": "qwen3_5",

3.8 인데 자기를 qwen3_5 라고 부르고 있습니다. 오타인가 싶어서 넉 달 전 모델인 3.6-27B 의 config 를 같이 열어봤습니다. 그쪽도 qwen3_5 였고, 그 아래 값들도 같았습니다. 레이어 64개, hidden size 5,120, vocab 248,320, 컨텍스트 262,144. 어텐션 헤드 24개에 intermediate 17,408 까지 같았습니다. 선형 어텐션 세 개에 풀 어텐션 하나가 반복되는 패턴도 그대로였습니다.

같은 모델입니다. 적어도 구조는요.

Qwen 쪽 설명도 이걸 숨기지 않습니다. 3.6 에서 3.8 로 오면서 좋아진 건 두 가지 때문이라고 적어놨습니다. 하나는 터미널이나 저장소, 브라우저 같은 실제 환경에서 돌린 대규모 강화학습이고, 다른 하나는 위에 있는 Max 로부터 받아온 on-policy distillation 입니다. 구조를 안 건드리고 훈련만 바꿨다는 뜻입니다.

처음에는 좀 허탈했습니다. 버전이 3.5, 3.6, 3.8 로 올라가는 동안 모델 자체는 3.5 였던 거니까요. 숫자만 올린 거 아니냐는 생각이 먼저 들었습니다.

그런데 하루쯤 지나고 다시 보니 이게 생각보다 중요한 이야기 같습니다. 제가 새 모델을 볼 때 쓰던 방법이 여기서 안 먹혔기 때문입니다.

저는 새 모델이 나오면 파라미터 수를 먼저 봤습니다. 그다음 컨텍스트 길이를 보고, 아키텍처가 뭐가 바뀌었나를 봤습니다. 그게 "뭐가 달라졌는지" 를 아는 방법이었으니까요. 그런데 이번엔 그 세 개가 전부 그대로입니다. 그 방법으로 보면 아무것도 안 바뀐 모델입니다. 그런데 실제로 써본 사람들은 코딩이나 긴 작업에서 확실히 다르다고 합니다.

그러니까 제가 보던 자리가 틀렸던 겁니다. 스펙표는 이제 모델의 어느 부분도 잘 설명해주지 못합니다. 몸은 그대로 두고 훈련만 갈아서 내놓는 게 가능해졌으니까요. 그리고 훈련이 어떻게 바뀌었는지는 config 에 안 적힙니다. 적을 자리가 없습니다.

그럼 뭘 봐야 하나. 이번에 알아보면서 제가 실제로 유용했던 건 스펙이 아니라 기본값이었습니다.

기본값이 xhigh 라는 건 생각보다 큰 이야기입니다

27B 는 thinking 이 기본으로 켜져 있습니다. 요청마다 끌 수는 있는데, 안 끄면 매번 생각을 하고 답합니다. 그리고 reasoning_effort 라는 값이 있는데 기본값이 xhigh 입니다. 아래로 medium 과 low 가 있습니다.

깔고 나서 처음 던진 질문이 유독 느리게 오면 이것 때문일 겁니다. 모델이 느린 게 아니라 최대치로 생각하도록 설정된 상태로 배포된 거니까요. 저는 이걸 미리 알아서 다행이라고 생각했습니다. 안 알아봤으면 첫 응답 기다리면서 "27B 가 이렇게 느린가" 하고 잘못된 결론을 내렸을 겁니다.

API 로 쓰는 경우에는 이게 돈 문제로 넘어갑니다. 생각한 만큼 출력 토큰이 나가니까요. 기본값 그대로 쓰면 같은 질문에 청구되는 금액이 몇 배가 됩니다.

이런 게 요즘 새 모델 볼 때 실제로 봐야 하는 것 같습니다. 파라미터 수는 검색하면 어디든 나오는데, 기본값이 뭐로 박혀서 나왔는지는 모델 카드를 직접 열어야 나옵니다. 그리고 첫 사용감을 결정하는 건 후자입니다.

이 대목을 적어두고 나서 Fable 5.1 발표를 봤는데, 거기서 같은 이야기가 반대편에서 나왔습니다. 그래서 이 글이 두 모델 이야기가 됐습니다.

라이선스가 두 갈래로 갈렸습니다

앞에서 미뤄둔 이야기입니다. Qwen 3.8 의 오픈웨이트가 두 개인데 조건이 다릅니다.

27B 는 Apache 2.0 입니다. 이건 익숙한 쪽입니다. 받아서 쓰고 고치고 팔고 다 됩니다.

2.4T-A95B 는 다릅니다. Apache 도 MIT 도 아니고 Qwen 이 따로 만든 라이선스가 붙었습니다. 저작권 표시를 유지하라는 조항은 익숙한데, 그 뒤에 두 개가 더 있습니다. 월 사용자가 1억 명을 넘거나 월 매출이 2천만 달러를 넘는 조직은 모델 이름을 눈에 띄게 표시해야 합니다. 그리고 MaaS 나 AI 업무 어시스턴트를 하는 사업체 중에 최근 열두 달 합산 매출이 5천만 달러를 넘으면 별도로 라이선스를 받아야 합니다.

개인이 집에서 돌리는 데는 아무 상관 없는 조항들입니다. 저도 해당 안 됩니다. 그런데 이게 걸리는 이유는 다른 데 있습니다.

"오픈웨이트" 라는 말이 이제 한 가지를 뜻하지 않게 됐습니다. 예전에는 가중치를 공개했다고 하면 Apache 나 MIT 를 붙였고, 그러니까 공개했다는 말과 자유롭게 쓸 수 있다는 말이 같은 뜻이었습니다. 지금은 같은 회사가 같은 날짜 근처에 풀어놓은 두 모델의 조건이 다릅니다. 받을 수 있다는 것과 쓸 수 있다는 것이 갈라진 겁니다.

그래서 설치 전에 확인할 목록에 라이선스가 새로 들어왔습니다. 예전에는 안 봤습니다. 오픈웨이트라고 적혀 있으면 그걸로 끝이었으니까요. 지금은 어느 체크포인트를 받는지에 따라 조건이 다르니 봐야 합니다.

회사에서 쓸 거라면 이건 미리 확인하는 편이 낫습니다. 나중에 법무 검토에서 걸리면 이미 그 모델에 맞춰 짜놓은 게 다 헛일이 됩니다.

Fable 5.1 은 어제 나왔습니다

여기서 Fable 이야기로 넘어갑니다. 원래 계획에는 없었는데 어제 나와버렸습니다.

9월 1일에 Fable 5.1 이 나왔고, Mythos 5.1 이 같이 나왔습니다. 둘은 같은 모델인데 안전장치 수준이 다릅니다. Mythos 쪽은 기업 파트너만 쓸 수 있고, Fable 이 대중에게 열린 쪽입니다. Fable 5 가 6월 9일이었으니까 석 달 만입니다. API 뿐 아니라 Claude Code 쪽에도 바로 들어갔습니다.

발표에서 앞세운 건 세 개였습니다. 가격, 데이터 보존, 그리고 세이프가드입니다. 성능 쪽에서는 과학 연구를 다루는 능력이 Fable 5 대비 거의 두 배가 됐다는 게 제일 큰 항목이었고, 에이전틱 코딩도 올랐습니다. 지식 노동을 재는 GDPval 은 1,700점대에서 1,800점대로 올라왔습니다.

그런데 개발자 입장에서 실제로 의미가 있는 건 그 뒤에 있었습니다.

발표 페이지 자체가 데모였습니다

본문으로 들어가기 전에 하나 짚고 싶은 게 있습니다. 이번 발표 페이지가 평소 앤트로픽 블로그와 형태가 달랐습니다. 색을 바꿀 수 있고, 옆에 챕터가 붙어 있고, 벤치마크 표를 스크롤하면 헤더가 위에 고정됩니다. 후기를 쓴 사람도 이걸 보고 Fable 을 써서 만든 것 같다고 짚었습니다.

저는 이 대목이 발표 내용보다 더 눈에 들어왔습니다. 모델을 소개하는 페이지를 그 모델로 만들어놓은 셈이니까요. "코딩이 좋아졌다" 는 문장을 벤치마크 표로 증명하는 대신 페이지 자체를 증거로 내놓은 겁니다.

이게 요즘 발표 방식이 바뀌는 지점 같습니다. 예전에는 성능을 표로 보여줬는데, 표는 자기가 매긴 점수라 신뢰가 안 갑니다. 그런데 페이지가 실제로 잘 굴러가면 그건 그 자리에서 확인됩니다. 읽는 사람이 스크롤을 해보는 것으로 검증이 끝나니까요. 발표문을 읽으면서 동시에 결과물을 만지게 만드는 방식이고, 저는 이게 표보다 정직하다고 봅니다.

다만 여기에도 함정이 있습니다. 잘 만든 랜딩 페이지 하나가 증명하는 범위는 생각보다 좁습니다. 스크롤 애니메이션과 고정 헤더는 예쁘게 만들기 쉬운 쪽에 속하고, 실제로 개발에서 시간을 잡아먹는 건 그런 게 아닙니다. 상태 관리가 꼬이는 자리, 예외 케이스가 열 개씩 튀어나오는 자리요. 페이지가 예쁘다고 그쪽까지 좋아졌다고 읽으면 안 됩니다.

"싸졌다" 는 말이 세 가지 뜻으로 쓰이고 있습니다

이 대목에서 제가 한 번 헛다리를 짚었습니다. 처음에 저는 가격표를 열어봤습니다. 입력과 출력 정가는 그대로였고, 캐시 읽기만 4분의 1로 내려갔습니다. 그래서 "정가는 안 내렸으니 인하폭이 크지 않다" 고 판단했습니다.

그게 틀렸습니다. 사람들이 말하는 "3분의 1" 은 가격표에 있는 숫자가 아니었습니다.

앤트로픽이 낸 차트를 보면 X축이 비용이고 Y축이 스코어입니다. 여기서 읽어야 하는 건 단가가 아니라 같은 점수에 도달하는 데 드는 값입니다. Fable 5 에서 xhigh 로 얻던 점수를 5.1 은 low 로 얻습니다. 단가가 한 푼도 안 내려도, 낮은 단계로 같은 결과가 나오면 실제 지불액은 3분의 1이나 4분의 1이 됩니다.

그러니까 지금 "싸졌다" 는 말이 세 가지 다른 뜻으로 쓰이고 있습니다.

첫째, API 정가. 안 내렸습니다. 입력과 출력은 그대로입니다.

둘째, 캐시 읽기 단가. 75% 내렸습니다. 일반적인 사용에서 25% 정도, 도구 호출이 많은 에이전트 작업에서 최대 45% 절감이라고 앤트로픽이 밝혔습니다. 그런데 이건 API 이야기입니다. 구독으로 쓰는 사람에게는 해당 사항이 없습니다. 이 구분이 발표 문구에서는 잘 안 보입니다.

셋째, 같은 결과에 드는 총비용. 이게 3분의 1에서 4분의 1입니다. 그리고 대부분의 사람이 체감하는 건 이 세 번째입니다.

세 개가 다른 이야기인데 다 "싸졌다" 로 뭉쳐서 돌고 있습니다. 그래서 자기가 어느 쪽으로 쓰는지에 따라 인하가 체감되기도 하고 전혀 체감되지 않기도 합니다. 구독으로만 쓰는 사람이 캐시 인하 기사를 읽고 기대했다면 아무 변화도 못 느꼈을 겁니다.

그런데 싸진 게 아니라 바꾼 것 같습니다

여기가 이번에 알아보면서 제일 재미있었던 대목입니다.

실사용 후기를 두 개 봤는데, 처음엔 두 사람 말이 어긋나 보였습니다.

한쪽은 애플 사이트를 그대로 재현하는 작업 한 시간과 분자 시뮬레이터 만드는 작업 세 시간을 붙여서 돌렸는데, 주간 사용량이 16% 밖에 안 나갔다고 합니다. Fable 5 였으면 50% 는 넘게 썼을 거라는 체감이었습니다. 확실히 토큰을 덜 쓴다는 이야기였습니다.

다른 쪽은 네 모델에 같은 프롬프트를 던져서 비교했는데, Fable 5.1 이 제일 오래 걸렸습니다. 30분 정도요. 이유를 이렇게 짚었습니다. 중간에 검수하는 단계가 굉장히 많고, 자기가 한 걸 다시 보면서 스스로 루프를 돌더라는 겁니다.

두 이야기가 모순이 아닙니다. 자기 검수 루프를 도니까 시간은 더 걸리고, 그렇게 해서 결과가 좋아지니 낮은 단계로도 목표에 도달하고, 그래서 총 토큰은 줄어듭니다. 제3자 측정에서도 같은 단계끼리 맞대면 5.1 이 출력 토큰을 훨씬 많이 쓴다고 나옵니다. 같은 xhigh 끼리 비교하면 오히려 비싸고, 같은 점수를 목표로 하면 훨씬 쌉니다.

그래서 저는 이걸 "싸졌다" 보다 "바꿨다" 로 읽고 있습니다. 돈을 시간으로 바꾼 겁니다.

30분을 기다릴 수 있는 작업이면 이건 순수하게 이득입니다. 밤에 걸어놓고 자면 되니까요. 그런데 대화하면서 짜는 작업이면 이야기가 다릅니다. 30분 기다렸다가 방향이 틀렸다는 걸 알면 그 30분이 통째로 날아갑니다. 앞의 후기에서 한 시간 작업 중 첫 30분이 생각하는 시간이었고 고민과 구현이 1대 1이었다는 관찰이 나오는데, 그 30분 동안 사람은 할 일이 없습니다.

저는 요즘 속도 쪽을 더 보는 편입니다. 계획서대로 짰으면 그 버그는 그대로 나갔다 에 적었던 게 이거랑 통합니다. 계획을 오래 세우는 게 항상 좋은 게 아니고, 짧게 던져서 틀린 걸 빨리 보는 편이 나은 경우가 있습니다. 검수 루프를 많이 도는 모델은 전자에 최적화된 거고, 그게 제 작업 방식과 맞는지는 별개 문제입니다.

그리고 이게 Qwen 이야기와 같은 이야기였습니다

여기서 앞의 Qwen 대목이 다시 걸립니다.

Qwen 27B 의 reasoning_effort 기본값이 xhigh 로 박혀서 나왔습니다. Fable 5.1 은 검수 루프를 많이 돌아서 30분이 걸립니다. 두 회사가 서로 다른 라인의 모델을 내놨는데 사용자가 마주치는 건 같은 현상입니다. 모델이 예전보다 오래 생각합니다.

그리고 그 대가를 받아내는 방식도 같습니다. 오래 생각하는 만큼 결과가 좋아지니까, 같은 결과를 목표로 하면 값이 내려갑니다. Fable 은 낮은 단계로 같은 점수를 내는 걸로, Qwen 은 구조를 안 바꾸고 훈련만 갈아서 27B 짜리를 그 자리까지 끌어올리는 걸로요.

그러니까 이번 두 릴리스가 말하는 건 같은 문장 같습니다. 모델을 더 크게 만드는 경쟁에서 더 오래 생각하게 만드는 경쟁으로 넘어갔다는 것. Qwen 의 config 가 세 버전째 그대로인 게 그 증거처럼 보입니다. 몸을 안 키우고도 올릴 데가 남아 있다는 판단이니까요.

그래서 설치 전에 봐야 할 것도 달라졌습니다. 파라미터 수와 컨텍스트 길이는 이제 별 정보가 아닙니다. 대신 기본 effort 가 뭐로 박혀 있는지, 그걸 어디까지 내릴 수 있는지, 내리면 품질이 어디서 무너지는지를 봐야 합니다. 그리고 이건 스펙표에 안 적힙니다. 직접 돌려봐야 나옵니다.

세이프가드가 무해한 요청을 막는 일이 있습니다

이건 미리 알아둘 만해서 적습니다.

앞의 후기에서 분자 시뮬레이터를 만들려고 프롬프트를 넣었는데 플래그가 걸렸다고 합니다. 윤리 기준에 맞지 않으니 프롬프트를 바꾸거나 다른 모델을 쓰라는 메시지가 나왔다고요. 화학무기 같은 걸 막으려고 넣은 장치일 텐데, 실제로 넣은 요청은 분자 상호작용을 시각화하는 것이었습니다. 프롬프트를 고쳐서 우회했고, 또 걸려서 또 고쳤습니다.

그런데 나중에 같은 프롬프트가 그냥 통과됐습니다. 판정이 일관되지 않다는 뜻입니다.

실용적으로는 이렇게 정리됩니다. 막혔다고 포기하지 말고 몇 시간 뒤에 같은 걸 다시 던져보면 될 수도 있습니다. 이건 알아두면 시간을 아낍니다.

그런데 후기에서 짚은 대목이 더 날카로웠습니다. Mythos 계열을 플래깅 없이 쓰는 소수 회사가 있다면, 그 차이가 그대로 경쟁 우위가 된다는 것. 같은 모델인데 안전장치 수준만 다른 두 버전을 내놓고 한쪽만 파트너에게 준다는 구조가 실제로 그렇습니다.

저는 이 지적이 맞다고 봅니다. 그리고 이게 로컬 모델을 굳이 보는 이유 중 하나이기도 합니다. 27B 를 내 카드에 올려놓으면 이런 판정을 안 받습니다. 성능이 프론티어보다 낮은 건 알지만, 막히지 않는다는 것 자체가 어떤 작업에서는 성능보다 중요합니다. 내 커밋 92%는 남의 데이터센터 위에 있다 에서 걱정했던 것과 결이 같은 이야기입니다.

시스템 프롬프트가 유출됐고 거기서 방향이 보였습니다

나온 지 얼마 안 됐는데 벌써 5.1 의 시스템 프롬프트가 유출됐습니다. Fable 5 것과 비교한 정리를 봤는데, 제일 크게 바뀐 게 메모리 시스템이었습니다.

프로필, 토픽, 영역, 사람, 성능 같은 범주로 나눠서 구조적으로 저장한다고 합니다. 위키처럼 항목을 쪼개놓는 방식이요. 과거 대화 검색, 스킬과 플러그인 추천, 도구 사용 규칙, 웹 검색 강화도 같이 들어갔고, 답변 스타일은 간결한 쪽으로 갔습니다. 저작권과 IP 규칙은 더 엄격해졌고, 대화 종료 안전장치가 새로 추가됐습니다.

이걸 보면서 든 생각은 모델 성능 이야기가 아니라 하네스 이야기라는 것입니다. 메모리를 범주로 쪼개서 저장하고 필요할 때 꺼내는 건 모델 안에서 일어나는 일이 아니고 그 위에 씌운 구조에서 일어나는 일입니다. 그런데 그 구조가 사용감의 상당 부분을 결정합니다.

저도 샌드박스 에이전트들이 폴더 이름으로 대화했다 를 쓰면서 비슷한 걸 했습니다. 파일로 상태를 남기고 다음 세션이 그걸 읽게 하는 구조요. 그게 이제 모델 쪽 기본 장비로 들어가고 있는 것 같습니다.

같은 프롬프트로 네 모델을 비교한 걸 봤습니다

후기 중 하나가 네 모델에 같은 프롬프트를 던졌습니다. Three.js 로 다섯 장면을 연속 프로젝트로 만들라는 요청이었습니다. 개인 섬 위의 미래형 맨션 외부 궤도, 다이아몬드 샹들리에가 있는 대연회장, 워터파크가 있는 수영장, 람보르기니 열 대가 있는 차고, 옥상 헬리콥터 착륙장.

작성자 판단으로 1등이 Fable 5.1, 2등이 Grok 4.6, 3등이 Fable 5, 4등이 GPT 5.6 이었습니다. Fable 5.1 은 제일 오래 걸렸는데 결과가 제일 좋았고, 헬리콥터가 야간에 착륙하는 장면까지 나왔다고 합니다. GPT 쪽은 요청을 잘못 이해해서 이미지를 만들려 했고, 만든 결과물은 마우스 조작이 아예 안 됐습니다.

이 비교를 보면서 제가 실제로 유용했던 건 순위가 아닙니다. 프롬프트 하나로 낸 결과라는 점입니다. 작성자도 그렇게 밝혔습니다. 프롬프트 하나로는 순위를 정할 수 없습니다. 다만 "이 정도 복잡도의 작업을 한 번에 던지면 대략 어떤 그림이 나오는지" 는 알 수 있고, 그건 벤치마크 표보다 감이 잡힙니다.

GPT 쪽이 헤맨 대목도 재료로는 쓸모가 있었습니다. Three.js 로 만들라는 요청을 이미지 생성으로 받았고, 지적을 받고 나서는 다른 도구로 넘기려 했습니다. 이건 성능이 낮아서 생긴 일로 보이지 않습니다. 요청을 자기가 잘하는 형태로 바꿔서 받은 것에 가깝습니다. 모델을 붙여 쓰다 보면 이 습성이 성능보다 더 자주 문제가 됩니다.

제3자 지표로는 Artificial Analysis 가 5.1 을 1위로 올렸습니다. 그 아래로 Opus 5, Fable 5, GPT 5.6 순입니다. 가장 비싸면서 성능도 제일 좋은 자리에 있다는 게 그쪽 정리였습니다. 주식 분석에 모델 셋을 붙여 서로 검증시켰다 를 하면서 배운 게 하나 있는데, 모델을 여러 개 붙여서 비교하는 작업은 결과보다 어디서 갈리는지를 봐야 쓸모가 있습니다. 이 비교에서 갈린 자리는 결과물의 완성도가 아니라 조작이 되느냐였습니다. 넷 중 둘은 마우스 컨트롤이 안 됐습니다.

점수는 양쪽 다 자기가 매겼습니다

이건 짚어두는 편이 좋을 것 같습니다.

알리바바는 3.8-Max 를 내놓으면서 Fable 5 다음이라고 했습니다. 그런데 그 순위는 알리바바 내부 평가에 근거한 거고, 공식 벤치마크 표는 아직 안 나왔습니다. Fable 5.1 의 출시 수치들도 자기가 보고한 값입니다.

어느 쪽도 제3자가 채점한 게 아닙니다. 그리고 알리바바가 기준으로 삼은 Fable 5 는 어제 5.1 로 갱신됐습니다. 8월에 세운 비교 대상이 9월에 바뀐 거죠.

제3자 지표를 보면 그림이 좀 다릅니다. Artificial Analysis 기준으로 Qwen 3.8-Max 는 Kimi K3 와 1점 차이로 붙어 있습니다. 발표 문구에서 느껴지는 순위와 온도가 다릅니다.

이걸 보면서 든 생각은 점수가 틀렸다는 게 아닙니다. 자기가 낸 점수는 자기가 잘하는 쪽을 골라서 낸 점수라는 것이 당연한데, 그걸 자꾸 잊는다는 겁니다. 벤치마크 표를 보면 숫자가 객관적으로 생겨서 그렇습니다. 어느 벤치를 표에 넣고 어느 벤치를 뺐는지는 표에 안 적히니까요.

그래서 저는 새 모델 나왔을 때 점수를 보는 시간을 좀 줄이기로 했습니다. 어차피 며칠 지나면 실제로 써본 사람들 이야기가 올라옵니다. 그게 표보다 정확합니다. 이번에도 그랬습니다. 제가 가격표를 잘못 읽고 있던 걸 후기 두 개가 고쳐줬습니다.

그래서 지금은 이렇게 보고 있습니다

깔기 전에 알아본 걸 정리하니 결국 남은 건 몇 개 안 됩니다.

27B 는 받아볼 만한 것 같습니다. 24GB 카드가 있으면 Q4 로 올려보고, 컨텍스트를 어디까지 잡을 수 있는지가 첫 관문일 겁니다. Apache 2.0 이니까 라이선스는 신경 안 써도 됩니다. 다만 첫 응답이 느리다고 놀라지 말고 reasoning_effort 를 먼저 medium 으로 내려보는 게 순서 같습니다. 기본값이 최대치라는 걸 모르고 성능을 판단하면 틀립니다.

Max 급 체크포인트는 받을 이유가 별로 없어 보입니다. 돌릴 장비가 없고, 라이선스도 조건이 붙습니다. 그거 받을 여력이 있으면 API 를 쓰는 게 맞을 것 같습니다.

Fable 5.1 은 이미 쓰고 있으니 따로 설치할 게 없습니다. 대신 두 가지는 확인할 생각입니다. 하나는 캐시를 어떻게 쓰고 있는지입니다. 인하분이 거기로만 들어왔으니, 구독으로만 쓰고 있으면 싸졌다는 이야기가 저한테는 해당이 안 됩니다. 다른 하나는 effort 를 얼마나 내려도 되는지입니다. 낮은 단계로 같은 점수가 나온다는 게 이번 릴리스의 요점이면, 기본값으로 계속 돌리는 건 그 이득을 안 받는 셈이 됩니다.

"싸졌다" 는 말은 조건부로 받아들이는 게 맞을 것 같습니다. 어느 뜻으로 싸진 건지, 그게 내 사용 방식에 해당하는지를 보고 나서야 판단이 됩니다. 세 가지 뜻이 다 다르고, 그중 하나는 API 사용자만 해당하고, 하나는 시간을 더 쓰는 대가로 얻는 겁니다.

아직 안 본 게 하나 남았습니다. 27B 를 실제로 올려놓고 며칠 쓰면 벤치에 안 나오는 게 나올 겁니다. 긴 파일을 물렸을 때 어디서 흐트러지는지, 한국어로 물으면 영어로 물을 때랑 얼마나 다른지, 도구 호출을 시켰을 때 몇 번째에서 엉키는지. 이런 건 남의 글로는 안 채워집니다. 그건 받아본 다음에 적겠습니다.

Fable 쪽도 그렇습니다. 검수 루프를 많이 돈다는 관찰은 이해가 되는데, 그게 제 작업에서 이득인지 손해인지는 아직 모르겠습니다. 30분 기다리는 게 아까운 작업이 저한테는 꽤 많습니다. 반대로 밤에 걸어놓고 아침에 확인하면 되는 작업도 있으니, 결국 작업을 두 종류로 나눠서 effort 를 따로 잡아야 할 것 같습니다. 며칠 더 써봐야 알 것 같습니다.