6.2 바이너리 크기 분석: 설계 원칙이 적용 분야에 미치는 영향

러스트 프로그램은 C/C++로 작성된 유사 기능의 프로그램에 비해 실행 파일(binary)의 크기가 큰 경향을 보입니다. 이는 러스트가 C/C++의 대안으로 논의되는 자원 제약적인 시스템 프로그래밍 영역에서 고려사항이 됩니다. 본 절에서는 이러한 현상의 기술적 원인을 분석하고, 구체적인 사례 비교를 통해 그 파급 효과를 검토합니다.

1. 기술적 원인: ABI 불안정성과 정적 링킹

러스트 바이너리 크기 증가의 원인 중 하나는 표준 라이브러리(libstd)의 ABI(Application Binary Interface)가 안정적으로 유지되지 않는다는 설계상의 특징에 있습니다. C언어는 수십 년간 안정적인 libc ABI를 기반으로, 시스템에 설치된 공유 라이브러리를 여러 프로그램이 함께 사용하는 동적 링킹을 지원합니다. 이로 인해 C 프로그램의 실행 파일은 자신의 고유 코드만 포함하여 작은 크기를 유지할 수 있습니다.

반면 러스트는 언어와 라이브러리의 개선과 발전을 위해 libstd의 내부 구현을 변경할 수 있도록 ABI를 안정화하지 않았습니다. 이는 '안정적 호환성'보다 '빠른 진화'를 우선하는 설계상의 선택입니다. 이 선택의 결과로, 버전 간 호환성을 보장하기 어려운 동적 링킹 대신 프로그램이 필요한 라이브러리 코드를 실행 파일 내에 포함하는 정적 링킹이 기본 방식으로 채택되었습니다. 따라서 프로그램이라도 libstd의 관련 기능들이 바이너리에 포함되어 크기가 증가하게 됩니다.

2. 사례 연구: CLI 도구 및 코어 유틸리티 비교

이러한 설계의 영향은 실제 프로그램의 크기 비교를 통해 확인할 수 있습니다.

사례 1: grep과 ripgrep ripgrep은 러스트로 작성된 텍스트 검색 도구로, C언어 기반의 grep과 비교되곤 합니다. 그러나 일반적인 리눅스 시스템에서 동적 링킹된 grep의 크기는 수십 킬로바이트(KB)인 반면, 정적 링킹된 ripgrep은 수 메가바이트(MB)에 달합니다. 이는 단일 애플리케이션 배포 시 의존성 관리를 용이하게 하지만, 운영체제의 기본 도구 전체를 대체하는 시나리오에서는 총용량 증가로 작용할 수 있습니다.

사례 2: BusyBox와 uutils 자원이 제한된 임베디드 리눅스 환경에서는 ls, cat 등 다수의 명령어를 단일 바이너리로 제공하는 BusyBox가 사용됩니다. C언어로 작성된 BusyBox는 전체 크기가 1MB 미만입니다. 반면, 유사한 목적으로 러스트로 개발된 uutils는 수 MB에 달하는 크기를 가집니다. 구체적인 크기는 각 프로젝트의 버전과 컴파일 환경에 따라 변동될 수 있으나, 이러한 경향성은 두 언어의 표준 라이브러리 설계와 기본 빌드 방식의 차이에서 비롯되는 구조적인 결과로 볼 수 있습니다. 아래 표는 알파인 리눅스(Alpine Linux) 패키지 기준의 비교입니다.

표 6.2: 코어 유틸리티 구현체의 패키지 크기 비교 (Alpine Linux v3.22 기준)¹

이 데이터는 러스트의 기본 빌드 방식이 BusyBox가 목표로 하는 임베디드 환경의 요구사항과는 차이가 있음을 보여줍니다.

3. 크기 축소 기법과 그 상충 관계

러스트 바이너리 크기를 줄이기 위한 여러 기법들이 존재하며, 이는 min-sized-rust 등의 가이드라인을 통해 공유됩니다. 기법은 다음과 같습니다.

• 패닉 핸들링 방식 변경 (panic = 'abort'): 패닉 발생 시 스택을 정리하는(unwinding) 대신 즉시 프로그램을 중단시켜 관련 코드와 메타데이터를 제거합니다. 이는 크기를 줄이지만, 자원 해제(resource cleanup) 과정을 생략하며 catch_unwind를 통한 패닉 복구를 불가능하게 합니다. 즉, 바이너리 크기 최적화와 시스템의 회복력(resilience) 확보 기능 사이의 공학적 상충 관계(trade-off)를 수반합니다.
• 표준 라이브러리 제외 (no_std): 힙 메모리 할당, 스레딩, 파일 입출력 등 운영체제 의존적인 기능을 제공하는 libstd를 사용하지 않습니다. 이는 크기를 줄일 수 있으나, Vec<T>, String 등 자료구조와 기능들을 직접 구현하거나 외부 크레이트에 의존해야 하는 제약이 따릅니다.

이처럼 러스트에서 C/C++ 수준의 바이너리를 구현하기 위해서는, 언어가 기본으로 제공하는 기능과 일부 안전장치를 비활성화해야 합니다. 이는 러스트의 기본 설계 철학이 바이너리 크기보다 기능 및 런타임 성능에 중점을 두고 있음을 시사합니다.

'무비용 추상화' 원칙과 그 구현 방식인 모노모피제이션이 초래하는 컴파일 시간 및 바이너리 크기 증가는, 러스트의 설계 철학을 보여주는 사례입니다.

이러한 비용은 '성숙도 문제'가 아니라, '런타임 성능'이라는 가치를 확보하기 위해 '개발 시간'과 '배포 크기'라는 다른 자원을 교환한 '본질적 상충 관계'입니다. 이는 비용은 사라지는 것이 아니라, 다른 곳으로 이전될 뿐이라는 공학의 원칙을 보여줍니다. 따라서 개발자는 '무비용'이라는 용어의 이면에 있는 이러한 비용 전가의 메커니즘을 이해하고, 자신의 프로젝트가 요구하는 제약 조건(예: 컴파일 속도, 바이너리 크기)과 러스트의 설계 철학이 부합하는지를 평가할 필요가 있습니다.