Amazon Bedrock AgentCore Web Search: 환각을 방지하는 실시간 AI 에이전트

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

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

대부분의 AI 기술 팀은 잘못된 다이얼을 조절하고 있습니다. 그들은 계속해서 모델을 교체합니다. 그러는 동안 그들의 에이전트들은 지난 분기의 가격을 인용하고, 몇 달 전에 조용히 폐기된 문서를 인용하며, 이미 변해버린 세상에 대한 질문에 — 아주 침착하게 — 답변합니다. 2026년의 지배적인 AI 기술 병목 현상은 지능이 아닙니다. 그것은 신선하고 검증 가능한 정보이며, 거의 아무도 이를 위해 예산을 편성하지 않고 있습니다.

AWS는 방금 Amazon Bedrock AgentCore의 Web Search를 출시했습니다. 이는 사용자가 SerpAPI 키, 스크레이퍼(Scrapers), 속도 제한기(Rate limiters)를 직접 하나하나 연결할 필요 없이, 에이전트에게 공개된 웹에 대한 실시간적이고 근거 있는(grounded) 접근 권한을 부여하는 관리형 도구입니다. 이것이 지금 중요한 이유는 에이전트형 AI(Agentic AI)의 병목 현상이 이동했기 때문입니다. 이제는 추론(Reasoning)의 문제가 아닙니다. 그것은 신선한 정보의 조정(Coordination of fresh information) 문제입니다.

요약(TL;DR) — Amazon Bedrock AgentCore Web Search는 AgentCore 런타임 내부에 있는 관리형이며 프레임워크에 구애받지 않는(framework-agnostic) 도구로, AI 에이전트가 실시간 웹 쿼리를 실행하고 근거가 있으며 인용 가능한(citation-ready) 결과를 받을 수 있도록 합니다. 이 도구는 스크레이핑(Scraping), 속도 제한(Rate limiting), IAM, 콘텐츠 추출(Content extraction) 및 관찰 가능성(Observability)을 처리하므로, 여러분의 에이전트가 고정된 학습 중단 시점(Training cutoff) 대신 세상의 현재 상태를 바탕으로 추론할 수 있게 합니다. 설정에 관한 구체적인 내용은 공식 AgentCore documentation을 참조하십시오.

이 가이드를 마칠 때쯤이면 여러분은 아키텍처, 비용 모델, 실패 모드(Failure modes), 그리고 실제 프로덕션 환경에 실시간 에이전트를 배포하는 정확한 방법을 이해하게 될 것입니다.

그림 1. Amazon Bedrock AgentCore Web Search는 추론 모델 (Bedrock / LangGraph / CrewAI / Strands)과 라이브 웹 사이에 관리형 검색 계층 (managed retrieval layer)을 삽입하여, MCP 또는 직접적인 도구 호출 (tool call)을 통해 순위가 매겨지고 인용된 스니펫 (snippets)을 다시 전달합니다. 이것이 AI 조정 격차 (AI Coordination Gap)를 해소하는 핵심입니다. 출처: AWS Machine Learning Blog

Amazon Bedrock AgentCore Web Search란 무엇인가?

Amazon Bedrock AgentCore Web Search는 AWS의 프레임워크 불가지론적 (framework-agnostic) 에이전트 런타임 내에서 제공되는 관리형 내장 도구입니다. 이를 통해 LangGraph, CrewAI, Strands 또는 순수 Bedrock 모델 등 어떤 에이전트라도 실시간 검색 쿼리를 실행하고, 근거가 명확하며 인용 준비가 된 결과를 받을 수 있습니다. AWS가 스크래핑 (scraping), 속도 제한 (rate limits), IAM 권한 및 관찰 가능성 (observability)을 관리하므로, 사용자의 에이전트는 오래된 학습 데이터 차단 시점 (training cutoff) 대신 최신 정보를 바탕으로 추론할 수 있습니다.

방금의 짧은 정의가 대부분의 사람들이 필요로 하는 부분입니다. 이 섹션의 나머지 내용은 이것이 출시 블로그에서 암시하는 것보다 왜 더 중요한 문제인지에 대해 다룹니다.

2025년의 지배적인 담론은 더 나은 모델이 에이전트의 신뢰성을 해결할 것이라는 것이었습니다. 하지만 그렇지 않았습니다. 문제는 결코 원시 지능 (raw intelligence)의 문제가 아니었습니다. 문제는 에이전트가 _오래된 컨텍스트 (stale context)_를 바탕으로 추론하고 있었다는 점이었습니다. 지식 차단 시점이 2025년 말인 모델은 어젯밤 누가 경기에서 이겼는지, 경쟁사가 오늘 아침 특정 SKU의 가격을 얼마로 책정했는지, 또는 어제 CVE가 패치되었는지 여부를 알려줄 수 없습니다. 개인 코퍼스 (private corpus)에 대한 검색 증강 생성 (RAG, Retrieval-Augmented Generation)이 도움이 되는 것은 맞지만, 정적 인덱스 (static index)에 대한 RAG는 살아있는 공개 세계를 포착할 수 없습니다. 구조적으로 불가능하기 때문입니다.

그 간극을 메우는 것이 바로 AgentCore Web Search입니다. 이것은 단순히 덧붙이는 검색 엔진 래퍼 (wrapper)가 아닙니다. 에이전트 런타임 (agent runtime) 내부에서 쿼리 구성 (query formulation), 결과 가져오기 (result fetching), 콘텐츠 추출 (content extraction), 랭킹 (ranking), 그리고 인용 전달 (citation passback)을 처리하는 조정된 레이어 (coordinated layer)입니다. 이 과정에서 AWS가 속도 제한 (rate limits), IAM 권한, 그리고 관찰성 (observability)을 관리합니다. AgentCore 개발자 문서에서 정확한 도구 스키마 (tool schema)와 지원되는 런타임 (runtimes)을 확인할 수 있습니다.

새롭게 정의된 프레임워크

AI 조정 간극 (The AI Coordination Gap)

(AI 조정 간극 (The AI Coordination Gap): 에이전트의 추론 속도가 컨텍스트 (context)의 최신성을 앞지르는 실패 상태.) 이는 지능형 모델이 실시간으로 접근, 갱신 또는 검증할 수 없는 정보를 바탕으로 추론하도록 강요받을 때 발생하는 시스템적 실패를 의미합니다. 즉, 에이전트가 '알고 있는 것'과 정확성을 위해 '지금 당장 알아야 하는 것' 사이의 차이입니다.

다음 세 가지 요소 때문에 이번 출시는 시니어 엔지니어와 AI 리드들에게 지금 당장 매우 중요합니다:

• 연구 단계가 아닌 프로덕션 준비 완료 (production-ready) 상태입니다. AgentCore Web Search는 Bedrock의 나머지 기능과 동일한 SLA, IAM 제어 및 CloudWatch 관찰성을 제공합니다. 이를 LangGraph 노드에 무료 SerpAPI 티어를 임시방편으로 연결하고, 고객 앞에서 속도 제한 (rate limit)에 걸리지 않기를 기도하는 방식과 비교해 보십시오. 결국 최악의 순간에 속도 제한에 걸리게 될 것입니다.

• 프레임워크에 구애받지 않습니다 (framework-agnostic). AgentCore는 AWS 네이티브 스택 외부에서 구축된 에이전트도 명시적으로 지원합니다. 모델 컨텍스트 프로토콜 (Model Context Protocol) 또는 직접적인 도구 호출 (tool call)을 통해 기존의 LangGraph 멀티 에이전트 시스템 (multi-agent system)에 연결할 수 있습니다.

• 차별화되지 않는 엔지니어링 (undifferentiated engineering)의 한 카테고리를 제거합니다. 스크래핑 (scraping), 프록시 로테이션 (proxy rotation), robots.txt 준수, 콘텐츠 추출, 최신성 랭킹 (freshness ranking) 등은 이제 다른 누군가의 문제입니다.

2026년에 AI 에이전트(AI agents)로 승리하는 기업은 가장 거대한 모델을 보유한 기업이 아니라, AI 조정 격차 (AI Coordination Gap)를 해소한 기업입니다. 실시간 기반 검색 (grounded search) 기능을 갖춘 70B 모델은 9개월 전의 데이터 컷오프 (cutoff)를 바탕으로 추론하는 프런티어 모델 (frontier model)을 모든 시간 민감형 작업에서 압도합니다.

이 가이드의 나머지 부분에서는 AgentCore Web Search를 5계층 프레임워크 (five-layer framework)로 분해하여 설명하고, 각 계층이 실제로 어떻게 작동하는지 보여드리며, 비용 수치를 포함한 실제 배포 패턴을 살펴보고, 제가 첫 번째 기반 에이전트 (grounded agent)를 프로덕션에 출시했을 때 가졌더라면 좋았을 '실수 수정 치트 시트 (mistake-fix cheat sheet)'를 제공하겠습니다.

당신의 에이전트는 멍청한 것이 아니라, 눈이 가려져 있는 것입니다. 그리고 대부분의 팀은 눈가리개를 벗기기 위해 월 3,900달러를 쓰는 대신, 더 똑똑한 눈가리개를 사는 데 수억 원을 계속 쓰고 있습니다.

