1.4. 강력한 타입 시스템과 패턴 매칭

컴파일 시점에 에러를 잡아내는 엄격함

러스트가 추구하는 ‘안전성’은 단순히 메모리 관리에만 국한되지 않습니다. 러스트는 언어의 근간을 이루는 정적 타입 시스템(static type system)을 통해, 프로그램이 처할 수 있는 다양한 상태와 오류 가능성을 코드 수준에서 명시적으로 표현하고, 컴파일러가 이를 강제하도록 설계되었습니다. 이는 잠재적인 런타임 오류를 컴파일 시점에 미리 발견하여, 프로그램의 전체적인 안정성을 극대화하는 핵심적인 전략입니다. 이 전략의 중심에는 러스트의 강력한 타입 시스템, 그리고 그것을 효과적으로 다루는 패턴 매칭(pattern matching)에 있습니다.

러스트의 타입 시스템에서 가장 빛을 발하는 부분은 바로 열거형(enum)입니다. 다른 언어에서 단순히 몇 가지 상수를 나열하는 용도로 쓰이는 enum과 달리, 러스트의 enum은 각 변형(variant)이 서로 다른 타입과 개수를 담을 수 있는 유연한 데이터 구조입니다. 러스트는 이를 활용하여 프로그램의 불확실한 상태를 매우 안전하게 다룹니다.

대표적인 예가 바로 널 포인터(null pointer) 문제를 해결한 Option<T> 타입입니다. 러스트에는 null이 존재하지 않습니다. 대신, 값이 있을 수도 있고 없을 수도 있는 상황을 Some(value) 또는 None이라는 두 가지 상태를 가진 Option 열거형으로 표현합니다. 이렇게 함으로써, 컴파일러는 개발자가 None일 경우를 반드시 처리하도록 강제하여, ‘null 포인터 역참조’와 같은 런타임 오류를 원천적으로 불가능하게 만듭니다. 마찬가지로, 성공 또는 실패 가능성이 있는 연산은 Result<T, E> 타입을 통해 Ok(value) 또는 Err(error) 상태를 명시적으로 반환하도록 하여, 오류 처리를 누락하는 실수를 방지합니다.

이러한 강력한 타입을 안전하고 편리하게 다루게 해주는 도구가 바로 패턴 매칭입니다. 러스트의 match 표현식은 Option이나 Result와 같은 열거형의 모든 가능한 경우를 남김없이 검사하도록 컴파일러가 강제합니다. 이를 소진 검사(exhaustiveness checking)라고 합니다.

let maybe_number: Option<i32> = Some(10);

// `match` 표현식은 모든 가능한 경우를 빠짐없이 검사하도록 강제하는데,

// 이를 '소진 검사(exhaustiveness checking)'라고 합니다.

// 따라서 `None` 경우를 처리하는 코드를 빠뜨리면 컴파일 에러가 발생합니다.

match maybe_number {

    Some(number) => println!("숫자: {}", number),

    None => println!("숫자가 없습니다."),

}

이처럼 프로그래머가 특정 상태나 오류 케이스를 처리하는 것을 잊어버리는 흔한 실수를, 컴파일러가 “당신은 이 경우를 빠뜨렸습니다”라고 친절하게 알려주며 막아주는 것입니다.

요컨대, 러스트의 강력한 타입 시스템은 프로그램의 상태를 명시적으로 모델링하게 하고, 패턴 매칭은 그 모든 상태를 빠짐없이 안전하게 처리하도록 강제합니다. 이는 “컴파일러를 까다로운 조력자로 삼아, 런타임에 발생할 수 있는 수많은 잠재적 버그를 컴파일 시점에 미리 박멸하는 것”이라는 러스트의 핵심 설계 철학을 보여주는 대표적인 예입니다.