Rust 댕글링 참조 방지하기 완벽 가이드

Rust의 소유권 시스템이 어떻게 댕글링 참조를 컴파일 타임에 방지하는지 알아봅니다. 메모리 안전성을 보장하는 Rust의 핵심 메커니즘을 초보자도 쉽게 이해할 수 있도록 풀어냅니다.

---

목차

1. 댕글링 참조란 무엇인가
2. 스코프와 수명의 관계
3. 올바른 참조 반환 방법
4. 수명 명시의 기본
5. 수명 명시 생략 규칙
6. 구조체에서의 수명
7. 정적 수명
8. 수명 하위 타이핑
9. 수명 경계
10. 댕글링 참조 방지 핵심 정리

---

1. 댕글링 참조란 무엇인가

김개발 씨가 C++ 프로젝트에서 버그를 수정하다가 우연히 이상한 현상을 발견했습니다. 이미 삭제된 메모리를 가리키는 포인터 때문에 프로그램이 이상하게 동작했기 때문입니다.

"이게 뭐지? 분명히 값을 읽어야 하는데 쓰레기 값이 나오네..." 선배 개발자가 다가와 말했습니다.

"그거 댕글링 참조예요. Rust는 이걸 아예 컴파일할 때 잡아줍니다."

댕글링 참조는 이미 해제된 메모리를 가리키는 참조입니다. 마치 이미 철수한 친구의 전화번호를 계속 누르는 것과 같습니다.

이 참조를 사용하면 프로그램이 예측 불가능하게 동작하거나 보안 취약점이 발생할 수 있습니다. Rust는 이런 문제를 컴파일 타임에 완전히 방지합니다.

다음 코드를 살펴봅시다.

fn main() {
    let reference_to_nothing = dangle();
}

fn dangle() -> &String {
    let s = String::from("hello");
    &s // 여기서 s의 참조를 반환합니다
} // 하지만 여기서 s가 스코프를 벗어나 삭제됩니다!
  // 따라서 &s는 아무것도 가리키지 않게 됩니다

어느 날 김개발 씨가 C++로 작성된 레거시 코드를 분석하고 있었습니다. 함수 하나가 로컬 변수의 참조를 반환하는 코드를 발견했고, 아무 문제 없이 컴파일되어 실행되었습니다.

하지만 실행할 때마다 결과가 달라지는 이상한 현상이 있었습니다. 선배 개발자 박시니어 씨가 다가와 코드를 보더니 고개를 저었습니다.

"이거 댕글링 참조 버그예요. 함수가 끝나면 로컬 변수는 사라지는데, 그 주소를 계속 쓰고 있어서 그래요." 댕글링 참조란 정확히 무엇일까요?

쉽게 비유하자면, 댕글링 참조는 이미 이사 간 친구의 옛 주소로 편지를 보내는 것과 같습니다. 편지는 배달되지만, 그 집에는 더 이상 친구가 살지 않죠.

누군가 다른 사람이 그 편지를 읽을 수도 있고, 편지가 분실될 수도 있습니다. 마찬가지로, 이미 해제된 메모리를 가리키는 참조는 예측할 수 없는 결과를 낳습니다.

댕글링 참조가 왜 위험할까요? 첫째, 프로그램이 불안정해집니다.

이미 해제된 메모리를 읽으면 쓰레기 값이 나올 수 있고, 프로그램이 비정상 종료될 수 있습니다. 둘째, 보안 취약점이 됩니다.

공격자가 해제된 메모리에 악의적인 데이터를 써서 프로그램을 조작할 수도 있습니다. C나 C++ 같은 언어에서는 이런 문제가 런타임에야 발견됩니다.

개발자가 직접 메모리를 관리해야 하고, 실수하기 쉽습니다. 대규모 프로젝트에서는 이런 버그를 찾는 데 며칠이 걸리기도 합니다.

Rust는 이 문제를 근본적으로 해결했습니다. 바로 소유권 시스템을 통해서입니다.

Rust 컴파일러는 참조가 가리키는 값이 참조보다 오래 살아있는지 컴파일 타임에 검사합니다. 만약 그렇지 않다면, 컴파일 에러를 내고 프로그램을 빌드하지 않습니다.

이것이 Rust의 핵심 철학입니다. 안전하지 않은 코드는 애초에 컴파일되지 않게 하는 것입니다.

위의 코드를 보겠습니다. dangle 함수는 String의 참조를 반환하려고 합니다.

하지만 s는 함수가 끝날 때 스코프를 벗어나고 메모리가 해제됩니다. 따라서 반환된 참조는 아무것도 가리키지 않게 됩니다.

Rust 컴파일러는 이를 감지하고 에러를 발생시킵니다. 실무에서 댕글링 참조는 얼마나 자주 발생할까요?

놀랍게도 꽤 자주 발생합니다. 특히 함수가 로컬 변수의 참조를 반환하거나, 컬렉션의 요소를 반복하면서 컬렉션을 수정할 때 발생하기 쉽습니다.

Rust를 사용하면 이런 걱정에서 완전히 자유로워집니다. 컴파일러가 대신 검사해주기 때문입니다.

