"러스트로 만든 프로그램의 바이너리 크기가 크다는 지적에 대해 다양한 시각이 존재합니다. 이 현상은 러스트의 설계 특성에서 비롯되며, 이에 대한 객관적인 논의가 중요합니다."

러스트는 뛰어난 성능과 메모리 안전성으로 주목받는 언어입니다. 하지만 모든 기술은 선택과 타협의 결과이며, 러스트 역시 예외는 아닙니다. 특히 '바이너리 크기' 문제는 러스트의 특정 설계 방식에서 비롯되는 특성이며, 이는 일부 환경에서 중요한 고려사항이 됩니다. 이 글에서는 러스트의 바이너리 크기 특성과 그 배경, 그리고 관련 논의의 중요성을 살펴봅니다.

러스트 프로그램의 '바이너리 크기': 설계 선택의 결과

러스트로 개발된 프로그램의 실행 파일 크기가 상대적으로 커지는 것은 언어의 핵심 설계 방식에서 기인합니다. 이는 특정 장점을 얻기 위한 언어 개발팀의 의도적인 선택이며, 다음과 같은 주요 요인들이 복합적으로 작용합니다.

1. 정적 링킹의 기본:

   • 러스트는 표준 라이브러리(libstd) 및 대부분의 외부 의존성 크레이트들을 빌드된 바이너리 파일 안에 정적으로 링킹하는 것을 기본으로 합니다. 이는 프로그램을 단일 파일로 쉽게 배포하고, 런타임에 외부 라이브러리 의존성 문제를 피하며, 높은 런타임 성능을 확보하는 데 유리합니다.

   • 하지만 이 방식은 필요한 모든 라이브러리 코드가 각 실행 파일 안에 복사되어 포함되므로, 바이너리 크기가 커지는 결과를 가져옵니다. 예를 들어, C 언어로 작성된 ls, cp와 같은 기본 유틸리티는 수십 킬로바이트(KB)에 불과한 경우가 많습니다. 이는 시스템의 공통 라이브러리(libc)를 동적으로 공유하기 때문입니다.

   • 반면, 러스트로 구현된 코어 유틸리티 프로젝트인 uutils의 개별 명령어 바이너리는 수 메가바이트(MB)에 달하기도 합니다. 이는 C 기반 유틸리티에 비해 수십 배에서 많게는 수백 배의 크기 차이를 보일 수 있습니다.

2. 모노모피제이션(Monomorphization):

   • 러스트의 제네릭(Generic) 코드는 런타임 오버헤드를 줄이기 위해 컴파일 시점에 사용된 각 구체적인 타입별로 코드를 생성합니다. 이 '코드 팽창' 현상 역시 최종 바이너리 크기 증가에 영향을 미칩니다.

[Alpine Linux 공식 패키지 크기 비교 (x86 아키텍처 기준 예시)]

가볍고 효율적인 시스템에 중점을 둔 Alpine Linux의 공식 패키지를 비교하면 이러한 크기 차이가 더욱 명확해집니다.

• busybox (C 기반, 통합 유틸리티): 설치 시 약 0.8MB ~ 1.0MB

  • 수백 개의 기본 명령어를 단일 바이너리에 통합하고도 매우 작은 크기를 유지합니다.

• coreutils (C 기반, GNU Coreutils 전체 패키지): 설치 시 약 1.1MB

  • GNU Coreutils 전체 패키지의 크기이며, 개별 명령어는 훨씬 작습니다.

• uutils (Rust 기반, 통합 바이너리): 설치 시 약 5.9MB

  • 비슷하게 여러 유틸리티를 통합했지만, busybox나 coreutils에 비해 상대적으로 훨씬 큰 크기를 보입니다.

uutils 프로젝트가 단일 통합 바이너리를 지향하는 것은, 러스트의 특성상 개별 바이너리로 빌드할 때 발생하는 코드 중복으로 인한 크기 증가 문제를 완화하고 전체적인 디스크 공간 효율성을 높이기 위한 전략적 선택입니다.

'바이너리 크기'에 대한 다양한 시각과 고려사항

러스트 프로그램의 바이너리 크기는 모든 프로젝트에서 동일하게 중요한 요소는 아닙니다.

• 덜 중요한 환경: 클라우드 서버 환경이나 데스크톱 애플리케이션처럼 디스크 공간과 네트워크 대역폭이 충분한 경우에는 몇 메가바이트의 크기 차이가 큰 단점으로 인식되지 않을 수 있습니다.

• 중요한 환경: 하지만 임베디드 시스템, IoT 장치, 리소스가 제한된 컨테이너(예: 도커 이미지), 혹은 부팅 시간이 중요한 시스템에서는 바이너리 크기가 여전히 중요한 제약 조건으로 작용합니다.

이러한 특성 때문에 일부 러스트 옹호자들은 바이너리 크기 문제를 크게 고려하지 않기도 하며, 때로는 최적화 옵션(min-sized-rust 가이드라인)을 적용하여 크기를 줄일 수 있다고 제안하기도 합니다. 하지만 이러한 최적화는 특정 언어 기능을 포기하거나 복잡한 빌드 과정을 거쳐야 하는 등의 추가적인 노력을 요구할 수 있습니다.

개발 경험과 실용성에 대한 영향

바이너리 크기 문제는 단순히 용량 문제를 넘어, 개발 과정과 전반적인 실용성에도 영향을 미칠 수 있습니다.

• 느린 컴파일 시간: '제로 코스트 추상화'를 위한 복잡한 컴파일 과정과 방대한 코드 처리는 러스트의 컴파일 시간을 길게 만듭니다. 특히 대규모 프로젝트에서는 컴파일러(rustc)의 높은 메모리 사용량으로 인해 시스템의 메모리가 부족해져 OOM(Out of Memory) Killer에 의해 강제 종료되는 경우도 발생하며, 이는 개발자의 생산성을 저해할 수 있는 요인입니다.

• 배포 및 관리의 복잡성: 큰 바이너리는 배포 시간 증가, 스토리지 비용 상승 등으로 이어질 수 있습니다.

러스트 생태계의 성숙을 위한 열린 논의

러스트는 강력한 기술적 장점을 가진 언어이지만, 모든 언어에는 고유한 특성과 그로 인한 한계가 존재합니다. '바이너리 크기'와 같은 특성은 러스트의 설계 선택에서 비롯되는 필연적인 결과이며, 이를 인정하고 객관적으로 논의하는 것이 중요합니다.

러스트 커뮤니티가 언어의 강점뿐만 아니라 이러한 현실적인 특성들을 투명하게 공유하고, 다양한 환경에서의 실용적인 적용 방안을 모색하며, 건설적인 비판에 열린 자세를 가질 때 비로소 더 넓은 분야에서 신뢰받고 존경받는 언어로 성장할 수 있을 것입니다.