새 연구에서 Claude Opus 4.7은 주어진 공격 실증을 90.2%의 사례에서 막았지만 원 개발자 테스트를 통과한 패치는 60.7%였다. 29.5%포인트 차이가 핵심이다. 충돌 하나를 없앤다고 유지관리자가 의도한 동작을 보존한 보안 수정이 입증되지는 않는다.
Northwestern의 Dang K Le, Wenxuan Shi와 Xinyu Xing은 10월 7일 벤치마크 신뢰성 연구를 보고했다. C·C++·Go·Rust의 오픈소스 84개 프로젝트, 역사적 버그 112개를 다룬다. 특정 Claude·에이전트 구성의 사전 논문이지 모든 자율 패치나 운영 보안의 보편적 실패율은 아니다.
모델이 좋아져도 채점 격차는 남는다
통제 실험은 같은 사례에서 OpenCode에 Sonnet 4.0, Sonnet 4.5와 Opus 4.7을 연결했다. 빌드·테스트 지침은 주었지만 처음에는 PoC 본문을 주지 않았다. PoC는 보고된 실패를 보이는 입력이나 절차다.
Sonnet 4.0은 PoC 77.7%, 개발자 테스트 43.8%, Sonnet 4.5는 84.8%와 48.2%, Opus는 90.2%와 60.7%였다. Opus는 양쪽에서 실제 개선됐지만 PoC를 통과한 패치 중 32.7%는 개발자 테스트에 실패했다. 공개 채점 분석이 강조한, 겉보기 성공 셋 중 하나다.
Opus는 기존 회귀 테스트도 94.6% 통과했으나 격차를 없애지 못했다. 기존 모음은 알려진 예를 검사하고 실제 수정 때 추가한 시험은 새 결함 주변의 빠진 의도를 담을 수 있다.
연구자는 원 수정 커밋의 단위·통합 테스트를 재구성해 에이전트 패치 뒤 적용했다. 텍스트 일치가 아닌 행동을 검사하므로 다른 구현도 통과할 수 있다. 완전 해결은 빌드, 반복 PoC 억제, 기존 회귀와 추가 개발자 테스트의 네 단계를 모두 요구했다.
PHP는 잘못된 이유로 충돌이 사라질 수 있음을 보인다
과거 PHP range() 버그는 혼합 유형을 잘못 분류해 문자열 아닌 값을 문자열처럼 접근할 수 있었다. 혼합 유형을 즉시 거부하면 충돌과 여러 기존 시험은 해결해도 PHP가 변환해야 하는 유효한 숫자·문자 조합까지 거부한다.
원 수정은 분류를 고치며 유효 동작을 유지했다. 인접한 정상 입력의 개발자 시험이 진짜 수정과 과도한 우회를 구분했다. 충돌만 보는 평가는 둘을 똑같이 보상한다.
이런 가드는 응급 완화로 유용해도 완전 수리는 아닐 수 있다. 테스트 과적합은 근본 요구보다 보이는 예만 맞춘다. 보안에서는 증상을 숨기고 다른 경로를 남기며 잘못된 안도감으로 검토를 줄일 수 있다.
개발자 시험도 더 나은 대리 지표이지 모든 인수 판단은 아니다. 성능·호환성·가독성·구조를 다 담지 않는다. 타당한 대안이 문서 밖 행동을 일부러 바꿀 수도 있어 과거 시험 실패는 검토할 불일치이지 자동 위험은 아니다.
지침이 측정 능력을 바꾼다
자세한 명령이 있을 때 Sonnet 4.0의 PoC 통과는 77.7%, 없으면 74.1%였다. 개발자 시험은 41.1%에서 43.8%로 변했다. C/C++만 보면 지침은 PoC를 72%에서 92%로 올렸지만 개발자 시험은 28%에서 36%였다.
문서는 사람에게도 정당한 도움이다. 그러나 정보 예산을 공개하지 않으면 점수를 비교할 수 없다. Go·Rust 명령은 예측하기 쉽고 C/C++는 빌드·플래그·래퍼가 다양하다. 환경 지원이 실제 수정 품질 평가 전에 점수를 바꿀 수 있다.
Go 62개에서 소스 PoC를 보여주면 충돌 시험은 69.4%에서 95.2%, 개발자 시험은 41.9%에서 48.4%로 올랐다. 읽을 수 있는 시험 코드는 API·호출 형태를 보여 눈에 보이는 검사에 맞추기 쉽게 한다.
C/C++ 25개에서 불투명한 바이너리·텍스트 입력을 보여줘도 PoC 92%, 개발자 36%는 같았다. 둘 다 PoC 제공이라고 할 수 있지만 한쪽은 실행 의도를 드러내고 다른 쪽은 입력 의미를 추론해야 한다. 같은 정보 조건이 아니다.
검색과 인프라는 양방향으로 점수를 왜곡한다
역사적 과제에는 공개 이슈·권고·수정이 있다. 논문은 웹 도구로 원 패치를 찾은 에이전트와 정리되지 않은 Git 기록에서 예전 수정을 찾은 사례를 기록한다. 성공했어도 독립 수리 추론을 깔끔하게 측정하지 않는다.
운영 개발에서 웹과 기록 검색은 합리적이다. 무도움 추론을 주장하는 평가에서만 오염이 된다. 검색·도구 능력 시험이라면 명시해 허용할 수 있다. 과거 수정을 학습으로 기억했을 가능성도 절대 점수 해석을 제한한다.
프레임워크 오류는 반대로 올바른 결과를 숨기거나 비밀 정답을 노출한다. 권한·시간 제한·시험 파일 충돌이 빌드를 막거나 좋은 패치를 오답으로 만든다. 개별 문제는 전체 실행 사례 약 5~32%에 영향을 주어 순위 차이보다 클 수 있었다.
따라서 점수는 모델, 에이전트 틀, 프롬프트, 도구, 소스 포장, 제한과 채점의 전체 결과다. 통제는 OpenCode·Claude, 사례는 Claude Code·Sonnet 4.5도 포함했다. 두 환경을 같은 것으로 보면 안 된다.
관련 연구도 여러 시험을 요구한다
PVBench는 20개 프로젝트 209개에서 기본 검사 통과 패치의 40% 초과가 개발자 수정 기반 추가 시험에 실패했다고 했다. 데이터·설계가 달라 직접 비교할 Claude 비율은 아니다.
PatchBench는 11개 에이전트의 PoC 단독 해결률이 평균 1.83배 부풀려졌다고 보고했다. 보안 재실행·단위·출력 검사를 합치면 최상위도 원 PoC 97% 초과에서 약 절반으로 떨어졌다.
PatchBench는 충돌 스택 밖을 수정하는 취약점을 골라 달라진 저장소 맥락에 이식해 과거 패치 기억의 가치를 줄였다. 모든 성공이 새로운 추론이라고 가정하지 않는다.
Berkeley의 CyberGym-E2E는 139개 프로젝트 920개 취약점의 발견·재현·수정을 결합한다. 목표를 알려주면 최고 구성은 약 80%를 수정했지만 발견부터 하면 낮아졌고 표면적인 충돌 가드도 나타났다.
모델·과제·정의가 달라 하나의 순위가 아니다. Cyber Index 방법도 감사·발견·재현·정상 동작을 깨지 않는 수정으로 확장한다. 공통 문제는 성공 비율에 무엇이 포함되느냐다.
강한 판정도 운영 증명은 아니다
Northwestern 표본은 재현 빌드와 의미 있는 원 테스트를 요구했다. 112개는 다양해도 모든 운영 취약점을 대표하지 않는다. 공개 자료가 학습에 포함됐을 수 있다. 이는 절대 비율을 제한하지만 프롬프트·채점 변화의 통제된 효과는 없애지 않는다.
운영은 자체 시험·정적 분석·퍼징·리뷰·단계 배치로 더 안전할 수 있지만 불완전한 시험·미기록 행동·없는 의존으로 더 어려울 수도 있다. 정돈된 평가나 PoC 통과만으로 무인 배치 준비를 입증하지 못한다.
PoC와 개발자 의도 시험을 함께 보고하고 도구·네트워크 권한, 기록 정리, 시간과 단계 오류를 공개하며 실제 유지관리자의 수용·수정·거절을 추적해야 한다. 다른 공격 경로·새 약점도 중요하다. 과거 패치와 문자 일치는 행동 검증의 대안이 아니다.
검색 가능한 기술 지식 기반은 지침·도구 기록·패치·검증을 보존하지만 코드를 맞게 만들지는 않는다. 근거 있는 결론은 Opus의 실제 개선과 충돌 점수가 개발자 정렬 성공보다 29.5%포인트 높았다는 것이다. 생성 수리는 후보이며 안전성과 정상 행동에 독립 증거가 필요하다.