러스트가 진정한 C/C++의 대체재임을 증명하기 위해서는, C/C++이 수십 년간 군림해 온 시스템 프로그래밍의 최전선, 즉 임베디드 시스템과 운영체제 커널 영역을 정복해야만 합니다. 러스트 커뮤니티는 ‘Rust for Linux’ 프로젝트 등을 내세우며, 러스트의 안전성이 이 분야에 새로운 시대를 열 것이라고 홍보합니다. 하지만 임베디드 시스템 개발은 단일한 분야가 아니며, 카림 야그모어(Karim Yaghmour)와 같은 전문가들이 지적하듯, OS 없이 하드웨어를 직접 제어하는 ‘딥리 임베디드’와 리눅스 커널 위에서 동작하는 ‘임베디드 리눅스’는 근본적으로 다른 접근 방식을 요구합니다.3 이 절에서는 운영체제 없이 동작하는 베어메탈(Bare-metal) 환경과 리눅스 커널이라는 두 가지 다른 맥락에서 러스트가 마주하는 실제적인 제약을 각각 분석합니다.

첫째, 운영체제조차 없는 진정한 Bare-metal 임베디드 시스템의 세계에서 러스트는 ‘거대한 바이너리 크기’라는 첫 번째 장벽에 부딪힙니다. 수 킬로바이트(KB)의 플래시 메모리와 램(RAM)으로 동작해야 하는 수많은 마이크로컨트롤러 환경을 고려해볼 때, 일반적인 애플리케이션처럼 libstd를 포함시키는 것은 그 자체로 불가능에 가깝습니다. 만약 그렇게 한다면 바이너리는 수 메가바이트(MB)에 달해, 수 킬로바이트(KB)의 플래시 메모리에는 도저히 들어갈 수 없기 때문입니다.

이에 대한 러스트 생태계의 대답은 no_std 환경입니다. 이는 표준 라이브러리를 아예 사용하지 않는 방식으로, 바이너리 크기를 획기적으로 줄여줍니다. 하지만 이것은 ‘모든 문제의 해결책’이 아니라, ‘하나의 문제를 해결하기 위해 다른 모든 것을 포기하는’ 것에 가깝습니다. no_std 환경을 선택하는 순간, 개발자는 Vec, String과 같은 기본적인 자료구조, 동적 메모리 할당, 운영체제 추상화 등 러스트가 제공하는 대부분의 편리하고 현대적인 기능을 포기해야 합니다. 결국, 개발자는 C언어처럼 모든 것을 맨바닥부터 직접 구현하거나, 아직은 파편화되어 있는 no_std용 크레이트 생태계에 의존해야 하는, 또 다른 종류의 ‘고통’과 마주하게 됩니다. 물론, 이러한 단점에도 불구하고 no_std 러스트를 선택하는 개발자들도 존재한다. 그들은 C언어에서 흔히 발생하는 치명적인 버그들을 컴파일 시점에 원천적으로 방지해주는 러스트의 강력한 안전장치가, 약간의 바이너리 크기 증가나 기능적 제약이라는 비용을 지불할 만한 충분한 가치가 있다고 판단하는 것이다. 이는 ‘최소한의 크기’와 ‘최소한의 버그’라는 두 가치 사이에서, 후자를 선택하는 합리적인 공학적 결정이다.

둘째, 리눅스 커널과 같은 거대한 C언어 기반 프로젝트에 적용될 때, 러스트는 ‘C ABI에 대한 종속성’이라는 또 다른 장벽과 마주합니다. ‘Rust for Linux’ 프로젝트가 이룬 성과는 분명 인상적이지만, 그 현실을 들여다보면 러스트 코드는 커널의 ‘주인’이 아닌 ‘손님’에 가깝습니다.

러스트로 작성된 드라이버 모듈은, 커널의 다른 부분과 소통하기 위해 C언어의 데이터 구조 레이아웃(#[repr(C)])을 따라야 하고, 수많은 unsafe 블록을 통해 C 함수를 호출하며, 커널이 기대하는 복잡한 포인터 기반의 인터페이스에 자신을 맞춰야 합니다. 이는 러스트의 소유권 모델이 제공하는 순수한 안전성을 상당 부분 포기해야 함을 의미합니다.

현재 리눅스 커널 내 러스트의 현실은 여전히 미미한 수준입니다. 2025년 6월 30일 기준으로 kernel.org에서 배포된 리눅스 커널 6.15.4 버전을 cloc으로 분석한 결과, 순수 코드 라인(주석, 공백 제외) 약 2,878만 줄 중 러스트 코드는 약 1만 4천 줄(14,154 라인)로, 전체의 약 0.05%에 불과합니다.

아래의 요약 표는 해당 시점 커널 내 주요 시스템 언어들의 비중을 보여줍니다.

(표는 주요 언어만 발췌하여 표시했습니다. 총 코드 라인 수 28,789,463 라인 기준)

현재 포함된 러스트 코드는 대부분 드라이버 작성을 위한 기본적인 인프라 수준이며, 실제 핵심적인 기능을 담당하는 부분은 전무합니다. 리눅스 커널 내에서 러스트가 의미 있는 존재감을 갖기까지는 상당한 시간이 걸릴 것으로 보입니다.

결론적으로, 임베디드와 커널이라는 두 영역에서, 러스트의 채택은 ‘모든 것을 해결하는 만능 열쇠’가 아니라, 수많은 기술적, 구조적 한계와 타협하며 특정 ‘틈새’를 어렵게 파고드는 과정에 가깝습니다. 이는 러스트의 ‘범용 시스템 프로그래밍 언어’라는 주장에 깊은 의문을 던지게 만듭니다.