모든 대규모 언어 모델(LLM) 순위표는 당신을 속이고 있습니다.

Cline 팀은 자신들의 저장소(Repository)에 있는 실제 버그를 사용하여, 완전히 동일한 환경에서 GLM-5.2와 Claude Opus 4.8을 테스트했습니다.

결과는 매우 충격적이었습니다.

Opus는 속도가 3배 빠르고, 토큰(Token) 소모는 절반이며, 가격은 두 배 비쌉니다.
버그를 수정하고 모든 테스트를 통과했습니다.
하지만 프로덕션 빌드(Production Build)에서 직접적으로 무너졌으며, 발견되지 않은 타입 오류(Type Error)를 남겼습니다.

GLM은 속도가 느리고, 토큰을 67% 더 많이 사용하며, 도구 호출(Tool Call)이 2.3배 많고, 가격은 절반으로 저렴합니다.
버그를 고쳤을 뿐만 아니라, 능동적으로 데드 코드(Dead Code)를 정리했습니다.
최종 빌드는 아무런 잠재적 위험 없이 깨끗하게 통과되었습니다.

이것이 바로 순위표와 실제 세상의 차이입니다.
SWE-bench는 버그를 고칠 수 있는지 여부만 측정할 수 있습니다.
수정 후에 당신의 프로덕션 환경을 몰래 망가뜨릴지 여부는 측정할 수 없습니다.
테스트를 통과했다고 해서 코드를 사용할 수 있다는 뜻은 아닙니다.
대규모 프로젝트에서 이것은 치명적입니다.

본질은 누가 더 똑똑하냐의 문제가 아닙니다. 왜냐하면 훈련 목표가 완전히 다르기 때문입니다.
GLM은 강화학습 (RL)을 통해 검증 문화(Verification Culture)를 학습했습니다.
더 많이 소모된 토큰은 모두 빌드 실행, 타입 확인, 쓰레기 정리, 회귀 방지(Regression Prevention)에 사용되었습니다.
그것은 멍청한 것이 아니라 책임감이 있는 것입니다.
Opus는 효율적인 업무 완수를 추구하고, GLM은 한 번에 제대로 하는 것을 추구합니다.

더 주목해야 할 점은 이것이 오픈 소스 모델이라는 것입니다.
이제 더 이상 폐쇄형 모델(Closed-source Model)의 저렴한 대체품이 아닙니다.
장기 주기 코드 에이전트(Long-cycle Code Agent)의 차원에서 자신만의 차별화된 우위를 찾아냈습니다.

에이전트 시대의 가성비 논리는 완전히 바뀌었습니다.
이전에는 1,000토큰당 비용을 비교했습니다.
이제는 성공적인 작업 한 번당 비용을 비교합니다.
토큰을 조금 더 쓰더라도 한 번에 제대로 하는 것이,
빠르지만 두 번 재작업해야 하는 것보다 항상 더 경제적입니다.
인력 투입을 통한 원인 파악 비용을 절감하는 것은 말할 것도 없습니다.

에이전트를 만드는 모든 사람에게 두 가지 조언을 드립니다.
첫째, 순위표를 믿지 말고 자신의 저장소에 있는 실제 버그로 직접 돌려보세요.
둘째, 시스템 프롬프트(System Prompt)에 완료 전 반드시 빌드 검증을 수행하고 데드 코드를 정리하라는 명령을 강제로 추가하세요.

미래의 경쟁은 모델이 누가 더 똑똑한가가 아니라, 누가 더 책임감이 있는가에 달려 있습니다.