Executive Summary

구글 오픈소스 취약점 포상 프로그램은 2022년 8월에 생겼다. 구글이 관리하는 오픈소스 저장소에서 결함을 찾아 보내면 돈을 주는 창구다. 보상 대상은 크게 세 범주로 나뉘어 있었다. 공급망 침해, 제품 취약점, 그리고 기타 보안 이슈다. 2026년 10월 1일에 접수가 닫힌 것은 그중 둘째다.

규칙 페이지의 제품 취약점 절 첫 문단이 그 사실을 적는다. 아래는 2026년 10월 6일에 받은 전문의 축자 번역이고, 굵게 표시한 것도 원문 그대로다.

2026년 10월 1일부로 우리는 OSS VRP에 제출되는 제품 취약점을 더 이상 받지 않는다. 구글 클라우드 제품에 영향을 주는 일부 구글 클라우드 저장소에 대해서는 클라우드 VRP를 통해 제품 취약점 보고를 계속 받을 수 있다. 우리는 OSS VRP의 이 부분을 계속 다듬어 나갈 것이며 2027년 1분기에 업데이트를 드릴 것을 약속한다. 그동안에는 우리의 다른 VRP 프로그램에서 영향을 찾아 그쪽으로 제출하거나, 패치 리워드 프로그램을 이용하기를 권한다. 이 변경은 2026년 10월 1일 이전에 제출된 제품 취약점에는 영향을 주지 않는다. 원문: "As of October 1, 2026, we are no longer accepting product vulnerabilities submitted to the OSS VRP. … We will continue to reformat and work on this aspect of the OSS VRP and commit to giving an update in Q1 2027. … This change does not affect product vulnerabilities submitted before October 1, 2026." — Google Bug Hunters, OSS VRP Rules(2026-10-06 수신)

이 문단에서 읽어야 할 것이 셋이다. 첫째, 닫힌 범주는 제품 취약점 하나다. 공급망 침해 제보는 그대로 받는다. 둘째, 2027년 1분기에 약속한 것은 재개가 아니라 업데이트다. 다시 연다는 말도, 어떤 조건이면 연다는 말도 이 문단에 없다. 셋째, 구글은 갈 곳을 두 군데 가리켜 뒀다. 다른 VRP 프로그램과 패치 리워드 프로그램이다. 뒤에서 보겠지만 이 두 곳의 성격이 이 글의 축이다.

1.1보상표에서 비워진 것은 한 줄이다

규칙 페이지에는 보상표가 그대로 남아 있다. 저장소 등급은 OT0에서 OT3까지 넷으로 나뉘고, 플래그십에 가까울수록 보상이 크다. 그 표에서 제품 취약점 줄만 네 칸이 모두 비었다. 나머지 두 줄은 살아 있다.

2026년 10월 6일 수신한 규칙 페이지의 라이브 보상표를 그대로 옮겼다. 보상표가 통째로 비었다고 적으면 틀린다. 비워진 줄은 하나다.

이 프로그램이 출범할 때의 보상 범위는 100달러에서 31,337달러까지였다. 지금 남아 있는 공급망 제보의 하한이 500달러인 것은 하한을 올렸기 때문이 아니라, 4년 사이에 저장소 등급제가 들어오면서 표 자체가 다시 짜였기 때문이다.

1.2왜 닫았는지는 X 포스트 한 건에만 적혀 있다

사유를 밝힌 문장은 규칙 페이지에 없다. 10월 6일에 받은 전문에는 일시 중단이나 자동 제보, 급증, AI 같은 말이 한 번도 나오지 않는다. 사유가 적힌 곳은 구글 VRP 공식 계정이 10월 1일에 올린 X 포스트 하나다.

이번 중단은 자동 제출이 크게 늘었고 그 대다수가 유효하지 않기 때문이다. 우리는 OSS VRP의 이 부분을 계속 다듬어 나갈 것이며 2027년 1분기에 업데이트를 드릴 것을 약속한다. 원문: "This pause is due to a significant rise in automated submissions, the vast majority of which are not valid. …" — @GoogleVRP, 2026-10-01 16:00 UTC

구글 버그헌터스 블로그의 공개 피드를 2023년 8월부터 2026년 9월 24일까지 전수로 훑어도 이 중단을 알리는 포스트 자체가 없다. 즉 세계에서 가장 큰 포상 프로그램 가운데 하나가 접수를 닫으면서, 그 이유를 적은 자사 매체는 소셜 미디어 글 한 건이 전부다. 같은 날 보도한 매체 넷 가운데 셋은 사유를 X 포스트에만 귀속했고, 한 곳은 공지가 프로그램 안내에도 올랐다고 적었는데 그 기사가 안내에서 직접 인용한 문장은 사유 문장이 아니었다. 규칙 페이지에서 사유 문장이 지워졌다고 쓸 근거는 찾지 못했다. 아카이브 서비스가 모두 막혀 과거 판본을 대조할 수 없었기 때문이다.

10월 1일의 공지만 보면 갑작스러운 결정으로 읽힌다. 그 전 반년 남짓의 공지를 날짜순으로 늘어놓으면 다른 그림이 나온다. 구글은 같은 해에 포상 창구를 네 번 손봤고, 그중 셋이 오픈소스 프로그램이고 하나는 크롬·안드로이드 프로그램이다. 네 번 모두 구글 버그헌터스의 공식 공지에 적혀 있다.

4월의 유인 제거는 3월 19일 포스트에 사후 삽입된 갱신 블록에 들어 있고, 그 블록에는 날짜가 없다.

2.13월에 요구한 것은 증거였다

첫 손질은 3월 19일에 왔다. 구글은 상위 두 등급 저장소의 메모리 손상 제보에 둘 중 하나를 요구하기 시작했다. 퍼징 인프라에서 돌릴 수 있는 정확한 재현 절차를 붙이거나, 아니면 해당 저장소에 이미 머지된 패치를 붙이라는 것이다. 왜 그렇게 했는지도 같은 규칙 페이지에 적어 뒀다. 중요한 프로젝트는 되도록 퍼징 인프라에 통합하는 쪽이 개별 메모리 손상 제보를 사람이 하나씩 판정하는 것보다 더 튼튼하고 규모를 키울 수 있는 방어라는 것이다.

