우월한 러스트와 나르시시즘 (초안)
최종 수정일:
초안입니다.
서론: ‘완벽한 언어’라는 종교, 러스트 생태계를 돌아보다
프로그래밍 세계에 혜성처럼 등장한 러스트(Rust)는 지난 몇 년간 가장 뜨거운 언어였습니다. 개발자 설문조사에서 수년째 ‘가장 사랑받는 언어’로 선정되었고, 그 지지자들은 지칠 줄 모르는 열정으로 러스트의 가치를 설파합니다. 그들이 내세우는 ‘Why Rust?’라는 질문에 대한 답은 명쾌하고 단호하게 들립니다. “가비지 컬렉터(GC) 없이도 메모리 안전성을 달성하며, 실행 시 리소스가 극도로 효율적입니다. Cargo라는 통일된 툴체인으로 개발 환경은 파편화되지 않았으며, Result 타입으로 에러 처리가 강제되어 프로그램의 안정성이 비교 불가능할 정도로 높습니다.”
일견 모든 것이 사실처럼 보입니다. 러스트는 실제로 많은 기술적 성취를 이뤄낸 뛰어난 언어임이 분명합니다. 하지만 한 걸음 더 깊이 들어가 그 주장들의 맥락을 자세히 들여다보면, 우리는 기술에 대한 객관적 평가라기보다는 특정 신념을 강화하기 위한 논리가 반복되고 있음을 발견하게 됩니다. 당연한 사실이 특별한 전유물로 포장되고, 복잡한 현실은 단순한 이분법으로 재단되며, 불편한 진실은 의도적으로 외면당합니다. 이 책은 바로 그 지점에서 시작합니다.
‘리소스 효율성과 GC 부재’는 러스트만의 고유한 장점이 아니라, C, C++, Ada 등 수십 년간 시스템 프로그래밍의 역사를 이끌어 온 네이티브 컴파일 언어들의 공통적인 특징입니다. 이 당연한 사실을 마치 러스트만의 위대한 발명인 것처럼 제시하는 것은, 다른 시스템 언어들의 존재와 가치를 의도적으로 무시하는 평가절하의 한 방식입니다. 특히 최고 수준의 예측 가능성이 요구되는 항공, 국방 분야에서 검증된 Ada와 같은 언어 앞에서 이 특징을 내세우는 것은 설득력이 떨어집니다.
‘Cargo를 중심으로 한 통일된 개발 환경’이 강력한 장점임은 분명합니다. 그러나 이것이 곧 언어 자체의 완벽성을 증명하는 근거가 되지는 않으며, 필요에 따라 다른 빌드 시스템을 사용할 수 있다는 현실을 가리지도 않습니다. 마찬가지로 ‘Result 타입을 통한 명시적 에러 처리’는 훌륭한 설계지만, ‘throw/catch는 위험하다’는 주장은 Java의 ‘Checked Exception’과 같은 대안을 무시하는 성급한 일반화의 오류입니다. 더 나아가, 이는 수십 년 전부터 언어 차원의 엄격한 예외 처리를 통해 안전성을 제공해 온 Ada의 역사를 애써 외면하는 행위이기도 합니다.
그렇다면 왜 이토록 명백한 논리적 비약과 사실 왜곡을 감수하면서까지 비슷한 주장들이 반복되는 것일까요? 이 책은 그 원인을 기술에 대한 순수한 열정이 아닌, ‘집단적 나르시시즘’과 그 ‘방어기제’라는 심리학적 렌즈로 분석하고자 합니다. 그 기저에는 “나는 완벽한 언어를 사용한다, 고로 나는 우월하고 특별하다”는 자기애적 투사가 깔려 있습니다. 자신의 자존감과 정체성을 ‘완벽한 도구’에 완전히 의탁하는 것입니다. 이 순간부터 기술에 대한 합리적 비판은 곧 자신의 존재 가치에 대한 공격으로 받아들여집니다.
이 깨지기 쉬운 자아를 보호하기 위해, 커뮤니티는 ‘러스트’를 모든 문제의 해결책으로 이상화하고, 비판자는 ‘이해하지 못하는 무지한 자’로 평가절하하며, 기술적 논점 대신 “열등감 때문에 비판한다”며 비판자의 의도를 공격합니다. 결국 이러한 현상은 기술의 발전을 위한 건강한 토론이 아니라, 자신의 믿음을 지키기 위한 ‘종교 전쟁’에 가깝습니다. 가장 큰 비극은, 이러한 맹목적인 숭배와 공격성이 오히려 건설적인 비판을 통한 성장의 기회를 차단하고, 그 기술 생태계 자체를 병들게 한다는 점입니다.
이 책은 러스트의 기술적 성취를 부정하지 않습니다. 오히려 그 잠재력을 믿기에, 현재의 나르시시즘적 문화가 어떻게 스스로를 고립시키고 퇴보를 야기하는지를 면밀히 추적할 것입니다. 제1부에서는 러스트의 핵심 특징을 소개하고, 제2부에서는 안전성, 개발 경험, 소유권이라는 3대 신화가 어떻게 우월주의로 변질되는지 해부합니다. 제3부에서는 그 결과로 나타나는 커뮤니티의 폐쇄성, 생태계의 성장통, 거버넌스의 실패를 분석하고, 마지막 제4부에서는 나르시시즘을 극복하고 진정한 성숙으로 나아가기 위한 구체적인 제언을 담았습니다.
이 책은 러스트에 대한 찬사도, 저주도 아닙니다. 이것은 러스트 생태계가 스스로를 비추어 볼 수 있는, 차갑지만 정직한 거울이 되고자 하는 시도입니다. 부디 이 비판적 성찰의 여정이 더 건강하고 성숙한 기술 문화를 만드는 데 기여할 수 있기를 바랍니다.
제1부: 러스트란 무엇인가
제1장: 러스트 언어 소개 및 주요 특징
1.1. 탄생 배경과 철학: 왜 러스트인가?
새로운 프로그래밍 언어는 저마다의 이유를 가지고 탄생하지만, 러스트(Rust)처럼 기존의 패러다임에 대한 근본적인 도전에서 시작된 경우는 드뭅니다. 러스트의 탄생 배경을 이해하기 위해서는, 먼저 시스템 프로그래밍 세계가 오랫동안 해결하지 못했던 고질적인 딜레마를 살펴볼 필요가 있습니다.
수십 년간, 저수준(low-level) 시스템을 다루는 개발자들은 ‘성능’과 ‘안전성’ 사이에서 고통스러운 양자택일을 강요받아 왔습니다. 한쪽에는 C/C++와 같은 언어가 있었습니다. 이들은 하드웨어를 직접 제어하는 막강한 성능과 제어권을 제공했지만, 그 대가로 세그멘테이션 폴트(segmentation fault), 버퍼 오버플로우(buffer overflow), 데이터 경쟁(data race)과 같은 치명적인 메모리 오류의 책임을 전적으로 프로그래머에게 떠넘겼습니다. 다른 한쪽에는 Java나 C#과 같은 가비지 컬렉터(GC) 기반의 언어들이 있었습니다. 이들은 자동 메모리 관리를 통해 높은 수준의 안전성을 제공했지만, GC의 런타임 오버헤드와 예측 불가능성 때문에 실시간 시스템이나 운영체제 커널과 같은 모든 시스템 영역을 대체할 수는 없었습니다.
모질라(Mozilla)의 연구 프로젝트로 시작된 러스트는 바로 이 ‘성능이냐, 안전성이냐’의 오랜 딜레마를 정면으로 돌파하겠다는 대담한 목표를 가지고 탄생했습니다. 즉, “C++ 수준의 빠른 성능를 가지면서도, GC 없이 높은 수준의 안전성을 보장하는 언어”를 만들고자 한 것입니다. 이 야심 찬 비전을 달성하기 위해, 러스트는 설계 초기부터 다음의 세 가지 핵심 목표를 일관되게 추구했습니다.
안전성 (Safety), 성능 (Performance), 동시성 (Concurrency)
안전성
러스트의 핵심적인 철학은 메모리 안전성입니다. 컴파일 시점에 코드의 메모리 사용 규칙을 엄격하게 검사하여, 시스템을 붕괴시킬 수 있는 치명적인 버그들을 원천적으로 제거하는 것을 목표로 합니다. 이는 프로그래머의 실수를 탓하는 대신, 컴파일러가 실수를 저지를 수 없도록 강제하는 새로운 접근법입니다.
성능
러스트는 시스템 프로그래밍 언어로서의 정체성을 잊지 않았습니다. GC와 같은 무거운 런타임에 의존하지 않고, 하드웨어의 성능을 최대한으로 끌어낼 수 있도록 설계되었습니다. ‘제로 코스트 추상화(Zero-Cost Abstractions)’라는 원칙은, 개발자가 고수준의 편리한 기능을 사용하더라도 추가적인 런타임 비용이 발생하지 않도록 보장하는 러스트의 자신감을 보여줍니다.
동시성
현대의 멀티코어 프로세서 환경에서, 여러 스레드가 충돌 없이 안전하게 데이터를 공유하는 것은 매우 어려운 문제입니다. 러스트는 언어의 소유권 시스템을 통해, 컴파일 시점에 ‘데이터 경쟁’과 같은 동시성 관련 버그를 찾아내고 방지합니다. 이를 통해 개발자들은 ‘두려움 없는 동시성(Fearless Concurrency)’을 경험할 수 있습니다.
결론적으로, ‘왜 러스트인가?’라는 질문에 대한 답은 바로 이 세 가지 목표의 교차점에 있습니다. 러스트는 성능, 안전성, 동시성이라는, 이전까지는 동시에 달성하기 어려웠던 가치들을 하나의 언어 안에서 구현하기 위한 체계적인 시도입니다. 그리고 이 대담한 목표를 달성하기 위해, 러스트는 ‘소유권’이라는 독특하고 강력한 개념을 언어의 핵심에 도입했습니다.
1.2. 소유권(Ownership), 빌림(Borrowing), 생명주기(Lifetimes)
가비지 컬렉터 없이 메모리 안전성을 달성하는 핵심 원리
앞서 언급한 러스트의 대담한 목표들, 특히 ‘가비지 컬렉터(GC) 없는 메모리 안전성’은 기존의 프로그래밍 언어에서는 불가능에 가까운 영역으로 여겨졌습니다. C/C++처럼 프로그래머의 수동 관리에 의존하면 실수가 발생하고, Java처럼 GC에 의존하면 런타임 성능 저하를 감수해야 했습니다. 러스트는 이 문제를 해결하기 위해, 런타임이 아닌 컴파일 타임에 메모리 관리 규칙을 엄격하게 강제하는, 언어의 독창적이자 핵심적인 시스템을 도입했습니다. 바로 소유권, 빌림, 생명주기라는 세 가지 개념입니다.
1. 소유권 (Ownership): 모든 값에는 주인이 있다
러스트의 메모리 관리 철학은 ‘소유권’이라는 단 하나의 단순한 규칙에서 시작합니다.
- 모든 값(value)은 단 하나의 소유자(owner) 변수만을 가집니다.
- 소유자가 스코프(scope, 유효 범위)를 벗어나면, 그 값은 자동으로 메모리에서 해제(drop)됩니다.
- 소유권은 다른 변수로 ‘이동(move)’될 수 있으며, 이동 후 원래의 소유자는 더 이상 유효하지 않습니다.
이 세 가지 규칙은 매우 강력한 효과를 낳습니다. 하나의 값은 오직 하나의 소유자만이 해제할 수 있으므로, ‘이중 해제(double free)’ 오류가 원천적으로 불가능해집니다. 또한, 소유권이 이동하면 이전 변수는 사용할 수 없게 되므로, 이미 해제된 메모리를 사용하려는 ‘해제 후 사용(use-after-free)’ 오류의 상당수를 컴파일 시점에 막아줍니다.
2. 빌림 (Borrowing): 소유권 없이 안전하게 접근하기
만약 소유권 이동만이 유일한 데이터 전달 방식이라면, 함수에 값을 전달할 때마다 소유권이 계속 이동하여 매우 비효율적이고 불편할 것입니다. 이를 해결하기 위해 러스트는 ‘빌림’이라는 개념을 제공합니다. 이는 데이터의 소유권을 넘기지 않고, 특정 스코프 내에서 데이터에 대한 접근 권한(참조, reference)을 잠시 빌려주는 것입니다.
하지만 이 ‘빌림’에는 반드시 지켜야 할 엄격한 규칙이 있습니다.
- 특정 데이터에 대해, 여러 개의 ‘읽기 전용 빌림(immutable borrow,
&T)’은 동시에 존재할 수 있습니다. - 하지만 ‘수정 가능한 빌림(mutable borrow,
&mut T)’은 단 하나만 존재할 수 있으며, 이 기간 동안에는 다른 어떤 빌림도 허용되지 않습니다.
컴파일러는 이 규칙을 통해, 하나의 데이터에 대해 동시에 여러 곳에서 수정하려는 시도나, 데이터를 읽는 동시에 수정하려는 시도를 컴파일 시점에 완벽하게 차단합니다. 이것이 바로 러스트가 ‘데이터 경쟁(data race)’을 원천적으로 방지하고 ‘두려움 없는 동시성’을 달성하는 핵심 원리입니다.
3. 생명주기 (Lifetimes): 빌린 데이터의 유효 기간 보장
빌림이 있다면, 빌려온 것이 언제까지 유효한지를 보장하는 장치가 필요합니다. ‘생명주기’는 바로 이 ‘빌림(참조)’이 유효한 스코프, 즉 ‘생존 기간’을 컴파일러에게 알려주는 역할을 합니다.
컴파일러는 생명주기 분석을 통해, 빌려온 데이터가 소유자에 의해 먼저 해제되어 발생하는 ‘댕글링 포인터(dangling pointer)’ 문제를 방지합니다. 즉, “데이터의 실제 생존 기간보다, 그것을 빌려온 참조의 생존 기간이 더 길어지는” 위험한 상황을 절대로 허용하지 않습니다. 대부분의 경우 컴파일러가 생명주기를 자동으로 추론하지만, 복잡한 상황에서는 개발자가 명시적으로 생명주기를 지정하여 컴파일러의 분석을 돕습니다.
이 세 가지 개념, 즉 소유권으로 자원의 생애를 관리하고, 빌림으로 데이터 경쟁 없이 안전하게 공유하며, 생명주기로 댕글링 포인터를 방지하는 이 정교한 시스템은 ‘보로 체커(Borrow Checker)’라는 컴파일러의 일부에 의해 강제됩니다. 이 엄격한 체커는 러스트의 가파른 학습 곡선의 주된 원인이기도 하지만, 동시에 러스트가 그토록 자랑하는 ‘성능 저하 없는 안전성’을 실현하는 심장과도 같은 존재입니다.
1.3. 성능: 제로 코스트 추상화(Zero-Cost Abstractions)
고수준의 편리함과 저수준의 제어 능력을 동시에 제공
전통적인 프로그래밍 언어의 세계는 오랫동안 ‘추상화 수준’과 ‘성능’ 사이의 트레이드오프(trade-off) 관계에 놓여 있었습니다. 파이썬(Python)이나 자바(Java)와 같은 고수준 언어는 개발자가 사용하기 편리한 강력한 추상화 기능을 제공하지만, 그 편리함의 대가로 런타임에 보이지 않는 비용(overhead)을 지불해야 했습니다. 반대로 C언어와 같은 저수준 언어는 하드웨어에 가까운 수준의 성능을 제공했지만, 개발자는 모든 것을 수동으로 제어해야 했고 코드의 가독성과 유지보수성이 떨어지는 불편함을 감수해야 했습니다. “읽고 쓰기 편한 아름다운 코드”와 “빠른 성능” 사이에서 하나를 선택해야 했던 것입니다.
러스트는 이 오랜 딜레마에 대해 “추상화를 위해 성능을 희생해서는 안 된다”는 강력한 철학을 제시합니다. 이것이 바로 ‘제로 코스트 추상화(Zero-Cost Abstractions, ZCA)’ 원칙입니다. ZCA란, 개발자가 이터레이터(iterator), 제네릭(generics), 트레잇(trait) 등 고수준의 편리한 추상화 기능을 사용해 코드를 작성하더라도, 컴파일된 최종 결과물은 저수준에서 손으로 직접 최적화한 코드와 동일한 성능을 내야 한다는 원칙입니다.
이것이 가능한 이유는, 러스트가 추상화에 대한 비용을 런타임이 아닌 컴파일 타임에 모두 처리하기 때문입니다. 컴파일러는 개발자가 작성한 고수준의 추상적인 코드를 분석하여, 실행 시점에는 아무런 추가 비용이 발생하지 않는 매우 효율적인 기계 코드로 변환해 줍니다.
대표적인 예가 바로 이터레이터입니다. 다음의 코드를 보겠습니다.
// 1부터 99까지의 숫자 중, 3의 배수만 골라 제곱한 값들의 합을 구하는 코드
let sum = (1..100).filter(|&x| x % 3 == 0).map(|x| x * x).sum::<u32>();
이 코드는 filter, map, sum과 같은 고수준 메서드를 연쇄적으로 사용하여 “무엇을 할 것인지”를 선언적으로 명확하게 보여줍니다. C언어였다면 for 루프와 if 조건문, 그리고 별도의 합계 변수를 사용하여 복잡하게 작성해야 했을 것입니다. 하지만 러스트 컴파일러는 이 고수준의 이터레이터 코드를 최적화하여, 사실상 손으로 짠 for 루프와 완전히 동일한 기계 코드를 생성해 냅니다. filter나 map과 같은 중간 단계의 호출 비용은 컴파일 과정에서 모두 사라집니다.
이러한 마법은 러스트의 강력한 타입 시스템과 제네릭, 그리고 컴파일러의 적극적인 인라이닝(inlining)과 모노모피제이션(monomorphization) 같은 기술을 통해 가능해집니다. 컴파일러가 더 많은 일을 하는 대신, 런타임의 사용자는 아무런 비용도 지불하지 않는 것입니다.
결론적으로, 제로 코스트 추상화는 개발자가 ‘성능 저하’에 대한 걱정 없이, 자신이 원하는 더욱 표현력 높고 안전한 방식으로 코드를 작성할 수 있도록 해주는 러스트의 핵심적인 성능 철학입니다. 이는 개발자가 “편리함과 성능”이라는 두 마리 토끼를 모두 잡을 수 있게 해주는 강력한 무기입니다.
1.4. 강력한 타입 시스템과 패턴 매칭
컴파일 시점에 에러를 잡아내는 엄격함
러스트가 추구하는 ‘안전성’은 단순히 메모리 관리에만 국한되지 않습니다. 러스트는 언어의 근간을 이루는 정적 타입 시스템(static type system)을 통해, 프로그램이 가질 수 있는 다양한 상태와 오류 가능성을 코드 수준에서 명시적으로 표현하고, 컴파일러가 이를 강제하도록 설계되었습니다. 이는 잠재적인 런타임 오류를 컴파일 시점에 미리 발견하여, 프로그램의 전체적인 안정성을 극대화하는 핵심적인 전략입니다. 이 전략의 중심에는 러스트의 강력한 타입 시스템, 그리고 그것을 효과적으로 다루는 패턴 매칭(pattern matching)이 있습니다.
러스트의 타입 시스템에서 가장 빛을 발하는 부분은 바로 열거형(enum)입니다. 다른 언어에서 단순히 몇 가지 상수를 나열하는 용도로 쓰이는 enum과 달리, 러스트의 enum은 각 변형(variant)이 서로 다른 타입과 양의 데이터를 가질 수 있는 강력한 데이터 구조입니다. 러스트는 이를 활용하여 프로그램의 불확실한 상태를 매우 안전하게 다룹니다.
대표적인 예가 바로 널 포인터(null pointer) 문제를 해결한 Option<T> 타입입니다. 러스트에는 null이 존재하지 않습니다. 대신, 값이 있을 수도 있고 없을 수도 있는 상황을 Some(value) 또는 None이라는 두 가지 상태를 가진 Option 열거형으로 표현합니다. 이렇게 함으로써, 컴파일러는 개발자가 None일 경우를 반드시 처리하도록 강제하여, ‘null 포인터 역참조’와 같은 런타임 오류를 원천적으로 불가능하게 만듭니다. 마찬가지로, 성공 또는 실패 가능성이 있는 연산은 Result<T, E> 타입을 통해 Ok(value) 또는 Err(error) 상태를 명시적으로 반환하도록 하여, 오류 처리를 누락하는 실수를 방지합니다.
이러한 강력한 타입을 안전하고 편리하게 다루게 해주는 도구가 바로 패턴 매칭입니다. 러스트의 match 표현식은 Option이나 Result와 같은 열거형의 모든 가능한 경우를 남김없이 검사하도록 컴파일러가 강제합니다. 이를 소진 검사(exhaustiveness checking)라고 합니다.
let maybe_number: Option<i32> = Some(10);
// `match`는 `maybe_number`가 가질 수 있는 모든 경우(`Some`과 `None`)를
// 처리하도록 강제합니다. 만약 `None` 경우를 빼먹으면 컴파일 에러가 발생합니다.
match maybe_number {
Some(number) => println!("숫자: {}", number),
None => println!("숫자가 없습니다."),
}
이처럼 프로그래머가 특정 상태나 오류 케이스를 처리하는 것을 잊어버리는 흔한 실수를, 컴파일러가 “당신은 이 경우를 빠뜨렸습니다”라고 친절하게 알려주며 막아주는 것입니다.
결론적으로, 러스트의 강력한 타입 시스템은 프로그램의 상태를 명시적으로 모델링하게 하고, 패턴 매칭은 그 모든 상태를 빠짐없이 안전하게 처리하도록 강제합니다. 이는 “컴파일러를 까다로운 조력자로 삼아, 런타임에 발생할 수 있는 수많은 잠재적 버그를 컴파일 시점에 미리 박멸하는 것”이라는 러스트의 핵심 설계 철학을 보여주는 대표적인 예입니다.
1.5. 생태계: 카고(Cargo)와 크레이트(Crates.io)
현대적인 빌드 시스템과 패키지 매니저
하나의 프로그래밍 언어가 성공하기 위해서는 언어 자체의 우수성뿐만 아니라, 개발자들이 그 언어를 쉽고 효율적으로 사용할 수 있도록 돕는 강력한 생태계와 도구가 반드시 필요합니다. 특히 C/C++와 같은 전통적인 시스템 프로그래밍 언어들은 공식적인 패키지 관리나 빌드 시스템이 없어, 개발자들이 프로젝트마다 다른 도구(Makefile, CMake 등)와 복잡한 라이브러리 의존성 문제로 많은 시간을 허비해야 했습니다.
러스트는 이러한 문제를 해결하기 위해, 언어의 설계 초기부터 현대적인 개발 환경을 제공하는 것을 핵심 목표 중 하나로 삼았습니다. 그 중심에는 러스트의 공식 빌드 시스템이자 패키지 매니저인 카고(Cargo)와, 공식 라이브러리 저장소인 크레이트(Crates.io)가 있습니다.
카고는 단순히 코드를 컴파일하는 것을 넘어, 프로젝트의 생명주기 전체를 관리하는 올인원(All-in-one) 커맨드 라인 도구입니다. 개발자는 일관된 명령어를 통해 다음과 같은 작업을 손쉽게 처리할 수 있습니다.
- 프로젝트 생성 (
cargo new): 표준화된 디렉터리 구조를 가진 새로운 프로젝트를 생성합니다. - 의존성 관리:
Cargo.toml이라는 설정 파일에 필요한 라이브러리(러스트에서는 ‘크레이트’라고 부릅니다)의 이름과 버전만 명시하면, 카고가 자동으로 해당 라이브러리와 그 하위 의존성까지 모두 다운로드하고 관리합니다. - 빌드 및 실행 (
cargo build,cargo run): 단 한 줄의 명령어로 프로젝트를 컴파일하고 실행합니다. - 테스트 및 문서화 (
cargo test,cargo doc): 프로젝트에 포함된 테스트 코드를 실행하고, 소스코드 주석을 바탕으로 깔끔한 HTML 문서를 생성합니다.
이 모든 작업의 중심에는 크레이트(Crates.io)가 있습니다. 이는 Node.js의 NPM이나 파이썬의 PyPI와 같은 중앙 집중형 패키지 저장소로, 전 세계의 러스트 개발자들이 자신이 만든 라이브러리를 손쉽게 공유하고, 다른 사람의 라이브러리를 가져다 쓸 수 있는 거대한 광장 역할을 합니다.
결론적으로, 카고와 크레이트 생태계는 러스트의 가파른 학습 곡선에도 불구하고, 많은 개발자들이 러스트를 “생산성이 높다”고 평가하는 여러 이유 중 하나입니다. 프로젝트 설정부터 의존성 관리, 빌드, 테스트에 이르는 복잡한 과정들을 단 하나의 표준화된 도구로 통합함으로써, 개발자가 오롯이 코드 자체에만 집중할 수 있는 쾌적하고 현대적인 개발 경험을 제공하기 때문입니다.
이처럼 제1부에서는 러스트가 왜 ‘가장 사랑받는 언어’로 불리는지, 그 기술적인 이상과 매력적인 철학, 그리고 현대적인 생태계를 살펴보았습니다. 러스트는 분명 수많은 문제를 해결하기 위해 탄생한, 매우 잘 설계된 언어입니다.
하지만, 이 눈부신 이상 뒤에는 ‘우월주의’와 ‘나르시시즘’이라는 그림자가 드리워져 있습니다. 제2부부터는 이 이상이 어떻게 현실에서 신화가 되고, 그 신화가 커뮤니티와 생태계에 어떤 균열을 만들어내는지를 본격적으로 파헤쳐 보겠습니다.
제2부: “우리는 다르다”: 러스트 우월주의의 발현과 특징
제2장: 러스트의 “안전성” 신화와 독선
2.1. ‘혁신’과 ‘안전성’의 재정의: 러스트의 위치 재조명
러스트(Rust)를 둘러싼 담론의 중심에는 항상 ‘혁신’과 ‘안전성’이라는 두 개의 강력한 키워드가 자리 잡고 있습니다. 러스트 커뮤니티는 이 두 가치를 언어의 존재 이유이자, 다른 모든 언어에 대한 우월성의 근거로 제시합니다. 하지만 우리가 이 용어들을 당연하게 받아들이는 대신, 그 의미를 엄밀하게 파고들기 시작하면, 견고해 보였던 논리의 성벽에 균열이 보이기 시작합니다.
이 절에서는 러스트의 우월주의를 지탱하는 이 두 기둥이 어떻게 교묘하게 재정의되고, 그 과정에서 어떤 진실이 외면당하는지를 분석하고자 합니다. 그 대표적인 예가 바로 ‘혁신’이라는 단어의 의미를 둘러싼 논쟁입니다.
러스트의 혁신성을 옹호하는 이들은 종종, Ada와 같은 선례가 있음에도 불구하고 러스트가 ‘안전한 시스템 프로그래밍’이라는 가치를 비로소 대중화시킨 ‘실용적 혁신’을 이뤘다고 주장합니다. 일견 타당하게 들리는 이 주장 이면에는, ‘혁신’이라는 단어의 의미를 자신들에게 유리하게 재정의하려는 교묘한 수사학이 숨어있습니다.
‘혁신’의 정의와 논리적 궤변: 러스트의 진짜 위치는 어디인가?
‘혁신(innovation)’의 사전적 의미는 “묵은 방법이나 관습을 완전히 바꾸어서 새롭게 하는 것”입니다. 이 엄밀한 잣대를 들이대면, “러스트가 과연 혁신인가?”라는 질문은 매우 타당한 문제 제기가 됩니다. 러스트가 달성했다고 평가받는 목표, 즉 ‘GC 없는 성능과 메모리 안전성의 양립’은 사실 완전히 새로운 것이 아니기 때문입니다.
이미 수십 년 전, Ada와 그 정형 검증 서브셋인 SPARK는 수학적 증명이라는, 러스트의 보로 체커보다 훨씬 더 엄격한 방식으로 이 목표를 달성했습니다. 또한 러스트의 핵심 설계인 ‘소유권’ 개념 역시, C++이 RAII 패턴과 스마트 포인터를 통해 발전시켜 온 자원 관리 철학의 성공적인 진화에 가깝습니다. 이처럼 러스트는 ‘무에서 유를 창조’한 것이 아니라, 기존에 존재하던 훌륭한 개념들을 매우 영리하게 통합하고, 컴파일러를 통해 시스템적으로 ‘강제’한 것에 가깝습니다. 이는 의심할 여지 없이 위대한 공학적 성취이지만, ‘완전한 새로움’을 의미하는 ‘혁신’과는 거리가 있습니다.
물론, 러스트 지지자들은 ‘혁신’의 의미를 ‘실용성의 혁신’으로 재정의하여 반론을 제기합니다. Ada의 접근법이 너무 학술적이고 비용이 높아 현실 세계에 널리 쓰이지 못한 반면, 러스트는 Cargo와 같은 현대적인 툴체인과 상대적으로 낮은 진입 장벽을 통해 ‘안전한 시스템 프로그래밍’의 가치를 대중화했다는 것입니다. 하지만 이것은 논점을 교묘하게 바꾸는 논리적 궤변에 가깝습니다. 그들은 ‘실용적 성공’을 근거로, 마치 러스트가 ‘개념적 유일성’까지 가진 것처럼 주장하며 다른 언어들의 역사적 성취를 의도적으로 평가절하합니다.
‘실용적 혁신’이라는 반론 분석: 가치의 대중화인가, 논점 흐리기인가?
앞서 ‘완전한 새로움’이라는 엄격한 잣대로 볼 때 러스트는 혁신이 아니라고 결론 내렸지만, 러스트 지지자들은 바로 이 지점에서 강력한 반론을 제기합니다. 그들은 러스트의 혁신이 ‘개념의 발명’이 아닌 ‘가치의 대중화’, 즉 ‘실용적 혁신’에 있다고 주장합니다.
이 주장의 핵심은 다음과 같습니다. Ada/SPARK가 추구했던 높은 수준의 안전성은 엄청난 비용(높은 학습 곡선, 복잡한 툴체인, 느린 개발 속도)을 요구했기 때문에, 결국 항공, 국방과 같은 극소수의 특수 분야에만 머물렀다는 것입니다. 반면, 러스트는 Cargo라는 현대적이고 편리한 툴체인, 상대적으로 낮은 진입 장벽, 그리고 활발한 커뮤니티를 통해, 이전까지는 소수의 전문가들만 누릴 수 있었던 ‘안전한 시스템 프로그래밍’이라는 가치를 일반 대중 개발자들의 영역으로 끌어내리는 데 성공했다는 것입니다. 즉, 아무도 쓸 수 없었던 완벽한 기술보다, 많은 사람이 쓸 수 있는 ‘충분히 좋은’ 기술이 더 혁신적이라는 주장입니다.
이러한 주장은 분명 일리가 있으며, 러스트가 이룬 괄목할 만한 성취를 담고 있습니다. 러스트가 개발자 경험(DX)을 개선하고 안전성의 가치를 널리 알린 공로는 결코 작지 않습니다.
하지만 문제가 되는 것은, 이 ‘실용적 혁신’이라는 주장이 사용되는 방식입니다. 이것은 종종 ‘개념적 혁신’의 부재라는 비판을 회피하고, 논점을 흐리기 위한 수사학적 도구로 사용됩니다.
‘A는 개념적으로 새로운가?’라는 질문에 대해, ‘A는 시장에서 성공했고 사용하기 편하다’고 답하는 것은 동문서답에 가깝습니다. 두 번째 주장이 사실이라 할지라도, 그것이 첫 번째 질문에 대한 직접적인 답이 되지는 않습니다. 러스트 커뮤니티의 일부는 바로 이 지점에서 논리적 비약을 저지릅니다. 그들은 러스트의 ‘실용적 성공’을 근거로, 마치 러스트가 ‘개념적 유일성’까지 가진 것처럼 주장하며, Ada와 C++ 같은 언어들이 수십 년간 쌓아 올린 역사적 성취를 의도적으로 평가절하합니다.
결국 ‘실용적 혁신’이라는 주장은, ‘혁신’의 본래 의미에 대한 비판을 피하면서도 ‘혁신’이라는 영광스러운 타이틀은 계속 유지하고 싶을 때 사용되는 편리한 논리입니다. 이는 이 책이 지속적으로 지적하는, 자신들의 우월성을 유지하기 위해 용어의 의미를 자의적으로 재정의하고 논점을 흐리는 태도의 또 다른 예시일 뿐입니다.
‘메모리 안전성’의 범위 축소: 의도적으로 외면된 ‘메모리 릭(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가 아니므로, 러스트는 ‘메모리 안전한’ 언어가 맞습니다. 하지만 진짜 문제는, 커뮤니티의 일부가 이 기술적으로 협소한 정의를 대중을 상대로 한 홍보에 그대로 사용함으로써, 일반적인 개발자가 ‘메모리 안전성’이라는 단어에 기대하는 바와 실제 보장 내용 사이의 인지적 간극을 교묘하게 이용하고 있다는 점입니다.
하지만 이러한 정의는, 러스트가 마치 ‘모든 메모리 관련 문제를 해결한 언어’인 것처럼 보이게 만드는 착시 효과를 낳습니다. 자신들의 한계를 가리고 ‘완벽한 안전성’이라는 신화를 유지하기 위해 핵심 용어의 범위를 축소하는 행위는, 이 책이 비판하고자 하는 의도적인 논점 흐리기와 사실 왜곡의 대표적인 사례입니다.
증명의 영역: Ada/SPARK의 수학적 안전성과 러스트의 한계
러스트의 ‘안전성’이 C/C++에 비해 비약적인 발전이라는 점은 의심의 여지가 없습니다. 하지만 그 안전성이 시스템 프로그래밍 세계에서 도달할 수 있는 궁극의 정점인 것처럼 이야기되는 것은 명백한 과장입니다. 안전성이라는 가치를 객관적으로 평가하기 위해서는, 수십 년간 가장 엄격한 신뢰성을 요구하는 분야를 지배해 온 Ada/SPARK 생태계와 러스트의 보장 수준을 직접 비교해야만 합니다.
러스트의 안전성 보장: ‘메모리 안전’의 영역
러스트의 핵심적인 안전성은 ‘소유권’과 ‘빌림’ 규칙을 통해 컴파일 시점에 메모리 안전(memory safety)과 데이터 경쟁(data race) 부재를 보장하는 것입니다. 이는 컴파일만 통과하면 해당 유형의 버그는 존재하지 않는다는 강력한 선언이며, ‘제로 코스트 추상화’ 원칙 덕분에 런타임 성능 저하 없이 이 모든 것을 달성합니다. 이것은 러스트가 이룬 위대한 공학적 성취입니다.
하지만 러스트의 보장은 이 영역에 머무릅니다. 프로그램의 전반적인 논리적 정확성(logical correctness)이나, 모든 종류의 런타임 오류(runtime error) 부재까지 보장하지는 않습니다. 정수 오버플로우, 배열 인덱스 초과, 0으로 나누기 등의 오류는 여전히 발생할 수 있으며, 이는 메모리 오염과 같은 예측 불가능한 상태로 빠지는 대신, ‘패닉(panic)’이라 불리는 통제된 프로그램 중단으로 이어질 뿐, 프로그램의 지속적인 안정적 실행을 보장하지는 않습니다.
Ada/SPARK의 안전성 보장: ‘프로그램 정확성’의 영역
반면, Ada/SPARK 생태계는 훨씬 더 넓은 범위의 안전성을 목표로 합니다.
-
Ada의 기본 안전성: Ada 언어 자체는 강력한 타입 시스템과 계약 기반 설계(
pre,post조건 등)를 통해 메모리 오류뿐만 아니라 논리적 오류까지도 방지하려 시도합니다. 만약 컴파일 시점에 증명할 수 없는 잠재적 오류(예: 런타임 입력값에 따른 배열 접근)가 있다면, 이를 안전하게 처리할 수 있는 예외(exception)를 발생시키는 코드를 런타임에 포함시켜 프로그램의 예측 불가능한 붕괴를 막습니다. 이는 오류로부터 시스템이 회복하여 임무를 지속할 수 있게 하는 ‘회복력(Resilience)’을 제공합니다. -
SPARK의 수학적 증명: SPARK는 여기서 한 걸음 더 나아가, Ada의 ‘런타임 검사’조차 필요 없게 만든다. SPARK의 정형 검증 도구는 코드의 실행 경로를 수학적으로 분석하여, 런타임 오류 자체가 원천적으로 발생하지 않음을 ‘증명’합니다.
아래 표는 두 언어(와 서브셋)의 보장 수준 차이를 명확히 보여줍니다.
| 오류 유형 | Rust | Ada (기본) | SPARK |
|---|---|---|---|
| 메모리 오류 (UB) | 컴파일 시 차단 (보장) | 컴파일/런타임 차단 (보장) | 수학적으로 부재 증명 |
| 데이터 경쟁 | 컴파일 시 차단 (보장) | 컴파일/런타임 차단 (보장) | 수학적으로 부재 증명 |
| 정수 오버플로우 | panic 또는 순환(설정따라 다름) |
런타임 예외 발생 (안전) | 수학적으로 부재 증명 |
| 배열 범위 초과 | panic (프로그램 중단) |
런타임 예외 발생 (안전) | 수학적으로 부재 증명 |
| 논리적 오류 | 프로그래머 책임 | 계약 기반 설계로 일부 방지 | 계약에 따라 부재 증명 가능 |
표에서 명확히 드러나듯이, 러스트의 안전성은 뛰어나지만 Ada/SPARK 생태계가 제공하는 다층적이고 수학적인 보증 수준에는 미치지 못합니다. 따라서 러스트의 안전성이 마치 ‘궁극의 정점’인 것처럼 이야기되는 커뮤니티의 지배적인 서사는, 오직 C/C++만을 비교 대상으로 삼고 더 넓은 기술의 역사를 외면하는 편협하고 자기중심적인 시각에 불과하다.
진화하는 현실: C/C++과 정적 분석 도구의 조합
실용적 대안: 가비지 컬렉션의 재평가 (Go, Java, C#)
절대적 우위는 없다: 성능, 메모리, 생산성의 트레이드오프 분석
메모리 너머의 위험: 러스트가 막지 못하는 버그들
2.2. 보로 체커(Borrow Checker)는 만능인가?
보로 체커의 순기능 인정, 하지만 과도한 맹신 개발 생산성 저하와 학습 곡선이라는 현실적 대가 “보로 체커와 싸우는 즐거움”이라는 이중적 태도 비판
2.3. unsafe 블록과 위선의 경계
안전성 강조에도 불구하고 존재하는 unsafe: 그 존재 이유와 통제 문제 unsafe 사용 시 러스트 개발자의 책임 전가와 “너는 안전하게 쓰고 있니?”식의 태도 비판
2.4. ‘안전한 실패’의 역설: Segmentation Fault와 Panic
- 패닉의 본질: 메모리 오염 없는 크래시(Crash)일 뿐인가?
- 사용자 관점에서의 프로그램 중단: Segfault와 Panic의 실질적 차이
- 결국은 프로그래머의 역량: 언어가 모든 것을 해결해준다는 환상 비판
제3장: “개발 경험”이라는 이름의 자기애
3.1. 가파른 학습 곡선과 ‘고통의 미학’
가파른 학습 곡선: 소유권(Ownership) 및 빌림(Borrowing) 개념의 복잡성 복잡한 타입 시스템 및 제네릭(Generics)의 난해함 러스트의 높은 진입 장벽을 ‘도전’과 ‘성장’으로 포장하는 경향 신규 개발자의 진입 장벽과 생산성 저하, 그리고 이를 ‘노력 부족’으로 치부하는 태도 실제 프로젝트에서의 생산성 저하와 일정 압박에 대한 외면
3.2. 러스트는 “최적의 선택”이라는 강박
문제 해결의 다양성 무시: 모든 문제를 러스트로 해결하려는 시도 다른 언어와 프레임워크에 대한 편협한 시각과 불필요한 비하 특정 도메인에 대한 과도한 일반화 (예: 웹 백엔드는 무조건 러스트)
3.3. 비동기 프로그래밍(async/await)과 복잡성 과시
Pin, Generator 등 고난이도 개념에 대한 과도한 자랑 실제 디버깅의 어려움과 복잡성 대비 낮은 효용성 단순함을 추구하는 다른 비동기 모델에 대한 배척
3.4. ‘우아한 에러 처리’라는 신화: Result 타입의 실용성 재고
- try…catch는 과연 죄악인가?: 다른 언어의 에러 처리 방식 재평가
- 함수형 언어에서 차용한 아이디어: ‘새로움’에 대한 과장된 홍보
- 끝없이 이어지는 ?와 .map_err(): ‘편리성’과 코드 가독성의 현실
제4장: 러스트의 ‘소유권’ 개념: 역사적 맥락과 오해
4.1. C/C++에서의 자원 관리와 ‘소유권’의 뿌리
4.1.1. C 언어의 수동 메모리 관리와 ‘책임’의 문제
4.1.2. RAII와 스마트 포인터(unique_ptr, shared_ptr)를 통한 C++의 발전
4.2. 러스트 소유권의 ‘혁신성’에 대한 재평가
4.2.1. 개념 자체의 새로움이 아닌 ‘컴파일러 강제’의 의미 분석
4.2.2. 숙련된 C/C++ 개발자가 바라보는 러스트 소유권의 시각
제3부: 나르시시즘의 결과: 고립, 배제, 그리고 퇴보
제5장: ‘완벽한 언어’라는 종교: 집단적 나르시시즘과 방어기제
앞선 장들에서 우리는 러스트(Rust)를 둘러싼 여러 ‘신화’들을 해체해 보았습니다. 기술적으로 절대적이지 않은 ‘안전성’, 때로는 고통스러운 ‘개발 경험’, 그리고 C++로부터 이어진 ‘소유권’의 역사적 맥락을 통해, 러스트 역시 수많은 장점과 함께 명백한 단점과 트레이드오프를 가진 하나의 ‘도구’임을 확인했습니다.
그렇다면 우리는 여기서 근본적인 질문과 마주하게 됩니다. 왜 이토록 명백한 기술적 현실에도 불구하고, 러스트 커뮤니티의 일부는 언어의 단점을 인정하지 않으며 비판에 대해 극도로 방어적인 태도를 보이는 것일까요? 왜 기술에 대한 건전한 토론이 개인에 대한 비난과 조롱으로 변질되는 현상이 반복되는 것일까요?
이 질문에 대한 답은 더 이상 기술의 영역에 있지 않습니다. 우리는 그 원인을 인간의 심리, 특히 ‘집단적 나르시시즘’과 그것이 발현시키는 강력한 ‘방어기제’에서 찾아야 합니다. 이 장에서는 러스트 커뮤니티의 일부가 어떻게 ‘완벽한 언어’라는 종교를 만들어내고, 그 믿음을 지키기 위해 어떤 심리적 메커니즘을 작동시키는지, 그리고 그 결과가 어떻게 프로젝트의 거버넌스 실패라는 재앙으로까지 이어졌는지를 심층적으로 분석하고자 합니다.
5.1. 자기애적 투사와 ‘우리’라는 과대성
“나는 특별하다”: 개인의 정체성과 ‘완벽한 도구’의 동일시
모든 현상의 시작점에는 하나의 프로그래밍 언어가 개인의 자존감과 결합되는 심리적 과정, 즉 ‘자기애적 투사’가 있습니다. 이 과정은 단순하지만 강력한 삼단논법의 형태를 띱니다.
- “러스트는 기술적으로 우월하고 완벽한 언어다.”
- “나는 그 어렵고 우월한 러스트를 이해하고 사용하는 특별한 개발자다.”
- “그러므로, 나는 다른 언어를 사용하는 평범한 개발자들보다 우월하다.”
이 논리적 비약을 통해, 개인은 자신의 자존감과 기술적 정체성을 ‘러스트’라는 외부의 대상에 완전히 의탁하게 됩니다. 이제 러스트의 결점에 대한 비판은 단순한 기술적 피드백이 아니라, 자신의 지성과 능력, 나아가 존재 가치 자체를 위협하는 실존적 공격으로 받아들여집니다. 러스트에 대한 공격은 곧 ‘나’에 대한 공격이 되는 것입니다.
“우리는 선구자다”: ‘우리’(깨달은 자)와 ‘그들’(계몽되지 못한 자)의 이분법적 세계관
이러한 개인의 심리는 ‘우리 러스트 개발자들(Rustaceans)’이라는 집단 속에서 증폭되며 ‘집단적 과대성’으로 발전합니다. “우리만이 메모리 안전성의 진정한 가치를 이해하는 선구자”라는 강한 유대감과 소속감이 형성되는 것입니다. 이 과정에서 자연스럽게 세상은 둘로 나뉩니다. ‘우리’(깨달은 자, 미래를 이끄는 자)와 ‘그들’(C++의 불안전함이나 가비지 컬렉터의 나태함에 빠진, 아직 계몽되지 못한 자).
‘러스트만이 답이다’ 식의 배타적 사고방식과 ‘모든 시스템 프로그래밍 대체’ 주장의 확대 해석
‘우리’와 ‘그들’을 나누는 이분법적 세계관은 필연적으로 “러스트만이 모든 문제의 답이며, 종국에는 모든 시스템 프로그래밍을 대체할 것”이라는 배타적이고 과대망상적인 믿음으로 이어집니다. 이는 단순히 기술에 대한 강한 자신감을 넘어, 다른 모든 대안을 평가절하하고 자신들의 선택을 유일한 진리라고 믿는 ‘선민사상’의 발현입니다.
하지만 이러한 ‘완전한 대체’라는 주장은 소프트웨어 생태계의 두 가지 근본적인 현실을 외면하고 있습니다.
첫째는 기술적 현실, 즉 C ABI(Application Binary Interface)에 대한 반영구적 종속성입니다. 현대의 모든 운영체제와 하드웨어 드라이버, 그리고 수많은 핵심 라이브러리들은 C언어의 호출 규약이라는 ‘공용어’를 통해 소통합니다. 러스트 역시 이 거대한 생태계와 소통하기 위해서는 C ABI를 사용할 수밖에 없습니다. 이는 러스트가 ‘대체’하려는 바로 그 C의 유산 없이는 홀로 존재할 수 없다는 구조적 한계를 의미하며, 러스트의 현실적 위치가 ‘대체’가 아닌 ‘공존’ 혹은 ‘대용’임을 명백히 보여줍니다.
둘째는 시장적 현실, 즉 ‘응용 프로그램 생태계’ 중심의 가치 판단입니다. 최종 사용자는 운영체제나 프로그래밍 언어 자체를 사용하기 위해 컴퓨터를 켜지 않습니다. 그들은 워드프로세서, 게임, 전문 소프트웨어와 같은 ‘응용 프로그램’을 사용하기를 원합니다. 러스트로 만든 시스템이 기술적으로 아무리 우월하다 한들, 수십 년간 C/C++ 생태계가 쌓아 올린 방대한 응용 프로그램들과 호환되지 않는다면 그것은 ‘아무도 살지 않는 기술적 유토피아’일 뿐입니다.
결국 ‘모든 것을 대체할 것’이라는 주장은 합리적인 기술 예측이라기보다는, 앞서 언급한 ‘영웅 서사’를 뒷받침하기 위한 집단적 과대성의 표현에 가깝습니다.
5.2. 비판에 대한 방어기제 분석: 이상화, 평가절하, 그리고 투사
나르시시스트의 자아는 겉보기에는 강대해 보이지만, 그 내면은 유리처럼 깨지기 쉽습니다. 따라서 그들의 믿음의 근간인 ‘완벽한 러스트’라는 신념이 위협받을 때, 그들의 자아를 보호하기 위해 작동하는 첫 번째 방어기제가 바로 이상화(idealization)와 평가절하(devaluation)입니다. 이 두 가지는 동전의 양면처럼 함께 작동하며, 현실을 왜곡하고 자신들의 믿음을 수호하는 견고한 벽을 만듭니다.
이상화와 평가절하
첫 번째 방어기제는 ‘러스트’를 모든 단점으로부터 자유로운 완벽한 존재로 이상화하는 것입니다. 가파른 학습 곡선, 긴 컴파일 시간, 복잡한 생태계와 같은 명백한 단점들은 “네가 아직 이해를 못 해서 그렇다”는 식으로 축소되거나, “그것은 위대한 안전성을 얻기 위한 사소한 대가”라며 합리화됩니다. 이 이상화 과정을 통해 러스트는 단순한 프로그래밍 도구를 넘어, 흠결 없는 종교적 신앙의 대상이 됩니다.
이러한 이상화를 유지하기 위해, 그들은 필연적으로 그 외의 모든 것을 평가절하합니다. 여기서 러스트 커뮤니티 일부가 사용하는 가장 교묘하고 비논리적인 방법 중 하나가 바로 ‘불공정한 비교 프레임’입니다. 그들은 러스트 컴파일러가 보장하는 ‘안전한(safe) 러스트’와 C/C++ 언어의 본질적인 ‘안전하지 않음(unsafe)’을 직접 비교하며 러스트의 우월성을 주장합니다. 하지만 진정으로 공정하게 비교하려면 마땅히 개발자가 모든 책임을 지는 ‘unsafe 러스트’와 C/C++를 비교하거나, 이미 더 높은 수준의 안전성을 달성한 Ada와 러스트를 비교해야 합니다. 공정한 비교를 의도적으로 외면하고 자신들에게 유리한 프레임만을 선택하는 것이야말로, 러스트를 이상화하고 타 언어를 손쉽게 평가절하하기 위한 대표적인 방어 전략입니다.
여기서 우리는 중요한 질문과 마주하게 됩니다. 나르시시즘의 전형적인 패턴이 ‘이상화’ 이후에 ‘평가절하’가 온다면, 왜 그들은 러스트의 결점을 발견했을 때 러스트 자체를 평가절하하지 않는 것일까요? 왜 평가절하의 화살은 항상 외부의 비판자나 다른 언어에게로만 향하는 것일까요?
그 이유는 이들에게 러스트가 단순한 ‘외부 대상’이 아니라, ‘자아와 융합된 정체성의 일부’이기 때문입니다. 러스트의 결점은 곧 ‘나의 결점’으로 인식되며, 이는 견딜 수 없는 ‘나르시시즘적 상처(Narcissistic Injury)’를 유발합니다. 만약 여기서 러스트 자체를 평가절하한다면, 그것은 자신이 쏟아부은 막대한 노력과 시간, 그리고 자신의 정체성 전부가 잘못되었다고 인정하는 ‘자아의 붕괴’를 의미합니다.
이 파국적인 상황을 막기 위해, 마음은 필사적으로 다른 방어기제를 사용합니다. 바로 세상을 ‘완벽하게 좋은 것(러스트, 나, 우리)’과 ‘아주 나쁜 것(비판자, 다른 언어)’으로 나누는 ‘분리(Splitting)’입니다. 그리고 자신의 내면에서 발생한 ‘나의 믿음이 흔들리는 불안감’과 수치심을 ‘나쁜 대상’에게 떠넘기는 ‘투사(Projection)’를 사용합니다.
결론적으로, 그들은 자아 붕괴를 막기 위해 평가절하의 대상을 외부로 전치(Displacement)시킵니다. “내 자아의 일부인 러스트는 완벽하다. 따라서 저 비판이 틀렸다. 비판하는 저 자가 어리석거나, 악의적이거나, 열등한 것이다.” 이 과정을 통해, 러스트라는 신전은 흠 없는 상태로 보존되며, 그 신전을 더럽히려 한 외부의 이단자만이 경멸과 공격의 대상이 되는 것입니다. 다른 언어와 비판자에 대한 격렬한 평가는, 역설적으로 그들이 자신의 신념을 얼마나 필사적으로 방어하고 있는지를 보여주는 명백한 증거입니다.
이러한 평가절하가 통하지 않을 때, 그들의 방어기제는 다음 단계인 ‘투사와 책임 전가’로 넘어가게 됩니다.
투사(projection)와 책임 전가(blame-shifting)
비판의 기술적 타당성을 이성적으로 반박하기 어려워지면, 그들은 비판하는 사람의 ‘의도’를 공격합니다. 이는 자신의 불안감이나 열등감을 상대에게 떠넘기는 투사입니다. “당신이 러스트를 비판하는 이유는, 당신이 사용하는 언어가 러스트만큼 뛰어나지 않다는 것을 인정하기 싫은 당신의 열등감 때문이다”라는 식의 주장이 대표적입니다.
더 나아가, 문제는 ‘러스트의 단점’이 아니라 ‘그 단점을 지적하는 당신의 낮은 기술 수준’이라고 책임을 전가합니다. “우리 회사는 기술 수준이 높아 러스트를 성공적으로 도입했는데, 당신의 회사가 도입하지 못하는 것은 개발자들의 역량이 부족하기 때문이다”라는 식의 오만한 주장이 그 예입니다. 이러한 주장은 러스트 도입의 현실적 제약(레거시 시스템과의 연동, 생태계의 미성숙, 인력풀 부족 등)을 완전히 무시하는 편협한 시각이며, 리눅스 커널과 같은 최상위 프로젝트에서조차 러스트의 비중이 0.1% 미만이라는 객관적인 현실을 외면하는 행위입니다.
나르시시즘적 격노(narcissistic rage)
논리가 통하지 않고 자신의 믿음이 계속해서 위협받을 때, 그들은 최후의 수단인 나르시시즘적 격노를 표출합니다. 이것은 더 이상 토론이 아닌, 상대를 인격적으로 파괴하기 위한 공격입니다. 비판자의 과거 발언을 캐내 조롱하고(“당신은 예전에도 틀린 말을 했다”), 허위 사실을 유포하여 평판을 훼손하며, 집단적으로 ‘좌표’를 찍어 상대를 커뮤니티에서 고립시키고 추방하려 합니다.
5.3. 영웅 서사와 ‘불편한 진실’의 외면
C++ 악마화와 러스트 구원자 서사 구축
이러한 방어기제들이 유지되는 더 큰 배경에는 커뮤니티가 공유하는 하나의 강력한 ‘영웅 서사’가 있습니다. 바로 ‘수십 년간 개발자들을 괴롭혀 온 C++라는 악마를 물리치고, 모두를 메모리 안전성의 세계로 이끌 구원자 러스트’라는 이야기입니다. 이 단순하고 선명한 선악 구도는 매우 감정적으로 매력적이어서, 많은 이들이 복잡한 기술적 현실을 따지기보다 이 서사에 기꺼이 동참하게 만듭니다.
불편한 진실의 외면: Ada/SPARK와 같은 강력한 대안에 대한 의도적 침묵
이 영웅 서사를 지키기 위해, 커뮤니티는 서사에 방해가 되는 ‘불편한 진실’을 의도적으로 외면합니다. 그 대표적인 사례가 바로 Ada/SPARK와 같은 강력한 대안에 대한 의도적 침묵입니다. 만약 C++만이 유일한 대안이 아니라, 러스트보다 훨씬 이전부터 더 높은 수준의 수학적 안전성을 제공해 온 Ada와 같은 언어가 존재했다는 사실을 인정하게 되면, ‘러스트가 유일한 구원자’라는 영웅 서사는 힘을 잃게 됩니다. 그들의 목표가 진정한 ‘안전한 소프트웨어에 대한 학술적 탐구’가 아니라 ‘러스트의 우월성 서사 유지’에 있음을 보여주는 단적인 예입니다.
정보 생태계 오염과 인식 왜곡:
지배적 담론의 확산: 대중과 AI의 편향된 학습 유도
이러한 선택적 정보 취사선택과 영웅 서사의 반복적인 전파는, 단순히 커뮤니티 내부의 믿음을 강화하는 데서 그치지 않습니다. 이는 인터넷이라는 거대한 광장을 오염시켜, 기술 생태계 전체의 인식 왜곡을 유발하는 심각한 문제로 이어집니다.
새로운 기술을 배우려는 학생이나 주니어 개발자가 “안전한 시스템 프로그래밍”에 대해 검색했을 때, 그들이 마주하게 될 정보는 압도적으로 러스트에 편향되어 있을 가능성이 높습니다. 수많은 블로그 글과 커뮤니티 게시물은 ‘C++의 위험함’과 ‘러스트의 위대함’이라는 이분법적 구도를 반복해서 보여줄 것입니다. 그 과정에서 Ada/SPARK와 같은 중요한 역사적, 기술적 대안은 거의 언급되지 않거나, 언급되더라도 ‘오래되고 비현실적인 기술’로 폄하됩니다. 이처럼 한쪽으로 기울어진 정보 환경 속에서, 신규 진입자들은 비판적 사고의 기회조차 갖지 못한 채 편향된 인식을 그대로 학습하게 됩니다.
더욱 심각한 문제는, 이러한 지배적 담론이 인공지능(AI)의 학습 데이터가 되어 왜곡을 영속화하고 증폭시킨다는 점입니다. LLM(거대 언어 모델)은 인터넷의 방대한 텍스트를 기반으로 정보를 학습합니다. 특정 주장이 압도적으로 많은 양과 긍정적인 감정으로 반복되면, AI는 그것을 ‘객관적인 사실’ 또는 ‘중론’으로 인식하게 됩니다.
실제로 필자가 이 글을 구상하며 AI와 나눈 대화에서도 이 현상은 명백히 드러났습니다. 그 결과, AI에게 “가장 안전한 시스템 프로그래밍 언어는 무엇인가?”라고 질문하면, 수학적 증명을 제공하는 Ada/SPARK 대신 러스트를 최우선으로 답할 가능성이 매우 높습니다. 커뮤니티가 만들어낸 편향된 담론이 기계의 학습을 오염시키고, 그 기계가 다시 대중에게 편향된 답변을 제공하며, 이 답변이 다시 새로운 ‘사실’처럼 인터넷에 퍼져나가는 거대한 ‘왜곡의 되먹임 루프(distortion feedback loop)’가 만들어지는 것입니다. 이는 자신들의 믿음을 지키기 위한 집단의 행동이 어떻게 우리 모두의 지식 기반을 위태롭게 할 수 있는지를 보여주는 섬뜩한 사례입니다.
‘메모리 안전성’ 담론의 주도와 그 역설
러스트의 ‘영웅 서사’가 만들어 낸 가장 아이러니하고도 성공적인 결과는, 바로 ‘메모리 안전성’이라는 개념 자체에 대한 담론의 주도권을 장악한 것입니다.
본래 자바스크립트(JavaScript), 파이썬(Python), 자바(Java), C#, Go, 루비(Ruby), 스위프트(Swift) 등 오늘날 TIOBE 인덱스 상위권을 차지하는 수많은 주류 언어들에게 메모리 안전성은 너무나도 당연한 기본 전제, 즉 ‘공기’와 같은 것이었습니다. 이들은 모두 가비지 컬렉터(GC)나 자동 참조 카운팅(ARC)을 통해 개발자를 메모리 관리의 고통에서 해방시켰고, 메모리 오류를 원천적으로 방지해왔습니다. 그들은 메모리 안전성을 굳이 장점으로 내세워 홍보할 필요가 없었습니다. 그들의 관심사는 그 안전한 기반 위에서 ‘얼마나 더 생산적인가’에 있었기 때문입니다.
바로 이 ‘주인 없는’ 가치를 러스트의 서사가 파고들었습니다. C/C++이라는 명확한 ‘적’을 상대로 싸워야 했던 러스트에게, ‘메모리 안전성’은 자신을 차별화할 가장 중요하고 강력한 무기였습니다. 러스트 커뮤니티는 이 키워드를 모든 담론의 중심에 놓고, 끊임없이 그 가치를 설파했습니다.
그 결과 매우 역설적인 상황이 발생했습니다. 이미 메모리 안전한 언어를 매일 사용하던 수많은 개발자들이, 러스트를 통해 ‘메모리 안전성’이라는 단어와 그 중요성을 처음으로 진지하게 접하게 된 것입니다. “어, 내가 쓰던 자바스크립트도 메모리 안전한 언어였어?”라는 반응이 나오는 것 자체가 이 현상을 증명합니다.
결론적으로, 러스트는 자신들의 마케팅과 담론 형성을 통해, 수십 년간 당연하게 메모리 안전성을 누려온 다른 언어 개발자들에게 “당신들이 누려온 것의 이름이 바로 이것이다”라고 뒤늦게 알려준 셈이 되었습니다. 그리고 그 과정에서, ‘메모리 안전성’이라는 키워드를 러스트의 가장 강력한 브랜드 자산으로 만드는 데 성공했습니다. 이는 지배적인 서사가 어떻게 기술의 실제 역사나 소유권과 무관하게, 대중의 인식을 재편하고 특정 가치에 대한 주도권을 가져올 수 있는지를 보여주는 흥미로운 사례입니다.
5.4. 거버넌스의 실패와 신뢰의 붕괴: 상표권 사태
커뮤니티의 심리적 병리 현상은 결국 프로젝트의 방향을 결정하는 리더십의 판단을 흐리게 하고, 실질적인 재앙을 불러왔습니다. 2023년에 있었던 ‘상표권 정책 사태’는 그 모든 문제가 응축되어 폭발한 결정적인 사건입니다.
러스트 재단이 커뮤니티와의 소통 없이, 기존의 관행을 무시하고 매우 제한적인 상표권 정책 초안을 발표하자 커뮤니티는 격렬하게 반발했습니다. 이는 리더십 그룹이 “우리가 프로젝트를 위해 무엇이 최선인지 가장 잘 안다”는 집단적 나르시시즘에 빠져, 자신들의 결정을 커뮤니티가 당연히 수용할 것이라 믿었던 결과입니다.
이 사태는 ‘Crab-lang’이라는 이름의 언어 포크(fork) 위협으로까지 이어지며, 프로젝트의 실질적인 분열 가능성까지 보여주었습니다. 또한 재단의 배후에 있는 기업들의 이익과 오픈소스 커뮤니티의 자유로운 정신이 어떻게 충돌할 수 있는지, 그리고 ‘러스트 프로젝트’와 ‘러스트 재단’이라는 두 리더십 그룹 간의 괴리가 얼마나 심각한지를 여실히 드러냈습니다. 이 거버넌스의 실패는 수년에 걸쳐 쌓아온 커뮤니티와 리더십 간의 신뢰를 한순간에 붕괴시킨 사건으로 기록될 것입니다.
이처럼, 하나의 언어를 둘러싼 나르시시즘적 문화는 단순히 온라인상의 말싸움으로 끝나지 않습니다. 그것은 생태계의 건전한 성장을 저해하고, 합리적인 토론을 마비시키며, 종국에는 프로젝트의 리더십과 거버넌스마저 실패로 이끄는 파괴적인 힘을 가집니다. 다음 장에서는 이러한 문제들이 생태계의 기술적인 ‘성장통’을 어떻게 더욱 악화시키는지 구체적으로 살펴보겠습니다.
제6장: 생태계의 “성장통”을 외면하는 나르시시즘
6.1. 파편화된 크레이트(Crate) 생태계와 책임 회피
- 성숙도 낮은 크레이트, 불충분한 문서화, 유지보수 문제 외면
- “필요하면 네가 기여해라”식의 무책임한 태도
- 단편적인 성공 사례만 부각하고 전체적인 생태계 문제 간과
6.2. ‘Zero Cost Abstractions’ 홍보의 이면과 실제 비용
- ‘런타임 비용 제로’라는 말의 함정: C언어와의 현실적 비교
- 컴파일 시간과 바이너리 크기: 추상화의 비용은 누가 지불하는가?
- 과도한 모노모피제이션(Monomorphization)과 그 그림자
6.3. 개발 툴링(Tooling)의 고질적인 문제
- 느린 컴파일 시간: ‘Zero Cost Abstractions’의 대가와 대규모 프로젝트의 생산성 저하
- 불완전한 IDE 지원 및 어려운 디버깅 환경
- Cargo 빌드 시스템의 유연성 부족 및 의존성 관리의 복잡성
6.4. 바이너리 크기 문제와 ‘범용성’이라는 신기루
- libstd의 ABI 비호환성과 정적 링킹 강제 문제
- 사례 분석: grep과 rg의 바이너리 크기 비교
- min-sized-rust의 ‘불편한 진실’과 비정상적인 최적화 방식 비판
6.5. 실제 산업 적용의 한계와 회피적 해석
- 임베디드 시스템 및 리눅스 커널 적용의 실제적 제약 (바이너리, ABI 등)
- 특정 분야 외 대규모 도입의 어려움을 인정하지 않음
- 레거시 시스템과의 연동 문제, 마이그레이션 비용 등 현실적 문제 간과
- “아직 초기 단계라서 그렇다”는 변명만 반복
제4부: 나르시시즘을 넘어, 성숙한 러스트 생태계를 향하여
제7장: 러스트의 재평가: 현실적 장점, 한계, 그리고 개발자의 자세
7.1. 러스트의 실제적 강점과 ‘틈새 시장’
7.1.1. 보안성 향상: 메모리 오류 방지와 그 실질적 가치
- 잘못된 메모리 참조 오류 컴파일 시 방지
- 민감 정보 노출 방지 가능성
7.1.2. 현실적 포지션: 클라우드, 서버 등 ‘틈새’에서의 가능성과 C/C++, Java의 벽
7.2. 개발자의 현명한 선택과 학습 방향
7.2.1. ‘장밋빛 미래’에 대한 맹목적 기대 경계
7.2.2. 기초의 중요성: C/C++, 자료구조 등 보편적 컴퓨터 과학 지식의 가치
7.3. 성숙한 기술 문화를 향한 개인의 노력
7.3.1. 상호 존중과 건강한 비판이 공존하는 생태계 지향
7.3.2. 건설적인 비판을 수용하는 열린 자세의 중요성
제8장: 러스트의 미래: 나르시시즘 극복을 통한 진정한 성장
8.1. 생태계의 양적/질적 성장을 위한 과제
핵심 크레이트의 안정화와 표준화 노력 문서화 및 예제 코드의 확충 다양한 산업 분야로의 진출을 위한 유연성 확보
8.2. 개발 커뮤니티의 다양성 포용과 확장
젠더, 인종, 경력 등 다양한 배경의 개발자 환영 멘토링 프로그램 활성화 및 초보자 지원 강화 비난이 아닌 격려와 협력의 문화 조성
8.3. 궁극적으로 지향해야 할 러스트의 가치
- 진정한 의미의 “안전성”과 “성능” 추구 (나르시시즘이 아닌)
- 개발자의 행복과 생산성 증진에 기여하는 언어
- 지속 가능한 발전과 상호 협력적인 생태계 구축
결론: 러스트여, 나르시시즘을 버리고 겸손해져라
- 러스트의 잠재력은 여전히 크다.
- 그러나 나르시시즘적 태도는 스스로를 고립시키고 발전을 저해한다.
- 건강한 자기 성찰과 외부와의 소통을 통해 진정한 “우월함”을 증명해야 한다.
- 모두에게 더 나은 시스템 프로그래밍 언어가 되기 위한 러스트의 새로운 시작.