2025년 최신 Android 데이터에 따르면 메모리 안전성 취약점은 처음으로 전체 취약점의 20% 미만으로 감소했다. 이는 플랫폼의 새롭고 활발한 부분에서 Rust 사용이 확대되는 시기와 맞물린 결과다. 2025년 11월 12일 Google Security Blog에 게시된 분석에 따르면 C와 C++에서 Rust로 전환한 효과는 보안 위험 감소에 그치지 않고 코드 검토를 가속화하며 변경 사항의 안정성도 개선한다.
데이터는 Google이 직접 개발한 코드와 외부 기관이 관리하는 오픈 소스 코드를 모두 포함한 Android 코드 변경 사항을 기반으로 하며, C, C++, Java, Kotlin, Rust를 포함한다. 분석이 2025년 말보다 몇 달 앞서 발표된 만큼 Google은 표준 90일 수정 기간으로 인해 결과가 최종 수치와 매우 가까우며, 필요할 경우 수정 작업을 앞당길 수 있다고 설명했다.
더 높은 보안성과 더 빠른 제공
Google은 저수준 프로그래밍에서 C와 C++의 직접적인 대안으로 Rust를 Android에 도입했다. Rust는 비슷한 수준의 제어력과 예측 가능성을 유지하면서도 메모리 안전성과 관련된 위험을 크게 줄인다. 분석에 따르면 새로운 Rust 코드의 규모가 급격히 증가하는 동시에 새로운 C++ 코드의 증가는 더 느리게 지속됐다. 그 결과 새로 추가되는 Rust의 규모가 C++와 비슷해졌으며, 두 개발 경로를 더욱 신뢰성 있게 비교할 수 있게 됐다.
Google은 생산성과 안정성의 두 측면을 측정하기 위해 DORA 프레임워크를 사용했다. 언어 간 비교의 어려움을 줄이기 위해 Android 플랫폼에서 근무하는 유사한 개발자 집단이 작성한, 규모가 비슷한 변경 사항에 초점을 맞췄다. 또한 Rust 도입이 증가함에 따라 시간에 따른 추세를 추적했다.
비슷한 규모의 Rust 변경 사항은 C++ 변경 사항보다 약 20% 적은 검토가 필요하다. 또한 현재 코드 검토에 소요되는 시간이 약 25% 더 짧다. Google은 2023년과 2024년 사이에 나타난 뚜렷한 개선이 Android 팀의 Rust 경험 증가에 따른 것일 수 있다고 추측하지만, 단정하지는 않는다.
안정성 측면에서는 중간 규모 및 대규모 Rust 변경 사항의 회귀율이 C++ 변경 사항보다 약 네 배 낮다. Google은 회귀 작업의 감소가 변경 사항의 품질을 반영할 뿐 아니라 생산성도 높인다고 강조한다. 회귀는 재작업, 추가 검토, 재빌드, 사고 후 보고서 작성, 다른 팀의 작업 중단으로 이어질 수 있기 때문이다.
시스템 서비스와 라이브러리 밖으로 확대되는 Rust
Google은 Android 시스템 서비스와 라이브러리를 구축하기 위한 Rust 지원이 성숙했다고 말하며, 이에 따라 생태계의 다른 계층으로도 사용을 확대하고 있다.
- 커널: Android용 Linux 6.12 커널은 Google이 Rust 지원을 활성화한 최초의 커널이며, 최초의 프로덕션 Rust 드라이버도 포함한다. Google은 Arm 및 Collabora와 함께 커널 모드에서 작동하는 GPU 드라이버를 계속 개발하고 있다.
- 펌웨어: Google은 높은 권한, 성능 제약, 일부 보호 조치의 제한 때문에 펌웨어가 위험성이 높고 보안 확보가 어렵다고 본다. Google은 수년 전부터 펌웨어에 Rust를 사용해 왔으며, 커뮤니티를 위해 교육 과정과 코드를 공개했다. 특히 Rusted Firmware-A를 중심으로 Arm과 협력하고 있다.
- Google 애플리케이션: Bluetooth를 통해 주변 기기를 안전하고 비공개적으로 검색하는 데 사용되는 Nearby Presence 프로토콜은 Google Play Services 내부에서 Rust로 동작한다. RCS를 통한 보안 메시징용 MLS 프로토콜도 향후 버전의 Google Messages에 포함될 예정이다.
- Chromium: PNG 및 JSON 파서와 웹 글꼴이 Rust로 작성된 메모리 안전 구현으로 대체됐다. 이에 따라 Chromium 엔지니어들은 Rule of 2를 따르면서 웹에서 유입되는 데이터를 더 쉽게 처리할 수 있다.
사용자에게 도달할 뻔한 취약점
Google은 Rust의 장점에 초점을 맞추면서도 Android에서 Rust 기반 최초의 메모리 안전성 취약점으로 기록될 뻔한 사례를 소개한다. CrabbyAVIF에서 선형 버퍼 오버플로가 공개 릴리스에 도달하기 전에 발견됐으며, 수정 사항에는 높은 우선순위를 부여하고 릴리스 채널을 통한 도달 과정을 추적할 수 있도록 CVE-2025-48530 식별자가 부여됐다.
분석에 따르면 Scudo Hardened Allocator 메모리 할당자는 보조 할당 영역을 둘러싼 보호 페이지 덕분에 취약점의 악용을 확정적으로 불가능하게 만들었다. 또한 Scudo는 오버플로를 조용한 메모리 손상에서 명확한 충돌로 바꿔 문제 발견을 도왔다. 반면 이 사건은 충돌 보고 시스템의 한계를 드러냈다. 충돌이 오버플로로 인해 발생했다는 점을 명확히 보여주지 못해 분류와 대응이 늦어졌기 때문이다. Google은 이 한계를 해결했으며, 이제 시스템은 Scudo 보호 페이지로의 오버플로가 발생할 때 명확한 신호를 제공한다고 밝혔다.
unsafe가 존재하는데도 Rust가 중요한 이유는 무엇인가?
Google은 C, C++, Rust 중 어떤 언어에서든 안전하지 않은 코드를 금지하는 것이 운영 체제 개발에 실용적인 해결책이라고 보지 않는다. API 바인딩과 하드웨어를 다뤄야 하기 때문이다. 따라서 Comprehensive Rust 교육 과정에서 안전하지 않은 코드를 다루는 고급 모듈을 개발하고 있다. 이 모듈은 개발자에게 이러한 코드와 정의되지 않은 동작의 안전성을 평가하는 방법, 안전성 주석을 사용하는 방법, 그리고 안전하지 않은 부분을 안전한 추상화 내부에 캡슐화하는 방법을 가르친다.
Android 플랫폼의 약 500만 줄에 이르는 Rust 코드와 출시 전에 처리된 잠재적 사례 한 건을 바탕으로 Google은 Rust의 메모리 안전성 취약점 밀도를 코드 100만 줄당 약 0.2건으로 추정한다. 이를 C와 C++에서의 코드 100만 줄당 약 1,000건이라는 역사적 밀도와 비교하면, 자체 추정치 기준으로 1,000배를 초과하는 감소를 의미한다. 또한 코드의 약 4%가 unsafe{} 블록 안에 작성됐다고 지적한다. 그러나 대부분의 Rust 검사가 계속 적용되고, 안전하지 않은 코드를 캡슐화할 수 있으며, 추가적인 검토를 받는다는 점을 고려하면 모든 안전하지 않은 코드 한 줄이 C 또는 C++의 동일한 위험에 노출된다고 가정하는 것은 위험을 과대평가하는 것이라고 설명한다.
Google은 Rust 도입이 보안 개선을 성능, 절차 또는 기능 출시 속도의 추가 비용과 연결해 온 전통적인 방정식을 바꾼다고 결론 내린다. C와 C++, 소프트웨어 및 하드웨어 보호 메커니즘이 다층 방어 체계에서 여전히 중요하지만, 회사는 Rust로의 전환이 더 안전하면서도 동시에 더 효율적인 경로를 제공한다고 본다. 먼저 서두른 뒤 나중에 결과를 처리하는 방식이 아니라는 것이다.