▲

Rust 의무 종속성, 2026년 5월부터 Debian APT에 도입 예정

 (lists.debian.org)
2P by GN⁺ 2일전 | ★ favorite | 댓글 1개
  • Debian의 APT 패키지 관리자에 2026년 5월 이후부터 Rust 기반 코드와 종속성이 포함될 예정
  • 초기 단계에서는 Rust 컴파일러, 표준 라이브러리, 그리고 Sequoia 생태계가 통합 대상
  • .deb, .ar, .tar 파일 파서와 HTTP 서명 검증 코드가 메모리 안전성과 단위 테스트 강화 측면에서 주요 개선 영역
  • Rust 툴체인이 없는 포트는 6개월 내 Rust 환경 구축 또는 지원 종료(sunset) 필요
  • 프로젝트 전체가 현대적 도구와 기술로 전환하기 위한 조치로, 구형 하드웨어 호환성에 발목 잡히지 않기 위한 방향

APT에 Rust 코드 도입 계획

  • APT에 Rust 코드와 하드 종속성(hard dependency) 을 2026년 5월 이후 도입 예정
    • 도입 시점은 2026년 5월 이후로, 그 이전에는 적용되지 않음
  • 초기 통합 범위는 Rust 컴파일러, 표준 라이브러리, Sequoia 생태계로 한정됨

코드 품질 및 안전성 향상 목적

  • .deb, .ar, .tar 파일 파싱 코드와 HTTP 서명 검증 코드가 Rust 도입의 주요 대상
    • 이 영역은 메모리 안전 언어와 강화된 단위 테스트 체계의 이점을 크게 받을 것으로 명시됨

포트 유지보수자에 대한 요구사항

  • Rust 툴체인이 없는 포트는 6개월 내 Rust 환경을 구축해야 함
    • 그렇지 않을 경우 해당 포트는 중단(sunset) 될 수 있음

프로젝트 방향성

  • Debian 프로젝트가 현대적 도구와 기술을 활용해 발전해야 함을 강조
    • 구형 하드웨어나 레트로 컴퓨팅 장치에 맞추려는 시도로 인해 발전이 지연되어서는 안 된다고 명시됨

기타 정보

  • 발신자는 Debian 및 Ubuntu 코어 개발자 Julian Andres Klode
  • 메일은 Debian 개발자 메일링 리스트 debian-devel에 게시됨
  • 첨부 파일로 PGP 서명(signature.asc) 포함
  • 추가적인 기술 세부사항이나 일정 변경에 대한 언급은 없음
