OOM(Out Of Memory) 발생 경험과 해결 방법

1. 발생 경험 소개

> “네, OOM을 직접 겪은 경험이 있습니다. 예를 들어, Spring 기반 서버에서 특정 배치 작업이나 대량 트래픽 유입 시 java.lang.OutOfMemoryError: Java heap space가 발생한 적이 있습니다.”



2. 문제 파악 방법

로그 분석: OOM 발생 시점의 catalina.out / 애플리케이션 로그 확인.

Heap dump 분석: -XX:+HeapDumpOnOutOfMemoryError 옵션으로 덤프를 남겨 Eclipse MAT이나 VisualVM 같은 툴로 메모리 누수 객체 추적.

모니터링 지표: JVM GC 로그, Prometheus/Grafana 대시보드, NewRelic/APM 등으로 heap 사용량 추적.

패턴 확인: 특정 API 호출 시, 혹은 특정 스케줄러 실행 시마다 메모리가 비정상적으로 증가하는 패턴 확인.


3. 원인 & 해결

메모리 누수: 캐시에 넣고 제거하지 않는 객체, DB 커넥션 close 누락 → 코드 수정.

대량 데이터 처리 방식 문제: 수십만 건을 한 번에 메모리에 로드 → 스트리밍 처리(ResultSet fetchSize, cursor, Stream API)로 변경.

잘못된 라이브러리 사용: JSON 직렬화 시 무한 참조 구조 → Jackson @JsonIgnore / DTO 분리.

JVM 설정 부족: 단순히 heap size가 너무 작음 → -Xmx 조정.


4. 예방책

사전 부하 테스트(JMeter, Gatling)로 병목 검증.

JVM 모니터링/알람 시스템 구축.

캐시 사용 시 eviction 정책 적용.

주기적으로 heap dump 분석 & 코드 리뷰.



---

완성 답변 예시 (면접용 1분 버전)

> “네, 대용량 데이터 처리 과정에서 OutOfMemoryError를 경험한 적이 있습니다.
당시에는 한 번에 수십만 건 데이터를 메모리에 적재하는 방식이라 heap이 부족했습니다. 문제를 파악하기 위해 GC 로그와 heap dump를 분석했고, 데이터가 스트리밍되지 않고 전부 적재되는 걸 확인했습니다. 해결책으로는 JDBC fetchSize를 적용하고 스트리밍 기반 처리로 변경했습니다.
이후에는 JMeter 부하 테스트를 통해 재발을 막았고, JVM 모니터링과 캐시 정책도 개선했습니다.
이런 경험을 통해, OOM은 단순히 heap을 늘리는 게 아니라 근본적인 데이터 처리 방식과 코드 구조를 점검해야 한다는 걸 배웠습니다.”