메모리 누수 탐지

C++과 같은 언어에서 동적 메모리 할당을 사용하는 경우, 또 다른 종류의 치명적인 오류가 발생할 수 있습니다.

바로 메모리 누수(Memory Leak)입니다.

메모리 누수는 당장은 눈에 띄지 않지만, 프로그램의 성능 저하와 결국에는 시스템 전체의 안정성을 위협할 수 있는 심각한 문제입니다.

이번 장에서는 메모리 누수가 무엇인지 이해하고, 이를 탐지하고 해결하기 위한 다양한 기법과 도구들을 학습하겠습니다.

먼저 아래 다이어그램으로 힙 블록의 해제 책임을 잃는 순간이 어떻게 누수로 이어지는지 확인합니다.

메모리 누수란 무엇인가?

메모리 누수는 프로그램이 동적으로 할당한 메모리(예: new 연산자를 통해 힙에 할당된 메모리)를 더 이상 사용하지 않음에도 불구하고, 해당 메모리를 해제해 할당자가 재사용할 수 있게 하지 않아 발생하는 현상입니다.

이렇게 반환되지 않은 메모리는 프로그램이 종료될 때까지 다른 용도로 재사용될 수 없으며, 마치 물이 새는 것처럼 계속 쌓여갑니다.

• 성능 저하: 사용 가능한 물리 메모리가 줄어들어 운영체제가 가상 메모리(페이징 파일)를 더 자주 사용하게 되고, 이는 디스크 I/O를 유발하여 프로그램의 속도를 현저히 떨어뜨립니다.
• 시스템 불안정: 결국에는 시스템의 사용 가능한 메모리를 모두 소진시켜 다른 프로그램이나 운영체제 자체의 오작동 또는 강제 종료를 유발할 수 있습니다.
• 찾기 어려움: 당장 프로그램이 크래시되지 않아 발견하기 어렵고, 누수가 서서히 진행되기 때문에 원인을 파악하기가 매우 어렵습니다.

• new 또는 malloc으로 메모리를 할당했지만, 해당 메모리에 대한 delete 또는 free 호출을 누락한 경우.
• 포인터 변수가 스코프를 벗어나거나 재할당되어 이전에 할당된 메모리 주소를 잃어버린 경우.
• 예외 발생 등으로 delete 호출이 건너뛰어진 경우 (RAII를 사용하지 않았을 때).

스마트 포인터를 이용한 예방

소유권 상황에 따라 unique_ptr·shared_ptr·weak_ptr을 구별하고 소유자 소멸이 해제 책임으로 이어지는지 확인합니다.

가장 좋은 메모리 누수 탐지 및 해결책은 바로 예방입니다.

현대 C++에서는 스마트 포인터(Smart Pointer)를 사용하여 동적 메모리 관리를 자동화하고 메모리 누수를 효과적으로 방지할 수 있습니다. (14장 3절 스마트 포인터 참조)

• std::unique_ptr
  • 단일 소유권(exclusive ownership)을 가지는 스마트 포인터입니다.
  • unique_ptr 객체가 스코프를 벗어나 소멸될 때, 비어 있지 않다면 설정된 삭제자를 호출합니다. 이 절의 단일 객체·기본 삭제자 예제에서는 delete로 객체를 소멸하고 메모리를 해제합니다.
  • 소유자의 해제 책임을 연결해 메모리 누수를 예방합니다. 하지만 get()으로 얻은 raw 관찰 포인터(dangling pointer가 될 수 있는 포인터)의 수명을 자동으로 연장하지는 않습니다.
• std::shared_ptr
  • 공유 소유권(shared ownership)을 가지는 스마트 포인터입니다.
  • 참조 카운팅(reference counting) 방식을 사용하여, 같은 소유 그룹의 마지막 강한 소유권이 사라질 때 관리 객체를 설정된 삭제자로 정리합니다. 이 절의 기본 삭제자 예제에서는 delete에 해당하는 객체 정리가 이때 일어납니다. 모든 shared_ptr 변수 자체의 스코프 종료만이 아니라 reset·대입도 소유권을 줄일 수 있습니다.
  • 순환 참조(circular reference) 시 메모리 누수가 발생할 수 있으므로 주의해야 합니다 (이 경우 std::weak_ptr 사용).

#include <iostream>
#include <memory> // std::unique_ptr, std::shared_ptr을 위해

class MyClass {
public:
    int value;
    MyClass(int v) : value(v) {
        std::cout << "MyClass(" << value << ") created.\n";
    }
    ~MyClass() {
        std::cout << "MyClass(" << value << ") destroyed.\n";
    }
};

