Amazon Bedrock을 활용한 MCP 허브 아키텍처로 기업의 AI 시스템 비즈니스 민첩성 가속화

이 게시글은 AWS Artificial Intelligence Blog의 “Accelerating AI innovation: Scale MCP servers for enterprise workloads with Amazon Bedrock by Xan Huang“ 를 번역 및 편집 하였습니다.

생성형 AI는 새로운 도구, 서비스 및 모델이 자주 출시되면서 빠른 속도로 발전하고 있습니다. Gartner에 따르면, 에이전트 AI는 2025년 주요 기술 트렌드 중 하나이며, 조직들은 기업 환경에서 에이전트를 활용하는 방법에 대한 프로토타입을 구현하고 있습니다. 에이전트는 도구에 의존하며, 각 도구는 정보를 송수신하는 자체 메커니즘을 가질 수 있습니다. Anthropic의 Model Context Protocol(MCP)은 이러한 문제를 해결하기 위한 오픈 소스 프로토콜입니다. 이 프로토콜은 다양한 도구와 호환되는 통신 표준을 제공하며, 에이전트 애플리케이션의 대규모 언어 모델(LLM)이 표준 메커니즘을 사용하여 기업 API나 외부 도구에 연결하는 데 사용될 수 있습니다. 그러나 금융 서비스와 같은 대규모 기업 조직은 복잡한 데이터 거버넌스와 운영 모델을 가지고 있어 MCP를 활용하는 에이전트를 구현하기 어렵습니다.

주요 문제 중 하나는 개별 팀이 자체 도구를 구축하는 사일로식 접근 방식으로, 이는 노력의 중복과 자원 낭비로 이어집니다. 이러한 접근 방식은 혁신을 늦추고 통합 및 기업 설계의 불일치를 초래합니다. 또한 팀 간에 여러 개의 연결되지 않은 MCP 도구를 관리하는 것은 AI 이니셔티브를 효과적으로 확장하기 어렵게 만듭니다. 이러한 비효율성은 기업이 포스트 트레이딩 처리, 고객 서비스 자동화 및 규제 준수와 같은 작업에 생성형 AI를 완전히 활용하는 것을 방해합니다.

이 게시물에서는 Amazon Bedrock을 사용한 중앙 집중식 MCP 서버 구현을 소개합니다. 이 구현은 도구와 리소스에 대한 공유 액세스를 제공하는 혁신적인 접근 방식을 제공합니다. 이 접근 방식을 통해 팀은 도구 개발이나 유지 관리에 시간을 소비하는 대신 AI 기능 구축에 집중할 수 있습니다. MCP를 통해 리소스와 도구에 대한 액세스를 표준화함으로써 조직은 AI 에이전트 개발을 가속화하여 팀이 더 빠르게 프로덕션에 도달할 수 있습니다. 또한 중앙 집중식 접근 방식은 일관성과 표준화를 제공하고 도구가 개별 팀이 아닌 전담 팀에 의해 관리되기 때문에 운영 오버헤드를 줄입니다. 또한 MCP 서버에 대한 통제된 액세스를 시행하는 중앙 집중식 거버넌스를 가능하게 하여 데이터 유출 위험을 줄이고 조직 전체에서 승인되지 않거나 안전하지 않은 도구 사용을 방지합니다.

솔루션 개요

다음 그림은 컴플라이언스, 트레이딩, 운영 및 리스크 관리와 같은 여러 사업부(LoB)에 걸쳐 MCP 서버를 사용하는 금융 서비스 사용 사례를 기반으로 한 제안 솔루션을 보여줍니다. 각 사업부는 특정 비즈니스에 맞춤화된 고유한 기능을 수행합니다. 예를 들어, 트레이딩 사업부는 거래 실행에 중점을 두는 반면, 리스크 사업부는 리스크 한도 확인을 수행합니다. 이러한 기능을 수행하기 위해 각 부서는 해당 사업부 내에서 작업 및 관련 데이터에 대한 액세스를 용이하게 하는 MCP 서버 세트를 제공합니다. 이러한 서버는 각 사업부 내에서 개발된 에이전트가 접근할 수 있으며, 사업부 외부의 에이전트에게도 노출될 수 있습니다.

