RSS는 안 오르는데 OOM이 난다면 메모리 누수가 아닐 수 있나요?

단편화·임시 스파이크·외부 라이브러리 캐시 등 다른 원인이 있습니다. 힙 프로파일러와 시스템 메트릭을 함께 봐야 합니다.

Valgrind와 ASan 중 무엇을 먼저 쓰나요?

개발 빌드에서 ASan이 빠르게 많은 클래스의 오류를 잡습니다. Valgrind는 환경에 따라 느리지만 일부 힙 패턴에서 유용합니다. 팀 CI 정책에 맞춰 선택합니다.

Heaptrack은 어떤 질문에 답해 주나요?

어떤 호출 경로가 얼마나 할당했는지 보여 줘 누수라기보다 과다 할당·캐시 폭증을 찾을 때 좋습니다.

수정 후에도 메모리가 서서히 든다면?

컨테이너 reserve·풀 재사용·캐시 상한 같은 설계 검토가 필요합니다. 한 번의 누수 수정으로 끝나지 않는 경우가 많습니다.

C++ 메모리 누수 디버깅 실전 사례 | 프로덕션 서버 메모리 사용량 급증 해결기

2026년 3월 30일 · 22분 읽기 · 수정 2026년 4월 7일 고급

이 글의 핵심

프로덕션 C++ 서버에서 발생한 메모리 누수를 Valgrind, ASan, Heaptrack으로 추적하고 해결한 실전 사례. 증상 분석부터 근본 원인 파악, 수정, 재발 방지까지 전 과정을 다룹니다.

들어가며

프로덕션 환경에서 메모리 누수는 서버를 서서히 죽이는 무서운 버그입니다. 이 글에서는 실제로 겪었던 메모리 누수 사례를 통해 증상 발견부터 근본 원인 파악, 수정, 재발 방지까지 전 과정을 다룹니다. 일상에 빗대면, 물은 잘 나오는데 월세는 안 나가는 하수구와 비슷합니다. 겉보기 연결 수는 정상인데, 어딘가에 물이 고여만 가는 패턴입니다.

이 글을 읽으면

메모리 누수 증상을 조기에 발견하는 방법을 배웁니다
Valgrind, ASan, Heaptrack 등 도구를 실전에서 활용하는 법을 익힙니다
복잡한 코드베이스에서 누수 원인을 추적하는 전략을 이해합니다
메모리 누수를 예방하는 코딩 패턴을 습득합니다

실전 경험에서 배운 교훈

이 기술을 실무 프로젝트에 처음 도입했을 때, 공식 문서만으로는 알 수 없었던 많은 함정들이 있었습니다. 특히 프로덕션 환경에서 발생하는 엣지 케이스들은 로컬 개발 환경에서는 재현조차 되지 않았죠.

가장 어려웠던 점은 성능 최적화였습니다. 처음엔 “동작만 하면 되겠지”라고 생각했지만, 실제 사용자 트래픽이 몰리면서 병목 지점들이 하나씩 드러났습니다. 특히 데이터베이스 쿼리 최적화, 캐싱 전략, 에러 핸들링 구조 등은 여러 번의 장애를 겪으면서 개선해 나갔습니다.

이 글에서는 그런 시행착오를 통해 얻은 실전 노하우와, “이렇게 하면 안 된다”는 교훈들을 함께 정리했습니다. 특히 트러블슈팅 섹션은 실제 장애 대응 경험을 바탕으로 작성했으니, 비슷한 문제를 마주했을 때 참고하시면 도움이 될 것입니다.

1. 증상: 서버 메모리 사용량이 계속 증가

문제 상황

구체적으로는 배포 후 3일째부터 채팅 서버의 메모리 사용량이 시간에 비례해 계속 불어났습니다. 연결 수·처리량은 안정적인데 RSS만 커지는 누적 누수 패턴이었습니다.

