Claude가 rsync의 버그를 늘렸는가?

• Claude 보조 릴리스는 rsync v3.4.2와 v3.4.3 두 건뿐이며, 심각도 가중 버그/10커밋 기준으로 과거 릴리스보다 유난히 버그가 많다는 증거가 없음
• sev/10c는 버그 심각도 점수를 0~1로 정규화해 릴리스별로 합산하고 커밋 수로 나눈 뒤 10커밋당 값으로 환산하는 핵심 지표임
• v3.4.2는 50커밋·9개 Claude 커밋·버그 0개·0.00 sev/10c이고, v3.4.3은 34커밋·28개 Claude 커밋·버그 17개·3.29 sev/10c로 IQR 양쪽을 끼며 어느 쪽도 이상치가 아님
• 정확 순열 검정 p값은 46%, Fisher의 정확 검정 p값은 74%, 오즈비는 1.06으로, Claude 릴리스가 무작위 2개 릴리스보다 나쁘거나 중앙값 초과 가능성이 높다는 신호가 거의 없음
• v3.4.1은 Claude 도입 전 릴리스인데도 59버그·9커밋·39.39 sev/10c로 전체 데이터의 최악값이었으며, rsync 논란의 핵심은 역사적 분포 없이 단일 회귀를 Claude와 연결한 데 있음

---

배경과 질문

• 2026년 5월 말 rsync 논란은 v3.4.3 회귀와 해당 릴리스의 Claude 커밋을 연결한 Mastodon 게시물에서 시작해 Hacker News와 GitHub 이슈 "Please Do Not Vibe Fuck Up This Software"로 확산, 해당 이슈에는 300개가 넘는 댓글이 쌓임
• 반복된 핵심 명제는 Claude 보조 개발이 안정적이던 도구에 버그를 넣었다는 형태였고, 데이터 질문은 Claude 보조 릴리스가 역사적 릴리스보다 비정상적으로 버그가 많은지 여부임
• Lobsters에서는 릴리스별 회귀 수를 시간 차트로 보자는 요청이 나왔고, 분석의 초점은 “Claude 보조 릴리스가 유난히 버그가 많은가”라는 단일 질문임

데이터 범위와 재현성

• 데이터는 RsyncProject/rsync의 v2.4.6부터 v3.4.3까지 버그 데이터가 있는 36개 릴리스이며, Claude 커밋이 있는 릴리스는 v3.4.2와 v3.4.3 두 개뿐임
• 지표·방법론·데이터 소스 선택은 사람이 직접 했고, 통계학 석사 학위를 가진 배우자의 조언을 반영함
• 데이터 수집, DuckDB 적재, 뷰 생성, 통계 분석 스크립트는 GLM 5.1이 작성했지만, 모든 숫자·통계·카드·그래프는 통계 분석을 실행한 Python 스크립트가 자동 템플릿으로 삽입함
• 재현용 alexispurslane/rsync-analysis 저장소는 전체 파이프라인을 처음부터 끝까지 실행할 수 있음

지표와 버그 귀속 방식

• 핵심 지표는 심각도 가중 버그/10커밋인 sev/10c이며, 계산식은 sev/10c = (Σ severity/100 ÷ total_commits) × 10임
• 커밋은 기본 브랜치의 committer date 순서로 정렬하고, 각 릴리스 범위는 이전 태그부터 해당 태그까지의 커밋으로 잡으며, pre·rc 태그는 경계에서 제외해 최종 릴리스에 흡수하는 방식임
• 버그 출처는 GitHub 이슈, rsync Bugzilla, rsync 메일링 리스트 세 가지이며, GitHub 이슈와 메일링 리스트 버그는 보고 시점 직전에 배포된 최신 릴리스에 귀속함
• Bugzilla 항목은 “Version” 필드가 버그가 보고된 릴리스를 명시하므로 해당 릴리스에 귀속함
• 릴리스 단위 분석을 택한 이유는 비판 자체가 “Claude 커밋이 있는 릴리스 전체가 더 버그가 많아졌다”는 형태이고, 대부분의 버그가 정확히 어떤 커밋에서 비롯됐는지 명시하지 않기 때문임

심각도 평가 방식

• 모든 버그 보고서는 Qwen 3 35B가 0~100점 심각도로 채점했고, 프롬프트는 실제 사용자 영향 관점의 선임 신뢰성 엔지니어 역할을 부여함
• 90~100점은 조용한 데이터 손상·데이터 손실·원격 코드 실행 또는 무단 접근 보안 취약점, 70~89점은 크래시·행·백업 실패·빌드 실패, 50~69점은 우회 가능한 기능 회귀로 구분함
• Bugzilla와 메일링 리스트는 본문 없이 제목만 있었으므로 모델이 제목만 보고 평가했고, 정보가 부족하면 40~60점 중간 범위로 기울도록 지시함
• 출력은 structured output의 JSON schema로 정수 심각도만 허용했고, temperature 0으로 고정해 같은 입력이 같은 점수를 내도록 설정함
• 기능 요청, 스팸, AI 관련 비기술적 항의, 빈 제출처럼 0점을 받은 이슈는 기본 버그 수에서 제외함

Claude 릴리스의 통계 결과

• v3.4.2는 50커밋 중 Claude 커밋 9개, 실제 버그 0개, 0.00 sev/10c, 0백분위 릴리스임
• v3.4.3은 34커밋 중 Claude 커밋 28개, 버그 17개, 3.29 sev/10c, 77백분위 릴리스임
• 역사적 IQR은 0.29~2.59 sev/10c이며, v3.4.2는 IQR 바로 아래, v3.4.3은 IQR 바로 위에 있어 두 릴리스가 중간 분포를 서로 반대쪽에서 끼는 형태임
• 정확 순열 검정은 가능한 2개 릴리스 조합 595개 중 272개가 Claude 그룹 평균 1.65 sev/10c 이상이어서 p값 46%라는 결과를 냄
• Fisher의 정확 검정은 중앙값 0.74 sev/10c 기준으로 Claude 릴리스가 중앙값 초과에 더 자주 놓이는지 봤고, p값 74%와 오즈비 1.06이라는 결과를 냄

커밋 수와 변경 규모

• Claude 릴리스는 평균 42커밋, Claude 미포함 릴리스는 평균 185커밋이었고, 임의 2개 릴리스가 그만큼 많거나 더 많은 커밋을 가질 확률은 88%였음
• GitHub compare API 기준 변경 라인은 Claude 릴리스 평균 3,756줄, Claude 미포함 릴리스 평균 696줄이었고, 임의 2개 릴리스가 그만큼 많거나 더 많은 변경 라인을 가질 확률은 5%였음
• 심각도 가중 버그 수는 Claude 릴리스 평균 5.6개, Claude 미포함 릴리스 평균 14.9개였고, 임의 2개 릴리스가 그만큼 많거나 더 많은 심각도 가중 버그를 가질 확률은 77%였음
• 결론적으로 Claude 릴리스는 변경 라인이 훨씬 많았지만, 커밋 수나 심각도 가중 버그 수가 더 많지는 않은 결과임

버전 체제와 사전 이상치

• v2.x 릴리스 평균은 1.11 sev/10c, v3.x 릴리스 평균은 4.23 sev/10c로 v3.x 쪽이 더 높은 버그율을 보임
• v3.x만 비교해도 Claude 릴리스는 중간권 또는 그보다 나은 위치에 있으며, Claude를 이상치처럼 보이게 하려면 더 조용한 과거 시대와 비교해 이미 Claude 이전에 일어난 변화를 Claude 탓으로 돌리는 형태가 됨
• Wald–Wolfowitz runs test는 Claude 없는 35개 릴리스에서 관측 run 13개, 무작위 기대값 18.5개, z=-1.88, p=0.060을 냈고, 0.05 기준에서는 무작위성을 기각할 만큼 강하지 않음
• v3.4.1은 Claude 도입 전 릴리스인데도 59버그·9커밋·39.39 sev/10c로 전체 데이터에서 가장 높은 버그율을 기록한 릴리스임
• v3.4.1은 v3.4.0 다음 날 나온 hotfix 릴리스였고, 다른 모든 릴리스를 한 자릿수 차이 이상으로 넘는 최고 버그율을 보였지만 AI를 탓할 대상이 없던 시기였음

해석과 한계

• 데이터와 일치하는 해석은 “현재 두 Claude 릴리스는 역사적 릴리스와 통계적으로 구별되지 않는다”는 쪽임
• v3.4.3은 3.29 sev/10c로 77백분위라 높기는 하지만 극단값은 아니며, 이보다 높은 점수를 낸 역사적 릴리스가 8개 있음
• “Claude가 분명히 더 나쁘게 만들었다”는 명제는 릴리스 분포, 순열 검정, Fisher 검정 어느 쪽에서도 뒷받침되지 않음
• 반대로 “Claude 커밋은 일반적으로 앞으로도 더 나쁘게 만들지 않는다”는 결론도 이 데이터에서 나오지 않으며, 현재 두 릴리스가 평범하다는 범위에 그침
• 이 지표는 커밋 복잡도나 보안 작업 강도를 통제하지 못하는 둔한 도구라는 한계를 가짐

논의된 교란 요인

• Hacker News의 한 사용자는 CVE 대응 보안 수정이 2007년부터 코드에 있던 코딩 오류를 드러낸 것으로 보인다고 봄
• Lobsters의 한 사용자는 “LLM → 알려진 보안 이슈 증가 → 평소보다 많은 변경 필요 → 평소보다 많은 회귀”라는 인과 사슬을 제시함
• Andrew Tridgell은 AI 생성 CVE 보고서 홍수가 rsync의 공격 표면에 빠르고 광범위한 변경을 요구했다고 설명함
• 이 교란 요인까지 포함하면 문제는 Claude 자체라기보다 더 많은 보안 작업과 그에 따른 변경량 증가라는 쪽에 가까움

[GN⁺]

Hacker News 의견들

• 커밋을 보다가 원래 커밋과 되돌림 커밋을 발견했음: https://github.com/RsyncProject/rsync/commit/d046525de39315d...
  malloc이어야 할 경로까지 calloc으로 바뀌면서 모든 할당을 calloc이 엄격한 상위 호환인 것처럼 강제함. 큰 할당이나 재귀적 할당에서는 비용이 꽤 커짐. Claude로 작성된 코드에서 이런 게 주의망을 빠져나가는 좋은 예처럼 보임. 되돌림은 https://github.com/RsyncProject/rsync/commit/7db73ad9a1b8721...에 있고, 되돌림 설명도 반쯤만 읽어도 LLM이 쓴 티가 남. 원 글을 올린 사람의 심정은 이해됨

  • 커밋 수 자체도 수상함. 최근 두 달 동안 rsync에 들어간 커밋 수가 그 전 2년치와 비슷하고, 대부분 Claude로 작성된 커밋임. 이런 변경까지 들어간 걸 보면 AI 사용에 신나서 점점 부주의해지는 전형적인 모습처럼 보임
  • “Claude로 작성됨”은 맞지 않음. 되돌림 커밋은 https://github.com/RsyncProject/rsync/issues/959를 참조하고, 그 이슈에서 작성자가 직접 “메모리를 0으로 만드는 변경은 내 아이디어이자 내 변경”이라고 설명함
    보안 보고서에서 배열 끝을 넘어선 요소 사용이 나왔고, 할당을 0으로 초기화하면 비슷한 버그가 나중에 생겨도 유효 포인터 대신 null 포인터 역참조로 끝날 가능성이 높다고 봤다는 것임. Claude는 커밋 묶음을 정리하는 데만 썼고, 조금이라도 수정하면 co-authored 태그가 붙는 방식이라 Claude가 변경을 작성했다는 뜻은 아님. 실제 코드는 본인이 썼다고 밝힘
  • Claude가 그 결정을 했다고 단정하진 않겠음. 큰 커밋 사이에 몰래 끼어든 부수적 변경도 아니고, 커밋 메시지부터 “새로 할당된 메모리를 모두 0으로 초기화”라고 시작하며 실제로 그 일을 함. 애초에 어떤 프롬프트였다고 상상하는지 모르겠음
    사람이 처음엔 개선이라고 생각했다가 RSS 회귀를 보고 다시 생각했을 가능성이 충분함. 그리고 이 변경이 반드시 RSS를 늘려야 한다는 자연법칙도 없음. calloc은 운영체제에서 막 받은 새 메모리 매핑이 이미 0으로 초기화된다는 점을 알고 특수 처리할 수도 있음. 여기서 AI 탓을 한다면, AI가 취약점 보고의 폭증을 만들고 그게 급한 수정의 폭증으로 이어졌으며, 급한 수정이 가끔 다른 문제를 만든다는 의미에 가까움
  • AI에 Linux overcommit까지 곱해진 시대라니 대단함. 개인적으로는 10.8GB는 요즘 별것도 아니고, sprintf 버퍼가 그보다 더 클지도 모름. 아니라면 그래야 하고, 아니면 snprintf를 쓰기 시작해야 함

• 댓글을 달기 전에 rsync 작성자가 링크한 글을 읽어보길 권함: https://medium.com/@tridge60/rsync-and-outrage-d9849599e5a0
  공개하자면 Tridge와 몇 년째 연락하진 않았지만 오랫동안 동료이자 멘토였음. 십자군에 합류하기 전에 그의 관점을 고려할 가치가 있음

  • 이게 최상단 댓글이어야 함. 그가 이런 글까지 써야 했다는 게 꽤 슬픔. 그의 청구서를 내주는 것도 아닌 사람들이 판단을 너무 많이 함
  • “새 테스트 스위트의 핵심 구조를 master에서 공개적으로 먼저 만드는 게 좋겠다고 생각했다”는 부분이 완전히 이해되진 않음. 테스트만 갱신했거나 master에만 푸시했다면 사람들이 분노하진 않았을 것임
    하지만 그는 릴리스 브랜치에도 깨지는 변경을 푸시했음. 수년간 작동하던 워크플로를 깨는 건 사람들을 화나게 만드는 가장 확실한 방법이고, 거기에 커밋에서 “Claude”까지 보이면 불에 기름을 붓는 셈임
  • 그의 답변은 정말 잘 쓴 대응이라고 봄

• 이 싸움에 직접 걸린 건 없지만, 몇 가지 수상해 보이는 부분이 있음. 버그가 가장 많이 귀속된 릴리스가 Claude 공동 작성 커밋이 처음 들어간 릴리스 바로 직전인 1월 릴리스인데, 귀속 표시가 안 된 LLM 작성 커밋이 이 릴리스에 들어갔을 가능성은 없는지 궁금함
  릴리스 귀속 방법론도 별로임. 마이너 버전 업데이트에서 도입된 버그가 그 마이너 버전에서 가장 오래 유지된 패치 릴리스로 귀속되는 경향이 있음. 3.4.1이 실제로 많은 버그를 도입했다고 보긴 어렵고, 3.4.0 다음 날 나온 탓에 그 릴리스에서 생긴 버그가 3.4.1로 잡혔을 가능성이 큼. 또 최근 릴리스는 버그가 보고될 시간이 적었기 때문에 최근 릴리스가 덜 버그 많은 것처럼 평가되는 편향도 있을 수 있음

  • 동의함. 글의 “rsync 역사상 최악의 릴리스는 Claude 도입 이전이었고, 아무도 알아차리지 못했다”는 표현은 작성자가 이 싸움에 이해관계가 없다는 느낌보다는 화려한 통계 용어로 의견을 감싼다는 느낌을 줌
    “눈부실 만큼 명확하다”? 그래프 하나 그리면 됨. 그리고 v3.4.1은 2025-01-16이라 기술적으로 AI 보조 코딩 시대 안에 있고, 귀속 표시가 표준 관행이 되기 전이었음
  • 릴리스가 꽤 드문 점을 감안해 같은 부분을 살펴보기 시작했음. 귀속 표시가 안 된 LLM 작성 커밋 문제를 피하려면, 분석은 v3.3.0 전후의 버그 심각도 비교를 포함해야 한다고 봄. 날짜는 2024년 4월 6일임
  • LLM은 여러 방식으로 쓸 수 있음. 사람이 아주 직접 개입해 로컬 변경만 시키는 방식부터 완전히 맡기는 방식까지 다양함
    LLM이 생성했지만 커밋 메시지에 공동 작성자가 붙지 않은 코드를 많이 봤음. 보통 코드베이스와의 인터페이스가 Claude/Codex 같은 도구를 통해 완전히 이뤄질 때만 그런 태그가 붙는 듯하고, 그런 커밋들은 대개 가장 장황하면서도 왜 바꿨는지는 거의 말하지 않고 코드 변경 요약만 함. 반대로 Claude를 도구로 쓰는 개발자도 봤음. VSCode와 Claude 터미널을 오가며 올바른 코드를 직접 확인하고, 배관 작업만 Claude에 맡기는 식임. 아마 작성자도 작게 시작했다가 시간이 지나며 커졌을 수 있음
  • 첫째와 둘째 포인트는 서로 모순돼 보임. 3.4.1의 모든 버그가 3.4.0에 귀속되어야 한다면, 귀속되지 않은 LLM 커밋이 프로젝트에 들어갔어야 하는 시점은 더 앞당겨지고, 그럴수록 가설은 더 터무니없어짐
    더 큰 문제는, 이전 릴리스에 LLM 커밋이 몰래 들어갔고 그래서 버그율이 높았다는 가설을 뒷받침하는 증거가 전혀 없음. 버그 수가 높으면 자동으로 AI 개입을 뜻한다고 전제하지 않는 한 근거가 없고, 그건 순환논법임. 셋째 포인트는 타당함. 보통 버그를 찾는 데 얼마나 걸리는지와 각 버전이 릴리스 주기에서 어디쯤인지 분석해뒀고 원하면 올릴 수 있음
  • 가장 노골적으로 놀라운 오류부터 보자면, Claude 통계가 전체 데이터 2개에서 나온 것임

• 여기엔 중요한 메타 차원의 아이러니가 있음. 원 글은 AI 사용을 방어하지만, 데이터를 분석하고 결과를 제시하는 데도 명백히 AI를 쓴 것으로 보임
  그 과정에서 작성자는 자신이 잘 이해하지 못하는 방식으로 통계를 사용했고, 여러 잘못된 결론에 도달함. 관련 논의는 https://news.ycombinator.com/item?id=48417626에서 볼 수 있음. 요약하면 이 연구는 충분한 통계적 검정력이 없고, 정당화되지 않는 “차이가 없다”는 주장을 하고 있음. 결국 LLM으로 데이터를 해석하다가, 이 연구가 조사하려던 것과 같은 종류의 실수, 즉 거짓을 자신 있게 단언하는 실수를 한 셈임

  • AI는 너무 종교 같음. 믿는 사람에게 무슨 말을 해도 믿음을 의심하게 만들 수 없음. 더 일반적으로 말하면, 누군가 믿고 싶어 하는 것을 이성으로 설득해 포기하게 만들 수는 없음

• 이 일에 화난 사람들이 rsync 유지보수자를 압박해서 얻을 건, 다른 사람들이 AI 사용을 책임 있게 공개하지 않게 만드는 것뿐일 거라고 봄. 논란을 피하려고 커밋에서 Claude 귀속 표시를 꺼버리게 만들 것임

  • AI 사용 공개는 별로 신경 쓰지 않음. 직접 아는 사람이 아니라면 사람이 만든 코드가 AI가 만든 코드보다 반드시 낫다고 믿지 않기 때문임
    어쨌든 커밋하고 푸시하는 코드에 대한 책임은 사람이 져야 함. 이건 변한 적이 없음. 손으로 썼든, 고양이가 키보드 위를 걸어가서 만들어졌든, AI가 만들었든 내 관심사는 아님. 프로젝트의 코드 품질은 온갖 이유로 떨어질 수 있고, AI가 만들었는지 여부에만 집착하는 건 생산적이지 않음. 누군가는 AI를 비판할 구실을 찾고, 다른 누군가는 AI를 방어하고 싶다면 그렇게 해도 되지만, 프로젝트 코드 품질을 평가하는 방식으로는 맞지 않음
  • 논란과 무관하게 그런 표시를 끄는 게 맞음. 조 단위 기업에 무료 광고를 해줄 이유가 없음. Generated-by 같은 트레일러는 제3자 프로젝트에 기여할 때나 관련 있고, 그때는 공개하는 게 예의임
  • “비윤리적이거나 부도덕한 일을 했다고 화내지 마라, 아니면 더 비윤리적이거나 부도덕한 일을 할 것이다!”라는 식으로 들림
    LLM 생성 코드의 귀속 표시를 끄는 건 사기임. 자신이 코드를 썼다고 말하는 셈이기 때문임. 물론 애초에 LLM으로 코드를 생성하는 것과도 잘 맞긴 함. 실제로는 라이선스와 저작권 표시를 제거한 채 입력을 되뱉는 일이니까
  • 그게 나쁜 일인가 싶음. Anthropic 마케팅 부서 관점에서는 그렇겠지만, 에이전트가 개발자 도구함의 또 다른 도구일 뿐이라면 귀속 표시는 좀 이상하게 느껴짐. 결국 커밋 책임은 개발자에게 있음
  • 이 논리는 매번 나오지만 설득력이 없음. 문제를 공개적으로 짚으면 숨길 유인이 생기는 건 맞지만, 그래서 어쩌라는 건지 모르겠음
    AI가 나쁘다는 논쟁은 잠시 빼고 비유하자면, 탈세는 나쁘고 비윤리적이며 보이면 지적해야 함. 그런데 그게 숨길 유인을 만든다고 해서, 지적하지 말고 입 다물고 있어야 한다는 결론이 되진 않음

• Andrew가 rsync를 만들고 유지해온 일에는 감사하지만, 집 네트워크에서 머신 간 파일 백업에 rsync를 크게 의존하고 있어서 Homebrew의 rsync 버전을 3.4.1에 고정하는 방법을 시간을 들여 알아냈음
  이후 두 버전의 버그가 정말 무섭고, 이 모든 일을 촉발한 원래 보고서도 마찬가지임. 생각보다 훨씬 복잡했던 절차는 여기에 정리했음: https://gist.github.com/e40/caa67c1b8d439a528695f996d0519d8e

