1. 러스트 언어 소개 및 주요 특징

이 장에서는 러스트(Rust) 언어의 설계 철학과 이를 구현하는 기술적 특징들을 분석합니다. 논의는 러스트가 대응하고자 한 시스템 프로그래밍 분야의 문제, 즉 '성능'과 '안전성'의 상충 관계를 살펴보는 것에서 시작합니다.

이어서, 이 목표를 달성하기 위해 러스트가 도입한 메모리 관리 모델(소유권, 빌림, 생명주기), C++의 계보를 잇는 '무비용 추상화' 원칙, 타입 시스템을 통한 안전성 확보 방식, 그리고 이를 뒷받침하는 표준화된 개발 도구 생태계 순으로 그 주요 특징을 검토합니다.

1.1 탄생 배경: '성능'과 '안전성'의 상충 관계

프로그래밍 언어는 각기 다른 이유를 가지고 개발되지만, 러스트(Rust)는 기존 패러다임에 새로운 방식으로 접근하여 주목을 받았습니다. 러스트의 개발 배경을 이해하기 위해서는, 시스템 프로그래밍 분야에서 오랫동안 논의되어 온 선택의 문제를 살펴볼 필요가 있습니다.

과거 저수준(low-level) 시스템 개발자들은 '성능'과 '안전성' 사이에서 선택을 해야 하는 상황에 놓였습니다. 한쪽에는 C/C++와 같은 언어가 있었습니다. 이들은 하드웨어를 직접 제어하여 높은 수준의 성능과 제어권을 제공했으나, 세그멘테이션 폴트(segmentation fault), 버퍼 오버플로(buffer overflow), 데이터 경쟁(data race)과 같은 메모리 오류의 처리 책임을 프로그래머에게 부여했습니다. 다른 한편에는 Ada처럼 언어 차원에서 높은 수준의 안전성과 예측 가능성을 추구하며 특정 고신뢰성 시스템 분야에서 사용되어 온 언어가 존재했습니다. 또 다른 사례로는 Java나 C#과 같은 가비지 컬렉터(GC) 기반의 언어들이 있었습니다. 이들은 자동 메모리 관리를 통해 메모리 안전성을 제공했지만, GC의 런타임 오버헤드와 동작의 예측 불가능성으로 인해 실시간 시스템이나 운영체제 커널과 같은 일부 시스템 영역에서는 사용이 제한되었습니다.

모질라(Mozilla)의 연구 프로젝트로 시작된 러스트는 '성능과 안전성'의 상충 관계를 해결하려는 목표를 가지고 개발되었습니다. 즉, C++ 수준의 성능을 가지면서도, GC 없이 메모리 안전성을 보장하는 언어를 만들고자 한 것입니다. 이 목표를 달성하기 위해, 러스트는 설계 초기부터 안전성, 성능, 동시성이라는 핵심 목표를 설정했습니다.

안전성 (safety)

러스트의 핵심 설계 원칙 중 하나는 메모리 안전성입니다. 컴파일 시점에 코드의 메모리 사용 규칙을 검사하여, 메모리 오류로 인해 발생할 수 있는 프로그램의 비정상적 종료, 데이터 오염, 시스템 제어권 탈취와 같은 문제들을 방지하는 것을 목표로 합니다. 이는 프로그래머의 실수 가능성을 줄이기 위해, 컴파일러가 오류가 발생할 수 있는 코드의 컴파일을 차단하는 접근법입니다.

성능 (performance)

러스트는 시스템 프로그래밍 언어를 지향하며, 성능을 핵심 목표 중 하나로 삼았습니다. GC와 같은 런타임에 의존하지 않고, 하드웨어의 성능을 효율적으로 사용할 수 있도록 설계되었습니다. '무비용 추상화(Zero-Cost Abstractions)' 원칙은, 개발자가 고수준의 추상화 기능을 사용하더라도 추가적인 런타임 비용이 발생하지 않도록 보장하는 러스트의 설계 원칙을 나타냅니다.

동시성 (concurrency)

