2026년 5월 말, rsync가 논란에 휩싸였습니다.

rsync는 1996년부터 사용되어 온 Unix의 파일 동기화 도구로, Linux의 패키지 매니저, 백업 시스템, CI/CD 파이프라인의 뒷받침으로서 인프라를 지탱해 온 소프트웨어입니다. 그 유지보수자가 Claude를 사용하여 코드를 작성하고 있다는 사실이 밝혀지면서 커뮤니티가 격분했습니다.

GitHub의 issue에는 「Please Do Not Vibe Fuck Up This Software」라는 제목이 붙었고, 329건의 댓글이 쏟아졌습니다. Mastodon의 포스트는 수천 개의 부스트를 모았으며, Hacker News에서도 수백 건의 댓글이 오갔습니다. 폭력을 암시하는 일러스트까지 게시되었습니다.

핵심 주장은 다음과 같았습니다. "Claude가 작성한 코드 때문에 안정적이었던 도구에 버그가 늘어났다."

하지만 이는 실증적으로 검증할 수 있는 주장입니다. 실제로 검증한 사람이 있습니다.

1. 검증의 전체상

저자인 alexispurslane은 rsync의 모든 릴리스 이력을 대상으로 버그 밀도(bug density)의 통계 분석을 수행하였고, 그 결과를 GitHub 리포지토리로 공개했습니다 (데이터, 스크립트, 분석 파이프라인 모두 재현 가능).

분석 방법론은 통계학 석사 학위를 가진 저자의 아내와 상담하여 설계되었습니다. 저자는 그 경위를 다음과 같이 기록했습니다.

"아내는 전후의 버그 밀도를 단순 비교해도 샘플 수가 너무 적어 노이즈에 묻힐 것이며, 같은 이유로 선형 회귀 (linear regression)도 작동하지 않을 것이라고 지적했습니다. Claude 릴리스가 역사적 분포의 어디에 위치하는지, 그리고 그 위치의 값을 역사적 분포에서 무작위로 얻을 확률이 얼마나 되는지를 보는 것이 할 수 있는 최선의 방법이라고 가르쳐 주었습니다."

사용 지표: severity-weighted bugs per 10 commits (sev/10c)

단순한 버그 건수가 아니라, 중요도(severity)로 가중치를 둔 버그 밀도를 사용합니다.

계산식: sev/10c = (Σ severity/100 ÷ total_commits) × 10

왜 가중치를 두는가? 버튼의 오타와 CVE (보안 취약점)를 동일한 1건으로 계산한다면 실태를 오판하게 됩니다.

중요도 점수 산정 방식

버그 보고는 모두 오픈 소스 소형 LLM (Qwen 3 35B)에게 "시니어 신뢰성 엔지니어 (SRE)"로서 평가하게 했습니다. 루브릭 (rubric):

데이터 소스

버그 보고는 3가지 소스에서 수집되었습니다.

• GitHub issues (REST API 경유)
• rsync Bugzilla (API 경유)
• rsync 메일링 리스트

커밋 귀속: 기본 브랜치의 모든 커밋을 커미터 날짜 순으로 정렬하여, 태그 사이의 커밋을 해당 릴리스에 할당. 프리릴리스 (pre-release) 태그는 최종 릴리스에 흡수.

2. 결과: Claude 릴리스는 통계적으로 이상하지 않다

기본 데이터

분석 대상은 버그 데이터가 있는 36개 릴리스 (v2.4.6 ~ v3.4.3)입니다. 그중 Claude의 커밋을 포함하는 것은 2개 릴리스뿐입니다.

비교를 위해 역사적 평균값은 2.95 sev/10c, 중앙값은 1.78 sev/10c입니다.

즉:

• v3.4.2는 역사적 평균보다 훨씬 낮음 (0.00)
• v3.4.3은 역사적 평균을 약간 상회함 (3.29)
• 2개의 Claude 릴리스는 사분위 범위 (IQR)의 반대 방향으로 움직임.
  한쪽은 좋고, 한쪽은 나쁨

둘 다 이상치 (outlier)는 아닙니다.

통계 검정 ①: 정밀 치환 검정 (exact permutation test)

36개 릴리스 중 임의의 2개를 선택했을 때, Claude 릴리스와 같거나 그보다 더 나쁜 점수가 나올 확률은?

