3. '안전성' 서사의 다각적 분석

프로그래밍 언어 러스트(Rust)의 정체성은 '안전성(safety)'이라는 주요 속성에 기반합니다. 러스트 담론에서 '안전성'은 C/C++의 메모리 오류 문제를 해결하는 주요 특징으로 강조됩니다. 그러나 '안전성'이라는 용어는 기술적, 역사적, 담론적 맥락에서 다층적인 의미를 가집니다.

본 3장에서는 이 '안전성' 서사를 다각적으로 분석하는 것을 목표로 합니다.

첫째, '혁신'으로 평가되는 러스트의 핵심 개념들이 C++, Ada 등 선행 기술들과 어떤 관계에 있는지 역사적 맥락을 검토합니다 (3.1절). 둘째, 러스트가 보증하는 '안전성'의 기술적 정의와 그 경계(unsafe, panic) 및 한계(메모리 릭, 논리적 오류)를 명확히 규정합니다 (3.2절). 셋째, C++, Ada/SPARK, 그리고 GC 기반 언어와의 비교 분석을 통해, 각기 다른 공학적 접근법이 선택한 '안전성'의 보증 수준과 상충 관계를 분석합니다 (3.3-3.5절). 마지막으로, 이러한 기술적 분석을 바탕으로 '안전성'이라는 개념이 담론 내에서 어떻게 기능하는지 검토하고(3.6절), 프로그래밍 언어 설계의 상충 관계를 결론으로 제시합니다 (3.7절).

3.1 '혁신'의 의미와 역사적 선례 분석

러스트(Rust)는 '성능'과 '안전성'이라는 목표를 동시에 추구하며, 시스템 프로그래밍의 기존 설계 방식에 새로운 접근법을 제시했다는 점에서 '혁신'으로 평가됩니다. 이 '혁신'의 의미를 공학적, 역사적 관점에서 분석하기 위해, 본 절은 러스트의 핵심 개념들이 어떤 기술적 선례에 기반하고 있는지를 살펴봅니다.

소프트웨어 공학의 발전은 기존 아이디어의 계승과 새로운 적용을 통해 이루어집니다. 본 절에서는 러스트의 핵심 개념들이 C++, Ada, 그리고 함수형 언어 등에서 발전된 아이디어들과 어떻게 연결되는지를 분석합니다.

특히 본 절에서는 Ada 및 그 부분집합인 SPARK를 비교 대상으로 참조합니다. 이는 Ada/SPARK가 'GC 없는 안전성'이라는 러스트의 목표를 수십 년 전에 다른 방식으로 달성했던 역사적 선례이기 때문입니다. 따라서 두 기술을 비교하는 것은 러스트의 접근 방식이 어떤 지점에서 독창성을 갖는지를 이해하기 위한 분석 도구로 사용됩니다.

소유권과 자원 관리: C++ RAII 패턴의 계승

러스트의 '소유권(ownership)' 모델은 C++에서 발전된 자원 관리 기법과 연관됩니다. C++은 자원의 생명주기를 객체의 생명주기와 연동하여, 소멸자 호출 시 자원을 자동으로 해제하는 RAII(Resource Acquisition Is Initialization) 디자인 패턴을 정립하고, 이를 스마트 포인터를 통해 구체화했습니다.

자원의 '소유권'을 통해 메모리를 관리한다는 개념 자체는 C++에서 먼저 정립되었습니다. 러스트의 특징은 이 아이디어를 선택적으로 사용하는 패턴이 아닌, 컴파일러가 언어의 모든 영역에서 강제하는 규칙으로 만들었다는 점에 있습니다. (C++의 RAII와 스마트 포인터에 대한 상세한 분석은 4.1절에서 이어집니다.)

GC 없는 안전성: Ada/SPARK의 선례

러스트의 주요 특징 중 하나는 '가비지 컬렉터(GC) 없는 메모리 안전성'입니다. 이 목표는 1980년대에 미 국방부 주도로 개발된 Ada 언어에서 먼저 추구되었습니다. Ada는 고신뢰성 시스템을 위해 설계된 언어로, 타입 시스템과 런타임 검사를 통해 GC 없이도 널 포인터 접근, 버퍼 오버플로 등의 오류를 방지합니다.

Ada의 부분집합인 SPARK는 정형 검증(formal verification) 기법을 도입했습니다.¹ 이는 프로그램의 특정 속성(예: 런타임 오류의 부재)을 수학적으로 증명하는 기술로, 러스트의 빌림 검사기가 제공하는 메모리 안전성 보증과는 다른 범위와 수준의 신뢰도를 제공합니다. (이에 대한 상세한 비교는 3.4절에서 이어집니다.)

러스트의 빌림 검사기는 정형 검증보다 자동화된 방식으로 메모리 안전성 문제에 접근한다는 실용적인 차이가 있습니다. 'GC 없이 안전성을 달성한다'는 목표 자체는 Ada/SPARK 생태계에서 먼저 구현된 역사적 선례가 존재합니다.

