왜 지금 러스트인가

채용 공고에서 "Rust 경험 우대"라는 문구를 본 적이 있다면, 그게 최근 몇 년 사이 갑자기 생긴 일이라는 것도 눈치챘을 겁니다. Stack Overflow 개발자 설문에서 Rust는 2016년부터 9년 연속 "가장 사랑받는 언어" 1위를 지키고 있습니다. 이 기록을 가진 언어는 없습니다. 그런데 흥미로운 점은, 같은 설문에서 "가장 배우고 싶은 언어" 순위는 Python이 앞선다는 겁니다. 다들 Rust를 쓰는 사람은 떠나지 않는데, 아직 안 써본 사람은 선뜻 손이 안 간다는 뜻입니다. 이 책은 그 망설임의 정체 — 소유권과 빌림 검사기 — 를 정면으로 다룹니다.

C/C++가 못 한 약속

C와 C++는 강력하지만 대가가 있습니다. 메모리를 다 쓰고 나서 해제를 깜빡하면 누수가 나고, 이미 해제한 메모리를 또 쓰면 use-after-free 버그가 됩니다. 이런 버그의 무서운 점은 컴파일은 멀쩡히 되고, 대부분의 경우 실행도 잘 된다는 겁니다. 문제는 특정 조건에서만, 보통은 운영 환경에 배포되고 나서야 터집니다. 2019년 마이크로소프트는 자사 제품에서 발견된 보안 취약점의 약 70%가 메모리 안전 문제였다고 공개했습니다. 구글 크롬 팀도 비슷한 수치를 발표했고요.

가비지 컬렉터를 쓰는 언어(Java, Go, Python 등)는 이 문제를 런타임에 해결합니다. 안 쓰는 메모리를 런타임이 감시하다가 자동으로 회수합니다. 안전하지만 공짜가 아닙니다 — GC가 도는 동안 프로그램이 멈추는 순간(stop-the-world)이 생기고, 메모리 사용량도 예측하기 어려워집니다. 지연시간에 민감한 시스템(게임 엔진, 임베디드, 고빈도 거래 시스템)에서는 이게 치명적일 수 있습니다.

Rust는 세 번째 길을 택했습니다. 런타임 GC 없이, 컴파일 타임에 메모리 안전을 검증합니다. 컴파일러가 "이 코드는 해제된 메모리를 참조할 가능성이 있다"고 판단하면 아예 컴파일을 거부합니다. 실행 파일에는 검증 로직이 남지 않으니 런타임 비용도 없습니다.

fn main() {
    let data = vec![1, 2, 3, 4, 5];
    let total: i32 = data.iter().sum();
    println!("합계: {}", total);
}

이 코드는 평범해 보이지만, data의 소유권이 누구에게 있고 언제 해제되는지가 컴파일러 머릿속에서 전부 추적되고 있습니다. 앞으로 몇 챕터에 걸쳐 그 추적 규칙을 하나씩 뜯어볼 겁니다.

이 책이 다루지 않는 것

솔직히 말하면 이 책은 Rust 언어 전체를 다루는 책이 아닙니다. 트레잇, 매크로, 제네릭의 세세한 문법, 웹 프레임워크나 임베디드 개발 같은 응용 분야는 다루지 않습니다. 그런 내용은 이미 훌륭한 자료가 많습니다. 이 책이 파고드는 건 딱 하나, Rust를 다른 언어와 근본적으로 다르게 만드는 소유권·빌림·라이프타임 시스템입니다. 이 개념을 넘어서면 나머지 문법은 C 계열 언어를 알고 있다면 상대적으로 수월하게 익힐 수 있습니다. 반대로 이 개념을 건너뛰면 아무리 문법을 외워도 컴파일러와 매번 싸우게 됩니다.

왜 지금인가

리눅스 커널이 2022년부터 Rust 코드를 받아들이기 시작했고, 마이크로소프트는 Windows 커널 일부를 Rust로 재작성하고 있습니다. AWS, 디스코드, 드롭박스는 이미 핵심 인프라에 Rust를 쓰고 있고요. 이건 유행이 아니라 "메모리 버그를 근본적으로 줄이고 싶다"는 업계 전체의 절박함이 만든 흐름입니다. 배우는 데 시간이 걸리는 언어지만, 그 시간에 대한 보상이 분명한 시점이라고 생각합니다.