C++ 댕글링 레퍼런스: 지역 변수 반환·임시 객체·컨테이너 요소에서 생기는 원인과 탐지

Dangling Reference란?

소멸된 객체를 참조하는 레퍼런스

참조(reference)는 포인터와 달리 “값을 담는 변수”가 아니라 이미 존재하는 객체에 붙이는 또 다른 이름에 가깝습니다 — 참조 자체는 별도의 메모리 검사 없이 그 대상이 항상 유효하다고 가정하고 동작하도록 설계되어 있어, nullptr 검사 같은 안전장치가 애초에 언어 차원에서 존재하지 않습니다. func()가 지역 변수 s에 대한 참조를 반환하면, 함수가 끝나는 순간 s는 스택에서 소멸되어 그 메모리는 다른 용도로 재사용될 수 있는 상태가 되는데, 반환된 참조는 이 사실을 전혀 모른 채 여전히 그 (이제는 무효한) 메모리 주소를 계속 가리킵니다. 이것이 위험한 이유는 ref를 읽는 시점에 컴파일러도 런타임도 이 문제를 자동으로 감지하지 못하고, 정의되지 않은 동작으로 조용히 넘어간다는 데 있습니다 — 운이 나쁘면 크래시하지만, 운이 좋으면(더 나쁘게도) 우연히 이전 값이 메모리에 남아있어 정상적으로 동작하는 것처럼 보이다가 다른 상황에서만 실패합니다.

// ❌ 댕글링 레퍼런스
const std::string& func() {
    std::string s = "Hello";
    return s;  // s는 함수 종료 시 소멸
}

int main() {
    const std::string& ref = func();
    // ref는 소멸된 객체 참조 (위험!)
}

발생 원인

네 가지 원인은 겉모습이 다르지만 모두 같은 패턴을 공유합니다 — “참조나 포인터가 가리키는 대상의 수명이, 그 참조/포인터 자신의 수명보다 먼저 끝난다”는 것입니다. func1은 스택에 있는 지역 변수가 함수 반환과 동시에 소멸되는 경우이고, func2는 std::string("Hello")라는 임시 객체가 c_str() 호출이 끝나는 세미콜론 지점에서 소멸되어(임시 객체는 그것이 속한 전체 표현식이 끝나면 사라집니다) 그 포인터가 즉시 무효화되는 경우입니다. func3은 vec이라는 지역 컨테이너 자체가 함수 종료와 함께 소멸되어 그 원소를 가리키던 참조도 함께 무효화되는 경우이고, func4는 delete로 메모리를 명시적으로 해제한 뒤에도 그 포인터를 계속 참조하려 시도하는 경우입니다. 이 네 원인을 관통하는 하나의 질문은 “이 참조/포인터가 가리키는 실제 메모리가 지금 이 순간에도 유효한가”이며, 댕글링 버그를 예방하는 습관은 결국 이 질문을 참조를 만들 때마다 스스로에게 던지는 것입니다.

// 1. 지역 변수 반환
const int& func1() {
    int x = 10;
    return x;  // x 소멸
}

// 2. 임시 객체
const char* func2() {
    return std::string("Hello").c_str();  // 임시 객체 소멸
}

// 3. 컨테이너 요소
const int& func3() {
    std::vector<int> vec = {1, 2, 3};
    return vec[0];  // vec 소멸
}

// 4. 포인터 역참조
int& func4() {
    int* ptr = new int(10);
    delete ptr;
    return *ptr;  // 해제된 메모리
}

실전 예시

예시 1: 함수 반환

값 반환이 안전한 이유는 반환값 자체가 호출자 쪽에 새로 생성되는 독립적인 객체이기 때문입니다 — C++17부터 보장된 복사 생략(guaranteed copy elision) 덕분에 return name;은 대부분의 경우 실제 복사조차 없이 name이 호출자의 반환값 저장 위치에 직접 구성되므로, “안전을 위해 값 반환을 쓰면 성능을 희생한다”는 통념은 최신 C++에서는 대체로 사실이 아닙니다. static 지역 변수를 참조로 반환하는 것이 안전한 이유는 다릅니다 — static 변수는 함수 호출과 무관하게 프로그램이 끝날 때까지 존재하는 정적 저장 기간을 가지므로, 함수가 반환되어도 그 변수는 소멸되지 않고 계속 살아있습니다. 다만 이 정적 변수 방식은 모든 호출이 같은 객체를 공유한다는 부작용을 동반하므로(멀티스레드 환경에서의 동시 접근 문제 포함), 매번 새로운 독립적인 값이 필요하다면 값 반환이 여전히 더 안전한 기본 선택입니다.