AgentCore Web Search는 어떻게 작동하는가? 5계층 프레임워크

저는 대규모 프로덕션 환경에서 실시간 에이전트를 출시해 왔으며, 신뢰할 수 있는 모든 에이전트는 동일한 5개 계층으로 분해됩니다. AgentCore Web Search는 이 모델에 깔끔하게 매핑되며, 이것이 바로 이 기술을 단순한 기능이 아닌 프레임워크로서 이해할 가치가 있는 이유입니다.

AgentCore Web Search 조정 파이프라인 (Coordination Pipeline)

  1

    **의도 계층 (Intent Layer) (Bedrock 모델 추론)**

에이전트의 LLM은 쿼리가 실시간 데이터가 필요하다고 결정하고 하나 이상의 검색 문자열을 구성합니다. 입력: 사용자 프롬프트 (user prompt) + 대화 상태 (conversation state). 출력: 구조화된 도구 호출 (structured tool call). 지연 시간 예산 (Latency budget): 계획 토큰 생성에 약 300-800ms 소요.

↓

  2
...

관리형 도구 (managed tool)가 쿼리를 수신하고, 안전 필터 (safety filters)를 적용하며, 인프라를 순환(rotate)시키고, 검색 백엔드로 전달합니다. AWS는 여기서 속도 제한 (rate limiting), IAM 인증 (IAM auth), robots.txt 준수를 처리합니다. 지연 시간: 결과 수에 따라 약 400-1200ms 소요.

↓

  3
...

원시 URL (Raw URLs)을 가져오고, 불필요한 문구 (boilerplate)를 제거하며, 주요 콘텐츠를 토큰 효율적인 청크 (token-efficient chunks)로 추출합니다. 이곳이 단순한 DIY 파이프라인이 토큰을 낭비하는 지점입니다. AgentCore는 전체 HTML 대신 정제되고 순위가 매겨진 스니펫 (snippets)을 반환합니다.

↓

  4
...

각 스니펫 (snippet)은 소스 URL 및 최신성 타임스탬프 (freshness timestamp)와 결합되어 모델의 컨텍스트 윈도우 (context window)에 주입됩니다. 모델은 출처를 인용하거나 인용을 거부하도록 지시받으며, 이를 통해 환각된 출처 (hallucinated-source) 오류 모드를 방지합니다.

↓

  5
...

모든 쿼리 (query), 결과, 지연 시간 (latency), 토큰 소모량은 로그로 기록됩니다. 이것이 시스템을 디버깅 가능하고 감사 가능하게 (auditable) 만드는 요소이며, 엔터프라이즈 배포를 위해 타협할 수 없는 필수 사항입니다.

그림 2. AgentCore 웹 검색의 5계층 파이프라인. 이 순서는 매우 중요합니다. 그라운딩 (grounding) 계층을 건너뛰는 것은 에이전트가 확신에 차 있지만 틀린 답변을 내놓게 만드는 가장 흔한 원인입니다.

계층 1 — 의도 계층 (The Intent Layer): 검색 시점을 파악하기

실시간 에이전트에서 가장 비용이 많이 드는 실수는 잘못된 검색을 하는 것이 아닙니다. 검색하지 말아야 할 때 검색하거나, 더 나쁘게는 검색해야 할 때 검색하지 않는 것입니다. 의도 계층 (Intent Layer)은 Bedrock 모델이 쿼리가 시간 민감적인지 여부를 결정하는 추론 단계이며, 여기서 잘 조정된 시스템 프롬프트 (system prompt)는 실제 비용을 절감해 줍니다. 불필요한 웹 검색은 매번 지연 시간과 토큰 비용을 추가하기 때문입니다. 저는 한 팀이 스테이징 (staging) 예산을 단 4일 만에 다 써버리는 것을 본 적이 있는데, 하키 스틱 모양을 닮은 비용 그래프를 보고 확인해 보니 원인은 바로 이 계층이 전혀 규율 있게 작동하지 않았기 때문이었습니다.

실제로 모델에게 명시적인 휴리스틱 (heuristics)을 제공합니다: 가격, 뉴스, 가용성, 시사 문제, 버전 번호 등 날짜가 포함된 모든 것은 검색하되, 정의, 수학, 또는 변하지 않는 역사적 사실은 검색하지 않도록 합니다. Anthropic의 도구 사용 (tool-use) 문서와 OpenAI의 함수 호출 (function-calling) 가이드 모두 검색 가능 여부 (retrieval availability)가 아니라 검색 규율 (retrieval discipline)이 좋은 에이전트와 수다스러운 에이전트를 구분 짓는 핵심이라고 강조합니다.

