AWS Agent Toolkit: 클라우드 권한을 과도하게 허용하지 않고 코드 에이전트와 MCP를 사용하는 방법

AWS Agent Toolkit은 최근의 소식을 지속 가능한 결정으로 전환합니다. 즉, 코드 에이전트에게 마스터 키를 넘겨주지 않으면서 어떻게 클라우드 접근 권한을 부여할 것인가에 대한 문제입니다.

2026년 5월 6일, AWS는 AWS MCP Server의 일반 가용성(General Availability)을 발표하고 이를 Agent Toolkit for AWS 내에 배치했습니다. 이 뉴스는 단순히 또 다른 MCP 서버가 존재한다는 것만을 의미하지 않습니다. 기술적인 신호는 대형 클라우드 제공업체가 현재의 문서, 인증된 호출(Authenticated calls), 스킬(Skills), 그리고 감사 제어(Audit controls)를 코드 에이전트를 위해 특별히 설계된 계층으로 패키징하려고 시도하고 있다는 점입니다.

정말로 중요한 뉴스

이것은 논의의 판도를 바꿉니다. 지금까지 많은 팀은 로컬 CLI, 광범위한 자격 증명(Credentials), 문서 스니펫(Snippets), 개별 스크립트 등을 사용하여 수동으로 에이전트를 AWS에 연결해 왔으며, 모델이 이상한 행동을 하지 않을 것이라는 막연한 신뢰에 의존해 왔습니다. AWS는 더 좁은 인터페이스를 제안합니다. 즉, 제한된 도구, IAM, CloudTrail, CloudWatch, 실시간으로 검색된 문서, 그리고 멀티 API 작업을 위한 격리된 Python 실행 환경을 제공하는 것입니다.

지속 가능한 가이드로서, 질문은 오늘 이것을 설치해야 하는가가 아닙니다. 질문은 Claude Code, Codex, Cursor, Kiro 또는 기타 MCP 클라이언트가 실제 인프라에 대해 추론하도록 허용하기 전에 어떤 최소한의 아키텍처가 필요한가 하는 것입니다.

AWS Agent Toolkit 포함 사항

AWS의 공식 리포지토리(Repository)는 이 툴킷을 AI 에이전트가 AWS에서 애플리케이션을 구축, 배포 및 관리할 수 있도록 돕는 MCP 서버, 스킬(Skills), 플러그인(Plugins) 및 규칙 파일(Rules files)의 집합으로 설명합니다. 플러그인은 MCP Server 설정과 구체적인 도구를 위한 스킬을 패키징합니다. 검토된 문서 시점을 기준으로, AWS는 Claude Code 및 Codex를 위한 플러그인과 MCP와 호환되는 다른 에이전트들을 위한 직접 설정을 언급하고 있습니다.

가장 중요한 부분은 관리형 AWS MCP Server입니다.

AWS는 aws___search_documentation, aws___read_documentation, aws___retrieve_skill, aws___recommend와 같은 지식 도구(knowledge tools), aws___call_aws, aws___suggest_aws_commands와 같은 API 도구(API tools), 그리고 AWS 접근 권한이 있는 샌드박스(sandbox) 환경에서 Python을 실행하기 위한 aws___run_script 도구를 제공합니다.

이러한 설계는 두 가지 고전적인 문제를 해결하려는 시도입니다. 첫째, 모델은 학습 데이터 날짜 이후에 어떤 새로운 API, 리전(region) 또는 서비스가 존재하는지 알지 못합니다. 둘째, 에이전트에게 AWS CLI와 광범위한 자격 증명(credentials)이 포함된 로컬 셸(shell)을 부여하는 것은 감사(audit)하기 어려운 단일 권한에 너무 많은 기능을 혼합하는 결과를 초래합니다.

MCP 연결만으로는 충분하지 않은 이유

