Google Cloud, AI 위협 방어를 이사회 핵심 기준으로 제시

Google Cloud는 AI 위협 방어를 이사회 의제로 끌어올리며, 기계 속도로 작동하는 자동화 공격에 수동적 감독만으로는 대응할 수 없다고 주장했다.

이는 단순한 새로운 보안 홍보 문구 이상의 변화다. Google은 이사들이 자동화 방어를 CISO에게 위임하는 또 하나의 기술 비용이 아니라 비즈니스 성장을 위한 인프라로 여겨야 한다고 본다.

이 주장은 어려운 균형 문제를 낳는다. 이사회는 더 빠른 AI 도입을 원하지만, 그 속도를 뒷받침하는 자동화 자체가 불투명한 의사결정, 과도한 접근 권한, 검증되지 않은 복구 조치를 초래할 수 있다.

Google의 해법은 AI 네이티브, 에이전트 기반, 개방형 방어 전략에 초점을 맞춘다. 이 플랫폼은 자동 탐지, 맥락 기반 위험 분석, 코드 복구, 지속적 모니터링을 결합한다.

회사는 이러한 접근법이 보안 팀이 모든 AI 프로젝트의 속도를 늦추지 않으면서 자동화 위협에 대응할 수 있게 한다고 말한다. 그러나 이사회는 더 빠른 자동화가 단지 활동 속도만 높이는 것이 아니라 실제로 더 안전한 결과를 낳는다는 증거를 여전히 요구해야 한다.

이 구분이 중요한 이유는 Google이 진단과 플랫폼을 모두 판매하고 있기 때문이다. 이사들은 거버넌스 프레임워크의 가치를 특정 제품에 대한 주장과 분리해 판단해야 한다.

Google Cloud, 보안 출시를 거버넌스 의무로 전환하다

핵심 변화는 Google Cloud가 이제 자동화 위협 방어를 이사회 차원의 운영 요건으로 규정한다는 점이다.

Google Cloud의 CISO인 Chris Betz와 CISO Office의 시니어 디렉터 Alicja Cade는 2026년 7월 31일 이 주장을 제시했다. 이들의 이사회 가이드는 회사의 Cloud CISO Perspectives 뉴스레터에 실렸다.

이들은 주요 비즈니스 이니셔티브마다 AI 구성 요소가 포함되는 경우가 점점 늘고 있다고 주장한다. 따라서 각 이니셔티브는 이에 상응하는 속도로 운영할 수 있는 보안 기반에 의존하게 된다.

이러한 관점은 보안 거버넌스를 제품 출시와 직접 연결한다. 방어 준비 상태를 검토하지 않은 채 공격적인 AI 투자를 승인하는 이사회는 비즈니스 속도와 통제 속도 간의 불일치를 감수하는 셈이다.

Google은 5월 27일 더 광범위한 AI Threat Defense 플랫폼을 공개했다. 회사는 이를 기업 환경을 준비하고, 스캔하며, 우선순위를 정하고, 복구하고, 모니터링하는 상시 가동 시스템으로 설명한다.

이 아키텍처는 Gemini 및 기타 모델을 Wiz의 위험 맥락, CodeMender의 복구 기능, Mandiant의 위협 전문성과 결합한다. Google은 이 플랫폼이 공격 경로를 예측하고 실제 비즈니스 영향을 기준으로 노출의 우선순위를 정한다고 말한다.

두 달 뒤, 회사는 논의를 보안 운영 센터를 넘어서는 수준으로 끌어올리고 있다. 7월 가이드는 이사회가 비즈니스 지원, 복구, 통합, 맥락 기반 우선순위 설정, AI 정책이라는 다섯 가지 영역을 평가할 것을 요청한다.

이 질문들은 추상적인 감독을 기대되는 운영 성과로 바꾼다. 이사들은 투자가 제품 출시 기간을 단축하는지, 복구 시간을 줄이는지, 워크플로를 통합하는지, 오탐을 제한하는지, 내부 AI 사용을 통제하는지 물어야 한다.

이는 이사들이 모델을 선택하거나 보안 도구를 구성하라는 요청이 아니다. Google은 실행 책임을 경영진, 기술 리더, 보안 팀에 명시적으로 맡긴다.

대신 이사회는 자동화가 확장될 수 있는 조건을 수립해야 한다. 여기에는 경영진이 어떤 성과를 보고할지, 어디까지 사람의 승인이 필수로 남을지, 예외 사항이 어떻게 이사회에 보고될지를 결정하는 일이 포함된다.

규제 환경은 이미 사이버보안을 이사회 감독 범위에 포함하고 있다. SEC는 상장사가 중대한 사이버 위험을 관리하는 절차를 설명하고 이사회의 감독 역할을 밝혀야 한다고 요구한다.

중대한 사이버 사고는 일반적으로 기업이 중요성을 판단한 후 영업일 기준 4일 이내에 공시해야 한다. 이 기한은 분산된 소유권과 불분명한 에스컬레이션 경로를 단순한 운영상 불편을 넘어서는 문제로 만든다.

Google은 이러한 기존 책임을 AI 특화 방어로 확장하고 있다. 회사의 입장은 이사회가 모델, 데이터, 애플리케이션, ID를 보호하는 시스템과 AI 도입을 분리해 관리할 수 없다는 것이다.

이것이 이 글의 핵심 긴장을 만든다. 자동화 방어는 비즈니스 속도를 약속하지만, 시스템이 위험을 잘못 분류하거나 우선순위를 정하거나 복구할 때 더 강력한 자동화는 더 명확한 책임 소재도 요구한다.

따라서 이사들은 두 가지를 동시에 판단해야 한다. 조직이 충분히 빠르게 움직이는지, 그리고 압박 상황에서도 통제가 이해 가능한 상태로 유지되는지를 평가해야 한다.

Google Cloud가 수동 방어가 한계에 이르렀다고 말하는 이유

Google Cloud의 주장은 자동화 공격자와 수동 대기열 중심으로 구성된 보안 팀 사이의 속도 격차가 커지고 있다는 데서 출발한다.

기존의 취약점 관리에서는 발견, 우선순위 설정, 배정, 패치, 검증, 모니터링이 분리되는 경우가 많다. 각 인계 단계는 지연을 만들고 맥락을 잃게 한다.

자동화 공격자는 이러한 조직적 제약을 공유하지 않는다. AI 에이전트는 주간 검토 회의를 기다리지 않고도 표적을 스캔하고, 가설을 시험하며, 변형을 생성하고, 행동을 반복할 수 있다.

Google은 과거에는 수주가 걸리던 공격이 이제 몇 시간 또는 며칠 안에 전개될 수 있다고 말한다. 이는 변화하는 위협 환경에 관한 회사의 주장이나, 그 운영상 함의는 신빙성이 있다.

팀은 사람의 백로그에 티켓을 더 추가하는 방식으로 기계 속도의 탐색에 대응할 수 없다. 대기열이 감당하기 어려워지기 전에 결과를 필터링하고, 검증하고, 전달하며, 때로는 복구하는 자동화가 필요하다.

이 때문에 Google은 평균 복구 시간, 즉 MTTR을 강조한다. 이 지표는 조직이 발견된 노출이나 운영 문제를 해결하는 데 걸리는 시간을 추적한다.

이사회가 모든 티켓을 모니터링할 필요는 없다. 하지만 핵심 시스템의 MTTR이 개선되는지, 더 빠른 복구가 용납하기 어려운 운영 장애를 일으키지는 않는지는 알아야 한다.

Google은 맥락 기반 접근 방식의 사례로 Morgan Stanley를 제시한다. Google에 따르면 이 은행은 Google Cloud 및 Wiz와 협력해 분산된 도구를 통합 워크플로로 대체했다.

회사는 Morgan Stanley가 위협 탐지 시간을 99.9% 줄여 45분에서 90초 이하로 단축했다고 말한다. 독자들은 이 결과를 공급업체가 제시한 고객 사례로 받아들여야 한다.

그럼에도 이 사례는 Google이 이사회가 측정하기를 바라는 대상을 보여준다. 목표 성과는 구매한 AI 기능이나 생성된 알림의 수가 아니다.

의미 있는 위협을 식별하고, 이를 비즈니스 노출과 연결하며, 적절한 대응을 시작하는 데 필요한 시간이다. 이 순서는 실제 사고 상황에서도 신뢰할 수 있어야 한다.

비즈니스 맥락은 이 모델의 중심이다. 격리된 테스트 서비스의 심각한 취약점이 민감한 운영 데이터에 닿는 중간 수준의 노출보다 반드시 우선순위가 높지는 않다.

보안 팀은 이미 그러한 판단을 내리고 있지만, 분산된 시스템은 과정을 느리게 만든다. 애플리케이션, ID, 자산, 담당자에 관한 데이터는 흔히 별도의 도구에 흩어져 있다.

Google은 방어 시스템이 도달 가능성과 비즈니스 가치를 기준으로 결과의 순위를 매길 수 있도록 충분한 내부 맥락을 제공하자고 제안한다. 도달 가능성이란 공격자가 취약한 구성 요소에 현실적으로 접근해 악용할 수 있는지를 뜻한다.

이는 오탐과 알림 피로를 줄일 수 있다. 동시에 우선순위 시스템이 민감한 운영 관계에 접근해야 한다는 점에서 새로운 거버넌스 문제를 만들 수도 있다.

맥락이 풍부한 보안 플랫폼은 자산 목록, ID 권한, 애플리케이션 종속성, 코드, 위협 인텔리전스, 사고 이력을 처리할 수 있다. 이러한 입력은 의사결정을 개선하는 동시에 집중 위험을 높인다.

이사회는 누가 이 맥락에 접근할 수 있는지, 얼마나 오래 보관되는지, 모델이 승인된 방어 목적을 넘어 이를 사용하지 않는지 물어야 한다.

또한 사고 이후 조직이 의사결정을 재구성할 수 있는지도 물어야 한다. 누구도 그 근거를 설명할 수 없다면, 신속한 자동화 조치는 거버넌스 측면에서 제한적인 가치만 가진다.

따라서 Google이 강조하는 속도는 요건의 절반에 불과하다. 성숙한 방어 프로그램은 신속한 조치와 함께 추적 가능성, 통제된 권한, 복구 가능한 변경 사항을 결합해야 한다.

이 조합이 자동화가 회복탄력성을 만드는지, 아니면 실수를 더 빠르게 확산시키는지를 결정한다.

진짜 경쟁은 통합 맥락과 포인트 도구 간의 대결이다

주요 경쟁 구도는 Google Cloud와 특정 경쟁사 간의 대결이 아니라, 통합 보안 플랫폼과 분산된 포인트 도구 환경 간의 대결이다.

대부분의 대기업은 클라우드, 엔드포인트, ID, 애플리케이션, 컴플라이언스 프로그램 전반에 걸쳐 축적된 보안 제품을 운영한다. 각 구매는 특정 문제를 해결할 수 있지만 또 다른 데이터 경계를 추가한다.

이러한 분산은 중복 알림, 일관되지 않은 심각도 점수, 상충하는 자산 기록을 낳는다. 분석가는 근본적인 위협을 평가하기 전에 시스템 간 정보를 해석하는 데 시간을 쓴다.

Google은 이사회가 이러한 아키텍처를 비즈니스 위험으로 다루기를 바란다. 7월 가이드는 경영진이 통합 플랫폼으로 나아가고 있는지, 아니면 도구의 누더기 조합을 유지하고 있는지 묻는다.

회사는 2025년 위협 인텔리전스, 보안 운영, 클라우드 보안, 엔터프라이즈 브라우징을 아우르는 융합 계층으로 Google Unified Security를 도입했다. Gemini는 그 환경 안에서 조사와 워크플로 자동화를 지원한다.

AI Threat Defense는 플랫폼 논리를 취약점 관리와 자동화 복구로 확장한다. 4단계 프레임워크는 준비, 스캔 및 우선순위 설정, 복구, 모니터링을 포괄한다.

CodeMender는 이 이야기의 중요한 부분을 담당한다. Google은 2026년 7월 21일 이 관리형 코드 보안 에이전트를 프리뷰로 출시했다.

이 에이전트는 코드를 스캔하고 잠재적 취약점을 조사하며 제안된 수정 사항을 생성한다. 개발자는 기존 개발 도구를 통해 패치를 검토하고 적용할 수 있다.

