이 질문 뒤에 면접관이 확인하려는 것은 따로 있습니다.
인턴 때 Spring 기반 API 서버가 며칠에 한 번씩 응답 지연이 발생하는 이슈가 있었습니다. 장애 때마다 원인을 몰라 재시작했는데, 저는 먼저 JVM 지표를 수집하는 것부터 해보자고 했습니다.
Prometheus와 Grafana로 힙 사용량, GC 빈도, GC 소요 시간을 시각화했습니다. 데이터를 보니 Full GC가 지연 직전에 급증하는 패턴이 명확했습니다. 이전에 비해 객체 생성량이 늘어난 시점을 코드 배포 이력과 대조해 보니 특정 배포 이후부터 패턴이 시작됐습니다.
해당 배포의 변경사항을 분석해 List에 대량 데이터를 반복 변환하던 로직이 불필요한 객체를 너무 많이 만들고 있었습니다. 스트림으로 교체하니 GC 빈도가 정상으로 돌아왔습니다. 모니터링이 없었다면 재시작만 반복하다가 근본 원인을 몰랐을 것이라는 걸 배웠습니다.
팀 프로젝트에서 두 서비스 간 API 호출이 예상보다 100ms 이상 느린 현상이 있었습니다. 서비스 로직은 빠른데 이상하게 응답 시간이 높게 나왔습니다.
tcpdump로 패킷을 캡처해 보니 연결 맺는 과정이 매 요청마다 반복되고 있었습니다. HTTP 연결 재사용 설정이 꺼져 있어서, 매번 TCP 핸드셰이크를 새로 하고 있었습니다. 클라이언트 커넥션 풀 설정을 활성화하니 레이턴시가 110ms에서 12ms로 줄었습니다.
처음엔 코드 로직 문제라 생각하고 한참 코드만 봤는데 사실은 설정 문제였습니다. 성능 이슈가 생기면 코드 → 설정 → 인프라 순서로 계층을 넓혀가며 확인하는 접근을 그때부터 쓰게 됐습니다.
사이드 프로젝트에서 트래픽이 몰릴 때 일부 요청이 매우 느리거나 타임아웃이 나는 문제가 있었습니다. 서버 CPU와 메모리는 여유가 있어서 처음엔 원인을 몰랐습니다.
Spring Actuator의 스레드 덤프를 확인하니 대부분의 스레드가 외부 API 응답을 기다리며 WAITING 상태였습니다. 기본 스레드 풀 크기가 200인데, 외부 API가 느릴 때 스레드를 물고 있다가 신규 요청이 스레드를 받지 못하고 대기하는 상황이었습니다.
스레드 풀 크기를 50으로 줄이고 외부 API 타임아웃을 800ms로 명시했습니다. 스레드가 빨리 반환되니 전체 처리량이 안정됐습니다. 스레드 수가 많다고 좋은 게 아니라, 빠르게 반환되는 스레드가 좋다는 걸 그때 배웠습니다.
답변에서 흔히 빠지는 것들 — 빠져 있으면 꼬리질문이 깊어집니다.
이 질문에 이어 토스 백엔드 면접관이 던질 가능성이 높은 후속 질문.
이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 특정 회사가 실제로 이 질문을 출제했다는 것을 보장하지 않으며, 모든 예시는 우문현답이 직접 작성한 창작물입니다. 해당 회사의 공식 입장과는 무관합니다. 회사 측의 정정 요청이 있을 경우 24시간 이내에 응답·수정합니다.