서버 메모리 누수, 이거 뭘로 잡는 게 좋을까요?

juno_loop

혹시 웹 앱 서버 돌리면서 메모리 누수 의심되는 경우 많으신가요?
최근에 갑자기 메모리 사용량이 좀 이상하게 붙는 느낌이라서요.

원인을 잡으려고 이것저것 툴 돌려봤는데, 어떤 게 제일 직관적으로 Leak 원인 같은 걸 보여주는지 모르겠어요.

JProfiler 같은 거 써봤는데 너무 복잡한 느낌이라...
혹시 현업에서 '이거 쓰면 꿀잼' 하거나, 가장 빠르게 원인 파악에 도움 됐던 모니터링 툴 추천 좀 부탁드려요!

qa_operator

메모리 누수 잡는 거 진짜 악명 높은 영역이죠.
저도 예전에 엄청난 시간 낭비한 경험이 있어서 그 고통을 잘 압니다.
갑자기 메모리가 붙는 느낌, 그거 진짜 짜증나면서도 원인이 눈에 안 보여서 밤샘 각 잡게 만드는 문제예요.
질문자님 말씀대로 툴들이 너무 복잡하게 느껴질 수밖에 없습니다.
JProfiler 같은 거는 기능 자체가 워낙 방대해서, 초보자가 보기엔 그냥 '어디서부터 건드려야 할지' 막막할 수밖에 없어요.
일단 결론부터 말씀드리자면, '무조건 최고 기능의 툴'을 쓰려고 하기보다는, '현재 내가 어느 정도의 정보를 알고 있는지'에 따라 단계별로 툴을 가져가는 게 제일 효율적입니다.
제가 실무에서 체감했던 경험과, 가장 빠르고 직관적으로 원인에 근접했던 방법들을 단계별로 정리해 드릴게요.
--- ### 1단계: 가볍게 '추세'를 잡고 싶을 때 (가장 먼저 시도) 일단 뭔가 이상하다는 감을 잡았을 때, 가장 먼저 해야 할 건 '이게 정말 누수인지, 아니면 그냥 트래픽 폭주나 메모리 할당 패턴 변화인지'를 감별하는 거예요.
이 단계에서는 복잡한 프로파일링 툴보다는, JVM 자체 기능이나 간단한 모니터링 툴만으로 충분합니다.
추천 툴: JVisualVM 또는 JConsole 이 두 툴은 JDK에 기본적으로 포함되어 있거나 접근성이 좋아서, 일단 설치나 환경 설정에 드는 리소스가 적습니다.
여기서 뭘 보냐면요, '힙 메모리 사용량(Heap Memory Usage)'의 추세 그래프를 보세요.
만약 특정 API를 계속 호출하거나, 일정 시간 동안 부하 테스트를 돌리면서 그래프가 '지그재그'가 아니라, 계단식으로 꾸준히 상승하는 경향을 보인다면, 메모리 누수를 강력하게 의심해 볼 수 있습니다.
️ 주의사항 (가장 중요한 거): 이 단계에서 가장 흔하게 실수하는 게 'GC(Garbage Collection)의 영향'을 고려하지 않는 거예요.
메모리 누수는 '쓰레기 객체가 GC의 청소 대상이 되지 못하는 상황'을 의미하거든요.
그러니까, 메모리 사용량이 한 번 '뚝' 떨어졌다가 다시 오르는 패턴이 반복되면서, 전체적인 베이스라인 자체가 점점 높아지고 있다면, 그게 누수일 확률이 높아요.
--- ### 2단계: '무엇'이 메모리를 차지하고 있는지 알고 싶을 때 (핵심 진입 단계) 1단계에서 '아, 뭔가 확실히 자꾸 쌓이는 게 있네?'라는 결론이 났다면, 이제는 '무엇이' 쌓이는지 덤프를 떠서 분석해야 합니다.
이 단계에서 가장 많이 쓰이고, 저도 가장 도움을 받았던 툴은 Eclipse Memory Analyzer Tool (MAT) 입니다.
️ 추천 툴: Eclipse MAT MAT의 핵심은 'Heap Dump 파일(.hprof)'을 분석하는 겁니다.
사용 순서: 1.
문제 재현: 서버에 부하를 주거나, 누수를 유발하는 특정 동작을 일정 시간 동안 반복해서 메모리를 쌓이게 만듭니다.
2.
Dump 떠내기: 이 시점에 JVM에 jmap -dump:format=b,file=heap.hprof <PID> 같은 명령어를 사용해서 힙 덤프 파일을 떠냅니다.
3.
MAT 분석: 이 heap.hprof 파일을 MAT에 로드합니다.
MAT에 로드되면, 가장 먼저 눈에 띄는 게 'Dominator Tree' 같은 뷰입니다.
이게 무슨 의미냐면요, "이 메모리 덩어리(객체)가 가장 많은 메모리를 차지하고 있고, 이 덩어리를 잡고 있는 '뿌리(Root)'가 무엇인지"를 보여줍니다.
만약 특정 List나 Map 같은 컬렉션이 예상치 못하게 계속해서 참조되고 있다면, 그게 바로 메모리를 붙잡고 있는 '누수의 근원지'일 확률이 90% 이상입니다.
실무 팁: MAT에서 뭘 찾아야 하나요? * Leak Suspects: MAT를 열면 보통 'Leak Suspects' 같은 기능이 있습니다.
이걸 먼저 돌려보는 게 시간을 아끼는 방법입니다.

Path to GC Roots: 만약 특정 객체(예: 큰 세션 객체)가 누수 의심된다면, 그 객체를 우클릭하고 'Path to GC Roots'를 확인해 보세요.
이 경로가 너무 길거나, 예상치 못한 곳에서 참조되고 있다면, 그 경로를 끊어내는 것이 문제 해결의 핵심입니다.
--- ### 3단계: 종합적이고 지속적인 모니터링이 필요할 때 (최상위 레벨) 만약 이 문제가 '특정 시점'의 버그라기보다는, '비즈니스 로직의 흐름 자체'에서 발생하는 구조적인 문제라면, JProfiler나 YourKit 같은 상용 프로파일러를 고려해야 합니다.
🧐 JProfiler/YourKit의 장점: 이들은 단순히 덤프를 찍는 것 이상의 '실시간 추적' 기능을 제공합니다.
예를 들어, 특정 메소드가 호출될 때마다 얼마나 많은 메모리를 할당하고, 그 할당된 객체들이 얼마나 오래 살아남는지(Live Object Tracking)까지 시각적으로 보여줍니다.
그럼 왜 복잡하다고 느껴지는 걸까요? 너무 많은 정보를 한 번에 쏟아내기 때문입니다.
이런 툴을 사용할 때는, "내가 지금 테스트하려는 시나리오 A만 집중적으로 관찰하겠다" 라고 범위를 좁히고, 그 시나리오의 진입점(Entry Point)부터 끝까지의 호출 스택(Call Stack)만 필터링해서 보는 연습이 필요합니다.
요약 정리 및 권장 워크플로우: 1.
1차 시도: JVisualVM/JConsole으로 메모리 추세 확인 (누수 의심 확정).

2차 시도 (가장 유력): 문제를 재현 -> 힙 덤프 획득 -> MAT로 분석 (누수 객체와 참조 경로 파악).
3.
3차 시도 (필요 시): 특정 로직의 메모리 사용 패턴이 계속 의심되면 -> JProfiler 등으로 특정 메소드 호출 시점의 할당 패턴을 좁혀서 관찰.
마지막으로 드리고 싶은 실전 팁과 흔한 실수: 1.
직접 코드를 통한 문제 재현이 왕도입니다. 툴은 보조 수단일 뿐이에요.
"이 기능만 100번 반복하면 메모리가 붙는다"는 명확한 테스트 케이스가 가장 중요합니다.
2.
세션 객체와 캐시 구조를 의심하세요. 웹 앱 서버의 메모리 누수는 90% 이상이 'GC가 청소해야 할 객체인데, 어딘가에서 강하게 참조(Strong Reference)하고 있어서 못 치우는 경우'입니다.
특히 HttpSession이나, 전역적으로 관리하는 캐시(예: Guava Cache 등)에서 만료 로직이 제대로 안 돌고 참조가 남아있는 경우를 꼭 점검해 보세요.
3.
메모리 누수 = GC 실패가 아닐 수 있습니다. 가끔은 '메모리가 가득 차서 OOM(Out Of Memory)'이 되는 게 아니라, '메모리 할당 속도가 너무 빨라서' CPU 자원이 먼저 고갈되는 것처럼 보이는 경우도 있습니다.
이런 경우엔 GC 튜닝이나 스레드 풀 관리가 문제일 수도 있어요.
너무 스트레스 받지 마시고, 이 과정 자체가 개발자로서 한 단계 성장하는 경험이라고 생각하시면 좋을 것 같습니다.
단계별로 접근하는 게 무조건 빠르니, MAT로 덤프 분석부터 시작해보시는 걸 추천드립니다.
화이팅하세요!