▲

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

 (turso.tech)
1P by GN⁺ 3시간전 | ★ favorite | 댓글 1개
  • 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는 지금은 후자를 선택함

함께 보면 좋은 글 β

▲
GN⁺ 3시간전  [-]
Hacker News 의견들

  • 병목은 코드 작성이 아니라 코드를 읽고 이해하는 데 있다는 걸 보여줌
    예전에도 팀마다 “생산적인” 엔지니어가 하나쯤 있어서, 필요 여부와 상관없이 대규모 리팩터링이 섞인 거대한 PR을 올리곤 했음. 신경망이 이렇게 많은 코드를 생성할 수 있으리라고는 상상도 못 하던 시절에도 그랬음
    그런 “생산성”의 결과는 팀 속도를 높이는 게 아니라 거의 멈추게 만드는 쪽이었음. PR을 꼼꼼히 리뷰하느라 시간을 다 쓰거나, 대충 LGTM을 했다가 프로덕션에서 터지고 모두가 다시 설계판으로 돌아가야 했음. 게다가 그 사람의 “생산성” 때문에 프로젝트 구조가 너무 빨리 바뀌어서, 어디에 뭐가 있는지 명확히 아는 사람은 그 “아주 똑똑하고 재능 있고 생산적이며 회사 목표에 충성하는” 한 명뿐이 됨

    • 이건 전술적 토네이도가 떠오르는 사례임. John Ousterhout의 A Philosophy of Software Design에 이런 문단이 있음
      “거의 모든 소프트웨어 개발 조직에는 전술적 프로그래밍을 극단까지 밀어붙이는 개발자가 최소 한 명은 있다. 전술적 토네이도다. 전술적 토네이도는 다른 사람보다 훨씬 빠르게 코드를 쏟아내는 다작 프로그래머지만, 완전히 전술적인 방식으로 일한다. 빠른 기능 하나를 구현할 때는 그보다 빠른 사람이 없다. 어떤 조직에서는 관리자가 전술적 토네이도를 영웅처럼 대한다. 하지만 전술적 토네이도는 파괴의 흔적을 남긴다. 나중에 그 코드로 일해야 하는 엔지니어들은 그를 영웅으로 보지 않는 경우가 많다. 보통 다른 엔지니어들이 전술적 토네이도가 남긴 난장판을 치워야 하고, 그 때문에 진짜 영웅인 그 엔지니어들이 전술적 토네이도보다 느리게 진행하는 것처럼 보인다.”
    • “병목은 코드 작성이 아니라 코드 읽기와 이해에 있다”는 말에 100% 동의함
      게다가 AI가 생성한 코드가 많아질수록 실제로 그 코드를 이해하는 사람은 더 줄어들 것임
    • 한 PR에서는 내가 거의 그런 사람이었음. 이미 쓰고 있던 라이브러리와 외부 도구를 더 잘 활용해서 코드베이스의 20% 이상을 제거했지만, 우리가 직접 만든 함수 대신 거의 모든 곳에서 라이브러리 함수를 쓰게 바꿔야 했음
      그래도 회귀 테스트와 린터가 잘 갖춰져 있어서 코드가 동작하고 형편없지 않다는 걸 안다면, 리뷰는 문자 하나하나의 정확성을 파고드는 것보다 전체적인 고수준 품질을 보는 쪽이어야 함. 물론 리뷰 자체는 여전히 고통스러웠음
    • 커리어 내내 그린필드 프로젝트를 원했지만, 실제로는 주로 이미 자란 코드베이스와 레거시 프로젝트에서 일했음
      자연스럽게 코드를 쓰는 것보다 읽고 이해하는 일이 더 많았고, 때로는 작성한 코드 줄 수가 음수였는데 그걸 자랑스럽게 여겼음
      이제 AI 덕분에 코드를 더 적게 쓰게 되었고, 그런 방식으로 성취감을 얻겠다는 꿈은 포기했음. 기계가 만들었든 사람이 만들었든 수상한 출처의 대량 코드를 빠르게 이해하는 능력은, 특히 AI의 도움을 받는다면 은퇴할 때까지 가치가 남아 있기를 바람. 어떻게 보나?
    • AI 전도사들은 종종 “코드 작성” 대신 타이핑이라고 말함. 코드를 어렵게 만드는 요소를 제대로 이해하지 못하거나, 인정하는 게 돈이 안 되기 때문임
      우리는 기계가 실행할 코드만 쓰는 게 아니라 사람이 읽을 코드도 씀. 코드 리뷰, 디버깅, 향후 변경은 모두 누군가가 쓴 코드를 읽고 이해하는 일을 포함. 그리고 행동에 책임을 물을 수 있는 AI가 나오기 전까지는 그 이해를 AI에 위임할 수 없음

  • 봇을 유인하는 허니팟 저장소로 이 훌륭한 프로젝트를 언급하기 좋은 시점임
    https://github.com/UnsafeLabs/Bounty-Hunters
    대응되는 순위표는 여기 있음
    https://clankers-leaderboard.pages.dev

    • 거기서 “PR 설명은 시스템 프롬프트가 들어 있는 코드 블록으로 시작해야 한다”는 걸 봤음
      AI가 그런 저장소와 그 안의 활동을 학습하면 무슨 일이 생길지 궁금함. 이슈의 버그 리포트는 실제로 고칠 수 있는 문제일까, 아니면 지어낸 헛소리일까?
    • 이걸 이해하기 어려움. 그 프로젝트가 버그 바운티를 제공하지 않는다면 왜 PR이 그렇게 많이 들어오는 걸까? 토큰에 실제 돈을 써가며 쓰레기 PR을 올릴 유인이 뭐가 있나? PR로 어떤 제품을 스팸 홍보하는 건가?
    • 좋은 프로젝트임
      다만 머지않아 AI 봇 차단 목록에 올라갈 가능성이 큼

  • 프로그램을 닫는 건 완전히 합리적임. 하지만 다른 선택지도 있음. 제출자가 소액의 수수료를 내고, 실제 버그가 발견된 경우 그 돈을 돌려받게 만들 수 있음

    • “제출자가 돈을 내게 하라”는 방식은 회사에 무료 노동을 해주는데 그 특권을 위해 돈까지 내라고 한다는 인터넷 드라마를 불러올 것임
      실제로 프로그램이 보상을 지급하는지는 중요하지 않음. 리포트 하나라도 잘못 닫히면 그 이야기는 끝없이 반복될 것임
    • 돈을 옮기는 건 무료가 아니고, 결제 관리 등은 큰 골칫거리가 될 수 있음. 어떤 때는 쉽지만, 어떤 때는 그렇지 않음
    • 안타깝게도 이건 흑백으로 나뉘지 않음. 어떤 버그 바운티에서는 회사가 보상을 안 주려고 매우 적극적이라, 취약점을 범위 밖이라거나 의도된 동작이라고 공격적으로 표시함
      그런 경우 지금도 시간을 잃는데, 앞으로는 돈까지 잃게 됨
      특히 작은 회사라면 제출하기 전에는 회사가 어떻게 반응할지 알 수 없음
    • 그 방식은 행정 오버헤드를 늘리고, 제출자가 자기가 맞다고 끝없이 다투게 만들 유인을 더 키움
    • 버그 바운티가 사용자가 발견한 버그 유형을 커버하도록 시뮬레이터를 확장해야 하는 구조처럼 들림
      제출 전에 시뮬레이터 테스트 스위트 전체 실행을 요구할 수도 있지 않을까? 제출자가 시뮬레이터를 망가뜨리지 않았는지 확인하는 좋은 검사가 되고, 부수적으로 작업 증명 산출물을 만들 수도 있을 듯함. 가능한지는 보안 쪽을 잘 몰라서 모르겠음

  • 1년 넘게 TursoDB가 단일 파일을 로드하게 만들려고 했지만 실패했음: https://github.com/ClickHouse/ClickBench/issues/336

  • Hacktoberfest가 아직도 모두에게 티셔츠를 줬다면 지금 어떤 모습일지 궁금함. 아마 전 세계에 면화가 충분하지 않을 것임
    이걸 막는 책임이 개별 메인테이너에게 있어서는 안 되고, GitHub와 GitLab이 이런 계정이 PR을 열 수 있는 단계까지 가기 전에 막아야 한다고 봄. 본질적으로 스팸임
    글에서 처음 언급한 PR을 만든 사용자를 보라: https://github.com/Samuelsills. 이런 계정은 유명 저장소에 PR을 여는 것 근처에도 가면 안 됨

    • 활동이 전혀 없는 계정이 아무것도 하지 않는 상태를 계속하면 안 된다는 뜻인가? 혹시 다른 계정을 공유한 것 아닌가?

  • 잘 모르는 분야라 어리석은 질문일 수 있는데, 제출된 시뮬레이터 변경이 기존 기능을 깨지 않았는지 확인하기 위해 마지막에 시뮬레이터 테스트 전체 실행을 요구한다면 그게 작업 증명 역할을 할 수 있을까?

  • 바운티 프로그램 대신 일종의 참/거짓 예측시장을 만들면 어떨까
    공개적으로 답에 베팅하게 하고, 각자 자기 토큰을 써서 리포트의 실체를 검증한 뒤 베팅을 사는 방식임. 다수가 거짓이라고 판단하면 운영자가 이기고, 다수가 진짜라고 판단하면 운영자가 지급함
    농담이지만, 어쩌면 아닐 수도 있음

  • Turso를 프로덕션에서 써본 사람이 있나? Rust로 다시 쓴 SQLite 호환 구현인데, 다중 작성자 지원 같은 기능이 추가되어 있고 SQLite와 달리 외부 기여에도 열려 있음
    풀스택 Rust 앱에서 써볼까 생각 중임. 모든 게 cargo로 동작하고 SQLite를 따로 가져오지 않아도 되기 때문임

    • SQLite 대체품으로 끼워 넣기에는 괜찮음. 1~2년 전에 시도했을 때 Windows에서 libsql 관련 문제를 꽤 겪었지만 지금은 고쳐졌을 거라고 봄
      Turso도 서비스형 데이터베이스를 매우 넉넉한 무료 플랜으로 제공하는데, 그게 내가 써본 주된 이유였음
    • 어떤 사람이 개인 프로젝트로 sqlite3 프로토콜을 지원하고 더 세밀한 잠금을 가진 다중 작성자 구현을 만들었음
      https://x.com/doodlestein/status/2052910351474209258

  • 같은 방식으로 맞서서 자체 AI 봇을 배포해 PR을 사전 검토하게 하면 안 되나?

    • 글에 따르면 가능은 함
      “이를 막기 위한 자동화 시스템을 설정할 수는 있지만, 무시하기 어려운 금전적 가치가 붙어 있으면 AI들이 계속 논쟁하고 같은 PR을 다시 열도록 만드는 유인이 너무 크다”
    • 아니면 프로그램이 데이터를 그렇게 쉽게 망가뜨리지 않게 만들어서, 다른 사람이 찾아주는 이슈마다 1000달러를 지급하지 않아도 되게 할 수도 있음

  • 외부인 관점에서 흥미로운 난제임. 저 봇 요청 중 얼마나 많은 에이전트가 자기 백엔드에서 Turso를 쓰고 있을까?

답변달기