이 질문 뒤에 면접관이 확인하려는 것은 따로 있습니다.
사이드 프로젝트에서 응답 시간이 2초를 넘는 API를 최적화한 경험이 있습니다. 먼저 JVM GC 로그를 분석했더니 풀 GC가 500ms 이상 걸리는 구간이 반복됐습니다. Heap 크기와 G1GC 리전 설정을 조정하고, 장기 생존 객체를 별도 풀로 분리하면서 GC 빈도와 지연을 줄였습니다. 또한 핫 코드 경로에서 불필요한 객체 생성을 줄이는 리팩토링을 병행했습니다. 결과적으로 P99 레이턴시가 1.8초에서 420ms로 줄었습니다. 대규모 트래픽 환경에서는 GC 튜닝보다 오브젝트 생성 자체를 줄이는 게 더 근본적인 접근이라는 걸 배웠습니다. JVM 튜닝은 증상보다 원인을 찾는 과정이 핵심이라는 걸 배웠습니다.
GC 로그와 힙 덤프를 먼저 읽는 습관이 레이턴시 문제 해결의 출발점이라고 생각합니다.
JVM 튜닝에서 또 다른 접근으로 힙 메모리 프로파일링 도구를 활용해 메모리 누수(Memory Leak)와 과도한 객체 생성을 탐지하고 근본 원인을 제거하는 방식을 사용했습니다. GC 튜닝은 GC 자체의 동작을 최적화하지만, 근본적으로 불필요한 객체가 계속 생성되거나 해제되지 않으면 GC 빈도를 아무리 줄여도 레이턴시는 다시 올라옵니다.
`VisualVM`과 `Eclipse MAT`으로 힙 덤프를 분석하면서 참조가 끊기지 않아 GC에서 회수되지 않는 객체 집합을 찾았고, 그 원인이 캐시 구현에서 강한 참조(Strong Reference)를 쓰던 부분이었습니다. 약한 참조(WeakReference) 전환 최적화가 캐시 항목이 메모리 압박 시 자동으로 해제되도록 변경하면서, 불필요한 풀 GC 트리거를 줄이는 방식이고, 이것이 레이턴시 개선의 두 번째 레이어였습니다.
P99 레이턴시가 여전히 600ms에서 내려오지 않아서 힙 덤프를 다시 분석했을 때, 캐시 외에 스레드 로컬 변수에 대용량 데이터가 쌓이는 패턴이 추가로 발견됐고, 이를 정리하면서 목표치인 500ms 이하로 도달했습니다. 메모리 문제는 GC 설정보다 객체 수명 주기를 먼저 추적하는 것이 더 빠른 해결 경로입니다.
JVM 레이턴시 최적화에서 GC 튜닝·메모리 누수 탐지와 다른 세 번째 레이어로 JIT(Just-In-Time) 컴파일러 최적화를 유도하는 방식과 핫 코드 경로의 코드 레벨 개선을 병행하는 접근을 사용했습니다. JIT는 자주 실행되는 코드를 런타임에 기계어로 컴파일하는데, 코드 구조가 JIT 최적화를 방해하면 런타임 성능이 기대보다 낮아집니다.
인라이닝(Inlining)이 제대로 이루어지려면 메서드 크기가 JVM 임계값 이하여야 하고, 과도하게 큰 메서드는 컴파일 대상에서 제외되면서 레이턴시에 영향을 줍니다. JIT 인라이닝 유도 코드 분리가 핫 코드 경로의 대형 메서드를 분리해서 JIT 컴파일 적용 범위를 넓히는 방식이고, 이것이 GC 외 레이턴시 최적화에서 유효했던 접근입니다.
`-XX:+PrintCompilation` 플래그로 JIT 컴파일 로그를 추적했을 때, 핵심 비즈니스 로직 메서드가 컴파일되지 않고 인터프리터 모드로 실행되는 것을 발견했고, 메서드를 분리하면서 해당 경로의 레이턴시가 30% 이상 줄었습니다. GC 로그와 JIT 컴파일 로그를 함께 보는 것이 JVM 레이턴시 최적화의 완성입니다.
답변에서 흔히 빠지는 것들 — 빠져 있으면 꼬리질문이 깊어집니다.
이 질문에 이어 쿠팡 ML 인프라 면접관이 던질 가능성이 높은 후속 질문.
이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 특정 회사가 실제로 이 질문을 출제했다는 것을 보장하지 않으며, 모든 예시는 우문현답이 직접 작성한 창작물입니다. 해당 회사의 공식 입장과는 무관합니다. 회사 측의 정정 요청이 있을 경우 24시간 이내에 응답·수정합니다.