같은 규칙에 구멍이 하나 남아 있었다. 메모리 손상이 아닌 취약점은 같은 등급에서도 머지된 패치가 필요 없다고 규칙 원문이 그대로 적는다. 증거 없이 낼 수 있는 면이 남았다는 뜻이다. 이 문장은 규칙 원문에 있는 사실이다. 그 구멍 때문에 반년 남짓 뒤 접수 중단까지 갔다는 것은 이 글의 추론이지 구글의 설명이 아니다.

2.24월에는 보상을 없애고 읽는 것도 멈췄다

두 번째 손질은 3월 포스트 안에 조용히 들어왔다. 구글은 그 포스트에 4월 갱신 블록을 덧붙여, 하위 두 등급 저장소의 제품 취약점과 기타 보안 이슈에는 보상도 크레딧도 주지 않겠다고 적었다. 그리고 한 문장을 더 붙였다. 구글 보안팀은 이 제보들을 트리아지하지 않겠다는 문장이다. 보상만 끊은 것이 아니라 읽는 것 자체를 멈추겠다고 선언한 셈이다. 같은 블록에서 하위 등급 공급망 제보의 상한도 3,133.70달러로 내렸다.

이 갱신에는 날짜가 없다. 원문에 적힌 것은 4월이라는 달 이름뿐이고, 피드상 포스트 날짜는 3월 19일 그대로다. 구글이 기존 포스트를 제자리에서 고쳤기 때문이다. 그래서 이 글도 4월 며칠이라고 적지 않는다.

2.3다섯 달 전, 같은 회사가 다른 창구는 증거를 요구하며 열어 뒀다

세 번째 손질이 이 글의 축이다. 2026년 4월 30일, 구글은 크롬과 안드로이드 포상 프로그램을 AI 시대에 맞게 개편한다는 공지를 올렸다. 닫는 쪽이 아니라 요건을 바꾸는 쪽이었다.

AI는 길고 상세한 설명문을 쓰는 일을 손쉽게 만들었다. 앞으로 우리 프로그램의 초점은 버그가 존재한다는 구체적 증거를 우선하는 쪽으로 옮겨 간다. 우리는 이제 가장 효과적인 보고란 간결한 것, 곧 우리가 사안을 검증하고 배분하는 데 필요한 재현기와 산출물만 담은 것이라고 본다. 원문: "While AI has made it effortless to produce lengthy, detailed write-ups… we are shifting our program's focus to prioritize concrete proof that a bug exists. We now consider the most effective reports to be concise, containing only a reproducer and the necessary artifacts to help us validate and route the issue." — Evolving the Android & Chrome VRPs for the AI Era(2026-04-30)

구글은 요구만 한 것이 아니다. 같은 글에서, 연구자가 권한 있는 프로세스의 임의 읽기·쓰기나 통제된 브라우저 메모리 유출을 증거로 제시할 수 있도록 연구자 전용 크롬 빌드를 따로 배포하겠다고 적었다. 증거를 내라고 요구하면서 증거를 만들 도구를 함께 주겠다는 설계다.

안드로이드 쪽도 같은 방향이다. 리눅스 커널 취약점은 악용 가능성의 구체적 증명이 없으면 구글이 관리하는 구성요소로 범위를 좁히겠다고 했고, 대부분의 취약점에 대해 제안 패치를 담은 보고를 강하게 장려하겠다고 적었다. 그리고 자동화된 AI 도구가 찾기에 여전히 어려운 범주를 우선하겠다고 덧붙였다. 보상은 오히려 올라갔다. 안드로이드 최상단이 100만 달러에서 150만 달러가 됐다. 반대로 폐지된 것도 있다. 원격 코드 실행과 렌더러 임의 읽기·쓰기에 붙던 특별 보너스인데, 폐지 이유가 AI가 이런 기법의 시연을 거의 일상으로 만들었다는 것이다.

AI가 쏟아 낸 보안 제보라고 하면 보통 가짜를 떠올린다. 없는 취약점을 그럴듯하게 써 보내는 것 말이다. 구글이 3월 블로그에서 비용의 원인으로 적은 것은 두 범주였고, 가짜는 그중 하나일 뿐이다.

취약점이 어떻게 촉발되는지에 관해 잘못된 정보나 환각을 담은 AI 생성 보고. 원문: "AI-generated reports that contain incorrect information or 'hallucinations' about how a vulnerability might be triggered."

두 번째 범주는 거짓 제보가 아니다. 지적한 코딩 오류가 실제로 그 자리에 있고, 가리킨 코드 줄도 틀리지 않은 경우다.

버퍼 오버플로 같은 코딩 오류를 가리킨다는 점에서는 기술적으로 유효하지만, 해당 프로젝트의 보안 모델에 비춰 보안 영향이 미미하거나 도달 가능한 코드 경로에 있지 않은 보고의 홍수. 원문: "A flood of reports that, while technically valid in pointing to a coding error like a buffer overflow, have negligible security impact given the project's security model or are not in reachable codepaths." — Streamlining Google's OSS VRP: Key Rule Updates(2026-03-19)

뒤의 범주가 비용의 본체다. 가짜는 짧게 반박하고 닫을 수 있다. 재현이 안 되면 그걸로 끝이다. 그런데 버퍼 오버플로가 실제로 거기 있고 코드도 정확히 가리키는데 그 경로에 바깥에서 도달할 수 없는 제보는 다르다. 기각하려면 사람이 그 프로젝트의 위협 모델을 알아야 하고, 호출 그래프를 따라가 도달 가능성을 판정해야 한다. 맞는 제보가 틀린 제보보다 비싼 구조다.

구글 자신의 결론 문장도 거기 있다. 밀을 보상하고 싶지 쭉정이를 보상하고 싶지 않다는 것, 그리고 모호한 보고를 트리아지하는 데서 실행 가능하고 영향이 큰 수정을 보상하는 쪽으로 초점을 옮긴다는 것이다.

3.1제보를 만드는 돈과 처리하는 돈의 차이가 실측돼 있다

