"Claude 쓰면 버그난다"는 직관에 통계로 반격한 첫 OSS 사례 — rsync p값 논쟁을 바이브코더가 읽는 법

핵심 요약 (TL;DR)

rsync 3.4.1 이후 Andrew Tridgell이 머지한 'tridge and claude' 커밋이 증분 백업을 깼다는 GitHub 항의("Please Do Not Vibe Fuck Up This Software")가 6/4 The Register로 번지자, 블로거 Alexis Purslane이 약 2,000건의 버그 리포트를 permutation test로 돌려 "Claude 릴리스의 버그율이 역대 베이스라인과 통계적으로 구별되지 않는다"고 6/5 분석을 공개했습니다. 메인 결과 p=0.46(permutation), 보조 Fisher's exact p=0.74. HN 237점·229댓글까지 갔어요. Tridge 본인은 "진짜 부담은 AI가 생성하는 CVE 리포트 폭주"라고 답했습니다. 바이브코더에게 이건 데이터로 반박할 무기 한 장이 생긴 사건입니다.

무슨 일이 있었나요

rsync는 1996년부터 Tridge(Andrew Tridgell, Samba·patch도 그가 만들었음)가 운영해온 백업·동기화 인프라입니다. 3.4.1 릴리스 이후 'tridge and claude'로 표시된 커밋 수십 건이 머지됐고, 일부 사용자가 증분 백업이 깨졌다며 GitHub에 강한 제목의 쓰레드를 올렸어요. 6/4 The Register가 이를 1면급으로 보도하면서 "OSS가 vibe coding으로 망하는 첫 사례"라는 프레임이 퍼졌습니다.

Purslane이 뭘 계산했나요

약 2,000건의 rsync 버그 리포트를 "버그 per 10 커밋"으로 정규화하고, "Claude가 들어간 릴리스 그룹"과 "역대 베이스라인 그룹"의 버그율 분포를 permutation test로 비교했습니다. 메인 결과는 p=0.46 — 차이가 통계적으로 의미 없습니다. 보조로 Fisher's exact test도 돌려 p=0.74를 얻었어요.

물론 댓글에서 통계학자들의 반박이 따라붙었습니다. "Claude 릴리스 표본이 2개뿐이라 검정력이 부족하다", "버그 심각도 가중치가 없다", "초기 릴리스에 미신고 LLM 커밋이 있을 수도 있다." 모두 합리적 지적입니다. 결론을 단정하기엔 이르지만, "바이브코딩이 버그를 늘렸다"는 직관 쪽이 입증 책임을 진다는 프레임이 바뀐 게 핵심이에요. 직관과 데이터가 같은 토론 테이블에 올라온 첫 사례라는 겁니다.

Tridge가 진짜 짚은 건 따로 있어요

Tridge는 The Register 인터뷰에서 두 가지를 말했습니다. 첫째, 자기는 Claude를 "grunt work"에 썼고 프레임워크는 본인이 설계했으며 결과 코드는 수동 리뷰했다. 둘째, 진짜 부담은 AI가 생성하는 CVE 리포트 폭주 — 짧은 시간에 많은 변경을 강제당하면서 회귀가 늘었다는 것.

이 두 번째 문장이 한국 메인테이너·시니어에게 더 중요합니다. "Claude가 버그를 만들었다"가 아니라 "AI 생산 CVE가 패치 압박을 만들었고, 그 압박이 변경량을 늘렸고, 변경량이 회귀를 늘렸다"는 인과 사슬. 같은 패턴이 한국 OSS·내부 인프라 팀에 곧 닥칠 가능성이 큽니다. 도구를 욕하는 건 쉽지만, 진짜 위험은 한 단계 위에 있어요.

한국 바이브코더가 이걸 어떻게 쓰면 되나요

세 가지로 정리됩니다.

1. 무근거 프레임을 데이터로 받아치기. "바이브코딩 쓰면 버그난다"는 말이 회의실에서 나오면, rsync HN 분석을 인용하세요. 직관과 데이터가 같은 무게로 다뤄지지 않게 만드는 것이 첫 단계입니다.

2. 진짜 위험을 진짜 위치로 옮기기. "AI 도구"가 아니라 "AI CVE 폭주 → 패치 압박 → 변경량 → 회귀"가 진짜 인과입니다. 보안 자동화 도입 시 메인테이너의 패치 큐를 어떻게 보호할지 함께 설계해야 합니다.

3. 본인 워크플로에 통계 흔적 남기기. Tridge처럼 "Claude는 grunt work, 프레임워크는 사람"이라는 분리를 commit 메시지·PR 본문에 명시적으로 적어두세요. 6개월 후 누군가 같은 통계 분석을 돌릴 때 당신의 데이터가 신호로 살아남습니다.

FAQ

Q. p=0.46이면 Claude가 버그를 늘리지 않았다는 뜻인가요?
A. 정확히는 "Claude 릴리스의 버그율이 역대 베이스라인과 통계적으로 구별되지 않는다"입니다. 표본 한계는 분명하지만, "늘렸다"는 주장 쪽이 입증 책임을 진다는 프레임 전환이 의미입니다.

Q. 그래도 증분 백업이 깨졌다는 사용자 보고는 사실이잖아요?
A. 사실입니다. 다만 Tridge는 그 use case를 "valid but unusual"이라 표현했고, 회귀 자체는 즉시 대응됐어요. 회귀 발생과 회귀율 증가는 다른 질문이라는 게 분석의 핵심입니다.

Q. 한국 OSS 메인테이너에게 가장 중요한 한 줄은요?
A. AI가 만든 CVE 리포트 폭주가 메인테이너의 패치 큐를 망가뜨립니다. 도구 사용 정책보다 패치 큐 보호 정책을 먼저 설계하세요.

소스: news.ycombinator.com/item?id=48411635, alexispurslane.github.io/rsync-analysis/, theregister.com 6/4 보도