무슨 오류가 있어?

베어메탈, 리눅스 임베디드라고 정확히 구분하지 않는 건 있지만,

이미 내용은 정확하게 구분이 되어 있다.

ㅆㅇㅆ, 러스트 빠돌이 하두 헛소리하길래

베어메탈을 직접 언급하고, 각주까지 넣어서

방어적으로 글을 개선했지.

그 차이 외에는 내용이 동일하다.

왜 이렇게 허위주장하는지에 대해서는

내 책에 잘 나온다.

6.4. 바이너리 크기 문제와 '범용성'이라는 신기루

실행 파일의 크기가 크다는 것은 비단 러스트만의 문제는 아닙니다. Go와 같은 다른 현대 언어들 역시, 간편한 배포를 위해 모든 의존성을 포함한 단일 정적 바이너리를 생성하면서 비슷한 특성을 공유합니다. 서버 환경과 같이 저장 공간과 네트워크 대역폭이 충분한 영역에서, 이는 큰 단점으로 여겨지지 않습니다.

하지만 이 문제가 유독 러스트의 '범용성' 주장에 치명적인 이유는, 러스트가 스스로를 C/C++의 '대체재'라고 주장하기 때문입니다. 이 주장은 곧, C/C++이 수십 년간 지배해 온 임베디드 시스템, 운영체제 커널과 같이 자원이 극도로 제한된 환경에서도 자신들이 최적의 선택이라는 선언과 같습니다.

바로 이 지점에서 러스트의 '주장'과 기술적 '현실'은 정면으로 충돌합니다. C/C++은 전통적으로 동적 링킹을 통해 매우 작은 실행 파일을 만드는 데 최적화되어 있습니다. 반면, 러스트의 기본 빌드 방식(정적 링킹, 제네릭의 모노모피제이션)은 이와 대조적으로 훨씬 더 큰 실행 파일을 생성합니다.

결국 바이너리 크기 문제는 단순한 기술적 한계를 넘어, 러스트가 과연 모든 시스템 프로그래밍 영역을 아우르는 진정한 '범용' 언어가 될 수 있는지에 대한 근본적인 질문을 던집니다. 이어지는 내용에서는 이러한 문제가 발생하는 구체적인 기술적 원인과, 그것이 러스트의 '범용성'이라는 신기루에 어떻게 균열을 내는지를 상세히 분석하겠습니다.

libstd의 ABI 안정성 부재와 정적 링킹이라는 귀결

러스트로 만든 간단한 "Hello, world!" 프로그램이 C언어로 만든 것보다 수백 배 더 큰 바이너리 파일을 생성하는 현상은, 많은 개발자들에게 의문을 안겨줍니다. 그 가장 근본적인 원인은 러스트의 표준 라이브러리인 libstd가 안정적인 ABI(Application Binary Interface)를 제공하지 않는다는 언어의 핵심적인 설계 철학에 있습니다.

ABI란, 컴파일된 코드가 서로 상호작용하는 방식에 대한 저수준 규약입니다. C언어의 표준 라이브러리(libc 등)는 수십 년간 안정적인 ABI를 유지해왔습니다. 그 덕분에, 운영체제는 libc를 단 하나만 시스템에 설치해두고, 모든 C 프로그램이 이 공유된 라이브러리를 함께 사용하는 **'동적 링킹'**이 가능합니다. C 프로그램의 실행 파일이 매우 작은 크기를 가질 수 있는 이유가 바로 이것입니다. 실행 파일은 자신의 고유한 코드만 담고 있고, 표준 라이브러리 기능은 이미 시스템에 존재하는 공용 부품을 빌려 쓰는 것과 같습니다.

하지만 러스트는 다른 길을 선택했습니다. 러스트는 언어와 표준 라이브러리를 빠르게 발전시키고 개선하는 것을 최우선 가치로 삼습니다. 만약 libstd의 ABI를 안정적으로 고정해버리면, String이나 Vec의 내부 데이터 구조를 개선하거나, 함수 호출 방식을 최적화하는 등의 발전을 자유롭게 할 수 없게 됩니다. 과거 버전의 ABI에 영원히 묶이는 '기술적 부채'가 되기 때문입니다. 즉, 러스트는 **'안정적인 호환성'보다 '빠른 진화'**를 선택한 것입니다.

이 선택의 대가는 혹독합니다. libstd의 ABI가 안정적이지 않기 때문에, 러스트 1.78 버전으로 컴파일된 프로그램이, 시스템에 설치된 러스트 1.79 버전의 libstd와 호환된다는 보장이 없습니다. 따라서 동적 링킹은 매우 위험하고 불안정한 방식이 됩니다.

