러스트가 C/C++을 대체할 수 없는 가장 근본적인 이유는, 역설적이게도 러스트가 제대로 작동하기 위해 C/C++ 생태계에 구조적으로 의존할 수밖에 없다는 현실에 있습니다. 현대 컴퓨팅 세계에서 C언어의 ABI(Application Binary Interface)는 운영체제, 하드웨어 드라이버, 그리고 수십 년간 쌓인 핵심 라이브러리들이 서로 소통하는 '공용어(lingua franca)'와 같습니다. 러스트는 이 거대한 C의 제국 위에서 태어났으며, 그 영향력에서 결코 자유로울 수 없습니다.

이 구조적 종속성은 세 가지 층위에서 명확하게 드러납니다.

첫째, 가장 낮은 수준인 운영체제와의 소통입니다. 러스트 프로그램이 파일을 읽고, 네트워크에 접속하며, 메모리를 할당받는 등 의미 있는 작업을 수행하려면 결국 운영체제가 제공하는 시스템 콜(System Call)을 사용해야 합니다. 그리고 이 모든 시스템 콜 API는 예외 없이 C ABI를 통해 세상에 노출되어 있습니다. 러스트의 표준 라이브러리(libstd) 역시, 그 화려하고 안전한 추상화의 이면에는 이러한 저수준 C 인터페이스를 안전하게 포장하는 코드가 자리 잡고 있습니다. 즉, 러스트는 가장 근본적인 생존 활동부터 C의 도움 없이는 아무것도 할 수 없습니다.

둘째, 라이브러리 생태계의 현실입니다. crates.io의 풍부한 생태계를 지탱하는 핵심적인 크레이트들 상당수는 *-sys라는 접미사를 달고 있습니다. 이것은 OpenSSL, zlib, libgit2와 같이 이미 세상에 존재하는, 성능과 안정성이 검증된 C 라이브러리를 러스트에서 호출할 수 있도록 저수준으로 포장한 것에 불과합니다. 이 경계면을 만드는 작업은 unsafe 블록을 필수적으로 동반하며, 이 지점에서 러스트가 자랑하는 컴파일러의 자동 안전성 보장은 무력화되고 모든 책임은 다시 개발자 개인에게 전가됩니다. 실용성을 위해, 러스트는 스스로 비판했던 C/C++의 세계로 다시 돌아가 손을 내밀어야 하는 모순적인 상황에 놓이는 것입니다.

셋째, 리눅스 커널 통합 사례는 이 종속성의 현실을 가장 극명하게 보여줍니다. 'Rust for Linux' 프로젝트는 러스트의 가능성을 보여주는 위대한 시도이지만, 그 내부를 들여다보면 러스트 코드는 커널의 주인이 아니라, C로 만들어진 거대한 구조에 맞추어 자신을 변화시켜야 하는 '손님'에 가깝습니다. 러스트 코드는 C의 자료구조 레이아웃을 흉내 내기 위해 #[repr(C)]를 사용해야 하고, 커널의 다른 함수를 호출하기 위해 수많은 unsafe 코드를 작성해야 합니다. 러스트의 소유권 모델이 C의 포인터 중심 세계관에 맞추어지는, 주객이 전도된 모습입니다.

결론적으로, C ABI에 대한 이러한 다층적이고 구조적인 종속성은 러스트가 C/C++의 '대체재'가 될 수 없음을 증명하는 가장 결정적인 근거입니다. 러스트는 C라는 거인의 어깨 위에 올라탄 강력한 파트너이자, C의 언어로 소통하는 현대적인 **'클라이언트(Client)'**일 뿐, 그 거인을 밀어내고 새로운 질서를 만들 독립적인 존재가 아닙니다.