러스트 프로그래밍 언어

Steve Klabnik, Carol Nichols, Chris Krycho 공저, 그리고 러스트 커뮤니티의 기여

이 판본은 모든 프로젝트의 Cargo.toml 파일에 edition = "2024" 를 설정하여 Rust 2024 에디션 관용구를 사용하고, Rust 1.90.0(2025-09-18 출시) 이상을 사용한다고 가정합니다. 설치하거나 업데이트하는 방법은 1장 “설치” 절을 참고하고, 에디션 정보는 부록 E를 참고하세요.

HTML 형식은 https://doc.rust-lang.org/stable/book/ 에서 온라인으로 읽을 수 있고, rustup 으로 설치한 Rust에는 오프라인 문서도 포함되어 있습니다. rustup doc --book 명령으로 열 수 있습니다.

커뮤니티에서 만든 여러 번역본도 제공됩니다.

이 책은 No Starch Press에서 종이책과 전자책으로도 구매할 수 있습니다.

🚨 더 상호작용적인 학습 경험을 원하나요? 퀴즈, 하이라이트, 시각화 등 여러 기능이 포함된 다른 버전의 러스트 책도 있습니다: https://rust-book.cs.brown.edu

머리말

러스트 프로그래밍 언어는 짧은 몇 년 사이에 아주 먼 길을 걸어왔습니다. 소수의 초기 열성 팬들이 만들고 키워 낸 작은 공동체에서 출발해, 이제는 전 세계에서 가장 사랑받고 가장 수요가 높은 프로그래밍 언어 중 하나가 되었습니다. 돌이켜 보면, 러스트의 힘과 가능성이 사람들의 시선을 끌고 시스템 프로그래밍 분야에 자리를 잡으리라는 점은 어느 정도 필연적이었습니다. 그러나 오픈 소스 커뮤니티 전반에 퍼져 나간 전 세계적 관심의 성장과 혁신, 그리고 그것이 산업 전반의 대규모 도입을 촉진하리라는 점은 결코 당연한 일이 아니었습니다.

오늘날 러스트에 대한 관심과 채택이 폭발적으로 늘어난 이유를 설명하는 것은 어렵지 않습니다. 메모리 안전성에, 빠른 성능에, 친절한 컴파일러에, 뛰어난 툴링까지 갖춘 언어를 누가 마다하겠습니까? 지금 여러분이 보고 있는 러스트는 시스템 프로그래밍에 대한 수년간의 연구와 활기차고 열정적인 커뮤니티의 실용적 지혜가 결합된 결과입니다. 이 언어는 분명한 목적 아래 세심하게 설계되었고, 개발자가 안전하고 빠르며 신뢰할 수 있는 코드를 더 쉽게 작성할 수 있도록 도와주는 도구를 제공합니다.

하지만 러스트를 진정 특별하게 만드는 것은, 사용자 여러분이 목표를 이룰 수 있도록 힘을 실어 주겠다는 뿌리 깊은 철학입니다. 이 언어는 여러분의 성공을 바라며, 그런 역량 부여의 원칙은 러스트를 만들고 유지하고 알리는 커뮤니티의 중심부를 관통하고 있습니다. 이 결정판 교재의 이전 판 이후로도 러스트는 더욱 발전하여, 진정으로 세계적이고 신뢰받는 언어가 되었습니다. 러스트 프로젝트는 이제 러스트 재단의 탄탄한 지원을 받고 있으며, 재단은 러스트가 안전하고 안정적이며 지속 가능하도록 보장하는 핵심 이니셔티브에도 투자하고 있습니다.

이번 러스트 프로그래밍 언어 판은 언어가 세월에 따라 발전해 온 내용을 반영하고, 새롭고 가치 있는 정보를 담은 포괄적인 개정판입니다. 하지만 이것은 단순히 문법과 라이브러리를 설명하는 안내서가 아닙니다. 품질, 성능, 그리고 사려 깊은 설계를 중시하는 커뮤니티로 여러분을 초대하는 책이기도 합니다. 처음으로 러스트를 탐험해 보려는 숙련 개발자든, 이미 러스트를 익혀 더 실력을 다듬고 싶은 경험 많은 러스타시안이든, 이번 판은 누구에게나 건질 것을 제공합니다.

러스트의 여정은 협업과 학습, 그리고 반복적인 개선의 역사였습니다. 언어와 생태계의 성장은 그 뒤에 있는 활기차고 다양한 커뮤니티를 있는 그대로 반영합니다. 핵심 언어 설계자부터 가볍게 기여한 참여자들까지, 수천 명의 개발자가 보탠 기여가 러스트를 이렇게 독특하고 강력한 도구로 만들었습니다. 여러분이 이 책을 집어 드는 순간, 단지 새로운 프로그래밍 언어를 배우는 것이 아닙니다. 소프트웨어를 더 좋고, 더 안전하고, 더 즐겁게 만드는 흐름에 동참하게 되는 것입니다.

러스트 커뮤니티에 오신 것을 환영합니다!

• 러스트 재단 사무총장, Bec Rumbul

들어가며

러스트 프로그래밍 언어 에 오신 것을 환영합니다. 이 책은 러스트를 소개하는 입문서입니다. 러스트 프로그래밍 언어는 더 빠르고 더 신뢰할 수 있는 소프트웨어를 작성하도록 도와줍니다. 보통 프로그래밍 언어를 설계할 때는 고수준의 사용 편의성과 저수준의 세밀한 제어가 서로 충돌합니다. 러스트는 이 충돌에 정면으로 도전합니다. 강력한 기술적 역량과 훌륭한 개발 경험의 균형을 통해, 러스트는 메모리 사용량 같은 저수준 세부 사항을 제어하면서도 그에 따라붙기 마련이던 번거로움은 크게 줄여 줍니다.

러스트는 누구를 위한 언어인가

러스트는 여러 이유로 다양한 사람들에게 잘 맞는 언어입니다. 그중에서도 특히 중요한 몇 부류를 살펴보겠습니다.

개발자 팀

러스트는 시스템 프로그래밍 지식 수준이 서로 다른 대규모 개발자 팀이 협업할 때 생산적인 도구임이 입증되고 있습니다. 저수준 코드는 다양한 미묘한 버그에 취약한데, 대부분의 다른 언어에서는 이런 버그를 광범위한 테스트와 숙련 개발자의 세심한 코드 리뷰를 통해서만 잡아낼 수 있습니다. 러스트에서는 컴파일러가 문지기 역할을 수행하여, 동시성 버그를 포함한 이런 잡기 어려운 버그가 있는 코드는 아예 컴파일하지 않습니다. 팀은 컴파일러와 함께 일함으로써 버그를 쫓는 데 시간을 쓰기 보다 프로그램의 논리에 집중할 수 있습니다.

러스트는 시스템 프로그래밍 세계에 현대적인 개발 도구도 함께 가져왔습니다.

• 함께 제공되는 의존성 관리자이자 빌드 도구인 Cargo는 의존성 추가, 컴파일, 관리 작업을 러스트 생태계 전반에서 일관되고 수월하게 만들어 줍니다.
• rustfmt 포매터는 여러 개발자 사이에서 일관된 코딩 스타일을 보장합니다.
• Rust Language Server는 코드 자동 완성과 인라인 오류 메시지 같은 통합 개발 환경 (IDE) 연동을 가능하게 합니다.

이런 도구들과 러스트 생태계의 다른 도구들을 활용하면, 개발자는 시스템 수준의 코드를 작성하면서도 높은 생산성을 유지할 수 있습니다.

학생

러스트는 학생과 시스템 개념을 배우고 싶은 사람들에게도 잘 맞습니다. 많은 사람이 러스트를 사용하면서 운영체제 개발 같은 주제를 배웠습니다. 커뮤니티는 매우 친절하며 학생들의 질문에 기꺼이 답해 줍니다. 러스트 팀은 이 책과 같은 노력을 통해, 특히 프로그래밍을 처음 접하는 사람들에게 시스템 개념을 더 쉽게 접할 수 있게 만들고자 합니다.

기업

대기업과 소기업을 포함한 수백 개의 회사가 커맨드라인 도구, 웹 서비스, DevOps 도구, 임베디드 장치, 오디오·비디오 분석 및 트랜스코딩, 암호화폐, 생물정보학, 검색 엔진, 사물 인터넷 애플리케이션, 머신 러닝, 심지어 Firefox 웹 브라우저의 핵심 일부에 이르기까지 다양한 분야에서 러스트를 실제 운영 환경에 사용하고 있습니다.

오픈 소스 개발자

러스트는 러스트 언어 자체와 커뮤니티, 개발 도구, 라이브러리를 함께 만들어 가고 싶은 사람들을 위한 언어이기도 합니다. 러스트 언어에 기여해 주신다면 언제든 환영합니다.

속도와 안정성을 중시하는 사람

러스트는 언어에서 속도와 안정성을 모두 원하는 사람을 위한 언어입니다. 여기서 말하는 속도는 러스트 코드가 얼마나 빠르게 실행되는가뿐 아니라, 러스트가 얼마나 빠르게 프로그램을 작성하게 해 주는가도 포함합니다. 러스트 컴파일러의 검사는 기능 추가와 리팩터링 과정에서도 안정성을 보장합니다. 이런 검사가 없는 언어의 낡고 깨지기 쉬운 레거시 코드와는 대조적이며, 그런 코드들은 개발자가 수정 자체를 두려워하는 경우가 많습니다. 러스트는 수동으로 작성한 저수준 코드만큼 빠르게 컴파일되는 고수준 기능, 즉 zero-cost abstraction을 지향함으로써 안전한 코드가 곧 빠른 코드가 되도록 노력합니다.

러스트는 여기서 언급한 사람들 외에도 훨씬 더 많은 사용자를 지원하고자 합니다. 지금 소개한 부류는 그중 일부의 대표적인 이해관계자일 뿐입니다. 전체적으로 보면, 러스트의 가장 큰 야망은 프로그래머가 수십 년 동안 당연하게 받아들여 온 절충을 없애는 데 있습니다. 안전성 그리고 생산성, 속도 그리고 사용 편의성을 함께 제공하겠다는 것입니다. 러스트를 직접 써 보고, 이런 선택이 여러분에게도 잘 맞는지 확인해 보세요.

이 책은 누구를 위한 책인가

이 책은 여러분이 다른 프로그래밍 언어로 코드를 작성해 본 적은 있다고 가정하지만, 그 언어가 무엇인지는 가정하지 않습니다. 다양한 배경을 가진 독자가 폭넓게 접근할 수 있도록 내용을 구성하려 했습니다. 프로그래밍이 무엇인지, 혹은 프로그래밍을 어떻게 사고해야 하는지에 대해서는 많은 시간을 쓰지 않습니다. 만약 여러분이 프로그래밍을 완전히 처음 접한다면, 프로그래밍 자체를 소개하는 입문서를 먼저 읽는 편이 더 나을 수 있습니다.

이 책을 사용하는 방법

대체로 이 책은 앞에서 뒤로 순서대로 읽는 것을 전제로 합니다. 뒤의 장들은 앞선 장들의 개념을 바탕으로 하며, 앞 장에서 어떤 주제를 자세히 다루지 않더라도 뒤 장에 가서 다시 그 주제를 깊게 다루는 경우가 있습니다.

이 책에는 두 종류의 장이 있습니다. 개념 장과 프로젝트 장입니다. 개념 장에서는 러스트의 특정 측면을 배우고, 프로젝트 장에서는 지금까지 배운 내용을 적용해 작은 프로그램을 함께 만들어 봅니다. 2장, 12장, 21장은 프로젝트 장이고, 나머지는 개념 장입니다.

1장에서는 러스트 설치 방법, “Hello, world!” 프로그램 작성 방법, 그리고 러스트의 패키지 관리자이자 빌드 도구인 Cargo 사용법을 설명합니다. 2장은 러스트로 프로그램을 작성하는 실습형 입문 장으로, 숫자 맞히기 게임을 만들어 봅니다. 여기서는 개념을 높은 수준에서 다루고, 자세한 내용은 뒤 장들에서 보강합니다. 손을 바로 움직여 보고 싶다면 2장이 좋은 출발점입니다. 반대로 모든 세부를 익힌 뒤 다음으로 넘어가고 싶은 꼼꼼한 학습자라면, 다른 프로그래밍 언어와 비슷한 러스트 기능을 설명하는 3장으로 먼저 가도 됩니다. 그런 다음 배운 내용을 프로젝트에 적용해 보고 싶을 때 2장으로 돌아오면 됩니다.

4장에서는 러스트의 소유권 시스템을 배웁니다. 5장에서는 구조체와 메서드를 다루고, 6장에서는 열거형, match 식, if let 및 let...else 제어 흐름 구문을 다룹니다. 여러분은 구조체와 열거형을 사용해 자신만의 타입을 만들게 됩니다.

7장에서는 러스트의 모듈 시스템과, 코드와 공개 애플리케이션 프로그래밍 인터페이스(API)를 구성하기 위한 공개 범위 규칙을 배웁니다. 8장에서는 표준 라이브러리가 제공하는 대표적인 컬렉션 자료구조인 벡터, 문자열, 해시 맵을 다룹니다. 9장에서는 러스트의 에러 처리 철학과 기법을 살펴봅니다.

10장에서는 여러 타입에 적용되는 코드를 정의할 수 있게 해 주는 제네릭, 트레이트, 라이프타임을 깊이 있게 다룹니다. 11장은 테스트에 관한 내용으로, 러스트의 안전성 보장이 있더라도 프로그램의 논리가 올바른지 확인하려면 테스트가 필요하다는 점을 보여 줍니다. 12장에서는 파일 안의 텍스트를 검색하는 grep 명령줄 도구 기능의 일부를 직접 구현해 봅니다. 여기서는 앞 장에서 다룬 많은 개념을 활용합니다.

13장에서는 함수형 프로그래밍 언어에서 온 러스트 기능인 클로저와 반복자를 살펴봅니다. 14장에서는 Cargo를 더 깊이 들여다보고, 라이브러리를 다른 사람과 공유할 때의 모범 사례를 이야기합니다. 15장에서는 표준 라이브러리가 제공하는 스마트 포인터와, 그 기능을 가능하게 하는 트레이트를 다룹니다.

16장에서는 다양한 동시성 프로그래밍 모델을 둘러보고, 러스트가 여러 스레드를 겁 없이 다룰 수 있게 어떻게 도와주는지 설명합니다. 17장에서는 그 내용을 바탕으로 러스트의 async, await 문법과 태스크, 퓨처, 스트림, 그리고 그것들이 가능하게 하는 경량 동시성 모델을 탐구합니다.

18장에서는 여러분이 익숙할 수 있는 객체 지향 프로그래밍 원칙과 러스트식 관용 표현을 비교해 봅니다. 19장은 패턴과 패턴 매칭에 대한 참고서 같은 장으로, 러스트 프로그램 전반에서 아이디어를 강력하게 표현하는 방법을 다룹니다. 20장에는 unsafe Rust, 매크로, 그리고 라이프타임, 트레이트, 타입, 함수, 클로저에 대한 추가 논의를 포함해 다양한 고급 주제가 담겨 있습니다.

21장에서는 저수준 멀티스레드 웹 서버를 구현하는 프로젝트를 완성합니다!

마지막으로, 몇몇 부록에는 언어에 관한 유용한 정보를 좀 더 참고서 형식으로 정리해 두었습니다. 부록 A는 러스트의 키워드, 부록 B는 연산자와 기호, 부록 C는 표준 라이브러리가 제공하는 파생 가능한 트레이트, 부록 D는 유용한 개발 도구, 부록 E는 러스트 에디션을 설명합니다. 부록 F에서는 이 책의 번역본을 찾을 수 있고, 부록 G에서는 러스트가 어떻게 만들어지는지와 nightly Rust가 무엇인지 설명합니다.

이 책을 읽는 데 정답은 없습니다. 앞부분을 건너뛰고 싶다면 그렇게 해도 됩니다. 다만 헷갈리는 부분이 생기면 앞 장으로 다시 돌아와야 할 수도 있습니다. 결국 여러분에게 가장 잘 맞는 방식으로 읽으면 됩니다.

러스트를 배우는 과정에서 매우 중요한 부분 중 하나는 컴파일러가 보여 주는 오류 메시지를 읽는 법을 익히는 것입니다. 이 메시지들은 여러분을 올바르게 동작하는 코드로 이끌어 줍니다. 그래서 이 책에는 컴파일되지 않는 예제와, 그 상황에서 컴파일러가 실제로 보여 줄 오류 메시지를 함께 많이 실었습니다. 눈에 띄는 예제를 아무거나 입력해서 실행하면 컴파일되지 않을 수도 있다는 점을 기억하세요! 실행하려는 예제가 원래 오류를 내도록 의도된 것인지 주변 설명을 꼭 읽어 보아야 합니다. 대부분의 경우 컴파일되지 않는 코드에 대해서는 올바른 버전까지 함께 안내할 것입니다. Ferris는 원래 동작하지 않도록 의도된 코드를 구분하는 데도 도움을 줍니다.

Ferris	의미
	이 코드는 컴파일되지 않습니다!
	이 코드는 패닉이 발생합니다!
	이 코드는 원하는 동작을 만들어 내지 못합니다.

대부분의 경우, 컴파일되지 않는 코드는 올바른 버전까지 함께 안내할 것입니다.

소스 코드

이 책을 생성하는 데 사용된 원본 파일은 GitHub에서 찾을 수 있습니다.

시작하기

이제 러스트 여정을 시작해 봅시다! 배울 것은 많지만, 모든 여정은 어디선가 시작합니다. 이 장에서는 다음 내용을 다룹니다.

• Linux, macOS, Windows에 Rust 설치하기
• Hello, world! 를 출력하는 프로그램 작성하기
• 러스트의 패키지 관리자이자 빌드 시스템인 cargo 사용하기

설치

설치

첫 번째 단계는 Rust를 설치하는 것입니다. Rust 버전과 관련 도구를 관리하는 명령줄 도구인 rustup 을 통해 Rust를 내려받겠습니다. 다운로드하려면 인터넷 연결이 필요합니다.

다음 단계는 Rust 컴파일러의 최신 안정 버전을 설치합니다. 러스트의 안정성 보장은 이 책에서 컴파일되는 모든 예제가 더 새로운 Rust 버전에서도 계속 컴파일되도록 보장합니다. 다만 Rust는 오류 메시지와 경고를 자주 개선하므로, 버전에 따라 출력이 조금 다를 수는 있습니다. 다시 말해, 여기 소개한 방법으로 설치한 더 새로운 안정 버전의 Rust라면 이 책의 내용과 함께 예상대로 동작해야 합니다.

Linux 또는 macOS에 rustup 설치하기

Linux나 macOS를 사용한다면 터미널을 열고 다음 명령을 입력하세요.

$ curl --proto '=https' --tlsv1.2 https://sh.rustup.rs -sSf | sh

이 명령은 스크립트를 내려받고 rustup 도구 설치를 시작합니다. rustup 은 Rust의 최신 안정 버전을 설치해 줍니다. 중간에 비밀번호 입력을 요구할 수 있습니다. 설치에 성공하면 다음 줄이 표시됩니다.

Rust is installed now. Great!

또한 linker 도 필요합니다. 이것은 Rust가 컴파일 결과물을 하나의 파일로 연결할 때 사용하는 프로그램입니다. 아마 이미 설치되어 있을 가능성이 큽니다. linker 관련 오류가 발생한다면 보통 linker를 포함하는 C 컴파일러를 설치해야 합니다. C 컴파일러는 일부 널리 쓰이는 Rust 패키지가 C 코드에 의존하기 때문에 그런 경우에도 유용합니다.

macOS에서는 다음 명령으로 C 컴파일러를 설치할 수 있습니다.

$ xcode-select --install

Linux 사용자는 일반적으로 사용하는 배포판의 문서에 따라 GCC나 Clang을 설치해야 합니다. 예를 들어 Ubuntu를 쓴다면 build-essential 패키지를 설치하면 됩니다.

Windows에 rustup 설치하기

Windows에서는 https://www.rust-lang.org/tools/install 으로 가서 Rust 설치 안내를 따르면 됩니다. 설치 과정 중 어느 시점에 Visual Studio를 설치하라는 안내가 나옵니다. 이것은 프로그램을 컴파일할 때 필요한 linker와 네이티브 라이브러리를 제공합니다. 이 단계에서 더 도움이 필요하다면 https://rust-lang.github.io/rustup/installation/windows-msvc.html를 참고하세요.

이 책의 나머지 부분에서는 cmd.exe 와 PowerShell 모두에서 동작하는 명령을 사용합니다. 둘 사이에 차이가 있는 경우에는 어느 쪽을 써야 하는지 따로 설명하겠습니다.

문제 해결

Rust가 제대로 설치되었는지 확인하려면 셸을 열고 다음 줄을 입력하세요.

$ rustc --version

다음과 같은 형식으로, 가장 최근에 릴리스된 안정 버전의 버전 번호, 커밋 해시, 커밋 날짜가 보여야 합니다.

rustc x.y.z (abcabcabc yyyy-mm-dd)

이 정보가 보인다면 Rust 설치에 성공한 것입니다! 보이지 않는다면 아래와 같이 Rust가 %PATH% 시스템 변수에 들어 있는지 확인하세요.

Windows CMD에서는 다음을 사용합니다.

> echo %PATH%

PowerShell에서는 다음을 사용합니다.

> echo $env:Path

Linux와 macOS에서는 다음을 사용합니다.

$ echo $PATH

이 모든 것이 맞는데도 Rust가 동작하지 않는다면 도움을 받을 수 있는 곳이 여럿 있습니다. 다른 Rustacean(우리가 스스로를 부르는 다소 장난스러운 별명)과 어떻게 연락할 수 있는지는 커뮤니티 페이지에서 확인할 수 있습니다.

업데이트와 제거

rustup 으로 Rust를 설치했다면 새로 릴리스된 버전으로 업데이트하는 것은 쉽습니다. 셸에서 다음 업데이트 명령을 실행하세요.

$ rustup update

Rust와 rustup 을 제거하려면 셸에서 다음 제거 명령을 실행하세요.

$ rustup self uninstall

로컬 문서 읽기

Rust를 설치하면 문서의 로컬 사본도 함께 설치되므로 오프라인에서도 읽을 수 있습니다. rustup doc 명령을 실행하면 브라우저에서 로컬 문서가 열립니다.

표준 라이브러리가 제공하는 타입이나 함수가 무엇을 하는지, 어떻게 사용하는지 확실하지 않을 때는 언제든 API 문서를 찾아보세요!

텍스트 에디터와 IDE 사용하기

이 책은 여러분이 Rust 코드를 작성할 때 어떤 도구를 쓰는지에 대해 아무 가정도 하지 않습니다. 거의 모든 텍스트 에디터로 충분합니다! 다만 많은 텍스트 에디터와 통합 개발 환경(IDE)은 Rust를 기본적으로 지원합니다. Rust 웹사이트의 도구 페이지에서 다양한 에디터와 IDE의 비교적 최신 목록을 확인할 수 있습니다.

이 책을 오프라인으로 따라 하기

몇몇 예제에서는 표준 라이브러리 밖의 Rust 패키지를 사용합니다. 그런 예제를 따라 하려면 인터넷 연결이 있거나, 필요한 의존성을 미리 내려받아 두어야 합니다. 의존성을 미리 내려받으려면 다음 명령을 실행하면 됩니다. (cargo 가 무엇인지와 각 명령이 무엇을 하는지는 뒤에서 자세히 설명합니다.)

$ cargo new get-dependencies
$ cd get-dependencies
$ cargo add rand@0.8.5 trpl@0.2.0

이렇게 하면 해당 패키지 다운로드가 캐시에 저장되어 나중에 다시 내려받지 않아도 됩니다. 이 명령을 실행한 뒤에는 get-dependencies 폴더를 계속 보관할 필요는 없습니다. 이 과정을 마쳤다면, 책의 나머지 부분에서 사용하는 모든 cargo 명령에 --offline 플래그를 붙여 네트워크에 접근하려 하지 않고 캐시된 버전을 사용하도록 할 수 있습니다.

Hello, World!

Hello, World!

이제 Rust를 설치했으니 첫 번째 Rust 프로그램을 작성해 볼 차례입니다. 새로운 언어를 배울 때는 화면에 Hello, world! 라는 문구를 출력하는 작은 프로그램을 작성하는 것이 전통이므로, 여기서도 같은 방식으로 시작하겠습니다!

프로젝트 디렉터리 준비

먼저 Rust 코드를 저장할 디렉터리를 만듭니다. 러스트는 코드가 어디에 있든 상관하지 않지만, 이 책의 연습문제와 프로젝트를 위해서는 홈 디렉터리 아래에 projects 디렉터리를 만들고 모든 프로젝트를 그 안에 두는 방식을 권합니다.

터미널을 열고 다음 명령으로 projects 디렉터리와, 그 안에 “Hello, world!” 프로젝트용 디렉터리를 만드세요.

Linux, macOS, Windows의 PowerShell에서는 다음을 입력합니다.

$ mkdir ~/projects
$ cd ~/projects
$ mkdir hello_world
$ cd hello_world

Windows CMD에서는 다음을 입력합니다.

> mkdir "%USERPROFILE%\projects"
> cd /d "%USERPROFILE%\projects"
> mkdir hello_world
> cd hello_world

Rust 프로그램의 기초

다음으로 새 소스 파일을 만들고 이름을 main.rs 로 지정합니다. Rust 파일은 항상 .rs 확장자로 끝납니다. 파일 이름에 단어가 두 개 이상 들어간다면, 관례상 밑줄로 단어를 구분합니다. 예를 들어 helloworld.rs 보다는 hello_world.rs 를 사용합니다.

방금 만든 main.rs 파일을 열고, 목록 1-1의 코드를 입력하세요.

fn main() {
    println!("Hello, world!");
}

파일을 저장한 뒤 ~/projects/hello_world 디렉터리에서 터미널 창으로 돌아갑니다. Linux나 macOS에서는 다음 명령으로 파일을 컴파일하고 실행합니다.

$ rustc main.rs
$ ./main
Hello, world!

Windows에서는 ./main 대신 .\main 명령을 입력합니다.

> rustc main.rs
> .\main
Hello, world!

운영체제에 상관없이 터미널에 Hello, world! 문자열이 출력되어야 합니다. 이 출력이 보이지 않는다면 설치 절의 “문제 해결” 부분으로 돌아가 도움을 받는 방법을 확인하세요.

Hello, world! 가 출력되었다면 축하합니다! 여러분은 공식적으로 첫 Rust 프로그램을 작성한 것입니다. 이제 여러분도 Rust 프로그래머입니다. 환영합니다!

Rust 프로그램의 구조

이 “Hello, world!” 프로그램을 자세히 살펴봅시다. 먼저 첫 번째 조각은 다음과 같습니다.

fn main() {

}

이 줄들은 main 이라는 이름의 함수를 정의합니다. main 함수는 특별합니다. 모든 실행 가능한 Rust 프로그램에서 가장 먼저 실행되는 코드이기 때문입니다. 여기서 첫 줄은 매개변수가 없고 아무것도 반환하지 않는 main 함수를 선언합니다. 매개변수가 있다면 괄호(()) 안에 들어갑니다.

함수 본문은 {} 로 감싸여 있습니다. 러스트는 모든 함수 본문을 중괄호로 감싸도록 요구합니다. 여는 중괄호를 함수 선언과 같은 줄에 두고, 그 앞에 공백 하나를 두는 것이 좋은 스타일입니다.

main 함수 본문에는 다음 코드가 들어 있습니다.

#![allow(unused)]
fn main() {
println!("Hello, world!");
}

이 한 줄이 이 작은 프로그램의 모든 일을 합니다. 화면에 텍스트를 출력하는 것입니다. 여기에는 주목할 중요한 세 가지가 있습니다.

첫째, println! 은 Rust 매크로를 호출합니다. 만약 함수였다면 println (! 없음) 형태로 적었을 것입니다. Rust 매크로는 코드를 생성하는 코드를 작성하여 Rust 문법을 확장하는 방법이며, 이에 대해서는 20장 에서 더 자세히 다룹니다. 지금은 ! 가 붙으면 일반 함수가 아니라 매크로를 호출한다는 점, 그리고 매크로는 함수와 같은 규칙만 따르지는 않는다는 점만 알면 충분합니다.

둘째, "Hello, world!" 문자열이 보입니다. 이 문자열을 println! 에 인수로 전달하면 화면에 출력됩니다.

셋째, 줄 끝에 세미콜론(;)이 있습니다. 이것은 현재 식이 끝났고 다음 식이 시작될 준비가 되었음을 뜻합니다. Rust 코드의 대부분의 줄은 세미콜론으로 끝납니다.

컴파일과 실행

방금 새로 만든 프로그램을 실행했으니, 이 과정의 각 단계를 살펴봅시다.

Rust 프로그램을 실행하기 전에, rustc 명령에 소스 파일 이름을 넘겨 Rust 컴파일러로 먼저 컴파일해야 합니다.

$ rustc main.rs

C나 C++ 배경이 있다면 이것이 gcc 나 clang 과 비슷하다는 점을 알 수 있을 것입니다. 컴파일에 성공하면 Rust는 실행 가능한 바이너리를 출력합니다.

Linux, macOS, Windows PowerShell에서는 셸에서 ls 명령을 입력해 실행 파일을 볼 수 있습니다.

$ ls
main  main.rs

Linux와 macOS에서는 두 개의 파일이 보일 것입니다. Windows의 PowerShell에서는 CMD에서 보이는 것과 같은 세 개의 파일이 보입니다. Windows CMD에서는 다음을 입력합니다.

> dir /B %= the /B option says to only show the file names =%
main.exe
main.pdb
main.rs

여기에는 .rs 확장자를 가진 소스 코드 파일, 실행 파일(Windows에서는 main.exe, 그 외 플랫폼에서는 main), 그리고 Windows를 사용할 경우 .pdb 확장자를 가진 디버깅 정보 파일이 표시됩니다. 이제 main 또는 main.exe 파일을 다음과 같이 실행합니다.

$ ./main # or .\main on Windows

여러분의 main.rs 가 “Hello, world!” 프로그램이라면, 이 줄은 터미널에 Hello, world! 를 출력합니다.

Ruby, Python, JavaScript 같은 동적 언어에 더 익숙하다면, 프로그램을 컴파일하는 단계와 실행하는 단계를 따로 나누는 것이 낯설 수 있습니다. 러스트는 ahead-of-time compiled 언어입니다. 즉, 프로그램을 컴파일한 뒤 생성된 실행 파일을 다른 사람에게 전달하면, 그 사람은 Rust가 설치되어 있지 않아도 실행할 수 있습니다. 반면 .rb, .py, .js 파일을 누군가에게 주면, 그 사람은 각각 Ruby, Python, JavaScript 구현체를 설치하고 있어야 합니다. 대신 그런 언어에서는 프로그램을 컴파일하고 실행하는 데 명령 하나면 충분합니다. 언어 설계에는 언제나 절충이 따릅니다.

단순한 프로그램은 rustc 로 컴파일하는 것만으로도 충분하지만, 프로젝트가 커질수록 여러 옵션을 관리하고 코드를 쉽게 공유할 방법이 필요해집니다. 다음 절에서는 실제 현실의 Rust 프로그램을 작성할 때 큰 도움이 되는 Cargo 도구를 소개하겠습니다.

Hello, Cargo!

Hello, Cargo!

Cargo는 러스트의 빌드 시스템이자 패키지 관리자입니다. 대부분의 Rustacean은 Rust 프로젝트를 관리할 때 이 도구를 사용합니다. Cargo가 코드 빌드, 코드가 의존하는 라이브러리 다운로드, 그리고 그 라이브러리들의 빌드 같은 일을 많이 대신 처리해 주기 때문입니다. (코드에 필요한 라이브러리를 의존성(dependencies) 이라고 부릅니다.)

우리가 지금까지 작성한 것 같은 가장 단순한 Rust 프로그램은 의존성이 없습니다. “Hello, world!” 프로젝트를 Cargo로 만들었다면, Cargo의 기능 중 코드 빌드를 담당하는 부분만 사용했을 것입니다. 하지만 더 복잡한 Rust 프로그램을 작성하게 되면 의존성이 추가되기 시작하고, 프로젝트를 Cargo로 시작해 두면 그런 의존성을 훨씬 쉽게 추가할 수 있습니다.

대부분의 Rust 프로젝트가 Cargo를 사용하기 때문에, 이 책의 나머지 부분도 여러분이 Cargo를 사용한다고 가정합니다. Cargo는 “설치” 절에서 설명한 공식 설치 방법으로 Rust를 설치했다면 함께 설치됩니다. 다른 방식으로 Rust를 설치했다면, 터미널에서 다음 명령을 입력해 Cargo가 설치되어 있는지 확인하세요.

$ cargo --version

버전 번호가 보이면 Cargo가 있는 것입니다! command not found 같은 오류가 보이면, 자신이 사용한 설치 방식의 문서를 확인해 Cargo를 따로 설치하는 방법을 찾아보세요.

Cargo로 프로젝트 만들기

Cargo를 사용해 새 프로젝트를 만들고, 그것이 우리가 처음 만든 “Hello, world!” 프로젝트와 어떻게 다른지 살펴봅시다. 다시 projects 디렉터리(혹은 코드를 보관하기로 정한 위치)로 이동한 뒤, 어떤 운영체제에서든 다음을 실행하세요.

$ cargo new hello_cargo
$ cd hello_cargo

첫 번째 명령은 hello_cargo 라는 새 디렉터리와 프로젝트를 만듭니다. 프로젝트 이름을 hello_cargo 로 지었기 때문에 Cargo도 같은 이름의 디렉터리에 파일들을 생성합니다.

hello_cargo 디렉터리로 들어가 파일 목록을 살펴보세요. Cargo가 두 개의 파일과 하나의 디렉터리를 생성해 둔 것을 볼 수 있습니다. 즉 Cargo.toml 파일과, 그 안에 main.rs 파일이 들어 있는 src 디렉터리입니다.

또한 .gitignore 파일과 함께 새 Git 저장소도 초기화합니다. 이미 존재하는 Git 저장소 안에서 cargo new 를 실행하면 Git 관련 파일은 생성되지 않습니다. 이 동작을 바꾸고 싶다면 cargo new --vcs=git 를 사용할 수 있습니다.

원하는 텍스트 에디터로 Cargo.toml 을 열어 보세요. 목록 1-2와 비슷한 모습일 것입니다.

[package]
name = "hello_cargo"
version = "0.1.0"
edition = "2024"

[dependencies]

이 파일은 Cargo의 설정 형식인 TOML(Tom’s Obvious, Minimal Language) 형식으로 작성되어 있습니다.

첫 줄의 [package] 는 뒤따르는 항목들이 패키지 설정임을 나타내는 섹션 헤딩입니다. 앞으로 이 파일에 더 많은 정보를 추가하면서 다른 섹션도 늘어나게 됩니다.

다음 세 줄은 Cargo가 프로그램을 컴파일하는 데 필요한 설정, 즉 이름, 버전, 사용할 Rust 에디션을 지정합니다. edition 키는 부록 E에서 다룹니다.

마지막 줄인 [dependencies] 는 프로젝트의 의존성을 나열하는 섹션의 시작입니다. Rust에서는 코드 패키지를 crate 라고 부릅니다. 이 프로젝트에서는 다른 crate가 필요 없지만, 2장의 첫 번째 프로젝트에서는 필요하므로 그때 이 의존성 섹션을 사용하게 됩니다.

이제 src/main.rs 를 열어 봅시다.

Filename: src/main.rs

fn main() {
    println!("Hello, world!");
}

Cargo는 목록 1-1에서 우리가 직접 쓴 것과 똑같은 “Hello, world!” 프로그램을 자동으로 만들어 주었습니다! 지금까지 우리가 만든 프로젝트와 Cargo가 생성한 프로젝트의 차이는, Cargo는 코드를 src 디렉터리에 넣고 최상위 디렉터리에 Cargo.toml 설정 파일을 만든다는 점입니다.

Cargo는 소스 파일이 src 디렉터리 안에 있기를 기대합니다. 프로젝트 최상위 디렉터리는 README 파일, 라이선스 정보, 설정 파일, 그리고 코드와 직접 관련 없는 다른 것들을 두는 곳입니다. Cargo를 사용하면 프로젝트를 체계적으로 정리할 수 있습니다. 모든 것에는 자리가 있고, 모든 것이 제자리에 있게 됩니다.

“Hello, world!” 프로젝트처럼 Cargo를 사용하지 않고 시작한 프로젝트라도, 나중에 Cargo를 사용하는 프로젝트로 바꿀 수 있습니다. 프로젝트 코드를 src 디렉터리 안으로 옮기고 적절한 Cargo.toml 파일을 만들면 됩니다. 그 파일을 쉽게 만드는 방법 중 하나는 cargo init 을 실행하는 것입니다. 그러면 자동으로 생성해 줍니다.

Cargo 프로젝트 빌드하고 실행하기

이제 “Hello, world!” 프로그램을 Cargo로 빌드하고 실행할 때 무엇이 다른지 살펴봅시다! hello_cargo 디렉터리에서 다음 명령으로 프로젝트를 빌드하세요.

$ cargo build
   Compiling hello_cargo v0.1.0 (file:///projects/hello_cargo)
    Finished dev [unoptimized + debuginfo] target(s) in 2.85 secs

이 명령은 실행 파일을 현재 디렉터리가 아니라 target/debug/hello_cargo (Windows에서는 target\debug\hello_cargo.exe) 에 만듭니다. 기본 빌드는 디버그 빌드이기 때문에, Cargo는 바이너리를 debug 라는 디렉터리에 넣습니다. 실행 파일은 다음 명령으로 실행할 수 있습니다.

$ ./target/debug/hello_cargo # or .\target\debug\hello_cargo.exe on Windows
Hello, world!

모든 것이 잘 되었다면 터미널에 Hello, world! 가 출력됩니다. cargo build 를 처음 실행하면 Cargo는 최상위 디렉터리에 Cargo.lock 이라는 새 파일도 만듭니다. 이 파일은 프로젝트의 의존성 정확한 버전을 추적합니다. 이 프로젝트에는 의존성이 없기 때문에 내용이 많지 않습니다. 이 파일은 손으로 수정할 일이 없고, Cargo가 내용을 대신 관리해 줍니다.

방금은 cargo build 로 프로젝트를 빌드하고 ./target/debug/hello_cargo 로 실행했지만, cargo run 을 쓰면 코드 컴파일과 생성된 실행 파일 실행을 한 번에 할 수 있습니다.

$ cargo run
    Finished dev [unoptimized + debuginfo] target(s) in 0.0 secs
     Running `target/debug/hello_cargo`
Hello, world!

cargo run 은 먼저 cargo build 를 실행하고 다시 바이너리 전체 경로를 입력해야 하는 방식보다 훨씬 편리합니다. 그래서 대부분의 개발자는 cargo run 을 사용합니다.

이번에는 Cargo가 hello_cargo 를 컴파일하고 있다는 출력이 보이지 않았다는 점에 주목하세요. Cargo가 파일이 바뀌지 않았다고 판단했기 때문에 다시 빌드하지 않고 그냥 바이너리만 실행한 것입니다. 소스 코드를 수정했다면 실행 전에 프로젝트를 다시 빌드했을 것이고, 다음과 같은 출력이 보였을 것입니다.

$ cargo run
   Compiling hello_cargo v0.1.0 (file:///projects/hello_cargo)
    Finished dev [unoptimized + debuginfo] target(s) in 0.33 secs
     Running `target/debug/hello_cargo`
Hello, world!

Cargo는 cargo check 라는 명령도 제공합니다. 이 명령은 코드가 컴파일되는지만 빠르게 확인하고, 실행 파일은 만들지 않습니다.

$ cargo check
   Checking hello_cargo v0.1.0 (file:///projects/hello_cargo)
    Finished dev [unoptimized + debuginfo] target(s) in 0.32 secs

왜 실행 파일을 만들지 않으려 할까요? cargo check 는 실행 파일 생성 단계를 건너뛰기 때문에 cargo build 보다 훨씬 빠른 경우가 많습니다. 코드를 작성하면서 계속 중간 점검을 하고 있다면, cargo check 는 프로젝트가 아직 잘 컴파일되는지를 더 빨리 알려 줍니다. 그래서 많은 Rustacean이 프로그램을 작성하는 동안 주기적으로 cargo check 를 실행해 컴파일 상태를 확인하고, 실행 파일이 필요해졌을 때 cargo build 를 실행합니다.

지금까지 Cargo에 대해 배운 내용을 정리해 봅시다.

• cargo new 로 프로젝트를 만들 수 있습니다.
• cargo build 로 프로젝트를 빌드할 수 있습니다.
• cargo run 으로 빌드와 실행을 한 번에 할 수 있습니다.
• cargo check 로 바이너리를 만들지 않고 오류만 확인할 수 있습니다.
• Cargo는 빌드 결과를 코드와 같은 디렉터리가 아니라 target/debug 디렉터리에 저장합니다.

Cargo를 사용할 때의 또 다른 장점은, 어떤 운영체제에서 작업하든 명령이 같다는 것입니다. 따라서 이 시점부터는 Linux·macOS와 Windows를 따로 나눠 설명하지 않겠습니다.

릴리스용 빌드

프로젝트가 마침내 배포할 준비가 되었다면, cargo build --release 로 최적화를 켜고 컴파일할 수 있습니다. 이 명령은 실행 파일을 target/debug 대신 target/release 에 만듭니다. 최적화를 켜면 Rust 코드 실행 속도는 빨라지지만, 컴파일 시간은 더 길어집니다. 그래서 프로필이 두 가지 존재합니다. 자주 빠르게 다시 빌드하고 싶은 개발용 프로필 하나, 사용자에게 전달할 최종 프로그램을 가능한 빠르게 실행되도록 빌드하는 용도의 프로필 하나입니다. 코드 실행 시간을 벤치마크할 때는 반드시 cargo build --release 로 빌드하고 target/release 안의 실행 파일로 측정하세요.

Cargo의 관례 활용하기

단순한 프로젝트에서는 Cargo가 rustc 를 직접 쓰는 것에 비해 큰 차이를 주지 않을 수 있습니다. 하지만 프로그램이 복잡해질수록 Cargo의 진가가 드러납니다. 프로그램이 여러 파일로 커지거나 의존성이 필요해지면, 빌드 조율을 Cargo에 맡기는 편이 훨씬 쉽습니다.

hello_cargo 프로젝트는 단순하지만, 앞으로 러스트를 사용하는 동안 계속 쓰게 될 실제 도구의 상당 부분을 이미 사용하고 있습니다. 실제로 이미 존재하는 프로젝트에서 작업할 때도, 다음처럼 Git으로 코드를 받아오고 해당 프로젝트 디렉터리로 이동한 뒤 빌드하면 됩니다.

$ git clone example.org/someproject
$ cd someproject
$ cargo build

Cargo에 대해 더 알고 싶다면 공식 문서를 확인하세요.

정리

여러분은 이미 러스트 여정을 훌륭하게 시작했습니다! 이 장에서는 다음 내용을 배웠습니다.

• rustup 으로 Rust의 최신 안정 버전을 설치하는 방법
• 더 새로운 Rust 버전으로 업데이트하는 방법
• 로컬에 설치된 문서를 여는 방법
• rustc 를 직접 사용해 “Hello, world!” 프로그램을 작성하고 실행하는 방법
• Cargo의 관례를 사용해 새 프로젝트를 만들고 실행하는 방법

이제 좀 더 실질적인 프로그램을 만들어 보면서 Rust 코드를 읽고 쓰는 감각을 익히기 좋은 시점입니다. 그래서 2장에서는 숫자 맞히기 게임 프로그램을 만들어 봅니다. 만약 일반적인 프로그래밍 개념이 Rust에서 어떻게 동작하는지부터 배우고 싶다면 3장을 먼저 읽은 뒤 다시 2장으로 돌아오면 됩니다.

숫자 맞히기 게임 프로그래밍하기

직접 손을 움직여 보는 프로젝트를 함께 진행하면서 러스트를 시작해 봅시다! 이 장에서는 실제 프로그램 안에서 몇 가지 흔한 러스트 개념을 사용하는 방법을 보여 주며, 여러분을 러스트에 입문시킵니다. let, match, 메서드, 연관 함수, 외부 크레이트 등 여러 가지를 배우게 됩니다! 이어지는 장들에서는 이 아이디어들을 더 자세히 살펴볼 것입니다. 이 장에서는 우선 기초를 직접 연습해 보겠습니다.

우리는 초보자용 고전 프로그래밍 문제인 숫자 맞히기 게임을 구현할 것입니다. 동작 방식은 이렇습니다. 프로그램은 1부터 100 사이의 임의의 정수를 하나 생성합니다. 그런 다음 플레이어에게 추측값을 입력하라고 요청합니다. 추측값이 입력되면, 프로그램은 그 값이 너무 작은지 너무 큰지 알려 줍니다. 정답을 맞히면 게임은 축하 메시지를 출력하고 종료합니다.

새 프로젝트 준비하기

새 프로젝트를 만들려면 1장에서 만든 projects 디렉터리로 가서, 다음과 같이 Cargo를 사용해 새 프로젝트를 만드세요.

$ cargo new guessing_game
$ cd guessing_game

첫 번째 명령인 cargo new 는 프로젝트 이름(guessing_game)을 첫 번째 인수로 받습니다. 두 번째 명령은 새 프로젝트 디렉터리로 이동합니다.

생성된 Cargo.toml 파일을 살펴보세요.

파일명: Cargo.toml

[package]
name = "guessing_game"
version = "0.1.0"
edition = "2024"

[dependencies]

1장에서 보았듯이 cargo new 는 “Hello, world!” 프로그램도 함께 생성합니다. src/main.rs 파일도 확인해 봅시다.

파일명: src/main.rs

fn main() {
    println!("Hello, world!");
}

이제 cargo run 명령을 사용해 이 “Hello, world!” 프로그램을 컴파일하고 같은 단계에서 실행해 봅시다.

$ cargo run
   Compiling guessing_game v0.1.0 (file:///projects/guessing_game)
    Finished `dev` profile [unoptimized + debuginfo] target(s) in 0.08s
     Running `target/debug/guessing_game`
Hello, world!

run 명령은 이 게임에서처럼 프로젝트를 빠르게 반복 개발할 때 유용합니다. 매 반복마다 다음 단계로 넘어가기 전에 바로 테스트할 수 있기 때문입니다.

src/main.rs 파일을 다시 여세요. 앞으로 작성할 코드는 전부 이 파일 안에 넣게 됩니다.

추측값 처리하기

숫자 맞히기 게임 프로그램의 첫 번째 부분은 사용자 입력을 요청하고, 그 입력을 처리하며, 입력이 우리가 기대한 형식인지 확인하는 것입니다. 우선은 플레이어가 추측값을 입력할 수 있게만 해 봅시다. 목록 2-1의 코드를 src/main.rs 에 입력하세요.

use std::io;

fn main() {
    println!("Guess the number!");

    println!("Please input your guess.");

    let mut guess = String::new();

    io::stdin()
        .read_line(&mut guess)
        .expect("Failed to read line");

    println!("You guessed: {guess}");
}

이 코드에는 많은 정보가 들어 있으니 한 줄씩 살펴봅시다. 사용자 입력을 받고 그 결과를 출력하려면, io 입출력 라이브러리를 스코프로 가져와야 합니다. io 라이브러리는 std 라고 부르는 표준 라이브러리에서 제공합니다.

use std::io;

fn main() {
    println!("Guess the number!");

    println!("Please input your guess.");

    let mut guess = String::new();

    io::stdin()
        .read_line(&mut guess)
        .expect("Failed to read line");

    println!("You guessed: {guess}");
}

기본적으로 러스트는 표준 라이브러리 안의 몇몇 항목을 모든 프로그램의 스코프로 가져옵니다. 이 집합을 prelude 라고 하며, 그 전체 내용은 표준 라이브러리 문서에서 볼 수 있습니다.

사용하고 싶은 타입이 prelude 안에 없다면 use 문으로 그 타입을 명시적으로 스코프로 가져와야 합니다. std::io 라이브러리를 사용하면 사용자 입력을 받을 수 있는 기능을 포함해 여러 유용한 기능을 쓸 수 있습니다.

1장에서 본 것처럼 main 함수는 프로그램의 진입점입니다.

use std::io;

fn main() {
    println!("Guess the number!");

    println!("Please input your guess.");

    let mut guess = String::new();

    io::stdin()
        .read_line(&mut guess)
        .expect("Failed to read line");

    println!("You guessed: {guess}");
}

fn 문법은 새 함수를 선언하고, 괄호 () 는 매개변수가 없음을 뜻하며, 중괄호 { 는 함수 본문의 시작을 나타냅니다.

1장에서 배운 것처럼 println! 은 문자열을 화면에 출력하는 매크로입니다.

use std::io;

fn main() {
    println!("Guess the number!");

    println!("Please input your guess.");

    let mut guess = String::new();

    io::stdin()
        .read_line(&mut guess)
        .expect("Failed to read line");

    println!("You guessed: {guess}");
}

이 코드는 게임 이름을 출력하고 사용자에게 입력을 요청하는 프롬프트를 보여 줍니다.

변수로 값 저장하기

다음으로 사용자 입력을 저장할 변수 를 하나 만듭니다.

use std::io;

fn main() {
    println!("Guess the number!");

    println!("Please input your guess.");

    let mut guess = String::new();

    io::stdin()
        .read_line(&mut guess)
        .expect("Failed to read line");

    println!("You guessed: {guess}");
}

이제 프로그램이 꽤 흥미로워지기 시작합니다! 이 짧은 한 줄 안에도 많은 일이 일어납니다. 우리는 let 문을 사용해 변수를 만듭니다. 예를 들면 다음과 같습니다.

let apples = 5;

이 줄은 apples 라는 새 변수를 만들고 값 5 에 바인딩합니다. 러스트에서 변수는 기본적으로 불변입니다. 즉 한 번 값을 넣으면 그 값은 바뀌지 않습니다. 이 개념은 3장의 “변수와 가변성” 절에서 자세히 다룹니다. 변수를 가변으로 만들려면 변수 이름 앞에 mut 를 붙입니다.

let apples = 5; // 불변
let mut bananas = 5; // 가변

숫자 맞히기 게임 프로그램으로 돌아오면, 이제 let mut guess 가 guess 라는 이름의 가변 변수를 도입한다는 것을 알 수 있습니다. 등호(=)는 지금 어떤 값을 변수에 바인딩하겠다는 뜻입니다. 등호 오른쪽에 있는 값은 String::new 호출 결과이며, 이 함수는 새로운 String 인스턴스를 반환합니다. String 은 표준 라이브러리가 제공하는 문자열 타입으로, 크기를 늘릴 수 있는 UTF-8 인코딩 텍스트입니다.

::new 에서 :: 문법은 new 가 String 타입의 연관 함수라는 뜻입니다. 연관 함수(associated function) 는 어떤 타입에 구현된 함수입니다. 여기서는 String 타입에 구현된 함수이지요. 이 new 함수는 새로운 빈 문자열을 만듭니다. new 는 어떤 종류의 새 값을 만드는 함수의 이름으로 매우 흔하게 쓰이기 때문에 많은 타입에서 볼 수 있습니다.

정리하면, let mut guess = String::new(); 라는 줄은 현재 새롭고 빈 String 인스턴스에 바인딩된 가변 변수를 만든 것입니다. 후우!

사용자 입력 받기

프로그램 첫 줄에서 use std::io; 로 표준 라이브러리의 입출력 기능을 포함시켰다는 것을 떠올려 봅시다. 이제 io 모듈의 stdin 함수를 호출해 사용자 입력을 처리해 보겠습니다.

use std::io;

fn main() {
    println!("Guess the number!");

    println!("Please input your guess.");

    let mut guess = String::new();

    io::stdin()
        .read_line(&mut guess)
        .expect("Failed to read line");

    println!("You guessed: {guess}");
}

만약 프로그램 처음에 use std::io; 로 io 모듈을 가져오지 않았다면, 이 함수를 std::io::stdin 처럼 전체 경로로 써서 여전히 사용할 수 있습니다. stdin 함수는 std::io::Stdin 인스턴스를 반환하는데, 이 타입은 터미널의 표준 입력을 가리키는 핸들을 나타냅니다.

다음 줄의 .read_line(&mut guess) 는 표준 입력 핸들에서 read_line 메서드를 호출해 사용자 입력을 받습니다. 그리고 read_line 에 &mut guess 를 인수로 넘겨, 사용자 입력을 어떤 문자열에 저장할지 알려 줍니다. read_line 의 전체 역할은 사용자가 표준 입력에 입력한 내용을 우리가 넘긴 문자열의 끝에 덧붙이는 것(기존 내용을 덮어쓰지 않음)이므로, 그 문자열을 인수로 전달합니다. 또한 메서드가 문자열 내용을 바꿔야 하므로 문자열 인수는 가변이어야 합니다.

& 는 이 인수가 참조(reference) 임을 나타냅니다. 참조는 데이터를 메모리에 여러 번 복사하지 않고도 코드의 여러 부분이 하나의 데이터를 접근하게 해 주는 방법입니다. 참조는 복잡한 기능이지만, 러스트의 큰 장점 중 하나는 참조를 안전하고 쉽게 사용할 수 있다는 점입니다. 이 프로그램을 완성하는 데 지금 당장 그 세부를 많이 알 필요는 없습니다. 지금은 변수와 마찬가지로 참조도 기본적으로 불변이라는 점만 알면 충분합니다. 그래서 가변으로 만들기 위해 &guess 가 아니라 &mut guess 라고 써야 합니다. (4장에서 참조를 더 자세히 설명합니다.)

Result 타입으로 발생 가능한 실패 처리하기

아직도 우리는 같은 코드 줄을 다루고 있습니다. 이제 세 번째 줄의 텍스트를 설명하려는 것이지만, 이 역시 하나의 논리적 코드 줄의 일부라는 점에 주목하세요. 다음 부분은 다음 메서드입니다.

use std::io;

fn main() {
    println!("Guess the number!");

    println!("Please input your guess.");

    let mut guess = String::new();

    io::stdin()
        .read_line(&mut guess)
        .expect("Failed to read line");

    println!("You guessed: {guess}");
}

이 코드는 다음처럼 한 줄로도 쓸 수 있었습니다.

io::stdin().read_line(&mut guess).expect("Failed to read line");

하지만 이렇게 한 줄로 길게 쓰면 읽기 어렵기 때문에 나누어 쓰는 편이 좋습니다. .method_name() 문법으로 메서드를 호출할 때는 줄바꿈과 공백을 적절히 넣어 긴 줄을 나누는 것이 보통 현명합니다. 이제 이 줄이 실제로 무엇을 하는지 살펴봅시다.

앞에서 설명했듯 read_line 은 사용자가 입력한 내용을 우리가 전달한 문자열에 넣는 동시에 Result 값을 반환합니다. Result 는 열거형 enumeration, 흔히 enum 이라고 부르는 타입입니다. enum은 여러 가능한 상태 중 하나가 될 수 있는 타입입니다. 우리는 각 가능한 상태를 variant 라고 부릅니다.

6장에서 enum을 더 자세히 다루겠습니다. 이런 Result 타입의 목적은 에러 처리 정보를 표현하는 것입니다.

Result 의 variant는 Ok 와 Err 입니다. Ok variant는 작업이 성공했음을 뜻하고 성공적으로 만들어진 값을 담고 있습니다. Err variant는 작업이 실패했음을 뜻하고, 어떻게 혹은 왜 실패했는지에 대한 정보를 담습니다.

다른 모든 타입의 값처럼 Result 타입의 값에도 메서드가 정의되어 있습니다. Result 인스턴스는 expect 메서드를 가집니다. 이 Result 인스턴스가 Err 값이라면, expect 는 프로그램을 중단시키고 expect 에 전달한 메시지를 출력합니다. read_line 메서드가 Err 를 반환한다면, 그것은 대개 기저 운영체제에서 올라온 오류 때문일 것입니다. 반대로 이 Result 인스턴스가 Ok 값이라면, expect 는 Ok 가 들고 있는 반환값만 꺼내어 돌려줍니다. 이 경우 그 값은 사용자 입력의 바이트 수입니다.

expect 를 호출하지 않으면 프로그램은 컴파일되지만, 경고를 받게 됩니다.

$ cargo build
   Compiling guessing_game v0.1.0 (file:///projects/guessing_game)
warning: unused `Result` that must be used
  --> src/main.rs:10:5
   |
10 |     io::stdin().read_line(&mut guess);
   |     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
   |
   = note: this `Result` may be an `Err` variant, which should be handled
   = note: `#[warn(unused_must_use)]` on by default
help: use `let _ = ...` to ignore the resulting value
   |
10 |     let _ = io::stdin().read_line(&mut guess);
   |     +++++++

warning: `guessing_game` (bin "guessing_game") generated 1 warning
    Finished `dev` profile [unoptimized + debuginfo] target(s) in 0.59s

러스트는 read_line 이 반환한 Result 값을 사용하지 않았다고 경고하며, 그 말은 프로그램이 발생 가능한 오류를 처리하지 않았다는 뜻입니다.

경고를 없애는 올바른 방법은 실제로 에러 처리 코드를 작성하는 것이지만, 여기서는 문제가 생기면 그냥 프로그램을 중단시키고 싶을 뿐이므로 expect 를 사용할 수 있습니다. 에러로부터 복구하는 방법은 9장에서 배우게 됩니다.

println! 플레이스홀더로 값 출력하기

지금까지의 코드에서, 닫는 중괄호를 빼면 이제 설명하지 않은 줄은 하나만 남았습니다.

use std::io;

fn main() {
    println!("Guess the number!");

    println!("Please input your guess.");

    let mut guess = String::new();

    io::stdin()
        .read_line(&mut guess)
        .expect("Failed to read line");

    println!("You guessed: {guess}");
}

이 줄은 이제 사용자 입력을 담고 있는 문자열을 출력합니다. {} 라는 중괄호 쌍은 플레이스홀더입니다. {} 를 값을 제자리에 고정해 두는 작은 게 집게발이라고 생각해도 좋습니다. 변수 값을 출력할 때는 중괄호 안에 변수 이름을 넣을 수 있습니다. 식의 계산 결과를 출력할 때는 포맷 문자열 안에 빈 중괄호를 두고, 그 뒤에 각 빈 플레이스홀더에 출력할 식을 쉼표로 구분해 같은 순서로 나열합니다. 변수와 식 결과를 한 번의 println! 호출로 출력하면 다음처럼 됩니다.

#![allow(unused)]
fn main() {
let x = 5;
let y = 10;

println!("x = {x} and y + 2 = {}", y + 2);
}

이 코드는 x = 5 and y + 2 = 12 를 출력합니다.

첫 번째 부분 테스트하기

숫자 맞히기 게임의 첫 번째 부분을 테스트해 봅시다. cargo run 으로 실행합니다.

$ cargo run
   Compiling guessing_game v0.1.0 (file:///projects/guessing_game)
    Finished `dev` profile [unoptimized + debuginfo] target(s) in 6.44s
     Running `target/debug/guessing_game`
Guess the number!
Please input your guess.
6
You guessed: 6

이 시점에서 게임의 첫 번째 부분은 끝났습니다. 키보드에서 입력을 받고, 그 값을 출력하고 있습니다.

비밀 숫자 생성하기

다음으로는 사용자가 맞혀야 할 비밀 숫자를 생성해야 합니다. 게임을 여러 번 플레이해도 재미있으려면 비밀 숫자는 매번 달라야 합니다. 또한 게임이 너무 어렵지 않도록 1부터 100 사이의 임의의 수를 사용하겠습니다. 러스트는 아직 표준 라이브러리에 난수 생성 기능을 포함하고 있지 않습니다. 하지만 러스트 팀은 그 기능을 제공하는 rand crate를 제공합니다.

크레이트로 기능 늘리기

crate는 러스트 소스 코드 파일들의 모음이라는 점을 기억하세요. 지금까지 우리가 만들고 있던 프로젝트는 실행 가능한 바이너리 크레이트(binary crate) 입니다. 반면 rand crate는 라이브러리 크레이트(library crate) 로, 다른 프로그램에서 사용하도록 만든 코드를 담고 있으며 그 자체로 실행되지는 않습니다.

외부 크레이트를 다룰 때야말로 Cargo의 진가가 드러납니다. rand 를 사용하는 코드를 쓰기 전에, Cargo.toml 파일을 수정해 rand crate를 의존성으로 추가해야 합니다. 지금 파일을 열고, Cargo가 만들어 둔 [dependencies] 섹션 헤더 아래 맨 아래에 다음 줄을 추가하세요. 여기 적힌 것처럼 rand 와 이 버전 번호를 정확히 사용해야 합니다. 그렇지 않으면 이 튜토리얼의 코드 예제가 동작하지 않을 수 있습니다.

파일명: Cargo.toml

[dependencies]
rand = "0.8.5"

Cargo.toml 파일에서 어떤 헤더 뒤에 나오는 내용은 다음 섹션이 시작될 때까지 모두 그 섹션에 속합니다. [dependencies] 에서는 프로젝트가 어떤 외부 크레이트에 의존하는지, 그리고 그 크레이트의 어떤 버전을 요구하는지를 Cargo에게 알려 줍니다. 여기서는 rand crate를 시맨틱 버전 지정자 0.8.5 로 지정합니다. Cargo는 시맨틱 버저닝(줄여서 SemVer 라고도 부름)을 이해하는데, 이것은 버전 번호를 표기하는 표준입니다. 0.8.5 라는 지정자는 사실 ^0.8.5 의 축약형이며, 이는 0.8.5 이상이면서 0.9.0 미만인 모든 버전을 뜻합니다.

Cargo는 이런 버전들이 0.8.5와 공개 API 호환성을 가진다고 간주합니다. 이 지정은 이 장의 코드와 여전히 컴파일되는 최신 패치 릴리스를 받게 해 줍니다. 반면 0.9.0 이상 버전은 아래 예제와 같은 API를 유지한다고 보장되지 않습니다.

이제 코드는 바꾸지 말고, 목록 2-2처럼 프로젝트를 빌드해 봅시다.

$ cargo build
  Updating crates.io index
   Locking 15 packages to latest Rust 1.85.0 compatible versions
    Adding rand v0.8.5 (available: v0.9.0)
 Compiling proc-macro2 v1.0.93
 Compiling unicode-ident v1.0.17
 Compiling libc v0.2.170
 Compiling cfg-if v1.0.0
 Compiling byteorder v1.5.0
 Compiling getrandom v0.2.15
 Compiling rand_core v0.6.4
 Compiling quote v1.0.38
 Compiling syn v2.0.98
 Compiling zerocopy-derive v0.7.35
 Compiling zerocopy v0.7.35
 Compiling ppv-lite86 v0.2.20
 Compiling rand_chacha v0.3.1
 Compiling rand v0.8.5
 Compiling guessing_game v0.1.0 (file:///projects/guessing_game)
  Finished `dev` profile [unoptimized + debuginfo] target(s) in 2.48s

여러분의 화면에는 다른 버전 번호가 보일 수도 있습니다(하지만 SemVer 덕분에 모두 이 코드와 호환됩니다). 또 운영체제에 따라 줄 구성이 조금 다를 수 있고, 줄 순서도 달라질 수 있습니다.

외부 의존성을 포함하면 Cargo는 그 의존성이 필요로 하는 것들의 최신 버전을 registry 에서 가져옵니다. registry는 Crates.io의 데이터 사본입니다. Crates.io는 러스트 생태계 사람들이 자신의 오픈 소스 러스트 프로젝트를 올려 다른 사람이 사용할 수 있게 하는 곳입니다.

registry를 갱신한 뒤 Cargo는 [dependencies] 섹션을 검사하고 아직 다운로드되지 않은 크레이트를 내려받습니다. 여기서는 우리가 직접 명시한 의존성은 rand 하나뿐이지만, Cargo는 rand 가 동작하는 데 필요한 다른 크레이트도 함께 가져옵니다. 크레이트를 다운로드한 뒤 러스트는 그것들을 컴파일하고, 그런 다음 의존성을 사용할 수 있는 상태로 프로젝트 자체를 컴파일합니다.

아무 것도 바꾸지 않은 상태에서 곧바로 cargo build 를 다시 실행하면, Finished 줄 외에는 아무 출력도 보이지 않을 것입니다. Cargo는 의존성을 이미 다운로드하고 컴파일했으며, Cargo.toml 에서 그 의존성과 관련한 내용이 바뀌지 않았다는 사실을 알고 있습니다. 또한 여러분의 코드도 바뀌지 않았다는 것을 알기 때문에 그것도 다시 컴파일하지 않습니다. 할 일이 없으니 그냥 종료하는 것입니다.

반대로 src/main.rs 파일을 열어 사소한 변경을 하고 저장한 다음 다시 빌드하면, 다음처럼 두 줄 정도만 보게 됩니다.

$ cargo build
   Compiling guessing_game v0.1.0 (file:///projects/guessing_game)
    Finished `dev` profile [unoptimized + debuginfo] target(s) in 0.13s

이 줄들은 Cargo가 src/main.rs 에 대한 아주 작은 변경만 반영해 빌드를 갱신했다는 것을 보여 줍니다. 의존성은 바뀌지 않았으므로 Cargo는 이미 내려받고 컴파일해 둔 결과를 그대로 재사용할 수 있다는 것을 압니다.

재현 가능한 빌드 보장하기

Cargo에는 여러분이나 다른 사람이 코드를 빌드할 때마다 같은 결과물을 다시 만들 수 있도록 보장하는 메커니즘이 있습니다. Cargo는 여러분이 달리 지시하지 않는 한, 현재 지정된 의존성 버전만 사용합니다. 예를 들어 다음 주에 rand crate의 0.8.6 버전이 나왔다고 해 봅시다. 그 버전에는 중요한 버그 수정이 들어 있지만, 동시에 여러분의 코드를 깨뜨리는 회귀도 포함되어 있다고 합시다. 이런 상황을 다루기 위해 러스트는 여러분이 처음 cargo build 를 실행할 때 Cargo.lock 파일을 생성합니다. 그래서 이제 guessing_game 디렉터리 안에 그 파일이 있게 됩니다.

프로젝트를 처음 빌드할 때 Cargo는 조건에 맞는 의존성 버전을 모두 계산해 Cargo.lock 파일에 기록합니다. 이후에 프로젝트를 빌드하면 Cargo는 Cargo.lock 파일이 존재한다는 것을 보고, 버전을 다시 계산하는 대신 그 안에 적힌 버전을 사용합니다. 이렇게 해서 자동으로 재현 가능한 빌드를 얻게 됩니다. 다시 말해 명시적으로 업그레이드하지 않는 한, 여러분의 프로젝트는 Cargo.lock 파일 덕분에 0.8.5에 그대로 머무릅니다. Cargo.lock 파일은 재현 가능한 빌드에 중요하기 때문에, 대개 프로젝트의 다른 코드와 함께 버전 관리에 포함됩니다.

새 버전을 사용하기 위해 크레이트 업데이트하기

실제로 크레이트를 업데이트하고 싶을 때를 위해 Cargo는 update 명령을 제공합니다. 이 명령은 Cargo.lock 파일을 무시하고, Cargo.toml 의 지정 조건을 만족하는 최신 버전을 다시 계산합니다. 그리고 그 결과를 Cargo.lock 파일에 기록합니다. 기본적으로 Cargo는 0.8.5보다 크고 0.9.0보다 작은 버전만 찾습니다. 만약 rand crate가 0.8.6과 0.999.0이라는 두 개의 새 버전을 릴리스했다면, cargo update 를 실행했을 때 다음과 같은 출력을 보게 됩니다.

$ cargo update
    Updating crates.io index
     Locking 1 package to latest Rust 1.85.0 compatible version
    Updating rand v0.8.5 -> v0.8.6 (available: v0.999.0)

Cargo는 0.999.0 릴리스를 무시합니다. 이 시점에서는 여러분의 Cargo.lock 파일도 바뀌어, 현재 사용 중인 rand crate 버전이 0.8.6이라는 내용이 기록될 것입니다. 만약 rand 0.999.0이나 0.999.x 계열을 쓰고 싶다면, Cargo.toml 파일을 다음과 같이 바꿔야 합니다(하지만 아래 예제는 rand 0.8을 전제로 하므로 실제로는 바꾸지 마세요).

[dependencies]
rand = "0.999.0"

그다음 cargo build 를 실행하면 Cargo는 사용 가능한 크레이트 registry를 갱신하고, 새로 지정한 버전에 따라 rand 요구 사항을 다시 계산합니다.

Cargo와 그 생태계에 관해서는 할 말이 훨씬 더 많고, 14장에서 다시 다룰 것입니다. 하지만 지금은 이 정도면 충분합니다. Cargo 덕분에 라이브러리 재사용이 매우 쉬워지므로, Rustacean은 여러 패키지를 조합해 더 작은 프로젝트들을 만들어 낼 수 있습니다.

임의의 숫자 생성하기

이제 rand 를 사용해 맞혀야 할 숫자를 생성해 봅시다. 다음 단계는 목록 2-3처럼 src/main.rs 를 수정하는 것입니다.

use std::io;

use rand::Rng;

fn main() {
    println!("Guess the number!");

    let secret_number = rand::thread_rng().gen_range(1..=100);

    println!("The secret number is: {secret_number}");

    println!("Please input your guess.");

    let mut guess = String::new();

    io::stdin()
        .read_line(&mut guess)
        .expect("Failed to read line");

    println!("You guessed: {guess}");
}

먼저 use rand::Rng; 줄을 추가합니다. Rng 트레이트는 난수 생성기가 구현하는 메서드를 정의하며, 우리가 그 메서드를 사용하려면 이 트레이트가 스코프에 있어야 합니다. 트레이트는 10장에서 자세히 다룹니다.

다음으로 중간에 두 줄을 더 추가합니다. 첫 번째 줄에서는 rand::thread_rng 함수를 호출해 우리가 사용할 특정 난수 생성기를 가져옵니다. 현재 실행 중인 스레드에 지역적인 난수 생성기이며, 운영체제가 시드를 제공합니다. 그런 다음 그 난수 생성기에 대해 gen_range 메서드를 호출합니다. 이 메서드는 앞에서 use rand::Rng; 문으로 스코프에 가져온 Rng 트레이트에 정의되어 있습니다. gen_range 메서드는 범위 식을 인수로 받아, 그 범위 안의 임의의 숫자를 생성합니다. 여기서 사용하는 범위 식은 start..=end 형태이며, 하한과 상한을 모두 포함합니다. 따라서 1부터 100 사이 숫자를 요청하려면 1..=100 을 써야 합니다.

두 번째 새 줄은 비밀 숫자를 출력합니다. 프로그램을 개발하는 동안 테스트하기엔 유용하지만, 최종 버전에서는 삭제할 것입니다. 프로그램이 시작하자마자 정답을 출력해 버리면 게임이라고 하기 어렵겠지요!

프로그램을 몇 번 실행해 보세요.

$ cargo run
   Compiling guessing_game v0.1.0 (file:///projects/guessing_game)
    Finished `dev` profile [unoptimized + debuginfo] target(s) in 0.02s
     Running `target/debug/guessing_game`
Guess the number!
The secret number is: 7
Please input your guess.
4
You guessed: 4

$ cargo run
    Finished `dev` profile [unoptimized + debuginfo] target(s) in 0.02s
     Running `target/debug/guessing_game`
Guess the number!
The secret number is: 83
Please input your guess.
5
You guessed: 5

매번 다른 임의의 숫자가 생성될 것이고, 모두 1과 100 사이 숫자여야 합니다. 아주 좋습니다!

추측값을 비밀 숫자와 비교하기

이제 사용자 입력과 임의의 숫자가 있으니 둘을 비교할 수 있습니다. 그 단계는 목록 2-4에 나와 있습니다. 참고로 이 코드는 아직은 컴파일되지 않으며, 곧 그 이유를 설명하겠습니다.

use std::cmp::Ordering;
use std::io;

use rand::Rng;

fn main() {
    // --snip--
    println!("Guess the number!");

    let secret_number = rand::thread_rng().gen_range(1..=100);

    println!("The secret number is: {secret_number}");

    println!("Please input your guess.");

    let mut guess = String::new();

    io::stdin()
        .read_line(&mut guess)
        .expect("Failed to read line");

    println!("You guessed: {guess}");

    match guess.cmp(&secret_number) {
        Ordering::Less => println!("Too small!"),
        Ordering::Greater => println!("Too big!"),
        Ordering::Equal => println!("You win!"),
    }
}

먼저 표준 라이브러리에서 std::cmp::Ordering 이라는 타입을 스코프로 가져오는 use 문을 하나 더 추가합니다. Ordering 타입 역시 enum이며, Less, Greater, Equal variant를 가집니다. 이 셋은 두 값을 비교했을 때 가능한 세 가지 결과입니다.

그다음 아래쪽에 Ordering 타입을 사용하는 다섯 줄을 추가합니다. cmp 메서드는 두 값을 비교하며, 비교 가능한 어떤 것에도 호출할 수 있습니다. 비교 대상에 대한 참조를 인수로 받는데, 여기서는 guess 와 secret_number 를 비교합니다. 그리고 use 문으로 스코프에 가져온 Ordering enum의 variant 중 하나를 반환합니다. 우리는 match 식을 사용해, guess 와 secret_number 를 cmp 로 비교한 결과 어떤 Ordering variant가 반환되었는지에 따라 다음에 무엇을 할지 결정합니다.

match 식은 여러 arm 으로 이루어집니다. 각 arm은 맞춰 볼 패턴 과, 그 값이 그 패턴에 맞을 때 실행할 코드로 구성됩니다. 러스트는 match 에 주어진 값을 가져와 각 arm의 패턴과 차례대로 비교합니다. 패턴과 match 구문은 아주 강력한 러스트 기능입니다. 코드가 마주칠 수 있는 다양한 상황을 표현할 수 있고, 그 모든 상황을 처리하도록 보장해 주기 때문입니다. 이 기능은 각각 6장과 19장에서 자세히 다룹니다.

여기서 사용한 match 식을 예로 들어봅시다. 사용자가 50을 추측했고, 이번에 무작위로 생성된 비밀 숫자가 38이라고 해 봅시다.

코드가 50과 38을 비교하면, 50이 38보다 크기 때문에 cmp 메서드는 Ordering::Greater 를 반환합니다. match 식은 Ordering::Greater 값을 받고, 각 arm의 패턴을 검사하기 시작합니다. 첫 번째 arm의 패턴인 Ordering::Less 를 보면 Ordering::Greater 와 맞지 않기 때문에 그 arm의 코드는 무시하고 다음 arm으로 이동합니다. 다음 arm의 패턴은 Ordering::Greater 이고, 이것은 Ordering::Greater 와 정확히 일치합니다! 따라서 이 arm에 연결된 코드가 실행되어 화면에 Too big! 를 출력합니다. match 식은 첫 번째로 성공한 매치 이후에 끝나므로, 이 경우 마지막 arm은 검사하지 않습니다.

하지만 목록 2-4의 코드는 아직 컴파일되지 않습니다. 실제로 실행해 봅시다.

$ cargo build
   Compiling libc v0.2.86
   Compiling getrandom v0.2.2
   Compiling cfg-if v1.0.0
   Compiling ppv-lite86 v0.2.10
   Compiling rand_core v0.6.2
   Compiling rand_chacha v0.3.0
   Compiling rand v0.8.5
   Compiling guessing_game v0.1.0 (file:///projects/guessing_game)
error[E0308]: mismatched types
  --> src/main.rs:23:21
   |
23 |     match guess.cmp(&secret_number) {
   |                 --- ^^^^^^^^^^^^^^ expected `&String`, found `&{integer}`
   |                 |
   |                 arguments to this method are incorrect
   |
   = note: expected reference `&String`
              found reference `&{integer}`
note: method defined here
  --> /rustc/1159e78c4747b02ef996e55082b704c09b970588/library/core/src/cmp.rs:979:8

For more information about this error, try `rustc --explain E0308`.
error: could not compile `guessing_game` (bin "guessing_game") due to 1 previous error

오류의 핵심은 타입이 맞지 않는다(mismatched types) 는 것입니다. 러스트는 강력한 정적 타입 시스템을 가집니다. 하지만 타입 추론도 지원합니다. 예를 들어 우리가 let mut guess = String::new() 라고 썼을 때, 러스트는 guess 가 String 이어야 한다는 것을 추론했고 타입을 직접 적으라고 요구하지 않았습니다. 반면 secret_number 는 숫자 타입입니다. 1부터 100 사이 값을 가질 수 있는 러스트의 숫자 타입은 여럿 있습니다. 32비트 정수 i32, 부호 없는 32비트 정수 u32, 64비트 정수 i64 등입니다. 별도의 정보가 없으면 러스트는 기본적으로 i32 를 사용하며, 다른 곳의 타입 정보가 영향을 주지 않는 한 secret_number 의 타입도 i32 입니다. 오류가 나는 이유는 러스트가 문자열과 숫자 타입을 서로 비교할 수 없기 때문입니다.

결국 우리가 원하는 것은 프로그램이 입력으로 읽어들인 String 을 숫자 타입으로 바꾸어, 그 값을 비밀 숫자와 수치적으로 비교하는 것입니다. 이를 위해 main 함수 본문에 다음 줄을 추가합니다.

파일명: src/main.rs

use std::cmp::Ordering;
use std::io;

use rand::Rng;

fn main() {
    println!("Guess the number!");

    let secret_number = rand::thread_rng().gen_range(1..=100);

    println!("The secret number is: {secret_number}");

    println!("Please input your guess.");

    // --snip--

    let mut guess = String::new();

    io::stdin()
        .read_line(&mut guess)
        .expect("Failed to read line");

    let guess: u32 = guess.trim().parse().expect("Please type a number!");

    println!("You guessed: {guess}");

    match guess.cmp(&secret_number) {
        Ordering::Less => println!("Too small!"),
        Ordering::Greater => println!("Too big!"),
        Ordering::Equal => println!("You win!"),
    }
}

그 줄은 다음과 같습니다.

let guess: u32 = guess.trim().parse().expect("Please type a number!");

여기서는 guess 라는 새 변수를 만듭니다. 잠깐, 프로그램에 이미 guess 라는 변수가 있지 않았나요? 그렇습니다. 하지만 다행히 러스트는 이전 guess 값을 새로운 값으로 가릴 수 있게 해 줍니다. 이것을 shadowing 이라고 하며, 예를 들어 guess_str 와 guess 처럼 서로 다른 이름의 두 변수를 억지로 만들지 않고도 guess 라는 이름을 재사용할 수 있게 합니다. 이것은 3장에서 더 자세히 다루겠지만, 지금은 한 타입의 값을 다른 타입으로 바꾸고 싶을 때 자주 쓰는 기능이라는 점만 기억하면 됩니다.

이 새 변수는 guess.trim().parse() 식의 결과에 바인딩됩니다. 여기서 식 안의 guess 는 문자열 입력을 담고 있던 원래의 guess 변수를 가리킵니다. String 인스턴스의 trim 메서드는 앞뒤 공백을 제거합니다. 문자열을 u32 로 변환하기 전에 이 작업이 꼭 필요합니다. u32 는 숫자 데이터만 담을 수 있기 때문입니다. 사용자는 read_line 을 만족시키기 위해 추측값을 입력한 뒤 enter 를 눌러야 하고, 그러면 문자열 끝에 줄바꿈 문자가 추가됩니다. 예를 들어 사용자가 5 를 입력하고 enter 를 누르면, guess 는 5\n 처럼 보입니다. \n 은 줄바꿈을 뜻합니다. (Windows에서는 enter 를 누르면 캐리지 리턴과 줄바꿈 \r\n 이 함께 들어갑니다.) trim 메서드는 이런 \n 또는 \r\n 을 제거해서 순수하게 5 만 남깁니다.

문자열의 parse 메서드는 문자열을 다른 타입으로 변환합니다. 여기서는 문자열을 숫자로 바꾸기 위해 사용합니다. 원하는 숫자 타입을 러스트에게 정확히 알려 주기 위해 let guess: u32 라고 씁니다. guess 뒤의 콜론(:)은 변수의 타입을 명시하겠다는 뜻입니다. 러스트에는 여러 기본 숫자 타입이 있는데, 여기 나오는 u32 는 부호 없는 32비트 정수입니다. 작은 양의 정수를 다룰 때 좋은 기본 선택입니다. 다른 숫자 타입은 3장에서 배웁니다.

또한 이 예제 프로그램에서는 u32 타입 주석과 secret_number 와의 비교가 함께 있기 때문에, 러스트는 secret_number 역시 u32 여야 한다고 추론합니다. 이렇게 하면 비교가 같은 타입 두 값 사이에서 이루어집니다.

parse 메서드는 논리적으로 숫자로 바꿀 수 있는 문자에 대해서만 동작하므로 쉽게 오류가 날 수 있습니다. 예를 들어 문자열이 A👍% 라면 이를 숫자로 바꿀 방법이 없습니다. 실패할 가능성이 있으므로 parse 역시 read_line 과 마찬가지로 Result 타입을 반환합니다([앞의 “Result 타입으로 발생 가능한 실패 처리하기”] (#handling-potential-failure-with-result) 참조). 따라서 여기서도 같은 방식으로 다시 expect 메서드를 사용합니다. parse 가 문자열에서 숫자를 만들지 못해 Err variant를 반환하면, expect 호출은 게임을 중단시키고 우리가 준 메시지를 출력합니다. 반대로 parse 가 문자열을 숫자로 성공적으로 변환하면 Result 의 Ok variant를 반환하고, expect 는 우리가 원하는 숫자를 그 Ok 값에서 꺼내 반환합니다.

이제 프로그램을 실행해 봅시다.

$ cargo run
   Compiling guessing_game v0.1.0 (file:///projects/guessing_game)
    Finished `dev` profile [unoptimized + debuginfo] target(s) in 0.26s
     Running `target/debug/guessing_game`
Guess the number!
The secret number is: 58
Please input your guess.
  76
You guessed: 76
Too big!

좋습니다! 추측값 앞에 공백이 들어 있었는데도 프로그램은 사용자가 76을 추측했다는 것을 올바르게 알아냈습니다. 프로그램을 여러 번 실행해 다양한 입력에서 어떻게 동작하는지 확인해 보세요. 정답을 맞혀 보고, 너무 큰 숫자도 넣어 보고, 너무 작은 숫자도 넣어 보세요.

이제 게임의 대부분은 동작하지만, 사용자는 한 번만 추측할 수 있습니다. 루프를 추가해 이를 바꿔 봅시다!

루프로 여러 번 추측하기 허용하기

loop 키워드는 무한 루프를 만듭니다. 사용자에게 더 많은 기회를 주기 위해 루프를 추가해 봅시다.

파일명: src/main.rs

use std::cmp::Ordering;
use std::io;

use rand::Rng;

fn main() {
    println!("Guess the number!");

    let secret_number = rand::thread_rng().gen_range(1..=100);

    // --snip--

    println!("The secret number is: {secret_number}");

    loop {
        println!("Please input your guess.");

        // --snip--


        let mut guess = String::new();

        io::stdin()
            .read_line(&mut guess)
            .expect("Failed to read line");

        let guess: u32 = guess.trim().parse().expect("Please type a number!");

        println!("You guessed: {guess}");

        match guess.cmp(&secret_number) {
            Ordering::Less => println!("Too small!"),
            Ordering::Greater => println!("Too big!"),
            Ordering::Equal => println!("You win!"),
        }
    }
}

보시다시피 추측 입력 프롬프트부터 그 뒤의 모든 코드를 루프 안으로 옮겼습니다. 루프 안의 줄들은 각각 공백 네 칸씩 더 들여쓰는 것을 잊지 말고, 프로그램을 다시 실행해 보세요. 이제 프로그램은 영원히 다음 추측을 계속 요청합니다. 그런데 이로 인해 새로운 문제가 생깁니다. 사용자가 게임을 끝낼 수 없게 보입니다!

물론 사용자는 키보드 단축키 ctrl-C 로 프로그램을 강제 종료할 수 있습니다. 하지만 “추측값을 비밀 숫자와 비교하기” 에서 parse 를 설명할 때 언급했듯이, 다른 탈출 방법도 있습니다. 사용자가 숫자가 아닌 값을 입력하면 프로그램이 크래시 나는 것이지요. 이를 활용하면 사용자가 게임을 종료할 수 있습니다. 아래를 보세요.

$ cargo run
   Compiling guessing_game v0.1.0 (file:///projects/guessing_game)
    Finished `dev` profile [unoptimized + debuginfo] target(s) in 0.23s
     Running `target/debug/guessing_game`
Guess the number!
The secret number is: 59
Please input your guess.
45
You guessed: 45
Too small!
Please input your guess.
60
You guessed: 60
Too big!
Please input your guess.
59
You guessed: 59
You win!
Please input your guess.
quit

thread 'main' panicked at src/main.rs:28:47:
Please type a number!: ParseIntError { kind: InvalidDigit }
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

quit 을 입력하면 게임이 종료되긴 하지만, 다른 어떤 숫자가 아닌 입력을 넣어도 마찬가지로 종료됩니다. 말할 것도 없이 그다지 좋은 방식은 아닙니다. 또한 정답을 맞혔을 때도 게임이 멈추게 만들고 싶습니다.

정답을 맞히면 종료하기

사용자가 이겼을 때 게임이 끝나도록 break 문을 추가해 봅시다.

파일명: src/main.rs

use std::cmp::Ordering;
use std::io;

use rand::Rng;

fn main() {
    println!("Guess the number!");

    let secret_number = rand::thread_rng().gen_range(1..=100);

    println!("The secret number is: {secret_number}");

    loop {
        println!("Please input your guess.");

        let mut guess = String::new();

        io::stdin()
            .read_line(&mut guess)
            .expect("Failed to read line");

        let guess: u32 = guess.trim().parse().expect("Please type a number!");

        println!("You guessed: {guess}");

        // --snip--

        match guess.cmp(&secret_number) {
            Ordering::Less => println!("Too small!"),
            Ordering::Greater => println!("Too big!"),
            Ordering::Equal => {
                println!("You win!");
                break;
            }
        }
    }
}

You win! 뒤에 break 줄을 추가하면, 사용자가 비밀 숫자를 맞혔을 때 프로그램이 루프를 빠져나오게 됩니다. 루프를 빠져나온다는 것은 프로그램도 종료된다는 뜻입니다. 루프가 main 의 마지막 부분이기 때문입니다.

잘못된 입력 처리하기

이제 게임 동작을 한 단계 더 다듬어 봅시다. 사용자가 숫자가 아닌 값을 입력했을 때 프로그램을 크래시시키는 대신, 그런 입력은 무시하고 계속 추측하게 만들겠습니다. 이를 위해 guess 를 String 에서 u32 로 변환하는 줄을 목록 2-5처럼 바꿉니다.

use std::cmp::Ordering;
use std::io;

use rand::Rng;

fn main() {
    println!("Guess the number!");

    let secret_number = rand::thread_rng().gen_range(1..=100);

    println!("The secret number is: {secret_number}");

    loop {
        println!("Please input your guess.");

        let mut guess = String::new();

        // --snip--

        io::stdin()
            .read_line(&mut guess)
            .expect("Failed to read line");

        let guess: u32 = match guess.trim().parse() {
            Ok(num) => num,
            Err(_) => continue,
        };

        println!("You guessed: {guess}");

        // --snip--

        match guess.cmp(&secret_number) {
            Ordering::Less => println!("Too small!"),
            Ordering::Greater => println!("Too big!"),
            Ordering::Equal => {
                println!("You win!");
                break;
            }
        }
    }
}

여기서는 expect 호출을 match 식으로 바꾸었습니다. 즉, 오류가 나면 크래시하는 방식에서 오류를 직접 처리하는 방식으로 이동한 것입니다. parse 가 Result 타입을 반환하고, Result 가 Ok 와 Err variant를 가진 enum이라는 점을 기억하세요. 여기서는 cmp 메서드의 Ordering 결과를 다룰 때와 마찬가지로 match 식을 사용하고 있습니다.

parse 가 문자열을 숫자로 성공적으로 변환하면, 결과 숫자를 담은 Ok 값을 반환합니다. 그 Ok 값은 첫 번째 arm의 패턴과 일치하고, match 식은 parse 가 만든 값을 Ok 안에서 꺼내 그 num 값 자체를 돌려줍니다. 이 숫자는 우리가 새로 만드는 guess 변수에 바로 들어갑니다.

반대로 parse 가 문자열을 숫자로 바꾸지 못하면, 에러에 대한 자세한 정보를 담은 Err 값을 반환합니다. 이 Err 값은 첫 번째 arm의 Ok(num) 패턴과는 맞지 않지만, 두 번째 arm의 Err(_) 패턴과는 맞습니다. 밑줄 _ 은 모든 값을 받아들이는 패턴입니다. 여기서는 안에 어떤 정보가 들어 있든 모든 Err 값을 다 받아들이겠다는 뜻입니다. 따라서 프로그램은 두 번째 arm의 코드인 continue 를 실행합니다. 이것은 프로그램에게 loop 의 다음 반복으로 가서 다시 추측값을 물어보라고 지시합니다. 즉, 결과적으로 프로그램은 parse 가 만날 수 있는 모든 오류를 무시하게 됩니다.

이제 프로그램의 모든 동작이 기대한 대로 되어야 합니다. 실행해 봅시다.

$ cargo run
   Compiling guessing_game v0.1.0 (file:///projects/guessing_game)
    Finished `dev` profile [unoptimized + debuginfo] target(s) in 0.13s
     Running `target/debug/guessing_game`
Guess the number!
The secret number is: 61
Please input your guess.
10
You guessed: 10
Too small!
Please input your guess.
99
You guessed: 99
Too big!
Please input your guess.
foo
Please input your guess.
61
You guessed: 61
You win!

아주 좋습니다! 이제 아주 작은 마지막 수정만 하면 숫자 맞히기 게임이 완성됩니다. 프로그램이 아직도 비밀 숫자를 출력하고 있다는 점을 떠올려 보세요. 테스트할 때는 유용했지만, 게임의 재미를 망칩니다. 비밀 숫자를 출력하는 println! 을 삭제합시다. 최종 코드는 목록 2-6에 나와 있습니다.

use std::cmp::Ordering;
use std::io;

use rand::Rng;

fn main() {
    println!("Guess the number!");

    let secret_number = rand::thread_rng().gen_range(1..=100);

    loop {
        println!("Please input your guess.");

        let mut guess = String::new();

        io::stdin()
            .read_line(&mut guess)
            .expect("Failed to read line");

        let guess: u32 = match guess.trim().parse() {
            Ok(num) => num,
            Err(_) => continue,
        };

        println!("You guessed: {guess}");

        match guess.cmp(&secret_number) {
            Ordering::Less => println!("Too small!"),
            Ordering::Greater => println!("Too big!"),
            Ordering::Equal => {
                println!("You win!");
                break;
            }
        }
    }
}

이제 여러분은 숫자 맞히기 게임을 성공적으로 만들었습니다. 축하합니다!

정리

이 프로젝트는 많은 새로운 러스트 개념을 직접 손으로 익히는 방식으로 소개해 주었습니다. let, match, 함수, 외부 크레이트 사용법 등 여러 가지를 다뤘습니다. 다음 몇 장에서 이 개념들을 더 자세히 배우게 됩니다. 3장에서는 대부분의 프로그래밍 언어에 공통으로 있는 변수, 데이터 타입, 함수 같은 개념을 다루고, 그것들을 러스트에서 어떻게 사용하는지 보여 줍니다. 4장에서는 러스트를 다른 언어와 구별해 주는 소유권을 탐구합니다. 5장에서는 구조체와 메서드 문법을 다루고, 6장에서는 enum이 어떻게 동작하는지 설명합니다.

일반적인 프로그래밍 개념

이 장에서는 거의 모든 프로그래밍 언어에 등장하는 개념들과, 그것들이 러스트에서 어떻게 동작하는지를 다룹니다. 많은 프로그래밍 언어는 핵심 부분에서 상당히 많은 공통점을 가지고 있습니다. 이 장에서 소개하는 개념들 중 러스트만의 고유한 것은 없지만, 러스트의 맥락 속에서 그것들을 설명하고 사용하는 관례도 함께 살펴보겠습니다.

구체적으로는 변수, 기본 타입, 함수, 주석, 제어 흐름을 배우게 됩니다. 이런 기초는 모든 러스트 프로그램에 등장하며, 초반에 익혀 두면 앞으로의 학습을 지탱해 줄 단단한 기반이 됩니다.

변수와 가변성

변수와 가변성

“변수로 값 저장하기” 절에서 언급했듯이, 변수는 기본적으로 불변입니다. 이것은 러스트가 제공하는 안전성과 쉬운 동시성을 최대한 활용하는 방식으로 코드를 작성하도록 살짝 밀어 주는 여러 장치 중 하나입니다. 물론 여전히 변수를 가변으로 만들 수도 있습니다. 러스트가 왜 불변성을 선호하도록 유도하는지, 그리고 어떤 경우에는 왜 그 기본 선택에서 벗어나고 싶을 수 있는지를 살펴봅시다.

변수가 불변이라면, 어떤 값이 이름에 한 번 바인딩되고 나면 그 값을 바꿀 수 없습니다. 이를 확인해 보기 위해 projects 디렉터리 안에 cargo new variables 를 사용해 variables 라는 새 프로젝트를 만들어 봅시다.

그런 다음 새 variables 디렉터리에서 src/main.rs 를 열고, 코드를 다음과 같이 바꾸세요. 아직은 이 코드는 컴파일되지 않습니다.

Filename: src/main.rs

fn main() {
    let x = 5;
    println!("The value of x is: {x}");
    x = 6;
    println!("The value of x is: {x}");
}

저장한 뒤 cargo run 으로 프로그램을 실행해 보세요. 다음 출력처럼 불변성과 관련된 오류 메시지를 받게 될 것입니다.

$ cargo run
   Compiling variables v0.1.0 (file:///projects/variables)
error[E0384]: cannot assign twice to immutable variable `x`
 --> src/main.rs:4:5
  |
2 |     let x = 5;
  |         - first assignment to `x`
3 |     println!("The value of x is: {x}");
4 |     x = 6;
  |     ^^^^^ cannot assign twice to immutable variable
  |
help: consider making this binding mutable
  |
2 |     let mut x = 5;
  |         +++

For more information about this error, try `rustc --explain E0384`.
error: could not compile `variables` (bin "variables") due to 1 previous error

이 예제는 컴파일러가 프로그램의 오류를 어떻게 찾아주는지를 보여 줍니다. 컴파일러 오류는 답답할 수 있지만, 사실 그것은 아직 프로그램이 여러분이 원하는 일을 안전하게 하지 못하고 있다는 뜻일 뿐입니다. 여러분이 형편없는 프로그래머라는 뜻은 절대로 아닙니다! 경험 많은 Rustacean도 여전히 컴파일러 오류를 만납니다.

여러분이 cannot assign twice to immutable variable `x` 라는 오류 메시지를 받은 이유는, 불변 변수 x 에 두 번째 값을 대입하려 했기 때문입니다.

불변으로 지정된 값을 바꾸려 할 때 컴파일 시점 오류가 나는 것은 중요합니다. 바로 이 상황이 버그로 이어질 수 있기 때문입니다. 코드의 한 부분은 어떤 값이 절대 바뀌지 않는다고 가정하고 동작하는데, 다른 부분이 그 값을 바꿔 버리면 첫 번째 부분의 코드는 설계한 대로 동작하지 않을 수 있습니다. 이런 종류의 버그는 나중에 원인을 추적하기가 어렵고, 특히 두 번째 코드 조각이 값을 가끔만 바꿀 때 더 그렇습니다. 러스트 컴파일러는 여러분이 어떤 값이 바뀌지 않는다고 선언하면 정말로 바뀌지 않도록 보장해 주므로, 그 상태를 머릿속으로 따로 추적할 필요가 없습니다. 덕분에 코드에 대해 추론하기가 더 쉬워집니다.

하지만 가변성은 매우 유용할 수 있고, 코드를 더 편하게 작성하게 해 주기도 합니다. 변수는 기본적으로 불변이지만, 2장 에서 했듯이 변수 이름 앞에 mut 를 붙이면 가변으로 만들 수 있습니다. mut 를 추가하는 것은 이 변수의 값이 코드의 다른 부분에서 바뀔 것이라는 의도를 미래의 독자에게 전달하는 역할도 합니다.

예를 들어 src/main.rs 를 다음처럼 바꿔 봅시다.

Filename: src/main.rs

fn main() {
    let mut x = 5;
    println!("The value of x is: {x}");
    x = 6;
    println!("The value of x is: {x}");
}

이제 프로그램을 실행하면 다음과 같은 결과를 얻습니다.

$ cargo run
   Compiling variables v0.1.0 (file:///projects/variables)
    Finished `dev` profile [unoptimized + debuginfo] target(s) in 0.30s
     Running `target/debug/variables`
The value of x is: 5
The value of x is: 6

mut 를 사용했기 때문에 x 에 바인딩된 값을 5 에서 6 으로 바꿀 수 있습니다. 결국 가변성을 사용할지 말지는 여러분의 선택이며, 그 상황에서 무엇이 가장 명확한지에 따라 달라집니다.

상수 선언하기

불변 변수와 마찬가지로 상수(constants) 도 이름에 바인딩된 뒤 바뀌지 않는 값입니다. 하지만 상수와 변수 사이에는 몇 가지 차이가 있습니다.

첫째, 상수에는 mut 를 사용할 수 없습니다. 상수는 단지 기본적으로 불변인 것이 아니라, 항상 불변입니다. 상수는 let 키워드 대신 const 키워드로 선언하며, 값의 타입을 반드시 명시해야 합니다. 타입과 타입 주석은 다음 절인 “데이터 타입”에서 다루므로 지금은 세부를 걱정하지 않아도 됩니다. 다만 타입을 항상 명시해야 한다는 점만 기억하세요.

상수는 전역 스코프를 포함한 어떤 스코프에서도 선언할 수 있으므로, 코드의 여러 부분이 알아야 하는 값에 유용합니다.

마지막 차이는, 상수는 상수식으로만 값을 지정할 수 있고 런타임에 계산되어야만 하는 결과값으로는 지정할 수 없다는 점입니다.

다음은 상수 선언의 예입니다.

#![allow(unused)]
fn main() {
const THREE_HOURS_IN_SECONDS: u32 = 60 * 60 * 3;
}

이 상수의 이름은 THREE_HOURS_IN_SECONDS 이고, 값은 60(1분의 초 수) × 60(1시간의 분 수) × 3(이 프로그램에서 계산하고 싶은 시간 수)의 결과로 설정됩니다. 러스트에서 상수 이름은 모두 대문자로 쓰고 단어 사이는 밑줄로 구분하는 것이 관례입니다. 컴파일러는 컴파일 시점에 제한된 연산 집합을 평가할 수 있으므로, 이 상수를 그냥 10,800 으로 쓰는 대신 더 이해하고 검증하기 쉬운 형태로 적을 수 있습니다. 상수를 선언할 때 어떤 연산을 사용할 수 있는지는 Rust Reference의 상수 평가 절을 참고하세요.

상수는 선언된 스코프 안에서 프로그램이 실행되는 전체 시간 동안 유효합니다. 이런 성질 때문에 상수는 애플리케이션 도메인에서 프로그램의 여러 부분이 알아야 하는 값, 예를 들면 게임 플레이어가 얻을 수 있는 최대 점수나 빛의 속도 같은 값을 표현할 때 유용합니다.

프로그램 전반에서 쓰이는 하드코딩된 값을 상수로 이름 붙여 두면, 미래의 유지보수자가 그 값의 의미를 이해하는 데 도움이 됩니다. 또한 나중에 그 값을 바꿔야 할 때 코드의 단 한 곳만 수정하면 된다는 점도 장점입니다.

섀도잉

2장의 숫자 맞히기 게임 튜토리얼에서 본 것처럼, 이전 변수와 같은 이름으로 새 변수를 선언할 수 있습니다. Rustacean은 이때 첫 번째 변수가 두 번째 변수에 의해 shadowed 되었다고 말합니다. 즉, 변수 이름을 사용할 때 컴파일러가 보게 되는 것은 두 번째 변수라는 뜻입니다. 결과적으로 두 번째 변수는 첫 번째 변수를 가려 버리고, 다시 다른 변수에 가려지거나 스코프가 끝날 때까지 그 이름에 대한 모든 사용을 자신이 차지합니다. 섀도잉은 다음처럼 같은 변수 이름을 다시 쓰고 let 키워드를 반복해서 사용하면 됩니다.

Filename: src/main.rs

fn main() {
    let x = 5;

    let x = x + 1;

    {
        let x = x * 2;
        println!("The value of x in the inner scope is: {x}");
    }

    println!("The value of x is: {x}");
}

이 프로그램은 먼저 x 를 값 5 에 바인딩합니다. 그런 다음 let x = 를 다시 사용해 새 변수 x 를 만들고, 원래 값에 1 을 더해 x 값을 6 으로 만듭니다. 이후 중괄호로 만들어진 내부 스코프 안에서 세 번째 let 문도 x 를 다시 섀도잉하고 새 변수를 만듭니다. 이번에는 이전 값에 2 를 곱해서 x 값을 12 로 만듭니다. 그 스코프가 끝나면 내부 섀도잉은 사라지고 x 는 다시 6 이 됩니다. 프로그램을 실행하면 다음과 같은 출력이 나옵니다.

$ cargo run
   Compiling variables v0.1.0 (file:///projects/variables)
    Finished `dev` profile [unoptimized + debuginfo] target(s) in 0.31s
     Running `target/debug/variables`
The value of x in the inner scope is: 12
The value of x is: 6

섀도잉은 변수를 mut 로 만드는 것과 다릅니다. 만약 let 키워드 없이 실수로 이 변수에 다시 대입하려고 하면 컴파일 시점 오류가 나기 때문입니다. let 을 사용하면 값에 몇 번의 변환을 적용한 뒤에도, 그 변환이 끝난 이후 변수는 다시 불변으로 둘 수 있습니다.

mut 와 섀도잉의 또 다른 차이는, let 키워드를 다시 사용할 때 우리는 사실상 새 변수를 만들기 때문에 값의 타입을 바꾸면서도 같은 이름을 재사용할 수 있다는 점입니다. 예를 들어 어떤 프로그램이 사용자에게 텍스트 사이에 넣고 싶은 공백 수를 공백 문자로 입력하게 한 뒤, 그 입력을 숫자로 저장하고 싶다고 해 봅시다.

fn main() {
    let spaces = "   ";
    let spaces = spaces.len();
}

첫 번째 spaces 변수는 문자열 타입이고, 두 번째 spaces 변수는 숫자 타입입니다. 이처럼 섀도잉은 spaces_str 와 spaces_num 같은 다른 이름을 굳이 придумать할 필요를 없애 주고, 더 단순한 spaces 라는 이름을 그대로 재사용하게 해 줍니다. 반면 여기에 mut 를 사용하려고 하면, 다음과 같이 컴파일 시점 오류가 납니다.

fn main() {
    let mut spaces = "   ";
    spaces = spaces.len();
}

오류 메시지는 변수의 타입을 바꾸는 것은 허용되지 않는다고 알려 줍니다.

$ cargo run
   Compiling variables v0.1.0 (file:///projects/variables)
error[E0308]: mismatched types
 --> src/main.rs:3:14
  |
2 |     let mut spaces = "   ";
  |                      ----- expected due to this value
3 |     spaces = spaces.len();
  |              ^^^^^^^^^^^^ expected `&str`, found `usize`

For more information about this error, try `rustc --explain E0308`.
error: could not compile `variables` (bin "variables") due to 1 previous error

이제 변수가 어떻게 동작하는지 살펴봤으니, 변수가 가질 수 있는 더 많은 데이터 타입을 살펴봅시다.

데이터 타입

데이터 타입

러스트의 모든 값은 특정한 데이터 타입(data type) 을 가집니다. 데이터 타입은 어떤 종류의 데이터가 지정되었는지를 러스트에게 알려 주며, 러스트는 이를 바탕으로 그 데이터를 어떻게 다뤄야 할지 알 수 있습니다. 여기서는 데이터 타입의 두 가지 하위 집합인 스칼라 타입과 복합 타입을 살펴보겠습니다.

러스트는 정적 타입(statically typed) 언어라는 점을 기억하세요. 즉, 컴파일 시점에 모든 변수의 타입을 알고 있어야 합니다. 컴파일러는 보통 값과 사용 방식을 보고 어떤 타입을 써야 하는지 추론할 수 있습니다. 하지만 2장의 “추측값을 비밀 숫자와 비교하기” 절에서 parse 를 사용해 String 을 숫자 타입으로 바꾼 경우처럼, 여러 타입이 가능한 상황에서는 다음처럼 타입 주석을 추가해야 합니다.

#![allow(unused)]
fn main() {
let guess: u32 = "42".parse().expect("Not a number!");
}

위 코드에 있는 : u32 타입 주석을 추가하지 않으면, 러스트는 아래와 같은 오류를 표시합니다. 이 오류는 컴파일러가 우리가 어떤 타입을 쓰고 싶은지 알기 위해 더 많은 정보를 필요로 한다는 뜻입니다.

$ cargo build
   Compiling no_type_annotations v0.1.0 (file:///projects/no_type_annotations)
error[E0284]: type annotations needed
 --> src/main.rs:2:9
  |
2 |     let guess = "42".parse().expect("Not a number!");
  |         ^^^^^        ----- type must be known at this point
  |
  = note: cannot satisfy `<_ as FromStr>::Err == _`
help: consider giving `guess` an explicit type
  |
2 |     let guess: /* Type */ = "42".parse().expect("Not a number!");
  |              ++++++++++++

For more information about this error, try `rustc --explain E0284`.
error: could not compile `no_type_annotations` (bin "no_type_annotations") due to 1 previous error

다른 데이터 타입에서도 여러 형태의 타입 주석을 보게 될 것입니다.

스칼라 타입

스칼라(scalar) 타입은 하나의 단일 값을 나타냅니다. 러스트에는 네 가지 기본 스칼라 타입이 있습니다. 정수, 부동소수점 수, 불리언, 문자입니다. 다른 프로그래밍 언어에서 이미 익숙할 수도 있습니다. 러스트에서 각각이 어떻게 동작하는지 바로 살펴봅시다.

정수 타입

정수(integer) 는 소수 부분이 없는 숫자입니다. 우리는 2장에서 이미 u32 라는 정수 타입을 사용했습니다. 이 타입 선언은 그 값이 부호 없는 정수(부호 있는 정수 타입은 u 대신 i 로 시작합니다)이며, 32비트 공간을 차지한다는 뜻입니다. 표 3-1에는 러스트의 내장 정수 타입이 나와 있습니다. 이들 중 어느 것을 사용해도 정수 값의 타입을 선언할 수 있습니다.

표 3-1: 러스트의 정수 타입

각 변형은 부호 있음 또는 부호 없음일 수 있으며, 크기가 명시되어 있습니다. 부호 있음(signed) 과 부호 없음(unsigned) 은 숫자가 음수가 될 수 있는지 여부를 뜻합니다. 즉 숫자와 함께 부호를 저장해야 하는지(부호 있음), 아니면 항상 양수이므로 부호 없이 표현할 수 있는지(부호 없음)를 말합니다. 종이에 숫자를 적는 것과 비슷합니다. 부호가 중요할 때는 더하기나 빼기 기호를 함께 적지만, 숫자가 양수라고 가정해도 안전할 때는 부호를 생략합니다. 부호 있는 숫자는 2의 보수 표현으로 저장됩니다.

각 부호 있는 변형은 −(2^{n − 1}) 부터 2^{n − 1} − 1 까지의 수를 저장할 수 있습니다. 여기서 n 은 해당 변형이 사용하는 비트 수입니다. 따라서 i8 은 −(2⁷) 부터 2⁷ − 1 까지, 즉 −128 에서 127 까지 저장할 수 있습니다. 부호 없는 변형은 0 에서 2ⁿ − 1 까지 저장할 수 있으므로, u8 은 0 에서 2⁸ − 1, 즉 0 에서 255 까지 저장할 수 있습니다.

또한 isize 와 usize 타입은 프로그램이 실행되는 컴퓨터의 아키텍처에 따라 달라집니다. 64비트 아키텍처라면 64비트, 32비트 아키텍처라면 32비트입니다.

정수 리터럴은 표 3-2에 보인 여러 형식으로 쓸 수 있습니다. 여러 숫자 타입으로 사용될 수 있는 숫자 리터럴은 57u8 처럼 타입 접미사를 붙여 타입을 지정할 수 있습니다. 또한 숫자를 읽기 쉽게 하기 위해 시각적 구분자인 _ 를 사용할 수도 있습니다. 예를 들어 1_000 은 1000 과 같은 값입니다.

표 3-2: 러스트의 정수 리터럴

그렇다면 어떤 정수 타입을 써야 할까요? 잘 모르겠다면 러스트의 기본값이 대체로 좋은 출발점입니다. 정수 타입의 기본값은 i32 입니다. isize 나 usize 를 주로 쓰는 상황은 어떤 종류의 컬렉션을 인덱싱할 때입니다.

부동소수점 타입

러스트에는 소수점을 가진 숫자인 부동소수점 수(floating-point numbers) 를 위한 기본 타입도 두 가지 있습니다. 러스트의 부동소수점 타입은 각각 32비트와 64비트 크기의 f32, f64 입니다. 기본 타입은 f64 인데, 현대 CPU에서는 대체로 f32 와 속도가 비슷하면서도 더 높은 정밀도를 제공하기 때문입니다. 모든 부동소수점 타입은 부호가 있습니다.

다음은 부동소수점 수가 실제로 동작하는 예시입니다.

파일명: src/main.rs

fn main() {
    let x = 2.0; // f64

    let y: f32 = 3.0; // f32
}

부동소수점 수는 IEEE-754 표준에 따라 표현됩니다.

숫자 연산

러스트는 모든 숫자 타입에 대해, 여러분이 기대할 만한 기본 수학 연산인 덧셈, 뺄셈, 곱셈, 나눗셈, 나머지 연산을 지원합니다. 정수 나눗셈은 0 쪽으로 버림하여 가장 가까운 정수를 얻습니다. 다음 코드는 let 문 안에서 각 숫자 연산을 어떻게 사용하는지를 보여 줍니다.

파일명: src/main.rs

fn main() {
    // addition
    let sum = 5 + 10;

    // subtraction
    let difference = 95.5 - 4.3;

    // multiplication
    let product = 4 * 30;

    // division
    let quotient = 56.7 / 32.2;
    let truncated = -5 / 3; // Results in -1

    // remainder
    let remainder = 43 % 5;
}

이 문장들 안의 각 식은 수학 연산자를 사용하고, 하나의 값으로 평가된 뒤 변수에 바인딩됩니다. 러스트가 제공하는 모든 연산자 목록은 부록 B 에서 볼 수 있습니다.

불리언 타입

대부분의 다른 프로그래밍 언어와 마찬가지로, 러스트의 불리언 타입은 두 가지 가능한 값만 가집니다. true 와 false 입니다. 불리언은 크기가 1바이트입니다. 러스트에서 불리언 타입은 bool 로 표기합니다. 예를 들면 다음과 같습니다.

파일명: src/main.rs

fn main() {
    let t = true;

    let f: bool = false; // with explicit type annotation
}

불리언 값은 주로 if 식 같은 조건문에서 사용합니다. 러스트에서 if 식이 어떻게 동작하는지는 “제어 흐름” 절에서 다룹니다.

문자 타입

러스트의 char 타입은 언어에서 가장 기본적인 문자 타입입니다. 다음은 char 값을 선언하는 몇 가지 예입니다.

파일명: src/main.rs

fn main() {
    let c = 'z';
    let z: char = 'ℤ'; // with explicit type annotation
    let heart_eyed_cat = '😻';
}

char 리터럴은 큰따옴표를 사용하는 문자열 리터럴과 달리, 작은따옴표로 감싼다는 점에 주목하세요. 러스트의 char 타입은 크기가 4바이트이며 유니코드 스칼라 값을 나타냅니다. 즉, 단순히 ASCII 문자만이 아니라 훨씬 더 많은 것을 표현할 수 있습니다. 악센트가 있는 문자, 중국어·일본어·한국어 문자, 이모지, zero-width space 모두 러스트에서 유효한 char 값입니다. 유니코드 스칼라 값 범위는 U+0000 부터 U+D7FF 및 U+E000 부터 U+10FFFF 까지입니다. 다만 유니코드에서 “문자”라는 개념은 생각보다 단순하지 않기 때문에, 인간이 직관적으로 생각하는 “한 글자”와 러스트의 char 가 반드시 일치하지는 않습니다. 이 주제는 8장의 “문자열에 UTF-8 텍스트 저장하기” 절에서 자세히 다룹니다.

복합 타입

복합 타입(compound types) 은 여러 값을 하나의 타입으로 묶을 수 있습니다. 러스트에는 두 가지 기본 복합 타입이 있습니다. 튜플과 배열입니다.

튜플 타입

튜플(tuple) 은 서로 다른 타입의 여러 값을 하나의 복합 타입으로 묶는 일반적인 방법입니다. 튜플은 길이가 고정되어 있어서, 한 번 선언하면 크기를 늘리거나 줄일 수 없습니다.

튜플은 괄호 안에 쉼표로 구분된 값 목록을 써서 만듭니다. 튜플 안의 각 위치는 타입을 가지며, 서로 다른 값들이 같은 타입일 필요는 없습니다. 아래 예시에서는 선택적인 타입 주석을 추가해 두었습니다.

파일명: src/main.rs

fn main() {
    let tup: (i32, f64, u8) = (500, 6.4, 1);
}

변수 tup 은 튜플 전체에 바인딩됩니다. 튜플은 하나의 단일 복합 요소로 간주되기 때문입니다. 튜플 안의 개별 값을 꺼내려면 다음처럼 패턴 매칭을 사용해 튜플을 구조분해할 수 있습니다.

파일명: src/main.rs

fn main() {
    let tup = (500, 6.4, 1);

    let (x, y, z) = tup;

    println!("The value of y is: {y}");
}

이 프로그램은 먼저 튜플을 만들고 그것을 변수 tup 에 바인딩합니다. 그런 다음 let 과 패턴을 사용해 tup 을 세 개의 개별 변수 x, y, z 로 나눕니다. 이것을 구조분해(destructuring) 라고 하며, 하나의 튜플을 여러 부분으로 풀어내는 것입니다. 마지막으로 프로그램은 y 의 값인 6.4 를 출력합니다.

튜플 요소는 점(.)과 접근하려는 값의 인덱스를 사용해 직접 가져올 수도 있습니다. 예를 들면 다음과 같습니다.

파일명: src/main.rs

fn main() {
    let x: (i32, f64, u8) = (500, 6.4, 1);

    let five_hundred = x.0;

    let six_point_four = x.1;

    let one = x.2;
}

이 프로그램은 튜플 x 를 만들고, 각 요소를 대응하는 인덱스로 접근합니다. 대부분의 프로그래밍 언어와 마찬가지로, 튜플의 첫 번째 인덱스는 0입니다.

아무 값도 가지지 않는 튜플에는 특별한 이름이 있는데, 바로 유닛(unit) 입니다. 이 값과 그에 대응하는 타입은 모두 () 로 쓰며, 비어 있는 값 또는 비어 있는 반환 타입을 나타냅니다. 어떤 식이 다른 값을 반환하지 않으면 암묵적으로 유닛 값을 반환합니다.

배열 타입

여러 값을 모아 두는 또 다른 방법은 배열(array) 입니다. 튜플과 달리, 배열의 모든 요소는 반드시 같은 타입이어야 합니다. 또 다른 언어의 배열과 달리, 러스트의 배열은 길이가 고정되어 있습니다.

배열 값은 대괄호 안에 쉼표로 구분된 목록으로 씁니다.

파일명: src/main.rs

fn main() {
    let a = [1, 2, 3, 4, 5];
}

배열은 지금까지 본 다른 타입들과 마찬가지로 데이터를 스택에 배치하고 싶을 때, 또는 힙이 아닌 스택에 두고 싶을 때(스택과 힙은 4장 에서 더 다룹니다), 혹은 요소 수가 항상 고정되어 있음을 보장하고 싶을 때 유용합니다. 다만 배열은 벡터만큼 유연하지는 않습니다. 벡터는 표준 라이브러리가 제공하는 비슷한 컬렉션 타입으로, 내용물이 힙에 저장되기 때문에 크기를 늘리거나 줄일 수 있습니다. 배열과 벡터 중 무엇을 써야 할지 확신이 없다면, 아마 벡터를 써야 할 가능성이 큽니다. 벡터는 8장에서 자세히 다룹니다.

하지만 요소 개수가 절대 바뀌지 않는다는 것을 알고 있다면 배열이 더 적합합니다. 예를 들어 프로그램에서 월 이름을 사용한다면, 항상 12개 요소를 가진다는 것을 알고 있으므로 벡터보다는 배열을 사용할 것입니다.

#![allow(unused)]
fn main() {
let months = ["January", "February", "March", "April", "May", "June", "July",
              "August", "September", "October", "November", "December"];
}

배열의 타입은 대괄호 안에 각 요소의 타입, 세미콜론, 그리고 배열 요소 수를 적어 표현합니다. 예를 들면 다음과 같습니다.

#![allow(unused)]
fn main() {
let a: [i32; 5] = [1, 2, 3, 4, 5];
}

여기서 i32 는 각 요소의 타입입니다. 세미콜론 뒤의 숫자 5 는 배열이 다섯 개 요소를 포함한다는 뜻입니다.

또한 초기값 하나와 세미콜론, 길이를 지정해 모든 요소를 같은 값으로 초기화할 수도 있습니다. 다음과 같습니다.

#![allow(unused)]
fn main() {
let a = [3; 5];
}

이 배열 a 는 다섯 개 요소를 가지며, 처음에는 모두 값 3 으로 설정됩니다. 이것은 let a = [3, 3, 3, 3, 3]; 를 더 간결하게 쓴 것과 같습니다.

배열 요소 접근하기

배열은 스택에 배치될 수 있는, 크기가 알려져 있고 고정된 하나의 연속 메모리 조각입니다. 배열의 요소에는 다음처럼 인덱싱을 사용해 접근할 수 있습니다.

파일명: src/main.rs

fn main() {
    let a = [1, 2, 3, 4, 5];

    let first = a[0];
    let second = a[1];
}

이 예제에서 first 라는 변수는 배열의 [0] 위치에 있는 값이 1 이므로 값 1 을 갖게 됩니다. second 라는 변수는 [1] 인덱스에 있는 값 2 를 갖게 됩니다.

잘못된 배열 요소 접근

배열 끝을 넘어선 요소에 접근하려 하면 어떤 일이 벌어지는지 봅시다. 2장의 숫자 맞히기 게임과 비슷하게, 사용자에게 배열 인덱스를 입력받는 다음 코드를 실행한다고 해 봅시다.

파일명: src/main.rs

use std::io;

fn main() {
    let a = [1, 2, 3, 4, 5];

    println!("Please enter an array index.");

    let mut index = String::new();

    io::stdin()
        .read_line(&mut index)
        .expect("Failed to read line");

    let index: usize = index
        .trim()
        .parse()
        .expect("Index entered was not a number");

    let element = a[index];

    println!("The value of the element at index {index} is: {element}");
}

이 코드는 컴파일 자체는 성공합니다. cargo run 으로 실행해 0, 1, 2, 3, 4 를 입력하면 프로그램은 배열에서 해당 인덱스의 값을 출력합니다. 하지만 배열 끝을 넘는 숫자, 예를 들어 10 을 입력하면 다음과 같은 출력을 보게 됩니다.

thread 'main' panicked at src/main.rs:19:19:
index out of bounds: the len is 5 but the index is 10
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

이 프로그램은 인덱싱 연산에 잘못된 값을 사용하는 지점에서 런타임 오류를 일으켰습니다. 프로그램은 오류 메시지와 함께 종료되었고, 마지막 println! 문은 실행되지 않았습니다. 인덱싱을 사용해 요소에 접근하려 할 때 러스트는 지정한 인덱스가 배열 길이보다 작은지 검사합니다. 인덱스가 길이보다 크거나 같으면 러스트는 패닉을 일으킵니다. 특히 이 예제처럼 사용자가 나중에 어떤 값을 입력할지 컴파일러가 알 수 없는 경우에는, 이런 검사를 런타임에 할 수밖에 없습니다.

이것은 러스트의 메모리 안전 원칙이 실제로 동작하는 예입니다. 많은 저수준 언어에서는 이런 검사가 이루어지지 않으며, 잘못된 인덱스를 주면 유효하지 않은 메모리에 접근할 수 있습니다. 러스트는 그런 잘못된 메모리 접근을 허용하고 계속 진행하는 대신, 즉시 종료함으로써 여러분을 이런 종류의 오류로부터 보호합니다. 9장에서는 러스트의 에러 처리를 더 살펴보고, 패닉을 일으키지도 않고 잘못된 메모리 접근도 허용하지 않는 읽기 쉽고 안전한 코드를 어떻게 작성할 수 있는지 설명합니다.

함수

함수

함수는 러스트 코드 곳곳에서 매우 흔하게 등장합니다. 여러분은 이미 이 언어에서 가장 중요한 함수 중 하나인 main 함수를 보았습니다. main 은 많은 프로그램의 진입점입니다. 또한 새 함수를 선언할 수 있게 해 주는 fn 키워드도 보았습니다.

러스트 코드는 함수와 변수 이름에 snake case 를 관례적으로 사용합니다. 즉 모든 문자를 소문자로 쓰고, 단어 사이는 밑줄로 구분합니다. 다음은 함수 정의 예제를 담은 프로그램입니다.

파일명: src/main.rs

fn main() {
    println!("Hello, world!");

    another_function();
}

fn another_function() {
    println!("Another function.");
}

러스트에서 함수는 fn 뒤에 함수 이름과 괄호를 써서 정의합니다. 중괄호는 함수 본문이 어디서 시작하고 끝나는지를 컴파일러에게 알려 줍니다.

우리가 정의한 함수는 이름 뒤에 괄호를 붙여 호출할 수 있습니다. another_function 이 프로그램 안에 정의되어 있으므로, main 함수 안에서도 호출할 수 있습니다. 소스 코드에서는 another_function 을 main 함수 뒤에 정의했지만, 앞에 정의해도 상관없습니다. 러스트는 함수를 어디에 정의했는지는 신경 쓰지 않고, 호출자가 볼 수 있는 스코프 어딘가에 정의되어 있기만 하면 됩니다.

함수를 좀 더 살펴보기 위해 functions 라는 새 바이너리 프로젝트를 시작해 봅시다. another_function 예제를 src/main.rs 에 넣고 실행해 보세요. 다음과 같은 출력이 나올 것입니다.

$ cargo run
   Compiling functions v0.1.0 (file:///projects/functions)
    Finished `dev` profile [unoptimized + debuginfo] target(s) in 0.28s
     Running `target/debug/functions`
Hello, world!
Another function.

줄들은 main 함수에 나타난 순서대로 실행됩니다. 먼저 “Hello, world!” 메시지가 출력되고, 그다음 another_function 이 호출되어 해당 메시지가 출력됩니다.

매개변수

함수에는 매개변수(parameters) 를 정의할 수 있습니다. 매개변수는 함수 시그니처의 일부인 특별한 변수입니다. 함수에 매개변수가 있으면, 그 매개변수들에 실제 값을 전달할 수 있습니다. 엄밀히 말하면 실제 전달되는 값은 인수(arguments) 라고 부르지만, 일상적인 대화에서는 함수 정의 안의 변수와 함수를 호출할 때 넘기는 실제 값 둘 모두를 가리켜 parameter 와 argument 를 섞어 쓰는 경우가 많습니다.

이번 버전의 another_function 에서는 매개변수를 하나 추가합니다.

파일명: src/main.rs

fn main() {
    another_function(5);
}

fn another_function(x: i32) {
    println!("The value of x is: {x}");
}

이 프로그램을 실행해 보세요. 다음과 같은 출력이 나올 것입니다.

$ cargo run
   Compiling functions v0.1.0 (file:///projects/functions)
    Finished `dev` profile [unoptimized + debuginfo] target(s) in 1.21s
     Running `target/debug/functions`
The value of x is: 5

another_function 선언에는 x 라는 이름의 매개변수 하나가 있습니다. x 의 타입은 i32 입니다. 우리가 another_function 에 5 를 넘기면, println! 매크로는 포맷 문자열 안에서 x 가 들어 있던 중괄호 자리에 5 를 넣습니다.

함수 시그니처에서는 각 매개변수의 타입을 반드시 선언해야 합니다. 이것은 러스트 설계에서 의도적으로 선택한 점입니다. 함수 정의에 타입 주석을 요구하면, 컴파일러는 코드의 다른 위치에서 여러분이 의미한 타입을 추론하기 위해 추가 정보를 거의 요구하지 않게 됩니다. 또한 함수가 어떤 타입을 기대하는지 알고 있으므로 더 유용한 오류 메시지를 제공할 수 있습니다.

매개변수가 여러 개라면 다음처럼 쉼표로 구분합니다.

파일명: src/main.rs

fn main() {
    print_labeled_measurement(5, 'h');
}

fn print_labeled_measurement(value: i32, unit_label: char) {
    println!("The measurement is: {value}{unit_label}");
}

이 예제는 print_labeled_measurement 라는 함수에 두 개의 매개변수를 둡니다. 첫 번째 매개변수는 value 이고 타입은 i32 입니다. 두 번째는 unit_label 이고 타입은 char 입니다. 함수는 그다음 value 와 unit_label 을 모두 포함한 문자열을 출력합니다.

이 코드를 실행해 봅시다. 현재 functions 프로젝트의 src/main.rs 에 들어 있는 프로그램을 위 예제로 바꾸고, cargo run 으로 실행하세요.

$ cargo run
   Compiling functions v0.1.0 (file:///projects/functions)
    Finished `dev` profile [unoptimized + debuginfo] target(s) in 0.31s
     Running `target/debug/functions`
The measurement is: 5h

value 에는 5, unit_label 에는 'h' 를 넘겨 함수 호출을 했으므로, 프로그램 출력에도 그 값들이 포함됩니다.

문장과 식

함수 본문은 여러 문장들로 이루어지며, 선택적으로 마지막에 식 하나로 끝날 수 있습니다. 지금까지 우리가 본 함수들은 마지막 식을 포함하지 않았지만, 여러분은 이미 문장 안의 일부로 식을 본 적이 있습니다. 러스트는 식 중심 언어이기 때문에 이 차이를 이해하는 것이 중요합니다. 다른 언어에서는 이런 구분이 같지 않은 경우도 있으니, 문장과 식이 무엇이고 그 차이가 함수 본문에 어떤 영향을 주는지 살펴봅시다.

• 문장(statements) 은 어떤 동작을 수행하지만 값을 반환하지 않는 명령입니다.
• 식(expressions) 은 어떤 결과값으로 평가됩니다.

몇 가지 예를 살펴봅시다.

사실 우리는 이미 문장과 식을 사용해 왔습니다. let 키워드로 변수를 만들고 값을 대입하는 것은 문장입니다. 목록 3-1에서 let y = 6; 은 문장입니다.

fn main() {
    let y = 6;
}

함수 정의 자체도 문장입니다. 앞의 예제 전체가 그 자체로 하나의 문장입니다. (곧 보겠지만, 함수 호출 은 문장이 아닙니다.)

문장은 값을 반환하지 않습니다. 따라서 다음 코드처럼 let 문을 다른 변수에 대입할 수 없으며, 오류가 발생합니다.

파일명: src/main.rs

fn main() {
    let x = (let y = 6);
}

이 프로그램을 실행하면 다음과 같은 오류가 나타납니다.

$ cargo run
   Compiling functions v0.1.0 (file:///projects/functions)
error: expected expression, found `let` statement
 --> src/main.rs:2:14
  |
2 |     let x = (let y = 6);
  |              ^^^
  |
  = note: only supported directly in conditions of `if` and `while` expressions

warning: unnecessary parentheses around assigned value
 --> src/main.rs:2:13
  |
2 |     let x = (let y = 6);
  |             ^         ^
  |
  = note: `#[warn(unused_parens)]` on by default
help: remove these parentheses
  |
2 -     let x = (let y = 6);
2 +     let x = let y = 6;
  |

warning: `functions` (bin "functions") generated 1 warning
error: could not compile `functions` (bin "functions") due to 1 previous error; 1 warning emitted

let y = 6 문은 값을 반환하지 않으므로, x 가 바인딩할 대상이 없습니다. 이것은 C나 Ruby처럼 대입문이 대입된 값을 반환하는 언어와 다른 점입니다. 그런 언어에서는 x = y = 6 이라고 써서 x 와 y 모두 6 을 갖게 할 수 있지만, 러스트에서는 그렇게 되지 않습니다.

식은 값으로 평가되며, 여러분이 러스트에서 작성하게 될 코드의 대부분을 이룹니다. 예를 들어 5 + 6 같은 수학 연산은 11 이라는 값으로 평가되는 식입니다. 식은 문장의 일부가 될 수도 있습니다. 목록 3-1에서 let y = 6; 의 6 은 값 6 으로 평가되는 식입니다. 함수 호출도 식입니다. 매크로 호출도 식입니다. 중괄호로 만든 새 스코프 블록도 식입니다. 예를 들면 다음과 같습니다.

파일명: src/main.rs

fn main() {
    let y = {
        let x = 3;
        x + 1
    };

    println!("The value of y is: {y}");
}

다음 식:

{
    let x = 3;
    x + 1
}

은 이 경우 4 로 평가되는 블록입니다. 그 값이 let 문의 일부로서 y 에 바인딩됩니다. 지금까지 본 대부분의 줄과 달리, x + 1 줄 끝에는 세미콜론이 없다는 점에 주목하세요. 식에는 세미콜론이 붙지 않습니다. 식 끝에 세미콜론을 붙이면 그 식은 문장이 되고, 더 이상 값을 반환하지 않게 됩니다. 다음으로 함수 반환값과 식을 살펴볼 때 이 점을 기억하세요.

반환값을 가지는 함수

함수는 자신을 호출한 코드에 값을 돌려줄 수 있습니다. 반환값에 이름을 붙이지는 않지만, 화살표(->) 뒤에 그 타입은 반드시 선언해야 합니다. 러스트에서 함수의 반환값은 함수 본문 블록의 마지막 식의 값과 같습니다. return 키워드와 값을 사용해 함수에서 일찍 빠져나올 수도 있지만, 대부분의 함수는 마지막 식을 암묵적으로 반환합니다. 다음은 값을 반환하는 함수의 예입니다.

파일명: src/main.rs

fn five() -> i32 {
    5
}

fn main() {
    let x = five();

    println!("The value of x is: {x}");
}

five 함수 안에는 함수 호출도, 매크로도, 심지어 let 문도 없습니다. 숫자 5 하나만 있을 뿐입니다. 하지만 이것은 러스트에서 완전히 유효한 함수입니다. 함수의 반환 타입도 -> i32 로 명시되어 있다는 점에 주목하세요. 이 코드를 실행해 보면, 출력은 다음과 같을 것입니다.

$ cargo run
   Compiling functions v0.1.0 (file:///projects/functions)
    Finished `dev` profile [unoptimized + debuginfo] target(s) in 0.30s
     Running `target/debug/functions`
The value of x is: 5

five 안의 5 는 함수의 반환값이며, 그래서 반환 타입이 i32 인 것입니다. 이것을 조금 더 자세히 봅시다. 중요한 점이 두 가지 있습니다. 첫째, let x = five(); 라는 줄은 함수 반환값을 사용해 변수를 초기화하고 있음을 보여 줍니다. 함수 five 는 5 를 반환하므로, 이 줄은 사실 다음과 같습니다.

#![allow(unused)]
fn main() {
let x = 5;
}

둘째, five 함수는 매개변수가 없고 반환값의 타입을 정의하지만, 함수 본문은 세미콜론이 없는 5 하나뿐입니다. 그 이유는 우리가 그 식의 값을 그대로 반환하고 싶기 때문입니다.

다른 예를 하나 더 봅시다.

파일명: src/main.rs

fn main() {
    let x = plus_one(5);

    println!("The value of x is: {x}");
}

fn plus_one(x: i32) -> i32 {
    x + 1
}

이 코드를 실행하면 The value of x is: 6 이 출력됩니다. 그런데 x + 1 이 들어 있는 줄 끝에 세미콜론을 붙여 식을 문장으로 바꾸면 어떻게 될까요?

파일명: src/main.rs

fn main() {
    let x = plus_one(5);

    println!("The value of x is: {x}");
}

fn plus_one(x: i32) -> i32 {
    x + 1;
}

이 코드를 컴파일하면 다음과 같은 오류가 납니다.

$ cargo run
   Compiling functions v0.1.0 (file:///projects/functions)
error[E0308]: mismatched types
 --> src/main.rs:7:24
  |
7 | fn plus_one(x: i32) -> i32 {
  |    --------            ^^^ expected `i32`, found `()`
  |    |
  |    implicitly returns `()` as its body has no tail or `return` expression
8 |     x + 1;
  |          - help: remove this semicolon to return this value

For more information about this error, try `rustc --explain E0308`.
error: could not compile `functions` (bin "functions") due to 1 previous error

핵심 오류 메시지인 mismatched types 는 이 코드의 본질적인 문제를 드러냅니다. 함수 plus_one 의 정의는 i32 를 반환하겠다고 말하지만, 문장은 값으로 평가되지 않으며, 이는 unit 타입 () 로 표현됩니다. 따라서 아무 값도 반환되지 않고, 이것이 함수 정의와 모순되어 오류가 발생하는 것입니다. 이 출력에서 러스트는 문제를 고칠 수 있도록 도움말도 제공합니다. 세미콜론을 제거하라고 제안하는데, 그렇게 하면 오류가 해결됩니다.

주석

주석

모든 프로그래머는 자신의 코드를 이해하기 쉽게 만들려고 노력하지만, 때로는 추가 설명이 필요합니다. 이런 경우 프로그래머는 소스 코드 안에 주석(comments) 을 남깁니다. 컴파일러는 이 주석을 무시하지만, 소스 코드를 읽는 사람에게는 유용할 수 있습니다.

다음은 간단한 주석입니다.

#![allow(unused)]
fn main() {
// hello, world
}

러스트에서 관용적인 주석 스타일은 슬래시 두 개로 주석을 시작하고, 그 주석은 줄 끝까지 이어집니다. 한 줄을 넘어가는 주석은 다음처럼 각 줄마다 // 를 넣어야 합니다.

#![allow(unused)]
fn main() {
// So we're doing something complicated here, long enough that we need
// multiple lines of comments to do it! Whew! Hopefully, this comment will
// explain what's going on.
}

주석은 코드가 있는 줄의 끝에 둘 수도 있습니다.

파일명: src/main.rs

fn main() {
    let lucky_number = 7; // I'm feeling lucky today
}

하지만 보통은 주석을 설명하려는 코드 위의 별도 줄에 두는 형식을 더 자주 보게 됩니다.

파일명: src/main.rs

fn main() {
    // I'm feeling lucky today
    let lucky_number = 7;
}

러스트에는 또 다른 종류의 주석인 문서화 주석도 있습니다. 이것은 14장의 “Crates.io에 크레이트 배포하기” 절에서 다룹니다.

제어 흐름

제어 흐름

조건이 true 인지에 따라 어떤 코드를 실행할 수 있는 능력과, 조건이 true 인 동안 어떤 코드를 반복해서 실행할 수 있는 능력은 대부분의 프로그래밍 언어에서 기본이 되는 구성 요소입니다. 러스트 코드의 실행 흐름을 제어하게 해 주는 가장 흔한 구문은 if 식과 루프입니다.

if 식

if 식은 조건에 따라 코드를 분기하게 해 줍니다. 조건을 제공한 뒤 “이 조건이 성립하면 이 코드 블록을 실행하고, 그렇지 않으면 이 코드 블록을 실행하지 않는다”라고 말하는 방식입니다.

if 식을 실험하기 위해 projects 디렉터리에 branches 라는 새 프로젝트를 만드세요. src/main.rs 파일에 다음 내용을 입력합니다.

파일명: src/main.rs

fn main() {
    let number = 3;

    if number < 5 {
        println!("condition was true");
    } else {
        println!("condition was false");
    }
}

모든 if 식은 if 키워드로 시작하고, 그 뒤에 조건이 옵니다. 여기서는 number 변수가 5보다 작은 값인지 확인합니다. 조건이 true 일 때 실행할 코드 블록은 조건 바로 뒤 중괄호 안에 둡니다. if 식에서 조건과 연결된 코드 블록은 2장의 “추측값을 비밀 숫자와 비교하기” 절에서 다룬 match 식의 arm과 비슷하게, 때때로 arm 이라고 부르기도 합니다.

필요하다면 여기서처럼 else 식을 포함해, 조건이 false 로 평가될 때 실행할 대체 코드 블록을 줄 수도 있습니다. else 식을 제공하지 않은 상태에서 조건이 false 가 되면, 프로그램은 if 블록을 건너뛰고 다음 코드로 그냥 넘어갑니다.

이 코드를 실행해 보세요. 다음과 같은 출력이 나타납니다.

$ cargo run
   Compiling branches v0.1.0 (file:///projects/branches)
    Finished `dev` profile [unoptimized + debuginfo] target(s) in 0.31s
     Running `target/debug/branches`
condition was true

이번에는 number 값을 조건이 false 가 되도록 바꿔서 어떤 일이 일어나는지 확인해 봅시다.

fn main() {
    let number = 7;

    if number < 5 {
        println!("condition was true");
    } else {
        println!("condition was false");
    }
}

프로그램을 다시 실행하고 출력을 확인해 보세요.

$ cargo run
   Compiling branches v0.1.0 (file:///projects/branches)
    Finished `dev` profile [unoptimized + debuginfo] target(s) in 0.31s
     Running `target/debug/branches`
condition was false

또 하나 주목할 점은, 이 코드의 조건은 반드시 bool 이어야 한다는 것입니다. 조건이 bool 이 아니면 오류가 발생합니다. 예를 들어 다음 코드를 실행해 보세요.

파일명: src/main.rs

fn main() {
    let number = 3;

    if number {
        println!("number was three");
    }
}

이번에는 if 조건이 값 3 으로 평가되므로, 러스트는 오류를 냅니다.

$ cargo run
   Compiling branches v0.1.0 (file:///projects/branches)
error[E0308]: mismatched types
 --> src/main.rs:4:8
  |
4 |     if number {
  |        ^^^^^^ expected `bool`, found integer

For more information about this error, try `rustc --explain E0308`.
error: could not compile `branches` (bin "branches") due to 1 previous error

오류는 러스트가 bool 을 기대했지만 정수를 받았다고 알려 줍니다. Ruby나 JavaScript 같은 언어와 달리, 러스트는 불리언이 아닌 타입을 자동으로 불리언으로 변환하지 않습니다. if 의 조건으로는 항상 명시적으로 불리언을 제공해야 합니다. 예를 들어 숫자가 0 이 아닐 때만 if 코드 블록을 실행하고 싶다면, 다음처럼 if 식을 바꿀 수 있습니다.

파일명: src/main.rs

fn main() {
    let number = 3;

    if number != 0 {
        println!("number was something other than zero");
    }
}

이 코드를 실행하면 number was something other than zero 가 출력됩니다.

else if 로 여러 조건 다루기

if 와 else 를 결합한 else if 식으로 여러 조건을 사용할 수 있습니다. 예를 들면 다음과 같습니다.

파일명: src/main.rs

fn main() {
    let number = 6;

    if number % 4 == 0 {
        println!("number is divisible by 4");
    } else if number % 3 == 0 {
        println!("number is divisible by 3");
    } else if number % 2 == 0 {
        println!("number is divisible by 2");
    } else {
        println!("number is not divisible by 4, 3, or 2");
    }
}

이 프로그램은 네 가지 가능한 경로를 가집니다. 실행하면 다음과 같은 출력이 보일 것입니다.

$ cargo run
   Compiling branches v0.1.0 (file:///projects/branches)
    Finished `dev` profile [unoptimized + debuginfo] target(s) in 0.31s
     Running `target/debug/branches`
number is divisible by 3

이 프로그램이 실행되면 각 if 식을 차례로 검사하고, 조건이 true 로 평가되는 첫 번째 본문만 실행합니다. 예를 들어 6은 2로도 나누어떨어지지만, number is divisible by 2 는 출력되지 않습니다. 마찬가지로 else 블록의 number is not divisible by 4, 3, or 2 도 보이지 않습니다. 러스트는 첫 번째 true 조건에 해당하는 블록만 실행하고, 그 하나를 찾고 나면 나머지는 검사하지 않기 때문입니다.

else if 식이 너무 많아지면 코드가 복잡해 보일 수 있으므로, 하나보다 많아질 것 같다면 리팩터링을 고려해 보는 것이 좋습니다. 이런 경우를 위해 6장에서는 match 라는 강력한 러스트 분기 구문을 설명합니다.

let 문 안에서 if 사용하기

if 는 식이기 때문에, 목록 3-2처럼 let 문 오른쪽에서 사용해 결과를 변수에 대입할 수 있습니다.

fn main() {
    let condition = true;
    let number = if condition { 5 } else { 6 };

    println!("The value of number is: {number}");
}

number 변수는 if 식의 결과에 따라 값이 바인딩됩니다. 어떤 일이 일어나는지 보기 위해 이 코드를 실행해 보세요.

$ cargo run
   Compiling branches v0.1.0 (file:///projects/branches)
    Finished `dev` profile [unoptimized + debuginfo] target(s) in 0.30s
     Running `target/debug/branches`
The value of number is: 5

코드 블록은 내부의 마지막 식으로 평가된다는 점, 그리고 숫자 하나만 있는 것도 식이라는 점을 기억하세요. 이 경우 전체 if 식의 값은 어느 코드 블록이 실행되느냐에 따라 달라집니다. 따라서 if 의 각 arm에서 결과가 될 수 있는 값들은 모두 같은 타입이어야 합니다. 목록 3-2에서는 if arm과 else arm 모두 i32 정수를 결과로 내놓았습니다. 만약 아래 예시처럼 타입이 맞지 않으면 오류가 납니다.

파일명: src/main.rs

fn main() {
    let condition = true;

    let number = if condition { 5 } else { "six" };

    println!("The value of number is: {number}");
}

이 코드를 컴파일하면 오류가 발생합니다. if 와 else arm이 서로 호환되지 않는 타입의 값을 가지며, 러스트는 프로그램 어디에서 문제가 생겼는지를 정확히 알려 줍니다.

$ cargo run
   Compiling branches v0.1.0 (file:///projects/branches)
error[E0308]: `if` and `else` have incompatible types
 --> src/main.rs:4:44
  |
4 |     let number = if condition { 5 } else { "six" };
  |                                 -          ^^^^^ expected integer, found `&str`
  |                                 |
  |                                 expected because of this

For more information about this error, try `rustc --explain E0308`.
error: could not compile `branches` (bin "branches") due to 1 previous error

if 블록 안의 식은 정수로 평가되고, else 블록 안의 식은 문자열로 평가됩니다. 이것은 동작할 수 없습니다. 변수는 하나의 단일 타입만 가져야 하고, 러스트는 컴파일 시점에 number 변수의 타입이 무엇인지 확실히 알아야 하기 때문입니다. number 의 타입을 알고 있어야 컴파일러가 number 를 사용하는 모든 곳에서 그 타입이 유효한지 검사할 수 있습니다. 만약 number 의 타입이 런타임에 가서야 결정된다면 컴파일러는 훨씬 더 복잡해지고, 어떤 변수든 여러 가상의 타입을 추적해야 하므로 코드에 대해 보장할 수 있는 것도 줄어들게 됩니다.

루프로 반복하기

어떤 코드 블록을 한 번 이상 실행해야 하는 경우는 자주 있습니다. 이를 위해 러스트는 여러 가지 루프(loop) 를 제공합니다. 루프는 루프 본문 안의 코드를 끝까지 실행한 뒤 즉시 처음으로 다시 돌아갑니다. 루프를 실험해 보기 위해 loops 라는 새 프로젝트를 만들어 봅시다.

러스트에는 세 종류의 루프가 있습니다. loop, while, for 입니다. 하나씩 모두 살펴보겠습니다.

loop 로 코드 반복하기

loop 키워드는 어떤 코드 블록을 영원히, 혹은 여러분이 명시적으로 멈추라고 말할 때까지 계속 반복해서 실행하라고 러스트에게 지시합니다.

예를 들어 loops 디렉터리의 src/main.rs 파일을 다음처럼 바꿔 봅시다.

파일명: src/main.rs

fn main() {
    loop {
        println!("again!");
    }
}

이 프로그램을 실행하면, 우리가 수동으로 중지할 때까지 again! 이 계속 반복해서 출력됩니다. 대부분의 터미널은 무한 루프에 빠진 프로그램을 중단하기 위해 ctrl-C 키보드 단축키를 지원합니다. 한 번 시도해 보세요.

$ cargo run
   Compiling loops v0.1.0 (file:///projects/loops)
    Finished `dev` profile [unoptimized + debuginfo] target(s) in 0.08s
     Running `target/debug/loops`
again!
again!
again!
again!
^Cagain!

^C 기호는 여러분이 ctrl-C 를 눌렀다는 뜻입니다.

인터럽트 신호를 받았을 때 루프가 어느 지점에 있었는지에 따라, ^C 뒤에 again! 이 보일 수도 있고 보이지 않을 수도 있습니다.

다행히 러스트는 코드 안에서 루프를 빠져나오는 방법도 제공합니다. 루프 안에 break 키워드를 두면 언제 루프 실행을 멈출지를 프로그램에 알려 줄 수 있습니다. 2장의 “정답을 맞히면 종료하기” 절에서 사용자가 정답을 맞혔을 때 프로그램을 종료하기 위해 이것을 이미 써 본 적이 있습니다.

숫자 맞히기 게임에서는 continue 도 사용했었는데, 루프 안에서 continue 는 현재 반복에서 남은 코드를 건너뛰고 다음 반복으로 가라고 프로그램에 지시합니다.

루프에서 값 반환하기

loop 의 한 가지 활용법은, 실패할 수 있다는 것을 알고 있는 작업을 재시도하는 것입니다. 예를 들어 어떤 스레드가 작업을 끝냈는지 계속 확인하는 경우가 그렇습니다. 그리고 그 작업 결과를 루프 밖의 나머지 코드에 전달해야 할 수도 있습니다. 이를 위해 루프를 멈추는 break 식 뒤에 반환하고 싶은 값을 붙일 수 있습니다. 그러면 그 값이 루프 밖으로 반환되어 이후 코드에서 사용할 수 있습니다. 예를 들면 다음과 같습니다.

fn main() {
    let mut counter = 0;

    let result = loop {
        counter += 1;

        if counter == 10 {
            break counter * 2;
        }
    };

    println!("The result is {result}");
}

루프 전에 counter 라는 변수를 선언하고 0 으로 초기화합니다. 그런 다음 루프가 반환하는 값을 담기 위해 result 라는 변수를 선언합니다. 루프의 각 반복마다 counter 에 1 을 더하고, 그 뒤 counter 가 10 과 같은지 확인합니다. 같다면 break 키워드와 함께 counter * 2 라는 값을 사용합니다. 루프 뒤에는 세미콜론을 붙여, 이 값이 result 에 대입되는 문장을 끝냅니다. 마지막으로 result 의 값을 출력하는데, 이 경우 값은 20 입니다.

루프 안에서 return 을 사용할 수도 있습니다. break 가 현재 루프만 빠져나가는 반면, return 은 항상 현재 함수 전체를 종료합니다.

루프 레이블로 구분하기

루프 안에 또 다른 루프가 있다면, break 와 continue 는 그 지점에서 가장 안쪽 루프에 적용됩니다. 필요하다면 루프에 레이블(loop label) 을 지정하고, break 나 continue 와 함께 사용해 가장 안쪽 루프가 아니라 그 레이블이 붙은 루프에 적용되게 할 수 있습니다. 루프 레이블은 반드시 작은따옴표 하나로 시작해야 합니다. 다음은 중첩 루프 두 개가 있는 예입니다.

fn main() {
    let mut count = 0;
    'counting_up: loop {
        println!("count = {count}");
        let mut remaining = 10;

        loop {
            println!("remaining = {remaining}");
            if remaining == 9 {
                break;
            }
            if count == 2 {
                break 'counting_up;
            }
            remaining -= 1;
        }

        count += 1;
    }
    println!("End count = {count}");
}

바깥쪽 루프에는 'counting_up 이라는 레이블이 있고, 0에서 2까지 올라갑니다. 레이블이 없는 안쪽 루프는 10에서 9로 내려갑니다. 레이블을 지정하지 않은 첫 번째 break 는 안쪽 루프만 종료합니다. break 'counting_up; 문은 바깥쪽 루프를 종료합니다. 이 코드는 다음을 출력합니다.

$ cargo run
   Compiling loops v0.1.0 (file:///projects/loops)
    Finished `dev` profile [unoptimized + debuginfo] target(s) in 0.58s
     Running `target/debug/loops`
count = 0
remaining = 10
remaining = 9
count = 1
remaining = 10
remaining = 9
count = 2
remaining = 10
End count = 2

while 로 조건부 루프 단순화하기

프로그램은 루프 안에서 어떤 조건을 평가해야 하는 경우가 많습니다. 그 조건이 true 인 동안 루프가 실행되고, 조건이 더 이상 true 가 아니게 되면 프로그램은 break 를 호출해 루프를 멈춥니다. 이런 동작은 loop, if, else, break 를 조합해서 구현할 수도 있습니다. 원한다면 직접 그렇게 한 번 만들어 봐도 좋습니다. 하지만 이 패턴은 너무 흔해서, 러스트는 이를 위한 내장 언어 구성 요소인 while 루프를 제공합니다. 목록 3-3에서는 while 을 사용해 프로그램을 세 번 반복하며 카운트다운하고, 루프가 끝난 뒤 메시지를 출력하고 종료합니다.

fn main() {
    let mut number = 3;

    while number != 0 {
        println!("{number}!");

        number -= 1;
    }

    println!("LIFTOFF!!!");
}

이 구문은 loop, if, else, break 를 썼을 때 필요했을 많은 중첩을 없애 주며, 훨씬 더 명확합니다. 조건이 true 로 평가되는 동안에는 코드가 실행되고, 그렇지 않으면 루프를 빠져나옵니다.

for 로 컬렉션 순회하기

배열 같은 컬렉션의 요소들을 순회할 때 while 구문을 선택할 수도 있습니다. 예를 들어 목록 3-4의 루프는 배열 a 의 각 요소를 출력합니다.

fn main() {
    let a = [10, 20, 30, 40, 50];
    let mut index = 0;

    while index < 5 {
        println!("the value is: {}", a[index]);

        index += 1;
    }
}

여기서 코드는 배열 요소를 따라가며 증가합니다. 인덱스 0 에서 시작해, 배열의 마지막 인덱스에 도달할 때까지 반복합니다(즉 index < 5 가 더 이상 true 가 아닐 때까지). 이 코드를 실행하면 배열의 모든 요소가 출력됩니다.

$ cargo run
   Compiling loops v0.1.0 (file:///projects/loops)
    Finished `dev` profile [unoptimized + debuginfo] target(s) in 0.32s
     Running `target/debug/loops`
the value is: 10
the value is: 20
the value is: 30
the value is: 40
the value is: 50

예상한 대로 배열의 다섯 값이 모두 터미널에 나타납니다. index 가 어느 시점에 5 가 되더라도, 배열에서 여섯 번째 값을 가져오려 시도하기 전에 루프가 멈춥니다.

하지만 이 접근법은 오류가 나기 쉽습니다. 인덱스 값이나 검사 조건이 잘못되면 프로그램이 패닉을 일으킬 수 있기 때문입니다. 예를 들어 배열 a 정의를 네 개 요소로 바꾸고도 조건을 while index < 4 로 갱신하는 것을 잊어버리면 코드가 패닉을 일으킵니다. 또한 이 방식은 느리기도 합니다. 컴파일러가 루프의 각 반복마다 인덱스가 배열 범위 안에 있는지 조건 검사하는 런타임 코드를 추가하기 때문입니다.

더 간결한 대안으로 for 루프를 사용하면 컬렉션의 각 항목에 대해 코드를 실행할 수 있습니다. for 루프는 목록 3-5와 같습니다.

fn main() {
    let a = [10, 20, 30, 40, 50];

    for element in a {
        println!("the value is: {element}");
    }
}

이 코드를 실행하면 목록 3-4와 같은 출력을 보게 됩니다. 더 중요한 것은, 이제 코드가 더 안전해졌고 배열 끝을 넘어가거나 일부 요소를 빠뜨리는 버그 가능성도 사라졌다는 점입니다. for 루프에서 생성되는 머신 코드는 매 반복마다 인덱스를 배열 길이와 비교할 필요가 없기 때문에 더 효율적일 수도 있습니다.

for 루프를 사용하면 배열 값 개수를 바꿀 때도 목록 3-4 방식처럼 다른 코드까지 함께 바꾸는 것을 기억할 필요가 없습니다.

안전성과 간결성 덕분에 for 루프는 러스트에서 가장 흔히 쓰이는 반복 구문입니다. 심지어 목록 3-3의 카운트다운 예시처럼 특정 횟수만큼 코드를 실행하고 싶을 때도, 대부분의 Rustacean은 while 대신 for 루프를 사용할 것입니다. 그 방법은 표준 라이브러리가 제공하는 Range 를 사용하는 것입니다. Range 는 한 숫자에서 시작해 다른 숫자 직전까지의 수를 순서대로 생성합니다.

카운트다운을 for 루프와, 아직 설명하지 않은 또 다른 메서드인 rev 를 사용해 범위를 뒤집는 방식으로 작성하면 다음과 같습니다.

파일명: src/main.rs

fn main() {
    for number in (1..4).rev() {
        println!("{number}!");
    }
    println!("LIFTOFF!!!");
}

이 코드가 조금 더 보기 좋지 않나요?

정리

여기까지 왔다면 잘해낸 것입니다! 꽤 큰 장이었습니다. 여러분은 변수, 스칼라 및 복합 데이터 타입, 함수, 주석, if 식, 루프를 배웠습니다! 이 장에서 다룬 개념을 연습해 보고 싶다면, 다음과 같은 프로그램을 만들어 보세요.

• 화씨와 섭씨 사이 온도 변환하기
• n 번째 피보나치 수 구하기
• 노래의 반복 구조를 활용해 크리스마스 캐럴 “The Twelve Days of Christmas” 가사 출력하기

이제 다음으로 넘어갈 준비가 되었다면, 다른 대부분의 프로그래밍 언어에는 흔히 존재하지 않는 러스트의 개념인 소유권에 대해 이야기하겠습니다.

소유권 이해하기

소유권은 러스트에서 가장 독특한 기능이며, 언어의 나머지 부분 전반에 깊은 영향을 미칩니다. 소유권 덕분에 러스트는 가비지 컬렉터 없이도 메모리 안전성을 보장할 수 있으므로, 소유권이 어떻게 동작하는지 이해하는 것이 중요합니다. 이 장에서는 소유권과 더불어 그와 관련된 몇 가지 기능, 즉 대여, 슬라이스, 그리고 러스트가 메모리에 데이터를 어떻게 배치하는지도 함께 다룹니다.

소유권이란 무엇인가?

소유권이란 무엇인가?

소유권(ownership) 은 러스트 프로그램이 메모리를 관리하는 방식을 지배하는 규칙 집합입니다. 모든 프로그램은 실행 중 컴퓨터 메모리를 어떻게 사용할지 관리해야 합니다. 어떤 언어는 프로그램이 실행되는 동안 더 이상 쓰이지 않는 메모리를 정기적으로 찾아 정리하는 가비지 컬렉션을 사용합니다. 또 다른 언어에서는 프로그래머가 메모리를 명시적으로 할당하고 해제해야 합니다. 러스트는 세 번째 접근법을 사용합니다. 컴파일러가 검사하는 규칙 집합을 가진 소유권 시스템을 통해 메모리를 관리합니다. 이 규칙 가운데 하나라도 어기면 프로그램은 컴파일되지 않습니다. 소유권의 어떤 기능도 프로그램이 실행되는 동안 성능을 느리게 만들지 않습니다.

소유권은 많은 프로그래머에게 새로운 개념이기 때문에 익숙해지는 데 시간이 조금 걸립니다. 좋은 소식은, 러스트와 소유권 규칙에 익숙해질수록 안전하고 효율적인 코드를 자연스럽게 작성하는 일이 점점 쉬워진다는 점입니다. 계속 연습해 보세요!

소유권을 이해하게 되면, 러스트를 독특하게 만드는 기능들을 이해할 수 있는 단단한 기초를 얻게 됩니다. 이 장에서는 아주 흔한 자료구조인 문자열을 중심으로 몇 가지 예를 직접 따라가며 소유권을 배워 보겠습니다.

소유권 규칙

먼저 소유권 규칙을 살펴봅시다. 뒤이어 나오는 예제를 따라가는 동안 다음 규칙을 계속 머릿속에 두세요.

• 러스트의 각 값은 소유자(owner) 를 가진다.
• 어떤 값에는 한 시점에 오직 하나의 소유자만 있을 수 있다.
• 소유자가 스코프를 벗어나면 값은 버려진다(drop 된다).

변수 스코프

이제 기본적인 러스트 문법을 지나왔으므로, 예제마다 fn main() { 전체를 계속 포함하지는 않겠습니다. 직접 따라 하신다면 아래 예제들을 수동으로 main 함수 안에 넣어 주세요. 이렇게 하면 보일러플레이트 코드보다 실제 핵심에 집중할 수 있어 예제가 좀 더 간결해집니다.

소유권의 첫 번째 예로, 몇 가지 변수의 스코프를 살펴보겠습니다. 스코프(scope) 는 어떤 항목이 유효한 프로그램 구간을 뜻합니다. 다음 변수를 보세요.

#![allow(unused)]
fn main() {
let s = "hello";
}

변수 s 는 문자열 리터럴을 가리킵니다. 이 문자열 값은 프로그램 텍스트 안에 하드코딩되어 있습니다. 이 변수는 선언된 시점부터 현재 스코프가 끝날 때까지 유효합니다. 목록 4-1은 변수 s 가 어디서 유효한지를 주석으로 표시한 프로그램입니다.

fn main() {
    {                      // s is not valid here, since it's not yet declared
        let s = "hello";   // s is valid from this point forward

        // do stuff with s
    }                      // this scope is now over, and s is no longer valid
}

즉, 여기에는 두 가지 중요한 시점이 있습니다.

• s 가 스코프 안으로 들어오면 유효해집니다.
• s 는 스코프 밖으로 나갈 때까지 유효합니다.

이 시점에서 스코프와 변수의 유효 기간 사이 관계는 다른 프로그래밍 언어와 비슷합니다. 이제 여기에 String 타입을 도입해 이해를 확장해 보겠습니다.

String 타입

소유권 규칙을 설명하려면 3장의 [“데이터 타입”] 절에서 다룬 타입들보다 좀 더 복잡한 데이터 타입이 필요합니다. 앞서 다룬 타입들은 크기가 알려져 있고, 스택에 저장할 수 있으며, 스코프가 끝나면 스택에서 제거할 수 있고, 다른 코드가 같은 값을 다른 스코프에서 사용해야 할 때도 빠르고 단순하게 복사해 독립적인 새 인스턴스를 만들 수 있습니다. 하지만 우리는 힙에 저장되는 데이터를 살펴보고, 러스트가 언제 그 데이터를 정리해야 하는지 어떻게 아는지 알아보고 싶습니다. String 타입은 이 목적에 아주 좋은 예입니다.

여기서는 String 의 여러 측면 중 소유권과 관련된 부분에 집중하겠습니다. 이런 특징은 표준 라이브러리가 제공하는 다른 복잡한 데이터 타입이나 여러분이 직접 만든 타입에도 똑같이 적용됩니다. 소유권과 직접 관련 없는 String 의 성질은 8장 에서 다룹니다.

우리는 이미 문자열 리터럴을 보았습니다. 문자열 리터럴은 문자열 값이 프로그램 코드 안에 하드코딩되어 있습니다. 문자열 리터럴은 편리하지만, 우리가 텍스트를 다루고 싶어 하는 모든 상황에 적합하지는 않습니다. 한 가지 이유는 불변이라는 점입니다. 또 다른 이유는, 모든 문자열 값을 우리가 코드를 작성하는 시점에 미리 알 수는 없기 때문입니다. 예를 들어 사용자 입력을 받아 저장하고 싶다면 어떨까요? 이런 상황을 위해 러스트에는 String 타입이 있습니다. 이 타입은 힙에 할당된 데이터를 관리하므로, 컴파일 시점에 길이를 알 수 없는 텍스트 양도 저장할 수 있습니다. 문자열 리터럴에서 String 을 만들려면 다음처럼 from 함수를 사용합니다.

#![allow(unused)]
fn main() {
let s = String::from("hello");
}

이중 콜론 :: 연산자는 from 함수를 string_from 같은 별도 이름으로 쓰는 대신 String 타입 아래에 네임스페이스된 함수로 사용하게 해 줍니다. 이 문법은 5장의 “메서드” 절에서, 그리고 7장의 “모듈 트리의 항목을 경로로 가리키기” 절에서 모듈 네임스페이싱을 설명할 때 더 다루겠습니다.

이런 종류의 문자열은 변경할 수 있습니다.

fn main() {
    let mut s = String::from("hello");

    s.push_str(", world!"); // push_str() appends a literal to a String

    println!("{s}"); // this will print `hello, world!`
}

그렇다면 여기서는 무엇이 다를까요? 왜 String 은 바꿀 수 있는데 문자열 리터럴은 그럴 수 없을까요? 차이는 이 두 타입이 메모리를 다루는 방식에 있습니다.

메모리와 할당

문자열 리터럴의 경우, 내용물을 컴파일 시점에 알 수 있으므로 그 텍스트는 최종 실행 파일 안에 직접 하드코딩됩니다. 그래서 문자열 리터럴은 빠르고 효율적입니다. 하지만 이런 성질은 문자열 리터럴이 불변이라는 사실에서만 나옵니다. 안타깝게도, 컴파일 시점에 크기를 알 수 없고 실행 중에도 크기가 바뀔 수 있는 텍스트 조각 하나하나를 모두 바이너리 안의 메모리 덩어리로 넣어 둘 수는 없습니다.

String 타입이 가변적이고 커질 수 있는 텍스트를 지원하려면, 컴파일 시점에 크기를 알 수 없는 메모리 양을 힙에 할당해 내용을 저장해야 합니다. 이는 다음을 의미합니다.

• 런타임에 메모리 할당자에게 메모리를 요청해야 합니다.
• String 사용이 끝났을 때 그 메모리를 할당자에게 돌려주는 방법이 필요합니다.

첫 번째는 우리가 처리합니다. String::from 을 호출하면, 그 구현은 필요한 메모리를 요청합니다. 이것은 거의 모든 프로그래밍 언어에서 공통적입니다.

하지만 두 번째는 다릅니다. 가비지 컬렉터(GC) 가 있는 언어에서는 GC가 더 이상 사용되지 않는 메모리를 추적하고 정리해 주므로, 우리는 그 과정을 의식하지 않아도 됩니다. GC가 없는 대부분의 언어에서는 메모리가 더 이상 쓰이지 않는 시점을 우리가 직접 알아내고, 메모리를 요청할 때 했던 것처럼 명시적으로 해제하는 코드를 호출해야 합니다. 이것을 정확히 하는 일은 역사적으로 매우 어려운 프로그래밍 문제였습니다. 잊으면 메모리를 낭비하고, 너무 일찍 해제하면 잘못된 변수가 남으며, 두 번 해제하면 그것도 버그입니다. 정확히 하나의 allocate 와 정확히 하나의 free 를 짝지어야 합니다.

러스트는 다른 길을 택합니다. 메모리는 그것을 소유한 변수가 스코프를 벗어날 때 자동으로 반환됩니다. 목록 4-1의 스코프 예제를 문자열 리터럴 대신 String 으로 바꿔 보면 다음과 같습니다.

fn main() {
    {
        let s = String::from("hello"); // s is valid from this point forward

        // do stuff with s
    }                                  // this scope is now over, and s is no
                                       // longer valid
}

여기에는 String 이 필요로 하는 메모리를 할당자에게 돌려줄 자연스러운 지점이 있습니다. 바로 s 가 스코프를 벗어나는 순간입니다. 변수가 스코프를 벗어나면, 러스트는 우리를 대신해 특별한 함수를 호출합니다. 이 함수의 이름은 drop 이며, String 작성자는 이 함수 안에 메모리를 반환하는 코드를 넣을 수 있습니다. 러스트는 닫는 중괄호를 만났을 때 drop 을 자동으로 호출합니다.

이 패턴은 러스트 코드가 작성되는 방식에 아주 큰 영향을 미칩니다. 지금은 단순해 보이지만, 힙에 할당한 같은 데이터를 여러 변수가 사용하려는 더 복잡한 상황에서는 코드 동작이 예상과 다를 수 있습니다. 이제 그런 상황을 몇 가지 살펴보겠습니다.

이동(move)으로 변수와 데이터가 상호작용하는 방식

러스트에서는 여러 변수가 같은 데이터와 다양한 방식으로 상호작용할 수 있습니다. 목록 4-2는 정수를 사용하는 예를 보여 줍니다.

fn main() {
    let x = 5;
    let y = x;
}

이 코드가 무엇을 하는지는 대략 짐작할 수 있습니다. “값 5 를 x 에 바인딩하고, 그다음 x 의 값을 복사해 y 에 바인딩한다”는 의미입니다. 실제로도 그렇습니다. 정수는 크기가 알려져 있고 고정된 단순한 값이므로, 두 개의 5 값 모두 스택에 푸시됩니다.

이제 String 버전을 봅시다.

fn main() {
    let s1 = String::from("hello");
    let s2 = s1;
}

겉보기에는 매우 비슷하므로, 같은 방식으로 동작할 것이라고 생각할 수도 있습니다. 즉 두 번째 줄이 s1 의 값을 복사해 s2 에 바인딩한다고 생각하기 쉽습니다. 하지만 실제로는 그렇지 않습니다.

String 이 내부적으로 어떻게 생겼는지 그림 4-1을 봅시다. String 은 왼쪽에 보이는 세 부분으로 이루어져 있습니다. 문자열 내용을 담는 메모리를 가리키는 포인터, 길이, 용량입니다. 이 데이터 묶음은 스택에 저장됩니다. 오른쪽에는 실제 문자열 내용을 담고 있는 힙 메모리가 있습니다.

그림 4-1: 값 "hello" 를 가진 String 이 s1 에 바인딩되었을 때의 메모리 표현

길이는 현재 String 내용이 사용하는 메모리 양(바이트 수)입니다. 용량은 String 이 할당자로부터 받은 총 메모리 양(바이트 수)입니다. 길이와 용량의 차이는 중요하지만, 여기서는 무시해도 괜찮습니다.

s1 을 s2 에 대입하면, String 데이터가 복사됩니다. 즉 스택에 있는 포인터, 길이, 용량이 복사됩니다. 포인터가 가리키는 힙 데이터 자체는 복사하지 않습니다. 다시 말해 메모리 표현은 그림 4-2처럼 됩니다.

그림 4-2: s1 의 포인터, 길이, 용량을 복사한 변수 s2 의 메모리 표현

메모리 표현은 그림 4-3처럼 되지 않습니다. 만약 러스트가 힙 데이터까지 함께 복사했다면 메모리는 그 그림처럼 보였을 것입니다. 그렇게 되면 힙 데이터가 클 때 s2 = s1 연산은 런타임 성능 측면에서 매우 비싸질 수 있습니다.

그림 4-3: 러스트가 힙 데이터까지 복사했다면 s2 = s1 이 보였을 또 다른 가능성

앞에서 변수가 스코프를 벗어나면 러스트가 자동으로 drop 함수를 호출해 그 변수의 힙 메모리를 정리한다고 말했습니다. 그런데 그림 4-2에서는 두 데이터 포인터가 같은 위치를 가리키고 있습니다. 이것은 문제가 됩니다. s2 와 s1 이 스코프를 벗어나면 둘 다 같은 메모리를 해제하려 할 것이기 때문입니다. 이것을 이중 해제(double free) 오류라고 하며, 앞에서 언급한 메모리 안전성 버그 중 하나입니다. 메모리를 두 번 해제하면 메모리 손상이 발생할 수 있고, 이는 보안 취약점으로 이어질 수도 있습니다.

메모리 안전성을 보장하기 위해, 러스트는 let s2 = s1; 이후 s1 을 더 이상 유효하지 않다고 간주합니다. 그러면 s1 이 스코프를 벗어날 때 러스트는 아무 것도 해제할 필요가 없어집니다. s2 가 만들어진 뒤 s1 을 사용하려 하면 어떤 일이 일어나는지 보세요. 동작하지 않습니다.

fn main() {
    let s1 = String::from("hello");
    let s2 = s1;

    println!("{s1}, world!");
}

러스트는 무효화된 참조를 사용하는 것을 막기 때문에 다음과 같은 오류를 받게 됩니다.

$ cargo run
   Compiling ownership v0.1.0 (file:///projects/ownership)
error[E0382]: borrow of moved value: `s1`
 --> src/main.rs:5:16
  |
2 |     let s1 = String::from("hello");
  |         -- move occurs because `s1` has type `String`, which does not implement the `Copy` trait
3 |     let s2 = s1;
  |              -- value moved here
4 |
5 |     println!("{s1}, world!");
  |                ^^ value borrowed here after move
  |
  = note: this error originates in the macro `$crate::format_args_nl` which comes from the expansion of the macro `println` (in Nightly builds, run with -Z macro-backtrace for more info)
help: consider cloning the value if the performance cost is acceptable
  |
3 |     let s2 = s1.clone();
  |                ++++++++

For more information about this error, try `rustc --explain E0382`.
error: could not compile `ownership` (bin "ownership") due to 1 previous error

다른 언어를 다룰 때 얕은 복사(shallow copy) 와 깊은 복사(deep copy) 라는 용어를 들어 본 적이 있다면, 데이터 자체를 복사하지 않고 포인터, 길이, 용량만 복사하는 이 개념은 얕은 복사와 비슷하게 들릴 것입니다. 하지만 러스트는 동시에 첫 번째 변수도 무효화하기 때문에, 이것을 얕은 복사라고 부르지 않고 이동(move) 이라고 부릅니다. 이 예에서는 s1 이 s2 로 이동되었다 고 말합니다. 실제 상태는 그림 4-4와 같습니다.

그림 4-4: s1 이 무효화된 뒤의 메모리 표현

이것으로 문제가 해결됩니다. 이제 유효한 것은 s2 하나뿐이므로, s2 가 스코프를 벗어날 때 그 하나만 메모리를 해제하면 됩니다.

더 나아가, 여기에는 하나의 설계 선택이 암시되어 있습니다. 러스트는 여러분의 데이터에 대해 “깊은” 복사를 자동으로 만들지 않습니다. 따라서 러스트에서의 자동 복사는 런타임 성능 측면에서 비용이 낮다고 가정할 수 있습니다.

스코프와 대입

이와 반대되는 방향의 관계도 있습니다. 스코프, 소유권, 그리고 drop 함수를 통한 메모리 해제 사이의 관계입니다. 기존 변수에 완전히 새로운 값을 대입하면, 러스트는 즉시 drop 을 호출해 원래 값의 메모리를 해제합니다. 예를 들어 다음 코드를 보세요.

fn main() {
    let mut s = String::from("hello");
    s = String::from("ahoy");

    println!("{s}, world!");
}

우리는 먼저 변수 s 를 선언하고 값 "hello" 인 String 에 바인딩합니다. 그리고 곧바로 "ahoy" 값을 가진 새로운 String 을 만들어 s 에 대입합니다. 이 시점에는 원래 힙 값 "hello" 를 가리키는 것은 아무 것도 없습니다. 그림 4-5는 지금의 스택과 힙 데이터를 보여 줍니다.

그림 4-5: 초기 값이 완전히 교체된 뒤의 메모리 표현

따라서 원래 문자열은 즉시 스코프를 벗어난 것으로 처리됩니다. 러스트는 그 값에 대해 drop 함수를 실행하고, 메모리는 곧바로 해제됩니다. 마지막에 값을 출력하면 결과는 "ahoy, world!" 가 됩니다.

clone 으로 변수와 데이터가 상호작용하는 방식

만약 String 의 힙 데이터를 스택 데이터뿐 아니라 깊게 복사하고 싶다면, clone 이라는 흔한 메서드를 사용할 수 있습니다. 메서드 문법은 5장에서 설명하겠지만, 메서드는 많은 프로그래밍 언어에서 공통적인 기능이기 때문에 이미 익숙할 수도 있습니다.

다음은 clone 메서드가 실제로 동작하는 예입니다.

fn main() {
    let s1 = String::from("hello");
    let s2 = s1.clone();

    println!("s1 = {s1}, s2 = {s2}");
}

이 코드는 잘 동작하며, 힙 데이터가 실제로 복사되는 그림 4-3의 동작을 명시적으로 만듭니다.

clone 호출을 보면, 여러분은 임의의 코드가 실행되고 있고 그 코드는 비쌀 수도 있다는 사실을 알 수 있습니다. 즉, 무언가 특별한 일이 일어나고 있음을 시각적으로 알려 주는 신호입니다.

스택에만 있는 데이터: Copy

아직 이야기하지 않은 한 가지가 더 있습니다. 정수를 사용하는 다음 코드는(일부는 목록 4-2에 이미 나왔습니다) 잘 동작하고 유효합니다.

fn main() {
    let x = 5;
    let y = x;

    println!("x = {x}, y = {y}");
}

하지만 이 코드는 방금 배운 내용과 모순되는 것처럼 보일 수 있습니다. clone 호출이 없는데도 x 는 여전히 유효하고 y 로 이동되지 않았기 때문입니다.

그 이유는 정수처럼 컴파일 시점에 크기가 알려진 타입은 전부 스택에 저장되기 때문입니다. 따라서 실제 값 자체를 복사하는 비용이 매우 작습니다. 즉, 변수 y 를 만든 뒤에도 x 가 유효하지 않아야 할 이유가 없습니다. 다시 말해, 이런 경우에는 깊은 복사와 얕은 복사의 차이가 없으므로, clone 을 호출해도 일반 복사와 다를 바가 없고 그냥 생략할 수 있습니다.

러스트에는 Copy 트레이트라는 특별한 표시가 있습니다. 정수처럼 스택에 저장되는 타입에 이 트레이트를 붙일 수 있습니다(10장에서 트레이트를 더 자세히 다룹니다). 어떤 타입이 Copy 트레이트를 구현하면, 그 타입을 사용하는 변수는 이동되지 않고 단순히 복사됩니다. 따라서 다른 변수에 대입한 뒤에도 계속 유효합니다.

러스트는 타입 자체나 그 일부라도 Drop 트레이트를 구현했다면, 그 타입에 Copy 주석을 붙이게 하지 않습니다. 값이 스코프를 벗어날 때 특별한 일이 일어나야 하는데, 그 타입에 Copy 를 추가하면 컴파일 시점 오류가 납니다. 여러분의 타입에 Copy 주석을 추가해 트레이트를 구현하는 방법은 부록 C의 [“파생 가능한 트레이트”] derivable-traits를 참고하세요.

그렇다면 어떤 타입이 Copy 트레이트를 구현할까요? 정확한 것은 해당 타입의 문서를 확인하면 되지만, 일반적으로 단순한 스칼라 값들의 묶음은 Copy 를 구현할 수 있고, 할당이 필요하거나 어떤 형태의 자원인 것은 구현할 수 없습니다. Copy 를 구현하는 타입에는 다음과 같은 것들이 있습니다.

• u32 같은 모든 정수 타입
• true, false 값을 가지는 불리언 타입 bool
• f64 같은 모든 부동소수점 타입
• 문자 타입 char
• 내부 요소들도 모두 Copy 를 구현하는 경우의 튜플. 예를 들어 (i32, i32) 는 Copy 이지만 (i32, String) 은 아닙니다.

소유권과 함수

값을 함수에 넘기는 동작은 값을 변수에 대입하는 동작과 비슷합니다. 변수를 함수에 넘기면 대입과 마찬가지로 이동되거나 복사됩니다. 목록 4-3은 변수들이 어디서 스코프 안으로 들어오고 어디서 나가는지 주석으로 표시한 예시입니다.

fn main() {
    let s = String::from("hello");  // s comes into scope

    takes_ownership(s);             // s's value moves into the function...
                                    // ... and so is no longer valid here

    let x = 5;                      // x comes into scope

    makes_copy(x);                  // Because i32 implements the Copy trait,
                                    // x does NOT move into the function,
                                    // so it's okay to use x afterward.

} // Here, x goes out of scope, then s. However, because s's value was moved,
  // nothing special happens.

fn takes_ownership(some_string: String) { // some_string comes into scope
    println!("{some_string}");
} // Here, some_string goes out of scope and `drop` is called. The backing
  // memory is freed.

fn makes_copy(some_integer: i32) { // some_integer comes into scope
    println!("{some_integer}");
} // Here, some_integer goes out of scope. Nothing special happens.

만약 takes_ownership 호출 뒤에 s 를 다시 사용하려 하면, 러스트는 컴파일 시점 오류를 냅니다. 이런 정적 검사가 실수를 막아 줍니다. main 에서 s 와 x 를 사용하는 코드를 직접 추가해 보면서, 어디까지 사용할 수 있고 어디서 소유권 규칙이 막는지 확인해 보세요.

반환값과 스코프

반환값도 소유권을 옮길 수 있습니다. 목록 4-4는 목록 4-3과 비슷한 주석을 붙여, 어떤 값을 반환하는 함수의 예를 보여 줍니다.

fn main() {
    let s1 = gives_ownership();        // gives_ownership moves its return
                                       // value into s1

    let s2 = String::from("hello");    // s2 comes into scope

    let s3 = takes_and_gives_back(s2); // s2 is moved into
                                       // takes_and_gives_back, which also
                                       // moves its return value into s3
} // Here, s3 goes out of scope and is dropped. s2 was moved, so nothing
  // happens. s1 goes out of scope and is dropped.

fn gives_ownership() -> String {       // gives_ownership will move its
                                       // return value into the function
                                       // that calls it

    let some_string = String::from("yours"); // some_string comes into scope

    some_string                        // some_string is returned and
                                       // moves out to the calling
                                       // function
}

// This function takes a String and returns a String.
fn takes_and_gives_back(a_string: String) -> String {
    // a_string comes into
    // scope

    a_string  // a_string is returned and moves out to the calling function
}

변수의 소유권은 항상 같은 패턴을 따릅니다. 어떤 값을 다른 변수에 대입하면 그 값은 이동됩니다. 힙 데이터를 포함한 변수가 스코프를 벗어나면, 그 데이터의 소유권이 다른 변수로 이동해 있지 않은 한 그 값은 drop 에 의해 정리됩니다.

이 방식은 동작하긴 하지만, 함수가 값을 받을 때마다 소유권을 가져가고 다시 돌려주는 것은 다소 번거롭습니다. 함수가 값을 사용만 하고 소유권은 가져가지 않게 하고 싶다면 어떻게 해야 할까요? 다시 사용하려면 우리가 넘긴 것은 결과와 별도로 그대로 다시 돌려받아야 한다는 점도 꽤 성가십니다.

러스트는 목록 4-5처럼 튜플을 사용해 여러 값을 반환할 수 있게 해 줍니다.

fn main() {
    let s1 = String::from("hello");

    let (s2, len) = calculate_length(s1);

    println!("The length of '{s2}' is {len}.");
}

fn calculate_length(s: String) -> (String, usize) {
    let length = s.len(); // len() returns the length of a String

    (s, length)
}

하지만 이것은 너무 장황하고, 원래 흔해야 할 개념치고는 일이 많습니다. 다행히 러스트는 소유권을 옮기지 않고도 값을 사용할 수 있게 해 주는 기능을 제공합니다. 바로 참조입니다.

참조와 대여

참조와 대여

목록 4-5의 튜플 코드가 가진 문제는, String 이 calculate_length 로 이동되었기 때문에 함수 호출 뒤에도 그 String 을 계속 사용하려면 호출한 함수 쪽으로 다시 String 을 반환해야 한다는 점입니다. 대신 String 값에 대한 참조를 넘길 수 있습니다. 참조는 어떤 주소를 따라가 그곳에 저장된 데이터에 접근할 수 있다는 점에서 포인터와 비슷합니다. 다만 그 데이터는 다른 어떤 변수가 소유하고 있습니다. 포인터와 달리 참조는, 그 참조가 살아 있는 동안 특정 타입의 유효한 값을 가리킨다는 것이 보장됩니다.

다음은 값의 소유권을 가져가는 대신, 객체에 대한 참조를 매개변수로 받는 calculate_length 함수를 정의하고 사용하는 방법입니다.

fn main() {
    let s1 = String::from("hello");

    let len = calculate_length(&s1);

    println!("The length of '{s1}' is {len}.");
}

fn calculate_length(s: &String) -> usize {
    s.len()
}

먼저 변수 선언과 함수 반환값에 있던 튜플 코드가 모두 사라졌다는 점에 주목하세요. 둘째, calculate_length 에 &s1 을 넘기고 있고, 함수 정의에서도 String 대신 &String 을 받고 있습니다. 이 앰퍼샌드들은 참조를 나타내며, 값의 소유권을 가져가지 않고도 그 값을 가리킬 수 있게 해 줍니다. 그림 4-6은 이 개념을 보여 줍니다.

그림 4-6: String s1 을 가리키는 &String s 도식

여기서 함수 호출을 좀 더 자세히 봅시다.

fn main() {
    let s1 = String::from("hello");

    let len = calculate_length(&s1);

    println!("The length of '{s1}' is {len}.");
}

fn calculate_length(s: &String) -> usize {
    s.len()
}

&s1 문법은 s1 의 값을 가리키는 참조를 만들게 해 주지만, 그 값을 소유하지는 않습니다. 참조는 소유권이 없기 때문에, 참조 자체가 더 이상 사용되지 않더라도 그 참조가 가리키는 값은 정리되지 않습니다.

마찬가지로 함수 시그니처에서도 & 를 써서 매개변수 s 의 타입이 참조라는 점을 나타냅니다. 설명을 위해 몇 가지 주석을 덧붙이면 다음과 같습니다.

fn main() {
    let s1 = String::from("hello");

    let len = calculate_length(&s1);

    println!("The length of '{s1}' is {len}.");
}

fn calculate_length(s: &String) -> usize { // s is a reference to a String
    s.len()
} // Here, s goes out of scope. But because s does not have ownership of what
  // it refers to, the String is not dropped.

변수 s 가 유효한 스코프는 다른 함수 매개변수와 동일하지만, s 가 참조할 뿐 소유하지는 않기 때문에 s 가 더 이상 사용되지 않는다고 해서 그 참조 대상 값이 삭제되지는 않습니다. 함수가 실제 값을 받는 대신 참조를 매개변수로 받으면, 소유권을 가졌던 적이 없으므로 나중에 값을 반환해 소유권을 돌려줄 필요도 없습니다.

참조를 만드는 행위를 대여(borrowing) 라고 부릅니다. 현실에서 어떤 사람이 물건을 소유하고 있을 때 우리가 그것을 빌려 쓰는 것과 같습니다. 다 쓰고 나면 돌려줘야 합니다. 우리는 그것을 소유하는 것이 아닙니다.

그렇다면 빌린 값을 수정하려 하면 어떻게 될까요? 목록 4-6의 코드를 시도해 봅시다. 미리 말하면, 동작하지 않습니다!

fn main() {
    let s = String::from("hello");

    change(&s);
}

fn change(some_string: &String) {
    some_string.push_str(", world");
}

오류는 다음과 같습니다.

$ cargo run
   Compiling ownership v0.1.0 (file:///projects/ownership)
error[E0596]: cannot borrow `*some_string` as mutable, as it is behind a `&` reference
 --> src/main.rs:8:5
  |
8 |     some_string.push_str(", world");
  |     ^^^^^^^^^^^ `some_string` is a `&` reference, so the data it refers to cannot be borrowed as mutable
  |
help: consider changing this to be a mutable reference
  |
7 | fn change(some_string: &mut String) {
  |                         +++

For more information about this error, try `rustc --explain E0596`.
error: could not compile `ownership` (bin "ownership") due to 1 previous error

변수가 기본적으로 불변인 것처럼, 참조도 기본적으로 불변입니다. 따라서 우리가 참조하고 있는 것을 수정하는 것은 허용되지 않습니다.

가변 참조

목록 4-6의 코드는 몇 가지 작은 수정을 통해, 가변 참조(mutable reference) 를 사용하도록 고치면 빌린 값을 수정할 수 있습니다.

fn main() {
    let mut s = String::from("hello");

    change(&mut s);
}

fn change(some_string: &mut String) {
    some_string.push_str(", world");
}

먼저 s 를 mut 로 바꿉니다. 그런 다음 change 함수를 호출하는 곳에서 &mut s 로 가변 참조를 만들고, 함수 시그니처도 some_string: &mut String 처럼 가변 참조를 받도록 수정합니다. 이렇게 하면 change 함수가 빌린 값을 변경한다는 사실이 아주 명확해집니다.

가변 참조에는 큰 제약이 하나 있습니다. 어떤 값에 대한 가변 참조가 하나 존재하는 동안은, 그 값에 대한 다른 어떤 참조도 동시에 가질 수 없습니다. s 에 대해 두 개의 가변 참조를 만들려는 다음 코드는 실패합니다.

fn main() {
    let mut s = String::from("hello");

    let r1 = &mut s;
    let r2 = &mut s;

    println!("{r1}, {r2}");
}

오류는 다음과 같습니다.

$ cargo run
   Compiling ownership v0.1.0 (file:///projects/ownership)
error[E0499]: cannot borrow `s` as mutable more than once at a time
 --> src/main.rs:5:14
  |
4 |     let r1 = &mut s;
  |              ------ first mutable borrow occurs here
5 |     let r2 = &mut s;
  |              ^^^^^^ second mutable borrow occurs here
6 |
7 |     println!("{r1}, {r2}");
  |                -- first borrow later used here

For more information about this error, try `rustc --explain E0499`.
error: could not compile `ownership` (bin "ownership") due to 1 previous error

이 오류는 같은 시점에 s 를 가변으로 두 번 이상 빌릴 수 없기 때문에 이 코드가 유효하지 않다고 말합니다. 첫 번째 가변 대여는 r1 에 있고, println! 에서 사용될 때까지 살아 있어야 합니다. 그런데 그 가변 참조가 만들어진 뒤 실제로 사용되기 전에, 우리는 r2 라는 또 다른 가변 참조를 만들어 r1 과 같은 데이터를 빌리려 했습니다.

같은 데이터에 대한 여러 가변 참조를 동시에 막는 이 제약은, 변경 자체는 허용하되 매우 통제된 방식으로만 허용한다는 뜻입니다. 대부분의 언어는 원하면 언제든 값을 바꿀 수 있게 해 주기 때문에, 이것은 새로운 Rustacean들이 종종 어려워하는 부분입니다. 하지만 이 제약의 장점은 러스트가 컴파일 시점에 데이터 경쟁을 막을 수 있다는 점입니다. 데이터 경쟁(data race) 은 레이스 컨디션과 비슷한 문제로, 다음 세 가지 조건이 동시에 성립할 때 발생합니다.

• 두 개 이상의 포인터가 같은 데이터에 동시에 접근한다.
• 그 포인터 중 적어도 하나는 데이터를 쓰는 데 사용된다.
• 데이터 접근을 동기화하는 메커니즘이 없다.

데이터 경쟁은 정의되지 않은 동작을 일으키며, 런타임에 추적하려고 하면 진단과 수정이 매우 어렵습니다. 러스트는 데이터 경쟁이 있는 코드를 아예 컴파일하지 않음으로써 이 문제를 막습니다.

언제나 그렇듯, 중괄호로 새 스코프를 만들면 여러 가변 참조를 사용할 수 있습니다. 단, 동시에 존재하지만 않으면 됩니다.

fn main() {
    let mut s = String::from("hello");

    {
        let r1 = &mut s;
    } // r1 goes out of scope here, so we can make a new reference with no problems.

    let r2 = &mut s;
}

러스트는 가변 참조와 불변 참조를 섞어 쓸 때도 비슷한 규칙을 강제합니다. 다음 코드는 오류를 발생시킵니다.

fn main() {
    let mut s = String::from("hello");

    let r1 = &s; // no problem
    let r2 = &s; // no problem
    let r3 = &mut s; // BIG PROBLEM

    println!("{r1}, {r2}, and {r3}");
}

오류는 다음과 같습니다.

$ cargo run
   Compiling ownership v0.1.0 (file:///projects/ownership)
error[E0502]: cannot borrow `s` as mutable because it is also borrowed as immutable
 --> src/main.rs:6:14
  |
4 |     let r1 = &s; // no problem
  |              -- immutable borrow occurs here
5 |     let r2 = &s; // no problem
6 |     let r3 = &mut s; // BIG PROBLEM
  |              ^^^^^^ mutable borrow occurs here
7 |
8 |     println!("{r1}, {r2}, and {r3}");
  |                -- immutable borrow later used here

For more information about this error, try `rustc --explain E0502`.
error: could not compile `ownership` (bin "ownership") due to 1 previous error

후우. 같은 값에 대한 불변 참조가 있는 동안에는 가변 참조도 가질 수 없습니다.

불변 참조를 사용하는 사람은 값이 갑자기 바뀌리라고 기대하지 않기 때문입니다! 반면 여러 개의 불변 참조는 동시에 허용됩니다. 데이터를 읽기만 하는 사람은 다른 사람이 읽는 내용에 영향을 줄 수 없기 때문입니다.

참조의 스코프는 참조가 도입된 지점에서 시작해, 그 참조가 마지막으로 사용되는 지점까지 이어진다는 점에도 주의하세요. 예를 들어 다음 코드는, 불변 참조가 마지막으로 사용되는 곳이 println! 이고 그 뒤에 가변 참조가 도입되므로 컴파일됩니다.

fn main() {
    let mut s = String::from("hello");

    let r1 = &s; // no problem
    let r2 = &s; // no problem
    println!("{r1} and {r2}");
    // Variables r1 and r2 will not be used after this point.

    let r3 = &mut s; // no problem
    println!("{r3}");
}

불변 참조 r1, r2 의 스코프는 그것들이 마지막으로 사용되는 println! 이후에 끝납니다. 이는 가변 참조 r3 가 만들어지기 이전 입니다. 따라서 스코프가 겹치지 않기 때문에 이 코드는 허용됩니다. 컴파일러는 스코프 끝보다 더 앞선 시점에서 참조가 이미 더 이상 사용되지 않는다는 점을 알 수 있습니다.

대여 관련 오류가 때로는 답답할 수 있지만, 이것은 러스트 컴파일러가 잠재적인 버그를 런타임이 아니라 컴파일 시점에 미리 알려 주고, 정확히 어디가 문제인지 보여 주고 있다는 뜻이라는 점을 기억하세요. 그러면 데이터가 왜 생각한 것과 다르게 되었는지 나중에 추적할 필요가 줄어듭니다.

댕글링 참조

포인터를 사용하는 언어에서는, 어떤 메모리를 해제한 뒤 그 메모리를 가리키는 포인터를 그대로 남겨 두는 실수를 통해 댕글링 포인터(dangling pointer) 를 만들기 쉽습니다. 댕글링 포인터는 이미 다른 것에 재할당되었을 수도 있는 메모리 위치를 참조합니다. 반면 러스트에서는 컴파일러가 참조가 절대 댕글링 참조가 되지 않도록 보장합니다. 어떤 데이터에 대한 참조가 있다면, 컴파일러는 그 참조가 살아 있는 동안 데이터가 먼저 스코프를 벗어나지 않도록 확인합니다.

러스트가 컴파일 시점 오류로 이를 어떻게 막는지 보기 위해, 댕글링 참조를 일부러 만들어 보겠습니다.

fn main() {
    let reference_to_nothing = dangle();
}

fn dangle() -> &String {
    let s = String::from("hello");

    &s
}

오류는 다음과 같습니다.

$ cargo run
   Compiling ownership v0.1.0 (file:///projects/ownership)
error[E0106]: missing lifetime specifier
 --> src/main.rs:5:16
  |
5 | fn dangle() -> &String {
  |                ^ expected named lifetime parameter
  |
  = help: this function's return type contains a borrowed value, but there is no value for it to be borrowed from
help: consider using the `'static` lifetime, but this is uncommon unless you're returning a borrowed value from a `const` or a `static`
  |
5 | fn dangle() -> &'static String {
  |                 +++++++
help: instead, you are more likely to want to return an owned value
  |
5 - fn dangle() -> &String {
5 + fn dangle() -> String {
  |

For more information about this error, try `rustc --explain E0106`.
error: could not compile `ownership` (bin "ownership") due to 1 previous error

이 오류 메시지에는 아직 다루지 않은 기능인 라이프타임이 언급됩니다. 라이프타임은 10장에서 자세히 다룹니다. 하지만 라이프타임 부분을 잠시 무시하고 보면, 이 메시지는 왜 이 코드가 문제인지에 대한 핵심을 담고 있습니다.

this function's return type contains a borrowed value, but there is no value
for it to be borrowed from

dangle 코드의 각 단계에서 정확히 무슨 일이 일어나는지 좀 더 자세히 봅시다.

fn main() {
    let reference_to_nothing = dangle();
}

fn dangle() -> &String { // dangle returns a reference to a String

    let s = String::from("hello"); // s is a new String

    &s // we return a reference to the String, s
} // Here, s goes out of scope and is dropped, so its memory goes away.
  // Danger!

s 는 dangle 안에서 만들어졌기 때문에, dangle 의 코드가 끝나면 s 는 할당 해제됩니다. 그런데 우리는 그 값에 대한 참조를 반환하려 했습니다. 그러면 이 참조는 무효한 String 을 가리키게 됩니다. 좋지 않지요! 러스트는 이런 코드를 허용하지 않습니다.

여기서 해결책은 String 을 직접 반환하는 것입니다.

fn main() {
    let string = no_dangle();
}

fn no_dangle() -> String {
    let s = String::from("hello");

    s
}

이 코드는 아무 문제 없이 동작합니다. 소유권이 함수 밖으로 이동하므로, 아무 것도 미리 해제되지 않습니다.

참조 규칙

지금까지 참조에 대해 다룬 내용을 정리해 봅시다.

• 어떤 시점이든, 가변 참조는 하나만 있거나, 아니면 불변 참조를 몇 개든 가질 수 있습니다.
• 참조는 언제나 유효해야 합니다.

다음으로는 또 다른 종류의 참조인 슬라이스를 살펴보겠습니다.

슬라이스 타입

슬라이스 타입

슬라이스(slices) 는 컬렉션 안에서 연속된 요소 시퀀스를 참조할 수 있게 해 줍니다. 슬라이스는 참조의 한 종류이므로 소유권을 갖지 않습니다.

작은 프로그래밍 문제를 하나 생각해 봅시다. 공백으로 구분된 여러 단어를 담고 있는 문자열을 받아서, 그 문자열에서 첫 번째 단어를 반환하는 함수를 작성한다고 합시다. 함수가 문자열 안에서 공백을 찾지 못하면, 문자열 전체가 하나의 단어라는 뜻이므로 문자열 전체를 반환해야 합니다.

먼저 슬라이스를 사용하지 않고 이 함수의 시그니처를 어떻게 작성할지를 살펴보며, 슬라이스가 해결해 줄 문제를 이해해 봅시다.

fn first_word(s: &String) -> ?

first_word 함수는 &String 타입의 매개변수를 가집니다. 소유권은 필요 없으므로 이 점은 괜찮습니다. (관용적인 러스트에서는 함수가 정말 필요하지 않은 한 인수의 소유권을 가져가지 않으며, 왜 그런지는 계속 진행하면서 분명해질 것입니다.) 하지만 무엇을 반환해야 할까요? 우리는 문자열의 일부 에 대해 적절히 말할 방법이 없습니다. 다만 단어 끝 위치를 나타내는 인덱스, 즉 공백의 위치를 반환할 수는 있습니다. 목록 4-7처럼 그렇게 해 봅시다.

fn first_word(s: &String) -> usize {
    let bytes = s.as_bytes();

    for (i, &item) in bytes.iter().enumerate() {
        if item == b' ' {
            return i;
        }
    }

    s.len()
}

fn main() {}

String 을 요소 하나씩 순회하며 값이 공백인지 확인해야 하므로, as_bytes 메서드를 사용해 String 을 바이트 배열로 바꿉니다.

fn first_word(s: &String) -> usize {
    let bytes = s.as_bytes();

    for (i, &item) in bytes.iter().enumerate() {
        if item == b' ' {
            return i;
        }
    }

    s.len()
}

fn main() {}

그다음 iter 메서드로 바이트 배열의 반복자를 만듭니다.

fn first_word(s: &String) -> usize {
    let bytes = s.as_bytes();

    for (i, &item) in bytes.iter().enumerate() {
        if item == b' ' {
            return i;
        }
    }

    s.len()
}

fn main() {}

반복자는 13장에서 더 자세히 다룹니다. 지금은 iter 가 컬렉션 안의 각 요소를 반환하는 메서드이고, enumerate 는 iter 의 결과를 감싸 각 요소를 튜플의 일부로 반환한다는 점만 알면 됩니다. enumerate 가 반환하는 튜플의 첫 번째 요소는 인덱스이고, 두 번째 요소는 해당 요소에 대한 참조입니다. 인덱스를 직접 계산하는 것보다 조금 더 편리합니다.

enumerate 메서드가 튜플을 반환하므로, 패턴을 사용해 그 튜플을 구조분해할 수 있습니다. 패턴은 6장에서 더 다룹니다. 여기서 for 루프에서는 튜플 안의 인덱스에 대해 i, 단일 바이트에 대해 &item 을 갖는 패턴을 지정합니다. .iter().enumerate() 로부터 요소에 대한 참조를 받기 때문에, 패턴에도 & 를 씁니다.

for 루프 안에서는 바이트 리터럴 문법을 사용해 공백을 나타내는 바이트를 찾습니다. 공백을 찾으면 그 위치를 반환합니다. 그렇지 않으면 s.len() 을 사용해 문자열 길이를 반환합니다.

fn first_word(s: &String) -> usize {
    let bytes = s.as_bytes();

    for (i, &item) in bytes.iter().enumerate() {
        if item == b' ' {
            return i;
        }
    }

    s.len()
}

fn main() {}

이제 문자열 안에서 첫 번째 단어 끝 인덱스를 알아낼 수는 있지만, 문제가 하나 있습니다. 우리는 그저 usize 하나만 반환하고 있습니다. 그런데 이 숫자는 &String 이라는 맥락 속에서만 의미가 있습니다. 다시 말해 String 과 완전히 분리된 값이기 때문에, 앞으로도 그 값이 여전히 유효하리라는 보장이 없습니다. 목록 4-8의 프로그램은 목록 4-7의 first_word 함수를 사용하는 예입니다.

fn first_word(s: &String) -> usize {
    let bytes = s.as_bytes();

    for (i, &item) in bytes.iter().enumerate() {
        if item == b' ' {
            return i;
        }
    }

    s.len()
}

fn main() {
    let mut s = String::from("hello world");

    let word = first_word(&s); // word will get the value 5

    s.clear(); // this empties the String, making it equal to ""

    // word still has the value 5 here, but s no longer has any content that we
    // could meaningfully use with the value 5, so word is now totally invalid!
}

이 프로그램은 오류 없이 컴파일되고, s.clear() 호출 뒤에 word 를 사용하더라도 마찬가지입니다. word 는 s 의 상태와 전혀 연결되어 있지 않기 때문에, word 안에는 여전히 값 5 가 들어 있습니다. 우리는 그 값 5 와 변수 s 를 사용해 첫 번째 단어를 꺼내려고 시도할 수 있겠지만, 5 를 word 에 저장한 이후 s 의 내용이 바뀌었으므로 이것은 버그가 됩니다.

word 안의 인덱스가 s 안의 데이터와 어긋나지 않도록 계속 신경 써야 하는 것은 성가시고 오류를 만들기 쉽습니다. second_word 함수를 작성하면 이런 인덱스 관리는 더 취약해집니다. 시그니처는 다음처럼 되어야 할 것입니다.

fn second_word(s: &String) -> (usize, usize) {

이제 시작 인덱스 와 끝 인덱스를 함께 추적해야 하고, 모두 특정 시점의 데이터에서 계산된 값이지만 그 상태와는 전혀 연결되지 않은 값들입니다. 서로 관련 없는 변수 셋이 떠다니며 서로 동기화되어야 하는 상황이 된 것입니다.

다행히 러스트에는 이 문제를 해결하는 방법이 있습니다. 바로 문자열 슬라이스입니다.

문자열 슬라이스

문자열 슬라이스(string slice) 는 String 의 연속된 일부 요소에 대한 참조이며, 다음처럼 생겼습니다.

fn main() {
    let s = String::from("hello world");

    let hello = &s[0..5];
    let world = &s[6..11];
}

hello 는 문자열 전체 String 에 대한 참조가 아니라, 추가된 [0..5] 부분으로 지정된 String 의 일부에 대한 참조입니다. 슬라이스는 대괄호 안에 범위를 넣어 만듭니다. 즉 [starting_index..ending_index] 형태로 쓰며, starting_index 는 슬라이스의 첫 번째 위치이고, ending_index 는 슬라이스의 마지막 위치보다 하나 큰 값입니다. 내부적으로 슬라이스 데이터 구조는 시작 위치와 슬라이스 길이를 저장하며, 이 길이는 ending_index 에서 starting_index 를 뺀 값에 해당합니다. 따라서 let world = &s[6..11]; 에서 world 는 s 의 인덱스 6의 바이트를 가리키는 포인터와 길이 값 5 를 가진 슬라이스가 됩니다.

그림 4-7은 이를 도식으로 보여 줍니다.

그림 4-7: String 의 일부를 가리키는 문자열 슬라이스

러스트의 .. 범위 문법에서는 인덱스 0부터 시작하고 싶다면 두 점 앞의 값을 생략할 수 있습니다. 즉 다음 둘은 같습니다.

#![allow(unused)]
fn main() {
let s = String::from("hello");

let slice = &s[0..2];
let slice = &s[..2];
}

마찬가지로 슬라이스가 String 의 마지막 바이트를 포함한다면 뒤쪽 숫자를 생략할 수 있습니다. 즉 다음 둘도 같습니다.

#![allow(unused)]
fn main() {
let s = String::from("hello");

let len = s.len();

let slice = &s[3..len];
let slice = &s[3..];
}

문자열 전체를 슬라이스로 가져오고 싶다면 두 값 모두 생략할 수 있습니다. 따라서 다음 둘 역시 같습니다.

#![allow(unused)]
fn main() {
let s = String::from("hello");

let len = s.len();

let slice = &s[0..len];
let slice = &s[..];
}

이제 이 정보를 바탕으로 first_word 를 슬라이스를 반환하도록 다시 작성해 봅시다. “문자열 슬라이스” 를 뜻하는 타입은 &str 로 씁니다.

fn first_word(s: &String) -> &str {
    let bytes = s.as_bytes();

    for (i, &item) in bytes.iter().enumerate() {
        if item == b' ' {
            return &s[0..i];
        }
    }

    &s[..]
}

fn main() {}

단어 끝 인덱스를 찾는 방식은 목록 4-7과 동일합니다. 즉, 첫 번째 공백을 찾습니다. 공백을 찾으면 문자열의 시작부터 공백 인덱스까지를 시작과 끝 인덱스로 하는 문자열 슬라이스를 반환합니다.

이제 first_word 를 호출하면, 우리는 기반 데이터와 연결된 하나의 값을 돌려받습니다. 이 값은 슬라이스 시작 위치에 대한 참조와 슬라이스에 포함된 요소 수로 이루어져 있습니다.

슬라이스를 반환하는 방식은 second_word 함수에도 잘 맞습니다.

fn second_word(s: &String) -> &str {

이제는 훨씬 단순하고 실수하기 어려운 API를 갖게 되었습니다. 컴파일러가 String 안으로 들어가는 참조들이 유효하게 유지되는지 보장해 주기 때문입니다. 목록 4-8의 버그를 떠올려 보세요. 우리는 첫 번째 단어 끝 인덱스를 얻은 뒤 문자열을 비워서, 그 인덱스가 무효가 되었습니다. 그 코드는 논리적으로 잘못되었지만 즉시 오류를 드러내지는 않았습니다. 빈 문자열과 함께 첫 번째 단어 인덱스를 계속 쓰려는 시점에야 문제가 표면화되었을 것입니다. 하지만 슬라이스는 이런 버그를 불가능하게 만들고, 우리 코드에 문제가 있음을 훨씬 더 빨리 알려 줍니다. first_word 의 슬라이스 버전을 사용하면 컴파일 시점 오류가 납니다.

fn first_word(s: &String) -> &str {
    let bytes = s.as_bytes();

    for (i, &item) in bytes.iter().enumerate() {
        if item == b' ' {
            return &s[0..i];
        }
    }

    &s[..]
}

fn main() {
    let mut s = String::from("hello world");

    let word = first_word(&s);

    s.clear(); // error!

    println!("the first word is: {word}");
}

컴파일러 오류는 다음과 같습니다.

$ cargo run
   Compiling ownership v0.1.0 (file:///projects/ownership)
error[E0502]: cannot borrow `s` as mutable because it is also borrowed as immutable
  --> src/main.rs:18:5
   |
16 |     let word = first_word(&s);
   |                           -- immutable borrow occurs here
17 |
18 |     s.clear(); // error!
   |     ^^^^^^^^^ mutable borrow occurs here
19 |
20 |     println!("the first word is: {word}");
   |                                   ---- immutable borrow later used here

For more information about this error, try `rustc --explain E0502`.
error: could not compile `ownership` (bin "ownership") due to 1 previous error

대여 규칙에서 보았듯이, 어떤 것에 대한 불변 참조가 있다면 동시에 그 값에 대한 가변 참조를 가질 수 없습니다. clear 는 String 을 잘라내야 하므로 가변 참조를 얻어야 합니다. 그런데 clear 호출 뒤의 println! 이 word 안의 참조를 사용하므로, 그 시점까지는 불변 참조가 여전히 살아 있어야 합니다. 러스트는 clear 안의 가변 참조와 word 안의 불변 참조가 동시에 존재하는 것을 허용하지 않고, 컴파일에 실패합니다. 러스트는 API를 더 쓰기 쉽게 만들었을 뿐 아니라, 컴파일 시점에 하나의 버그 범주 전체를 제거해 준 것입니다.

문자열 리터럴은 슬라이스이다

앞에서 문자열 리터럴이 바이너리 안에 저장된다고 이야기했습니다. 이제 슬라이스를 알게 되었으니 문자열 리터럴도 정확히 이해할 수 있습니다.

#![allow(unused)]
fn main() {
let s = "Hello, world!";
}

여기서 s 의 타입은 &str 입니다. 즉 바이너리 안 특정 지점을 가리키는 슬라이스입니다. 이것이 문자열 리터럴이 불변인 이유이기도 합니다. &str 은 불변 참조이기 때문입니다.

문자열 슬라이스를 매개변수로 받기

문자열 리터럴과 String 값 모두에서 슬라이스를 취할 수 있다는 사실을 알게 되면, first_word 에 대해 한 가지 더 개선할 수 있습니다. 바로 시그니처입니다.

fn first_word(s: &String) -> &str {

경험 많은 Rustacean이라면 목록 4-9에 나온 시그니처를 사용할 것입니다. 이 시그니처는 &String 값과 &str 값 모두에 같은 함수를 적용할 수 있게 해 주기 때문입니다.

fn first_word(s: &str) -> &str {
    let bytes = s.as_bytes();

    for (i, &item) in bytes.iter().enumerate() {
        if item == b' ' {
            return &s[0..i];
        }
    }

    &s[..]
}

fn main() {
    let my_string = String::from("hello world");

    // `first_word` works on slices of `String`s, whether partial or whole.
    let word = first_word(&my_string[0..6]);
    let word = first_word(&my_string[..]);
    // `first_word` also works on references to `String`s, which are equivalent
    // to whole slices of `String`s.
    let word = first_word(&my_string);

    let my_string_literal = "hello world";

    // `first_word` works on slices of string literals, whether partial or
    // whole.
    let word = first_word(&my_string_literal[0..6]);
    let word = first_word(&my_string_literal[..]);

    // Because string literals *are* string slices already,
    // this works too, without the slice syntax!
    let word = first_word(my_string_literal);
}

이미 문자열 슬라이스가 있다면 그대로 전달하면 됩니다. String 이 있다면 그 String 의 슬라이스를 넘기거나, String 에 대한 참조를 넘길 수 있습니다. 이런 유연성은 역참조 강제(deref coercion)를 활용한 것으로, 이는 15장의 “함수와 메서드에서 역참조 강제 사용하기” 절에서 다룹니다.

String 에 대한 참조 대신 문자열 슬라이스를 받도록 함수를 정의하면, 기능을 잃지 않으면서도 API를 더 일반적이고 유용하게 만들 수 있습니다.

fn first_word(s: &str) -> &str {
    let bytes = s.as_bytes();

    for (i, &item) in bytes.iter().enumerate() {
        if item == b' ' {
            return &s[0..i];
        }
    }

    &s[..]
}

fn main() {
    let my_string = String::from("hello world");

    // `first_word` works on slices of `String`s, whether partial or whole.
    let word = first_word(&my_string[0..6]);
    let word = first_word(&my_string[..]);
    // `first_word` also works on references to `String`s, which are equivalent
    // to whole slices of `String`s.
    let word = first_word(&my_string);

    let my_string_literal = "hello world";

    // `first_word` works on slices of string literals, whether partial or
    // whole.
    let word = first_word(&my_string_literal[0..6]);
    let word = first_word(&my_string_literal[..]);

    // Because string literals *are* string slices already,
    // this works too, without the slice syntax!
    let word = first_word(my_string_literal);
}

다른 슬라이스들

상상할 수 있듯, 문자열 슬라이스는 문자열에만 특화된 것입니다. 하지만 더 일반적인 슬라이스 타입도 있습니다. 다음 배열을 보세요.

#![allow(unused)]
fn main() {
let a = [1, 2, 3, 4, 5];
}

문자열의 일부를 가리키고 싶을 수 있는 것처럼, 배열의 일부를 가리키고 싶을 수도 있습니다. 그럴 때는 다음처럼 씁니다.

#![allow(unused)]
fn main() {
let a = [1, 2, 3, 4, 5];

let slice = &a[1..3];

assert_eq!(slice, &[2, 3]);
}

이 슬라이스의 타입은 &[i32] 입니다. 문자열 슬라이스와 똑같은 방식으로 동작하며, 첫 번째 요소에 대한 참조와 길이를 저장합니다. 이런 종류의 슬라이스는 다른 여러 컬렉션에서도 사용하게 됩니다. 벡터를 다루는 8장에서 이런 컬렉션을 자세히 설명합니다.

정리

소유권, 대여, 슬라이스 개념은 컴파일 시점에 러스트 프로그램의 메모리 안전성을 보장해 줍니다. 러스트는 다른 시스템 프로그래밍 언어와 같은 수준의 메모리 사용 제어권을 제공하면서도, 데이터의 소유자가 스코프를 벗어날 때 그 데이터를 자동으로 정리하게 함으로써 그 제어를 얻기 위해 추가 코드를 쓰고 디버깅할 필요를 줄여 줍니다.

소유권은 러스트의 다른 많은 부분이 작동하는 방식에 영향을 주므로, 책의 나머지 부분에서도 이 개념들을 계속 다루게 됩니다. 이제 5장으로 넘어가 struct 로 여러 데이터 조각을 한데 묶는 방법을 살펴봅시다.

관련된 데이터를 구조체로 표현하기

struct 또는 structure 는 의미 있는 하나의 묶음을 이루는 여러 관련 값을 한데 묶고 이름 붙일 수 있게 해 주는 사용자 정의 데이터 타입입니다. 객체 지향 언어에 익숙하다면, 구조체는 객체의 데이터 속성과 비슷하다고 생각할 수 있습니다. 이 장에서는 튜플과 구조체를 비교하고 대조하면서, 여러분이 이미 알고 있는 내용을 바탕으로 언제 구조체가 데이터를 묶는 더 나은 방법이 되는지 보여 주겠습니다.

구조체를 정의하고 인스턴스를 만드는 방법을 살펴보고, 구조체 타입에 연결된 동작을 표현하기 위해 연관 함수를 어떻게 정의하는지도 설명합니다. 특히 연관 함수 중에서도 메서드 라고 부르는 종류를 다룹니다. 구조체와 6장에서 다룰 enum은, 러스트의 컴파일 시 타입 검사를 최대한 활용할 수 있도록 프로그램 도메인에 맞는 새로운 타입을 만들어 내는 기본 재료입니다.

구조체 정의와 인스턴스 생성

구조체 정의와 인스턴스 생성

구조체는 “튜플 타입” 절에서 다룬 튜플과 비슷합니다. 둘 다 여러 관련 값을 함께 담는다는 점이 그렇습니다. 튜플처럼 구조체 안의 각 요소도 서로 다른 타입일 수 있습니다. 하지만 튜플과 달리 구조체에서는 각 데이터 조각에 이름을 붙이므로, 그 값이 무엇을 뜻하는지 더 명확해집니다. 이런 이름 덕분에 구조체는 튜플보다 더 유연합니다. 인스턴스의 값을 지정하거나 접근할 때 데이터의 순서에 의존할 필요가 없기 때문입니다.

구조체를 정의하려면 struct 키워드를 쓰고 구조체 전체의 이름을 붙입니다. 구조체 이름은 함께 묶인 데이터 조각들이 무엇을 의미하는지 설명할 수 있어야 합니다. 그런 다음 중괄호 안에 데이터 조각의 이름과 타입을 정의하는데, 이것들을 필드(fields) 라고 부릅니다. 예를 들어 목록 5-1은 사용자 계정 정보를 저장하는 구조체를 보여 줍니다.

struct User {
    active: bool,
    username: String,
    email: String,
    sign_in_count: u64,
}

fn main() {}

구조체를 정의한 뒤에는 각 필드에 구체적인 값을 지정해 그 구조체의 인스턴스(instance) 를 만들 수 있습니다. 인스턴스를 만들려면 구조체 이름 뒤에 중괄호를 쓰고 그 안에 key: value 쌍을 넣습니다. 여기서 키는 필드 이름이고 값은 그 필드에 저장할 데이터입니다. 필드를 구조체 정의와 같은 순서로 적을 필요는 없습니다. 다시 말해 구조체 정의는 타입을 위한 일반적인 템플릿 같은 것이고, 인스턴스는 그 템플릿에 구체적인 데이터를 채워 넣어 해당 타입의 값을 만들어 냅니다. 예를 들어 특정 사용자를 목록 5-2처럼 선언할 수 있습니다.

struct User {
    active: bool,
    username: String,
    email: String,
    sign_in_count: u64,
}

fn main() {
    let user1 = User {
        active: true,
        username: String::from("someusername123"),
        email: String::from("someone@example.com"),
        sign_in_count: 1,
    };
}

구조체 안의 특정 값에 접근하려면 점 표기법을 사용합니다. 예를 들어 이 사용자의 이메일 주소에 접근하려면 user1.email 을 사용합니다. 인스턴스가 가변이라면, 점 표기법으로 특정 필드에 대입하여 값을 바꿀 수도 있습니다. 목록 5-3은 가변 User 인스턴스의 email 필드를 바꾸는 방법을 보여 줍니다.

struct User {
    active: bool,
    username: String,
    email: String,
    sign_in_count: u64,
}

fn main() {
    let mut user1 = User {
        active: true,
        username: String::from("someusername123"),
        email: String::from("someone@example.com"),
        sign_in_count: 1,
    };

    user1.email = String::from("anotheremail@example.com");
}

인스턴스 전체가 가변이어야 한다는 점에 주의하세요. 러스트는 일부 필드만 따로 가변으로 표시하는 것을 허용하지 않습니다. 또한 다른 식들과 마찬가지로, 함수 본문의 마지막 식으로 구조체의 새 인스턴스를 만들어 암묵적으로 반환할 수도 있습니다.

목록 5-4는 주어진 이메일과 사용자 이름으로 User 인스턴스를 반환하는 build_user 함수를 보여 줍니다. active 필드는 true, sign_in_count 필드는 1 값을 갖습니다.

struct User {
    active: bool,
    username: String,
    email: String,
    sign_in_count: u64,
}

fn build_user(email: String, username: String) -> User {
    User {
        active: true,
        username: username,
        email: email,
        sign_in_count: 1,
    }
}

fn main() {
    let user1 = build_user(
        String::from("someone@example.com"),
        String::from("someusername123"),
    );
}

함수 매개변수 이름을 구조체 필드 이름과 같게 두는 것은 자연스럽지만, email 과 username 필드 이름과 변수 이름을 둘 다 반복해서 써야 하는 것은 약간 번거롭습니다. 구조체에 필드가 더 많아지면 이런 반복은 더 성가셔질 것입니다. 다행히도 이를 줄일 수 있는 편리한 축약 문법이 있습니다!

필드 초기화 축약 문법 사용하기

목록 5-4에서는 매개변수 이름과 구조체 필드 이름이 정확히 같기 때문에, 필드 초기화 축약(field init shorthand) 문법을 사용하여 build_user 를 목록 5-5처럼 다시 쓸 수 있습니다. 동작은 완전히 같지만 username 과 email 을 반복해서 적지 않아도 됩니다.

struct User {
    active: bool,
    username: String,
    email: String,
    sign_in_count: u64,
}

fn build_user(email: String, username: String) -> User {
    User {
        active: true,
        username,
        email,
        sign_in_count: 1,
    }
}

fn main() {
    let user1 = build_user(
        String::from("someone@example.com"),
        String::from("someusername123"),
    );
}

여기서 우리는 email 이라는 필드를 가진 새 User 구조체 인스턴스를 만들고 있습니다. 그리고 build_user 함수의 email 매개변수에 들어 있는 값을 구조체 필드 email 의 값으로 넣고 싶습니다. 필드 이름과 매개변수 이름이 같기 때문에 email: email 대신 그냥 email 이라고만 써도 됩니다.

구조체 갱신 문법으로 인스턴스 만들기

같은 타입의 다른 인스턴스에 있는 값 대부분을 그대로 사용하되, 일부만 바꾼 새 인스턴스를 만들고 싶을 때가 자주 있습니다. 이때 구조체 갱신 문법(struct update syntax)을 사용할 수 있습니다.

먼저 목록 5-6에서는 갱신 문법 없이 평범한 방식으로 user2 라는 새 User 인스턴스를 만드는 방법을 보여 줍니다. email 에는 새 값을 넣고, 나머지 값은 목록 5-2에서 만든 user1 과 같은 값을 사용합니다.

struct User {
    active: bool,
    username: String,
    email: String,
    sign_in_count: u64,
}

fn main() {
    // --snip--

    let user1 = User {
        email: String::from("someone@example.com"),
        username: String::from("someusername123"),
        active: true,
        sign_in_count: 1,
    };

    let user2 = User {
        active: user1.active,
        username: user1.username,
        email: String::from("another@example.com"),
        sign_in_count: user1.sign_in_count,
    };
}

구조체 갱신 문법을 사용하면, 목록 5-7처럼 더 적은 코드로 같은 효과를 낼 수 있습니다. .. 문법은 명시적으로 설정하지 않은 나머지 필드들이 주어진 인스턴스의 같은 이름의 필드와 동일한 값을 갖도록 하라는 뜻입니다.

struct User {
    active: bool,
    username: String,
    email: String,
    sign_in_count: u64,
}

fn main() {
    // --snip--

    let user1 = User {
        email: String::from("someone@example.com"),
        username: String::from("someusername123"),
        active: true,
        sign_in_count: 1,
    };

    let user2 = User {
        email: String::from("another@example.com"),
        ..user1
    };
}

목록 5-7의 코드는 email 값만 다른 새 인스턴스 user2 를 만들고, username, active, sign_in_count 필드는 모두 user1 의 값을 사용합니다. ..user1 은 남은 필드들이 user1 의 대응하는 필드에서 값을 가져오도록 지정하는 문법이므로 반드시 마지막에 와야 합니다. 다만 구조체 정의에서 필드가 선언된 순서와 상관없이, 원하는 만큼의 필드에 대해 어떤 순서로든 값을 직접 지정할 수 있습니다.

구조체 갱신 문법이 대입문처럼 = 를 사용하는 데 주목하세요. 이것은 “이동(move)으로 변수와 데이터가 상호작용하는 방식” 절에서 보았듯이 데이터가 이동되기 때문입니다. 이 예제에서는 user1 의 username 필드 안에 있던 String 이 user2 로 이동했으므로, user2 를 만든 뒤에는 user1 을 더 이상 사용할 수 없습니다. 만약 user2 에 email 뿐 아니라 username 도 새 String 값을 넣고, user1 에서 active 와 sign_in_count 값만 사용했다면, user2 생성 이후에도 user1 은 여전히 유효했을 것입니다. active 와 sign_in_count 는 둘 다 Copy 트레이트를 구현하는 타입이기 때문에, “스택에만 있는 데이터: Copy” 절에서 설명한 동작이 적용되기 때문입니다. 이 예제에서는 user1.email 도 계속 사용할 수 있습니다. 그 값은 user1 밖으로 이동되지 않았기 때문입니다.

튜플 구조체로 서로 다른 타입 만들기

러스트는 튜플과 비슷하게 생긴 구조체도 지원하는데, 이것을 튜플 구조체(tuple struct) 라고 부릅니다. 튜플 구조체는 구조체 이름이 부여하는 의미는 가지지만, 각 필드에 이름이 붙지는 않습니다. 대신 필드의 타입만 가집니다. 튜플 구조체는 튜플 전체에 이름을 붙여 다른 튜플과 구별되는 타입으로 만들고 싶을 때, 그리고 일반 구조체처럼 각 필드에 이름을 붙이는 것이 장황하거나 중복일 때 유용합니다.

튜플 구조체를 정의하려면 struct 키워드와 구조체 이름을 쓰고, 뒤에 괄호 안에 필드들의 타입을 나열합니다. 예를 들어 다음 코드는 Color 와 Point 라는 두 튜플 구조체를 정의하고 사용합니다.

struct Color(i32, i32, i32);
struct Point(i32, i32, i32);

fn main() {
    let black = Color(0, 0, 0);
    let origin = Point(0, 0, 0);
}

black 과 origin 값은 서로 다른 타입의 인스턴스이기 때문에 타입도 다르다는 점에 주목하세요. 구조체 내부 필드 타입이 같더라도, 여러분이 정의한 각 구조체는 그 자체로 고유한 타입입니다. 예를 들어 Color 타입을 받는 함수는, 둘 다 세 개의 i32 값으로 이루어져 있더라도 Point 를 인수로 받을 수 없습니다. 이 점을 제외하면 튜플 구조체 인스턴스는 일반 튜플과 비슷해서, 각 부분으로 구조분해할 수도 있고 . 와 인덱스로 개별 값에 접근할 수도 있습니다. 다만 구조분해할 때는 일반 튜플과 달리 튜플 구조체 이름을 명시해야 합니다. 예를 들어 origin 안의 값을 x, y, z 변수로 구조분해하려면 let Point(x, y, z) = origin; 처럼 씁니다.

유닛 유사 구조체 정의하기

필드가 전혀 없는 구조체도 정의할 수 있습니다! 이런 구조체는 “튜플 타입” 절에서 언급한 유닛 타입 () 와 비슷하게 동작하기 때문에 유닛 유사 구조체(unit-like structs) 라고 부릅니다. 유닛 유사 구조체는 어떤 타입에 트레이트를 구현해야 하지만, 그 타입 자체 안에 저장하고 싶은 데이터는 없을 때 유용합니다. 트레이트는 10장에서 다룹니다. 다음은 AlwaysEqual 이라는 유닛 구조체를 선언하고 인스턴스를 만드는 예입니다.

struct AlwaysEqual;

fn main() {
    let subject = AlwaysEqual;
}

AlwaysEqual 을 정의할 때는 struct 키워드와 원하는 이름 뒤에 세미콜론만 적습니다. 중괄호도 괄호도 필요 없습니다! 그런 다음 subject 변수 안에 AlwaysEqual 인스턴스를 만들 수 있는데, 이 역시 중괄호나 괄호 없이 이름만 사용하는 비슷한 방식입니다. 나중에 이 타입에, 어떤 AlwaysEqual 인스턴스든 다른 어떤 인스턴스와도 항상 같다고 판단하는 동작을 구현할 수도 있다고 상상해 봅시다. 예를 들어 테스트할 때 항상 예측 가능한 결과를 얻고 싶을 수 있습니다. 그런 동작을 구현하는 데는 별도의 데이터가 필요하지 않습니다! 10장에서는 유닛 유사 구조체를 포함해 어떤 타입이든 트레이트를 정의하고 구현하는 방법을 배우게 됩니다.

struct User {
    active: bool,
    username: &str,
    email: &str,
    sign_in_count: u64,
}

fn main() {
    let user1 = User {
        active: true,
        username: "someusername123",
        email: "someone@example.com",
        sign_in_count: 1,
    };
}

$ cargo run
   Compiling structs v0.1.0 (file:///projects/structs)
error[E0106]: missing lifetime specifier
 --> src/main.rs:3:15
  |
3 |     username: &str,
  |               ^ expected named lifetime parameter
  |
help: consider introducing a named lifetime parameter
  |
1 ~ struct User<'a> {
2 |     active: bool,
3 ~     username: &'a str,
  |

error[E0106]: missing lifetime specifier
 --> src/main.rs:4:12
  |
4 |     email: &str,
  |            ^ expected named lifetime parameter
  |
help: consider introducing a named lifetime parameter
  |
1 ~ struct User<'a> {
2 |     active: bool,
3 |     username: &str,
4 ~     email: &'a str,
  |

For more information about this error, try `rustc --explain E0106`.
error: could not compile `structs` (bin "structs") due to 2 previous errors

구조체를 사용하는 예제 프로그램

구조체를 사용하는 예제 프로그램

언제 구조체를 사용하고 싶어지는지 이해하기 위해, 직사각형의 넓이를 계산하는 프로그램을 작성해 봅시다. 처음에는 개별 변수만 사용한 뒤, 점차 구조체를 사용하는 방식으로 리팩터링해 보겠습니다.

픽셀 단위로 주어진 직사각형의 너비와 높이를 받아 넓이를 계산하는 rectangles 라는 새 바이너리 프로젝트를 Cargo로 만들어 봅시다. 목록 5-8은 src/main.rs 에 넣을 수 있는, 그 작업을 수행하는 짧은 프로그램을 보여 줍니다.

fn main() {
    let width1 = 30;
    let height1 = 50;

    println!(
        "The area of the rectangle is {} square pixels.",
        area(width1, height1)
    );
}

fn area(width: u32, height: u32) -> u32 {
    width * height
}

이제 cargo run 으로 이 프로그램을 실행해 봅시다.

$ cargo run
   Compiling rectangles v0.1.0 (file:///projects/rectangles)
    Finished `dev` profile [unoptimized + debuginfo] target(s) in 0.42s
     Running `target/debug/rectangles`
The area of the rectangle is 1500 square pixels.

이 코드는 각 치수를 area 함수에 넘겨 직사각형 넓이를 알아내는 데 성공합니다. 하지만 이 코드를 더 명확하고 읽기 쉽게 만들 여지는 남아 있습니다.

문제는 area 의 시그니처를 보면 분명해집니다.

fn main() {
    let width1 = 30;
    let height1 = 50;

    println!(
        "The area of the rectangle is {} square pixels.",
        area(width1, height1)
    );
}

fn area(width: u32, height: u32) -> u32 {
    width * height
}

area 함수는 원래 하나의 직사각형 넓이를 계산해야 하는데, 지금 작성한 함수는 매개변수가 둘입니다. 그리고 이 매개변수 둘이 서로 관련 있다는 사실이 프로그램 어디에도 드러나지 않습니다. 너비와 높이를 함께 묶는 편이 더 읽기 쉽고 관리하기 쉬울 것입니다. 이를 위한 한 가지 방법은 이미 3장의 “튜플 타입” 절에서 다뤘습니다. 튜플을 사용하는 방식입니다.

튜플로 리팩터링하기

목록 5-9는 튜플을 사용하는 또 다른 버전의 프로그램을 보여 줍니다.

fn main() {
    let rect1 = (30, 50);

    println!(
        "The area of the rectangle is {} square pixels.",
        area(rect1)
    );
}

fn area(dimensions: (u32, u32)) -> u32 {
    dimensions.0 * dimensions.1
}

어떤 면에서는 이 프로그램이 더 낫습니다. 튜플 덕분에 약간의 구조가 생겼고, 이제는 인수를 하나만 넘깁니다. 하지만 다른 면에서는 이 버전이 덜 명확합니다. 튜플은 각 요소에 이름이 없기 때문에, 튜플의 각 부분에 인덱스로 접근해야 하고 그 때문에 계산이 덜 분명해집니다.

넓이 계산 자체에서는 너비와 높이를 바꿔 써도 문제가 없겠지만, 만약 화면에 직사각형을 그리려 한다면 문제가 됩니다! width 가 튜플 인덱스 0 이고 height 가 인덱스 1 이라는 사실을 계속 기억해야 하기 때문입니다. 코드를 사용하는 다른 사람에게는 이 사실을 파악하고 계속 염두에 두는 일이 더 어려울 것입니다. 데이터의 의미를 코드에 충분히 드러내지 않았기 때문에, 오히려 오류를 만들기 쉬운 상태가 되었습니다.

구조체로 리팩터링하기

구조체를 사용하면 데이터에 이름을 붙여 의미를 더할 수 있습니다. 튜플로 표현하던 것을 목록 5-10처럼, 전체에도 이름이 있고 각 부분에도 이름이 있는 구조체로 바꿀 수 있습니다.

struct Rectangle {
    width: u32,
    height: u32,
}

fn main() {
    let rect1 = Rectangle {
        width: 30,
        height: 50,
    };

    println!(
        "The area of the rectangle is {} square pixels.",
        area(&rect1)
    );
}

fn area(rectangle: &Rectangle) -> u32 {
    rectangle.width * rectangle.height
}

여기서는 구조체를 정의하고 이름을 Rectangle 로 붙였습니다. 중괄호 안에는 width 와 height 라는 필드를 정의했고, 둘 다 타입은 u32 입니다. 그리고 main 안에서는 너비가 30, 높이가 50 인 특정 Rectangle 인스턴스를 만들었습니다.

이제 area 함수는 rectangle 이라는 이름의 하나의 매개변수만 받는데, 그 타입은 Rectangle 구조체 인스턴스에 대한 불변 대여입니다. 4장에서 설명했듯이, 구조체의 소유권을 가져가는 대신 빌려 쓰고 싶기 때문에 참조를 사용합니다. 그렇게 하면 main 이 소유권을 계속 유지할 수 있고, 그래서 함수 시그니처와 호출 부분에 & 를 붙입니다.

area 함수는 Rectangle 인스턴스의 width, height 필드에 접근합니다 (빌린 구조체 인스턴스의 필드에 접근하는 것은 필드 값을 이동시키지 않는다는 점에 주의하세요. 그래서 러스트에서는 구조체를 빌리는 코드를 자주 보게 됩니다). 이제 area 의 함수 시그니처는 우리가 의도한 바를 정확히 말해 줍니다. Rectangle 의 넓이를 width 와 height 필드를 사용해 계산하라는 뜻입니다. 이렇게 하면 너비와 높이가 서로 관련된 값이라는 사실이 드러나고, 튜플 인덱스 0, 1 대신 설명적인 이름을 붙일 수 있습니다. 명확성 면에서 훨씬 낫습니다.

파생 트레이트로 유용한 기능 추가하기

프로그램을 디버깅할 때 Rectangle 인스턴스를 출력하고, 모든 필드 값을 한꺼번에 볼 수 있다면 유용할 것입니다. 목록 5-11은 우리가 앞 장들에서 써 왔던 것처럼 println! 매크로를 사용해 보려 하지만, 이 코드는 동작하지 않습니다.

struct Rectangle {
    width: u32,
    height: u32,
}

fn main() {
    let rect1 = Rectangle {
        width: 30,
        height: 50,
    };

    println!("rect1 is {rect1}");
}

이 코드를 컴파일하면 핵심적으로 다음과 같은 오류 메시지를 받게 됩니다.

error[E0277]: `Rectangle` doesn't implement `std::fmt::Display`

println! 매크로는 여러 가지 출력 형식을 지원하며, 기본적으로 중괄호는 Display 라는 형식을 사용하라는 뜻입니다. 이것은 최종 사용자가 바로 소비할 출력을 의도한 형식입니다. 지금까지 본 기본 타입들은 사용자에게 1 이나 다른 기본값을 보여 주는 방식이 사실상 하나뿐이므로 기본적으로 Display 를 구현합니다. 하지만 구조체는 상황이 다릅니다. println! 이 어떤 형식으로 출력해야 할지가 명확하지 않기 때문입니다. 쉼표를 넣을까요? 중괄호를 출력할까요? 모든 필드를 보여 줄까요? 이런 모호함 때문에, 러스트는 우리가 무엇을 원하는지 추측하지 않습니다. 그래서 구조체에는 println! 과 {} 플레이스홀더에 사용할 수 있는 Display 구현이 기본 제공되지 않습니다.

오류 메시지를 더 읽어 내려가면 이런 도움말을 찾을 수 있습니다.

   |                        |`Rectangle` cannot be formatted with the default formatter
   |                        required by this formatting parameter

한번 해 봅시다! 이제 println! 호출은 println!("rect1 is {rect1:?}"); 처럼 생기게 됩니다. 중괄호 안에 :? 지정자를 넣으면, println! 에게 Debug 라는 출력 형식을 사용하고 싶다고 알려 주는 것입니다. Debug 트레이트는 개발자에게 유용한 형식으로 구조체를 출력하게 해 주어, 디버깅 중에 그 값을 확인할 수 있게 합니다.

이 변경을 적용한 뒤 코드를 컴파일해 보세요. 아쉽게도 여전히 오류가 납니다.

error[E0277]: `Rectangle` doesn't implement `Debug`

하지만 이번에도 컴파일러는 유용한 힌트를 줍니다.

   |                        required by this formatting parameter
   |

러스트는 실제로 디버깅 정보를 출력하는 기능을 제공하지만, 우리 구조체에서 그 기능을 쓰겠다고 명시적으로 선택해야 합니다. 그렇게 하려면 목록 5-12처럼 구조체 정의 바로 앞에 #[derive(Debug)] 라는 바깥 속성을 추가합니다.

#[derive(Debug)]
struct Rectangle {
    width: u32,
    height: u32,
}

fn main() {
    let rect1 = Rectangle {
        width: 30,
        height: 50,
    };

    println!("rect1 is {rect1:?}");
}

이제 프로그램을 실행하면 오류는 사라지고, 다음과 같은 출력을 보게 됩니다.

$ cargo run
   Compiling rectangles v0.1.0 (file:///projects/rectangles)
    Finished `dev` profile [unoptimized + debuginfo] target(s) in 0.48s
     Running `target/debug/rectangles`
rect1 is Rectangle { width: 30, height: 50 }

좋습니다! 아주 예쁜 출력은 아니지만, 이 인스턴스의 모든 필드 값을 보여 주므로 디버깅에는 분명 도움이 됩니다. 구조체가 더 커지면 조금 더 읽기 쉬운 출력이 필요할 수 있는데, 그런 경우에는 println! 문자열에서 {:?} 대신 {:#?} 를 사용할 수 있습니다. 이 예제에서 {:#?} 스타일을 사용하면 다음과 같이 출력됩니다.

$ cargo run
   Compiling rectangles v0.1.0 (file:///projects/rectangles)
    Finished `dev` profile [unoptimized + debuginfo] target(s) in 0.48s
     Running `target/debug/rectangles`
rect1 is Rectangle {
    width: 30,
    height: 50,
}

또 다른 방법으로는 dbg! 매크로를 사용할 수 있습니다. dbg! 는 참조를 받는 println! 과 달리, 식의 소유권을 가져와서 그 식이 있는 파일과 줄 번호, 그리고 그 식의 결과값을 함께 출력한 뒤, 다시 그 값의 소유권을 반환합니다.

다음은 width 필드에 대입될 값과 rect1 구조체 전체 값을 함께 보고 싶은 예입니다.

#[derive(Debug)]
struct Rectangle {
    width: u32,
    height: u32,
}

fn main() {
    let scale = 2;
    let rect1 = Rectangle {
        width: dbg!(30 * scale),
        height: 50,
    };

    dbg!(&rect1);
}

30 * scale 식을 dbg! 로 감싸면, dbg! 는 식의 값 소유권을 돌려주기 때문에 width 필드는 dbg! 가 없을 때와 같은 값을 그대로 갖게 됩니다. 반면 rect1 의 소유권은 dbg! 에 빼앗기고 싶지 않으므로, 다음 호출에서는 &rect1 처럼 참조를 전달합니다. 이 예제의 출력은 다음과 같습니다.

$ cargo run
   Compiling rectangles v0.1.0 (file:///projects/rectangles)
    Finished `dev` profile [unoptimized + debuginfo] target(s) in 0.61s
     Running `target/debug/rectangles`
[src/main.rs:10:16] 30 * scale = 60
[src/main.rs:14:5] &rect1 = Rectangle {
    width: 60,
    height: 50,
}

첫 번째 출력은 src/main.rs 10번째 줄에서 30 * scale 식을 디버깅한 결과이며, 그 값은 60 입니다(정수에 구현된 Debug 형식은 값만 출력합니다). src/main.rs 14번째 줄의 dbg! 호출은 &rect1 의 값을 출력하고, 이 출력은 Rectangle 타입의 예쁜 Debug 형식을 사용합니다. dbg! 매크로는 코드가 실제로 무엇을 하고 있는지 파악할 때 아주 도움이 됩니다.

Debug 트레이트 외에도, 러스트는 derive 속성과 함께 사용할 수 있는 여러 트레이트를 제공하며, 이것들은 사용자 정의 타입에 유용한 동작을 추가해 줍니다. 그런 트레이트와 그 동작 목록은 부록 C에 정리되어 있습니다. 10장에서는 이런 트레이트를 직접 구현해 원하는 동작을 정의하는 방법과, 여러분 자신의 트레이트를 만드는 방법도 다룹니다. 또한 derive 외에도 다양한 속성이 있는데, 자세한 내용은 Rust Reference의 “Attributes” 절을 참고하세요.

현재 area 함수는 매우 특수합니다. 사각형 넓이만 계산할 수 있습니다. 이 동작을 Rectangle 구조체와 더 강하게 연결할 수 있다면 좋겠습니다. 다른 타입에서는 동작하지 않기 때문입니다. 다음으로는 area 함수를 Rectangle 타입 위에 정의된 area 메서드로 바꾸면서 이 코드를 계속 리팩터링해 보겠습니다.

메서드

메서드

메서드는 함수와 비슷합니다. fn 키워드와 이름으로 선언하고, 매개변수와 반환값을 가질 수 있으며, 다른 곳에서 메서드가 호출되었을 때 실행할 코드를 포함합니다. 하지만 함수와 달리 메서드는 구조체(또는 6장과 18장에서 각각 다룰 enum, trait object)의 맥락 안에서 정의되며, 첫 번째 매개변수는 언제나 self 입니다. self 는 메서드가 호출되는 구조체 인스턴스를 나타냅니다.

메서드 문법

Rectangle 인스턴스를 매개변수로 받는 area 함수를 바꿔, 목록 5-13처럼 Rectangle 구조체 위에 정의된 area 메서드로 만들어 봅시다.

#[derive(Debug)]
struct Rectangle {
    width: u32,
    height: u32,
}

impl Rectangle {
    fn area(&self) -> u32 {
        self.width * self.height
    }
}

fn main() {
    let rect1 = Rectangle {
        width: 30,
        height: 50,
    };

    println!(
        "The area of the rectangle is {} square pixels.",
        rect1.area()
    );
}

함수를 Rectangle 의 맥락 안에서 정의하려면 먼저 Rectangle 에 대한 impl (implementation) 블록을 시작합니다. 이 impl 블록 안에 있는 모든 것은 Rectangle 타입과 연관됩니다. 그런 다음 area 함수를 impl 중괄호 안으로 옮기고, 첫 번째 매개변수(이 경우 유일한 매개변수)를 시그니처와 본문 모두에서 self 로 바꿉니다. main 에서는 원래 area 함수에 rect1 을 인수로 넘겨 호출했지만, 이제는 메서드 문법 을 사용해 Rectangle 인스턴스 위에서 직접 area 메서드를 호출할 수 있습니다. 메서드 문법은 인스턴스 뒤에 점과 메서드 이름, 괄호, 그리고 필요한 인수를 붙이는 형태입니다.

area 의 시그니처에서는 rectangle: &Rectangle 대신 &self 를 사용합니다. 사실 &self 는 self: &Self 의 축약형입니다. impl 블록 안에서 Self 타입은 이 impl 블록이 구현하는 타입의 별칭이며, 여기서는 Rectangle 입니다. 메서드는 첫 번째 매개변수로 Self 타입의 self 라는 이름을 가져야 하므로, 러스트는 첫 번째 매개변수 자리에서 이 표현을 단순히 self 로 줄여 쓰도록 허용합니다. 또한 이 메서드가 Self 인스턴스를 빌려 쓴다는 사실을 나타내려면, rectangle: &Rectangle 에서 했던 것처럼 self 앞에 여전히 & 를 붙여야 한다는 점에 주의하세요. 메서드는 다른 매개변수와 마찬가지로 self 의 소유권을 가져갈 수도 있고, 여기처럼 불변으로 빌릴 수도 있으며, 가변으로 빌릴 수도 있습니다.

여기서 &self 를 선택한 이유는 함수 버전에서 &Rectangle 을 사용했던 이유와 같습니다. 소유권을 가져가고 싶지 않고, 구조체 안의 데이터를 읽기만 하고 싶기 때문입니다. 만약 메서드가 하는 일의 일부로 호출 대상 인스턴스를 바꾸고 싶다면, 첫 번째 매개변수로 &mut self 를 사용했을 것입니다. 첫 번째 매개변수로 그냥 self 를 사용해 인스턴스 소유권을 가져가는 메서드는 드문 편이며, 보통은 메서드가 self 를 다른 무언가로 변형시키고 난 뒤, 원래 인스턴스를 더 이상 호출자가 사용하지 못하게 하고 싶을 때 사용합니다.

메서드를 함수 대신 사용하는 가장 큰 이유는 메서드 문법을 제공하고, 메서드 시그니처마다 self 의 타입을 반복해서 적지 않아도 된다는 점 외에도, 코드 조직화 측면에 있습니다. 특정 타입 인스턴스로 할 수 있는 일들을 모두 하나의 impl 블록 안에 모아 둘 수 있으므로, 우리 라이브러리를 사용하는 사람이 Rectangle 관련 기능을 여기저기서 찾아다닐 필요가 없습니다.

구조체 필드 이름과 메서드 이름을 같게 지을 수도 있다는 점도 알아 두세요. 예를 들어 Rectangle 에 width 라는 이름의 메서드를 정의할 수 있습니다.

#[derive(Debug)]
struct Rectangle {
    width: u32,
    height: u32,
}

impl Rectangle {
    fn width(&self) -> bool {
        self.width > 0
    }
}

fn main() {
    let rect1 = Rectangle {
        width: 30,
        height: 50,
    };

    if rect1.width() {
        println!("The rectangle has a nonzero width; it is {}", rect1.width);
    }
}

여기서 우리는 width 필드 값이 0보다 크면 true, 0이면 false 를 반환하는 width 메서드를 만들기로 했습니다. 이렇게 같은 이름의 필드를 메서드 안에서 다른 목적으로 얼마든지 사용할 수 있습니다. main 에서 rect1.width 뒤에 괄호를 붙이면 러스트는 우리가 width 메서드를 의미한다고 압니다. 괄호가 없으면 width 필드를 의미한다고 압니다.

언제나 그런 것은 아니지만, 메서드 이름을 필드 이름과 같게 지을 때는 그 메서드가 대개 필드 값을 그대로 반환하고 다른 일은 하지 않도록 만들고 싶어 하는 경우가 많습니다. 이런 메서드를 getter 라고 합니다. 러스트는 다른 일부 언어와 달리 구조체 필드에 대한 getter를 자동으로 만들어 주지 않습니다. getter는 필드는 비공개로 두되 메서드는 공개로 만들어, 타입의 공개 API 일부로 읽기 전용 접근을 제공하고 싶을 때 유용합니다. 공개와 비공개가 무엇인지, 필드와 메서드를 어떻게 공개/비공개로 표시하는지는 7장에서 설명합니다.

#![allow(unused)]
fn main() {
#[derive(Debug,Copy,Clone)]
struct Point {
    x: f64,
    y: f64,
}

impl Point {
   fn distance(&self, other: &Point) -> f64 {
       let x_squared = f64::powi(other.x - self.x, 2);
       let y_squared = f64::powi(other.y - self.y, 2);

       f64::sqrt(x_squared + y_squared)
   }
}
let p1 = Point { x: 0.0, y: 0.0 };
let p2 = Point { x: 5.0, y: 6.5 };
p1.distance(&p2);
(&p1).distance(&p2);
}

추가 매개변수를 가지는 메서드

메서드를 직접 하나 더 구현해 보면서 연습해 봅시다. 이번에는 Rectangle 인스턴스가 또 다른 Rectangle 인스턴스를 받아, 두 번째 Rectangle 이 self(첫 번째 Rectangle) 안에 완전히 들어갈 수 있으면 true, 그렇지 않으면 false 를 반환하게 하고 싶습니다. 즉, can_hold 메서드를 정의한 뒤에는 목록 5-14와 같은 프로그램을 작성할 수 있어야 합니다.

fn main() {
    let rect1 = Rectangle {
        width: 30,
        height: 50,
    };
    let rect2 = Rectangle {
        width: 10,
        height: 40,
    };
    let rect3 = Rectangle {
        width: 60,
        height: 45,
    };

    println!("Can rect1 hold rect2? {}", rect1.can_hold(&rect2));
    println!("Can rect1 hold rect3? {}", rect1.can_hold(&rect3));
}

예상 출력은 다음과 같습니다. rect2 는 두 치수 모두 rect1 보다 작지만, rect3 는 rect1 보다 더 넓기 때문입니다.

Can rect1 hold rect2? true
Can rect1 hold rect3? false

우리는 메서드를 정의하려는 것이므로, 이것은 impl Rectangle 블록 안에 들어가게 됩니다. 메서드 이름은 can_hold 이고, 또 다른 Rectangle 에 대한 불변 대여를 매개변수로 받을 것입니다. 이 매개변수의 타입은 메서드를 호출하는 코드를 보면 알 수 있습니다. rect1.can_hold(&rect2) 는 &rect2 를 넘기는데, 이것은 Rectangle 인스턴스 rect2 에 대한 불변 대여입니다. 이는 자연스럽습니다. 우리는 rect2 를 읽기만 하면 되고(쓰기 위해서는 가변 대여가 필요합니다), 메서드 호출 후에도 main 이 rect2 의 소유권을 유지해 다시 사용할 수 있게 하고 싶기 때문입니다. can_hold 의 반환값은 불리언이고, 구현은 self 의 너비와 높이가 각각 다른 Rectangle 의 너비와 높이보다 큰지 확인하면 됩니다. 목록 5-15처럼 목록 5-13의 impl 블록 안에 새 can_hold 메서드를 추가해 봅시다.

#[derive(Debug)]
struct Rectangle {
    width: u32,
    height: u32,
}

impl Rectangle {
    fn area(&self) -> u32 {
        self.width * self.height
    }

    fn can_hold(&self, other: &Rectangle) -> bool {
        self.width > other.width && self.height > other.height
    }
}

fn main() {
    let rect1 = Rectangle {
        width: 30,
        height: 50,
    };
    let rect2 = Rectangle {
        width: 10,
        height: 40,
    };
    let rect3 = Rectangle {
        width: 60,
        height: 45,
    };

    println!("Can rect1 hold rect2? {}", rect1.can_hold(&rect2));
    println!("Can rect1 hold rect3? {}", rect1.can_hold(&rect3));
}

이제 목록 5-14의 main 함수와 함께 이 코드를 실행하면 원하는 출력이 나옵니다. 메서드는 self 매개변수 뒤에 원하는 만큼의 추가 매개변수를 받을 수 있고, 그 매개변수들은 함수의 매개변수와 똑같이 동작합니다.

연관 함수

impl 블록 안에 정의된 모든 함수는 연관 함수(associated functions) 라고 부릅니다. impl 뒤에 적힌 타입과 연관되어 있기 때문입니다. 이들 중에는 첫 번째 매개변수로 self 를 갖지 않는 함수도 정의할 수 있습니다(따라서 메서드는 아닙니다). 그런 함수들은 작업하는 데 타입의 인스턴스가 필요하지 않기 때문입니다. 우리는 이미 이런 함수 하나를 사용해 봤습니다. String 타입에 정의된 String::from 함수입니다.

메서드가 아닌 연관 함수는 보통 새 구조체 인스턴스를 반환하는 생성자 역할에 자주 사용합니다. 이런 함수 이름은 흔히 new 이지만, new 는 특별한 이름도 아니고 언어에 내장된 것도 아닙니다. 예를 들어 한 개의 길이만 받아 그 값을 너비와 높이 둘 다로 사용함으로써 정사각형 Rectangle 을 더 쉽게 만들 수 있도록, square 라는 연관 함수를 제공한다고 해 봅시다. 이렇게 하면 같은 값을 두 번 적지 않아도 됩니다.

파일명: src/main.rs

#[derive(Debug)]
struct Rectangle {
    width: u32,
    height: u32,
}

impl Rectangle {
    fn square(size: u32) -> Self {
        Self {
            width: size,
            height: size,
        }
    }
}

fn main() {
    let sq = Rectangle::square(3);
}

함수의 반환 타입과 본문에 있는 Self 키워드는 impl 키워드 뒤에 오는 타입의 별칭인데, 이 경우에는 Rectangle 입니다.

이 연관 함수를 호출하려면 구조체 이름과 함께 :: 문법을 사용합니다. 예를 들어 let sq = Rectangle::square(3); 처럼 씁니다. 이 함수는 구조체에 의해 네임스페이스가 나뉘어 있습니다. :: 문법은 연관 함수뿐 아니라 모듈이 만드는 네임스페이스에도 사용됩니다. 모듈은 7장에서 다룹니다.

여러 개의 impl 블록

각 구조체는 여러 개의 impl 블록을 가질 수 있습니다. 예를 들어 목록 5-15는, 각 메서드를 별도의 impl 블록에 넣은 목록 5-16의 코드와 동등합니다.

#[derive(Debug)]
struct Rectangle {
    width: u32,
    height: u32,
}

impl Rectangle {
    fn area(&self) -> u32 {
        self.width * self.height
    }
}

impl Rectangle {
    fn can_hold(&self, other: &Rectangle) -> bool {
        self.width > other.width && self.height > other.height
    }
}

fn main() {
    let rect1 = Rectangle {
        width: 30,
        height: 50,
    };
    let rect2 = Rectangle {
        width: 10,
        height: 40,
    };
    let rect3 = Rectangle {
        width: 60,
        height: 45,
    };

    println!("Can rect1 hold rect2? {}", rect1.can_hold(&rect2));
    println!("Can rect1 hold rect3? {}", rect1.can_hold(&rect3));
}

여기서는 메서드를 굳이 여러 impl 블록으로 나눌 이유가 없지만, 문법적으로는 유효합니다. 10장에서 제네릭 타입과 트레이트를 다룰 때 여러 impl 블록이 유용한 경우를 보게 됩니다.

정리

구조체는 도메인에 의미가 있는 사용자 정의 타입을 만들 수 있게 해 줍니다. 구조체를 사용하면 서로 관련된 데이터 조각을 한데 묶어 두고, 각 조각에 이름을 붙여 코드가 무엇을 의미하는지 더 분명하게 만들 수 있습니다. impl 블록 안에서는 타입과 연관된 함수를 정의할 수 있고, 메서드는 그 연관 함수의 한 종류로서 구조체 인스턴스가 어떤 동작을 하는지를 표현하게 해 줍니다.

하지만 사용자 정의 타입을 만드는 방법이 구조체뿐인 것은 아닙니다. 이제 러스트의 enum 기능으로 넘어가, 도구 상자에 또 하나의 중요한 도구를 추가해 봅시다.

열거형과 패턴 매칭

이 장에서는 enum 이라고도 부르는 열거형(enumeration)을 살펴봅니다. enum은 가능한 variant들을 열거함으로써 타입을 정의하게 해 줍니다. 먼저 enum을 정의하고 사용하는 방법을 보면서, enum이 데이터를 담는 동시에 의미도 표현할 수 있음을 보여 주겠습니다. 다음으로는 값이 어떤 것이거나 아무 것도 아닐 수 있음을 표현하는, 특히 유용한 Option 이라는 enum을 살펴봅니다. 그런 뒤 match 식 안의 패턴 매칭이 enum의 서로 다른 값에 따라 다른 코드를 실행하는 일을 얼마나 쉽게 만드는지 봅니다. 마지막으로, 코드에서 enum을 다룰 때 사용할 수 있는 또 다른 편리하고 간결한 관용구인 if let 구문을 다룹니다.

열거형 정의하기

열거형 정의하기

구조체가 width 와 height 를 가진 Rectangle 처럼 관련된 필드와 데이터를 함께 묶는 방법을 제공한다면, enum은 어떤 값이 “가능한 값들의 집합 중 하나”라고 말할 수 있는 방법을 제공합니다. 예를 들어 Rectangle 이 Circle, Triangle 도 포함하는 여러 가능한 도형 중 하나라고 표현하고 싶을 수 있습니다. 이를 위해 러스트는 이런 가능성들을 enum으로 인코딩하게 해 줍니다.

코드에서 표현하고 싶은 한 가지 상황을 살펴보면서, 왜 이 경우 enum이 유용하고 구조체보다 더 적절한지 알아봅시다. IP 주소를 다뤄야 한다고 해 보겠습니다. 현재 IP 주소에는 두 가지 주요 표준이 있습니다. 버전 4와 버전 6입니다. 프로그램이 만날 수 있는 IP 주소의 가능성은 이 둘뿐이므로, 우리는 가능한 모든 variant를 열거(enumerate) 할 수 있습니다. 열거형(enumeration)이라는 이름도 여기서 나옵니다.

어떤 IP 주소든 버전 4이거나 버전 6일 수는 있지만, 동시에 둘 다일 수는 없습니다. 이 특성 때문에 enum 데이터 구조가 적합합니다. enum 값은 그 variant 중 하나만 될 수 있기 때문입니다. 버전 4 주소와 버전 6 주소는 둘 다 본질적으로 IP 주소이므로, 코드가 “모든 종류의 IP 주소에 공통으로 적용되는 상황”을 다룰 때는 같은 타입으로 취급되어야 합니다.

이 개념은 IpAddrKind 라는 enum을 정의하고, IP 주소가 될 수 있는 종류인 V4, V6 를 나열함으로써 코드로 표현할 수 있습니다. 이것들이 enum의 variant입니다.

enum IpAddrKind {
    V4,
    V6,
}

fn main() {
    let four = IpAddrKind::V4;
    let six = IpAddrKind::V6;

    route(IpAddrKind::V4);
    route(IpAddrKind::V6);
}

fn route(ip_kind: IpAddrKind) {}

이제 IpAddrKind 는 코드의 다른 곳에서도 사용할 수 있는 사용자 정의 데이터 타입이 되었습니다.

enum 값

IpAddrKind 의 두 variant 각각의 인스턴스는 다음처럼 만들 수 있습니다.

enum IpAddrKind {
    V4,
    V6,
}

fn main() {
    let four = IpAddrKind::V4;
    let six = IpAddrKind::V6;

    route(IpAddrKind::V4);
    route(IpAddrKind::V6);
}

fn route(ip_kind: IpAddrKind) {}

enum의 variant는 그 enum 식별자 아래에 네임스페이스가 나뉘어 있으며, 둘을 구분할 때 이중 콜론을 사용한다는 점에 주목하세요. 이는 유용합니다. 왜냐하면 IpAddrKind::V4 와 IpAddrKind::V6 가 둘 다 같은 타입, 즉 IpAddrKind 이기 때문입니다. 따라서 예를 들어 어떤 IpAddrKind 든 받을 수 있는 함수를 정의할 수 있습니다.

enum IpAddrKind {
    V4,
    V6,
}

fn main() {
    let four = IpAddrKind::V4;
    let six = IpAddrKind::V6;

    route(IpAddrKind::V4);
    route(IpAddrKind::V6);
}

fn route(ip_kind: IpAddrKind) {}

그리고 이 함수는 어느 variant로도 호출할 수 있습니다.

enum IpAddrKind {
    V4,
    V6,
}

fn main() {
    let four = IpAddrKind::V4;
    let six = IpAddrKind::V6;

    route(IpAddrKind::V4);
    route(IpAddrKind::V6);
}

fn route(ip_kind: IpAddrKind) {}

enum을 사용하는 데는 더 많은 장점이 있습니다. IP 주소 타입을 더 생각해 보면, 지금은 실제 IP 주소 데이터 를 저장할 방법이 없습니다. 지금은 단지 그것이 어떤 종류 인지만 알고 있을 뿐입니다. 여러분은 5장에서 구조체를 배웠으니, 이 문제를 목록 6-1처럼 구조체로 해결하고 싶어질 수도 있습니다.

fn main() {
    enum IpAddrKind {
        V4,
        V6,
    }

    struct IpAddr {
        kind: IpAddrKind,
        address: String,
    }

    let home = IpAddr {
        kind: IpAddrKind::V4,
        address: String::from("127.0.0.1"),
    };

    let loopback = IpAddr {
        kind: IpAddrKind::V6,
        address: String::from("::1"),
    };
}

여기서는 IpAddr 라는 구조체를 정의했고, 두 개의 필드를 가집니다. 하나는 앞에서 정의한 enum 타입 IpAddrKind 를 가지는 kind 필드이고, 다른 하나는 String 타입의 address 필드입니다. 그리고 이 구조체의 인스턴스를 두 개 만들었습니다. 첫 번째 인스턴스 home 은 kind 값으로 IpAddrKind::V4 를 가지고, 그에 대응하는 주소 데이터는 127.0.0.1 입니다. 두 번째 인스턴스 loopback 은 kind 값으로 다른 variant인 V6 를 가지며, 주소 ::1 을 함께 가집니다. 즉, 구조체를 사용해 kind 와 address 값을 하나로 묶어 둔 것입니다.

하지만 같은 개념은 enum만으로도 더 간결하게 표현할 수 있습니다. 구조체 안에 enum을 넣는 대신, enum variant 각각에 직접 데이터를 담을 수 있습니다. 다음 IpAddr enum 정의는 V4 와 V6 variant가 모두 String 값을 함께 가진다고 말합니다.

fn main() {
    enum IpAddr {
        V4(String),
        V6(String),
    }

    let home = IpAddr::V4(String::from("127.0.0.1"));

    let loopback = IpAddr::V6(String::from("::1"));
}

이제 각 enum variant에 데이터를 직접 붙였습니다. 그래서 별도의 구조체가 더 이상 필요하지 않습니다. 여기서는 enum이 어떻게 동작하는지에 대한 또 다른 중요한 세부도 더 쉽게 보입니다. 우리가 정의한 각 enum variant 이름은 그 enum 인스턴스를 만드는 함수 역할도 한다는 점입니다. 즉 IpAddr::V4() 는 String 인수를 받아 IpAddr 타입 인스턴스를 반환하는 함수 호출입니다. enum을 정의하는 것만으로 이런 생성자 함수를 자동으로 얻게 됩니다.

구조체 대신 enum을 사용하는 또 다른 장점은, 각 variant가 서로 다른 타입과 개수의 데이터를 가질 수 있다는 점입니다. 버전 4 IP 주소는 항상 0에서 255 사이의 값을 가진 숫자 네 개로 이루어집니다. 만약 V4 주소는 네 개의 u8 값으로 저장하되, V6 주소는 하나의 String 값으로 표현하고 싶다면 구조체만으로는 어렵습니다. 하지만 enum은 이를 쉽게 처리할 수 있습니다.

fn main() {
    enum IpAddr {
        V4(u8, u8, u8, u8),
        V6(String),
    }

    let home = IpAddr::V4(127, 0, 0, 1);

    let loopback = IpAddr::V6(String::from("::1"));
}

지금까지 버전 4와 버전 6 IP 주소를 저장하기 위한 데이터 구조를 여러 방식으로 정의해 보았습니다. 그런데 알고 보면, IP 주소 자체를 저장하고 동시에 그것이 어떤 종류인지도 표현하고 싶어 하는 일은 너무 흔해서 표준 라이브러리에 이미 사용할 수 있는 정의가 있습니다. 표준 라이브러리가 IpAddr 를 어떻게 정의하는지 봅시다. 방금 우리가 직접 정의해 사용한 것과 정확히 같은 enum과 variant를 갖고 있지만, 주소 데이터는 각 variant마다 서로 다르게 정의된 두 구조체 형태로 안에 넣고 있습니다.

#![allow(unused)]
fn main() {
struct Ipv4Addr {
    // --snip--
}

struct Ipv6Addr {
    // --snip--
}

enum IpAddr {
    V4(Ipv4Addr),
    V6(Ipv6Addr),
}
}

이 코드는 enum variant 안에 문자열, 숫자 타입, 구조체 등 어떤 종류의 데이터든 넣을 수 있음을 보여 줍니다. 심지어 다른 enum을 넣는 것도 가능합니다! 또한 표준 라이브러리의 타입들은 여러분이 직접 생각해 낼 수 있는 것보다 훨씬 더 복잡하지만은 않은 경우가 많습니다.

표준 라이브러리에 IpAddr 정의가 있더라도, 우리는 그 정의를 스코프로 가져오지 않았기 때문에 충돌 없이 우리 자신의 정의를 여전히 만들고 사용할 수 있다는 점에 주목하세요. 타입을 스코프로 가져오는 방법은 7장에서 더 이야기합니다.

이제 표준 라이브러리에서 또 하나 흔하고 유용한 enum을 살펴봅시다. 목록 6-2는 여러 variant 안에 다양한 타입이 들어 있는 enum의 예입니다.

enum Message {
    Quit,
    Move { x: i32, y: i32 },
    Write(String),
    ChangeColor(i32, i32, i32),
}

fn main() {}

이 enum은 서로 다른 타입을 가진 네 개의 variant를 가집니다.

• Quit: 어떤 데이터도 전혀 가지지 않습니다
• Move: 구조체처럼 이름 붙은 필드를 가집니다
• Write: 하나의 String 을 가집니다
• ChangeColor: 세 개의 i32 값을 가집니다

목록 6-2처럼 variant가 서로 다른 형태를 가지는 enum을 정의하는 것은, 여러 종류의 구조체를 각각 따로 정의하는 것과 비슷합니다. 다만 enum은 struct 키워드를 사용하지 않고, 모든 variant가 하나의 Message 타입 아래에 함께 묶입니다. 다음 구조체들은 앞의 enum variant들이 담고 있던 것과 같은 데이터를 저장할 수 있습니다.

struct QuitMessage; // unit struct
struct MoveMessage {
    x: i32,
    y: i32,
}
struct WriteMessage(String); // tuple struct
struct ChangeColorMessage(i32, i32, i32); // tuple struct

fn main() {}

하지만 이렇게 서로 다른 구조체를 각각 사용하면, 각기 다른 타입을 가진 값들을 모두 받는 함수를 정의하기가 쉽지 않습니다. 반면 목록 6-2의 Message enum은 하나의 타입이므로 훨씬 간단합니다.

enum과 구조체 사이에는 또 다른 공통점이 있습니다. 구조체에 대해 impl 을 사용해 메서드를 정의할 수 있듯이, enum에도 메서드를 정의할 수 있습니다. 다음은 Message enum 위에 정의할 수 있는 call 이라는 메서드입니다.

fn main() {
    enum Message {
        Quit,
        Move { x: i32, y: i32 },
        Write(String),
        ChangeColor(i32, i32, i32),
    }

    impl Message {
        fn call(&self) {
            // method body would be defined here
        }
    }

    let m = Message::Write(String::from("hello"));
    m.call();
}

메서드 본문은 self 를 사용해 메서드가 호출된 값을 가져옵니다. 이 예제에서는 Message::Write(String::from("hello")) 값을 가지는 변수 m 을 만들었고, m.call() 이 실행될 때 call 메서드 본문 안에서 self 는 바로 이 값이 됩니다.

이제 표준 라이브러리의 또 다른, 아주 흔하고 유용한 enum인 Option 을 살펴봅시다.

Option enum

이 절에서는 표준 라이브러리가 정의한 또 다른 enum인 Option 을 사례 연구처럼 살펴봅니다. Option 타입은 값이 어떤 것일 수도 있고, 아무 것도 아닐 수도 있는 아주 흔한 상황을 표현합니다.

예를 들어 비어 있지 않은 리스트에서 첫 번째 항목을 요청하면 값을 얻게 됩니다. 하지만 빈 리스트에서 첫 번째 항목을 요청하면 아무 것도 얻지 못합니다. 이런 개념을 타입 시스템으로 표현하면, 컴파일러는 여러분이 처리해야 할 모든 경우를 다루었는지 검사할 수 있습니다. 이런 기능은 다른 프로그래밍 언어에서 매우 흔한 버그를 막는 데 도움이 됩니다.

프로그래밍 언어 설계는 흔히 어떤 기능을 포함하느냐의 관점에서 이야기되지만, 어떤 기능을 제외하느냐 도 똑같이 중요합니다. 러스트에는 많은 다른 언어가 가진 null 기능이 없습니다. Null 은 거기에 값이 없다는 뜻의 값입니다. null이 있는 언어에서는 변수가 늘 두 가지 상태 중 하나가 될 수 있습니다. null 이거나, null 이 아니거나.

2009년 “Null References: The Billion Dollar Mistake” 발표에서, null의 창시자 Tony Hoare는 이렇게 말했습니다.

나는 이것을 내 10억 달러짜리 실수라고 부른다. 그 당시 나는 객체 지향 언어에서 참조를 위한 최초의 포괄적인 타입 시스템을 설계하고 있었다. 내 목표는 참조의 모든 사용이 절대적으로 안전하도록 만들고, 그 검사를 컴파일러가 자동으로 수행하게 하는 것이었다. 그러나 null 참조를 넣고 싶은 유혹을 이기지 못했다. 구현이 너무 쉬웠기 때문이다. 그 결과 수많은 오류와 취약점, 시스템 충돌이 발생했고, 지난 40년 동안 아마 10억 달러에 해당하는 고통과 피해를 만들어 냈을 것이다.

Null 값의 문제는, null 값을 null 이 아닌 값처럼 사용하려 하면 어떤 형태로든 오류가 발생한다는 점입니다. 그리고 “null 이거나 아니거나” 라는 성질은 너무 널리 퍼져 있어, 이런 종류의 실수를 저지르기가 매우 쉽습니다.

하지만 null이 표현하려던 개념 자체는 여전히 유용합니다. 어떤 이유로든 현재 값이 유효하지 않거나 존재하지 않는 상태를 나타내는 것이니까요.

문제는 사실 개념 자체가 아니라 구체적인 구현 방식에 있습니다. 그래서 러스트는 null은 없지만, 값의 존재 여부를 표현할 수 있는 enum을 제공합니다. 이 enum이 바로 Option<T> 이며, 표준 라이브러리에서 다음과 같이 정의되어 있습니다.

#![allow(unused)]
fn main() {
enum Option<T> {
    None,
    Some(T),
}
}

Option<T> enum은 너무 유용해서 prelude에 포함되어 있습니다. 즉 명시적으로 스코프로 가져올 필요가 없습니다. 그 variant 역시 prelude에 포함되어 있으므로 Option:: 접두사 없이 Some, None 을 바로 쓸 수 있습니다. 물론 Option<T> 는 여전히 그저 평범한 enum이고, Some(T) 와 None 역시 Option<T> 타입의 variant입니다.

<T> 문법은 아직 이야기하지 않은 러스트의 기능입니다. 이것은 제네릭 타입 매개변수이며, 10장에서 더 자세히 다룹니다. 지금은 <T> 가 Option enum의 Some variant가 아무 타입의 데이터 하나를 담을 수 있다는 뜻이고, T 자리에 구체적인 타입이 들어올 때마다 전체 Option<T> 타입도 서로 다른 타입이 된다는 점만 알면 충분합니다. 다음은 숫자 타입과 문자 타입을 담는 Option 값을 사용하는 몇 가지 예입니다.

fn main() {
    let some_number = Some(5);
    let some_char = Some('e');

    let absent_number: Option<i32> = None;
}

some_number 의 타입은 Option<i32> 입니다. some_char 의 타입은 Option<char> 이고, 이는 서로 다른 타입입니다. Some variant 안에 값을 넣었기 때문에 러스트는 이 타입들을 추론할 수 있습니다. 반면 absent_number 에 대해서는 전체 Option 타입을 주석으로 달아 주어야 합니다. None 값만 보고는, 여기에 대응하는 Some variant가 어떤 타입을 가질지 컴파일러가 알 수 없기 때문입니다. 그래서 여기서는 absent_number 가 Option<i32> 타입이라는 사실을 직접 알려 줍니다.

Some 값을 가질 때 우리는 값이 존재한다는 사실을 알 수 있고, 그 값은 Some 안에 들어 있습니다. None 값을 가질 때는 어떤 의미에서는 null 과 같은 뜻입니다. 유효한 값이 없다는 뜻이니까요. 그렇다면 왜 Option<T> 가 null 보다 나을까요?

짧게 말하면, Option<T> 와 T (T 는 어떤 타입이든 될 수 있습니다)는 서로 다른 타입이기 때문입니다. 그래서 컴파일러는 Option<T> 값을 “확실히 유효한 값”처럼 사용하는 것을 허용하지 않습니다. 예를 들어 다음 코드는 i8 과 Option<i8> 를 더하려 하기 때문에 컴파일되지 않습니다.

fn main() {
    let x: i8 = 5;
    let y: Option<i8> = Some(5);

    let sum = x + y;
}

이 코드를 실행하면 다음과 같은 오류 메시지를 받습니다.

$ cargo run
   Compiling enums v0.1.0 (file:///projects/enums)
error[E0277]: cannot add `Option<i8>` to `i8`
 --> src/main.rs:5:17
  |
5 |     let sum = x + y;
  |                 ^ no implementation for `i8 + Option<i8>`
  |
  = help: the trait `Add<Option<i8>>` is not implemented for `i8`
  = help: the following other types implement trait `Add<Rhs>`:
            `&i8` implements `Add<i8>`
            `&i8` implements `Add`
            `i8` implements `Add<&i8>`
            `i8` implements `Add`

For more information about this error, try `rustc --explain E0277`.
error: could not compile `enums` (bin "enums") due to 1 previous error

꽤 강렬하지요! 이 오류 메시지가 뜻하는 바는, 러스트가 i8 과 Option<i8> 를 어떻게 더해야 할지 모르겠다는 것입니다. 왜냐하면 둘은 서로 다른 타입이기 때문입니다. 러스트에서 i8 같은 타입의 값을 갖는다는 것은, 컴파일러가 우리가 언제나 유효한 값을 가지고 있음을 보장해 준다는 뜻입니다. 따라서 그 값을 사용하기 전에 null인지 검사할 필요 없이 자신 있게 사용할 수 있습니다. 오직 Option<i8>(혹은 현재 다루는 다른 Option<T> 값)을 가질 때만, 값이 없을 가능성을 걱정해야 합니다. 그리고 컴파일러는 그 값을 사용하기 전에 그 경우를 반드시 처리하도록 강제합니다.

다시 말해, T 에 대한 연산을 수행하기 전에 Option<T> 를 T 로 변환해야 합니다. 이것은 일반적으로 null과 관련된 가장 흔한 문제 중 하나, 즉 실제로는 값이 없는데 값이 있을 것이라고 가정하는 실수를 잡는 데 도움이 됩니다.

값이 null 이 아니라고 잘못 가정할 위험을 없애면 코드에 대해 훨씬 더 확신을 가질 수 있습니다. null 일 수도 있는 값을 가지려면, 그 값의 타입을 Option<T> 로 만들어 명시적으로 선택해야 합니다. 그리고 그 값을 사용할 때는 값이 없을 수도 있는 경우를 명시적으로 처리해야 합니다. 반대로 어떤 값의 타입이 Option<T> 가 아니라면, 그 값이 null이 아니라고 안전하게 가정할 수 있습니다. 이것은 null 이 코드 전체로 퍼지는 것을 제한하고 러스트 코드의 안전성을 높이기 위한, 러스트의 의도적인 설계 선택입니다.

그렇다면 Option<T> 값을 가지고 있을 때, 그 안의 Some variant에서 T 값을 어떻게 꺼내어 사용할까요? Option<T> enum에는 다양한 상황에서 유용한 메서드가 많이 정의되어 있으며, 문서에서 확인할 수 있습니다. 러스트를 배워 나가면서 Option<T> 의 메서드들에 익숙해지는 것은 매우 큰 도움이 됩니다.

일반적으로 Option<T> 값을 사용하려면, 각 variant를 모두 처리하는 코드를 작성해야 합니다. Some(T) 값을 가진 경우에만 실행되는 코드가 필요하며, 그 코드 안에서는 내부의 T 값을 사용할 수 있어야 합니다. 그리고 None 값을 가진 경우에만 실행되는 다른 코드도 필요합니다. 그 경우에는 사용할 T 값이 없습니다. match 식은 enum과 함께 쓸 때 바로 이 역할을 하는 제어 흐름 구문입니다. 어떤 enum variant를 가졌는지에 따라 서로 다른 코드를 실행하며, 그 코드 안에서는 매칭된 값 내부의 데이터를 사용할 수 있습니다.

match 제어 흐름 구문

match 제어 흐름 구문

러스트에는 match 라는 매우 강력한 제어 흐름 구문이 있습니다. 이 구문은 어떤 값을 일련의 패턴과 비교한 뒤, 어떤 패턴이 맞는지에 따라 코드를 실행하게 해 줍니다. 패턴은 리터럴 값, 변수 이름, 와일드카드 등 다양한 것으로 이루어질 수 있으며, 19장에서 패턴 종류와 역할을 자세히 다룹니다. match 의 강력함은 패턴이 매우 표현력이 높다는 점과, 컴파일러가 가능한 모든 경우가 처리되었는지 확인해 준다는 점에서 나옵니다.

match 식을 동전 분류 기계라고 생각해도 좋습니다. 동전이 여러 크기의 구멍이 뚫린 레일을 따라 내려오다가, 들어갈 수 있는 첫 번째 구멍을 만나면 그곳으로 떨어집니다. 마찬가지로 값도 match 의 각 패턴을 차례로 통과하고, 값이 “맞는” 첫 번째 패턴을 만나면 그와 연결된 코드 블록으로 떨어져 실행됩니다.

마침 동전 이야기가 나왔으니, match 예제로 동전을 사용해 봅시다! 정체를 모르는 미국 동전을 받아서, 분류 기계처럼 그것이 어떤 동전인지 판별하고 몇 센트인지 반환하는 함수를 목록 6-3처럼 작성할 수 있습니다.

enum Coin {
    Penny,
    Nickel,
    Dime,
    Quarter,
}

fn value_in_cents(coin: Coin) -> u8 {
    match coin {
        Coin::Penny => 1,
        Coin::Nickel => 5,
        Coin::Dime => 10,
        Coin::Quarter => 25,
    }
}

fn main() {}

value_in_cents 함수 안의 match 를 하나씩 뜯어 봅시다. 먼저 match 키워드를 쓰고, 그 뒤에 식을 놓습니다. 여기서는 값 coin 입니다. 겉보기에는 if 와 함께 사용하는 조건식과 비슷해 보이지만, 큰 차이가 있습니다. if 는 조건이 반드시 불리언으로 평가되어야 하지만, 여기서는 어떤 타입이든 올 수 있습니다. 이 예제에서 coin 의 타입은 첫 줄에서 정의한 Coin enum 입니다.

그다음은 match arm 들입니다. 각 arm은 패턴과 코드, 두 부분으로 이루어집니다. 첫 번째 arm에는 Coin::Penny 라는 패턴이 있고, 그 뒤에 패턴과 실행할 코드를 구분하는 => 연산자가 있습니다. 여기서 코드는 단순히 값 1 입니다. 각 arm은 쉼표로 구분됩니다.

match 식이 실행되면, 주어진 값은 각 arm의 패턴과 순서대로 비교됩니다. 어떤 패턴이 값과 맞으면 그 패턴에 연결된 코드가 실행됩니다. 맞지 않으면 다음 arm으로 넘어갑니다. 동전 분류 기계와 같은 방식입니다. 필요한 만큼 arm을 둘 수 있으며, 목록 6-3에는 네 개의 arm이 있습니다.

각 arm에 연결된 코드는 하나의 식이며, 매칭된 arm 식의 결과값이 전체 match 식의 결과가 됩니다.

보통 목록 6-3처럼 각 arm이 단순히 값 하나를 반환하는 짧은 코드라면 중괄호를 사용하지 않습니다. 하지만 하나의 match arm 안에서 여러 줄의 코드를 실행하고 싶다면 반드시 중괄호를 사용해야 하고, 그 경우 arm 뒤의 쉼표는 선택 사항이 됩니다. 예를 들어 다음 코드는 Coin::Penny 가 들어올 때마다 “Lucky penny!” 를 출력하지만, 블록의 마지막 값인 1 은 그대로 반환합니다.

enum Coin {
    Penny,
    Nickel,
    Dime,
    Quarter,
}

fn value_in_cents(coin: Coin) -> u8 {
    match coin {
        Coin::Penny => {
            println!("Lucky penny!");
            1
        }
        Coin::Nickel => 5,
        Coin::Dime => 10,
        Coin::Quarter => 25,
    }
}

fn main() {}

값을 바인딩하는 패턴

match arm의 또 다른 유용한 기능은, 패턴이 매칭된 값 안의 일부를 변수에 바인딩할 수 있다는 점입니다. 이 방식으로 enum variant 안의 값을 꺼낼 수 있습니다.

예를 들어, enum variant 하나가 내부에 데이터를 갖도록 바꿔 봅시다. 1999년부터 2008년까지 미국은 50개 주 각각에 대해 다른 디자인을 한쪽 면에 새긴 quarter를 발행했습니다. 다른 동전에는 주 디자인이 없으므로, quarter만 이 추가 정보를 갖게 하면 됩니다. 목록 6-4처럼 Quarter variant 안에 UsState 값을 저장하도록 enum 을 변경할 수 있습니다.

#[derive(Debug)] // so we can inspect the state in a minute
enum UsState {
    Alabama,
    Alaska,
    // --snip--
}

enum Coin {
    Penny,
    Nickel,
    Dime,
    Quarter(UsState),
}

fn main() {}

친구가 50개 주 quarter를 전부 모으고 있다고 상상해 봅시다. 우리는 동전 종류별로 잔돈을 분류하면서, quarter가 나올 때마다 어떤 주의 것인지 이름도 함께 말해 줄 수 있습니다. 그러면 친구가 아직 없는 quarter라면 수집품에 추가할 수 있겠지요.

이 코드의 match 식에서는 Coin::Quarter variant에 매칭되는 패턴에 state 라는 변수를 추가합니다. 어떤 Coin::Quarter 가 매칭되면, state 변수는 그 quarter에 들어 있는 주(state) 값에 바인딩됩니다. 그러면 그 arm 안의 코드에서 state 를 바로 사용할 수 있습니다.

#[derive(Debug)]
enum UsState {
    Alabama,
    Alaska,
    // --snip--
}

enum Coin {
    Penny,
    Nickel,
    Dime,
    Quarter(UsState),
}

fn value_in_cents(coin: Coin) -> u8 {
    match coin {
        Coin::Penny => 1,
        Coin::Nickel => 5,
        Coin::Dime => 10,
        Coin::Quarter(state) => {
            println!("State quarter from {state:?}!");
            25
        }
    }
}

fn main() {
    value_in_cents(Coin::Quarter(UsState::Alaska));
}

만약 value_in_cents(Coin::Quarter(UsState::Alaska)) 를 호출했다면, coin 은 Coin::Quarter(UsState::Alaska) 가 됩니다. 이 값을 각 match arm과 비교해 보면, Coin::Quarter(state) 에 도달하기 전까지는 어느 것도 맞지 않습니다. 그 지점에서 state 는 UsState::Alaska 값에 바인딩됩니다. 그 다음 println! 식 안에서 이 바인딩을 사용해 Quarter 안의 실제 주 값만 꺼내 쓸 수 있습니다.

Option<T> 와 match 패턴

앞 절에서는 Option<T> 를 사용할 때 Some 안쪽의 T 값을 꺼내고 싶다고 이야기했습니다. 이것 역시 Coin enum을 다룰 때처럼 match 로 처리할 수 있습니다! 동전을 비교하는 대신 Option<T> 의 variant를 비교하는 것이고, match 식의 동작 방식은 그대로 같습니다.

예를 들어 Option<i32> 를 받아서 값이 있으면 그 값에 1을 더하고, 값이 없으면 None 을 그대로 반환하는 함수를 작성하고 싶다고 합시다.

이 함수는 match 덕분에 아주 쉽게 쓸 수 있으며, 목록 6-5와 같습니다.

fn main() {
    fn plus_one(x: Option<i32>) -> Option<i32> {
        match x {
            None => None,
            Some(i) => Some(i + 1),
        }
    }

    let five = Some(5);
    let six = plus_one(five);
    let none = plus_one(None);
}

plus_one 의 첫 번째 실행을 좀 더 자세히 봅시다. plus_one(five) 를 호출하면, plus_one 본문 안의 변수 x 는 Some(5) 값을 갖게 됩니다. 그런 다음 이 값은 각 match arm과 비교됩니다.

fn main() {
    fn plus_one(x: Option<i32>) -> Option<i32> {
        match x {
            None => None,
            Some(i) => Some(i + 1),
        }
    }

    let five = Some(5);
    let six = plus_one(five);
    let none = plus_one(None);
}

Some(5) 는 None 패턴과 맞지 않으므로 다음 arm으로 넘어갑니다.

fn main() {
    fn plus_one(x: Option<i32>) -> Option<i32> {
        match x {
            None => None,
            Some(i) => Some(i + 1),
        }
    }

    let five = Some(5);
    let six = plus_one(five);
    let none = plus_one(None);
}

Some(5) 가 Some(i) 와 맞을까요? 맞습니다! 같은 variant이기 때문입니다. i 는 Some 안의 값에 바인딩되고, 따라서 i 는 값 5 를 갖습니다. 그러면 이 arm의 코드가 실행되어 i 에 1을 더하고, 합계 6 을 담은 새 Some 값이 만들어집니다.

이제 목록 6-5에서 x 가 None 인 두 번째 호출을 생각해 봅시다. match 에 진입해 첫 번째 arm과 비교합니다.

fn main() {
    fn plus_one(x: Option<i32>) -> Option<i32> {
        match x {
            None => None,
            Some(i) => Some(i + 1),
        }
    }

    let five = Some(5);
    let six = plus_one(five);
    let none = plus_one(None);
}

이번에는 매칭됩니다! 더할 값이 없으므로 프로그램은 멈추고 => 오른쪽의 None 값을 반환합니다. 첫 번째 arm이 맞았으므로 다른 arm들은 비교하지 않습니다.

match 와 enum을 조합하는 방식은 여러 상황에서 유용합니다. 러스트 코드에서는 이 패턴을 아주 자주 보게 될 것입니다. enum에 대해 match 를 하고, 안의 데이터를 변수에 바인딩한 뒤, 그것을 바탕으로 코드를 실행하는 방식입니다. 처음에는 약간 헷갈릴 수 있지만, 익숙해지고 나면 모든 언어에 이런 기능이 있기를 바라게 될지도 모릅니다. 실제로 많은 사용자가 아주 좋아하는 기능입니다.

match 는 모든 경우를 다루어야 한다

match 에 대해 반드시 이야기해야 할 또 한 가지가 있습니다. 각 arm의 패턴은 가능한 모든 경우를 덮어야 한다는 점입니다. 아래의 plus_one 함수 버전은 버그가 있고 컴파일되지 않습니다.

fn main() {
    fn plus_one(x: Option<i32>) -> Option<i32> {
        match x {
            Some(i) => Some(i + 1),
        }
    }

    let five = Some(5);
    let six = plus_one(five);
    let none = plus_one(None);
}

우리는 None 경우를 처리하지 않았기 때문에 이 코드는 버그를 만듭니다. 다행히 이것은 러스트가 아주 잘 잡아내는 종류의 버그입니다. 이 코드를 컴파일하려 하면 다음 오류가 나옵니다.

$ cargo run
   Compiling enums v0.1.0 (file:///projects/enums)
error[E0004]: non-exhaustive patterns: `None` not covered
 --> src/main.rs:3:15
  |
3 |         match x {
  |               ^ pattern `None` not covered
  |
note: `Option<i32>` defined here
 --> /rustc/1159e78c4747b02ef996e55082b704c09b970588/library/core/src/option.rs:593:1
 ::: /rustc/1159e78c4747b02ef996e55082b704c09b970588/library/core/src/option.rs:597:5
  |
  = note: not covered
  = note: the matched value is of type `Option<i32>`
help: ensure that all possible cases are being handled by adding a match arm with a wildcard pattern or an explicit pattern as shown
  |
4 ~             Some(i) => Some(i + 1),
5 ~             None => todo!(),
  |

For more information about this error, try `rustc --explain E0004`.
error: could not compile `enums` (bin "enums") due to 1 previous error

러스트는 우리가 가능한 모든 경우를 다루지 않았다는 사실을 알고 있고, 심지어 어떤 패턴을 빠뜨렸는지도 알고 있습니다! 러스트의 match 는 완전해야(exhaustive) 합니다. 코드가 유효하려면 가능한 경우를 하나도 빠짐없이 다루어야 합니다. 특히 Option<T> 의 경우, 러스트는 None 경우를 명시적으로 처리하는 것을 잊지 못하게 함으로써, 값이 없을지도 모르는데 있다고 가정하는 실수를 막아 줍니다. 앞에서 이야기한 “10억 달러짜리 실수”가 여기서는 일어날 수 없게 되는 것입니다.

catch-all 패턴과 _ 플레이스홀더

enum을 사용할 때, 몇몇 특정 값에 대해서만 특별한 동작을 하고 나머지 모든 값에 대해서는 기본 동작을 하고 싶을 수도 있습니다. 예를 들어 어떤 게임을 구현하는데, 주사위를 굴려 3이 나오면 플레이어는 이동하지 않고 멋진 모자를 하나 얻습니다. 7이 나오면 멋진 모자를 하나 잃습니다. 그 외 모든 값에서는 플레이어가 보드 위에서 그 숫자만큼 이동합니다. 다음은 그 논리를 구현한 match 예시입니다. 주사위 결과는 임의 값이 아닌 하드코딩된 값으로 넣었고, 그 외의 실제 게임 로직은 예제 범위를 벗어나므로 본문이 없는 함수 호출로만 표현했습니다.

fn main() {
    let dice_roll = 9;
    match dice_roll {
        3 => add_fancy_hat(),
        7 => remove_fancy_hat(),
        other => move_player(other),
    }

    fn add_fancy_hat() {}
    fn remove_fancy_hat() {}
    fn move_player(num_spaces: u8) {}
}

첫 두 arm의 패턴은 리터럴 값 3, 7 입니다. 나머지 모든 가능한 값을 처리하는 마지막 arm의 패턴은 other 라는 이름의 변수입니다. 이 other arm에서 실행되는 코드는 그 변수를 move_player 함수에 넘겨 사용합니다.

이 코드는, 우리가 u8 이 가질 수 있는 모든 값을 하나하나 나열하지 않았더라도 컴파일됩니다. 마지막 패턴이 명시적으로 나열되지 않은 모든 값과 맞기 때문입니다. 이 catch-all 패턴 덕분에 match 가 완전해야 한다는 요구를 만족합니다. 단, 패턴은 순서대로 검사되므로 catch-all arm은 반드시 마지막에 두어야 합니다. 만약 catch-all을 앞에 두면 나머지 arm은 절대로 실행되지 않을 것이므로, 러스트는 catch-all 뒤에 arm을 추가하면 경고합니다.

러스트에는 catch-all을 원하되, 그 값 자체를 사용하고 싶지 않을 때 쓰는 특별한 패턴도 있습니다. _ 는 어떤 값과도 매칭되지만, 그 값에 이름을 바인딩하지 않습니다. 이것은 “우리는 이 값을 사용하지 않을 것이다”라고 러스트에게 알려 주는 것이며, 따라서 러스트는 사용하지 않는 변수에 대한 경고도 하지 않습니다.

게임 규칙을 조금 바꿔 봅시다. 이제 3이나 7이 아닌 값을 굴리면 그냥 다시 굴려야 한다고 합시다. 더 이상 catch-all 값 자체를 사용할 필요가 없으므로, other 라는 변수 대신 _ 를 쓰도록 코드를 바꿀 수 있습니다.

fn main() {
    let dice_roll = 9;
    match dice_roll {
        3 => add_fancy_hat(),
        7 => remove_fancy_hat(),
        _ => reroll(),
    }

    fn add_fancy_hat() {}
    fn remove_fancy_hat() {}
    fn reroll() {}
}

이 예시 역시 완전성 요구를 만족합니다. 마지막 arm에서 다른 모든 값을 명시적으로 무시했기 때문에, 빠뜨린 경우가 없습니다.

마지막으로 규칙을 한 번 더 바꿔서, 3이나 7이 아닌 값을 굴리면 그 턴에는 아무 일도 일어나지 않는다고 해 봅시다. 이 경우에는 _ arm과 함께 유닛 값(3장의 “튜플 타입” 절에서 언급한 빈 튜플 타입)을 코드로 쓰면 표현할 수 있습니다.

fn main() {
    let dice_roll = 9;
    match dice_roll {
        3 => add_fancy_hat(),
        7 => remove_fancy_hat(),
        _ => (),
    }

    fn add_fancy_hat() {}
    fn remove_fancy_hat() {}
}

여기서는 더 앞쪽 arm의 패턴과 맞지 않는 다른 모든 값은 사용하지 않겠고, 그 경우에는 아무 코드도 실행하고 싶지 않다고 러스트에게 명시적으로 말하고 있는 것입니다.

패턴과 매칭에 대해서는 19장에서 더 많은 내용을 다룹니다. 지금은 조금 장황하게 느껴질 수 있는 상황에서 유용한 if let 문법으로 이제 넘어가 보겠습니다.

if let과 let...else로 더 간결하게 쓰기

if let과 let...else 로 더 간결하게 제어 흐름 쓰기

if let 문법은 if 와 let 을 합쳐, 하나의 패턴과 맞는 값만 처리하고 나머지는 무시하는 일을 덜 장황하게 표현할 수 있게 해 줍니다. 예를 들어 목록 6-6의 프로그램은 config_max 변수에 들어 있는 Option<u8> 값을 match 로 처리하지만, 실제로 코드를 실행하고 싶은 경우는 값이 Some variant일 때뿐입니다.

fn main() {
    let config_max = Some(3u8);
    match config_max {
        Some(max) => println!("The maximum is configured to be {max}"),
        _ => (),
    }
}

값이 Some 이면, 패턴 안에서 그 값을 max 변수에 바인딩해 Some 안쪽 값을 출력합니다. None 값에 대해서는 아무 것도 하고 싶지 않습니다. 그런데 match 식을 완전하게 만들려면, 하나의 variant만 처리하고도 _ => () 같은 코드를 덧붙여야 합니다. 이건 성가신 보일러플레이트죠.

대신 if let 을 사용하면 훨씬 더 짧게 같은 일을 쓸 수 있습니다. 다음 코드는 목록 6-6의 match 와 동일하게 동작합니다.

fn main() {
    let config_max = Some(3u8);
    if let Some(max) = config_max {
        println!("The maximum is configured to be {max}");
    }
}

if let 문법은 패턴과 식을 등호로 구분해 받습니다. 동작 방식은 match 와 같아서, 식이 match 에 주어지고 패턴이 첫 번째 arm 역할을 합니다. 이 경우 패턴은 Some(max) 이며, max 는 Some 안쪽 값에 바인딩됩니다. 그 뒤 if let 블록 본문에서, 대응하는 match arm에서 했던 것과 똑같이 max 를 사용할 수 있습니다. if let 블록 안의 코드는 값이 해당 패턴과 매칭될 때만 실행됩니다.

if let 을 사용하면 타이핑도 줄고, 들여쓰기도 줄며, 보일러플레이트 코드도 줄어듭니다. 하지만 그 대가로 match 가 강제하던 완전성 검사를 잃게 됩니다. 즉, 어떤 경우를 빠뜨렸는지 컴파일러가 확인해 주지 않습니다. 따라서 match 와 if let 중 어느 것을 선택할지는, 지금 상황에서 더 간결한 코드를 얻는 것이 완전성 검사를 포기할 만한 가치가 있는지에 따라 달라집니다.

다르게 말하면, if let 은 하나의 패턴과 매칭될 때만 코드를 실행하고, 나머지 모든 값은 무시하는 match 의 문법적 설탕이라고 생각할 수 있습니다.

if let 에는 else 도 붙일 수 있습니다. else 와 연결된 코드 블록은, 같은 일을 하는 match 식에서 _ 케이스와 함께 둘 코드와 동일한 역할을 합니다. 목록 6-4의 Coin enum 정의를 떠올려 봅시다. 거기서 Quarter variant는 UsState 값을 함께 가지고 있었습니다. 만약 quarter가 아닌 동전을 셀 필요도 있고, quarter라면 어떤 주의 동전인지도 출력하고 싶다면 다음처럼 match 식으로 쓸 수 있습니다.

#[derive(Debug)]
enum UsState {
    Alabama,
    Alaska,
    // --snip--
}

enum Coin {
    Penny,
    Nickel,
    Dime,
    Quarter(UsState),
}

fn main() {
    let coin = Coin::Penny;
    let mut count = 0;
    match coin {
        Coin::Quarter(state) => println!("State quarter from {state:?}!"),
        _ => count += 1,
    }
}

혹은 다음처럼 if let 과 else 식을 사용할 수도 있습니다.

#[derive(Debug)]
enum UsState {
    Alabama,
    Alaska,
    // --snip--
}

enum Coin {
    Penny,
    Nickel,
    Dime,
    Quarter(UsState),
}

fn main() {
    let coin = Coin::Penny;
    let mut count = 0;
    if let Coin::Quarter(state) = coin {
        println!("State quarter from {state:?}!");
    } else {
        count += 1;
    }
}

let...else 로 “행복한 경로” 유지하기

흔한 패턴 하나는 값이 존재할 때 어떤 계산을 수행하고, 그렇지 않으면 기본값을 반환하는 것입니다. 주 값이 들어 있는 동전 예제를 계속 사용해 보면, 만약 어떤 quarter가 새겨진 주가 얼마나 오래된 주인지에 따라 재미있는 말을 하고 싶다면, UsState 위에 주의 연도를 확인하는 메서드를 다음처럼 도입할 수 있습니다.

#[derive(Debug)] // so we can inspect the state in a minute
enum UsState {
    Alabama,
    Alaska,
    // --snip--
}

impl UsState {
    fn existed_in(&self, year: u16) -> bool {
        match self {
            UsState::Alabama => year >= 1819,
            UsState::Alaska => year >= 1959,
            // -- snip --
        }
    }
}

enum Coin {
    Penny,
    Nickel,
    Dime,
    Quarter(UsState),
}

fn describe_state_quarter(coin: Coin) -> Option<String> {
    if let Coin::Quarter(state) = coin {
        if state.existed_in(1900) {
            Some(format!("{state:?} is pretty old, for America!"))
        } else {
            Some(format!("{state:?} is relatively new."))
        }
    } else {
        None
    }
}

fn main() {
    if let Some(desc) = describe_state_quarter(Coin::Quarter(UsState::Alaska)) {
        println!("{desc}");
    }
}

그런 다음 목록 6-7처럼 if let 을 사용해 동전 종류를 매칭하고, 조건 본문 안에서 state 변수를 도입할 수 있습니다.

#[derive(Debug)] // so we can inspect the state in a minute
enum UsState {
    Alabama,
    Alaska,
    // --snip--
}

impl UsState {
    fn existed_in(&self, year: u16) -> bool {
        match self {
            UsState::Alabama => year >= 1819,
            UsState::Alaska => year >= 1959,
            // -- snip --
        }
    }
}

enum Coin {
    Penny,
    Nickel,
    Dime,
    Quarter(UsState),
}

fn describe_state_quarter(coin: Coin) -> Option<String> {
    if let Coin::Quarter(state) = coin {
        if state.existed_in(1900) {
            Some(format!("{state:?} is pretty old, for America!"))
        } else {
            Some(format!("{state:?} is relatively new."))
        }
    } else {
        None
    }
}

fn main() {
    if let Some(desc) = describe_state_quarter(Coin::Quarter(UsState::Alaska)) {
        println!("{desc}");
    }
}

이 코드는 원하는 일을 하기는 하지만, 작업이 if let 본문 안으로 밀려 들어갔습니다. 해야 할 일이 더 복잡해지면, 최상위 분기들이 서로 어떤 관계인지 따라가기가 어려워질 수 있습니다. 또는 식이 값을 만들어 낸다는 사실을 이용해, if let 에서 state 를 만들어 내거나 조기에 반환할 수도 있습니다. 목록 6-8처럼 말이죠. (match 로도 비슷하게 만들 수 있습니다.)

#[derive(Debug)] // so we can inspect the state in a minute
enum UsState {
    Alabama,
    Alaska,
    // --snip--
}

impl UsState {
    fn existed_in(&self, year: u16) -> bool {
        match self {
            UsState::Alabama => year >= 1819,
            UsState::Alaska => year >= 1959,
            // -- snip --
        }
    }
}

enum Coin {
    Penny,
    Nickel,
    Dime,
    Quarter(UsState),
}

fn describe_state_quarter(coin: Coin) -> Option<String> {
    let state = if let Coin::Quarter(state) = coin {
        state
    } else {
        return None;
    };

    if state.existed_in(1900) {
        Some(format!("{state:?} is pretty old, for America!"))
    } else {
        Some(format!("{state:?} is relatively new."))
    }
}

fn main() {
    if let Some(desc) = describe_state_quarter(Coin::Quarter(UsState::Alaska)) {
        println!("{desc}");
    }
}

하지만 이 코드도 나름대로 따라가기 불편합니다. if let 의 한 분기는 값을 만들고, 다른 분기는 함수에서 바로 반환해 버리기 때문입니다.

이런 흔한 패턴을 더 보기 좋게 표현하기 위해, 러스트는 let...else 를 제공합니다. let...else 문법은 왼쪽에 패턴, 오른쪽에 식을 받는다는 점에서 if let 과 매우 비슷하지만, if 분기는 없고 else 분기만 있습니다. 패턴이 맞으면, 패턴 안의 값은 바깥 스코프에 바인딩됩니다. 패턴이 맞지 않으면, 프로그램 흐름은 else arm으로 들어가며, 그 arm은 반드시 함수에서 반환해야 합니다.

목록 6-9는 목록 6-8을 if let 대신 let...else 로 썼을 때 어떤 모습인지 보여 줍니다.

#[derive(Debug)] // so we can inspect the state in a minute
enum UsState {
    Alabama,
    Alaska,
    // --snip--
}

impl UsState {
    fn existed_in(&self, year: u16) -> bool {
        match self {
            UsState::Alabama => year >= 1819,
            UsState::Alaska => year >= 1959,
            // -- snip --
        }
    }
}

enum Coin {
    Penny,
    Nickel,
    Dime,
    Quarter(UsState),
}

fn describe_state_quarter(coin: Coin) -> Option<String> {
    let Coin::Quarter(state) = coin else {
        return None;
    };

    if state.existed_in(1900) {
        Some(format!("{state:?} is pretty old, for America!"))
    } else {
        Some(format!("{state:?} is relatively new."))
    }
}

fn main() {
    if let Some(desc) = describe_state_quarter(Coin::Quarter(UsState::Alaska)) {
        println!("{desc}");
    }
}

이 방식은 if let 처럼 두 분기의 제어 흐름이 크게 갈라지지 않으면서도, 함수 본문이 주로 “행복한 경로(happy path)” 에 머무르게 해 줍니다.

어떤 상황에서 프로그램 로직이 match 로 표현하기엔 너무 장황하다면, if let 과 let...else 역시 러스트 도구 상자 안에 있다는 점을 기억해 두세요.

정리

이제 우리는 enum을 사용해, 열거된 값 집합 중 하나가 될 수 있는 사용자 정의 타입을 만드는 방법을 배웠습니다. 또한 표준 라이브러리의 Option<T> 타입이 타입 시스템을 사용해 오류를 막는 데 어떻게 도움을 주는지도 보았습니다. enum 값 안에 데이터가 있다면, 처리해야 할 경우 수에 따라 match 나 if let 을 사용해 그 값을 꺼내 쓰면 됩니다.

이제 여러분의 러스트 프로그램은 구조체와 enum을 사용해 도메인 개념을 더 정확히 표현할 수 있게 되었습니다. API에 사용할 사용자 정의 타입을 만들면 타입 안전성도 함께 얻습니다. 컴파일러가 함수가 기대하는 타입의 값만 함수에 들어오도록 보장해 주기 때문입니다.

이제 사용자가 쉽게 쓸 수 있고, 동시에 정말 필요한 것만 정확히 드러내는 잘 정리된 API를 제공하기 위해, 러스트의 모듈로 넘어가 보겠습니다.

패키지, 크레이트, 모듈

프로그램이 커질수록 코드를 잘 정리하는 일은 점점 더 중요해집니다. 관련 기능을 함께 묶고, 서로 다른 기능을 분리해 두면, 어떤 기능을 구현한 코드를 어디서 찾아야 하는지, 그리고 그 기능의 동작 방식을 바꾸려면 어디로 가야 하는지가 훨씬 분명해집니다.

지금까지 우리가 작성한 프로그램은 하나의 파일 안, 하나의 모듈 안에 있었습니다. 프로젝트가 커지면 코드를 여러 모듈로 나누고, 나중에는 여러 파일로 나누어 정리해야 합니다. 하나의 패키지는 여러 개의 바이너리 크레이트를 포함할 수 있고, 선택적으로 하나의 라이브러리 크레이트도 포함할 수 있습니다. 패키지가 더 커지면 일부를 별도 크레이트로 분리해 외부 의존성으로 만들 수도 있습니다. 이 장에서는 이런 기법을 모두 다룹니다. 함께 진화하는 서로 관련된 패키지들의 집합으로 이루어진 아주 큰 프로젝트를 위해서는 Cargo가 워크스페이스도 제공하며, 이는 14장의 [“Cargo 워크스페이스”] workspaces 절에서 설명합니다.

또한 구현 세부를 캡슐화하는 방법도 설명합니다. 이를 통해 더 높은 수준에서 코드를 재사용할 수 있습니다. 어떤 연산을 구현하고 나면, 다른 코드는 그 구현이 내부에서 어떻게 동작하는지 몰라도 공개 인터페이스를 통해 그 코드를 호출할 수 있습니다. 코드를 작성하는 방식에 따라, 다른 코드가 사용할 수 있도록 공개할 부분과 여러분이 자유롭게 바꿀 수 있도록 비공개 구현 세부로 둘 부분이 정해집니다. 이것 역시 머릿속에 유지해야 하는 세부 사항의 양을 줄이는 방법입니다.

관련된 개념으로 스코프(scope)가 있습니다. 코드를 작성하는 중첩된 맥락에는 “현재 스코프 안에 있다”고 정의된 이름들의 집합이 있습니다. 코드를 읽고 쓰고 컴파일할 때, 프로그래머와 컴파일러는 특정 위치의 어떤 이름이 변수, 함수, 구조체, enum, 모듈, 상수, 혹은 다른 항목을 가리키는지, 그리고 그것이 무슨 의미인지 알아야 합니다. 스코프를 만들고, 어떤 이름이 스코프 안에 있고 밖에 있는지를 바꿀 수 있습니다. 같은 스코프 안에 같은 이름의 항목 두 개를 둘 수는 없으며, 이름 충돌을 해결하는 도구도 존재합니다.

러스트에는 어떤 세부를 노출하고 어떤 세부를 비공개로 둘지, 그리고 프로그램의 각 스코프 안에 어떤 이름이 있는지를 포함해 코드 조직을 관리할 수 있게 해 주는 여러 기능이 있습니다. 이러한 기능들을 묶어 흔히 모듈 시스템(module system) 이라고 부르며, 다음이 포함됩니다.

• 패키지(Packages): 크레이트를 빌드, 테스트, 공유하게 해 주는 Cargo 기능
• 크레이트(Crates): 라이브러리 또는 실행 파일을 만들어 내는 모듈 트리
• 모듈과 use: 경로의 조직, 스코프, 공개 범위를 제어하게 해 줌
• 경로(Paths): 구조체, 함수, 모듈 같은 항목에 이름을 붙이는 방법

이 장에서는 이 기능들을 모두 다루고, 이들이 어떻게 상호작용하는지 설명하며, 스코프를 관리하는 데 어떻게 사용하는지도 보여 줄 것입니다. 이 장을 마치면 모듈 시스템을 탄탄하게 이해하고, 스코프를 능숙하게 다룰 수 있게 될 것입니다.

패키지와 크레이트

패키지와 크레이트

모듈 시스템에서 가장 먼저 다룰 부분은 패키지와 크레이트입니다.

크레이트(crate) 는 러스트 컴파일러가 한 번에 고려하는 코드의 최소 단위입니다. cargo 대신 rustc 를 실행하고, 소스 코드 파일 하나만 넘긴다고 해도(1장의 “Rust 프로그램의 기초” 절에서 실제로 그랬습니다), 컴파일러는 그 파일을 하나의 크레이트로 취급합니다. 크레이트는 모듈을 포함할 수 있고, 앞으로 보겠지만 그 모듈들은 크레이트와 함께 컴파일되는 다른 파일에 정의될 수도 있습니다.

크레이트는 두 형태 중 하나일 수 있습니다. 바이너리 크레이트 또는 라이브러리 크레이트입니다. 바이너리 크레이트(binary crates) 는 컴파일해 실행 가능한 파일로 만들 수 있는 프로그램입니다. 예를 들어 커맨드라인 프로그램이나 서버가 여기에 해당합니다. 각각은 실행 파일이 돌아갈 때 어떤 일이 일어나는지 정의하는 main 함수를 반드시 가져야 합니다. 지금까지 우리가 만든 크레이트는 모두 바이너리 크레이트였습니다.

라이브러리 크레이트(library crates) 는 main 함수가 없고, 실행 파일로 컴파일되지도 않습니다. 대신 여러 프로젝트가 공유해서 사용할 기능을 정의합니다. 예를 들어 2장에서 사용한 rand 크레이트는 난수를 생성하는 기능을 제공합니다. Rustacean이 “crate” 라고 말할 때는 대부분 라이브러리 크레이트를 의미하며, 일반적인 프로그래밍 개념의 “라이브러리” 와 사실상 같은 뜻으로 쓰기도 합니다.

크레이트 루트(crate root) 는 러스트 컴파일러가 출발점으로 삼는 소스 파일이며, 해당 크레이트의 루트 모듈이 됩니다(모듈은 [“모듈로 스코프와 공개 범위 제어하기”] modules 절에서 자세히 설명합니다).

패키지(package) 는 하나 이상의 크레이트를 묶어 특정 기능 집합을 제공하는 단위입니다. 패키지는 그 크레이트들을 어떻게 빌드할지 설명하는 Cargo.toml 파일을 포함합니다. Cargo 자체도 사실 하나의 패키지입니다. 여러분이 코드를 빌드할 때 써 온 커맨드라인 도구용 바이너리 크레이트를 포함하고 있기 때문입니다. Cargo 패키지는 또한 그 바이너리 크레이트가 의존하는 라이브러리 크레이트도 포함하고 있습니다. 다른 프로젝트는 Cargo 라이브러리 크레이트에 의존해, Cargo 커맨드라인 도구가 사용하는 것과 같은 로직을 재사용할 수 있습니다.

패키지는 원하는 만큼 많은 바이너리 크레이트를 포함할 수 있지만, 라이브러리 크레이트는 최대 하나까지만 포함할 수 있습니다. 또한 패키지는 라이브러리든 바이너리든 적어도 하나의 크레이트는 반드시 포함해야 합니다.

패키지를 만들면 실제로 어떤 일이 일어나는지 살펴봅시다. 먼저 cargo new my-project 명령을 실행합니다.

$ cargo new my-project
     Created binary (application) `my-project` package
$ ls my-project
Cargo.toml
src
$ ls my-project/src
main.rs

cargo new my-project 를 실행한 뒤 ls 로 Cargo가 무엇을 만들었는지 확인합니다. my-project 디렉터리 안에는 Cargo.toml 파일이 있는데, 이것이 패키지를 정의합니다. 또한 main.rs 를 담고 있는 src 디렉터리도 있습니다. Cargo.toml 을 에디터로 열어 보면, 그 안에 src/main.rs 에 대한 언급은 없습니다. Cargo는 src/main.rs 가 패키지와 같은 이름의 바이너리 크레이트 루트라는 관례를 따릅니다. 마찬가지로 패키지 디렉터리에 src/lib.rs 가 있으면, 패키지는 패키지와 같은 이름의 라이브러리 크레이트를 포함하고 있고, src/lib.rs 가 그 크레이트의 루트라고 Cargo는 압니다. Cargo는 이런 크레이트 루트 파일들을 rustc 에 넘겨 라이브러리나 바이너리를 빌드합니다.

여기서는 패키지 안에 src/main.rs 만 있으므로, my-project 라는 이름의 바이너리 크레이트 하나만 포함합니다. 만약 패키지에 src/main.rs 와 src/lib.rs 가 모두 있다면, 같은 이름을 가진 바이너리와 라이브러리, 두 개의 크레이트를 포함하게 됩니다. 또한 src/bin 디렉터리에 파일을 넣으면 패키지는 여러 개의 바이너리 크레이트를 가질 수 있으며, 각 파일은 각각 별도의 바이너리 크레이트가 됩니다.

모듈로 스코프와 공개 범위 제어하기

Control Scope and Privacy with Modules

이 절에서는 모듈과 모듈 시스템의 다른 구성 요소들을 다룹니다. 항목에 이름을 붙이는 경로(paths), 경로를 스코프로 가져오는 use 키워드, 그리고 항목을 공개로 만드는 pub 키워드가 그것입니다. 또한 as 키워드, 외부 패키지, 글롭 연산자도 함께 설명합니다.

모듈 치트 시트

모듈과 경로의 세부로 들어가기 전에, 여기서는 모듈, 경로, use 키워드, pub 키워드가 컴파일러 안에서 어떻게 동작하는지와 대부분의 개발자가 코드를 어떻게 정리하는지를 빠르게 훑어볼 수 있는 참조를 제공합니다. 이 장 전체에서 이 규칙들을 예제로 하나씩 살펴보겠지만, 여기 내용은 모듈이 어떻게 동작하는지 상기할 때 훌륭한 요약표가 됩니다.

• 크레이트 루트에서 시작하기: 크레이트를 컴파일할 때 컴파일러는 먼저 크레이트 루트 파일(보통 라이브러리 크레이트는 src/lib.rs, 바이너리 크레이트는 src/main.rs) 에서 컴파일할 코드를 찾습니다.
• 모듈 선언하기: 크레이트 루트 파일에서 새 모듈을 선언할 수 있습니다. 예를 들어 mod garden; 으로 “garden” 모듈을 선언한다고 합시다. 그러면 컴파일러는 다음 위치에서 그 모듈 코드를 찾습니다.
  • 세미콜론 대신 mod garden 뒤에 오는 중괄호 안 인라인 코드
  • src/garden.rs 파일
  • src/garden/mod.rs 파일
• 하위 모듈 선언하기: 크레이트 루트가 아닌 어떤 파일에서도 하위 모듈을 선언할 수 있습니다. 예를 들어 src/garden.rs 에서 mod vegetables; 를 선언할 수 있습니다. 그러면 컴파일러는 부모 모듈 이름을 딴 디렉터리 안에서 하위 모듈 코드를 다음 위치에서 찾습니다.
  • 세미콜론 대신 mod vegetables 뒤에 오는 중괄호 안 인라인 코드
  • src/garden/vegetables.rs 파일
  • src/garden/vegetables/mod.rs 파일
• 모듈 안 코드에 대한 경로: 어떤 모듈이 크레이트 일부가 되면, 같은 크레이트의 다른 곳 어디서든(공개 범위 규칙이 허용하는 한) 그 코드에 대한 경로를 사용해 접근할 수 있습니다. 예를 들어 garden의 vegetables 모듈 안 Asparagus 타입은 crate::garden::vegetables::Asparagus 에 있습니다.
• 비공개와 공개: 모듈 안의 코드는 기본적으로 부모 모듈에서 보기에 비공개입니다. 모듈을 공개로 만들려면 mod 대신 pub mod 로 선언합니다. 공개 모듈 안의 항목도 함께 공개하려면 각 선언 앞에 pub 를 붙입니다.
• use 키워드: 하나의 스코프 안에서 use 키워드는 긴 경로 반복을 줄이기 위한 지름길을 만듭니다. 어떤 스코프에서 crate::garden::vegetables::Asparagus 를 참조할 수 있다면, use crate::garden::vegetables::Asparagus; 로 단축 이름을 만들 수 있고, 그 뒤부터는 그 스코프 안에서 그냥 Asparagus 라고만 써도 됩니다.

여기서는 이런 규칙을 보여 주기 위해 backyard 라는 바이너리 크레이트를 만듭니다. 크레이트 디렉터리 역시 backyard 라는 이름을 가지며, 다음 파일과 디렉터리를 포함합니다.

backyard
├── Cargo.lock
├── Cargo.toml
└── src
    ├── garden
    │   └── vegetables.rs
    ├── garden.rs
    └── main.rs

이 경우 크레이트 루트 파일은 src/main.rs 이고, 다음 내용을 담고 있습니다.

use crate::garden::vegetables::Asparagus;

pub mod garden;

fn main() {
    let plant = Asparagus {};
    println!("I'm growing {plant:?}!");
}

pub mod garden; 줄은 컴파일러에게 src/garden.rs 에서 찾은 코드를 포함하라고 알려 줍니다. 그 파일의 내용은 다음과 같습니다.

pub mod vegetables;

여기서 pub mod vegetables; 는 src/garden/vegetables.rs 의 코드도 포함하라는 뜻입니다. 그 파일의 코드는 다음과 같습니다.

#[derive(Debug)]
pub struct Asparagus {}

이제 이 규칙들의 세부로 들어가 실제로 어떻게 동작하는지 살펴봅시다!

관련 코드를 모듈로 묶기

모듈(modules) 은 크레이트 안의 코드를 읽기 쉽고 재사용하기 쉽게 정리하게 해 줍니다. 또한 모듈은 항목의 공개 범위(privacy) 를 제어할 수 있게 해 줍니다. 모듈 안의 코드는 기본적으로 비공개이기 때문입니다. 비공개 항목은 외부에서 쓸 수 없는 내부 구현 세부입니다. 우리는 모듈과 그 안의 항목들을 공개로 만들 수도 있는데, 그러면 외부 코드가 그것들을 사용하고 의존할 수 있게 됩니다.

예제로, 레스토랑 기능을 제공하는 라이브러리 크레이트를 하나 작성해 봅시다. 여기서는 레스토랑 구현 자체보다 코드 조직에 집중하기 위해, 함수 시그니처만 정의하고 본문은 비워 두겠습니다.

레스토랑 업계에서는 보통 레스토랑의 일부를 프런트 오브 하우스(front of house), 다른 일부를 백 오브 하우스(back of house)라고 부릅니다. 프런트 오브 하우스 는 손님이 있는 공간입니다. 호스트가 손님을 자리로 안내하고, 서버가 주문과 계산을 받고, 바텐더가 음료를 만드는 곳이 여기에 포함됩니다. 백 오브 하우스 는 셰프와 요리사가 주방에서 일하고, 식기 세척 담당이 정리하고, 매니저가 행정 업무를 보는 공간입니다.

우리 크레이트도 이런 식으로 구성하려면, 기능을 중첩된 모듈들로 조직하면 됩니다. cargo new restaurant --lib 를 실행해 restaurant 라는 새 라이브러리를 만드세요. 그다음 src/lib.rs 에 목록 7-1의 코드를 넣어 몇 개의 모듈과 함수 시그니처를 정의합니다. 이 코드는 프런트 오브 하우스 부분에 해당합니다.

mod front_of_house {
    mod hosting {
        fn add_to_waitlist() {}

        fn seat_at_table() {}
    }

    mod serving {
        fn take_order() {}

        fn serve_order() {}

        fn take_payment() {}
    }
}

모듈은 mod 키워드와 모듈 이름(여기서는 front_of_house)을 써서 정의합니다. 그 뒤 중괄호 안에 모듈 본문이 들어갑니다. 모듈 안에는 hosting, serving 처럼 다른 모듈도 넣을 수 있습니다. 또한 구조체, enum, 상수, 트레이트, 그리고 목록 7-1의 함수처럼 다른 항목 정의도 담을 수 있습니다.

모듈을 사용하면 서로 관련된 정의를 함께 묶고, 왜 서로 관련되어 있는지도 이름으로 표현할 수 있습니다. 이 코드를 사용하는 프로그래머는 모든 정의를 다 읽어야 하는 대신 그룹을 따라가며 코드를 탐색할 수 있어서, 자신에게 필요한 정의를 더 쉽게 찾을 수 있습니다. 또한 이 코드에 새 기능을 추가하는 프로그래머도 프로그램을 정리된 상태로 유지하려면 코드를 어디에 넣어야 하는지 쉽게 알 수 있습니다.

앞에서 src/main.rs 와 src/lib.rs 를 크레이트 루트 라고 부른다고 했습니다. 이런 이름이 붙은 이유는, 이 두 파일 중 어느 하나의 내용이든 크레이트의 모듈 구조 맨 위에 있는 crate 라는 이름의 모듈을 이루기 때문입니다. 이 구조를 모듈 트리 라고 합니다.

목록 7-2는 목록 7-1 구조에 대한 모듈 트리를 보여 줍니다.

crate
 └── front_of_house
     ├── hosting
     │   ├── add_to_waitlist
     │   └── seat_at_table
     └── serving
         ├── take_order
         ├── serve_order
         └── take_payment

이 트리는 어떤 모듈이 다른 모듈 안에 중첩되는지 보여 줍니다. 예를 들어 hosting 은 front_of_house 안에 들어 있습니다. 또한 어떤 모듈은 서로 형제(siblings) 인데, 이는 같은 모듈 안에 정의되었다는 뜻입니다. hosting 과 serving 은 front_of_house 안에 함께 정의된 형제 모듈입니다. 모듈 A가 모듈 B 안에 들어 있다면, A를 B의 자식(child) 이라고 하고 B를 A의 부모(parent) 라고 합니다. 그리고 전체 모듈 트리는 암묵적인 crate 모듈 아래에 뿌리를 두고 있다는 점에 주목하세요.

모듈 트리는 컴퓨터의 파일시스템 디렉터리 트리를 떠올리게 할 수도 있습니다. 그리고 그 비유는 아주 적절합니다! 파일시스템에서 디렉터리로 파일을 정리하듯, 우리는 모듈을 사용해 코드를 정리합니다. 또한 디렉터리 안 파일을 찾아야 하듯, 모듈도 찾아낼 수 있는 방법이 필요합니다.

모듈 트리의 항목을 경로로 가리키기

모듈 트리의 항목을 경로로 가리키기

모듈 트리 안에서 어떤 항목을 어디서 찾을지 러스트에게 알려 주려면, 파일시스템을 탐색할 때 경로를 쓰는 것과 같은 방식으로 경로(path)를 사용합니다. 함수를 호출하려면 그 함수의 경로를 알아야 합니다.

경로는 두 가지 형태를 가질 수 있습니다.

• 절대 경로(absolute path) 는 크레이트 루트에서 시작하는 전체 경로입니다. 외부 크레이트의 코드에 대해서는 절대 경로가 크레이트 이름으로 시작하고, 현재 크레이트의 코드에 대해서는 리터럴 crate 로 시작합니다.
• 상대 경로(relative path) 는 현재 모듈에서 시작하며, self, super, 또는 현재 모듈 안의 식별자를 사용합니다.

절대 경로든 상대 경로든, 그 뒤에는 이중 콜론(::)으로 구분된 하나 이상의 식별자가 이어집니다.

목록 7-1로 돌아가서, add_to_waitlist 함수를 호출하고 싶다고 해 봅시다. 이것은 결국 “add_to_waitlist 함수의 경로가 무엇인가?”라고 묻는 것과 같습니다. 목록 7-3은 일부 모듈과 함수를 제거한 목록 7-1의 코드입니다.

여기서는 크레이트 루트에 정의된 새 함수 eat_at_restaurant 안에서 add_to_waitlist 를 호출하는 두 가지 방법을 보여 줍니다. 이 경로들은 모두 맞지만, 아직 컴파일을 막는 또 다른 문제가 남아 있습니다. 잠시 뒤에 왜 그런지 설명하겠습니다.

eat_at_restaurant 함수는 우리 라이브러리 크레이트의 공개 API 일부이므로 pub 키워드를 붙입니다. “pub 키워드로 경로 노출하기” 절에서 pub 에 대해 더 자세히 다룹니다.

mod front_of_house {
    mod hosting {
        fn add_to_waitlist() {}
    }
}

pub fn eat_at_restaurant() {
    // Absolute path
    crate::front_of_house::hosting::add_to_waitlist();

    // Relative path
    front_of_house::hosting::add_to_waitlist();
}

eat_at_restaurant 에서 add_to_waitlist 를 처음 호출할 때는 절대 경로를 사용합니다. add_to_waitlist 함수는 eat_at_restaurant 와 같은 크레이트 안에 정의되어 있으므로, 절대 경로를 시작할 때 crate 키워드를 사용할 수 있습니다. 그런 다음 add_to_waitlist 에 도달할 때까지 각 모듈 이름을 차례로 이어 붙입니다. 이를 파일시스템으로 비유하면, /front_of_house/hosting/add_to_waitlist 경로로 add_to_waitlist 프로그램을 실행하는 것과 비슷합니다. crate 로 시작하는 것은 셸에서 파일시스템 루트 / 로 시작하는 것과 같은 느낌입니다.

두 번째 호출에서는 상대 경로를 사용합니다. 경로는 eat_at_restaurant 와 같은 모듈 트리 수준에 정의된 모듈 이름 front_of_house 로 시작합니다. 파일시스템으로 비유하면 front_of_house/hosting/add_to_waitlist 경로를 쓰는 것과 같습니다. 모듈 이름으로 시작했다는 것은 상대 경로라는 뜻입니다.

상대 경로를 쓸지 절대 경로를 쓸지는 프로젝트 상황에 따라 정해야 하는 선택입니다. 이 선택은 항목 정의 코드와 그것을 사용하는 코드를 따로 옮길 가능성이 더 큰지, 함께 옮길 가능성이 더 큰지에 달려 있습니다. 예를 들어 front_of_house 모듈과 eat_at_restaurant 함수를 함께 customer_experience 라는 모듈로 옮긴다면, add_to_waitlist 로 가는 절대 경로는 바꿔야 하지만 상대 경로는 그대로 유효합니다. 반대로 eat_at_restaurant 함수만 따로 dining 모듈로 옮긴다면, 절대 경로는 그대로 유지되지만 상대 경로는 수정해야 합니다. 일반적으로는, 코드 정의와 항목 호출을 독립적으로 옮기고 싶어질 가능성이 더 크기 때문에 절대 경로를 선호합니다.

이제 목록 7-3을 실제로 컴파일해 보고 왜 아직 컴파일되지 않는지 확인해 봅시다. 얻게 되는 오류는 목록 7-4에 나와 있습니다.

$ cargo build
   Compiling restaurant v0.1.0 (file:///projects/restaurant)
error[E0603]: module `hosting` is private
 --> src/lib.rs:9:28
  |
9 |     crate::front_of_house::hosting::add_to_waitlist();
  |                            ^^^^^^^  --------------- function `add_to_waitlist` is not publicly re-exported
  |                            |
  |                            private module
  |
note: the module `hosting` is defined here
 --> src/lib.rs:2:5
  |
2 |     mod hosting {
  |     ^^^^^^^^^^^

error[E0603]: module `hosting` is private
  --> src/lib.rs:12:21
   |
12 |     front_of_house::hosting::add_to_waitlist();
   |                     ^^^^^^^  --------------- function `add_to_waitlist` is not publicly re-exported
   |                     |
   |                     private module
   |
note: the module `hosting` is defined here
  --> src/lib.rs:2:5
   |
 2 |     mod hosting {
   |     ^^^^^^^^^^^

For more information about this error, try `rustc --explain E0603`.
error: could not compile `restaurant` (lib) due to 2 previous errors

오류 메시지는 hosting 모듈이 private 하다고 말합니다. 다시 말해 hosting 모듈과 add_to_waitlist 함수로 가는 경로 자체는 맞지만, 러스트는 private 한 부분에 접근할 수 없기 때문에 그것을 사용하게 해 주지 않습니다. 러스트에서는 모든 항목(함수, 메서드, 구조체, enum, 모듈, 상수)이 기본적으로 부모 모듈 기준으로 private 입니다. 어떤 항목을 private 로 만들고 싶다면 그냥 모듈 안에 두면 됩니다.

부모 모듈 안의 코드는 자식 모듈 안의 private 항목을 사용할 수 없습니다. 하지만 자식 모듈 안의 코드는 조상 모듈 안의 항목을 사용할 수 있습니다. 자식 모듈은 구현 세부를 감싸고 숨기지만, 자식 모듈 자체는 자신이 정의된 바깥 맥락을 볼 수 있기 때문입니다. 이 비유를 계속 사용하자면, privacy 규칙은 레스토랑의 백오피스와 비슷합니다. 그 안에서 무슨 일이 벌어지는지는 손님에게는 비공개이지만, 매니저는 자신이 운영하는 레스토랑 전체를 보고 필요한 일을 할 수 있습니다.

러스트가 모듈 시스템을 이렇게 동작하게 만든 것은, 내부 구현 세부를 숨기는 것이 기본이 되게 하기 위해서입니다. 그래야 내부 코드 중 어떤 부분은 바꿔도 외부 코드를 깨뜨리지 않는지 쉽게 알 수 있습니다. 물론 러스트는 pub 키워드를 사용해 자식 모듈 안의 코드를 바깥 조상 모듈에 노출할 수 있는 선택지도 제공합니다.

pub 키워드로 경로 노출하기

hosting 모듈이 private 하다고 알려 준 목록 7-4의 오류로 다시 돌아갑시다. 우리는 부모 모듈 안의 eat_at_restaurant 함수가 자식 모듈 안의 add_to_waitlist 함수에 접근하길 원합니다. 그러므로 목록 7-5처럼 hosting 모듈 앞에 pub 키워드를 붙입니다.

mod front_of_house {
    pub mod hosting {
        fn add_to_waitlist() {}
    }
}

// -- snip --
pub fn eat_at_restaurant() {
    // Absolute path
    crate::front_of_house::hosting::add_to_waitlist();

    // Relative path
    front_of_house::hosting::add_to_waitlist();
}

안타깝게도 목록 7-5의 코드도 여전히 컴파일 오류를 일으킵니다. 목록 7-6이 그 오류를 보여 줍니다.

$ cargo build
   Compiling restaurant v0.1.0 (file:///projects/restaurant)
error[E0603]: function `add_to_waitlist` is private
  --> src/lib.rs:10:37
   |
10 |     crate::front_of_house::hosting::add_to_waitlist();
   |                                     ^^^^^^^^^^^^^^^ private function
   |
note: the function `add_to_waitlist` is defined here
  --> src/lib.rs:3:9
   |
 3 |         fn add_to_waitlist() {}
   |         ^^^^^^^^^^^^^^^^^^^^

error[E0603]: function `add_to_waitlist` is private
  --> src/lib.rs:13:30
   |
13 |     front_of_house::hosting::add_to_waitlist();
   |                              ^^^^^^^^^^^^^^^ private function
   |
note: the function `add_to_waitlist` is defined here
  --> src/lib.rs:3:9
   |
 3 |         fn add_to_waitlist() {}
   |         ^^^^^^^^^^^^^^^^^^^^

For more information about this error, try `rustc --explain E0603`.
error: could not compile `restaurant` (lib) due to 2 previous errors

무슨 일이 있었을까요? mod hosting 앞에 pub 키워드를 붙이면 그 모듈 자체는 공개가 됩니다. 이 변경으로, 우리가 front_of_house 에 접근할 수 있다면 이제 hosting 에도 접근할 수 있습니다. 하지만 hosting 안의 내용물 은 여전히 private 입니다. 모듈을 공개로 만든다고 해서 내용물까지 자동으로 공개되지는 않습니다. 모듈에 붙은 pub 키워드는 조상 모듈의 코드가 그 모듈을 참조 할 수 있게 할 뿐, 그 안의 코드를 바로 사용할 수 있게 하지는 않습니다. 모듈은 컨테이너이기 때문에, 모듈만 공개로 만들어서는 할 수 있는 일이 많지 않습니다. 그 안의 항목 중 하나 이상도 명시적으로 공개해야 합니다.

목록 7-6의 오류는 add_to_waitlist 함수가 private 하다고 말합니다. privacy 규칙은 모듈뿐 아니라 구조체, enum, 함수, 메서드에도 모두 적용됩니다.

그렇다면 목록 7-7처럼 add_to_waitlist 함수 정의 앞에도 pub 키워드를 붙여 이 함수도 공개로 만들어 봅시다.

mod front_of_house {
    pub mod hosting {
        pub fn add_to_waitlist() {}
    }
}

// -- snip --
pub fn eat_at_restaurant() {
    // Absolute path
    crate::front_of_house::hosting::add_to_waitlist();

    // Relative path
    front_of_house::hosting::add_to_waitlist();
}

이제 코드는 컴파일됩니다! privacy 규칙과 관련해서 왜 pub 를 추가하면 eat_at_restaurant 안에서 이 경로들을 사용할 수 있게 되는지, 절대 경로와 상대 경로를 기준으로 다시 봅시다.

절대 경로에서는 먼저 크레이트 모듈 트리의 루트인 crate 에서 시작합니다. front_of_house 모듈은 크레이트 루트에 정의되어 있습니다. front_of_house 자체는 public 이 아니지만, eat_at_restaurant 함수가 front_of_house 와 같은 모듈(즉 둘이 형제) 안에 정의되어 있으므로 eat_at_restaurant 에서 front_of_house 를 참조할 수 있습니다. 그 다음은 pub 로 표시된 hosting 모듈입니다. 우리는 hosting 의 부모 모듈에 접근할 수 있으므로 hosting 에도 접근할 수 있습니다. 마지막으로 add_to_waitlist 함수도 pub 로 표시되어 있고, 그 부모 모듈에도 접근할 수 있으므로, 이 함수 호출은 유효합니다.

상대 경로에서는 첫 단계만 다르고 논리는 같습니다. 크레이트 루트가 아니라 front_of_house 에서 시작합니다. front_of_house 모듈은 eat_at_restaurant 와 같은 모듈 안에 정의되어 있으므로, eat_at_restaurant 가 속한 모듈에서 시작하는 상대 경로도 작동합니다. 그 뒤로는 hosting 과 add_to_waitlist 가 둘 다 pub 이므로 나머지 경로도 유효합니다.

만약 여러분이 라이브러리 크레이트를 공유해서 다른 프로젝트에서도 그 코드를 사용하게 하려면, 공개 API는 사용자와의 계약이 됩니다. 사용자들이 여러분의 코드와 어떻게 상호작용할 수 있는지를 결정하기 때문입니다. 사람들이 여러분의 크레이트에 쉽게 의존할 수 있도록 공개 API 변경을 관리하는 데는 여러 고려사항이 있습니다. 이 책의 범위를 벗어나는 주제이므로, 관심이 있다면 Rust API Guidelines를 참고하세요.

super 로 상대 경로 시작하기

현재 모듈이나 크레이트 루트가 아니라, 부모 모듈 에서 시작하는 상대 경로도 만들 수 있습니다. 경로 시작에 super 를 사용하면 됩니다. 이는 파일시스템 경로에서 부모 디렉터리로 가는 .. 와 비슷합니다. super 를 사용하면 부모 모듈 안에 있는 항목을 참조할 수 있으므로, 어떤 모듈이 부모와 밀접하게 관련되어 있지만 언젠가 모듈 트리 안의 다른 위치로 부모와 함께 이동할 가능성이 있을 때 특히 유용합니다.

목록 7-8의 코드는 셰프가 잘못된 주문을 바로잡은 뒤 직접 손님에게 전달하는 상황을 모델링합니다. back_of_house 모듈 안에 정의된 fix_incorrect_order 함수는 super 로 시작하는 경로를 사용해 부모 모듈 안에 정의된 deliver_order 함수를 호출합니다.

fn deliver_order() {}

mod back_of_house {
    fn fix_incorrect_order() {
        cook_order();
        super::deliver_order();
    }

    fn cook_order() {}
}

fix_incorrect_order 함수는 back_of_house 모듈 안에 있으므로, super 를 사용해 back_of_house 의 부모 모듈로 올라갈 수 있습니다. 이 경우 부모는 크레이트 루트인 crate 입니다. 거기서부터 deliver_order 를 찾으면 됩니다. 성공입니다! 우리는 back_of_house 모듈과 deliver_order 함수가 앞으로도 서로 같은 관계를 유지한 채 함께 이동할 가능성이 크다고 생각합니다. 따라서 이 코드가 나중에 다른 모듈로 옮겨지더라도 수정할 곳을 줄이기 위해 super 를 사용했습니다.

구조체와 enum을 공개로 만들기

구조체와 enum도 pub 를 사용해 공개로 지정할 수 있지만, 이 경우에는 몇 가지 추가 세부가 있습니다. 구조체 정의 앞에 pub 를 붙이면 구조체 자체는 공개되지만, 구조체의 필드들은 여전히 private 입니다. 각 필드는 공개할지 말지를 개별적으로 정할 수 있습니다. 목록 7-9에서는 public 한 back_of_house::Breakfast 구조체를 정의했는데, toast 필드는 public 이고 seasonal_fruit 필드는 private 입니다. 이는 손님은 식사에 어떤 빵이 나올지 선택할 수 있지만, 어떤 과일이 곁들여질지는 계절과 재고 상황에 따라 셰프가 결정하는 레스토랑 상황을 모델링한 것입니다. 과일 종류는 자주 바뀌므로, 손님은 과일을 고를 수도 없고 어떤 과일이 나올지도 볼 수 없습니다.

mod back_of_house {
    pub struct Breakfast {
        pub toast: String,
        seasonal_fruit: String,
    }

    impl Breakfast {
        pub fn summer(toast: &str) -> Breakfast {
            Breakfast {
                toast: String::from(toast),
                seasonal_fruit: String::from("peaches"),
            }
        }
    }
}

pub fn eat_at_restaurant() {
    // Order a breakfast in the summer with Rye toast.
    let mut meal = back_of_house::Breakfast::summer("Rye");
    // Change our mind about what bread we'd like.
    meal.toast = String::from("Wheat");
    println!("I'd like {} toast please", meal.toast);

    // The next line won't compile if we uncomment it; we're not allowed
    // to see or modify the seasonal fruit that comes with the meal.
    // meal.seasonal_fruit = String::from("blueberries");
}

back_of_house::Breakfast 구조체의 toast 필드는 public 이므로, eat_at_restaurant 안에서 점 표기법으로 toast 필드를 읽고 쓸 수 있습니다. 하지만 seasonal_fruit 는 private 이기 때문에 eat_at_restaurant 에서 사용할 수 없습니다. 직접 seasonal_fruit 값을 바꾸려는 줄의 주석을 풀어 보면 어떤 오류가 나는지 확인할 수 있습니다!

또한 back_of_house::Breakfast 는 private 필드를 하나 가지고 있으므로, Breakfast 인스턴스를 만들어 주는 public 연관 함수가 필요합니다(여기서는 summer 라는 이름을 붙였습니다). 만약 Breakfast 에 이런 함수가 없다면, eat_at_restaurant 안에서 Breakfast 인스턴스를 만들 수 없습니다. private 필드 seasonal_fruit 값을 설정할 방법이 없기 때문입니다.

반면 enum을 public 으로 만들면, 그 variant 들은 자동으로 모두 public 이 됩니다. 즉 enum 키워드 앞에만 pub 를 붙이면 됩니다. 목록 7-10을 보세요.

mod back_of_house {
    pub enum Appetizer {
        Soup,
        Salad,
    }
}

pub fn eat_at_restaurant() {
    let order1 = back_of_house::Appetizer::Soup;
    let order2 = back_of_house::Appetizer::Salad;
}

Appetizer enum을 public 으로 만들었기 때문에, eat_at_restaurant 안에서 Soup 와 Salad variant를 사용할 수 있습니다.

Enum은 variant 가 public 이 아니면 사실상 별로 쓸모가 없습니다. 그래서 매번 variant 마다 전부 pub 를 달아야 한다면 꽤 성가실 것입니다. 이런 이유로 enum variant는 기본적으로 public 입니다. 반면 구조체는 필드가 공개되지 않아도 유용한 경우가 많기 때문에, 구조체 필드는 pub 로 표시하지 않는 한 기본적으로 private 라는 일반 규칙을 따릅니다.

이제 pub 과 관련해 아직 다루지 않은 마지막 모듈 시스템 기능이 하나 남아 있습니다. 바로 use 키워드입니다. 먼저 use 자체를 살펴보고, 그다음 pub 과 use 를 함께 쓰는 방법을 보겠습니다.

use 키워드로 경로를 스코프로 가져오기

use 키워드로 경로를 스코프로 가져오기

함수를 호출할 때마다 전체 경로를 일일이 적는 것은 번거롭고 반복적으로 느껴질 수 있습니다. 목록 7-7에서는 add_to_waitlist 함수를 호출하기 위해 절대 경로를 쓰든 상대 경로를 쓰든, 매번 front_of_house 와 hosting 을 함께 적어야 했습니다. 다행히 이를 단순화하는 방법이 있습니다. use 키워드를 사용해 한 번만 경로의 지름길을 만들고, 그 뒤로는 같은 스코프 안에서 더 짧은 이름만 쓰면 됩니다.

목록 7-11에서는 crate::front_of_house::hosting 모듈을 eat_at_restaurant 함수의 스코프로 가져와, eat_at_restaurant 안에서 hosting::add_to_waitlist 라고만 적어 add_to_waitlist 함수를 호출하게 합니다.

mod front_of_house {
    pub mod hosting {
        pub fn add_to_waitlist() {}
    }
}

use crate::front_of_house::hosting;

pub fn eat_at_restaurant() {
    hosting::add_to_waitlist();
}

스코프 안에 use 와 경로를 추가하는 것은 파일시스템에서 심볼릭 링크를 만드는 것과 비슷합니다. 크레이트 루트에 use crate::front_of_house::hosting 을 추가하면, hosting 이 이제 그 스코프 안에서 유효한 이름이 됩니다. 마치 hosting 모듈이 크레이트 루트에 정의된 것처럼 보이게 되는 것입니다. use 로 스코프 안에 가져온 경로도 다른 경로와 마찬가지로 privacy 검사를 받습니다.

use 는 오직 그것이 선언된 특정 스코프 에서만 지름길을 만든다는 점에 주의하세요. 목록 7-12에서는 eat_at_restaurant 함수를 customer 라는 새 자식 모듈 안으로 옮깁니다. 그러면 함수 본문은 use 문이 있는 스코프와 다른 스코프에 있게 되므로, 더 이상 컴파일되지 않습니다.

mod front_of_house {
    pub mod hosting {
        pub fn add_to_waitlist() {}
    }
}

use crate::front_of_house::hosting;

mod customer {
    pub fn eat_at_restaurant() {
        hosting::add_to_waitlist();
    }
}

컴파일러 오류를 보면, customer 모듈 안에서는 이 지름길이 더 이상 적용되지 않는다는 것을 알 수 있습니다.

$ cargo build
   Compiling restaurant v0.1.0 (file:///projects/restaurant)
error[E0433]: failed to resolve: use of unresolved module or unlinked crate `hosting`
  --> src/lib.rs:11:9
   |
11 |         hosting::add_to_waitlist();
   |         ^^^^^^^ use of unresolved module or unlinked crate `hosting`
   |
   = help: if you wanted to use a crate named `hosting`, use `cargo add hosting` to add it to your `Cargo.toml`
help: consider importing this module through its public re-export
   |
10 +     use crate::hosting;
   |

warning: unused import: `crate::front_of_house::hosting`
 --> src/lib.rs:7:5
  |
7 | use crate::front_of_house::hosting;
  |     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  |
  = note: `#[warn(unused_imports)]` on by default

For more information about this error, try `rustc --explain E0433`.
warning: `restaurant` (lib) generated 1 warning
error: could not compile `restaurant` (lib) due to 1 previous error; 1 warning emitted

또한 use 가 원래 있던 스코프 안에서는 더 이상 사용되지 않는다는 경고도 함께 뜹니다. 이 문제를 해결하려면 use 를 customer 모듈 안으로 옮기거나, 자식 모듈 customer 안에서 super::hosting 처럼 부모 모듈의 지름길을 참조하면 됩니다.

관용적인 use 경로 만들기

목록 7-11을 보며 이런 의문이 들었을 수도 있습니다. 왜 use crate::front_of_house::hosting 을 적고, eat_at_restaurant 안에서는 hosting::add_to_waitlist 를 호출했을까요? 같은 효과를 얻기 위해 add_to_waitlist 함수까지 포함한 경로를 use 로 가져와도 될 것 같은데 말입니다. 목록 7-13처럼요.

mod front_of_house {
    pub mod hosting {
        pub fn add_to_waitlist() {}
    }
}

use crate::front_of_house::hosting::add_to_waitlist;

pub fn eat_at_restaurant() {
    add_to_waitlist();
}

목록 7-11과 목록 7-13은 둘 다 같은 일을 하지만, use 로 함수를 스코프로 가져오는 관용적인 방식은 목록 7-11 쪽입니다. 함수 자체가 아니라 부모 모듈을 use 로 가져오면, 함수 호출 시 부모 모듈 이름을 붙여야 합니다. 이 방식은 함수가 로컬에 정의된 것이 아니라는 사실을 드러내면서도, 전체 경로를 계속 반복하는 일은 줄여 줍니다. 반대로 목록 7-13의 코드는 add_to_waitlist 가 어디서 정의된 것인지 한눈에 분명하지 않습니다.

반면 구조체, enum, 기타 항목을 use 로 가져올 때는 전체 경로를 지정하는 것이 관용적입니다. 목록 7-14는 표준 라이브러리의 HashMap 구조체를 바이너리 크레이트 스코프로 가져오는 관용적인 방식을 보여 줍니다.

use std::collections::HashMap;

fn main() {
    let mut map = HashMap::new();
    map.insert(1, 2);
}

이 관용구 뒤에 특별히 강한 이유가 있는 것은 아닙니다. 그냥 이런 방식이 널리 퍼졌고, 사람들이 이런 형태로 러스트 코드를 읽고 쓰는 데 익숙해졌기 때문입니다.

이 관용구의 예외는, use 문으로 같은 이름의 항목 두 개를 동시에 스코프로 가져오려는 경우입니다. 러스트는 같은 이름 두 개를 허용하지 않기 때문입니다. 목록 7-15는 이름은 같지만 부모 모듈이 다른 두 Result 타입을 스코프로 가져오는 방법과, 각각을 어떻게 참조하는지를 보여 줍니다.

use std::fmt;
use std::io;

fn function1() -> fmt::Result {
    // --snip--
    Ok(())
}

fn function2() -> io::Result<()> {
    // --snip--
    Ok(())
}

보시다시피 부모 모듈 이름을 함께 쓰면 두 Result 타입을 구별할 수 있습니다. 만약 use std::fmt::Result 와 use std::io::Result 를 그대로 둘 다 가져오면, 같은 스코프에 Result 타입이 두 개 있게 되어, 우리가 Result 라고 썼을 때 러스트는 어느 것을 뜻하는지 알 수 없게 됩니다.

as 키워드로 새 이름 붙이기

같은 이름의 타입 두 개를 같은 스코프로 가져오는 문제를 해결하는 또 다른 방법도 있습니다. 경로 뒤에 as 와 새 로컬 이름, 즉 별칭(alias) 을 붙이는 것입니다. 목록 7-16은 as 를 사용해 두 Result 타입 중 하나의 이름을 바꿈으로써, 목록 7-15의 코드를 다른 방식으로 쓴 예입니다.

use std::fmt::Result;
use std::io::Result as IoResult;

fn function1() -> Result {
    // --snip--
    Ok(())
}

fn function2() -> IoResult<()> {
    // --snip--
    Ok(())
}

두 번째 use 문에서는 std::io::Result 타입의 새 이름으로 IoResult 를 선택했습니다. 이제 std::fmt 에서 가져온 Result 와 충돌하지 않게 됩니다. 목록 7-15와 7-16은 둘 다 관용적인 방식으로 여겨지므로, 어느 쪽을 선택할지는 여러분의 취향에 달려 있습니다.

pub use 로 이름 재수출하기

use 키워드로 어떤 이름을 스코프로 가져오면, 그 이름은 가져온 그 스코프 안에서만 private 합니다. 그 스코프 밖의 코드가 그 이름을 마치 그 스코프 안에서 정의된 것처럼 참조할 수 있게 하려면, pub 와 use 를 결합할 수 있습니다. 이 기법을 재수출(re-exporting) 이라고 합니다. 어떤 항목을 스코프로 가져오면서 동시에, 다른 사람도 자기 스코프로 가져올 수 있게 공개하기 때문입니다.

목록 7-17은 목록 7-11의 루트 모듈 안 use 를 pub use 로 바꾼 코드입니다.

mod front_of_house {
    pub mod hosting {
        pub fn add_to_waitlist() {}
    }
}

pub use crate::front_of_house::hosting;

pub fn eat_at_restaurant() {
    hosting::add_to_waitlist();
}

이 변경 이전에는, 외부 코드는 restaurant::front_of_house::hosting::add_to_waitlist() 경로를 사용해 add_to_waitlist 함수를 호출해야 했고, 그러려면 front_of_house 모듈 자체도 pub 로 표시되어 있어야 했습니다. 하지만 pub use 로 루트 모듈에서 hosting 모듈을 재수출했기 때문에, 이제 외부 코드는 restaurant::hosting::add_to_waitlist() 경로를 사용할 수 있습니다.

재수출은 내부 코드 구조와, 그 코드를 호출하는 프로그래머가 그 도메인을 생각하는 방식이 다를 때 유용합니다. 이 레스토랑 비유에서 레스토랑을 운영하는 사람은 “프런트 오브 하우스” 와 “백 오브 하우스” 로 생각하겠지만, 손님은 아마 그런 식으로 생각하지 않을 것입니다. pub use 를 사용하면 우리는 코드는 한 구조로 짜되, 외부에는 다른 구조를 노출할 수 있습니다. 이렇게 하면 라이브러리를 작성하는 사람에게도, 라이브러리를 호출하는 사람에게도 더 잘 정리된 라이브러리가 됩니다. pub use 의 또 다른 예와, 이것이 크레이트 문서에 어떤 영향을 미치는지는 14장의 “편리한 공개 API 내보내기” 절에서 다시 보게 됩니다.

외부 패키지 사용하기

2장에서는 난수를 얻기 위해 rand 라는 외부 패키지를 사용한 숫자 맞히기 게임을 만들었습니다. 프로젝트에서 rand 를 사용하기 위해 Cargo.toml 에 다음 줄을 추가했었습니다.

rand = "0.8.5"

Cargo.toml 에 rand 를 의존성으로 추가하면, Cargo는 crates.io 에서 rand 패키지와 그 의존성들을 내려받아 우리 프로젝트에서 사용할 수 있게 만듭니다.

그다음 우리 패키지 스코프로 rand 정의를 가져오기 위해, 크레이트 이름 rand 로 시작하는 use 줄을 추가하고 스코프로 가져오고 싶은 항목을 나열했습니다. 2장의 “임의의 숫자 생성하기” 절에서 Rng 트레이트를 스코프로 가져오고 rand::thread_rng 함수를 호출했던 것을 떠올려 보세요.

use std::io;

use rand::Rng;

fn main() {
    println!("Guess the number!");

    let secret_number = rand::thread_rng().gen_range(1..=100);

    println!("The secret number is: {secret_number}");

    println!("Please input your guess.");

    let mut guess = String::new();

    io::stdin()
        .read_line(&mut guess)
        .expect("Failed to read line");

    println!("You guessed: {guess}");
}

러스트 커뮤니티 구성원들은 crates.io 에 수많은 패키지를 공개해 두었고, 그중 어떤 것이든 여러분의 패키지에 가져오는 과정은 똑같습니다. 즉, Cargo.toml 에 의존성을 적고, use 로 그 크레이트의 항목을 스코프로 가져오면 됩니다.

표준 라이브러리 std 도 사실은 우리 패키지 밖에 있는 외부 크레이트라는 점도 기억하세요. 다만 표준 라이브러리는 러스트 언어와 함께 제공되므로, Cargo.toml 을 바꿔서 std 를 따로 추가할 필요는 없습니다. 그러나 그 안의 항목을 패키지 스코프로 가져오려면 여전히 use 를 통해 참조해야 합니다. 예를 들어 HashMap 을 쓰려면 다음 줄을 사용합니다.

#![allow(unused)]
fn main() {
use std::collections::HashMap;
}

이것은 표준 라이브러리 크레이트 이름인 std 로 시작하는 절대 경로입니다.

중첩 경로로 use 목록 정리하기

같은 크레이트나 같은 모듈 안에 정의된 여러 항목을 사용한다면, 각 항목을 별도 use 줄로 적는 것은 파일에서 세로 공간을 많이 차지할 수 있습니다. 예를 들어 목록 2-4의 숫자 맞히기 게임에서는 다음 두 use 문으로 std 의 항목을 스코프로 가져왔습니다.

use rand::Rng;
// --snip--
use std::cmp::Ordering;
use std::io;
// --snip--

fn main() {
    println!("Guess the number!");

    let secret_number = rand::thread_rng().gen_range(1..=100);

    println!("The secret number is: {secret_number}");

    println!("Please input your guess.");

    let mut guess = String::new();

    io::stdin()
        .read_line(&mut guess)
        .expect("Failed to read line");

    println!("You guessed: {guess}");

    match guess.cmp(&secret_number) {
        Ordering::Less => println!("Too small!"),
        Ordering::Greater => println!("Too big!"),
        Ordering::Equal => println!("You win!"),
    }
}

대신 중첩 경로를 사용하면 같은 항목들을 한 줄로 가져올 수 있습니다. 방법은 경로의 공통 부분을 먼저 쓰고, 그 뒤에 이중 콜론을 붙인 다음, 서로 다른 부분만 중괄호 안에 목록으로 넣는 것입니다. 목록 7-18을 보세요.

use rand::Rng;
// --snip--
use std::{cmp::Ordering, io};
// --snip--

fn main() {
    println!("Guess the number!");

    let secret_number = rand::thread_rng().gen_range(1..=100);

    println!("The secret number is: {secret_number}");

    println!("Please input your guess.");

    let mut guess = String::new();

    io::stdin()
        .read_line(&mut guess)
        .expect("Failed to read line");

    let guess: u32 = guess.trim().parse().expect("Please type a number!");

    println!("You guessed: {guess}");

    match guess.cmp(&secret_number) {
        Ordering::Less => println!("Too small!"),
        Ordering::Greater => println!("Too big!"),
        Ordering::Equal => println!("You win!"),
    }
}

규모가 큰 프로그램에서는 같은 크레이트나 모듈에서 많은 항목을 사용할 때, 이런 중첩 경로가 필요한 별도 use 문 개수를 크게 줄여 줍니다.

중첩 경로는 경로의 어느 수준에서든 사용할 수 있습니다. 따라서 일부 하위 경로를 공유하는 두 use 문을 합칠 때도 유용합니다. 예를 들어 목록 7-19는 두 개의 use 문을 보여 줍니다. 하나는 std::io 를, 다른 하나는 std::io::Write 를 스코프로 가져옵니다.

use std::io;
use std::io::Write;

이 두 경로의 공통 부분은 std::io 이며, 첫 번째 경로 전체가 바로 그 공통 부분입니다. 이 둘을 하나의 use 문으로 합치려면, 목록 7-20처럼 중첩 경로 안에서 self 를 사용할 수 있습니다.

use std::io::{self, Write};

이 한 줄은 std::io 와 std::io::Write 를 둘 다 스코프로 가져옵니다.

글롭 연산자로 항목 가져오기

어떤 경로 안에 정의된 모든 public 항목을 스코프로 가져오고 싶다면, 경로 뒤에 * 글롭 연산자를 붙일 수 있습니다.

#![allow(unused)]
fn main() {
use std::collections::*;
}

이 use 문은 std::collections 안에 정의된 모든 public 항목을 현재 스코프로 가져옵니다. 다만 글롭 연산자는 사용할 때 주의가 필요합니다! 글롭은 어떤 이름들이 현재 스코프에 들어와 있는지, 그리고 프로그램에서 사용한 이름이 원래 어디서 정의된 것인지를 파악하기 어렵게 만들 수 있습니다. 또한 의존성이 정의를 바꾸면, 여러분이 가져온 내용도 같이 바뀝니다. 예를 들어 그 의존성이 같은 스코프 안에서 여러분의 정의와 같은 이름의 항목을 새로 추가하면, 의존성을 업그레이드했을 때 컴파일 오류로 이어질 수 있습니다.

글롭 연산자는 테스트할 때 테스트 대상의 모든 것을 tests 모듈 안으로 가져오는 데 자주 사용되며, 이는 11장의 “테스트 작성 방법” 절에서 설명합니다. 또한 prelude 패턴의 일부로 사용되기도 합니다. 그 패턴에 대한 더 자세한 내용은 표준 라이브러리 문서 를 참고하세요.

모듈을 여러 파일로 분리하기

모듈을 여러 파일로 분리하기

지금까지 이 장의 예제들은 여러 모듈을 한 파일 안에 정의했습니다. 하지만 모듈이 커지면, 코드를 더 쉽게 탐색할 수 있도록 정의를 별도 파일로 옮기고 싶어질 수 있습니다.

예를 들어 여러 레스토랑 모듈이 있던 목록 7-17의 코드부터 시작해 봅시다. 이번에는 모든 모듈을 크레이트 루트 파일 안에 두지 않고, 각 모듈을 파일로 분리해 보겠습니다. 이 경우 크레이트 루트 파일은 src/lib.rs 이지만, 크레이트 루트가 src/main.rs 인 바이너리 크레이트에도 같은 절차를 적용할 수 있습니다.

먼저 front_of_house 모듈을 자체 파일로 분리합니다. front_of_house 모듈의 중괄호 안 코드를 제거하고 mod front_of_house; 선언만 남겨, src/lib.rs 가 목록 7-21의 코드만 담도록 만듭니다. 물론 목록 7-22의 src/front_of_house.rs 파일을 만들기 전까지는 이 코드는 컴파일되지 않습니다.

mod front_of_house;

pub use crate::front_of_house::hosting;

pub fn eat_at_restaurant() {
    hosting::add_to_waitlist();
}

그다음 중괄호 안에 있던 코드를 목록 7-22처럼 src/front_of_house.rs 라는 새 파일로 옮깁니다. 크레이트 루트에서 front_of_house 라는 이름의 모듈 선언을 봤기 때문에, 컴파일러는 이 파일에서 모듈 코드를 찾습니다.

pub mod hosting {
    pub fn add_to_waitlist() {}
}

주의할 점은, 모듈 트리 안에서 어떤 파일을 mod 선언으로 한 번만 불러오면 충분하다는 것입니다. 컴파일러가 그 파일이 프로젝트 일부라는 것을 알고(그리고 mod 문이 어디에 있는지 덕분에 모듈 트리 안의 어느 위치에 속하는지도 알고) 나면, 프로젝트의 다른 파일에서는 “모듈 트리의 항목을 경로로 가리키기” 절에서 설명한 것처럼 선언된 위치를 가리키는 경로로 그 코드에 접근하면 됩니다. 다시 말해 mod 는 다른 언어에서 보았을 수도 있는 “include” 연산이 아닙니다.

이제 hosting 모듈도 별도 파일로 분리해 봅시다. 다만 이번 과정은 조금 다릅니다. hosting 은 루트 모듈의 자식이 아니라 front_of_house 의 자식 모듈이기 때문입니다. 따라서 hosting 파일은 모듈 트리에서 그 조상 이름을 딴 새 디렉터리, 여기서는 src/front_of_house 안에 두게 됩니다.

hosting 을 옮기기 시작하려면, src/front_of_house.rs 를 hosting 모듈 선언만 남도록 바꿉니다.

pub mod hosting;

그다음 src/front_of_house 디렉터리와 hosting.rs 파일을 만들어 hosting 모듈에 있던 정의를 넣습니다.

pub fn add_to_waitlist() {}

만약 hosting.rs 를 src 디렉터리에 그냥 두었다면, 컴파일러는 그 코드를 크레이트 루트에서 선언된 hosting 모듈의 코드라고 기대했을 것입니다. front_of_house 자식으로 선언된 hosting 모듈의 코드라고는 보지 않습니다. 즉 어떤 모듈의 코드를 찾을 때 어떤 파일을 살펴볼지에 대한 컴파일러 규칙 덕분에, 디렉터리와 파일 구조가 모듈 트리와 더 가깝게 맞춰지게 됩니다.

이제 각 모듈의 코드를 별도 파일로 옮겼지만, 모듈 트리는 그대로 유지됩니다. 정의가 다른 파일에 있더라도 eat_at_restaurant 안의 함수 호출은 수정 없이 그대로 동작합니다. 이 기법을 사용하면 모듈이 커질 때 새 파일로 옮겨 가며 구조를 유지할 수 있습니다.

또한 src/lib.rs 안의 pub use crate::front_of_house::hosting 문도 바뀌지 않았고, use 는 어떤 파일이 크레이트 일부로 컴파일되는지에는 아무 영향도 주지 않는다는 점에도 주목하세요. 모듈을 선언하는 것은 mod 키워드이며, 러스트는 모듈과 같은 이름의 파일을 찾아 그 코드를 해당 모듈에 넣습니다.

정리

러스트는 패키지를 여러 크레이트로 나누고, 하나의 크레이트도 여러 모듈로 나눌 수 있게 해 줍니다. 그래서 한 모듈에 정의된 항목을 다른 모듈에서 참조할 수 있습니다. 이때 절대 경로나 상대 경로를 사용할 수 있고, use 문을 사용하면 같은 스코프 안에서 더 짧은 경로를 반복해서 사용할 수 있습니다. 모듈 코드는 기본적으로 private 이지만, pub 키워드를 붙여 정의를 public 하게 만들 수 있습니다.

다음 장에서는, 이렇게 잘 정리한 코드 안에서 사용할 수 있는 표준 라이브러리의 몇 가지 컬렉션 자료구조를 살펴보겠습니다.

자주 쓰는 컬렉션

러스트의 표준 라이브러리에는 컬렉션(collections) 이라고 부르는 아주 유용한 자료구조가 여럿 들어 있습니다. 대부분의 다른 데이터 타입은 하나의 특정 값만 표현하지만, 컬렉션은 여러 값을 담을 수 있습니다. 내장된 배열이나 튜플과 달리, 이 컬렉션들이 가리키는 데이터는 힙에 저장됩니다. 따라서 데이터 양을 컴파일 시점에 미리 알 필요가 없고, 프로그램이 실행되는 동안 크기가 커지거나 줄어들 수 있습니다. 컬렉션 종류마다 제공하는 기능과 비용이 다르며, 지금 상황에 맞는 것을 고르는 능력은 시간을 들여 익히게 됩니다. 이 장에서는 러스트 프로그램에서 아주 자주 쓰이는 세 가지 컬렉션을 다룹니다.

• 벡터(vector) 는 개수가 가변적인 여러 값을 메모리에서 서로 붙여 저장할 수 있게 합니다.
• 문자열(string) 은 문자의 컬렉션입니다. 앞에서 String 타입을 간단히 언급했지만, 이 장에서는 그것을 더 깊이 다룹니다.
• 해시 맵(hash map) 은 특정 키와 값을 연결할 수 있게 합니다. 이는 더 일반적인 자료 구조인 맵(map) 의 한 가지 구현입니다.

표준 라이브러리가 제공하는 다른 컬렉션 종류를 알고 싶다면 문서를 참고하세요.

이 장에서는 벡터, 문자열, 해시 맵을 어떻게 만들고 갱신하는지, 그리고 각각이 어떤 점에서 특별한지를 설명합니다.

벡터로 값 목록 저장하기

벡터로 값 목록 저장하기

우리가 처음 살펴볼 컬렉션 타입은 벡터라고도 부르는 Vec<T> 입니다. 벡터는 여러 값을 하나의 자료구조 안에 저장하며, 그 값들은 메모리 안에서 서로 붙어 있습니다. 벡터는 같은 타입의 값만 저장할 수 있습니다. 파일의 텍스트 줄들이나 장바구니 안 상품 가격처럼, 항목들의 목록을 가지고 있을 때 유용합니다.

새 벡터 만들기

새로운 빈 벡터를 만들려면 목록 8-1처럼 Vec::new 함수를 호출합니다.

fn main() {
    let v: Vec<i32> = Vec::new();
}

여기서는 타입 주석을 추가했다는 점에 주목하세요. 아직 이 벡터에 아무 값도 넣지 않았기 때문에, 러스트는 우리가 어떤 종류의 요소를 저장하려는지 알 수 없습니다. 이것은 중요한 점입니다. 벡터는 제네릭으로 구현되어 있으며, 여러분 자신의 타입에 제네릭을 적용하는 방법은 10장에서 다룹니다. 지금은 표준 라이브러리의 Vec<T> 가 어떤 타입이든 담을 수 있다는 것만 알면 충분합니다. 특정 타입을 저장하는 벡터를 만들 때는 꺾쇠 괄호 안에 그 타입을 명시할 수 있습니다. 목록 8-1에서는 v 안의 Vec<T> 가 i32 타입의 요소를 담을 것이라고 러스트에게 알려 준 것입니다.

하지만 대부분은 초기값을 가진 Vec<T> 를 만들고, 러스트가 저장하려는 값의 타입을 추론하게 할 것입니다. 그래서 이런 타입 주석은 드물게만 필요합니다. 러스트는 vec! 매크로를 제공하는데, 이것은 여러분이 넘긴 값들을 담은 새 벡터를 만들어 줍니다. 목록 8-2는 값 1, 2, 3 을 담은 새 Vec<i32> 를 만듭니다. 이 정수 타입은, 3장의 “데이터 타입” 절에서 다뤘듯이 기본 정수 타입인 i32 가 됩니다.

fn main() {
    let v = vec![1, 2, 3];
}

초기값으로 i32 값을 넣었기 때문에, 러스트는 v 의 타입이 Vec<i32> 라고 추론할 수 있고 타입 주석도 필요 없습니다. 다음으로는 벡터를 어떻게 수정하는지 살펴봅시다.

벡터 갱신하기

벡터를 만든 뒤 요소를 추가하려면 목록 8-3처럼 push 메서드를 사용할 수 있습니다.

fn main() {
    let mut v = Vec::new();

    v.push(5);
    v.push(6);
    v.push(7);
    v.push(8);
}

모든 변수와 마찬가지로 값을 바꾸려면, 3장에서 이야기했듯이 mut 키워드로 변수를 가변으로 만들어야 합니다. 벡터 안에 넣는 숫자는 모두 i32 타입이고, 러스트는 이 사실을 데이터로부터 추론하므로 Vec<i32> 주석이 따로 필요 없습니다.

벡터 요소 읽기

벡터 안에 저장된 값을 참조하는 방법은 두 가지가 있습니다. 인덱싱을 사용하거나 get 메서드를 사용하는 것입니다. 다음 예제에서는 각 방법이 반환하는 값의 타입을 이해하기 쉽도록 주석처럼 드러내 두었습니다.

목록 8-4는 인덱스 문법과 get 메서드, 두 방식으로 벡터 값에 접근하는 예를 보여 줍니다.

fn main() {
    let v = vec![1, 2, 3, 4, 5];

    let third: &i32 = &v[2];
    println!("The third element is {third}");

    let third: Option<&i32> = v.get(2);
    match third {
        Some(third) => println!("The third element is {third}"),
        None => println!("There is no third element."),
    }
}

여기서 몇 가지 세부를 눈여겨봅시다. 인덱스 값 2 로 세 번째 요소를 가져오는데, 이는 벡터 인덱스가 0부터 시작하기 때문입니다. & 와 [] 를 사용하면 해당 인덱스 위치의 요소에 대한 참조를 얻게 됩니다. 반면 get 메서드에 인덱스를 인수로 넘기면, match 와 함께 사용할 수 있는 Option<&T> 를 얻게 됩니다.

러스트가 벡터 요소를 참조하는 두 가지 방법을 제공하는 이유는, 기존 요소 범위를 벗어난 인덱스를 사용했을 때 프로그램이 어떻게 동작하길 원하는지를 여러분이 선택할 수 있게 하기 위해서입니다. 예를 들어 요소가 다섯 개인 벡터가 있을 때, 인덱스 100의 요소에 각 기법으로 접근해 보면 어떤 일이 벌어지는지 목록 8-5가 보여 줍니다.

fn main() {
    let v = vec![1, 2, 3, 4, 5];

    let does_not_exist = &v[100];
    let does_not_exist = v.get(100);
}

이 코드를 실행하면 첫 번째 [] 방식은 존재하지 않는 요소를 참조하기 때문에 프로그램을 패닉하게 만듭니다. 이 방식은 벡터 끝을 넘는 요소 접근이 시도되면 프로그램을 즉시 중단시키고 싶을 때 적합합니다.

get 메서드는 인덱스가 벡터 범위를 벗어나면 패닉하지 않고 None 을 반환합니다. 정상적인 상황에서도 가끔 범위를 벗어난 접근이 일어날 수 있다면 이 방식을 쓰는 것이 좋습니다. 그러면 여러분의 코드는 6장에서 다룬 것처럼 Some(&element) 또는 None 둘 다를 처리하는 로직을 갖게 됩니다. 예를 들어 인덱스가 사용자의 입력에서 온 값일 수 있습니다. 사용자가 실수로 너무 큰 숫자를 입력해 None 이 반환되면, 현재 벡터에 항목이 몇 개인지 알려 주고 유효한 값을 다시 입력할 기회를 줄 수 있습니다. 이것이 오타 하나로 프로그램이 크래시하는 것보다 사용자 친화적입니다.

프로그램이 유효한 참조를 가지고 있으면, 대여 검사기는 4장에서 다룬 소유권 및 대여 규칙을 적용하여 그 참조와 벡터 내용에 대한 다른 참조들이 계속 유효하도록 보장합니다. “같은 스코프 안에서는 가변 참조와 불변 참조를 동시에 가질 수 없다”는 규칙을 떠올려 보세요. 이 규칙은 목록 8-6에 그대로 적용됩니다. 여기서는 벡터 첫 번째 요소에 대한 불변 참조를 잡아 둔 상태에서 벡터 끝에 새 요소를 추가하려 합니다. 이 프로그램은 나중에 그 요소를 다시 참조하려 한다면 동작하지 않습니다.

fn main() {
    let mut v = vec![1, 2, 3, 4, 5];

    let first = &v[0];

    v.push(6);

    println!("The first element is: {first}");
}

이 코드를 컴파일하면 다음과 같은 오류가 납니다.

$ cargo run
   Compiling collections v0.1.0 (file:///projects/collections)
error[E0502]: cannot borrow `v` as mutable because it is also borrowed as immutable
 --> src/main.rs:6:5
  |
4 |     let first = &v[0];
  |                  - immutable borrow occurs here
5 |
6 |     v.push(6);
  |     ^^^^^^^^^ mutable borrow occurs here
7 |
8 |     println!("The first element is: {first}");
  |                                      ----- immutable borrow later used here

For more information about this error, try `rustc --explain E0502`.
error: could not compile `collections` (bin "collections") due to 1 previous error

목록 8-6의 코드는 얼핏 보기에는 동작해야 할 것처럼 보일 수 있습니다. 벡터 맨 끝에 변화가 생기는 것이 왜 첫 번째 요소에 대한 참조와 상관있을까요? 이 오류는 벡터가 동작하는 방식에서 비롯됩니다. 벡터는 값을 메모리 안에 서로 붙여 두기 때문에, 벡터 끝에 새 요소를 추가하는 일이 현재 저장된 위치에 모든 요소를 계속 붙여 놓을 공간이 없다면, 새 메모리를 할당하고 기존 요소를 통째로 복사하는 작업을 필요로 할 수도 있습니다. 그렇게 되면 첫 번째 요소를 가리키던 참조는 이미 해제된 메모리를 가리키게 됩니다. 대여 규칙은 프로그램이 그런 상황에 빠지는 것을 막아 줍니다.

벡터 값 순회하기

벡터 안의 각 요소에 차례로 접근하려면, 하나씩 인덱스로 가져오기보다 모든 요소를 반복(iterate)하면 됩니다. 목록 8-7은 for 루프를 사용해 i32 값을 담은 벡터의 각 요소에 대한 불변 참조를 얻고 출력하는 방법을 보여 줍니다.

fn main() {
    let v = vec![100, 32, 57];
    for i in &v {
        println!("{i}");
    }
}

가변 벡터의 각 요소에 대한 가변 참조를 순회하면서, 모든 요소 값을 바꿀 수도 있습니다. 목록 8-8의 for 루프는 각 요소에 50 을 더합니다.

fn main() {
    let mut v = vec![100, 32, 57];
    for i in &mut v {
        *i += 50;
    }
}

가변 참조가 가리키는 값을 바꾸려면, i 안의 실제 값에 도달하기 위해 먼저 * 역참조 연산자를 사용해야 하고, 그 뒤에 += 연산자를 쓸 수 있습니다. 역참조 연산자에 대해서는 15장의 “역참조 연산자로 값 따라가기” 절에서 더 자세히 다룹니다.

불변이든 가변이든 벡터를 순회하는 일은 대여 검사기 규칙 덕분에 안전합니다. 만약 목록 8-7이나 8-8의 for 루프 본문 안에서 항목을 삽입하거나 삭제하려 했다면, 목록 8-6에서 본 것과 비슷한 컴파일 오류를 얻게 됩니다. for 루프가 가지고 있는 벡터에 대한 참조가, 벡터 전체를 동시에 수정하는 것을 막기 때문입니다.

enum으로 여러 타입 저장하기

벡터는 같은 타입의 값만 저장할 수 있습니다. 이는 때때로 불편할 수 있습니다. 실제로는 서로 다른 타입의 항목 목록을 저장해야 하는 경우도 분명 있기 때문입니다. 다행히 enum의 variant들은 모두 같은 enum 타입 아래에 정의되므로, 서로 다른 타입의 요소를 표현할 하나의 타입이 필요할 때 enum을 정의해 사용할 수 있습니다!

예를 들어 어떤 스프레드시트의 한 행에서 값을 가져오고 싶은데, 그 행의 어떤 열은 정수, 어떤 열은 부동소수점 수, 어떤 열은 문자열을 담고 있다고 해 봅시다. 이때 다양한 값 타입을 담을 variant를 가지는 enum을 정의할 수 있고, 모든 variant는 동일한 타입, 즉 그 enum 타입으로 취급됩니다. 그러면 그 enum을 담는 벡터를 만들 수 있고, 결과적으로 서로 다른 타입을 하나의 벡터 안에 담을 수 있습니다. 목록 8-9가 이를 보여 줍니다.

fn main() {
    enum SpreadsheetCell {
        Int(i32),
        Float(f64),
        Text(String),
    }

    let row = vec![
        SpreadsheetCell::Int(3),
        SpreadsheetCell::Text(String::from("blue")),
        SpreadsheetCell::Float(10.12),
    ];
}

러스트는 각 요소를 저장하는 데 힙 메모리가 정확히 얼마나 필요한지 알아야 하므로, 벡터 안에 어떤 타입들이 들어갈지 컴파일 시점에 알고 있어야 합니다. 또한 이 벡터에 어떤 타입이 허용되는지도 명시적이어야 합니다. 만약 러스트가 벡터가 아무 타입이나 담을 수 있게 허용했다면, 벡터 요소에 수행하는 연산과 맞지 않는 타입이 들어가 오류를 일으킬 가능성이 생깁니다. enum과 match 식을 함께 사용하면, 6장에서 보았듯이 러스트는 가능한 모든 경우가 컴파일 시점에 처리되었는지를 확인해 줍니다.

런타임에 벡터에 저장될 타입의 전체 집합을 미리 알 수 없다면, enum 기법은 통하지 않습니다. 그런 경우에는 18장에서 다룰 trait object를 사용할 수 있습니다.

지금까지 벡터를 사용하는 가장 흔한 방법들을 살펴보았으니, 표준 라이브러리가 Vec<T> 에 정의해 둔 유용한 메서드들을 API 문서에서 꼭 확인해 보세요. 예를 들어 push 외에도 마지막 요소를 제거해 반환하는 pop 메서드가 있습니다.

벡터가 drop 되면 요소도 함께 drop 된다

다른 struct 와 마찬가지로, 벡터도 스코프를 벗어나면 해제됩니다. 목록 8-10은 그 지점을 주석으로 보여 줍니다.

fn main() {
    {
        let v = vec![1, 2, 3, 4];

        // do stuff with v
    } // <- v goes out of scope and is freed here
}

벡터가 drop 되면 그 안의 모든 내용도 함께 drop 됩니다. 즉 벡터가 들고 있던 정수들도 정리됩니다. 대여 검사기는 벡터 내용에 대한 참조가 벡터 자체가 유효한 동안에만 사용되도록 보장합니다.

이제 다음 컬렉션 타입인 String 으로 넘어가 봅시다!

문자열로 UTF-8 텍스트 저장하기

문자열에 UTF-8 텍스트 저장하기

우리는 4장에서 문자열을 이미 이야기했지만, 여기서는 더 깊이 들여다보겠습니다. 새로운 Rustacean이 문자열에서 자주 막히는 이유는 대개 세 가지가 겹치기 때문입니다. 러스트는 잠재적 오류를 잘 드러내는 언어이고, 문자열은 많은 프로그래머가 생각하는 것보다 복잡한 자료구조이며, 거기에 UTF-8 까지 얽혀 있습니다. 다른 프로그래밍 언어에서 넘어올 때 이 요소들이 합쳐져 꽤 어렵게 느껴질 수 있습니다.

문자열은 바이트들의 컬렉션에, 그 바이트를 텍스트로 해석할 때 유용한 기능을 제공하는 메서드가 덧붙은 형태로 구현되기 때문에, 여기서는 컬렉션의 맥락에서 문자열을 다룹니다. 이 절에서는 String 에 대해, 생성·갱신·읽기처럼 모든 컬렉션 타입이 공통으로 갖는 연산을 설명합니다. 또한 사람이 String 데이터를 이해하는 방식과 컴퓨터가 그것을 해석하는 방식의 차이 때문에, String 이 다른 컬렉션과 어떻게 다른지도 살펴봅니다.

문자열 정의하기

먼저 러스트에서 문자열 이라는 말을 정확히 무엇으로 뜻하는지 정의해 봅시다. 러스트 코어 언어 자체에는 문자열 타입이 하나뿐인데, 그것은 문자열 슬라이스 str 이고 대개는 빌린 형태인 &str 로 보게 됩니다. 4장에서 설명했듯, 문자열 슬라이스는 어딘가에 저장된 UTF-8 인코딩 문자열 데이터에 대한 참조입니다. 예를 들어 문자열 리터럴은 프로그램 바이너리 안에 저장되므로 문자열 슬라이스입니다.

반면 String 타입은 코어 언어에 내장된 것이 아니라 표준 라이브러리가 제공하는 타입으로, 크기를 키울 수 있고, 가변이며, 소유권을 가지는 UTF-8 인코딩 문자열 타입입니다. Rustacean이 러스트에서 “문자열”이라고 말할 때는 String 을 뜻할 수도 있고 문자열 슬라이스 &str 을 뜻할 수도 있습니다. 이 절은 주로 String 에 초점을 맞추지만, 러스트 표준 라이브러리에서는 String 과 문자열 슬라이스 둘 다 매우 자주 사용되며, 둘 다 UTF-8 인코딩이라는 점을 기억하세요.

새 문자열 만들기

String 은 추가적인 보장과 제약, 기능이 붙은 바이트 벡터를 감싼 래퍼(wrapper) 형태로 구현되어 있기 때문에, Vec<T> 에서 가능한 많은 연산이 String 에도 가능합니다. Vec<T> 와 String 에서 똑같이 동작하는 함수의 한 예가 인스턴스를 만드는 new 함수입니다. 목록 8-11을 보세요.

fn main() {
    let mut s = String::new();
}

이 한 줄은 s 라는 새 빈 문자열을 만듭니다. 그다음 우리는 이 안에 데이터를 넣을 수 있습니다. 흔히는 문자열을 만들 때 이미 초기 데이터가 있는 경우가 많습니다. 그럴 때는 문자열 리터럴처럼 Display 트레이트를 구현하는 모든 타입에서 사용할 수 있는 to_string 메서드를 사용합니다. 목록 8-12가 두 가지 예를 보여 줍니다.

fn main() {
    let data = "initial contents";

    let s = data.to_string();

    // The method also works on a literal directly:
    let s = "initial contents".to_string();
}

이 코드는 initial contents 를 담은 문자열을 만듭니다.

문자열 리터럴로부터 String 을 만들 때는 String::from 함수도 사용할 수 있습니다. 목록 8-13의 코드는 to_string 을 쓴 목록 8-12와 같은 의미입니다.

fn main() {
    let s = String::from("initial contents");
}

문자열은 정말 많은 곳에서 쓰이기 때문에, 러스트는 문자열과 함께 사용할 수 있는 다양한 범용 API를 제공합니다. 그래서 여러 선택지가 존재하며, 어떤 것은 겉보기에는 중복되어 보일 수도 있습니다. 하지만 모두 나름의 쓰임새가 있습니다! 여기서는 String::from 과 to_string 이 같은 일을 하므로, 무엇을 선택할지는 스타일과 가독성의 문제입니다.

문자열은 UTF-8 로 인코딩된다는 점을 기억하세요. 따라서 올바르게 인코딩된 어떤 데이터든 문자열 안에 넣을 수 있습니다. 목록 8-14처럼 말입니다.

fn main() {
    let hello = String::from("السلام عليكم");
    let hello = String::from("Dobrý den");
    let hello = String::from("Hello");
    let hello = String::from("שלום");
    let hello = String::from("नमस्ते");
    let hello = String::from("こんにちは");
    let hello = String::from("안녕하세요");
    let hello = String::from("你好");
    let hello = String::from("Olá");
    let hello = String::from("Здравствуйте");
    let hello = String::from("Hola");
}

이들 모두 유효한 String 값입니다.

문자열 갱신하기

String 은 Vec<T> 와 마찬가지로 더 많은 데이터를 밀어 넣으면 길이가 늘어나고, 내용도 바뀔 수 있습니다. 또한 + 연산자나 format! 매크로를 사용해 여러 String 값을 편하게 이어 붙일 수도 있습니다.

push_str 와 push 로 덧붙이기

목록 8-15처럼 push_str 메서드를 사용해 문자열 슬라이스를 덧붙이면 String 을 키울 수 있습니다.

fn main() {
    let mut s = String::from("foo");
    s.push_str("bar");
}

이 두 줄 뒤에 s 는 foobar 를 담게 됩니다. push_str 메서드가 문자열 슬라이스를 받는 이유는, 매개변수의 소유권을 꼭 가져오고 싶지는 않기 때문입니다. 예를 들어 목록 8-16의 코드에서는 s1 에 s2 의 내용을 붙인 뒤에도 s2 를 계속 사용하고 싶습니다.

fn main() {
    let mut s1 = String::from("foo");
    let s2 = "bar";
    s1.push_str(s2);
    println!("s2 is {s2}");
}

만약 push_str 이 s2 의 소유권을 가져갔다면 마지막 줄에서 s2 를 출력할 수 없었을 것입니다. 하지만 이 코드는 우리가 기대한 대로 잘 동작합니다!

push 메서드는 문자 하나를 매개변수로 받아 String 에 추가합니다. 목록 8-17은 push 로 String 에 문자 l 을 추가하는 예입니다.

fn main() {
    let mut s = String::from("lo");
    s.push('l');
}

그 결과 s 는 lol 을 담게 됩니다.

+ 또는 format! 으로 이어 붙이기

대부분의 경우 두 개 이상의 기존 문자열을 합치고 싶어질 것입니다. 그 방법 중 하나는 목록 8-18처럼 + 연산자를 사용하는 것입니다.

fn main() {
    let s1 = String::from("Hello, ");
    let s2 = String::from("world!");
    let s3 = s1 + &s2; // note s1 has been moved here and can no longer be used
}

문자열 s3 는 Hello, world! 를 담게 됩니다. 덧셈 뒤에 s1 이 더 이상 유효하지 않은 이유와, s2 에는 참조를 사용한 이유는 + 연산자가 내부적으로 호출하는 메서드 시그니처를 보면 알 수 있습니다. + 연산자는 add 메서드를 사용하며, 시그니처는 대략 다음과 같습니다.

fn add(self, s: &str) -> String {

표준 라이브러리 안에서는 add 가 제네릭과 연관 타입을 사용해 정의되어 있습니다. 여기서는 String 값으로 이 메서드를 호출할 때 실제로 대입되는 구체 타입만 적어 둔 것입니다. 제네릭은 10장에서 다룹니다. 이 시그니처에는 + 연산자의 미묘한 부분을 이해하는 데 필요한 단서가 담겨 있습니다.

첫째, s2 앞에 & 가 있습니다. 즉 두 번째 문자열은 참조 형태로 첫 번째 문자열에 더해집니다. 이는 add 함수의 s 매개변수 때문입니다. String 에는 문자열 슬라이스를 더할 수는 있지만, 두 개의 String 값 자체를 그대로 더할 수는 없습니다. 그런데 잠깐, &s2 의 타입은 &String 이지 &str 이 아닙니다. 그런데도 목록 8-18이 컴파일되는 이유는 무엇일까요?

이는 컴파일러가 &String 인수를 &str 로 강제(coerce)할 수 있기 때문입니다. add 메서드를 호출할 때 러스트는 역참조 강제를 사용해서 &s2 를 &s2[..] 로 바꿉니다. 역참조 강제는 15장에서 더 자세히 다룹니다. add 가 s 매개변수의 소유권을 가져가지 않기 때문에, 이 연산 이후에도 s2 는 여전히 유효한 String 으로 남습니다.

둘째, 시그니처를 보면 add 가 self 의 소유권을 가져간다는 점도 알 수 있습니다. self 앞에 & 가 없기 때문입니다. 이는 목록 8-18에서 s1 이 add 호출로 이동되며, 연산 뒤에는 더 이상 유효하지 않음을 뜻합니다. 즉 let s3 = s1 + &s2; 는 두 문자열을 모두 복사해 새 문자열을 만드는 것처럼 보일 수 있지만, 실제로는 s1 의 소유권을 가져가고, s2 내용의 복사본을 그 뒤에 붙인 다음, 결과의 소유권을 반환합니다. 즉 많이 복사하는 것처럼 보이지만, 실제 구현은 그보다 더 효율적입니다.

여러 문자열을 이어 붙여야 한다면 + 연산자의 동작은 꽤 다루기 불편해집니다.

fn main() {
    let s1 = String::from("tic");
    let s2 = String::from("tac");
    let s3 = String::from("toe");

    let s = s1 + "-" + &s2 + "-" + &s3;
}

이 시점에서 s 는 tic-tac-toe 가 됩니다. 하지만 + 와 따옴표가 많이 섞여 있어서 무슨 일이 일어나는지 한눈에 보기 어렵습니다. 문자열을 더 복잡하게 합칠 때는 대신 format! 매크로를 사용할 수 있습니다.

fn main() {
    let s1 = String::from("tic");
    let s2 = String::from("tac");
    let s3 = String::from("toe");

    let s = format!("{s1}-{s2}-{s3}");
}

이 코드 역시 s 를 tic-tac-toe 로 만듭니다. format! 매크로는 println! 과 비슷하게 동작하지만, 화면에 출력하는 대신 결과 내용을 담은 String 을 반환합니다. format! 버전의 코드는 훨씬 읽기 쉽고, 매크로가 생성한 코드는 참조를 사용하므로 호출 과정에서 어떤 인수의 소유권도 가져가지 않습니다.

문자열 인덱싱

많은 다른 프로그래밍 언어에서는 문자열 안의 개별 문자를 인덱스로 접근하는 것이 흔하고 유효한 연산입니다. 하지만 러스트에서 인덱싱 문법으로 String 의 일부에 접근하려 하면 오류를 받습니다. 목록 8-19의 잘못된 코드를 보세요.

fn main() {
    let s1 = String::from("hi");
    let h = s1[0];
}

이 코드는 다음과 같은 오류를 냅니다.

$ cargo run
   Compiling collections v0.1.0 (file:///projects/collections)
error[E0277]: the type `str` cannot be indexed by `{integer}`
 --> src/main.rs:3:16
  |
3 |     let h = s1[0];
  |                ^ string indices are ranges of `usize`
  |
  = help: the trait `SliceIndex<str>` is not implemented for `{integer}`
  = note: you can use `.chars().nth()` or `.bytes().nth()`
          for more information, see chapter 8 in The Book: <https://doc.rust-lang.org/book/ch08-02-strings.html#indexing-into-strings>
  = help: the following other types implement trait `SliceIndex<T>`:
            `usize` implements `SliceIndex<ByteStr>`
            `usize` implements `SliceIndex<[T]>`
  = note: required for `String` to implement `Index<{integer}>`

For more information about this error, try `rustc --explain E0277`.
error: could not compile `collections` (bin "collections") due to 1 previous error

이 오류는 핵심을 잘 보여 줍니다. 러스트 문자열은 인덱싱을 지원하지 않습니다. 왜 그럴까요? 이를 이해하려면 러스트가 문자열을 메모리에 어떻게 저장하는지부터 이야기해야 합니다.

내부 표현

String 은 사실 Vec<u8> 를 감싼 래퍼입니다. 목록 8-14에서 봤던 UTF-8 예제 문자열을 다시 봅시다. 먼저 이 문자열입니다.

fn main() {
    let hello = String::from("السلام عليكم");
    let hello = String::from("Dobrý den");
    let hello = String::from("Hello");
    let hello = String::from("שלום");
    let hello = String::from("नमस्ते");
    let hello = String::from("こんにちは");
    let hello = String::from("안녕하세요");
    let hello = String::from("你好");
    let hello = String::from("Olá");
    let hello = String::from("Здравствуйте");
    let hello = String::from("Hola");
}

이 경우 len 은 4 가 됩니다. 즉 문자열 "Hola" 를 저장하는 벡터는 4바이트 길이라는 뜻입니다. 이 문자열의 각 글자는 UTF-8 로 인코딩될 때 1바이트씩을 차지합니다. 하지만 다음 줄은 조금 놀랍게 느껴질 수 있습니다(이 문자열은 숫자 3이 아니라, 키릴 문자 대문자 제(Ze)로 시작합니다).

fn main() {
    let hello = String::from("السلام عليكم");
    let hello = String::from("Dobrý den");
    let hello = String::from("Hello");
    let hello = String::from("שלום");
    let hello = String::from("नमस्ते");
    let hello = String::from("こんにちは");
    let hello = String::from("안녕하세요");
    let hello = String::from("你好");
    let hello = String::from("Olá");
    let hello = String::from("Здравствуйте");
    let hello = String::from("Hola");
}

이 문자열 길이를 묻는다면 아마 12라고 대답하고 싶을지도 모릅니다. 실제로는 러스트의 답은 24입니다. “Здравствуйте” 를 UTF-8 로 인코딩하는 데 필요한 바이트 수가 24이기 때문입니다. 이 문자열의 각 유니코드 스칼라 값은 2바이트를 차지합니다. 따라서 문자열 바이트 인덱스는 항상 유효한 유니코드 스칼라 값 하나와 대응되지 않습니다. 이를 보여 주기 위해 다음 잘못된 러스트 코드를 생각해 봅시다.

let hello = "Здравствуйте";
let answer = &hello[0];

여러분은 이미 answer 가 첫 글자 З 가 되지 않을 것이라는 점을 알고 있습니다. UTF-8 로 인코딩하면 З 의 첫 번째 바이트는 208, 두 번째는 151 이기 때문에, answer 는 겉보기에 208 이어야 할 것처럼 보일 수 있습니다. 하지만 208 은 그 자체로 유효한 문자가 아닙니다. 어떤 사용자가 이 문자열의 첫 글자를 요구했을 때 208 을 돌려주는 것은 거의 분명히 원하는 동작이 아닙니다. 그런데 러스트가 바이트 인덱스 0에서 실제로 볼 수 있는 것은 그 208 하나뿐입니다. 문자열에 라틴 문자만 들어 있더라도 사람은 보통 바이트 값을 원하지 않습니다. 만약 &"hi"[0] 가 유효한 코드라서 바이트 값을 반환한다면, 그것은 h 가 아니라 104 를 반환했을 것입니다.

그래서 러스트는 예기치 않은 값을 반환해 나중에야 드러날 버그를 만드는 대신, 이 코드를 아예 컴파일하지 않음으로써 개발 초기 단계에서 오해를 예방합니다.

바이트, 스칼라 값, 그리고 그래핌 클러스터

UTF-8 과 관련해 또 한 가지 중요한 점은, 문자열을 러스트의 관점에서 바라보는 방식이 실제로는 세 가지나 있다는 것입니다. 바이트, 스칼라 값, 그래핌 클러스터입니다 (그래핌 클러스터는 사람이 보통 글자 라고 부르는 것과 가장 가깝습니다).

데바나가리 문자로 쓰인 힌디어 단어 “नमस्ते” 를 보면, 이것은 다음과 같은 u8 값 벡터로 저장됩니다.

[224, 164, 168, 224, 164, 174, 224, 164, 184, 224, 165, 141, 224, 164, 164,
224, 165, 135]

즉 18바이트이고, 컴퓨터는 최종적으로 이런 식으로 데이터를 저장합니다. 이것을 유니코드 스칼라 값, 곧 러스트의 char 타입 관점에서 보면 다음과 같이 보입니다.

['न', 'म', 'स', '्', 'त', 'े']

여기에는 char 값이 여섯 개 있지만, 네 번째와 여섯 번째는 글자가 아닙니다. 그 자체만으로는 의미가 없는 발음 부호입니다. 마지막으로 그래핌 클러스터로 보면, 사람이 힌디어 단어를 네 글자라고 보는 것과 비슷한 결과를 얻습니다.

["न", "म", "स्", "ते"]

러스트는 컴퓨터가 저장한 원시 문자열 데이터를 이렇게 여러 방식으로 해석할 수 있도록 해 줍니다. 그래서 데이터가 어떤 인간 언어인지와 상관없이, 각 프로그램이 자신에게 필요한 해석 방식을 선택할 수 있습니다.

러스트가 String 에 대해 문자 인덱싱을 허용하지 않는 마지막 이유는, 인덱싱 연산은 항상 상수 시간(O(1))에 끝날 것이라고 기대되기 때문입니다. 하지만 String 에 대해서는 그 성능을 보장할 수 없습니다. 러스트는 해당 인덱스까지 유효한 문자 수가 몇 개인지 판단하기 위해 문자열 시작부터 끝까지 걸어가야 할 수도 있기 때문입니다.

문자열 슬라이싱

문자열에 인덱싱하는 것은 반환 타입이 무엇이어야 하는지가 불명확하기 때문에 대체로 좋은 생각이 아닙니다. 바이트 값이어야 할까요, 문자여야 할까요, 그래핌 클러스터여야 할까요, 아니면 문자열 슬라이스여야 할까요? 그래서 정말 인덱스를 사용해 문자열 슬라이스를 만들고 싶다면, 러스트는 여러분에게 더 구체적으로 지정하라고 요구합니다.

숫자 하나로 [] 인덱싱을 하는 대신, 범위를 넣어 특정 바이트를 담는 문자열 슬라이스를 만들 수 있습니다.

#![allow(unused)]
fn main() {
let hello = "Здравствуйте";

let s = &hello[0..4];
}

여기서 s 는 문자열의 앞 4바이트를 담은 &str 이 됩니다. 앞에서 각 글자가 2바이트씩이라고 했으므로, s 는 Зд 가 됩니다.

만약 &hello[0..1] 처럼 글자의 바이트 일부만 잘라내려 한다면, 벡터에서 잘못된 인덱스를 접근했을 때처럼 러스트는 런타임에 패닉을 일으킵니다.

$ cargo run
   Compiling collections v0.1.0 (file:///projects/collections)
    Finished `dev` profile [unoptimized + debuginfo] target(s) in 0.43s
     Running `target/debug/collections`

thread 'main' panicked at src/main.rs:4:19:
byte index 1 is not a char boundary; it is inside 'З' (bytes 0..2) of `Здравствуйте`
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

따라서 범위를 사용해 문자열 슬라이스를 만들 때는 프로그램이 크래시할 수 있으므로 주의해야 합니다.

문자열 순회하기

문자열의 일부를 다루는 가장 좋은 방법은, 원하는 것이 문자인지 바이트인지 명시하는 것입니다. 개별 유니코드 스칼라 값을 원하면 chars 메서드를 사용합니다. "Зд" 에 chars 를 호출하면 char 타입 값 두 개가 분리되어 반환되고, 각 요소를 반복하며 접근할 수 있습니다.

#![allow(unused)]
fn main() {
for c in "Зд".chars() {
    println!("{c}");
}
}

이 코드는 다음을 출력합니다.

З
д

반대로 여러분의 도메인에서는 raw byte가 더 적절할 수도 있습니다. 그럴 때는 bytes 메서드를 사용할 수 있습니다.

#![allow(unused)]
fn main() {
for b in "Зд".bytes() {
    println!("{b}");
}
}

이 코드는 이 문자열을 구성하는 4개의 바이트를 출력합니다.

208
151
208
180

다만 유효한 유니코드 스칼라 값 하나가 1바이트보다 큰 경우도 많다는 점을 반드시 기억하세요.

데바나가리 문자 예처럼 그래핌 클러스터를 문자열에서 꺼내는 일은 복잡하기 때문에, 표준 라이브러리는 이 기능을 제공하지 않습니다. 만약 꼭 필요하다면 crates.io에 이 기능을 제공하는 크레이트들이 있습니다.

문자열의 복잡성 다루기

정리하면, 문자열은 복잡합니다. 프로그래밍 언어마다 이 복잡성을 프로그래머에게 어떻게 보여 줄지에 대해 서로 다른 선택을 합니다. 러스트는 String 데이터를 정확하게 다루는 것을 모든 프로그램의 기본 동작으로 삼기로 선택했습니다. 그래서 프로그래머는 UTF-8 데이터를 처리할 때 처음부터 조금 더 많은 생각을 해야 합니다. 이 선택은 다른 언어보다 문자열의 복잡성을 더 많이 드러내지만, 나중에 개발 과정에서 비 ASCII 문자와 관련된 오류를 처리하느라 고생할 일을 줄여 줍니다.

좋은 소식은 표준 라이브러리가 String 과 &str 위에 다양한 기능을 제공하여, 이런 복잡한 상황을 올바르게 처리하는 데 도움을 준다는 점입니다. 문자열 검색을 위한 contains, 문자열 일부를 다른 문자열로 바꾸는 replace 같은 유용한 메서드가 있으니 문서를 꼭 확인해 보세요.

이제 조금 덜 복잡한 주제로 넘어가 봅시다. 해시 맵입니다!

해시 맵으로 키와 값을 연결하기

해시 맵으로 키와 값을 연결하기

우리가 자주 쓰는 컬렉션의 마지막은 해시 맵입니다. HashMap<K, V> 타입은 해싱 함수(hashing function) 를 사용해, 타입 K 의 키를 타입 V 의 값에 대응시켜 저장합니다. 이 해싱 함수는 키와 값을 메모리 안에 어떻게 배치할지 결정합니다. 많은 프로그래밍 언어가 이런 자료구조를 지원하지만, hash, map, object, hash table, dictionary, associative array 등 서로 다른 이름을 쓰기도 합니다.

해시 맵은 벡터처럼 인덱스로 데이터를 찾는 대신, 어떤 타입이든 될 수 있는 키를 통해 데이터를 찾고 싶을 때 유용합니다. 예를 들어 게임에서 각 팀의 점수를 추적할 때, 해시 맵의 키를 팀 이름으로, 값은 그 팀의 점수로 둘 수 있습니다. 특정 팀 이름을 주면 점수를 얻을 수 있습니다.

이 절에서는 해시 맵의 기본 API를 살펴봅니다. 하지만 표준 라이브러리의 HashMap<K, V> 에는 더 많은 유용한 기능이 숨겨져 있으므로, 늘 그렇듯 더 자세한 내용은 표준 라이브러리 문서를 확인하세요.

새 해시 맵 만들기

빈 해시 맵을 만드는 방법 중 하나는 new 를 사용하고, insert 로 요소를 추가하는 것입니다. 목록 8-20에서는 Blue 와 Yellow 라는 두 팀의 점수를 저장합니다. Blue 팀은 10점으로 시작하고, Yellow 팀은 50점으로 시작합니다.

fn main() {
    use std::collections::HashMap;

    let mut scores = HashMap::new();

    scores.insert(String::from("Blue"), 10);
    scores.insert(String::from("Yellow"), 50);
}

먼저 표준 라이브러리의 컬렉션 부분에서 HashMap 을 use 해야 한다는 점에 주목하세요. 세 가지 자주 쓰는 컬렉션 중에서 해시 맵은 가장 덜 흔하게 사용되기 때문에, prelude로 자동 스코프에 들어오지 않습니다. 또한 해시 맵은 표준 라이브러리에서 다른 두 컬렉션보다 직접적인 지원이 적어서, 예를 들어 벡터처럼 전용 매크로가 제공되지는 않습니다.

벡터와 마찬가지로 해시 맵도 데이터를 힙에 저장합니다. 이 HashMap 은 키 타입이 String, 값 타입이 i32 입니다. 벡터처럼 해시 맵도 동질적입니다. 즉 모든 키는 같은 타입이어야 하고, 모든 값도 같은 타입이어야 합니다.

해시 맵 값에 접근하기

해시 맵에서 값을 꺼내려면 목록 8-21처럼 get 메서드에 키를 넘기면 됩니다.

fn main() {
    use std::collections::HashMap;

    let mut scores = HashMap::new();

    scores.insert(String::from("Blue"), 10);
    scores.insert(String::from("Yellow"), 50);

    let team_name = String::from("Blue");
    let score = scores.get(&team_name).copied().unwrap_or(0);
}

여기서 score 는 Blue 팀에 연관된 값을 가지며, 결과는 10 입니다. get 메서드는 Option<&V> 를 반환합니다. 만약 해시 맵 안에 그 키에 대응하는 값이 없다면 get 은 None 을 반환합니다. 이 프로그램은 copied 를 호출해 Option<&i32> 대신 Option<i32> 를 얻고, 이어서 unwrap_or 로 키에 해당하는 항목이 없을 경우 score 를 0으로 설정합니다.

해시 맵의 각 키-값 쌍도 벡터와 비슷하게 for 루프로 순회할 수 있습니다.

fn main() {
    use std::collections::HashMap;

    let mut scores = HashMap::new();

    scores.insert(String::from("Blue"), 10);
    scores.insert(String::from("Yellow"), 50);

    for (key, value) in &scores {
        println!("{key}: {value}");
    }
}

이 코드는 각 쌍을 임의의 순서로 출력합니다.

Yellow: 50
Blue: 10

해시 맵에서 소유권 관리하기

i32 처럼 Copy 트레이트를 구현하는 타입에 대해서는 값이 해시 맵 안으로 복사됩니다. 반면 String 같은 소유 타입 값은 이동되며, 해시 맵이 그 값의 소유자가 됩니다. 목록 8-22가 이를 보여 줍니다.

fn main() {
    use std::collections::HashMap;

    let field_name = String::from("Favorite color");
    let field_value = String::from("Blue");

    let mut map = HashMap::new();
    map.insert(field_name, field_value);
    // field_name and field_value are invalid at this point, try using them and
    // see what compiler error you get!
}

field_name 과 field_value 변수는 insert 호출로 해시 맵 안으로 이동되었기 때문에, 그 뒤에는 더 이상 사용할 수 없습니다.

만약 해시 맵에 값 자체가 아니라 참조를 넣는다면, 값은 해시 맵 안으로 이동되지 않습니다. 다만 그 참조가 가리키는 값은 적어도 해시 맵이 유효한 동안 계속 유효해야 합니다. 이 문제는 10장의 [“라이프타임으로 참조의 유효성 검증하기”] validating-references-with-lifetimes 절에서 더 이야기합니다.

해시 맵 갱신하기

키-값 쌍의 수는 늘어나거나 줄어들 수 있지만, 하나의 고유한 키에는 어떤 순간에도 오직 하나의 값만 연결될 수 있습니다(그 반대는 아닙니다. 예를 들어 Blue 팀과 Yellow 팀이 둘 다 값 10 을 가질 수는 있습니다).

해시 맵 안의 데이터를 바꾸고 싶을 때는, 그 키에 이미 값이 있을 때 어떻게 처리할지를 먼저 정해야 합니다. 새 값으로 기존 값을 덮어쓸 수도 있고, 기존 값을 유지하고 새 값을 무시할 수도 있으며, 이전 값과 새 값을 결합할 수도 있습니다. 각각을 어떻게 하는지 살펴봅시다.

값을 덮어쓰기

해시 맵에 키와 값을 넣은 뒤, 같은 키에 다른 값을 다시 넣으면 그 키에 연결된 값은 교체됩니다. 목록 8-23의 코드는 insert 를 두 번 호출하지만, 해시 맵에는 키-값 쌍 하나만 남습니다. Blue 팀 키에 대한 값을 두 번 넣기 때문입니다.

fn main() {
    use std::collections::HashMap;

    let mut scores = HashMap::new();

    scores.insert(String::from("Blue"), 10);
    scores.insert(String::from("Blue"), 25);

    println!("{scores:?}");
}

이 코드는 {"Blue": 25} 를 출력합니다. 원래 값 10 은 덮어써졌습니다.

키가 없을 때만 값 추가하기

특정 키에 값이 이미 있는지 먼저 검사한 뒤, 존재할 때와 없을 때 다르게 처리하는 일도 흔합니다. 예를 들어 키가 이미 있으면 기존 값을 그대로 유지하고, 키가 없으면 그때만 새 키와 값을 추가하고 싶을 수 있습니다.

이를 위해 해시 맵은 entry 라는 특수 API를 제공합니다. entry 는 확인하고 싶은 키를 인수로 받습니다. 그리고 Entry 라는 enum 값을 반환하는데, 이것은 그 위치에 값이 있을 수도 있고 없을 수도 있음을 나타냅니다. 예를 들어 Yellow 팀 키에 값이 있는지 확인하고, 없다면 값 50 을 넣고 싶다고 해 봅시다. Blue 팀도 마찬가지입니다. entry API를 사용하면 코드는 목록 8-24처럼 됩니다.

fn main() {
    use std::collections::HashMap;

    let mut scores = HashMap::new();
    scores.insert(String::from("Blue"), 10);

    scores.entry(String::from("Yellow")).or_insert(50);
    scores.entry(String::from("Blue")).or_insert(50);

    println!("{scores:?}");
}

Entry 에 정의된 or_insert 메서드는, 해당 키가 이미 있다면 그 값에 대한 가변 참조를 반환하고, 없다면 인수로 받은 값을 새 값으로 삽입한 뒤 그 새 값에 대한 가변 참조를 반환하도록 정의되어 있습니다. 이 방식은 우리가 직접 조건 로직을 쓰는 것보다 훨씬 깔끔하며, 대여 검사기와도 더 잘 맞습니다.

목록 8-24의 코드를 실행하면 {"Yellow": 50, "Blue": 10} 이 출력됩니다. 첫 번째 entry 호출은 Yellow 팀이 아직 값을 갖고 있지 않기 때문에 키와 값 50 을 넣습니다. 두 번째 호출은 Blue 팀이 이미 값 10 을 가지고 있으므로 해시 맵을 바꾸지 않습니다.

이전 값을 바탕으로 값 갱신하기

해시 맵의 또 다른 흔한 사용 패턴은 어떤 키의 값을 조회한 뒤, 그 이전 값을 바탕으로 다시 갱신하는 것입니다. 예를 들어 목록 8-25의 코드는 어떤 텍스트 안에서 각 단어가 몇 번 나오는지 세고 있습니다. 단어를 키로 하고, 등장 횟수를 값으로 갖는 해시 맵을 사용합니다. 어떤 단어를 처음 보면 먼저 값 0 을 넣습니다.

fn main() {
    use std::collections::HashMap;

    let text = "hello world wonderful world";

    let mut map = HashMap::new();

    for word in text.split_whitespace() {
        let count = map.entry(word).or_insert(0);
        *count += 1;
    }

    println!("{map:?}");
}

이 코드는 {"world": 2, "hello": 1, "wonderful": 1} 을 출력합니다. 키-값 쌍이 다른 순서로 출력될 수도 있는데, “해시 맵 값에 접근하기” 절에서 설명했듯 해시 맵 순회 순서는 임의적이기 때문입니다.

split_whitespace 메서드는 text 안의 값을 공백 기준으로 나눈 하위 슬라이스에 대한 반복자를 반환합니다. or_insert 메서드는 지정한 키에 대한 값의 가변 참조(&mut V) 를 반환합니다. 여기서는 그 가변 참조를 count 변수에 저장합니다. 따라서 그 값에 대입하려면 먼저 별표(*)로 count 를 역참조해야 합니다. 이 가변 참조는 for 루프 한 반복이 끝나면 스코프를 벗어나므로, 이런 변경은 모두 대여 규칙상 안전하고 허용됩니다.

해싱 함수

기본적으로 HashMap 은 SipHash 라는 해싱 함수를 사용합니다. 이 함수는 해시 테이블을 이용한 서비스 거부(DoS) 공격에 대한 저항성을 제공합니다¹. 이것이 사용 가능한 가장 빠른 해싱 알고리즘은 아니지만, 성능이 조금 떨어지는 대신 보안을 얻는다는 점에서 대체로 합리적인 선택입니다. 만약 코드를 프로파일링해 보았더니 기본 해시 함수가 너무 느리다면, 다른 hasher를 지정해 다른 함수로 바꿀 수 있습니다. Hasher 는 BuildHasher 트레이트를 구현한 타입입니다. 트레이트와 그 구현 방법은 10장에서 다룹니다. 직접 처음부터 hasher를 구현할 필요는 없고, crates.io에는 다양한 흔한 해싱 알고리즘을 구현한 hasher를 제공하는 라이브러리들이 공유되어 있습니다.

정리

벡터, 문자열, 해시 맵은 데이터를 저장하고, 접근하고, 수정해야 할 때 프로그램에서 필요한 기능의 큰 부분을 담당합니다. 이제 여러분은 다음과 같은 문제를 충분히 풀 수 있어야 합니다.

1. 정수 리스트가 주어졌을 때, 벡터를 사용해 리스트의 median(정렬했을 때 가운데 값)과 mode(가장 자주 나타나는 값. 해시 맵이 도움이 됩니다)를 구해 보세요.
2. 문자열을 Pig Latin 으로 변환해 보세요. 각 단어의 첫 자음은 단어 끝으로 옮기고 ay 를 붙입니다. 그래서 first 는 irst-fay 가 됩니다. 모음으로 시작하는 단어에는 대신 끝에 hay 를 붙입니다(apple 은 apple-hay 가 됩니다). UTF-8 인코딩의 세부도 꼭 염두에 두세요!
3. 해시 맵과 벡터를 사용해, 회사의 부서에 직원 이름을 추가할 수 있는 텍스트 인터페이스를 만들어 보세요. 예를 들어 “Add Sally to Engineering” 또는 “Add Amir to Sales” 같은 식입니다. 그런 다음 사용자가 특정 부서의 모든 사람 목록이나, 회사 전체 사람들을 부서별로 알파벳 순서대로 정렬해 조회할 수 있게 해 보세요.

표준 라이브러리 API 문서에는 벡터, 문자열, 해시 맵이 가진 메서드들이 잘 정리되어 있고, 이런 연습문제를 풀 때 큰 도움이 될 것입니다!

이제 점점 더 복잡한 프로그램으로 들어가고 있고, 연산이 실패할 수도 있는 상황도 등장하기 시작합니다. 그래서 지금이 바로 에러 처리를 이야기하기 좋은 시점입니다. 다음 장에서 그 내용을 다루겠습니다!

1. https://en.wikipedia.org/wiki/SipHash ↩

에러 처리

에러는 소프트웨어에서 피할 수 없는 현실이므로, 러스트는 무언가 잘못되었을 때를 다루기 위한 여러 기능을 제공합니다. 많은 경우 러스트는 코드가 컴파일되기 전에, 에러 가능성을 인정하고 어떤 조치를 취하라고 요구합니다. 이런 요구는 여러분의 프로그램이 실제 운영 환경에 배포되기 전에 에러를 발견하고 적절히 처리하도록 만들어 더 견고하게 해 줍니다.

러스트는 에러를 크게 두 가지 범주로 나눕니다. 복구 가능한 에러와 복구 불가능한 에러입니다. 복구 가능한 에러(recoverable error) 는 예를 들어 파일을 찾을 수 없다 같은 경우로, 보통은 사용자에게 문제를 알리고 작업을 다시 시도하고 싶을 가능성이 큽니다. 반면 복구 불가능한 에러(unrecoverable error) 는 배열 끝을 넘어선 위치에 접근하려는 경우처럼 항상 버그의 증상이며, 따라서 프로그램을 즉시 멈추고 싶습니다.

대부분의 언어는 이 두 종류를 구분하지 않고, 예외 같은 메커니즘으로 같은 방식으로 처리합니다. 러스트에는 예외가 없습니다. 대신 복구 가능한 에러를 위한 Result<T, E> 타입과, 복구 불가능한 에러를 만났을 때 실행을 멈추는 panic! 매크로가 있습니다. 이 장에서는 먼저 panic! 호출을 다루고, 이어서 Result<T, E> 값을 반환하는 방법을 설명합니다. 또한 어떤 상황에서 에러 복구를 시도할지, 아니면 실행을 멈출지를 결정할 때 고려할 점도 함께 살펴봅니다.

panic!으로 복구 불가능한 에러 다루기

panic! 으로 복구 불가능한 에러 다루기

가끔은 코드 안에서 좋지 않은 일이 벌어지고, 그것에 대해 할 수 있는 일이 전혀 없을 때가 있습니다. 이런 경우 러스트는 panic! 매크로를 제공합니다. 실제로 패닉을 일으키는 방법은 두 가지입니다. 코드가 패닉을 일으키는 동작을 하게 만드는 것(예를 들어 배열 끝을 넘어서 접근하기), 혹은 panic! 매크로를 직접 호출하는 것입니다. 두 경우 모두 프로그램에서 패닉이 발생합니다. 기본적으로 이런 패닉은 실패 메시지를 출력하고, 스택을 언와인드하며 정리한 뒤 종료합니다. 또한 환경 변수를 통해 패닉이 발생했을 때 호출 스택까지 함께 표시하도록 할 수 있어, 패닉 원인을 추적하기가 더 쉬워집니다.

[profile.release]
panic = 'abort'

이제 간단한 프로그램에서 panic! 을 직접 호출해 봅시다.

fn main() {
    panic!("crash and burn");
}

프로그램을 실행하면 다음과 비슷한 출력이 보일 것입니다.

$ cargo run
   Compiling panic v0.1.0 (file:///projects/panic)
    Finished `dev` profile [unoptimized + debuginfo] target(s) in 0.25s
     Running `target/debug/panic`

thread 'main' panicked at src/main.rs:2:5:
crash and burn
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

panic! 호출은 마지막 두 줄에 들어 있는 에러 메시지를 발생시킵니다. 첫 번째 줄은 우리가 지정한 패닉 메시지와 패닉이 발생한 소스 코드 위치를 보여 줍니다. src/main.rs:2:5 는 src/main.rs 파일의 두 번째 줄, 다섯 번째 문자라는 뜻입니다.

이 경우 표시된 줄은 우리 코드의 일부이며, 그 줄로 가 보면 실제 panic! 호출이 있다는 것을 볼 수 있습니다. 하지만 다른 경우에는 panic! 호출이 우리 코드가 직접 호출한 다른 코드 안에 있을 수도 있습니다. 그러면 오류 메시지가 가리키는 파일명과 줄 번호는, 우리 코드가 아니라 panic! 매크로가 실제로 호출된 그쪽 코드 위치가 될 것입니다.

panic! 호출이 어디서 왔는지에 대한 함수 백트레이스를 사용하면, 문제를 일으키는 우리 코드 부분을 알아낼 수 있습니다. panic! 백트레이스를 어떻게 읽는지 이해하기 위해, 이번에는 우리가 직접 매크로를 호출하는 대신 우리 코드의 버그로 인해 라이브러리 안에서 panic! 이 호출되는 예를 보겠습니다. 목록 9-1은 벡터에서 유효한 범위를 벗어난 인덱스에 접근하려는 코드입니다.

fn main() {
    let v = vec![1, 2, 3];

    v[99];
}

여기서는 벡터의 100번째 요소에 접근하려고 합니다(인덱스는 0부터 시작하므로 실제 인덱스 값은 99입니다). 하지만 이 벡터에는 요소가 세 개뿐입니다. 이런 상황에서 러스트는 패닉을 일으킵니다. [] 는 어떤 요소를 반환해야 하는 문법인데, 유효하지 않은 인덱스를 넘기면 러스트가 돌려줄 수 있는 올바른 요소가 존재하지 않기 때문입니다.

C에서는 자료구조 끝을 넘어 읽는 것이 정의되지 않은 동작입니다. 때에 따라서는 그 자료구조에 속하지 않는 메모리이더라도, 마치 그 요소 자리에 해당하는 위치의 값을 그냥 읽어 올 수도 있습니다. 이를 버퍼 오버리드(buffer overread) 라고 하며, 공격자가 인덱스를 조작해 읽어서는 안 되는 데이터를 읽을 수 있게 되면 보안 취약점으로 이어질 수 있습니다.

러스트는 이런 취약점으로부터 프로그램을 보호하기 위해, 존재하지 않는 인덱스의 요소를 읽으려 하면 실행을 중단하고 더 이상 진행하지 않습니다. 실제로 실행해 봅시다.

$ cargo run
   Compiling panic v0.1.0 (file:///projects/panic)
    Finished `dev` profile [unoptimized + debuginfo] target(s) in 0.27s
     Running `target/debug/panic`

thread 'main' panicked at src/main.rs:4:6:
index out of bounds: the len is 3 but the index is 99
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

이 에러는 우리가 벡터 v 의 인덱스 99에 접근하려는 main.rs 4번째 줄을 가리킵니다.

note: 줄은 에러를 일으킨 정확한 경로를 백트레이스로 보고 싶다면 RUST_BACKTRACE 환경 변수를 설정할 수 있다고 알려 줍니다. 백트레이스(backtrace) 는 이 지점에 도달하기까지 호출된 모든 함수의 목록입니다. 러스트의 백트레이스도 다른 언어와 마찬가지로 읽습니다. 맨 위에서부터 내려가다가 여러분이 작성한 파일이 나오는 지점을 찾으면 됩니다. 그 지점이 문제의 출발점입니다. 그 위의 줄들은 여러분 코드가 호출한 코드들이고, 그 아래 줄들은 여러분 코드를 호출한 코드입니다. 여기에는 핵심 러스트 코드, 표준 라이브러리 코드, 또는 사용하는 외부 크레이트 코드가 포함될 수도 있습니다. RUST_BACKTRACE 환경 변수를 0 이 아닌 값으로 설정해 백트레이스를 확인해 봅시다. 목록 9-2는 여러분이 보게 될 출력과 비슷한 예를 보여 줍니다.

$ RUST_BACKTRACE=1 cargo run
thread 'main' panicked at src/main.rs:4:6:
index out of bounds: the len is 3 but the index is 99
stack backtrace:
   0: rust_begin_unwind
             at /rustc/4d91de4e48198da2e33413efdcd9cd2cc0c46688/library/std/src/panicking.rs:692:5
   1: core::panicking::panic_fmt
             at /rustc/4d91de4e48198da2e33413efdcd9cd2cc0c46688/library/core/src/panicking.rs:75:14
   2: core::panicking::panic_bounds_check
             at /rustc/4d91de4e48198da2e33413efdcd9cd2cc0c46688/library/core/src/panicking.rs:273:5
   3: <usize as core::slice::index::SliceIndex<[T]>>::index
             at file:///home/.rustup/toolchains/1.85/lib/rustlib/src/rust/library/core/src/slice/index.rs:274:10
   4: core::slice::index::<impl core::ops::index::Index<I> for [T]>::index
             at file:///home/.rustup/toolchains/1.85/lib/rustlib/src/rust/library/core/src/slice/index.rs:16:9
   5: <alloc::vec::Vec<T,A> as core::ops::index::Index<I>>::index
             at file:///home/.rustup/toolchains/1.85/lib/rustlib/src/rust/library/alloc/src/vec/mod.rs:3361:9
   6: panic::main
             at ./src/main.rs:4:6
   7: core::ops::function::FnOnce::call_once
             at file:///home/.rustup/toolchains/1.85/lib/rustlib/src/rust/library/core/src/ops/function.rs:250:5
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.

출력이 꽤 길지요! 실제로 보게 되는 정확한 출력은 운영체제와 러스트 버전에 따라 다를 수 있습니다. 이 정도 정보가 담긴 백트레이스를 얻으려면 디버그 심벌이 켜져 있어야 합니다. 우리가 지금처럼 cargo build 나 cargo run 을 --release 없이 실행할 때는 디버그 심벌이 기본적으로 활성화됩니다.

목록 9-2 출력에서 백트레이스의 6번째 줄이 문제를 일으키는 우리 프로젝트 코드, 즉 src/main.rs 4번째 줄을 가리킵니다. 프로그램이 패닉하지 않게 하고 싶다면, 우리가 작성한 파일을 처음 언급하는 줄의 위치부터 조사를 시작하면 됩니다. 목록 9-1처럼 의도적으로 패닉을 일으키는 코드를 쓴 경우, 해결책은 벡터 인덱스 범위를 벗어난 요소를 요청하지 않는 것입니다. 앞으로 코드가 패닉을 일으킬 때는, 어떤 연산이 어떤 값과 함께 실행되어 패닉이 발생했는지, 그리고 그 대신 코드가 무엇을 해야 하는지를 판단해야 합니다.

이 장의 뒤쪽 [“panic! 을 써야 할 때와 쓰지 말아야 할 때”] to-panic-or-not-to-panic 절에서, 언제 panic! 을 사용해야 하고 언제 사용하지 말아야 하는지 다시 돌아와 이야기할 것입니다. 이제는 Result 로 에러에서 어떻게 복구하는지 살펴봅시다.

Result로 복구 가능한 에러 다루기

Result 로 복구 가능한 에러 다루기

대부분의 에러는 프로그램 전체를 멈출 정도로 심각하지는 않습니다. 함수가 실패하더라도, 그 이유를 해석하고 대응하기 쉬운 경우가 많기 때문입니다. 예를 들어 파일을 열려고 했는데 파일이 존재하지 않아 실패했다면, 프로세스를 끝내는 대신 파일을 새로 만들고 싶을 수도 있습니다.

2장의 “Result 타입으로 발생 가능한 실패 처리하기” 절에서 본 것처럼, Result enum은 Ok 와 Err 두 variant를 가진다고 정의되어 있습니다.

#![allow(unused)]
fn main() {
enum Result<T, E> {
    Ok(T),
    Err(E),
}
}

T 와 E 는 제네릭 타입 매개변수입니다. 제네릭은 10장에서 더 자세히 다룹니다. 지금은 T 가 성공했을 때 Ok variant 안에 들어가는 값의 타입을 뜻하고, E 는 실패했을 때 Err variant 안에 들어가는 에러 값의 타입을 뜻한다는 것만 알면 됩니다. Result 가 이런 제네릭 매개변수를 가지기 때문에, 우리는 성공값과 에러값이 서로 다른 여러 상황에서 Result 타입과 그 위의 함수들을 유연하게 사용할 수 있습니다.

실패할 수 있는 함수가 Result 값을 반환하는 경우를 호출해 봅시다. 목록 9-3에서는 파일을 열려고 시도합니다.

use std::fs::File;

fn main() {
    let greeting_file_result = File::open("hello.txt");
}

File::open 의 반환 타입은 Result 입니다. 여기서 제네릭 매개변수 T 는 성공값 타입인 std::fs::File 로 채워지고, 에러값에 쓰이는 E 는 std::io::Error 로 채워집니다.

이 반환 타입은 File::open 호출이 성공하면 읽기나 쓰기에 사용할 수 있는 파일 핸들을 반환할 수 있다는 뜻입니다. 동시에 호출이 실패할 수도 있습니다. 예를 들어 파일이 존재하지 않거나, 우리가 접근 권한을 갖고 있지 않을 수 있습니다. 따라서 File::open 은 성공/실패 여부를 알려 주면서, 동시에 파일 핸들이나 에러 정보 중 하나를 함께 전달할 방법이 필요합니다. Result enum 이 바로 그 정보를 표현합니다.

File::open 이 성공하면 변수 greeting_file_result 의 값은 파일 핸들을 담은 Ok 인스턴스가 됩니다. 실패하면 greeting_file_result 는 어떤 종류의 에러가 발생했는지 더 많은 정보를 담은 Err 인스턴스가 됩니다. 이제 목록 9-3의 코드에, File::open 이 어떤 값을 반환했는지에 따라 다른 행동을 하도록 코드를 추가해야 합니다.

목록 9-4는 6장에서 배운 기본 도구인 match 식을 사용해 Result 를 처리하는 한 가지 방법을 보여 줍니다.

use std::fs::File;

fn main() {
    let greeting_file_result = File::open("hello.txt");

    let greeting_file = match greeting_file_result {
        Ok(file) => file,
        Err(error) => panic!("Problem opening the file: {error:?}"),
    };
}

Option enum과 마찬가지로, Result enum과 그 variant 역시 prelude 덕분에 이미 스코프에 들어와 있으므로, match arm 안에서 Ok, Err 앞에 Result:: 를 붙일 필요가 없습니다.

결과가 Ok 이면 이 코드는 Ok 안의 file 값을 꺼내어, 그 파일 핸들을 greeting_file 변수에 대입합니다. match 뒤에서는 이 파일 핸들을 읽기나 쓰기에 사용할 수 있습니다. 다른 arm은 File::open 으로부터 Err 값을 받은 경우를 처리합니다. 여기서는 그냥 panic! 매크로를 호출하기로 했습니다.

현재 디렉터리에 hello.txt 라는 파일이 없는 상태에서 이 코드를 실행하면, panic! 매크로로부터 다음과 같은 출력을 보게 됩니다.

$ cargo run
   Compiling error-handling v0.1.0 (file:///projects/error-handling)
    Finished `dev` profile [unoptimized + debuginfo] target(s) in 0.73s
     Running `target/debug/error-handling`

thread 'main' panicked at src/main.rs:8:23:
Problem opening the file: Os { code: 2, kind: NotFound, message: "No such file or directory" }
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

늘 그렇듯, 이 출력은 정확히 무엇이 잘못되었는지를 알려 줍니다.

서로 다른 에러를 서로 다르게 매칭하기

목록 9-4의 코드는 File::open 이 실패한 이유와 상관없이 무조건 panic! 을 일으킵니다. 하지만 우리는 실패 이유에 따라 다른 동작을 하게 만들고 싶습니다.

File::open 이 실패한 이유가 파일이 존재하지 않기 때문이라면, 파일을 새로 만들고 그 파일 핸들을 반환하고 싶습니다. 반면 권한이 없어서 열 수 없는 경우처럼, 다른 이유로 실패한다면 여전히 목록 9-4처럼 panic! 하고 싶습니다. 이를 위해 목록 9-5처럼 안쪽에 또 하나의 match 식을 추가합니다.

use std::fs::File;
use std::io::ErrorKind;

fn main() {
    let greeting_file_result = File::open("hello.txt");

    let greeting_file = match greeting_file_result {
        Ok(file) => file,
        Err(error) => match error.kind() {
            ErrorKind::NotFound => match File::create("hello.txt") {
                Ok(fc) => fc,
                Err(e) => panic!("Problem creating the file: {e:?}"),
            },
            _ => {
                panic!("Problem opening the file: {error:?}");
            }
        },
    };
}

File::open 이 Err variant 안에 담아 반환하는 값의 타입은 io::Error 인데, 이것은 표준 라이브러리가 제공하는 구조체입니다. 이 구조체에는 kind 라는 메서드가 있고, 이를 호출하면 io::ErrorKind 값을 얻을 수 있습니다. io::ErrorKind 역시 표준 라이브러리가 제공하는 enum으로, io 연산에서 발생할 수 있는 서로 다른 종류의 에러를 표현하는 variant들을 가집니다.

우리가 여기서 쓰고 싶은 variant는 ErrorKind::NotFound 입니다. 이 값은 열려고 했던 파일이 아직 존재하지 않는다는 뜻입니다. 따라서 우리는 먼저 greeting_file_result 에 대해 match 를 하고, 그 안에서 error.kind() 결과에 대해 또 match 를 합니다. 안쪽 match 에서 확인하고 싶은 조건은 error.kind() 가 ErrorKind enum의 NotFound variant 인지 여부입니다. 만약 그렇다면 File::create 로 파일을 만들려고 시도합니다.

하지만 File::create 도 실패할 수 있으므로, 안쪽 match 식에도 두 번째 arm이 필요합니다. 파일을 만들 수 없으면 다른 에러 메시지를 출력합니다. 바깥쪽 match 의 두 번째 arm은 그대로 유지되므로, “파일이 없음” 이외의 에러는 여전히 모두 패닉을 일으킵니다.

use std::fs::File;
use std::io::ErrorKind;

fn main() {
    let greeting_file = File::open("hello.txt").unwrap_or_else(|error| {
        if error.kind() == ErrorKind::NotFound {
            File::create("hello.txt").unwrap_or_else(|error| {
                panic!("Problem creating the file: {error:?}");
            })
        } else {
            panic!("Problem opening the file: {error:?}");
        }
    });
}

에러 시 패닉하기 위한 지름길

match 도 충분히 잘 동작하지만, 장황하게 느껴질 수 있고 의도를 항상 잘 드러내는 것도 아닙니다. Result 타입에는 더 구체적인 작업을 수행하기 위한 여러 헬퍼 메서드가 정의되어 있습니다.

unwrap 메서드는 목록 9-4에서 우리가 직접 쓴 match 식을 축약한 메서드입니다. Result 값이 Ok variant면 unwrap 은 그 안의 값을 반환합니다. 반면 Err variant 면 unwrap 이 대신 panic! 매크로를 호출합니다.

다음은 unwrap 을 사용하는 예입니다.

use std::fs::File;

fn main() {
    let greeting_file = File::open("hello.txt").unwrap();
}

만약 hello.txt 파일 없이 이 코드를 실행하면, unwrap 이 내부에서 호출한 panic! 으로부터 다음과 같은 에러 메시지가 나옵니다.

thread 'main' panicked at src/main.rs:4:49: called `Result::unwrap()` on an `Err` value: Os { code: 2, kind: NotFound, message: "No such file or directory" }

비슷하게 expect 메서드를 사용하면 panic! 메시지도 직접 선택할 수 있습니다.

다음이 expect 의 문법입니다.

use std::fs::File;

fn main() {
    let greeting_file = File::open("hello.txt")
        .expect("hello.txt should be included in this project");
}

우리는 expect 역시 unwrap 과 같은 방식으로 사용합니다. 파일 핸들을 반환받거나, 아니면 panic! 매크로를 호출하도록 하는 것이지요. 다만 expect 가 panic! 에 전달하는 에러 메시지는 unwrap 이 쓰는 기본 메시지가 아니라, 우리가 직접 expect 에 넘긴 인수입니다.

결과는 다음과 같습니다.

thread 'main' panicked at src/main.rs:5:10: hello.txt should be included in this project: Os { code: 2, kind: NotFound, message: "No such file or directory" }

실전 품질의 코드에서는 대부분의 Rustacean이 unwrap 보다는 expect 를 선호하고, 해당 연산이 왜 성공해야 하는지에 대한 맥락을 메시지에 넣어 둡니다. 그렇게 하면 나중에 그 가정이 틀렸을 때 디버깅에 더 많은 정보를 얻을 수 있습니다.

에러 전파하기

어떤 함수 구현이 실패할 수 있는 다른 함수를 호출할 때, 그 함수 안에서 직접 에러를 처리하는 대신 호출한 쪽 코드로 에러를 반환하여 거기서 무엇을 할지 결정하게 할 수 있습니다. 이를 에러를 전파(propagating) 한다고 하며, 더 많은 문맥과 로직을 가진 호출하는 쪽 코드에게 더 큰 제어권을 주게 됩니다.

예를 들어 목록 9-6은 파일에서 사용자 이름을 읽어 오는 함수를 보여 줍니다. 파일이 없거나 읽을 수 없다면, 이 함수는 그 에러를 함수를 호출한 쪽 코드에 그대로 돌려줍니다.

#![allow(unused)]
fn main() {
use std::fs::File;
use std::io::{self, Read};

fn read_username_from_file() -> Result<String, io::Error> {
    let username_file_result = File::open("hello.txt");

    let mut username_file = match username_file_result {
        Ok(file) => file,
        Err(e) => return Err(e),
    };

    let mut username = String::new();

    match username_file.read_to_string(&mut username) {
        Ok(_) => Ok(username),
        Err(e) => Err(e),
    }
}
}

이 함수는 훨씬 더 짧게 쓸 수도 있지만, 에러 처리를 살펴보기 위해 일부를 수동으로 길게 적어 보겠습니다. 마지막에 더 짧은 버전도 보여 줄 것입니다.

먼저 함수의 반환 타입부터 봅시다. Result<String, io::Error> 입니다. 이는 이 함수가 Result<T, E> 타입의 값을 반환한다는 뜻이고, 여기서 제네릭 매개변수 T 는 구체 타입 String 으로, 제네릭 타입 E 는 구체 타입 io::Error 로 채워졌다는 의미입니다.

이 함수가 문제 없이 성공하면, 이 함수를 호출한 코드는 파일에서 읽은 사용자 이름을 담고 있는 String 을 포함한 Ok 값을 받습니다. 반대로 함수가 문제를 만나면, 호출한 쪽 코드는 어떤 문제가 있었는지 더 많은 정보를 담은 io::Error 인스턴스를 포함한 Err 값을 받게 됩니다. 우리가 이 함수의 반환 타입으로 io::Error 를 선택한 이유는, 함수 본문 안에서 실패할 수 있는 두 연산인 File::open 함수와 read_to_string 메서드가 둘 다 io::Error 타입의 에러를 반환하기 때문입니다.

함수 본문은 먼저 File::open 을 호출하는 것으로 시작합니다. 그런 다음 목록 9-4의 match 와 비슷한 방식으로 이 Result 값을 처리합니다. File::open 이 성공하면 패턴 변수 file 안의 파일 핸들이 가변 변수 username_file 안으로 들어가고 함수는 계속 진행합니다. Err 인 경우에는 panic! 을 호출하는 대신 return 키워드로 함수 전체에서 조기에 빠져나오며, File::open 의 에러 값을(이제 패턴 변수 e 안에 있습니다) 이 함수의 에러 값으로 그대로 호출한 쪽에 돌려줍니다.

그래서 username_file 안에 파일 핸들이 있게 되면, 함수는 username 이라는 새 String 을 만들고, username_file 의 파일 핸들에 대해 read_to_string 메서드를 호출해 파일 내용을 username 안으로 읽어들입니다. read_to_string 역시 실패할 수 있기 때문에 또 다른 Result 를 반환합니다. File::open 이 성공했다고 해서 read_to_string 도 반드시 성공하는 것은 아니므로, 이 Result 도 다시 match 로 처리해야 합니다. read_to_string 이 성공하면 함수는 성공한 것이므로, username 안에 들어 있는 사용자 이름을 Ok 로 감싸 반환합니다. 실패하면 File::open 의 반환값을 처리했던 match 에서와 같은 방식으로 그 에러 값을 반환합니다. 다만 여기서는 함수의 마지막 식이므로 return 을 명시적으로 쓸 필요가 없습니다.

그러면 이 함수를 호출한 코드는 String 을 담은 Ok 값이나, io::Error 를 담은 Err 값을 받게 되고, 그중 무엇을 받았는지에 따라 처리할 수 있습니다. 예를 들어 호출한 코드는 Err 값을 받으면 panic! 을 호출해 프로그램을 중단시킬 수도 있고, 기본 사용자 이름을 사용하거나, 파일이 아닌 다른 곳에서 사용자 이름을 읽어 올 수도 있습니다. 현재 함수 안에서는 호출한 쪽 코드가 실제로 무엇을 하려는지 알 수 없으므로, 성공과 에러 정보를 그대로 위로 전파해 적절히 처리하도록 맡기는 것입니다.

이런 식의 에러 전파 패턴은 러스트에서 너무 흔하기 때문에, 이를 더 쉽게 쓰도록 러스트는 물음표 연산자 ? 를 제공합니다.

? 연산자 지름길

목록 9-7은 목록 9-6과 같은 기능을 하는 read_username_from_file 구현을 보여 줍니다. 이번 구현은 ? 연산자를 사용합니다.

#![allow(unused)]
fn main() {
use std::fs::File;
use std::io::{self, Read};

fn read_username_from_file() -> Result<String, io::Error> {
    let mut username_file = File::open("hello.txt")?;
    let mut username = String::new();
    username_file.read_to_string(&mut username)?;
    Ok(username)
}
}

Result 값 뒤에 붙은 ? 는, 목록 9-6에서 우리가 직접 쓴 match 식과 거의 같은 방식으로 동작하도록 정의되어 있습니다. Result 값이 Ok 라면, 그 안의 값이 이 식의 결과로 반환되고 프로그램은 계속 진행합니다. 값이 Err 라면, 마치 우리가 직접 return 키워드를 쓴 것처럼 함수 전체에서 그 Err 가 반환되어 에러 값이 호출하는 쪽 코드로 전파됩니다.

하지만 목록 9-6의 match 가 하던 일과 ? 가 하는 일 사이에는 차이도 있습니다. ? 를 호출한 에러 값은 표준 라이브러리의 From 트레이트에 정의된 from 함수를 거칩니다. 이 함수는 한 타입의 값을 다른 타입으로 변환할 때 사용됩니다. ? 연산자가 from 을 호출하면, 받은 에러 타입은 현재 함수의 반환 타입에 정의된 에러 타입으로 변환됩니다. 이는 함수가 여러 방식으로 실패할 수 있더라도 하나의 에러 타입으로 전부를 대표하고 싶을 때 유용합니다.

예를 들어 목록 9-7의 read_username_from_file 함수가 우리가 직접 정의한 OurError 라는 사용자 정의 에러 타입을 반환하도록 바꿀 수 있다고 해 봅시다. 그리고 io::Error 로부터 OurError 인스턴스를 만드는 impl From<io::Error> for OurError 도 정의한다면, read_username_from_file 본문 안의 ? 호출은 자동으로 from 을 사용해 에러 타입을 변환해 줍니다. 따라서 함수 안에 별도의 추가 코드가 필요하지 않습니다.

목록 9-7 맥락에서 보면, File::open 호출 뒤의 ? 는 Ok 안의 값을 username_file 변수로 돌려줍니다. 에러가 발생하면, ? 는 함수 전체에서 조기 반환하여 그 Err 값을 호출하는 코드에 넘깁니다. read_to_string 호출 끝의 ? 도 똑같이 동작합니다.

? 연산자는 보일러플레이트를 크게 줄여 주며, 함수 구현을 더 단순하게 만들어 줍니다. 심지어 ? 바로 뒤에 메서드 호출을 이어 붙여 코드 길이를 더 줄일 수도 있습니다. 목록 9-8을 보세요.

#![allow(unused)]
fn main() {
use std::fs::File;
use std::io::{self, Read};

fn read_username_from_file() -> Result<String, io::Error> {
    let mut username = String::new();

    File::open("hello.txt")?.read_to_string(&mut username)?;

    Ok(username)
}
}

이 버전에서는 함수 처음에 username 새 String 을 만드는 부분은 그대로 두고, 중간의 username_file 변수를 없앴습니다. 대신 File::open("hello.txt")? 의 결과에 직접 read_to_string 호출을 연결했습니다. read_to_string 호출 끝에는 여전히 ? 가 붙어 있고, File::open 과 read_to_string 둘 다 성공하면 username 을 담은 Ok 값을 반환합니다. 실패 시에는 에러를 반환합니다. 기능은 목록 9-6, 9-7과 동일하며, 단지 더 간결하고 사용하기 편한 방식으로 쓴 것뿐입니다.

목록 9-9는 fs::read_to_string 을 사용해 이 코드를 더 짧게 만드는 방법을 보여 줍니다.

#![allow(unused)]
fn main() {
use std::fs;
use std::io;

fn read_username_from_file() -> Result<String, io::Error> {
    fs::read_to_string("hello.txt")
}
}

파일을 문자열로 읽는 일은 꽤 흔한 연산이므로, 표준 라이브러리는 파일을 열고, 새 String 을 만들고, 파일 내용을 읽어 그 안에 넣은 뒤, 그 문자열을 반환하는 편리한 fs::read_to_string 함수를 제공합니다. 물론 여기서는 에러 처리 과정을 설명하기 위해 더 긴 방식을 먼저 살펴본 것입니다.

? 연산자를 사용할 수 있는 곳

? 연산자는 그것이 적용되는 값과 호환되는 반환 타입을 가진 함수 안에서만 사용할 수 있습니다. 이는 ? 연산자가 목록 9-6의 match 식에서 우리가 했던 것처럼, 함수 바깥으로 값을 조기 반환하도록 정의되어 있기 때문입니다. 목록 9-6의 match 는 Result 값에 대해 동작했고, 조기 반환 arm은 Err(e) 값을 반환했습니다. 따라서 함수의 반환 타입도 그 return 과 호환되도록 Result 여야 했습니다.

목록 9-10에서는 반환 타입이 ? 를 사용하는 값과 호환되지 않는 main 함수 안에서 ? 를 썼을 때 어떤 오류가 나는지 살펴봅니다.

use std::fs::File;

fn main() {
    let greeting_file = File::open("hello.txt")?;
}

이 코드는 실패할 수 있는 파일 열기 연산을 수행합니다. ? 연산자는 File::open 이 반환한 Result 값에 붙어 있지만, 이 main 함수의 반환 타입은 Result 가 아닌 () 입니다. 이 코드를 컴파일하면 다음과 같은 오류를 얻게 됩니다.

$ cargo run
   Compiling error-handling v0.1.0 (file:///projects/error-handling)
error[E0277]: the `?` operator can only be used in a function that returns `Result` or `Option` (or another type that implements `FromResidual`)
 --> src/main.rs:4:48
  |
3 | fn main() {
  | --------- this function should return `Result` or `Option` to accept `?`
4 |     let greeting_file = File::open("hello.txt")?;
  |                                                ^ cannot use the `?` operator in a function that returns `()`
  |
help: consider adding return type
  |
3 ~ fn main() -> Result<(), Box<dyn std::error::Error>> {
4 |     let greeting_file = File::open("hello.txt")?;
5 +     Ok(())
  |

For more information about this error, try `rustc --explain E0277`.
error: could not compile `error-handling` (bin "error-handling") due to 1 previous error

이 오류는 ? 연산자를 Result, Option, 혹은 FromResidual 을 구현한 다른 타입을 반환하는 함수에서만 쓸 수 있다고 지적합니다.

이 오류를 고치는 방법은 두 가지입니다. 하나는 특별한 제약이 없다면, 함수의 반환 타입을 ? 를 사용하는 값과 호환되도록 바꾸는 것입니다. 다른 하나는 match 나 Result<T, E> 의 메서드들을 사용해 그 Result<T, E> 를 적절한 방식으로 처리하는 것입니다.

오류 메시지는 또한 ? 를 Option<T> 값과 함께 사용할 수도 있다고 언급했습니다. Result 에서 ? 를 쓰는 경우와 마찬가지로, Option 에 대한 ? 는 Option 을 반환하는 함수 안에서만 사용할 수 있습니다. Option<T> 에 대해 ? 가 동작하는 방식은 Result<T, E> 에 대해 동작하는 방식과 비슷합니다. 값이 None 이면 그 시점에서 함수 바깥으로 None 을 조기 반환합니다. 값이 Some 이면, Some 안의 값이 식의 결과가 되고 함수는 계속 진행합니다. 목록 9-11은 주어진 텍스트에서 첫 줄의 마지막 문자를 찾는 함수 예입니다.

fn last_char_of_first_line(text: &str) -> Option<char> {
    text.lines().next()?.chars().last()
}

fn main() {
    assert_eq!(
        last_char_of_first_line("Hello, world\nHow are you today?"),
        Some('d')
    );

    assert_eq!(last_char_of_first_line(""), None);
    assert_eq!(last_char_of_first_line("\nhi"), None);
}

이 함수는 문자 하나가 있을 수도 있고 없을 수도 있기 때문에 Option<char> 를 반환합니다. 이 코드는 문자열 슬라이스 인수 text 에 lines 메서드를 호출하는데, 이는 문자열 안의 줄들에 대한 반복자를 반환합니다. 함수는 첫 번째 줄만 확인하고 싶기 때문에, 반복자에 next 를 호출해 첫 값을 가져옵니다. 만약 text 가 빈 문자열이면, 이 next 호출은 None 을 반환하고, 이때 우리는 ? 를 사용해 함수를 멈추고 last_char_of_first_line 에서 None 을 반환합니다. 반대로 text 가 빈 문자열이 아니라면, next 는 첫 줄의 문자열 슬라이스를 담은 Some 값을 반환합니다.

? 는 그 문자열 슬라이스를 꺼내 주고, 우리는 그 슬라이스에 chars 를 호출해 문자 반복자를 얻을 수 있습니다. 우리는 첫 줄의 마지막 문자에 관심이 있으므로, 반복자에 last 를 호출해 마지막 항목을 반환합니다. 이 역시 Option 인데, 첫 줄이 빈 문자열일 가능성이 있기 때문입니다. 예를 들어 text 가 "\nhi" 라면, 첫 줄은 비어 있지만 뒤 줄에는 문자가 있습니다. 그러나 첫 줄에 마지막 문자가 있다면 그 값은 Some variant로 반환됩니다. 중간의 ? 연산자는 이 전체 로직을 매우 간결하게 표현하게 해 줍니다. 만약 Option 에 대해 ? 를 쓸 수 없었다면, 이 로직은 훨씬 더 많은 메서드 호출이나 match 식으로 구현해야 했을 것입니다.

중요한 점은, Result 를 반환하는 함수 안에서는 Result 에 대해 ? 를 사용할 수 있고, Option 을 반환하는 함수 안에서는 Option 에 대해 ? 를 사용할 수 있지만, 이 둘을 마음대로 섞어 쓸 수는 없다는 것입니다. ? 연산자는 Result 를 Option 으로, 혹은 그 반대로 자동 변환해 주지 않습니다. 그런 경우에는 Result 의 ok 메서드나 Option 의 ok_or 메서드처럼, 명시적으로 변환하는 메서드를 사용해야 합니다.

지금까지 우리가 사용한 모든 main 함수는 () 를 반환했습니다. main 함수는 실행 가능한 프로그램의 시작점이자 끝점이기 때문에, 프로그램이 기대한 대로 동작하려면 반환 타입에 몇 가지 제약이 있습니다.

다행히 main 도 Result<(), E> 를 반환할 수 있습니다. 목록 9-12는 목록 9-10의 코드를 가져와, main 의 반환 타입을 Result<(), Box<dyn Error>> 로 바꾸고 마지막에 Ok(()) 를 추가한 버전입니다. 이 코드는 이제 컴파일됩니다.

use std::error::Error;
use std::fs::File;

fn main() -> Result<(), Box<dyn Error>> {
    let greeting_file = File::open("hello.txt")?;

    Ok(())
}

Box<dyn Error> 타입은 trait object이며, 이는 18장의 “공통 동작을 추상화하기 위해 트레이트 객체 사용하기” 절에서 다룹니다. 지금은 Box<dyn Error> 를 “어떤 종류의 에러든 담을 수 있는 것” 정도로 읽으면 됩니다. Box<dyn Error> 가 허용되기 때문에, Result<(), Box<dyn Error>> 를 반환하는 main 안에서는 어떤 Err 값이든 조기 반환될 수 있습니다. 이 main 함수 본문이 현재는 std::io::Error 타입 에러만 반환하더라도, 나중에 다른 종류의 에러를 반환하는 코드를 추가해도 이 시그니처는 여전히 올바르게 유지됩니다.

main 함수가 Result<(), E> 를 반환하면, main 이 Ok(()) 를 반환할 때 실행 파일은 종료 값 0 으로 끝나고, Err 를 반환하면 0이 아닌 값으로 끝납니다. C로 작성된 실행 파일도 종료 시 정수를 반환합니다. 성공적으로 끝난 프로그램은 0, 오류로 끝난 프로그램은 0 이 아닌 정수를 반환합니다. 러스트도 이 관례와 호환되기 위해 실행 파일에서 정수를 반환합니다.

main 함수는 [표준 라이브러리의 std::process::Termination 트레이트] termination를 구현한 어떤 타입이든 반환할 수 있습니다. 이 트레이트는 ExitCode 를 반환하는 report 함수를 포함합니다. 여러분 자신의 타입에 Termination 트레이트를 구현하는 방법은 표준 라이브러리 문서를 참고하세요.

이제 panic! 을 호출하는 경우와 Result 를 반환하는 경우의 세부를 모두 살펴봤으니, 어떤 상황에서 어느 쪽을 사용하는 것이 적절한지라는 주제로 다시 돌아가 보겠습니다.

panic!을 써야 할 때와 쓰지 말아야 할 때

panic! 을 써야 할 때와 쓰지 말아야 할 때

그렇다면 언제 panic! 을 호출해야 하고, 언제 Result 를 반환해야 할까요? 코드가 패닉하면 복구할 방법이 없습니다. 복구 가능성이 있든 없든 모든 에러 상황에 대해 panic! 을 호출할 수는 있지만, 그렇게 하면 “이 상황은 복구 불가능하다”는 결정을 호출하는 코드 대신 여러분이 내려 버리는 것입니다. 반대로 Result 값을 반환하면 호출하는 코드에 선택지를 남겨 둡니다. 호출하는 코드는 자기 상황에 맞는 방식으로 복구를 시도할 수도 있고, 혹은 이 경우 Err 값이 사실상 복구 불가능하다고 판단해 panic! 을 호출하고, 여러분의 “복구 가능한 에러”를 자기 쪽에서는 “복구 불가능한 에러”로 바꿀 수도 있습니다. 그래서 실패할 수 있는 함수를 정의할 때는 Result 를 반환하는 것이 좋은 기본 선택입니다.

예제 코드, 프로토타입 코드, 테스트 같은 상황에서는 Result 대신 패닉하는 코드를 작성하는 편이 더 적절할 수 있습니다. 왜 그런지 먼저 살펴보고, 그다음에는 컴파일러는 실패 가능성을 알 수 없지만 인간인 여러분은 “실패할 수 없다”고 판단할 수 있는 상황을 논의하겠습니다. 마지막에는 라이브러리 코드에서 패닉할지 말지를 결정할 때 도움이 되는 일반적인 가이드라인으로 장을 마무리합니다.

예제, 프로토타입 코드, 테스트

어떤 개념을 설명하기 위한 예제를 작성할 때, 그 안에 견고한 에러 처리 코드까지 다 넣어 버리면 오히려 예제가 덜 명확해질 수 있습니다. 예제에서 unwrap 같은 패닉 가능 메서드를 호출하는 것은, “여기에는 실제 애플리케이션이 상황에 맞게 에러를 처리하는 방식이 들어갈 자리표시자” 정도로 이해하면 됩니다.

마찬가지로, 에러를 어떻게 처리할지 아직 결정하지 않은 프로토타입 단계에서는 unwrap 과 expect 가 매우 편리합니다. 나중에 프로그램을 더 견고하게 만들 준비가 되었을 때 “여기를 다시 봐야 한다”는 표시를 코드에 명확하게 남겨 두기 때문입니다.

테스트에서 어떤 메서드 호출이 실패한다면, 그 메서드 자체가 테스트 대상이 아니더라도 테스트 전체가 실패해야 합니다. 러스트에서 테스트 실패는 panic! 으로 표시되므로, unwrap 이나 expect 를 호출했을 때 그대로 패닉하는 동작은 오히려 우리가 원하는 정확한 행동입니다.

여러분이 컴파일러보다 더 많은 정보를 알고 있을 때

또 다른 적절한 경우는, 어떤 로직 덕분에 Result 가 반드시 Ok 값을 가질 것이라는 사실을 여러분은 알고 있지만 컴파일러는 알지 못하는 경우입니다. 일반적인 의미에서 실패할 가능성이 여전히 있는 연산을 호출하고 있으므로, 코드 안에는 여전히 Result 값이 생깁니다. 그러나 코드 전체를 사람이 직접 살펴보았을 때 특정 상황에서는 Err variant가 절대로 나올 수 없다고 확신할 수 있다면, expect 를 호출하고 왜 그런 확신을 갖는지를 expect 의 메시지 안에 적어 두는 것은 충분히 괜찮습니다. 다음은 예시입니다.

fn main() {
    use std::net::IpAddr;

    let home: IpAddr = "127.0.0.1"
        .parse()
        .expect("Hardcoded IP address should be valid");
}

우리는 하드코딩된 문자열을 파싱해 IpAddr 인스턴스를 만들고 있습니다. 127.0.0.1 이 유효한 IP 주소라는 사실을 우리가 직접 확인할 수 있으므로, 이 경우에는 expect 를 사용해도 됩니다. 하지만 문자열이 하드코딩되어 있다는 사실이 parse 메서드의 반환 타입을 바꾸지는 않습니다. 여전히 Result 값을 받게 되고, 컴파일러는 이 문자열이 언제나 유효한 IP 주소라는 것을 알아내지 못하므로 Err 가능성도 있다고 보고 Result 처리를 강제합니다. 만약 이 IP 주소 문자열이 프로그램 안에 하드코딩된 것이 아니라 사용자 입력에서 왔다면, 당연히 실패 가능성이 있으므로 Result 를 더 튼튼한 방식으로 처리해야 할 것입니다. 지금 “이 IP 주소는 하드코딩되어 있다”는 가정을 메시지에 적어 두면, 나중에 다른 입력원에서 IP 주소를 받게 될 때 expect 를 더 적절한 에러 처리 코드로 바꿔야 한다는 사실도 쉽게 드러납니다.

에러 처리 가이드라인

코드가 나쁜 상태(bad state)에 빠질 가능성이 있다면, 그럴 때는 패닉하게 만드는 것이 바람직합니다. 여기서 나쁜 상태 란 어떤 가정, 보장, 계약, 혹은 불변 조건이 깨진 상태를 말합니다. 예를 들어 잘못된 값, 서로 모순되는 값, 필요한 값의 부재 같은 것이 여기에 해당하고, 보통 다음 중 하나 이상이 함께 성립합니다.

• 그 나쁜 상태는 사용자가 가끔 잘못된 형식으로 데이터를 입력하는 것처럼 “가끔 일어날 수 있는 일” 이 아니라, “예상 밖의 일” 이다.
• 그 이후의 코드가 매 단계마다 문제를 검사하는 대신, “지금 나쁜 상태가 아니다”는 사실에 의존해야 한다.
• 사용 중인 타입으로 이 정보를 깔끔하게 인코딩할 좋은 방법이 없다. 18장의 “상태와 동작을 타입으로 인코딩하기” 절에서 이 의미가 무엇인지 예제를 통해 살펴봅니다.

누군가가 여러분의 코드를 호출할 때 말이 안 되는 값을 넘겼다면, 가능하다면 에러를 반환해 라이브러리 사용자가 자기 상황에 맞는 결정을 내리게 하는 것이 좋습니다. 그러나 계속 진행하는 것이 위험하거나 해로울 수 있는 경우라면, panic! 을 호출해 라이브러리를 사용하는 사람에게 “여기에는 버그가 있다”는 사실을 알려 주고 개발 중에 고치게 하는 편이 더 좋을 수도 있습니다. 마찬가지로, 여러분이 제어할 수 없는 외부 코드를 호출했는데 그것이 고칠 방법도 없는 잘못된 상태를 반환한다면, panic! 이 적절한 선택인 경우가 많습니다.

반대로 실패가 기대되는 상황이라면, panic! 보다는 Result 를 반환하는 편이 적절합니다. 예를 들어 파서에 잘못된 형식의 데이터가 들어오거나, HTTP 요청이 속도 제한에 걸렸음을 나타내는 상태 코드를 반환하는 경우가 그렇습니다. 이런 경우 Result 를 반환하는 것은 “실패가 예상 가능한 가능성” 이며, 호출하는 코드가 이를 어떻게 처리할지 결정해야 함을 의미합니다.

코드가 잘못된 값으로 호출되었을 때 사용자를 위험하게 만들 수 있는 연산을 수행한다면, 코드 안에서 먼저 값이 유효한지 검사하고, 유효하지 않다면 패닉해야 합니다. 이것은 주로 안전 때문입니다. 잘못된 데이터로 연산하려고 하면 코드가 취약점에 노출될 수 있습니다. 이것이 표준 라이브러리가 배열 범위를 벗어난 메모리 접근 시 panic! 을 호출하는 주된 이유입니다. 현재 자료구조에 속하지 않는 메모리에 접근하려는 시도는 아주 흔한 보안 문제이기 때문입니다. 함수는 종종 계약(contract) 을 가집니다. 입력이 특정 요구사항을 만족할 때만 그 동작이 보장됩니다. 계약이 깨졌을 때 패닉하는 것은 자연스러운 일입니다. 계약 위반은 항상 호출자 쪽의 버그 를 의미하기 때문이며, 호출하는 코드가 일일이 처리해야 할 종류의 에러가 아니기 때문입니다. 사실 호출하는 코드가 “복구”할 합리적인 방법도 없습니다. 고쳐야 하는 것은 호출하는 프로그래머 의 코드입니다. 함수의 계약은, 특히 계약 위반이 패닉을 일으킨다면 API 문서에 설명되어 있어야 합니다.

그렇다고 모든 함수에 이런 검사를 전부 손으로 넣는다면 장황하고 귀찮아집니다. 다행히 러스트의 타입 시스템(그리고 컴파일러의 타입 검사)을 이용해 많은 검사를 대신 시킬 수 있습니다. 함수가 어떤 타입을 매개변수로 받는다면, 컴파일러가 이미 유효한 값만 들어올 수 있도록 보장했다는 사실을 믿고 이후 로직을 진행할 수 있습니다. 예를 들어 Option 대신 단일 타입을 받는다면, 이 프로그램은 없음 이 아니라 무언가 가 반드시 있다는 것을 기대하고 있습니다. 그러면 코드는 Some 과 None 두 경우를 모두 다룰 필요 없이, 값이 확실히 있다는 경우 하나만 처리하면 됩니다. 함수에 “없음” 을 넘기려는 코드는 아예 컴파일조차 되지 않으므로, 함수는 런타임에서 그 경우를 검사할 필요가 없습니다. 또 다른 예는 u32 같은 부호 없는 정수 타입을 사용하는 것입니다. 그러면 매개변수가 절대 음수가 아님이 보장됩니다.

검증을 위한 사용자 정의 타입

러스트 타입 시스템을 사용해 “유효한 값만 가진다”는 사실을 보장하는 아이디어를 한 걸음 더 밀어붙여, 검증용 사용자 정의 타입을 만드는 방법을 살펴봅시다. 2장의 숫자 맞히기 게임을 떠올려 보세요. 그 코드에서는 사용자에게 1부터 100 사이의 숫자를 추측하라고 했지만, 실제로는 비밀 숫자와 비교하기 전에 그 추측이 정말 그 범위 안에 있는지 검사하지 않았습니다. 추측값이 양수인지 정도만 확인했지요. 그때는 결과가 그렇게 심각하지 않았습니다. 범위 밖 숫자라도 “너무 큽니다” 또는 “너무 작습니다” 출력은 여전히 맞았으니까요. 하지만 유효한 추측값 범위를 사용자에게 안내하고, 범위를 벗어난 숫자를 입력했을 때와 문자를 입력했을 때의 동작을 다르게 만드는 것은 분명 유용한 개선입니다.

이를 처리하는 한 가지 방법은 추측값을 u32 가 아니라 i32 로 파싱해 음수도 허용한 뒤, 숫자가 범위 안에 있는지 검사하는 코드를 추가하는 것입니다.

use rand::Rng;
use std::cmp::Ordering;
use std::io;

fn main() {
    println!("Guess the number!");

    let secret_number = rand::thread_rng().gen_range(1..=100);

    loop {
        // --snip--

        println!("Please input your guess.");

        let mut guess = String::new();

        io::stdin()
            .read_line(&mut guess)
            .expect("Failed to read line");

        let guess: i32 = match guess.trim().parse() {
            Ok(num) => num,
            Err(_) => continue,
        };

        if guess < 1 || guess > 100 {
            println!("The secret number will be between 1 and 100.");
            continue;
        }

        match guess.cmp(&secret_number) {
            // --snip--
            Ordering::Less => println!("Too small!"),
            Ordering::Greater => println!("Too big!"),
            Ordering::Equal => {
                println!("You win!");
                break;
            }
        }
    }
}

if 식은 값이 범위를 벗어났는지 검사하고, 범위를 벗어나면 사용자에게 문제를 알린 뒤 continue 를 호출해 루프의 다음 반복으로 넘어가 다시 추측값을 묻습니다. 그리고 if 식 뒤에서는 guess 가 반드시 1과 100 사이임을 알고 있으므로, 비밀 숫자와의 비교를 안심하고 진행할 수 있습니다.

하지만 이 방법도 이상적이지는 않습니다. 프로그램이 정말로 1부터 100 사이의 값에서만 동작해야 하고, 이런 요구를 가진 함수가 여러 개 있다면, 모든 함수 안에 이런 검사를 반복해서 적는 것은 지루하고(심지어 성능에도 영향을 줄 수 있습니다).

대신 별도 모듈 안에 새 타입을 만들고, 인스턴스를 생성하는 함수 안에 검증을 넣을 수 있습니다. 그러면 검증을 여러 곳에 반복하지 않아도 되고, 함수들은 그 새 타입을 시그니처에 사용함으로써 “전달받은 값은 이미 유효하다”는 사실을 믿고 코드를 쓸 수 있습니다. 목록 9-13은 new 함수에 1부터 100 사이 값이 들어왔을 때만 Guess 인스턴스를 만들어 주는 한 가지 방법을 보여 줍니다.

#![allow(unused)]
fn main() {
pub struct Guess {
    value: i32,
}

impl Guess {
    pub fn new(value: i32) -> Guess {
        if value < 1 || value > 100 {
            panic!("Guess value must be between 1 and 100, got {value}.");
        }

        Guess { value }
    }

    pub fn value(&self) -> i32 {
        self.value
    }
}
}

참고로 이 코드는 src/guessing_game.rs 안에 있지만, 여기에는 보여 주지 않은 mod guessing_game; 모듈 선언이 src/lib.rs 안에 추가되어 있어야 합니다. 새 모듈 파일 안에서 우리는 value 라는 i32 필드를 가진 Guess 구조체를 정의합니다. 이 필드에 실제 숫자가 저장됩니다.

그리고 나서 Guess 위에 new 라는 연관 함수를 구현합니다. new 함수는 value 라는 이름의 i32 매개변수 하나를 받고 Guess 를 반환합니다. new 본문 안의 코드는 value 가 1과 100 사이인지 검사합니다. 만약 이 검사를 통과하지 못하면 panic! 을 호출합니다. 이것은 이 함수를 호출하는 코드를 작성한 프로그래머에게 “고쳐야 할 버그가 있다”는 사실을 알려 주기 위함입니다. 범위 밖 값으로 Guess 를 만드는 것은 Guess::new 가 기대하는 계약을 어기는 것이기 때문입니다. Guess::new 가 패닉할 수 있는 조건은 공개 API 문서에도 설명되어 있어야 합니다. 14장에서는 API 문서 안에 panic! 가능성을 어떻게 표시하는지도 다룹니다. 반대로 value 가 검사를 통과하면, value 필드가 그 값으로 설정된 새 Guess 를 만들어 반환합니다.

그 다음에는 self 를 빌리고 다른 매개변수는 받지 않으며 i32 를 반환하는 value 라는 메서드를 구현합니다. 이런 종류의 메서드는 보통 필드 데이터를 꺼내 반환하는 역할을 하므로 getter 라고 부릅니다. 이 public 메서드가 필요한 이유는, Guess 구조체의 value 필드가 private 이기 때문입니다. value 필드를 private 로 두는 것은 중요합니다. Guess 를 사용하는 코드가 직접 value 를 설정하지 못하게 하기 위해서 입니다. 모듈 바깥 코드가 Guess 인스턴스를 만들려면 반드시 Guess::new 를 사용해야 하고, 그러면 Guess 안의 값은 항상 Guess::new 의 검사를 통과한 값이라는 사실이 보장됩니다.

1부터 100 사이 숫자만 받아야 하는 함수라면, 이제 시그니처에서 i32 대신 Guess 를 받거나 반환한다고 선언할 수 있습니다. 그러면 함수 본문 안에서 추가 검사 코드를 또 작성할 필요가 없습니다.

정리

러스트의 에러 처리 기능은 여러분이 더 견고한 코드를 작성하도록 설계되어 있습니다. panic! 매크로는 프로그램이 더 이상 감당할 수 없는 상태에 있다는 신호를 보내고, 잘못된 값으로 계속 진행하는 대신 프로세스를 멈추게 합니다. Result enum은 타입 시스템을 사용해, 어떤 연산이 실패할 수 있지만 여러분의 코드가 그 실패로부터 복구할 수 있다는 사실을 표현합니다. Result 는 여러분의 코드를 호출하는 코드에게도, 성공과 실패 가능성을 모두 처리해야 한다는 사실을 알릴 수 있습니다. 적절한 상황에서 panic! 과 Result 를 사용하는 것은, 피할 수 없는 문제들 앞에서도 코드를 더 신뢰할 수 있게 만들어 줍니다.

이제 여러분은 표준 라이브러리가 Option 과 Result enum에서 제네릭을 어떻게 유용하게 사용하는지도 보았습니다. 다음으로는 제네릭이 어떻게 동작하는지, 그리고 여러분 자신의 코드에서 제네릭을 어떻게 사용할 수 있는지를 이야기하겠습니다.

제네릭 타입, 트레이트, 라이프타임

모든 프로그래밍 언어에는 개념 중복을 효과적으로 다루기 위한 도구가 있습니다. 러스트에서는 그중 하나가 제네릭(generics) 입니다. 제네릭은 구체적인 타입이나 다른 속성을 대신하는 추상적인 자리표시자입니다. 우리는 코드를 컴파일하고 실행할 때 그 자리에 무엇이 올지 몰라도, 제네릭의 동작 방식이나 제네릭들 사이 관계를 표현할 수 있습니다.

함수는 i32 나 String 같은 구체 타입 대신 어떤 제네릭 타입의 매개변수를 받을 수 있습니다. 이는 함수가 여러 구체 값에 같은 코드를 적용하기 위해 “값은 아직 모르는” 매개변수를 받는 것과 비슷합니다. 사실 우리는 이미 6장에서 Option<T>, 8장에서 Vec<T> 와 HashMap<K, V>, 9장에서 Result<T, E> 를 통해 제네릭을 사용해 보았습니다. 이 장에서는 여러분 자신의 타입, 함수, 메서드에 제네릭을 정의하는 방법을 살펴보게 됩니다!

먼저, 코드 중복을 줄이기 위해 함수를 추출하는 방법을 다시 훑어보겠습니다. 그런 다음 매개변수 타입만 다른 두 함수를 같은 기법으로 하나의 제네릭 함수로 바꾸겠습니다. 또한 구조체와 enum 정의 안에서 제네릭 타입을 사용하는 방법도 설명합니다.

그다음에는 트레이트를 사용해 동작을 제네릭한 방식으로 정의하는 방법을 배웁니다. 트레이트와 제네릭 타입을 결합하면, “아무 타입이나” 가 아니라 “특정 동작을 가진 타입만” 받아들이도록 제네릭 타입을 제한할 수 있습니다.

마지막으로 라이프타임(lifetimes) 을 다룹니다. 라이프타임은 제네릭의 한 종류로, 참조들이 서로 어떻게 관계되는지를 컴파일러에게 알려 줍니다. 라이프타임을 사용하면 빌린 값에 대해 컴파일러가 더 많은 정보를 알 수 있게 되어, 우리 도움 없이도 보장할 수 있는 것보다 더 많은 상황에서 참조가 유효함을 보장할 수 있습니다.

함수 추출로 중복 제거하기

제네릭은 여러 타입을 나타내는 자리표시자로 특정 타입을 대체함으로써 코드 중복을 없애게 해 줍니다. 제네릭 문법으로 바로 들어가기 전에, 먼저 제네릭 타입을 사용하지 않고도 어떻게 중복을 제거할 수 있는지 살펴봅시다. 구체적인 값을 여러 값을 나타내는 자리표시자로 바꾸는 함수를 추출하는 방식입니다. 그런 다음 같은 기법을 적용해 제네릭 함수를 추출해 보겠습니다. 함수를 추출할 수 있는 중복 코드를 어떻게 찾아내는지 익히면, 제네릭을 사용할 수 있는 중복 코드도 자연스럽게 보이기 시작할 것입니다.

먼저 목록 10-1의 짧은 프로그램부터 시작합니다. 이 프로그램은 숫자 목록에서 가장 큰 수를 찾습니다.

fn main() {
    let number_list = vec![34, 50, 25, 100, 65];

    let mut largest = &number_list[0];

    for number in &number_list {
        if number > largest {
            largest = number;
        }
    }

    println!("The largest number is {largest}");
    assert_eq!(*largest, 100);
}

우리는 정수 목록을 number_list 변수에 저장하고, 목록의 첫 번째 숫자에 대한 참조를 largest 라는 변수에 넣습니다. 그런 다음 목록의 모든 숫자를 순회하면서, 현재 숫자가 largest 안에 저장된 숫자보다 크면 그 변수 안의 참조를 새 숫자로 바꿉니다. 반대로 현재 숫자가 지금까지 본 가장 큰 수보다 작거나 같으면 변수는 바뀌지 않고, 코드는 다음 숫자로 넘어갑니다. 목록의 모든 숫자를 검사하고 나면, largest 는 가장 큰 수를 가리키게 되는데, 이 경우 그 값은 100입니다.

이제 우리는 숫자 목록 두 개에서 각각 가장 큰 수를 찾아야 하는 상황을 맞았다고 해 봅시다. 그렇게 하려면 목록 10-1의 코드를 그냥 복사해 프로그램의 두 곳에서 같은 논리를 사용할 수 있습니다. 목록 10-2가 그런 모습입니다.

fn main() {
    let number_list = vec![34, 50, 25, 100, 65];

    let mut largest = &number_list[0];

    for number in &number_list {
        if number > largest {
            largest = number;
        }
    }

    println!("The largest number is {largest}");

    let number_list = vec![102, 34, 6000, 89, 54, 2, 43, 8];

    let mut largest = &number_list[0];

    for number in &number_list {
        if number > largest {
            largest = number;
        }
    }

    println!("The largest number is {largest}");
}

이 코드는 동작하지만, 코드를 복붙하는 것은 지루하고 실수하기 쉽습니다. 나중에 코드를 수정하고 싶을 때 여러 곳을 함께 바꿔야 한다는 점도 문제입니다.

이 중복을 제거하기 위해, 정수 목록을 매개변수로 받아 그 목록에 대해 동작하는 함수를 정의함으로써 추상화를 만들어 봅시다. 이렇게 하면 코드가 더 명확해지고, “목록에서 가장 큰 수를 찾는다”는 개념도 더 추상적으로 표현할 수 있습니다.

목록 10-3에서는 가장 큰 수를 찾는 코드를 largest 라는 함수로 추출합니다. 그런 다음 목록 10-2의 두 목록 각각에 대해 이 함수를 호출합니다. 앞으로 추가되는 다른 i32 목록에도 같은 함수를 사용할 수 있습니다.

fn largest(list: &[i32]) -> &i32 {
    let mut largest = &list[0];

    for item in list {
        if item > largest {
            largest = item;
        }
    }

    largest
}

fn main() {
    let number_list = vec![34, 50, 25, 100, 65];

    let result = largest(&number_list);
    println!("The largest number is {result}");
    assert_eq!(*result, 100);

    let number_list = vec![102, 34, 6000, 89, 54, 2, 43, 8];

    let result = largest(&number_list);
    println!("The largest number is {result}");
    assert_eq!(*result, 6000);
}

largest 함수는 list 라는 매개변수를 가지며, 이것은 함수에 전달할 수 있는 어떤 구체적인 i32 슬라이스라도 나타냅니다. 따라서 함수를 호출하면, 우리가 실제로 넘긴 구체 값에 대해 그 코드가 실행됩니다.

정리하면, 목록 10-2의 코드를 목록 10-3처럼 바꾸기 위해 다음 단계를 거쳤습니다.

1. 중복 코드를 찾는다.
2. 중복 코드를 함수 본문으로 추출하고, 그 코드의 입력과 반환값을 함수 시그니처로 지정한다.
3. 중복되던 두 코드 위치를 함수 호출로 바꾼다.

이제 같은 단계를 제네릭에도 적용해 코드 중복을 줄여 보겠습니다. 함수 본문이 구체적인 값 대신 추상적인 list 에 대해 동작할 수 있었던 것처럼, 제네릭도 코드가 추상적인 타입에 대해 동작하게 해 줍니다.

예를 들어 i32 슬라이스에서 가장 큰 값을 찾는 함수 하나와, char 슬라이스에서 가장 큰 값을 찾는 함수 하나가 있다고 해 봅시다. 이 중복을 어떻게 제거할 수 있을까요? 이제 알아봅시다!

제네릭 데이터 타입

제네릭 데이터 타입

제네릭은 함수 시그니처나 구조체 같은 항목 정의를 만들 때 사용하며, 이후 다양한 구체 데이터 타입과 함께 쓸 수 있게 해 줍니다. 먼저 함수, 구조체, enum, 메서드를 제네릭으로 정의하는 방법을 살펴보겠습니다. 그런 다음 제네릭이 코드 성능에 어떤 영향을 미치는지도 이야기하겠습니다.

함수 정의에서의 제네릭

제네릭을 사용하는 함수를 정의할 때는, 보통 매개변수와 반환값의 데이터 타입을 적는 자리인 함수 시그니처에 제네릭을 둡니다. 이렇게 하면 코드는 더 유연해지고, 함수 호출자에게 더 많은 기능을 제공하면서도 코드 중복은 막을 수 있습니다.

앞의 largest 함수 예를 계속 써 봅시다. 목록 10-4는 슬라이스에서 가장 큰 값을 찾는 두 함수가 나와 있는데, 함수 이름과 시그니처 안의 타입만 다르고 나머지는 같습니다. 그다음 이 둘을 제네릭을 사용하는 하나의 함수로 합칠 것입니다.

fn largest_i32(list: &[i32]) -> &i32 {
    let mut largest = &list[0];

    for item in list {
        if item > largest {
            largest = item;
        }
    }

    largest
}

fn largest_char(list: &[char]) -> &char {
    let mut largest = &list[0];

    for item in list {
        if item > largest {
            largest = item;
        }
    }

    largest
}

fn main() {
    let number_list = vec![34, 50, 25, 100, 65];

    let result = largest_i32(&number_list);
    println!("The largest number is {result}");
    assert_eq!(*result, 100);

    let char_list = vec!['y', 'm', 'a', 'q'];

    let result = largest_char(&char_list);
    println!("The largest char is {result}");
    assert_eq!(*result, 'y');
}

largest_i32 함수는 목록 10-3에서 추출했던, 슬라이스 안의 가장 큰 i32 를 찾는 함수입니다. largest_char 함수는 슬라이스 안의 가장 큰 char 를 찾습니다. 함수 본문은 완전히 같으니, 하나의 함수에 제네릭 타입 매개변수를 도입하여 중복을 제거합시다.

하나의 새 함수 안에서 타입들을 매개변수화하려면, 함수의 값 매개변수에 이름을 붙일 때와 마찬가지로 타입 매개변수에도 이름을 붙여야 합니다. 타입 매개변수 이름에는 어떤 식별자를 써도 되지만, 관례적으로 T 를 많이 사용합니다. 러스트에서 타입 매개변수 이름은 대개 짧고, 종종 한 글자이며, 러스트 타입 이름 관례인 UpperCamelCase 를 따릅니다. type 의 첫 글자인 T 는 대부분의 Rust 프로그래머가 기본 선택으로 사용하는 이름입니다.

함수 본문 안에서 어떤 매개변수를 사용하려면, 컴파일러가 그 이름이 무엇을 뜻하는지 알게 하려고 시그니처 안에 선언해 두어야 합니다. 마찬가지로 함수 시그니처 안에서 타입 매개변수 이름을 사용하려면, 먼저 그 이름을 선언해야 합니다. 제네릭 largest 함수를 정의하려면, 함수 이름과 매개변수 목록 사이에 꺾쇠 괄호 <> 안에 타입 이름 선언을 넣습니다. 예를 들면 다음과 같습니다.

fn largest<T>(list: &[T]) -> &T {

이 정의는 “함수 largest 는 어떤 타입 T 에 대해 제네릭이다”라고 읽을 수 있습니다. 이 함수는 list 라는 매개변수 하나를 가지며, 이는 T 타입 값을 담은 슬라이스입니다. largest 함수는 같은 T 타입의 값에 대한 참조를 반환합니다.

목록 10-5는 시그니처 안에서 제네릭 데이터 타입을 사용하는 largest 함수 정의를 보여 줍니다. 이 목록은 또한 i32 슬라이스와 char 슬라이스 각각으로 함수를 호출하는 방법도 보여 줍니다. 다만 이 코드는 아직 컴파일되지 않습니다.

fn largest<T>(list: &[T]) -> &T {
    let mut largest = &list[0];

    for item in list {
        if item > largest {
            largest = item;
        }
    }

    largest
}

fn main() {
    let number_list = vec![34, 50, 25, 100, 65];

    let result = largest(&number_list);
    println!("The largest number is {result}");

    let char_list = vec!['y', 'm', 'a', 'q'];

    let result = largest(&char_list);
    println!("The largest char is {result}");
}

지금 이 코드를 컴파일하면 다음 오류가 납니다.

$ cargo run
   Compiling chapter10 v0.1.0 (file:///projects/chapter10)
error[E0369]: binary operation `>` cannot be applied to type `&T`
 --> src/main.rs:5:17
  |
5 |         if item > largest {
  |            ---- ^ ------- &T
  |            |
  |            &T
  |
help: consider restricting type parameter `T` with trait `PartialOrd`
  |
1 | fn largest<T: std::cmp::PartialOrd>(list: &[T]) -> &T {
  |             ++++++++++++++++++++++

For more information about this error, try `rustc --explain E0369`.
error: could not compile `chapter10` (bin "chapter10") due to 1 previous error

도움말에는 std::cmp::PartialOrd 가 언급되어 있는데, 이것은 트레이트이고 바로 다음 절에서 자세히 다룰 것입니다. 지금은 이 오류가, largest 본문이 T 가 될 수 있는 모든 타입에 대해 동작하지 않는다고 말하고 있다는 점만 알면 충분합니다. 함수 본문 안에서 T 타입 값들을 비교하려 하기 때문에, 값들을 순서 비교할 수 있는 타입만 쓸 수 있습니다. 이를 가능하게 하기 위해 표준 라이브러리에는 타입이 구현할 수 있는 std::cmp::PartialOrd 트레이트가 있습니다(이 트레이트에 대한 더 자세한 내용은 부록 C를 참고하세요). 목록 10-5를 고치려면 도움말의 제안처럼, T 에 들어올 수 있는 타입을 PartialOrd 를 구현한 타입으로 제한하면 됩니다. 그러면 표준 라이브러리가 i32 와 char 모두에 PartialOrd 를 구현하고 있으므로 이 목록은 컴파일됩니다.

구조체 정의에서의 제네릭

구조체의 하나 이상의 필드에 제네릭 타입 매개변수를 사용하도록 구조체를 정의할 수도 있습니다. 목록 10-6은 x, y 좌표값을 어떤 타입이든 담을 수 있도록 Point<T> 구조체를 정의한 예입니다.

struct Point<T> {
    x: T,
    y: T,
}

fn main() {
    let integer = Point { x: 5, y: 10 };
    let float = Point { x: 1.0, y: 4.0 };
}

구조체 정의에서 제네릭을 사용하는 문법은 함수 정의에서 사용한 것과 비슷합니다. 먼저 구조체 이름 바로 뒤의 꺾쇠 괄호 안에 타입 매개변수 이름을 선언합니다. 그다음 구조체 정의 안에서 원래 구체 타입을 적을 위치에 제네릭 타입을 사용합니다.

여기서 Point<T> 를 정의할 때 제네릭 타입을 하나만 사용했기 때문에, 이 정의는 Point<T> 구조체가 어떤 타입 T 에 대해 제네릭이며, 필드 x 와 y 둘 다 같은 타입이라는 뜻입니다. 목록 10-7처럼 서로 다른 타입 값을 가진 Point<T> 인스턴스를 만들려고 하면 코드는 컴파일되지 않습니다.

struct Point<T> {
    x: T,
    y: T,
}

fn main() {
    let wont_work = Point { x: 5, y: 4.0 };
}

이 예제에서 x 에 정수 값 5 를 대입하는 순간, 컴파일러는 이 Point<T> 인스턴스에 대해 제네릭 타입 T 가 정수 타입임을 알게 됩니다. 그런 뒤 y 에 4.0 을 넣으면, y 는 x 와 같은 타입이어야 하므로 다음과 같은 타입 불일치 오류가 발생합니다.

$ cargo run
   Compiling chapter10 v0.1.0 (file:///projects/chapter10)
error[E0308]: mismatched types
 --> src/main.rs:7:38
  |
7 |     let wont_work = Point { x: 5, y: 4.0 };
  |                                      ^^^ expected integer, found floating-point number

For more information about this error, try `rustc --explain E0308`.
error: could not compile `chapter10` (bin "chapter10") due to 1 previous error

x 와 y 둘 다 제네릭이지만 서로 다른 타입을 허용하는 Point 구조체를 정의하려면, 여러 개의 제네릭 타입 매개변수를 사용할 수 있습니다. 예를 들어 목록 10-8에서는 Point 정의를 T, U 두 타입에 대해 제네릭하게 바꾸고, x 는 T, y 는 U 타입으로 만듭니다.

struct Point<T, U> {
    x: T,
    y: U,
}

fn main() {
    let both_integer = Point { x: 5, y: 10 };
    let both_float = Point { x: 1.0, y: 4.0 };
    let integer_and_float = Point { x: 5, y: 4.0 };
}

이제 목록에 나온 모든 Point 인스턴스가 허용됩니다! 정의 안에는 필요한 만큼 많은 제네릭 타입 매개변수를 둘 수 있습니다. 다만 몇 개 이상으로 많아지면 코드를 읽기 어려워집니다. 코드 안에 제네릭 타입이 너무 많이 필요하다고 느껴진다면, 코드 구조를 더 작은 조각들로 다시 나눠야 한다는 신호일 수도 있습니다.

enum 정의에서의 제네릭

구조체와 마찬가지로, enum도 variant 안에 제네릭 데이터 타입을 담도록 정의할 수 있습니다. 6장에서 사용했던 표준 라이브러리의 Option<T> enum을 다시 봅시다.

#![allow(unused)]
fn main() {
enum Option<T> {
    Some(T),
    None,
}
}

이제 이 정의가 좀 더 잘 이해될 것입니다. 보시다시피 Option<T> enum은 타입 T 에 대해 제네릭이고, 두 개의 variant를 가집니다. Some 은 타입 T 값 하나를 담고, None 은 아무 값도 담지 않습니다. Option<T> 를 사용하면 “선택적인 값”이라는 추상 개념을 표현할 수 있고, Option<T> 가 제네릭이기 때문에 그 값의 타입이 무엇이든 같은 추상화를 사용할 수 있습니다.

Enum도 여러 개의 제네릭 타입을 사용할 수 있습니다. 9장에서 사용했던 Result enum이 그 예입니다.

#![allow(unused)]
fn main() {
enum Result<T, E> {
    Ok(T),
    Err(E),
}
}

Result enum은 두 타입 T, E 에 대해 제네릭이며, Ok 와 Err 두 variant를 가집니다. Ok 는 T 타입 값 하나를 담고, Err 는 E 타입 값 하나를 담습니다. 이 정의 덕분에, 어떤 연산이 성공할 수도(T 타입 값 반환), 실패할 수도(E 타입의 에러 반환) 있는 상황 어디에서든 Result enum을 편리하게 사용할 수 있습니다. 실제로 이것이 우리가 목록 9-3에서 파일을 열 때 사용했던 방식입니다. 파일이 성공적으로 열리면 T 는 std::fs::File 로 채워지고, 열기에 문제가 생기면 E 는 std::io::Error 로 채워졌습니다.

여러 구조체나 enum 정의가 내부에 담은 값의 타입만 다르고 나머지는 비슷하다면, 제네릭 타입을 사용해 중복을 피할 수 있습니다.

메서드 정의에서의 제네릭

5장에서 했던 것처럼, 구조체와 enum 위에 메서드를 구현하면서 그 정의 안에서 제네릭 타입을 사용할 수도 있습니다. 목록 10-9는 목록 10-6의 Point<T> 구조체에 x 라는 메서드를 구현한 예입니다.

struct Point<T> {
    x: T,
    y: T,
}

impl<T> Point<T> {
    fn x(&self) -> &T {
        &self.x
    }
}

fn main() {
    let p = Point { x: 5, y: 10 };

    println!("p.x = {}", p.x());
}

여기서는 Point<T> 위에 x 라는 메서드를 정의했고, 이 메서드는 필드 x 안의 데이터에 대한 참조를 반환합니다.

여기서도 T 를 impl 뒤에 다시 선언해야 한다는 점에 주의하세요. 그래야 Point<T> 타입에 메서드를 구현하고 있다는 사실을 T 를 사용해 표현할 수 있습니다. impl 뒤에 T 를 제네릭 타입으로 선언함으로써, 러스트는 Point 의 꺾쇠 괄호 안에 있는 T 가 구체 타입이 아니라 제네릭 타입임을 알 수 있습니다. 물론 구조체 정의에서 사용한 것과 다른 이름을 써도 되지만, 같은 이름을 쓰는 것이 관례입니다. impl 안에 제네릭 타입을 선언한 메서드는, 그 제네릭 타입 자리에 어떤 구체 타입이 들어오든 그 타입의 모든 인스턴스에 대해 정의됩니다.

타입 위에 메서드를 정의할 때 제네릭 타입에 제한을 둘 수도 있습니다. 예를 들어 Point<T> 의 모든 인스턴스가 아니라, Point<f32> 인스턴스에만 메서드를 구현할 수 있습니다. 목록 10-10에서는 구체 타입 f32 를 사용하므로, impl 뒤에 어떤 타입도 선언하지 않습니다.

struct Point<T> {
    x: T,
    y: T,
}

impl<T> Point<T> {
    fn x(&self) -> &T {
        &self.x
    }
}

impl Point<f32> {
    fn distance_from_origin(&self) -> f32 {
        (self.x.powi(2) + self.y.powi(2)).sqrt()
    }
}

fn main() {
    let p = Point { x: 5, y: 10 };

    println!("p.x = {}", p.x());
}

이 코드는 Point<f32> 타입에는 distance_from_origin 메서드가 존재하지만, T 가 f32 가 아닌 다른 Point<T> 인스턴스에는 이 메서드가 없다는 뜻입니다. 이 메서드는 좌표 (0.0, 0.0) 으로부터 점이 얼마나 떨어져 있는지 측정하며, 부동소수점 타입에서만 가능한 수학 연산을 사용합니다.

구조체 정의에 쓰인 제네릭 타입 매개변수와, 그 구조체 메서드 시그니처에 쓰는 제네릭 매개변수는 항상 같을 필요는 없습니다. 목록 10-11은 예를 더 분명히 하기 위해 구조체 Point 에는 X1, Y1 을, mixup 메서드 시그니처에는 X2, Y2 를 사용합니다. 이 메서드는 self 의 Point(타입 X1) 에서 x 값을, 매개변수로 들어온 Point(타입 Y2) 에서 y 값을 가져와 새 Point 인스턴스를 만듭니다.

struct Point<X1, Y1> {
    x: X1,
    y: Y1,
}

impl<X1, Y1> Point<X1, Y1> {
    fn mixup<X2, Y2>(self, other: Point<X2, Y2>) -> Point<X1, Y2> {
        Point {
            x: self.x,
            y: other.y,
        }
    }
}

fn main() {
    let p1 = Point { x: 5, y: 10.4 };
    let p2 = Point { x: "Hello", y: 'c' };

    let p3 = p1.mixup(p2);

    println!("p3.x = {}, p3.y = {}", p3.x, p3.y);
}

main 안에서는 x 에 i32 값 5, y 에 f64 값 10.4 를 가진 Point 하나를 정의했습니다. p2 변수는 x 에 문자열 슬라이스 "Hello", y 에 문자 c 를 가진 Point 구조체입니다. p1 에 대해 p2 를 인수로 mixup 을 호출하면 p3 를 얻는데, x 는 p1 에서 왔기 때문에 i32, y 는 p2 에서 왔기 때문에 char 입니다. 그래서 println! 은 p3.x = 5, p3.y = c 를 출력합니다.

이 예제의 목적은, 어떤 제네릭 매개변수는 impl 뒤에 선언되고 어떤 것은 메서드 정의 뒤에 선언된다는 상황을 보여 주는 데 있습니다. 여기서 X1 과 Y1 은 구조체 정의와 함께 가기 때문에 impl 뒤에 선언되고, X2 와 Y2 는 그 메서드에서만 의미가 있기 때문에 fn mixup 뒤에 선언됩니다.

제네릭을 사용하는 코드의 성능

제네릭 타입 매개변수를 사용하면 런타임 비용이 생기는지 궁금할 수도 있습니다. 좋은 소식은, 제네릭 타입을 사용해도 프로그램은 구체 타입을 직접 썼을 때보다 느려지지 않는다는 점입니다.

러스트는 컴파일 시점에 제네릭 코드를 단형화(monomorphization) 하여 이를 해결합니다. 단형화 는 컴파일 시 사용된 구체 타입을 채워 넣어, 제네릭 코드를 구체 코드로 바꾸는 과정입니다. 이 과정에서 컴파일러는 우리가 목록 10-5의 제네릭 함수를 만들기 위해 수행했던 추상화의 반대 작업을 합니다. 즉, 제네릭 코드가 호출되는 모든 위치를 살펴보고, 그 호출에서 사용된 구체 타입에 대한 코드를 생성합니다.

표준 라이브러리의 제네릭 Option<T> enum을 예로 들어 이 동작을 살펴봅시다.

#![allow(unused)]
fn main() {
let integer = Some(5);
let float = Some(5.0);
}

러스트가 이 코드를 컴파일할 때 단형화를 수행합니다. 그 과정에서 컴파일러는 Option<T> 인스턴스에서 사용된 값을 읽고, 두 종류의 Option<T> 가 쓰였다는 사실을 알아냅니다. 하나는 i32, 다른 하나는 f64 입니다. 그래서 Option<T> 의 제네릭 정의를 i32 용과 f64 용 두 정의로 확장하여, 제네릭 정의를 구체적인 정의로 대체합니다.

단형화된 버전의 코드는 대략 다음과 비슷한 모습이 됩니다(여기서는 설명을 위해 컴파일러가 실제로 쓰는 이름과는 다른 이름을 사용합니다).

enum Option_i32 {
    Some(i32),
    None,
}

enum Option_f64 {
    Some(f64),
    None,
}

fn main() {
    let integer = Option_i32::Some(5);
    let float = Option_f64::Some(5.0);
}

즉, 제네릭 Option<T> 는 컴파일러가 만든 구체적인 정의들로 치환됩니다. 러스트는 제네릭 코드를 이렇게 각 인스턴스의 구체 타입을 명시한 코드로 컴파일하므로, 제네릭을 써도 런타임 비용을 치르지 않습니다. 실행 시에는 우리가 각 정의를 손으로 복붙해 쓴 것과 완전히 같은 방식으로 동작합니다. 단형화 과정 덕분에 러스트의 제네릭은 런타임에서 매우 효율적입니다.

트레이트로 공통 동작 정의하기

트레이트로 공통 동작 정의하기

트레이트(trait) 는 특정 타입이 가지는 기능을 정의하며, 그 기능을 다른 타입과 공유할 수 있게 해 줍니다. 트레이트를 사용하면 공통 동작을 추상적인 방식으로 정의할 수 있습니다. 또한 트레이트 바운드(trait bounds) 를 사용하면, 제네릭 타입이 “아무 타입이나” 가 아니라 어떤 특정 동작을 가진 타입만 받아들이도록 제한할 수 있습니다.

트레이트 정의하기

타입의 동작은 그 타입에 대해 호출할 수 있는 메서드들로 이루어집니다. 서로 다른 여러 타입에서 같은 메서드를 호출할 수 있다면, 그 타입들은 같은 동작을 공유한다고 할 수 있습니다. 트레이트 정의는 메서드 시그니처들을 한데 모아, 어떤 목적을 달성하기 위해 필요한 동작 집합을 정의하는 방법입니다.

예를 들어 서로 다른 종류와 길이의 텍스트를 담는 여러 구조체가 있다고 합시다. 하나는 특정 장소에서 작성된 뉴스 기사를 담는 NewsArticle 구조체이고, 다른 하나는 최대 280자까지의 글과 함께 새 글인지, 재게시인지, 답글인지 같은 메타데이터를 담는 SocialPost 구조체입니다.

우리는 이런 데이터들을 요약해서 보여 줄 수 있는 aggregator 라는 미디어 집계 라이브러리 크레이트를 만들고 싶습니다. 그렇게 하려면 각 타입에서 요약을 얻을 수 있어야 하고, 인스턴스에서 summarize 메서드를 호출해 그 요약을 받아오고 싶습니다. 목록 10-12는 이런 동작을 표현하는 public Summary 트레이트 정의를 보여 줍니다.

pub trait Summary {
    fn summarize(&self) -> String;
}

여기서는 trait 키워드와 트레이트 이름 Summary 를 사용해 트레이트를 선언합니다. 이 트레이트를 사용하는 다른 크레이트도 접근할 수 있도록 pub 으로 선언했다는 점도 주의하세요. 중괄호 안에는 이 트레이트를 구현하는 타입들이 가져야 할 동작을 설명하는 메서드 시그니처를 적습니다. 이 경우에는 fn summarize(&self) -> String 하나입니다.

메서드 시그니처 뒤에는 중괄호로 본문을 쓰는 대신 세미콜론만 붙입니다. 이 트레이트를 구현하는 각 타입은 이 메서드 본문에 대해 자기만의 구체적인 동작을 제공해야 합니다. 컴파일러는 Summary 트레이트를 구현한 어떤 타입이든 정확히 이 시그니처를 가진 summarize 메서드를 정의했는지 확인합니다.

하나의 트레이트는 여러 메서드를 가질 수도 있습니다. 시그니처를 한 줄에 하나씩 적고, 각 줄은 세미콜론으로 끝내면 됩니다.

타입 위에 트레이트 구현하기

이제 Summary 트레이트 메서드의 원하는 시그니처를 정의했으니, 이를 미디어 집계기 안의 각 타입에 구현할 수 있습니다. 목록 10-13은 NewsArticle 구조체에 대해 Summary 트레이트를 구현한 예를 보여 줍니다. 여기서는 제목, 작성자, 장소를 이용해 summarize 의 반환값을 만듭니다. SocialPost 구조체의 경우에는, 게시물 본문이 이미 280자로 제한된다고 가정하고 사용자 이름과 본문 전체를 이어 붙여 요약을 만듭니다.

pub trait Summary {
    fn summarize(&self) -> String;
}

pub struct NewsArticle {
    pub headline: String,
    pub location: String,
    pub author: String,
    pub content: String,
}

impl Summary for NewsArticle {
    fn summarize(&self) -> String {
        format!("{}, by {} ({})", self.headline, self.author, self.location)
    }
}

pub struct SocialPost {
    pub username: String,
    pub content: String,
    pub reply: bool,
    pub repost: bool,
}

impl Summary for SocialPost {
    fn summarize(&self) -> String {
        format!("{}: {}", self.username, self.content)
    }
}

타입 위에 트레이트를 구현하는 방식은 일반 메서드 구현과 비슷합니다. 차이점은 impl 뒤에 구현하려는 트레이트 이름을 쓰고, 그 뒤에 for 키워드, 그리고 트레이트를 구현할 타입 이름을 쓴다는 점입니다. impl 블록 안에는 트레이트 정의가 요구한 메서드 시그니처들을 적습니다. 단, 시그니처마다 세미콜론을 붙이는 대신 중괄호와 실제 메서드 본문을 넣어 그 타입에 맞는 구체 동작을 정의합니다.

이제 라이브러리는 NewsArticle 과 SocialPost 에 Summary 를 구현했으므로, 크레이트 사용자는 이 타입 인스턴스에서 일반 메서드처럼 트레이트 메서드를 호출할 수 있습니다. 차이가 있다면 사용자 쪽 코드도 타입과 함께 그 트레이트를 스코프로 가져와야 한다는 점입니다. 다음은 바이너리 크레이트가 우리 aggregator 라이브러리 크레이트를 사용하는 예입니다.

use aggregator::{SocialPost, Summary};

fn main() {
    let post = SocialPost {
        username: String::from("horse_ebooks"),
        content: String::from(
            "of course, as you probably already know, people",
        ),
        reply: false,
        repost: false,
    };

    println!("1 new post: {}", post.summarize());
}

이 코드는 1 new post: horse_ebooks: of course, as you probably already know, people 를 출력합니다.

aggregator 크레이트에 의존하는 다른 크레이트도 Summary 트레이트를 스코프로 가져와 자신만의 타입에 Summary 를 구현할 수 있습니다. 한 가지 제한이 있는데, 어떤 타입에 트레이트를 구현하려면 그 트레이트나 타입, 혹은 둘 다가 현재 크레이트 로컬이어야 합니다. 예를 들어 SocialPost 타입은 우리 aggregator 크레이트 안에 정의되어 있으므로, 표준 라이브러리 트레이트인 Display 를 SocialPost 에 구현할 수 있습니다. 반대로 Summary 트레이트는 우리 크레이트 안에 정의되었으므로, Vec<T> 같은 표준 라이브러리 타입에 대해서도 Summary 를 구현할 수 있습니다.

하지만 외부 트레이트를 외부 타입에 구현할 수는 없습니다. 예를 들어 Display 와 Vec<T> 는 둘 다 표준 라이브러리 안에 정의되어 있으므로, 우리 aggregator 크레이트 안에서 Vec<T> 에 Display 를 구현하는 것은 불가능합니다. 이 제약은 일관성(coherence) 이라고 하는 속성의 일부이며, 더 구체적으로는 고아 규칙(orphan rule) 이라고 부릅니다. 부모 타입이 현재 크레이트에 없기 때문에 붙은 이름입니다. 이 규칙 덕분에 다른 사람의 코드가 여러분의 코드를 망가뜨리거나, 그 반대가 되는 일을 막을 수 있습니다. 이 규칙이 없다면 두 크레이트가 같은 타입에 같은 트레이트를 구현할 수 있고, 그때 러스트는 어떤 구현을 사용해야 할지 알 수 없게 됩니다.

기본 구현 사용하기

때로는 트레이트의 모든 메서드에 대해 각 타입이 반드시 구현을 제공하게 하는 대신, 일부 또는 전부에 기본 동작을 제공하는 편이 유용합니다. 그러면 특정 타입에 트레이트를 구현할 때, 각 메서드의 기본 동작을 그대로 쓰거나 필요에 따라 덮어쓸 수 있습니다.

목록 10-14에서는, 목록 10-12처럼 summarize 메서드 시그니처만 두는 대신, Summary 트레이트의 summarize 메서드에 기본 문자열 구현을 제공합니다.

pub trait Summary {
    fn summarize(&self) -> String {
        String::from("(Read more...)")
    }
}

pub struct NewsArticle {
    pub headline: String,
    pub location: String,
    pub author: String,
    pub content: String,
}

impl Summary for NewsArticle {}

pub struct SocialPost {
    pub username: String,
    pub content: String,
    pub reply: bool,
    pub repost: bool,
}

impl Summary for SocialPost {
    fn summarize(&self) -> String {
        format!("{}: {}", self.username, self.content)
    }
}

NewsArticle 인스턴스에 대해 이 기본 구현을 사용하려면, impl Summary for NewsArticle {} 처럼 빈 impl 블록만 적으면 됩니다.

NewsArticle 위에 summarize 메서드를 직접 정의하지는 않았지만, 기본 구현을 제공했고 NewsArticle 이 Summary 트레이트를 구현한다고 명시했으므로, 우리는 여전히 NewsArticle 인스턴스에 대해 summarize 를 호출할 수 있습니다.

use aggregator::{self, NewsArticle, Summary};

fn main() {
    let article = NewsArticle {
        headline: String::from("Penguins win the Stanley Cup Championship!"),
        location: String::from("Pittsburgh, PA, USA"),
        author: String::from("Iceburgh"),
        content: String::from(
            "The Pittsburgh Penguins once again are the best \
             hockey team in the NHL.",
        ),
    };

    println!("New article available! {}", article.summarize());
}

이 코드는 New article available! (Read more...) 를 출력합니다.

기본 구현을 만들더라도, 목록 10-13에서 SocialPost 에 대해 했던 구현을 바꿀 필요는 없습니다. 기본 구현을 덮어쓰는 문법은, 애초에 기본 구현이 없는 트레이트 메서드를 구현하는 문법과 동일하기 때문입니다.

기본 구현은 같은 트레이트 안의 다른 메서드를 호출할 수도 있습니다. 그 다른 메서드가 기본 구현을 갖지 않아도 됩니다. 이런 방식으로 트레이트는 꽤 많은 유용한 기능을 제공하면서, 실제 구현자에게는 극히 일부만 정의하게 만들 수 있습니다. 예를 들어 Summary 트레이트에 구현이 필수인 summarize_author 메서드를 두고, 그 메서드를 호출하는 기본 구현을 가진 summarize 메서드를 다음처럼 정의할 수 있습니다.

pub trait Summary {
    fn summarize_author(&self) -> String;

    fn summarize(&self) -> String {
        format!("(Read more from {}...)", self.summarize_author())
    }
}

pub struct SocialPost {
    pub username: String,
    pub content: String,
    pub reply: bool,
    pub repost: bool,
}

impl Summary for SocialPost {
    fn summarize_author(&self) -> String {
        format!("@{}", self.username)
    }
}

이 버전의 Summary 를 사용하려면, 타입 위에 트레이트를 구현할 때 summarize_author 만 정의하면 됩니다.

pub trait Summary {
    fn summarize_author(&self) -> String;

    fn summarize(&self) -> String {
        format!("(Read more from {}...)", self.summarize_author())
    }
}

pub struct SocialPost {
    pub username: String,
    pub content: String,
    pub reply: bool,
    pub repost: bool,
}

impl Summary for SocialPost {
    fn summarize_author(&self) -> String {
        format!("@{}", self.username)
    }
}

이제 summarize_author 를 정의해 두었으므로, SocialPost 인스턴스에 대해 summarize 를 호출할 수 있습니다. Summary 트레이트의 기본 구현이 우리가 제공한 summarize_author 를 호출하기 때문입니다. 즉, summarize_author 만 구현하면 Summary 트레이트가 summarize 동작까지 제공해 주는 셈이고, 추가 코드를 더 쓸 필요가 없습니다. 실제로 쓰면 이런 모습입니다.

use aggregator::{self, SocialPost, Summary};

fn main() {
    let post = SocialPost {
        username: String::from("horse_ebooks"),
        content: String::from(
            "of course, as you probably already know, people",
        ),
        reply: false,
        repost: false,
    };

    println!("1 new post: {}", post.summarize());
}

이 코드는 1 new post: (Read more from @horse_ebooks...) 를 출력합니다.

한 가지 주의할 점은, 같은 메서드를 덮어쓴 구현 안에서 그 메서드의 기본 구현을 직접 호출하는 것은 불가능하다는 것입니다.

트레이트를 매개변수로 사용하기

이제 트레이트를 정의하고 구현하는 법을 알게 되었으니, 트레이트를 사용해 여러 타입을 받는 함수를 어떻게 정의하는지 살펴봅시다. 목록 10-13에서 NewsArticle 과 SocialPost 위에 구현한 Summary 트레이트를 이용해, item 매개변수에 대해 summarize 메서드를 호출하는 notify 함수를 정의해 보겠습니다. 이를 위해 impl Trait 문법을 사용합니다.

pub trait Summary {
    fn summarize(&self) -> String;
}

pub struct NewsArticle {
    pub headline: String,
    pub location: String,
    pub author: String,
    pub content: String,
}

impl Summary for NewsArticle {
    fn summarize(&self) -> String {
        format!("{}, by {} ({})", self.headline, self.author, self.location)
    }
}

pub struct SocialPost {
    pub username: String,
    pub content: String,
    pub reply: bool,
    pub repost: bool,
}

impl Summary for SocialPost {
    fn summarize(&self) -> String {
        format!("{}: {}", self.username, self.content)
    }
}

pub fn notify(item: &impl Summary) {
    println!("Breaking news! {}", item.summarize());
}

item 매개변수에 구체 타입을 적는 대신, impl 키워드와 트레이트 이름을 지정했습니다. 이 매개변수는 해당 트레이트를 구현하는 어떤 타입이든 받을 수 있습니다. notify 본문 안에서는 Summary 트레이트에서 온 메서드들, 예를 들어 summarize 를 item 에 대해 호출할 수 있습니다. 따라서 notify 에 NewsArticle 이나 SocialPost 인스턴스를 넘길 수 있습니다. 하지만 String 이나 i32 같은 타입은 Summary 를 구현하지 않았으므로, 그런 타입으로 호출하려 하면 컴파일되지 않습니다.

트레이트 바운드 문법

impl Trait 문법은 단순한 경우에는 아주 편리하지만, 사실은 트레이트 바운드 라는 더 긴 형태의 문법에 대한 설탕 문법입니다. 그 모습은 다음과 같습니다.

pub fn notify<T: Summary>(item: &T) {
    println!("Breaking news! {}", item.summarize());
}

이 긴 형태는 앞 절의 예제와 완전히 동등하지만 더 장황합니다. 트레이트 바운드는 제네릭 타입 매개변수 선언 뒤에 콜론을 붙이고 꺾쇠 괄호 안에서 지정합니다.

impl Trait 문법은 단순한 경우에 더 간결하게 코드를 쓰게 해 주고, 반면 전체 트레이트 바운드 문법은 더 복잡한 표현이 필요한 경우에 유용합니다. 예를 들어 Summary 를 구현하는 두 매개변수를 받는 함수를 정의할 수 있습니다. impl Trait 문법으로는 이렇게 씁니다.

pub fn notify(item1: &impl Summary, item2: &impl Summary) {

이 방식은 item1 과 item2 가 서로 다른 타입이어도 둘 다 Summary 만 구현하고 있으면 허용하고 싶을 때 적절합니다. 하지만 두 매개변수가 같은 타입이길 강제하고 싶다면, 다음처럼 트레이트 바운드를 사용해야 합니다.

pub fn notify<T: Summary>(item1: &T, item2: &T) {

item1 과 item2 의 타입으로 지정된 제네릭 타입 T 가 하나뿐이라는 사실이, 두 인수에 들어오는 실제 타입이 반드시 같아야 한다는 제약을 만들어 냅니다.

+ 문법으로 여러 트레이트 바운드 지정하기

하나 이상의 트레이트 바운드도 지정할 수 있습니다. 예를 들어 notify 가 item 에 대해 summarize 를 호출하는 동시에 출력 형식화도 하고 싶다고 해 봅시다. 그러면 item 이 Display 와 Summary 를 둘 다 구현해야 한다고 notify 정의에 적어 주면 됩니다. 이때 + 문법을 사용합니다.

pub fn notify(item: &(impl Summary + Display)) {

이 + 문법은 제네릭 타입에 대한 트레이트 바운드와 함께 쓸 때도 유효합니다.

pub fn notify<T: Summary + Display>(item: &T) {

이 두 바운드가 지정되면, notify 본문 안에서는 summarize 를 호출할 수 있고, {} 형식화를 사용해 item 을 출력할 수도 있습니다.

where 절로 트레이트 바운드 더 명확하게 쓰기

트레이트 바운드가 많아지면 단점도 생깁니다. 각 제네릭마다 자기 바운드가 있고, 여러 제네릭 타입 매개변수를 가진 함수는 함수 이름과 매개변수 목록 사이에 바운드 정보가 잔뜩 들어가서 시그니처를 읽기 어려워질 수 있습니다. 이를 위해 러스트는 함수 시그니처 뒤의 where 절 안에 트레이트 바운드를 적는 대체 문법을 제공합니다. 즉, 다음과 같이 쓰는 대신

fn some_function<T: Display + Clone, U: Clone + Debug>(t: &T, u: &U) -> i32 {

다음처럼 where 절을 쓸 수 있습니다.

fn some_function<T, U>(t: &T, u: &U) -> i32
where
    T: Display + Clone,
    U: Clone + Debug,
{
    unimplemented!()
}

이 함수 시그니처는 훨씬 덜 복잡해 보입니다. 함수 이름, 매개변수 목록, 반환 타입이 가깝게 모여 있어서, 트레이트 바운드가 많은 함수가 아닌 일반 함수처럼 읽히기 때문입니다.

트레이트를 구현하는 타입 반환하기

반환 위치에서도 impl Trait 문법을 사용하여, 어떤 트레이트를 구현하는 타입 값을 돌려줄 수 있습니다.

pub trait Summary {
    fn summarize(&self) -> String;
}

pub struct NewsArticle {
    pub headline: String,
    pub location: String,
    pub author: String,
    pub content: String,
}

impl Summary for NewsArticle {
    fn summarize(&self) -> String {
        format!("{}, by {} ({})", self.headline, self.author, self.location)
    }
}

pub struct SocialPost {
    pub username: String,
    pub content: String,
    pub reply: bool,
    pub repost: bool,
}

impl Summary for SocialPost {
    fn summarize(&self) -> String {
        format!("{}: {}", self.username, self.content)
    }
}

fn returns_summarizable() -> impl Summary {
    SocialPost {
        username: String::from("horse_ebooks"),
        content: String::from(
            "of course, as you probably already know, people",
        ),
        reply: false,
        repost: false,
    }
}

반환 타입으로 impl Summary 를 사용함으로써, returns_summarizable 함수가 Summary 트레이트를 구현하는 어떤 타입을 반환한다는 사실을 구체 타입 이름 없이 표현할 수 있습니다. 이 경우 returns_summarizable 은 SocialPost 를 반환하지만, 이 함수를 호출하는 코드가 그 사실을 알 필요는 없습니다.

반환 타입을 “어떤 트레이트를 구현하는 타입”으로만 지정할 수 있다는 점은 특히 클로저와 반복자 맥락에서 유용합니다. 이것들은 13장에서 다루는데, 클로저와 반복자는 컴파일러만 알 수 있거나 이름이 너무 길어서 일일이 적기 어려운 타입을 만들어 내기 때문입니다. impl Trait 문법은 함수가 Iterator 같은 트레이트를 구현하는 타입을 반환한다고 짧고 간결하게 적게 해 줍니다.

다만 impl Trait 는 오직 하나의 구체 타입만 반환할 때만 사용할 수 있습니다. 예를 들어 반환 타입을 impl Summary 로 지정해 놓고, 상황에 따라 NewsArticle 이나 SocialPost 를 반환하는 코드는 동작하지 않습니다.

pub trait Summary {
    fn summarize(&self) -> String;
}

pub struct NewsArticle {
    pub headline: String,
    pub location: String,
    pub author: String,
    pub content: String,
}

impl Summary for NewsArticle {
    fn summarize(&self) -> String {
        format!("{}, by {} ({})", self.headline, self.author, self.location)
    }
}

pub struct SocialPost {
    pub username: String,
    pub content: String,
    pub reply: bool,
    pub repost: bool,
}

impl Summary for SocialPost {
    fn summarize(&self) -> String {
        format!("{}: {}", self.username, self.content)
    }
}

fn returns_summarizable(switch: bool) -> impl Summary {
    if switch {
        NewsArticle {
            headline: String::from(
                "Penguins win the Stanley Cup Championship!",
            ),
            location: String::from("Pittsburgh, PA, USA"),
            author: String::from("Iceburgh"),
            content: String::from(
                "The Pittsburgh Penguins once again are the best \
                 hockey team in the NHL.",
            ),
        }
    } else {
        SocialPost {
            username: String::from("horse_ebooks"),
            content: String::from(
                "of course, as you probably already know, people",
            ),
            reply: false,
            repost: false,
        }
    }
}

NewsArticle 또는 SocialPost 둘 중 하나를 반환하는 것은, 컴파일러 안에서 impl Trait 문법이 구현되는 방식의 제약 때문에 허용되지 않습니다. 이런 동작을 하는 함수는 18장의 “공통 동작을 추상화하기 위해 트레이트 객체 사용하기” 절에서 작성하는 법을 다룹니다.

트레이트 바운드로 조건부 메서드 구현하기

제네릭 타입 매개변수를 사용하는 impl 블록에 트레이트 바운드를 걸면, 특정 트레이트를 구현하는 타입에 대해서만 메서드를 구현할 수 있습니다. 예를 들어 목록 10-15의 Pair<T> 타입은 항상 새 Pair<T> 인스턴스를 반환하는 new 함수를 구현합니다 (5장의 “메서드 문법” 절에서 보았듯, Self 는 impl 블록의 타입, 여기서는 Pair<T> 의 별칭입니다). 하지만 다음 impl 블록에서 Pair<T> 는 내부 타입 T 가 비교를 가능하게 하는 PartialOrd 와 출력을 가능하게 하는 Display 를 모두 구현한 경우에만 cmp_display 메서드를 구현합니다.

use std::fmt::Display;

struct Pair<T> {
    x: T,
    y: T,
}

impl<T> Pair<T> {
    fn new(x: T, y: T) -> Self {
        Self { x, y }
    }
}

impl<T: Display + PartialOrd> Pair<T> {
    fn cmp_display(&self) {
        if self.x >= self.y {
            println!("The largest member is x = {}", self.x);
        } else {
            println!("The largest member is y = {}", self.y);
        }
    }
}

또한 어떤 다른 트레이트를 구현하는 모든 타입에 대해, 특정 트레이트를 조건부로 구현할 수도 있습니다. 트레이트 바운드를 만족하는 모든 타입에 대한 이런 구현을 블랭킷 구현(blanket implementation) 이라고 하며, 러스트 표준 라이브러리에서 광범위하게 사용됩니다. 예를 들어 표준 라이브러리는 Display 를 구현하는 모든 타입에 대해 ToString 트레이트를 구현합니다. 표준 라이브러리 안의 impl 블록은 대략 다음과 비슷합니다.

impl<T: Display> ToString for T {
    // --snip--
}

표준 라이브러리에 이런 블랭킷 구현이 있기 때문에, Display 를 구현하는 모든 타입은 ToString 트레이트에 정의된 to_string 메서드를 사용할 수 있습니다. 예를 들어 정수는 Display 를 구현하므로, 다음처럼 정수를 대응하는 String 값으로 바꿀 수 있습니다.

#![allow(unused)]
fn main() {
let s = 3.to_string();
}

블랭킷 구현은 해당 트레이트 문서의 “Implementors” 섹션에서 확인할 수 있습니다.

트레이트와 트레이트 바운드를 사용하면, 제네릭 타입 매개변수를 활용해 중복을 줄이면서도 그 제네릭 타입이 특정 동작을 가져야 한다고 컴파일러에게 명시할 수 있습니다. 그러면 컴파일러는 이 트레이트 바운드 정보를 사용해, 실제로 우리 코드와 함께 쓰이는 모든 구체 타입이 올바른 동작을 제공하는지 검사할 수 있습니다. 동적 타입 언어에서는, 어떤 메서드를 구현하지 않은 타입에 대해 그 메서드를 호출하면 런타임에서야 오류를 보게 됩니다. 반면 러스트는 그런 오류를 컴파일 시점으로 끌어올려, 코드가 실행되기도 전에 반드시 고치게 만듭니다. 게다가 런타임에 동작 여부를 검사하는 코드를 우리가 직접 작성할 필요도 없습니다. 컴파일 시점에 이미 검사가 끝났기 때문입니다. 이런 방식은 제네릭의 유연성을 유지하면서도 성능을 떨어뜨리지 않습니다.

라이프타임으로 참조의 유효성 검증하기

라이프타임으로 참조의 유효성 검증하기

라이프타임은 우리가 이미 써 오고 있던 또 다른 종류의 제네릭입니다. 타입이 원하는 동작을 갖는지 보장하는 대신, 라이프타임은 참조가 필요한 만큼 오래 유효한지를 보장합니다.

4장의 “참조와 대여” 절에서는 설명하지 않았던 세부가 하나 있는데, 러스트의 모든 참조는 저마다의 라이프타임을 가진다는 점입니다. 라이프타임은 그 참조가 유효한 스코프를 뜻합니다. 대부분의 경우 라이프타임은 암묵적이고 추론됩니다. 타입이 대개 추론되는 것과 비슷합니다. 여러 타입이 가능할 때만 우리가 타입을 주석으로 적어 주어야 합니다. 마찬가지로 참조의 라이프타임이 여러 방식으로 관련될 수 있는 경우에만 라이프타임을 주석으로 명시해야 합니다. 러스트는 런타임에 실제로 사용되는 참조들이 확실히 유효하도록, 제네릭 라이프타임 매개변수로 참조들 사이 관계를 적어 주길 요구합니다.

라이프타임 주석은 대부분의 다른 프로그래밍 언어에는 없는 개념이므로 낯설게 느껴질 수 있습니다. 이 장에서 라이프타임 전체를 완전히 다루지는 않겠지만, 라이프타임 문법을 만날 수 있는 흔한 상황들을 설명해 개념에 익숙해지게 하겠습니다.

댕글링 참조

라이프타임의 주된 목적은 댕글링 참조를 막는 것입니다. 만약 허용된다면, 프로그램은 원래 의도한 데이터가 아닌 다른 데이터를 참조하게 될 수도 있습니다. 목록 10-16의 프로그램은 바깥 스코프와 안쪽 스코프를 함께 가지고 있습니다.

fn main() {
    let r;

    {
        let x = 5;
        r = &x;
    }

    println!("r: {r}");
}

바깥 스코프에는 초기값이 없는 r 이라는 변수가 선언되어 있고, 안쪽 스코프에는 초기값 5 를 가진 x 가 선언되어 있습니다. 안쪽 스코프에서 우리는 r 의 값을 x 에 대한 참조로 설정하려고 합니다. 그 뒤 안쪽 스코프는 끝나고, 바깥 스코프에서 r 의 값을 출력하려 합니다. 이 코드는 컴파일되지 않습니다. r 이 참조하는 값이 우리가 r 을 사용하기도 전에 스코프를 벗어나 버리기 때문입니다. 오류 메시지는 다음과 같습니다.

$ cargo run
   Compiling chapter10 v0.1.0 (file:///projects/chapter10)
error[E0597]: `x` does not live long enough
 --> src/main.rs:6:13
  |
5 |         let x = 5;
  |             - binding `x` declared here
6 |         r = &x;
  |             ^^ borrowed value does not live long enough
7 |     }
  |     - `x` dropped here while still borrowed
8 |
9 |     println!("r: {r}");
  |                   - borrow later used here

For more information about this error, try `rustc --explain E0597`.
error: could not compile `chapter10` (bin "chapter10") due to 1 previous error

오류 메시지는 변수 x 가 “충분히 오래 살지 않는다”고 말합니다. 이유는 안쪽 스코프가 7번째 줄에서 끝날 때 x 도 스코프를 벗어나기 때문입니다. 하지만 r 은 바깥 스코프에 있어 더 오래 유효합니다. 그래서 우리는 r 이 “더 오래 산다”고 말합니다. 만약 러스트가 이 코드를 허용했다면, r 은 x 가 스코프를 벗어날 때 이미 해제된 메모리를 가리키게 되었을 것이고, 그 뒤 r 에 대해 무엇을 하든 올바르게 동작하지 않았을 것입니다. 그렇다면 러스트는 어떻게 이 코드가 잘못되었다는 것을 알까요? 대여 검사기를 사용합니다.

대여 검사기

러스트 컴파일러에는 모든 대여가 유효한지 확인하기 위해 스코프를 비교하는 대여 검사기(borrow checker) 가 있습니다. 목록 10-17은 목록 10-16과 같은 코드에, 변수 라이프타임을 주석으로 표시한 버전입니다.

fn main() {
    let r;                // ---------+-- 'a
                          //          |
    {                     //          |
        let x = 5;        // -+-- 'b  |
        r = &x;           //  |       |
    }                     // -+       |
                          //          |
    println!("r: {r}");   //          |
}                         // ---------+

여기서는 r 의 라이프타임을 'a, x 의 라이프타임을 'b 라고 표시했습니다. 보시다시피 안쪽 'b 블록은 바깥쪽 'a 라이프타임 블록보다 훨씬 작습니다. 컴파일 시점에 러스트는 두 라이프타임 크기를 비교하고, r 은 'a 라이프타임을 가지지만 가리키는 메모리는 'b 라이프타임을 가진다는 사실을 확인합니다. 그래서 프로그램을 거부합니다. 'b 가 'a 보다 짧기 때문입니다. 참조 대상이 참조보다 오래 살지 못하는 것입니다.

목록 10-18은 댕글링 참조가 없도록 코드를 고친 버전이며, 오류 없이 컴파일됩니다.

fn main() {
    let x = 5;            // ----------+-- 'b
                          //           |
    let r = &x;           // --+-- 'a  |
                          //   |       |
    println!("r: {r}");   //   |       |
                          // --+       |
}                         // ----------+

여기서는 x 의 라이프타임 'b 가 'a 보다 더 길기 때문에, r 이 x 를 참조해도 문제가 없습니다. 러스트는 x 가 유효한 동안 r 안의 참조도 항상 유효하다는 사실을 알고 있습니다.

이제 참조의 라이프타임이 무엇이고, 러스트가 라이프타임을 분석해 참조가 언제나 유효하도록 어떻게 보장하는지 알게 되었으니, 함수 매개변수와 반환값에서 제네릭 라이프타임을 어떻게 사용하는지 살펴보겠습니다.

함수에서의 제네릭 라이프타임

문자열 슬라이스 두 개 중 더 긴 쪽을 반환하는 함수를 작성해 보겠습니다. 이 함수는 두 개의 문자열 슬라이스를 받아 하나의 문자열 슬라이스를 반환할 것입니다. longest 함수를 구현하고 나면, 목록 10-19의 코드는 The longest string is abcd 를 출력해야 합니다.

fn main() {
    let string1 = String::from("abcd");
    let string2 = "xyz";

    let result = longest(string1.as_str(), string2);
    println!("The longest string is {result}");
}

이 함수가 문자열 자체가 아니라 문자열 슬라이스, 즉 참조를 받는다는 점에 주목하세요. 우리는 longest 가 인수의 소유권을 가져가길 원하지 않기 때문입니다. 왜 이런 매개변수를 원하는지에 대해서는 4장의 [“문자열 슬라이스를 매개변수로 받기”] string-slices-as-parameters 절을 떠올려 보세요.

만약 목록 10-20처럼 longest 함수를 구현하려 하면, 이 코드는 컴파일되지 않습니다.

fn main() {
    let string1 = String::from("abcd");
    let string2 = "xyz";

    let result = longest(string1.as_str(), string2);
    println!("The longest string is {result}");
}

fn longest(x: &str, y: &str) -> &str {
    if x.len() > y.len() { x } else { y }
}

대신 우리는 라이프타임에 대해 이야기하는 다음과 같은 오류를 얻게 됩니다.

$ cargo run
   Compiling chapter10 v0.1.0 (file:///projects/chapter10)
error[E0106]: missing lifetime specifier
 --> src/main.rs:9:33
  |
9 | fn longest(x: &str, y: &str) -> &str {
  |               ----     ----     ^ expected named lifetime parameter
  |
  = help: this function's return type contains a borrowed value, but the signature does not say whether it is borrowed from `x` or `y`
help: consider introducing a named lifetime parameter
  |
9 | fn longest<'a>(x: &'a str, y: &'a str) -> &'a str {
  |           ++++     ++          ++          ++

For more information about this error, try `rustc --explain E0106`.
error: could not compile `chapter10` (bin "chapter10") due to 1 previous error

도움말은 반환 타입에 제네릭 라이프타임 매개변수가 필요하다고 알려 줍니다. 러스트는 반환되는 참조가 x 를 가리키는지, 아니면 y 를 가리키는지 알 수 없기 때문입니다. 사실 우리도 함수 정의만 보고는 알 수 없습니다. 이 함수 본문에서 if 블록은 x 를, else 블록은 y 를 반환하기 때문입니다.

이 함수를 정의하는 시점에서는 실제로 어떤 값이 이 함수에 들어올지 모르므로, if 분기가 실행될지 else 분기가 실행될지도 알 수 없습니다. 또한 들어올 참조들의 구체적인 라이프타임도 모르기 때문에, 목록 10-17과 10-18에서처럼 단순히 스코프를 보고 반환될 참조가 언제나 유효한지 판단할 수 없습니다. 대여 검사기도 마찬가지로 이를 알 수 없습니다. x, y 의 라이프타임이 반환값 라이프타임과 어떤 관계인지 모르기 때문입니다. 이 오류를 고치기 위해, 참조들 사이 관계를 정의하는 제네릭 라이프타임 매개변수를 추가해 대여 검사기가 분석할 수 있게 해야 합니다.

라이프타임 주석 문법

라이프타임 주석은 참조가 실제로 얼마나 오래 사는지를 바꾸지 않습니다. 대신 여러 참조의 라이프타임이 서로 어떤 관계를 갖는지를 설명할 뿐입니다. 이는 라이프타임 자체에는 영향을 주지 않습니다. 함수 시그니처가 제네릭 타입 매개변수 덕분에 어떤 타입이든 받을 수 있는 것처럼, 제네릭 라이프타임 매개변수를 지정하면 어떤 라이프타임을 가진 참조든 받아들일 수 있습니다.

라이프타임 주석은 약간 특이한 문법을 가집니다. 라이프타임 매개변수 이름은 작은따옴표 (') 로 시작해야 하고, 보통 모두 소문자이며 매우 짧습니다. 제네릭 타입 이름처럼, 대부분의 사람은 첫 번째 라이프타임 주석 이름으로 'a 를 사용합니다. 라이프타임 매개변수 주석은 참조의 & 뒤에 두고, 참조 타입과는 공백으로 구분합니다.

다음은 예시입니다. 라이프타임 매개변수가 없는 i32 참조, 'a 라는 라이프타임을 가진 i32 참조, 그리고 같은 'a 라이프타임을 가진 가변 i32 참조입니다.

&i32        // a reference
&'a i32     // a reference with an explicit lifetime
&'a mut i32 // a mutable reference with an explicit lifetime

라이프타임 주석 하나만 떼어 놓고 보면 큰 의미는 없습니다. 주석의 목적은 여러 참조의 제네릭 라이프타임 매개변수들 사이 관계를 러스트에게 알려 주는 데 있기 때문입니다. 이제 longest 함수 맥락에서 라이프타임 주석들이 서로 어떻게 관련되는지 봅시다.

함수 시그니처에서의 라이프타임

함수 시그니처에서 라이프타임 주석을 사용하려면, 함수 이름과 매개변수 목록 사이의 꺾쇠 괄호 안에 제네릭 라이프타임 매개변수를 선언해야 합니다. 이는 제네릭 타입 매개변수를 선언할 때와 같습니다.

우리는 이 시그니처가 다음 제약을 표현하길 원합니다. “반환되는 참조는 두 매개변수가 모두 유효한 동안에만 유효하다.” 즉, 매개변수의 라이프타임과 반환값 라이프타임 사이 관계를 표현하고 싶은 것입니다. 이를 위해 라이프타임 이름을 'a 로 정하고, 모든 참조에 같은 이름을 붙입니다. 목록 10-21을 보세요.

fn main() {
    let string1 = String::from("abcd");
    let string2 = "xyz";

    let result = longest(string1.as_str(), string2);
    println!("The longest string is {result}");
}

fn longest<'a>(x: &'a str, y: &'a str) -> &'a str {
    if x.len() > y.len() { x } else { y }
}

이 코드는 목록 10-19의 main 함수와 함께 사용하면 정상적으로 컴파일되고, 원하는 결과를 출력합니다.

이제 함수 시그니처는 러스트에게 “어떤 라이프타임 'a 에 대해, 함수는 그 라이프타임 이상 살아 있는 문자열 슬라이스 두 개를 받고, 반환값 역시 최소한 'a 동안 살아 있는 문자열 슬라이스다”라고 말하고 있습니다. 실제로는, longest 함수가 반환하는 참조의 라이프타임은 함수 인수들이 가리키는 두 값의 라이프타임 중 더 짧은 쪽과 같다는 뜻입니다. 이것이 바로 우리가 러스트가 이 코드를 분석할 때 사용하길 원하는 관계입니다.