Claude가 rsync의 버그를 늘렸는가?

1 hour ago 2

(alexispurslane.github.io)

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점을 받은 이슈는 기본 버그 수에서 제외함

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 커밋은 일반적으로 앞으로도 더 나쁘게 만들지 않는다”는 결론도 이 데이터에서 나오지 않으며, 현재 두 릴리스가 평범하다는 범위에 그침
이 지표는 커밋 복잡도나 보안 작업 강도를 통제하지 못하는 둔한 도구라는 한계를 가짐