증상: 콘솔은 되는데 MCP·Bedrock만 ‘전체 타임아웃’처럼 보일 때

2026년 전후로 IDE·CLI에서 바로 붙는 Model Context Protocol(MCP) 생태계가 빠르게 정리되고, 클라우드 공급자 측 AWS MCP Server·Agent Toolkit for AWS 같은 공식·준공식 툴링도 검색 노출이 늘어난 시기입니다. 사용자 입장에서는 한 화면에서 계정 연동·모델 호출·도구 실행을 기대하는데, 실제 패킷은 브라우저 기반 AWS 콘솔 줄과 Amazon Bedrock 런타임 API, 그리고 문서·콘솔 자산을 실어 나르는 CDN 축으로 갈라집니다. 그중 한 줄만 느리거나 다른 Clash 정책으로 새면, 앱 레벨에서는 분 단위 대기·재시도 루프·빈 응답으로 관측되어 「노드 전체가 불량」이라는 단정으로 이어지기 쉽습니다.

특히 회사망·Zero Trust·지역 회선을 오가는 개발자에게는 signin.aws.amazon.com 같은 로그인 스택과 *.amazonaws.com 리전 엔드포인트, 그리고 OAuth 콜백·조직 SSO가 붙은 접미가 서로 다른 DNS 경로·TCP 경로를 타는 경우가 많습니다. Bedrock은 리전 선택에 민감하고, 스트리밍 응답이 긴 편이라 HTTP/2 협상·중간 프록시 설정이 미세하게 어긋나도 체감 지연이 크게 불어납니다. 그래서 첫 화면부터 속도 테스트 숫자가 아니라 Clash 라이브 연결 로그의 정책 칼럼을 펼치는 습관이 중요합니다.

공통 진단 틀은 연결 로그·TLS 타임아웃과 규칙 매칭 모범을 병행하는 편이 빠릅니다. 같은 증상이라도 내장 터미널·외부 터미널·IDE 호스트 프로세스는 환경 변수 상속이 달라 한 번 관측했다고 끝내기 어렵습니다. 세션 종류별로 필터 문자열을 바꿔 비교하세요.

ℹ 첫 필터: 실패 직후 amazonaws, aws.amazon, awsapps, cloudfront, bedrock, 로그에 찍힌 OIDC·STS 접미를 넣어 보세요. 한 줄이라도 정책 문자열이 다르면 노드를 갈아치우기 전에 도메인 분류 한두 줄이 답인 경우가 많습니다.

이름 공간: 콘솔·STS·OIDC·Bedrock 런타임·CloudFront CDN

아래는 출발점용 체크리스트입니다. 계정 플랜·리전·SSO·기능 플래그에 따라 하위 호스트는 바뀔 수 있으므로, 팀은 실제 로그 문자열과 날짜를 YAML 주석에 남기는 편이 안전합니다. Notion·AWS 글이 다루는 협업 동기화 축과 겹치는 부분이 있어도, 이번 글의 초점은 MCP·에이전트 런타임이 반복적으로 두드리는 AWS 이름 공간입니다.

브라우저 중심 시나리오와 달리 MCP 컨슈머는 HTTP_PROXY 계열 변수·셸 프로파일·IDE 통합 터미널의 상속 차이까지 겹칩니다. «같은 노드인데 왜 브라우저만 된다»는 말이 자주 나오는 이유입니다.

AWS MCP Server·Agent Toolkit에서 자주 갈라지는 축

AWS MCP Server는 IDE가 도구 호출을 원격에 맡길 때 연속적으로 여러 AWS 서비스 엔드포인트를 밟습니다. 한 줄이 직접 회선으로 떨어지고 다른 줄만 상위 프록시로 가면, 사람 눈에는 단일 작업처럼 보여도 패킷 레벨에서는 비대칭 경로가 생깁니다. Agent Toolkit for AWS 계열은 샘플·스키마·템플릿 번들을 추가로 당겨 오는 경우가 있어 CDN 접미가 예상보다 길어집니다.

운영 관점에서는 이름을 아름답게 쪼개기보다, 라이브에서 관측한 접미를 하나의 AWS_DEV_MCP 의도 그룹에 모은 뒤 예외만 쪼개는 편이 실수가 적습니다. 예외를 늘리면 GeoIP·우선순위 글에서 말하는 덮어쓰기 사고가 늘어납니다.

macOS에서 시스템 확장·레거시 프록시 잔상이 겹치면 증상만 보고는 한참 헤맬 수 있습니다. 같은 시기에 막히면 macOS TUN·프록시 충돌 문서를 병렬로 열어두세요.

AWS_DEV_MCP 정책 그룹과 RULE-SET 순서

한 덩어리로 묶는 설계

