Amazon Bedrock AgentCore Web Search: 프로덕션 AI 에이전트를 위한 실시간 그라운딩 (Live Grounding)

원문은 twarx.com에서 처음 게시되었습니다 - 전체 인터랙티브 버전은 그곳에서 읽을 수 있습니다.

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

당신의 AI 에이전트는 환각 (Hallucination)을 일으키는 것이 아닙니다. 더 이상 존재하지 않는 세상에 대해 진실을 말하고 있을 뿐입니다. Amazon Bedrock AgentCore web search는 업계 전체가 근본적인 거짓 위에 프로덕션 에이전트를 구축해 왔다는 사실을 보여주는 최초의 AWS 네이티브 신호입니다. 즉, 어제의 데이터가 오늘의 의사결정에 충분하다는 거짓말 말입니다.

Amazon Bedrock AgentCore web search는 에이전트가 추론 (Inference) 시점에 실시간 웹을 쿼리할 수 있도록 해주는 관리형 도구이며, 메모리, 코드 실행 및 브라우저 상호작용을 이미 처리하고 있는 동일한 런타임 (Runtime) 내에 위치합니다. 이것이 지금 중요한 이유는 LangGraph, AutoGen 또는 CrewAI를 연결했든 아니든, AWS에서 프로덕션 에이전트를 실행하는 모든 팀이 지식 컷오프 (Knowledge Cutoff) 문제를 의사결정 계층에 조용히 포함시켜 배포해 왔기 때문입니다.

이 글을 마칠 때쯤이면 여러분은 왜 정적 에이전트 (Static Agents)가 실패하는지, 실시간 그라운딩 (Live Grounding)을 어떻게 올바르게 설계해야 하는지, 그리고 언제 그것을 사용하지 말아야 하는지를 정확히 이해하게 될 것입니다.

시각화된 '정체된 세상 가정 (Stale World Assumption)': 실시간 세상은 이미 변했지만, 프로덕션 에이전트는 고정된 스냅샷을 바탕으로 자신 있게 추론하고 있습니다. Amazon Bedrock AgentCore web search는 그 간극을 메우는 계층입니다.

정체된 세상 가정 (The Stale World Assumption): 왜 대부분의 프로덕션 AI 에이전트의 아키텍처가 결함이 있는가

여기 대부분의 팀이 직면하기를 거부하는 역설적인 진실이 있습니다. 프로덕션 에이전트에서 발생하는 최악의 실패는 모델의 실패가 아닙니다. 그것은 모델이 완벽하게 실행하고 있는 아키텍처의 실패입니다. 당신의 Claude 3.5 Sonnet 또는 Amazon Nova Pro 에이전트는 당신이 시킨 일을 정확히 수행했습니다. 즉, 몇 주 전에 수명을 다한 데이터를 바탕으로 아름답게 추론한 것입니다.

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

오래된 세계 가정 (The Stale World Assumption) — AI 에이전트가 현실의 고정된 스냅샷을 바탕으로 추론하도록 설계되어, 출력되는 모든 결정이 죽은 데이터에 대해서는 기술적으로는 옳지만 실제 살아있는 세계에 대해서는 운영상 틀리게 되는 조용한 아키텍처 결함

이는 모델의 학습 중단 시점(training cutoff)과 벡터 인덱스(vector index)의 마지막 재인덱싱 작업(re-indexing job)을 세상의 실시간 상태를 대체하는 수단으로 취급하는 체계적인 실수를 지칭합니다. 모든 에이전트는 기본적으로 이를 상속받으며, 대부분의 팀은 에이전트가 추론하는 것과 동일한 오래된 데이터로 테스트를 통과하기 때문에 이를 인지하지 못합니다.

2026년, 지식 중단(Knowledge Cutoff)이 기업에 실제로 초래하는 비용

지식 중단(Knowledge cutoff)은 모델 카드 각주에 언급할 만한 사소한 특이사항이 아닙니다. 이는 재무제표상의 부채입니다. Gartner의 추정에 따르면, 2025년까지 기업용 AI 배포의 40% 이상이 90일보다 오래된 데이터를 기반으로 결정을 내릴 것이라고 합니다. 이는 모델의 실패 때문이 아니라 아키텍처 설계 때문입니다. 2026년에도 그 수치는 개선되지 않았습니다. 오히려 에이전트 기반 배포(agentic deployments)의 폭발적 증가로 인해 상황은 더 악화되었습니다. 에이전트는 단순히 오래된 데이터로 답변하는 것에 그치지 않고, 그 데이터를 바탕으로 직접 '행동(act)'하기 때문입니다.

