Hacker News 2026.06.06 84

"Claude가 rsync 버그를 늘렸을까?" — AI 코딩이 정말 코드를 망치는지 데이터로 따져본 분석

모두가 궁금해하던 그 질문

AI가 짜준 코드, 정말 믿어도 될까요? 요즘 개발자라면 누구나 한 번쯤 던져본 질문이죠. 그런데 이걸 막연한 느낌이 아니라 실제 오픈소스 프로젝트의 커밋 기록으로 검증해보자는 흥미로운 분석이 나왔어요. 대상은 다름 아닌 rsync예요. 파일을 효율적으로 복사·동기화하는 그 유명한 유틸리티 있잖아요. 수십 년 된 C 프로젝트라서 코드가 매우 견고하기로 유명하거든요.

질문은 직설적이에요. "rsync에 Claude 같은 AI 도구로 작성·수정한 커밋이 들어가기 시작한 뒤로, 버그가 실제로 늘었는가?"

어떻게 분석했냐면요

분석의 핵심은 커밋 히스토리를 추적하는 것이었어요. 어떤 커밋이 AI의 도움으로 들어왔는지를 표시(예: 커밋 메시지에 AI 도구 언급)하고, 그 커밋들이 이후에 "이건 버그였네" 하고 되돌려지거나 수정되는 비율을 사람이 짠 커밋과 비교한 거예요.

여기서 잠깐, 버그를 어떻게 추적하냐면요. git에는 git blame과 git bisect 같은 도구가 있어요. blame은 "이 코드 줄을 마지막으로 건드린 게 누구의 어떤 커밋이냐"를 알려주고, bisect는 "버그가 처음 들어온 커밋이 어디냐"를 이진 탐색으로 찾아줘요. 이런 식으로 "나중에 fix 커밋이 고친 그 버그의 원인 커밋"을 역추적하면, 어떤 커밋이 문제를 일으켰는지 가려낼 수 있거든요. 이걸 AI 커밋 그룹과 사람 커밋 그룹으로 나눠서 결함률을 비교한 거예요.

결과를 단정하기 어려운 이유

재미있는 건, 이런 분석이 "AI는 버그를 N% 늘린다" 같은 깔끔한 결론을 내기가 생각보다 굉장히 어렵다는 점이에요. 왜 그러냐면요.

첫째, 표본이 너무 작아요. AI로 표시된 커밋 자체가 전체에서 차지하는 비율이 적으면, 버그 한두 개 차이로 통계가 크게 흔들려요. 한쪽이 10개 커밋인데 그중 2개가 버그면 20%인데, 사실 그 2개는 우연일 수도 있는 거죠.

둘째, AI 커밋과 사람 커밋의 난이도가 달라요. 사람들은 보통 쉬운 보일러플레이트나 리팩터링을 AI에게 맡기고, 정말 까다로운 핵심 로직은 직접 짜는 경향이 있거든요. 그러면 AI 커밋이 평균적으로 더 안전해 보일 수 있는데, 이건 AI가 잘해서가 아니라 애초에 쉬운 일만 시켰기 때문일 수 있어요. 반대 경우도 마찬가지고요. 이걸 통계에서는 '선택 편향(selection bias)'이라고 해요.

셋째, 버그가 드러나는 데 시간이 걸려요. 최근에 들어간 AI 커밋은 아직 버그가 발견될 시간이 충분히 안 지났을 수 있어요. 잠복기가 있는 거죠. 그래서 "아직 버그 안 났으니 안전하다"는 결론은 위험해요.

이런 한계들 때문에 분석은 "AI가 버그를 늘렸다/줄였다"를 단정하기보다, 데이터로 이 질문에 답하는 게 왜 이렇게 까다로운지를 솔직하게 보여주는 쪽에 가치가 있어요.

업계 맥락에서 보면

이 주제는 지금 가장 논쟁적인 영역이에요. 한쪽에서는 "AI 코딩 어시스턴트가 생산성을 몇 배 올려준다"고 하고, 다른 쪽에서는 GitClear 같은 곳에서 "AI 도입 이후 코드 중복이 늘고 리팩터링이 줄었다"는 데이터를 내놓기도 했거든요. rsync처럼 품질 기준이 극도로 높은 인프라급 프로젝트에서 이걸 따져보는 건 의미가 커요. 토이 프로젝트가 아니라 전 세계가 의존하는 코드니까요.

그리고 이건 단순히 'AI 대 인간'의 문제가 아니에요. 진짜 변수는 그 커밋을 리뷰하는 과정이 얼마나 탄탄했느냐예요. AI가 짰든 사람이 짰든, 꼼꼼한 코드 리뷰와 테스트를 거치면 버그는 걸러지거든요.

한국 개발자에게 주는 의미

실무적으로 챙길 교훈이 분명해요. AI가 짜준 코드를 "빠르게 나왔으니 대충 믿고 머지"하는 습관이 진짜 위험하다는 거예요. 코드의 출처가 사람이든 AI든, 적용해야 할 검증의 강도는 똑같아야 해요. 오히려 AI 코드는 그럴듯해 보이는데 미묘하게 틀린 경우가 있어서, 리뷰어가 "잘 짠 것 같네" 하고 방심하기 쉬운 함정이 있거든요.

그리고 우리 팀에서도 이걸 측정해볼 수 있어요. 커밋에 AI 사용 여부를 태깅하는 컨벤션을 두고, 나중에 결함률·재작업률을 비교해보면 우리 팀만의 데이터가 쌓여요. 남이 "AI는 좋다/나쁘다" 하는 말에 휘둘리지 말고, 우리 코드베이스에서 직접 측정한 숫자로 판단하는 게 가장 정확하거든요.