이때 필요한 것이 execution receipt입니다. receipt는 단순 로그 이벤트가 아니라, 작업 단위 액션을 설명 가능한 객체로 묶는 기록입니다. 저는 이를 Execution Receipt 트렌드 글의 실무판이라고 보는 편이 맞다고 생각합니다. Action Lineage Graph가 전체 실행 연결을 보여주고, Capability Lease가 현재 권한 범위를 제한한다면, execution receipt는 이번 액션 하나가 어떤 계약 아래 실행됐고 어떤 증거를 남겼는지를 닫아 주는 마지막 고리입니다.

이 글에서 얻는 것

• execution receipt를 어떤 액션부터 붙여야 투자 대비 효과가 큰지 우선순위를 정할 수 있습니다.
• approval, lease, evidence, replay guard를 한 레코드에 어떻게 묶어야 운영 설명 가능성이 올라가는지 이해할 수 있습니다.
• coverage, unverifiable action rate, approval-to-receipt latency 같은 지표를 어떤 초기 목표값으로 운영할지 바로 가져갈 수 있습니다.

핵심 개념/이슈

1) receipt는 감사 로그가 아니라 실행 계약의 결과 레코드다

실무에서 receipt를 잘못 도입하면 “로그를 더 많이 저장하는 프로젝트"로 끝나기 쉽습니다. 하지만 receipt의 핵심은 보존량이 아닙니다. 액션 하나를 intent, approval, capability, evidence, effect와 함께 설명 가능한 상태로 묶는 것이 본질입니다.

예를 들어 에이전트가 운영 채널에 공지 메시지를 보냈다면 최소한 아래 질문에 답할 수 있어야 합니다.

• 이 메시지는 누가 요청했는가
• 사람이 승인했다면 어떤 승인 레퍼런스와 연결되는가
• 당시 허용된 capability lease는 무엇이었는가
• 실제 발송 대상과 message id는 무엇인가
• 동일 intent가 재시도로 두 번 발송된 것은 아닌가

즉 receipt는 “이벤트가 있었다"를 넘어서 행동의 정당성과 결과를 한 번에 설명하는 최소 단위여야 합니다.

2) 최소 필드는 작아도 되지만 approval, lease, actual effect는 반드시 같이 있어야 한다

처음부터 거대한 스키마를 만들 필요는 없습니다. 다만 아래 필드는 거의 빠지면 안 됩니다.

• receipt_id
• intent_id 또는 task_id
• subject_id 또는 session_id
• approval_ref
• capability_lease_ref
• tool_action
• resource_scope
• expected_effect
• actual_effect
• evidence_refs
• outcome
• started_at, completed_at
• replay_guard_key

여기서 특히 중요한 것은 expected_effect와 actual_effect를 분리하는 것입니다. 승인 당시 기대 효과는 “문서 2개 수정"인데 실제 효과가 “문서 2개 수정 + 설정 파일 변경"이라면, receipt가 있어야 범위 초과를 바로 탐지할 수 있습니다. approval과 lease를 따로 저장하는 것만으로는 부족한 이유가 여기에 있습니다. 승인 근거와 실제 결과가 한 곳에서 비교돼야 자동 판정이 가능해집니다.

3) 우선순위는 고위험 쓰기 액션부터 붙이는 편이 가장 안전하다

receipt를 모든 액션에 한꺼번에 붙이려 하면 오래 걸리고, 운영팀 피로만 늘어납니다. 초반 우선순위는 아래처럼 잡는 편이 좋습니다.

1. 외부 전송, 운영 명령, 권한 변경
2. 코드/문서 수정
3. 배치 트리거, 설정 변경, 데이터 쓰기
4. 읽기 전용 조사 액션

이 순서가 좋은 이유는 복구 난이도와 설명 책임이 정확히 이 순서로 커지기 때문입니다. 외부 전송은 취소가 어렵고, 운영 명령은 영향 범위가 넓고, 코드 변경은 diff와 테스트 증거를 붙이기 쉬워서 빠르게 효과를 볼 수 있습니다. 반면 읽기 전용 액션은 나중에 coverage를 넓힐 때 포함해도 됩니다.

