최근 프로그래밍 언어 커뮤니티에서 메모리 안전성(memory safety)을 두고 Rust(러스트)와 Fil-C(필-C) 개발자들 사이에 치열한 논쟁이 벌어지고 있습니다. Fil-C 개발자들은 Rust의 `unsafe` 키워드 존재를 이유로 Rust가 완전히 메모리 안전하지 않다고 비판하며, 자신들의 Fil-C가 더 안전한 대안이라고 주장합니다. 하지만 이러한 주장은 Fil-C가 가진 현실적인 제약과 비용을 간과하고 있다는 지적이 나옵니다.
Fil-C는 기존 C/C++ 코드를 메모리 안전하게 실행하기 위한 새로운 접근 방식을 제공합니다. 이는 범위 밖 접근이나 해제 후 사용과 같은 잘못된 메모리 접근이 발생하면 프로그램이 패닉(panic)을 일으키도록 설계되었습니다. 이를 위해 가비지 컬렉터(GC)와 포인터가 접근할 수 있는 메모리를 추적하는 InvisiCaps 기술을 결합합니다. 반면 Rust는 컴파일 시점에 메모리 안전성 문제를 일으킬 수 있는 프로그램을 적극적으로 차단하며, `unsafe` 블록은 원시 포인터 역참조 등 특정 보장을 우회하는 탈출구 역할을 합니다. C/C++ 계열 언어는 대부분의 메모리 안전성 보장을 프로그래머에게 맡기는 책임 모델을 가지고 있습니다.
그러나 Fil-C는 비용 없는 드롭인 대체재가 아닙니다. 기존 C/C++ 프로그램과 ABI(Application Binary Interface)가 호환되지 않고, 특정 상황에서는 수 배의 성능 저하가 발생할 수 있으며, 가비지 컬렉터(GC)를 도입해야 합니다. 이러한 제약은 성능이 중요하거나 기존 시스템과의 호환성이 필수적인 대규모 프로젝트에는 적용하기 어렵습니다. 실제로 안드로이드(Android) 운영체제에 적용된 500만 줄 이상의 Rust 코드에서는 출시 전 수정된 잠재적 메모리 안전성 취약점이 단 1건 발견되어, 100만 줄당 0.2건이라는 매우 낮은 밀도를 기록했습니다. 이는 과거 C/C++ 코드의 100만 줄당 약 1,000건에 비해 1,000배 이상 낮은 수치로, Rust가 실제 환경에서 메모리 안전성 문제 발생 위험을 크게 줄여준다는 강력한 증거입니다.
결론적으로, 모든 프로그램에 99.9%의 문제를 막는 기술과 90%의 프로그램에 100%의 문제를 막는 기술 중 하나만 선택할 필요는 없습니다. Fil-C의 제약을 수용할 수 있는 C/C++ 프로젝트는 Fil-C 바이너리를 제공할 수 있으며, Fil-C를 적용하기 어려운 소프트웨어에는 Rust와 같은 대안이 적합합니다. 메모리 안전성은 성능, ABI 호환성, GC 유무, 데이터 경쟁 방지 등 다양한 요소를 함께 고려해야 하는 복합적인 문제입니다. Rust의 `unsafe` 키워드 존재만으로 Rust를 배제하는 것은 Fil-C의 현실적인 비용과 Rust의 실제적인 보안 기여를 간과하는 일방적인 시각이며, 각 언어의 장단점과 적용 범위를 이해하고 균형 잡힌 접근이 필요합니다.