MCP는 에이전트가 도구를 발견하고 호출하는 방식을 표준화하지만, 실제 운영 환경(production)에서의 사용이 안전하다는 것을 보장하지는 않습니다. MCP를 활용한 운영 패턴에 관한 최근 논문은 세 가지 빈번한 공백을 요약합니다: 신원 전파(identity propagation), 도구를 위한 적응형 예산(adaptive budgets), 그리고 구조화된 오류 의미론(structured error semantics)입니다. 이를 클라우드 관점으로 번역하면, 누가 각 작업을 요청했는지, 호출 체인이 얼마나 많은 비용을 지출하거나 시간을 소요할 수 있는지, 그리고 API가 실패했을 때 에이전트가 어떻게 복구되는지를 알아야 한다는 의미입니다.

AWS는 IAM 컨텍스트 키(context keys), CloudTrail, 그리고 CloudWatch의 메트릭(metrics)을 통해 이러한 격차의 일부를 메워줍니다. 이를 통해 인간의 작업과 MCP를 통해 시작된 작업을 분리하고 에이전트를 위한 특정 정책을 작성할 수 있습니다. 예를 들어, 사용자는 자신의 인간 역할(human role)에서 광범위한 권한을 가질 수 있지만, MCP 경로는 읽기 전용이나 가변적 작업(mutable actions)의 일부 집합으로 제한될 수 있습니다.

실질적인 결론은 불편하지만 반드시 필요합니다. 서버를 설치하는 것은 쉬운 부분입니다. 진짜 중요한 작업은 정책(policies), 범위(scopes), 로그(logs), 예산(budgets), 프로젝트 프롬프트(prompts) 검토 및 가역성(reversibility) 테스트에 있습니다.

멘탈 모델: 세 가지 권한 경로 (three lanes of permission)

클라우드를 과도하게 개방하지 않으면서 이러한 유형의 툴킷(toolkit)을 도입하려면 세 가지 경로를 분리해야 합니다. 문서(documentation) 경로는 자격 증명(credentials)을 필요로 하지 않으며, 에이전트가 가이드, API, 지역적 가용성(regional availability) 및 모범 사례(best practices)를 검색할 수 있도록 허용합니다. 이 경로는 환각(hallucinations)과 오래된 코드를 줄여주기 때문에 거의 항상 허용되어야 합니다.

검사(inspection) 경로는 자격 증명을 사용하지만, 상태를 읽는 용도로만 사용합니다: 리소스 목록화(listing resources), 구성(configuration) 검토, 메트릭(metrics) 조회, 지역(regions) 유효성 검사 또는 예상 비용 분석 등이 이에 해당합니다. 여기서 에이전트가 내부 정보를 보게 되므로 위험도가 높아지지만, 아직 인프라를 변경하지는 않습니다. 이는 실제 파일럿(pilot) 프로젝트를 위한 가장 좋은 시작점입니다.

변이(mutation) 경로는 리소스를 생성, 수정 또는 삭제합니다. 이 경로는 비운영(non-production) 환경, 명시적인 정책(policies), 인간의 승인(human approval) 및 비용 제한(cost limits)과 함께 나중에 도입되어야 합니다. 만약 첫 번째 파일럿이 이미 운영 환경에 대해 변이적인 call_aws를 허용한다면, 문제는 MCP가 아니라 거버넌스(governance)입니다.

run_script는 로컬 셸(shell)이 아닙니다

run_script 도구는 에이전트가 여러 AWS 호출을 그룹화하고, 결과를 필터링하며, 단 한 번의 요청으로 응답을 계산할 수 있게 해주기 때문에 가장 흥미로운 요소 중 하나입니다. AWS는 이 도구가 샌드박스(sandbox) 내에서 서버 측(server-side)에서 실행되며, IAM 권한을 상속받고, 일반적인 네트워크 액세스나 로컬 파일 시스템에 대한 액세스 권한은 없다고 설명합니다.

그렇다고 해서 이 도구가 무해하다는 뜻은 아닙니다. 읽기 권한이 있는 스크립트는 민감한 인벤토리(inventory)를 열거할 수 있습니다. 쓰기 권한이 있는 스크립트는 많은 리소스를 빠르게 변경할 수 있습니다. 하지만 완전한 로컬 터미널(terminal)을 제공하는 것보다는 설계 측면에서 개선된 방식입니다. 공격 표면(surface)을 줄이고, 작업을 더 관찰 가능(observable)하게 만들며, 에이전트가 AWS, 로컬 파일 시스템, 저장소의 비밀(secrets), 그리고 임의의 명령어를 동일한 공간에서 혼합하는 것을 방지할 수 있기 때문입니다.

저의 규칙이라면, 재고, 기본 컴플라이언스 (compliance), 지역별 비교, 예상 비용 또는 구성 체크와 같은 읽기 전용 집계 쿼리를 위해 우선 run_script를 허용할 것입니다. 변형 (mutations) 작업의 경우에는 인프라 PR (Pull Request), 검토 가능한 플랜, 그리고 별도의 배포를 요구할 것입니다.

비용과 컨텍스트

AWS는 툴킷이 도구 목록을 짧게 유지하고 필요할 때만 스킬 (skills)/문서 (documentation)를 검색하기 때문에 토큰 (tokens) 사용량을 줄일 수 있다고 강조합니다. 이는 중요한 지점입니다. 40개의 범용 도구와 프롬프트 (prompt)에 붙여넣은 문서를 가진 에이전트는 비용이 더 많이 들 뿐만 아니라, 잘못된 선택을 할 가능성도 더 높습니다.

확인해야 할 사항

실시간 최신 문서 또한 응답의 품질을 변화시킵니다. GA (General Availability) 발표에서 AWS는 S3 Vectors와 같은 최신 서비스의 예를 들어, 컷오프 (cutoff) 시점이 이전인 모델이 최신 문서를 조회하지 않으면 오래된 옵션으로 응답할 수 있음을 보여주었습니다. 클라우드 팀의 경우, 이러한 차이는 새로운 API, 지역 서비스, CDK constructs 및 가격 정책 변경 사항에서 확연히 드러납니다.

그럼에도 불구하고, 토큰 절감이 실제 클라우드 비용을 가려서는 안 됩니다. 에이전트가 리소스를 생성할 수 있다면, 중요한 비용은 모델 제공업체가 아닌 AWS Billing (결제)에서 발생할 수 있습니다. 따라서 배포 작업은 실행 전에 추정치, 태그 (tags), 정리 (teardown) 및 제한 사항을 요청해야 합니다.

공급망 리스크 (Supply chain risk)

에이전트를 위한 도구 생태계는 빠르게 성장하고 있습니다. 177,000개의 MCP 도구에 대한 한 연구에 따르면, 시간이 지남에 따라 액션 (action) 도구의 비중이 커졌으며, 도구 복제 (tool cloning)에 관한 또 다른 논문은 MCP 및 스킬 (Skills) 리포지토리에서 높은 중복성을 발견했습니다. 이는 직접적인 함의를 갖습니다. 단순히 통합(integrations) 개수만 세는 것으로는 부족하며, 출처, 유지 관리, 권한 및 취약한 템플릿과의 유사성을 검토해야 합니다.

이러한 맥락에서 AWS가 공식적이고 지원되는 툴킷을 공개하는 것은 출처 리스크의 일부를 줄여주지만, 운영 리스크를 완전히 제거하지는 않습니다.

여전히 버전, 로컬 프록시 (local proxy), 클라이언트 설정, 자격 증명 (credentials), IAM 스코프 (scopes) 및 프로젝트 규칙을 검토해야 합니다.

합리적인 결정은 '오직 공식적인 것만' 혹은 '어떤 MCP든 상관없다'가 아닙니다. 명확한 소유자(owners)와 정기적인 검토가 동반된 작은 허용 목록 (allowlist)을 운영하는 것입니다. 클라우드에 접근할 수 있는 도구는 에디터의 장식적인 확장 기능이 아니라, 인프라 종속성 (infrastructure dependencies)으로 취급해야 합니다.

파일럿 체크리스트

