1만5천 API를 묶은 AWS MCP, 클라우드 에이전트의 새 경계

AI 요약

• 무슨 일: AWS가 AWS MCP Server를 GA로 전환하고 Agent Toolkit for AWS에 묶었습니다.
  • call_aws, 문서 검색, skill 검색, sandboxed Python 실행을 단일 MCP 표면으로 제공합니다.
• 숫자: 300개 이상 AWS 서비스와 1만5천 개 이상 API action을 에이전트가 호출할 수 있는 구조입니다.
• 의미: 코딩 에이전트의 클라우드 접근이 로컬 CLI 편의 기능에서 IAM, CloudWatch, CloudTrail이 붙은 운영 경계로 이동합니다.
• 주의점: MCP는 곧 새 인프라 공격면입니다. 권한 축소, 감사 로그, 승인 절차가 제품 선택만큼 중요합니다.

AWS가 2026년 5월 6일 AWS MCP Server의 일반 제공을 발표했습니다. 겉으로 보면 "AWS용 MCP 서버가 GA가 됐다"는 제품 뉴스입니다. 하지만 개발자 입장에서 더 중요한 변화는 따로 있습니다. 이제 코딩 에이전트가 클라우드 계정 안에서 무엇을 볼 수 있고, 무엇을 실행할 수 있고, 어떤 로그로 남는지를 클라우드 사업자가 정식 운영 모델로 다루기 시작했다는 점입니다.

이 발표는 Agent Toolkit for AWS라는 더 큰 묶음 안에 들어갑니다. Toolkit은 관리형 AWS MCP Server, agent skills, agent plugins를 한데 묶습니다. AWS는 이 도구를 Claude Code, Codex, Kiro, Cursor 같은 MCP 호환 코딩 에이전트와 연결할 수 있다고 설명합니다. GitHub 저장소도 공개되어 있고, aws-core, aws-agents, aws-data-analytics 같은 플러그인 묶음이 나뉘어 있습니다.

중요한 질문은 "에이전트가 AWS를 더 잘 쓰게 됐다"가 아닙니다. 이미 많은 개발자는 Claude Code, Codex, Cursor, Gemini CLI 같은 도구에 aws CLI를 열어 주고 있습니다. 작은 실험에서는 그것만으로 충분합니다. 문제는 그 다음입니다. 회사 계정, 여러 리전, 비용 제한, 개인정보, 프로덕션 IAM role이 걸리면 에이전트의 AWS 호출은 더 이상 편의 기능이 아니라 운영 위험입니다. AWS의 이번 발표는 바로 그 위험을 제품 표면으로 끌어올립니다.

AWS가 문제로 지목한 것은 모델 지식의 낡음입니다

AWS News Blog의 설명은 꽤 직접적입니다. 코딩 에이전트가 AWS를 깊게 다룰 때 최신 문서를 보지 못하면 몇 가지 실패가 반복됩니다. 모델의 훈련 시점 이후에 나온 서비스나 기능을 모릅니다. AWS는 예로 Amazon S3 Vectors, Amazon Aurora DSQL, Amazon Bedrock AgentCore를 듭니다. 인프라를 만들라고 하면 AWS CDK나 CloudFormation보다 AWS CLI를 바로 쓰려는 경향도 있다고 말합니다. 그리고 IAM 정책을 만들 때 필요 이상으로 넓은 권한을 생성하기 쉽다고 지적합니다.

이 문제는 개발자가 AI 코딩 도구에서 자주 보는 실패와 비슷합니다. 모델은 그럴듯한 코드를 만들지만, 오늘의 API shape를 모르거나 방금 바뀐 provider 규칙을 반영하지 못합니다. 일반 애플리케이션 코드에서는 테스트와 타입 오류로 어느 정도 걸러집니다. 클라우드 인프라에서는 실패 양상이 다릅니다. 틀린 API 이름, 누락된 리전 조건, 과한 IAM action, 잘못된 리소스 정책이 실제 계정에 들어갈 수 있습니다.

