C++ 메모리 누수 디버깅 실전 사례 | 프로덕션 서버 메모리 사용량 급증 해결기
이 글의 핵심
C++ 프로덕션 서버 메모리 누수 디버깅 실전 사례 - Valgrind, ASan, Heaptrack 활용
들어가며
프로덕션 환경에서 메모리 누수는 서버를 서서히 죽이는 무서운 버그입니다. 이 글에서는 실제로 겪었던 메모리 누수 사례를 통해 증상 발견부터 근본 원인 파악, 수정, 재발 방지까지 전 과정을 다룹니다.
일상에 빗대면, 물은 잘 나오는데 월세는 안 나가는 하수구와 비슷합니다. 겉보기 연결 수는 정상인데, 어딘가에 물이 고여만 가는 패턴입니다.
이 글을 읽으면
- 메모리 누수 증상을 조기에 발견하는 방법을 배웁니다
- Valgrind, ASan, Heaptrack 등 도구를 실전에서 활용하는 법을 익힙니다
- 복잡한 코드베이스에서 누수 원인을 추적하는 전략을 이해합니다
- 메모리 누수를 예방하는 코딩 패턴을 습득합니다
목차
- 증상: 서버 메모리 사용량이 계속 증가
- 초기 분석: 모니터링 데이터 확인
- 도구 선택: Valgrind vs ASan vs Heaptrack
- Valgrind로 첫 추적 시도
- ASan으로 빠른 재현
- Heaptrack으로 할당 패턴 분석
- 근본 원인: 이벤트 리스너 누적
- 수정: RAII와 스마트 포인터 적용
- 검증: 메모리 프로파일 비교
- 재발 방지: CI에 ASan 추가
- 마무리
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)초기 가설
- 연결 객체가 제대로 해제되지 않는가?
- 로그 버퍼가 계속 쌓이는가?
- 캐시가 무한정 커지는가?
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로 소유권을 명확히 하세요.
관련 글
- C++ 스마트 포인터 완벽 가이드
- C++ RAII 패턴
- C++ Valgrind 사용법
- C++ ASan 디버깅
실전 체크리스트
메모리 누수 디버깅 체크리스트
- 메모리 사용량 모니터링 설정 (Prometheus, Grafana)
- 증가 패턴 분석 (선형, 계단, 주기적)
- 도구 선택 (Valgrind, ASan, Heaptrack)
- 재현 환경 구축 (부하 테스트)
- 콜스택 분석 (할당 위치 추적)
- 근본 원인 파악 (왜 해제되지 않는가)
- 수정 (RAII, 스마트 포인터)
- 검증 (메모리 프로파일 비교)
- CI에 sanitizer 추가
- 코드 리뷰 가이드 업데이트
메모리 안전 코딩 체크리스트
-
new사용 시 대응하는delete확인 - 가능하면 스마트 포인터 사용
- 리소스 획득 시 RAII 패턴 적용
- 콜백/리스너 등록 시 해제 메커니즘 구현
- 순환 참조 가능성 검토 (
weak_ptr고려) - 예외 안전성 확인 (예외 발생 시에도 해제되는가)
키워드
C++, 메모리 누수, Memory Leak, 디버깅, Valgrind, ASan, AddressSanitizer, Heaptrack, 프로덕션, 실전 사례, RAII, 스마트 포인터, 이벤트 리스너, 프로파일링, CI/CD