운영 난이도 대비 효과가 좋은 형태는 AWS_DEV_MCP 그룹을 하나 두고, 라이브에서 관측한 amazonaws·aws.amazon·해당 세션에서 실제로 열린 CDN 줄을 우선 같은 정책으로 보내는 것입니다. 이때 DOMAIN-SUFFIX,.amazonaws.com처럼 지나치게 넓은 줄을 업무 트래픽까지 한 노드에 몰리게 쓰면 역효과가 나므로, 팀 허용 범위 안에서 최소 필요 접미만 남깁니다.

API와 CDN을 쪼개는 설계

AWS_MCP_API와 AWS_MCP_CDN처럼 나누면 원인 추적에는 유리하지만, 서로 다른 레이턴시 등급의 노드를 붙이면 긴 세션에서 경로가 교차하며 새로운 끊김이 생길 수 있습니다. 분리한다면 같은 리전 또는 같은 채널 집합을 운영 문서로 고정하는 편이 안전합니다.

팀에서 OpenCode CLI·Claude Code를 병행한다면 프로필 안에서 섹션 주석으로 공급자별 블록을 시각적으로 나눕니다. 그렇지 않으면 RULE-SET 자동 갱신 때 덮어쓰기 사고가 납니다.

OAuth 브라우저 탭과 IDE 토큰 교환 불일치

브라우저에서 성공 배너를 봤다고 IDE의 MCP 세션이 끝난 것은 아닙니다. 마지막 교환 패킷이 다른 출구로 나가면 런타임은 조용히 재시도 루프에 들어갑니다. 회사망에서는 HTTPS 인터셉트 없이도 정책 라벨만으로 특정 접미가 느려지거나 HTML 응답이 바뀌는 일이 있어, 사람 눈에는 단순 플러그인 버그처럼 보입니다.

따라서 OAuth·조직 SSO·콜백 호스트도 Bedrock API 블록과 같은 지연 프로필 아래 두거나, 최소한 라이브 로그에서 정책 문자열을 맞춘 뒤에야 로그인을 다시 시도하는 순서를 지키는 편이 낫습니다. 수동으로 HTTPS_PROXY를 넣었다면 자식 프로세스가 변수를 물려받지 못하는 런타임도 있으므로, 재현 순서를 로그 캡처 수준으로 남기면 이후 분석이 빨라집니다.

예시 YAML 조각과 운영 시 수정 포인트

아래는 교육용 예시입니다. 프로덕션에 그대로 복사하지 마세요. 실제 수동 줄은 라이브 연결 문자열과 공식 문서의 호스트 목록을 따라가고, RULE-SET이 수동 DOMAIN을 가리지 않는지 패치 노트처럼 확인합니다. 관측되지 않은 서드파티 접미는 주석으로 비워 두었다가 로그가 채워지면 붙입니다.

Illustrative YAML fragment

rules:
  - DOMAIN-SUFFIX,amazonaws.com,AWS_DEV_MCP
  - DOMAIN-SUFFIX,aws.amazon.com,AWS_DEV_MCP
  - DOMAIN-SUFFIX,amazon.com,AWS_DEV_MCP
  # Add CDN / console assets observed in live logs:
  # - DOMAIN-SUFFIX,cloudfront.net,AWS_DEV_MCP
  - GEOIP,KR,DIRECT
  - MATCH,DIRECT

GEOIP 줄과 최종 MATCH는 조직·회선에 맞게 조정합니다. 구독 품질·갱신 URL 자체가 병목이 되는 경우는 구독 유지 가이드와 함께 봅니다.

TUN, Meta DNS, IDE·터미널 프록시

런타임이 운영체제의 시스템 프록시 레이어를 건너뛰면 TUN으로 로컬 소켓 패스 전체를 한 라우팅 스택 아래 둘 때가 많습니다. 그다음은 DNS입니다. 외부 DoH가 빠르게 응답해 보여도 규칙 적중 순서만 틀어지면 같은 엔드포인트라도 다른 IP로 붙고 줄이 또 갈립니다. 가능하면 단말 안의 권위 경로를 한 갈래로 정리합니다.

Meta DNS에서는 fallback과 fake-ip 필터 순서가 중요합니다. 구체 패턴은 nameserver·fallback·fake-ip 문서를 적용한 뒤, 터미널 앱과 IDE를 완전히 종료했다가 다시 열어 상속을 초기화합니다.

Clash를 종료했는데도 시스템 프록시 잔상이 남으면 MCP 문제와 비슷한 착시가 납니다. 종료 후 네트워크 복구 절차를 함께 확인하세요.

검증 순서와 체크포인트

