AI 에이전트는 확장하기 전에 제어 플레인이 필요하다

Google News는 엔터프라이즈 리더들에게 단호한 경고를 제시했다. 조직이 AI 에이전트를 안전하게 확장하려면 먼저 제어 플레인이 필요하다는 것이다. 이제 쟁점은 자율성과 인간 노동의 대립이 아니다. 빠른 에이전트 배포와 자율적 행동을 가시적이고 제한 가능하며 되돌릴 수 있게 유지하는 데 필요한 통제 장치의 대립이다.

이 구분이 중요한 이유는 AI 에이전트가 단순히 텍스트를 생성하는 데 그치지 않기 때문이다. 에이전트는 기업 데이터를 조회하고, 소프트웨어 도구를 호출하며, 기록을 업데이트하고, 제한적인 감독 아래 워크플로를 실행할 수 있다. 기능이 하나 추가될 때마다 모델의 응답은 잠재적인 비즈니스 행동으로 바뀐다.

최근 Google News 보도는 엔터프라이즈 기술 전반의 더 폭넓은 변화를 포착한다. Microsoft, IBM, Salesforce, Databricks, AWS는 모두 에이전트 플랫폼의 중심에 거버넌스를 더 가깝게 배치하고 있다. 이들의 경쟁은 이제 가장 똑똑한 모델을 제공하는 기업이 누구인가뿐 아니라, 에이전트를 누가 통제하는가에 관한 것이다.

AI 에이전트 경쟁은 파일럿에서 통제로 이동했다

중요한 변화는 에이전트 거버넌스가 정책 문서가 아니라 하나의 제품 범주가 되었다는 점이다.

초기 엔터프라이즈 AI 프로젝트는 일반적으로 승인된 데이터 위에 대화형 인터페이스를 올려놓는 방식이었다. 보안 팀은 모델 접근, 데이터 보존, 직원들이 민감한 정보를 공개 서비스에 붙여넣는지 여부에 집중할 수 있었다.

에이전트는 이러한 위험 경계를 확장한다. 하나의 작업 중 여러 시스템을 연결하고, 도구를 선택하며, 계획을 수립하고, 확률적 출력에 따라 단계를 실행할 수 있다. 허용된 행동도 잘못된 순서로 이뤄지면 받아들일 수 없는 결과를 낳을 수 있다.

재고를 읽고, 공급업체에 연락하며, 주문을 생성할 수 있는 구매 에이전트를 생각해 보자. 각 권한은 개별적으로는 정당할 수 있다. 그러나 결합된 워크플로는 여전히 주문을 중복 생성하거나, 승인되지 않은 공급업체를 선택하거나, 기밀 수요 예측을 노출할 수 있다.

이 때문에 제어 플레인이 논의의 중심이 됐다. 에이전트 제어 플레인은 에이전트를 등록하고, ID를 할당하며, 정책을 시행하고, 행동을 모니터링하고, 수명 주기를 관리하기 위한 공유 시스템이다.

IBM은 이 개념을 조직 전반에서 에이전트를 배포, 운영, 모니터링, 관리할 수 있는 시스템으로 설명한다. IBM의 agent control plane은 비즈니스 시스템과 다단계 워크플로 전반에서 에이전트를 조율하기도 한다.

제어 플레인은 애플리케이션 보안이나 모델 안전장치를 대체하지 않는다. 서로 다른 에이전트, 모델, 도구, 비즈니스 애플리케이션 위에 공통 운영 계층을 제공한다. 이 계층은 에이전트가 행동하기 전에 기본적인 질문에 답할 수 있어야 한다.

이 에이전트의 소유자는 누구인가? 어떤 데이터를 조회할 수 있는가? 어떤 도구를 호출할 수 있는가? 어떤 지출 한도가 적용되는가? 어떤 행동에 승인이 필요한가? 관리자는 어떻게 워크플로를 중단하거나 되돌릴 수 있는가?

