Discover tools at runtime with AWS Agent Registry

🖼️ 인포그래픽

🖼️ 4컷 인포그래픽

💡 한 줄 요약

AWS Agent Registry는 승인된 MCP 서버와 A2A 에이전트를 실행 시점에 검색해 요청별로 활용하도록 지원하며, 연결 메타데이터 제공과 호출 자격 증명 관리를 분리한다.

📌 핵심 요약

• 기업 내부 API가 수백 개로 늘어나면 도구를 하드코딩하는 방식은 도구 이름 구분에 드는 토큰과 기능 추가에 따른 코드 변경·재배포 부담을 키울 수 있다.
• 샘플은 Discover → Instantiate → Execute 흐름으로 AWS Agent Registry를 검색하고, MCP 또는 A2A 클라이언트를 생성한 뒤 발견된 기능만 가진 임시 내부 에이전트로 요청을 처리한다.
• AWS Agent Registry는 연결 메타데이터와 프로토콜 설명자를 반환하지만 호출 자격 증명이나 인증 방식은 반환하지 않는다. 샘플은 MCP 호출에 별도로 얻은 Cognito OAuth 토큰을, A2A 호출에 IAM으로 인증하는 boto3 요청을 사용한다.
• 수동 승인 구성에서 레코드는 DRAFT → PENDING_APPROVAL → APPROVED 단계를 거치며, 승인된 레코드만 검색 가능한 데이터 플레인에 노출된다.
• 검색은 키워드와 의미 기반 검색을 결합한다. 샘플은 주문 상태, 가격·할인, 반품·환불의 세 시나리오를 보여주지만, 카탈로그 확대만으로 검색 순위가 개선된다고 주장하지는 않는다.

🧩 주요 포인트

1. 도구 연결을 실행 시점 검색으로 전환 → 기능 추가에 따른 오케스트레이터 코드 변경과 재배포 의존도를 줄이는 접근이다.
2. 승인된 연결 메타데이터와 별도 자격 증명 경로를 결합 → 검색 허용 여부와 실제 MCP·A2A 호출 인증을 각각 관리해야 한다.
3. 요청별 도구 구성과 의미 기반 검색을 결합 → 도구 선택 범위를 좁힐 수 있지만, 설명의 구별 가능성과 대표 질의를 통한 검색 품질 검증이 중요하다.

🧠 상세 정리

1. 하드코딩된 도구 연결의 확장 문제

원문은 에이전트 데모에서 잘 드러나지 않는 문제로 도구 목록의 확장을 제시하며, 몇 개의 도구에서는 무난한 하드코딩 방식이 수십 개부터 약해지고 그 이상에서는 관리하기 어려워진다고 설명한다. 기업 시스템은 가격, 고객 지원, 주문, 재고, 고객 데이터에 관한 내부 API를 수백 개 제공할 수 있으며, 모델이 사용자 요청을 추론하기보다 도구 이름을 구별하는 데 더 많은 토큰을 쓸 수도 있다. 새 기능을 추가할 때마다 오케스트레이터 코드 수정과 재배포, 여러 팀의 릴리스 조율이 필요하다는 점도 부담이다. 이러한 병목은 내부 API를 에이전트에 제공하는 기업용 SaaS 환경에서도 나타날 수 있다. 제안하는 접근은 모든 도구를 빌드 시점에 연결하는 대신, 실행 시점에 필요한 도구를 검색하도록 오케스트레이터의 접근 방식을 바꾸는 것이다.

2. 발견·생성·실행으로 나눈 요청 처리

AWS Agent Registry는 MCP 서버, 에이전트, 에이전트 스킬을 등록하고 검색하는 관리형 서비스이며, 게시자는 검색 가능한 설명과 프로토콜별 설명자를 등록한다. 샘플의 오케스트레이터는 도구나 에이전트의 연결 정보를 미리 내장하지 않고, 자연어 질의로 승인되어 검색 가능한 레코드를 찾는다. 검색 응답에는 레코드 식별 정보, 이름, 설명, 유형, 상태, 버전과 MCP 서버 메타데이터 또는 A2A 에이전트 카드 같은 설명자가 포함된다. 이후 설명자 유형에 맞는 클라이언트를 생성하고, 발견된 도구만 포함하는 임시 내부 에이전트가 요청을 처리하며 결과를 사용자에게 종합해 전달한다. 요청이 끝나면 내부 에이전트와 클라이언트를 정리하고, 다음 요청에서는 검색과 도구 구성을 새로 수행하는 것이 Discover → Instantiate → Execute 흐름의 핵심이다.

