‘메모리 안전성’의 범위 축소: 의도적으로 외면된 ‘메모리 릭(Memory Leak)’ 문제

용어의 재정의 문제는 ‘혁신’이라는 단어에만 국한되지 않습니다. 러스트의 존재 이유와도 같은 ‘메모리 안전성’이라는 핵심 가치에서 이 문제는 더욱 교묘하고 심각하게 나타납니다.

러스트는 의심할 여지 없이 뛰어난 메모리 안전성을 제공합니다. 컴파일러는 널 포인터 역참조, 해제 후 사용(use-after-free), 데이터 경쟁(data race)과 같은 치명적인 메모리 오류들을 컴파일 시점에 거의 완벽하게 차단합니다. 이것은 러스트가 C/C++에 비해 갖는 명백한 우위입니다.

하지만 여기에는 ‘불편한 진실’이 하나 있습니다. 바로 메모리 릭(memory leak)입니다. 메모리 릭은 프로그램이 할당된 메모리를 해제하지 않아, 시스템의 가용 메모리가 점차 줄어드는 심각한 메모리 관리 문제입니다. 그런데 러스트의 ‘안전성 보장’은 이 메모리 릭을 포함하지 않습니다. Rc<T>와 RefCell<T>을 함께 사용할 때 발생하는 순환 참조(reference cycle)는 메모리 릭을 유발하는 대표적인 사례이며, 이는 ‘safe’ 코드로 분류됩니다.

문제는 러스트가 메모리 릭을 막지 못한다는 기술적 한계 자체가 아닙니다. 문제는 러스트 커뮤니티의 일부가 ‘메모리 안전성’이라는 용어를 홍보할 때, 이 메모리 릭 문제를 의도적으로 논의의 범위에서 제외하거나 축소하는 경향을 보인다는 점입니다.

필자 역시 러스트를 공부하며 메모리 릭 문제를 제기했을 때, “러스트가 보장하는 메모리 안전성은 메모리 릭을 포함하지 않기 때문에, 그것은 논점에서 벗어난다”는 식의 답변을 수없이 들어왔습니다. 하지만 이것이 과연 타당한 주장일까요?

러스트의 공식 문서, 특히 ‘러스트노미콘(The Rustonomicon)’에 따르면 러스트의 ‘안전성(Safety)’이 보장하는 것은 단 하나, 즉 “안전한(Safe) 코드는 절대로 Undefined Behavior(UB, 정의되지 않은 동작)를 유발하지 않는다”는 것입니다. UB란 널 포인터 역참조나 데이터 경쟁처럼 프로그램의 동작을 예측 불가능하게 만드는 치명적인 오류를 의미합니다.

그들은 ‘메모리 안전성’을 ‘Undefined Behavior(정의되지 않은 동작)를 유발하지 않는 것’으로 범위를 좁게 재정의합니다. 이 정의에 따르면 메모리 릭은 Undefined Behavior가 아니므로, 러스트는 ‘메모리 안전한’ 언어가 맞습니다. 하지만 진짜 문제는, 커뮤니티의 일부가 이 기술적으로 협소한 정의를 대중을 상대로 한 홍보에 그대로 사용함으로써, 일반적인 개발자가 ‘메모리 안전성’이라는 단어에 기대하는 바와 실제 보장 내용 사이의 인지적 간극을 교묘하게 이용하고 있다는 점입니다.

하지만 이러한 정의는, 러스트가 마치 ‘모든 메모리 관련 문제를 해결한 언어’인 것처럼 보이게 만드는 착시 효과를 낳습니다. 자신들의 한계를 가리고 ‘완벽한 안전성’이라는 신화를 유지하기 위해 핵심 용어의 범위를 축소하는 행위는, 이 책이 비판하고자 하는 의도적인 논점 흐리기와 사실 왜곡의 대표적인 사례입니다.