Qwen 3.8 설치 전 확인할 것 - 세 갈래 버전 차이와 24GB VRAM 실제 요건

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

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

Qwen 3.8은 이름이 세 개였습니다

처음에 제일 헷갈렸던 게 이거였습니다. Qwen 3.8 써봤다는 글들을 읽으면서 계속 같은 모델 얘기인 줄 알았는데, 읽다 보면 어떤 사람은 API를 쓰고 있고 어떤 사람은 자기 그래픽카드에 올려놨습니다. 알고 보니 이름이 세 개였습니다.

맨 위에 Qwen 3.8-Max가 있습니다. 8월 초에 API로 열렸고, 전체 파라미터는 엄청나게 큰데 토큰마다 실제로 쓰는 건 그중 일부인 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를 올리고도 컨텍스트에 여유가 생기니까, 오래 쓸 생각이면 그쪽이 편할 것 같습니다.

이것도 결국 일의 크기 얘기 같습니다. 파일 하나 보여주고 고쳐 달라는 일이면 컨텍스트가 짧아도 충분하고, 저장소 전체를 물려서 뭘 찾으라는 일이면 24GB로는 모자랍니다. 262K는 모델이 받을 수 있는 최대치이고, 제 카드에서 실제로 쓸 수 있는 건 그보다 한참 아래일 겁니다. 그러면 처음부터 큰 일은 API에 맡기고 짧은 일만 로컬에 두는 식으로 나누는 게 맞을 수도 있겠다는 생각이 듭니다. 로컬에 다 올리겠다고 욕심을 내면 카드를 바꾸는 얘기로 넘어가는데, 그 돈이면 API를 꽤 오래 쓸 수 있습니다.

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

config.json을 열어보니

알아보다가 제일 오래 붙잡고 있던 게 여기였습니다.

받기 전에 모델 카드를 읽다가 버릇처럼 config.json을 열어봤는데 첫 줄이 이랬습니다.

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

3.8인데 자기를 qwen3_5라고 부르고 있었습니다. 오타인가 싶어서 넉 달 전에 나온 3.6-27B의 config를 같이 열어봤습니다. 그쪽도 qwen3_5였고 그 밑의 값들도 같았습니다. 레이어 수, hidden size, vocab 크기, 컨텍스트 길이, 어텐션 헤드 수, intermediate 크기까지 다 같았고, 선형 어텐션 세 개에 풀 어텐션 하나가 반복되는 패턴도 그대로였습니다. 적어도 구조로는 같은 모델이었습니다.

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로 쓰면 이게 돈 문제가 됩니다. 생각한 만큼 출력 토큰이 나가니까요. 기본값 그대로 쓰면 같은 질문에 나오는 청구액이 몇 배가 됩니다.

요즘 새 모델을 볼 때는 이런 걸 봐야 하는 것 같습니다. 파라미터 수는 검색하면 어디든 나오는데, 기본값이 뭐로 박혀서 나왔는지는 모델 카드를 직접 열어야 보입니다. 그리고 처음 써봤을 때 느낌을 정하는 건 대개 뒤쪽입니다.

기본값을 최대치로 박아 둔 건 만드는 쪽에서 보면 이해가 갑니다. 처음 써보는 사람한테 제일 좋은 결과를 보여주고 싶을 테니까요. 그런데 쓰는 쪽에서 보면 모든 질문에 제일 오래 생각하라고 시켜 둔 셈입니다. 변수 이름 하나 물어보는 데도, 커밋 메시지 한 줄 써달라는 데도 xhigh로 생각합니다. 이 정도 일에 이만큼 생각할 일인가는 모델이 대신 따져 주지 않으니 쓰는 사람이 정해야 합니다. 저는 기본값이 그 판단을 대신해 줬다고 믿고 넘어가기 쉽다는 게 더 걸립니다. 기본값은 대개 그냥 두게 되니까요. 그리고 그냥 둔 기본값으로 느려졌다, 비싸졌다는 인상이 굳어 버리면 나중에 값을 내려 봐도 그 인상은 잘 안 바뀝니다.

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

라이선스가 두 가지였습니다

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

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

2.4T-A95B는 다릅니다. Apache도 MIT도 아니고 Qwen이 따로 만든 라이선스가 붙었습니다. 저작권 표시를 유지하라는 건 익숙한데, 그 뒤에 조건이 두 개 더 있습니다. 사용자나 매출이 아주 큰 조직은 모델 이름을 눈에 띄게 표시해야 하고, MaaS나 AI 업무 어시스턴트를 하는 사업체 중 매출이 일정 규모를 넘으면 라이선스를 따로 받아야 합니다.

개인이 집에서 돌리는 데는 상관없는 조항들이고, 저도 해당 안 됩니다. 그래도 마음에 걸린 건 다른 이유였습니다. 오픈웨이트라는 말이 이제 한 가지 뜻이 아니게 된 것 같습니다. 예전에는 가중치를 공개했다고 하면 Apache나 MIT를 붙였고, 그러니 공개했다는 말과 마음대로 쓸 수 있다는 말이 같은 뜻이었습니다. 지금은 같은 회사가 비슷한 때에 푼 두 모델의 조건이 서로 다릅니다. 받을 수 있다는 것과 쓸 수 있다는 게 따로 놀기 시작한 겁니다. 이름에 오픈이 붙어 있으니 자유롭겠거니 하고 넘어가기 쉬운데, 이제는 그 이름만 보고는 아무것도 장담할 수 없게 된 것 같습니다.

그래서 깔기 전에 확인할 목록에 라이선스가 새로 들어왔습니다. 예전에는 안 봤습니다. 오픈웨이트라고 적혀 있으면 그걸로 끝이었으니까요. 회사에서 쓸 거라면 더 그렇습니다. 나중에 법무 검토에서 걸리면 그 모델에 맞춰 짜놓은 게 다 헛일이 되니까요.

Fable 5.1은 어제 나왔습니다

원래 계획에는 없었는데 어제 나와버렸습니다.

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

발표에서 앞세운 건 가격, 데이터 보존, 세이프가드 세 가지였습니다. 성능 쪽에서는 과학 연구를 다루는 능력이 Fable 5보다 거의 두 배가 됐다는 게 제일 크게 나왔고, 에이전틱 코딩과 지식 노동 쪽 점수도 올랐습니다. 그런데 개발자 입장에서 정말 의미 있는 건 그 뒤에 있었습니다.

그 전에 하나 눈에 띈 게 있었습니다. 이번 발표 페이지가 평소 앤트로픽 블로그와 생김새가 달랐습니다. 색을 바꿀 수 있고, 옆에 챕터가 붙어 있고, 벤치마크 표를 스크롤하면 헤더가 위에 붙어 있습니다. 후기를 쓴 사람도 이걸 보고 Fable로 만든 것 같다고 했습니다.

저는 이게 발표 내용보다 더 눈에 들어왔습니다. 모델을 소개하는 페이지를 그 모델로 만들어 놓은 셈이니까요. 코딩이 좋아졌다는 말을 벤치마크 표로 보여주는 대신 페이지 자체를 내놓은 겁니다. 표는 자기가 매긴 점수라 별로 믿음이 안 가는데, 페이지가 실제로 잘 돌아가면 보는 사람이 스크롤해 보는 걸로 바로 알 수 있습니다. 저는 이쪽이 표보다 정직하다고 느꼈습니다.

그렇다고 잘 만든 랜딩 페이지 하나가 보여주는 게 많지는 않은 것 같습니다. 스크롤 애니메이션이나 고정 헤더는 예쁘게 만들기 쉬운 편이고, 실제로 개발에서 시간을 잡아먹는 건 그런 게 아닙니다. 상태 관리가 꼬이고, 예외 케이스가 열 개씩 튀어나오는 쪽이요. 페이지가 예쁘다고 그쪽까지 좋아졌다고 읽기는 어렵습니다.

싸졌다는 말

여기서 제가 한 번 헛다리를 짚었습니다. 처음에 가격표를 열어봤더니 입력과 출력 정가는 그대로였고 캐시 읽기만 4분의 1로 내려가 있었습니다. 그래서 정가는 안 내렸으니 별로 안 싸졌다고 생각했습니다.

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

앤트로픽이 낸 차트를 보면 가로축이 비용이고 세로축이 점수입니다. 여기서 봐야 하는 건 단가가 아니라 같은 점수까지 가는 데 드는 돈이었습니다. Fable 5가 xhigh로 내던 점수를 5.1은 low로 냅니다. 단가가 한 푼도 안 내려도 낮은 단계로 같은 결과가 나오면 실제로 내는 돈은 3분의 1이나 4분의 1이 됩니다.

그러니까 지금 싸졌다는 말이 세 가지 다른 뜻으로 쓰이고 있는 것 같습니다. API 정가는 안 내렸습니다. 캐시 읽기 단가는 크게 내렸고, 앤트로픽은 일반적으로 쓰면 25%쯤, 도구 호출이 많은 에이전트 작업에서는 그보다 더 아낀다고 했는데, 이건 API 얘기라서 구독으로 쓰는 사람한테는 상관이 없습니다. 발표 문구에서는 이 구분이 잘 안 보입니다. 그리고 같은 결과에 드는 전체 비용이 3분의 1에서 4분의 1로 줄었는데, 대부분 사람이 실제로 느끼는 건 이쪽입니다.

셋이 다른 얘기인데 다 싸졌다로 뭉쳐서 돌고 있습니다. 그래서 자기가 어떻게 쓰느냐에 따라 싸진 게 느껴지기도 하고 전혀 안 느껴지기도 합니다. 구독으로만 쓰는 사람이 캐시 인하 기사를 보고 기대했다면 아무 변화도 못 느꼈을 겁니다.

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

이번에 알아보면서 제일 재밌었던 건 여기였습니다.

실제로 써본 후기를 두 개 봤는데 처음엔 둘이 서로 다른 말을 하는 것처럼 보였습니다.

한쪽은 애플 사이트를 그대로 따라 만드는 작업 한 시간과 분자 시뮬레이터를 만드는 작업 세 시간을 이어서 돌렸는데 주간 사용량이 16%밖에 안 나갔다고 했습니다. Fable 5였으면 절반은 넘게 썼을 거라는 느낌이었다고요. 확실히 토큰을 덜 쓴다는 얘기였습니다.

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

둘이 부딪히는 얘기가 아니었습니다. 자기 검수 루프를 도니까 시간은 더 걸리고, 그렇게 해서 결과가 좋아지니 낮은 단계로도 목표까지 가고, 그래서 전체 토큰은 줄어듭니다. 같은 단계끼리 맞대면 5.1이 출력 토큰을 훨씬 많이 쓴다는 측정도 있었습니다. 같은 xhigh끼리 놓으면 오히려 비싸고, 같은 점수를 목표로 하면 훨씬 쌉니다.

이걸 보면서 비싸다 싸다를 모델 단위로 말하는 게 점점 의미가 없어진다는 생각이 들었습니다. 같은 모델이 low로 돌면 싸고 xhigh로 돌면 비쌉니다. 그러면 비교해야 하는 건 모델과 모델이 아니라, 이 일에 필요한 만큼만 생각하게 했을 때 드는 값입니다. 그 값은 일마다 다르니 가격표에 적힐 수가 없습니다. 가격표를 아무리 읽어도 제 청구서가 어떻게 될지 잘 안 보였던 게 그래서였던 것 같습니다.

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

30분을 기다려도 되는 일이면 그냥 이득입니다. 밤에 걸어놓고 자면 되니까요. 그런데 대화하면서 짜는 일이면 얘기가 다릅니다. 30분 기다렸다가 방향이 틀린 걸 알면 그 30분이 통째로 날아갑니다. 앞의 후기에서도 한 시간 작업 중 처음 30분이 생각하는 시간이었다고 했는데, 그 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로 다섯 장면을 이어지는 프로젝트로 만들라는 요청이었습니다. 개인 섬 위 미래형 맨션 바깥을 도는 장면, 다이아몬드 샹들리에가 있는 대연회장, 워터파크가 딸린 수영장, 람보르기니 열 대가 있는 차고, 옥상 헬리콥터 착륙장이요.

작성자는 Fable 5.1, Grok 4.6, Fable 5, 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 출시 수치들도 앤트로픽이 직접 낸 값입니다. 그리고 알리바바가 기준으로 삼은 Fable 5는 어제 5.1로 바뀌었습니다. 8월에 세운 비교 대상이 9월에 바뀐 거죠.

제3자 지표로 보면 그림이 좀 다릅니다. Artificial Analysis에서 Qwen 3.8-Max는 Kimi K3와 거의 붙어 있고, 작업당 비용은 오히려 Kimi 쪽이 낮습니다. 발표 문구에서 느껴지던 순위와는 온도가 다릅니다.

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

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

깔기 전에 지금 생각

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

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

집에서 하는 일 중에 Max급이 꼭 있어야 하는 일은 사실 별로 없을 것 같습니다. 27B로 안 되는 일이 생기면 그때 API로 큰 모델을 부르면 됩니다. 제일 큰 걸 미리 받아 두는 건 쓸 일이 생기기 전에 장비부터 사 두는 것과 비슷하고, 그렇게 사 둔 장비는 대개 책상 밑에서 놀게 됩니다. 일이 먼저 있고 모델은 그다음에 고르는 게 순서인 것 같습니다.

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

싸졌다는 말은 조건을 붙여서 들어야 할 것 같습니다. 어떤 뜻으로 싸진 건지, 그게 제가 쓰는 방식에 해당하는지를 보고 나서야 판단이 됩니다. 세 가지 뜻이 다 다르고, 하나는 API 쓰는 사람만 해당되고, 하나는 시간을 더 쓰고 얻는 겁니다.

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

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