검증이 생산보다 비싸다는 말은 오래된 직관이지만, 그 격차를 달러로 잰 연구가 2026년에 나왔다. 소프트웨어공학 학회 MSR 2026에 실린 적대적 버그 리포트 연구는 자동 프로그램 수리 에이전트를 공격 대상으로 놓고, 공격자가 쓰는 돈과 방어자가 쓰는 돈을 같은 잣대로 쟀다.

출처는 arXiv 2509.05372 v2 본문 6.6절이다. 논문은 이 격차를 자릿수 비대칭이라고 부른다. 0.87달러는 자동 수리 에이전트를 돌리는 돈이지 사람이 한 건을 판정하는 돈이 아니다.

만드는 데 0.000295달러, 처리하는 데 0.87달러다. 약 2,950배다. 더 아픈 대목은 그다음이다. 그 돈을 다 쓰고도 51건 가운데 46건, 곧 90.2%에서 공격자가 의도한 대로 패치가 나왔다. 보안연구자와 침투테스터 두 사람이 따로 손으로 확인한 결과다.

방어 쪽 성적표는 더 선명하다. 가장 성적이 좋은 사전 필터가 51건 중 24건을 잡아 47.05%였고, 사후 코드 리뷰 도구가 모든 신뢰도 등급을 합쳐 58.82%였다. 사람이 그 리뷰 코멘트를 읽어야 판정이 된다는 단서가 붙는다. 가장 센 조합을 다 붙여도 차단율 상한이 72.5%이고, 저자들은 그 조합이 오탐을 늘려 실제 운영에서는 비현실적일 수 있다고 적는다. 그리고 가장 선명한 한 수가 남아 있다. 정적 분석기 CodeQL은 51건 가운데 한 건도 잡지 못했다.

3.2도달할 수 없는 코드라는 말에는 학술 대응물이 있다

구글이 3월에 쓴 도달 가능한 코드 경로에 있지 않다는 표현은 학술 쪽에도 같은 자리가 있다. 오픈소스 저장소 2,414곳을 대상으로 소프트웨어 자재명세서 기반 취약점 스캐너의 출력을 검사한 연구가 위양성률 92.0%를 보고하면서, 그 주된 원인으로 도달할 수 없는 코드 안의 취약점을 경보로 올리는 것을 지목했다. 함수 호출 관계를 따져 걷어낼 수 있었던 비중이 61.9%다.

여기서 모수를 반드시 가려야 한다. 92.0%는 스캐너가 올린 경보의 모수에서 나온 값이다. 사람이 손으로 쓴 제보의 모수가 아니다. 이것을 제보의 92%가 쓸모없다는 말로 옮기면 거짓이 된다. 버그바운티 제보 모수에서 맞지만 도달 불가능한 것의 비중을 잰 연구는 이 글을 준비하면서 찾지 못했다. 그 공백 자체가 지금 상황을 말해 준다. 모두가 이 범주가 비용의 원인이라고 말하는데, 그 비중을 공개 수치로 가진 쪽은 아무도 없다.

리뷰어들이 실제로 쓰는 분류에도 이 범주가 이름으로 있다. 공개된 버그바운티 제보 9,942건의 기각 사유를 분류한 연구는 위험 평가, 경로 노출, 의도된 동작이라는 항목을 따로 세웠고, 각각 유효하지만 영향이 낮다고 평가된 발견, 보안 영향 없는 파일 경로 노출, 프로젝트가 받아들인 설계상의 절충이라고 정의한다. 다만 이 논문에서 비율을 끌어내서는 안 된다. 범주별 건수가 없고, 표본이 공개된 제보라 유효한 쪽으로 기울어 있기 때문이다.

부수적으로 눈에 띄는 발견이 하나 있다. 같은 연구가, 평판이 높은 제보자가 경계선에 있는 사례에서 유리한 판정을 받는 경향을 관측했다. 사람의 판정이 제보 내용 바깥의 신호에도 반응한다는 뜻이다. 우리가 콘텐츠 파이프라인의 검증 단계를 설계하면서 같은 문제를 다룬 적이 있다.

구글만 그런 것이 아니다. 2026년 1월부터 10월까지, 오픈소스 보안 제보를 받는 창구들이 잇따라 규칙을 바꿨다. 아래 표는 당사자 공지로 확인한 것만 날짜순으로 모은 것이고, 각 사건을 장치의 성격으로 분류했다.

모두 당사자 공지나 공식 블로그에서 확인한 날짜다. 인텔 건은 보도일이 9월 18일과 19일로 갈려 둘 다 적었다.

4.1한 흐름처럼 보이지만 사유는 넷이 다 다르다

포상을 접은 곳들을 묶어 AI 때문이라고 적으면 편하다. 당사자 공지를 하나씩 펴면 사유가 넷으로 갈린다. 뭉뚱그리면 이 사건의 모양이 흐려진다.

• curl은 지어낸 거짓말을 제출할 유인을 없애려는 시도라고 스스로 밝혔다. 같은 공지에서 세 가지 흐름을 함께 지목했는데, 정신을 멍하게 만드는 AI 쓰레기, 그 어느 때보다 질이 낮아진 사람, 그리고 돕기보다 구멍을 들쑤시려는 태도다.
• 인터넷 버그 바운티는 AI 보조 연구가 생태계 전반의 취약점 발견을 넓히고 있으며 오픈소스에서 발견과 수선 사이의 균형이 실질적으로 바뀌었다고 적었다.
• Node.js의 사유는 돈이다. 공지 제목 자체가 자금 상실로 인한 중단이고, AI라는 말이 공지에 한 번도 나오지 않는다. 다만 그 자금원이 인터넷 버그 바운티였다. AI 제보 급증이 그 프로그램의 접수를 멈추게 했고, 그래서 공용 자금이 사라졌고, 예산 없는 프로젝트의 포상이 사라졌다. 두 다리를 건너 도달한 셈이다.
• 인텔은 이유를 밝히지 않았다. 최초 보도도 이 변경의 이유에 관한 공식 언급이 없다고 썼고, 인텔이 내놓은 대체 프로그램의 자기 서술은 보상 없는 책임 공개 프로그램이다. 이유를 밝히지 않는 것 역시 2026년 현장의 한 모습이다.

