말과 행동의 불일치: 백엔드 상태 검증으로 보는 에이전트 무결성
법률 에이전트가 완결을 선언한 텍스트 답변과 데이터베이스에 남긴 실제 변경 상태의 정합성을 격리된 도구 세션에서 반복 검증하는 원리를 분석합니다.
초록 최근 LLM 기반 에이전트 시스템은 자연어로 유려하고 완결성 높은 답변을 생성함에도 불구하고, 실제 환경의 데이터베이스나 백엔드 원장에는 올바른 트랜잭션을 기록하지 못하거나 누락하는 '말과 행동의 괴리' 문제를 노출하고 있습니다. Microsoft와 Hugging Face가 공동 공개한 ThinkingBox 연구는 생성된 문장이 아니라 에이전트가 격리된 MCP 세션 종료 후 남긴 백엔드 종단 상태(Terminal Backend State)와 사이드이펙트를 측정해야만 진정한 신뢰성을 평가할 수 있음을 입증했습니다. 본 칼럼에서는 에이전트의 텍스트 출력과 상태 변경 트랜잭션 간의 불일치 메커니즘을 규명하고, 단일 실행의 우연적 성공을 배제하기 위한 다회차 연속 실행 신뢰도 측정 기법을 고찰합니다. 또한 법률 에이전트 아키텍처에서 조회(Read) 도구와 상태 변경(Write) 도구를 구조적으로 분리하고 격리 샌드박스에서 상태 무결성을 담보하는 시스템 설계 원리를 제시합니다. 이를 통해 언어적 환각을 넘어 시스템적 실행 환각을 제어하는 법률 AI 무결성 체계를 확립하고자 합니다.
상담 티켓 처리 에이전트가 규정을 철저히 검토하고 '고객님의 배송 지연 보상 건은 규정에 따라 보상 불가로 처리되었으며, 관련 내역을 빠짐없이 시스템에 등록하고 티켓을 정상 종료했습니다'라는 완벽한 문장의 답변을 생성했습니다. 도구 호출 로그를 살펴보면 주문 번호를 조회하고, 배송 추적을 확인하며, 환불 정책을 두 차례 검색한 기록까지 질서정연하게 남아 있습니다. 그러나 운영팀이 실제 백엔드 데이터베이스를 확인했을 때, 티켓 테이블에는 아무런 기록도 생성되지 않았거나 필수 상태 플래그가 미처리 상태로 방치되어 있는 사례가 빈번히 발생합니다. 에이전트는 언어적으로는 완벽하게 작업을 완결했다고 선언했으나, 실제 데이터베이스는 그 선언에 전혀 동의하지 않는 상황입니다. 지금까지의 생성형 AI 평가는 주로 에이전트가 내놓은 텍스트의 논리성, 문법적 완성도, 혹은 프롬프트 내 인라인 인용의 정확성에만 매몰되어 있었습니다. 하지만 외부 도구를 직접 호출하며 실세계와 상호작용하는 에이전틱 아키텍처에서 진짜 무결성은 언어가 아니라 데이터베이스에 남겨진 종단 상태(Terminal State)로 증명되어야 합니다. 오늘 칼럼에서는 문장이 아닌 시스템 사이드이펙트를 기반으로 에이전트의 실행 무결성을 검증하는 아키텍처적 원리를 분석합니다.
핵심 기술 개념
백엔드 종단 상태 (Terminal Backend State)
에이전트가 도구 호출 세션을 종료하고 완결을 선언했을 때 데이터베이스나 원장 등 시스템 저장소에 최종적으로 반영된 물리적 레코드의 상태입니다.
사이드이펙트 검증 (Side Effect Verification)
에이전트가 생성한 자연어 문장이 아니라, 도구 실행을 통해 외부 환경에 초래한 데이터 변경·생성·삭제 등의 상태 변화가 규정된 명세와 일치하는지 판정하는 평가 기법입니다.
격리된 MCP 세션 (Isolated MCP Session)
모델 컨텍스트 프로토콜(MCP) 환경에서 에이전트의 도구 호출을 독립된 샌드박스에서 실행하여, 외부 데이터 오염 없이 종단 상태의 변화만을 순수하게 추적·감사할 수 있도록 격리한 런타임 환경입니다.
기술 심층 분석
언어화된 완결 선언과 시스템 상태 간의 비대칭적 단절
LLM은 근본적으로 텍스트 토큰의 확률적 분포를 학습한 모델이기 때문에, 문맥상 가장 그럴듯한 '업무 완결 보고' 텍스트를 생성하는 것과 실제 도구를 통해 백엔드 데이터베이스를 갱신하는 트랜잭션을 엄격히 동기화하지 못합니다. 모델은 도구 호출의 반환값을 자신의 컨텍스트 윈도우에 입력받는 순간, 해당 정보를 요약하고 매끄러운 종결 어미를 붙이는 데 집중합니다. 이 과정에서 필요한 후속 도구 호출(예: 데이터베이스 Insert/Update 쿼리 실행)을 생략했음에도 불구하고, 이미 이전 단계에서 획득한 지식을 바탕으로 작업이 완료되었다고 착각하는 생성적 확증 편향이 발생합니다. 이는 텍스트 생성 파이프라인과 트랜잭션 실행 루프가 서로 다른 계층에서 작동하기 때문에 발생하는 구조적 단절입니다. 에이전트의 자기 보고형 텍스트는 내부 논리적 자기 확신에 불과하며, 실제 시스템 원장에 물리적 쓰기 작업이 일어났는지를 입증하는 증거가 될 수 없습니다. 결국 자연어 완결 선언을 신뢰성의 척도로 삼는 기존의 평가 체계는 에이전트의 심각한 시스템적 태만을 감지하지 못하는 치명적인 한계를 가집니다.
ThinkingBox가 규명한 사이드이펙트 기반 평가 메커니즘
Microsoft와 Hugging Face가 공동 발표한 ThinkingBox 연구는 이러한 문제를 정면으로 돌파하기 위해, 에이전트가 생성한 문장이 아니라 에이전트가 떠난 자리에 남겨진 기록(records they leave behind)을 평가 기준으로 삼았습니다. 이 메커니즘은 에이전트를 격리된 도구 세션(Isolated MCP tool sessions) 환경에 배치하고, 작업이 종료된 순간 백엔드 시스템의 최종 종단 상태와 발생한 모든 사이드이펙트를 추출하여 정답 스키마와 대조합니다. 예를 들어 복합 민원 처리 시나리오에서 에이전트가 규정을 올바르게 해석했더라도, 데이터베이스에 민원 티켓을 정식으로 생성하고 상태 코드를 올바른 열거형 값으로 갱신하지 않았다면 실패로 판정합니다. 즉, 텍스트 일치율이나 LLM 심사위원의 정성적 점수를 완전히 배제하고, 결정론적인 데이터베이스 쿼리와 상태 검증기를 통해 채점의 객관성을 확보합니다. 이는 에이전트 평가의 무게중심을 '무엇을 말했는가'에서 '실제로 시스템에 무엇을 남겼는가'로 전환한 패러다임의 진화이며, 법률 및 금융과 같이 데이터 정합성이 필수적인 산업군에서 요구되는 핵심 검증 규격입니다.
단일 실행의 착시를 깨는 연속 반복 신뢰도(N-in-a-row)의 수학적 필요성
에이전트가 특정 도구 호출 시나리오를 한 번 성공적으로 마쳤다고 해서 해당 워크플로우가 안전하다고 단정할 수 없습니다. 비결정론적 디코딩과 온도의 영향으로 인해 에이전트는 동일한 입력에 대해서도 도구 호출의 순서를 임의로 변경하거나 간헐적으로 필수 인자 전달을 누락할 수 있습니다. ThinkingBox가 '20회 연속으로 동일한 백엔드 종단 상태를 재현할 수 있는가'를 엄격하게 묻는 이유는 바로 이 확률적 불안정성을 통계적으로 제거하기 위함입니다. 단일 시도 성공 확률이 90%인 에이전트라 할지라도 20회 연속 성공 확률은 약 12.1%로 급감하며, 이는 실무 환경에 단독으로 배치하기에 위험한 수준임을 드러냅니다. 격리된 환경에서 초기화된 데이터베이스를 매회 새로 제공하고 동일한 과업을 반복 수행하게 함으로써, 에이전트의 상태 변경 궤적이 우연한 요행에 기인한 것인지 아니면 시스템적으로 안정화된 결정론적 수렴인지 판별할 수 있습니다. 법률 사건 처리와 같은 고위험 영역에서는 이와 같은 연속 반복 통과율이 보증되지 않는 에이전트의 도구 권한을 엄격히 제한해야 합니다.
도구 호출 계층에서의 조회(Read)와 변출(Write) 분리 격리 아키텍처
에이전트의 사이드이펙트 무결성을 통제하기 위해서는 도구의 권한 체계를 엄격히 이원화해야 합니다. 조회(Read-only) 도구는 정보의 수집만을 목적으로 하므로 텍스트 인라인 대조와 검색 정밀도 관리가 중심이 되지만, 쓰기(Write/Update) 도구는 외부 데이터베이스의 상태를 비가역적으로 변경하므로 트랜잭션 관리와 사전 검증 게이트가 필수적입니다. 에이전트가 쓰기 도구를 호출할 때는 실제 데이터베이스에 즉시 반영하지 않고, 가상 트랜잭션 샌드박스에서 사이드이펙트 시뮬레이션을 선행하도록 설계해야 합니다. 시뮬레이션 결과로 도출된 종단 레코드 상태가 사전 정의된 비즈니스 규칙과 스키마 무결성 제약조건을 완벽히 충족하는지 검증기가 확인한 후에만 커밋(Commit)을 승인합니다. 만약 에이전트가 텍스트로는 처리를 완료했다고 주장하면서도 시뮬레이션 샌드박스에 아무런 쓰기 호출을 발생시키지 않았거나 잘못된 파라미터를 넘겼다면, 런타임 인터럽트를 발생시켜 에이전트에게 상태 불일치 피드백을 전달하고 재시도를 강제해야 합니다.
기술적 트레이드오프
긴장 관계 모든 에이전트 도구 호출을 격리된 샌드박스에서 실행하고 백엔드 종단 상태를 20회 이상 반복 검증하는 것은 인프라 오버헤드와 응답 지연 시간을 급격히 증가시키는 반면, 텍스트 기반 검증에만 의존하는 방식은 응답 속도는 빠르나 데이터 불일치 위험을 방치합니다.
실무적 해소 실제 서비스 런타임에서는 정보 조회형 질의와 상태 변경형 질의를 진입 단계에서 분기하여, 상태 변경을 수반하지 않는 법령·판례 조회는 경량 인라인 검증으로 즉각 응답합니다. 반면 사건 상태 갱신이나 외부 원장 기록이 수반되는 도구 호출에 대해서만 경량 트랜잭션 격리 컨테이너를 가동하고, 런타임 사전 시뮬레이션과 사후 종단 상태 diff 검사를 결합하여 연산 비용과 무결성 사이의 최적 균형을 유지합니다.
이 주장이 틀리는 조건
반증 조건 에이전트가 격리된 도구 세션에서 작업을 종료했을 때 기록된 백엔드 종단 상태의 일치율과, 에이전트가 출력한 자연어 완료 선언문의 정확도 간에 통계적 상관계수(r)가 0.95 이상으로 나타나 텍스트 검사만으로도 백엔드 상태 오류를 99% 이상 감지할 수 있음이 관측된다면, 본 칼럼이 제시한 '사이드이펙트 기반 격리 검증 체계의 독립적 필요성'은 반증됩니다. 또한 동일 과업을 20회 반복 실행하여 측정한 백엔드 종단 상태의 표준편차가 단 1회 실행 후 텍스트 기반 사후 감사(Post-hoc Text Auditing)를 수행했을 때의 에러 검출력과 비교하여 유의미한 차이를 보이지 않는 경우에도 본 아키텍처의 당위성은 기각됩니다.
법마디 OS에 적용한다면
현재 Lawmadi OS는 60개 법률 분야별 AI 리더가 질의를 배정받아 판례와 조문 조회 도구(MCP)를 통해 국가법령정보센터(law.go.kr) API 원문과 대조하는 검증 체계를 운영하고 있습니다. 이 환경에서 판례·조문 조회는 안전한 조회(Read) 도구에 해당하지만, 향후 법마디 OS가 복합 소송 절차 관리나 기일 계산 원장 기록과 같은 상태 변경(Write) 도구를 도입할 경우 ThinkingBox의 사이드이펙트 검증 아키텍처를 핵심 감사 엔진으로 편입할 계획입니다. 구체적으로 법률 에이전트가 특정 소송 기일이나 절차적 요건을 원장에 기록하는 MCP 도구를 호출할 때, 실제 원장에 바로 반영하지 않고 격리된 세션 샌드박스에서 종단 상태 변경 사항을 시뮬레이션합니다. 시뮬레이션 결과 생성된 레코드의 필드와 상태 플래그가 실제 법정 기한 규칙 및 law.go.kr의 최신 조문 요건과 완벽히 부합하는지 결정론적 검증기로 감사한 뒤 비로소 최종 커밋을 허용하는 구조를 설계할 수 있습니다. 또한 배포 전 회귀 테스트 파이프라인에서 변호사시험 기출 답안 코퍼스 및 법률 도구 호출 시나리오를 대상으로 20회 연속 실행(N-in-a-row) 무결성 테스트를 의무화하여, 도구 호출 시퀀스의 확률적 표류를 원천 차단하는 평가 하네스를 구축하는 방안을 검토하겠습니다.
기술적 함의
- 에이전트의 신뢰성은 유려하게 출력된 자연어 문장이 아니라 시스템 백엔드에 남겨진 종단 데이터 상태로 측정되어야 합니다.
- 단일 실행의 성공은 통계적 착시일 수 있으므로, 격리된 도구 환경에서의 다회차 연속 반복 검증이 필수적입니다.
- 조회 도구와 상태 변경 도구를 엄격히 분리하고 가상 샌드박스 시뮬레이션을 거치는 다층 검증이 리걸테크 시스템의 안정성을 보장합니다.
"AI가 완결되었다고 말할 때 시스템의 데이터베이스를 확인하십시오. 진정한 기술적 무결성은 문장의 유려함이 아니라 데이터의 침묵 속에 기록된 정확한 상태 변화에서 비롯됩니다."
