Rust 근황, 리눅스 커널이 실험을 끝냈다

Rust를 둘러싼 가장 큰 소식은 문법이나 새 기능이 아니라 리눅스 커널에서 벌어졌다. 2025년 12월 도쿄에서 열린 커널 메인테이너 서밋에서 Rust는 더 이상 실험이 아니라고 결론이 났다. 이 글은 그 결정이 무엇을 뜻하는지, 그리고 2026년 하반기 현재 Rust 언어 자체가 어디까지 와 있는지를 정리한다.

"실험은 끝났다"는 문장이 나온 배경

Rust for Linux 프로젝트를 이끄는 미겔 오헤다(Miguel Ojeda)가 커널 메일링 리스트에 올린 말이 그대로 제목이 됐다. "the experiment is done, i.e. Rust is here to stay." 실험은 끝났고 Rust는 남는다는 뜻이다.

이 결정이 중요한 이유는 커널에 Rust 코드가 들어간 것 자체가 아니다. 코드는 2022년부터 들어가 있었다. 바뀐 것은 지위다. 그동안 Rust 코드는 "해봐도 되지만 언제든 걷어낼 수 있는 것"이었고, 그래서 새 드라이버를 Rust로 쓰겠다는 결정에는 늘 정치적 부담이 따랐다. 이제는 C와 나란히 놓인 영구 언어다.

오헤다는 동시에 선을 그었다. "이것이 모든 커널 설정, 아키텍처, 툴체인에서 전부 동작한다는 뜻은 아니다." 아직 할 일이 많다는 것이다. 이 단서가 붙은 이유는 실제로 아키텍처별 지원 편차가 있기 때문이다.

근거로 자주 인용되는 것은 그레그 크로아-하트만의 관찰이다. Rust로 쓴 드라이버가 C로 쓴 것보다 안전하다는 것이 실제로 확인되고 있다는 취지였다. 드라이버는 커널 취약점이 가장 많이 나오는 영역이고, 그 대부분이 메모리 관련 버그다. Rust가 겨냥한 지점과 정확히 맞는다.

이미 수백만 대에서 돌고 있다

논쟁이 길었던 만큼 "그래서 실제로 쓰이냐"는 질문이 따라붙는다. 답은 이미 쓰이고 있다는 것이다.

안드로이드 16이 6.12 커널 기반으로 나오면서 Rust로 작성된 메모리 할당 관련 코드가 함께 배포됐다. 기사 표현으로는 "수백만 대의 기기가 이미 Rust for Linux를 프로덕션에서 쓰고 있다". 실험실 이야기가 아니라 손에 들린 휴대전화 이야기다.

이 지점이 Rust 논쟁의 성격을 바꿨다. 이전까지는 "메모리 안전이 그렇게 중요한가"가 쟁점이었다면, 이제는 "이미 돌고 있는데 어디까지 넓힐 것인가"가 쟁점이다. 질문이 바뀌면 답도 바뀐다.

다만 과장은 경계해야 한다. 커널 전체에서 Rust가 차지하는 비중은 여전히 작고, 증가 속도도 폭발적이지는 않다는 관측이 있다. C로 쓰인 수천만 줄을 다시 쓰는 일은 일어나지 않는다. 새로 쓰는 드라이버와 격리된 서브시스템에서 선택지가 하나 늘어난 것으로 보는 편이 정확하다.

언어 자체는 컴파일러 내부를 갈아엎는 중이다

리눅스 쪽 소식에 가려졌지만, 2026년 Rust의 언어 개발은 눈에 띄는 문법 추가보다 컴파일러 내부 재작성에 몰려 있다. 공식 블로그의 최근 글 제목이 그대로 말해준다.

2026년 8월 4일 "Enabling the next iteration of the borrow checker on nightly", 8월 21일 "Enabling the next-generation trait solver on nightly". 빌림 검사기와 트레이트 해결기를 각각 차세대 구현으로 갈아 끼우는 작업이 나이틀리에서 켜졌다는 뜻이다.

이게 왜 중요한가. Rust를 쓰다 보면 "논리적으로 문제없는데 빌림 검사기가 거절하는" 코드를 만난다. 특히 조건 분기마다 다른 수명을 갖는 참조를 다룰 때 그렇다. 새 빌림 검사기는 이 한계를 줄이는 것을 목표로 오래 개발돼 왔다. 트레이트 해결기 쪽은 복잡한 제네릭에서 컴파일이 느려지거나 이상한 오류가 나던 문제를 겨냥한다.

사용자 입장에서는 새 기능이 아니라 "안 되던 게 되고, 느리던 게 빨라지는" 변화다. 화려하지 않지만 체감은 크다. 다만 나이틀리 단계이므로 안정 버전에 오기까지는 시간이 더 걸린다.

버전 자체는 6주 주기를 그대로 지키고 있다. 2026년 9월 3일 1.98.1이 나왔고, 그 직전 8월 20일에 1.98.0이 나왔다. 꾸준하다는 것 말고는 특별할 게 없는데, 사실 언어에 이보다 좋은 상태는 드물다.

