제목: 러스트의 장점은 사실이지만, “반대자는 저능하다”는 결론은 사실이 아니다

러스트의 장점을 짧게 정리한 부분 자체는 대체로 맞다.

러스트는


  • GC 없이 메모리 안전성을 추구하고
  • 높은 런타임 성능을 목표로 하며
  • Option, Result, 패턴 매칭으로 많은 오류를 컴파일 타임에 드러내고
  • Safe Rust에서 데이터 레이스를 방지하며
  • Cargo로 빌드, 의존성, 테스트, 문서화를 통합한다


좋은 언어고, 강한 장점을 가진다.

문제는 그다음이다.

이 장점들로부터 “러스트의 우월성에 의문을 갖는 사람은 저능하다”는 결론은 나오지 않는다.

첫째, GC 없는 메모리 안전성은 러스트만의 역사적 발명도 아니고, 모든 종류의 안전성을 뜻하지도 않는다.

Safe Rust는 해제 후 사용, 이중 해제, 데이터 레이스 같은 특정 오류를 강하게 막는다. 그러나 unsafe, FFI, 메모리 누수, 자원 고갈, 논리적 오류, 교착 상태는 별도로 다뤄야 한다.

“메모리 안전하다”와 “프로그램 전체가 안전하다”는 같은 말이 아니다.

둘째, “런타임 성능이 압도적”이라는 말은 비교 대상과 워크로드가 없으면 의미가 없다.

무엇보다 빠른가?

C인가, C++인가, Java인가, Go인가?

어떤 컴파일 옵션과 어떤 입력에서 빠른가?

지연 시간인가, 처리량인가, 메모리 사용량인가?

러스트는 매우 빠를 수 있다. 하지만 “항상 압도적”이라는 말은 벤치마크가 아니라 수사다.

셋째, 컴파일 타임 검사는 강력하지만 모든 오류를 잡지 않는다.

Option과 Result, 소진 검사는 분명 좋은 기능이다. 그러나 잘못된 비즈니스 로직, 잘못된 계산, 잘못된 요구사항, 교착 상태, 성능 병목과 장애 복구 실패까지 컴파일러가 해결해주지는 않는다.

넷째, 데이터 레이스 방지와 스레드 문제 전체의 해결은 다르다.

Safe Rust는 데이터 레이스를 막는다.

하지만 교착 상태, 라이브락, 잘못된 동기화 순서, 논리적 경쟁 조건까지 없애지는 않는다.

다섯째, Cargo는 훌륭하지만 개발 환경 전체가 Cargo 하나로 끝나는 것은 아니다.

빌드, 테스트와 의존성 관리가 통합된 것은 큰 장점이다.

하지만 대규모 모노레포, 복잡한 코드 생성, 외부 라이브러리 연동, 디버깅, IDE 기능, 컴파일 시간과 피처 조합 문제는 여전히 존재한다.

그리고 CMake, Gradle, Maven을 한 생태계의 파편화처럼 묶는 것도 이상하다.

CMake는 주로 C/C++, Gradle과 Maven은 JVM 생태계의 도구다. 서로 다른 언어 생태계의 도구 셋을 한데 모아 Cargo 하나와 비교하면 비교 단위부터 맞지 않는다.

러스트는 장점이 많다.

하지만 기술의 장점을 인정하는 것과 모든 상황에서 절대적으로 우월하다고 믿는 것은 다르다.

좋은 개발자는 언어를 숭배하는 사람이 아니다.

보증 범위를 알고, 남는 오류를 알고, 비용을 알고, 프로젝트 조건에 따라 선택하는 사람이다.

그리고 반대자를 저능하다고 부르는 순간 그 글은 기술 설명이 아니라 게이트키핑이 된다.

기술적 우월성을 주장하려면 사람의 지능을 공격할 것이 아니라 비교 조건과 측정 결과를 제시해야 한다.

러스트의 장점은 러스트의 장점이다.

다른 사람의 지능을 판정하는 증거는 아니다.