안녕하세요, 여러분. 15년 차 백엔드 개발자이자, 수많은 밤을 모니터 불빛 아래서 지새운 여러분의 든든한 선배입니다. 오늘은 개발자라면 누구나 한 번쯤, 아니 수십 번쯤 겪어봤을 악몽 같은 주제를 들고 왔습니다. 바로 자바 스프링 부트 서버를 운영하다 보면 마주치는 저승사자, 'java.lang.OutOfMemoryError', 줄여서 OOM에 대한 이야기입니다. 단순히 에러를 해결하는 것을 넘어, 서버의 안정성을 99.99%까지 끌어올리는 심도 있는 분석법을 공유하려 합니다.
솔직히 고백하자면, 저도 신입 시절 이 에러를 처음 만났을 때 정말 식은땀이 줄줄 흘렀습니다. 금요일 오후 5시, 퇴근 직전에 갑자기 모니터링 알람이 울리면서 서버가 픽픽 쓰러지기 시작했죠. 로그를 보니 힙 메모리가 부족하다는데, 당장 원인은 모르겠고, 일단 서버 재시작(Restart)으로 급한 불만 끄고 도망치듯 퇴근했던 기억이 납니다. 하지만 여러분도 아시죠? 원인을 해결하지 않은 재시작은 시한폭탄의 타이머를 다시 돌려놓는 것일 뿐이라는 사실을요. 그 주 주말 내내 저는 불안감에 시달려야 했습니다.
많은 분들이 OOM을 만나면 단순히 힙 메모리 크기(-Xmx)를 늘리는 것으로 해결하려 합니다. "아, 사용자가 늘어서 그런가 보다" 하고 말이죠. 하지만 15년의 경험상, 메모리를 2GB에서 4GB로, 8GB로 늘려도 결국엔 다시 터집니다. 3일 버티던 서버가 5일 버틸 뿐입니다. 왜냐고요? 밑 빠진 독에 물을 붓고 있기 때문입니다. 메모리 누수(Memory Leak)가 발생하고 있다면, 천하의 슈퍼컴퓨터를 가져와도 결국엔 뻗게 되어 있습니다. 누수는 단순히 자원 낭비가 아니라 서비스의 신뢰도를 갉아먹는 치명적인 버그입니다.
오늘은 바로 그 '새는 구멍'을 찾는 가장 확실하고 과학적인 방법, 힙 덤프(Heap Dump) 분석에 대해 아주 깊이 있게 파헤쳐 보려 합니다. 단순히 툴 사용하는 법을 넘어서, 메모리 구조가 어떻게 생겨먹었길래 이런 일이 생기는지, 그리고 실전에서 제가 겪었던 황당하고도 치명적인 사례들을 통해 여러분의 디버깅 시간을 3일에서 30분으로 단축해 드리겠습니다. 이론적인 이야기보다는 당장 실무에 적용할 수 있는 '전투 기술' 위주로 준비했습니다. 커피 한 잔 진하게 타시고 따라오세요. ☕
1. 적을 알고 나를 알자: OOM과 힙 덤프의 정체
먼저 OOM이 왜 발생하는지 그 본질부터 짚고 넘어가야 합니다. 자바는 가비지 컬렉터(GC)가 알아서 메모리를 청소해 주는 아주 편리한 언어입니다. 개발자가 `malloc`과 `free`를 직접 하지 않아도 되죠. 그런데 왜 메모리가 부족할까요? GC가 파업이라도 한 걸까요? 아닙니다. GC는 누구보다 열심히 일하고 있습니다. 문제는 '도달 가능한 객체(Reachable Object)'가 너무 많아졌기 때문입니다.
쉽게 비유하자면, 여러분이 방 청소를 하는데(GC), "이건 나중에 쓸 거야"라고 손에 꽉 쥐고 있는 쓰레기들이 방안에 가득 찬 상황입니다. 청소부는 여러분이 잡고 있는 물건은 절대 버리지 못합니다. 자바에서도 마찬가지입니다. 개발자가 실수로 어떤 객체를 static 변수나 캐시, 혹은 스레드 로컬(ThreadLocal) 같은 곳에 참조를 걸어두면, GC는 "아, 이건 주인이 쓰고 있는 거구나"라고 판단해서 절대 지우지 않습니다. 이런 객체들이 야금야금 쌓이다가 결국 힙 메모리를 가득 채우게 되는 것이죠. 이것이 바로 메모리 릭의 실체입니다.
이때 우리에게 필요한 것이 바로 '힙 덤프(Heap Dump)'입니다. 힙 덤프는 특정 시점의 자바 메모리 상태를 그대로 사진 찍듯 파일(hprof)로 저장한 것입니다. 이 안에는 어떤 객체가 몇 개나 있는지, 그 객체가 누구랑 연결되어 있는지, 그 객체 안에 어떤 데이터가 들어있는지가 낱낱이 기록되어 있습니다. 마치 범죄 현장의 CCTV 영상과도 같습니다. 범인(메모리 누수 원인)을 잡으려면 이 CCTV를 분석하는 기술이 필수적입니다. 단순히 로그만 봐서는 절대 알 수 없는 '객체 간의 관계'를 보여주기 때문입니다.
💡 힙 덤프 분석의 핵심 지표: Shallow vs Retained Heap
힙 덤프를 열어보면 가장 먼저 마주치는 난관이 바로 'Shallow Heap'과 'Retained Heap'이라는 용어입니다. 이 둘의 차이를 모르면 분석 자체가 불가능합니다. 제가 아주 쉽게 설명해 드릴게요. 이 개념을 이해하는 것이 분석의 50%를 차지합니다.
Shallow Heap(얕은 힙)은 객체 그 자체가 차지하는 메모리 크기입니다. 예를 들어, 가방이라는 객체가 있다면 가방의 천, 지퍼 무게만을 뜻합니다. 보통은 크기가 작습니다. 반면, Retained Heap(유지된 힙)은 그 객체가 사라질 때 함께 사라질 수 있는 모든 객체의 크기 합입니다. 즉, 가방 안에 들어있는 노트북, 책, 지갑의 무게까지 다 합친 것이죠.
우리가 주목해야 할 범인은 Shallow Heap이 큰 녀석이 아닙니다. Retained Heap이 비정상적으로 큰 녀석을 잡아야 합니다. 겉보기엔 작아 보이는 리스트(List) 객체 하나(Shallow Size는 고작 24byte)가, 알고 보니 수백만 개의 거대한 이미지 객체를 참조하고 있어서 1GB를 차지하고 있을 수 있거든요. 이걸 놓치면 헛다리만 짚게 됩니다. 따라서 힙 덤프 분석 툴에서는 반드시 Retained Heap 기준으로 정렬하여 상위 객체를 살펴봐야 합니다.
2. 힙 덤프를 확보하는 전략과 도구 비교
범인을 잡으려면 증거물인 힙 덤프를 확보해야 합니다. 힙 덤프를 생성하는 방법은 여러 가지가 있습니다. 하지만 실전 운영 환경(Production)에서는 아무거나 막 쓰면 안 됩니다. 덤프를 뜨는 순간 JVM은 모든 동작을 멈추는 'Stop-the-World' 상태에 빠지기 때문입니다. 트래픽이 몰리는 시간에 덤프를 떴다가는 서비스 전체가 수십 초에서 수 분간 먹통이 될 수 있습니다.
제가 가장 추천하는 방법은 JVM 옵션을 미리 설정해두는 것입니다. '-XX:+HeapDumpOnOutOfMemoryError' 옵션을 시작 스크립트에 넣어두면, OOM이 발생해서 서버가 죽기 직전에 자동으로 힙 덤프를 남겨줍니다. 이건 정말 필수입니다. 사고가 난 뒤에 "아, 덤프 뜰걸" 하고
댓글
댓글 쓰기