왜 요즘 프로젝트는 Go 대신 Rust로 만들어지는가

최근 시스템 프로그래밍과 인프라 도구 영역에서 흥미로운 변화가 관찰되고 있다. 전통적으로 이 분야의 절대 강자였던 Go(Golang) 대신 Rust를 선택하는 신규 프로젝트가 급격히 늘어나는 추세다. 단순히 언어의 인기가 높아서일까, 아니면 기술적인 필연성이 작용하고 있는 것일까.

먼저 눈에 띄는 실사례들을 살펴보자. AWS의 서버리스 인프라를 지탱하는 Firecracker는 보안과 초경량성을 위해 Rust로 개발되었다. 컨테이너 런타임인 Deno는 Node.js의 한계를 넘기 위해 핵심 엔진을 Rust로 구축했고, 서비스 메시 도구인 Linkerd는 성능 오버헤드를 줄이기 위해 프록시 계층을 Go에서 Rust로 전면 재작성했다. 이외에도 ripgrep, bat, fd와 같이 기존 유닉스 도구를 대체하는 고성능 CLI 툴들도 대거 Rust의 힘을 빌리고 있다.

Go와 Rust는 각기 다른 철학을 지닌다. Go의 핵심 가치는 단순함과 생산성이다. 가비지 컬렉터(GC)를 통해 메모리 관리를 자동화하고, 고루틴과 채널이라는 강력한 추상화로 동시성 프로그래밍을 쉽게 만들었다. 반면 Rust는 안전성과 성능에 타협하지 않는다. GC 없이 소유권(Ownership) 시스템을 통해 컴파일 시점에 메모리 안전성을 보장하며, C/C++ 수준의 하드웨어 제어 능력을 제공한다.

과거에는 이 두 언어 사이의 선택 기준이 명확했다. '빠르게 만들고 협업하기 좋은 도구’가 필요하면 Go를, '실수가 용납되지 않는 극한의 성능과 안전성’이 필요하면 Rust를 선택했다. 하지만 최근에는 그 균형추가 Rust 쪽으로 더 많이 기우는 느낌이다. 그 이유는 인프라 시스템이 점점 더 거대해지고 정밀해지면서, GC로 인한 미세한 지연 시간(Latency)조차도 시스템 전체의 성능 병목으로 작용하기 시작했기 때문이다.

여기에 결정적인 변수가 하나 더 추가되었다. 바로 AI 코딩의 등장이다. 필자가 관찰한 바에 따르면, Rust의 가장 큰 진입 장벽이었던 '학습 곡선’이 AI 덕분에 급격히 낮아졌다.

과거에는 빌림 검사기(Borrow Checker)가 내뱉는 난해한 에러 메시지 앞에서 좌절하고 다시 익숙한 Go로 돌아가는 엔지니어가 많았다. 하지만 이제는 Claude나 Gemini 같은 AI 모델이 복잡한 수명 주기(Lifetime) 문제를 실시간으로 해석해주고, 안전한 리팩토링 코드를 제안한다. 'Rust는 어렵다’는 이유로 포기하던 시대는 끝났다. 이제는 AI라는 든든한 조수와 함께 Rust의 모든 장점을 온전히 누릴 수 있게 된 것이다.

결국 최근의 Rust 열풍은 기술적 우수성에 AI라는 실질적인 생산성 도구가 결합된 결과라고 생각한다. 인프라의 복잡도가 높아질수록 Rust가 제공하는 '컴파일 시점의 확신’은 더욱 소중해질 것이며, AI는 그 확신으로 가는 길을 더 평탄하게 만들어줄 것이다.