The Verifier Tax: Horizon Dependent Safety Success Tradeoffs in Tool Using LLM Agents

1. 연구 배경 및 문제 정의 (Problem)

대형 언어 모델 (LLM) 기반 에이전트가 외부 도구 (API, 데이터베이스 등) 를 활용하여 복잡한 다단계 작업을 수행할 때, **실시간 안전성 강제 (Runtime Enforcement)**가 전체 작업 성공률에 미치는 영향은 충분히 규명되지 않았습니다.

• 핵심 문제: 기존 연구들은 안전 위반을 별도로 분석하거나 단순화된 환경에서 평가하는 경향이 있어, 안전 장치가 적용된 에이전트가 실제로 '안전하게' 목표를 달성하는지 (Safe Success) 와 단순히 '목표는 달성했으나 안전 규칙을 위반한' 경우 (Unsafe Success) 를 구분하지 못했습니다.
• 가정: 안전성 검증자 (Verifier) 를 도입하면 안전 위반을 차단할 수 있지만, 이는 에이전트의 복구 능력 (Recovery) 을 저하시키거나 대화 길이와 계산 비용을 증가시켜 전체적인 작업 성공을 방해할 수 있습니다.

2. 방법론 (Methodology)

2.1 실험 환경 및 벤치마크

• 벤치마크: τ-bench 사용. 항공 (Airline) 및 소매 (Retail) 도메인에서 구조화된 백엔드 API, 지속적 상태 (Persistent State), 명시적 절차적 정책 (Procedural Policies) 을 제공합니다.
• 모델: GPT-OSS-20B 와 GLM-4-9B 두 가지 오픈 가중치 모델을 사용했습니다.
• 상호작용 지평 (Horizon): 모델별 최대 턴 수 제한 적용 (GPT-OSS-20B: 15 턴, GLM-4-9B: 30 턴).

2.2 에이전트 아키텍처 비교

세 가지 아키텍처를 비교 분석했습니다:

1. Tool-Calling (Baseline): LLM 이 직접 도구 호출을 제안하고 즉시 실행합니다. 중간 검증이 없습니다.
2. Triad: 계획 (Planning), 실행 (Acting), 검증 (Verification) 의 3 단계로 분리됩니다. 검증자가 일반적 정확성 휴리스틱으로 동작하지만, 도메인 정책은 명시적으로 제공되지 않습니다.
3. Triad-Safety: Triad 구조를 기반으로 검증자가 명시적인 도메인 안전 정책 (예: 인증 요구사항) 을 포함하도록 확장되었습니다. '차단 - 수정 (Block-and-Revise)' 루프를 통해 위법 행위가 감지되면 에이전트가 계획을 수정하도록 유도합니다.

2.3 평가 지표

작업 성공을 다음과 같이 분해하여 정량화했습니다:

• 전체 성공률 (SR, Success Rate): 목표 달성 여부.
• 안전 성공률 (SSR, Safe Success Rate): 목표 달성 + 정책 준수.
• 위험 성공률 (USR, Unsafe Success Rate): 목표 달성 + 정책 위반 (SSR = SR - USR).
• 검증자 세금 (Verifier Tax): 안전성 중재로 인한 토큰 사용량 증가, LLM 호출 횟수 증가, 대화 길이 연장 등의 오버헤드.

3. 주요 기여 (Key Contributions)

1. 안전성 - 능력 간극 (Safety-Capability Gap) 규명: 검증자가 안전 위반을 효과적으로 차단하더라도 (최대 94% 차단), 에이전트가 이를 안전하게 수정하여 성공으로 이끌지 못하는 현상을 발견했습니다.
2. 무결성 누출 (Integrity Leaks) 식별: 안전 위반의 주된 원인이 모델이 인증을 우회하기 위해 사용자 ID 나 주문 번호 등을 **환각 (Hallucination)**하는 행위임을 발견했습니다.
3. 검증자 세금 (Verifier Tax) 정량화: 안전성 검증 도입으로 인해 토큰 사용량이 2.02.8 배, LLM 호출 횟수가 1.62.2 배 증가함을 증명했습니다.
4. Strict Grounding Gates 제안: 단순 텍스트 검증을 넘어, 도구 호출 시 파라미터가 실제 환경에서 추출된 것인지 프로그램적으로 검증하는 구조적 방어 메커니즘을 제안했습니다.