명시적 오류 처리: 함수형 프로그래밍의 영향

러스트의 Result와 Option을 통한 명시적인 오류 처리 방식 또한 기존 프로그래밍 패러다임에 그 기반을 두고 있습니다. 이는 Haskell, OCaml과 같은 ML 계열 함수형 언어에서 발전된 '대수적 데이터 타입(Algebraic Data Type, ADT)'과 모나딕(Monadic) 에러 처리 기법을 차용한 것입니다. 이들 언어는 타입 시스템을 통해 '값이 없는 상태'나 '오류가 발생한 상태'를 명시적으로 표현하고, 컴파일러가 모든 경우를 처리하도록 강제하는 방식을 사용해왔습니다.

개념의 통합과 강제

러스트의 핵심 개념들은 독립적으로 발생한 것이 아니라, 기존 언어들의 아이디어를 통합한 결과물입니다. C++의 RAII 원칙, Ada/SPARK의 GC 없는 안전성 추구, 그리고 함수형 언어의 타입 기반 오류 처리 방식 등이 그 예입니다.

따라서 러스트의 설계상 특징은 여러 개념을 하나의 언어 안에 통합하고, 이를 컴파일러를 통해 언어의 기본 규칙으로 '강제'함으로써 광범위한 코드에 걸쳐 안전성 보증을 제공하려는 시도로 분석할 수 있습니다.

3.2 러스트 '안전성'의 정의, 경계, 그리고 한계

러스트(Rust)의 '안전성'은 포괄적인 '무결점(bug-free)'을 의미하는 것이 아니라, 명확하게 정의된 기술적 보증 범위를 지칭합니다. 이 '안전성'의 정확한 의미와 그 범위를 이해하는 것은 러스트의 공학적 설계를 분석하는 데 필요합니다.

본 3.2절에서는 먼저 러스트가 보증하는 '안전성'의 핵심 정의를 규명하고(3.2.1), 이어서 unsafe 키워드로 대표되는 보증의 경계(3.2.2), panic이라는 실패 모델(3.2.3), 그리고 메모리 릭과 논리적 오류처럼 보증 범위에 포함되지 않는 문제들(3.2.4, 3.2.5)을 순차적으로 분석하여 그 한계를 명확히 합니다.

3.2.1 '안전성'의 정의: 정의되지 않은 동작(UB) 방지

러스트(Rust) 담론에서 '안전성(safety)'은 핵심 개념으로 제시됩니다. 이 용어의 기술적 정의는 명확한 규정이 필요합니다. 러스트 언어 모델에서 '안전성'은 모든 종류의 버그(bug)가 없음을 의미하는 것이 아니라, '정의되지 않은 동작(Undefined Behavior, UB)'의 부재를 보증하는, 구체적이고 한정된 의미로 사용됩니다.

'정의되지 않은 동작'은 C/C++과 같은 언어에서 프로그램이 언어 명세가 규정하지 않는 상태에 진입하여, 시스템 충돌, 데이터 오염, 보안 취약점 등을 유발할 수 있는 예측 불가능한 행위를 의미합니다.

러스트의 설계 목표 중 하나는 'Safe Rust'로 분류되는 코드 영역에서 이러한 UB가 발생하는 것을 컴파일 시점에 정적으로 방지하는 것입니다. 러스트의 컴파일러(특히 빌림 검사기)는 해제 후 사용(use-after-free), 널 포인터 역참조(null pointer dereferencing), 버퍼 오버플로(buffer overflow), 그리고 스레드 간의 데이터 경쟁(data race)과 같은 UB 유발 원인들을 차단합니다.

이 정의는 러스트의 공식 문서 '러스트노미콘(The Rustonomicon)'에 명시되어 있습니다. 코드가 '안전(Safe)'하다고 말하는 것은, 이 코드가 어떠한 정의되지 않은 동작(UB)도 일으키지 않을 것임을 약속하는 것입니다.²

따라서 러스트의 '안전성 보증'은 '메모리 안전성'과 '스레드 안전성(데이터 경쟁 방지)'이라는 특정 영역에 집중됩니다. 이 기술적 정의는 '안전성'이라는 용어에 대한 일반적인 인식(예: 프로그램의 논리적 정확성, 런타임 오류 부재)과 범위 차이가 있으며, 이는 이후 절에서 분석할 한계(메모리 릭, 패닉 등)를 이해하는 기준점이 됩니다.

3.2.2 unsafe 키워드와 C ABI 종속성

러스트의 컴파일 시점 안전성 보장은 'Safe Rust'로 분류된 영역에서 유효합니다. 그러나 러스트는 unsafe 키워드를 통해, 컴파일러의 규칙(소유권, 빌림 규칙 등)을 우회할 수 있는 명시적인 경로를 제공합니다. unsafe 블록 내에서 개발자는 원시 포인터(raw pointer) 역참조, 가변 정적 변수 접근 등 정의되지 않은 동작(UB)을 유발할 수 있는 작업을 수행할 수 있습니다. unsafe의 존재는 러스트의 안전성 보증이 미치는 범위와 그 경계를 규정합니다.