MCP 서버의 개발은 분산화되어 있습니다. 각 사업부는 자신의 특정 기능을 지원하는 서버를 개발할 책임이 있습니다. 서버 개발이 완료되면 중앙에서 호스팅되고 모든 사업부에서 접근할 수 있게 됩니다. 이는 공유 리소스에 대한 통제와 거버넌스를 유지하면서 부서 간 AI 기반 솔루션의 통합을 용이하게 하는 레지스트리 또는 마켓플레이스 형태를 취합니다.

다음 섹션에서는 개념적 수준에서 이 솔루션이 어떤 모습인지 살펴보겠습니다.

에이전트 기반 시스템과 중앙 MCP 서버 허브 간의 상호작용

다음 흐름도는 Amazon Bedrock을 사용하여 구축된 에이전트 애플리케이션이 MCP 서버 허브에 위치한 MCP 서버 중 하나와 어떻게 상호작용하는지 보여줍니다.

이 흐름은 다음 단계로 구성됩니다.

애플리케이션은 로드 밸런서를 통해 중앙 MCP 허브에 연결하고 특정 MCP 서버에서 사용 가능한 도구 목록을 요청합니다. 이는 에이전트 애플리케이션이 접근할 수 있는 서버에 따라 세분화될 수 있습니다.
트레이드 서버는 도구 이름, 설명 및 필요한 입력 매개변수와 같은 세부 정보를 포함한 사용 가능한 도구 목록으로 응답합니다.
에이전트 애플리케이션은 Amazon Bedrock 에이전트를 호출하고 사용 가능한 도구 목록을 제공합니다.
이 정보를 사용하여 에이전트는 주어진 작업과 사용 가능한 도구 목록을 기반으로 다음에 수행할 작업을 결정합니다.
에이전트는 가장 적합한 도구를 선택하고 도구 이름과 입력 매개변수로 응답합니다. 제어권은 에이전트 애플리케이션으로 돌아옵니다.
에이전트 애플리케이션은 도구 이름과 입력 매개변수를 사용하여 MCP 서버를 통해 도구 실행을 요청합니다.
트레이드 MCP 서버는 도구를 실행하고 실행 결과를 애플리케이션에 반환합니다.
애플리케이션은 도구 실행 결과를 Amazon Bedrock 에이전트에게 다시 전달합니다.
에이전트는 도구 실행 결과를 관찰하고 다음 단계를 결정합니다.

이제 솔루션의 기술 아키텍처를 자세히 살펴보겠습니다.

아키텍처 개요

다음 다이어그램은 사업부(LoB)를 위한 중앙 집중식 MCP 서버 클러스터를 호스팅하는 아키텍처를 보여줍니다.

이 아키텍처는 다섯 개의 섹션으로 나눌 수 있습니다.

MCP 서버 디스커버리 API
에이전트 애플리케이션
중앙 MCP 서버 허브
도구 및 리소스

각 섹션을 자세히 살펴보겠습니다.

