님들 이런 생각 못해봤지?

사방팔방에서 다들 러스트 찬양하니까.

이번에 추가할 내용이다.

아직 초안이고 더욱 구체적으로 다음을 것이다.

제5장: 러스트의 설계, 혁신인가 결함인가?

지금까지 우리는 러스트의 ‘안전성’, ‘개발 경험’, ‘소유권’을 둘러싼 여러 신화와 그 이면의 문제들을 살펴보았습니다. 하지만 학습 곡선, 생태계, 컴파일 시간과 같은 비판들은 어쩌면 현상에 대한 지적에 머무를 뿐일지 모릅니다. 저는 이 책을 집필하며 그 모든 문제의 근원을 파고들었고, 마침내 하나의 본질적인 질문과 마주했습니다. ‘러스트의 설계 철학 그 자체는 과연 올바른가?’

이 장은 그 기나긴 비판적 연구의 종착역입니다. 그리고 제가 도달한 최종적인 결론, 즉 러스트의 방식은 위대한 혁신이 아니라 소프트웨어 공학의 보편적 원칙을 비껴간 근본적인 ‘설계 결함’으로 귀결되었습니다.

이를 위해 Ada/SPARK와의 비교를 통해, 러스트의 방식이 과연 혁신인지 아니면 결함인지 그 문제의 본질을 심층적으로 분석해 보겠습니다.

5.1. 발단: 비대한 바이너리라는 ‘치명적 결함’

논의는 “러스트로 만든 프로그램은 바이너리 크기가 비대해져 C/C++를 대체할 수 없으며, 이는 치명적인 설계 결함이다”라는 날카로운 비판에서 시작되었습니다. 그 원인으로 모든 라이브러리를 포함하는 정적 링킹과 제네릭 코드마다 복사본을 만드는 모노모피제이션(Monomorphization)이 지목되었습니다.

이에 대해 러스트의 설계는 성능과 배포 편의성을 위한 ‘의도된 트레이드오프’이며, 커널이나 임베디드 환경에서는 표준 라이브러리를 제외하는 no_std 방식을 사용한다는 표준적인 반론이 제시되었습니다. 하지만 이 반론은 더 깊은 철학적 질문의 서막에 불과했습니다.

5.2. 역사적 대안: 개발자의 보편적 사고방식과 TDD

논의의 핵심적인 전환점은 에이다(Ada)의 등장과 함께였습니다. Ada는 제네릭을 구현할 때 코드 공유를 통해 바이너리 크기 증가를 억제하며, 이는 러스트와 다른 접근법이 존재함을 보여줍니다.

여기서부터 논의는 단순한 기술 비교를 넘어, 소프트웨어의 ‘올바름’을 추구하는 두 가지 다른 철학의 대립으로 발전합니다.

모든 프로그래밍의 근간에는 ‘함수에 입력 x를 넣으면, 결과 y가 나올 것이다’(f(x)→y)라는 지극히 단순하고 상식적인 기대가 있습니다. 이것은 개발자가 함수를 설계하고, 의도하고, 증명하려는 모든 사고의 출발점입니다.

현대 소프트웨어 공학에서 이 기대를 체계화한 방법론이 바로 테스트 주도 개발(Test-Driven Development, TDD)입니다. 개발자는 실제 코드를 작성하기에 앞서, $f(x)$가 y를 반환할 것을 기대하는 테스트 코드를 먼저 작성합니다. 이는 ‘기대하는 결과(가설)’를 먼저 정의하고, 그 기대를 만족시키는 코드를 나중에 구현하는 과학적 사고방식과 정확히 일치합니다.

바로 이 사고방식을 언어 차원으로 끌어올린 것이 Ada/SPARK가 사용하는 ‘계약 기반 설계(Design by Contract)’ 패러다임입니다. ‘입력값은 이러해야 한다(사전 조건)’는 $f(x)$의 x에 대한 가설이며, ‘결괏값은 이러할 것이다(사후 조건)’는 y에 대한 검증입니다. 따라서 이 방식이 TDD에 익숙하거나 체계적인 설계를 중시하는 개발자에게 오히려 더 직관적이고 편안하게 느껴질 수 있는 것입니다.

5.3. 핵심 쟁점: 개발자의 ‘의도’ vs. 컴파일러의 ‘규칙’

결국 논쟁은 “무엇이 중심이 되어야 하는가?”라는 질문으로 귀결되었습니다.

접근법 A (Ada/SPARK 등): 개발자의 ‘의도’를 검증하는 도구 이 방식은 개발자의 사고방식을 중심에 둡니다. 개발자는 먼저 “함수에 X를 입력하면 Y가 나온다”는 자신의 의도(계약)를 명확히 합니다. 그 후 자유롭게 코드를 구현하면, 도구는 작성된 코드가 처음에 정의한 의도와 일치하는지 검증하는 보조적인 역할을 수행합니다.

이러한 ‘계약 기반 설계’는 Ada/SPARK만의 독점적인 방식이 아닙니다. C/C++를 위한 Frama-C나 VCC 같은 다른 여러 정적 분석 및 형식 검증 도구들 역시 동일한 철학을 공유합니다. 이는 개발자의 생각을 보조하고 검증하는, 매우 정석적인 접근법입니다.

접근법 B (러스트): 도구의 ‘규칙’에 의도를 맞추는 언어 컴파일러가 먼저 “메모리는 이러이러한 규칙으로만 다뤄야 한다”는 양보 없는 규칙을 제시합니다. 개발자는 자신의 의도를 이 규칙의 틀 안에서 표현하기 위해 노력해야 합니다. 도구의 규칙이 주도권을 가집니다.

5.4. 최종 결론: 혁신인가, 철학적 결함인가?

이 근본적인 철학의 차이에서 두 가지 상반된 평가가 나옵니다.

러스트 비판론 (사용자의 최종 관점)

개발자의 정상적이고 과학적인 사고방식을 따르지 않고, 오히려 그 사고방식을 언어의 독특한 규칙에 억지로 끼워 맞추게 하는 것은 ‘설계 결함’입니다. 이는 문제를 정면으로 해결하기보다 교묘하게 우회하려는 시도이자, 소프트웨어 공학의 보편적 원칙에서 벗어난 ‘비정석적’인 방식입니다. 숙련된 개발자에게는 불필요한 제약이며, 초심자에게는 과도한 장벽으로 작용할 뿐입니다.

러스트 옹호론 (일반론)

현실의 개발 환경에서는 모든 개발자가 이상적인 설계를 따르지 않습니다. 러스트의 강제적인 규칙은 개발자의 역량이나 훈련 수준에 관계없이 모든 코드에 ‘최소한의 안전선’을 제공하여, 메모리 오류와 같은 최악의 버그를 시스템적으로 막아주는 실용적인 ‘혁신’입니다.

결론적으로, 어떤 시각을 가질지는 개발자의 경험과 철학에 달려있습니다. 명시적인 논리와 증명을 중시하는 이에게 러스트의 방식은 부자연스러운 제약일 것이며, 현실적인 안전장치를 중시하는 이에게는 실용적인 해결책일 것입니다.

이처럼 러스트의 핵심 설계 철학은, 소프트웨어 공학의 전통적인 원칙에 비추어볼 때 충분히 논쟁의 대상이 될 수 있으며, ‘설계 결함’이라는 날카로운 비판에 직면할 수 있는 정당한 이유를 가지고 있습니다.

그렇다면, 이러한 합리적이고 철학적인 비판에 대해, 러스트 커뮤니티의 일부는 왜 기술적 토론이 아닌, 개인에 대한 비난과 비이성적인 방어기제로 반응하는 것일까요?

이어지는 제3부에서는 바로 그 현상의 심리적 원인을 파헤쳐 보겠습니다.