Incident Library

IL-0448 Uzabase · 2026-07-28 (게시일)kubernetesnetworking

Job 파드가 15분 넘게 걸리는 LLM 에이전트 요청의 응답을 일정 확률로 받지 못하고 계속 기다렸다

Uzabase 의 Speeda 사업 Product Team 은 LLM 에이전트로 여러 공개 자료에서 기업의 경영 과제를 뽑아 목록으로 만든다. 품질을 높이려고 에이전트가 리뷰를 여러 번 되풀이하므로 응답까지 15분 넘게 걸리는 일이 많았다. 클라이언트인 Job 파드가 에이전트에 요청하면 일정 확률로 응답이 오지 않았다. 에이전트 로그에는 응답을 정상으로 보낸 기록이 있었다. 두 쪽 로그를 맞춰 보니 응답까지 대략 13분 넘게 걸린 요청이 실패하고 있었다.

팀은 Claude Code 와 함께 조사하다 원인을 찾았다. 클러스터는 kube-proxy 의 IPVS 모드로 통신을 라우팅했다. ConfigMap 의 KubeProxyConfiguration 에서 IPVS 의 tcpTimeout 이 0s 로 남아 있어 기본값 15분이 쓰였다. 15분 넘게 패킷이 오가지 않은 TCP 커넥션은 IPVS 의 커넥션 관리 테이블에서 지워진다. 이 테이블은 어느 커넥션을 어느 파드로 보내는지 세션 단위로 기록해 둔다. 커넥션이 지워질 때 클라이언트와 에이전트에는 아무 알림이 없고 RST 도 FIN 도 가지 않는다. 두 쪽은 커넥션이 살아 있다고 여겼다. 에이전트가 보낸 응답은 클라이언트에 닿지 않았고, 클라이언트는 응답을 계속 기다렸다. 팀은 Python 으로 쓴 클라이언트에서 TCP keepalive 를 켜 커넥션을 유지하는 방법으로 해결했다.

심각도
–
영향 범위
Requests from Job pods to the LLM agent that took longer than about 15 minutes never received their responses
영향 사용자
–
지역
–
감지까지
–
복구까지
–

증상

클라이언트인 Job 파드가 LLM 에이전트에 경영 과제 추출을 요청하면 일정 확률로 응답이 돌아오지 않았다. 응답이 오지 않는 요청에 뚜렷한 규칙이 보이지 않아 조사가 초반에 막혔다.

클라이언트 로그를 보면 일부 작업은 끝났다는 기록이 없는 채로 남아 있었다. 그 작업에는 60분이 지나자 클라이언트에 설정해 둔 강제 재시도가 걸렸다.

팀은 처음에 에이전트 쪽에 문제가 생겨 일부 요청에 응답하지 않는다고 의심했다. 그러나 에이전트 로그에는 응답을 정상으로 보낸 기록이 있었다. 그래서 팀은 쿠버네티스 네트워크의 문제를 의심하고 조사를 이어 갔다.

클라이언트와 에이전트의 로그를 맞춰 보니 응답까지 대략 13분 넘게 걸리는 요청이 실패하고 있었다. 팀은 네트워크 어딘가에서 타임아웃이 걸린다고 보고 조사했다.

증상 간헐적 타임아웃

원인

원인 DNS·네트워크 장애

구성 요소 kube-proxy
기여 요인 기본 설정 방치한계 미인지
촉발
LLM 에이전트가 리뷰를 여러 번 되풀이해 응답에 15분 넘게 걸렸고, 그동안 TCP 커넥션에 패킷이 오가지 않았다.

감지

팀은 클라이언트 로그에서 Job 파드의 요청 일부에 응답이 돌아오지 않는 것을 확인했다.

조치

후속 조치

–

교훈

소프트웨어 엔지니어는 애플리케이션에만 관심을 두기 쉽지만 네트워크와 인프라 지식도 갖춰야 한다. AI 애플리케이션이 흔해지면서 응답까지 오래 걸리는 경우가 늘어날 것이므로, 원인을 알 수 없는 네트워크 오류가 나면 이 설정을 떠올릴 만하다.

출처

관련 사례

내 클러스터에도 있는지 확인하기

kubegap 은 Claude Code 나 Codex 에서 쿠버네티스 클러스터를 읽기만 하며 이 사례와 같은 상태를 점검합니다. 이 사례의 구성 요소: kube-proxy. 점검 항목의 근거는 이 사례 같은 공개 보고서입니다.

kubegap 열기

AI 도구와 스크립트용

API 는 키가 필요 없습니다. MCP 서버는 search_incidents, get_incident, list_incidents, get_topic, vocab 도구를 내놓습니다. 사용법은 API 와 MCP.