학부 연구생 D씨는 오픈소스 프로젝트의 버그 바운티 공고를 보고 LLM(거대언어모델)에 코드 분석을 요청했다. 깃허브(GitHub, 소프트웨어 버전 관리 플랫폼)의 풀 리퀘스트(PR, 코드 변경 제안) 목록이 의미 없는 텍스트와 잘못된 버그 제보로 가득 차는 현상이 빈번해졌다. 보상금을 노린 자동화 도구가 생성한 저질 콘텐츠가 개발자의 검토 시간을 잠식하고 있다. 이런 곤란을 겪는 개발자가 늘고 있다.

데이터 오염 방지를 위한 1,000달러의 보상 체계

Turso(SQLite를 재작성하는 데이터베이스 프로젝트)는 데이터 오염을 유발하는 버그를 발견해 증명할 경우 1,000달러를 지급하는 프로그램을 운영해 왔다. 이 프로그램은 Turso 1.0 버전 출시 전까지 시스템의 신뢰성을 확보하기 위해 도입되었다.

검증을 위해 Deterministic Simulator(결정론적 시뮬레이터), 퍼저(Fuzzer, 무작위 데이터를 입력해 오류를 찾는 도구), SQLite 대비 오라클 기반 차분 테스트 엔진, 동시성 시뮬레이터, Antithesis(복잡한 시스템의 버그를 찾는 테스트 플랫폼) 등을 활용했다. 다만 모든 테스트 인프라는 소프트웨어이기에 완벽할 수 없으며, 특히 1GB 이상의 대규모 데이터베이스에서만 발생하는 버그처럼 시뮬레이터가 생성하지 못하는 조합의 오류가 존재한다는 점을 인정했다.

실제 보상금은 총 5명에게 지급되었다. 시뮬레이터 핵심 기여자 Alperen, LLM을 창의적으로 활용해 시뮬레이터 미도달 영역을 찾은 Mikael, 정형 기법(Formal Methods, 수학적 논리로 소프트웨어 정확성을 검증하는 방법)을 통해 SQLite에서 10개 이상의 버그를 찾아낸 Pavan Nambi가 포함된다.

기술적 증명에서 AI 슬롭으로의 변질

이전의 버그 제보는 시뮬레이터를 직접 확장해 오류를 증명해야 했기에 진입 장벽이 높았다. 단순한 버그 지적이 아니라 기술적 증명이 필수적이었으므로 고숙련 개발자 중심의 기여가 이루어졌다.

반면 최근에는 LLM을 이용해 무작위로 코드를 찌르는 슬롭(Slop, AI가 생성한 저질 콘텐츠) 방식의 공격이 급증했다. 데이터베이스 헤더에 임의로 쓰레기 바이트를 주입한 뒤 데이터가 오염되었다고 주장하거나, SQL 데이터베이스에서 SQL 문이 실행되는 것을 취약점이라고 주장하는 수준의 PR이 쏟아졌다.

주목할 점은 이러한 저질 PR들이 LLM 특유의 장황한 설명(Wall-of-text)을 동반하며 유지보수자의 시간을 낭비시킨다는 점이다. SQLite의 설계상 특징인 동시 쓰기 기능을 구현한 뒤, 저널 모드를 WAL(Write-Ahead Logging, 변경 사항을 로그에 먼저 기록하는 방식)로 설정하지 않으면 SQLite가 파일을 열 수 없다는 당연한 사실을 버그로 제보하는 사례도 발생했다. 결국 유지보수 인력이 버그 수정이 아닌 저질 PR을 닫는 작업에 대부분의 시간을 소비하게 되었다.

현금 보상이라는 고전적 동기 부여 방식이 AI 시대의 자동화된 공격 앞에서는 오히려 프로젝트의 생산성을 파괴하는 독이 되었다.