Claude가 rsync 버그를 늘렸다는 주장, 데이터로 까보니 애매했다

논란의 시작은 버그보다 분위기였음

• rsync가 Claude 도움을 받은 커밋을 포함한 뒤, 온라인에서는 “AI가 안정적인 도구를 망쳤다”는 식의 주장이 확 퍼짐

  • 시작점은 Mastodon의 근거 약한 상관관계 지적이었고, 이후 Hacker News와 GitHub 이슈로 번짐
  • GitHub에는 “Please Do Not Vibe Fuck Up This Software”라는 이슈까지 열렸고, 댓글은 350개 이상 달림
  • 문제는 그 이슈가 실제 버그 리포트나 재현 절차가 아니라, Claude 사용을 비난하는 스크린샷에서 출발했다는 점임

• 논쟁의 핵심 주장은 단순했음. “Claude가 들어간 rsync 릴리스는 예전보다 버그가 많아졌다”는 것

  • 특히 rsync처럼 오래되고 신뢰받는 도구에서 이 주장은 꽤 센 주장임
  • 백업, 배포, 파일 동기화에 쓰이는 도구라서 회귀 하나가 운영 자동화 전체에 영향을 줄 수 있음
  • 그래서 저자는 감정 싸움 대신 릴리스별 버그 데이터를 까보기로 함

분석 방식은 꽤 단순하지만 주장에 맞춰져 있음

• 저자는 릴리스 단위로 버그를 묶고, sev/10c라는 지표를 사용함

  • sev/10c는 커밋 10개당 심각도 가중 버그 수를 뜻함
  • 버그를 단순히 1개씩 세지 않고, 0100점 심각도 점수를 01로 정규화해서 합산함
  • “버튼 오타랑 보안 취약점이 같은 1건이면 이상하지 않냐”는 반론을 반영한 셈임

• 버그 데이터는 GitHub 이슈, Bugzilla, rsync 메일링 리스트에서 가져옴

  • GitHub 이슈와 메일링 리스트 버그는 신고 시점 직전에 나온 릴리스에 귀속함
  • Bugzilla는 각 항목의 Version 필드를 보고 해당 릴리스에 귀속함
  • 프리릴리스 태그나 릴리스 후보 태그는 최종 릴리스에 흡수해서 경계로 쓰지 않음

• 버그 심각도 평가는 Qwen 3 35B가 맡음

  • 모델은 “실제 사용자 영향도를 평가하는 시니어 신뢰성 엔지니어” 역할로 프롬프트를 받음
  • 각 버그의 제목과 본문 최대 3,000자를 보고 0~100 정수 점수를 출력함
  • 온도는 0으로 고정해서 같은 입력이면 같은 점수가 나오게 함
  • 기능 요청, 스팸, AI 논쟁성 빈 이슈처럼 심각도 0인 항목은 기본 버그 카운트에서 제외함

결과는 “Claude 릴리스가 튄다”와 거리가 멀었음

• Claude가 포함된 rsync 릴리스 2개는 역사적 분포에서 특이한 나쁜 값이 아니었음

  • v3.4.2는 실제 버그가 0개로 사분위 범위보다 살짝 아래였음
  • v3.4.3은 사분위 범위보다 살짝 위였지만, 나쁜 이상치라고 부를 정도는 아니었음
  • 둘을 합치면 하나는 낮고 하나는 높은 쪽이라, 전체적으로 중간권을 끼고 있는 모양임

• 정확 순열 검정에서도 “Claude 때문에 나빠졌다”는 가설은 힘을 못 얻음

  • 가능한 모든 릴리스 2개 조합을 비교해서, Claude 그룹만큼 나쁘거나 더 나쁜 조합이 얼마나 되는지 봄
  • 결과적으로 눈감고 릴리스 2개를 뽑아도 비슷하거나 더 나쁜 경우가 거의 절반 수준으로 나옴
  • 이 정도면 “Claude 릴리스가 유난히 버그가 많다”는 주장과는 거리가 있음

• Fisher 정확 검정으로도 같은 결론이 나옴

  • 질문을 바꿔서 “Claude 릴리스가 역사적 중앙값보다 나쁜 쪽에 더 자주 들어가나”를 봄
  • 하지만 표본이 Claude 릴리스 2개뿐이라 강한 예측 모델을 만들 수는 없음
  • 대신 “현재 관측된 두 릴리스만 놓고 보면 특별히 나쁘다는 증거가 없다” 정도는 말할 수 있음

오히려 더 흥미로운 건 코드 변경량과 버그 수의 관계임

• Claude 릴리스는 변경된 코드 라인 수가 역사적 릴리스보다 많이 늘었음

  • GitHub 비교 API로 연속 태그 사이의 추가와 삭제 라인을 계산함
  • 커밋 수 자체는 의미 있게 늘었다고 보기 어려웠고, 오히려 적은 편에 가까웠음
  • 하지만 변경 라인 수는 꽤 크게 증가함

• 그런데 코드 변경량이 늘었는데도 버그 수가 같이 폭증하지는 않았음

  • “Claude가 개발 속도를 올려서 릴리스당 총 버그가 늘었다”는 반론을 확인하려면 이 지점이 중요함
  • 더 많은 코드가 바뀌었는데 버그가 역사적 분포의 중간권이면, 적어도 단순한 “AI라서 품질 폭망” 그림은 안 맞음
  • 물론 커밋 수나 라인 수는 복잡도를 완벽히 설명하지 못하는 둔한 지표임

