리눅스 커널에서 Rust를 실험적으로 도입한 이후 2025 Maintainers Summit에서 그 성과와 남은 과제를 평가한 내용.
URL: https://lwn.net/Articles/1050174/
제목: 커널 Rust 실험의 현황
By Jonathan Corbet
2025년 12월 13일
Rust로 커널 코드를 작성할 수 있는 기능은 명시적으로 “실험(experiment)”으로 추가되었다. 일이 잘 풀리지 않으면 Rust는 다시 제거될 것이었다. 2025 Maintainers Summit에서는 이 실험의 현황을 평가하고, 이제 결과를 성공으로 선언할 때가 되었는지 결정하기 위한 세션이 열렸다. (어쩌면 놀랍지 않게도) 결론은 이 실험이 실제로 성공이라는 것이었지만, 그 과정에서 흥미로운 논점들이 몇 가지 제기되었다.
세션을 이끈 Miguel Ojeda는 몇 가지 헤드라인으로 시작했다. NVIDIA GPU를 위한 Nova 드라이버가 오고 있으며, 일부는 이미 메인라인에 병합되었다. 또한 Android binder 드라이버가 6.18에 병합되었다. 더 큰 뉴스는 Android 16 시스템이 6.12 커널을 사용해 출하되면서, Rust로 작성된 ashmem 모듈을 포함한다는 점이라고 그는 말했다. 즉, 이제 수백만 대의 실제 기기에서 Rust 코드가 포함된 커널이 돌아가고 있다.
한편 Debian 프로젝트도 마침내 커널 빌드에서 Rust를 활성화했다. 이는 다가오는 “forky” 릴리스에서 나타날 것이다. 커널 내 Rust 코드의 양은 “폭발적으로” 증가하고 있으며, 지난 1년 사이 5배로 늘었다. 커널 개발자와 Rust 언어 개발자 간 협력도 늘어나, 커널 프로젝트가 언어 자체의 발전에도 상당한 영향력을 행사하게 되었다. Rust 커뮤니티는 커널 프로젝트를 돕는 데 전념하고 있다고 그는 말했다.
GCC 코드 생성기를 rustc 컴파일러에 접목하는 rust_codegen_gcc 노력도 진전 중이다. 한편 완전한 GCC 기반의 gccrs 프로젝트도 순조롭게 진행되고 있다. gccrs는 이제 커널의 Rust 코드를 컴파일할 수 있다(다만 올바르게 실행 가능한 코드로 컴파일하는 부분은 여전히 작업 중인 것으로 보인다). gccrs 개발자들은 커널을 빌드하는 것을 최우선 과제 중 하나로 보고 있으며, Ojeda는 내년에 이 프로젝트에서 흥미로운 소식이 있을 것으로 기대한다고 말했다.
Rust 언어 버전과 관련해서는, 현재 계획은 커널이 언제나 Debian stable 릴리스에 포함된 Rust 버전으로 빌드 가능하도록 보장하는 것이다. 커널의 최소 버전은 해당 Debian 릴리스 이후 6~12개월 사이에 올릴 예정이다. 커널은 현재 최소 Rust 1.78을 지정하고 있고, (세션 시점의) 최신 버전은 1.92였다. Debian은 1.85를 제공하고 있으므로, Ojeda는 커널이 그 버전으로 옮겨가면 여러 우회책을 제거할 수 있을 것이라고 제안했다.
Jiri Kosina는 최소 언어 버전을 얼마나 자주 올릴 것인지 물었다. Ojeda는 Debian stable 릴리스 때마다 올릴 것이라고 반복했지만, 장기적으로는 Debian 릴리스 두 번 중 한 번 꼴로 바뀔 수도 있다고 했다. 대체로 개발자들이 무엇을 필요로 하느냐의 문제라고 그는 말했다. Linus Torvalds는 개발자들이 배제되는 결과만 초래하지 않는다면 최소 버전을 비교적 공격적으로 올리는 것에 찬성한다고 했다. 배포판들은 전통적으로 GCC를 업데이트해온 것보다 Rust를 더 공격적으로 업데이트하고 있으므로, 더 새 버전을 요구하는 것이 덜 문제가 될 것이라고 했다.
Arnd Bergmann은 SUSE의 SLES가 뒤처져 있었던 탓에 커널이 GCC 8을 최소 지원 버전으로 선언하는 시점을 1년 더 앞당기지 못했었다고 말했다. Kosina는 SUSE가 이제 더 좋아져서 최신 컴파일러 버전을 제공하고 있다고 답했다. Dave Airlie는 엔터프라이즈 배포판들이 Rust를 활성화하기 시작하면 문제가 생길 수 있다고 우려했다. 이들이 오래된 버전을 오랫동안 고정해버릴 수 있기 때문이다. 하지만 Thomas Gleixner는 이제 Debian조차 GCC 14를 제공하고 있다고 언급하며, 전반적인 상황이 나아졌다고 말했다.
이 모든 소식을 감안할 때, Ojeda는 “experimental” 태그를 재고할 때가 되었는지 물었다. 그는 그 변경 요청에 대해 보수적으로 접근하려고 했지만, Android가 Rust 코드를 출하하고 있는 만큼 이제는 때가 왔다고 말했다. Airlie는 4월 1일에 발표하면서 실험이 실패했다고 말하자고 농담을 던졌다. 좀 더 진지하게는, “experimental” 태그를 제거하면 회사 내에서 Rust에 더 많은 자원을 투입하도록 설득하는 데 도움이 될 것이라고 말했다.
Bergmann도 실험 종료 선언에 동의했지만, Rust가 아직 “아무도 쓰지 않는 아키텍처에서는 동작하지 않는다”는 점만 우려했다. 그래서 당분간 Rust 코드는 잘 지원되는 아키텍처로 제한해야 한다고 생각했다. Ojeda는 현재 x86, Arm, Loongarch, RISC-V, user-mode Linux에 대한 지원이 좋으며, 주요 아키텍처는 양호하다고 말했다. Bergmann이 PowerPC 지원을 묻자, Ojeda는 PowerPC 개발자들이 가장 먼저 Rust 지원을 추가하는 pull request를 보낸 사람들 중 하나라고 답했다.
Bergmann은 s390 지원에 대해서도 계속 물었다. Ojeda는 이를 살펴본 결과 동작해야 한다고 결론 내렸지만, 현재 상태는 모르겠다고 했다. Airlie는 IBM이 그 문제를 해결해야 하며 결국 해결될 것이라고 말했다. Greg Kroah-Hartman은 Rust 업스트림이 그 아키텍처를 지원한다고 지적했다. Bergmann이 빅엔디언 시스템에서 문제가 예상되는지 묻자, Kroah-Hartman은 일부 드라이버는 그런 시스템에서 제대로 돌아갈 가능성이 낮다고 말했다.
코어 커널이 Rust 코드에 의존성을 추가하는 문제에 관해 Airlie는 1~2년은 더 걸릴 것이라고 말했다. Kroah-Hartman은 코어 커널과 Rust 드라이버 간 상호작용을 걱정했지만, 예상보다 그런 문제를 훨씬 덜 보았다고 말했다. Rust로 작성된 드라이버는 실제로 C로 작성된 드라이버보다 훨씬 더 안전하다는 것이 입증되고 있다고 했다. Torvalds는 Rust 코드에 CVE 번호를 부여하자는 요구가 나오기 시작했는데, 이는 Rust가 분명히 더 이상 실험이 아니라는 증거라고 말했다. Kroah-Hartman은 Rust 코드에 대해 아직 그런 CVE는 발급된 적이 없다고 했다.
DRM(그래픽) 서브시스템은 Rust 언어의 초기 채택자였다. 하지만 Airlie(DRM 메인테이너)가 이 서브시스템이 “약 1년 정도 후”에는 C로 작성된 새 드라이버를 허용하지 않고 Rust 사용을 요구하게 될 것이라고 말했을 때는, 그래도 다소 놀라운 일이었다.
Ojeda는 처음 질문으로 돌아갔다. “experimental” 상태를 끝낼 수 있는가? Torvalds는 거의 5년이 지났으니 이제 때가 되었다고 말했다. Kroah-Hartman은 컴파일러 개발자들의 지원이 늘어난 것을 승리를 선언할 강한 이유로 들었다. Steve Rostedt는 함수 트레이싱이 동작하는지 물었다. Alice Ryhl는 그것은 실제로 동작한다고 빠르게 답했지만, “심볼 디맨글링이 있으면 좋겠다”고 덧붙였다.
Ojeda는 Rust로 작업할 수 있는 능력이 새로운 개발자와 새로운 메인테이너를 끌어들이는 데 성공했으며, 이것이 프로젝트의 원래 목표 중 하나였다고 결론지었다. 또한 사람들에게 문서화 작업을 하도록 영감을 주고 있다고 했다. Rust 코드를 리뷰하고 싶어 하는 사람들이 많으며, 그는 새로운 사람들을 빠르게 성장시키는 데 도움을 줄 수 있는 더 경험 많은 개발자들의 목록을 만들고 있다고 말했다.
세션은 Dan Williams가 이런 프로젝트를 이끌기에 Ojeda보다 더 나은 사람을 상상할 수 없다고 말하며 축하를 전했고, 방 안에서는 큰 박수가 터져 나오는 것으로 마무리되었다.
| 이 글의 인덱스 항목 |
|---|
| Kernel |
| Conference |
2025년 12월 13일 3:02 UTC (토) Paf (구독자, #91811) [링크]
정말 축하할 만합니다. 오래 C 개발을 해온 사람으로서, 이 영역에서 더 나은 무언가가 실제로 쓰이는 것을 보는 건 매우 흥분되는 일이네요. 이제 1~2년만 더 지나면 저도 뭔가에 써볼 수 있을 것 같습니다.
2025년 12월 13일 4:48 UTC (토) Cyberax (✭ supporter ✭, #52523) [링크]
참고로, Rust를 읽기 쉬운 C로 번역하는 새 프로젝트가 있습니다: https://jonathan.protzenko.fr/2025/10/28/eurydice.html
이런 특수한 아키텍처들을 위해 조사해볼 만한 것 같습니다.
2025년 12월 13일 13:57 UTC (토) patrick_g (구독자, #44470) [링크] (응답 13개)
DRM(그래픽) 서브시스템은 C로 작성된 새 드라이버를 허용하지 않고 Rust를 요구하기까지 “약 1년 남았다”.
와. 제가 예상한 것보다 훨씬 빠르네요.
2025년 12월 13일 14:19 UTC (토) pizza (구독자, #46) [링크]
와. 제가 예상한 것보다 훨씬 빠르네요.
음, 꼭 그렇진 않죠. 이 “실험”의 요점이 사실상 그거였으니까요 [1].
제게 더 중요한 질문은 (a) 언제 코어 서브시스템에 Rust가 들어가서 Rust가 진짜로 _필수_가 되는지(“하드웨어 foo가 있는 경우에만 옵션”이 아니라), 그리고 (b) 언제 모든 새 코드에 Rust를 요구하게 되는지입니다.
어중간한 절충에는 의미가 없습니다. 그런 건 비용만 높이고 이점은 줄이니까요.
[1] 흔히 말하듯 “안 되면 임시일 뿐이다”.
2025년 12월 13일 14:41 UTC (토) iabervon (구독자, #722) [링크] (응답 11개)
제가 기대했던 것보다 빠르긴 하지만, 저는 유사한 작은 드라이버들이 많이 새로 생기는 분야를 생각하고 있었어요. DRM은 대형 드라이버들이 유사한 장치들을 상당 부분 포괄하다가, 충분히 갈라질 때에야 새 설계를 정당화할 수 있는 편이니, 실제로 새로 시작할 때는 매우 앞을 내다보는 게 합리적입니다. 여기서 변화에 대한 저항은, 새 기능을 추가하기 위해 기존 드라이버를 Rust로 다시 쓰라고 요구하지 않는 데에 있죠.
2025년 12월 14일 3:14 UTC (일) riking (구독자, #95706) [링크] (응답 10개)
GPU 드라이버는 현대 컴퓨터에서 가장 크래시가 잦은 부분으로도 유명하고, Android의 “새로운 메모리-불안전 코드 구성요소 금지” 정책이 좋은 결과를 내고 있는 듯합니다. 따라 하는 게 타당해 보입니다.
2025년 12월 14일 22:23 UTC (일) hailfinger (구독자, #76962) [링크] (응답 9개)
더 많은 파일시스템 드라이버가 Rust로 작성되기를 기대하고 있습니다. 이는 어느 정도(말장난은 아닙니다) “사용자가 악성 파일시스템을 마운트하는” 문제를 해결해줄 겁니다. 물론 서비스 거부(DoS)는 여전히 가능하겠지만, 파일시스템 드라이버에 코드 실행 버그가 없다는 건 제 기준에서는 큰 장점입니다.
2025년 12월 15일 9:54 UTC (월) taladar (구독자, #68407) [링크] (응답 4개)
“악성 파일시스템”으로 인한 “서비스 거부”가 정말 문제로 볼 수 있나요? 즉, 악성 파일시스템을 만들 수 있는 사람이면 핵심 파일시스템 구조를 전략적으로 덮어써서 DoS는 본질적으로 항상 가능하지 않나요?
2025년 12월 15일 10:23 UTC (월) farnz (구독자, #17727) [링크] (응답 3개)
서비스 거부가 어디까지 영향을 미치느냐에 달렸죠. 악성 파일시스템에만 접근이 제한된다면 문제는 아닙니다. 하지만 악성 파일시스템이 FS 드라이버로 하여금 락을 잡은 채로 유지하게 해서 어떤 파일시스템에도 접근하지 못하게 만들 수 있다면, 그건 DoS 공격입니다.
2025년 12월 15일 12:54 UTC (월) pizza (구독자, #46) [링크] (응답 2개)
악성 파일시스템에만 접근이 제한된다면 문제는 아닙니다.
…그럼 악성과 단순 손상(파손)을 어떻게 구분하죠?
(전자 접근을 막는 “DoS”는 좋다고도, 후자는 나쁘다고도 할 수 있는데요…)
2025년 12월 15일 12:57 UTC (월) farnz (구독자, #17727) [링크]
파일시스템이 손상되면 어차피 장담할 수 있는 건 없죠. 손상이 데이터가 복구 불가한 수준까지 확장됐을 수도 있습니다. 따라서 손상된 파일시스템의 내용은 보안 관점에서 이미 “서비스”의 일부가 아닙니다. 왜냐하면 이미 잃어버린 것이니까요. 구현 품질 관점에서 손상된 파일시스템에서 가능한 많은 데이터를 복구할 수 있으면 좋겠지만, 이는 시스템 전체의 가용성에는 영향을 주면 안 되고, 그 파일시스템 하나에만 영향을 줘야 합니다.
2025년 12월 16일 2:09 UTC (화) corbet (편집자, #1) [링크]
Linux에는 “단순히 손상된”(corrupted) 파일시스템을 적절히 처리할 수 있는 파일시스템들이 여럿 있습니다. 악의적으로 손상된 파일시스템은 올바른 메타데이터 체크섬을 갖고 있어서 탐지하기 훨씬 어렵습니다. 질적으로 다른 문제입니다.
2025년 12월 15일 10:38 UTC (월) jengelh (구독자, #33263) [링크]
여기만 봐도 됩니다: https://lwn.net/Articles/1044432/
2025년 12월 17일 8:09 UTC (수) koflerdavid (구독자, #176408) [링크] (응답 2개)
악의적으로 손상된 파일시스템은 커널이 충분히 방어하지 못하는 중요한 공격 벡터입니다. 마운트 권한이 root에 속하는 데는 이유가 있죠.
파일시스템 작성은 악성 입력을 걱정하지 않더라도 이미 충분히 복잡합니다. 그리고 Rust tar 라이브러리의 보안 구멍에서 보았듯, Rust를 쓴다고 해서 해결책이 되는 것은 아닙니다.
2025년 12월 17일 9:07 UTC (수) taladar (구독자, #68407) [링크] (응답 1개)
Rust 구현이 tar의 그 두 개 크기 필드처럼 모호하고 나쁜 표준으로부터 보호해주지는 못합니다. 논리 버그로부터도 보호해주지 못하죠. 하지만 다른 보안 이슈들에 쓰는 노력을 줄여주기 때문에 그런 문제들을 찾는 데 도움이 되지 않는다는 뜻은 아닙니다.
2025년 12월 17일 10:37 UTC (수) koflerdavid (구독자, #176408) [링크]
악성 파일시스템으로부터 안전해지는 것은 파일시스템을 공격 벡터로 인식하는 것에서 출발하는 의식적인 설계 결정의 결과입니다. 모호함이 파일시스템에서는 마법처럼 사라지는 것도 아니고, 특히 여러 구현이 있는 경우라면 더 그렇죠. Rust가 이런 것들에 도움이 될 수는 있지만, 과장해서 약속하는 건 보기 좋지 않습니다.
2025년 12월 13일 14:19 UTC (토) smcv (구독자, #53363) [링크]
Thomas Gleixner는, 심지어 Debian도 이제 GCC 14를 제공한다고 언급했다
Debian stable은 일부 “엔터프라이즈” 배포판들만큼 오래되지 않습니다. 다음 stable 릴리스로 대체되기까지 수명은 약 2년이죠. 설령 프리즈가 1년 내내 걸린다고 비관적으로 가정해도 “새 것 가능”에서 대체까지 약 3년 정도입니다. Ubuntu LTS도 비슷한 수명을 갖지만 Debian과 약 1년 정도 어긋나 있습니다.
Debian 생태계에서 새 버전을 전제로 할 수 있는지의 제한 요소는, 더 이상 최신이 아닌 “oldstable” 릴리스(예: 글 작성 시점의 Debian 12 또는 Ubuntu 22.04)까지 지원하려고 하느냐입니다. 또는 더 오래된 LTS(예: Debian 11 또는 Ubuntu 20.04)처럼 제한적 혹은 제3자 지원만 있는 경우도 있죠. Linux Mint나 pop!OS 같은 Ubuntu 파생 배포판이 Ubuntu 자체보다 더 제약 요인이 되는 경우도 있는데, 이들이 권장 릴리스를 항상 최신 Ubuntu LTS에 맞추지는 않기 때문입니다.
이런 오래된 릴리스는 지원 수준이 감소하긴 해도 꽤 오랫동안 0이 되지는 않기 때문에, 업스트림은 대개 어느 선에서 지원을 끊을지 트레이드오프에 기반해 결정해야 합니다. 예컨대 “최신 Debian stable 또는 최신 Ubuntu LTS 중 더 오래된 것을 기준으로 삼고, OS가 그것보다 오래되었으면 업그레이드해달라”는 정책은 실무에서 꽤 잘 작동하는 편이라고 느꼈습니다.
2025년 12월 15일 10:00 UTC (월) taladar (구독자, #68407) [링크] (응답 35개)
솔직히 말해, 그렇게 많은 사람들이 Rust 컴파일러가(버그를 제외하면) 최신 버전이 과거 버전에서 컴파일되던 코드를 모두 컴파일할 수 있도록 만들어져 있다는 점을 완전히 무시하는지 이해가 되지 않습니다. 그래서 구버전을 쓰는 게임은 불필요하죠.
2025년 12월 15일 10:44 UTC (월) hailfinger (구독자, #76962) [링크] (응답 1개)
하지만 여기서는 Rust 컴파일러의 최소 요구 버전을 올리는 이야기, 즉 반대 방향 아닌가요?
물론 더 새로운 Rust 컴파일러로 예전 컴파일러 버전을 타겟으로 한 코드를 컴파일할 수는 있지만, 오래된 Rust 컴파일러로 더 새로운 컴파일러 버전을 타겟으로 한 코드를 컴파일할 수는 없습니다. 오래된 버전에는 아직 없는 기능들이 있을 수 있으니까요.
2025년 12월 15일 12:35 UTC (월) taladar (구독자, #68407) [링크]
네, 하지만 그들이 올리는 최소 버전은 이미 다시 여러 버전 뒤처진 것입니다.
2025년 12월 15일 10:49 UTC (월) farnz (구독자, #17727) [링크] (응답 32개)
“stable” 배포판은 릴리스 후 버전을 크게 올리는 업데이트를 피하려 합니다. 예컨대 RHEL을 쓰면 컴파일러는 RHEL 릴리스 시점에 고정되고, 포인트 릴리스에서는 거의 바뀌지 않습니다(다만 더 새 버전 컴파일러를 받을 수 있는 “toolset” 패키지는 보통 있습니다). 이는 특정 릴리스 버전에서 알려진 버그 집합을 유지하기 위한 것으로, 이상적으로는 stable 배포판이 수정 사항을 적용하면서 버그가 단조 감소하길 기대합니다. 그 결과 커널은 stable 배포판보다 더 새로운 컴파일러를 요구하고 싶지 않아 합니다. stable 배포판은 알려진 버그 집합을 고수하려 하고, 새 컴파일러 버전에서 새 버그가 들어오는 위험을 감수하지 않으려 하기 때문입니다. 물론 더 새로운 컴파일러를 사용하는 것은 자유입니다(예: 커널이 GCC 8.1 이상을 요구하더라도 많은 커널은 더 새로운 GCC로 빌드됩니다. 예컨대 제가 지금 쓰는 커널은 GCC 15.2로 빌드되었죠). 하지만 커널은 GCC 8.1보다 더 새로운 GCC를 요구하는 C 코드 패치는 받아들이지 않을 것입니다. 아직 8.1을 쓰는 중요한 stable 배포판이 존재하기 때문입니다.
2025년 12월 15일 12:37 UTC (월) taladar (구독자, #68407) [링크] (응답 29개)
하지만 stable 배포판이 다른 소프트웨어에 대해 그렇게 하는 이유는 대부분의 프로그램이 Rust 컴파일러처럼 하위 호환되는 방식이 아니기 때문입니다.
그냥 그만해야 합니다. 솔직히 말해 기존 소프트웨어도 가장 오래된 LTS 배포판과 최신 릴리스 간 버전 차이가 너무 커서 꽤 짜증납니다. 저는 고객을 위해 그 모든 것을 운영해야 하는 시스템 관리자로서 하는 말입니다.
2025년 12월 15일 12:50 UTC (월) farnz (구독자, #17727) [링크] (응답 9개)
아니요. stable 배포판이 그렇게 하는 이유는 새 버그가 추가될 가능성을 최소화하기 위해서입니다. 목표는 x < y인 임의의 x, y에 대해 RHEL M.y의 버그 목록이 RHEL M.x의 버그 목록과 동일하거나 그 부분집합이 되도록 하는 것입니다. 따라서 RHEL M.x에서 동작하던 서비스를 가져오면, 최악의 경우에도 M.y에서도 같은 문제를 겪는 수준이어야 하죠(OS가 버그여야만 성립하는 동작에 의존하지 않았다면).
이는 하위 호환성과는 무관합니다. 새 릴리스가 100% 호환이라도, 새 릴리스의 모든 버그가 옛 릴리스에도 존재한다는 보장이 없으면 이 정책에 걸릴 수 있습니다.
2025년 12월 15일 17:30 UTC (월) khim (구독자, #9252) [링크] (응답 1개)
아니요. stable 배포판이 그렇게 하는 이유는 새 버그가 추가될 가능성을 최소화하기 위해서입니다. 그런데 왜 그 논리가, 새 코드가 들어오고 더 새 컴파일러가 필요해지는 상황을 막지 못하는 거죠?
사람들이 화나는 건 그것입니다. 오래되고 안정적인 코드는 괜찮아요. 저도 오래된 하드웨어와 소프트웨어를 자주 만집니다. 그런데 그걸 다루는 도구까지 오래된 걸 쓰라고 하잖아요!
왜 오래된 컴파일러와 새 Linux 커널을 섞으려 하죠? 정말 이해가 안 됩니다!
2025년 12월 15일 17:44 UTC (월) farnz (구독자, #17727) [링크]
배포판은 새 컴파일러 버전이 필요한 새 코드를 가져오지 않습니다. 커널 버전을 포함해 모든 것을 릴리스 시점에 고정하죠. 하지만 커널은 배포판 커널에서 버그를 찾은 사람들이 최신 커널(그리고 Linus의 최신 릴리스 위에 얹은 패치까지 포함)에서 테스트할 수 있길 원합니다. 다음 배포판 릴리스까지 기다리게 만들고 싶지 않죠. 오래된 컴파일러 버전을 유지하는 이유는 배포판이 아니라, 더 오래된 컴파일러 등을 가진 배포판 위에서도 빌드할 수 있길 바라는 커널 개발자들 때문입니다.
2025년 12월 16일 9:14 UTC (화) taladar (구독자, #68407) [링크] (응답 6개)
문제는 stable 배포판이 백포트가 코드베이스에 익숙하지 않은 사람들이 upstream 릴리스보다 훨씬 적게 테스트한 새 코드임에도, 마치 새 버전이 아닌 것처럼 행동한다는 겁니다.
RHEL은 버그 측면에서 최악의 배포판 중 하나입니다. 핵심 패키지 관리 도구에 심각한 버그가 여러 번 있었고, 트랜잭션 도중 세그폴트가 나면서 업데이트 중간에 중복 설치된 RPM이 남는 경우도 있었습니다. 수년간 최신 upstream을 계속 업데이트해도 멀쩡하던 제 unstable Gentoo에서는 그런 일이 없었는데요.
백포팅 과정이 새 버그를 도입하지 않는다는 생각은, 관리자가 “불가능한 일을 해내야 한다”고 요구할 때 사람들에게 하는 거짓말 중 하나일 뿐입니다.
2025년 12월 16일 14:36 UTC (화) pj (구독자, #4506) [링크] (응답 5개)
백포팅 과정이 새 버그를 도입하지 않는다는 생각은… 거짓말
동의합니다. 왜 경영진은 현재 깨진 코드를 백포트된 변경(“수정”)으로 바꾸는 것이, 그냥 업그레이드하는 것만큼(혹은 그보다) 불안정할 수 있다는 걸 이해하지 못할까요? 게다가 업그레이드하면 다른 모든 테스트와 수정의 혜택도 함께 받으니, 더 잘 동작하는 시스템이 될 가능성이 높고, 문제가 생겨도 표준 버전에 대해 버그를 보고할 수 있는데요!
2025년 12월 16일 15:08 UTC (화) pizza (구독자, #46) [링크] (응답 4개)
백포트된 수정이 업그레이드만큼 불안정하다
그 주장은 두 diff의 크기 차이로 쉽게 반박됩니다.
업그레이드하면 다른 모든 작업의 혜택도 함께 받는다
그 다른 모든 작업의 단점은 conveniently 무시하고 계시네요.
2025년 12월 17일 9:04 UTC (수) taladar (구독자, #68407) [링크] (응답 3개)
그리고 당신은 그 백포트 작업에 드는 기회비용(예: 더 장기적으로 유용한 테스트 추가 등)을 무시하고 있네요.
2025년 12월 17일 13:13 UTC (수) pizza (구독자, #46) [링크] (응답 2개)
기회비용을 무시한다
사실 그렇지 않습니다. 저(그리고 여기 다른 사람들)는 서로 다른 사람들이 각 선택지의 비용과 이점에 서로 다른 가중치를 두며, 그 결과 각자의 운영 제약(장비/시간/예산/규제 등)에 따라 “최적” 결과가 달라진다고 말하는 겁니다.
…당신은 한쪽은 비용뿐이고 다른 쪽은 이점뿐인 것처럼 말하네요.
2025년 12월 18일 9:09 UTC (목) taladar (구독자, #68407) [링크] (응답 1개)
여러 해 프로그래머이자 시스템 관리자였던 저는, 장기 지원 배포판이 존재하는 비용을 실제로 지불하는 쪽입니다. LTS 배포판이 안정성 보장을 얼마나 못하는지, 그리고 가장 오래된 LTS가 아직 지원하지 않는다는 이유로 많은 문제 해결책 도입을 미뤄야 하는 타협이 얼마나 큰지 봐왔기 때문에, 제겐 전부 비용으로 보입니다.
2025년 12월 18일 13:48 UTC (목) pizza (구독자, #46) [링크]
전부 비용으로 보인다
그럴 수 있죠.
하지만 같은 질문을 LTS 배포판의 사용자들에게 던지면 전혀 다른 답이 나올 겁니다.
다시 말하지만, 사람마다 비용과 이점의 상대적 중요도에 서로 다른 가중치를 둡니다.
(개인적으로는 $$$(또는 패치)가 붙어 있지 않으면 그냥 무시합니다.)
2025년 12월 15일 12:51 UTC (월) pm215 (구독자, #98099) [링크] (응답 3개)
stable 배포판이 다른 소프트웨어에 대해 그렇게 하는 이유는 의도적인 하위호환 파괴를 피하는 것뿐 아니라, 새 버전에 неизбеж하게 섞여 들어오는 의도치 않은 새 버그를 피하려는 것도 있다고 생각합니다. 아무리 잘 운영되는 프로젝트가 신중한 하위호환 약속을 해도, 새 코드를 쓰는 이상 새 버그는 들어가기 마련이죠. 이는 Rust에만 해당되는 문제가 아닙니다. 누구도 “ls” 인터페이스가 호환되지 않게 바뀔 거라 기대하진 않지만, stable 배포판은 여전히 릴리스 시점 버전에 머뭅니다.
stable 배포판의 약속은 최소한의 신중한 변경만 적용해, 사용자가 의존하는 것들을 깨뜨릴 위험을 최소화한다는 것입니다. 더 빠르게 업데이트되는 “롤링” 배포판을 선호한다면 그런 선택지도 있지만, 그것만이 유일한 형태가 아닌 데는 좋은 이유가 있다고 봅니다.
2025년 12월 16일 9:17 UTC (화) taladar (구독자, #68407) [링크] (응답 2개)
문제는 그게 실무에서는 전혀 작동하지 않는다는 겁니다. RHEL 같은 LTS 배포판은, 동시에 수십/수백 개 패키지의 백포트를 처리해야 하고 코드베이스의 동작에 익숙하지 않은 사람들이 도입한 새 버그로 가득합니다. 백포트는 새 버전입니다. 다만 테스트가 부실한 새 버전일 뿐이죠.
2025년 12월 16일 16:36 UTC (화) pm215 (구독자, #98099) [링크] (응답 1개)
제 경험은 다르네요. 수십 년간 Debian과 Ubuntu stable 배포판을 써왔지만, stable/security 업데이트로 도입된 버그를 만난 기억이 없습니다.
2025년 12월 19일 0:15 UTC (금) rgmoore (✭ supporter ✭, #75) [링크]
이는 배포판이 “안정”을 얼마나 오래 약속하느냐에 따라 다를 수 있습니다. 약속이 길수록 “stable”과 현재 버전 사이 괴리가 커지고, 백포트는 더 어려워집니다. 이는 어떤 안정성 보장 기간에도 실질적 한계를 두게 될 텐데, 주요 upstream 프로젝트가 오래된 버전을 얼마나 잘 지원하는지와 관련이 있을 겁니다. 공식 LTS 버전이 지원하는 범위를 넘어 자체 커널 백포트를 하려는 배포판은 문제를 자초하는 셈입니다.
2025년 12월 15일 13:03 UTC (월) pizza (구독자, #46) [링크] (응답 1개)
대부분의 프로그램이 Rust 컴파일러처럼 하위 호환되지 않는다
그건 당신의 코드(그리고 끌어오는 모든 크레이트)가 “unstable” Rust 기능을 전혀 쓰지 않을 때만 해당됩니다.
2025년 12월 16일 9:20 UTC (화) taladar (구독자, #68407) [링크]
네, 릴리스된 stable 버전만 실제로 사용한다면요. 그래서 Linux 커널이 필요한 기능들이 안정화된 Rust 버전으로 빨리 올라가야 한다는 이유가 더 됩니다. 그렇지 않으면 몇 년 뒤 업데이트할 때 옛 unstable 기능에서 큰 점프를 하게 되는 “안정성의 환상”만 남게 될 겁니다.
2025년 12월 15일 13:32 UTC (월) johill (구독자, #25196) [링크] (응답 6개)
“내/이 소프트웨어는 특별하니 stable 배포판도 안정적일 필요 없다”는 주장은 아마 절대 이길 수 없을 겁니다.
2025년 12월 16일 9:26 UTC (화) taladar (구독자, #68407) [링크]
맞을지도 모르죠. 백포트를, 새 보안 수정과 때로는 기능까지도 새 버그 위험 없이 제공하는 만병통치약처럼 파는 뱀 기름 산업은 너무 깊게 뿌리내렸습니다. 실제로는 코드베이스 경험이 적은 사람들이(수십/수백 패키지를 맡으니) 적게 테스트한 포크에 가깝습니다.
2025년 12월 16일 11:17 UTC (화) farnz (구독자, #17727) [링크] (응답 4개)
문제의 일부는, 물리 매체가 주요 배포 수단이던 시절에서 네트워크 링크로 옮겨온 이후로 “stable distro” 개념을 진지하게 재평가하지 않았다는 점입니다. “패치 릴리스에서 새 버그 없음”을 원하는 동력은 “버그 발견”에서 “버그 수정”까지 걸리는 시간에 있었습니다. 물리 매체 시절에는 수정된 바이너리를 우편으로 보내야 해서, 새 버그는 큰 문제였습니다. 우편으로 수정본이 도착할 때까지 다운타임을 감수하거나, 도착할 때까지 다른 우회책을 찾아야 했죠.
이제는 네트워크로 수정본을 받을 수 있어 턴어라운드가 수일/수주에서 수시간/수일로 줄었습니다. 그래서 “새 버그 없음” 약속이 여전히 예전만큼 중요한지 확실치 않습니다. 오늘날에는 “회귀를 빠르게 수정”하는 약속이 더 가치 있을지도 모르죠. 변경이 많아지긴 해도 회귀도 빠르게 고쳐지니까요.
2025년 12월 19일 0:38 UTC (금) rgmoore (✭ supporter ✭, #75) [링크] (응답 3개)
이는 애플리케이션 소프트웨어를 기반 시스템 변화에 맞춰 얼마나 쉽게 업데이트할 수 있는지에 크게 달려 있다고 생각합니다. 애플리케이션이 FOSS거나 사내 개발로 완전히 통제 가능하다면, 최신에 가깝게 유지하는 게 합리적일 수 있습니다. 반대로 애플리케이션을 쉽게 바꿀 수 없다면, 기반이 호환되지 않는 변경을 하지 않도록 하는 게 훨씬 더 중요해집니다.
애플리케이션을 완전히 통제하지 못하는 이유는 많습니다. 바이너리만 제공되는 상용 소프트웨어를 쓰는 사람들은 벤더가 제공하는 것에 맞춰야 합니다. 벤더가 업데이트를 제공하지 않거나(혹은 매우 비싸게 받거나) 심지어 폐업한 경우, 오래된 소프트웨어를 가능한 오래 돌리려 해야 합니다. 벤더가 정기 업데이트를 제공하더라도 워크플로를 깨는 비호환 변경이 포함될 수 있어, 사용자는 업데이트를 드물게 하고 싶어합니다. 규제 기관이 소프트웨어 업데이트 때마다 비용과 시간이 많이 드는 검증을 요구하는 경우도 있어, 오래된 버전을 유지하는 게 노동을 크게 줄입니다.
2025년 12월 19일 5:06 UTC (금) raven667 (구독자, #5198) [링크] (응답 1개)
아주 작은 팀이나 1인 개발자 팀에서는, 플랫폼 변경에 맞춰 사내 소프트웨어를 재테스트하고 수정하는 유지 비용이 결코 작지 않습니다. 규제 기관이 철저한 검증을 요구하지 않더라도요. 모든 조직이 기능 개발/버그 수정에 쓰던 시간을 크게 멈춰가며, 불규칙하고 불편한 일정으로 플랫폼 리베이스를 할 의지가 있는 것도 아닙니다. 어떤 조직은 하드웨어를 교체하고 새 OS로 옮겨야 하는 5~10년 주기에 맞춰 계획하는 편이 낫습니다. 두 스택을 병행하며 통합 테스트를 할 수 있는 기간이 있고, 조직이 마이그레이션 시간을 확보할 수 있으니까요. 계속 업데이트를 쫓다 보면, 각종 라이브러리가 의도적으로 또는 실수로 동작을 바꿔서 장애를 추적하게 될 수 있습니다.
이건 QA 환경과 충분한 테스트 스위트가 있으면 해결 가능한 문제이지만, 소규모 조직에겐 시간 측면에서 과도한 비용이며 다른 우선순위와 직접 경쟁합니다. 대규모 팀은 커뮤니케이션 오버헤드 때문에 더 공식적인 프로세스, CI, 테스트 등이 필요하고, 그런 환경에선 자동화 테스트에 시간을 쓰는 게 더 유리해지죠.
그래서 저는 커널, glibc 등 일부 핵심 유틸을 제외하면, ABI 규율이 “아무 생각 없이 업데이트해도 안전”할 수준으로 갖춰져 있지 않다는 점에서, LTS/엔터프라이즈 배포판이 왜 모든 것을 동결하려 하는지 이해합니다. 이는 개발자들이 무능해서가 아니라, 많은 프로젝트가 자원봉사 기반이어서 배포판 제작자가 인터넷에서 주워온 모든 도구/라이브러리가 같은 ABI 기준을 갖추길 기대하는 게 비현실적이기 때문입니다. 배포판 제작자는 이를 동결과 신중한 패치로 완화하지만(완전히 제거하진 못하죠), 롤링 배포판을 프로덕션에서 쓰는 사람들은 워크로드에 영향을 주는 변경이 생길 때 얼마나 재테스트하고 수정해야 할까요? 아마 0은 아닐 겁니다.
2025년 12월 19일 10:17 UTC (금) farnz (구독자, #17727) [링크]
서로 다른 사내 소프트웨어, 총 개발자 수 3명(직원의 절반)부터 1만 명 이상까지 세 번에 걸쳐, 저는 더 빠르게 새 플랫폼으로 리베이스하도록 밀어붙인 적이 있습니다. 세 경우 모두에서 제가 체감한 경험은, upstream 플랫폼에 더 가깝게 유지할수록 플랫폼 리베이스에 쓰는 총 시간이 줄어든다는 것입니다. “현재”에 매주 리베이스하면 3년마다 리베이스하는 것보다 여러 이유로 경험이 더 좋아집니다:
다만 이는 전통적인 LTS/엔터프라이즈 사고방식(당신이 매우 잘 설명한)에서 큰 태도 변화가 필요합니다. 그리고 릴리스 사이에 upstream 개발자와 직접 소통하고, 그들이 하는 일을 테스트할 수 있을 때만 가능합니다(상용 종속성이 있으면 불가능하죠). 또한 플랫폼 리베이스가 지금처럼 항상 큰 비용일 거라고 기대한다면 매우 두렵기도 합니다. 이점이 드러나기까지 시간이 걸리기도 하죠(예: 리베이스에 6개월을 잡아두었는데, 실제로는 지난 큰 리베이스 이후 누적 3개월만 최신으로 리베이스하는 데 쓴 걸 깨닫게 되는 식입니다).
2025년 12월 19일 9:23 UTC (금) farnz (구독자, #17727) [링크]
“새 버그 없음”만이 “비호환 변경 없음”을 얻는 유일한 방법은 아닙니다. “회귀를 빠르게 고치기” 정책도 사용자 문제를 일으키는 변경을 고쳐서 같은 목적을 달성합니다. 그리고 “회귀를 빠르게 고쳐서 사용자들이 최신 버전에 머물게 하는 것”에는 큰 장점이 있습니다. 정의상 지난주 변경 중 어떤 것이 버그를 일으켰는지 찾는 것이 지난 15년 변경 중에서 찾는 것보다 쉽기 때문입니다. 사용자들이 영원히 머물러 있는 것은 아니죠. 예컨대 2024년에 지원이 끝날 때까지 RHEL6을 쓰던 사용자가(지원 없이) RHEL10을 기다렸다가 이제 RHEL10으로 옮겼다면, 그들은 RHEL6과 RHEL10 사이에서 “깨진 것”을 모두 고쳐달라 할 것입니다. 그러나 그건 너무 큰 작업입니다. OS 기반 전체에 대한 “회귀”이고, 거의 14년치 변경에서 무엇이 잘못됐는지 찾아야 하니까요.
더 나쁜 점은, 중간에 RHEL7/8/9가 있었기 때문에 RHEL6→RHEL10 간 “회귀”를 고치려 하면, RHEL7(또는 8, 9)→RHEL10에서는 회귀를 만들 수 있다는 것입니다. 이것이 작동하려면 RHEL이 강제하는 것처럼 지원 기간에 제한을 두고, 지원 기간이 끝나면 재인증/업데이트 구매/벤더가 살아있을 때 새 버전 도입 등을 해야 한다는 점을 받아들여야 합니다. 하지만 “14년마다 한 번 큰 패닉(때로는 사업 중단급)”이 “매일 작은 패닉”보다 낫다고 확신하지는 못하겠고, 실제로 Debian 같은 LTS 배포판에서도 “큰 패닉”을 본 적이 있습니다(옛 직장에서 Debian Sarge→Etch가 크게 깨졌고, 다른 사용자가 이미 의존하고 있어 회귀를 되돌릴 수도 없었지만, 우리는 어쨌든 업데이트해야 했죠). 그렇다고 잦은 업데이트가 정말 “매일 작은 패닉”인지도 확신이 없습니다. 오히려 “매달 한 번 작은 패닉, 그리고 upstream이 당신의 유즈케이스를 회귀 테스트에 추가”일 수도 있죠.
2025년 12월 16일 14:29 UTC (화) laarmen (구독자, #63948) [링크] (응답 5개)
“새 rustc는 옛 코드와 호환된다”는 말은 실제로는 완전히 사실이 아닙니다. 실무적으로 성립하는 것은, 새 rustc 릴리스 시점에 crater 런을 통해 crates.io의 모든 크레이트 최신 버전을 컴파일할 수 있어야 한다는 것입니다. 물론 이는 대단한 성과입니다. 그리고 표준적인 개발 관점에서는, 의존성을 최신으로 유지하는 것이 일반적이고 의존성 수도 그렇게 많지 않으니 두 개념이 거의 동일하게 보이기도 합니다.
하지만 LTS 배포판은 아주 많은 크레이트를 패키징하며, 대부분은 오래되었습니다. 그리고 이를 쉽게 업데이트할 수도 없습니다. 그런 환경에서 기본 Rust 컴파일러 버전을 올리는 것은 훨씬 더 위험해집니다.
2025년 12월 16일 14:34 UTC (화) farnz (구독자, #17727) [링크] (응답 1개)
제가 꽤 오래된 코드( rust-toolchain 파일 기준으로 1.24용)를 찾아봤는데, 현재 nightly로도 아주 잘 빌드됩니다. 불안정 기능을 쓰지 않았고 옛 rustc 용으로 작성되었는데도 현재 rustc에서 동작하지 않는 크레이트 예시가 있나요? 실제로 무엇이 깨졌는지 궁금합니다. 예컨대 std::env::set_var 변경은 알고 있는데, 지난 10년 동안 또 무엇이 깨졌는지 알고 싶습니다.
2025년 12월 16일 14:48 UTC (화) laarmen (구독자, #63948) [링크]
네, 대부분의 오래된 코드는 문제 없이 컴파일될 겁니다. 제가 보기엔 Rust의 호환성 스토리는 가장 좋은 축에 속합니다. 지금 당장 떠오르는 구체적 예시는 Rust 1.80과 time 정도인데, 그건 특수한 경우였고 실제로는 탐지되었지만 무시되기도 했죠. 다만 Rust 변경 로그에서 “이 변경으로 컴파일 실패한 크레이트 XX개를 확인했고, 작성자들과 함께 고친 새 버전을 출시했다” 같은 문구를 여러 번 본 기억이 있습니다.
2025년 12월 16일 15:03 UTC (화) pizza (구독자, #46) [링크] (응답 2개)
의존성을 최신으로 유지하고 의존성이 많지 않다
…“수백 개”는 “그렇게 많지” 않은 건가요?
(이 일화는 제가 지금 배포한 모든 Rust 기반 것들이 제공함)
2025년 12월 16일 15:23 UTC (화) laarmen (구독자, #63948) [링크]
맞아요, 제 실수입니다. 정확히는 crates.io 전체에 비해 “그렇게 많지 않다”는 의미였고, 그 말은 오래되고 호환성 문제가 있는 크레이트가 섞여 있을 확률이 낮다는 뜻입니다.
Rust 프로젝트의 엄청난 의존성 트리를 옹호하는 건 아닙니다 :-)
구체적인 수치를 들자면, Ubuntu의 Rust 1.85는 672개의 크레이트를 vendor합니다. 그 디렉터리는 cargo와 rustdoc을 포함한 전체 툴체인의 의존성을 담고 있으니, 생태계에서는 보수적인 편이라고 생각합니다.
2025년 12월 17일 9:02 UTC (수) taladar (구독자, #68407) [링크]
수백 개 크레이트는 예컨대 Qt 하나보다도 코드가 적을 가능성이 큽니다.
2025년 12월 15일 14:48 UTC (월) iabervon (구독자, #722) [링크] (응답 1개)
더 그럴듯한 주장은, 더 새 Rust 컴파일러가 उपलब्ध해도 오래된 것을 계속 쓰는 건 새 버그(혹은 새로 실행되는 코드)를 도입하지 않는다는 것이고, 오래된 Rust 컴파일러로 새 커널을 빌드하는 것이 새 Rust 컴파일러로 빌드하는 것보다 더 안정적인 건 아니라는 점입니다. C 사용자 공간에서는 어떤 것들은 새 컴파일러로, 다른 것들은 옛 컴파일러로 빌드하는 것이 문제가 될 수 있어서 여러 버전을 함께 두고 싶지 않을 수 있지만, Rust는 실행 파일에 들어가는 모든 소스(표준 라이브러리 포함)를 함께 빌드하는 경향이 있고, 커널도(C도 포함해) 비슷합니다.
새 Rust 컴파일러 릴리스가 있다고 해서 python-cryptography나 curl을 다시 빌드하는 건 피하는 게 맞겠지만, 그렇다고 upstream에서 하는 것처럼 더 새 Rust 컴파일러로 커널을 빌드하지 못할 이유는 없습니다.
2025년 12월 15일 14:59 UTC (월) pizza (구독자, #46) [링크]
새 커널을 옛 Rust 컴파일러로 빌드하는 것이 더 안정적인 건 아니다
…그 커널이 서로 다른 컴파일러 리비전에서 다르게 취급되는 “unstable” Rust 기능에 의존한다면 다르죠.
(제가 틀렸다면 정정해 주세요. 그런데 메인라인 R4L에는 아직 불안정 요소가 꽤 남아 있는 걸로 압니다. 시간이 지나면 줄어들겠지만, 새/선택적 Linux 기능을 위해 가끔은 다시 늘어날 거라고 기대하는 것도 합리적입니다.)
2025년 12월 15일 13:41 UTC (월) salimma (구독자, #34460) [링크] (응답 1개)
Dave Airlie는 엔터프라이즈 배포판이 Rust를 활성화하면 오래된 버전을 오래 고정할 수 있다고 우려했다
SLES나 Ubuntu LTS가 어떻게 영향을 받는지는 모르겠지만, CentOS Stream / RHEL은 Rust를 6개월마다 리베이스하고, 따라서 모든 다운스트림도 마찬가지입니다.
2025년 12월 15일 19:11 UTC (월) salimma (구독자, #34460) [링크]
예: 오늘 기준
$ fedrq pkgs --src rust -b ubi9
rust-1.88.0-1.el9.src
$ fedrq pkgs --src rust -b ubi10
rust-1.88.0-1.el10.src
$ fedrq pkgs --src rust -b c9s
rust-1.91.0-1.el9.src
$ fedrq pkgs --src rust -b c10s
rust-1.91.0-1.el10.src
$ fedrq pkgs --src rust -b f42
rust-1.91.1-1.fc42.src
$ fedrq pkgs --src rust -b f43
rust-1.91.1-1.fc43.src
$ fedrq pkgs --src rust -b rawhide
rust-1.92.0-1.fc44.src
2025년 12월 23일 16:07 UTC (화) moltonel (구독자, #45207) [링크] (응답 1개)
이 주제에 대해 많은 이견을 봤지만, 명확한 “공식” 입장은 못 봤습니다.
실험 기능에 대해 제출된 CVE는 거절될까요? CVE 할당 과정이 모든 버그 수정에 대해 체계적/포괄적으로 이루어질 만큼 충분한가요? Rust 실험에 대한 CVE가 적은 주된 이유가 실험 코드가 의도적으로 제외되기 때문인가요? CVE-2025-38033은 반례인가요?
2025년 12월 25일 7:57 UTC (목) gregkh (구독자, #8) [링크]
실험 기능에 대해 제출된 CVE는 거절될까요?
아니요.
CVE 할당 과정이 모든 버그 수정에 대해 체계적/포괄적으로 이루어질 만큼 충분한가요?
그렇게 되길 바랍니다. 놓친 게 있다면 cve@k.o의 개발자들에게 알려주세요.
Rust 실험에 대한 CVE가 적은 주된 이유가 실험 코드가 의도적으로 제외되기 때문인가요?
아니요.
그리고 언제나 그렇듯, 궁금하다면 사람들은 커널 CVE 메인테이너에게 이런 걸 그냥 물어볼 수도 있습니다 :)
Copyright © 2025, Eklektix, Inc.
이 글은 Creative Commons CC BY-SA 4.0 라이선스 조건에 따라 재배포될 수 있습니다.
댓글과 공개 게시물의 저작권은 각 작성자에게 있습니다.
Linux는 Linus Torvalds의 등록 상표입니다.
