2025년 Rust: 기초 소프트웨어를 목표로

(smallcultfollowing.com)

21P by GN⁺ 3일전 | ★ favorite | 댓글 13개

Rust는 올해 10주년을 맞이하며, 향후 기초(Foundational) 소프트웨어 개발의 핵심 언어로 자리매김하고 있음
기초 소프트웨어는 운영체제 커널, 클라우드 플랫폼, 임베디드 장치, CLI 도구 등 모든 것의 기반이 되는 계층을 의미
Rust는 C/C++ 수준의 성능과 신뢰성을 제공하면서도 메모리 안전성을 보장하는 타입 시스템으로 장벽을 낮췄음
Rust의 사명은 단순히 기반 영역에 국한되지 않고, Dioxus, Tauri, Leptos와 같은 프로젝트를 통해 상위 애플리케이션 개발에도 파급 효과를 주고 있음
향후 언어 상호 운용성, 타입 시스템 확장, 생태계 강화 등을 핵심 투자 영역으로 계획하고 있음

Rust의 비전: 기초 소프트웨어

Rust의 핵심 비전은 기초 소프트웨어를 보다 쉽게 작성·유지할 수 있게 하는 것임
- 기초 소프트웨어란 모든 시스템의 기반이 되는 운영체제 커널, 클라우드 인프라, 임베디드 장치, CLI 도구 등을 포함
- 이미 Windows와 Linux 커널, VSCode 검색 엔진 ripgrep, Deno, Python uv 패키지 매니저 등 다양한 곳에서 채택되고 있음
이러한 소프트웨어는 성능·신뢰성·생산성이 동시에 중요함
- 기반이 무너지면 상위 계층 전체가 영향을 받기 때문에 안정성이 필수
- 성능 저하는 상위 계층의 성능 한계로 이어지므로 최소한의 오버헤드 필요

기초 소프트웨어의 성능, 신뢰성, 생산성

기초 소프트웨어는 모든 소프트웨어와 마찬가지로 다양한 요구가 있으나, 모든 요소가 더욱 중요함
- 신뢰성은 최우선 과제임. 기초가 무너지면 그 위에 있는 모든 것이 실패하는 구조임
- 성능 오버헤드는 상위 계층 성능의 한계를 결정하므로 최소화해야 함
기존에는 이러한 요구사항을 충족하는 데 두 가지 선택지가 있었음
- C/C++ : 큰 자유를 제공하지만 이에 상응하는 완벽성이 요구됨
- Java, Go 등 고수준 언어: 성능 유지를 위한 특별한 코딩 방식 필요, 추상화와 편의성 사용에 제약을 받음
Rust는 제로-코스트 추상화와 메모리 안전성을 보장하는 타입 시스템의 결합으로 기존 방식을 바꿈
고수준 코드를 안전하게 작성하면서 저수준 성능과 메모리 안정성을 동시에 달성하는 도구가 됨

진입장벽 낮추기와 개발자 역량 강화

Rust 발표에서 타입 시스템과 정적 검사를 "시금치" (좋지만 먹기 싫은 것)로 비유하는 경우가 많음
현실적으로 타입 시스템은 개발자에게 강력한 무기임
초보자는 타입 시스템을 배우며 성공적인 소프트웨어 구조 학습이 가능함
전문가는 자체 구조 설계에서 실수를 더 빨리 발견할 수 있음

Yehuda Katz의 "집중 상태에서 만드는 추상화가 피로한 나의 미래를 돕는다"는 발언도 이를 잘 요약함

비기초 소프트웨어 영역

Rust의 미션이 기초 소프트웨어에 초점이 맞춰졌다 해도 그 외 영역이 무시되는 것은 아님
Dioxus, Tauri, Leptos 등 프로젝트는 Rust를 활용해 GUI, 웹페이지 같은 고수준 애플리케이션 영역으로도 확장하고 있음
Rust의 주요 강점은 본질적으로 기초 소프트웨어에 집중되어 있지만, 이러한 시도들은 무시해서는 안됨

스트레칭 목표와 성장