void leaky_function() {
    // raw pointer 사용: delete 호출을 잊으면 메모리 누수 발생
    MyClass* obj_ptr = new MyClass(1);
    // obj_ptr을 delete 하는 것을 잊었다면 누수
    // delete obj_ptr; // 이 라인이 없으면 누수
} // obj_ptr 스코프 벗어나도 힙 메모리는 해제되지 않음

void safe_unique_ptr_function() {
    // std::unique_ptr 사용: 스코프 벗어날 때 자동 해제
    std::unique_ptr<MyClass> obj_uptr = std::make_unique<MyClass>(2);
    // 아무것도 하지 않아도 자동으로 delete 호출
} // obj_uptr 소멸, MyClass(2) 자동 해제

void safe_shared_ptr_function() {
    // std::shared_ptr 사용: 참조 카운트가 0이 될 때 자동 해제
    std::shared_ptr<MyClass> obj_sptr1 = std::make_shared<MyClass>(3);
    std::shared_ptr<MyClass> obj_sptr2 = obj_sptr1; // 참조 카운트 증가

} // obj_sptr1, obj_sptr2 모두 소멸될 때 MyClass(3) 자동 해제

int main() {
    std::cout << "--- Calling leaky_function ---\n";
    leaky_function(); // 메모리 누수 발생 가능성

    std::cout << "\n--- Calling safe_unique_ptr_function ---\n";
    safe_unique_ptr_function(); // 자동 해제

    std::cout << "\n--- Calling safe_shared_ptr_function ---\n";
    safe_shared_ptr_function(); // 자동 해제

    std::cout << "\n--- Program finished ---\n";
    return 0;
}

예시

위의 누수 예제는 MyClass(1)의 생성 출력 뒤 소멸 출력이 없고, MyClass(2)·MyClass(3)은 해당 소유자의 정리 때 소멸 출력이 나옵니다. 소멸 출력만으로 모든 메모리 누수를 증명하거나 배제할 수는 없지만 해제 책임을 추적하는 첫 단서입니다. 다음 별도 프로그램은 누수를 만들지 않고 관찰·이동·정리의 경계를 확인합니다. C++14 이상이 필요합니다.

#include <iostream>
#include <memory>
#include <utility>

struct Tracked {
    int value;
    explicit Tracked(int v) : value(v) { std::cout << "create " << value << '\n'; }
    ~Tracked() { std::cout << "destroy " << value << '\n'; }
};

int main() {
    auto owner = std::make_unique<Tracked>(7);
    Tracked* observer = owner.get(); // 관찰만 하고 해제 책임은 갖지 않음
    std::cout << observer->value << '\n';
    auto next_owner = std::move(owner);
    std::cout << bool(owner) << " : " << bool(next_owner) << '\n';
    next_owner.reset(); // destroy7은 여기서 발생
    observer = nullptr; // 해제 뒤에는 역참조하지 않음
    std::cout << bool(owner) << " : " << bool(next_owner) << '\n';

    auto first = std::make_shared<Tracked>(9);
    auto second = first;
    first.reset(); // second가 아직 강한 소유권을 유지
    std::cout << second->value << '\n';
    second.reset(); // 마지막 강한 소유권이 사라져 destroy9
}

출력 순서는 create 7, 7, 0 : 1, destroy 7, 0 : 0, create 9, 9, destroy 9입니다. owner를 이동해도 그 객체는 바로 소멸하지 않고 next_owner가 책임을 받습니다. reset 뒤 observer의 옛 주소를 역참조하면 안 됩니다. 포인터 변수에 nullptr를 넣는 행위가 힙 객체를 해제한 것이 아니라, 앞선 소유자의 reset이 해제했습니다.

독립 확인: next_owner.reset을 호출하기 전에 owner.reset을 먼저 호출하면 Tracked(7)이 소멸하나요? first.reset 뒤 second가 살아 있을 때 Tracked(9)은 소멸하나요? 끝으로 next_owner.release로 raw 주소를 받았다면 reset과 달리 누구에게 해제 책임이 남는지도 설명하세요.

새로운 C++ 코드를 작성할 때는 특별한 이유가 없다면 항상 스마트 포인터를 사용하여 동적 메모리를 관리하는 습관을 들여야 합니다.

메모리 누수 탐지 도구 (Memory Leak Detectors)

아무리 스마트 포인터를 사용해도 레거시 코드나 특정 라이브러리 사용 시, 또는 복잡한 시나리오에서는 여전히 메모리 누수가 발생할 수 있습니다.

이때 메모리 누수 탐지 도구를 함께 사용합니다.

// leaky_program.cpp
#include <iostream>
#include <vector>

