우리에게도 Mythos가 있다: GLM 5.2가 우리의 Cyber Benchmark에서 Claude를 능가하다

우리는 최첨단 코딩 에이전트 (coding agents)를 평가할 때 사용했던 것과 동일한 데이터셋과 프롬프트를 사용하여, 우리의 IDOR 벤치마크에 일련의 인기 있는 오픈 소스 모델들을 대상으로 테스트를 진행했습니다. 결과는 놀라웠습니다. Zhipu AI의 오픈 웨이트 (open-weight) 모델인 GLM 5.2가 IDOR 탐지에서 39%의 F1 점수를 기록하며, 취약점 하나를 발견할 때마다 약 0.17달러의 비용으로 Claude Code (32%)를 앞질렀습니다. Semgrep의 멀티모달 파이프라인 (multimodal pipeline, F1 53–61%)에는 여전히 뒤처졌지만, 해당 파이프라인은 많은 중량 작업을 수행하는 목적 맞춤형 하네스 (harness) 내에서 작동합니다. 프롬프트 외에 아무것도 주어지지 않은 모델들 중에서는, 더 이상 뻔한 약자가 아닌 최고의 오픈 웨이트 옵션으로서 Claude Opus 4.8을 능가했습니다.

우리가 정말로 오픈 웨이트 챔피언을 가리려 했던 것은 아닙니다. 우리는 더 좁고 지루한 질문에 답하려 했습니다: 취약점 탐지 성능 중 얼마만큼이 모델로부터 오고, 얼마만큼이 그 주변의 하네스 (harness)로부터 오는가? 보안 작업에 AI 에이전트를 적극적으로 활용하는 고객들과 소통하는 Semgrep에게 이것은 매우 중요한 질문입니다. 하네스 (harness)란 모델을 감싸는 비계 (scaffolding)와 같습니다. 모델에 저장소 (repository)를 제공하고, 모델이 무엇을 볼지 결정하며, 출력을 파싱 (parse)하고, 작업을 반복하도록 루프를 돌립니다. 우리의 내부 멀티모달 파이프라인은 정적 분석 (static analysis)을 위해 특별히 제작된 하네스 내에서 실행됩니다. 우리는 IDOR 또는 Insecure Direct Object References (부적절한 직접 객체 참조)를 찾는 워크플로를 통해 이를 내부적으로 한동안 테스트해 왔습니다. 이것들은 대략적으로 "다른 사용자의 소유인 무언가에 접근하고 있다"라고 생각할 수 있는 접근 제어 (access control) 문제입니다.

우리의 하네스 (harness)는 애플리케이션의 엔드포인트 (endpoints)를 나열하고, 코드는 중요한 컨텍스트 (context)만을 걸러내려고 시도하며, 그 후 모델을 해당 지점으로 직접 안내합니다. 이는 매우 많은 구조를 갖추고 있지만, 제가

둘째, 코딩 분야에서 진정으로 경쟁력이 있습니다. GLM 5.2는 Mixture-of-Experts (MoE) 모델로, 총 파라미터 수는 약 7,500억 개에 달하지만 토큰당 활성화되는 파라미터는 약 400억 개에 불과하여, 그 크기 대비 추론 비용 (inference cost)을 낮게 유지합니다. 사용 가능한 컨텍스트 (context)를 200K에서 무려 1M 토큰까지 확장했으며, Z.ai의 주장은 이 컨텍스트가 단순히 더 많은 입력을 수용하는 것을 넘어, 길고 복잡한 에이전트 궤적 (agent trajectories) 전반에 걸쳐 신뢰성을 유지한다는 것입니다. 다시 말하지만, 이는 보안 작업에서 매우 중요한데, IDOR와 같은 보안 작업은 권한 부여 프레임워크 (authorization framework)를 통해 서로 다른 파일들을 가로질러 추론할 수 있어야 하기 때문입니다. 표준 코딩 벤치마크 (coding benchmarks)에서 GLM 5.2는 현재 가장 강력한 오픈 웨이트 (open-weight) 수치를 기록하고 있습니다. Terminal-Bench 2.1에서 81.0을 기록했으며 (GLM 5.1의 63.5와 비교 시, 그리고 Claude Opus 4.8의 85.0과 불과 몇 포인트 차이), SWE-bench Pro에서는 62.1을 기록하여 폐쇄형 프런티어 모델 (closed frontier models)들을 근소하게 앞지르고 최상위 모델들을 한 자릿수 퍼센트 차이로 추격하고 있습니다.