기초 소프트웨어는 저수준 세부 제어를 필요로 하므로, 일반적으로 접근성과 사용성(ergonomics) 은 중요하지 않게 여겨지는 경향이 있음
필요한 세부 제어가 있는 만큼, 오히려 더 사용성이 중요함
개발자가 정말 중요한 부분에만 집중할 수 있게 도와주면 생산성이 크게 향상됨

Rust의 고수준 적용을 추진하는 프로젝트들은 Rust 프로그래밍을 더욱 편리하게 개선할 기회를 제공함
이러한 개선점이 기초 소프트웨어 개발에도 고스란히 반영됨
핵심은 제어권과 신뢰성을 잃지 않고 사용성을 높이는 것

전체 스택 지원의 중요성

Rust에서 고수준 애플리케이션 개발을 쾌적하게 만드는 또 다른 이유는 전체 스택을 하나의 기술로 구축할 수 있기 때문
처음에는 Rust를 데이터 플레인 서비스 등 일부에만 사용하려던 개발자들이, 전 영역에 확장하는 경우가 많아짐
Rust가 생산성이 높고, 하나의 언어로 라이브러리와 코드 공유가 가능하기 때문임
본질적으로 단순한 코드는 어느 언어로 작성해도 단순함

점진적 심화(Iterative Deepening)의 경험

이상적으로는 Rust 사용자 첫 경험이 단순하고, 프로젝트가 진전됨에 따라 점진적으로 더 많은 제어를 국지적으로 확장할 수 있어야 함
이는 단순해 보이지만 실제로 매우 어려운 과제임
많은 프로젝트가 초심자 진입장벽이 크거나, 높은 제어 단계를 배우는 데 많은 지식을 요구하여 실패함
Rust가 항상 성공하는 것은 아니지만, 이를 개선하기 위해 지속적으로 노력 중임

앞으로의 계획

본 글은 이 시리즈의 첫 글로 이후 네 번에 걸쳐 Rust가 기초 소프트웨어에 더 적합해지기 위해 필요한 투자 영역을 제시할 계획임
- 언어 상호 운용성(smooth language interop) 과 확장성(extensibility)
- 타입 시스템을 통한 목표 명확화(clarity of purpose)
- 생태계 강화: 더 나은 가이드라인, 도구, Rust Foundation 활용
- 마지막 글에서는 Rust 오픈소스 조직 운영에 대해, 기여 및 유지보수가 최대한 접근성 높고 즐거운 활동이 되기 위한 방안을 다룰 예정

▲

aer0700 15시간전 [-]

c나 cpp에 표준적인 패키지 매니저가 있었으면 좋았을텐데요. Cargo를 보면 늘 그런 생각이 듭니다.

답변달기

▲

GN⁺ 3일전 [-]

Hacker News 의견

