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

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

# 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

관련 논문

• 취약한 앱을 직접 만들고 LLM이 해킹할 수 있는지 $1,500 써서 실험해봤다

  Firebase 취약점을 가진 앱을 직접 제작하고 GPT-5.5, Claude, Deepseek 등 주요 LLM이 자율적으로 해킹할 수 있는지 실험한 결과, GPT-5.5가 70% 성공률로 압도적이었고 Claude는 보안 거부 정책 때문에 능력과 무관하게 낮은 점수를 기록했다.

• Clustered Self-Assessment: LLM 불확실성 정량화를 위한 간단하고 효과적인 방법

  LLM이 여러 답변을 의미 단위로 묶어 객관식으로 만들고 스스로 채점해서 '이 답 얼마나 확신해?'를 수치로 뽑아내는 기법.

• SkillHarm: 자동 생성 기반의 Skill-Use Lifecycle 전반을 다루는 Agent Skill 공격 벤치마크

  AI 에이전트가 사용하는 'Skill 패키지'에 악성 페이로드를 심으면 최신 모델도 86%까지 뚫린다는 보안 벤치마크.

• MemTrace: LLM Memory System의 오류를 추적하고 원인을 찾아내는 프레임워크

  RAG, Mem0 같은 LLM 메모리 시스템이 왜 틀린 답을 내는지 자동으로 찾아주는 디버깅 프레임워크

• DeepSWE: 오염 없는 장기 코딩 에이전트 벤치마크

  기존 SWE-bench의 데이터 오염 및 검증 오류 문제를 해결하기 위해 처음부터 새로 만든 코딩 에이전트 벤치마크로, GPT-5.5가 70%로 1위를 차지하고 모델 간 성능 격차가 훨씬 뚜렷하게 드러난다.

• Constraint Decay: LLM 에이전트가 백엔드 코드 생성에서 구조적 제약을 못 따라가는 이유

  LLM 코딩 에이전트는 구조적 제약(아키텍처 패턴, ORM, DB 설계)이 쌓일수록 성능이 급격히 떨어지는 'constraint decay' 현상을 보인다는 연구 결과로, AI 코딩 도구를 프로덕션에 쓰려는 개발자라면 반드시 알아야 할 한계다.

• AMEL: 대화 히스토리가 LLM 판단에 미치는 누적 편향 효과

Related Resources

• 원문: Did Claude Increase Bugs in rsync?
• 분석 GitHub 저장소 (전체 파이프라인 공개)
• rsync 문제가 된 Claude 커밋
• 해당 커밋 리버트
• rsync 기여자 그래프