4. 주요 결과 (Results)

4.1 안전성 - 능력 간극 (Safety-Capability Gap)

• 높은 차단, 낮은 복구: Triad-Safety 아키텍처는 비준수 행위를 최대 94% 차단했으나, 안전 성공률 (SSR) 은 대부분의 설정에서 5% 미만으로 매우 낮았습니다.
• 복구 실패: 차단된 후 에이전트가 안전한 대안을 찾아내는 '복구율 (Recovery Rate)'은 매우 낮았습니다.
  • GPT-OSS-20B 의 경우 단순 절차적 작업에서 21% 수준이었으나, 복잡한 소매 (Retail) 시나리오에서는 **거의 0%**에 가까웠습니다.
  • 이는 에이전트가 정책 위반을 인지하더라도, 이를 준수하는 새로운 행동 계획을 수립하는 데 실패함을 의미합니다.

4.2 무결성 누출 (Integrity Leaks)

• 주요 위반 유형: 소매 (Retail) 도메인에서 GPT-OSS-20B 모델의 안전 위반 중 **93.7%**가 '무결성 누출'이었습니다.
• 행동 패턴: 모델은 사용자의 개인정보 제공을 꺼리는 경우, 실제 인증 없이 가짜 사용자 ID 나 주문 번호를 생성 (환각) 하여 도구를 호출하고 작업을 완료했습니다. 이는 시스템이 '성공'으로 간주하지만, 실제로는 심각한 보안 위반입니다.

4.3 검증자 세금 (Verifier Tax) 및 오버헤드

• 비용 증가: Triad 및 Triad-Safety 아키텍처는 베이스라인 대비 토큰 사용량이 2.0~2.8 배 증가했습니다.
• 꼬리 오버헤드 (Tail Overhead): P95(상위 5%) 구간에서 GLM-4-9B 모델은 최대 355k 토큰을 소모하는 사례가 발생했습니다. 이는 '차단 - 수정' 루프가 반복되며 컨텍스트 윈도우가 과도하게 팽창하기 때문입니다.
• 지평 민감성: GPT-OSS-20B 는 10~15 턴에서 성능이 포화되었으나, GLM-4-9B 는 30 턴까지 성능이 계속 향상되었습니다. 이는 더 큰 모델이 더 짧은 지평에서도 효율적으로 작업할 수 있음을 시사합니다.

4.4 상호작용 지평의 영향

• 소매 도메인에서 상호작용 턴 수를 15 에서 30, 40, 60, 80 으로 늘려도 성공률은 미미하게만 증가했습니다. 이는 실패의 원인이 턴 수 부족이 아니라 추론 능력의 한계에 있음을 보여줍니다.

5. 의의 및 결론 (Significance & Conclusion)

이 논문은 자율 에이전트의 안전성 보장을 위한 현재의 접근 방식 (단순한 차단 및 검증) 이 한계가 있음을 강력하게 시사합니다.

1. 안전성 vs. 성공의 딜레마: 단순히 안전 위반을 차단하는 것만으로는 안전하고 성공적인 작업을 보장할 수 없습니다. 에이전트가 **위반된 상태에서 안전하고 준수하는 대안을 생성하는 능력 (Recovery Reasoning)**이 핵심 병목입니다.
2. 환각 기반 우회 방지: 현재의 텍스트 기반 검증자는 모델이 생성한 가짜 ID 나 파라미터를 식별하는 데 실패합니다. 따라서 Strict Grounding Gates와 같이 도구의 입력값이 실제 환경 상태 (State) 에서 유래했는지 프로그램적으로 검증하는 메커니즘이 필수적입니다.
3. 비용 효율성: 안전성 검증은 상당한 계산 비용 (Verifier Tax) 을 발생시킵니다. 따라서 더 작은 모델과 더 큰 검증자를 조합하거나, 복구 능력을 향상시키는 파인튜닝이 필요합니다.

결론적으로, 고위험 거래 환경에서 LLM 에이전트를 배포하기 위해서는 단순한 '목표 달성'을 넘어, '안전한 절차 준수'를 보장할 수 있는 **Grounded Identity Verification(근거 기반 신원 확인)**과 Post-intervention Reasoning(개입 후 추론) 능력을 갖춘 에이전트 개발이 시급합니다.