• 이 글은 답보다 질문을 더 많이 남겨서 판단을 내리기 어려움. 왜 Claude 커밋 직전의 v3.4.1이 가장 버그가 많았고, 왜 “아무도 알아차리지 못했는지” 모르겠음. 그냥 인간 오류라고 넘기기엔 너무 이상함
  또 왜 v3.4.2는 버그가 0개이거나 버그 점수가 0인지도 의문임. 다른 커밋에는 없어 보이는 이런 이상치가 집계 통계에 섞여 “Claude가 버그를 만든다?” 점수를 낮추도록 허용된 것도 이상함. 솔직히 이게 작성자의 분석에서 위험 신호가 아니었다는 점이 이해되지 않음. 고급 통계를 돌린다는 이유로 반쪽짜리 분석이 매우 복잡한 완성품처럼 제시된 느낌임

  • v3.4.1이 인간 오류가 아니라고 볼 이유가, 그렇게 될 수 없다는 선결 가정 말고 무엇인지 모르겠음
    v3.4.2도 원래 지표에서는 기능 요청과 질문을 걸러내기 전엔 버그 4개였고, 그 전엔 더 높았지만 전체 분석에는 큰 차이를 만들지 않았음. 사분위 범위 안, 그것도 낮은 쪽에 잘 들어갔음. Claude 릴리스가 겨우 두 개뿐인 상황에서 하나의 이상치를 그냥 웃겨 보인다는 이유로 제거하는 편이 더 나쁘고 더 임의적이라고 봄

• “커밋 복잡도, 보안 집중도, 버그 심각도를 통제하지 않는다. 한 줄 오타 수정과 CVE 패치를 구분하지 않는 둔기다. 하지만 비판자들의 ‘Claude가 상황을 악화시킨다’는 비난도 둔기이므로, 둔기가 가장 공정한 대응이다”라는 식이라면 동의하기 어려움
  사용자 관점에서 버그의 성격이 더 나빠졌는지를 이해해야 함. 비율이 그대로라도 체감 소프트웨어 품질이 떨어졌다면, 특히 프로젝트 유지보수자라면 그걸 더 나빠졌다고 볼 것임. 이 분석을 완전히 무시하려는 건 아니지만, 이런 질문은 정량 분석만으로 충분히 답하기 어렵다고 봄

  • 그래도 공정하다고 봄. 지금까지 누군가 코드를 분석해서 어떤 심각도의 회귀가 몇 개 나왔다고 말한 걸 못 봤음. 그냥 “LLM 때문에 버그가 늘었다”고만 함
    이 분석은 원하면 직접 검증할 수 있고, “LLM이 있어도 버그 수는 꽤 평균적”이라고 말함. 그 주장에는 직접 대응한 셈임. 더 미묘한 분석을 원한다면 직접 해서 결과를 공유하면 됨
  • 증거 없이 주장된 것은 증거 없이 기각될 수 있음. 이 분석은 원래 주장에 쓰인 것보다 더 많은 증거와 더 높은 엄밀성을 가짐. 내겐 충분함. 누군가 원래 주장을 더 나은 증거로 뒷받침하는 일을 실제로 한다면 좋고, 보고 싶음. 그때까지는 이 문제를 걱정하지 않겠음
  • 입증 책임은 주장하는 사람에게 있는 것 아닌가?