4) replay guard가 없으면 receipt는 예쁘지만 운영 사고는 계속 난다

많은 팀이 receipt 스키마는 만들지만 재시도 중복을 막는 키를 빼먹습니다. 그러면 감사 설명은 그럴듯해도 운영 사고는 계속 납니다. timeout이나 worker 재시작 뒤 같은 intent가 다시 실행되면, receipt는 두 장 생기고 실제 효과도 두 번 발생할 수 있기 때문입니다.

그래서 replay_guard_key 또는 duplicate suppression key를 필수 필드로 두는 편이 좋습니다. 보통 아래 조합이면 출발점으로 충분합니다.

• 외부 전송: intent_id + destination + template_version
• 코드 수정: task_id + repo + branch + scope
• 운영 명령: intent_id + service + action + target_env

중요한 것은 키가 완벽히 보편적일 필요는 없다는 점입니다. 먼저 같은 효과를 두 번 내면 안 되는 액션에만 붙여도 사고율이 크게 떨어집니다.

5) 좋은 receipt 파이프라인은 draft와 finalize를 분리한다

실행 직전에 receipt draft를 만들고, 실행 후 evidence를 수집해 finalize하는 구조가 가장 단순합니다.

1. intent 생성
2. approval 연결
3. capability lease 발급 또는 참조
4. tool action 직전 receipt draft 생성
5. 실행 결과와 evidence 수집
6. actual effect 계산
7. receipt finalize 및 경보 평가

이 구조의 장점은 실패도 같은 형태로 남길 수 있다는 점입니다. denied, expired, partial success도 모두 receipt로 저장하면 운영 데이터 왜곡이 줄어듭니다. 성공만 남기면 coverage는 높아 보여도 실제 설명 가능성은 낮습니다.

실무 적용

1) 권장 초기 목표값

처음 운영할 때는 아래 숫자가 무난한 출발점입니다.

• 외부 전송, 운영 변경, 권한 변경: receipt coverage 100%
• 코드/문서 수정: receipt coverage 95% 이상
• unverifiable_action_rate: 0.1% 미만
• approval_to_receipt_p95: 60초 미만
• evidence_completeness_ratio: 95% 이상
• duplicate_execution_rate: 0.5% 미만

이 숫자의 핵심은 완벽한 자동화가 아닙니다. 설명 불가능한 실행을 먼저 줄이는 것이 목표입니다.

2) 팀 역할 분리 기준

• 플랫폼 팀: receipt 스키마, 저장소, policy evaluator, replay guard 제공
• 제품/도메인 팀: expected effect 정의, 고위험 액션 분류, evidence 최소 세트 정의
• 운영자/리뷰어: partial success 분류, 롤백 승인, 예외 정책 검토

이 분리가 없으면 플랫폼은 과도하게 추상적인 필드만 만들고, 도메인 팀은 사람이 읽어도 의미 없는 outcome만 남기게 됩니다.

3) 실제 점검 체크리스트

• 외부 전송 액션은 모두 approval_ref와 message id를 같이 남긴다.
• 코드 수정 액션은 diff hash 또는 commit ref를 evidence로 남긴다.
• lease 만료 후 발생한 actual effect는 무조건 실패 receipt와 경보로 승격한다.
• replay guard hit는 success가 아니라 duplicate-skipped 같은 별도 outcome으로 구분한다.
• expected effect와 actual effect 차이가 있으면 사람이 보게 되는 review queue로 보낸다.

트레이드오프/주의점

첫째, evidence를 너무 자세히 저장하면 비밀값이나 개인정보가 섞일 수 있습니다. 원문보다 hash, pointer, redaction을 기본값으로 두는 편이 안전합니다.

둘째, 모든 것을 동기식으로 finalize하면 쓰기 경로가 느려집니다. 핵심 필드만 동기 반영하고, 세부 evidence 보강은 짧은 비동기 후처리로 넘기는 편이 좋습니다.

