AI 에이전트에게 영수증이 필요한 이유

에이전트가 주문을 취소했다. 고객에게는 환불 안내도 나갔다. 겉으로는 일이 끝났다.

그런데 하루 뒤 고객이 묻는다. “왜 제 주문이 취소됐나요?” 운영팀도 묻는다. “누가 승인했나요?” 재무팀은 더 단순한 질문을 한다. “얼마가, 어느 계좌에서, 어떤 정책에 따라 움직였나요?”

이때 “모델이 그렇게 판단했습니다”는 답이 아니다.

사람이 결제한 뒤에는 영수증이 남는다. 가게, 시간, 품목, 금액, 결제 수단이 있다. 영수증은 그 거래가 좋았다는 증명도, 가게가 항상 옳다는 보증도 아니다. 다만 어떤 일이 실제로 일어났고, 나중에 무엇을 확인할 수 있는지 알려 준다.

AI 에이전트에게도 비슷한 것이 필요하다. 나는 그것을 실행 영수증이라고 부르고 싶다. 단순한 시스템 로그도 아니고, 모델의 생각을 전부 저장한 기록도 아니다. 어떤 과업에서, 어떤 근거와 권한으로, 무엇을 바꾸었는지 나중에 복원할 수 있게 하는 최소 기록이다.

로그는 많은데, 설명은 없는 상태

에이전트를 붙이면 로그는 빠르게 늘어난다. 프롬프트, 토큰, API 응답 시간, 도구 호출, 오류 코드, 재시도 횟수. 대부분 필요하다. 하지만 사건이 생겼을 때 이 조각들을 연결하지 못하면 로그는 전자레인지 설명서처럼 길고, 정작 필요한 질문에는 답하지 못한다.

예를 들어 환불 API가 세 번 호출되었다는 로그만 있어서는 부족하다. 첫 호출은 어떤 주문을 대상으로 했는가. 두 번째 호출은 왜 재시도했는가. 이미 환불된 상태라는 응답을 봤는가. 마지막 호출 전에 사람이 승인했는가. 정책 문서의 어느 버전을 근거로 삼았는가. 되돌릴 수 없는 변경이었다면 중단할 기회가 있었는가.

이 질문들은 모델의 내면을 캐내자는 요구가 아니다. 행동의 외부 조건을 확인하자는 요구다.

영수증은 로그를 대체하지 않는다. 로그 위에 얇은 연결층을 하나 더 놓는다. 그래서 좋은 실행 영수증은 거대한 데이터 모델보다 먼저, “이 행동은 무엇을 바꾸었는가”라는 질문에서 시작한다.

정답이 있어도 거래가 설명되지는 않는다

에이전트 평가가 어려운 이유도 여기서 나온다. 우리는 최종 답변이나 테스트 통과 여부를 보기 쉽다. 코드가 테스트를 통과했는지, 예약이 완료됐는지, 고객에게 답변이 전송됐는지. 그러나 에이전트는 답변을 만들기 전에 환경을 읽고, 도구를 고르고, 여러 상태를 거쳐, 때로는 외부 시스템을 바꾼다.

WebArena는 전자상거래·포럼·협업 개발·콘텐츠 관리 환경을 재현해 웹 에이전트를 시험했다.[1] 초기 결과에서 당시 최선의 GPT-4 기반 에이전트가 종단 간 과업 성공률 14.41%에 머물렀고, 사람은 78.24%를 보였다.[1] 이 숫자를 오늘의 모델 성적으로 읽을 이유는 없다. 시간이 지나면 모델과 하네스가 바뀐다. 더 중요한 것은 웹에서 장기 과업을 끝내는 일이, 좋은 답 한 번을 만드는 일과 다른 종류의 문제라는 사실이다.

SWE-bench도 같은 장면을 보여 준다. 실제 GitHub 이슈와 PR에서 가져온 문제를 코드베이스와 실행 환경 안에서 해결하게 한다.[2] 여기서 패치가 통과했다는 판정은 중요하다. 하지만 실무자는 그 뒤에 또 묻게 된다. 어떤 파일을 바꾸었는가. 금지된 영역을 건드리지 않았는가. 테스트가 없던 부작용은 없는가. 사람이 검토해야 할 변경을 건너뛰지 않았는가.

완료는 결과다. 영수증은 경로다.

이 차이를 섞으면 문제가 생긴다. 성공한 실행이 안전한 실행처럼 보이고, 실패한 실행이 모두 모델의 부족처럼 보인다. 실제로는 환경이 깨졌을 수 있고, 도구의 반환값을 잘못 읽었을 수 있고, 과업 자체의 성공 기준이 모호했을 수 있다. 실행 영수증은 이때 책임을 자동으로 판결하지 않는다. 다만 어느 질문을 먼저 확인해야 하는지 보여 준다.

영수증에는 무엇이 들어가야 하나

모든 행동을 비디오처럼 녹화할 필요는 없다. 개인정보, 보안, 저장 비용 때문에라도 그 방식은 좋지 않다. 반대로 최종 결과만 남기는 것은 너무 얇다. 그 사이에 최소 단위가 있다.

과업: 무엇을 하도록 요청받았는가
제약: 무엇을 해서는 안 되는가, 언제 사람을 불러야 하는가
환경: 어떤 정책·권한·초기 상태에서 실행했는가
근거: 어떤 문서·조회 결과·확인된 사실을 사용했는가
행동: 어떤 도구로 무엇을 읽고 바꾸었는가
결과: 무엇이 바뀌었고, 검증과 부작용은 무엇이었는가

이 여섯 줄은 길어 보이지만 실제로는 도구 호출과 상태 변경에 이미 흩어져 있는 정보다. 영수증의 일은 정보를 새로 발명하는 것이 아니라, 서로 떨어진 증거를 하나의 실행 ID 아래로 묶는 것이다.

여기서 특히 중요한 것은 근거와 권한이다. 검색 결과를 봤다는 사실만으로 고객 정보를 삭제해도 되는 것은 아니다. 정책 문서를 찾았다는 사실만으로 예외 조항이 적용되는 것도 아니다. 과업의 목적, 문서의 버전, 현재 상태, 권한 범위가 함께 맞아야 한다.

그래서 “도구를 잘 쓴다”는 말도 조금 더 구체적이어야 한다. 알맞은 API를 호출했다는 뜻만은 아니다. 그 API를 이 상태에서 이 범위로 호출해도 됐는지, 반환값의 경고를 다음 행동에 반영했는지까지 포함한다.

도구 호출은 클릭 한 번보다 무겁다

사람이 웹사이트에서 버튼을 누르면 대개 화면에 취소·확인·경고가 보인다. 에이전트의 도구 호출은 이 중간 단계를 압축한다. 빠른 대신, 확인의 맥락도 함께 사라지기 쉽다.

ToolEmu는 고위험 도구 사용에서 생길 수 있는 행동과 실패를 실제 외부 시스템 대신 언어 모델로 모사한 sandbox 안에서 살폈다.[3] 이 연구가 모든 도구 환경을 대표하지는 않는다. 그래도 한 가지는 분명히 보여 준다. 도구 평가는 “이 API 이름을 골랐는가”보다 넓어야 한다. 호출의 순서, 인자, 관찰한 반환값, 잠재 부작용이 모두 결과를 바꾼다.

실행 영수증은 이때 도구 호출을 네 가지 질문으로 번역한다. 다른 도구가 아니라 이 도구를 고른 이유가 있었는가. 입력 범위는 과업의 범위를 넘지 않았는가. 반환된 경고나 빈 결과를 읽었는가. 다음 행동 전에 중단·승인·되돌림의 기회가 있었는가.

이 질문은 작은 차이처럼 보인다. 하지만 한 번이라도 외부 상태를 바꾸는 에이전트를 운영해 보면 곧 무게가 달라진다. 검색 실패는 다시 검색하면 될 수 있다. 잘못 발급된 쿠폰, 삭제된 레코드, 잘못 전송된 이메일은 그 다음 단계가 필요하다. 그래서 영수증은 사고가 난 뒤에만 쓰는 사후 문서가 아니라, 위험한 행동 앞에 “무엇을 남길 것인가”를 정하는 설계다.

‘생각의 전문’이 아니라 행동의 증거

여기서 흔히 나오는 오해가 있다. 에이전트를 설명하려면 모든 추론 과정을 저장해야 한다는 생각이다. 나는 그쪽으로 가지 않는 편이 낫다고 본다. 내부 추론 텍스트는 민감한 정보를 포함할 수 있고, 길다고 해서 더 정확한 설명이 되는 것도 아니다. 사람이 나중에 읽을 수 있다는 사실과, 그 기록이 행동의 원인을 증명한다는 사실은 다르다.

대신 필요한 것은 관찰 가능한 행동의 증거다. 어떤 근거 ID를 참고했는가. 어떤 도구를 어떤 스키마로 불렀는가. 반환 상태는 무엇이었는가. 어떤 정책 때문에 권한이 제한됐는가. 누가 승인하거나 중단시켰는가. 바뀐 레코드는 무엇이며 되돌릴 수 있는가.

AgentDiagnose는 종단 성공 여부만으로 가려지는 실행 궤적을 분석하고, 탐색·과업 분해·관찰 읽기·자기 검증 같은 능력을 따로 살핀다.[4] 이 관점은 실행 영수증과 잘 닿는다. 영수증이 판단을 대신하기보다, 실행이 어디에서 갈라졌는지 볼 수 있게 하기 때문이다.

물론 이 기록이 곧 인과 증명은 아니다. “빈 검색 결과 뒤에 잘못된 API 호출이 있었다”는 사실은 알 수 있다. 검색 서비스의 장애가 원인이었는지, 에이전트가 빈 결과를 잘못 해석한 것이 원인이었는지는 재실행과 비교가 필요하다. 영수증은 판결문이 아니라 조사 기록이다.

