Rust는 정말 빠른가? 성능의 비밀과 숨겨진 함정들

"Rust는 빠르다"는 말, 어디까지 믿어야 할까

요즘 개발자 컨퍼런스나 블로그를 보면 Rust 이야기가 빠지지 않아요. "C/C++만큼 빠르면서 메모리 안전성까지 보장한다"는 매력적인 슬로건 덕분에 Linux 커널, Windows 커널, 그리고 수많은 인프라 도구들이 Rust로 넘어가고 있죠. 그런데 정작 "Rust가 왜, 어떻게 빠른가?"를 깊게 들여다본 자료는 의외로 많지 않아요.

이번에 GitHub에 공개된 "Performance of Rust Language"라는 슬라이드 자료가 바로 그 빈틈을 채워줘요. 단순히 "Rust 짱"이 아니라, 컴파일러 관점에서 Rust가 어떤 최적화를 받을 수 있고, 어떤 부분에서는 오히려 C보다 불리한지까지 솔직하게 다루고 있거든요. 한국에서 시스템 프로그래밍이나 백엔드 성능 튜닝을 고민하는 분들에게는 꽤 묵직한 인사이트를 주는 자료예요.

Rust가 빠른 진짜 이유

Rust가 빠르다고 할 때, 단순히 "가비지 컬렉터(GC)가 없어서"라고만 설명하는 경우가 많아요. 물론 그것도 맞지만, 더 깊이 들어가면 몇 가지 결정적인 요인이 있어요.

첫째는 소유권(ownership) 시스템 덕분에 컴파일러가 얻는 정보의 양이에요. 일반적인 C 코드에서는 포인터 두 개가 같은 메모리를 가리킬 수 있는지 컴파일러가 알 수 없어요. 이걸 "aliasing 문제"라고 하는데, 이 때문에 컴파일러는 "혹시 모르니까" 최적화를 포기하는 경우가 많거든요. 반면 Rust는 빌림(borrowing) 규칙 덕분에 "이 참조는 절대 다른 참조와 겹치지 않아"라는 보장을 컴파일러에게 줄 수 있어요. 이게 LLVM의 noalias 속성으로 그대로 전달되면서 더 공격적인 최적화가 가능해지는 거죠.

둘째는 모노모피제이션(monomorphization)이라는 제네릭 처리 방식이에요. 이게 뭐냐면, Rust는 제네릭 함수를 쓸 때마다 타입별로 별도의 함수를 만들어요. 예를 들어 Vec<i32>와 Vec<String>은 컴파일 후에 완전히 다른 코드가 되는 거죠. 자바의 제네릭처럼 런타임에 캐스팅하는 오버헤드가 없어요. 대신 컴파일 시간이 길어지고 바이너리 크기가 커지는 단점이 있긴 해요.

셋째는 제로 코스트 추상화(zero-cost abstraction)예요. Iterator 체인을 길게 써도 컴파일러가 그걸 단순한 for 루프로 풀어버려요. 그러니까 코드는 우아하게 짜면서도 어셈블리 수준에서는 손으로 최적화한 C 코드와 비슷한 결과가 나오는 거예요.

그런데 함정도 있다

슬라이드에서 특히 흥미로운 부분은 Rust가 C보다 느릴 수 있는 경우를 솔직하게 짚는다는 거예요.

대표적인 게 panic 처리 비용이에요. Rust는 배열 인덱스에 접근할 때마다 경계 검사(bounds check)를 하거든요. arr[i] 한 줄이 사실은 "i가 범위 안에 있는지 확인 → 아니면 panic" 이라는 두 단계로 컴파일돼요. 컴파일러가 똑똑하게 이 검사를 제거하기도 하지만, 항상 그런 건 아니에요. 성능 크리티컬한 루프에서는 get_unchecked 같은 unsafe 함수를 써야 할 때도 있어요.

또 하나는 Drop 호출 오버헤드예요. Rust는 변수가 스코프를 벗어나면 자동으로 Drop을 호출해서 자원을 정리해주는데, 복잡한 구조체에서는 이 과정이 의외로 무거울 수 있어요. C에서는 그냥 메모리만 해제하고 끝낼 일을, Rust에서는 각 필드를 재귀적으로 정리하니까요.

그리고 링크 타임 최적화(LTO)나 코드젠 유닛 설정에 따라 성능 차이가 크게 나요. 그냥 cargo build --release로 끝내는 게 아니라, Cargo.toml에 lto = true, codegen-units = 1, opt-level = 3 같은 옵션을 잘 챙겨야 진짜 성능이 나와요.

C/C++, Go, Zig와 비교하면

Rust의 위치를 더 잘 이해하려면 다른 시스템 언어들과 비교해보는 게 좋아요. C는 여전히 "컴파일러가 도와주지 않는 대신 개발자가 다 책임지는" 언어예요. 빠르지만 안전하지 않죠. C++는 추상화 도구는 풍부하지만 템플릿 메타프로그래밍이나 헤더 의존성 같은 게 컴파일 시간을 잡아먹어요.

Go는 GC가 있어서 시스템 프로그래밍보다는 서버 애플리케이션에 적합해요. 단순함이 무기지만, 마이크로초 단위 성능을 다투는 영역에서는 한계가 있어요. 최근 주목받는 Zig는 "단순한 C의 대체"를 지향하면서 컴파일 타임 코드 실행 같은 신박한 기능을 제공하지만, 메모리 안전성은 Rust만큼 강하지 않아요.

결국 Rust는 "안전성을 포기하지 않으면서 C 수준의 성능을 노리는" 유일한 메인스트림 옵션이라고 볼 수 있어요. 그게 진입 장벽이라는 비싼 대가를 치르고 얻는 것이긴 하지만요.

한국 개발자에게 주는 시사점

한국에서도 토스의 Sliper, 라인의 인프라 도구, 당근의 일부 백엔드 컴포넌트 등에서 Rust 도입 사례가 늘고 있어요. 특히 고성능 네트워크 서버, 데이터 처리 파이프라인, WASM 기반 프론트엔드에서 Rust의 가치가 빛나요.

하지만 "Rust로 바꾸면 무조건 빨라진다"는 환상은 버려야 해요. 이번 슬라이드가 보여주듯, Rust도 잘못 쓰면 C보다 느릴 수 있고, 진짜 성능을 뽑아내려면 컴파일러가 어떻게 코드를 변환하는지, LLVM IR이 어떻게 생성되는지까지 이해해야 하거든요. 그러니까 Rust를 도입하려면 "문법만 익히는" 게 아니라 벤치마킹 습관과 프로파일링 도구(perf, flamegraph 등) 사용법까지 함께 배우는 게 좋아요.