흔히 도는 잘못된 정보 하나

Rust 소식을 검색하면 "2026 에디션"을 언급하는 글이 여럿 나온다. 2026년 9월 현재 공식 블로그에 그런 발표는 없다. 가장 최근 에디션은 2025년 2월에 나온 Rust 2024다.

에디션은 3년 주기가 관례였으므로 다음은 2027년이 유력하지만, 그것도 확정 발표가 있어야 사실이다. 기술 블로그를 읽을 때 버전과 일정은 항상 공식 출처로 확인하는 편이 좋다. 특히 요즘은 그럴듯하게 쓰였지만 출처가 없는 글이 검색 결과 상단에 꽤 올라온다.

커널에서 Rust가 실제로 들어간 자리

"커널에 Rust가 들어갔다"는 말은 범위를 짚어야 의미가 생긴다. 현재 Rust가 자리 잡은 곳은 대체로 이런 성격의 코드다.

드라이버가 가장 크다. 안드로이드의 Binder IPC, 애플 실리콘용 GPU 드라이버(Asahi), 여러 네트워크·파일시스템 서브시스템이 Rust 구현을 갖고 있다. 공통점은 외부 입력을 직접 받고, 경계가 비교적 명확하며, 새로 쓰는 코드라는 것이다.

반대로 스케줄러나 메모리 관리 같은 핵심부는 여전히 C다. 여기는 코드가 수십 년간 다듬어졌고, 수많은 아키텍처별 예외가 얽혀 있다. 다시 쓸 이유도 없고 다시 쓸 수도 없다.

오헤다가 "모든 설정과 아키텍처에서 동작하는 건 아니다"라고 단서를 단 지점이 위 흐름도의 마지막 분기다. x86_64와 arm64는 비교적 잘 되지만 그 밖의 아키텍처는 편차가 있다.

안전한 언어가 해결하지 못하는 것

메모리 안전성 이야기가 나오면 "Rust로 쓰면 버그가 없어진다"는 식으로 요약되곤 하는데, 정확하지 않다. Rust가 막는 것은 특정 부류의 버그다.

널 포인터 역참조, use-after-free, 버퍼 오버플로, 데이터 레이스. 이것들은 컴파일 단계에서 상당 부분 걸린다. 커널 CVE의 큰 비중이 여기 속하므로 효과가 크다.

반면 논리 오류, 교착 상태, 잘못된 권한 검사, 프로토콜 구현의 실수는 Rust도 못 막는다. 커널 드라이버에서 인증을 빠뜨렸다면 그건 언어와 무관하다. 그리고 커널 코드는 하드웨어를 직접 건드려야 하므로 unsafe 블록을 피할 수 없다. 그 안에서는 Rust의 보증이 프로그래머의 책임으로 넘어간다.

그래서 정확한 표현은 "버그가 없어진다"가 아니라 "버그의 종류가 바뀐다"에 가깝다. 그레그 크로아-하트만이 관찰한 "더 안전하다"도 이 맥락으로 읽는 것이 맞다.

그래서 지금 Rust를 배워야 하나

나는 조건부로 그렇다고 본다. 조건이 중요하다.

배울 만한 경우는 다루는 문제가 성능이나 안전성에 실제로 민감할 때다. 시스템 프로그래밍, 임베디드, 고성능 네트워크 서버, WebAssembly 타깃 같은 영역이다. 여기서는 Rust가 주는 것이 비용보다 크다. 커널이 영구 채택을 결정한 것도 이 영역에서의 가치가 증명됐기 때문이다.

서두를 필요가 없는 경우는 웹 백엔드나 데이터 처리처럼 이미 성숙한 대안이 있는 영역이다. Rust로 웹 API를 만들 수 있고 실제로 잘 만들어지지만, 개발 속도와 인력 확보를 생각하면 기존 스택이 합리적인 경우가 많다. "Rust가 뜨니까"만으로 팀의 주 언어를 바꾸는 것은 대개 손해다.

반론도 있다. 러닝 커브가 가파르다는 이유로 미루면 영영 안 배우게 된다는 것이다. 일리가 있다. 그래서 나는 주 언어를 바꾸는 것과 배워두는 것을 구분하길 권한다. 작은 CLI 도구 하나를 Rust로 만들어 보는 것은 며칠이면 되고, 소유권 개념을 손에 익히면 다른 언어에서도 메모리와 수명을 보는 눈이 달라진다. 그 정도는 지금 해둘 가치가 충분하다.

참고 자료

• Rust boosted by permanent adoption for Linux kernel code — DevClass — 도쿄 서밋 결정, 미겔 오헤다와 그레그 크로아-하트만의 발언, 안드로이드 프로덕션 사용
• Rust Blog — 1.98 릴리스 일정, 차세대 빌림 검사기와 트레이트 해결기 나이틀리 활성화 공지
• Rust enters the Linux kernel, but its adoption is leveling off — Techzine — 커널 내 Rust 비중과 증가 추세에 대한 신중한 관점