LLM 에이전트 안전성 테스트를 자동화하려는 Vera 논문 읽기

모델보다 먼저, 에이전트를 어떻게 시험할 것인가

오늘 소개할 논문은 Yunhao Feng, Ruixiao Lin, Ming Wen, Qinqin He, Yanming Guo, Yifan Ding, Yutao Wu, Jialuo Chen, Yunhao Chen, Xiaohu Du, Jianan Ma, Zixing Chen, Zhuoer Xu, Xingjun Ma, Xinhao Deng의 Safety Testing LLM Agents at Scale: From Risk Discovery to Evidence-Grounded Verification입니다. 원문은 arXiv 원문에서 볼 수 있습니다.

이 논문은 LLM 에이전트(대형언어모델이 외부 도구를 사용해 여러 단계를 스스로 수행하는 시스템)의 안전성을 대규모로 테스트하는 방법을 다룹니다. 초록만 보면, 저자들은 Vera라는 자동화 안전 테스트 프레임워크를 제안합니다. 문제의식은 분명합니다. 에이전트가 단순히 답변만 하지 않고 파일을 만들고, 코드를 실행하고, 브라우저나 외부 도구를 호출하며, 여러 차례 상호작용을 이어가면 위험도 더 복잡해집니다. 그런데 기존 안전성 테스트는 전문가가 미리 정한 위반 사례를 중심으로 설계되고, 결과 판단도 하드코딩된 규칙에 기대는 경우가 많습니다. 에이전트가 빠르게 변할수록 확장 비용이 커지는 구조입니다.

저는 이 문제의식이 꽤 중요하다고 봅니다. 생성형 AI 시장 초반에는 모델이 무엇을 아는지, 얼마나 잘 답하는지가 중심 질문이었습니다. 하지만 에이전트 시장으로 넘어가면 질문이 달라집니다. 이제는 모델이 무엇을 말했는지보다, 실제 환경에서 어떤 행동을 했고 그 결과가 무엇으로 남았는지가 중요해집니다. 특히 업무 자동화, 개발 자동화, 금융 리서치, 고객 응대, 로보틱스 제어처럼 도구 사용과 실행 결과가 연결되는 영역에서는 더 그렇습니다.

Vera가 보려는 것은 답변이 아니라 실행 흔적입니다

논문 초록에서 가장 눈에 띄는 부분은 Vera가 모델의 자기 보고에 기대지 않으려 한다는 대목입니다. 여기서 자기 보고란 에이전트가 스스로 “저는 안전하게 처리했습니다”라고 말하는 식의 응답을 뜻합니다. 저자들은 대신 환경 상태와 도구 호출 증거를 근거로 결과를 판단한다고 설명합니다. 쉽게 말하면, 에이전트가 안전하다고 말했는지보다 실제 파일, 상태, 로그, 도구 호출 결과가 어떻게 남았는지를 보겠다는 접근입니다.

이 차이는 작아 보이지만 실무적으로는 큽니다. 사람에게 보고서를 쓰는 챗봇이라면 답변 품질만 보아도 어느 정도 판단할 수 있습니다. 하지만 에이전트가 외부 도구를 호출하는 순간, 안전성은 텍스트의 문제가 아니라 시스템 상태의 문제가 됩니다. 어떤 파일이 만들어졌는지, 어떤 명령이 실행됐는지, 어떤 환경 변화가 있었는지, 어떤 도구 호출이 이어졌는지를 봐야 합니다.

초록에 따르면 Vera는 세 단계의 자기 강화형 파이프라인을 사용합니다. 먼저 문헌 기반 탐색으로 새롭게 등장하는 위험을 계속 발견하고, 이를 안전 위험, 공격 방법, 도구 실행 환경의 분류 체계로 구조화합니다. 이어서 이 분류 체계의 여러 축을 조합해 실행 가능한 안전성 테스트 케이스를 만듭니다. 각 케이스에는 구체적인 안전 목표, 프로그램으로 구성된 초기 상태, 관찰 가능한 산출물에 근거한 결정론적 검증 조건이 포함됩니다. 마지막 단계에서는 서로 다른 에이전트를 격리된 샌드박스(실제 시스템과 분리된 시험 환경)에서 실행하고, 제어 에이전트가 실행 중 관찰을 보면서 여러 턴의 상호작용을 이끌어갑니다.

왜 자동화된 안전 테스트가 필요해지는가

초록에서 저자들이 지적하는 기존 방식의 한계는 두 가지로 읽힙니다. 하나는 위험 목록을 전문가가 직접 설계해야 한다는 점입니다. 다른 하나는 결과 판단이 하드코딩된 규칙에 많이 묶인다는 점입니다. 이런 방식은 작고 고정된 제품에는 어느 정도 작동할 수 있습니다. 하지만 에이전트는 그렇지 않습니다. 사용할 수 있는 도구가 늘어나고, 실행 환경이 바뀌고, 공격 방법도 계속 변합니다. 그러면 테스트 자체도 살아 있는 시스템처럼 업데이트되어야 합니다.

