메모리 안전성은 시스템 프로그래밍에서 가장 오래된 골칫거리다. C와 C++은 out-of-bounds 접근, use-after-free 같은 위반을 언어 차원에서 막지 않고 대부분 프로그래머의 책임으로 남긴다. C++의 RAII와 스마트 포인터, Zig의 defer처럼 도움을 주는 장치는 있지만, 근본적으로 잘못된 메모리 접근을 강제로 차단하지는 못한다. 반면 Rust는 컴파일 단계에서 메모리 안전을 깨뜨릴 수 있는 프로그램을 아예 통과시키지 않으려 한다. 대가로 안전한 프로그램조차 거부될 때가 있고, 이를 우회하기 위한 unsafe라는 탈출구가 존재해 원시 포인터 역참조 등을 허용한다.
최근 이 구도에 새로운 변수가 등장했다. Fil-C는 C와 C++ 코드를 컴파일하면 잘못된 메모리 접근이 발생하는 순간 패닉을 일으키도록 만든다. 이를 위해 가비지 컬렉션(GC)과, 포인터가 접근 가능한 메모리 영역을 추적하는 InvisiCaps라는 기법을 결합한다. Zig의 저자 Andrew Kelley 역시 Fil-C에서 영감을 받은 새 컴파일 모드를 예고했다. 원문 필자는 Fil-C가 성공해 인기 있는 C/C++ 프로젝트가 Fil-C로 컴파일된 릴리스를 제공하게 되기를 진심으로 바란다고 밝힌다. 메모리 안전을 확보하는 선택지가 늘어나는 것은 그 자체로 반가운 일이기 때문이다.
논쟁의 실제 축: 안전이 아니라 진영
문제는 이 새로운 선택지가 종종 Rust를 깎아내리는 무기로 쓰인다는 점이다. Fil-C 저자는 unsafe를 통해 Rust의 보장을 일부 우회할 수 있다는 이유로 Rust를 '메모리 비안전 언어'라 부른다. Kelley가 붙인 컴파일 모드 이슈 제목도 "(Rust와 달리) 실제로 메모리 안전한 컴파일 모드를 도입한다"는 표현을 담고 있다. 여기서 흔히 등장하는 주장은 이렇다. "Rust 진영이 정말 메모리 안전을 중시한다면 더 안전한 Fil-C를 홍보하고 Rust를 버려야 한다. 그러지 않는다면 그들은 안전이 아니라 자기네 새 언어에 애착이 있을 뿐이다." 원문 필자는 이런 논리를, Rust 개발자들이 흔히 비난받는 바로 그 광신적·컬트적 태도라고 지적한다.
이 주장이 놓치는 것은 Fil-C가 무비용의 드롭인 대체재가 아니라는 사실이다. Fil-C는 non-Fil-C로 컴파일된 프로그램과 ABI 호환이 되지 않고, 경우에 따라 몇 배 느려질 수 있으며, GC를 도입한다. 많은 일상 유틸리티에서는 이 대가가 문제되지 않는다. 몇 배 느려도 체감하지 못하는 프로그램이 많고, 동적 링크를 하지 않아 ABI 호환성이 무의미한 경우도 많다. 그러나 모든 소프트웨어가 단순 유틸리티는 아니다. GC와 ABI 비호환이 치명적인 인기 프로젝트가 다수 존재하며, 이들은 현재 형태의 Fil-C 계열 기술을 결코 채택하지 않을 것이다. 그리고 흥미롭게도 Fil-C를 쓸 수 없는 바로 그 종류의 프로그램이 Rust에 잘 맞는 경우가 많다.
unsafe가 있으니 Rust는 위험한가
unsafe의 존재만으로 Rust를 비안전이라 규정하는 것은 절대주의적 관점이다. 실무 데이터는 다른 이야기를 한다. 원문이 인용한 Android 플랫폼 사례에서, 약 500만 줄의 Rust 코드에서 잠재적 메모리 안전 취약점은 단 하나 발견됐고 그마저 출시 전에 수정됐다. 이는 100만 줄당 0.2건의 취약점 밀도다. 같은 조직의 C/C++ 역사적 데이터는 100만 줄당 약 1,000건에 가까웠으니, 1,000배 이상의 감소인 셈이다. 프로젝트마다 수치는 다르겠지만, Rust가 실무에서 메모리 안전 문제 발생 위험을 크게 낮춘다는 점은 이제 충분히 입증됐다고 볼 만하다.
필자가 던지는 비유는 명료하다. 100%의 프로그램에서 문제의 99.9%를 막는 기술과, 90%의 프로그램에서 문제의 100%를 막는 기술 중 하나를 골라야 한다면 무엇을 택하겠는가. 정확한 숫자는 알 수 없지만 요점은 분명하다. 게다가 우리는 굳이 둘 중 하나만 고를 필요가 없다. 대가를 감수할 수 있는 C/C++/Zig 프로젝트는 Fil-C 바이너리로 제공되고, 그럴 수 없는 소프트웨어는 위험을 대부분 혹은 완전히 제거하는 언어로 작성되면 된다. 두 접근은 경쟁이 아니라 보완 관계다.
크래시도 공짜가 아니다
또 하나 간과되는 지점이 있다. Fil-C에서 100만 줄당 1,000건의 메모리 취약점은 '크래시'로 바뀐다. 보안 취약점보다는 낫지만, 그것은 여전히 수정해야 할 방대한 양의 크래시다. 게다가 과거에는 공격자가 프로그램을 크래시시킬 수 있다는 사실 자체가 보안 취약점으로 이어진 사례도 있었다. 드문 문제를 두려워하는 영역이라면 이 점도 함께 저울에 올려야 공정하다. GC 언어로 쓸 수 있는 프로그램은 애초에 unsafe가 필요 없는 경우가 많고, unsafe가 필요한 프로그램은 GC를 쓸 수 없는 경우가 많다는 점도 실무적 현실이다.
결국 이 글이 겨냥하는 것은 특정 언어가 아니라 태도다. Rust의 데이터 레이스 방지 같은 다른 보장과 언어 기능을 고려하면, 극히 낮은 심각 메모리 오류 위험은 충분히 감수할 만한 트레이드오프라고 판단하는 개발자가 많다. 필자는 마지막으로 일관성을 요구한다. Rust의 100만 줄당 0.2건조차 용납할 수 없을 만큼 메모리 안전을 중시하는 사람이라면, 아무 보호 장치 없이 C/C++이나 non-fil Zig를 컴파일하는 이들을 Rust 개발자보다 더 강하게 비판해야 마땅하다는 것이다. 진정으로 안전을 위한다면 더 위험한 대안을 방치할 이유가 없기 때문이다. 한국의 실무자에게 이 논쟁이 주는 교훈은 명확하다. 도구 선택은 진영 논리가 아니라 프로젝트의 성능·호환성·런타임 제약이라는 구체적 트레이드오프 위에서 이뤄져야 한다.