Amazon Bedrock AgentCore Web Search: 오래된 RAG를 해결하는 아키텍처

원문은 twarx.com에서 처음 게시되었습니다 - 전체 대화형 버전은 그곳에서 읽어보세요.

최종 업데이트: 2026년 6월 19일

당신의 RAG (Retrieval-Augmented Generation) 파이프라인은 지식 시스템이 아닙니다. 그것은 달력이 따라잡기를 기다리는 슬로 모션 환각 (hallucination)일 뿐입니다. Amazon Bedrock AgentCore web search는 AI 에이전트를 단순히 개선하는 것이 아니라, 애초에 문제를 일으켰던 아키텍처적 가정을 제거합니다.

Amazon Bedrock AgentCore web search는 Amazon Bedrock AgentCore 제품군 내에 있는 AWS의 관리형 실시간 검색 (live-retrieval) 도구입니다. 이를 통해 에이전트는 스크래핑 (scraping) 인프라 없이도 최신 웹 데이터를 가져올 수 있으며, MCP, LangGraph, AutoGen, 그리고 CrewAI에 네이티브하게 연결됩니다. 이것이 지금 등장한 이유는 잔혹할 정도로 단순합니다. 에이전트가 추론하는 규제, 가격, 시장 데이터는 몇 달이 아니라 며칠 만에 구식이 되기 때문입니다.

이 가이드를 마칠 때쯤이면 여러분은 아키텍처를 이해하고, 프로덕션 에이전트를 배포하며, 실제 AWS 가격 수치를 바탕으로 쿼리당 실제 비용을 계산하고, 규모가 커질 때 정확히 무엇이 깨지는지 알게 될 것입니다.

Amazon Bedrock AgentCore web search가 에이전트의 추론 루프 (reasoning loop)와 라이브 웹 사이에 위치하는 방식 — 시간적 쇠퇴 한계 (Temporal Decay Ceiling)를 깨뜨리는 핵심 메커니즘. 출처

Amazon Bedrock AgentCore Web Search란 무엇이며 왜 중요한가

Amazon Bedrock AgentCore web search는 사용자가 크롤러(crawler), 프록시(proxy) 또는 스크래핑 파이프라인(scraping pipeline)을 직접 운영할 필요 없이, Bedrock 기반 에이전트가 실시간 웹 쿼리를 실행하고 출처가 명시된 구조화된 결과를 받을 수 있도록 지원하는 완전 관리형 서버리스(serverless) 도구입니다. AWS는 2025년 중반, 이를 더 넓은 AgentCore 제품군 내의 관리형 구성 요소로 발표했으며, 이는 단순한 추가 통합 방식이 아닌 에이전트 라이프사이클(agent lifecycle)의 핵심 구성 요소(first-class citizen)로 제공됩니다.

AWS의 AI 및 데이터 부문 부사장(VP)인 Swami Sivasubramanian은 공식 발표 블로그에서 이번 출시를 다음과 같이 정의했습니다: 에이전트에게는 '검색 인프라(retrieval infrastructure)를 유지 관리해야 하는 운영상의 부담 없이 최신 정보에 접근할 수 있는 권한'이 필요하다는 것입니다. 이 한 문장이 전체 논지의 핵심입니다. AWS가 제거한 것은 검색 기능 자체가 아니라, 바로 그 '부담'입니다.

AWS 공식 발표 해독: 출시된 기능 vs 약속된 기능

AWS 발표를 통해 제공된 세 가지 구체적인 사항은 다음과 같습니다: Bedrock Converse API를 통해 호출 가능한 관리형 웹 검색 도구, 네이티브 MCP (Model Context Protocol) 호환성, 그리고 소스 URL, 스니펫(snippet), 최신성 타임스탬프(freshness timestamp)를 포함하는 구조화된 JSON 결과입니다. 다만, 신호는 보냈으나 아직 일반 가용성(GA, General Availability) 단계에 도달하지 않은 기능들도 있습니다: 스니펫을 넘어서는 구조화된 데이터 추출(structured data extraction)과 초기 출시 지역 외의 멀티 리전(multi-region) 가용성입니다. 이 차이는 매우 중요합니다. 헤드라인만 보고 모든 구조화된 추출 기능이 출시된 것으로 오해한 팀들은 이미 기술 지원 티켓을 접수했습니다.

