AI의 경이로움: 버그 바운티 (Bug Bounty) 프로그램을 종료합니다

거의 1년 동안, Turso는 데이터 손상 (Data Corruption)을 유발할 수 있음을 증명할 수 있는 모든 버그에 대해 1,000달러를 지급하는 프로그램을 운영해 왔습니다. 오늘, 저희는 이 프로그램을 종료합니다.

거의 1년 동안, Turso는 데이터 손상 (Data Corruption)을 유발할 수 있음을 증명할 수 있는 모든 버그에 대해 1,000달러를 지급하는 프로그램을 운영해 왔습니다. 오늘, 저희는 엄청난 슬픔과 함께 이 프로그램을 종료합니다.

이유는 간단합니다. 모든 이들이 슬롭 머신 (Slop Machine)에 의해 침수되고 있기 때문입니다. 이 점에 있어서 저희가 유일한 것은 아닙니다. 하지만 특정 클래스의 버그를 대가로 돈을 제공하는 프로그램은 슬롭 제작자 (Slop Makers)들에게 너무나 매력적인 표적이 됩니다. 며칠 동안 저희의 메인테이너 (Maintainers)들은 Turso에서 데이터 손상을 유발하는 버그를 발견했다고 주장하는 슬롭 PR (Slop PRs)을 닫는 일 외에는 거의 아무것도 하지 못했습니다. 많은 오픈 소스 (OSS) 프로젝트들이 기여 (Contribution)에 대한 문을 닫고 있는 시기에, 저희는 Turso의 문을 열어두기 위해 가능한 모든 노력을 다하고 싶습니다. 오픈 기여 (Open Contribution) 프로젝트가 되는 것은 저희 DNA의 일부입니다. 그것이 Turso가 탄생한 방식입니다. 하지만 불행하게도, 금전적 보상이 이를 거의 불가능하게 만들고 있으며, 이제는 종료해야만 합니다.

저희가 이 사실을 공개적이고 강력하게 공유하는 이유는, 우리 모두가 이 새로운 시대에 좋은 거버넌스 (Governance)를 구축하기 위한 새로운 방법을 찾아야 하며, 서로에게서 배워야 한다고 믿기 때문입니다. 이것이 그 대화에 대한 저희의 기여입니다.

저희가 이 프로그램을 시작한 이유는 세계에서 가장 신뢰할 수 있는 소프트웨어 중 하나로 알려진 SQLite를 재작성하고 있기 때문입니다. 커뮤니티는 이토록 야심 찬 프로젝트에 대해 높은 기준을 기대하며, 저희는 SQLite의 전설적인 신뢰성에 부합하거나 심지어 능가할 수 있도록 엄청난 노력을 투자하고 있습니다. Turso는 네이티브 결정론적 시뮬레이터 (Deterministic Simulator), 퍼저 (Fuzzers) 모음, SQLite를 대상으로 하는 오라클 기반 차등 테스트 엔진 (Oracle-based Differential Testing Engine), 동시성 시뮬레이터 (Concurrency Simulator)를 탑재하여 제공하며, 그 외에도 Antithesis 상에서 광범위한 실행을 수행하고 있습니다.

우리는 테스트 규율 (testing discipline)을 진지하게 받아들입니다. 그리고 우리의 자신감을 전달하고 싶었습니다. 반면에, 그 모든 테스트 인프라 (testing infrastructure)는 결국 소프트웨어일 뿐이며 완벽하지 않습니다. 세상의 모든 퍼저 (fuzzer)와 시뮬레이터 (simulator)를 작성할 수는 있겠지만, 그것들은 효과적으로 생성된 조합 내에서만 버그를 찾아낼 수 있습니다. 예를 들어, 퍼저 (fuzzer)가 인덱스 (index)를 전혀 생성하지 않는다면, 시스템의 나머지 부분을 아무리 잘 스트레스 테스트 (stress test) 하더라도 정의상 인덱스와 관련된 버그는 찾을 수 없습니다. 실제 사례로서, 우리는 시뮬레이터 (simulator)를 빠져나간 버그들을 발견했는데, 이는 해당 버그들이 1GB보다 큰 데이터베이스에서만 나타났기 때문입니다. 그리고 우리가 모든 실행 (every run) 시에 공격적으로 결함 주입 (fault injection)을 수행했기 때문에, 데이터베이스가 해당 버그를 유발할 만큼 충분히 커질 기회가 없었습니다.

