에이전트한테 코드를 맡겼는데 2년 전 API를 써서 돌려주는 일. 매개변수 순서를 옛날 버전 기준으로 넣어놓는 일. 자동화를 굴려본 사람이면 다 겪어봤을 겁니다.
w4g1.dev에 올라온 글은 이걸 모델의 결함이 아니라 의도된 절충으로 봅니다. 제목부터 “모델은 의도적으로 더 멍청해지고 있다”입니다.
숫자로 보면 이렇습니다
추론 쪽은 확실히 좋아졌습니다. GLM-5.2는 토큰당 40B 활성 매개변수로 AIME 2026에서 99.2%, Qwen3.5는 17B로 91.3%를 냈습니다. 활성 매개변수를 이 정도로 줄이고도 나오는 점수입니다.
사실 회상 쪽은 반대입니다. 도구 없이 세부 정보를 떠올리는 SimpleQA에서 Gemini 2.5 Pro가 53%였고, Qwen3.5 4B와 9B는 Artificial Analysis 지식 평가에서 **환각률 80~82%**를 기록했습니다.
열에 여덟은 지어낸다는 뜻입니다. 이 숫자를 보고 나면 “가볍고 똑똑한 로컬 모델”이라는 말이 다르게 들립니다.
왜 이런 절충이 생기나
Physics of Language Models 실험이 모델의 사실 지식 저장 용량을 매개변수당 약 2비트로 측정했습니다. 잘 알려지지 않은 사람의 생년, 지역별 인구, npm 패키지 함수의 인수 순서 같은 걸 가중치에 다 넣으려면 매개변수가 그만큼 필요합니다.
반면 추론 절차는 종류가 적습니다. 문제를 쪼개고, 중간 상태를 추적하고, 결과를 검산하고, 실패한 단계에서 되돌아가는 것. 네 가지가 온갖 문제에 재사용됩니다. 증류와 강화학습으로 작은 모델에 옮기기도 상대적으로 쉽습니다.
그리고 사실은 빨리 낡습니다. 훈련이 끝나는 순간부터 API도 가격도 인물 소속도 어긋나기 시작하고, 이걸 고치려면 추가 학습이 필요합니다. 대수 규칙이나 두 출처의 모순 찾는 법은 그렇지 않습니다.
비싸고 느리게 갱신되는 자리(가중치)에는 오래 가는 걸 넣고, 빨리 바뀌는 건 실행 시점에 밖에서 가져오자. 글의 주장은 이 한 줄입니다.
다 빼자는 건 아닙니다
무엇을 검색해야 할지 판단하려면 기본 지식은 있어야 합니다. 글이 든 예가 명확합니다. PostgreSQL이 뭐고 어디 쓰는지, MVCC가 대충 어떻게 도는지는 알아야 하지만, 특정 Planner 기능이 몇 버전에 들어갔는지까지 외울 필요는 없다는 겁니다.
검색하기는 쉬운데 가중치에 저장하기는 비싼 것부터 밖으로 빼는 게 요지입니다.
빼낸 자리는 하네스가 채웁니다. 코딩 에이전트라면 라이브러리 API를 통째로 기억하는 대신 지금 프로젝트의 node_modules와 설치된 패키지 문서를 읽으면 됩니다. 학습 데이터에 흔했던 옛날 API가 아니라 실제 설치된 버전이 기준이 됩니다.
환각이 데이터 버그가 된다
여기가 실무자에게 제일 와닿는 대목입니다.
가중치에 잘못 박힌 지식은 손을 못 댑니다. 어디서 왔는지 추적이 안 되고, 그 하나만 고칠 방법도 없습니다. 프롬프트로 우회하거나 재학습을 기다리는 수밖에 없습니다.
외부 문서를 참조한 오류는 다릅니다. 어떤 출처를 봤는지 확인할 수 있고, 문서가 틀렸으면 고치면 다음 요청부터 반영됩니다. 회귀 테스트도 짤 수 있습니다.
불투명한 모델 기억의 문제가 평범한 데이터 버그에 가까워진다 — 이게 글이 말하는 핵심 차이입니다.
단, 글도 인정합니다. 검색을 붙여도 모델이 출처를 잘못 읽거나 여러 정보를 잘못 엮을 수 있어서 환각이 사라지진 않습니다.
반론이 만만치 않습니다
Hacker News 토론이 이 글에 꽤 박합니다. 옮길 만한 게 몇 개 있습니다.
근거 데이터가 낡았다. SimpleQA는 2025년 9월에 측정을 멈췄고, 비교에 쓴 Gemini 2.5 Pro는 16개월 된 모델입니다. “지금 돈 주고 살 수 있는 최고의 회상 능력”이 아니라는 겁니다. 검증판인 SimpleQA Verified가 따로 있습니다.
전제 자체를 못 채운다. 이게 제일 아픕니다. 모델이 사실을 모른다고 해서 반드시 검색하는 건 아닙니다. 그냥 지어낼 수도 있습니다. 이 구조가 성립하려면 모델이 자기가 모른다는 걸 알아야 하는데, 글은 그게 어떻게 개선되는지 다루지 않고 넘어갑니다.
검색 품질과 비용. 검색 엔진 의존도가 극단적으로 높아지는데 검색 품질은 나빠지는 중이라는 지적, 그리고 Google 프로그램용 검색이 1,000회당 2.50달러부터라는 계산이 붙었습니다. 매 질의마다 검색이 붙으면 이게 그대로 운영비입니다.
출처가 있다고 맞는 것도 아니다. 답을 아는 질문을 던졌더니 정반대로 답하면서 출처를 달아놨고, 확인해보니 AI 검색 최적화 쓰레기 글이었다는 경험담도 있었습니다.
글 자체가 AI 생성. Pangram 판별에서 100%로 나왔다는 지적도 있습니다. 아이러니한 지점이라 그냥 적어둡니다.
소비자 GPU 얘기는 아직 상상입니다
글이 마지막에 던지는 그림이 하나 있습니다. DeepSeek V4-Flash는 전체 284B인데 토큰당 13B만 활성화됩니다. 비활성 Expert 상당수가 사실 지식 창고 역할을 한다고 가정하면, 그걸 외부 지식으로 대체해 모델 전체를 줄일 수 있다는 겁니다. 끝까지 밀면 20~40B급을 4-bit로 양자화해 24GB GPU에서 프런티어급 추론을 돌리는 구성이 나옵니다.
솔깃하지만 글 스스로 밝힙니다. Expert 계층이 대부분 지식 저장용이라는 전제도, 그만큼 줄일 수 있다는 것도 입증된 게 아닙니다.
지금 뭘 할 수 있나
인프라를 새로 깔아 전면 도입할 단계는 아니라고 봅니다. 반론에서 나온 두 가지가 그대로 걸립니다. 모델이 모를 때 검색을 하도록 만드는 문제, 그리고 검색 비용.
다만 방향 자체는 이미 각자 쓰고 있는 것과 이어집니다. 프로젝트 문서를 에이전트에 물려주는 것, 버전 정보를 컨텍스트에 넣어주는 것 전부 같은 발상입니다.
작게 검증한다면 이런 순서겠습니다. 로컬 소형 모델에 프로젝트 의존성 문서만 붙여서, 같은 작업을 큰 모델에 맡겼을 때와 비교해보는 것. 잘 되는지보다 모를 때 검색을 하는지, 아니면 그냥 지어내는지를 보는 게 핵심입니다. 거기서 갈립니다.