그래서 Vera의 첫 단계가 문헌 기반 탐색이라는 대목이 중요합니다. 초록에 따르면 이 단계는 새롭게 등장하는 위험을 계속 발견하고, 이를 분류 체계로 정리합니다. 여기서 분류 체계는 단순한 목록이 아니라 테스트 케이스를 만드는 재료에 가깝습니다. 안전 위험, 공격 방법, 실행 환경을 각각의 축으로 보고 조합하면 더 많은 상황을 만들 수 있기 때문입니다.

두 번째 단계인 조합적 구성도 같은 맥락입니다. 예를 들어 어떤 위험이 있고, 어떤 공격 방법이 있으며, 어떤 도구 실행 환경이 있다고 할 때, 이들을 조합하면 하나의 구체적인 시험 문제가 됩니다. 초록은 각 안전성 케이스가 안전 목표, 프로그램으로 구성된 초기 상태, 결정론적 검증 조건을 포함한다고 설명합니다. 여기서 결정론적 검증 조건은 같은 상태라면 같은 방식으로 판단할 수 있는 규칙이라고 이해하면 됩니다. LLM 에이전트는 비결정적입니다. 같은 요청에도 다른 답을 할 수 있습니다. 그래서 테스트 판단은 관찰 가능한 증거를 근거로 최대한 명확해야 합니다.

세 번째 단계에서는 실행이 중요해집니다. Vera는 이질적인 에이전트들을 격리된 샌드박스에서 실행하고, 제어 에이전트가 런타임 관찰을 보면서 여러 턴의 상호작용을 조정한다고 합니다. 여기서 제어 에이전트는 시험관에 가까운 역할입니다. 테스트 대상 에이전트가 어떻게 반응하는지 보면서 다음 상호작용을 이끌어가는 구조입니다. 초록 기준으로는 이 설계가 비결정적인 에이전트를 소프트웨어 테스트 원칙에 맞게 다루려는 시도로 읽힙니다.

초록에 담긴 실험 결과를 조심스럽게 읽기

저자들은 Vera를 네 개의 프로덕션 에이전트 프레임워크, OpenClaw, Hermes, Codex, Claude Code에서 평가했다고 밝힙니다. 초록에 따르면 이 과정에서 상당한 안전성 취약점이 드러났고, 다중 채널 공격에서는 평균 공격 성공률이 93.9%에 도달했다고 합니다. 또한 Vera-Bench라는 벤치마크를 공개하며, 3개의 실행 설정에 걸친 124개 위험 범주와 1,600개의 실행 가능한 안전성 케이스로 구성되어 있다고 설명합니다.

이 숫자는 눈에 띕니다. 다만 저는 이 글에서 초록 밖의 세부 실험 조건이나 각 프레임워크별 차이를 추정하지 않겠습니다. 어떤 공격을 다중 채널 공격으로 정의했는지, 각 프레임워크의 설정이 어땠는지, 실패와 성공을 어떤 세부 기준으로 나눴는지는 본문을 더 읽어야 확인할 수 있습니다. 따라서 여기서 말할 수 있는 범위는 제한적입니다. 초록 기준으로는 저자들이 대규모 실행형 테스트 인프라로 현재 에이전트 시스템의 안전성 약점을 드러냈다고 주장한다고 보는 편이 적절합니다.

그래도 이 결과의 의미는 작지 않습니다. 에이전트가 실제 업무 환경에 들어갈수록 안전성 평가는 단순한 레드팀 프롬프트 모음이 아니라, 실행 환경과 상태 검증을 포함하는 테스트 인프라에 가까워질 가능성이 높습니다. 특히 코딩 에이전트, 리서치 에이전트, 브라우저 에이전트, 업무 자동화 에이전트처럼 도구 호출을 많이 쓰는 영역에서는 이런 접근이 더 중요해질 수 있습니다.

투자자 관점: 다음 인프라 레이어는 안전 테스트 스택일 수 있습니다

제가 이 논문을 투자자 관점에서 눈여겨보는 이유는, 에이전트 시장의 병목이 모델 자체에서 운영 인프라로 이동할 가능성을 보여주기 때문입니다. 초기에는 더 좋은 모델, 더 긴 컨텍스트, 더 낮은 추론 비용이 핵심 경쟁축이었습니다. 하지만 기업이 에이전트를 실제 업무에 붙이기 시작하면 질문은 더 구체적으로 바뀝니다. 이 에이전트가 어떤 조건에서 위험해지는가. 위험을 반복적으로 재현할 수 있는가. 수정 후에는 정말 나아졌는가. 감사나 내부 통제 관점에서 증거를 남길 수 있는가.

