← Back to Blog
AI · AX Article · 2026.08.21

에이전트의 완료는 마지막 문장이 아니라 바뀐 세계에서 판정해야 한다

도구를 쓰는 에이전트의 성공을 마지막 답변이 아니라 외부 시스템의 최종 상태, 필수 중간 사건, 금지된 부작용, 반복 성공으로 판정하는 런타임 설계를 살펴본다.

AIai-agentagent-runtimetool-useevaluation

도형의 윤곽만 있는 받침과 실제 입체 도형이 놓인 받침을 대비한 개념 이미지

AI로 생성한 개념 이미지이며, 실제 시스템의 실행 화면이 아니다.

고객이 “예약을 취소해 달라”고 요청했고 에이전트가 “취소했습니다”라고 답했다. 이 문장은 자연스럽고 자신감도 있다. 하지만 예약 데이터베이스가 그대로라면 작업은 끝나지 않았다. 반대로 취소는 됐지만 환불 계정까지 잘못 바뀌었다면, 목표를 달성했다는 사실만으로 성공이라고 할 수도 없다.

도구를 쓰는 에이전트의 출력은 문장 하나가 아니다. 대화, API 호출, 파일 쓰기, 승인, 재시도, 외부 시스템의 변화가 합쳐져 하나의 실행이 된다. 하지만 많은 평가와 운영 화면은 여전히 마지막 텍스트를 중심으로 완료를 판정한다. 답이 그럴듯한지, 사용자가 만족할 만한지, 심사 모델이 높은 점수를 주는지 확인한 뒤 성공으로 표시한다.

완료 기준은 런타임으로 옮겨야 한다. 에이전트가 무엇을 말했다가 아니라 허용된 절차를 거쳐 현실의 상태가 어떻게 달라졌는가를 읽어야 한다. 여기서는 이 기준을 상태 기반 완료 판정이라고 부른다. 표준화된 단일 제품 기능이 아니라, 도구 실행형 에이전트가 만족해야 할 관측 가능한 사후조건과 금지 조건을 설계하는 방법을 뜻한다.

같은 목표에 이르는 경로가 여러 개라면 마지막 상태를 본다

2024년 공개된 τ-bench는 도구, 에이전트, 사용자의 상호작용을 함께 평가하는 벤치마크다. 에이전트는 소매와 항공 영역의 데이터베이스를 API로 읽고 쓰며, 사용자와 여러 차례 대화하고, 영역별 정책을 따라야 한다. 연구진은 한 작업에 도달하는 대화와 읽기 호출은 다양할 수 있다는 점을 전제로, 대화가 끝난 뒤 데이터베이스 상태를 사람이 주석한 목표 상태와 비교한다.

이 설계는 정답을 하나의 실행 경로로 고정하지 않는다. 사용자는 같은 요청을 다르게 말할 수 있고, 에이전트는 필요한 정보를 여러 순서로 조회할 수 있다. 중요한 것은 허용된 범위 안에서 올바른 쓰기가 일어났는지다. τ-bench의 보상은 최종 데이터베이스가 목표 상태와 같은지, 사용자에게 필요한 정보가 전달됐는지를 함께 본다.

다만 논문은 이 규칙 기반 보상이 필요조건일 수는 있어도 충분조건은 아닐 수 있다고 지적한다. 예를 들어 사용자의 명시적 확인 없이 반품을 실행해도 데이터베이스 상태만 맞으면 통과할 수 있다. 이는 상태 기반 판정의 반례라기보다, 최종 상태뿐 아니라 허용된 상태 전이까지 계약에 넣어야 한다는 점을 보여 준다.

2025년 4월 갱신된 ToolSandbox는 이 문제를 중간 상태까지 확장한다. 이 벤치마크의 도구는 Wi-Fi, 셀룰러 연결, 위치 서비스, 저전력 모드처럼 암묵적인 의존 관계가 있는 세계 상태를 읽거나 바꾼다. 메시지를 보내려면 셀룰러 연결이 먼저 켜져야 하고, 어떤 도구는 현재 상태 때문에 실패할 수 있다. 에이전트는 오류를 관찰한 뒤 필요한 상태를 바꾸고 다시 시도해야 한다.

