Rsync와 분노

저는 오래전에 블로그 운영을 포기했습니다 (ArduPilot에 관한 가끔의 글을 제외하고는요). 저는 그저 코드를 작성하고 사람들이 그것을 유용하게 사용하기를 바라는 편이라, 이 글을 쓰는 것이 조금 이상하게 느껴지기도 합니다. 하지만 최근 제가 받아온 수많은 분노 섞인 게시물들을 고려했을 때, 무언가 글을 올려야 할 것 같다고 생각했습니다.

많은 오픈 소스 패키지 개발자들과 마찬가지로, 저 또한 rsync 유지 관리자 (maintainer)로서 최근 보안 보고서의 홍수에 직면해 있습니다. 그 보고서 중 상당수는 AI가 생성한 것들입니다 (전부는 아닙니다. 매우 세심하고 높은 품질의 수동 분석이 포함된 주목할 만한 것들도 있습니다).

이러한 홍수가 더욱 격렬해지기 시작하면서, 저는 rsync의 방어 체계를 대폭 강화해야 한다는 것을 깨달았습니다. 우리는 훨씬 더 철저한 테스트 스위트 (test suites), 코드 커버리지 분석 (code coverage analysis), 훨씬 더 많은 플랫폼에서의 CI 테스트, 가능한 보안 문제를 찾기 위한 의도적이고 철저한 스캐닝 (그래야 다른 사람들이 찾기 전에 제가 최소한 몇 개라도 찾을 수 있으니까요!), 그리고 수많은 심층 방어 (defence-in-depth) 강화 기술의 추가가 필요했습니다. 이 모든 것은 엄청난 양의 작업입니다. 저는 은퇴했습니다 (제 아내는 이에 반대할 수도 있겠지만요!). 저는 rsync 보안 문제를 해결하기보다는 밖에서 항해를 하고 싶습니다. 그래서 해야 할 일을 돕기 위해 여러 AI 도구들을 활용했습니다. 저는 그렇게 한 것에 대해 전혀 후회하지 않습니다. 비록 AI 반대론자들의 분노 섞인 폭풍을 보면, 많은 사람이 제가 이런 생각을 했다는 것만으로도 발가락이 묶인 채 채찍질을 당해야 한다고 생각하는 것 같지만 말입니다.

저를 향한 입에 거품을 무는 듯한 모든 비난에 답하려고 시도한다면 시간이 너무 오래 걸릴 것이기에, 여기 몇 가지만 적어둡니다:

— 저는 기존의 쉘 스크립트 (shell script) 설계를 바탕으로 rsync 테스트 스위트 (test suite)를 Python으로 다시 작성했습니다. 설계는 제가 직접 수행했으며 (그 결과에 대해 정말 만족합니다), 단순 반복 작업 (grunt work)은 Codex 및 Gemini를 통한 교차 검증과 함께 Claude를 사용하여 수행했습니다. 저는 단순히 "테스트 스위트를 Python으로 변환해줘"라고 말하며 느낌대로 코딩 (vibe-code)한 것이 아닙니다. 저는 40년 경력의 소프트웨어 엔지니어이며 (네, 저 정말 나이가 많습니다!), 따라서 설계를 먼저 진행했고 이를 검증할 계획을 세웠습니다. AI 도구들이 그런 단순 반복 작업에 능숙하기 때문에 이를 활용했을 뿐입니다. 저는 모든 부분을 직접 검토했으며, 이를 정확하게 만들기 위해 엄청난 양의 CI (지속적 통합) 시간을 들여 실행했습니다 (CI 대기 시간을 줄이기 위해 현재는 대부분의 테스트를 수행할 수 있는 다수의 로컬 VM을 사용하는 방식으로 전환했습니다). 커밋 히스토리에서 Claude가 공동 작성자 (co-authored)로 표시된 것은 관용적인 표현을 빌리자면 소프트웨어 엔지니어링 빙산의 일각일 뿐입니다.

