5.4 명시적 오류 처리 모델(Result<T, E>)의 실용성 재고

러스트는 Result<T, E> 열거형과 패턴 매칭, ? 연산자를 통해 컴파일 시점에 오류 처리를 강제하는 명시적 오류 처리 모델을 채택하고 있습니다. 이 모델은 오류 처리 누락을 방지하는 기능을 합니다. 본 절에서는 이 모델의 실용성을 분석하기 위해, 대안적인 오류 처리 방식과의 비교, 개념의 역사적 기원, 그리고 실제 사용 시 발생하는 비용을 분석합니다.

1. 대안적 모델과의 비교: try-catch 예외 처리

러스트의 Result 모델을 논의할 때, try-catch 기반의 예외 처리 모델은 종종 예측 불가능한 제어 흐름으로 인해 비판의 대상이 됩니다. 그러나 예외 처리 메커니즘은 다음과 같은 공학적 특징을 가집니다.

• 관심사의 분리(separation of concerns): try 블록에는 정상적인 로직을, catch 블록에는 예외 상황 처리를 분리하여 기술할 수 있습니다. 오류가 발생한 지점에서 이를 처리할 지점까지 제어 흐름을 즉시 전달하므로, 여러 함수 단계를 거치며 오류를 수동으로 전파하는(return Err(...)) 방식을 피할 수 있습니다.
• 컴파일 시점 검사: 어떤 예외가 발생할지 모른다는 비판은 모든 경우에 해당하지 않습니다. 예를 들어, 자바(Java)의 '체크 예외(Checked Exception)'는 함수가 던질 수 있는 예외를 시그니처에 명시하도록 하고, 컴파일러가 그 처리를 강제합니다. 이는 오류 누락을 방지한다는 목표를 Result 타입과 다른 방식으로 달성하는 사례입니다.
• 시스템 회복력(resilience): 예외 처리 시스템은 오류 기록(logging), 자원 해제(finally), 그리고 오류 복구 로직을 통해 프로그램의 비정상적인 중단을 막고 서비스의 운영을 지속하는 데 역할을 합니다.

2. 개념의 역사적 기원: 함수형 프로그래밍

Result와 Option을 통한 명시적 오류 및 상태 처리 방식은 러스트 고유의 것이 아니며, 기존에 존재하던 개념을 차용한 것입니다. 이 아이디어의 뿌리는 함수형 프로그래밍(functional programming) 진영에 있습니다.

하스켈(Haskell)의 Maybe a, Either a b 타입이나 OCaml, F#과 같은 ML 계열 언어의 합 타입(Sum Type)은 수십 년 전부터 값의 부재나 오류 상태를 타입 시스템으로 표현하고, 컴파일러가 모든 경우를 처리하도록 강제하는 방식을 사용해왔습니다.

따라서 러스트의 기여는 이 개념을 '발명'한 것이라기보다, 시스템 프로그래밍 언어의 맥락에 맞게 '재해석'하고 ? 연산자와 같은 문법적 편의성을 통해 '대중화'한 데에 있다고 분석될 수 있습니다.

3. 실용적 비용: 오류 타입 변환의 장황함(verbosity)

? 연산자는 동일한 오류 타입을 전파하는 시나리오에서는 사용되지만, 다양한 외부 라이브러리를 사용하는 실제 애플리케이션에서는 한계를 보입니다. 각기 다른 라이브러리는 자신만의 고유한 오류 타입(예: std::io::Error, sqlx::Error)을 반환하며, 개발자는 이들을 애플리케이션의 단일한 오류 타입으로 변환해주는 상용구 코드(boilerplate code)를 반복적으로 작성해야 합니다.

// 여러 다른 종류의 오류를 단일 애플리케이션 오류 타입으로 변환하는 예시
fn load_config_and_user(id: Uuid) -> Result<Config, MyAppError> {
    let file_content = fs::read_to_string("config.toml")
        .map_err(MyAppError::Io)?; // std::io::Error -> MyAppError

    let config: Config = toml::from_str(&file_content)
        .map_err(MyAppError::Toml)?; // toml::de::Error -> MyAppError

    // ...
    Ok(config)
}

이러한 반복적인 변환을 해소하기 위해 anyhow, thiserror와 같은 외부 라이브러리가 사용됩니다. 그러나 생태계에서 특정 기능(이 경우, 유연한 오류 처리)을 위해 외부 라이브러리 사용이 사실상 표준처럼 여겨진다는 사실은, 언어의 기본 기능만으로 실용적인 애플리케이션 개발 시 추가적인 요구사항이 있음을 시사합니다.

4. 사례 연구: Cloudflare 장애와 unwrap()의 사용

러스트의 오류 처리 모델이 실제 운영 환경에서 어떻게 작용하는지는 2025년 11월 발생한 Cloudflare의 서비스 중단 사고를 통해 확인할 수 있습니다.¹ 이 사고는 Result 타입을 반환하는 함수에서 에러 케이스를 match나 ? 연산자로 처리하지 않고, unwrap()을 사용하여 패닉(panic)이 발생했기 때문입니다.

러스트는 Result 타입을 통해 개발자가 오류를 명시적으로 처리하도록 강제합니다. 그러나 동시에 unwrap()이라는 메서드를 통해 그 강제성을 우회할 수 있는 수단을 제공합니다. 이론적으로 unwrap()은 프로토타이핑이나 테스트 코드에 주로 사용되지만, 실제 개발 과정에서는 복잡한 에러 처리 로직을 작성하는 비용을 줄이기 위해 프로덕션 코드에서도 사용되는 경우가 있습니다.

이 사례는 언어의 강제성이 개발자의 편의성을 우선시하는 선택을 완전히 배제할 수 없음을 시사합니다. 컴파일러가 규칙을 강제하더라도, 개발자가 구현 편의를 위해 안전장치를 우회하는 경로(unwrap)를 선택한다면, 그 결과는 시스템 중단으로 이어질 수 있습니다. 이는 러스트의 '강제적 안전성' 모델이 실제 엔지니어링 현장의 인적 요인(Human Factor)과 결합될 때 발생할 수 있는 한계를 보여주는 사례입니다.