튜토리얼 2026-05-10 · 약 20분

AWS Agent Toolkit와 Amazon Bedrock·CLI·npm이 동시에 타임아웃될 때, 2026년 Clash 분류로 코딩 에이전트 출구 맞추기

2026년 5월 AWS가 AWS Agent Toolkit을 내놓으면서, 검색과 커뮤니티 화제가 “모델 품질”만이 아니라 에이전트가 실제로 호출하는 AWS API·터미널 의존성 전체로 빠르게 옮겨 갔습니다. Amazon Bedrock으로 추론하고, AWS CLI와 각종 SDK로 리소스를 다루며, npm에서 CDK나 런타임 패키지를 받고, 샘플은 GitHub에서 git clone으로 가져오는 패턴은 이제 단일 스크립트 한 줄이 아니라 열 개 이상의 서로 다른 호스트를 동시에 밟습니다. 여기에 Model Context Protocol(MCP)로 편집기나 로컬 도우미가 붙으면 호스트 목록은 더 길어집니다. 브라우저만 맞춰 둔 프록시 규칙으로는 “콘솔은 되는데 CLI만 멈춘다” 같은 간헐 증상이 남기 쉽고, 그래서 이 글은 Clash의 분류 규칙 순서·DNS·노드 운용을 AWS 쪽 워크플로에 맞춰 정리합니다. 터미널·패키지·MCP까지 묶은 공통 패턴은 OpenCode·npm·GitHub 분류 글·Claude Code·MCP 글과 세트로 보셔도 좋습니다.

에이전트 툴킷이 네트워크 지도를 넓힌다

에이전트 스택이 두꺼워질수록 “한 벤더의 챗 API 한 줄”로 끝나지 않습니다. IaC 템플릿을 받아 배포하고 로그를 훑는 순간만 해도 AWS 서비스 엔드포인트가 여러 개로 갈라지고, 로컬에서는 자격 증명 갱신과 리전 기본값이 추가 요청을 만듭니다. 워크스테이션에서 돌아가는 런타임은 Node·Python·Go 등으로 갈리므로, 운영체제의 “시스템 프록시”를 존중하지 않는 프로세스가 섞이기 쉽습니다. 그 결과 패킷 레벨에서는 모두 정상인데 애플리케이션에서는 읽기 타임아웃처럼 보이는 상황이 잦아집니다.

  • 동시성: 채팅 스트림, 벌크 다운로드, 짧은 제어 플레인 호출이 한 작업 단위 안에서 겹칩니다.
  • 호스트 다양성: 추론, 제어, 패키지, Git, 브라우저 SSO 창마다 목적지 문자열이 달라집니다.
  • MCP: 로컬 서버는 루프백이지만, 마켓·문서·번들이 원격이면 별도 HTTPS가 붙습니다.

한 줄 요약

AWS Agent Toolkit을 도입했다는 사실 자체보다, 어떤 프로세스가 어떤 호스트를 실제로 치는지가 먼저입니다. Connections 로그를 단일 근거로 삼으세요.

다섯 축으로 나누기: Bedrock·자격증명·AWS API·npm·GitHub

규칙을 쓰기 전 머릿속 지도를 고정합니다. 첫째는 Bedrock 문서에 적힌 추론 및 관리형 호스트입니다. 둘째는 IAM·SSO·STS처럼 자격 증명과 세션을 만지는 축입니다. 셋째는 일반적인 EC2·S3·CloudWatch 같은 제어 플레인·데이터 플레인 호스트로 묶이는 공용 AWS API입니다. 넷째는 npm 레지스트리와 tarball CDN, 때로는 조직마다 다른 사내 프록시 레지스트리입니다. 다섯째는 GitHub의 웹·API·오브젝트 스토리지·raw 경로입니다. 리전과 조직 설정마다 문자열은 달라지므로, 문서에 나온 예시 도메인을 그대로 복사해 넣지 말고 본인 세션의 로그로 교차 검증해야 합니다.

이 다섯 축은 네트워크 특성이 다릅니다. 추론 스트림은 낮은 지터와 긴 세션 유지가 중요하고, npm은 수많은 작은 파일과 가끔 큰 tarball에 민감합니다. GitHub API는 출구 IP가 자주 바뀌면 레이트 리밋 메시지가 섞이기 쉽습니다. SSO 단계는 브라우저와 CLI가 서로 다른 프로세스 트리를 타므로, “로그인 창은 열렸는데 토큰만 안 온다” 식의 증상이 규칙 순서에서 설명되기도 합니다.