셋째, 스키마를 너무 일반화하면 사람이 읽어도 의미가 없습니다. did something 같은 outcome은 저장 비용만 늘리고 운영 판단에는 거의 도움이 되지 않습니다.

관련 글

• Execution Receipt 트렌드 글
• Action Lineage Graph
• Capability Lease
• Test Evidence Pipeline

개발 초기에는 넓은 allowlist와 긴 세션이 편합니다. 그런데 에이전트가 여러 도구를 넘나들고, 사람 승인과 배치 작업이 섞이고, 세션이 하루 이상 이어지기 시작하면 정적 역할만으로는 설명이 안 됩니다. 오전에 승인된 쓰기 권한이 밤까지 살아 있고, 원래 문서 수정용이던 세션이 나중에는 배포 관련 액션까지 시도하는 식입니다. 사고는 대개 여기서 납니다.

그래서 최근 팀들이 보는 방향은 “역할을 더 촘촘히 쪼개자"가 아니라 작업 단위 capability lease를 발급하고 자동 만료시키자에 가깝습니다. 저는 이 흐름이 Tool Permission Manifest + Runtime Attestation의 다음 단계라고 생각합니다. manifest가 “무엇이 원칙적으로 가능한가"를 정한다면, capability lease는 이번 작업에서 지금 당장 무엇이 허용되는가를 제한합니다.

이 글에서 얻는 것

• 정적 역할 기반 권한이 장시간 에이전트 운영에서 왜 과권한으로 변하는지 이해할 수 있습니다.
• capability lease를 어떤 필드와 어떤 만료 규칙으로 설계해야 실효성이 있는지 기준을 잡을 수 있습니다.
• 승인, 세션 보안, 실행 추적을 capability lease와 어떻게 연결해야 하는지 운영 숫자 중심으로 정리할 수 있습니다.

핵심 개념/이슈

1) 정적 역할은 짧은 스크립트에는 맞아도 긴 작업 흐름에는 너무 넓다

전통적인 RBAC는 사람 계정과 서비스 계정에는 잘 맞습니다. 하지만 에이전트 실행은 보통 더 유동적입니다.

• 하나의 요청 안에서 read-only 조사와 write action이 섞입니다.
• 승인 전과 승인 후의 허용 범위가 달라집니다.
• 같은 세션이라도 오전 작업과 오후 작업의 목적이 달라집니다.
• 멀티에이전트 환경에서는 보조 실행자마다 필요한 권한이 다릅니다.

이때 editor, deployer, ops-bot 같은 정적 역할은 너무 넓거나 너무 자주 바뀝니다. 결국 실무 문제는 권한 정의 부족보다 권한 수명(lifetime)과 작업 문맥(context)이 분리돼 있다는 점입니다. 이 문제는 Harness Engineering에서 말한 실행 프레임 고정, Approval-Driven Auto-Remediation에서 말한 승인 경계와 바로 연결됩니다.

2) capability lease는 “권한 목록"이 아니라 “만료되는 작업 토큰"에 가깝다

capability lease의 핵심은 단순 allowlist가 아닙니다. 최소한 아래 정보가 같이 있어야 의미가 있습니다.

• subject: 어떤 에이전트/세션/하위 실행자가 쓰는가
• task_id: 어떤 요청 또는 티켓에 묶인 권한인가
• allowed_actions: 허용 툴과 액션 범위
• resource_scope: 경로, 저장소, 서비스, 환경 범위
• expiry: 몇 분 후 자동 만료되는가
• approval_ref: 어떤 승인 또는 정책 판정과 연결되는가
• max_effect: 허용 가능한 변경량, 예를 들어 파일 20개 이하, 외부 전송 0회
• revoke_hook: 사람이 중간에 즉시 회수할 수 있는가

즉 lease는 “이 세션은 deployer 역할이다"보다 훨씬 좁습니다. 오히려 “이 세션은 30분 동안 특정 저장소의 docs 디렉터리만 수정 가능"처럼 행동 범위와 시간 범위를 동시에 묶는 계약에 가깝습니다.