테스트는 비교를 위해, 영수증은 발견을 위해

그렇다면 실행 영수증만 남기면 평가도 충분할까. 그렇지 않다. 반복해서 비교하려면 고정된 환경과 테스트가 필요하다. 프롬프트를 바꿨을 때, 도구 설명을 고쳤을 때, 모델을 바꿨을 때 무엇이 달라졌는지 보려면 같은 조건에서 다시 실행해야 한다. AgentBench처럼 여러 환경을 놓는 이유도 그것이다.[5]

하지만 고정된 평가는 아직 일어나지 않은 실패를 모른다. OpenAI는 장기 실행 모델의 내부 사용을 모니터링하며, 기존 배포 전 평가에서 보이지 않았던 원치 않는 행동을 발견한 뒤 평가와 통제를 추가했다고 설명한다.[6] 이는 모든 것을 감시하면 된다는 뜻이 아니다. 평가 세트가 현실보다 먼저 완전해질 수 없다는 뜻이다.

그래서 테스트와 영수증은 다른 역할을 맡는다. 테스트는 변경 전후를 공정하게 비교한다. 영수증은 실제 사용에서 처음 보는 문제를 발견하고, 그 문제를 다음 테스트로 옮길 재료를 만든다.

실행 영수증에서 낯선 실패를 발견한다
→ 민감정보와 부작용을 제거한 재현 과업으로 만든다
→ 고정 테스트에 넣어 변경 전후를 비교한다
→ 다시 운영에서 그 변경의 부작용을 관찰한다

이 순환이 없으면, 운영은 그저 사건을 쌓는 장소가 되고 평가는 그저 점수를 쌓는 장소가 된다. 둘이 만나야 기록이 학습 가능한 경험으로 바뀐다.

결국, 에이전트가 남겨야 하는 것은 답변만이 아니다

AI 에이전트가 더 많은 일을 할수록 우리는 더 자주 “무엇을 할 수 있는가”를 묻게 된다. 그러나 외부 시스템을 읽고 바꾸는 순간부터 다른 질문도 함께 따라온다. 그 행동은 어떤 근거에서 나왔는가. 누가 그 범위를 허용했는가. 문제가 생기면 어디까지 되짚을 수 있는가.

영수증은 에이전트를 믿으라고 요구하는 장치가 아니다. 오히려 믿음이 필요 없는 부분을 줄이는 장치다. 최종 결과가 그럴듯하다는 인상 대신, 과업·근거·권한·행동·결과를 나누어 확인하게 한다.

에이전트가 일을 대신하는 시대에 부족한 것은 로그가 아닐지 모른다. 일이 실제로 어떻게 처리됐는지, 사람이 다시 묻고 확인할 수 있는 형태로 남기는 방식일 것이다.

영수증을 잘 남기기 시작하면 설계의 우선순위도 바뀐다. 처음부터 모든 도구와 모든 판단을 설명하려 하기보다, 되돌릴 수 없는 행동부터 고른다. 결제, 데이터 삭제, 외부 발송, 권한 변경처럼 한 번 일어나면 비용이 생기는 지점이다. 그 지점에는 과업 ID, 사용한 정책 버전, 승인 여부, 변경 전후 상태를 연결한다. 조회나 초안 생성처럼 되돌릴 수 있는 행동에는 더 가벼운 기록을 남긴다. 기록의 밀도도 위험을 따라 달라져야 한다.

그리고 영수증은 사람만을 위한 장부가 아니다. 다음 실행의 에이전트도 이전 실행이 어떤 조건에서 성공했고 어디서 멈췄는지 읽을 수 있다. 그때 기록은 단순한 사후 감사 자료가 아니라, 같은 실수를 반복하지 않게 하는 작업의 문맥이 된다. 다만 그 효과는 실행 기록을 과거의 답으로 바로 복사하지 않을 때에만 생긴다. 과거 행동의 근거와 당시의 조건을 함께 읽을 수 있어야 하기 때문이다.

결국 영수증은 자동화를 늦추기 위한 서류가 아니다. 더 많은 자동화가 실제 일을 대신할수록, 그 자동화가 어디까지 책임지는지 선명하게 만드는 장치다. 누군가 다시 묻는 순간에만 등장하는 기록이 아니라, 시스템이 스스로 멈추고 사람에게 넘길 근거를 미리 만들어 두는 구조에 가깝다.

[5]: AgentBench: Evaluating LLMs as Agents

[1]: WebArena: A Realistic Web Environment for Building Autonomous Agents

[2]: SWE-bench: Can Language Models Resolve Real-World GitHub Issues?

[3]: ToolEmu: Identifying the Risks of LM Agents with an LM-Emulated Sandbox

[4]: AgentDiagnose: An Open Toolkit for Diagnosing LLM Agent Trajectories

[6]: Safety alignment for long-horizon AI models