버그 바운티 프로그램을 종료합니다

• Turso는 데이터 손상 입증 버그에 1,000달러를 지급하던 버그 바운티를 약 1년 운영한 뒤 종료함
• 보상이 걸리자 AI 생성 저품질 PR이 대량 유입돼 유지보수자들이 며칠 동안 이를 닫는 데 시간을 씀
• 초기에는 5명에게 보상했고, 일부 기여는 시뮬레이터 개선과 SQLite의 10개 넘는 버그 발견으로 이어짐
• Turso는 보증 시스템으로 의심 PR을 자동 종료했지만, 봇들이 수동 검토 이슈와 유사 PR 재제출을 반복함
• Turso는 오픈 기여를 유지하기 위해 시스템을 닫기보다 금전 인센티브 제거를 선택함

Turso가 버그 바운티를 중단한 이유

• Turso는 거의 1년 동안 데이터 손상으로 이어질 수 있음을 입증한 버그에 1,000달러를 지급했지만, 이제 프로그램을 종료함
• 금전 보상이 붙은 뒤 Turso 저장소에는 AI 생성 저품질 PR이 몰렸고, 유지보수자들이 며칠 동안 대부분의 시간을 이런 PR을 닫는 데 써야 했음
• Turso는 오픈 기여 프로젝트로 남고 싶지만, 특정 버그 유형에 돈을 지급하는 구조가 오픈 기여 운영을 거의 불가능하게 만든다고 봄
• 이번 결정은 새로운 시대의 오픈소스 거버넌스를 어떻게 세울지 함께 배워야 한다는 인식 속에서 공개됨

프로그램을 시작한 배경

• Turso는 세계에서 가장 신뢰성 높은 소프트웨어 중 하나로 알려진 SQLite를 다시 구현하고 있으며, 그만큼 높은 신뢰성 기준이 필요함
• Turso는 SQLite 수준의 신뢰성을 맞추거나 넘어서기 위해 여러 테스트 체계를 운영함
  • 네이티브 결정적 시뮬레이터
  • 여러 퍼저(fuzzer)
  • SQLite와 비교하는 오라클 기반 차등 테스트 엔진
  • 동시성 시뮬레이터
  • Antithesis에서의 광범위한 실행
• 테스트 인프라도 결국 소프트웨어라 완벽하지 않으며, 생성기가 실제로 만들어내는 조합 안에서만 버그를 잡을 수 있음
• 예를 들어 퍼저가 인덱스를 만들지 않으면, 시스템의 다른 부분을 강하게 스트레스 테스트해도 인덱스 관련 버그는 찾기 어려움
• Turso는 데이터베이스가 1GB보다 클 때만 나타나는 버그를 찾았는데, 매 실행마다 장애를 공격적으로 주입한 탓에 데이터베이스가 그 크기까지 커지지 못해 시뮬레이터를 빠져나갔음
  • 관련 내용: 호환 시스템 작성의 모험
• 자동화 테스트의 장점은 한 번 빠져나간 버그라도 테스트 생성기를 개선하면 버그의 한 범주 전체를 제거할 수 있다는 데 있음
• 버그 바운티는 Turso의 테스트 방법론에 대한 자신감을 보여주면서도, 시뮬레이터가 잘 다루지 못한 영역을 누군가 찾아내면 보상하기 위한 장치였음
• 초기 계획은 Turso 1.0 출시 전까지 데이터 손상 버그에 1,000달러를 지급하고, 1.0 이후에는 보상 규모와 대상 범위를 점진적으로 늘리는 것이었음

AI 저품질 제출이 늘기 전의 효과

• 프로그램 초기에는 총 5명이 보상을 받았고, 이들은 프로젝트에 의미 있게 기여함
• Alperen은 Turso 시뮬레이터의 핵심 기여자 중 한 명이었고, 개선 가능한 지점을 알고 있었음
• Mikael은 LLM을 창의적으로 사용해 시뮬레이터가 도달하지 못하는 지점을 찾아냈고, 이후 Turso에 채용됨
• Pavan Nambi는 시뮬레이터와 형식 기법을 결합해 Turso 버그뿐 아니라 SQLite 자체에서도 10개가 넘는 버그를 찾아냄