1단계: Connections에서 프로세스별 목적지 모으기

추측을 줄이는 것이 가장 저렴한 디버깅입니다. aws 바이너리, 언어별 SDK 런타임, node로 돌아가는 MCP 브리지, npm 자식 프로세스가 각각 어떤 SNI를 치는지 Clash 대시보드나 컨트롤러 로그에 적습니다. Windows에서는 WSL 내부 Node가 호스트와 다른 경로로 나가는 경우가 있어 WSL2·Clash 글을 함께 참고해 이중 스택을 점검합니다. 장시간 실험을 반복한다면 “같은 명령을 아침과 저녁에 실행했을 때만 실패한다”는 패턴이 노드 품질인지 경로 분리인지부터 가릅니다.

목록에 자주 등장하는 유형(환경마다 다름)

  • 리전을 포함한 Bedrock 호출 대상(문서·CLI 출력에서 재확인).
  • SSO Start URL·포털·토큰 교환에 쓰이는 호스트 묶음.
  • amazonaws.com 패밀리 안에서도 역할별로 다른 서브도메인이 있는 경우.
  • registry.npmjs.org와 실제 tarball이 뜨는 CDN 호스트.
  • github.com, api.github.com, objects.githubusercontent.com 등 서로 다른 접두사.

아래 YAML은 설명용 스켈레톤입니다. BEDROCK·AWS-AUTH·AWS-GENERAL·PKG-CDN·GITHUB 자리에 구독에 있는 proxy-group 이름을 넣고, 행은 로그로 채웁니다.

# Illustrative rules — replace proxy groups; verify hostnames in your logs
rules:
  - DOMAIN-SUFFIX,bedrock-runtime.example-region.amazonaws.com,BEDROCK
  - DOMAIN-SUFFIX,oidc.example-sso.amazonaws.com,AWS-AUTH
  - DOMAIN-SUFFIX,sso.example.amazonaws.com,AWS-AUTH
  - DOMAIN-SUFFIX,amazonaws.com,AWS-GENERAL
  - DOMAIN-SUFFIX,registry.npmjs.org,PKG-CDN
  - DOMAIN-SUFFIX,npmjs.org,PKG-CDN
  - DOMAIN-SUFFIX,github.com,GITHUB
  - DOMAIN-SUFFIX,githubusercontent.com,GITHUB
  - MATCH,DIRECT

분류 규칙은 위에서 아래로 첫 매칭이 승리합니다. 이미 RULE-SET을 끌고 있다면 그 안에 amazonaws.com 전체를 한 번에 던지는 행이 있는지 먼저 보고, 로컬 오버라이드가 실제로 살아 있는 위치인지 병합 규칙을 읽습니다. DOMAIN-KEYWORD,amazon처럼 지나치게 넓은 키워드는 다른 업무 SaaS까지 끌고 와 의도치 않은 프록시를 만들 수 있으니 최후 수단으로만 두는 편이 낫습니다.

2단계: 장시간 스트림과 “fat download”를 한 노드에 묶지 않기

모델 응답 스트림과 제어 플레인의 짧은 왕복은 한 TCP 패턴으로 이어질 수 있지만, npm install은 짧은 요청 폭발과 가끔 큰 tarball을 함께 끌고 옵니다. 둘을 동일한 url-test 그룹에 넣고 자동 전환을 공격적으로 돌리면, 스트림 중간에 출구가 바뀌어 재협상·재시도 폭주가 나고 CLI만 끊기는 현상이 생깁니다. CDK나 대형 번들을 설치하는 날에만 “베드락은 되는데 npm만 이상하다”는 패턴은 이 구조와 잘 맞습니다.

트래픽 노드에 바라는 성질 자주 생기는 실수
Bedrock 스트림 플랩이 적고 RTT가 안정적 속도 테스트 1위 노드만 고집
npm·대용량 에셋 처리량·재시도 친화 스트림과 같은 큐를 공유
GitHub API 출구 IP가 덜 바뀜 짧은 주기 자동 failover
SSO·STS 세션 일관성 브라우저 축과 CLI 축 노드 불일치