Google은 CodeMender가 여러 모델을 사용할 수 있으며 AI Threat Defense의 구성 요소로 작동할 수 있다고 말한다. 멀티모델 설계는 단일 모델이 모든 보안 작업을 똑같이 잘 수행하지는 못한다는 점을 인정한다.

생성된 패치는 애플리케이션 동작을 바꿀 수 있으므로 사람의 검토는 여전히 중요하다. 기술적으로 유효한 수정이라도 문서화되지 않은 비즈니스 요구사항이나 운영 종속성과 충돌할 수 있다.

바로 이 지점에서 플랫폼 통합은 매력적이면서도 위험해진다. 탐지, 맥락, 코드, 배포를 연결하면 복구 시간을 며칠에서 몇 분으로 단축할 수 있다.

동일한 연결은 잘못된 지시, 침해된 ID, 오염된 신호, 모델 오류의 영향을 확대할 수도 있다. 통합은 방어자에게는 마찰을 줄이고, 잠재적으로는 침입자에게도 마찰을 줄인다.

포인트 도구는 다른 위험 프로필을 제공한다. 그 경계는 피해 범위를 제한하고, 공급업체 다양성을 유지하며, 팀이 특수한 환경에 맞는 전문 제품을 선택하게 해줄 수 있다.

하지만 이러한 경계는 상관관계 분석과 대응도 늦춘다. 한 시스템의 알림에는 의미 있는 우선순위 설정에 필요한 ID 데이터나 애플리케이션 맵이 포함되지 않을 수 있다.

이사회는 모든 영역에서 하나의 공급업체를 요구하는 방식으로 이 논쟁을 해결해서는 안 된다. 대신 어떤 통합이 측정 가능한 성과를 내고, 어떤 통합이 용납할 수 없는 집중 위험을 만드는지 경영진에게 설명하도록 해야 한다.

유용한 아키텍처는 모든 통제를 단일 제공업체에 넘기지 않으면서도 공통 데이터 계층과 조율된 워크플로를 포함할 수 있다.

Microsoft, Palo Alto Networks, CrowdStrike를 비롯한 주요 보안 공급업체들도 자체적인 플랫폼 전략을 추진하고 있다. 이들 역시 텔레메트리, 위협 인텔리전스, AI 어시스턴트, 자동화 대응을 결합한다.

그러한 경쟁 방향은 시장이 통합으로 향하고 있다는 Google의 진단을 뒷받침한다. 그렇다고 하나의 플랫폼 아키텍처가 모든 기업에 적합하다는 뜻은 아니다.

기업은 증거를 보존하고, 특화된 통제를 통합하며, 공급자를 변경할 수 있어야 하므로 개방형 인터페이스가 중요하다. Google이 말하는 “개방성”은 그 표현 자체가 아니라 실제 배포된 상호운용성을 기준으로 평가해야 한다.

이사회는 데이터 내보내기 결과물이 계속 활용 가능한지, 워크플로가 타사 도구를 지원하는지, 핵심 정책이 공급자 전환 후에도 유지되는지를 경영진에 물을 수 있다.

또한 장애 모드 테스트를 요청해야 한다. 중앙 플랫폼을 사용할 수 없게 될 경우, 팀에는 탐지, 에스컬레이션, 긴급 대응을 지속하기 위한 문서화된 방법이 필요하다.

통합은 의사결정 시간을 줄이면서도 의존성을 숨기지 않을 때 가치를 발휘한다. 그렇지 않으면 통합 대시보드는 해결되지 않은 운영 공백을 그럴듯하게 덮는 층이 될 수 있다.

지식 집약적인 팀에서는 이 원칙이 보안 콘솔을 넘어선다. 명확한 knowledge blending 프로세스는 단절된 업무 시스템 전반에서 의사결정, 증거, 운영 맥락을 보존하는 데 도움이 될 수 있다.

거버넌스의 목표는 통합 그 자체가 아니다. 신호에서 비즈니스 영향, 책임자, 조치, 검증, 이사회 보고로 이어지는 방어 가능한 연결고리를 구축하는 것이다.

이사회는 자동화를 운영하는 것이 아니라 거버넌스해야 한다

이사는 일상적인 기술적 판단은 책임 있는 경영진에게 맡기되, 자동화된 방어 체계에는 측정 가능한 경계를 설정해야 한다.

