러스트가 가진 ‘크기’의 의미를 가장 깊이 이해하기 위해서는, 먼저 C언어 생태계의 경이로운 창조물인 BusyBox가 왜 존재하는지를 알아볼 필요가 있습니다.

BusyBox는 “임베디드 리눅스의 스위스 군용 칼”이라는 별명처럼, 극도로 자원이 제한된 환경(예: 공유기, 셋톱박스, 초소형 IoT 기기)을 위해 탄생했습니다. ls, cat 등 수백 개의 필수 명령어를 단 ~800KB의 단일 바이너리에 모두 담아, 최소한의 디스크 공간과 메모리로 완전한 유닉스 환경을 제공하는 것이 그 목적입니다. 이는 C언어와 경량 라이브러리 musl이 만들어낸, 효율성과 미니멀리즘의 정수입니다.

이제, BusyBox와 동일한 ‘올인원’ 단일 바이너리 아키텍처를 가진 러스트의 uutils를 그 옆에 놓아보겠습니다. 알파인 리눅스 기준으로, uutils의 크기는 약 6.3MB에 달합니다. BusyBox보다 8배 가까이 큽니다.

여기서 우리는 근본적인 질문을 던질 수밖에 없습니다. 과연 8배나 큰 uutils가, 1KB의 공간도 아껴야 하는 임베디드 환경에서 BusyBox의 목적을 대체할 수 있을까요? 답은 명백히 ‘아니오’에 가깝습니다.

이 비교는 전통적인 GNU coreutils(설치 크기 약 1.0MB)를 함께 놓았을 때 더욱 명확해집니다. 각 패키지의 정보는 알파인 리눅스 공식 패키지 페이지에서 직접 확인할 수 있습니다.

논평: 이 표는 C 생태계가 어떻게 문제에 따라 다른 해법을 제시하는 성숙함을 보여주는지 명확히 드러냅니다. 일반적인 환경에서는 표준 GNU coreutils를, 극한의 환경에서는 BusyBox를 사용하는 지혜가 있습니다.

하지만 러스트의 uutils는 그 어느 쪽의 목적도 완벽하게 만족시키지 못하는, 어중간한 위치에 서 있습니다. GNU coreutils보다 6배나 커서 일반적인 시스템에서조차 ‘비대’하며, BusyBox를 대체하기에는 터무니없이 거대합니다.

결국 uutils의 존재는, 러스트의 ‘안전성’과 ‘현대성’이라는 가치가, C 생태계가 수십 년간 쌓아 올린 ‘효율성’과 ‘유연성’이라는 현실의 벽 앞에서 얼마나 큰 ‘비용’을 치러야 하는지를 보여주는 가장 정직한 증거입니다.

물론, 임베디드 리눅스와 같이 더 큰 시스템에서는 C 역시 동적 링킹을 적극적으로 활용하여 유연성을 확보합니다. 이는 C 생태계가 시스템의 규모에 따라 ‘초경량 정적’ 방식과 ‘효율적인 동적’ 방식을 자유롭게 오가는 성숙함을 보여주는 지점입니다. 반면, 러스트의 기본 빌드 방식은 이 두 시나리오 모두에서 최적의 해법과는 거리가 있습니다. 러스트가 제공하는 가치들이, 결코 가볍지 않은 ‘비용’을 수반함을 보여주는 명백한 증거입니다.