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

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

대부분의 AI 기술 워크플로우는 완전히 잘못된 문제를 해결하고 있습니다. 그들은 어떤 모델을 사용할지에 집착하는 반면, 실제 프로덕션 에이전트(production agents)를 망가뜨리는 요소는 무시합니다. 바로 에이전트가 지금 당장 무엇이 사실인지 알 수 있는 신뢰할 수 있는 방법이 없다는 점입니다. 이것이 현대 기업용 AI (enterprise AI)의 핵심적인 실패 모드이며, 모델 선택과는 거의 관련이 없습니다.

AWS는 방금 Bedrock AgentCore의 웹 검색 (Web Search on Amazon Bedrock AgentCore)를 출시했습니다. 이는 MCP를 통해 에이전트 런타임(agent runtimes)에 직접 삽입되는 관리형 라이브 웹 검색(live-web retrieval) 도구입니다. 스크레이퍼(scrapers), 프록시 팜(proxy farms), 취약한 헤드리스 브라우저(headless browsers)가 필요 없습니다. 이 AI 기술이 중요한 이유는 최신 근거(fresh grounding)가 없는 에이전트는 자신 있게 환각(hallucinate)을 일으키며, 이 단일 실패 모드가 기업용 배포를 영원한 POC(Proof of Concept) 지옥에 머물게 만들기 때문입니다.

이 글을 다 읽을 때쯤이면, 여러분은 **AI 조정 격차 (AI Coordination Gap)**가 무엇인지, 왜 라이브 검색이 그 격차의 일부를 해소하는지, 그리고 지연 시간 예산(latency budget)을 낭비하지 않고 어떻게 이를 프로덕션 에이전트에 연결할 수 있는지 이해하게 될 것입니다.

Bedrock AgentCore의 웹 검색이 에이전트의 추론 루프(reasoning loop)와 오픈 웹 사이에 어떻게 라이브 검색 레이어를 삽입하여 AI 조정 격차의 일부를 해소하는지 보여줍니다. 출처

개요: Bedrock AgentCore의 웹 검색이란 실제로 무엇인가

Amazon Bedrock AgentCore는 AI 에이전트를 대규모로 구축, 배포 및 운영하기 위한 AWS의 런타임(runtime) 및 툴링(tooling) 계층입니다. 2025년에 프리뷰(preview)로 출시된 이 서비스는 Bedrock Agents의 기반이 되는 프로덕션 기질(production substrate)로서, 에이전트가 실행되는 내부의 메모리(memory), ID(identity), 게이트웨이(gateways) 및 보안 실행 환경(secure execution environment)을 처리합니다. 웹 검색(Web Search)은 가장 최신의 내장 도구로, 에이전트가 쿼리를 발행하고 오픈 웹(open web)에서 실시간으로 순위가 매겨진 결과를 받아 정제되고 인용 가능한 콘텐츠를 가져올 수 있게 해주는 관리형 기능(managed capability)입니다. 이 모든 과정은 귀사의 팀이 단 한 줄의 스크래핑(scraping) 인프라도 유지 관리할 필요 없이 이루어집니다. 전체 출시 세부 사항은 AWS Bedrock documentation에서 확인할 수 있습니다.

이것이 들리는 것보다 왜 더 중요한 일인지 설명하겠습니다. 지금까지 에이전트에게 실시간 웹 액세스 권한을 부여한다는 것은 다음 세 가지 고통스러운 옵션 중 하나를 의미했습니다: 스크래퍼 플릿(scraper fleet)을 구축하고 관리하거나(속도 제한, CAPTCHA, IP 차단 문제), 제3자 검색 API 호출당 비용을 지불하며 직접 결합하거나, 아니면 에이전트의 지식이 학습 중단 시점(training cutoff)에 멈춰 있다는 사실을 그냥 받아들이는 것이었습니다. 모든 옵션은 어딘가에서 신뢰성을 떨어뜨립니다. 이제 AWS는 Model Context Protocol (MCP)를 지원하는 일급 관리형 프리미티브(first-class, managed primitive)로서 실시간 검색을 제공합니다. 즉, Bedrock, LangGraph, CrewAI 또는 AutoGen 기반으로 구축되었든 관계없이, MCP를 인식하는 모든 에이전트는 별도의 커스텀 글루 코드(glue code) 없이도 이를 도구로 사용할 수 있습니다.

진정한 승부처는 '이제 에이전트가 구글링을 할 수 있다'는 점이 아닙니다. AWS가 실시간 검색(live retrieval)의 운영 부담—최신성(freshness), 중복 제거(deduplication), 콘텐츠 추출(content extraction)—을 단일 IAM 경계 내의 관리형 서비스로 흡수했다는 점입니다. 이는 에이전트 기반의 POC(Proof of Concept)가 프로덕션 단계로 넘어가지 못하는 가장 흔한 이유를 제거합니다.