아래 순서를 플레이북처럼 고정하면 다른 앱과의 교차 영향을 줄이면서 빠르게 좁힐 수 있습니다.

  1. IDE 확장·MCP 바이너리 설치·업데이트 단계부터 연결 로그를 켭니다. 패키지 레이어에서 막히면 사용자 공간 규칙 이전에 별도 카테고리가 필요합니다.
  2. 실패 직후 라이브 목록에서 콘솔·STS·Bedrock·CDN·OAuth 줄의 정책명을 나란히 비교합니다. 하나라도 다르면 DOMAIN 줄을 보강하고 RULE-SET 상단 순서를 점검합니다.
  3. 브라우저 로그인 탭이 조직 차단 페이지로 바뀌지 않았는지 확인한 뒤 IDE를 재시작합니다.
  4. RULE-SET을 자동 갱신한 직후에만 깨졌다면 차단 카테고리가 새로운 접미를 삼켰는지 외부 diff로 확인합니다.
  5. 노드 교체로 패턴이 그대로면 순수 회선 문제인지 TLS 경고인지 TLS 로그부터 다시 읽습니다.
  6. GUI 편집은 부담스럽지만 터미널 디버깅은 가볍다고 느낀다면, 사용 중인 클라이언트가 라이브 뷰를 제대로 내주는지 클라이언트 선택 문서와 대조합니다.

자주 묻는 질문

브라우저 콘솔 로그인은 되는데 IDE의 AWS MCP만 멈춥니다.

브라우저와 MCP 런타임은 호스트 집합·프록시 상속이 다릅니다. 라이브 로그에서 IDE 프로세스가 연 amazonaws·awsapps·OIDC 관련 줄을 한 줄씩 채워 넣으세요. GeoIP나 광역 RULE에 밀리지 않았는지도 함께 봅니다.

RULE-SET에 amazonaws.com이 있다고 적혀 있는데도 Bedrock만 빈 응답입니다.

주석과 실제 갱신본·매치 순서는 다를 수 있습니다. bedrock-runtime 같은 리전별 호스트나 CloudFront 접미가 다른 정책으로 찍히면 수동 DOMAIN 보강이 필요합니다.

GitHub에서 받은 MCP 레포는 AWS와 무관해 보이는데 왜 같이 깨질까요?

릴리스 자산·문서·패키지가 GitHub·npm·CDN을 함께 두드리면 별도 호스트가 끼어듭니다. 연결 로그에서 프로세스별 접미를 나눠 보세요.

준수와 한계

⚠ 준수 알림: 현지 법령, 서비스 약관, 고용·학내 정책을 따르세요. 본 글은 합법망에서의 라우팅 위생을 다루는 기술 자료이며, 통제 회피를 돕는 내용은 포함하지 않습니다.

Zero Trust 장비에서는 사용자가 규칙을 아무리 정교하게 써도 인증 교환 단계에서 아예 거절되는 경우가 많습니다. 이때는 IT 승인 없이 우회를 시도하기보다, 정책상 불가능한 케이스로 분류하고 공식 경로를 밟는 편이 안전합니다.

맺음말

AWS MCP Server·Agent Toolkit for AWS와 Amazon Bedrock을 IDE에서 한 번에 묶을 때의 타임아웃은 단일 장애라기보다 콘솔·API·CDN·OAuth 줄이 서로 다른 출구를 타거나 DNS와 TCP 경로만 엇나가며 생기는 경우가 적지 않습니다. Clash에서 이를 줄이려면 이름 공간마다 명시적인 도메인 분류와 짧은 주기의 규칙 세트 점검 루틴이 필요하고, 협업 동기화용 목록과 MCP·에이전트용 목록을 문서적으로 분리해 두는 편이 혼선을 줄입니다. Notion·AWS 글과 주제가 비슷해 보여도, 이번 글은 로그인 스택·런타임 호스트·GitHub 릴리스 축까지 포함한 개발자 워크플로에 더 가깝습니다.

원클릭형 상용 VPN 일부는 애플리케이션별 호스트를 세밀하게 보여 주는 라이브 뷰가 부족해 증상이 길어지면 시간만 소모되는 경우가 있습니다. 반면 한 패널에서 RULE 순서·TUN·연결 로그를 함께 다룰 수 있는 Clash Meta 계열은 IDE·터미널 도구와 맞물릴 때 디버깅 루프를 짧게 만드는 데 유리합니다. Clash V.CORE는 멀티 공급자·멀티 스트림 시나리오를 전제로 프로필과 UI 신호를 정리해 두었기 때문에 AWS·Bedrock·MCP처럼 조용히 멈추는 통합 흐름과도 확인 단계가 덜 헷갈립니다.

→ Clash를 무료로 다운로드해서 이번에 정리한 AWS·Bedrock·콘솔·CDN·OAuth 줄을 라이브 연결 숫자로 다시 교차 검증해 보세요.