"제발 이 소프트웨어 바이브코딩으로 망치지 마세요" - rsync 메인테이너의 절규

35년 된 소프트웨어에 올라온 충격적인 이슈

오픈소스 세계에서 좀 화제가 된 이슈가 있어요. rsync라는 프로젝트의 GitHub 저장소에 "Please Do Not Vibe Fuck Up This Software"(제발 이 소프트웨어를 바이브로 망치지 말아주세요)라는 제목의 이슈가 올라온 거예요. 제목부터 욕설 섞인 절규인데, 내용을 보면 단순한 짜증이 아니라 오픈소스 메인테이너들이 요즘 겪고 있는 진짜 심각한 고민이 담겨 있어요.

rsync가 뭐냐면, 1990년대부터 있어온 파일 동기화 도구예요. 서버 두 대 사이에서 파일을 복사하거나 백업할 때 거의 표준처럼 쓰이는 프로그램이고요, 핵심은 '바뀐 부분만 골라서 전송한다'는 알고리즘이에요. 1GB 파일에서 1KB만 바뀌었으면 그 1KB만 보내는 거죠. 이게 단순해 보이지만 내부적으로는 체크섬, 롤링 해시, 압축, 네트워크 프로토콜이 정교하게 얽혀 있어서 한 줄만 잘못 건드려도 데이터가 깨질 수 있는 그런 소프트웨어예요. 전 세계 수억 대의 서버와 NAS가 이걸 매일 돌리고 있고요.

"바이브 코딩"이 뭐길래

이슈 제목의 핵심 단어 vibe coding(바이브 코딩)은 최근 1~2년 사이에 생긴 신조어예요. 풀어서 설명하면, "코드를 깊이 이해하지 않고 AI(ChatGPT, Claude, Cursor 같은 도구)에게 시켜서 '느낌대로' 짜는 방식"을 뜻해요. 원래는 OpenAI 공동창업자 안드레이 카르파시가 '에러 메시지를 그냥 AI에 복붙해서 고치는 게 재밌다'며 농담처럼 쓴 표현인데, 어느새 진지한 비판의 대상이 됐어요.

이번 이슈를 올린 사람의 핵심 메시지는 이거예요. "rsync 같은 인프라급 소프트웨어에 AI가 생성한 코드를 무비판적으로 PR로 던지지 마라." 최근 rsync 저장소에 AI가 만든 것으로 의심되는 패치들이 쏟아져 들어오고 있는데, 겉보기엔 그럴듯하지만 자세히 보면 미묘하게 잘못된 코드, 기존 동작을 깨뜨리는 변경, 메인테이너가 검토하는 데 시간만 잡아먹는 "AI 슬롭(slop)"이 많다는 거예요.

특히 rsync는 위험성이 큰 소프트웨어예요. 백업 도구라는 게 잘못되면 어떻게 되겠어요? 사용자가 "백업했다"고 안심하고 있는데 실제로는 데이터가 깨진 채로 저장돼 있으면, 진짜 복구가 필요한 순간에 모든 게 사라지는 거예요. "조용히 실패하는 백업 도구"는 백업이 없는 것보다 더 나쁘다는 말이 있는데, rsync에 잘못된 패치가 들어가면 정확히 그런 상황이 발생할 수 있어요.

오픈소스 메인테이너들의 새로운 고통

이건 rsync만의 문제가 아니에요. 작년부터 curl, cURL, Python, FFmpeg 같은 주요 오픈소스 프로젝트의 메인테이너들이 비슷한 불만을 쏟아내고 있어요. curl 창시자 다니엘 스텐베르그는 "AI가 생성한 보안 취약점 신고가 너무 많아서, 진짜 보안 이슈를 처리할 시간이 없다"고 공개적으로 호소했어요. 누군가 ChatGPT에 "curl에서 보안 취약점 찾아줘"라고 시키면, AI는 그럴듯한 코드 분석과 함께 사실은 존재하지도 않는 버그를 신고서로 만들어내거든요. 메인테이너는 이걸 다 검토해야 하고요.

rsync 이슈의 작성자는 한 발 더 나아가서, AI 도구를 쓰지 말라는 게 아니라 "이해하지 않고 쓰지 말라"고 강조해요. AI가 생성한 코드라도 본인이 한 줄 한 줄 의미를 알고, 왜 그렇게 짰는지 설명할 수 있고, 엣지 케이스를 직접 테스트해봤다면 괜찮다는 거예요. 문제는 "AI가 이렇게 짜줬는데 잘 모르겠지만 일단 PR 올려봅니다" 같은 태도예요.

한국 개발자 입장에서 생각해볼 점

이 논쟁은 한국에서도 남일이 아니에요. 요즘 주니어 개발자 채용 현장에서 "AI 도구를 잘 쓰는 게 경쟁력"이라는 말이 흔하잖아요. 맞는 말이긴 한데, 이번 rsync 이슈는 그 반대편의 위험을 보여주는 거예요. AI 도구를 쓰는 능력과 코드를 이해하는 능력은 다른 거라는 거죠.

실무에서 적용할 수 있는 몇 가지 원칙을 정리해보면 이래요. 첫째, AI가 짜준 코드를 PR에 올리기 전에 본인이 디버거로 한 번 따라가보세요. 변수 값이 어떻게 흐르는지, 예외는 어디서 발생할 수 있는지 직접 확인해야 해요. 둘째, 테스트를 직접 작성해보세요. AI에게 테스트까지 시키면 AI가 자기 코드에 맞춰 테스트를 만들어줘서, 버그가 있어도 통과돼버려요. 셋째, 인프라성·보안성 코드는 특히 조심하세요. 백업, 인증, 암호화, 결제 같은 영역은 "그럴듯하게 동작하는 것"과 "올바르게 동작하는 것" 사이의 간극이 어마어마하게 커요.

그리고 오픈소스 기여를 꿈꾸는 분들에게 특히 강조하고 싶어요. AI에게 "이 프로젝트에 기여할 수 있는 이슈 찾아서 패치 만들어줘" 하지 마세요. 메인테이너들에게 민폐가 될 뿐만 아니라, 본인의 평판도 깎이는 길이에요. 작은 기여라도 본인이 진짜로 코드베이스를 읽고 이해하고 제안하는 게 백 배 가치 있어요.

마무리

rsync 메인테이너의 거친 제목 뒤에는 "코드를 이해하지 않고 던지지 마라"는 본질적인 메시지가 있어요. AI가 코딩의 진입장벽을 낮춰준 건 사실이지만, 인프라급 소프트웨어의 책임감까지 낮춰주진 않거든요. 여러분은 어디까지가 "AI 도움 받은 코딩"이고 어디서부터가 "바이브 코딩"이라고 생각하세요? 본인이 일하는 도메인에서 AI 코드를 무비판적으로 머지하면 안 되는 영역은 어디인가요?