Serverless MCP server for AI agent data lake access on Amazon ECS Fargate

🖼️ 인포그래픽

🖼️ 4컷 인포그래픽

💡 한 줄 요약

Amazon NASC 팀은 Amazon ECS와 AWS Fargate 기반의 서버리스 MCP 서버를 구축해 AI 에이전트의 데이터 레이크 접근을 중앙화하고, JSON 메타데이터로 신규 데이터셋을 연결하는 구조를 제시한다.

📌 핵심 요약

• Amazon의 North America Sort Center(NASC) 지원 팀은 수천 개 데이터셋에 대한 에이전트별 SQL 생성·스키마 관리·연결 처리 중복과 분산된 접근 제어, 테이블마다 통상 며칠이 걸리는 온보딩 문제를 해결하고자 공통 MCP 게이트웨이를 구축했다.
• 아키텍처는 클라이언트, MCP 서버, 도구, 지식 베이스 갱신의 네 계층으로 구성된다. Amazon ECS와 AWS Fargate에서 클라이언트와 MCP 서버를 분리하고, Amazon Cognito로 인증하며 Amazon DynamoDB에 세션과 대화 상태를 저장한다.
• FastMCP 기반 /mcp 엔드포인트는 MCP 호환 클라이언트에 도구를 제공한다. Amazon Bedrock이 도구 실행을 조율하며, Amazon Athena·Amazon Redshift는 SQL 질의를, Amazon Bedrock Knowledge Bases는 문서·메타데이터·운영 정책의 의미 검색을 담당한다.
• 신규 데이터셋은 스키마·업무 맥락·열 설명·샘플 값을 담은 JSON 메타데이터로 등록한다. 파이프라인이 Amazon Titan Text Embeddings로 임베딩을 생성하고 Amazon Bedrock Knowledge Bases에 색인하면, 연결된 에이전트가 수동 재색인이나 서버 재시작 없이 해당 테이블을 발견할 수 있다.
• 선택적 컨텍스트 매핑은 검색 대상을 관련 테이블로 제한하며, 원문 팀의 테스트에서는 이러한 범위 제한으로 전체 상호작용 지연을 15–20초 수준으로 유지했다. Amazon Bedrock Guardrails는 모든 LLM 상호작용에 적용되고, Athena 도구는 SELECT 전용 제약으로 쓰기 작업을 거부한다.

🧩 주요 포인트

1. 테이블마다 작성하던 통합 코드를 JSON 메타데이터와 공통 MCP 도구로 대체함으로써, 데이터셋 확장이 개별 에이전트의 코드 수정·재배포에 의존하는 부담을 줄이는 구조다.
2. 클라이언트와 MCP 서버의 실행을 분리하고 대화 상태를 Amazon DynamoDB에 저장하므로, AWS Fargate 태스크를 교체하거나 확장하면서도 대화를 이어갈 수 있다.
3. 컨텍스트 매핑, Amazon Bedrock Guardrails, Athena의 SELECT 전용 제약은 각각 검색 범위, 모델 상호작용, 데이터 쓰기를 다룬다. SQL 정확도와 지연 개선, 공통 안전 정책, 쓰기 차단을 서로 다른 지점에서 지원한다.

🧠 상세 정리

1. 분산된 데이터 접근과 구축 목표

원문은 AI 애플리케이션이 기업 데이터 레이크에 접근할 때 에이전트마다 통합 로직을 반복 구현하는 문제에서 출발한다. Amazon의 North America Sort Center(NASC) 지원 팀이 다루는 데이터 레이크에는 운영 지표, 비즈니스 분석, 도메인별 정보를 포함한 수천 개 데이터셋이 있으며, 계획 담당자는 이를 용량·인력·패키지 흐름 관리에 활용한다. 각 팀이 별도로 만든 에이전트는 SQL 생성, 스키마 지식, 연결 처리를 자체 구현했기 때문에 스키마가 바뀌면 여러 에이전트를 각각 수정해야 했다. 접근 제어도 분산되어 데이터 접근 판단을 감사할 단일 지점이 없었고, 신규 테이블 연결에는 도구 코드 작성과 질의 검증, 재배포로 통상 며칠이 필요했다. 이에 팀은 설정 기반 데이터 접근, MCP 호환 클라이언트가 공유하는 도구 인터페이스, MCP 서버 계층의 중앙 권한 집행, 급증하는 AI 작업량에 대응하는 탄력적 인프라를 설계 목표로 정했다.

2. 네 계층으로 분리한 서버리스 아키텍처

