AWS MCP Server GA 이후 코딩 에이전트가 AWS API만 장시간 타임아웃될 때: STS·Regional 엔드포인트·게이트웨이를 Clash(mihomo)로 분기한 실무 (2026)

1. AWS MCP가 패키지 지연과 다른 이유

AWS MCP Server 계열 기능은 MCP 메시지만 보이고, 안쪽에서는 AWS SDK가 쓰는 것과 같은 Regional 엔드포인트 패턴을 따라갑니다. 예를 들어 secretsmanager.eu-west-1.amazonaws.com 같은 FQDN이 연속 호출되는데 규칙이 IDE 전용 호스트 세트에 묶여 있으면 패킷 일부만 DIRECT로 떨어져 느린 국내 회선만 타거나, 다른 노드에서는 TLS 핸드셰이크까지 가지 못합니다. MCP UI에선 사용자가 패키지를 한 번도 깔지 않았는데도 Coding Agent가 STS를 호출해야 하므로, IAM 정책과 별개로 네트워크 레이아웃 자체가 먼저 엇갈릴 가능성부터 본다고 생각하는 편이 빠릅니다.

반대로 패키지 기반 MCP라면 조직 사내 NPM 미러 때문에 꼬이는 패턴과 섞입니다. 그때는 Model Context Protocol·npm 규칙 블록부터 다시 깔지만, 순수하게 REST AWS API 게이트웨이와 IAM 제어 플레인 호스트 묶음이라면 패키지 캐시를 만져도 시간낭비일 수 있습니다. 문서에서는 GA 직후 흔한 질문이 "왜 MCP만 시간이 많이 걸리나요?"인데 그 답 중 하나가 Clash 규칙 스택이 AWS 축까지 아직 포함되지 않았다는 사실입니다.

2. MCP가 실제로 부르는 AWS 트래픽 맵

정확히는 조직 선택과 도구 패키지에 따라 다르지만, 일반적인 흐름은 credentials 체인 → Regional 서비스 → 람다 또는 HTTP API 게이트웨이 호출 백패스처럼 3축입니다. STS로 갱신 토큰을 받거나 AssumeRole을 태울 때 sts.ap-northeast-2.amazonaws.com 과 sts.amazonaws.com 이 같이 목록에 뜹니다. 이어 Secrets Manager나 CloudWatch 로그 업로드를 붙였다면 secretsmanager.region.amazonaws.com 과 logs.region.amazonaws.com 줄이 새로 깔립니다. 이 축 각각은 별도 회선 상태를 가질 수 있으므로, 한 호스트만 프록시 규칙 밖으로 걸어도 MCP 전체 레이턴시가 깨집니다.

boto3는 환경 변수·프로파일 순서와 리전 문자열 때문에 실제 접속 순서도 조금 달라집니다. AWS_REGION 이 비어 있는 요청이라도 상위 MCP 구현체가 디폴트 리전 문자열을 박았는지부터 확인해야, 예상과 다른 접미 문자열 때문에 규칙이 미스 매칭되는지 여부를 줄일 수 있습니다. 동시 다발 도메인이 보이므로 DOMAIN-SUFFIX 방식 한 번에 접는 전략이 실무에서는 자주 채택됩니다.

3. API 게이트웨이·워크플로별 출구 패턴

일부 MCP 구현체는 사용자 정의 브라우저 훅이 아니라 API Gateway 실행 URL 패턴인 <id>.execute-api.<region>.amazonaws.com 으로 HTTP 백패스합니다. 즉 MCP 메시지만 보더라도 콘솔에서는 보기 어려운 게이트웨이 줄이 새로 깔립니다. 이 줄을 패키지 다운 규칙에 넣어두었다고 생각했다가 실패하는 사례가 빈번하기 때문에 실행 엔진의 문서 블록에 나온 FQDN을 그대로 Clash rules 상단 블록에 옮기거나, 패턴까지 한데 묶었는지 검토합니다.

만약 MCP가 사용자 조직별 프라이빗 엔드포인트 또는 자체 라우팅 도메인을 가리키도록 커스터마이즈됐다면 PUBLIC_AWS_GATEWAY_ENDPOINT 같은 환경 변수가 존재하는지부터 살피세요. 변수가 있다면 문자열 하나가 전체 MCP 트래픽을 새 도메인으로 돌립니다. DNS spoofing 또는 DNS leak 으로 잘못된 IP만 맞았을 때는 TLS 경고까지 가기 전 장시간 SYN 대기처럼 느껴져도 로그 레벨이 낮은 클라이언트에선 MCP만 멈춘 것처럼 보입니다.

4. DNS·fake-ip 스니퍼와 TLS 행태

