그래서 최근 흐름은 단순히 “에이전트에게 폴더를 하나 주자"에서 한 단계 더 나아가고 있습니다. 저는 이걸 Agent Workspace Lease Broker라고 부르는 편이 좋다고 봅니다. 작업공간을 영구 소유물이 아니라, 제한된 시간 동안 발급되는 lease로 보는 방식입니다. 이 관점은 Stateful Sandbox Snapshot, Harness Engineering, Background Agent Session Result Inbox, Agent Handoff Packet과 자연스럽게 이어집니다. 핵심은 에이전트가 코드를 잘 쓰는가보다, 작업공간의 시작·변경·검증·회수가 설명 가능한가입니다.

이 글에서 얻는 것

• 코딩 에이전트 작업공간을 단순 worktree가 아니라 lease 단위 운영 자원으로 봐야 하는 이유를 이해할 수 있습니다.
• lease에 repo, branch, allowed paths, TTL, secret scope, validation contract를 넣는 기준을 잡을 수 있습니다.
• 병렬 에이전트 작업에서 merge 충돌, stale 환경, 비밀값 노출, 결과 회수 누락을 줄이는 실무 절차를 설계할 수 있습니다.

핵심 개념/이슈

1) 작업공간은 폴더가 아니라 실행 계약이다

Git worktree, devcontainer, sandbox snapshot은 모두 유용합니다. 하지만 그것만으로는 운영 질문에 답하기 어렵습니다. 예를 들어 에이전트 A가 billing 모듈을 고치고, 에이전트 B가 같은 repo에서 auth 모듈을 고친다고 합시다. 폴더는 분리돼 있어도 shared test database, dependency cache, feature flag config, generated file, lock file이 겹치면 결과가 서로 오염될 수 있습니다.

Lease는 이 경계를 명시합니다.

