Rust의 과제는 단순한 가파른 학습 곡선으로 요약되지 않습니다. 컴파일 성능, borrow checker, async 복잡성, 생태계 탐색, 그리고 도메인별 제약이 어떻게 생산성과 도입에 영향을 주는지 살펴보고, 이를 해결하기 위한 권고를 제시합니다.
2026년 3월 20일 · Vision Doc group을 대표하여 Jack Huey
Rust의 과제를 이해하기 위해 이야기를 듣기 시작했을 때, 우리는 borrow checker의 학습 곡선과 어쩌면 생태계의 몇 가지 공백에 대한 이야기를 들을 것이라고 예상했습니다. 물론 실제로도 그랬습니다. 아주 많이요. 하지만 물론, 현실은 그것보다 더 미묘했습니다.
통념은 Rust의 학습 곡선이 가파르지만, 일단 "감이 오면" 그다음부터는 순항한다는 것입니다. 우리가 발견한 것은, 경험이 쌓이면 어떤 과제는 사라지지만 다른 과제로 대체된다는 점입니다. 초보자는 ownership 개념으로 어려움을 겪고, 숙련자는 도메인별 과제에 직면합니다. 네트워크 개발자는 async 복잡성을, 안전 필수 팀은 인증 공백을, 임베디드 개발자는 생태계 성숙도 문제를 마주합니다.
하지만 이것이 모두 비관적인 이야기만은 아닙니다. 결국 우리는 Rust의 과제에도 불구하고, Rust가 여전히 필요하고 또 원해지는 언어라는 점을 확인했습니다.
[Rust를 더 낫게 만들기 위해] 제시된 모든 일이 이루어진다면 저는 행복한 Rust 프로그래머가 될 겁니다. 그렇지 않더라도 저는 여전히 Rust 프로그래머일 겁니다. -- 성능 향상을 위해 Rust를 도입하는 엔지니어링 매니저
경험 수준이나 도메인과 상관없이, 모든 인터뷰에서 우리는 동일한 핵심 과제 집합에 대해 들었습니다. 이것들은 사라지는 초보자 문제들이 아니라, 개발자가 성장함에 따라 다른 방식으로 나타나는 근본적인 마찰 지점들입니다.
우리가 분석한 모든 집단—초보자부터 전문가까지, 임베디드 개발자부터 웹 개발자까지—은 컴파일 시간이 생산성에 대한 중요한 장벽이라고 언급했습니다.
"Java는 대략 100밀리초가 걸리고, Rust는 무엇을 바꿨는지에 따라 5초에서 1분까지 걸립니다" -- 대기업에서 백엔드 시스템을 다루는 수석 엔지니어
"8초에서 10초 반복 주기... 박스의 패딩을 조정하고 싶을 때 말이죠" -- GUI 개발 팀
영향은 도메인에 따라 다르지만, 패턴은 일관됩니다. 빠른 반복 주기가 필요한 CLI 도구와 GUI 개발자가 가장 큰 타격을 받습니다. 25~30분의 빌드 시간을 겪는 안전 필수 개발자는 작업 흐름이 크게 방해받습니다. 크기 제약이 있는 임베디드 개발자는 컴파일 시간이 더 길고 디버깅도 복잡하게 만드는 최적화 빌드를 강요받습니다.
특히 중요하게 짚어야 할 점은, 이것이 단순히 절대적인 빌드 시간의 문제가 아니라는 것입니다. 시간이 지날수록 누적되는 개발 속도 세금의 문제입니다. 긴 컴파일 시간은 코드 반복 시간에 강한 부정적 영향을 줄 수 있습니다. 핫 리로딩, 빠른 디버그 빌드, 더 빠른 링킹처럼 코드 반복 시간을 줄일 수 있는 모든 것은 개발 속도에 매우 큰 영향을 미칠 것입니다.
더 나아가, 컴파일 성능에 대한 세금은 규모가 커질수록 더 누적됩니다. 개별 개발자는 5~10초 빌드를 참을 수 있을지 몰라도, CI/CD 파이프라인, 대규모 코드베이스, 잦은 반복 작업을 가진 팀은 기하급수적으로 더 나쁜 영향을 받습니다. 한 참여자는 "도구가 내가 실수했다는 걸 알아내기 전에 30분을 기다리는" 25~30분 빌드 주기를 언급했습니다.
borrow checker는 흔히 "초보자 문제"로 이야기되며, 우리가 확인한 바로도 대체로 그렇습니다. 초보자는 borrow checker의 영향을 가장 크게 받지만, 이 영향은 개발자가 Rust를 편하게 작성하는 단계까지도 종종 이어져, 그 단계에서도 여전히 가끔 borrow checker에 걸려 넘어지곤 합니다.
하지만 Rust 경험이 매우 많은 개발자들은 borrow checker 자체를 거의 좌절 요인으로 언급하지 않습니다.
Ownership: 그 장을 처음 읽었을 때 저는 정말로, 이게 뭐지? 싶었습니다. - Rust를 첫 언어로 배우는 개발자
저는 Rust를 오랫동안 작성하고 나서야 비로소 borrow checker를 이해했습니다 - 개발자 도구 회사의 임원
여러 참여자가 async를 고충 지점으로 지목했습니다. 많은 사람이, 초보자뿐만 아니라, 아예 그것을 완전히 피하고 대신 sync Rust에만 집중하곤 합니다. 많은 이들에게 async Rust는 완전히 다른 것처럼 느껴지기 때문입니다.
Rust에 대한 제 가장 큰 불만은 async입니다. [어떤 도구]를 쓰려면 우리는 그 모델을 강제로 써야 합니다... 단지 다른 언어가 아니라, 다른 프로그래밍 모델입니다... 저는 경험이 전혀 없어서, 계속 피하고 있습니다. - 대기업에서 보안 에이전트를 개발하는 개발자
물론 실제로 그것을 사용하는 사람들은 종종 그것이 얼마나 복잡한지, 어떤 면에서는 미완성처럼 느껴지는지, 또는 배우기 얼마나 어려운지 이야기합니다.
"async이고 generic이며 lifetime도 있는 Rust를 다루게 되면, 그 타입들은 너무 복잡해져서 사실상 Rust의 신 같은 사람이 되어야 합니다" -- 프로덕션 Rust 경험이 있는 소프트웨어 엔지니어
"제 전반적인 인상은 사실 꽤 부정적입니다. 덜 구워진 느낌이에요... 알아야 할 난해한 지식이 많습니다" -- 연구 소프트웨어 엔지니어
"기본적인 Rust와 async 프로그래밍 사이에는 상당한 학습 격차가 있습니다... 이 격차를 넘으려면 상당한 투자가 필요한 '슬픔의 협곡'이 생깁니다." -- 전문 개발자
async 복잡성은 개별 개발자 경험만의 문제가 아닙니다. 이는 생태계 분절화와 아키텍처 잠금 효과로 인해 더 악화됩니다.
"여전히 이런 상황이 많다는 사실이 문제입니다. 저 라이브러리가 유용해 보이니 써야겠다고 생각하는 순간, 바로 tokio나 다른 런타임 가운데 하나에 묶이게 됩니다" -- 커뮤니티 중심 개발자
이러한 분절화는 아키텍처 결정을 초기에 강요하고 라이브러리 호환성을 제한하여, 프로그래밍 언어들 사이에서도 독특한 도전 과제를 만듭니다.
물론, 많은 사람이 언급된 과제들에도 불구하고 async에 대해 긍정적인 감정을 표현한다는 점 역시 분명히 해둘 필요가 있습니다.
Rust 생태계는 도메인별로 고르지 않은 성숙도를 보입니다. CLI 도구와 웹 백엔드에는 매우 훌륭하지만, 임베디드나 안전 필수 애플리케이션 같은 다른 도메인에서는 상당히 부족합니다. 이는 Rust의 평판이 도메인에 따라 극적으로 달라지는 분절된 도입 환경을 만들어 냅니다.
"사람들이 Rust를 쓰지 않는 가장 큰 이유는, 들어가게 될 생태계가 기대와 다르기 때문입니다. C++가 가진 도구도, 라이브러리도 없습니다." -- 대형 기술 기업의 개발자
"선택지가 많다는 점이 오히려 올바른 선택을 하기를 어렵게 만든다고 생각합니다" -- 고수준 언어에서 전환 중인 개발자
"써야 할 crate들이 잘 발견되지 않습니다... 특정 용도에 어떤 crate를 써야 하는지에 대한 암묵적 지식의 층이 있고, 그런 건 경험을 통해 쌓이게 됩니다" -- 웹 개발자
문제는 라이브러리가 부족하다는 것이 아니라, 올바른 것을 고르려면 초심자에게 없는 전문성이 필요하다는 점입니다.
다만 Rust Project는 대체로 이를 의도적으로 선택해 왔습니다. 혁신을 부당하게 억누르지 않기 위해 특정 crate에 공식적인 지위를 부여하지 않기로 한 것입니다. 기대는, 새 crate가 어떤 잘 자리 잡은 crate보다 "더 좋다"면 그 새 crate가 더 인기를 얻게 되어야 한다는 것입니다. 그러나 Project가 더 확립된 crate 사용을 권장하면, 그렇게 될 가능성은 줄어듭니다. 이것은 재검토할 가치가 있는 절충일 수도 있고, 혹은 영리한 해결책을 찾을 수도 있습니다.
핵심 과제는 보편적이지만, 각 도메인은 궁극적으로 도입을 가로막는 요인 또는 감수 가능한 절충이 될 수 있는 고유한 과제를 가지고 있습니다.
임베디드 개발자는 자원 측면에서 가장 제약이 큰 환경에 놓여 있으며, 이는 학습과 같은 다른 과제를 증폭시킬 수 있습니다.
"crate를 하나 가져오면, 많은 것들이 함께 따라오고 그것을 통제할 수 없습니다" -- 임베디드 시스템 연구자
"hashmap 같은 표준 컬렉션을 사용할 수 없습니다" -- 임베디드 소프트웨어 엔지니어
디버그 빌드는 소형 컨트롤러에는 너무 커져서, 개발자는 디버깅을 복잡하게 만드는 최적화 빌드를 사용할 수밖에 없습니다. 크로스 컴파일은 또 다른 복잡성 계층을 더합니다. 성장하고는 있지만, "no-std" 생태계에는 여전히 상당한 공백이 있습니다.
안전 필수 개발자는 Rust의 메모리 안전성 보장을 필요로 하지만, 인증과 도구를 둘러싼 고유한 과제에 직면합니다.
"C++에서 하듯이 안전 필수성을 측정할 수 있는 같은 도구가 우리에게는 없고, 그 점이 우려 지점이라고 생각합니다" -- 안전 시스템 엔지니어
"Rust를 아는 사람이 많지 않고, 많은 관리자는 이것이 오래 갈 기술이라고 실제로 신뢰하지 않습니다" -- 조직적 장벽에 대해 이야기하는 안전 필수 개발자
Rust의 빠른 진화와 안정성을 요구하는 안전 필수 분야의 요구사항 사이의 긴장은, 기술적 이점이 분명할 때조차 도입 장벽을 만듭니다.
참고로, 우리는 이전에 안전 필수 Rust 전체를 다룬 블로그 글을 작성했습니다. 꼭 읽어보세요!
GUI 개발자는 빠른 시각적 피드백이 필요하므로, 컴파일 시간이 특히 더 고통스럽습니다.
우리에게는 그냥 Rust 코드로 된 UI 프레임워크가 있어서, 박스의 패딩을 조정하고 싶을 때마다 ... 10초 이상 반복 주기를 그냥 받아들이는 것이 고통스럽습니다. -- GUI 앱을 개발하는 개발자
이 작업을 통해 얻은 중요한 통찰 하나는, 곰곰이 생각해 보면 당연한 이야기이기도 하지만, Rust를 배우는 경험은 보편적이지 않다는 점입니다. 당신의 배경에 크게 좌우됩니다.
고수준 언어 개발자는 Rust와 함께 시스템 개념도 배워야 합니다.
저에게 어려웠던 점은 더 저수준의 컴퓨터 과학 개념과 Rust를 동시에 이해해야 했다는 것입니다. -- Typescript 배경의 개발자
저수준 개발자는 기존 패턴과 개념을 내려놓는 데 종종 어려움을 겪습니다.
저는 C++ 세계에서 왔기 때문에 모든 것을 처리하는 거대한 클래스를 가지고 있었어요. "한 단계 내려가야 해"라는 것을 체화하는 데 시간이 좀 걸렸습니다. -- C++ 배경의 개발자
Rust는 포인터라는 개념을 감추려 했습니다 - 그냥 포인터라고 말해 주세요 -- 시스템 수준 개발자
하지만 흥미롭게도, Rust를 C++와 함께 배우는 것은 학생들이 둘 다 더 잘 이해하도록 도울 수 있습니다.
학생들은 C++에서 smart pointer를 배우고, 이어서 '이제 Rust에서도 smart pointer를 배우고 있습니다'라고 하죠 — 둘을 동시에 배우면 더 쉬워집니다. -- 커뮤니티 조직자
컴파일 성능이 모든 사용자 집단에 영향을 미친다는 점을 고려하면, 우리는 이를 단순한 구현 세부사항이 아니라 언어 차원의 일급 관심사로 다룰 것을 권고합니다. 여기에는 다음이 포함될 수 있습니다.
이 목표를 염두에 둔 멋진 커뮤니티 프로젝트 몇 가지도 간단히 소개하고 싶습니다.
우리는 이전에 이 영역에서 몇 가지 제안을 한 바 있으며, 그것들은 여전히 유효합니다. 사용자에게 유용한 crate를 찾도록 도울 뿐만 아니라 crate 간 더 나은 호환성을 가능하게 하는 방법을 찾는 것은 분명 Rust 커뮤니티에 순긍정적인 이익을 가져올 것입니다.
누군가 Rust를 배울 때, 그 사람의 프로그래밍 언어 배경, 경험 수준, 그리고 일하려는 도메인은 모두 그 사람이 마주하는 과제에 영향을 줍니다. 우리는 Rust Project와 커뮤니티가 개인의 필요에 맞게 학습 경로를 _조정_할 방법을 찾을 것을 권고합니다. 예를 들어 C나 C++ 배경을 가진 사람에게는 reference를 pointer와 직접 비교할 수 있게 하는 것이 유용할 수 있습니다.
마찬가지로, 도메인 특화 학습 자료는 일반적인 "Rust 튜토리얼"보다 초심자가 자신이 직면한 문제에 더 구체적으로 집중하도록 도울 수 있습니다. 예를 들어 Embedded Rust Book이 그렇습니다.
이것은 쉬운 일이 아닙니다. 여기에는 움직이는 요소가 많지만, 많은 사람이 분명 어려움을 겪고 있다는 점은 명확합니다. 한편으로 async Rust는 몇몇 언어 기능에서 sync Rust와 비교해 종종 "미완성"처럼 느껴집니다. 다른 한편으로 문서는 종종 sync Rust에 초점을 맞추고 있습니다. 예를 들어 The Rust Programming Language Book의 상당 부분은 sync 코드 패턴에 집중합니다.
Rust Project 내부에서는 dyn trait에서의 async 함수처럼 오랫동안 기다려온 기능의 안정화를 추진하거나, 예를 들어 lifetime과 async 코드 문제에 대한 컴파일러 오류를 개선하는 방향으로 작업할 수 있습니다. 또한 std 안에 기본적인 async 라이브러리 trait와 함수를 포함하여, 더 응집력 있는 async 생태계를 가능하게 할 수 있습니다.
물론 Rust Project 내부에서 할 수 있는 일만큼이나, 튜토리얼과 예제 코드 제작에 더 많은 커뮤니티 참여를 이끌어내고, 그 외에도 단지 지식을 공유하는 것만으로도 이 격차를 줄이는 데 큰 도움이 될 수 있습니다.
Rust의 과제는 통상적인 "가파른 학습 곡선"이라는 서사가 시사하는 것보다 더 미묘합니다. 그것들은 도메인에 따라 다르고, 경험에 따라 변화합니다.
이러한 패턴을 이해하는 것은 Rust의 지속적인 성장에 매우 중요합니다. 우리가 Rust의 도달 범위를 넓혀 가려면, 초기 학습 곡선만이 아니라 모든 경험 수준에서 생산성에 영향을 미치는 지속적인 마찰도 해결해야 합니다.
좋은 소식은, 이러한 패턴을 인식하는 것만으로도 개선을 위한 권고를 얻을 수 있다는 점입니다. 전문성의 기울기를 인정하고, 컴파일 성능을 우선시하며, 더 나은 생태계 탐색을 만들고, 배경 의존적 과제를 다룸으로써 우리는 Rust가 모든 사람이 신뢰할 수 있고 효율적인 소프트웨어를 만들 수 있도록 힘을 실어 준다는 약속을 실현하도록 도울 수 있습니다.
[
Rust 팀이 유지 관리합니다. 오타를 발견하셨나요? 여기에서 수정 사항을 보내 주세요!
Rust Blog