unsafe 키워드의 주요 사용 목적 중 하나는 외부 언어 연동, 즉 FFI(Foreign Function Interface)입니다. 현대의 많은 운영체제, 하드웨어 드라이버, 핵심 라이브러리들은 C언어의 ABI(Application Binary Interface)를 사실상의 표준 인터페이스로 사용합니다. 러스트 프로그램이 파일 시스템, 네트워크, 저수준 하드웨어 제어 등 운영체제의 기능을 사용하기 위해서는 C ABI로 구현된 시스템 API를 호출해야 하는 경우가 많습니다.

이러한 FFI 호출은 unsafe 블록을 요구합니다. 이는 러스트 컴파일러가 FFI 경계 너머 C 코드의 동작(예: 전달된 포인터가 유효한지, 버퍼 크기가 정확한지)을 검증할 수 없기 때문입니다. 즉, 러스트는 C ABI와의 상호작용 지점에서 구조적인 종속성을 가지며, 이 지점에서 안전성 보증의 책임은 컴파일러에서 unsafe 코드를 작성하는 개발자에게로 이전됩니다.

unsafe는 FFI 외에도 다음과 같은 저수준 작업을 위해 사용됩니다.

• 컴파일러가 검증할 수 없는 고성능 자료구조 구현 (예: Vec<T>의 내부적인 메모리 할당 관리)
• 운영체제 커널이나 임베디드 환경에서의 하드웨어 레지스터 직접 제어

러스트 생태계는 이러한 unsafe 코드를 '안전한(safe)' 인터페이스로 추상화하여 캡슐화하는 패턴을 사용합니다. 그러나 이 구조에서 unsafe 구현부에 결함이 존재할 경우, 'Safe Rust'로 작성된 코드에서도 메모리 오류가 발생할 수 있습니다. unsafe 키워드는 러스트가 C ABI를 포함한 저수준 시스템과 상호작용하기 위한 필수적인 장치이며, 동시에 러스트의 정적 안전성 보증이 적용되지 않는 경계면을 명시적으로 드러내는 역할을 합니다.

3.2.3 '안전한 실패'와 panic의 의미

러스트의 오류 처리 모델에는 '안전한 실패(safe failure)'라는 개념이 있으며, 이는 panic 메커니즘과 관련됩니다. panic의 의미를 분석하기 위해, '실패'라는 용어를 두 가지 관점에서 구분할 수 있습니다.

• 메모리 무결성 관점 (Safe Failure): 정의되지 않은 동작(UB)이나 데이터 오염을 유발하는 실패(예: C/C++의 세그멘테이션 폴트)와 구별되는, 제어된 방식의 프로그램 종료를 의미합니다. 러스트의 panic은 기본적으로 스택을 풀고(unwinding) 각 객체의 소멸자(drop)를 호출하며, 메모리 무결성을 보존한 채 스레드를 종료시킵니다. 이 관점에서 panic은 UB를 유발하지 않으므로 '안전한 실패'입니다.

• 서비스 연속성 관점 (Unrecoverable Halt): 오류 발생 시 예외 처리 등을 통해 로직을 복구하거나 서비스를 지속하지 않고, 해당 스레드가 종료되는 상태를 의미합니다. 이 관점에서 panic은 '회복 불가능한 중단'에 해당합니다.

기술적으로 panic은 메모리 무결성을 보장하며 디버깅을 보조하는 기능을 합니다. 그러나 이는 시스템의 지속적인 생존이나 서비스의 '회복력(resilience)'과는 구별되는 개념입니다.

러스트는 std::panic::catch_unwind 함수를 통해 panic이 스레드 경계를 넘어 전파되는 것을 차단하고 복구를 시도할 수 있는 경로를 제공합니다.³ 이는 panic의 '회복 불가능한 중단' 특성을 관리하기 위한 예외적인 수단으로 볼 수 있습니다.

3.2.4 '안전한' 메모리 릭 문제

러스트의 '안전성' 정의(3.2.1절)는 정의되지 않은 동작(UB)을 방지하는 데 초점을 맞추며, 메모리 릭(memory leak)은 이 보증 범위에 포함되지 않습니다. 메모리 릭은 프로그램이 할당된 메모리를 해제하지 않아 시스템의 가용 메모리가 점진적으로 줄어드는 현상입니다.

러스트의 관점에서 메모리 릭은 UB(Undefined Behavior)가 아니므로 '안전한(safe)' 동작으로 분류됩니다. 메모리가 해제되지 않고 누수되는 것은 프로그램의 리소스 고갈 문제를 일으킬 수는 있으나, 해제된 메모리에 접근(use-after-free)하거나 동일한 메모리를 두 번 해제(double-free)하는 것과 같은 메모리 오염이나 시스템 충돌로 이어지지는 않기 때문입니다.