40% 이상
90일보다 오래된 데이터를 기반으로 결정을 내리는 기업용 AI 배포
[Gartner, 2025](https://www.gartner.com/en/information-technology)
...

RAG와 벡터 데이터베이스가 실시간 데이터 문제를 해결하지 못하는 이유

이는 현재 에이전트 구축 분야에서 가장 비용이 많이 드는 오해입니다. 바로 RAG (Retrieval-Augmented Generation, 검색 증강 생성)가 신선도(freshness) 문제를 해결할 것이라는 믿음입니다. 그렇지 않습니다. Pinecone이나 Amazon OpenSearch와 같은 벡터 데이터베이스를 사용하는 RAG 파이프라인은 '문서 검색(document retrieval)'을 해결할 뿐입니다. 즉, 발행 날짜와 상관없이 의미론적으로 가장 유사한 청크(chunk)를 검색합니다. 이들은 수동적인 재인덱싱(re-indexing) 주기를 필요로 합니다. 기본적으로 실시간(real-time)이 아니며, 아무리 영리하게 청킹(chunking)을 한다 해도 이 사실은 변하지 않습니다.

벡터 인덱스(vector index)는 스냅샷입니다. 인덱싱을 마치는 순간, 드리프트(drift)가 쌓이기 시작합니다. 코사인 유사도(Cosine similarity)에는 '이 문서는 6주 전에는 사실이었지만 지금은 틀렸다'라는 개념이 없습니다. 코사인 유사도는 가장 관련성이 높은 오래된 답변을 매우 확신에 찬 태도로 반환할 것입니다. 저는 평가 점수가 훌륭하게 나왔다는 이유로 데이터의 신선도(freshness) 문제를 해결했다고 믿었던 팀들이, 정작 동일한 오래된 코퍼스(corpus)로 구축된 테스트 세트를 사용했다가 큰 실패를 겪는 것을 목격했습니다. 이러한 근본적인 한계는 검색을 처음부터 코퍼스에 국한된 작업(corpus-bound operation)으로 정의한 원본 RAG 연구 논문에도 잘 기록되어 있습니다.

RAG는 에이전트를 최신 상태로 만들어주지 않습니다. RAG는 에이전트가 마지막으로 인덱싱한 내용에 대해 확신을 갖게 만들 뿐입니다. 이 둘은 같지 않으며, 그 사이의 간극이 바로 신뢰성이 무너지는 지점입니다.

LangGraph, AutoGen, 그리고 CrewAI 파이프라인에 내재된 폐쇄 세계 가정 (closed-world assumption)

LangGraph와 AutoGen은 모두 실시간 소스에 명시적으로 연결하지 않는 한 정적 지식 검색(static knowledge retrieval)을 기본값으로 사용합니다. 이는 대부분의 팀이 테스트 단계가 아닌 프로덕션 단계에서 발견하게 되는 격차입니다. 오케스트레이션 그래프(orchestration graph)는 결함 없이 실행됩니다. 모든 노드는 200 상태 코드를 반환합니다. 에이전트는 일관성 있고 인용이 잘 된 답변을 생성하지만, 공교롭게도 현재 시점에서는 틀린 내용을 말하게 됩니다.

AWS에서 CrewAI 오케스트레이션 파이프라인을 운영하던 한 금융 서비스 팀은, 에이전트가 6주 전에 업데이트된 규제 임계값을 확신을 가지고 인용하여 전체 컴플라이언스(compliance) 검토를 유발했다고 보고했습니다. 에이전트가 고장 난 것이 아니었습니다. 세상은 변했지만, 에이전트는 이를 인지하도록 구축되지 않았을 뿐입니다.

'오래된 세상 가정(Stale World Assumption)'은 모델의 문제가 아닙니다. OpenAI의 GPT-4o, Anthropic의 Claude 3.5 Sonnet, 그리고 Amazon Nova 모두 동일하게 이 문제를 물려받습니다. 해결책은 전적으로 도구 계층(tool layer)에 있습니다. 어떤 프런티어 모델(frontier model)을 선택하든 해결 방법은 같습니다. 추론 시점(inference time)에 실시간 그라운딩(live grounding)을 강제하는 것입니다.

Amazon Bedrock AgentCore Web Search의 실체 (그리고 실체가 아닌 것)

마케팅 용어보다 용어의 정의가 더 중요하기 때문에, 공식 AWS 발표(AWS announcement) 내용을 정확하게 해독해 보겠습니다.

공식 AWS 발표 해독: 그라운딩 (grounding) vs. 검색 (retrieval) vs. 브라우징 (browsing)

Amazon Bedrock AgentCore web search는 에이전트가 추론 시점(inference time)에 실시간 웹을 쿼리할 수 있도록 하는 관리형 도구입니다. 이것은 크롤링 후 캐싱(crawl-and-cache)하는 시스템이 아닙니다. 이것은 실시간 그라운딩(real-time grounding) 호출입니다. 이 차이가 핵심입니다. 캐시는 그저 '오래된 세계 가정(Stale World Assumption)'을 갓 구워낸 버전일 뿐입니다. 그라운딩(Grounding)이란 에이전트가 추론하는 바로 그 순간에 세상의 실시간 상태를 가져온다는 것을 의미합니다.

세 가지 용어가 끊임없이 혼용되고 있으며, 이는 실제로 비용 손실을 초래합니다. _검색 (Retrieval)_은 사용자가 인덱싱한 자체 코퍼스(corpus)에서 정보를 가져옵니다. _브라우징 (Browsing)_은 웹 애플리케이션을 통해 실제 브라우저를 구동합니다. _그라운딩 (Grounding)_은 모델의 생성(generation)을 검증된 실시간 사실에 고정(anchor)시킵니다. AgentCore web search는 그라운딩입니다. 검색이 아닙니다. 브라우징도 아닙니다. 공식 Bedrock Agents 문서(Bedrock Agents documentation)는 이러한 기본 요소(primitives)를 의도적으로 명확히 구분하고 있습니다.

AgentCore web search와 AgentCore Browser Tool의 차이점

이 둘은 서로 다른 도구이며, 이를 혼동하면 비용과 지연 시간(latency) 손실을 보게 됩니다. AgentCore Browser Tool은 웹 앱 상호작용(클릭, 양식 채우기, 다단계 흐름 탐색 등)을 위해 완전히 격리된 Chromium 환경을 제공합니다. 반면, web search는 지식 그라운딩을 위한 구조화된 실시간 쿼리 결과(structured live query results)를 제공합니다. 만약 에이전트가 포털에 로그인하여 결제를 완료해야 한다면, 그것은 Browser Tool의 역할입니다. 만약 EC2 인스턴스의 현재 가격을 확인해야 한다면, 그것은 web search의 역할입니다. 작업에 맞지 않는 도구를 사용하는 것은, 단 한 번의 API 호출로 끝낼 수 있는 일을 위해 헤드리스 브라우저(headless browser)를 구동하는 것과 같습니다.

AWS는 방금 DIY 검색 도구 스택 전체를 기술 부채(technical debt)로 만들어 버렸습니다. 메모리(Memory), 코드 실행(code execution), 브라우저(browser), 그리고 실시간 그라운딩(live grounding)이 이제 하나의 런타임(runtime) 안에 존재합니다. 이전에는 LangGraph, Tavily, 그리고 별도의 메모리 저장소(memory store)를 통해 직접 구축(hand-roll)해야 했던 기능들이 이제는 관리형 프리미티브(managed primitive)가 되었습니다.

AgentCore 아키텍처에서 MCP와 도구 사용(tool-use) 프로토콜의 역할

AWS는 AgentCore를 메모리, 도구 사용(tool use), 코드 실행, 그리고 이제는 실시간 웹 그라운딩(live web grounding)까지 아우르는 풀스택 에이전트 런타임(full-stack agent runtime)으로 포지셔닝하며, 현재 대부분의 팀이 직접 구축하고 있는 LangGraph + 외부 검색 API 패턴과 직접적으로 경쟁합니다. 결정적으로, Anthropic에서 개발하여 오픈 소스로 공개한 MCP (Model Context Protocol)가 AgentCore의 도구 사용(tool-use) 레이어 내에서 지원됩니다. 이는 웹 검색 결과가 프롬프트에 억지로 밀어 넣은 가공되지 않은 문자열(raw strings)이 아니라, 구조화된 컨텍스트 블록(structured context blocks)으로 전달될 수 있음을 의미합니다. 이는 추론 체인(reasoning chain)을 통해 인용 메타데이터(citation metadata)를 보존하려고 할 때 생각보다 훨씬 더 중요한 요소입니다.

AWS의 자체 발표에서는 에이전트가 현재 AWS 서비스 가격에 대한 질문에 답변하는 모습을 보여주는데, 이는 정의상 정적 RAG(Retrieval-Augmented Generation) 시스템이 실패할 수밖에 없는 전형적인 유스케이스(use case)입니다. 가격은 변하기 때문입니다. 지난 분기 가격 페이지를 벡터 인덱스(vector index)로 만들어 두는 것은 기능처럼 보이지만 실제로는 부채(liability)일 뿐입니다.

이것이 무엇이 아닌지 명확히 하자면: AgentCore 웹 검색은 기업 내부의 독점 콘텐츠에 대한 심층 문서 RAG(document RAG)를 대체하는 것이 아닙니다. 이는 기존의 벡터 데이터베이스(vector database) 검색 위에 놓이는, 누락되었던 실시간 세계(live-world) 레이어입니다. 내부 정책 문서용으로는 기존의 OpenSearch 인덱스를 유지하십시오. 그리고 실시간 세계를 위해 웹 검색을 추가하는 것입니다. 만약 더 넓은 범위의 런타임을 매핑하고 있다면, AI 에이전트 프레임워크 비교 개요를 통해 오픈 소스 대안들과 AgentCore를 비교해 볼 수 있습니다.

AgentCore 런타임은 메모리 (Memory), 코드 실행 (Code Execution), 브라우저 도구 (Browser Tool), 그리고 웹 검색 그라운딩 (Web Search Grounding)을 하나의 관리형 레이어로 통합하여, 기존에 별도로 통합해야 했던 네 가지 시스템을 하나로 축소합니다. 출처

Amazon Bedrock AgentCore Web Search가 직접적으로 해결하는 5가지 실패 모드 (Failure Modes)

실제로 서비스에 배포되었을 때 '오래된 정보에 기반한 가정 (Stale World Assumption)'은 어떤 모습으로 나타날까요? 다음은 프로덕션 환경에서 발생하는 다섯 가지 실패 모드와, 실시간 그라운딩 (Live Grounding)이 각 문제를 어떻게 해결하는지에 대한 설명입니다.

실패 모드 1: 확신에 찬 오답 (Confident wrongness)

가장 위험한 모드입니다. 코사인 유사도 (Cosine-similarity) 검색을 사용하는 에이전트는 문서의 발행 날짜와 상관없이 의미론적으로 가장 유사한 문서를 반환합니다. 대부분의 RAG (Retrieval-Augmented Generation) 구현에는 기본적으로 시간적 순위 지정 (Temporal ranking) 기능이 없기 때문입니다. 에이전트는 0.94의 유사도 점수와 권위 있는 어조로 답변을 보고합니다. 하지만 사실은 6주 전의 죽은 정보입니다. 높은 확신과 오래된 데이터의 결합은 기업용 AI에서 신뢰도를 파괴하는 가장 치명적인 조합이며, 제가 프로덕션에서 본 수정되지 않은 모든 RAG 파이프라인의 기본 동작 방식입니다.

실패 모드 2: 검색 증강 환각 (Retrieval-augmented hallucination)

벡터 인덱스 (Vector index)가 오래된 데이터를 증폭시킬 때, RAG는 문제를 적극적으로 악화시킵니다. 환각 (Hallucination)을 줄이기 위해 검색을 추가했지만, 결과적으로 모델에게 확신을 가지고 검색된 잘못된 사실을 제공하게 된 것입니다. 모델은 이제 이를 사실 (Ground truth)로 취급하고 이를 바탕으로 추론을 진행합니다. 이 환각은 출처가 명시된 주장처럼 보이기 때문에, 단순한 환각보다 잡아내기가 더 어렵습니다.

실패 모드 3: 오케스트레이션 맹목성 (Orchestration blindness)

n8n 워크플로 자동화 (workflow automations) 및 정적 지식 베이스 (static knowledge bases)를 호출하는 AutoGen 워크플로에는 데이터 소스가 최신 상태가 아니게 되었을 때 이를 감지할 메커니즘이 없습니다. 파이프라인은 200 상태 코드로 성공을 반환하지만, 콘텐츠는 몇 달 전의 오래된 데이터일 수 있습니다. 대시보드는 초록색(정상)이지만, 데이터는 죽어 있는 상태입니다. 귀하의 워크플로 자동화 (workflow automation)는 시간적 드리프트 (temporal drift)가 발생했다는 신호가 없기 때문에 스스로 수정할 수 없습니다. 시스템 설계상 시간의 흐름에 대해 눈이 멀어 있기 때문입니다.

실패 모드 4: 재색인 트레드밀 (The re-indexing treadmill)