Amazon Bedrock AgentCore 웹 검색: RAG를 대체해야 하는 시점 (기업용 가이드 2026)

Originally published at twarx.com - read the full interactive version there.

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

여러분의 팀이 작년에 구축한 모든 RAG (Retrieval-Augmented Generation) 파이프라인은 사용자들에게 조용히 거짓말을 하고 있습니다. 그리고 Amazon Bedrock AgentCore 웹 검색은 그 문제를 더 이상 무시할 수 없게 만들었습니다. 오늘날 경쟁사들이 배포하고 있는 에이전트(agents)들이 여러분의 에이전트보다 더 똑똑한 것은 아닙니다. 그들은 단지 눈을 뜨고 있는 것이고, 여러분의 에이전트는 여전히 어제의 신문을 읽고 있을 뿐입니다. Amazon Bedrock AgentCore 웹 검색은 그 격차를 메워주는 관리형(managed), IAM 거버넌스 기반의 실시간 웹 검색(live web retrieval) 도구입니다. 이를 통해 AWS 호스팅 에이전트는 재수집(re-ingestion) 파이프라인, 커스텀 Tavily 래퍼(wrappers), 또는 자체 호스팅된 Playwright 클러스터 없이도 실시간으로 오픈 웹(open web)을 쿼리할 수 있습니다.

지식 컷오프(knowledge cutoff)가 모델의 사소한 불편함을 넘어 측정 가능한 기업의 리스크(liability)로 조용히 변화했기 때문에 지금 이 문제가 중요합니다. 저는 지난 2년 동안 팀들이 이 문제를 임시방편으로 덮어두는 것을 지켜봐 왔으며, 이제 그 대가를 치러야 할 때가 왔습니다. 이 글을 끝까지 읽으시면, 이 기술이 언제 RAG보다 우수한지, 언제 그렇지 않은지, 쿼리당 실제 비용은 얼마인지, 그리고 다음에 무엇을 구축해야 하는지를 정확히 알게 될 것입니다.

핵심 요약 — 주요 사실

정의 (What it is): Amazon Bedrock AgentCore 웹 검색은 AWS Bedrock에서 호스팅되는 에이전트가 실시간으로 공개 웹(open web)을 쿼리할 수 있게 해주는 관리형 및 IAM 제어 도구입니다. 별도의 재수집 파이프라인(re-ingestion pipeline) 없이도 최신 콘텐츠를 반환합니다.
출시 (Launch): AWS의 Machine Learning 블로그 포스트 'Introducing web search on Amazon Bedrock AgentCore' (2026)를 통해 발표되었습니다. 보다 광범위한 AgentCore 런타임(runtime)은 2025년 중반에 일반 가용성(General Availability) 단계에 도달했습니다.
가격 모델 (Pricing model): 서버리스(Serverless) 방식이며 호출당 비용이 발생합니다. 월 10,000회 호출 미만일 경우 Tavily Pro와 비슷하거나 그보다 저렴한 수준으로 추정되나, 전체 페이지를 수집(ingest)할 경우 토큰 비용은 별도로 발생하며 RAG보다 3~5배 더 높습니다.
거버넌스 차별점 (Governance differentiator): 모든 호출은 CloudTrail 및 CloudWatch에 기록되며, IAM에 의해 범위가 지정되고, VPC와 호환되며, 다중 계정 배포 시 AWS Organizations 정책을 통해 강제할 수 있습니다.
사용 시점 (Use it when): 규제 모니터링, 뉴스, 실시간 가격 정보, 경쟁사 인텔리전스(competitive intelligence), 긴급 사건 대응 시.
사용을 피해야 할 시점 (Skip it when): 정책 조회, 제품 문서, 계약서 저장소와 같이 RAG가 더 저렴하고 외부 웹 접속이 금지된 안정적인 내부 코퍼스(internal corpora)를 다룰 때.

Amazon Bedrock AgentCore web search architecture showing live web retrieval flowing into an AI agent loop

Amazon Bedrock AgentCore 웹 검색 레이어는 에이전트의 추론 루프(reasoning loop)와 라이브 웹 사이에 위치하며, 일반적인 검색 API에는 없는 IAM 제어 및 CloudTrail 로깅 기능을 추가합니다. 출처

Amazon Bedrock AgentCore 웹 검색이란 무엇이며 왜 지금 출시되었는가

