Cargo 1.100의 의존성 대기 기간, 잠금 파일과 설치 명령에서 갈린다
Cargo 1.100은 새 버전을 선택하기 전에 공개 경과 시간을 확인할 수 있다. 기존 잠금 파일과 CLI 설치에 적용되지 않는 경계, 긴급 패치의 예외 비용을 살펴 팀의 의존성 갱신 정책에 넣을 조건을 정리한다.
오늘 공개된 라이브러리 버전이 자동 업데이트에 곧바로 들어오는 일을 늦추고 싶다고 하자. Cargo 1.100에서는 패키지가 공개된 뒤 일정 시간이 지나야 새 의존성 후보로 선택하도록 설정할 수 있다. 하지만 이 설정을 켜도 이미 잠금 파일에 들어온 버전은 그대로 남는다. 기다리는 시간을 정하기 전에, 어느 경로에서 새 버전을 받아들이는지부터 알아야 한다.
Rust 팀은 2026년 11월 12일 발표에서 이 기능의 안정화를 알렸다. GeekNews 등록은 13일 오전 4시 49분, 한국 시각이다. 여기서는 언어 기능 전체보다 Cargo의 의존성 선택 정책을 살펴본다. 공식 문서를 읽은 분석이며 Cargo 1.100을 설치하거나 아래 설정으로 빌드를 실행하지 않았다.
기다리는 대상은 다운로드가 아니라 버전 선택이다
Cargo는 Rust의 패키지·빌드 도구다. 프로젝트의 요구에 맞는 패키지 버전을 고르는 과정을 의존성 해석이라고 한다. 새 min-publish-age 설정은 이 과정에서 공개된 지 얼마 안 된 버전을 후보에서 제외한다. 파일을 내려받은 뒤 며칠 보관했다가 실행하는 기능은 아니다. 선택 규칙
아래는 Cargo 1.100 이상에서 프로젝트의 .cargo/config.toml에 둘 수 있는 작은 예다. 기존 파일이 있다면 같은 테이블을 중복 선언하지 않고 합쳐야 한다.
[registry]
global-min-publish-age = "3 days"
기본값은 "0"이므로 버전만 올렸다고 대기 기간이 생기지는 않는다. 레지스트리별 registries.<name>.min-publish-age가 있으면 그 값이 우선한다. 레지스트리는 패키지와 버전 정보를 제공하는 저장소다. 설정 문서
Rust 팀이 제시한 배경은 악성 패키지가 공개 직후 수시간이나 수일 안에 발견되는 경우가 있다는 것이다. 그 발견 시간을 기다리자는 접근이다. 공식 발표 다만 3일은 설정 예시이지 안전성이 입증되는 기간이 아니다. 사흘 뒤에도 아무도 문제를 발견하지 못할 수 있다. 내가 기대하는 효과는 빠르게 드러난 문제를 피할 여유이며, 코드 검토를 대신하는 인증은 아니다.
잠금 파일에 들어간 버전에는 소급하지 않는다
Cargo.toml이 허용할 버전 범위를 적는 곳이라면, Cargo.lock은 실제로 선택한 버전을 기록한다. 해석기는 가능한 한 기존 기록을 유지한다. 대기 기간에 못 미치는 버전도 이미 잠금 파일에 있으면 계속 사용한다. 잠금 파일과 업데이트 동작
가령 어제 공개된 버전이 이미 Cargo.lock에 들어 있고 오늘 3일 대기를 설정했다고 하자. 다음 빌드에서 그 버전이 자동으로 빠지거나 이전 버전으로 내려가지는 않는다. 이는 문서의 규칙을 적용한 가정이다. 새 정책의 도입과 기존 의존성의 점검을 따로 해야 하는 이유다.
나는 여기서 잠금 파일의 역할을 다시 보게 된다. 같은 버전을 반복해서 빌드하는 재현성과, 그 버전을 처음 받아들일 때의 판단은 다른 책임이다. CI가 --locked로 잠금 파일의 변경을 막아도, 다른 경로에서 이미 반영된 업데이트의 적절성까지 확인해 주지는 않는다. 해석과 잠금 동작
따라서 평소 빌드와 잠금 파일 갱신 작업을 나눠 보겠다. 개발자와 업데이트 작업이 같은 Cargo 버전·정책을 사용하는지 확인하고, 변경 요청에서는 직접 의존성뿐 아니라 함께 달라진 간접 의존성도 읽어야 한다. 설정 파일 하나를 추가한 사실보다 새 버전이 기록으로 들어오는 경로가 더 중요하다.
설치 명령과 레지스트리에 별도 경계가 있다
공식 발표는 적용되지 않는 경로를 명시한다. 특히 cargo install은 설치할 도구와 그 의존성 모두에서 최소 공개 경과 시간을 무시한다. 프로젝트에 대기를 설정해도 CI 준비 단계에서 최신 CLI를 설치하는 경로까지 같은 정책으로 보호되지는 않는다.
| 사용하는 경로 | 대기 기간을 읽는 기준 |
|---|---|
| 의존성을 새로 선택·갱신한다 | 설정한 기간보다 최근 버전은 후보에서 제외한다 |
Cargo.lock의 기존 버전을 쓴다 | 최근 버전이어도 계속 사용할 수 있다 |
cargo install로 도구를 설치한다 | 도구와 의존성에 대기 기간을 적용하지 않는다 |
버전 정보에 pubtime이 없다 | 공개 시각이 없어 대기로 보류하지 않는다 |
pubtime은 레지스트리 인덱스에 기록된 버전 공개 시각이다. 사내 레지스트리나 미러를 쓴다면 이 정보의 제공 여부를 확인해야 한다. 값을 모른다는 이유로 보수적으로 차단하는 규칙은 아니다. 적용 한계
설치에는 별도의 변화도 있다. Cargo 1.100의 cargo install은 배포 패키지에 포함된 Cargo.lock이 있으면 기본으로 사용한다. 없으면 일반적인 의존성 해석을 하며, --locked를 붙여도 잠금 파일이 새로 생기는 것은 아니다. 이 경우에는 경고한다. 현재 설치 문서, 1.100 변경 기록
그러므로 설치할 CLI의 버전을 고정하는 일과 간접 의존성까지 고정하는 일을 구분하겠다. 기존에 검증한 바이너리를 CI 이미지에 포함하는 방법도 비교할 수 있다. 어느 쪽이든 도구를 어떻게 갱신하고 검증할지 남겨야 한다. 잠금 파일을 쓴다는 사실도 패키지 내용이 안전하다는 판정은 아니다.
긴급 패치를 기다리지 않을 절차도 필요하다
보안 수정이 오늘 배포됐다면 일률적인 대기는 이미 알려진 결함을 더 오래 남길 수 있다. 공식 발표는 한 번의 업데이트에서 CARGO_RESOLVER_INCOMPATIBLE_PUBLISH_AGE=allow를 지정하고 cargo update의 --precise로 버전을 고르는 예외를 안내한다. 선택한 버전은 잠금 파일에 기록돼 이후에도 유지된다. 예외 적용 방식
이때 해제는 지정한 패키지 하나만을 위한 승인 규칙이 아니다. 해석기 문서는 그 업데이트에 필요한 간접 의존성도 선택할 수 있다고 설명한다. 나는 예외를 적용한 변경에서 잠금 파일 전체의 차이를 확인하고, 어떤 공지와 수정 내용을 근거로 기다리지 않았는지 기록하겠다. 예외 환경 변수를 CI의 상시 설정으로 남기면 대기 정책 자체가 사라진다.
첫 적용에서는 다음 네 가지를 확인할 수 있다.
- 개발 머신과 업데이트 작업, CI가 Cargo 1.100 이상의 같은 정책을 사용하는지 확인한다.
- 기존 잠금 파일, 새 버전 선택, CLI 설치를 나눠 어떤 경로에 대기가 적용되는지 살핀다.
- 보류된 업데이트와 해석 실패를 관찰하고, 팀의 수정 대응 시간에 맞춰 대기 기간을 정한다.
- 긴급 예외에서 함께 바뀐 버전과 검증 결과를 남기고, 다음 실행에서 원래 정책으로 돌아오는지 확인한다.
정기적으로 의존성을 갱신하고 짧은 지연을 받아들일 수 있는 팀이라면 검토할 가치가 있다. 반면 막 공개된 버전의 기능이나 수정이 당장 필요하다면 예외 검토 비용도 함께 생긴다. 내 도입 기준은 며칠을 기다렸는가보다 구체적이다. 새 버전을 받아들이는 경로와 건너뛰는 경로를 설명할 수 있고, 기다림과 긴급 대응을 같은 절차 안에서 관리할 수 있는가다.
참고 자료
이 이야기가 도움이 되었나요?