AWS Agent Toolkit IDE 오류? IAM·STS와 툴 API용 Clash 분할 실측 (2026)

2026년 AWS Agent Toolkit이 IDE 트래픽을 넓히는 방식

AWS Agent Toolkit은 생성형 AI 코딩 에이전트가 편집기 안에서 스킬 체인을 돌리도록 돕는 공식 방향의 툴링에 가깝고, 실제 네트워크에서는 IAM 자격 증명 확인·STS 임시 토큰·리전별 *.amazonaws.com API가 한 세션 안에서 연달아 열립니다. 사용자 입장에서는 “스킬 한 번 실행”이지만 백엔드에서는 GetCallerIdentity 같은 글로벌 호출 다음에 Bedrock Agent Runtime·Lambda·CloudFormation처럼 접두가 붙은 호스트로 이어지기도 해서, 규칙 한 줄이 빗나가면 전체가 ETIMEDOUT처럼 보이기 쉽습니다.

Visual Studio Code와 Cursor처럼 확장 생태계가 있는 IDE에서는 Toolkit 본체 트래픽과 마켓·보조 AI 확장이 동시에 놓입니다. 여기에 로컬에서 돌아가는 언어 런타임이 다시 AWS SDK를 부르면, 브라우저에서 보던 콘솔 경로와 완전히 다른 TLS 레그가 생깁니다. 이 글은 정책 위반 우회가 아니라, 허용된 회선 안에서 Clash 분할로 관측 가능한 호스트 축을 고정하는 데만 초점을 둡니다.

AWS MCP Server 가이드와 무엇이 다른가

같은 IDE 안에서 AWS MCP Server를 병행하면 프로토콜 레벨의 툴 호출과 Toolkit 스킬이 서로 다른 프로세스 트리를 탈 수 있습니다. 호스트 패턴은 amazonaws.com 가족으로 크게 겹치지만, MCP 쪽은 종종 Node·Python 의존성 설치나 추가 레지스트리를 열고, Toolkit은 편집기가 붙인 SSO·자격 증명 브로커 쪽을 더 자주 밟습니다. 따라서 한쪽만 안정화했다고 다른 쪽 증상까지 사라진다고 단정하기 어렵습니다.

범용적으로는 MCP·툴체인 분할 가이드를 함께 두고, AWS 축만 이 글과 MCP 전용 글에서 교차 확인하는 구성이 재현 비용을 줄입니다. 핵심은 “같은 계정인데 왜 브라우저만 빠른가”가 아니라 목적지 FQDN·매칭된 프록시 그룹을 로그로 일치시키는 일입니다.

증상을 세 레이어로 자르기

첫 레이어는 글로벌 게이트입니다. sts.amazonaws.com·iam.amazonaws.com에서만 지연되거나 실패하면 AssumeRole 이전 단계가 무너진 것이므로, 리전별 줄보다 먼저 이 축을 안정 노드나 회사 정책이 허용한 직통으로 고정합니다. 둘째 레이어는 리전 서비스 호스트입니다. 예를 들어 lambda.ap-northeast-2.amazonaws.com처럼 리전 접두가 붙은 이름이 GEOIP 기반 광역 규칙에 걸려 예상과 다른 노드로 새면, 스킬 중 특정 API만 가끔 실패하는 패턴이 납니다.

셋째 레이어는 사람 중심 로그인입니다. signin.aws.amazon.com·console.aws.amazon.com과 IAM Identity Center 조직 도메인은 브라우저 창과 IDE가 동시에 건드립니다. 브라우저는 이미 안정적인데 Toolkit 인증 창만 멈춘다면 이 레이어가 다른 전략 그룹으로 새고 있을 가능성이 큽니다. 세 레이어마다 DOMAIN-SUFFIX 줄을 분리해 두면 나중에 노드 교체·회선 변경 시에도 diff가 작습니다.

참고: 실제로 열리는 호스트는 리전·파티션·사용 서비스에 따라 달라집니다. 아래 패턴은 출발점일 뿐이며, 확정은 항상 Clash 연결 목록과 IDE 디버그 채널의 원문 URL을 기준으로 하세요.

