- 들어가며 — 릴리스 노트와 내 터미널이 겹친 날
- 1.97에서 실제로 바뀐 세 가지
- 정직하게 — 오퍼레이터엔 툴체인 버전보다 kube-rs가 중요했다
- 그래서 누가 지금 올려야 하나
- 마치며
- 참고 자료
들어가며 — 릴리스 노트와 내 터미널이 겹친 날
2026년 7월 9일, Rust 1.97.0이 stable로 나왔습니다. 우연히도 저는 그 며칠 전부터 홈랩 서버(Ubuntu, rustup 설치)에서 cargo 1.97로 쿠버네티스 GPU 오퍼레이터를 짜고 있었습니다. 그래서 이 글은 두 겹입니다 — (1) 릴리스 노트에서 정말 바뀐 것을 그대로 읽고, (2) 바로 그 툴체인으로 실제 작업을 한 사람의 시선에서 "그게 내 작업을 뭘 바꿨나"를 정직하게 따집니다. 결론부터 말하면, 흥분할 만한 릴리스는 아닙니다. 그리고 그게 나쁜 뜻은 아닙니다.
1.97에서 실제로 바뀐 세 가지
릴리스 노트의 헤드라인은 세 개입니다. 셋 다 언어 문법이 아니라 툴체인의 동작에 관한 것입니다.
1. v0 심볼 맹글링이 stable 기본값이 됐다. 그동안 rustc는 C++의 Itanium ABI 맹글링을 재활용했는데, 이 방식은 제네릭 인자를 해시 뒤에 숨겨 정보를 잃었습니다. 새 v0 스킴은 Rust 전용이라, 릴리스 노트 표현대로 "제네릭 파라미터 인스턴스화가 해시 뒤로만 추적되지 않고 그 값을 보존"합니다. 2025년 11월부터 nightly 기본값이었고, 1.97에서 stable로 올라왔습니다. 눈에 보이는 효과는 백트레이스·perf 같은 프로파일러·디버거의 심볼이 읽기 쉬워진다는 것 — 평소엔 안 보이다가 문제를 팔 때 고마운 종류의 변화입니다.
2. Cargo가 경고를 "거부(deny)"할 수 있다. 새 build.warnings 설정(환경변수 CARGO_BUILD_WARNINGS)이 세 단계를 줍니다 — allow(무시), warn(빌드는 통과, 기본값), deny(경고 시 빌드 실패).
# .cargo/config.toml
[build]
warnings = "deny"
핵심 이점은 릴리스 노트의 표현대로 "이 기능을 써도 빌드 캐시가 무효화되지 않는다"는 점입니다. 지금까지 CI에서 흔히 쓰던 RUSTFLAGS="-D warnings"는 플래그가 바뀌면 전체 재빌드를 유발했는데, 이건 그렇지 않으니 임시로 켜고 끄기가 쉽습니다. CI에서 --keep-going과 조합하면 멈추기 전에 모든 에러를 모아 볼 수도 있습니다.
3. 링커 출력이 더는 숨지 않는다. 그동안 rustc는 링크가 성공하면 링커 출력을 조용히 삼켰습니다. 1.97부터는 링커 메시지를 경고 수준 lint로 기본 노출하고, Cargo.toml의 [lints.rust]로 조절합니다. nightly에서 이걸 켜자 실제로 숨어 있던 결함 몇 개가 드러나 고쳐졌다고 합니다.
그리고 자잘한 안정화 API들입니다.
Default for RepeatN
Copy for ffi::FromBytesUntilNulError
Send for std::fs::File (UEFI)
<{integer}>::isolate_highest_one / isolate_lowest_one / highest_one / lowest_one
<{uN}>::bit_width
NonZero<{integer}>:: 위 메서드들의 대응판
const 승격: char::is_control
비트를 직접 만지는 코드라면 반가운 정수 메서드들이지만, 대부분의 앱 코드엔 오늘 당장 영향이 없습니다.
정직하게 — 오퍼레이터엔 툴체인 버전보다 kube-rs가 중요했다
여기가 이 글의 진짜 요점입니다. 저는 cargo 1.97로 실제 오퍼레이터를 빌드해 돌렸습니다. 실측 환경입니다.
빌드 cargo 1.97, 릴리스 최초 16.7초(의존성 포함), 증분 2.6초
크레이트 kube 0.96 (client+runtime+derive+rustls-tls), k8s-openapi 0.23 (v1_31)
실행 out-of-cluster, ~/.kube/config로 실제 API 서버에 접속
대상 Kubernetes v1.32.5
그런데 솔직히 말하면, 위 세 가지 1.97 헤드라인 중 어느 것도 이 오퍼레이터를 짜는 방식을 바꾸지 않았습니다. 오퍼레이터를 가능하게 한 건 언어나 툴체인의 이번 버전이 아니라 kube-rs 0.96이라는 생태계였습니다 — #[derive(CustomResource)]로 구조체를 CRD로 바꾸고, controller 런타임이 리컨사일 루프를 돌리고, rustls-tls로 openssl 의존성 없이 어디서나 빌드되게 하는 것. 이 레버리지는 전부 크레이트 쪽에 있습니다.
16.7초/2.6초라는 빌드 속도도 1.97의 공이라기보다 그냥 cargo가 cargo인 덕입니다. 즉 Rust의 언어·툴체인은 이미 지루할 만큼 안정적이고(좋은 뜻입니다), 실제 생산성의 차이는 생태계에서 납니다. 그 오퍼레이터가 실제로 무엇을 발견했는지 — 제 GPU 노드 4개가 전부 죽어 있었다는 진단 — 는 Rust로 쿠버네티스 GPU 오퍼레이터 만들기에 실측 로그와 함께 따로 정리했습니다.
그래서 누가 지금 올려야 하나
담담하게 정리하면 이렇습니다.
- 대부분의 사람: 그냥
rustup update stable하고 잊으면 됩니다. 코드를 바꿀 이유가 없습니다. - 디버깅·프로파일링을 자주 하는 사람: v0 맹글링 덕에 백트레이스와
perf심볼이 나아집니다. 조용하지만 실질적인 이득입니다. - CI를 관리하는 사람:
build.warnings = "deny"는 캐시를 깨지 않고 경고를 실패로 바꿔 주니,RUSTFLAGS="-D warnings"를 대체할 만합니다. - 크로스 컴파일·커스텀 링커와 씨름하는 사람: 이제 링커가 하던 말이 보입니다. 문제를 파던 사람에겐 반가운 변화입니다.
$ rustup update stable
서두를 이유는 없습니다. 6주 주기의 조용한 릴리스답게, 올리면 대체로 좋아지고 안 올려도 당장 깨지지 않습니다.
마치며
정직한 감상은 이렇습니다. Rust 1.97은 문법을 흔드는 릴리스가 아니라, 심볼·경고·링커 같은 툴체인의 위생을 손보는 릴리스입니다. 화려하지 않지만, 이런 게 쌓여서 "돌아가면 대체로 옳다"는 언어의 신뢰가 만들어집니다. 그리고 바로 그 며칠간의 실측이 저에게 가르쳐 준 건 조금 다른 각도였습니다 — 실제 일을 굴리는 힘은 툴체인 버전 숫자가 아니라, 그 위에서 성숙한 생태계(kube-rs)에 있다는 것. 그러니 1.97은 조용히 올리고, 에너지는 크레이트를 고르는 데 쓰는 편이 낫습니다.
참고 자료
현재 단락 (1/35)
2026년 7월 9일, [Rust 1.97.0](https://blog.rust-lang.org/2026/07/09/Rust-1.97.0/)이 stable로 나왔습니다. 우연히도 ...