3) 왜 지금 이 모델이 중요해졌나: 멀티에이전트와 장시간 세션이 늘었기 때문이다

짧은 단발성 호출만 있을 때는 정적 정책으로도 버틸 수 있습니다. 하지만 최근 운영 패턴은 다릅니다.

• 세션이 스레드나 프로젝트 단위로 오래 유지됩니다.
• 보조 에이전트가 조사, 수정, 검증을 분담합니다.
• 승인 대기 후 다시 이어서 실행되는 흐름이 늘어납니다.
• 결과물은 Test Evidence Pipeline이나 Action Lineage Graph처럼 구조화된 증거와 함께 남아야 합니다.

이 구조에서는 “한 번 허용한 권한이 언제까지 유효한가"가 훨씬 중요합니다. 승인 순간에는 안전했어도, 2시간 뒤 작업 문맥이 바뀌면 같은 권한은 위험해질 수 있습니다.

4) capability lease는 세션 보안과도 붙어야 한다

lease를 발급해도 세션이 탈취되면 문제가 남습니다. 그래서 capability lease는 Passkey + Device-Bound Session 같은 세션 무결성 계층과 같이 가야 합니다. 이상적인 구조는 아래에 가깝습니다.

• 사람 승인 또는 정책 판정이 발생한다.
• 해당 세션/기기 문맥에 묶인 lease가 짧게 발급된다.
• 실행 중 증적이 쌓이고, 범위를 벗어나면 즉시 거부된다.
• 시간이 지나거나 handoff가 일어나면 lease는 자동 만료된다.

즉 권한은 “누가 로그인했는가"보다 지금 이 작업이 여전히 같은 문맥 안에 있는가를 더 강하게 반영해야 합니다.

5) KPI도 자동화율보다 권한 체류 시간을 봐야 한다

성숙한 팀은 “얼마나 많이 자동화했는가” 대신 아래 숫자를 봅니다.

• dormant_permission_minutes: 발급됐지만 실제 사용되지 않은 권한의 총 시간
• out_of_scope_action_rate: lease 범위를 벗어난 액션 시도 비율
• approval_to_execution_p95: 승인 후 실제 실행까지 걸리는 시간
• expired_lease_reuse_attempts: 만료 권한 재사용 시도 건수
• manual_revoke_time: 사람이 중단 버튼을 눌렀을 때 실제 회수까지 걸리는 시간

이 수치가 중요한 이유는, 긴 수명의 넓은 권한이야말로 사고 표면을 키우기 때문입니다. lease가 잘 설계된 시스템은 과권한 상태가 오래 남아 있지 않습니다.

실무 적용

1) 최소 capability lease 스키마

처음부터 복잡한 권한 엔진이 필요하지는 않습니다. 아래 정도면 출발점으로 충분합니다.

• lease_id
• subject_id
• task_id
• allowed_actions[]
• resource_scope[]
• issued_at, expires_at
• approval_ref
• max_effect
• revoked_at
• evidence_ref

핵심은 lease가 정책 파일의 복사본이 아니라, 이번 작업의 실행 계약이라는 점입니다. 그래서 발급과 사용, 만료와 회수 이벤트가 모두 추적 가능해야 합니다.

2) 의사결정 기준(숫자·조건·우선순위)

보통 아래 기준으로 시작하면 현실적입니다.

• read-only 조사 lease: 15~30분
• 로컬 문서/코드 수정 lease: 30~60분
• 운영 환경 변경 lease: 10~15분, 승인 참조 필수
• 외부 전송/권한 변경 lease: 단일 액션 단위, 실행 직후 즉시 만료
• 하위 에이전트 lease: 부모 lease보다 항상 더 좁아야 함

추가 조건 예시는 이렇습니다.

