구글이 6월에 크롬 버그를 역대급으로 고쳤다는데, 이게 좋은 소식일까요

구글이 최근 크롬 보안 성과를 자랑하고 다닙니다. 한 달 만에 지난 2년치를 합친 것보다 많은 메모리 안전성 버그를 고쳤다는 겁니다. 숫자만 보면 대단합니다. 그런데 보안 업계 반응은 묘하게 미지근합니다. “고친 버그가 많다"는 게 정말 안전해졌다는 뜻인지, 아무도 확신을 못 하거든요.

먼저 솔직히 말씀드릴 게 있습니다. 이번 주제는 커뮤니티 데이터가 거의 안 잡혔습니다. 지난 30일간 레딧에서 이 논쟁을 정면으로 다룬 스레드를 못 찾았습니다. 그래서 이 글은 실시간 여론 분석이라기보다, 그동안 쌓인 맥락을 놓고 “이 숫자를 어떻게 읽어야 하는가"를 따져보는 쪽에 가깝습니다.

무슨 일이 벌어지고 있나

구글은 2024년부터 Big Sleep이라는 프로젝트를 밀고 있습니다. 딥마인드와 프로젝트 제로가 함께 만든 LLM 기반 취약점 탐색 에이전트입니다. 사람이 코드를 읽다가 “여기 이상한데” 하고 감을 잡는 과정, 그걸 모델에게 시키는 겁니다.

이게 왜 중요하냐면 기존 퍼징과 성격이 다르기 때문입니다. 전통적인 퍼저는 무작위 입력을 때려 넣어 크래시를 냅니다. 빠르고 싸지만 코드 흐름을 이해하지는 못합니다. 반면 Big Sleep 같은 접근은 코드의 의미를 읽습니다. “이 함수는 해제된 포인터를 다시 쓸 수 있겠는데?” 이런 식으로 짚어내는 거죠.

여기에 OSS-Fuzz의 AI 강화 버전이 붙으면서 취약점 발견 속도가 계단식으로 올라갔습니다. 크롬처럼 코드베이스가 거대하고 공격 표면이 넓은 프로젝트일수록 효과가 큽니다. 크롬 코드는 수천만 줄 규모입니다. 사람 손으로 전수 검사할 크기가 아닙니다.

“많이 고쳤다"가 왜 애매한 지표인가

여기서부터가 진짜 쟁점입니다. 패치 건수는 완전히 다른 두 가지 이유로 늘어날 수 있습니다.

첫째, 발견 능력이 좋아져서. 원래 있던 버그를 이제야 찾아낸 경우입니다. 이건 좋은 뉴스입니다. 동시에 “그동안 이 버그들을 안고 브라우저를 써왔다"는 뜻이기도 하고요.

둘째, 코드가 원래 그만큼 취약해서. 발견 도구가 좋아진 게 아니라 새로 짜는 코드에서 버그가 계속 나온다는 신호일 수도 있습니다.

구글의 발표는 첫 번째 해석을 깔고 있습니다. 하지만 외부에서는 둘을 구분할 방법이 없습니다. 패치 건수만 봐서는 발견율과 생성율을 갈라낼 수가 없으니까요. 보안 지표의 오래된 함정입니다. 병원이 진단 장비를 새로 들이면 확진자 수가 급증합니다. 그렇다고 도시가 갑자기 병들었다고 하지는 않죠. 거꾸로 확진자가 늘었으니 이제 안전하다고 말하는 것도 이상하고요.

방어 우위론과 그 반박

AI 취약점 탐색을 두고 낙관론자들은 방어자가 구조적으로 유리하다고 말합니다. 방어자는 소스 코드 전체를 쥐고 있습니다. 빌드 파이프라인도 자기 손안에 있고 CI에 퍼저를 무제한으로 돌릴 수도 있죠. 공격자는 바이너리만 붙잡고 씨름해야 합니다. 같은 AI 도구를 줘도 방어자 쪽 효율이 훨씬 높다는 논리입니다.

반박도 만만치 않습니다. 핵심은 비대칭성입니다. 방어자는 발견한 버그를 전부 고쳐야 하지만 공격자는 하나만 찾으면 됩니다. AI가 양쪽 발견 속도를 똑같이 10배 올려줘도 이 비대칭은 그대로입니다. 오히려 벌어질 수도 있습니다. 고쳐야 할 절대량이 늘면 패치 파이프라인 자체가 병목이 되니까요.

패치 자체도 공격 정보가 됩니다. 오픈소스 프로젝트에서 커밋이 공개되면 그 diff를 읽고 원래 취약점을 역산하는 건 오래된 기법입니다. 이제는 그 역산도 AI에게 시킬 수 있습니다. n-day 익스플로잇 제작이 그만큼 빨라진다는 뜻입니다. 크롬처럼 사용자가 수십억 명인 소프트웨어에서는 패치가 다 퍼질 때까지 며칠이 그대로 공격 창구가 됩니다.

그래서 실제로 뭐가 달라졌나

냉정하게 보면 확실히 달라진 건 두 가지입니다.

하나는 비용 구조입니다. 예전에는 숙련된 보안 연구자 한 명의 시간이 병목이었습니다. 이제는 컴퓨팅 비용이 병목입니다. 사람 대신 GPU를 더 사면 되는 문제로 바뀐 겁니다. 자본이 있는 조직에 유리하죠. 구글, 마이크로소프트 같은 곳 말입니다. 문제는 인터넷 인프라 상당수가 관리자 한두 명이 유지하는 오픈소스라는 겁니다. 이쪽에는 GPU 예산이 없습니다.

다른 하나는 버그 리포트의 홍수입니다. 이미 curl 같은 프로젝트에서는 AI가 만든 저품질 취약점 신고 때문에 관리자가 지친다는 이야기가 나왔습니다. 진짜 버그와 환각을 가려내는 데 사람 시간이 들어갑니다. 발견 도구가 싸지면 노이즈도 같이 싸집니다.

구글의 6월 성과는 이 두 조건이 다 갖춰진 곳에서 나왔습니다. 돈이 있고 리포트를 걸러낼 전담 인력이 있습니다. 패치를 하루 만에 배포할 인프라도 있고요. 크롬에서 통했다고 생태계 전체가 안전해지는 건 아닙니다.

그럼 이 숫자를 어떻게 읽어야 할까

패치 건수 대신 볼 만한 지표가 있습니다. 취약점이 코드에 들어간 시점부터 고쳐질 때까지 걸린 시간, 이른바 버그 수명입니다. 이 숫자가 짧아진다면 발견 능력이 실제로 개선된 겁니다. 반대로 패치 건수만 늘고 수명이 그대로라면 그냥 뒤늦게 청소하는 중일 수도 있습니다.

또 하나는 실제 공격에 쓰인 제로데이 건수입니다. 크롬은 매년 여러 건의 인더와일드 제로데이를 겪어왔습니다. AI 방어가 정말 우위를 만들었다면 이 숫자가 줄어야 합니다. 아직 그런 추세는 뚜렷하지 않습니다.

구글이 나쁜 일을 한다는 말은 전혀 아닙니다. 크롬 사용자 입장에서 버그가 더 많이, 더 빨리 고쳐지는 건 그냥 좋은 일입니다. 다만 “많이 고쳤다"를 “이제 안전하다"로 번역하는 순간 논리가 하나 빠집니다. 여러분이 쓰는 소프트웨어 중에 구글만큼 예산을 못 쓰면서 같은 규모의 AI 버그 리포트를 감당해야 하는 프로젝트가 몇이나 될까요. 진짜 문제는 아마 그쪽에서 먼저 터질 겁니다.