원문은 twarx.com에서 처음 게시되었습니다 - 전체 대화형 버전은 그곳에서 읽을 수 있습니다.

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

대부분의 AI 기술 워크플로우는 완전히 잘못된 문제를 해결하고 있습니다. AWS가 방금 Amazon Bedrock AgentCore의 웹 검색 (Web Search on Amazon Bedrock AgentCore) 기능을 출시했으며, 온라인에서 가장 큰 반응은 정보의 최신성(freshness)에 관한 것이었습니다. 즉, 마침내 오늘 무슨 일이 일어났는지 아는 에이전트(agents)에 대한 이야기입니다. 이는 표면적인 이야기일 뿐이며, AI 기술의 더 넓은 관점에서 볼 때 가장 흥미롭지 않은 부분입니다.

AgentCore 웹 검색은 내장된 인용(citation), 속도 제한(rate-limiting), 그리고 신원 제어(identity controls) 기능을 갖추고, Bedrock 에이전트에게 실시간의 근거 있는 웹 검색(grounded retrieval)을 제공하는 관리형 도구(managed tool)입니다. 이것이 지금 중요한 이유는 모든 진지한 에이전트 스택(agent stack) — LangGraph, CrewAI, AutoGen — 이 동시에 동일한 벽에 부딪히고 있기 때문입니다.

이 글을 읽고 나면, 여러분은 프로덕션급 웹 검색 에이전트를 설계하고, 에이전트를 망가뜨리는 다섯 가지 실패 요인을 피하며, 진짜 병목 현상(bottleneck)이 무엇인지 알게 될 것입니다. 그것은 검색(retrieval)이 아니라 조정(coordination)입니다.

Amazon Bedrock AgentCore 웹 검색은 에이전트의 추론 루프(reasoning loop)와 라이브 웹 사이에 위치하며, 검색(retrieval), 인용(citation), 속도 제한(rate-limiting)을 관리형 인프라(managed infrastructure)로서 처리합니다. 이것은 대부분의 팀이 직접 구축하려고 시도하지만, 잘못 구축하게 되는 계층입니다.

개요: AgentCore 웹 검색이 실제로 변화시키는 것

지난 2년 동안, 프로덕션 환경에서의 지배적인 AI 에이전트 (AI agents) 패턴은 정적인 벡터 저장소 (vector store)를 대상으로 하는 검색 증강 생성 (Retrieval-Augmented Generation, RAG)이었습니다. 데이터를 스크래핑하고, 청킹(chunking)하고, 임베딩(embedding)한 뒤 쿼리하는 방식입니다. 모델은 세상의 고정된 스냅샷을 바탕으로 답변합니다. 이는 마지막 임베딩 작업 이후에 발생한 일들 — 주가, 규제 변화, 경쟁사의 가격 책정, 갑작스러운 서비스 중단 등 — 에 대해 사용자가 질문하기 전까지는 완벽하게 작동합니다.

AgentCore 웹 검색은 그 간극을 메웁니다. 이는 Amazon Bedrock AgentCore 내부의 퍼스트 파티 (first-party) 도구로, 에이전트가 추론 (reasoning) 중간에 이를 호출하여 오픈 웹 (open web)으로부터 실시간으로 랭킹이 매겨지고 인용된 결과를 가져올 수 있습니다. 프록시 스크래핑 (proxy scraping)도 필요 없고, 직접 SerpAPI 키를 관리할 필요도 없으며, 인용 계층 (citation layer)을 처음부터 구축할 필요도 없습니다. 모델이 답변의 근거로 삼을 수 있는 소스 URL이 포함된 구조화된 결과를 반환하며, AgentCore의 정체성 (identity), 메모리 (memory), 관찰 가능성 (observability) 프리미티브 (primitives)를 그대로 상속받습니다. 공식적인 기능 상세 분석은 AWS Bedrock Agents documentation을 참조하십시오.

여기서 직관에 반하는 부분이 있으며, 이것이 이 글의 핵심 논지입니다: 웹 검색은 결코 어려운 문제가 아니었습니다. 누구나 검색 API를 호출할 수 있습니다. 진짜 어려운 문제는 검색 기능이 활성화된 에이전트가 6개의 노드로 구성된 시스템 중 하나의 노드일 때, 그리고 모든 노드가 무엇이 사실인지, 무엇이 최신인지, 그리고 다음에 무엇을 해야 하는지에 대해 합의해야 할 때 발생합니다. 이것이 바로 AI 조정 격차 (AI Coordination Gap)이며, AgentCore 웹 검색이 흥미로운 이유는 바로 이것이 단독 API가 아닌 조정 프리미티브 (coordination primitive)로 설계된 첫 번째 주요 검색 도구이기 때문입니다.