핵심 소프트웨어를 논할 때 Rust에서 제일 아쉽다고 생각하는 부분은 ABI임을 꼽음. Rust로 OS를 만들고 풍부한 서비스를 제공하려면, OS가 업그레이드되어도 애플리케이션이 라이브러리를 다시 컴파일할 필요 없이 쓸 수 있어야 함. Windows는 COM, Apple은 한때 ObjC의 dynamic dispatch(그리고 지금은 Swift ABI), Android는 JVM 및 바이트코드로 이 문제를 해결함. Rust는 사실상 extern "C" 밖에 지원을 못 해서 동적 라이브러리 활용이 제한적임. VM 계층(JVM, .NET) 없이 ABI를 제공하는 건 엄청나게 어렵고, 한번 정한 구현 세부사항을 절대 바꾸지 않아야 하므로 우선순위가 밀릴 만하다고 생각함. 실제로 이런 모델이 성공한 건 Swift와 COM 정도임. Rust에 완전한 ABI가 도입된다면 거의 완벽한 언어에 가까워질 것이라고 생각함. (바이너리 형태로 의존성을 관리하면 컴파일 시간도 크게 줄어듦)
- Rust가 기본적으로 선택적(opt-in)인 ABI 안정성만 도입하려는 이유가 zero-cost abstraction을 추구하기 때문임을 설명함. 안정적인 ABI는 성능 저하를 동반함을 C++의 사례(C++ ABI 관련 설명)로 방증함. Rust끼리 플러그인을 동적으로 로드(dlopen)하는 용도로는 stabby, abi_stable 등의 도구가 있고 꽤 잘 동작함. 보다 범용적인 언어간 상호운용을 위해선 crABI(crABI 제안서)가 미래의 대안이 될 수 있음. 다만 Rust만으로 해결 가능한 문제가 아니고, 다른 언어와 리눅스 배포판 등 여러 커뮤니티의 지지와 협력이 필요함. Rust는 I/O와 메모리 할당 방식을 명시적으로 선택하는 언어다 보니 Swift처럼 모든 걸 공유 라이브러리로만 해결하는 구조가 맞지 않을 수 있다는 점도 언급함.
- 거의 같은 문제를 Wasm Components로 해결하려고 시도 중임. WebAssembly가 이식 가능한 명령 포맷이라면, WebAssembly Components는 이식 가능한 실행/링킹 포맷임. 완전히 repr(wasm)/extern "wasm"처럼 손쉽지는 않지만 wit-bindgen이나 wasm32-wasip2 타깃을 활용하면 어렵지 않게 쓸 수 있음. Wasm Components 소개 영상
- 이게 정말 필요한지 의문임을 밝힘. 더 다양한 '것들'(slices, trait objects 등)을 인터페이스로 넘기는 게 더 편하긴 하겠지만, 현실적으로 extern "C" ABI만으로도 필요한 건 다 할 수 있음. 그리고 extern ABI를 더 많은 유형으로 확장하는 제안도 본 적이 있음
- Rust 콘퍼런스에서 이 주제에 대해 Swift의 방식을 강하게 참고한 내용의 발표를 본 적 있음. 아마도 추후 이 쪽으로 발전할 거라는 예상임
- 실제로 이미 그런 게 있음. 이름은 바로 'C'임을 언급함
Rust를 정말 좋아하지만 몇 가지 짜증나는 고질적인 문제들이 더 많은 관심을 받으면 좋겠음
- 1. self-referencing struct 문제가 있음. 예를 들어 소스 파일과 파싱된 AST를 같은 struct에 담고 싶어도 현재는 쉽지 않음. offset reference 같은 게 있으면 좋겠음
- 1. orphan rule(고아 트레잇 규칙). 이유는 이해하지만 여전히 귀찮은 규칙임. 새로운 기능(때로는 2~3중 래핑이 필요!)으로 해결할 수 있지만 꼭 이래야만 하는지 의문임
- 1. 적절한 컴파일 타임을 얻으려면 프로젝트를 많은 작은 크레이트로 쪼개야 함. 그 이유는 이해하지만 결과는 별로임. 크레이트는 하나의 컴파일 단위로 취급되고, 이는 순환 의존성이 허용되기 때문임. 하지만 대부분의 코드엔 실제론 순환 의존성이 없으니, 이런 걸 opt-in으로 처리하거나, 크레이트 내부 아이템/파일을 의존 그래프에 따라 자동으로 컴파일 단위로 나눠주면 좋겠음
- 생각나는 것만 적었지만 더 많을 것 같음. Rust는 건설적인 비판임에도 불구하고 내 인생 최고의 언어임
  - Rust는 크레이트 간에는 순환 의존성을 허용하지 않지만, 크레이트 내 모듈 간에는 순환 의존성이 허용됨을 지적함. 대부분의 코드엔 순환 의존성이 없다고 생각하지만, 예를 들어 test 서브모듈이 있는 어떤 모듈도 순환 의존성이 적용됨. 테스트를 제대로 분리하려면 모든 테스트 함수를 크레이트 루트에 정의해야 하는데, 현실적으로 비효율적임
  - 1, 2번에 완전 동의함. 4번으로 partial self borrows(메서드가 struct의 일부만 빌리도록 하는 기능)가 있었으면 좋겠다는 의견도 추가함. 3번은 여러 크레이트를 한 번에 배포할 수 있는 등 좀 더 나은 지원이 먼저 필요하다고 봄
  - orphan rule에 관해, Rust가 다른 더 나은 대안을 도입할 필요성을 말하는 것인지, 아니면 이걸 대체할 수 있는 기능이 필요하기만 하다는 것인지 더 설명해주기를 바람
  - orphan rule에 전적으로 동의함. 어플리케이션 크레이트에서는 이를 비활성화하거나 proc macro 등으로 충분한 위생이 보장될 땐 규칙을 완화할 수 있으면 좋겠음
