Fil-C로 컴파일한 C를 Rust에서 안전하게: 마이그레이션 미룸의 대가로 런타임 검사를

Rust로 시스템 소프트웨어를 짜본 사람이라면 익숙한 순간이 있다. 컴파일러가 소유권과 수명을 검증해 메모리 안전을 증명해주다가도, 오래된 C 라이브러리를 불러 쓰는 순간 unsafe 경계를 넘게 된다. 그 너머의 C 코드가 계약을 지키리라 믿는 수밖에 없는데, 정작 그 계약은 Rust도 C도 강제하지 못한다. 도멘 코자르(Domen Kozar)는 이 구도가 거꾸로 뒤집혀 있다고 지적한다. 검증된 새 코드가 검증되지 않은 옛 코드에 의존하고, 낡은 C를 그대로 두는 쪽이 싸고 다시 짜는 쪽이 비싸다는 것이다.

Fil-C가 제안하는 다른 거래

Fil-C는 이 문제에 정면으로 다른 답을 내놓는다. C와 C++를 케이퍼빌리티(capability) 기반으로 재컴파일하고, 포인터 연산마다 런타임 검사를 넣으며, 동시성 가비지 컬렉터로 메모리를 관리한다. 그 결과 메모리 안전 위반은 공격 가능한 취약점이 되는 대신 그 자리에서 패닉으로 멈춘다. 중요한 점은 대부분의 기존 코드가 소스를 거의 혹은 전혀 고치지 않고도 이 방식으로 컴파일된다는 것이다. 대가는 컴파일 타임이 아니라 런타임에 치른다. 즉 안전을 실행 속도로 사는 셈이다.

코자르가 원하는 것은 이 Fil-C의 ABI와 대화할 수 있는 Rust FFI다. 그는 이것을 extern "fil-c"라고 부른다. 첫 버전은 의도적으로 좁혀도 좋다고 본다. 스칼라 값, 복사된 문자열과 슬라이스, 그리고 불투명한 핸들 정도만 주고받고, 안전한 Rust 래퍼를 생성하며, C 의존성 그래프 전체를 Fil-C로 컴파일한다. 대신 평범한 unsafe C로 되돌아가는 탈출구는 두지 않는다. 공유 메모리 같은 까다로운 기능은 Rust가 Fil-C에 넘긴 케이퍼빌리티를 확실히 회수할 수 있게 된 뒤로 미룬다.

ABI라는 벽

이것이 기존 bindgen에 옵션 하나를 더하는 수준의 일이 아니라는 점이 핵심이다. Fil-C는 소스 수준에서는 C와 호환되지만 의도적으로 ABI 호환은 아니다. 평범한 Rust의 extern "C"가 말하는 ABI를 Fil-C 진영에서는 '욜로-C(Yolo-C)'라 부르는데, 바로 그 검사 없는 세계다. 다리를 놓는다는 것은 Rust든 Fil-C든, 아니면 생성된 스텁 한 쌍이든, Fil-C의 보장을 잃지 않으면서 값을 교환하는 법을 배우게 만든다는 뜻이다. 쉬웠다면 이미 존재했을 것이라는 저자의 말은 엄살이 아니라 문제의 난도를 가리킨다.

다행히 이 스택의 한 축은 이미 모양을 갖춰가고 있다. filnix는 Fil-C를 Nix의 크로스 컴파일 플랫폼으로 패키징했고, 이미 100개가 넘는 nixpkgs 패키지를 이식했다. Fil-C를 하나의 '플랫폼'으로 취급한다는 것은 Nix가 전이적 의존성 폐포(closure) 전체를 Fil-C ABI로 다시 빌드한다는 의미다. 평범한 C를 실수로 그 안에 링크해 넣는 사고를 구조적으로 막는 것이다. filnix 자체가 Rust 다리는 아니지만, 재현 가능한 툴체인과 패키지 세계, 그리고 실험할 테스트베드를 제공한다.

Zig도 비슷한 지점으로

비슷한 문제를 다른 방향에서 접근하는 곳도 있다. 앤드루 켈리(Andrew Kelley)는 Fil-C에서 영감을 받은 선택적 fil ABI를 Zig에 제안했다. 이는 Zig 컴파일러와 표준 라이브러리 안의 독립 구현으로, Zig 프로그램과 그 C·C++ 의존성 트리 전체를 런타임 메모리 안전과 함께 컴파일하는 것을 목표로 한다. Rust 다리가 진입해야 할 세계와 놀랄 만큼 가까운 그림이다. Fil-C는 케이퍼빌리티 모델과 작동하는 런타임을, Rust는 컴파일 타임 안전을, Zig는 Fil-C에서 착안한 ABI 실험을, Nix와 filnix는 의존성 그래프 전체를 재빌드하고 시험할 기반을 각각 갖고 있다. 저자는 이 네 진영이 거의 호환되지만 서로 떨어진 섬으로 남기보다 한자리에 모이기를 바란다.

실무자 관점에서 이 구상이 매력적인 이유는 인센티브를 올바로 정렬하기 때문이다. 지금까지 메모리 안전을 위한 재작성은 순수한 비용이었고, 그 보상은 눈에 잘 띄지 않았다. Fil-C 다리가 놓이면 그림이 바뀐다. 낡은 라이브러리를 그대로 두어도 메모리 안전은 확보되지만, 모든 포인터 연산이 검사를 거치고 그 메모리가 가비지 컬렉션에 참여하는 성능 세금을 문다. 반대로 뜨거운 경로(hot path)를 Rust로 다시 짜면 그 검사는 정적 검증으로 바뀌어 세금이 사라진다. C는 '영구적인 빠른 길'이 아니라 '안전한 호환의 길'로 역할이 바뀌고, 마이그레이션을 끝낼 성능상의 이유가 비로소 생긴다.

다만 한계는 분명히 짚어둘 필요가 있다. 여기서 말하는 '100% 안전'은 지원되는 경계 전체에서 메모리 안전하다는 뜻이지, 논리 버그나 교착 상태, 잘못 설계된 API로부터 자유롭다는 뜻이 아니다. 그리고 그 경계야말로 가장 어려운 부분이다. Fil-C는 현재 프로그램과 의존성 전체가 자신의 ABI를 쓸 것을 요구하며, 평범한 C와의 상호운용을 명시적으로 비목표(non-goal)로 둔다. Rust 다리가 성립하려면 이 '온전한 세계' 보장을 지켜야지, 검사 없는 욜로 모양의 구멍을 슬쩍 뚫어서는 안 된다. 그 순간 전체 보장이 무너지기 때문이다. 즉 아직은 제안이자 초대다. 저자는 내년 란사로테에서 열리는 OceanSprint에 함께 만들자고 부르고 있고, filnix를 만드는 미카엘 브로크만(Mikael Brockman)이 이미 참여를 수락했다고 전한다.