Knowledge MCP vs 관리형 AWS MCP Server, IAM, 그리고 .env에 키를 붙여넣지 않고 Claude Code, Claude 앱, Kiro에서 설정하는 방법.

🇧🇷 포르투갈어로도 이용 가능: AWS MCP Server: qual usar, quando e como configurar

한 장면을 말씀드려 보겠습니다. 여러분도 분명 겪어보셨을 상황입니다.

밤 11시, 여러분은 바로 옆에 AI를 앉혀두고 코딩을 하고 있습니다. 무언가를 물어보면 AI는 그것이 존재한다고 단언합니다. 이전에 만들어본 것과 매우 유사한 이름의 서비스를 만들어내고, 심지어 작동한다고 약속하는 구현 방식과 상세한 방법까지 제시합니다. 그러면 여러분은 '허, 그런 게 있었나? 말이 되는 것 같으니 문서를 확인해봐야겠다'라고 생각하죠. 그리고 쾅, 그것이 환각 (hallucinating)이었다는 사실을 깨닫게 됩니다. AI는 존재하지 않는 함수에서 AWS 서비스를 호출하는 Lambda 코드를 작성하고, DynamoDB 테이블을 연결하고, IaC (Infrastructure as Code)를 구축하는 등 모든 과정을 수행하고 있었습니다. 그러고 나서 AI는 이름을 확인하기 위해 "계정의 현재 설정(config)을 살펴보겠다"라고 요청하고, 여러분은 모두가 마주하는 벽에 부딪힙니다.

에이전트 (agent)는 환각을 일으킬 뿐만 아니라, 여러분의 계정에 대한 접근 권한이 없습니다. 리소스를 볼 수 없으며, 실제로 무엇이 있는지 전혀 모릅니다. 그래서 에이전트는 자신이 가장 잘하는 일을 합니다. 창의적이고, 주도적이며, 여러분을 기쁘게 하기 위해 무언가를 발명해냅니다. AI에게는 그것이 존재하는 것이 논리적이기 때문에, 당연히 존재한다고 가정합니다. 이 작은 친구는 부끄러워하지도 않습니다. 존재하지 않는 ARN을 건네주고, 사용하지 않는 리전 (region)을 선택하며, 테이블 이름을 추측합니다. 그렇게 진행됩니다. AI는 여러분을 기쁘게 하기 위해 만들어진 목적 그대로 행동하고 있는 것입니다.

그리고 AI와 싸우는 데 지쳐서 그냥 일을 마무리하고 싶은 여러분은 어떻게 하나요? AI가 "잠시만 계정을 확인해서" 실제 이름으로 모든 것을 정확하게 알려줄 수 있도록, .env 파일에 액세스 키 (access key)를 붙여넣고 마나요? 이런 적이 한 번도 없었던 사람이 있을까요?

그리고 그 모든 것이 괜찮아 보이지만, 단 한 가지 세부 사항이 문제입니다. 바로 당신이 그 작업을 했다는 사실을 잊어버리는 것이죠. 그리고 쾅, .env 파일이 커밋(commit)에 포함되어 버립니다. 이미 Git 히스토리에 남았고, 곳곳에서 경고가 울리며, 평소와 다름없는 난장판이 됩니다. 이제 키(key)가 노출되었습니다. 그리고 바로 그 순간, 당신을 벌주기로 마음먹었거나 혹은 너무 의욕이 앞선 것처럼 보이는 당신의 에이전트(agent)가 당신의 계정에 대한 실제 액세스 권한을 얻게 되고, 누가 알겠습니까, 잘못된 스택(stack)을 삭제하기로 결정할지도 모릅니다. 아니면 그저 단 하루 만에 40달러의 깜짝 청구서가 날아올 수도 있는데, 아무도 지켜보지 않을 때는 훨씬 더 끔찍한 숫자로 변하기도 합니다. 저도 이런 일을 겪어봤습니다. 아마 당신도 그랬을 것입니다.

좋은 소식은 AWS가 이 문제를 해결했다는 것입니다. 사실, AWS는 이름이 너무 비슷해서 많은 사람을 혼란스럽게 만드는 두 가지 방식으로 이 문제를 해결했습니다. 이 포스트는 제가 가졌으면 좋았을 지도입니다. 이 둘의 차이점은 무엇인지, 각각 어떤 고통을 해결해 주는지, 그리고 언제 어떻게 각각을 사용해야 하는지에 대한 지도 말입니다. 시작해 봅시다.