3. 참조 아키텍처와 세 가지 데모

샘플의 참조 아키텍처는 AWS Agent Registry, Amazon Bedrock AgentCore Gateway, Amazon Bedrock AgentCore runtime, Amazon Bedrock, Amazon Cognito, AWS Lambda, AWS Secrets Manager로 구성된다. Gateway는 주문 관리 Lambda 도구를 MCP 서버로 노출하고, runtime은 오케스트레이터와 Pricing 및 Customer Support A2A 에이전트를 호스팅한다. Amazon Bedrock은 오케스트레이터와 A2A 에이전트가 사용하는 기반 모델을 제공하며, 샘플은 현재 교차 리전 모델 ID를 통해 Anthropic Claude Sonnet 모델을 설정한다. 첫 데모는 주문 상태를 조회하는 MCP 단독 호출이고, 두 번째는 가격과 할인을 처리하기 위해 MCP와 A2A를 연결하는 경우다. 세 번째는 반품·환불이라는 단어가 대응하는 A2A 에이전트 이름에 없더라도 사용자 의도를 설명과 의미적으로 연결해 검색하는 상황을 보여준다.

4. 레코드와 프로토콜 설명자의 등록

Registry 레코드는 검색용 설명과 프로토콜별 설명자로 구성되며, 샘플은 레지스트리와 레코드의 수명 주기 작업에는 제어 플레인 클라이언트를, 실행 시점 검색에는 데이터 플레인 클라이언트를 사용한다. 레코드 생성 시 recordType은 필수이며, MCP 서버에는 MCP를, A2A 기반 에이전트에는 AGENT를 사용하고 프로토콜 메타데이터는 descriptors 아래의 mcpServer 또는 a2aAgentCard에 저장한다. MCP 설명자는 서버 메타데이터와 도구 정의를 담으며, 예시의 스키마 버전은 각각 2025-12-11과 2025-06-18이고 A2A 에이전트 카드는 0.3을 사용한다. 이러한 설명자는 연결에 필요한 데이터를 제공하지만 소비자가 호출 시 제시해야 할 자격 증명을 포함하지 않는다. 검색용 설명은 사용자 관점의 언어로 작성하면서 인접한 레코드와 기능을 구별해야 하며, 설명자에 담기는 프로토콜 데이터와 역할을 나누어 이해해야 한다.

5. 수동 승인과 검색 노출의 통제

샘플은 자동 승인 규칙이 비어 있는 레지스트리를 생성하며, 수동 승인 구성에서는 새 레코드가 DRAFT에서 PENDING_APPROVAL을 거쳐 APPROVED로 이동해야 한다. 승인 요청 제출과 상태 변경은 IAM으로 권한을 확인하므로, 기능을 게시하는 주체와 승인하는 주체의 권한을 분리할 수 있다. 제시된 코드는 먼저 레코드 상태를 읽고 DRAFT이면 승인을 요청한 다음, 상태를 APPROVED로 갱신하는 두 단계 전환을 보여준다. 검색 가능한 Registry 데이터 플레인에는 구성된 승인 절차를 완료한 레코드만 반환되므로, 등록만으로 곧바로 검색 대상이 되는 구조는 아니다. 이 승인 흐름은 어떤 기능을 발견하도록 허용할지 통제하는 장치이며, 발견된 기능을 실제로 호출할 때 필요한 자격 증명은 별도 경로에서 확보한다는 원칙과 함께 작동한다.

6. 혼합 검색과 검색 품질의 해석

데이터 플레인은 검색 가능한 레코드를 대상으로 키워드와 의미 기반 검색을 결합하며, 원문이 제시하는 최신 메서드 이름은 search_discoverable_registry_records이다. 검색 응답은 정규화된 레코드 필드와 검색 가능한 설명자를 제공하고, 예시 검색 코드는 최대 3개 결과를 요청하지만 오케스트레이터의 핵심 루프는 최대 5개를 요청한다. 반품·환불 질의가 Customer Support Agent를 찾는 데모에서는 에이전트 이름보다 설명에 담긴 의도가 검색 연결의 근거가 된다. 다만 원문은 이를 데모 결과로 한정하며, 카탈로그가 커지기만 하면 검색 순위가 좋아진다는 일반적 주장으로 해석하지 말라고 명시한다. 따라서 사용자 언어로 기능을 구별하는 설명을 작성하고 대표 질의로 검색 품질을 평가하는 과정이 중요하며, 결과 수 설정만으로 적절한 기능 선택이 보장된다고 볼 근거는 제시되지 않는다.