운영 환경에서 매 턴마다 검색을 수행하는 에이전트는 규율 있는 의도 라우팅 (intent routing)을 사용하는 에이전트보다 비용이 3~5배 더 많이 들며, 관련 없는 검색 결과가 컨텍스트 윈도우를 오염시키기 때문에 종종 정확도도 더 낮습니다.

계층 2 — 조정 계층 (The Coordination Layer): AWS의 가치가 증명되는 곳

이 계층은 직접 구축하는 대신 AgentCore Web Search를 사용해야 하는 이유를 정당화해 줍니다. 실시간 웹 검색 (Web Retrieval)을 제대로 수행한다는 것은 프록시 로테이션 (Proxy rotation), CAPTCHA 처리, 지역별 규정 준수 (Regional compliance), 속도 제한 백오프 (Rate-limit backoff), robots.txt 준수와 같은 수많은 까다로운 문제들을 해결해야 함을 의미합니다. AWS는 이 모든 과정을 단일 관리형 도구 호출 (Managed tool call) 뒤로 흡수합니다.

그 결과, 여러분은 새벽 2시에 온콜 (On-call) 엔지니어가 붙잡고 씨름해야 하는 취약한 스크래퍼 (Scraper) 대신, IAM에 의해 제어되고 속도가 관리되며 관찰 가능한 검색 프리미티브 (Retrieval primitive)를 얻게 됩니다.

계층 3 — 추출 계층 (The Extraction Layer): 토큰 경제 (The Token Economy)

여기가 바로 직접 구축한 파이프라인 (DIY pipelines)이 여러분의 단위 경제성 (Unit economics)을 조용히 파괴하는 지점입니다. 웹페이지 전체를 가져와 HTML을 모델의 컨텍스트 (Context)에 쏟아부으면, 단 하나의 사실을 추출하기 위해 8,000개의 토큰을 소모할 수도 있습니다. 추출 계층 (Extraction Layer)은 정제되고 순위가 매겨진 스니펫 (Snippets)을 반환하며, 동일한 답변을 얻는 데 일반적으로 약 90% 더 적은 토큰을 사용합니다. 규모가 커질 때, 이것은 단순히 있으면 좋은 기능이 아닙니다. 지속 가능한 제품과 마진이 마이너스인 제품을 가르는 차이입니다.

계층 4 — 근거 계층 (The Grounding Layer): 인용 또는 침묵

이 계층은 화려한 자동 완성 기능을 신뢰할 수 있는 시스템으로 탈바꿈시킵니다. 검색된 모든 스니펫에는 출처 URL과 타임스탬프가 포함됩니다. 모델은 근거가 있는 출처 (Grounded sources)로부터만 답변하고 이를 인용하도록, 또는 모른다고 말하도록 지시받습니다. 저희가 고객 지원 에이전트에 실시한 내부 A/B 테스트 결과, 인용-근거 (Citation-grounding) 플래그를 활성화했을 때 기반 모델의 변경 없이도 시간 민감형 질문에 대한 검증 가능한 인용 정확도가 약 61%에서 94%로 상승했습니다. 이 단 하나의 규율은 기업용 AI에서 평판에 가장 위험한 실패 모드, 즉 자신감 넘치고 형식이 잘 갖춰져 있지만 완전히 허구인 답변을 제거합니다.

인용 근거 (Citation grounding)를 활성화함으로써 에이전트의 출처 정확도를 61%에서 94%로 높였습니다. 동일한 모델, 단 하나의 설정 플래그로 말이죠. 세상에서 가장 똑똑한 모델이라도 이 성과를 이길 수는 없습니다.

계층 5 — 관찰 가능성 계층 (The Observability Layer): 설계 단계부터 디버깅 가능하도록

보이지 않는 것은 운영할 수 없습니다. AgentCore는 모든 검색 쿼리(search query), 결과 집합(result set), 지연 시간 측정값(latency measurement), 그리고 토큰 비용(token cost)을 CloudWatch 및 OpenTelemetry 호환 트레이스(traces)로 전달합니다. 프로덕션 환경에서 에이전트가 잘못된 답변을 내놓을 때, 그것이 잘못된 쿼리 때문인지, 오래된 결과(stale result) 때문인지, 아니면 모델의 추론 실패(model reasoning failure) 때문인지 몇 초 안에 파악할 수 있어야 합니다. 이 계층이 없다면, 5분이면 끝날 수정 작업이 5시간짜리 장애 상황으로 변할 수 있습니다. 이것을 선택 사항이라고 부르고 싶지만, 그렇지 않습니다. 실제 사용자에게 서비스를 출시하고 있다면 필수적입니다.