# 우분투가 Rust를 사용한다는 것은 무엇을 의미할까? > Clean Markdown view of GeekNews topic #27028. Use the original source for factual precision when an external source URL is present. ## Metadata - GeekNews HTML: [https://news.hada.io/topic?id=27028](https://news.hada.io/topic?id=27028) - GeekNews Markdown: [https://news.hada.io/topic/27028.md](https://news.hada.io/topic/27028.md) - Type: GN+ - Author: [xguru](https://news.hada.io/@xguru) - Published: 2026-02-26T23:27:40+09:00 - Updated: 2026-02-26T23:27:40+09:00 - Original source: [smallcultfollowing.com](https://smallcultfollowing.com/babysteps/blog/2026/02/23/ubuntu-rustnation/) - Points: 6 - Comments: 1 ## Summary 우분투의 **Rust 도입**은 언어 채택 주기에서 Rust가 얼리 어답터 단계를 넘어 **초기 다수(Early Majority)** 로 확장되고 있음을 보여줍니다. Canonical은 Rust를 새로운 기반 소프트웨어의 기본 언어로 채택하며, 기존 C/C++ 유틸리티를 메모리 안전한 Rust 버전으로 교체하는 ‘드롭인’ 전략을 통해 불연속성을 최소화하고 있습니다. 이러한 접근은 Rust가 ‘최첨단 기술’이 아닌 ‘업계 표준’으로 자리 잡는 전환점이자, 오픈소스 생태계가 공감과 협력을 통해 성장해야 할 방향을 시사합니다. ## Topic Body - Ubuntu의 **Rust 도입**은 기술 채택 주기에서 Rust가 **얼리 어답터에서 캐즘을 넘어 주류 단계로 이동**하고 있음을 보여줌 - Canonical은 Rust를 **새로운 기반 소프트웨어의 기본 언어**로 채택하여 C, C++, 일부 Python 사용을 대체하고 있으며, 메모리 안전 유틸리티 개발에 재정·명성 양면으로 투자 중 - 초기 다수(Early Majority) 사용자는 **"업계 표준"과 기존 워크플로와의 호환성**을 원하기 때문에, 드롭인 방식의 유틸리티 교체가 캐즘을 넘는 핵심 전략 - Rust의 **표준 라이브러리 확장 문제**가 다시 부상했으며, 2016년 거부된 "Rust Platform" 개념이 초기 다수에게는 오히려 적합할 수 있다는 재평가 - 채택 확대를 투자로 연결하는 구조와 오픈소스 커뮤니티의 **공감(empathy) 기반 포용력**이 Rust의 다음 단계 성장에 필수적임 --- ### Rust의 '캐즘 넘기'는 영역마다 다름 - Rust가 **Technology Adoption Life Cycle**에서 캐즘을 넘었는지는 영역에 따라 다름 - Amazon 내부에서는 대규모 **데이터 플레인**이나 리소스 인식 에이전트 구축에 Rust가 확고히 자리 잡았지만, 일반 개발에는 여전히 과하다는 인식 존재 - **Safety Critical Software** 영역에서는 성공 사례가 있지만 대부분의 업계는 "관망 모드"에 머무는 상태 ### "레퍼런스 고객"의 중요성 - 캐즘을 넘기 위한 핵심은 **레퍼런스 고객(reference customers)** 확보 - 초기 채택자는 "변화의 주체(change agent)"를 구매하지만, **초기 다수는 기존 운영의 생산성 향상**을 원하며 불연속성을 최소화하려 함 - 자신과 비슷한 조직이 성공한 사례를 보는 것이 새로운 기술 도입에 가장 설득력 있는 요인 - S3 팀의 Rust 성공이 대규모 서비스 팀에는 설득력이 있지만, **CRUD 서비스 팀에게는 직접적 설득력이 부족**한 것이 그 예시 ### Ubuntu(Canonical)의 Rust 도입 전략 - Rust Nation에서 Canonical VP of Engineering **Jon Seager**가 "Rust Adoption At Scale with Ubuntu" 키노트 발표 - Canonical은 자체 개발 언어를 Python, C/C++, Go로 한정해왔으나 최근 Rust를 추가하여 **새로운 기반 작업의 기본 언어**로 채택 - Lars Bergstrom의 Google 내 Rust 채택 키노트와 유사하게, **비전과 실용성을 동시에 갖춘** 접근 방식 - 이는 초기 채택자에서 초기 다수로 전환하는 데 필요한 정확한 특성 ### 메모리 안전 유틸리티에 대한 투자 - Jon Seager는 Ubuntu가 **메모리 안전 기반 유틸리티 구축을 "pay it forward"** 차원에서 지원해야 한다고 언급 - Canonical은 **Trifecta Tech Foundation**의 sudo-rs, ntpd-rs 개발과 **uutils**의 coreutils 작업을 재정 지원 중 - Ubuntu가 새로운 것을 먼저 시도하고 검증한 뒤 다른 배포판이 혜택을 받을 수 있도록 하는 구조 - 기존 워크플로에 그대로 들어가는 **드롭인 유틸리티**가 초기 다수의 "불연속성 최소화" 요구에 부합 ### 새로운 채택자의 요구: 표준 라이브러리 확장 - 만찬 자리에서 Jon Seager는 Rust의 **작은 표준 라이브러리 정책을 재검토**해야 한다고 발언 - 이는 수년간 반복되어 온 요구이며, 단순히 큰 표준 라이브러리를 제공하는 것이 아니라 **"Battery Packs"** 이라는 프로젝트 형태의 대안을 구상 중 - 2016년 제안된 **Rust Platform**(특정 crate를 확장 표준 라이브러리로 인정하는 개념)은 당시 초기 채택자들에게 거부되었으나, 초기 다수에게는 적합할 수 있다는 재평가 - 당시에는 `Cargo.toml`에 의존성을 추가하면 충분하다는 의견이 우세했음 ### 성장을 위한 변화의 필요성 - 초기 채택자에서 초기 다수로 전환하려면 **"최첨단(state-of-the-art)"이 아닌 "업계 표준(industry standard)"** 이라는 메시지가 필요 - Rust는 업계 인지도 확보에는 성공했으며, 이제 **"될 수 있는 것"이 아닌 "실제로 무엇인지"** 를 기준으로 최선의 선택이 되어야 함 - 이 두 가지가 때로 긴장 관계에 있을 수 있음 - 실용주의자에게 마케팅하려면 인내심, 해당 산업 이슈에 대한 이해, 업계 컨퍼런스 참석 등이 필요 ### 채택을 투자로 연결하는 구조 - Rust 채택 확대는 Rust 프로젝트와 생태계에 대한 **요구 증가**를 수반 - Canonical 같은 오픈소스 조직에는 $$보다 **조직 간 관계 구축과 기여**가 더 중요 - Rust for Linux 개발자들이 초기에는 Rust 메인테이너의 도움을 받았지만, 점차 **직접 버그를 수정**하고 메인테이너는 멘토 역할로 전환 - 흥미로운 추세로, 자금은 Rust를 **이미 도입한 기업보다 도입을 검토 중인 기업**에서 나오는 경우가 많음 - 내부의 초기 채택자 개인이 조직 도입을 추진하며 **"테이블 스테이크" 기능** 개발에 예산을 배정 - Rust Foundation Silver Member Directory의 Alexandru Radovici에 따르면, 다수의 **안전 필수 소프트웨어 기업**이 Rust의 갭을 메우기 위한 자금은 있지만 사용 방법을 모르는 상황 ### 오픈소스의 역할과 공감의 중요성 - 오픈소스는 캐즘을 넘기 위한 훌륭한 플랫폼이지만, **파벌(cliques)과 "구전 전통(oral traditions)"** 이 진입 장벽이 될 수 있음 - 잘못된 용어 사용으로 아이디어가 거부되거나, 무례한 응답 하나가 새로운 기여자를 떠나게 만들 수 있음 - Rust의 다음 성장 단계에 가장 필요한 것은 **오픈소스에서의 공감(Empathy in Open Source)** - Rust가 사람들을 도울 수 있는 곳을 찾아가서 **지원하고 역량을 부여하는 것**이 핵심 ## Comments ### Comment 51968 - Author: neo - Created: 2026-02-26T23:27:40+09:00 - Points: 1 ###### [Hacker News 의견들](https://news.ycombinator.com/item?id=47125286) - Ubuntu가 **GPL이 아닌 라이선스의 userland**를 사용한다는 건, 리눅스 생태계에서 더 많은 **TiVoization**을 허용할 수 있다는 의미임 systemd 진영의 Amutable이 만드는 방향과 결합되면, 사용자 수정이 불가능한 **폐쇄형 리눅스 배포판**이 등장할 수도 있음 기업 입장에서는 완전한 서명 검증이 가능한 폐쇄형 환경이 매력적일 수 있음. “ls”나 “cd”조차 닫힌 소스가 되는 세상이라니, 묘하게 묵시록적인 느낌임 - util-linux나 BSD가 사라지는 건 아님. Ubuntu가 마음에 안 들면 안 쓰면 됨. Debian이 훨씬 안정적이었음 - 사실 GNU/Linux라 불렸던 이유가 있음. Android/Linux도 GPL userland가 아니고, 임베디드 경쟁자들도 대부분 GPL이 아님. 결국 **Linux는 커널일 뿐**임 - 역사적으로 보면 내가 순진한 걸 수도 있지만, 이런 변화가 꼭 나쁘다고 생각하진 않음. 오픈소스 유틸을 선호하긴 하지만, **명세를 지키는 폐쇄형 대안**이 존재해도 괜찮다고 봄. 기업이 그렇게 해서 오픈소스 프로젝트에 더 많은 자금을 투입할 수도 있음 - 솔직히 Ubuntu는 품질보다 마케팅으로 승부하는 **리눅스의 Apple** 같음. Debian 계열은 유지보수 비용이 낮아서 쓰는 거고, 개인적으로는 Fedora나 OpenSUSE가 미래라고 생각함 - 만약 이런 변화로 리눅스 사용자 95%가 같은 OS를 쓰게 된다면, 그리 나쁜 일은 아닐 수도 있음 - Rust가 넘어야 할 **진짜 간극(chasm)** 은 안전한 ABI를 가진 **동적 링크 지원**임 한 라이브러리를 수정해도 안전성이 보장되고, C 수준의 ABI 안정성을 확보해야 C/C++ 진영에서 Rust 채택이 가능해짐 - Rust는 이미 C ABI로 통신 가능함. C++과 동일한 수준의 **동적 링크** 기능을 제공함 - C++의 ABI 안정성은 언어 발전을 막는 주범임. STL의 클래스 레이아웃을 바꿀 수 없고, 헤더에 구현된 템플릿은 나중에 최적화도 어려움. Rust는 이런 **“stable ABI”를 지원하지 않아야 함** - Rust의 효율성은 **컴파일 시점 모노모픽화**에 의존함. ABI를 만들려면 링크 타임 특수화를 고려해야 함. 단순히 링커로 코드 생성을 옮기는 수준이 아니라, 함수 파라미터의 “형태(shape)”를 신중히 다뤄야 함 - 동적 링크는 디버그 빌드에서 **컴파일 시간 단축**에도 유리함. 변경되지 않은 라이브러리는 다시 빌드할 필요가 없고, 런타임 오버헤드도 미미함 - Rust 커뮤니티가 GPL보다 MIT을 선호하는 건 아쉬움. **GPL은 사용자 친화적**, MIT은 기업 친화적임. “Rewrite-it-in-Rust” 운동이 사용자 보호보다 언어 확산에만 집중하는 게 문제라고 생각함 - Ubuntu가 Rust를 도입하는 것보다 더 큰 문제는, 여전히 **curl|bash 스크립트**로 중요한 빌드를 처리한다는 점임 [firefox-snap의 snapcraft.yaml](https://github.com/canonical/firefox-snap/blob/90fa83e60ffef6c72c28288cda381de25d518f5b/snapcraft.yaml#L149-L159)을 보면 명확함 - “curl|bash”라 하면 보통 무작위 설정 변경이나 .bashrc 수정이 떠오르지만, 이번엔 단순히 **정적 툴체인 설치 스크립트**를 실행하는 수준임. 90년대식 방식이지만 상대적으로 안전함 - Rust 버전이 너무 오래된 배포판이 많음. Debian이나 Ubuntu LTS의 Rust는 **시대에 뒤떨어진 버전**이라 정적 링크를 싫어하는 듯함 - curl로 뭔가를 실행하더라도 **해시 검증**만 잘 하면 괜찮음 - Rust Coreutils 프로젝트가 **MIT 라이선스**라는 점이 마음에 걸림 FSF의 철학이 비판받을 때도 있지만, **GPL은 오픈소스를 보호**함. Canonical이 Ubuntu 전반을 MIT으로 바꾸면 어떤 일이 생길지 모르겠음 - GPL은 예전엔 강력했지만, 이제는 **자동 저작권 세탁 시스템** 덕분에 MIT/BSD나 상용 코드로 변환되는 경우가 많음. FSF도 해결책이 없음 - 라이선스 논의는 끝이 없음. GPL은 채택을 제한하지만, MIT은 더 유연함. 결국 **목표가 무엇이냐**에 따라 다름 — 모두가 쓸 수 있는 OSS를 원하느냐, 아니면 기업이 기여 없이 이익을 얻지 못하게 막느냐 - Coreutils가 MIT이 되었다고 해서 구체적으로 어떤 “악행”이 가능해지는지 궁금함 - rust-coreutils 때문에 **CUDA Toolkit 설치가 불가능**했음. 관련 이슈는 [NVIDIA 포럼](https://forums.developer.nvidia.com/t/cuda-runfile-wont-extract/351343)에 있음 - 링크된 스레드는 gzip 관련 문제였던 것 같음. dd 때문은 아닌 듯함 - 솔직히 rust-coreutils는 존재 이유가 없음. Ubuntu 설치 후 제일 먼저 할 일은 **진짜 coreutils와 sudo를 다시 설치**하는 것임 - “Crossing the chasm”이라는 개념이 흥미로움. Ubuntu의 coreutils 사례 외에도 Rust가 넘으려는 간극이 많음 Rust for Linux나 자동차 산업용 Rust도 있지만, 아직은 드라이버 수준에 머무는 듯함 - Rust는 여러 방향으로 확장 중임. pyo3(파이썬 모듈 대체), Dioxus(React 유사 웹 프레임워크), Ferrocine(자동차용 컴파일러) 등이 대표적임. **DARPA TRACTOR** 프로젝트도 Rust 채택을 가속화함 - Rust의 **Project Goals** 문서([링크](https://rust-lang.github.io/rust-project-goals/))를 보면 커뮤니티가 중점적으로 투자하는 방향을 알 수 있음 - Rust 자체는 훌륭하지만, 일부 커뮤니티가 기존 안정된 소프트웨어를 “Rust로 다시 쓰기”만 하며 **브랜드를 낚아채는 행태**가 문제임. Ubuntu도 그런 **미덕 과시(virtue signaling)** 에 빠진 듯함 - 표준 라이브러리를 나중에 바꾸겠다는 논리는 위험함. 사용자는 “간극”보다 **안정적이고 품질 높은 시스템**을 원함 - Rust의 경우 stdlib을 “바꾸는” 게 아니라 **추가하는 건 쉬움**. 6주마다 새 릴리스가 나오고, 매번 10개 이상 기능이 추가됨. 이미 수백 개의 기능이 stdlib에 들어감 - Rust 생태계의 **미성숙함**이 채택을 막는 요인임. 많은 crate가 1.0 이전 버전이거나 단순한 C 래퍼 수준임. 암호화 관련은 괜찮지만, SAML 같은 건 찾기 어려움 - pre-1.0 버전은 너무 걱정 안 해도 됨. **SemVer를 엄격히 지키는 문화** 때문에 1.0 선언을 미루는 경우가 많음. `libc`처럼 API에 깊이 얽힌 crate는 버전 올리기 어렵기도 함. 개인적으로는 [blessed.rs](https://blessed.rs) 같은 **큐레이션된 리스트**를 참고함 - gettext도 30년 만에 1.0이 됐음 - Python의 cryptography 모듈이 Rust toolchain을 요구해서 **Termux 환경에서 설치가 불가능**했음. Rust 의존성 때문에 Python 프로젝트조차 무거워지는 건 불편함 - Rust로 C++ 코드를 “느낌만 번역(vibe-translate)”해서 **라이선스 변경**하는 움직임이 있음. 예를 들어 sudo-rs는 오히려 **C 버전보다 안전성 기록이 나쁨** - Rust와 AI, 안전성이라는 **선전(propaganda)** 가 너무 과함. 처음엔 Rust를 사랑했지만, MIT 라이선스 논란과 과도한 홍보가 점점 피로하게 느껴짐 - .NET의 **거대한 표준 라이브러리**는 정말 쾌적함. 대부분의 작업이 표준 방식으로 가능하고, 이상한 구현이 있으면 다수가 표준화를 추진함 - Rust의 **작은 stdlib**은 실수라고 생각함. stdlib은 언제나 존재하는 유일한 의존성이므로, 완벽하진 않아도 더 많은 도구가 포함돼야 함 - 하지만 시스템 프로그래머 입장에서는 큰 stdlib이 오히려 문제임. .NET은 GC 기반이라 상관없지만, Rust나 C++은 **베어메탈 환경**에서도 돌아야 함. 큰 stdlib은 메모리 제약(<64K) 환경에서 부담이 큼 Rust의 std/core는 이미 너무 커서 마이크로컨트롤러에서는 **약한 심볼(weak symbol)** 같은 트릭이 필요함. 작은 stdlib은 **API 안정성 유지와 유지보수 부담 완화**에 유리함. C++이 이 문제로 고생했기 때문에 Rust는 신중해야 함