AI가 쏟아내는 취약점, 보안 업계의 두 기둥이 동시에 흔들린다

요즘 보안 업계에 묘한 긴장감이 감돕니다. AI 코드 스캐너와 LLM 기반 퍼저(fuzzer)가 하루에 수백, 수천 건의 취약점 후보를 쏟아내기 시작하면서, 오랫동안 신성하게 여겨졌던 두 가지 관행이 동시에 흔들리고 있기 때문인데요. 바로 책임 공개(Responsible Disclosure)와 버그바운티(Bug Bounty)입니다. 두 문화는 서로 다른 철학에서 출발했지만, 공통적으로 “사람이 시간을 들여 찾은 진짜 취약점"이라는 전제 위에 서 있었습니다. 그 전제가 지금 무너지고 있습니다.

책임 공개라는 신사 협정의 배경

책임 공개는 1990년대 후반부터 자리 잡은 일종의 신사 협정입니다. 보안 연구자가 취약점을 발견하면, 공개하기 전에 먼저 벤더에 알리고 패치할 시간을 줍니다. 보통 90일이 표준이죠. 구글 프로젝트 제로(Project Zero)가 이 기준을 사실상 굳혔습니다.

이 모델이 작동하려면 두 가지 전제가 필요합니다. 첫째, 연구자가 발견하는 취약점의 양이 벤더가 처리할 수 있는 규모여야 합니다. 둘째, 보고된 취약점이 대체로 진짜여야 합니다. 사람이 손으로 분석하던 시대에는 두 조건 모두 자연스럽게 충족됐습니다.

그런데 AI가 등장했습니다

GPT-5급 모델과 전용 보안 LLM이 코드베이스를 통째로 삼키고 취약점을 자동 생성하기 시작했습니다. 한 명의 연구자가 하루에 수백 건의 잠재 취약점 보고서를 만들어낼 수 있게 됐습니다. 문제는 이 보고서들의 상당수가 가짜라는 점입니다.

오픈소스 메인테이너 커뮤니티에서는 이미 비명이 터져 나왔습니다. curl 메인테이너 다니엘 스텐베리는 작년부터 “AI가 만든 슬롭(slop) 취약점 보고가 일과의 절반을 잡아먹는다"고 공개적으로 분노해왔습니다. 보고서는 그럴듯한 영어로 작성되고, 코드 스니펫까지 포함돼 있어 처음 보면 진짜처럼 보입니다. 그런데 깊이 파보면 함수 시그니처가 틀렸거나, 존재하지 않는 API를 참조하거나, 흐름 자체가 말이 안 되는 경우가 태반입니다.

버그바운티는 더 직접적인 타격

책임 공개가 신뢰의 문제라면, 버그바운티는 돈의 문제입니다. 해커원(HackerOne), 버그크라우드(Bugcrowd) 같은 플랫폼은 “유효한 취약점에 보상금을 지급한다"는 단순한 규칙으로 굴러갑니다. 그런데 AI 보고서가 쏟아지면서 이 경제 모델이 삐걱거리고 있습니다.

트리아지(triage) 비용이 폭증하고 있습니다. 진짜 취약점 한 건을 찾기 위해 가짜 보고서 수십 건을 검수해야 합니다. 일부 기업은 이미 프로그램을 일시 중단하거나, AI 보고서를 명시적으로 금지하는 조항을 추가했습니다. 반대로 일부 헌터는 AI를 잘 활용해 보고 처리량을 몇 배로 늘리며 상위권을 휩쓸고 있습니다. 정직한 헌터와 슬롭 양산자를 구분하기가 점점 어려워지고 있습니다.

그래서 누가 이득을 보는가

역설적이지만, 가장 큰 이득을 보는 쪽은 공격자일 수 있습니다. 방어자 측이 가짜 보고서 분류에 자원을 소모하는 동안, 공격자는 같은 AI 도구로 진짜 취약점을 찾아 패치 전에 악용할 수 있습니다. 방어와 공격의 비대칭이 다시 한번 벌어지는 셈입니다.

대형 벤더들은 이미 대응책을 준비 중입니다. AI 보고서에 별도의 검증 절차를 요구하거나, PoC(개념 증명) 코드 첨부를 의무화하는 식입니다. 하지만 이는 진짜 연구자에게도 진입 장벽을 높이는 부작용을 낳습니다.

두 문화가 동시에 재설계되어야 합니다

책임 공개와 버그바운티는 지난 20년간 보안 생태계를 떠받친 두 기둥이었습니다. 이 둘이 동시에 흔들린다는 건, 개별 정책 수정으로 해결될 문제가 아니라 보안 보고의 경제학과 윤리 자체를 다시 설계해야 한다는 신호입니다.

여러분이 만약 오픈소스 프로젝트를 운영하거나 사내 보안 프로그램을 담당한다면, 지금 한 번쯤 자문해볼 때입니다. AI 슬롭이 일주일치 보고의 절반을 차지하는 시대가 와도 우리 프로세스가 버틸 수 있을까요? 그리고 진짜 좋은 연구자를 식별할 시그널은 무엇이 되어야 할까요?