Claude가 rsync의 버그를 증가시켰는가? 데이터 분석

TL;DR Highlight

rsync 프로젝트에 Claude AI가 도입된 이후 버그가 늘었다는 소셜 미디어 주장을 실제 데이터와 통계 분석으로 검증한 글로, 결론적으로 Claude 도입 후 릴리즈가 역사적 분포에서 유독 버그가 많다는 통계적 근거는 없었다.

Who Should Read

오픈소스 프로젝트에 AI 코딩 도구를 도입하려는 개발자, 또는 AI 생성 코드의 품질 문제를 객관적으로 판단하고 싶은 엔지니어.

Core Mechanics

2026년 5월, rsync 프로젝트가 Claude AI의 코드 기여를 사용했다는 사실이 알려지면서 소셜 미디어에서 논란이 폭발했다. 증거 없는 Mastodon 포스트 하나가 수천 개의 공유와 좋아요를 받았고, Hacker News에서도 81개 댓글이 달리며 'LLM은 안전하게 쓸 수 없다'는 분위기가 형성됐다.
논란의 정점은 GitHub에 올라온 'Please Do Not Vibe Fuck Up This Software'라는 이슈였다. 기술적 내용이나 실제 버그 리포트는 전혀 없었고, Mastodon 비판 포스트의 스크린샷 하나만 첨부됐지만 329개의 댓글이 쌓이며 일부 심각한 괴롭힘까지 발생했다.
저자는 이 주장을 검증하기 위해 Penn State 통계학 석사 학위를 가진 아내의 자문을 받아 분석 방법론을 설계했다. Claude 도입 이후 샘플 수가 적기 때문에 단순 회귀 분석보다는 '과거 분포에서 Claude 이후 릴리즈가 얼마나 이상치인가'를 보는 방식이 가장 적합하다는 조언을 따랐다.
분석 방법은 '10커밋당 심각도 가중 버그 수(severity-weighted bugs per 10 commits)'를 지표로 삼고, exact permutation test(데이터 순열을 무작위로 섞어 관찰된 결과가 우연인지 검증하는 통계 기법)를 사용했다.
분석 결과, Claude가 참여한 릴리즈들은 rsync의 역사적 릴리즈 분포 안에서 통계적으로 이상하게 버그가 많다고 볼 수 없었다. 즉, 데이터상으로 Claude 도입이 버그를 증가시켰다는 주장을 지지하는 근거가 없었다.
저자는 숫자 위변조나 AI 환각(hallucination) 문제를 원천 차단하기 위해, 보고서에 표시되는 모든 수치와 그래프를 Python 통계 분석 스크립트가 HTML에 직접 템플릿으로 삽입하는 방식을 사용했다. 전체 파이프라인을 처음부터 재실행할 수 있도록 GitHub에 공개했다.
데이터 수집, DB 구성, 통계 분석 스크립트는 GLM 5.1이 작성했고, 최초 보고서 산문도 AI가 썼다. 그러나 방법론, 지표 선택, 데이터 소스 결정은 전적으로 저자 본인이 했다. 이후 HN에서 반응이 거의 없자 산문 전체를 직접 다시 작성해 공개했다.
가장 버그가 많은 릴리즈는 Claude 커밋이 처음 등장하기 직전 릴리즈(2026년 1월)였다는 점이 흥미롭다. 이는 Claude 이전에도 이미 문제가 있었을 가능성, 혹은 그 릴리즈에 미공개 LLM 커밋이 포함됐을 가능성을 시사한다.

Evidence

실제로 문제가 된 Claude 작성 커밋 사례가 공유됐다. `if (!ptr)` 조건을 `if (!ptr || ptr == do_calloc)`으로 바꾸면서 모든 메모리 할당을 calloc으로 강제하는 버그가 슬쩍 끼어들었고, 이는 대용량·재귀 할당에서 성능 비용을 유발했다. 결국 리버트됐는데, 리버트 커밋 설명도 LLM이 쓴 것처럼 보인다는 댓글이 달렸다.
분석 방법론에 대한 구체적 비판이 있었다. 버그를 릴리즈에 귀속시키는 방식의 문제(마이너 버전 직후 나온 패치 릴리즈가 과도하게 많은 버그를 부담하게 됨), 최근 릴리즈일수록 버그 제보 시간이 짧아 실제보다 적게 보이는 편향 가능성이 지적됐다.
Claude 커밋이 고작 2개인데 통계적으로 의미 있는 결론을 낼 수 있냐는 의문이 제기됐다. 통계학 교과서에서는 최소 30개 이상의 데이터 포인트가 필요하다고 배웠는데 이 분석은 그 기준을 충족하지 못한다는 지적이었다.
보고서의 비판적 어조가 분석 신뢰성을 스스로 훼손한다는 의견이 있었다. 통계 방법론에 공을 들였음에도 불구하고, '멍청한 AI 혐오자들이 틀린 것' 같은 감정적 표현 때문에 강한 사전 편향이 느껴져 읽기를 멈췄다는 독자도 있었다.
AI 도구 사용에 대한 압박이 오히려 역효과를 낼 것이라는 관점도 공유됐다. 개발자들이 드라마를 피하기 위해 Claude 기여 표시(co-authored attribution)를 슬쩍 꺼버리는 방향으로 움직일 것이므로, 책임감 있는 AI 사용 공개를 오히려 억제하게 된다는 주장이었다.

