AgentCore 웹 검색 GA, MCP 에이전트의 검색 API 삭제

AI 요약

• 무슨 일: AWS가 us-east-1에서 AgentCore Web Search를 GA로 열었습니다.
  • AgentCore Gateway의 MCP 커넥터로 붙고, 결과는 스니펫·출처 URL·제목·발행일을 포함합니다.
• 실무 변화: 검색 API 키, 별도 MCP 서버, 결과 파싱 코드를 줄일 수 있습니다.
• 주의점: 리전은 아직 us-east-1 중심이고, 인용 링크 유지 의무가 문서에 명시돼 있습니다.

AWS가 2026년 6월 16일 Amazon Bedrock AgentCore에 관리형 웹 검색 도구를 일반 제공(GA)으로 추가했습니다. AWS News Blog는 6월 17일 AWS Summit New York 발표 맥락에서 이 기능을 다시 소개했고, AgentCore 문서는 같은 도구를 Gateway의 커넥터 대상으로 설명합니다. 에이전트가 자연어 쿼리를 보내면 Web Search Tool은 스니펫, 출처 URL, 제목, 발행일을 돌려주고, 모델은 그 결과를 근거로 답변을 작성합니다.

이 발표가 개발팀에 닿는 지점은 검색 품질 경쟁보다 운영 경계입니다. 지금까지 에이전트에 웹 검색을 붙이려면 외부 검색 API 계약, 키 보관, 사용량 제한, 결과 형식 정규화, MCP 서버 래핑, 보안 심사를 따로 묶어야 했습니다. AgentCore Web Search는 그 일을 AgentCore Gateway 안쪽의 connectorId: "web-search"로 압축합니다. 웹 검색이 제품 기능이 아니라 인프라 권한 모델의 일부가 되는 셈입니다.

AWS가 밝힌 구조는 세 단계입니다. 첫째, 개발자는 AgentCore Gateway를 만들거나 기존 Gateway에 Web Search Tool 대상을 추가합니다. 둘째, 에이전트 런타임은 Gateway URL을 MCP 서버처럼 보고 tools/list와 도구 호출을 수행합니다. 셋째, Web Search는 Amazon이 운영하는 웹 인덱스와 Amazon Knowledge Graph를 사용해 검색 결과와 구조화된 사실을 섞어 돌려줍니다. AWS Machine Learning Blog는 이 인덱스가 수십억 개가 아니라 "수백억 문서" 규모이며, 새 콘텐츠를 분 단위로 반영한다고 설명했습니다.

외부 검색 API와 비교하면 달라지는 항목이 분명합니다.

AgentCore의 큰 그림에서 Gateway는 도구의 출입문입니다. AgentCore 개요 문서는 Runtime, Harness, Memory, Gateway, Browser, Code Interpreter, Observability, Evaluation, Policy를 독립 또는 결합 가능한 모듈로 나열합니다. Gateway는 API, Lambda 함수, MCP 서버, 내장 커넥터를 에이전트 도구로 바꾸는 위치에 있습니다. Web Search가 이 위치에 들어갔다는 말은, 웹 검색 권한이 프롬프트 안의 편의 기능이 아니라 기업 계정의 IAM, JWT, 감사 정책과 함께 다뤄진다는 뜻입니다.

문서에서 확인되는 세부 제약도 있습니다. Web Search Tool 문서는 현재 가용 리전을 US East (N. Virginia), 즉 us-east-1로 적었습니다. 응답 형식 예시는 MCP 호환 content 배열 안에 JSON 문자열로 결과 목록을 담고, 각 결과는 text, url, title, publishedDate 필드를 가질 수 있습니다. 같은 문서는 Web Search 결과를 최종 사용자에게 보여줄 때 제공된 출처 인용과 링크를 유지해야 한다고 명시합니다. 검색 결과를 대량 추출하거나 경쟁 인덱스를 만드는 데 쓰면 안 된다는 제한도 붙어 있습니다.

