git과 coreutils의 Rust 도입을 둘러싼 논쟁을 계기로, 보안·성능·라이선스·유행 담론에 대한 오해를 짚고 Rust를 선택하는 현실적 동기를 설명한다. 대형 코드베이스에서의 점진적 도입과 메모리 안전, 동시성, 유지보수성의 장점을 사례와 함께 다룬다.
제 Rust 관련 전문 글쓰기는 이제 corrode 블로그로 옮겼으니, 여기서는 좀 더 캐주얼하게 기존 소프트웨어에서 Rust를 쓰는 문제를 둘러싼 최근 논쟁에 대해 개인적인 생각을 나눠 보려 한다.
문제의 두 프로젝트는 git(커널 스레드, Hacker News 토론)과, 최근 Rust로 다시 작성되어 Ubuntu 25.10 Quizzical Quokka에 포함될 coreutils이다.
이 글을 쓰게 된 직접적인 계기는 트위터에서의 논의와 “우리는 진짜 문제 해결보다 언어의 유행을 좇고 있는가?”라는 블로그 글이었다.
두 경우 모두, 저자들은 Rust를 선택한 동기에 대해 온갖 추측을 내놓는데, 프로덕션에서 Rust를 쓰도록 팀을 돕는 입장에서 그러한 주장들은… 꽤 우습게 느껴진다.
corrode를 시작했을 때만 해도, 사람들은 Rust가 진지한 용도로는 쓰이지 않는다고들 했다. 나는 클라이언트 업무를 통해 프로덕션 사용 사례를 알고 있었지만, 공개된 정보는 거의 없었다. 그래서 기업들이 실제로 Rust를 현실 세계의 애플리케이션에 선택하고 있음을 보여 주려고 ‘Rust in Production’ 팟캐스트를 시작했다. 하지만 사람들은 자신이 틀렸다는 사실을 인정하고 싶어 하지 않기 때문에, 그 음모론은 이제 “Big Rust”가 세상을 장악하려 한다는 이야기로 변주되었다. 😆
해당 블로그 글과 트위터 스레드의 주장 몇 가지를 살펴보고, 이것들이 얼마나 쉽게 반박될 수 있는지 보자.
“GNU Core Utils는 역사 내내 사실상 큰 보안 취약점이 없었다”
그랬다면 좋았겠다. 간단한 CVE 검색만 해도 수십 년간 여러 보안 이슈가 있었다는 걸 보여 준다. 버퍼 오버플로부터 경로 트래버설 취약점까지 다양하다. 불과 몇 달 전에도, 공격자가 특별히 조작한 입력 스트림을 보내면 민감한 데이터가 유출될 수 있는 sort의 힙 버퍼 언더리드가 발견되었다.
GNU coreutils는 전 세계에서 가장 널리 쓰이는 소프트웨어 묶음 중 하나로, 수십억 대 설치에 수백(수천?) 명의 개발자가 코드를 들여다본다. 그래도 취약점은 발생한다. 올바르고 안전한 C 코드를 작성하는 것은 쉽지 않다. 아무리 주의를 기울이고 규율을 지킨다 해도 마찬가지다.
ls는 5천 줄에 달한다.(소스 코드 참조) 파일 이름과 메타데이터를 출력하는 데 저 정도 분량이면, 공격 표면도 상당히 큰 편이다!
“Rust는 잘해야 C 성능을 따라갈 뿐이고, 보통은 더 느리다”
Trifecta의 작업은 경우에 따라 Rust가 C보다 더 빠를 수 있음을 보여 준다. 특히 동시성 작업에서, 그리고 메모리 안전을 보장하면서 그렇다. 안전한 C 코드를 쓰는 것도 어려운데, 안전한 동시성 C 코드를 써 보라고?
그 지점에서 Rust가 빛난다. 보안 이슈를 걱정하지 않고도 터무니없는 수준의 병렬화를 달성할 수 있다. 그리고 아니다, 코드 곳곳에 unsafe 블록을 도배할 필요 없다. Steve Klabnik의 Oxide 관련 최근 발표를 보라. 그들이 만든 부트로더와 선점형 멀티태스킹 OS인 hubris—둘 다 아주 핵심적인 시스템 코드—는 각각 unsafe 코드가 5%에 불과하다. 아예 unsafe 없이도 Rust로 대규모 코드베이스를 작성할 수 있다.
사소한 예로, 어느 날 나는 cat을 Rust로 다시 써 봤다. 결과는 내 머신에서 GNU cat보다 3배 빨랐다. 관련 글을 읽어 보라. 내가 한 건 splice를 써서 데이터를 복사한 것뿐인데, 메모리 복사를 한 번 아낄 수 있다. 성능은 언어뿐 아니라 사용하는 알고리즘과 시스템 콜에도 좌우된다.
Rust의 강점을 살리면 C의 성능을 맞출 수 있다. 적어도 이를 가로막는 기술적 한계는 없다. 그리고 개인적으로는, Rust에서는 메모리 안전 버그를 낼까 걱정하지 않아도 되기 때문에 코드 최적화를 훨씬 더 공격적으로 시도할 마음이 생긴다. 나만 그런 건 아닌 듯하다.
“업계는 필요성보다 새로움을 보상한다”
이는 대다수 성공적인 기업(구글, 메타 등)이 최첨단 언어가 아니라 검증된 기술 스택을 주로 사용한다는 사실을 무시한다. 이들 기업은 방대한 코드베이스를 갖고 있어 최신 유행 언어로 모조리 갈아엎을 여력이 없다. 하지만 새로운 컴포넌트에는 Rust를 쓰고, 기존 것도 점진적으로 다시 쓰는 선택을 한다. 보안 취약점의 70%가 메모리 안전 문제이고, 이를 고치는 데 드는 비용이 엄청나기 때문이다. 만약 새 언어로 전환하지 않고도 이 문제를 피할 수 있었다면, 그렇게 했을 것이다.
게다가 Rust가 이제 신규 라고 부르기도 애매하다. Rust 1.0이 나온 지 10년이 넘었다! 업계는 느리게 움직이지만, 그렇게까지 느리진 않다. 의외로, 수많은 기성 기업이 이를 “새로움”으로 여기지도, 대대적으로 발표하지도 않은 채 Rust를 쓰고 있다는 사실에 놀라게 될 것이다.
“100% 치밀하게 조율된 일이다”
트위터 스레드에선 여러 사람이 이것이 개발자들이 더 나은 도구를 고른 결과가 아니라, 누군가가 조정한 거대한 계획이라고 확신하지만, 정작 git과 coreutils의 메인테이너들은 모두가 볼 수 있는 공개 포럼에서 자신의 동기를 공개적으로 논의했다.
“이들은 C를 대체/삭제하려 한다. 그건 일어나지 않을 것이다”
그 점은 맞다. C는 당분간 사라지지 않는다. 세상에는 이미 C/C++ 코드가 너무 많고, 전부를 Rust로 다시 쓰는 건 불가능하다. 좋은 소식은 C/C++ 코드를 Rust로 컴포넌트 단위로 점진적으로 다시 쓸 수 있다는 것이다. git 메인테이너들이 바로 그렇게, 새로운 컴포넌트에 Rust를 사용하는 계획을 세우고 있다.
“GNU 라이선스의 소프트웨어를 MIT 라이선스 소프트웨어로 바꾸려는 것이다”
Rust를 사용해도 여전히 코드를 GPL이나 원하는 어떤 라이선스로든 배포할 수 있다. git 자체는 GPL이고, 많은 Rust 프로젝트들이 MIT만이 아닌 다양한 라이선스를 쓴다. 라이선스 공포는 흔히 오픈소스 라이선스를 잘 이해하지 못한 사람들이 꺼내 들거나, 그냥 FUD일 뿐이다.
MIT 코드는 GPL 코드와 여전히 호환되며, 같은 프로젝트에서 문제 없이 함께 사용할 수 있다. 다만 최종 산출물(사용자에게 전달하는 바이너리 실행 파일)은 GPL의 바이럴리티(전염성) 때문에 GPL의 적용을 받게 된다.
“그저 개발자들이 심심해서 반짝이는 새 언어를 만지고 싶어 하는 것뿐”
C 프로젝트의 고령화된 메인테이너들은 은퇴하고 있고, 새로운 개발자들은 개인 시간까지 들여 C를 배워 레거시 코드를 유지보수하고 싶어 하지 않는다. C 개발자는 사실상 멸종 위기다. 신세대 개발자들은 현대적인 언어로 일하고 싶어 하는데, 누가 그걸 탓하겠는가? 여러분이라면 40년 된 COBOL 코드베이스나 낡은 Perl 스크립트를 유지보수하고 싶겠는가? 우리는 앞으로 나아가야 한다.
“기존 도구를 다시 쓰느라 시간 쓸 게 아니라 완전히 새로운 걸 만들지 그러냐?”
그게 그렇게 간단하지 않다. 코드는 이야기의 일부일 뿐이다. 나머지는 생태계, 도구 체인, 통합, 문서, 사용자 기반이다. 이런 것들을 구축하는 데는 여러 해가 걸린다. 사용자는 자신의 워크플로를 바꾸고 싶어 하지 않으므로 드롭인 대체재를 원한다. 투박하고 구식일지라도, 검증된 인터페이스와 API에는 큰 가치가 있다.
물론, Rust로 전혀 새로운 도구도 만들어지고 있다.
“저 사람들은 진짜 문제를 푸는 법은 모르고, 유행만 좇는다”
수년 혹은 수십 년 동안 이런 프로젝트를 다뤄 온 메인테이너들의 기술 전문성을 싸그리 무시하는 발언이다. 그들은 그 누구보다도 문제의 아픈 지점을 잘 안다.
만약 그들이 유행만 좇았다면, 애초에 이런 프로젝트를 유지보수하지 않았을 것이다! 이 사람들은 세계에서 가장 숙련된 개발자들 중 일부다. 그런데도 어떤 이들은 그들에게 일하는 방법을 가르치려 든다.
“이건 소프트웨어를 감염시키는 각종 ‘와이크’ 정치의 일부다”
메모리 안전을 정치적 음모로 여긴다고? 버퍼 오버플로를 막는 것이 이념적 입장이라니. 이와 가장 가까운 것은 백악관의 기술 보고서 정도인데, 정부 소프트웨어에는 메모리 안전한 언어를 권고하고, 연방 자금 지원을 받는 소프트웨어에는 메모리 안전을 의무화하자는, 매우 합리적인 권고다.
계속 말할 수 있지만, 요지는 충분히 전달되었으리라 본다.
Rust를 진지하게 시도해 본 사람이라면, 메모리 안전, 동시성, 유지보수성 측면에서 Rust가 주는 장점을 안다. 이는 유행을 좇는 일이 아니라, 소프트웨어 품질에 대한 장기적 투자다. 매일 더 많은 기업이 Rust를 성공적으로 도입하면서, Rust는 많은 신규 프로젝트에서 점점 더 기본 선택이 되고 있다.
프로덕션에서 Rust를 사용하는 법을 더 알고 싶다면, 제 다른 블로그를 보거나 Rust in Production 팟캐스트를 들어 보라.
아, 그리고 이런 주장을 올리는 사람을 알면, 논쟁은 그만두고 이 글 링크만 보내라.
좋은 작업에는 시간이 든다. 오래가는 소프트웨어를 만들고 싶다면, CodeCrafters는 지름길 없이 바닥부터 만들어 보는 방법을 가르친다. 무료로 체험해 보고, 유료 플랜은 40% 할인 혜택을 받자. 저는 구독으로 커미션을 받는다.
