# 러스트의 한계, 또는 아마존, 클라우드플레어, 디스코드를 따라 하면 안 되는 이유 "러스트(Rust)가 이 프로젝트에 적합한가?" 이 질문을 꽤 자주 받는다. 고통스럽고 비용이 많이 드는 실수를 피하는 데 도움이 될 수 있도록 내 생각을 정리할 때가 된 것 같다. 짧게 답하면 **아마도 아니다(팀이 이미 러스트 전문가들로 가득한 경우가 아니라면)**. "하지만 아마존, 클라우드플레어, 구글, 메타, 디스코드 등이 모든 것을 러스트로 옮기고 있다면, 우리도 따라야 하는 것 아닌가?" 아니다. [러스트에 관한 책(Black Hat Rust)을 쓴](https://kerkour.com/black-hat-rust) 사람이 이런 말을 하니 놀랄 수도 있다. 하지만 나처럼 설명 없는 짧은 답변에 만족하지 못한다면, 계속 읽어보라. 러스트 컴파일러가 강제하는 정확성은 일부 프로젝트에서 많은 시간을 절약해 준다. 반면 생태계의 분열은 다른 프로젝트에서 많은 시간을 낭비하게 만들며, 한 가지 큰 단점 때문에 러스트를 선택한 것을 후회하게 될 수도 있다. ## 러스트는 과도하게 홍보된다 러스트는 [10년 연속 스택 오버플로가 선정한 가장 원하는/존경받는 언어](https://survey.stackoverflow.co/2025/technology#2-programming-scripting-and-markup-languages)다. 하지만 실제 **사용량** 기준으로는 14위에 불과하다. 사람들이 원하는 것과 현실에서 실제로 하는 일 사이에는 뚜렷한 괴리가 있다. 때로 러스트는 _메타버스(metaverse)_와 비슷하다는 생각이 든다. 많은 사람이 이야기하지만, 실제로 그 안에서 하루를 보내는 사람은 많지 않다. ## 비동기(async)는 어렵다 러스트 코드를 감사할 때 가장 먼저 하는 일은 실행기(executor)를 블로킹하는 동기 함수가 있는지 찾는 것이다. 이는 디버깅하기 어려운 성능 불일치나 잠재적인 서비스 거부(Denial of Service, DoS) 공격으로 이어지는 경우가 많다. 수천 줄이 넘는 코드베이스에서 이벤트 루프를 블로킹하는 사례가 하나도 없었던 프로젝트는 기억나지 않는다. 또한 `async`는 러스트에서 가장 유명하면서도 악명 높은 기능인 소유권(ownership)을 이해하고 설계하기 어렵게 만든다. 제네릭, 수명(lifetime), 비동기가 함께 작동하는 방식 때문에 요구사항이 바뀌면 기존 소유권 가정이 더는 유효하지 않을 수 있다. 그 결과 지나치게 많은 코드를 수정해야 하는 일도 드물지 않다. 하지만 내 경험상 `async`의 가장 큰 단점은 생태계 분열이다. 이제 동기 함수와 라이브러리, `async` 함수와 라이브러리가 있으며, 서로 호환되지 않는 여러 런타임도 존재한다. 따라서 I/O에는 전용 라이브러리가 필요하다. 물론 _sans-IO 패턴(sans-IO pattern)_을 사용한다면 예외다. 파이썬을 사용하는 친구와 이야기했을 때도 똑같은 문제를 겪고 있다고 했다. `async` 코드에서 동기 코드를 호출할 수 있도록 래퍼를 작성하는 데 많은 허드렛일이 생긴다는 것이다. ## 러스트 프로젝트는 퇴화한다 2020년 1월부터 2026년 5월까지 러스트는 [54번의 릴리스](https://github.com/rust-lang/rust/blob/master/RELEASES.md)를 내놓았다. 변경 로그만 7,500줄에 이른다. 초보자를 더욱 혼란스럽게 하는 러스트 "에디션(edition)"은 아직 언급하지도 않았다. 사용자 문제를 해결하는 일만으로도 충분하지 않다고 생각했다면, 이제 6주마다 툴체인, 도커파일, 의존성 등을 업데이트해야 한다. [프로그래밍 언어는 제품이 아니라 플랫폼이다](https://kerkour.com/programming-languages-are-platforms). 개발자가 도구와 씨름하는 데 대부분의 시간을 쓰지 않도록, 프로그래밍 언어는 안정적이어야 하며 천천히 발전해야 한다. 기능은 시간이 갈수록 누적되며 관리할 수 없는 복잡성을 낳는다.  너무 빠르게 변화하는 언어는 생태계에 큰 혼란을 가져온다. 일부 개발자는 라이브러리에 _이달의 새 기능(the new feature of the month)_을 넣고 싶어 한다. 하지만 실제로는 거의 가치가 전달되지 않는 허드렛일만 늘어난다. 현업™에서는 프로젝트를 3년 이상 전혀 건드리지 않다가 갑자기 업데이트해야 하는 일이 드물지 않다. 54개 버전 뒤처진 서비스의 의존성을 업데이트하라는 임무를 맡았다고 상상해 보라. 같은 기간 고는 12번, Node.js는 12번(그중 LTS는 6번), 파이썬은 5번 릴리스됐다. ## 러스트의 가장 큰 약점: 빈약한 표준 라이브러리 [러스트는 고급 이론으로 뒷받침되는 강력한 언어에 모든 것을 걸고 있다](https://kerkour.com/programming-vs-software-engineering-rust-vs-go). 하지만 개발자가 비즈니스 문제를 해결하는 데 언어만으로는 부족하다는 사실을 놓쳤다. 매번 바퀴를 다시 발명하지 않게 해 주고 많은 시간을 절약해 주는 강력한 라이브러리 생태계도 필요하다. 안타깝게도 러스트 라이브러리 생태계는 미성숙한 정도가 아니라 그보다 더 심각하다. [hyper](https://crates.io/crates/hyper), [regex](https://crates.io/crates/regex), [tokio](https://crates.io/crates/tokio)처럼 다른 어떤 생태계와도 비교하기 어려울 만큼 뛰어난 라이브러리도 있다. 하지만 이들은 "공식" 라이브러리가 아니다. 즉, 러스트 프로젝트나 [러스트의 확장 표준 라이브러리(Rust's extended standard library)](https://kerkour.com/rust-extended-standard-library)에 속하지 않는다. 그 결과 날짜·시간 및 암호화 라이브러리처럼 모두에게 필요한 라이브러리가 끊임없이 바뀐다. 시간이 흐를수록 생태계는 더 분열되는 듯하다. 매달 새 라이브러리가 나타나고, 그만큼 자주 다른 라이브러리가 버려진다. 예를 들어, 방금 작업 중인 _작은(small)_ 프로젝트의 의존성을 살펴봤다. 암호화 라이브러리가 5개 이상이나 있었다. 서로 다른 두 버전의 [ring](https://crates.io/crates/ring), [aws-lc-rs](https://crates.io/crates/aws-lc-rs), [boring](https://crates.io/crates/boring), 그리고 [RustCrypto](https://github.com/RustCrypto)의 여러 라이브러리다. 각 의존성이 암호화 기본 기능에 서로 다른 라이브러리를 선택했기 때문이다. 이는 터무니없다. 우선 [공급망 공격 진입점](https://kerkour.com/rust-supply-chain-nightmare)을 대폭 늘린다. 또한 이 모든 라이브러리를 감사할 방법도 없다. FIPS 검증 모드를 제공하는 것은 `aws-lc-rs`와 `boring`뿐이다. [고(Go)에서는](https://kerkour.com/programming-vs-software-engineering-rust-vs-go) 표준 라이브러리에 필요한 모든 암호화 기본 기능이 들어 있으며, 모두 전문가가 작성하고 감사했다. 하나의 생태계에 노력을 집중할 때 얻는 힘이 바로 이것이다. 러스트의 악명 높은 가파른 학습 곡선은 아예 언급하지도 않았다. 러스트 프로젝트를 방치해 썩지 않게 하려고 들여야 하는 노력에 비하면 이는 아무것도 아니다. ## 러스트가 빛나는 분야 요약하면, C/C++를 대체하는 용도다. ### 크로스플랫폼 앱의 공통 코어 모든 조직이 크로스플랫폼 애플리케이션을 만들어야 하는 것은 아니다. 하지만 오늘날 러스트의 가장 빠르게 성장하고 성공한 활용 사례는 아마도 공통 코어 또는 공유 라이브러리를 구축하는 일일 것이다. 이렇게 만든 코드는 모바일 플랫폼, 컴퓨터, WebAssembly를 통한 웹, 심지어 서버에서도 사용할 수 있다. 러스트는 메모리 안전성과 패키지 관리자를 제공하면서 이 모든 플랫폼을 대상으로 할 수 있는 유일한 프로그래밍 언어다.  크로스플랫폼 앱 개발은 원래 매우 어렵고 비용도 많이 든다. 러스트는 이를 더 어렵게 하지 않으며, 오히려 더 쉽고 저렴하게 만든다. 자세한 내용, 아키텍처 분석, 코드 예제는 [크로스플랫폼 러스트: 왓츠앱, 시그널 등이 수십억 대의 기기에 러스트를 배포하는 방식 분석](https://kerkour.com/rust-cross-platform-apps)과 [사례 연구: 프로톤이 수백만 명을 위한 안전한 크로스플랫폼 애플리케이션을 구축하는 데 러스트를 사용하는 방법](https://kerkour.com/proton-apps-rust)을 참고하라. ### 시스템 프로그래밍 매우 적은 리소스를 사용하므로, 러스트는 시스템 데몬과 운영체제에 연동해야 하는 백그라운드 프로그램에 완벽하게 맞는다. 고도 바짝 따라오고 있지만 심각한 바이너리 비대화 문제가 있다. [파이어크래커 심층 분석: 러스트와 마이크로VM이 클라우드 인프라를 혁신하는 방식](https://kerkour.com/firecracker-deep-dive-rust)과 [공격 보안에 러스트를 사용하는 이유](https://kerkour.com/why-rust-for-offensive-security)를 참고하라. ### 임베디드 개발 이런 말이 있다. IoT(Internet of Things, 사물 인터넷·연결 기기)의 S는 보안(Security)을 뜻한다. 임베디드 개발은 오랫동안 열악한 개발 관행과 툴킷, 실시간 OS로 인한 복잡성, 심각하게 오래된 의존성, 지나치게 많은 취약점에 시달려 왔다. 그래서 임베디드 업계는 러스트로 전환하고 있다. 아직은 전환 속도가 다소 느리다. 칩 제조사가 프로덕션 수준의 러스트 HAL(Hardware Abstraction Layer, 하드웨어 추상화 계층)과 SDK를 항상 제공하는 것은 아니기 때문이다. 하지만 점점 더 많은 제조사가 이를 제공하고 있으며, 투자 대비 큰 효과를 보고 있다. 오늘날 러스트와 함께 사용할 수 있는 대표적인 마이크로컨트롤러는 RISC-V 기반 ESP32-C3 / ESP32-C6 / ESP32-C5 계열일 것이다. 에스프레시프(Espressif)가 제공하는 뛰어난 HAL과 커뮤니티가 구축한 건전한 패키지 생태계를 모두 갖추고 있다. ESP32-C6에서 러스트를 컴파일하고 실행하는 데는 문자 그대로 명령 두 개면 충분하다. ``` $ rustup target add riscv32imac-unknown-none-elf $ cargo run ``` nRF5xxx, RP2040 및 RP2350, STM32 마이크로컨트롤러도 상당히 성숙한 HAL과 SDK를 갖추고 있다. 임베디드 러스트를 시작하려면 [러스트 임베디드 개발 입문: 생태계 개요](https://kerkour.com/introduction-to-embedded-development-with-rust)와 [러스트 및 ESP32-C6 마이크로컨트롤러로 침투 테스트 장치 구축하기](https://kerkour.com/rust-esp32-pentest)를 참고하라. ### 데이터베이스 데이터베이스에는 성능, 네트워킹, 고수준 추상화가 필요하므로 러스트가 완벽하게 맞는다. 자세한 내용은 [모든 데이터베이스는 결국 러스트로 (재)작성될 것이다](https://kerkour.com/rust-databases)를 참고하라. ### 터무니없이 큰 규모에서 작업할 때 마지막으로, 당신이 AWS나 클라우드플레어이거나 초당 엄청난 수의 트랜잭션을 처리하는 차세대 데이터베이스를 구축하고 있다고 하자. 서버에서 메모리 1바이트와 CPU 시간 1마이크로초까지 짜내야 한다면, 러스트는 필요한 모든 제어 기능을 제공하면서도 고수준 추상화를 사용할 수 있게 해 주므로 적합하다. 생태계 때문에 고보다 속도가 느려질 수는 있다. 하지만 대규모 환경에서는 정확성과 성능을 보장하는 러스트의 타입 시스템이 이를 보완해 준다. 러스트는 제로 비용 추상화(zero-cost abstractions) 외에도 메모리 할당자 변경처럼 특정 워크로드에 맞게 프로그램을 조정하는 데 필요한 모든 제어 수단을 제공한다. [jemalloc으로 러스트 메모리 파편화 방지하기](https://kerkour.com/rust-jemalloc)와 [클라우드플레어가 러스트로 초당 5,000만 건 이상의 요청에서 수백만 개 웹사이트를 제공하고(또 망가뜨리는) 방식](https://kerkour.com/how-cloudflare-uses-rust)을 참고하라. ### 백엔드 서비스(팀이 이미 러스트를 좋아한다면) 사람으로 구성됐든 AI 에이전트로 구성됐든, 팀이 이미 러스트에 폭넓은 경험이 있고 그 단점을 헤쳐 나가는 방법을 안다면 러스트는 거의 모든 프로젝트에 적합할 수 있다. 고급 컴파일러와 타입 시스템 덕분에 많은 시간과 노력, 비용을 절약할 가능성도 크다. [Axum, SQLx, PostgreSQL로 러스트 중간 규모 웹 서비스 설계 및 구축하기](https://kerkour.com/rust-web-services-axum-sqlx-postgresql)를 참고하라. "안다(knows)"가 아니라 "좋아한다(loves)"라고 한 이유가 있다. 백엔드 서비스의 황금 표준인 고와 비교하면, 러스트 코드베이스를 유지 관리하는 데는 필연적으로 더 많은 리소스가 든다. 따라서 의존성 관리와 같이 당장 비즈니스 가치를 제공하지 않는 일을 기꺼이 할 열정이 필요하다. 그리고 그것은 전혀 문제 될 것이 없다. ## 마무리 생각 이제 너무 늦기 전에 러스트를 배우고 현대 소프트웨어 개발 열차에 올라타려면 어떻게 해야 할지 궁금할 수 있다. 누군가가 당신의 꿈의 직업을 가져가기 전에 말이다. 좋은 소식이 있다. SIMD 프로그래밍을 배우고 싶다면 [순수 러스트로 하는 SIMD 프로그래밍](https://kerkour.com/introduction-rust-simd)을 살펴보라. 러스트 백엔드 개발을 배우고 싶다면 [Axum, SQLx, PostgreSQL로 러스트 중간 규모 웹 서비스 설계 및 구축하기](https://kerkour.com/rust-web-services-axum-sqlx-postgresql)를 참고하라. 응용 암호학을 배우고 싶다면 [암호학적 올바른 답: 포스트 양자 및 러스트 에디션](https://kerkour.com/post-quantum-cryptography-recommendations-rust)부터 시작하라. 마지막으로, 내 책 [블랙 햇 러스트(Black Hat Rust)](https://kerkour.com/black-hat-rust)에서는 러스트가 _무엇인지(what)_만 배우는 것이 아니다. 제네릭, 트레이트, 이터레이터 등이 무엇인지뿐 아니라, 러스트를 _어떻게 사용해야 하는지(how to)_도 배운다. 러스트 프로젝트를 어떻게 설계해야 하는지, 어떤 패턴을 사용하고 어떤 패턴을 피해야 하는지도 다룬다. [블랙 햇 러스트(Black Hat Rust)](https://kerkour.com/black-hat-rust)는 이론에서 실습으로 나아간다. 웹 서버, 종단 간 암호화 원격 접근 도구(Remote Access Tool, RAT), 어셈블리 대신 `#![no_std]`를 사용한 러스트 셸코드 등을 비롯한 다양한 응용 프로젝트를 직접 만들며 배운다. 며칠 또는 몇 주 동안 읽고 코딩하면 프로덕션 수준의 러스트 실력을 갖추게 해 줄 실습 프로젝트들이다. 이 블로그의 [러스트(Rust)](https://kerkour.com/tags/rust) 태그에서도 어렵게 얻은 많은 교훈을 찾을 수 있다. 즐겁게 읽기를 바란다 :)