https://nimfsoft.art/ko/books/deconstructing-the-rust-discourse/

님프소프트 - 러스트 담론을 해체하다님프소프트 - 러스트 담론을 해체하다nimfsoft.art



사례 연구 6: ‘러스트 외에는 대안이 없다’와 요구사항의 생략


상황: 한 온라인 게시판에서 “배포 환경을 마음대로 정할 수 없는 실전 프로젝트에서는 C++을 사용할 자신이 없으며, 러스트 말고는 대안이 없다”는 취지의 주장이 제시되었습니다. 이 주장은 C++의 메모리 안전성 위험과 배포 제약을 근거로 러스트의 유일성을 결론짓습니다.


논증 구조: 주장을 단순화하면 다음과 같습니다.


  1. C++은 메모리 안전 언어가 아니므로 실전 프로젝트에서 선택하기 어렵다.
  2. 배포 환경에는 제약이 있다.
  3. 따라서 러스트 외에는 대안이 없다.


첫 번째 전제가 특정 프로젝트에서 C++을 제외할 충분한 이유가 될 수는 있습니다. 그러나 한 후보를 제외했다는 사실은 다른 모든 후보가 제외되었다는 뜻이 아닙니다. 세 번째 결론을 정당화하려면 적어도 다음 사항이 추가로 제시되어야 합니다.


  • 대상 시스템의 성능, 지연 시간, 메모리, 실시간성, 인증과 지원 플랫폼 요구사항
  • GC나 VM, 관리형 런타임의 허용 여부와 단일 바이너리·정적 링크 등 실제 배포 조건
  • 기존 코드, 라이브러리, ABI, 운영 도구와 조직 인력의 제약
  • 비교할 후보 집합과 각 후보를 같은 기준으로 제외한 근거


이 조건에 따라 후보는 달라집니다. 관리형 런타임이 허용되는 백엔드나 업무 시스템이라면 Java, C#, Go, Python, Ruby 등이 후보가 될 수 있습니다(3.5절). GC 없는 네이티브 실행과 컴파일 시점 메모리 안전성이 핵심이면 러스트가 강력한 후보이며, 강한 런타임 검사·예측 가능한 실시간성·정형 검증이 중요하면 Ada/SPARK도 검토 대상이 됩니다(3.4절). 기존 C/C++ 자산이 크다면 동일 언어 현대화, 위험 모듈 격리, 선택적 러스트 도입과 혼합 언어 구조도 대안입니다(3.3절). 플랫폼과 생태계에 따라 Swift 등 다른 언어가 적합할 수도 있습니다.


또한 ‘실전 프로젝트’는 요구사항이 아니라 수사적 범주입니다. 웹 서비스, 데스크톱 애플리케이션, 임베디드 장치, 운영체제 커널, 금융 시스템과 안전 필수 제어 시스템은 모두 실전이지만 결함 모델과 배포 조건이 다릅니다. ‘실전’이라는 말로 이 차이를 지우면 특정 경험에서 얻은 판단이 모든 프로젝트의 규칙으로 확대됩니다.


배포 제약 역시 러스트를 자동으로 선택하게 하지 않습니다. 런타임 설치가 금지된 환경에서는 러스트가 유리할 수 있지만, JVM이나 .NET만 승인된 조직, 특정 ABI와 공급업체 툴체인이 고정된 장치, 인증된 Ada 도구 체인이 요구되는 시스템에서는 다른 선택이 더 현실적일 수 있습니다. 배포 제약이 강할수록 새 언어와 툴체인의 도입 자체가 추가 제약이 될 가능성도 검토해야 합니다.


판정 기준: “러스트 외에는 대안이 없다”는 강한 명제를 입증하려면 (1) 요구사항을 명시하고, (2) 현실적인 후보 집합을 구성하며, (3) 모든 후보에 같은 비교 기준을 적용하고, (4) 러스트가 그 요구사항을 충족하는 동시에 다른 후보는 충족하지 못함을 보여야 합니다. 이러한 비교 없이 C++에 대한 불안과 불명확한 배포 제약만 제시한다면, 결론은 러스트의 유일성을 입증하기보다 후보 집합의 생략과 거짓 양자택일을 보여줍니다.


보다 정확한 주장은 다음과 같습니다.


GC 없는 네이티브 실행, 강한 정적 메모리 안전성, 대상 플랫폼 지원과 조직의 유지보수 역량이 동시에 필요하고 다른 후보가 해당 조건을 충족하지 못하는 프로젝트라면 러스트는 가장 강한 선택지가 될 수 있습니다. 그러나 그 조건과 비교가 제시되기 전에는 ‘유력한 선택지’와 ‘유일한 대안’을 구분해야 합니다.