G - 러스트가 만들어지는 과정과 ‘Nightly 러스트’

이 부록은 러스트가 어떻게 만들어지는지와, 그것이 러스트 개발자인 여러분에게 어떤 영향을 주는지 이야기합니다.

부록 G - 러스트가 만들어지는 과정과 ‘Nightly 러스트’

정체되지 않는 안정성

언어로서 러스트는 코드의 안정성을 아주 중요하게 생각합니다. 러스트가 그 위에 무언가를 만들 수 있는 단단한 바탕이 되기를 바라는데, 무언가가 계속 바뀐다면 그럴 수 없을 것입니다. 동시에 새 기능을 실험할 수 없다면, 더는 무언가를 바꿀 수 없게 된 릴리스 뒤에야 중요한 결함을 발견할 수도 있습니다.

이 문제에 대한 러스트의 해결책은 정체되지 않는 안정성(stability without stagnation)이라고 부르는 것이며, 그 바탕의 원칙은 이렇습니다. 새 안정 버전의 러스트로 올리는 것을 결코 두려워하지 않아도 되어야 합니다. 업그레이드는 매번 아무 고통 없이 이루어져야 하며, 그러면서도 새 기능과 더 적은 버그, 더 빠른 컴파일 시간을 가져와야 합니다.

더 깊이: 안정성 약속에 남겨 둔 예외

새 안정 버전이 기존 코드를 깨뜨리지 않는다는 약속에도 정해진 예외가 있습니다. 언어의 버전 규칙을 정한 RFC 1122는 마이너 릴리스에 들어갈 수 있는 호환되지 않는 변경을 컴파일러의 버그나 타입 시스템의 문제를 고치는 것으로 제한합니다. 건전성(soundness)의 구멍을 막다 보면, 그 구멍에 우연히 기대던 코드가 컴파일되지 않을 수 있기 때문입니다. 명세가 덜 정해진 부분을 정하는 변경도 같은 방식으로 다루며, 타입 추론의 몇몇 세부 동작도 바뀔 수 있다고 적습니다.

대신 RFC는 그런 변경의 영향을 먼저 재도록 합니다. 첫 단계는 crater 같은 도구로 crates.io의 크레이트들에 미치는 영향을 평가하는 것이며, 영향을 받는 크레이트의 수를 전체 영향을 가늠하는 대략적인 지표로 봅니다. 영향이 크다면 정한 범위 안에서 새 규칙을 따르지 않게 하는 표시를 주는 것 같은 완화 방법을 함께 두도록 합니다. 그래서 안정 버전을 올린 뒤 오래된 코드가 컴파일되지 않는다면, 그 변경이 이런 수정에 해당하는지 릴리스 노트에서 먼저 확인해 봅니다.

칙칙폭폭! 릴리즈 채널과 기차 타기

러스트의 개발은 기차 일정(train schedule)에 따라 이루어집니다. 곧 모든 개발은 러스트 저장소의 main 브랜치에서 이루어집니다. 릴리스는 Cisco IOS와 다른 소프트웨어 프로젝트에서 써 온 소프트웨어 릴리스 기차 모델(train model)을 따릅니다. 러스트에는 세 개의 릴리스 채널이 있습니다.

대부분의 러스트 개발자는 주로 안정(stable) 채널을 쓰지만, 실험적인 새 기능을 써 보고 싶은 사람은 nightly나 beta를 쓸 수 있습니다. 아래 그림은 이 세 채널이 6주 주기로 어떻게 맞물리는지 보여 줍니다.

main의 스냅숏이 매일 자동으로 만들어져 nightly가 됩니다. 0주에 그때의 main에서 beta N이 갈라지고, 이전 구간에서 검증한 beta N−1은 stable N−1로 올라옵니다. 6주가 지나면 beta N이 stable N으로 올라오고, 같은 시점의 main에서 beta N+1이 새로 갈라집니다. 12주에는 beta N+1이 stable N+1로 올라오고 beta N+2가 갈라집니다. 이처럼 새 beta가 출발하는 시점과 이전 beta가 stable에 도착하는 시점은 6주마다 겹칩니다. beta에는 다음 안정 버전에 꼭 필요한 수정만 골라 되돌려 넣을(backport) 수 있습니다.

