에이전트에게 필요한 것은 더 나은 프롬프트가 아니라 영수증입니다

대부분의 AI 에이전트 (AI agent) 데모는 첫 번째 성공적인 실행을 최적화합니다. 하지만 실제 에이전트의 작업은 에이전트가 "완료되었습니다"라고 말한 이후부터 흥미로워집니다. 코딩 에이전트 (coding agent), 브라우저 에이전트 (browser agent), 또는 MCP 연결 워크플로우 (MCP-connected workflow)의 경우, 마지막 채팅 답변만으로는 충분하지 않습니다. 저는 영수증 (receipt)을 원합니다. 즉, 인간이 발생한 일을 신뢰하고, 디버깅 (debug)하고, 다시 재생(replay)하거나, 롤백(roll back)하고, 설명할 수 있도록 돕는 압축된 운영 기록 (operational record) 말입니다. 거대한 트랜스크립트 (transcript)나 가공되지 않은 로그 덤프 (raw log dump)가 아닙니다. 영수증이어야 합니다.

"완료"는 상태가 아닙니다

어떤 에이전트에게 결제 흐름 (billing flow)을 업데이트하라는 요청을 했다고 가정해 봅시다. 에이전트는 문서를 읽고, 4개의 파일을 수정하고, 테스트 명령어를 호출하고, 통합 테스트 하나를 건너뛰고, 환경 설정 파일 (env file)을 건드린 뒤 다음과 같이 말합니다: "완료되었습니다."

그 답변 자체만으로는 거의 쓸모가 없습니다. 운영자는 여전히 다음 사항들을 알아야 합니다:

• 에이전트는 자신이 어떤 작업을 수행하고 있다고 생각했는가?
• 어떤 파일, 도구 (tools), 시스템, 또는 데이터에 접근할 수 있었는가?
• 어떤 컨텍스트 (context)가 작업에 영향을 미쳤는가?
• 어떤 도구나 명령어를 호출했는가?
• 어떤 작업이 읽기 전용 (read-only)이었고, 어떤 것이 쓰기 (write), 파괴적 (destructive), 외부적 (external), 또는 비용 발생 (spend-affecting) 작업이었는가?
• 무엇이 변경되었는가?
• 어떤 체크가 통과되었고, 실패했거나, 건너뛰어졌는가?
• 무엇이 승인을 필요로 했는가?
• 인간이 무엇을 검토해야 하는가?
• 어떻게 재시도 (retry), 다시 재생 (replay), 재개 (resume), 또는 롤백 (roll back)할 수 있는가?

이것이 바로 영수증입니다.

에이전트 영수증에는 무엇이 포함되어야 할까요?
첫 번째 버전은 화려할 필요가 없습니다.

유용한 영수증에는 다음 내용이 포함되어야 합니다:

task (작업): 에이전트가 수행하고 있다고 믿었던 작업
scope (범위): 에이전트가 접근할 수 있도록 허용된 파일, 시스템, 도구 또는 데이터
context_used (사용된 컨텍스트): 작업에 영향을 미친 문서, 파일, 메모리, 링크 또는 이전 실행 기록
actions (동작): 도구 호출 (tool calls), 명령 (commands), API 호출, 파일 수정
action_class (동작 분류): 읽기 (read), 쓰기 (write), 파괴적 (destructive), 외부 전송 (external send), 비용 발생 (spend-affecting), 권한 변경 (permission-changing)
state_changes (상태 변경): 변경된 파일, 생성된 레코드, 전송된 메시지, 시작된 작업
checks_run (실행된 검사): 테스트, 린터 (linters), 스캔, 드라이 런 (dry runs), 평가 (evals)
checks_skipped (건너뛴 검사): 실행되지 않은 예상 검사 항목 및 그 이유
approvals (승인): 해당 동작, 범위, 만료를 승인한 주체 또는 대상, 일회성 여부 대 정책 여부
outcome (결과): 완료 (completed), 부분 완료 (partial), 차단됨 (blocked), 실패 (failed), 되돌림 (reverted), 검토 필요 (needs review)
recovery (복구): 재시도, 재개, 조사 또는 롤백 (roll back) 방법

다음은 작은 예시입니다:

{
"receipt_version" : "0.1" ,
"run_id" : "run_2026_05_23_001" ,
"agent" : {
"name" : "local-coding-agent" ,
"provider" : "Anthropic" ,
"model" : "Claude-Sonnet-4.5" ,
"runtime" : "local"
} ,
"task" : {
"summary" : "결제 재시도 핸들러를 업데이트하고 회귀 테스트 커버리지 (regression coverage)를 추가함" ,
"scope" : [
"repo:apps/billing" ,
"tool:filesystem.read" ,
"tool:filesystem.write" ,
"tool:shell.test"
] ,
"out_of_scope" : [
"production database" ,
"deployment" ,
"customer email sending"
]
} ,
"actions" : [
{
"tool" : "filesystem.write" ,
"action_class" : "write" ,
"result" : "success" ,
"decision_id" : "decision_write_002"
} ,
{
"tool" : "shell.test" ,
"action_class" : "exec" ,
"result" : "success" ,
"decision_id" : "decision_exec_004"
}
] ,
"checks" : {
"run" : [ "npm test -- billing" ] ,
"skipped" : [
{
"check" : "full integration suite" ,
"reason" : "staging 자격 증명 필요"
}
]
} ,
"outcome" : {
"status" : "completed" ,
"review_needed" : true ,
"recovery" : "수정된 파일을 되돌리거나 npm test -- billing을 다시 실행하십시오"
}
}

