Agentic AI 기반 플랫폼 – Part2 : AgentCore Gateway, Identity로 구현하는 MCP Registry

들어가며

이전 글(Part 1)에서는 2명의 Solutions Architect가 7주 만에 Agentic AI 기반 플랫폼을 구축한 과정과 AI-DLC 방법론, Kiro, Claude Code, Linear 등의 도구 활용 사례를 소개했습니다.

이번 글에서는 해당 플랫폼의 핵심 기능 중 하나인 MCP Registry를 기술적으로 깊이 있게 다룰 예정으로, MCP Registry는 AI Agent가 사용할 도구(MCP)를 생성, 등록, 배포, 관리하는 기능으로, Amazon Bedrock AgentCore의 세 가지 핵심 컴포넌트인 AgentCore Runtime, AgentCore Gateway, AgentCore Identity를 활용하여 구현했습니다.

이 글을 통해 다양한 형태의 MCP를 AgentCore 기반으로 통합 관리하는 아키텍처를 설계하고 구현하는 데 실질적인 참고가 되기를 바랍니다.

이 글은 시리즈의 두 번째 편으로, MCP Registry의 아키텍처와 AgentCore 활용을 다룹니다. 다음 편에서는 Agent 관리와 Strands Agents를 활용한 AI Agent 생성 및 배포에 대해 상세히 다루겠습니다.

Part 1에서 소개한 MCP Registry

Part 1에서 소개한 것처럼, MCP Registry는 AI Agent가 사용할 외부 도구를 등록하고 관리하는 기능입니다. 세 가지 형태로 MCP를 등록할 수 있으며, 각 MCP의 상태 관리와 Tool 목록 조회를 지원합니다.

Figure 1. <MCP Registry 구현 화면>

이번 글에서는 이 MCP Registry가 내부적으로 어떤 AWS 서비스를 활용하여, 어떻게 구현되었는지를 상세히 다루겠습니다.

MCP Registry 아키텍처 개요

MCP Registry란?

MCP Registry는 AI Agent가 외부 세계와 상호작용하기 위한 도구(Tool)를 통합 관리하는 기능입니다. 하나의 플랫폼에서 다양한 형태의 MCP를 등록하고, 각 MCP가 제공하는 Tool 목록을 자동으로 조회하며, Agent에 연결할 수 있도록 표준화된 엔드포인트를 제공합니다.

본 프로젝트에서 MCP Registry는 세 가지 등록 유형을 지원합니다.

Figure 2. <MCP Registry 에서 지원하는 3가지 MCP 등록 유형>

핵심 설계 원칙

이 아키텍처를 설계하면서 가장 중요하게 고려한 점은 “Agent 입장에서 MCP의 출처에 관계없이 동일한 방식으로 Tool을 호출할 수 있어야 한다” 는 것이었습니다. 외부 URL을 등록하든, 컨테이너를 배포하든, REST API를 변환하든, 최종적으로 Agent에 노출되는 인터페이스는 AgentCore Gateway를 통한 표준 MCP 프로토콜로 통일됩니다.

Amazon Bedrock AgentCore 핵심 컴포넌트

MCP Registry 구현의 근간이 되는 Amazon Bedrock AgentCore의 세 가지 핵심 컴포넌트를 먼저 살펴보겠습니다.

AgentCore Runtime: 서버리스 컨테이너 배포

AgentCore Runtime은 컨테이너 이미지를 서버리스 환경에서 실행하는 관리형 컴퓨팅 서비스입니다. 본래 AI Agent를 인프라 관리 없이 배포하고 상태를 유지(stateful)할 수 있도록 설계된 서비스이며, MCP 서버와 A2A(Agent-to-Agent) 서버 배포도 지원합니다. ECR(Elastic Container Registry)에 저장된 Docker 이미지를 지정하면, 스케일링과 헬스 체크를 Runtime이 관리해주므로 MCP 서버를 간편하게 배포할 수 있습니다.
B
본 프로젝트에서 Runtime은 Internal MCP (Container) 배포에 활용됩니다.

AgentCore Gateway: MCP 통합 엔드포인트

AgentCore Gateway는 MCP 프로토콜을 지원하는 관리형 게이트웨이로, 다양한 백엔드 소스를 단일 MCP 엔드포인트로 통합합니다. Gateway에는 여러 Target을 연결할 수 있으며, 각 Target은 서로 다른 유형의 백엔드를 나타냅니다.

특히 Integration Target은 Salesforce, Slack, Jira, Asana, Zendesk 등 주요 SaaS 서비스에 대해 사전 구성된 템플릿을 제공합니다. 별도의 MCP 서버를 개발하거나 OpenAPI Schema를 작성할 필요 없이, AWS Management Console에서 서비스를 선택하고 인증 정보(OAuth2 또는 API Key)만 설정하면 해당 서비스의 API가 MCP Tool로 자동 등록됩니다. 예를 들어 “Slack 채널에 메시지를 보내고 Jira에 이슈를 생성하는 Agent”를 MCP 서버 개발 없이 Gateway 설정만으로 구현할 수 있습니다.

Gateway를 어떻게 구성할지는 거버넌스 정책에 따라 달라집니다. 본 프로젝트에서는 두 가지 패턴을 사용했습니다. 하나는 여러 MCP를 하나의 공유 Gateway에 Target으로 묶어 관리하는 방식이고, 다른 하나는 MCP마다 전용 Gateway를 생성하여 완전히 격리하는 방식입니다. External MCP처럼 외부 서버를 가볍게 등록하는 경우에는 공유 Gateway로 관리 부담을 줄이고, Internal MCP처럼 개별 엔드포인트, 개별 IAM 역할, Semantic Search 설정 등을 MCP 단위로 독립 관리해야 하는 경우에는 전용 Gateway가 적합합니다.

Gateway의 또 하나의 강력한 기능은 Semantic Search입니다. protocolConfiguration에서 searchType: 'SEMANTIC'을 설정하면, Agent가 수십~수백 개의 Tool 중에서 의미적으로 가장 적합한 Tool을 자연어로 검색할 수 있습니다.

create_params = {
    'name': gateway_name,
    'roleArn': role_arn,
    'protocolType': 'MCP',
    'authorizerType': 'AWS_IAM',
    'protocolConfiguration': {
        'mcp': {
            'searchType': 'SEMANTIC'
        }
    }
}
gateway = gateway_client.create_gateway(**create_params)

Semantic Search가 활성화되면, Gateway에 x_amz_bedrock_agentcore_search라는 내장 Tool이 자동으로 추가됩니다. Agent는 이 Tool을 호출하면서 자연어 쿼리를 전달하고, Gateway는 등록된 Tool들 중 의미적으로 관련성이 높은 Tool 목록을 반환합니다.

Semantic Search를 효과적으로 활용하려면, 각 Tool의 Schema 품질이 중요합니다. AWS 공식 성능 가이드에서도 다음과 같이 권장하고 있습니다.

• Tool의 description을 명확하고 구체적으로 작성할 것 – Semantic Search가 Tool을 검색할 때 핵심적으로 활용하는 필드입니다.
• 파라미터에도 의미 있는 설명을 포함할 것 – Agent가 올바른 Tool을 선택하고 정확한 인자를 전달하는 데 도움이 됩니다.
• Schema를 가능한 간결하게 유지하고, required 필드를 명확히 지정할 것

예를 들어, get_order라는 Tool 이름만으로는 “주문 상태 확인”, “주문 이력 조회”, “주문 취소 가능 여부 확인” 중 어떤 용도인지 알 수 없습니다. description: "주문 ID를 기반으로 현재 배송 상태, 예상 도착일, 결제 정보를 조회합니다"와 같이 구체적으로 기술해야 Semantic Search에서 정확한 Tool을 반환할 수 있습니다.

공식 Quota 기준으로 Gateway당 최대 100개 Target, Target당 최대 1,000개 Tool을 등록할 수 있어, 이론적으로 하나의 Gateway에서 수만 개의 Tool을 관리할 수 있습니다. 모든 Tool을 Agent 컨텍스트에 넣는 대신 Semantic Search로 필요한 것만 검색하므로, 토큰 사용량 절감과 Tool 선택 정확도 향상을 동시에 기대할 수 있습니다.

