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

 (alexispurslane.github.io)
1P by GN⁺ | ★ favorite | 댓글 1개
  • 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점을 받은 이슈는 기본 버그 수에서 제외함

Claude 릴리스의 통계 결과

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

논의된 교란 요인

  • Hacker News의 한 사용자는 CVE 대응 보안 수정이 2007년부터 코드에 있던 코딩 오류를 드러낸 것으로 보인다고 봄
  • Lobsters의 한 사용자는 “LLM → 알려진 보안 이슈 증가 → 평소보다 많은 변경 필요 → 평소보다 많은 회귀”라는 인과 사슬을 제시함
  • Andrew Tridgell은 AI 생성 CVE 보고서 홍수가 rsync의 공격 표면에 빠르고 광범위한 변경을 요구했다고 설명함
  • 이 교란 요인까지 포함하면 문제는 Claude 자체라기보다 더 많은 보안 작업과 그에 따른 변경량 증가라는 쪽에 가까움

함께 보면 좋은 글 β

GN⁺   [-]
Lobste.rs 의견들

  • 앞으로 바이브 코딩으로 진행될 FOSS 프로젝트를 계속 쓸지 말지는 각자 판단할 수 있다고 봄. 다만 관리자가 바이브 코딩 도구로 전환한 뒤 커뮤니티가 보인 분노는 꽤 놀라웠고, 글에 나온 실증 데이터는 적어도 그 관행 변화의 영향을 더 잘 맥락화해 줌
    관리자가 이 코딩 방식을 채택하면서 신뢰가 유지될지 더 무너질지는 시간이 지나야 알 수 있음

    • 이 전환에 화낸 사람들 중 실제로 rsync에 의미 있게 기여했거나 돈을 낸 사람이 얼마나 되는지 궁금함

  • 이 분석은 내가 바라던 바로 그 내용이었고 그 이상이었음. 특히 “모든 지표, 방법론, 데이터 출처는 Penn State University 통계학 석사인 아내와 상의해 내가 직접 골랐다”는 부분이 좋았고, 실제 통계 전문가를 참여시킨 점과 읽기 쉬운 글로 만든 점이 훌륭함
    “커밋 10개당 버그 수”라는 단일 지표를 썼다는데, SI 접두어를 써서 커밋당 데시버그(decibugs)라고 부를 기회를 놓친 듯함

    • 동의함. 내 글은 아니지만, 누군가가 과열된 찬반을 넘어 코드 품질에 미친 영향을 데이터로 보여준 점이 좋았음

  • 오픈소스 프로젝트의 성공은 인식에 너무 크게 좌우돼서 사람들이 GitHub 스타를 돈 주고 사기도 함. 안타깝게도 이번 인식 문제는 통제를 벗어나 하나의 논점이 됐고, 어떤 데이터도 그걸 바꾸기 어려움
    앞으로 “rsync 관리자가 LLM을 썼더니 망가졌다”는 말은 “데이터센터가 하루에 깨끗한 물 50만 갤런을 낭비한다”, “METR 연구가 LLM이 생산성을 떨어뜨린다고 했다” 같은 논점과 함께 AI 회의론자들이 꺼내 들게 될 것임
    내가 AI 회의론자인지 여부를 말하려는 건 아니고, 이 주제의 논쟁이 보통 이런 식으로 흘러간다는 점을 말하는 것임

    • 그게 왜 “논점”이지, 그냥 사실 아닌가?
    • 글쓴이가 데이터로 누군가를 설득하려는지는 모르겠음. 이 글은 rsync의 도구 채택을 둘러싼 매운 논쟁에 데이터 맥락을 붙인 것으로 봄
      다만 글에서 다른 비정량적 요소들이 완전히 빠졌다는 말은 맞고, 전도사와 회의론자 양쪽의 소음이 이미 충분해서 일부러 그랬을 것 같음

  • rsync 역사상 최악의 릴리스는 Claude 도입 전이었고, 커밋 10개당 버그가 39.39개였다는 부분이 매우 중요하고 예상 가능한 결론임
    사용자와 개발자 사이에 테스트, 품질보증 같은 프로세스가 소프트웨어의 정확성을 보장하지 못하면 LLM이 있든 없든 버그를 배포하게 됨. LLM은 이 과정에 해가 될 수도 있고 도움이 될 수도 있음

    • 동의함. cURL의 최근 글은 그 반대편 사례를 보여주는 듯함
      이미 수년간 자리 잡은 강한 소프트웨어 공학 관행 덕분에 비슷한 AI 도구로 버그를 찾는 가치가 전반적으로 낮아졌음
    • rsync의 미래에 대해 몇 가지 우려가 있음. 가장 큰 문제는 rsync가 사실상 몇 년간 완성된 프로젝트였는데, AI를 쓰면서 기존 테스트 코드를 뜯어내고 Python 테스트 스위트로 바꿨으며, 상당 기간 기존 테스트를 병행해 정확성을 검증하지 않았다는 점임
      내 기준으로는 무책임함. 특히 rsync의 주된 목적은 소중한 데이터를 옮기는 것이고, 그 데이터의 무결성은 절대적으로 중요함

  • “AI 반대 사용자에게 전형적이듯 결국 폭력 판타지로 escalated됐다” 같은 수사는 피했으면 함. 글쓴이가 동의하지 않는 일부 사람들을 일반화할 뿐 아니라, 원래 동의하지 않는 독자에게도 반감을 사서 정작 가장 읽어야 할 사람들이 글을 보지 않게 됨
    별개로, 이전 버전보다 버그가 많든 적든 나는 별로 상관하지 않음. 내가 중요하게 보는 건 내가 생각하는 소프트웨어 개발 방식과 맞지 않는 방식으로 개발된다는 점임. 효율성 말고도 문제가 있다는 기본 이해가 없다면 이 입장이 합리적이라고 설득할 기대는 없음
    다행히 원치 않으면 이 버전의 rsync를 쓰지 않아도 되고, LLM 사용 이전에서 갈라진 대안을 고를 것임

    • 이 글은 너무 화가 많이 담겨 있어서 오래 읽지 못하고 포기했음. 공정하려고 했거나 적어도 그렇게 보였으면 더 나았을 듯함
      이미 오래전에 반박된 밈, 즉 첫 번째 버그 리포트가 사람들이 몰려든 이슈였다는 얘기를 반복한 것도 도움이 안 됐음. 실제 첫 버그 리포트는 따로 있었음

  • 지금 글이 솔직히 더 낫다고 봄. 다만 “이 지표는 커밋 복잡도, 보안 민감도, 버그 심각도를 통제하지 못한다. 한 줄짜리 오타 수정과 CVE 패치를 구분하지 못하는 둔한 도구다”라는 부분은, LLM은 나쁘다 쪽에 있는 내 입장에서는 핵심 비판을 놓치는 것임
    나와 다른 사람들이 제기하는 비판은 AI가 더 크고 쉽게 이해하기 어려우며 복잡도를 늘리는 커밋을 쏟아내게 만든다는 것임. LLM 지지자들도 비슷한 말을 하다가, 수십 년간 검증된 “PR 읽기” 관행에서 “LLM이 모든 걸 테스트할 수 있어야 한다”로 골대를 옮기곤 함. 하지만 코드 복잡도가 기술 부채라는 문제는 사라지지 않음
    이번 경우 버그 심각도는 매우 높음. 백업 워크플로가 실제로 깨졌기 때문임. rsync는 백업에 널리 쓰이고, 사람들은 패치 업데이트로 백업 스크립트가 깨질 가능성은 상상조차 하지 않을 만큼 “전투 검증된” 도구로 신뢰해 왔음
    LLM이 버그 있는 소프트웨어를 만든 게 우연이었다거나, 관리자가 LLM 작업 흐름을 바꾸고 테스트 커버리지를 높여야 한다고 말할 수는 있음. 실제로 관리자도 그렇게 말했음. 하지만 분노의 핵심은 이 도구가 그 신뢰를 깼다는 데 있음
    실제로 요즘 “코드를 전혀 읽지 않는다”고 말하는 새 부류의 LLM 프로그래머들이 있음. 읽는 데 시간이 너무 오래 걸리고 일반 프로그래머 코드보다 파악하기 복잡하다는 이유임. 코드를 읽는다는 건 다른 사람의 정신 모델을 배우는 일인데, LLM 도구는 하나의 일관된 정신 모델을 제공하지 못함
    별개로 사이트 접근성도 확인해야 함. 시력이 꽤 좋고 20대 후반인데도 크림색/노란색 배경 위의 밝은 회색 글자는 읽기 정말 고통스러움

    • 인용한 부분이 헷갈림. 글에서 쓴 지표는 커밋 10개당 버그 수에 심각도 가중치를 준 것처럼 보이는데, 글쓴이가 자기 자신과 모순되는 건가? 내가 잘못 읽은 건가?
    • 워크플로가 깨졌다는 사람들에게는 오픈소스 소프트웨어와 GPL 라이선스가 무엇인지, 어떤 보장을 주는지 배우기 좋은 기회라고 봄
      사람들이 직접 그 버그를 발견했을 것 같지는 않음. rsync 사용자 90% 이상은 그 버그가 없는 이전 버전을 쓰고 있을 거라고 추측함. 나도 그중 하나임 
      $ uname -a  