lease_id: ws_20260511_001
repo: study-blog
base_ref: main@abc123
branch: agent/authz-cache-playbook
allowed_paths:
  - content/learning/deep-dive/**
ttl_minutes: 180
secret_scope: none
network_scope: docs-readonly
validation_contract:
  - markdown frontmatter check
  - internal link check
  - word count gate
cleanup_policy: archive_24h_then_delete
result_target: background-agent-inbox

이렇게 적으면 작업공간은 그냥 위치가 아니라 “어디까지 해도 되는지"와 “언제 끝나야 하는지"를 가진 자원이 됩니다. Capability Lease가 권한의 시간 제한이라면, workspace lease는 파일·환경·검증 범위의 시간 제한입니다.

2) 병렬성의 진짜 비용은 merge 시점에 온다

에이전트를 여러 개 띄우면 초반에는 생산성이 크게 오른 것처럼 보입니다. 하지만 같은 모듈, 같은 테스트 fixture, 같은 generated schema를 건드린 작업이 나중에 한꺼번에 합쳐지면 사람이 충돌을 풀어야 합니다. 이때 문제는 단순 Git conflict가 아닙니다. 두 변경이 각각은 통과했지만 함께 돌리면 깨지는 semantic conflict가 더 흔합니다.

그래서 lease broker는 작업 생성 시점에 충돌 가능성을 낮춰야 합니다.

• repo별 동시 active lease: 처음에는 3~5개 이하
• 같은 top-level module 동시 수정: 기본 1개, 예외 시 owner 승인
• 수정 파일 수 예상 10개 초과 또는 서비스 2개 이상 영향: 별도 merge lane
• generated file, migration, lockfile 수정: lease 생성 시 conflict flag 부여
• base ref가 main보다 24시간 이상 뒤처지면 rebase 또는 재생성 요구

이 기준은 Change Intelligence Control Plane과 닮았습니다. 차이는 change intelligence가 변경 위험을 읽는 계층이라면, workspace lease broker는 위험한 충돌이 생기기 전에 작업공간 배정을 조정하는 계층이라는 점입니다.

3) stale workspace는 실패보다 더 조용하게 위험하다

실패한 에이전트 작업은 눈에 보입니다. 테스트가 깨지고, 에러가 남고, 리뷰어가 멈춥니다. 더 위험한 것은 오래 살아남은 작업공간입니다. 3일 전 dependency 상태, 이미 바뀐 API 계약, 만료된 feature flag, 예전 환경변수가 남아 있는데 에이전트가 그 위에서 새 코드를 생성하면 결과는 그럴듯하지만 최신 main과 맞지 않을 수 있습니다.

따라서 lease에는 freshness 기준이 필요합니다.

이 관점은 Context Freshness Budget과도 같습니다. 오래된 컨텍스트가 답을 오염시키듯, 오래된 작업공간은 diff를 오염시킵니다.

4) 결과 회수는 diff가 아니라 lease 종료 이벤트다

백그라운드 에이전트 결과를 받을 때 “수정했습니다” 한 줄은 부족합니다. 사람이 필요한 것은 merge 가능한 상태인지, 어떤 검증을 통과했는지, 어떤 파일이 lease 범위를 벗어났는지, 작업공간을 지워도 되는지입니다. 그래서 result inbox에는 diff summary만이 아니라 lease 종료 이벤트가 들어가야 합니다.

종료 이벤트의 최소 필드는 다음입니다.

• lease id, repo, branch, base ref, final ref
• changed files, allowed path 위반 여부
• validation commands와 결과
• 실패/보류 사유와 재현 명령
• 남은 임시 파일, DB, cache, background process 여부
• 다음 액션: merge, review, rerun, archive, discard

이 구조가 있으면 Execution Receipt와 Action Lineage Graph에 작업공간 단위 증거를 연결하기 쉬워집니다. 에이전트가 뭘 했는지만이 아니라, 어떤 환경에서 했고 그 환경을 어떻게 회수했는지가 남습니다.

실무 적용

1) 처음에는 broker를 서비스로 만들지 말고 기록부터 표준화한다

가장 현실적인 시작은 별도 플랫폼이 아니라 작은 lease record입니다. issue comment, PR body, JSON 파일, 내부 queue metadata 중 어디든 좋습니다. 중요한 것은 작업 생성 시점에 아래 필드를 강제하는 것입니다.

lease_id:
owner:
agent:
repo:
base_ref:
branch_or_worktree:
allowed_paths:
forbidden_paths:
ttl:
secret_scope:
network_scope:
validation_contract:
cleanup_policy:
result_target:

이 필드가 쌓이면 나중에 자동 broker로 옮기기 쉽습니다. 반대로 처음부터 Kubernetes operator나 복잡한 control plane을 만들면 실제 병목을 확인하기 전에 운영 부담이 커집니다.

2) worktree와 validation contract를 같이 발급한다

작업공간만 만들고 검증 명령을 나중에 정하면 결과 비교가 어렵습니다. lease 생성 시점에 “이 작업의 완료 조건"을 붙여야 합니다. 예를 들어 문서 작업은 frontmatter, 링크, 문자수 검증이 완료 조건이고, 백엔드 코드 작업은 unit test, integration test, migration dry-run, lint가 완료 조건일 수 있습니다.

기본 운영값은 아래처럼 잡을 수 있습니다.

• low-risk 문서/설정 작업: TTL 2~3시간, allowed paths 좁게, validation 1~3개
• 일반 코드 수정: TTL 4~8시간, repo 동시 lease 제한, unit test 필수
• migration/보안/권한 변경: TTL 짧게, secret scope 최소화, human review lane 고정
• 실패한 lease: 자동 재시도 1회 이하, 이후 result inbox로 보류
• 완료 후 cleanup evidence 없으면 merge 전 경고

이 기준은 Task Graph Runtime과도 연결됩니다. task graph의 각 노드가 독립 검증 단위를 갖듯, workspace lease도 독립 회수 단위를 가져야 합니다.

3) 비밀값과 네트워크 범위를 lease에 묶는다

코딩 에이전트 작업공간은 단순 파일 수정 공간이 아닙니다. 테스트를 돌리고, 패키지를 설치하고, 외부 문서를 읽고, 때로는 staging API에 접근합니다. 따라서 secret scope와 network scope를 lease에 넣어야 합니다.

권장 우선순위는 보수적입니다.

1. 기본값은 secret 없음, 외부 네트워크 제한
2. dependency install은 registry allowlist와 lockfile 검증
3. staging token은 작업군별 short-lived token만 사용
4. production secret은 자동 에이전트 workspace에 직접 주입 금지
5. 외부 전송·배포·결제 권한은 workspace lease가 아니라 별도 capability lease로 분리

이렇게 해야 작업공간 정리 실패가 곧 비밀값 잔존 사고로 이어지지 않습니다. Tool Permission Manifest와 같은 권한 선언 흐름이 workspace 레벨까지 내려오는 셈입니다.

트레이드오프/주의점

첫째, lease broker는 분명 마찰을 만듭니다. 에이전트를 바로 실행하는 것보다 lease를 발급하고 범위를 적는 과정이 느립니다. 하지만 repo가 커지고 병렬 작업이 늘면 이 마찰은 비용이 아니라 보험이 됩니다. 특히 같은 파일을 세 에이전트가 동시에 고치는 상황을 한 번 겪으면, 사전 범위 제한의 가치가 바로 보입니다.

둘째, 자동 cleanup은 조심해야 합니다. 오래된 작업공간을 전부 삭제하면 깔끔해 보이지만, 실패 재현 증거까지 날릴 수 있습니다. 처음에는 delete보다 archive가 낫습니다. 성공한 저위험 작업은 24~72시간 뒤 삭제하고, 실패·보안·권한 관련 작업은 7일 이상 보관하는 식으로 위험도별 정책을 나눕니다.

셋째, 중앙 broker가 병목이 될 수 있습니다. 모든 작은 작업까지 승인 큐를 타게 만들면 에이전트의 장점이 사라집니다. 따라서 정책은 risk-tier별로 달라야 합니다. 저위험 문서 수정은 자동 발급, migration·권한·배포 경로는 좁은 lease와 review lane을 붙이는 식이 현실적입니다.

넷째, lease record가 있어도 실제 환경 격리가 없으면 반쪽입니다. 같은 테스트 DB, 같은 Redis, 같은 로컬 cache를 공유하면 폴더만 분리된 상태가 됩니다. 최소한 테스트 namespace, temp directory, port range, cache key prefix는 lease id 기반으로 분리해야 합니다.

의사결정 우선순위는 충돌 방지 > 비밀값/권한 범위 > 검증 재현성 > 회수 가능성 > 실행 속도입니다. 에이전트가 빠르게 시작하는 것보다, 끝난 뒤 사람이 믿고 회수할 수 있는지가 더 중요합니다.

체크리스트 또는 연습

체크리스트

• 에이전트 작업마다 lease id, repo, base ref, branch/worktree가 기록된다.
• allowed paths와 forbidden paths가 작업 생성 시점에 정해진다.
• repo별 active lease 수와 같은 모듈 동시 수정 수에 상한이 있다.
• validation contract가 lease에 포함되고, 완료 보고는 같은 lease 안의 실행 결과만 인정한다.
• secret scope와 network scope 기본값이 최소 권한이다.
• idle/stale workspace 기준과 archive/delete 정책이 있다.
• result inbox에 lease 종료 이벤트, cleanup evidence, next action이 함께 들어간다.
• lease 범위를 벗어난 파일 수정은 merge 전에 경고되거나 차단된다.

연습

1. 현재 팀에서 에이전트가 가장 자주 만지는 repo 1개를 골라 active workspace 목록을 만들어 보세요. base ref가 24시간 이상 지난 작업이 몇 개인지 확인하는 것만으로도 stale 비용이 보입니다.
2. 문서 수정, 일반 코드 수정, migration 작업을 각각 하나씩 골라 lease TTL, allowed paths, validation contract를 표로 작성해 보세요.
3. 완료된 에이전트 작업 3건을 대상으로 “diff 요약"이 아니라 “lease 종료 이벤트” 형식으로 다시 정리해 보세요. cleanup evidence와 next action이 빠져 있을 가능성이 큽니다.

관련 글

• Stateful Sandbox Snapshot
• Harness Engineering
• Background Agent Session Result Inbox
• Agent Handoff Packet
• Capability Lease