---
title: "Claude가 rsync 버그를 늘렸다는 주장, 데이터로 까보니 애매했다"
published: 2026-06-05T12:43:33.000Z
canonical: https://jeff.news/article/3753
---
# Claude가 rsync 버그를 늘렸다는 주장, 데이터로 까보니 애매했다

rsync에 Claude가 들어간 뒤 버그가 늘었다는 온라인 논란을 실제 릴리스별 버그 데이터로 검증한 글이다. 결론은 꽤 차갑다. Claude가 포함된 두 릴리스는 역사적 분포에서 튀는 수준이 아니었고, 오히려 논란은 데이터보다 AI에 대한 분노에 더 가까웠다는 쪽이다.

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

- rsync가 Claude 도움을 받은 커밋을 포함한 뒤, 온라인에서는 “AI가 안정적인 도구를 망쳤다”는 식의 주장이 확 퍼짐
  - 시작점은 Mastodon의 근거 약한 상관관계 지적이었고, 이후 Hacker News와 GitHub 이슈로 번짐
  - GitHub에는 “Please Do Not Vibe Fuck Up This Software”라는 이슈까지 열렸고, 댓글은 350개 이상 달림
  - 문제는 그 이슈가 실제 버그 리포트나 재현 절차가 아니라, Claude 사용을 비난하는 스크린샷에서 출발했다는 점임

- 논쟁의 핵심 주장은 단순했음. “Claude가 들어간 rsync 릴리스는 예전보다 버그가 많아졌다”는 것
  - 특히 rsync처럼 오래되고 신뢰받는 도구에서 이 주장은 꽤 센 주장임
  - 백업, 배포, 파일 동기화에 쓰이는 도구라서 회귀 하나가 운영 자동화 전체에 영향을 줄 수 있음
  - 그래서 저자는 감정 싸움 대신 릴리스별 버그 데이터를 까보기로 함

> [!IMPORTANT]
> 이 글은 “Claude가 버그를 절대 만들지 않는다”는 주장이 아님. “이번 rsync 릴리스 2개가 통계적으로 유난히 나빴다는 증거가 있냐”를 따진 글임.

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

- 저자는 릴리스 단위로 버그를 묶고, `sev/10c`라는 지표를 사용함
  - `sev/10c`는 커밋 10개당 심각도 가중 버그 수를 뜻함
  - 버그를 단순히 1개씩 세지 않고, 0~100점 심각도 점수를 0~1로 정규화해서 합산함
  - “버튼 오타랑 보안 취약점이 같은 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개뿐이라 강한 예측 모델을 만들 수는 없음
  - 대신 “현재 관측된 두 릴리스만 놓고 보면 특별히 나쁘다는 증거가 없다” 정도는 말할 수 있음

> [!NOTE]
> 표본이 2개라서 미래 Claude 사용이 안전하다고 일반화할 수는 없음. 다만 “이미 rsync가 Claude 때문에 무너졌다”는 식의 단정도 데이터로는 버티기 어렵다는 얘기임.

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

- 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 논쟁에서도 측정 단위를 먼저 정해야 한다”에 가까워요. 커밋, 릴리스, 변경 라인 수, 심각도, 사용자 영향 중 뭘 볼지 정하지 않으면 결국 좋아하는 결론에 맞춰 숫자를 고르게 되거든요.

## 핵심 포인트

- Claude가 포함된 rsync 릴리스 2개는 심각도 가중 버그율 기준으로 역사적 분포의 중간권에 있었다
- 정확 순열 검정과 Fisher 정확 검정 모두 Claude 릴리스가 비정상적으로 버그가 많다는 근거를 보여주지 못했다
- 최근 변화의 진짜 원인은 Claude 자체보다 AI로 폭증한 보안 제보와 그에 따른 대규모 수정 작업에 가까웠다
- 온라인 논란은 기술적 버그 리포트보다 AI 사용에 대한 반감과 유지보수자 공격으로 번졌다

## 인사이트

이 글의 포인트는 Claude를 무조건 옹호하자는 게 아니라, 오픈소스에서 AI 사용을 비판하려면 최소한 릴리스 단위 데이터와 결함 정의부터 맞춰야 한다는 거다. 싫어하는 도구가 보였다고 모든 회귀를 거기에 꽂아버리면, 정작 유지보수 리스크는 안 보인다.