파일 기반 모듈 분리

지금까지 6장의 예제는 파일 하나에 모듈을 여럿 정의했습니다. 모듈이 커지면 정의를 다른 파일로 옮겨 코드를 찾기 쉽게 하고 싶어집니다. 이 글에서는 use 키워드로 경로를 스코프 안으로 가져오기의 마지막 레스토랑 코드에서 시작해, 크레이트 루트 파일에 모두 정의했던 모듈을 파일로 하나씩 옮겨 봅니다. 여기서는 크레이트 루트가 src/lib.rs이지만, 크레이트 루트가 src/main.rs인 바이너리 크레이트에서도 똑같이 할 수 있습니다.

모듈을 파일로 옮기기

먼저 front_of_house 모듈을 파일로 옮깁니다. front_of_house 모듈의 중괄호 안의 코드를 지우고 mod front_of_house; 선언만 남겨, src/lib.rs를 다음과 같이 만듭니다. 이 상태로는 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();
}

그다음 중괄호 안에 있던 코드를 새 파일 src/front_of_house.rs로 옮깁니다. 크레이트 루트에서 front_of_house라는 모듈 선언을 만났으므로, 컴파일러는 이 파일에서 모듈의 본문을 찾습니다.

pub mod hosting {
    pub fn add_to_waitlist() {}
}

mod 선언으로 파일을 불러오는 일은 모듈 트리에서 한 번만 하면 됩니다. 그 파일이 프로젝트의 일부라는 것과 모듈 트리의 어디에 있는지를 컴파일러가 알게 되면, 다른 파일에서는 모듈 경로와 아이템 참조에서 본 것처럼 그 모듈이 선언된 곳의 경로로 그 안의 코드를 가리킵니다. 곧 mod는 다른 언어에서 보는 파일 포함(include) 연산이 아닙니다.

다음으로 hosting 모듈을 파일로 옮깁니다. hosting은 루트 모듈이 아니라 front_of_house의 자식이므로 과정이 조금 다릅니다. hosting의 파일은 모듈 트리에서 그 조상의 이름을 딴 새 폴더, 여기서는 src/front_of_house 폴더에 둡니다. 먼저 src/front_of_house.rs에는 hosting 모듈의 선언만 남깁니다.

pub mod hosting;

그리고 src/front_of_house 폴더를 만들고, 그 안의 hosting.rs 파일에 hosting 모듈의 본문을 적습니다. 파일 자체가 모듈의 중괄호 역할을 하므로, 파일에는 mod hosting과 중괄호 없이 그 안에 있던 내용만 옮깁니다.

pub fn add_to_waitlist() {}

hosting.rs를 src 폴더에 바로 두면, 컴파일러는 그 코드를 크레이트 루트에 선언된 hosting 모듈로 여기고 front_of_house의 자식으로 보지 않습니다. 지금의 mod hosting; 선언은 front_of_house 안에 있으므로 컴파일러는 src/front_of_house 폴더에서 찾습니다. 어떤 모듈의 코드를 어느 파일에서 찾을지 정하는 컴파일러의 규칙 덕분에 폴더와 파일의 구조가 모듈 트리와 비슷하게 맞춰집니다.

대체 파일 경로

지금까지는 러스트 컴파일러가 쓰는 가장 관례적인 파일 경로를 보았지만, 러스트는 예전 방식의 파일 경로도 지원합니다. 크레이트 루트에 선언된 front_of_house 모듈의 본문은 다음 두 곳에서 찾습니다.

같은 모듈에 두 방식을 함께 쓰면 컴파일 오류가 납니다. 한 프로젝트에서 모듈마다 다른 방식을 섞어 쓰는 것은 허용되지만, 프로젝트를 읽는 사람이 헷갈릴 수 있습니다. mod.rs 방식의 가장 큰 단점은 프로젝트에 mod.rs라는 이름의 파일이 많아져, 편집기에서 여러 개를 함께 열었을 때 구분하기 어렵다는 것입니다. 기본 경로 대신 다른 파일을 쓰려면 #[path = "..."] 속성으로 직접 지정할 수도 있습니다.

파일을 나눠도 같은 모듈 트리

이제 각 모듈의 코드를 다른 파일로 옮겼지만 모듈 트리는 그대로입니다. 아래 그림처럼 한 파일에 모두 있던 때와 파일을 나눈 뒤의 모듈 트리는 crate에서 front_of_house, hosting, add_to_waitlist로 이어지는 같은 모양이며, 달라진 것은 각 모듈의 본문이 놓인 파일뿐입니다.

