Debian의 핵심 도구 APT가 Rust 의존성을 도입하려는 계획을 둘러싸고, 비공식 포트와 보안, 정적 링크, ABI 안정성, Rust 생태계와 배포판의 역할 등에 대한 논쟁이 이어지고 있다.
By Joe Brockmeier
2025년 11월 24일
프로젝트나 패키지가 새 의존성을 추가하는 일은 대개 뉴스거리가 되지 않는다. 하지만 Debian의 Advanced Package Tool (APT)처럼 핵심 도구의 변경은 파급 효과가 크다. 예를 들어, Julian Andres Klode가 APT가 2026년 5월부터 Rust를 필요로 하게 될 것이라고 선언하면서, Debian의 일부 비공식 포트들은 동작하는 Rust 툴체인을 갖추거나 오래된 버전의 APT에 의존해야 하는 상황이 되었다. 이는 특히, 단일 관리자 한 명이 광범위한 영향을 미치는 변경을 할 수 있는지에 대한 여러 질문을 프로젝트 내부에서 불러일으켰다.
10월 31일, Klode는 debian-devel 메일링 리스트에 2026년 5월부터 Rust 의존성과 코드를 APT에 도입할 계획이라고 알리는 공지를 보냈다:
처음에는 Rust 컴파일러와 표준 라이브러리, 그리고 Sequoia 생태계로 확장될 것입니다.
특히, .deb, .ar, .tar를 파싱하는 코드와 HTTP 서명 검증 코드는 메모리 안전 언어와 더 강력한 단위 테스트 접근 방식으로부터 큰 이득을 볼 수 있습니다.
동작하는 Rust 툴체인이 없는 포트를 유지 관리하고 있다면, 향후 6개월 안에 Rust 툴체인을 갖추거나 그 포트를 종료(sunset)해 주십시오.
Klode는 또한, 프로젝트 전체가 앞으로 나아가고 현대적인 기술에 의존할 수 있으려면, 그리고 "레트로 컴퓨팅 장치에 현대 소프트웨어를 억지로 끼워 넣으려" 하다가足을 잡히지 않으려면 이것이 필요하다고 덧붙였다. 일부 Debian 개발자들은 이 소식을 반겼다. Paul Tagliamonte는 이것이 비공식 Debian 포트에 영향을 줄 것이라는 점은 인정했지만, Rust 도입을 향한 추진을 "반가운 소식"이라고 불렀다.
한편, John Paul Adrian Glaubitz는 Klode의 표현 방식이 불쾌하며 접근법이 대립적이라고 불만을 제기했다. 그는 다른 메시지에서 Rust 채택 자체에는 반대하지 않는다고 설명했다. 실제로 그는 Debian의 많은 아키텍처에서 Rust를 활성화하는 작업을 했으며, Rust 툴체인 및 LLVM 업스트림의 아키텍처별 버그를 수정하는 데 도움을 주기도 했다. 그러나 공지의 문맥은 계획 변경의 여지가 거의 없다는 인상을 강하게 주었다. Klode가 메시지를 "이해해 주셔서 감사합니다(thank you for understanding)"라는 말로 끝맺으면서, 추가 논의를 사실상 닫아 버렸기 때문이다. Glaubitz는 이 메시지에서 드러난 Klode의 커뮤니케이션 스타일에 불편함을 표시한 여러 Debian 개발자 가운데 한 명이었다.
Klode는 짧게나마, Rust가 이미 Debian의 모든 릴리스 아키텍처와 포트(단 Alpha (alpha), Motorola 680x0 (m68k), PA-RISC (hppa), SuperH (sh4)를 제외하고)에 대해 이미 강제 요구 사항(hard requirement)이라고 지적했다. 이는 APT가 Sequoia-PGP 프로젝트의 sqv 도구를 사용해 OpenPGP 서명을 검증하기 때문이다. Rust 컴파일러가 없는 포트에서는 APT가 GNU Privacy Guard 서명 검증 도구인 gpgv로 폴백한다. 하지만 이제 APT가 Rust에 직접 의존하게 되면, Rust 컴파일러가 없는 포트에서는 APT 자체를 사용할 수 없게 된다. LWN은 최근 각 아키텍처의 Rust 지원 상태와 함께, Linux 아키텍처 지원 현황을 다룬 바 있다.
Klode가 언급한 포트는 어느 것도 현재 Debian이 공식적으로 지원하는 아키텍처에 포함되지 않으며, Debian 14("forky")에서의 공식 지원 대상도 아니다. sh4 포트는 한 번도 공식 지원된 적이 없고, 다른 포트들은 Debian 6.0 이후로 지원되지 않았다. Rust가 없는 포트에 대한 실제 영향도 처음 들었을 때만큼 극적이지는 않다. Glaubitz는 Antoni Boucher에게 "Julian이 설정한 최후통첩(ultimatum)은 사실상 존재하지 않는다"고 안심시키면서도, 그런 식으로 표현하면 "뉴스에서 더 많은 관심을 끈다"고 말했다. Boucher는 rust_codegen_gcc의 관리자로, 이는 Rust용 GCC 선행 컴파일( ahead-of-time) 코드 생성기다. Glaubitz에 따르면, Boucher와 다른 사람들이 해당 포트에서 Rust를 부트스트랩할 때까지, 포트들이 Rust 없는 버전의 APT를 사용하는 것을 막는 것은 아무것도 없다.
APT의 또 다른 주요 기여자인 David Kalnischkies는, 만약 목표가 버그 감소라면 Klode가 언급한 .deb, .ar, .tar 포맷을 파싱하는 코드를 아예 APT에서 제거하는 편이 더 낫겠다고 제안했다. 해당 코드는 apt-ftparchive와 apt-extracttemplates 두 도구에만 필요하며, 이 중 "심각한 수준의 사용(serious usage)"은 Klode의 고용주인 Canonical이 자사의 소프트웨어 협업 플랫폼 Launchpad에서 하는 사용뿐이라고 지적했다. 만약 이들을 APT 메인 코드베이스에서 분리해낸다면, 해당 도구들이 Rust로 작성되든 Python으로 작성되든 다른 언어로 작성되든 상관없게 되며, 어떤 포트에서든 직접적으로 필수적인 도구가 아니게 된다.
Kalnischkies는 Klode가 언급한 "강력한 단위 테스트 접근 방식"을 구현하는 데 Rust가 필수라는 주장에도 의문을 제기했다:
C++에서도 단위 테스트를 충분히 할 수 있습니다. 우리는 실제로 그렇게 하고 있죠. 핵심 문제는 그 테스트를 누가 작성하느냐입니다. 문서와 마찬가지로요.
예를 들어, 당신의 새로운 솔버에는 (기존 통합 테스트를 제외하면) 단위 테스트가 전혀 없습니다. 이것이 C++ 때문이라고 진지하게 주장할 수는 없겠죠? 만약 현재 우리가 사용하는 GoogleTest가 마음에 들지 않는다면, 제가 예전에 언급했듯이 doctest를 제안할 수도 있습니다. 비슷하거나 다른 스타일의 프레임워크들이 많이 있습니다.
Klode는 아직 이 코멘트들에 답하지 않았는데, 이는 APT에 Rust에 대한 하드 의존성을 도입하는 일이 자신의 작업 범위를 넘어서는 영향을 갖는다는 점에서 다소 아쉬운 부분이다. 그가 이러한 질문들에 대해 충분히 타당한 답을 갖고 있을 가능성도 크지만, 한편으로는 Klode가 단지 Rust로의 트렌드를 좇고 있는 듯한 인상을 줄 수도 있다. 그는 Ubuntu의 GNU Coreutils에서 Rust 기반 uutils로의 마이그레이션 작업에 참여하고 있으며, 이 작업의 이유 또한 현대화와 더 나은 보안에 초점이 맞춰져 있다. 하지만 Rust로 전환한다고 해서 자동으로 보안이 보장되는 것은 아니며, 고려해야 할 다른 요소들도 많다.
예를 들어, Adrian Bunk는 APT의 일부가 Rust로 작성될 경우 Debian의 여러 팀과 도구가 영향을 받게 된다는 점을 지적했다. Debian 13("trixie") 릴리스 노트에서는 Debian의 인프라가 현재 Go와 Rust처럼 "체계적으로 정적 링크를 사용하는" 패키지 타입을 재빌드하는 데 문제가 있으며, 따라서 "이러한 패키지들에 대한 보안 지원은 인프라가 유지 가능하게 처리할 수 있을 만큼 개선될 때까지 제한적일 것"이라고 언급한다. 제한적인 보안 지원이란 Rust 라이브러리에 대한 업데이트가 대개 두 달에 한 번 정도인 포인트 릴리스 때에만 제공된다는 뜻이다. 보안 팀은 sqv에 대해서는 완전 지원을 제공한다고 명시했지만, 여전히 해결되지 않은 문제가 남아 있다.
정적 링크 문제 때문에, 현재 40개가 넘는 Rust 크레이트에 의존하는 sqv의 의존 라이브러리들 가운데 하나라도 보안 이슈로 인해 재빌드가 필요해지면, 잠재적으로 sqv 역시 재빌드가 필요해진다. 또한 모든 의존성에 대한 CVE를 추적하고, 특정 Rust 크레이트의 보안 취약점이 해당 크레이트에 의존하는 Rust 프로그램의 업데이트를 요구하는지를 파악하는 데 어려움이 있다.
Debian의 Rust 툴체인 관리자 중 한 명인 Fabian Grünbichler는, Debian이 Rust 패키지를 다루면서 겪고 있는 여러 미해결 문제들을 나열했다. 그중 큰 문제는 정적 링크된 라이브러리를 선언하기 위한 일관된 Debian 정책이 필요하다는 점이다. 2022년 Guillem Jover는 Static-Built-Using(SBU)라는 Debian 패키지 제어 필드를 추가했는데, 이는 바이너리 패키지를 빌드하는 데 사용된 소스 패키지를 나열한다. 이 필드는 어떤 소스 패키지가 업데이트되었을 때, 해당 바이너리 패키지를 재빌드해야 하는지 여부를 알려주는 역할을 한다. 예를 들어, sqv는 Debian에 패키지된 40개 이상의 Rust 크레이트에 의존한다. SBU를 선언하지 않으면, 그 중 하나가 업데이트되었을 때 sqv도 업데이트가 필요한지 명확히 알기 어렵다. Debian은 2024년 4월부터 SBU에 대한 정책 요구 사항을 논의해 오고 있으나, 아직 완성되거나 채택되지는 않았다.
Grünbichler가 촉발한 논의에서, Debian의 Rust 관련 문제들 대부분이 해결되는 과정에 있다는 점은 분명해졌다. 하지만 Klode가 APT가 Rust에 의존하게 될 것이라고 선언하기 전에, 이 문제들을 조사했거나, 심지어 "이 의존성을 도입하기에 이 일정이 타당한가?"라고 물어보았다는 증거는 없다.
Debian의 슬로건(또는 그 중 하나)은 "범용 운영체제(the universal operating system)"다. 이는 이 프로젝트가 가능한 한 다양한 하드웨어(신형과 구형 모두) 위에서 동작하고, 데스크톱, 서버, IoT 기기 등에서 사용 가능하도록 하는 것을 목표로 함을 의미한다. "Why Debian" 페이지는 사용자와 개발자가 왜 Debian을 선택해야 하는지를 설명하는 여러 이유를 나열한다. 다양한 하드웨어 아키텍처 지원, 장기 지원, 민주적 거버넌스 구조 등은 Debian이 내세우는 장점 중 일부다. 또한 "Debian은 단일 회사에 의해 통제될 수 없다"고 명시한다. 그런데 특정 회사에 고용된 단일 개발자가, 논의나 토론 없이 그 회사에 유리해 보이는 변경을 밀어붙이면서, 여러 하드웨어 아키텍처에 영향을 주고, 다른 자원봉사자들에게 계획에 없던 작업을 하거나 인위적인 마감 시한을 맞추도록 요구하는 모습은, 프로젝트가 표방하는 여러 가치에 반하는 것처럼 보인다.
물론 Debian에는, 다른 개발자들이 필요하다고 느낄 경우 사용할 수 있는 견제와 균형 장치가 있다. 예를 들어 누군가 Debian의 기술 위원회에 문제를 제기하거나, 일반 결의(general resolution)를 발의해, 토론만으로는 설득할 수 없는 개발자의 결정을 뒤집을 수 있다. 실제로 최근에는, 위원회가 systemd 유지 관리자들에게 /var/lock 디렉터리를 제공하도록 요구하는 결정을 내리기도 했다. 이는 "영향을 받는 소프트웨어의 만족스러운 마이그레이션이 이루어지고, 정책이 이에 맞게 갱신될 때까지" 유지되어야 한다고 했다.
그러나 Debian이 때때로 매우 느리게, 심지어 빙하처럼 느리게 움직인다는 점도 공정하게 지적할 수 있을 것이다. APT는 2015년에 소스 정보 리스트를 위한 DEB822 포맷 지원을 추가했다. 그럼에도 APT가 이 포맷을 수년간 지원해 왔음에도, Klode가 Debian 12("bookworm") 릴리스를 앞두고, Debian이 새 포맷으로 이동하도록 추진했을 때(2021년), 그는 저항에 부딪혀 성공하지 못했다. 이제 APT 3.0으로의 전환과 함께 trixie에서 DEB822가 기본이 되었지만, APT는 향후 수년 동안 기존 포맷도 계속 지원할 것이다.
사실, Klode가 APT에서 무엇을 하든 간에, 더 많은 자유 소프트웨어가 Rust로(또는 Rust로 재작성되어) 만들어지고 있다. 그러한 소프트웨어를 Debian 패키지로 제공할 때, 이를 쉽게 지원할 수 있도록 하는 것은 모두에게 이득이다. 아마도 프로젝트는 Rust 지원을 개선하는 방향으로 더 빠르게 움직이도록 강하게 밀어붙일 개발자들을 필요로 할지도 모른다. 하지만 진정으로 필요한 것은 Debian 및 다른 곳에서 Rust를 지원하기 위한 작업, 예컨대 gccrs 같은 프로젝트에 더 많은 개발자가 손을 보태는 일이다. 단일 개발자가 임의로 다른 자원봉사자들이 부랴부랴 지원해야 할 의존성을 선언하는 것은 Debian의 커뮤니티 지향적인 성격과 잘 어울리지 않는 듯하다.
이하 내용은 본문에 달린 일부 댓글 토론을 요약/번역한 것이다.
2025년 11월 24일 16:42 UTC (월) atai (구독자, #10977) (링크) (5개의 응답)
Rust 컴포넌트를 C/C++ 구현으로 채워 넣을 수 있도록 APT를 포크해서, 이 포터블 APT가 Rust를 사용하는 APT와 기능/특징 면에서 동등하게 유지되게 할 수는 없을까요? 그러면 이런 포트들이 계속 갈 수 있을 텐데요.
2025년 11월 24일 16:53 UTC (월) epa (구독자, #39769) (링크) (2개의 응답)
Rust에서 C로 변환하는 컨버터는 어떤가요? 어딘가에 있을 거라고 막연히 기대하고 있었습니다. 빌림 검사기(borrow checker)나 Rust의 대부분의 컴파일 타임 검사는 돌리지 않겠지만, 예전에 완전한 Rust 컴파일러로 빌드가 되었던 코드라면 상관없겠죠. 그리고 항상 단일 스레드로만 실행되는 코드를 생성하도록 할 수도 있을 겁니다.
2025년 11월 24일 17:14 UTC (월) ojeda (구독자, #143370) (링크)
그런 목적이라면, 기존 Rust 컴파일러에 새 백엔드를 하나 작성할 수 있습니다. 그러면 빌림 검사기 및 다른 모든 컴파일 타임 검사가 그대로 적용되죠.
rustc_codegen_clr에는 그런 모드가 있고,rustc용 새 C 백엔드를 만들려는 시도도 있었습니다. 둘 다 "프로덕션 준비 완료" 상태는 아니지만, 꽤 괜찮은 접근법이며 실제로 많은 언어들이 그런 식으로 컴파일러를 설계합니다.
2025년 11월 25일 20:16 UTC (화) hsivonen (구독자, #91034) (링크)
Rust는 wasm을 타깃으로 할 수 있고, wasm2c가 있습니다. 이 조합은 RLBox가 실제로 존재하고, Firefox에서 clang이 만든 wasm을 사용하는 데 쓰일 정도로 충분히 잘 동작합니다.
다만, Rust 입력이 FFI로 노출하는 것과 동일한 인터페이스를 C 코드 더미가 노출하도록 만드는 데 어느 정도의 노력이 필요한지는 잘 모르겠습니다.
2025년 11월 24일 16:53 UTC (월) jmm (구독자, #34596) (링크)
Debian에는 apt에 대한 엄격한 의존성이 없습니다. 애초에 이 논의 전체가 지나치게 부풀려졌습니다.
Rust 툴체인이 없는 포트는 C++로 작성된 cupt를 사용할 수도 있습니다.
2025년 11월 24일 16:56 UTC (월) farnz (구독자, #17727) (링크)
언제나 그렇듯이, 문제는 "누가 포크를 해서 업스트림을 계속 따라갈 것이냐"입니다.
다른 경로로는 gccrs나 rust_codegen_gcc 같은 프로젝트에 기여해서, 이런 포트들에서도 Rust를 사용할 수 있게 만드는 방법이 있습니다. 이렇게 하면, 한 번 Rust 지원을 갖추고 나면 Debian에서 Rust를 필요로 하는 다른 패키지들도 해당 포트에서 빌드 가능해진다는 장점이 있습니다.
이후 댓글에서는 Debian에서 Rust 및 Go 기반 패키지의 정적 링크 문제, 공유 라이브러리 대 정적 링크, ABI(응용 바이너리 인터페이스) 안정성과 재빌드 비용, 컨테이너 환경과 전통적인 배포판의 역할 차이, Java 및 Swift, C++과 비교한 Rust ABI 논의, 배포판 인프라 비용과 재빌드 규모 등에 대한 광범위한 토론이 이어진다. 핵심 쟁점은 다음과 같다.
마지막으로, Debian이 공식 릴리스 아키텍처에서 제외한 포트들이 여전히 프로젝트 내 의사결정(예: APT의 Rust 의존성 도입)에 영향을 미치는 것이 적절한지, 아키텍처를 "드롭"한다는 것이 정책적으로 정확히 무엇을 의미하는지 묻는 질문도 제기된다.