이 인용 의무는 제품 설계에 직접 영향을 줍니다. 에이전트가 "요약만" 내보내는 채팅 화면이라도, 검색 결과를 사용했다면 출처 URL과 링크를 표시해야 합니다. 내부 운영 도구라면 감사 로그에 어떤 검색 결과가 모델 입력으로 들어갔는지 남기는 설계가 필요합니다. 고객 대면 답변이라면 링크 표시 위치, 클릭 추적, 오래된 출처가 재사용되는 경우의 갱신 정책까지 정해야 합니다. 웹 검색을 붙였다는 사실보다 검색 결과의 출처 생애주기를 제품이 관리해야 한다는 점이 더 큽니다.

가격 메시지도 개발팀의 검토 항목입니다. AWS News Blog는 Web Search 도구 자체에는 추가 요금이 없고 Gateway 데이터 전송 요금만 낸다고 설명했습니다. 하지만 실제 비용은 검색 호출 횟수, 반환 스니펫 길이, 모델 입력 토큰, Gateway 트래픽, 후속 도구 호출이 함께 결정합니다. 검색 API 청구서가 사라져도 모델 비용과 데이터 전송 비용이 남습니다. 따라서 "무료 검색"이 아니라 "검색 사업자별 계약과 키 운영 비용을 AWS Gateway 비용 구조로 옮긴다"는 표현이 더 정확합니다.

AWS가 강조하는 차별점은 자체 인덱스입니다. What's New는 Web Search가 Amazon의 검색 인프라와 구조화된 지식 그래프 데이터를 결합한다고 설명했습니다. AWS News Blog는 그 인프라가 Alexa+, Amazon Q Business, Kiro 같은 에이전트형 검색 경험에서 축적된 것이라고 적었습니다. 이 주장은 엔터프라이즈 고객에게 두 가지 질문을 남깁니다. Amazon 인덱스의 신선도와 커버리지가 개발자 문서, 논문, 작은 오픈소스 저장소까지 충분한가. 그리고 기존에 쓰던 Google Programmable Search, Brave Search, Tavily, 자체 크롤러 대비 어떤 질의에서 결과가 좋아지는가.

아직 공개된 독립 벤치마크는 부족합니다. AWS가 말한 "분 단위 갱신"과 "수백억 문서"는 강한 주장입니다. 하지만 개발팀이 채택을 결정하려면 자사 쿼리 집합으로 재현성, 인용 정확도, 오래된 문서 노출률, 중복 결과, 비영어 결과 품질을 테스트해야 합니다. 특히 한국어 개발 문서나 국내 공공 문서처럼 검색 사업자마다 커버리지가 크게 갈리는 영역은 별도 평가가 필요합니다.

Classmethod DevelopersIO의 6월 18일 사용 후기는 이 기능의 초기 체감을 잘 보여줍니다. 작성자는 이전에는 Tavily나 Brave Search 같은 외부 검색 API를 MCP 서버로 연결해야 했지만, 이제 AgentCore Gateway 안에서 웹 검색 도구를 선택할 수 있다고 설명했습니다. 같은 글은 2026년 6월 기준 도쿄 리전은 지원하지 않고 us-east-1만 지원한다고 적었습니다. 한국이나 일본 기업이 테스트할 때 리전, 지연 시간, 데이터 거버넌스를 먼저 확인해야 하는 이유입니다.

샘플 저장소도 AWS의 의도를 보여줍니다. awslabs/agentcore-samples는 AgentCore를 프레임워크와 모델에 독립적인 운영 플랫폼으로 소개하고, Strands Agents, CrewAI, LangGraph, LlamaIndex 같은 프레임워크와 어떤 LLM도 가져올 수 있다고 설명합니다. 기능 목록에는 Gateway, Identity, Memory, Tools, Observability, Evaluation, Policy가 함께 들어갑니다. Web Search는 단독 검색 제품이 아니라 이 목록의 Tools와 Gateway 사이에 놓인 부품입니다.