#include <string>

// ❌ 지역 변수 레퍼런스 반환
const std::string& getName() {
    std::string name = "Alice";
    return name;  // 위험!
}

// ✅ 값 반환
std::string getName() {
    std::string name = "Alice";
    return name;  // 안전 (복사 또는 이동)
}

// ✅ 정적 변수 반환
const std::string& getStaticName() {
    static std::string name = "Alice";
    return name;  // 안전
}

int main() {
    auto name1 = getName();  // 안전
    const auto& name2 = getStaticName();  // 안전
}

예시 2: 임시 객체

getVector()[0]이 위험한 이유를 정확히 짚어보면, getVector()가 반환하는 vector<int> 임시 객체는 그 값을 즉시 어딘가에 저장하지 않는 한 그 표현식이 포함된 전체 문장이 끝나는 세미콜론에서 소멸됩니다 — [0]으로 원소를 참조한 것은 그 임시 벡터의 내부 버퍼를 가리키는 참조인데, 벡터 자체가 소멸되면 그 내부 버퍼도 함께 해제되므로 badFirst는 이미 해제된 메모리를 가리키게 됩니다. const auto& vec2 = getVector();가 안전한 이유는 C++의 특별한 규칙(임시 객체를 const 참조에 바인딩하면 그 임시 객체의 수명이 참조의 수명까지 연장된다) 덕분입니다 — 다만 이 수명 연장은 정확히 그 참조 변수 하나에만 적용되며, vec2[0]처럼 그로부터 파생된 다른 참조에는 전이되지 않는다는(하지만 vec2가 살아있는 한 그 내부 데이터도 살아있으므로 first2는 안전합니다) 미묘함이 있어 이 규칙에 지나치게 의존하기보다 명확하게 값을 저장하는 편이 더 안전한 습관입니다.

#include <vector>

// ❌ 임시 객체 레퍼런스
std::vector<int> getVector() {
    return {1, 2, 3};
}

int main() {
    // ❌ 임시 객체 즉시 소멸
    const int& badFirst = getVector()[0];
    // getVector()의 임시 객체 소멸

    // ✅ 컨테이너 저장
    auto vec = getVector();
    const int& first = vec[0];  // 안전

    // ✅ 수명 연장
    const auto& vec2 = getVector();
    const int& first2 = vec2[0];  // 안전
}

예시 3: 컨테이너 요소

data[key]가 위험한 이유는 std::map::operator[]의 흔히 간과되는 동작 때문입니다 — 이 연산자는 key가 맵에 없으면 그 자리에 기본 생성된 새 값을 조용히 삽입한 뒤 그 값에 대한 참조를 반환합니다(찾기 실패를 알려주는 대신). 이 자체는 댕글링 문제라기보다 “조회했을 뿐인데 맵의 내용이 바뀌는” 놀라움에 가깝지만, 반환된 참조가 이후 맵이 재조정(rehash)되거나 그 키가 삭제되면 무효화될 수 있다는 점에서 실질적인 위험이 있습니다. find를 쓰면 존재 여부를 확인만 하고 값을 변경하지 않으므로 이런 부작용이 없고, getValuePtr처럼 포인터를 반환하는 방식은 “값을 찾지 못했다”는 경우를 nullptr로 명시적으로 표현할 수 있어 호출자가 그 실패 가능성을 놓치기 어렵게 만듭니다 — 참조는 “항상 유효한 무언가를 가리킨다”는 것을 문법적으로 약속하는 타입이라 애초에 “없을 수도 있음”을 표현하기에 적합하지 않습니다.

#include <map>
#include <string>

class Database {
private:
    std::map<int, std::string> data;
    
public:
    // ❌ 임시 맵 요소 반환
    const std::string& getValue(int key) {
        return data[key];  // data[key]가 없으면 임시 생성
    }
    
    // ✅ 값 반환 또는 optional
    std::string getValue(int key) {
        auto it = data.find(key);
        return it != data.end() ? it->second : "";
    }
    
    // ✅ 포인터 반환
    const std::string* getValuePtr(int key) {
        auto it = data.find(key);
        return it != data.end() ? &it->second : nullptr;
    }
};

예시 4: 멤버 변수

