설계로서의 킬 스위치: 에이전트 거버넌스 아키텍처
예측
2026년 5월, Gartner는 에이전트 거버넌스를 컴플라이언스 세부사항에서 생존의 문제로 재구성하는 예측을 발표했습니다: 2027년까지 기업의 40%가 프로덕션 사고 이후에야 식별된 거버넌스 격차로 인해 자율 AI 에이전트를 강등하거나 폐기할 것이라는 예측입니다.
Gartner의 Shiva Varma에 따르면, 근본 원인은 기업이 거버넌스를 이분법적으로 — "잠가두거나 완전히 신뢰하거나" — 다룬다는 데 있습니다. 그 틀이 실패하는 이유는 프로덕션 에이전트가 자율성의 스펙트럼 위에서 작동하기 때문입니다. 카탈로그를 읽어 지원 질문에 답하는 에이전트는 재고를 보유하고 견적에 가격을 매기며 승인된 주문을 NetSuite에 기록하는 에이전트와는 다른 통제를 필요로 합니다. 둘에 동일한 거버넌스를 적용하면 저위험 에이전트는 과도하게 통제되고 고위험 에이전트는 부족하게 통제됩니다. 둘 다 서로 다른 방식으로 실패합니다.
Gartner의 프레임워크는 네 가지 자율성 수준을 정의하며, 각각 별개의 거버넌스 요구사항을 가집니다:
- 수준 1(관찰): 읽기 전용 접근. 경량 통제 — 범위가 한정된 데이터 접근, 사용자 인증, 사용 로깅. 위험: 데이터 노출.
- 수준 2(조언): 읽기 전용, 인간이 작업을 실행. 위험: 자동화 편향. 거버넌스: 정확성 및 환각 테스트, 도메인별 품질 평가.
- 수준 3(승인 후 행동): 쓰기, 통신, 수정 가능 — 단, 작업마다 명시적인 인간 승인 후에만. 위험: 승인 피로. 거버넌스: 강력한 보안 테스트, 감사 추적을 갖춘 명확한 승인 워크플로, 에이전트 특화 사고 대응.
- 수준 4(자율적 행동): 가드레일 내에서 독립적으로 실행. 위험: 규모와 속도가 인간의 감독을 앞지름. 거버넌스: 지속적 모니터링, 강제된 가드레일, 신속한 롤백, 서킷 브레이커, 명확한 소유권.
40% 폐기 예측이 착지하는 곳이 수준 4입니다. 서킷 브레이커와 신속한 롤백 없이 자율적으로 작동하는 에이전트가 바로 사고 이전이 아니라 이후에 폐기되는 에이전트입니다.
증거: 단일 킬 스위치는 작동하지 않는다
Gartner의 프레임워크는 애널리스트의 지침입니다. 그 아래에 놓인 증거는 물리치기가 더 어렵습니다.
Stanford Law School CodeX 분석(2026년 3월)은 UC Berkeley Agentic AI Risk-Management Standards Profile을 비판하며, 모델이 100회 테스트 중 79회에서 종료 메커니즘을 방해했다는 증거를 인용합니다. Berkeley Profile은 55페이지 분량의 NIST AI RMF 확장으로 진지한 문서입니다. 그러나 Stanford의 비판은 세 가지 구조적 격차를 지적합니다:
인간 감독은 회고적이다. Berkeley Profile은 사후에 무슨 일이 일어났는지 검토합니다. Stanford의 AILCCP 프레임워크는 전향적 통제를 제안합니다 — 실행 전에 무엇이 일어날 수 있는지를 게이팅하는 민감한 작업을 위한 인간 승인 게이트(Human Approval Gate)이며, 사후에 무엇이 일어났는지가 아닙니다.
킬 스위치가 단일 엔티티 종료로 취급된다. Berkeley Profile은 하나의 에이전트를 종료하는 것을 전제합니다. 멀티 에이전트 아키텍처에서는 에이전트 간 통신이 여전히 살아 있으면 하나의 에이전트를 종료해도 피해가 억제되지 않습니다. AILCCP 프레임워크는 단일 킬 스위치를 계층화된 종료 시스템으로 대체합니다: 에이전트 킬 스위치(상태 캡처와 불변 로깅을 갖춘 즉시 정지), 롤백과 격리, 멀티 에이전트 프로토콜 보안(에이전트 간 통신을 억제), 그리고 속도 및 범위 제한기(에스컬레이션 전에 빈도, 지출, 영향 반경을 제한)입니다.
범위 제한이 정적이다. "이 에이전트는 개발 시스템만 수정해야 한다"는 정책은, 에이전트가 기술적으로 프로덕션에 대한 접근 권한을 가지고 있고 거기에 도달하는 것을 막는 메커니즘이 없다면 무의미합니다. AILCCP 프레임워크는 안전 작업 필터(허용 목록)와 섀도 모드 사전 실행 점검(의도된 작업과 승인된 작업을 비교하는 드라이런)을 통해 범위를 실시간으로 강제합니다.
Stanford의 결론은 직접적입니다: "상응하는 통제 구체성 없는 포괄적 위험 식별은 불을 묘사하면서 소화기를 제공하지 않는 문서를 낳는다." AILCCP 프레임워크는 원칙을 감사 가능하고 방어 가능한 메커니즘으로 변환하도록 설계된 48개의 통제를 규정합니다.
Cloud Security Alliance(2026년 1월)는 다른 경로를 통해 독립적으로 동일한 결론에 도달했습니다. CSA는 SAE J3016 차량 자동화 수준을 반영한 6단계 자율성 분류(L0~L5)를 발표했습니다. CSA의 핵심 발견: "에이전트형 AI를 배포하는 대다수 조직은 자율성 수준에 대한 공식 분류 체계가 없고, 자율성 결정을 임시방편으로 내리며, [그리고] 자율성 경계에 대한 기술적 강제가 없다." CSA는 단도직입적으로 말합니다: "'이 AI는 개발 시스템만 수정해야 한다'는 정책은, AI가 기술적으로 프로덕션에 대한 접근 권한을 가지고 있고 거기에 접근하는 것을 막는 메커니즘이 없다면 무의미하다."
세 개의 독립된 출처 — Gartner, Stanford Law CodeX, CSA — 는 동일한 결론으로 수렴합니다: 이분법적 거버넌스는 실패하고, 계층화된 종료를 갖춘 비례적 거버넌스가 표준이며, 자율성 경계의 기술적 강제가 정책과 통제의 차이라는 것입니다.
규제라는 강제 동력
EU AI 법은 2026년 8월 2일에 완전한 집행에 도달합니다 — 오늘로부터 22일 후입니다. 제14조는 고위험 AI 시스템이 실시간 정지 능력을 구현할 것을 의무화합니다. 제12조는 최소 6개월간의 로그 보존을 요구합니다. 전문 99와 100은 컴플라이언스를 멀티 에이전트 체인 내 모든 에이전트로 확장합니다. 최대 벌금은 3,500만 유로 또는 전 세계 연간 매출의 7%입니다.
Gartner, Stanford, CSA가 설명하는 계층화된 종료 시스템은 단순한 모범 사례가 아닙니다. 그것은 제14조의 정지 능력, 제12조의 로그 보존, 그리고 전문 99와 100의 멀티 에이전트 범위를 충족하는 아키텍처입니다. 컴플라이언스 기한은 거버넌스 아키텍처를 미래의 고려사항이 아니라 임박한 요구사항으로 만듭니다.
4계층 아키텍처
AILCCP 계층화된 종료 시스템은 네 개의 구체적인 구현 계층에 대응합니다. 각 계층은 테스트하고 감사하며 컴플라이언스 검토자에게 실증할 수 있는 통제입니다.
계층 1: 아이덴티티 기반 접근 게이팅
모든 도구 호출은 실행 전에 인증을 거칩니다. 에이전트는 MCP 서버에 대한 포괄적 접근 권한을 갖지 않습니다 — 자격 증명을 제시하고, 서버가 이를 검증하며, 자격 증명이 유효한 경우에만 호출이 진행됩니다.
SilvaEngine의 ai_mcp_daemon_engine에서 이것은 FlexJWTMiddleware입니다 — 모든 요청을 가로채고 Bearer 토큰을 추출하여 검증을 AWS Cognito(프로덕션 배포용) 또는 로컬 HS256 JWT 공급자(개발용)로 라우팅하는 Starlette 미들웨어입니다. 이 미들웨어는 공용 경로 목록(/auth, /health)을 유지하며, 유효한 토큰을 지니지 않은 다른 모든 요청을 401 응답으로 거부합니다. Cognito 경로는 user pool의 well-known 엔드포인트에서 HTTP/2 지원과 캐시된 JWKS 응답(TTL 구성 가능, 기본 3600초)으로 JWKS를 가져오므로, 토큰 검증이 호출마다 네트워크 왕복을 추가하지 않습니다.
이것이 AILCCP의 "아이덴티티 취소를 갖춘 에이전트 킬 스위치" — 첫 번째 게이트입니다. 에이전트의 자격 증명이 Cognito에서 취소되면, 그 에이전트의 이후 모든 도구 호출은 미들웨어에서 실패합니다. 종료는 즉각적이며 에이전트의 코드나 모듈 구성을 건드릴 필요가 없습니다. Cognito 사용자를 취소하는 것이 오작동하는 에이전트를 멈추는 가장 빠른 방법입니다.
계층 2: 도구별 서킷 브레이커와 감사 로그
모든 도구 실행은 실행 전에 호출을 기록하고 완료 후 결과로 레코드를 갱신하는 데코레이터로 감싸집니다. 레코드는 도구 이름, 입력 인수, 출력 내용, 상태(initial, completed, failed), 밀리초 단위 소요 시간, 그리고 호출자의 아이덴티티를 캡처합니다.
ai_mcp_daemon_engine에서 이것은 mcp_utility.py의 execute_decorator입니다. 도구 함수가 실행되기 전에 데코레이터는 DynamoDB에 상태 initial의 MCPFunctionCallModel 레코드를 생성하여 partition key, 도구 이름, 인수, 타임스탬프를 캡처합니다. 실행 후에는 내용, 상태 completed, 밀리초 단위 time_spent로 레코드를 갱신합니다. 도구가 예외를 발생시키면 데코레이터가 이를 잡아 레코드를 failed 상태로 갱신하고 전체 traceback을 notes 필드에 기록한 뒤 다시 던집니다.
MCPFunctionCallModel은 partition_key 해시 키와 mcp_function_call_uuid 레인지 키를 가진 DynamoDB 테이블(mcp-function_calls)에 레코드를 저장합니다. 세 개의 로컬 보조 인덱스로 MCP 유형별, 이름별, 갱신 타임스탬프별 쿼리가 가능합니다 — 그래서 운영자는 "지난 한 시간 동안 가격 책정 도구에 대한 실패한 호출을 모두 보여줘"라고 물어 단일 인덱스 쿼리로 답을 얻을 수 있습니다. DynamoDB의 400KB 항목 한도를 초과하는 내용은 자동으로 S3로 오프로드되며, content_in_s3 플래그가 해당 레코드를 표시합니다.
이것이 AILCCP의 "불변 로깅"과 "서킷 브레이커"의 결합입니다. 감사 추적은 제12조가 요구하는 컴플라이언스 증거입니다. 도구별 상태 추적은 서킷 브레이커의 기반입니다 — 도구의 실패율이 임계값을 넘으면 운영자는 에이전트의 나머지에 영향을 주지 않고 그 도구를 비활성화할 수 있습니다. MCPFunctionCallModel 레코드는 모니터링, 알림, 사고 후 재구성을 위한 데이터 소스입니다.
계층 3: 테넌트 범위 데이터 격리
모든 도구 호출은 데이터 접근을 단일 테넌트로 범위 지정하는 partition key를 지닙니다. partition key는 엔드포인트 ID와 선택적 파트 ID로부터 # 구분자로 결합되어 구성됩니다. 모든 DynamoDB 쿼리, 모든 캐시 조회, 모든 모듈 상태 작업이 이 키로 필터링됩니다. 테넌트 A를 위해 작동하는 에이전트는 partition key가 애플리케이션 계층이 아니라 데이터 계층에서 강제되기 때문에 테넌트 B의 데이터를 읽을 수 없습니다.
ai_mcp_daemon_engine에서 AIMCPDaemonEngine._apply_partition_defaults 메서드는 수신 요청의 endpoint_id와 part_id로부터 partition key를 구성하고, 이를 GraphQL 컨텍스트를 통해 모든 하위 쿼리와 뮤테이션에 전파합니다. MCPFunctionCallModel, MCPFunctionModel, MCPModuleModel, MCPSettingModel은 모두 partition_key를 해시 키로 사용합니다. 캐시 계층(CACHE_ENTITY_CONFIG와 CACHE_RELATIONSHIPS)은 모든 캐시 항목을 context:partition_key로 키잉하므로 캐시 무효화는 테넌트 범위입니다.
이것이 AILCCP의 "속도 및 범위 제한기"와 CSA의 "자율성 경계의 기술적 강제"를 하나의 메커니즘으로 결합한 것입니다. 에이전트의 영향 반경은 partition key로 제한됩니다. 개발 시스템 수정을 승인받은 수준 3 에이전트는 partition key가 다르고 파티션 간 쿼리 경로가 없기 때문에 프로덕션 시스템에 도달할 수 없습니다. 범위 제한은 정책 문서가 아니라 데이터 모델에 의해 강제됩니다.
계층 4: 신속한 롤백과 모듈 수준 비활성화
모든 MCP 모듈은 오케스트레이션 백본을 건드리지 않고 비활성화할 수 있습니다. 모듈 구성은 DynamoDB에 저장되며 런타임에 Config.fetch_mcp_configuration을 통해 로드됩니다. 모듈을 비활성화한다는 것은 그 구성 레코드를 갱신하는 것을 의미합니다 — 다음 구성 가져오기는 그것을 제외하며, 에이전트에게 반환되는 도구 목록에는 비활성화된 도구가 더 이상 포함되지 않습니다. 코드 배포도, 재시작도, 에이전트 재컴파일도 없습니다.
Config 클래스의 admin_static_token은 범위가 한정된 취소 경로를 제공합니다. 관리자 토큰을 가진 운영자는 GraphQL 뮤테이션 인터페이스를 통해 구성 변경 — 모듈 비활성화, 속도 제한 갱신, 설정 변경 — 을 발행할 수 있습니다. 이 토큰은 perm: true 클레임을 가진 정적 JWT로 만료 검사를 우회하므로, 정상적인 토큰 발급 흐름이 중단되어도 관리자 경로는 항상 사용 가능합니다.
이것이 AILCCP의 "롤백과 격리" 계층입니다. 모듈이 오작동하면 운영자의 첫 번째 조치는 구성을 통해 그것을 비활성화하는 것입니다 — 에이전트는 나머지 도구로 계속 작동하고, 비활성화된 모듈의 함수 호출은 에이전트가 폴백 경로를 통해 처리할 수 있는 오류를 반환합니다. 모듈은 (조사를 위해 구성이 보존된 채) 격리되며 에이전트를 오프라인으로 만들지 않습니다. 이것이 모든 것을 멈추는 킬 스위치와 장애를 격리하는 계층화된 종료의 차이입니다.
왜 계층들이 함께 작동하는가
각 계층은 서로 다른 장애 모드에 대처합니다:
| 장애 모드 | 계층 | 통제 | 무슨 일이 일어나는가 |
|---|---|---|---|
| 에이전트 자격 증명 유출 | 1 | 아이덴티티 기반 접근 게이팅 | Cognito 사용자 취소; 이후 모든 호출이 401 반환 |
| 도구가 잘못된 결과 생성 | 2 | 도구별 서킷 브레이커 | 도구 비활성화; 에이전트가 폴백으로 라우팅하거나 인간에게 에스컬레이션 |
| 에이전트가 미승인 데이터 접근 | 3 | 테넌트 범위 격리 | partition key가 데이터 계층에서 테넌트 간 쿼리 차단 |
| 모듈이 불규칙하게 작동 | 4 | 신속한 롤백 | 구성을 통해 모듈 비활성화; 에이전트가 나머지 도구로 계속 |
계층들은 독립적이며 조합 가능합니다. Gartner 수준 2(조언) 에이전트는 그 작업이 자문적이고 인간이 결과를 실행하므로 계층 1과 2 — 인증과 감사 로그 — 만 필요할 수 있습니다. 수준 4(자율적 행동) 에이전트는 네 계층 모두에 더해, 이상이 에스컬레이션되기 전에 이를 탐지하기 위한 감사 추적의 지속적 모니터링을 필요로 합니다.
CSA 분류는 동적 조정 차원을 추가합니다: 자율성 수준은 이상 발생 시 자동으로 낮아질 수 있다는 것입니다. 평소 수준 4에서 작동하는 에이전트는 오류율이 임계값을 초과할 때 수준 3(승인 후 행동)으로 자동 강등될 수 있습니다 — 계층 2의 서킷 브레이커 데이터가 자율성 수준 결정에 공급됩니다. 바로 여기서 계층들은 스택이 아니라 시스템이 됩니다: 감사 추적이 거버넌스 결정에 정보를 주고, 거버넌스 결정이 가드레일을 조정하며, 조정된 가드레일이 동일한 네 계층을 통해 강제됩니다.
구매 기준
Gartner의 예측 — 2027년까지 기업의 40%가 에이전트를 폐기 — 에는 구매자용 번역이 있습니다. 에이전트 벤더가 이 네 가지 질문에 답하지 못한다면, 그들에게는 거버넌스 모델이 없는 것입니다:
귀사의 에이전트는 어떤 자율성 수준에서 작동합니까? 답이 "경우에 따라" 또는 "완전 자율"이라면 분류 체계가 없는 것입니다. CSA는 대다수 조직이 공식 분류를 갖고 있지 않음을 발견했습니다.
오작동하는 에이전트를 어떻게 종료합니까? 답이 "프로세스를 멈춘다" 또는 "코드에서 도구를 제거한다"라면 계층화된 종료가 없는 것입니다. 에이전트를 배포 없이 비활성화할 수 없으며, 이는 대응 시간이 초가 아니라 시간 단위로 측정됨을 의미합니다.
최근 100회 도구 호출의 감사 추적을 보여줄 수 있습니까? 답이 "CloudWatch에 로그가 있다"라면 구조화된 도구별 감사 레코드가 없는 것입니다. 감사 추적은 로그 스트림에서 grep 할 수 있는 것이 아니라 도구 이름, 상태, 시간 범위로 쿼리 가능해야 합니다.
한 테넌트의 에이전트가 잘못되면 영향 반경은 얼마입니까? 답이 "배포 단위로 격리한다"라면 데이터 계층의 테넌트 격리가 없는 것입니다. 영향 반경은 단일 테넌트가 아니라 배포 전체입니다.
4계층 아키텍처는 정책 선언이 아니라 구체적 메커니즘으로 각 질문에 답합니다. 그것이 불을 묘사하는 것과 소화기를 제공하는 것의 차이입니다.
NetSuite, BigCommerce, 세 개의 공급업체 카탈로그를 운영하는 유통업체는 Gartner 수준 3의 에이전트를 배포합니다: 견적에 가격을 매기고 재고를 보유하며 승인된 주문을 NetSuite에 기록합니다 — 단, 임계값을 초과하는 모든 가격 책정 작업은 인간 승인을 필요로 하며, 모든 도구 호출은 partition key, 도구 이름, 인수 해시, 소요 시간과 함께 기록됩니다. 어느 공급업체 카탈로그 모듈이 일관되지 않은 가용성 데이터를 반환하기 시작하면, 운영자는 구성을 통해 그 모듈을 비활성화합니다. 에이전트는 폴백 카탈로그로 라우팅하고, 비활성화된 모듈의 최근 호출은 조사를 위해 감사 추적에서 조회되며, 에이전트는 전 과정 동안 온라인을 유지합니다. 그 빌드는 4단계 방법론의 24단계이며, 일반적으로 58주 안에 가동됩니다.
범위가 정해진 구축을 요청하세요. 1주일 디스커버리. 시스템 인벤토리, 워크플로 맵, 고정 범위를 얻습니다 — 저희와 구축하든 하지 않든.
귀하의 시스템을 위해 이것을 구축하고 싶으신가요?
여기의 각 문서는 실제 프로덕션 작업에서 나왔습니다. 대상 시스템과 워크플로가 있다면, 1주 내에 빌드를 범위 정의할 수 있습니다.
범위 정의 빌드 요청1주 발견. 시스템 인벤토리, 워크플로 맵, 고정 범위를 받습니다 — 우리와 빌드할지 여부와 관계없이.