인터넷 버그 바운티의 공지에는 눈여겨볼 설계가 하나 더 있다. 접수를 멈추면서 동시에, 자격을 갖춘 오픈소스 프로젝트에는 AI 보조 트리아지 기능을 포함한 플랫폼 이용권을 기업용 라이선스와 같은 수준으로 무상 제공하겠다고 적었다. 돈은 끊고 검증 도구는 준 것이다. 유인 제거라고만 부르기에도, 접수 중단이라고만 부르기에도 맞지 않는 칸이다.

4.2curl은 전후를 수로 공개한 유일한 곳이다

구글도 깃허브도 증명 요구의 전후 효과를 수치로 내놓지 않았다. 공지 어디에도 없다. 요건을 걸고 그 결과를 공개한 곳은 curl 하나이고, 메인테이너 대니얼 스텐베리가 자기 블로그에 다섯 차례에 걸쳐 적었다.

스텐베리의 2026년 1월 26일·2월 25일·4월 22일·5월 26일·6월 29일 포스트를 종합했다. 2025년 유효율에 관해 그는 스무 건 중 한 건도 진짜가 아니었다고 적었다.

보상 없이 플랫폼에 복귀한 뒤의 국면에서 스텐베리는 쓰레기 제보가 더는 문제가 아니라고 판단했다. 유효율을 범위로 내놓은 것도 그 포스트다.

슬롭 상황은 더 이상 문제가 아니다. 확인된 취약점의 비율이 AI 이전인 2024년 수준으로 돌아왔고 심지어 그것을 넘어섰다. 대략 15~16% 범위다. 원문: "The slop situation is not a problem anymore." / "The rate of confirmed vulnerabilities is back to and even surpassing the 2024 pre-AI level, meaning somewhere in the 15-16% range." — Daniel Stenberg, High quality chaos(2026-04-22)

여기까지는 성공담으로 읽힌다. 뒷면은 한 달 뒤 포스트에 있다. 들어오는 보안 보고의 속도가 2024년의 4~5배이고 2025년의 두 배이며, 평균적으로 하루에 한 건 이상을 받는다는 것이다. 상반기가 끝나기 전에 CVE 30건을 찍었고, 프로젝트 사상 최대였다. 유인을 없애자 쓰레기는 사라졌는데, 유효율이 올라간 만큼 사람이 끝까지 따라가야 할 진짜 건수가 늘었다. 거르는 데 성공했는데 일이 더 늘어난 것이다.

회복의 원인은 단정할 수 없다. 스텐베리 본인이 원인을 못 박지 않았고, 유인 제거가 효과를 냈다는 설명과 모델 성능이 좋아졌다는 설명이 경합한다. 둘을 가를 자료는 아직 공개돼 있지 않다.

4.3플랫폼 전체에서도 같은 모양이 보인다

한 사람의 기록이라 일반화하기 어렵다면, 플랫폼 전체 통계가 옆에 있다. HackerOne이 2026년 5월 6일에 낸 보고서는 직전 12개월 동안 플랫폼 전체의 평균 수선 시간이 약 80% 줄었다고 적는다. 같은 보고서가 바로 옆에 붙여 둔 것은 한 달에 해결되는 취약점의 총 건수가 약 46% 줄었다는 사실이다. 검증은 됐으나 해결되지 않은 누적 백로그가 21배 넘게 늘었고, 미해결 치명 등급이 25배 늘었으며, 치명 등급 해결률이 83% 이상에서 40% 미만으로 떨어졌다. 보고서 자신의 요약 문장은 더 빨리 해결할 수 있게 됐지만 더 많이 해결하지는 못했다는 것이다.

두 수치의 축이 다르다는 점을 반드시 붙여야 한다. 80%는 건당 걸리는 시간, 곧 속도의 축이고, 46%는 한 달에 몇 건을 닫았는가, 곧 처리량의 축이다. 나란히 놓으면 빨라졌는데 느려졌다는 모순처럼 읽히지만 실제로는 두 축이 갈라진 것이다. curl의 기록과 이 통계도 서로 독립이다. 한쪽은 메인테이너 한 사람의 장부이고 다른 쪽은 플랫폼 전체의 집계다. 같은 방향을 가리킨다는 것이 두 자료가 공유하는 전부다.

같은 회사가 3주 전에 낸 다른 글은 또 다른 틀을 쓴다. 2026년 4월 15일 글은 3월 한 달에 제보가 46,947건으로 역대 최고였고 전년 대비 76% 늘었으며, 방어자들이 1년 전보다 19% 더 많은 취약점을 고쳤다고 적는다. 같은 회사가 발표마다 다른 틀로 같은 문제를 설명하는 것이다. 하나의 숫자로 뭉뚱그릴 수 없다는 뜻이기도 하다.

4.4이 글이 쓰이는 날, 40여 개 프로젝트의 심사가 풀린다

표의 마지막에서 두 번째 줄은 과거 사건이 아니다. OpenJS 재단은 9월 17일부터 Node.js, Electron, ESLint, Fastify, webpack을 포함한 40개가 넘는 프로젝트의 CVE 심사를 전면 중단했고, 그 정지가 풀리는 날이 2026년 10월 6일이다. 이 글을 쓰는 날이다. 구글이 제품 취약점 접수를 닫은 바로 그 주에, 자바스크립트 생태계의 주요 프로젝트들은 3주째 취약점 심사 자체를 멈춘 상태였다.

OpenJS는 그 배경이 되는 수치를 분기 보고에 실었다. 2026년 3월 한 달에 제보 65건, 2월에는 비교 기준이 밝혀지지 않은 4.6배 급증, Express와 Lodash 두 프로젝트의 제보 기각률 70~90%, 그리고 2025년 하반기 3건이던 CVE 발행이 2026년 상반기에 49건이 됐다. 다만 귀속을 섞지 말아야 한다. Node.js의 포상 중단은 자금 때문이었고, CVE 심사 정지는 AI 생성 제보 급증에 따른 자원봉사자 소진 때문이다. 같은 생태계에서 서로 다른 시점에 일어난 다른 사건이다. 메인테이너 소진을 활동 기록으로 읽는 일은 우리가 따로 다룬 적이 있다.

지금까지의 이야기를 AI가 보안 제보를 망쳤다로 요약하면 2026년의 절반만 보는 것이 된다. 같은 해에 반대 방향의 기록도 쌓였다. 가장 무게가 나가는 증언은 도구를 파는 쪽이 아니라 피해를 본 쪽에서 나왔다.

이제 거의 모든 보안 보고가 어느 정도는 AI를 쓴다. 문장이 쓰인 방식을 보면 안다. 다만 예전과 다른 점은, 지금은 대체로 품질이 매우 높다는 것이다. 원문: "Almost every security report now uses AI to various degrees. You can tell by the way they are worded… The difference now compared to before however, is that they are mostly very high quality." — Daniel Stenberg, High quality chaos(2026-04-22)

AI 쓰레기 때문에 포상을 닫은 바로 그 사람이, 석 달 뒤에 적은 문장이다. 보안 도구를 파는 회사가 같은 말을 했다면 마케팅으로 읽혔을 것이다. 피해 당사자가 적었기에 무게가 다르다.

5.1공개 벤치마크에서 성적이 1년 만에 올랐다

학술 벤치마크도 마찬가지다. 실제 오픈소스 취약점을 재현하게 시키는 CyberGym은 2026년 3월에 3판을 내면서, 에이전트가 제로데이 34건과 과거의 불완전한 패치 18건을 새로 찾아냈다고 보고했다. 최고 재현 성공률은 17.9%다. 1년 전 1판에서는 제로데이 15건에 성공률 11.9%였다. 그 변화 자체가 이 절에서 가장 중요한 사실이다. 같은 과제에서 1년 사이에 성적이 올랐다.

페블러스 원본 도식. 출처: CyberGym arXiv:2506.02548(v1 2025년, v3 2026년 3월). 같은 과제에서 제로데이 발견과 재현 성공률이 모두 올랐다.

같은 연구진이 낸 후속 벤치마크는 결함을 찾는 일부터 패치까지를 한 줄로 이어 평가했다. 오픈소스 139곳, 취약점 920건이다. 결론이 흥미롭다. 패치를 만드는 일은 성공률이 높고, 병목은 탐지와 개념 증명 생성 쪽에 있다는 것이다. 고치는 것보다 그것이 진짜임을 입증하는 것이 어렵다는 말이고, 이 글이 다루는 것이 바로 그것이다.

5.2자동 공격 에이전트가 제출한 1,060건의 내역

자율 침투 테스트 회사 XBOW는 2025년 6월 미국 리더보드 1위에 올랐다. 사람이 아닌 제출자로는 처음이다. 자사 블로그가 공개한 누적 제출은 1,060건이고, 그 내역을 그대로 적으면 이렇다. 트리아지로 넘어간 것이 303건, 해결된 것이 130건, 아직 심사 중인 것이 125건, 신규가 33건이다. 그리고 중복 208건, 참고용 209건, 해당 없음 36건이다.

뒤의 세 숫자를 더하면 453건으로, 전체의 약 42.7%다. 이 비율은 공개된 내역에서 이 글이 계산한 값이고 XBOW가 그렇게 요약한 적은 없다. 리더보드 1위를 찍은 자동 에이전트의 제출에서도 열에 넷은 진전으로 이어지지 않았다는 뜻이다. 위양성이 없다는 이 회사의 광고 문구에도 단서를 달아야 한다. 창업자 본인이 비즈니스 로직 결함처럼 자동 검증이 어려운 범주에서는 위양성이 남는다고 밝혔다.

페블러스 원본 도식. 출처: XBOW, We Ran 1,060 Autonomous Attacks(2026-03-02). 453건·42.7%는 본문이 공개 내역에서 직접 계산한 값이고 XBOW가 요약한 수치가 아니다.

구글 쪽 사례도 있다. 프로젝트 제로와 딥마인드가 함께 만든 Big Sleep은 2024년 10월에 SQLite 결함을 릴리스 전에 잡았고, 2025년 7월에는 실제 악용 직전에 차단된 사례를 남겼으며, 같은 해 8월에 오픈소스에서 알려지지 않은 결함 20건을 찾았다. 그리고 바로 그 4월 30일 포스트에서, 구글은 Big Sleep과 코드멘더와 퍼징 인프라를 자기 다층 방어의 자동화 축으로 함께 호명한다. 한쪽 창구에서 AI가 쓴 제보를 더 받지 않기로 하면서, 다른 쪽에서는 AI가 찾는 양을 늘리고 있는 것이다. 우리도 레거시 코드를 AI로 감사한 기록을 남긴 적이 있다.

2026년의 기록에서 가장 눈에 띄는 것은 서로를 인용하지 않은 셋이 같은 요건에 도달했다는 사실이다. 세계에서 가장 큰 포상 프로그램을 운영하는 회사, 혼자 프로젝트를 지키는 메인테이너, 그리고 자율 공격 에이전트를 파는 회사다. 처지가 정반대인 셋이 같은 두 가지를 요구했다.

네 줄 모두 당사자의 공개 문서에 적힌 요건이다. 위의 둘은 같은 회사의 서로 다른 프로그램이고, 구글·curl·XBOW 셋 사이에는 서로를 인용한 자리가 없다.

스텐베리는 요건을 쓰면서 발견 경위를 판정에서 아예 뺐다. 보안팀이 묻는 것은 하나라는 쪽이다.

우연히 걸려 넘어졌든, 소스 코드를 한 줄씩 다 읽어서 찾았든, AI가 짚어 줬든, 보안팀에게 그건 거의 상관이 없다. 팀이 주로 신경 쓰는 것은 그 문제가 진짜인가다. 원문: "…whether you fell over it by accident, you found it by reading every single line of source code or if an AI pointed it out to you, it has little relevance to the security team. The team primarily cares about if the problem is real." — Daniel Stenberg, Do excellent vulnerability reports(2026-06-29)

XBOW가 같은 요구에 도달한 경로는 반대쪽이다. 메인테이너의 책상이 아니라 언어 모델이 할 수 없는 일에서 출발한다.

그럴듯함은 증명이 아니다. 언어 모델은 현실을 직접 관찰할 수 없으므로, 검증은 모델 안에 살 수 없다. … XBOW는 발견과 검증을 완전히 분리한다. 창의적인 AI가 발견하고, 결정론적 논리가 무엇이 진짜인지를 결정한다. 원문: "plausibility is not proof. … Because LLMs can't observe reality directly, validation can't live inside the model."(2026-01-15) / "XBOW separates discovery from validation entirely. … Creative AI discovers. Deterministic logic decides what's real."(2026-03-02) — XBOW 자사 블로그