많은 파일럿은 이러한 질문에 맞춤형 코드 내부에서 답한다. 그러나 서로 다른 팀이 각기 다른 클라우드, 소프트웨어 플랫폼, 개발 프레임워크를 통해 에이전트를 배포하면 이 접근 방식은 취약해진다.

재무 부서는 엔터프라이즈 애플리케이션 안에서 에이전트를 도입할 수 있다. 개발자는 오픈 프레임워크로 또 다른 에이전트를 구축할 수 있다. 직원들은 보안 팀에 알리지 않은 채 로우코드 도구로 에이전트를 만들 수도 있다.

이는 관리되지 않는 클라우드 서비스와 소프트웨어 계정이 과거에 늘어났던 양상과 유사한 에이전트 난립을 초래한다. 차이는 에이전트가 지속적으로, 그리고 기계 속도로 행동할 수 있다는 점이다.

따라서 Google News의 헤드라인은 또 하나의 거버넌스 논쟁 이상의 의미를 지닌다. 이는 아키텍처의 변화를 반영한다. 엔터프라이즈는 에이전트가 수적으로 늘어나거나 깊게 연결되기 전에 이들을 운영 주체로 다루는 관리 계층이 필요하다.

Google News가 지금 거버넌스를 가리키는 이유

에이전트 도입은 자율 소프트웨어를 식별, 모니터링, 제약하는 시스템보다 빠르게 진행되고 있다.

압력은 두 방향에서 온다. 비즈니스 팀은 애플리케이션 경계를 넘나드는 자동화를 원한다. 기술 리더는 보이지 않는 소프트웨어 ID 집단을 만들지 않으면서 이 수요를 지원해야 한다.

전통적인 ID 시스템은 사람이 로그인하고, 권한을 부여받으며, 세션에 대한 책임을 진다는 가정에 기반한다. 에이전트는 사람, 애플리케이션, 부서 또는 다른 에이전트를 대신해 작동할 수 있기 때문에 이 모델을 복잡하게 만든다.

에이전트는 작업을 위임할 수도 있다. 상위 에이전트는 전문 에이전트에게 기록 검색, 문서 분석, 시스템 업데이트를 요청할 수 있다. 이 사슬은 소유권과 책임 소재를 추적하기 어렵게 만든다.

Microsoft는 이 문제를 ID 난립에 비유했다. Microsoft의 control plane guidance는 과도한 권한이 실수, 과도한 공유, 의도치 않은 데이터 노출로 인한 피해를 키울 수 있다고 경고한다.

ID만으로는 충분하지 않다. 제어 플레인은 에이전트가 무엇을 시도했는지, 어떤 리소스에 접근했는지, 각 도구 호출 후 어떤 일이 일어났는지도 기록해야 한다. 이 이력이 없으면 팀은 장애를 재구성할 수 없다.

관측성이란 에이전트가 생성하는 추적 정보, 이벤트, 비용, 결과를 수집하는 것을 뜻한다. 동일한 입력이 항상 동일한 계획을 생성하지 않을 때 특히 중요해진다.

기존 소프트웨어는 대개 개발자가 미리 정의한 경로를 따른다. 반면 에이전트는 목표를 해석하고 런타임에 단계를 선택한다. 따라서 모니터링은 애플리케이션 가용성뿐 아니라 의사결정과 행동도 포착해야 한다.

비용도 또 다른 압박 요인이다. 에이전틱 워크플로는 여러 모델을 호출하고, 복수의 데이터 저장소를 검색하며, 유료 서비스를 실행할 수 있다. 루프나 제대로 제한되지 않은 작업은 유용한 결과를 내지 못한 채 리소스를 소비할 수 있다.

CIO Dive는 에이전트 도입이 엔터프라이즈 워크플로 전반으로 확산되면서 Salesforce와 Databricks가 거버넌스 기능을 추가했다고 보도했다. governance rollouts에는 모델 접근, API 사용, 내부 시스템, 로깅, 비용 추적을 위한 통제가 포함됐다.

같은 보도에 따르면 AWS도 에이전트를 위한 중앙 집중식 레지스트리를 도입했다. 레지스트리는 배포된 에이전트와 연관 메타데이터의 인벤토리를 만들어 기본적인 발견 문제를 해결한다.

인벤토리는 필요하지만 충분하지는 않다. 목록만으로는 에이전트가 권한 없는 도구를 호출하는 것을 막을 수 없다. 특정 거래에 사람의 승인이 필요한지도 판단할 수 없다.

더 강력한 모델은 등록과 런타임 시행을 결합한다. 런타임 시행은 에이전트가 작동하는 동안, 연결된 시스템이 요청을 수락하기 전에 행동을 평가한다.

이 때문에 현재의 변화가 중요하다. 거버넌스는 정기 검토에서 지속적 통제로 옮겨가고 있다. 정책은 모델, 도구, 환경을 넘나들며 에이전트와 함께 이동해야 한다.

Google News를 통해 드러난 논의가 시의적절한 이유는 엔터프라이즈가 지금 이 경계에 다가가고 있기 때문이다. 파일럿은 분절된 통제로도 버틸 수 있다. 운영 단계의 포트폴리오는 그렇지 못하다.

핵심 경쟁은 중앙 통제와 플랫폼 종속의 대립이다

엔터프라이즈는 에이전트 전체를 한눈에 볼 필요가 있지만, 주요 벤더들은 자사 플랫폼이 그 관점의 중심이 되기를 원한다.

통합 제어 플레인은 일관된 ID, 정책, 로그, 승인, 비용 보고를 약속한다. 모든 개발 팀이 이런 기능을 독립적으로 구축할 필요를 줄일 수 있다.

그러나 엔터프라이즈는 단일 에이전트 플랫폼만 운영하는 경우가 드물다. 여러 클라우드, 소프트웨어 제품군, 모델, 내부 프레임워크를 사용한다. 인수합병과 부서별 구매는 변동성을 더욱 키운다.

이 때문에 핵심 아키텍처 질문은 피할 수 없다. 거버넌스는 각 에이전트 플랫폼 내부에 있어야 하는가, 아니면 독립 계층이 벤더 전반의 에이전트를 관리해야 하는가?

플랫폼 네이티브 통제는 에이전트가 작동하는 애플리케이션과 긴밀하게 통합될 수 있다. Salesforce 에이전트는 Salesforce 기록, 권한, 워크플로에서 컨텍스트를 상속할 수 있다. 클라우드 네이티브 에이전트는 제공업체의 ID 및 모니터링 서비스를 사용할 수 있다.

이러한 통합은 구현 작업을 줄인다. 하지만 다른 부서가 다른 플랫폼을 선택하면 거버넌스 섬이 생긴다. 보안 팀은 정의가 호환되지 않고 범위가 불완전한 여러 대시보드를 받게 될 수 있다.

Salesforce는 확장된 Agent Fabric을 멀티벤더 환경을 위한 제어 플레인으로 포지셔닝했다. 여기에는 에이전트 발견, 결정론적 오케스트레이션, 모델 거버넌스가 포함된다.

결정론적 오케스트레이션은 모델이 모든 행동을 선택하게 두는 대신, 중요한 워크플로 단계에 사전 정의된 규칙을 사용한다. 승인, 거래 한도, 필수 점검을 확률적 추론의 바깥에 둘 수 있다.

IBM도 비슷하게 폭넓은 입장을 취했다. IBM의 Agentic Control Plane은 watsonx Orchestrate를 통해 프레임워크와 환경 전반의 에이전트를 관리하도록 설계됐다.

독립적인 보안 및 관측성 벤더는 또 다른 경로를 제시한다. 이들은 에이전트와 엔터프라이즈 시스템 사이에 위치해 도구 호출을 검사하고, 정책을 시행하며, 여러 개발 스택 전반의 활동을 기록할 수 있다.

각 접근 방식에는 절충점이 있다. 네이티브 통제는 더 깊은 통합을 제공하지만 한 벤더에 대한 의존도를 높일 수 있다. 독립적 통제는 더 넓은 범위를 제공하지만 팀이 통합하고 유지해야 할 또 하나의 계층을 추가한다.