개발자는 비즈니스 로직에 집중할 수 있고, 메모리 버그를 찾아 헤매는 시간을 아낄 수 있습니다.

실전 팁

💡 - 댕글링 참조는 런타임 버그가 아니라 컴파일 에러로 발생합니다

• Rust의 소유권 시스템이 메모리 안전성을 컴파일 타임에 보장합니다
• 다른 언어에서 흔히 발생하는 메모리 버그를 사전에 차단합니다

---

2. 스코프와 수명의 관계

김개발 씨가 Rust 코드를 작성하다가 컴파일 에러를 마주했습니다. "borrowed value does not live long enough"라는 메시지가 나온 것입니다.

영어로 된 에러 메시지를 보며 고개를 갸웃거리는 김개발 씨에게 박시니어 씨가 설명해주었습니다. "수명 문제예요.

참조가 가리키는 값보다 오래 살려고 해서 그래요."

스코프는 변수가 유효한 범위입니다. 수명은 참조가 유효한 기간입니다.

마치 도서관 대출 기간처럼, 참조는 원본 값이 살아있는 동안에만 유효합니다. Rust는 이 관계를 엄격하게 관리하여 메모리 안전성을 보장합니다.

다음 코드를 살펴봅시다.

fn main() {
    let r;                // r의 수명 시작 (아직 값 없음)

    {
        let x = 5;        // x의 수명 시작
        r = &x;           // r이 x를 참조
    }                     // x가 스코프를 벗어나 삭제됨

    println!("r: {}", r); // 에러! x는 이미 사라짐
}

김개발 씨가 Rust로 간단한 프로그램을 작성하고 있었습니다. 변수를 먼저 선언하고 나중에 참조를 할당하는 패턴을 사용했는데, 컴파일러가 불평하기 시작했습니다.

"이게 왜 에러지? 분명히 코드가 맞는데..." 박시니어 씨가 코드를 보더니 설명했습니다.

"여기서 x는 안쪽 스코프에서만 살아있어요. 하지만 r은 바깥쪽에서도 사용하려고 하죠.

x는 이미 사라졌는데 r은 그걸 가리키고 있어서 문제예요." 스코프란 무엇일까요? 스코프는 변수가 유효한 코드 범위입니다.

변수는 선언된 지점부터 스코프가 끝날 때까지 살아있습니다. 중괄호로 둘러싸인 블록이 끝나면, 그 안에서 선언된 변수들은 모두 사라집니다.

마치 회의실에서 회의가 끝나면 모든 자료가 치워지는 것과 같습니다. 수명은 참조의 유효 기간입니다.

참조는 다른 변수를 가리키는 주소 같은 것인데, 이 주소가 유효하려면 가리키는 변수가 살아있어야 합니다. 도서관에서 책을 빌렸는데, 반납 기간이 지난 책을 계속 쓸 수 없는 것과 같습니다.

Rust는 이 관계를 매우 엄격하게 관리합니다. 참조의 수명은 가리키는 값의 수명을 넘을 수 없습니다.

이 규칙을 어기면 컴파일 에러가 발생합니다. 위의 코드를 다시 보겠습니다.

r은 바깥쪽 스코프에서 선언되었습니다. 그다음 안쪽 블록에서 x를 선언하고 r이 x를 참조하게 했습니다.

하지만 안쪽 블록이 끝나면서 x는 사라집니다. 이때 r은 여전히 x를 가리키려고 합니다.

이미 사라진 변수를 가리키는 것이죠. Rust 컴파일러는 이를 허용하지 않습니다.

다른 언어에서는 어떨까요? C++에서는 이런 코드가 컴파일될 수 있습니다.

하지만 실행할 때 예측할 수 없는 동작을 하게 됩니다. 때로는 정상적으로 동작하는 것처럼 보이지만, 때로는 프로그램이 죽거나 잘못된 결과를 냅니다.

이런 버그는 재현하기 어렵고 찾기도 힘듭니다. Rust는 이런 문제를 원천적으로 차단합니다.

컴파일할 때 바로 에러를 내니까요. 개발자는 실행해보기도 전에 문제를 알 수 있습니다.

이것이 Rust가 "안전한 언어"라고 불리는 이유 중 하나입니다. 실무에서는 어떤 상황에 이런 문제가 발생할까요?

예를 들어 함수에서 로컬 변수의 참조를 반환하려고 할 때 자주 발생합니다. 또는 벡터의 요소를 참조한 다음 벡터를 재할당할 때도 발생합니다.

Rust는 이런 상황을 모두 컴파일 타임에 잡아냅니다.

실전 팁

💡 - 스코프는 변수가 유효한 범위, 수명은 참조가 유효한 기간입니다

• 참조는 가리키는 값보다 오래 살 수 없습니다
• 중괄호 블록이 끝나면 그 안의 변수들은 모두 사라집니다

---

3. 올바른 참조 반환 방법

"그럼 함수에서 값을 반환하려면 어떻게 해야 하나요?" 김개발 씨가 질문했습니다. 박시니어 씨가 미소를 지으며 답했습니다.

"두 가지 방법이 있어요. 소유권을 아예 넘기거나, 충분히 오래 사는 참조를 반환하는 거죠."

