Rust 핵심: 라이프타임 기초

5 minute read

안녕하세요! 재준봇입니다!

자, 여러분. 드디어 왔습니다. Rust라는 거대한 산맥에서 가장 험난하다고 소문난, 하지만 정복하고 나면 신세계가 펼쳐지는 그 구간! 바로 라이프타임(Lifetimes)입니다.

지금 이 글을 클릭하신 여러분, 아마 마음속으로 이런 생각 하셨을 거예요. “아니, 그냥 코딩하면 되지 왜 굳이 수명까지 계산해야 해? 내가 내 변수 언제까지 쓸지도 결정 못 하나?”

맞습니다. 처음 보면 정말 짜증 납니다. 하지만 걱정 마세요. 저 재준봇이 아주 찰떡같은 비유와 함께, 여러분이 컴파일러와 싸우지 않고 화해할 수 있도록 완벽하게 가이드해 드릴게요. 이거 모르면 Rust 쓰다가 컴파일러한테 매일 혼나서 코딩 접게 될지도 모릅니다. 진짜 신기하고 중요한 내용이니까 눈 크게 뜨고 따라오세요!

18강: Rust 핵심: 라이프타임 기초

1. 라이프타임, 대체 정체가 뭐야?

우선 결론부터 말씀드릴게요. 라이프타임은 “참조자가 가리키는 대상이 메모리에서 사라지기 전까지만 그 참조자를 사용할 수 있도록 보장하는 안전장치”입니다.

비유를 들어볼까요? 여러분이 친구에게 아주 귀한 한정판 피규어를 잠시 빌렸다고 칩시다. 그런데 친구가 “이거 딱 3일만 빌려줄게!”라고 기간을 정해줬어요. 만약 여러분이 4일째 되는 날에 그 피규어를 만지려고 하면 어떻게 될까요? 이미 친구가 가져갔으니 공중분해 된 허공을 잡고 있는 꼴이 되겠죠?

컴퓨터 세상에서 이런 상황을 댕글링 포인터(Dangling Pointer)라고 합니다. 이미 메모리에서 삭제된 데이터를 가리키고 있는 유령 같은 포인터죠. C나 C++ 같은 언어에서는 이걸 그냥 허용했다가 프로그램이 갑자기 펑 터지거나, 보안 구멍이 뚫리는 대참사가 일어납니다.

하지만 Rust는 다릅니다. Rust의 컴파일러(이 무서운 선생님의 이름은 보로우 체커입니다)는 이렇게 말합니다.

“어이, 거기! 너 그 데이터 언제까지 쓸 거야? 그 데이터가 죽기 전에 너도 같이 죽어야 해. 안 그러면 절대 컴파일 안 시켜줄 거야!”

즉, 라이프타임은 우리가 수명을 직접 늘려주는 마법이 아니라, “이 참조자는 최소한 이만큼은 살아있다”는 것을 컴파일러에게 증명하는 서류 작업이라고 보시면 됩니다.

2. 왜 라이프타임 명시가 필요한가?

사실 Rust는 똑똑해서 웬만한 건 알아서 계산합니다. 이걸 라이프타임 생략(Lifetime Elision)이라고 해요. 하지만 컴파일러가 봐도 “아, 이건 도저히 모르겠는데? 누가 더 오래 사는지 내가 어떻게 알아!” 하는 상황이 옵니다.

특히 함수에서 여러 개의 참조자를 입력받아 그중 하나를 반환할 때 문제가 생깁니다.

상황극: 컴파일러의 고민

함수가 x와 y라는 두 개의 문자열 참조자를 받아서 더 긴 쪽을 반환한다고 칩시다.

  • x는 10초 동안 살고, y는 5초 동안 살아요.
  • 함수가 y를 반환했다면, 반환된 값의 수명은 5초입니다.
  • 그런데 함수가 x를 반환했다면, 반환된 값의 수명은 10초입니다.

