https://nimfsoft.art/ko/books/deconstructing-the-rust-discourse/#1%EB%B6%80-%EB%9F%AC%EC%8A%A4%ED%8A%B8%EC%9D%98-%EB%93%B1%EC%9E%A5%EA%B3%BC-%EA%B8%B0%EC%88%A0%EC%A0%81-%ED%8A%B9%EC%A7%95

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


1. 러스트 언어 소개 및 주요 특징


이 장은 러스트의 특징을 단순히 나열하기보다, 연구 질문 RQ1과 RQ2의 출발점이 되는 두 문제를 검토합니다. 첫째, 러스트가 시스템 프로그래밍에서 해결하려 한 결함과 비용은 무엇인가. 둘째, 소유권·빌림·생명주기·타입 시스템과 무비용 추상화가 제공하는 보증은 어디까지이며 어떤 상충 관계를 수반하는가.


이를 위해 언어의 설계 목표, 명세상 보증, 컴파일러와 라이브러리의 구현, 실제 워크로드에서 관측되는 결과를 구분합니다. 소유권과 빌림, 무비용 추상화, 타입과 패턴 매칭, Cargo 생태계를 차례로 살펴보되, 특정 설계 목표를 모든 프로그램의 성능이나 안전성에 관한 보편적 결과로 확대하지 않습니다. 산업 도입 성과와 변경 전략은 뒤의 장에서 별도의 증거 기준으로 다룹니다.


1.1 탄생 배경: ‘성능’과 ‘안전성’의 상충 관계


시스템 프로그래밍에서는 하드웨어 제어, 예측 가능한 자원 관리, 처리량과 지연 시간, 메모리 안전성, 동시성 오류 방지가 동시에 요구될 수 있습니다. 다만 이를 단순히 ‘성능 아니면 안전성’의 양자택일로 표현하면 역사적 선택지를 지나치게 축소합니다. C와 C++는 저수준 제어와 수동 자원 관리를 중심으로 발전했고, Ada/SPARK는 강한 타입과 런타임 검사, 계약과 정형 검증을 결합해 왔으며, GC 기반 언어는 자동 메모리 회수와 관리형 런타임을 사용합니다. 어느 접근이 적합한지는 결함 모델, 실시간성, 워크로드, 운영 환경과 검증 요구에 따라 달라집니다.


러스트는 Mozilla Research에서 시작되었으며, 메모리 안전성, 동시성, 저수준 제어와 성능을 함께 추구하는 시스템 프로그래밍 언어로 발전했습니다.https://nimfsoft.art/ko/books/deconstructing-the-rust-discourse/#fn:rust-origin-and-goals">2 여기서 ‘GC 없이 메모리 안전성을 제공하고 C++와 경쟁할 수 있는 성능을 지향한다’는 설명은 설계 목표와 가치 제안입니다. 모든 러스트 프로그램이 모든 C++ 프로그램과 같은 성능을 낸다거나, 런타임 비용과 실패가 사라진다는 보편적 보증은 아닙니다. 따라서 다음 세 목표도 설계 목표, 언어 보증, 구현 특성과 관측 결과를 구분하여 읽어야 합니다.


안전성 (safety)


Safe Rust는 소유권, 빌림과 타입 규칙을 통해 특정한 잘못된 메모리 접근과 데이터 경쟁을 방지합니다. 이 보증은 컴파일러와 라이브러리, unsafe로 구현된 추상화와 FFI 경계가 각자의 계약을 지킨다는 전제 위에서 성립합니다.https://nimfsoft.art/ko/books/deconstructing-the-rust-discourse/#fn:rust-safety-boundary">3panic, 교착 상태, 자원 누수와 고갈, 논리 오류, 모든 보안 취약점 또는 서비스 연속성까지 자동으로 보증하지는 않습니다. 정확한 보증 경계는 1.2절과 3.2절에서 구체적으로 검토합니다.


성능 (performance)


러스트는 필수 가비지 컬렉터 없이 네이티브 코드를 생성하고, 고수준 추상화가 피할 수 있는 추가 런타임 비용을 요구하지 않도록 설계하는 무비용 추상화 원칙을 채택했습니다.https://nimfsoft.art/ko/books/deconstructing-the-rust-discourse/#fn:rust-zero-cost-abstraction">4 이 원칙은 모든 추상화가 언제나 같은 속도를 낸다는 뜻이 아니며, 컴파일 시간, 바이너리 크기, 메모리 사용량, 디버깅 난이도와 개발자의 인지 비용이 0이라는 뜻도 아닙니다. 실제 성능은 워크로드, 알고리즘, 최적화, 할당, 입출력, 라이브러리와 하드웨어 조건을 명시하여 측정해야 합니다.


동시성 (concurrency)


Safe Rust의 소유권과 타입 시스템은 데이터 경쟁을 방지하지만, 일반적인 경쟁 조건, 교착 상태, 기아, 우선순위 역전이나 분산 시스템의 일관성 문제까지 제거하지는 않습니다.https://nimfsoft.art/ko/books/deconstructing-the-rust-discourse/#fn:rust-concurrency-boundary">5 따라서 ‘두려움 없는 동시성’은 모든 동시성 결함의 부재가 아니라, 특정 메모리 안전성 위반과 데이터 경쟁을 컴파일 단계에서 차단하는 범위가 정해진 표현으로 해석해야 합니다.


이 장에서 중요한 출발점은 러스트가 안전성, 성능과 동시성을 하나의 설계 안에서 함께 추구한다는 사실과, 그 목표가 곧 모든 환경의 관측 결과를 뜻하지는 않는다는 구분입니다. 다음 절부터는 소유권과 빌림이 제공하는 구체적 보증, 허용하지 않는 유효한 프로그램, 런타임 검사와 구현 의존성, 다른 설계와의 상충 관계를 차례로 검토합니다.


-------------------------


1. 런타임이 객체의 도달 가능성 등을 추적하여 더 이상 사용되지 않는 메모리를 자동으로 회수하는 메모리 관리 기법 https://nimfsoft.art/ko/books/deconstructing-the-rust-discourse/#fnref:gc">


2. Rust Core Team, Laying the foundation for Rust’s future; Aaron Turon, Abstraction without overhead: traits in Rust. 전자는 러스트가 Mozilla Research 프로젝트로 시작된 역사와 독립 프로젝트로의 전환을 설명하고, 후자는 메모리 안전성·데이터 경쟁 방지·추상화 비용이라는 설계 축을 설명합니다. https://nimfsoft.art/ko/books/deconstructing-the-rust-discourse/#fnref:rust-origin-and-goals">


3. The Rust Reference, Behavior considered undefined 및 Behavior not considered unsafe; The Rustonomicon, How Safe and Unsafe Interact. 공식 문서도 unsafe 계약의 soundness 책임, 미완성인 의미 규칙, 교착 상태·자원 누수·논리 오류가 메모리 비안전성과 구별된다는 점을 명시합니다. https://nimfsoft.art/ko/books/deconstructing-the-rust-discourse/#fnref:rust-safety-boundary">


4. Aaron Turon, Abstraction without overhead: traits in Rust. 이 글은 무비용 추상화를 러스트 설계의 핵심 원칙으로 설명하지만, 특정 프로그램의 성능 결과를 보편적으로 보증하지는 않습니다. https://nimfsoft.art/ko/books/deconstructing-the-rust-discourse/#fnref:rust-zero-cost-abstraction">


5. The Rustonomicon, Data Races and Race Conditions; The Rust Programming Language, Using Threads to Run Code Simultaneously. 공식 문서는 Safe Rust가 데이터 경쟁을 방지하지만 일반 경쟁 조건과 교착 상태는 별개의 문제임을 구분합니다. https://nimfsoft.art/ko/books/deconstructing-the-rust-discourse/#fnref:rust-concurrency-boundary">