경험 많은 Rust 개발자 두 명에게 Rust를 배운 노력이 가치 있었는지 물으면 완전히 정반대의 답을 들을 수 있습니다. 한 명은 커리어에 아무 도움이 되지 않았다고 말할 수 있고, 다른 한 명은 자신이 내린 최고의 기술적 결정 중 하나였다고 말할 수 있습니다. 둘 다 옳을 수 있습니다.
바로 이 모순에 ‘Rust는 배울 가치가 있을까’라는 질문의 핵심이 있고, 일괄적인 ‘예’가 여러분에게 쓸모없는 이유도 여기에 있습니다. Rust는 컴파일 언어이며, 그 안전한 부분집합은 런타임에 가비지 컬렉터 없이도 컴파일 시점에 메모리 안전성 규칙을 강제합니다.
그래서 저는 답을 분명히 내리고, 그 답이 기대는 조건을 밝히고, 그 조건에 드는 비용을 보여 드리겠습니다.
요약
Rust는 컴파일러가 특정 부류의 버그를 잡아 주는 데 비용을 치를 가치가 있는, 오래 쓸 무언가를 만든다면 배울 가치가 있습니다. 이번 달 안에 CRUD 앱을 출시해야 하거나, 프로그래밍을 처음 배우거나, 채용 공고 수를 세고 있다면 맞지 않습니다. 평점: 5점 만점에 4점, 본전을 찾기 전에 드는 비용 때문에 감점했습니다.
- 얻는 것: 안전한 Rust에서는 소유권과 빌림 규칙이 use-after-free, 이중 해제, 잘못된 참조, 데이터 경쟁 버그를 프로덕션 장애가 아닌 컴파일 오류로 바꿉니다. 이것이 핵심 장점의 전부이고, 좋은 장점입니다.
- 치르는 것: 컴파일러는 지금 쓰는 언어가 조용히 내려 주던 메모리 결정을 직접 적으라고 요구하며, 초반에는 도구가 까다롭게 구는 것처럼 느껴집니다.
- 지속성 문제는 결론이 났습니다. 커널 메인테이너들은 2025년 12월 Maintainers Summit에서 Rust 실험을 종료하기로 결론 내렸고, Linux 7.0에서 ‘실험적’이라는 딱지가 떨어졌습니다.
- 유행 문제는 결론이 나지 않았고, 이는 다른 질문입니다. Rust는 TIOBE 2026년 9월 지수에서 #10에 올라 있으며, 1년 전 #18에서 상승했습니다.
- 제가 테스트한 Rust 서비스는 실행보다 컴파일에 훨씬 많은 메모리가 필요했습니다. 빌드 중에는 1 GB 가까이 치솟았고, 실행 중 유휴 상태에서는 약 3.5 MB였습니다.
- 이런 분께 맞습니다: 이미 다른 언어로 제품을 출시하고 있고 메모리 버그의 대가가 큰 무언가를 만들고 있거나, 시스템 소프트웨어 가까이에서 일하는 분. 이런 분께는 맞지 않습니다: 마감에 쫓기고 있거나, 완전히 처음 시작하거나, 채용 공고가 가장 많은 언어를 찾고 있는 분.
이 리뷰를 만든 방법: 여기 나온 빌드와 런타임 수치는 제가 직접 측정한 것입니다. Rust 1.98.1을 설치하고 작은 Axum 웹 서비스를 작성한 뒤, 컴파일하는 데 무엇이 들고 실행하는 데 무엇이 드는지 측정했습니다. 전용 하드웨어가 아니라 샌드박스 컨테이너에서 실행했고 프로젝트도 하나뿐이므로, 수치는 법칙이 아니라 하나의 데이터 포인트로 봐 주세요. 나머지는 모두 1차 자료나 권위 있는 출처에서 가져왔습니다. 커널 패치와 이에 대한 LWN의 보도, Google의 Android 보안 게시물, TIOBE 자체 지수(4월 논평은 Slashdot의 기록을 통해), Linux 7.0 머지 윈도에 관한 Phoronix 기사, Binder 취약점에 대한 Linux 커널 CVE 기록, Canonical의 공식 발표, 그리고 2025년 Stack Overflow 설문 조사입니다. 커널 패치는 읽었습니다. 커널 Rust 코드를 감사하지는 않았습니다. 또 저는 Rust를 몇 년씩 써 온 사람이 아니므로, 이 리뷰가 언어 자체를 평가하는 부분은 오래 써 온 실무자들의 글을 읽고 그 이름을 밝히는 방식입니다.
컴파일러가 주는 것
Rust에서 두 스레드에 같은 벡터에 대한 가변 참조를 넘기면 코드가 컴파일되지 않습니다. 경고가 아닙니다. 마감이 급할 때 꺼 버릴 수 있는 lint도 아닙니다. 빌드가 안 됩니다. 이 거부가 바로 안전한 Rust에서 여러분이 사는 것입니다. use-after-free, 이중 해제, 잘못된 참조, 데이터 경쟁 버그가 프로덕션 장애가 아니라 컴파일 오류로 밀려납니다. Rust의 탈출구(unsafe)는 이러한 보장 중 일부를 우회할 수 있으므로, 이것이 모든 Rust 코드베이스에 대한 절대적인 약속은 아닙니다.
소유권이란 모든 값에 그 값을 해제할 책임이 있는 소유자가 정확히 하나 있다는 뜻입니다. 빌림이란 참조를 빌려줄 수 있다는 뜻이지만, 컴파일러는 그 수명을 추적해서 참조가 가리키는 대상보다 오래 살거나 가변 빌림이 다른 빌림과 공존하는 것을 허용하지 않습니다. 안전한 Rust에서는 use-after-free, 이중 해제, 잘못된 참조, 데이터 경쟁 버그가 프로그램이 실행되기 전에 소유권과 타입 시스템에 의해 잡힙니다.
가비지 컬렉터가 없다는 것이 거래의 나머지 절반입니다. 누가 무엇을 언제 해제할지 소유권이 이미 정해 두므로, 런타임에 힙을 추적할 필요가 없습니다. 컬렉터가 들어 있지 않은 바이너리를 배포하고, 튜닝해 가며 피해야 하는 일시 정지 시간도 생기지 않습니다.
대가는 보장과 같은 곳에서 나타납니다. 지금 쓰는 언어가 여러분 대신 조용히 내려 주던 메모리 결정 하나하나를 Rust는 직접 적으라고 요구합니다. 이것은 누가 소유하는지, 그 참조는 얼마나 오래 사는지, 다른 무언가가 그것을 볼 수 있는지, 스레드 경계를 넘는지. 컴파일러가 까다롭게 구는 게 아닙니다. 추측하기를 거부하는 것입니다.
그러니까 이것이 누구든 Rust가 요구하는 대가를 치르는 이유이고, 저는 충분히 설득력이 있다고 봅니다. Rust가 없애 주는 부류의 버그가 여러분이 걱정하는 부류가 아니라면, 이 리뷰의 나머지 부분도 아마 생각을 바꾸지 못할 겁니다.
Rust는 아직 실험 단계일까, 아니면 이제 프로덕션 인프라일까?
Rust는 2025년 12월에 실험 단계를 벗어났고, 이를 끝낸 것은 다름 아닌 커널 메인테이너들이었습니다. 2025 Maintainers Summit에서 그들은 Rust가 기술적으로나 사회적으로나 커널에서 제 몫을 해냈다고 결론 내렸습니다. LWN의 Jonathan Corbet은 2025년 12월 10일 그 합의를 이렇게 전했습니다. 커널의 Rust는 더 이상 실험적이지 않습니다.
Rust는 바로 그 실험을 위해 2022년 v6.1에서 메인라인 Linux에 들어갔습니다. 딱지를 떼는 Miguel Ojeda의 패치는 Summit 사흘 뒤에 나왔고, Linux 7.0 머지 윈도에 반영되었습니다.
“하지만 실험은 끝났다. 즉, Rust는 계속 남는다.”
Miguel Ojeda, “rust: conclude the Rust experiment”, LKML, 2025년 12월 13일
이와 별개로, 그리고 그보다 앞서, Google이 Rust로 다시 작성한 Android의 Binder 드라이버, 즉 Android 프로세스들이 (끊임없이) 통신에 사용하는 IPC 계층이 Linux 6.18에 들어갔습니다. 6.18은 2025년 11월 30일에 출시되었습니다. 이 이정표는 Summit의 합의와 구분해서 보세요. 메인테이너 그룹이 아이디어에 축복을 내린 것이 아니라, 한 기업이 출시 제품을 커널 Rust에 건 사건입니다. 그 후 커널 Rust는 첫 CVE를 냈습니다: CVE-2025-68260, 같은 Binder 드라이버의 경쟁 상태 버그로, Greg Kroah-Hartman이 2025년 12월 16일에 발표했으며 6.18에서 들어와 6.18.1에서 수정되었습니다. 초기 보도는 크래시에 초점을 맞췄지만, Linux 커널 CVE 팀의 이후 점수 평가는 CVE-2025-68260을 7.8(High)로 매기고 커널 메모리 손상을 통한 로컬 권한 상승 경로를 설명합니다. 같은 드라이버(rust_binder)에서는 그 뒤로도 CVE가 추가로 쌓였습니다.
Android에서는 증거가 숫자로 나옵니다. Google의 보안 블로그는 2022년 12월, Android의 Rust 코드에서 발견된 메모리 안전성 취약점이 0건이었다고 밝혔습니다. 당시 AOSP의 Rust 코드는 약 150만 줄, Android 13 신규 네이티브 코드의 약 21%였습니다. 2022년 범위에 대한 2022년 발표라는 점을 기억하세요. Google의 이후 게시물은 더 긴 추세를 보여 줍니다. 메모리 안전성 문제는 2019년 Android 취약점의 76%를 차지했지만 2024년에는 24%로 줄었고, 실제 건수도 220건 이상에서 36건(예상)으로 떨어졌습니다. 이 수치들은 대체한 기준과 비교할 때만 의미가 있는데, 그 기준은 아주 뛰어난 엔지니어들이 아주 좋은 도구로 작성한 C와 C++입니다.
같은 방향을 가리키는 작은 신호가 두 가지 더 있습니다. Asahi Linux의 Apple AGX GPU 드라이버는 Rust로 작성되었으며, Apple이 아니라 Asahi Linux 프로젝트가 리버스 엔지니어링 작업으로 만든 것입니다. Canonical의 rust-coreutils 업데이트에 따르면 Ubuntu 26.04 LTS는 대부분의 유틸리티에 rust-coreutils 0.8.0을 탑재합니다. 세 가지는 GNU coreutils로 남는데(cp, mv, rm), 2026년 4월 22일 기준으로 TOCTOU 문제 8건이 아직 해결되지 않았기 때문입니다. Canonical은 나머지 유틸리티를 26.10에서 전환하는 것을 목표로 하고 있습니다.
제가 가장 높은 점수를 주는 축이 바로 이것이고, 그 이유는 여기 걸린 약속의 성격에 있습니다. 커널 메인테이너들은 결론 낸 실험을 되돌리지 않고, Google은 그 규모의 재작성을 되돌리지 않으며, Canonical은 어떻게 되나 보려고 다시 작성한 coreutils를 LTS에 넣지 않습니다. Rust의 인기가 어떻게 되든, 누군가는 그 코드를 수년간 유지보수해야 합니다.
Rust는 죽었을까, 아니면 성장세가 주춤할 뿐일까?
아닙니다. Rust는 2026년 1월 TIOBE에서 역대 최고 순위인 #13과 타이를 이뤘습니다. 석 달 뒤 #16으로 내려앉았고, TIOBE CEO Paul Jansen은 2026년 4월, 당시 Slashdot이 인용한 논평에서 Rust의 인기 성장세가 “주춤해지는 것 같다”고, 톱 10 진입은 “이전보다 더 멀어 보인다”고 썼습니다.
그가 말한 것은 Rust가 자신의 지수에서 역대 최고 순위에 올랐다가 다시 내려온 일이었습니다. 이 순위는 2024년 7월에 처음 차지했던 자리입니다.
TIOBE의 2026년 9월 지수는 Rust를 #10에 올려놓았습니다. 1년 전 #18에서 상승했고, TIOBE가 1월에 역대 최고라고 불렀던 #13도 넘어섰습니다.
제 해석은 이렇습니다. 정체는 실제였습니다. 다만 천장이 아니라 에어 포켓이었습니다. 이 해석이 어느 진영의 버전보다 낫습니다. “Rust가 멈췄다”는 이제 틀렸고, “Rust는 오르기만 한다”는 한 번도 맞은 적이 없기 때문입니다.
이 단서는 양쪽 모두에 적용되며, Slashdot 기사도 당시 이를 지적했습니다. 순위가 그저 검색 엔진 결과의 월별 노이즈 때문에 오르내리는 것일 수도 있지 않을까? 지수가 세는 것이 바로 그 검색 결과입니다. 한 분기에 세 계단 하락한 것이 Rust가 둔화되고 있다는 약한 증거였다면, 여섯 계단 상승도 Rust가 이기고 있다는 약한 증거일 뿐입니다. 날씨로 보고, 기후로 보지 마세요.
선호도에 관해 더 강한 신호는 Stack Overflow 설문 조사이며, 여기서 Rust는 또다시 가장 존경받는 프로그래밍 언어로 뽑혔습니다(2025년, 72%). 지난 1년간 사용했고 앞으로도 계속 쓰고 싶은 사람의 비율입니다. 이는 도입률이 아니라 계속 사용하려는 의향이며, 이 언어를 꾸준히 즐길 수 있을지 판단하는 중이라면 단순한 인기보다 더 쓸모 있는 신호입니다.
기세는 모호하고, 저는 이를 앞서 다룬 지속성보다 낮게 평가합니다. 여러분이 투자하는 대상은 순위가 아니기 때문입니다.
Rust를 배우는 데 드는 비용
비용은 초반에 한꺼번에 찾아옵니다. Python이나 Java, C#이라면 기꺼이 실행해 줄 코드가 소유권 모델이 이해되기 전까지는 임의적으로 느껴지는 이유로 계속 거부되고, 이를 미룰 방법은 없습니다. ORM을 완전히 이해하지 못해도 일단 출시하며 넘어갈 수 있는 것과 달리, 빌림 검사기는 출시로 넘어갈 수 없습니다.
저를 놀라게 한 부분이 여기 있는데, 예상과 정반대로 흘러갑니다. r/rust의 “Struggling to learn Rust” 스레드에서 가장 큰 호응을 얻은 답글은 문제를 어려움이 아니라 낯섦으로 다시 정의하며, 스레드 전체도 가비지 컬렉션 언어에서 넘어온 숙련 개발자들이 오히려 더 고생한다고 짚습니다. u/Voxelman은 이렇게 잘라 말합니다: “Rust는 어렵지 않습니다. 다를 뿐입니다.” 같은 스레드에서 그들은 자신이 걸어온 길도 설명합니다. C64 Basic에서 시작해 여러 명령형 언어를 거쳤고, 처음 Rust를 접했을 때는 옛 습관을 버리는 데 시간이 걸려서 “전혀 WOW가 아니었다”고 합니다.
청구서의 모양이 바로 이렇습니다. 8년 동안 Python을 써 왔다면, 여러분은 규칙 몇 개를 배우는 게 아니라 누가 뒷정리를 해 주는지에 대한 가정들을 내려놓는 것입니다. 아는 게 적은 사람일수록 버릴 것도 적습니다.
그 스레드에서 반복해서 보이는 패턴이 하나 더 있는데, 이는 순서의 실수를 자신감의 문제로 바꿔 버립니다. 사람들이 Rust 자체가 아니라 웹 프레임워크 선택에서 막히고, 소유권이 자리 잡기도 전에 Axum이나 Actix로 언어를 배우려 한다는 것입니다. u/jmartin2683의 말을 빌리면 그건 “rails를 배우면서 ruby를 배우려는 것과 같다.”
비용에 관한 경고 대부분은 엉뚱한 것을 가리키고 있다고 봅니다. 주말 하루가 아니라 꾸준한 연습 시간을 잡으세요. 그리고 초반의 좌절을 여러분의 능력에 대한 판정으로 받아들이지 마세요.
Rust는 실행보다 빌드에 더 큰 머신이 필요하다
제가 예상하지 못한 발견은 이것입니다. 이 Rust 프로젝트는 빌드하는 데 실행할 때보다 몇 자릿수 더 많은 메모리가 들었습니다. 저는 작은 Axum 서비스(Tokio full 기능 세트, serde, serde_json, tower, JSON 라우트 하나, 의존성 트리에 약 60개 크레이트)를 rustc와 cargo 1.98.1로 빌드했고, 릴리스 프로필에는 strip = true 설정을 넣었습니다. 그런 다음 깨끗한 상태에서 두 번 빌드했습니다:
# constrained: one compile job at a time
cargo build --release --jobs 1
# unconstrained: default parallelism, 4 vCPUs available
cargo build --release컴파일 작업을 하나로 제한했을 때(--jobs 1), cargo, rustc, 링커 전체의 최대 메모리는 두 가지 측정 방식 중 어느 것을 택하느냐에 따라 464 MB에서 527 MB 사이였고(첫 번째 수치가 너무 깔끔해 보여서 두 가지 방식으로 측정했습니다), 113초가 걸렸습니다. vCPU 4개에서 기본 병렬 설정으로는 최대 메모리가 대략 두 배인 약 1 GB가 되었고, 빌드는 약 35초 만에 끝났습니다. 여기서 변수는 프로젝트가 아니라 병렬성입니다. 작업이 많을수록 동시에 상주하는 rustc 프로세스도 많아지며, 그래서 컴파일러는 몇 분 동안 계속 주어진 코어를 모두 기꺼이 가져가는 몇 안 되는 워크로드 중 하나입니다.
완성된 프로그램은 strip 후 1.3 MB이고, 유휴 상태에서 약 3.3~3.6 MB의 메모리를 사용합니다.
기본 병렬 설정에서는 컴파일에 실행보다 200~300배 많은 메모리가 들고, 작업을 하나로 제한해도 여전히 100배를 훌쩍 넘습니다. 프로덕션에서 Rust 서비스에 필요한 만큼만 서버 크기를 잡으면 그 서비스를 빌드할 수 없는 머신이 될 수 있고, 실패 방식도 깔끔한 오류가 아닙니다. 빌드 도중 OOM 킬러가 rustc를 종료시키거나, 컴파일러가 20분 동안 스왑을 헤매게 됩니다. 효과적인 답은 두 가지입니다. 하나는 여유 있는 곳에서 빌드하고 바이너리를 배포하는 것으로, 별도의 빌드 머신을 두는 방식이며 무거운 Docker 작업과 같은 패턴입니다. 다른 하나는 그 머신에서 빌드하되 여유를 주는 것입니다. 이런 형태의 서비스라면 RAM 몇 GB와 vCPU 2개면 넉넉합니다. 그래도 부족하면 탈출구는 --jobs 1 옵션입니다(네, 더 느립니다. 그게 트레이드오프입니다).
작업하는 머신에 그만한 여유가 없다면, 저희 셀프 관리형 Linux VPS 상품이 시간 단위 또는 월 단위 요금제로 root 접근 권한을 제공하고, 빌드를 올려 두었다가 끝나면 반납할 곳이 되어 줍니다. 다만 이는 여전히 여러분이 운영하는 서버이지, 알아서 운영되는 서버는 아닙니다.
프로젝트 하나, 형태 하나, 머신 하나입니다. 머신은 전용 서버가 아니라 공유 샌드박스 컨테이너였고 사용 가능한 메모리는 약 2 GB였으므로, 제한 없는 최고치는 더 큰 머신에서보다 한계에 더 가깝게 돌고 있었습니다. 이것은 보편적인 상수가 아닙니다. 의존성 트리가 네 배 크거나 릴리스 프로필에서 링크 타임 최적화를 켜면 다른 수치를 예상하세요. 의존성 트리가 크거나, 링크 타임 최적화를 쓰거나, 제네릭을 많이 쓰는 코드는 빌드 메모리를 더 끌어올릴 수 있으니, 제 측정값을 보편적인 상한으로 여기지 마세요.
저라면 이 내용을 언어를 배울지 말지가 아니라 어떻게 일할지의 문제로 분류하겠습니다. 부딪히기 전에 알아 두세요.
Rust를 배워야 하는 사람
시간을 들이라고 권할 상황은 세 가지입니다. 메모리 버그의 대가가 큰 장수 소프트웨어, 운영 체제 가까이에서 하는 일, 그리고 컴파일러와 씨름하는 경험이 메모리에 대한 사고방식에 주는 변화를 원할 때입니다. 각각에는 그 시간이 보상받는 이유가 있습니다.
이미 다른 언어로 제품을 출시하고 있고, 메모리 버그의 대가가 큰 장수 소프트웨어를 만들고 있다. 계속 떠 있어야 하는 서비스. 다른 팀들이 의존하는 라이브러리. use-after-free가 터미널의 스택 트레이스가 아니라 사고 검토 회의를 뜻하는 모든 것. 이 보장 전체가 바로 이런 경우를 위해 만들어졌고, 초기에 치르는 비용은 만들고 있는 것의 수명 전체에 걸쳐 상각됩니다.
시스템 소프트웨어 근처나 내부에서 일한다. 드라이버, 디바이스 작업, 기본 시스템 유틸리티, 임베디드 등 운영 체제 위가 아니라 아래에 있는 모든 것. 업계가 다른 곳에서는 하지 않은 방식으로 이 분야에 전념해 왔고, 메모리 안전성 증거도 여기서 가장 강력합니다.
부수 효과를 원한다. 그 r/rust 스레드의 댓글 작성자 두 명은 Rust의 커리어 가치에 대해서는 완전히 의견이 다르지만, 이 지점에서는 같은 결론에 이릅니다. u/tyler_church, 즉 커리어에 미친 영향은 전혀 없었다고 말하는 사람조차 “다른 언어로 다른 프로그램을 작성하는 방식에 어쩌면 미묘한 영향”은 있었다고 인정합니다. u/SirKastic23, 즉 Rust를 써서 돈을 받은 지 2년 된 사람은 예상하지 못한 방식으로 코딩 실력이 넓어졌다고 말합니다. 연구가 아니라 두 사람의 이야기일 뿐이지만, Rust를 직업으로 쓰지 않더라도 남는 보상은 바로 이것입니다. 이력서의 한 줄이 아니라 생각하는 방식의 변화입니다.
Rust를 배우지 말아야 하는 사람
그 시간을 다른 데 쓰는 편이 나은 상황은 세 가지입니다. 이번 달에 마감이 있거나, 프로그래밍 자체를 처음 배우고 있거나, 채용 공고에 얼마나 많이 언급되는지로 언어를 고르고 있는 경우입니다. 사람들이 가장 많이 묻는 것은 세 번째입니다.
이번 달에 CRUD 앱이나 프로토타입 마감이 있다. Rust는 금요일까지 결과물이 있어야 하는 일에는 정확히 최악의 일정으로 다가옵니다. 빠른 빌드와 가비지 컬렉션 방식의 메모리 관리를 갖춘 컴파일 언어를 원하고 Rust의 소유권 기반 보장이 필요 없다면, 대신 Go를 고르는 것이 당연한 선택입니다.
프로그래밍 자체를 처음 배우고 있다. 이 문제는 Rust로 생계를 꾸리는 사람들 사이에서도 정말로 의견이 갈리고, r/rust 스레드들의 논쟁도 양방향으로 흘러갑니다. 그래서 제 입장은, 동전이 어느 쪽으로 떨어지든 초보자에게 동전 던지기를 건네는 것은 나쁜 조언이라는 것입니다. 먼저 더 너그러운 환경에서 컴퓨터가 어떻게 동작하는지 배우고, 그다음 돌아와서 컴파일러가 그것을 조여 주게 하세요.
채용 공고에 얼마나 많이 언급되는지로 언어를 고르고 있다. 여기서는 숫자를 제시하지 않겠습니다. 제가 옹호할 수 있는 출처까지 추적되는 Rust 연봉이나 채용 수치를 찾지 못했기 때문입니다. u/crusoe가 그 r/rust 스레드에서 묘사하는 것은 자리는 더 적고 더 전문화된 시장입니다. 이는 한 스레드의 댓글 한 개일 뿐 노동 시장 데이터가 아니므로, Rust 일자리가 전반적으로 부족하다는 주장으로 바꾸지는 않겠습니다. 채용 규모가 결정 요인이라면 언어를 고르기 전에 목표 시장의 현재 공고를 확인하세요.
자주 묻는 질문
Rust는 무료인가요?
네. 언어와 공식 프로젝트는 일반적으로 이중 라이선스로 MIT 라이선스와 Apache License 2.0에 따라 제공되며, 툴체인은 rustup으로 무료 설치할 수 있습니다. 유료 등급도, 구매해야 할 상용 라이선스도 없습니다.
Rust를 배우는 데 얼마나 걸리나요?
이미 프로그래밍을 한다면 문법은 보통 쉬운 부분입니다. 소유권과 빌림은 메모리에 대한 사고방식을 바꾸기 때문에 더 오래 걸리고, 라이프타임과 비동기 Rust는 나중에 또 한 층을 더합니다. 설득력 있는 보편적 기간을 찾지 못했으므로 숫자를 붙이지는 않겠습니다.
Rust는 첫 프로그래밍 언어로 좋은가요?
제 답은 ‘아니요’지만, 이 질문은 숙련된 실무자들 사이에서도 논쟁 중이라는 점을 알아 두세요. r/rust의 “Struggling to learn Rust” 스레드에서 u/cassepipe 님은 Rust에 한 번 튕겨 나갔다가 C와 C++을 거쳐 돌아온 뒤, Rust는 “좋은 첫 언어가 아니다”라고 딱 잘라 말합니다. 반면 u/Voxelman 님은 정반대로 주장합니다. 명령형 언어는 나중에 버려야 할 습관을 가르치기 때문에 시작하기에 나쁜 곳이라는 것입니다. 같은 논쟁이 Rust 자체 사용자 포럼에서도 네 페이지에 걸쳐 이어집니다. 보고할 만한, 커뮤니티 차원에서 정리된 답은 없습니다.
Rust가 C++을 대체하고 있나요?
아닙니다. Rust는 C와 C++ 옆에 추가되어 특정 신규 구성 요소에 선택되고 있으며, 이는 다른 이야기입니다. Linux 커널에서 Rust는 기존 C 코드베이스를 통째로 대체하는 것이 아니라 그 옆에 추가되고 있습니다. Android에서 Google이 밝힌 접근 방식은 기존 C와 C++을 변환하는 것이 아니라 새 코드를 메모리 안전 언어로 작성하는 것입니다. 오랫동안 공존할 것으로 보세요.
Rust는 Go보다 빠른가요?
이건 벤치마크하지 않았으므로, 어느 쪽이 무조건 더 빠르다고 주장하지 않겠습니다. Rust는 메모리 할당을 더 세밀하게 제어할 수 있고 가비지 컬렉터가 필요 없습니다. Go는 가비지 컬렉션 런타임을 사용하며, 저수준 제어 일부를 내주는 대신 개발을 더 단순하게 만듭니다. 어느 쪽이 더 빠른지는 워크로드, 구현, 병목에 따라 달라지므로, 여러분의 애플리케이션과 비슷한 벤치마크를 사용하세요.
토론
댓글
토론에 참여하려면 로그인하세요.