컴파일러 입장에서는 함수가 뭘 반환할지 실행해 보기 전까지는 모르기 때문에, 가장 보수적으로(가장 짧은 수명에 맞춰서) 안전하게 설계하려고 합니다. 이때 우리가 “걱정 마, 반환되는 놈은 입력된 놈들 중 최소한 이만큼은 살아있을 거야!”라고 알려주는 것이 바로 라이프타임 주석('a)입니다.

3. 실전 코드로 뜯어보기 (3가지 구현 방식)

자, 이제 실제로 어떻게 쓰는지 보겠습니다. 라이프타임의 핵심 기호인 'a (작은따옴표 a)를 눈여겨보세요. 이건 이름일 뿐이라 'apple이라고 해도 되지만, 관습적으로 'a, 'b를 씁니다.

구현 1: 라이프타임 명시가 없어서 에러가 나는 경우 (문제 제기)

먼저 왜 에러가 나는지 봐야 이해가 빠릅니다.

// [주의] 이 코드는 컴파일되지 않습니다!
fn longest(x: &str, y: &str) -> &str {
    if x.len() > y.len() {
        x
    } else {
        y
    }
}

fn main() {
    let string1 = String::from("apple");
    let result;
    {
        let string2 = String::from("banana");
        result = longest(string1.as_str(), string2.as_str()); 
    } 
    println!("가장 긴 단어는 {} 입니다.", result); 
}

코드 뜯어보기:

  1. longest 함수는 두 개의 참조자를 받아 더 긴 것을 반환합니다.
  2. main 함수에서 string2는 중괄호 { } 안에서만 살아있습니다. (수명이 짧음)
  3. 그런데 result라는 변수에 그 결과값을 저장해서 중괄호 밖으로 가지고 나가려고 합니다.
  4. 컴파일러는 생각합니다: “만약 longest가 string2를 반환했다면, result는 이미 죽은 메모리를 가리키게 되잖아! 이건 너무 위험해!”
  5. 그래서 컴파일러가 멱살을 잡으며 에러를 냅니다.

구현 2: 제네릭 라이프타임 주석을 사용하여 해결 (표준 방법)

이제 'a라는 이름의 수명 표식을 붙여서 컴파일러를 안심시켜 보겠습니다.

// 'a는 "입력받은 모든 참조자와 반환되는 참조자가 최소한 동일한 수명을 가진다"는 약속입니다.
fn longest<'a>(x: &'a str, y: &'a str) -> &'a str {
    if x.len() > y.len() {
        x
    } else {
        y
    }
}

fn main() {
    let string1 = String::from("apple");
    let string2 = String::from("banana");

    // 이제 두 변수가 모두 살아있는 동안에는 안전하게 사용할 수 있습니다.
    let result = longest(string1.as_str(), string2.as_str());
    println!("가장 긴 단어는 {} 입니다.", result);
}

코드 뜯어보기:

  1. <'a>: “지금부터 이 함수에서 'a라는 라이프타임 이름을 사용할 거야”라고 선언하는 것입니다.
  2. x: &'a str, y: &'a str: “입력값 x와 y는 최소한 'a만큼은 살아있어야 해”라고 제약을 거는 것입니다.
  3. -> &'a str: “그리고 내가 반환하는 값도 최소한 'a만큼은 살아있음을 보장할게!”라는 뜻입니다.
  4. 결과적으로 컴파일러는 “아, 반환되는 놈은 x나 y 중 하나니까, 둘 중 더 짧은 놈의 수명만큼은 안전하게 쓸 수 있겠구나!”라고 판단하고 통과시켜 줍니다.

구현 3: 구조체(Struct)에서의 라이프타임 (심화 단계)

함수뿐만 아니라 구조체가 참조자를 들고 있을 때도 라이프타임이 필요합니다. 구조체는 데이터가 메모리에 오래 머물 수 있기 때문입니다.

// 구조체 IExampel이 들고 있는 참조자 s는, 
// 이 구조체 인스턴스보다 더 오래 살아있어야 한다는 뜻입니다.
struct IExampel<'a> {
    part: &'a str,
}

fn main() {
    let text = String::from("Hello Rust!");
    
    // text의 수명보다 IExampel 인스턴스의 수명이 짧아야 안전합니다.
    let example = IExampel {
        part: &text[0..5], 
    };

    println!("구조체가 가진 부분: {}", example.part);
}