▲
GN⁺ 2일전  [-]
Hacker News 의견

  • 이제야 시기가 온 것 같음. 신뢰할 수 없는 데이터 파싱 코드를 여전히 C로 유지하는 건 시간이 지날수록 커지는 기술 부채임
    Rust는 C보다 작성이 훨씬 어렵지도 않고, 언어 설계와 코드 안전성에 대한 지금의 지식을 반영해 C를 다시 만든다면 나올 법한 언어임
    32비트 x86 지원을 실용적 이유로 버릴 수 있다면, 이런 아키텍처들도 마찬가지임. 정말 유지하고 싶다면 Rust 툴체인 백엔드를 직접 만들어야 함

    • 현재 기본 시스템에서 핵심 애플리케이션에 허용된 언어는 C, C++, Shell(bash), Perl, Python 정도임. Python이 추가된 게 약 20년 전이고, Rust는 C의 역할을 대체할 만큼 충분히 근접한 첫 언어임
      Go가 그나마 비슷했지만 systemd 같은 핵심 시스템에 쓰일 정도로 논의된 적은 없음. 과거 C++, Python, Perl이 추가될 때도 이런 논쟁이 있었을지 궁금함
    • “.deb, .ar, .tar 파서와 HTTP 서명 검증 코드가 메모리 안전 언어로 이득을 볼 것”이라지만, 지난 30년간 안정화된 코드들을 굳이 새 언어로 다시 쓰는 게 어떤 실질적 이익을 줄지 의문임
      이미 전투 검증된 코드를 버리고 새 호환성 문제와 버그를 만드는 게 과연 가치가 있을까 생각함
    • 오래된 C 코드의 보안 문제를 해결하는 더 실용적인 접근으로 Fil-C 프로젝트가 있음. C를 사실상 관리형 언어처럼 만들어 재작성 필요성을 줄이는 방식임
    • 이건 단순히 메모리 안전성의 문제가 아님. C 커뮤니티의 고령화로 유지보수 인력을 구하기 어려움. 우리 팀도 C/C++ 코드를 전부 다른 언어로 옮기고 있음. 대부분의 C/C++ 개발자는 40대쯤이고 이직 의향이 낮음
    • Rust가 C를 현대적으로 재창조한 언어라는 주장에는 동의하기 어려움. 예를 들어 COSMIC 데스크탑의 시계 위젯 코드는 비슷한 복잡도의 C 코드(GNU coreutils 등)보다 훨씬 읽기 어려움

  • Rust로 코어 시스템을 다시 쓰는 흐름이 강하지만, 오래된 도구를 재작성한다고 해서 보안이 실제로 나아지는지는 의문임
    새로운 시스템을 도입하기 어렵다는 건 이해하지만, 여전히 전신 시대의 설계 결정 위에 층층이 쌓인 구조를 유지하는 느낌임

    • 이런 재작성의 이유로 두 가지를 들을 수 있음.
      첫째, 오래된 C/C++ 코드베이스를 다루고 싶어 하는 신규 기여자가 거의 없음. Rust로 옮기면 새 개발자 유입이 쉬워짐
      둘째, 신뢰성은 사용 빈도로 검증되지만 보안성은 공격으로만 검증됨. 오래된 코드가 모든 공격 벡터를 거쳤다고 보긴 어려움. 따라서 선제적 보안 강화의 명분이 큼
    • uutils/coreutils는 MIT 라이선스, GNU coreutils는 GPL이라 라이선스 차이가 있음. 기업 입장에서는 이게 중요한 포인트일 수 있음
    • 누군가는 배워야 하므로, 단순하고 테스트하기 쉬운 프로젝트를 연습용으로 재작성하는 건 괜찮다고 생각함. 다만 그 결과물이 원본을 대체할지는 별개의 논의임

  • Debian 메일 스레드에 따르면, Rust는 이미 대부분의 Debian 릴리스 아키텍처에서 필수임
    관련 메일에서 alpha, hppa, m68k, sh4만 예외로 언급됨. 이 아키텍처들의 향후 운명이 궁금함

    • 이런 오래된 머신을 아직 쓰는 사람이 있는지 진심으로 궁금함. 대부분 20년 이상 된 하드웨어임.
      Rust는 m68k용 Tier 3 타깃을 제공하지만, 다른 아키텍처는 없음. 실제 사용 사례가 궁금함
    • Debian Supported Architectures에 따르면 이 플랫폼들은 비공식 상태임.
      32비트 x86과 MIPS가 빠진 반면 이들이 남아 있는 건 의외임. 개인적으로는 향수도 있지만, 실제 사용처는 잘 모르겠음
    • m68k에는 이미 LLVM 포트가 있어서 Rust 구현이 가능함. alpha, hppa, sh4용 LLVM 백엔드도 교육용 참고 자료로 가치가 있음
      과거 LLVM에는 DEC Alpha 백엔드가 있었지만 오래전 일임
    • Ubuntu 입장에서는 이런 아키텍처들은 상업적 가치가 없음
    • 완전히 구식이라 그냥 마지막 지원 버전에서 멈추거나, 자체 배포판을 만들면 됨. Rust 지원을 추가하는 건 비현실적임

  • Rust 커뮤니티가 기존 프로젝트에 끼어드는 대신, 새로운 현대적 기술을 직접 만들어 증명했으면 함
    Redox 같은 독립 프로젝트가 그런 예시인데, 왜 이런 시도를 더 밀지 않는지 아쉬움

    • 이건 Debian이 Rust 의존성을 추가한 공식 결정임. 외부 Rust 팬들이 강요한 게 아님
      물론 “Rust로 다시 써라”는 과격한 팬들도 있지만, 이번 건은 그와 다름
    • ripgrep이 바로 그런 예시임. 새로 만들었고, 사람들이 실제로 좋아함

  • Rust 표준 라이브러리를 쓰는 건 괜찮지만, 단순한 deb 파서 빌드에 cargo 패키지 500개를 끌어오는 건 원치 않음

  • Rust-for-GCC 포트가 안정화될 때까지 기다리는 게 합리적일 수도 있음
    커널도 GCC 지원이 되기 전까지는 Rust를 필수로 하지 않을 예정임.
    여러 구현이 생기면 언어가 덜 불안정해질 것임
    다만 지금 아키텍처 지원을 끊으면, 나중에 Rust 툴체인이 생겼을 때 복귀 절차가 복잡해질 수 있음

    • 사실 이런 아키텍처들은 이미 10년 넘게 Debian에서 제외된 상태임. 이번 변화로 새로 빠지는 건 아님
    • 공식 지원이 없고, 개인이 여가 시간에 유지하는 수준임. 기업이 장기 유지보수를 맡지 않는 한 복귀는 어려움
    • GCCRS는 아직 libcore조차 빌드 못 하고, Rust 1.50 수준임. 일반용 컴파일러로는 수년은 걸릴 것 같음
      오히려 rustc_codegen_gcc가 먼저 안정화될 가능성이 큼
    • 포트들은 Debian 정식 릴리스에 포함되지 않고, unstable 채널로만 배포됨

  • Debian Rust 논의 메일의 작성자가 keepassxc 패키지 유지보수자라는 점을 상기함
    과거에도 upstream 개발자와 사용자에게 거친 언행을 보였다는 스레드가 있음

    • 나도 그 메일을 보고 바로 확인했는데, 예전 스레드가 떠올라 웃었음
    • 솔직히 그가 쓴 표현은 거칠지만 직설적일 뿐 모욕적이지는 않음. 괜한 드라마로 보임
    • HN 게시물 자체는 공격적이지 않은데, 일부가 과하게 받아들이는 듯함
    • 이런 문화가 자유 소프트웨어 세계에 만연함. 실제 사용자보다 이상적 사용자상을 좇는 경향이 GNOME 3, Mozilla 시절부터 이어져 왔다고 봄

  • 한 사람의 의견이 변하는 과정을 보는 게 흥미로움. 이전 발언 링크

    • 시간이 지나며 생각을 바꾸는 태도는 보기 좋음
    • APT의 Rust 도입도 coreutils 전환처럼 관리적 결정일 가능성이 큼

  • Rust는 단순한 유행(hype) 이라고 생각함. 임베디드 세계에서는 여전히 C가 왕임.
    실제로 Rust를 쓰거나 고려하는 사람을 주변에서 본 적이 없음

    • “내 주변엔 없다”로 결론내리긴 무리임. Rust를 쓰는 임베디드 개발자도 많음
    • AWS 내부에서는 EC2, IAM, DynamoDB, S3 등 핵심 서비스가 Rust로 작성됨.
      성능과 메모리 효율을 유지하면서 개발 속도가 빠름.
      유일한 단점은 바이너리 크기임. Rust의 미래는 이미 확고하다고 봄
    • Rust는 임베디드에서도 강력하지만, 제조사 지원이 부족해 하드웨어별 초기 작업량이 많음.
      그래도 메모리 안전성만이 아니라 언어와 툴체인 전체 품질이 매력임
    • avr-rust, esp-rs, cortex-m 등으로 임베디드 생태계도 서서히 변화 중임
    • Microsoft, Google 등에서도 Rust를 논의하고 실제 제품에 적용 중임

  • 다언어(polyglot) 환경은 문제를 더 만든다고 생각함.
    Python, Node, Go, Rust 등 각기 다른 툴체인과 패키지 관리자가 필요해 복잡함
    Node로 버퍼 오버플로를 없앴더니 공급망 공격이 늘었음.
    차라리 새로 시작하는 게 낫고, Rust를 전면적으로 쓰고 싶다면 Redox OS에 기여하는 게 맞음

    • 현실적으로 각 언어는 고유한 장단점이 있고, Debian은 실용적 OS로서 다양한 언어를 지원해야 함
      모든 걸 한 언어로 다시 쓰는 건 비현실적이며, Redox를 밀어주는 것도 오히려 비효율적일 수 있음
      Rust는 이미 충분히 검증된 언어이고, C보다 수정 시 자폭 확률이 낮은 컴파일 언어로서 가치가 있음
      오래된 아키텍처를 버리는 것도 무리는 아님
    • Debian처럼 큰 프로젝트는 선택지를 넓히는 게 합리적임. Rust를 추가하는 건 충분히 이해 가능한 결정임
      어떤 언어를 뺄지, 넣을지는 Debian 유지보수자들이 판단할 일임
    • Linux는 이미 수십 년 전 복잡성과의 싸움을 포기했음
답변달기