7. 설명자에 따른 클라이언트 생성과 인증

오케스트레이터는 검색된 레코드의 설명자를 해석해 MCP 또는 A2A 클라이언트를 만들지만, 검색 응답에서 호출 자격 증명이나 인증 방식을 얻지는 않는다. 샘플의 MCP 서버는 먼저 AgentCore Gateway의 대상으로 추가한 도구를 나타내므로, MCP 설명자가 가리키는 주소는 Gateway 엔드포인트다. 애플리케이션은 신뢰할 수 있는 별도 설정 경로에서 Cognito OAuth 액세스 토큰을 가져와 MCPClient 생성에 사용하며, Gateway는 인바운드 호출에 Cognito JWT 인증을 적용하고 자신의 IAM 역할로 Lambda 대상을 호출한다. A2A 레코드는 AgentCore runtime 엔드포인트를 식별하는 URL이 포함된 에이전트 카드를 제공한다. A2A 래퍼는 boto3 데이터 플레인 클라이언트를 통해 해당 runtime을 호출하고 호출자의 AWS 자격 증명으로 요청에 서명하므로, 연결 메타데이터 검색과 인증 정보 적용은 별개의 단계다.

8. 요청별 내부 에이전트의 구성과 자료 범위

AgentCore runtime에 배포된 Strands 오케스트레이터는 discover_and_execute를 노출하며, 이 함수는 Registry 검색, 설명자 해석, MCP·A2A 클라이언트 생성과 요청 범위 내부 에이전트 실행을 연결한다. 제공된 코드에서 MCP 클라이언트는 시작된 뒤 도구 목록을 가져오고, 내부 에이전트는 이 MCP 도구와 A2A 도구를 합친 목록 및 BedrockModel로 구성된다. 시스템 프롬프트는 주문 조회·상태·취소·주소 변경에는 MCP 도구를, 가격·할인·프로모션 코드에는 pricing_agent를, 반품·환불·불만·에스컬레이션에는 customer_support_agent를 사용하도록 안내한다. 본문은 요청 종료 후 내부 에이전트와 클라이언트를 정리한다고 설명하지만, 제공된 마지막 코드 블록은 ret 부분에서 끊겨 있어 반환과 정리 구현 전체를 확인할 수는 없다. 샘플 디렉터리에는 배포 스크립트와 orchestrator_agent.py, 설명자 해석 및 클라이언트 생성을 담당하는 utils.py, 자원 제거용 cleanup.py가 있다고 안내되어 있다.

🧾 핵심 주장 / 시사점

• 실행 시점 검색은 도구 연결을 오케스트레이터 코드에 고정하는 부담을 줄이는 접근이지만, 등록·승인·설명 품질이 통합 과정의 중요한 조건이 된다.
• Registry에서 발견할 수 있다는 사실과 실제 호출 권한을 갖췄다는 사실은 구별된다. 승인 흐름과 별도 자격 증명 경로가 함께 마련되어야 샘플의 호출 구조가 성립한다.
• 반품·환불 데모는 설명에 담긴 사용자 의도를 활용하는 검색의 가능성을 보여주며, 검색 정확도의 일반화에는 대표 질의를 통한 별도 평가가 필요하다.

✅ 액션 아이템

• 기업 내부 API가 수백 개로 늘어나는 환경에서 실행 시점 검색이 오케스트레이터 코드 변경·재배포 부담을 줄일 수 있는지 검토한다.
• DRAFT → PENDING_APPROVAL → APPROVED 승인 흐름과 MCP의 Cognito OAuth 토큰, A2A의 IAM 호출 인증을 각각 확인한다.
• 주문 상태, 가격·할인, 반품·환불을 대표 질의로 삼아 의미 기반 검색과 설명의 구별 가능성을 평가한다.

❓ 열린 질문

• 실행 시점 검색으로 전환하면 기업 내부 API가 수백 개인 환경에서 오케스트레이터 코드 변경과 재배포 부담을 얼마나 줄일 수 있는가?
• DRAFT → PENDING_APPROVAL → APPROVED 승인 흐름과 별도 자격 증명 경로는 MCP·A2A 호출 과정에서 어떻게 함께 관리되는가?
• 주문 상태, 가격·할인, 반품·환불의 대표 질의에서 의미 기반 검색은 필요한 기능을 얼마나 일관되게 찾아내는가?