그 결과, 러스트 컴파일러는 기본적으로 **'정적 링킹'**을 강제합니다. 즉, 개발자가 만드는 모든 실행 파일 안에, 해당 프로그램이 사용하는 libstd의 모든 기능들을 복사해서 통째로 집어넣는 방식입니다. "Hello, world!"를 출력하기 위해 println! 매크로 하나만 사용했더라도, 그 매크로가 의존하는 수많은 표준 라이브러리의 코드들이 전부 내 실행 파일 안으로 들어오게 됩니다.

결론적으로, 러스트의 '빠른 진화'라는 철학은 'ABI 안정성 포기'를 낳았고, 이는 '정적 링킹 강제'로 이어져 '거대한 바이너리 크기'라는 현실적인 문제를 만들어냈습니다. 이는 메모리와 저장 공간이 극도로 중요한 임베디드 시스템이나 운영체제 커널과 같은 전통적인 C/C++의 영역에서 러스트가 왜 '범용적'이기 어려운지를 보여주는 첫 번째 기술적 증거입니다.

사례 1: grep과 rg의 바이너리 크기 비교

libstd의 정적 링킹이 실제로 어느 정도의 영향을 미치는지, 우리에게 익숙한 두 커맨드 라인 도구를 통해 구체적으로 살펴보겠습니다. 바로 C언어로 작성된 전통적인 텍스트 검색 도구인 **grep**과, 러스트로 작성되어 그 대안으로 떠오른 **ripgrep(rg)**입니다.

ripgrep은 러스트 커뮤니티가 내세우는 가장 자랑스러운 성공 사례 중 하나입니다. 병렬 처리를 통해 기존의 grep보다 월등히 빠른 검색 속도를 보여주며, 더 편리하고 다양한 기능을 제공합니다. 성능과 기능 면에서 ripgrep이 더 뛰어난 도구라는 점에는 이견이 없을 것입니다.

하지만, 두 도구의 실행 파일(binary) 크기를 비교해보면 우리는 러스트의 '현실적인 대가'와 마주하게 됩니다.

grep: 일반적인 리눅스 시스템에서 grep 실행 파일의 크기는 **수십 킬로바이트(KB)**에 불과합니다. (시스템에 따라 30KB ~ 150KB 내외)

ripgrep(rg): 반면, 정적으로 컴파일된 ripgrep 실행 파일의 크기는 **수 메가바이트(MB)**에 달합니다. (시스템에 따라 5MB ~ 12MB 내외)

두 도구의 파일 크기는 몇 퍼센트의 차이가 아니라, 적게는 수십 배에서 많게는 수백 배까지 차이가 나는 것입니다.

이러한 압도적인 크기 차이는 바로 앞서 설명한 링킹 방식의 차이에서 비롯됩니다. grep은 매우 작을 수 있는 이유가, 자신의 핵심 로직만 담고 있고, 나머지 표준 기능들은 운영체제에 이미 설치된 공용 libc 라이브러리를 빌려 쓰기(동적 링킹) 때문입니다. 반면 ripgrep은 다른 시스템에 쉽게 복사해서 바로 실행할 수 있는 '편리함'을 위해, 자신이 사용하는 러스트 표준 라이브러리와 다른 모든 의존성 크레이트들을 자신의 실행 파일 안에 전부 포함하고 있습니다(정적 링킹).

물론, 최종 사용자가 내려받아 사용하는 단일 애플리케이션의 관점에서 몇 메가바이트의 크기는 큰 문제가 아닐 수 있습니다. 오히려 의존성 문제 없이 단일 파일로 배포되는 것이 더 큰 장점일 수 있습니다.

하지만 이 책이 지적하는 'C/C++ 대체재'라는 관점에서는 심각한 문제가 됩니다. 만약 리눅스의 /bin, /usr/bin 디렉터리에 있는 수백 개의 기본 명령어(ls, cp, cat 등)가 모두 수십 킬로바이트의 C 프로그램이 아니라, 수 메가바이트의 러스트 프로그램으로 대체된다고 상상해 보십시오. 운영체제의 기본 용량은 지금보다 수십, 수백 배로 팽창할 것입니다. 이는 저장 공간이 제한적인 임베디드 시스템이나 도커 이미지와 같은 환경에서는 결코 받아들일 수 없는 트레이드오프입니다.

결론적으로, ripgrep은 러스트의 뛰어난 성능을 보여주는 훌륭한 쇼케이스입니다. 하지만 동시에, 러스트의 기본 빌드 방식이 만들어내는 '거대한 바이너리'라는 현실과, 그 현실이 '모든 것을 대체하겠다'는 범용성의 신기루에 어떻게 균열을 내는지를 보여주는 가장 명백한 사례이기도 합니다.