이 구분은 두 가지 흔한 실패를 막는다. 수동적인 이사회는 모호한 사이버 업데이트만 받게 되고, 지나치게 개입하는 이사회는 스스로 관리할 수 없는 사고 대응을 방해하게 된다.

Google은 더 건설적인 중간 지대를 제안한다. 이사는 보안 성과를 비즈니스 전략과 연결하고, 경영진이 증거를 제시하도록 요구하는 질문을 해야 한다.

첫 번째 질문은 비즈니스 활성화에 관한 것이다. 승인된 AI 아이디어가 통제된 프로덕션 릴리스로 이어지는 경로를 실제로 단축하는 보안 투자는 무엇인가?

신뢰할 수 있는 답변은 구체적인 지연 요인, 책임자, 통제 개선 사항을 제시해야 한다. AI 보안 기능을 구매하는 일을 곧바로 비즈니스 민첩성 향상으로 간주해서는 안 된다.

두 번째 질문은 개선 조치 성과에 관한 것이다. 이사회는 탐지 시간, 우선순위 지정 시간, 수정 시간, 검증 실패를 포함한 중요 노출의 추세 데이터를 받아야 한다.

전사 단일 MTTR은 심각한 문제를 가릴 수 있다. 저위험 티켓 처리 성과는 개선되더라도, 중요한 인터넷 노출 시스템은 여전히 위험에 남아 있을 수 있다.

세 번째 질문은 도구 통합에 관한 것이다. 경영진은 어떤 인계 절차가 사라졌는지, 어떤 가시성 공백이 해소되었는지, 플랫폼 장애 시 조직이 어떻게 대응할지를 보여야 한다.

네 번째 질문은 맥락 기반 우선순위 지정에 관한 것이다. 이사는 자동화된 의사결정에 어떤 데이터가 활용되는지, 팀이 잘못된 우선순위에 어떻게 이의를 제기하는지 이해해야 한다.

다섯 번째 질문은 AI 안전성과 정책에 관한 것이다. 기업에는 승인된 아키텍처, 런타임 가시성, 데이터 유출 통제, AI 개발 기준이 필요하다.

Shadow AI는 특별한 주의가 필요하다. 이 용어는 공식 승인, 가시성 또는 확립된 데이터 보호 없이 사용되는 AI 도구나 모델을 포괄한다.

승인되지 않은 모든 도구를 금지한다고 해서 문제가 해결되는 경우는 드물다. 직원들이 이를 도입하는 이유는 승인된 워크플로가 없거나, 느리거나, 부적절하기 때문이다.

이사회 차원의 대응은 제한 조치와 실제로 쓸 수 있는 대안을 함께 제시해야 한다. 경영진은 shadow AI를 어떻게 발견하고, 지식재산을 어떻게 보호하며, 정당한 사용 사례를 어떻게 거버넌스 체계 안으로 편입하는지 설명해야 한다.

Google의 secure AI framework는 데이터, 인프라, 모델, 애플리케이션 전반의 위험을 더 폭넓게 조망한다. 여기에는 프롬프트 인젝션, 데이터 오염, 모델 유출, 비정상적 행위와 같은 우려가 포함된다.

이러한 라이프사이클 관점은 AI 보안이 모델 엔드포인트에서 멈출 수 없다는 점에서 유용하다. 학습 데이터, 검색 시스템, 에이전트 도구, ID, 출력 처리 모두가 노출 수준에 영향을 미친다.

NIST는 AI risk framework를 통해 공급업체 중립적인 기준점을 제공한다. 핵심 기능은 govern, map, measure, manage다.

NIST는 거버넌스를 최종 승인 관문이 아니라 지속적이고 횡단적인 활동으로 설명한다. 이는 두 프레임워크의 목적은 다르지만, 지속적인 방어가 필요하다는 Google의 주장과 맞닿아 있다.

NIST는 AI 시스템 전반의 위험 관리에 초점을 둔다. Google의 AI Threat Defense는 AI와 맥락 기반 보안 시스템을 사이버 위협 대응에 활용하는 데 초점을 둔다.

이사회는 둘을 혼동하지 않고 연결해야 한다. AI를 활용해 조직을 보호한다고 해서 조직이 구축하는 AI 시스템까지 자동으로 보호되는 것은 아니다.

