러스트의 의존성들이 점점 걱정스럽다

• 러스트의 의존성 관리 시스템 이 개발을 편리하게 하지만, 의존성 개수와 품질 문제가 고민임
• 잘 사용하는 크레이트 조차 최신 상태가 아닐 수 있어 직접 구현하는 것이 나을 때도 있음
• Axum, Tokio 등 유명 크레이트를 추가한 뒤, 의존성 포함 전체 코드 라인 수 가 360만이나 되어 감당하기 어려움
• 실제 내가 작성한 코드는 1,000줄 정도에 불과하나, 주변 코드는 검토와 감사를 사실상 못함
• 러스트 표준 라이브러리 확장, 관리 어려움 등 명확한 ** 해결책**이 없는 상황임

러스트 의존성 문제 개요

• 러스트는 내가 가장 좋아하는 언어이며, ** 커뮤니티와 언어 사용성**이 매우 뛰어남
• 개발 생산성은 높지만, ** 의존성 관리** 측면에서 최근 걱정이 생김

러스트 크레이트와 Cargo의 장점

• Cargo로 ** 패키지 관리 및 빌드 작업 자동화**가 가능하여 생산성이 매우 향상됨
• 여러 운영체제 및 아키텍처 이동이 수월하고, ** 직접 파일을 관리하거나 빌드 도구 설정**을 신경쓰지 않아도 됨
• 별도의 패키지 관리 고민 없이 바로 ** 코드 작성**이 가능함

러스트 크레이트 관리의 단점

• 패키지 관리에 신경을 덜 쓰게 되어 ** 안정성**에 소홀해짐
• 예를 들어, ** dotenv 크레이트**를 사용했는데, 유지보수 중단됨을 Security Advisory를 통해 알게 됨
• ** 대체 크레이트**(dotenvy)를 고려하다가, 실제로 필요한 부분만 35줄 정도로 직접 구현함
• 여러 언어에서 패키지 미유지 이슈가 빈번하게 발생하므로, ** 의존성이 불가피한 상황**이 문제의 본질임

의존성이 불러오는 코드량 급증

• Tokio, Axum 등 ** 러스트 생태계의 중요하고 품질 좋은 패키지** 사용 중임
• 종속성으로 Axum, Reqwest, ripunzip, serde, serde_json, tokio, tower-http, tracing, tracing-subscriber를 추가함
• 웹서버와 파일 압축 해제, 로그 기능이 주 목적이어서 ** 프로젝트 자체는 단순**함
• Cargo vendor 기능을 활용해 모든 의존 크레이트를 ** 로컬로 다운로드**함
• tokei로 코드 라인을 분석해보니, 의존성 포함 ** 약 360만 줄**에 달함(벤더된 크레이트 제외시 약 11,136줄)
• 참고로 리눅스 커널 전체가 약 2,780만 줄로 알려져 있어, 내 작은 프로젝트가 그 일곱 분의 일에 해당하는 양임
• 내가 작성한 실제 코드는 약 1,000줄에 불과함
• 이렇게 많은 줄의 ** 의존코드를 감시하고 감시**(audit)하는 것은 사실상 불가능임

해결책에 대한 고민

• 현재로썬 뚜렷한 해결책이 없는 상태임
• 일부는 Go처럼 ** 표준 라이브러리를 확장**하자고 주장하지만, 이 또한 유지 관리 부담 등 새로운 문제를 야기함
• 러스트는 ** 고성능, 안전성, 모듈성**을 추구하며 임베디드나 C++과 경쟁할 목표라 표준 라이브러리 확대가 신중해야 함
• 예를 들어, Tokio 같은 고도화된 런타임도 ** Github와 Discord**에서 매우 활발히 관리됨
• 현실적으로 ** 비동기 런타임이나 웹서버 같은 핵심 인프라를 직접 구현**하는 것은 개인 개발자에겐 무리임
• 대형 서비스인 ** Cloudflare**도 tokio와 crates.io 의존성을 그대로 사용하며, 감사를 얼마나 자주 하는지는 불분명함
• ** Clickhouse**도 바이너리 크기, 크레이트 수량에 대한 문제를 언급함
• Cargo로 최종 바이너리에 포함되는 코드 라인을 ** 정확히 식별하기 어렵고** 플랫폼별 불필요한 코드도 포함되는 한계가 있음
• 결국, ** 커뮤니티 전체에 해답을 물을 수밖에 없는 현실임**