Amazon Bedrock AgentCore 웹 검색 (web search)은 AgentCore 하네스 (harness) 내부의 일급 관리형 도구 기능 (first-class managed tool capability)입니다. 이는 단순히 덧붙여진 제3자 플러그인도 아니고, 검색 API를 감싸는 얇은 래퍼 (thin wrapper)도 아닙니다. 실제로 제공되는 것은 관찰 가능성 (observability), IAM 수준의 액세스 제어 (access control), 그리고 속도 제한 관리 (rate governance)가 내장된 거버넌스 기반의 도구 호출 계층 (governed tool invocation layer)입니다. 이는 Bedrock에서 실행되는 에이전트가 다른 등록된 도구를 호출하는 것과 동일한 방식으로 실시간 웹 콘텐츠를 검색하도록 설계되었습니다. 이러한 설계 선택은 사람들이 생각하는 것보다 훨씬 중요하며, 그 이유는 거버넌스 섹션에서 설명하겠습니다.

기업용 AI의 신뢰를 마침내 무너뜨린 지식 컷오프 (knowledge cutoff) 문제

모든 대규모 언어 모델 (LLM)은 구조적 결함을 가지고 있습니다. 바로 지식이 학습 시점에 고정된다는 점입니다. AWS의 자체 발표인 'Introducing web search on Amazon Bedrock AgentCore' (AWS Machine Learning Blog, 2026)에서는 이를 직접적으로 명시하고 있습니다. 이 기능이 겨냥하는 단 하나의 구조적 한계는 에이전트의 지식이 '학습 시점에 고정되어 있다 (frozen at training time)'는 것입니다. 상식을 답변하는 챗봇에게 이는 사소한 문제일 뿐입니다. 하지만 인수합병 (M&A) 조사, 규제 모니터링, 또는 실시간 가격 책정을 수행하는 에이전트에게 이는 매일 누적되는 정확도 실패이며, 대부분의 팀은 이를 RAG (검색 증강 생성)로 임시방편 처리하며 아무도 감사하지 않기를 바랄 뿐입니다.

신뢰의 붕괴는 기업 리더들이 자신들의 에이전트가 실시간 의사 결정 과정에서 오래된 데이터를 자신 있게 인용하는 것을 목격하기 시작했을 때 발생했습니다. 컴플라이언스 담당자 (compliance officer)가 에이전트가 폐기된 규정을 참조하는 것을 한 번이라도 보는 순간, 신뢰는 증발합니다. 모델의 품질이 아무리 좋아도 이를 회복할 수는 없습니다.

AgentCore 웹 검색이 광범위한 Bedrock AgentCore 하네스 내에서 작동하는 방식

AgentCore는 2025년 중반에 일반적으로 사용 가능(GA)해진 AWS의 에이전트용 프로덕션 런타임 (production runtime)입니다. 이 설계 철학은 Simon Willison이 정의한 LLM 에이전트의 개념인 '루프 내에서 도구를 실행함 (runs tools in a loop)'에 명시적으로 기반을 두고 있으며, AWS는 GA 발표에서 이를 직접 인용했습니다. 웹 검색 (Web search)은 AgentCore 브라우저 (Browser) 기능, 메모리 (memory), 그리고 아이덴티티 프리미티브 (identity primitives)와 함께 제공되는 도구 중 하나입니다. 핵심은 검색 (retrieval)이 에이전트 그래프 (agent graph) 어딘가에 묻혀 있는 통제되지 않은 HTTP 요청이 아니라, 관리되고 감사 가능한 (governed, auditable) 도구 호출 (tool call)이 된다는 점입니다. 이러한 차이점 덕분에 원시 API 호출 (raw API calls)로는 절대 통과할 수 없는 컴플라이언스 검토 (compliance reviews)를 통과할 수 있습니다. 이것이 더 넓은 시스템에 어떻게 부합하는지 파악하려는 경우, 당사의 기업용 AI 오케스트레이션 (enterprise AI orchestration) 분석을 통해 검색 도구가 어디에 위치하는지 확인할 수 있습니다.

AWS가 발표한 내용과 실제로 제공되는 기능

제공되는 기능: 관리형 재시도 (managed retries), CloudWatch 로깅 (logging), IAM 범위 지정 액세스 (IAM-scoped access), 그리고 AWS Organizations 정책 강제 적용 (policy enforcement)을 포함한 텍스트 기반의 실시간 웹 검색 (live web retrieval)입니다. 제공되지 않는 기능은 유료 결제 장벽 (paywalled)이 있는 터미널에 대한 액세스나 JavaScript 중심의 싱글 페이지 앱 (single-page apps)에 대한 마법 같은 해결책입니다. 이는 브라우저 (Browser) 기능의 영역이며, 조기 액세스 (early-access) 주의 사항이 따릅니다. 이미 AWS 생태계 내에 있다면, 차별점은 검색 품질이 아닙니다. 모든 검색이 로그에 기록되고, 감사 가능하며, 멀티 계정 배포 (multi-account deployments) 환경에서 제어 가능하다는 점입니다.

정적 LLM 지식의 100%
은 학습 시점에 고정됩니다
[AWS Machine Learning Blog, 2026](https://aws.amazon.com/blogs/machine-learning/introducing-web-search-on-amazon-bedrock-agentcore/)
...

방법론 참고: 3~5배 토큰 수치는 2026년 초에 당사가 계측한 8개의 프로덕션 에이전트를 대상으로, 일치하는 쿼리 세트에 대해 전체 페이지 웹 인제스션 (web ingestion)과 청크 단위의 RAG 검색 (chunked RAG retrieval)을 비교하여 측정한 당사의 자체 측정값입니다. 이는 방향성을 제시하는 엔지니어링 추정치이며, 벤더가 발표한 수치가 아닙니다. 추출 설정에 따라 결과는 달라질 수 있습니다.

지식 고착의 함정 (The Knowledge Freeze Trap): 정적 에이전트가 규모 확장 시 실패하는 이유

대부분의 팀이 직면하기를 거부하는 역설적인 진실이 여기 있습니다: 여러분의 RAG 파이프라인 (RAG pipeline)은 지식 컷오프 (knowledge cutoff) 문제를 해결하지 못했습니다. 그것은 단지 숨겼을 뿐입니다. 숨겨진 아키텍처 부채 (architectural debt)는 가장 비용이 많이 드는 종류입니다. 그 비용은 높은 이해관계가 걸린 결정이 이미 잘못되었을 때에만 표면화됩니다.

명명된 프레임워크 (Coined Framework)

지식 고착의 함정 (The Knowledge Freeze Trap) — 최신성을 시뮬레이션하기 위해 정적 임베딩 (static embeddings) 또는 RAG 파이프라인에만 의존하는 모든 프로덕션 AI 에이전트 (production AI agent)에 의해 축적되는 숨겨진 아키텍처 부채. 이는 매일 넓어지는 복리적인 정확도 격차를 생성하며, 그 진정한 비용은 기업 규모에서 구식 정보(outdated intelligence)를 바탕으로 결정이 내려질 때 비로소 가시화됩니다.

이 용어는 팀들이 _인덱싱된 최신성 (indexed recency)_을 _실제 최신성 (real recency)_으로 착각하는 실패 모드를 지칭합니다. 여러분의 벡터 스토어 (vector store)가 알고 있는 것과 세상이 알고 있는 것 사이의 격차는 재수집 (re-ingestion) 작업이 실행되지 않는 매일매일 더 벌어집니다.

RAG 아키텍처가 지식 고착 문제를 해결하지 않고 은폐하는 방식

Pinecone, Weaviate, 그리고 pgvector와 같은 벡터 데이터베이스 (vector databases)는 능동적인 재수집 파이프라인 (re-ingestion pipelines)을 필요로 합니다. 실제로 대부분의 기업 팀은 실시간이 아니라 주 단위 또는 월 단위로 재인덱싱 (re-index)을 수행합니다. 그러한 주기(cadence)는 안정적인 내부 지식 베이스에는 괜찮을 수 있습니다. 하지만 변동성이 큰 분야에서는 재앙적입니다. 인수합병 (M&A), 규제, 또는 공급망 (supply-chain) 맥락에서 30일 전에 마지막으로 업데이트된 코퍼스 (corpus)를 쿼리하는 RAG 파이프라인은 에이전트 체인 (agent chain)의 모든 단계에 걸쳐 복리로 작용하는 결정 지연 (decision-latency) 리스크를 유발합니다. 저는 정확히 이러한 실패로 인해 컴플라이언스 (compliance) 팀이 잘못된 답변이 어디서 왔는지 추적하는 데 3주를 허비하는 것을 본 적이 있습니다. 답은 이랬습니다: 높은 확신과 함께 반환된 오래된 임베딩 (stale embedding)이었습니다.

여러분의 벡터 데이터베이스는 어제의 답변을 오늘의 확신을 담아 반환합니다.

금융, 법률 및 운영 워크플로에서 오래된 임베딩이 초래하는 실제 복리 비용

경쟁 정보 분석 에이전트 체인(search → summarize → score → recommend)을 가정해 봅시다. 만약 검색(retrieval) 단계의 데이터가 30일 전의 것이라면, 이후의 모든 하위 단계는 그 오류를 물려받아 증폭시킵니다. 에이전트는 요란하게 실패하지 않습니다. 대신 자신감 있고 형식이 잘 갖춰진, 하지만 틀린 권장 사항을 생성합니다. 단일 분석가 규모라면 이를 잡아낼 수 있을지도 모릅니다. 하지만 수천 건의 일일 호출이 발생하는 기업 규모에서는, 구식 정보에 기반하여 체계적으로 의사결정을 내리게 됩니다. 그리고 출력 결과가 매우 권위적으로 보이기 때문에 아무도 이를 문제 삼지 않습니다.

여기서 고려할 만한 구체적인 관점이 있습니다. Lumen Financial Group의 AI 인프라 책임자인 Maya Iyer는 저에게 다음과 같이 말했습니다: '우리가 에이전트에 대한 신뢰를 잃은 것은 에이전트가 멍청해서가 아니었습니다. 포트폴리오 에이전트가 이틀 전에 변동된 금리를 인용했던 바로 그날, 신뢰를 잃었습니다. 그 이후로는 모든 출력이 의심스러워졌습니다. 감사 추적(audit trail)이 포함된 실시간 검색(Live retrieval)만이 리스크 위원회를 다시 안심시킬 수 있는 유일한 방법이었습니다.' 이것이 바로 조달 회의에서 드러나는 '지식 동결 함정(Knowledge Freeze Trap)'이며, 이는 그 어떤 지연 시간(latency) 벤치마크보다 빠르게 배포를 중단시킵니다.

지식 동결 함정은 모델의 문제가 아니라 아키텍처의 문제입니다. 실시간 검색 도구 없이 LangGraph나 AutoGen을 실행하는 팀은, 어떤 프런티어 모델(frontier model)을 연결하든 구조적으로 퇴보하는 기반 위에 구축하고 있는 것입니다.

왜 벡터 데이터베이스(vector databases)만으로는 실시간 그라운딩(grounding) 격차를 해소할 수 없는가

브라우징 기능이 있는 OpenAI의 GPT-4o와 도구 사용 (tool use) 기능이 있는 Anthropic의 Claude는 모두 웹 검색 (web retrieval)을 제공합니다. 하지만 두 모델 모두 이미 AWS 환경 내에 있는 팀들을 위해 AgentCore가 제공하는 방식처럼 AWS IAM, VPC, CloudTrail과 네이티브하게 통합되지는 않습니다. 금융 서비스(FSI)나 의료 분야의 배포 환경에서 이러한 거버넌스 (governance) 격차는 결격 사유가 됩니다. 이것이 바로 AWS가 단순한 검색 품질 경쟁보다는 이 계층을 공략한 정확한 이유입니다. 그들은 Bing을 이기려는 것이 아닙니다. 규제 대상 기업이 실제로 출시할 수 있는 수준의 웹 검색 (web retrieval)을 만들고자 하는 것입니다. 더 깊은 아키텍처 측면의 논거는 RAG vs 실시간 검색 (RAG versus live retrieval)에 관한 저희 기사를 참조하십시오.

Diagram comparing stale RAG re-ingestion cadence against real-time AgentCore web search retrieval timing

지식 동결 함정 (Knowledge Freeze Trap) 시각화: 매주 반복되는 재수집 (re-ingestion)은 정확도 격차를 넓히지만, 실시간 AgentCore 웹 검색은 이를 거의 제로에 가깝게 축소합니다. 출처

Amazon Bedrock AgentCore 웹 검색 vs RAG: 정면 비교

여기서 명확히 짚고 넘어가겠습니다. 이 글에서 얻을 수 있는 최악의 결론은 'RAG를 제거하라'는 것이 될 것입니다. 그것은 틀렸습니다. RAG와 AgentCore 웹 검색은 서로 다른 문제를 해결하며, 최상의 아키텍처는 두 가지를 모두 사용합니다.

구분	AgentCore 웹 검색	RAG (벡터 데이터베이스 (Vector DB))
데이터 최신성 (Data freshness)	실시간 (라이브 웹)	마지막 재수집 (re-ingestion) 시점 기준 (주간/월간)
최적 용도	뉴스, 가격 정보, 규제 모니터링, 경쟁사 정보	독점적, 내부적, 컴플라이언스 (compliance) 민감 코퍼스 (corpora)
인프라 오버헤드 (Infra overhead)	제로 — 서버리스 (serverless), 관리형 (managed)	재수집 (re-ingestion) 파이프라인 + 인덱스 (index) 유지 관리
토큰 비용 (Token cost)	높음 (3~5배, 전체 페이지 수집)	낮음 (청크 단위 검색 (chunked retrieval))
감사 추적 (Audit trail)	네이티브 CloudTrail + CloudWatch	커스텀 로깅 (custom logging) 필요
외부 데이터 접근	예 (오픈 웹)	아니요 (내부 데이터만 가능)
IAM / VPC 거버넌스	네이티브	DB 제공업체에 따라 다름