핵심 요약

• shadow는 실행을 하지 않는 비교 단계입니다. 정책의 판단과 사람이 내린 최종 판단, 둘이 달랐던 이유를 함께 기록합니다.
• 제한 auto는 좁고 되돌릴 수 있는 내부 작업에서만 시작합니다. 입력 형식, 호출자, 대상 리소스, 실행 환경을 미리 묶어 둡니다.
• 외부 발송·삭제·결제·권한 확대는 별도 경계입니다. 영향이 비가역적이거나 대상이 넓다면 승인 대기 또는 차단이 기본값입니다.
• 승격 기준과 롤백 책임자를 같은 카드에 적어야 합니다. 관측값이 나빠졌을 때 누가 어떤 스위치로 멈출지 빠져 있으면 자동 실행으로 올리지 않습니다.

auto가 생겼다고 바로 자동 실행하면 안 되는 이유

새 agent 또는 MCP 도구 정책에 auto 선택지가 보이면, 팀은 곧바로 “이제 승인 없이 돌려도 되는가?”를 묻게 됩니다. 이 질문에는 도구 이름이 아니라 호출 한 번이 실제로 무엇을 바꾸는지로 답해야 합니다.

Claude Managed Agents의 permission policies 문서는 서버가 agent 또는 MCP 도구 호출을 호출별로 평가하고, 실행·거부·승인 대기 결정을 다룬다고 설명합니다. 릴리스 노트는 관련 평가 정보가 이벤트에 남는다고 안내합니다. 다만 이 기능은 해당 제품의 Managed Agents 범위에 대한 설명이며, 문서상 beta 상태와 변경 가능성도 함께 확인해야 합니다. 다른 도구나 공급자에 같은 동작을 단정해서는 안 됩니다.

3단계 rollout: shadow → 제한 auto → pause 또는 deny

처음부터 모든 호출을 같은 속도로 승격하지 마세요. 아래 순서는 판단 품질과 실행 범위를 분리해 검증하는 데 쓰는 운영 틀입니다.

shadow 단계는 ‘아무 일도 하지 않는 기간’이 아닙니다. 예를 들어 내부 문서 검색 도구라면 호출 목적, 검색 범위, 정책의 예상 결정, 담당자가 실제로 내린 결정을 남겨 둘 수 있습니다. 이 기록이 있어야 나중에 제한 auto로 올릴 때 “왜 이 입력과 이 대상은 괜찮은가”를 설명할 수 있습니다.

팀이 함께 쓰는 6칸 canary 카드

도구마다 아래 여섯 칸을 한 장으로 적어 두면, “자동화하자”는 추상적인 합의를 실제 운영 기준으로 바꿀 수 있습니다. 이 카드는 특정 제품의 설정 화면을 대신하지 않습니다. 팀이 호출 범위와 중단 조건을 합의하기 위한 기록 양식입니다.

1. 영향도
   읽기, 내부 변경, 외부 변경 중 어디에 속하는지 적습니다.
2. 입력 경계
   허용할 입력 형식과 길이, 호출자를 정합니다.
3. 대상
   접근 가능한 프로젝트·폴더·계정 등 리소스를 좁게 지정합니다.
4. 기대 결정
   shadow에서 어떤 판단이 나와야 하는지 한 문장으로 씁니다.
5. 증거
   결정, 사람 판단, 결과, 오류, 불일치 이유를 연결합니다.
6. 롤백 책임자
   누가 어떤 조건에서 중지하고 복구할지 정합니다.

예시: 내부 조회와 고객 이메일 발송을 같은 방식으로 다루지 않기

아래는 실제 고객 사례나 성능 측정 결과가 아닌, 판단 방법을 보여 주는 가상의 업무 예시입니다.

비용 관점에서도 차이가 큽니다. 조회 호출의 오류는 재시도와 조사 비용으로 끝날 수 있지만, 잘못 보낸 이메일은 고객 신뢰 회복, 지원 대응, 기록 정정 비용으로 이어질 수 있습니다. 자동화의 이득은 호출 수가 아니라 오류가 났을 때 팀이 감당할 운영 비용까지 포함해 판단해야 합니다.

승격을 멈춰야 하는 실패 조건

NIST AI Risk Management Framework는 위험을 거버넌스, 맥락 파악, 측정, 관리의 연속 과정으로 다룹니다. 이를 특정 도구 기능의 안전 보증으로 해석할 수는 없지만, 자동 실행 범위를 한 번 정하고 끝내지 말아야 한다는 운영 원칙에는 도움이 됩니다. 호출 범위가 바뀌거나 새로운 실패가 나타나면 카드를 다시 shadow로 되돌리는 것이 자연스러운 절차입니다.

기존 운영 글과 함께 적용하는 순서

1. 먼저 중앙 정책이 실제 IDE에 적용됐는지 확인하는 방법으로 설정의 실제 상태를 확인합니다.
2. 그다음 읽기와 외부 변경의 최초 승인 경계를 정하는 방법으로 도구를 분류합니다.
3. 장기 작업이라면 사람 재판단 지점을 설계하는 방법을 함께 적용합니다.
4. 마지막으로 설정의 intended state와 actual state를 대조하는 방법에 canary 카드 결과를 남깁니다.

자주 묻는 질문

auto가 있으면 사람 승인을 완전히 없애도 되나요?

아닙니다. auto는 제품과 정책이 호출을 평가하는 방식일 수 있지만, 비가역적이거나 외부 영향을 만드는 업무까지 사람의 검토를 없애는 근거는 아닙니다.

shadow 단계에서는 무엇을 기록해야 하나요?

호출 목적, 입력과 대상 범위, 정책 판단, 사람이 내린 최종 판단, 둘이 달랐던 이유, 예상된 결과와 실제 관측값을 함께 남기는 것이 좋습니다.

제한 auto로 올려도 되는 도구는 어떻게 고르나요?

입력·대상·환경이 좁고, 결과가 내부에만 머물며, 실패해도 되돌릴 수 있고, 중단과 복구 책임자가 명확한 도구부터 검토하세요.

외부 발송과 권한 변경은 왜 승인 대기 또는 차단으로 남겨야 하나요?

수신자·계정·권한 범위가 조금만 달라져도 결과가 되돌리기 어렵고 신뢰 비용이 커질 수 있기 때문입니다. 개별 호출의 평가 결과만으로 그 비용을 상쇄할 수는 없습니다.

참고 자료

• Claude Platform release notes — Managed Agents permission policies의 변경 사항과 이벤트 기록 설명을 확인했습니다.
• Claude Managed Agents: Permission policies — 호출별 권한 평가와 제품 범위를 확인했습니다.
• Claude Managed Agents overview — beta 상태와 적용 전제를 확인했습니다.
• NIST AI Risk Management Framework — 위험을 지속적인 거버넌스와 관리 과정으로 다루는 관점을 참고했습니다.