모델이 영수증을 소유해서는 안 됩니다.
모델은 의도 (intent)를 요약할 수 있습니다.

하지만 확실한 증거는 런타임 (runtime), 도구 계층 (tool layer), 또는 제어 평면 (control plane)에서 나와야 합니다: 명령 (commands), 종료 코드 (exit codes), 도구 호출 (tool calls), 수정된 파일 (files touched), 승인 (approvals), 정책 버전 (policy versions), 상태 변경 (state changes), 생성된 아티팩트 (artifacts created). 만약 에이전트가 스스로 자신의 감사 추적 (audit trail)을 작성한다면, 그 감사 추적은 그저 또 다른 모델 출력물일 뿐입니다. 그것은 요약으로서 유용할 수는 있지만, 증거로서 충분하지는 않습니다.

트레이스 (Traces)만으로는 충분하지 않습니다. OpenTelemetry 스타일의 트레이스는 유용합니다. 이는 지연 시간 (latency), 재시도 (retries), 오류 (errors), 그리고 서비스 경계 (service boundaries)를 설명해 줍니다. 하지만 에이전트 운영자에게는 종종 다른 객체가 필요합니다. 트레이스는 어떤 스팬 (span)이 느렸는지를 알려줍니다. 영수증 (receipt)은 에이전트가 무엇을 할 수 있도록 허용되었는지, 실제로 무엇을 했는지, 왜 허용되었는지, 무엇이 변경되었는지, 그리고 무엇을 검토해야 하는지를 알려줍니다. 트레이스는 실행 (execution)을 설명하고, 영수증은 책임 (responsibility)을 설명합니다. 당신에게는 둘 다 필요합니다.

MCP는 영수증의 중요성을 높입니다. MCP (Model Context Protocol)는 에이전트가 도구와 컨텍스트 (context)에 접근하는 공통된 방식을 제공하기 때문에 유용합니다. 또한 도구 경계 (tool boundary)를 훨씬 더 중요하게 만듭니다. 일단 에이전트가 여러 MCP 서버를 호출할 수 있게 되면, 단일 호출은 무해해 보일 수 있지만 그 시퀀스 (sequence) 전체는 그렇지 않을 수 있습니다: 서버 A에서 고객 데이터를 읽고, 서버 B를 통해 이를 처리한 뒤, 서버 C를 통해 게시하거나 전송하는 식입니다. 이것이 바로 영수증이 개별 호출뿐만 아니라, 실행 전반에 걸친 소스 (source), 싱크 (sink), 데이터 클래스 (data class), 액션 클래스 (action class), 정책 버전 (policy version), 그리고 승인 범위 (approval scope)를 포착해야 하는 이유입니다.

우리가 Armorer를 통해 나아가고자 하는 방향: 이것이 우리가 Armorer를 통해 구축하고 있는 방향입니다. Armorer는 AI 에이전트를 위한 로컬 제어 평면 (local control plane)입니다. 목표는 모든 에이전트를 불투명한 채팅창으로 취급하는 대신, 에이전트 실행 (agent runs), 도구 (tools), 승인 (approvals), 작업 (jobs), 로그 (logs), 그리고 복구 (recovery)를 당신의 로컬 머신에서 검사 가능하게 (inspectable) 만드는 것입니다. Armorer Guard는 액션 경계 (action boundary) 근처의 체크에 집중합니다: 에이전트가 무엇을 하려고 하는지, 어떤 클래스의 액션인지, 허용되어야 하는지, 차단되어야 하는지, 아니면 승인으로 라우팅되어야 하는지, 그리고 그 이후에 어떤 결정 기록 (decision record)이 존재해야 하는지를 확인합니다.

영수증 규격 (receipt spec)에 대한 GitHub 토론은 여기에서 확인할 수 있습니다: https://github.com/ArmorerLabs/Armorer/discussions/43 그리고 저장소 (repo)는 여기 있습니다: https://github.com/ArmorerLabs/Armorer 핵심적인 가설은 간단합니다. 에이전트 (agents)가 더 유능해짐에 따라, 병목 현상 (bottleneck)은 "작업을 수행할 수 있는가?"에서 "그것이 수행한 내용을 내가 이해하고, 통제하며, 복구할 수 있는가?"로 이동한다는 것입니다. 그 계층 (layer)은 아직 초기 단계에 있습니다. 하지만 저는 이것이 실질적인 에이전트 엔지니어링 (agent engineering)이 나아가고 있는 방향이라고 생각합니다.