p = 0.46 (46%)

즉, 무작위로 어떤 2개 릴리스를 선택하더라도 46%의 확률로 비슷한 수준의 나쁜 결과가 나옵니다. 이는 "Claude 릴리스가 특히 나쁘다"라는 주장을 전혀 뒷받침하지 않습니다.

통계 검정 ②: Fisher의 정확 검정 (Fisher's Exact Test)

Claude 릴리스가 역사적 중앙값보다 높은 위치에 있을 확률은 다른 릴리스와 비교했을 때 높은가?

p = 0.74 (74%), 오즈비 (Odds Ratio) = 1.06

오즈비 1.06은 "차이가 거의 없음"을 의미합니다. Claude 릴리스가 중앙값보다 높게 나타날 확률은 다른 릴리스와 실질적으로 동일합니다.

역사적 평균과의 비교

역사적 평균 sev/10c = 2.95

Claude 릴리스의 평균 sev/10c = 1.65

역사적 평균은 Claude 평균의 1.8배입니다. 즉, Claude 릴리스는 역사적으로 보았을 때 더 "나은" 쪽에 위치하고 있습니다.

3. 왜 "버그가 늘었다"고 느껴졌는가

통계적으로는 버그가 늘지 않았음에도 불구하고, 왜 커뮤니티는 "늘었다"고 확신했을까요? 저자의 분석과 다른 소스들을 통해 드러나는 구조가 있습니다.

이유 ①: 이상 징후가 있는 릴리스는 Claude 이전에 있었다

v3.4.1은 59개의 버그를 9개의 커밋으로 쏟아낸, 역사상 가장 밀도가 높은 릴리스 중 하나입니다. 하지만 이 릴리스에 Claude는 전혀 관여하지 않았습니다.

이유 ②: 인과관계의 오인

Lobsters의 사용자 jbert가 이 인과 연쇄를 정리했습니다.

"변경량의 증가(따라서 리그레션 (Regression)의 증가)를 촉발한 트리거는, (주로) LLM을 사용하여 발견된 대량의 보안 문제의 유입이었습니다. 인과관계는 다음과 같습니다: LLM → 더 많은 알려진 보안 문제 발견 → 평소보다 더 많은 변경 필요 → 평소보다 더 많은 리그레션."

rsync의 유지보수자인 Andrew Tridgell (Tridge) 본인도, AI가 생성한 CVE 리포트의 홍수에 대응하기 위해 급격하고 광범위한 변경이 불가피했다고 설명했습니다.

즉, 버그가 늘어난 것처럼 보인 원인은 "Claude가 코드를 작성했기 때문"이 아니라, "보안 수정의 급증으로 인해 변경량이 폭등했기 때문"입니다. Claude는 원인이 아니라, 같은 시기에 사용된 도구에 불과합니다.

이유 ③: 증거 없는 선험적 판단

저자는 이 현상의 본질을 꿰뚫고 있습니다.

"분노의 대상은 rsync가 지금 좋아졌느냐 나빠졌느냐가 아니라, 사람들이 AI를 싫어하며 실증적인 결과가 아닌 선험적인 정의로부터—원하는 결론을 향해 논하고 있다는 점에 있었습니다."

Lobsters의 한 댓글이 전형적인 사례입니다.

"저자가 이러한 보안 버그들을 수작업으로 다루며 기능을 유지하는 멘탈 모델 (Mental Model)을 유지했다면, 리그레션은 더 적었을 것이다."

이는 인과관계에 대한 주장일 뿐, 증거는 전혀 없습니다. 그리고 실제 데이터는 이 주장을 뒷받침하지 않습니다.

4. 보조 사례: AI가 "가정한 것"을 확인하기

rsync 사건은 "AI의 코드에 버그가 많은가"를 통계로 검증한 이야기지만, 한 가지 더 짚고 넘어가야 할 관점이 있습니다. AI 코드의 버그는 어디에 숨어 있는가 하는 점입니다.

개발자 Harsh가 2026년 6월 Dev.to에 게시한 글 「The Bug That Took 10 Minutes to Fix and 3 Days to Find」는 이 질문에 대한 구체적인 답변입니다.

무슨 일이 일어났는가

AI에게 리스트를 처리하는 함수를 작성하게 했습니다. 프롬프트는 명확했고, 출력은 깔끔했으며, 테스트를 통과했고, PR (Pull Request)도 리뷰를 통과했습니다. 화요일에 배포되었습니다.

목요일, 빈 리스트를 가진 사용자가 엔드포인트에 접속했습니다. 함수는 빈 리스트를 받아 처리한 뒤, 아무것도 반환하지 않았습니다. 에러도 아니고 빈 리스트도 아닌, 침묵이었습니다. UI는 프리징 (Freezing)되었습니다.

왜 3일이나 걸렸는가

저자는 3일 동안 로그, 프레임워크, 데이터베이스, 네트워크, 그리고 코드 자체를 의심했습니다. 로그에는 에러가 없었고, 로컬에서는 테스트 데이터(즉, 비어 있지 않은 리스트)로 작동하기 때문에 재현되지 않았습니다.

3일째 아침, 마침내 "입력이 비어 있다면 어떻게 될까?"라는 질문에 도달했습니다.

헬퍼 함수 (Helper Function)는 리스트에 최소 하나 이상의 요소가 있다는 것을 전제로 작성되어 있었습니다. 비어 있는 경우, 예외(Exception)도 경고도 내지 않고 조용히 아무것도 반환하지 않았던 것입니다.

수정은 단 한 줄이었습니다:

if not items:
    return []

교훈: AI가 "무엇을 썼는가"가 아니라 "무엇을 가정했는가"

저자의 결론은 명쾌합니다.

「AI는 리스트가 비어 있지 않을 것이라고 가정했습니다. 학습 데이터의 대부분의 예시에서 리스트에 아이템이 있었기 때문입니다. 저는 AI가 에지 케이스 (Edge Case)를 처리하고 있다고 가정했습니다. 코드가 완벽해 보였기 때문입니다. 두 가정 모두 그 자체로는 틀리지 않았습니다. 단지 검증되지 않았을 뿐입니다. 검증되지 않은 가정은 이자가 붙어 돌아오는 부채입니다.」

그리고 실천적인 규칙:

「모든 함수에 대해, 배포하기 전에 스스로에게 물어보세요. 『이것이 아무것도 받지 않는다면 어떻게 될까?』. 이 질문은 30초면 물어보고 답할 수 있습니다. 그랬다면 3일을 아꼈을 것입니다.」

이 사례가 rsync 사건과 연결되는 지점은 리뷰의 초점입니다. rsync 커뮤니티는 「Claude가 작성한 코드인가, 인간이 작성한 코드인가」를 문제 삼았지만, 이는 생산적인 질문이 아닙니다. 생산적인 질문은 「이 코드는 무엇을 가정하고 있는가, 그 가정은 검증되었는가」입니다.

이 질문은 코드를 작성한 것이 AI든 인간이든 동일하게 유효합니다.

5. 지표 없는 논쟁은 감정에 매몰된다

rsync 사건에서 이끌어낼 수 있는 가장 중요한 구조는 기술적인 이야기가 아니라, 조직과 업계가 AI 코드를 어떻게 평가해야 하는가에 대한 이야기입니다.

현재의 디폴트: 「누가 작성했는가」로 판단하기

rsync 사건의 커뮤니티 반응은 전형적이었습니다. Git의 blame이나 GitHub의 커밋 메시지에서 「Claude」라는 글자를 발견하고, 해당 릴리스에서 발생한 모든 버그를 Claude의 탓으로 돌립니다. 이전후 릴리스와의 비교도 없고, 버그의 심각도 구분도 없으며, 변경량과의 상관관계도 보지 않습니다.

이 판단 방식은 편안할 정도로 단순하지만, 데이터에 기반하고 있지 않습니다.

지향해야 할 모습: 「품질이 어떻게 변했는가」로 판단하기

alexispurslane의 분석이 보여준 것은 올바른 질문을 던지는 방법입니다.

지표를 정의한다: sev/10c와 같이 심각도로 가중치를 둔 버그 밀도 -
베이스라인을 구축한다: 동일 프로젝트의 역사적 분포 -
통계 검정으로 비교한다: 치환 검정 (Permutation Test), 피셔의 정확 검정 (Fisher's Exact Test) -
결론을 신중하게 기술한다: 「이상하지 않다」가 「좋다」와 동일한 것은 아니다

이 방법이 완벽하지는 않습니다. 샘플 수가 2개(Claude 릴리스가 2개뿐임)라는 점은 통계적으로 취약합니다. 저자 자신도 이를 인정하고 있습니다. 하지만 「증거 없이 결론을 내리는 것」보다 「한정된 데이터로부터 신중하게 추론하는 것」이 훨씬 생산적입니다.

툴체인 (Toolchain)에 요구되는 것

앞으로 성숙한 팀이 물어야 할 것은 「이 코드는 AI가 작성했는가?」가 아니라, 다음 세 가지입니다.

결함률이 변화했는가: AI 도입 전후로 심각도 가중 버그 밀도가 어떻게 움직였는가 -
회귀율 (Regression Rate)이 변화했는가: 기존 기능이 망가지는 빈도가 늘었는가 줄었는가 -
롤백률 (Rollback Rate)이 변화했는가: 배포 후 되돌리는 빈도는 어떠한가

이러한 지표를 자동으로 대시보드화하는 툴은 2026년 시점에서도 아직 일반적이지 않습니다. 하지만 rsync 사건이 보여준 것은, 지표 (Metrics)의 부재가 논의의 품질을 결정적으로 떨어뜨린다는 점입니다.

지표가 있다면 「Claude의 코드는 버그가 많다」라는 주장은 검증 가능한 가설이 됩니다. 지표가 없다면 그것은 감정적인 신념에 머물며, 329개의 댓글과 폭력적인 일러스트를 양산할 뿐입니다.

툴체인이 증거를 제시하지 못하면 여론이 증거를 보충하려 합니다. 여론이 보충하는 증거는 대개 정확하지 않습니다.

요약

rsync 사건은 AI 코드 품질 문제의 가장 좋은 케이스 스터디입니다. 왜냐하면 데이터가 있기 때문입니다.

36개 릴리스, 3개의 데이터 소스, 심각도 가중 버그 밀도, 치환 검정과 피셔의 정확 검정. 결론은 「Claude 릴리스는 통계적으로 이상하지 않다」── p = 0.46은 「46%의 확률로 무작위로 동일한 결과가 나온다」를 의미하며, 차이가 없다는 강력한 증거입니다.

하지만 rsync 사건의 진정한 교훈은 통계 결과가 아닙니다.

지표가 없는 곳에서 AI 코드의 품질을 논하면, 논쟁은 감정에 지배당한다. 지표가 있다면 주장은 가설로 변하며 검증 가능해집니다. 검증 불가능한 주장은 아무리 목소리가 커도 엔지니어링의 판단 근거가 될 수 없습니다.

한편, 「The Bug That Took 3 Days to Find (찾는 데 3일이 걸린 버그)」가 보여준 것은 지표만으로는 부족하다는 점입니다. 통계는 "전체적으로 늘어나지 않았다"는 사실을 알려주지만, 개별적인 버그를 막아주지는 않습니다. 버그를 막는 것은 "이 코드는 무엇을 가정하고 있는가"라고 질문하는 습관입니다.

AI가 작성한 코드가 늘어날수록, 이 두 가지──매크로(Macro) 지표와 미クロ(Micro)적인 "가정의 확인"──모두가 필요해집니다.

본 기사는 AI 워치 "AI Code Review" 시리즈 총 4편 중 제3편입니다. 다음 편에서는 "Agent 시대의 Diff는 부족하다"──Code Review 기반이 재구축되는 이유를 전달해 드립니다.

출처

• alexispurslane 「Did Claude increase bugs in rsync?」 2026-06 (저자의 분석. 방법론은 저자의 아내〈통계학 석사·Penn State〉와의 상담을 통해 설계. 데이터 및 스크립트는 GitHub 리포지토리에서 완전히 재현 가능)
• rsync GitHub issue 「Please Do Not Vibe Fuck Up This Software」 2026-05-30 (329개 댓글)
• 개원중국(开源中国) 「rsync 유지 관리자를 위한 AI 코드 작성으로 커뮤니티 분노 유발」 2026-06-01
• Andrew Tridgell (rsync 유지 관리자)의 Medium 기사에 대한 답변 (Lobsters 경유)
• Harsh 「The Bug That Took 10 Minutes to Fix and 3 Days to Find」 Dev.to, 2026-06-03

Discussion