멀티코어 프로세서 환경에서, 여러 스레드가 충돌 없이 데이터를 공유하도록 작성하는 것은 복잡한 문제입니다. 러스트는 언어의 소유권 시스템을 통해, 컴파일 시점에 '데이터 경쟁'과 같은 동시성 관련 오류를 찾아내고 방지합니다. 이를 통해 개발자들은 '두려움 없는 동시성(fearless concurrency)'이라는 개념을 경험할 수 있습니다. 여기서 '두려움 없는'이란, 데이터 경쟁과 같은 특정 유형의 버그가 컴파일러에 의해 방지된다는 기술적 보장을 바탕으로, 개발자가 동시성 코드를 작성할 수 있음을 의미합니다.

결론적으로, '왜 러스트인가?'라는 질문은 이 세 가지 목표의 교차점에서 설명될 수 있습니다. 러스트는 성능, 안전성, 동시성이라는, 이전에는 동시에 달성하기 어려웠던 가치들을 하나의 언어 안에서 구현하려는 시도입니다. 이 목표를 달성하기 위해, 러스트는 '소유권'이라는 개념을 언어의 핵심 기능으로 도입했습니다.

1.2 소유권, 빌림, 생명주기를 통한 메모리 관리

러스트의 목표인 '가비지 컬렉터(GC) 없는 메모리 안전성'은 기존 방식과 구별됩니다. C/C++의 수동 관리는 오류 발생 가능성이 있으며, Java의 GC는 런타임 오버헤드를 수반합니다. 러스트는 이 문제를 해결하기 위해, 런타임이 아닌 컴파일 타임에 메모리 관리 규칙을 강제하는 시스템을 도입했습니다. 이는 소유권(ownership), 빌림(borrowing), 생명주기(lifetimes)라는 세 가지 개념으로 구성됩니다.

1. 소유권 (ownership): 모든 값에는 소유자가 있다

러스트의 메모리 관리는 '소유권' 규칙을 기반으로 합니다.

• 모든 값(value)은 단 하나의 소유자(owner) 변수만을 가집니다.
• 소유자가 스코프(scope, 유효 범위)를 벗어나면, 그 값은 자동으로 메모리에서 해제(drop)됩니다.
• 소유권은 다른 변수로 '이동(move)'될 수 있으며, 이동 후 원래의 소유자는 더 이상 유효하지 않습니다.

이 규칙들은 '이중 해제(double free)' 오류를 방지합니다. 또한, 소유권이 이동하면 이전 변수는 사용할 수 없으므로 '해제 후 사용(use-after-free)' 오류가 컴파일 시점에 방지됩니다.

2. 빌림 (borrowing): 소유권 없이 접근하기

소유권 이동만이 유일한 데이터 전달 방식일 경우, 비효율이 발생할 수 있습니다. 이를 해결하기 위해 러스트는 '빌림' 개념을 제공합니다. 이는 데이터의 소유권을 넘기지 않고, 특정 스코프 내에서 데이터에 대한 접근 권한(참조, reference)을 일시적으로 허용하는 것입니다.

'빌림'에는 다음과 같은 규칙이 적용됩니다.

• 특정 데이터에 대해, 여러 개의 '읽기 전용 빌림(immutable borrow, &T)'은 동시에 존재할 수 있습니다.
• '수정 가능한 빌림(mutable borrow, &mut T)'은 단 하나만 존재할 수 있으며, 이 빌림이 유효한 기간에는 다른 빌림이 허용되지 않습니다.

컴파일러는 이 규칙을 통해, 하나의 데이터에 대해 동시 수정 시도나 읽기와 수정의 동시 시도를 컴파일 시점에 차단합니다. 이것이 러스트가 '데이터 경쟁(data race)'을 방지하는 원리입니다.

3. 생명주기 (lifetimes): 빌린 데이터의 유효 기간 보장

'생명주기'는 '빌림(참조)'이 유효한 스코프, 즉 '생존 기간'을 컴파일러에 명시하는 역할을 합니다.

컴파일러는 생명주기 분석을 통해, 빌려온 데이터가 소유자에 의해 먼저 해제되어 발생하는 '댕글링 포인터(dangling pointer)' 문제를 방지합니다. 즉, 데이터의 실제 생존 기간보다, 그것을 빌려온 참조의 생존 기간이 더 길어지는 상황을 허용하지 않습니다. 컴파일러가 생명주기를 자동으로 추론하는 경우가 많으나, 추론이 어려운 경우 개발자가 명시적으로 생명주기를 지정할 수 있습니다.

