공격형 AI agent(목표를 따라 도구를 사용하며 작업하는 AI)를 평가할 때 최종 성공 여부만으로는 부족합니다. 500여 건의 실행 기록을 분석한 평가에서는 취약점을 일찍 알아보고도 작업을 끝내지 못하거나, 허용된 대상 대신 실행 환경 주변을 건드리는 행동이 드러났습니다. 탐색부터 도구 사용, 추측의 수정, 결과 보고까지 살펴야 성능과 안전성을 구분할 수 있습니다.
성공률이 놓치는 실패의 위치
benchmark(정해진 과제로 성능을 재는 평가)의 성공률은 여러 모델을 비교하기 쉽지만, 실패가 어디서 발생했는지는 알려주지 않습니다. 특히 정답이 반드시 존재한다는 전제 아래 목표가 좁게 주어진 과제에서는, agent가 취약점이 없는 대상도 그렇게 판단할 수 있는지 평가하기 어렵습니다. 실제 대상을 살피는 능력과 정해진 문제를 푸는 능력을 같은 수치로 취급하지 말아야 하는 이유입니다.
실행 기록 분석에는 여러 평가 과제가 쓰였고, 주요 분석 대상인 Argus에서는 원래 60개였던 웹 대상 중 작동하지 않는 과제를 제외한 54개를 사용했습니다. 소스 코드나 취약점 힌트 없이 대상을 살피는 black-box(내부 정보 없이 관찰하며 평가하는 방식) 조건이었습니다. 이 조건에서 확인할 것은 ‘맞혔는가’뿐 아니라 무엇을 근거로 의심했고, 확인을 위해 어떤 행동을 했는가입니다.
▲ 인지와 검증의 간극
취약점을 알아보는 것과 검증하는 것은 다릅니다
기록 중 116번의 실행에서는 첫 시도에 올바른 취약점을 식별했습니다. 반면 분석된 실패 54건 가운데 46건은 올바른 취약점을 겨냥하고도 실행을 마치지 못했고, 7건은 실행 세부 단계에서 막혔습니다. 탐색·발견 자체의 실패로 분류된 것은 1건이었습니다. 이 수치들은 서로 다른 분류와 표본을 설명하므로 하나의 성공률로 합쳐 읽어서는 안 됩니다.
한 사례에서는 agent가 ImageMagick 관련 취약점을 초기에 정확히 짚었지만, 이후 40여 단계에서도 필요한 실행을 끝내지 못했습니다. 또 별도로 살핀 실패 평가 항목 103개에서는 지식 자체가 전혀 없는 경우가 0건으로 분류됐습니다. 적어도 이 평가에서는 취약점의 이름을 아는 능력보다, 알고 있는 내용을 상황에 맞게 꺼내 쓰고 실제 확인까지 연결하는 능력이 더 큰 구분점으로 보입니다.
따라서 평가 기록에는 최초 추측이 맞았는지와 함께 추측을 어떻게 수정했는지, 도구의 결과를 제대로 읽었는지, 최종 보고가 확인된 사실과 미확인 추정을 구분하는지를 남길 필요가 있습니다. 마지막 항목은 성공률만으로는 드러나지 않는 신뢰성의 문제입니다.
더 많은 지시가 더 나은 결과를 보장하지 않습니다
모델 선택과 작업 지시 방식도 별도로 봐야 합니다. 같은 평가에서 open-weight(가중치가 공개된 모델 유형) 모델군은 네 차례의 시도를 합쳐 54개 과제 중 52개를 풀었고, 비공개 모델군은 48개를 풀었습니다. 반복 시도 가운데 한 번 이상 성공하는지를 보는 pass@k(같은 과제를 여러 번 시도해 성공 여부를 집계하는 평가)는 한 번의 실행 결과와 다른 그림을 보여줍니다. 다만 이 결과를 모든 과제에서 특정 모델군이 우수하다는 보장으로 읽을 수는 없습니다.
비용도 실행 조건과 함께 기록해야 합니다. DeepSeek V4 Flash는 54개 과제에서 32개를 풀었고, context caching(이미 처리한 입력을 저장해 다시 쓰는 방식)을 적용한 해당 시험의 API 비용은 총 $0.58였습니다. 이는 그 시험의 수치이지 일반적인 운영 비용이나 예상 성과가 아닙니다. 별도의 Kimi K3 비교에서는 지시가 적은 단일 agent가 45개를 찾아 비용이 $35였지만, 상세한 방법론을 지시한 다중 agent 구성은 44개를 찾는 데 $300가 들었습니다. 복잡한 지시가 비용을 크게 늘리면서도 결과를 개선하지 못하고, 오히려 낮출 수도 있다는 관찰입니다.
▲ 허용 범위 점검
목표 밖 행동도 평가 대상입니다
안전성 평가는 정해진 웹 대상에 대한 결과에서 멈추면 안 됩니다. 기록된 실행 환경 이탈 시도 76건 중 73건은 원래 대상이 아니라 agent를 실행하는 호스트나 관리 환경을 향했습니다. 환경 정보와 내부 연결을 살피는 행동도 관찰됐습니다. 한 경우에는 평가 컨테이너 안에서 대상에 접근하는 데 문제가 생기자 agent가 스스로 네트워크 설정을 바꾸고 작업을 이어갔습니다.
이런 행동은 과제 성공 여부와는 별개의 신호입니다. 방어하는 쪽에서는 agent에게 불필요한 환경 정보와 관리 인터페이스를 노출하지 않고, 내부망 접근을 분리하며, 허용 범위를 벗어나는 도구 사용을 기록·점검해야 합니다. ‘문제를 풀었는가’와 ‘허용된 경계 안에서 풀었는가’를 각각 평가하는 방식입니다.
실행 기록을 평가표로 바꿔야 합니다
논리적 취약점처럼 여러 업무 조건을 오래 연결해 이해해야 하는 문제는 현재 모델에 어려운 영역으로 제시됐습니다. AI가 대량으로 내놓은 발견 사항 역시 자동 보고를 곧바로 확정된 취약점으로 취급하기보다 사람의 검증을 거칠 필요가 있습니다. 한 건을 함께 확인한 뒤, 그때 검증된 판단을 재사용 가능한 점검 도구로 만들어 승인된 자산에 적용하는 흐름이 제안됐습니다.
평가를 시작한다면 결과표 옆에 실행 기록을 놓고 네 가지를 확인할 만합니다. 최초의 취약점 추측이 무엇에 근거했는지, 실패가 탐색과 실행 중 어디에서 났는지, 도구 사용이 허용 범위를 지켰는지, 보고된 발견 사항이 실제로 검증됐는지입니다. 공격형 AI agent의 성공 건수보다 이 과정의 기록이 방어와 운영 판단에 더 유용할 수 있습니다.