— "나는 xyz 대학의 박사 학위 소지자이며, 당신의 LLM (대규모 언어 모델)은 그저 모든 것을 지어내는 확률적 도구(stochastic tools)일 뿐이며, 이를 사용하면 세상이 무너질 것이라고 말하고 있다"라고 말하는 사람들에게, 당신은 시대에 뒤처져 있다는 사실을 알려드리고 싶습니다. 소프트웨어 엔지니어링의 세계는 지난 몇 달 동안 극적으로 변했습니다. IT 보안의 세계와 쏟아지는 보고들 속에서 소프트웨어를 유지 관리하는 방식은 불과 지난 몇 주 사이에 완전히, 그리고 철저하게 바뀌었습니다. 작년에 이 분야에 대해 배웠던 것이라면 마치 다른 행성에서 배운 것이나 다름없을 정도입니다. 아, 참고로 저도 컴퓨터 과학 (CS) 박사 학위가 있고, 실제로 신경망 (neural networks)에 관한 연구를 꽤 많이 했습니다. 그리고 네, 제 인생의 그 시절에 얻은 모든 지식 또한 완전히 시대에 뒤처져 있습니다. 또한, 인간의 지능 역시 그저 더 미세한 입자의 확률적 예측 (stochastic prediction)일 뿐인지에 대해서는 실제로 아무도 모릅니다. 언젠가 우리가 그것을 알아낼 수도 있고, 아닐 수도 있겠죠. 결론은 저는 LLM이 어떻게 작동하는지 (대략적으로라도!) 알고 있지만, 그렇다고 해서 그것들이 유용하지 않다는 뜻은 아니라는 것입니다. 그것은 당신이 주의를 기울여야 함을 의미하지만, 저는 주의를 기울이고 있습니다. 소위 인터넷 전문가라고 불리는 이들이 쏟아내는 쓰레기 같은 정보들을 처리하는 대신 항해를 즐기고 싶은 저의 욕구에 비추어 볼 때, 제가 할 수 있는 최대한의 주의를 기울이고 있습니다.

— 네, 3.4.3 릴리스의 일부 rsync 사용 사례에서 회귀(regressions)가 있었습니다. 저는 이번 릴리스에서 보안 이슈를 해결하는 쪽으로 의도적으로 무게를 두려 노력했고, 그 과정에서 몇몇 타당하지만(하지만 특이한) 사용 사례들이 휩쓸려 들어갔습니다. 해당 사례 중 그 어떤 것도 기존의 rsync 테스트 스위트(test suite)나 제가 수행한 모든 수동 테스트(네, 저도 rsync를 직접 사용하며, 단순히 개발만 하는 것이 아닙니다)로 커버되지 않았습니다. 저는 현재 이러한 회귀 문제들을 해결하고 있으며, github 리포지토리(repo)에 이슈(issues)나 PR(Pull Requests)로 이를 보고해 주신 모든 분께 감사드립니다. 제가 모든 것에 빠르게 응답하지는 못하더라도, 보고된 내용들을 읽고 있습니다. 만약 여러분의 rsync 사용 사례가 이러한 회귀 문제의 영향을 받았다면 사과드립니다. 보안 위험을 개의치 않으신다면 당연히 이전 릴리스를 사용하셔도 좋습니다.

— "세상에, pytest를 사용하지 않다니, 도대체 뭘 아는 게 있긴 한 건가!"라고 말씀하시는 분들께 말씀드립니다. 저는 다른 프로젝트에서 pytest를 광범위하게 사용해 왔습니다. 하지만 이 프로젝트에는 적합하지 않습니다. 이 테스트 스위트에서 수행해야 하는 작업 중에는 pytest로는 수행하기 매우 어려운 것들이 있기 때문입니다(적어도 저의 경험에 비추어 볼 때 그렇습니다). 그래서 저는 특정 작업에 맞는 적절한 접근 방식을 설계했습니다. 저는 평생 그렇게 해왔으며, 기존의 방식이 완전히 적합하지 않을 때는 종종 새로운 방식을 만들어내곤 합니다. 저는 개인적으로 이것이 바람직한 태도라고 생각합니다.