MCP 서버 디스커버리 API – 이 API는 다양한 MCP 서버를 발견하기 위한 전용 엔드포인트입니다. 여러 팀은 이 API를 호출하여 레지스트리에서 사용 가능한 MCP 서버를 찾고, 설명, 도구 및 리소스 세부 정보를 읽어 어떤 MCP 서버가 자신의 에이전트 애플리케이션에 적합한지 결정할 수 있습니다. 새로운 MCP 서버가 게시되면 Amazon DynamoDB 데이터베이스에 추가됩니다. MCP 서버 소유자는 레지스트리 정보를 최신 상태로 유지할 책임이 있습니다.
에이전트 애플리케이션 – 에이전트 애플리케이션은 Amazon Elastic Container Service(Amazon ECS)용 AWS Fargate에서 호스팅되며 Amazon Bedrock Agents를 사용하여 구축됩니다. 팀은 또한 새롭게 출시된 오픈 소스 AWS Strands Agents SDK 또는 다른 선택 가능한 에이전트 프레임워크를 사용하여 에이전트 애플리케이션을 구축하고 에이전트 애플리케이션을 호스팅하기 위한 자체 컨테이너화된 솔루션을 만들 수 있습니다. 에이전트 애플리케이션은 보안 프라이빗 가상 프라이빗 클라우드(VPC) 엔드포인트를 통해 Amazon Bedrock에 액세스합니다. MCP 서버에 액세스하기 위해 프라이빗 VPC 엔드포인트를 사용합니다.
중앙 MCP 서버 허브 – 여기에 MCP 서버가 호스팅됩니다. 서버에 대한 액세스는 AWS Network Load Balancer를 통해 이루어집니다. 기술적으로, 각 서버는 Amazon ECS에서 호스팅되는 Docker 컨테이너이지만, 자체 컨테이너 배포 솔루션을 선택할 수도 있습니다. 이러한 서버는 다른 서버에 영향을 주지 않고 개별적으로 확장할 수 있습니다. 이 서버들은 다시 프라이빗 VPC 엔드포인트를 사용하여 하나 이상의 도구에 연결됩니다.
도구 및 리소스 – 이 구성 요소는 데이터베이스, 다른 애플리케이션, Amazon Simple Storage Service(Amazon S3) 또는 기타 도구와 같은 도구를 보유합니다. 기업의 경우, 도구 및 리소스에 대한 액세스는 오직 프라이빗 VPC 엔드포인트를 통해서만 제공됩니다.

솔루션의 이점

이 솔루션은 다음과 같은 주요 이점을 제공합니다.

확장성과 복원력 – Fargate에서 Amazon ECS를 사용하기 때문에 인프라를 관리하거나 확장 문제를 처리할 필요 없이 즉시 확장성을 확보할 수 있습니다. Amazon ECS는 실패한 MCP 서버 태스크를 로컬에서 재시작하거나 컨테이너를 재프로비저닝하여 자동으로 장애를 감지하고 복구함으로써 다운타임을 최소화합니다. 또한 비정상 가용 영역에서 트래픽을 리디렉션하고 정상 가용 영역 간에 태스크를 재분배하여 서버에 대한 중단 없는 액세스를 제공할 수 있습니다.
보안 – MCP 서버에 대한 액세스는 PrivateLink와 같은 네트워크 제어를 통해 네트워크 수준에서 보호됩니다. 이를 통해 에이전트 애플리케이션이 조직에서 호스팅하는 신뢰할 수 있는 MCP 서버에만 연결되도록 하고, 반대로도 마찬가지입니다. 각 Fargate 워크로드는 격리된 환경에서 실행됩니다. 이는 태스크 간의 리소스 공유를 방지합니다. 애플리케이션 인증 및 권한 부여를 위해, 우리는 MCP 인증 서버(다음 GitHub 저장소 참조)를 사용하여 이러한 작업을 독립적으로 확장할 수 있는 전용 구성 요소에 위임할 것을 제안합니다.

이 글을 작성하는 시점에서 MCP 프로토콜은 사용자 수준의 액세스 제어나 권한 부여를 위한 내장 메커니즘을 제공하지 않습니다. 사용자별 액세스 제한이 필요한 조직은 MCP 프로토콜 위에 추가 보안 계층을 구현해야 합니다. 참조 구현을 위해서는 다음 GitHub 저장소를 참조하세요.

이제 이 솔루션의 구현에 대해 더 자세히 알아보겠습니다.

사용 사례

