툴을 개발하는데 막대한 자본과 시간이 들어가는데

명세가 수시로 바뀌면 어떻게 하겠는가?

그래서 러스트를 지원하는 툴이 별로 없는거다.

반면 c/c++ 지원툴은 엄청 많고.

러스트 담론을 해체하다 책 다시 보셈.

https://nimfsoft.art/ko/blog/2025/07/09/deconstructing-the-rust-discourse/

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

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

nimfsoft.art

3.5 비교 대상의 현실: 진화하는 C++의 다층적 안전망

러스트의 안전성을 강조하는 담론은 종종 C/C++과의 비교를 통해 그 가치를 입증합니다. 이 과정에서 C/C++은 메모리 문제 해결에 실패한 ‘과거의 언어’로 간주되곤 합니다. 하지만 이러한 비교가 타당성을 갖기 위해서는, 비교 대상이 1990년대의 C/C++이 아닌, 수많은 발전을 거듭한 ‘현대의 C/C++ 생태계’가 되어야 합니다.

지난 20여 년간 C++ 언어와 그 생태계는 안전성 확보를 위해 다층적인 접근법을 구축해 왔습니다. 그러나 이러한 안전망은 컴파일러에 내장된 러스트의 보증과 달리, 개발자의 의식적인 선택, 추가적인 비용, 그리고 엄격한 규율을 요구한다는 근본적인 차이점을 가집니다.

1. 언어의 진화: 모던 C++와 스마트 포인터의 ‘선택적’ 안전성

첫째, 언어 자체의 발전입니다. C++11 표준 이후 ‘모던 C++’은, RAII 패턴을 언어 차원에서 적극적으로 지원하는 스마트 포인터(std::unique_ptr, std::shared_ptr)를 표준 라이브러리에 도입했습니다. 이는 자원의 소유권을 명확히 하고 메모리를 자동으로 관리하여, 과거 C++의 고질적인 메모리 관련 문제 상당수를 언어 수준에서 방지하는 효과적인 방법입니다.

그러나 C++에서 스마트 포인터의 사용은 강제되지 않는 ‘모범 사례(best practice)’에 머무릅니다. 개발자는 언제든 원시 포인터(raw pointer)를 사용할 수 있으며, 컴파일러는 이를 막지 않습니다. 즉, 안전성에 대한 최종 책임은 여전히 개발자의 규율에 의존하며, 이로 인해 실수는 계속 발생할 수 있습니다.

2. 도구 생태계의 성숙: ‘비용과 전문성’을 요구하는 다층 방어

둘째, 정적 및 동적 분석을 아우르는 성숙한 도구 생태계의 지원입니다. 오늘날 전문적인 C/C++ 개발 환경은 다음과 같은 자동화된 도구들을 활용하여 안전성을 확보할 수 있습니다.

정적 분석: 컴파일 단계 이전에 코드베이스 전체를 정밀하게 분석하여 잠재적 버그를 찾아내는 Clang Static Analyzer, Coverity, PVS-Studio 등의 도구가 널리 사용됩니다.

동적 분석: 프로그램을 실제 실행하며 메모리 접근을 감시하여, 정적 분석만으로는 포착하기 어려운 미묘한 메모리 오류를 런타임에 탐지하는 Valgrind, 주소 새니타이저(AddressSanitizer)와 같은 도구들이 중요한 안전망 역할을 합니다.

실시간 린팅: Clang-Tidy와 같은 린터(linter)는 개발자가 코드를 작성하는 순간부터 잠재적 오류를 지적하며 실시간 피드백을 제공합니다. 특히 C++ Core Guidelines3의 여러 규칙을 강제하여 더 안전한 코딩 스타일을 유도합니다.

이러한 강력한 도구들은 안전성을 크게 향상시키지만, 강력한 상용 도구들은 종종 고가이며, 올바르게 설정하고 분석 결과를 해석하는 데 상당한 전문성을 요구합니다. 이는 러스트의 공식 툴체인(cargo)이 추가 비용 없이 기본적으로 제공하는 정적 분석 기능과는 접근성과 보편성 면에서 근본적인 차이가 있습니다.