AWS MCP Server는 이 간격을 "최신 문서 검색"과 "통제된 API 실행"으로 줄이려 합니다. 공식 문서에 따르면 문서 검색과 service information retrieval은 인증 없이 사용할 수 있습니다. 반면 AWS API 호출, sandboxed Python script 실행, curated skill 사용은 기존 IAM credentials를 통해 인증합니다. 단순 RAG 문서 검색 도구와 운영 도구 사이에 경계를 둔 셈입니다.

1만5천 API를 한 도구로 묶는다는 말의 무게

AWS가 강조한 숫자는 큽니다. AWS MCP Server의 call_aws 도구는 300개 이상 AWS 서비스와 1만5천 개 이상 API action을 다룰 수 있다고 설명됩니다. 이 숫자는 멋진 기능 소개이기도 하지만, 동시에 위험의 크기를 보여줍니다. 에이전트에게 클라우드 API 표면을 열어 준다는 것은 S3 버킷 목록 조회부터 IAM policy 변경, CloudFormation stack 조작, 비용 관련 조회, 로그 분석까지 같은 대화 안으로 들어온다는 뜻입니다.

그래서 발표에서 더 눈여겨볼 부분은 call_aws 자체보다 주변 장치입니다. 공식 문서의 tool 목록은 aws___search_documentation, aws___read_documentation, aws___retrieve_skill, aws___call_aws, aws___suggest_aws_commands, aws___run_script, aws___get_presigned_url, aws___get_tasks 등을 보여줍니다. 지식 도구와 실행 도구가 같은 서버 안에 있지만 역할은 다릅니다. 스킬은 workflow와 best practice를 제공하고, knowledge tool은 최신 정보를 가져오며, API tool은 인증과 권한을 거쳐 실제 작업을 실행합니다.

이 구조는 최근 에이전트 플랫폼들이 공통으로 가는 방향과 닮았습니다. "모델에게 모든 도구를 한꺼번에 보여 주기"보다 "작은 도구 표면, 필요할 때 불러오는 스킬, 검증된 절차, 감사 가능한 실행" 쪽입니다. AWS도 Agent SOPs에서 Skills로 전환한다고 설명합니다. 스킬은 AWS service team이 유지하며, 에이전트가 자주 틀리는 작업에 대해 curated guidance와 best practice를 제공합니다. 도구 목록을 짧고 예측 가능하게 유지해 hallucination을 줄인다는 설명도 붙어 있습니다.

로컬 CLI에서 감사 가능한 호출로

AWS 발표에서 가장 실무적인 부분은 IAM context key입니다. 제품 페이지와 GitHub README는 aws:CalledViaAWSMCP를 예로 듭니다. 이 condition key를 사용하면 같은 underlying IAM role을 쓰더라도 사람의 직접 호출과 MCP 서버를 통한 에이전트 호출을 구분하는 정책을 작성할 수 있습니다. 예를 들어 사람은 mutating operation을 수행할 수 있지만, MCP를 통한 호출은 read-only로 제한하는 방식입니다.

이것은 작은 차이가 아닙니다. 지금까지 많은 에이전트 도구는 사용자의 로컬 쉘을 빌려 AWS CLI를 실행했습니다. 그 경우 CloudTrail에는 API 호출이 남더라도 "이 호출이 사람이 명령한 것인지, 에이전트가 제안하고 실행한 것인지"를 운영적으로 나누기 어렵습니다. 로컬 터미널 로그와 채팅 세션 기록을 따로 보관해야 하고, 정책은 사용자의 권한 전체에 걸립니다.

AWS MCP Server는 이 호출을 별도의 관리형 표면으로 통과시키려 합니다. CloudWatch metric은 AWS-MCP namespace로 분리되고, CloudTrail은 API call record를 남깁니다. 기업 환경에서 의미 있는 것은 바로 이 분리입니다. 보안팀과 플랫폼팀은 에이전트 호출량, 실패율, 어떤 API가 많이 쓰이는지, 어떤 role에서 MCP를 통한 변경 시도가 있었는지를 볼 수 있어야 합니다. 그래야 "에이전트 사용을 금지할 것인가"와 "어떤 경계 안에서 허용할 것인가" 사이의 현실적인 선택지가 생깁니다.

