Rust에 대한 전문적인 글은 corrode 블로그로 옮겼기 때문에, 여기서는 조금 더 편하게 기존 소프트웨어에 Rust를 도입하는 문제를 둘러싼 최근 논쟁에 대한 개인적인 생각을 나눠보려 한다.

논쟁의 중심에 있는 두 프로젝트는 git(커널 스레드, Hacker News 토론)과 최근 Rust로 재작성되어 Ubuntu 25.10 Quizzical Quokka에 탑재될 예정인 Rust로 재작성된 coreutils다.

이 글을 쓰게 된 계기는 트위터에서의 토론과 “Are We Chasing Language Hype Over Solving Real Problems?”이라는 제목의 블로그 글이다.

두 경우 모두 필자들은 Rust를 선택한 동기에 대해 추측하고 있는데, 프로덕션 환경에서 Rust를 도입하려는 팀들을 돕는 사람으로서 그 주장들을 보니… 솔직히 웃음이 나온다.

내가 corrode를 시작했을 때만 해도 사람들은 Rust가 제대로 된 곳에서는 쓰이지 않는다고 말하곤 했다. 나는 클라이언트 작업을 통해 프로덕션 사용 사례를 알고 있었지만, 공개된 정보는 거의 없었다. 그래서 우리는 기업들이 실제로 현실 세계의 애플리케이션에 Rust를 선택하고 있다는 것을 보여주기 위해 ‘Rust in Production’ 팟캐스트를 시작했다. 하지만 사람들은 자신이 틀렸다는 것을 인정하기 싫어해서, 그 음모론은 이제 “Big Rust”가 세상을 장악하려 한다는 이야기로 변모했다. 😆

블로그 글과 트위터 스레드에 나온 주장들을 하나씩 살펴보고, 얼마나 쉽게 반박할 수 있는지 알아보자.

“GNU Core Utils는 존재한 이래로 중대한 보안 취약점이 거의 없었다”

사실이라면 얼마나 좋을까. 간단한 CVE 검색만 해봐도 수십 년간 버퍼 오버플로와 경로 탐색 취약점을 포함한 다수의 보안 이슈가 있었음을 알 수 있다. 불과 몇 달 전에도 sort에서 힙 버퍼 언더리드가 발견됐는데, 공격자가 특수하게 조작된 입력 스트림을 보내면 민감한 데이터가 유출될 수 있는 문제였다.

GNU coreutils는 전 세계에서 가장 널리 사용되는 소프트웨어 패키지 중 하나로, 수십억 대의 기기에 설치되어 있고 수백 명(수천 명?)의 개발자가 코드를 들여다본다. 그래도 취약점은 생긴다. 올바르고 안전한 C 코드를 작성하는 일은 결코 쉽지 않다. 아무리 각별히 조심하고 철저히 해도 마찬가지다.

ls만 해도 5천 줄이 넘는다. (소스 코드를 확인해 보라). 파일 이름과 메타데이터를 출력하는 데 이렇게 많은 코드가 필요하고, 그만큼 공격 표면도 넓다!

“Rust는 아무리 잘해봐야 C 성능에 겨우 맞먹을 뿐이며, 보통은 더 느리다”

Trifecta의 연구에 따르면 경우에 따라서는 C보다 빠른 Rust 코드를 작성하는 것도 가능하다. 특히 동시성 워크로드에서, 그것도 메모리 안전성을 보장하면서 말이다. 안전한 C 코드를 작성하는 것조차 어렵다면, 안전한 동시성 C 코드를 작성하는 건 어떨지 상상해 보라!

바로 이런 지점에서 Rust가 빛을 발한다. 보안 문제를 걱정하지 않고도 엄청난 수준의 병렬화를 달성할 수 있다. 그리고 코드 곳곳을 unsafe 블록으로 도배할 필요도 없다. Oxide에 관한 Steve Klabnik의 최근 발표를 보면, 부트로더와 선점형 멀티태스킹 OS인 hubris — 둘 다 상당히 핵심적인 시스템 코드다 — 각각 unsafe 코드가 5%에 불과하다는 것을 알 수 있다. Rust로는 unsafe 코드 없이도 대규모 코드베이스를 충분히 작성할 수 있다.

사소한 예로, 어느 날 cat을 Rust로 다시 작성해 본 적이 있다. 내 머신에서는 그 결과가 GNU cat보다 3배 빨랐다. 자세한 내용은 이 글에서 읽을 수 있다. 내가 한 일이라고는 데이터를 복사할 때 splice를 사용해 메모리 복사를 한 번 줄인 것뿐이다. 성능은 언어에만 달린 것이 아니라 어떤 알고리즘과 시스템 호출을 사용하느냐에 달려 있다.

Rust의 강점을 잘 활용하면 C의 성능에 충분히 맞먹을 수 있다. 적어도 이를 막는 기술적 제약은 없다. 그리고 개인적으로는 Rust에서는 메모리 안전성 버그를 걱정하지 않아도 되기 때문에 코드를 더 적극적으로 최적화하려는 의욕이 생긴다. 나만 그런 게 아닌 것 같다.

“업계에서는 필요성보다 참신함을 더 높이 평가한다”

이는 대부분의 성공한 기업(Google, Meta 등)이 최신 유행 언어가 아니라 오랜 기간 검증된 기술 스택을 주로 사용한다는 사실을 간과한 주장이다. 이들 기업은 방대한 코드베이스를 가지고 있어 모든 것을 최신 유행 언어로 다시 작성할 여유가 없다. 하지만 새로운 컴포넌트에 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로 새로운 도구들도 만들어지고 있다.

“그들은 문제를 실제로 해결할 줄 모르고 그저 유행을 쫓을 뿐이다”

수년, 수십 년간 이 프로젝트들을 이끌어 오며 누구보다 고충을 잘 아는 메인테이너들의 기술적 전문성을 깎아내리는 말이다.

그들이 정말 유행만 쫓는 사람들이었다면 애초에 이런 프로젝트를 유지보수하지도 않았을 것이다! 이들은 세계에서 가장 경험이 풍부한 개발자들 중 일부인데, 사람들은 그런 그들에게 어떻게 일해야 하는지 훈수를 두려 한다.

“소프트웨어를 감염시키는 woke mind virus의 일부다”

메모리 안전성을 정치적 음모라고 생각하다니 상상해 보라. 이제 버퍼 오버플로를 방지하는 것이 이념적 입장이라고 한다. 이와 가장 가까운 것은 정부 소프트웨어에 메모리 안전 언어를 권고하고 연방 자금을 받는 소프트웨어에 메모리 안전성을 의무화한 백악관 기술 보고서 정도인데, 꽤 합리적인 주장이다.

결론

더 이어갈 수도 있지만, 내 요점이 무엇인지는 이해했을 거라 생각한다.

Rust에 제대로 기회를 주는 사람들은 Rust가 메모리 안전성, 동시성, 유지보수성 측면에서 이점을 제공한다는 것을 안다. 이는 유행을 쫓는 것이 아니라 소프트웨어 품질에 대한 장기적인 투자다. 매일 더 많은 기업이 Rust를 성공적으로 도입하면서, Rust는 점점 더 많은 신규 프로젝트에서 기본 선택지가 되어 가고 있다.

프로덕션에서 Rust를 사용하는 것에 대해 더 알고 싶다면, 내 다른 블로그를 확인하거나 Rust in Production 팟캐스트를 들어보길 바란다.

아, 그리고 이런 주장을 하는 사람을 안다면, 논쟁을 멈추고 이 글 링크를 보내주자.