자동화된 테스트 (automated testing)의 주요 장점은, 버그가 검증 (validation) 과정을 빠져나갔을 때 테스트 생성기 (test generator)를 개선하면 버그의 한 계층 (entire class of bugs) 전체가 사라진다는 것입니다. 그래서 우리는 이 프로그램을 두 가지 목적을 모두 달성하기 위한 훌륭한 방법으로 구상했습니다. 즉, 우리의 *방법론 (methodology)*에 대한 신뢰를 구축하는 데 도움을 주는 동시에, 만약 누군가가 우리의 시뮬레이터 (simulator)가 잘 다루지 못한 영역을 찾아낸다면 기꺼이 보상하고 싶었습니다! 우리는 Turso의 1.0 버전을 출시할 때까지 데이터 손상 (data corruption)을 유발하는 버그에 대해 1,000달러의 보상금을 지급하며 프로그램을 시작했습니다. 우리의 계획은 1.0 버전에 도달하면 보상금의 규모를 상당한 수준으로 점진적으로 늘리고, 보상을 제공할 이슈 (issue)의 범위 또한 확대하는 것이었습니다.

우리는 이 프로그램에 매우 만족했습니다. 총 5명의 개인에게 보상을 지급했습니다. 상을 받은 모든 사람들은 정말 특별한 사람들이었습니다. 특히 Alperen의 작업은 강조할 만합니다. 그는 사실 우리 시뮬레이터 자체의 핵심 기여자 중 한 명이었습니다 (그가 개선될 수 있는 몇 군데를 알고 있다는 것은 놀라운 일이 아니었죠). 다음으로, Mikael은 LLM을 매우 창의적인 방식으로 사용하여 시뮬레이터가 도달하지 못한 부분을 파악했고 (우리는 나중에 Mikael을 고용했습니다), Pavan Nambi는 시뮬레이터를 형식적 방법(formal methods)과 결합하여 Turso에서 버그를 발견했을 뿐만 아니라, 이 방법론을 통해 SQLite 자체에서 10개가 넘는 버그를 실제로 찾아냈습니다.

저희 경험상, 치명적인 문제를 찾을 만큼 숙련된 사람은 저희 커뮤니티에 머물기를 바라는 사람이었습니다. 보상을 받기 위해 나쁜 PR(Pull Request)을 제출하려는 가끔 있는 사람들도 있었지만, 이는 드문 경우였습니다. 시뮬레이터를 확장하여 버그를 입증해야 한다는 요구 사항(단순히 버그를 지적하는 것만으로는 충분하지 않음)이 기준을 높게 유지하는 데 도움이 되었고, 가장 중요하게도, 그런 버그 자체가 많지 않았습니다.

하지만 어느 날 밤 갑자기 쓰레기 같은 자료들이 쏟아져 나왔습니다. Turso에 LLM을 단순히 겨냥하고 버그를 찾으려고 하는 것만으로는 보상이 너무 커졌습니다. 그리고 여러분도 아시다시피, LLM에게 버그를 찾아 보상을 받으라고 지시하면 어떤 출력물을 생성할 것입니다. 그것이 말이 되든 안 되든은 완전히 다른 이야기입니다. 그중 일부를 공유하고 싶습니다.