Toolkit 주변에서 자주 보는 도메인 묶음

자격 증명·식별: STS와 IAM 글로벌 엔드포인트는 스킬 시작 시 한 번이라도 막히면 이후 호출이 줄줄이 대기 상태로 보입니다. 실행형 스킬: Bedrock 에이전트·Lambda·Step Functions 등은 보통 서비스명.리전.amazonaws.com 형태입니다. 한 줄짜리 DOMAIN-SUFFIX,amazonaws.com 규칙이 편하지만, 회사 정책상 특정 리전만 우회해야 한다면 접두를 좁혀 위험 표면을 줄이는 편이 안전합니다.

로그인·SSO: 조직에서 발급한 *.awsapps.com 리다이렉트가 추가되면 GEOIP보다 위에서 별도 그룹으로 묶지 않으면 “콘솔은 되는데 토큰 교환만 실패” 같은 증상이 남습니다. 국내 직통 보존: 넓은 GEOIP,CN,DIRECT나 국내 CDN 직통 줄이 먼저 매칭되도록 두었다면, 그 아래에 두면 안 되는 호스트가 있는지 다시 읽어야 합니다. 의도는 중국 본토 사용자가 국내 리소스를 빠르게 쓰게 하는 것이지, amazonaws.com까지 같이 직통으로 보내려는 것이 아니라면 순서를 분리해야 합니다.

IDE 부가 트래픽: 확장 업데이트·테마 폰트 같은 흐름은 IDE AI 분할 글과 겹칩니다. Toolkit 스킬이 패키지 매니저를 호출하면 레지스트리 축도 함께 열리므로, 증상이 복합적일 때는 연결 로그에 npm·Git 호스트가 섞였는지부터 확인합니다.

proxy-groups와 rules 개념 스케치

아래는 이해를 돕는 축약 예입니다. 구독의 실제 proxies 이름으로 바꾸고, 로그에서 새로 잡힌 FQDN을 한 줄씩 덧붙이세요. AWS-STS-IAM은 지연에 민감한 글로벌 레그, AWS-Regional은 리전 API, AWS-Login은 브라우저 리다이렉트에 맞춘 풀을 연결하는 식으로 나눕니다.

YAMLproxy-groups:
  - name: "AWS-STS-IAM"
    type: url-test
    url: "https://sts.amazonaws.com"
    interval: 120
    tolerance: 50
    proxies:
      - DIRECT
      # 저지연 노드 ...

  - name: "AWS-Regional"
    type: select
    proxies:
      - DIRECT
      # 리전 API용 ...

  - name: "AWS-Login"
    type: select
    proxies:
      - DIRECT
      # 로그인·콘솔 ...

rules:
  - DOMAIN-SUFFIX,sts.amazonaws.com,AWS-STS-IAM
  - DOMAIN-SUFFIX,iam.amazonaws.com,AWS-STS-IAM
  - DOMAIN-SUFFIX,signin.aws.amazon.com,AWS-Login
  - DOMAIN-SUFFIX,console.aws.amazon.com,AWS-Login
  - DOMAIN-SUFFIX,amazonaws.com,AWS-Regional
  - DOMAIN-SUFFIX,aws.amazon.com,AWS-Login
  # GEOIP·RULE-SET·MATCH보다 위인지 최종 확인

amazonaws.com 한 줄이 너무 아래에 있으면 상단의 광역 GEOIP나 외부 RULE-SET이 STS만 다른 경로로 보내는 역설이 생깁니다. “위에서 아래 첫 일치” 원칙은 규칙 분할 가이드와 동일합니다.

실측 절차: 로그부터 TUN까지

