도구를 쓰는 AI 에이전트가 환불을 집행하고 기록을 고치고 다음 작업을 트리거하기 시작하면서, 평가의 질문이 바뀌었다. 이제 묻는 것은 "결과가 맞았는가"가 아니라 "그 행동을 뒷받침할 근거를 실행 전에 실제로 확보했는가"다. 이 논문은 656개 과제로 짠 벤치마크 SafeActBench로 열 개 모델·하네스 조합을 돌려, '근거에서 행동까지(evidence-to-action)' 이어지는 사슬이 어디서 끊어지는지 추적했다. 결론부터 말하면, 사슬은 실행 그 자체보다 그 앞—조사를 덜 끝내거나 근거를 다 갖추기 전에 손대는 지점—에서 더 자주 끊어진다.
예전 평가는 "함수를 맞게 호출했는가"에 가까웠다. 올바른 도구를, 올바른 대상에, 올바른 인자로 불렀으면 통과였다. 그런데 에이전트가 '답을 내놓는 존재'에서 '상태를 바꾸는 존재'로 넘어오면서 이 기준이 허술해졌다. 논문은 앱의 상태를 바꾸거나 바깥에 실제 효과를 내는 도구 호출을 결과성 행동(consequential action, 되돌리기 어려운 집행)이라 부른다. 환불 발행, 문서 발송, 레코드 수정 같은 것이다.
핵심 구분은 이것이다. '결과가 맞다'와 '그 행동에 근거가 있었다'는 별개다. 에이전트는 중복인지 확인하지도 않고 올바른 금액을 환불해 성공 응답을 받을 수 있다. 상태가 환불을 허용하고 호출도 정확하면 겉보기엔 성공이다. 하지만 에이전트가 남긴 기록 안에 근거가 남지 않았다면, 그 행동은 '뒷받침되지 않은' 것이다. 그리고 뒤 행동이 앞 결과에 기댈 때 이 결함은 그대로 전파된다.
기존 연구도 정적인 함수 호출 정확도에서 상태가 바뀌는 상호작용 평가로 이미 넘어왔다(AgentBench, WorkArena, OSWorld, AppWorld 등). 다만 '각 결과성 행동이 실행 전에 세운 근거에 의해 뒷받침되는가'는 덜 직접적으로 다뤄졌다는 것이 이 논문의 출발점이다.
논문의 뼈대는 하나의 사슬이다. '행동 전에 근거를 갖췄는가 → 행동 → 그 결과가 다음 행동으로 이어지는가.' 중복 결제 환불이라는 한 장면으로 따라가 보자.
1. 행동 앞의 근거. 환불 버튼을 누르기 전에 에이전트는 '이 결제가 정말 중복인지'부터 확인해야 한다. 영수증을 찾아 금액·대상·조건을 맞춰 보는 단계다. 여기서 핵심은 숫자가 맞느냐가 아니라 '그 숫자가 어디서 왔느냐'다. 옆 결제 A에서 49.99달러를 봤는데 환불 대상인 결제 B도 우연히 49.99달러라고 해서, A의 영수증이 B를 환불해도 된다는 근거가 되지는 않는다. 논문은 이렇게 출처에 묶인 정보를 증거(provenance, 정보의 출처)라고 부른다. 바로 그 환불이 건드리는 결제·고객·금액에 대한 관측이어야 증거다.
2. 조사된 비행동. 영수증을 찾아보니 중복이 아니거나 환불 조건이 안 맞을 수도 있다. 이때 그냥 "안 됩니다" 하고 멈추는 것만으로는 부족하다. 논문은 '조사된 비행동(investigated non-action)'을 요구한다. 왜 안 되는지 필요한 조사를 끝낸 뒤 멈추라는 것이다. 조사도 없이 미리 멈추면 게으른 거절이고, 조건이 분명치 않은데 일단 환불부터 하면 성급한 행동이다.
3. 연쇄. 환불이 끝나면 refund_id=R42 같은 식별자가 나온다. "환불했다고 고객에게 알려라"는 후속 행동은 반드시 '그 환불이' 돌려준 R42를 써야 한다. 다른 데서 주운 번호를 쓰면 의존성을 채우지 못한다. 순서도 묶인다. 알림은 환불이 실제로 끝난 뒤에야 보낼 수 있다.
이 세 마디를 사람 눈대중이 아니라 기계적으로 재려고 두 장치를 뒀다. 하나는 증거 원장(Evidence Ledger)으로, 에이전트가 확인한 사실을 '어디서 얻었고 무엇을 설명하는지'와 함께 적어 둔다. 다른 하나는 결정론적 평가기로, 에이전트가 남긴 행동·관측의 기록인 궤적(trajectory)을 그대로 되돌려 보며(replay) 필요한 조사를 했는지, 올바른 도구·대상·인자를 썼는지, 후속 행동이 선행 결과에 묶였는지를 따진다. 숨은 속마음을 들여다보거나 다른 AI의 판정에 기대지 않고, 과제 맥락·관측된 도구 사용·결과 상태만 쓴다.
SafeActBench는 656개 과제를 고객·정책, 엔지니어링·인프라, 법률·금융, 연구 보조, 스마트홈 제어, 헬스케어까지 여섯 개 운영 도메인에 나눠 담았다. 평가 프로토콜은 다섯 단계로, 정적 판단에서 의존성 제약 실행까지 점점 까다로워진다.
| 프로토콜 | 성격 | 행동 수 | 통과 조건 | 과제 수 |
|---|---|---|---|---|
| Legacy | 정적 판단 | – | 고정 후보 행동에 Allow/Block/Defer 판정 | 86 |
| V0 | 조사된 비행동 | 0 | 필요한 조사를 끝내고 결과성 행동을 하지 않음 | 175 |
| V1 | 단일 행동 | 1 | 올바른 행동 하나 전에 필요한 근거 확보 | 131 |
| V2 | 선형 다중 행동 | 2개 이상(≥2), 체인 | 각 행동 전 근거 + 후속이 선행의 실제 결과 사용 | 132 |
| V3 | 의존성 제약 다중 행동 | 2개 이상(≥2), DAG | 각 행동 전 근거 + 유효한 위상 순서면 어떤 순서든 | 132 |
표의 DAG는 '선후 관계만 정해진 작업 그물'(순서가 하나로 고정되지 않음)을, 위상 순서는 '선행 작업이 먼저 오기만 하면 되는 순서'를 뜻한다. 핵심 지표는 exact_case_success(ECS)로, 한 에피소드가 프로토콜 요구를 전부 만족했는지를 재는 통과/실패 이진값이다. 하나라도 어긋나면 실패다.
평가 대상은 다섯 개 모델 패밀리를 각각 두 가지 하네스에 올린 열 개 구성이다. 최신 상용 대형 모델부터 경량 오픈소스 모델까지 성격이 다른 패밀리를 함께 담았다. 여기서 하네스(harness)란 모델의 생각을 실제 도구 호출로 옮겨 주는 실행 프레임—말하자면 모델을 돌리는 운영체제(OS) 같은 것이다. 같은 두뇌(모델)라도 어떤 OS를 쓰느냐에 따라 일 처리 방식이 달라진다. 하나는 모델 제조사가 내놓은 전용 프레임워크, 다른 하나는 범용 ReAct 방식의 공유 프레임워크로, 같은 모델을 서로 다른 OS에 올려 'OS가 성능을 얼마나 가르는지' 떼어 보려는 설계다. 모든 구성은 같은 공개 과제·도구를 받고 채점 명세는 끝까지 숨겼으며, 각 과제-구성 쌍을 3회 반복 실행해 커버리지 100%를 보고한다.
여기서 이 평가가 보는 것과 못 보는 것을 짚어 두자. 평가기는 겉으로 드러난 궤적만 검사하지, 모델이 속으로 무엇에 기댔는지는 보지 못한다. 그래서 이 벤치마크는 '행동이 가진 정보와 앞뒤가 맞았는가(정합)'를 잴 뿐, '그 정보 때문에 그렇게 행동했는가(인과)'까지 재지는 못한다.
두 패턴이 또렷하다.
첫째, 정적 판단을 잘해도 증거 기반 실행은 훨씬 약할 수 있다. 어떤 구성은 Legacy에서 97.7%를 받는다(무작위 찍기 기대치가 약 33.3%인 3지 판정이니 거의 만점이다). 그런데 V1~V3로 가면 갈린다. DeepSeek를 전용 하네스에 올린 구성은 약 60%대를 유지하는 반면, GLM을 ZCode에 올린 구성은 12.1~34.1%로 주저앉고 V2(선형 다중 행동)에서 12.1%로 가장 낮았다. 과제를 똑같이 고정해 다시 재도 간극은 남아, 정적 정확도가 최소 95%인데 상호작용 ECS는 최대 52%였다(부록 C.2). 요컨대 정적 벤치마크 만점은 "무엇을 해야 하는지 판단할 줄 안다"는 뜻일 뿐, "상호작용 속에서 근거를 세우고 집행할 줄 안다"는 보장이 아니다.
둘째, 하네스 효과가 크고 방향이 모델마다 다르다. DeepSeek는 공유 하네스(57.5%)보다 전용 하네스(63.0%)에서 전체 ECS가 올랐는데 그 상당 부분이 Legacy에서 왔고, GLM은 거꾸로 공유 하네스(41.0%)가 전용 하네스(37.7%)보다 나았다. 나머지 패밀리는 자기 전용 하네스를 2.1~4.4점 선호했다. 같은 모델을 어느 OS에 올리느냐가 그 자체로 성능 변수라는 뜻이다.
더 흥미로운 건 사슬이 어디서 끊어지는가다. V0에서 조사를 끝내기 전에 멈춘 비율(BSR)은 21.7~62.9%, V1에서 근거를 다 갖추기 전에 손댄 비율(PAR)은 37.0~66.9%로 높았다. 반면 근거를 갖춘 뒤 행동했을 때의 성공률(CAS)은 열 중 아홉이 93.2~100%였다(한 구성만 83.3%). 즉 일단 근거가 준비되면 단일 행동 실행은 대체로 믿을 만하다. 문제는 그 앞이다. 조사를 덜 끝내고 멈추거나, 근거가 완성되기 전에 먼저 행동하는 상류(upstream)에서 실패가 더 많이 난다.
다중 행동은 실패 모양이 더 갈린다. V2·V3에서는 '행동 직전인데 전제가 안 선 경우(Gap)'와 '시작은 했지만 끝맺지 못한 경우(Part.)'가 새로 드러나는데, 둘의 비중이 구성마다 다르다. 마치 어떤 사람은 계획 단계에서 막히고(Gap), 다른 사람은 일단 시작은 하지만 마무리를 못 하는(Part.) 것처럼, 모델·하네스 조합마다 '실패하는 성격'이 다른 셈이다. 게다가 두 유형은 한 에피소드에서 겹칠 수 있어 깔끔히 둘로 쪼개지지도 않는다. 다중 행동 실패를 '하나의 공통 병목'으로 뭉뚱그릴 수 없다는 뜻이다.
앞서 말했듯 이 평가는 관측된 행동의 '정합'을 볼 뿐 '인과'를 단정하진 못한다. 겉으로 사슬이 이어진 것처럼 보이는 운 좋은 궤적과 실제로 근거에 기댄 궤적을, 관측만으로 완벽히 가르기는 어렵다.
그 위에 더 중요한 한계가 있다. 명세의 대표성이다. 벤치마크는 저자들이 설계한 요구 명세 위에서 돈다. 평가기가 쓰는 '필요한 근거'의 정의가 곧 채점 기준이므로, 그 명세가 현실의 결정 상황을 얼마나 대표하느냐가 결과의 일반화를 좌우한다. 저자 레퍼런스 해법 656개가 전부 평가기를 통과했고 인간 감사도 거쳤다고 하지만(부록 B.3), 이는 평가기의 자기정합성 검증이지 '명세가 곧 좋은 운영 규범'이라는 보장과는 다른 층위다. 또한 모델·하네스 구성은 특정 세대의 특정 조합이라, 다른 세대나 다른 프롬프트 전략에서 BSR·PAR 분포가 어떻게 움직일지는 이 표만으로 단정하기 어렵다.
이 논문은 상호작용 평가의 흐름 위에 선다. 앞서 말한 AgentBench 계열이 '과제를 완료했는가'를 현실적으로 재 왔다면, 이 논문은 '완료' 대신 '실행 전에 선 근거가 그 행동을 뒷받침하는가'로 초점을 옮긴다.
이 글에서 처음 나오는 두 연구와 견주면 색이 분명해진다. EnvTrustBench는 낡거나 조작된 관측을 지나치게 믿는 과신(overtrust)을 다루고, Near-Miss는 에이전트가 정책 점검을 건너뛰고도 최종 상태엔 도달할 수 있음을 보인다. 이 논문은 한 걸음 더 들어가 '그 행동이 건드리는 바로 그 대상·상태에 대해 실행 전 근거가 섰는지', '연쇄 행동이 선행 결과에 제대로 묶였는지'까지 본다. 언제 더 알아보고, 멈추고, 기권할지를 다룬 정보 탐색·기권 연구들과도 '행동이 일어나는 바로 그 지점에서 근거를 요구한다'는 점에서 구별된다.
이 논문의 발견은 학술적 이야기로 그치지 않는다. 우리 온틀이 AI 에이전트를 현업에 붙이며 치른 값비싼 교훈과 같은 지점을 짚기 때문이다.
온틀은 고객 프로젝트마다 AI PM을 파견해 접수부터 서비스 노출까지 관리한다. 논문이 가장 날카롭게 꽂히는 장면은, AI PM이 어떤 작업을 '진행'으로 밀거나 고객에게 지급성 혜택(예: 크레딧)을 집행하는 순간이다.
실제 사고가 있었다. 중복 클릭 한 번에 2만3천 크레딧이 잘못 나간 적이 있어, 돈·크레딧 같은 지급성 액션은 1회 제한과 원장 정정 원복을 기본으로 둔다. 이 논문의 틀을 빌리면, 당시 끊어진 고리는 집행(버튼) 자체가 아니었다. 버튼은 정상 작동했다. 약했던 건 그 앞, '이 지급이 이 수혜자에게 이 조건에서 아직 집행되지 않았다'를 출처에 묶어 확인하는 단계에 가깝다. 값이 맞고 호출이 성공했다고 끝이 아니라는 논문의 지적과 결이 닿는다.
그래서 온틀의 PM 재설계 방향—PM의 '말'을 믿는 대신, 공통 액션 서비스가 서버에서 근거 상태를 확인하고 결정론적으로 집행하도록 좁은 도구에 가둔 구조—은 논문이 LLM 판정 대신 결정론적 궤적 평가기를 쓴 것과 결이 같다. 이 논문이 주는 구체적 보강점은 측정 축이다. PM의 행동 로그를 BSR(조사 미완 정지)·PAR(조기 실행)·Gap(미해결 전제)·Part.(미완 워크플로)로 나눠 재면, "성공/실패"라는 단일 결과를 "어느 마디에서 끊어졌나"로 해부할 수 있다. 특히 온틀의 on_hold(결정 기다리는 중) 상태는 논문의 '조사된 비행동'과 닮았다. 그냥 멈추는 게 아니라, 왜 멈춰야 하는지 필요한 확인을 끝낸 뒤 멈춰야 고객에게 설명되는 정지가 된다. 조사 없이 멈추면 그건 BSR 유형의 성급한 정지에 가깝다.
기존 벤치마크는 대체로 과제를 완료했는지와 최종 상태가 맞는지를 봅니다. SafeActBench는 그 '직전'을 봅니다. 상태를 바꾸는 행동이 일어나기 바로 전에, 그 행동이 건드리는 대상·상태에 대한 근거가 관측된 궤적 안에서 출처 수준으로 확보됐는지 확인합니다. 최종 상태가 맞아도 근거가 없으면 실패로 봅니다.
조건을 붙여야 합니다. CAS는 '근거가 완성된 뒤 행동을 시도한 경우'의 성공률입니다. 그 조건 안에서는 단일 행동이 대체로 믿을 만했지만(열 중 아홉이 93.2~100%), 많은 실패는 그 조건에 닿기 전—조사 미완이나 조기 실행—에서 났습니다. "근거만 갖추면 집행은 잘한다, 문제는 근거를 갖추는 과정"이라고 읽는 게 정확합니다.
아닙니다. 방향이 모델마다 달랐습니다. DeepSeek는 전용 하네스에서 공유 하네스보다 올랐지만, GLM은 반대로 공유 하네스에서 더 나았습니다. 나머지는 자기 전용 하네스를 소폭 선호했고요. 그래서 하네스는 모델과 짝지어 함께 실측해야 할 변수입니다.