'Safe Rust' 코드 내에서도 메모리 릭은 발생할 수 있습니다. 한 가지 사례는 참조 카운팅(Reference Counting) 스마트 포인터인 Rc<T>와 내부 가변성을 제공하는 RefCell<T>을 함께 사용할 때 발생하는 순환 참조(reference cycle)입니다.

두 개 이상의 Rc 인스턴스가 RefCell 등을 통해 서로를 상호 참조하는 순환 구조를 형성하면, 각 인스턴스의 참조 카운트(reference count)가 0에 도달하지 못하게 됩니다. 프로그램의 다른 부분에서 이 순환 구조에 접근할 수 없게 되더라도, 순환 참조 내부의 카운트는 0이 되지 않아 소멸자(drop)가 호출되지 않고, 관련 메모리는 해제되지 않습니다.

이는 러스트의 소유권 및 빌림 규칙을 위반하지 않는 '안전한' 코드 내에서 발생하는 논리적 문제이며, 러스트의 안전성 모델이 모든 종류의 메모리 관련 문제를 자동으로 해결하는 것은 아님을 보여줍니다.

3.2.5 보증 범위 밖의 문제 (논리적 오류, 교착 등)

러스트 컴파일러가 제공하는 '안전성' 보증은 3.2.1절에서 정의했듯이 '메모리 안전성(UB 방지)'과 '데이터 경쟁(data race) 방지'라는 특정 영역에 집중됩니다. 컴파일러가 이 범위를 넘어서는 모든 종류의 버그를 방지하는 것은 아닙니다.

다음은 러스트의 안전성 보증 범위 밖에 있으며 개발자의 책임 영역에 속하는 주요 문제 유형입니다.

• 논리적 오류 (Logical Errors) 프로그램의 로직 자체가 의도와 다르게 작성된 경우입니다. 예를 들어, 금융 계산에서 이자율을 잘못 적용하거나 할인 로직을 중복으로 처리하는 등의 비즈니스 로직 오류가 해당합니다. 러스트의 빌림 검사기는 메모리 접근의 유효성은 검증하지만, 코드의 비즈니스 로직이 '정확하게' 동작하는지는 검증하지 않습니다.

• 교착 상태 (Deadlocks) 러스트의 동시성 보증은 여러 스레드가 동일한 데이터에 '동시에 쓰기'를 시도하여 발생하는 '데이터 경쟁'을 방지합니다. 하지만, 둘 이상의 스레드가 서로 다른 자원(예: 뮤텍스 A, B)을 점유한 채, 상대방의 자원(B, A)을 무한정 기다리는 '교착 상태'는 방지하지 못합니다. 이는 메모리 안전성 문제가 아닌, 동시성 설계의 논리적 결함입니다.

• 정수 오버플로 (Integer Overflow) 정수형 변수가 표현할 수 있는 범위를 넘어서는 연산이 발생하는 경우입니다. 러스트는 디버그 빌드에서는 panic을 발생시키지만, 릴리즈(배포) 빌드에서는 기본적으로 값이 순환(wrapping)하도록 처리합니다. 이는 정의되지 않은 동작(UB)은 아니지만, 개발자가 명시적으로 처리하지 않을 경우 계산 오류나 논리적 버그의 원인이 될 수 있습니다.

• 자원 고갈 (Resource Exhaustion) 3.2.4절의 메모리 릭 외에도, 파일 핸들러, 네트워크 소켓, 데이터베이스 커넥션 등 한정된 시스템 자원을 논리적 오류로 인해 해제하지 않아 발생하는 문제입니다. 러스트의 RAII 패턴(Drop 트레잇)이 자원 해제를 보조하지만, 모든 종류의 자원 누수를 언어 차원에서 보장하지는 않습니다.

이러한 보증 범위의 한계는 2024년에 발견된 CVE-2024-24576 취약점을 통해 확인할 수 있습니다. 이 취약점은 러스트의 '안전한(safe)' 표준 라이브러리 API(std::process::Command)에서 발생했으며, CVSS 10.0(Critical) 등급을 받았습니다. 원인은 메모리 오류가 아닌, Windows 환경에서 명령어를 처리할 때 인수를 제대로 이스케이프 처리하지 못해 발생한 명령어 삽입(Command Injection) 취약점, 즉 논리적 오류(CWE-78)였습니다.

이 사례는 러스트가 메모리 관련 UB를 방지하더라도, 그 보증 범위 밖에서는 논리적 보안 취약점이 발생할 수 있음을 보여줍니다.

3.3 비교 분석 1: C++의 다층적 안전성 확보 방안

러스트(Rust)의 안전성을 다루는 담론은 종종 C/C++과의 비교를 통해 그 가치를 설명합니다. 이 과정에서 1990년대의 C/C++이 아닌, 이후 변화가 축적된 '현대의 C/C++ 생태계'를 비교 대상으로 설정할 필요가 있습니다.

