Google의 대처 방식: 에이전트를 활용한 취약점 탐지, 추적, 해결 방법

*이 콘텐츠는 AI 번역 도구를 사용하여 번역되었습니다. 정확성을 기하기 위해 노력하고 있으나, 자동 번역에는 오류나 누락이 포함될 수 있습니다. 정확한 정보는 영문 원본을 참고해 주시기 바랍니다.

최첨단 AI 에이전트의 등장으로 소프트웨어 취약점 발견 및 익스플로잇에 드는 비용과 시간이 근본적으로 달라졌습니다. 불과 2년도 채 되지 않아, 과거에는 전문가가 몇 주에 걸쳐 수작업으로 해야 했던 리버스 엔지니어링이 이제는 단 몇 분 만에 가능해졌습니다. 

2025년 초에 Google은 취약점 탐지, 추적, 해결 방식을 소개했습니다. 당시의 보안 방어는 위험 평가, 시스템 전반의 심각한 버그에 대한 우선순위 지정, Tabletop 시뮬레이션 실시, 표준 빌드 파이프라인을 통한 카나리아 방식 수정 같은 익숙한 절차를 중심으로 이루어졌습니다.

하지만 이후 소프트웨어 보안 환경은 크게 달라졌습니다. 이제 에이전트는 그 어느 때보다 빠르게 소프트웨어 취약점을 발견하고 공격할 수 있으며, 기업 보안팀 역시 이전에는 존재조차 알지 못했던 수많은 취약점을 발견하고 있습니다. Google은 이러한 변화에 신속하고 유연하게 대응하기 위해 지난해 소개한 보안 체계를 발전시켜 자동화된 에이전트 시스템을 활용하는 새로운 접근 방식을 구축했습니다.

해결 지연 자체가 취약점이 되는 시대

에이전트의 등장으로 발견되는 취약점이 급증하고 대응에 허용되는 시간이 크게 줄어들면서 취약점 분류, 티켓 처리 대기열, 패치 적용 기간에 관한 기존 보안팀의 전제는 더 이상 유효하지 않게 되었습니다.

오늘날 모든 보안팀이 직면한 첫 번째 현실은 취약점의 폭발적인 증가입니다. 에이전트 덕분에 소프트웨어 취약점을 발견하고 보고하는 일이 훨씬 쉬워졌습니다. 퍼스트 파티 코드와 오픈소스 종속 항목에서 보고되는 취약점이 몇 배로 늘어나면서 사람이 직접 처리하는 기존의 취약점 분류 체계로는 감당하기 어려운 수준이 되었습니다.

하지만 더 근본적인 문제는 시간입니다. 취약점 파악은 더 이상 방어의 결정적인 단계가 아닙니다. 공격자가 약점을 몇 시간 만에 익스플로잇으로 전환하는 자율 도구를 보유한 상황에서는 취약점이 발견된 시점부터 패치가 프로덕션 환경에 배포되기까지 걸리는 시간, 즉 해결 지연 시간 자체가 새로운 취약점이 되고 있습니다.

Google Cloud CISO인 Chris Betz에 따르면 "소프트웨어 보안 업계에서 취약점을 알고도 수정사항을 신속하게 개발하고 배포하지 못하면 조직은 계속 위험에 노출됩니다. 공격 자동화로 익스플로잇까지 걸리는 시간이 크게 단축되면서 이제 대응 지연이 가장 중요한 위험 요인이 되었습니다."

취약점 발견 건수는 기하급수적으로 증가하는 반면 해결 작업은 여전히 사람의 작업 속도에 따라 선형적으로 진행된다면, 보안 격차는 계속 벌어질 수밖에 없습니다. 이에 Google은 에이전트 기반 공격에 대응하기 위해 방어용 에이전트를 개발했습니다.

복잡한 Fleet을 아우르는 전사적 보안 대응 조율

Google은 수만 개의 서로 다른 서비스를 운영하고, 방대한 퍼스트 파티 코드 저장소를 관리하며, 수천 개의 오픈소스 패키지에 의존하고 있습니다. 사업부마다 운영 주기와 배포 요구사항도 다릅니다.

소프트웨어 업계 전반에서 에이전트 기반 취약점 탐지가 가속화되자 Google은 각 팀이 개별적으로 대응할 경우 도구가 파편화되고 작업이 중복되며 심각한 보안 사각지대가 발생할 수 있다는 점을 인식했습니다. 전사적으로 대응을 조율하면 도구 배포를 중앙에서 관리하고 보안 기능을 개발 파이프라인 깊숙이 통합할 수 있습니다.

목표는 명확했습니다. 모든 제품 영역에 중앙 집중식 취약점 탐지 도구, 자동 패치 서비스, 배포 파이프라인을 제공하여 머신 속도로 진화하는 위협에 대응할 수 있게 하는 것입니다.