최신성 참고 (Freshness note): MCP 세계는 빠르게 움직입니다. 저는 이 가이드를 2026년 6월에 작성했고, 연결 흐름이 변경되었을 때(현재 읽고 계신 버전은 직접적인 OAuth를 사용합니다)인 2026년 7월에 이미 업데이트를 해야 했습니다. 새로운 기능들이 출시됨에 따라 최신 상태를 유지하도록 최선을 다하겠지만, 만약 눈앞의 화면과 일치하지 않는 부분이 있다면 공식 문서를 확인하고 댓글로 알려주세요. 수정하도록 하겠습니다.

이 글을 통해 배우게 될 내용

길을 잃지 않도록, 우리가 다룰 내용은 다음과 같습니다:

• 두 가지 AWS MCP 서버의 차이점과 각각이 해결하는 문제
• Claude Code, Claude 앱, 그리고 Kiro에서 단계별로 연결하는 방법
• 안전하게 액세스 권한을 부여하기 위해 계정의 IAM을 설정하는 방법
• 사용하지 말아야 할 때와 청구서에 나타날 끔찍한 깜짝 놀랄 일을 피하는 방법

그런데, MCP란 대체 무엇인가요?

서버에 대해 이야기하기 전에, 기준을 먼저 맞춰봅시다.

MCP (Model Context Protocol)는 AI 어시스턴트가 도구(tools), 데이터(data), 서비스(services)와 같은 외부 세계와 소통하기 위해 사용하는 "플러그(plug)"입니다. Anthropic이 이를 만들었으며, 현재는 오픈 거버넌스(open governance) 하에 있습니다. 지난 1년 동안 사용할 가치가 있는 모든 어시스턴트(Claude Code, Kiro, Cursor)가 MCP를 지원하기 시작했습니다.

쉬운 비유를 들어볼까요? API를 생각해보세요. API는 두 애플리케이션이 서로 통신할 수 있게 해주는 것입니다. MCP도 에이전트(agent)를 위한 동일한 개념입니다. 즉, 사용자가 모든 개별 시스템에 대해 맞춤형 통합(custom integration)을 구축할 필요 없이 AI가 어떤 도구와도 통신할 수 있게 해줍니다. MCP는 모두가 사용하기로 합의한 표준을 통해 에이전트를 시스템에 연결합니다. 표준의 장점은 바로 이것입니다. 한 번 배우면 어떤 도구와 어떤 클라이언트에서도 작동한다는 점이죠. 따라서 AI에게 귀하의 시스템에 대한 접근 권한을 부여하고 싶다면, 이것이 따라야 할 경로입니다.

그리고 삶을 훨씬 더 편하게 만들어주는 사실이 하나 있습니다. 대부분의 경우, 직접 MCP 서버를 구축할 필요조차 없다는 것입니다. 물론 직접 구축할 수도 있습니다(Lambda, Fargate 등 선호하는 방식에 따라). 만약 직접 구축하는 경우라면 AWS에서 제공하는 공식 가이드도 있습니다. 하지만 AWS는 이미 바로 사용할 수 있는 관리형 서버(managed servers)를 운영하고 있으므로, 많은 경우 그냥 연결해서 사용하기만 하면 됩니다. 직접 구축하는 것이 의미가 있는 경우는 목표가 다를 때입니다. 즉, 귀하의 내부 시스템(API, 런북(runbook), 알림(alert) 등)을 에이전트에 노출하고자 할 때입니다.

두 가지 AWS MCP 서버

네, 두 가지가 있습니다. 그리고 이름은 전혀 도움이 되지 않습니다. 아래 표에 모든 내용을 정리해 두었으며, 그 후 각각을 자세히 설명하겠습니다.

만약 이 글에서 단 한 문장만 기억해야 한다면, 바로 이 문장입니다:

한 서버는 에이전트에게 지식(knowledge)을 제공합니다. 다른 서버는 에이전트에게 손(hands)을 제공합니다.

실제로 어떤 문제를 겪고 있는지 파악하는 것이 승패의 절반을 결정합니다.

또 다른 비유를 들어볼까요? Knowledge(지식) 서버는 구루(guru)와 같습니다. AWS 문서 전체를 암기하고 있어 당신의 의문점을 즉석에서 해결해 주는 친구 말이죠. Managed(관리형) 서버는 배지를 확인하는 문지기(doorman)와 같습니다. 당신을 실제 계정으로 들여보내 주지만, 그 자리에 서서 확인 작업을 수행하며 IAM이 허가한 문만 열어줍니다. 이름이 배지와 일치하지 않나요? 그러면 들어갈 수 없습니다.