이 구현은 포스트 트레이드 실행을 특징으로 하는 금융 서비스 사용 사례를 기반으로 합니다. 포스트 트레이드 실행은 고객이 주식 매수/매도 주문을 한 후에 발생하는 프로세스와 단계를 말합니다. 이는 거래 세부 정보 확인, 실제 자산 이전, 실행에 대한 상세 보고서 제공, 사기 검사 실행 등 많은 단계를 포함합니다. 데모의 단순화를 위해 우리는 주문 실행 단계에 초점을 맞춥니다.

이 사용 사례는 금융 산업에 맞춤화되어 있지만, 이 아키텍처와 접근 방식을 다른 기업 워크로드에도 적용할 수 있습니다. 이 구현의 전체 코드는 GitHub에서 확인할 수 있습니다. 우리는 이 솔루션을 배포하기 위해 Python용 AWS Cloud Development Kit(AWS CDK)를 사용하여 MCP 서버를 통해 도구에 연결된 에이전트 애플리케이션을 생성합니다. 또한 에이전트 애플리케이션과 상호작용할 수 있는 Streamlit UI를 생성합니다.

다음 코드 스니펫은 MCP 디스커버리 API에 대한 접근을 제공합니다.

def get_server_registry():
    # Initialize DynamoDB client
    dynamodb = boto3.resource('dynamodb')
    table = dynamodb.Table(DDBTBL_MCP_SERVER_REGISTRY)
    
    try:
        # Scan the table to get all items
        response = table.scan()
        items = response.get('Items', [])
        
        # Format the items to include only id, description, server
        formatted_items = []
        for item in items:
            formatted_item = {
                'id': item.get('id', ''),
                'description': item.get('description', ''),
                'server': item.get('server', ''),
            }
            formatted_items.append(formatted_item)
        
        # Return the formatted items as JSON
        return {
            'statusCode': 200,
            'headers': cors_headers,
            'body': json.dumps(formatted_items)
        }
    except Exception as e:
        # Handle any errors
        return {
            'statusCode': 500,
            'headers': cors_headers,
            'body': json.dumps({'error': str(e)})
        }

위 코드는 AWS Lambda 함수를 통해 호출됩니다. 전체 코드는 GitHub 저장소에서 확인할 수 있습니다. 다음 그래픽은 디스커버리 API의 응답을 보여줍니다.

사용자가 “USD 186에 AMZN 주식 100주를 구매하여 A31과 B12 계좌에 균등하게 분배해주세요.”라는 질문을 제출하는 시나리오를 살펴보겠습니다. 이 작업을 실행하기 위해 에이전트 애플리케이션은 트레이드 실행 MCP 서버를 호출합니다. 다음 코드는 트레이드 실행을 위한 MCP 서버의 샘플 구현입니다:

from fastmcp import FastMCP
from starlette.requests import Request
from starlette.responses import PlainTextResponse
mcp = FastMCP("server")

@mcp.custom_route("/", methods=["GET"])
async def health_check(request: Request) -> PlainTextResponse:
    return PlainTextResponse("OK")

@mcp.tool()
async def executeTrade(ticker, quantity, price):
    """
    Execute a trade for the given ticker, quantity, and price.
    
    Sample input:
    {
        "ticker": "AMZN",
        "quantity": 1000,
        "price": 150.25
    }
    """
    # Simulate trade execution
    return {
        "tradeId": "T12345",
        "status": "Executed",
        "timestamp": "2025-04-09T22:58:00"
    }
    
@mcp.tool()
async def sendTradeDetails(tradeId):
    """
    Send trade details for the given tradeId.
    Sample input:
    {
        "tradeId": "T12345"
    }
    """
    return {
        "status": "Details Sent",
        "recipientSystem": "MiddleOffice",
        "timestamp": "2025-04-09T22:59:00"
    }
if __name__ == "__main__":
    mcp.run(host="0.0.0.0", transport="streamable-http")

전체 코드는 다음 GitHub 저장소에서 확인할 수 있습니다.

다음 그래픽은 MCP 서버 실행을 보여줍니다.

이것은 배포 단계에 초점을 맞춘 사용 사례의 샘플 구현입니다. 프로덕션 시나리오의 경우, 실행을 모니터링하고 트레이드 실행의 다양한 단계에서 입력을 제공하기 위한 인간 감독 워크플로우를 추가할 것을 강력히 권장합니다.

이제 이 솔루션을 배포할 준비가 되었습니다.

사전 요구 사항

이 솔루션의 사전 요구 사항은 GitHub 저장소의 README.md에서 확인할 수 있습니다.

솔루션 배포

이 솔루션을 실행하려면 다음 단계를 완료하세요.

GitHub 저장소의 README.md 파일로 이동하여 솔루션 배포 지침을 확인하세요. 배포를 완료하려면 이 단계를 따르세요.

성공적인 배포는 다음 스크린샷과 유사한 메시지와 함께 종료됩니다.

배포가 완료되면 Streamlit 애플리케이션에 액세스하세요.

터미널 출력에서 다음 스크린샷과 유사한 Streamlit URL을 찾을 수 있습니다.

브라우저에서 Streamlit 애플리케이션의 URL을 입력하여 애플리케이션 콘솔을 엽니다.

애플리케이션 콘솔의 왼쪽 창 MCP 서버 레지스트리 아래에 다양한 MCP 서버 세트가 나열되어 있습니다. 각 세트는 MCP 서버에 해당하며 이름, 설명, 입력 매개변수와 같은 도구의 정의를 포함합니다.

오른쪽 창 에이전트 앱에는 “USD 186에 AMZN 주식 100주를 구매하여 A31과 B12 계좌에 균등하게 분배해주세요.”라는 요청이 미리 채워져 있습니다. 이 요청은 에이전트에게 실행을 위해 제출할 준비가 되어 있습니다.

Submit을 선택하여 요청을 처리할 Amazon Bedrock 에이전트를 호출합니다.

에이전트 애플리케이션은 요청과 액세스할 수 있는 도구 목록을 함께 평가하고, 요청을 이행하기 위해 일련의 도구 실행과 평가를 반복합니다. 추적 출력을 통해 에이전트가 사용한 도구를 확인할 수 있습니다. 사용된 각 도구에 대해 입력 매개변수 값과 해당 결과를 볼 수 있습니다. 이 경우 에이전트는 다음과 같이 작동했습니다.

에이전트는 먼저 ticker=AMZN, quantity=100, price=186의 입력 매개변수로 executeTrade 함수를 사용했습니다.
거래가 실행된 후, allocateTrade 도구를 사용하여 두 포트폴리오 계좌 간에 거래 포지션을 할당했습니다.

리소스 정리

이 솔루션에서 사용된 서비스를 소비할 때 요금이 발생합니다. 리소스를 정리하는 방법에 대한 지침은 GitHub 저장소의 README.md에서 확인할 수 있습니다.

결론

이 솔루션은 AWS에서 MCP 서버를 구현하기 위한 간단하고 기업 환경에 적합한 접근 방식을 제공합니다. 이러한 중앙 집중식 운영 모델을 통해 팀은 MCP 서버를 유지 관리하는 대신 애플리케이션 구축에 집중할 수 있습니다. 기업들이 계속해서 에이전트 워크플로우를 도입함에 따라, 중앙 집중식 MCP 서버는 운영 사일로와 비효율성을 극복하기 위한 실용적인 솔루션을 제공합니다. AWS의 확장 가능한 인프라와 Amazon Bedrock Agents 및 Amazon ECS와 같은 고급 도구를 통해 기업은 더 스마트한 워크플로우와 향상된 고객 성과를 향한 여정을 가속화할 수 있습니다.

GitHub 저장소를 확인하여 자신의 AWS 환경에서 이 솔루션을 구성해보세요.

AWS에서 MCP 서버를 실행하는 방법에 대해 자세히 알아보려면 다음 리소스를 참조하세요.

AWS 기술 블로그