mihomo 사용자는 fake-ip 모드를 켠 뒤에도 이름 해석이 OS에 그대로 열린 경우 문제를 겪기 쉽습니다. MCP가 Node 런타임에서 돈다면 해당 프로세스가 127.0.0.53 같은 로컬 DNS를 그대로 쓸 수 있습니다. 결과적으로 패킷이 Clash 이름 해석 레이어를 거치기 전부터 엇나가서 규칙이 기대처럼 히트하지 않거나, 이름은 맞는데 선택된 노드가 달라 TLS 라운드 트립 시간이 깨지기도 합니다. sniffer 기능을 쓰더라도 SNI 문자열 없이 순수하게 IP로만 붙으면 MCP 내부 SDK가 무엇과 대화했는지 UI로는 불명료할 때가 많습니다.

IPv6 활성 상태에서 더 복합적으로 보일 수 있습니다. 같은 *.amazonaws.com 이어도 AAAA 레코드를 따로 두드리므로 규칙에 IPv6 정책이 빠져 있거나 이중 스택 회선 불균형 때문에 한쪽 레코드만 DIRECT로 새는 패턴입니다. 해당 주제 전체 접근 순서가 필요하면 IPv6·DNS 미세 조정 글 을 순서 그대로 밟으며 로그 패턴 비교하면 편합니다. 정리하면 Model Context Protocol MCP 전용 로그가 아니라 mihomo /logs 와 systemd journal 혹은 Windows 이벤트에서 DNS 질의 주체까지 같이 따라가세요.

5. mihomo rules 개념 스니펫

아래는 샘플입니다. 정책 그룹명은 사용 중인 YAML 이름으로 바꿉니다. 회사 규격상 일부 레코드를 DIRECT로 빼야 하면 STS보다 더 위 순서에서 예외 줄을 놓습니다. 주석은 규격상 영어입니다.

# Example — reorder for your corp DIRECT exceptions
rules:
  - DOMAIN,sts.amazonaws.com,PROXY_AWS_SESSION
  - DOMAIN-SUFFIX,execute-api.us-east-1.amazonaws.com,PROXY_AWS_SESSION
  - DOMAIN-SUFFIX,execute-api.ap-northeast-2.amazonaws.com,PROXY_AWS_SESSION
  - DOMAIN-SUFFIX,amazonaws.com,PROXY_AWS_SESSION
  - DOMAIN,signin.aws.amazon.com,PROXY_AWS_SESSION
  - DOMAIN,console.aws.amazon.com,PROXY_AWS_SESSION
  - DOMAIN-SUFFIX,awsapps.com,PROXY_AWS_SESSION

PROXY_AWS_SESSION 이름은 선택일 뿐이며, 장기 간 보수용으로 실제 선택형 그룹이나 url-test 그룹을 붙이면 노드 상태가 MCP 전체 회복력에 즉각 반영됩니다. 지연 테스트·폴백 그룹 과 구독 동기 안정화 절차를 같은 날 업데이트하면 조직 MCP 도입 테스트 시 반복 깜빡임을 줄입니다. 다만 과도하게 넓은 MATCH 한 줄 처리는 추적 불가 때문에 실무 MCP 운영에선 신중해야 합니다.

6. boto3·AWS CLI로 네트워크 대 IAM 분리 검증

MCP 대화창 문제인지 회선 문제인지를 가르는 가장 간단한 기준은 동일 자격증명 문자열과 동일 리전을 쓴 aws sts get-caller-identity 혹은 python REPL 에서 간단히 boto3 client('sts').get_caller_identity() 를 돌린 결과입니다. 셸에서는 빠르고 MCP만 무한히 기다린다면, 에이전트가 붙일 때 환경 변수나 프록시 인식이 다른지 검토합니다. 거꾸로 둘 다 멈추면 IAM 정책과 무관하게 TLS 경로 차단 또는 DNS일 확률이 큽니다. 그때 Clash 패널 로그 시간축과 openssl s_client 로우 레벨 점검을 병행합니다.

권장 오브젝트는 MCP가 실제 호출했다고 명시되는 서비스입니다. 저장소 MCP가 RDS 메타까지 읽는다면 해당 리전 문자열 그대로 describe-db-instances 처럼 간단 명령을 CLI로 우선 성공 확인하고, MCP에서만 실패하면 런타임 상속 값을 추적하면 됩니다. CLI에서도 같은 오류 문자열이라면 MCP보다 규칙이나 STS 자체 수정이 필요해집니다. 이 단계에서는 Coding Agent 프롬프트에 자격증명 없이 테스트하는 것만으로 문제를 축약할 수 있습니다.

7. SSO·브라우저 리다이렉트가 열리는 호스트

