Google Rust 가이드의 async 금지, 우리 팀도 따라야 할까?

세 줄 요약

Google 가이드의 async/await 금지를 모든 Rust 프로젝트에 적용할 필요는 없다. 해당 조항의 대상은 Chromium이다.
스레드·동기화 규칙에도 코드베이스별 범위가 있으며, 라이브러리와 애플리케이션의 API 권고 강도도 다르다.
팀에 채택한 규칙은 타입 설계 검토, rustfmt 포맷 검사, 개별 Clippy 린트로 나눠 관리할 수 있다.

규칙 제목에서 코드베이스 이름을 떼면 의미가 달라진다

Google Rust 스타일 가이드는 Google 내 Rust 사용을 위한 문서다. 최근 GeekNews에 공유된 이 가이드를 팀 규칙으로 가져오려면 항목별 적용 범위부터 봐야 한다.

항목	문서가 지정한 범위
async/await 사용 금지	Chromium
표준 라이브러리로 새 스레드 생성 금지, sequence 우선	Chromium
fuchsia_sync::Mutex 사용	Fuchsia

API 설계 규칙도 라이브러리에는 구속력을 두지만, 애플리케이션에는 강한 권고로 설명한다. 앱은 당장 필요한 문제를 단순하게 푸는 데 무게를 둔다. 외부 프로젝트가 이 표를 Rust 언어 전체의 금지 목록으로 받아들일 이유는 없다.

불리언 인수보다 이름 있는 타입이 의도를 잘 드러낸다

Rust API Guidelines는 인수의 의미를 타입으로 표현하도록 권한다. bool은 가능한 값은 적지만 무엇의 참·거짓인지는 호출만 보고 알기 어렵다.

예를 들어 문서 저장 옵션을 설명하기 위한 호출 save(true, false)를 생각할 수 있다. 설명용 예시를 save(Overwrite::Allow, Backup::Skip)처럼 바꾸면 각 선택의 뜻이 드러난다. 실제 코드에 필요한 타입은 API가 표현해야 할 선택에 맞춰 정한다.

같은 문서는 마일과 킬로미터를 서로 다른 newtype으로 구분하는 예도 든다. 둘 다 숫자로 저장하더라도 함수가 요구한 단위를 컴파일러가 구별하도록 만드는 방식이다. 이름만 바꾼 숫자 변수보다 타입 수준에서 혼동을 줄일 수 있다.

rustfmt는 포맷 차이를 검사한다

rustfmt를 Cargo 프로젝트에서 검사 모드로 쓰는 형태는 cargo fmt -- --check다. 포맷을 바꿀 필요가 없으면 성공하고, 차이가 있으면 이를 출력하며 실패 상태를 반환한다. CI에서 형식을 통일하는 데 쓸 수 있다.

그 결과는 코드의 외형에 대한 검사다. 어떤 인수를 별도 타입으로 만들지, 함수의 책임을 어디까지 둘지는 리뷰에서 판단해야 한다. rustfmt 문서도 매크로와 주석 등에는 처리나 형식 안정성에 제약이 있음을 밝힌다.

Clippy의 제한 규칙은 많이 켜는 것이 목표가 아니다

Clippy 사용 문서에 따르면 cargo clippy는 기본 린트 집합을 실행한다. 추가적인 pedantic 그룹은 더 엄격한 판단을 하며, 의도한 코드에도 경고가 생길 수 있어 예외 설정이 필요할 수 있다.

restriction 그룹은 특히 항목별 선택이 중요하다. 문서는 이 그룹을 통째로 활성화하지 말라고 명시한다. 일부 규칙이 다른 Clippy 규칙과 충돌할 수 있기 때문이다. 팀이 막으려는 패턴을 정한 뒤 해당 린트를 고르는 편이 맞다.

자주 묻는 질문

cargo fmt가 통과하면 API 설계도 검수된 것인가?

아니다. 포맷에 차이가 없다는 뜻이다. 인수의 의미와 함수의 책임은 별도로 검토해야 한다.

더 엄격하게 검사하려면 restriction 전체를 켜면 되는가?

Clippy 문서는 전체 활성화 대신 필요한 린트를 개별 선택하도록 안내한다.

팀에 가져올 규칙은 적용 대상, 자동 검사 가능 여부, 허용할 예외를 함께 적어야 한다. 다른 코드베이스의 금지 목록을 복사하는 것보다 그 구분이 먼저다.