# 배포 직후
$ ps aux | grep chat_server
user  12345  0.5  2.1  524288  .... ./chat_server
# 3일 후
$ ps aux | grep chat_server
user  12345  0.5  8.7  2162688  .... ./chat_server
# 7일 후 (OOM Killer에 의해 종료됨)
[  123.456] Out of memory: Killed process 12345 (chat_server)

초기 가설

연결 객체가 제대로 해제되지 않는가?
로그 버퍼가 계속 쌓이는가?
캐시가 무한정 커지는가?

일상 비유로 이해하기: 메모리를 아파트 건물로 생각해보세요. 스택은 엘리베이터 같아서 빠르지만 공간이 제한적입니다. 힙은 창고처럼 넓지만 물건을 찾는 데 시간이 걸립니다. 포인터는 “3층 302호”처럼 주소를 가리키는 메모지라고 보면 됩니다.

2. 초기 분석: 모니터링 데이터 확인

Prometheus 메트릭 확인

// 서버에 메트릭 수집 코드 추가
class MemoryMetrics {
public:
    static size_t getCurrentRSS() {
        std::ifstream stat("/proc/self/status");
        std::string line;
        while (std::getline(stat, line)) {
            if (line.find("VmRSS:") == 0) {
                std::istringstream iss(line);
                std::string key, value, unit;
                iss >> key >> value >> unit;
                return std::stoull(value) * 1024; // KB to bytes
            }
        }
        return 0;
    }
};
// 주기적으로 메트릭 전송
void reportMetrics() {
    auto rss = MemoryMetrics::getCurrentRSS();
    prometheus_gauge_set(memory_rss_bytes, rss);
}

패턴 분석

Grafana 대시보드를 보니:

메모리 증가율: 시간당 약 50MB
연결 수: 안정적 (100~200개)
요청 처리량: 변화 없음 결론: 연결당 메모리가 아니라, 시간이 지날수록 누적되는 무언가가 있다.

3. 도구 선택: Valgrind vs ASan vs Heaptrack

도구 비교

도구	장점	단점	적합한 상황
Valgrind	정확한 누수 탐지	매우 느림 (10-50배)	개발 환경, 작은 재현 케이스
ASan	빠름 (2배), 다양한 버그 탐지	재컴파일 필요	CI, 통합 테스트
Heaptrack	할당 패턴 시각화	누수만 찾기는 어려움	메모리 프로파일링

전략

ASan으로 빠르게 재현 시도
재현 안 되면 Valgrind로 정밀 분석
Heaptrack으로 할당 핫스팟 확인

4. Valgrind로 첫 추적 시도

빌드 및 실행

# 디버그 심볼 포함 빌드
$ g++ -g -O0 -std=c++17 *.cpp -o chat_server
# Valgrind 실행
$ valgrind --leak-check=full --show-leak-kinds=all \
           --track-origins=yes --log-file=valgrind.log \
           ./chat_server

문제점

서버가 너무 느려서 실제 부하를 재현할 수 없었습니다. 10분 실행해도 메모리 증가가 미미했습니다.

==12345== HEAP SUMMARY:
==12345==     in use at exit: 1,234,567 bytes in 1,234 blocks
==12345==   total heap usage: 12,345 allocs, 11,111 frees, 123,456,789 bytes allocated

결론: Valgrind는 프로덕션 부하를 재현하기엔 너무 느립니다.

5. ASan으로 빠른 재현

ASan 빌드

# ASan 플래그로 재컴파일
$ g++ -g -O1 -fsanitize=address -fno-omit-frame-pointer \
      -std=c++17 *.cpp -o chat_server_asan
# 환경 변수 설정
$ export ASAN_OPTIONS=detect_leaks=1:log_path=asan.log

부하 테스트

# 실제 트래픽 시뮬레이션
$ ./load_test.sh --connections=200 --duration=600s

결과

10분 만에 누수가 재현되었고, ASan이 리포트를 생성했습니다:

=================================================================
==23456==ERROR: LeakSanitizer: detected memory leaks
Direct leak of 48000 byte(s) in 1000 object(s) allocated from:
    #0 0x7f123456 in operator new(unsigned long)
    #1 0x7f234567 in EventManager::subscribe(std::string const&, EventCallback)
    #2 0x7f345678 in ChatRoom::addUser(User*)
    #3 0x7f456789 in Server::handleJoin(Connection*)
    ...
SUMMARY: AddressSanitizer: 48000 byte(s) leaked in 1000 allocations.

발견: `EventManager::subscribe` 에서 누수 발생!

6. Heaptrack으로 할당 패턴 분석

Heaptrack 실행

# Heaptrack으로 프로파일링
$ heaptrack ./chat_server
# GUI로 분석
$ heaptrack_gui heaptrack.chat_server.12345.gz

발견 사항

Heaptrack GUI의 “Flame Graph”를 보니:

EventManager::subscribe 가 전체 할당의 35%를 차지
할당은 계속 증가하는데 해제는 거의 없음
콜스택: ChatRoom::addUser → subscribe

7. 근본 원인: 이벤트 리스너 누적

문제 코드

class EventManager {
    std::unordered_map<std::string, std::vector<EventCallback*>> listeners_;
public:
    void subscribe(const std::string& event, EventCallback callback) {
        // 🚨 문제: new로 할당하지만 해제 코드가 없음
        auto* cb = new EventCallback(std::move(callback));
        listeners_[event].push_back(cb);
    }
    
    void publish(const std::string& event, const EventData& data) {
        if (auto it = listeners_.find(event); it != listeners_.end()) {
            for (auto* cb : it->second) {
                (*cb)(data);
            }
        }
    }
    
    // 🚨 소멸자에서 해제하지 않음!
    ~EventManager() = default;
};
class ChatRoom {
    EventManager& eventMgr_;
    
public:
    void addUser(User* user) {
        // 사용자가 입장할 때마다 리스너 등록
        eventMgr_.subscribe("message", [user](const EventData& data) {
            user->sendMessage(data);
        });
        
        // 🚨 사용자가 퇴장해도 리스너는 남아있음!
    }
};

왜 누수가 발생했나?

addUser 호출 시마다 new EventCallback 할당
사용자가 퇴장해도 listeners_ 벡터에 포인터가 남아있음
EventManager 소멸자에서 해제하지 않음
1000명 입장 → 1000개 할당 → 0개 해제 = 48KB 누수

8. 수정: RAII와 스마트 포인터 적용

해결 방법 1: 스마트 포인터 사용

class EventManager {
    using CallbackPtr = std::shared_ptr<EventCallback>;
    std::unordered_map<std::string, std::vector<CallbackPtr>> listeners_;
public:
    // 구독 ID 반환 (나중에 해제 가능)
    size_t subscribe(const std::string& event, EventCallback callback) {
        auto cb = std::make_shared<EventCallback>(std::move(callback));
        listeners_[event].push_back(cb);
        return reinterpret_cast<size_t>(cb.get()); // ID로 사용
    }
    
    void unsubscribe(const std::string& event, size_t id) {
        auto& cbs = listeners_[event];
        cbs.erase(
            std::remove_if(cbs.begin(), cbs.end(),
                [id](const CallbackPtr& cb) {
                    return reinterpret_cast<size_t>(cb.get()) == id;
                }),
            cbs.end()
        );
    }
    
    // 소멸자에서 자동 해제 (shared_ptr 덕분에)
    ~EventManager() = default;
};

해결 방법 2: RAII 래퍼

class Subscription {
    EventManager* mgr_;
    std::string event_;
    size_t id_;
public:
    Subscription(EventManager* mgr, std::string event, size_t id)
        : mgr_(mgr), event_(std::move(event)), id_(id) {}
    
    ~Subscription() {
        if (mgr_) {
            mgr_->unsubscribe(event_, id_);
        }
    }
    
    // 이동만 허용
    Subscription(Subscription&& other) noexcept
        : mgr_(other.mgr_), event_(std::move(other.event_)), id_(other.id_) {
        other.mgr_ = nullptr;
    }
    
    Subscription(const Subscription&) = delete;
    Subscription& operator=(const Subscription&) = delete;
};
class ChatRoom {
    EventManager& eventMgr_;
    std::vector<Subscription> subscriptions_; // RAII로 관리
public:
    void addUser(User* user) {
        auto id = eventMgr_.subscribe("message", [user](const EventData& data) {
            user->sendMessage(data);
        });
        
        // Subscription 객체가 소멸 시 자동 해제
        subscriptions_.emplace_back(&eventMgr_, "message", id);
    }
    
    void removeUser(User* user) {
        // subscriptions_ 벡터에서 해당 항목 제거하면
        // Subscription 소멸자가 자동으로 unsubscribe 호출
        // (실제로는 user와 subscription을 매핑해야 함)
    }
};

9. 검증: 메모리 프로파일 비교

수정 전

$ heaptrack ./chat_server_before
# 10분 실행 후
Peak heap memory: 2.1 GB
Total allocations: 1,234,567
Total deallocations: 234,567
Leaked: 1,000,000 allocations

수정 후

$ heaptrack ./chat_server_after
# 10분 실행 후
Peak heap memory: 156 MB
Total allocations: 1,234,567
Total deallocations: 1,234,565
Leaked: 2 allocations (정적 객체)

ASan 최종 확인

$ ./chat_server_asan
# 10분 부하 테스트 후 종료
# ASan 출력:
=================================================================
==45678==ERROR: LeakSanitizer: 0 byte(s) leaked in 0 allocation(s).

성공! 메모리 누수가 완전히 해결되었습니다.

10. 재발 방지: CI에 ASan 추가

GitHub Actions 설정

# .github/workflows/sanitizers.yml
name: Memory Sanitizers
on: [push, pull_request]
jobs:
  asan:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3
      
      - name: Build with ASan
        run: |
          cmake -DCMAKE_BUILD_TYPE=Debug \
                -DCMAKE_CXX_FLAGS="-fsanitize=address -fno-omit-frame-pointer" \
                -B build
          cmake --build build
      
      - name: Run tests with ASan
        run: |
          export ASAN_OPTIONS=detect_leaks=1:halt_on_error=1
          cd build && ctest --output-on-failure

코드 리뷰 체크리스트

팀 코드 리뷰 가이드에 추가:

new를 사용했다면 대응하는 delete가 있는가?
스마트 포인터를 사용할 수 있는가?
리소스 획득 시 RAII 패턴을 적용했는가?
콜백/리스너 등록 시 해제 메커니즘이 있는가?

11. 교훈과 베스트 프랙티스

핵심 교훈

조기 발견: 메모리 모니터링을 배포 초기부터 설정
도구 조합: Valgrind, ASan, Heaptrack을 상황에 맞게 활용
RAII 원칙: 리소스 획득은 초기화, 해제는 소멸자
자동화: CI에 sanitizer를 추가하여 회귀 방지

메모리 누수 예방 패턴

// ❌ 나쁜 패턴: 수동 메모리 관리
class BadCache {
    std::map<std::string, Data*> cache_;
public:
    void add(const std::string& key, Data* data) {
        cache_[key] = data; // 누가 해제하나?
    }
};
// ✅ 좋은 패턴: 스마트 포인터
class GoodCache {
    std::map<std::string, std::unique_ptr<Data>> cache_;
public:
    void add(const std::string& key, std::unique_ptr<Data> data) {
        cache_[key] = std::move(data); // 자동 해제
    }
};
// ✅ 더 좋은 패턴: 값 의미론
class BestCache {
    std::map<std::string, Data> cache_;
public:
    void add(const std::string& key, Data data) {
        cache_[key] = std::move(data); // 포인터 불필요
    }
};

마무리

이 사례를 통해 배운 점:

메모리 누수는 증상이 서서히 나타나므로 모니터링이 필수입니다
도구를 상황에 맞게 선택하면 디버깅 시간을 크게 단축할 수 있습니다
RAII와 스마트 포인터는 메모리 안전성의 기본입니다
CI에 sanitizer를 추가하면 회귀를 조기에 발견할 수 있습니다 프로덕션 환경에서 메모리 문제를 겪고 계신다면, 이 글의 접근 방식을 참고하여 체계적으로 해결해보세요.

FAQ

Q1. 프로덕션에서 ASan을 켜도 되나요? 성능 오버헤드(2배)가 있으므로, 일부 트래픽만 ASan 빌드로 라우팅하는 것을 권장합니다. 또는 스테이징 환경에서 프로덕션 트래픽을 리플레이하세요. Q2. Valgrind가 “still reachable”이라고 하는데 누수인가요? “still reachable”은 프로그램 종료 시 여전히 포인터가 있는 메모리입니다. 정적 객체나 싱글톤이면 정상이지만, 증가한다면 누수입니다. Q3. 스마트 포인터를 쓰면 순환 참조로 누수가 생기지 않나요? `shared_ptr` 순환 참조는 `weak_ptr`로 해결합니다. 가능하면 `unique_ptr`로 소유권을 명확히 하세요.

실전 체크리스트

메모리 누수 디버깅 체크리스트

메모리 안전 코딩 체크리스트

new 사용 시 대응하는 delete 확인
가능하면 스마트 포인터 사용
리소스 획득 시 RAII 패턴 적용
콜백/리스너 등록 시 해제 메커니즘 구현
순환 참조 가능성 검토 (weak_ptr 고려)
예외 안전성 확인 (예외 발생 시에도 해제되는가)

키워드

C++, 메모리 누수, Memory Leak, 디버깅, Valgrind, ASan, AddressSanitizer, Heaptrack, 프로덕션, 실전 사례, RAII, 스마트 포인터, 이벤트 리스너, 프로파일링, CI/CD

심화 부록: 구현·운영 관점

이 부록은 앞선 본문에서 다룬 주제(「C++ 메모리 누수 디버깅 실전 사례 | 프로덕션 서버 메모리 사용량 급증 해결기」)를 구현·런타임·운영 관점에서 다시 압축합니다. 도메인별 세부 구현은 글마다 다르지만, 입력 검증 → 핵심 연산 → 부작용(I/O·네트워크·동시성) → 관측의 흐름으로 장애를 나누면 원인 추적이 빨라집니다.

내부 동작과 핵심 메커니즘

flowchart TD
  A[입력·요청·이벤트] --> B[파싱·검증·디코딩]
  B --> C[핵심 연산·상태 전이]
  C --> D[부작용: I/O·네트워크·동시성]
  D --> E[결과·관측·저장]

sequenceDiagram
  participant C as 클라이언트/호출자
  participant B as 경계(런타임·게이트웨이·프로세스)
  participant D as 의존성(API·DB·큐·파일)
  C->>B: 요청/이벤트
  B->>D: 조회·쓰기·RPC
  D-->>B: 지연·부분 실패·재시도 가능
  B-->>C: 응답 또는 오류(코드·상관 ID)

불변 조건(Invariant): 버퍼 경계, 프로토콜 상태, 트랜잭션 격리, FD 상한 등 단계별로 문장으로 적어 두면 디버깅 비용이 줄어듭니다.
결정성: 순수 층과 시간·네트워크·스케줄에 의존하는 층을 분리해야 테스트와 장애 분석이 쉬워집니다.
경계 비용: 직렬화, 인코딩, syscall 횟수, 락 경합, 할당·GC, 캐시 미스를 의심 목록에 둡니다.
백프레셔: 생산자가 소비자보다 빠를 때 버퍼·큐·스트림에서 속도를 줄이는 신호를 어디에 둘지 정의합니다.

프로덕션 운영 패턴

영역	운영 관점 질문
관측성	요청 단위 상관 ID, 에러율·지연 p95/p99, 의존성 타임아웃·재시도가 대시보드에 보이는가
안전성	입력 검증·권한·비밀·감사 로그가 코드 경로마다 일관적인가
신뢰성	재시도는 멱등 연산에만 적용되는가, 서킷 브레이커·백오프·DLQ가 있는가
성능	캐시·배치 크기·커넥션 풀·인덱스·백프레셔가 데이터 규모에 맞는가
배포	롤백 룬북, 카나리/블루그린, 마이그레이션·피처 플래그가 문서화되어 있는가
용량	피크 트래픽·디스크·FD·스레드 풀 상한을 주기적으로 검증하는가

스테이징은 데이터 양·네트워크 RTT·동시성을 프로덕션에 가깝게 맞출수록 재현율이 올라갑니다.

확장 예시: 엔드투엔드 미니 시나리오

앞선 본문 주제(「C++ 메모리 누수 디버깅 실전 사례 | 프로덕션 서버 메모리 사용량 급증 해결기」)를 배포·운영 흐름에 맞춰 옮긴 체크리스트입니다. 도메인에 맞게 단계 이름만 바꿔 적용할 수 있습니다.

입력 계약 고정: 스키마·버전·최대 페이로드·타임아웃·에러 코드를 경계에 둔다.
핵심 경로 계측: 요청 ID, 단계별 지연, 외부 호출 결과 코드를 로그·메트릭·트레이스에서 한 흐름으로 본다.
실패 주입: 의존성 타임아웃·5xx·부분 데이터·락 대기를 스테이징에서 재현한다.
호환·롤백: 설정/마이그레이션/클라이언트 버전을 되돌릴 수 있는지 확인한다.
부하 후 검증: 피크 대비 p95/p99, 에러율, 리소스 상한, 알림 임계값을 점검한다.

handle(request):
  ctx = newCorrelationId()
  validated = validateSchema(request)
  authorize(validated, ctx)
  result = domainCore(validated)
  persistOrEmit(result, idempotentKey)
  recordMetrics(ctx, latency, outcome)
  return result

문제 해결(Troubleshooting)

증상	가능 원인	조치
간헐적 실패	레이스, 타임아웃, 외부 의존성, DNS	최소 재현 스크립트, 분산 트레이스·로그 상관관계, 재시도·서킷 설정 점검
성능 저하	N+1, 동기 I/O, 락 경합, 과도한 직렬화, 캐시 미스	프로파일러·APM으로 핫스팟 확인 후 한 가지씩 제거
메모리 증가	캐시 무제한, 구독/리스너 누수, 대용량 버퍼, 커넥션 미반납	상한·TTL·힙/FD 스냅샷 비교
빌드·배포만 실패	환경 변수, 권한, 플랫폼 차이, lockfile	CI 로그와 로컬 diff, 런타임·이미지 버전 핀
설정 불일치	프로필·시크릿·기본값, 리전	스키마 검증된 설정 단일 소스와 배포 매트릭스 표준화
데이터 불일치	비멱등 재시도, 부분 쓰기, 캐시 무효화 누락	멱등 키·아웃박스·트랜잭션 경계 재검토

권장 순서: (1) 최소 재현 (2) 최근 변경 범위 축소 (3) 환경·의존성 차이 (4) 관측으로 가설 검증 (5) 수정 후 회귀·부하 테스트.

배포 전에는 git add → git commit → git push 후 npm run deploy 순서를 권장합니다.

같이 보면 좋은 글 (내부 링크)

이 주제와 연결되는 다른 글입니다.

이 글에서 다루는 키워드 (관련 검색어)

C++, 디버깅, 메모리 누수, Valgrind, ASan, Heaptrack, 실전 사례, 프로덕션 등으로 검색하시면 이 글이 도움이 됩니다.

이 글이 도움이 되셨나요?

여러분의 피드백은 더 나은 콘텐츠를 만드는 데 도움이 됩니다

문제가 있거나 개선 제안이 있으시면 연락처로 알려주세요.