“Smooth, iterative deepening”이란 표현을 곱씹으며, Rust가 cross-language 호환성을 너무 중시하는 건 오히려 복잡성만 키우고 안전성을 해칠 위험이 있다고 생각함. 이런 경우 차라리 libc처럼 시스템의 밑바닥 부분을 교체하는 식으로 해야 도움이 된다고 봄. Go는 cross-language 호출을 거의 하지 않음. Google은 핵심 라이브러리를 직접 개발해 기초를 튼튼히 했지만, Rust는 다양한 버전의 기초 라이브러리가 난립하고 많은 게 불완전함
- 지난 20년간 컴퓨터 과학의 핵심 과제 중 하나가 동일한 머신 내에서 여러 프로그램이 효율적으로 소통하도록 하는 것임을 밝힘. 대부분 MS의 DLL 기반을 소스와 상태로 우회하려고 하거나, CORBA 같은 객체 요청 브로커는 정착에 실패함. qnx식의 RPC도 마찬가지. 그래서 지금도 잘 맞지 않는 것들을 강제로 묶어쓰려는 시도만 반복됨
- 실제로는 모든 걸 소켓으로도 처리할 수 있지만, 소켓은 로우 바이트 스트림이라 잘못된 추상화임에도 불구하고 사용성이 좋아서 쓸 수밖에 없음
  - 내가 보기엔, 게시물에서 다루는 내용은 기존의 DLL/COM/Wasm components처럼 진짜 cross-language shared library 대체를 하자는 게 아니라 C++을 점진적으로 Rust로 마이그레이션하려는 현실적 니즈 때문임. 전체적인 메모리 안전성 향상을 위해서 '기존 프로그램들은 어떻게 할 것인가'가 큰 숙제인데, 현재 Rust와 C++의 상호운용 수준은 부족함. 두 언어가 소스 레벨에서 원활하게 협력할 수 있으면 Rust가 상당수 C++의 범주를 대체하게 될 실제 가능성도 커짐
  - 가끔 소켓과 프로토콜만 맞추면 거의 최상의 cross-language abstraction이 되는 것 같음. 그렇다면 정말 이상적이라고 생각하는 cross-language 호출 추상화가 뭔지 궁금함
