이 게시물의 구체적 근거에는 꽤 중요한 문제가 있습니다.
속지 마십시오.
Android에서 메모리 안전 취약점 비중이 2019년 76%에서 2024년 24%, 2025년에는 20% 미만으로 감소한 것은 Google이 공개한 결과와 부합합니다. 그러나 Google은 이를 러스트 하나의 효과가 아니라 신규 코드를 여러 메모리 안전 언어로 전환한 전략, 기존 코드의 숙성, 샌드박싱과 다른 병행 개선이 함께 작용한 결과로 설명합니다.
“러스트가 C/C++보다 취약점 밀도가 1,000배 낮다”는 수치도 Google의 공식 발표에 있습니다. 다만 약 500만 줄의 Android Rust 코드에서 발견된 한 건의 출시 전 잠재 취약점과 역사적 C/C++ 자료를 이용한 추정입니다. 모든 프로젝트와 모든 결함 유형에 적용되는 통제 실험 결과는 아닙니다.
2. 227만 명의 출처가 잘못 연결됐습니다
약 226만 7천 명이라는 수치는 JetBrains가 2024 Developer Ecosystem 조사를 바탕으로 추산한 값입니다. 2025 State of Rust Survey가 생태계 인구를 227만 명으로 집계한 것이 아닙니다. 2025 State of Rust Survey는 7,156명의 응답을 받았으며, Rust 프로젝트 자체도 이 표본에서 전체 사용자 수를 과도하게 추정해서는 안 된다고 명시합니다.
3. Linux 커널 인용은 사실이지만 의미가 확대됐습니다
Miguel Ojeda는 2025년 12월 커널 메일링 리스트에서 “실험은 끝났고 러스트는 남는다”고 썼습니다. 다만 같은 글에서 모든 아키텍처·커널 설정·툴체인 조합이 완성됐다는 뜻은 아니며, 여전히 많은 작업과 실험적 조합이 남아 있다고 명시했습니다. “지원이 영구화됐다”와 “커널 개발의 보편적 표준이 됐다”는 같은 말이 아닙니다.
4. Discord의 ‘P99 50% 감소’는 공식 글에서 확인되지 않습니다
Discord 공식 글은 Go 구현의 주기적 지연 스파이크가 사라졌고, 최적화 후 Rust 구현이 지연 시간·CPU·메모리에서 더 나았다고 설명합니다. 그러나 본문에는 P99가 50% 감소했다는 수치가 없습니다. 오히려 Discord는 이 사례가 특정 캐시 구조와 오래된 Go 1.9 계열 구현에 관한 것이며, 모든 것을 Rust로 다시 쓰라는 뜻은 아니라고 명시했습니다.
5. Pingora 수치는 맞지만 성과 전체를 언어에 귀속할 수 없습니다
Cloudflare가 발표한 CPU 70%, 메모리 67% 절감은 맞습니다. 그러나 Cloudflare는 그 원인으로 Rust 코드뿐 아니라 연결 재사용률 향상, NGINX/OpenResty와 다른 멀티스레드 아키텍처, Lua-C 경계의 복사 제거 등을 함께 제시합니다. 이는 “Rust가 같은 프로그램을 자동으로 70% 빠르게 만들었다”는 비교가 아닙니다.
6. Firecracker 수치는 언어 벤치마크가 아닙니다
Firecracker의 125ms 미만 시작 시간은 공식 수치입니다. 하지만 이는 특정 i3.metal 환경의 기본 microVM 크기에서, BIOS와 불필요한 장치를 제거한 최소 장치 모델로 달성한 결과입니다. AWS는 Rust를 안전성 때문에 선택했지만, 125ms라는 수치 자체를 Rust 언어의 성능 효과로 분리해 측정하지 않았습니다.
7. Windows CVE 설명은 사실과 다릅니다
CVE-2025-30388의 공식 설명은 Windows Win32K-GRFX의 힙 버퍼 오버플로이며, 공격 벡터는 로컬 공격자와 사용자 상호작용입니다. 공식 기록에는 이것이 러스트 코드라는 내용도 없습니다. 따라서 “Windows 커널의 Rust 코드에서 나온 최초의 원격 코드 실행 취약점”이라는 서술은 적어도 CVE 공식 자료와 맞지 않습니다.
반면 CVE-2025-68260은 실제 Rust Binder 코드의 unsafe 연산에서 발생한 경쟁 상태로, 포인터 손상과 커널 충돌을 일으킬 수 있었습니다. 다만 공식 설명은 단순한 “해제 후 사용”보다는 동시 접근으로 인한 데이터 레이스와 메모리 손상에 가깝습니다.
8. unsafe가 감사 범위를 자동으로 작은 블록에만 가두는 것은 아닙니다
unsafe가 명시적으로 표시되는 것은 분명 감사에 유리합니다. 그러나 잘못된 unsafe 구현이 안전한 API를 통해 외부로 잘못된 불변 조건을 노출하면 영향은 해당 블록 바깥으로 전파됩니다. 따라서 감사 대상은 unsafe 줄 수뿐 아니라 그 블록이 보장해야 하는 안전 계약, 호출자, FFI와 공유 상태까지 포함합니다. 책의 현재 unsafe 분석으로 이 부분은 대응 가능합니다.
9. “비용을 앞당겨 내면 상환이 끝난다”는 과장입니다
학습 비용은 감소할 수 있지만 컴파일 시간, 복잡한 타입과 생명주기 설계, 코드 리뷰, unsafe 계약 유지, FFI, async 디버깅과 생태계 변화 비용은 프로젝트 수명 동안 계속 발생할 수 있습니다. Cargo의 표준화도 장점이지만, 비표준 빌드·대규모 모노레포·코드 생성에서는 별도 복잡성이 남습니다.
Async Drop 역시 아직 완성된 언어 기능이 아닙니다. Rust 프로젝트의 공식 목표 문서는 이를 장기 목표 또는 실험으로 설명했으며, 한때 구현 작업이 미지원 상태였다고 기록합니다. 이를 “2027 에디션에 포함될 로드맵”으로 단정하는 것은 현재 확인 가능한 공식 자료보다 앞선 주장입니다.
10. 정부 권고는 러스트의 보편적 의무화를 의미하지 않습니다
CISA와 NSA가 메모리 안전 언어 전환을 권고하고 DARPA가 C-to-Rust 자동 변환 연구를 추진하는 것은 사실입니다. 그러나 CISA·NSA 지침은 Rust뿐 아니라 C#, Go, Java, Python, Swift 등 여러 메모리 안전 언어를 검토하고, 전환이 실용적이지 않은 경우 기존 언어의 완화책도 함께 사용하라고 합니다. 즉 정책적 방향은 메모리 안전성 강화이지 “모든 시스템은 Rust여야 한다”가 아닙니다.
댓글 0