run_script는 편의 기능이면서 새로운 경계입니다

또 하나 주목할 기능은 run_script입니다. AWS는 에이전트가 짧은 Python script를 작성해 서버 측 sandbox에서 실행할 수 있다고 설명합니다. 이 sandbox는 사용자의 IAM 권한을 상속하지만 로컬 파일시스템이나 네트워크 접근은 없다고 합니다. 목적은 분명합니다. 에이전트가 API를 하나씩 부르며 컨텍스트와 시간을 쓰는 대신, 여러 API call을 묶어 결과를 필터링하고 계산한 뒤 한 번에 반환하게 하는 것입니다.

예를 들어 여러 계정 또는 여러 리전의 리소스 상태를 조회하고, tag 누락을 찾고, 비용 관련 metric을 합산하고, 실패한 CloudFormation stack event를 정리하는 작업을 생각해 볼 수 있습니다. 대화형 에이전트가 각 API 응답을 모두 모델 컨텍스트로 가져오면 토큰과 시간이 빠르게 늘어납니다. Python script가 중간 집계를 담당하면 모델은 최종 요약과 다음 의사결정에 집중할 수 있습니다.

하지만 이 기능은 "서버 측 코드 실행"이라는 말 그대로 새로운 경계이기도 합니다. AWS가 네트워크와 로컬 파일시스템 접근을 막는다고 해도, script는 IAM 권한을 가진 상태로 AWS API를 호출합니다. 따라서 플랫폼팀은 어떤 role이 run_script를 사용할 수 있는지, 어떤 API action 조합이 가능한지, 실패한 script와 long-running task가 어떻게 기록되는지 봐야 합니다. 에이전트가 단순히 정보를 조회하는 단계와 실제 환경을 바꾸는 단계 사이에 승인 절차가 있어야 합니다.

Agent Toolkit은 AWS Labs 실험의 제도권 편입입니다

GitHub의 Agent Toolkit for AWS 저장소는 이 발표를 AWS Labs 흐름의 후속으로 설명합니다. AWS는 2025년부터 AWS Labs를 통해 MCP server, skill, plugin을 공개해 왔고, 이번 Toolkit은 그 실험에서 얻은 구성요소를 AWS-supported 형태로 옮기는 작업입니다. Labs 자산은 계속 동작하고 기여도 받지만, 시간이 지나며 좋은 요소를 Toolkit으로 전환하겠다는 설명이 붙어 있습니다.

이 대목은 다른 빅테크의 움직임과도 연결됩니다. Anthropic은 MCP를 만든 뒤 Stainless를 인수하며 SDK, CLI, MCP server 생성 배관을 강화했습니다. Google은 Gemini API managed agents와 Android Agent Skills를 통해 에이전트가 도메인 규칙을 읽는 방식을 제품화하고 있습니다. GitHub는 Copilot CLI, cloud agent, Copilot app, review feedback handoff를 통해 코딩 에이전트를 GitHub 작업 표면 안으로 끌어들이고 있습니다.

AWS의 차별점은 모델이나 IDE가 아니라 클라우드 실행 계층입니다. 에이전트가 결국 배포, 로그, IAM, 데이터 파이프라인, 비용, VPC, 컨테이너, 서버리스 리소스를 건드리려면 클라우드 provider의 정책과 감사 체계 안으로 들어와야 합니다. Agent Toolkit은 바로 그 접점에 있습니다. MCP를 "agent가 도구를 부르는 표준"으로만 보지 않고, "agent가 클라우드 권한을 행사하는 통제면"으로 보는 발표입니다.

커뮤니티의 온도는 기대보다 경계에 가깝습니다

이번 취재에서 Hacker News와 GeekNews의 최신 목록을 같이 봤습니다. HN 메인에는 DeepSeek Reasonix, LLM agent fragility, AI chip memory cost처럼 비용과 안정성 관련 주제가 강하게 올라와 있었습니다. GeekNews에는 Zero, agentmemory, Herdr 등 에이전트 네이티브 개발 도구와 AI 보조 코딩 실무 글이 보였습니다. AWS Agent Toolkit 자체가 폭발적으로 논의되는 모습은 아니었습니다.