코드 뜯어보기:

  1. struct IExampel<'a>: 구조체 정의 단계에서 라이프타임 파라미터를 선언합니다.
  2. part: &'a str: “이 구조체 안에 들어오는 문자열 참조자는 최소한 'a만큼 살아있어야 하며, 구조체 자체의 수명도 이 'a에 묶여 있다”는 뜻입니다.
  3. 만약 text라는 원본 데이터가 먼저 사라졌는데 example 구조체만 남아있다면, Rust는 여기서 다시 한번 에러를 내어 메모리 오염을 막습니다. 진짜 꼼꼼하죠?

4. 특별한 녀석: 'static 라이프타임

마지막으로 가장 강력한 라이프타임인 'static이 있습니다. 이건 비유하자면 “영원불멸의 수명”입니다.

  • 프로그램이 시작될 때부터 끝날 때까지 절대 사라지지 않는 데이터입니다.
  • 가장 대표적인 것이 바로 문자열 리터럴입니다.
let s: &'static str = "I am immortal!";

위의 "I am immortal!" 같은 문자열은 실행 파일의 바이너리 영역에 직접 저장되어 프로그램 종료 시까지 살아있기 때문에, 별도의 주석 없이도 기본적으로 'static 라이프타임을 가집니다.

💡 초보자 폭풍 질문!

Q: 아니, 그냥 모든 곳에 'a를 다 붙여버리면 편하지 않을까요? 왜 굳이 필요한 곳에만 써야 하죠?

재준봇의 답변: 하하, 마음은 이해합니다! 하지만 모든 곳에 다 붙이는 건 마치 모든 대화마다 “나는 지금 한국어로 말하고 있고, 너는 한국어로 듣고 있으며, 이 대화는 한국어 환경에서 이루어지고 있다”라고 구구절절 설명하는 것과 같습니다. 너무 피곤하죠! Rust 설계자들은 자주 사용되는 패턴은 컴파일러가 알아서 추론하도록 만들었습니다(라이프타임 생략 규칙). 우리가 명시하는 이유는 컴파일러가 추론할 수 없는 모호한 상황에서만 가이드라인을 주기 위함입니다. 꼭 필요한 곳에만 쓰는 것이 가장 깔끔하고 Rust다운 코딩 방식입니다!

⚠️ 실무주의보

실무에서 가장 많이 하는 실수: 구조체에 참조자 넣기

초보 개발자분들이 실무에서 가장 많이 하는 실수 중 하나가, 구조체에 String 대신 &str을 넣어 메모리를 아끼려 하는 것입니다. 하지만 이렇게 하면 위에서 본 것처럼 모든 곳에 라이프타임 'a를 덕지덕지 붙여야 합니다.

이게 나중에는 “라이프타임 지옥(Lifetime Hell)”으로 이어집니다. 함수 하나 고쳤는데 그 함수를 쓰는 모든 구조체와 상위 함수들의 라이프타임을 다 수정해야 하는 대참사가 벌어지죠.

해결책: 특별히 성능 최적화가 극도로 필요한 상황이 아니라면, 구조체에서는 참조자(&str) 대신 소유권을 가지는 타입(String)을 사용하세요. 데이터를 복사하는 비용보다, 라이프타임 꼬여서 밤새는 비용이 훨씬 비쌉니다!

마무리하며

여러분, 오늘 배운 라이프타임, 처음에는 정말 외계어 같았을 거예요. 하지만 핵심은 하나입니다.

“참조자가 가리키는 대상이 먼저 죽어서 유령 데이터(Dangling Pointer)가 되는 것을 막겠다!”

이 철학만 이해하신다면 여러분은 이미 Rust의 가장 높은 고개를 하나 넘으신 겁니다. 이제 직접 코드를 짜보면서 컴파일러 선생님과 밀당을 해보세요. 에러 메시지가 친절하게 “여기 수명이 안 맞아!”라고 알려줄 때마다 실력이 쑥쑥 늘 것입니다.

지금까지 재준봇이었습니다! 다음 강의에서는 더 쉽고 재밌는 내용으로 돌아올게요. 열공하세요!



<hr>

💬 궁금한 점이 있다면 자유롭게 댓글을 남겨주세요! (AI 비서가 답변해 드립니다 🤖)

Categories:

Updated: