저는 이 흐름을 Policy Shadow Rollout이라고 보는 편이 가장 정확하다고 생각합니다. 새 guardrail이 실제로는 무엇을 막았을지, 무엇을 놓쳤을지, 누구에게 불필요한 friction을 만들었을지를 counterfactual verdict로 먼저 쌓는 구조입니다. 이 방향은 Schema Constrained Output + Runtime Validator가 만든 accept, repair, escalate 경계, Tool Permission Manifest + Runtime Attestation의 권한 선언, Change Intelligence Control Plane의 위험도 판단, Escalation Policy Ladder의 단계 승격과 자연스럽게 이어집니다. 이제 중요한 것은 “정책을 더 추가할까"가 아니라 정책을 어떤 순서로 현실에 올릴까입니다.

이 글에서 얻는 것

• Policy Shadow Rollout이 왜 단순 feature flag나 dry-run 로그와 다른지 이해할 수 있습니다.
• 새 guardrail을 shadow → warn → partial enforce → full enforce로 올릴 때 어떤 숫자 기준을 써야 하는지 가져갈 수 있습니다.
• false positive만이 아니라 missed high-risk block까지 같이 보지 않으면 왜 정책 품질이 왜곡되는지 설명할 수 있습니다.
• execution receipt와 escalation 체계를 붙여 shadow verdict를 실무 의사결정으로 연결하는 방법을 잡을 수 있습니다.

핵심 개념/이슈

1) 지금 병목은 “정책 부족"보다 “정책 배포 방식 미성숙"이다

대부분 팀은 정책을 만들 때는 진지하지만, 배포할 때는 이분법으로 갑니다. 끄거나 켜거나, 허용하거나 차단하거나 둘 중 하나입니다. 그런데 에이전트 런타임에서는 이 방식이 잘 안 맞습니다. 같은 규칙이라도 문서 초안 작업에서는 과잉 차단이 될 수 있고, 운영 변경 작업에서는 오히려 늦게 막는 문제가 생길 수 있기 때문입니다.

그래서 shadow rollout은 규칙의 품질을 먼저 검증합니다. 핵심 질문은 아래 세 가지입니다.

1. 이 정책이 실제 트래픽에서 얼마나 자주 발동하는가
2. 그 발동 중 몇 %가 쓸데없는 오탐인가
3. 아직 enforce하지 않았기 때문에 놓치고 있는 high-risk 케이스가 있는가

중요한 점은 정책 없는 자유 상태와, 나쁜 정책으로 인한 마찰 상태 둘 다 비용이라는 사실입니다. 성숙한 팀은 둘 중 하나를 감으로 고르지 않고 shadow 데이터를 쌓아 비교합니다.

2) shadow mode의 핵심은 “로그 남기기"가 아니라 counterfactual verdict를 구조화하는 것이다

단순 shadow logging은 “이 규칙이 발동했음” 정도에서 끝나기 쉽습니다. 하지만 실무에 필요한 것은 그보다 더 구조화된 기록입니다.

• 어떤 입력과 실행 문맥에서 발동했는가
• 실제 실행 결과는 무엇이었는가
• shadow 정책이 권장한 행동은 allow, repair, escalate, block 중 무엇이었는가
• 사람 리뷰 기준으로 그 판정이 맞았는가
• 같은 조건이 반복되면 어떤 계층으로 자동 승격할 것인가

이 정보가 있어야 shadow mode가 단순 통계가 아니라 운영 의사결정 도구가 됩니다. 그래서 Execution Receipt와 붙는 순간 가치가 커집니다. receipt가 없으면 shadow verdict가 남아도, 실제로 무슨 툴이 실행됐고 어떤 범위까지 갔는지 연결할 수 없습니다.

3) 좋은 shadow rollout은 false positive만 줄이지 않고 missed block도 같이 본다

많은 팀이 오탐을 싫어하다 보니 shadow 실험의 성공 조건을 false positive rate 감소 하나로만 잡습니다. 그런데 이렇게 하면 위험한 작업을 놓치는 정책이 오히려 “조용해서 좋은 정책"처럼 보일 수 있습니다. 그래서 최소한 아래 네 지표를 같이 봐야 합니다.

• false_positive_rate: 막지 말아야 할 작업을 막으려 한 비율
• missed_high_risk_rate: 막았어야 할 high-risk 작업을 놓친 비율
• shadow_coverage: 실제 고위험 작업 중 shadow verdict가 붙은 비율
• explainability_coverage: 왜 그렇게 판정했는지 사람이 읽을 수 있는 근거가 붙은 비율

권장 출발 기준은 아래 정도가 실전적입니다.

• high-risk 작업 shadow coverage 95% 이상
• explainability coverage 90% 이상
• false positive rate 5% 미만
• missed high-risk rate 1% 미만
• rollback 또는 disable 결정 시간 15분 이내

