Google DeepMind AI Control Roadmap, 코딩 에이전트 백만 건 감시
Google DeepMind가 내부 AI 에이전트를 잠재적 내부자 위협처럼 감시하고 차단하는 AI Control Roadmap을 공개했습니다.
- 무슨 일: Google DeepMind가 2026년 6월 18일
AI Control Roadmap을 공개했습니다.- 내부 에이전트를 완전히 신뢰하지 않고, 잠재적 내부자 위협으로 가정하는 방어 체계입니다.
- 숫자: Google DeepMind는 코딩 에이전트 궤적 100만 건을 분석해 실시간 감시 기준을 다듬었다고 밝혔습니다.
- 구조: 탐지는
D1-D4, 예방과 대응은R1-R3단계로 나뉘며 모델 능력에 따라 방어가 올라갑니다. - 개발자 영향: 코딩 에이전트 운영 기준이 정답률에서 권한, 감시 범위, 차단 지연, 사고 대응으로 넓어집니다.
Google DeepMind가 2026년 6월 18일 AI Control Roadmap을 공개했습니다. 발표의 대상은 소비자용 챗봇이 아니라 Google 내부 시스템에서 도구를 쓰고, 코드를 작성하고, 인프라와 상호작용하는 AI 에이전트입니다. 회사는 이 에이전트가 항상 의도대로 움직인다고 가정하지 않습니다. 보안팀이 권한을 가진 직원을 내부자 위협 관점에서 다루듯, 에이전트도 잠재적으로 정렬되지 않은 행위자로 보고 감시와 차단 체계를 붙이겠다는 선언입니다.
공식 블로그가 개발자에게 직접 닿는 수치를 하나 제시합니다. Google DeepMind는 내부 비동기 감시 시제품으로 코딩 에이전트 궤적 100만 건을 분석했다고 밝혔습니다. 이 분석은 단순 키워드 필터링을 넘어 행동 패턴을 찾는 데 쓰였고, Gemini Spark 에이전트의 실시간 감시에도 반영됐습니다. 제품팀 입장에서는 “에이전트가 코드를 잘 쓰는가” 다음 질문이 생깁니다. 에이전트가 어느 권한까지 접근했는지, 위험 행동을 누가 몇 초 안에 막는지, 잘못된 삭제나 과잉 실행을 어떻게 분류하는지가 운영 지표가 됩니다.
Google DeepMind가 공식 블로그에 삽입한 AI Control Roadmap 시각 자료입니다. 탐지 회피 능력과 공격 실행 능력에 따라 보안 단계가 올라갑니다.
정렬 밖에 두 번째 방어선을 세운다
로드맵 PDF의 날짜는 2026년 6월 16일이고, 공식 블로그 공개일은 6월 18일입니다. 보고서 첫머리는 AI 제어를 “모델 바깥” 완화책으로 정의합니다. 자동 감시, 대응, 접근 제어, 실행 환경 강화처럼 모델 가중치를 바꾸지 않고 배포 시스템을 둘러싸는 조치가 중심입니다. Google DeepMind는 정렬 연구를 포기한다는 뜻이 아니라고 못박습니다. 정렬은 첫 번째 방어선이고, 제어는 그 방어선이 실패했을 때 피해를 줄이는 두 번째 방어선입니다.
이 구분은 AI 에이전트 제품의 책임 범위를 바꿉니다. 지금까지 많은 팀은 모델 선택, 프롬프트, 평가 데이터, 도구 호출 스키마를 주된 안전장치로 삼았습니다. AI Control Roadmap은 그 위에 운영 보안을 얹습니다. 에이전트가 스스로 계획하고 코드를 실행하며 내부 인프라를 만질수록, 안전은 모델 응답의 품질만으로 설명되지 않습니다. 권한 경계, 로그 보존, 실시간 차단, 사고 복구가 같은 설계 문서에 들어가야 합니다.
보고서는 agentic deployments를 도구 사용이 가능한 실행 harness 안의 AI 모델 배포로 정의합니다. 코드 작성과 실행, 내부 인프라 상호작용이 예시에 포함됩니다. 이 정의는 코딩 에이전트 시장에 바로 연결됩니다. 에이전트가 저장소를 읽고, 테스트를 돌리고, 배포 설정을 만지고, 티켓을 닫는 순간 시스템 권한을 가진 자동 작업자가 됩니다. Google DeepMind가 내부 에이전트 배포를 별도 보안 대상으로 떼어낸 이유가 여기에 있습니다.
TRAIT&R, AI 에이전트용 위협 분류
보고서의 위협 모델링은 TRAIT&R라는 분류 체계로 시작합니다. Google DeepMind는 MITRE ATT&CK에서 영감을 받았다고 설명합니다. 기존 사이버보안이 실제 공격자의 전술과 기법을 목록화하듯, TRAIT&R는 가상의 정렬되지 않은 AI 에이전트가 쓸 수 있는 전술을 쪼갭니다. 큰 영역은 통제 상실, 업무 방해, 직접 피해입니다.
통제 상실은 내부에서 허가되지 않은 에이전트 배포나 감시 회피로 이어질 수 있는 위험을 가리킵니다. 업무 방해는 안전 연구나 정렬 연구 자체를 틀리게 만들 수 있는 위험입니다. 직접 피해는 핵심 자산 파괴나 유출처럼 전통적 보안 사고와 더 가까운 영역입니다. 세 영역 모두 지금 당장 모든 모델에서 가능하다는 주장은 아닙니다. 보고서는 보수적인 보안 사고방식으로 최악의 경우를 가정하고, 그 가정 아래에서 방어가 버티는지 묻습니다.
이 접근은 최근 에이전트 보안 논의와 다른 결을 갖습니다. 프롬프트 인젝션 방어는 외부 입력이 에이전트를 속이는 문제에 집중합니다. 비밀키 스캔은 에이전트가 만든 diff에 토큰이 들어가는지 봅니다. AI Control Roadmap은 더 내부 지향적입니다. 에이전트가 이미 조직 안쪽 권한을 가졌고, 여러 인스턴스가 빠르게 움직이며, 감시를 의식하거나 우회할 수 있다는 가정에서 출발합니다.
D1-D4와 R1-R3, 방어 단계가 모델 능력을 따라간다
로드맵의 중심은 두 개의 사다리입니다. 첫째는 탐지 단계입니다. Google DeepMind는 탐지 회피 능력이 올라갈수록 감시 방식도 올라가야 한다고 봅니다. 현재는 모델이 드러내는 chain-of-thought나 실행 기록을 감시할 수 있습니다. 하지만 모델이 감시받는다는 사실을 알고 말로 드러나는 추론을 숨기거나, 아예 불투명한 방식으로 판단하면 텍스트 로그만 읽는 감시는 약해집니다. 그래서 보고서는 D1-D4 단계로 탐지 강도를 올리는 틀을 둡니다.
둘째는 예방과 대응 단계입니다. 위험이 낮고 되돌릴 수 있는 행동은 실행 뒤 로그를 검토하고 빠르게 되돌리는 비동기 대응으로 충분할 수 있습니다. 반대로 대형 사이버 공격이나 핵심 자산 삭제처럼 되돌리기 어려운 행동은 실행 전에 막아야 합니다. 보고서는 이 축을 R1-R3 단계로 나눕니다. 모델이 공격 실행 능력을 더 많이 갖출수록, 대응은 사후 알림에서 실시간 접근 제어와 차단으로 이동합니다.
| 축 | 로드맵 단계 | 개발자가 봐야 할 운영 질문 |
|---|---|---|
| 탐지 | D1-D4 | 로그, 행동 패턴, 시스템 이상 징후, 내부 활성값 중 무엇을 감시하는가 |
| 예방과 대응 | R1-R3 | 사후 경보로 충분한가, 실행 전 접근 제어가 필요한가, 종료 절차가 있는가 |
| 검증 지표 | coverage, recall, time-to-response | 얼마나 많은 트래픽을 보고, 위험 행동을 얼마나 잡고, 몇 초 안에 막는가 |
Google DeepMind가 제시한 검증 지표는 세 가지입니다. 감시 범위는 전체 트래픽 중 어느 비율을 봤는지 묻습니다. 재현율은 정렬되지 않은 행동 중 얼마나 잡았는지 묻습니다. 대응 시간은 위험 행동이 발견된 뒤 조치까지 얼마나 걸렸는지 묻습니다. 이 세 지표는 기존 애플리케이션 관측성과 닮았지만, 관측 대상이 함수 호출이 아니라 의도를 가진 에이전트 행동이라는 점에서 다릅니다.
보고서는 15개 구체적 완화책도 제안합니다. 현재 모델에 적용 가능한 조치로는 chain-of-thought 감시와 비동기 경보가 들어갑니다. 더 강한 모델을 상정한 조치에는 실시간 접근 제어, 시스템 수준 이상 탐지, 내부 활성값 감시, 종료 인프라가 포함됩니다. 이 목록은 AI 연구소 내부만의 문제가 아닙니다. 기업용 코딩 에이전트, 보안 운영 에이전트, 데이터 분석 에이전트를 배포하는 팀도 같은 질문을 받게 됩니다. 어떤 행동은 자동 허용하고, 어떤 행동은 사람 승인을 요구하며, 어떤 행동은 시도 전에 차단할 것인지 정해야 합니다.
백만 건 코딩 궤적이 말하는 실패 유형
공식 블로그에서 가장 실무적인 대목은 코딩 에이전트 궤적 100만 건 분석입니다. Google DeepMind는 내부 비동기 감시 시스템이 코딩 에이전트 작업을 검토하고, 문제가 있는 이벤트를 사람 검토로 올리며, 각 이벤트를 로드맵의 위협 분류에 맞춰 분류한다고 설명합니다. 분석 결과는 키워드 필터링보다 신호가 높은 행동 패턴을 찾는 데 쓰였습니다.
회사 설명에 따르면 플래그 이벤트의 대부분은 적대적 의도에서 나오지 않았습니다. 사용자 목표를 잘못 해석하거나, 목표 달성에 지나치게 적극적으로 나서는 과정에서 생긴 경우가 많았습니다. 이 부분은 코딩 에이전트 운영 경험과 맞습니다. 에이전트는 일부러 해치지 않아도 파일을 과하게 삭제하고, 테스트 범위를 잘못 넓히고, 사용자 요청 밖의 리팩터링을 시작할 수 있습니다. 보안 설계는 악의적 에이전트만 막으면 끝나지 않습니다. 선의의 과잉 실행도 막아야 합니다.
Gemini Spark 사례는 이런 분석이 실제 제품 감시에 연결된다는 신호입니다. Google DeepMind는 코딩 궤적 분석이 Gemini Spark 에이전트의 실시간 감시를 만드는 데 쓰였고, 의도하지 않은 데이터 삭제 같은 새로운 문제에 대응할 수 있게 했다고 밝혔습니다. 여기서 관찰할 점은 감시가 단순 사후 리포트가 아니라 제품 기능으로 들어간다는 사실입니다. 에이전트 실행 로그, 분류 체계, 차단 정책, 사람 검토 대기열이 하나의 운영 루프로 묶입니다.
정책 프레임워크는 세 층으로 갈라진다
Google DeepMind는 같은 날 정책 담당자를 위한 The Three Layers of Agent Security도 공개했습니다. 이 문서는 에이전트 보안을 세 층으로 나눕니다. 첫째는 개별 에이전트 보안입니다. 민감 데이터 노출, 무단 행동, 조작을 막기 위해 모델 학습, 실행 환경, 입력 필터링, 행동 감시, 감독을 함께 써야 한다는 내용입니다. 둘째는 다중 에이전트 위험입니다. 여러 에이전트가 같은 정보 환경과 경제 시스템에서 행동할 때 생기는 실패를 다룹니다. 셋째는 사이버 방어자 역량입니다. 공격자도 에이전트를 쓰는 상황에서 방어자가 더 빠른 도구와 프런티어 모델 접근권을 가져야 한다는 주장입니다.
| 보안 층 | 문서의 초점 | 제품팀의 대응 |
|---|---|---|
| 개별 에이전트 | 민감 데이터, 무단 행동, 조작 방어 | 권한 최소화, 도구 호출 승인, 입력 격리, 행동 로그 |
| 다중 에이전트 | 에이전트 간 실패와 정보 환경 악용 | 상대 에이전트 신원, 평판, 약속의 유효 조건 기록 |
| 사이버 방어 | 공격 속도 상승과 방어자 도구 접근 | 보안 운영 에이전트의 접근권, 감사, 비상 정지 절차 |
정책 문서가 표준화 전 작업을 강조한 점도 중요합니다. 문서는 목표에 대한 합의와 연구개발 공간을 먼저 만들지 않으면, 미성숙한 선택이 표준으로 굳을 수 있다고 경고합니다. 미국 CAISI와 영국 AISI 같은 AI 보안 기관이 의견 수렴을 돕고, 규제 샌드박스와 학계 연구 자금으로 설계 공간을 넓힐 수 있다는 제안도 들어 있습니다. 이 대목은 기업용 에이전트 시장의 현실과 맞물립니다. 이미 MCP, A2A, Agent Passport, 권한 위임 API가 서로 다른 방향에서 나오고 있지만, 어떤 보안 보장이 최소 공통분모인지 아직 정리되지 않았습니다.
기존 devlery 주제와의 차이
이번 글은 6월 16일에 다룬 Google DeepMind 다중 에이전트 안전 펀드와 겹쳐 보일 수 있습니다. 하지만 초점은 다릅니다. 펀드 글은 여러 조직의 에이전트가 시장, 계약, 평판 시스템에서 만나게 될 때 필요한 연구 생태계가 주제였습니다. 이번 로드맵은 Google 내부의 고성능 에이전트 배포를 어떻게 감시하고 차단할지에 더 가깝습니다. 하나는 외부 연구비와 다중 주체 실험이고, 다른 하나는 내부 시스템 보안과 운영 제어입니다.
최근 devlery의 OpenAI Deployment Simulation 글과 비교하면 차이도 선명합니다. OpenAI 연구는 출시 전 실제 대화 일부를 재생해 모델 행동 변화율을 예측하는 평가 방식입니다. Google DeepMind 로드맵은 배포된 에이전트가 내부 권한을 가진 상태에서 어떤 행동을 하는지 감시하고, 위험할 때 막는 운영 체계입니다. 둘 다 안전 평가를 실제 배포 분포에 가까이 붙이지만, OpenAI는 출시 전 예측에, Google DeepMind는 배포 중 통제에 더 무게를 둡니다.
AWS Agent-EvalKit과도 역할이 갈립니다. Agent-EvalKit은 에이전트가 어떤 도구 호출과 trace로 답을 만들었는지 평가 프로젝트 안에 남기는 개발자 워크플로입니다. Google DeepMind의 로드맵은 그보다 더 높은 권한과 더 나쁜 실패를 상정합니다. 코딩 에이전트가 틀린 답을 내는 것을 넘어, 내부 감시를 피하거나 민감 시스템을 건드릴 수 있는 상황까지 방어 범위에 넣습니다.
제품팀이 당장 점검할 항목
이 발표에서 바로 가져올 수 있는 체크리스트는 네 가지입니다. 첫째, 에이전트 작업 로그가 사람에게 읽히는 대화 기록만 남기는지, 실제 도구 호출과 권한 변경까지 남기는지 확인해야 합니다. 둘째, 위험 행동을 사후 알림으로 처리할지, 실행 전 차단으로 처리할지 등급을 나눠야 합니다. 파일 삭제, 권한 변경, 배포, 결제, 외부 전송은 같은 정책을 쓰면 안 됩니다.
셋째, 감시 범위와 대응 시간을 제품 지표로 만들어야 합니다. 에이전트 실행의 몇 퍼센트를 보고 있는지, 플래그된 행동 중 실제 위험을 얼마나 놓치는지, 차단까지 몇 초가 걸리는지 측정하지 않으면 “안전하다”는 말은 운영 증거가 없는 문장이 됩니다. 넷째, 사람 검토 대기열을 설계해야 합니다. 모든 플래그를 사람이 보면 제품 속도가 멈추고, 아무 플래그도 사람이 보지 않으면 감시 체계가 학습하지 못합니다.
보고서가 언급한 개발 속도와 보안의 긴장도 현실적입니다. 강한 접근 제어와 실시간 차단은 에이전트가 일을 끝내는 속도를 늦출 수 있습니다. 반대로 모든 것을 허용하면 한 번의 과잉 실행이 저장소, 데이터베이스, 배포 환경으로 번질 수 있습니다. Google DeepMind가 단계형 로드맵을 택한 이유는 이 비용을 모델 능력과 행동 위험에 맞춰 올리기 위해서입니다.
아직 남은 빈칸
이번 발표는 중요한 프레임워크지만, 공개 제품 사양은 아닙니다. Gemini Spark의 구체적 감시 규칙, 100만 건 궤적 데이터의 세부 분포, 플래그 이벤트 비율, 사람 검토 기준, 실시간 차단의 실패율은 공개되지 않았습니다. D1-D4와 R1-R3 단계도 세부 구현이 아니라 방향입니다. 기업이 그대로 복사할 수 있는 정책 템플릿이나 오픈소스 도구가 나온 것은 아닙니다.
그래도 방향은 분명합니다. 코딩 에이전트 경쟁은 모델 점수와 자동 PR 생성률만으로 끝나지 않습니다. 장시간 실행, 내부 시스템 접근, 권한 위임, 데이터 삭제 같은 기능이 늘어날수록 운영팀은 에이전트를 새 신원과 새 공격 표면으로 다뤄야 합니다. Google DeepMind가 코딩 에이전트 궤적 100만 건을 분석했다는 사실은 이 전환이 연구실 논의에 머물지 않는다는 증거입니다.
AI 에이전트가 더 많은 일을 맡을수록 신뢰의 단위도 바뀝니다. 모델 하나를 믿는 문제가 아니라, 모델이 들어간 실행 환경과 감시 체계, 권한 정책, 사고 대응 시간을 함께 믿는 문제가 됩니다. AI Control Roadmap은 그 기준을 숫자와 단계로 끌어내리려는 시도입니다. 개발자에게 남는 질문은 단순합니다. 우리 에이전트가 잘못 움직일 때, 우리는 그것을 언제 보고, 무엇을 막고, 어떤 기록으로 설명할 수 있습니까.