Claude Code MCP request_timeout_ms: 60초 타임아웃을 설정 경로로 잡는 법 | DAKER 커뮤니티
Claude Code MCP request_timeout_ms란, MCP 서버별 도구 호출 대기 시간을 설정해 장기 실행 도구가 기본 timeout으로 끊기지 않게 하는 운영 설정입니다. 2026년 7월 11일 기준 최신 Claude Code changelog는 --mcp-config와 .mcp.json의 서버별 request_timeout_ms가 fresh session에서 무시되던 문제를 수정했다고 안내합니다. MCP 리포트 생성이나 사내 검색 도구가 60초 근처에서 반복 실패한다면, 오늘은 프롬프트보다 설정 경로부터 확인하세요.
DAKER 클로드 코드 MCP request_timeout_ms 60초 타임아웃 점검 만화 카드
문제 상황: MCP 도구가 왜 fresh session에서만 60초에 끊길까요?
한 줄 요약: 같은 MCP 도구가 긴 세션에서는 버티고 새 세션에서는 60초에 끊긴다면, 도구 성능보다 설정 적용 경로를 먼저 의심해야 합니다.
팀 MCP는 보통 리포트 생성, 내부 검색, 이슈 조회처럼 시간이 오래 걸리는 작업을 맡습니다. 그런데 새 Claude Code 세션에서만 장기 실행 도구가 짧게 끊기면 개발자는 “MCP 서버가 불안정하다”고 판단하기 쉽습니다. 최신 changelog 기준으로는 --mcp-config 또는 .mcp.json에 넣은 서버별 timeout이 fresh session에서 기본 60초처럼 동작하던 문제가 수정됐기 때문에, 팀은 버전과 설정 경로를 함께 점검해야 합니다.
핵심 개념: request_timeout_ms는 어디에 두고 어떻게 검증하나요?
핵심 포인트: request_timeout_ms는 “모든 MCP를 오래 기다리자”가 아니라, 오래 걸리는 특정 서버와 도구에만 근거를 붙여 조정하는 값입니다.
먼저 MCP 서버가 어떤 설정 파일에서 등록되는지 확인하세요. 프로젝트의 .mcp.json, 실행 시 전달한 --mcp-config, 사용자 설정이 섞이면 같은 서버 이름이라도 다른 timeout을 보고 있을 수 있습니다. DAKER의 설정과 메모리 디버깅 루프처럼 실제로 로드된 설정을 확인한 뒤, 장기 실행 도구에만 서버별 timeout을 부여하는 편이 안전합니다.
DAKER 클로드 코드 MCP request_timeout_ms 설정 경로 확인 워크플로 카드
단계별 사용법: MCP timeout 문제를 어떻게 좁히나요?
claude --version으로 팀 기준 버전이 최신 changelog 수정 이후인지 확인합니다.문제가 나는 MCP 서버가 프로젝트
.mcp.json, 별도--mcp-config, 사용자 설정 중 어디에서 등록되는지 적습니다.그 서버에만
request_timeout_ms가 있는지 확인하고, 전역으로 무리하게 늘리지 않습니다.새 Claude Code 세션에서 같은 도구를 다시 실행해 fresh session 재현 여부를 봅니다.
cold start에서 권한 프롬프트 도구가 MCP 서버를 가리킨다면, 서버 연결 전 오류와 실제 권한 거절을 구분합니다.
짧은 예시: 팀 런북에는 이렇게 남기세요
analytics MCP 서버는 리포트 생성이 2분 이상 걸릴 수 있다. .mcp.json의 request_timeout_ms 적용 여부를 fresh session에서 확인하고, 실패하면 서버 로그와 Claude Code 버전을 함께 남긴다.
이 문장은 “다시 시도해 봐”보다 낫습니다. 서버 이름, 설정 파일, 재현 조건, 증거 위치를 한 번에 남기기 때문입니다.
팀 적용 체크리스트: timeout을 늘리기 전에 무엇을 볼까요?
같은 서버 이름이 여러 설정 파일에 중복 등록되지 않았나요?
장기 실행 도구와 짧은 조회 도구를 같은 timeout으로 묶지 않았나요?
fresh session, resume session, background agent에서 같은 설정이 로드되나요?
권한 프롬프트 MCP 도구는 cold start 연결 순서를 확인했나요?
승인 자동화는 DAKER의 PermissionRequest hooks 글처럼 allow와 deny를 나눠 관리하나요?
공식 출처: 어떤 기준으로 확인했나요?
이 글은 2026년 7월 11일 기준 Anthropic Claude Code GitHub changelog 2.1.206과 2.1.205를 확인해 작성했습니다. 공개 본문에는 DAKER 운영 정책에 따라 외부 공식 URL을 직접 노출하지 않고, 기능명과 기준일만 남깁니다.
자주 묻는 질문
request_timeout_ms를 크게 잡으면 모든 MCP 문제가 해결되나요?
아닙니다. timeout은 기다리는 시간을 늘릴 뿐입니다. 인증 실패, 서버 연결 실패, 권한 프롬프트 오류는 별도로 구분해야 합니다.
.mcp.json과 --mcp-config 중 어디를 먼저 봐야 하나요?
실행 시 전달한 설정과 프로젝트 설정이 모두 후보입니다. 문제가 fresh session에서만 나면 실제 세션이 어떤 설정 파일을 읽는지 먼저 확인하세요.
MCP 서버별 timeout은 팀 문서에 남겨야 하나요?
남기는 편이 좋습니다. 특히 리포트 생성처럼 오래 걸리는 도구는 timeout 값, 이유, 담당 서버를 함께 기록해야 나중에 과도한 대기 시간을 줄일 수 있습니다.
권한 프롬프트 도구가 MCP에 있으면 무엇이 달라지나요?
cold start에서는 MCP 서버 연결 전 오류와 실제 권한 판단 실패를 구분해야 합니다. 최신 changelog는 이 연결 순서 관련 crash 수정도 함께 다룹니다.
오늘 팀 MCP 런북에서 서버별 timeout 값을 한 줄만 확인해 두면, 다음 장애 때 “느린 도구”와 “적용되지 않은 설정”을 더 빨리 나눌 수 있습니다.