• v2.x와 v3.x 시대를 나눠 봐도 Claude가 튀지는 않음

  • 전체 역사 평균은 2.95 sev/10c였음
  • v2.x 릴리스 평균은 1.11 sev/10c, v3.x 릴리스 평균은 4.23 sev/10c로 차이가 큼
  • 그런데 Claude 릴리스는 v3.x 안에서도 중간권 또는 그보다 나은 쪽에 있었음
  • “최근 안정화된 시대와 비교해야 한다”는 반론은 오히려 반대로 깨지는 셈임

진짜 원인은 Claude 코딩보다 보안 작업 폭증에 가까움

• 글에서 제시하는 더 그럴듯한 설명은 “AI가 만든 코드”가 아니라 “AI가 만든 보안 제보 폭증”임

  • rsync는 최근 보안 이슈와 CVE 대응 때문에 공격 표면을 빠르게 고쳐야 했음
  • 그 과정에서 오래 숨어 있던 코딩 오류가 드러나거나, 기존 동작과 충돌하는 회귀가 생길 수 있음
  • 한 HN 댓글은 2007년부터 있던 코딩 오류가 보안 수정 과정에서 드러난 것 같다고 짚음

• Lobsters 쪽에서는 인과 사슬을 더 노골적으로 정리함

  • 대규모 언어 모델(LLM)이 보안 이슈를 더 많이 찾아냄
  • 알려진 보안 이슈가 늘어나면서 rsync 유지보수자는 평소보다 많은 변경을 해야 했음
  • 변경량이 늘면 회귀도 늘 수 있음
  • 이 경우 문제는 “Claude가 rsync 코드를 망침”이 아니라 “보안 유지보수 압력이 갑자기 커짐”에 가까움

• 저자가 특히 찌르는 부분은 온라인 분노의 비대칭임

  • rsync 역사상 가장 나쁜 릴리스는 Claude 도입 전이었다고 함
  • 그때는 AI를 탓할 대상이 없어서 GitHub 이슈 수백 개짜리 난리가 나지 않았음
  • 이번에는 Claude라는 보기 좋은 적이 있었고, 그래서 평범한 회귀도 배신 서사로 커졌다는 해석임

개발자 입장에서 가져갈 포인트

• 오픈소스에서 AI 사용을 비판하려면 “느낌”보다 결함 정의와 비교 기준이 먼저임

  • 어떤 단위로 볼지 정해야 함. 커밋인지, 릴리스인지, 사용자 신고인지, CVE인지가 다 다름
  • 단순 버그 개수보다 심각도 가중치를 넣는 게 더 나을 수 있음
  • AI가 포함된 릴리스만 보는 게 아니라 역사적 릴리스와 같은 기준으로 비교해야 함

• 동시에 이 분석도 완벽한 결론은 아님

  • 표본이 Claude 릴리스 2개뿐이라 장기적인 품질 영향을 말하기엔 부족함
  • 버그가 정확히 어떤 커밋에서 생겼는지 대부분 명확하지 않음
  • 라인 수나 커밋 수는 코드 복잡도, 리뷰 품질, 테스트 범위를 충분히 설명하지 못함

• 그래도 한 가지는 꽤 분명함. “AI가 들어갔으니 망했다”는 말은 데이터 없이 하기엔 너무 싼 주장임

  • 특히 유지보수자가 보안 제보 폭증, 사용자 압박, 레거시 코드 수정까지 동시에 떠안는 상황이면 더 그렇음
  • AI 코딩 도구의 위험을 진지하게 보려면, 반감보다 측정 가능한 품질 지표가 먼저 나와야 함

---

기술 맥락

• 이 글에서 중요한 선택은 버그를 커밋 단위가 아니라 릴리스 단위로 본 거예요. 사용자는 개별 커밋을 설치하는 게 아니라 릴리스를 받기 때문에, “Claude가 들어간 릴리스가 실제로 더 나빴나”를 보려면 릴리스 기준이 더 맞거든요.

• 심각도 가중 버그율을 쓴 이유도 꽤 현실적이에요. 단순 버그 개수만 세면 문서 오타, 기능 요청, 치명적인 데이터 손상 가능성이 같은 무게가 돼요. 그래서 0~100점 심각도를 붙이고 커밋 10개당 값으로 정규화해서 비교한 거예요.

• 정확 순열 검정과 Fisher 정확 검정은 “느낌상 나빠졌다”를 피하려는 장치예요. Claude 릴리스가 2개뿐이라 거창한 예측 모델은 못 만들지만, 최소한 역사적 분포 안에서 그 2개가 얼마나 특이한지는 확인할 수 있거든요.

• 유지보수 관점에서 더 큰 변수는 Claude 커밋 자체보다 보안 이슈 대응량이에요. AI로 보안 제보가 늘면 maintainer는 더 많은 코드를 더 빨리 바꿔야 하고, 레거시 프로젝트에서는 그 과정에서 오래된 가정이 깨지기 쉬워요.

• 그래서 이 사례는 “AI 코딩이 안전하다”보다 “AI 논쟁에서도 측정 단위를 먼저 정해야 한다”에 가까워요. 커밋, 릴리스, 변경 라인 수, 심각도, 사용자 영향 중 뭘 볼지 정하지 않으면 결국 좋아하는 결론에 맞춰 숫자를 고르게 되거든요.