해답은 실제로 권한이 어디에 있는지에 따라서도 달라진다. 대시보드는 에이전트를 통제하지 않고도 관찰할 수 있다. 레지스트리는 에이전트의 행동을 제한하지 않고도 식별할 수 있다.

신뢰할 만한 제어 플레인에는 시행 지점이 필요하다. 도구 호출을 거부하고, 승인을 요청하며, 권한을 축소하고, ID를 일시 중지하거나, 워크플로를 중단할 수 있어야 한다.

또한 타사 구성 요소도 다뤄야 한다. 엔터프라이즈 에이전트는 외부 모델, 커넥터, 플러그인, 데이터 서비스에 자주 의존한다. 자사 벤더의 구성 요소만 보는 제어 플레인은 불완전한 위험 그림을 제공한다.

비용 보고도 같은 문제에 직면한다. 하나의 워크플로는 한 벤더의 에이전트, 다른 제공업체의 모델, 별도의 검색 서비스를 사용할 수 있다. 분절된 청구는 완전한 비즈니스 결과의 비용을 가린다.

이 경쟁은 CIO와 보안 리더에게 압박을 가한다. 에이전트 플랫폼을 선택한다는 것은 점점 더 ID, 정책, 텔레메트리, 재무 거버넌스를 위한 운영 모델을 선택한다는 의미가 되고 있다.

이 결정은 기능 체크리스트에서 시작해서는 안 된다. 조직의 최고 위험 워크플로와 에이전트가 접근해야 하는 시스템에서 시작해야 한다.

고객 지원 요약은 환불을 발행하는 에이전트와 다른 결과를 초래한다. 리서치 어시스턴트는 운영 인프라를 변경하는 에이전트와 다른 위험 프로필을 가진다.

유용한 질문은 벤더가 거버넌스를 제공하는지 여부가 아니다. 거의 모든 벤더가 그렇게 주장할 것이다. 구매자는 제품이 전체 워크플로 전반에서 어떤 행동을 관찰하고, 중단하고, 승인하며, 재구성할 수 있는지 물어야 한다.

일률적인 가드레일은 또 다른 실패를 만들 수 있다

중앙 통제는 에이전트의 자율성이나 영향과 무관하게 모두에게 동일한 제한을 적용할 때 역효과를 낸다.

하나의 제어 플레인에 대한 요구는 오해를 부를 수 있다. 하나의 정책이 모든 에이전트를 관리해야 한다는 생각이다. 이 접근 방식은 관리를 단순화하지만, 에이전트 역할 간의 중요한 차이를 무시한다.

Gartner는 2026년 5월 모든 에이전트에 일률적인 거버넌스를 적용하면 엔터프라이즈 배포가 실패할 수 있다고 경고했다. Gartner의 governance framework는 에이전트의 자율성, 민감도, 범위에 따라 달라지는 통제를 요구한다.

읽기 전용 접근 권한을 가진 요약 에이전트는 자금을 이체하는 에이전트와 동일한 승인 절차가 필요하지 않다. 둘을 똑같이 취급하면 저위험 워크플로에 과도한 부담을 주거나 고위험 워크플로를 충분히 보호하지 못할 수 있다.

이는 핵심적인 트레이드오프를 드러낸다. 기업에는 공통된 통제가 필요하지만, 공통된 위험을 전제해서는 안 된다.

유용한 아키텍처는 모든 에이전트 전반에 걸쳐 ID, 인벤토리, 로깅, 소유권을 표준화할 수 있다. 그다음 자율성과 잠재적 영향이 커질수록 더 강력한 통제를 적용해야 한다.

저위험 에이전트는 일반적인 로깅과 정기적 평가만으로 운영될 수 있다. 중간 위험 에이전트에는 범위가 제한된 권한, 지출 한도, 비정상적 행동에 대한 알림이 필요할 수 있다.

고위험 에이전트에는 결정론적 검증, 이중 승인, 제한된 실행 환경, 즉각적인 중지 제어가 필요할 수 있다. 일부 행동은 자율 소프트웨어에 계속 허용되지 않아야 한다.

바로 이 지점에서 많은 벤더의 주장은 면밀한 검토가 필요하다. 가시성이 안전을 보장하지는 않는다. 정책 설정이 집행을 보장하지는 않는다. 감사 추적이 되돌릴 수 없는 행동을 막지는 못한다.

평가 결과에도 한계가 있다. 고정된 프롬프트 집합으로 에이전트를 테스트하면 이미 알려진 취약점을 드러낼 수 있다. 하지만 프로덕션 환경에는 변화하는 데이터, 도구, 사용자 목표, 그리고 다른 에이전트와의 상호작용이 존재한다.

공격자는 이러한 연결고리를 악용할 수 있다. 프롬프트 인젝션은 문서, 이메일, 웹페이지 등 에이전트가 가져오는 콘텐츠 안에 악의적인 지시를 삽입한다. 에이전트는 숨겨진 지시를 자신의 작업 일부로 받아들일 수 있다.

모델 수준의 필터가 도움이 될 수는 있지만, 더 안전한 경계는 행동을 둘러싼 곳에 있다. 에이전트가 조작되더라도 비밀을 노출하거나 승인되지 않은 거래를 실행할 권한을 얻어서는 안 된다.

사람의 승인도 또 다른 복잡성을 낳는다. 모든 행동에 사람의 승인을 요구하면 자동화의 가치 상당 부분이 사라진다. 길고 빈번한 요청을 검토하도록 요구하는 일 역시 승인 피로를 만든다.

제어 플레인은 중대한 의사결정에만 사람의 개입을 남겨두어야 한다. 저위험 행동은 집행 가능한 정책을 따를 수 있고, 불확실하거나 민감한 행동은 검토 절차로 넘어가야 한다.

에이전트가 실패했을 때 조직에는 명확한 책임 구조도 필요하다. 배포된 각 에이전트에 소유자를 지정하는 일은 필수적이지만, 책임이 개발팀에서 끝나서는 안 된다.

비즈니스 리더는 허용 가능한 결과를 정의한다. 보안팀은 접근 제어를 수립한다. 법무 및 컴플라이언스 팀은 의무를 해석한다. 기술팀은 공유 인프라를 운영한다.

이러한 책임 분담은 거버넌스를 단순한 소프트웨어 구매가 아닌 운영 모델로 만든다. 제어 플레인은 의사결정을 집행할 수 있지만, 사람은 먼저 그 의사결정을 정확하게 정의해야 한다.

따라서 Google News의 서사를 비판적으로 읽을 필요가 있다. 중앙화된 대시보드를 구매한다고 해서 에이전트 운영이 안전해지는 것은 아니다. 시스템은 차등화된 통제, 실제 집행, 책임 있는 소유권을 지원해야 한다.

실효성 있는 제어 플레인에는 집행 가능한 다섯 개 계층이 필요하다

이 아키텍처는 에이전트 ID를 모든 행동, 결과, 책임 소유자와 연결할 때에만 성공한다.

첫 번째 계층은 인벤토리다. 모든 프로덕션 에이전트에는 소유자, 목적, 프레임워크, 모델 의존성, 데이터 접근 권한, 도구, 배포 상태를 담은 고유한 기록이 필요하다.

발견 범위에는 중앙 IT 외부에서 만들어진 에이전트도 포함되어야 한다. 그렇지 않으면 인벤토리는 승인된 프로젝트 목록에 그치고, 섀도 에이전트는 감독 없이 계속 운영된다.

두 번째 계층은 ID 및 접근 관리다. 에이전트에는 제한적이고 일시적이며 작업별로 특화된 권한을 받을 수 있는 비인간 ID가 필요하다.

직원의 자격 증명을 공유하면 책임성이 사라진다. 또한 해당 작업에 좁은 범위의 행동 하나만 필요하더라도 에이전트에 그 직원이 보유한 모든 권한을 부여하게 된다.

권한은 최소 권한 원칙을 따라야 하며, 이는 할당된 업무에 필요한 접근만 부여한다는 뜻이다. 수명이 짧은 자격 증명은 탈취된 토큰이나 방치된 에이전트로 인해 발생하는 노출을 추가로 줄일 수 있다.

세 번째 계층은 정책 집행이다. 정책은 실행 전에 도구 호출, 데이터 접근, 거래, 위임을 평가해야 한다.

예를 들어 한 정책은 민감한 기록이 포함된 내보내기를 차단할 수 있다. 다른 정책은 구매 금액이 정해진 한도를 넘을 때 승인을 요구할 수 있다. 또 다른 정책은 에이전트가 고객 데이터를 외부 모델과 결합하지 못하게 할 수 있다.

네 번째 계층은 관측성이다. 팀에는 최초 요청, 에이전트의 계획, 모델 호출, 검색된 컨텍스트, 도구 활동, 비용, 승인, 최종 결과를 연결하는 추적 정보가 필요하다.

이러한 기록은 인시던트 대응과 성능 분석을 지원한다. 또한 작업은 완료하지만 과도한 비용, 반복 오류, 또는 숨겨진 수동 정리를 초래하는 에이전트를 드러낸다.

다섯 번째 계층은 라이프사이클 관리다. 조직은 통제된 프로세스를 통해 에이전트를 테스트, 배포, 업데이트, 중단, 폐기할 수 있어야 한다.

모델과 도구는 배포 후에도 바뀐다. 한 구성에서 평가를 통과한 에이전트라도 커넥터, 프롬프트, 모델, 권한이 변경되면 다르게 행동할 수 있다.

라이프사이클 통제는 중요한 의존성이 바뀔 때 새로운 평가를 촉발해야 한다. 또한 에이전트가 폐기될 때 자격 증명과 통합을 제거해야 한다.

이 계층들은 에이전트가 내부 지식과 상호작용할 때 더 큰 가치를 발휘한다. 신뢰할 수 있는 AI knowledge base는 검색을 개선할 수 있지만, 접근에는 여전히 역할과 작업에 기반한 경계가 필요하다.

더 나은 컨텍스트가 통제의 필요성을 없애지는 않는다. 오히려 에이전트가 어떤 문서를 검색했는지, 그리고 그 문서가 왜 행동에 영향을 주었는지를 아는 일이 더 중요해진다.

같은 원칙은 에이전트 메모리에도 적용된다. 영속적 메모리는 에이전트가 작업 전반에서 컨텍스트를 유지하도록 도울 수 있다. 하지만 민감한 세부 정보, 오래된 지시, 잘못된 가정도 보존할 수 있다.

따라서 메모리에는 보존 규칙, 접근 제어, 삭제 경로가 필요하다. 사용자는 에이전트가 현재 세션 이후에도 정보를 저장하는 시점을 알아야 한다.

팀은 개별 모델 응답이 아니라 전체 워크플로를 대상으로 이러한 계층을 테스트해야 한다. 에이전트가 금지된 데이터를 사용했거나 승인되지 않은 변경을 남겼다면, 성공적인 답변은 의미가 없다.

시나리오 테스트에는 일반적인 실수, 악의적 입력, 사용할 수 없는 도구, 비용 급증, 권한 실패, 에스컬레이션이 필요한 요청이 포함되어야 한다. 또한 관리자가 활동을 신속히 중지할 수 있는지도 테스트해야 한다.

이러한 운영 중심 접근은 실제 제어 플레인과 거버넌스 쇼를 구분한다. 시스템은 유용한 자동화에 필요한 유연성을 충분히 보존하면서도 행동을 제약해야 한다.

통제가 따라갈 수 있는지는 세 가지 신호가 보여줄 것이다

다음 단계는 크로스 플랫폼 집행, 측정 가능한 프로덕션 결과, 그리고 차등화된 거버넌스가 작동한다는 증거로 결정될 것이다.

첫 번째 신호는 벤더 제어 플레인이 자체 생태계를 넘어 에이전트를 관리하는지 여부다. 제품 발표는 이미 멀티벤더 가시성을 약속하고 있지만, 기업에는 실제 배포를 통한 증명이 필요하다.

클라우드, 모델, 소프트웨어 플랫폼 전반에서 ID, 정책, 텔레메트리를 보존하는 커넥터를 주목해야 한다. 제어 플레인은 단순히 표시하는 데 그치지 않고 타사 행동을 중단할 수 있을 때 더 신뢰할 수 있다.

강력한 크로스 플랫폼 지원은 거버넌스가 공유된 엔터프라이즈 계층이 될 수 있다는 주장을 뒷받침할 것이다. 지원이 약하면 고객은 여러 제어 시스템을 관리하고 그 격차를 수동으로 조정해야 한다.

두 번째 신호는 조직이 에이전트 수와 함께 비즈니스 성과를 보고하는지 여부다. 배포 수치는 활동을 보여주지만, 에이전트가 유용한 작업을 안전하게 완료하는지는 보여주지 않는다.

유용한 측정 지표로는 성공적인 작업 완료, 사람에 의한 에스컬레이션 비율, 롤백 빈도, 정책 위반, 전체 워크플로 비용, 에이전트 결과를 수정하는 데 드는 시간이 있다.

IBM의 2026년 기술 리더십 연구는 포트폴리오 관리가 AI 예산을 늘리지 않고도 에이전트 배포를 개선할 수 있다고 주장한다. 해당 technology leader study는 실시간 지출 가시성의 격차도 강조한다.

실패 비용 감소와 수동 개입 감소에 대한 증거는 제어 플레인의 필요성을 강화할 것이다. 성과 데이터 없이 에이전트 수만 증가한다면, 실험이 여전히 운영 성숙도를 앞서고 있음을 시사할 것이다.

세 번째 신호는 조직이 하나의 보편적 정책 대신 위험 기반 통제를 채택하는지 여부다. 이를 위해서는 자율성, 데이터 민감도, 잠재적 영향에 따라 에이전트를 분류할 수 있는 제품이 필요하다.

이러한 분류를 기술적 집행과 연결하는 참조 아키텍처를 살펴봐야 한다. 고위험 행동에는 더 강력한 승인, 격리, 로깅, 복구 요건이 적용되어야 한다.

성공적인 차등화 거버넌스는 일률적 통제에 대한 Gartner의 경고에 답할 수 있다. 중앙화된 관리가 동일한 제한을 요구하지는 않는다는 점을 보여줄 것이다.

이 지점에서 실패하면 전체 모델이 약화된다. 조직은 과도한 검토로 무해한 에이전트를 늦추거나, 단순한 보조 도구용으로 설계된 통제에 중대한 워크플로를 노출하게 될 것이다.

Google News의 프레이밍은 엔터프라이즈 구매자에게 유용한 출발점을 제공하지만, 제어 플레인도 자신이 관리하는 에이전트와 동일한 수준의 검증을 받아야 한다. 구매자에게는 집행, 이식성, 측정 가능한 위험 감소의 증거가 필요하다.

기술 리더는 플랫폼을 선택하기 전부터 시작할 수 있다. 이미 사용 중인 에이전트를 목록화하고, 소유자를 식별하며, 도구 접근 권한을 매핑하고, 실패의 결과를 분류하라.

그다음 중대한 워크플로 하나를 선택해 전체 제어 체인을 테스트하라. 조직이 에이전트를 식별하고, 권한을 제한하고, 행동을 검토하고, 실행을 중단하고, 결과를 재구성할 수 있는지 검증하라.

플랫폼이 등록할 수 있는 에이전트 수로 준비도를 측정하지 마라. 가장 위험한 행동을 예방하고, 승인하고, 추적하고, 되돌릴 수 있는지로 측정하라.

다음 Google News 헤드라인은 아마 또 다른 대형 에이전트 출시를 다룰 것이다. 그 경쟁에 합류하기 전에 더 어려운 질문을 던져야 한다. 시연이 끝난 뒤 에이전트가 하는 일을 조직이 보고 멈출 수 있는가?