댕글링 참조를 방지하면서 함수에서 값을 반환하려면 소유권 이전 또는 충분히 긴 수명의 참조를 사용해야 합니다. 소유권을 넘기면 호출자가 값을 완전히 소유하게 되고, 참조를 반환하려면 원본이 충분히 오래 살아있어야 합니다.

다음 코드를 살펴봅시다.

fn main() {
    let string = no_dangle();
    println!("Got: {}", string);
}

// 올바른 방법 1: 소유권 이전
fn no_dangle() -> String {
    let s = String::from("hello");
    s // 소유권을 호출자에게 이전
}

// 올바른 방법 2: 충분히 긴 수명의 참조
fn first_word(s: &String) -> &str {
    let bytes = s.as_bytes();
    for (i, &item) in bytes.iter().enumerate() {
        if item == b' ' {
            return &s[0..i];
        }
    }
    &s[..]
}

김개발 씨가 이전 예제에서 댕글링 참조 문제를 겪은 후, 해결 방법을 궁금해했습니다. "함수에서 뭔가를 반환해야 하는데, 참조를 쓰면 안 된다면 어떻게 하죠?" 박시니어 씨가 화이트보드에 그림을 그리며 설명했습니다.

"두 가지 방법이 있어요. 첫 번째는 참조 대신 값을 직접 반환하는 거예요.

그러면 소유권이 호출자에게 넘어가죠." 소유권 이전이란 무엇일까요? 함수에서 값을 직접 반환하면, 그 값의 소유권이 호출자에게 넘어갑니다.

마치 선물을 주는 것과 같습니다. 선물을 받은 사람은 그 선물을 완전히 소유하고, 원할 때 해제할 수 있습니다.

함수 내부에서 만든 String을 그대로 반환하면, 호출자가 그 String을 소유하게 됩니다. no_dangle 함수를 보겠습니다.

이 함수는 String을 만들고 그대로 반환합니다. s의 소유권이 함수 밖으로 이전되는 것이죠.

따라서 s는 스코프가 끝날 때 해제되지 않습니다. 대신 호출자가 main 함수의 string 변수를 통해 이 값을 소유하게 됩니다.

두 번째 방법은 무엇일까요? 충분히 긴 수명의 참조를 반환하는 것입니다.

입력으로 받은 참조의 일부를 반환하는 경우입니다. 원본이 호출자에게 있으므로, 반환된 참조도 안전합니다.

first_word 함수를 보겠습니다. 이 함수는 String의 참조를 받아서 첫 번째 단어의 참조를 반환합니다.

입력 참조와 반환 참조의 수명이 같습니다. 원본 String이 살아있는 한 반환된 참조도 안전합니다.

Rust 컴파일러는 이 관계를 이해하고 허용합니다. 어떤 방법을 선택해야 할까요?

상황에 따라 다릅니다. 값을 계속 사용해야 한다면 소유권을 넘겨받는 것이 좋습니다.

큰 데이터를 복사하지 않고 일부만 읽어야 한다면 참조를 사용하는 것이 효율적입니다. 실무에서는 어떤 패턴이 자주 쓰일까요?

조회 함수는 보통 참조를 반환합니다. 데이터를 수정하지 않고 읽기만 하니까요.

생성 함수는 보통 소유권을 넘깁니다. 새로 만든 데이터를 호출자가 관리하게 하는 것이죠.

실전 팁

💡 - 값을 직접 반환하면 소유권이 호출자에게 이전됩니다

• 입력 참조의 일부를 반환하면 수명이 자동으로 연결됩니다
• 상황에 따라 적절한 방법을 선택하세요

---

4. 수명 명시의 기본

"컴파일러가 알아서 해주면 되는데 왜 수명을 명시해야 하나요?" 김개발 씨가 물었습니다. 박시니어 씨가 고개를 저었습니다.

"컴파일러도 모를 때가 있어요. 그때는 개발자가 직접 알려줘야 하죠."

수명 명시는 참조 간의 관계를 컴파일러에 알려주는 것입니다. 마치 약속 시간을 명확히 정하는 것처럼, 어떤 참조가 다른 참조와 얼마나 오래 함께 살아있을지 지정합니다.

함수 시그니처에서 수명을 명시하면 컴파일러가 참조의 안전성을 검증할 수 있습니다.

다음 코드를 살펴봅시다.

fn main() {
    let string1 = String::from("abcd");
    let string2 = "xyz";

    let result = longest(string1.as_str(), string2);
    println!("Longest: {}", result);
}

// 수명 명시 'a는 두 참조와 반환값이 같은 수명을 가짐을 의미
fn longest<'a>(x: &'a str, y: &'a str) -> &'a str {
    if x.len() > y.len() {
        x
    } else {
        y
    }
}

김개발 씨가 두 문자열 중 긴 것을 반환하는 함수를 작성했습니다. 컴파일러가 에러를 냈습니다.

"missing lifetime specifier"라는 메시지였습니다. 김개발 씨가 박시니어 씨에게 도움을 요청했습니다.