C++ 언어와 그 생태계는 안전성 확보를 위해 언어, 도구, 방법론에 걸친 다층적인 접근법을 사용해왔습니다. 이러한 접근법은 컴파일러에 내장된 러스트의 보증과 달리, 개발자의 선택, 추가 비용, 그리고 규율을 요구한다는 차이점이 있습니다.

1. 언어의 변화: 모던 C++와 '선택적' 안전성

C++11 표준 이후 '모던 C++'은, RAII(Resource Acquisition Is Initialization) 패턴을 지원하는 스마트 포인터(std::unique_ptr, std::shared_ptr)를 표준 라이브러리에 도입했습니다. 이는 자원의 소유권을 명시하고 메모리를 자동으로 관리하여, 기존 C++의 메모리 관련 문제 일부를 언어 수준에서 방지하는 방법입니다.

그러나 C++에서 스마트 포인터의 사용은 강제되지 않는 '모범 사례(best practice)'입니다. 개발자는 여전히 원시 포인터(raw pointer)를 사용할 수 있으며, 컴파일러는 이를 막지 않습니다. 안전성에 대한 책임은 개발자의 규율에 의존합니다.

2. 도구 생태계: '비용과 전문성'을 요구하는 접근

C/C++ 개발 환경은 다음과 같은 자동화된 도구들을 활용하여 안전성을 확보할 수 있습니다.

• 정적 분석: Coverity, PVS-Studio, Clang Static Analyzer 등은 컴파일 단계 이전에 코드베이스를 분석하여 잠재적 버그를 찾습니다.
• 동적 분석: Valgrind, 주소 새니타이저(AddressSanitizer) 등은 프로그램을 실행하며 메모리 접근을 감시하여 런타임에 오류를 탐지합니다.
• 실시간 린팅: Clang-Tidy와 같은 린터(linter)는 C++ Core Guidelines⁴의 규칙을 강제하여 특정 코딩 스타일을 유도합니다.

이러한 도구들은 안전성을 향상시키지만, 일부 상용 도구들은 비용이 발생하며, 설정하고 분석 결과를 해석하는 데 전문성을 요구합니다. 이는 러스트의 공식 툴체인(cargo)이 기본 제공하는 정적 분석 기능과는 접근성과 비용 면에서 차이가 있습니다.

3. 미션 크리티컬 시스템의 방법론: '특수 분야'의 접근

자동차, 항공, 의료 기기와 같이 높은 신뢰성이 요구되는 '미션 크리티컬(mission-critical)' 시스템 분야에서는 특정 방법론을 적용합니다.

• 코딩 표준 강제: MISRA C/C++와 같은 코딩 표준을 통해 동적 할당 등 잠재적 위험이 있는 언어 기능의 사용을 제한합니다.
• 정적 검증 수행: Polyspace, Frama-C와 같은 정적 코드 검증(static code verification) 도구를 통해 런타임 오류(예: 오버플로) 가능성을 수학적으로 검증합니다.

이러한 접근법은 C/C++ 코드의 안전성을 높일 수 있지만, 특정 분야에 한정되며 일반적인 소프트웨어 개발에 적용하기에는 개발 생산성에 영향을 미치는 비용과 노력을 수반합니다.

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

C++ 생태계는 안전성 확보를 위해 다층적인 방법론을 사용해왔습니다. C++23 표준에 도입된 std::expected가 러스트의 Result와 유사한 접근 방식을 취하는 것처럼, 프로그래밍 패러다임 간의 아이디어 교류도 이루어지고 있습니다.

그러나 C++에서 이러한 기능과 도구를 사용하는 것은 개발자의 '선택'에 의존하는 '모범 사례'에 해당합니다. 다수의 프로젝트에서 이러한 표준과 방법론이 일관되게 적용되지 않을 수 있으며, 메모리 관련 보안 사고는 계속 발생하고 있습니다.⁵

결론적으로, 러스트의 컴파일러 내장 안전 기능은 C++의 다층적 접근법과 비교했을 때, '안전성'을 '선택'이 아닌 '강제적인 기본값(enforced default)'으로 제공한다는 점에서 차이를 보입니다.

3.4 비교 분석 2: Ada/SPARK의 수학적 증명과 보증 수준

본 절에서는 Ada 및 그 부분집합인 SPARK를 '분석적 도구'로 활용하여, 러스트(Rust)의 안전성 모델이 시스템 프로그래밍의 안전성 보증 스펙트럼에서 어느 지점에 위치하는지를 기술합니다. SPARK의 '수학적으로 증명된 정확성'과 비교 분석을 통해, 러스트 모델의 공학적 특징과 보증 범위를 탐색합니다. 이 비교는 각기 다른 설계 철학이 선택한 상충 관계를 이해하기 위함입니다.