void create_leak() {
    int* p_int = new int(10); // 할당했지만 delete 하지 않음
    // p_int를 사용 후 버려짐.
    std::cout << "Leaked int at " << p_int << " with value " << *p_int << std::endl;

    std::vector<char>* p_vec = new std::vector<char>(1024); // 할당했지만 delete 하지 않음
    std::cout << "Leaked vector at " << p_vec << std::endl;
    // p_vec도 사용 후 버려짐
}

int main() {
    create_leak();
    std::cout << "Program exiting.\n";
    return 0;
}

g++ -g leaky_program.cpp -o leaky_program
valgrind --leak-check=full --show-leak-kinds=all --track-origins=yes ./leaky_program

g++ -fsanitize=address -g leaky_program.cpp -o leaky_program
./leaky_program

# UB 탐지
g++ -fsanitize=undefined -g your_program.cpp -o your_program_ubsan
./your_program_ubsan

# 데이터 레이스 탐지
g++ -fsanitize=thread -g your_program.cpp -o your_program_tsan
./your_program_tsan

누수 의심 경로와 플랫폼에 맞춰 동적 계측·Memcheck·메모리 스냅샷을 선택합니다.

정적 분석으로 사전 차단하기 (clang-tidy)

런타임 탐지 도구와 함께 정적 분석을 병행하면, 실행 전에 잠재 결함을 줄일 수 있습니다.

• clang-tidy는 널리 쓰이는 C++ 정적 분석 도구로, 메모리/성능/코드 스타일 문제를 자동 점검합니다.
• CI에 clang-tidy를 포함하면 코드 리뷰 이전에 결함을 빠르게 차단할 수 있습니다.

clang-tidy src/main.cpp -- -std=c++20

cmake -DCMAKE_CXX_CLANG_TIDY="clang-tidy;-checks=bugprone-*,performance-*,modernize-*" -S . -B build
cmake --build build

실무에서는 정적 분석(clang-tidy) + 동적 계측(ASan/UBSan/TSan) + 회귀 테스트 조합이 가장 안정적입니다.

메모리 누수 탐지 전략

누수된 메모리 블록 이해하기

탐지 도구가 보고하는 메모리 누수는 다양한 상태로 분류될 수 있습니다.

• Definitely lost: 프로그램이 해당 메모리 블록에 대한 포인터를 전혀 가지고 있지 않아, 해당 메모리를 해제할 방법이 완전히 사라진 경우. (가장 심각한 누수)
• Indirectly lost: 해당 블록을 가리키는 블록들 자체가 이미 lost인 경우. 트리의 루트 블록을 잃으면 자식 블록들이 이 상태가 될 수 있어, 최초로 잃은 소유 경로부터 추적합니다.
• Possibly lost: 도달 경로에 블록 시작이 아닌 내부 주소를 가리키는 포인터가 포함되어, 실제 소유 경로인지 우연한 값인지 추가 확인이 필요한 경우.
• Still reachable: 루트에서 시작 포인터를 따라 블록에 도달할 수 있는 경우. 도구가 앞으로 사용할지 여부까지 판단하는 것은 아닙니다. (일반적으로는 누수가 아니지만, 의도치 않은 경우도 있음)

Definitely lost는 반드시 해결해야 할 문제입니다. 이 분류는 Memcheck의 누수 분류에 해당하며, 다른 도구의 보고 용어와 일대일로 같다고 가정하지 않습니다.

예시

가상 보고에서 시작 포인터를 잃은 루트 블록 16 B와 그 루트만이 가리키던 자식 32 B는 각각 definitely lost·indirectly lost로 분류될 수 있습니다. 전역 캐시가 시작 포인터를 유지한 64 B는 still reachable일 수 있지만, 업무상 계속 필요한 캐시인지까지 도구가 판단하지는 않습니다. 실제 블록 크기나 원 예제의 vector 할당 크기를 이 숫자로 바꾸어 읽지 않습니다.

독립 확인: 한 블록의 시작 주소 대신 내부 원소 주소만 남았다는 possibly lost 보고를 보면 무엇을 확인해야 하나요? 반복 요청 뒤 still reachable 64 B가 그대로인 경우와 64·128·192 B로 늘어나는 경우 중 어느 쪽이 추가 수명 조사의 우선 후보인가요?

Possibly lost와 Still reachable은 코드의 맥락에 따라 중요도가 달라지지만, 대부분의 경우 조사하고 해결해야 합니다.

메모리 문제는 누수뿐 아니라 해제 후 사용, 버퍼 침범, 데이터 레이스처럼 여러 형태로 나타납니다.

아래 다이어그램은 예방, 정적 분석, 동적 계측, 장시간 검증을 어떤 순서로 조합할지 보여줍니다.

누수 보고서는 블록 상태를 구분해 해제 방법을 잃은 메모리부터 우선순위를 매겨 처리해야 합니다.