박시니어 씨가 코드를 보더니 설명했습니다. "컴파일러가 반환값이 어느 참조와 수명을 공유하는지 모르는 상황이에요.

x를 반환할 수도 있고 y를 반환할 수도 있으니까요. 이럴 때 수명을 명시해줘야 해요." 수명 명시란 정확히 무엇일까요?

수명 명시는 참조가 얼마나 오래 유효한지 컴파일러에 알려주는 표시입니다. 제네릭처럼 함수 이름 뒤에 <'a> 형태로 적습니다.

이것은 실제 수명을 지정하는 것이 아니라, 여러 참조 간의 관계를 설명하는 것입니다. 쉽게 비유하면 약속 시간 정하는 것과 같습니다.

"우리 세 사람은 같은 시간에 만나서 같은 시간에 헤어져"라고 정하는 것이죠. 수명 명시 'a는 "이 참조들은 같은 수명을 공유한다"는 의미입니다.

longest 함수를 보겠습니다. <'a>는 수명 매개변수입니다.

x: &'a str과 y: &'a str은 두 입력 참조가 같은 수명 'a를 가진다는 의미입니다. -> &'a str은 반환값도 같은 수명을 가진다는 의미입니다.

이 명시가 왜 필요할까요? 컴파일러가 반환값의 수명을 추론할 정보가 부족하기 때문입니다.

함수 본문을 보면 x 또는 y를 반환합니다. 어느 쪽이 반환될지는 런타임에 결정됩니다.

컴파일러는 이 정보만으로는 반환값의 수명을 알 수 없습니다. 따라서 개발자가 명시적으로 알려줘야 합니다.

수명 명시를 하면 어떤 이점이 있을까요? 컴파일러가 함수를 호출하는 모든 곳에서 수명 규칙을 검사할 수 있습니다.

반환된 참조를 너무 오래 사용하려고 하면 컴파일 에러가 발생합니다. 댕글링 참조가 발생할 가능성을 원천 차단하는 것이죠.

실무에서는 언제 수명 명시가 필요할까요? 함수가 여러 참조를 받고 그중 하나를 반환할 때 필요합니다.

구조체가 참조를 필드로 가질 때도 필요합니다. 처음에는 낯설지만, 익숙해지면 자연스럽게 작성할 수 있습니다.

실전 팁

💡 - 수명 명시는 참조 간의 관계를 설명합니다

• 함수가 여러 참조를 받고 그중 하나를 반환할 때 필요합니다
• 'a는 실제 수명이 아니라 참조 간의 관계를 나타냅니다

---

5. 수명 명시 생략 규칙

"그런데 이전에 작성한 코드는 수명 명시가 없었는데도 컴파일됐어요." 김개발 씨가 의아해했습니다. 박시니어 씨가 미소를 지었습니다.

"맞아요. 컴파일러가 추론할 수 있는 경우에는 명시를 생략할 수 있거든요."

수명 명시 생략 규칙은 컴파일러가 자동으로 수명을 추론하는 규칙입니다. 입력 참조가 하나뿐이거나, 메서드의 self 참조가 있는 경우 등 명시하지 않아도 컴파일러가 알아서 판단합니다.

이 규칙 덕분에 대부분의 코드에서 수명 명시가 필요 없습니다.

다음 코드를 살펴봅시다.

fn main() {
    let s = String::from("hello");

    // 수명 명시 없이도 컴파일됨
    let len = calculate_length(&s);
    println!("Length: {}", len);

    let first = first_char(&s);
    println!("First char: {}", first);
}

// 규칙 1: 입력 참조가 하나면 반환 참조도 같은 수명
fn calculate_length(s: &String) -> usize {
    s.len()
}

// 규칙 1: 입력 참조가 하나면 반환 참조도 같은 수명
fn first_char(s: &String) -> &str {
    &s[0..1]
}

김개발 씨가 수명 명시에 대해 배운 후, 이전에 작성한 코드들을 다시 살펴보았습니다. 분명 수명 명시가 없는데도 컴파일이 잘 되는 코드들이 있었습니다.

"이상하네. 배운 대로라면 수명을 명시해야 하는 거 아닌가?" 박시니어 씨가 설명했습니다.

"Rust 컴파일러가 일정한 패턴을 인식해서 자동으로 추론해주는 경우가 있어요. 이걸 수명 명시 생략 규칙이라고 해요." 수명 명시 생략 규칙이란 무엇일까요?

컴파일러가 자주 사용되는 패턴을 인식하여 자동으로 수명을 추론하는 규칙입니다. 마치 우리가 대화할 때 굳이 말하지 않아도 문맥으로 이해하는 것처럼, 컴파일러도 코드의 문맥을 이해합니다.

첫 번째 규칙은 입력 참조가 하나뿐인 경우입니다. 함수가 참조를 하나만 받으면, 반환값이 참조일 경우 같은 수명을 가진다고 가정합니다.

first_char 함수를 보겠습니다. &String을 받고 &str을 반환합니다.

입력이 하나뿐이므로 반환값은 입력과 같은 수명을 가집니다. 명시하지 않아도 컴파일러가 이해합니다.

