rsync와 분노

• rsync 유지보수는 보안 보고서 폭증과 AI 활용 논란이 겹치며 테스트, 코드 커버리지, 다중 플랫폼 CI, 보안 스캔, 방어 심층화가 필요해진 상황임
• 새 Python 테스트 스위트는 기존 셸 스크립트 구조를 대체하되 설계와 검증 계획은 유지관리자가 맡고, Claude, Codex, Gemini는 반복 작업 보조에 쓰인 방식임
• 3.4.3 릴리스는 보안 수정을 우선하면서 기존 테스트와 수동 테스트가 잡지 못한 일부 유효하지만 특이한 사용 사례에서 회귀가 발생한 릴리스였음
• pytest는 다른 프로젝트에서 많이 사용했지만 rsync 테스트 스위트의 특정 요구에는 맞지 않아 별도 접근을 설계한 선택이며, LLM은 조심스럽게 써야 하지만 유용한 도구라는 판단임
• 향후 방향은 회귀를 완화할 3.4.4와 큰 보안 변경을 담을 3.5.0 사이에서 결정 중이며, openrsync는 새 테스트 스위트에서 98개 중 85개를 실패한 상태임

---

보안 보고서 폭증과 방어 강화

• rsync 유지관리자는 최근 오픈소스 패키지 개발자들처럼 보안 보고서가 몰려드는 상황을 겪는 중이며, 그중 많은 보고서가 AI 생성물이지만 신중하고 수준 높은 수동 분석도 일부 존재함
• 보고서 증가가 심해지면서 rsync에는 더 철저한 테스트 스위트, 코드 커버리지 분석, 더 많은 플랫폼의 CI 테스트, 의도적인 보안 이슈 스캔, 방어 심층화 기법이 필요해진 상태임
• 유지관리자는 은퇴했고 항해를 더 하고 싶지만, 필요한 작업량 때문에 여러 AI 도구를 사용했으며 그 선택을 후회하지 않는 입장임

Python 테스트 스위트와 AI 보조 작업

• 기존 셸 스크립트 기반 rsync 테스트 스위트는 Python으로 다시 작성됐고, 핵심 설계와 검증 계획은 유지관리자가 직접 맡은 구조임
• Claude는 반복 작업에 쓰였고 Codex와 Gemini는 교차 확인에 쓰였으며, 단순히 “테스트 스위트를 Python으로 변환”하라고 맡긴 방식은 아니었음
• 유지관리자는 모든 부분을 직접 검토했고, 많은 CI 시간을 들여 맞췄으며, CI 대기 시간을 줄이기 위해 이후에는 여러 로컬 VM에서 대부분의 테스트를 수행하는 방식으로 이동함
• 커밋 기록의 co-authored by claude 표시는 전체 소프트웨어 엔지니어링 작업 중 일부만 드러난 결과라는 판단임

LLM 논쟁, pytest 선택, 3.4.3 회귀

• LLM은 작동 방식을 안다고 해서 쓸모없는 도구가 되는 것은 아니며, 조심해서 써야 하지만 현재 소프트웨어 엔지니어링과 IT 보안 유지보수 환경에서는 유용하다는 입장임
• rsync 3.4.3은 보안 이슈 수정을 우선하는 쪽으로 의도적으로 기운 릴리스였고, 그 과정에서 유효하지만 특이한 일부 사용 사례가 변경의 영향을 받은 상태임
• 영향을 받은 사용 사례들은 기존 rsync 테스트 스위트와 수동 테스트에 포함되지 않았으며, GitHub 저장소의 이슈와 PR로 보고된 회귀를 순차적으로 처리 중임
• pytest는 다른 프로젝트에서 많이 사용했지만, rsync 테스트 스위트에서 필요한 작업 일부가 pytest로는 매우 어렵다고 판단해 별도 테스트 접근을 설계한 선택임

다음 릴리스와 보안 테스트 확대

• 보안 보고서는 계속 들어오고 있으며, 현재 여러 CVE 작업이 진행 중임
• 시스템 개발 역량과 보안 지식을 갖춘 다른 개발자들이 합류했고, 일부는 최근의 분노가 계기가 되어 눈에 띄게 된 사람들임
• 다음 선택지는 일부 회귀를 완화하는 3.4.4와 훨씬 큰 변경을 담은 3.5.0 사이에 있으며, 3.5는 rsync 보안 기준을 크게 끌어올리지만 변화 규모가 큰 릴리스임
• 큰 변경 세트를 빠르게 적용하려면 rsync 같은 소프트웨어에 포괄적인 테스트 스위트가 필요했고, 새 테스트 스위트 재작성은 그 필요에서 나온 작업임
• 3.5 릴리스에는 보안 관련 이슈를 다루는 추가 테스트들이 들어갈 예정임

openrsync 비교와 코드 리뷰 요청

• openrsync를 특정 플랫폼용으로 패키징하겠다는 흐름에 대해, 새 rsync 테스트 스위트를 openrsync에 적용해볼 수 있다는 반응임
• 실행 예시는 다음 명령임

./runtests.py — rsync-bin=../openrsync/openrsync — use-tcp

• openrsync는 현재 98개 테스트 중 85개를 실패했으며, 많은 실패가 openrsync에 없는 기능 때문이지만 좋은 결과는 아니라는 평가임
• 분노를 더 표출하기보다 공개된 코드를 실제로 검토하고 건설적인 비판을 하는 쪽이 바람직하다는 요청임

[GN⁺]

Lobste.rs 의견들

• 인용문을 보면 작성자는 항해를 하고 싶은데도 프로젝트 유지보수에 압박감을 느끼고, LLM을 써서 둘 다 할 수 있는 해법을 본 것처럼 읽힘
  은퇴와 항해를 즐기느라 버그를 고치지 않는 것도 괜찮고, 오픈소스 프로젝트의 버그를 고치지 않는 것도 괜찮음. 다만 그 점을 공개적이고 투명하게 밝히면 됨. 예전 말처럼 “패치 환영”이면 충분함. 특히 자원이 많은 회사들이 그 프로젝트에 의존한다면 더더욱 그렇다
  더 많은 유지보수자와 개발자가 오픈소스 유지보수에 LLM의 “도움”을 받아야 한다는 압박 없이 은퇴와 항해를 즐겼으면 좋겠음. 그래도 rsync 프로젝트에서 LLM을 실험하고 싶다면 그건 그의 선택임. 다른 사람들이, 나를 포함해, 동의하지 않더라도 마찬가지
  이유가 무엇이든 오픈소스 개발자를 괴롭히는 사람들은 무료 오픈소스 소프트웨어가 제품이 아니라 선물이라는 점을 잊는 듯함

  • 사람들이 자기 시간을 써서 좋은 오픈소스 소프트웨어를 유지보수하는 것도 괜찮음
    바깥에서 구경만 하는 사람들은 마음에 안 들면 포크하면 됨. Andrew는 그 프로젝트에서 원하는 방식으로 일할 수 있고, 우리의 논평과 의견이 꼭 필요한 것도 아님
  • 참고로 Tridge는 이전 유지보수자가 어느 정도 번아웃된 뒤 rsync로 돌아왔으니, 그런 해석이 완전히 빗나간 건 아님
    희망적인 부분은 장기적으로 rsync 유지보수를 맡을 다른 사람이 나올 수도 있다는 점임. Tridge는 이미 예전에 새 유지보수자에게 넘긴 적이 있음
    OpenJS Foundation이 일부 프로젝트에 자금과 전환 지원을 제공해 단일 유지보수자 체제에서 팀 유지보수로 옮긴 사례에 대한 발표를 듣고 LWN에 글을 썼고, 오늘 공개될 예정임. rsync 같은 프로젝트에는 이런 지원이 훨씬 더 많이 필요함
  • 작성자가 공감을 구하면서 자신도 여러 욕구가 충돌하는 사람이고, 특히 보안 이슈가 오픈소스 유지보수자에게 큰 부담이라는 점을 상기시킨 것으로 해석했음
    보안 이슈는 압박이 크고, 노출도가 높으며, 유지보수자가 흥미를 느끼는 프로젝트의 핵심과는 동떨어진 경우가 많음
    유지보수에는 많은 책임이 있고 모두 즐겁지는 않지만, 자유 오픈소스 유지보수자들이 그런 일까지 해줄 때 고맙게 느낌. 그렇게 하는 사람은 많지 않아 보임
  • “LLM에 의지한다”는 표현은 결과물이 나빠진다는 뜻처럼 들리지만, 반드시 그렇지는 않음
    LLM 도움 없이는 특정 목표 달성 비용이 너무 높다고 판단될 수 있고, LLM 도움을 받으면 합리적인 비용이 될 수도 있음
    긍정적으로 보면, 건강한 일과 삶의 균형을 유지하려는 오픈소스 유지보수자가 LLM으로 작업량을 줄이면서도 원하는 목표를 더 쉽게 달성할 수 있게 된 것임
  • 그 해석은 글의 나머지를 읽기 전에 이미 결론을 정해놓은 것처럼 보임
    골라 인용한 부분은 도입부의 일부일 뿐이고, 이 글은 분명 신중하고 미묘한 맥락을 담아 쓴 글이지 기본적인 오픈소스 유지보수에 대한 글이 아님
    더 이상한 점은 인용문 바로 앞의 맥락을 빼놓았다는 것임. 보고가 폭증하면서 rsync의 방어선을 크게 올려야 했고, 훨씬 철저한 테스트 스위트, 코드 커버리지 분석, 더 많은 플랫폼에서의 CI 테스트, 보안 이슈 탐색, 방어 심층화 기법 추가가 필요해졌다는 내용임
    이 경우 작성자는 은퇴했지만, 다른 오픈소스 프로젝트에서는 직장이나 다른 일이 있는 사람들이 비슷한 업무 증가에 휩쓸릴 수 있음. 솔직히 이 댓글이 그렇게 많이 추천받는 게 당황스럽고, 선의로 쓴 글처럼 느껴지지 않음. 적어도 제목만 보고 달려와 남긴 댓글보다 겨우 나은 수준의 성의 없어 보이는 반응 같음

• 괴롭힘을 변명하거나 승인할 생각은 없지만, 이 방어에는 빠진 이유가 있음
  설명은 작성자가 바이브코딩용 설계를 했고, 결과 코드를 검토했으며, 코드와 챗봇에 능하고, 바이브코딩을 조심스럽게 다뤘고, 보안과 기능 회귀 사이 균형을 잡으려 했다는 것임. 그럴듯하게 들리지만 실제로는 회귀가 있었고, 작성자는 그 이유까지 도달하지 못함
  “AI 도구가 단순 작업에 강해서 그런 일을 맡겼다”고 했지만, 그렇지 않음. 챗봇은 실제로 작성에 서툼. 이것이 핵심인데 작성자는 그걸 인식조차 못 하는 듯함

  • 각 릴리스 이후 회귀가 얼마나 생겼는지 시간표로 실제 집계해 보면 흥미로울 것 같음
    최근에 숫자가 정말 늘었는지 확인할 수 있다면 좋겠음. 회귀 자체는 드문 일이 아니고, 사람들이 Andrew를 공격할 구실을 찾는 것일 수도 있다고 봄
  • 왜 코딩 에이전트가 문제인가? 테스트 스위트가 없거나 충분히 명세되지 않은 게 문제일 수도 있고, 유지보수자가 생각보다 코드베이스 이해를 더 많이 잃었기 때문일 수도 있지 않나?
  • 같은 글을 읽은 게 맞나 싶음
    작성자는 rsync 3.4.3 릴리스의 일부 사용 사례에서 회귀가 있었다고 인정했고, 그 릴리스에서는 의도적으로 보안 이슈 수정 쪽에 더 무게를 뒀으며, 유효하지만 특이한 사용 사례 일부가 변경에 걸렸다고 설명했음
    그 사례들은 기존 rsync 테스트 스위트나 직접 수행한 수동 테스트에 포함되지 않았고, 지금 회귀를 처리 중이며 GitHub 저장소에 이슈나 PR로 보고해준 사람들에게 감사한다고 했음. 자기 사용 사례가 영향을 받았다면 사과하고, 보안 위험을 감수하겠다면 이전 릴리스를 써도 된다고도 했음

• “소프트웨어 엔지니어링의 세계가 지난 몇 달 사이 극적으로 바뀌었다”, “IT 보안과 보고 폭주 속에서 소프트웨어를 유지보수하는 세계가 지난 몇 주 사이 완전히 바뀌었다”는 말을 지난 반년쯤 계속 반복해서 듣고 있는데 지침
  이 보고 폭주의 원인이 LLM이라면, 해법으로 LLM을 찾는 건 믿기 어려울 정도로 잘못된 방향처럼 느껴짐
  그래도 지금 인기 있는 무언가를 유지보수하는 일이 끔찍하리라는 점은 바로 믿을 수 있음. 어쩌면 그에게는 제한된 컴퓨팅 시간을 더 쥐어짜기보다 그냥 물러나 진짜 은퇴를 즐기는 게 최선일 수도 있음

  • 바이브코딩을 옹호하는 이야기도 지침. 거의 컬트를 보는 느낌임
    사람들이 주장하는 것의 절반만큼이라도 유용한 도구라면, 그 유용성은 스스로 말해줄 것이라고 봄
    다만 Tridgell 같은 사람의 이야기는 들을 가치가 있음. 그리고 보안 보고의 “홍수”는 진지하게 받아들여야 함. 누가, 무엇이 찾았든 보안 이슈는 보안 이슈임. 그래서 이 글은 평소에 보는 지겨운 공세와는 다르게 느껴짐
  • LLM이 만든 체계적 문제의 해답이 모두가 더 많은 LLM을 사는 것이라고 설득해 이익을 얻는 사람들이 있는 건 아닌지 의심하게 됨
    결국 LLM 의존도가 점점 커지는 하향 나선에 들어갈 수도 있음
  • 비슷하게, “웹이 클릭 농장용 AI 생성 페이지로 넘쳐서 웹 검색은 이제 쓸모없으니 그냥 LLM을 직접 쓰라”는 말과 닮았음
  • 이 부분을 조금 더 설명해줄 수 있나? 글쓴이는 보고된 보안 이슈를 처리하는 데 LLM이 유용하다고 말하는 것으로 해석했음
    그게 왜 잘못된 방향이라는 건가? 아무도 LLM을 갖지 않는 편이 더 낫다는 뜻인가?
  • LLM 사용이 악마화되는 것도 똑같이 지침. 사람이 주도하는 LLM 보조 개발을 바이브코딩이라고 부르는 것도 지겹고, AI 사용을 조금이라도 공개했다는 이유로 수백 명이 프로젝트나 개발자를 공격하는 것도 지침
    LLM 보조 개발이 반드시 “쓰레기 결과물”일 필요는 없음

• 이 글이 작성되고 공유된 점은 고맙게 봄. 특히 3.4.4로 일부 회귀를 완화할지, 훨씬 큰 변경을 담은 3.5.0으로 갈지 고민한다는 부분이 눈에 띄었음
  작성자가 읽고 있다면 여기서는 3.4.4가 맞는 접근으로 보임. 지난 릴리스에 회귀가 있었던 상황에서 곧장 큰 3.5.0으로 가면 많은 사람이 무모하다고 볼 것임. 사람들이 차이를 더 쉽게 이해하게 하면 우려가 줄어듦
  새 테스트 스위트의 핵심 구조를 master에서 공개적으로 먼저 작업하려 했지만 그게 분노를 부른 걸 보면 나쁜 생각이었을지도 모른다는 부분에 대해서는, 투명성을 줄인다고 인식과 반응이 좋아질 것 같지 않음. 기껏해야 더 큰 반발을 뒤로 미룰 뿐임
  openrsync에 새 rsync 테스트 스위트를 돌려보라는 말은 공정하지 않음. samba rsync는 프로토콜 32이고 openrsync는 프로토콜 27이며, 기능 완전성을 내세우는 것도 아니기 때문임

  • 그게 의도였다고 봄. 기본적으로 그만큼 뒤처져 있으니 행운을 빈다는 뜻임
  • 아이디어 하나는 3.5 작업을 하되 알파 릴리스를 내고, 검토와 테스터를 초대하는 것임

• Medium과 Cloudflare라니, 서로 섞이면 안 되는 끔찍한 조합임
  https://archive.is/qbyVA
  오픈소스 유지보수는 감사받기 어려운 일임. Tridge는 테스트 스위트의 기술 부채를 고치고 LLM이 탐지한 CVE 홍수에 책임감 있게 대응하려 했지만, Hyrum의 법칙에 맞은 것 같음. 3.4.4 계획이 그나마 덜 나쁜 선택이고, 결국 밀고 나가야 할 듯함

• 이 문제는 양쪽으로 마음이 갈림. 한편으로 보안은 사람이 직접 코드를 작성할 때만 보장될 수 있다고 봄
  코드를 쓰는 동안 그 코드에 대해 생각하고, 오류를 일찍 잡기 때문임. 나는 코드를 검토할 때보다 직접 쓸 때 훨씬 더 잘 씀. 검토 중에는 내가 모든 줄을 신중히 생각하지 않았기 때문에 많은 것들이 그냥 지나감
  다른 한편으로, 괴롭힘이 용납될 수 없다는 기본 사실은 별개로, Andrew는 자기 자유 시간에 자기 프로젝트를 원하는 방식으로 운영할 권리가 있음. LLM을 쓰고 싶다면 나는 동의하지 않지만 그건 그의 프로젝트이고 그의 재량임. 마음에 들지 않으면 내 백업을 restic이나 borgbackup으로 옮기거나 rsync를 포크해야 함
  분명히 하자면 나는 바이브코딩 자체에 반대하지 않음. 회사에서 반쯤 강제로 쓰게 하고 있고, 요즘 내 일의 대부분인 지루하고 새롭지 않은 접착 코드 작성에는 그럭저럭 괜찮음. 다만 자유 시간에는 쓰지 않음

  • 전반적으로 동의함. 백업에 관해서는 rsync가 아주 적합한 해법도 아님
    파일 내용이 손상됐을 때 복원하는 데 도움을 주지 못하기 때문임. restic 같은 도구가 훨씬 낫고, 파일의 이전 버전도 보관해서 이런 경우를 처리함. 실제로 삭제도 추적하므로 어떤 파일이 더 이상 관련 없는지도 알 수 있음
  • “이론상으로는 이론이 더 중요하지만…” 같은 농담과 비슷하다고 봄
    애플리케이션 보안 경험이 있고, 몇몇 익스플로잇을 고를 수 있으며, 리뷰에서 잡아낼 수도 있음. 하지만 현재 상위 LLM들이 “더 병적인 사례를 찾아라” 식의 반복을 돌리는 것만큼 잘하지는 못함
    그렇게 인기 있는 소프트웨어에서 내 코드, 사용한 라이브러리, 대체 구현의 이슈를 별로 애쓰지 않고도 찾았음. 사람이 쓸 수 있는 시간과 집요함은 전혀 비교가 안 됨
  • 보안을 종종 “신뢰할 수 없는 입력을 처리할 때의 안전한 코딩”으로 생각하지만, 보안을 보장하는 일에서 그것은 일부에 불과함
    조직 전반에는 이슈를 예방, 탐지, 대응하기 위한 보안 소프트웨어가 넓게 깔려 있음. 각 영역마다 항상 빈틈이 있고 해야 할 일이 더 있음. 조직은 완벽하지 않을 수 있음을 알면서도 보안 태세 개선을 받아들이는 편을, 개선이 아예 없는 것보다 선호할 수 있음. LLM이 제공하는 절충도 그 일부임
    이 절충점은 맥락에 따라 달라지지만 “모든 코드는 손으로 작성해야 한다”가 되는 경우는 드묾
    rsync 같은 서버에도 적용됨. 작성자가 말하듯 더 견고하고 회복력 있게 만들기 위한 큰 리팩터링이 필요할 수 있음. LLM으로 권한 분리 쪽으로 리팩터링해 더 작은 신뢰 기반 코드를 만들 수 있다면, 그 범위 밖의 일부 버그는 받아들일 수도 있음
    rsync의 구체적 맥락은 모르지만, 이런 프로젝트들이 보통 가진 제한된 자원 안에서 작성자가 프로젝트와 사용자에게 최선의 결정을 하고 있다고 믿음
  • 파일 변경을 감지하면 rsync의 영리한 차분 전송과 데이터 최소화 알고리즘 대신 파일 전체를 다시 보내도 괜찮다면 rclone도 선택지임
    대신 rclone은 병렬성을 갖고 있어서 사용 가능한 네트워크 대역폭을 훨씬 더 효과적으로 활용함
  • 표현이 좀 이상하게 느껴짐. 보안은 코드가 변해도 자동화가 강제하는 보장과 수학적 증명 같은 것의 도움을 받는다고 생각했음
    이것이 가질 수 있는 문제의 상한을 줌
    하한은 내가 찾거나, 다른 사람이 찾거나, 다른 무언가, 예컨대 LLM이 찾을 수 있는 버그와 취약점임
    사람이 자신이 작성한 C 코드, 예컨대 rsync를 검토하는 상황은 이 영역에서 좋은 위치라고 부르기 어려움. Andrew를 비난하려는 뜻은 전혀 없음

• 항해를 하고 싶어 하는 은퇴한 유지보수자에게는 공감하지만, 그 맥락이 근본적으로 바꾸는 건 없다고 봄
  Tridgell은 우리에게 어떤 작업도 빚지지 않았고, 은퇴해서 항해할 자유가 있음. 그렇게 하고 싶다면 잘되길 바람. 책임감을 느끼는 점에는 공감하지만, 행간을 제대로 읽었다면 그것을 어느 정도 부담으로 느끼는 듯함
  하지만 rsync는 핵심 소프트웨어이고, 그것을 유지보수하려는 사람은 일정한 품질 기준을 지켜야 한다고 봄. 유지보수자의 작업이 기준에 미치지 못하면 그것은 실수임. 그렇다고 괴롭힘을 받을 이유는 없음. 무언가가 실수라고 말하는 것은 그 실수를 한 사람이 나쁘다거나 그에게 공감하지 않는다는 뜻이 아님
  그래서 질문은 AI 코딩 도구가 한 작업이 기준에 맞았는가임. 어떤 기준이냐면, 대략 “이 품질로라도 작업이 된 것이 안 된 것보다 나은가”라는 기준임. 소프트웨어를 개선한다면 계속하면 되고, 더 나쁘게 만든다면 멈춰야 함. 영리한 정의라고 주장하진 않지만 올바른 정의라고 봄
  우리는 Tridgell에게 추가 작업을 요구할 권리는 없지만, 사실이라면 “이건 사용자들을 더 나쁘게 만든다”고 말할 여지는 있음
  솔직히 이 작업을 어떻게 판단해야 할지 완전히 정리된 생각은 없음. 회귀가 있었고 Tridgell은 그것을 경계 사례라고 설명했지만, 더 많은 맥락 없이는 그 경계 사례의 회귀 영향과 잠재 보안 이슈 수정의 가치를 어떻게 비교해야 할지 모르겠음
  “WITHOUT ANY WARRANTY”를 떠올리는 사람이 있겠지만, 그 조항은 여기서 무관함. 법적 책임의 부인이지 장인정신에 대한 자부심이나 최선을 다해야 한다는 비법적 요구의 부인이 아님. 이 댓글도 “WITHOUT ANY WARRANTY”로 제공되지만, 내가 실수하면 당연히 비판받을 수 있음

  • 그렇지 않음. 오픈소스는 그렇게 작동하지 않고, 그렇게 작동해야 하는 것도 아님
    작성자가 그것을 핵심 소프트웨어로 만든 게 아님. 당신이나 다른 사람이 그것을 쓴다면 책임은 사용자에게 있음. 소프트웨어가 기대대로 동작하지 않으면 포크하거나 대체하면 됨. 할 수 없는 일은 그 사람에게 당신 장단에 맞춰 움직이라고 강요하는 것임

• 원래 회귀 보도를 놓친 사람들을 위한 맥락: https://github.com/RsyncProject/rsync/issues/929

  • 맥락은 가치 있지만 GitHub 이슈가 아직도 잠기지 않았으니 직접 링크하지 않는 편이 나을 수도 있음
    이슈 보고는 mastodon post의 스크린샷이고, 그 뒤로 약 300개가 넘는 논쟁 댓글이 이어지고 있음
  • 실제 이슈는 이 링크임: https://github.com/RsyncProject/rsync/issues/897

• 설명하지 말고 그냥 하던 대로 하면 됨. 싫어하는 사람들은 계속 싫어함
  사람들이 어셈블리 작성을 멈췄을 때부터 싫어하기 시작했고, 앞으로도 멈추지 않을 것임

  • 이건 명백히 틀렸음. 많은 사람이 LLM에 반대하는 이유는 프로그래밍 언어와 개발 환경 개선에 관심이 없어서가 아니라, 오히려 그 관심 때문임