이제 미래에 대해 이야기해 보겠습니다. 아직 갈 길이 아주 멀기 때문입니다. 보안 보고가 계속해서 들어오고 있습니다. 저는 현재 여러 개의 CVE(Common Vulnerabilities and Exposures)를 처리하고 있습니다. 다행히 훌륭한 시스템 개발 기술과 보안 지식을 갖춘 다른 뛰어난 개발자들이 합류해 주었습니다. 이들 중 일부는 현재 벌어지고 있는 이 모든 분노 덕분에 제 눈에 띄기도 했습니다. 그러니 분노의 먹구름 속에도 한 줄기 빛은 있다는 것을 이해합니다. 다음 릴리스에서는 훌륭한 신규 rsync 개발자들에 대한 크레딧(credits)을 기대해 주세요.

저는 현재 일부 퇴보(regressions)를 완화하는 3.4.4 릴리스를 진행할지, 아니면 훨씬 더 큰 변화를 계획했던 3.5.0으로 넘어갈지 결정하려고 노력 중입니다. 3.5 릴리스는 rsync 보안 측면에서 기준을 엄청나게 높이겠지만, 이는 매우 큰 변화입니다. 필요한 대규모 변경 사항 세트는 테스트 스위트(test suite) 재작성 작업의 큰 동기부여가 되었습니다. rsync와 같은 소프트웨어에 대해 정말 포괄적인 테스트 스위트 없이는 신속하고 대규모인 변경을 수행할 수 없기 때문입니다. 새로운 테스트 스위트의 핵심 구조를 먼저 master 브랜치에서 공개적으로 진행하는 것이 좋은 아이디어라고 생각했지만, 그로 인해 발생한 모든 분노를 고려하면 아마도 나쁜 아이디어였을지도 모르겠습니다. 어쨌든, 새로운 테스트 스위트는 많은 도움이 되었으며, 3.5가 출시되면 여러분 모두가 즐겁게 읽을 수 있는 보안 관련 이슈에 대한 방대한 추가 테스트들을 준비해 두었습니다.

저는 (아마도 순진하게도) 현재의 이러한 추진력을 통해 상황을 앞서 나가고, 밀려드는 문제들이 점차 줄어들다가 결국 마를 수 있기를 희망합니다. 꿈은 꿀 수 있으니까요.

이제 분노 섞인 글을 올리는 분들 중 누군가가 제가 공개한 코드를 실제로 리뷰하고 건설적인 비판을 해준다면 정말 좋을 것입니다! 만약 그저 분노를 더 쏟아내고 싶을 뿐이라면, 인터넷 어딘가에 그런 행동이 환영받는 구석이 분명히 있을 것이라 확신합니다.

"XXX 플랫폼용 openrsync를 패키징해서 그걸 사용하겠다!"라고 말하는 모든 분들에 대해서는, 저는 그것이 꽤나 재미있다고 생각합니다. 만약 그 길을 가기로 결정하신다면, AI의 도움을 받아 작성된 것을 견딜 수 있다면 openrsync에서 새로운 rsync 테스트 스위트를 시도해 보시길 권합니다. 제가 오늘 테스트해 본 결과, 현재 openrsync는 98개의 테스트 중 85개에서 실패했습니다. 그러니 여러분이 이를 정상 궤도에 올려놓는 데 오래 걸리지는 않을 것이라 확신합니다. 실행 방법은 다음과 같습니다: "./runtests.py — rsync-bin=../openrsync/openrsync — use-tcp". 인정하건대 실패 사례의 상당수는 단지 openrsync에 없는 기능들 때문이지만, 그럼에도 불구하고 그리 좋은 결과는 아닙니다.

마지막으로, 요전 날 이 페이지(https://www.tridge.com/)를 우연히 보고 한참을 웃었습니다. 어쩌면 저는 평생 동안 실제로 로봇이었던 것 같기도 합니다. 아마 그래서 다른 사람들만큼 AI 도구들을 미워하지 않는 것일지도 모르겠습니다.