“모델은 한눈에 안 판다”는 말, 이젠 숫자로도 증명된다.

Semgrep이 IDOR 취약점 탐지 벤치마크를 공개했다. 실험 조건은 단순했다. 같은 데이터셋, 같은 시스템 프롬프트, 같은 평가 방식. 바꾼 건 모델과 하네스뿐이다. 그리고 결과는 생각보다 더 치열했다.

GLM 5.2가 Claude Code를 이겼다 — 보안 작업에서

F1 기준으로 보자. Semgrep의 전용 하네스에서 돌린 GPT 5.5가 61%로 1위. Opus 4.8이 53%로 2위다. 그런데 3위가 GLM 5.2다. Pydantic AI 단순 프롬프트 하네스 하나로 39% F1을 찍었다. Claude Code(Opus 4.8)는 28%. Claude Code(Opus 4.6)는 37%.

쉽게 말해서 이거다. 엔드포인트 열거나 유도 탐색 같은 특별한 스캐폴딩 없이, 프롬프트만 던졌는데도 open-weight 모델이 Claude Code보다 IDOR를 더 잘 찾았다. 취약점 하나 찾는 데 든 비용도 약 $0.17. Frontier 모델 API 요금의 1/6이다.

“제일 좋은 모델”은 애초에 틀린 질문이다

당원, 이게 중요한 게 아니다. GLM 5.2가 만능이라는 뜻이 절대 아니니까. GLM 5.2는 SWE-bench Pro에서 62.1%로 Claude Opus 4.8(69.2%)에 한참 뒤진다. HLE도 40.5%로 Opus 4.8(49.8%)보다 낮다. 모든 벤치마크에서 이기는 모델은 존재하지 않는다.

그런데도 많은 사람들이 “가장 좋은 모델은 뭐야?”를 진지하게 묻는다. 마치 하나만 고르면 된다고 믿는 것처럼. 이 벤치마크가 보여주는 건 정반대다. 작업의 성격에 따라 최적의 모델이 달라진다. IDOR 탐지에선 GLM 5.2, 일반 코딩에선 Claude, 장기 추론에선 GPT — 한 모델에 올인하는 건 그냥 돈과 정확도를 동시에 버리는 짓이다.

내가 3계층 라우팅을 만든 이유

Drewgent는 모델을 Flash/Pro/Max 3계층 피라미드로 운영한다. 단순 실행 작업은 deepseek-v4-flash(Flash), 코드 리뷰와 분석은 deepseek-v4-pro나 glm-5.2(Pro), 복잡한 추론과 계획은 qwen3.7-max(Max). 그리고 내부 작업용 Groq 무료 티어까지.

이 구조를 만든 건 “아, 나중에 GLM이 보안에서 강할 테니 준비해야지” 같은 예측 때문이 아니다. 그냥 단일 모델 의존이 병목이라고 생각했을 뿐이다. 한 모델이 모든 걸 잘할 거라는 믿음은 편하지만, 그건 믿음이지 설계가 아니다.

이번 GLM 5.2 벤치마크는 그 설계를 뒤늦게 검증해준 외부 사건에 불과하다. 나는 이미 4개월 전에 이 구조로 가기로 결정했고, 그 결정은 “GLM 5.2가 보안을 잘할까?” 같은 예측이 아니라 “어차피 어떤 모델도 만능은 아니다”라는 설계 원칙에서 나왔다.

진짜 교훈: 하네스가 모델보다 더 강력했다

벤치마크에서 진짜 주목할 건 따로 있다. Semgrep Multimodal이 두 모델(GPT 5.5, Opus 4.8)을 각각 61%, 53%까지 끌어올렸다는 사실. 전용 하네스(엔드포인트 열거 + 코드 컨텍스트 선별 + 유도 탐색)를 준 구성과 아닌 구성의 격차가, GLM 5.2와 Claude Code의 격차보다 훨씬 컸다.

이게 진짜 교훈이다. 구조가 모델을 이긴다. 가장 강한 하네스(GPT 5.5 + Semgrep)와 가장 약한 하네스(GLM 5.2 프롬프트 only)의 F1 차이는 22%p인데, GLM 5.2와 Claude Code의 차이는 2~11%p였다. 모델 선택보다 하네스 설계가 2~10배 더 큰 변수다.

이건 Ponytail 원칙과 정확히 같다. “이미 있는 걸로 되나?” → Semgrep 정적 분석 엔진을 도구로 제공하니 일부 모델은 오히려 더 못했다. 도구를 잘 쓰는 것도 구조의 일부라는 뜻이다.

열린 모델, 열린 설계

GLM 5.2는 MIT 라이선스다. 753B 파라미터, MoE 아키텍처, 토큰당 활성 파라미터는 약 40B. 양자화하면 로컬에서도 돌릴 수 있다. 보안팀이 민감한 환경 안에서 자체 실행할 수 있다는 건, API로 보내는 frontier 모델과 완전히 다른 게임이다.

물론 제한도 분명하다. 하나의 작업, 하나의 데이터셋, 한 번의 실행에서 나온 결과라는 건 글쓴이도 명시했다. SSRF 같은 다른 취약점 유형에서는 결과가 뒤집힐 수 있다. 하지만 그게 오히려 내 주장을 강화한다. 어떤 작업에 어떤 모델이 강한지, 매일 업데이트되는 실험 데이터를 바탕으로 라우팅해야 한다는 것.

덜어낼수록 강해진다

Drewgent의 설계 철학은 contraction이다. v0.8에서 에이전트 14→6개로 줄였고, n8n을 지우고 launchd cron 하나로 대체했으며, 비용도 65% 절감했다. 같은 철학이 모델 라우팅에도 적용된다.

“제일 좋은 모델”을 찾지 마라. 그건 존재하지 않는다. 대신, 어떤 작업을 어떤 모델이 가장 잘하는지 계속 관찰하고, 그 관찰을 시스템의 라우팅 로직에 박아라. 계획은 Pro로, 실행은 Flash로, 보안은 GLM으로 — 이렇게 분리하는 게 “가장 좋은 모델”을 기다리는 것보다 훨씬 낫다.

Semgrep 벤치마크가 그걸 다시 한 번 숫자로 보여줬다. 나는 그걸 설계로 이미 하고 있었다.