How to Apply

AI 생성 코드가 포함된 프로젝트에서 품질 논란이 제기될 경우, 단순한 반박 대신 이 글처럼 '릴리즈별 버그 수를 역사적 분포와 비교하고 permutation test를 수행하는' 방식으로 데이터 기반 대응을 준비할 수 있다. 전체 파이프라인을 GitHub에 공개해 재현 가능성을 확보하면 신뢰도가 높아진다.
AI가 생성한 코드 리뷰 시, 이 글에서 언급된 malloc/calloc 사례처럼 '조건 분기를 단순화하다가 의미가 바뀌는' 패턴을 특히 주의 깊게 봐야 한다. LLM은 두 브랜치를 하나로 합치는 리팩터링에서 미묘한 로직 변경을 일으키는 경향이 있으므로, 메모리 관리나 성능에 영향을 주는 코드는 반드시 수동 검토를 추가하라.
오픈소스 프로젝트에 AI 도구를 도입할 때는 커밋에 AI 기여를 명시적으로 표시하되(co-author 태그 등), 이 글의 사례처럼 표시 자체가 논란의 빌미가 될 수 있음을 인지해야 한다. 도구 사용 공개 정책을 팀 또는 프로젝트 CONTRIBUTING 문서에 미리 명문화해두면 사후 대응보다 훨씬 수월하다.
보고서나 분석 결과에 AI가 수치를 직접 쓰게 하지 말고, 이 글처럼 스크립트가 계산한 값을 HTML/Markdown 템플릿에 자동 삽입하는 방식을 사용하면 AI 환각으로 인한 수치 오류 위험을 없앨 수 있다. 보고서의 신뢰성을 높이는 동시에 '숫자를 꾸몄다'는 비판도 원천 차단된다.

Code Example

snippet

# Claude가 만든 버그 사례 (rsync commit d046525)
# 원래 의도: ptr이 없으면 malloc, ptr이 do_calloc이면 calloc
# 버그: 두 조건을 OR로 합치면서 ptr이 있어도 calloc을 타게 됨

# 버그 있는 버전 (Claude 작성)
- if (!ptr)
-   ptr = malloc(num * size);
- else if (ptr == do_calloc)
+if (!ptr || ptr == do_calloc)
    ptr = calloc(num, size);

# 문제: ptr이 유효한 포인터이고 do_calloc이 아닐 때도
# 두 번째 브랜치(calloc)로 빠지지 않으므로 할당이 안 됨
# 반대로 ptr이 NULL이면 malloc 대신 calloc이 항상 호출됨
# → 대용량/재귀 할당에서 불필요한 zero-initialization 비용 발생

Terminology

exact permutation test데이터를 무작위로 수없이 섞어보면서 '우리가 관찰한 결과가 그냥 운으로 나올 확률이 얼마나 되나'를 계산하는 통계 기법. 샘플 수가 적을 때 정규분포 가정 없이 쓸 수 있어 유용하다.

severity-weighted bugs버그마다 심각도 점수를 곱해서 합산하는 방식. 단순 버그 개수를 세면 사소한 오타와 치명적 크래시가 같은 무게가 되는데, 이를 보정하기 위한 방법이다.

calloc vs malloc둘 다 메모리를 할당하는 C 함수인데, calloc은 할당한 메모리를 자동으로 0으로 초기화(zero-initialization)한다. malloc은 초기화 없이 빠르게 할당만 하므로 대용량 할당에서는 calloc보다 훨씬 빠르다.

co-authored attributionGit 커밋 메시지에 'Co-authored-by: Claude'처럼 AI 도구가 코드 생성에 기여했음을 명시하는 관행. 투명성을 높이지만 이 글처럼 논란의 소지가 되기도 한다.

hallucinationAI 언어 모델이 실제로 존재하지 않는 수치, 사실, 인용 등을 마치 사실인 것처럼 자신 있게 생성하는 현상. 보고서에 AI가 숫자를 직접 쓰면 이 문제가 생길 수 있다.

open-slopware blacklistAI 생성 코드(slop)를 포함한 오픈소스 프로젝트를 목록화해 경고하려는 커뮤니티 움직임. 사용을 꺼리는 사람들이 참고하도록 만들어졌다.