AgentCore Web Search가 전체 AgentCore 스택 내에서 작동하는 방식

AgentCore는 단일 제품이 아닙니다. 이는 계층화된 플랫폼입니다: Runtime (관리형 에이전트 실행), Memory (지속적인 컨텍스트), Browser (대화형, 다단계 웹 탐색), 그리고 Tools (웹 검색은 이 중 하나입니다). 웹 검색은 Tools 계층에 위치하며, 읽기 전용(read-only) 및 고빈도 사실 근거(factual grounding)에 최적화되어 있습니다. 웹 검색과 Browser Tool의 차이점은 경쟁사 가이드에서 가장 많이 오해받는 부분이며, 아래의 심층 분석에서 이를 완전히 해결해 드립니다. 공식 AgentCore 제품 페이지에서 각 계층에 대한 문서를 확인할 수 있습니다.

명명된 프레임워크

Temporal Decay Ceiling (시간적 쇠퇴 한계) — 검색 코퍼스(retrieval corpus)가 운영 컨텍스트 윈도우(context window)보다 더 오래되어, 아무리 정교한 오케스트레이션(orchestration) 계층이라도 현재의 현실을 파악하지 못하게 될 때 모든 RAG 기반 에이전트가 직면하는 성능의 물리적 한계

이는 벡터 스토어(vector store)의 마지막 갱신 시점이 쿼리가 요구하는 신선도(freshness)보다 더 오래되어 버리는 순간을 의미합니다. 그 어떤 LangGraph 오케스트레이션, 리랭킹(reranking), 또는 프롬프트 엔지니어링(prompt engineering)도 한 번도 수집(ingested)되지 않은 사실을 찾아낼 수는 없습니다.

Temporal Decay Ceiling: 2025년 6월 이전에 구축된 모든 RAG 에이전트에 만료일이 존재하는 이유

2024 Databricks State of Data + AI 보고서에 따르면, 평균적인 기업용 RAG 코퍼스는 11일에 한 번 미만으로 갱신됩니다. 이는 일상적인 운영 쿼리에 대해 구조적으로 신선도가 떨어진 상태(stale)임을 의미합니다. LangGraph와 Pinecone을 사용하는 대형 은행의 금융 컴플라이언스(compliance) 에이전트들은 규제 업데이트 후 72시간 이내에 사실적 편차(factual drift)가 발생한다고 보고했습니다. 이것이 바로 눈에 보이는 Temporal Decay Ceiling입니다. 오케스트레이션은 완벽하고, 검색은 빠르며, 답변은 틀렸습니다. 현실이 변했기 때문입니다.

저는 작년에 중견 이커머스 고객사를 위해 경쟁 정보 분석 에이전트 (competitive-intelligence agent)를 구축하면서 개인적으로 이 한계에 부딪혔습니다. 당시 저희는 LangGraph 감독관 (supervisor) 뒤에서 매일 밤 갱신되는 Pinecone 코퍼스 (corpus)를 운영하며 하루에 약 9,000건의 가격 관련 쿼리를 처리했습니다. 검색 지연 시간 (retrieval latency)은 깔끔하게 180ms였습니다. 하지만 에이전트는 매일 오후마다 여전히 틀린 답을 내놓았습니다. 경쟁사의 가격 변동은 오전 6시에 발생하는데, 저희 코퍼스는 자정이 되어서야 이를 인지했기 때문입니다. 가격 경로를 실시간 그라운딩 (live grounding)으로 교체하자, 엔드 투 엔드 (end-to-end) 데이터 신선도가 '최대 18시간 지연'에서 '4초 미만 최신' 상태로 떨어졌고, 고객사의 최저가 매칭 승률은 2주 이내에 눈에 띄게 상승했습니다. 문제는 검색이 아니었습니다. 문제는 달력이었습니다.

대부분의 팀은 환각 (hallucination) 문제가 모델의 문제라고 생각합니다. 그것은 달력의 문제입니다. 모델은 괜찮습니다. 당신의 코퍼스가 뉴스로부터 3주나 뒤처져 있을 뿐입니다.

