제발 이 소프트웨어를 바이브로 망치지 말아 주세요
(github.com/RsyncProject)- 이 이슈는 Closed 상태로 끝났고, 본문에 재현 절차나 수정 제안이 없는 문제 제기성 글이어서 연결된 브랜치·PR·마일스톤은 보이지 않음
- 원래 제기는 rsync에 AI가 관여한 변경이 들어가며 안정성이 흔들린다는 우려였고, 본문은 텍스트 설명 없이 이미지 중심으로 올라옴
- 사용자는 log2ram이 rsync를 쓰는 탓에 3D 프린터가 100% CPU로 동작했다고 보고하며, AI가 이 버그를 로봇에 유입한 셈이라고 표현함
- 다른 사용자는 rsync가 새 기능이나 재작성보다 보안 업데이트와 버그 수정만 필요한 안정적인 도구였고, 최근 두 패치 릴리스에서 기존 기능을 바꾸지 않아야 할 문제가 생겼다고 봄
- DFIR 업무에 rsync를 쓰는 사용자는 AI가 업데이트에 관여한다는 사실만으로도 조직 정책상 “AI 도구”로 취급되어 추가 검토가 필요해졌다고 설명함
- 반대편에서는 이슈 트래커가 바이럴성 불만 표출 공간이 아니며, 구체적인 버그 리포트나 재현 절차가 없으면 Discussions로 옮기거나 포크해야 한다고 맞섬
- 핵심 충돌은 “무료 소프트웨어이니 마음에 들지 않으면 포크하라”는 입장과, rsync가 이미 핵심 인프라 도구라서 다운스트림의 핀ning·포크 논의 자체가 문제 신호라는 입장 사이에서 커짐
- 일부 사용자는 Rust 재작성이나 포크를 언급했지만, 다른 사용자는 rsync가 사랑받는 이유가 안정성과 그대로 동작함에 있으며 재작성은 별도 프로젝트라고 선을 그음
- AI 사용 옹호 쪽에서는 모든 AI 언급을 “바이브 슬롭”으로 몰면 안 되고, 3월 이후 커밋 로그를 직접 감사해 변경 이유를 확인해야 한다고 요구함
- kaithar는 최근 작업이 미초기화 메모리 읽기, 와이어 프로토콜 오버/언더플로, 32비트 타임스탬프, C 표준 관련 조정 등 버그·보안 결함 수정과 하드닝을 포함한다고 설명함
- 같은 댓글은 3.4.1 같은 오래된 릴리스에 고정하면 여러 CVE가 있는 버전에 머물 수 있고, 회귀는 테스트가 놓친 엣지 케이스에서 발생할 수 있다고 반박함
- 결론적으로 이슈는 구체적 버그 수정으로 수렴하지 못하고, rsync 같은 장기 안정 인프라에서 AI 보조 개발의 신뢰·감사·거버넌스를 어떻게 다룰지에 대한 논쟁으로 남음
댓글과 토론
Hacker News 의견들
-
이 집단 몰이는 정말 기괴하고, 일부는 비이성적으로 행동하는 듯함. 이 싸움에서 “이기고” 싶어지는 동기는 어느 정도 이해하지만, 이런 방식은 전혀 아니고 그냥 광신도처럼 보이게 만들 뿐임
이슈 페이지에서 regression을 검색해 17개 결과를 훑는 데 5분이면 충분함. GitHub 이전에 쓰던 추적기에는 더 있을 수도 있음
이런 행동은 매우 어리석고, 사람들은 가능한 모든 것에 매달려 AI 혐오를 정당화하려는 듯함. AI 이전에도 사람들은 실수했다는 사실을 잊은 것처럼 보임
AI가 rsync의 미해결 이슈를 유의미하게 늘렸다는 증거가 있다면 보여주면 좋겠음. 그러면 기꺼이 생각을 바꾸겠음- “사람들이 AI를 싫어해서 가능한 모든 것에 매달린다”는 식으로만 볼 일은 아님. 어떤 대상에 문제가 있다고 느끼면 사람들은 행동하게 됨
이번 커밋의 직접 원인이 아닐 수는 있지만, 다른 누적된 문제에 반응하는 것일 수 있고 그 자체로 고려해야 함
“AI가 [문화적 비유] 이후 최고”라는 식의 이야기를 억지로 삼켜야 하는 데 지친 사람들이 모든 지푸라기라도 붙잡고 맞서려는 것 같고, 그건 꽤 정상적인 반응이라고 봄 - 밈 이미지로 몰려드는 방식은 기괴함. 다만 사용된 언어 자체는 Tridgell이 LKML에서 익숙하게 보던 수준이라 그게 핵심 걱정은 아님
사용자가 AI를 신뢰하지 않는다는 우려를 아무도 말하지 않으면 유지보수자가 어떻게 알 수 있겠나? rsync는 매우 안정적이었음. 사람들이 조용히 Openrsync로 옮기고 아무 말도 하지 말아야 하나? - 매우 안정적이고 신뢰받던 도구가 갑자기 내리막을 걷기 시작했다면 사람들이 화내는 건 충분히 정당하다고 봄. Linux Mint Timeshift에는 rsync 이슈 페이지에 열려 있는 여러 회귀를 정리한 이슈가 있고, 이들은 vibecoding 이후에만 도입된 것으로 보임 (https://github.com/linuxmint/timeshift/issues/548)
그중 한 링크는 하위 배포판에서 보고된 버그를 더 크게 모은 곳으로 이어짐 (https://github.com/void-linux/void-packages/issues/60825)
vibecoding 소프트웨어의 평판을 생각하면 분노는 매우 합리적임. 좋아하는 전문가들조차 “버그를 안 내게 하려면 아주 특정한 방식으로 다뤄야 하고, 아마 도메인을 그려보기 위한 0버전에만 쓰는 게 좋다”고 말하는 수준임
그런데 업계 표준의 백업 핵심 도구가 “기능을 더 추가”하려는 유지보수자의 의도로, 명백히 안전하지 않은 방식으로 사용자 밑의 카펫을 빼버리는 상황임
Timeshift 스레드에도 “rsync 업데이트 후 일일 백업 중 CPU 사용량이 너무 심해져서 timeshift가 영원히 도는 걸 멈춰야 했다”는 내용이 있음
다르게 말하면, 사람들이 백업과 데이터를 맡겼던 도구가 엄청난 수의 회귀와 새 버그로 백업 인프라 전체를 깨뜨리고 있고, 그 이유가 핵심 개발자가 vibecoding을 하고 있기 때문이라 좌절하고 화난 것임
Simon Wilson 같은 vibecoding 전문가도 이것이 “특정 방식으로 도구를 다룰 때만” 가능하다고 명시하는데, 이 유지보수자는 그렇게 하지 않거나 그 말이 사실이 아닌 셈임
해당 스레드를 실제로 읽고 두 사람이 다투는 부분만 훑지 않으면, 산업 및 정부 환경의 사용자들이 이 소프트웨어를 업데이트하기 위해 전체 절차를 다시 거쳐야 한다는 보고가 여러 개 있음. 소프트웨어가 즉시 신뢰할 수 없게 되어 사용자에게 직접 피해를 주고, 해당 소프트웨어의 존재 이유를 무너뜨렸기 때문임
나도 이 소프트웨어로 500GB 이상 백업을 맡겼다면 화났을 것 같고, 회사가 백업을 꾸준히 테스트하지 않다가 1천만 달러 규모의 데이터 손실을 겪기 전까지 드러나지 않을 문제가 얼마나 더 들어갔을지 궁금함 - AI 기피 행동 증후군 같음
- AI는 이미 당파적 정치 쟁점이 되었고, 그에 따르는 결과도 모두 따라옴. 이쯤 되면 해가 동쪽에서 뜬다고 불평하는 것과 비슷함 :(
- “사람들이 AI를 싫어해서 가능한 모든 것에 매달린다”는 식으로만 볼 일은 아님. 어떤 대상에 문제가 있다고 느끼면 사람들은 행동하게 됨
-
정말 이해가 안 됨
수많은 사람과 서비스가 쓰는 견고한 소프트웨어가 있음. 잘 작동하고, 제 역할을 하며, 가끔 사소한 버그 수정 업데이트만 있으면 됨
여기서 왜 AI가 필요한가?
게다가 왜 사람들이 “포크해서 이전 버전을 써라”고 말하는지도 모르겠음. 오히려 반대여야 함. younamethetool-ai 같은 병렬 포크를 만들고 원본은 건드리지 말아야 함
이제 내 시스템 도구 전체를 포크해서 유지해야 하나?- “왜 여기서 AI가 필요하냐”에 대해서는, 여러 이슈 댓글에서도 말하듯 오픈소스 패키지에 기여하는 개발자가 작업 방식을 결정할 일임
증거 없이 이슈 추적기에서 AI가 소프트웨어를 망친다고 불평하는 건 Hacker News에서 자주 논의되는 오픈소스 기여자 괴롭힘의 한 형태임 [1]
https://github.com/RsyncProject/rsync/issues/929#issuecommen...
“이슈 추적기는 바이럴 소셜 미디어 게시물을 수확하는 곳이 아니다. 실행 가능한 버그를 보고하거나 직접 포크해라. 개발자 선택에 대해 분출하는 건 생산적이지 않다”
https://github.com/RsyncProject/rsync/issues/929#issuecommen...
“@II-Paulus-II 멈춰라. 너는 아무것도 모른다. 손으로 기능을 0개 배포했다. 네 코드에 의존한 사람은 아무도 없다. 너는 장난감 프로젝트와 스크립트를 처음부터 쓴다는 도덕적 우위에 기대어 숨어 있는 ‘AI가 이걸 썼다’ 삿대질러일 뿐이다. 배포도 못 하고, 적응도 못 하고, 이슈 추적기가 이런 태도를 보일 장소가 아니라는 것도 모른다”
[1] https://news.ycombinator.com/item?id=43077833 - “이 안정적이고 신뢰할 수 있는 일꾼을 망치지 말아 달라”는 감정에는 100% 동의함
자세히 읽지는 않았지만 “이번 릴리스에서 6개의 CVE가 수정됐다. 여섯 개 모두 VulnCheck가 CNA로 배정했다. 영향받는 버전은 모든 경우 3.4.2 이하다”라는 문장은 “왜?”에 대한 꽤 강한 답으로 보임
https://download.samba.org/pub/rsync/NEWS#3.4.3 - 많은 오픈소스 개발자가 감당해야 하는 권리 의식이 안타깝게 느껴짐. 취미로 무료로 무언가를 만들었는데, 자신들이 마음에 들지 않는 일을 했다고 돈 한 푼 낸 적 없는 화난 무리들을 상대해야 한다고 상상해보면 됨
첫 반응은 당연히 다른 데로 꺼지라고 말하고 싶을 것 같음 - 그건 유지보수자가 결정할 일 아닌가? AI로 테스트를 더 작성하겠다고 정하면 그렇게 하면 됨. 대중에게 빚진 게 있는 것도 아님
“대중”이 프로젝트를 인수해 유지하고 싶다면 포크할 수 있지만, 감사받기 어려운 일임 - 유지보수자가 왜 자기 저장소를 직접 포크해야 하나? 말도 안 됨. 예전 저장소는 누가 유지할 건가?
또 오픈소스 프로젝트에서 어떤 도구를 쓰는지 바꾸는 데 이유가 필요하지도 않고, 그 이유를 당신에게 빚진 것도 아님
- “왜 여기서 AI가 필요하냐”에 대해서는, 여러 이슈 댓글에서도 말하듯 오픈소스 패키지에 기여하는 개발자가 작업 방식을 결정할 일임
-
그 이슈가 열린 방식은 정말 불쾌하지만, 유지보수자들이 rsync에 AI를 풀어놓은 것처럼 보이는 건 이해가 안 됨. 왜 그랬을까? 이미 명성과 신뢰를 얻었고, 특정 틈새의 선두이며, 시장 압력에서도 벗어나 있고, 사람들은 그 도구를 좋아하며, 해야 할 일을 정확히 잘 해내는 상황에서 왜 비교적 실험적인 잡동사니를 시도하는가?
마치 Matrix에서 원시적인 인간 정신은 낙원을 받아들이지 못한다는 짧은 독백 같음. 완벽한 도구를 썼고, 이겼고, 틈새에서 거의 대체 불가능하며, 신뢰할 수 있고, 비유적으로는 누구나 아는 이름이 됐음. 그걸 도박하거나 건드리는 건 누구에게도 말이 안 되고 정말 어리둥절함
그래도 공식 이슈 추적기에서 그렇게 하는 건 여전히 정말 불쾌한 행동임. 태도도 나쁘고, 선의도 없어 보임- 몇 년 전이었다면 유지보수자들을 적극적으로 옹호했을 것 같음. 어떤 오픈소스 프로젝트든 유지하는 건 고되고 감사받기 힘든 일이고, rsync처럼 확립된 프로젝트라면 더더욱 그렇기 때문임
하지만 지금은 AI가 어디에서도 순긍정이라고 보이지 않고, 생성형 AI 사용에 대한 이 반발을 대중의 좋은 방향 수정으로 보게 됨
LLM 사용의 즉각적 만족감에 대해 다룬 글들이 있는데, 이 도구를 쓰는 사람들과 더 많이 상호작용할수록 이게 정말 핵심 문제일 수 있다고 생각함. 우리의 생물학이 감당하지 못함
원래는 매우 똑똑한 사람들이 슬롯머신이 말해줬다는 이유로 정말 어리석은 일을 하고, 슬롯머신이 실패했을 때는 무력해지도록 훈련까지 받아버린 모습을 봄
나는 발전을 보지 못하는 러다이트로 취급받는데, 동료들이 의미 없는 벤치마크를 만들고 AI로 만든 아름다운 그래프를 붙이는 걸 보게 됨
그러면 웃으며 좋은 작업인 척하거나, 벤치가 상수로 박힌 구간을 테스트하고 있어서 무의미하다고 꾸짖거나 둘 중 하나를 골라야 함. 어느 쪽이든 그들을 똑똑한 동료가 아니라 7살짜리처럼 대하는 꼴이 됨 - “왜?”에 대한 답은 모두가, 이 포럼까지 포함해 LLM의 즉각적 만족감에 중독됐기 때문임. 출력물을 훑어보면 자신이 생각한 대로 동작한다고 믿는 순수한 오만임
- 이 의견은 이슈만 보고 내린 건가, 아니면 실제 증거가 있나? 이 GitHub 링크는 흥미롭긴 하지만, “Claude” 외에 드라마가 무엇인지에 대한 맥락이 거의 없음
rsync 유지보수자들이 완벽하고 책임감 있는 유지보수자부터 무능한 아이들까지 어느 지점에 있든, 우리는 사실 알 수 없음 - rsync에 AI를 풀어놓는 게 이해 안 된다는 데 동의하고, 이슈 제기 방식이 정말 불쾌했다는 데도 동의함
다만 약간 주제를 벗어날 위험을 감수하고 이런 생각이 듦. Rsync 같은 성숙한 소프트웨어가 변경된 코드 줄 수 같은 움직임을 필요로 하지 않는다는 점은 제외하고, 유지보수자들이 프로젝트를 최선의 의도로 관리한다고 가정해보자
이 일이 오픈소스에서 벌어지고 있다면, 폐쇄형 소프트웨어 품질은 어떤 상태일까?
AI 사용량, 즉 입력이 성공 지표처럼 직원 평가에 들어가고, 사람들은 AI로 인한 대량 해고 위협에 패닉 상태임
아찔함 - 정말 이해 안 되는 건, Claude를 어떻게 썼는지 당신도 나도 전혀 모르면서 rsync에 AI를 풀어놨다고 말하는 것임
https://github.com/RsyncProject/rsync/issues/929#issuecommen...가 보여주는 건 더 이상 오래된 Darwin과 Linux < 5.6에서 동작하지 않는다는 점인데, Linux 5.6은 2020년에 폐기 예정이 된 버전임. 그 외 몇몇 버그도 있음
유지보수자가 오래된 시스템을 지원하고, 변경이 미칠 영향을 모두 알 것이라고 기대할 수는 없음. AI로 했든 손으로 했든 마찬가지임
- 몇 년 전이었다면 유지보수자들을 적극적으로 옹호했을 것 같음. 어떤 오픈소스 프로젝트든 유지하는 건 고되고 감사받기 힘든 일이고, rsync처럼 확립된 프로젝트라면 더더욱 그렇기 때문임
-
참고로 버그 자체는 Claude Code가 만든 30656c5e에서 들어갔고, 아마 부적절한 사람의 리뷰와 테스트가 함께 있었던 듯함
https://github.com/RsyncProject/rsync/commit/30656c5e
누군가 AI를 써서 최근 rsync를 이분 탐색한 것: https://github.com/themgt/rsync-compare-link-dest-341-343-re...
누군가 더 많은 Claude Code로 고치려는 시도: https://github.com/RsyncProject/rsync/pull/930
관련 티켓: https://github.com/RsyncProject/rsync/issues/915
30656c5e 직전 커밋에 회귀 테스트를 더 넣고, 기능을 유지한 채 앞으로 리베이스하는 걸 추천함- 그러면 원래 불만은 그냥 틀린 것처럼 보임
이건 “원치 않는 새 기능”이 아니었음. Tridge는 버그 보고와 관련된 보안 이슈를 고치고 있었음. 공감함. 우리 모두 보안 이슈에 얻어맞고 있음. 고치는 건 선택 사항이 아님
10년 된 소프트웨어로 돌아가 이걸 처리하는 일이 즐겁다고는 못 하겠고, 그래서 tridge가 노력하고 있다는 점이 인상적임
나도 이 혼란을 넘기기 위해 LLM을 쓰는 죄가 있음. tridge가 뭘 하는지는 모르지만, 나는 LLM이 뱉은 코드 한 줄 한 줄을 확인함. 그래도 버그가 새어 들어갈 위험은 분명히 큼
오랫동안 그 코드를 보지 않았고, 예전만큼 익숙하지도 않음. 그래서 버그가 새어 들어가는 건 크게 놀랄 일이 아님
이 폭발에서 이상한 점은 원래 불만을 낸 사람이 자기 백업 시스템을 매우 보호하려는 듯한데, tridge의 커밋은 고작 2주 전이었다는 것임. tridge가 뛰어나다는 건 알지만, 이런 건 당연히 알파 소프트웨어처럼 다뤄야 하지 않나? 무슨 생각이었을까? 그 사람도 신뢰할 수 있는 시스템을 만드는 법을 조금 배워야 할지도 모름
- 그러면 원래 불만은 그냥 틀린 것처럼 보임
-
몇 년 전이라면 이런 종류의 글이 Hacker News 메인에 올라올 확률은 거의 0에 가까웠을 것임. 내용의 옳고 그름과 무관하게, 여기에는 어떤 행동이 받아들일 수 없는지 이해하지 못하는 평범한 대중이 가득하지 않았기 때문임
여기서 말하는 건 이슈의 폭력적인 언어임. 그런데 이제 우리는 가장 뻔한 것도 구분하지 못하는 사람들에게 둘러싸여 있음- 어떤 트위터류 서비스의 스크린샷 하나와, 버그를 찾았다는 “누군지도 모를 사람”을 근거로 “Please Do Not Vibe Fuck Up This Software”라는 이슈를 여는 건 전혀 적절하지 않음
유지보수자에게 프로젝트 방향에 동의하지 않는다고 말하는 방식이 아님. 이 이슈는 완전히 쓸모없음. 차라리 “vibe coded 때문에 망가진” 버그 보고가 더 나았을 것임
이 말이 핵심을 찔렀음. 어떤 버그 보고도 주장된 --compare-dest= 회귀를 문서화하려는 시도조차 하지 않음. Ctrl-F를 해봐도 “compare-dest”를 다시 언급한 사람이 보이지 않았음
쓸모없는 AI 분노 댓글을 다는 사람들은 Opus 4.8에게 rsync 3.4.3과 3.4.1을 돌려서 회귀를 철저히 문서화하고, 깨진 커밋을 git bisect로 찾아 1000배 더 전문적이고 유용한 버그 보고서를 만들라고 시킬 수도 있었음
사회가 인간의 작업을 AI 작업보다 더 가치 있게 봐주길 원한다면, 인간만이 할 수 있는 바보 같은 행동은 피하는 게 좋음 - “normies” 같은 깔보는 표현을 쓰는 것에도 같은 말을 할 수 있음
메인에 올라온 이유는, 중요한 작업에 매일 쓰는 소프트웨어에 대해 다른 사람들도 비슷하게 느끼기 때문일 가능성이 있지 않나?
GitHub 이슈가 진부하고, 분명 감사받기 힘든 일인 건 맞지만, 현실적으로 rsync는 민감한 파이프라인 다수의 초석임 - 그 이슈를 “폭력적”이라고 묘사하는 건 이상함. 조금 읽어보면 규모가 크고, 관련된 누구도 도덕적 우위를 갖고 있지 않다는 게 분명함
정말 주제에서 벗어났다고 믿는다면 정중한 대응은 이슈를 닫는 것임
무엇이 그렇게 명백하다는 건지 아직 잘 모르겠음. 내게는 “멈춰라. 너는 아무것도 모른다. 손으로 기능을 0개 배포했다. 네 코드에 의존한 사람은 아무도 없다”가 “please do not vibe fuckup this software”보다 훨씬 폭력적으로 보임 - 내가 너무 회의적으로 변한 걸지도 모르겠음. HN과 GitHub 이슈의 댓글 중 점점 더 많은 수가 다른 사람들, 유지보수자까지 포함해 분노를 유도하는 봇처럼 느껴짐
- 이 댓글은 양쪽 모두에 적용될 만큼 모호해서 좋음 :)
- 어떤 트위터류 서비스의 스크린샷 하나와, 버그를 찾았다는 “누군지도 모를 사람”을 근거로 “Please Do Not Vibe Fuck Up This Software”라는 이슈를 여는 건 전혀 적절하지 않음
-
그 이슈 스레드에서 누가 실제로 이슈를 설명하긴 했나? 재현 단계, 기대 동작과 실제 동작 같은 것 말임
이건 이슈 추적기에 올라온 것임. “커밋 메시지에 Claude가 언급되어 있고, Bluesky의 어떤 사람이 자신이 겪은 불특정 문제가 그 커밋들과 관련 있다고 생각한다”는 건 실행 가능한 이슈가 아님
나머지 논의를 모두 제쳐두고, 내 프로젝트였다면 “재현 정보 부족”으로 닫고 잠갔을 것임. AI, 포크, 분노 발산에 관한 일반 토론은 더 나은 장소가 있음- 실제 이슈는 대략 이렇다고 보임
Linux < 5.6 사용자는 GitHub에서 빌드할 수 없음. 내게는 꽤 사소한 회귀로 보임. 5.6의 유지관리 버전, 주로 확장 보안 버전을 쓰는 사람들은 배포판 유지보수자가 빌드 실패를 발견해 적시에 고칠 수 있을 것임
경로 순회 공격에 대한 강화가 chroot 없이 네이티브 rsync 프로토콜을 쓰는 사용자에게 실패를 일으킴. 아이러니하게도 chroot = no는 강하게 권장되지 않음
네이티브 rsync를 자동화된 방식으로 쓰면 안 되고, 아예 쓰지 말라고 권하고 싶을 수도 있음. 해당 커밋이 고치는 CVE는 정확히 이 사용 사례에 적용됨
https://www.cve.org/CVERecord?id=CVE-2026-29518
데몬 + no chroot가 필요함. “daemon runs with elevated privileges. This vulnerability can only be triggered if the chroot setting is false.”
따라서 영향을 받은 워크플로는 가장 취약한 워크플로인데, 사람들이 버전을 되돌리라고 권하고 있는 셈임
게다가 회귀 테스트가 이걸 잡았어야 했다면, 그 테스트는 이전에 작성되어 있었어야 함
- 실제 이슈는 대략 이렇다고 보임
-
일부는 FOSS 프로젝트에 대해 잊은 듯함
“15. 보증의 부인
관련 법이 허용하는 한, 이 프로그램에는 보증이 없다. 서면으로 달리 명시되지 않는 한 저작권자 및/또는 기타 당사자는 프로그램을 ‘있는 그대로’ 제공하며, 명시적이든 묵시적이든 어떠한 보증도 하지 않는다. 여기에는 상품성이나 특정 목적 적합성에 대한 묵시적 보증도 포함되지만 이에 한정되지 않는다. 프로그램의 품질과 성능에 대한 모든 위험은 당신에게 있다. 프로그램에 결함이 있을 경우 필요한 서비스, 수리, 수정 비용은 당신이 부담한다”- 여기 OSS 사용자 면책 조항도 있음
나는 프로젝트가 내린 모든 결정, 커밋, 패치, 마케팅, 기타 결정에 대해 불평하고, 투덜대고, 비판하고, 화내거나, 달리 논평할 권리를 보유한다. 이러한 논평은 어떤 목적에 대한 적합성도 보증하지 않으며, 올바르거나 유용하거나 친절하다는 묵시적 보증도 포함하지 않는다. 내 논평이 원치 않는 것으로 판명될 경우, 당신은 그걸 해가 들지 않는 곳에 꽂아둘 권리를 보유한다
원치 않는 FOSS 프로젝트 비판을 마주칠 때 참고할 수 있도록 이 면책 조항을 출력해도 좋음
사람들이 “그들은 원하는 대로 할 수 있다”는 태도가 양방향이라는 걸 왜 이해하지 못하는지 모르겠음. 사용자도 원하는 대로 할 수 있음. 마음에 안 들면 표현할 수 있음 - 법적으로 그렇게 할 수 있다는 건 맞지만, 그렇게 하면 그냥 나쁜 사람이라는 것임
이슈 댓글 중 하나가 이렇게 말함
“노숙자에게 무료 수프를 준다고 해서 거기에 오줌을 싸도 되는 건 아니다” - “보증 없음”은 “불평 없음”과 같지 않음. 그렇지 않다면 이슈 추적기와 토론 섹션이 있을 이유가 없음
해당 이슈는 이미 엉망이 됐고, 당신의 논지도 거기서 이미 나왔음. 모두가 더 잘 처리할 수 있었겠지만, 법률 문구를 맹목적으로 인용한다고 해결되거나 나아지지는 않음
- 여기 OSS 사용자 면책 조항도 있음
-
이 주제로 HN 글을 세 번째 읽고 있음. 매번 같은 트윗, 또는 Mastodon/Bluesky류에서 뭐라고 부르는 그 게시물만 반복됨. 누가 실제로 문제를 디버깅하긴 했나?
원인이 엉성하게 생성된 코드였나, 아니면 진짜 보안 수정이 우연히 깨뜨린 것인가? 사람도 똑같이 했을 수 있는 방식으로 말임 -
이 반AI 히스테리는 전형적인 도덕적 공황임
- 어떤 것을 AI가 만든 것으로 식별함
- 그 제작에 관련됐을 수 있는 사람을 공격하고 배척함
모든 도덕적 공황이 그렇듯, 1번이 사실인지 여부는 완전히 부차적임. 핵심은 2번에서 거의 성적인 해방감을 얻는 것임
이 경우 rsync에 AI 생성 코드가 있다는 건 알고 있음. 지금쯤 유용한 소프트웨어 대부분이 그렇듯이. 하지만 온라인에서는 매일 마녀사냥을 보게 되고, 모든 마녀사냥이 그렇듯 고발이 사실인지는 별로 중요하지 않음. 히스테리 자체가 목적임
- 지금 넓게 무슨 일이 벌어지고 있는지, 그리고 이 스레드에서 무슨 일이 일어나는지 이해하기를 거부하고, 계속 이해하지 않아도 된다는 신호를 보내는 건 위험함
AI 주변에서 나타나는 분노는 대중이 잘못 알고 있거나 메시지가 잘못됐기 때문이 아니라 물리적 현실의 문제임
이 한 가지가 대량 해고의 구실로 쓰이고 있고, 기술 CEO들은 거의 매일 다른 모든 사람의 일자리까지 빼앗겠다고 말하며, 대형 클라우드 기업들은 방 안의 산소를 전부 빨아들이고 있음. 게임 업계조차 안전하지 않았음
이걸 “그냥 전형적인 도덕적 공황”이라고 보는 태도는 바다가 어느 방향으로 물러나는지 보고도 그쪽으로 정면으로 뛰어드는 것과 같음 - “핵심은 2번에서 거의 성적인 해방감을 얻는 것” 같은 느슨한 사고를 보면 답변을 진지하게 받아들이기 어려움
더 읽어보면 본인도 “마녀사냥”, “히스테리” 같은 감정적 언어를 쓰고 있음
이게 정말 마녀사냥인가? 그리고 인터넷 너머의 사람들이 성적 해방감에 가까워지는지 알 수 있나?
다른 사람들의 감정적 언어와 느슨한 사고에 본인도 같은 방식으로 반응하는 것 아닌가?
-
언제부터 GitHub 이슈가 다른 플랫폼 게시물의 스크린샷을 올리는 장소가 됐나?
이런 행동은 밈이나 오락성 콘텐츠를 올리는 곳에서만 봤음
실행 가능한 버그 보고나 기능 요청이 없음. 텍스트 버전도 없음. 원본 게시물 링크조차 없음
이걸 올린 사람은 GitHub Issues를 자기 개인 Twitter 계정으로 착각한 건가?- 스크린샷을 올리는 건 자동 LLM 응답을 막는 더 쉬운 방법임. 대부분은 비용이 더 싼 비전 없는 텍스트 모델을 쓰기 때문임