3. 미션 크리티컬 시스템의 접근법: ‘특수 분야’의 엄격한 규율

셋째, 자동차, 항공, 의료 기기와 같이 극도의 신뢰성이 요구되는 ‘미션 크리티컬(mission-critical)’ 시스템 분야에서는 이보다 훨씬 더 엄격한 방법론을 적용합니다.

코딩 표준 강제: MISRA C/C++와 같은 코딩 표준을 통해 위험한 언어 기능의 사용을 원천적으로 금지합니다.

코드 계약 명시: SAL, ACSL 등 애노테이션 언어를 사용하여 코드에 명시적인 ‘계약’을 추가합니다.

정적 검증 수행: Polyspace, Frama-C와 같은 정적 코드 검증(static code verification) 도구를 통해 런타임 오류 가능성을 수학적으로 검증합니다.

컴파일러 검증(compiler validation) 수행: 항공(DO-178C)이나 자동차(ISO 26262)와 같은 안전 표준에서는, 컴파일러가 소스 코드를 올바르게 기계 코드로 변환했음을 증명하는 과정을 요구합니다. 이는 Ada나 C/C++ 생태계에서 전문 벤더가 제공하는 ‘검증 키트(Qualification Kit)’를 통해 이루어지며, 언어의 표준화와 성숙한 상업적 생태계가 있기에 가능합니다. 이와 대조적으로, 러스트는 아직 이러한 공식적인 안전 표준 인증(예: ISO 26262)을 지원하는 도구 및 벤더 생태계가 C/C++만큼 성숙하지 않다는 현실적 한계를 가집니다 (7.2절 참고).

이러한 접근법은 C/C++ 코드를 매우 높은 수준으로 안전하게 만들 수 있음을 증명합니다. 하지만 이는 지극히 일부인 특수 분야에 한정되며, 일반적인 소프트웨어 개발에 적용하기에는 개발 생산성을 크게 저해하는 막대한 비용과 노력을 수반합니다.

결론: ‘선택적 노력’과 ‘강제적 기본값’의 차이

이처럼 현대 C++ 생태계가 스스로의 문제를 해결하기 위해 정교하고 다층적인 안전성 확보 방법론을 발전시켜 온 것은 명백한 사실입니다. 더 나아가, 이러한 발전은 단순히 기존 문제에 대한 방어적 대응을 넘어, 언어 자체의 근본적인 ‘진화’로 이어지고 있습니다. 예를 들어, C++23 표준에 도입된 std::expected는 러스트의 Result 타입과 같이 오류 값을 타입 시스템의 일부로 명시적으로 다루려는 시도이며, 이는 프로그래밍 패러다임 간의 긍정적인 아이디어 교류를 보여주는 중요한 사례입니다.

그러나 바로 그 지점에서 C++의 근본적인 접근 방식과 러스트의 가치가 명확히 구분됩니다. C++에서 std::expected와 같은 안전한 기능을 사용하는 것은, 여전히 개발자의 ‘선택’에 의존하는 ‘모범 사례(best practice)’에 해당합니다. 이는 값비싼 외부 도구나 엄격한 규율에 더해, 언어 차원의 선택적 노력을 요구함을 의미합니다. 현실적으로 대다수의 프로젝트에서 이러한 최신 표준과 방법론이 일관되게 적용되지 못하며, 바로 그 이유로 메모리 관련 보안 사고는 지금도 끊임없이 발생하고 있습니다.4

결론적으로, 러스트의 컴파일러 내장 안전장치는 C++의 다층적 안전망과 비교했을 때, ‘안전성’이라는 가치를 소수 전문가의 선택적 노력에서 모든 개발자를 위한 ‘강제적인 기본값(enforced default)’으로 전환했다는 점에서 근본적인 차이를 보입니다. 현대 C++의 안전성 확보 방식을 존중하는 것과 별개로, 이러한 방법론이 보편적으로 적용되지 못하는 ‘현실’이야말로 러스트와 같은 대안이 강력한 설득력을 얻는 이유임을 이해해야 합니다.