러스트가 C/C++을 '대체 불가'하게 만드는 주요 이유들

1. C ABI의 사실상 (반)영구적 지위

가장 핵심적인 이유 중 하나입니다. **C ABI(Application Binary Interface)**는 사실상 소프트웨어 산업의 국제 표준으로 자리 잡았습니다. 운영체제 커널(리눅스, 윈도우 등), 시스템 라이브러리, 하드웨어 드라이버, 그리고 거의 모든 프로그래밍 언어의 런타임이 C ABI를 기반으로 작동하고 있습니다.

• 상호 운용성(Interoperability): 다른 언어들이 C/C++로 작성된 라이브러리나 시스템 컴포넌트를 사용하기 위해서는 C ABI를 따라야 합니다. 러스트 역시 C 라이브러리와 상호 작용하기 위해 extern "C" 블록을 사용해야 합니다. 이는 러스트가 독자적인 ABI를 강제할 수 없으며, 기존 인프라에 의존할 수밖에 없음을 의미합니다.

• 레거시 코드 베이스: 수십 년간 축적된 C/C++로 작성된 방대한 레거시 코드를 단번에 바꿀 수는 없습니다. 이 코드들이 C ABI를 통해 연결되어 있기 때문에, C ABI가 사라지지 않는 한 C/C++의 존재 가치는 계속됩니다.

2. 러스트 libstd의 불안정성 (ABI)

러스트의 표준 라이브러리인 libstd는 언어의 안정적인 부분이지만, libstd 자체의 내부 ABI는 안정적이지 않습니다. 이는 러스트 컴파일러 버전이 바뀔 때마다 libstd의 내부 구조나 호출 방식이 변경될 수 있음을 의미합니다.

• 컴파일러 의존성: 러스트 프로젝트를 빌드할 때, 특정 러스트 컴파일러 버전과 그에 맞는 libstd 버전이 함께 사용되어야 합니다. 이는 다른 언어처럼 러스트로 컴파일된 바이너리가 어떤 러스트 런타임이든 상관없이 돌아가는 것을 어렵게 만듭니다.

• 정적 링크 강제: 따라서 러스트로 작성된 라이브러리를 외부(다른 러스트 코드나 C/C++ 코드)에서 사용하려면, 보통 libstd를 포함한 모든 의존성을 **정적으로 링크(static l i n k i n g)**해야 합니다. 동적 링크(dynamic l i n k i n g)가 어렵거나 불가능하다는 점은 시스템 레벨 라이브러리로서의 유연성을 떨어뜨립니다. C/C++은 동적 라이브러리(*.so, *.dll) 배포가 매우 일반적이죠.

• 커널 개발의 제약: 이러한 이유 때문에 libstd를 사용할 수 없는 환경(예: 운영체제 커널이나 베어 메탈 임베디드)에서는 no_std 환경에서 개발해야 합니다. 이는 러스트의 일부 편의 기능(예: 힙 할당, 스레딩)을 사용할 수 없게 만들어 개발 난이도를 높입니다.

3. 막대한 기존 C/C++ 생태계와 인력 풀

C/C++은 수십 년간 사용되어 온 언어이며, 그만큼 방대한 라이브러리, 프레임워크, 개발 도구, 그리고 숙련된 개발자 풀을 보유하고 있습니다.

• 산업 표준: 특정 산업 분야(예: 게임, 금융, 국방)에서는 C/C++이 사실상의 표준이며, 수많은 시스템과 솔루션이 이미 C/C++로 구축되어 있습니다.

• 인력 및 경험: C/C++ 개발자는 여전히 압도적으로 많으며, 이들의 경험과 지식은 쉽게 대체될 수 없습니다. 새로운 언어 도입에는 재교육과 인력 확보에 대한 부담이 따릅니다.

결론: '대체'가 아닌 '확장' 또는 '보완'

따라서 러스트는 C/C++이 지배하던 영역에서 '메모리 안전성과 동시성'이라는 강력한 강점을 내세워 새로운 프로젝트나 기존 시스템의 특정 모듈을 안전하고 효율적으로 개발하는 데 유용합니다. 그러나 위에 언급된 이유들로 인해 C/C++ 자체를 전면적으로 '대체'하는 것은 현실적으로 불가능에 가깝습니다.

러스트가 주목받는 것은 C/C++의 한계를 보완하고, 더 안전한 시스템 프로그래밍의 대안을 제시한다는 점 때문이지, C/C++의 역사를 완전히 지우고 그 자리를 차지하겠다는 의미는 아닙니다. 아마 '대체제'라는 표현보다는 'C/C++ 생태계의 안전한 확장' 또는 '고성능 시스템 프로그래밍의 강력한 대안' 정도로 이해하는 것이 더 적절할 것 같습니다.

이러한 점들을 고려할 때, 러스트가 가진 한계와 실제적인 적용 상황을 정확히 이해하는 것이 중요하다고 생각합니다.

네, 맞습니다. **"숨겨진 논리 또는 연산이 없어야 한다"**는 점은 Zig나 Odin 같은 C 계열 언어들이 추구하는 중요한 설계 원칙이자, 러스트와의 또 다른 차이점이 됩니다. 그리고 이 점이 시스템 프로그래밍이나 저수준 제어가 필요한 분야에서 C/C++ 개발자들이 선호하는 핵심적인 이유 중 하나입니다.