URL-TEST 주기와 허용 오차를 지나치게 타이트하게 두면 장시간 작업 중에도 후보 노드가 바뀝니다. 에이전트 세션용 그룹은 작업 시간 동안 수동 고정하거나 테스트 간격을 보수적으로 잡는 운용이 더 낫는 경우가 많습니다.

3단계: DNS·fake-ip·IPv6를 스택과 맞추기

브라우저, Electron 기반 IDE, 순수 터미널, 시스템 리졸버가 서로 다른 DNS 경로를 쓰면 같은 이름도 다른 애니캐스트 엣지로 갈라집니다. Clash에서 fake-ip를 쓰는 경우 일부 TLS 스택은 핸드셰이크 직후 끊기는 것처럼 보이기도 합니다. DNS·fake-ip 가이드의 순서대로 한 번에 한 변수만 바꿔 재현해 보세요.

  • IPv6: AAAA가 먼저 잡히면 의도와 다른 회선으로 나가는 사례가 있습니다.
  • Split tunnel: 회사 VPN과 병행할 때 터미널만 다른 라우팅 테이블을 타는지 확인합니다.
  • 캐시: 오래된 TTL이 남아 “방금 규칙을 고쳤는데도” 이전 목적지로 붙는 착시가 납니다.

주의

본문의 도메인 문자열은 이해를 돕기 위한 자리 표시자입니다. 실제 리전·조직·엔드포인트는 바뀔 수 있으니 항상 본인 Connections 로그를 단일 출처로 삼으세요.

4단계: TUN·환경 변수로 AWS CLI와 MCP 경로 확정

애플리케이션이 OS 프록시를 무시하면 TUN이 터미널과 언어 런타임에 유리한 경우가 많습니다. 반대로 TUN이 모든 트래픽을 끌어당겨 사내 SaaS와 충돌하면, 문제 프로세스만 골라내는 PROCESS-NAME 규칙이나 스플릿 앱 목록을 검토합니다. 보편적으로는 HTTPS_PROXY·HTTP_PROXY·ALL_PROXY를 셸 프로필이나 CI에 넣되, 해당 툴이 값을 존중하는지 확인합니다. Git의 http.proxy만 켜 두고 Node는 빈 손으로 나가면 증상이 격자무늬처럼 섞여 보입니다. 공통 패턴은 터미널·git·프록시 글과도 맞닿아 있습니다.

MCP로 Bedrock 클라이언트를 감싼 경우, 편집기 UI는 멀쩡한데 터미널 코덱스만 실패한다면 어느 바이너리가 설정 파일을 읽는지부터 갈라야 합니다. Connections에서 해당 자식 프로세스 이름을 추적하면 잘못된 MATCH,DIRECT나 낮은 우선순위 규칙에 걸린 흔적이 드러납니다.

5단계: MCP 레이어에서 터지는 지점 찾기

MCP 서버가 stdio로 로컬에 붙어도, 마켓에서 서버 목록을 받거나 원격 템플릿을 당기면 추가 HTTPS 호스트가 생깁니다. OAuth 루프백은 로컬이지만 토큰 교환 서버는 원격입니다. 플러그인 매니저가 별도 Node 자식을 띄우면 프로세스 필터도 달라집니다. Claude Code·MCP 분류 글에서 다룬 “웹 클라이언트와 다른 터미널 경로”는 Agent Toolkit 맥락에도 그대로 이어집니다. 차이는 브랜딩이 아니라 기본으로 붙는 AWS 호스트 집합과 빌드 체인이 끌고 오는 패키지 출처입니다.

  • 카탈로그 JSON: 버전 고정 URL이면 캐시와 충돌할 수 있습니다.
  • 원격 도구 번들: 압축을 풀 때 npm·GitHub 호출이 연쇄됩니다.
  • 에디터 vs CLI: 동일 MCP 이름이라도 실행 주체 프로세스가 다르면 규칙 매칭이 달라집니다.

다른 글과 겹치는 곳, 다른 곳

Anthropic·Claude 라우팅 글은 특정 챗 API 축에 가깝습니다. OpenCode 글은 터미널·npm·GitHub 비중이 큽니다. 이 글은 그 사이에서 AWS 제어 플레인·Bedrock·자격 증명·패키지·GitHub·MCP가 한 작업선으로 겹치는 검색 의도에 맞췄습니다. 규칙을 다른 글에서 통째로 복붙하지 말고 로그 패턴을 이식하세요. 그래야 리전 추가나 엔드포인트 변경에도 빠르게 따라갈 수 있습니다.