getName()이 안전한 이유는 name이 Widget 객체 자신의 멤버이기 때문입니다 — 그 객체가 살아있는 한 name도 함께 살아있으므로, 참조의 수명이 객체의 수명 안에 정확히 포함됩니다(호출자가 Widget 객체를 참조보다 먼저 파괴하지 않는 한). getUpperName()의 문제는 미묘한데, toUpper(name)이 name을 그대로 참조하는 것이 아니라 새로운 임시 문자열 객체를 만들어 반환하기 때문입니다 — 이 임시 객체는 getUpperName() 함수가 반환되는 시점에 소멸되므로, 그것을 참조로 돌려주는 것은 예시 2에서 다룬 “임시 객체를 참조로 돌려주는” 문제와 정확히 같은 패턴입니다. 멤버 변수 자체를 그대로 참조로 반환하는 것과, 그 멤버로부터 새로 계산된 값을 참조로 반환하는 것은 겉보기엔 비슷해 보여도 안전성이 완전히 다르다는 것이 이 대비가 보여주는 핵심입니다.

class Widget {
private:
    std::string name;
    
public:
    Widget(const std::string& n) : name(n) {}
    
    // ✅ 멤버 변수 레퍼런스 (안전)
    const std::string& getName() const {
        return name;
    }
    
    // ❌ 임시 객체 반환
    const std::string& getUpperName() const {
        return toUpper(name);  // 임시 객체
    }
    
    // ✅ 값 반환
    std::string getUpperName() const {
        return toUpper(name);
    }
    
private:
    std::string toUpper(const std::string& s) const {
        std::string result = s;
        // 대문자 변환
        return result;
    }
};

자주 발생하는 문제

문제 1: 반복자 무효화

std::vector는 원소들을 하나의 연속된 메모리 블록에 저장하는데, push_back으로 현재 용량을 초과하는 원소를 추가하면 벡터는 더 큰 새 블록을 할당하고 기존 원소들을 그리로 옮긴 뒤 원래 블록을 해제합니다 — 이 재할당이 일어나면 이전 블록을 가리키던 모든 참조·포인터·반복자는 이제 해제된 메모리를 가리키는 댕글링 상태가 됩니다. 문제는 이 재할당이 매번 일어나는 것이 아니라 벡터의 현재 용량(capacity)을 실제로 초과할 때만 일어난다는 점인데, 이는 곧 같은 코드가 어떤 상황에서는 우연히 안전하게 동작하다가(용량에 여유가 있어 재할당이 없는 경우) 다른 상황에서만 크래시를 낼 수 있다는 뜻입니다 — 이런 “가끔만 재현되는” 특성이 이 버그를 특히 찾기 어렵게 만듭니다. reserve()로 미리 충분한 용량을 확보해 재할당 자체를 방지하거나, 참조를 미리 만들어 두지 말고 필요할 때마다 인덱스로 새로 접근하는 것이 안전한 습관입니다.

#include <vector>

std::vector<int> vec = {1, 2, 3};

// ❌ 반복자 무효화
auto& ref = vec[0];
vec.push_back(4);  // 재할당 가능
// ref는 무효화될 수 있음

// ✅ 재할당 후 다시 참조
vec.push_back(4);
auto& ref = vec[0];

문제 2: 스마트 포인터

스마트 포인터를 쓰면 메모리 해제 시점을 명시적인 delete 대신 소유권 규칙에 맡길 수 있지만, 그렇다고 댕글링 참조 문제 자체가 사라지는 것은 아닙니다 — ptr->value에 대한 참조 ref를 만들어 둔 뒤 ptr.reset()으로 unique_ptr가 가리키던 Data 객체를 명시적으로 해제하면, ref는 정확히 원시 포인터를 delete했을 때와 같은 방식으로 댕글링됩니다. 이는 스마트 포인터가 “포인터가 가리키는 메모리를 언제 해제할지”를 관리해 줄 뿐, “그 메모리를 참조하는 다른 참조들이 어딘가에 남아있는지”까지는 추적하지 못하기 때문입니다. int value = ptr->value;처럼 참조가 아니라 값을 복사해 두면, 그 이후 원본 Data 객체가 어떻게 되든 value는 완전히 독립적인 자신만의 사본을 가지므로 이런 위험 자체가 성립하지 않습니다 — 스마트 포인터가 가리키는 대상에서 값을 꺼내 오래 보관해야 한다면, 참조보다 복사가 근본적으로 더 안전한 이유입니다.

#include <memory>

class Data {
public:
    int value = 42;
};

