Claude가 rsync 유지보수를 도왔지만 버그는 증가했다 — 데이터가 보여주는 결과

한 개발자가 최근 29년 동안의 rsync 릴리스(releases)를 대상으로 순열 검정 (permutation test)을 수행했습니다. 질문은 간단했습니다: Claude의 지원을 받는 개발이 시작된 이후 버그 밀도 (bug density)가 증가했는가?

답은 '예'입니다. 그리고 이는 통계적으로 유의미합니다.

무슨 일이 일어났는지, 데이터가 실제로 무엇을 보여주는지, 그리고 진짜 교훈이 "AI는 나쁘다"가 아니라 "우리의 워크플로우 (workflows)가 따라가지 못하고 있다"인 이유를 설명하겠습니다.

설정 (The Setup)

rsync는 29년 된 C 언어 코드베이스 (codebase)입니다. 실전에서 검증되었으며, 어디에서나 사용됩니다. 소수의 팀에 의해 유지보수되며, 때로는 한 번에 한 명만이 담당하기도 합니다.

코딩 어시스턴트 (coding assistant)로 Claude가 도입되었을 때, 팀은 생산성 향상을 경험했습니다. 더 많은 변경 사항이 더 빠르게 반영되었습니다. 하지만 버그 프로필 (bug profile) 또한 변했습니다.

분석에는 심각도 가중치가 적용된 '10개 커밋당 버그 수 (bugs-per-10-commits)' 지표가 사용되었습니다. 모든 릴리스를 도표로 나타냈으며, 그 후 Claude 도입 이후의 릴리스들을 과거의 분포 (distribution)와 비교했습니다.

그 결과가 어디에 위치하는지가 중요합니다.

방법론 (The Methodology)

저자는 이를 구축하기 위해 며칠을 보냈습니다. 단순히 "ChatGPT에 물어봤다" 식의 가벼운 의견이 아닙니다. 제대로 된 통계 파이프라인 (statistical pipeline)입니다:

• 모든 릴리스의 데이터를 수집하기 위한 DuckDB 사용
• 정확한 순열 검정 (permutation test) 수행 (모수적 근사 (parametric approximation)가 아님)
• 심각도 가중치 적용 버그 점수 산정
• 엔드 투 엔드 (end to end) 재현 가능 — 전체 파이프라인이 GitHub에 공개됨

방법론은 코드를 작성하기 전에 통계학자의 검토를 거쳤습니다. 최종 보고서의 모든 숫자는 Python 분석 스크립트에서 자동 템플릿화되었습니다. 숫자 자체에 대한 환각 (hallucination) 위험은 제로입니다.

분포가 보여주는 것 (What the Distribution Shows)

Claude 도입 이후의 릴리스들은 과거의 분포 범위를 벗어납니다. 적은 차이가 아닙니다. 순열 검정은 이를 명확하게 나타냅니다.

이것이 Claude가 "나쁜 코드를 작성했다"는 의미에서 버그를 유발했다는 뜻은 아닙니다. 데이터는 그 이유를 말해줄 수 없습니다. 데이터가 보여주는 것은 릴리스 프로필 (release profile)의 변화입니다.

제 생각은 이렇습니다: 개발 속도를 가속화하면 리뷰 역학 (review dynamics)이 변합니다. 유지보수자 (maintainer)는 AI가 코드의 일부를 작성했다는 것을 알 때 다르게 리뷰합니다. 그들은 AI의 결과물을 다르게 신뢰합니다. 리듬 (cadence)이 변합니다. 그리고 리듬이 변하면 결함 프로필 (defect profile) 또한 변합니다.

이것이 실제로 의미하는 것

AI 코딩 어시스턴트 (AI coding assistants)를 사용하는 엔지니어링 팀을 위한 세 가지 시사점입니다:

1. 리뷰 관행이 적응해야 합니다 — 기존의 코드 리뷰 (code review) 프로세스는 사람이 작성한 코드를 위해 설계되었습니다. 이는 특정한 실수 패턴을 가정합니다. AI는 다른 종류의 실수를 합니다. 여러분의 리뷰 체크리스트를 업데이트해야 합니다.

2. 지표가 중요합니다 — 이 분석이 가능한 이유는 rsync가 29년 치의 릴리스 (release) 데이터를 보유하고 있기 때문입니다. 대부분의 팀은 이와 같은 변화를 감지할 수 있을 만큼 릴리스당 버그를 엄격하게 추적하지 않습니다. 만약 AI 도구를 도입하고 있다면, 먼저 프로세스에 측정 도구 (instrument)를 갖추십시오.

3. 프레임이 잘못되었습니다 — AI 코드 품질에 관한 논의는 "AI가 좋은 코드를 작성하는가"에 머물러 있습니다. 그것은 잘못된 질문입니다. 올바른 질문은 "우리의 프로세스가 AI의 도움을 받은 코드를 올바르게 처리하고 있는가?"입니다. 코드 자체는 괜찮을 수 있습니다. 하지만 그 주변의 프로세스가 그렇지 않을 수 있습니다.

어려운 점

이 분석에서 가장 어려운 점은 재현 가능하다는 것입니다. 누구나 이를 검증할 수 있습니다. 그리고 지금까지 그 누구도 이 방법론 (methodology)의 허점을 찾아내지 못했습니다.

만약 여러분이 AI 코딩 어시스턴트가 순수하게 생산성 측면에서 이득이라고만 스스로에게 말해왔다면, 이는 불편한 사실일 것입니다. 그것들은 생산성 측면에서 이득이 맞습니다. 하지만 동시에 리스크 프로필 (risk profile)도 변화시킵니다.

AI 코딩 도구로 성공할 팀은 그것을 가장 빠르게 도입하는 팀이 아닙니다. 새로운 현실에 맞춰 자신들의 프로세스를 적응시키는 팀입니다.

AI 어시스턴트를 도입한 이후, 여러분의 팀은 코드 리뷰에 어떤 변화를 주었습니까? 무엇이 효과가 있고 무엇이 그렇지 않은지 진심으로 궁금합니다.