이것은 어디에서 실행되나요? AWS MCP Server는 원격(remote)에서 실행되며, 여기에 연결되는 것은 MCP 클라이언트(client)입니다: Claude Code, Claude 앱(Desktop 및 claude.ai), Kiro, Cursor, 또는 당신이 직접 작성한 에이전트 코드(Strands, SDK)가 이에 해당합니다. 이는 추론(inference)이 Bedrock에서 실행되더라도 동일하게 적용되는데, 클라이언트는 애플리케이션이지 모델이 아니기 때문입니다. 하지만 AgentCore에서 실행되는 프로덕션 에이전트(production agent)는 일반적으로 AgentCore Gateway(이 또한 MCP를 지원함) 또는 자체 MCP 서버를 통해 도구(tools)를 사용합니다. 해당 프로덕션 시나리오는 이 시리즈의 다음 포스트에서 다룰 주제입니다.

서버 #1: AWS Knowledge MCP Server

이 서버가 하는 일은 간단합니다. 원격에서 실행되는 완전 관리형(fully managed) 서버이며, 모델에게 항상 최신 상태인 공식 문서에 대한 구조화된 접근 권한을 제공합니다. 여기서 "최신(current)"이라는 점이 핵심입니다. 모델이 스스로 알고 있는 지식은 학습 데이터의 날짜(training date)에서 멈추기 때문에, 그 이후에 발생한 일에 대해서는 전혀 알지 못하고 결국 추측하게 됩니다. AWS는 이 서버를 동기화된 상태로 유지하므로, 이 서버는 당신의 신뢰할 수 있는 단일 출처(source of truth)가 됩니다. 문서를 검색하고, 해당 페이지를 깔끔한 마크다운(markdown) 형식으로 반환하며, 특정 리전(region)에 서비스가 존재하는지 확인하고, 현재 리전 목록을 나열합니다. 읽기 전용(Read-only)이므로 계정에 내용을 쓰거나 수정하지 않습니다.

이 서버를 활성화하는 것이 거의 당연한 선택(no-brainer)인 이유는 무엇일까요? 별도의 자격 증명(credential)이나 AWS 계정이 필요 없기 때문입니다. 보호해야 할 것도, 유출될 것도 없습니다. 리스크는 기본적으로 제로에 가까우며, 에이전트가 CDK를 내뱉기 전에 추측을 멈추고 실제 문서를 인용하기 시작한다는 점에서 얻는 이득은 매우 큽니다.

서비스를 학습할 때, 구축하려는 아키텍처를 설계하고 아이디어를 검증할 때, 구문을 확인할 때, 실제로 신뢰할 수 있는 IaC (Infrastructure as Code)를 생성할 때, 또는 브라우저를 열지 않고 "이게 내 리전에 이미 출시되었나?"라는 질문에 답을 얻고 싶을 때 사용하세요. 연결 방법은 URL을 붙여넣는 것뿐입니다. 클라이언트의 원격 (HTTP) 서버로 https://knowledge-mcp.global.api.aws를 추가하기만 하면 끝이며, 별도의 자격 증명(credentials)도 전혀 필요하지 않습니다. 이 서버를 켜두면, 에이전트는 학습 데이터에 기반해 추측하는 대신 실시간 문서를 확인한 후 CDK를 내뱉습니다. 환각(Hallucination) 현상이 발생하는 ARN (Amazon Resource Name) 수치가 급격히 떨어집니다. 꽤 괜찮죠?

서버 #2: AWS MCP Server, 관리형 서버 (계정을 읽고 조작함)

이것은 .env 파일을 사용하는 수치심을 치료해 주는 도구입니다.

고통의 종류가 다릅니다. 에이전트가 계정 내에서 실제로 무언가를 보거나 수행해야 합니다. 오류가 발생하는 함수의 CloudWatch 로그를 읽거나, 버킷에 실제로 무엇이 있는지 목록을 나열하거나, DynamoDB 테이블의 실제 스키마를 확인해야 합니다. 과거의 "해결책"은 에이전트에게 수명이 긴 자격 증명(long-lived credential)을 넘겨주는 것이었습니다. 이는 보안 담당자들을 밤잠 설치게 만드는 부분입니다. 그리고 솔직히 말해서, 여러분도 밤잠을 설치게 만들어야 마땅한 일입니다.

이 서버가 하는 일: AWS가 원격으로 호스팅하고 관리하며, 작고 고정된 도구 세트를 통해 에이전트에게 AWS 서비스에 대한 인증된 액세스 권한을 부여합니다. 로컬 설치가 필요 없고, 자동 업데이트가 지원되며, (제가 정말 좋아하는 부분인데) 모든 호출이 CloudTrail에 기록됩니다. 에이전트는 마스터 키를 갖지 않습니다. 실제 인증 흐름(auth flow)을 통해 여러분을 대신하여 인증하며, IAM (Identity and Access Management)의 통제(leash)를 받습니다.