개발과 릴리스 과정이 어떻게 동작하는지 예를 들어 봅니다. 러스트 팀이 Rust 1.5의 릴리스를 준비하고 있다고 합시다. 그 릴리스는 2015년 12월에 있었지만, 버전 번호를 현실적으로 보여 줄 것입니다. 러스트에 새 기능이 더해집니다. 새 커밋이 main 브랜치에 들어갑니다. 밤마다 러스트의 새 nightly 판이 만들어집니다. 매일이 릴리스 날이며, 이 릴리스들은 릴리스 기반 시설이 자동으로 만듭니다. 시간이 지나며 릴리스는 매일 밤 한 번씩 나옵니다.

6주마다 새 릴리스를 준비할 때가 됩니다. 러스트 저장소의 beta 브랜치가 nightly가 쓰는 main 브랜치에서 갈라집니다. 이제 nightly와 beta, 두 릴리스가 있습니다. 대부분의 러스트 사용자는 beta 릴리스를 직접 쓰지 않지만, 러스트의 CI 시스템에서 beta로 테스트해 전에는 되던 동작이 새 버전에서 깨지는 회귀(regression)를 찾도록 돕습니다. 변경 뒤에 이미 되던 동작을 다시 확인하는 회귀 테스트는 통합·인수·회귀 테스트에서 다룹니다. 그동안에도 nightly 릴리스는 여전히 매일 밤 나옵니다.

회귀가 발견되었다고 합시다. 회귀가 안정 릴리스로 몰래 들어가기 전에 beta 릴리스를 테스트할 시간이 있었던 것이 다행입니다. 수정은 main에 적용되어 nightly가 고쳐지고, 그 수정이 beta 브랜치로 되돌려 넣어져 beta의 새 릴리스가 만들어집니다.

첫 beta가 만들어지고 6주가 지나면 안정 릴리스를 할 때입니다. stable 브랜치가 beta 브랜치에서 만들어집니다. 만세! Rust 1.5가 끝났습니다. 하지만 하나를 잊었습니다. 6주가 지났으므로 다음 버전의 러스트인 1.6의 새 beta도 필요합니다. 그래서 stable이 beta에서 갈라진 뒤, 다음 버전의 beta가 다시 nightly에서 갈라집니다.

이것을 기차 모델이라고 부르는 까닭은, 6주마다 릴리스가 "역을 떠나지만", 안정 릴리스로 도착하기 전에 여전히 beta 채널을 지나는 여정을 거쳐야 하기 때문입니다.

러스트는 6주마다 시계처럼 릴리스합니다. 러스트 릴리스 하나의 날짜를 안다면 다음 릴리스의 날짜도 알 수 있습니다. 6주 뒤입니다. 6주마다 릴리스가 예정되어 있다는 점의 좋은 면은, 다음 기차가 곧 온다는 것입니다. 어떤 기능이 특정 릴리스를 놓치더라도 걱정할 필요가 없습니다. 짧은 시간 뒤에 또 다른 릴리스가 오기 때문입니다. 이것은 릴리스 마감일 즈음에 덜 다듬어진 기능을 몰래 넣으려는 압박을 줄여 줍니다.

이 과정 덕분에 언제든 다음 러스트 빌드를 미리 받아, 업그레이드가 쉬운지 직접 확인할 수 있습니다. beta 릴리스가 기대한 대로 동작하지 않는다면 팀에 알려, 다음 안정 릴리스가 나오기 전에 고치게 할 수 있습니다. beta 릴리스에서 무언가 망가지는 일은 비교적 드물지만, rustc도 소프트웨어이며 버그는 있습니다.

유지보수 기간

러스트 프로젝트는 가장 최근의 안정 버전을 지원합니다. 새 안정 버전이 릴리스되면, 이전 버전은 수명이 다합니다(end of life, EOL). 곧 각 버전은 6주 동안 지원됩니다.

불안정한 기능

이 릴리스 모델에는 하나가 더 있습니다. 불안정한 기능입니다. 러스트는 기능 플래그(feature flag)라는 기법으로 어떤 릴리스에서 어떤 기능을 켤지 정합니다. 새 기능이 개발 중이라면 main에 들어가므로 nightly에도 들어가지만, 기능 플래그 뒤에 있습니다. 사용자로서 개발 중인 기능을 써 보고 싶다면 그렇게 할 수 있지만, 러스트의 nightly 릴리스를 써야 하고 소스 코드에 알맞은 플래그를 달아 그 기능을 켜겠다고 선택해야 합니다.

#![feature(never_type)]

fn main() {}

#![feature(...)] 같은 속성은 nightly 컴파일러에서만 받아들여지며, beta나 stable 릴리스에서 쓰면 컴파일 오류가 납니다. 사용자가 beta나 stable 릴리스를 쓴다면 기능 플래그는 쓸 수 없습니다. 이것이 새 기능을 영원히 안정이라고 선언하기 전에 실제로 써 볼 수 있게 해 주는 열쇠입니다. 최신 기능을 원하는 사람은 그렇게 선택할 수 있고, 단단한 경험을 원하는 사람은 stable에 머물며 자기 코드가 깨지지 않을 것이라고 알 수 있습니다. 정체되지 않는 안정성입니다.

이 교재는 안정된 기능에 대한 정보만 담고 있습니다. 개발 중인 기능은 계속 바뀌며, 이 교재가 쓰인 때와 그 기능이 안정 빌드에서 켜지는 때 사이에 분명 달라질 것입니다. nightly 전용 기능의 문서는 온라인에서 찾을 수 있습니다.

Rustup과 러스트 Nightly의 역할

rustup을 쓰면 전역으로든 프로젝트마다든 러스트의 서로 다른 릴리스 채널 사이를 쉽게 바꿀 수 있습니다. 기본으로는 안정 러스트가 설치되어 있습니다. 예를 들어 nightly를 설치하려면 다음을 실행합니다.

rustup toolchain install nightly

rustup으로 설치한 모든 툴체인(toolchain), 곧 러스트와 그에 딸린 구성 요소의 릴리스를 볼 수도 있습니다. 다음은 저자 한 명의 Windows 컴퓨터에서 본 예입니다.

rustup toolchain list

stable-x86_64-pc-windows-msvc (active, default)
beta-x86_64-pc-windows-msvc
nightly-x86_64-pc-windows-msvc

보이는 것처럼 안정 툴체인이 기본(default)이며, 지금 폴더에서 실제로 쓰이는 툴체인(active)도 안정 툴체인입니다. 대부분의 러스트 사용자는 대부분의 경우 stable을 씁니다. 대부분의 경우 stable을 쓰되, 최첨단 기능에 관심이 있어 특정 프로젝트에서 nightly를 쓰고 싶을 수도 있습니다. 그렇게 하려면 그 프로젝트의 폴더에서 rustup override를 써서, 그 폴더에 있을 때 rustup이 nightly 툴체인을 쓰게 합니다.

cd ~/projects/needs-nightly
rustup override set nightly

이제 ~/projects/needs-nightly 안에서 rustc나 cargo를 부를 때마다, rustup은 기본인 안정 러스트 대신 nightly 러스트를 쓰도록 보장합니다. 러스트 프로젝트가 많을 때 아주 쓸모가 있습니다. 아래 표는 목적에 따라 툴체인을 어떻게 고르고 고정할지 정리한 것입니다.

배포의 기준은 stable 하나로 끝나지 않습니다. Cargo.toml의 rust-version으로 지원하는 최소 러스트 버전(minimum supported Rust version, MSRV)을 밝히고, stable과 MSRV를 각각 CI에서 검증하며, MSRV를 바꿀 때는 릴리스 정책에 따라 밝힙니다. beta는 배포를 막는 기본 CI 작업과 나눈 보조 작업으로 돌려, 다음 안정 버전의 회귀를 일찍 찾아 보고하는 데 씁니다. nightly로 실험할 때는 저장소에 넣은 rust-toolchain.toml에 nightly-YYYY-MM-DD처럼 날짜를 정해 고정하고, 기능 게이트, 추적 이슈, 담당자, 갱신 주기, stable로 옮기거나 그만둘 조건을 기록합니다. 한 번 비교해 보는 정도라면 cargo +nightly build처럼 명령 하나에서만 툴체인을 고르고, 저장소의 기본값이나 CI 설정을 바꾸지 않습니다.