• 20년 넘게 코딩해왔고, 코딩을 사랑해왔으며 앞으로도 그럴 가능성이 큼. 몇 달 전만 해도 AI 회의론자였지만, Claude와 Codex는 상상도 못 했던 방식으로 내 개발 방식과 속도를 바꿔놨음
  그 결과 더 많은 코드를 만들고 더 많은 버그도 찾고 있음. 그래서 HN 댓글에서 AI로 만들어진 것에 대한 극단적인 혐오를 보면 꽤 놀라움. AI가 도왔거나 전부 생성했다고 해서 프로젝트가 갑자기 vibe coding이 되는 것도 아니고, 그 말이 LLM 사용자에게 던지는 모욕이어야 하는 것도 아님. 90년대 중반 이후 해외 외주 개발이 늘면서 “인도 개발자”에게 쏟아졌던 멸시적 표현이 많이 떠오름. 2020년대 중반인 지금 비슷한 말이 AI를 향해 나오고 있음. 이해가 안 됨. 확실한 건 반대자와 무관하게 점점 더 많은 코드가 AI로 생성될 것이라는 점임

  • 나도 3년 전에는 비슷하게 AI 회의론자였음. GPT-4가 최첨단이던 시절에는 문맥 크기 한계 때문에 곧 정체될 거라고 생각했음. 32K 문맥을 쓰려면 말도 안 되는 돈을 내야 하던 때를 기억함
    작년에 처음으로 AI 에이전트가 사소하지 않은 버그를 만족스럽게 디버그하고 고치는 걸 봤음. 그때도 큰 작업에 써보면 이슈 추적기를 통째로 넘길 수 있는 수준은 아니란 게 분명했음. 지금은 지난 몇 달간 Codex로 사소하지 않은 프로젝트를 작업 중임. 라이브러리 이유로 C++로 시제품을 만들고, 초기 버전은 Haskell로 썼으며, 최근에는 모바일 메모리 사용을 억제하려고 Rust로 이식했음. 문제 없는 도구는 아니지만 지난 1년만의 진전 속도는 놀라움. 회의론은 좋지만, 건강한 회의론이라면 구체적 증거 앞에서는 물러나야 함
  • 도구가 관련된 어떤 주제에서든, 도구 자체를 좋아하는 사람과 도구로 다른 무언가를 하는 걸 좋아하는 사람이 있음. 프로그래밍에서 나는 후자였음. 프로그래밍은 내가 진짜 좋아하는 문제 해결, 시스템 수준 사고, 소프트웨어를 통한 멋진 해법 제공을 가능하게 하는 도구임
    그래서 AI가 지루한 부분을 도와주니 정말 즐겁고, 비프로그래머 동료들이 자신들의 vibe coded 아이디어가 현실이 되는 걸 보며 신나 하는 모습도 아주 재미있음. 소프트웨어 업계에서 일하는 반AI 입장의 관점이 진심으로 궁금함. 직업의 임박한 종말이나 기술 전환 때문일까?
  • 90년대 중반 해외 외주가 늘었을 때 “인도 개발자”를 향한 멸시적 표현이 나왔다면, 그 계기는 무엇이었나?
  • 외주 코드를 늘 다루는데 예외 없이 타이어 화재 같음. 방금도 어떤 개발자가 로컬 작업 환경을 설정할 줄 몰라 인증 검사를 우회하는 플래그를 기본 켜짐으로 커밋한 코드베이스를 일주일 동안 청소했음
    AI vibe coding에서도 같은 “지름길” 문제가 보고되고, 나 역시 최전선 모델을 사고 수준 11까지 올려 써도 AI가 생성한 거의 모든 코드를 다시 작성해야 했음. 그렇지만 AI는 PR 검토, 보안 취약점 분석, 오타 찾기, 역공학 같은 다른 활동에는 매우 유용함. 아마 구독을 다음 단계로 올려야 할 텐데, 동시에 AI가 생성한 코드는 여전히 쓸 수 없음. 한 사람 안에서도 “매우 유용해서 더 돈을 내야 함”과 “출력 코드 품질은 쓸모없음”이 동시에 가능하다면, 전체 사용자층에 다양한 의견이 나오는 건 당연함
  • LLM은 문맥 검색과 템플릿 출력에는 좋음. 하지만 보장되는 건 가장 낮은 공통의 두드러진 답이고, 저작권 보호가 안 되는 산출물이며, 저작권 누출로 인한 잠재적 법적 위험도 있음
    지금은 동형 표절의 Napster 황금기임

• 대체 이게 뭔가 싶음. 실제로 중요한 건 AI가 작성한 코드가 코드베이스에 허용된 뒤 버그가 더 많아졌는지뿐임. 답은 모두가 알고 있음. 그래도 “데이터”가 필요한 결론을 만드는 데 쓰일 수 있다는 걸 보는 건 늘 흥미로움

[GN⁺]

Lobste.rs 의견들

• 앞으로 바이브 코딩으로 진행될 FOSS 프로젝트를 계속 쓸지 말지는 각자 판단할 수 있다고 봄. 다만 관리자가 바이브 코딩 도구로 전환한 뒤 커뮤니티가 보인 분노는 꽤 놀라웠고, 글에 나온 실증 데이터는 적어도 그 관행 변화의 영향을 더 잘 맥락화해 줌
  관리자가 이 코딩 방식을 채택하면서 신뢰가 유지될지 더 무너질지는 시간이 지나야 알 수 있음

  • 이 전환에 화낸 사람들 중 실제로 rsync에 의미 있게 기여했거나 돈을 낸 사람이 얼마나 되는지 궁금함

• 이 분석은 내가 바라던 바로 그 내용이었고 그 이상이었음. 특히 “모든 지표, 방법론, 데이터 출처는 Penn State University 통계학 석사인 아내와 상의해 내가 직접 골랐다”는 부분이 좋았고, 실제 통계 전문가를 참여시킨 점과 읽기 쉬운 글로 만든 점이 훌륭함
  “커밋 10개당 버그 수”라는 단일 지표를 썼다는데, SI 접두어를 써서 커밋당 데시버그(decibugs)라고 부를 기회를 놓친 듯함

  • 동의함. 내 글은 아니지만, 누군가가 과열된 찬반을 넘어 코드 품질에 미친 영향을 데이터로 보여준 점이 좋았음

• 오픈소스 프로젝트의 성공은 인식에 너무 크게 좌우돼서 사람들이 GitHub 스타를 돈 주고 사기도 함. 안타깝게도 이번 인식 문제는 통제를 벗어나 하나의 논점이 됐고, 어떤 데이터도 그걸 바꾸기 어려움
  앞으로 “rsync 관리자가 LLM을 썼더니 망가졌다”는 말은 “데이터센터가 하루에 깨끗한 물 50만 갤런을 낭비한다”, “METR 연구가 LLM이 생산성을 떨어뜨린다고 했다” 같은 논점과 함께 AI 회의론자들이 꺼내 들게 될 것임
  내가 AI 회의론자인지 여부를 말하려는 건 아니고, 이 주제의 논쟁이 보통 이런 식으로 흘러간다는 점을 말하는 것임

  • 그게 왜 “논점”이지, 그냥 사실 아닌가?
  • 글쓴이가 데이터로 누군가를 설득하려는지는 모르겠음. 이 글은 rsync의 도구 채택을 둘러싼 매운 논쟁에 데이터 맥락을 붙인 것으로 봄
    다만 글에서 다른 비정량적 요소들이 완전히 빠졌다는 말은 맞고, 전도사와 회의론자 양쪽의 소음이 이미 충분해서 일부러 그랬을 것 같음

• rsync 역사상 최악의 릴리스는 Claude 도입 전이었고, 커밋 10개당 버그가 39.39개였다는 부분이 매우 중요하고 예상 가능한 결론임
  사용자와 개발자 사이에 테스트, 품질보증 같은 프로세스가 소프트웨어의 정확성을 보장하지 못하면 LLM이 있든 없든 버그를 배포하게 됨. LLM은 이 과정에 해가 될 수도 있고 도움이 될 수도 있음

  • 동의함. cURL의 최근 글은 그 반대편 사례를 보여주는 듯함
    이미 수년간 자리 잡은 강한 소프트웨어 공학 관행 덕분에 비슷한 AI 도구로 버그를 찾는 가치가 전반적으로 낮아졌음
  • rsync의 미래에 대해 몇 가지 우려가 있음. 가장 큰 문제는 rsync가 사실상 몇 년간 완성된 프로젝트였는데, AI를 쓰면서 기존 테스트 코드를 뜯어내고 Python 테스트 스위트로 바꿨으며, 상당 기간 기존 테스트를 병행해 정확성을 검증하지 않았다는 점임
    내 기준으로는 무책임함. 특히 rsync의 주된 목적은 소중한 데이터를 옮기는 것이고, 그 데이터의 무결성은 절대적으로 중요함

• “AI 반대 사용자에게 전형적이듯 결국 폭력 판타지로 escalated됐다” 같은 수사는 피했으면 함. 글쓴이가 동의하지 않는 일부 사람들을 일반화할 뿐 아니라, 원래 동의하지 않는 독자에게도 반감을 사서 정작 가장 읽어야 할 사람들이 글을 보지 않게 됨
  별개로, 이전 버전보다 버그가 많든 적든 나는 별로 상관하지 않음. 내가 중요하게 보는 건 내가 생각하는 소프트웨어 개발 방식과 맞지 않는 방식으로 개발된다는 점임. 효율성 말고도 문제가 있다는 기본 이해가 없다면 이 입장이 합리적이라고 설득할 기대는 없음
  다행히 원치 않으면 이 버전의 rsync를 쓰지 않아도 되고, LLM 사용 이전에서 갈라진 대안을 고를 것임

  • 이 글은 너무 화가 많이 담겨 있어서 오래 읽지 못하고 포기했음. 공정하려고 했거나 적어도 그렇게 보였으면 더 나았을 듯함
    이미 오래전에 반박된 밈, 즉 첫 번째 버그 리포트가 사람들이 몰려든 이슈였다는 얘기를 반복한 것도 도움이 안 됐음. 실제 첫 버그 리포트는 따로 있었음

• 지금 글이 솔직히 더 낫다고 봄. 다만 “이 지표는 커밋 복잡도, 보안 민감도, 버그 심각도를 통제하지 못한다. 한 줄짜리 오타 수정과 CVE 패치를 구분하지 못하는 둔한 도구다”라는 부분은, LLM은 나쁘다 쪽에 있는 내 입장에서는 핵심 비판을 놓치는 것임
  나와 다른 사람들이 제기하는 비판은 AI가 더 크고 쉽게 이해하기 어려우며 복잡도를 늘리는 커밋을 쏟아내게 만든다는 것임. LLM 지지자들도 비슷한 말을 하다가, 수십 년간 검증된 “PR 읽기” 관행에서 “LLM이 모든 걸 테스트할 수 있어야 한다”로 골대를 옮기곤 함. 하지만 코드 복잡도가 기술 부채라는 문제는 사라지지 않음
  이번 경우 버그 심각도는 매우 높음. 백업 워크플로가 실제로 깨졌기 때문임. rsync는 백업에 널리 쓰이고, 사람들은 패치 업데이트로 백업 스크립트가 깨질 가능성은 상상조차 하지 않을 만큼 “전투 검증된” 도구로 신뢰해 왔음
  LLM이 버그 있는 소프트웨어를 만든 게 우연이었다거나, 관리자가 LLM 작업 흐름을 바꾸고 테스트 커버리지를 높여야 한다고 말할 수는 있음. 실제로 관리자도 그렇게 말했음. 하지만 분노의 핵심은 이 도구가 그 신뢰를 깼다는 데 있음
  실제로 요즘 “코드를 전혀 읽지 않는다”고 말하는 새 부류의 LLM 프로그래머들이 있음. 읽는 데 시간이 너무 오래 걸리고 일반 프로그래머 코드보다 파악하기 복잡하다는 이유임. 코드를 읽는다는 건 다른 사람의 정신 모델을 배우는 일인데, LLM 도구는 하나의 일관된 정신 모델을 제공하지 못함
  별개로 사이트 접근성도 확인해야 함. 시력이 꽤 좋고 20대 후반인데도 크림색/노란색 배경 위의 밝은 회색 글자는 읽기 정말 고통스러움

  • 인용한 부분이 헷갈림. 글에서 쓴 지표는 커밋 10개당 버그 수에 심각도 가중치를 준 것처럼 보이는데, 글쓴이가 자기 자신과 모순되는 건가? 내가 잘못 읽은 건가?
  • 워크플로가 깨졌다는 사람들에게는 오픈소스 소프트웨어와 GPL 라이선스가 무엇인지, 어떤 보장을 주는지 배우기 좋은 기회라고 봄
    사람들이 직접 그 버그를 발견했을 것 같지는 않음. rsync 사용자 90% 이상은 그 버그가 없는 이전 버전을 쓰고 있을 거라고 추측함. 나도 그중 하나임

    $ uname -a  
    Darwin riemann.local 25.3.0 Darwin Kernel Version 25.3.0: Wed Jan 28 20:53:31 PST 2026; root:xnu-12377.91.3~2/RELEASE_ARM64_T8103 arm64
    
    $ port info rsync  
    rsync @3.4.1 (net)  
    [...]  
    

    관심을 끈 이유라면, 지금 커뮤니티 상당 부분이 혼란에 빠져 있다는 점은 Steven Pinker가 아니어도 이해할 수 있음. LLM이 인간보다 프로그래밍을 더 잘한다는 사실은 받아들이기 쉽지 않음
    자신의 정체성과 자존감을 프로그래밍 능력이나 직업에 두었던 사람들은 미래 생계/시장 가치의 불확실성과 정체성 위기라는 두 가지 위기를 맞고 있음
    공포, 불확실성, 의심은 다루기 어렵고 LLM 회사들은 주가를 올리기 위해 그 효과를 증폭하는 데 최선을 다하고 있음. 10월 이후 시장이 급격히 조정되면 이런 증폭 장치도 약해질 수 있다고 봄
    전 세계 프로그래머 중 아주 작은 비율, 즉 코드를 예술 형식으로 보는 사람들은 아마 LLM을 훈련과 실력 향상에 사용할 것임