• 동일 lease로 파일 20개 이상 수정 시 재승인 요구
• 승인 후 10분 내 실행되지 않으면 lease 자동 폐기
• 세션 handoff 또는 기기 문맥 변경 감지 시 lease 즉시 무효화
• out_of_scope_action_rate가 0.5%를 넘으면 정책보다 프롬프트 수정이 아니라 권한 설계 재검토 우선

우선순위는 즉시 회수 가능성 > 짧은 만료 시간 > 작업 범위 최소화 > 승인 UX > 구현 편의성 순이 좋습니다.

3) 4주 도입 플랜

1주차: 정적 권한 인벤토리화
현재 에이전트별 허용 도구, 쓰기 범위, 외부 전송 가능 범위를 모두 표로 뽑습니다.

2주차: 3개 작업 유형만 lease화
read-only 조사, 문서 수정, 운영 액션 세 가지만 먼저 task-scoped lease로 분리합니다.

3주차: 승인/세션 계층 연결
승인 이벤트와 lease 발급을 1:1 또는 1:N으로 연결하고, 세션 무결성 검증 실패 시 자동 회수되게 만듭니다.

4주차: evidence와 lineage 결합
lease 발급, 사용, 만료, 회수 이벤트를 evidence bundle과 lineage graph에 연결해 “왜 이 액션이 허용됐는가"를 5분 안에 설명 가능하게 만듭니다.

4) 어디부터 효과가 큰가

아래 환경에서는 특히 효과가 큽니다.

장시간 스레드형 세션이 많은 팀
오래 살아 있는 세션은 과권한이 남기 쉽습니다.

승인 후 실행까지 시간차가 큰 팀
승인과 실행 사이가 길수록 정적 권한이 위험해집니다.

멀티에이전트 분업이 있는 팀
보조 에이전트마다 lease를 다르게 줄 수 있어 blast radius를 줄이기 쉽습니다.

외부 전송과 운영 액션이 섞이는 팀
문서 작성과 배포, 알림 발송이 같은 세션에서 일어나면 lease 경계가 특히 중요합니다.

트레이드오프/주의점

1. lease TTL이 너무 짧으면 승인 피로가 커진다
   보안은 좋아지지만 실제 작업 흐름이 계속 끊길 수 있습니다.

2. 너무 세밀한 scope는 운영자가 이해하기 어렵다
   권한 모델이 정교해도 사람이 검토할 수 없으면 결국 우회가 생깁니다.

3. 회수 경로가 느리면 lease는 이름만 임시권한이다
   revoke가 수동 배치 반영이라면 사고 시점에는 이미 늦습니다.

4. 정책 파일만 있고 실행 문맥이 없으면 절반짜리다
   lease는 manifest, session binding, evidence, lineage와 같이 움직여야 합니다.

체크리스트 또는 연습

체크리스트

• read-only, write, 외부 전송, 운영 액션에 서로 다른 lease TTL이 있다.
• 승인 이벤트와 lease 발급 레코드가 연결된다.
• 하위 에이전트는 부모보다 좁은 lease만 받는다.
• handoff, 세션 변경, 기기 문맥 변경 시 lease가 자동 만료된다.
• dormant permission minutes와 expired reuse attempt를 측정한다.

연습 과제

1. 지금 쓰는 에이전트 워크플로 1개를 골라, 정적 역할 대신 task-scoped lease로 바꾸면 TTL과 scope를 어떻게 나눌지 설계해 보세요.
2. 최근 승인 기반 작업 3건을 돌아보고, 승인 시점과 실제 실행 시점 사이의 간격을 측정해 보세요. 10분 이상 벌어진 작업이 많다면 lease 만료 정책이 필요한 신호일 수 있습니다.
3. 외부 전송, 파일 수정, 배포 액션을 각각 하나씩 골라 max_effect를 숫자로 정의해 보세요. 예를 들면 파일 수정 20개 이하, 배포 대상 1개 환경만 허용 같은 식입니다.

관련 글

• Tool Permission Manifest + Runtime Attestation
• Passkey + Device-Bound Session
• Harness Engineering
• Test Evidence Pipeline
• Action Lineage Graph
• Approval-Driven Auto-Remediation