두 번째 규칙은 여러 입력 참조가 있는 경우입니다. 이 경우 컴파일러는 반환 참조의 수명을 추론하지 못합니다.

개발자가 명시해야 하죠. 앞서 본 longest 함수가 이 경우입니다.

세 번째 규칙은 메서드의 경우입니다. &self 또는 &mut self가 있으면, 반환 참조는 self와 같은 수명을 가진다고 가정합니다.

구조체의 메서드에서 자주 사용되는 패턴입니다. 이 규칙들이 왜 존재할까요?

Rust 개발자들이 실제 코드에서 가장 자주 사용하는 패턴을 분석했기 때문입니다. 대부분의 함수는 입력 참조가 하나뿐이거나, self를 사용하는 메서드입니다.

이런 경우 굳이 수명을 명시하면 코드가 길어지기만 합니다. 따라서 컴파일러가 자동으로 처리하도록 만들었습니다.

실무에서는 어떤 경우에 수명 명시가 필요할까요? 함수가 여러 참조를 받고 그중 하나를 반환할 때 필요합니다.

구조체가 참조를 저장할 때도 필요합니다. 하지만 이런 경우를 제외하면 대부분 수명 명시 없이 코드를 작성할 수 있습니다.

실전 팁

💡 - 입력 참조가 하나뿐이면 수명 명시를 생략할 수 있습니다

• 메서드에서 self를 사용하면 반환 참조의 수명이 자동 추론됩니다
• 복잡한 경우에는 여전히 수명 명시가 필요합니다

---

6. 구조체에서의 수명

김개발 씨가 구조체를 정의하다가 또 에러를 만났습니다. "구조체 필드에 참조를 넣으려는데 수명을 명시하래요." 박시니어 씨가 고개를 끄덕였습니다.

"구조체가 참조를 가지려면 그 참조가 얼마나 오래 유효한지 알아야 하니까요."

구조체의 수명 명시는 구조체가 참조를 필드로 가질 때 필요합니다. 구조체의 인스턴스가 참조하는 값보다 오래 살지 않도록 보장해야 합니다.

수명 명시를 통해 컴파일러가 이 관계를 검증할 수 있습니다.

다음 코드를 살펴봅시다.

// 수명 명시가 필요한 구조체
struct ImportantExcerpt<'a> {
    part: &'a str,
}

fn main() {
    let novel = String::from("Call me Ishmael. Some years ago...");
    let first_sentence = novel.split('.').next().expect("Could not find a '.'");

    // 구조체 인스턴스 생성
    let excerpt = ImportantExcerpt {
        part: first_sentence,
    };

    println!("Excerpt: {}", excerpt.part);
} // excerpt가 먼저 스코프를 벗어나고, 그 다음 novel이 해제됨

김개발 씨가 텍스트 처리 프로그램을 만들고 있었습니다. 문자열의 일부를 가리키는 구조체를 만들려고 했습니다.

컴파일러가 또 에러를 냈습니다. "lifetime parameter needed"라는 메시지였습니다.

박시니어 씨가 다가와 설명했습니다. "구조체가 참조를 저장하려면, 그 참조가 얼마나 오래 유효한지 알아야 해요.

구조체가 참조하는 값을 넘어서 살아있으면 안 되니까요." 왜 구조체에서 수명 명시가 필요할까요? 구조체의 인스턴스는 힙이나 스택에 할당됩니다.

참조 필드는 다른 데이터를 가리킵니다. 만약 구조체가 가리키는 데이터가 먼저 사라지면, 댕글링 참조가 발생합니다.

Rust는 이를 방지하기 위해 수명 명시를 요구합니다. ImportantExcerpt 구조체를 보겠습니다.

<'a>는 수명 매개변수입니다. part: &'a str은 part 필드가 수명 'a를 가진 문자열 슬라이스 참조라는 의미입니다.

구조체를 사용할 때 이 수명이 얼마인지 명시할 필요는 없습니다. 컴파일러가 자동으로 추론합니다.

main 함수를 보겠습니다. novel이라는 String을 만들었습니다.

그다음 첫 번째 문장을 추출했습니다. ImportantExcerpt 인스턴스를 만들어 그 문장의 참조를 저장했습니다.

여기서 수명 'a는 novel의 수명과 같습니다. novel이 살아있는 동안만 excerpt도 유효합니다.

만약 novel을 excerpt보다 먼저 스코프에서 제거하려고 하면 어떻게 될까요? 컴파일 에러가 발생합니다.

Rust가 "참조하는 값이 너무 일찍 사라진다"고 알려주는 것이죠. 실무에서는 어떤 경우에 구조체에 참조를 저장할까요?

데이터를 복사하지 않고 기존 데이터의 일부를 가리키고 싶을 때 사용합니다. 예를 들어 큰 텍스트 문서에서 특정 구간을 나타내는 구조체를 만들 때 유용합니다.

전체 텍스트를 복사하지 않고 참조만 저장하면 메모리를 아낄 수 있습니다. 하지만 참조 대신 소유권을 가지는 것이 더 간단할 때도 많습니다.

String을 사용하면 수명 걱정 없이 자유롭게 사용할 수 있습니다. 상황에 따라 적절한 선택이 필요합니다.

실전 팁

💡 - 구조체가 참조를 가지면 수명 명시가 필요합니다

• 구조체의 수명은 참조하는 값의 수명을 넘을 수 없습니다
• 복잡하다면 참조 대신 소유권을 가지는 타입을 고려하세요

---

7. 정적 수명

"수명이 프로그램 전체라고 지정할 수는 없나요?" 김개발 씨가 물었습니다. 박시니어 씨가 고개를 끄덕였습니다.

"있어요. 정적 수명이라고 하죠.

프로그램이 시작될 때부터 끝날 때까지 살아있는 참조예요."

정적 수명은 'static으로 표시하며, 프로그램 전체 기간 동안 유효한 참조입니다. 문자열 리터럴이 대표적인 예입니다.

정적 수명 참조는 프로그램의 바이너리에 직접 저장되어 프로그램이 종료될 때까지 살아있습니다.

다음 코드를 살펴봅시다.

fn main() {
    // 문자열 리터럴은 정적 수명을 가짐
    let s: &'static str = "I have a static lifetime.";

    println!("{}", s);

    // 정적 수명을 명시적으로 사용하는 함수
    let greeting = get_greeting();
    println!("{}", greeting);
}

// 정적 수명을 반환하는 함수
fn get_greeting() -> &'static str {
    "Hello, World!"
}

김개발 씨가 함수에서 문자열을 반환하는 코드를 작성하고 있었습니다. 수명 명시를 해야 하는데, 어떤 수명을 써야 할지 고민이었습니다.

"반환되는 문자열이 프로그램 내내 살아있으면 되는데..." 박시니어 씨가 해결책을 제시했습니다. "그럼 정적 수명을 쓰면 돼요.

'static이라고 쓰면 프로그램 전체 기간 동안 유효한 참조가 됩니다." 정적 수명이란 무엇일까요? 정적 수명은 프로그램이 시작될 때부터 종료될 때까지 유효한 수명입니다.

'static으로 표시합니다. 이 수명을 가진 참조는 프로그램 바이너리의 데이터 섹션에 저장됩니다.

프로그램이 실행되는 동안 항상 같은 주소에 존재합니다. 문자열 리터럴이 대표적인 예입니다.

"Hello, World!" 같은 문자열 리터럴은 컴파일 타임에 바이너리에 저장됩니다. 프로그램이 실행되면 이 문자열은 항상 메모리에 존재합니다.

따라서 어떤 함수에서도 안전하게 참조할 수 있습니다. get_greeting 함수를 보겠습니다.

이 함수는 &'static str을 반환합니다. 문자열 리터럴을 반환하기 때문입니다.

호출하는 쪽에서 수명을 걱정할 필요가 없습니다. 문자열이 프로그램 내내 살아있으니까요.

정적 수명은 언제 사용할까요? 주로 상수 문자열이나 전역 설정값에 사용합니다.

프로그램 전체에서 사용되는 고정된 데이터를 저장할 때 유용합니다. 하지만 모든 참조를 정적 수명으로 만들 수는 없습니다.

동적으로 할당된 데이터는 언젠가 해제되어야 하니까요. 주의할 점도 있습니다.

정적 수명을 너무 자주 사용하면 메모리 사용량이 늘어날 수 있습니다. 데이터가 프로그램 종료까지 메모리에 남기 때문입니다.

필요한 경우에만 사용해야 합니다. 또한 정적 수명 참조는 수정할 수 없습니다.

불변 참조만 가능합니다. 여러 스레드에서 동시에 접근할 수 있어야 하기 때문입니다.

수정이 필요하면 Mutex나 Atomic 타입을 사용해야 합니다. 실무에서는 문자열 상수나 에러 메시지에 자주 사용합니다.

"파일을 찾을 수 없습니다" 같은 고정된 메시지는 정적 수명으로 저장하는 것이 효율적입니다.

실전 팁

💡 - 'static 수명은 프로그램 전체 기간 동안 유효합니다

• 문자열 리터럴은 기본적으로 정적 수명을 가집니다
• 동적 데이터에는 정적 수명을 사용할 수 없습니다

---

8. 수명 하위 타이핑

"수명에도 타입처럼 상속 같은 개념이 있나요?" 김개발 씨가 호기심 있게 물었습니다. 박시니어 씨가 미소를 지었습니다.

"비슷한 게 있어요. 더 긴 수명은 더 짧은 수명의 상위 타입이 될 수 있죠."

수명 하위 타이핑은 긴 수명이 짧은 수명을 대체할 수 있는 개념입니다. 'static은 모든 수명의 상위 타입입니다.

더 오래 사는 참조를 더 짧게 사는 참조가 필요한 곳에 사용할 수 있습니다. 이를 통해 유연한 코드를 작성할 수 있습니다.

다음 코드를 살펴봅시다.

fn main() {
    // 정적 수명 문자열
    let static_str: &'static str = "I live forever";

    // 정적 수명은 더 짧은 수명 위치에 사용 가능
    let result = print_str(static_str);
    println!("{}", result);
}