6.1입력에 무엇이 딸려 오느냐가 난이도를 바꾼다

증거를 요구하면 실제로 판정이 쉬워지는가. 학술 쪽에 방향을 보여 주는 결과가 셋 있다. 세 결과는 코드베이스도 과제 정의도 모델도 시점도 달라 직접 비교할 수 없다. 비교가 아니라 방향으로만 읽어야 한다.

• 입력이 커널 보안 패치일 때, 개념 증명 재현 성공률이 100건 중 56건이었고 성공 한 건당 2.49달러와 11.9분이 들었다.
• 입력에 취약점 유형 분류와 코드 위치만 덧붙여도, 악용 입증 성공률이 아무 정보 없는 경우의 3배가 됐다. 단일 에이전트만 써도 1.75배다.
• 입력이 취약점 설명 텍스트뿐일 때, 재현 성공률의 최고값이 17.9%였다.

방향만 놓고 보면 이렇다. 산문 설명만 주면 어렵고, 코드 위치를 주면 쉬워지고, 패치를 주면 절반 넘게 재현된다. 구글이 3월에 요구한 것이 정확히 이 순서의 반대편이다. 가장 값싼 입력인 산문 주장을 막고, 가장 판정하기 쉬운 입력인 패치와 재현 절차를 요구했다.

6.2규격은 2024년부터 있었다

증거를 붙여 보내라는 요구는 소프트웨어 공급망 쪽에서 이미 규격이 돼 있다. in-toto 증명 규격 위에 선 SLSA 출처 증명은 빌더 신원, 빌드 명령, 파라미터, 환경 변수, 의존성 다이제스트를 서명해 묶고, in-toto가 단계별 정책 검증을 더한다. 믿어 달라고 말하는 대신, 서명된 증거를 함께 보내고 받는 쪽이 정책으로 돌려 본다. 구글이 공급망 제보에 요구한 실증과 설계 원리가 같다.

있다고 해서 쉽게 깔리는 것은 아니다. 깃허브 저장소 233곳의 SLSA 관련 이슈 1,523건을 분석한 연구는 도출한 과제 넷의 핵심이 구현의 복잡성과 불명확한 소통이라고 적는다. 데이터 쪽에는 아직 단일 규격이 없고 두 갈래로 나뉜다. 계약으로 품질을 강제하는 쪽과 암호학적 증명으로 출처를 붙이는 쪽이다. 표준 쪽에서는 오픈 데이터 컨트랙트 스탠더드 3.1.0판이 2025년 12월 8일에 승인돼 리눅스 재단 산하 프로젝트로 들어갔다.

6.3유보: 테스트 통과는 안전의 증거가 아니다

증거를 요구하는 설계에도 바닥이 있다. 구글 연구자가 공저한 2025년 10월 논문은 기능적으로는 올바른데 취약한 패치라는 범주를 정의하고, 표준 벤치마크에서 에이전트와 모델을 조합한 12가지 경우 전부가 그런 패치를 만들어 냈다고 보고한다. 한 조합에서는 특정 결함 유형의 공격 성공률이 40.7%였고, 블랙박스 환경에서 한 번 질의하는 것으로 충분했으며, 악의가 없는 개발자가 외부 코드를 복사해 넣어도 같은 일이 생긴다고 적는다. 다른 연구는 기능적으로 올바른 패치에 대한 공격 성공률이 최대 0.91까지 올라갔다고 보고했다. 3.1절에서 본 적대적 제보 연구에서도 악성 패치 51건 중 35건이 테스트 스위트에 새 실패를 하나도 내지 않았다.

단서가 하나 필요하다. 이 논문들이 다루는 것은 코드 에이전트가 생성한 패치다. 구글이 요구한 것은 이미 머지된 패치라 사람 리뷰가 한 겹 더 있다. 그 차이를 지우고 구글이 요구한 패치도 못 믿는다고 쓰면 과장이다. 그럼에도 남는 것은 있다. 기계가 돌려 볼 수 있는 증거는 사람이 읽어야 하는 주장보다 싸게 판정되지만, 그 판정이 안전을 보증하지는 않는다. 증거는 판정의 비용을 낮추는 장치이지 정답을 주는 장치가 아니다.

같은 구조를 우리는 다른 자리에서도 봤다. 학술 동료 심사에 AI 생성물이 섞여 든 사건이 그렇고, 사람 검수 용량을 넘어선 관측 경보가 그렇다. 발견과 복구의 속도 차를 다룬 마이크로소프트 보고서 분석도 같은 축 위에 있다.

1절부터 6절까지는 당사자 공지와 규칙 원문, 그리고 논문 본문에서 확인한 것이다. 이 절은 그 문서들이 하지 않은 이야기이고, 페블러스가 왜 이 사건을 오래 들여다봤는지에 관한 것이다.

7.1이건 보안 사건이기 전에 입구 설계 사건이다

페블러스의 일은 데이터가 학습에 들어가기 전에 그 상태를 묻는 것이다. 데이터클리닉은 들어온 데이터셋을 진단하고, AI-Ready Data는 학습 전 정리를 다룬다. 구글이 올해 바꿔 건 장치들은 성격상 같은 문제다. 유입이 공짜로 늘어날 때 입구에서 무엇을 요구할 것인가. 구글이 내린 답은 누가 보냈는지 가리자가 아니었다. 기계가 돌려 볼 수 있는 증거를 함께 보내라였다. 퍼징 재현 절차, 머지된 패치, PR 승인 요건을 우회한 실증, 크롬 쪽의 재현기까지 전부 사람이 읽고 판단할 필요 없이 실행해 보면 되는 산출물이다.

그리고 구글은 요구만 한 것이 아니라 증거를 만들 도구까지 배포하기로 했다. 데이터 수집 쪽에 그대로 옮길 수 있는 설계다. 제출자에게 증거를 붙이라고만 말하지 말고, 붙일 수 있는 규격과 그 규격을 실행해 볼 도구를 같이 주는 쪽이다.

7.2스키마는 통과하고 의미가 비어 있는 입력

