Cargo를 위한 비전

Stack Overflow 2025 설문에서 가장 선호되는 개발 도구로 꼽힌 Cargo를 더 발전시키기 위해 의존성 관리, 빌드 성능, 적응성, 유지보수라는 네 축에서 이상적인 작업 흐름을 모색함 crates.io 생태계의 재사용과 공동 감사를 살리면서 품질 좋은 패키지 탐색, Edition식 마이그레이션, 공개 의존성 및 API 수명주기로 업그레이드 비용과 위험을 낮추려 함 작은 변경에도 전체 스택이 다시 빌드되고 병렬 Cargo 실행이 잠기며 CI가 테스트를 반복하는 문제를 출력 해싱, 공유 캐시, 세밀한 잠금, 테스트 결과 캐싱 등으로 개선하려 함 Cargo를 작은 입출력 단계의 plumbing 명령으로 분해하고 구조화 로그를 제공해 기업 환경, Docker 캐시, 복잡한 애플리케이션 및 외부 도구가 동작을 조합·교체할 수 있게 하는 구상임 사람에게 명확한 신호와 빠른 피드백을 제공하는 데 우선순위를 두되, 에이전트 개발이 확대하는 의존성·성능·신호 품질 문제를 활용해 10% 수준의 점진적 개선을 넘어서는 변화를 추진하려 함 개선이 필요한 네 가지 작업 흐름 의존성 관리와 생태계 crates.io 생태계에서는 기존 기능뿐 아니라 향후 수정과 최적화의 혜택도 재사용하는 애플리케이션으로 전파됨 typos는 ignore를 재사용하므로 ripgrep의 대규모 모노레포 최적화 혜택을 자동으로 얻음 널리 쓰이는 직렬화 프레임워크 한두 개를 공동 감사하는 편이 애플리케이션마다 만든 여러 구현을 각각 감사하는 것보다 유리함 생산성이 내부자 지식에 좌우되지 않도록 품질 좋은 의존성 탐색을 개선해야 함 다운로드 수, 역의존 패키지, 리뷰 이력, 제작자의 다른 패키지에서 형성된 신뢰 등을 찾고 종합하는 데 많은 작업이 필요함 unsafe처럼 추가 검사가 필요한 지점을 격리하는 감사 지점을 더 만들고 쉽게 발견할 수 있어야 함 가능하면 감사 대상 기능은 선택 사항으로 두고, 성능이나 기능을 포기하는 대신 감사가 필요 없는 대체 경로를 제공해야 함 다른 사람의 검토를 신뢰할 때는 자신과 타인의 리뷰 추적이 의존성 사용 흐름에 통합돼야 함 업그레이드 부담을 줄이려면 유지보수자의 린트와 테스트부터 개선해 버그와 의도하지 않은 변경을 줄여야 함 호환성 파괴를 무조건 억제하면 기술 부채 제거와 기능·수정·빌드 성능 개선이 제한됨 변경 문서화만으로는 부족하며, Rust Edition처럼 불안정 기능으로 변경을 준비하고 사용자 마이그레이션...