Antithesis, SQLite WAL-Reset 버그를 범용 동시성 부하로 15분 만에 재현했다고 주장

Antithesis가 Tailscale과 SQLite의 6개월짜리 원인 분석을 어떻게 줄였을지 후속 글로 설명하겠다고 함.

이미 버그가 있다는 정보를 넣지 않았다는 근거가 글과 저장소에 보인다고 봄. 다른 버그도 찾았다고 하니 후속 공개를 기다리는 중임.

글쓴이 말로는 WAL 삽입과 체크포인트를 돌리는 범용 부하를 만들었고, 특정 버그 지식 없이도 여러 트랜잭션 시스템에 쓰는 방식이라고 함.

SQLite 어느 하위 시스템에서 문제를 찾아야 하는지 이미 안 상태였다면 격리 난이도가 얼마나 낮아졌는지 궁금함. 사후에 보면 당연해 보이는 실험일 수 있음.

소스 계측 뒤 WAL 버그 재현을 지시한 것처럼 읽힘. Antithesis가 실제로 무엇을 분석하고 왜 이 버그를 찾을 수 있었다고 확신하는지 기술 설명이 부족함.

Claude에 넣은 프롬프트를 찾지 못했음. 그냥 테스트 스위트를 만들라고 했는지, 버그를 찾도록 유도했는지 알 수 없어서 공정한 검증인지 판단하기 어렵더라.

글쓴이는 3.51.2에서 여러 프로세스로 삽입과 체크포인트를 돌리는 부하를 만들라고 했고, 에이전트도 버그 존재는 알고 있었다고 밝힘. 다만 부하 자체는 버그를 알지 못하며 WAL 체크포인트 시스템을 스트레스하는 평소 방식이라고 설명함.

예전 Antithesis 글은 기술적 사고 과정이 중심이고 제품 홍보는 곁다리였는데, 이번 글은 판매 글 비중이 너무 커 보임. Claude 모바일에 몇 줄 입력한 이야기가 기술적 본문 대부분을 차지해서 아쉬웠음.

TLA+로 같은 버그를 찾았다는 관련 글도 있음.

생산 장애가 SQLite, Tailscale, Linux 중 어디에 있는지조차 모르는 상황에서 Antithesis로 바로 연결할 수 있을지 의문임. 도구에 모든 맥락을 주면 이 버그를 안정적으로 찾는지도 알고 싶음.

누군가 문제를 발견한 뒤에야 더 싼 재현 방법이 나오는 P=NP 같은 분위기임. 문제의 존재와 대략적 위치를 이미 아는 일이 절반 이상인 듯함.