이미지: dbreunig.com
요약
- 코딩 모델 Fable은 품질은 뛰어나지만 비용이 커서, 설계는 Fable에 맡기고 반복 작업은 저렴한 모델로 넘기는 사용 방식이 확산되고 있어요
- Fable과 같은 주에 나온 GLM 5.2는 비용이 Fable의 약 9분의 1, Opus 5의 약 5분의 1 수준으로 알려졌어요
- Fable의 접근 통제와 데이터 보관 정책은 일부 기업·국가가 트래픽과 토큰 처리 경로를 다시 검토하게 만든 계기로 꼽혀요
- Fable 특징
- 뛰어난 코딩 품질, 높은 비용, 접근 통제·동적 성능 저하·데이터 보관 정책 포함
- GLM 5.2 출시 시점
- Fable과 같은 주 출시로 알려졌어요
- GLM 5.2 상대 비용
- Fable 대비 약 1/9, Opus 5 대비 약 1/5 수준
- 업계 반응
- 일부 기업·국가가 트래픽·토큰 처리 경로를 재검토하는 계기가 됐어요
- 배경 비유
- 허브 서터의 2005년 에세이 '공짜 점심'과 2000년대 중반 무어의 법칙 둔화에 빗댐
- 함께 언급된 모델
- Opus 5, GPT-5.6, K3 — 대부분의 코딩 작업에 충분하다고 평가됨
새 코딩 모델 Fable이 등장한 뒤로 개발자들 사이에서 "어떤 작업을 어떤 모델에 맡길까"를 따지는 습관이 부쩍 늘었어요. 기술 블로거 dbreunig는 이 변화를 무어의 법칙이 흔들리던 시절에 빗대 설명했는데, 최근 앤스로픽 가격에 불만을 느낀 코딩 에이전트 사용자들이 대안 모델로 옮겨가는 흐름과 겹쳐 눈길을 끌고 있어요.
성능은 최고, 비용은 부담
Fable은 품질 면에서 지금까지 나온 코딩 모델 중 손꼽힐 만큼 뛰어나다는 평가를 받아요. 문제는 가격이에요. 같은 시기에 있던 Opus나 GPT-5.6, K3 같은 모델로도 대부분의 코딩 작업은 충분히 처리할 수 있었기 때문에, 굳이 모든 작업을 Fable에 맡길 이유가 크지 않았다는 거예요. dbreunig는 이 상황을 "공짜 점심은 끝났다"고 정리했어요.
이 표현은 원래 소프트웨어 엔지니어 허브 서터가 2005년에 쓴 에세이에서 따온 말이에요. 무어의 법칙이 살아 있던 시절에는 18개월만 기다리면 CPU 성능이 두 배로 뛰었으니 코드를 굳이 최적화할 필요가 없었죠. 그런데 2000년대 중반 단일 스레드 성능이 정체되면서 개발자들은 병렬화, 아키텍처, 메모리 배치 같은 걸 직접 고민해야 했어요. dbreunig는 지금 AI 코딩 모델 시장에서 똑같은 일이 벌어지고 있다고 봐요.
GLM 5.2, 같은 주에 등장한 대안
Fable과 같은 주에 나온 GLM 5.2가 이 흐름의 중심에 있어요. GLM 5.2의 비용은 Fable의 약 9분의 1, Opus 5의 약 5분의 1 수준으로 알려졌어요. 품질이 Fable에 못 미칠 수는 있지만, 반복적인 코딩 작업 대부분에는 충분하다는 게 dbreunig의 판단이에요. 그래서 그는 설계 방향을 정할 때는 Fable과 대화하고, 실제 작업 지시는 GLM에 넘기는 식으로 두 모델을 나눠 쓰고 있다고 밝혔어요.
| 모델 | 상대 비용(GLM 5.2=1) |
|---|---|
| GLM 5.2 | 1 bar:11 |
| Opus 5 | 5 bar:56 |
| Fable | 9 bar:100 |
추론 비용이 떨어지면 결국 다시 가장 큰 모델로 몰릴 거라는 반론도 있어요. 하지만 dbreunig는 비용이 내려가면 K3나 큐원(Qwen) 같은 더 저렴한 모델도 똑같이 혜택을 받고, 코딩 하네스(harness) — AI에게 작업 맥락을 제공하는 도구 체계 — 가 좋아질수록 약한 모델도 충분한 맥락만 주면 제 몫을 한다고 반박했어요.
데이터 정책이 만든 두 번째 충격
Fable이 던진 충격은 가격만이 아니에요. 접근 통제, 동적 성능 저하(dynamic degradation), 필수 데이터 보관 정책까지 갖추고 있어서 일부 기업과 국가가 자기네 작업 기록과 토큰 처리 경로를 어디로 보낼지 다시 따져보게 됐다고 dbreunig는 전했어요. 어떤 모델을 쓰느냐가 곧 어디에 데이터를 맡기느냐의 문제가 된 셈이에요.
이런 흐름은 최근 오픈AI와 앤스로픽이 중국 AI 모델들의 추격 속에 가격을 낮춘 사정과도 맞닿아 있어요.
에디터의 시선
이 글은 Fable을 깎아내리는 게 아니에요. 오히려 Fable이 너무 잘 만들어졌던 탓에 시장이 쪼개졌다는 역설을 짚고 있어요. 코딩 에이전트를 실제로 팀에 붙여본 경험으로 보면 이 판단은 낯설지 않아요. 설계 단계에서 방향을 잡을 때는 비싸도 제일 똑똑한 모델을 쓰고, 방향이 정해진 뒤 반복 작업은 훨씬 싼 모델에 넘기는 방식은 이미 여러 개발팀에서 자연스러운 루틴이 되고 있어요.
국내 개발팀 입장에서 실무적으로 챙길 건 두 가지예요. 하나는 코딩 작업을 "설계"와 "구현"으로 나눠 각각 다른 비용대의 모델에 배분하는 라우팅 전략을 미리 세워두는 것이고, 다른 하나는 어떤 모델에 어떤 데이터가 흘러가는지를 팀 차원에서 기록해두는 습관이에요. Fable처럼 데이터 보관 정책이 까다로운 모델을 계약 검토 없이 도입했다가 나중에 감사에서 문제가 되는 경우를 막으려면 이 부분을 가볍게 넘기면 안 돼요.
앞으로 몇 달 안에는 GLM, K3, 큐원 계열처럼 저렴하면서 하네스와 잘 맞물리는 모델을 조합하는 스택이 더 늘어날 거예요. 반대로 가장 비싼 최상위 모델은 설계·검증처럼 실수 비용이 큰 구간에만 쓰이는 역할로 좁혀질 가능성이 커요. 모델 하나로 전부 해결하던 시대는 이제 지나갔다고 봐도 될 것 같아요.
댓글