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

> Clean Markdown view of GeekNews topic #24085. Use the original source for factual precision when an external source URL is present.

## Metadata

- GeekNews HTML: [https://news.hada.io/topic?id=24085](https://news.hada.io/topic?id=24085)
- GeekNews Markdown: [https://news.hada.io/topic/24085.md](https://news.hada.io/topic/24085.md)
- Type: GN+
- Author: [neo](https://news.hada.io/@neo)
- Published: 2025-11-02T09:47:03+09:00
- Updated: 2025-11-02T09:47:03+09:00
- Original source: [lists.debian.org](https://lists.debian.org/debian-devel/2025/10/msg00285.html)
- Points: 3
- Comments: 1

## Topic Body

- 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)** 포함  
- 추가적인 기술 세부사항이나 일정 변경에 대한 언급은 없음

## Comments



### Comment 45774

- Author: neo
- Created: 2025-11-02T09:47:03+09:00
- Points: 1

###### [Hacker News 의견](https://news.ycombinator.com/item?id=45779860) 
- 이제야 시기가 온 것 같음. **신뢰할 수 없는 데이터 파싱 코드**를 여전히 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 프로젝트](https://fil-c.org/)가 있음. C를 사실상 **관리형 언어**처럼 만들어 재작성 필요성을 줄이는 방식임
  - 이건 단순히 메모리 안전성의 문제가 아님. **C 커뮤니티의 고령화**로 유지보수 인력을 구하기 어려움. 우리 팀도 C/C++ 코드를 전부 다른 언어로 옮기고 있음. 대부분의 C/C++ 개발자는 40대쯤이고 이직 의향이 낮음
  - Rust가 C를 현대적으로 재창조한 언어라는 주장에는 동의하기 어려움. 예를 들어 [COSMIC 데스크탑의 시계 위젯 코드](https://github.com/pop-os/cosmic-applets)는 비슷한 복잡도의 C 코드(GNU coreutils 등)보다 훨씬 **읽기 어려움**

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

- Debian 메일 스레드에 따르면, Rust는 이미 대부분의 Debian 릴리스 아키텍처에서 필수임  
  [관련 메일](https://lists.debian.org/debian-devel/2025/10/msg00288.html)에서 alpha, hppa, m68k, sh4만 예외로 언급됨. 이 아키텍처들의 향후 운명이 궁금함
  - 이런 오래된 머신을 아직 쓰는 사람이 있는지 진심으로 궁금함. 대부분 20년 이상 된 하드웨어임.  
    Rust는 m68k용 [Tier 3 타깃](https://doc.rust-lang.org/nightly/rustc/platform-support/m68k-unknown-linux-gnu.html)을 제공하지만, 다른 아키텍처는 없음. 실제 사용 사례가 궁금함
  - [Debian Supported Architectures](https://wiki.debian.org/SupportedArchitectures)에 따르면 이 플랫폼들은 비공식 상태임.  
    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 패키지 유지보수자](https://github.com/keepassxreboot/keepassxc/issues/10725)라는 점을 상기함  
  과거에도 upstream 개발자와 사용자에게 거친 언행을 보였다는 스레드가 있음
  - 나도 그 메일을 보고 바로 확인했는데, 예전 스레드가 떠올라 웃었음
  - 솔직히 그가 쓴 표현은 거칠지만 **직설적일 뿐 모욕적이지는 않음**. 괜한 드라마로 보임
  - HN 게시물 자체는 공격적이지 않은데, 일부가 과하게 받아들이는 듯함
  - 이런 문화가 자유 소프트웨어 세계에 만연함. **실제 사용자보다 이상적 사용자상**을 좇는 경향이 GNOME 3, Mozilla 시절부터 이어져 왔다고 봄

- 한 사람의 의견이 변하는 과정을 보는 게 흥미로움. [이전 발언 링크](https://news.ycombinator.com/item?id=27594688)
  - 시간이 지나며 생각을 바꾸는 태도는 보기 좋음
  - APT의 Rust 도입도 coreutils 전환처럼 **관리적 결정**일 가능성이 큼

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

- **다언어(polyglot)** 환경은 문제를 더 만든다고 생각함.  
  Python, Node, Go, Rust 등 각기 다른 툴체인과 패키지 관리자가 필요해 복잡함  
  Node로 버퍼 오버플로를 없앴더니 **공급망 공격**이 늘었음.  
  차라리 새로 시작하는 게 낫고, Rust를 전면적으로 쓰고 싶다면 **Redox OS**에 기여하는 게 맞음
  - 현실적으로 각 언어는 고유한 장단점이 있고, Debian은 **실용적 OS**로서 다양한 언어를 지원해야 함  
    모든 걸 한 언어로 다시 쓰는 건 비현실적이며, Redox를 밀어주는 것도 오히려 비효율적일 수 있음  
    Rust는 이미 충분히 검증된 언어이고, C보다 **수정 시 자폭 확률이 낮은 컴파일 언어**로서 가치가 있음  
    오래된 아키텍처를 버리는 것도 무리는 아님
  - Debian처럼 큰 프로젝트는 선택지를 넓히는 게 합리적임. Rust를 추가하는 건 충분히 **이해 가능한 결정**임  
    어떤 언어를 뺄지, 넣을지는 Debian 유지보수자들이 판단할 일임
  - Linux는 이미 수십 년 전 **복잡성과의 싸움을 포기**했음