데이터 품질 논의는 보통 결측과 중복과 범위를 다룬다. 이 사건이 드러내는 결함은 종류가 다르다. 구글이 비용의 본체로 지목한 것은 거짓 제보가 아니라 기술적으로는 맞지만 도달할 수 없는 코드 경로를 가리키는 제보였다. 스키마로 치면 전부 통과하고 타입도 맞고 값의 범위도 정상인데, 의미가 비어 있는 레코드다.

학술 문헌이 같은 자리를 두 번 확인한다. 정적 분석기가 적대적 제보 51건 중 한 건도 잡지 못했고, 스캐너 위양성의 주된 원인은 도달할 수 없는 코드였다. 품질 지표를 설계할 때 이 항목을 기각하는 데 사람이 필요한가라는 물음이 결측률만큼 중요해지는 자리가 여기다. 우리가 에이전트가 쓴 지식그래프를 입구에서 판정한 기록을 남긴 것도 같은 물음에서였다.

페블러스 원본 도식. 타입·범위 검사는 자동으로 통과해도 도달 가능성 판정에는 사람이 필요하다는 7.2절의 비유를 흐름도로 옮겼다.

7.3입구 장치가 성공해도 검증 용량은 따로 남는다

들어오는 데이터가 많아진다는 말은 좋은 소식처럼 들린다. 2026년의 기록은 거기에 조건을 붙인다. curl은 보상을 없애 쓰레기를 없앴고 유효율을 15~16%로 되돌렸는데, 같은 해에 제보량이 2024년의 4~5배가 되면서 상반기가 끝나기 전에 CVE 30건을 찍었다. HackerOne은 플랫폼 전체에서 건당 처리 시간을 80% 줄이고도 월간 해결 건수가 46% 줄었다고 적었다.

수집량을 성과 지표로 쓰는 조직에 그대로 보여 줄 수 있는 현장 기록이다. 설계할 때 물어야 할 것은 얼마나 많이 받을 수 있는가가 아니라, 각 항목이 자기를 검사할 증거를 데리고 오는가다. 데이터 계약, 출처 증명, 자동 검증 가능한 샘플은 이름이 달라도 같은 요구다. 쓰레기 데이터가 모델을 어떻게 갉아먹는지를 다룬 글과 기여 자체를 거절한 프로젝트 이야기도 이 물음의 다른 답이었다.

7.4가려내기에서 요구하기로

지금까지 AI 생성물 논의는 주로 가려낼 것이냐에 머물렀다. 탐지, 워터마크, 출처 표시다. 2026년의 답은 다른 쪽으로 수렴했다. 구글과 curl 메인테이너와 XBOW가 서로를 인용하지 않은 채 같은 두 가지를 요구했고, 스텐베리는 AI가 짚어 줬든 상관없고 진짜인지만 본다고 명시적으로 적었다. 학술 서베이도 다르지 않다. 소극적 탐지와 워터마크는 정확성이 아니라 출처를 겨냥한다고 지적하면서, 대신 능동적인 기호·신경 결합 검증을 제안하고, 평가를 언어적 유창성에서 수학적 검증 가능성으로 옮기자고 적는다.

저자를 판별하는 일은 모델이 바뀔 때마다 다시 해야 하지만, 증거를 요구하는 설계는 누가 만들었든 똑같이 작동한다. 규격이 없어서 못 하는 것도 아니다. 공급망 쪽 증명 규격은 2024년부터 있었고, 데이터 쪽에도 기계가 읽는 계약 규격이 2025년 말에 표준이 됐다. 페블러스가 할 수 있는 일은 이 전환을 데이터 수집과 검수 쪽에서 먼저 한국어로 언어화하고, 입력마다 기계 검사 가능한 증거를 붙인다는 요건을 품질 규격 수준으로 제안하는 것이다. 이 글이 그 한 걸음이다.

출처의 등급이 갈리므로 묶어서 적는다. 첫 묶음은 당사자가 직접 낸 공지와 공식 블로그이고, 본문의 축자 인용은 전부 여기서 대조했다. 둘째 묶음은 학술 논문이며 판본 번호까지 적었다. 개정판에서 값이 바뀐 논문이 둘 있어, 본문은 최신 판본의 값만 썼다. 셋째 묶음은 규격 문서이고, 넷째 묶음은 보도를 거친 자료로 본문에서 쓸 때마다 귀속을 문장 안에 밝혔다.

당사자 공지·공식 블로그 (1차)

• 1.Google Bug Hunters. Google OSS VRP Rules. 2026년 10월 6일 수신 전문. bughunters.google.com — 1절의 접수 중단 문단, 보상표 세 줄, 공급망 제보의 실증 요건, OSS-Fuzz 통합 근거 문장이 여기서 나왔다.
• 2.Google Bug Hunters. Streamlining Google's OSS VRP: Key Rule Updates. 2026년 3월 19일, 4월 갱신 블록 포함 — 2.1·2.2절의 증명 요구와 유인 제거, 3절의 환각·도달 불가 두 범주와 밀과 쭉정이 문장이 여기서 나왔다. 갱신 블록에는 날짜가 없다.
• 3.Google Bug Hunters. Evolving the Android & Chrome VRPs for the AI Era. 2026년 4월 30일, Shailesh Saini·Tony Mendez — 2.3절 전체. ⚠️ 2차 다수가 5월 1일로 적지만 구글 게시일은 4월 30일이다.
• 4.Google Bug Hunters. Google VRPs in Review – 2025. 2026년 3월 11일 — OSS VRP의 2025년 처리 192건, 보상 62건, 32만 7,672달러.
• 5.@GoogleVRP. OSS VRP 제품 취약점 접수 중단 공지. X, 2026년 10월 1일 16:00 UTC — 사유 문장이 적힌 유일한 구글 매체다.
• 6.Daniel Stenberg. The end of the curl bug-bounty(2026-01-26) · curl security moves again(2026-02-25) · High quality chaos(2026-04-22) · The pressure(2026-05-26) · Do excellent vulnerability reports(2026-06-29) — 4.2절의 전후 수치, 5절 머리의 증언, 6절의 요건이 여기서 나왔다.
• 7.HackerOne. Internet Bug Bounty 접수 중단 공지(2026-03-27) · Finding Fast, Fixing Slow: The Rising Exposure Debt(2026-05-06) · Continuous Threat Exposure Management and the Remediation Crisis(2026-04-15, Alex Rice) · h1 Validation 보도자료(2026-04-21) — 4.3절의 세 가지 틀이 여기서 나왔다. ⚠️ 2차 일부가 쓴 백로그 29배는 원문에 없는 수치다. 원문 값은 21배와 25배다.
• 8.Node.js. Security Bug Bounty Program Paused Due to Loss of Funding(2026-04-02) · OpenJS Foundation. Security Update: Q2 2026(2026-07-08) — 4.1·4.4절. 전자의 공지에는 AI라는 말이 한 번도 나오지 않는다.
• 9.GitHub. The next chapter: restructuring GitHub's bug bounty program. 2026년 7월 22일, Catherine Cassell — 신규 연구자 초기 제출 4건 한도, 노이즈를 줄여 신호에 집중하겠다는 목적, 동기로 명시한 저노력·AI 생성 보고.
• 10.XBOW. The Road to Top 1: How XBOW Did It(2025-06-24) · Why LLMs Hallucinate Vulnerabilities(2026-01-15) · We Ran 1,060 Autonomous Attacks(2026-03-02) — 5.2절의 제출 내역과 6절의 설계 원칙.
• 11.Google Project Zero. Big Sleep 관련 포스트(2024-10, 2025-07, 2025-08) — 5.2절. 2026년 연간 집계는 공개돼 있지 않다.

