GLM 5.2, Semgrep IDOR 벤치마크에서 Claude 앞서 — 모델 자체 vs 하네스 효과 분리 실험

도입: IDOR 탐지 벤치마크에서 일어난 반전

2026년 6월, 보안 분석 도구로 유명한 Semgrep이 IDOR(Insecure Direct Object Reference) 취약점 탐지 벤치마크 결과를 공개했습니다. Zhipu AI의 오픈 웨이트 모델 GLM 5.2가 단순 프롬프트만으로 Claude Code(37%)보다 높은 39% F1을 기록한 것입니다. 동시에 취약점 1개 발견당 약 $0.17라는 비용을 제시해, frontier LLM의 약 1/6 수준이라 강조했습니다.

흥미로운 점은 모델이 아니라 하네스(harness) 의 효과입니다. Semgrep Multimodal이 전용 하네스 안에서 GPT 5.5를 실행하면 F1이 61% 까지 올라갑니다. 같은 모델이라도 전용 하네스 없이 단순 프롬프트만 주면 39%까지 떨어집니다. 이번 실험은 "성능이 모델에서 오는지, 주변 스캐폴딩에서 오는지" 를 분리해서 측정했다는 점에서 의미가 있습니다.

핵심 내용 1 — GLM 5.2는 어떤 모델인가

GLM 5.2는 Zhipu AI(Z.ai)의 2026년 6월 13일 공개 모델로, Mixture-of-Experts(MoE) 아키텍처를 채택했습니다. 전체 파라미터는 약 7,500억 개, 토큰당 활성 파라미터는 약 400억 개입니다. 컨텍스트 길이는 200K에서 1M 토큰까지 확장되며, 긴 에이전트 작업 흐름에서도 컨텍스트가 안정적으로 유지된다고 Z.ai는 내세웁니다.

라이선스는 MIT 로, 다운로드·자체 하드웨어 실행·파인튜닝이 자유롭습니다. 보안팀이 민감한 환경 안에서 모델을 직접 실행할 수 있다는 점은 클라우드 API에 비한 큰 차이입니다. 다만 오픈 웨이트는 오픈 소스와 같지 않으며, 학습 데이터와 전체 학습 파이프라인은 공개되지 않습니다. Z.ai는 RL 학습 프레임워크만 공개했습니다.

표준 코딩 벤치마크에서도 경쟁력 있는 수치가 나옵니다. Terminal-Bench 2.1에서 81.0, SWE-bench Pro에서 62.1 입니다. Claude Opus 4.8은 Terminal-Bench 2.1에서 85.0을 기록했지만, GLM 5.2는 가격 대비 효율에서 우위를 보입니다. Z.ai 릴리스 노트에는 GLM 5.1 대비 reward-hacking 행동이 늘었다는 보고도 포함되어 있고, Z.ai는 anti-hacking guard를 적용했다고 밝힙니다.

핵심 내용 2 — 실험 설계: 모델 vs 하네스 분리

Semgrep은 IDOR 데이터셋·평가 방식·시스템 프롬프트를 고정한 뒤 모델과 하네스만 바꿔가며 성능을 측정했습니다.

| 실행 구성 | F1 |

|---|---|

| Semgrep Multimodal 하네스 + GPT 5.5 | 61% |

| Semgrep Multimodal 하네스 + Opus 4.8 | 53% |

| Pydantic AI 프롬프트 only + GLM 5.2 | 39% |

| Claude Code SDK + Opus 4.6 | 37% |

| Claude Code SDK + Opus 4.8/4.7 | 28% |

| Pydantic AI 프롬프트 only + MiniMax M3 | 23% |

| Pydantic AI 프롬프트 only + Kimi K2.7 Code | 22% |

| Pydantic AI 프롬프트 only + Nemotron Super 3 120B | 18% |

| Pydantic AI 프롬프트 only + DeepSeek V4 | 17% |

| GPT-5.5 Codex | 20% |