Vera가 제안하는 방향은 이 질문에 가깝습니다. 위험을 발견하고, 테스트 케이스로 만들고, 샌드박스에서 실행하고, 환경 상태와 도구 호출 증거로 검증합니다. 전통적인 소프트웨어 테스트, 보안 테스트, 관측 가능성 도구의 사고방식을 에이전트 환경에 맞게 다시 조합하는 시도처럼 보입니다. 저는 이 지점에서 새로운 인프라 시장이 열릴 수 있다고 봅니다.

물론 조심스럽게 봐야 합니다. 초록만으로는 Vera가 실제 기업 환경의 복잡한 권한 구조, 데이터 민감도, 내부 시스템 연동, 인간 승인 절차까지 얼마나 잘 포괄하는지 알 수 없습니다. 자동으로 발견한 위험 분류 체계가 얼마나 신뢰할 수 있는지, 테스트 케이스가 현실의 업무 흐름을 얼마나 대표하는지도 추가 확인이 필요합니다. 벤치마크가 크다는 사실만으로 산업 표준이 된다고 말하기는 어렵습니다.

그래도 방향성은 중요합니다. 에이전트가 더 많은 권한을 갖게 될수록 기업은 모델 공급자에게만 의존하기 어렵습니다. 자체 업무 환경에서 안전성을 검증하고, 회귀 테스트를 돌리고, 실패 증거를 남기고, 배포 전후의 위험을 비교하는 도구가 필요해질 가능성이 높습니다. 이 논문은 그 시장이 단순한 평가 리포트가 아니라 실행 가능한 테스트 스택으로 형성될 수 있음을 보여주는 사례로 읽힙니다.

로보틱스와 물리 세계로 가면 더 민감해집니다

논문 자체는 LLM 에이전트의 외부 도구 사용과 실행 환경을 다룹니다. 초록에 로보틱스 실험이 직접 언급되지는 않습니다. 다만 투자자 관점에서 조심스럽게 연결해보면, 이 문제의식은 로보틱스와 물리 AI에서도 더 중요해질 수 있습니다. 로봇이 실제 세계에서 움직이면 에이전트의 행동은 더 이상 파일이나 로그의 문제가 아니라 물리적 결과로 이어질 수 있기 때문입니다.

여기서 중요한 것은 과장하지 않는 것입니다. Vera가 곧바로 로봇 안전성 테스트의 완성형이라고 말할 수는 없습니다. 초록 기준으로 Vera는 에이전트 프레임워크와 도구 실행 환경을 대상으로 한 안전 테스트 프레임워크입니다. 하지만 위험 분류, 실행 가능한 케이스 생성, 격리 환경, 관찰 가능한 증거 기반 검증이라는 구조는 물리 세계에 가까운 에이전트 시스템에도 참고할 만한 사고방식일 가능성이 있습니다.

앞으로 임바디드 AI(몸을 가진 기계나 로봇 안에서 작동하는 AI)와 업무용 소프트웨어 에이전트가 모두 커질수록, 공통 질문은 비슷해질 수 있습니다. 에이전트가 목표를 달성하는가뿐 아니라, 어떤 조건에서 위험한 행동을 하는가. 그 위험을 재현할 수 있는가. 개선이 실제로 위험을 줄였는가. 이 질문에 답하는 인프라가 시장에서 점점 중요해질 수 있다고 봅니다.

마지막으로 남는 질문

저는 이 논문을 모델 평가 논문이라기보다 에이전트 시대의 안전성 운영 논문으로 읽었습니다. 초록 기준으로 Vera의 핵심은 더 똑똑한 판정 모델을 하나 만드는 것이 아니라, 위험 발견부터 실행형 테스트, 증거 기반 검증까지 이어지는 파이프라인을 만드는 데 있습니다. 에이전트 시스템이 빠르게 변하기 때문에 이 구조가 중요합니다. 빠르게 변하는 시스템은 한 번의 평가표로 관리하기 어렵습니다. 계속 발견하고, 계속 시험하고, 계속 증거를 남기는 구조가 필요합니다.

투자자 관점의 takeaway는 세 가지입니다.

첫째, AI 에이전트 시장에서는 안전성 테스트와 검증 인프라가 독립적인 가치사슬로 커질 수 있습니다. 둘째, 좋은 테스트 도구는 모델의 답변을 보는 데 그치지 않고 실제 실행 흔적과 환경 상태를 봐야 할 가능성이 높습니다. 셋째, 기업 도입이 본격화될수록 벤치마크보다 중요한 것은 각 기업의 실제 환경에서 반복 가능하고 감사 가능한 검증 체계를 갖추는 일일 수 있습니다.

초록만으로는 이 프레임워크의 한계와 재현성을 충분히 판단할 수 없습니다. 그러나 Vera가 제기하는 질문은 선명합니다. 에이전트가 일을 하게 만들었다면, 이제는 그 일이 안전하게 이루어졌는지 증거로 확인할 방법도 필요합니다. 저는 이 질문이 앞으로 AI 인프라와 로보틱스 투자에서 점점 더 자주 등장할 것 같습니다.