"할당 피하기, GC 트리거 안되게 하기"가 최신 GC와 JIT 개념에 부합하지 않는다는 점을 부각함. 최신 GC는 stop-the-world latency가 거의 없는 경우도 많고, 전체 GC CPU 사용량은 resident set과 heap 크기의 비율이 주요 변수임. JIT는 AOT에 비해 최적화 기회가 더 크고, 더 적극적으로 탐색할 수 있음(투기적 최적화 덕분). 실제로 중요한 건 시작/워밍업 지연과 메모리 오버헤드, 그리고 악화된 최악 케이스 성능이 아니라 평균적 성능임. 게다가 수동 메모리 관리가 반드시 더 효율적이라고 보기 어렵고, 실제 RAM 사용량이 3배 늘어도 비용 차이는 제로일 수 있음. 이 주제를 잘 다룬 ISMM 학회 발표도 추천함
- JIT가 더 많은 최적화 기회를 본다는 의견은 뭘 의미하는지 구체적으로 궁금함. JIT는 결국 AOT의 보완임
- 여기서 말하는 '현대 GC'가 어떤 구현을 지칭하는지 묻는 질문임
플래그 처리된 댓글과 토론이 쟁점을 잘 짚었다고 봄. "공식 명세를 갖춘 언어 표준을 만들자", "구현이 여러 개 필요하다" 등 현실적으로 중요한 질문임. 특히 @infogulch가 언어가 산업의 근간이 되려면 공식 명세가 꼭 필요하다는 점을 잘 짚었음(참조 댓글)
- 플래그된 이유가 명확치 않을 뿐 아니라, 현실적으로 표준 명세가 없는 언어나 여러 개 구현이 없더라도 산업 기반 언어가 된 사례가 많음을 재치있게 예시로 듦. 예컨대 Ruby는 오래된 ISO 표준이 있다지만, 그건 해당 버전 한정이고 Python은 사실상 구현 자체가 표준임. Rust 역시 그렇고, 주류 사용자 입장에서는 이런 걸로 언어를 바꿔야 한다고 생각하진 않음
- "공식 언어 표준"에 대해 궁금해서 검색해보니 rust-lang/reference에 참조 문서가 있음. Rust 프로젝트는 언어 명세화에 상당히 진지하게 임하고 있음. 최근의 블로그 비전 소개글에서 진전 상황을 자세히 설명함. 명세 작업은 매우 크고 어렵지만, 주말에도 마스터 브랜치에 PR이 머지될 정도로 계속 활발히 진행 중임
- 구현이 여러 개 필요하다는 부분도 gccrs 등 대체 rust 컴파일러가 이미 공식적으로 개발되고 있어 도움이 되었기를 바람
- LLM과 Rust 모두 근본적으로 일부를 만족시키고 생산성에 약간의 향상을 준다고 보는 회의적 시각임. 다만 커뮤니티에서 책임감 없이 영향력을 키우려는 태도에는 동의하지 않음
- "published language standard"가 정확히 뭔지, 현실에서 어떤 도움이 되는지 더 설명을 부탁함
- Rust 자체에는 불만이 없으나, 일부 사용자가 형식 명세(formal specification)가 얼마나 중요한지 이해하지 못한다는 태도엔 아쉬움이 있음. 모든 컴퓨테이셔널 시스템은 명세에 얼마나 formal하게 접근하는지 따라 수명과 신뢰도가 좌우됨. 명확한 사양이 없다면 단순히 '어느 구현이 우연히 어떤 입력에 동작했다'는 것에 전적으로 의존해야 하므로, 그런 취약한 근거에서 시스템을 올려두는 건 위험함. 컴퓨팅에서 사양이 곧 시스템임(구현은 부수적인 최적화일 뿐)
사람들은 종종 Rust가 명세를 가져야 하냐는 질문 자체에 의문을 제기하는데, 이 점이 소프트웨어 엔지니어링에 실제 엔지니어링이 너무 적음을 방증함
- 소프트웨어 엔지니어링은 진짜 엔지니어링이 아니라고 생각함. 다리나 고층 건물처럼 3번씩 지어서 제대로 만들 필요가 없지만, 소프트웨어에서는 그게 오히려 좋은 접근법이 됨
Rust를 "프로그래머처럼 보이고 싶은 사람들만 쓰는 언어"라고 한 코멘트에 대해, 실제로 자신은 프로그래밍을 사랑하는 사람으로 Rust가 신선한 충격이었음을 밝힘. C++가 극도로 고통스러웠던 과거로 도저히 돌아가고 싶지 않음. 그리고 언어 표준(ferrocene 사양 기부)이나 구현 수가 중요하지 않다고 봄. Python, Java도 중심이 되는 구현 하나에 모두 의존하며 잘 운영되고 있음. C++은 여러 컴파일러를 지원하려다 결국 플랫폼별로 복잡한 문제만 커졌음. cargo의 "엉망진창"이 구체적으로 뭔지 모르겠고, C++쪽이 훨씬 더 불편했다고 생각함
- cargo에 대해 구체적으로 어떤 점이 문제인지 궁금함을 묻는 질문임
- 언어나 도구의 표준/구현 다양성이 정말 중요한지, 시기상조가 아닐지, 그리고 Rust가 일찍부터 이런 데 에너지를 쏟았다면 지금만큼 성공적이었을지 의문임을 덧붙임. 해당 기사에서는 그런 포괄적 대체(replacement of everything)를 주장하는 게 아니라, 특정 타깃 용도의 지원/적합성을 강조하려는 것 같음
- cargo는 현재 전 세계 주요 언어 중 최고의 패키지 매니저라고 생각함. 그간의 패키지 관리자들이 실패한 부분을 잘 학습해 가장 세련되고 인프라로서도 수준이 높음. 네임스페이스, 완전한 repeatable build 등 약간의 개선이 필요할 순 있지만, 지금의 cargo를 다른 언어에 얹는 건 거의 불가능에 가까움. 이만한 인프라를 가진 언어는 거의 없음