이미지 로딩 중...
AI Generated
2025. 11. 13. · 5 Views
Rust 제네릭 함수 완벽 가이드
Rust의 제네릭 함수를 사용하여 타입에 안전하면서도 재사용 가능한 코드를 작성하는 방법을 알아봅니다. 기본 문법부터 트레이트 바운드, 실무 활용 패턴까지 단계별로 학습합니다.
목차
- 제네릭 함수 기본 개념 - 타입에 독립적인 함수 작성하기
- 트레이트 바운드 기초 - 제네릭 타입에 제약 추가하기
- where 절 활용 - 복잡한 트레이트 바운드 깔끔하게 작성하기
- 다중 제네릭 타입 - 여러 타입 매개변수 활용하기
- 제네릭 구조체와 메서드 - 재사용 가능한 데이터 타입 만들기
- 제네릭 열거형 - 여러 상태를 타입 안전하게 표현하기
- 라이프타임과 제네릭 결합 - 참조를 안전하게 사용하기
- const 제네릭 - 컴파일 타임 상수를 타입 매개변수로
1. 제네릭 함수 기본 개념 - 타입에 독립적인 함수 작성하기
시작하며
여러분이 두 정수를 교환하는 함수를 작성했는데, 문자열이나 실수를 교환하는 함수도 필요한 상황을 겪어본 적 있나요? 매번 타입별로 똑같은 로직의 함수를 복사-붙여넣기 하는 것은 비효율적이고 유지보수도 어렵습니다.
이런 문제는 실제 개발 현장에서 자주 발생합니다. 동일한 로직이지만 다른 타입에 대해 적용해야 할 때마다 중복 코드가 늘어나고, 나중에 로직을 수정할 때 모든 함수를 찾아서 고쳐야 하는 번거로움이 생깁니다.
바로 이럴 때 필요한 것이 제네릭 함수입니다. 제네릭을 사용하면 하나의 함수로 여러 타입을 처리할 수 있어 코드 중복을 줄이고 타입 안전성을 유지하면서 재사용성을 극대화할 수 있습니다.
개요
간단히 말해서, 제네릭 함수는 구체적인 타입 대신 타입 매개변수를 사용하여 여러 타입에 대해 동작할 수 있는 함수입니다. 제네릭은 코드 재사용성과 타입 안전성을 동시에 제공합니다.
컴파일 타임에 타입이 결정되므로 런타임 오버헤드가 없고, 컴파일러가 타입 체크를 해주므로 안전합니다. 예를 들어, 데이터 구조를 조작하거나 알고리즘을 구현할 때 같은 로직을 여러 타입에 적용해야 하는 경우에 매우 유용합니다.
기존에는 i32, f64, String 등 각 타입마다 별도의 함수를 작성해야 했다면, 이제는 하나의 제네릭 함수로 모든 타입을 처리할 수 있습니다. 제네릭 함수의 핵심 특징은 첫째, 컴파일 타임 타입 체크로 안전성을 보장하고, 둘째, 단형성화(monomorphization)를 통해 런타임 성능 손실이 없으며, 셋째, 코드 중복을 크게 줄일 수 있다는 점입니다.
이러한 특징들이 Rust를 안전하면서도 효율적인 시스템 프로그래밍 언어로 만드는 핵심 요소입니다.
코드 예제
// 제네릭 타입 T를 받아 두 값을 교환하는 함수
fn swap<T>(a: &mut T, b: &mut T) {
std::mem::swap(a, b);
}
fn main() {
// 정수 교환
let mut x = 5;
let mut y = 10;
swap(&mut x, &mut y);
println!("x: {}, y: {}", x, y); // x: 10, y: 5
// 문자열 교환
let mut s1 = String::from("hello");
let mut s2 = String::from("world");
swap(&mut s1, &mut s2);
println!("s1: {}, s2: {}", s1, s2); // s1: world, s2: hello
}
설명
이것이 하는 일: 제네릭 함수는 함수 이름 뒤에 꺾쇠괄호 <T>를 사용하여 타입 매개변수를 선언하고, 함수 본문에서 그 타입을 사용합니다. 컴파일러는 함수가 호출될 때마다 구체적인 타입에 대한 코드를 생성합니다.
첫 번째로, fn swap<T>는 제네릭 타입 매개변수 T를 선언합니다. 이 T는 함수가 호출될 때 실제 타입으로 대체될 자리표시자입니다.
매개변수 a: &mut T, b: &mut T는 같은 타입 T의 가변 참조 두 개를 받습니다. 이렇게 하는 이유는 값을 직접 교환하려면 소유권을 가져와야 하지만, 참조를 사용하면 호출자가 원본 값을 계속 사용할 수 있기 때문입니다.
그 다음으로, 함수 본문에서 std::mem::swap(a, b)가 실행되면서 두 참조가 가리키는 값을 안전하게 교환합니다. 내부에서는 임시 메모리를 사용하여 값을 복사하지 않고 메모리 상의 위치만 바꾸므로 효율적입니다.
제네릭이므로 T가 어떤 타입이든 동일한 방식으로 동작합니다. 마지막으로, main 함수에서 swap(&mut x, &mut y)를 호출하면 컴파일러는 T를 i32로 구체화한 swap::<i32> 버전을 생성하고, swap(&mut s1, &mut s2)를 호출하면 T를 String으로 구체화한 swap::<String> 버전을 생성하여 최종적으로 각 타입에 최적화된 코드를 만들어냅니다.
여러분이 이 코드를 사용하면 타입별로 중복된 swap 함수를 작성할 필요가 없어지고, 컴파일 타임 타입 체크로 안전성을 보장받으며, 런타임 성능 오버헤드 없이 효율적인 코드를 실행할 수 있습니다. 또한 새로운 타입에 대해서도 추가 코드 없이 바로 사용할 수 있어 확장성이 뛰어납니다.
실전 팁
💡 제네릭 타입 매개변수는 관례적으로 T, U, V 등 대문자 한 글자를 사용하지만, 의미 있는 이름(예: TKey, TValue)을 사용하면 가독성이 향상됩니다.
💡 제네릭 함수를 작성할 때 흔히 하는 실수는 타입 T에 대해 사용할 수 없는 연산을 시도하는 것입니다. 예를 들어 a + b를 하려면 T가 Add 트레이트를 구현해야 합니다.
💡 성능 측면에서 제네릭은 단형성화를 통해 각 타입별 코드를 생성하므로 런타임 오버헤드가 없지만, 컴파일된 바이너리 크기는 증가할 수 있습니다.
💡 디버깅 시 cargo expand나 cargo-show-asm을 사용하면 제네릭이 어떻게 구체화되는지 확인할 수 있어 이해에 도움이 됩니다.
💡 여러 제네릭 타입이 필요하면 fn example<T, U>(a: T, b: U)처럼 쉼표로 구분하여 선언하고, 각각 독립적인 타입으로 사용할 수 있습니다.
2. 트레이트 바운드 기초 - 제네릭 타입에 제약 추가하기
시작하며
여러분이 두 값 중 큰 값을 반환하는 제네릭 함수를 만들려고 했는데, 컴파일 에러가 발생한 경험이 있나요? "cannot compare T with T"라는 에러 메시지를 보고 당황했을 것입니다.
이런 문제는 제네릭 타입이 너무 일반적이어서 어떤 연산이 가능한지 컴파일러가 알 수 없기 때문에 발생합니다. 모든 타입이 비교 가능한 것은 아니므로, 컴파일러는 안전을 위해 이를 허용하지 않습니다.
바로 이럴 때 필요한 것이 트레이트 바운드입니다. 트레이트 바운드를 사용하면 제네릭 타입이 특정 기능을 반드시 구현하도록 강제할 수 있어, 타입 안전성을 유지하면서 필요한 연산을 수행할 수 있습니다.
개요
간단히 말해서, 트레이트 바운드는 제네릭 타입 매개변수가 특정 트레이트를 구현해야 한다는 제약 조건입니다. 트레이트 바운드는 제네릭의 유연성과 타입 안전성 사이의 균형을 제공합니다.
무제한적인 제네릭은 너무 추상적이어서 유용한 작업을 할 수 없지만, 트레이트 바운드를 추가하면 해당 트레이트의 메서드를 안전하게 사용할 수 있습니다. 예를 들어, 정렬 알고리즘을 구현할 때 요소들이 비교 가능해야 하므로 Ord 트레이트 바운드가 필요합니다.
기존에는 제네릭 함수 내에서 타입 T로 할 수 있는 작업이 거의 없었다면, 이제는 트레이트 바운드를 통해 T가 가진 능력을 명시하고 그에 따른 연산을 수행할 수 있습니다. 트레이트 바운드의 핵심 특징은 첫째, 컴파일 타임에 타입이 요구사항을 만족하는지 검증하고, 둘째, 명시적으로 타입의 능력을 문서화하며, 셋째, 트레이트의 메서드를 안전하게 호출할 수 있다는 점입니다.
이러한 특징들이 Rust의 제네릭 시스템을 강력하고 안전하게 만듭니다.
코드 예제
// PartialOrd 트레이트를 구현한 타입만 받는 제네릭 함수
fn find_larger<T: PartialOrd>(a: T, b: T) -> T {
if a > b {
a
} else {
b
}
}
fn main() {
// 정수 비교
let max_num = find_larger(10, 20);
println!("더 큰 수: {}", max_num); // 20
// 실수 비교
let max_float = find_larger(3.14, 2.71);
println!("더 큰 실수: {}", max_float); // 3.14
// 문자열 비교도 가능 (PartialOrd 구현됨)
let max_str = find_larger("apple", "banana");
println!("사전순으로 뒤: {}", max_str); // banana
}
설명
이것이 하는 일: 트레이트 바운드는 제네릭 타입 매개변수 뒤에 콜론과 트레이트 이름을 추가하여 해당 타입이 반드시 그 트레이트를 구현해야 함을 명시합니다. 컴파일러는 함수 호출 시 전달된 타입이 요구사항을 만족하는지 검증합니다.
첫 번째로, fn find_larger<T: PartialOrd>는 타입 T가 PartialOrd 트레이트를 구현해야 한다고 선언합니다. PartialOrd는 부분 순서 비교를 가능하게 하는 트레이트로, >, <, >=, <= 연산자를 사용할 수 있게 합니다.
이렇게 바운드를 지정하면 함수 본문에서 a > b 비교를 안전하게 할 수 있습니다. 그 다음으로, 함수 본문에서 if a > b가 실행될 때 컴파일러는 T가 PartialOrd를 구현한다는 것을 알고 있으므로 비교 연산을 허용합니다.
내부적으로는 PartialOrd의 partial_cmp 메서드가 호출되어 두 값을 비교하고, 그 결과에 따라 더 큰 값을 반환합니다. 만약 PartialOrd를 구현하지 않은 타입을 전달하면 컴파일 에러가 발생합니다.
마지막으로, main 함수에서 다양한 타입으로 호출하면 컴파일러는 각 타입이 PartialOrd를 구현하는지 확인합니다. i32, f64, &str 모두 PartialOrd를 구현하므로 컴파일이 성공하고, 각 타입에 최적화된 비교 코드가 생성되어 최종적으로 효율적인 실행 파일을 만들어냅니다.
여러분이 이 코드를 사용하면 타입 안전성을 유지하면서 다양한 타입에 대해 비교 연산을 수행할 수 있고, 컴파일 타임에 잘못된 타입 사용을 방지할 수 있으며, 명시적인 트레이트 바운드로 함수의 요구사항을 명확히 문서화할 수 있습니다. 또한 IDE에서 자동완성과 타입 힌트를 받을 수 있어 개발 생산성이 향상됩니다.
실전 팁
💡 여러 트레이트 바운드가 필요하면 <T: PartialOrd + Clone + Debug>처럼 +로 연결하거나, where 절을 사용하여 where T: PartialOrd + Clone처럼 작성하면 가독성이 좋습니다.
💡 흔한 실수는 Copy 트레이트가 없는 타입을 값으로 반환하려는 것입니다. 위 예제에서 String을 사용하면 소유권 이동 문제가 발생하므로 참조를 반환하거나 Clone을 요구해야 합니다.
💡 성능상 트레이트 바운드는 정적 디스패치를 사용하므로 trait object(&dyn Trait)보다 빠르지만, 코드 크기는 증가할 수 있습니다. 성능이 중요하면 제네릭을, 바이너리 크기가 중요하면 trait object를 고려하세요.
💡 디버깅 시 println!("{:?}", value)를 사용하려면 T가 Debug 트레이트를 구현해야 하므로, 개발 중에는 <T: PartialOrd + Debug>처럼 Debug를 추가하면 편리합니다.
💡 표준 라이브러리의 일반적인 트레이트 바운드 패턴을 익히세요. Clone, Copy, Debug, Display, PartialEq, PartialOrd 등은 매우 자주 사용됩니다.
3. where 절 활용 - 복잡한 트레이트 바운드 깔끔하게 작성하기
시작하며
여러분이 제네릭 함수에 여러 개의 트레이트 바운드를 추가하다 보니 함수 시그니처가 한 줄에 다 들어가지 않을 정도로 길어진 경험이 있나요? fn process<T: Clone + Debug + PartialOrd, U: Display + Default>처럼 복잡해지면 가독성이 크게 떨어집니다.
이런 문제는 복잡한 제네릭 코드에서 흔히 발생합니다. 시그니처가 길어지면 코드를 읽기 어려워지고, 함수의 본질적인 역할이 가려지며, 유지보수가 힘들어집니다.
바로 이럴 때 필요한 것이 where 절입니다. where 절을 사용하면 트레이트 바운드를 함수 시그니처에서 분리하여 훨씬 읽기 쉬운 코드를 작성할 수 있습니다.
개요
간단히 말해서, where 절은 제네릭 타입의 트레이트 바운드를 함수 시그니처 뒤에 별도로 명시하는 문법입니다. where 절은 복잡한 제네릭 코드의 가독성을 크게 향상시킵니다.
함수 이름과 매개변수를 먼저 보고, 그 다음에 타입 제약사항을 확인할 수 있어 코드의 의도를 파악하기 쉽습니다. 예를 들어, 여러 제네릭 타입과 각각의 복잡한 바운드가 있는 함수를 작성할 때 where 절을 사용하면 구조가 명확해집니다.
기존에는 모든 트레이트 바운드를 꺾쇠괄호 안에 빼곡히 넣어야 했다면, 이제는 where 절로 분리하여 각 타입의 요구사항을 명확하게 나열할 수 있습니다. where 절의 핵심 특징은 첫째, 함수 시그니처와 트레이트 바운드를 분리하여 가독성을 높이고, 둘째, 복잡한 바운드 조건을 여러 줄로 나누어 작성할 수 있으며, 셋째, 연관 타입에 대한 바운드처럼 꺾쇠괄호로 표현할 수 없는 제약도 명시할 수 있다는 점입니다.
이러한 특징들이 대규모 프로젝트에서 제네릭 코드의 유지보수성을 크게 향상시킵니다.
코드 예제
use std::fmt::{Debug, Display};
// where 절을 사용한 깔끔한 함수 시그니처
fn compare_and_print<T, U>(first: T, second: U) -> bool
where
T: PartialOrd + Debug + Clone,
U: Display + Default + PartialEq,
{
println!("First value: {:?}", first);
println!("Second value: {}", second);
// 각 타입의 트레이트 메서드 사용 가능
let cloned = first.clone();
let default_u = U::default();
second == default_u
}
fn main() {
let result = compare_and_print(42, "Hello");
println!("Is default? {}", result); // false
}
설명
이것이 하는 일: where 절은 함수의 반환 타입 뒤, 중괄호 앞에 위치하며, 각 제네릭 타입 매개변수에 대한 트레이트 바운드를 명시합니다. 컴파일러는 where 절의 조건을 동일하게 검증하지만, 코드의 구조가 훨씬 명확해집니다.
첫 번째로, fn compare_and_print<T, U>(first: T, second: U) -> bool는 제네릭 타입 T와 U를 선언하지만, 여기서는 트레이트 바운드를 명시하지 않습니다. 함수 시그니처가 간결해져서 함수가 무엇을 하는지 한눈에 파악할 수 있습니다.
이렇게 하는 이유는 복잡한 바운드 조건이 시그니처를 어지럽히지 않도록 하기 위함입니다. 그 다음으로, where 절에서 T: PartialOrd + Debug + Clone과 U: Display + Default + PartialEq를 각각 별도의 줄로 명시합니다.
내부에서는 컴파일러가 이 조건들을 검증하고, 함수 본문에서 first.clone(), {:?} 포맷, U::default() 등의 트레이트 메서드를 안전하게 사용할 수 있게 합니다. 각 타입의 요구사항이 명확히 분리되어 있어 이해하기 쉽습니다.
마지막으로, 함수 본문에서 각 트레이트의 기능을 활용합니다. println!("{:?}", first)는 Debug를, clone()은 Clone을, println!("{}", second)는 Display를 사용하며, 최종적으로 모든 타입 제약이 만족되었을 때만 컴파일이 성공하여 안전한 코드를 만들어냅니다.
여러분이 이 코드를 사용하면 복잡한 제네릭 함수도 읽기 쉬운 형태로 작성할 수 있고, 각 타입의 요구사항을 명확히 파악할 수 있으며, 팀 동료들이 코드를 이해하고 유지보수하기 쉬워집니다. 또한 새로운 트레이트 바운드를 추가할 때도 where 절에 한 줄만 추가하면 되므로 확장성이 뛰어납니다.
실전 팁
💡 where 절은 트레이트 바운드가 2개 이상이거나, 타입 매개변수가 2개 이상일 때 사용하면 가독성이 크게 향상됩니다. 간단한 경우는 <T: Clone>처럼 인라인으로 작성하세요.
💡 흔한 실수는 where 절을 중괄호 뒤에 쓰는 것입니다. 반드시 함수 시그니처와 중괄호 사이에 위치해야 합니다.
💡 성능상 where 절과 인라인 바운드는 동일합니다. 둘 다 컴파일 타임에 동일한 방식으로 처리되므로, 가독성만 고려하여 선택하면 됩니다.
💡 복잡한 제네릭 코드를 디버깅할 때는 where 절을 사용하면 컴파일 에러 메시지에서 어느 바운드가 만족되지 않았는지 더 명확하게 확인할 수 있습니다.
💡 연관 타입(associated type)에 제약을 걸 때는 where 절이 필수입니다. 예: where T: Iterator, T::Item: Display는 인라인으로 표현할 수 없습니다.
4. 다중 제네릭 타입 - 여러 타입 매개변수 활용하기
시작하며
여러분이 키-값 쌍을 다루는 함수를 작성할 때, 키와 값이 서로 다른 타입이어야 하는 상황을 겪어본 적 있나요? 예를 들어 문자열 키와 정수 값, 또는 정수 키와 구조체 값 같은 조합이 필요한 경우입니다.
이런 문제는 데이터 구조나 알고리즘을 구현할 때 자주 발생합니다. HashMap, BTreeMap 같은 컬렉션이나, 튜플을 반환하는 함수들은 모두 여러 독립적인 타입을 처리해야 합니다.
바로 이럴 때 필요한 것이 다중 제네릭 타입 매개변수입니다. 여러 타입 매개변수를 사용하면 각각 독립적인 타입으로 작동하면서도 하나의 함수나 구조체에서 함께 사용할 수 있습니다.
개요
간단히 말해서, 다중 제네릭 타입은 함수나 구조체에서 두 개 이상의 독립적인 타입 매개변수를 사용하는 것입니다. 다중 제네릭은 실무에서 매우 흔하게 사용됩니다.
서로 다른 타입을 조합해야 하는 경우가 많고, 각 타입이 다른 트레이트 바운드를 가질 수 있습니다. 예를 들어, 변환 함수를 작성할 때 입력 타입과 출력 타입이 다르거나, 두 개의 컬렉션을 병합할 때 각 컬렉션의 요소 타입이 다를 수 있습니다.
기존에는 하나의 타입만 제네릭하게 처리할 수 있었다면, 이제는 여러 타입을 동시에 제네릭하게 다룰 수 있어 훨씬 유연한 API를 설계할 수 있습니다. 다중 제네릭의 핵심 특징은 첫째, 각 타입 매개변수가 독립적으로 작동하므로 서로 다른 타입이 될 수 있고, 둘째, 각 타입에 서로 다른 트레이트 바운드를 적용할 수 있으며, 셋째, 타입 간의 관계를 명시적으로 표현할 수 있다는 점입니다.
이러한 특징들이 복잡한 데이터 구조와 알고리즘을 타입 안전하게 구현할 수 있게 합니다.
코드 예제
use std::fmt::Display;
// 두 개의 독립적인 제네릭 타입을 받는 함수
fn create_pair<K, V>(key: K, value: V) -> (K, V)
where
K: Display + Clone,
V: Debug + Default,
{
println!("Creating pair with key: {}", key);
println!("Value: {:?}", value);
(key, value)
}
// 서로 다른 타입을 변환하는 함수
fn convert<T, U>(input: T, converter: fn(T) -> U) -> U {
converter(input)
}
fn main() {
// 문자열과 정수 쌍
let pair1 = create_pair("user_id", 12345);
println!("Pair: {:?}", pair1);
// 타입 변환 예제
let result = convert(42, |x| x.to_string());
println!("Converted: {}", result); // "42"
}
설명
이것이 하는 일: 다중 제네릭 타입은 꺾쇠괄호 안에 쉼표로 구분된 여러 타입 매개변수를 선언하고, 각각을 함수 매개변수나 반환 타입에서 독립적으로 사용합니다. 컴파일러는 호출 시점에 각 타입을 추론하거나 명시적으로 지정받습니다.
첫 번째로, fn create_pair<K, V>(key: K, value: V) -> (K, V)는 K와 V라는 두 개의 독립적인 타입 매개변수를 선언합니다. K는 키의 타입, V는 값의 타입을 나타내며, 서로 같을 수도 다를 수도 있습니다.
where 절에서 K에는 Display + Clone을, V에는 Debug + Default를 요구하여 각 타입이 필요한 기능을 갖추도록 합니다. 이렇게 분리하면 키와 값에 서로 다른 요구사항을 적용할 수 있습니다.
그 다음으로, 함수 본문에서 println!("Creating pair with key: {}", key)는 K가 Display를 구현한다는 것을 활용하고, println!("Value: {:?}", value)는 V가 Debug를 구현한다는 것을 활용합니다. 내부적으로는 각 타입의 트레이트 메서드가 호출되며, 최종적으로 (K, V) 튜플을 반환합니다.
convert 함수는 타입 T를 받아 U로 변환하는 더 일반적인 패턴을 보여줍니다. 마지막으로, main 함수에서 create_pair("user_id", 12345)를 호출하면 컴파일러는 K를 &str로, V를 i32로 추론합니다.
convert(42, |x| x.to_string())에서는 T가 i32, U가 String으로 추론되어, 각 타입 조합에 최적화된 코드가 생성되며 최종적으로 타입 안전하면서도 유연한 실행 파일을 만들어냅니다. 여러분이 이 코드를 사용하면 서로 다른 타입의 데이터를 함께 처리할 수 있고, 각 타입에 적절한 제약을 독립적으로 적용할 수 있으며, 타입 변환이나 데이터 구조 구현 시 높은 유연성을 얻을 수 있습니다.
또한 컴파일러의 타입 추론 덕분에 대부분의 경우 타입을 명시하지 않아도 자동으로 결정됩니다.
실전 팁
💡 타입 매개변수 이름은 의미 있게 지으면 가독성이 향상됩니다. K, V는 키-값을, T, U는 일반적인 타입을, I, O는 입력-출력을 나타내는 관례가 있습니다.
💡 흔한 실수는 제네릭 타입 간의 관계를 명시하지 않아서 예상과 다르게 동작하는 것입니다. 예를 들어 T와 U가 같은 타입이어야 한다면 추가 바운드나 where 절로 명시해야 합니다.
💡 성능상 다중 제네릭도 단일 제네릭과 동일하게 단형성화됩니다. 하지만 타입 조합의 수만큼 코드가 생성되므로 (예: T×U 조합), 바이너리 크기가 증가할 수 있습니다.
💡 디버깅 시 타입 추론이 예상과 다르게 작동하면 터보피쉬 문법(::<>)으로 명시적으로 타입을 지정하세요. 예: create_pair::<&str, i32>("key", 42)
💡 제네릭 타입이 3개 이상 필요하면 코드 복잡도가 급격히 증가합니다. 이 경우 일부 타입을 구체화하거나, 타입 별칭(type alias)을 사용하거나, 구조체로 묶는 것을 고려하세요.
5. 제네릭 구조체와 메서드 - 재사용 가능한 데이터 타입 만들기
시작하며
여러분이 좌표를 표현하는 구조체를 만들 때, 정수 좌표도 필요하고 실수 좌표도 필요한 상황을 겪어본 적 있나요? Point2D_i32, Point2D_f64처럼 타입마다 별도의 구조체를 만드는 것은 매우 비효율적입니다.
이런 문제는 데이터 구조를 설계할 때 자주 발생합니다. 동일한 구조와 로직을 가진 타입들을 중복으로 정의하면 코드 양이 늘어나고, 버그 수정이나 기능 추가 시 모든 버전을 수정해야 하는 부담이 생깁니다.
바로 이럴 때 필요한 것이 제네릭 구조체입니다. 제네릭 구조체와 메서드를 사용하면 하나의 정의로 여러 타입을 지원하는 재사용 가능한 데이터 타입을 만들 수 있습니다.
개요
간단히 말해서, 제네릭 구조체는 타입 매개변수를 가진 구조체로, 인스턴스 생성 시 구체적인 타입이 결정됩니다. 제네릭 구조체는 라이브러리와 프레임워크의 핵심 구성 요소입니다.
Vec<T>, Option<T>, Result<T, E> 같은 표준 라이브러리의 핵심 타입들이 모두 제네릭 구조체입니다. 메서드도 제네릭으로 만들 수 있어 구조체의 타입 매개변수를 활용하거나, 메서드만의 추가 제네릭 타입을 가질 수 있습니다.
예를 들어, 컬렉션 타입을 구현할 때 요소 타입을 제네릭으로 만들면 모든 타입의 요소를 저장할 수 있습니다. 기존에는 각 타입마다 별도의 구조체와 메서드를 정의해야 했다면, 이제는 하나의 제네릭 구조체로 모든 타입을 처리할 수 있습니다.
제네릭 구조체의 핵심 특징은 첫째, 타입 안전성을 유지하면서 재사용성을 극대화하고, 둘째, impl 블록에서 타입 매개변수를 사용하여 메서드를 구현하며, 셋째, 특정 타입에 대해서만 메서드를 구현하는 것도 가능하다는 점입니다. 이러한 특징들이 유연하면서도 안전한 API 설계를 가능하게 합니다.
코드 예제
use std::fmt::Display;
// 제네릭 구조체 정의
struct Point<T> {
x: T,
y: T,
}
// 모든 T에 대한 메서드 구현
impl<T> Point<T> {
fn new(x: T, y: T) -> Self {
Point { x, y }
}
fn x(&self) -> &T {
&self.x
}
}
// 특정 트레이트를 구현한 T에 대해서만 메서드 제공
impl<T: Display + Clone> Point<T> {
fn print(&self) {
println!("Point({}, {})", self.x, self.y);
}
fn distance_from_origin(&self) -> T
where
T: std::ops::Mul<Output = T> + std::ops::Add<Output = T> + From<f64>,
{
// 간단한 예제 (실제로는 더 복잡한 계산)
self.x.clone()
}
}
fn main() {
// 정수 좌표
let p1 = Point::new(5, 10);
println!("x: {}", p1.x());
p1.print(); // Point(5, 10)
// 실수 좌표
let p2 = Point::new(3.5, 7.2);
p2.print(); // Point(3.5, 7.2)
}
설명
이것이 하는 일: 제네릭 구조체는 타입 매개변수를 필드의 타입으로 사용하고, impl 블록에서도 동일한 타입 매개변수를 선언하여 메서드를 구현합니다. 인스턴스 생성 시 타입이 구체화되어 타입 안전성을 보장합니다.
첫 번째로, struct Point<T> { x: T, y: T }는 제네릭 타입 T를 가진 구조체를 정의합니다. x와 y 필드 모두 같은 타입 T를 사용하므로, 한 Point 인스턴스 내에서는 x와 y가 항상 같은 타입입니다.
이렇게 하면 타입 불일치를 컴파일 타임에 방지할 수 있습니다. 만약 x와 y가 다른 타입이어야 한다면 Point<T, U>처럼 두 개의 타입 매개변수를 사용할 수 있습니다.
그 다음으로, impl<T> Point<T>는 모든 타입 T에 대해 구현되는 메서드를 정의합니다. new와 x 메서드는 T가 어떤 트레이트를 구현하든 관계없이 사용할 수 있습니다.
내부적으로 Self는 Point<T>를 의미하며, 타입 매개변수가 자동으로 전달됩니다. 반면 impl<T: Display + Clone> Point<T>는 Display와 Clone을 구현한 T에 대해서만 print 메서드를 제공합니다.
마지막으로, main 함수에서 Point::new(5, 10)을 호출하면 컴파일러는 T를 i32로 추론하여 Point<i32> 인스턴스를 생성하고, Point::new(3.5, 7.2)는 Point<f64>를 생성합니다. 각 타입에 대해 최적화된 코드가 생성되어, 최종적으로 런타임 오버헤드 없이 타입 안전한 코드를 실행하며, 하나의 정의로 무한한 타입을 지원할 수 있습니다.
여러분이 이 코드를 사용하면 범용적인 데이터 구조를 한 번만 정의하여 모든 타입에 사용할 수 있고, 특정 기능은 필요한 트레이트를 구현한 타입에만 제공하여 API를 세밀하게 제어할 수 있으며, 표준 라이브러리와 동일한 패턴으로 전문적인 코드를 작성할 수 있습니다. 또한 타입 추론 덕분에 대부분의 경우 사용이 매우 간편합니다.
실전 팁
💡 제네릭 구조체의 타입 매개변수는 구조체 정의와 impl 블록 양쪽에 모두 선언해야 합니다. impl<T> Point<T>에서 첫 번째 <T>는 타입 매개변수 선언, 두 번째 <T>는 사용을 의미합니다.
💡 흔한 실수는 모든 메서드를 하나의 impl 블록에 넣으려는 것입니다. 트레이트 바운드가 다르면 별도의 impl 블록으로 분리하여 각 메서드가 필요한 최소한의 바운드만 요구하도록 하세요.
💡 성능상 제네릭 구조체의 크기는 구체화된 타입의 크기와 동일합니다. Point<i32>는 8바이트, Point<f64>는 16바이트를 차지하므로 메모리 오버헤드가 없습니다.
💡 디버깅 시 #[derive(Debug)]를 추가하면 모든 타입에 대해 자동으로 Debug 트레이트가 구현됩니다. 단, 필드 타입들도 Debug를 구현해야 합니다.
💡 제네릭 구조체를 공개 API로 제공할 때는 타입 별칭(type alias)을 함께 제공하면 사용자 편의성이 높아집니다. 예: type Point2D = Point<f64>;
6. 제네릭 열거형 - 여러 상태를 타입 안전하게 표현하기
시작하며
여러분이 성공 또는 실패를 나타내는 타입을 만들 때, 성공 시 반환할 값의 타입이 매번 다른 상황을 겪어본 적 있나요? 어떤 함수는 i32를 반환하고, 다른 함수는 String을 반환하는데, 각각에 대해 별도의 Result 타입을 만드는 것은 비현실적입니다.
이런 문제는 에러 처리, 옵셔널 값, 여러 상태를 가진 타입을 다룰 때 자주 발생합니다. Rust의 표준 라이브러리가 제공하는 Option<T>와 Result<T, E>가 바로 이 문제의 해결책이며, 여러분도 동일한 패턴으로 커스텀 타입을 만들 수 있습니다.
바로 이럴 때 필요한 것이 제네릭 열거형입니다. 제네릭 열거형을 사용하면 여러 변형(variant)에서 서로 다른 타입의 데이터를 담으면서도 타입 안전성을 유지할 수 있습니다.
개요
간단히 말해서, 제네릭 열거형은 타입 매개변수를 가진 enum으로, 각 변형이 제네릭 타입의 데이터를 포함할 수 있습니다. 제네릭 열거형은 Rust 프로그래밍의 핵심 패턴입니다.
Option<T>는 값이 있거나 없을 수 있는 상황을, Result<T, E>는 성공 또는 실패를 표현합니다. 이들은 null 참조나 예외 대신 타입 시스템을 통해 안전하게 에러를 처리하게 합니다.
예를 들어, 파일 읽기 함수는 Result<String, io::Error>를 반환하여 성공 시 파일 내용을, 실패 시 에러 정보를 타입 안전하게 전달합니다. 기존에는 에러 코드나 null 값으로 실패를 표현했다면, 이제는 제네릭 열거형으로 모든 가능한 상태를 명시적으로 타입으로 표현할 수 있습니다.
제네릭 열거형의 핵심 특징은 첫째, 여러 상태를 하나의 타입으로 안전하게 표현하고, 둘째, 패턴 매칭으로 모든 경우를 처리하도록 강제하며, 셋째, 각 변형이 서로 다른 타입의 데이터를 담을 수 있다는 점입니다. 이러한 특징들이 Rust의 안전성과 표현력을 크게 향상시킵니다.
코드 예제
// 비동기 작업의 상태를 표현하는 제네릭 열거형
enum AsyncResult<T, E> {
Pending,
Success(T),
Failed(E),
}
// 제네릭 열거형에 메서드 구현
impl<T, E> AsyncResult<T, E> {
fn is_pending(&self) -> bool {
matches!(self, AsyncResult::Pending)
}
fn unwrap_or(self, default: T) -> T {
match self {
AsyncResult::Success(value) => value,
_ => default,
}
}
}
// Display 트레이트를 구현한 타입에만 제공되는 메서드
impl<T: std::fmt::Display, E: std::fmt::Display> AsyncResult<T, E> {
fn print_status(&self) {
match self {
AsyncResult::Pending => println!("작업 진행 중..."),
AsyncResult::Success(val) => println!("성공: {}", val),
AsyncResult::Failed(err) => println!("실패: {}", err),
}
}
}
fn main() {
let result1: AsyncResult<i32, String> = AsyncResult::Success(42);
result1.print_status(); // 성공: 42
let result2: AsyncResult<String, &str> = AsyncResult::Failed("네트워크 오류");
result2.print_status(); // 실패: 네트워크 오류
println!("Is pending? {}", result1.is_pending()); // false
}
설명
이것이 하는 일: 제네릭 열거형은 여러 변형을 가지며, 각 변형이 제네릭 타입 매개변수를 사용하여 데이터를 저장합니다. 패턴 매칭을 통해 현재 어떤 변형인지 확인하고 내부 데이터에 접근합니다.
첫 번째로, enum AsyncResult<T, E>는 두 개의 타입 매개변수를 선언합니다. T는 성공 시 반환할 값의 타입, E는 실패 시 에러의 타입을 나타냅니다.
Pending 변형은 데이터를 갖지 않고, Success(T)는 T 타입의 값을, Failed(E)는 E 타입의 에러를 포함합니다. 이렇게 설계하면 비동기 작업의 세 가지 상태(대기, 성공, 실패)를 명확하게 타입으로 표현할 수 있습니다.
그 다음으로, impl<T, E> AsyncResult<T, E>에서 메서드를 구현합니다. is_pending은 matches! 매크로로 현재 변형을 확인하고, unwrap_or는 패턴 매칭으로 Success인 경우 내부 값을 추출하고 그 외에는 기본값을 반환합니다.
내부적으로 컴파일러는 모든 변형을 처리했는지 검사하여 누락된 경우를 방지합니다. 또 다른 impl 블록에서는 T와 E가 Display를 구현할 때만 print_status를 제공합니다.
마지막으로, main 함수에서 AsyncResult::Success(42)는 T가 i32, E가 String인 인스턴스를 생성하고, AsyncResult::Failed("네트워크 오류")는 T가 String, E가 &str인 인스턴스를 생성합니다. 각 타입 조합에 대해 별도의 코드가 생성되며, 최종적으로 컴파일러의 철저한 패턴 매칭 검사 덕분에 처리되지 않은 경우가 없음을 보장받아 안전한 코드를 실행합니다.
여러분이 이 코드를 사용하면 복잡한 상태 머신을 타입 안전하게 표현할 수 있고, 컴파일러가 모든 경우를 처리하도록 강제하여 런타임 에러를 방지하며, 표준 라이브러리의 Option, Result와 동일한 패턴으로 커스텀 타입을 만들 수 있습니다. 또한 명시적인 타입으로 코드의 의도가 명확해져 유지보수성이 향상됩니다.
실전 팁
💡 제네릭 열거형을 설계할 때는 각 변형이 명확한 의미를 가져야 합니다. Option<T>는 Some(T)와 None, Result<T, E>는 Ok(T)와 Err(E)처럼 직관적인 이름을 사용하세요.
💡 흔한 실수는 패턴 매칭에서 일부 변형을 처리하지 않는 것입니다. _ 와일드카드 대신 모든 변형을 명시적으로 매칭하면 나중에 변형이 추가될 때 컴파일 에러로 알려줍니다.
💡 성능상 제네릭 열거형의 크기는 가장 큰 변형의 크기 + 태그(discriminant) 크기입니다. 너무 큰 데이터는 Box로 감싸서 힙에 할당하면 열거형 크기를 줄일 수 있습니다.
💡 디버깅 시 #[derive(Debug)]와 함께 각 변형을 println!("{:?}", result)로 출력하면 현재 상태를 쉽게 확인할 수 있습니다.
💡 제네릭 열거형과 match 표현식을 함께 사용하면 함수형 프로그래밍 스타일의 안전한 에러 처리를 구현할 수 있습니다. map, and_then 같은 메서드를 추가하면 더욱 강력해집니다.
7. 라이프타임과 제네릭 결합 - 참조를 안전하게 사용하기
시작하며
여러분이 제네릭 구조체에 참조를 저장하려고 했는데, "expected named lifetime parameter"라는 컴파일 에러를 본 경험이 있나요? 제네릭만으로는 참조의 수명을 표현할 수 없어서 발생하는 문제입니다.
이런 문제는 데이터를 소유하지 않고 빌려오는 구조체나 함수를 만들 때 자주 발생합니다. 참조는 메모리 안전성을 위해 수명(lifetime) 정보가 필요하며, 제네릭과 함께 사용하려면 추가적인 문법이 필요합니다.
바로 이럴 때 필요한 것이 라이프타임 매개변수입니다. 라이프타임과 제네릭을 결합하면 참조를 포함하는 제네릭 타입을 안전하게 만들 수 있습니다.
개요
간단히 말해서, 라이프타임 매개변수는 참조가 얼마나 오래 유효한지를 나타내는 제네릭 매개변수의 한 종류입니다. 라이프타임은 Rust의 메모리 안전성을 보장하는 핵심 메커니즘입니다.
제네릭 타입이 참조를 포함할 때, 그 참조가 구조체보다 오래 살아있음을 컴파일러에게 증명해야 합니다. 라이프타임 매개변수는 작은따옴표로 시작하며(예: 'a, 'b), 타입 매개변수와 함께 사용됩니다.
예를 들어, 문자열 슬라이스를 저장하는 구조체는 그 슬라이스가 유효한 동안만 존재해야 합니다. 기존에는 소유권을 가진 데이터만 제네릭 구조체에 저장할 수 있었다면, 이제는 라이프타임을 명시하여 참조도 안전하게 저장할 수 있습니다.
라이프타임과 제네릭의 결합에서 핵심 특징은 첫째, 참조의 유효성을 컴파일 타임에 검증하고, 둘째, 여러 참조 간의 수명 관계를 명시할 수 있으며, 셋째, 타입 안전성과 메모리 안전성을 동시에 달성한다는 점입니다. 이러한 특징들이 Rust를 메모리 안전한 시스템 프로그래밍 언어로 만듭니다.
코드 예제
use std::fmt::Display;
// 라이프타임과 제네릭을 함께 사용하는 구조체
struct DataWrapper<'a, T> {
data: &'a T,
metadata: String,
}
// 라이프타임과 제네릭에 대한 메서드 구현
impl<'a, T> DataWrapper<'a, T> {
fn new(data: &'a T, metadata: String) -> Self {
DataWrapper { data, metadata }
}
fn get_data(&self) -> &T {
self.data
}
}
// 특정 트레이트 바운드를 가진 경우에만 제공되는 메서드
impl<'a, T: Display> DataWrapper<'a, T> {
fn print_info(&self) {
println!("Data: {}", self.data);
println!("Metadata: {}", self.metadata);
}
}
fn main() {
let number = 42;
let wrapper = DataWrapper::new(&number, "Important number".to_string());
wrapper.print_info();
// Data: 42
// Metadata: Important number
println!("Original value: {}", wrapper.get_data());
}
설명
이것이 하는 일: 라이프타임 매개변수는 참조가 유효한 범위를 나타내며, 제네릭 타입 매개변수와 함께 사용하여 어떤 타입의 참조든 안전하게 저장할 수 있습니다. 컴파일러는 참조가 구조체보다 오래 살아있는지 검증합니다.
첫 번째로, struct DataWrapper<'a, T>는 라이프타임 매개변수 'a와 타입 매개변수 T를 선언합니다. data: &'a T는 "라이프타임 'a를 가진 T에 대한 참조"를 의미합니다.
이는 data가 가리키는 값이 최소한 이 구조체만큼은 살아있어야 함을 보장합니다. 이렇게 명시하면 댕글링 포인터(dangling pointer)를 컴파일 타임에 방지할 수 있습니다.
metadata는 소유된 String이므로 라이프타임 표기가 필요 없습니다. 그 다음으로, impl<'a, T> DataWrapper<'a, T>에서 라이프타임과 타입 매개변수를 모두 선언합니다.
new 메서드는 data: &'a T를 받아 같은 라이프타임으로 저장하고, get_data는 &T를 반환하는데 이는 암묵적으로 구조체의 라이프타임과 연결됩니다. 내부적으로 컴파일러는 모든 참조가 수명 규칙을 만족하는지 보로우 체커로 검증합니다.
impl<'a, T: Display>는 추가로 Display 바운드를 요구하는 메서드를 제공합니다. 마지막으로, main 함수에서 let number = 42로 값을 생성하고, DataWrapper::new(&number, ...)로 그 참조를 저장합니다.
컴파일러는 number가 wrapper보다 먼저 선언되었으므로 더 오래 살아있음을 확인하고, wrapper가 스코프를 벗어나기 전에 number가 유효하므로 안전하다고 판단합니다. 최종적으로 메모리 안전성이 보장된 코드를 실행하며, 런타임 오버헤드 없이 참조를 효율적으로 사용합니다.
여러분이 이 코드를 사용하면 데이터를 복사하지 않고 참조로 효율적으로 다룰 수 있고, 컴파일 타임에 모든 메모리 안전성 문제를 잡을 수 있으며, 제네릭의 유연성과 참조의 효율성을 동시에 얻을 수 있습니다. 또한 명시적인 라이프타임으로 참조 간의 관계가 명확해져 복잡한 데이터 구조도 안전하게 설계할 수 있습니다.
실전 팁
💡 라이프타임 매개변수는 일반적으로 'a, 'b, 'c 순서로 사용하지만, 의미 있는 이름(예: 'input, 'output)을 사용하면 복잡한 코드에서 가독성이 향상됩니다.
💡 흔한 실수는 불필요한 곳에 라이프타임을 추가하는 것입니다. 소유된 데이터(String, Vec 등)는 라이프타임이 필요 없으며, 참조만 명시하면 됩니다.
💡 성능상 라이프타임 자체는 런타임 오버헤드가 전혀 없습니다. 순수하게 컴파일 타임 정보이며, 실행 파일에는 포함되지 않습니다.
💡 디버깅 시 "lifetime may not live long enough" 에러가 나면, 참조가 가리키는 값이 참조보다 먼저 소멸하는지 확인하세요. 스코프 순서를 조정하거나 소유권을 가져오는 것으로 해결할 수 있습니다.
💡 복잡한 라이프타임 관계는 where 절로 명시할 수 있습니다. 예: where 'a: 'b는 'a가 'b보다 오래 살아있음을 의미합니다.
8. const 제네릭 - 컴파일 타임 상수를 타입 매개변수로
시작하며
여러분이 고정 크기 배열을 다루는 제네릭 함수를 만들려고 했는데, 크기가 다른 배열마다 별도의 함수를 작성해야 했던 경험이 있나요? [i32; 3]과 [i32; 5]는 Rust에서 완전히 다른 타입으로 취급됩니다.
이런 문제는 배열, 행렬, 고정 크기 버퍼를 다룰 때 자주 발생합니다. 전통적인 제네릭으로는 타입만 매개변수화할 수 있고, 크기나 길이 같은 상수 값은 처리할 수 없었습니다.
바로 이럴 때 필요한 것이 const 제네릭입니다. const 제네릭을 사용하면 타입뿐만 아니라 컴파일 타임 상수도 매개변수로 받아 더 유연한 제네릭 코드를 작성할 수 있습니다.
개요
간단히 말해서, const 제네릭은 타입 대신 컴파일 타임 상수 값을 매개변수로 받는 제네릭입니다. const 제네릭은 Rust 1.51부터 안정화된 비교적 새로운 기능입니다.
배열의 크기, 행렬의 차원, 고정 크기 버퍼의 용량 등을 타입 매개변수로 표현할 수 있습니다. 이전에는 각 크기마다 별도의 구현이 필요했지만, 이제는 하나의 제네릭 구현으로 모든 크기를 처리할 수 있습니다.
예를 들어, 2D 게임의 타일맵이나 과학 계산의 고정 크기 벡터를 구현할 때 매우 유용합니다. 기존에는 Vec<T>처럼 동적 크기만 제네릭하게 다룰 수 있었다면, 이제는 [T; N]처럼 고정 크기도 제네릭하게 다룰 수 있습니다.
const 제네릭의 핵심 특징은 첫째, 컴파일 타임에 크기가 결정되어 런타임 오버헤드가 없고, 둘째, 타입 안전성을 유지하면서 다양한 크기를 지원하며, 셋째, 배열 같은 고정 크기 자료구조를 효율적으로 추상화할 수 있다는 점입니다. 이러한 특징들이 시스템 프로그래밍과 임베디드 개발에서 매우 유용합니다.
코드 예제
use std::fmt::Debug;
// const 제네릭을 사용한 고정 크기 배열 래퍼
struct FixedArray<T, const N: usize> {
data: [T; N],
}
impl<T, const N: usize> FixedArray<T, N> {
fn len(&self) -> usize {
N
}
fn get(&self, index: usize) -> Option<&T> {
self.data.get(index)
}
}
// Debug를 구현한 타입에만 제공되는 메서드
impl<T: Debug, const N: usize> FixedArray<T, N> {
fn print_all(&self) {
println!("Array of size {}: {:?}", N, self.data);
}
}
// 배열 두 개를 연결하는 함수
fn concat_arrays<T: Copy, const M: usize, const N: usize>(
a: [T; M],
b: [T; N],
) -> [T; M + N] {
let mut result = [a[0]; M + N];
result[..M].copy_from_slice(&a);
result[M..].copy_from_slice(&b);
result
}
fn main() {
let arr1 = FixedArray { data: [1, 2, 3] };
arr1.print_all(); // Array of size 3: [1, 2, 3]
let arr2 = FixedArray { data: [1.1, 2.2, 3.3, 4.4] };
arr2.print_all(); // Array of size 4: [1.1, 2.2, 3.3, 4.4]
let combined = concat_arrays([1, 2], [3, 4, 5]);
println!("Combined: {:?}", combined); // [1, 2, 3, 4, 5]
}
설명
이것이 하는 일: const 제네릭은 타입 매개변수 목록에 const N: usize처럼 상수를 선언하고, 이를 배열 크기나 기타 상수가 필요한 곳에 사용합니다. 컴파일러는 각 상수 값에 대해 별도의 코드를 생성합니다.
첫 번째로, struct FixedArray<T, const N: usize>는 타입 T와 상수 N을 매개변수로 받습니다. data: [T; N]은 N개의 T를 담는 고정 크기 배열을 의미하며, N은 컴파일 타임에 결정됩니다.
이렇게 하면 FixedArray<i32, 3>과 FixedArray<i32, 5>는 서로 다른 타입이 되어, 크기가 다른 배열을 섞어 쓰는 실수를 컴파일 타임에 방지할 수 있습니다. 그 다음으로, impl<T, const N: usize> FixedArray<T, N>에서 메서드를 구현합니다.
len 메서드는 상수 N을 직접 반환하므로 런타임 계산이 없고, get 메서드는 경계 검사를 포함하여 안전하게 요소에 접근합니다. 내부적으로 N은 컴파일 타임 상수이므로, 컴파일러가 최적화를 더 잘 수행할 수 있습니다.
concat_arrays 함수는 두 개의 const 제네릭 M과 N을 받아, M + N 크기의 배열을 반환하는 복잡한 예제입니다. 마지막으로, main 함수에서 FixedArray { data: [1, 2, 3] }을 생성하면 컴파일러는 N을 3으로 추론하여 FixedArray<i32, 3> 타입을 만들고, [1.1, 2.2, 3.3, 4.4]는 FixedArray<f64, 4>를 만듭니다.
각 크기에 대해 최적화된 코드가 생성되어, 최종적으로 런타임 오버헤드 없이 타입 안전한 고정 크기 배열을 효율적으로 다룰 수 있습니다. 여러분이 이 코드를 사용하면 배열 크기를 제네릭하게 처리하여 코드 중복을 줄일 수 있고, 컴파일 타임에 크기가 결정되어 성능이 뛰어나며, 잘못된 크기의 배열을 사용하는 버그를 컴파일 타임에 잡을 수 있습니다.
또한 임베디드 시스템이나 게임 개발처럼 고정 크기 자료구조가 중요한 분야에서 매우 유용합니다.
실전 팁
💡 const 제네릭의 타입은 현재 정수 타입(usize, u8, i32 등), bool, char만 지원됩니다. 문자열이나 구조체는 아직 사용할 수 없습니다.
💡 흔한 실수는 const 제네릭을 런타임 값으로 사용하려는 것입니다. N은 반드시 컴파일 타임에 알 수 있는 상수여야 하며, 변수를 전달할 수 없습니다.
💡 성능상 const 제네릭은 단형성화되므로 각 크기별로 코드가 생성됩니다. 크기가 많으면 바이너리가 커질 수 있으니, 자주 사용하는 크기만 구체화하는 것을 고려하세요.
💡 디버깅 시 타입 에러 메시지에 const 제네릭 값이 표시됩니다. "expected [i32; 3], found [i32; 5]"처럼 크기 불일치를 명확히 알 수 있습니다.
💡 배열 초기화 시 [default_value; N] 문법을 사용하려면 값이 Copy 트레이트를 구현해야 합니다. Copy가 아니면 std::array::from_fn을 사용하세요.