11.10.2 실행 전(Pre-execution) 샌드박스 오라클을 이용한 도구 호출 안정성 평가

11.10.2 실행 전(Pre-execution) 샌드박스 오라클을 이용한 도구 호출 안정성 평가

11.10.1절의 Pydantic 1차 방어망을 무사히 통과하여 tool_calls의 JSON 껍데기(Schema Payload)가 타입(Type)적으로 완벽함이 수학적으로 증명되었다고 해서, 곧바로 그 무시무시한 API의 방아쇠(Execute)를 당기도록 허락하는 것은 정신을 잃은 시스템이다. 예컨대 {"target_account": "123-45", "transfer_amount": 999999999}라는 무자비한 환각 JSON 페이로드는 Integer와 String 타입을 완벽히 준수하므로 스키마 유효성 검사는 가뿐히 통과하겠지만, 이 상태로 실제 마이크로서비스 송금 API에 이 페이로드를 밀어 넣는 행위는 회사의 파산이라는 대참사를 불러온다.

따라서 데이터베이스의 상태 변경(State Mutation)을 수반하는 강력한 에이전틱 액션(Agentic Action)과 프로덕션 인프라 사이에는, 물리적 실행 조작의 방아쇠를 꺾어버리고 시뮬레이션만 수행하는 ‘실행 전(Pre-execution) 샌드박스 오라클(Sandbox Oracle)’ 계층이 두꺼운 방탄유리처럼 한 겹 더 개입해야만 한다.

1. 샌드박스 시뮬레이션(Dry-run) 오라클의 런타임 개념

이 샌드박스 오라클의 철학은 매우 차갑고 명료하다. “만약 에이전트가 쥐어준 이 파라미터 뭉치대로 지금 프로덕션 시스템을 돌린다면, 시스템 내부에서 도대체 어떤 물리적·재무적 상태 변경 파동(State Machine Mutation)이 일어날 것인가?“를, 실제 백엔드 데이터베이스에는 단 한 줄의 커밋(Commit)도 기록하지 않은 채 가상의 메모리 런타임 위에서 시뮬레이션(Simulation)으로 계산하여 그 위험도를 사전 채점(Scoring)해 내는 독립 엔진이다.

이 아키텍처는 런타임에서 보통 다음과 같은 트랜잭션 라이프사이클을 거친다.

  1. 가설 실행 (Dry-run Transaction): 챗봇 LLM이 송금 API 도구를 자신만만하게 호출하면, 백엔드 라우터(Router)는 즉시 데이터 소스를 복제된 읽기 전용(Read-only) 샌드박스로 라우팅한다. 그 위에서 실제 Transfer Account 객체의 비즈니스 로직을 동일하게 흘려보내되, 종착역에서 데이터베이스 commit() 대신 무조건 rollback()을 호출하여 가상 트랜잭션의 연산 결과를 메모리상에만 인출(Fetch)한다.
  2. 물리적 보안 룰 매칭 (Security Rule Enforcement): 오라클 룰 엔진(Rule Engine)이 방금 인출된 가상의 결과 텐서를 차갑게 평가한다. “최종 잔고가 마이너스(Negative)로 진입하는가?”, “송금 대상 계좌가 금융 감독원 블랙리스트에 등재된 해시태그와 일치하는가?”, “과거 10분간의 트랜잭션 빈도가 이상 탐지(Anomaly) 임계값을 초과하는가?” 등, LLM은 죽었다 깨어나도 혼자서 계산할 수 없는 복잡계 비즈니스의 명시적 하한선 제약 조건(Guardrails)들을 0과 1의 이진 분류로 계산해 낸다.

2. 동적 위임과 Human-in-the-loop(HITL) 다이내믹 트리거

만약 위에서 가동된 샌드박스 오라클이 해당 도구 호출 시뮬레이션 결과에 대해 RISK_LEVEL: CRITICAL이나 RULE_VIOLATION_TRUE라는 붉은색 플래그를 하나라도 반환했다면, 시스템은 즉시 무자비한 API 실행을 전면 홀드(Hold)시킨다.

에러를 뱉고 다운되는 것이 아니다. 시스템은 해당 시뮬레이션의 ’실패 사유 텍스트’를 챗봇(Agent)에게 시스템 프롬프트(Tool Message Response)로 도로 돌려보내며, 에이전트 스스로가 고객에게 자신의 모호함을 고백하고 명시적인 동의(Approval)와 2FA(2-Factor Authentication) 서명을 구하는 Human-in-the-Loop(HITL) 모드로 전환하도록 우아하게 강제(Enforce)한다.

[Agent Fallback Message]: “고객님, 말씀하신 금액으로 송금 API를 호출할 예정입니다만, 사내 보안 오라클 시스템의 사전 검증 결과 해당 금액이 오늘 설정된 1일 이체 한도(5,000만 원)를 2% 초과하는 것으로 아슬아슬하게 계산되었습니다. 강제 예외 한도를 적용하여 제 권한으로 이 결제 스크립트를 최종 실행(Execution)할까요? ARS 인증 혹은 카카오페이 서명 승인(Approval)을 통해 확인을 부탁드립니다.”

이처럼 ‘실행 전 샌드박스 오라클’ 아키텍처는 확률에 취한 언어 모델이 만들어낸 파라미터가 비즈니스 도메인의 치명적인 루비콘강(Rubicon)을 뻔뻔하게 넘나들려 할 때, 기계가 멋대로 돌이킬 수 없는 선을 넘기 바로 직전 인간 고객의 직접 승인(Approval)이라는 강력한 권한의 사슬(Chain of Responsibility)을 걸어 잡아채는 가장 현대적이고 에이전틱(Agentic)한 통제 및 면책 메커니즘이다.