숨겨진 논리/연산이 없다는 것의 의미

이것은 코드를 읽었을 때, 작성된 그대로의 동작을 정확하게 예측할 수 있어야 한다는 철학을 의미합니다. 즉, 컴파일러나 런타임이 개발자가 명시적으로 작성하지 않은 추가적인 연산을 삽입하거나, 예상치 못한 방식으로 동작을 변경하지 않아야 한다는 것입니다.

• 명시성(Explicitness): 모든 것이 명시적이어야 합니다. 어떤 연산이든, 어떤 메모리 할당이든, 어떤 제어 흐름이든 코드에 그대로 드러나야 합니다.

• 예측 가능성(Predictability): 특정 코드가 실행될 때 어떤 어셈블리 코드로 변환될지, 얼마나 많은 CPU 사이클을 소모할지, 어떤 메모리 할당이 일어날지 등을 개발자가 비교적 정확하게 예측할 수 있어야 합니다. 이는 성능 튜닝이나 임베디드 시스템처럼 자원이 제한적인 환경에서 특히 중요합니다.

• 제어권(Control): 개발자가 시스템의 모든 측면에 대해 최대한의 제어권을 가져야 합니다. 숨겨진 동작은 이 제어권을 약화시킵니다.

러스트가 숨겨진 논리/연산으로 비칠 수 있는 이유

러스트는 안전성을 최우선 가치로 두기 때문에, 컴파일러가 개발자를 대신하여 많은 **안전 검사(Safety Checks)**와 오류 방지 로직을 삽입합니다. 이러한 로직들은 때로는 개발자에게 '숨겨진 연산'처럼 느껴질 수 있습니다.

• 소유권 및 빌림 규칙: 러스트의 소유권(Ownership) 시스템은 런타임 오류를 방지하기 위해 컴파일 타임에 많은 규칙을 강제합니다. 이는 개발자가 C/C++에서처럼 자유롭게 포인터를 다루는 것을 제한하고, 때로는 컴파일러가 '추가적인' 검사를 수행한다고 느끼게 합니다.

• 런타임 패닉(Panic): 러스트는 Result 타입이나 Option 타입으로 오류를 명시적으로 처리하는 것을 권장하지만, 예상치 못한 상황(예: 배열 인덱스 범위를 벗어나는 접근, unwrap() 실패)에서는 런타임에 **패닉(Panic)**을 일으킵니다. 패닉은 스택 언와인딩(Stack Unwinding)과 같은 추가적인 런타임 오버헤드를 유발할 수 있으며, C/C++의 크래시(Crash)와는 다른 방식으로 동작합니다. C/C++은 보통 '정의되지 않은 동작(Undefined Behavior)'으로 이어지죠.

• 제네릭(Generics)의 단형성(Monomorphization): 러스트는 제네릭 코드를 컴파일할 때, 실제로 사용되는 타입별로 별도의 함수를 생성합니다(단형성). 이는 런타임 오버헤드를 줄이지만, 최종 바이너리 크기를 증가시킬 수 있으며, 컴파일러가 '어떤 코드를 생성할지'에 대한 명시적인 제어가 부족하다고 느낄 수 있습니다. (C++ 템플릿도 유사합니다.)

• 최적화 방식: 러스트 컴파일러는 LLVM을 기반으로 강력한 최적화를 수행합니다. 이는 좋은 성능으로 이어지지만, 때로는 개발자가 작성한 코드와 실제 기계어 코드 간의 간극을 만들어 '숨겨진' 최적화 동작이 있다고 느끼게 할 수 있습니다.

Zig/Odin의 차별점

Zig나 Odin은 이러한 '숨겨진' 동작을 최소화하거나 아예 없애는 것을 목표로 합니다.

• 오류 처리의 명시성: Zig는 오류를 반환 값으로 명시적으로 처리하는 것을 강제하며, 런타임 패닉을 최대한 지양합니다. 개발자가 모든 잠재적인 오류 경로를 직접 처리하도록 요구합니다.

• 제어권 극대화: 메모리 할당, 오류 처리, 제네릭 등 모든 것이 개발자가 직접 명시적으로 제어하도록 설계되어 있습니다.

• Minimal Runtime: 런타임 라이브러리가 매우 작거나 거의 없어서, 컴파일된 바이너리가 어떤 추가적인 환경에 의존하지 않고 독립적으로 동작하도록 합니다. 이는 베어 메탈 프로그래밍이나 임베디드 시스템에 유리합니다.

결론적으로, "숨겨진 논리나 연산이 없어야 한다"는 것은 **'정확한 제어와 예측 가능성'**을 중시하는 저수준 프로그래밍에서 매우 중요한 가치입니다. 러스트는 '안전성'을 위해 컴파일러가 개입하는 정도가 크기 때문에 이 관점에서는 C/C++이나 Zig/Odin만큼 '숨겨지지 않은' 느낌을 주지 못할 수 있습니다.

이러한 철학적 차이가 각 언어가 어떤 분야에 더 적합한지를 결정하는 중요한 요소가 됩니다.

그럼에도 불구하고 러스트가 위대하다???

구라 고마쳐라

혹세무민 고마해라