개발자 관점에서 가장 유용한 변화는 책임 분리입니다. 에이전트 애플리케이션 코드는 "최신 정보를 찾아라"라는 도구 호출을 Gateway에 맡기고, Gateway는 검색 백엔드 자격 증명과 스키마 관리를 맡습니다. 모델 제공자는 OpenAI, Anthropic, Google, Amazon Nova, Meta, Mistral 중 무엇이든 될 수 있습니다. 검색 호출 권한은 모델 선택과 분리됩니다. 이 분리는 여러 모델을 번갈아 쓰는 기업에 중요합니다. 모델이 바뀌어도 웹 검색 도구의 권한, 감사, 인용 정책은 Gateway에 남기기 때문입니다.

반대로 단점도 이 구조에서 나옵니다. AgentCore를 쓰지 않는 팀에게는 Gateway 자체가 새로운 의존성입니다. 이미 Cloudflare Workers, 자체 MCP Gateway, LangGraph Platform, Vercel Functions로 도구 라우팅을 표준화한 팀은 AWS 검색 하나 때문에 운영 경로를 바꾸기 어렵습니다. 또 AgentCore Web Search가 us-east-1부터 열렸기 때문에, 데이터 주권이나 지연 시간 요건이 강한 조직은 리전 확장을 기다려야 합니다.

보안팀에는 "쿼리가 AWS 밖으로 나가지 않는다"는 문장이 강하게 들릴 수 있습니다. 그러나 쿼리가 AWS 안에 머문다는 말과, 검색 결과를 모델이 안전하게 사용한다는 말은 다릅니다. 웹 검색 결과에는 프롬프트 인젝션, 오래된 문서, 악성 페이지, 광고성 콘텐츠가 섞일 수 있습니다. Gateway는 자격 증명과 연결을 관리하지만, 검색 결과의 신뢰 점수, 도메인 제한, 답변 인용, 위험 문구 필터링은 애플리케이션 계층과 정책 계층이 함께 설계해야 합니다.

AWS 문서에 있는 도메인 차단 목록 기능은 이 지점과 연결됩니다. Web Search Tool 문서는 특정 도메인을 질의 대상에서 제외하는 설정을 안내합니다. 모든 검색을 허용하는 에이전트와 승인된 문서 사이트만 검색하는 에이전트는 위험 수준이 다릅니다. 개발팀은 사내 정책에 맞춰 공식 문서, 규제 기관, 주요 공급사 문서, 신뢰 가능한 뉴스 소스처럼 허용 범위를 나누고, 고객 답변에는 어떤 출처가 들어갔는지 남기는 편이 낫습니다.

이번 발표는 에이전트 시장의 검색 기능이 두 갈래로 나뉘는 장면입니다. 하나는 Perplexity나 Tavily처럼 검색 자체를 제품으로 제공하는 방식입니다. 다른 하나는 AWS처럼 검색을 에이전트 운영 플랫폼의 도구 커넥터로 흡수하는 방식입니다. 전자는 검색 품질과 개발자 경험을 빠르게 밀고, 후자는 계정, 리전, 감사, 권한, 비용을 한 클라우드 안에 묶습니다. 기업 에이전트에서는 두 번째 방식이 구매 절차와 보안 검토를 줄일 수 있습니다.

한국 개발팀이 바로 확인할 항목은 네 가지입니다. 첫째, 현재 워크로드가 us-east-1에서 허용되는지 확인해야 합니다. 둘째, 기존 검색 API가 제공하던 랭킹 품질과 Amazon 인덱스 결과를 같은 쿼리로 비교해야 합니다. 셋째, 최종 화면과 로그에 출처 링크를 어떻게 유지할지 정해야 합니다. 넷째, Gateway 데이터 전송, 모델 입력 토큰, 검색 호출 빈도를 합산해 실제 비용을 계산해야 합니다.

AgentCore Web Search는 화려한 모델 발표가 아닙니다. 그러나 에이전트 제품을 운영해 본 팀에는 모델보다 더 자주 부딪히는 문제가 검색 API 키, 출처 인용, 도구 권한, 리전, 비용입니다. AWS가 이 기능을 MCP 커넥터로 넣은 이유도 여기에 있습니다. 에이전트가 최신 웹을 읽는 순간, 검색은 부가 기능이 아니라 운영 책임이 됩니다. 이번 GA는 그 책임을 애플리케이션 코드 밖, Gateway 안으로 옮기는 선택지입니다.