러스트(Rust)는 등장과 동시에 수많은 개발자의 찬사를 받았다. '메모리 안전성', '두려움 없는 동시성', 'C++에 버금가는 성능'. 이 세 가지 기치 아래, 러스트는 시스템 프로그래밍의 고질적인 문제들을 해결할 구원자처럼 보였다. 7년 연속 스택 오버플로우 설문조사에서 '가장 사랑받는 언어' 1위를 차지한 사실은 그 인기를 증명한다. 오로지 인기만 있다. 실제 사용자는 거의 없다. C/C++ 대비 0.001% 정도의 사용성?? 두려운 없는 동시성이라고 과대성 홍보를 하는데, Ada도 데이터 경쟁을 방지한다. ㅎㅎ 이건 몰랐지? ㅋㅋ

하지만 반짝이는 갑옷은 무겁기 마련이다. 러스트가 제공하는 눈부신 안전성의 대가로 우리가 무엇을 지불해야 하는지, 그 이면의 그림자를 냉정하게 들여다볼 필요가 있다.

1. 가파른 절벽, 그리고 끝나지 않는 싸움

러스트를 배우는 과정은 종종 '가파른 학습 곡선'을 넘어 '절벽'에 비유된다. 그 중심에는 러스트의 핵심 철학이자 가장 큰 장벽인 '소유권(Ownership)'과 '빌림 검사기(Borrow Checker)'가 있다. 이들은 컴파일 타임에 메모리 오류를 원천 차단하는 강력한 수문장이지만, 수십 년간 다른 프로그래밍 패러다임에 익숙해진 개발자에게는 새로운 사고방식을 강요하는 고문관과도 같다.

개발자는 문제 해결에 집중하기보다, 컴파일러의 비위를 맞추기 위해 코드와 씨름하는 자신을 발견하게 된다. 간단한 연결 리스트(Linked List) 구현조차 러스트에서는 고도의 훈련을 요구하는 과제가 된다. 이는 생산성의 급격한 저하로 이어지며, 특히 빠른 프로토타이핑이 중요한 환경에서 러스트는 최악의 선택지가 될 수 있다. 컴파일만 되면 작동한다는 말은, 그 컴파일까지 가는 과정이 얼마나 험난한지에 대한 반증일 뿐이다.

그래서 오죽하면 "고통의 미학"이라는 정신병이 다 생길까? ㅎㅎ 고통 속에서 개발하여 쾌락을 얻는단다.

2. 느린 컴파일, 더딘 개발 속도

러스트의 컴파일러는 수많은 정적 분석을 통해 꼴랑 코드의 메모리 안전성을 보장한다. 하지만 이 철두철미함의 대가는 끔찍하게 느린 컴파일 시간이다. 프로젝트의 규모가 커질수록, 코드 한 줄을 수정하고 결과를 확인하기까지의 시간은 기하급수적으로 늘어난다.

이는 빠른 피드백 루프(코드 수정 → 컴파일 → 테스트)가 생명인 현대 소프트웨어 개발 환경에 치명적인 단점이다. Go 언어의 초고속 컴파일이 주는 경쾌함이나 스크립트 언어의 즉시성에 비하면, 러스트의 개발 경험은 무겁고 답답하게 느껴진다. 개발자는 코딩하는 시간보다 컴파일러가 일하는 것을 기다리는 시간에 더 많은 커피를 마시게 될지도 모른다.

3. 모든 것을 해결해주지는 않는 생태계

crates.io로 대표되는 러스트의 패키지 생태계는 경이로운 속도로 성장했지만, 여전히 성숙한 언어들에 비해 부족한 부분이 매우 많다. 특히 GUI 개발, 데이터 과학, 게임 개발(최근 Bevy 등의 약진이 있지만)과 같은 특정 도메인에서는 라이브러리의 선택지가 좁거나 대부분 검증되지 않은 경우가 많다.

이는 러스트를 '모든 문제를 해결하는 만능 언어'로 채택하기 어렵게 만든다. 사실 불가능한다. 특정 목적을 위해서는 수십 년간 라이브러리와 노하우가 축적된 C++, Java, Python이 훨씬 현실적인 대안이다. 러스트는 웹 백엔드나 CLI 도구와 같은 특정 영역에서는 유용하지만, 그 외의 영역에서는 아직 '미완의 대기'에 가깝다.

4. 복잡성의 그늘: 제2의 C++이 될 것인가?

러스트는 메모리 안전이라는 명확한 목표를 가지고 시작했지만, 언어의 규모는 계속해서 커지고 있다. async/await, const generics, GATs(Generic Associated Types) 등 고급 기능들이 추가되면서 언어 자체의 복잡성은 날이 갈수록 높아지고 있다. 그러면서도 OOP를 반쪽만 지원한다. ㅎㅎ Ada와 극명한 대조를 이루는 부분이다.

이는 C++이 걸어왔던 길을 연상시킨다. 수많은 기능이 추가되면서 언어 전체를 깊이 있게 이해하는 전문가가 드물어지고, 팀 내에서 사용하는 기능의 부분집합(subset)이 달라 코드 스타일이 파편화되는 문제가 발생할 수 있다. 안전성을 위해 도입한 복잡성이 오히려 새로운 종류의 '인지적 부하'를 만들어내는 아이러니가 생기는 것이다. 또한, 안전을 보장할 수 없는 영역을 위해 남겨둔 unsafe 키워드는 러스트의 안전성이라는 신화를 떠받치는 아슬아슬한 기반이다. 결국 성능을 극한으로 추구하는 코드는 unsafe 블록으로 채워지게 되고, 그곳에서는 러스트가 자랑하는 어떤 안전장치도 작동하지 않는다. 러스트가 자랑하는 안전성은 unsafe에서 온다고 해도 과언이 아니다. 실제로 unsafe없이 러스트는 사실상 작동하지 않기 때문이다. unsafe위에 세워진 safe라는 불안한 안전성 신화. 그것도 메모리 안전에만 한정.

제발 타 언어, 타 언어 사용자들을 욕하지 말라.

러스트는 위대한 언어가 아니며, 특히 안정성과 성능이 무엇보다 중요한 시스템 프로그래밍 영역에서는 C/C++, Ada를 쓴다. 하지만 러스트를 선택하는 것은 '빛나는 갑옷'의 무게를 기꺼이 감당하겠다는 결심과 같다. 그래서 '러스트는 위대하다'며 자기 체면을 걸어 인지 부조화를 해소하고 있는 것이다.

가파른 학습 곡선, 느린 개발 속도, 아직도 부족한 생태계, 그리고 점점 커지는 복잡성. 이 모든 비용을 치를 가치가 있는 문제인지 신중하게 저울질해야 한다. 러스트는 위대한 언어가 아니다. 그저 매우 특수하고 강력한 목적을 위해 하나를 얻고 두 개를 잃는 그리고 다루기 매우 어려운 도구일 뿐이다.