이 세 가지 개념, 즉 소유권으로 자원의 생애를 관리하고, 빌림으로 데이터 접근을 제어하며, 생명주기로 댕글링 포인터를 방지하는 시스템은 '빌림 검사기(borrow checker)'라는 컴파일러의 일부에 의해 강제됩니다. 이 검사기는 '성능 저하 없는 안전성'을 구현하는 메커니즘입니다.

1.3 무비용 추상화(Zero-Cost Abstractions)의 계보

고수준 추상화와 저수준 제어

프로그래밍 언어에서 '추상화 수준'과 '성능'은 상충 관계에 있는 것으로 인식되어 왔습니다. 파이썬(Python)이나 자바(Java) 같은 고수준 언어는 개발자에게 추상화 기능을 제공하지만, 고수준 기능을 사용할수록 런타임 비용(overhead)이 발생하는 경향이 있었습니다. 반대로 C언어와 같은 저수준 언어는 상대적으로 높은 성능을 제공했지만, 개발자는 수동으로 메모리 등을 제어해야 했으며, 이는 코드의 가독성 및 유지보수성에 영향을 미칠 수 있었습니다.

C++과 러스트는 이 상충 관계에 대해 사용하지 않는 것에 대해서는 비용을 지불하지 않는다는 철학을 제시합니다. 이것은 '무비용 추상화(Zero-Cost Abstractions, ZCA)' 원칙입니다. ZCA란, 개발자가 이터레이터(iterator), 제네릭(generics), 트레잇(trait) 등 고수준 추상화 기능을 사용해 코드를 작성하더라도, 컴파일된 최종 결과물은 저수준에서 수동으로 최적화한 코드와 동일하거나 유사한 성능을 내는 것을 목표로 하는 원칙입니다.

이 원칙의 기원은 C언어에서 찾을 수 있습니다. C는 struct를 통해 개발자가 메모리 레이아웃을 제어하게 하고, inline 함수나 매크로를 통해 함수 호출 비용을 줄이는 등, 프로그래머가 수동으로 비용 없는 코드를 작성할 수 있는 수단을 제공했습니다. 예를 들어, sizeof 연산자를 사용하여 자료구조의 메모리 크기를 컴파일 타임에 계산하거나, #define 매크로를 활용하여 코드를 컴파일 전에 확장시키는 방식은 런타임 오버헤드 없이 특정 기능을 구현하는 C의 초기 ZCA 형태라 할 수 있습니다.

C++은 이 기반 위에 언어 차원의 추상화를 구축했습니다. 핵심 요소는 템플릿(templates)과 RAII(자원 획득은 초기화다)였습니다.

• 템플릿은 타입 검사를 수행하며 컴파일 시점에 여러 타입에 대한 코드를 생성합니다.
• RAII는 소멸자를 통해 자원 관리를 자동화하는 패턴입니다.

러스트는 C/C++의 ZCA 철학을 계승하며, '소유권' 시스템을 도입했습니다. 즉, 추상화에 대한 비용을 런타임이 아닌 컴파일 타임에 처리하여 성능 저하를 최소화하는 동시에, 빌림 검사기를 통해 추상화가 메모리 안전 규칙을 준수하도록 강제하는 것입니다.

대표적인 예는 이터레이터입니다.

// 1부터 99까지의 숫자 중, 3의 배수만 골라 제곱한 값들의 합을 구하는 코드
let sum = (1..100).filter(|&x| x % 3 == 0).map(|x| x * x).sum::<u32>();

이 코드는 filter, map, sum과 같은 고수준 메서드를 연쇄적으로 사용하여 작업을 선언적으로 기술합니다. C언어에서는 for 루프와 if 조건문, 별도의 합계 변수를 사용하는 명령형 방식이 일반적입니다. 러스트 컴파일러는 이 고수준 이터레이터 코드를 최적화하여, 수동으로 작성한 for 루프와 유사한 성능의 기계 코드를 생성합니다. filter나 map과 같은 중간 단계의 호출 비용은 컴파일 과정에서 인라이닝 등을 통해 제거될 수 있으며, 또한 메모리 접근이 컴파일 시점에 안전한지 검사합니다.

이러한 컴파일 시점 최적화는 러스트의 타입 시스템과 제네릭, 그리고 컴파일러의 인라이닝(inlining)과 모노모피제이션(monomorphization) 같은 기술을 통해 이루어집니다. 이는 런타임 비용을 줄이는 대신 컴파일 타임에 더 많은 처리를 수행하는 방식입니다.

1.4 타입 시스템과 패턴 매칭을 통한 안전성 확보

컴파일 시점의 오류 검사

러스트의 '안전성'은 메모리 관리 외의 영역을 포함합니다. 러스트는 정적 타입 시스템(static type system)을 통해, 프로그램이 처할 수 있는 다양한 상태와 오류 가능성을 코드 수준에서 명시적으로 표현하고, 컴파일러가 이를 강제하도록 설계되었습니다. 이는 잠재적인 런타임 오류를 컴파일 시점에 발견하여, 프로그램의 안정성을 높이는 방식입니다. 이 방식은 러스트의 타입 시스템과 패턴 매칭(pattern matching)을 기반으로 합니다.

러스트 타입 시스템의 특징 중 하나는 열거형(enum)입니다. 일부 언어의 enum이 상수를 나열하는 용도로 사용되는 것과 달리, 러스트의 enum은 각 변형(variant)이 서로 다른 타입과 개수의 데이터를 포함할 수 있는 데이터 구조입니다. 러스트는 이를 활용하여 프로그램의 불확실한 상태를 다룹니다.

대표적인 예는 Option<T> 타입이며, 이는 널 포인터(null pointer) 관련 문제를 처리하기 위해 사용됩니다. 러스트에는 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!("숫자가 없습니다."),
}

이처럼 프로그래머가 특정 상태나 오류 케이스 처리를 누락하는 경우, 컴파일러가 오류를 발생시켜 이를 방지합니다.

요컨대, 러스트의 타입 시스템은 프로그램의 상태를 명시적으로 모델링하게 하고, 패턴 매칭은 그 모든 상태가 처리되도록 강제합니다. 이는 런타임(runtime)에 발생할 수 있는 오류를 컴파일 시점에 발견하려는 러스트의 설계 원칙을 보여주는 예입니다.

1.5 생태계: 카고(Cargo)와 크레이트(Crates.io)

빌드 시스템과 패키지 매니저

프로그래밍 언어의 채택에는 언어 자체의 특징 외에 생태계와 도구가 영향을 미칩니다. C/C++와 같은 일부 시스템 프로그래밍 언어들은 공식 지정된 패키지 관리자나 빌드 시스템이 부재하여, 개발자들이 프로젝트마다 다른 도구(Makefile, CMake 등)를 사용하고 의존성을 관리하는 경우가 있었습니다.

러스트는 언어 설계 시점에 개발 환경 관련 도구를 제공하는 것을 목표 중 하나로 설정했습니다. 그 결과물은 공식 빌드 시스템 겸 패키지 매니저인 카고(Cargo)와 공식 패키지 저장소인 크레이트(Crates.io)입니다.

카고는 코드 컴파일을 포함하여 프로젝트 생명주기를 관리하는 커맨드 라인 도구입니다. 개발자는 명령어를 통해 다음 작업을 수행할 수 있습니다.

• 프로젝트 생성 (cargo new): 표준화된 디렉터리 구조를 가진 새로운 프로젝트를 생성합니다.
• 의존성 관리: cargo.toml 설정 파일에 필요한 라이브러리(러스트에서는 '크레이트'로 지칭)의 이름과 버전을 명시하면, 카고가 해당 라이브러리와 그 하위 의존성을 다운로드하고 관리합니다.
• 빌드 및 실행 (cargo build, cargo run): 명령어를 통해 프로젝트를 컴파일하고 실행합니다.
• 테스트 및 문서화 (cargo test, cargo doc): 프로젝트에 포함된 테스트 코드를 실행하고, 소스코드 주석을 바탕으로 HTML 문서를 생성합니다.

크레이트(Crates.io)는 Node.js의 NPM이나 파이썬의 PyPI와 유사한 중앙 집중형 패키지 저장소입니다. 이곳은 러스트 개발자들이 라이브러리를 공유하고 사용할 수 있는 플랫폼 역할을 합니다.

카고는 프로젝트 설정, 의존성 관리, 빌드, 테스트 과정을 표준화된 도구로 통합하여, 개발 환경 설정 및 의존성 관리의 부담을 줄이는 것을 목표로 합니다.