조직 SSO를 쓰면 AWS 콘솔처럼 portal.sso.ap-northeast-2.amazonaws.com 과 브라우저 OIDC 교환 패턴용 도메인 줄이 MCP 자격 체크 전에 새로 깔립니다. 웹에서는 이미 허용돼 에이전트만 막히는 상태가 많은데 원인 중 하나가 Clash 브라우저 전용 블록 과 Node 자식 MCP 서버 블록 순서 차이 때문입니다. DOMAIN-SUFFIX awsapps.com 과 oidc.region.amazonaws.com 줄을 MCP 전용 블록에 포함시켜야 반복 브라우저 인증 타임아웃이 줄어듭니다. 동시 HTTPS 요청 많을 때 MCP가 자동 리프레시 토큰을 주고받는 동안 줄이 새도 스니퍼로 실제 문자열까지 확인해야 합니다.

8. 에이전트 자식 프로세스·TUN·환경변수 정렬

Coding Agent가 Node 기반 MCP 자식 프로세스를 새로 만들면 해당 PID는 종종 부모 편집기의 시스템 프록시 상속값을 무시합니다. 따라서 패킷 레벨에서는 TUN 모드 또는 OS 전역 DNS 가이드를 맞춰야 합니다. Windows에선 Verge 레이어별 순서 참고가 필요해 Verge 문서 패턴형 글 과 UWP 브레이크 패턴까지 같이 놓습니다. macOS에서는 터미널 레이어 차이 때문에 LaunchAgent 안 HTTP_PROXY 문자열 삽입 과 Clash 패킷 헤더가 같은지 교차 테스트합니다.

AWS 전용 MCP는 인증 과정까지 자동이라면 패마다 HTTPS_PROXY=http://127.0.0.1:7890 같은 줄을 MCP 메타데이터 JSON에 명시해야 하는 사례도 있습니다. 문자열 형식까지 잘못되었을 때는 연결 문자열 검증까지 가지 않고 그냥 네트워크 unreachable 로만 남습니다. MCP 설치 방법이 패키지가 아니더라도 내부적으로 uvx 나 pnpm dlx 런처를 타는 레이어도 있으므로 pnpm·레지스트리 분할 글 까지 겹치는지 함께 보는 편이 안전합니다.

9. 실측 점검 체크리스트

첫째, 동일 시간대 동일 회선 아래 MCP와 CLI가 같은 명령을 성공했는지 기록합니다. 둘째, mihomo 연결 패널에서 AWS 관련 줄이 선택한 정책 그룹에 찍혔는지 스크린 숏 이상으로 증명합니다. 셋째, DNS 패널 또는 dig 출력에서 fake-ip 문자열 여부 확인합니다. 넷째, IAM SCP 나 역할 신뢰 정책에서 세션 문자열 차단이 있는지 MCP 전용 이름으로 필터링합니다. 다섯째, MCP 릴리스 노트 또는 GA 채널에서 리전 문자열 디폴트 변경이 발표된 주간을 비교해서 로그 줄이 교체되지 않았는지 업데이트합니다. 단계마다 패킷 패턴 변경이 발생하면 레포지토리 레벨 MCP YAML도 같이 올립니다.

장애 회고문을 남긴다면 "MCP 패널에서는 보이지만 실패" 와 같은 문장형보다 FQDN·HTTP 상태 문자열 또는 TLS 오류 줄을 시간순 타임라인으로 남길 때 네트워크·보안 두 팀 간 합류가 빨라집니다. Model Context Protocol 디버깅은 한 줄이라도 MCP 상위 채널 밖 패킷을 보게 만드는 경험일 때 가장 많이 줄어듭니다.

10. 자주 묻는 질문

AWS MCP 타임아웃이 boto3 같은 CLI에서도 같은가요?

동일 회선이라면 패턴적으로 같습니다. MCP만 깨져 있다면 MCP 런타임 특유의 환경 변수나 자식 프로세스 프록시 미적용 같은 예외 레이어부터 봅니다. TUN 테스트로 교차 증명하세요.

DOMAIN_SUFFIX amazonaws.com 한 줄로 넣어도 되나요?

실무 MCP 온보딩에서 속도 우선이라면 허용됩니다. 회사 규격에선 내부 전용 접미나 직연결 대역을 DIRECT로 놓아야 하는 경우 많으므로 순서 블록을 문서화하세요.

STS는 글로벌 STS와 리전별 STS 엔드포인트 차이도 있나요?

SDK 문자열 순서 때문에 둘이 섞입니다. 로그 줄을 그대로 Clash 줄에 이름으로 재사용하면 가장 명확합니다. 광역 패턴이라도 STS 두 줄 예외를 깜빡하지 않도록 체크리스트에 포함하세요.