• Claude 보조 릴리스는 rsync v3.4.2와 v3.4.3 두 건뿐이며, 심각도 가중 버그/10커밋 기준으로 과거 릴리스보다 유난히 버그가 많다는 증거가 없음
  • sev/10c는 버그 심각도 점수를 0~1로 정규화해 릴리스별로 합산하고 커밋 수로 나눈 뒤 10커밋당 값으로 환산하는 핵심 지표임
  • v3.4.2는 50커밋·9개 Claude 커밋·버그 0개·0.00 sev/10c이고, v3.4.3은 34커밋·28개 Claude 커밋·버그 17개·3.29 sev/10c로 IQR 양쪽을 끼며 어느 쪽도 이상치가 아님
  • 정확 순열 검정 p값은 46%, Fisher의 정확 검정 p값은 74%, 오즈비는 1.06으로, Claude 릴리스가 무작위 2개 릴리스보다 나쁘거나 중앙값 초과 가능성이 높다는 신호가 거의 없음
  • v3.4.1은 Claude 도입 전 릴리스인데도 59버그·9커밋·39.39 sev/10c로 전체 데이터의 최악값이었으며, rsync 논란의 핵심은 역사적 분포 없이 단일 회귀를 Claude와 연결한 데 있음

배경과 질문

  • 2026년 5월 말 rsync 논란은 v3.4.3 회귀와 해당 릴리스의 Claude 커밋을 연결한 Mastodon 게시물에서 시작해 Hacker News와 GitHub 이슈 "Please Do Not Vibe Fuck Up This Software"로 확산, 해당 이슈에는 300개가 넘는 댓글이 쌓임
  • 반복된 핵심 명제는 Claude 보조 개발이 안정적이던 도구에 버그를 넣었다는 형태였고, 데이터 질문은 Claude 보조 릴리스가 역사적 릴리스보다 비정상적으로 버그가 많은지 여부임
  • Lobsters에서는 릴리스별 회귀 수를 시간 차트로 보자는 요청이 나왔고, 분석의 초점은 “Claude 보조 릴리스가 유난히 버그가 많은가”라는 단일 질문임

데이터 범위와 재현성

  • 데이터는 RsyncProject/rsync의 v2.4.6부터 v3.4.3까지 버그 데이터가 있는 36개 릴리스이며, Claude 커밋이 있는 릴리스는 v3.4.2와 v3.4.3 두 개뿐임
  • 지표·방법론·데이터 소스 선택은 사람이 직접 했고, 통계학 석사 학위를 가진 배우자의 조언을 반영함
  • 데이터 수집, DuckDB 적재, 뷰 생성, 통계 분석 스크립트는 GLM 5.1이 작성했지만, 모든 숫자·통계·카드·그래프는 통계 분석을 실행한 Python 스크립트가 자동 템플릿으로 삽입함
  • 재현용 alexispurslane/rsync-analysis 저장소는 전체 파이프라인을 처음부터 끝까지 실행할 수 있음

지표와 버그 귀속 방식

  • 핵심 지표는 심각도 가중 버그/10커밋인 sev/10c이며, 계산식은 sev/10c = (Σ severity/100 ÷ total_commits) × 10임
  • 커밋은 기본 브랜치의 committer date 순서로 정렬하고, 각 릴리스 범위는 이전 태그부터 해당 태그까지의 커밋으로 잡으며, pre·rc 태그는 경계에서 제외해 최종 릴리스에 흡수하는 방식임
  • 버그 출처는 GitHub 이슈, rsync Bugzilla, rsync 메일링 리스트 세 가지이며, GitHub 이슈와 메일링 리스트 버그는 보고 시점 직전에 배포된 최신 릴리스에 귀속함
  • Bugzilla 항목은 “Version” 필드가 버그가 보고된 릴리스를 명시하므로 해당 릴리스에 귀속함
  • 릴리스 단위 분석을 택한 이유는 비판 자체가 “Claude 커밋이 있는 릴리스 전체가 더 버그가 많아졌다”는 형태이고, 대부분의 버그가 정확히 어떤 커밋에서 비롯됐는지 명시하지 않기 때문임

심각도 평가 방식

  • 모든 버그 보고서는 Qwen 3 35B가 0~100점 심각도로 채점했고, 프롬프트는 실제 사용자 영향 관점의 선임 신뢰성 엔지니어 역할을 부여함
  • 90~100점은 조용한 데이터 손상·데이터 손실·원격 코드 실행 또는 무단 접근 보안 취약점, 70~89점은 크래시·행·백업 실패·빌드 실패, 50~69점은 우회 가능한 기능 회귀로 구분함
  • Bugzilla와 메일링 리스트는 본문 없이 제목만 있었으므로 모델이 제목만 보고 평가했고, 정보가 부족하면 40~60점 중간 범위로 기울도록 지시함
  • 출력은 structured output의 JSON schema로 정수 심각도만 허용했고, temperature 0으로 고정해 같은 입력이 같은 점수를 내도록 설정함
  • 기능 요청, 스팸, AI 관련 비기술적 항의, 빈 제출처럼 0점을 받은 이슈는 기본 버그 수에서 제외함

Claude 릴리스의 통계 결과

  • v3.4.2는 50커밋 중 Claude 커밋 9개, 실제 버그 0개, 0.00 sev/10c, 0백분위 릴리스임
  • v3.4.3은 34커밋 중 Claude 커밋 28개, 버그 17개, 3.29 sev/10c, 77백분위 릴리스임
  • 역사적 IQR은 0.29~2.59 sev/10c이며, v3.4.2는 IQR 바로 아래, v3.4.3은 IQR 바로 위에 있어 두 릴리스가 중간 분포를 서로 반대쪽에서 끼는 형태임
  • 정확 순열 검정은 가능한 2개 릴리스 조합 595개 중 272개가 Claude 그룹 평균 1.65 sev/10c 이상이어서 p값 46%라는 결과를 냄
  • Fisher의 정확 검정은 중앙값 0.74 sev/10c 기준으로 Claude 릴리스가 중앙값 초과에 더 자주 놓이는지 봤고, p값 74%와 오즈비 1.06이라는 결과를 냄

커밋 수와 변경 규모

  • Claude 릴리스는 평균 42커밋, Claude 미포함 릴리스는 평균 185커밋이었고, 임의 2개 릴리스가 그만큼 많거나 더 많은 커밋을 가질 확률은 88%였음
  • GitHub compare API 기준 변경 라인은 Claude 릴리스 평균 3,756줄, Claude 미포함 릴리스 평균 696줄이었고, 임의 2개 릴리스가 그만큼 많거나 더 많은 변경 라인을 가질 확률은 5%였음
  • 심각도 가중 버그 수는 Claude 릴리스 평균 5.6개, Claude 미포함 릴리스 평균 14.9개였고, 임의 2개 릴리스가 그만큼 많거나 더 많은 심각도 가중 버그를 가질 확률은 77%였음
  • 결론적으로 Claude 릴리스는 변경 라인이 훨씬 많았지만, 커밋 수나 심각도 가중 버그 수가 더 많지는 않은 결과임

버전 체제와 사전 이상치

  • v2.x 릴리스 평균은 1.11 sev/10c, v3.x 릴리스 평균은 4.23 sev/10c로 v3.x 쪽이 더 높은 버그율을 보임
  • v3.x만 비교해도 Claude 릴리스는 중간권 또는 그보다 나은 위치에 있으며, Claude를 이상치처럼 보이게 하려면 더 조용한 과거 시대와 비교해 이미 Claude 이전에 일어난 변화를 Claude 탓으로 돌리는 형태가 됨
  • Wald–Wolfowitz runs test는 Claude 없는 35개 릴리스에서 관측 run 13개, 무작위 기대값 18.5개, z=-1.88, p=0.060을 냈고, 0.05 기준에서는 무작위성을 기각할 만큼 강하지 않음
  • v3.4.1은 Claude 도입 전 릴리스인데도 59버그·9커밋·39.39 sev/10c로 전체 데이터에서 가장 높은 버그율을 기록한 릴리스임
  • v3.4.1은 v3.4.0 다음 날 나온 hotfix 릴리스였고, 다른 모든 릴리스를 한 자릿수 차이 이상으로 넘는 최고 버그율을 보였지만 AI를 탓할 대상이 없던 시기였음

해석과 한계

  • 데이터와 일치하는 해석은 “현재 두 Claude 릴리스는 역사적 릴리스와 통계적으로 구별되지 않는다”는 쪽임
  • v3.4.3은 3.29 sev/10c로 77백분위라 높기는 하지만 극단값은 아니며, 이보다 높은 점수를 낸 역사적 릴리스가 8개 있음
  • “Claude가 분명히 더 나쁘게 만들었다”는 명제는 릴리스 분포, 순열 검정, Fisher 검정 어느 쪽에서도 뒷받침되지 않음
  • 반대로 “Claude 커밋은 일반적으로 앞으로도 더 나쁘게 만들지 않는다”는 결론도 이 데이터에서 나오지 않으며, 현재 두 릴리스가 평범하다는 범위에 그침
  • 이 지표는 커밋 복잡도나 보안 작업 강도를 통제하지 못하는 둔한 도구라는 한계를 가짐

논의된 교란 요인

  • Hacker News의 한 사용자는 CVE 대응 보안 수정이 2007년부터 코드에 있던 코딩 오류를 드러낸 것으로 보인다고 봄
  • Lobsters의 한 사용자는 “LLM → 알려진 보안 이슈 증가 → 평소보다 많은 변경 필요 → 평소보다 많은 회귀”라는 인과 사슬을 제시함
  • Andrew Tridgell은 AI 생성 CVE 보고서 홍수가 rsync의 공격 표면에 빠르고 광범위한 변경을 요구했다고 설명함
  • 이 교란 요인까지 포함하면 문제는 Claude 자체라기보다 더 많은 보안 작업과 그에 따른 변경량 증가라는 쪽에 가까움