Rust가 오랫동안 ‘가장 사랑받는(이제는 가장 존경받는)’ 언어로 꼽혀온 이유를 인터뷰 데이터를 통해 살펴보고, Rust의 신뢰성·효율성·도구 지원·생태계·확장성이 어떻게 ‘어떤 문제에도 가져갈 수 있는 믿을 만한 다목적 도구’라는 경험을 만들어내는지, 그리고 이를 유지·강화하기 위한 제안을 정리한다.
Rust는 2015년 1.0 릴리스 이후 매년 Stack Overflow의 Most Loved(현재 명칭은 Most Admired) 언어로 선정되어 왔습니다. 이는 Rust를 사용하는 사람들이 Rust를 계속 쓰고 싶어한다는 뜻입니다1. 그리고 그 이유는 성능이 중요한 작업이나 임베디드 개발에만 있는 것이 아니라, 셸 스크립트, 웹 앱, 그리고 전혀 예상 못한 온갖 작업에까지 확장됩니다. 한 참가자는 이를 아주 잘 요약했습니다. “이제는 Rust 말고 다른 언어로는 코드를 쓰고 싶지 않아요.”
비전 문서 데이터를 분석하며 우리가 정말 설명하고 싶었던 것 중 하나는 이것이었습니다: 사람들이 Rust에 그렇게 강한 충성심을 갖게 만드는 것은 무엇인가?2 인터뷰에 기반한 답은 단순하면서도 복잡합니다. 짧게 말하면 Rust는 신뢰할 수 있고 효율적인 소프트웨어를 쓰도록 사람들을 ‘강화(empower)’한다는 것입니다. 익숙하게 들리나요? 그럴 만합니다. 이는 웹사이트에 적어둔 슬로건이기도 하니까요. 더 흥미로운 질문은 그 ‘강화’가 어떻게 생기는지, 그리고 Rust를 발전시킬 때 그것이 무엇을 시사하는지입니다.
우리가 가장 먼저 알아차린 점은, 대화 내내—누군가가 첫 Rust 프로그램을 쓰는 중이든 몇 년째 쓰는 중이든, 거대한 데이터 클러스터를 만들든 임베디드 디바이스를 만들든 그냥 취미로 만지작거리든—사람들이 Rust에서 좋다고 말하는 요소들이 꽤 일관되게 반복된다는 것이었습니다.
첫째는 신뢰성(reliability) 입니다. 사람들은 “컴파일되면 동작한다”는 느낌을 사랑합니다:
“Rust에서 정말 좋은 점은 컴파일만 되면 보통 실행도 된다는 거예요. 그건 환상적이고, Java에서는 익숙하지 않은 경험이죠.” -- 자동차 임베디드 시스템에서 일하는 시니어 소프트웨어 엔지니어
“Rust는 정말로 당신 편이 되어주는 언어 중 하나예요. 더 푹 잘 수 있고, 실제로 덜 ‘영리하게’ 굴어도 되죠.” -- Rust 컨설턴트이자 오픈 소스 프레임워크 개발자
또 하나는 물론 효율성(efficiency) 입니다. 특히 아주 큰 규모(데이터 센터)와 아주 작은 규모(임베디드)라는 양 극단에서 자주 언급됩니다:
“머신 자원을 [주요] 계산에 남겨두고 싶어요. 워치독 같은 것 때문에 자원을 뺏기고 싶지 않죠.” -- 데이터 사이언스 플랫폼에서 일하는 소프트웨어 엔지니어
“Rust를 쓰면 속도 측면에서도 이점이 있어요. 예를 들어, [..] Python 컴포넌트를 Rust 컴포넌트로 바꾸기만 했는데 100배 속도 향상이 있었죠.” -- 의료기기 스타트업의 Rust 개발자
효율성은 특히 ‘대규모(at-scale) 워크로드’ 를 운영하는 고객들과 이야기할 때 자주 등장하는데, 작은 성능 향상도 큰 비용 절감으로 이어질 수 있기 때문입니다:
“우리는 라이브러리가 하나 있는데—사실상 임베디드 DB 같은 거예요—많은 머신에 배포합니다. Java로 작성되어 있었고 최근 Java에서 Rust로 재작성했는데, 성능이 9~10배 정도 개선됐어요.” -- 클라우드 인프라 서비스에서 일하는 디스팅귀시드 엔지니어
“VM을 로드하는 Java 코드와 Rust 사이에서 같은 모듈에서 4배 효율을 보고 있어요. 데이터 센터 비용으로 보면 엄청난 돈이 절약되죠.” -- 금융 서비스 전문 백엔드 엔지니어링 회사 창업자
스펙트럼의 다른 쪽 끝에서는, 임베디드 개발을 하거나 더 낮은 추상화 수준에서 작업하는 사람들이 Rust가 제공하는 로우레벨 제어와 시스템 세부사항에 대한 접근 능력을 강조합니다:
“Rust는 제가 오랫동안 찾아 헤매던 C의 대체재였어요.” -- 금융 서비스 전문 백엔드 엔지니어링 회사 창업자
“새로 뭔가를 쓸 거고, 로우레벨 시스템스러운 작업을 한다면, 솔직히 Rust가 유일한 현실적 선택지라고 생각해요.” -- 디스팅귀시드 엔지니어
많은 사람들이 Rust의 지원적인 도구(tooling) 의 중요성을 말합니다. 빠르게 시작하게 해주고, 특히 컴파일러의 에러 메시지가 그렇습니다:
“제가 Rust를 배우는 데 성공할 수 있었던 큰 이유는 도구 때문이라고 생각해요. 제겐 Rust 언어 자체는 시작이 어려웠지만, 도구는 믿을 수 없을 만큼 쉬웠어요.” -- 개발자 도구 회사 임원
“도구가 저에게도 우리에게도 정말 잘 맞아요. 제가 Rust와 상호작용하는 1순위 방식은 도구 생태계를 통해서예요. Cargo로 빌드하고, Cargo로 테스트하고, 모든 곳에서 Clippy에 의존합니다.” -- 안전이 중요한 로보틱스에서 일하는 임베디드 시스템 엔지니어
“Rust 컴파일러의 에러 메시지와 제안도 매우 도움이 된다고 생각해요.” -- 형식 검증(formal verification) 전문 교수
마지막으로, Rust의 가장 중요한 미덕 중 하나는 확장성(extensibility) 입니다. 언어 자체와 crates.io 생태계 양쪽 모두에서, Rust는 최종 사용자가 필요에 맞는 라이브러리와 추상화를 만들 수 있도록 설계되어 있습니다:
“크레이트 생태계가 안정성 보장과 시맨틱 버저닝과 결합되면서, 제가 본 ‘집어 들고 바로 쓰는’ 생태계 중 최고예요.” -- 컴퓨터 과학 교수이자 프로그래밍 언어 디자이너
“proc macro는 Rust의 정말 큰 초능력이라고 생각해요.” -- Rust 네트워킹 라이브러리의 제작자이자 유지관리자
“Rust는 시작하기, 재사용하기, 새 도구와 새 라이브러리를 빠르게 실험하기가 정말 정말 쉬워요... 그래서 제게는 실험 플랫폼으로서 훌륭합니다.” -- 임베디드 및 실시간 시스템에 집중하는 Rust 전문가이자 컨설턴트
신뢰성, 효율성, 도구, 생태계—이 모든 것은 사람들이 Rust에서 고마워하는(appreciate) 것들입니다. 하지만 그들이 사랑하는(love) 것은 그중 어느 하나가 아닙니다. 여러 요소가 결합되어 Rust가 신뢰할 수 있고 다재다능한 도구가 되어, 거의 어떤 문제에도 가져갈 수 있게 해준다는 점입니다:
“그 언어를 알게 됐을 때 ‘그래, 이게 내가 찾던 언어야’라는 생각이 들었어요. C와 Python을 쓸지 고민하는 걸 멈추게 해주는 언어죠. 그래서 Rust를 써야만 해요. 가장 낮은 수준까지도, 가장 높은 수준까지도 갈 수 있으니까요.” -- 아프리카의 소프트웨어 엔지니어이자 커뮤니티 조직자
“저는 임베디드부터 아주 화려한 애플리케이션까지, 위에서 아래까지 잘 동작하는 언어를 원했어요.” -- 컴퓨터 과학 교수이자 프로그래밍 언어 디자이너
“만약 [Rust]가 어떤 방식으로든 더 자기 자신을 ‘팔’아야 한다면, 저는 이렇게 말할 것 같아요. 고성능, 높은 표현력, 범용 언어이며, 스택의 맨 위부터 맨 아래까지 전부 그 언어로 쓸 수 있다는 멋진 장점이 있다.” -- 임베디드 및 실시간 시스템에 집중하는 Rust 전문가이자 컨설턴트
신뢰성을 빼면, 신뢰할 수 없게 됩니다. 배포할 때마다 의심하게 되고, 리팩터링을 두려워하고, 주니어 개발자가 크리티컬 경로를 건드리게 하는 데 머뭇거리게 됩니다.
“Rust는 그 문턱을 낮춰줘요. 올바른 Rust 코드를 쓰는 게 훨씬 쉽습니다. 팀 리더로서 경험이 적은 엔지니어가 이런 중요한 애플리케이션에 기여할 때도 훨씬 안전하다고 느껴요.” -- 클라우드 인프라 서비스에서 일하는 디스팅귀시드 엔지니어
“제가 Rust 소프트웨어를 작성한 경험은 대체로 한번 동작하게 만들면, 계속 동작한다는 거예요. 언어 차원에서의 하위 호환성에 대한 많은 배려와, 전반적인 생태계에 대한 많은 배려가 결합된 결과죠.” -- 임베디드 및 실시간 시스템에 집중하는 Rust 전문가이자 컨설턴트
신뢰성은 또한 사람들이 새로운 도메인에 들어갈 때 도움이 되는 가드레일을 제공합니다—초보자가 기본을 배우는 경우든, 전문가가 낯선 영역에 들어가는 경우든 말이죠:
“Rust는 match 같은 것들, 그리고 정말 좋은 함수형 프로그래밍 기법들을 소개해줘요.” -- 프로덕션 Rust 경험이 있는 소프트웨어 엔지니어
“Rust의 소유권 규율은 일반 Rust 프로그래머에게도, 검증(verification)에도 유용하다고 생각해요. 함수 범위 안에서 무엇을 수정하는지, 무엇이 수정되지 않는지, 무엇이 별칭(alias)이고 무엇이 아닌지 아주 명확히 알 수 있게 해주죠.” -- 형식 검증 전문 교수
“Rust를 발견했고... 사실상 혼자 펌웨어 개발을 하면서 자신감을 조금 더 얻기 위해 쓰기 시작했어요.” -- 자동차 디지털 콕핏 시스템에서 일하는 소프트웨어 엔지니어
효율성과 로우레벨 제어를 빼면, 갈 수 없는 곳들이 생깁니다. 임베디드 시스템, 실시간 애플리케이션, 사이클당 비용(cost-per-cycle)이 중요한 모든 곳들 말이죠.
“Rust 성능은 말도 안 되게 좋아요. 훨씬 더 좋은데다가 안전하죠. C++/C 라이브러리나 C 애플리케이션을 Rust로 다시 썼을 때, Rust가 메모리 레이아웃을 더 잘 잡아줘서 오히려 더 빨라지곤 했어요.” -- 소비자 쇼핑 경험을 이끄는 시니어 프린시펄 엔지니어
“열에 아홉은 마이크로컨트롤러 코드를 쓰고 유닛 테스트로만 테스트해요. 실제 하드웨어에 올리면 첫 번에 그냥 동작하죠.” -- 안전이 중요한 로보틱스에서 일하는 임베디드 시스템 엔지니어
“확장되는 시스템을 자신 있게 구축할 수 있어요.” -- 미디어 및 스트리밍 플랫폼에서 20년 경력의 엔지니어링 매니저
도구와 생태계를 빼면, 시작할 수가 없습니다. 혹은 시작은 해도 고된 작업이 되고, 생산적이라는 느낌을 갖기 어렵습니다.
“저에게 Rust 시작은 언어가 어려웠지만 도구는 믿을 수 없을 만큼 쉬웠어요... 그냥 코드를 쓰기 시작하면 빌드되고 실행됐고, 그게 저에겐 엄청 큰 차이를 만들었습니다.” -- 개발자 도구 회사 창업자 겸 CEO
“Cargo는 놀라운 패키지 매니저예요. 제가 써본 것 중 최고일지도 몰라요. Cargo에서 문제를 겪은 적이 거의 없어요. 그냥 되죠.” -- 프로덕션 Rust 경험이 있는 소프트웨어 엔지니어
“Rust 컴파일러는 에러를 정말 잘 내줘요. 어떤 종류의 에러를 만들어내는지 면에서 엄청나게 도움이 됩니다. 그런데 단지 에러뿐 아니라, 다른 언어가 잡지 못할 에러까지도 잡아준다는 사실이죠.” -- 클라우드 인프라 서비스에서 일하는 디스팅귀시드 엔지니어
이 모든 요소가 함께 맞물리면 흥미로운 일이 벌어집니다. Rust가 원래는 접근하기 어려웠을 도메인으로 들어가는 게이트웨이가 됩니다. Rust가 이전에는 할 수 없었던 일을 할 수 있게 해줘서 커리어가 바뀐 사람들의 이야기를 우리는 계속 들었습니다:
“저는 토목공학이었고 프론트엔드 개발을 독학했어요. 컴퓨터 배경이 전혀 없었죠. Rust와 분산 시스템, 그리고 그 주변의 설계와 시스템에 관심이 생겼어요. 전공을 바꿨고, 컴퓨터 과학과 Rust를 동시에 공부했습니다.” -- 암호학 연구로 전향 중인 소프트웨어 엔지니어
“지난 25년 동안 [다국적 엔지니어링·기술 회사]의 여러 자회사들과 일해왔어요. 대부분 Java 쪽에서 소프트웨어 개발을 해왔죠... 2년 전 자동차 분야를 들여다보기 시작했습니다. 그 맥락에서 자연스럽게 C++(하기 싫었죠)를 시작하든지, 새로 자리 잡는 Rust 생태계로 뛰어들 기회를 잡든지 둘 중 하나였어요.” -- 자동차 임베디드 시스템에서 일하는 시니어 소프트웨어 엔지니어
“저는 블록체인에서 시작했어요. 지금은 본업에서 다른 일을 하고 있죠. Rust가 그 도메인으로 들어가는 방법을 실제로 제공해줬어요.” -- Rust 개발자이자 항공우주 커뮤니티 리더
“그 전에는 동적 언어, 특히 Ruby로 10년 동안 웹 애플리케이션을 개발했어요. 시스템 프로그래밍에 초점을 맞춘 언어를 선택하고 싶어서 Rust를 선택했습니다. 제 커리어가 바뀐 거죠.” -- 자동차 시스템 및 블록체인 인프라에서 일하는 Rust 컨설턴트 겸 저자
Rust의 각 속성은 여러 도메인에 걸친 범용성을 위해 필요합니다. 하지만 어느 하나가 과도해지거나, 다른 속성이 빠지면, 오히려 장애물이 되기도 합니다.
Rust의 가장 강력한 측면 중 하나는 타입 시스템을 통해 애플리케이션 도메인의 요소들을 모델링할 수 있다는 점입니다. 이는 버그를 방지하고, 초보자들이 시작하는 데도 도움을 줍니다3:
“그냥 원시 비트 필드를 쓰는 대신, 누군가가 그걸 타입 시스템에 인코딩해두었어요. 그래서 ‘문 열기(open door)’ 같은 함수가 있을 때 문이 이미 열려 있으면 ‘문 열기’를 전달할 수 없죠. 타입 시스템이 그걸 튕겨내고 거부합니다.” -- 자동차 디지털 콕핏 시스템에서 일하는 소프트웨어 엔지니어
“계약을 만들 수 있어요. 예를 들어, 어떤 순서로 락을 사용할 수 있는지 같은 것들요.” -- 자동차 미들웨어 개발을 하는 시니어 임베디드 시스템 엔지니어
하지만 문제는, 그 불변식을 타입으로 인코딩하는 작업이 가끔은 문제 자체보다 더 복잡한 무언가를 만들어낼 수 있다는 것입니다:
“Rust에 async도 있고 제네릭도 있고 라이프타임도 있으면, 타입이 너무 복잡해져서 그 코드를 이해하거나 작성하려면 사실상 Rust 신(Rust god) 같은 사람이 되어야 해요.” -- 프로덕션 Rust 경험이 있는 소프트웨어 엔지니어
“스파게티 코드 대신 스파게티 타이핑이 있죠.” -- 자동차 반도체 회사의 플랫폼 아키텍트
“저는 더 불투명하고, 이해하기가 더 어렵다고 느껴요. 타입이 단지 인터페이스만 설명하는 게 아니라 라이프타임, 접근 방식, 스택인지 힙인지 같은 것들까지 설명하니까, 안에 너무 많은 것들이 들어있어요.” -- 데이터 사이언스 플랫폼에서 일하는 소프트웨어 엔지니어
이 때문에 어떤 사람들은 Rust의 더 복잡한 기능은 정말 필요할 때만 쓰자는 주장을 하기도 합니다:
“제 주장은 Rust의 어려운 부분—트레이트, 라이프타임 등—이 생산성을 위해 근본적으로 필요한 건 아니라는 거예요. 학습 곡선과 라이브러리 구성 방식을 통해 더 빠르게 온보딩할 수 있는 방법이 있어요.” -- Rust 네트워킹 라이브러리의 제작자이자 유지관리자
Async Rust는 네트워크 시스템을 Rust로 구축하는 사용을 크게 늘리는 데 기여했습니다. 하지만 많은 댓글에서 “async Rust”는 동기 Rust보다 훨씬 더 어렵다는 느낌을 이야기했습니다:
“학습에는 램프가 있고, 그 다음 점프가 있고, 저기 async가 따로 있어요. 그래서 목표는 Rust에 충분히 신나게 만들어서 ‘슬픔의 협곡(chasm of sadness)’을 뛰어넘어 async Rust 쪽에 착지하는 거죠.” -- 자동차 디지털 콕핏 시스템에서 일하는 소프트웨어 엔지니어
“전반적인 인상은 솔직히 꽤 부정적이에요. 덜 구워진 느낌이죠... Pin 같은—효과적으로 쓰려면 비전문적인 지식이 많이 필요한데, 예를 들면 Pin이 어떻게 동작하는지 저는 설명 못하거든요?” -- Rust 전문성을 가진 연구 소프트웨어 엔지니어
Rust가 “새로운 도메인에 도전할 수 있게 도와주는 믿을 만한 도구”라는 경험을 제공하려면, 사람들이 그 새 도메인에서도 기존 Rust에서의 기대와 지식을 활용할 수 있어야 합니다. Async에서는 언어 기능의 공백(예: 트레이트에서의 async fn은 작년에야 가능해졌고 여전히 구멍이 있음)뿐 아니라, 다른 곳에서 “격차를 메우는” 역할을 하던 지원적 도구와 생태계도 덜 잘 동작합니다:
“에러 메시지가 너무 다루기 어려워서 async를 쓰지 않는 쪽에 찬성했어요.” -- 데스크톱 애플리케이션 개발자
“여전히 많은 상황에서 _저 라이브러리 유용해 보이는데, 쓰고 싶다_가 곧바로 tokio-rs나 다른 런타임 중 하나에 묶이게 만들어요. 그러면 나도 라이브러리를 쓰려고 했는데 런타임에 락인이라니 좀 실망인데 라고 되죠.” -- 리눅스 기능 안전(functional safety)에서 일하는 안전 시스템 엔지니어
“우리는 보통 서비스에 Rust를 쓰고, DB 등과 상호작용하는 라이브러리들이 async인 경우가 많아서 async를 많이 씁니다. 문제를 겪는 경우는, 예를 들어 설명되지 않는 높은 CPU 사용률 같은 거죠. 그걸 트러블슈팅하거나 진단하는 사실상 유일한 직접적인 방법은 좋아, GDB를 붙여서 모든 스레드가 뭘 하는지 보자 같은 거예요. GDB는—이건 당연히 Rust 탓은 아니지만—특히 큰 애플리케이션에서 사용하기 쉬운 도구가 아니죠. [..] async에서는 더 어려워요. 코드가 실행되는 걸 보는 게 아니라, 지금은 사실 힙 위에 앉아 있는 상태거든요. 초반에는 그게 그런 구조라는 걸 실제로 몰랐어요.” -- Rust와 Python을 쓰는 회사의 숙련된 Rust 개발자
Async는 충분히 중요해서 더 깊이 파고들 가치가 있습니다. 우리의 연구는 많은 좌절을 드러냈지만, 더 구체적인 통찰을 주기에는 충분히 깊지 않았습니다. 이는 ( 첫 번째 글에서 제안한) 미래의 사용자 연구 팀이 맡으면 좋은 과제일 것입니다.
앞서 Rust의 확장성이 범용성을 달성하는 방식의 일부라고 말했습니다. 오버로딩 가능한 연산자, 트레이트, 매크로 같은 메커니즘은 라이브러리가 개발자에게 풍부한 경험을 제공하게 해줍니다. 작은 표준 라이브러리와 쉬운 패키지 관리는 흔한 요구부터 특수한 요구까지 아우르는 풍부한 크레이트 생태계의 형성을 장려합니다. 그러나 특히 처음 시작할 때는, 그 확장성 이 오히려 지원성 을 희생시키는 결과가 될 수 있습니다. 선택지가 너무 많아(“선택의 폭정”) 압도적으로 느껴지기 때문입니다:
“어떤 크레이트를 써야 하는지 발견하기가 좀 어려워요. 특정 작업에 어떤 크레이트를 써야 하는지에 대한 암묵지(tacit knowledge) 층이 있는데, 경험과 고생을 통해 쌓이죠. 모두가 각자 리서치를 하고 있어요.” -- 개발자 프레임워크를 다루는 웹 개발자이자 컨퍼런스 발표자
“Crates.io가 그 결정을 내리는 데 필요한 메타데이터 일부를 주긴 하지만, 원스톱 샵은 아니잖아요? crates.io에 가서 ‘X를 하려면 어떤 라이브러리를 써야 해?’라고 물으면 그냥 답해주는 식은 아니죠.” -- 연구 소프트웨어 엔지니어
Rust 조직은 역사적으로 생태계의 특정 크레이트를 ‘공식 추천(bless)’하는 데 소극적이었습니다. 하지만 현실적으로 어떤 크레이트들은 사실상 어디에나 존재합니다. 이건 신규 사용자가 탐색하기 특히 어렵습니다:
“튜토리얼에서는
Result<Box<dyn Error>>를 쓰는데—다른 사람들은 아무도 그렇게 안 해요. 다들 anyhow-result를 쓰죠... 저는 result 방식으로 시작했는데, 찾은 정보들은 전부 anyhow 예제 코드였어요. 좀 안 맞았고, 제가 뭘 해야 하는지 몰랐죠.” -- 데이터 사이언스 플랫폼에서 일하는 소프트웨어 엔지니어
“어떤 서드파티 크레이트를 써야 하는지에 대한 명확하게 기록된 합의가 없어요. [..] 가끔은 정말로 불명확해요—CBOR 크레이트는 뭘 쓰죠?[..] 어떤 크레이트가 아직도 활발히 유지보수되는지 보기 어렵고요. [..] crates.io에 크레이트가 너무 많다는 사실 자체가 약간의 리스크가 됩니다.” -- 대형 기술 기업의 Rust 팀
우리는 Rust를 개발할 때 목표로 삼는 바를 정의하는 RFC를 만들 것을 권장합니다. 이 RFC는 Rust를 사용하는 전체 경험(언어, 도구, 라이브러리)을 포괄해야 합니다. 이 RFC는 제안된 사용자 연구 팀이 작성할 수도 있지만, 누가 이를 승인(accept)해야 하는지는 명확하지 않습니다—사용자 연구 팀 자체일 수도 있고, 리더십 카운슬일 수도 있겠지요.
이 글은 Rust의 진정한 “강화의 마법”이 여러 속성을 동시에 달성할 때—신뢰성, 효율성, 로우레벨 제어, 지원성 등—발생한다는 점을 확인했습니다. 커뮤니티가 함께 참조할 수 있고, RFC나 기타 설계 제안을 평가할 때 활용할 수 있는 가치들의 정본(canonical) 목록이 있다면 유용할 것입니다.
이 작업에 참고할 만한 이전 시도들도 여럿 있습니다(예: Tyler Mandry의 글, Rustacean Principles, Rust Design Axioms). 우리의 연구에서 얻은 한 가지 통찰은, 어떤 가치가 “가장 중요하다”를 정할 필요가 없다는 것입니다. Rust가 진짜로 잘 동작하려면 모든 요소를 동시에 달성해야 합니다. 순위를 매기기보다는 다음 경우에 어떤 느낌인지 설명하는 것이 도움이 될 수 있습니다:
이 “골디락스(goldilocks)” 프레이밍은 사람들에게 자신이 어디에 있는지 인식하게 하고, 잘못된 위계질서를 만들지 않으면서 방향을 수정하게 도와줍니다.
우리는 핵심 전략으로 확장성에 더 집중(double down) 할 것을 권장합니다. 트레이트, 매크로, 연산자 오버로딩 같은 Rust의 확장성은 범용성의 핵심이었습니다. 하지만 현재 그 확장성은 특정 영역—타입 시스템과 초기 단계의 proc macro—에 집중되어 있습니다. 이를 지원적인 인터페이스(크레이트가 더 나은 진단과 가이드를 제공) 와 컴파일 워크플로(크레이트가 빌드 과정의 더 많은 단계에 통합) 로 확장해야 합니다.
Rust의 확장성은 Rust가 범용성을 달성하는 중요한 요소이며, 그 범용성은 사람들이 Rust를 사랑하는 이유의 큰 부분입니다. proc macro, 트레이트 시스템, 빌림 검사기 같은 메커니즘을 활용해 Rust 크레이트는 고수준의 우아한 인터페이스를 제공하면서도 효율적인 머신 코드로 컴파일될 수 있습니다. 최고로 잘 맞아떨어질 때는, 약간 마법처럼 느껴지기도 합니다.
안타깝게도 Rust는 크레이트가 안전하고 효율적인 추상화를 만들 수 있는 좋은 도구는 제공하지만, 지원적인(supportive) 추상화를 가능하게 하는 도구는 제공하지 못합니다. Rust 내장 개념에 대해서는 사용자를 성공으로 이끄는 효과적인 에러 메시지를 만들기 위해 노력했고, 흔한 실수를 잡거나 중요한 규칙을 강제하는 린트도 컴파일러에 포함시켜 배포합니다. 하지만 크레이트는 이러한 혜택을 거의 받지 못합니다. RFC #3368처럼 diagnostic 네임스페이스와 #[diagnostic::on_unimplemented]를 도입한 RFC를 통해 Rust는 이미 이 방향으로 움직이기 시작했습니다. 우리는 이를 계속 이어가고 더 나아갈 기회를 찾아야 합니다. 특히 DSL 같은 인터페이스를 만들기 쉬운 proc macro 영역에서는 더더욱 그렇습니다.
확장성의 또 다른 큰 과제는 빌드 시스템과 백엔드에 관한 것입니다. Rust의 현재 확장 메커니즘(예: build.rs, proc macro)은 컴파일 과정의 초기 단계 에 집중되어 있습니다. 그러나 상호운용성(interop), 정리 증명(theorem proving), GPU 프로그래밍, 분산 시스템 등 다양한 Rust 확장 시나리오는 컴파일 과정의 다른 단계에도 통합할 수 있으면 이득이 큽니다. Stable MIR 프로젝트와 build-std 프로젝트 목표는 이런 작업의 예입니다.
확장성에 더 집중하는 것은 현재의 Rust를 더 쉽게 쓰게 해줄 뿐 아니라, Rust를 새로운 도메인에서 사용할 수 있게 하고 그 사용을 지원할 것입니다. 특히 안전이 중요한(safety critical) 애플리케이션은 관련 표준을 충족하기 위해 많은 커스텀 린트와 도구가 필요합니다. 컴파일러 확장성은 Rust가 이런 틈새 요구를 더 일반적인 방식으로 지원할 수 있게 해줍니다.
우리는 사용자가 crates.io 생태계를 탐색하는 데 도움을 주는 방법을 찾을 것을 권장합니다. 오늘날 관용적인 Rust는 에러 처리부터 async 런타임까지 모든 것에서 커스텀 크레이트에 의존합니다. 생태계에 기대는 것은 Rust가 더 많은 도메인으로 확장되는 데 도움이 되고, 혁신적인 접근법이 발견될 수 있게 합니다. 하지만 어떤 크레이트를 써야 하는지 찾는 것은 시작 단계에서 큰 장애물입니다. Rust 조직은 신중하게 중립적인 입장을 유지하고 있는데, 이는 좋지만 사람들이 ‘입문용 스타터 세트’ 크레이트에 대한 조언을 얻을 곳이 없다는 뜻이기도 합니다.
여기서의 정답은 명확하지 않습니다. 표준 라이브러리를 확장하면 추가 실험을 가로막을 수 있고, 크레이트를 ‘공식 추천’하는 것은 정치적 리스크를 수반합니다. 그러나 올바른 해결책이 어렵다고 해서 문제를 무시해야 한다는 뜻은 아닙니다. Rust는 오래된 트레이드오프에 대해 창의적인 해법을 탐색해온 역사가 있으며, 이 문제에도 그 에너지를 가져와야 합니다.
해결책의 일부는 라이브러리 간 상호운용성(interop)을 더 잘 가능하게 하는 것입니다. 이는 핵심 상호운용 트레이트(특히 async)를 추가하거나, 표준적인 빌딩 블록(예: HTTP 라이브러리를 위한 타입 정의를 제공하는 http 크레이트)을 공식화하는 방식으로 나타날 수 있습니다. 일관성(coherence) 규칙 변경도 도움이 될 수 있는데, 현재 규칙은 생태계에서 새로운 상호운용 트레이트를 도입하고 점진적으로 채택하는 것을 허용하지 않기 때문입니다.
이 글의 핵심을 정리하면:
2025년에는 Rust 사용자 중 72%가 계속 사용하고 싶다고 답했습니다. 과거에는 Rust가 다른 어떤 언어보다도 훨씬 높은 점수를 받았지만, 올해는 Gleam이 70%로 아주 근접했습니다! 잘했네요! Gleam은 멋져 보입니다—그리고 fn 키워드 선택도 좋은 선택입니다. ;) ↩
그리고, 어, 우리가 어떻게 하면 그걸 망치지 않을 수 있을까요? ↩
...잠을 덜 자고 일하는 숙련 개발자에게도요. 그들은 종종 초보자와 꽤 비슷하게 행동하거든요. ↩
