Claude가 rsync의 버그를 늘렸는가? — 36개 릴리스 데이터로 본 통계적 검증
2026년 5월 말, rsync 저장소에 "Please Do Not Vibe Fuck Up This Software"라는 제목의 이슈가 올라왔습니다. 300개가 넘는 댓글이 쌓이면서 Claude 보조 개발이 안정적이던 도구에 버그를 넣었다는 주장이 빠르게 확산됐습니다. Hacker News와 Lobsters에서도 비슷한 논의가 이어졌고, 표면적으로는 "AI가 오픈소스 품질을 망치고 있다"는 결론이 자연스러워 보였습니다.
그런데 alexispurslane가 직접 수집한 36개 릴리스 데이터와 통계 분석은 그 직관과 다른 그림을 그립니다. 이번 글에서는 sev/10c 지표, 순열 검정, Fisher 검정으로 검증한 결과와 함께, "Claude = 버그"라는 단순 공식이 놓치고 있는 교란 요인을 짚어봅니다.
분석의 데이터 범위
분석 대상은 RsyncProject/rsync 저장소의 v2.4.6부터 v3.4.3까지 버그 데이터가 있는 36개 릴리스입니다. 이 가운데 Claude 커밋이 포함된 릴리스는 단 두 개입니다. v3.4.2와 v3.4.3입니다.
버그 출처는 GitHub 이슈, rsync Bugzilla, rsync 메일링 리스트 세 가지입니다. GitHub 이슈와 메일링 리스트 버그는 보고 시점 직전에 배포된 최신 릴리스에 귀속시키고, Bugzilla 항목은 Version 필드가 명시한 릴리스에 귀속시키는 방식을 사용합니다. 커밋 단위로 원인을 추적하지 못한 이유는 대부분의 버그 보고가 어떤 커밋에서 비롯됐는지 명시하지 않기 때문입니다.
심각도 평가는 Qwen 3 35B 모델이 0~100점 사이의 정수로 채점했습니다. 90~100점은 조용한 데이터 손상이나 원격 코드 실행 같은 보안 취약점, 70~89점은 크래시나 행, 백업 실패, 빌드 실패, 50~69점은 우회 가능한 기능 회귀로 구분합니다. structured output JSON 스키마와 temperature 0 설정으로 같은 입력에 같은 점수가 나오도록 통제했습니다.
핵심 지표: 심각도 가중 버그/10커밋
분석의 핵심 지표는 sev/10c입니다. 계산식은 다음과 같습니다.
sev_per_10c = (sum(severity) / 100 / total_commits) * 10즉, 릴리스의 모든 버그 심각도를 0~1로 정규화해 합산한 뒤 커밋 수로 나누고, 10커밋당 값으로 환산한 것입니다. 커밋 수가 많은 릴리스가 단순히 더 많은 버그를 가질 수 있다는 점을 보정하기 위한 장치입니다.
v3.4.2는 50커밋 중 Claude 커밋이 9개였고, 실제 버그는 0개, sev/10c는 0.00으로 0백분위 릴리스입니다. v3.4.3은 34커밋 중 Claude 커밋이 28개, 버그 17개, sev/10c 3.29로 77백분위 릴리스입니다. 역사적 IQR은 0.29~2.50인데, v3.4.2는 IQR 바로 아래, v3.4.3은 IQR 바로 위에 있어 두 릴리스가 중간 분포를 서로 반대쪽에서 끼는 형태입니다.
통계 검정 결과
"Claude 릴리스가 무작위 2개 릴리스보다 나쁘거나 중앙값을 초과할 가능성이 높은가"를 검증하기 위해 두 가지 검정을 돌렸습니다.
정확 순열 검정은 가능한 2개 릴리스 조합 595개 중 272개가 Claude 그룹 평균 1.65 sev/10c 이상이어서 p값 46%라는 결과를 냈습니다. Fisher의 정확 검정은 중앙값 0.74 sev/10c 기준으로 오즈비 1.06, p값 74%를 기록했습니다. 둘 다 Claude 릴리스가 통계적으로 이상치라고 말할 수 있는 근거가 되지 못합니다.
커밋 수와 변경 규모를 따로 보면 흥미로운 점이 드러납니다. 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 릴리스는 변경 라인이 압도적으로 많았지만, 커밋 수나 심각도 가중 버그 수는 더 많지 않았다는 결과입니다.
v3.4.1이라는 강력한 반례
논란에서 자주 누락되는 사실은 v3.4.1입니다. v3.4.1은 Claude 도입 전 릴리스인데도 59버그, 9커밋, 39.39 sev/10c로 전체 데이터셋에서 가장 높은 버그율을 기록한 릴리스입니다. v3.4.0 다음 날 나온 hotfix 릴리스였고, 다른 모든 릴리스를 한 자릿수 차이 이상으로 능가했지만 당시에는 AI를 탓할 대상이 없었습니다.
v2.x 릴리스 평균이 1.11 sev/10c, v3.x 릴리스 평균이 4.23 sev/10c라는 점도 주목할 만합니다. v3.x만 비교해도 Claude 릴리스는 중간권 또는 그보다 나은 위치에 있으며, "Claude를 이상치처럼 보이게 하려면 더 조용한 과거 시대와 비교해 이미 Claude 이전에 일어난 변화를 Claude 탓으로 돌리는 형태"가 됩니다. Wald–Wolfowitz runs test는 Claude 없는 35개 릴리스에서 관측 run 13개, 무작위 기대값 18.5개, z=-1.88, p=0.060을 냈고, 0.05 기준에서는 무작위성을 기각할 만큼 강하지 않습니다.
교란 요인: LLM이 만들어낸 CVE 홍수
데이터와 일치하는 가장 그럴듯한 해석은 "현재 두 Claude 릴리스는 역사적 릴리스와 통계적으로 구별되지 않는다"입니다. v3.4.3이 3.29 sev/10c로 77백분위라 높긴 하지만, 이보다 높은 점수를 낸 역사적 릴리스가 8개나 있습니다. Hacker News의 한 사용자는 CVE 대응 보안 수정이 2007년부터 코드에 있던 코딩 오류를 드러낸 것이라고 봤고, Lobsters의 한 사용자는 "LLM이 알려진 보안 이슈를 더 많이 표면화하면서 평소보다 많은 변경이 필요해지고, 그에 따라 평소보다 많은 회귀가 따라온다"는 인과 사슬을 제시했습니다.
Andrew Tridgell 본인이 설명한 내용도 같은 맥락입니다. AI로 생성된 CVE 보고서 홍수가 rsync의 공격 표면에 빠르고 광범위한 변경을 요구했고, 그 변경량의 증가가 회귀로 이어졌다는 것입니다. Hacker News 댓글에서 공유된 구체적 사례로는 malloc이어야 할 경로까지 calloc으로 강제 변환한 커밋과, 이를 되돌린 커밋이 있으며, 되돌림 메시지만 봐도 LLM이 작성한 티가 강하게 남는다고 지적받았습니다.
이 교란 요인까지 포함하면, 문제는 "Claude 자체"라기보다 "더 많은 보안 작업과 그에 따른 변경량 증가"에 가깝습니다. Claude가 작성한 코드가 실수 없이 들어왔더라도, Claude가 표면화한 보안 이슈가 더 많은 변경을 끌어들이고, 그 변경 자체가 회귀 위험을 키운 셈입니다.
지표의 한계
이 분석의 sev/10c 지표는 커밋 복잡도나 보안 작업 강도를 통제하지 못하는 둔한 도구입니다. 같은 줄 수의 변경이라도 보안 패치는 회귀 위험이 더 높을 수 있는데, 이 차이를 구분하지 못합니다. 또한 Claude 릴리스 표본이 단 2개에 불과해 통계 검정력이 약하다는 점, 36개 릴리스라는 표본 크기 자체가 작은 점도 한계입니다.
"Claude가 분명히 더 나쁘게 만들었다"는 명제는 릴리스 분포, 순열 검정, Fisher 검정 어느 쪽에서도 뒷받침되지 않습니다. 반대로 "Claude 커밋은 일반적으로 앞으로도 더 나쁘게 만들지 않는다"는 결론도 이 데이터에서 나오지 않으며, "현재 두 릴리스는 평범한 범위 안에 있다"는 정도에 그친다는 점이 정확한 해석입니다.
오픈소스 품질 논쟁에 대한 시사점
이번 rsync 사례는 LLM 보조 개발과 오픈소스 품질을 다룰 때 데이터 없이 감정적으로 결론 내리는 함정을 잘 보여줍니다. 단일 회귀를 Claude와 연결하기 전에 최소한 다음 두 가지를 확인해야 합니다.
1. 같은 시점의 다른 릴리스들이 비슷한 버그율을 보였는가
2. 변경량의 증가 같은 교란 요인은 없는가
v3.4.1이 Claude 도입 전에 최악의 버그율을 기록했다는 사실은, "rsync 자체가 v3.x 체제에서 구조적으로 더 많은 회귀를 겪어 왔다"는 점을 시사합니다. LLM 도입과 별개로 v3.x로의 전환이 단순 버그 수를 늘렸을 가능성이 높습니다. AI 보조 개발의 영향을 평가하려면, v3.x 안에서 Claude 릴리스와 비Claude 릴리스를 비교했는지, 아니면 v2.x와 v3.x 전체를 통틀어 비교했는지를 구분해야 합니다.
결론적으로, 이번 통계 분석은 "Claude가 rsync의 버그를 늘렸다"는 대중적 주장을 지지하지 않습니다. 다만, 변경량 증가가 회귀를 끌어들이는 부수 효과는 분명히 존재하므로, AI 보조 개발이 활성화된 프로젝트에서는 코드 리뷰와 테스트 커버리지 강화가 그 어느 때보다 중요해졌다고 보는 것이 합리적입니다.
📚 출처
'AI 뉴스' 카테고리의 다른 글
| Ladybird, 공개 풀 리퀘스트 수락 중단 — AI 시대 오프소스 신뢰 모델의 대전환 (0) | 2026.06.06 |
|---|---|
| 우주비행사들, 공기 누출 수리로 대피한 뒤 ISS 복귀 지시 받아 — 7년 만의 누출 위기 돌아보기 (0) | 2026.06.06 |
| 자율형 AI 웜, 기업 네트워크를 스스로 누비다: 케임브리지 연구진의 충격적인 PoC (1) | 2026.06.06 |
| Project Capture - AI 에이전트용 화면 캡처 자동화 스킬 정리 (0) | 2026.06.06 |
| AI 사용과 수학 능력 저하가 만든 Berkeley CS 수업의 낙제율 급증 (0) | 2026.06.06 |