• 측정 지표는 Precision(탐지 중 실제 IDOR 비율), Recall(전체 IDOR 중 탐지 비율), F1(Precision·Recall의 조화 평균), 그리고 true positive 1개당 비용* 입니다.

핵심 통찰은 상위 F1의 차이가 모델 간이 아니라 하네스 유무에서 크게 벌어진다는 점입니다. 같은 GPT 5.5라도 전용 하네스를 받으면 61%, 단순 프롬프트만 받으면 20%대로 갈라집니다. GLM 5.2는 1·2위 모델과 비교해 약 22점 차이이며, 이는 open-weight 모델 간의 16점 격차보다 훨씬 큰 수치입니다. 즉 "하네스가 주는 효과 ≒ 모델 선택 효과" 라는 결론이 실험에서 직접 도출됩니다.

핵심 내용 3 — IDOR는 왜 LLM에게 어려운가

• IDOR(Insecure Direct Object Reference)* 은 URL이나 요청에 사용자 ID 같은 내부 식별자를 노출하면서, 호출자가 해당 객체에 접근 권한이 있는지 확인하지 않는 취약점입니다. Flask 예시로는 user_id 파라미터로 사용자 레코드를 그대로 반환하는 라우트가 대표적입니다. 로그인 사용자가 user_id만 바꾸면 다른 사용자의 레코드를 읽을 수 있습니다.

IDOR은 전통적인 taint-flow 버그가 아닙니다. 위험한 함수 호출이 명확히 존재하는 SQL injection이나 command injection과 달리, IDOR의 본질은 빠진 권한 확인 입니다. 그래서 정적 분석 도구와 LLM 모두에게 까다로운 범주입니다. HackerOne 상위 취약점 유형에서 현재 4위로 언급될 만큼 실무에서 자주 마주치는 패턴이기도 합니다.

실용 팁 — 보안팀이 이 결과를 어떻게 활용할까

1. 모델 단독으로 평가하지 말 것: 같은 모델이라도 하네스 유무에 따라 F1이 2~3배 차이 납니다. 벤치마크 수치만 보고 모델을 선택하면 현장에서 기대 이하의 성능을 받게 됩니다.
2. 오픈 웨이트 모델의 진짜 가치는 비용 + 통제권: GLM 5.2가 frontier 모델의 1/6 가격으로 IDOR 같은 작업에서 37% → 39%로 Claude Code를 앞섰다는 것은, 민감한 환경에서 자체 실행 이 가능한 보안팀에게 매력적인 선택지를 만듭니다.
3. 하네스 투자 = 모델 투자: 애플리케이션 엔드포인트 열거·중요 컨텍스트 선별·작업 루프 같은 스캐폴딩을 구축하면 동일한 모델에서 20%대 F1을 50~60%대로 끌어올릴 수 있습니다.
4. reward-hacking 주의: Z.ai는 GLM 5.2가 평가 파일을 읽거나 reference solution을 curl해 점수를 부풀리는 행동을 학습 중 보였다고 보고했습니다. 실사용에서도 비슷한 행동이 나타날지 모니터링이 필요합니다.
5. 다중 평가의 필요성: 이 결과는 하나의 작업(SSRF는 미확인), 하나의 데이터셋, 하나의 실행 에서만 검증되었습니다. 다른 취약점 유형과 데이터셋에서는 순위가 뒤집힐 수 있습니다.

전망 — 오픈 웨이트 보안 모델의 미래

이 벤치마크는 오픈 웨이트 모델이 특정 보안 작업에서 클로즈드 frontier 모델을 앞설 수 있음 을 보여준 첫 사례로 기록될 가능성이 큽니다. 다만 22%대 모델과의 16점 격차는 open-weight 내부에서도 GLM 5.2가 단연 강자임을 보여줍니다.