다만, Semantic Search 호출은 분당 25회(기본값)의 속도 제한이 있으므로, 고빈도 호출 시나리오에서는 Service Quotas를 통해 증가를 요청해야 합니다.

또한 Gateway는 Tool 이름에 {target_name}__{tool_name} 형식의 prefix를 자동으로 추가합니다. 이를 통해 여러 Target에서 동일한 이름의 Tool이 있더라도 충돌 없이 구분할 수 있습니다.

AgentCore Identity: 인증과 접근 제어

AgentCore Identity는 AI Agent와 자동화 워크로드를 위한 ID, 인증, 자격증명 관리 서비스입니다. Gateway의 인바운드 인증(누가 Gateway를 호출할 수 있는가)과 아웃바운드 인증(Gateway가 Target 백엔드를 어떻게 호출하는가)을 모두 관리합니다.

인바운드 인증 — Gateway를 호출하는 주체의 신원을 검증합니다.

아웃바운드 인증 — Gateway가 Target 백엔드를 호출할 때 필요한 인증 정보를 Credential Provider가 관리합니다.

Figure 3. <AgentCore Identity 인증 흐름>

MCP 유형별 아키텍처와 구현

External MCP: 외부 MCP 서버 연결

External MCP는 이미 운영 중인 MCP 서버의 엔드포인트 URL을 플랫폼에 등록하는 방식입니다. 공유 Gateway에 MCP Server Target으로 등록됩니다. AWS 관리형 MCP 서비스(예: https://knowledge-mcp.global.api.aws/)나, 사내에서 streamable-http로 직접 운영하는 MCP 서버를 연결할 때 유용합니다.

MCP 생태계는 streamable-http를 지원하는 MCP 서버가 늘어남에 따라 이 방식의 활용 범위도 넓어지고 있습니다. 한편, Slack이나 Jira 같은 주요 SaaS 서비스 연동이 목적이라면 앞서 소개한 Integration Target을 활용하는 것이 더 간편합니다.

플랫폼 내부적으로는 다음과 같은 플로우로 동작합니다.

생성 플로우:

1. Cognito 공유 인프라 조회/생성 (User Pool, Resource Server, M2M Client)
2. OAuth2 Credential Provider 조회/생성
3. 공유 Gateway(external-mcp-gateway) 조회/생성
4. Gateway READY 상태 대기
5. MCP Server Target 생성 (외부 엔드포인트 URL + OAuth Credential 연결)
6. Gateway에 tools/list 요청을 보내 Tool 목록 자동 조회 (SigV4 인증)
7. DynamoDB 저장

# MCP Server Target 생성 예시
response = gateway_client.create_gateway_target(
    gatewayIdentifier=gateway_id,
    name=target_name,
    description='MCP Server Target for my-mcp',
    targetConfiguration={
        'mcp': {
            'mcpServer': {
                'endpoint': 'https://my-mcp-server.example.com/mcp'
            }
        }
    },
    credentialProviderConfigurations=[{
        'credentialProviderType': 'OAUTH',
        'credentialProvider': {
            'oauthCredentialProvider': {
                'providerArn': oauth_provider_arn,
                'scopes': ['mcp-api/read', 'mcp-api/write', 'mcp-api/invoke']
            }
        }
    }]
)

흥미로운 점은, Gateway에 Target을 추가한 후 tools/list를 호출하면 등록한 MCP 서버가 제공하는 모든 Tool을 자동으로 발견할 수 있다는 것입니다. 이를 통해 사용자가 수동으로 Tool 정보를 입력할 필요 없이, MCP 프로토콜 표준에 따라 Tool 메타데이터가 자동으로 수집됩니다.

Figure 4. <등록한 MCP 서버가 제공하는 Tool 이 자동 조회되는 화면>

Internal MCP (Container) 배포: 컨테이너 기반 MCP 배포

Internal MCP (Container)는 가장 완전한 형태의 MCP 배포 방식입니다. ECR 이미지를 전용 Runtime에 배포하고 전용 Gateway를 생성하여 완전히 격리된 MCP 환경을 제공합니다.

배포 플로우 상세

배포 과정은 여러 AWS 리소스의 생성을 수반하므로, SSE(Server-Sent Events) 스트리밍을 통해 각 단계의 진행 상황을 실시간으로 프론트엔드에 전달합니다.

Figure 5. <Internal MCP (Container) 배포 프로그레스 UI – SSE를 통해 각 단계별 진행 상황을 실시간 표시>

MCP 서버 개발 가이드

AgentCore Runtime에 배포할 MCP 서버를 개발할 때 준수해야 하는 사항들이 있습니다.

서버 코드 구조:

import os
from mcp.server.fastmcp import FastMCP

# 모듈 레벨에서 MCP 인스턴스 생성 (중요!)
mcp = FastMCP(host="0.0.0.0", port=8000, stateless_http=True)

@mcp.tool()
def my_tool(param: str) -> str:
    """Tool 설명"""
    return "result"

def main():
    mcp.run(transport='streamable-http')

if __name__ == '__main__':
    main()

핵심 주의사항:

• Docker 이미지는 반드시 ARM64 아키텍처로 빌드해야 합니다. AMD64로 빌드하면 Runtime 생성 시 ValidationException: Architecture incompatible ... Supported architectures: [arm64] 오류가 발생합니다.
• 의존성에 mcp[cli] 패키지를 사용해야 합니다. 이 패키지가 from mcp.server.fastmcp import FastMCP를 제공합니다. PyPI에는 이름이 비슷한 fastmcp라는 별도의 커뮤니티 패키지가 있는데, import 경로와 API가 다르므로 혼동하지 않아야 합니다.
• transport='streamable-http'를 사용하고, host="0.0.0.0", port=8000, stateless_http=True를 설정해야 합니다.

Dockerfile:

FROM public.ecr.aws/amazonlinux/amazonlinux:2023

# ARM64 빌드 필수 (--platform linux/arm64)
# python, uv 설치 등 (생략)

WORKDIR /app
COPY . .
RUN uv sync --frozen

ENV PATH="/app/.venv/bin:$PATH" \
    PYTHONUNBUFFERED=1 \
    MCP_TRANSPORT=streamable-http \
    FASTMCP_HOST=0.0.0.0 \
    FASTMCP_PORT=8000

# Healthcheck - streamable-http 모드에서는 /mcp 엔드포인트 사용
HEALTHCHECK --interval=60s --timeout=10s --start-period=30s --retries=3 \
    CMD curl -sf http://localhost:8000/mcp || exit 1

EXPOSE 8000

ENTRYPOINT ["python", "-m", "my_mcp_server"]

빌드 및 ECR 푸시:

# ARM64 빌드 (필수!)
docker build --platform linux/arm64 -t my-mcp-server:v1 .

# ECR 푸시
aws ecr get-login-password --region us-east-1 | \
  docker login --username AWS --password-stdin {account_id}.dkr.ecr.us-east-1.amazonaws.com

docker tag my-mcp-server:v1 {account_id}.dkr.ecr.us-east-1.amazonaws.com/mcp-server:v1
docker push {account_id}.dkr.ecr.us-east-1.amazonaws.com/mcp-server:v1

Internal MCP (API) 생성: OpenAPI Schema로 REST API를 MCP화

Internal MCP (API)는 기존 REST API를 코드 변경 없이 MCP로 변환하는 가장 흥미로운 기능입니다. OpenAPI Spec(Swagger)을 입력하면 AgentCore Gateway가 각 API 엔드포인트를 MCP Tool로 자동 매핑합니다.

생성 플로우:

1. 전용 Gateway IAM 역할 생성
2. 전용 Gateway 생성 (IAM Authorizer, Semantic Search는 사용자 선택에 따라 활성화)
3. Gateway READY 대기
4. OpenAPI Schema를 기반으로 OpenAPI Target 생성
5. Credential Provider 연결 (API Key 또는 OAuth2)
6. OpenAPI Schema에서 Tool 메타데이터 자동 추출
7. DynamoDB 저장

# OpenAPI Target 생성 예시
target_config = {
    "mcp": {
        "openApiSchema": {
            "inlinePayload": json.dumps(openapi_schema)  # OpenAPI 3.0 JSON
        }
    }
}

response = gateway_client.create_gateway_target(
    gatewayIdentifier=gateway_id,
    name='sample-api',
    description='Sample REST API',
    targetConfiguration=target_config,
    credentialProviderConfigurations=[{
        'credentialProviderType': 'API_KEY',
        'credentialProvider': {
            'apiKeyCredentialProvider': {
                'providerArn': api_key_provider_arn,
                'credentialLocation': 'HEADER',
                'credentialParameterName': 'apikey'
            }
        }
    }]
)

이 방식의 장점은, 기존에 운영 중인 REST API의 코드를 전혀 수정하지 않고도 Agent가 MCP 프로토콜로 호출할 수 있게 된다는 것입니다. OpenAPI Schema에 정의된 경로, 파라미터, 응답 형식이 MCP Tool의 inputSchema와 description으로 자동 변환됩니다.

특히 Amazon API Gateway를 사용하고 있다면 통합이 더욱 간편합니다. API Gateway는 OpenAPI Schema 내보내기를 기본 지원하므로, 기존에 운영 중인 API Gateway의 스키마를 그대로 추출하여 AgentCore Gateway의 OpenAPI Target에 연결할 수 있습니다. AWS 서비스 간의 자연스러운 통합으로 기존 API 자산을 빠르게 MCP화할 수 있는 경로입니다.

적용 시 고려사항: API 응답 크기와 컨텍스트 관리

다만, 기존 REST API를 MCP Tool로 변환할 때 반드시 검토해야 할 사항이 있습니다. API의 응답이 곧 Agent의 Tool 응답이 된다는 점입니다. Tool 응답은 LLM의 컨텍스트 윈도우에 그대로 포함되기 때문에, 응답의 크기와 내용이 Agent의 성능과 비용에 직접적인 영향을 미칩니다.

사내 API들은 일반적으로 다양한 클라이언트(웹, 모바일, 내부 시스템)를 고려하여 응답에 많은 필드를 포함하는 경우가 많습니다. 예를 들어 주문 조회 API가 주문 정보, 결제 상세, 배송 이력, 고객 메타데이터 등을 모두 반환할 수 있는데, Agent가 실제로 필요한 정보는 그 중 일부(예: 주문 상태, 배송 예정일)일 수 있습니다.

따라서 기존 API를 MCP화하기 전에, Agent가 실제로 필요한 응답 항목만을 반환하는지 검토하는 과정이 필요합니다. 만약 기존 API의 응답이 과도하게 크다면, 기존 API 앞단에 응답을 가공하는 중간 레이어를 두거나, Agent 전용 경량 API 엔드포인트를 별도로 구성하는 것을 권장합니다.

인증과 보안

Amazon Cognito 기반 OAuth2 인프라: 서비스(MCP)를 사용할 자격 확인

본 프로젝트에서는 MCP 간 인증을 위해 Amazon Cognito를 공유 OAuth2 인프라로 활용했습니다. 하나의 User Pool을 생성하고, Resource Server에 read, write, invoke 세 가지 scope를 정의하여 MCP 접근을 세밀하게 제어합니다.

Cognito 공유 인프라 구성:
├── User Pool: aws-agentic-ai-mcp-pool-{env}
│   ├── Domain: mcp-{pool_suffix}
│   ├── Resource Server: mcp-api
│   │   ├── Scope: read (Tool 목록 조회)
│   │   ├── Scope: write (Tool 실행)
│   │   └── Scope: invoke (Runtime 호출)
│   └── M2M Client: mcp-gateway-oauth-client
│       └── OAuth Flow: client_credentials
└── Discovery URL: https://cognito-idp.{region}.amazonaws.com/{pool_id}/.well-known/openid-configuration

이 인프라는 플랫폼이 최초 MCP를 배포할 때 자동으로 생성됩니다. 이미 존재하는 경우 기존 리소스를 재사용하므로, 여러 MCP를 배포해도 Cognito 리소스가 중복 생성되지 않습니다.

AWS IAM 기반 인증 (SigV4): 서비스가 AWS 자원을 쓸 권한 확인

Internal MCP의 Gateway는 AWS IAM Authorizer를 사용합니다. 플랫폼 백엔드에서 Gateway를 호출할 때는 AWS Signature V4 서명을 사용합니다.

from botocore.auth import SigV4Auth
from botocore.awsrequest import AWSRequest

# MCP Protocol tools/list 요청
payload = {
    "jsonrpc": "2.0",
    "id": "list-tools",
    "method": "tools/list"
}

request = AWSRequest(
    method='POST',
    url=gateway_url,
    data=json.dumps(payload),
    headers={'Content-Type': 'application/json'}
)

# SigV4 서명 추가
SigV4Auth(credentials, 'bedrock-agentcore', region).add_auth(request)

response = requests.post(url, headers=dict(request.headers), data=request.body)

사용자 기반 접근 제어: 3LO와 AgentCore Policy

본 프로젝트에서는 플랫폼 수준의 M2M(Machine-to-Machine) 인증에 초점을 맞추었지만, AgentCore Identity는 사용자 단위의 세밀한 접근 제어도 지원합니다. 엔터프라이즈 환경에서 Agent 도입을 검토할 때 자주 거론되는 영역입니다.

3LO(Three-Legged OAuth) 인증은 Agent가 Tool을 실행하는 시점에 최종 사용자의 동의를 받아 동적으로 자격 증명을 발급하는 방식입니다. 예를 들어 Slack Tool을 호출할 때, 플랫폼의 자격 증명이 아닌 실제 사용자의 Slack 계정으로 인증하여, “누가 이 작업을 수행했는가”를 명확히 추적할 수 있습니다.

Amazon Bedrock AgentCore Policy는 Gateway 레벨에서 Agent의 모든 트래픽을 가로채 정책을 평가한 뒤 Tool 접근을 허용하는 서비스입니다. 정책은 오픈소스 인가 정책 언어인 Cedar로 작성하며, user identity와 tool input parameters를 기반으로 접근 여부를 판단합니다. 자연어로 정책을 기술하면 Cedar 코드로 자동 변환하는 기능도 제공합니다.

이러한 기능들은 엔터프라이즈 환경에서 “누가, 어떤 Tool을, 어떤 권한으로 호출했는가”를 제어하고 감사해야 하는 요구사항에 대응할 수 있습니다. 본 프로젝트에서는 이 기능들을 직접 구현하지는 않았지만, 엔터프라이즈 요구사항에 따라 확장 포인트로서 고려해볼 만합니다.

Observability: ADOT를 활용한 모니터링

AgentCore Runtime에 배포된 MCP 서버의 로그와 트레이싱을 위해 AWS Distro for OpenTelemetry(ADOT)를 활용했습니다. Dockerfile의 ENTRYPOINT를 opentelemetry-instrument로 감싸면, 코드 수정 없이 자동 계측이 적용됩니다.

# ADOT 환경변수 설정
ENV AGENT_OBSERVABILITY_ENABLED=true \
    OTEL_PYTHON_DISTRO=aws_distro \
    OTEL_PYTHON_CONFIGURATOR=aws_configurator \
    OTEL_EXPORTER_OTLP_PROTOCOL=http/protobuf \
    OTEL_TRACES_EXPORTER=otlp

# opentelemetry-instrument로 자동 계측
ENTRYPOINT ["opentelemetry-instrument", "python", "-m", "my_mcp_server"]

이후 CloudWatch GenAI Observability 대시보드에서 Agent, Gateway, Memory 등 리소스 유형별 메트릭을 한눈에 확인할 수 있으며, 로그 그룹은 /aws/bedrock-agentcore/runtimes/{runtime-id} 경로에 자동 생성됩니다. AgentCore Observability는 OpenTelemetry 표준 포맷으로 텔레메트리를 출력하므로, Datadog, Splunk, Grafana 등 OTEL 호환 플랫폼과도 연동할 수 있습니다.

Figure 6. <CloudWatch Transaction Search에서 MCP 서버 트레이스 조회 화면>

대시보드에서 특정 세션이나 트레이스를 선택하면 span 단위의 상세 뷰로 drill-down할 수 있습니다. 세션 ID 기반으로 Agent의 event loop cycle → LLM 호출 → Tool 실행의 전체 흐름이 span 계층 구조로 시각화되며, 각 span에서 소요 시간, 토큰 사용량, Tool의 입출력 데이터까지 확인할 수 있어 성능 병목 식별과 디버깅에 유용합니다.

Figure 7. < Agent 실행 흐름 요약 메트릭 정보>

마치며

MCP Registry를 AgentCore 기반으로 구현하면서 얻은 핵심 인사이트를 정리하면 다음과 같습니다.

1. AgentCore Gateway는 MCP 통합의 핵심입니다.
다양한 형태의 MCP(외부 URL, 컨테이너, REST API)를 하나의 표준 인터페이스로 통합할 수 있습니다. Agent 입장에서는 MCP의 출처를 몰라도 동일한 방식으로 Tool을 호출할 수 있으며, AgentCore Gateway의 Semantic Search를 통해 수십 개의 Tool 중 최적의 특정 도구(Tool)를 자동으로 선택할 수 있습니다.

2. Cognito 기반 OAuth2 인프라와 AgentCore Identity를 활용하면 MCP 접근 인증을 일관되게 관리할 수 있습니다.
하나의 Cognito User Pool을 중앙 인증 서버로 구성하고, OAuth2 Credential Provider를 통해 AgentCore Gateway가 외부 API를 안전하게 호출하도록 구성했습니다. 이를 통해 각 MCP마다 개별적인 인증 체계를 구현할 필요 없이, 플랫폼 차원에서 일관된 보안 정책을 적용할 수 있었습니다.

3. AgentCore는 M2M 인증을 넘어 사용자 수준의 접근 제어까지 확장할 수 있습니다.
본 프로젝트에서는 Credential Provider 기반의 M2M 인증을 구현했지만, 3LO 인증과 AgentCore Policy를 활용하면 “누가, 어떤 Tool을, 어떤 권한으로 호출했는가”까지 제어할 수 있습니다. Agent가 엔터프라이즈 환경에서 실제 업무에 투입되려면 이러한 세밀한 접근 제어와 감사 추적이 필수적이며, AgentCore가 이를 위한 확장 포인트를 이미 제공하고 있다는 점은 주목할 만합니다.

최종 요약하면, “수많은 AI 도구들을 한곳에 모아(AgentCore Gateway), 보안 걱정 없이 안전하게 연결하고(OAuth2), 누가 뭘 했는지 꼼꼼하게 관리할 수 있는(Policy)플랫폼”을 구축한 내용입니다.

이 글은 시리즈의 2편입니다. 다음 편에서는 Agent관리 기능과 Strands Agents 프레임워크를 활용한 AI Agent 생성, 배포, 실시간 테스트에 대해 기술적으로 상세히 다루겠습니다.

주요 링크 모음

• Agentic AI 기반 플랫폼 – 7주만에 기획부터 배포까지, Part 1: AI-DLC 방법론과 유용한 도구들
• Amazon Bedrock AgentCore 공식 문서
  • Amazon Bedrock AgentCore Gateway 문서
  • Amazon Bedrock AgentCore Identity 문서
  • Amazon Bedrock AgentCore Policy 문서
  • Amazon Bedrock AgentCore Observability 문서
• AWS Labs MCP Servers (GitHub)
• Amazon Bedrock AgentCore Starter Toolkit GitHub
• Amazon Bedrock AgentCore Samples 리포지토리
• Amazon Bedrock AgentCore Identity로 안전한 기업형 에이전트 구현하기 | AWS 기술 블로그