자동화된 보안 에이전트는 취약점 적체를 줄일 수 있지만, 거버넌스되지 않은 비즈니스 에이전트는 여전히 민감한 데이터를 노출할 수 있다. 두 문제 모두 감독이 필요하지만 통제 방식은 다르다.

이사는 CISO, 최고기술책임자, 최고정보책임자, 법무팀, 리스크 책임자, 비즈니스 책임자를 포괄하는 책임 지도를 요구해야 한다.

그 지도에는 누가 자동화된 조치를 승인하는지, 누가 이를 중단할 수 있는지, 누가 사고의 중대성을 판단하는지가 명시되어야 한다.

SEC의 cyber disclosure rules는 상장기업에 이러한 에스컬레이션 경로를 중요한 사안으로 만든다. 연간 공시에는 이사회의 감독과 사이버 위험에서 경영진의 역할을 설명해야 한다.

이 규정은 이사가 보안 엔지니어가 될 것을 요구하지 않는다. 다만 감독이 어떻게 작동하는지 기업이 설명할 것을 요구한다.

AI 기반 운영에서는 권한이 모델, 도구, 공급업체, 팀 전반에 분산되므로 이러한 설명이 더 어려워진다. 실행이 더 자율화될수록 명확한 책임 소재의 가치는 커진다.

따라서 이사회는 조치 등급을 포함한 자동화 정책을 승인해야 한다. 영향이 낮은 작업은 자동으로 실행할 수 있지만, 영향이 큰 변경은 지정된 사람의 승인을 받아야 한다.

예를 들어 시스템은 승인 없이 경보 정보를 보강할 수 있다. 프로덕션 서비스를 격리하거나 자동 생성된 패치를 병합하는 일에는 더 강한 통제가 필요하다.

정책에는 로깅, 롤백, 테스트, 예외 처리, 정기 검토가 포함되어야 한다. 이는 특정 공급업체에 대한 선호가 아니라 거버넌스 요건이다.

이사회는 잘못된 권고, 사용할 수 없는 모델, 탈취된 서비스 계정, 오염된 맥락 데이터가 포함된 훈련도 요청해야 한다.

목적은 모든 실패를 예측하는 것이 아니다. 자동화에 문제가 생겼음을 사람들이 인식하고, 시스템이 문제를 증폭시키기 전에 복구할 수 있는지 확인하는 것이다.

Google Cloud의 주장은 여전히 독립적인 검증이 필요하다

Google Cloud는 일관된 전략을 제시하지만, 이사회는 자율 방어를 확립된 표준으로 간주하기 전에 운영상의 증거를 요구해야 한다.

첫 번째 불확실성은 선별된 배포 환경 밖에서의 성과다. 공급업체 사례 연구는 달성 가능한 결과를 보여줄 수 있지만, 복잡한 조직 전반에서의 일반적인 성과를 드러내지는 못한다.

Morgan Stanley가 보고한 탐지 개선은 주목할 만하지만, 모든 고객에게 예상되는 성과를 입증하지는 않는다. 아키텍처, 인력, 자산 품질, 통합 깊이에 따라 결과는 달라질 수 있다.

이사회는 배포가 시작되기 전에 기준 측정을 요청해야 한다. 기준이 없으면 경영진은 자동화가 속도, 정확성, 범위, 엔지니어링 업무량을 개선했는지 보여줄 수 없다.

두 번째 불확실성은 오탐과 미탐에 관한 것이다. 맥락 기반 우선순위 지정은 주의를 분산시키는 경보를 줄일 수 있지만, 잘못된 억제는 중요한 노출을 묻어버릴 수 있다.

경영진은 정밀도, 놓친 탐지, 재개된 발견 사항, 재정의된 권고안을 보고해야 한다. 높은 경보량만으로 강력한 보안을 의미하지는 않는다.

세 번째 불확실성은 개선 조치의 품질이다. 코드 생성 에이전트는 빠르게 패치를 제안할 수 있지만, 속도가 동작의 정확성을 보장하지는 않는다.

Google은 CodeMender 변경 사항에서 개발자가 검토 과정에 남도록 한다. 이는 의미 있는 안전장치이지만, 조직은 긴급 상황에서 검토가 어떻게 작동하는지 검증해야 한다.

검토자에게는 테스트, 소유권 정보, 의존성 맥락, 안전한 롤백 경로가 필요하다. 그렇지 않으면 사람은 형식적인 승인 단계에 그치게 된다.

네 번째 불확실성은 런타임에서의 자율성이다. 보안 에이전트는 활동을 차단하고, 자산을 격리하거나, 접근 권한을 변경해 위협을 억제할 수 있다.

이러한 조치는 조직을 보호할 수도 있고 중요한 서비스를 중단시킬 수도 있다. 적절한 임계값은 시스템 중요도, 신뢰도, 이용 가능한 복구 옵션에 따라 달라진다.

다섯 번째 불확실성은 플랫폼 집중도다. 코드, ID, 취약점, 애플리케이션 관계, 사고 데이터를 모두 보는 시스템은 매력적인 공격 표적이 된다.

이사회는 Google과 내부 팀이 어떻게 직무를 분리하고, 자격 증명을 보호하며, 권한 있는 에이전트를 모니터링하고, 맥락 데이터 접근을 제한하는지 물어야 한다.

계약 및 이탈 계획도 필요하다. 공급업체 관계가 변경되더라도 사고 증거, 정책, 자산 관계는 계속 접근 가능해야 한다.

여섯 번째 불확실성은 적대적 적응이다. 공격자는 자동화된 방어가 위험을 분류하는 방식을 연구하고, 그러한 판단을 조작할 방법을 찾을 것이다.

이들은 잡음성 발견 사항을 대량 생성하고, 사각지대를 겨냥하며, 맥락 신호를 오염시키거나, 방어 에이전트에 연결된 도구를 악용할 수 있다.

따라서 AI 대 AI라는 구도는 경쟁을 지나치게 단순화할 수 있다. 인간 운영자는 여전히 표적을 선택하고, 전략을 조정하며, 합법적인 접근 권한을 악용하고, 조직의 혼선을 이용한다.

공개 보안 연구, 레드팀 테스트, 공급업체 간 위협 인텔리전스는 여전히 중요하다. 플랫폼은 텔레메트리만으로 모든 비즈니스 의존성이나 내부자의 동기를 추론할 수 없다.

이사회는 머신 속도의 방어를 구매하면 AI 보안 문제가 해결된다는 단순한 약속을 경계해야 한다. 실제 프로그램에는 아키텍처, ID, 데이터 거버넌스, 소프트웨어 관행, 사고 대응, 인력 교육이 포함된다.

또한 자동화를 전문성을 성급히 줄이는 근거로 삼아서도 안 된다. 보안 전문가는 새로운 행동을 평가하고, 영향이 큰 조치를 검증하며, 예외를 관리해야 한다.

자동화는 반복 업무를 제거할 때 분석가와 엔지니어의 시간을 되돌려줄 수 있다. 경영진이 인력 감축을 핵심 성공 지표로 삼을 경우 회복력을 약화시킬 수도 있다.

올바른 척도는 통제된 위험 감소다. 중요한 노출이 수용할 수 없는 운영상 피해 없이 더 빨리 해소된다는 증거가 있을 때만 더 빠른 활동은 의미가 있다.

기업이 다른 공급업체를 선택하더라도 Google의 이사회 논지는 여전히 유효하다. 보안 거버넌스는 AI 기반 운영의 속도와 범위에 부합해야 한다.

제품 주장은 이사회가 모든 전략적 플랫폼 투자에 적용하는 것과 같은 수준의 회의적 검토를 받아야 한다. 기술, 모델, 공급업체가 바뀌더라도 거버넌스는 지속 가능해야 한다.

AI Threat Defense가 기준선이 될지 보여줄 세 가지 신호

다음 시험대는 기업이 Google Cloud의 이사회용 언어를 측정 가능하고 반복 가능한 보안 성과로 전환할 수 있는지 여부다.

첫 번째 신호는 AI 기반 개선 조치의 프로덕션 증거다. Google은 CodeMender를 프리뷰로 출시했으므로, 조직은 통제된 시연을 넘어 배포가 어떻게 수행되는지 지켜봐야 한다.

유용한 증거에는 검증된 발견 취약점, 수용된 패치, 거부된 패치, 회귀, 절감된 시간이 포함된다. 또한 인간 검토가 결과를 어떻게 바꾸는지도 보여야 한다.

낮은 롤백 및 재정의 비율로 광범위하게 배포된다면, 자동화된 개선 조치가 비즈니스 속도를 높일 수 있다는 Google의 주장을 뒷받침할 것이다.

빈번한 되돌림이나 설명되지 않는 판단은 이 주장을 약화시킬 것이다. 이는 에이전트의 속도가 여전히 상당한 수작업 검증에 의존한다는 점을 시사할 수 있다.

두 번째 신호는 이사회 수준의 보고 품질이다. 기업은 기능 목록에서 벗어나 비즈니스 시스템과 연결된 결과 중심 지표로 전환해야 한다.

이러한 조치에는 핵심 MTTR, 노출의 도달 가능성, 자동화된 조치 실패율, 미해결 고영향 예외 사항, 섀도우 AI 적용 범위가 포함됩니다.

더 나은 보고는 이사회가 개별 도구를 직접 관리하지 않고도 AI 위협 방어를 감독할 수 있음을 보여줄 것입니다. 제품 도입에 초점을 둔 모호한 업데이트는 감독 체계가 미성숙하다는 신호입니다.

세 번째 신호는 경쟁 및 표준과의 정렬입니다. 고객이 AI Threat Defense를 다른 벤더 및 공인된 거버넌스 프레임워크와 연결할 수 있다면 Google의 전략은 더욱 신뢰를 얻을 수 있습니다.

이식 가능한 증거, 개방형 인터페이스, 공유 정책 정의, 독립적인 테스트를 지원하면 회사의 ‘개방형’ 포지셔닝이 강화될 것입니다.

반대로 폐쇄형 워크플로와 어려운 데이터 내보내기는 이를 약화시킬 것입니다. 이는 이사회 기준선을 일반적인 보안 표준이 아니라 플랫폼 종속을 위한 논거로 바꾸게 됩니다.

이사회는 중대한 사고 발생 시 규제기관이 자동화된 의사결정을 어떻게 해석하는지도 주시해야 합니다. 기존 사이버 규정은 감독, 위험 관리 프로세스, 적시 공시에 초점을 둡니다.

향후 지침은 위협의 우선순위를 정하고, 프로덕션 시스템을 변경하거나, 중요성 판단에 영향을 미치는 AI 에이전트에 대한 기대치를 명확히 할 수 있습니다.

실질적인 대응은 기다릴 필요가 없습니다. 이사들은 경영진에게 공격, 의사결정, 복구 사이에 존재하는 현재의 속도 격차를 문서화하도록 요구할 수 있습니다.

그런 다음 측정 가능한 자동화를 위해 하나의 핵심 워크플로를 선택할 수 있습니다. 파일럿에는 기준선 지표, 승인 경계, 로그, 독립적 검증, 롤백 테스트가 포함되어야 합니다.

성공 시에는 프로그램을 점진적으로 확대해야 합니다. 실패 시에는 변경이 필요한 아키텍처나 통제에 관한 근거를 확보해야 합니다.

Google Cloud는 AI 도입이 이를 보호하는 시스템보다 더 빠르게 진행될 수 있다는 이사회 차원의 문제를 정확히 짚었습니다.

제안된 해법은 맥락화된 보안 데이터, 자율 에이전트, 통합 워크플로, 지속적인 모니터링을 결합합니다. 이 설계는 속도를 제공하지만, 동시에 권한과 정보를 집중시킵니다.

따라서 이사회 기준선은 ‘AI로 AI와 맞서라’는 지침보다 더 강력해야 합니다. 추적 가능한 자동화, 책임 소재가 명확한 담당자, 검증된 복구, 측정 가능한 위험 감소를 요구해야 합니다.

다음 거버넌스 검토에서 한 가지 직접적인 질문을 던지십시오. 경영진은 새로운 위험을 감추지 않으면서 자동화된 방어가 조직의 가장 중요한 노출을 더 빠르게 해소한다는 사실을 증명할 수 있는가?

답이 근거가 아닌 제품명에 의존한다면 조직은 준비되지 않았습니다. 근거가 명확하다면 Google Cloud의 이사회 논지는 이미 운영상의 현실이 되고 있습니다.