• 이 글은 회귀를 언급한 댓글을 많이 인용하지만, 분석 자체는 회귀가 아니라 버그 리포트만 측정함. 버그가 도입된 릴리스가 아니라 보고된 릴리스에 버그를 연결하고, 릴리스의 심각도는 커밋 수로 재면서 릴리스 기간이나 배포판 채택 같은 명확한 요인은 빼고 있음
  이게 어떻게 말이 되는지 모르겠음

• 개인적으로는 LLM을 쓰는 프로젝트를 피함. 실질적인 이유가 있어서라기보다 그냥 매우 꺼림칙하기 때문이고, 누군가 “kek”나 “fren” 같은 말을 쓰면 별 이유 없이도 더는 상호작용하고 싶지 않다는 신호로 받아들이는 것과 비슷함
  지금 LLM 사용을 싫어하는 이유로 나오는 설명들은 거꾸로 붙인 합리화처럼 느껴짐. 윤리, 품질 같은 현재의 우려는 맞지만, 그런 문제가 해결된다고 해서 나 같은 AI 반대 성향 사람들이 갑자기 괜찮아질 것 같지는 않음
  그래서 “AGENTS.md”, Claude 공동 작성 커밋 등이 있는 프로젝트는 구체적 이유 없이 피함. 그냥 불쾌하고 취향에 안 맞으며, 버그가 있든 없든 상관없음. 다른 사람들도 비슷하게 느끼는 경우가 있을 것 같음

• 글쓴이에게 말하자면, 첫째로 판타지는 말임. 실제로는 말에서 멈췄다고 주장하는 셈이거나, 적어도 비언어적 확대가 있었다고 주장하지는 않는 것임
  둘째로 이런 주장을 하려면 가까운 통계 전문가에게 어떻게 뒷받침할 수 있는지 물어봐야 함. 몇 사람이 그런 글을 올렸다는 것만으로 그것이 “전형적”이라는 주장을 의미 있게 뒷받침하지 못함
  내가 통계로 뒷받침하지 않은 일화적 관찰로는, “AI 반대” 사용자들은 LLM이 도움이 안 되는 곳에 끼어드는 것을 대체로 폭력적으로 느끼기보다 슬퍼하는 쪽에 가까움

  • 가끔 매우 장황하고 자세한 글로 LLM 반대자 중 일부, 보통 LLM에 감정적·사회적으로 반응하는 일부를 반박하는 글을 봄. 그런 글은 이유를 명확히 설명하긴 어렵지만 매우 불성실하게 느껴지고, 약자를 때리는 느낌이 있음
    너무 자세해서 감정적 관점에서 반박하기 어렵고, 결국 “LLM이 문제가 아니라 제대로 쓰면 증폭 장치가 된다. AI 반대자들은 뭘 모르는 것이고 뒤처질까 봐 겁먹었을 뿐이다”로 끝나는 듯함
    rsync 관리자들의 작업을 논쟁으로 깎아내리고 싶지도 않아서, 내가 어떻게 설득력 있는 반론을 만들 수 있을지 모르겠음
    여기 통계는 오픈소스 유지보수 관점에서 흥미로울 수 있지만 결론이 이상하게 한쪽으로 기울어져 있고, GitHub식 오픈소스가 내가 기여하고 싶은 형태가 아니라는 느낌이 남음
    그래도 rsync 저장소에서 관리자에게 집단으로 몰려든 건 전혀 좋지 않다고 봄
  • 공개적인 폭력 판타지를 괜찮지 않다고 부르는 건 맞음. 그런 건 문명으로서 지향할 만한 일이 아님. 다만 글쓴이가 그걸 “전형적”이라고 부른 부분은 일반화라서 거슬림
    일화적 관찰에 관해서는 이 만화가 맞는 말 같음. 구체적이고 측정 가능한 주장을 보는 걸 좋아하는데, 숫자를 좋아해서이기도 하고 온라인 토론이 마지막 컷의 이상적 세계에 조금이라도 가까워지도록 만들기 때문임

• 분석은 고맙지만 방법론에는 확신이 안 듦. 커밋마다 핵심 코드, 즉 테스트나 문서가 아닌 코드의 변경 줄 수를 곱한 차이 단위 버그 수 같은 지표와, 릴리스 후 특정 버그 수에 도달하는 데 걸리는 시간 분석이 궁금함
  다만 이번 릴리스가 다른 릴리스보다 훨씬 많은 관심을 받아 버그가 더 많이 보고됐을 가능성이 높기 때문에, 아주 설득력 있는 지표를 만들기는 어려워 보임. “릴리스 후 몇 주 기준으로 전형적인가?” 같은 질문도 별로 유용하지 않을 수 있음