러스트의 안전성 보증: '정의되지 않은 동작(UB)' 방지

3.2절에서 분석했듯이, 러스트의 핵심적인 안전성 보증은 '소유권'과 '빌림' 규칙을 통해, 컴파일 시점에 정의되지 않은 동작(Undefined Behavior, UB)을 유발하는 메모리 접근 오류 및 데이터 경쟁(data race)을 방지하는 것입니다.

그러나 이 보증은 프로그램의 논리적 정확성(logical correctness)이나, 모든 종류의 런타임 오류(runtime error) 부재를 보증하지는 않습니다. 예를 들어 정수 오버플로, 배열 인덱스 초과 등의 오류는 panic(3.2.3절)으로 이어지며, 이는 시스템의 안정적 '실행' 보장과는 구별됩니다.

Ada/SPARK의 안전성 보증: '프로그램 정확성' 증명

반면, Ada/SPARK 생태계는 더 넓은 범위의 정확성을 목표로 합니다.

1. Ada의 기본 안전성 및 회복력: Ada는 언어 차원에서 타입 시스템과 '계약 기반 설계(Design by Contract)'를 통해 논리적 오류 방지를 시도하며, 정수 오버플로를 포함한 런타임 오류 발생 시 예외(exception)를 발생시키는 것을 기본으로 합니다. 이는 오류 처리 루틴을 통해 시스템이 임무를 지속하게 하는 '회복력(resilience)'을 지향하는 설계입니다. 이는 '회복 불가능한 오류'로 간주하고 스레드를 중단하는 러스트의 panic 철학과 목표점에서 차이를 보입니다.

2. SPARK의 수학적 증명: Ada의 부분집합인 SPARK는 정형 검증(formal verification) 도구를 통해 코드의 논리적 속성을 수학적으로 분석합니다. 이를 통해 런타임 오류(정수 오버플로, 배열 인덱스 초과 등 포함)가 발생하지 않음을 컴파일 시점에 '증명'할 수 있습니다.

두 언어의 보증 수준 비교

결론: 안전성 스펙트럼에서의 위치

이 비교 분석은 러스트의 안전성 모델이 '안전성' 스펙트럼의 특정 지점에 위치함을 보여줍니다. SPARK가 '수학적 증명'을 위해 개발자의 명시적인 증명 노력(주석, 계약 명시 등)과 전문 도구 활용을 요구하는 반면, 러스트는 일부 보증 범위(UB 방지)에 집중하고 개발자의 학습 곡선(빌림 검사기)을 비용으로 지불하는 방식으로 자동화된 안전성을 제공합니다.

두 기술은 각기 다른 공학적 문제에 대한 해법을 제시하며, 러스트의 안전성을 C/C++만을 비교 대상으로 평가하는 것은 시스템 프로그래밍의 전체 스펙트럼을 파악하는 데 한계를 가질 수 있습니다.

3.5 비교 분석 3: 대안적 메모리 관리 방식 (GC)의 재평가