ToolSandbox는 하나의 고정된 호출열을 정답으로 강제하지 않는다. 대신 반드시 일어나야 하는 사건인 Milestones와 일어나서는 안 되는 사건인 Minefields를 둔다. Milestone은 시간 의존성이 있는 DAG를 이루며, 실제 실행 궤적의 대화와 세계 상태를 이 DAG에 맞춰 평가한다. 같은 목표에 이르는 호출 순서가 달라도 핵심 사건을 만족하면 인정하고, 정보가 부족한데 도구 인수를 지어내는 것처럼 금지된 사건이 발생하면 실패로 처리한다.

두 연구를 함께 읽으면 도구 에이전트의 정답은 마지막 문장이나 유일한 호출열에 머물지 않는다. 목표 상태, 필수 중간 사건, 금지된 부작용을 함께 만족하는 실행 궤적이 정답이다.

완료 판정은 프롬프트가 아니라 실행 계약이어야 한다

이 원칙을 실제 런타임에 적용하려면 작업 목표부터 판정 가능한 계약으로 바꿔야 한다. “보고서를 올려라”처럼 자연어 목표만 주면, 에이전트가 파일을 만들었는지, 승인된 위치에 올렸는지, 기존 파일을 덮어쓰지 않았는지, 공개 링크가 열리는지를 서로 다른 층에서 확인하기 어렵다.

최소한 다음 다섯 항목이 필요하다.

  1. 초기 상태와 식별자: 대상 계정, 문서, 예약, 저장소처럼 무엇을 바꿀지 고정한다. 실행마다 run_id와 대상의 안정적인 ID를 둔다.
  2. 관측 가능한 사후조건: 실행 뒤 반드시 참이어야 하는 값을 적는다. “업로드 호출 성공”이 아니라 대상 목록에 같은 파일 ID가 보이고 공개 URL이 읽히는지가 조건이 된다.
  3. 필수 사건: 승인, 원문 직접 읽기, 테스트 통과처럼 최종 상태만으로 확인할 수 없는 절차를 기록한다.
  4. 금지 사건과 쓰기 범위: 허가되지 않은 대상 변경, 중복 전송, 예상 밖 삭제, 정책 위반 호출을 실패 조건으로 둔다.
  5. 반복 성공 조건: 한 번의 성공률만 보지 않고 같은 계약을 여러 번 수행했을 때 일관되게 통과하는지 본다.

API의 200 OK나 도구의 exit 0은 완료 증거의 일부일 뿐이다. 요청을 받았음을 뜻할 수는 있어도, 비동기 처리까지 끝났음을 보장하지는 않는다. 쓰기 도구가 반환한 ID를 저장하고, 권위 있는 읽기 경로로 다시 조회하는 readback이 필요하다. 파일이라면 경로와 hash, 데이터베이스라면 행의 revision, 배포라면 대상 commit과 live route를 연결할 수 있다.

재시도도 상태 계약에 포함된다. 네트워크가 끊긴 뒤 같은 호출을 다시 보낼 때 외부 시스템이 첫 요청을 이미 처리했는지 모르면 중복 결제나 이중 게시로 이어질 수 있다. 런타임은 고유 작업 ID, 멱등 키, 처리 영수증을 사용하고, 재시도 전에 현재 상태를 읽어야 한다. checkpoint는 모델의 진행 위치를 복구하지만 외부 부작용이 한 번만 일어났다는 사실까지 보장하지 않는다.

완료 판정기는 에이전트의 자기보고를 입력으로 삼을 수는 있어도 판정 권한을 넘겨서는 안 된다. 실행 결과를 agent-reported, tool-accepted, state-observed, policy-passed, human-approved처럼 나누면 어느 층에서 아직 끝나지 않았는지 드러난다. 모든 상태를 하나의 success: true에 합치면 복구와 감사가 어려워진다.

최종 상태만 보면 놓치는 실패가 있다

상태 기반 판정은 텍스트 심사보다 결정적일 수 있지만, 현실을 완전히 읽어 내지는 못한다. 외부 시스템의 상태 일부만 관측할 수 있고, 비동기 복제나 캐시 때문에 readback이 늦을 수 있다. 올바른 결과가 자연어 품질에 달린 작업도 있다. 상담 답변의 공감, 기획서의 통찰, 협상의 적절성을 데이터베이스 값만으로 환원하기는 어렵다.

결과가 같아도 절차가 중요한 작업이 있다. 사용자의 승인 없이 예약을 취소하거나, 허용되지 않은 개인정보를 읽은 뒤 올바른 결과를 만든 실행은 실패다. 그래서 목표 상태와 함께 권한, 호출 순서, 접근 범위, 금지된 중간 사건을 봐야 한다. ToolSandbox가 Milestone과 Minefield를 함께 둔 이유도 여기에 있다.