명명된 프레임워크

AI 조정 격차 (The AI Coordination Gap)

AI 조정 격차 (AI Coordination Gap)는 진실성 (truth), 최신성 (freshness), 상태 (state)에 대한 공유 프로토콜 없이 개별적으로는 신뢰할 수 있는 AI 구성 요소들을 체인(chain)으로 연결했을 때 나타나는 복합적인 실패를 의미합니다. 이는 각 단계가 개별적으로는 잘 작동함에도 불구하고, 시스템 전체적으로는 여전히 잘못된 답변을 내놓는 이유를 설명합니다.

시니어 엔지니어들은 이러한 격차를 직관적으로 느낍니다. 당신은 리서치 에이전트 (research agent)를 구축합니다. 검색기 (retriever)는 잘 작동합니다. 요약기 (summarizer)도 잘 작동합니다. 검증기 (verifier)도 잘 작동합니다. 데모를 보여주면 완벽해 보입니다. 하지만 프로덕션 (production)에 배포하면, 2023년의 가격을 현재 가격으로 인용하거나, 두 에이전트가 서로 모순되는 데이터를 가져왔을 때 오케스트레이터 (orchestrator)가 조용히 잘못된 것을 선택하기 시작합니다. 아무것도 고장 나지 않았습니다. 모든 것이 제대로 조정(coordination)되지 않았을 뿐입니다.

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

이 가이드는 AgentCore Web Search를 계층 구조 (framework of layers)로 분해하여, 실제 설정 (config)을 통해 각 계층이 실무에서 어떻게 작동하는지 보여주고, 배포 과정을 살펴보고, 팀원들이 질문할 법한 FAQ 수준의 답변을 제공합니다. 이 글을 다 읽을 때쯤이면, 기업용 AI (enterprise AI) 분야에서 승리하고 있는 팀들이 단순히 가장 최신의 데이터를 가진 팀이 아니라, 조정 격차 (coordination gap)를 해소한 팀이라는 사실을 알게 될 것입니다.

웹 검색 (Web search)은 결코 어려운 문제가 아니었습니다. 조정 (Coordination)이 문제였습니다. AgentCore는 설계 단계에서부터 이 점을 인정하는 최초의 검색 도구 (retrieval tool)입니다.

실시간 AgentCore 웹 검색 시스템의 5가지 계층

AgentCore Web Search를 단일 API 호출로 취급한다면, 데모는 성공하겠지만 감사 (audit)에서는 실패할 것입니다. 올바른 멘탈 모델 (mental model)은 조정된 5개의 계층입니다. 각 계층은 AI 조정 격차 (AI Coordination Gap)가 벌어지거나 좁혀지는 지점입니다.

AgentCore Web Search 조정 스택 (요청부터 근거 있는 답변까지)

  1

    **의도 및 최신성 라우터 (Intent & Freshness Router)**

에이전트의 추론 루프 (reasoning loop) (Bedrock 모델 + AgentCore)는 쿼리 (query)에 실시간 데이터가 실제로 필요한지 여부를 결정합니다. 정적인 질문은 메모리/RAG (RAG)로 향하고, 시간에 민감한 질문은 웹 검색 (Web Search)을 트리거합니다. 여기서 잘못된 라우팅 (misrouting)이 발생하는 것이 오래된 답변이 나오는 가장 흔한 원인입니다. 지연 시간 예산 (latency budget): 약 50ms 결정.

↓

  2
...

관리형 검색 호출 (Managed retrieval call). 소스 URL, 스니펫 (snippets), 타임스탬프 (timestamps)와 함께 순위가 매겨진 결과를 반환합니다. 속도 제한 (rate-limiting), 재시도 (retries), 프로바이더 추상화 (provider abstraction)를 처리합니다. 사용자는 키 (keys)나 프록시 (proxies)를 직접 관리할 필요가 없습니다. 일반적인 지연 시간: 쿼리당 400–900ms.

↓

  3
...

모델이 생성하는 각 주장 (claim)은 검색된 소스 URL과 결합됩니다. 이것이 환각 (hallucination) 위험이 급감하는 지점입니다. 모델은 인용된 스니펫 (snippet)이 지원하는 내용만을 단언할 수 있습니다. 결합되지 않은 주장은 플래그가 지정되거나 제외됩니다.

↓

  4
...