제안된 구조는 클라이언트, MCP 서버, 도구, 지식 베이스 갱신의 네 계층을 분리하며, 각 계층을 독립적으로 배포하고 확장할 수 있도록 설계한다. 도구 계층의 기반인 메타데이터 카탈로그에는 스키마 설명, 열별 의미, 테이블 관계가 저장되고, 에이전트는 SQL을 생성할 때 이 정보를 조회한다. 따라서 테이블 구조를 에이전트 코드에 고정하지 않고 카탈로그에서 스키마 지식을 얻으며, 갱신 계층은 새 데이터셋의 메타데이터를 색인해 카탈로그를 최신 상태로 유지한다. 외부 요청은 Amazon Route 53과 HTTPS·AWS WAF가 설정된 Application Load Balancer를 거쳐 인증 및 클라이언트 처리 단계로 진입하고, 내부 로드 밸런서를 통해 MCP 서버로 전달된다. 데이터 계층에서는 Amazon Athena와 Amazon Redshift가 SQL을 실행하고 Amazon Bedrock Knowledge Bases가 의미 검색을 담당하며, Amazon S3와 지식 베이스로의 데이터 수집에는 AWS Lambda가 사용된다.

3. 클라이언트 인증과 업무 컨텍스트에 따른 범위 제한

클라이언트 계층은 Amazon ECS Fargate에서 실행되며, Amazon Cognito를 통한 JSON Web Token(JWT) 인증과 Amazon DynamoDB 기반 세션 저장을 통합한다. 요청에 업무 맥락을 보강하는 컨텍스트 매핑 설정은 각 질의가 관련 테이블만 대상으로 삼도록 범위를 정한다. 예시에서는 package_data가 analytics_db.regional_order_summary와 operations_gold.load_summary에 연결되고, labor_planning은 workforce.capacity_details를 대상으로 한다. 컨텍스트에 테이블이 지정되면 MCP 서버는 메타데이터 카탈로그 검색을 해당 테이블로 제한해 불필요한 후보를 줄이고 SQL 생성 정확도를 높인다. 원문 팀은 테스트에서 이러한 범위 제한을 통해 전체 상호작용 지연을 15–20초 수준으로 유지했다고 설명하며, 새로운 업무 도메인은 매핑 항목을 추가하는 방식으로 연결할 수 있다고 제시한다.

4. 상태 없는 MCP 실행과 대화 상태의 유지

MCP 서버는 클라이언트 계층과 분리된 자체 ECS Fargate 클러스터에서 실행되며, 요청은 Amazon Route 53과 프라이빗 서브넷의 내부 Application Load Balancer를 통해 도달한다. 서버는 질의 분석부터 도구 선택, 실행, 응답 생성까지 전체 과정을 조율하고, FastMCP 기반 JSON-RPC 인터페이스인 /mcp 엔드포인트를 제공한다. Amazon Q Developer나 IDE 확장 같은 외부 MCP 호환 클라이언트도 이 엔드포인트를 통해 도구를 직접 발견하고 호출할 수 있다. Fargate 태스크 자체는 상태를 보유하지 않으며 대화 상태는 DynamoDB에 저장하므로, 태스크를 교체하거나 확장해도 대화 데이터를 유지할 수 있다. 요청이 들어오면 에이전트는 세션 이력을 가져와 Amazon Bedrock으로 사용자 의도를 분석하고 적절한 도구를 실행한 뒤 결과를 사용자에게 스트리밍한다.

5. 공통 도구와 메타데이터 기반 SQL 실행

도구는 FastMCP에 등록되어 실행 시점에 발견되며, SQL 질의, 문서·메타데이터 검색, 정책 검색이라는 세 가지 범주로 제시된다. SQL 도구는 Amazon Athena와 Amazon Redshift를 백엔드로 사용해 설정된 데이터셋을 조회하고, 문서·메타데이터 검색은 Amazon Bedrock Knowledge Bases에서 내부 문서와 테이블 정보, 팀 위키를 검색한다. 정책 검색 역시 Amazon Bedrock Knowledge Bases를 사용하지만 운영 정책과 표준 절차를 찾는 데 목적이 있다. 데이터 레이크의 주된 접근 수단인 Athena 도구를 사용할 때 에이전트는 먼저 메타데이터 카탈로그에서 스키마를 이해하고, Amazon Bedrock을 통해 최적화된 SQL을 생성한다. 이어 SQL의 Athena 호환성을 검증하고 자동 수정한 뒤 실행하며, 반환된 결과는 조율 역할의 에이전트가 자연어 답변으로 종합한다.

6. 모델 상호작용과 데이터 쓰기에 적용되는 통제

원문은 책임 있는 AI 통제로 Amazon Bedrock Guardrails와 Athena 도구의 읽기 전용 제약을 설명한다. Amazon Bedrock Guardrails는 모든 LLM 상호작용에 적용되며, 유해 콘텐츠 필터링과 근거성 확인을 수행하고 프롬프트 주입 시도 차단을 돕도록 설계되어 있다. 이는 모든 공격을 확실하게 막는다는 보장으로 제시된 것이 아니라, MCP 서버 계층에서 운영되는 공통 통제로 설명된다. 연결된 에이전트는 접속 방식과 관계없이 같은 콘텐츠 안전 정책을 적용받으며, 공통 서버 계층이 정책 적용 지점이 된다. 별도로 Athena 질의 도구는 SELECT 전용 규칙을 강제해 쓰기 작업이 데이터 레이크에 도달하기 전에 도구 수준에서 거부하며, 이는 모델 응답에 대한 통제와 구분되는 데이터 작업 제약이다.

7. JSON 메타데이터에 담는 스키마와 업무 의미

새 데이터셋을 연결하는 핵심 입력은 테이블 스키마와 업무 맥락, 열별 의미를 기술한 JSON 메타데이터 파일이며, 이 파일은 에이전트가 데이터셋을 이해하고 질의하는 단일 기준 정보로 쓰인다. 예시의 analytics_db.regional_order_summary에는 데이터베이스 서비스와 테이블 이름뿐 아니라 일별 갱신, 최근 7일의 증분 갱신, 약 21억 행의 테이블 크기 같은 정보도 포함된다. business_description_for_the_table에는 timestamp 열과 문자열 리터럴을 비교할 때 date()로 감싸라는 Athena 전용 힌트처럼 SQL 검증 실패를 줄이기 위한 지침을 담을 수 있다. column_details는 column_name [type] 형식의 열 이름에 자연어 설명과 샘플 값을 연결해 스키마와 업무 의미를 함께 제공한다. 특히 sample_values는 warehouse_id에 FC-EAST-07 같은 코드가 저장된다는 실제 값의 형태를 알려 주므로, 에이전트가 시설 이름을 임의로 가정하지 않고 WHERE 조건을 생성하는 데 도움이 된다.

8. 자동 색인과 선택적 컨텍스트의 결합

메타데이터 파일을 수집한 파이프라인은 Amazon Titan Text Embeddings로 벡터 임베딩을 생성하고 Amazon Bedrock Knowledge Bases에 색인한다. 색인이 완료되면 연결된 모든 에이전트가 해당 테이블을 발견할 수 있으며, 이를 위해 별도의 수동 재색인이나 서버 재시작을 할 필요는 없다고 원문은 설명한다. 특정 애플리케이션의 정확도를 높이고 싶다면 엔지니어가 데이터셋을 업무 컨텍스트와 선택적으로 연결할 수 있고, 예시의 delivery_metrics는 analytics_db.customer_orders_summary를 대상으로 한다. 컨텍스트를 지정하지 않으면 에이전트는 색인된 모든 테이블을 검색하며, 범위 제한 설정은 메타데이터 파일 자체를 수정하지 않고도 나중에 추가할 수 있다. 마지막 사례는 지난달 금액이 가장 큰 주문 10건을 묻는 요청에 대해 클라이언트가 업무 맥락을 보강하고 에이전트가 질문을 벡터화해 메타데이터를 검색하는 흐름을 보여 주지만, 제공된 본문은 그 도중에 끊겨 이후 실행 결과나 추가 확장 정책은 확인할 수 없다.

🧾 핵심 주장 / 시사점

• 이 구조에서 메타데이터는 단순한 스키마 목록을 넘어 업무 의미와 실제 값의 패턴, SQL 엔진별 힌트를 전달하는 실행 기반이다. 따라서 통합 코드의 부담을 줄이는 만큼 메타데이터 내용의 정확성이 SQL 생성 품질에 중요해진다.
• 모든 테이블을 검색할 수 있는 확장성과 관련 테이블만 검색하는 정밀도는 선택적 컨텍스트 매핑으로 조정된다. 제시된 15–20초 지연은 해당 팀의 테스트 결과이므로 다른 환경의 보편적 성능으로 해석할 수 없다.
• 중앙 MCP 서버는 공통 도구와 정책을 여러 클라이언트가 공유하는 지점이 된다. 다만 본문은 중앙 권한 집행을 목표로 제시하면서도 구체적인 권한 판정 규칙보다 인증, Guardrails, SELECT 전용 통제를 중심으로 설명한다.

✅ 액션 아이템

• 신규 데이터셋 연결 시 JSON 메타데이터에 스키마·업무 맥락·열 설명·샘플 값을 반영하고, 공통 MCP 도구를 통한 접근 가능 여부 확인.
• 컨텍스트 매핑 적용 범위에 따른 SQL 정확도와 전체 상호작용 지연을 검토하고, 원문 테스트의 15–20초 결과와 비교.
• MCP 서버의 중앙 권한 집행과 Amazon Bedrock Guardrails 적용, Athena의 SELECT 전용 제약을 각각 확인.

❓ 열린 질문

• Amazon NASC의 수천 개 데이터셋에 대해 MCP 서버는 사용자별 접근 권한을 어떤 기준으로 판정하는가?
• 컨텍스트 매핑으로 검색 범위를 제한했을 때의 15–20초 지연은 데이터셋과 동시 요청이 증가하면 어떻게 달라지는가?
• JSON 메타데이터의 스키마·열 설명·샘플 값이 실제 데이터셋과 달라졌을 때 갱신과 정확성은 어떻게 보장하는가?