이 질문 뒤에 면접관이 확인하려는 것은 따로 있습니다.
인턴 때 Spring 기반 배치 서비스가 며칠 운영 후 메모리가 꽉 차서 재시작해야 하는 문제가 있었습니다. 원인을 모르는 상태로 재시작만 반복했는데, 제가 원인 파악을 해보겠다고 했습니다.
GC 로그를 활성화하고 VisualVM으로 힙 사용량 추이를 확인하니, 특정 객체가 GC 이후에도 계속 쌓이는 게 보였습니다. 힙 덤프를 분석하니 캐시 Map에 키를 넣기만 하고 제거하는 로직이 없었던 것이 원인이었습니다.
WeakHashMap으로 교체해 GC가 참조되지 않는 키를 자동으로 제거하도록 하니 메모리가 안정됐습니다. 메모리 문제를 추측으로 고치는 것과 프로파일러로 확인하고 고치는 것은 완전히 다른 일이라는 걸 그때 배웠습니다. 이후엔 성능 문제는 항상 측정 먼저 하는 습관이 생겼습니다.
사이드 프로젝트에서 여러 외부 API를 순차적으로 호출하는 로직이 느리다는 피드백을 받았습니다. Kotlin 코루틴으로 병렬 호출로 바꾸면 빨라질 거라 생각했는데, 먼저 측정부터 하자고 결정했습니다.
JMH 벤치마크 라이브러리로 현재 순차 호출 시간을 측정했더니 평균 1,200ms였습니다. 코루틴 async/await 병렬 구조로 바꾼 뒤 같은 조건에서 측정하니 280ms였습니다. API 4개가 모두 독립적으로 호출 가능한 구조였기 때문에 효과가 컸습니다.
실패했던 부분은 처음 코루틴 스코프를 잘못 설정해 외부에서 취소 신호를 보내도 하위 코루틴이 멈추지 않는 문제가 있었습니다. 구조화된 동시성을 이해하고 나서 수정했습니다. 측정 없이 최적화를 시작하지 않는 것과 동시성 모델을 제대로 이해하고 쓰는 것, 두 가지를 그때 배웠습니다.
팀 프로젝트에서 게시글 목록 API가 데이터가 늘수록 느려진다는 것을 체감했습니다. 코드를 봐도 이유를 몰라 Hibernate 통계를 활성화하고 요청마다 실행되는 쿼리 수를 로그로 찍어봤습니다.
목록 20개를 가져올 때 쿼리가 21개 실행되는 게 보였습니다. 게시글마다 작성자 정보를 별도 조회하는 전형적인 N+1 문제였습니다. @EntityGraph로 작성자를 함께 가져오도록 수정하니 쿼리가 1개로 줄었고 응답 시간이 620ms에서 80ms로 줄었습니다.
코드를 읽어선 N+1이 보이지 않는 경우가 많다는 걸 그때 알았습니다. 이후엔 관계가 있는 엔티티를 다루는 API를 만들 때 쿼리 로그를 기본으로 켜 놓고 확인하는 습관이 생겼습니다.
답변에서 흔히 빠지는 것들 — 빠져 있으면 꼬리질문이 깊어집니다.
이 질문에 이어 넥스트증권 백엔드 면접관이 던질 가능성이 높은 후속 질문.
이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 특정 회사가 실제로 이 질문을 출제했다는 것을 보장하지 않으며, 모든 예시는 우문현답이 직접 작성한 창작물입니다. 해당 회사의 공식 입장과는 무관합니다. 회사 측의 정정 요청이 있을 경우 24시간 이내에 응답·수정합니다.