// src/lib.rs
mod front_of_house;

// src/front_of_house.rs
pub mod hosting;

mod front_of_house;

mod hosting;

// src/lib.rs
#[path = "front.rs"]
mod front_of_house;

use module::item;

pub use module::item;

그래서 정의가 다른 파일에 있어도 eat_at_restaurant 안의 함수 호출은 고치지 않고 그대로 동작합니다. 이 방법으로 모듈이 커질 때마다 새 파일로 옮길 수 있습니다. src/lib.rs의 pub use crate::front_of_house::hosting 문장도 바꾸지 않았다는 점에 주목합니다. 본문 없는 mod는 모듈을 선언하고 관례적인 경로에서 본문을 찾는 반면, use는 이미 선언된 아이템의 이름을 지금의 스코프에 묶고, pub use는 그 이름을 새 공개 경로로 내보낼 뿐입니다. use는 크레이트의 일부로 컴파일될 파일에 아무 영향도 주지 않습니다.

세 파일 src/lib.rs, src/front_of_house.rs, src/front_of_house/hosting.rs를 저장하고 cargo check를 실행하면, 컴파일러는 mod 선언을 따라 두 파일을 읽어 같은 모듈 트리를 만듭니다. 호출까지 확인하려면 같은 패키지에 다음 src/main.rs를 더합니다.

fn main() {
    println!("before");
    restaurant::eat_at_restaurant();
    restaurant::hosting::add_to_waitlist();
    println!("after");
}

before
after

add_to_waitlist의 본문은 비어 있으므로, 호출을 둘러싼 before와 after 두 줄만 출력됩니다. 바이너리는 바깥 크레이트이므로 pub use가 만든 restaurant::hosting 경로로 함수를 부릅니다. 모듈의 소스 파일을 찾는 규칙은 Reference의 모듈 소스 파일에 정리되어 있습니다.

모듈 요약

러스트에서는 패키지를 여러 크레이트로, 크레이트를 여러 모듈로 나누고, 한 모듈에 정의한 아이템을 절대 경로나 상대 경로로 다른 모듈에서 가리킬 수 있습니다. 이런 경로를 use로 스코프에 가져오면, 그 스코프에서 아이템을 여러 번 쓸 때 짧은 이름을 쓸 수 있습니다. 모듈의 코드는 기본으로 비공개이지만, pub을 붙여 정의를 공개할 수 있습니다.

정리

• mod 이름;만 남기고 본문을 이름.rs로 옮기면, 컴파일러가 그 파일에서 모듈의 본문을 찾습니다.
• 자식 모듈의 파일은 부모 모듈의 이름을 딴 폴더에 두며, src/front_of_house/hosting.rs처럼 모듈 트리를 따라 놓입니다.
• mod는 파일을 포함하는 연산이 아니며, 한 모듈은 트리에서 한 번만 선언합니다.
• 예전 방식의 mod.rs도 지원하지만 같은 모듈에 두 방식을 함께 쓸 수는 없고, #[path]로 경로를 직접 정할 수도 있습니다.
• 파일을 나눠도 모듈 트리와 경로는 그대로이므로 호출 코드와 use, pub use를 고칠 필요가 없습니다.

연습 문제

1. 파일 문제인가 공개 문제인가

세 파일 배치로 되돌린 뒤 다음 변경을 하나씩 적용합니다. 각각 어떻게 되나요? (가) hosting.rs를 src/hosting.rs로 옮기고 선언은 그대로 둔다. (나) src/front_of_house.rs를 그대로 두고 src/front_of_house/mod.rs도 만든다. (다) src/lib.rs의 pub use crate::front_of_house::hosting;을 use crate::front_of_house::hosting;으로 바꾼다.

2. 새 모듈을 파일로 만들기

front_of_house에 serving 모듈을 더해 그 안에 pub fn take_order() {}를 두려 합니다. 지금의 파일 배치를 따른다면 무엇을 어디에 적어야 하나요?

이것으로 6장을 마칩니다. 다음 장의 벡터와 값 목록에서는 이렇게 정리한 코드에서 쓸 표준 라이브러리의 컬렉션 자료 구조를 살펴봅니다.