증상별로 의심할 순서

콘솔·문서는 되는데 AWS CLI만 응답이 없다

터미널이 DIRECT로 나가거나, CLI만 다른 불안정 노드에 걸린 경우를 의심합니다. TUN 전환과 환경 변수 주입 후 같은 목적지가 프록시 체인을 통과하는지 확인합니다.

SSO 로그인 직후 추론 호출만 실패한다

자격 증명 축과 Bedrock 축이 서로 다른 정책 그룹으로 갈리면 토큰이 유효해 보여도 중간에 끊깁니다. 두 축을 한 세션에서 일관된 출구로 묶었는지 봅니다.

npm는 대부분 되는데 특정 스코프만 실패

tarball이 다른 도메인으로 리다이렉트되면 레지스트리 행만으로는 부족합니다. 실패한 패키지 한 건에 verbose 로그를 켜 실제 URL을 확인하세요.

자주 묻는 질문

리전을 바꿨는데 갑자기 전체가 느려졌습니다.

리전 문자열이 바뀌면 Bedrock과 제어 API 호스트 집합이 함께 바뀝니다. 이전 리전에 맞춰 둔 좁은 규칙이 무용지물이 되거나, 광범위한 fallback에만 걸려 먼 CDN으로 새는 경우가 있습니다. Connections에서 새 호스트를 다시 수집하세요.

사내 프록시와 Clash를 같이 쓰면 충돌이 납니다.

사내망 대상은 DIRECT, 공용 클라우드 API는 프록시 그룹으로 두는 식의 스플릿이 필요합니다. 반대로 회사 룰을 무시하고 전부 터널에 넣으면 인증 실패가 납니다. 축 이름을 “업무 SaaS”와 “에이전트 개발”로 나눠 테이블을 유지하세요.

CI에서만 패키지 단계가 자주 타임아웃됩니다.

러너 환경에 프록시 환경 변수가 비어 있거나, 캐시 없이 매번 전 세계 미러를 돌 경우가 많습니다. Clash를 러너 호스트에 두거나, 동일한 규칙을 인프라 레벨 egress에 이식했는지 확인합니다.

실무 체크리스트

  1. 에이전트 실행 중 aws·언어 런타임·npm·git·MCP 보조 프로세스의 Connections 로그를 모은다.
  2. Bedrock, 자격 증명, 일반 AWS API, npm·CDN, GitHub 서브도메인을 정책 그룹에 매핑할지 결정한다.
  3. DNS·fake-ip·IPv6를 고정한 채 한 변수씩만 바꿔 재현한다.
  4. 장시간 스트림용 그룹과 대량 패키지용 그룹을 분리한다.
  5. TUN 또는 환경 변수로 터미널과 CI가 실제 Clash 출구를 통과하는지 검증한다.

정리와 제품 관점에서의 선택

일부 단일 목적 프록시 앱은 “브라우저 속도” 하나에 맞춰져 있어, AWS Agent Toolkit처럼 제어 플레인·Amazon Bedrock·CLI·npm·GitHub·MCP가 동시에 움직이는 개발자 작업선을 한 설정 트리에서 설명하기 어렵습니다. 규칙을 파일 한 덩어리로만 노출하거나 DNS 제어가 부족하면 증상이 간헐적으로만 남아 재현이 힘들어집니다. Clash 계열은 호스트·프로세스·정책 그룹의 분류 규칙을 쌓고 DNS와 TUN을 같은 구성 안에서 다룰 수 있어 에이전트 코딩 스택과 잘 맞습니다. 노드 선택을 작업 성격에 맞게 나누면 베드락 호출과 터미널 의존성 설치가 동시에 흔들리는 날을 줄이기 쉽습니다.

같은 원리를 다른 브랜드 키워드로 찾는다면 OpenCode·npm·GitHub 글과 함께 읽어도 좋습니다. 호스트 목록만 AWS 축에 맞게 갈아 끼우면 됩니다.

Clash를 무료로 내려받아 에이전트 출구를 직접 비교해 보세요

에이전트·Bedrock 출구 정리

AWS API·CLI·npm·GitHub를 나누고 개발 전용 정책 그룹에 묶으세요.

Clash 다운로드