RFC 과정과 팀

그렇다면 이 새 기능들은 어떻게 알게 될까요? 러스트의 개발 모델은 의견 요청(Request For Comments, RFC) 과정을 따릅니다. 러스트를 개선하고 싶다면 RFC라는 제안서를 쓸 수 있습니다.

누구나 러스트를 개선하는 RFC를 쓸 수 있으며, 제안은 여러 주제의 하위 팀으로 이루어진 러스트 팀이 검토하고 논의합니다. 팀의 전체 목록은 러스트 웹사이트에 있으며, 언어 설계, 컴파일러 구현, 기반 시설, 문서 같은 프로젝트의 각 영역마다 팀이 있습니다. 알맞은 팀이 제안과 의견을 읽고, 자신의 의견을 쓰고, 결국 그 기능을 받아들일지 거절할지 합의에 이릅니다.

기능이 받아들여지면, 러스트 저장소에 이슈가 열리고, 누군가 그것을 구현할 수 있습니다. 그 기능을 구현하는 사람이 처음에 그 기능을 제안한 사람이 아닐 수도 있습니다. 구현이 준비되면 앞의 불안정한 기능에서 이야기한 것처럼 기능 게이트 뒤에서 main 브랜치에 들어갑니다.

시간이 지나, nightly 릴리스를 쓰는 러스트 개발자들이 새 기능을 써 볼 수 있게 되면, 팀원들이 그 기능과 그것이 nightly에서 어떻게 동작했는지 논의하고, 안정 러스트에 들어가야 할지 정합니다. 앞으로 나아가기로 하면 기능 게이트가 없어지고, 이제 그 기능은 안정된 것으로 여겨집니다. 기차를 타고 새 안정 러스트 릴리스에 이릅니다. 다만 모든 변경이 RFC에서 시작하지는 않습니다. 중요한 설계 변경은 RFC를 거치는 경우가 많지만, 버그 수정이나 문서 개선, 작은 구현 변경은 보통 RFC 없이 이루어집니다.

정리

• 러스트는 정체되지 않는 안정성을 원칙으로, 안정 버전을 올려도 코드가 깨지지 않으면서 새 기능과 개선을 받게 합니다.
• nightly는 main에서 매일, beta는 6주마다 main에서 갈라지고, 6주 동안 검증한 beta가 stable이 되며, 안정 버전은 다음 버전이 나올 때까지 6주 동안 지원됩니다.
• 개발 중인 기능은 기능 플래그 뒤에 있어 nightly에서 #![feature(...)]로만 쓸 수 있습니다.
• rustup으로 rustup toolchain install nightly처럼 툴체인을 설치하고, rustup override set이나 rust-toolchain.toml로 프로젝트마다 툴체인을 고정하며, cargo +nightly로 명령 하나에서만 고를 수 있습니다.
• 큰 설계 변경은 RFC로 제안되고 팀이 검토해 받아들이며, 구현은 기능 게이트 뒤에서 시험된 뒤 안정화됩니다.

연습 문제

1. 언제 stable이 될까

어떤 수정이 main에 들어간 날 beta가 막 갈라졌다면, 그 수정은 대략 언제 stable에 들어가나요? beta로 되돌려 넣는다면 어떻게 되나요?

2. 툴체인을 어떻게 고정할까

라이브러리를 배포하는 팀이 (가) 최소 Rust 1.85를 지원하겠다고 약속하고 싶다. (나) 아직 불안정한 기능 하나를 실험용 브랜치에서 쓰고 싶다. 각각 무엇을 하나요?

이것으로 부록을 마칩니다. 처음부터 다시 훑어보고 싶다면 러스트 교재의 목차로 돌아가세요.