학술 논문 (판본 명시)

• 12.Przymus, Happe, Cito. Adversarial Bug Reports as a Security Risk in Language Model-Based Automated Program Repair. arXiv:2509.05372 v2, MSR 2026. arxiv.org — 3.1절의 비용 세 값은 본문 6.6절에 있다. 초록에는 없다. 공격 성공 46/51, 필터 24/51, 사후 리뷰 30/51, CodeQL 0/51, 테스트 무실패 35/51도 여기서 나왔다.
• 13.Zhou, Dacier, Konstantinou. A Reality Check on SBOM-based Vulnerability Management. arXiv:2511.20313 v2(2026-04-17) — 3.2절의 저장소 2,414곳, 위양성 92.0%, 호출 분석으로 걷어낸 61.9%. ⚠️ v1의 값은 97.5%와 63.3%이고 2차 요약 다수가 아직 v1을 돈다.
• 14.Zheng 외. From Reviewers' Lens: Understanding Bug Bounty Report Invalid Reasons with LLMs. arXiv:2511.18608 — 3.2절의 기각 사유 분류와 평판 효과. 범주별 건수가 없어 비율은 끌어내지 않았다.
• 15.Wang, Shi, He, Cai, Zhang, Song. CyberGym. arXiv:2506.02548 v3(2026-03-24) · CyberGym-E2E. arXiv:2606.04460 — 5.1절. v1의 값은 제로데이 15건에 11.9%다.
• 16.Pu 외. Patch-to-PoC (K-Repro). arXiv:2602.07287 v2 · Sajadi 외. AXE: Grey-Box Exploitability Confirmation for Localized Vulnerability Reports. arXiv:2602.14345 v2 — 6.1절의 56/100과 3배. 척도가 달라 직접 비교하지 않았다.
• 17.Peng 외(공저 Mihai Christodorescu, Google). When "Correct" Is Not Safe. arXiv:2510.17862 · Chen, He, Jana, Ray. Red Teaming Program Repair Agents (SWExploit). arXiv:2509.25894 — 6.3절. 대상은 코드 에이전트가 생성한 패치다.
• 18.Ding 외. AI Slop and Hallucinations in Vulnerability Assessment: A Survey. arXiv:2608.25667(2026-08-26) — 7.4절의 탐지 대 검증 프레이밍. 이 서베이에는 수치가 없다.
• 19.Tamanna 외. Analyzing Challenges in Deployment of the SLSA Framework. arXiv:2409.05014 — 6.2절의 저장소 233곳, 이슈 1,523건. Ni 외. Learning to Triage Vulnerability Reports from Program Analysis. arXiv:2510.20739, ASE 2026 · Pesoli, Errico, Cavallaro. arXiv:2605.24632 — 배경으로만 참조했고, 후자의 검증 시간·시급 값은 저자의 가정값이라 쓰지 않았다.

규격·표준

• 20.in-toto attestation 규격 · SLSA provenance 규격 — 6.2절·7.4절.
• 21.Open Data Contract Standard v3.1.0. Linux Foundation AI & Data, Bitol 프로젝트. 2025년 12월 8일 승인 — 6.2절·7.4절의 데이터 쪽 계약 규격.

보도 (귀속 명시해 사용)

• 22.TechCrunch(Anthony Ha, 2026-10-04) · Help Net Security(2026-10-05) · SecurityWeek(Eduard Kovacs, 2026-10-05) · BleepingComputer(Sergiu Gatlan, 2026-10-05) · ITPro(Ross Kelly, 2026-10-05) — 1.2절의 귀속 비교에 썼다. ⚠️ Tom's Hardware(2026-10-04)가 전한 수천 건은 출처가 밝혀지지 않아 본문 수치로 쓰지 않았다.
• 23.Dark Reading(Rob Wright, 2025-08-13). How an AI-Based 'Pen Tester' Became a Top Bug Hunter on HackerOne — XBOW 창업자의 블랙햇 2025 발언 출처다. 발화는 1차 사건이지만 문서로는 현장 취재를 거친 2차다. Phoronix(Michael Larabel, 2026-09-18) — 인텔. Axios(2026-03-10) — OpenSSF 측 발언.

페블러스 블로그 인접 글

• 24.AI가 쓴 심사평이 학회를 흔든 사건(6.3절) · 에이전트 콘텐츠 파이프라인의 검증 설계(3.2절) · 에이전트가 쓴 지식그래프를 입구에서 판정하기(7.2절) · 사람 검수 용량을 넘어선 관측 경보(6.3절) · 레거시 코드 AI 감사 기록(5.2절) · 공격은 하루, 복구는 한 달(6.3절) · 메인테이너 소진 신호(4.4절) · 쓰레기 데이터와 모델 열화(7.3절) · AI 코드 기여를 거절한 프로젝트(7.3절)