언어 문법이 아니라, Rust가 지금 산업 현장에서 어떤 자리를 대체하고 있는지를 여섯 가지 사례로 살펴본다. 성능이 필요한 곳에는 늘 C/C++가 있었다. 그 자리에 지금 Rust가 들어가는 이유를 실제 사건과 수치로 확인한다.
커널은 메모리 안전성과 성능이 가장 첨예하게 충돌하는 영역이다. 버그 하나가 시스템 전체의 권한을 내주기 때문에, 그동안 C의 자리를 대체할 언어가 나타나기 어려웠다. Rust는 런타임 오버헤드 없이 소유권 규칙으로 이 문제를 풀겠다는 제안을 들고 커널에 들어왔고, 드라이버처럼 상대적으로 격리된 영역부터 점진적으로 침투했다.
Linux 커널은 2022년부터 "Rust for Linux" 프로젝트를 통해 실험적으로 Rust 코드를 받아들이기 시작했다. 2025년 12월, 커널 메인테이너들은 Rust 지원을 더 이상 실험적이지 않다고 선언했고, 2026년 2월 출시된 Linux 7.0에서는 공식적으로 "Rust 실험"이 종료되었음을 명시했다. 즉 지금은 "Rust를 써도 되는가"가 아니라 "Rust로 무엇을 더 옮길 것인가"를 논의하는 단계다.
Windows도 같은 방향으로 움직이고 있다. Microsoft의 한 Distinguished Engineer는 2030년까지 Windows 코드베이스에서 C/C++을 제거하겠다는 목표를 공개적으로 제시했고, 실제로 Windows 커널 일부에 Rust 코드가 배포되고 있다.
Google은 Android 운영체제의 Rust 코드가 C/C++ 코드 대비 약 1000배 낮은 메모리 안전 취약점 밀도를 보인다고 보고했다. 이는 "Rust가 안전하다"는 주장이 아니라, 실제 배포된 대규모 코드베이스에서 측정된 수치라는 점에서 커널 도입 논쟁의 핵심 근거로 쓰인다.
Python은 인터프리터 언어라서 언어 자체의 실행 속도는 느리지만, 그 위에서 돌아가는 툴(린터, 패키지 매니저, 포매터)까지 느릴 필요는 없다. 과거에는 이런 인프라 도구를 C로 다시 짜는 것이 일반적이었는데, 최근 몇 년 사이 이 자리를 Rust가 대체하고 있다.
ruff — Flake8과 수십 개의 플러그인을 대체하는 린터 겸
포매터. 기존 Python 기반 린터보다 수십~수백 배 빠르다고 알려져 있다.uv — pip, virtualenv, poetry, pyenv의 역할을 하나로
묶은 패키지·프로젝트 매니저.pydantic-core, polars — 데이터 검증과
데이터프레임 처리처럼 연산량이 많은 영역을 Rust로 재작성한 사례.maturin / PyO3 — Python 확장 모듈 자체를
Rust로 작성할 수 있게 해주는 브릿지. 위 도구들이 이 위에서 만들어졌다.두 도구 모두 Astral이라는 한 회사가 만들었다는 점도 눈여겨볼 만하다. "Python 생태계의 느린 부분을 Rust로 재작성한다"는 전략을 하나의 제품 전략으로 밀고 나간 사례다.
Astral이 공개한 벤치마크에 따르면 uv는 캐시가 없는
상태에서도 pip보다 최대 약 10배, 전역 캐시가 준비된 일상적인
개발 환경에서는 최대 약 100배 빠른 설치 속도를 보인다.
grep, find, cat, ls
같은 명령어는 1970~80년대 C 코드가 지금도 거의 그대로 쓰이는
영역이다. 오래 검증되어 안정적이지만, 동시에 수십 년 묵은 메모리
안전성 문제를 안고 있기도 하다. ripgrep(grep),
fd(find), bat(cat),
eza(ls), zoxide(cd) 같은 Rust 재구현체들이
이 자리를 하나씩 대체하고 있다.
이 흐름에는 두 가지 서로 다른 동기가 섞여 있다. 하나는 속도이고,
다른 하나는 보안이다. 두 동기가 함께 드러나는 가장 분명한 사례가
sudo-rs다.
ripgrep 프로젝트는 공식 저장소에 GNU grep, ag, ack 등과의 비교 벤치마크를 공개하고 있으며, 대용량 코드베이스를 정규식으로 검색하는 전형적인 시나리오에서 GNU grep보다 눈에 띄게 빠른 결과를 꾸준히 보여준다.
sudo는 root 권한 승격을 담당하는, 시스템에서 가장 민감한 바이너리 중 하나다. 그런데 2021년 보안 업체 Qualys는 C로 작성된 sudo에서 10년 가까이 방치되어 있던 힙 버퍼 오버플로우 취약점(CVE-2021-3156, 일명 "Baron Samedit")을 발견했다. 일반 사용자가 이 취약점만으로 root 권한을 얻을 수 있었다.
이 사건은 비영리 보안 이니셔티브 Prossimo가 sudo와 su를 Rust로
완전히 재작성하는 sudo-rs 프로젝트를 시작하는 계기가
됐다. sudo-rs는 2025년 10월 Ubuntu 25.10부터 기본 sudo로 채택되었고,
2026년 4월 출시된 Ubuntu 26.04 LTS에서도 기본값을 유지하며 주요
배포판 중 처음으로 "메모리 안전 sudo"를 기본 탑재한 사례가 되었다.
WebAssembly(WASM)는 GC 없이 실행되는 저수준 바이트코드 포맷이라, Rust처럼 GC가 없는 언어와 잘 맞는다. 그 결과 Rust는 WASM 생태계에서 사실상 기본 언어에 가까운 위치를 차지하고 있다. 쓰이는 무대는 크게 둘로 나뉜다.
wasm-bindgen과
wasm-pack을 이용해 Rust 코드를 WASM으로 컴파일하고
JavaScript와 상호운용한다. 이미지·오디오 처리, 게임 엔진의 핵심
연산처럼 순수 JS로는 성능이 부족한 영역에 쓰인다.
(이 영역은 특정 벤치마크 하나로 요약하기보다, 채택 사례 자체가 증거에 가깝다 — Figma, 1Password 같은 회사들의 브라우저 제품과 Cloudflare, Fastly의 엣지 런타임이 실제 프로덕션에서 Rust→WASM 경로를 쓰고 있다.)
GPU 프로그래밍(CUDA)과 임베디드는 C/C++가 가장 오래, 가장 굳건하게 자리 잡고 있는 영역이다. 오랫동안 rust-cuda, cudarc 같은 커뮤니티 프로젝트가 이 벽을 두드려 왔는데, 2026년 9월 8일 NVIDIA가 직접 "CUDA Rust"를 공식 발표하면서 상황이 바뀌었다. 이제는 "커뮤니티가 비공식으로 시도하는 영역"이 아니라 "NVIDIA가 직접 투자하는 영역"이 됐다.
CUDA Rust는 두 갈래(track)로 나뉜다. GPU 커널을 Rust로 직접 컴파일하는 길이 열렸다는 점이 핵심이다 — 지금까지는 Rust에서 CUDA 커널을 "실행"할 수는 있어도, 커널 본체는 결국 C++로 짜야 했다.
두 프로젝트 모두 Rust의 소유권 규칙으로 GPU 메모리 접근 충돌(스레드 수천 개가 같은 버퍼에 동시에 접근하는 문제)을 컴파일 타임에 잡아낸다. 예를 들어 출력 버퍼를 입력으로도 함께 넘기는 코드는 두 트랙 모두에서 컴파일 자체가 거부된다.
NVIDIA는 두 프로젝트 모두 아직 "프로덕션 준비 단계는 아니다"라고 스스로 명시했다. 다만 cutile-rs는 이미 Hugging Face의 추론 엔진 Grout와 mistral.rs 같은 외부 프로젝트에서 쓰이기 시작했다는 점도 함께 밝혔다. 즉 이 영역은 여전히 "초기 단계"이지만, 그 초기 단계의 성격이 "커뮤니티 실험"에서 "제작사 공식 투자"로 바뀐 것이 이번 발표의 의미다.
임베디드 영역에서는 #![no_std]와
embedded-hal을 중심으로, 운영체제 없이 마이크로컨트롤러
위에서 직접 동작하는 Rust 코드가 실제 제품에 쓰이고 있다. 새로운
하드웨어 타겟이 나올 때마다 Rust 지원이 뒤따라오는 패턴이 이제
GPU에서도 반복되는 셈이다.
앞의 다섯 사례가 모두 "기존 C/C++ 시스템에 Rust를 점진적으로 얹는" 방식이었다면, Redox OS는 정반대 접근이다. 커널부터 드라이버, 셸까지 전체 운영체제를 처음부터 Rust로 작성하는 실험적 프로젝트다. 마이크로커널 구조를 채택했으며, "레거시 호환을 신경 쓰지 않고 Rust로 OS를 새로 짜면 어디까지 갈 수 있는가"를 보여주는 사례로 의미가 있다.
상용 환경에 바로 쓰이는 프로젝트는 아니지만, 학부생 입장에서는 오히려 이런 프로젝트가 더 유용할 수 있다. Linux처럼 이미 수천만 줄이 쌓인 코드베이스가 아니라, 처음부터 Rust스러운 설계 원칙 위에서 OS 구조를 읽어볼 수 있기 때문이다.