이 PR에서는 작성자가 데이터베이스 헤더에 쓰레기 바이트(garbage bytes)를 수동으로 주입한 다음, 이것이 데이터베이스를 손상시켰다고 주장했습니다 (당연하죠!). 저희 유지 관리자(maintainer)가 '음, 뭐 대단한 것도 아니네'라고 지적하자, 작성자(또는 그의 봇)는 평소의 LLM이 유도하는 장문의 텍스트로 계속 논쟁을 벌였습니다.

믿기 어려울 수도 있지만, 이것은 실제로 데이터베이스를 손상시키하기 위해 소스 코드를 수정하여 경계 초과 배열 접근(out-of-bound array access)을 수동으로 추가하는 것보다 덜 놀라운 일입니다.

표와 녹색 체크 표시, 그리고 엠 대시(em dashes)로 가득 찬 이 다른 PR에서, 저자는 임의의 SQL 문(SQL statements) 실행을 허용하는 심각한 취약점(critical vulnerability)을 발견했다고 주장합니다. 상상이 가시나요? SQL 문 실행을 허용하는 SQL 데이터베이스라니요. 우리가 어떻게 이 상황에서 회복할 수 있을까요.

이 또 다른 걸작은 SQLite와 차별화되는 기능 중 하나인 Turso에서 동시 쓰기(concurrent writes)를 가능하게 하며, 그 후 저널 모드(journal mode)를 다시 WAL로 설정하기 전까지는 SQLite가 파일을 열 수 없음을 보여줍니다. 즉, 동시 쓰기를 비활성화하는 것인데(이것이 시스템이 작동하도록 설계된 방식입니다).

이 다른 건에 대해서는 멋진 설명을 쓰고 싶지만, 그들이 무엇을 하려는 것인지 전혀 모르겠습니다. 우리의 유지 관리자(maintainer)인 Mikael(과거에 상을 받았던 바로 그분입니다!)이 지적했듯이, 이 사람은 그저 상금 발표를 보고 침을 흘리기 시작하여 슬롭 머신(slop machine)을 우리에게 겨눈 것이 매우 분명합니다.

질서를 세우기 위한 우리의 마지막 시도로, 우리는 보증(vouching) 시스템을 설계하고 구현했습니다. 만약 제출물이 봇(bot)으로부터 온 것이라고 의심되면, 우리는 그냥 자동으로 종료(auto-close)합니다. 그리고 이것은 한동안 괜찮게 작동했습니다. 봇들이 자신들의 PR이 종료된 것에 대해 의문을 제기하고 수동 검토를 요청하는 이슈(issues)를 열기 시작하기 전까지는 말이죠. 그것들은 모두 똑같이 생겼습니다:

우리는 또한 PR을 종료할 수 있었던 많은 사례에서, 잠시 후 다른 사용자에 의해 동일하거나 매우 유사한 PR이 다시 열리는 것을 목격했습니다.

물론 주요 문제는 슬롭 제작자(slopmaker)가 제출물을 생성하는 데 아마 1분 정도밖에 걸리지 않는다는 점입니다. 하지만 우리가 그것을 읽고, 이해하고, 대응하는 데는 몇 시간이 걸립니다. 그리고 그것들은 거의 무한한 속도로 생성될 수 있습니다. 이를 차단하기 위해 자동화된 시스템을 구축하는 것도 가능하지만, 무시할 수 없는 달러 가치가 결부되어 있기 때문에, AI들이 계속해서 논쟁하고, 동일한 PR을 다시 여는 등의 행위를 지속하게 만드는 유인(incentive)이 너무나 큽니다.

우리는 기여자들로 구성된 오픈 소스 (Open Source) 커뮤니티를 매우 소중하게 생각하며, 앞으로도 커뮤니티를 계속해서 강화해 나갈 것입니다. 하지만 현 시점에서, 우리는 그 어떤 종류의 금전적 유인 (financial incentive)도 오픈 시스템 (open system)과 잘 맞지 않는다고 판단합니다. 우리는 시스템을 폐쇄하거나, 아니면 유인을 제거해야만 합니다. 현재로서는 우리는 후자를 선택하고자 합니다.