▲

우분투가 Rust를 사용한다는 것은 무엇을 의미할까?

 (smallcultfollowing.com)
2P by GN⁺ 2일전 | ★ favorite | 댓글 1개
  • 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가 사람들을 도울 수 있는 곳을 찾아가서 지원하고 역량을 부여하는 것이 핵심
▲
GN⁺ 2일전  [-]
Hacker News 의견들

  • 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을 보면 명확함

    • “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 포럼에 있음

    • 링크된 스레드는 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 문서(링크)를 보면 커뮤니티가 중점적으로 투자하는 방향을 알 수 있음
    • 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 같은 큐레이션된 리스트를 참고함
    • 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는 신중해야 함
답변달기