평가 환경 자체의 편향도 남는다. τ-bench는 소매·항공의 단순화된 데이터베이스와 정책을 사용하며, 연구진이 가능한 결과를 하나로 주석한 작업을 중심으로 한다. ToolSandbox는 34개 도구와 1,032개 시나리오를 사람이 설계하고 LLM 사용자 시뮬레이터를 사용했다. 두 벤치마크는 상태 기반 평가의 유용한 메커니즘을 보여 주지만, 실제 조직의 불완전한 정책과 장기간 업무를 그대로 재현하지는 않는다.

상태 검사를 촘촘하게 만들수록 설계 비용도 커진다. 예상 사후조건, 허용된 쓰기 집합, 금지 사건, 보상 지연을 작업마다 정의해야 한다. 작은 저위험 작업에 거대한 상태 기계를 붙이면 운영 부담이 이득보다 커질 수 있다. 처음부터 모든 행동을 추적하기보다, 되돌리기 어렵거나 외부 영향을 만드는 쓰기부터 계약화하는 편이 현실적이다.

공개 AKM 계약에 연결할 때 생기는 구분

2026년 8월 21일 직접 확인한 공개 DECK6/akm의 default branch는 main이었고, HEAD는 f26ace2a16caba724b24db12cbee238ebb52498f였다. 이 커밋의 EVIDENCE-SCHEMA.md는 검색된 candidate, 원출처 위치를 읽은 direct-read, 특정 주장을 지지하는 claim-supported를 구분한다. 또 EvidencePacket이 PASS여도 downstream answer나 artifact가 아직 작성되지 않았거나 승인되지 않았을 수 있다고 명시한다.

이 공개 문서는 P0 evidence data contract이며, 에이전트 런타임의 완료 판정기가 구현돼 있다는 증거가 아니다. 다만 완료 상태를 하나로 합치지 않는다는 설계 경계는 분명하다. DEXA가 이 계약을 실행 쪽으로 확장한다면 evidence readiness와 artifact completion을 별도 축으로 두게 된다.

가령 조사 글 게시 작업은 다음과 같이 나눌 수 있다. 출처가 직접 읽혀 주장과 연결되면 evidence-ready다. 원고와 이미지가 만들어지고 정적 빌드가 통과하면 artifact-built다. 의도한 commit이 원격에 반영되고 live URL이 해당 본문과 이미지를 반환하면 published-observed다. 그 사이에 승인되지 않은 파일 변경이나 중복 게시가 없었음을 확인해야 최종 완료로 판정한다.

상태를 나누는 이유는 어느 단계까지 끝났고 어디서 재개할지를 정하기 위해서다. evidence가 준비됐지만 글이 없으면 작성 단계로 돌아가고, commit은 올라갔지만 live route가 이전 본문이면 배포 관찰을 계속한다. 마지막 문장이 “완료했습니다”여도 사후조건이 맞지 않으면 런타임은 완료를 선언하지 않는다.

반증 가능한 조건이 설계의 출발점이다

도구 에이전트의 품질을 높일 때 더 좋은 마지막 답변을 만드는 데만 집중하기 쉽다. 하지만 실제 자동화에서 중요한 질문은 따로 있다. 무엇이 바뀌어야 하는가, 무엇은 바뀌면 안 되는가, 어떤 사건은 반드시 지나야 하는가, 같은 작업을 다시 해도 일관되게 성공하는가다.

실무에서는 외부 쓰기가 발생하는 작업 하나를 골라 작은 완료 계약부터 만들 수 있다. 초기 상태 snapshot을 남기고, 예상 write-set과 no-write-set을 정의하며, 도구 응답의 ID를 권위 있는 readback과 연결한다. 승인이나 정책 검사는 필수 사건으로, 허가되지 않은 호출은 minefield로 둔다. 마지막에는 한 번의 성공 여부와 반복 실행의 일관성을 따로 기록한다.

그렇다고 에이전트의 말이 불필요해지는 것은 아니다. 마지막 답변은 사용자에게 결과를 설명하는 인터페이스로 남는다. 다만 완료 판정은 그 아래에서 관측한 상태와 실행 사건을 근거로 삼는다. 런타임을 끝내는 기준은 유창한 종료 문구가 아니라 반증 가능한 사후조건이어야 한다.

직접 읽은 자료