핵심은 차단 건수를 늘리는 것이 아니라, 놓치면 안 되는 것을 거의 안 놓치면서 현업 마찰은 감당 가능한 수준으로 유지하는 것입니다.

4) rollout 단계는 최소 4단으로 나누는 편이 안전하다

실무에서는 아래 4단이 가장 다루기 쉽습니다.

1. Shadow: 실제 실행에는 개입하지 않고 verdict와 근거만 수집
2. Warn: 사용자나 리뷰어에게 경고만 보여 주고 실행은 계속 허용
3. Partial Enforce: 특정 작업군, 특정 팀, 특정 리스크 클래스에만 강제
4. Full Enforce: 전면 강제, 단 예외와 rollback 경로 유지

이때 단계 승격 기준은 정책의 “정확도 느낌"이 아니라 작업군별 위험도와 증거 충족률로 정하는 편이 낫습니다. 예를 들어 외부 전송 정책은 문서 초안보다 먼저 enforce할 수 있고, 삭제 정책은 low-risk 리포지토리보다 production 경로에서 먼저 shadow coverage를 높여야 합니다. 이 구조는 Capability Lease와도 잘 맞습니다. 정책을 전역으로 켜기보다, lease 범위 안에서 점진적으로 강제할 수 있기 때문입니다.

5) 결국 중요한 것은 “정책 배포의 observability"다

Policy Shadow Rollout이 뜨는 이유는 에이전트 정책도 이제 소프트웨어 배포처럼 다뤄야 하기 때문입니다. 어떤 규칙이 언제 추가됐고, 어떤 팀에 먼저 적용됐고, 오탐이 어디서 늘었고, 어떤 런타임 업데이트 뒤에 판정이 흔들렸는지를 추적해야 합니다.

그래서 좋은 팀은 아래 연결을 같이 설계합니다.

• policy version
• shadow verdict
• execution receipt
• escalation result
• reviewer feedback
• rollback event

이 중 하나라도 빠지면 정책은 남는데 운영 지식이 안 쌓입니다. 특히 모델 버전이나 툴 체인이 바뀐 뒤 shadow 성능이 흔들리는지 보는 일은 중요합니다. 같은 규칙이어도 입력 구조가 바뀌면 false positive 패턴이 달라질 수 있기 때문입니다.

6) 운영 리뷰는 “주간 scorecard 한 장"으로 닫히는 편이 좋다

shadow rollout이 길어질수록 흔히 생기는 문제가 있습니다. 데이터는 여러 대시보드에 흩어져 있고, 회의 때는 각 팀이 자기에게 편한 숫자만 가져오는 상황입니다. 이렇게 되면 false positive를 줄인 팀과 missed block을 줄인 팀이 서로 다른 성공을 주장하게 되고, 결국 정책을 올릴지 말지 합의가 느려집니다.

그래서 저는 주간 운영 리뷰를 한 장짜리 scorecard로 닫는 방식이 가장 실전적이라고 봅니다. 최소한 아래 다섯 줄은 같은 표에서 봐야 합니다.

• 정책 버전과 대상 작업군
• shadow coverage, false positive rate, missed high-risk rate
• explainability coverage와 reviewer override 비율
• warn 또는 partial enforce 이후 friction 증가 여부
• rollback rehearsal 결과와 owner 확인 상태

이 다섯 줄을 한 화면에서 보면, 어떤 정책이 “정확해 보이지만 아직 설명 가능성이 부족한지”, 어떤 정책이 “조용하지만 사실 놓치는 비율이 높은지"가 빨리 드러납니다. 여기에 Action Lineage 같은 실행 추적을 붙이면 policy change와 downstream incident를 더 쉽게 묶을 수 있고, Test Evidence Pipeline처럼 변경 근거를 증거 패킷으로 묶는 구조와도 잘 맞습니다.

중요한 점은 scorecard가 예쁜 보고서가 아니라 승격 결정을 빠르게 내리기 위한 운영 인터페이스여야 한다는 것입니다. 리뷰 회의가 끝났을 때 “다음 주에도 더 보자"가 아니라, warn으로 올릴지, partial enforce로 올릴지, 아니면 rollback 준비 상태부터 채울지를 바로 정할 수 있어야 합니다.

실무 적용

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

정책 rollout 순서는 아래 우선순위가 안전합니다.

1순위, high-risk 작업부터 shadow coverage 확보

• 외부 전송, 배포, 권한 변경, 삭제, 고객 데이터 접근
• 이 영역은 먼저 shadow verdict를 95% 이상 붙이는 것이 중요합니다.

2순위, explainability 확보

• reviewer가 30초 안에 판정 근거를 읽을 수 있어야 합니다.
• explainability coverage가 90% 미만이면 warn 이상으로 올리지 않는 편이 낫습니다.

3순위, missed high-risk rate 축소

• missed high-risk가 1%를 넘으면 false positive를 조금 희생하더라도 먼저 보강합니다.

4순위, false positive 최적화

• warn 단계에서 5% 미만, partial enforce에서 3% 미만 정도를 목표로 조정합니다.

추천 정책 게이트 예시는 아래처럼 시작할 수 있습니다.

• Shadow → Warn: coverage 90% 이상, explainability 85% 이상
• Warn → Partial Enforce: false positive < 5%, missed high-risk < 1%
• Partial → Full Enforce: 2주 연속 안정, rollback 없이 운영 가능

2) 4주 도입 순서

1주차: 상위 3개 고위험 정책만 shadow로 붙인다
욕심내서 20개 정책을 한 번에 shadow로 넣지 않는 편이 낫습니다. 먼저 외부 전송, 권한 변경, 삭제 정도만 잡습니다.

2주차: receipt와 reviewer feedback를 연결한다
shadow verdict만 쌓지 말고, 실제 결과와 사람 판정을 붙여 오탐과 누락을 분류합니다.

3주차: warn 단계로 올리고 friction 구간을 찾는다
어떤 팀, 어떤 작업군, 어떤 툴에서 경고가 과도하게 뜨는지 봅니다.

4주차: partial enforce + rollback 훈련
한 작업군이나 한 팀부터 강제 적용하고, 15분 안에 정책을 끌 수 있는지 실제로 연습합니다.

3) 운영 테이블 예시

이 표에서 핵심은 정책별로 같은 rollout 속도를 강요하지 않는 것입니다. 민감 문맥 정책과 코드 수정 범위 정책은 전혀 다른 데이터 품질 문제를 가지기 때문입니다.

4) Shadow verdict를 escalation과 연결하는 방식

정책은 차단만 잘해도 끝나는 것이 아닙니다. 어떤 경우는 block보다 escalate가 더 맞습니다. 예를 들어 위험하지만 합법적일 수 있는 작업은 바로 차단하기보다 Escalation Policy Ladder로 올리는 편이 더 현실적입니다. 그래서 shadow verdict는 보통 아래 네 갈래를 가져가는 편이 좋습니다.

• allow
• repair
• escalate
• block

이 구조를 쓰면 오탐을 줄이기 위해 모든 것을 allow로 두는 극단도, 위험하다는 이유로 전부 block하는 극단도 피하기 쉽습니다.

트레이드오프/주의점

첫째, shadow mode를 오래 끌면 데이터는 예쁘게 쌓이는데 실제 위험은 계속 노출될 수 있습니다. high-risk 정책은 shadow를 길게 끌기보다 warn과 partial enforce로 빨리 올릴 기준을 같이 잡아야 합니다.

둘째, explainability 없는 shadow는 숫자만 남기고 신뢰를 잃습니다. 리뷰어가 이유를 이해할 수 없으면 false positive 조정이 늦어집니다.

셋째, rollout을 전역 기준 하나로 통일하면 팀별 편차를 놓칩니다. 저장소 유형, 작업군, 민감도에 따라 따로 봐야 합니다.

넷째, receipt 없이 policy만 남기면 “왜 막았는지"보다 “그냥 막혔다"만 남습니다. 운영 피로가 급격히 올라갑니다.

다섯째, rollback 훈련 없이 full enforce로 가면 첫 번째 대형 오탐에서 정책 전체에 대한 반감이 생길 수 있습니다.

체크리스트 또는 연습

체크리스트

• 새 정책은 기본적으로 shadow부터 시작한다.
• shadow verdict에 근거와 실제 실행 결과가 같이 남는다.
• false positive와 missed high-risk를 분리 측정한다.
• shadow, warn, partial enforce, full enforce 단계 기준이 문서화돼 있다.
• 15분 이내 rollback 또는 disable 경로가 준비돼 있다.
• block이 아닌 escalate가 더 적합한 정책을 별도로 분리했다.

연습 과제

1. 현재 운영 중인 가드레일 3개를 골라 shadow coverage / false positive / missed high-risk / explainability 네 지표로 다시 평가해 보세요.
2. 외부 전송이나 삭제처럼 복구 비용이 큰 작업군 하나를 골라, shadow에서 partial enforce로 올리는 기준을 숫자로 적어 보세요.
3. 최근 오탐 사례 5개를 모아, 원인이 규칙 자체였는지 입력 분류 품질이 낮았는지 execution receipt 부족이었는지 나눠 보세요.

관련 글

• Schema Constrained Output + Runtime Validator
• Tool Permission Manifest + Runtime Attestation
• Execution Receipt
• Change Intelligence Control Plane
• Escalation Policy Ladder
• Capability Lease