시니어 엔지니어들에게 관련 질문은 매우 날카롭습니다. 이 AI 기술이 지연 시간 (Latency)에 어떤 영향을 미치는가? 기존의 RAG 파이프라인 (RAG pipeline)과 어떻게 상호작용하는가? 어디에서 실패하는가? 그리고 결정적으로 — 이것이 정말로 영리한 데모와 신뢰할 수 있는 시스템 사이의 격차를 해소하는가? 이 기술은 제가 'AI 조정 격차 (AI Coordination Gap)'라고 부르는 더 넓은 문제의 한 가지 특정 차원을 다룹니다. 그리고 이러한 프레임워크를 이해하는 것이 제품을 출시하는 팀과 계속해서 아키텍처만 재설계하는 팀을 가르는 차이점입니다.

조어된 프레임워크 (Coined Framework)

AI 조정 격차 (The AI Coordination Gap)

AI 조정 격차 (AI Coordination Gap)는 개별적으로는 유능한 AI 구성 요소들 — 강력한 모델, 좋은 벡터 저장소 (Vector store), 깔끔한 프롬프트 (Prompt) — 이 있음에도 불구하고, 이들 사이에서 _진실 (Truth), 타이밍 (Timing), 상태 (State)_를 조정하는 계층이 없기 때문에 신뢰할 수 없는 시스템을 만들어내는 지속적인 실패 모드입니다. 이는 구성 요소의 역량과 시스템의 신뢰성 사이의 격차를 일컫습니다.

실시간 웹 검색 (Live web search)은 그 격차를 메우는 하나의 가교입니다. 즉, 모델의 추론 (Reasoning)과 진실 (현재 실제로 존재하는 것)을 조정합니다. 하나의 가교일 뿐입니다. 이를 전체 솔루션으로 취급하는 것이 바로 대부분의 팀이 저지를 실수입니다.

어제의 사실에 대해 95% 정확한 모델은 오늘 아침에 바뀐 사실에 대해서는 0% 정확합니다. 최신성 (Freshness)은 정확도의 개선이 아니라, 완전히 다른 축입니다.

AI 조정 격차: 에이전트가 실제로 무너지는 네 가지 계층

대부분의 에이전트 실패는 '모델 문제'로 오진됩니다. 그것은 조정 (Coordination)의 문제입니다. 데모는 아름답게 작동하지만 프로덕션 환경에서 무너지는 에이전트 기반 시스템의 원인을 감사할 때 제가 사용하는 프레임워크는 다음과 같습니다. 이 격차에는 네 가지 뚜렷한 계층이 있으며, AgentCore의 웹 검색 (Web Search on AgentCore)은 그중 세 가지에 닿아 있습니다.

83%
각 단계의 신뢰도가 97%인 6단계 파이프라인의 엔드 투 엔드 (End-to-end) 신뢰도
[arXiv compounding-error analysis, 2025](https://arxiv.org/abs/2305.10601)
...

계층 1 — 진실 계층 (The Truth Layer) (지금 현재 무엇이 실제인가)

이것이 바로 AgentCore의 웹 검색 (Web Search on AgentCore)이 직접적으로 해결하고자 하는 계층입니다. LLM의 파라미터 메모리 (Parametric Memory)는 학습 중단 시점 (Training Cutoff)에 고정된 스냅샷입니다. 어떤 최첨단 모델 (Frontier Model)에게라도 지난주에 일어난 사건에 대해 물어본다면, 모델은 답변을 거부하거나 허구의 내용을 만들어냅니다. 진실 계층 (The Truth Layer)은 가격, 뉴스, 문서 버전, 재고 수준, 규제 변화와 같이 '현재 무엇이 사실인가'를 해결하기 위한 시스템의 메커니즘입니다. 이 계층이 없다면, 당신의 에이전트는 유용한 비서가 아니라 확신에 찬 역사학자에 불과할 것입니다.

실시간 웹 검색은 추론 시점 (Inference Time)에 신선하고, 순위가 매겨졌으며, 출처가 명시된 콘텐츠를 컨텍스트 윈도우 (Context Window)에 주입함으로써 이 격차를 메웁니다. 여기서 중요한 엔지니어링적 뉘앙스는, 이것이 당신의 개인 코퍼스 (Private Corpus)에 대한 RAG (Retrieval-Augmented Generation)가 아니라, 개방되고 큐레이션되지 않았으며 적대적인 웹 (Open, Uncurated, Adversarial Web)에 대한 검색이라는 점입니다. 이러한 차이점이 결과를 검증하는 모든 방식의 근간이 됩니다. 저는 검증 계층 (Verification Layer)이 달리 말하기 전까지는 모든 검색 결과를 신뢰할 수 없는 입력값으로 취급할 것입니다.

계층 2 — 상태 계층 (The State Layer) (이 세션에서 무엇이 일어났는가)

에이전트는 다회차 작업 (Multi-turn Tasks)을 수행하는 동안 맥락을 놓치곤 합니다. 상태 계층 (The State Layer)은 메모리를 조정합니다. 즉, 사용자가 세 단계 전에 무엇을 물었는지, 어떤 도구들이 이미 실행되었는지, 어떤 중간 결과들이 존재하는지를 관리합니다. AgentCore는 웹 검색과는 별개로, 자체적인 메모리 프리미티브 (Memory Primitives)를 통해 이를 처리합니다. 웹 검색은 상태 계층에 신선한 사실을 공급하지만, 상태 계층을 대체하지는 않습니다. 이 둘을 혼동하는 것은 팀의 디버깅 시간을 몇 주씩 잡아먹는 전형적인 실수입니다. 에이전트 메모리 패턴 (Agent Memory Patterns)에 대한 우리의 심층 분석에서는 상태 (State)와 검색 (Retrieval)을 어떻게 깔끔하게 분리하여 유지할 수 있는지 상세히 다룹니다.

계층 3 — 라우팅 계층 (The Routing Layer) (언제 어떤 기능을 호출할 것인가)

이곳이 바로 멀티 에이전트 오케스트레이션 (multi-agent orchestration)이 존재하는 지점입니다. 에이전트는 다음과 같이 결정해야 합니다: 매개변수 지식 (parametric knowledge)으로 답변할 것인가, 개인 벡터 저장소 (private vector store)를 쿼리할 것인가, 아니면 실시간 웹을 검색할 것인가? 잘못된 라우팅 (routing)은 비용이 많이 듭니다. 매 턴마다 웹 검색을 수행하면 지연 시간 (latency)과 비용이 발생하며, 전혀 검색하지 않으면 신뢰를 잃게 됩니다. MCP 도구 설명을 가이드로 삼는 모델의 도구 사용 추론 (tool-use reasoning)이 이를 조정합니다. 도구 설명을 잘못 작성하면 에이전트는 두 숫자를 더하기 위해 웹을 검색합니다. 저는 실제 운영 환경에서 이를 목격했습니다. 결코 사소한 문제가 아닙니다.

계층 4 — 검증 계층 (The Verification Layer) (이 결과를 신뢰할 수 있는가)

가장 어렵고 가장 덜 구축된 계층입니다. 실시간 웹 결과에는 SEO 스팸, 오래된 캐시 페이지, 그리고 명백한 오정보가 포함되어 있습니다. 검증 계층 (Verification Layer)은 주장들을 교차 검증하고, 출처의 권위 (source authority)를 평가하며, 최종 답변에 무엇을 포함할지 결정합니다. 웹 검색 (Web Search)은 이 계층이 대조할 수 있도록 출처 URL을 정확하게 반환하지만, AWS가 당신을 위해 이 계층을 구축해주지는 않습니다. 당신이 직접 구축해야 합니다. 아무도 당신을 대신해 해주지 않을 것입니다.

정립된 프레임워크

AI 조정 격차 (The AI Coordination Gap)

운영 측면에서 재정의하자면: AI 조정 격차 (AI Coordination Gap)는 모델 단위가 아니라 계층 단위로 해결됩니다. AgentCore의 웹 검색은 관리형 진실 계층 (managed Truth Layer)입니다. 이것이 당신의 라우팅 (Routing) 및 검증 (Verification) 책임을 면제해주지는 않습니다.

AI 에이전트로 승리하고 있는 기업들은 가장 많은 GPU를 보유한 기업들이 아닙니다. 다른 모든 이들이 어떤 모델을 사용할지 논쟁하고 있을 때, 검증 계층 (Verification Layer)을 구축한 기업들입니다.

네 가지 계층으로 나뉜 AI 조정 격차 (AI Coordination Gap). Bedrock AgentCore의 웹 검색은 관리형 진실 계층 (managed Truth Layer)이며, 나머지 세 계층은 여전히 당신의 엔지니어링 책임으로 남아 있습니다.

AgentCore의 웹 검색이 실제로 작동하는 방식

요청 경로 (request path)에 대해 구체적으로 살펴보겠습니다. 지연 시간 (latency)과 실패 동작 (failure behavior)은 바로 이러한 세부 사항에 달려 있기 때문입니다.

Bedrock AgentCore 내부의 실시간 웹 검색 요청 경로 (Live Web Search Request Path Inside Bedrock AgentCore)

  1

    **에이전트 추론 루프 (Agent reasoning loop, Bedrock 모델)**

모델은 사용자 쿼리 (user query)를 평가하고, 웹 검색을 위한 MCP 도구 설명을 읽은 뒤, 실시간 조회가 필요한지 결정합니다. 출력: 구조화된 검색 쿼리 (structured search query). 지연 시간 (latency): 모델에 따라 다르며, 통상적으로 300–900ms입니다.

↓

  2
...

쿼리는 IAM 범위 (IAM scope)와 속도 제한 (rate limits)을 강제하는 AgentCore의 게이트웨이 (gateway)를 통과한 후, 관리형 웹 검색 도구로 라우팅 (route)됩니다. 귀하의 팀이 직접 관리하는 스크레이퍼 인프라 (scraper infra)는 필요하지 않습니다.

↓

  3
...

AWS는 실시간 웹 소스를 대상으로 검색을 실행하고, 중복을 제거하며, 소스 URL과 함께 깨끗하고 읽기 쉬운 콘텐츠를 추출합니다. 지연 시간 (latency): 결과 수와 깊이에 따라 통상적으로 800ms–2.5s입니다.

↓

  4
...

순위가 매겨지고 정제된 결과가 에이전트로 반환되며, 출처 표기 (attribution)와 함께 컨텍스트 윈도우 (context window)에 주입됩니다. 이제 모델은 최신의 그라운드 트루스 (ground truth)를 바탕으로 추론합니다.

↓

  5
...

귀하의 프롬프트 로직 (prompt logic) 또는 보조 에이전트 (secondary agent)가 소스의 권위 (authority)를 교차 검증하고, 충돌을 해결하며, 인용된 답변을 합성 (synthesize)합니다. 이 단계는 AWS가 대신 구축해 주지 않는 계층입니다.

전체 실시간 검색 경로 — 단계 1~4는 AWS가 관리하지만, 단계 5(검증)가 실제 운영 환경의 신뢰성 (production reliability)을 결정짓는 지점이라는 점에 유의하십시오.

검색이 보강된 턴 (search-augmented turn)당 전체 엔드 투 엔드 (end-to-end) 지연 시간 예산은 대략 1.1s–3.4s입니다. 고객 대상 채팅 에이전트의 경우, 이는 즉각적인 느낌과 느릿한 느낌을 가르는 차이입니다. 이것이 바로 라우팅 계층 (Routing Layer)이 중요한 이유입니다. 모든 턴에서 검색을 수행하는 것이 아니라, 모델의 파라메트릭 지식 (parametric knowledge)에 대한 확신이 낮거나 쿼리가 명시적으로 시간에 민감할 때만 검색을 수행해야 합니다.

운영 환경에서의 경험칙 (Rule of thumb): 만약 에이전트 턴의 30% 이상이 실시간 웹 검색을 트리거한다면, 이는 검색 도구의 문제가 아니라 라우팅 로직 (routing logic)이 잘못된 것입니다. 공격적으로 캐싱 (cache)하고, 명시적인 최신성 신호 (freshness signals) 뒤에 검색을 배치하십시오.

최소 구성 연결 예시 (MCP 도구 등록)

python — AgentCore 웹 검색을 MCP 도구로 등록

Bedrock AgentCore 에이전트를 위한 예시 MCP 도구 등록

Web Search 도구는 AgentCore Gateway를 통해 MCP 엔드포인트로 노출됩니다.

from mcp import ClientSession
from bedrock_agentcore import AgentRuntime, Gateway

1. 에이전트가 관리형 Web Search MCP 엔드포인트를 가리키도록 설정합니다.

gateway = Gateway(
name='web-search-gateway',
tools=['agentcore.builtin.web_search'], # 관리형, 스크래퍼 인프라 불필요
)

2. 에이전트가 매 턴마다 검색하지 않도록 라우팅 가드 (routing guard)를 정의합니다.

SEARCH_POLICY = {
'trigger_when': ['time_sensitive', 'low_parametric_confidence'],
'max_results': 5, # 지연 시간 (latency) 제한 유지
'require_source_urls': True, # 검증 계층 (Verification Layer)에 제공
}

3. 에이전트의 추론 루프 (reasoning loop)가 결정하며, 게이트웨이가 IAM 및 속도 제한 (rate limits)을 강제합니다.

runtime = AgentRuntime(
model='anthropic.claude-sonnet',
gateway=gateway,
policy=SEARCH_POLICY,
)

4. 종합 (synthesis)하기 전에 반드시 검증하십시오 — AWS가 출처를 반환하면, 사용자가 이를 판단합니다.