두 소스가 서로 상충할 때 (가격 A vs 가격 B, 날짜 X vs 날짜 Y), 이 계층은 최신성 (recency) + 권위 (authority) 휴리스틱 (heuristic)을 적용하여, 조용히 하나를 선택하는 대신 충돌을 표면화합니다. 이것이 AI 조정 격차 (AI Coordination Gap)의 핵심입니다.

↓

  5
...

AgentCore Memory는 무엇이, 언제, 어디에서 검색되었는지를 기록합니다. 다운스트림 에이전트 (downstream agents)는 다시 검색하는 대신 이 공유된 상태 (shared state)를 읽음으로써, 모순되는 병렬 검색을 방지합니다. 감사를 위해 전체 추적 (trace)이 로그로 기록됩니다.

검색 호출 그 자체가 아니라, 최신성 라우팅 (freshness routing)과 충돌 해결 (conflict resolution)이 멀티 에이전트 시스템 (multi-agent systems)이 조용히 무너지는 지점이기 때문에 이 시퀀스 (sequence)가 중요합니다.

Layer 1: 의도 및 최신성 라우터 (The Intent & Freshness Router)

실시간 에이전트에서 가장 비용이 많이 드는 실수는 모든 것에 대해 웹 검색을 호출하는 것입니다. 이는 느리고, 쿼리당 비용이 발생하며, 컨텍스트 (context)를 노이즈로 가득 채웁니다. 라우터는 가벼운 분류 단계로, 종종 도구 사용 (tool-use) 결정을 내리는 동일한 Bedrock 모델을 사용하여 다음과 같이 질문합니다: "이 질문에 답하기 위해 최근에 변경된 지식이 필요한가?"

'프랑스의 수도는 어디인가?' → 검색 불필요. 'us-east-1의 현재 AWS Lambda 가격은 얼마인가?' → 검색 필요, 가격은 변하기 때문입니다. 훌륭한 라우터는 검색 호출 볼륨을 60–70% 절감하고 지연 시간 (latency)을 극적으로 개선합니다. LangGraph를 사용하는 팀들은 바로 이 지점에서 검색 노드 이전에 조건부 엣지 (conditional edge)를 추가합니다. LangGraph conditional-edge docs에서 정확한 패턴을 확인할 수 있습니다.

프로덕션 환경에서 모든 쿼리를 웹 검색으로 라우팅했을 때, 최신성 게이트 (freshness-gated) 라우터를 사용할 때보다 평균 지연 시간이 640ms 증가하고 API 비용이 세 배로 늘어났습니다. 반면 정적 질문에 대한 정확도 향상은 전혀 없었습니다. 가져오기(fetch) 전에 게이트를 두십시오.

Layer 2: 관리형 검색 호출 (The Managed Search Call)

이 부분은 AWS가 실제로 출시한 부분이며, 여러분이 더 이상 직접 구축할 필요가 없는 부분입니다. AgentCore Web Search가 나오기 전에는 팀마다 SerpAPI, Bing Search API, Tavily, 또는 자체 제작한 헤드리스 브라우저 스크래퍼(headless-browser scrapers)를 연결하여 사용했습니다. 각 방식은 고유의 인증(auth), 속도 제한(rate limits), 그리고 취약한 파싱(parsing) 문제를 안고 있었습니다. AgentCore는 이를 표준 도구 사용(tool-use) 인터페이스를 통해 에이전트가 호출할 수 있는 단일 관리형 도구(managed tool) 뒤로 추상화합니다.

Python — Bedrock 에이전트 런타임(agent runtime)을 통해 AgentCore Web Search를 호출하기

프로덕션 준비 완료: 에이전트가 호출할 수 있는 도구로서의 AgentCore Web Search

import boto3

agent = boto3.client('bedrock-agentcore') # AgentCore 런타임 클라이언트

response = agent.invoke_agent(
agentId='research-agent-prod',
sessionId='sess-9f2c',
inputText='What is the current Anthropic Claude API pricing per million tokens?',

웹 검색(Web Search)이 에이전트의 관리형 도구로 등록되어 있습니다.

모델이 호출 시점을 결정하며, AgentCore가 실행을 처리합니다.

enableTrace=True # 감사를 위해 어떤 소스가 검색되었는지 캡처합니다
)

response에는 근거가 있는 답변(grounded answer) + 인용된 소스 URL(cited source URLs) + 타임스탬프(timestamps)가 포함됩니다

for citation in response['citations']:
print(citation['sourceUrl'], citation['retrievedAt'])

여러분이 하지 않고 있는 작업들에 주목하십시오: 검색 제공업체를 위한 API 키 관리, 429 속도 제한(rate limits) 처리, HTML 파싱, 또는 결과 형식의 정규화(normalizing) 등입니다. 이것이 바로 관리형 서비스의 가치입니다. 이는 연구 단계가 아닌, 오늘 바로 프로덕션에 적용할 수 있는 수준입니다. boto3 SDK 레퍼런스에서 전체 에이전트 런타임 인터페이스를 확인할 수 있습니다.

Layer 3: 근거 제시 및 인용 결합기 (The Grounding & Citation Binder)

이것이 바로 검색 기능이 있는 에이전트와 자신만만하게 거짓말을 하는 에이전트를 구분 짓는 요소입니다. 근거 제시 (Grounding)는 생성된 모든 주장을 검색된 출처와 결합합니다. AgentCore는 URL과 스니펫 (snippets)이 포함된 구조화된 결과를 반환하여, 모델이 스니펫이 지원하는 내용만을 주장하도록 지시받고 — 또한 감사(audited)받을 수 있도록 합니다. 근거 기반 생성 (grounded generation)에 관한 Anthropic의 연구에 따르면, 인용이 결합된 답변은 근거가 없는 답변에 비해 사실 오류율을 약 절반 정도로 줄여줍니다.

출처를 인용할 수 없는 에이전트는 지능적인 것이 아니라, 홍보(PR)를 잘하는 매우 유창한 추측기에 불과합니다.

정립된 프레임워크 (Coined Framework)

AI 조정 격차 (The AI Coordination Gap)

AI 조정 격차 (AI Coordination Gap)는 개별적으로는 신뢰할 수 있는 AI 구성 요소들이 진실성, 최신성, 그리고 상태 (state)를 위한 공유 프로토콜 없이 체인 (chain)으로 연결될 때 발생하는 복합적인 실패를 의미합니다. 근거 제시 (Grounding)와 충돌 해결 (conflict resolution)은 이 격차를 능동적으로 메우는 두 가지 계층입니다.

Layer 4: 충돌 해결기 (The Conflict Resolver)

라이브 웹은 모순적입니다. '현재 GPT-4 컨텍스트 윈도우 (context window)'를 검색하면 서로 다른 세 개의 날짜에서 나온 세 개의 숫자를 발견하게 될 것입니다. 단순한 에이전트는 그중 순위가 가장 높은 것을 선택합니다. 조정된 에이전트는 최신성 가중치 (recency-weighting)와 출처 권위 (source authority)를 적용하며 — 결정적으로 — 불확실성을 거짓된 확신으로 세탁하는 대신, 그 충돌을 사용자나 다운스트림 노드 (downstream node)에 드러냅니다.

이것은 모든 멀티 에이전트 시스템 (multi-agent system)에서 가장 레버리지가 높은 단일 계층입니다. 연구 에이전트와 검증 에이전트가 모두 독립적으로 웹을 쿼리하여 서로 다른 스냅샷을 얻었을 때, AgentCore 메모리 (AgentCore Memory)의 지원을 받는 충돌 해결기는 오케스트레이터 (orchestrator)가 모순된 상태를 바탕으로 행동하는 것을 방지합니다.

Layer 5: 관측 가능성 및 상태 쓰기 (Observability & State Writeback)

모든 검색(retrieval)은 로그로 기록됩니다: 어떤 쿼리였는지, 어떤 소스였는지, 타임스탬프는 언제인지, 그리고 모델이 그것을 어떻게 처리했는지에 대한 정보입니다. 그러면 AgentCore Memory는 하위 에이전트(downstream agents)가 데이터를 다시 가져오느라 다른 스냅샷(snapshot)을 얻게 될 위험을 감수하는 대신, 공유된 검색 상태(retrieval state)를 읽을 수 있게 해줍니다. 이것이 바로 병렬 에이전트들이 서로 상충하는 결론을 내리는 것을 방지하는 방법입니다. 또한 규제 기관이나 CFO가 "이 숫자가 어디에서 나왔습니까?"라고 물을 때 사용할 수 있는 감사 추적(audit trail) 역할도 합니다. 더 넓은 관측 가능성(observability) 측면을 살펴보려면, AgentCore가 추적하는 트레이싱 표준(tracing standards)을 다루는 OpenTelemetry documentation을 참고하십시오.

5계층 조정 스택(five-layer coordination stack). 대부분의 팀은 2계층과 3계층을 구축하지만, 승리하는 팀은 1, 4, 5계층을 구축합니다. 바로 이 지점에서 AI 조정 격차(AI Coordination Gap)가 실제로 해소됩니다.

AgentCore 웹 검색과 대안들의 비교