AI 생성 제출이 만든 운영 부담

• Turso가 원한 제출 기준은 단순한 버그 지적이 아니라, 시뮬레이터를 확장해 데이터 손상 버그를 입증하는 것이었음
• 이 조건 덕분에 보상을 노린 나쁜 PR은 드물었고, 실제 데이터 손상 버그도 많지 않았음
• 이후 LLM에 Turso를 대상으로 버그를 찾고 보상을 받으라고 지시한 제출이 대량으로 발생함
• LLM은 그런 지시를 받으면 어떤 출력이든 만들어냈지만, 그 출력이 타당한지는 별개의 문제였음

대표적인 저품질 제출

• 수동으로 데이터베이스 헤더를 망가뜨린 PR

  • PR #6257은 데이터베이스 헤더에 쓰레기 바이트를 수동으로 주입한 뒤 데이터베이스가 손상됐다고 주장함
  • 유지보수자가 당연한 결과라고 짚은 뒤에도, 제출자 또는 봇은 LLM식 장문의 반박을 이어감

• 소스 코드에 직접 out-of-bound 접근을 넣은 제출

  • 또 다른 제출은 데이터베이스를 손상시키기 위해 소스 코드에 out-of-bound 배열 접근을 수동으로 추가함
  • 관련 이슈: tursodatabase/turso#5508

• SQL 실행을 취약점으로 주장한 PR

  • PR #4322는 표, 초록색 체크 표시, em dash가 가득한 형태였고, 임의 SQL 문 실행을 허용하는 치명적 취약점을 찾았다고 주장함
  • Turso는 SQL 데이터베이스가 SQL 문 실행을 허용한다는 점 자체를 취약점으로 볼 수 없다고 봄

• Turso의 동시 쓰기 기능을 오해한 PR

  • PR #6874는 Turso의 차별점 중 하나인 동시 쓰기를 활성화한 뒤, 저널 모드를 WAL로 되돌려 동시 쓰기를 비활성화하기 전까지 SQLite가 파일을 열 수 없음을 보임
  • 이는 시스템이 설계된 대로 동작한 결과였음

• 의도를 파악하기 어려운 제출

  • 또 다른 제출은 무엇을 하려는지 파악하기 어려운 내용이었음
  • 유지보수자 Mikael은 제출자가 보상 공지를 보고 AI 생성 도구를 Turso에 겨냥한 것으로 판단함

마지막 대응: 보증 시스템

• Turso는 질서를 세우기 위한 마지막 시도로 보증(vouching) 시스템을 설계하고 구현함
• 제출이 봇에서 온 것으로 의심되면 자동으로 닫는 방식이었고, 한동안은 어느 정도 작동함
• 이후 봇들은 PR이 닫힌 이유를 문제 삼아 수동 검토를 요청하는 이슈를 열기 시작함
• PR을 닫으면 같은 사용자 또는 다른 사용자가 곧바로 동일하거나 매우 비슷한 PR을 다시 여는 일도 여러 번 발생함

오픈 기여와 금전 인센티브의 충돌

• 저품질 제출을 만드는 쪽은 제출 생성에 1분 정도만 쓰면 되지만, Turso는 이를 읽고 이해하고 대응하는 데 몇 시간을 써야 함
• 이런 제출은 사실상 무한에 가까운 속도로 생성될 수 있음
• 자동화된 게이트키핑 시스템을 만들 수는 있지만, 무시할 수 없는 금전 보상이 붙으면 AI가 계속 논쟁하고 같은 PR을 다시 열 인센티브가 커짐
• Turso는 오픈소스 기여자 커뮤니티를 중요하게 여기며 계속 강화하겠지만, 현재로서는 오픈 시스템에서 어떤 형태의 금전 인센티브도 잘 작동하지 않는다고 봄
• 선택지는 시스템을 닫거나 인센티브를 없애는 것이며, Turso는 지금은 후자를 선택함