AWS가 MCP를 GA로 끌어올린 날 — 표준은 누구의 손을 떠났는가

Anthropic이 만든 프로토콜을 AWS가 GA로 내놓는다는 것은 무엇을 의미하는가. 표준이 제작자의 손을 떠나는 순간, 그 표준은 더 강해지는가 아니면 형해화되는가. 그리고 그 사이에 누구의 IAM 정책이 가장 먼저 깨지는가.

도입 — 102 LGTM이 말해주는 것

2026년 5월 6일, AWS는 자사의 Model Context Protocol(MCP) 서버를 일반 공급(GA)으로 전환했다고 공식 블로그에 발표했다. 사흘 뒤인 5월 9일, 일본 AWS 커뮤니티의 한 엔지니어 Syoitu가 Qiita에 “AWS MCPサーバー超進化してGAしたらしい”라는 제목의 정리 글을 올렸고, 이 글은 게시 24시간 만에 102개의 LGTM을 받았다. 일본 Qiita에서 100 LGTM은 한 해에 손에 꼽히는 수치다. 같은 주에 그보다 많은 LGTM을 받은 글은 전 카테고리를 통틀어 다섯 편이 되지 않는다.

이 숫자가 말해주는 것은 단순한 인기가 아니라, 일본 엔지니어 커뮤니티가 이 발표를 “그동안 기다려 왔다”는 사실이다. AWS는 이미 2025년 중반부터 awslabs/mcp 저장소를 통해 30개가 넘는 개별 MCP 서버를 미리보기(preview) 형태로 공개해 왔다. DynamoDB, EKS, Lambda, Bedrock Knowledge Bases, CloudFormation, Aurora 시리즈, Neptune, Redshift, Q Business — 각각이 별도 패키지였고, 각각이 별도 설치였고, 각각이 별도 인증 흐름이었다. Syoitu의 글이 정리한 새 GA 버전 aws-mcp는 이 30여 개를 단일 매니지드 엔드포인트(https://aws-mcp.us-east-1.api.aws/mcp) 뒤로 통합하고, 인증을 IAM SigV4로 일원화한다. 즉 GA가 의미하는 것은 “써도 된다”가 아니라 “이제 다른 식으로 쓸 필요가 없다”는 통보에 가깝다.

이 발표가 한 주 전 GitHub의 6일과 다른 점은, 무너진 기존 질서가 아니라 새로 굳어 가는 질서라는 데 있다. Anthropic이 2024년 11월 25일에 MCP를 발표했을 때만 해도, 이 프로토콜은 한 회사의 한 클라이언트(Claude Desktop)에서만 의미를 갖는 사양으로 보였다. 1년 6개월이 지난 지금, OpenAI는 ChatGPT에 MCP 호스트를 통합했고, Microsoft는 Visual Studio Code와 Copilot Studio에서 MCP를 1급 시민으로 다루며, Google은 Gemini의 도구 호출 백엔드를 MCP 호환 레이어 위에 얹었다. 그리고 5월 6일, 이 흐름의 마지막 결손이었던 AWS가 매니지드 엔드포인트로 합류했다. 지금부터 1년 안에 “MCP를 지원하지 않는 클라우드 콘솔”은 사실상 존재하지 않게 될 가능성이 높다.

그렇다면 질문은 자연스럽게 한 가지로 모인다. Anthropic이 이 표준을 더 이상 통제하지 못하게 됐을 때, 그 표준은 무엇이 되는가. 그리고 그 사이에 누구의 IAM 정책이 가장 먼저 깨지는가.

본문 1 — AWS MCP 서버가 실제로 무엇을 하는가

먼저 GA된 AWS MCP 서버가 구체적으로 무엇을 노출하는지부터 정확히 짚어 두자. 추상적 마케팅 문구로는 본질이 보이지 않는다.

새로운 매니지드 서버는 단일 엔드포인트(https://aws-mcp.us-east-1.api.aws/mcp) 뒤에 일곱 개의 핵심 도구(tool)를 노출한다. 이 도구들은 두 부류로 나뉜다. 한쪽은 리소스 조작 계열이고, 다른 한쪽은 지식 계열이다.

리소스 조작 계열의 핵심은 call_aws다. 이 단일 도구가 약 1만 5천 개의 AWS API 작업을 호출 가능한 함수로 노출한다. 즉, 에이전트는 ec2:DescribeInstances도, s3:PutObject도, iam:CreateRole도, bedrock:InvokeModel도 모두 같은 도구의 인자 형태로 호출한다. 두 번째 도구 run_script는 네트워크가 격리된 샌드박스에서 Python/boto3 스크립트를 실행하며, 호출자의 IAM 권한을 그대로 상속한다. 즉 단일 API 호출로 끝나지 않는 멀티스텝 자동화 — 페이지네이션, 조건 분기, 결과 필터링 — 를 에이전트가 한 번에 끝낼 수 있다. 세 번째 suggest_aws_commands는 자연어를 AWS CLI 명령으로 변환한다.

지식 계열은 search_documentation(공식 문서 교차 참조), retrieve_skill(AWS 서비스 팀이 직접 관리하는 베스트 프랙티스 SOP 회수), 그리고 리전 메타데이터를 다루는 list_regions와 get_regional_availability로 구성된다. 흥미로운 것은 retrieve_skill이다. 이 도구가 회수하는 “스킬”은 AWS의 각 서비스 팀이 자체적으로 작성·갱신하는 권장 절차서이며, 모델이 자신의 학습 데이터에 들어 있던 1년 전 정보 대신 이 SOP를 우선 참조하도록 유도한다. 모델 응답의 정확성을 모델 학습이 아니라 RAG 측 계약으로 보장하는 설계다.

인증 흐름은 결정적인 차이를 만든다. 종래의 awslabs/mcp 미리보기 서버들은 각각 로컬 프로세스로 실행되며 ~/.aws/credentials나 환경 변수에서 자격 증명을 읽었다. 새 GA 버전은 매니지드 원격 엔드포인트지만, 직접 토큰을 발급받지 않는다. 대신 mcp-proxy-for-aws라는 로컬 프록시가 클라이언트(Claude Code, Cursor, VS Code)와 원격 엔드포인트 사이에 끼어, IAM SigV4 서명을 매 요청에 직접 걸어 준다. 즉 OAuth도, 별도 API 키도, 토큰 회전 스케줄도 없다. 사용자는 그저 aws sso login --profile MyAdminProfile을 한 번 돌려 SSO 세션을 갱신하기만 하면 된다.

Syoitu의 글에 실린 등록 명령은 다음과 같다.

aws sso login --profile MyAdminProfile

claude mcp add-json aws-mcp --scope user '{
  "command": "uvx",
  "args": [
    "mcp-proxy-for-aws@latest",
    "https://aws-mcp.us-east-1.api.aws/mcp",
    "--metadata", "AWS_REGION=ap-northeast-1"
  ],
  "env": {
    "AWS_PROFILE": "MyAdminProfile",
    "AWS_REGION": "ap-northeast-1"
  }
}'

이 짧은 등록 한 줄로 클라이언트 측에서 일어나는 일은 다음과 같다. 모든 MCP 도구 호출은 stdio로 mcp-proxy-for-aws에 전달되고, 이 프록시는 SigV4로 서명한 HTTPS 요청을 매니지드 엔드포인트로 포워딩한다. 응답은 그대로 클라이언트로 돌아온다. 토큰이 클라이언트 메모리에 머무는 시간은 0초이며, 자격 증명은 SDK가 이미 관리하던 ~/.aws/sso/cache 안에 머문다. 이것이 AWS가 자랑하는 “zero credential exposure”의 실체다.

여기까지가 사실관계다. 그러나 같은 글의 댓글창에 한 일본 엔지니어가 단 짧은 코멘트가 더 본질적이다. “결국 AWS CLI를 자연어로 두른 것 아닌가(結局AWS CLIを自然言語でラップしただけでは?).” 절반은 맞다. call_aws는 본질적으로 boto3 호출의 얇은 래퍼다. 그러나 절반은 틀렸다. 진짜 변화는 도구의 개수가 아니라, 그 도구를 호출하는 주체가 바뀌었다는 데 있다.

본문 2 — MCP 표준의 1년 6개월: 한 회사의 사양에서 인터넷 표준으로

Anthropic이 MCP를 발표한 것은 2024년 11월 25일이다. 그날의 발표 자료를 다시 읽어 보면, MCP는 처음부터 “AI 애플리케이션을 위한 USB-C 포트”를 표방했다. 표준의 제작자가 처음부터 자신의 제품에 한정하지 않을 의지를 명시한 것이다. 그러나 그 의지가 실제로 실현될지는, 표준의 채택 곡선이 아니라 표준 거버넌스의 변환 곡선에서 결정된다.

채택 곡선부터 짚자. 발표 후 첫 6개월간 MCP는 Claude Desktop을 위한 사양으로만 인식됐다. 변화의 신호는 2025년 5월 OpenAI가 ChatGPT의 도구 호출 인터페이스를 MCP와 호환되는 형태로 재설계한다고 공지한 시점이다. 같은 해 9월 Microsoft가 Visual Studio Code 1.93에 MCP 클라이언트를 1급 시민으로 통합했고, 2025년 12월에는 Google이 Gemini API의 함수 호출 백엔드를 MCP 호환 레이어 위에 올린다고 발표했다. 이 시점에서 클라우드 메이저 셋(AWS·Azure·GCP) 중 두 곳이 클라이언트 측 채택을 선언했고, 서버 측에서는 이미 awslabs/mcp가 30여 개의 미리보기 서버를 풀어 둔 상태였다. 그리고 2026년 5월 6일, AWS가 매니지드 GA로 합류한 것이다.

채택 곡선만 보면 OpenAPI가 RESTful API의 사실상 표준이 되어 가던 2016～2018년 흐름과 정확히 닮아 있다. 한 회사(Swagger Inc., 이후 SmartBear)가 발표한 사양이 Linux Foundation 산하 OpenAPI Initiative로 이관되고, 이관 직후 AWS, Microsoft, Google, IBM이 일제히 OpenAPI를 자사 API Gateway의 1급 입력 포맷으로 채택하면서, OpenAPI는 “한 회사가 미는 사양”에서 “업계가 디폴트로 가정하는 포맷”으로 전이했다. MCP의 5월 6일은 그 전이 곡선의 OpenAPI 3.0 GA 시점에 해당한다.

그러나 거버넌스 곡선을 보면 그림이 다르다. MCP의 사양은 여전히 modelcontextprotocol/specification 저장소에서 관리되며, 이 저장소의 메인테이너 명단은 Anthropic 직원이 다수를 차지한다. 표준 변경은 RFC 형식의 PR로 제안되지만, 머지 권한은 Anthropic이 가진다. AWS는 클라이언트와 서버를 만들 뿐 사양 변경에 직접 영향을 미치지 않는다. 다만 AWS GA 발표 자료에서 한 줄, “AWS는 MCP의 향후 진화에 활발히 참여한다(AWS will actively participate in the future evolution of MCP)“는 문장이 끼어 있다. 이 한 줄이 의미하는 것은 향후 MCP 사양 변경의 거버넌스 압력 균형이 옮겨가기 시작했다는 신호다.

여기서 흥미로운 것은 MCP 표준이 아직 IETF나 ISO 같은 형식적 표준화 기구에 위탁되지 않았다는 점이다. OpenAPI가 Linux Foundation으로 이관된 것과 다르다. Anthropic은 MCP를 “오픈 프로토콜”이라고 부르지만, 그 오픈성은 사양 문서가 공개돼 있다는 의미일 뿐 거버넌스의 분산을 보장하지는 않는다. AWS, Microsoft, Google이 내부적으로 자신들이 필요한 확장을 사양에 반영시키지 못하면, 이들은 결국 자체 호환 레이어를 만들어 사실상의 분기를 일으킬 가능성이 있다. 2010년대 초 SAML이 OAuth 2.0의 사양 정의를 둘러싸고 일부 IDP가 자체 확장을 만들어 상호운용성을 깨뜨린 사례가 그 단적인 선례다.

Hacker News 토론에서 한 댓글이 정확히 이 지점을 짚었다. “AWS가 MCP를 GA로 내놓는다는 것은, 6개월 안에 ‘AWS MCP Extensions’가 나온다는 뜻이다. 그리고 그 확장이 사양에 머지되지 않으면, MCP는 사실상 두 개가 된다(AWS shipping MCP GA means ‘AWS MCP Extensions’ lands in 6 months. If they don’t get merged upstream, MCP de facto forks).” 이 비관에는 일리가 있다. 매니지드 엔드포인트는 그 자체로 사양 외 확장의 자연스러운 통로가 된다. AWS가 자사 IAM과 결합한 사용자 정의 메타데이터 필드를 매니지드 엔드포인트에 추가했을 때, 그 필드가 표준 사양에 들어 있지 않더라도 클라이언트는 이미 그 필드에 의존해 동작한다.

표준의 제작자가 통제력을 잃는 방식은 두 가지다. 하나는 거버넌스를 능동적으로 양도하는 것이고(OpenAPI의 길), 다른 하나는 사실상의 사용자가 사양 외 영역에서 자신만의 확장을 굳혀 가는 것이다(SAML의 길). MCP는 지금 두 길의 갈림목에 있다. AWS의 GA는 그 갈림목을 OpenAPI 쪽으로 미는 압력이 될 수도 있고, SAML 쪽으로 끄는 압력이 될 수도 있다. 다음 6개월 동안 Anthropic이 어떤 거버넌스 변화를 발표하는지가 결정적이다.

또 한 가지, 쉽게 간과되는 사실이 있다. MCP의 채택 곡선이 빨라진 가장 큰 이유는 표준 자체의 우수성이 아니라, 코딩 에이전트 생태계의 구조적 압력이다. 한 주 전 GitHub의 6일간 균열에서 본 것처럼, 코딩 에이전트의 폭증은 30배 부하를 만들어 GitHub 인프라를 흔들었다. 이 폭증의 이면에는 에이전트가 호출해야 할 도구의 폭증이 있다. AWS, GitHub, Slack, Linear, Notion, Datadog — 에이전트 한 명이 다뤄야 할 외부 시스템의 수가 빠르게 두 자릿수에 도달했고, 각 시스템마다 별도 SDK 어댑터를 작성하는 것은 더 이상 지속 가능하지 않다. MCP는 이 적응 압력에 대한 가장 단순한 답이었기에 빠르게 채택됐다. 즉, MCP의 승리는 사양의 우수성이 아니라 에이전트 생태계의 통일성에 대한 시장의 절박함이 만든 것이다.

본문 3 — 보안과 거버넌스의 다음 청구서

GA 발표 자료가 가장 길게 다룬 부분은 인증과 권한이다. AWS는 새로운 두 개의 IAM 컨텍스트 키를 도입했다. aws:ViaAWSMCPService와 aws:CalledViaAWSMCP. 전자는 호출이 매니지드 MCP 엔드포인트를 통과했음을 의미하고, 후자는 호출이 원래 AWS MCP 도구에서 발원했음을 의미한다. 이 두 키를 IAM 정책의 Condition에 걸면, 운영자는 “MCP 경로로는 RDS 백업 삭제를 금지” 같은 정책을 단 몇 줄로 작성할 수 있다. 적어도 이론상으로는 그렇다.

문제는 IAM 모델 자체가 코딩 에이전트의 호출 패턴을 위해 설계된 것이 아니라는 점이다. 종래의 IAM은 사람·서비스·역할이라는 세 종류의 주체를 가정하며, 각각의 주체가 한 세션 안에서 일관된 의도로 행동한다는 가정을 깔고 있다. 코딩 에이전트는 이 세 가지 어디에도 깔끔하게 맞지 않는다. 에이전트는 사람의 위임을 받아 동작하지만, 그 위임의 범위는 자연어로 주어진다. 에이전트는 서비스이지만, 그 행동의 패턴은 정해진 RPC가 아니라 모델의 즉흥적 판단이다. 에이전트는 역할을 가질 수 있지만, 한 세션 안에서 여러 역할을 자유롭게 옮겨 다닐 가능성이 있다.

이 불일치는 구체적인 실패 모드로 나타난다. 가장 단순한 시나리오는 권한 escalation이다. 사용자가 에이전트에게 “스테이징 환경의 EC2 인스턴스를 정리해 줘”라고 요청했다고 하자. 매니지드 MCP 서버는 사용자의 SSO 세션 토큰으로 SigV4 서명을 수행한다. 사용자가 가진 IAM 권한이 만일 ec2:*을 포함하고 있다면, 에이전트는 스테이징뿐 아니라 프로덕션 인스턴스도 종료할 수 있다. 사람 운영자라면 콘솔에서 잘못된 환경을 클릭했음을 곧바로 깨닫겠지만, 에이전트는 자연어 요청에 대한 자신의 해석에 따라 실행한다. AWS 문서가 권장하는 완화책은 “관리자 권한이 아닌 읽기 위주의 사용자 정의 IAM 역할을 쓰라(use a read-focused custom IAM role)“는 것이다. 그러나 이 권고는 곧 모순으로 부딪힌다. 에이전트가 유용해지려면 결국 쓰기 권한이 필요하다.

두 번째 시나리오는 secret 흐름이다. 매니지드 엔드포인트는 사용자 자격 증명을 직접 받지 않지만, 에이전트가 호출하는 AWS API의 응답 안에는 secret이 들어 있을 수 있다. 예를 들어 secretsmanager:GetSecretValue 호출의 응답은 평문 secret을 포함한다. 이 응답이 매니지드 MCP 엔드포인트를 거쳐 클라이언트로 돌아온다는 것은, secret이 일시적으로나마 AWS의 매니지드 인프라를 통과한다는 의미다. AWS는 “응답은 저장되지 않는다”고 명시하지만, 응답이 저장되지 않는다는 것과 응답이 어디에서도 로깅되지 않는다는 것은 다르다. CloudTrail에는 호출이 기록되고, 매니지드 서비스의 운영 로그에는 메타데이터가 남는다. 이 메타데이터가 향후 어떤 형태의 침해 진입점이 될지는 아직 미지의 영역이다.

세 번째 시나리오는 MCP 자체의 audit log 부재다. 현행 MCP 사양에는 도구 호출의 결과를 누가 무엇을 위해 받았는지를 기록하는 표준화된 audit log 형식이 없다. AWS는 CloudTrail로 호출 측을 기록하지만, 모델이 그 응답을 어떻게 해석했는지, 어떤 후속 호출로 이어졌는지의 인과 사슬은 모델 측 클라이언트에만 남는다. Claude Code의 세션 로그, Cursor의 세션 캐시, VS Code의 확장 로그 — 각 클라이언트마다 다른 형식, 다른 보존 기간, 다른 접근 통제를 가진다. 사고가 일어났을 때 운영팀이 호출 측 CloudTrail과 응답 측 클라이언트 로그를 결합해 인과 사슬을 복원하는 일은, 현실적으로 거의 불가능에 가깝다.

GA 시점에서 AWS가 약속한 것 — IAM SigV4 통합, 새로운 Condition 키, CloudTrail 기록 — 은 이 세 가지 시나리오 중 첫 번째를 부분적으로 다룰 뿐, 두 번째와 세 번째는 여전히 미해결로 남아 있다. 이것이 MCP가 OpenAPI의 길을 갈지 SAML의 길을 갈지를 결정할 또 하나의 변수다. 인증·권한·audit이라는 보안 3축의 표준화가 사양 차원에서 이뤄지지 않으면, 각 클라우드 벤더는 자체 확장으로 이 공백을 메울 수밖에 없고, 그 순간 사실상의 분기가 시작된다.

마지막으로 한 가지를 짚자. 코딩 에이전트가 클라우드 API를 직접 호출하는 패턴이 굳어지면, 운영팀의 일은 “사람의 행동을 감사하는 것”에서 “에이전트의 해석을 감사하는 것”으로 옮겨간다. 이는 단순한 도구의 변화가 아니라 직무의 변화다. SRE는 이미 “SLO를 정의하는 사람”에서 “에이전트가 제안한 SLO 변경을 승인하는 사람”으로 변하기 시작했고, 보안 엔지니어는 “정책을 작성하는 사람”에서 “에이전트가 정책 위반을 시도했을 때 그것이 의도된 위반인지 잘못된 해석인지 판별하는 사람”으로 변할 가능성이 높다. AWS의 MCP GA는 이 직무 변화의 가속 페달이다.

결론 — 표준이 떠난 자리에 남는 것

처음의 질문으로 돌아가자. Anthropic이 만든 프로토콜을 AWS가 GA로 내놓는다는 것은 무엇을 의미하는가. 표준이 제작자의 손을 떠나는 순간, 그 표준은 더 강해지는가 아니면 형해화되는가.

대답은 둘 다다. AWS의 GA는 MCP를 사실상 클라우드 표준으로 굳혔다. 클라우드 메이저 셋 중 둘이 매니지드 채널로 합류한 이상, 남은 한 곳(Google)이 같은 길을 따라가는 것은 시간 문제다. 이 의미에서 MCP는 한 회사의 사양에서 업계의 디폴트로 전이를 마쳤다. 동시에, 그 전이는 거버넌스의 분산을 동반하지 않은 채로 일어났다. AWS는 매니지드 엔드포인트를 통해 사양 외 확장을 자연스럽게 추가할 수 있고, 그 확장이 표준에 역류하지 않는다면 사실상의 분기는 그 확장의 첫 사용자가 클라이언트를 업데이트한 순간부터 시작된다.

102 LGTM이 말해 주는 것은 이 양면을 일본 엔지니어 커뮤니티가 이미 직관적으로 이해했다는 사실이다. 그들은 awslabs/mcp의 30개 미리보기 서버를 일일이 설치하며 각각의 인증 흐름을 별도로 관리해 본 경험이 있고, 그 고통을 단일 매니지드 엔드포인트가 해결한다는 점에서 GA를 환영했다. 동시에 같은 커뮤니티의 다른 한쪽은 “결국 AWS CLI를 자연어로 두른 것 아닌가”라는 회의적 코멘트를 남겼다. 이 두 반응은 모순이 아니라, 같은 사실의 양면이다. 매니지드 엔드포인트는 운영 부담을 줄이지만, 그것은 운영 부담의 일부를 AWS의 통제 아래로 옮긴다는 뜻이기도 하다.

다음 6개월의 관전 포인트는 세 가지다. 첫째, Anthropic이 MCP의 거버넌스를 어떤 형태로 분산할 것인가. Linux Foundation 산하 산업 컨소시엄이 형성되면 OpenAPI의 길이 굳어지고, 그 발걸음이 늦어지면 SAML의 길이 가까워진다. 둘째, AWS가 매니지드 엔드포인트에 어떤 사양 외 확장을 추가할 것인가. 그 확장이 표준 RFC로 역류하면 분기는 일어나지 않지만, 그렇지 않으면 클라이언트 호환성의 첫 균열이 시작된다. 셋째, 보안 사고가 어떤 형태로 처음 터질 것인가. 권한 escalation, secret 누출, audit 사슬 단절 — 어느 하나가 헤드라인에 오르는 순간, MCP의 보안 모델은 사양 차원에서의 재설계 압력을 받는다.

표준이 떠난 자리에는 두 가지가 남는다. 하나는 그 표준에 의존해 만들어진 인프라이고, 다른 하나는 그 인프라가 만들어낸 새로운 직무다. 5월 6일 이전의 AWS 운영자는 “AWS API를 누가 호출했는지”를 감사했다. 5월 6일 이후의 AWS 운영자는 “AWS API를 호출한 에이전트가 그 호출을 어떤 자연어 요청에서 유도했는지”를 감사하기 시작한다. 이 감사 대상의 변화는 표준의 통제권이 누구에게 있는가보다 훨씬 더 깊은 곳에서 우리 일을 바꾼다.

그래서 마지막 질문은 이렇게 바뀐다. 당신이 운영하는 IAM 정책은, 사람을 위해 설계됐는가, 아니면 에이전트를 위해 다시 설계할 준비가 됐는가.

출처: