Rust에 베팅한 지 10년이 되었고, 앞으로 기대하는 것
(tably.com)- Rust 1.0 출시 직후부터 10년간 Rust를 실무에 도입한 경험과 앞으로의 10년에 대한 기대를 정리한 글
- 초창기에는 버전 호환성 문제와 빌드 시간, 빌림 검사기(borrow checker) 적응이 어려웠음
- Rust 커뮤니티와 생태계는 “탁월한 프로그래밍 감각”과 강한 공동체 문화로 인해 빠르게 발전했으며, 뛰어난 개발자들이 Rust로 모여드는 현상이 두드러짐
- 이제는 일반 시스템 및 백엔드 분야에서 Rust가 “안정적인 선택” 이 되었으며, 표준 라이브러리의 발전과 크레이트 생태계의 성숙으로 인해 불확실성이 크게 줄었음
- 빌드 속도, 이식성, const 기능, 동시성, 다양한 도메인 확장 등 Rust가 해결해야 할 남은 과제와 발전 방향을 구체적으로 제시함
- 앞으로의 10년은 더 빠른 컴파일, 광범위한 도메인 확장, 개발자 경험의 혁신이 이어질 것으로 전망하며, Rust 생태계의 긍정적 피드백 루프가 가속화될 것이라고 기대함
- 2015년 6월, Rust 1.0 공개의 열기가 식어가는 한달 후쯤에 첫번째 Rust 코드를 작성함
- C, Python, JavaScript를 사용해오다 Rust를 접한 이후, 다시는 돌아보지 않게 됨
- Rust 기반의 스타트업 두 곳, 50만 줄 이상의 코드를 작성했던 경험을 기반으로 10년의 성찰을 공유함
초창기는 힘겨운 시간 - The early days were painful
- 초기 Rust 도입 시, 크레이트와 컴파일러 간 버전 호환성이 매우 불안정했으며, 작은 버그 픽스에도 전체 빌드 환경을 강제로 업데이트하는 일이 많았음
- 빌림 검사기(‘borrow checker’)의 개념과 라이프타임 관리가 어렵게 느껴졌으며, 복잡한 타입이 늘어날수록 컴파일 시간이 급격히 늘어나는 문제가 심각했음
- 새로운 기능이나 버그 픽스가 필요할 때마다 “세상의 모든 버전”을 업데이트해야 했으며, 호환 가능한 버전을 찾는 데 많은 시간을 소비해야 했음
Rust 커뮤니티의 탁월함 - The people were and are exceptional
- Rust 생태계는 단순하고 우아한 구현, 빠르고 견고한 성능을 지향하는 탁월한 프로그래밍 문화가 자리잡았음
- TypeScript나 Python을 쓸 때보다 Rust의 의존성 구조가 훨씬 깔끔하고 빌드가 단순함
- 커뮤니티 자원봉사자들의 헌신적인 기여와 “지금은 아니다/아직 아니다”라는 신중한 태도가 핵심적 역할을 함
- 런던에서 Rust 개발자 구인에 큰 이점이 있었으며, Rust 개발자의 평균 역량이 매우 높음
Rust, (몇몇 도메인에선) 안전한 선택지가 됨 - Rust has become a safe bet (in some domains)
- 초창기에는 표준 라이브러리(std)의 부재로 인해 직접 유틸리티 함수와 패치를 만들어야 했으나, 이제는 대부분의 기능이 std와 크레이트에 내장되어 불확실성이 크게 감소함
- 빌드와 업그레이드 예측 가능성, 외부 의존성 감소, semver 준수, 빌림 검사기와 추론 엔진 개선 등으로 Rust 사용 경험이 대폭 안정화됨
- 신규 크레이트(예: jiff, polars, tauri)는 과거의 시행착오를 기반으로 개발되고, tokio, hyper, regex 등은 실전에서 검증됨
- 과거에는 “바퀴 재발명”이 불가피했지만, 지금은 비즈니스 로직에 집중해 고성능/견고한 애플리케이션 개발이 가능해짐
오늘날의 Rust가 보여주는 개발 환경 - Rust today feels like what programming should be
- Rust는 간결하고 견고한 빌드 시스템, 최고의 에러 메시지와 린트, 훌륭한 문서와 IDE 통합, 강력한 CI/회귀 테스트 등 프로그래머 중심의 공감 능력을 갖춘 언어임
- 대규모 오픈소스 프로젝트 중 Rust만큼 프로그래머 친화적인 언어는 드뭄
- 수많은 커뮤니티와 기여자들의 “장기적 투자”가 현재의 Rust를 만든 핵심 요인임
향후 10년에 대한 기대 - What I’m looking forward to over the next 10 years
더 단순하고 빠른 빌드 - Simpler and faster builds
- 복잡하거나 느린 의존성을 단순하고 빠른 것으로 대체하는 작업이 계속될 것으로 기대
- 순수 Rust 표준 라이브러리, 시스템 linker와 라이브러리 의존성 감소, pure-Rust 암호화, 영속 BTreeMap, Rust 기반 게임 엔진 등 새로운 시도가 기대됨
- Tably에서도 최근 수개월간 프론트엔드/백엔드 컴파일 속도가 60% 향상됨
이식성 증대와 #[cfg()] 최소화 - Improved portability and less #[cfg()]
- 다양한 플랫폼/옵션 조합의 테스트가 어렵고, #[cfg()]로 인한 미검증 코드/문서 불완전/IDE 문제 등이 발생함
- trait system 내로 #[cfg()]를 이동하여 플랫폼/옵션 보장 및 재컴파일 최소화, MIR 캐시, 빠른 CI 실현이 기대됨
모든 코드가 const가 되길 - Everything being const
- 컴파일 타임에 더 많은 작업을 미리 수행함으로써 매크로/빌드스크립트 의존도를 줄이고, 런타임 오류도 미리 방지 가능
- 현재는 제한적이나, 앞으로 “모든 코드가 const context에서 실행 가능”한 Rust를 지향
동시성의 단순화 - Simpler concurrency
- 현행 Rust의 비동기(Async) 모델은 ‘static bound, cancellation-safety, trait 제한 등 복잡성이 높아 실무에 어려움을 줌
- 과거의 user-space green thread(libgreen)처럼 언어 차원의 단순한 동시성 추구가 필요함
더 많은 도메인에서의 경쟁력 갖추기 - Excelling in more domains
- Rust의 웹 브라우저 내 활용(특히 wasm/rustwasm) 분야는 아직 미개척 상태로, 크로스브라우저 스택트레이스 등 여러 과제가 남아 있음
- leptos, sycamore 등 프레임워크 발전이 지속적이지만, 여전히 개선 여지 있음
- Rapid prototyping, 비즈니스 로직, GUI, 머신러닝, 게임개발 등 Rust가 아직 완전히 뚫지 못한 도메인도 지속적으로 개선될 것으로 기대
결론
- Rust 성장의 미래는 매우 명확하고 희망적임
- 도입이 늘수록 엔지니어링/테스트 역량이 커지고, 이로 인해 더 넓은 채택과 개선이 선순환을 이루는 구조
- 다가오는 10년은 보다 빠른 컴파일, 다양한 분야에서의 적용, 매끄러운 개발 경험이 현실화될 것
- Rust의 새로운 10년을 기대함
러스트는 다 좋은데 언어가 너무 요구하는 것이 많아요.
러스트를 사용하다 보면 아이디어의 구현 자체에 집중하기보다는 러스트라는 언어에 대한 연구를 하는 것 같아요.
C++에서 옮긴다던지 하는 식으로 이미 만들어진 프로젝트를 옮기는 데에는 별 지장 없겠지만
새로운 아이디어를 구현할 때 사용하는 것이 편한지는 잘 모르겠습니다.
Hacker News 의견
- 매우 긍정적인 내용의 글이고 내 경험과도 맞아떨어짐. 다만 어두운 전망을 꼽으라면 이런 부분임:
"async는 static 바운드, 취소 안전성, 트레이트와 dyn 관련 제한 등으로 인해 비교적 높은 복잡도 비용을 가지고 있음. 현재로선 이 문제가 풀릴 기미가 없음. 동기/비동기 프리미티브 간의 분기와 생태계의 고유한 특성이 async tax(추가 비용)을 높임. Effects에 기반한 솔루션도 딱히 희망적이지 않음."
"1.0 이전 Rust에는 libgreen이라는 해법이 있었음. bifurcation(분할) 없는 사용자 공간에서 동시성을 구현했지만, 성능, 이식성, 유지보수 비용이 상당해 결국 제거됨. 엔지니어링 역량만 충분하다면 다시 고민해볼 만한 가치가 있다고 생각함. 언젠가 std::{fs, net}와 fiber::{spawn, select}를 generator로 zero-cost wrapping한 PoC를 만들고 싶음"- "'static bound이 복잡도를 높게 만든다"라는 논의는 Tokio async 러ntime의 설계 선택일 뿐 Rust 전체의 디자인이라고 보긴 어렵다는 의견임. Embassy async runtime은 이런 바운드 없이도 동작하지만, 대신 pinning을 직접 관리해야 함. 'static bound는 사실 복잡도 낮추려는 취지임
- 2022년 말 Rust에 빠져 공부한 사람으로서, 2015년 같이 더 힘들었던 시절에 언어를 배운 분들의 경험담이 항상 흥미로움. Rust가 더 성숙한 시점에 배울 수 있어서 이미 가파른 러닝 커브가 다소 완화된 느낌을 받았고, 그 점에서 운이 좋았다고 생각함. 요즘은 글에서 언급한 Rust 초창기 경험담을 Zig에서 다시 겪고 있는 기분임. Zig는 Rust 초창기와 비슷한 시점에 있는 것 같음. 그래도 이미 재밌게 사용 중임
- "찾은 것보다 더 나은 상태로 남겨둘 것"이라는 문화가 강함. 툴이나 언어가 헷갈렸다면 사용자 잘못이 아니라는 생각이 자리잡음. 내가 혼동을 겪었다면 다른 이들도 겪을 테니, 발견할 때마다 개선하는 게 모두에게 큰 이득임. 나무 심는 데 두 번째로 좋은 때가 오늘이라는 속담이 적용됨. 이런 문화 덕분에 예전에 Rust를 시도했다가 좌절했던 사람이 1년 뒤라면 충분히 더 개선된 경험을 할 수 있음. 그래서 Rust 입문자에게 줄 최고의 조언은 "6개월만 기다려봐"였음
- MSFT, Google 같은 빅테크나 Linux 등 대형 오픈소스 프로젝트에 채택된 언어라면 이미 생태계가 충분히 성숙했다는 증거임. 하지만 Zig는 아직 기존 도구들에 비해 (큰) 변화를 보여주진 못해서 그런 확신이 없음
- Rust는 함수형 프로그래밍을 장려하는 느낌을 받음. 원래는 내부 상태를 advance마다 변경하는 파서를 만들다, 가변성과 빌림체계(borrowing) 때문에 힘들어서 stateless 파서로 바꿔야 했음. 내부 인덱스 수정 대신 인덱스를 반환하는 구조로 변경하게 됨. 이런 식으로 기존 방식이 잘 안 먹혀서 Rust에서 새롭게 접근해야 하는 경우가 흔한지 궁금함
- 나도 비슷한 경험이 있음. 단순한 경우라면 mutable, 명령형 스타일로도 문제 없지만, 복잡도가 커질수록 함수형 스타일로 바꾸고 변경을 최대한 피하게 됨. Borrow checker랑 라이프타임 때문에 전통적인 패턴이 어렵고 자연스럽게 함수형으로 가게 됨. 함수형으로 구현하는 게 익숙치 않으면 힘들 수 있지만, 컴파일러가 더 만족스러워지는 경험임
- Async/await가 Rust를 사용하지 않는 유일한 이유임
- 사실 async/await는 Rust를 써야 할 주요한 이유 중 하나라고 생각함. 동시성 패턴을 훨씬 간단하게 만들어 주기 때문임. 초반엔 뭔가 악성 전염병처럼 모든 코드가 결국 async가 되어야만 하는 느낌이었는데, async 코드와 상호작용하는 법 알게 되니 편해짐. 보통 spawn, spawn_blocking, futures::stream이 90%의 활용도를 차지하고, 적절하게 "경계"를 세워두면 async가 전파될 필요도 없음
- 어느 정도 이해는 됨. 하지만 나는 Rust에서 async/await가 딱 맞아떨어져서 가장 큰 사용 이유가 됨. 문법도 좋아하고 function colouring 문제도 별로 신경 쓰지 않음. 특히 tokio를 쓸 때 필요한 표준 함수의 async 버전이 다 있어서 솔루션이 잘 풀리는 느낌임. 이런 부분이 배리어를 만들 수도 있지만, 동시성 프로그램 짜기 훨씬 쉽고 퍼포먼스도 괜찮아서 만족함. 취소(cancellation) 같은 건 좀 헤매기도 하지만, 그건 내 실력 문제라고 생각함
- 지금은 다 제공하고 있지 않나?