솔직히 말해서, 지난주 리눅스 커널 메인테이너 서밋(Maintainers Summit)에서 나온 소식은 꽤 충격적이었습니다. DRM(Direct Rendering Manager) 서브시스템 메인테이너인 Dave Airlie가 “이제 새로운 C 드라이버를 금지하고 Rust 사용을 의무화하기까지 약 1년 남았다” 라고 선언했기 때문입니다.

수십 년간 리눅스 커널의 절대 권력이었던 C 언어의 입지가 흔들리는 것을 넘어, 이제는 ‘레거시’ 취급을 받기 직전이라는 신호탄입니다. 오늘은 이 거대한 흐름의 중심에 있는 Arm Mali GPU용 Rust 드라이버, Tyr 프로젝트의 현재와 기술적 난관들을 엔지니어의 관점에서 뜯어보겠습니다.

Tyr: 단순한 드라이버가 아닌 ‘Rust 커널’의 리트머스 시험지

Tyr 프로젝트는 Arm, Collabora, Google이 합작하여 개발 중인 Rust 기반의 Mali GPU 커널 드라이버입니다. 2025년 초만 해도 “과연 될까?” 싶었던 이 프로젝트가, 연말에는 리눅스 플러머스 컨퍼런스(LPC)에서 3D 레이싱 게임인 SuperTuxKart를 구동하는 데 성공했습니다.

하지만 단순히 게임이 돌아간다는 사실보다 중요한 건, 이 프로젝트가 커널 내 Rust 추상화(Abstraction)의 한계를 밑바닥까지 검증하고 있다는 점 입니다. 커널 드라이버 개발자로서 Tyr의 현황을 보면, 현재 Rust-for-Linux가 마주한 기술적 부채와 해결 과제들이 적나라하게 보입니다.

기술적 병목: 아직 ‘준비’되지 않은 Rust 추상화들

Tyr가 메인라인 커널(6.18)에 일부 병합되었지만, 실사용이 불가능한 이유는 명확합니다. GPU 드라이버의 핵심 기능들을 구현하기 위한 Rust 인프라가 아직 공사 중이기 때문입니다.

• GEM Shmem & GPUVM: 통합 그래픽(SoC) 환경에서는 시스템 메모리를 공유해야 하므로 GEM shmem 객체가 필수적입니다. 또한, 최신 GPU는 CPU처럼 가상 메모리 격리가 필요한데, 이를 위한 GPUVM과 io-pgtable의 Rust 추상화가 아직 완성되지 않았습니다. Alice Ryhl과 Lyude Paul 같은 엔지니어들이 이 부분을 메우기 위해 고군분투하고 있죠.

• 순환 의존성(Circular Dependency) 문제: 개인적으로 가장 흥미로운 기술적 난제는 ‘초기화’ 문제입니다. 기존 C 드라이버에서는 구조체를 malloc하고 포인터를 돌려쓰며 대충 초기화하는 게 가능했습니다. 하지만 Rust의 타입 시스템은 이를 용납하지 않습니다.

  • drm::Device를 생성하려면 드라이버의 private data가 필요합니다.
  • 그런데 private data 안에서 펌웨어를 로드하거나 메모리를 할당하려면 drm::Device가 필요합니다.
  • 이 닭과 달걀의 문제 를 해결하기 위해 drm::DeviceCtx라는 새로운 상태(state) 개념을 도입하여 타입 시스템 레벨에서 해결하려는 시도가 진행 중입니다. 이건 C에서는 고민할 필요조차 없었던, 언어적 특성이 커널 설계를 강제하는 아주 좋은 예시입니다.

스케줄러의 진화: JobQueue로의 전환

기존 drm_gpu_scheduler는 펌웨어 기반 스케줄링이 대세가 된 현대 GPU 아키텍처와 맞지 않는 부분이 많았습니다. 특히 Rust의 소유권(Ownership) 모델과 결합될 때 수명(Lifetime) 관리 문제가 골치 아팠죠.

현재 논의되는 새로운 방향성은 JobQueue 입니다. 커널은 복잡한 스케줄링 로직을 덜어내고, 의존성(Dependency)이 해결된 작업을 큐에 넣는 역할만 수행하며, 실제 스케줄링은 펌웨어에 위임하는 방식입니다. Tyr는 이 새로운 설계 패턴을 검증하는 테스트베드 역할을 하고 있습니다. 만약 이 구조가 정착된다면, 향후 Nova(Nvidia GSP용 Rust 드라이버) 등 다른 드라이버들도 이 혜택을 보게 될 겁니다.

현실적인 평가: 아직은 ‘프로토타입’

냉정하게 평가하자면, Tyr는 아직 프로덕션 레벨과는 거리가 멉니다. 엔지니어링 관점에서 가장 치명적인 결함 두 가지가 있습니다.

1. 전력 관리(Power Management) 부재: 모바일 기기에서 전력 관리가 없는 드라이버는 배터리를 순식간에 녹여버리는 발열체일 뿐입니다. 현재 주파수 스케일링(Frequency Scaling)을 위한 Rust 추상화조차 없는 상태입니다.
2. GPU 리커버리 부재: GPU가 행(Hang)에 걸렸을 때 시스템 전체가 멈추지 않도록 복구하는 코드가 없습니다. 이는 사용자 경험 측면에서 배포 불가능(Showstopper) 수준의 문제입니다.

Hacker News의 반응과 나의 생각

Hacker News의 여론을 살펴보면, “C 절대주의자들의 텃밭이었던 커널이 이렇게 빨리 변할 줄 몰랐다”는 반응이 지배적입니다. 특히 Asahi Linux 팀이 보여준 성과가 Rust 드라이버의 가능성을 증명했다는 의견에 저도 동의합니다.

제 결론은 이렇습니다: Tyr는 단순한 ‘또 하나의 드라이버’가 아닙니다. 리눅스 커널이 C에서 Rust로 체질 개선을 하는 과정에서 겪는 성장통(Growing Pains) 그 자체입니다. 초기화 문제나 메모리 모델의 충돌은 Rust가 커널 개발의 느슨했던 관행들을 더 엄격하고 안전한 구조로 재편하고 있음을 보여줍니다.

1년 뒤, 정말로 새로운 C 드라이버가 금지될지는 두고 봐야겠지만, “메모리 안전성이 보장되지 않는 드라이버는 더 이상 받지 않겠다” 는 메인테이너들의 의지는 확고해 보입니다. 시니어 엔지니어라면 이제 Rust는 ‘배우면 좋은 언어’가 아니라, 시스템 프로그래밍의 ‘기본 소양’으로 받아들여야 할 때가 왔습니다.