오히려 주변 반응은 "MCP와 sandbox가 새로운 인프라 공격면이 되는 것 아니냐"에 가깝습니다. r/sysadmin의 최근 스레드는 MCP server와 agent sandbox를 2026년 인프라 질문으로 보며 secret, API key, database credential이 agent context로 흘러가는 상황을 걱정했습니다. ByteVanguard의 MCP 보안 글도 MCP server를 단순 AI 설정 파일이 아니라 web application, API gateway, internal service와 같은 보안 범주로 봐야 한다고 주장합니다.

이 반응은 AWS 발표를 더 흥미롭게 만듭니다. AWS가 CloudWatch, CloudTrail, IAM context key를 전면에 세운 것은 우연이 아닙니다. 시장이 이미 "에이전트에게 도구를 연결하자" 단계를 지나 "그 도구가 프로덕션 권한을 가질 때 누가 책임지는가"로 넘어갔기 때문입니다.

개발팀에게 달라지는 실무 질문

개발팀이 당장 물어야 할 질문은 세 가지입니다. 첫째, 에이전트가 AWS를 다룰 때 로컬 CLI를 직접 열어 줄 것인지, MCP Server 같은 관리형 경계를 통과시킬 것인지입니다. 개인 실험에서는 전자가 빠릅니다. 팀 단위 운영에서는 후자가 더 설명 가능할 수 있습니다.

둘째, 에이전트용 IAM 권한을 사람 권한과 다르게 설계할 것인지입니다. aws:CalledViaAWSMCP 같은 condition key가 의미 있으려면 조직의 IAM policy와 SCP가 이를 반영해야 합니다. 단순히 "우리 개발자는 이미 admin이니 에이전트도 같은 권한이면 된다"는 접근은 에이전트의 반복 실행, 오해, prompt injection 가능성을 과소평가합니다.

셋째, skill과 문서 검색을 조직 표준과 어떻게 맞출지입니다. AWS skill은 유용한 출발점이지만, 모든 회사의 네트워크, tagging, encryption, approval, cost policy가 같지는 않습니다. 에이전트가 공식 best practice를 따르는 것과 회사의 내부 guardrail을 따르는 것은 다를 수 있습니다. 따라서 AWS Toolkit을 쓰더라도 사내 규칙 파일, repository-level instruction, preflight check, CI policy가 함께 필요합니다.

결론: MCP는 연결 표준에서 운영 표준으로 이동 중입니다

AWS MCP Server GA는 단일 제품 발표 이상입니다. MCP가 "모델에게 도구를 붙이는 편한 방법"에서 "에이전트가 실제 인프라 권한을 행사하는 표준 경로"로 이동하고 있음을 보여줍니다. 여기서 경쟁력은 도구 수만으로 결정되지 않습니다. 오히려 어떤 도구를 적게 노출할지, 언제 skill을 불러올지, 권한을 어떻게 좁힐지, 로그를 어떻게 남길지, 실패를 어떻게 되돌릴지가 더 중요해집니다.

AWS는 1만5천 개 이상 API action이라는 거대한 표면을 하나의 MCP 서버로 묶었습니다. 동시에 IAM condition key, CloudWatch metric, CloudTrail audit record를 붙였습니다. 이 조합은 앞으로 다른 클라우드와 에이전트 플랫폼이 피하기 어려운 기준이 될 가능성이 큽니다. 코딩 에이전트가 진짜 업무를 맡는다면, 그 에이전트도 결국 사람과 마찬가지로 권한, 로그, 책임의 체계 안에 들어와야 하기 때문입니다.

그래서 이번 뉴스의 핵심은 "AWS가 MCP를 지원한다"가 아닙니다. 클라우드 에이전트의 다음 경쟁축이 모델 성능이나 IDE UX만이 아니라 운영 통제와 감사 가능성으로 옮겨간다는 신호입니다. 개발자가 볼 질문도 바뀝니다. 이제는 "이 에이전트가 AWS를 호출할 수 있나"보다 "그 호출이 어떤 경계 안에서, 어떤 기록으로, 어떤 승인 뒤에 일어나는가"를 먼저 물어야 합니다.