Darwin riemann.local 25.3.0 Darwin Kernel Version 25.3.0: Wed Jan 28 20:53:31 PST 2026; root:xnu-12377.91.3~2/RELEASE_ARM64_T8103 arm64

$ port info rsync  
rsync @3.4.1 (net)  
[...]
      관심을 끈 이유라면, 지금 커뮤니티 상당 부분이 혼란에 빠져 있다는 점은 Steven Pinker가 아니어도 이해할 수 있음. LLM이 인간보다 프로그래밍을 더 잘한다는 사실은 받아들이기 쉽지 않음
      자신의 정체성과 자존감을 프로그래밍 능력이나 직업에 두었던 사람들은 미래 생계/시장 가치의 불확실성과 정체성 위기라는 두 가지 위기를 맞고 있음
      공포, 불확실성, 의심은 다루기 어렵고 LLM 회사들은 주가를 올리기 위해 그 효과를 증폭하는 데 최선을 다하고 있음. 10월 이후 시장이 급격히 조정되면 이런 증폭 장치도 약해질 수 있다고 봄
      전 세계 프로그래머 중 아주 작은 비율, 즉 코드를 예술 형식으로 보는 사람들은 아마 LLM을 훈련과 실력 향상에 사용할 것임

  • 이 글은 회귀를 언급한 댓글을 많이 인용하지만, 분석 자체는 회귀가 아니라 버그 리포트만 측정함. 버그가 도입된 릴리스가 아니라 보고된 릴리스에 버그를 연결하고, 릴리스의 심각도는 커밋 수로 재면서 릴리스 기간이나 배포판 채택 같은 명확한 요인은 빼고 있음
    이게 어떻게 말이 되는지 모르겠음

  • 개인적으로는 LLM을 쓰는 프로젝트를 피함. 실질적인 이유가 있어서라기보다 그냥 매우 꺼림칙하기 때문이고, 누군가 “kek”나 “fren” 같은 말을 쓰면 별 이유 없이도 더는 상호작용하고 싶지 않다는 신호로 받아들이는 것과 비슷함
    지금 LLM 사용을 싫어하는 이유로 나오는 설명들은 거꾸로 붙인 합리화처럼 느껴짐. 윤리, 품질 같은 현재의 우려는 맞지만, 그런 문제가 해결된다고 해서 나 같은 AI 반대 성향 사람들이 갑자기 괜찮아질 것 같지는 않음
    그래서 “AGENTS.md”, Claude 공동 작성 커밋 등이 있는 프로젝트는 구체적 이유 없이 피함. 그냥 불쾌하고 취향에 안 맞으며, 버그가 있든 없든 상관없음. 다른 사람들도 비슷하게 느끼는 경우가 있을 것 같음

  • 글쓴이에게 말하자면, 첫째로 판타지는 말임. 실제로는 말에서 멈췄다고 주장하는 셈이거나, 적어도 비언어적 확대가 있었다고 주장하지는 않는 것임
    둘째로 이런 주장을 하려면 가까운 통계 전문가에게 어떻게 뒷받침할 수 있는지 물어봐야 함. 몇 사람이 그런 글을 올렸다는 것만으로 그것이 “전형적”이라는 주장을 의미 있게 뒷받침하지 못함
    내가 통계로 뒷받침하지 않은 일화적 관찰로는, “AI 반대” 사용자들은 LLM이 도움이 안 되는 곳에 끼어드는 것을 대체로 폭력적으로 느끼기보다 슬퍼하는 쪽에 가까움

    • 가끔 매우 장황하고 자세한 글로 LLM 반대자 중 일부, 보통 LLM에 감정적·사회적으로 반응하는 일부를 반박하는 글을 봄. 그런 글은 이유를 명확히 설명하긴 어렵지만 매우 불성실하게 느껴지고, 약자를 때리는 느낌이 있음
      너무 자세해서 감정적 관점에서 반박하기 어렵고, 결국 “LLM이 문제가 아니라 제대로 쓰면 증폭 장치가 된다. AI 반대자들은 뭘 모르는 것이고 뒤처질까 봐 겁먹었을 뿐이다”로 끝나는 듯함
      rsync 관리자들의 작업을 논쟁으로 깎아내리고 싶지도 않아서, 내가 어떻게 설득력 있는 반론을 만들 수 있을지 모르겠음
      여기 통계는 오픈소스 유지보수 관점에서 흥미로울 수 있지만 결론이 이상하게 한쪽으로 기울어져 있고, GitHub식 오픈소스가 내가 기여하고 싶은 형태가 아니라는 느낌이 남음
      그래도 rsync 저장소에서 관리자에게 집단으로 몰려든 건 전혀 좋지 않다고 봄
    • 공개적인 폭력 판타지를 괜찮지 않다고 부르는 건 맞음. 그런 건 문명으로서 지향할 만한 일이 아님. 다만 글쓴이가 그걸 “전형적”이라고 부른 부분은 일반화라서 거슬림
      일화적 관찰에 관해서는 이 만화가 맞는 말 같음. 구체적이고 측정 가능한 주장을 보는 걸 좋아하는데, 숫자를 좋아해서이기도 하고 온라인 토론이 마지막 컷의 이상적 세계에 조금이라도 가까워지도록 만들기 때문임

  • 분석은 고맙지만 방법론에는 확신이 안 듦. 커밋마다 핵심 코드, 즉 테스트나 문서가 아닌 코드의 변경 줄 수를 곱한 차이 단위 버그 수 같은 지표와, 릴리스 후 특정 버그 수에 도달하는 데 걸리는 시간 분석이 궁금함
    다만 이번 릴리스가 다른 릴리스보다 훨씬 많은 관심을 받아 버그가 더 많이 보고됐을 가능성이 높기 때문에, 아주 설득력 있는 지표를 만들기는 어려워 보임. “릴리스 후 몇 주 기준으로 전형적인가?” 같은 질문도 별로 유용하지 않을 수 있음

답변달기
GeekBots 가 이제 오픈소스 기반 사내 협업도구 Mattermost 도 지원합니다. 긱뉴스를 사용중인 팀 채널에서 받아보세요.