로컬 체인에서 트랜잭션이 결정적으로 재생되고, “unsafe RPC”가 제한된 샌드박스 안에서 한 에이전트가 스마트컨트랙트를 읽고 수정하고 실행한다. 목표는 버그를 “발견”하는 데서 끝나지 않는다. 취약점을 재현하고, 패치를 적용한 뒤, 익스플로잇이 더는 성공하지 않게 만드는 단계까지 다룬다. EVMbench는 이 전 과정을 Detect–Patch–Exploit 세 가지 모드로 평가하려는 벤치마크다.

세 줄 요약

• 무슨 변화/핵심이슈인가? EVMbench는 스마트컨트랙트 보안을 “취약점 탐지”에만 두지 않고 **탐지→패치→익스플로잇(공격)**까지 포함한 에이전트형 평가로 묶는다.
• 왜 중요한가? 같은 능력 향상이 방어 자동화뿐 아니라 공격 자동화에도 쓰일 수 있다. 스마트컨트랙트처럼 자금 손실과 연결되는 영역에서는 이 점이 리스크 요인이 된다.
• 독자는 뭘 하면 되나? 보안 도입 의사결정을 “탐지 성능” 중심에서 **패치의 기능 보존(기존 테스트 통과) + 익스플로잇 실패(추가 공격 테스트)**까지 충족하는지로 옮긴다. 가능하면 내부 파이프라인에도 비슷한 채점 규칙을 적용해본다.

현황

평가 모드는 Detect, Patch, Exploit 세 가지로 나뉜다. Detect는 감사 리포트를 그라운드트루스로 삼아, 에이전트가 취약점을 얼마나 찾아내는지(recall 중심)를 본다. Patch는 실무에 가까운 절차를 따른다. 에이전트가 코드를 고친 뒤 기존 테스트가 통과하는지로 기능 보존을 확인한다. 이어서 평가자가 주입하는 unseen exploit tests로 패치 이후에도 공격이 성공하는지(실패해야 정답)를 검사한다.

Exploit은 공격을 “프로그램적으로” 평가하려는 축이다. OpenAI 소개 글은 익스플로잇 태스크가 라이브 네트워크가 아니라 격리된 로컬(Anvil) 샌드박스에서 돌아가며, Rust 기반 하네스가 컨트랙트를 배포하고 트랜잭션을 결정적으로 재생하며 unsafe RPC 메서드를 제한한다고 밝힌다. 또한 그레이더 우회를 줄이기 위해 커스텀 그레이더를 만들고 환경을 레드팀해 우회 수단을 찾은 뒤 패치했다고 설명한다.

분석

EVMbench의 핵심은 “정답 텍스트”를 맞히는 문제가 아니라, 돈이 걸린 보안 워크플로를 하나의 루프로 다루는 데 있다. 실전 감사에서 취약점은 보통 (1) 탐지, (2) 재현 가능한 증거(재현/PoC), (3) 패치, (4) 회귀/재공격 테스트를 통과해야 종료된다. EVMbench는 Patch에서 기존 테스트 통과 + unseen exploit tests에서 익스플로잇 실패를 요구한다. 이를 자동 채점 규칙으로 고정해, “코드를 읽고 쓰는 능력”을 실제 작업 기준에 더 가깝게 맞춘다.

동시에 이 벤치마크는 양면성을 노출한다. 자동화는 방어뿐 아니라 공격에도 쓰일 수 있다. Exploit 모드를 별도로 둔 것은 이 부분을 평가 대상으로 포함하겠다는 선택이다. 다만 대표성은 제한적일 수 있다. OpenAI는 **“EVMbench does not represent the full difficulty of real-world smart contract security”**라고 명시한다. 공개 감사/대회 기반 데이터는 대형 프로덕션 컨트랙트, 다중 컨트랙트 상호작용, 운영 중 트리아지 같은 변수를 충분히 담지 못할 수 있다. 또한 외부 리뷰(요약된 조사 결과)에서는 데이터셋에 실제로는 exploit 불가능한데 high severity로 분류된 항목이 있었다는 지적이 있다. 따라서 그라운드트루스 품질은 도입 전에 조직 차원에서 점검할 필요가 있다.

실전 적용

보안 조직이 EVMbench에서 가져오기 좋은 요소는 “점수”보다 “채점 규칙”이다. 특히 Patch의 두 단계—기존 테스트 통과로 기능 보존 확인, unseen exploit tests로 재공격 내성 확인—는 스마트컨트랙트 팀의 내부 CI에 옮겨 붙이기 쉽다. 에이전트를 도입할 때도 “취약점 위치를 맞힌다”가 아니라 “패치가 배포 가능한 상태임이 테스트로 확인된다”를 통과 기준으로 둔다. 이때 증거는 설명 문장이 아니라 테스트 실행 결과로 남긴다.

예: 감사 리포지토리(내부/외부)를 바탕으로 취약한 샘플을 모은다. 팀이 쓰는 테스트 스위트를 유지한 채 에이전트에게 패치를 맡긴다. 그 다음, 보안팀이 별도로 만든 공격 테스트(재진입, 권한 체크 우회 등)를 “unseen exploit tests”처럼 추가한다. 이를 통해 패치가 단순 수정인지, 공격을 막는 변경인지 구분한다. 이 구조는 에이전트가 테스트를 회피하는 수정이나, 기능을 손상시키는 변경을 빠르게 걸러내는 데 도움 된다.

오늘 바로 할 일 체크리스트

• 내부 스마트컨트랙트 리포지토리에서 “기존 테스트 통과”와 “익스플로잇 실패”를 동시에 요구하는 Patch 채점 파이프라인을 만든다.
• 익스플로잇 검증은 라이브가 아닌 **격리된 로컬 체인(Anvil 같은 샌드박스)**에서만 돌린다는 운영 원칙을 문서화한다.
• 에이전트 성능 보고서를 “탐지 결과” 중심에서 “패치 후 회귀 테스트/공격 테스트 결과” 중심으로 바꾼다.

FAQ

Q1. EVMbench는 무엇을 평가합니까?
A1. 스마트컨트랙트 보안에서 에이전트가 취약점을 **탐지(Detect)**하고, 코드를 **패치(Patch)**하며, 경우에 따라 **익스플로잇(Exploit)**까지 수행하는 능력을 평가합니다.

Q2. 패치가 ‘좋은 패치’인지 어떻게 검증합니까?
A2. 패치 후 기존 테스트가 통과하는지로 기능 보존을 확인합니다. 평가자가 주입하는 unseen exploit tests에서 익스플로잇이 실패하는지로 취약점 제거를 검증합니다. 또한 테스트 파일 조작을 막기 위해, 허용되지 않은 테스트 수정은 실행 전에 리셋하는 절차가 포함됩니다.

Q3. 이 벤치마크를 그대로 현실 난이도로 믿어도 됩니까?
A3. 제한이 있습니다. OpenAI가 “실세계 스마트컨트랙트 보안의 전체 난이도를 대표하지 않는다”고 명시했습니다. 데이터 라벨 품질에 대한 지적도 보고된 바 있습니다. 따라서 조직 내부 기준(자사 코드베이스, 실제 운영 제약, 추가 공격 테스트)으로 보정해 사용하는 접근이 안전합니다.

결론

EVMbench는 스마트컨트랙트 보안에서 에이전트의 능력을, 탐지 결과가 아니라 패치와 재공격 내성까지 포함한 규칙으로 평가하려 한다. 앞으로의 관전 포인트는 이 평가 방식이 “패치까지 가능한 탐지”를 기본 기대치로 만들지, 또는 공격 자동화 비용을 더 낮추는 방향으로 먼저 쓰일지에 있다.

다음으로 읽기

• AI 자료 모음 (24h) - 2026-03-07
• 연소 LLM 지식주입+평가 파이프라인
• LLM 에이전트 메모리 입장제어
• PDF 표 추출, 조건 따라 성능이 바뀐다
• 웹검색과 추론 모드 트레이드오프

참고 자료

• Introducing EVMbench | OpenAI - openai.com
• EVMbench: Evaluating AI Agents on Smart Contract Security (PDF) - cdn.openai.com
• arxiv.org - arxiv.org