리눅스 커널에서의 Rust 실험 (성공적) 종료

• 리눅스 커널 내 Rust 통합 작업이 실험 단계를 마치고 정식 구성 요소로 인정됨
• 연례 Maintainers Summit에서 개발자들이 Rust 지원을 영구적 기능으로 채택하기로 합의
• 이에 따라 커널 내 Rust 관련 코드에서 ‘experimental’ 태그가 제거될 예정
• LWN 편집자는 “실험은 끝났고, 성공이었다”고 밝히며 Rust for Linux 팀의 성과를 언급
• 이는 커널 개발 언어 확장과 안전성·현대화 방향의 중요한 전환점으로 평가됨

---

커널 Rust 실험의 종료와 정식 채택

• 연례 Maintainers Summit에서 커널 내 Rust 지원이 논의되었으며, 참석한 개발자들은 Rust가 더 이상 실험적 기능이 아님에 합의
  • Rust는 이제 커널의 핵심 일부로 자리 잡음
  • 이에 따라 관련 코드에서 ‘experimental’ 표시가 제거될 예정
• LWN 편집자는 게시글에서 “실험은 끝났고, 성공이었다”고 명시
  • Rust for Linux 팀의 노고에 대해 축하 메시지를 전달

커뮤니티 반응

• 게시글 제목이 일시적으로 오해를 불러일으켜, 일부 독자들이 Rust 제거로 착각하는 반응을 보임
  • 여러 댓글에서 “순간 속았다”, “감정 롤러코스터였다” 등의 반응이 이어짐
• 일부 사용자는 Phoronix의 헤드라인 스타일을 언급하며 유머러스하게 반응
  • Phoronix의 벤치마크 활동과 오픈소스 생태계 업데이트가 유용하다는 평가도 함께 제시됨
• 다른 댓글에서는 Microsoft가 Windows 커널에도 Rust를 도입 중임을 언급
  • 일부 구성 요소가 이미 Rust로 작성되어 출하 단계에 포함되었다는 의견 제시

Rust 도입의 의미

• 커널 내 Rust 지원이 공식적·지속적 기능으로 전환됨으로써,
  메모리 안전성 강화와 현대적 언어 도입이 커널 개발의 일부로 정착
• 커널과 Windows 양쪽에서 Rust가 채택되며, 시스템 프로그래밍 언어의 세대 교체 흐름이 가시화됨
• 커뮤니티는 이번 결정을 성공적인 실험의 완결로 받아들이며, 향후 Rust 기반 커널 모듈 확장을 기대하는 분위기

[secret3056]

그런 것 치고는 메인테이너가 여럿 떨어져나가지 않았나요?

[bus710]

한글 관련 서적이 딱 한권 나와 있는데, 아쉽게도 리눅스 커널에서 러스트 사용 방식이 여러번 브레이킹 체인지를 겪는 바람에 요즘의 커널과는 완전히 호환 되지 않더라구요. 깃헙 등을 통해 보완이 되면 참 좋겠습니다.

[GN⁺]

Hacker News 의견들

• Rust 지원이 지난 2년 동안 정말 많이 발전했음
  이제는 거의 보일러플레이트 없이 커널 모듈을 작성할 수 있을 정도임
  “experimental” 태그가 제거된 건 큰 이정표라고 생각함
  앞으로 배포판들이 Rust 지원이 기본 활성화된 커널을 내놓는 날이 진짜 전환점이 될 것 같음

  • 이미 일부 배포판은 그렇게 하고 있음
    예를 들어 NixOS와 Arch는 Rust로 작성된 QR 코드 커널 패닉 화면을 활성화함
    Fedora도 아마 지원하는 걸로 알고 있음
  • Fedora 43은 CONFIG_RUST=y로 컴파일된 걸로 알고 있음
  • “Rust 지원이 기본 활성화된 커널”이란 표현이 무슨 뜻인지 궁금함
    커널이 Rust 사용자 공간을 지원하는 건 아니고, 단지 일부 커널 코드가 rustc로 컴파일된다는 의미로 이해함
  • Rust가 GCC에서 완전 지원되기 전까지는 모든 플랫폼에서 가능할지 의문임

• 오랜 저항 끝에 Linux 커널에서 Rust가 공식적으로 채택된 게 감격스러움
  Rust for Linux 팀에게 박수를 보냄

  • 예전에 Asahi 프로젝트 관련 Rust 코드가 유지보수자 거부로 인해 혼란스러웠던 기억이 있음
    그 사건이 프로젝트의 첫 번째 도미노였는지 궁금함
  • Phoronix 기사에 따르면
    Rust for Linux 공동 유지보수자였던 Alex Gaynor가 공식적으로 물러났다고 함
    이제 Miguel Ojeda가 유일한 공식 유지보수자로 남았고, 여러 명의 코드 리뷰어가 있음

• “experimental” 태그 제거가 모든 유지보수자가 Rust 코드를 깨뜨리지 않도록 의무화된다는 뜻인지 궁금함

  • 실제로는 Rust가 커널에 정식으로 자리 잡았다는 신호일 뿐임
    개발자들이 Rust 기반 드라이버에 투자해도 된다는 안정감의 표시임
    여전히 규칙은 동일하고, Rust 빌드를 깨뜨리는 코드는 Linus에게 보낼 수 없음
  • 커널 내에서는 사용자 공간 API 외에는 안정성이 보장되지 않음
    즉, 유지보수자가 내부 Rust 코드를 깨뜨려도 규칙 위반은 아님

• Rust가 지원하지 않는 아키텍처들은 이제 버려지는 것인지 궁금함

  • 그렇지 않음. Rust는 현재 드라이버 서브시스템에서만 사용됨
    커널의 핵심 부분은 여전히 C로 작성되어야 함
  • 어떤 아키텍처가 지원되지 않는지 궁금함
  • 농담으로 “그렇다, 다 요리됐다(cooked)”고 표현함

• 기사 제목이 “The (successful) end of the kernel Rust experiment”로 수정되었다고 함
  원래 제목이 과장됐다는 커뮤니티의 피드백 때문임

  • 수정된 제목이 적절하다고 생각함
    Hacker News 가이드라인에 따르면
    “원래 제목이 오해의 소지가 있을 때만 수정하라”고 되어 있음
  • “successful”이라는 단어는 이미 암시된 것 같음
    실패한 실험은 끝나지 않기 때문임
  • 농담조로 “Linux devs tried Rust — you won’t BELIEVE the reaction!” 같은 제목을 제안함

• “이거 큰 일인가요?”라는 질문에

  • “맞음, 큰 의존성이 추가된 셈임”
  • “그렇다”고 짧게 동의함

• Linux 커널 드라이버가 Rust로 가는 흐름이라면, FreeBSD 같은 BSD 계열도 같은 산화(oxidation) 를 겪을지 궁금함
  아니면 저항과 분화가 생길지 주목함

• 새로운 시도를 반기는 입장임

  • 하지만 어떤 사람은 “새로운 건 불안정하고 배우기 어렵다”고 반박함
    Rust는 메모리 안전성과 표현력 덕분에 그 어려움을 감수할 가치가 있다고 생각함

• 현재 커널에서 Rust로 작성된 부분이 무엇인지 궁금함

  • 대표적으로 DRM Panic “Screen of Death” 가 Rust로 작성됨
    Phoronix 기사 참고
  • 주로 GPU 드라이버 쪽에서 Rust가 사용되고 있음

• 커널의 Rust 코드에 unsafe가 얼마나 포함되어 있는지 궁금함
  예전엔 unsafe가 너무 불편하다는 불만이 많았음

  • 대부분의 unsafe 코드는 C API와 상호작용하는 kernel crate 내부에 숨겨져 있음
    드라이버 개발자는 거의 unsafe를 쓸 필요가 없음
  • unsafe는 본질적으로 경계부 코드(edge) 에서만 쓰이도록 설계된 것임
    대부분의 코드는 안전한 Rust로 작성됨
  • unsafe가 여전히 어렵긴 하지만, 실제 드라이버 코드에서는 거의 등장하지 않음
    예를 들어 pwm_th1520.rs는
    Send와 Sync를 지원하기 위한 한 줄짜리 unsafe만 포함함
  • unsafe 블록은 문서화하고 안전한 인터페이스로 감싸서 다시는 직접 볼 필요 없게 만드는 게 원칙임