구글 스타일 가이드에 Rust가 추가됐어요
구글은 오래전부터 사내 코딩 규칙을 google.github.io/styleguide에 공개해 왔어요. C++, Java, Python, Go처럼 언어마다 가이드가 따로 있는데요, 그중 C++ 가이드는 '예외(exception)를 쓰지 않는다' 같은 과감한 결정으로 유명하죠. 이번에 여기에 Rust 스타일 가이드가 새로 올라왔어요.
이게 왜 의미 있냐면, 구글은 Rust를 실험 삼아 써보는 회사가 아니거든요. 안드로이드 팀은 몇 년째 새로운 시스템 코드를 Rust로 작성하고 있어요. 구글이 공개한 자료를 보면 안드로이드 취약점 가운데 메모리 안전성 관련 비중이 2019년 76%에서 2024년 24%까지 떨어졌고요. 크롬도 폰트 파싱처럼 위험한 코드를 Rust로 옮기는 중이고, 사내 교육용으로 만든 'Comprehensive Rust' 강의도 공개돼 있어요. 수천 명이 같은 Rust 코드베이스를 함께 고치는 회사가 '우리는 이렇게 쓴다'고 정리한 문서라서 무게가 있는 거예요.
rustfmt와 clippy가 있는데 왜 또 가이드가 필요할까
Rust를 써보신 분이라면 이런 의문이 들 수 있어요. Rust에는 공식 포매터 rustfmt와 꽤 강력한 린터 clippy가 이미 있잖아요. 들여쓰기나 줄바꿈은 rustfmt가 알아서 맞춰주고, 비효율적인 패턴은 clippy가 잡아주죠.
그런데 스타일 가이드는 그 너머의 영역을 다뤄요. 비유하자면 rustfmt는 '맞춤법 검사기'고, 스타일 가이드는 '팀의 글쓰기 원칙'에 가까워요. 맞춤법이 다 맞아도 읽기 힘든 글이 있잖아요. 코드도 마찬가지라서, 컴파일도 되고 clippy 경고도 없는데 동료가 이해하기 어려운 코드가 있거든요.
대표적인 게 unwrap()이에요. 이게 뭐냐면, 값이 없거나 에러가 났을 때 프로그램을 그 자리에서 패닉으로 멈춰버리는 함수예요. 프로토타입 만들 땐 편한데, 서버에서 쓰면 바로 장애로 이어지죠. 그래서 팀마다 '테스트 코드에서만 허용', 'expect로 이유를 꼭 남기기', '? 연산자로 에러를 위로 넘기기' 같은 규칙을 정해 둬요. unsafe도 비슷해요. 컴파일러의 안전 검사를 잠깐 끄는 블록인데, 그래도 이 코드가 왜 안전한지를 // SAFETY: 주석으로 남기는 게 커뮤니티 관례예요. clippy에도 이걸 강제하는 린트가 있고요. 이 밖에도 에러 타입을 라이브러리마다 직접 정의할지 범용 에러 타입으로 처리할지, 제네릭과 트레이트 객체(dyn Trait) 중 뭘 기본으로 쓸지, 매크로는 어디까지 허용할지 같은 문제가 있어요. 이런 건 도구가 대신 답해주지 못하고, 정답이 하나로 정해져 있지도 않아요. 그래서 '팀이 합의한 기본값'이 필요한 거예요.
기존 문서들과 무엇이 다를까
헷갈리기 쉬운 부분이 있는데요, Rust 프로젝트에도 공식 'Rust Style Guide'가 있어요. 다만 이건 rustfmt의 기본 서식을 정의한 문서라서 주로 코드 모양을 다뤄요. 'Rust API Guidelines'는 공개 크레이트를 만들 때 이름은 어떻게 짓고 트레이트는 어떻게 구현할지 같은 API 설계 원칙을 정리한 문서예요. 리눅스 커널도 Rust 코드용 코딩 가이드라인을 따로 두고 있고요.
구글 가이드는 이 문서들과 결이 좀 달라요. 초점이 '큰 조직 안에서 많은 사람이 함께 유지보수할 코드'에 맞춰져 있거든요. 구글이 2022년에 공개한 Go 스타일 가이드를 떠올려보면 감이 와요. 그 가이드는 규칙만 늘어놓지 않고 '왜 그렇게 하는지'를 길게 설명하는 게 특징이었어요. 그러니 이번 가이드도 규칙 자체보다 그 근거를 중심으로 읽어보시면 얻는 게 훨씬 많을 거예요.
한국 개발자에게 주는 시사점
국내에서도 블록체인, 게임 서버, 고성능 프록시, 임베디드 쪽을 중심으로 Rust를 도입하는 팀이 늘고 있어요. 그런데 도입 초기 팀들이 다 같이 겪는 문제가 있어요. 각자 공부한 방식대로 코드를 짠다는 거예요. 누구는 이터레이터 체인을 길게 엮고, 누구는 빌림 검사기(borrow checker, 메모리 소유권 규칙을 검사하는 컴파일러 기능)를 피하려고 clone()을 남발하고요. 이게 쌓이면 코드 리뷰가 취향 싸움으로 번져요.
이럴 땐 구글 가이드를 팀 컨벤션의 출발점으로 삼아보세요. 전부 따를 필요는 없어요. '기본은 구글 가이드, 우리 팀은 이 부분만 다르게' 하는 식으로 차이점만 적어 둬도 논쟁이 확 줄어요. 그리고 자동화할 수 있는 건 최대한 자동화하세요. rustfmt.toml과 clippy 린트 설정으로 강제할 수 있는 건 CI에 넣고, 사람이 판단해야 하는 부분만 가이드로 남기는 게 정석이에요. Rust를 공부 중인 주니어에게도 좋은 교재예요. 문법 책이 '이렇게 쓸 수 있다'를 알려준다면, 스타일 가이드는 '실무에선 이렇게 쓰는 게 낫다'를 알려주거든요.
마무리
한줄 정리: 도구는 서식을 맞춰주고, 스타일 가이드는 판단을 맞춰줘요. Rust를 대규모로 쓰는 구글의 기준은 팀 컨벤션의 좋은 출발점이에요.
여러분 팀은 unwrap처럼 '편하지만 위험한' 기능을 어디까지 허용하고 있나요? 사내 코딩 컨벤션 문서가 실제로 잘 지켜지고 있는지도 궁금해요.
🔗 출처: Hacker News