셋째, 비용입니다. 토큰 경제학 (Tokenomics)은 LLM의 능력 그 자체만큼이나 빠르게 중요해지고 있습니다. 보고된 가격은 유사한 프런티어 모델들의 약 6분의 1 수준이며, 오픈 모델을 면밀히 추적하는 평론가들은 GLM 5.2의 시장 반응을 DeepSeek에 비유하기도 했습니다. GLM 5.2는 토큰 경제학뿐만 아니라, 프런티어급 폐쇄형 모델들이 탈옥 (jailbreaks) 보고 이후 새로운 수출 제한 조치를 받은 직후에 등장했다는 점에서 매우 민감한 시기에 출시되었습니다. 이 모델을 코드 작업에 활용하려는 분들이 주목해야 할 릴리스 노트 (release notes)의 세부 사항이 하나 있습니다. Z.ai의 보고에 따르면 GLM 5.2는 GLM 5.1보다 더 많은 보상 해킹 (reward-hacking) 동작을 보입니다. 학습 과정에서 점수를 부풀리기 위해 보호된 평가 파일을 읽거나 참조 솔루션을 curl로 가져오는 등의 행위를 하여, 그들은 전용 안티 해킹 가드 (anti-hacking guard)를 구축해야 했습니다. 이는 팀의 정직한 공개이지만, 만약 당신이 해킹을 위한 모델을 만들고 있었다면... 애초에 테스트를 우회하려고 시도하는 것만큼 해커다운 행동은 없을 것입니다.

우리의 실험

세부 사항으로 너무 깊이 들어가기 전에, 우리가 정확히 무엇을 하려고 했는지와 우리의 실험이 무엇이었는지 요약하는 것이 중요합니다. IDOR에 대한 빠른 복습: 부적절한 직접 객체 참조 (Insecure Direct Object Reference, IDOR)는 애플리케이션이 호출자가 실제로 해당 객체에 접근할 권한이 있는지 확인하지 않고, 요청에 사용자 ID와 같은 내부 식별자를 노출하는 취약점 클래스입니다. 식별자를 변경하면 다른 사람의 데이터를 얻게 됩니다.

@app.route('/user/<int:user_id>')
def get_user(user_id):
user = User.query.get_or_404(user_id)
...

이 Flask 라우트(route)는 요청자가 해당 데이터를 소유하고 있는지 확인하는 절차 없이, URL의 ID로부터 사용자 레코드를 직접 가져와 반환합니다. 로그인한 사용자라면 누구나 user_id를 변경하여 다른 사람의 레코드를 읽을 수 있습니다. IDOR는 비즈니스 로직 결함(business-logic flaw)과 설정 오류(misconfiguration) 사이의 어딘가에 위치하며, 오염 흐름(taint-flow) 버그가 아닙니다. 바로 이 점이 정적 분석(static analysis)과 LLM 모두에게 어렵게 만드는 요소입니다. 플래그를 지정할 '위험한 함수'가 있는 것이 아니라, 확인 절차가 누락되어 있기 때문입니다. 또한 이는 실제 환경에서 가장 흔하게 발견되는 취약점 중 하나이기도 합니다 (현재 HackerOne의 주요 취약점 유형 목록에서 4위). 이것이 우리가 벤치마크로서 IDOR를 계속해서 다루는 이유입니다.

다시 우리의 실험으로 돌아가서: 우리는 표준적인 실험 조건에 따라 세 가지 요소는 고정하고 한 가지 요소만 변화를 주었습니다. 고정된 요소: IDOR 데이터셋 (이전 연구에서 사용했던 것과 동일한 실제 오픈 소스 애플리케이션들), 평가 방법 (알려진 참 양성(true positives) 세트에 대한 F1 score), 그리고 IDOR 시스템 프롬프트 자체입니다. 변화를 준 요소: 모델과 그 하네스(harness)입니다. 구체적으로는 다음과 같습니다:

Semgrep Multimodal는 엔드포인트를 열거하고 모델을 해당 엔드포인트로 안내하는 우리의 커스텀 하네스 내부에서 실행되었습니다. 우리는 그 뒤에 있는 두 개의 프런티어 모델(frontier models)로 이를 테스트했습니다. 하지만 우리는 또한 단순히

Claude Code를 Claude Code SDK를 통해 실행하였고, 다른 제공업체의 모델들은 동일한 프롬프트를 사용하되 각자의 네이티브 SDK를 통해 실행했습니다. 그리고

**오픈 웨이트 모델 (open-weight models)**인 GLM 5.2, MiniMax M3, Kimi K2.7 Code는 IDOR 프롬프트만을 포함한 단순한 Pydantic AI 하네스에서 실행되었습니다.

이것은 매우 중요한 세부 사항이므로 두 번 말씀드리겠습니다. 오픈 웨이트 (open-weight) 모델들에게는 멀티모달 파이프라인 (multimodal pipeline)이 받는 엔드포인트 탐색 스캐폴딩 (endpoint-discovery scaffolding)이 제공되지 않았습니다. 이 모델들은 오직 프롬프트와 코드베이스 (codebase)만을 보았습니다. 이것이 바로 아무런 도움 없이 모델들이 스스로 해낼 수 있는 능력입니다.

우리는 또한 효과성을 측정하기 위해 몇 가지 다른 지표들을 계산했습니다.

정밀도 (Precision): 탐지기가 IDOR로 표시한 모든 것 중 실제 IDOR였던 비율은 얼마인가? 높은 정밀도 = 적은 오탐 (false alarms). 만약 10개의 버그를 보고했는데 그중 7개가 실제라면, 정밀도는 70%입니다.

재현율 (Recall): 데이터셋에 실제로 존재하는 모든 실제 IDOR 중 모델이 찾아낸 비율은 얼마인가? 높은 재현율 = 실제 버그를 몇 개 놓침. 만약 20개의 실제 IDOR가 있고 모델이 12개를 잡아냈다면, 재현율은 60%입니다.

F1 (F1 Score): 정밀도와 재현율의 균형을 맞추는 단일 수치입니다. 이는 조화 평균 (harmonic mean)입니다: F1 = 2 × (정밀도 × 재현율) / (정밀도 + 재현율). 단순 정확도 (accuracy) 대신 F1을 사용하는 이유는 두 목표가 서로 충돌하기 때문입니다. 탐지기는 자신이 확실하다고 생각하는 단 하나의 버그만 표시함으로써 100% 정밀도를 달성할 수 있지만 (이 경우 재현율은 매우 처참하게 낮아집니다), 또는 모든 것을 취약하다고 표시함으로써 100% 재현율을 달성할 수 있습니다 (이 경우 오탐이 너무 많아져 정밀도가 매우 처참해집니다). F1은 두 가지 모두를 동시에 잘 수행하는 것에 보상을 주며, 조화 평균은 한쪽으로 치우친 점수에 벌칙을 줍니다. 정밀도나 재현율 중 어느 하나라도 0에 가깝다면 F1은 크게 하락합니다. 이것이 이 포스트 전반에 걸쳐 우리가 사용할 지표입니다.

달러 비용 (Cost in dollars): 진양성 (true positive)당 비용 및 총 실행 비용을 발견된 실제 버그 수로 나눈 값입니다. 탐지기를 실행하는 데 드는 실제 경제적 비용을 의미합니다. F1 점수가 평범하더라도 저렴한 모델이 이 지표에서는 승리할 수 있습니다.

결과

IDOR 탐지 F1 점수 기준 순위:

IDOR 탐지 F1 점수 기준 순위:

| | | | |
1 | Semgrep Multimodal (GPT 5.5) | Semgrep Multimodal | 61% |
2 | Semgrep Multimodal (Opus 4.8) | Semgrep Multimodal | 53% |
3 | GLM 5.2 | Pydantic AI (prompt only) | 39% |
4 | Claude Code (Opus 4.6) | Claude Code SDK | 37% |
5 | Claude Code (Opus 4.8/4.7) | Claude Code SDK | 28% |
6 | MiniMax M3 | Pydantic AI (prompt only) | 23% |
7 | Kimi K2.7 Code | Pydantic AI (prompt only) | 22% |
8 | GPT-5.5 | Codex | 20% |
9 | Nemotron Super 3 120B | Pydantic AI (prompt only) | 18% |
10 | DeepSeek V4 | Pydantic AI (prompt only) | 17% |

저희에게는 두 가지 발견이 눈에 띕니다.

저희의 멀티모달 파이프라인이 선두를 차지했으며, 아마도 그 이유가 하네스(harness) 덕분일 것입니다. GPT 5.5와 Semgrep Multimodal 내부의 Opus 4.8이 각각 61%와 53%로 상위 두 자리를 차지했습니다. 물론 이것은 저희와 고객들에게 좋은 소식이며, 저희 접근 방식이 효과적임을 입증하는 것이기도 합니다... 하지만 그게 흥미로운 부분은 아닙니다.

가장 큰 놀라움은 3위입니다. GLM 5.2는 어떠한 스캐폴딩(scaffolding) 없이도 Claude Code를 7%p 차이로 앞질렀습니다 (39% 대 32%). 아무런 기반 구조 없이 실행된 오픈 웨이트 모델이 추론 능력이 중요한 보안 작업에서 최첨단 코딩 에이전트보다 뛰어난 성능을 보인 것입니다. 게다가 저렴하게도 말이죠! GLM 5.2의 가격으로 계산했을 때, 취약점 하나를 찾는 데 드는 비용은 대략 $0.17에 불과했습니다. 수천 개의 엔드포인트에 걸쳐 실행할 수 있는 탐지 작업에서, 버그당 경제성은 단순한 참고 사항이 아니라, 해당 기술을 규모 있게(at scale) 사용할 수 있는지 여부를 결정하는 경우가 많습니다.