아래 순서는 현장에서 증상을 빠르게 좁힐 때 쓰기 좋습니다. 각 단계에서 호스트명 메모를 남기면 이후 Mihomo·Clash Verge 프로필에 그대로 반영할 수 있습니다.

  1. Toolkit 스킬을 재현한 직후 Clash 로그에서 목적지 호스트와 매칭된 정책·프록시 그룹을 적습니다. 의도와 다른 그룹이면 규칙 순서를 가장 먼저 의심합니다.
  2. 동일 머신 터미널에서 curl -v https://sts.amazonaws.com와 문제 리전의 서비스 엔드포인트를 교차로 호출해 TLS 왕복 시간을 비교합니다. IDE만 느리면 HTTPS_PROXY·NO_PROXY와 브라우저 설정 차이를 봅니다.
  3. enhanced-mode: fake-ip를 쓰는 프로필이라면 fake-ip-filter에 STS·로그인 호스트가 필요한지 확인합니다. 이미 IP로 붙는 클라이언트는 도메인 규칙이 스킵되어 다른 매칭으로 새기도 합니다.
  4. VS Code·Cursor의 시스템 프록시 따르기 여부와 Clash mixed-port를 맞춥니다. 확장이 자식 프로세스를 띄우면 부모와 다른 환경 변수를 물려받는 경우가 있습니다.
  5. 여전히 경로가 엇갈리면 TUN 모드로 전환해 커널 레벨에서 일관되게 Clash를 통과하는지 비교합니다. DNS와 UDP가 겹치면 증상이 바뀌는지가 결정적 힌트입니다.

주의: 출처가 불명확한 RULE-SET은 예고 없이 광역 매칭을 넣을 수 있습니다. 프로덕션 자격 증명이 있는 워크스테이션에서는 신뢰 가능한 구독과 로컬 명시 규칙을 우선하고, 변경 후에는 짧은 연결 테스트로 회귀를 확인하세요.

자주 묻는 질문

Q. 스킬 목록은 보이는데 실행만 간헐적으로 멈춥니다. A. 체인 중간 호스트 하나가 다른 노드로 새면 전체가 타임아웃처럼 보입니다. 로그에서 실패 직전 세 연결의 목적지가 모두 같은 그룹인지 확인하고, STS·리전·로그인 줄을 분리해 재측정하세요.

Q. MCP 없이 Toolkit만 씁니다. 여전히 이 글이 필요한가요? A. 네. MCP 연결 여부와 무관하게 SDK 경로의 IAM·STS·amazonaws.com 축은 동일하게 드러납니다. 다만 MCP를 추가하면 AWS MCP 분할 글과 교차 점검이 필요합니다.

마무리

AWS Agent Toolkit은 IDE 안에서 짧게 보이는 스킬 이름 뒤에 IAM·STS·리전별 API·브라우저 로그인을 한꺼번에 실어 나릅니다. 이 축을 한 그룹에 몰아 넣으면 로그만 길어지고 원인 추적은 더 어려워집니다. 반대로 DOMAIN-SUFFIX와 전략 그룹으로 세 레이어를 나누면 “AI 코딩 에이전트만 유난히 불안정하다”는 체감을 빠르게 수치로 줄일 수 있습니다.

브라우저 전용 VPN이나 단일 토글형 클라이언트는 IDE 자식 프로세스와 리전별 amazonaws.com 조합까지 동일한 우선순위로 다루기 어렵고, 호스트 단위 미세 조정도 제한적인 경우가 많습니다. ClashSource가 안내하는 Clash·Mihomo 계열 설정은 파일 하나에서 규칙 순서·DNS·TUN을 함께 다룰 수 있어, 2026년처럼 IDE 프록시와 퍼블릭 클라우드 API가 겹치는 개발 환경과 잘 맞습니다. 과장 없이 말하면, 도구가 제공하는 건 “회선을 바꿀 수 있는 통로”이고 안정성은 결국 관측 가능한 호스트 목록과 순서 설계에서 나옵니다.

설치와 기본 프로필 적용은 문서 허브를 참고한 뒤, 분할을 적용할 준비가 되었다면 Clash 클라이언트를 무료로 다운로드해 본문 예시를 바탕으로 proxy-groups와 rules만 조정해 보시길 권합니다. Toolkit 연결이 안정되면 에이전트 스킬 실패로 끊기던 편집 흐름이 한결 덜 끊깁니다.