쉬운 영어로 설명하는 인증 흐름: 현재 두 가지 경로가 있으며, 더 최신 방식이 더 간단합니다. 현재 서버는 OAuth를 직접 사용합니다. 클라이언트에 URL을 추가하면, 첫 번째 도구 호출 시 AWS 로그인 브라우저가 열리고, 평소 사용하던 ID로 로그인하면 끝입니다. 토큰은 1시간 동안 유지되며 최대 12시간까지 스스로 갱신됩니다. 프록시도 필요 없고, 설치할 것도 없습니다.

두 번째 경로는 mcp-proxy-for-aws를 사용하는 SigV4입니다. 이는 사용자의 로컬 머신에서 실행되는 오픈 소스 프록시(open source proxy)로, 로컬 AWS CLI 자격 증명(credentials)을 가져와 모든 호출에 서명(sign)을 합니다. 이 방식도 여전히 유효하며 특정 상황에서 유용합니다: 동일한 세션 내의 여러 계정 사용, 읽기 전용 모드(에이전트로부터 쓰기 권한이 있는 도구를 숨김), 고정된 기본 리전(default region) 설정, 또는 OAuth 권한(signin:AuthorizeOAuth2Access 및 signin:CreateOAuth2Token)을 차단하는 조직(org)의 경우입니다.

어떤 방식을 선택하든 결과는 같습니다. 어디에도 키(key)를 붙여넣을 필요가 없으며, 에이전트는 사용자의 신원(identity)으로 동작하고, 모든 것은 사용자의 IAM을 준수합니다. 참고로, 문서 검색(Documentation search)에는 자격 증명이 전혀 필요하지 않습니다.

OAuth 흐름(flow) 단계별 안내:

1. 사용자의 역할(role) 또는 사용자(user)에 AWSMCPSignInOAuthAccessPolicy 관리형 정책(managed policy)을 (한 번) 연결합니다.
2. 클라이언트에 서버 URL을 추가하고 첫 번째 호출을 실행합니다.
3. AWS 로그인(AWS Sign-in) 브라우저 창이 열리면 승인(authorize)합니다. 그러면 클라이언트가 토큰을 유지합니다 (1시간 유지, 최대 12시간까지 자동 갱신).
4. 서버가 컨텍스트 키(context keys)를 적용하여 AWS 서비스로 전달합니다.
5. IAM이 사용자의 정책을 통해 권한을 부여(authorize)하고 응답합니다.
6. 전체 호출 내역이 CloudTrail에 기록됩니다.

첫 번째 도구 호출 시 브라우저가 열리고, 사용자가 로그인하며, 에이전트는 IAM의 통제 하에 계정을 확인합니다.

또 다른 경로도 있습니다. 바로 aws-core 플러그인입니다. AWS MCP Server 위에 추가로 구성되어 있으며, 이 플러그인은 AWS 에이전트 스킬을 제공합니다. 이는 에이전트가 CDK(Cloud Development Kit), 서버리스(serverless), 컨테이너(containers), 그리고 청구 작업까지 잘 처리할 수 있도록 준비된 명령어 묶음입니다. 만약 서버와 추가적인 맥락 정보를 한 번에 원한다면, Anthropic의 공식 마켓플레이스에서 설치할 수 있습니다. Claude Code가 이미 내장하고 있는 플러그인입니다:

/plugin install aws-core@claude-plugins-official

사람들이 헷갈려 하는 세부 사항이 하나 있습니다: 이 명령어는 Claude Code 내부, 터미널에서 실행됩니다. Claude Desktop 앱의 '플러그인(Plugins)' 섹션은 다른 카탈로그이므로, 그곳에서 aws-core를 찾으려고 하지 마세요 (앱 내에서는 경로가 다음 섹션의 커넥터입니다).

여기서 조향(steering)에 해당하는 것은 프로젝트 루트에 있는 CLAUDE.md 파일이며, 아래 Kiro 블록에서 보여주는 것과 동일한 규칙을 따릅니다.

Claude 앱에서 (데스크톱 및 claude.ai)

네, 앱에서도 작동하며 터미널이 필요 없습니다. Claude Desktop에서는: 설정(Settings) > 커넥터(Connectors) > '사용자 지정 커넥터 추가(Add custom connector)'를 선택하고 이름을 지정한 후 (저는 aws-mcp라고 이름 붙였습니다), URL을 붙여넣으면 됩니다: