Rust에 대한 전문적인 글은 이제 corrode blog에 올리고 있어서, 여기서는 좀 더 가볍게 기존 소프트웨어에 Rust를 사용하는 문제를 둘러싼 최근 논쟁에 대한 개인적인 생각을 공유해보려 한다.

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

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

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

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

블로그 글과 Twitter 스레드에 나온 주장 몇 가지를 살펴보고, 얼마나 쉽게 반박될 수 있는지 보자.

“GNU Core Utils는 그 존재 역사 동안 사실상 중대한 보안 취약점을 한 번도 겪은 적이 없다”

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

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

ls 하나가 5,000줄이나 된다. (소스 코드를 확인해보라). 파일 이름과 메타데이터를 출력하는 데 이 정도 코드라니, 엄청난 양이고 공격 표면도 넓다!

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

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

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

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

Rust의 강점을 잘 활용하면 C의 성능에 맞먹을 수 있다. 적어도 이를 막는 기술적 한계는 없다. 그리고 개인적으로는 Rust에서는 메모리 안전성 버그를 걱정하지 않아도 되니 코드를 더 공격적으로 최적화하려는 의지가 생긴다. 나만 그런 것 같지는 않다.

“업계에서는 필요성보다 참신함을 보상한다”

이 주장은 대부분의 성공적인 기업(Google, Meta 등)이 최신 유행 언어가 아니라 오랜 시간 검증된 기술 스택을 주로 사용한다는 사실을 간과한다. 이들 기업은 코드베이스가 방대해서 모든 걸 최신 유행 언어로 다시 작성할 여유가 없다. 하지만 새로운 컴포넌트에 Rust를 사용하고 기존 컴포넌트를 점진적으로 다시 작성하는 것의 가치를 인정한다. 70%의 보안 취약점이 메모리 안전성 문제이고, 이런 문제를 고치는 데 엄청난 비용이 들기 때문이다. 새로운 언어로 갈아타지 않고 해결할 수 있다면 이들 기업이 마다할 이유가 없다.

게다가 Rust는 더 이상 그리 새로운 언어도 아니다. Rust 1.0은 10년 넘게 전에 출시됐다! 업계의 움직임은 느리지만, 그렇다고 그 정도로 느리지는 않다. 얼마나 많은 기존 기업들이 Rust를 “참신함”이라고 생각하지도, 굳이 알리지도 않으면서 사용하고 있는지 알면 놀랄 것이다.

“100% 조직적으로 꾸며진 일이다”

Twitter 스레드에서는 여러 사람이 이를 개발자들이 더 나은 도구를 선택한 결과가 아니라 어떤 조직적인 대형 계획이라고 확신하고 있었는데, 정작 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 팟캐스트를 들어보라.

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