2026년 5월 말, rsync 프로젝트에서 클로드(Claude)가 작성한 코드로 인해 버그가 발생했다는 근거 없는 주장이 마스토돈과 해커뉴스를 중심으로 확산되며 큰 논란이 일었다. 이에 대해 한 개발자가 통계학 석사 학력을 가진 아내의 조언을 받아 철저한 데이터 분석을 수행하고, AI가 수치를 조작하거나 환각(hallucination) 현상을 일으키지 않도록 전체 파이프라인을 공개하여 결과를 검증할 수 있도록 했다. 이 사건은 오픈소스 내 AI 코드 도입에 대한 맹목적인 혐오와 비판이 얼마나 빠르게 확산할 수 있는지, 그리고 이를 방어하기 위해 얼마나 투명하고 엄격한 데이터 검증이 필요한지를 보여줍니다.
번역된 본문
0 · 면책 조항: AI 보조 도구는 어떻게 사용되었는가
이 보고서가 '클로드가 클로드를 옹호하는 것', 'AI가 만든 쓰레기(AI slop)', '아마도 전부 환각(hallucination)일 것' 등의 비난을 피하기 위해, 이 보고서가 작성된 방식에 대한 몇 가지 핵심 사항을 설명하는 것이 좋겠다고 생각했습니다. 모든 지표, 방법론, 데이터 소스는 펜실베이니아 주립대에서 통계학 석사 학위를 취득한 제 아내와의 상담을 통해 제가 독점적으로 선택했습니다. 이 방법론은 아내의 의견을 직접적으로 반영한 것입니다. 클로드 도입 전후의 코드 10줄당 버그 수를 단순 비교하는 것은 클로드 도입 이후의 샘플 수가 적어 노이즈의 영향을 너무 많이 받을 것이며, 비슷한 이유로 다양한 변수의 상대적 영향을 파악하기 위해某种 선형 회귀 모델(linear regression model)을 구축하려는 시도 역시 작동하지 않을 것이라고 아내가 지적했습니다. 아내는 클로드 도입 이후의 릴리스가 과거 분포의 어느 위치에 해당하는지, 그리고 과거 데이터를 바탕으로 했을 때 클로드 도입 이후 릴리스만큼 '나쁘거나' 그보다 더 심한 릴리스가 나올 확률이 얼마나 되는지를 확인하는 것이 현 상황에서 할 수 있는 최선의 방법일 것이라고 구체적으로 말해주었습니다. 저는 이 작업에 며칠을 보냈으며, 깃허브 저장소(GitHub repo)를 만들기도 전에 이미 이틀을 할애했고, (앞서 언급한 아내의 피드백을 반영하여) 더 나은 방법론을 사용하기 위해 최소 한 번 이상의 대대적인 전면 수정을 거쳤습니다. 이는 저에게 상당한 수동적이고 인지적인 노력이 필요한 작업이었습니다.
데이터를 가져오고, DuckDB 데이터베이스 파일로 취합하며, 해당 DB에 뷰를 구성하고, 그 후 해당 데이터에 대해 통계 분석을 수행하는 데 사용된 스크립트는 실제로 GLM 5.1에 의해 작성되었습니다. 지금 보고 계신 최종 보고서 웹페이지의 HTML과 원본 산문의 상당 부분 역시 마찬가지입니다. 하지만 가장 중요한 점은, 이 보고서의 모든 숫자, 통계, 카드, 그래프는 통계 분석을 실행한 파이썬(Python) 스크립트에 의해 직접 자동 템플릿화되어 삽입되므로, 숫자에 대한 어떠한 환각(hallucination)이나 불일치의 가능성도 완전히 차단된다는 것입니다. 이 글을 해커뉴스에 게시한 후 실제 내용에 대한 실질적인 의견, 토론, 반응을 거의 받지 못하자, 저는 모든 산문을 제 목소리로 다시 작성하기로 결정했습니다. 누군가 저의 장황함이나 문장 구조에 대해 불평한다면 — 사람들은 보통 그렇게 합니다. 이것이 제가 원래 AI에게 산문 작성을 맡겼던 이유 중 하나이며, 템플릿화로 인해 더 이상 필요 없게 된 다른 이유들도 있었습니다 — 그들은 제각기 알아서 하시면 됩니다. 여기에 제시된 데이터와 결과를 재현하고, 그것이 정확히 어떻게 계산되었는지 검사하고 싶다면, 여기서 저장소를 찾을 수 있습니다. 저는 파이프라인을 처음부터 끝까지 완전히 처음부터 실행할 수 있도록 의도적으로 만들었습니다. 따라서 제가 데이터를 조작하거나 망가뜨렸다고 믿도록 강요하는 신비한 DB 블롭(blob) 없이도 전체 파이프라인을 엔드투엔드로 볼 수 있습니다. 이 숫자들에 대해 화가 나 있다면, 먼저 그곳을 확인하십시오.
1 · 배경: rsync를 둘러싼 분노
2026년 5월 말, rsync에서 큰 논란이 터졌습니다. 첫째로, 특정 사용자가 특정 릴리스로 업그레이드한 후 겪은 회귀(regression)와 해당 릴리스에 클로드 커밋(commit)이 포함되어 있다는 것의 허위 상관관계를 지적하는, 아무런 근거 없는 마스토돈 게시물이 올라왔습니다. 이 게시물의 조회 수는 알 수 없지만, '좋아요'와 '부스트' 수는 쉽게 1,000개를 넘어섰고 32명의 고유 사용자로부터 58개의 답글을 얻는 등 상당한 인기를 끌었습니다. — 근거 없는 반(AI) 혐오가 항상 그렇듯이 — 이 게시물은 해커뉴스에까지 퍼져나갔고, 81개의 댓글이 달렸으며, LLM을 안전하게 사용할 수 있는 사람은 없다는 것을 이것이 일劳永逸地(한 번에) 증명했다며 혼합된 공포, 분노, 환호성으로 가득 찼습니다. 그 모든 속에서 회귀와 버그가 클로드에 의해 발생했다는 견해를 더욱 부추긴 특정 댓글이 하나 있었습니다. 2026년 5월 30일, 이렇게 번져가던 분노는 하나의 초점으로 급속히 뭉쳤습니다. 바로 rsync 저장소에 대해 열린 '이 소프트웨어를 감성으로 망치지 마세요(Please Do Not Vibe Fuck Up This Software)'라는 제목의 깃허브 이슈였습니다. 이 이슈는 프로젝트의 클로드 사용을 비판하는 마스토돈 게시물의 스크린샷을 첨부했습니다. 그것은...
0 · Disclaimer: How AI Assistance Was Used In order to avoid accuastions of this "just being Claude defending Claude," "AI slop," "probably all hallucinations," etc., I've decided it's probably worth explaining a few key points about how this report was created: All metrics, methodology, and data sources were exclusively chosen by me, in consultation with my wife, who has a Master's Degree in Statistics from Penn State University. The methodology is directly based on my wife's input: she was the one that pointed out that trying to just compare bugs per ten lines of code before and after would likely be too effected by noise because of the low number of post-Claude samples, and that, for similar reasons, trying to build some kind of linear regression model to ascertain the relative effects of different variables would probably also not work. She specifically told me that looking at where the post-Claude releases fall into the historical distribution, and how likely from the historical distribution we would be to get releases as "bad" or worse than the post-Claude releases, was probably the best that could be done. I spent several days on this, two before even creating the GitHub repo and had at least one major total rewrite of the report to use a better methodology (given the feedback from my wife mentioned above). This was a lot of manual, cognitive effort on my end. The scripts used to fetch the data, collate it into a DuckDB database file, construct the views on that DB, and then do the statistical analysis on that data, were indeed written by GLM 5.1 , as was the HTML and much of the original prose for the final report webpage you're looking at right now. Crucially, however, all numbers, statistics, cards, and graphs in this report are automatically templated in directly by the Python script that ran the statistical analysis , thus avoiding any possibility of hallucinations or inconsistencies in the numbers. After posting this on Hacker News and recieving almost no substantive input, discussion, or response on the actual content of the article, I decided to rewrite all of the prose in my own voice. If anyone complains about my verbosity or sentence structure — as they usually do, which is the reason I originally let the AI write the prose, among other reasons obsoleted by templating — they can go fuck themselves. If you want to replicate the data and results here, and inspect exactly how they were calculated, you can find the repository here . I have purposefully made it so that the pipeline can be run end to end completely from scratch, so you can see the entire pipeline end-to end, with no mysterious DB blobs forcing you to trust that I didn't doctor or screw up the data. If you want to be mad about the numbers, look there first. 1 · Background: The rsync Outrage In late May 2026, rsync blew up. First, an evidence-free Mastodon post was made pointing to a spurious correlation between a regression that particular user experienced upon upgrading to a release, and that release having Claude commits in it. It was viewed an unknown number of times, but even likes and boosts passed the thousands mark handily, and it gained significant traction — as all spurious anti-AI hate does —, seeing 58 replies from 32 unique users. Someone rages about "cognitive surrender" with no evidence; another suggests adding rsync to the famous open-slopware blacklist . From there, it spread to Hacker News , with 81 comments, full of mixed dread, anger, and crowing about how this finally proves once and for all no one can use LLMs safely. Among all that was one particular comment which spurred further the view that the regressions and bugs were caused by Claude. This On May 30, 2026, this burgeoning outrage emergently coalesced into a single focal point: a GitHub issue titled "Please Do Not Vibe Fuck Up This Software" , opened against the rsync repository. It attached a screenshot of the Mastodon post criticizing the project's use of Claude. That's it. No bug report, no technical content, no attempt to actually ascertain if the concern was real or justified; just 350+ comments ranging from thoughtful concern to outright harassment (most of the most egregious, unreasonable, and outright violent comments have since been deleted; few thought to preserve them). The thread did not stop at words. As is typical for anti-AI users , it eventually escalated to fantasies of violence. One user posted a now deleted comment including My Little Pony drawings of themselves strangling the "project janitor that pushed vibecoded commits": Completing the internet outrage cycle, this issue in turn spread to Hacker News , generating hundreds more comments. Some attempted to point at the number of regressions after the introduction of Claude — "The Linux Mint Timeshift tool has an issue open documenting a number of regressions that are currently open on the rsync issues page, that were only introduced post-vibecoding" — as evidence that it was worse. Others pointed out that those regressions were not caused by Claude, and in response, the goalposts were moved again. Over and over, the core theme was one central claim, repeated everywhere: Claude-assisted development introduced bugs into a previously stable tool. AI is cognitive surrender, is cocaine, is loss of craft, and the users are right to be angry as a result: People are very justifiably angry that a very stable, well trusted tool , has started to immediately go downhill… all because the main dev is vibecoding that software. — fao_ on Hacker News However, this isn't doesn't have to be a question solved only on the basis of — ironically — vibes. This is something that could be, at least to a degree, empirically tested. Some even pointed that out: On Lobste.rs, in response to the Medium essay Tridge himself posted in response , finally some users like boramalper begin to actually ask for evidence one way or another: It'd be interesting if someone actually did a timechart of regressions after each release (if at all possible) to see if the number actually went up recently or not. — boramalper on Lobsters User bitshift replied: "I would also love to see such a chart. It wouldn't be completely informative… But at least it would be something objective we could measure." This analysis is that chart. Or, well, as best as it can be made, given the limitations of the data (see the previous section). 2 · Executive Summary 46 releases with bug data, spanning v2.4.6 to v3.4.3 2 releases have Claude commits: v3.4.2 (9 Claude, 0.80 bugs/10c) and v3.4.3 (28 Claude, 6.76 bugs/10c) Both fall inside the middle 50% of the historical distribution Exact permutation test p-value = 46%: if you pick any 2 releases at random, you'd score as bad or worse 46% of the time The historical mean is 2× the Claude mean (7.59 vs 3.78 bugs/10c) No regime shift detected: runs test p=0.123, sequence is consistent with randomness v3.4.1 (102 bugs / 9 commits, no Claude) is an outlier but belongs in the baseline — it is a release, and the distribution already captures it 3 · The Metric The analysis uses a single metric: bugs per 10 commits (bugs/10c). For each release, divide the number of bugs attributed to it by the number of commits in its range, then multiply by 10. This normalizes for release size. bugs/10c = (bug_count ÷ total_commits) × 10 How commits are assigned to releases Every commit on the default branch was ordered by committer date to produce a sequential timeline. Each git tag points to a specific commit in this timeline. A release's range is all commits between the previous tag and its own tag. Pre-release tags ("pre", "rc") are skipped as boundaries and absorbed into their final release. Every commit belongs to exactly one release. How bugs are found and assigned to releases Bug counts come from three sources: GitHub issues in the rsync repository (collated via the GitHub REST API), the rsync Bugzilla instance (collected via the API), and the rsync mailing lis