무엇보다 Google은 이 문제를 혼자 해결하려 하지 않았습니다. 현대 소프트웨어는 서로 긴밀하게 연결된 오픈소스 생태계를 기반으로 하므로 엔터프라이즈 보안은 공동의 책임이기도 합니다. Google은 Project Glasswing과 같은 이니셔티브를 통해 업계 파트너들과 협력하며 고급 추론 모델이 취약점을 발견하는 방식을 연구했습니다. 

동시에 오픈소스 재단 및 유지보수 담당자들과의 협력을 확대하여 모두가 함께 사용하는 디지털 자산을 보호하는 데 힘쓰고 있습니다.

핵심 아키텍처: 에이전트 기반 스캔과 자동 패치

기존 취약점 스캐너는 정기적으로 일괄 검사를 실행하여 위험한 코드 패턴과 알려진 취약점이 있는 종속 항목을 찾아낸 다음, 엔지니어가 직접 조사할 수 있도록 티켓을 생성합니다. 하지만 수천 건의 새로운 취약점 보고가 머신 속도로 쏟아지는 상황에서는 이러한 수동 인계 방식이 한계에 부딪힙니다.

이 문제를 해결하기 위해 Google은 수동적인 취약점 탐지에서 능동적인 해결로 전환하는 내부 프로그램인 Project Fortify를 구축했습니다. Project Fortify는 취약점을 지속적으로 탐색하고 자동 패치 생성을 직접 수행하도록 지원하는 에이전트 기반 스캔 플랫폼입니다. 

Google은 탐지와 수정을 별개의 작업으로 취급하는 대신, 탐지-수정-배포 파이프라인을 통해 자율적인 취약점 탐지를 자동 코드 수정과 직접 연결했습니다.

하지만 모든 시스템의 위험 수준이 같은 것은 아닙니다. 중요 기반 시설, 주요 ID 서비스, 경계 프록시의 경우 제품 영역별로 스캐너를 조정해 높은 재현율을 우선시할 수 있습니다. 오탐이 다소 증가하더라도 실제 취약점을 가능한 한 많이 찾아내는 방식입니다. 이러한 핵심 애셋을 담당하는 팀은 잠재적 취약점을 하나라도 놓치지 않도록 더 많은 수동 검토 작업을 감수합니다.

보안팀은 이 위험 모델에 파라미터를 할당하여 중앙에서 제공하는 공통 자동화 기능을 활용하면서도 각 팀의 위험 허용 수준에 맞게 운영할 수 있습니다.

Google이 배포하고 오픈소스로 공개한 도구

자율 보안 시스템을 대규모로 운영하려면 새로운 시스템을 구축해야 합니다. Google은 이러한 도구를 더 넓은 커뮤니티와 공유하기 위해 노력하고 있습니다.

• Mantis 오픈소스 스캐너: 코드베이스 요약과 샌드박스 기반 자동 검증을 결합한 보안 감사용 멀티 에이전트 프레임워크입니다.

• Chrome의 패치 주기 단축: Google Chrome 보안팀은 보안 업데이트 주기를 단축해 취약점 발견 후 며칠 내에 브라우저 수정사항을 제공할 수 있도록 했습니다.

• 오픈소스 유지보수 지원: Google은 OpenSSF와 협력해 핵심 업스트림 라이브러리를 위한 인프라와 취약점 분류 도구에 자금을 지원하고 있습니다.

• OSS-Fuzz의 CodeMender: Google에서 OSS-Fuzz에 CodeMender를 추가함에 따라 퍼징 대상으로 등록된 프로젝트의 오픈소스 유지보수 담당자에게 CodeMender가 생성한 패치를 무료로 제공합니다.

취약점 탐지와 수정을 넘어서는 접근방식

탐지-수정-배포 주기를 자동화하는 것은 필수적이지만, 취약점을 발견한 후 패치를 적용하는 것만으로는 충분하지 않습니다. Google은 사후 대응 중심의 패치에서 한 걸음 더 나아가 근본적인 보안 방어 역량을 강화하는 데 지속적으로 투자하고 있습니다.

• 메모리 안전성 강화: Rust와 같은 메모리 안전 언어의 사용을 Android, Chrome, 핵심 인프라 전반으로 확대하고 있습니다. 

• 아키텍처 불변성: 플랫폼 계층에서 보안 프레임워크를 강제 적용하여 일반적인 버그가 처음부터 발생하지 않도록 합니다.

• 에이전트 기반의 지속적인 보안 검증: 모든 코드 커밋에서 보안 보장 조건을 검증하는 자율 에이전트 체계로 전환합니다.

2026년에 효과적으로 보안을 유지하려면 위협과 같은 속도로 작동하는 자율 시스템이 필요합니다. 취약점 분류부터 수정, 배포까지 걸리는 시간을 단축하는 개발자와 보안 엔지니어는 수동으로 취약점을 분류하는 작업에서 벗어나 엔터프라이즈를 안전하게 보호하는 자율 시스템을 감독하는 역할에 집중할 수 있습니다.

Google Cloud의 최신 위협 관리 접근 방식에 대해 자세히 알아보려면 CISO 인사이트 허브를 확인하세요.