// 'a 수명을 요구하지만 'static도 허용됨
fn print_str<'a>(s: &'a str) -> &'a str {
    println!("{}", s);
    s
}

김개발 씨가 함수를 호출하다가 이상한 점을 발견했습니다. 함수가 &'a str을 요구하는데, &'static str을 전달해도 잘 작동했습니다.

"이게 왜 되는 거지? 수명이 다른데..." 박시니어 씨가 설명했습니다.

"수명에도 하위 타이핑이 있어요. 더 긴 수명은 더 짧은 수명의 상위 타입이에요.

그래서 'static은 어디든 들어갈 수 있죠." 수명 하위 타이핑이란 무엇일까요? 쉽게 비유하면 큰 상자와 작은 상자의 관계와 같습니다.

큰 상자에 들어갈 수 있는 물건은 작은 상자에도 들어갈 수 있습니다. 마찬가지로 더 긴 수명을 가진 참조는 더 짧은 수명이 필요한 곳에 사용할 수 있습니다.

'static은 가장 긴 수명입니다. 프로그램 전체 기간 동안 살아있습니다.

따라서 모든 수명 매개변수 위치에 사용할 수 있습니다. print_str 함수는 &'a str을 요구합니다.

하지만 &'static str을 전달해도 됩니다. 'static이 'a보다 길거나 같기 때문입니다.

이 개념이 왜 유용할까요? 코드를 더 유연하게 작성할 수 있기 때문입니다.

함수가 특정 수명의 참조를 요구할 때, 호출자가 더 긴 수명의 참조를 가지고 있다면 문제없이 사용할 수 있습니다. 수명을 명시적으로 변환할 필요가 없습니다.

예를 들어 설정값을 읽는 함수를 생각해 봅시다. 함수는 &'a str을 요구합니다.

설정값이 파일에서 읽은 문자열이라면 수명이 제한적입니다. 하지만 기본값이 문자열 리터럴이라면 정적 수명입니다.

두 경우 모두 같은 함수를 사용할 수 있습니다. 실무에서는 언제 이 개념을 접하게 될까요?

주로 라이브러리 함수를 사용할 때입니다. 많은 라이브러리 함수가 수명 매개변수를 사용합니다.

호출할 때 정적 수명 문자열을 전장해도 문제없이 작동합니다. 하위 타이핑 덕분입니다.

주의할 점도 있습니다. 반대 방향은 안 됩니다.

더 짧은 수명을 더 긴 수명이 필요한 곳에 사용할 수 없습니다. 이것은 댕글링 참조를 유발할 수 있기 때문입니다.

실전 팁

💡 - 더 긴 수명은 더 짧은 수명 위치에 사용할 수 있습니다

• 'static은 모든 수명 매개변수 위치에 사용할 수 있습니다
• 반대 방향은 허용되지 않습니다

---

9. 수명 경계

"제네릭 타입에도 수명을 제한할 수 있나요?" 김개발 씨가 질문했습니다. 박시니어 씨가 고개를 끄덕였습니다.

"네, 수명 경계를 사용하면 됩니다. 타입이 특정 수명 이상 살아있어야 한다고 지정할 수 있어요."

수명 경계는 제네릭 타입이 참조를 포함할 때 그 수명을 제한하는 것입니다. T: 'a 형태로 표기하며, 타입 T가 수명 'a보다 오래 살아야 함을 의미합니다.

이를 통해 참조를 포함한 제네릭 타입의 안전성을 보장합니다.

다음 코드를 살펴봅시다.

use std::fmt::Display;

// 수명 경계: T는 'a보다 오래 살아야 함
struct Ref<'a, T: 'a> {
    value: &'a T,
}

fn main() {
    let num = 42;
    let ref_num = Ref { value: &num };

    print_value(&ref_num);
}

fn print_value<'a, T: Display + 'a>(r: &Ref<'a, T>) {
    println!("Value: {}", r.value);
}

김개발 씨가 제네릭 구조체를 만들고 있었습니다. 참조를 저장하는 제네릭 구조체를 만들려는데 컴파일러가 수명 경계를 요구했습니다.

"이건 또 뭐지?" 박시니어 씨가 다가와 설명했습니다. "제네릭 타입 T가 참조를 포함할 수 있어요.

그럼 그 참조의 수명이 구조체의 수명보다 길어야 하죠. 이걸 보장하려고 수명 경계를 사용해요." 수명 경계란 무엇일까요?

수명 경계는 제네릭 타입 매개변수에 수명 조건을 추가하는 것입니다. T: 'a라고 쓰면, 타입 T가 수명 'a보다 오래 살아야 한다는 의미입니다.

T가 참조를 포함한다면, 그 참조의 수명이 'a 이상이어야 합니다. Ref 구조체를 보겠습니다.

<'a, T: 'a>는 두 개의 매개변수를 가집니다. 'a는 수명 매개변수입니다.

T: 'a는 타입 매개변수인데, 수명 경계가 있습니다. T가 'a 이상 살아야 한다는 의미입니다.

왜 이런 경계가 필요할까요? Ref 구조체는 &'a T 타입의 참조를 저장합니다.

