AI VIDEO BRIEFING

구글 빅 슬립·코드멘더 정리: AI 에이전트가 보안 취약점을 찾아 자동으로 고치는 구조와 한계

구글 보안 총괄들이 밝힌 AI 취약점 자동화 전략. 깊은 메모리 버그를 오탐 없이 찾아내는 빅 슬립과, 패치를 여러 겹으로 검증해 오픈소스에 178건을 반영한 코드멘더의 작동 방식과 남은 한계를 정리했다.

구글이 밝힌 AI 보안 자동화: 취약점을 찾는 '빅 슬립', 고치는 '코드멘더' 영상 대표 이미지

핵심 메시지

  • 구글은 에이전트형 AI가 모든 소프트웨어의 취약점을 찾아낼 수 있는 시대가 임박했다고 보고, 취약점 폭증에 대비한 두 프로젝트를 공개했다.
  • 빅 슬립은 코드베이스를 깊이 학습한 뒤 가설을 세우고 디버거와 스크립트로 스스로 검증하는 반복 루프로 작동하며, '취약점 증명' 코드를 만들어 오탐률을 0으로 낮췄다.
  • 코드멘더는 발견된 취약점의 패치 후보를 만든 뒤 퍼징·형식 검증·차등 테스트·LLM 검토를 모두 통과한 것만 제출하며, 지금까지 오픈소스에 178건의 자동 생성 수정이 반영됐다.
  • 발표자들은 취약점을 찾고 고치는 문제보다 세상의 코드베이스가 실제로 패치를 적용하게 만드는 문제가 더 어렵다고 인정했다.

쉽게 이해하기

구글의 보안 엔지니어링 총괄 헤더 애드킨스와 딥마인드의 보안·프라이버시 총괄 포 플린이 [un]prompted 2026 무대에서 자사의 코드 보안 전략을 설명했다. 두 사람은 오픈소스 침투 테스트 프레임워크가 늘어나고 취약점 발견 스타트업에 10억 달러 규모의 투자금이 몰리는 상황을 근거로, 공격자와 방어자 모두가 에이전트형 도구로 거의 모든 취약점을 찾아낼 수 있는 시점이 멀지 않았다고 진단했다.

그 결과는 취약점의 홍수다. 발표에 따르면 미국 취약점 데이터베이스의 분석 대기열에는 3만 건의 적체가 쌓여 있고, CVE 등록 건수는 한 해 사이 35% 늘었다. 애드킨스는 취약점이 너무 많아지면 지금의 심각도 점수 체계가 의미를 잃을 것이라며, 발견 자체보다 우선순위를 매기고 처리하는 방식을 다시 설계해야 한다고 말했다.

빅 슬립은 뛰어난 취약점 연구자가 특정 코드베이스에 깊이 통달하는 과정을 그대로 흉내 낸다. 먼저 코드 구조와 과거 취약점 이력을 학습한 뒤, '이 부분이 취약할 것 같다'는 가설을 세우고 디버거·코드 브라우저·파이썬 인터프리터를 도구로 써서 직접 테스트 코드를 짜 검증한다. 크래시가 재현되면 검증 단계로 넘어가 취약점을 증명하는 코드를 만들고, 제미나이가 함수별로 원인을 설명하는 보고서까지 작성한다.

코드멘더는 그다음 절반, 즉 고치는 일을 맡는다. 패치는 보안 결함을 실제로 없애야 하고, 기존 기능을 망가뜨리지 않아야 하며, 원저자의 코딩 관용구를 최대한 존중해야 한다. 이를 확인하기 위해 패치 전후 퍼징, 해당 구간의 형식 검증, 차등 테스트, 별도 프롬프트로 구성한 LLM 검토가 붙는 플러그형 검증 체계를 만들었고, 어느 검증도 통과하지 못하면 실패 원인을 다시 모델에 입력해 새 후보를 만들게 한다.

다만 두 사람은 남은 문제도 분명히 했다. 현재 연구 대상은 크롬의 자바스크립트 엔진이나 FFmpeg처럼 신뢰할 수 없는 입력을 다루는 인프라 구성 요소이며, 애플리케이션의 비즈니스 로직 취약점에 같은 방법이 통할지는 아직 모른다고 답했다. 무엇보다 만들어진 패치를 세상이 제때 적용하게 만드는 방법은 AI로 풀 방법을 모르겠다고 털어놨다.

주요 인사이트

  • 오탐률 0이라는 수치의 핵심은 모델 성능이 아니라 '증명' 단계다. 취약점을 재현하는 코드를 함께 만들어야만 보고서가 나가도록 파이프라인을 설계해, 사람이 검토하지 않아도 신뢰할 수 있는 결과만 남게 했다.
  • 패치 자동화의 어려움은 취약점을 없애는 것이 아니라 기능을 보존했음을 증명하는 데 있다. 구글이 검증기를 여러 겹 쌓고 '너무 신중하다'는 비판을 감수한 이유도, 커뮤니티의 신뢰가 무너지면 기술 채택 자체가 멈추기 때문이다.
  • 퍼징 도구가 여전히 대규모로 돌아가는데도 빅 슬립이 퍼저가 놓친 버그를 찾아낸다는 점은, 이 방식이 기존 자동화가 닿지 못하던 깊이를 겨냥하고 있음을 보여준다.
  • 발견과 수정이 자동화되면 병목은 배포로 옮겨간다. 발표자들이 유일하게 해법을 제시하지 못한 지점도 '패치를 AI의 속도로 적용하게 만드는 일'이었다.

자주 묻는 질문

빅 슬립은 일반적인 코드 리뷰용 LLM 사용과 무엇이 다른가?

단순히 코드를 넣고 취약점을 물어보는 방식이 아니라, 코드베이스와 과거 취약점을 먼저 학습한 뒤 가설을 세우고 디버거와 직접 작성한 스크립트로 그 가설을 반복 검증하는 순환 구조로 동작한다. 마지막에는 취약점을 재현하는 증명 코드까지 만들어 보고서에 첨부한다.

코드멘더가 만든 패치는 어떻게 검증하나?

패치 전후로 퍼징을 돌려 기능이 깨지지 않았는지 확인하고, 해당 코드 구간의 형식 검증과 차등 테스트를 거치며, 악의적 입력을 다시 넣어 취약점이 사라졌는지 본다. 여기에 별도로 설계한 프롬프트로 LLM에게 패치를 검토하게 한 뒤, 모든 검증을 통과한 후보만 커뮤니티에 제출한다.

이 기술이 아직 다루지 못하는 영역은?

연구가 주로 크롬 엔진이나 FFmpeg 같은 인프라 구성 요소에 집중돼 있어, 애플리케이션 사용 맥락에 따라 달라지는 비즈니스 로직 취약점에는 적용 여부가 확인되지 않았다. 또 만들어진 패치를 각 조직이 신속히 적용하도록 만드는 문제는 미해결로 남아 있다.

원문과 출처

이 글은 원본 영상의 자막을 바탕으로 한국어 독자를 위해 요약했습니다. 전체 맥락과 최신 정보는 원문에서 확인하세요.

YouTube 원본 영상 보기 ↗

관련 AI 소식