같은 코드를 같은 prompt로 봐도 결과가 흔들린다. Snyk가 2026년 6월 29일 공개한 VulnBench JS 1.0은 agentic LLM security review가 취약점을 얼마나 반복해서 찾는지 측정했다. 핵심은 승자 찾기가 아니라, 개발 워크플로에 들어오는 LLM 보안 리뷰가 매번 같은 위험을 보여줄 수 있느냐는 운영 문제다.

벤치마크는 10개의 JavaScript와 Express fixture project, 44개의 Snyk Code reference finding을 사용했다. Snyk Code SAST와 Claude Opus 4.6 Medium, Opus 4.6 High, Opus 4.7 Max, Sonnet 4.6 Medium, Sonnet 4.6 High 등 여섯 configuration이 각 task를 5번씩 수행했다. 전체 구조는 10 tasks x 6 configurations x 5 repetitions, 총 300 runs다. 모델은 project files를 읽을 수 있었지만 reference file은 볼 수 없었다.

가장 좋은 LLM configuration은 Claude Opus 4.6 Medium으로, Snyk-reference F1 75.4%, recall 68.0%, precision 91.5%를 기록했다. 같은 표에서 Snyk Code SAST는 자기 reference set을 기준으로 100.0% F1과 0.0 percentage-point standard deviation을 보였다. Snyk도 이 수치를 “Snyk가 모든 취약점을 100% 맞혔다”는 뜻으로 읽지 말라고 선을 긋는다. 기준은 Snyk Code와의 agreement, 그리고 반복 실행에서의 variance다.

재현성 문제는 reference 밖 추가 보고에서 더 뚜렷했다. 전체 model configurations에서 unique unmatched finding signatures 161개 중 80개, 즉 49.7%가 5번 반복 중 1번만 나타났다. 반대로 reference-matched finding은 158개 중 134개가 5번 모두에서 반복됐다. 모델이 알려진 취약점 형태를 잡을 때는 비교적 안정적이지만, 추가로 제기하는 보안 이슈는 훨씬 더 흔들린다는 뜻이다.

비용이 곧 성능도 아니었다. Claude Opus 4.7 Max는 평균 95,969 tokens와 $0.3559 per session을 썼지만 Snyk-reference F1은 68.8%였다. Claude Opus 4.6 Medium은 평균 51,574 tokens와 $0.0628 per session으로 75.4%를 기록했다. 작은 fixture에서 나온 비용 차이지만, PR과 CI에서 반복 실행되는 보안 점검이라면 운영비와 triage 부담으로 바로 이어진다.

Snyk의 결론은 LLM과 SAST 중 하나를 고르는 쪽이 아니다. 모델은 command injection, hardcoded credentials, SQL injection, SSRF 같은 익숙한 exploit shape를 잘 잡았고, 한 사례에서는 Snyk Code reference 밖의 실제 gap 후보도 드러냈다. 반면 path traversal 반복 흐름, resource-limit 취약점, framework information exposure처럼 systematic data-flow가 필요한 영역에서는 deterministic analysis가 더 강했다. 다음 검증 지점은 독립 ground truth를 둔 더 큰 application fixture와 LLM+SAST 결합 workflow다.

#snyk

Snyk 300회 반복 테스트, LLM 보안 리뷰의 흔들리는 재현성