이 참조가 유효하려면 T 자체도 'a 동안 살아있어야 합니다. 만약 T가 더 짧은 수명의 참조를 포함한다면, 그 참조가 먼저 사라질 수 있습니다.

그러면 댕글링 참조가 발생합니다. Rust는 이를 방지하기 위해 수명 경계를 요구합니다.

print_value 함수를 보겠습니다. 이 함수는 Ref의 참조를 받아 값을 출력합니다.

T: Display + 'a 경계가 있습니다. T는 Display 트레이트를 구현해야 하고, 수명 'a 이상 살아야 합니다.

실무에서 수명 경계는 언제 필요할까요? 주로 참조를 저장하는 제네릭 컨테이너를 만들 때 필요합니다.

예를 들어 제네릭 참조 래퍼나, 참조를 포함하는 제네릭 구조체를 만들 때 사용합니다. 많은 경우 컴파일러가 자동으로 요구하므로 직접 생각할 필요가 없습니다.

실전 팁

💡 - 수명 경계는 제네릭 타입이 특정 수명 이상 살아야 함을 지정합니다

• T: 'a는 T가 참조를 포함할 때 필요합니다
• 컴파일러가 자동으로 요구하는 경우가 많습니다

---

10. 댕글링 참조 방지 핵심 정리

"지금까지 배운 내용을 정리하면 뭐가 핵심인가요?" 김개발 씨가 물었습니다. 박시니어 씨가 화이트보드에 핵심 포인트들을 적으며 정리해주었습니다.

댕글링 참조 방지를 위한 핵심은 참조의 수명이 가리키는 값의 수명을 넘지 않도록 하는 것입니다. Rust의 소유권 시스템, 수명 명시, 컴파일러 검사가 함께 작동하여 메모리 안전성을 보장합니다.

다음 코드를 살펴봅시다.

fn main() {
    // 핵심 1: 참조는 원본보다 오래 살 수 없음
    let s1 = String::from("hello");
    let r1 = &s1;
    println!("{}", r1); // OK: s1이 살아있음

    // 핵심 2: 함수에서 소유권 이전
    let s2 = create_string();
    println!("{}", s2);

    // 핵심 3: 수명 명시로 관계 표현
    let a = String::from("long string");
    let b = "xyz";
    let long = longest(&a, b);
    println!("Longest: {}", long);
}

fn create_string() -> String {
    String::from("owned value")
}

fn longest<'a>(x: &'a str, y: &'a str) -> &'a str {
    if x.len() > y.len() { x } else { y }
}

김개발 씨가 댕글링 참조에 대해 배운 내용을 정리하고 있었습니다. 여러 개념이 섞여서 헷갈리기 시작했습니다.

박시니어 씨가 정리를 도와주었습니다. "핵심은 간단해요.

참조는 가리키는 값보다 오래 살면 안 된다는 거예요." 첫 번째 핵심은 참조의 수명 제한입니다. 참조는 언제나 가리키는 값보다 짧거나 같은 수명을 가져야 합니다.

이 규칙을 어기면 컴파일 에러가 발생합니다. Rust 컴파일러가 모든 참조의 수명을 추적하고 검사합니다.

두 번째 핵심은 소유권 이전입니다. 함수에서 로컬 변수의 참조를 반환할 수 없습니다.

대신 값을 직접 반환하여 소유권을 넘겨야 합니다. 그러면 호출자가 값을 소유하고 관리합니다.

세 번째 핵심은 수명 명시입니다. 함수가 여러 참조를 받고 그중 하나를 반환할 때, 어떤 참조와 수명을 공유하는지 명시해야 합니다.

컴파일러가 모든 호출 지점에서 안전성을 검증할 수 있습니다. 네 번째 핵심은 자동 추론입니다.

많은 경우 컴파일러가 수명을 자동으로 추론합니다. 입력 참조가 하나뿐이거나 메서드에서 self를 사용할 때가 그렇습니다.

개발자가 명시하지 않아도 됩니다. 다섯 번째 핵심은 정적 수명입니다.

프로그램 전체 기간 동안 유효한 참조가 필요할 때 'static을 사용합니다. 문자열 리터럴이 대표적인 예입니다.

이 모든 것을 통합하는 것이 Rust의 소유권 시스템입니다. 소유권, 빌림, 수명이 함께 작동하여 메모리 안전성을 보장합니다.

개발자는 가비지 컬렉터 없이도 안전한 코드를 작성할 수 있습니다. 박시니어 씨가 마무리했습니다.

"처음에는 복잡해 보일 거예요. 하지만 익숙해지면 자연스러워요.

그리고 런타임에 메모리 버그를 찾아 헤매는 일이 없어져요." 김개발 씨가 고개를 끄덕였습니다. "네, 이제 이해됐어요.

컴파일할 때 잡아주니까 실행해보기도 전에 안전하다는 걸 알 수 있네요."

실전 팁

💡 - 참조는 가리키는 값보다 오래 살 수 없습니다

• 소유권 이전으로 댕글링 참조를 피할 수 있습니다
• 수명 명시는 참조 간의 관계를 명확히 합니다

---

이상으로 학습을 마칩니다. 위 내용을 직접 코드로 작성해보면서 익혀보세요!