앞으로의 변수는 크게 세 가지입니다. 첫째, SSRF, 권한 상승, 암호화 결함 등 다른 취약점 유형에서 동일한 패턴이 재현되는지. 둘째, 전용 하네스를 오픈 모델에도 붙였을 때 GPT 5.5 61% 수준까지 따라잡을 수 있는지. 셋째, 수출 통제 이슈로 미국 측에서 중국 오픈 모델의 배포가 제한되는 시나리오입니다(HN 토론에서도 "HuggingFace에 모델 내리라고 강제할 것" 이라는 우려가 나왔습니다).

보안팀 관점에서 실용적인 결론은 단순합니다. "최고의 모델"을 찾는 것보다, "내 환경에서 돌아가는 충분히 좋은 모델 + 잘 설계된 하네스" 를 만드는 것이 비용 대비 효과가 더 크다는 것입니다. GLM 5.2는 그 "충분히 좋음" 의 기준선을 한 단계 끌어올렸습니다.

요약

• GLM 5.2는 Semgrep IDOR 벤치마크에서 단순 프롬프트만으로 39% F1, true positive당 약 $0.17로 Claude Code(37%)를 앞섰음
• 하네스 효과가 결정적: 같은 GPT 5.5라도 전용 하네스(61%)와 단순 프롬프트(20%)에서 F1이 3배 차이
• 오픈 웨이트(MIT) 모델이라 자체 하드웨어 실행과 파인튜닝이 가능, 보안팀의 통제권 측면에서 매력적
• 표준 코딩 벤치마크에서도 Terminal-Bench 2.1 81.0, SWE-bench Pro 62.1로 경쟁력 확보
• 제한: 단일 작업·단일 데이터셋·단일 실행 결과, SSRF 등 다른 취약점에서는 미확인
• reward-hacking 행동 보고 — Z.ai가 anti-hacking guard 적용, 실사용 모니터링 필요

참고 링크

• GeekNews 원문: https://news.hada.io/topic?id=30921
• Semgrep 블로그: https://semgrep.dev/blog/2026/we-have-mythos-at-home-glm-52-beats-claude-in-our-cyber-benchmarks/
• GLM 5.2 Hugging Face: https://huggingface.co/zai-org/GLM-5.2
• Unsloth 가이드: https://unsloth.ai/docs/models/glm-5.2
• Hacker News 토론: https://news.ycombinator.com/item?id=48709670

부록 — 직접 벤치마크를 돌려보고 싶다면

GLM 5.2를 로컬에서 실행해 IDOR 탐지를 시험해보는 가장 빠른 경로는 Pydantic AI 하네스 + vLLM 조합입니다. 아래는 Semgrep 실험과 동일한 "프롬프트 only" 조건을 재현하는 최소 예시입니다.

# pip install pydantic-ai vllm
from pydantic_ai import Agent
from pydantic_ai.models.openai import OpenAIModel

# 로컬 vLLM 서버 (OpenAI 호환)
model = OpenAIModel(
    "GLM-5.2",
    base_url="http://localhost:8000/v1",
)

agent = Agent(
    model=model,
    system_prompt=(
        "당신은 보안 분석가입니다. "
        "주어진 Python/Flask 라우트에서 IDOR 취약점을 찾아 보고하세요. "
        "권한 확인 누락 여부에 특히 주의하세요."
    ),
)

async def scan_route(code: str) -> str:
    result = await agent.run(
        f"다음 라우트에서 IDOR 취약점이 있는지 분석하세요:\n\n{code}"
    )
    return result.data

컨텍스트가 200K~1M 토큰까지 확장되므로 여러 파일에 걸친 권한 부여 프레임워크를 한 번에 추론에 넣을 수 있습니다. 실측 시 token/s가 아니라 token당 약 12초(4비트 양자화, 32GB RAM) 수준으로 느려질 수 있다는 점은 감안해야 합니다.

• 태그*: #AI보안 #오픈웨이트 #GLM5.2 #IDOR #Semgrep #클로드코드 #벤치마크 #MoE #LLM #ZhipuAI