// ❌ 소유권 이전 후 참조
std::unique_ptr<Data> getData() {
    return std::make_unique<Data>();
}

int main() {
    auto ptr = getData();
    int& ref = ptr->value;
    
    ptr.reset();  // 메모리 해제
    // ref는 댕글링
}

// ✅ shared_ptr 또는 값 복사
int main() {
    auto ptr = std::make_shared<Data>();
    int value = ptr->value;  // 값 복사
    
    ptr.reset();
    // value는 안전
}

문제 3: 람다 캡처

[&x]로 참조 캡처된 람다는 내부적으로 x의 주소만 저장해 두고, 나중에 그 람다가 호출될 때 그 주소를 다시 역참조해 값을 읽습니다 — createGetter()가 반환된 시점에 지역 변수 x는 이미 스택에서 소멸되었으므로, 이후 getter()를 호출해 그 람다의 본문이 실행되는 순간 x의 주소는 이미 무효한 메모리를 가리키고 있습니다. 이 문제가 특히 위험한 이유는 람다를 만드는 시점(createGetter() 내부)에는 x가 멀쩡히 살아있어 아무 문제가 없어 보인다는 것입니다 — 실제 문제는 그 람다가 나중에, 원래 스코프를 벗어난 시점에 호출될 때만 드러나므로, 참조 캡처의 위험성은 람다를 만드는 코드가 아니라 그 람다를 호출하는 코드의 타이밍에 달려 있습니다. [x]처럼 값으로 캡처하면 람다 객체 생성 시점에 x의 값이 그대로 복사되어 람다 내부에 독립적으로 저장되므로, 원본 x가 소멸된 이후에도 안전하게 그 값을 사용할 수 있습니다 — 람다가 원래 스코프보다 더 오래 살아남을 가능성이 있다면(반환되거나, 비동기로 실행되거나, 다른 객체에 저장되는 경우) 값 캡처를 기본으로 삼아야 합니다.

#include <functional>

// ❌ 지역 변수 레퍼런스 캡처
std::function<int()> createGetter() {
    int x = 10;
    return [&x]() { return x; };  // x 소멸
}

int main() {
    auto getter = createGetter();
    int value = getter();  // 위험!
}

// ✅ 값 캡처
std::function<int()> createGetter() {
    int x = 10;
    return [x]() { return x; };  // 안전
}

문제 4: 체이닝

메서드 체이닝(obj.method1().method2())은 각 메서드가 *this에 대한 참조를 반환해 다음 메서드를 이어 호출할 수 있게 하는 패턴인데, createBuilder().append("Hello")처럼 그 체인의 첫 객체 자체가 임시 객체라면 다른 함정이 기다리고 있습니다 — append가 반환하는 Builder&는 그 임시 Builder 객체를 가리키는 참조인데, 이 임시 객체는 체인 전체가 포함된 전체 표현식이 끝나는 세미콜론에서 소멸됩니다. auto& builder = ...처럼 그 참조를 별도 변수에 저장해 두려는 시도는, 저장하는 순간 이미 그 원본 임시 객체는 이번 문장이 끝나며 사라질 운명이므로 builder는 즉시 댕글링 참조가 됩니다. auto builder = createBuilder().append("Hello");처럼 auto&가 아니라 auto(값)로 받으면, append가 반환한 참조가 가리키는 Builder 객체(사실 createBuilder()가 만든 바로 그 임시 객체입니다)를 그 자리에서 복사(또는 이동)해 완전히 독립적인 새 객체로 만들므로 이후 원본 임시 객체가 소멸되어도 아무 영향이 없습니다.

class Builder {
private:
    std::string data;
    
public:
    // ❌ 임시 객체 반환
    Builder& append(const std::string& s) {
        data += s;
        return *this;
    }
};

Builder createBuilder() {
    return Builder();
}

int main() {
    // ❌ 임시 객체 체이닝
    auto& builder = createBuilder().append("Hello");
    // createBuilder()의 임시 객체 소멸
    
    // ✅ 값으로 받기
    auto builder = createBuilder().append("Hello");
}

탐지 방법