러스트(Rust)의 메모리 관리 방식은 C/C++의 수동 관리 방식과 비교되곤 합니다. 그러나 시스템 프로그래밍 스펙트럼에는 가비지 컬렉터(GC)를 통해 메모리 안전성과 생산성을 달성하는 언어들(예: Go, C#, Java) 역시 포함됩니다.

러스트 관련 담론의 일부에서는 GC의 'Stop-the-World' 멈춤 현상과 런타임 오버헤드를 근거로, GC 언어들이 특정 시스템 프로그래밍 영역에 부적합하다고 주장하기도 합니다. 이러한 주장은 과거 GC 기술에는 해당될 수 있으나, 최근 GC 기술의 특성을 반영하지 못할 수 있습니다.

현재 주류 언어에 탑재된 GC는 제너레이셔널(generational) GC, 동시성(concurrent) GC, 병렬(parallel) GC 등의 기법을 통해 애플리케이션의 실행 중단을 최소화하면서 메모리를 관리합니다. 예를 들어, Go 언어의 GC는 마이크로초(µs) 단위의 멈춤 시간을 목표로 설계되었으며 네트워크 서버와 클라우드 인프라에서 사용됩니다. Java의 ZGC나 Shenandoah GC 등은 대용량 힙(Heap)에서도 밀리초(ms) 단위의 일시 정지를 목표로 합니다.

러스트의 소유권 모델과 GC는 '비용을 지불하는 방식'에 대한 설계 철학의 차이로 볼 수 있습니다.

• 러스트의 접근법: 런타임 비용을 최소화하는 대신, 그 비용을 컴파일 시간과 개발자의 인지적 부담(학습 곡선, 빌림 검사기), 즉 '개발 시간'으로 이전합니다.
• GC 언어의 접근법: 개발자의 인지적 부담과 개발 시간을 줄이는 대신, 런타임에 CPU와 메모리 자원이라는 '기계 시간'을 비용으로 사용합니다.

하드웨어 제약이 있는 임베디드 시스템이나 하드 리얼타임(hard real-time) 운영체제와 같이 GC 사용이 제한되는 영역은 존재합니다. 하지만 이러한 특정 요구사항을 일반화하여 모든 GC 기반 언어의 실용성을 평가하는 것은, 다양한 비즈니스 환경의 요구를 고려하지 않는 것일 수 있습니다. 일부 상업적 환경에서는 개발 속도와 시장 출시 시간이 런타임 성능보다 중요할 수 있으며, 이 경우 GC 언어는 하나의 선택지가 될 수 있습니다.

3.6 담론 분석: '실용성'과 '책임'의 재정의

앞선 절(3.1-3.5)에서는 러스트(Rust)의 '안전성' 모델을 기술적, 역사적 관점에서 분석하고 C++, Ada/SPARK, GC 언어 등 타 접근법과 비교했습니다. 이 과정에서 러스트의 개념적 선례(3.1)와 기술적 한계(3.2) 또한 다루었습니다.

본 3.6절에서는 분석의 초점을 '기술적 사실'에서 '기술적 담론(discourse)'으로 이동합니다. 즉, 이러한 기술적 사실들이 러스트 생태계 내에서 어떻게 소통되고 해석되는지, 그리고 '안전성'이라는 핵심 서사가 어떻게 유지되고 방어되는지를 분석합니다.

먼저 '혁신'의 의미가 '실용성'으로 재정의되는 방식(3.6.1)과, 메모리 릭이나 unsafe 버그와 같은 기술적 한계에 대한 '책임'이 귀속되는 방식(3.6.2)을 검토합니다.

3.6.1 '실용적 혁신'의 담론적 기능

3.1절에서 러스트(Rust)의 핵심 개념들이 C++, Ada 등 선행 기술에 기반하고 있음을 분석했습니다. 이러한 분석에 대해, 러스트의 혁신이 '개념의 발명'이 아닌 '가치의 대중화(democratization)' 또는 '실용적 혁신'에 있다는 주장이 제기됩니다.

이 주장의 논리는 다음과 같습니다. Ada/SPARK의 'GC 없는 안전성'은 항공, 국방 등 특정 분야에서 높은 비용(학습 곡선, 전문 도구, 개발 속도)을 요구하여 일반 개발자들에게 확산되지 못했습니다. 반면, 러스트는 카고(Cargo)와 같은 도구 생태계 및 커뮤니티를 통해 이 개념을 일반 시스템 프로그래밍 영역으로 확산시켰다는 것입니다. 즉, 소수만 사용하는 기술보다 다수가 활용할 수 있는 기술이 공학적 의미가 더 크다는 주장입니다.

본서가 분석하는 지점은 이 '실용적 혁신'이라는 주장이 기술 담론 내에서 작동하는 방식입니다. 이 주장은 '개념적 독창성의 부재'라는 비판적 질문에 대한 응답으로 사용될 때, 수사적 도구(rhetorical tool)로 기능하는 경향이 관찰됩니다.

A는 개념적으로 새로운가?라는 질문에 대해, A는 시장에서 사용되며 실용적이다라고 답변하는 것은, 전자의 질문에 대한 직접적인 답변이 아닐 수 있습니다. 이는 논의의 범주를 '개념의 기원(origin)'에서 '실용적 효용성(utility)'으로 전환시키는 논점 변경(topic shift)으로 볼 수 있습니다.

이러한 논리적 전환은, 러스트의 '실용적 성과'를 근거로 '개념적 유일성'을 암시하는 담론으로 이어질 수 있습니다. 그 결과, Ada와 C++ 같은 언어들의 역사적, 공학적 결과물이 상대적으로 낮게 평가되거나 논의에서 배제되는 효과가 나타날 수 있습니다. '실용적 혁신'이라는 개념은 러스트의 성과를 설명하는 동시에, '혁신'이라는 용어의 본래 의미에 대한 비판적 검토를 회피하는 담론적 기능을 수행할 수 있습니다.

3.6.2 '책임'의 귀속: 메모리 릭과 unsafe의 논의 방식

러스트(Rust)의 기술적 한계(3.2절)가 논의될 때, 해당 문제에 대한 '책임'이 귀속되는 방식은 특정 담론적 패턴을 보입니다. 이는 '안전성'이라는 언어의 핵심 개념을 보존하기 위한 논리적 경계 설정으로 분석할 수 있습니다.

1. 메모리 릭: '안전성'의 정의를 통한 책임 분리

3.2.4절에서 분석했듯이, 러스트는 순환 참조 등으로 '안전한(safe)' 코드 내에서도 메모리 릭(memory leak)이 발생할 수 있습니다.

이러한 기술적 사실이 러스트의 '메모리 안전성'에 대한 비판으로 제기될 때, 담론은 종종 3.2.1절의 기술적 정의(안전성 = UB 방지)를 참조합니다. 메모리 릭은 정의되지 않은 동작(UB)을 유발하지 않으므로, '안전하지 않은(unsafe)' 동작이 아니며, 따라서 컴파일러의 '안전성 보증' 범위에 해당하지 않는다는 논리입니다.

이 접근법은 '메모리 문제'를 'UB를 유발하는 문제'와 'UB를 유발하지 않는(safe) 논리적 문제(메모리 릭)'로 분리합니다. 결과적으로, 메모리 릭 방지의 책임은 컴파일러의 보증 영역에서 개발자의 논리적 책임 영역으로 이전됩니다. 이는 C/C++ 커뮤니티에서 메모리 관리가 포괄적인 개발자의 '책임'으로 다루어지는 방식과 차이를 보입니다.

2. unsafe 버그: unsafe 경계를 통한 책임 고립

3.2.2절에서 설명했듯이, unsafe 블록 내부의 코드는 컴파일러의 안전성 검사를 우회하며, 이 부분의 버그는 'Safe Rust' 코드의 안정성까지 훼손할 수 있습니다.

라이브러리의 unsafe 코드에서 메모리 오류가 발생했을 때, 담론은 'Safe Rust'의 보증 자체가 실패한 것이 아님을 강조하는 경향이 있습니다. 오류의 원인은 'Safe Rust' 모델이 아닌, 'unsafe 코드를 작성한 개발자의 책임'으로 귀속됩니다.

unsafe 키워드는 코드의 특정 영역을 '신뢰할 수 없음'으로 명시하는 동시에, 그 영역에서 발생하는 문제의 책임을 개발자에게 고립시키는 역할을 합니다. 이는 C/C++에서 라이브러리 버그가 언어 자체의 내재된 위험성의 발현으로 받아들여지는 것과 대조됩니다.

결론적으로, 이 두 가지 논의 방식은 러스트의 핵심 개념인 'Safe Rust의 메모리 안전 보장'을 유지하는기제로 작동합니다. (1) '안전성'의 정의를 (UB 방지로) 한정하고, (2) unsafe라는 명시적 경계를 통해 책임을 분리함으로써, 기술 생태계에서 실제 발생하는 문제(메모리 릭, unsafe 버그)에도 불구하고 'Safe Rust'의 보증은 유효하다는 핵심 서사를 유지합니다.

3.7 결론: 성능, 안전성, 생산성의 상충 관계

소프트웨어 공학에서 단일 도구가 모든 요구사항을 만족시키기는 어렵습니다. 이는 프로그래밍 언어 설계에도 적용됩니다. 공학적 설계는 일반적으로 여러 목표 사이의 상충 관계(trade-off) 를 조정하는 과정입니다.

프로그래밍 언어는 통상적으로 성능 및 메모리 제어, 개발 생산성, 그리고 컴파일러 수준의 안전성이라는 세 가지 요소를 기준으로 설계 방향이 결정됩니다. 각 언어와 생태계는 이 세 가지 요소 사이에서 특정한 지점을 선택하며, 각기 다른 특징과 비용을 가집니다.

• C/C++: 하드웨어 제어와 실행 성능을 우선순위에 둡니다. 이를 위해 개발자는 메모리 관리를 포함한 책임을 직접 담당해야 하며(3.3절), 안전성은 외부 도구나 규율에 의존합니다.
• Go, Java/C#: 가비지 컬렉터(GC)와 런타임을 통해 개발 생산성에 중점을 둡니다(3.5절). 이 설계는 런타임 오버헤드를 비용으로 지불합니다.
• Ada/SPARK: 수학적으로 증명 가능한 최고 수준의 안전성과 정확성을 목표로 합니다(3.4절). 이는 높은 수준의 개발 비용과 전문성을 요구합니다.
• Rust: GC 없이 C++과 유사한 수준의 성능과 '메모리 안전성(UB 방지)'을 동시에 달성하는 것을 목표로 합니다(3.2절). 이는 런타임 비용 대신, 개발자가 소유권과 빌림 검사기 모델을 학습하고 코드에 적용해야 하는 '개발 시간'과 '인지적 비용'을 요구합니다.

이러한 설계적 차이로 인해 각 언어는 특정 개발 시나리오에서 다른 적합성을 보일 수 있습니다. 예를 들어, 웹 서비스 백엔드는 Go의 생산성을, 항공기 제어 시스템은 SPARK의 증명 가능한 안정성을, GC가 제약이 되는 시스템에서는 Rust의 모델을 선택할 수 있습니다.

결론적으로, '안전성'은 단일한 개념이 아닌 다층적인 스펙트럼(3.4절 표 참고)이며, 모든 언어는 고유의 설계 목표에 따라 특정 특징과 그에 수반되는 비용을 가집니다. 따라서 특정 문제 영역의 제약 조건과 요구사항을 분석하여 그에 맞는 도구를 선택하는 것이 공학적 접근 방식에 해당합니다.