AgentCore 웹 검색은 MCP와 네이티브하게 통합됩니다. 이는 AutoGen이나 CrewAI와 같은 오케스트레이션 레이어 (orchestration layers)가 커스텀 커넥터 (custom connectors)를 작성할 필요 없이 이를 표준화된 도구 호출 (tool call)로 호출할 수 있음을 의미합니다. 이러한 표준화 덕분에 노후된 RAG에서 벗어나는 과정은 코드 재작성이 아닌 단순한 설정 변경이 됩니다. 프로토콜에 대한 더 자세한 배경 정보는 Anthropic의 문서를 참조하세요.

<11일
평균 기업용 RAG 코퍼스 갱신 간격
[Databricks State of Data + AI, 2024](https://www.databricks.com/blog)
...

프로덕션 AI 에이전트의 현황: 무엇이 준비되었고 무엇이 여전히 실험적인가

제품을 출시하려 한다면, 어떤 기능이 SLA (Service Level Agreement)를 보장하는지, 그리고 어떤 기능이 여전히 데모 수준인지 정확히 알아야 합니다. 2025년 2분기 기준의 솔직한 현황은 다음과 같습니다.

지금 바로 프로덕션 투입 가능: 오늘날 기업 고객에게 바로 제공할 수 있는 AgentCore 기능들

Amazon Bedrock AgentCore Runtime은 일반적으로 사용 가능(Generally Available, GA)합니다. 웹 검색(Web search) 도구는 us-east-1 및 eu-west-1 리전에서 SLA(Service Level Agreement)가 보장되는 퍼블릭 프리뷰(Public preview) 상태입니다. GA 상태를 확인하지 않고 다른 리전에 프로덕션(Production) 용도로 배포하지 마십시오. 이는 현재 스택에서 프로덕션 준비 완료(Production-ready)와 실험적(Experimental) 단계를 구분하는 가장 명확한 기준입니다. Runtime, Memory, 그리고 IAM 범위의 도구 호출(Tool invocation)은 충분히 검증되었습니다. 웹 검색은 프리뷰 단계이지만, Accenture의 AWS 실무 부서가 정적 RAG에서 실시간 웹 기반 검색(Live web-grounded retrieval)으로 전환한 후, 시간에 민감한 조달 쿼리에 대한 에이전트 환각(Hallucination) 발생률이 34% 감소했음을 보여주는 문서화된 파일럿을 실행했을 정도로 충분히 안정적입니다.

Accenture의 AWS 실무 부서 수석 솔루션 아키텍트(Principal Solutions Architect)인 Maya Lin은 Twarx에 그 결과가 그녀의 팀조차 놀라게 했다고 전했습니다: '우리는 정보의 신선도(Freshness)가 개선될 것이라고 예상했습니다. 하지만 우리가 예상하지 못했던 것은, 오래된 코퍼스(Stale-corpus) 기반의 답변을 제거하는 것만으로도 후속 인간 검토(Human review) 작업이 3분의 1이나 줄어들었다는 점입니다. 비용 절감은 검색 자체에서 온 것이 아니라, 더 이상 수행할 필요가 없어진 수정 작업에서 발생했습니다.'

여전히 실험적인 단계: 멀티 에이전트 웹 검색 조정 및 자율 브라우징 체인

관리형 AWS 프리미티브(Managed AWS primitive)는 아니지만, 감독자(Supervisor)가 병렬 검색 서브 에이전트(Sub-agents)를 조정하는 멀티 에이전트 웹 검색 오케스트레이션(Multi-agent web search orchestration)은 현재 구축이 가능합니다. 이는 LangGraph 또는 AutoGen을 사용하여 직접 조립해야 합니다. 브라우저 도구(Browser Tool)와 웹 검색을 결합하여 장기 실행 루프(Long-running loops)를 형성하는 자율 브라우징 체인(Autonomous browsing chains)은 명백히 연구 단계에 있으며, 인간의 체크포인트(Human checkpoint) 없이는 고객 대상 프로덕션 경로에 포함되어서는 안 됩니다.

OpenAI, Anthropic, 그리고 AWS가 실시간 그라운딩(Real-Time Grounding) 아키텍처에서 갈라지는 지점

OpenAI's Bing 그라운딩 (grounding)을 사용하는 GPT-4o와 Brave Search를 활용한 Anthropic Claude의 도구 사용 (tool-use)은 가장 유사한 두 가지 경쟁적 프리미티브 (primitives)입니다. 하지만 둘 중 어느 것도 AgentCore와 같이 전체 에이전트 생명주기 관리 플랫폼 (agent lifecycle management platform)에 네이티브하게 내장되어 있지는 않습니다. 이러한 플랫폼 임베딩 (platform embedding)이 전략적 차이점입니다. AWS는 그라운딩 (grounding)을 독립적인 검색 호출 (search call)이 아닌, 거버넌스 (governance)의 일부로 판매합니다.

AutoGen 0.4와 LangGraph 0.2는 모두 MCP 도구 등록 (tool registration)을 지원합니다. 이는 AgentCore 웹 검색이 AWS 외부의 오케스트레이션 스택 (orchestration stacks)에 외부 도구로 연결될 수 있음을 의미합니다. 이는 오케스트레이터 (orchestrator)는 AWS 외부에 있지만 그라운딩 (grounding)은 AWS 내부에 존재하는 하이브리드 배포 (hybrid deployments)를 위한 결정적인 해제 요소 (unlock)입니다.

CrewAI 사용자들을 위한 한 가지 지연 시간 (latency) 주의 사항이 있습니다. CrewAI의 순차적 작업 모델 (sequential task model)은 웹 검색 지연 시간이 급증할 때 병목 현상 (bottleneck)을 일으킵니다. AWS 벤치마크 공개 자료에 따르면 AgentCore 웹 검색 호출당 p95 지연 시간은 2.1~3.8초로 예상되며, 5개의 작업이 순차적으로 진행되는 크루 (crew) 환경에서는 이 수치가 빠르게 누적됩니다.

세 가지 실시간 그라운딩 (real-time grounding) 아키텍처는 생명주기 통합 (lifecycle integration) 측면에서 갈라집니다. AWS는 웹 검색을 전체 에이전트 거버넌스 (agent governance) 내부에 내장하는 반면, OpenAI와 Anthropic은 이를 개별적인 도구 호출 (tool call)로 노출합니다.

기술적 심층 분석: Amazon Bedrock AgentCore 웹 검색의 실제 작동 방식

작동 메커니즘은 주변 생태계가 시사하는 것보다 더 간단합니다. 마케팅 요소를 제외하면, 구조화되고 출처가 명시된 (source-attributed) JSON을 반환하는 서버리스 도구 호출 (serverless tool invocation)일 뿐입니다.

아키텍처 상세 설명: 에이전트 도구 호출부터 그라운딩된 응답까지

AgentCore 웹 검색 요청 생명주기: 도구 호출에서 그라운딩된 답변까지

  1

    **Bedrock Converse API — 모델이 tool_use 블록을 생성**

모델(Claude 3.5 Sonnet, Nova Pro 또는 Llama 3.1 405B)은 현재 데이터가 부족하다고 판단하고, 쿼리 문자열(query string)과 선택 사항인 결과 개수(num_results)를 포함한 구조화된 tool_use 요청을 생성합니다.

↓

  2
...

요청은 AWS의 관리형 보안 계층을 통해 라우팅됩니다: IAM 액세스 제어(access control), VPC 격리(isolation), 그리고 CloudTrail 감사 로깅(audit logging)이 자동으로 적용됩니다. 사용자의 계정에서 크롤러 인프라(crawler infrastructure)가 실행되지 않습니다.

↓

  3
...

실시간 웹 결과가 구조화된 JSON 형식으로 가져와져 반환됩니다: 소스 URL(source URL), 스니펫(snippet), 최신성 타임스탬프(freshness timestamp). 이는 읽기 전용 검색(read-only retrieval)이며, 대화형 브라우징(interactive browsing)이 아닙니다.

↓

  4
...

애플리케이션은 결과를 모델 컨텍스트(context)에 tool_result 블록으로 다시 주입하기 전에 결과를 정화(sanitise)합니다 (프롬프트 인젝션 방어 (prompt-injection defence)).

↓

  5
...

모델은 출처 인용(source attribution)을 포함한 최종 답변을 합성합니다 — 여기서 최신성 타임스탬프(freshness timestamp)가 시간적 쇠퇴 한계(Temporal Decay Ceiling)를 극복하는 핵심 요소입니다.

이 시퀀스가 중요한 이유는 4단계인 정화(sanitisation) 과정이 대부분의 팀이 생략하는 단계이며, 바로 이 지점이 프롬프트 인젝션(prompt-injection) 공격이 발생하는 지점이기 때문입니다.

MCP 통합: AgentCore Web Search를 표준화된 도구로 등록하기