• 민감한 데이터가 없는 샌드박스 (sandbox) 환경 또는 AWS 개발 계정으로 시작하세요.
• 먼저 문서화 (documentation) 및 스킬 (skills)을 활성화하고, 변경 가능한 (mutable) 작업은 뒤로 미루세요.
• 읽기 전용 권한을 가진 MCP 경로 전용 IAM 정책을 생성하세요.
• 인간의 작업과 에이전트의 작업을 분리하기 위해 컨텍스트 키 (context keys) 또는 그에 상응하는 조건을 사용하세요.
• 에이전트 워크플로우에 의해 생성된 리소스에 태그를 지정하고 정리 (teardown) 루틴을 정의하세요.
• 파일럿 세션이 끝날 때마다 CloudTrail 및 CloudWatch 메트릭을 검토하세요.
• 프롬프트 (prompts), 로그 (logs), 에이전트 규칙 파일 (rules files)에 운영 환경의 비밀 값 (production secrets)이 포함되지 않도록 금지하세요.
• 어떤 명령어나 도구가 명시적인 인간의 확인을 필요로 하는지 정의하세요.
• 비용을 측정하세요: 토큰 (tokens), 투입된 인간의 시간, 생성된 AWS 리소스 및 승인된 변경 사항.
• 실제 변경을 허용하기 전에 롤백 (rollback) 절차를 문서화하세요.

합리적인 워크플로우

보수적인 워크플로우는 에이전트에게 현재 문서와 기존 인프라 읽기를 사용하여 아키텍처를 조사하도록 요청하는 것입니다. 그 후 에이전트는 서비스, 권한, 예상 비용, 리스크, CDK 또는 CloudFormation 변경 사항 및 복구 전략을 포함한 텍스트 기반의 계획을 제안해야 합니다.

구현 사항은 다른 인프라 변경 사항과 마찬가지로 Git에 존재해야 합니다. 에이전트는 CDK, Terraform 또는 CloudFormation을 생성할 수 있지만, 배포는 반드시 검토, 테스트, 스캐닝 (scanning) 및 CI/CD를 거쳐야 합니다. 에이전트가 API를 직접 실행하는 경우, 이는 작고 되돌릴 수 있으며 비운영 환경 내에서 수행되는 작업에 한정되어야 합니다.

목표는 에이전트가 스스로 더 빠르게 배포하는 것이 아닙니다. 목표는 더 적은 구식 문서, 더 적은 과도한 IAM 권한, 그리고 리뷰어를 위한 더 많은 근거를 바탕으로 더 정보가 풍부한 제안에 도달하는 것입니다.

결론

AWS Agent Toolkit과 AWS MCP Server가 중요한 이유는 에이전트를 위한 클라우드 액세스를 명시적인 아키텍처로 전환하기 때문입니다. 즉, 작은 도구, 살아있는 문서, IAM, 감사(Audit), 그리고 유지 관리되는 기술(Skills)로 구성됩니다. 이는 임시적인 흐름에 자격 증명(Credentials)을 붙여넣고 모델이 잘 작동하기를 바라는 것보다 훨씬 더 나은 방식입니다.

책임감 있는 도입은 읽기와 문서화에서 시작하여, 읽기 전용(Read-only) 검사로 이어지며, 그 이후에야 제한된 변형(Mutations) 단계로 진입합니다. 만약 여러분의 팀이 권한, 로그, 비용 및 롤백(Rollback)을 설명할 수 없다면, 아직 에이전트가 실제 인프라를 운영하도록 맡길 준비가 되지 않은 것입니다.

운영 규칙

자동화는 단순히 검토 가능한 노이즈를 생성하는 곳이 아니라, 코멘트가 기술적 의사결정을 바꿀 수 있는 곳에서 활성화하십시오.

출처 및 참고 문헌

• AWS News Blog: AWS MCP Server GA
• Agent Toolkit for AWS documentation
• AWS MCP Server tools
• GitHub: aws/agent-toolkit-for-aws
• AWS Developer Tools Blog: Agent Plugins for AWS
• How are AI agents used? Evidence from 177,000 MCP tools
• Bridging Protocol and Production: MCP design patterns
• Evaluating Tool Cloning in Agentic-AI Ecosystems

원문은 devaisemanal.com에 게시되었습니다.