세 가지 방법은 각각 다른 시점에 문제를 발견하며, 서로를 대체하기보다 보완합니다. 컴파일러 경고(-Wreturn-local-addr, -Wreturn-stack-address)는 “지역 변수의 주소나 참조를 그대로 반환하는” 가장 명백한 패턴만 컴파일 타임에 정적으로 잡아내며, 비용이 전혀 없다는 장점이 있지만 예시 2·3·4처럼 간접적인 경로로 발생하는 댕글링은 놓칠 수 있습니다. Clang Static Analyzer나 Cppcheck 같은 정적 분석 도구는 코드를 실제로 실행하지 않고도 더 넓은 범위의 데이터 흐름을 추적해 컴파일러보다 정교한 패턴까지 잡아낼 수 있지만, 그만큼 분석 시간이 오래 걸리고 오탐(false positive)도 나올 수 있습니다. AddressSanitizer나 Valgrind 같은 런타임 검사 도구는 실제로 프로그램을 실행하며 해제된 메모리에 접근하는 순간을 정확히 잡아내므로 가장 확실하지만, 그 코드 경로가 실제로 실행되어야만(즉 테스트가 그 버그를 실제로 트리거해야만) 발견할 수 있다는 근본적 한계가 있습니다 — 이 세 가지를 함께 쓰는 것이 실무에서 가장 견고한 방어선입니다.

// 1. 컴파일러 경고
// -Wreturn-local-addr (GCC)
// -Wreturn-stack-address (Clang)

// 2. 정적 분석 도구
// - Clang Static Analyzer
// - Cppcheck
// - PVS-Studio

// 3. 런타임 검사
// - AddressSanitizer
// - Valgrind

해결 방법

이 다섯 가지 해법을 관통하는 공통 원리는 “참조/포인터가 가리키는 대상의 수명을, 그 참조를 실제로 사용하는 코드의 수명보다 항상 더 길게 만든다”는 것입니다 — 값 반환은 아예 새로운 독립 객체를 만들어 수명 문제 자체를 없애고, 스마트 포인터는 참조 카운팅이나 명확한 소유권으로 수명을 관리하며, 출력 매개변수는 호출자가 이미 소유한 객체에 값을 채워 넣어 애초에 함수 내부에서 새 객체를 만들 필요조차 없앱니다. 정적 변수와 멤버 변수는 그 저장 기간(프로그램 전체, 또는 소유 객체와 동일)이 참조를 쓰려는 코드의 수명보다 확실히 길다는 것을 구조적으로 보장하는 방식입니다. 어떤 해법을 선택할지는 “이 값이 얼마나 오래 살아있어야 하는가”라는 질문에 대한 답에 따라 자연스럽게 결정됩니다 — 함수 호출마다 새 값이 필요하면 값 반환, 여러 곳에서 공유해야 하면 스마트 포인터, 이미 존재하는 버퍼를 채우기만 하면 되면 출력 매개변수를 선택하는 식입니다.

// 1. 값 반환
std::string func() {
    std::string s = "Hello";
    return s;  // 복사 또는 이동
}

// 2. 스마트 포인터
std::shared_ptr<Data> func() {
    return std::make_shared<Data>();
}

// 3. 출력 매개변수
void func(std::string& out) {
    out = "Hello";
}

// 4. 정적 변수
const std::string& func() {
    static std::string s = "Hello";
    return s;
}

// 5. 멤버 변수
class Widget {
    std::string name;
public:
    const std::string& getName() const {
        return name;  // 안전
    }
};

FAQ

Q1: Dangling Reference는 언제?

A:

• 지역 변수 반환
• 임시 객체 참조
• 소멸된 객체 접근

Q2: 탐지 방법은?

A:

• 컴파일러 경고
• 정적 분석 도구
• AddressSanitizer

Q3: 해결 방법은?

A:

• 값 반환
• 스마트 포인터
• 정적 변수

Q4: 성능 영향은?

A:

• 값 반환: RVO/이동으로 최적화
• 스마트 포인터: 약간의 오버헤드

Q5: 안전한 레퍼런스는?

A:

• 멤버 변수
• 정적 변수
• 매개변수

Q6: Dangling Reference 학습 리소스는?

A:

• “Effective C++”
• “C++ Core Guidelines”
• cppreference.com

---

같이 보면 좋은 글

• C++ use-after-free: 해제 후 사용이 생기는 패턴과 ASan·gdb로 추적하기
• C++ 버퍼 오버플로우: strcpy·오프바이원 실수가 생기는 원리와 방지·탐지 방법
• C++ 객체 수명과 저장 기간: 생성·소멸 순서, 임시 객체 수명, 댕글링 참조
• std::optional로 ‘값 없음’ 표현하기: value_or, C++23 and_then·transform, 에러 처리 패턴
• C++ 참조