러스트(Rust)와 C/C++의 메모리 안전성 취약점(CVE) 수를 단순 비교하는 것은 두 언어의 실제 보안 수준을 오해하게 만들 수 있습니다. 이는 각 언어 생태계가 메모리 안전성 취약점을 '라이브러리 문제'로 간주하고 CVE로 등록하는 기준에 큰 차이가 있기 때문입니다.
C/C++에서는 잘못된 API 호출로 인해 정의되지 않은 동작(Undefined Behavior, UB)이나 세그멘테이션 폴트(Segmentation Fault)가 발생하더라도, 대부분 사용자 코드의 오용으로 처리되며 모든 잠재적 가능성을 CVE로 등록하지 않습니다. 예를 들어, 널(NULL) 포인터를 인자로 받는 C 라이브러리 함수 `curl_getenv(NULL)` 호출은 경고 없이 컴파일되지만 실행 시 세그폴트가 발생할 수 있습니다. 하지만 이는 일반적으로 `curl` 라이브러리의 취약점으로 보고되지 않고, API의 잘못된 사용으로 간주됩니다. 반면 러스트에서는 `unsafe` 키워드를 사용하지 않은 안전한 API 호출만으로 메모리 버그가 발생하면, 이를 라이브러리의 '사운드니스 버그(soundness bug)'로 간주하고 CVE로 등록할 수 있습니다. 이는 러스트가 `safe`와 `unsafe`라는 명확한 구분을 통해 메모리 안전성 책임을 명시하기 때문입니다.
이러한 기준의 차이는 러스트의 일부 CVE가 C/C++보다 훨씬 엄격한 기준으로 기록됨을 의미합니다. 따라서 단순히 원시 CVE 수만을 비교하여 러스트가 '실제로는 메모리 안전하지 않다'거나 '도입할 가치가 없다'고 주장하는 것은 잘못된 결론으로 이어질 수 있습니다. 러스트는 `unsafe` 블록 없이 안전한 API를 사용했을 때 메모리 버그가 발생하지 않아야 한다는 강력한 보장을 제공하며, 라이브러리가 내부적으로 `unsafe` 코드를 사용하다 버그를 내더라도 그 수정 책임은 라이브러리에 있습니다. 이는 러스트가 실무적으로 확장 가능한 메모리 안전성을 제공하는 핵심 요소입니다. 결과적으로, 두 언어의 메모리 안전성을 정확하게 평가하려면 CVE 집계 방식의 근본적인 차이를 이해하는 것이 필수적입니다.