최근 개발자 사이에서는 에이전트형 코딩 도구를 쓰는 사람들이 앤트로픽의 가격에 부담을 느껴 대안 모델로 옮겨 가고 있다는 이야기가 오간다. 한 개발 블로그(dbreunig.com)의 글쓴이는 이 흐름을 보며, Fable이라는 고성능 모델이 나온 직후 스스로 떠올렸던 생각을 다시 꺼냈다. 이제 '공짜 점심(free lunch)'의 시대가 끝났다는 것이다. 이 표현은 하드웨어 성능이 저절로 좋아지던 시절이 저물었음을 지적한 소프트웨어 엔지니어 허브 서터(Herb Sutter)의 유명한 에세이에서 빌려온 것이다.
무어의 법칙이 남긴 교훈
무어의 법칙이 유효하던 시절에는 코드를 악착같이 최적화할 이유가 크지 않았다. 18개월만 기다리면 성능이 두 배인 CPU가 나와 문제를 대신 해결해 주었기 때문이다. 그러나 2000년대 중반 들어 단일 스레드 성능 향상이 정체되자 상황이 달라졌다. 개발자들은 병렬화, 아키텍처, 메모리 지역성(memory locality) 같은 문제를 직접 고민해야 했고, 결국 '어떤 작업을 어디에 배치할 것인가'를 따지기 시작했다.
글쓴이는 이 구도가 지금의 대규모 언어모델 생태계에서 되풀이되고 있다고 본다. Fable이 등장하기 전까지는 코딩 하네스(harness)나 컨텍스트 전략을 다듬는 데 시간을 쏟는 일이 다소 부질없게 느껴졌다. 어차피 비슷하거나 더 저렴한 가격의 신모델이 나와 대부분의 문제를 덮어 주었기 때문이다. 하드웨어 성능이 알아서 좋아지던 시절과 똑같은 심리였다.
Fable이 바꾼 계산법
Fable은 출시 당시에도, 그리고 지금도 대단히 뛰어난 모델로 평가된다. 문제는 비용이 너무 높다는 점이다. 실제로 많이 필요한 코드 작업에는 Opus를 비롯해 5.6, K3, 심지어 GLM 같은 모델도 '충분히 좋았다'. 최고 성능이 아니어도 대다수 업무가 돌아간다면, 굳이 가장 비싼 모델에 모든 작업을 흘려보낼 이유가 사라진다. 그래서 다시 '어떤 작업을 어디로 보낼 것인가'라는 질문이 돌아왔다.
글쓴이가 특히 주목하는 것은 Fable과 같은 주에 나온 GLM 5.2다. 비용이 Fable의 약 9분의 1, Opus 5의 약 5분의 1 수준이라고 한다. 그렇다면 GLM의 품질이 Fable의 9분의 1이냐고 물으면, 특정 유형의 작업에서는 그럴 수도 있다. 하지만 반복적이고 정형화된 코딩이라면 충분하고도 남는다는 것이 그의 판단이다. 특히 좋은 컨텍스트가 함께 주어질 때 그렇다. 그는 먼저 Fable과 대화하며 설계를 캐묻고 다듬은 뒤, 정리된 작업 지시서를 GLM에 넘기는 방식을 자주 쓴다고 밝힌다. 값비싼 모델은 사고와 설계에, 저렴한 모델은 실행에 쓰는 역할 분담인 셈이다.
값이 내리면 다시 큰 모델로 돌아갈까
이에 대해 흔히 나오는 반론은, 추론 비용이 계속 떨어지면 결국 모든 작업을 다시 가장 큰 모델로 몰아넣게 되리라는 것이다. 글쓴이는 여기에 확신을 갖지 못한다. 같은 비용 절감의 흐름은 K3나 Qwen 같은 모델에도 똑같이 적용되고, 하네스가 더 정교해질수록 상대적으로 약하지만 여전히 훌륭한 모델에 충분한 컨텍스트를 주기가 쉬워지기 때문이다. 격차가 좁혀지는 쪽이 아니라, 작은 모델을 잘 쓰는 기술이 함께 발전하는 쪽에 무게를 두는 셈이다.
비용 외에 또 하나의 변수가 이 변화를 굳힌다. Fable이 함께 몰고 온 충격, 즉 접근 통제, 동적 성능 저하(dynamic degradation), 강제적인 데이터 보존 정책이다. 이런 조건은 적지 않은 기업과 국가로 하여금 자신들의 추론 기록(trace)을 어디로 보내고 토큰을 어디서 조달할지 다시 따져 보게 만들었다. 성능과 가격만이 아니라 데이터 주권과 통제권까지 모델 선택의 기준으로 들어온 것이다.
한국 실무자에게 이 논의가 주는 함의는 분명하다. 단일 최상위 모델에 모든 것을 맡기던 관행에서 벗어나, 작업 성격에 따라 모델을 나누는 라우팅 전략과 컨텍스트 설계 역량이 실질적인 경쟁력이 된다는 점이다. 다만 원문은 개인 개발자의 경험과 판단에 기반한 관점이며, 언급된 비용 배수나 품질 평가는 특정 시점의 상황일 뿐 정량적으로 검증된 벤치마크는 아니라는 한계도 함께 읽어야 한다. 조직이라면 데이터가 어디에 남는지, 모델 성능이 조용히 조정될 여지는 없는지까지 계약과 아키텍처 차원에서 점검하는 편이 안전하다.