에이전트는 더 나은 프롬프트뿐 아니라 영수증이 필요하다
출처: Dev.to
대부분의 AI 에이전트 데모는 첫 번째 성공적인 실행에만 초점을 맞춥니다.
실제 에이전트 작업이 흥미로워지는 순간은 에이전트가 “완료”라고 말했을 때입니다.
코딩 에이전트, 브라우저 에이전트, 혹은 MCP‑연결 워크플로우의 경우, 최종 채팅 답변만으로는 충분하지 않습니다. 나는 영수증이 필요합니다: 인간이 신뢰하고, 디버깅하고, 재실행하고, 롤백하거나, 무슨 일이 일어났는지 설명할 수 있게 해 주는 간결한 운영 기록.
거대한 전사본도, 원시 로그 덤프도 아닙니다. 바로 영수증입니다.
예를 들어, 에이전트에게 청구 흐름을 업데이트하라고 요청했다고 가정해 보세요.
에이전트는 문서를 읽고, 네 파일을 수정하고, 테스트 명령을 실행하고, 하나의 통합 테스트를 건너뛰고, 환경 파일을 건드린 뒤에 이렇게 말합니다:
Done.
그 답변만으로는 거의 쓸모가 없습니다. 운영자는 여전히 다음을 알아야 합니다:
- 에이전트가 수행하고 있다고 생각한 작업은 무엇인가?
- 어떤 파일, 도구, 시스템, 데이터에 접근할 수 있었는가?
- 어떤 컨텍스트가 작업에 영향을 주었는가?
- 어떤 도구나 명령을 호출했는가?
- 읽기 전용 작업과 쓰기, 파괴적, 외부, 비용에 영향을 주는 작업은 어느 것이었는가?
- 무엇이 바뀌었는가?
- 어떤 검증이 통과했으며, 실패했으며, 건너뛰었는가?
- 어떤 승인이 필요했는가?
- 인간이 검토해야 할 사항은 무엇인가?
- 어떻게 재시도, 재실행, 재개 또는 롤백할 수 있는가?
그것이 바로 영수증입니다.
첫 번째 버전은 화려할 필요가 없습니다.
유용한 영수증에는 다음과 같은 내용이 포함되어야 합니다:
- task: 에이전트가 수행하고 있다고 믿은 작업
- scope: 접근이 허용된 파일, 시스템, 도구, 데이터
- context_used: 작업에 영향을 준 문서, 파일, 메모리, 링크, 이전 실행 등
- actions: 도구 호출, 명령, API 호출, 파일 편집 등
- action_class: 읽기, 쓰기, 파괴적, 외부 전송, 비용에 영향, 권한 변경 등
- state_changes: 변경된 파일, 생성된 레코드, 전송된 메시지, 시작된 작업 등
- checks_run: 테스트, 린터, 스캔, 드라이런, 평가 등
- checks_skipped: 실행되지 않은 예상 검증과 그 이유
- approvals: 누가, 무엇이, 어떤 범위, 만료 시점, 일회성 vs 정책 등
- outcome: 완료, 부분 완료, 차단, 실패, 되돌림, 검토 필요 등
- recovery: 재시도, 재개, 검사, 롤백 방법
아래는 작은 예시입니다:
{
"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": "Update the billing retry handler and add 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": "requires staging credentials"
}
]
},
"outcome": {
"status": "completed",
"review_needed": true,
"recovery": "Revert the modified files or rerun npm test -- billing"
}
}모델은 의도를 요약할 수 있습니다.
하지만 확실한 증거는 런타임, 도구 레이어, 혹은 제어 평면에서 나와야 합니다:
- 명령어
- 종료 코드
- 도구 호출
- 수정된 파일
- 승인 기록
- 정책 버전
- 상태 변화
- 생성된 아티팩트
에이전트가 자체 감사 로그를 작성한다면, 그 로그는 또 다른 모델 출력에 불과합니다.
요약으로는 유용하지만 증거로는 부족합니다.
OpenTelemetry 스타일의 트레이스는 유용합니다. 지연 시간, 재시도, 오류, 서비스 경계를 설명해 주죠.
하지만 에이전트 운영자는 종종 다른 형태의 객체가 필요합니다.
- 트레이스는 어느 스팬이 느렸는지를 알려줍니다.
- 영수증은 에이전트가 어떤 권한으로 무엇을 실제로 했는지, 왜 허용됐는지, 무엇이 바뀌었는지, 무엇을 검토해야 하는지를 알려줍니다.
트레이스는 실행을 설명하고, 영수증은 책임을 설명합니다. 두 가지가 모두 필요합니다.
MCP는 에이전트가 도구와 컨텍스트에 접근하는 공통 방식을 제공하기 때문에 유용합니다. 동시에 도구 경계가 훨씬 더 중요해집니다.
에이전트가 여러 MCP 서버에 호출할 수 있게 되면, 단일 호출은 무해해 보이지만 전체 흐름은 그렇지 않을 수 있습니다:
- 서버 A에서 고객 데이터를 읽는다.
- 서버 B에서 데이터를 처리한다.
- 서버 C를 통해 데이터를 퍼블리시하거나 전송한다.
따라서 영수증은 개별 호출뿐 아니라 실행 전체에 걸친 source, sink, data class, action class, policy version, approval scope까지 캡처해야 합니다.
이것이 우리가 Armorer와 함께 구축하고 있는 방향입니다.
Armorer는 AI 에이전트를 위한 로컬 제어 평면입니다. 목표는 에이전트 실행, 도구, 승인, 작업, 로그, 복구 과정을 여러분의 머신에서 직접 검사 가능하게 만들고, 모든 에이전트를 불투명한 채팅 창으로 취급하지 않는 것입니다.
Armorer Guard는 행동 경계 근처의 검증에 초점을 맞춥니다: 에이전트가 무엇을 하려는가, 어떤 종류의 행동인가, 허용되어야 하는가, 차단되어야 하는가, 혹은 승인이 필요한가, 그리고 이후에 어떤 결정 레코드가 존재해야 하는가?
영수증 사양에 대한 GitHub 토론은 여기에서 확인할 수 있습니다:
https://github.com/ArmorerLabs/Armorer/discussions/43
레포지토리는 여기입니다:
https://github.com/ArmorerLabs/Armorer
베팅은 간단합니다:
에이전트가 점점 더 능숙해짐에 따라, 병목 현상은 “작업을 수행할 수 있는가?”에서 “그 결과를 이해하고, 관리하고, 복구할 수 있는가?”로 이동합니다.
그 단계는 아직 초기 단계이지만, 실용적인 에이전트 엔지니어링이 나아갈 방향이라고 생각합니다.